La spécificité des projets de Data Warehouse, par rapport aux applications de gestion traditionnelles, se reflète également dans une technique différente de modélisation des données. En environnement décisionnel, les données sont organisées de manière à répondre directement aux requêtes typiques de l’utilisateur final. Pour télécharger le texte complet et obtenir plus d’informations, cliquez ICI
Supposons, par exemple, que l’objectif de l’utilisateur soit de surveiller dans le temps la planification et la réalisation de projets d’investissement utilisant des financements publics, localisés dans différentes zones du territoire national, liés à divers secteurs d’activité. De manière simplifiée, on peut imaginer représenter cette activité à travers un cube, dont les côtés reproduisent les variables temps, localité et classification d’activité, concernant les projets. Chaque point à l’intérieur du cube est l’intersection des coordonnées définies par les côtés du cube lui-même et représente la mesure du fait d’intérêt (le projet et le financement correspondant) pour cette combinaison particulière de localité, secteur d’activité, temps, qui représentent les dimensions de l’analyse. Dans le domaine des Data Warehouse, on parle donc de modélisation dimensionnelle des données. Le modèle dimensionnel et le modèle traditionnel entité-relationnel sont potentiellement capables de stocker les mêmes informations. La différence réside dans la recherche de performances optimales sur les deux types d’environnements. Dans les environnements opérationnels, il est essentiel d’adopter des techniques de normalisation qui, en éliminant les redondances, permettent à un grand nombre de transactions répétitives d’interroger et de mettre à jour les informations en un seul point de la base de données. Les systèmes d’aide à la décision, en revanche, sont caractérisés par un nombre réduit de transactions, qui opèrent néanmoins de manière transversale sur la base de données, nécessitant un accès en lecture à un grand nombre de données à joindre. L’utilisation de techniques de normalisation apparaît donc contre-productive dans la conception d’un système de Data Warehouse. Dans un environnement décisionnel, il est plus correct de concevoir la base de données de manière à satisfaire de façon directe et simplifiée les besoins spécifiques des utilisateurs finaux, notamment à travers des données dénormalisées et agrégées. Il est important de consacrer une grande attention à l’analyse du modèle conceptuel, en prévoyant toutes les dimensions d’analyse et pour chaque dimension les attributs correspondants. Les attributs des tables dimensionnelles sont utilisés directement comme conditions de recherche dans les requêtes sur le Data Warehouse et comme en-têtes des colonnes dans les rapports des utilisateurs finaux. L’utilisation de données préagrégées et de synthèse limite le nombre d’opérations nécessaires pour reconstruire l’information demandée. Le star schema, en plus d’être optimisé pour les requêtes, présente l’avantage supplémentaire de permettre une représentation graphique du business plus compréhensible pour l’utilisateur final. Contrairement au schéma entité-relationnel, où toutes les entités sont représentées de la même manière, le star schema est asymétrique. Au centre du diagramme se trouve une table dominante de grande taille, qui est la seule à posséder des connexions multiples, matérialisées par des champs clés qu’elle contient, vers les autres tables. Les autres tables représentent les dimensions d’analyse à travers lesquelles on examine le « fait » d’intérêt. Techniquement, la table centrale est appelée « fact table » et les autres « dimension table ». La fact table est la table où sont stockées les mesures numériques du fait (dans l’exemple, le montant du financement du projet d’investissement), chacune représentant l’intersection de toutes les dimensions et quantifiant une ou plusieurs variables. Normalement, c’est la seule table normalisée. Les autres tables représentent les dimensions d’analyse à travers lesquelles on examine le « fait » et contiennent des attributs de type descriptif. La cardinalité de ces tables, normalement dénormalisées, est limitée. Parmi les tables dimensionnelles, la table de la dimension temps est toujours présente dans les modèles dimensionnels, quel que soit le business à représenter. Cela découle de la caractéristique des systèmes de Data Warehouse qui gèrent aussi les informations historiques. Parfois, pour améliorer encore l’interprétabilité du modèle, même les tables dimensionnelles sont normalisées, explicitant les hiérarchies. Cela donne lieu à un schéma dit en « flocon de neige » ou Snowflake Schema. La navigation des données à travers le modèle snowflake est moins efficace que dans le Star Schema car elle augmente le nombre de tables sur lesquelles effectuer les jointures. Il faut considérer que, si d’un côté la dénormalisation garantit de meilleures performances dans les opérations de requête, elle rend aussi plus coûteuse la mise à jour et le chargement des données. Plus généralement, les opérations de maintenance du modèle de données multidimensionnel, telles que l’extension à de nouvelles dimensions d’analyse, nécessitent un chargement « ex novo » de la base de données. Pour cela, il faut évaluer de cas en cas le compromis entre les deux besoins et adopter selon les cas le Star Schema ou le Snowflake Schema. Il faut aussi ajouter que, pour des modèles très complexes, avec différentes fact tables partageant de nombreuses dimensions, il devient difficile d’adopter la technique dimensionnelle, aussi parce qu’il n’est pas toujours clair quelles sont les tables des faits et quelles sont celles des dimensions. Pour la conception conceptuelle de l’Enterprise Data Warehouse, un modèle de données Entity-Relationship approprié et dénormalisé semble donc plus préférable. La modélisation dimensionnelle est en revanche sans aucun doute plus adaptée à la représentation des données des Data Mart. Les modèles dimensionnels peuvent être implémentés aussi bien sur des DBMS relationnels que sur des DBMS multidimensionnels spécifiques. REPRODUCTION RÉSERVÉE
Pubblicato in Business
Soyez le premier à commenter