Conseil 67: Maintenir des références vers les sources opérationnelles

Nos entrepôts de données sont de plus en plus orientés vers le suivi des opérations détaillées des clients en quasi temps réel. Et comme Patricia Seybold souligne dans son livre, Customers.com (Times Business, 1998), la gestion des relations client, c'est avoir accès aux données de tous les processus d'une organisation en relation avec les clients.

Garder les informations détaillées issues de tous les processus faisant face aux clients, et en même temps fournir une vision intégrée, présente un défi intéressant pour l'architecte ETL. Supposons que nous ayons une entreprise orientée client avec une quinzaine de systèmes en relation avec celui-ci comme la gestion des ventes des magasins, des ventes en ligne, des livraisons, des paiements, des crédits, des contrats de maintenance, des centres d'appels et diverses formes de communications commerciales. Beaucoup de ces systèmes créent leur propre clé naturelle pour chaque client, et certains d'entre eux ne traitent pas les doublons se référant à un même client. Au final, Il se peut que nous n'ayons aucun identifiant client unique et fiable à travers tous ces systèmes.

L'architecte ETL fait face à la tâche ardue d'avoir à dédupliquer les enregistrements clients de chaque système source distinct, à faire correspondre les clients à travers les différents systèmes, et à conserver les attributs les plus fiables issus de chacun des systèmes.

Le dilemme pour l'architecte ETL est que, même après avoir produit un enregistrement final parfait du client, l'analyste peut être incapable de retracer le chemin qui va de l'entrepôt de données à un ensemble de transactions intéressantes dans l'un des systèmes sources. Les étapes qui mènent à la création de cet enregistrement parfait peut se composer de changements subtils dans les noms, les adresses et les attributs des clients qui découplent l'entrepôt de données des transactions originales des systèmes sources.

La demande récente des utilisateurs finaux à avoir accès à tous les détails disponibles des transactions clients dans l'entrepôt de données, signifie que nous avons besoin d'une certaine manière de reporter tous les ID clients d'origine dans la dimension Client finale. En outre, si les systèmes sources ont généré des enregistrements en double pour un même client (que nous avons trouvé et corrigé lors du traitement ETL), nous devons stocker tous ces identifiants en double dans la dimension Client. En maintenant seulement un ensemble complet de pointeurs vers les identifiants d'origines du client, pouvons-nous offrir le niveau de traçage que les analystes et utilisateurs finaux attendent.

Je recommande de créer une simple table de références croisées pour conserver tous les identifiants clients d'origine. Cette table contient les champs suivants:

• Clé naturelle client dans l'entrepôt de données
• Nom du système source
• Clé client dans le système source

La clé naturelle client dans l'entrepôt de données est créée par l'entrepôt lui même. Nous avons besoin de ce type de clé permanente et immuable dans la dimension Client pour identifier sans ambiguité les évolutions lentes de type 2 d'un client donné.

Cette table peut être requêtée directement, en filtrant sur la clé naturelle de l'entrepôt de données, ou par une jointure entre ce champ et son double dans la dimension Client. Dans les deux cas, les champs Système Source donneront la liste complète des identifiants d'origine.

Cette conception a l'avantage qu'en ajoutant simplement des lignes de données dans notre petite table de références croisées, nous arrivons à gérer les différents identifiants clients dans les systèmes sources, ainsi que l'intégration de nouveaux systèmes sources à l'avenir.

Source originale: www.kimballgroup.com

Article original "Kimball Design Tip #67: Maintaining back pointers to operational sources", publié le 4 mai 2005.