Data Modeling Patterns: Choosing the Right Architecture

La modélisation des données est le socle structurel de toute plateforme analytique. Un mauvais modèle ralentit les requêtes, déroute les analystes et rend l'évolution du schéma pénible. Le bon modèle accélère la production d'insights et évolue avec l'entreprise.

Comparaison des Approches de Modélisation

Approche	Structure	Performance Requêtes	Flexibilité	Complexité	Idéal Pour
Schéma en Étoile	Tables de faits + dimensions dénormalisées	Excellente — peu de jointures	Moyenne	Faible	Dashboards BI, requêtes connues
Schéma en Flocon	Tables de faits + dimensions normalisées	Bonne — plus de jointures	Élevée	Moyenne	Sensibilité stockage, sources normalisées
Data Vault 2.0	Hubs + Links + Satellites	Variable — nécessite des marts	Très élevée	Élevée	Industries réglementées, auditabilité
One Big Table (OBT)	Table unique large dénormalisée	Excellente — zéro jointure	Faible	Très faible	Petites équipes, analytique mono-domaine

Kimball vs Inmon : Le Grand Débat

Dimension	Kimball (Bottom-Up)	Inmon (Top-Down)
Point de départ	Processus métier / département	Modèle de données d'entreprise
Structure centrale	Schémas dimensionnels en étoile	Entrepôt de données 3NF
Data marts	Construits en premier, conformes dans le temps	Dérivés de l'entrepôt central
Délai premier résultat	Semaines	Mois
Ãvolution du schema	Moderee	Complexe — effets en cascade
Taille d'équipe requise	Petite à moyenne	Grande, équipe dédiée
Pertinence moderne	Élevée — compatible dbt/lakehouse	Moyenne — grandes entreprises

Couches de Modélisation dbt

┌─────────────────────────────────────────────────────────┐
│               Structure Projet dbt                      │
├─────────────────────────────────────────────────────────┤
│  Sources    → Références systèmes externes              │
│  Staging    → Nettoyage, renommage, déduplication       │
│  Intermediate → Logique métier, jointures               │
│  Marts      → Tables exposées : faits et dimensions     │
│  Metrics    → Définitions de la couche sémantique       │
└─────────────────────────────────────────────────────────┘

Arbre de Décision pour le Choix du Pattern

Départ : Quelle est votre contrainte principale ?

├── "Rapidité de livraison"
│   ├── Petit jeu de données (< 50 Go) ? → One Big Table (OBT)
│   └── Jeu plus volumineux ? → Schéma en Étoile (Kimball)
│
├── "Réglementation / auditabilité"
│   └── Historique complet + lignage ? → Data Vault 2.0
│
├── "Flexibilité des requêtes"
│   ├── Requêtes connues et stables ? → Schéma en Étoile
│   └── Ad-hoc, exploratoire ? → Schéma en Flocon ou Data Vault + Marts
│
└── "Taille et compétences de l'équipe"
    ├── < 3 data engineers ? → OBT ou Schéma en Étoile
    └── Ãquipe de modelisation dediee ? → Data Vault ou Inmon 3NF

Anti-Patterns à Éviter

Anti-Pattern	Symptôme	Correction
Table divine	200+ colonnes, granularités mélangées	Décomposer en faits/dimensions
Soft deletes partout	Drapeaux `is_deleted` qui gonflent les tables	Utiliser SCD Type 2 ou archivage
Logique métier dans l'outil BI	Métriques divergentes entre dashboards	Pousser la logique dans dbt / couche sémantique
Pas de déclaration de grain	Analystes incertains de ce que représente une ligne	Documenter le grain par modèle

Ressources

:::