Partie I - Du modèle relationnel aux trois grandes écoles du Data Warehouse
Il existe une manière assez réductrice de raconter l'histoire de la modélisation des données.
Elle consiste à présenter successivement quelques techniques : le modèle relationnel, la troisième forme normale, le modèle en étoile, le Data Vault, puis les architectures plus récentes. Chaque méthode disposerait de ses avantages, de ses inconvénients et de ses cas d'usage. L'architecte n'aurait ensuite qu'à choisir dans cette boîte à outils la technique correspondant le mieux à son projet.
Cette lecture est pratique. Mais elle passe à côté de l'essentiel.
L'histoire de la modélisation des données est avant tout une histoire de problèmes successifs.
Comment représenter l'information indépendamment de son stockage physique ?
Comment intégrer des dizaines de systèmes qui décrivent différemment les mêmes objets ?
Comment rendre cette information compréhensible pour l'analyste ?
Comment conserver son histoire ?
Comment absorber le changement sans reconstruire continuellement le système ?
Comment distinguer ce que la source nous a effectivement transmis de ce que l'entreprise en a ensuite déduit ?
Et, plus profondément encore : quelle partie de la réalité voulons-nous préserver lorsque nous transformons l'activité d'une organisation en données ?
Les grandes écoles de modélisation donnent des réponses différentes à cette question.
Codd cherche d'abord à préserver la cohérence logique et l'indépendance de la donnée vis-à-vis de sa représentation physique.
Inmon cherche à construire une représentation intégrée de l'entreprise.
Kimball organise la donnée autour des processus métier et de leur analyse.
Linstedt cherche à préserver les identités, les relations, la provenance et l'histoire des changements.
Ces approches sont régulièrement présentées comme concurrentes. Elles le sont parfois. Mais les opposer systématiquement masque quelque chose de beaucoup plus intéressant : elles ne cherchent pas exactement à optimiser la même chose.
C'est précisément ce qui explique pourquoi, plus d'un demi-siècle après les travaux fondateurs du modèle relationnel, leurs principes continuent de réapparaître dans les architectures Snowflake, Fabric, Databricks, dbt ou Lakehouse sous des formes nouvelles.
Pour comprendre l'architecture Data moderne, il est donc utile de revenir là où tout commence.
1. Avant le Data Warehouse : Codd et l'indépendance de la donnée
En 1970, Edgar F. Codd, chercheur chez IBM, publie dans Communications of the ACM son article devenu historique : A Relational Model of Data for Large Shared Data Banks.
Le texte ne parle évidemment ni de Data Warehouse, ni de Data Lake, ni de modèle en étoile.
Mais il contient une idée fondamentale qui traversera toute l'histoire de la Data : la représentation logique de l'information doit autant que possible être indépendante de son organisation physique dans la machine.
Codd cherche notamment à dépasser les modèles hiérarchiques et réseaux alors utilisés. Il introduit une représentation fondée sur des relations n-aires et aborde explicitement les questions de redondance et de cohérence.
Cela paraît presque banal aujourd'hui.
Ça ne l'était absolument pas.
Codd contribue à établir une séparation conceptuelle entre deux choses que l'informatique avait tendance à confondre :
ce que signifie la donnée et la manière dont la machine la stocke.
Cette distinction va avoir des conséquences considérables.
Prenons un univers extrêmement simple :
CLIENT
CONTRAT
PRODUIT
AGENCE
VENTE
Le monde réel contient des clients. Ces clients souscrivent des contrats. Ces contrats concernent des produits. Des ventes sont réalisées par certaines agences.
La question du modélisateur devient :
Quelles relations logiques existent entre ces objets, indépendamment de la façon dont ils seront physiquement stockés ?
La normalisation prolonge cette logique.
Si l'adresse d'un client est répétée dans cinquante lignes de transactions, nous introduisons de la redondance. Si elle change dans quarante-neuf lignes mais pas dans la cinquantième, nous introduisons potentiellement une incohérence.
Le modèle relationnel et les formes normales cherchent notamment à maîtriser ce genre de problèmes.
C'est une révolution conceptuelle dont nous sous-estimons parfois l'importance parce qu'elle fait désormais partie du paysage.
Mais elle pose bientôt un nouveau problème.
Un excellent modèle pour maintenir une information cohérente n'est pas nécessairement un excellent modèle pour l'analyser.
C'est là que commence véritablement notre histoire.
2. Le problème que les systèmes transactionnels ne résolvaient pas
Une base opérationnelle répond admirablement à certaines questions :
Quel est le contrat du client 84721 ?
Quel est son statut actuel ?
Cette commande a-t-elle été payée ?
Quelle adresse doit être utilisée pour la livraison ?
Mais le management commence progressivement à poser d'autres questions :
Comment le chiffre d'affaires a-t-il évolué sur cinq ans ?
Quels produits progressent selon les régions ?
Comment le portefeuille client s'est-il transformé ?
Quel était le statut de ces clients au moment où les transactions ont été réalisées ?
Quelle était notre exposition à tel risque au 31 décembre il y a trois ans ?
Nous ne sommes plus dans le même problème informatique.
Le système opérationnel cherche généralement à connaître l'état nécessaire à l'exécution du processus actuel.
Le système décisionnel doit être capable d'expliquer l'activité dans le temps.
C'est une différence fondamentale.
L'entreprise possède par ailleurs rarement un seul système.
Elle possède un CRM qui connaît un CUSTOMER_ID, un ERP qui connaît un CLIENT_NUMBER, une plateforme e-commerce qui utilise un USER_ID, une application historique qui identifie la même personne autrement.
Et chacun peut posséder sa propre définition du client, du produit, du contrat ou du chiffre d'affaires.
Le problème n'est donc plus seulement :
Comment stocker les données ?
Il devient :
Comment construire une mémoire analytique cohérente de l'entreprise à partir de systèmes qui n'ont jamais été conçus pour raconter ensemble la même histoire ?
C'est sur ce terrain que Bill Inmon va construire une première grande réponse.
3. Bill Inmon : représenter l'entreprise avant de représenter les rapports
La définition historique associée à Bill Inmon décrit le Data Warehouse comme une collection de données orientée sujet, intégrée, historisée dans le temps et non volatile, destinée à soutenir la prise de décision. Cette définition reste l'une des plus citées dans la littérature consacrée au Data Warehousing.
Chacun de ces termes mérite attention.
Subject-oriented — orienté sujet
Les systèmes opérationnels sont généralement organisés autour d'applications ou de processus techniques.
Le Data Warehouse réorganise l'information autour de grands sujets de l'entreprise :
CLIENT
PRODUIT
CONTRAT
FOURNISSEUR
VENTE
On commence donc déjà à s'éloigner de l'organisation des applications sources.
Integrated — intégré
C'est probablement le mot le plus important.
Supposons trois systèmes :
CRM → CUSTOMER_ID
ERP → CLIENT_CODE
WEB → USER_ID
Si ces trois identifiants peuvent désigner la même personne, le Data Warehouse doit résoudre cette hétérogénéité.
Même problème pour :
M / F
Male / Female
1 / 2
H / F
ou :
EUR
€
EURO
978
L'intégration ne consiste pas simplement à déplacer des données.
Elle consiste à réconcilier des représentations différentes d'une même réalité métier.
Time-variant — historisé
Le temps devient une dimension fondamentale.
Un système opérationnel peut avoir besoin de connaître l'adresse actuelle d'un client.
Le Data Warehouse peut avoir besoin de savoir :
Adresse A : 2019 → 2022
Adresse B : 2022 → 2025
Adresse C : 2025 → aujourd'hui
La question n'est plus uniquement :
Quelle est l'adresse ?
mais :
Quelle était l'information pertinente à un instant donné ?
Non-volatile
Le Data Warehouse n'est pas conçu comme un système transactionnel dans lequel les enregistrements sont constamment modifiés au gré des opérations courantes.
L'histoire doit pouvoir être conservée et analysée.
4. L'architecture Inmon : intégrer d'abord, distribuer ensuite
L'approche Inmon est communément qualifiée de top-down.
Le principe architectural peut être simplifié ainsi :
SYSTÈMES SOURCES
│
▼
INTÉGRATION / ETL
│
▼
ENTERPRISE DATA WAREHOUSE
modèle intégré
atomique
3NF
│
┌─────────┼─────────┐
▼ ▼ ▼
MART A MART B MART C
│ │ │
▼ ▼ ▼
BI BI BI
Dans la Corporate Information Factory associée à Inmon, l'Enterprise Data Warehouse constitue le cœur intégré ; les Data Marts sont alimentés en aval. Les descriptions classiques de cette architecture présentent généralement le cœur EDW sous une forme normalisée, souvent en troisième forme normale, avec des marts potentiellement dimensionnels en aval.
L'ordre est important.
On ne commence pas par demander :
Quel dashboard devons-nous produire ?
On cherche d'abord à établir :
Quelle représentation cohérente de l'entreprise devons-nous construire ?
Puis cette représentation alimente différents usages.
C'est intellectuellement très puissant.
Une règle fondamentale apparaît :
intégrer une fois, consommer plusieurs fois.
Mais cette ambition a un coût.
Construire un modèle d'entreprise transversal peut être long. Les frontières métier sont difficiles à stabiliser. Les projets peuvent devenir importants avant même que les utilisateurs voient leurs premiers indicateurs.
Et surtout, un modèle fortement normalisé n'est pas nécessairement l'interface analytique la plus naturelle pour un utilisateur BI.
Ralph Kimball va attaquer précisément ce problème.
5. Ralph Kimball : partir du processus métier et de la mesure
Kimball change le point de départ.
Il ne demande pas d'abord :
Comment représenter toute l'entreprise ?
Il demande :
Quel processus métier voulons-nous analyser ?
Vente.
Commande.
Livraison.
Sinistre.
Paiement.
Appel.
Souscription.
Stock.
À partir de là, le monde analytique se divise en deux grandes familles : les mesures et leur contexte.
Kimball décrit explicitement le modèle dimensionnel comme une séparation entre les mesures — les facts — et le contexte descriptif qui les entoure — les dimensions.
Prenons une vente :
DIM_DATE
│
│
DIM_CLIENT ─── FACT_VENTE ─── DIM_PRODUIT
│
│
DIM_AGENCE
La table de faits contient par exemple :
Quantité
Montant_HT
Remise
Marge
Les dimensions répondent aux questions :
Qui ?
Quoi ?
Quand ?
Où ?
Quel produit ?
Quel segment ?
Quel canal ?
Cette représentation est extraordinairement adaptée à l'analyse.
On peut presque lire le modèle comme une phrase :
Montant des ventes par produit, par client, par agence et par période.
La structure technique épouse la question analytique.
6. Le grain : probablement l'idée la plus importante de Kimball
La méthode Kimball propose quatre décisions structurantes :
- sélectionner le processus métier ;
- déclarer le grain ;
- identifier les dimensions ;
- identifier les faits.
Le deuxième point est crucial.
Que représente exactement une ligne de la table de faits ?
Une vente ?
Une ligne de commande ?
Une ligne de commande par produit ?
Le solde d'un compte chaque fin de mois ?
Un appel reçu par un agent ?
Un événement de navigation ?
Kimball insiste fortement sur le grain : sa définition constitue le contrat du modèle, et dimensions comme faits doivent rester cohérents avec ce niveau de granularité.
Supposons :
FACT_VENTE
et déclarons :
Une ligne représente un produit vendu dans une transaction donnée.
Alors :
Date
Client
Produit
Agence
Quantité
Prix
Remise
peuvent avoir du sens à ce grain.
Mais introduire arbitrairement :
Chiffre_Affaires_Annuel_Client
dans cette même ligne devient dangereux.
Pourquoi ?
Parce que la mesure annuelle serait répétée sur chaque transaction et pourrait être agrégée incorrectement.
Le grain n'est donc pas une subtilité de modélisateur.
C'est la définition de ce que signifie une observation dans le système analytique.
7. Kimball n'est pas simplement « faire des étoiles »
Une caricature persistante consiste à résumer l'opposition ainsi :
Inmon = modèle d'entreprise
Kimball = petits Data Marts départementaux
C'est insuffisant.
Kimball propose également une logique d'intégration à l'échelle de l'entreprise : l'Enterprise Data Warehouse Bus Architecture et les conformed dimensions.
Une dimension CUSTOMER partagée par les processus Vente, Support et Livraison permet à plusieurs modèles dimensionnels de parler un langage commun.
On peut alors obtenir :
DIM_CUSTOMER
/ | \
/ | \
FACT_SALES FACT_SUPPORT FACT_DELIVERY
L'entreprise n'est plus intégrée nécessairement par un grand modèle normalisé central.
Elle peut l'être par la conformité des dimensions et des définitions utilisées entre processus métier.
Voilà la véritable différence philosophique.
Inmon cherche principalement l'intégration dans un cœur d'entreprise commun.
Kimball cherche l'intégration analytique à travers des processus métier coordonnés et des dimensions conformes.
Ce n'est pas simplement 3NF contre étoile.
C'est une différence dans l'endroit où l'on place la cohérence du système.
8. Deux philosophies, deux difficultés
À ce stade, deux réponses majeures se dessinent.
Inmon
Sources
↓
Modèle intégré de l'entreprise
↓
Data Marts
↓
Analyse
Kimball
Sources
↓
Processus métier
↓
Facts + Dimensions conformes
↓
Analyse
Inmon optimise fortement la cohérence et l'intégration centrales.
Kimball optimise fortement l'intelligibilité et l'utilisabilité analytiques.
Mais un nouveau problème apparaît progressivement.
Les entreprises grossissent.
Les sources se multiplient.
Les systèmes sont remplacés.
Les identifiants changent.
Les attributs apparaissent et disparaissent.
Les règles métier évoluent.
Les acquisitions ajoutent de nouveaux ERP et CRM.
Et les régulateurs demandent parfois de pouvoir expliquer non seulement ce que nous savons aujourd'hui, mais aussi :
D'où cette information provenait-elle ?
Quand l'avons-nous reçue ?
Qu'avait envoyé exactement le système source ?
Quelle règle métier avons-nous appliquée ensuite ?
Pouvons-nous reconstruire ce que nous savions à cette date ?
La question se déplace.
Il ne suffit plus de construire une excellente représentation de l'entreprise.
Il ne suffit plus non plus de construire une excellente représentation analytique de ses processus.
Il faut construire une architecture capable d'absorber le changement tout en préservant l'histoire et la provenance.
C'est ici qu'intervient Dan Linstedt.
9. Dan Linstedt : séparer ce qui change de ce qui ne change pas de la même manière
Data Vault introduit une idée extrêmement élégante : ne mettons pas dans une même structure des choses dont la nature et le rythme d'évolution sont différents.
Trois constructions deviennent fondamentales :
Hub
Link
Satellite
La littérature de référence consacrée au Data Vault décrit précisément cette décomposition : les Hubs portent les business keys, les Links matérialisent les relations entre ces clés et les Satellites portent les attributs descriptifs ainsi que leur histoire.
Prenons notre univers :
CLIENT
CONTRAT
PRODUIT
Nous pouvons identifier les concepts métier stables :
HUB_CLIENT
HUB_CONTRAT
HUB_PRODUIT
Les Hubs contiennent principalement les business keys permettant d'identifier ces concepts.
Puis les relations :
HUB_CLIENT
│
▼
LINK_CLIENT_CONTRAT
▲
│
HUB_CONTRAT
Et enfin les descriptions :
HUB_CLIENT
│
├── SAT_CLIENT_CRM
│
├── SAT_CLIENT_ERP
│
└── SAT_CLIENT_WEB
Le Hub répond essentiellement :
De quel objet métier parlons-nous ?
Le Link :
Quels objets sont liés ?
Le Satellite :
Que savons-nous de cet objet ou de cette relation, depuis quelle source et à quel moment ?
Les Satellites sont précisément conçus pour conserver le contexte descriptif et ses changements dans le temps.
Et cette séparation change beaucoup de choses.
10. Data Vault : préserver avant d'interpréter
Imaginons que le CRM dise :
CLIENT 874
Segment = PREMIUM
Ville = Paris
et que l'ERP fournisse :
CLIENT 874
Risk_Class = B
Country = FR
Dans un modèle classique, nous pourrions chercher rapidement à construire :
DIM_CLIENT
contenant la représentation métier consolidée du client.
Data Vault pose une question préalable :
Que nous ont réellement dit les différentes sources ?
On peut préserver séparément les informations provenant du CRM et de l'ERP.
La transformation métier peut venir ensuite.
C'est ici qu'apparaît une distinction essentielle entre Raw Data Vault et Business Vault.
Le Raw Vault vise à conserver une représentation historisée et traçable des informations intégrées avec un minimum d'interprétation métier ; le Business Vault introduit ensuite règles, calculs et structures dérivées. Les Information Marts peuvent finalement exposer des modèles dimensionnels ou d'autres structures adaptées aux consommateurs.
On obtient conceptuellement :
SOURCES
│
▼
STAGING
│
▼
RAW DATA VAULT
│
▼
BUSINESS VAULT
│
▼
INFORMATION MARTS
│
▼
BI / ANALYTICS
Et quelque chose d'intéressant apparaît immédiatement.
Kimball n'a pas nécessairement disparu.
Il peut simplement se trouver plus loin dans l'architecture.
Un Data Vault peut parfaitement alimenter un modèle dimensionnel destiné à Power BI ou à une autre couche analytique. Data Vault Alliance décrit d'ailleurs le cœur Data Vault autour des Business Keys dans les Hubs, des attributs dans les Satellites et des relations/transactions dans les Links, avec une couche dimensionnelle possible pour faciliter la consommation analytique.
Nous commençons alors à voir apparaître une conclusion beaucoup plus intéressante que le traditionnel débat :
Inmon ou Kimball ou Data Vault ?
Peut-être avons-nous mal formulé la question depuis le début.
11. Trois écoles, trois objets que l'on cherche à protéger
Nous pouvons maintenant reformuler les trois approches.
Inmon protège la cohérence de l'entreprise
Son problème central est l'intégration.
Plusieurs systèmes
↓
Une représentation intégrée
↓
Plusieurs usages
Kimball protège la signification analytique
Son unité fondamentale devient le processus et son événement mesurable.
Processus métier
↓
Grain
↓
Facts + Dimensions
↓
Analyse
Linstedt protège l'histoire et la provenance
Il sépare identité, relation et description afin que l'arrivée de nouvelles sources ou de nouveaux attributs puisse être absorbée sans remettre continuellement en cause le cœur existant.
Business Key → HUB
Relationship → LINK
Context + History → SATELLITE
Nous pouvons donc résumer leurs préoccupations dominantes ainsi :
| École | Question fondamentale |
|---|---|
| Inmon | Comment construire une représentation intégrée de l'entreprise ? |
| Kimball | Comment représenter correctement un processus pour l'analyse ? |
| Linstedt | Comment intégrer et historiser des données changeantes tout en conservant leur provenance ? |
Cette lecture permet également de comprendre pourquoi les débats comparant ces écoles tournent parfois en rond.
Elles ne définissent pas toujours la même couche du problème.
Une architecture moderne pourrait parfaitement contenir :
┌───────────────────────────────┐
│ BI / SEMANTIC │
│ approche dimensionnelle │
│ KIMBALL │
└───────────────▲───────────────┘
│
┌───────────────┴───────────────┐
│ INFORMATION MARTS │
└───────────────▲───────────────┘
│
┌───────────────┴───────────────┐
│ BUSINESS VAULT │
│ règles et dérivations │
└───────────────▲───────────────┘
│
┌───────────────┴───────────────┐
│ RAW DATA VAULT │
│ HUBS / LINKS / SATELLITES │
│ LINSTEDT │
└───────────────▲───────────────┘
│
┌───────────────┴───────────────┐
│ SOURCES MÉTIER │
└───────────────────────────────┘
On pourrait également retrouver dans d'autres organisations un cœur intégré fortement inspiré de la philosophie Inmon avant la constitution de couches de consommation dimensionnelles.
Autrement dit :
une architecture n'est pas obligée d'adhérer religieusement à une seule école.
Elle peut utiliser plusieurs philosophies à différents endroits parce que ces endroits ne répondent pas aux mêmes contraintes.
Et cette constatation nous conduit à une partie beaucoup moins connue de l'histoire.
Car Inmon, Kimball et Linstedt ne sont pas seuls.
À côté de ces trois grandes traditions existent des approches beaucoup plus discrètes, parfois techniquement fascinantes : Anchor Modeling, modèles temporels et bitemporels, modélisation événementielle, modèles sémantiques, ontologies et Knowledge Graphs.
Certaines poussent l'historisation beaucoup plus loin.
D'autres considèrent que le véritable objet à conserver n'est pas l'état d'une entité mais l'événement qui l'a fait changer.
D'autres encore considèrent que tables et colonnes ne suffisent pas : ce qu'il faut préserver avant tout, c'est le sens.
C'est là que l'histoire de la modélisation devient véritablement surprenante.
→ Partie II — Les écoles oubliées : Anchor Modeling, temps, événements et modèles sémantiques
Références principales de cette partie
- E. F. Codd, A Relational Model of Data for Large Shared Data Banks, IBM Research / Communications of the ACM, 1970.
- Ralph Kimball / Kimball Group, Dimensional Modeling Techniques.
- Ralph Kimball / Kimball Group, Four-Step Dimensional Design Process.
- Ralph Kimball, Keep to the Grain in Dimensional Modeling.
- Bill Inmon / Corporate Information Factory, présentation comparative de l'architecture EDW normalisée et des Data Marts.
- Dan Linstedt & Michael Olschimke, Building a Scalable Data Warehouse with Data Vault 2.0, chapitre consacré aux Hubs, Links et Satellites.
- Data Vault Alliance, présentation des principes fondamentaux de Data Vault 2.0.