Modélisation Data Vault

La modélisation Data Vault est une modélisation de données (pour les bases de données relationnelles) conçue pour historiser des données provenant de plusieurs sources de données. Comme toute modélisation, elle est utilisée pour l'interrogation de données (historiques) et est particulièrement adaptée à l'audit de données, à la traçabilité de la donnée et à la résistance au changement de la structure de données. Cette modélisation est une alternative aux modélisations en forme normale.

Plusieurs principes ont présidé à son élaboration. En premier, c'est le souci de retracer l'origine de chaque donnée. En second, c'est le souci de s'abstraire du dilemme de la donnée "brute" ou de la donnée "travaillée" en facilitant l'intégration de la donnée brute (tout découle de cette dernière). Ensuite, c'est le souci d'apporter une structure de donnée résistante au changement et de minimiser l'intégration d'une nouvelle source de données dans une structure de données existante. Enfin, c'est le souci d'apporter une modélisation qui permet le parallélisme au niveau du chargement des données. Ce dernier point fait suite à l'augmentation du volume de données à intégrer dans les systèmes d'informatique décisionnelle.

Cette modélisation porte aussi le nom (rarement utilisé) "Common Foundational Integration Modelling Architecture" qui souligne le focus sur l'intégration de la donnée brute.

Historique

Dan Linstedt a conçu la modélisation Data Vault en 1990, l'a placé dans le domaine public en 2000 et a publié les principes de modélisation (sous la forme de 5 articles) en 2002 sur le site "The Data Administration Newsletter". Dan Linstedt s'est inspiré du réseau neuronal : le noyau neuronal est le "hub", la dendrite neuronale est le "satellite" et la synapse (le lien entre les neurones) est le "link".

Notions de base

Rappelons qu'une structure de base de données est composée d'entités (exemple : clients), d'attributs (exemple : coordonnées clients) et de liens entre entités (exemple : liens entre clients et vendeurs). Et on sait que les "clés" des entités (exemple : code client) évoluent lentement alors que les attributs (exemple : adresse client) évoluent plus rapidement. Cet écart dans la fréquence de changement a conditionné la conception de la modélisation Data Vault : la clé est isolée dans un "hub" (noyau) et les autres attributs sont exportés dans plusieurs "satellites" (dendrites).

Rappelons que dans une modélisation traditionnelle, tous les codes et les attributs cohabitent. Cela a deux effets secondaires. Si une entité existante s'enrichit de nouveaux attributs, l'entité doit être restructurée. Et si une structure de données s'enrichit de nouvelles entités, la structure de données existante doit être restructurée. Dans bon nombre de projets d'informatique décisionnelle, ce travail constant de restructuration peu devenir (très) coûteux.

Hub

Un hub ne contient que des clés (exemple : codes clients). On peut compléter chaque clé avec une ou plusieurs métadonnées permettant de retracer son origine (exemple : nom du système informatique d'origine), sa date d'extraction, ses mises à jour, etc. Un hub ne stocke aucun attribut (exemple : nom du client). Enfin, chaque clé est dotée d'une clé de substitution ("surrogate key", en anglais) pour éviter les problèmes de performance liés aux clés complexes.

Un hub ne devrait pas contenir de clé multi-organisations (exemple : concaténation de codes clients), à moins que ce type de clé soit généralisé dans les systèmes informatiques d'une organisation.

Un hub devrait avoir au moins un satellite.

Enfin, les hubs ne devraient contenir que des clés naturelles, c'est-à-dire des clés qui identifient à coup sûr les entités.

Satellite

On peut considérer le hub comme le parent et le satellite comme l'enfant. Un parent peut avoir plusieurs enfants. Exemple : le hub "client" peut avoir les satellites "système source A", "système source B", etc. On peut compléter chaque attribut avec une ou plusieurs métadonnées permettant de retracer sa date d'extraction, ses mises à jour, etc.

Les satellites peuvent être définis par systèmes source mais aussi par fréquence de changement. Par exemple, en fonction de leur fréquence de changement, on peut ventiler les attributs d'un même système source dans plusieurs satellites. Cette pratique minimisera encore plus le travail de restructuration de données.

Il n'y a pas de "link" entre un satellite et son hub car un enfant n'est pas partagé par plusieurs parents (dans le système neural, une dendrite n'est pas partagée par plusieurs neurones). L'enfant-satellite stocke la clé de substitution du parent-hub.

Le lien relie deux hubs (voire plus). On peut compléter chaque lien avec une ou plusieurs métadonnées permettant de retracer sa création, ses mises à jour, etc. Le lien stocke les clés de substitution des hubs. Dans une modélisation traditionnelle, le lien est une relation "plusieurs-à-plusieurs" ("many-to-many", en anglais) entre les entités (exemple : un client est démarché par plusieurs vendeurs, un vendeur démarche plusieurs clients). Dans la modélisation Data Vault, les hubs-satellites (neurones) sont toujours reliés par des liens (synapses) quelle que soit la cardinalité de la relation (plusieurs-à-plusieurs ou pas).

Un lien peut avoir des satellites.

Un lien pourrait être lié à un autre lien mais cette pratique pénaliserait le parallélisme au niveau du chargement des données. La création d'un second lien entre les hubs concernés est recommandée.

Fichier de référence

Les données de référence ne manquent pas dans une organisation (géographie, codification métier, etc.). Tout fichier de référence peut être intégré dans un modèle Data Vault.

Chargement de données

La pratique du chargement de données dans un modèle Data Vault est détaillée dans le 5e article de Dan Linstedt sur le site "The Data Administration Newsletter". Cette pratique s'adapte aux outils (dits "ETL") de chargement utilisés en informatique décisionnelle.

Consultation de données

La modélisation Data Vault est une modélisation de base de données conçue pour historiser des données. Elle n'a pas été conçue pour faciliter la consultation de données par des utilisateurs finaux. Car lorsqu'on multiplie des satellites et des liens pour gagner de la souplesse de chargement, on perd inévitablement de la performance lorsque vient le temps d'interroger les données.

Cela dit, dans les systèmes d'informatique décisionnelle, les outils utilisateur (produits par l'industrie du logiciel ou développé en interne) interrogent des modèles de données dits "dimensionnels" créés à partir d'autres modélisations. La création de modèles dimensionnels à partir de la modélisation Data Vault n'est pas plus compliquée que la création à partir d'autres modélisations. Par contre, l'inverse est complexe (du fait de la structure très modulaire d'un modèle Data Vault).

Outils

Des outils sont déjà disponibles pour automatiser des tâches de modélisation Data Vault. Évidemment, le niveau de support varie énormément d'un outil à l'autre. On peut citer :

Références
  • Ronald Damhof, Lidwine van As, « The next generation EDW – Letting go of the idea of a single version of the truth », Database Magazine (DB/M), Array Publications B.V.,‎ (lire en ligne)
  • Daniel Linstedt, Kent Graziano et Hans Hultgren, The New Business Supermodel. The Business of Data Vault modelling, 2nd edition, Lulu.com, , 81 p. (ISBN 978-1-4357-1914-9, lire en ligne)
  • Thomas C. Hammergren et Alan R. Simon, Data Warehousing for Dummies, 2nd edition, John Wiley & Sons, (ISBN 978-0-470-40747-9)
  • Dan Linstedt, Super Charge your Data Warehouse, Dan Linstedt, (ISBN 978-0-9866757-1-3)
  • Portail de l’informatique
Cet article est issu de Wikipedia. Le texte est sous licence Creative Commons - Attribution - Partage dans les Mêmes. Des conditions supplémentaires peuvent s'appliquer aux fichiers multimédias.