À propos des Links

Petr Beles, 2150 GmbH 2017-02-11 Links représentant des transactions dans Data Vault

Dans cet article, je discute uniquement des links représentant des transactions. J’exclus délibérément les links représentant des relations (c’est-à-dire les relations de master data — donnant du contexte à un objet comme le link entre une ville et une commune).

Une ligne dans un link conventionnel dans Data Vault est définie par une combinaison unique de relations (représentée par le hash des BKs composés de tous les hubs impliqués) plus potentiellement un dependent child key. (Building a scalable DWH with DV 2.0 — Linstedt & Olschimke 4.4.5)

Dans le monde réel, les transactions ont souvent des business keys uniques (le numéro qui est communiqué au client — pas la clé technique). Prenons une commande comme exemple : une commande a un numéro de commande et chaque ligne de cette commande a un numéro de ligne. Même si le numéro de ligne en lui-même est une weak entity, il est uniquement identifiable en combinant l’id de transaction avec le numéro de ligne.

Cela signifie que la hash key dépend des relations identifiantes comme celle vers la transaction (si modélisée explicitement) et le dependent child key comme le numéro de ligne de commande. Le problème est qu’aussi des parties non identifiantes telles que la relation client ou produit sont utilisées pour construire la hash key pour une ligne dans la table link. En d’autres termes, la hash key représentant la combinaison de toutes les business keys plus le dependent child est en fait une hashdiff key et non un identifiant de transaction.

Il n’y a rien de mal à cela. Une hashdiff key peut être un outil très puissant pour déterminer si une ligne doit être insérée ou non. Si les relations non identifiantes d’une transaction ne changent jamais après que la transaction a été soumise au Data Vault, le grain du link est même le même que le grain des transactions.

Le problème est : dans de nombreuses industries, les relations non identifiantes d’une transaction peuvent changer ou arriver après qu’elle a été soumise au Vault. Les deux processus métier valides conduisent à une seconde entrée dans le link Data Vault conventionnel.

Alors pourquoi changer quelque chose qui fonctionne ?

Honnêtement parce que je n’ai jamais compris le grain de la table link : une transaction a initialement une ligne quand elle arrive pour la première fois. Si le client d’une commande change comme décrit ci-dessus, une nouvelle ligne est ajoutée. Donc, nous avons maintenant deux lignes dans la table link pour la même transaction. Si la commande est ramenée au premier client, elle a toujours deux lignes.

Et le deuxième problème, plus important, est logique : les link à link links doivent être omis car non seulement vous casseriez vos processus agiles à cause des dépendances mais vous lieriez aussi des versions de votre transaction entre elles au lieu de la transaction elle-même.

Alors quels sont les changements qui pourraient améliorer la situation à mon avis personnel ?

• Créer un hub qui représente toujours le grain le plus fin de votre transaction. Dans l’exemple ci-dessus : sales order line avec une BK de order id en combinaison avec le numéro de ligne

• Inclure le link vers ce hub dans votre transaction. Se débarrasser du dependent child key dans le link car il n’est plus nécessaire

• Connecter tous les attributs de contexte de votre transaction au hub comme un satellite normal au lieu de le connecter au link

• Connecter les tracking satellites qui vérifient les clés manquantes dans la source à ce hub au lieu du link

• Décider si votre transaction peut changer après avoir été soumise au Data Vault

  • Si oui : charger votre link comme SCD Type 2 load basé sur ce hub conducteur — vous pouvez créer une vue SCD Type 1 virtuelle ou matérialisée par-dessus ce link en partitionnant par la keyed-instance hub key

  • Si non : charger votre link comme SCD Type 0 load basé sur ce hub conducteur

• Si la performance est un problème, vous pouvez toujours utiliser l’approche hashdiff pour charger la table link SCD type 2

• Si vous devez lier deux transactions, créez simplement un link entre les deux keyed-instance hubs basé sur le bon grain de ces transactions

La chose drôle est, quand vous regardez ce que vous devez faire techniquement, vous faites exactement la même chose que pour charger un satellite : vous comparez des attributs (hash keys liés) basés sur la hash key du hub.

De plus, ajouter des parties de link non identifiantes devient absolument agile car elles se connectent simplement au même hub et peuvent être fusionnées avec le link existant de manière sans perte.

Et en dernier point, vous pouvez mettre les parties optionnelles d’un link dans une table séparée qui est peu peuplée. Avec le hub tenant le bon grain de la transaction, vous pouvez réunir les parties obligatoires et optionnelles. Appliquez juste le même pattern que lors de la combinaison de différents satellites.

Cela s’oppose-t-il au standard Data Vault ?

Honnêtement, pour la plupart des parties, je crois que non :

• Rien ne devrait vous empêcher de créer un hub au plus bas grain d’une transaction et de l’appeler hub « keyed-instance ».

• Stocker les attributs dépendant d’une hub key comme satellite par opposition à un satellite link ? Je n’y vois pas non plus de problème.

• Est-il possible d’implémenter des links qui sont vraiment identifiés par tous les objets liés : oui c’est possible en combinant toutes les clés dans le hub.

• Est-ce que tout ce qui est livré peut être reproduit à partir des données stockées : oui

• La losslessness (Verbundtreue) est-elle garantie : oui

Il y a un mais : en implémentant le link comme SCD type 2 load basé sur le keyed instance hub, cela change le nombre de lignes dans la table link. Dans mon exemple avec une commande qui passe du client A à B et revient, il y aurait seulement 2 lignes dans le pattern original. Dans le nouveau design, elle a maintenant 3 lignes. La PK n’est pas la hashdiff key basée sur toutes les parties mais la keyed instance hub hash key + le load time.

Donc oui, il y a un petit écart par rapport au standard qui à mon avis a du sens car cela rend l’interrogation de la table beaucoup plus simple : si vous voulez obtenir la dernière version de la transaction, partitionnez juste par la driving hub key et prenez la dernière load date.

Pas besoin de joindre d’autres tables pour trouver la dernière version comme vous auriez besoin de le faire dans la conception originale. Pareil pour créer une histoire complète de la transaction : juste partitionner par la driving hub key. Et le plus important, le grain est défini à nouveau : chaque version de la transaction dans le temps a sa propre ligne.

Alors devrais-je l’utiliser ?

C’est à vous. Mais je suis confiant que le pattern fonctionne comme décrit et nous l’avons prouvé dans des scénarios du monde réel incluant du traitement en temps quasi réel et j’aime les bénéfices qui viennent avec. Donc est-ce que je l’utilise pour tous les links ? Non ! Mais je l’utilise pour tous les links représentant des transactions. Les links entre master data représentant du contexte sont une autre histoire que je discuterai séparément.