Une idée reçue persiste autour du Data Vault : il ne serait applicable que sur des bases relationnelles classiques. Dès que l’on parle de Hadoop, de MongoDB ou plus largement de technologies NoSQL, le Data Vault serait jugé inadapté, trop relationnel ou trop normalisé.
Cette vision repose sur une confusion fondamentale.
Le Data Vault est avant tout un modèle conceptuel et logique, pas un schéma physique figé. Comme toute modélisation, qu’il s’agisse de 3NF, d’un modèle en étoile ou d’un modèle snowflake, il doit être adapté au moteur de stockage choisi.
Un principe clé : séparer le “quoi” du “comment”
Le Data Vault définit :
- ce que l’on modélise : identités, relations, attributs historisés ;
- comment on structure conceptuellement la donnée face au changement.
Il ne dicte pas :
- le type d’index,
- le mode de partitionnement,
- le niveau de dénormalisation,
- ni même l’existence de tables au sens relationnel.
👉 Confondre modèle Data Vault et implémentation relationnelle est une erreur de perspective.
Data Vault = modélisation conceptuelle transverse
Au niveau conceptuel, le Data Vault repose sur des invariants :
- les Hubs pour l’identification métier,
- les Links pour les relations,
- les Satellites pour les attributs et l’historique.
Ces concepts existent indépendamment du moteur physique :
- relationnel : PostgreSQL, Oracle, SQL Server ;
- distribué : Hive, Spark, BigQuery ;
- document : MongoDB ;
- colonne : HBase ;
- ou cloud-native.
👉 Ce sont les patterns d’implémentation qui changent, pas les principes.
Implémenter un Data Vault sur Hadoop / Big Data
Sur des plateformes Hadoop ou Spark :
- les Hubs, Links et Satellites sont souvent implémentés comme des tables distribuées ;
- le partitionnement, par date, source ou domaine, devient central ;
- les jointures sont maîtrisées via le design : batch, ELT, matérialisations intermédiaires.
Des adaptations courantes consistent à utiliser :
- le regroupement de Satellites par domaine ou fréquence de changement ;
- l’usage intensif du partitionnement temporel ;
- l’optimisation des accès via des formats colonne comme Parquet ou ORC.
👉 Le Data Vault y est souvent plus naturel que sur des bases relationnelles classiques, du fait de son orientation historisée et incrémentale.
Implémenter un Data Vault sur MongoDB ou bases document
Dans un contexte NoSQL document :
- un Hub peut devenir un document racine ;
- ses Satellites peuvent être :
- des sous-documents historisés ;
- ou des collections séparées selon les volumes.
- les Links peuvent être matérialisés par des références explicites ou des collections relationnelles.
Des choix sont faits en fonction :
- des volumes,
- des patterns d’accès,
- des contraintes de performance.
👉 Comme pour un modèle en étoile sur MongoDB, une part de dénormalisation est assumée, sans renier le modèle conceptuel.
Exactement comme pour la 3NF ou l’étoile
Il est important de rappeler une évidence souvent oubliée :
- une modélisation 3NF n’est jamais implémentée “pure” en production ;
- un modèle en étoile est presque toujours dénormalisé, indexé et partitionné.
Le Data Vault ne fait pas exception.
👉 Toute modélisation est :
- conceptuelle et logique en amont ;
- physique et pragmatique en aval.
Ce n’est pas une faiblesse, c’est une règle d’architecture.
Ce qui ne change jamais, quel que soit le moteur
Quel que soit le stockage, un Data Vault réussi conserve :
- la séparation identification / relation / attributs ;
- l’historisation explicite ;
- la traçabilité par source ;
- la capacité à absorber le changement.
👉 Ce sont ces propriétés qui font la valeur du Data Vault, pas le nombre de tables SQL.
Le vrai risque : adapter le modèle… ou le renier
Adapter le Data Vault à un moteur NoSQL est sain.
En revanche, renoncer à ses principes au nom de la performance ou de la “simplicité” conduit souvent à :
- une perte de traçabilité ;
- une dette data difficile à résorber ;
- des modèles impossibles à faire évoluer.
👉 L’enjeu n’est pas “Data Vault ou NoSQL”.
👉 L’enjeu est plutôt : “comment implémenter intelligemment le Data Vault sur un moteur donné ?”
Conclusion
Le Data Vault 2.0 n’est ni relationnel, ni NoSQL par nature.
Il est conceptuel, agnostique du stockage et orienté long terme.
Comme toute modélisation sérieuse, il nécessite :
- des adaptations physiques ;
- des compromis techniques ;
- des optimisations locales.
👉 La vraie question n’est donc pas : “le Data Vault est-il compatible avec Hadoop ou MongoDB ?”
👉 Mais plutôt : “avons-nous la maturité pour distinguer modèle conceptuel et implémentation physique ?”