1. Normalisation - Reference Rapide (1NF a 5NF)
| Forme | Regle | En une phrase | Exemple de violation |
| 1NF | Valeurs atomiques, pas de groupes repetitifs | Chaque cellule contient une seule valeur | Colonne telephones contenant "01,02,03" |
| 2NF | 1NF + pas de dependance partielle | Chaque colonne non-cle depend de TOUTE la cle primaire | nom_produit depend seulement de produit_id dans une cle composite (commande_id, produit_id) |
| 3NF | 2NF + pas de dependance transitive | Aucune colonne non-cle ne depend d'une autre colonne non-cle | nom_ville depend de code_postal qui depend de la cle |
| BCNF | 3NF + tout determinant est une cle candidate | Version stricte de 3NF | Un determinant fonctionnel qui n'est pas une super-cle |
| 4NF | BCNF + pas de dependance multivaluee | Pas de colonnes independantes a valeurs multiples | Un employe a plusieurs competences ET plusieurs langues (independantes) |
| 5NF | 4NF + pas de dependance de jointure | La table ne peut pas etre decomposee sans perte | Relations 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
| Etape | Action | Exemple (E-commerce) |
| 1. Choisir le processus metier | Identifier le processus a mesurer | Ventes en ligne |
| 2. Declarer le grain | Definir ce que represente une ligne | Une ligne = une ligne de commande |
| 3. Identifier les dimensions | Le "qui, quoi, ou, quand, comment" | date, client, produit, magasin, promotion |
| 4. Identifier les faits | Les mesures numeriques | quantite, montant_ttc, remise, cout |
Types de Tables de Faits
| Type | Description | Granularite |
| Transaction | Un evenement a un instant T | Une ligne par transaction |
| Periodic Snapshot | Photo a intervalles reguliers | Une ligne par periode |
| Accumulating Snapshot | Cycle de vie d'un processus | Une ligne par entite, mise a jour |
| Factless Fact | Evenement sans mesure | Presence/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)
| Type | Methode | Historique | Colonnes ajoutees | Cas d'usage |
| Type 0 | Pas de changement | Non | Aucune | Donnees fixes (date de naissance) |
| Type 1 | Ecrasement | Non | Aucune | Corrections, donnees non historisees |
| Type 2 | Nouvelle ligne | Oui (complet) | date_debut, date_fin, est_actuel | Historique complet requis (adresse, statut) |
| Type 3 | Nouvelle colonne | Partiel (1 version) | ancien_X, nouveau_X | Un seul changement a tracer |
| Type 4 | Table d'historique separee | Oui | Table dim_X_hist | Dimension tres grande, changements frequents |
| Type 6 | Hybride (1+2+3) | Oui + courant | date_debut, date_fin, est_actuel + colonnes _actuel | Besoin 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
| Critere | Star Schema | Data Vault |
| Objectif | Reporting, BI | Integration, historique |
| Agilite | Schema fixe | Tres flexible |
| Historique | Via SCD | Natif (satellites) |
| Charge | Parallele limite | Tres parallelisable |
| Requetes | Simples (JOIN) | Complexes (multi-JOIN) |
| Couche BI | Directe | Necessite Business Vault |
5. DAMA-DMBOK 2.0 - 11 Knowledge Areas
| # | Knowledge Area | Objectif Principal | Activites Cles |
| 1 | Data Governance | Planifier, superviser, controler | Politiques, standards, roles, comites |
| 2 | Data Architecture | Definir la structure des donnees | Blueprints, modeles, standards, integration |
| 3 | Data Modeling & Design | Representer les besoins en donnees | Conceptuel, logique, physique, normalisation |
| 4 | Data Storage & Operations | Gerer le stockage et les operations | DBA, backup, monitoring, performance |
| 5 | Data Security | Proteger les donnees | Acces, chiffrement, audit, classification |
| 6 | Data Integration & Interoperability | Deplacer et combiner les donnees | ETL, ELT, APIs, MDM, virtualisation |
| 7 | Document & Content Mgmt | Gerer les donnees non structurees | ECM, records management, archivage |
| 8 | Reference & Master Data | Gerer les donnees de reference | MDM, golden record, data matching |
| 9 | Data Warehousing & BI | Fournir des insights | DWH, reporting, dashboards, OLAP |
| 10 | Metadata Management | Gerer les donnees sur les donnees | Catalogues, lineage, glossaire, tags |
| 11 | Data Quality | Assurer la fiabilite | Profiling, 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
| Role | Responsabilite | Profil | Exemple d'action |
| Data Owner | Responsable metier du domaine de donnees | Directeur, VP, Manager senior | Approuve les definitions, autorise les acces |
| Data Steward | Gardien operationnel de la qualite | Analyste metier, expert domaine | Definit les regles de qualite, resout les conflits |
| Data Custodian | Gestion technique et operationnelle | DBA, ingenieur data, IT | Backup, securite, performance, acces techniques |
| Chief Data Officer | Vision strategique des donnees | C-level, Direction Generale | Definit la strategie data, sponsor executif |
| Data Governance Council | Comite de pilotage | Cross-fonctionnel | Valide les politiques, arbitre les conflits |
| Data Architect | Conception de l'architecture | IT / Architecture | Definit les modeles, standards techniques |
7. ETL vs ELT vs Reverse ETL
| Critere | ETL | ELT | Reverse ETL |
| Flux | Extract → Transform → Load | Extract → Load → Transform | Warehouse → Transform → SaaS |
| Transformation | En transit (serveur ETL) | Dans le data warehouse | Avant envoi vers les outils |
| Outils | Informatica, Talend, SSIS | dbt, Spark, SQL natif | Census, Hightouch, Grouparoo |
| Stockage | Donnees transformees seulement | Donnees brutes + transformees | N/A (pousse vers les outils) |
| Performance | Limitee par le serveur ETL | Puissance du cloud DWH | Depend des APIs cibles |
| Scalabilite | Verticale | Horizontale (cloud) | Limitee par les destinations |
| Cout | Licence ETL + serveurs | Compute warehouse (pay-per-use) | Par synchro/ligne |
| Cas d'usage | Legacy, on-premise, compliance | Cloud-native, big data, agilite | Activation data, CRM, marketing |
8. Medallion Architecture (Bronze / Silver / Gold)
| Couche | Contenu | Schema | Qualite | Consommateurs |
| Bronze (Raw) | Donnees brutes, copie exacte des sources | Schema-on-read, format source | Aucun nettoyage | Data Engineers |
| Silver (Cleaned) | Donnees nettoyees, validees, conformees | Schema enforce, types corrects | Dedupliquee, validee, jointe | Data Analysts, Data Scientists |
| Gold (Business) | Donnees agregees, metriques metier | Star schema, KPIs, cubes | Business-ready, documentee | BI, 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
| Critere | Inmon (CIF) | Kimball | Data Vault 2.0 |
| Approche | Top-down (EDW → Data Marts) | Bottom-up (Data Marts → EDW) | Hybride (integration agile) |
| Modele | 3NF normalise | Star Schema (dimensionnel) | Hub-Link-Satellite |
| Agilite | Faible (longue planification) | Moyenne (iteratif) | Elevee (ajout sans refacto) |
| Historisation | Timestamps | SCD Types 0-6 | Natif (insert-only satellites) |
| Audit | Bon | Limite | Excellent (tracabilite complete) |
| Requetes | Complexes (3NF = JOINs) | Simples (star = peu de JOINs) | Tres complexes (multi-JOINs) |
| Cas ideal | Gouvernance forte, single source | BI, dashboards, analytics | Multi-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)
| Architecture | Principe | Golden Record | Sync |
| Registry | Index sans copie | Virtuel (pointeurs) | Lecture seule |
| Consolidation | Copie fusionnee | Physique, lecture seule | Unidirectionnel |
| Coexistence | Golden redistribue | Physique, redistribue | Bidirectionnel |
| Centralized | Hub unique d'ecriture | Physique, source unique | Hub-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
| Type | Contenu | Responsable |
| Technique | Schema, types, DDL, index, partitions | DBA / Data Engineer |
| Business | Definitions, glossaire, KPIs, regles metier | Data Steward / Owner |
| Operationnelle | Dates de chargement, volumes, erreurs, freshness | Data Engineer / Ops |
Outils de Catalogage
| Outil | Type | Forces |
| DataHub | Open Source | Lineage auto, API GraphQL, extensible |
| OpenMetadata | Open Source | UI intuitive, quality integree, profiling |
| Atlan | SaaS | UX moderne, collaboration, lineage riche |
| Collibra | Enterprise | Workflows gouvernance, tres complet |
16. RGPD & Compliance - Reference Rapide
8 Droits RGPD
| Droit | Impact Technique |
| Acces | Export de donnees (API) |
| Rectification | Workflow de modification + audit |
| Effacement (oubli) | Suppression en cascade, propagation |
| Portabilite | Export JSON/CSV standard |
| Opposition | Flags opt-out, filtrage pipelines |
| Limitation | Status "gele" |
| Profilage | Explainability, intervention humaine |
| Information | Politique 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
| Commande | Action |
dbt run | Execute tous les modeles |
dbt test | Execute tous les tests |
dbt build | Run + test + snapshot + seed |
dbt docs generate | Genere la documentation + lineage |
dbt run --select tag:daily | Execute les modeles tagges "daily" |
dbt run --select +fact_revenue | Execute fact_revenue + toutes ses dependances |