En bref
La table de dimensions fournit le contexte qui donne du sens aux mesures de la table de faits. Large (nombreuses colonnes descriptives) et courte (peu de lignes par rapport aux faits), elle permet de filtrer, grouper et analyser les événements métier selon toutes les perspectives utiles. La gestion des dimensions à évolution lente (SCD) — et en particulier le choix du Type 2 avec conservation de l'historique — est la décision de conception la plus structurante pour la fiabilité analytique à long terme.
Définition complète
Une table de dimensions (dimension table en anglais) est une table qui fournit le contexte descriptif des événements métier enregistrés dans une table de faits. Elle répond aux questions : qui a acheté (dimension Client), quoi (dimension Produit), où (dimension Géographie), quand (dimension Date), par quel canal (dimension Canal). Ce contexte transforme des mesures brutes — 12 000 € de chiffre d'affaires — en information analytique exploitable : 12 000 € de chiffre d'affaires réalisés par des clients PME en Île-de-France, via le canal web, sur le plan Growth, au mois de mars.
Sur le plan physique, la table de dimensions se distingue de la table de faits par sa forme inversée : elle est large (de nombreuses colonnes d'attributs descriptifs — souvent entre 20 et 100 colonnes pour une dimension Client ou Produit) et courte (de quelques milliers à quelques millions de lignes, contre des milliards pour les tables de faits). Dans un schéma en étoile, les tables de dimensions entourent la table de faits centrale et lui sont reliées par des clés étrangères.
Les dimensions les plus courantes dans un entrepôt de données analytique sont : la dimension Client (attributs démographiques, segment, région, ancienneté), la dimension Produit (catégorie, gamme, coût, marge standard), la dimension Date (jour, semaine, mois, trimestre, année fiscale, indicateur de jour ouvré), la dimension Géographie (ville, département, région, pays), et la dimension Canal (web, commercial, partenaire, EDI). Chaque organisation peut également avoir des dimensions métier spécifiques — Campagne marketing, Employé commercial, Agence.
Comment l'implémenter
La conception d'une table de dimensions commence par l'identification exhaustive des attributs descriptifs pertinents pour l'analyse. Chaque attribut par lequel les utilisateurs souhaitent filtrer ou grouper leurs données doit figurer dans la table de dimensions appropriée. La règle de Kimball est explicite : dénormaliser les dimensions — c'est-à-dire intégrer directement dans la table de dimensions les attributs qui, dans un modèle transactionnel normalisé, seraient dans des tables séparées. Cette dénormalisation simplifie les requêtes analytiques et améliore les performances.
Structure type d'une dimension Client
Clé de substitution : client_key (entier généré par l'entrepôt, clé de jointure avec les tables de faits).
Clé naturelle : client_id_source (identifiant du CRM ou ERP, conservé pour réconciliation).
Attributs descriptifs : nom, secteur, taille (PME/ETI/GE), région, ville, code postal, pays, plan tarifaire, date d'acquisition, canal d'acquisition, chargé de compte.
Attributs SCD Type 2 : date_debut_validite, date_fin_validite, est_courant (booléen pour identifier la ligne active).
La gestion des Slowly Changing Dimensions (SCD) — dimensions à évolution lente — est la décision de conception la plus structurante. Le Type 2 est le standard moderne : lorsqu'un attribut change (un client passe du segment PME au segment ETI), une nouvelle ligne est ajoutée avec les nouvelles valeurs et une date de début de validité, et l'ancienne ligne est fermée avec une date de fin de validité. Cela permet d'analyser les données historiques avec les valeurs correctes à chaque période, garantissant la cohérence des analyses dans le temps.
Comparaison des types SCD
Type 0 : aucun changement autorisé — l'attribut est immuable (ex : date de naissance).
Type 1 : écrasement — la valeur est remplacée, pas d'historique conservé. Adapté aux corrections d'erreurs.
Type 2 : historique complet — nouvelle ligne à chaque changement avec dates d'effet. Standard recommandé pour les attributs analytiquement significatifs.
Type 3 : valeur précédente conservée dans une colonne dédiée — un seul niveau d'historique.
Exemple concret
Considérons une entreprise SaaS B2B française avec 850 clients actifs. La dimension Client contient 850 lignes courantes, plus les lignes historiques pour les clients qui ont changé de segment ou de plan tarifaire — soit environ 1 200 lignes au total après deux ans d'activité. Chaque ligne contient 35 attributs : identifiant, raison sociale, SIREN, secteur NAF, effectif, région administrative, département, ville, code postal, plan Fairview actuel, montant MRR, date de signature du premier contrat, canal d'acquisition, nom du chargé de compte, et les colonnes SCD (date de début et de fin de validité, indicateur de ligne courante).
En janvier 2026, le client Dupont & Associés (SIREN 123456789) passe du plan Growth (349 €/mois) au plan Scale (699 €/mois). Avec un SCD Type 2, l'ancienne ligne est fermée (date_fin_validite = 31/01/2026, est_courant = false) et une nouvelle ligne est créée (date_debut_validite = 01/02/2026, plan = Scale, est_courant = true). Les analyses de chiffre d'affaires réalisé en décembre 2025 utiliseront automatiquement l'ancienne ligne (plan Growth), tandis que les analyses de février 2026 utiliseront la nouvelle ligne (plan Scale). Sans SCD Type 2, toutes les analyses historiques de ce client refléteraient incorrectement le plan Scale.
La dimension Date de cette même entreprise est construite une fois pour toutes et contient 3 650 lignes (10 ans), avec 28 attributs par ligne : date complète, jour de la semaine (1-7 et libellé), numéro de semaine ISO, mois (numéro et libellé), trimestre, semestre, année civile, année fiscale (si différente), indicateur de jour ouvré, indicateur de week-end, indicateur de jour férié français, indicateur de premier jour du mois, indicateur de dernier jour du mois, etc. Cette richesse d'attributs permet aux équipes opérationnelles de construire n'importe quelle analyse temporelle sans calcul SQL complexe.
Analyse approfondie
Les dimensions conformées (conformed dimensions) sont un concept architectural central dans les entrepôts de données multi-domaines. Une dimension est dite conformée lorsqu'elle est partagée entre plusieurs tables de faits ou plusieurs data marts. Par exemple, si la même dimension Client est utilisée dans le data mart Commercial (table de faits Opportunités), dans le data mart Finance (table de faits Factures) et dans le data mart Support (table de faits Tickets), alors ces trois domaines peuvent être analysés conjointement sans ambiguïté — le même client_key référence le même client dans les trois contextes. Les dimensions conformées sont le fondement de l'architecture de bus de Kimball.
La dimension de déchets (junk dimension) est un pattern pratique pour gérer les attributs de faible cardinalité qui ne méritent pas une table de dimension propre. Par exemple, un événement de transaction peut avoir des indicateurs booléens (commande urgente : oui/non, client B2B : oui/non, première commande : oui/non). Plutôt que d'ajouter ces drapeaux directement dans la table de faits — ce qui la rendrait plus large et violerait les principes du modèle dimensionnel — on les regroupe dans une table de junk dimension avec une clé de substitution. La table de faits ne contient alors qu'une seule clé étrangère vers cette dimension.
La mini-dimension est un pattern complémentaire pour gérer les attributs à évolution rapide dans une grande dimension. Si une dimension Client contient 10 millions de lignes et que certains attributs — comme le segment de valeur calculé chaque mois ou le score de risque churn — changent fréquemment, le SCD Type 2 appliqué à ces attributs produirait un volume de lignes historiques ingérable. La solution est d'extraire ces attributs à évolution rapide dans une table séparée (mini-dimension) avec sa propre clé de substitution, référencée par la table de faits plutôt que par la dimension principale.
La role-playing dimension est un pattern qui se présente lorsqu'une même dimension physique doit être utilisée plusieurs fois dans une même table de faits, chacune avec un rôle différent. Par exemple, une table de faits Commandes peut avoir trois références à la dimension Date : date de commande, date de livraison prévue, date de livraison effective. Dans le modèle physique, ces trois rôles partagent la même table de dimension Date, mais apparaissent dans le schéma logique comme trois dimensions distinctes — souvent implémentées comme des vues SQL sur la table Date physique.
La hiérarchie au sein d'une dimension est une source fréquente de complexité. Une dimension Géographie peut contenir plusieurs niveaux : ville, département, région, pays. Une dimension Produit peut avoir : référence, sous-catégorie, catégorie, gamme, marque. Dans un modèle dimensionnel dénormalisé, tous ces niveaux sont des colonnes dans la même table — ce qui simplifie les requêtes au prix d'une légère redondance. L'approche normalisée (snowflake) crée des tables séparées pour chaque niveau, reliées entre elles — ce qui réduit la redondance mais complexifie les requêtes et dégrade les performances analytiques pour un gain de stockage marginal dans les entrepôts modernes.
Erreurs fréquentes dans la conception des tables de dimensions
- ✗
Utiliser la clé naturelle comme clé de jointure avec la table de faits : si le système source réutilise des identifiants, les supprime ou en change le format, toute la cohérence du modèle est compromise. La clé de substitution — un entier séquentiel généré par l'entrepôt — garantit la stabilité des jointures indépendamment des évolutions des systèmes sources. La clé naturelle doit figurer dans la dimension comme attribut, mais jamais comme clé de jointure vers la table de faits.
- ✗
Appliquer le SCD Type 1 (écrasement) par défaut sans réfléchir aux conséquences analytiques : écraser les valeurs d'attributs sans conserver l'historique est souvent le choix de facilité technique. Mais si un client change de région en juin, et que toutes les analyses antérieures reflètent désormais la nouvelle région, les rapports Q1 et Q2 deviennent incohérents. Le SCD Type 2 est plus complexe à implémenter, mais il est le seul qui garantit que les analyses historiques restent exactes à mesure que les données évoluent.
- ✗
Normaliser les dimensions (schéma en flocon) pour économiser du stockage : décomposer une dimension Client en tables Client, Secteur, Région, Plan, reliées par des jointures, réduit légèrement la redondance de stockage — mais rend chaque requête analytique plus complexe, dégrade les performances, et n'apporte aucun avantage réel dans les entrepôts de données modernes où le coût du stockage est marginal. La dénormalisation des dimensions est un principe fondamental du modèle en étoile, pas un compromis : elle simplifie les requêtes, améliore les performances et facilite la compréhension du modèle par les utilisateurs métier.
Comment Fairview gère les dimensions opérationnelles
Fairview construit et maintient automatiquement les dimensions opérationnelles à partir de vos sources de données — CRM, outils de facturation, ERP. La dimension Client est enrichie en continu depuis Stripe, HubSpot ou Salesforce selon la configuration de votre workspace. Les changements de plan tarifaire, de segment ou de chargé de compte sont gérés en SCD Type 2 par défaut : chaque modification est historisée avec une date d'effet, garantissant que vos analyses rétrospectives restent cohérentes même si la composition de votre base clients évolue.
La dimension Date dans Fairview est préconstruite avec l'ensemble des attributs temporels pertinents pour les opérations SaaS : périodes de facturation, semaines glissantes, comparaisons de périodes (mois sur mois, trimestre sur trimestre), et fenêtres de rétention pour l'analyse des cohortes. Vos équipes opérationnelles n'ont pas besoin de construire des requêtes SQL complexes pour analyser l'évolution d'une métrique sur 13 semaines glissantes ou comparer les performances par trimestre fiscal.
En un coup d'œil
- Catégorie
- Business Intelligence
- Termes associés
- 4 termes
- Standard SCD recommandé
- Type 2 (historique)
- Temps de lecture
- 10 min
Questions fréquentes
Qu'est-ce qu'une Slowly Changing Dimension (SCD) et quels types existent ?
Une SCD est une dimension dont les attributs évoluent dans le temps. Le Type 0 ignore les changements. Le Type 1 écrase la valeur sans conserver l'historique. Le Type 2 — le standard moderne — ajoute une nouvelle ligne avec les nouvelles valeurs et des dates d'effet, en conservant l'ancienne ligne pour les analyses historiques. Le Type 3 conserve l'ancienne valeur dans une colonne dédiée mais ne gère qu'un seul niveau d'historique.
Quelle est la différence entre une dimension conforme et une dimension locale ?
Une dimension conformée est partagée entre plusieurs tables de faits ou data marts, permettant des analyses croisées cohérentes. Par exemple, une dimension Client commune aux data marts Commercial et Finance permet d'analyser les ventes et les paiements sur les mêmes clients sans ambiguïté. Une dimension locale (ou junk dimension) regroupe des attributs de faible cardinalité spécifiques à un processus métier — comme des indicateurs booléens — qui ne méritent pas une table de dimension propre.
Pourquoi utiliser une clé de substitution plutôt que la clé naturelle ?
La clé de substitution est un entier généré par l'entrepôt, indépendant des systèmes sources. Elle est indispensable pour le SCD Type 2 — plusieurs lignes pour un même client dans le temps ont chacune leur propre clé de substitution. Elle protège aussi contre les changements de format ou de valeur des clés naturelles dans les systèmes sources. La clé naturelle est conservée comme attribut de la dimension pour la réconciliation, mais n'est jamais utilisée comme clé de jointure avec la table de faits.
Qu'est-ce qu'une dimension date et pourquoi est-elle indispensable ?
La dimension date est une table à part entière — pas une simple colonne de date — qui contient des attributs précalculés : jour de la semaine, numéro de semaine ISO, mois, trimestre, année, indicateur de jour ouvré, période fiscale, etc. Ces attributs permettent aux outils de BI de filtrer et grouper selon n'importe quelle granularité temporelle sans calcul ad hoc. Une dimension date bien construite contient entre 10 et 50 attributs. Elle est présente dans presque toutes les tables de faits et constitue la dimension la plus universelle du modèle dimensionnel.
Découvrez-le dans Fairview
Des dimensions gérées automatiquement.
Démo en direct de 25 minutes. Fairview construit et maintient vos dimensions opérationnelles avec historique SCD Type 2 — sans ingénierie data de votre part.