Modélisation dimensionnelle — la théorie derrière dim et fact

Vous êtes ici : Comprendre — les fondations : pourquoi dim et fact sont modélisés ainsi. La théorie de la modélisation dimensionnelle, puis ce que GS-Apps en applique réellement — chaque affirmation sourcée. Lecture 15 min. Audience : devs, data engineers. Date : 2026-07-17 | Version : 1.0 — création (MASTER-DOCS-LEXIQUE-DIMENSIONNEL) ; état observé au 2026-07-17

TL;DR

Question	Réponse	Source
Quel patron de modélisation ?	Modèle dimensionnel en étoile (`fact` au centre, `dim` autour), au sein du médaillon	ADR-056 (amendement 2026-06-30) ; Architecture de données §2
Des clés de substitution ?	Oui — GUID générés pour les dimensions (la clé source est conservée à part), entiers auto-incrémentés pour les faits	DDL observé (`packages/db/sql`)
Quel type de SCD ?	Type 1 (écrasement) sur toutes les dimensions observées — aucune historisation par versions à ce jour	DDL observé — aucune colonne `valid_from` / `valid_to` / `is_current`
Les dimensions sont-elles conformes ?	Oui — partagées entre la BI et les apps (données de référence)	Architecture de données §2 ; FK OLTP vers `dim.*` observées
Kimball ou Inmon ?	Démarche dimensionnelle bottom-up (proche Kimball), construite domaine par domaine ; aucun entrepôt 3NF à la Inmon	ADR-056 D7 (pilote par domaine) ; analyse ci-dessous

1. Fait et dimension — les deux familles

Toute question analytique a la même forme : une mesure, découpée par un vocabulaire. « Combien de dollars de factures (mesure) par succursale (découpage) par mois (découpage) ? »

Une table de faits enregistre des événements mesurables : une ligne par événement, des colonnes numériques (les mesures) et des références vers les dimensions. Elle est longue (beaucoup de lignes) et étroite de sens (un seul type d’événement).
Une table de dimension décrit un objet du monde : un véhicule, une succursale, un client, une date. Elle est courte (quelques dizaines à quelques milliers de lignes) mais riche en attributs — c’est par eux qu’on filtre et qu’on regroupe.

La distinction est une question à se poser devant chaque table : est-ce quelque chose qui arrive (fait) ou quelque chose qui existe (dimension) ?

2. Le schéma en étoile

La forme canonique du modèle dimensionnel : la table de faits au centre, ses dimensions autour, jointes par clé. Le nom vient du dessin.

L’étoile réelle de GS-Apps : fact.invoices au centre, ses cinq dimensions autour. Chaque flèche est une référence fait-vers-dimension.

Pourquoi cette forme plutôt qu’un modèle normalisé ? Parce que la question analytique type se traduit alors en une jointure par découpage — simple à écrire, prévisible à optimiser, lisible par un outil de BI. La variante flocon (snowflake) normalise les dimensions entre elles (la succursale pointe sa région au lieu de répéter le nom de région) : moins de redondance, une jointure de plus.

3. Le grain — la première décision

Le grain est la définition exacte de ce que représente une ligne de la table de faits : « une ligne = une facture », « une ligne = un punch d’employé par jour ». C’est la première décision de toute modélisation — avant les mesures, avant les dimensions — parce que tout en découle : une mesure n’a de sens qu’au grain déclaré, et on ne peut pas joindre proprement deux faits de grains différents.

Les mesures se classent par rapport au grain :

Type	Définition	Exemple
Additive	Sommable sur toutes les dimensions	Montant d’une facture — sommable par mois, par client, par succursale
Semi-additive	Sommable sur certaines dimensions seulement	Un solde ou un niveau de stock — sommable par succursale, pas dans le temps
Non additive	Jamais sommable ; se recalcule	Un ratio, un pourcentage — on additionne numérateur et dénominateur, jamais le ratio

4. Clés de substitution

Une clé de substitution (surrogate key) est une clé technique générée par la plateforme — par opposition à la clé naturelle, l’identifiant du système source (numéro d’employé, code de succursale). On substitue pour trois raisons :

Découpler du système source — si la source recode ses identifiants, fusionne, ou qu’une deuxième source arrive avec les mêmes numéros, le modèle ne bouge pas.
Permettre l’historisation — une dimension historisée (SCD type 2, ci-dessous) a plusieurs lignes pour le même objet source ; seule une clé générée peut les distinguer.
Uniformiser les jointures — toutes les dimensions se joignent de la même façon, y compris celles qui n’ont pas de clé source propre (le calendrier).

La clé naturelle n’est pas perdue : elle reste en colonne, sous contrainte d’unicité — c’est par elle que l’ETL retrouve la ligne à mettre à jour.

5. SCD — que faire quand une dimension change

Les objets décrits par les dimensions changent lentement : un employé change de succursale, un véhicule change de statut. Les stratégies classiques (Slowly Changing Dimensions) :

Type	Stratégie	On gagne	On perd
Type 1	Écraser la valeur ; la ligne reflète l’état courant	Simplicité — une ligne par objet	L’histoire : les faits passés se relisent avec l’état d’aujourd’hui
Type 2	Historiser : nouvelle ligne à chaque changement, bornée par `valid_from` / `valid_to` + drapeau `is_current`	La vérité historique — chaque fait se joint à la version en vigueur à sa date	Complexité : clés de substitution obligatoires, ETL plus riche, dimensions plus longues
Type 3	Colonne « valeur précédente » à côté de la valeur courante	Comparer avant/après un changement précis	Une seule étape d’historique ; rarement suffisant

Le choix se fait attribut par attribut, selon la question métier : « le coût de ce bon doit-il rester rattaché à la succursale de l’époque ? » exige du type 2 sur cet attribut ; « on veut juste l’adresse à jour » se contente du type 1.

6. Dimensions conformes

Une dimension est conforme quand plusieurs tables de faits — voire plusieurs systèmes — partagent la même table de dimension, avec les mêmes clés et les mêmes attributs. C’est ce qui rend les analyses croisées possibles : si les factures et les bons de maintenance pointent la même dim.branches, « coût total par succursale » a un sens ; si chacun a sa propre table de succursales, rien ne se recoupe. Dans la démarche de Kimball, l’ensemble des dimensions conformes forme le bus de l’entrepôt : chaque nouveau domaine s’y branche au lieu de réinventer son vocabulaire.

7. Kimball et Inmon — les deux écoles

	Kimball (dimensionnel, bottom-up)	Inmon (entrepôt d’entreprise, top-down)
Point de départ	Un processus métier à la fois (facturation, maintenance…)	Le modèle d’entreprise complet d’abord
Modèle central	Étoiles fait/dimension, reliées par les dimensions conformes (le « bus »)	Entrepôt normalisé (3NF) ; les marts dimensionnels en sont dérivés
Livraison	Incrémentale — chaque domaine livre de la valeur seul	Longue phase de fondation avant la première valeur
Force	Rapidité, lisibilité BI, adoption progressive	Cohérence globale forte, source unique très formalisée
Risque	Dérive si les dimensions ne sont pas réellement conformes	Effet tunnel ; coût initial élevé

Les deux écoles convergent sur un point : la couche servie aux outils d’analyse est dimensionnelle. Le débat porte sur ce qu’il y a en amont.

8. Comment GS-Apps l’applique — l’état observé

Chaque affirmation de cette section cite sa source : un ADR, ou le DDL versionné (packages/db/sql) et le schéma réel de la base, inspectés lors de la rédaction (2026-07-17).

Le patron : une étoile dans le médaillon

La couche servie du médaillon comprend un modèle dimensionnel en étoile : schémas dim (8 dimensions : régions, succursales, clients, véhicules, employés, projets, points de service, calendrier) et fact (fact.invoices, fact.plans), aux côtés de gold (agrégats). C’est formalisé par l’ADR-056 (amendement 2026-06-30 : « dim/fact font partie du même standard médaillon ») et décrit dans Architecture de données §2.

Clés de substitution : oui, en deux saveurs

Dimensions : clé primaire id UNIQUEIDENTIFIER générée (DEFAULT NEWID()), la clé naturelle SOFI conservée à part sous contrainte d’unicité par compagnie (UNIQUE (code_sofi, company_id) sur dim.branches, UNIQUE (no_client, company_id) sur dim.customers, etc.) — observé dans le DDL de création des dimensions.
Faits : clé de substitution BIGINT IDENTITY (FactureKey, PlanFactKey) — observé dans le DDL.
Exception assumée : dim.calendar utilise une clé intelligente date_key INT (la date encodée en entier) comme clé primaire — le patron classique des dimensions date, où la clé est stable par nature.

SCD : type 1 partout, à ce jour

Aucune dimension observée ne porte de colonnes d’historisation (valid_from / valid_to / is_current) : les mises à jour écrasent la valeur — c’est du SCD type 1. Le suivi se limite au pack standard de la plateforme (updated_at, version, is_active en soft-delete) et à l’horodatage de synchronisation (sofi_synced_at). Conséquence à connaître : les faits passés se relisent toujours avec l’état courant de la dimension (un véhicule transféré de succursale emporte son historique de coûts avec lui). Aucun ADR ne fige ce choix comme définitif — c’est l’état observé.

Les liens fait-dimension

fact.invoices référence ses dimensions par colonnes UNIQUEIDENTIFIER (projet_id, client_id, succursale_id, employee_id) vers les id de dim.*, et par DateKey INT vers dim.calendar.date_key — observé. Deux particularités héritées, visibles dans le DDL :

Les tables de faits portent encore les clés entières legacy de l’ancienne génération analytique (ProjetKey, ClientKey, SuccursaleKey…) à côté des références GUID — les deux jeux coexistent.
Les références fait-vers-dimension sont logiques (par convention de jointure), sans contrainte FOREIGN KEY déclarée en base ; sur silver, le DDL les annote explicitement « FK logique ». Les FK déclarées existent en revanche entre dimensions (dim.vehicles vers dim.branches vers dim.regions ; dim.projects vers dim.customers) — l’étoile est donc légèrement floconnée au niveau des dimensions.

Dimensions conformes — jusque dans l’OLTP

Les dimensions servent la BI et les apps : la page Architecture de données documente les dim.* comme données de référence des apps, et le DDL le confirme jusqu’à la contrainte — le domaine inventaire déclare de vraies FK OLTP vers dim.service_points. C’est la version GS-Apps de la dimension conforme : une seule table de succursales, de véhicules ou de points de service, pour tous les consommateurs.

Multi-tenant par construction

Toutes les dimensions et tables de faits portent company_id NOT NULL et sont couvertes par la RLS (fn_company_predicate, politique par schéma) — décision ADR-056 D6, état vérifié dans Architecture de données §3. Seule dim.calendar n’a pas de company_id : le calendrier est une dimension globale, identique pour toutes les compagnies.

Positionnement Kimball / Inmon

Aucun ADR ne revendique une école par son nom. Les choix observés — modèle en étoile, dimensions conformes partagées, construction domaine par domaine (le pilote maintenance/RDS de l’ADR-056 D7, puis les suivants) — relèvent de la démarche dimensionnelle bottom-up de Kimball, sans en adopter tous les canons (pas d’historisation SCD 2, clés GUID plutôt qu’entières sur les dimensions, FK fait-dimension non déclarées). Il n’existe pas d’entrepôt normalisé 3NF à la Inmon, et rien dans les ADR n’en projette un.

Pour aller plus loin

Architecture de données — la structure : schémas, médaillon, RLS, connexion.
Cycle de vie des données — comment l’ETL alimente ces tables.
Lexique technique — tous les acronymes de cette page en une ligne chacun.
ADR-056 — Architecture médaillon — les décisions D1-D7 et l’amendement qui formalise dim/fact.
ADR-094 — Une seule trajectoire de base — base unique, déclencheur charge, chemin réel du médaillon.
ADR-039 — Architecture de données 2026 — constats techniques (columnstore, etc.) ; trajectoire « Option C » remplacée par ADR-094.