Modélisation dimensionnelle : Comment choisir entre Fait, Dimension ou Attribut de Dimension ?

C’est une question qui m’a été posée dernièrement, et je voulais partager avec vous la réponse. Pour ceux qui débutent, on va parler ici de comment construire un modèle dimensionnel, qui permettra le stockage et l’analyse de données que l’on souhaite étudier, que ce soit pour Excel, Power Pivot, SQL Server ou SSAS.

Et pour bien répondre, le mieux est de partir d’un cas pratique :
Je veux analyser la ville de mes magasins, comment la représenter dans mon modèle ?

  • Est-ce que c’est un fait ? L’implémentation géographique de mes magasins ?
    • Qui méritera donc une table de fait à part entière…
  • Est-ce que c’est une dimension à part entière ?
    • Qui méritera donc une table propre et des clefs étrangères dans les tables de fait qui l’utilisent…
  • Ou est-ce que c’est un attribut de ma dimension magasin ?
    • Qui méritera donc une colonne dans la table de dimension correspondante…

Comme d’habitude la réponse est de l’expert est « ça dépend ! »

Mais...

« Et ça dépend de quoi ? » me demandez-vous ?

D’abord de savoir si on joue avec un fait ou une dimension. Là le critère pour trancher est simple : la valeur permet-elle de quantifier (compter, mesurer…) ou qualifier (ventiler, filtrer, trier, grouper…) le processus que je veux étudier (ce à quoi correspond une ligne dans ma table de fait).

Dans notre cas : les quantités mesurées peuvent-elles être ventilées par villes, ou pas ? La réponse est oui : ma ville en elle-même n’est donc pas un fait. Et c’est d’ailleurs plutôt logique, un fait c’est un processus métier qui se réalise, typiquement une transaction ou un comptage. Si on joue avec des villes, une transaction ça pourrait être un déménagement, un comptage le recensement annuel. La ville en elle-même n’est donc pas une mesure. Attention à ne pas croire que la distinction se fait selon le type de la donnée, texte ou valeur numérique, puisqu’un âge ou un prix peuvent complétement être des éléments servant à filtrer (j’étudie mon CA des ventes par prix de vente des articles), donc être côté dimension.

Pour les gens de niveaux 2 et plus, vous noterez que la vraie question sous-jacente est comme toujours de préciser quel est le processus métier concerné par ma table de fait. A quel événement dans le monde réel correspond une ligne dans ma table de fait.

La question suivante est de savoir si la ville est une dimension de mon processus métier, ou un attribut d’une autre dimension, dans mon cas la ville du magasin (cf. schéma ci-dessous):

MD - Schéma 1

D’un point de vue strictement fonctionnel, le critère est simple : c’est le rythme de changement d’un attribut par rapport à un autre, et par rapport aux faits :

  • Si le magasin ne change jamais de ville : la ville est un attribut du magasin, c’est une colonne de la dimension magasin (partie droite du schéma)
  • Si le magasin peut changer de ville mais c’est rare : toujours un attribut mais on va utiliser les techniques SCD (d’où d’ailleurs le lent/slowly de slowly changing dimension, dimension à variation lente) dans la dimension magasin (partie droite du schéma)
  • Si le magasin change de ville plus ou moins à la même granularité temporelle que les faits (le mois ou le jour) : alors c’est une dimension indépendante (partie gauche du schéma)

Plutôt élégant non ?

Maintenant, il arrive que pour des raisons techniques on puisse créer des dimensions géographie ou adresse, quand on veut réutiliser ces adresses pour différentes dimensions (clients, collaborateurs, fournisseurs…), même si on est dans les cas invariants ou à variation lente. A ce moment-là soit on floconne les dimensions, soit on reste en étoile. En flocon (schéma en dessous à droite) on complexifie l’alimentation et les requêtes pour utiliser le modèle (jointures à étage), en étoile (schéma en dessous à gauche) on perd toutes les relations qui existent entre la géographie et le magasin qui n’auraient pas été concrétisées par un fait :

MD - Schéma 2

Dans ce cas, à vous de choisir en fonction de votre besoin métier et vos contraintes techniques.

Si on récapitule le tout, c’est plutôt simple finalement ?

  • Fait ou Dimension : quantifier (mesurer) versus qualifier (ventiler).
  • Dimension ou Attribut de dimension : en fonction du rythme du changement de l’attribut par rapport à la table de fait.

Évidemment on ne peut pas parler de modélisation dimensionnelle sans rappeler que c’est une science exacte qui dispose d’une bible, le DWH Toolkit de Ralph Kimball et toute sa clique.

N’hésitez pas à partager vos cas tordus, la théorie ça doit se tester sur la pratique 😉

Modélisation Dimensionnelle : Les Fondements du Datawarehouse (webcast)

Comme promis précédemment, voici le webcast de la session que j’ai co-animé aux Journées SQL Server 2011: Modélisation Dimensionnelle – Le fondement du Datawarehouse. Pour info je suis le mec qui monopolise la parole pendant les premiers 3/4 d’heure (désolé Jean-Pierre!)

Le webcast est disponible juste là:

Webcast Journées SQL Server 2011 : Modélisation DimensionnelleModélisation Dimensionnelle – Webcast JSS 2011

Les slides sont disponibles en PDF et en PPTX. Pour la liste de tous les webcasts, c’est sur le site du GUSS.

Je vous mets ici les références citées de la session, par ordre chronologique:

Les liens vers les organisateurs:

  • Le GUSS : inscrivez vous, c’est gratuit!
  • Microsoft : les meilleurs produits bases de données et décisionnel du monde, oui madame! Vous y trouverez SQL Server 2012 en version RC0 (Release Candidate) en téléchargement libre 😉

Je rajoute la littérature obligatoire pour tout consultant décisionnel qui se respecte 😉

Si vous avez des remarques, des conseils, des corrections à faire, ou des questions à poser c’est le moment et l’endroit (PS : pour les clefs étrangères, c’est ici que ça se passe) 😉

Modélisation dimensionnelle : La révolution vient d’Italie!

Marco Russo (Blog | Twitter) retrouve son compère Alberto Ferrari (Blog | Twitter) pour mettre à jour son célèbre PDF gratuit The Many to Many Revolution.

Ça parle many to many, évidemment, en UDM (SSAS Classique) et en Tabular (BISM mode PowerPivot) autour d’une dizaine de cas fonctionnels classiques. C’est top!

C’est un document à lire / conserver sous le coude pour tous les consultants décisionnels qui s’orientent vers de l’architecture applicative, c’est à dire le bon design des modèles dimensionnels pour répondre correctement et efficacement au besoin métier.

Comme d’habitude avec les PDF et livres des compères, c’est super bien écrit, très clair et avec plein d’exemples. Je recommande vivement 🙂

Update 10/11/11 : Annonce officielle de la mise à jour par Marco Russo.

Des lignes et des colonnes

Je me suis fait une drôle de réflexion ce matin en lisant cet article d’Alex Payne (un des premiers ingés de Twitter, maintenant CTO de BankSimple), et plus particulièrement ce paragraphe:

Even the most bureaucratic of technologies can’t be claimed to be un-opinionated or free from our values. The lowly SQL database, workhorse of dismal trades like accounting and business analytics, is theoretically “value-neutral” to the data it stores. Yet, in structuring data into rows and columns of particular standard types, a set of values emerges that dictates what information is and how it should be stored and queried.

Traduit grossièrement:

Même la plus basique des technologies est affectée par nos valeurs et nos opinions. La simple base de données SQL, moteur de basses besognes telles que la comptabilité ou l’analyse business, est en théorie neutre en valeur vis-à-vis des données qu’elle héberge. Pourtant, en structurant les données en lignes et en colonnes de types standardisés, un ensemble de valeurs apparaît et dicte ce qu’est l’information et comment elle doit être stockée et requêtée.

C’est tellement vrai!

Pour étudier un événement à travers un modèle relationnel, un modèle en étoile, on le force à prendre une forme qui ne lui est pas forcément naturelle. La question devient: quelle est la valeur de l’analyse si pour la réaliser il a fallut tordre les faits et les conformer à un modèle artificiel? On retourne ici en plein problème de « legibility » dont je parlais tantôt.

Alors évidemment, étant donné que la plupart des phénomènes que l’on doit modéliser dans l’entreprise sont artificiels, il est facile de les modéliser en utilisant un processus artificiel. Un flux comptable, un portefeuille financier, une masse salariale, une chaîne de production… ce sont des éléments inventés de toutes pièces par l’homme et qui donc se conforment facilement dans une base de données.

Mais quand on étudie des phénomènes plus libres comme des courants d’idées sur Internet, la manière dont les sociétés s’organisent et se désorganisent, la mode… les relations humaines en somme, et bien cette mécanique se grippe vite. C’est surement la raison pour laquelle la plupart les gros acteurs sur le web, les journalistes et bloggeurs data ou encore les chercheurs en sciences sociales, n’utilisent que très peu les bases de données SQL et préfèrent le NoSQL, BigData et les nouveaux outils de visualisation (R & co).

Il suffit de voir les résultats de leurs études sur FlowingData ou Information is Beautiful, et de considérer l’effort que cela prendrait de faire certaines de ces analyses sur une plateforme décisionnelle classique, quand c’est possible, pour bien prendre conscience du poids que nous impose le modèle relationnel.

C’est une état de fait tellement évident qu’on l’oublie trop souvent lorsque vient le moment de modéliser un nouveau système décisionnel. Or certaines activités de l’entreprise comportent des éléments à la limite du modélisable, des éléments pourtant cruciaux à la compréhension globale de l’activité. Je pense par exemple aux relations clients ou aux ressources humaines. Sur ces domaines il faut donc être particulièrement prudent, se souvenir de ces limitations, et prévenir les utilisateurs des limites de l’outil à analyser un phénomène qui par définition ne peut pas être modélisé correctement.