0 / 0
Retourner à la version anglaise de la documentation
Algorithmes de correspondance dans IBM Match 360
Dernière mise à jour : 22 nov. 2024
Algorithmes de correspondance dans IBM Match 360

IBM Match 360 utilise des algorithmes de correspondance pour résoudre les enregistrements de données en entités de données de base. Les ingénieurs de données peuvent définir différents algorithmes de correspondance pour chaque type d'entité dans leurs données. Les algorithmes de correspondance peuvent ensuite analyser les données pour évaluer et comparer des enregistrements, puis collecter des enregistrements correspondants dans des entités.

Il existe deux raisons communes pour faire correspondre vos données :

  • Pour la déduplication d'enregistrement et de résolution d'entité, le processus de correspondance analyse vos données pour déterminer si des enregistrements en double existent dans vos données. Les enregistrements dupliqués suspects sont fusionnés en entités de données maître afin d'établir une vue unique, sécurisée et à 360 degrés de vos données.
  • Pour créer d'autres types d'associations d'entités, le processus de mise en correspondance analyse vos données afin de collecter des enregistrements dans des entités qui représentent différents types de regroupement, par exemple un foyer.

Regardez la vidéo suivante pour savoir comment utiliser IBM Match 360 afin de configurer un algorithme de correspondance pour un modèle de données personnalisé.

Cette vidéo fournit une méthode visuelle pour apprendre les concepts et les tâches de cette documentation.

Dans cette rubrique :

Mise en correspondance pour créer plusieurs types d'entité

Les algorithmes de correspondance IBM Match 360 sont pilotés par le type d'entité des données associées. Vous pouvez définir plusieurs types d'entité pour chaque type d'enregistrement dans le modèle de données. Pour chaque type d'entité, configurez et optimisez son algorithme de correspondance correspondant pour vous assurer que IBM Match 360 crée des entités qui répondent aux exigences de votre organisation.

Un seul enregistrement peut faire partie de plusieurs entités distinctes. Si votre modèle de données inclut plusieurs types d'entité, vous pouvez exécuter différents types de correspondance dans le même fichier. Par exemple, considérons un fichier qui inclut des enregistrements de personne de l'ensemble de votre entreprise. Si le type d'enregistrement Personne inclut des définitions pour un type d'entité personne et un type d'entité Foyer, vous pouvez exécuter l'algorithme de correspondance de personne pour la résolution d'entité et le dédoublonnage, et exécuter également l'algorithme de correspondance des foyers pour créer des entités qui appartiennent à un même foyer.

Le processus de correspondance

Le moteur de mise en correspondance passe par un processus défini pour faire correspondre les enregistrements en entités. Le processus de jumelage comprend trois étapes principales :

  1. standardisation. Au cours de cette étape, l'algorithme normalise le format des données de sorte qu'elles puissent être traitées par le moteur correspondant.

  2. Compartimentage. L'algorithme trie les données en différentes catégories ou " compartiments " pour qu'il puisse comparer des informations similaires à celles de l'information.

  3. Comparaison. L'algorithme compare les données pour déterminer un score final de comparaison. L'algorithme utilise ensuite le score de comparaison pour déterminer si les enregistrements ont une correspondance.

Chacune de ces étapes est définie et configurée par l'algorithme de correspondance.

Règles de résilience

Vous pouvez utiliser l'API IBM Match 360 pour configurer des règles de résilience qui limitent la façon dont l'algorithme de mise en correspondance réagit aux modifications des données d'enregistrement.

En l'absence de règles de résilience, un certain nombre de changements de liens entre entités peuvent se produire lorsqu'un enregistrement de données de base est ajouté, mis à jour ou supprimé :

  • Si un nouvel enregistrement est ajouté, il peut :

    • Rejoindre une entité existante.
    • Faire en sorte que deux ou plusieurs entités existantes se rejoignent en jouant le rôle d'un document de liaison.
    • Former une nouvelle entité unique.

  • Si un enregistrement est mis à jour, il peut l'être :

    • N'appartient plus à son entité actuelle et devient une nouvelle entité unique.
    • Ne plus appartenir à son entité actuelle et rejoindre une autre entité existante.
    • Provoquer l'éclatement de l'entité actuelle en plusieurs entités.
    • Permet à d'autres entités de rejoindre l'entité existante en jouant le rôle d'un enregistrement collé.
    • Ne pas modifier la composition de l'entité.

  • Si un enregistrement est supprimé, il peut :

    • Entraîne la suppression de son entité unique.
    • Provoquer la scission de l'entité actuelle.

En définissant des règles de résilience, les ingénieurs de données peuvent configurer la façon dont le moteur de correspondance IBM Match 360 réagit à chacun de ces scénarios. Le moteur de correspondance contrôle son comportement de liaison pour s'aligner sur les règles de résilience que vous avez configurées. En configurant des règles de résilience, vous pouvez limiter les fusions et les scissions d'entités, ce qui vous permet d'obtenir une composition d'entités plus stable.

Définir des règles de résilience en utilisant l'API " resiliency_rules Si une règle donnée est définie sur " FALSE, le scénario de liaison d'entités correspondant n'effectuera pas les modifications habituelles de liaison d'entités.

Pour obtenir l'ensemble actuel de règles de résilience, exécutez la commande API suivante :

GET /mdm/v1/resiliency_rules

Pour mettre à jour les règles de résilience, exécutez la commande API suivante avec une charge utile mise à jour :

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": {
   }
 }
}

Composants de l'algorithme de correspondance

Trois types principaux de composants définissent un algorithme de correspondance IBM Match 360 :

programmes de standardisation

Comme le nom l'indique, les normalisateurs définissent la façon dont les données sont normalisées. La normalisation permet à l'algorithme de correspondance de convertir les valeurs des différents attributs en une représentation normalisée qui peut être traitée par un moteur de correspondance.

L'algorithme de correspondance utilise plusieurs programmes de standardisation. Chaque programme de standardisation est adapté pour traiter des types d'attributs spécifiques trouvés dans les données d'enregistrement.

Les programmes de standardisation sont définis par des objets JSON. Chaque définition d'objet JSON de programme de standardisation contient trois éléments :

  • label - Un libellé qui identifie ce programme de standardisation.

  • inputs -La liste inputs comporte un élément, qui est un objet JSON. Cet objet JSON comporte deux éléments : fields et attributes:

    • fields - La liste des zones à utiliser pour la standardisation.
    • attributes - La liste des attributs à utiliser pour la standardisation .

  • standardizer_recipe - Une liste des objets JSON dans lesquels chaque objet représente une étape à exécuter pendant le processus du programme de standardisation associé. Chaque objet de la liste standardizer_recipe se compose de quatre éléments principaux :

    • label - Un libellé qui identifie cette étape dans la recette du programme de standardisation.
    • method - La méthode interne utilisée. Cet élément est juste pour référence et ne doit pas être modifié.
    • inputs -Elément unique de la liste inputs défini un niveau supérieur.
    • fields - Une liste des zones à utiliser pour cette étape. Il s'agit généralement d'un sous-ensemble de toutes les zones définies dans la liste inputs de niveau supérieur. Toutes les étapes ne doivent pas traiter toutes les zones inputs.
    • set_resource - Le nom d'une ressource personnalisable de type set utilisée pour cette étape.
    • map_resource - Le nom d'une ressource personnalisable de type map utilisée pour cette étape.

    En fonction du comportement d'une étape, il peut y avoir plus d'éléments de configuration requis dans l'objet JSON correspondant.

Normalisateurs préconfigurés

Les normalisateurs suivants sont prêts à être utilisés dans IBM Match 360. Les normalisateurs préconfigurés sont également personnalisables.

Programme de normalisation des noms de personne

Ce programme de normalisation est utilisé pour normaliser les valeurs d'attribut de nom de personne. Il contient les recettes suivantes, dans l'ordre:

  1. Upper case -Convertit les valeurs de zone d'entrée pour utiliser leurs équivalents en majuscules.
  2. Map character -Convertit les caractères d'entrée UNICODE en caractères alphabétiques anglais équivalents. Vous pouvez éventuellement définir la mappe dans les ressources IBM Match 360 .
  3. Tokenizer -Permet de segmenter la valeur de la zone d'entrée en plusieurs jetons, en fonction de la liste de délimiteurs définie.
  4. Parse token -Analyse les valeurs de zone d'entrée dans différents jetons, en fonction des valeurs prédéfinies dans les ressources IBM Match 360 . Par exemple, vous pouvez utiliser cette recette pour analyser les valeurs de suffixe, de préfixe et de génération dans les zones appropriées.
  5. Length -supprime les jetons qui se trouvent en dehors d'une plage de longueurs donnée. Les valeurs minimale et maximale sont définies dans les ressources IBM Match 360 .
  6. Stop token -Supprime les valeurs d'entrée anonymes, comme configuré.
  7. Pick token -Sélectionne un sous-ensemble (ou la totalité) des jetons comme données standardisées à utiliser dans la création de tickets et la comparaison.

Le programme de normalisation des noms de personne utilise par défaut les ressources de mappe suivantes:

  • map_character_general -Convertit les caractères d'entrée UNICODE en caractères alphabétiques anglais équivalents.
  • person_map_name_alignments -Analyse les valeurs de suffixe, de préfixe et de génération dans les zones appropriées.

Le programme de normalisation des noms de personne utilise par défaut les ressources d'ensemble suivantes:

  • person_set_name_aname -Supprime les valeurs de nom de personne anonyme.
Programme de normalisation des noms d'organisation

Ce programme de normalisation est utilisé pour normaliser les valeurs d'attribut de nom d'organisation. Il contient les recettes suivantes, dans l'ordre:

  1. Upper case -Convertit les valeurs de zone d'entrée pour utiliser leurs équivalents en majuscules.
  2. Map character -Convertit les caractères d'entrée UNICODE en caractères alphabétiques anglais équivalents. Vous pouvez éventuellement définir la mappe dans les ressources IBM Match 360 .
  3. Stop character -Supprime les caractères d'entrée non souhaités des valeurs de nom.
  4. Map token -Génère des pseudonymes ou d'autres noms pour l'entrée donnée et stocke les informations dans une nouvelle zone interne distincte.
  5. Tokenizer -Permet de segmenter la valeur de la zone d'entrée en plusieurs jetons, en fonction de la liste de délimiteurs définie.
  6. Stop token -Supprime les valeurs d'entrée anonymes, comme configuré.
  7. Acronym -Génère un acronyme pour le nom d'organisation donné et stocke les informations dans une nouvelle zone interne distincte. Cette valeur d'acronyme est utilisée lors de la comparaison pour gérer les noms abrégés.
  8. Pick token -Sélectionne un sous-ensemble (ou la totalité) des jetons comme données standardisées à utiliser dans la création de tickets et la comparaison.

Le programme de normalisation des noms d'organisation utilise par défaut les ressources de mappe suivantes:

  • map_character_general -Convertit les caractères d'entrée UNICODE en caractères alphabétiques anglais équivalents.
  • org_map_name_cnick_name -Génère des pseudonymes ou d'autres noms pour l'entrée indiquée.

Le programme de normalisation des noms d'organisation utilise par défaut les ressources d'ensemble suivantes:

  • org_set_name_aname -Supprime les valeurs de nom d'organisation anonyme.
Programme de standardisation de date

Ce programme de normalisation permet de normaliser les valeurs d'attribut de date. Il prend en charge de nombreux formats de date différents et contient les recettes suivantes, dans l'ordre:

  1. Map character -Convertit les barres obliques (/) en tirets (-).
  2. Date function -Convertit les entrées de date dans différents formats dans un format standardisé.
  3. Stop token -Supprime les valeurs de date anonymes, comme configuré.
  4. Parse token -Analyse les valeurs de zone d'entrée dans différents jetons, en fonction de certaines expressions régulières. Par exemple, vous pouvez utiliser cette recette pour analyser une entrée de date complète dans des jetons de jour, de mois et d'année.
  5. Pick token -Sélectionne un sous-ensemble (ou la totalité) des jetons comme données standardisées à utiliser dans la création de tickets et la comparaison.

Le programme de standardisation de date utilise par défaut les ressources de mappe suivantes:

  • map_character_date_separators-Convertit la barre oblique (/) ou tout autre caractère de séparation en tirets (-).
  • map_date_tokens_year_month_day -Analyse la valeur de date d'entrée dans des zones internes, à savoir birth_year, birth_month et birth_day, en fonction d'expressions régulières.

Le programme de standardisation de date utilise par défaut les ressources d'ensemble suivantes:

  • set_date_date -Supprime les valeurs de date anonymes.
Programme de normalisation des genres

Ce programme de normalisation est utilisé pour normaliser les valeurs d'attribut de genre. Il contient les recettes suivantes, dans l'ordre:

  1. Map character -Convertit les caractères d'entrée UNICODE en caractères alphabétiques anglais équivalents. Vous pouvez éventuellement définir la mappe dans les ressources IBM Match 360 .
  2. Upper case -Convertit les valeurs de zone d'entrée pour utiliser leurs équivalents en majuscules.
  3. Stop token -Supprime les valeurs de genre d'entrée anonyme, comme configuré.
  4. Map token -Convertit les valeurs de jeton d'entrée en valeurs équivalentes, comme configuré dans les ressources IBM Match 360 .
  5. Parse token -Analyse les valeurs de zone traitées dans une zone interne appropriée.
  6. Pick token -Sélectionne un sous-ensemble (ou la totalité) des jetons comme données standardisées à utiliser dans la création de tickets et la comparaison.

Le programme de standardisation de genre utilise par défaut les ressources de mappe suivantes:

  • map_character_general -Convertit les caractères d'entrée UNICODE en caractères alphabétiques anglais équivalents.
  • map_gender_gender -Mappe différentes valeurs de genre d'entrée à des valeurs standard.
  • map_gender_tokens_gender -Analyse la valeur du jeton d'entrée dans la zone gender interne en fonction d'une expression régulière.

Le programme de standardisation de genre utilise par défaut les ressources d'ensemble suivantes:

  • set_gender_anon_gender -Supprime les valeurs de genre d'entrée anonyme.
Programme de standardisation d'adresse

Ce programme de normalisation est utilisé pour normaliser les valeurs d'attribut d'adresse. Les adresses peuvent avoir plusieurs formats différents, en fonction des environnements locaux. Cette flexibilité nécessite un traitement complexe pour convertir les adresses en une forme standardisée. Le programme de standardisation d'adresse contient les recettes suivantes, dans l'ordre:

  1. Upper case -Convertit les valeurs de zone d'entrée pour utiliser leurs équivalents en majuscules.
  2. Map character -Convertit les caractères d'entrée UNICODE en caractères alphabétiques anglais équivalents. Vous pouvez éventuellement définir la mappe dans les ressources IBM Match 360 .
  3. Map token -Convertit les valeurs de jeton d'entrée en valeurs équivalentes, comme configuré dans les ressources IBM Match 360 . Par exemple, "Etats-Unis d'Amérique", "Etats-Unis" et "Etats-Unis" peuvent tous être mappés à "Etats-Unis". Ce mappage est commun pour les valeurs de zone de pays et de province / état. En outre, les caractères délimiteurs configurés dans la ressource sont mappés au caractère espace.
  4. Tokenizer -Permet de segmenter la valeur de la zone d'entrée en plusieurs jetons, en fonction de la liste de délimiteurs définie.
  5. Stop token -Supprime les valeurs d'entrée anonymes, telles que les codes postaux, telles que configurées.
  6. Keep token -Autorise uniquement la liste de valeurs définie pour un champ donné. Par exemple, vous pouvez définir une liste de codes postaux autorisés lors de la normalisation. Les valeurs d'entrée qui ne figurent pas dans la liste autorisée seront supprimées.
  7. Parse token -Analyse les valeurs de zone d'entrée dans des zones internes appropriées en fonction de certaines expressions régulières et de valeurs prédéfinies, telles que configurées dans les ressources. Vous pouvez utiliser cette recette pour tronquer un jeton donné à une certaine longueur à l'aide d'expressions régulières. Vous pouvez également définir différents ensembles de modèles alphanumériques sous la forme d'expressions régulières pour n'autoriser que certains modèles.
  8. Join fields -associe deux zones ou plus pour créer une nouvelle valeur combinée, affectée à une zone interne. Par exemple, les valeurs de zone latitude et longitude peuvent être jointes ensemble pour former une nouvelle zone interne appelée lat_long.
  9. Pick token -Sélectionne un sous-ensemble (ou la totalité) des jetons comme données standardisées à utiliser dans la création de tickets et la comparaison.

Le programme de standardisation d'adresse utilise par défaut les ressources de mappe suivantes:

  • map_character_general -Convertit les caractères d'entrée UNICODE en caractères alphabétiques anglais équivalents.
  • map_address_country -Convertit les valeurs de pays d'entrée en valeurs équivalentes.
  • map_address_province_state -Convertit les valeurs de province et d'état d'entrée en valeurs équivalentes.
  • map_address_delimiter_removal -Mappe les caractères délimiteurs configurés dans la ressource vers le caractère espace.
  • map_address_addr_tok -Convertit les valeurs de jeton d'adresse d'entrée en valeurs équivalentes.
  • map_address_tokens_unit_type_and_number -Analyse la zone d'entrée residence_number en fonction d'une expression régulière dans des zones internes, à savoir unit_type et unit_number.
  • map_address_tokens_street_number_name_direction_type -Analyse la zone d'entrée address_line1 en fonction d'une expression régulière dans des zones internes, à savoir street_number, street_name, directionet street_type.
  • map_address_tokens_sub_division -Analyse la zone d'entrée address_line2 en fonction d'une expression régulière dans la zone interne sub_division.
  • map_address_tokens_pobox_type_and_number -Analyse la zone d'entrée address_line3 en fonction d'une expression régulière dans des zones internes, à savoir pobox_type et pobox.
  • map_address_tokens_city -Analyse la valeur d'entrée de la zone city en fonction d'une expression régulière.
  • map_address_tokens_province -Analyse la valeur d'entrée de la zone province_state en fonction d'une expression régulière dans la zone interne province.
  • map_address_tokens_postal_code -Analyse la valeur d'entrée de la zone zip_postal_code en fonction d'une expression régulière dans la zone interne postal_code.
  • map_address_tokens_country -Analyse la valeur d'entrée de la zone country en fonction d'une expression régulière.
  • map_address_tokens_latitude -Analyse la valeur d'entrée de la zone latitude_degrees en fonction d'une expression régulière dans la zone interne latitude.
  • map_address_tokens_longtitude -Analyse la valeur d'entrée de la zone longitude_degrees en fonction d'une expression régulière dans la zone interne longitude.

Le programme de standardisation d'adresse utilise par défaut les ressources d'ensemble suivantes:

  • set_address_postal_code -Supprime les valeurs d'entrée anonymes pour zip_postal_code.
Programme de standardisation de téléphone

Ce programme de normalisation est utilisé pour normaliser les valeurs d'attribut de téléphone. Il contient les recettes suivantes, dans l'ordre:

  1. Stop character -Supprime les caractères d'entrée indésirables des valeurs de téléphone.
  2. Stop token -Supprime les valeurs de téléphone anonyme, comme configuré.
  3. Phone -Analyse les numéros de téléphone d'entrée avec des formats différents de différents environnements locaux dans un format commun. Cette recette peut être configurée pour supprimer les indicatifs régionaux et les codes pays des numéros de téléphone. Il peut également conserver un certain nombre de chiffres dans un numéro de téléphone normalisé.
  4. Parse token -Analyse les valeurs de zone traitées dans une zone interne appropriée en fonction de certaines expressions régulières, comme configuré dans les ressources.
  5. Pick token -Sélectionne un sous-ensemble (ou la totalité) des jetons comme données standardisées à utiliser dans la création de tickets et la comparaison.

Le programme de standardisation de téléphone utilise par défaut les ressources de carte suivantes:

  • map_phone_tokens_phone -Analyse les valeurs de téléphone dans un champ interne en fonction d'expressions régulières.

Le programme de standardisation de téléphone utilise par défaut les ressources d'ensemble suivantes:

  • set_character_phone -Remplace tous les caractères non alphanumériques. Permet de spécifier des expressions régulières.
  • set_phone_anon_phone -Supprime les valeurs de téléphone anonyme.
Programme de normalisation d'identification

Ce programme de normalisation est utilisé pour normaliser les valeurs d'attribut d'identification. Il contient les recettes suivantes, dans l'ordre:

  1. Map character -Convertit les caractères d'entrée UNICODE en caractères alphabétiques anglais équivalents. Vous pouvez éventuellement définir la mappe dans les ressources IBM Match 360 .
  2. Upper case -Convertit les valeurs de zone d'entrée pour utiliser leurs équivalents en majuscules.
  3. Stop character -Supprime les caractères d'entrée indésirables des valeurs d'identification.
  4. Stop token -Supprime les valeurs d'entrée anonymes, comme configuré.
  5. Map token -Convertit les valeurs de jeton d'entrée en valeurs équivalentes, comme configuré dans les ressources IBM Match 360 .
  6. Parse token -Analyse les valeurs de zone traitées dans une zone interne appropriée en fonction de certaines expressions régulières, comme configuré dans les ressources.
  7. Pick token -Sélectionne un sous-ensemble (ou la totalité) des jetons comme données standardisées à utiliser dans la création de tickets et la comparaison.

Le programme de standardisation d'identification utilise par défaut les ressources de mappe suivantes:

  • map_character_general -Convertit les caractères d'entrée UNICODE en caractères alphabétiques anglais équivalents.
  • map_identifier_equi_identifier -Convertit les valeurs de jeton d'entrée en valeurs équivalentes.
  • map_identifier_tokens_identification_number -Analyse les valeurs de zone traitées dans une zone interne appropriée en fonction de certaines expressions régulières, comme configuré dans les ressources.

Le programme de normalisation d'identification utilise par défaut les ressources Set suivantes:

  • set_character_identification_number -Supprime les caractères d'entrée non alphanumériques des valeurs d'identification. Permet de spécifier des expressions régulières.
  • set_identifier_anonymous -Supprime les valeurs d'identification anonyme.
Programme de standardisation d'e-mail

Ce programme de normalisation permet de normaliser les valeurs d'attribut d'e-mail. Il contient les recettes suivantes, dans l'ordre:

  1. Map character -Convertit les caractères d'entrée UNICODE en caractères alphabétiques anglais équivalents. Vous pouvez éventuellement définir la mappe dans les ressources IBM Match 360 .
  2. Upper case -Convertit les valeurs de zone d'entrée pour utiliser leurs équivalents en majuscules.
  3. Stop token -Supprime les valeurs d'entrée anonymes, comme configuré.
  4. Map token -Convertit les valeurs de jeton d'entrée en valeurs équivalentes, comme configuré dans les ressources IBM Match 360 .
  5. Parse token -Analyse les valeurs de zone traitées dans une zone interne appropriée en fonction de certaines expressions régulières, comme configuré dans les ressources.
  6. Pick token -Sélectionne un sous-ensemble (ou la totalité) des jetons comme données standardisées à utiliser dans la création de tickets et la comparaison.

Le programme de standardisation d'e-mail utilise par défaut les ressources de mappe suivantes:

  • map_character_general -Convertit les caractères d'entrée UNICODE en caractères alphabétiques anglais équivalents.
  • map_non_phone_equi_non_phone -Convertit les valeurs de jeton d'entrée en valeurs équivalentes.
  • map_non_phone_tokens_non_phone -Analyse la zone d'entrée email_id en fonction d'une expression régulière dans les zones internes email_local_part et email_domain.

Le programme de standardisation d'e-mail utilise par défaut les ressources d'ensemble suivantes:

  • set_non_phone_anon_non_phone -Supprime les valeurs d'e-mail anonymes.
Programme de normalisation des médias sociaux

Ce programme de normalisation est utilisé pour normaliser les valeurs d'attribut des médias sociaux. Il contient les recettes suivantes, dans l'ordre:

  1. Map character -Convertit les caractères d'entrée UNICODE en caractères alphabétiques anglais équivalents. Vous pouvez éventuellement définir la mappe dans les ressources IBM Match 360 .
  2. Upper case -Convertit les valeurs de zone d'entrée pour utiliser leurs équivalents en majuscules.
  3. Stop token -Supprime les valeurs d'entrée anonymes, comme configuré.
  4. Map token -Convertit les valeurs de jeton d'entrée en valeurs équivalentes, comme configuré dans les ressources IBM Match 360 .
  5. Parse token -Analyse les valeurs de zone traitées dans une zone interne appropriée en fonction de certaines expressions régulières, comme configuré dans les ressources.
  6. Pick token -Sélectionne un sous-ensemble (ou la totalité) des jetons comme données standardisées à utiliser dans la création de tickets et la comparaison.

Le programme de normalisation des médias sociaux utilise par défaut les ressources de mappe suivantes:

  • map_character_general -Convertit les caractères d'entrée UNICODE en caractères alphabétiques anglais équivalents.
  • map_non_phone_equi_non_phone -Convertit les valeurs de jeton d'entrée en valeurs équivalentes.
  • map_non_phone_tokens_non_phone -Analyse la zone d'entrée social_media_handle dans la zone interne social_media_id en fonction d'expressions régulières.

Le programme de normalisation des médias sociaux utilise les ressources d'ensemble suivantes par défaut:

  • set_non_phone_anon_non_phone -Supprime les valeurs social_media_id anonymes.

Types d'entité (bucketing)

Dans un seul algorithme de correspondance, chaque type d'enregistrement peut avoir plusieurs définitions de type d'entité (objetsentity_type JSON). Par exemple, dans un algorithme défini pour un type d'enregistrement de personne, vous pouvez avoir besoin de créer plusieurs définitions de type d'entité, telles que l'entité de personne, l'entité du foyer, l'entité d'emplacement et d'autres entités.

Chaque type d'entité peut être utilisé pour faire correspondre et lier des enregistrements de différentes manières. Un type d'entité définit comment les enregistrements sont mis en boucle et comparés lors du processus de correspondance.

Chaque définition de type d'entité (entity_type) dans l'algorithme de correspondance comporte plusieurs éléments JSON:

  • clerical_review_threshold - Les enregistrements dont le score de comparaison est inférieur au seuil d'examen de bureau sont considérés comme des non-concordances.

  • auto_link_threshold - Les enregistrements dont le score de comparaison est supérieur au seuil de connexion automatique sont considérés comme étant suffisamment solides pour qu'ils correspondent automatiquement.

  • bucket_generators - Cette section contient la définition des générateurs de compartiment configurés pour un type d'entité. Il existe deux types de générateurs : les compartiments et les groupes de compartiments.

    • Les compartiment implique un compartimentage pour un seul attribut. Chaque définition bucket comprend quatre éléments :

      • label - Un libellé qui identifie le générateur de compartiment.
      • maximum_bucket_size - Une valeur définissant la taille des gros compartiments. Tout hachage de compartiment dont la taille de segment est supérieure à cette valeur n'est pas pris en compte pour la sélection des candidats lors de la mise en correspondance.
      • inputs - Pour les compartiments, la liste inputs ne comporte qu'un seul élément, qui est un objet JSON. Cet objet JSON comporte deux éléments : fields et attributes:
        • fields - La liste des zones à utiliser pour le compartimentage.
        • attributes - La liste des attributs à utiliser pour le compartimentage.
      • bucket_recipe - Une liste de compartiment de segment définit les étapes du générateur de compartiment à exécuter pendant le processus du compartimentage. Chaque liste bucket_recipe comporte un certain nombre de sous-éléments :
        • label - Un libellé qui identifie l'élément de recette de compartiment.
        • method - La méthode interne utilisée. Cet élément est juste pour référence et ne doit pas être modifié.
        • inputs -Elément unique de la liste inputs défini un niveau supérieur.
        • fields - La liste des zones à utiliser pour ce compartiment. Il s'agit généralement d'un sous-ensemble de toutes les zones définies dans la liste inputs de niveau supérieur.
        • min_tokens - Le nombre minimal de jetons à utiliser lorsque la recette est en train de former un hachage de compartiment.
        • max_tokens - Le nombre maximal de jetons à utiliser ensemble lorsque la recette est en train de former un hachage de compartiment.
        • count - La limite du nombre de hachages de compartiments pour un enregistrement unique généré à partir d'un générateur de compartiment. Si un enregistrement génère un lot de hachages de compartiments, seul le nombre de hachages défini par cet élément est ramassé.
        • bucket_group - Le numéro de séquence d'un groupe de compartiments qui génère un hachage de compartiment. Un numéro de séquence n'a pas été attribué à des étapes ou des recettes intermédiaires.
        • order - Indique si les jetons sont triés en ordre lexicographique lorsque plusieurs jetons sont combinés pour former un hachage de compartiment.
        • maximum_bucket_size - Une valeur définissant la taille des gros compartiments. Cet élément est le même que celui qui est défini au niveau du générateur de compartiment ; aussi, le fait de l'avoir au niveau de la recette de compartiment vous donne un meilleur contrôle sur les importants compartiments individuels.

    • Les groupes de compartiments implique un compartimentage pour plus d'un attribut. Chaque définition bucket_group comprend cinq éléments :

      • label - Un libellé qui identifie le générateur de compartiment.
      • maximum_bucket_size - Une valeur définissant la taille des gros compartiments. Tout hachage de compartiment dont la taille de segment est supérieure à cette valeur n'est pas pris en compte pour la sélection des candidats lors de la mise en correspondance.
      • inputs - Pour les groupes de compartiments, la liste inputs comporte plusieurs éléments d'objet JSON. Les objets JSON ont chacun deux éléments : fields et attributes:
        • fields - La liste des zones à utiliser pour le compartimentage.
        • attributes - La liste des attributs à utiliser pour le compartimentage.
      • bucket_recipe - Une liste de compartiment de segment définit les étapes du générateur de compartiment à exécuter pendant le processus du compartimentage. Chaque liste bucket_recipe comporte un certain nombre de sous-éléments :
        • label - Un libellé qui identifie l'élément de recette de compartiment.
        • method - La méthode interne utilisée. Cet élément est juste pour référence et ne doit pas être modifié.
        • inputs -Elément unique de la liste inputs défini un niveau supérieur.
        • fields - La liste des zones à utiliser pour ce compartiment. Il s'agit généralement d'un sous-ensemble de toutes les zones définies dans la liste inputs de niveau supérieur.
        • min_tokens - Le nombre minimal de jetons à utiliser lorsque la recette est en train de former un hachage de compartiment.
        • max_tokens - Le nombre maximal de jetons à utiliser ensemble lorsque la recette est en train de former un hachage de compartiment.
        • count - La limite du nombre de hachages de compartiments pour un enregistrement unique généré à partir d'un générateur de compartiment. Si un enregistrement génère de nombreux hachages de compartiment, seul le nombre de hachages défini par cet élément est ramassé.
        • bucket_group - Le numéro de séquence d'un groupe de compartiments qui génère un hachage de compartiment. Un numéro de séquence n'a pas été attribué à des étapes ou des recettes intermédiaires.
        • order - Indique si les jetons sont triés en ordre lexicographique lorsque plusieurs jetons sont combinés pour former un hachage de compartiment.
        • maximum_bucket_size - Une valeur définissant la taille des gros compartiments. Cet élément est le même que celui défini au niveau du générateur de compartiment. Être capable de le définir au niveau de la recette de compartiments vous donne un meilleur contrôle sur les importants compartiments individuels.
        • set_resource - Le nom d'une ressource de type set utilisée pour une recette de compartiment.
        • map_resource - Le nom d'une ressource de type map utilisée pour une recette de compartiment.
        • output_fields - Si cette recette produit de nouvelles zones une fois qu'elle a terminé des fonctions de compartimentage dans les zones d'entrée, cet élément contient une liste des noms des zones générées.
      • bucket_group_recipe - Une section de recette de groupe de compartiments est généralement utilisée pour définir des segments qui se composent de plusieurs attributs. Chaque élément d'une liste bucket_group_recipe est un objet JSON définissant la construction pour un seul groupe de segments.
        • La liste inputs dans bucket_group_recipe comporte plusieurs éléments, ce qui signifie qu'elle fait référence à plusieurs attributs définis dans le tableau inputs de niveau supérieur.
        • L'élément fields est une liste de listes. Chaque liste interne de zones est associée à la liste attributes correspondante.
        • Les listes min_tokens et max_tokens comportent plusieurs éléments, chaque élément correspondant à la liste attributes respective.
      Remarque :

      Dans certaines définitions de recette de bucketing, il existe une propriété nommée search_only. Par défaut, sa valeur est false. Si la valeur est true, cette propriété indique qu'un compartiment ou un groupe de compartiments est utilisé uniquement pour les scénarios de recherche probabiliste et qu'il n'est pas utilisé pour les scénarios de résolution d'entité (mise en correspondance).

  • compare_methods - Définitions des méthodes de comparaison configurées pour un type d'entité. Chaque objet compare_methods JSON est constitué de définitions de différentes méthodes compare. L'algorithme de correspondance ajoute les scores de chaque définition de méthode compare pour obtenir le score de comparaison final. L'objet JSON de chaque méthode compare contient trois éléments :

    • label - Un libellé qui identifie la méthode compare.
    • methods - Une liste des comparateurs qui forment un groupe de comparaison. Chaque élément de ce tableau représente un comparateur, destiné à un type d'attribut correspondant. L'algorithme de correspondance considère le maximum des scores de tous les comparateurs dans une liste methods comme le score final de ce groupe de comparaison. Chaque définition de comparateur comprend deux éléments :
      • inputs - Pour les comparateurs, la liste inputs ne comporte qu'un seul élément, qui est un objet JSON. Cet objet JSON comporte deux éléments : fields et attributes:
        • fields - La liste des zones à utiliser pour la comparaison.
        • attributes - La liste des attributs à utiliser pour la comparaison.
      • compare_recipe -Cette liste est utilisée principalement pour définir les étapes de comparaison. En général, il n'existe qu'un seul élément JSON dans ce tableau, représentant une seule étape pour effectuer la comparaison. Cette étape comporte cinq éléments :
        • label - Un libellé qui identifie l'étape de comparaison.
        • method - La méthode interne utilisée. Cet élément est juste pour référence et ne doit pas être modifié.
        • inputs -Elément unique de la liste inputs défini un niveau supérieur.
        • fields -Zones à utiliser pour cette comparaison parmi toutes les zones définies dans la liste inputs de niveau supérieur.
        • comparison_resource - Le nom d'une ressource de comparaison personnalisable utilisée pour cette étape de comparaison.
    • weights - Chaque comparaison effectuée par un comparateur donne un score de nombre compris entre 0 et 10. Ce nombre est appelé mesure de distance ou de similarité. Une distance de 0 indique que les valeurs comparées sont exactement les mêmes. Une distance de 10 indique qu'ils sont complètement différents. En réponse aux 11 valeurs distinctes (0 à 10), 11 poids sont définis pour chaque comparateur. Après avoir calculé la distance, la méthode de comparaison détermine la valeur de pondération correspondante dans la liste des pondérations, ce qui donne le score de comparaison total. Les ingénieurs de données peuvent personnaliser les pondérations selon les besoins, en fonction de la qualité des données, de la distribution ou d'autres facteurs.

  • record_filter -L'élément de filtrage d'enregistrement permet au moteur de mise en correspondance de sélectionner des enregistrements à mettre en correspondance en fonction de leurs types d'entité. Chaque définition de filtre d'enregistrement contient un élément:

    • criteria -Inclut ou exclut les enregistrements de la prise en compte de la correspondance en fonction de conditions spécifiques. Cet élément contient un objet JSON avec une paire clé-valeur.

      La clé de l'objet JSON criteria est un nom d'attribut. Il peut s'agir de l'un des éléments suivants:

      • Attribut système record_source .
      • Attribut personnalisé défini par l'utilisateur d'un type d'attribut simple (chaîne).

    La valeur de l'objet JSON criteria est un autre objet JSON contenant un élément, qui peut être l'un des suivants:

    • allowed -Tableau de valeurs de chaîne. Les enregistrements qui incluent l'une de ces valeurs seront pris en compte lors de la mise en correspondance.
    • disallowed -Tableau de valeurs de chaîne. Les enregistrements qui incluent l'une de ces valeurs ne seront pas pris en compte lors de la mise en correspondance.

  • source_level_thresholds -Les seuils de niveau source vous permettent de définir des seuils de liaison automatique et de révision administrative sur une base de source à source. Les seuils de niveau source remplacent les valeurs de seuil globales par défaut. Chaque configuration de seuil de niveau source contient une collection de sources avec des seuils par défaut spécifiques à la source facultatifs ou une collection de paires de seuils source-source qui vous permettent de définir des seuils différents pour chaque source. Pour plus d'informations, voir Configuration des seuils de correspondance spécifiques à la source dans la rubrique Optimisation de l'algorithme de correspondance avancé .

Ressources de demande de service

Les définitions de compartiment utilisent les ressources de mappe suivantes par défaut:

  • person_map_name_nickname -Génère des pseudonymes ou d'autres noms pour une entrée de nom de personne donnée.
  • org_map_name_cnick_name -Génère des pseudonymes ou d'autres noms pour une entrée de nom d'organisation donnée.

Les définitions de compartiment utilisent par défaut les ressources Set suivantes:

  • person_set_name_bkt_anon -Supprime les valeurs de nom de personne anonyme.
  • org_set_name_acname -Supprime les valeurs de nom d'organisation anonyme.

Fonctions de comparaison

Les fonctions de comparaison, parfois appelées comparateurs, sont l'un des composants clés de l'algorithme de correspondance. Les fonctions de comparaison sont utilisées par le moteur de mise en correspondance pour comparer les données d'enregistrement lors du processus de mise en correspondance. Essentiellement, la mise en correspondance d'enregistrements implique la comparaison de différents types d'attributs entre les données de différents enregistrements.

Pour la plupart des types d'attribut couramment utilisés dans les domaines de personne, d'organisation et d'emplacement, le moteur de correspondance IBM Match 360 inclut des méthodes de comparaison préconfigurées.

Dans IBM Match 360, les fonctions de comparaison utilisent une approche de comparaison connue sous le nom de vecteurs de fonction. Il existe différentes définitions de fonction personnalisables dans IBM Match 360 qui sont utilisées pour différentes fonctions de comparaison. Chaque comparaison aboutit à une mesure de la distance (un vecteur) qui montre à quel point deux valeurs d'attribut données sont dissimilaires.

Dans l'algorithme de correspondance, chaque valeur de distance discrète est affectée d'une pondération qui détermine le degré de prise en compte de cette valeur. Le poids est combiné à la distance pour produire un score de comparaison. L'algorithme de correspondance ajoute tous les scores de comparaison ensemble pour obtenir un score de comparaison final pour la comparaison globale enregistrement à enregistrement.

A propos des fonctions

Une fonction représente les détails de niveau fin d'une fonction de comparaison. Différents types d'attributs utilisent différents types de contrôles de similarité, ce qui signifie que leurs caractéristiques varient également.

Les définitions de fonction déterminent les types de fonctions internes utilisées pour chaque fonction de comparaison. Des exemples de fonctions internes incluent la correspondance exacte, la distance d'édition, le pseudonyme, l'équivalent phonétique ou la correspondance initiale.

Ressources de comparaison

Chaque méthode de comparaison inclut des ressources qui contiennent les détails de ses opérations de comparaison internes.

Chacun des types de comparaison par défaut possède ses propres ressources. Voir chaque type de comparaison pour plus de détails sur les ressources associées.

Pour les comparaisons sur des types d'attribut personnalisés dont le type correspond à generic, la méthode de comparaison générique inclut les ressources suivantes:

  • compare_spec_generic -Dans l'algorithme généré, le format de nom de cette ressource est recordType_entityType_compare_spec_generic.

Comparaisons de noms de personnes

Les différentes zones d'un attribut de nom de personne sont traitées différemment. Pour les zones telles que les valeurs de préfixe, de suffixe et de génération, l'exactitude ou la non-concordance est vérifiée. D'autres zones, telles que le prénom, le nom de famille et le deuxième prénom, utilisent principalement les fonctions suivantes:

  • Correspondance exacte
  • Correspondance de pseudonymes
  • Editer la distance
  • Correspondance des initiales
  • Correspondance phonétique
  • Mauvais positionnement des jetons
  • Jetons supplémentaires
  • Valeurs manquantes

La méthode de comparaison des noms de personne inclut les ressources suivantes:

  • person_compare_spec_name -Dans l'algorithme généré, le format de nom de cette ressource est recordType_entityType_ compare_spec_name. Par exemple : person_person_entity_compare_spec_name.

Comparaisons de noms d'organisation

Pour les noms d'organisation, il existe une zone qui contient l'intégralité du nom métier. Ce champ est comparé à l'aide principalement des caractéristiques suivantes:

  • Correspondance exacte
  • Correspondance de pseudonymes
  • Editer la distance
  • Correspondance des initiales
  • Correspondance phonétique
  • Mauvais positionnement des jetons
  • Jetons supplémentaires
  • Valeurs manquantes

Pour les noms d'organisation, les acronymes et les pseudonymes sont également comparés pour leur exactitude.

La méthode de comparaison des noms d'organisation inclut les ressources suivantes:

  • org_compare_spec_name -Dans l'algorithme généré, le format de nom de cette ressource est recordType_entityType_ compare_spec_name.

Comparaisons de dates

Pour les dates, il existe généralement trois zones à comparer: jour, mois et année.

La zone year est comparée à l'aide des fonctions suivantes:

  • Exactitude
  • Editer la distance
  • Non-correspondance
  • Manquant

Les zones day et month sont comparées à l'aide des fonctions suivantes:

  • Exactitude
  • Non-correspondance
  • Manquant

Le comparateur de dates vérifie également si les zones day et month ont été transposées en raison de différences d'environnement local dans le formatage des dates.

La méthode de comparaison de date inclut les ressources suivantes:

  • compare_spec_date -Dans l'algorithme généré, le format de nom de cette ressource est recordType_entityType_ compare_spec_date.

Comparaisons de genre

L'attribut de genre est comparé à l'aide des fonctions suivantes:

  • Exactitude
  • Non-correspondance

La méthode de comparaison des sexes comprend les ressources suivantes:

  • compare_spec_gender -Dans l'algorithme généré, le format de nom de cette ressource est recordType_entityType_ compare_spec_gender.

Comparaisons d'adresses

Les différentes zones d'un attribut d'adresse sont traitées différemment.

Les zones telles que le pays, la ville, la province / l'état et la subdivision sont comparées à l'aide des caractéristiques suivantes:

  • Exactitude
  • Equivalence
  • Editer la distance
  • Non-correspondance
  • Manquant

Les zones de code postal sont comparées à l'aide des fonctions suivantes:

  • Exactitude
  • Editer la distance
  • Non-correspondance
  • Manquant

Les champs tels que le numéro de rue, le nom de la rue, le type de rue, le numéro d'unité et la direction sont comparés à l'aide des caractéristiques suivantes:

  • Exactitude
  • Equivalence
  • Correspondance des initiales
  • Editer la distance
  • Non-correspondance
  • Mauvais positionnement des jetons
  • Manquant

La méthode de comparaison d'adresses inclut les ressources suivantes:

  • compare_spec_address -Dans l'algorithme généré, le format de nom de cette ressource est recordType_entityType_ compare_spec_address.

Comparaisons téléphoniques

Les attributs de numéro de téléphone sont comparés à l'aide des fonctions suivantes:

  • Correspondance exacte
  • Editer la distance
  • Non-correspondance

La méthode de comparaison téléphonique inclut les ressources suivantes:

  • compare_spec_phone -Dans l'algorithme généré, le format de nom de cette ressource serait recordType_entityType_ compare_spec_phone.

Comparaisons d'identificateurs

Les attributs de numéro d'identification sont comparés à l'aide des fonctions suivantes:

  • Correspondance exacte
  • Editer la distance
  • Non-correspondance

La méthode de comparaison des identificateurs inclut les ressources suivantes:

  • compare_spec_identifier -Dans l'algorithme généré, le format de nom de cette ressource est recordType_entityType_ compare_spec_identifier.

Comparaisons de courriers électroniques

Les attributs d'e-mail se composent de deux parties: l'ID unique (avant le symbole @) et le domaine d'e-mail (après le symbole @). Les parties ID et domaine sont comparées séparément à l'aide des fonctions suivantes:

  • Correspondance exacte
  • Editer la distance
  • Non-correspondance

Les résultats des deux comparaisons sont combinés de manière pondérée afin de produire un score de comparaison global.

La méthode de comparaison de courrier électronique inclut les ressources suivantes:

  • compare_spec_email -Dans l'algorithme généré, le format de nom de cette ressource est recordType_entityType_ compare_spec_email.

Comparaisons des médias sociaux

Les attributs de descripteur des médias sociaux sont comparés à l'aide des fonctions suivantes:

  • Correspondance exacte
  • Editer la distance
  • Non-correspondance

La méthode de comparaison des médias sociaux inclut les ressources suivantes:

  • compare_spec_non_phone -Dans l'algorithme généré, le format de nom de cette ressource est recordType_entityType_ compare_spec_non_phone.

Editer la distance

Le moteur de correspondance IBM Match 360 calcule la distance d'édition comme l'une des fonctions internes lors de la comparaison et de la correspondance des différents attributs. La distance d'édition est une mesure de la façon dont les deux chaînes sont différentes les unes des autres. Elle est calculée en comptant le nombre de modifications requises pour transformer une chaîne en une autre.

Il existe différentes manières de définir la distance d'édition à l'aide de différents ensembles d'opérations de chaîne. Par défaut, IBM Match 360 utilise une fonction de distance d'édition standard accessible au public dans la littérature. Vous pouvez également choisir d'utiliser une fonction de distance d'édition IBM Match 360 spécialisée.

  • La fonction de distance d'édition standard fournit une meilleure performance du moteur correspondant. Pour cette raison, il s'agit de la configuration de comparaison par défaut pour tous les attributs, à l'exception du type d'attribut Téléphone.

  • Fonction de distance d'édition spécialisée est créé pour les cas d'utilisation d'hyper-précision. Cette option prend en compte des typos ou des caractères similaires, tels que 8 et B, 0 et O, 5 et S, ou 1 et I. Lorsqu'il y a une non concordance dans deux valeurs comparées basées sur des caractères similaires, la mesure de dissimilarité attribuée est inférieure à ce qui serait affecté par une fonction de distance d'édition standard. Par conséquent, ces types de non correspondances ne sont pas pénalisées aussi fortement par la fonction spécialisée.

    Important : La fonction de distance d'édition spécialisée inclut des calculs complexes. En conséquence, le choix de cette option a une incidence sur les performances du système pendant le processus de mise en correspondance.

Pour plus d'informations sur la personnalisation de votre algorithme de correspondance, y compris l'utilisation de l'API pour personnaliser la distance d'édition, voir Personnalisation et renforcement de votre algorithme de correspondance.

En savoir plus

Rubrique parent : Gestion des données maître

Recherche et réponse à l'IA générative
Ces réponses sont générées par un modèle de langue de grande taille dans watsonx.ai en fonction du contenu de la documentation du produit. En savoir plus