Inmon, Kimball et Data Vault

Résumé

Trois façons de modéliser un entrepôt de données. Inmon construit d’abord un entrepôt d’entreprise normalisé (3NF), puis en tire des data marts. Kimball modélise directement des processus métier en tables de faits et de dimensions, reliées par des dimensions conformées. Data Vault sépare les identifiants (Hubs), les relations (Links) et les attributs historisés (Satellites) pour tracer chaque donnée. Elles se combinent : on voit souvent un Data Vault ou un entrepôt normalisé en couche d’intégration, et un modèle dimensionnel en couche de présentation.

Prérequis

Normalisation 2NF et 3NF pour comprendre la 3NF. Le vocabulaire (grain, SCD, dimension conforme) est dans le Glossaire data engineering.

Comparaison

Aspect	Inmon	Kimball	Data Vault
Point de départ	Modèle de données d’entreprise	Processus métier à mesurer	Clés métier des sources
Ordre	Entrepôt d’abord, marts ensuite	Un mart par processus, intégrés par des dimensions conformées	Raw Vault d’abord, marts ensuite
Modèle	3NF dans l’entrepôt, dimensionnel dans les marts	Dimensionnel (étoile)	Hubs, Links, Satellites
Historique	Entrepôt « non volatil et historisé »	Géré par type de SCD par dimension	Complet, insert-only
Changement de schéma source	Rigide	Modéré	Souple : on ajoute des satellites
Interrogeable par le métier	Via les marts	Directement	Via une couche de présentation
Démarrage	Long	Rapide	Long (modèle peu intuitif)
Coût en jointures	Élevé en 3NF	Faible en étoile	Élevé ; on ajoute des tables PIT et Bridge

Inmon : l’entrepôt d’entreprise

Pour Inmon, un entrepôt est orienté sujet, intégré, historisé et non volatil. On intègre les sources dans un entrepôt central en 3NF, au niveau de détail le plus fin, puis on dérive des data marts pour chaque besoin. Son architecture complète s’appelle la Corporate Information Factory (CIF), qui inclut un ODS (voir Staging, ODS, DWH et architecture médaillon).

flowchart LR
    S[Sources] --> L[Staging / landing] --> E["EDW<br/>3NF, atomique"] --> M["Data marts<br/>dénormalisés"] --> B[BI]

Force : une intégration cohérente à l’échelle de l’entreprise. Coût : démarrage long, équipe spécialisée.

Kimball : le modèle dimensionnel

Kimball part des processus métier (une commande, un appel, un encaissement). Pour chacun, on choisit le grain (une ligne = une ligne de commande, par exemple), on crée une table de faits au grain le plus fin disponible, entourée de dimensions descriptives.

erDiagram
    FAIT_VENTES }o--|| DIM_DATE : "date"
    FAIT_VENTES }o--|| DIM_PRODUIT : "produit"
    FAIT_VENTES }o--|| DIM_CLIENT : "client"

Les marts d’un même entrepôt partagent des dimensions conformées (la même DIM_PRODUIT partout), organisées par la bus matrix (processus en lignes, dimensions en colonnes). C’est ce qui garantit des chiffres comparables d’un mart à l’autre et évite la dispersion.

L’historique des attributs d’une dimension se gère par type de Slowly Changing Dimension (SCD) : type 1 écrase, type 2 ajoute une ligne datée, type 3 garde l’ancienne valeur dans une colonne. On utilise des clés de substitution pour ne pas dépendre des clés des sources.

Force : livrer vite un modèle lisible par le métier. Limite : la discipline des dimensions conformées est indispensable ; sans elle, on retombe dans des marts isolés.

Data Vault : la traçabilité

Data Vault sépare les données en trois objets :

• Hubs : un identifiant métier unique par entité (client, produit), avec une clé de substitution, la source et la date de chargement.
• Links : les relations entre hubs.
• Satellites : les attributs descriptifs, historisés par date de chargement.

Les données sont chargées sans jamais être modifiées ni supprimées (insert-only). Le Raw Vault garde les données telles que reçues, un Business Vault optionnel y ajoute des règles métier, et des marts dimensionnels (souvent à la Kimball) servent la BI. Le Raw Vault offre une version unique des faits tels que les sources les ont fournis ; ce n’est pas un entrepôt normalisé à la Inmon.

flowchart LR
    S[Sources] --> G[Staging] --> R["Raw Vault<br/>Hubs, Links, Satellites"] --> BV["Business Vault<br/>(optionnel)"] --> DM["Data marts<br/>dimensionnels"] --> B[BI]

Exemple minimal pour des clients et leurs commandes :

Objet	Table	Contenu
Hub	hub_client	client_hk (clé de hachage), client_id (clé métier), load_date, record_source
Hub	hub_commande	commande_hk, commande_id, load_date, record_source
Link	link_client_commande	link_hk, client_hk, commande_hk, load_date, record_source
Satellite	sat_client	client_hk, load_date, nom, ville, hash_diff ; une ligne par changement

Force : audit complet, ajout de sources sans casser l’existant, chargements parallélisables. Limites : beaucoup de tables, jointures nombreuses (d’où les tables PIT et Bridge), modèle peu intuitif.

Insert-only et droit à l'effacement

Un historique qui n’est jamais supprimé entre en tension avec le droit à l’effacement du RGPD. Les solutions courantes : isoler les données personnelles dans des satellites dédiés qu’on peut purger, ou chiffrer ces champs et détruire la clé (crypto-shredding). « Conforme par construction » est donc inexact : l’auditabilité aide, mais l’effacement demande une conception explicite. La note Maintenance d’un lakehouse traite le même problème côté lakehouse.

Choisir

• Peu de sources, équipe réduite, besoin de livrer vite : Kimball.
• Beaucoup de sources qui changent, audit exigé (finance, santé, assurance) : Data Vault en intégration, Kimball en présentation.
• Exigence d’un modèle d’entreprise unique et d’une forte gouvernance : Inmon, ou un entrepôt normalisé équivalent.
• En dbt, une couche d’intégration puis une couche de marts dimensionnels est un montage courant, mais ce n’est pas une règle : voir dbt — Fondamentaux.

À vérifier avant de s'appuyer dessus

Le nombre exact de niveaux de la CIF et la place précise de l’ODS selon Inmon proviennent de sources secondaires. Consulter Building the Data Warehouse (Inmon) avant de citer.

Sources

• Bill Inmon, Building the Data Warehouse.
• Ralph Kimball et Margy Ross, The Data Warehouse Toolkit.
• Dan Linstedt et Michael Olschimke, Building a Scalable Data Warehouse with Data Vault 2.0.
• Synthèse de comparaison : Keboola, Kimball vs Inmon.

Notes liées

• Schéma en étoile, de bout en bout : un modèle dimensionnel construit.
• Slowly Changing Dimensions, types 0 à 3 : gérer les attributs de dimension qui changent.
• Data mesh : l’approche décentralisée, par opposition à l’entrepôt central.
• Normalisation 2NF et 3NF : la 3NF d’Inmon et la dénormalisation dimensionnelle.
• Staging, ODS, DWH et architecture médaillon : où ces modèles s’insèrent dans le flux de données.
• Glossaire data engineering : grain, SCD, clé de substitution.
• MOC Data Engineering : carte du vault.