Qu'est-ce qu'un link dans Data Vault ?

Les hubs vous disent quels clients, produits et commandes existent. Ils ne disent rien de la façon dont ces éléments sont liés entre eux. C’est le rôle du link.

En termes de modélisation classique, une relation devient un link. Pour le dire simplement, une clé étrangère dans un modèle en troisième forme normale sert de base à un link. Là où la table Order porte un customer_id, le Data Vault comporte un link entre le hub commande et le hub client.

Le link classique

Un link enregistre une relation entre des business keys : cette commande appartient à ce client, ce contrat couvre ce produit. Comme un hub, il ne stocke aucune donnée descriptive.

Une table de link contient :

• Link hash key. La clé primaire, un hash calculé sur les business keys de tous les hubs qu’il relie.
• Hash keys des hubs. Une colonne par hub participant.
• Load Date. Le moment où la relation a été vue pour la première fois.
• Record Source. Le système qui l’a livrée.

Comme les hubs, les links sont alimentés en insertion seule. Une relation vue une fois reste dans le link : savoir si elle est encore valable aujourd’hui relève d’un effectivity satellite, qui fera l’objet d’un prochain article de cette série.

Dans le Data Vault tel que le décrivent les manuels, chaque link est modélisé en n:m, afin de ne jamais avoir à le reconstruire lorsqu’une relation 1:n devient n:m après une fusion ou l’arrivée d’un nouveau système. Une structure n:m ne signifie pas pour autant que les données le sont. Si une commande est rattachée à un autre client, elle ne se met pas à appartenir à deux clients : le nouveau client remplace l’ancien. Pour lire un link correctement, il faut connaître son côté directeur.

Dans Datavault Builder, le link classique est un link binaire entre deux hubs, et il porte sa cardinalité : 1:1, n:1, 1:n ou n:m. La cardinalité définit quel côté dirige la relation, si bien qu’un changement du côté directeur est interprété comme un remplacement, et non comme une relation supplémentaire.

Si vous connaissez la modélisation classique, vous connaissez déjà le link

Le link de transaction

Pour les transactions, Datavault Builder ajoute un second type de link. Une transaction, comme une ligne de commande, un paiement ou une ligne de livraison, se rapporte à plusieurs hubs à la fois, et le Data Vault conventionnel la place souvent directement dans un link, parfois non historisé et doté de dependent child keys. La granularité reste alors implicite : c’est la combinaison de clés, quelle qu’elle soit, qui rend une ligne unique. Si la source rattache ensuite une ligne de commande à un autre client, ce link contient deux lignes pour la même ligne de commande, et rien dans le modèle n’indique laquelle décrit la transaction.

Le link de transaction rend la granularité explicite. La granularité la plus fine de la transaction reçoit son propre hub, le grain hub (Hub_Sales_Order_Line, Hub_Payment_Transaction), et le link est ancré sur lui. Le link de transaction acquiert ainsi quatre propriétés, chacune avec sa raison d’être :

• Une granularité fixe. Il y a une entrée de link par ligne de commande, et la granularité ne peut pas dériver.

• Un côté directeur défini. Le grain hub dirige la relation. Si une ligne de commande reçoit un nouveau produit, le nouveau produit remplace l’ancien : la ligne ne se retrouve pas à pointer vers deux produits à la fois.

• Des relations identifiantes et non identifiantes. Le grain hub est l’identité de la transaction. Le client, le produit et le magasin y participent en tant que références, selon la même distinction qu’en modélisation entité-association classique.

  « La clé, toute la clé, rien que la clé, je le jure devant Codd. » Le résumé classique de la troisième forme normale de Codd vaut ici aussi : le grain hub est la clé de la transaction, et tout le reste la décrit ou renvoie à un autre concept.

• Des attributs portés par un hub. La quantité, le prix et le statut vont dans un satellite ordinaire rattaché au grain hub. Ils peuvent être chargés en delta comme ceux de n’importe quel autre satellite, et d’autres attributs peuvent être ajoutés plus tard sans remodélisation. Data Vault autorise aussi les link satellites pour cela : notre expérience montre qu’un hub s’y prête mieux, et il en va de même pour une table d’association qui porte des attributs, comme un rôle ou un pourcentage dans l’affectation d’un client à un contrat.

Résoudre le problème des links entre links

La première règle de Data Vault veut que les links relient des hubs. Un link ne peut pas référencer un autre link.

Or, dans la réalité, les transactions se rapportent sans cesse à d’autres transactions : une ligne de facture correspond à une ligne de livraison, un paiement solde une facture, un retour référence une ligne de commande. Le contournement habituel consiste à tout aplatir dans un seul link composite à six clés de hub ou plus, difficile à lire et qui fait de chaque chargement une unité de travail volumineuse.

Avec les links de transaction, le problème disparaît. Chaque transaction possède déjà un grain hub, si bien qu’une relation entre deux transactions est un link ordinaire entre deux hubs :

Hub_Delivery_Line ↔ Link_Delivery_To_Invoice ↔ Hub_Invoice_Line

Aucune référence d’un link vers un autre, aucun contournement par dependent child keys, et chaque link reste suffisamment petit pour être lisible.

Ce pattern remonte à 2017, lorsque je l’ai décrit pour la première fois dans « À propos des Links », en le comparant au standard Data Vault 2.0.

Ce qui change avec Datavault Builder

• Les deux types de link, dans un seul modèle. Des links binaires pour les relations entre données de référence, des links de transaction lorsque la relation est une transaction.
• La cardinalité et la granularité sont des décisions de modélisation. Vous indiquez la cardinalité d’un link binaire, ou ce qu’est une transaction, et l’outil construit à partir de là le link et ses chargements.
• Le code est généré. Les hash keys, l’unité de travail et le chargement en insertion seule suivent le même pattern pour chaque link, sur Snowflake, Databricks, BigQuery, SQL Server, Fabric, Oracle ou PostgreSQL.

Ce qu’il faut décider

Prenez vos trois transactions les plus importantes et notez, pour chacune, ce qui en constitue une occurrence. Si la réponse est une combinaison de client, de produit et de date plutôt qu’un numéro de ligne ou de document, la granularité est implicite, et c’est là qu’un link de transaction stabilisera le modèle.