Organisation hiérarchique et attributs des dimensions

Le chapitre précédent a permis de poser les fondations de la modélisation en définissant la structure générale des modèles en étoile et en flocon. Cependant, dans un entrepôt de données en production, les dimensions sont rarement figées : elles évoluent dans le temps, accumulent de forts volumes de données et nécessitent une conception minutieuse. Avant d’explorer, au fil de ce chapitre, la gestion de ces cycles de vie complexes (dimensions à évolution lente, optimisation et stockage), il convient de consolider la manière dont une dimension s’organise en son sein.

Au-delà de leur rôle, les dimensions doivent être organisées de manière cohérente à travers des attributs, qu’ils soient de navigation ou descriptifs.

Chaque table de dimension est identifiée par une clé primaire, qui la relie aux tables de faits via des clés étrangères. Cette structuration permet de garantir la cohérence entre les faits et leurs axes d’analyse.

Par exemple, une dimension Temps peut contenir les attributs suivants : Date, Semaine, Mois, Année, et peut être liée à une table de faits Ventes à travers une clé étrangère Date_de_vente.

En modélisation...

Conception et optimisation des hiérarchies et niveaux d’agrégation

Une hiérarchie est une organisation logique d’attributs (ou de niveaux) dans une dimension, permettant de représenter des relations d’inclusions ou d’agrégation de ces attributs.

Elle permet de précalculer (lors de la mise à jour du cube) les liens entre les niveaux de détail pour une navigation optimale dans les données en roll-up ou drill-down.

Trois grands types de hiérarchies sont à distinguer :

Hiérarchie équilibrée : une hiérarchie est dite équilibrée quand toutes ses branches vont jusqu’au même niveau de détail. C’est généralement le cas dans des structures bien définies, telles qu’une organisation basée sur le temps (Année → Trimestre → Mois → Jour) ou sur la géographie (Pays → Région → Ville). Cette forme de hiérarchie est avantageuse en termes de simplicité de modélisation et d’efficacité d’exploitation, en particulier pour les agrégations.

Elle convient très bien quand la structure métier est stable, claire et qu’il n’y a pas de particularité à gérer selon les cas.

Hiérarchie déséquilibrée : à l’inverse, une hiérarchie déséquilibrée se caractérise par...

Gestion des Slowly Changing Dimensions (SCD)

Une dimension sert, comme vu précédemment, à contextualiser les faits. Contrairement aux faits, les données des dimensions sont susceptibles d’évoluer dans le temps, ce qui implique des ajustements dans leur modélisation.

Ces évolutions peuvent être gérées de différentes manières, en fonction du besoin en historisation, de la volumétrie, et des capacités de traitement de l’ETL ou de l’ELT.

Prenons un exemple : un client peut changer d’adresse, de nom, de segment marketing ou de statut. De tels changements soulèvent une question clé : faut-il conserver une trace de ces évolutions ? Et si oui, de quelle façon ?

C’est à ce niveau qu’intervient la gestion des Slowly Changing Dimensions (SCD). Ce terme désigne les techniques de modélisation qui permettent de gérer l’évolution lente des données de dimension tout en préservant la cohérence des analyses historiques.

1. Typologie des SCD (type 0, 1, 2, 3…)

La gestion de l’évolution des données de dimension repose sur plusieurs stratégies appelées Slowly Changing Dimensions (SCD). Si les premiers types (de 0 à 3) sont universellement reconnus et font l’objet d’un consensus, il faut noter que la terminologie pour les types hybrides plus avancés (5, 6, et parfois 7) peut varier. Les définitions ne sont pas toujours standardisées à l’identique entre les différents ouvrages ou implémentations. On distingue classiquement les types principaux suivants :

Type 0 - Figé (Read-only) : aucune modification n’est autorisée : les données de la dimension restent figées, même si les valeurs changent dans la source. Exemple : une dimension dim_temps (dates, jours fériés, etc.) dont le contenu est stable. Avantage : simplicité de gestion, cohérence assurée dans le temps. Inconvénient : ne convient pas aux dimensions susceptibles d’évoluer.
Type 1 - Écrasement sans historique : les changements écrasent directement la valeur existante dans la dimension, sans conserver d’historique....

Modélisation des dimensions complexes

1. Multi-hiérarchies et relations parent-enfant

Les dimensions complexes apparaissent lorsque la structure ou le contenu des dimensions dépasse le cadre d’une hiérarchie simple ou d’une valeur unique par clé.

Ces structures nécessitent des approches de modélisation plus poussées afin de garantir la cohérence des données, la souplesse d’usage et des performances correctes lors des analyses. Lorsqu’une dimension est organisée selon plusieurs niveaux logiques (par exemple : continent, pays, région, ville), une hiérarchie peut être utilisée pour refléter cette organisation. Mais dans certains cas, une dimension peut porter plusieurs hiérarchies ou être organisée selon des relations de type parent-enfant, ce qui rend sa modélisation plus délicate.

Multi-hiérarchies : certaines dimensions doivent supporter plusieurs parcours hiérarchiques selon le métier (marketing, logistique, etc.). Chaque hiérarchie propose un axe d’analyse différent sur les mêmes données de base, ce qui enrichit les possibilités d’exploration tout en nécessitant une gestion rigoureuse pour éviter les confusions.

Exemple : dimension « Produit » avec deux hiérarchies différentes :

Hiérarchie 1 (Marketing) : Catégorie > Famille > Produit
Hiérarchie 2 (Logistique) : Ligne d’approvisionnement > Zone > Produit

Id Produit	Nom Produit	Catégorie	Famille	Ligne Appro	Zone
P001	Casque bluetooth	Audio	Sans fil	L1	Z-EU

Relations Parent-Enfant : les relations de type parent-enfant sont utiles pour représenter des structures à profondeur variable selon les cas, comme dans un organigramme ou des catégories emboîtées. Ce type de modélisation, bien qu’offrant une grande souplesse, exige des traitements particuliers selon la technologie cible. Par exemple, le moteur SSAS Multidimensionnel gère nativement ces hiérarchies sans figer le nombre de niveaux, mais cela peut lourdement impacter les performances d’agrégation sur de gros volumes. À l’inverse, un moteur comme SSAS Tabulaire (ou Power BI) ne les supporte pas nativement...

Gestion des dimensions volumineuses

Certaines dimensions, comme les clients, les produits ou les adresses, peuvent contenir plusieurs centaines de milliers, voire des millions de lignes. Leur volumétrie impacte directement les performances globales du cube et nécessite une attention particulière en termes de conception, de stockage et d’accès aux données.

1. Stratégies de stockage et compression

Lorsque la dimension devient massive, chaque choix de conception peut avoir un effet démultiplié. Une des premières approches consiste à optimiser la structure même de la table en limitant les redondances : éviter les colonnes inutiles, privilégier les types de données les plus compacts, et surtout normaliser certains attributs si leur cardinalité est élevée. Par exemple, plutôt que de stocker le nom complet du pays sur chaque ligne de la dimension client, on peut envisager une table de référence dédiée avec une simple clé.

La compression joue également un rôle important. De nombreux moteurs OLAP et bases de données en colonne permettent des mécanismes de compression automatique, particulièrement efficaces sur les colonnes peu distinctes. Une colonne comme Type de Client ou Pays peut ainsi être compressée très efficacement si elle contient peu de valeurs distinctes.

On peut aussi réfléchir à la granularité de la dimension : est-ce qu’il est pertinent d’avoir une ligne par événement ou par entité ? Parfois, un regroupement ou une dénormalisation partielle permet de réduire le volume de manière significative sans compromettre les analyses.

Enfin, sur les plateformes cloud ou big data, il faut aussi penser à la manière dont les données sont distribuées physiquement : partitionnement, clustering ou zonage selon certains attributs clés (par exemple, l’année d’enregistrement ou le pays) permet de ne lire que la partie utile de la dimension au moment de l’analyse.

Par exemple :

Id technique Client	Id Client	Nom du Client	Age	Statut	Catégorie Socio- professionnelle	Date d’activation
1	1	Jen Dupont	34	Actif	Employé	2023-02-01
2	2	Alice Martin	45	Inactif	Cadre	2024-03-02
3	3	Jacques...

Modélisation des dimensions et hiérarchies