Qu’est-ce qu’une dimension en data warehouse ?

C’est en préparant une formation sur les bases de la BI pour une PME industrielle que je me suis retrouvé face à cette question toute simple en apparence : “C’est quoi une dimension ?”

Et là, je me suis rappelé mes débuts. J’étais persuadé qu’un entrepôt de données, c’était une grosse base SQL, et qu’on allait juste empiler des chiffres et faire des requêtes. Jusqu’à ce que je tombe sur un schéma en étoile. Et que je découvre que derrière chaque chiffre, il y avait des axes de lecture — les fameuses dimensions.

Alors voilà. Si vous vous demandez ce que signifie une dimension en data warehouse, on va prendre le temps de répondre. Sans jargon. Avec des exemples concrets. Et avec un vrai regard métier.

Comprendre les dimensions sans les compliquer

Imaginez une immense feuille Excel avec des milliers de lignes. Chaque ligne contient un chiffre clé : une vente, une commande, une livraison. Ces chiffres, ce sont les faits. Mais pris seuls, ils ne veulent pas dire grand-chose.

Ce qui leur donne du sens, ce sont les colonnes qui les entourent : date, client, produit, région… C’est ça, les dimensions.

Elles permettent de poser des questions intelligentes comme :

• Quelles ont été les ventes par produit, par mois ?

• Quel client a généré le plus de chiffre d’affaires en Île-de-France ?

• Quelle gamme fonctionne le mieux chez les 18-25 ans ?

Autrement dit, une dimension, c’est un angle d’analyse.

Ce qu’on trouve dans une dimension

Prenons un exemple concret : la dimension Client. Qu’est-ce qu’on y trouve ?

• Le nom du client

• Le genre

• L’âge

• Le segment (particulier, pro…)

• La ville, le code postal, la région

• Le canal d’acquisition

• La date de premier achat

Ce ne sont pas des données “chiffrées” à analyser directement, mais elles permettent de catégoriser les faits. Et de les croiser.

Autre exemple : la dimension Produit.

• Code produit

• Libellé

• Catégorie

• Sous-catégorie

• Marque

• Prix de vente

Et ainsi de suite. Chaque dimension est une table qui contient des attributs descriptifs. Elle donne du relief aux données brutes.

Pourquoi les dimensions sont centrales en data warehouse

Dans tout projet de BI, les dimensions sont les piliers. Voici pourquoi :

• Elles permettent de faire des regroupements (ventes par région, clients par segment…)

• Elles structurent les analyses dans le temps (dimension Date : année, trimestre, mois, semaine, jour)

• Elles rendent les chiffres intelligibles. Sans elles, vos rapports seraient plats, aveugles, muets.

Et puis il y a la notion de hiérarchie. Exemple avec le temps :

• Jour → Mois → Trimestre → Année

Ou avec la géographie :

• Ville → Département → Région → Pays

Ces hiérarchies permettent des analyses multi-niveaux, du plus détaillé au plus global.

Les différents types de dimensions (et pourquoi ça compte)

On entre ici dans le cœur du métier. Il existe plusieurs types de dimensions, que j’explique souvent avec des exemples vécus :

Dimensions à évolution lente (SCD – Slowly Changing Dimensions)

J’ai bossé avec un client dans l’assurance où les adresses des clients changeaient fréquemment. Il fallait donc pouvoir :

• soit mettre à jour l’info en écrasant l’ancienne (type 1),

• soit garder une trace de chaque version (type 2),

• soit archiver dans une autre colonne (type 3).

👉 Utile dès que vos données décrivent quelque chose qui peut évoluer (adresse, fonction, statut…).

Dimensions dégénérées

Parfois, une info comme le numéro de commande n’a pas besoin d’attributs. Elle reste dans la table de faits, sans être reliée à une dimension classique. On l’appelle « dégénérée » – oui, un peu triste comme nom.

Dimensions conformes

C’est là que ça devient puissant : une même dimension utilisée dans plusieurs tableaux de bord. Exemple ? La dimension “Date”. Si elle est uniforme dans vos ventes, vos stocks, vos retours, vous pouvez tout recouper proprement.

Dimensions poubelles (junk)

Dans certains cas, on regroupe dans une seule dimension des petites variables binaires ou qualitatives (oui/non, validé/pas validé, priorité A/B/C…). Ça évite de créer 15 mini-dimensions.

Dimensions à rôle multiple

Une même table “Date” peut servir à plusieurs usages dans la table de faits :

• Date de commande

• Date de livraison

• Date de paiement

On l’utilise plusieurs fois, avec des alias.

Comment modéliser vos dimensions dans un entrepôt de données ?

J’aime bien utiliser l’image d’un plateau de jeu. Vos dimensions sont les axes sur lesquels vous posez les pions (les faits).

Et pour organiser tout ça, on parle de modèle en étoile :

• Au centre, la table de faits (commandes, ventes, etc.)

• Autour, les dimensions (clients, produits, date…)

Un autre modèle, plus détaillé, est le modèle en flocon : les dimensions y sont normalisées. Utile si vous voulez gagner en cohérence et éviter la redondance.

Mais dans 80 % des cas, le modèle en étoile suffit largement pour commencer.

Tableau comparatif des types de dimensions

---

Ce que j’ai appris en les mettant en œuvre

Une chose à retenir : la qualité de votre data warehouse repose à 80 % sur la pertinence de vos dimensions.
Vous pouvez avoir les meilleurs outils, si vos dimensions sont mal définies, vous obtiendrez des analyses biaisées.

Un client dans le e-commerce avait une dimension “Produit” qui changeait de structure tous les 6 mois. Résultat : des rapports incohérents, des stats impossibles à comparer. Il a fallu reprendre tout l’historique pour reconstruire une structure solide. Depuis, on versionne chaque changement et on trace tout.

FAQ

Quelle est la différence entre une dimension et une mesure ?

Une mesure est un chiffre (CA, nombre de commandes, taux de retour…).
Une dimension est une étiquette qui permet de trier, regrouper ou filtrer ces chiffres (produit, date, client…).

Faut-il créer une table de dimension pour chaque champ ?

Pas toujours. Pour des champs isolés sans logique métier forte (par exemple un flag “VIP”), on peut les laisser dans la table de faits ou les regrouper dans une junk dimension.

Peut-on créer des dimensions personnalisées dans Power BI ou Tableau ?

Oui, absolument. Même si le modèle sous-jacent est SQL, vous pouvez créer des dimensions calculées ou dérivées dans l’outil de dataviz.

Est-ce que les dimensions doivent être figées ?

Non. Les dimensions évoluent : nouveaux produits, nouveaux segments clients, changements d’organisation. Il faut juste bien gérer leur évolution dans le temps (SCD).

Combien de dimensions faut-il idéalement dans un modèle ?

Il n’y a pas de règle universelle, mais en général entre 5 et 15 dimensions suffisent à structurer un sujet métier. Trop de dimensions tue la lisibilité, pas assez limite l’analyse.

Conclusion

Une dimension en data warehouse, ce n’est pas juste un concept technique. C’est ce qui donne vie à vos chiffres, ce qui leur permet de raconter une histoire, de répondre à des vraies questions.

Et si vous commencez à construire votre entrepôt de données ou votre modèle BI, mon conseil est simple : travaillez vos dimensions comme des fondations. Donnez-leur un nom clair, une structure propre, une logique métier forte. Parce qu’un bon modèle ne se mesure pas au nombre de lignes… mais à la pertinence des angles sous lesquels on peut le lire.

Et croyez-moi : quand un commercial, un contrôleur de gestion ou un directeur marketing peut, en deux clics, voir « les ventes par produit, par mois, pour les clients premium en Île-de-France », alors là, vous savez que vos dimensions font le job.