3-B. Les tables de dimension▲
Les dimensions correspondent donc à vos axes d'analyses, exemple : Produits, Agences, Temps, Rating Client, Localité, Ancienneté, Service, etc. On retrouve souvent les mêmes dimensions dans un même secteur d'activité et pour cause, les utilisateurs métier expérimentés savent très bien distinguer l'utile de l'inutile.
Une dimension correspond à un arbre, le but étant d'être capable de faire joindre les faits à un noeud ou à une feuille de cet arbre. Grâce à cette jointure entre mesures et dimensions, vous permettez aux analystes de calculer un agrégat par noeud, par branche ou pour l'ensemble du tronc, le tout sur plusieurs dimensions à la fois (croisement de dimensions).
Exemple de dimensions temps :
Exemple de dimension produit :
Le décideur peut alors analyser l'agrégat des mesures associées à ces dimensions par trimestre et sous-catégories de produits.
Considérez les dimensions comme l'interface entre l'homme et les données de votre système de mesure. Tout rapport sera toujours construit à travers les dimensions que vous mettez à disposition des utilisateurs. C'est pourquoi, elles se doivent d'être simples et d'avoir du sens pour l'ensemble de vos utilisateurs.
En croisant les dimensions, les analystes construisent « le contexte » du rapport. Si le « contexte » est incompréhensible vos rapports le seront tout autant.
3-B-1. Les règles d'or des tables de dimensions▲
Voici une série de conseils qui pourront vous être utiles lors de la mise en place de vos tables de dimensions :
- même si une table de dimension est souvent très dé-normalisée, veuillez à toujours respecter la première forme normale (unicité de la clé et valeur atomique des champs) ;
- afin de faciliter la maintenance due à l'évolution des dimensions et dans le but de faciliter les jointures avec la table de fait et de réduire la volumétrie de celle-ci, préférez l'utilisation d'une clé physique générique et dépourvue de sens et qui soit de type « auto-incrément » plutôt qu'une clé logique composée de plusieurs champs pour vos tables de dimensions ;
- même s'il existe différents types de processus pour mettre à jour une table de dimension, un conseil : ne supprimez jamais une ligne d'une table de dimension. Si vous ne souhaitez pas afficher des dimensions obsolètes, utilisez un champ ETAT ou FLAGAFFICHAGE. Il est très difficile de mesurer l'impact de la suppression d'une valeur de dimension sur l'ensemble des rapports de vos utilisateurs. Si un rapport est produit un jour « j » ses valeurs doivent être identique s'il est produit jour « j+30 » ou « j+365 ». Si vous supprimez physiquement une ligne d'une dimension cela ne sera plus le cas ;
- pour faciliter la production de rapports et le calcul d'agrégats, faites en sorte de créer des dimensions respectant une hiérarchie simple de type 1 vers n. Imaginez les relations au sein d'une même dimension comme celles des poupées russes qui s'emboîtent ou comme un arbre vis-à-vis de ses branches et de ses feuilles. Cette approche est très naturelle pour l'utilisateur qui facilite la manipulation des données. Exemple :
- un domaine de produit contient une à plusieurs catégories de produits ; une catégorie de produit contient une ou plusieurs références de produit,
- une région contient un ou plusieurs départements, un département contient un ou plusieurs sites de production, un site de production contient 1 ou plusieurs services ; - En d'autres termes, éviter les relations n vers n dans une dimension. Délimitez strictement la hiérarchie de vos dimensions : un site de production appartient à un et un seul département, un département n'appartient qu'à une et une seule région. Si « un département peut appartenir à plusieurs régions » dans votre dimension, vous risquez de complexifier l'accès à l'information et la production de rapports. Pensez aux poupées Russe !
- Évitez les modèles de dimensions en flocon, ils sont plus difficiles à maintenir et moins efficaces. Normalement, vous pouvez toujours les éviter en créant deux dimensions complètement distinctes. Exemple, un produit peut appartenir à une typologie de produit et un produit appartient également à un regroupement de produits. Dans ce cas il est préférable de créer deux axes d'analyses : Typologie Produit et Produits.
Vous l'avez compris, l'approche multidimensionnelle est simple et naturelle. Une organisation compte, selon la complexité de son activité, de trois à douze dimensions(6). Si vous en avez plus, vous devez simplifier votre modèle. Le croisement de dimensions est souvent interprété comme une dimension en soit. Exemple, vous êtes peut être tenté par une dimension « Segmentation clientèle », mais celle-ci ne revient-elle pas au croisement de votre dimension Métier et de votre dimension ? Âge ?
N'oubliez pas que la valeur ajoutée d'un système multidimensionnel provient essentiellement de ses dimensions et de la possibilité de les croiser, ce qui permet de mettre en perspective des mesures dans un contexte riche de sens.
3-B-2. Quelques patrons liés aux tables de dimensions ▲
Voici quelques modèles connus et reconnus à appliquer lors de la modélisation de vos dimensions.
3-B-2-A. Les dimensions à « jeux de rôle »▲
Ce modèle représente le fait d'implémenter une seule dimension physique pouvant représenter plusieurs axes d'analyses pour les utilisateurs ; typiquement la dimension « Temps ». En tant que concepteur vous pouvez produire différentes vues de cette de table de dimension « Temps » afin de permettre aux utilisateurs d'utiliser différents axes d'analyses (exemple : date d'achat, date de livraison...). Vous ne gérez donc qu'une seule dimension physique tout en mettant à disposition de vos utilisateurs plusieurs axes d'analyses.
3-B-2-B. Les dimensions à changement rapide▲
Lorsqu'une dimension comporte un très grand nombre de champs évoluant en continu, il est préférable de regrouper ces champs dans une table satellite (relation 1->N). Les champs à évolution constante se retrouvent alors isolés et disponibles à travers une simple jointure. Le fait d'isoler ces champs à évolution rapide facilite la maintenance et le traitement des erreurs de chargement. Cela permet également de réduire l'impact sur votre dimension en cas d'erreurs. Exemple, les produits financiers comme les actions avec leurs statuts et valorisations à un moment T.
3-B-2-C. Les flags dimensionnels (à utiliser avec modération)▲
Il est parfois intéressant de connaître si une occurrence de table de fait appartient à un « groupe », sans pour autant que ce « groupe » soit suffisamment important pour en faire une dimension. Dans ce cas précis l'utilisation de flags dimensionnels peuvent s'avérer utile. Le flag dimensionnel est un champ de nature dimensionnelle qui n'a pas une table de dimension. Le flag dimensionnel n'est pas une clé étrangère mais un flag avec ses valeurs propres (celles-ci doivent être connues des utilisateurs). Exemple, pour chaque occurrence d'une table de fait liée à un processus de vente, nous pourrions créer le flag dimensionnel « Vente Direct » avec les valeurs possible ['O' | 'N']. Il permet aux analyses de faire des statistiques comparatives entre les ventes dites « directes » et les autres à partir d'une seule table de fait.
3-B-2-D. Les mini-dimensions ou dimensions déportées▲
Lorsque la table de fait comporte beaucoup d'attributs spécifiques liés aux mesures, il est d'usage de déporter l'ensemble de ces attributs dans une table de type « mini-dimension » uniquement utilisée pour interroger cette table de fait. Une « mini-dimension » est donc généralement liée à une seule table de fait. Exemple, dans une table de fait qui comporte des mesures liées aux crédits, les attributs du crédit peuvent être déportés dans une mini-dimension.
3-B-2-E. Les dimensions dégénérées▲
Un nom bien savant pour un modèle relativement simple. Dans certains rapports, il s'avère parfois utile de proposer un accès vers le détail ou d'ajouter des informations sur la transaction traitée. La dimension dégénérée consiste en un champ dans votre table de fait qui fait référence à l'identifiant de la transaction dans la base opérationnelle ou vers votre ODS(7). Ce modèle très utile permet de vérifier la véracité des chiffres fournis ainsi que la valeur des dimensions indiquées. Exemple, un champ « référence du contrat » dans une table de fait de transaction vous permettra de créer un lien vers votre système opérationnel afin d'accéder à ses propriétés.
3-B-2-F. Les dimensions horodatées▲
Ce modèle consiste à ajouter des dates de début et de fin de validité à une table de dimension. Cette pratique peut s'avérer particulièrement utile lorsqu'on sait que les données de la dimension sont « périssables », exemple : une date de transfert ou de licenciement d'un employé (l'employé ne fait plus partie du service il ne doit pas apparaître dans la dimension) ; une date de fin de disponibilité d'un produit (le produit n'est plus référencé, il ne doit pas apparaître dans la dimension)...
3-B-2-G. La dimension audit▲
Véritable « cerise sur le gâteau », la dimension audit consiste à loger l'ensemble des informations sur le chargement de vos tables de fait et de dimensions. Cette dimension contient, entre autres, l'ensemble des métadonnées renseignées dans vos job ETL. Chaque feuille de cette dimension correspond à un job ETL et l'ensemble des mesures (nombre d'opérations INSERT, temps d'exécution, temps CPU, temps CPU réservé à la qualité de données, etc.) sont bien entendu regroupées dans une table de fait.
Vous pouvez également rattacher la dimension audit à toutes les occurrences de vos tables de fait à travers un champ « référence job ETL ». Cela vous permettra de connaître « qui à chargé quoi, quand et comment ? ».
La dimension audit permet une traçabilité et démontre une certaine rigueur ainsi qu'un certain professionnalisme dans la mise en place de votre système décisionnel.