Clés techniques versus clés métier dans Data Vault
Les systèmes sources conservent la business key dans l'enregistrement de référence, mais toutes les relations reposent sur des clés techniques. Quatre façons de gérer cette situation, ce que coûte chacune, et le pattern que nous utilisons : un PSA hub pour les clés techniques, mappé sur le hub de la business key.
La plateforme d'automatisation de data warehouse à laquelle les équipes data font confiance
Cela vous semble familier ?
- La table des commandes ne porte que l'identifiant client interne au système, et le numéro de client se trouve dans une autre table.
- Chaque source a reçu son propre hub client, et les données n'ont jamais été réunies.
- Les jointures du staging vont chercher les business keys dans la source, et plus personne ne peut prouver ce que la source a réellement livré.
Data Vault repose sur les business keys : elles sont stables, partagées entre les systèmes, et survivent aux migrations. Les difficultés commencent lorsque l’on regarde comment les systèmes sources stockent réellement les relations.
Le problème : les relations reposent sur des clés techniques
La plupart des systèmes sources conservent la business key dans l’entité qu’elle définit. La table des clients contient le numéro de client. Les relations, en revanche, utilisent les clés techniques propres au système :
| Table | Colonnes |
|---|---|
Customer |
customer_id = 10492, customer_number = CUST-9921, nom, adresse |
Order |
order_id = 884102, order_number = SO-1018, customer_id = 10492 |
La commande ne connaît son client que sous la forme 10492. Pour la relier au hub client, dont la
clé est CUST-9921, il faut traduire l’une en l’autre.
En termes de modélisation classique : la source utilise des clés de substitution pour ses clés étrangères, alors que Data Vault attend la clé naturelle. Toute la question est de savoir où cette traduction a lieu.
Quatre façons de résoudre le problème
| Approche | Fonctionnement | L’inconvénient |
|---|---|---|
| 1. Un vault source par système | Des hubs distincts pour les clients du CRM et ceux de la facturation, dont la clé est l’identifiant technique | Techniquement faisable, mais les données ne sont jamais intégrées |
| 2. Des API sources avec business keys | Demander à chaque source de livrer chaque relation avec des business keys | Très appréciable quand cela arrive, ce qui est rare |
| 3a. Vos propres lookups pendant le staging | Remplacer les clés techniques par des business keys en interrogeant la source pendant le staging | Cela fonctionne et vous en gardez la maîtrise, mais les données sont modifiées avant d’être écrites, elles ne sont donc plus auditables, et les lookups font peser une charge sur les systèmes de production, où elle n’a pas sa place |
| 3b. Des lookups après le staging | Remplacer les clés techniques à l’aide de jointures après le staging, soit sur les tables de staging, soit sur le vault | Les jointures sur les tables de staging empêchent le chargement delta, car elles ont besoin des tables complètes. Les jointures sur le vault fonctionnent, mais les données sont tout de même modifiées avant d’être chargées |
| 4. Des PSA hubs | Charger les clés techniques dans leur propre hub et les mapper sur le hub de la business key | Une jointure générée de plus lors des requêtes. Un chargement Business Vault peut la rendre inutile. |
Le pattern que nous utilisons : les PSA hubs
Un PSA hub est un hub destiné aux clés techniques des systèmes sources. PSA signifie persistent staging area, mais pas au sens où on l’entend dans les data lakes, c’est-à-dire une copie à plat des tables sources : celle-ci est déjà au format vault, avec des hubs et des links, et des satellites là où ils sont nécessaires. Dans l’exemple ci-dessous, la PSA ne contient aucun attribut, seulement les relations techniques : les données descriptives se trouvent sur le hub de la business key.
Chaque concept reçoit deux hubs, jamais un par système source :
- Le PSA hub contient les clés techniques de tous les systèmes, chacune avec son
Business Key Prefix :
CRM|10492,ERP|80012. - Le hub du Raw Vault contient les business keys sans préfixe :
CUST-9921.
Le chargement ne nécessite alors plus aucune traduction :
- Les transactions sont chargées telles qu’elles sont livrées. La commande
884102est reliée au clientCRM|10492par un link entre le PSA hub commande et le PSA hub client, avec les clés techniques exactement telles que la source les détient. - Les enregistrements de référence assurent le mapping. L’enregistrement client porte à la fois
10492etCUST-9921: il relie donc la clé de la PSA à la business key, selon une relation n:1. Les clés techniques de plusieurs systèmes peuvent désigner le même client. - Les satellites vont sur le hub de la business key. Le nom et l’adresse du client décrivent
CUST-9921, quel que soit le système qui les a livrés.
Le même pattern se répète pour chaque concept : commandes, produits, contrats.
Les requêtes : un chemin, et un raccourci
Pour restituer les commandes avec leur client intégré, la requête va de la commande au PSA hub commande, suit la relation technique jusqu’au PSA hub client, puis rejoint le client :
Order → Order PSA → Customer PSA → Customer
C’est le chemin brut, entièrement traçable. Là où les requêtes doivent être plus rapides, vous configurez un chargement Business Vault qui crée un link d’exploration : il résout le chemin une fois pour toutes et stocke la relation directe entre la commande et le client. Les rapports lisent le chemin court ; le chemin long reste la piste d’audit.
Ce que vous y gagnez
- Rien n’est modifié avant d’être écrit. Les clés techniques sont chargées telles que la source les a livrées, si bien que chaque ligne reste auditable.
- Aucun lookup sur les systèmes de production. La traduction a lieu dans l’entrepôt.
- Des écritures rapides. Le chargement ne nécessite aucun lookup, chaque source se charge donc aussi vite qu’elle livre, et le link d’exploration est créé ensuite de manière asynchrone.
- Une restitution intégrée. Chaque client apparaît une seule fois, identifié par sa business key, avec les transactions de tous les systèmes qui lui sont rattachées.
- Les migrations restent circonscrites. Lorsqu’un système source est remplacé, ses nouvelles clés techniques sont mappées sur les mêmes business keys, et l’historique concorde toujours.
Ce qui change avec Datavault Builder
Datavault Builder prend en charge la PSA, le Raw Vault et le Business Vault, et les trois forment un seul modèle intégré. Chaque couche peut être développée par étapes agiles, au fur et à mesure des besoins : commencez par les PSA hubs, ajoutez le mapping vers les business keys, configurez un link d’exploration là où une requête le demande.
Le Business Key Prefix qui distingue CRM|10492 de ERP|10492 fait partie du modèle, et les hubs,
links et chargements du pattern sont générés comme tous les autres. La décision de modélisation
vous revient : quel concept, quelle business key, et où un link d’exploration en vaut la peine.
Voyez-le fonctionner sur l'une de vos sources
Réservez une démo gratuite et apportez le connecteur qui vous coûte le plus cher, en argent ou en temps.
Trois étapes pour passer des clés techniques aux business keys
-
Charger le Raw Vault comme d’habitude
Les hubs de business keys et leurs satellites, chargés à partir des enregistrements de référence exactement comme le décrit la littérature.
-
Ajouter des PSA hubs pour les clés techniques
Les PSA hubs contiennent les clés techniques avec leur Business Key Prefix, et les relations entre eux reposent sur ces clés.
-
Raccourcir le chemin si cela en vaut la peine
Là où une requête a réellement besoin de rapidité, un link d’exploration stocke une fois pour toutes la relation directe.
Comment Datavault Builder supprime les frictions de l'ingestion
-
L'ingestion est intégrée
Chargements batch, delta et CDC depuis les bases de données, les fichiers, les API REST, les sources NoSQL et Python, les flux comme Kafka arrivant en micro-batches. La même plateforme qui génère le warehouse, sans seconde facture.
-
Votre schéma, pas celui du fournisseur
Les tables source sont mappées vers un modèle Data Vault 2.0 que vous avez conçu. Une nouvelle colonne ou une table renommée change un mapping, pas une chaîne de scripts post-chargement.
-
Seuls les deltas circulent
Les Hubs, Links et Satellites chargent ce qui a changé. Les rechargements complets restent en staging au lieu d’être retraités en aval chaque nuit.
-
L'historique est conservé par conception
Chaque changement est conservé tel qu’il arrive, donc le reporting historique fonctionne même là où la source écrase ses propres lignes.
-
Du code que vous n'écrivez jamais
Le chargement, l’historisation et la traçabilité sont générés depuis le modèle en temps réel et s’exécutent nativement sur Snowflake, Databricks, BigQuery, SQL Server, Fabric, Oracle ou PostgreSQL.
-
Une plateforme, jusqu'à neuf outils en moins
Modélisation, ETL, CI/CD, documentation et traçabilité au même endroit. C’est ce qui rend possible les 14,7 minutes entre le besoin et la production.
Reconnu par BARC dans The Data Fabric Survey 26
Rencontrez notre expert
Vingt minutes avec notre Sales Director et une réponse honnête sur l’adéquation avec votre stack.
Matt Collett
Sales Director
Parfait, choisissez un créneau qui vous convient :
Les autres problèmes traités par cette série
-
Qu'est-ce qu'une business key dans Data Vault ?
Une business key est l’identifiant que vos collaborateurs et vos clients utilisent réellement : le numéro de client, le numéro de facture, le numéro de contrat. Elle est stable, elle est partagée entre les systèmes, et c’est sur elle que repose chaque hub d’un Data Vault.
-
Qu'est-ce qu'un satellite dans Data Vault ?
Un satellite contient tout ce qui décrit un hub : noms, statuts, montants, ainsi que chacune de leurs modifications, ajoutées sans jamais être mises à jour. C’est une Slowly Changing Dimension de type 2 sans UPDATE, avec une piste d’audit complète intégrée.
-
Qu'est-ce qu'un link dans Data Vault ?
Un link enregistre une relation entre des business keys : cette commande appartient à ce client. Datavault Builder couvre le link Data Vault classique et y ajoute un link de transaction ancré sur un grain hub, qui fixe la granularité d’une transaction et permet de relier les transactions entre elles.
-
Qu'est-ce qu'un hub dans Data Vault ?
Un hub représente un concept métier central, comme le client, le produit ou le compte, sous la forme de la liste de ses clés : toutes celles que l’entrepôt a jamais reçues, chacune une seule fois. Il stocke l’identité, pas l’état, et c’est cette sobriété qui en fait le point où les silos des systèmes sources disparaissent.
Questions et réponses
- Dan Linstedt. Il a développé la méthode dans les années 1990 et l’a publiée vers 2000. Data Vault 2.0, qui ajoute au modèle les hash keys, une méthodologie et une architecture, a suivi en 2013.
- L’ouvrage de référence est Building a Scalable Data Warehouse with Data Vault 2.0 de Dan Linstedt et Michael Olschimke (Morgan Kaufmann, 2015).
- Non. Bill Inmon considère Data Vault comme une évolution de sa vision de l’entrepôt de données d’entreprise en troisième forme normale, et non comme une approche concurrente.
- Non. Une couche de restitution dimensionnelle fait souvent partie d’une implémentation Data Vault : le vault conserve l’historique intégré, et les schémas en étoile sont construits au-dessus pour le reporting. Le même vault peut aussi fournir des tables plates ou un Unified Star Schema.
- Avec l’automatisation, une vue en troisième forme normale au-dessus d’un Data Vault peut être générée de manière entièrement déterministe. Le vault contient les données une seule fois, et la couche 3FN est dérivée du modèle. Comment cela fonctionne.
- S’y lancer sans automatisation. Data Vault repose sur un petit nombre de patterns stricts et répétitifs : c’est précisément ce qui le rend fastidieux et source d’erreurs quand on l’écrit à la main, et simple à générer. C’est pourquoi il vaut mieux utiliser Datavault Builder.
- Oui. Répartir les clés, les relations et l’historique entre hubs, links et satellites produit plus de tables qu’un modèle normalisé ou dimensionnel. C’est pourquoi la couche physique doit être masquée par une approche pilotée par le modèle comme Datavault Builder : vous travaillez sur le modèle métier, et les tables sont générées.
- Demandez une démo et voyez un Data Vault construit sur vos propres sources, ou commandez un environnement de formation pour l’essayer vous-même.
- Ici. Datavault Builder est une solution d’automatisation Data Vault : consultez les tarifs ou demandez une démo.
- Datavault Builder est concédé sous licence annuelle d’utilisation. Des licences perpétuelles sont disponibles sur demande. Les éditions et leur contenu figurent sur la page des tarifs.