tadata
← Retour à l'accueil

Patterns de Modélisation de Données : Choisir la Bonne Architecture

#data-modeling#data-engineering#analytics#data-warehouse

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

ApprocheStructurePerformance RequêtesFlexibilitéComplexitéIdéal Pour
Schéma en ÉtoileTables de faits + dimensions dénormaliséesExcellente — peu de jointuresMoyenneFaibleDashboards BI, requêtes connues
Schéma en FloconTables de faits + dimensions normaliséesBonne — plus de jointuresÉlevéeMoyenneSensibilité stockage, sources normalisées
Data Vault 2.0Hubs + Links + SatellitesVariable — nécessite des martsTrès élevéeÉlevéeIndustries réglementées, auditabilité
One Big Table (OBT)Table unique large dénormaliséeExcellente — zéro jointureFaibleTrès faiblePetites équipes, analytique mono-domaine
tadata
fact_sales FK date_key FK customer_sk FK product_sk FK store_sk Σ quantity Σ net_amount Σ discount_amount Σ cost_amount dim_date PK date_key date month quarter fiscal_year is_holiday dim_product PK product_sk product_id name subcategory category (denormalised) dim_customer PK customer_sk customer_id (business key) segment city valid_from valid_to is_current dim_store PK store_sk store_id region format 1 N 1 N 1 N 1 N Grain: one row per order line Schéma en étoile des ventes dans l'entrepôt gold
fact_sales FK date_key FK customer_sk FK product_sk FK store_sk Σ quantity Σ net_amount Σ discount_amount Σ cost_amount dim_date PK date_key date month quarter fiscal_year is_holiday dim_product PK product_sk product_id name subcategory category (denormalised) dim_customer PK customer_sk customer_id (business key) segment city valid_from valid_to is_current dim_store PK store_sk store_id region format 1 N 1 N 1 N 1 N Grain: one row per order line Schéma en étoile des ventes dans l'entrepôt gold

Extrait de la fiche « DP-600 Prepare Data (2): Transform and Query » · Demander la fiche complète

Kimball vs Inmon : Le Grand Débat

DimensionKimball (Bottom-Up)Inmon (Top-Down)
Point de départProcessus métier / départementModèle de données d'entreprise
Structure centraleSchémas dimensionnels en étoileEntrepôt de données 3NF
Data martsConstruits en premier, conformes dans le tempsDérivés de l'entrepôt central
Délai premier résultatSemainesMois
Évolution du schemaModereeComplexe — effets en cascade
Taille d'équipe requisePetite à moyenneGrande, équipe dédiée
Pertinence moderneÉlevée — compatible dbt/lakehouseMoyenne — grandes entreprises

Couches de Modélisation dbt

tadata
  1. 1. Sources
  2. 2. Staging (stg_)
  3. 3. Intermédiaire (int_)
  4. 4. Marts (fct_, dim_)
  5. 5. Métriques (mtc_)
Sources
données brutes : références aux systèmes externes, contrôles de fraîcheur
Staging (stg_)
nettoyage 1:1 : renommage, typage, déduplication ; un modèle par table source
Intermédiaire (int_)
jointures de logique métier, agrégations entre modèles de staging
Marts (fct_, dim_)
exposés aux consommateurs : tables de faits et de dimensions
Métriques (mtc_)
définitions de la couche sémantique pour les outils BI
Structure d'un projet dbt et rôle de chaque couche

Arbre de Décision pour le Choix du Pattern

tadata
  • 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 modélisation dédiée ? → Data Vault ou Inmon 3NF

Anti-Patterns à Éviter

Anti-PatternSymptômeCorrection
Table divine200+ colonnes, granularités mélangéesDécomposer en faits/dimensions
Soft deletes partoutDrapeaux is_deleted qui gonflent les tablesUtiliser SCD Type 2 ou archivage
Logique métier dans l'outil BIMétriques divergentes entre dashboardsPousser la logique dans dbt / couche sémantique
Pas de déclaration de grainAnalystes incertains de ce que représente une ligneDocumenter le grain par modèle
tadata
SCD type 1 (overwrite): customer 42 moves from Lyon to Paris ✗ 42 | Ana | Paris (Lyon is lost) ✗ MERGE ... WHEN MATCHED THEN UPDATESET * ✗ one row per key, small, simple ✗ use for corrections and attributes nobodyreports on historically SCD type 2 (history): a new row, the old one closed ✓ 42 | Ana | Lyon | 2024-01-10 | 2026-09-30 |current = false ✓ 42 | Ana | Paris | 2026-10-01 | null |current = true ✓ facts join on the surrogate key or on datebetween valid_from and valid_to ✓ pipelines: AUTO CDC ... STORED AS SCD TYPE2 adds __START_AT / __END_AT keep history
SCD type 1 (overwrite): customer 42 moves from Lyon to Paris ✗ 42 | Ana | Paris (Lyon is lost) ✗ MERGE ... WHEN MATCHED THEN UPDATESET * ✗ one row per key, small, simple ✗ use for corrections and attributes nobodyreports on historically SCD type 2 (history): a new row, the old one closed ✓ 42 | Ana | Lyon | 2024-01-10 | 2026-09-30 |current = false ✓ 42 | Ana | Paris | 2026-10-01 | null |current = true ✓ facts join on the surrogate key or on datebetween valid_from and valid_to ✓ pipelines: AUTO CDC ... STORED AS SCD TYPE2 adds __START_AT / __END_AT keep history

Extrait de la fiche « DP-750 Domain 3a: Model and Ingest Data in Unity Catalog » · Demander la fiche complète

Ressources

Nous utilisons des cookies analytiques pour améliorer votre expérience. Aucune donnée personnelle n'est collectée.