III. L'entrepôt de données multidimensionnel en pratique▲
III-A. Les tables de faits▲
Tout d'abord, démystifions la chose… Une table de faits n'est rien d'autre qu'un ensemble de données structurées, composé de champs de type dimension (le contexte) et champs de type mesure (les faits).
Un processus d'entreprise peut être représenté à l'aide d'une ou plusieurs tables de faits. À ce jour on dénombre trois types de tables de faits(5) : les tables de faits de transaction, les tables de faits périodiques et les tables de faits récapitulatives.
III-A-1. Les règles d'or des tables de faits▲
Voici une série de conseils qui pourront vous être utiles lors de la mise en place de n'importe quelle table de faits (n'hésitez pas à les relire avant d'en concevoir une nouvelle, vous économiserez sans doute un temps précieux) :
- l'unicité d'une ligne d'une table de faits doit toujours pouvoir être garantie par la concaténation de ses champs dimensions. En effet, même si les concepteurs rajoutent souvent une clé physique de type « auto-incrémenté » la clé logique de table reste l'unicité du contexte. En d'autres termes, si un fait (une occurrence) a exactement le même contexte (mêmes valeurs de dimensions) qu'un autre fait, cela doit être la même ligne ;
- une table de faits contient toujours la dimension temps. Bien que la durée de rétention varie en fonction de la granularité de la mesure, TOUTES vos mesures doivent comprendre un historique pour vous permettre de produire des tendances. Un entrepôt de données quel qu'il soit doit comprendre la dimension temps (c'est à l'équipe métier de juger de la durée minimale de rétention requise pour leur permettre de prendre des décisions et non pas aux administrateurs de base de données) ;
- les mesures stockées dans une table de faits sont (presque) toujours de types numériques et additifs. Cela implique les règles suivantes : les ratios sont toujours stockés à travers deux champs distincts (numérateur et dénominateur). Les mesures stockées ne correspondent jamais à une moyenne (la somme des moyennes ne correspond pas à la moyenne des sommes !). Prenez garde au calcul des délais, vous ne stockez pas les dates, mais la durée effective du délai calculé quel qu'en soit l'unité (jours, minutes ou secondes) ;
- les données d'une table de faits sont figées. Une table de faits stocke une situation passée et révolue (sauf table de faits récapitulative). Il ne doit pas y avoir d'opération de mise à jour sur la table une fois le chargement effectué et que ses données sont à disposition des utilisateurs (sauf correction). Si certains de vos utilisateurs génèrent le rapport « situation financière du 31 mars 2011 » le 5 avril et que d'autres utilisateurs génèrent ce même rapport le 10 mai, ils doivent absolument avoir accès aux mêmes chiffres ;
- une table de faits est toujours interrogée à partir d'un contexte donné. Sa volumétrie ainsi que sa nature transverse (multitude de dimensions) vous obligent à interroger une table de faits à partir d'un contexte bien particulier (filtre de dimensions) ;
- des vues d'une même table de faits peuvent être produites avec des filtres entièrement différents parce que les besoins d'un service à un autre sont entièrement différents. Ce qui importe, c'est que les deux services aient la même définition de la mesure, car les rapports sont produits à partir de la même source de données ;
- une table de faits ne doit pas contenir de ligne artificielle valorisée à zéro. Il faut donc éviter les alimentations de type « produit cartésien de dimension ». Exemple, si votre système opérationnel ne contient pas d'information sur la vente du produit « REF-0001 » vendu dans l'agence « ABC » qu'il en soit ainsi ! Ne créez pas la ligne « REF-001 | ABC | … | 0 » sous peine d'explosion du volume de données ;
- une table de faits ne comprend que les clés des dimensions, sous forme de clé étrangère (numérique de préférence et dénuée de sens pour faciliter la maintenance, cf. chapitre sur les tables de dimensions). Si les tables de faits peuvent être très longues en termes de nombre d'occurrences, elles doivent être étroites en largeur pour pouvoir les compresser en terme d'espace et être performante ;
- le volume d'une table de faits dépend (en partie) du nombre de dimensions AINSI QUE de la structure de celle-ci (profondeur, nombre d'occurrences). En d'autres termes plus le contexte est précis et plus votre table de faits sera volumineuse et difficile à maintenir.
III-A-2. Quelques patrons liés aux tables de faits▲
Comme nous l'avons déjà précisé, le concepteur d'entrepôt de données distingue différents types de tables de faits : de transaction, périodique et récapitulative. Même si nous classons les tables de faits par type, le principe reste identique : c'est une structure contenant des champs « clé étrangère » de table de dimensions (contexte) et des champs de type mesure.
Connaître et maîtriser les différents types de tables de faits vous aidera tout au long de la conception de votre marché de l'information. Cela vous permettra de mettre en place plus rapidement un SID complet. En effet, malgré la transversalité du système, les besoins de reporting sont redondants. En connaissant les patterns à appliquer vous accélérerez la mise en place ainsi que la qualité et la pertinence de l'information fournie.
III-A-2-a. Table de faits de transaction▲
C'est le type le plus commun et le plus fondamental, l'ensemble de votre entrepôt repose sur les tables de faits de transaction.
Principe : comme son nom l'indique, elle repose sur la transaction du système opérationnel. Vous devez définir les clés des dimensions de chacune des transactions opérationnelles et extraire les mesures qui vous intéressent. Ici, la difficulté provient de la gestion des dimensions (notamment le traitement des nouvelles occurrences) ainsi que du compromis volumétrie/précision du contexte fourni (cf. étape choix de la granularité de la table de faits).
Attention, il ne s'agit pas d'avoir une ligne par transaction, bien au contraire. Ici l'unicité de l'occurrence est marquée par l'unicité de son contexte (ensemble des clés de dimensions, cf. règle 1 des propriétés des tables de faits). Notez que plus vous agrégez les faits, moins il sera possible de proposer des dimensions dégénérées (cf. chapitre « Les Dimensions »).
Vous n'avez pas à faire d'opération de mise à jour sur une table de faits de transaction (sauf erreur de chargement). La table de faits de transaction représente le niveau le plus détaillé que peut proposer votre entrepôt sur le processus en question, c'est pourquoi le choix de la granularité de celle-ci est si important.
III-A-2-b. Table de faits périodique▲
Une table de faits périodique est généralement construite à partir d'une table de faits de transaction. Elle représente soit l'image d'une table de faits de transaction à un moment T ; soit la synthèse d'une table de faits de transaction à travers l'agrégation des mesures sur ses dimensions.
Les tables de faits périodiques permettent d'analyser un volume de transaction beaucoup plus important et ainsi de dégager des tendances. En contrepartie, le nombre et les profondeurs des dimensions sont réduits. En d'autres termes, plus vous agrégez les mesures de la table de transaction plus votre contexte d'analyse sera limité, mais plus vous pourrez traiter de transactions et dégager des tendances. Comme toujours tout est histoire de compromis…
Une bonne approche peut être de proposer une table de faits de transaction avec un contexte d'analyse très riche et très détaillé sur un axe de temps limité (trois mois) couplé à une table de faits périodique avec un contexte moins riche (profondeurs de dimension moins importante ou suppression de dimensions), mais un axe de temps plus important (36 mois).
Tout comme sur les tables de faits de transaction, hormis une erreur de chargement, les tables de faits périodiques ne doivent pas être soumises à des opérations de mise à jour, la production de ce type de tables consiste à agréger et à charger les données.
Si votre processus possède un nombre de dimensions restreint avec très peu d'occurrences, le volume traité par votre table de faits de transaction peut éventuellement vous permettre de proposer un axe temps suffisant à vos analystes, auquel cas la mise en place d'une table de faits périodique n'est pas nécessaire, voir déconseillée.
III-A-2-c. Table de faits récapitulative▲
Très utiles et complémentaires aux autres types de tables de faits, les tables de faits récapitulatives sont aussi plus complexes et plus difficiles à maintenir.
La table de faits récapitulative n'est pas fondée sur la transaction ou sur l'axe temps, mais sur l'analyse détaillée d'une dimension. Exemple : l'activité d'un site de production. Dans les autres types de table de faits la référence d'un site de production était un axe d'analyse possible, mais le but premier était l'analyse du processus à travers ses différentes mesures. Dans les tables de faits récapitulatives les rôles s'inversent, on souhaite analyser une dimension à travers différents processus. La table de faits récapitulative va donc contenir différentes mesures liées à différents processus pour une même occurrence de dimension.
Les tables de faits récapitulatives permettent une analyse transversale d'une dimension clé stratégique. Contrairement aux autres types de tables de fait, l'essentiel des opérations effectuées sur ce type de table sont des mises à jour. Les tables de faits récapitulatives sont complémentaires aux autres types de tables de faits et leur contenu repose entièrement sur les tables de faits de type transactionnel.
La notion de table de faits récapitulative peut encore vous paraître abstraite, prenons un exemple basique pour illustrer ces propos. Imaginons que vous disposiez de deux tables de faits de type transaction. La première est liée à un processus de vente (dimensions utilisées : Temps, Magasin, Employé, Produit, Age client, Localité client). La seconde est liée à un processus de réclamation (dimensions utilisées : Temps, Produit). Vous pourriez donc créer une table de faits récapitulative « Mesure Produit » qui intègre pour chaque produit la notion de ventes et de réclamation.
III-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 nœud ou à une feuille de cet arbre. Grâce à cette jointure entre mesures et dimensions, vous permettez aux analystes de calculer un agrégat par nœud, 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.
III-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, veillez à 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 faits 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 « autoincré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 russes !
- É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.
III-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.
III-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.
III-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.
III-B-2-c. Les flags dimensionnels (à utiliser avec modération)▲
Il est parfois intéressant de connaître si une occurrence de table de faits 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 peut 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 faits liée à un processus de vente, nous pourrions créer le flag dimensionnel « Vente Direct » avec les valeurs possibles ['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.
III-B-2-d. Les minidimensions ou dimensions déportées▲
Lorsque la table de faits 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 « minidimension » uniquement utilisée pour interroger cette table de fait. Une « minidimension » est donc généralement liée à une seule table de fait. Exemple, dans une table de faits qui comporte des mesures liées aux crédits, les attributs du crédit peuvent être déportés dans une minidimension.
III-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 faits 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 faits de transaction vous permettra de créer un lien vers votre système opérationnel afin d'accéder à ses propriétés.
III-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)…
III-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 faits et de dimensions. Cette dimension contient, entre autres, l'ensemble des métadonnées renseignées dans vos jobs 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 faits.
Vous pouvez également rattacher la dimension audit à toutes les occurrences de vos tables de faits à 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.
III-C. Maintenance d'un entrepôt de données multidimensionnel▲
La maintenance et l'évolution des dimensions à long terme sont un processus délicat. Dans une approche multidimensionnelle, vos dimensions étant communes à l'ensemble des tables de fait, une simple erreur de maintenance sur une dimension aura un impact sur l'ensemble de votre système décisionnel. Vous marchez donc sur des œufs…
La bonne nouvelle, c'est qu'il n'existe pas « trente-six » façons de maintenir une dimension. Si vous respectez les quelques conseils prodigués dans la partie « les tables de dimensions » lors de la conception de vos dimensions, vous pourrez mettre en place ces conseils de maintenance sans grande difficulté.
III-C-1. Opérations de maintenance liées aux dimensions▲
III-C-1-a. Ajout▲
Avant d'ajouter une nouvelle occurrence de dimension, posez-vous les questions suivantes : cette occurrence a-t-elle sa place dans la structure hiérarchique de ma dimension ? Les catégories parentes de celle-ci sont-elles réellement adéquates ? Un chargement rétroactif de certaines tables de faits est-il nécessaire ?
L'ajout d'une feuille dans un arbre de dimension est rarement problématique, il faut juste veiller à conserver une cohérence hiérarchique et logique dans toute la hauteur de l'arbre.
III-C-1-b. Suppression▲
Votre arbre de dimension évoluant, les utilisateurs ont maintenant accès à des valeurs d'occurrence obsolètes. Vous souhaitez supprimer l'accès à ses occurrences, pour cela deux méthodes possibles :
- première méthode (conseillée) : mettez en place un champ « visibilité de l'utilisateur » dans vos tables de dimensions et changez la valeur de ce champ lorsque l'occurrence est obsolète ;
- avantage : méthode simple à mettre en œuvre, aucune opération de mise à jour des tables de faits n'est nécessaire,
- inconvénient : des valeurs de dimension étant masquées à l'utilisateur et les tables de faits n'ayant subi aucune modification, il se peut que l'agrégat d'un rapport puisse ne pas représenter la somme des valeurs après un « drill-down » sur la dimension ; - seconde méthode : vous décidez de supprimer l'occurrence de votre table de dimension. Dès lors, l'ensemble des occurrences dans vos tables de faits qui font référence à cette valeur de dimension seront obsolètes. Vous devez alors mettre à jour l'ensemble des tables de fait, en remplaçant la référence de la dimension supprimée par une référence de dimension « valeur non applicable » que vous aurez créée au préalable dans votre dimension.
Quelle méthode utiliser ?
Si l'occurrence de dimension à supprimer n'est plus référencée par vos tables de faits depuis longtemps (exemple, une référence de produits qui n'existe plus depuis plusieurs mois), la méthode via un champ « flag » semble être la plus pertinente.
III-C-1-c. Mise à jour▲
La modification d'une dimension est l'opération la plus délicate. Comme pour la suppression nous pouvons distinguer deux méthodes :
- première méthode : vous remplacez simplement l'ancienne valeur par la nouvelle ;
- avantage : méthode est simple à mettre en œuvre et il n'y a aucun processus de traçage d'évolution à mettre en œuvre,
- inconvénient : il y a un impact sur l'ensemble des rapports programmés avant la modification ; - seconde méthode (conseillée) : en cas d'évolution, vous ajoutez la nouvelle valeur sans supprimer l'ancienne que vous marquez comme « non applicable » à partir d'un champ « flag » prévu à cet effet. Ainsi lors du processus d'alimentation de la table de fait, c'est bien la nouvelle valeur qui est référencée et non l'ancienne. Ici le nombre d'occurrences de la table de dimension augmente à chaque modification.
- avantage : aucun rapport n'est impacté,
- inconvénient : le processus de maintenance est un peu plus complexe.
Les opérations d'ajout, de suppression et de mise à jour de vos dimensions sont moins triviales qu'il ni paraît. J'espère que cette courte présentation vous permettra de cerner rapidement la problématique de maintenance des dimensions dans un entrepôt de données multidimensionnel.
III-C-2. Opérations de maintenance liées aux mesures▲
Hormis les tables de faits de type récapitulatif, les seules opérations effectuées sur vos tables de faits seront des insertions (sauf erreur de chargement…). Toutefois, vous pourrez rencontrer des difficultés de maintenance liée à vos tables de fait, celles-ci peuvent provenir :
III-C-2-a. Du volume de données traitées :▲
Une granularité très fine dans une table de faits peut amener à avoir à traiter des millions d'occurrences. Les gros volumes sont toujours délicats à traiter, si l'alimentation de cette table est en dépendance avec d'autres tables (des bases métiers par exemple) c'est l'ensemble de vos traitements de nuit qui seront retardés… (Une nuit de traitement à une durée maximum de 12 heures). Vous devez absolument garder un œil sur le temps de traitement de chacune de vos tables et sur les différentes dépendances de votre nuit batch.
III-C-2-b. De la complexité du calcul des mesures :▲
Des calculs de mesure complexes peuvent devenir problématiques, exemple : les calculs de délais ou les calculs qui doivent tenir compte de l'état d'autres occurrences de tables opérationnelles. Hélas, ici, les compromis avec les analystes ne seront probablement pas possibles. Une définition de mesure ne doit pas être changée pour cause de problème technique de mise en œuvre. Essayez de mettre en place des vues des tables opérationnelles réduites et divisez la complexité du calcul en différentes étapes plus simples : « break it and make it easier ».
III-C-2-c. Des jointures avec les tables de dimensions :▲
Pour déterminer le contexte des occurrences de vos tables de fait, vous allez devoir d'une manière ou d'une autre, déterminer quelles sont vos clés de dimension pour chaque occurrence traitée. Or, il arrive que pour diverses raisons (évolution des tables opérationnelles ; erreur de chargement de vos dimensions ; problème de qualité des données) que vos lignes de mesure ne trouvent pas de correspondance dans vos dimensions. Ici attention, il ne faut surtout pas perdre ces enregistrements ! Ces occurrences existent, elles doivent donc être prises en compte dans le calcul de votre mesure. Pour cela, je vous conseille de mettre en place une catégorie « Non Applicable » dans chacune de vos dimensions. Si votre enregistrement ne trouve pas de correspondance, il doit tomber par défaut dans cette catégorie « Non Applicable ». Vous serez ensuite apte à isoler les enregistrements problématiques pour les corriger.
D'après ma propre expérience, ces trois points sont des problématiques récurrentes liées aux tables de fait. Cette courte présentation vous permettra sans doute de mettre en place un système plus robuste.