Dans un entrepôt de données, les dimensions portent le qui, quoi, où, quand, pourquoi et comment d'un événement métier. Les faits portent les mesures, les dimensions portent le contexte qui les rend lisibles.
C'est la réponse à la question la plus posée sur le sujet en informatique décisionnelle, celle de la différence entre table de faits et table de dimension. Le schéma en étoile relie les deux par des relations clé primaire / clé étrangère, et une table de dimension possède une seule colonne de clé primaire.
Des libellés, pas des codes
Une règle de conception paraît anodine et décide pourtant de l'usage réel de l'entrepôt : les attributs de dimension les plus puissants sont ceux qui portent des libellés verbeux, et non des codes.
Un attribut qui vaut « Client grand compte, secteur public » se lit dans un tableau de bord. Un attribut qui vaut « GC-PU-03 » oblige à maintenir un dictionnaire à côté, et ce dictionnaire finit toujours par diverger de la donnée.
Pourquoi la clé du système opérationnel ne peut pas servir
Voici le point qui surprend le plus les équipes venant du transactionnel. La clé primaire d'une dimension ne peut pas être la clé naturelle du système opérationnel.
La raison est simple une fois énoncée : un même objet aura plusieurs lignes dès lors qu'on historise ses changements. Un même client existera en trois exemplaires si son adresse a changé deux fois, et une clé unique côté source ne peut pas identifier trois lignes.
La règle est donc de créer des clés primaires entières anonymes pour chaque dimension. Une seule exception existe, et elle est explicite : la dimension date est la seule exemptée de la règle de la clé de substitution.
Les dimensions à évolution lente, une décision et non un constat
Ralph Kimball a introduit la notion de dimension à évolution lente en 1996. Trente ans plus tard, elle reste présentée partout comme une typologie à connaître, ce qui manque l'essentiel.
Le type retenu n'est pas une propriété de la donnée. C'est une décision à rendre avec les représentants de la gouvernance des données, c'est-à-dire une réponse que l'entreprise choisit d'apporter à une question métier : quand un attribut change, que doit devenir le passé ?
En type 1, l'ancienne valeur est écrasée par la nouvelle, ce qui détruit l'historique. En type 2, il faut ajouter au minimum trois colonnes à la ligne de dimension, et le passé est préservé.
Un exemple rend l'arbitrage tangible. Sur une dimension Client en type 2, dans une PME qui suit 4 200 clients, un déménagement de la région Bretagne vers la région Occitanie crée une deuxième ligne, avec une date de début, une date de fin et un indicateur de ligne courante. Le chiffre d'affaires 2024 reste rattaché à la Bretagne, au lieu de basculer rétroactivement en Occitanie.
Aucune des deux réponses n'est techniquement supérieure. La question posée à la direction commerciale est celle-ci : voulez-vous que vos historiques régionaux se réécrivent quand un client déménage ? Le type de SCD ne fait qu'enregistrer sa réponse.
Un détail de nomenclature, souvent pris pour de l'arbitraire, achève d'éclairer la logique : le type 5 s'appelle ainsi parce que 4 plus 1 font 5, et le type 6 parce que 2 plus 3 plus 1 font 6. Les types dits supérieurs sont des combinaisons des précédents, pas des mécanismes nouveaux.
Une même dimension, plusieurs rôles
Un mécanisme revient massivement dans les recherches sur le sujet, et il est plus simple qu'il n'en a l'air. Une même dimension physique peut être référencée plusieurs fois dans une table de faits, chaque référence correspondant à un rôle logiquement distinct.
Le cas d'école est la date : une commande a une date de commande, une date d'expédition et une date de livraison. Ce sont trois références vers la même table calendrier, avec trois rôles différents.
L'erreur consiste à créer trois tables. Elle triple la maintenance et garantit qu'un jour les trois divergeront, alors qu'une seule table référencée trois fois répond exactement au besoin.
Deux dimensions conformes, au sens strict
Le terme circule beaucoup et sa définition est plus exigeante que son usage courant. Deux dimensions sont conformes quand leurs attributs portent les mêmes noms de colonnes et les mêmes domaines de valeurs.
Pas des noms équivalents ni des valeurs comparables : les mêmes. C'est cette identité littérale qui permet ensuite de rapprocher deux jeux de mesures sans conversion.
Le cas limite : la dimension dégénérée
Il existe une dimension qui n'a pas de table. Une dimension dégénérée n'a aucun contenu en dehors de sa clé, et se place directement dans la table de faits.
Le numéro de commande en est l'exemple type : il sert à regrouper des lignes, mais il ne porte aucun attribut descriptif qui justifierait une table à part. Lui en créer une produirait une table à une seule colonne, jointe pour rien.
Pourquoi une table calendrier plutôt que des fonctions de date
La question revient à chaque projet : pourquoi stocker les dates dans une table alors que le SQL sait les calculer ?
La réponse tient dans un exemple. La dimension calendrier existe pour éviter de recalculer en SQL des dates comme Pâques, qu'il faut lire dans la table. Les jours fériés mobiles, les semaines fiscales et les périodes de clôture propres à l'entreprise ne se déduisent d'aucune formule universelle.
Ce que cela demande à l'outil
Tout ce qui précède désigne une compétence précise attendue d'une solution de business intelligence : savoir exploiter une dimension historisée, c'est-à-dire lire la bonne version d'un attribut à la date de l'événement mesuré.
Notre catalogue en recense 26, et parmi elles, 12 offres facturées par utilisateur et par mois s'échelonnent de 12,1 € à 115 € HT.
C'est sur ce point que se joue la différence entre deux outils d'apparence équivalente, et notre comparateur aide à les départager : un outil incapable de gérer l'indicateur de ligne courante affichera les ventes passées sous les attributs d'aujourd'hui, en silence et sans jamais signaler d'erreur.
Sources
- Kimball Group, Dimension Table Structure
- Kimball Group, Dimensions for Context
- Kimball Group, Dimension Surrogate Keys
- Kimball Group, Design Tip 152, Slowly Changing Dimension Types
- Kimball Group, Slowly Changing Dimension Type 1
- Kimball Group, Slowly Changing Dimension Type 2
- Kimball Group, Conformed Dimensions
- Kimball Group, Role-Playing Dimensions
- Kimball Group, Degenerate Dimensions
- Kimball Group, Star Schemas and OLAP Cubes
- Kimball Group, Calendar Date Dimension
