Nous pouvons maintenant faire l'expérience qui permet réellement de comprendre les différences entre les grandes écoles de modélisation.
Prenons un seul domaine métier.
Pas cinq exemples différents.
Pas cinq entreprises.
Pas cinq jeux de données.
Un seul univers :
CLIENT
CONTRAT
PRODUIT
VENTE
AGENCE
Le métier nous donne les règles suivantes.
Un client peut posséder plusieurs contrats.
Un contrat porte sur un produit.
Une agence commercialise les contrats.
Les ventes génèrent du chiffre d'affaires.
Un client possède un segment commercial.
Ce segment peut évoluer.
Son adresse peut également changer.
Un contrat possède un statut susceptible d'évoluer :
PROSPECT
ACTIVE
SUSPENDED
CANCELLED
Enfin, plusieurs systèmes interviennent.
CRM
ERP
SYSTEME_CONTRAT
REFERENTIEL_PRODUIT
SYSTEME_COMMERCIAL
Le CRM possède ses propres identifiants.
L'ERP en possède d'autres.
Certaines données se chevauchent.
Certaines se contredisent.
Et l'entreprise veut répondre à des questions relativement classiques :
Quel chiffre d'affaires avons-nous généré par produit ?
Quels segments clients progressent ?
Combien de contrats étaient actifs à une date donnée ?
Quelle agence a commercialisé quel produit ?
Mais elle veut également pouvoir répondre à des questions plus difficiles :
Quelle source nous a fourni cette information ?
Quand avons-nous reçu la modification ?
Quel était le segment du client au moment de la vente ?
Quelle était la valeur connue par le système avant une correction rétroactive ?
Nous allons maintenant donner exactement ce problème à plusieurs modélisateurs.
Et ils ne vont pas du tout construire la même chose.
33. Si nous donnons le problème à Inmon
L'approche Inmon commence par regarder l'entreprise comme un ensemble de grands sujets intégrés.
Notre modèle conceptuel pourrait donc s'organiser autour de :
CUSTOMER
CONTRACT
PRODUCT
AGENCY
SALE
avec leurs relations.
Schématiquement :
CUSTOMER
│
│
▼
CONTRACT ───── PRODUCT
│
│
▼
SALE ─────── AGENCY
L'objectif premier est de construire une représentation cohérente et intégrée du domaine.
Les données provenant du CRM, de l'ERP ou du système commercial devront donc être harmonisées avant d'entrer dans le cœur décisionnel.
Par exemple :
CRM.Customer_ID
ERP.Client_Code
Sales.Customer_Number
devront être rapprochés pour produire une représentation cohérente du client.
Le modèle central cherchera à réduire la redondance et pourra être fortement normalisé.
Nous pourrions obtenir :
CUSTOMER
--------
Customer_ID
Customer_Name
Birth_Date
CUSTOMER_ADDRESS
----------------
Customer_ID
Address_ID
Valid_From
Valid_To
ADDRESS
-------
Address_ID
Street
City
Country
CONTRACT
--------
Contract_ID
Customer_ID
Product_ID
Status_ID
PRODUCT
-------
Product_ID
Product_Name
Product_Category
SALE
----
Sale_ID
Contract_ID
Agency_ID
Sale_Date
Amount
AGENCY
------
Agency_ID
Agency_Name
Region_ID
L'intérêt apparaît rapidement.
Les concepts d'entreprise sont clairement séparés.
Le modèle peut servir plusieurs besoins.
L'agence, le client, le produit et le contrat ne sont pas définis spécifiquement pour un seul dashboard.
Ils appartiennent au patrimoine informationnel intégré de l'entreprise.
C'est précisément la force de cette philosophie.
Mais plaçons maintenant un analyste devant ce modèle.
Il demande :
Donne-moi le chiffre d'affaires par mois, catégorie de produit, région et segment client.
La requête peut nécessiter de nombreuses jointures.
La structure est cohérente.
Elle n'est pas nécessairement idéale pour l'exploration analytique.
Voilà pourquoi une architecture de type Inmon conduit fréquemment à produire ensuite des structures de restitution plus adaptées aux usages décisionnels.
La question devient alors :
Et si nous avions commencé directement par la question analytique ?
C'est exactement ce que ferait Kimball.
34. Si nous donnons le même problème à Kimball
Kimball commencerait probablement par demander :
Quel processus métier voulons-nous analyser ?
Réponse :
la vente.
Deuxième question :
Quel est le grain ?
Supposons :
Une ligne représente la vente d'un contrat correspondant à un produit, à une date et via une agence donnée.
Nous pouvons alors construire :
DIM_DATE
│
│
DIM_CUSTOMER ───── FACT_SALE ───── DIM_PRODUCT
│
│
DIM_AGENCY
│
│
DIM_CONTRACT
La table de faits pourrait contenir :
FACT_SALE
---------
Date_Key
Customer_Key
Product_Key
Agency_Key
Contract_Key
Quantity
Gross_Amount
Discount_Amount
Net_Amount
Margin
Et les dimensions :
DIM_CUSTOMER
------------
Customer_Key
Customer_Business_Key
Name
City
Country
Segment
...
DIM_PRODUCT
-----------
Product_Key
Product_Code
Product_Name
Category
Brand
...
DIM_AGENCY
----------
Agency_Key
Agency_Code
Agency_Name
Region
...
DIM_DATE
--------
Date_Key
Date
Month
Quarter
Year
...
Nous retrouvons la logique classique du star schema : une table de faits centrale portant les mesures, entourée de dimensions descriptives. C'est encore aujourd'hui le modèle que Microsoft présente comme adapté aux workloads analytiques dans Fabric Warehouse.
Une requête analytique devient presque naturelle :
SUM(Net_Amount)
BY
Year
Product_Category
Agency_Region
Customer_Segment
Le modèle ressemble au langage utilisé par le métier.
C'est l'une des raisons de la longévité extraordinaire du modèle dimensionnel.
35. Et lorsque le client change de segment ?
Voilà où apparaît une autre idée classique de Kimball : les Slowly Changing Dimensions.
Imaginons :
Client 102
2024 → STANDARD
2025 → PREMIUM
2026 → VIP
Si nous écrasons simplement :
Segment = VIP
alors une vente réalisée en 2024 pourrait apparaître aujourd'hui comme une vente réalisée à un client VIP.
C'est faux historiquement.
Avec une dimension de type 2, nous pouvons produire :
Customer_Key | Customer_ID | Segment | Valid_From | Valid_To
----------------------------------------------------------------
501 | 102 | STANDARD | 2024-01-01 | 2024-12-31
783 | 102 | PREMIUM | 2025-01-01 | 2025-12-31
954 | 102 | VIP | 2026-01-01 | ...
Une vente de 2024 pointe vers :
Customer_Key = 501
Une vente de 2026 vers :
Customer_Key = 954
L'historisation sert ici directement la justesse analytique.
Et cela illustre parfaitement la philosophie Kimball.
La question n'est pas :
Comment conserver absolument toutes les variations de toutes les sources ?
La question est :
Quelle version de la dimension était pertinente pour interpréter correctement ce fait ?
36. L'intégration selon Kimball
Supposons désormais que nous voulions analyser :
VENTE
SUPPORT CLIENT
SINISTRE
PAIEMENT
Le modèle ne devient pas nécessairement quatre univers indépendants.
Nous pouvons réutiliser certaines dimensions :
DIM_CUSTOMER
/ | \
/ | \
FACT_SALE FACT_SUPPORT FACT_PAYMENT
La conformed dimension devient le mécanisme d'intégration.
Kimball Group décrit précisément les dimensions conformes comme des dimensions communes réutilisées entre plusieurs modèles dimensionnels afin de fournir des attributs descriptifs cohérents et de permettre l'analyse entre plusieurs processus métier.
La bus matrix permet alors de cartographier les processus métier en lignes et les dimensions partagées en colonnes.
Par exemple :
| Processus | Date | Client | Produit | Agence | Contrat |
|---|---|---|---|---|---|
| Vente | ✓ | ✓ | ✓ | ✓ | ✓ |
| Paiement | ✓ | ✓ | ✓ | ||
| Support | ✓ | ✓ | ✓ | ✓ | |
| Résiliation | ✓ | ✓ | ✓ | ✓ | ✓ |
Nous obtenons donc une architecture d'entreprise, mais construite par processus métier coordonnés, plutôt que par un grand modèle normalisé construit en amont.
37. Si nous donnons le problème à Linstedt
Changeons maintenant complètement de perspective.
Nous donnons les mêmes sources au Data Vault.
Cette fois, le point de départ sera notamment l'identification des Business Keys.
Nous avons :
CUSTOMER_NUMBER
CONTRACT_NUMBER
PRODUCT_CODE
AGENCY_CODE
Nous construisons :
HUB_CUSTOMER
HUB_CONTRACT
HUB_PRODUCT
HUB_AGENCY
Puis les relations métier :
HUB_CUSTOMER
│
▼
LINK_CUSTOMER_CONTRACT
▲
│
HUB_CONTRACT
et :
HUB_CONTRACT
│
▼
LINK_CONTRACT_PRODUCT
▲
│
HUB_PRODUCT
ainsi que :
HUB_CONTRACT
│
▼
LINK_CONTRACT_AGENCY
▲
│
HUB_AGENCY
Les informations descriptives deviennent des Satellites.
Par exemple :
HUB_CUSTOMER
│
├── SAT_CUSTOMER_CRM
│
├── SAT_CUSTOMER_ERP
│
└── SAT_CUSTOMER_MARKETING
Chaque Satellite peut conserver notamment :
Load_Date
Record_Source
HashDiff
...
et les attributs provenant du système concerné.
Nous changeons radicalement de priorité.
Kimball cherchait essentiellement à faciliter l'interprétation analytique d'un fait.
Data Vault cherche d'abord à permettre l'intégration historisée et traçable de sources qui évoluent.
38. Un désaccord entre sources devient une information
Voilà une différence particulièrement intéressante.
Supposons :
CRM:
Client 102
Segment = PREMIUM
ERP:
Client 102
Segment = STANDARD
Une architecture fortement orientée consolidation pourrait chercher rapidement :
SEGMENT_FINAL = ?
et appliquer une règle :
CRM wins
ou :
ERP wins
Dans un Raw Vault, nous pouvons conserver les deux descriptions dans des Satellites différents.
Conceptuellement :
HUB_CUSTOMER
│
├── SAT_CRM
│ Segment = PREMIUM
│
└── SAT_ERP
Segment = STANDARD
Nous n'avons pas encore décidé lequel est « vrai ».
Nous avons préservé ce que chaque source nous a dit.
C'est seulement dans une couche métier ultérieure que nous pouvons décider :
BUSINESS RULE:
Preferred segment source = CRM
Cette séparation entre données reçues et interprétation métier est l'une des raisons pour lesquelles Data Vault peut être particulièrement intéressant lorsque provenance, auditabilité et changements de sources comptent fortement.
39. Mais alors, comment Power BI consomme-t-il tout cela ?
Voilà l'une des erreurs fréquentes lorsque l'on compare Data Vault et Kimball.
On montre :
HUBS
LINKS
SATELLITES
puis :
FACTS
DIMENSIONS
et l'on demande :
Lequel choisir ?
Mais pourquoi Power BI devrait-il nécessairement consommer directement des dizaines de Hubs, Links et Satellites ?
Il peut être beaucoup plus naturel de produire :
RAW VAULT
↓
BUSINESS VAULT
↓
DIM_CUSTOMER
DIM_PRODUCT
DIM_AGENCY
FACT_SALE
↓
SEMANTIC MODEL
↓
POWER BI
Nous retrouvons alors une idée importante de notre article :
Data Vault et Kimball peuvent parfaitement exister dans la même architecture parce qu'ils peuvent optimiser deux couches différentes.
Le premier privilégie l'intégration, l'historisation et la traçabilité.
Le second privilégie la consommation analytique.
Et les plateformes modernes continuent de donner une place importante au modèle dimensionnel côté consommation. Microsoft recommande toujours explicitement les faits, dimensions et star schemas dans Fabric Warehouse.
40. Si nous donnons le problème à Anchor Modeling
Voyons maintenant ce qui se passe avec Anchor Modeling.
Nous pouvons commencer par identifier :
CUSTOMER
CONTRACT
PRODUCT
AGENCY
comme Anchors.
Puis isoler leurs attributs.
CUSTOMER
│
├── Customer_Name
├── Customer_Address
├── Customer_Segment
├── Customer_Risk_Class
└── Customer_Preferred_Channel
Les relations deviennent des Ties :
CUSTOMER ───── CONTRACT
CONTRACT ───── PRODUCT
CONTRACT ───── AGENCY
Ce qui devient intéressant est que :
Customer_Address
peut être historisé indépendamment de :
Customer_Segment
lui-même indépendant de :
Customer_Risk_Class
Si demain apparaît :
Customer_ESG_Profile
nous pouvons ajouter cette information sans redéfinir nécessairement les autres attributs.
Le modèle accepte presque philosophiquement que :
nous ne savons pas aujourd'hui tout ce que nous voudrons représenter demain.
Cette propriété peut être extrêmement intéressante dans les patrimoines longs et les domaines dont la structure métier évolue régulièrement.
Mais elle produit également un modèle techniquement beaucoup plus fragmenté.
Et c'est là que revient une règle générale :
Une qualité obtenue dans une couche peut produire une complexité supplémentaire dans une autre.
Une structure extraordinairement flexible pour l'historisation n'est pas nécessairement la structure la plus simple à donner directement à un analyste.
Encore une fois, la couche de consommation peut être différente de la couche de persistance.
41. Et si nous modélisions le domaine comme une suite d'événements ?
Essayons maintenant une cinquième lecture.
Nous ne stockons plus d'abord :
CONTRACT
Status = ACTIVE
Nous observons :
CustomerCreated
CustomerAddressChanged
CustomerSegmentChanged
ContractCreated
ContractActivated
ProductAssignedToContract
SaleCompleted
PaymentReceived
ContractSuspended
ContractReactivated
ContractCancelled
L'histoire d'un contrat devient :
ContractCreated
↓
ContractActivated
↓
PaymentReceived
↓
ContractSuspended
↓
ContractReactivated
↓
ContractCancelled
L'état actuel :
CANCELLED
n'est que le dernier résultat d'une séquence.
Cette représentation est particulièrement puissante lorsque la séquence et le processus sont eux-mêmes importants.
Elle permet de mesurer :
temps moyen création → activation
temps activation → premier paiement
nombre de suspensions avant résiliation
séquences précédant un défaut
parcours précédant une conversion
Le fait analytique peut alors émerger d'une histoire événementielle beaucoup plus riche.
Mais, là encore, nous ne sommes pas obligés de demander à l'utilisateur métier d'interroger directement tous les événements.
Nous pouvons dériver :
EVENTS
↓
DERIVED STATE
↓
FACT_CONTRACT_ACTIVITY
↓
DIMENSIONS
↓
BI
La bonne architecture n'est donc pas celle qui impose le même modèle à toutes les couches.
Elle est celle qui préserve les bonnes propriétés au bon endroit.
42. Le grand tableau comparatif
Nous pouvons maintenant comparer les principales philosophies.
| Critère | Inmon | Kimball | Data Vault | Anchor | Event-oriented |
|---|---|---|---|---|---|
| Objet principal | Entreprise | Processus analytique | Business keys et relations | Structure évolutive | Événement |
| Intégration | Très forte | Via dimensions/faits conformes | Très forte | Possible | À construire |
| Lisibilité BI | Moyenne | Très forte | Faible directement | Faible directement | Faible directement |
| Historisation | Forte | Ciblée selon besoin | Très forte | Très fine | Native |
| Provenance | Possible | Généralement secondaire | Centrale | Possible | Très forte |
| Évolution structurelle | Modérée | Modérée | Forte | Très forte | Forte |
| Auditabilité | Forte si bien conçue | Correcte | Très forte | Forte | Très forte |
| Performance analytique directe | Variable | Forte | Généralement non optimale | Généralement non optimale | Non optimale |
| Complexité de modèle | Moyenne à forte | Faible à moyenne | Forte | Forte | Forte |
| Orientation métier | Sujets d'entreprise | Processus / mesures | Identités / relations / sources | Concepts / attributs | Comportements / changements |
Il serait néanmoins dangereux de transformer ce tableau en concours.
Attribuer :
Kimball = 8/10
Data Vault = 9/10
Inmon = 7/10
n'aurait guère de sens.
Il faut plutôt se demander :
Quelle propriété dois-je préserver dans cette couche précise ?
43. Le cloud n'a pas supprimé la modélisation
Nous pouvons maintenant faire un saut vers l'architecture contemporaine.
Les plateformes ont profondément changé.
Nous pouvons disposer :
- d'object storage ;
- de formats colonnes ;
- de moteurs distribués ;
- d'élasticité compute ;
- de séparation storage/compute ;
- de streaming ;
- de formats transactionnels sur Data Lake ;
- de catalogues centralisés ;
- de semantic layers ;
- d'IA générative.
Mais aucune de ces innovations ne répond automatiquement à :
Qu'est-ce qu'un client ?
Quel est le grain de cette table ?
Quelle est la relation entre contrat et produit ?
Quelle source fait autorité ?
Quelle version historique utiliser ?
Que signifie réellement le chiffre d'affaires ?
Snowflake, par exemple, gère automatiquement une grande partie des aspects physiques du stockage de ses tables, notamment leur organisation en micro-partitions. Cela réduit le besoin pour le concepteur de contrôler directement certains détails physiques du stockage, mais cela ne décide évidemment pas à sa place ce qu'est un client, un fait ou une dimension.
Autrement dit :
le cloud automatise beaucoup de physique. Il n'automatise pas la sémantique métier.
44. Medallion Architecture : nouvelle école ou nouveau découpage ?
Prenons l'un des patterns les plus célèbres du Lakehouse contemporain :
BRONZE
↓
SILVER
↓
GOLD
Databricks décrit officiellement la Medallion Architecture comme une organisation des données en couches correspondant à des niveaux croissants de qualité : Bronze pour les données brutes, Silver pour les données raffinées, Gold pour les données métier prêtes à l'usage.
Une confusion fréquente consiste à traiter :
BRONZE / SILVER / GOLD
comme s'il s'agissait d'une nouvelle réponse à :
INMON / KIMBALL / DATA VAULT
Mais ce ne sont pas exactement les mêmes dimensions architecturales.
Medallion répond principalement à :
À quel niveau de raffinement cette donnée se trouve-t-elle ?
Kimball répond davantage à :
Comment organiser cette donnée pour l'analyse ?
Data Vault :
Comment intégrer et historiser des données issues de sources changeantes ?
Inmon :
Comment construire une représentation intégrée de l'entreprise ?
Ces idées peuvent donc se combiner.
45. Data Vault dans une architecture Medallion
On pourrait par exemple concevoir :
BRONZE
────────────────────────────
Raw CRM
Raw ERP
Raw Sales
Raw Contracts
↓
SILVER
────────────────────────────
Raw Data Vault
Hubs
Links
Satellites
↓
SILVER / BUSINESS
────────────────────────────
Business Vault
Rules
Derived entities
↓
GOLD
────────────────────────────
DIM_CUSTOMER
DIM_PRODUCT
DIM_AGENCY
FACT_SALE
↓
SEMANTIC MODEL
────────────────────────────
Measures
KPIs
Hierarchies
Business terminology
Ce n'est pas la seule architecture possible.
Mais elle montre pourquoi les débats du type :
« Data Vault ou Medallion ? »
peuvent être mal posés.
On compare parfois une technique de modélisation avec un principe de stratification des traitements et de qualité des données.
La documentation Databricks elle-même présente Medallion comme un pattern de couches de données progressivement raffinées.
46. Et dans Microsoft Fabric ?
Microsoft Fabric fournit aujourd'hui à la fois des expériences Lakehouse et Warehouse.
Le Lakehouse combine stockage de type Data Lake et possibilités de requêtage de type Data Warehouse, en s'appuyant notamment sur Delta Lake, Spark et SQL.
Mais lorsque l'on arrive à la conception analytique d'un Warehouse, Microsoft continue explicitement d'enseigner :
FACT TABLES
DIMENSION TABLES
STAR SCHEMA
et relie cette approche aux modèles sémantiques Power BI.
C'est extrêmement révélateur.
Le Lakehouse n'a pas rendu Kimball obsolète.
Il a changé la plateforme sur laquelle Kimball peut être matérialisé.
Nous pouvons donc avoir :
ONELAKE
↓
LAKEHOUSE
↓
TRANSFORMATION / INTEGRATION
↓
WAREHOUSE
↓
STAR SCHEMA
↓
SEMANTIC MODEL
↓
POWER BI
Le progrès technologique n'annule pas nécessairement le progrès conceptuel précédent.
Il peut l'accueillir dans une nouvelle architecture.
47. Snowflake et le retour de la couche sémantique
Snowflake fournit un autre exemple particulièrement intéressant.
Ses Semantic Views permettent de mapper des concepts métier sur les données physiques, de définir relations, métriques et dimensions, puis d'utiliser notamment Cortex Analyst pour permettre des requêtes en langage naturel. Snowflake recommande même de commencer par une structure physique simple, typiquement un star schema.
Cette évolution est importante.
Pendant des années, nous avons principalement demandé :
Comment permettre à un analyste de comprendre nos données ?
Maintenant, nous demandons également :
Comment permettre à une IA de comprendre ce que signifient nos données ?
La question de la sémantique revient donc au premier plan.
Pour qu'un utilisateur demande :
Quelle est la marge moyenne des clients premium ayant souscrit un produit automobile en Île-de-France ?
le système doit comprendre :
MARGE
CLIENT
PREMIUM
PRODUIT
AUTOMOBILE
ILE-DE-FRANCE
et leurs relations.
Le problème de demain pourrait donc ne pas être :
Avons-nous assez de données ?
mais :
Avons-nous suffisamment bien modélisé leur signification pour permettre aux humains et aux machines de les interroger correctement ?
48. La modélisation devient plus importante lorsque l'IA arrive
On pourrait croire que les Large Language Models rendent la modélisation moins nécessaire.
Après tout, pourquoi construire des modèles complexes si une IA peut lire les tables et produire du SQL ?
Mais cette intuition peut produire exactement l'effet inverse.
Un LLM peut parfaitement voir :
CUST_SEG_CD
Il ne sait pas nécessairement si :
01
signifie :
Premium
Standard
Retail
Corporate
Active
Prospect
Il peut voir :
REV_AMT
mais ignorer s'il s'agit :
du revenu brut,
du revenu net,
du revenu comptabilisé,
du revenu facturé,
du revenu encaissé,
du revenu à taux de change constant.
Plus l'interface devient naturelle, plus la couche sémantique derrière cette interface doit être rigoureuse.
L'utilisateur ne formulera plus :
SELECT ...
FROM ...
JOIN ...
GROUP BY ...
Il dira :
Montre-moi les clients les plus rentables.
Et soudain, toute la difficulté se concentre dans un seul mot :
rentables.
Comment calcule-t-on la rentabilité ?
Sur quelle période ?
À quel grain ?
Avec quels coûts ?
Selon quelle devise ?
Quelle définition métier ?
Le LLM n'élimine donc pas la modélisation.
Il peut au contraire rendre ses erreurs beaucoup plus dangereuses parce qu'il masque la complexité derrière une interface linguistique extrêmement convaincante.
49. L'architecture moderne comme empilement de philosophies
Nous pouvons maintenant proposer une architecture conceptuelle plus générale.
┌─────────────────────────────────────────────┐
│ CONSUMPTION │
│ BI / AI / Apps / Data Products │
└──────────────────▲──────────────────────────┘
│
┌──────────────────┴──────────────────────────┐
│ SEMANTIC LAYER │
│ Metrics / Business Concepts / Relationships │
└──────────────────▲──────────────────────────┘
│
┌──────────────────┴──────────────────────────┐
│ DIMENSIONAL / SERVING │
│ Facts / Dimensions / Aggregations │
│ KIMBALL │
└──────────────────▲──────────────────────────┘
│
┌──────────────────┴──────────────────────────┐
│ BUSINESS INTEGRATION │
│ Rules / Conformance / Derived Data │
└──────────────────▲──────────────────────────┘
│
┌──────────────────┴──────────────────────────┐
│ HISTORICAL INTEGRATION │
│ Hubs / Links / Satellites │
│ DATA VAULT │
└──────────────────▲──────────────────────────┘
│
┌──────────────────┴──────────────────────────┐
│ RAW / LANDING │
│ Source-aligned history / events │
└──────────────────▲──────────────────────────┘
│
┌──────────────────┴──────────────────────────┐
│ SOURCES │
│ CRM / ERP / APIs / Files / Streams │
└─────────────────────────────────────────────┘
On pourrait modifier cette architecture selon le contexte.
Certaines entreprises n'ont aucun besoin de Data Vault.
Certaines peuvent construire directement des modèles dimensionnels.
D'autres ont besoin d'un cœur intégré normalisé.
Certaines utiliseront largement des événements.
D'autres auront besoin de bitemporalité.
Certaines ajouteront un Knowledge Graph.
Mais le principe devient clair :
Une architecture Data moderne peut être comprise comme un empilement de représentations différentes d'une même réalité, chacune optimisée pour une propriété différente.
50. Alors, quelle école choisir ?
La réponse la plus utile est probablement :
aucune, si par choisir nous entendons adhérer dogmatiquement à une seule méthode pour toutes les couches.
Il faut plutôt commencer par les contraintes.
Si la priorité est :
Une BI rapide et compréhensible
Kimball reste extrêmement pertinent.
Une intégration d'entreprise centralisée
Une philosophie proche d'Inmon peut rester particulièrement appropriée.
Beaucoup de sources, changements fréquents, provenance et auditabilité
Data Vault devient très attractif.
Une très forte évolution structurelle et temporelle
Anchor Modeling mérite d'être étudié.
Une activité naturellement décrite par des transitions
Event-oriented modeling devient particulièrement puissant.
Des relations métier complexes et une forte exigence sémantique
Graphes, ontologies et Knowledge Graphs peuvent apporter une représentation différente et complémentaire.
Des exigences réglementaires sur l'histoire de la connaissance
La modélisation temporelle ou bitemporelle peut devenir indispensable.
Ce ne sont pas simplement des technologies.
Ce sont des façons de penser le problème.
51. La meilleure méthode dépend de ce que l'on refuse de perdre
Nous pouvons maintenant reformuler tout l'article en une seule question.
Lorsqu'une entreprise transforme son activité en données, qu'est-ce qu'elle refuse de perdre ?
Si elle refuse de perdre la cohérence logique :
Codd.
Si elle refuse de perdre la vision intégrée de l'entreprise :
Inmon.
Si elle refuse de perdre l'intelligibilité analytique :
Kimball.
Si elle refuse de perdre la provenance et l'histoire des sources :
Linstedt.
Si elle refuse de perdre la capacité du modèle à évoluer :
Anchor Modeling.
Si elle refuse de perdre la distinction entre ce qui était vrai et ce qui était connu :
bitemporal modeling.
Si elle refuse de perdre la succession exacte des changements :
event-oriented modeling.
Si elle refuse de perdre le sens reliant les concepts :
semantic modeling et Knowledge Graphs.
Et voilà pourquoi ces écoles persistent.
Elles protègent chacune quelque chose que l'entreprise peut considérer comme précieux.
52. Conclusion — Nous n'avons probablement jamais eu à choisir
Pendant des décennies, une grande partie de la littérature sur le Data Warehousing a présenté les méthodes sous forme d'affrontements.
Inmon contre Kimball.
Puis :
Data Vault contre modèle dimensionnel.
Aujourd'hui :
Lakehouse contre Warehouse.
Data Lake contre Data Warehouse.
Semantic Layer contre modèle physique.
Mais cette manière de poser le problème peut être trompeuse.
Car une entreprise n'a pas qu'un seul besoin.
Elle doit simultanément :
ingérer
intégrer
historiser
transformer
gouverner
expliquer
analyser
servir
interpréter
Une représentation idéale pour l'ingestion n'est pas nécessairement idéale pour l'analyse.
Une représentation idéale pour l'audit n'est pas nécessairement idéale pour Power BI.
Une représentation idéale pour la BI n'est pas nécessairement idéale pour reconstruire exactement ce qu'une source avait envoyé cinq ans auparavant.
Une représentation idéale pour un humain n'est pas nécessairement suffisante pour permettre à un agent IA de comprendre les relations métier.
Le problème architectural moderne n'est donc probablement plus :
Quel modèle dois-je choisir ?
Il devient :
À quelle couche dois-je utiliser quelle représentation, et quelle propriété de la donnée dois-je préserver à chaque transformation ?
Cette question permet de réconcilier une grande partie des écoles que nous avons parcourues.
Un système pourrait recevoir des événements.
Conserver les données sources.
Les intégrer selon une logique proche du Data Vault.
Appliquer des règles métier.
Construire des modèles dimensionnels.
Les exposer dans une couche sémantique.
Et enrichir certains domaines avec un graphe de connaissances.
Aucune contradiction.
Chaque représentation joue son rôle.
Ce qui nous ramène, plus d'un demi-siècle plus tard, au problème fondamental posé par la modélisation :
une donnée n'est jamais seulement une valeur stockée quelque part.
Elle possède un grain.
Une identité.
Une provenance.
Une temporalité.
Des relations.
Un contexte.
Et surtout, une signification.
Les technologies de stockage continueront probablement à changer.
Les moteurs seront plus rapides.
Les plateformes deviendront plus automatisées.
Les assistants IA écriront davantage de SQL.
Les architectures absorberont toujours plus de données.
Mais aucune puissance de calcul ne pourra supprimer la nécessité de répondre correctement à une question aussi simple que :
Qu'est-ce que cette donnée représente réellement ?
C'est précisément pour cette raison que les idées de Codd, Inmon, Kimball, Linstedt et des écoles venues après eux ne constituent pas seulement l'histoire du Data Warehousing.
Elles constituent encore une partie du vocabulaire intellectuel dont nous avons besoin pour construire les architectures Data de demain.
Références complémentaires — architecture moderne
- Microsoft, Dimensional modeling in Fabric Data Warehouse. Microsoft continue de recommander explicitement une conception en faits et dimensions et le star schema pour les workloads analytiques dans Fabric Warehouse.
- Microsoft, Understand star schema and the importance for Power BI. Le star schema y est présenté comme une approche mature et largement adoptée pour les modèles analytiques.
- Microsoft, What is a lakehouse? — Microsoft Fabric. Fabric Lakehouse combine stockage de type Data Lake, Delta Lake, Spark et accès SQL.
- Databricks, What is the Medallion Lakehouse Architecture?. Databricks définit Bronze, Silver et Gold comme des couches de qualité et de raffinement croissants.
- Databricks, Data Warehousing Architecture. La documentation actuelle présente Medallion comme un pattern structurant du Lakehouse moderne.
- Snowflake, Snowflake Key Concepts and Architecture. Snowflake prend en charge automatiquement de nombreux aspects physiques du stockage, notamment les micro-partitions.
- Snowflake, Overview of Semantic Views. Les Semantic Views permettent d'associer les concepts métier aux structures physiques et Snowflake recommande notamment de partir d'un star schema simple.
- Kimball Group, Enterprise Data Warehouse Bus Architecture. Les dimensions conformes assurent la cohérence entre plusieurs processus métier.
- Kimball Group, Enterprise Data Warehouse Bus Matrix. La bus matrix articule processus métier et dimensions partagées à l'échelle de l'entreprise.
La thèse en une phrase
L'histoire de la modélisation Data n'est pas celle d'une succession de méthodes qui s'éliminent les unes les autres ; c'est celle d'une accumulation de réponses à des problèmes différents — cohérence, intégration, analyse, histoire, changement, provenance et sens — que l'architecture moderne doit désormais savoir combiner.