Rapprochement via de multiples passes
Vous pouvez créer un Job ayant plusieurs tMatchGroup à la suite afin de créer des partitions de données basées sur différentes clés de bloc.
Par exemple, vous souhaitez chercher les doublons ayant la même ville ou le même code postal dans une base de données clients. Dans ce cas, vous pouvez utiliser deux composants tMatchGroup à la suite afin de traiter les partitions de données :
- Un tMatchGroup pour lequel la colonne "city" est la clé de bloc.
- Un tMatchGroup pour lequel la colonne "ZipCode" est la clé de bloc.
Qu'est-ce que le rapprochement via de multiples passes ?
L'idée sur laquelle repose le rapprochement via de multiples passes consiste à réutiliser des enregistrements maître définis dans la passe précédente en tant que données d'entrée du composant tMatchGroup. Le rapprochement via de multiples passes est plus efficace si les clés de bloc ne sont presque pas corrélées. Par exemple, il n'est pas pertinent de définir la colonne "country" (pays) en tant que clé de bloc et la colonne "city" (ville), comme autre clé de bloc, car toutes les comparaison effectuées avec la clé de bloc "city" seront également effectuées avec la clé de bloc "country".
Lorsque vous utilisez le rapprochement via de multiples passes avec l'algorithme Simple VSR Matcher, seuls les enregistrements maître de taille 1 (enregistrements pour lesquels il n'y a eu aucune correspondance) sont comparés aux enregistrements maître, quelle que soit leur taille. Il n'y aucune comparaison entre deux enregistrements maître créés à partir d'au moins deux enfants chacun.
Exemple de rapprochement via de multiples passes
Dans l'exemple suivant, le jeu de données contient quatre enregistrements. Le premier composant tMatchGroup a une clé de bloc définie sur la colonne "ZipCode", le deuxième composant tMatchGroup a une clé de bloc définie sur la colonne "city". L'attribut "name" est utilisé en tant que clé de rapprochement.
| id | Name (Nom) | city | ZipCode |
|---|---|---|---|
| 1 | John Doe | Nantes | 44000 |
| 2 | John B. Doe | Nantes | |
| 3 | Jon Doe | Nantes | 44000 |
| 4 | John Doe | Nantes |
Après la première passe, les enregistrements 1 et 3 sont regroupés d'une part, les enregistrements 2 et 4 sont regroupés d'autre part. Dans ces groupes, l'enregistrement 1 et l'enregistrement 2 sont des enregistrements maître.
Dans le deuxième tMatchGroup, seuls les enregistrements maître de la première passe, l'enregistrement 1 et l'enregistrement 2, sont comparés. Puisque la taille des groupes est strictement supérieure à 1, ils ne font l'objet d'aucune comparaison. L'ordre dans lequel les enregistrements en entrée sont classés est donc très important.
Les résultats suivants sont retournés :
| id | Name (Nom) | city | ZipCode | GID | GRP_SIZE | MASTER | SCORE | GRP_QUALITY |
|---|---|---|---|---|---|---|---|---|
| 1 | John Doe | Nantes | 44000 | 0 | 2 | true | 1.0 | 0.875 |
| 3 | Jon Doe | Nantes | 44000 | 0 | 0 | false | 0.85 | 0 |
| 2 | John B. Doe | Nantes | 1 | 2 | true | 1.0 | 0.727 | |
| 4. | John Doe | Nantes | 1 | 0 | false | 0.72 | 0 |
Lorsque vous utilisez l'algorithme T-Swoosh avec les mêmes paramètres et la fonction de consolidation Most common, les résultats suivants sont retournés :
| id | Name (Nom) | city | ZipCode | GID | GRP_SIZE | MASTER | SCORE | GRP_QUALITY |
|---|---|---|---|---|---|---|---|---|
| 1 | John Doe | Nantes | 44000 | 0 | 4 | true | 1.0 | 0.727 |
| 1 | John Doe | Nantes | 44000 | 0 | 0 | true | 0.875 | 0 |
| 3 | Jon Doe | Nantes | 44000 | 0 | 0 | false | 0.875 | 0 |
| 2 | John B. Doe | Nantes | 0 | 0 | true | 0.72 | 0 | |
| 4 | John Doe | Nantes | 1 | 0 | false | 0.72 | 0 |