La plupart des concepteurs de bases de données partent soit d'un modèle relationnel normalisé, soit d'un schéma en étoile (modèle dimensionnel). Pour de nombreuses applications, ces approches fonctionnent parfaitement. Toutefois, les organisations gérant de vastes entrepôts de données alimentés par de multiples systèmes sources se heurtent souvent à des obstacles : le schéma devient fragile, le suivi des données historiques s'avère complexe et l'intégration d'une nouvelle source de données implique de modifier des tables déjà en production. Data Vault 2.0 a été spécialement conçu pour résoudre ces problèmes. Cet article explique en quoi il consiste, comment il fonctionne et comment l'utiliser dans Navicat Data Modeler 4.
Qu'est-ce que Data Vault 2.0 ?
Data Vault 2.0 est une méthodologie de modélisation des données développée par Dan Linstedt, initialement présentée au début des années 2000 et considérablement élargie vers 2013. Alors que la première version se concentrait exclusivement sur les techniques de modélisation, la version 2.0 a élargi son champ d'application pour englober les modèles d'architecture, la méthodologie et l'intégration avec les pratiques modernes, notamment le développement agile, le cloud computing et l'automatisation.
Le principe fondamental est simple : au lieu de regrouper l'identité, les relations et les attributs descriptifs dans une seule table (comme le fait une table de dimension traditionnelle), Data Vault 2.0 les sépare en trois types de structures distincts. C'est cette séparation qui confère à la méthodologie sa résilience et sa flexibilité.
Les trois composants fondamentaux
Les « hubs » représentent des concepts métier fondamentaux et ne stockent rien d'autre que des clés métier, c'est-à-dire les identifiants naturels réellement utilisés par votre organisation, tels qu'un identifiant client, un code produit ou un numéro de commande. Ainsi, un hub dédié aux clients ne contiendrait que des identifiants clients, et rien d’autre. Les hubs sont conçus pour être stables. À ce titre, ils ne changent pas lorsque les systèmes sources évoluent, et ils ne stockent rien qui puisse devenir obsolète.
Les liens (links) capturent les relations entre les hubs. Si un client passe une commande, une table de liens enregistre cette relation en conservant les clés de hachage provenant du hub client et du hub commande. Les liens sont également immuables et fonctionnent uniquement en mode ajout (append-only) : une fois enregistrée, une relation est conservée définitivement. Ils constituent ainsi une piste d'audit fiable de toutes les associations ayant existé entre les entités métier.
Les « satellites » sont les éléments qui contiennent les attributs descriptifs et l'historique. Un satellite rattaché à un hub client peut stocker le nom, l'adresse et les coordonnées du client, ainsi que des horodatages indiquant le moment où chaque version de ces attributs a été chargée. Comme les satellites sont distincts des hubs, il est possible d'associer plusieurs satellites à un même hub — par exemple, un par système source ou un par fréquence de modification — sans modifier le hub lui-même. C'est cette caractéristique qui confère au modèle Data Vault une grande flexibilité lorsqu'il s'agit d'intégrer une nouvelle source de données.
Quand l'utiliser (et quand l'éviter)
La complexité de Data Vault 2.0 se justifie lorsque vous construisez un entrepôt de données d'entreprise devant intégrer de multiples systèmes sources, gérer des modifications fréquentes de schéma et conserver une piste d'audit complète retraçant l'arrivée et l'évolution des données au fil du temps. Les secteurs réglementés en particulier – tels que la finance, la santé et l’assurance – tirent profit de la traçabilité inhérente au modèle « hub-link-satellite », car chaque donnée comporte systématiquement son horodatage de chargement et son système source.
Il est moins adapté aux bases de données analytiques plus simples, aux petites équipes disposant de ressources de modélisation limitées, ou aux applications où la simplicité des requêtes et les performances au niveau de la couche d’intégration priment sur la flexibilité. Data Vault est une couche d’intégration, et non une couche de consommation. Par conséquent, les analystes doivent interroger une couche de présentation (généralement un schéma en étoile ou un *data mart*) construite au-dessus de cette structure, plutôt que le *vault* lui-même. Les équipes qui négligent cette distinction et interrogent directement le *vault* trouvent souvent les jointures entre les nombreuses tables trop complexes à gérer.
Modélisation Data Vault 2.0 avec Navicat Data Modeler
La prise en charge de Data Vault 2.0 a été introduite dans Navicat Data Modeler 4, à la fois en tant que produit autonome et dans le cadre de Navicat 17.2, en mars 2025. Elle s'ajoute à la prise en charge existante des méthodologies de modélisation relationnelle et dimensionnelle, ce qui vous permet d'utiliser ces trois approches au sein d'une même application.
Lorsque vous sélectionnez Data Vault 2.0 comme méthode de modélisation, le canevas et les types d’objets sont adaptés à cette méthodologie. Vous manipulez nativement les concepts de « hub », de « link » et de « satellite » au lieu de les simuler à l'aide d'objets de table génériques ; cela garantit une plus grande clarté lors de la phase de conception et permet de générer un code DDL précis au moment du déploiement. L'environnement visuel offre une vue claire de la structure en étoile (« hub-and-spoke ») de votre modèle, ce qui facilite la compréhension des liens entre les entités et de l’emplacement où les nouveaux systèmes sources doivent être rattachés.
L'éventail complet de fonctionnalités de Navicat Data Modeler complète parfaitement le flux de travail Data Vault. Une fois le modèle physique prêt, la commande "Synchroniser avec la base de données" compare le modèle à une base de données active et génère un script de déploiement pour les différences constatées ; ce qui s'intègre naturellement dans le mode de développement incrémental par sprints prôné par Data Vault 2.0. La fonctionnalité « Exporter le modèle vers un fichier SQL/script » génère l’intégralité du DDL pour le schéma modélisé, prêt à être intégré au contrôle de version ou transmis à un outil de migration. De plus, comme Navicat Data Modeler prend en charge un large éventail de bases de données — notamment MySQL, PostgreSQL, SQL Server, Oracle, MariaDB, MongoDB, SQLite et Snowflake — le même processus de modélisation s'applique quel que soit le moteur sous-jacent de votre entrepôt de données.
Conclusion
Data Vault 2.0 ne convient pas à tous les projets. Toutefois, pour les organisations qui développent des entrepôts de données d’entreprise devant s’adapter en douceur aux changements et maintenir une piste d’audit fiable, il offre un niveau de résilience que les approches traditionnelles peinent à égaler. La méthodologie nécessite un certain temps d’apprentissage, mais ses principes sous-jacents — séparer l’identité des relations, séparer les relations de la description et rendre tout auditable — apparaissent logiques une fois que l’on a saisi le principe. Grâce à la prise en charge native de Data Vault 2.0 introduite dans Navicat Data Modeler 4, les équipes disposent désormais d’un environnement de modélisation visuel qui s’exprime directement dans le langage de cette méthodologie, réduisant ainsi les frictions entre la conception et la mise en œuvre.
