Cheatsheet - Phase 2

Modelisation & Design | Reference Rapide

1. Normalisation - Reference Rapide (1NF a 5NF)

FormeRegleEn une phraseExemple de violation
1NFValeurs atomiques, pas de groupes repetitifsChaque cellule contient une seule valeurColonne telephones contenant "01,02,03"
2NF1NF + pas de dependance partielleChaque colonne non-cle depend de TOUTE la cle primairenom_produit depend seulement de produit_id dans une cle composite (commande_id, produit_id)
3NF2NF + pas de dependance transitiveAucune colonne non-cle ne depend d'une autre colonne non-clenom_ville depend de code_postal qui depend de la cle
BCNF3NF + tout determinant est une cle candidateVersion stricte de 3NFUn determinant fonctionnel qui n'est pas une super-cle
4NFBCNF + pas de dependance multivalueePas de colonnes independantes a valeurs multiplesUn employe a plusieurs competences ET plusieurs langues (independantes)
5NF4NF + pas de dependance de jointureLa table ne peut pas etre decomposee sans perteRelations ternaires decomposables en relations binaires
Regle pratique : En OLTP, viser 3NF/BCNF. En OLAP/Data Warehouse, denormaliser (star schema) pour les performances de lecture.

2. Kimball Star Schema - Checklist

Les 4 Etapes Kimball

EtapeActionExemple (E-commerce)
1. Choisir le processus metierIdentifier le processus a mesurerVentes en ligne
2. Declarer le grainDefinir ce que represente une ligneUne ligne = une ligne de commande
3. Identifier les dimensionsLe "qui, quoi, ou, quand, comment"date, client, produit, magasin, promotion
4. Identifier les faitsLes mesures numeriquesquantite, montant_ttc, remise, cout

Types de Tables de Faits

TypeDescriptionGranularite
TransactionUn evenement a un instant TUne ligne par transaction
Periodic SnapshotPhoto a intervalles reguliersUne ligne par periode
Accumulating SnapshotCycle de vie d'un processusUne ligne par entite, mise a jour
Factless FactEvenement sans mesurePresence/absence (couverture)

Template SQL - Star Schema

-- Table de dimension
CREATE TABLE dim_produit (
    produit_sk    INT PRIMARY KEY,       -- Surrogate key
    produit_nk    VARCHAR(20) NOT NULL,  -- Natural/business key
    nom           VARCHAR(200),
    categorie     VARCHAR(100),
    sous_categorie VARCHAR(100),
    marque        VARCHAR(100),
    prix_unitaire DECIMAL(10,2),
    date_debut    DATE,
    date_fin      DATE,
    est_actuel    BOOLEAN DEFAULT TRUE
);

-- Table de faits
CREATE TABLE fait_ventes (
    date_sk       INT REFERENCES dim_date(date_sk),
    produit_sk    INT REFERENCES dim_produit(produit_sk),
    client_sk     INT REFERENCES dim_client(client_sk),
    magasin_sk    INT REFERENCES dim_magasin(magasin_sk),
    quantite      INT,
    montant_ht    DECIMAL(12,2),
    montant_ttc   DECIMAL(12,2),
    remise        DECIMAL(10,2),
    cout          DECIMAL(12,2),
    marge         DECIMAL(12,2)
);

3. Slowly Changing Dimensions (SCD)

TypeMethodeHistoriqueColonnes ajouteesCas d'usage
Type 0Pas de changementNonAucuneDonnees fixes (date de naissance)
Type 1EcrasementNonAucuneCorrections, donnees non historisees
Type 2Nouvelle ligneOui (complet)date_debut, date_fin, est_actuelHistorique complet requis (adresse, statut)
Type 3Nouvelle colonnePartiel (1 version)ancien_X, nouveau_XUn seul changement a tracer
Type 4Table d'historique separeeOuiTable dim_X_histDimension tres grande, changements frequents
Type 6Hybride (1+2+3)Oui + courantdate_debut, date_fin, est_actuel + colonnes _actuelBesoin d'historique ET de valeur courante

Template SCD Type 2

-- Insertion du nouvel enregistrement
INSERT INTO dim_client (client_sk, client_nk, nom, ville, date_debut, date_fin, est_actuel)
VALUES (nextval('seq_client'), 'C-1001', 'Jean Dupont', 'Lyon',
        CURRENT_DATE, '9999-12-31', TRUE);

-- Fermeture de l'ancien enregistrement
UPDATE dim_client
SET date_fin = CURRENT_DATE - 1, est_actuel = FALSE
WHERE client_nk = 'C-1001'
  AND est_actuel = TRUE
  AND client_sk != currval('seq_client');

4. Data Vault 2.0 - Composants

HUB (Entite metier)

  • hash_key - MD5/SHA-1 de la business key
  • business_key - Cle naturelle
  • load_date - Date de premier chargement
  • record_source - Systeme source
CREATE TABLE hub_client (
  hub_client_hk  CHAR(32) PRIMARY KEY,
  client_bk      VARCHAR(50) NOT NULL,
  load_date      TIMESTAMP NOT NULL,
  record_source  VARCHAR(100)
);

LINK (Relation/Association)

  • hash_key - MD5/SHA-1 des BKs combinees
  • FK vers chaque Hub implique
  • load_date + record_source
CREATE TABLE lnk_client_commande (
  lnk_cli_cmd_hk   CHAR(32) PRIMARY KEY,
  hub_client_hk     CHAR(32) NOT NULL,
  hub_commande_hk   CHAR(32) NOT NULL,
  load_date         TIMESTAMP NOT NULL,
  record_source     VARCHAR(100)
);

SATELLITE (Attributs descriptifs)

  • FK vers Hub ou Link parent
  • load_date - Debut de validite
  • load_end_date - Fin de validite
  • hash_diff - Hash des attributs (detection de changement)
  • Colonnes descriptives
CREATE TABLE sat_client_details (
  hub_client_hk  CHAR(32) NOT NULL,
  load_date      TIMESTAMP NOT NULL,
  load_end_date  TIMESTAMP DEFAULT '9999-12-31',
  hash_diff      CHAR(32) NOT NULL,
  nom            VARCHAR(200),
  email          VARCHAR(200),
  ville          VARCHAR(100),
  record_source  VARCHAR(100),
  PRIMARY KEY (hub_client_hk, load_date)
);

Comparaison Star Schema vs Data Vault

CritereStar SchemaData Vault
ObjectifReporting, BIIntegration, historique
AgiliteSchema fixeTres flexible
HistoriqueVia SCDNatif (satellites)
ChargeParallele limiteTres parallelisable
RequetesSimples (JOIN)Complexes (multi-JOIN)
Couche BIDirecteNecessite Business Vault

5. DAMA-DMBOK 2.0 - 11 Knowledge Areas

#Knowledge AreaObjectif PrincipalActivites Cles
1Data GovernancePlanifier, superviser, controlerPolitiques, standards, roles, comites
2Data ArchitectureDefinir la structure des donneesBlueprints, modeles, standards, integration
3Data Modeling & DesignRepresenter les besoins en donneesConceptuel, logique, physique, normalisation
4Data Storage & OperationsGerer le stockage et les operationsDBA, backup, monitoring, performance
5Data SecurityProteger les donneesAcces, chiffrement, audit, classification
6Data Integration & InteroperabilityDeplacer et combiner les donneesETL, ELT, APIs, MDM, virtualisation
7Document & Content MgmtGerer les donnees non structureesECM, records management, archivage
8Reference & Master DataGerer les donnees de referenceMDM, golden record, data matching
9Data Warehousing & BIFournir des insightsDWH, reporting, dashboards, OLAP
10Metadata ManagementGerer les donnees sur les donneesCatalogues, lineage, glossaire, tags
11Data QualityAssurer la fiabiliteProfiling, cleansing, monitoring, regles
Moyen mnemotechnique : "GAMS SI DR WMQ" - Governance, Architecture, Modeling, Storage, Security, Integration, Documents, Reference, Warehousing, Metadata, Quality.

6. Roles de la Gouvernance des Donnees

RoleResponsabiliteProfilExemple d'action
Data OwnerResponsable metier du domaine de donneesDirecteur, VP, Manager seniorApprouve les definitions, autorise les acces
Data StewardGardien operationnel de la qualiteAnalyste metier, expert domaineDefinit les regles de qualite, resout les conflits
Data CustodianGestion technique et operationnelleDBA, ingenieur data, ITBackup, securite, performance, acces techniques
Chief Data OfficerVision strategique des donneesC-level, Direction GeneraleDefinit la strategie data, sponsor executif
Data Governance CouncilComite de pilotageCross-fonctionnelValide les politiques, arbitre les conflits
Data ArchitectConception de l'architectureIT / ArchitectureDefinit les modeles, standards techniques

7. ETL vs ELT vs Reverse ETL

CritereETLELTReverse ETL
FluxExtract → Transform → LoadExtract → Load → TransformWarehouse → Transform → SaaS
TransformationEn transit (serveur ETL)Dans le data warehouseAvant envoi vers les outils
OutilsInformatica, Talend, SSISdbt, Spark, SQL natifCensus, Hightouch, Grouparoo
StockageDonnees transformees seulementDonnees brutes + transformeesN/A (pousse vers les outils)
PerformanceLimitee par le serveur ETLPuissance du cloud DWHDepend des APIs cibles
ScalabiliteVerticaleHorizontale (cloud)Limitee par les destinations
CoutLicence ETL + serveursCompute warehouse (pay-per-use)Par synchro/ligne
Cas d'usageLegacy, on-premise, complianceCloud-native, big data, agiliteActivation data, CRM, marketing

8. Medallion Architecture (Bronze / Silver / Gold)

CoucheContenuSchemaQualiteConsommateurs
Bronze (Raw)Donnees brutes, copie exacte des sourcesSchema-on-read, format sourceAucun nettoyageData Engineers
Silver (Cleaned)Donnees nettoyees, validees, conformeesSchema enforce, types correctsDedupliquee, validee, jointeData Analysts, Data Scientists
Gold (Business)Donnees agregees, metriques metierStar schema, KPIs, cubesBusiness-ready, documenteeBI, Executives, ML models

Pipeline type

[Sources]     [Bronze]           [Silver]              [Gold]
APIs     -->  raw_orders    -->  clean_orders     -->  fact_ventes
DBs      -->  raw_clients   -->  clean_clients    -->  dim_client
Files    -->  raw_produits  -->  clean_produits   -->  dim_produit
Streams  -->  raw_events    -->  clean_events     -->  kpi_daily_sales
Bonnes pratiques : Toujours conserver le Bronze (immuable). Silver = source de verite. Gold = optimise pour la consommation. Utiliser des tables Delta/Iceberg pour le versioning.

9. Data Mesh - 4 Principes

1. Domain Ownership

Chaque domaine metier possede et gere ses propres donnees. Les equipes domaine sont responsables de la qualite, du schema et du cycle de vie de leurs donnees.

Exemple : L'equipe "Commandes" gere toutes les donnees de commandes, de la source a l'exposition.

2. Data as a Product

Les donnees sont traitees comme un produit avec des standards de qualite : decouvrable, adressable, fiable, autodescriptive, interoperable, securisee.

Exemple : Un "data product" commandes avec SLA, documentation, contrat de schema.

3. Self-Serve Data Platform

Une plateforme interne qui abstrait la complexite technique et permet aux equipes domaine de creer, deployer et gerer leurs data products de maniere autonome.

Exemple : Templates dbt, CI/CD automatise, infrastructure as code, catalogue centralise.

4. Federated Computational Governance

Gouvernance decentralisee avec des politiques globales appliquees automatiquement. Standards communs, interoperabilite assuree, conformite automatisee.

Exemple : Schemas globaux, conventions de nommage, regles de qualite automatisees via la plateforme.

Quand adopter le Data Mesh ? Organisations grandes (50+ data engineers), multiples domaines metier, equipes decentralisees, besoin d'agilite. Quand eviter ? Petites equipes, donnees simples, organisation centralisee.

10. Templates SQL DDL

Table de Dimension (Star Schema)

CREATE TABLE dim_date (
    date_sk          INT PRIMARY KEY,
    date_complete    DATE NOT NULL UNIQUE,
    jour             INT,
    mois             INT,
    annee            INT,
    trimestre        INT,
    semaine_iso      INT,
    nom_jour         VARCHAR(10),     -- Lundi, Mardi...
    nom_mois         VARCHAR(15),     -- Janvier, Fevrier...
    est_weekend      BOOLEAN,
    est_ferie        BOOLEAN,
    saison           VARCHAR(15)
);

Table de Faits (Star Schema)

CREATE TABLE fait_ventes (
    date_sk       INT NOT NULL REFERENCES dim_date(date_sk),
    produit_sk    INT NOT NULL REFERENCES dim_produit(produit_sk),
    client_sk     INT NOT NULL REFERENCES dim_client(client_sk),
    magasin_sk    INT NOT NULL REFERENCES dim_magasin(magasin_sk),
    promo_sk      INT REFERENCES dim_promotion(promo_sk),
    -- Mesures additives
    quantite      INT NOT NULL,
    montant_ht    DECIMAL(12,2) NOT NULL,
    montant_ttc   DECIMAL(12,2) NOT NULL,
    remise        DECIMAL(10,2) DEFAULT 0,
    cout_achat    DECIMAL(12,2),
    marge         DECIMAL(12,2),
    -- Mesures semi-additives
    stock_fin     INT
);

Hub (Data Vault)

CREATE TABLE hub_produit (
    hub_produit_hk   CHAR(32) PRIMARY KEY,  -- MD5(produit_bk)
    produit_bk       VARCHAR(50) NOT NULL,
    load_date        TIMESTAMP NOT NULL,
    record_source    VARCHAR(100) NOT NULL
);

Link (Data Vault)

CREATE TABLE lnk_vente (
    lnk_vente_hk     CHAR(32) PRIMARY KEY,
    hub_client_hk     CHAR(32) NOT NULL REFERENCES hub_client(hub_client_hk),
    hub_produit_hk    CHAR(32) NOT NULL REFERENCES hub_produit(hub_produit_hk),
    hub_date_hk       CHAR(32) NOT NULL REFERENCES hub_date(hub_date_hk),
    load_date         TIMESTAMP NOT NULL,
    record_source     VARCHAR(100) NOT NULL
);

Satellite (Data Vault)

CREATE TABLE sat_produit_details (
    hub_produit_hk    CHAR(32) NOT NULL,
    load_date         TIMESTAMP NOT NULL,
    load_end_date     TIMESTAMP DEFAULT '9999-12-31 23:59:59',
    hash_diff         CHAR(32) NOT NULL,
    nom_produit       VARCHAR(200),
    categorie         VARCHAR(100),
    prix_unitaire     DECIMAL(10,2),
    poids_kg          DECIMAL(8,3),
    record_source     VARCHAR(100),
    PRIMARY KEY (hub_produit_hk, load_date)
);

Requete Analytique Type

-- Top 10 produits par chiffre d'affaires mensuel
SELECT
    d.annee,
    d.nom_mois,
    p.categorie,
    p.nom AS produit,
    SUM(f.montant_ttc)   AS ca_total,
    SUM(f.quantite)      AS qte_totale,
    SUM(f.marge)         AS marge_totale,
    ROUND(SUM(f.marge)/NULLIF(SUM(f.montant_ht),0)*100, 1) AS taux_marge_pct
FROM fait_ventes f
JOIN dim_date d    ON f.date_sk    = d.date_sk
JOIN dim_produit p ON f.produit_sk = p.produit_sk
WHERE d.annee = 2024
GROUP BY d.annee, d.nom_mois, d.mois, p.categorie, p.nom
ORDER BY d.mois, ca_total DESC
FETCH FIRST 10 ROWS ONLY;

11. Inmon vs Kimball vs Data Vault - Decision

CritereInmon (CIF)KimballData Vault 2.0
ApprocheTop-down (EDW → Data Marts)Bottom-up (Data Marts → EDW)Hybride (integration agile)
Modele3NF normaliseStar Schema (dimensionnel)Hub-Link-Satellite
AgiliteFaible (longue planification)Moyenne (iteratif)Elevee (ajout sans refacto)
HistorisationTimestampsSCD Types 0-6Natif (insert-only satellites)
AuditBonLimiteExcellent (tracabilite complete)
RequetesComplexes (3NF = JOINs)Simples (star = peu de JOINs)Tres complexes (multi-JOINs)
Cas idealGouvernance forte, single sourceBI, dashboards, analyticsMulti-sources, agilite, audit
Conseil : En pratique, combinez Data Vault (couche persistance) + Kimball Star Schema (couche presentation BI). Architecture : Sources → Raw Vault → Business Vault → Data Marts (Star) → BI.

12. Lambda & Kappa Architecture

Lambda (Nathan Marz, 2011)

  • Batch Layer : traitement complet (Spark, heures)
  • Speed Layer : temps reel (Kafka/Flink, secondes)
  • Serving Layer : fusion des vues

Probleme : duplication de code (batch + stream)

Kappa (Jay Kreps, 2014)

  • Un seul pipeline streaming
  • Log immutable (Kafka) = source de verite
  • Retraitement par replay du log

Avantage : un seul codebase, simplification

Lambda:  Sources --> [Batch Layer] + [Speed Layer] --> [Serving Layer]
Kappa:   Sources --> [Kafka Log] --> [Stream Processing] --> [Serving Layer]
Regle : Choisir Kappa par defaut. Lambda seulement si batch complexe indispensable.

13. OBT & Activity Schema

One Big Table (OBT)

  • Denormalisation totale en une seule table large
  • Zero JOINs, optimal avec moteurs colonnaires
  • Trade-off : simplicite vs duplication
  • Ideal : dashboards specifiques, BigQuery/Snowflake

Activity Schema

  • 4 colonnes : entity_id, activity, timestamp, properties (JSON)
  • Chaque ligne = un evenement
  • Ideal : product analytics, funnels, retention
  • Tres flexible grace au JSON

14. Master Data Management (MDM)

ArchitecturePrincipeGolden RecordSync
RegistryIndex sans copieVirtuel (pointeurs)Lecture seule
ConsolidationCopie fusionneePhysique, lecture seuleUnidirectionnel
CoexistenceGolden redistribuePhysique, redistribueBidirectionnel
CentralizedHub unique d'ecriturePhysique, source uniqueHub-and-spoke

Match & Merge

-- Match probabiliste avec pg_trgm (PostgreSQL)
SELECT a.id, b.id,
       similarity(a.nom, b.nom) AS score
FROM clients a JOIN clients b ON a.id < b.id
WHERE similarity(a.nom, b.nom) > 0.7
   OR similarity(a.email, b.email) > 0.8;

15. Metadata & Data Catalog

TypeContenuResponsable
TechniqueSchema, types, DDL, index, partitionsDBA / Data Engineer
BusinessDefinitions, glossaire, KPIs, regles metierData Steward / Owner
OperationnelleDates de chargement, volumes, erreurs, freshnessData Engineer / Ops

Outils de Catalogage

OutilTypeForces
DataHubOpen SourceLineage auto, API GraphQL, extensible
OpenMetadataOpen SourceUI intuitive, quality integree, profiling
AtlanSaaSUX moderne, collaboration, lineage riche
CollibraEnterpriseWorkflows gouvernance, tres complet

16. RGPD & Compliance - Reference Rapide

8 Droits RGPD

DroitImpact Technique
AccesExport de donnees (API)
RectificationWorkflow de modification + audit
Effacement (oubli)Suppression en cascade, propagation
PortabiliteExport JSON/CSV standard
OppositionFlags opt-out, filtrage pipelines
LimitationStatus "gele"
ProfilageExplainability, intervention humaine
InformationPolitique de confidentialite

Pseudonymisation vs Anonymisation

-- Pseudonymisation (reversible, reste sous RGPD)
SELECT md5(client_id || 'salt') AS pseudo_id, segment, ville FROM clients;

-- Anonymisation (irreversible, hors RGPD)
UPDATE clients SET nom='ANONYMISE', email=NULL WHERE date_suppression IS NOT NULL;
Classification : Public → Interne → Confidentiel → Restreint. Notification breach RGPD : 72 heures. Sanction max : 4% CA mondial ou 20M€.

17. Data Fabric & Semantic Layer

Data Fabric

  • Architecture metadata-driven
  • Knowledge graphs pour la decouverte
  • IA pour classification, matching, recommandations
  • Vendors : Informatica, IBM, Denodo

Semantic Layer

  • Definitions metier sur donnees physiques
  • Metriques, dimensions, hierarchies
  • Outils : dbt Metrics, Cube.dev, AtScale
  • Pont entre technique et metier
Data Fabric vs Data Mesh : Fabric = approche technologique (metadata + IA). Mesh = approche organisationnelle (domaines). Complementaires : Fabric peut etre la plateforme self-serve du Mesh.

18. dbt - Structure Projet & Commandes

my_project/
├── dbt_project.yml        # Config projet
├── models/
│   ├── staging/           # Silver (1:1 sources)
│   │   ├── _sources.yml
│   │   └── stg_orders.sql
│   ├── intermediate/      # Logique intermediaire
│   └── marts/             # Gold (business models)
│       └── fact_revenue.sql
├── tests/                 # Tests custom SQL
├── macros/                # Fonctions Jinja
├── seeds/                 # CSV de reference
└── snapshots/             # SCD Type 2 auto

Commandes Essentielles

CommandeAction
dbt runExecute tous les modeles
dbt testExecute tous les tests
dbt buildRun + test + snapshot + seed
dbt docs generateGenere la documentation + lineage
dbt run --select tag:dailyExecute les modeles tagges "daily"
dbt run --select +fact_revenueExecute fact_revenue + toutes ses dependances