Docs
...
Matching algorithms in IBM Match 360

Abgleichalgorithmen in IBM Match 360

Letzte Aktualisierung: 22. Nov. 2024
Abgleichalgorithmen in IBM Match 360

IBM Match 360 verwendet Abgleichsalgorithmen, um Datensätze in Stammdateneinheiten aufzulösen. Datenentwickler können unterschiedliche Abgleichalgorithmen für jeden Entitätstyp in ihren Daten definieren. Die Abgleichalgorithmen können danach die Daten analysieren, um Datensätze auszuwerten und zu vergleichen, und anschließend die abgeglichenen Datensätze in Entitäten zu erfassen.

Zwei häufige Gründe für den Datenabgleich:

  • Zum Entfernen doppelter Datensätze und zum Auflösen von Entitäten analysiert der Abgleichsprozess Ihre Daten, um festzustellen, ob in Ihren Daten doppelte Datensätze vorhanden sind. Mutmaßliche Duplikate werden in Stammdatenentitäten zusammengeführt, um eine einzelne, zuverlässige 360-Grad-Ansicht Ihrer Daten zu erstellen.
  • Zum Erstellen anderer Typen von Entitätszuordnungen analysiert der Abgleichsprozess Ihre Daten, um Datensätze in Entitäten zu erfassen, die verschiedene Arten von Gruppierungen darstellen (z. B. einen Haushalt).

Sehen Sie sich das folgende Video an, um zu erfahren, wie Sie mit IBM Match 360 einen Abgleichalgorithmus für ein angepasstes Datenmodell einrichten können.

Dieses Video bietet eine visuelle Methode zum Erlernen der Konzepte und Tasks in dieser Dokumentation.

Inhalt dieses Themas:

Abgleich zum Erstellen mehrerer Entitätstypen

IBM Match 360-Abgleichalgorithmen werden vom Entitätstyp der zugeordneten Daten gesteuert. Für jeden Datensatztyp im Datenmodell können Sie mehrere Entitätstypen definieren. Konfigurieren und optimieren Sie für jeden Entitätstyp den entsprechenden Abgleichalgorithmus, um sicherzustellen, dass die von IBM Match 360 erstellten Entitäten die Anforderungen Ihres Unternehmens erfüllen.

Ein einzelner Datensatz kann mehr als einer separaten Entität angehören. Wenn Ihr Datenmodell mehr als einen Entitätstyp enthält, können Sie verschiedene Abgleichstypen auf dasselbe Dataset anwenden. Angenommen, Sie verfügen über ein Dataset, das Personendatensätze aus Ihrem gesamten Unternehmen enthält. Wenn der Datensatztyp 'Person' Definitionen für einen Entitätstyp 'Person' und einen Entitätstyp 'Haushalt' enthält, können Sie den Abgleichalgorithmus 'Person' für Entitätsauflösung und Deduplizierung verwenden und den Abgleichalgorithmus 'Haushalt', um Entitäten zu erstellen, die aus Datensätzen des Typs 'Person' bestehen, die demselben Haushalt angehören.

Der Abgleichsprozess

Die Matching-Engine führt einen definierten Prozess aus, um Datensätze zu Entitäten zusammenzufassen. Dieser Abgleichsprozess umfasst die drei folgenden Hauptschritte:

  1. Standardisierung In diesem Schritt standardisiert der Algorithmus das Format der Daten, damit sie von der Matching-Engine verarbeitet werden können.

  2. Gruppierung (Bucketing) Der Algorithmus klassifiziert Daten in verschiedene Kategorien (Buckets), damit ähnliche Einzelinformationen verglichen werden können.

  3. Vergleichen Der Algorithmus vergleicht Daten, um einen finalen Vergleichsscore zu ermitteln. Anschließend ermittelt der Algorithmus anhand des Vergleichsscores fest, ob die Datensätze als Übereinstimmungen einzustufen sind.

Jeder dieser Schritte wird durch den Abgleichalgorithmus definiert und konfiguriert.

Regeln für die Widerstandsfähigkeit

Sie können die IBM Match 360 API verwenden, um Ausfallsicherheitsregeln zu konfigurieren, die die Reaktion des Abgleichsalgorithmus auf Datensatzdatenänderungen begrenzen.

Ohne Ausfallsicherheitsregeln gibt es eine Reihe möglicher Änderungen der Entitätsverknüpfung, die auftreten können, wenn ein Stammdatensatz hinzugefügt, aktualisiert oder gelöscht wird:

  • Wenn ein neuer Datensatz hinzugefügt wird, kann er:

    • Beitritt zu einem bestehenden Unternehmen.
    • Zwei oder mehr bestehende Entitäten zusammenfügen, indem sie als Klebedatensatz fungieren.
    • Bilden Sie eine neue Singleton-Entität.

  • Wenn ein Datensatz aktualisiert wird, kann er das:

    • Sie gehören nicht mehr zu ihrer aktuellen Entität und werden zu einer neuen Singleton-Entität.
    • Nicht mehr zu seiner derzeitigen Einheit gehören und sich einer anderen bestehenden Einheit anschließen.
    • Seine aktuelle Entität in mehrere Entitäten aufspalten lassen.
    • Veranlassen Sie andere Entitäten, sich der bestehenden Entität anzuschließen, indem Sie als "glue record" fungieren.
    • Verursacht keine Änderungen in der Entitätszusammensetzung.

  • Wenn ein Datensatz gelöscht wird, kann er:

    • Veranlassen Sie, dass seine Singleton-Entität ebenfalls gelöscht wird.
    • Verursacht die Aufspaltung seiner aktuellen Entität.

Durch die Definition von Ausfallsicherheitsregeln können Datentechniker konfigurieren, wie die IBM Match 360 Matching Engine auf jedes dieser Szenarien reagiert. Die Matching Engine steuert ihr Verknüpfungsverhalten so, dass es mit den von Ihnen konfigurierten Ausfallsicherheitsregeln übereinstimmt. Durch die Konfiguration von Ausfallsicherheitsregeln können Sie die Zusammenführung und Aufteilung von Entitäten einschränken, was zu einer stabileren Zusammensetzung von Entitäten führt.

Definieren Sie Ausfallsicherheitsregeln mit Hilfe der API " resiliency_rules. Wenn eine bestimmte Regel auf " FALSE gesetzt wird, dann wird das entsprechende Entity-Linking-Szenario seine üblichen Entity-Linking-Änderungen nicht durchführen.

Führen Sie den folgenden API-Befehl aus, um den aktuellen Satz von Ausfallsicherheitsregeln abzurufen:

GET /mdm/v1/resiliency_rules

Um die Resiliency-Regeln zu aktualisieren, führen Sie den folgenden API-Befehl mit einer aktualisierten Nutzlast aus:

PUT /mdm/v1/resiliency_rules

{
"link_resiliency_rules": {
  "records": {
     "person": {
        "add": {
           "join_existing_entity": "true/false",
           "merge_entities": "true/false"
        },
        "update": {                                                                                    
            "record_becoming_singleton": "true/false",
            "join_existing_entity": "true/false",
            "original_entity_split": "true/false",
            "merge_entities": "true/false"
        },
        "delete": {
            "singleton_entity_deletion": "true",
            "original_entity_split": "true/false"
        }
     }
   },
   "entities": {
   }
 }
}

Komponenten des Abgleichalgorithmus

Drei Haupttypen von Komponenten definieren einen IBM Match 360 -Abgleichalgorithmus:

Standardisierer

Wie der Name vermuten lässt, legen Standardisierer fest, wie Daten standardisiert werden. Die Standardisierung ermöglicht dem Abgleichalgorithmus, die Werte verschiedener Attribute in eine standardisierte Darstellung umzuwandeln, die von der Matching-Engine verarbeitet werden kann.

Der Abgleichalgorithmus verwendet mehrere Standardisierer. Jeder Standardisierer ist für die Verarbeitung bestimmter Attributtypen konzipiert, die in Datensatzdaten enthalten sind.

Standardisierer werden durch JSON-Objekte definiert. Die Definition des JSON-Objekts für jeden Standardisierer enthält drei Elemente:

  • label - Eine Bezeichnung, die diesen Standardisierer identifiziert.

  • inputs - Die Liste inputs enthält ein einzelnes Element, bei dem es sich um ein JSON-Objekt handelt. Dieses JSON-Objekt enthält die beiden Elemente fields und attributes:

    • fields - Die Liste der Felder, die für die Standardisierung verwendet werden sollen.
    • attributes - Die Liste der Attribute, die für die Standardisierung verwendet werden sollen.

  • standardizer_recipe - Eine Liste mit JSON-Objekten. Dabei stellt jedes Objekt einen Schritt dar, der im Standardisierungsprozess des zugehörigen Standardisierers ausgeführt werden soll. Jedes Objekt in der Liste standardizer_recipe besteht aus vier Hauptelementen:

    • label - Eine Bezeichnung, die diesen Schritt im Konzept des Standardisierers identifiziert.
    • method - Die verwendete interne Methode. Dieses Element dient nur zu Referenzzwecken und darf nicht bearbeitet werden.
    • inputs -Ein einzelnes Element der Liste inputs , das eine Ebene höher definiert ist.
    • fields - Eine Liste der Felder, die für diesen Schritt verwendet werden sollen. Dies ist im Allgemeinen eine Untergruppe aller Felder, die in der Liste inputs eine Ebene höher definiert sind. Nicht in jedem Schritt müssen alle Felder aus inputs verarbeitet werden.
    • set_resource - Der Name einer anpassbaren Ressource des Typs set, die für diesen Schritt verwendet wird.
    • map_resource - Der Name einer anpassbaren Ressource des Typs map, die für diesen Schritt verwendet wird.

    Je nach Ausführungsverhalten eines Schritts können weitere Konfigurationselemente vorhanden sein, die für das jeweilige JSON-Objekt erforderlich sind.

Vorkonfigurierte Standardisierer

Die folgenden Standardisierer können in IBM Match 360verwendet werden. Die vorkonfigurierten Standardisierer sind ebenfalls anpassbar.

Standardisierer für Personennamen

Dieser Standardisierer wird verwendet, um Attributwerte für den Personennamen zu standardisieren. Sie enthält nacheinander die folgenden Rezepte:

  1. Upper case -Konvertiert die Eingabefeldwerte, um ihre Entsprechungen in Großbuchstaben zu verwenden.
  2. Map character -Konvertiert UNICODE-Eingabezeichen in äquivalente englische Alphabetzeichen. Definieren Sie optional die Map in den IBM Match 360 -Ressourcen.
  3. Tokenizer -Zerlegt den Eingabefeldwert basierend auf der definierten Liste der Begrenzer in mehrere Token.
  4. Parse token -Parst die Eingabefeldwerte in verschiedene Tokens, abhängig von den vordefinierten Werten in den IBM Match 360 -Ressourcen. Sie können diese Anleitung beispielsweise verwenden, um Suffix-, Präfix-und Generierungswerte in entsprechende Felder zu parsen.
  5. Length -Verwirft Tokens, die außerhalb eines bestimmten Längenbereichs liegen. Mindest-und Maximalwerte sind in den IBM Match 360 -Ressourcen definiert.
  6. Stop token -Entfernt anonyme Eingabewerte wie konfiguriert.
  7. Pick token -Wählt eine Untergruppe (oder alle) der Token als standardisierte Daten für Bucketing und Vergleich aus.

Der Standardisierer für Personennamen verwendet standardmäßig die folgenden Mapressourcen:

  • map_character_general -Konvertiert UNICODE-Eingabezeichen in äquivalente englische Alphabetzeichen.
  • person_map_name_alignments -Parst Suffix-, Präfix-und Generierungswerte in geeignete Felder.

Der Standardisierer für Personennamen verwendet standardmäßig die folgenden Set-Ressourcen:

  • person_set_name_aname -Entfernt anonyme Personennamenswerte.
Standardisierer für Organisationsnamen

Dieser Standardisierer wird verwendet, um Attributwerte für Organisationsnamen zu standardisieren. Sie enthält nacheinander die folgenden Rezepte:

  1. Upper case -Konvertiert die Eingabefeldwerte, um ihre Entsprechungen in Großbuchstaben zu verwenden.
  2. Map character -Konvertiert UNICODE-Eingabezeichen in äquivalente englische Alphabetzeichen. Definieren Sie optional die Map in den IBM Match 360 -Ressourcen.
  3. Stop character -Entfernt unerwünschte Eingabezeichen aus den Namenswerten.
  4. Map token -Generiert Kurznamen oder alternative Namen für die angegebene Eingabe und speichert die Informationen in einem separaten neuen internen Feld.
  5. Tokenizer -Zerlegt den Eingabefeldwert basierend auf der definierten Liste der Begrenzer in mehrere Token.
  6. Stop token -Entfernt anonyme Eingabewerte wie konfiguriert.
  7. Acronym -Generiert ein Akronym für den angegebenen Organisationsnamen und speichert die Informationen in einem separaten neuen internen Feld. Dieser Akronymwert wird beim Vergleich verwendet, um abgekürzte Namen zu verarbeiten.
  8. Pick token -Wählt eine Untergruppe (oder alle) der Token als standardisierte Daten für Bucketing und Vergleich aus.

Der Standardisierer für Organisationsnamen verwendet standardmäßig die folgenden Mapressourcen:

  • map_character_general -Konvertiert UNICODE-Eingabezeichen in äquivalente englische Alphabetzeichen.
  • org_map_name_cnick_name -Generiert Kurznamen oder alternative Namen für die angegebene Eingabe

Der Standardisierer für Organisationsnamen verwendet standardmäßig die folgenden Set-Ressourcen:

  • org_set_name_aname -Entfernt anonyme Organisationsnamen.
Standardisierer für Datum

Dieser Standardisierer wird zum Standardisieren von Datumsattributwerten verwendet. Es unterstützt viele verschiedene Datumsformate und enthält die folgenden Rezepte, in der Reihenfolge:

  1. Map character -Konvertiert Schrägstriche (/) in Gedankenstriche (-).
  2. Date function -Konvertiert Datumseingaben in verschiedenen Formaten in ein standardisiertes Format.
  3. Stop token -Entfernt anonyme Datumswerte wie konfiguriert.
  4. Parse token -Parst die Eingabefeldwerte abhängig von bestimmten regulären Ausdrücken in verschiedene Tokens. Sie können dieses Rezept beispielsweise verwenden, um eine vollständige Datumseingabe in Tag-, Monats-und Jahrestoken zu analysieren.
  5. Pick token -Wählt eine Untergruppe (oder alle) der Token als standardisierte Daten für Bucketing und Vergleich aus.

Der Datumsstandardisierer verwendet standardmäßig die folgenden Mapressourcen:

  • map_character_date_separators-Konvertiert Schrägstrich (/) oder andere Trennzeichen in Gedankenstriche (-).
  • map_date_tokens_year_month_day -Parst den Eingabedatumswert in interne Felder, nämlich birth_year, birth_month und birth_day, basierend auf regulären Ausdrücken.

Der Datumsstandardisierer verwendet standardmäßig die folgenden Set-Ressourcen:

  • set_date_date -Entfernt anonyme Datumswerte.
Standardisierer für Geschlecht

Dieser Standardisierer wird verwendet, um die Werte von Geschlechtsattributen zu standardisieren. Sie enthält nacheinander die folgenden Rezepte:

  1. Map character -Konvertiert UNICODE-Eingabezeichen in äquivalente englische Alphabetzeichen. Definieren Sie optional die Map in den IBM Match 360 -Ressourcen.
  2. Upper case -Konvertiert die Eingabefeldwerte, um ihre Entsprechungen in Großbuchstaben zu verwenden.
  3. Stop token -Entfernt gemäß Konfiguration anonyme Eingabewerte für das Geschlecht.
  4. Map token -Konvertiert Eingabetokenwerte in äquivalente Werte, wie in den IBM Match 360 -Ressourcen konfiguriert.
  5. Parse token -Parst verarbeitete Feldwerte in ein geeignetes internes Feld.
  6. Pick token -Wählt eine Untergruppe (oder alle) der Token als standardisierte Daten für Bucketing und Vergleich aus.

Der Standardisierer für Geschlecht verwendet standardmäßig die folgenden Kartenressourcen:

  • map_character_general -Konvertiert UNICODE-Eingabezeichen in äquivalente englische Alphabetzeichen.
  • map_gender_gender -Ordnet verschiedene Eingabewerte für das Geschlecht den Standardwerten zu
  • map_gender_tokens_gender -Parst den Eingabetokenwert für das interne Feld gender auf der Basis eines regulären Ausdrucks.

Der Standardisierer für Geschlecht verwendet standardmäßig die folgenden Set-Ressourcen:

  • set_gender_anon_gender -Entfernt anonyme Eingabewerte für das Geschlecht.
Adressstandardisierer

Dieser Standardisierer wird verwendet, um Adressattributwerte zu standardisieren. Adressen können je nach Ländereinstellung verschiedene Formate haben. Diese Flexibilität erfordert eine komplexe Verarbeitung, um Adressen in eine standardisierte Form zu konvertieren. Der Adressstandardisierer enthält die folgenden Anleitungen in der Reihenfolge:

  1. Upper case -Konvertiert die Eingabefeldwerte, um ihre Entsprechungen in Großbuchstaben zu verwenden.
  2. Map character -Konvertiert UNICODE-Eingabezeichen in äquivalente englische Alphabetzeichen. Definieren Sie optional die Map in den IBM Match 360 -Ressourcen.
  3. Map token -Konvertiert Eingabetokenwerte in äquivalente Werte, wie in den IBM Match 360 -Ressourcen konfiguriert. Beispielsweise können "Vereinigte Staaten von Amerika", "Vereinigte Staaten" und "USA" allen "USA" zugeordnet werden. Diese Zuordnung gilt für Feldwerte für Land und Bundesland/Kanton. Darüber hinaus werden in der Ressource konfigurierte Begrenzungszeichen dem Leerzeichen zugeordnet.
  4. Tokenizer -Zerlegt den Eingabefeldwert basierend auf der definierten Liste der Begrenzer in mehrere Token.
  5. Stop token -Entfernt anonyme Eingabewerte, wie z. B. Postleitzahlen, wie konfiguriert.
  6. Keep token -Lässt nur die definierte Liste von Werten für ein bestimmtes Feld zu. Sie können beispielsweise eine Liste mit Postleitzahlen definieren, die während der Standardisierung zulässig sind. Eingabewerte, die nicht in der Liste der zulässigen Werte enthalten sind, werden entfernt.
  7. Parse token -Parst die Eingabefeldwerte abhängig von bestimmten regulären Ausdrücken und vordefinierten Werten, die in den Ressourcen konfiguriert sind, in geeignete interne Felder. Sie können diese Anleitung verwenden, um ein bestimmtes Token mithilfe von regulären Ausdrücken auf eine bestimmte Länge abzuschneiden. Sie können auch verschiedene alphanumerische Mustergruppen in Form von regulären Ausdrücken definieren, um nur bestimmte Muster zuzulassen.
  8. Join fields -verknüpft zwei oder mehr Felder miteinander, um einen neuen kombinierten Wert zu erstellen, der einem internen Feld zugeordnet ist Beispielsweise können latitude -und longitude -Feldwerte miteinander verknüpft werden, um ein neues internes Feld namens lat_longzu bilden.
  9. Pick token -Wählt eine Untergruppe (oder alle) der Token als standardisierte Daten für Bucketing und Vergleich aus.

Der Adressstandardisierer verwendet standardmäßig die folgenden Mapressourcen:

  • map_character_general -Konvertiert UNICODE-Eingabezeichen in äquivalente englische Alphabetzeichen.
  • map_address_country -Konvertiert die eingegebenen Landeswerte in äquivalente Werte.
  • map_address_province_state -Konvertiert Werte für Eingabeprovinz und Bundesstaat in äquivalente Werte.
  • map_address_delimiter_removal -Ordnet in der Ressource konfigurierte Begrenzungszeichen dem Leerzeichen zu.
  • map_address_addr_tok -Konvertiert die Tokenwerte der Eingabeadresse in äquivalente Werte.
  • map_address_tokens_unit_type_and_number -Parst das Eingabefeld residence_number auf der Basis eines regulären Ausdrucks in interne Felder, nämlich unit_type und unit_number.
  • map_address_tokens_street_number_name_direction_type -Parst das Eingabefeld address_line1 basierend auf einem regulären Ausdruck für interne Felder, nämlich street_number, street_name, directionund street_type.
  • map_address_tokens_sub_division -Parst das Eingabefeld address_line2 basierend auf einem regulären Ausdruck für das interne Feld sub_division.
  • map_address_tokens_pobox_type_and_number -Parst das Eingabefeld address_line3 auf der Basis eines regulären Ausdrucks in interne Felder, nämlich pobox_type und pobox.
  • map_address_tokens_city -Parst den Eingabewert des Felds city auf der Basis eines regulären Ausdrucks.
  • map_address_tokens_province -Parst den Eingabewert des Felds province_state auf der Basis eines regulären Ausdrucks für das interne Feld province.
  • map_address_tokens_postal_code -Parst den Eingabewert des Felds zip_postal_code auf der Basis eines regulären Ausdrucks für das interne Feld postal_code.
  • map_address_tokens_country -Parst den Eingabewert des Felds country auf der Basis eines regulären Ausdrucks.
  • map_address_tokens_latitude -Parst den Eingabewert des Felds latitude_degrees auf der Basis eines regulären Ausdrucks im internen Feld latitude.
  • map_address_tokens_longtitude -Parst den Eingabewert des Felds longitude_degrees auf der Basis eines regulären Ausdrucks für das interne Feld longitude.

Der Adressstandardisierer verwendet standardmäßig die folgenden Set-Ressourcen:

  • set_address_postal_code -Entfernt anonyme Eingabewerte für zip_postal_code.
Standardisierer für Telefonanruf

Dieser Standardisierer wird verwendet, um Telefonattributwerte zu standardisieren. Sie enthält nacheinander die folgenden Rezepte:

  1. Stop character -Entfernt unerwünschte Eingabezeichen aus Telefonwerten.
  2. Stop token -Entfernt anonyme Telefonwerte wie konfiguriert.
  3. Phone -Parst eingegebene Telefonnummern mit unterschiedlichen Formaten aus verschiedenen Ländereinstellungen in ein einheitliches Format. Dieses Rezept kann so konfiguriert werden, dass Vorwahl und Landesvorwahl aus den Telefonnummern entfernt werden. Es kann auch eine bestimmte Anzahl von Ziffern in einer standardisierten Telefonnummer behalten.
  4. Parse token -Parst verarbeitete Feldwerte abhängig von bestimmten regulären Ausdrücken, die in den Ressourcen konfiguriert sind, in ein geeignetes internes Feld.
  5. Pick token -Wählt eine Untergruppe (oder alle) der Token als standardisierte Daten für Bucketing und Vergleich aus.

Der Telefonstandardisierer verwendet standardmäßig die folgenden Kartenressourcen:

  • map_phone_tokens_phone -Parst Telefonwerte auf der Basis von regulären Ausdrücken in ein internes Feld.

Der Telefonstandardisierer verwendet standardmäßig die folgenden Set-Ressourcen:

  • set_character_phone -Ersetzt alle Zeichen, die nicht alphanumerisch sind Ermöglicht die Angabe regulärer Ausdrücke.
  • set_phone_anon_phone -Entfernt anonyme Telefonwerte.
Standardisierer für Identifikation

Dieser Standardisierer wird verwendet, um Identifikationsattributwerte zu standardisieren. Sie enthält nacheinander die folgenden Rezepte:

  1. Map character -Konvertiert UNICODE-Eingabezeichen in äquivalente englische Alphabetzeichen. Definieren Sie optional die Map in den IBM Match 360 -Ressourcen.
  2. Upper case -Konvertiert die Eingabefeldwerte, um ihre Entsprechungen in Großbuchstaben zu verwenden.
  3. Stop character -Entfernt unerwünschte Eingabezeichen aus Identifikationswerten.
  4. Stop token -Entfernt anonyme Eingabewerte wie konfiguriert.
  5. Map token -Konvertiert Eingabetokenwerte in äquivalente Werte, wie in den IBM Match 360 -Ressourcen konfiguriert.
  6. Parse token -Parst verarbeitete Feldwerte abhängig von bestimmten regulären Ausdrücken, die in den Ressourcen konfiguriert sind, in ein geeignetes internes Feld.
  7. Pick token -Wählt eine Untergruppe (oder alle) der Token als standardisierte Daten für Bucketing und Vergleich aus.

Der Standardisierer für Identifikation verwendet standardmäßig die folgenden Mapressourcen:

  • map_character_general -Konvertiert UNICODE-Eingabezeichen in äquivalente englische Alphabetzeichen.
  • map_identifier_equi_identifier -Konvertiert Eingabetokenwerte in äquivalente Werte.
  • map_identifier_tokens_identification_number -Parst verarbeitete Feldwerte abhängig von bestimmten regulären Ausdrücken, die in den Ressourcen konfiguriert sind, in ein geeignetes internes Feld.

Der Standardisierer für die Identifikation verwendet standardmäßig die folgenden Set-Ressourcen:

  • set_character_identification_number -Entfernt nicht alphanumerische Eingabezeichen aus Identifikationswerten. Ermöglicht die Angabe regulärer Ausdrücke.
  • set_identifier_anonymous -Entfernt anonyme Identifikationswerte.
E-Mail-Standardisierer

Dieser Standardisierer wird verwendet, um E-Mail-Attributwerte zu standardisieren. Sie enthält nacheinander die folgenden Rezepte:

  1. Map character -Konvertiert UNICODE-Eingabezeichen in äquivalente englische Alphabetzeichen. Definieren Sie optional die Map in den IBM Match 360 -Ressourcen.
  2. Upper case -Konvertiert die Eingabefeldwerte, um ihre Entsprechungen in Großbuchstaben zu verwenden.
  3. Stop token -Entfernt anonyme Eingabewerte wie konfiguriert.
  4. Map token -Konvertiert Eingabetokenwerte in äquivalente Werte, wie in den IBM Match 360 -Ressourcen konfiguriert.
  5. Parse token -Parst verarbeitete Feldwerte abhängig von bestimmten regulären Ausdrücken, die in den Ressourcen konfiguriert sind, in ein geeignetes internes Feld.
  6. Pick token -Wählt eine Untergruppe (oder alle) der Token als standardisierte Daten für Bucketing und Vergleich aus.

Der E-Mail-Standardisierer verwendet standardmäßig die folgenden Mapressourcen:

  • map_character_general -Konvertiert UNICODE-Eingabezeichen in äquivalente englische Alphabetzeichen.
  • map_non_phone_equi_non_phone -Konvertiert Eingabetokenwerte in äquivalente Werte.
  • map_non_phone_tokens_non_phone -Parst das Eingabefeld email_id auf der Basis eines regulären Ausdrucks für die internen Felder email_local_part und email_domain.

Der E-Mail-Standardisierer verwendet standardmäßig die folgenden Set-Ressourcen:

  • set_non_phone_anon_non_phone -Entfernt anonyme E-Mail-Werte.
Standardisierer für Social Media

Dieser Standardisierer wird zur Standardisierung von Social-Media-Attributwerten verwendet. Sie enthält nacheinander die folgenden Rezepte:

  1. Map character -Konvertiert UNICODE-Eingabezeichen in äquivalente englische Alphabetzeichen. Definieren Sie optional die Map in den IBM Match 360 -Ressourcen.
  2. Upper case -Konvertiert die Eingabefeldwerte, um ihre Entsprechungen in Großbuchstaben zu verwenden.
  3. Stop token -Entfernt anonyme Eingabewerte wie konfiguriert.
  4. Map token -Konvertiert Eingabetokenwerte in äquivalente Werte, wie in den IBM Match 360 -Ressourcen konfiguriert.
  5. Parse token -Parst verarbeitete Feldwerte abhängig von bestimmten regulären Ausdrücken, die in den Ressourcen konfiguriert sind, in ein geeignetes internes Feld.
  6. Pick token -Wählt eine Untergruppe (oder alle) der Token als standardisierte Daten für Bucketing und Vergleich aus.

Der Standardisierer für Social Media verwendet standardmäßig die folgenden Mapressourcen:

  • map_character_general -Konvertiert UNICODE-Eingabezeichen in äquivalente englische Alphabetzeichen.
  • map_non_phone_equi_non_phone -Konvertiert Eingabetokenwerte in äquivalente Werte.
  • map_non_phone_tokens_non_phone -Parst das Eingabefeld social_media_handle für das interne Feld social_media_id basierend auf regulären Ausdrücken.

Der Standardisierer für Social Media verwendet standardmäßig die folgenden Set-Ressourcen:

  • set_non_phone_anon_non_phone -Entfernt anonyme social_media_id-Werte.

Entitätstypen (Bucketing)

In einem einzelnen Abgleichalgorithmus kann jeder Datensatztyp über mehrere Entitätstypdefinitionen (JSON-Objekte des Typs entity_type) verfügen. Beispiel: In einem Algorithmus, der für einen Datensatztyp 'Person' definiert ist, müssen Sie möglicherweise mehr als eine Entitätstypdefinition erstellen (z. B. die Entitäten 'Person', 'Haushalt', 'Standort' und andere).

Jeder Entitätstyp kann verwendet werden, um Datensätze auf verschiedene Arten abzugleichen und zu verknüpfen. Ein Entitätstyp definiert, wie Datensätze beim Abgleichen gruppiert und verglichen werden.

Jede Entitätstypdefinition (entity_type) im Abgleichalgorithmus hat mehrere JSON-Elemente:

  • clerical_review_threshold - Datensätze, deren Vergleichsscore unter dem Schwellenwert für manuelle Überprüfung liegt, werden als Nichtübereinstimmungen eingestuft.

  • auto_link_threshold - Datensätze, deren Vergleichsscore über dem Schwellenwert für automatische Verknüpfung (autolink) liegt, werden als starke Übereinstimmungen eingestuft und automatisch abgeglichen.

  • bucket_generators - Dieser Abschnitt enthält die Definition der für einen Entitätstyp konfigurierten Bucketgeneratoren. Es gibt zwei Typen von Bucketgeneratoren: Buckets und Bucketgruppen.

    • Buckets sind Gruppierungsklassen für ein einzelnes Attribut. Jede bucket-Definition enthält vier Elemente:

      • label - Eine Bezeichnung, die den Bucketgenerator identifiziert.
      • maximum_bucket_size - Ein Wert, der die Größe für umfangreiche Buckets definiert. Jeder Bucket-Hash mit einer Bucketgröße, die diesen Wert überschreitet, wird bei der Auswahl der Kandidaten für den Abgleich nicht berücksichtigt.
      • inputs - Für Buckets enthält die Liste inputs nur ein einzelnes Element, das ein JSON-Objekt ist. Dieses JSON-Objekt enthält die beiden Elemente fields und attributes:
        • fields - Die Liste der Felder, die für das Bucketing verwendet werden sollen.
        • attributes - Die Liste der Attribute, die für das Bucketing verwendet werden sollen.
      • bucket_recipe -Eine Bucketkonzeptliste definiert die Schritte, die der Bucketgenerator während des Bucketing-Prozesses ausführen muss. Jede bucket_recipe-Liste enthält eine Reihe von Unterelementen:
        • label - Eine Bezeichnung, die das Bucketkonzeptelement identifiziert.
        • method - Die verwendete interne Methode. Dieses Element dient nur zu Referenzzwecken und darf nicht bearbeitet werden.
        • inputs -Ein einzelnes Element der Liste inputs , das eine Ebene höher definiert ist.
        • fields - Eine Liste der Felder, die für dieses Bucket verwendet werden sollen. Dies ist im Allgemeinen eine Untergruppe aller Felder, die in der Liste inputs eine Ebene höher definiert sind.
        • min_tokens - Die Mindestanzahl der Tokens, die verwendet werden sollen, wenn das Konzept einen Bucket-Hash bildet.
        • max_tokens - Die maximale Anzahl der Tokens, die zusammen verwendet werden sollen, wenn das Konzept einen Bucket-Hash bildet.
        • count - Ein Grenzwert für die Anzahl der Bucket-Hash-Elemente für einen einzelnen Datensatz, die aus einem Bucketgenerator generiert werden. Wenn ein Datensatz zahlreiche Bucket-Hash-Elemente generiert, wird nur die von diesem Element festgelegte Hash-Anzahl berücksichtigt.
        • bucket_group - Die Folgenummer für eine Bucketgruppe, die einen Bucket-Hash erzeugt. Zwischenschritten oder -konzepten wird keine Folgenummer zugewiesen.
        • order - Gibt an, ob die Tokens in lexikografischer Reihenfolge sortiert werden, wenn mehrere Tokens zu einem Bucket-Hash kombiniert werden.
        • maximum_bucket_size - Ein Wert, der die Größe für umfangreiche Buckets definiert. Dieses Element entspricht dem auf der Ebene des Bucketgenerators definierten Element. Durch das Vorhandensein dieses Elements auch auf der Bucketkonzeptebene können Sie umfangreiche einzelne Buckets differenzierter steuern.

    • Bucketgruppen ermöglichen das Bucketing für mehr als ein Attribut. Jede bucket_group-Definition enthält fünf Elemente:

      • label - Eine Bezeichnung, die den Bucketgenerator identifiziert.
      • maximum_bucket_size - Ein Wert, der die Größe für umfangreiche Buckets definiert. Jeder Bucket-Hash mit einer Bucketgröße, die diesen Wert überschreitet, wird bei der Auswahl der Kandidaten für den Abgleich nicht berücksichtigt.
      • inputs - Die Liste inputs für Bucketgruppen enthält mehr als ein JSON-Objektelement. Die JSON-Objekte verfügen jeweils die beiden Elemente fields und attributes:
        • fields - Die Liste der Felder, die für das Bucketing verwendet werden sollen.
        • attributes - Die Liste der Attribute, die für das Bucketing verwendet werden sollen.
      • bucket_recipe -Eine Bucketkonzeptliste definiert die Schritte, die der Bucketgenerator während des Bucketing-Prozesses ausführen muss. Jede bucket_recipe-Liste enthält eine Reihe von Unterelementen:
        • label - Eine Bezeichnung, die das Bucketkonzeptelement identifiziert.
        • method - Die verwendete interne Methode. Dieses Element dient nur zu Referenzzwecken und darf nicht bearbeitet werden.
        • inputs -Ein einzelnes Element der Liste inputs , das eine Ebene höher definiert ist.
        • fields - Eine Liste der Felder, die für dieses Bucket verwendet werden sollen. Dies ist im Allgemeinen eine Untergruppe aller Felder, die in der inputs -Liste eine Ebene höher definiert sind.
        • min_tokens - Die Mindestanzahl der Tokens, die verwendet werden sollen, wenn das Konzept einen Bucket-Hash bildet.
        • max_tokens - Die maximale Anzahl der Tokens, die zusammen verwendet werden sollen, wenn das Konzept einen Bucket-Hash bildet.
        • count - Ein Grenzwert für die Anzahl der Bucket-Hash-Elemente für einen einzelnen Datensatz, die aus einem Bucketgenerator generiert werden. Wenn ein Datensatz zahlreiche Bucket-Hash-Elemente generiert, wird nur die von diesem Element festgelegte Hash-Anzahl berücksichtigt.
        • bucket_group - Die Folgenummer für eine Bucketgruppe, die einen Bucket-Hash erzeugt. Zwischenschritten oder -konzepten wird keine Folgenummer zugewiesen.
        • order - Gibt an, ob die Tokens in lexikografischer Reihenfolge sortiert werden, wenn mehrere Tokens zu einem Bucket-Hash kombiniert werden.
        • maximum_bucket_size - Ein Wert, der die Größe für umfangreiche Buckets definiert. Dieses Element entspricht dem Element, das auf der Ebene des Bucketgenerators definiert ist. Durch die Möglichkeit, dieses Element auf der Ebene des Bucketkonzepts zu definieren, können Sie umfangreiche einzelne Buckets differenzierter steuern.
        • set_resource - Der Name einer Ressource des Typs set, die für ein Bucketkonzept verwendet wird.
        • map_resource - Der Name einer Ressource des Typs map, die für ein Bucketkonzept verwendet wird.
        • output_fields - Wenn das Konzept nach dem Anwenden der Bucketing-Funktionen auf die Eingabefelder neue Felder erzeugt, enthält dieses Element eine Liste mit den Namen der generierten Felder.
      • bucket_group_recipe - Ein Abschnitt in einem Bucketgruppenkonzept wird normalerweise zum Definieren von Buckets verwendet, die aus mehr als einem Attribut bestehen. Jedes Element in einer Liste bucket_group_recipe ist ein JSON-Objekt, in dem das Konstrukt für eine einzelne Bucketgruppe definiert wird.
        • Die Liste inputs in bucket_group_recipe enthält mehr als ein Element, d. h., sie verweist auf mehr als ein Attribut, das im inputs -Array eine Ebene höher definiert ist.
        • Das Element fields ist eine Auflistung der Listen. Jede innere Feldliste ist der entsprechenden Liste attributes zugeordnet.
        • Die Listen min_tokens und max_tokens enthalten mehrere Elemente. Dabei entspricht jedes dieser Elemente der jeweiligen Liste attributes.
      Hinweis:

      In einigen Definitionen für Bucketing-Rezepte gibt es eine Eigenschaft mit dem Namen search_only. Der Standardwert ist false. Wenn diese Eigenschaft auf truegesetzt ist, gibt sie an, dass ein Bucket oder eine Bucketgruppe nur für Szenarios mit probabilistischer Suche und nicht für Szenarios mit Entitätsauflösung (Abgleich) verwendet wird.

  • compare_methods - Definitionen der für einen Entitätstyp konfigurierten Vergleichsmethoden. Jedes JSON-Objekt compare_methods besteht aus Definitionen für verschiedene compare-Methoden. Der Abgleichalgorithmus addiert die Scores aus jeder compare-Methodendefinition, um den finalen Vergleichsscore zu berechnen. Das JSON-Objekt für jede compare-Methode enthält drei Elemente:

    • label - Eine Bezeichnung, die die compare-Methode angibt.
    • methods - Eine Liste der Vergleichsoperatoren, die eine Vergleichsgruppe bilden. Jedes Element in diesem Array stellt einen Vergleichsoperator dar, der für einen Abgleichattributtyp bestimmt ist. Der Abgleichalgorithmus stuft den Maximalwert der Scores aus allen Vergleichsoperatoren in einer Liste methods als den finalen Score dieser Vergleichsgruppe ein. Jede Vergleichsoperatordefinition enthält zwei Elemente:
      • inputs -Für Vergleichsoperatoren enthält die Liste inputs nur ein einzelnes Element, das ein JSON-Objekt ist. Dieses JSON-Objekt enthält die beiden Elemente fields und attributes:
        • fields - Die Liste der Felder, die für den Vergleich verwendet werden sollen.
        • attributes - Die Liste der Attribute, die für den Vergleich verwendet werden sollen.
      • compare_recipe - Diese Liste wird hauptsächlich zum Definieren der Vergleichsschritte verwendet. Dieses Array enthält in der Regel nur ein einzelnes JSON-Element, das nur einen einzigen zum Ausführen des Vergleichs darstellt. Dieser Schritt besteht aus fünf Elementen:
        • label - Eine Bezeichnung, die den Vergleichsschritt identifiziert.
        • method - Die verwendete interne Methode. Dieses Element dient nur zu Referenzzwecken und darf nicht bearbeitet werden.
        • inputs -Ein einzelnes Element der Liste inputs , das eine Ebene höher definiert ist.
        • fields -Die Felder, die für diesen Vergleich verwendet werden sollen, aus allen Feldern, die in der inputs -Liste eine Ebene höher definiert sind.
        • comparison_resource - Der Name einer anpassbaren Vergleichsressource, die für diesen Vergleichsschritt verwendet wird.
    • weights - Jeder von einem Vergleichsoperator durchgeführte Vergleich, ergibt einen Zahlenwert von 0 bis 10. Diese Zahl wird als Distanz- oder Unähnlichkeitsmaß bezeichnet. Der Distanzwert 0 bedeutet, dass die verglichenen Werte genau gleich sind. Der Distanzwert 10 bedeutet, dass sie vollständig verschieden sind. Entsprechend den 11 verschiedenen Werten (0 - 10), werden für jeden Vergleichsoperator 11 Gewichtungen definiert. Nach dem Berechnen des Distanzwerts ermittelt die Vergleichsmethode den entsprechenden Gewichtungswert aus der Liste der Gewichtungen und damit den Gesamtvergleichsscore. Datenentwickler können die Gewichtungen nach Bedarf anpassen, basierend auf Datenqualität, Verteilung oder anderen Faktoren.

  • record_filter -Das Datensatzfilterelement ermöglicht es der Abgleichsfunktion, Datensätze für den Abgleich auf der Basis ihrer Entitätstypen auszuwählen. Jede Datensatzfilterdefinition enthält ein Element:

    • criteria -Schließt Datensätze auf der Basis bestimmter Bedingungen von der Berücksichtigung ein oder aus. Dieses Element enthält ein JSON-Objekt mit einem Schlüssel/Wert-Paar.

      Der Schlüssel des JSON-Objekts criteria ist ein Attributname. Es kann sich um eine der folgenden handeln:

      • Das Systemattribut record_source .
      • Ein benutzerdefiniertes angepasstes Attribut eines einfachen Attributtyps (Zeichenfolge)

    Der Wert des JSON-Objekts criteria ist ein weiteres JSON-Objekt, das ein Element enthält. Folgende Elemente sind möglich:

    • allowed -Ein Array von Zeichenfolgewerten. Datensätze, die einen dieser Werte enthalten, werden beim Abgleich berücksichtigt.
    • disallowed -Ein Array von Zeichenfolgewerten. Datensätze, die einen dieser Werte enthalten, werden beim Abgleich nicht berücksichtigt.

  • source_level_thresholds -Schwellenwerte auf Quellenebene ermöglichen es Ihnen, Schwellenwerte für automatische und manuelle Überprüfung auf der Basis von Quelle zu Quelle zu definieren. Schwellenwerte auf Quellenebene überschreiben die globalen Standardschwellenwerte. Jede Schwellenwertkonfiguration auf Quellenebene enthält eine Sammlung von Quellen mit optionalen quellenspezifischen Standardschwellenwerten oder eine Sammlung von Quellen-Quellen-Schwellenwertpaaren, mit denen Sie unterschiedliche Schwellenwerte für jede Quelle definieren können. Weitere Informationen finden Sie unter Quellenspezifische übereinstimmende Schwellenwerte konfigurieren im Abschnitt Erweiterte Abgleichalgorithmusoptimierung .

Bucketing-Ressourcen

Die Bucketing-Definitionen verwenden standardmäßig die folgenden Mapressourcen:

  • person_map_name_nickname -Generiert Kurznamen oder alternative Namen für die Eingabe eines bestimmten Personennamens
  • org_map_name_cnick_name -Generiert Kurznamen oder alternative Namen für die Eingabe eines bestimmten Organisationsnamens.

Die Bucketing-Definitionen verwenden standardmäßig die folgenden Set-Ressourcen:

  • person_set_name_bkt_anon -Entfernt anonyme Personennamenswerte.
  • org_set_name_acname -Entfernt anonyme Organisationsnamen.

Vergleichsfunktionen

Vergleichsfunktionen, manchmal auch als Vergleichsoperatorenbezeichnet, sind eine der Schlüsselkomponenten des Abgleichalgorithmus. Vergleichsfunktionen werden von der Abgleichengine verwendet, um Datensatzdaten während des Abgleichprozesses zu vergleichen. Der Datensatzabgleich umfasst im Wesentlichen den Vergleich verschiedener Attributtypen zwischen den Daten verschiedener Datensätze.

Für viele der häufig verwendeten Attributtypen in Personen-, Organisations-und Standortdomänen enthält die IBM Match 360 -Abgleichsengine vorkonfigurierte Vergleichsmethoden.

In IBM Match 360verwenden Vergleichsfunktionen einen Ansatz zum Vergleich, der als Featurevektorenbezeichnet wird. Es gibt verschiedene anpassbare Featuredefinitionen in IBM Match 360 , die für verschiedene Vergleichsfunktionen verwendet werden. Jeder Vergleich ergibt ein Distanzmaß (einen Vektor), das zeigt, wie unterschiedlich zwei gegebene Attributwerte sind.

Im Abgleichalgorithmus erhält jeder diskrete Abstandswert eine Gewichtung, die bestimmt, wie stark dieser Wert berücksichtigt werden soll. Die Gewichtung wird mit der Entfernung kombiniert, um eine Vergleichsbewertung zu erzeugen. Der Abgleichalgorithmus addiert alle Vergleichsscores, um eine endgültige Vergleichsbewertung für den Gesamtvergleich von Datensatz zu Datensatz zu erhalten.

Informationen zu Features

Ein Feature stellt die Feindetails einer Vergleichsfunktion dar. Verschiedene Typen von Attributen verwenden unterschiedliche Typen von Ähnlichkeitsprüfungen, d. h., ihre Funktionen variieren ebenfalls.

Funktionsdefinitionen geben die Typen interner Funktionen vor, die für die einzelnen Vergleichsfunktionen verwendet werden. Beispiele für interne Funktionen sind exakte Übereinstimmung, Bearbeitungsabstand, Kurzname, phonetische Entsprechung oder anfängliche Übereinstimmung.

Vergleichsressourcen

Jede Vergleichsmethode enthält Ressourcen, die die Details ihrer internen Vergleichsoperationen enthalten.

Jeder der Standardvergleichstypen verfügt über eigene Ressourcen. Details zu den zugehörigen Ressourcen finden Sie in den einzelnen Vergleichstypen.

Für Vergleiche für angepasste Attributtypen mit dem übereinstimmenden Typ genericenthält die generische Vergleichsmethode die folgenden Ressourcen:

  • compare_spec_generic -Im generierten Algorithmus ist das Namensformat dieser Ressource recordType_entityType_compare_spec_generic.

Personennamensvergleiche

Unterschiedliche Felder in einem Personennamensattribut werden unterschiedlich behandelt. Für Felder wie Präfix, Suffix und Generierungswerte wird die Genauigkeit oder Nichtübereinstimmung geprüft. Andere Felder wie Vorname, Nachname und zweiter Vorname verwenden in erster Linie die folgenden Funktionen:

  • Exakte Übereinstimmung
  • Kurznamenübereinstimmung
  • Bearbeitungsabstand
  • Übereinstimmung mit Initialen
  • Phonetische Übereinstimmung
  • Falsche Platzierung von Tokens
  • Zusätzliche Token
  • Fehlende Werte

Die Vergleichsmethode für Personennamen umfasst die folgenden Ressourcen:

  • person_compare_spec_name -Im generierten Algorithmus ist das Namensformat dieser Ressource recordType_entityType_ compare_spec_name. Beispiel: person_person_entity_compare_spec_name.

Organisationsnamensvergleiche

Für Organisationsnamen gibt es typischerweise ein Feld, das den gesamten Geschäftsnamen enthält. Dieses Feld wird hauptsächlich mit den folgenden Merkmalen verglichen:

  • Exakte Übereinstimmung
  • Kurznamenübereinstimmung
  • Bearbeitungsabstand
  • Übereinstimmung mit Initialen
  • Phonetische Übereinstimmung
  • Falsche Platzierung von Tokens
  • Zusätzliche Token
  • Fehlende Werte

Bei Organisationsnamen werden die Akronyme und Kurznamen ebenfalls auf Genauigkeit verglichen.

Die Vergleichsmethode für Organisationsnamen umfasst die folgenden Ressourcen:

  • org_compare_spec_name -Im generierten Algorithmus ist das Namensformat dieser Ressource recordType_entityType_ compare_spec_name.

Datumsvergleiche

Für Datumsangaben gibt es normalerweise drei zu vergleichende Felder: Tag, Monat und Jahr.

Das Feld year wird mithilfe der folgenden Funktionen verglichen:

  • Genauigkeit
  • Bearbeitungsabstand
  • Nicht übereinstimmend
  • Nicht vorhanden

Die Felder day und month werden mithilfe der folgenden Funktionen verglichen:

  • Genauigkeit
  • Nicht übereinstimmend
  • Nicht vorhanden

Der Datumsvergleichsoperator prüft auch, ob die Felder day und month aufgrund von Unterschieden bei der Ländereinstellung im Datumsformat transponiert wurden.

Die Datumsvergleichsmethode umfasst die folgenden Ressourcen:

  • compare_spec_date -Im generierten Algorithmus ist das Namensformat dieser Ressource recordType_entityType_ compare_spec_date.

Geschlechtervergleiche

Das Attribut "gender" wird mithilfe der folgenden Funktionen verglichen:

  • Genauigkeit
  • Nicht übereinstimmend

Die Methode zum Vergleich des Geschlechts umfasst die folgenden Ressourcen:

  • compare_spec_gender -Im generierten Algorithmus ist das Namensformat dieser Ressource recordType_entityType_ compare_spec_gender.

Adressvergleiche

Unterschiedliche Felder in einem Adressattribut werden unterschiedlich behandelt.

Felder wie "country", "city", "province" und "subdivision" werden mithilfe der folgenden Funktionen verglichen:

  • Genauigkeit
  • Äquivalenz
  • Bearbeitungsabstand
  • Nicht übereinstimmend
  • Nicht vorhanden

Postleitzahlfelder werden mithilfe der folgenden Funktionen verglichen:

  • Genauigkeit
  • Bearbeitungsabstand
  • Nicht übereinstimmend
  • Nicht vorhanden

Felder wie Straßennummer, Straßenname, Straßentyp, Einheitennummer und Richtung werden mithilfe der folgenden Funktionen verglichen:

  • Genauigkeit
  • Äquivalenz
  • Übereinstimmung mit Initialen
  • Bearbeitungsabstand
  • Nicht übereinstimmend
  • Falsche Platzierung von Tokens
  • Nicht vorhanden

Die Adressvergleichsmethode umfasst die folgenden Ressourcen:

  • compare_spec_address -Im generierten Algorithmus ist das Namensformat dieser Ressource recordType_entityType_ compare_spec_address.

Telefonvergleiche

Telefonnummernattribute werden mithilfe der folgenden Funktionen verglichen:

  • Exakte Übereinstimmung
  • Bearbeitungsabstand
  • Nicht übereinstimmend

Die Telefonvergleichsmethode enthält die folgenden Ressourcen:

  • compare_spec_phone -Im generierten Algorithmus wäre das Namensformat dieser Ressource recordType_entityType_ compare_spec_phone.

Kennungsvergleiche

Identifikationsnummernattribute werden mithilfe der folgenden Funktionen verglichen:

  • Exakte Übereinstimmung
  • Bearbeitungsabstand
  • Nicht übereinstimmend

Die ID-Vergleichsmethode enthält die folgenden Ressourcen:

  • compare_spec_identifier -Im generierten Algorithmus ist das Namensformat dieser Ressource recordType_entityType_ compare_spec_identifier.

E-Mail-Vergleiche

E-Mail-Attribute bestehen aus zwei Teilen: der eindeutigen ID (vor dem Symbol @) und der E-Mail-Domäne (nach dem Symbol @). Sowohl die ID-als auch die Domänenkomponenten werden separat mit den folgenden Funktionen verglichen:

  • Exakte Übereinstimmung
  • Bearbeitungsabstand
  • Nicht übereinstimmend

Das Ergebnis der beiden Vergleiche wird gewichtet kombiniert, um einen Gesamtvergleichsscore zu erhalten.

Die E-Mail-Vergleichsmethode umfasst die folgenden Ressourcen:

  • compare_spec_email -Im generierten Algorithmus ist das Namensformat dieser Ressource recordType_entityType_ compare_spec_email.

Social-Media-Vergleiche

Social-Media-Handle-Attribute werden mithilfe der folgenden Funktionen verglichen:

  • Exakte Übereinstimmung
  • Bearbeitungsabstand
  • Nicht übereinstimmend

Die Social-Media-Vergleichsmethode umfasst die folgenden Ressourcen:

  • compare_spec_non_phone -Im generierten Algorithmus ist das Namensformat dieser Ressource recordType_entityType_ compare_spec_non_phone.

Bearbeitungsabstand

Die Matching-Engine von IBM Match 360 berechnet den Bearbeitungsabstand als eine der internen Funktionen beim Vergleich und Abgleich verschiedener Attribute. Der Bearbeitungsabstand ist ein Maß dafür, wie unähnlich zwei Zeichenfolgen voneinander sind. Beim Berechnen dieses Werts wird ermittelt, wie viele Änderungen erforderlich sind, um eine Zeichenfolge in die andere umzuwandeln.

Es gibt verschiedene Verfahren, den Bearbeitungsabstand mithilfe verschiedener Gruppen von Zeichenfolgeoperationen zu definieren. In IBM Match 360 wird eine Standardfunktion für den Bearbeitungsabstand verwendet, die in der Literatur öffentlich zugänglich ist. Alternativ können Sie eine spezielle IBM Match 360-Funktion für den Bearbeitungsabstand verwenden.

  • Standardfunktion für den Bearbeitungsabstand ermöglicht eine bessere Leistung der Matching-Engine. Darum wird diese Standardvergleichskonfiguration für alle Attribute verwendet (mit Ausnahme des Attributtyps für Telefonnummern).

  • Spezialisierte Funktion für den Bearbeitungsabstand wurde für Anwendungsfälle entwickelt, die eine besonders hohe Genauigkeit erfordern. Diese Option berücksichtigt Schreibfehler oder ähnlich aussehende Zeichen wie 8 und B, 0 und O, 5 und S oder 1 und I. Wenn bei zwei verglichenen Werten eine Abweichung durch ähnlich aussehende Zeichen auftritt, ist das zugewiesene Unähnlichkeitsmaß kleiner als bei einer Standardfunktion für den Bearbeitungsabstand. Abweichungen dieser Art werden von der spezialisierten Funktion weniger stark abgewertet.

    Wichtig: Die spezialisierte Funktion für den Bearbeitungsabstand umfasst einige komplexe Berechnungen. Dies hat zur Folge, dass sich die Verwendung dieser Option beim Abgleichsprozess auf die Systemleistung auswirkt.

Informationen zum Anpassen Ihres Abgleichsalgorithmus, einschließlich der Verwendung der API zum Anpassen der Bearbeitungsdistanz, finden Sie unter Abgleichsalgorithmus anpassen und stärken.

Weitere Informationen

Übergeordnetes Thema: Stammdaten verwalten