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.
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, les 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.
Dans l'exemple suivant, vous souhaitez trouver les doublons ayant la même ville ou le même code postal dans une base de données clients. Vous pouvez utiliser deux composants tMatchGroup à la suite afin de traiter les partitions de données. Le jeu de données contient quatre enregistrements. Le premier composant tMatchGroup a une clé de bloc définie sur la colonne ZipCode et le second tMatchGroup a une clé de bloc définie sur la colonne city. Le nom (name) de l'attribut est utilisé comme 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 | _ |
Le caractère _ dans la colonne ZipCode représente une donnée vide. Le code postal ZipCode n'est pas fourni pour les enregistrements 2 et 4.
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 |
Le caractère _ dans la colonne ZipCode représente une donnée vide. Comme le code postal ZipCode n'a pas été fourni en entrée, la colonne ZipCode est vide pour les enregistrements 2 et 4.
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 |
Le caractère _ dans la colonne ZipCode représente une donnée vide. Comme le code postal ZipCode n'a pas été fourni en entrée, la colonne ZipCode est vide pour les enregistrements 2 et 4.