Les trois grandes traditions étudiées précédemment — Inmon, Kimball et Linstedt — permettent déjà de couvrir une part considérable des architectures décisionnelles rencontrées en entreprise.

Mais elles ne racontent qu'une partie de l'histoire.

À leur périphérie se sont développées d'autres approches, parfois beaucoup moins connues, qui partent d'une interrogation différente.

Que se passe-t-il lorsque le modèle lui-même change continuellement ?

Comment distinguer le moment où quelque chose s'est produit du moment où nous avons appris que cela s'était produit ?

Pourquoi conserver uniquement l'état d'une entité alors que cet état résulte d'une succession d'événements ?

Et que faire lorsque le véritable problème n'est plus de stocker des valeurs, mais de représenter correctement le sens et les relations entre les concepts ?

Ces questions ont produit plusieurs familles de modélisation particulièrement intéressantes.

Certaines sont anciennes.

D'autres sont intimement liées aux architectures distribuées contemporaines.

Et certaines semblent aujourd'hui retrouver une importance nouvelle avec les Knowledge Graphs, les systèmes événementiels et l'intelligence artificielle.

Pour les comprendre, commençons par un problème extrêmement concret.

12. Le grand ennemi du modèle de données : le changement

Construisons une table apparemment innocente :

CUSTOMER

Customer_ID
Name
Address
City
Country
Segment
Risk_Class
Sales_Region

Elle fonctionne.

Puis le métier demande :

Preferred_Channel

Nous ajoutons une colonne.

Quelques mois plus tard :

ESG_Category

Nouvelle colonne.

Puis une source supplémentaire fournit :

Customer_Loyalty_Level

Encore une colonne.

Mais le véritable problème apparaît lorsqu'on nous demande :

Depuis quand ce client appartient-il au segment PREMIUM ?

Nous devons maintenant historiser Segment.

Puis :

Quelle était sa région commerciale au moment de la vente ?

Il faut historiser Sales_Region.

Puis :

Nous avons découvert que son adresse avait changé trois semaines avant que notre système ne l'enregistre.

Et soudain, une seule notion de date ne suffit plus.

Ce petit exemple révèle un problème général :

les attributs d'une entité ne changent ni au même moment, ni à la même fréquence, ni pour les mêmes raisons.

Pourtant, nos modèles ont souvent tendance à les regrouper parce qu'ils décrivent le même objet.

C'est précisément ce présupposé que va attaquer une approche beaucoup moins connue : Anchor Modeling.

13. Anchor Modeling : concevoir un modèle qui s'attend à changer

Anchor Modeling est une technique développée notamment autour des travaux de Lars Rönnbäck et de ses collaborateurs.

Sa philosophie est radicalement différente d'une modélisation relationnelle traditionnelle.

Au lieu de construire une grosse entité :

CUSTOMER

avec des dizaines d'attributs, Anchor Modeling pousse très loin la décomposition du modèle.

Ses principaux composants sont :

ANCHOR
ATTRIBUTE
TIE
KNOT

L'Anchor représente essentiellement l'identité d'un concept.

Un client peut ainsi devenir :

CUSTOMER

mais ses propriétés ne sont pas nécessairement stockées avec lui.

Nous pouvons conceptuellement obtenir :

             CUSTOMER
                │
       ┌────────┼────────┐
       │        │        │
      Name    Address  Segment

Chaque attribut peut devenir une structure indépendante.

Cela peut sembler excessif.

Pourquoi transformer une table simple en une multitude de structures ?

Parce qu'une propriété importante apparaît immédiatement :

chaque attribut peut désormais posséder sa propre histoire.

Le nom peut changer rarement.

L'adresse peut changer plusieurs fois.

Le segment commercial peut être recalculé tous les mois.

Le score de risque peut changer quotidiennement.

Le modèle n'oblige plus ces propriétés à partager artificiellement le même cycle de vie.

14. Anchors, Attributes, Ties et Knots

Prenons un domaine légèrement plus complet :

CLIENT
CONTRAT
PRODUIT

Dans Anchor Modeling, CLIENT, CONTRAT et PRODUIT peuvent être représentés comme des Anchors.

Ils correspondent à des identités relativement stables.

Les propriétés deviennent des Attributes :

CLIENT
   │
   ├── NAME
   ├── ADDRESS
   ├── SEGMENT
   └── RISK_CLASS

Les relations entre Anchors sont représentées par des Ties.

Par exemple :

CLIENT ───── CONTRAT

ou :

CONTRAT ───── PRODUIT

Les Knots, enfin, permettent notamment de représenter certains ensembles de valeurs partagés et relativement stables.

Une classification comme :

BRONZE
SILVER
GOLD
PLATINUM

peut par exemple être factorisée plutôt que répétée inutilement.

Ce qui est particulièrement intéressant n'est cependant pas la terminologie.

C'est la philosophie sous-jacente.

Dans un modèle conventionnel, nous avons tendance à nous demander :

Comment construire aujourd'hui le bon modèle ?

Anchor Modeling pose une question légèrement différente :

Comment construire un modèle qui pourra continuer à évoluer demain sans détruire ce qui fonctionnait hier ?

C'est une différence subtile mais profonde.

15. Le schéma comme structure évolutive

Imaginons qu'en 2026 notre client possède :

Name
Address
Segment

En 2027, le métier demande :

Preferred_Channel

Dans une architecture classique, nous pouvons modifier :

CUSTOMER

Dans Anchor Modeling, nous pouvons ajouter un nouvel attribut :

CUSTOMER
   │
   ├── Name
   ├── Address
   ├── Segment
   └── Preferred_Channel  ← nouveau

Le cœur existant n'a pas besoin d'être redéfini.

Cette logique donne au modèle une propriété importante : l'extensibilité.

Le modèle est pensé pour être enrichi.

Cette idée rapproche intellectuellement Anchor Modeling du Data Vault.

Mais les deux ne sont pas identiques.

Data Vault organise notamment le modèle autour des Business Keys, relations, contexte et provenance.

Anchor Modeling pousse particulièrement loin la séparation des propriétés et leur évolution temporelle indépendante.

On pourrait caricaturer les deux questions ainsi :

Data Vault : comment préserver l'histoire et la provenance de données provenant de systèmes changeants ?

Anchor Modeling : comment construire un schéma qui puisse lui-même évoluer continuellement sans perdre son histoire ?

Les frontières sont évidemment plus subtiles dans la pratique, mais cette distinction permet de comprendre leur intuition respective.

16. Le temps n'est pas une colonne

Nous arrivons maintenant à un sujet plus profond encore.

Dans beaucoup de modèles, le temps apparaît simplement comme :

CREATED_DATE
UPDATED_DATE

ou :

START_DATE
END_DATE

Mais le temps dans un système d'information possède plusieurs significations.

Prenons un exemple.

Un client déménage de Paris à Lyon le :

3 juillet 2026

Mais il ne signale son changement d'adresse que le :

18 juillet 2026

Notre système apprend donc le 18 juillet quelque chose qui était vrai depuis le 3 juillet.

Quelle date devons-nous enregistrer ?

Le 3 ?

Le 18 ?

La réponse est :

les deux.

Car elles répondent à deux questions différentes.

17. Valid Time et Transaction Time

La modélisation temporelle distingue notamment deux notions fondamentales.

Valid Time

Le moment où l'information est considérée comme vraie dans le domaine réel.

Dans notre exemple :

Adresse Lyon

VALID_FROM = 03/07/2026

Transaction Time

Le moment où l'information a été enregistrée ou connue par le système.

RECORDED_AT = 18/07/2026

Nous avons donc :

Monde réel
03/07/2026
     │
     │ déménagement
     ▼

Système
18/07/2026
     │
     │ information reçue
     ▼

Cette distinction produit une capacité analytique extraordinaire.

Nous pouvons demander :

Quelle était réellement l'adresse du client le 10 juillet ?

Réponse :

Lyon

Mais nous pouvons également demander :

Quelle adresse notre système pensait-il correcte le 10 juillet ?

Réponse :

Paris

Les deux réponses sont justes.

Elles décrivent simplement deux temporalités différentes.

18. Le modèle bitemporel : deux histoires simultanées

Lorsque nous conservons à la fois le Valid Time et le Transaction Time, nous entrons dans le domaine de la bitemporalité.

Conceptuellement :

                    TEMPS RÉEL
                        →
              Valid From / Valid To

TEMPS DU
SYSTÈME
   ↓

Recorded From
Recorded To

Nous pouvons alors reconstruire non seulement :

ce qui était vrai,

mais également :

ce que nous pensions être vrai à un instant donné.

Cette différence devient capitale dans certains secteurs.

Assurance.

Banque.

Finance.

Administration.

Santé.

Conformité réglementaire.

Gestion contractuelle.

Imaginons qu'une décision ait été prise le 10 juillet sur la base des données disponibles à cette date.

Le 18 juillet, nous corrigeons rétroactivement une information.

Une base classique pourrait simplement présenter l'information corrigée.

Mais lors d'un audit six mois plus tard, la question devient :

Pourquoi avez-vous pris cette décision le 10 juillet ?

Pour répondre correctement, nous devons reconstruire :

LE MONDE TEL QUE
LE SYSTÈME LE CONNAISSAIT
LE 10 JUILLET

Ce n'est plus simplement de l'historisation.

C'est l'historisation de notre connaissance du monde.

Et cette nuance est fondamentale.

19. Du modèle d'état au modèle d'événements

Une autre école prend le problème dans une direction encore différente.

Considérons :

CUSTOMER

Status = GOLD
Address = Lyon
Contract = ACTIVE

Ce modèle nous dit ce qui est vrai maintenant.

Mais comment en sommes-nous arrivés là ?

Peut-être :

CustomerCreated
       ↓
AddressRegistered
       ↓
ContractSigned
       ↓
CustomerUpgradedToSilver
       ↓
AddressChanged
       ↓
CustomerUpgradedToGold

L'état actuel n'est alors plus la donnée fondamentale.

Il devient le résultat d'une succession d'événements.

C'est l'idée centrale de l'Event Sourcing : les changements de l'état d'une application sont capturés sous forme d'une séquence d'événements conservés. Cette séquence permet notamment de reconstruire des états passés ou de rejouer l'histoire du système.

Cette manière de penser transforme complètement la question.

Au lieu de demander :

Quel est l'état du client ?

nous demandons :

Quels événements ont conduit le client jusqu'à cet état ?

20. State versus Event

Prenons un compte bancaire.

Approche orientée état :

ACCOUNT

Balance = 2 450 €

Nous savons combien d'argent se trouve actuellement sur le compte.

Approche événementielle :

AccountOpened       +0
SalaryReceived   +3 000
RentPaid          -900
Restaurant         -80
TransferReceived  +500
ElectricityPaid    -70

L'état :

Balance = ...

peut être dérivé de la séquence d'événements.

Martin Fowler résume précisément le principe d'Event Sourcing comme la conservation de tous les changements d'état sous forme d'une séquence d'événements ; l'état peut ensuite être reconstruit en rejouant cette séquence.

C'est une inversion importante.

Dans un système traditionnel :

ÉTAT = vérité principale
HISTORIQUE = éventuellement conservé

Dans une architecture event-sourced :

ÉVÉNEMENTS = vérité historique
ÉTAT = projection calculable

21. Pourquoi les événements sont analytiquement fascinants

Cette philosophie possède des conséquences particulièrement intéressantes pour la Data.

Supposons un parcours e-commerce :

ProductViewed
ProductAddedToCart
CheckoutStarted
PaymentAttempted
PaymentFailed
PaymentRetried
PaymentSucceeded
OrderPrepared
OrderShipped
OrderDelivered

Si nous conservons uniquement :

ORDER_STATUS = DELIVERED

nous avons détruit une grande partie de l'histoire.

Or cette histoire permet d'analyser :

• les abandons de panier ;
• les échecs de paiement ;
• les temps entre étapes ;
• les retries ;
• les comportements utilisateurs ;
• les goulets d'étranglement opérationnels ;
• les séquences précédant une conversion.

L'événement n'est donc pas seulement un mécanisme technique destiné aux architectures distribuées.

Il peut devenir une unité analytique extrêmement riche.

Nous retrouvons d'ailleurs indirectement une intuition déjà présente chez Kimball.

Une table de faits transactionnelle représente souvent elle aussi un événement métier.

La différence est que l'Event Sourcing pousse beaucoup plus loin l'idée : l'événement peut devenir la source permettant de reconstruire l'état lui-même.

22. Event Sourcing et Data Warehouse ne sont pas la même chose

Une distinction est cependant nécessaire.

Kafka n'est pas un Data Warehouse.

Un event store n'est pas automatiquement une plateforme analytique.

Et Event Sourcing n'est pas une méthode de modélisation dimensionnelle.

Ce sont des préoccupations architecturales différentes.

Mais elles peuvent se rencontrer.

Une architecture pourrait ressembler à :

APPLICATIONS
     │
     ▼
EVENTS
     │
     ▼
EVENT STREAM / EVENT STORE
     │
     ├───────────────┐
     ▼               ▼
Operational       Data Platform
Projections          │
                     ▼
                Data Warehouse
                     │
                     ▼
                FACT / DIM
                     │
                     ▼
                   BI

Nous pouvons ainsi conserver l'événement comme trace fine de ce qui s'est produit tout en construisant des modèles analytiques optimisés pour l'usage.

Une fois encore, une école n'élimine pas nécessairement l'autre.

Elle peut occuper une autre couche de l'architecture.

23. Une autre rupture : et si tables et colonnes n'étaient pas suffisantes ?

Jusqu'ici, malgré leurs différences, presque toutes nos approches partagent une intuition commune.

Nous avons des entités.

Nous avons des attributs.

Nous avons des relations.

Nous les organisons dans des structures.

Mais certains domaines deviennent tellement interconnectés que la relation elle-même devient presque aussi importante que l'entité.

Prenons :

PERSONNE
ENTREPRISE
CONTRAT
ADRESSE
PRODUIT
FOURNISSEUR
FILIALE
BÉNÉFICIAIRE

Puis ajoutons :

PERSONNE
   ├── travaille pour → ENTREPRISE
   ├── possède → CONTRAT
   ├── réside à → ADRESSE
   └── bénéficie de → PRODUIT

ENTREPRISE
   ├── appartient à → GROUPE
   ├── achète à → FOURNISSEUR
   └── possède → FILIALE

Notre problème n'est plus uniquement de connaître les attributs de chaque objet.

Nous voulons explorer le réseau de relations qui unit les objets.

C'est ici qu'interviennent les modèles de graphe et, plus particulièrement, les approches sémantiques.

24. RDF : Subject, Predicate, Object

Le Resource Description Framework — RDF — formalise une représentation particulièrement simple.

Une information peut être exprimée comme un triplet :

SUBJECT
PREDICATE
OBJECT

La spécification RDF du W3C définit précisément un graphe RDF comme un ensemble de triplets composés d'un sujet, d'un prédicat et d'un objet.

Par exemple :

Mohamed
WORKS_FOR
Company_A

ou :

Company_A
LOCATED_IN
Paris

ou :

Product_42
BELONGS_TO
Category_X

Nous obtenons progressivement :

[Person]
    │
 works_for
    ▼
[Company]
    │
 located_in
    ▼
 [Paris]

La relation n'est plus seulement une foreign key technique.

Elle porte une signification explicite.

Le W3C présente d'ailleurs RDF comme un framework permettant d'exprimer des informations concernant des ressources — personnes, objets physiques, documents ou concepts abstraits — et d'interconnecter différents jeux de données.

25. De la donnée à la connaissance

Nous touchons ici une frontière importante.

Une table pourrait dire :

CUSTOMER_ID = 127
PRODUCT_ID  = 32

La relation existe techniquement.

Mais que signifie-t-elle ?

Le client :

possède le produit ?
a consulté le produit ?
a acheté le produit ?
est éligible au produit ?
a résilié le produit ?
a recommandé le produit ?

La modélisation sémantique cherche à rendre ce sens explicite.

On ne représente plus seulement :

A → B

mais :

A --[HAS_PURCHASED]--> B

ou :

A --[IS_ELIGIBLE_FOR]--> B

ou :

A --[IS_BENEFICIARY_OF]--> B

C'est une différence considérable.

Car une machine peut alors commencer à raisonner non seulement sur des valeurs, mais sur des concepts et des relations explicitement définis.

26. Ontologies : formaliser le vocabulaire de l'entreprise

Prenons les mots :

CLIENT
CUSTOMER
CONSUMER
PROSPECT
MEMBER
SUBSCRIBER
BENEFICIARY

Sont-ils synonymes ?

Probablement pas.

Mais dans une grande entreprise, différents systèmes peuvent employer plusieurs de ces termes pour parler de réalités qui se recouvrent partiellement.

Une ontologie cherche notamment à formaliser :

• les concepts ;
• leurs propriétés ;
• leurs relations ;
• leurs catégories ;
• leurs contraintes ;
• parfois les règles permettant d'en déduire de nouvelles connaissances.

Nous pouvons par exemple définir :

PERSON
   │
   ├── CUSTOMER
   │
   ├── EMPLOYEE
   │
   └── SUPPLIER_CONTACT

puis :

CUSTOMER
   └── HOLDS → CONTRACT

CONTRACT
   └── COVERS → RISK

CONTRACT
   └── DISTRIBUTED_BY → AGENCY

Nous ne sommes plus seulement en train de dessiner un schéma physique.

Nous construisons un vocabulaire formalisé du domaine.

Et cette distinction devient de plus en plus intéressante à l'heure des Knowledge Graphs et des systèmes d'intelligence artificielle.

27. Le retour spectaculaire de la sémantique

Pendant longtemps, dans beaucoup d'équipes BI, le mot semantic signifiait essentiellement :

Nom convivial
Mesure
Hiérarchie
Relation
KPI

La couche sémantique servait à cacher la complexité technique et à présenter aux utilisateurs une représentation compréhensible.

Cette fonction reste essentielle.

Microsoft recommande encore explicitement le star schema pour les workloads analytiques de Fabric Warehouse et présente le modèle dimensionnel comme un support particulièrement adapté aux modèles sémantiques Power BI.

Mais l'arrivée des systèmes génératifs redonne au mot sémantique une profondeur supplémentaire.

Supposons qu'un utilisateur demande :

Quels clients à forte valeur appartenant à des entreprises exposées au secteur automobile ont réduit leur activité au cours des six derniers mois ?

Un humain comprend immédiatement plusieurs concepts :

CLIENT
HIGH_VALUE
ENTREPRISE
SECTEUR
AUTOMOBILE
ACTIVITÉ
RÉDUCTION
PÉRIODE

Pour un système informatique, cette question suppose de savoir :

• ce qu'est un client ;
• comment un client est relié à une entreprise ;
• comment une entreprise est reliée à un secteur ;
• ce que signifie high value ;
• quelle mesure représente l'activité ;
• comment calculer une réduction ;
• quelle période utiliser.

Le problème n'est plus simplement :

Où se trouve la colonne ?

Il devient :

Que signifie la question ?

C'est exactement là que la modélisation sémantique retrouve une importance stratégique.

28. Une généalogie commence à apparaître

Nous pouvons maintenant prendre suffisamment de recul pour voir quelque chose d'intéressant.

Chaque école a déplacé l'objet principal de la modélisation.

Codd

L'objet central est la relation logique.

Comment représenter correctement l'information ?

Inmon

L'objet central devient l'entreprise intégrée.

Comment construire une représentation cohérente
des grands sujets de l'organisation ?

Kimball

L'objet central devient le processus analytique.

Qu'est-ce qui s'est passé,
à quel grain,
et selon quelles dimensions ?

Linstedt

L'objet central devient l'identité, la relation, l'histoire et la provenance.

Qu'avons-nous reçu,
de quelle source,
et comment cela a-t-il évolué ?

Anchor Modeling

L'objet central devient la capacité du modèle à évoluer.

Comment changer le modèle
sans détruire son histoire ?

Modélisation bitemporelle

L'objet central devient la connaissance dans le temps.

Qu'est-ce qui était vrai ?
Et quand savions-nous que c'était vrai ?

Event-oriented modeling

L'objet central devient le changement lui-même.

Quel événement s'est produit ?

Semantic / Knowledge Graph

L'objet central devient le sens.

Que signifie cette information
et comment ce concept est-il relié aux autres ?

Nous obtenons presque une progression intellectuelle :

DONNÉE
  ↓
RELATION
  ↓
ENTREPRISE
  ↓
PROCESSUS
  ↓
HISTOIRE
  ↓
CHANGEMENT
  ↓
ÉVÉNEMENT
  ↓
SENS

Il ne faut pas interpréter cette succession comme un remplacement.

C'est précisément l'inverse.

29. Les nouvelles écoles ne tuent presque jamais les anciennes

Voilà probablement l'une des leçons les plus importantes de toute cette histoire.

L'invention du Data Warehouse n'a pas supprimé le modèle relationnel.

Kimball n'a pas supprimé Inmon.

Data Vault n'a pas supprimé Kimball.

Les architectures événementielles n'ont pas supprimé les Data Warehouses.

Les Knowledge Graphs ne vont probablement pas supprimer les modèles dimensionnels.

Pourquoi ?

Parce qu'ils ne résolvent pas exactement le même problème.

Un modèle dimensionnel reste extraordinairement efficace pour répondre à :

Chiffre d'affaires par mois, produit, région et segment client.

Un Knowledge Graph peut être extraordinairement efficace pour explorer :

Quelles relations indirectes existent entre cette personne, ces entreprises, ces contrats et ces bénéficiaires ?

Un Event Store peut être particulièrement adapté pour répondre à :

Quelle séquence exacte d'événements a conduit à cet état ?

Un modèle bitemporel :

Que pensions-nous savoir au 31 décembre ?

Un Data Vault :

Quelle information avons-nous reçue de quelle source, et comment a-t-elle changé ?

Ce ne sont pas six réponses différentes à une question unique.

Ce sont six questions différentes.

30. Et pourtant, l'étoile refuse de mourir

Il y a quelque chose de presque amusant dans l'histoire de la Data.

À chaque révolution technologique, nous annonçons implicitement que les anciennes méthodes vont devenir inutiles.

Big Data.

Hadoop.

Data Lake.

Cloud.

Lakehouse.

Streaming.

IA.

Et pourtant, en 2026, Microsoft documente toujours explicitement :

FACT TABLE
DIMENSION TABLE
STAR SCHEMA

pour Fabric Warehouse et recommande le star schema comme approche de conception pour les workloads analytiques.

Power BI continue également de présenter le star schema comme une approche mature et largement adoptée, particulièrement pertinente pour construire des modèles sémantiques performants et utilisables.

Pourquoi cette persistance ?

Parce que les technologies de stockage ont changé beaucoup plus rapidement que les questions posées par les humains.

Un directeur commercial demande toujours :

Combien avons-nous vendu ?

Par rapport à l'année dernière ?

Dans quelle région ?

Sur quels produits ?

Pour quels clients ?

Avec quelle marge ?

Autrement dit :

MEASURE
   BY
DIMENSION

Et tant que cette structure restera au cœur de l'analyse, la pensée dimensionnelle conservera une pertinence remarquable.

31. Le paradoxe de l'architecture Data moderne

Nous arrivons donc à un paradoxe.

Nous disposons aujourd'hui de plateformes technologiquement incomparables avec celles sur lesquelles travaillaient les pionniers du Data Warehousing.

Stockage objet.

Formats colonne.

Compute distribué.

Streaming.

Cloud.

Serverless.

Delta tables.

Lakehouse.

Semantic models.

Knowledge Graphs.

Large Language Models.

Et pourtant, nous continuons de rencontrer les mêmes questions fondamentales :

Quelle est l'identité du client ?

Quelle est la définition du chiffre d'affaires ?

À quel grain cette donnée existe-t-elle ?

Comment historiser cet attribut ?

Quelle source fait autorité ?

Comment rattacher ces deux objets ?

Que savions-nous à cette date ?

Quelle règle métier a produit cette valeur ?

Comment exposer cette information aux utilisateurs ?

La technologie a changé.

L'épistémologie de la donnée beaucoup moins.

Et c'est précisément pourquoi connaître ces écoles n'est pas un exercice historique.

C'est une manière de disposer de plusieurs modèles mentaux face à un problème d'architecture.

32. Nous pouvons maintenant faire l'expérience décisive

Il nous manque néanmoins quelque chose.

Jusqu'ici, nous avons étudié ces écoles séparément.

C'est confortable.

Mais ce n'est pas ainsi qu'un architecte travaille.

Dans un véritable projet, personne ne vient demander :

Pourriez-vous m'implémenter une belle philosophie de modélisation ?

Le métier arrive plutôt avec quelque chose comme :

Nous avons des clients.

Ils souscrivent des contrats.

Les contrats portent sur des produits.

Les ventes passent par des agences.

Les clients peuvent changer de segment.

Les contrats peuvent changer de statut.

Nous devons analyser le chiffre d'affaires.

Nous devons conserver l'historique.

Et l'audit doit pouvoir expliquer l'origine des données.

Voilà le véritable test.

Prenons exactement le même domaine métier.

Les mêmes clients.

Les mêmes contrats.

Les mêmes produits.

Les mêmes agences.

Les mêmes ventes.

Et donnons-le successivement à :

Inmon.

Kimball.

Linstedt.

Anchor Modeling.

Puis regardons ce qu'ils construisent.

Nous verrons immédiatement que chacun découpe la même réalité d'une manière différente.

Ensuite seulement, nous pourrons poser la question qui compte vraiment :

Quelle architecture choisir aujourd'hui ?

Ou, plus probablement :

Quelles parties de chacune de ces écoles devons-nous combiner ?

C'est l'objet de la dernière partie.

Partie III — Un même métier, cinq modèles : le grand comparatif et l'architecture Data moderne

Dans la dernière partie, nous allons abandonner presque entièrement la théorie abstraite.

Nous partirons d'un domaine unique :

CLIENT
   │
CONTRAT
   │
PRODUIT
   │
VENTE
   │
AGENCE

et nous le reconstruirons selon les différentes philosophies.

Nous comparerons ensuite les approches sur les mêmes critères :

intégration — grain — historisation — auditabilité — évolutivité — performance analytique — lisibilité — coût de développement — complexité — gouvernance.

Enfin, nous replacerons tout cela dans une architecture contemporaine :

Sources
   ↓
Lake / Landing
   ↓
Integration
   ↓
History
   ↓
Business Transformation
   ↓
Dimensional / Semantic Layer
   ↓
BI / AI / Data Products

Et nous pourrons alors répondre à la question qui traverse tout cet article :

Inmon, Kimball, Linstedt et les autres étaient-ils réellement concurrents — ou avons-nous passé trente ans à comparer des réponses destinées à des couches différentes du problème ?

Références complémentaires de cette partie

• Martin Fowler, Event Sourcing — définition, reconstruction d'états historiques, replay et temporal queries.
• W3C, RDF 1.2 Concepts and Abstract Data Model — modèle RDF fondé sur les triplets subject–predicate–object.
• W3C, RDF 1.1 Primer — principes de RDF, ressources, relations et interconnexion de datasets.
• Microsoft, Dimensional modeling in Fabric Data Warehouse — recommandation actuelle du star schema et articulation avec les modèles sémantiques Power BI.
• Microsoft, What is Fabric Data Warehouse? — positionnement actuel de Fabric Warehouse, notamment pour les schémas star/snowflake et les modèles sémantiques gouvernés.