La modélisation dimensionnelle est une technique de conception de bases de données orientée vers l’analyse plutôt que vers la transaction. Là où un système transactionnel classique (OLTP) est optimisé pour écrire et modifier des données rapidement, un entrepôt de données (OLAP) est optimisé pour les lire et les agréger efficacement à des fins d’analyse. Elle repose sur deux types de tables : les tables de faits (mesures quantitatives) et les tables de dimensions (contexte descriptif).

• Tables de faits – contiennent les mesures (chiffre d’affaires, quantité vendue, durée). Chaque ligne représente un événement mesurable.
• Tables de dimensions – décrivent le contexte (qui, quoi, où, quand). Exemples : produit, client, date, magasin.

ISOSET propose des cursus complets pour maîtriser ces concepts, essentiels à tout projet BI.

Le schéma en étoile est la forme la plus simple de modélisation dimensionnelle. Une table de faits centrale est directement reliée à plusieurs tables de dimensions, formant visuellement une étoile.

• Structure dénormalisée – les dimensions ne sont pas éclatées en sous-tables, ce qui réduit le nombre de jointures.
• Performances élevées – moins de jointures = requêtes plus rapides, idéal pour Power BI, Tableau, Looker.
• Lisibilité – le modèle est facile à comprendre pour des analystes non spécialistes en bases de données.
• Redondance acceptée – les dimensions peuvent contenir des données dupliquées, compromis conscient en faveur de la vitesse.

# Exemple de schéma en étoile (SQL)
-- Table de faits Ventes
CREATE TABLE ventes_fait (
    id_vente INT PRIMARY KEY,
    id_produit INT,
    id_client INT,
    id_magasin INT,
    id_date INT,
    quantite INT,
    montant DECIMAL(10,2)
);
-- Dimensions
CREATE TABLE produit_dim (...);
CREATE TABLE client_dim (...);
CREATE TABLE magasin_dim (...);
CREATE TABLE date_dim (...);

ISOSET aide les entreprises à implémenter des schémas en étoile pour des rapports rapides et efficaces.

Le schéma en flocon est une extension du Star Schema dans laquelle les tables de dimensions sont elles-mêmes décomposées en sous-dimensions, formant une structure ramifiée qui évoque un flocon de neige.

• Normalisation poussée – chaque dimension est éclatée en plusieurs tables pour éliminer les redondances (ex: Produit → Catégorie → Marque).
• Intégrité des données – moins de duplication signifie moins de risques d’incohérence lors des mises à jour.
• Complexité accrue – davantage de tables et de jointures rendent les requêtes plus lourdes.
• Usage adapté – préféré lorsque les dimensions sont très larges, fréquemment mises à jour, ou lorsque l’espace disque est une contrainte.

# Exemple de dimension normalisée (Snowflake)
CREATE TABLE produit_dim (
    id_produit INT PRIMARY KEY,
    nom_produit VARCHAR(100),
    id_categorie INT
);
CREATE TABLE categorie_dim (
    id_categorie INT PRIMARY KEY,
    nom_categorie VARCHAR(50),
    id_marque INT
);
CREATE TABLE marque_dim (...);

• Privilégiez le Star Schema – si la priorité est la performance des requêtes, la simplicité de maintenance et la facilité d’usage pour les équipes métier.
• Privilégiez le Snowflake – si l’intégrité des données, la réduction de la redondance et la rigueur de modélisation sont des exigences non négociables.

Dans la pratique, de nombreux Data Warehouses adoptent un modèle hybride, combinant les deux approches selon les sujets d’analyse. Comprendre ces arbitrages nécessite non seulement des connaissances techniques, mais aussi une vision métier. ISOSET transmet cette capacité d’analyse dans ses formations.

Une table de faits contient des mesures (additives, semi-additives ou non-additives) et des clés étrangères vers les dimensions. La granularité (niveau de détail) est le choix le plus important : une ligne peut représenter une vente unitaire, un panier, une journée de magasin, etc.

• Faits additifs – peuvent être additionnés selon toutes les dimensions (ex: montant).
• Faits semi-additifs – additionnables selon certaines dimensions seulement (ex: solde bancaire additionnable par client mais pas par date).
• Faits non-additifs – ne peuvent pas être additionnés (ex: pourcentage, prix unitaire).
• Faits sans mesures (factless facts) – tables de faits qui enregistrent des événements sans mesure (ex: présence à un cours).

Les dimensions donnent le « qui, quoi, où, quand ». Elles évoluent dans le temps (un client déménage, un produit change de prix). La gestion des changements dans les dimensions est un sujet clé : les Slowly Changing Dimensions (SCD).

• SCD Type 0 – ne jamais modifier (valeur fixe).
• SCD Type 1 – écraser l’ancienne valeur (perte de l’historique).
• SCD Type 2 – créer une nouvelle ligne avec des dates de validité (consulte l’historique).
• SCD Type 3 – ajouter une colonne « ancienne valeur » (trace limitée).

# Exemple SCD Type 2 (dimension client)
CREATE TABLE client_dim (
    id_client_surrogate INT PRIMARY KEY,
    id_client_naturel INT,
    nom VARCHAR(100),
    ville VARCHAR(50),
    date_debut DATE,
    date_fin DATE,
    est_courant BOOLEAN
);

ISOSET initie les jeunes à ces concepts à travers des exemples ludiques (suivi de personnages de jeux).

Les outils modernes de data warehousing (Snowflake, BigQuery, Redshift, Azure Synapse) et les frameworks ELT (dbt) intègrent nativement les concepts dimensionnels. Avec dbt, on peut définir des modèles (tables de faits, dimensions) en SQL, versionnés, testables et documentés.

# Exemple dbt – modèle de table de faits
{{ config(materialized='table') }}
SELECT
    order_id as id_commande,
    product_id as id_produit,
    customer_id as id_client,
    order_date as id_date,
    quantity as quantite,
    amount as montant
FROM {{ ref('stg_orders') }}

ISOSET forme aux bonnes pratiques d’implémentation avec dbt, Airflow et les entrepôts cloud.

• Granularité mal définie – mélanger plusieurs niveaux de détail dans une même table de faits.
• Dimensions dégénérées – stocker des identifiants transactionnels comme dimension au lieu de les laisser dans la fait.
• Oublier la dimension date – toujours modéliser une dimension date pour les analyses temporelles.
• Sur-normaliser en Star Schema – le Star Schema est dénormalisé, ne pas chercher à normaliser.
• Mauvaise gestion des SCD – ne pas anticiper les évolutions des dimensions métier.

Les témoignages d’anciens élèves d’ISOSET soulignent la clarté de l’approche : *« Je comprenais mal la différence entre Star et Snowflake. Avec les cas pratiques ISOSET, j’ai conçu mon premier Data Warehouse en étoile. Aujourd’hui, nos tableaux de bord sont 10 fois plus rapides. »*