Conception d'un entrepôt de données (Data Warehouse)

J'estime en avoir assez parlé ici et ici : mais un peu de répétition ne fait pas de mal !!!
Un entrepôt de données, ou data Warehouse, est une vision centralisée et universelle de toutes les informations de l'entreprise. C'est une structure (comme une base de données) qui a pour but, contrairement aux bases de données, de regrouper les données de l'entreprise pour des fins analytiques et pour aider à la décision stratégique. La décision stratégique étant une action entreprise par les décideurs de l'entreprise et qui vise à améliorer, quantitativement ou qualitativement, la performance de l'entreprise. En gros, c'est un gigantesque tas d'informations épurées, organisées, historisées et provenant de plusieurs sources de données, servant aux analyses et à l'aide à la décision. L'entrepôt de données est l'élément central de l'informatique décisionnelle à l'heure où j'écris ce tutoriel. En effet, l'entrepôt de données est le meilleur moyen que les professionnels ont trouvé pour modéliser de l'information pour des fins d'analyse, et il ne serait pas étonnant que d'ici quelques années un nouveau concept apparaisse pour révolutionner l'informatique décisionnelle… Mais intéressons-nous à ce qui existe pour l'instant…

Les Data Warehouses étant, en général, très volumineux et très complexes à concevoir, on a décidé de les diviser en bouchées plus faciles à créer et entretenir. Ce sont les Data Marts. On peut faire des divisions par fonction (un data mart pour les ventes, pour les commandes, pour les ressources humaines) ou par sous-ensemble organisationnel (un data mart par succursale). Nous verrons plus tard comment organiser les data marts pour créer un entrepôt proprement dit.

Lorsqu'on fait un schéma de BD pour un système d'information classique, on parle en termes de tables et de relations, une table étant une représentation d'une entité et une relation une technique pour lier ces entités. Et bien en BI, on parle en termes de Dimension et de Faits. C'est une autre approche des données, on entend par dimensions les axes avec lesquels on veut faire l'analyse. Il peut y avoir une dimension client, une dimension produit, une dimension géographie (pour faire des analyses par secteur géographique), etc.

Une dimension est tout ce qu'on utilisera pour faire nos analyses.

Les faits, en complément aux dimensions, sont ce sur quoi va porter l'analyse. Ce sont des tables qui contiennent des informations opérationnelles et qui relatent la vie de l'entreprise. On aura des tables de faits pour les ventes (chiffre d'affaire net, quantités et montants commandés, quantités facturées, quantités retournées, volumes des ventes, etc.) par exemple ou sur les stocks (nombre d'exemplaires d'un produit en stock, niveau de remplissage du stock, taux de roulement d'une zone, etc.), ou peut être sur les ressources humaines (performances des employés, nombre de demandes de congés, nombre de démissions, taux de roulement des employés, etc.).

Un fait est tout ce qu'on voudra analyser.

L'ETL, dont j'ai expliqué les fondements dans cet article, sert à transposer le modèle entité-relation des bases de données de production ainsi que les autres modèles utilisés dans les opérations de l'entreprise, en modèle à base de dimensions et de faits (nous verrons ces modèles dans les deux prochaines définitions).

Une étoile est une façon de mettre en relation les dimensions et les faits dans un entrepôt de données. Nous le verrons plus tard, mais le principe est que les dimensions sont directement reliées à un fait (schématiquement, ça fait comme une étoile).

Un autre modèle de mise en relation des dimensions et des faits dans un entrepôt de données. Le principe étant qu'il peut exister des hiérarchies de dimensions et qu'elles sont reliées aux faits, ça fait comme un flocon :)

On vous demande de créer un data Mart (une étoile) pour l'analyse de l'activité des représentants d'une entreprise de vente d'imprimantes. Le chef d'entreprise veut savoir ce qui se passe pour ses vendeurs. Les employés font ils leur travail, quelle est la zone de couverture des vendeurs, ou sont les endroits où les vendeurs sont le moins efficaces, quelle est la moyenne de ventes des représentants, etc., etc. L'entreprise possède un système de gestion de ressources humaines, un système de gestion des ventes et des feuilles de route avec des informations concernant les vendeurs : kilomètres parcourus, litres d'essence utilisée, frais de voyage, ventes, promesses de vente, etc.

Notre objectif est d'analyser l'activité des représentants. Il semble que nous ayons toutes les informations pour ce faire… Mais dans différents systèmes.

Commençons l'analyse.

Le but du jeu est de déceler les axes d'analyses (les dimensions) avec leurs attributs ainsi que les éléments à analyser (les faits). La meilleure façon de ce faire, selon moi, est l'étude approfondie de ce qui se passe dans l'entreprise : documents échangés, rapports périodiques, interviews des personnes clés, étude des besoins. Il faut vraiment faire un travail d'acteur, et rentrer dans la peau de chaque utilisateur, savoir comment les analystes organisent leurs raisonnements, savoir ce que voient les décideurs avant de décider, connaître les indicateurs de bonne santé de l'entreprise et de la concurrence. Un vrai travail de fourmi et des heures de plaisir :)

Les techniques d'acquisition d'information et d'analyse des besoins étant un sujet à eux seuls, je passerais la main pour ce point … Nous supposerons que tout a été fait selon les règles de l'art et nous nous contenterons de compiler :)

Une manière très pratique de modéliser un cas en BI se fait comme suit :

Explications : le tableau suivant a été rempli pendant la phase d'analyse, en posant des questions aux décideurs du type :

• que voulez-vous analyser (la dernière ligne du tableau) ?
• quels sont vos critères d'analyse (la première ligne du tableau) ?
• jusqu'à quel niveau de détail voulez-vous aller (les cellules è l'intérieur) ?

La structure d'un entrepôt étant plus rigide que les systèmes conventionnels (se basent sur des ETL, des validations créées par l'homme, etc.), il est capital d'avoir une analyse des besoins exhaustive et conforme aux attentes des décideurs.

Il faut savoir :

• d'où provient chaque champ ?
• comment transite l'information ?
• où trouver l'information voulue ?

Se poser des questions du type :

• ai-je assez de données pour répondre aux besoins ?
• sinon, qu'est-ce que cela impliquerait de les créer ?
• comment alimenter mes dimensions ?
• comment alimenter mes faits ?
• comment valider mes chargements ?
• etc., etc., etc.

Vous pouvez penser que c'est de la paranoïa (comme certains clients) et croire que tous ces problèmes n'apparaîtront pas forcément. Mais rappelez-vous qu'un entrepôt, ça coûte très cher, et qu'un entrepôt avec des données incomplètes, invalides ou non conformes à la demande est tout simplement à mettre à la poubelle…

La modélisation en étoile découle naturellement du tableau ci-dessus, il en résulte le schéma suivant :

Vous comprenez maintenant pourquoi on appelle ce schéma « modèle en étoile ».
Toutes les dimensions sont directement reliées à la table de faits, qui contient les données à analyser. Plusieurs remarques sont à faire pour ce schéma.

• La table de fait contient se qu'on appelle des « mesures », des champs (numériques pour la plupart) sur lesquels on va faire nos analyses, on peut y trouver le montant des ventes nettes, les quantités vendues, les kilomètres parcourus, les quantités en pré commande, etc. La table de faits est reliée aux dimensions par des relations (1, n). Pour analyser une ligne de fait par client par exemple, il faut qu'il y ait une relation entre cette ligne et la dimension client.
• Les tables de dimension contiennent les éléments qu'utiliseront les décideurs pour voir la table de faits. Les utilisateurs pourront ainsi apprécier les montants des ventes par vendeur, par client, ou le kilométrage pour un vendeur pour un client donné (pour voir si ce client est rentable), calculer le coût de revient d'un produit par rapport aux activités des vendeurs, etc.
• On n'utilise JAMAIS la clé d'un système de production comme clé de dimension : pour préserver l'historique des modifications dans l'entrepôt de données (voir l'article sur la gestion de l'historique dans un entrepôt de données).
• La granularité des tables de dimensions et de faits doit être la même : imaginez que la table de faits regroupe les informations par heures et que la table de dimension du temps gère les minutes, il ne sera pas possible de lier la dimension temps et la table de faits (multi détermination).
• Chaque ligne de la table de faits doit avoir une relation avec chacune des tables de dimensions : dans le cas contraire, on aurait perte d'information ou analyse erronée.
• Il n'existe de relations qu'entre les dimensions et les tables de faits. Il sera beaucoup trop compliqué de gérer et d'utiliser des dimensions liées entre elles. N'oubliez pas que le schéma doit être assimilable par des non-informaticiens pour pouvoir l'exploiter. N'ayons pas peur de créer des doublons !

Vous remarquez que tous ces termes sont empruntés à l'astronomie et à la météo : étoile, flocon, constellation. Hubert Reeves n'a qu'à bien se tenir :)
Une constellation est une série d'étoiles (tu m'étonnes !) ou de flocons reliés entre eux par des dimensions. Il s'agit donc d'étoiles avec des dimensions en commun. Un environnement décisionnel idéal serait une place ou il serait possible de naviguer d'étoile en étoile, de constellation en constellation et de Data Mart en DataMart à la recherche de l'information si précieuse.
Un des indicateurs clés d'une bonne conception d'entrepôt est la grosseur des constellations. En effet, plus la constellation est grosse, plus cela veut dire que vous avez réutilisé vos dimensions, et qui dit réutilisation de dimension, dit dimensions complètes, centralisées et avec une vue orientée entreprise.
Je m'explique.

En conception d'entrepôt, il ne faut pas se casser la tête, dès qu'une dimension existante ne correspond pas parfaitement aux besoins d'une nouvelle étoile, on en crée une autre, même si elle est « presque » comme la dimension que nous allions utiliser. C'est pour cela qu'il faut créer, autant que possible, des dimensions génériques et qui soient vraies tout le temps, pour toutes les fonctions de l'entreprise. Ces dimensions pourront être réutilisées et assurer une pérennité des données. Et si de telles dimensions ne peuvent pas être créées, il ne faut pas avoir de remords à créer des dimensions similaires, mais adaptées aux besoins de la nouvelle étoile. Mais si vous voyez que dans chaque étoile vous êtes obligés de créer une nouvelle dimension « client » par exemple, posez-vous des questions sur votre conception.

Récapitulons, nous avons vu comment créer une étoile ou un flocon, nous avons vu que les data marts sont des étoiles regroupées par fonction ou par utilité dans l'entreprise et nous savons qu'un entrepôt est l'ensemble de tous les data marts de l'entreprise. Nous savons faire une étoile, mais comment les regrouper pour mettre en œuvre un entrepôt de données ? Et bien trois méthodes s'offrent à nous :

• Top-Down : c'est la méthode la plus lourde, la plus contraignante et la plus complète en même temps. Elle consiste en la conception de tout l'entrepôt (i.e. : toutes les étoiles), puis en la réalisation de ce dernier. Imaginez le travail qu'une telle méthode implique : savoir à l'avance toutes les dimensions et tous les faits de l'entreprise, puis réaliser tout ça… Le seul avantage que cette méthode comporte est qu'elle offre une vision très claire et très conceptuelle des données de l'entreprise ainsi que du travail à faire ;
• Bottom-Up : c'est l'approche inverse, elle consiste à créer les étoiles une par une, puis les regrouper par des niveaux intermédiaires jusqu'à obtention d'un véritable entrepôt pyramidal avec une vision d'entreprise. L'avantage de cette méthode est qu'elle est simple à réaliser (une étoile à la fois), l'inconvénient est le volume de travail d'intégration pour obtenir un entrepôt de données ainsi que la possibilité de redondances entre les étoiles (car elles sont faites indépendamment les unes des autres) ;
• Middle-Out : c'est l'approche hybride, et conseillée par les professionnels du BI. Elle consiste en la conception totale de l'entrepôt de données (i.e. : concevoir toutes dimensions, tous les faits, toutes les relations), puis créer des divisions plus petites et plus gérables et les mettre en œuvre. Cela équivaut à découper notre conception par éléments en commun et réaliser les découpages un par un. Cette méthode tire le meilleur des deux précédentes sans avoir les contraintes. Il faut juste noter que cette méthode implique, parfois, des compromis de découpage (dupliquer des dimensions identiques pour des besoins pratiques).