N°d’ordre : UNIVERSITE*MOHAMED BOUDIAF* DE M’SILA FACULTE DES SCIENCES ET SCIENCES DE L’INGENIEUR DEPARTEMENT D’INFORMATIQUE MEMOIRE Présenté pour l’obtention du diplôme de : Magister Spécialité : Informatique Option : Informatique industrielle Par : GHELLAB Abdelkrim Thème : Soutenu publiquement le : ----/----/-------- devant le jury composé de : Mr. BOUDERAH BRAHIM, Maître de Conférence, Université de M’sila Président Mr. BELOUADAH HOCINE, Maître de conférence, Université M'sila Rapporteur Mr. MAAMRA Mohamed Said, Chargé de recherche, USTHB Co-encadreur Mr. ABASSI Moncef, Professeur, USTHB Examinateur Mr. MIHOUBI Douadi, Maître d e conférence - Université de M’sila Examinateur Mr. BRAHIMI Mahmoud, Chargé de cours, Université de M’sila Invité CONCEPTION D'UNE BASE DE DONNEES DECISIONNELLE Résumé Le travail s'inscrit dans la problématique générale de la modélisation conceptuelle des Entrepôt de données. Le Domaine que nous avons choisi est relatif à la dérivation d'un schéma conceptuel pour les Entrepôt de données à partir des schémas opérationnels et en particulier les schémas E/R. Dans ce mémoire, nous avons présenté une approche de conception de schéma conceptuel multidimensionnel à partir du schéma E-R opérationnel, inspiré essentiellement de l’approche de Daniel L. Moddy et Mark A.R. Kortink comme approche de base, ainsi que les travaux de B. Husemman pour son formalise, sans oublier la démarche de R. Kimball, qui s'inscrit dans le cycle de vie dimensionnel. L’objectif principal de cette approche est d’exploiter le schéma E-R initial opérationnel et déduire les faits et les dimensions en utilisant la méthode de classification des entités du schéma E-R initial en trois classes (Transactionnelle, composante, classification), et puis déterminer les différentes hiérarchies existantes, et en premier définir les spécifications des besoins sous forme d’une série des questions ou requêtes pour les futures analyses OLAP, et un tableau de spécification obtenu à partir de l’analyse du schéma E-R initial et les requêtes des décideurs pour classifier les attributs (Mesure, Dimensionnel, Optionnel), et enfin produire le modèle multidimensionnel où nous avons un large choix d'options pour la réalisation de ce modèle. Chacune de ces différentes options (Etoile, Flocon de neige, Galaxie, Plat, etc.) représente le compromis entre la complexité et la redondance, et obéit à des règles de passage du modèle E-R d’entreprise vers le modèle multidimensionnel, et nous avons défini des niveaux de restriction pour toutes les mesures le long des différents chemins d'agrégation dans chaque schéma multidimensionnel de fait. Les Mots Clés: Entrepôt de données, Fait, Dimension, Magasins, Mesure, OLAP, Hierarchie Abstract The present work is interested in the general problem of the conceptual modeling of data warehouse. The Field that we have chosen relates to the derivation of a conceptual scheme for data warehouse starting from the operational scheme and in particular E/R ones. We have presented an approach that permits the conception (design) of a multidimensional conceptual scheme starting from operational E-R scheme, inspired essentially from the approach of Daniel L Moddy and Mark A.R. Kortink as a basic approach and the work of B.Husemman for its formalism, without forgetting the work of R. Kimball which falls under the dimensional cycle of life. The principal objective of this approach is to exploit the initial operational E-R scheme to deduce the facts and dimensions by using the entities classification method of the initial E-R scheme into three classes (Transactional, component, classification) then determine the various hierarchies that exist. Firstly, the needs specifications are defined in a form of series of questions or requests for the future OLAP analyses. Secondly, a specification table is obtained from the analysis of the initial E-R scheme and the requests of the deciders to classify the attributes (Measurement, Dimensional, Optional). Finally, to produce the multidimensional model where we have a broad choice of options (Star, Snowflake, Galaxy, Flat, etc.) each one represents the compromise between complexity and redundancy and obeys to many rules of passage from the company’s E-R model towards the multidimensional model. We have defined levels of restriction for all measurements along the various aggregation paths in each fact multidimensional scheme. Keys Word: Data Warehouse, Data Mart, Fact, dimension, hierarchie, OLAP, Measurement. ملخص خازن المجال الذي اخترناه يتمثل في إيجاد تصميم تصوري لم. هذا العمل يندرج في إطار النمذجة التصورية لمخازن المعطيات ).E/R(المعطيات انطلاقا من تصاميم عملية و بالأخص التصميم مستوحاة أساسا من ،العملي) E/R(مقاربة لإيجاد تصميم تصوري متعدد الأبعاد انطلاقا من التصميم اقترحنا ،في هذه المذآرة التي تندرج في إطار دورة ،آمبال.ر ن ننسى سيرورة دون أ،أوزمان. و آذا باستعمال تشكيل ب،آورتينك. ر.مودي و مارك أ.مقاربة دانيال ل .الحياة البعدوية و استخراج الأحداث و الأبعاد باستعمال طريقة (E/R)الهدف الأساسي للمقاربة المقترحة هو استعمال التصميم العملي الأولي لكن ، و بعد ذالك تعيين مختلف التدرجات الموجودة ، ) نصنيف، مرآب،معاملاتي( الأولي إلى ثلاثة أصناف (E/R)تصنيف آائنات التصميم و إنشاء جدول مواصفة انطلاقا من تحليل ، فيما بعدOLAPفي البداية تحديد المتطلبات على شكل سلسلة من الأسئلة أو طلبات لأجل محللي وفي النهاية التوصل إلى نموذج ،)ي اختيار، بعدوي،قياس( أجل تصنيف الخصائص ن الأولي و طلبات أصحاب القرار م(E/R)التصميم ) الخ، طبق، مجرة،ثلج آومة ال،نموذج نجمي(آل من هذه الاختيارات. متعدد الأبعاد أين يكون لدينا عدة خيارات من أجل إنجاز هذا النموذج و آذالك قمنا ،سسة إلى النموذج المتعدد الأبعاد المؤ(E/R) و يخضع إلى قواعد المرور من نموذج ،الوصلة بين التعقيد و التكراريشكل .بتعريف مستويات اقتصار من أجل آل القياسات عبر مختلف سبل التجميع في آل تصميم الأحداث متعدد الأبعاد الكلمات المفتاحية .تدرج ، OLAP ، قياس، مخزن، بعد، الحدث ،مخزن المعطيات Remerciements En tout premier lieu, je remercie mon dieu, tout puissant, qui m'a éclairé le bon chemin et qui m'aide à réaliser dans les meilleurs conditions ,ainsi que mes encadreurs respectivement Mr BELOUADAH Hocine, et Mr Maamra Med Said qui m'ont guidé avec patience et gentillesse et m'ont fait profiter de leurs grandes expériences ainsi que leurs précieuses remarques qui ont grandement contribué à améliorer la qualité de ce mémoire. Qu'il soit ici assuré de ma profonde gratitude et de mon très grand respect. Je tiens à remercier sincèrement l'ensemble des membres du Jury qui me font grand honneur d'avoir accepté de juger mon travail. Je remercie Mr. BOUDERAH BRAHIM, Maître de Conférence, Université de M’sila pour l'honneur qu'il me fait en acceptant la présidence de ce jury. Qu'il trouve donc ici l'assurance de ma profonde gratitude. Je tiens à exprimer tout ma reconnaissance à Messieurs ABASSI Moncef, professeur à USTHB, et MIHOUBI Douadi Maître d e conférence à l'université de M’sila, et BRAHIMI Mahmoud Chargé de cours à l'université de M’sila, pour avoir accepté d'être examinateurs de ce travail et pour le temps qu'il ont investi à l'évaluer malgré leurs nombreuses obligations. Je voudrais remercier tous mes collègues de la promotion Poste graduation, sans oublier Mr MAHDJOUBI Rosafi Chef Département Informatique, et MR GASMi Abdelkader Président du Conseil Scientifique, et à toutes les personnes qui ont contribué de prés ou de loin à l’élaboration de notre travail et tout particulièrement à Mr HIMEUR Fares, et BACHIRI Hamza. Merci infiniment à toutes mes sœurs et frères, mes collègues du travail. Dédicaces A ma chère mère et mon chèr père A ma chère femme A mon frère Khaled A mes Sœurs et mes frères A mon fils Abdelillah A ma chère poupée adorée Aichouche Sara A tous mes amies Introduction 1 Partie I. Système d'information Décisionnel I.1. Informatique Décisionnelle Vs Opérationnelle. 4 I.1.1. Informatique Décisionnelle Vs Opérationnelle 4 I.1.2. Définition d'un Data warehouse. 6 I.1.3. Composantes Architecturales d'un Data Warehouse 8 I.1.4. Entrepôts des données et magasins des données 10 I.1.5. Mise En Oeuvre D'un Data Warehouse 10 I.1.6. Système OLAP Versus Système OLTP 14 I.2. Cycle de Vie Multidimensionnel… 17 I.2.1. Planification de projet 18 I.2.2. Définition des besoins 19 I.2.3. Modélisation dimensionnelle des données 19 I.2.4. Conception du modèle physique de données 19 I.2.5. Conception et développement de la zone de préparation 20 I.2.6. Définition de l'architecture technique 20 I.2.7. Choix technologique et mise en œuvre 20 I.2.8. Développement de l'application utilisateur 21 I.2.9. Déploiement 21 I.2.10 Maintenance et croissance 21 I.2.11. Gestion du projet 22 Partie II. Architecture d'un Data warehouse II.1 Architecture d'un Data warehouse 23 II.1.1 Intégration/Construction/Réorganisation/Interrogation : 23 II.1.1.1 Intégration 23 II.1.1.1.1 Les méta données. 24 II.1.1.1.2. Intégration des schémas de sources. 25 II.1.1.1.3. L'extraction des données 25 II.1.1.1.4. Nettoyage des données. 26 II.1.1.1.5. L'intégration des données. 27 II.1.1.2 Construction 27 resèTable des mati II.1.1.3 Réorganisation 27 II.1.1.4 Interrogation 27 II.2. Les différentes architectures d'un data warehouse 28 II.2.1. L'architecture réelle 28 II.2.2. L'architecture Virtuelle. 29 II.2.3. L’architecture Remote 29 II.3. Datamining. 29 Partie III. Les Concepts de Base de la Modélisation Multidimensionnelle III.1 La Modélisation Multidimensionnelle. 30 III.1.1. Concepts de bases Multidimensionnels 30 III.1.1.1. Concept de Cube 30 III.1.1.2. Concept de Faits 36 III.1.1.3. Concept de Dimension 37 III.1.1.4. Concept d'hiérarchie 38 III.1.2. Schémas Multidimensionnels 38 III.1.2.1. Schéma en Etoile 39 III.1.2.2. Schéma en Flocon 40 III.1.2.3. Schéma en Constellation 41 III.1.2.4. Schéma en Grappe 42 III.1.2.5. Complexité Vs Redondance 43 III.1.2.6. Agrégations. 44 III.1.3. Les implémentations des modèles multidimensionnels 44 III.1.3.1. MOLAP. 45 III.1.3.2. ROLAP. 45 III.1.3.3. HOLAP. 46 Partie IV. Les Approches de conception Multidimensionnelle Introduction 47 IV.1.1. Conception d'un schéma conceptuel selon l'approche KIMBALL 47 IV.1.2. Les neuf décisions 48 IV.2. Conception d'un schéma conceptuel selon l'approche A.R. KORTINK et D.L M 50 IV.2.1. Introduction. 50 IV.2.2. Classification des entités 50 IV.2.3. Identification des hiérarchies. 52 IV.2.4. Production du modèle multidimensionnel. 53 IV.2.5. Evaluation et raffinement 65 IV.2.6. Conclusion 66 IV.3. Conception d'un schéma conceptuel selon l'approche B. Husemann & J. Lechtenborger, & G. Vossen 67 IV.3.1. Introduction. 67 IV.3.2. Terminologie et notation 67 IV.3.3. Un Modèle de processus de conception d'un DWH 70 IV.3.4. Modélisation Conceptuelle du DWH 72 PARTIE V APPROCHE PROPOSEE AVEC UNE ETUDE DE CAS: V.1 - Introduction : 79 V.2. Présentation Des Méthodes De Conception : 79 V.3. Choix De L’approche 80 V.4. Démarche De L’approche : 81 V.4.1. Planification Du Projet 81 V.4.2. Définition Et Analyse Des Besoins Décisionnels 81 V.4.3. Modélisation Dimensionnelle Des Données 82 V.4.4. Conception Et Développement De La Zone De Préparation 83 V.5.Etude De Cas : Filiale Les Moulins Du Hodna M’sila 87 Conclusion 97 Introduction▐ 1 INTRODUCTION : Devant le phénomène de la mondialisation qui a engendré un environnement de concurrence grandissant, la prise de décision est devenue cruciale et vitale pour les dirigeants et les chefs d'entreprises. L'efficacité de cette prise de décision repose sur la mise à disposition des informations pertinentes et d'outils adaptés aux décideurs et gestionnaires. Le problème des entreprises est d'exploiter efficacement d'importants volumes d'informations, provenant soit de leurs systèmes opérationnels, soit de leur environnement extérieur (et souvent mis en quarantaine), pour supporter la prise de décision. Les systèmes traditionnels s'avèrent inadaptés à une telle activité. Afin de pallier cet inconvénient, des systèmes décisionnels ont été développés; fondés sur les entrepôts de données et des outils d'investigation de ces données pour guider, voire suggérer des décisions cruciales. Cependant la mise en oeuvre d'un entrepôt ne peut actuellement s'effectuer à coûts et délais acceptables. Selon le "Meta Group", 95% des 500 entreprises les plus importantes aux Etats- Unis ont déjà ou sont en train de finaliser la mise en place d'un tel système [TEST00], et d'après une enquête d'information Week publie en Juin 1998 fait du Data Warehouse la priorité numéro 1 en matière d'évolution des système d'information d'entreprise [KIM97]. La plupart de ces systèmes reposent sur un espace de stockage centralisé, appelé entrepôt de données (data warehouse en anglais) ; son rôle est d'intégrer et de stocker l'information utile aux décideurs et de conserver l'historique des données pour supporter les analyses effectuées lors des prises de décision. Le schéma multidimensionnel est considéré comme le cœur de l’entreposage de données et comme l’élément de base dans le cycle globale de développement et de Introduction▐ 2 maintenance du data warehouse. Afin d’exprimer les caractéristiques du paradigme multidimensionnel, les approches de modélisation peuvent être basées sur des nouveaux modèles, ce qui nécessite des efforts additionnels pour leurs constructions tel qu’il est le cas dans les travaux de Agrawal [AGR97], et Cabibbo [CAB98]. C’est pour cette raison que la majorité des approches de modélisation multidimensionnelle sont basées sur l’extension des modèles existants afin d’exprimer les besoins décisionnels. Parmi les travaux basés sur cette approche nous citons les suivants : [TRU02], [AKO01], [GOLF98], l’objectif majeur de ces approches ou travaux est de proposer des modèles multidimensionnels standards permettant de représenter les données opérationnelles dans un niveau plus élevé [ASK03]. Contexte général de la thèse de mémoire Alors que peu de travaux de recherche à l'instant ont été conduits dans le domaine de présenter une méthode ou démarche complète pour dériver un schéma conceptuel pour les entrepôts de données à partir des schémas opérationnels et en particulier les schémas E/R qui représentent le modèle de données de la quasi majorité des schémas des bases de données opérationnelles en Algérie , pour cela nous essayons de faire un survol sur les méthodes de conceptions des schémas conceptuels multidimensionnels à partir du modèle relationnel et de faire une comparaison entre ces méthodes afin de présenter une démarche "Complète " qui peut aider un informaticien d'une organisation à exploiter leurs schémas opérationnelles de données et de tirer le schéma conceptuel du data warehouse. Cette approche sera inspirée essentiellement des travaux de Daniel L. Moody et Mark A.R. Kortink et al, et Bobo Huseman et al, et R. Kimball Introduction▐ 3 Pour cela nous allons suivre dans ce mémoire les lignes suivantes: - Présentations de tous les concepts relatifs aux systèmes décisionnels, Les entrepôts de données (Data Warehouse), les magasins (data marts), [1ere Partie, 2eme Partie, 3eme Partie] - Une présentation des principales méthodes de conception des entrepôts de données, [4eme Partie]. - Etude de cas pour illustrer la démarche proposée, [5eme Partie]. . PARTIE I: SYSTEME D’INFORMATION DECISIONNEL▐ 4 PARTIE 1 SYSTEME D’INFORMATION DECISIONNEL I.1. INFORMATIQUE DECISIONNELLE VS OPERATIONNELLE I.1.1. Informatique Décisionnelle Vs Opérationnelle: Loin d’être qu’un simple phénomène de mode, l’informatique décisionnelle est devenue incontournable pour toute entreprise moderne. Les enjeux économiques et financiers des entreprises sont devenus tels que l’intuition et la réflexion ne suffisaient plus à prendre une décision. Dans un monde où la concurrence fait rage et où chaque choix stratégique peut être vital, les décideurs devaient se munir d’outils informatiques puissants et fiables visant à faciliter la tâche de pilotage de l’entreprise. Et ceci en offrant les moyens d’exploiter les données stockées dans les bases de données de l’entreprise souvent restées au stade d’archives, et d’en extraire le contenu informationnel qui servira de miroir de l’état de l’entreprise et qui permettra la compréhension du passé et du coup à une meilleure anticipation du futur. Définition 1 : Une définition simple consiste à dire que l’informatique décisionnelle en anglais « business intelligence » est la branche de l’informatique qui permet l'exploitation des données de l'entreprise dans le but de faciliter la prise de décision. C'est-à-dire, la compréhension du fonctionnement actuel et l'anticipation des actions pour un pilotage éclairé de l'entreprise. Définition 2 : Une deuxième définition plus technique veut que nous présentions en premier lieu les différents niveaux d’un système d’information et que nous définissions ce qu’est un système d’information décisionnel. PARTIE I: SYSTEME D’INFORMATION DECISIONNEL▐ 5 I.1.1.1 Les différents niveaux d’un système d’information d’une organisation: Résumé dans le schéma ci-dessous, un système d’information se décompose en trois niveaux : A- Le niveau opérationnel : Concerne les données relatives aux différentes fonctions de l’entreprise, il s’agit des bases de données résultantes des sources d’information internes. B- Le niveau décisionnel : Constitue une synthèse des données opérationnelles, choisies pour leur pertinence. Ce niveau concerne des données qui, agrégées, intégrées et organisées sur base de structures particulières de stockage volumineux, résultent en informations pertinentes à la décision. C- Le niveau stratégique : le niveau le plus élevé dans la hiérarchie, concerne l’orientation des informations résidant au niveau décisionnel en vue de fournir des indicateurs pertinents. Ce niveaux fourni au décideur d’une part, des systèmes de pilotage qui lui fournissent une série de tableaux de bord et de synthèse, très souvent enrichis de fonctionnalités statistiques et de simulations, et d’autre part sur des outils d’extraction, de gestion de connaissances qui permettent de mettre en évidence des corrélations entre des événements apparemment non liés. La finalité du niveau stratégique est le pilotage de l’entreprise dans une vision stratégique à long terme [Van01]. PARTIE I: SYSTEME D’INFORMATION DECISIONNEL▐ 6 I.1.2 - Définition d'un Data Warehouse : Toute entreprise possède actuellement d'importants volumes de données, stockés le plus souvent dans différents médias (bases de données, documents papiers,...) et a besoin d'outil permettant une exploitation efficace et performante de ces données pour l'aider dans ses prises de décision. Les entrepôts de données apportent des solutions à cette problématique. Un entrepôt se définit par Bill Immon référence, considère comme le père du concept, dans son livre "Using the Data Warehouse", il en donne la définition suivante, qui fait référence : "Le Data Warehouse est une collection de données intégrées, orientées sujet, non volatiles, historisées, résumées et disponibles pour l’interrogation et l’analyse" [FRA00], [EVO00]. Il permet de stocker des données nécessaires à la prise de décision ; il est alimenté via des extractions de données portant sur les bases de production (sources de données) et la saisie de données quotidiennes [EVO99]. information ’me dèun syst’rents niveaux déLes diff: 1° NFigure Niveau stratégique (connaissances) Niveau décisionnel (information) Niveau opérationnel (données) Systèmes de pilotages: Outils OLAP,EIS,SIAD Outils de simulation Outils de fouille de données,… Systèmes d’entreposage Info centre, base de données multidimensionnelles, Systèmes opérants : Outils OLTP, Base de données, Fichier de données, Système d’acquisition et se restitution de données,… Couloirs Applications informatiques PARTIE I: SYSTEME D’INFORMATION DECISIONNEL▐ 7 Les données d’un Entrepôt de données respectent donc les caractéristiques suivantes : – Intégrées : Les données de l’entrepôt proviennent de différentes sources éventuellement hétérogènes. L’intégration consiste à résoudre les problèmes d’hétérogénéité des modèles, des schémas, de la sémantique. – Orientées sujet : Les données de l’entrepôt sont organisées autour des thèmes qui ont un intérêt majeur pour l'entreprise, le but de cette organisation est de disposer de l'ensemble des informations utiles sur un thème le plus souvent transversal aux structures fonctionnelles et organisationnelles de l'entreprise tels que : Le client, Le Produit, Les Ventes… Cette orientation par thème va permettre à l'entreprise de développer son système décisionnel progressivement, c’est une approche par itération. - Non volatiles : Les données de l’entrepôt sont essentiellement utilisées en mode de consultation; elles sont très rarement modifiées, la non volatilité des données est en quelque sorte une conséquence de l’historisation. – Historisées : La prise en compte de l’évolution des données est primordiale pour la prise de décision et notamment les prédictions. Dans un système de production ; la donnée est mise à jour à chaque nouvelle transaction. Dans un Data Warehouse, la donnée ne doit jamais être mise à jour. Un référentiel temps doit être associé à la donnée afin d’être capable d’identifier une valeur particulière dans le temps. PARTIE I: SYSTEME D’INFORMATION DECISIONNEL▐ 8 – Résumées : Les informations issues des sources de données doivent être agrégées (ou résumé) et réorganisées afin de faciliter le processus de prise de décision. – Disponibles pour l’interrogation et l’analyse : Les utilisateurs doivent pouvoir consulter les données réorganisées de l’entrepôt en fonction de leurs droits d’accès. De plus, l'entrepôt de données offre à l’entreprise les avantages suivants [EVO00] : – Il constitue une collection de données centralisées disponibles pour l’aide à la décision (OLAP, datamining,...). – Les évolutions des données de l’entrepôt sont conservées (historisation des données). – Il contient un ensemble de données consolidées (données homogènes et fiables). – Il contient des données agrégées permettant une analyse à différents niveaux de détails. – Il permet de développer différents thèmes d’analyse (réorganisation en fonction des sujets à analyser). I.1.3 Composantes Architecturales d'un Data Warehouse: L'architecture des systèmes décisionnels met en jeu quatre éléments essentiels : les sources de données, l'entrepôt de données, les magasins de données et les outils d'analyse et d'interrogation. PARTIE I: SYSTEME D’INFORMATION DECISIONNEL▐ 9 Figure N° 2 : Les Composants du Data Warehouse [BOL02] √ Les sources de données: sont nombreuses, variées, distribuées et autonomes. Elles peuvent être internes (bases de production de l'entreprise) ou externes (Données fournies par les partenaires tels que: Les fournisseurs, clients, Administration Publiques, Documentation Juridiques) à l'entreprise. √ L'entrepôt de données: est le lieu de stockage centralisé des informations utiles pour les décideurs. Il met en commun les données provenant des différentes sources et conserve leurs évolutions. √ Les magasins de données: sont des extraits de l'entrepôt orientés sujet. Les données sont organisées de manière adéquate pour permettre des analyses rapides à des fins de prise de décision, et principalement dédie à une classe de décideurs. PARTIE I: SYSTEME D’INFORMATION DECISIONNEL▐ 10 √ Les outils d'analyse : permettent de manipuler les données suivant des axes d'analyses. L'information est visualisée au travers d'interfaces interactives et fonctionnelles dédiées à des décideurs souvent non informaticiens (directeurs, chefs de services,…). I.1.5. Entrepôts des données et Magasins des données Il est important de distingue les entrepôts et les magasins [TEST00]: L’entrepôt de données est le lieu de stockage centralisé d'un extrait des bases de production. Cet extrait concerne les données pertinentes pour le support à la décision. Elles sont intégrées et historisées. L’organisation des données est faite selon un modèle qui facilite la gestion efficace des données et leur historisation. Le magasin de données : Est un extrait de l'entrepôt. Les données extraites sont adaptées à une classe de décideurs ou à un usage particulier (recherche de corrélation, logiciel de Statistiques,...). L’organisation des données suit un modèle spécifique qui facilite les traitements décisionnels. I.1.5. LA MISE EN OEUVRE D'UN DATA WAREHOUSE Quatre caractéristiques ont des effets déterminants sur la démarche de conception d’un Data Warehouse [FRA00]: a- Les évolutions technologiques : un système d’information peut se construire par intégration d’un certain nombre de composants, chacun pouvant être choisi par rapport à son contexte d’utilisation. L’entreprise défini son architecture en fonction de ses besoins. PARTIE I: SYSTEME D’INFORMATION DECISIONNEL▐ 11 b- La stratégie de l’entreprise: le Data Warehouse est très proche de la stratégie de l’entreprise. L’objectif du Data Warehouse se définit en terme de métier. Il faut donc impliquer les utilisateurs ayant le plus de connaissances dans leur entreprise ou dans leur métier. c- L’amélioration continue: un Data Warehouse doit évoluer en fonction des demandes utilisateurs ou des nouveaux objectifs de l’entreprise. d- La maturité de l’entreprise: certaines entreprises ont déjà un système décisionnel. D’autres n’ont aucun acquis. Dans tous les cas, il n’existe pas de cadre figé pour la conception d’un Data Warehouse. Chaque entreprise doit adapter le projet à son contexte, en ne perdant pas les objectifs de vue. Cet objectif est de mettre en place un système d’information cohérent et intégré, le système devant être décomposé en applications, chacune s’intégrant dans le Data Warehouse. I.1.5.1 - DECOUVRIR ET DEFINIR LES INITIATIVES Cette phase consiste en l’étude stratégique du Data Warehouse et la définition du plan d’action. I.1.4.1.1 - L’étude Stratégique Pendant l’étude stratégique, il faut : - Informer et motiver les personnes concernées dans l’entreprise. - Impliquer les managers, les équipes opérationnelles, les équipes informatiques: phase d’identification et de compréhension des enjeux métier/entreprise. - Identifier les projets Data Warehouse. L’étude stratégique permet d’identifier la stratégie de l’entreprise, son organisation, les processus qu’elle met en œuvre, la culture de l’entreprise. Le but est de déterminer les domaines pour lesquels la mise en place d’un Data Warehouse peut être le plus bénéfique. PARTIE I: SYSTEME D’INFORMATION DECISIONNEL▐ 12 I.1.5.1.2 - Le Plan d’action Pour mettre en place le plan d’action, il faut : - Vérifier la faisabilité de chaque projet (s’assurer de l’existence et de la qualité des données, des possibilités techniques, des possibilités organisationnelles). - Estimer les ressources pour chaque projet. - Séquencer et planifier les projets. I.1.5.2 - L’INFRASTRUCTURE Il s’agit de déterminer l’infrastructure technologique et organisationnel nécessaire à la mise en place du Data Warehouse. I.1.5.2.1- L’infrastructure Technique Des choix technologiques en phase avec la politique de l’entreprise doivent être faits à plusieurs niveaux : - Les fournisseurs : faut-il prendre un seul fournisseur (ce qui facilite la politique d’intégration et en réduit les coûts de mise en œuvre) ou assembler les meilleurs offres du marché (ce qui apporte une flexibilité, une adaptation à chaque projet, mais coûte beaucoup en intégration). - Les outils : faut-il construire, acheter ou faire avec l’existant. - Comment sera utilisé le Data Warehouse, par qui, comment sera structuré l’organisation qui l’exploitera. - Faut-il une architecture centralisé (Data Warehouse), distribuée (plusieurs Data Mart), ou une architecture répliquée (un Data Warehouse et plusieurs Data Mart). - La structure de stockage, sera-t-elle relationnelle, multidimensionnelle, hybride (Data Warehouse en relationnel, Data Mart en multidimensionnel). - Choisir le matériel : selon les volumes envisagés, les utilisateurs concernés, l’architecture visée, la flexibilité attendue. PARTIE I: SYSTEME D’INFORMATION DECISIONNEL▐ 13 - Organiser l’administration des systèmes et la gestion de la sécurité. I.1.5.2.2 - L’infrastructure Organisationnelle Parallèlement aux choix technologiques, il faut : - Déterminer la logistique et l’organisation nécessaires à la concrétisation des initiatives. - Répartir les tâches entre les équipes de développement et les équipes d’exploitation : déterminer l’alimentation du Data Warehouse, l’administration. - Déterminer les flux d’informations entre le Data Warehouse et les utilisateurs. I.1.5.3 - LA MISE EN ŒUVRE DES APPLICATIONS La démarche proposée est une démarche en cinq étapes : - La Spécification, - La Conception, - La Mise En Œuvre et l’intégration, - Le Déploiement Et La Mise En Place Des Accompagnements, - Les Mesures. Ces étapes correspondent à celles de mise en place d’un projet informatique. Pendant l’étape de spécification, les différentes étapes des initiatives sont définies et planifiées de manières plus détaillées. Il est recommandé de faire attention aux coûts cachés que peuvent entraîner les technologies informatiques. L’étape de mesure permet de faire le bilan de la réalisation et de capitaliser les réussites et échecs rencontrés pendant le développement de l’application. Deux visions du Data Warehouse cohabitent dans l’approche précédente : - Une vision entreprise : chaque projet défini dans la première phase (initiative) est construit de manière indépendante et répond à un objectif métier délimité, tout en s’intégrant dans le Data Warehouse. PARTIE I: SYSTEME D’INFORMATION DECISIONNEL▐ 14 - Une vision projet : les projets identifiés deviennent des applications. Donc le processus est itératif. Il n’existe pas de démarche complète et universelle pour la mise en œuvre d’un data Warehouse. Toute approche doit être adaptée à l’entreprise. I.1.5.4 - L’ADMINISTRATION DES DONNEES Comme tout autre système informatique, un Data Warehouse s’administre. Dès la phase de conception de l’architecture, il faut penser à l’administration des données, c’est une des fonctions les plus importantes du Data Warehouse. Cette fonction est d’autant plus importante que le Data Warehouse évolue au fur et à données, permettant de décrire, stocker et diffuser les méta-données associées. Cette mise en place passe par l’organisation d’une fonction d’administration des données à plusieurs niveaux, par la définition de normes et de procédure d’administration des référentiels. I.1.6. SYSTEMES OLAP VERSUS SYSTEMES OLTP I.1.61. OLAP Versus OLTP Les bases de données sont utilisées dans les entreprises pour organiser les importants volumes d'informations contenus dans leurs systèmes opérationnels. Ces données sont gérées selon des processus transactionnels en ligne (OLTP : "On-Line Transactional Processing" . L'exploitation de l'information contenue dans ces systèmes opérationnels est devenue une préoccupation essentielle pour les dirigeants qui sont appelles à prendre des décisions par une meilleure connaissance de leur activité, et par conséquent les entreprises sont donc à la recherche de systèmes supportant efficacement les applications d'aide à la décision. Ces applications décisionnelles PARTIE I: SYSTEME D’INFORMATION DECISIONNEL▐ 15 utilisent des processus d'analyse en ligne de données (OLAP : "On-Line Analytical Processing". Ces processus répondent aux besoins spécifiques des analyses d'information [Codd93] [TEST00]. I.1.6.2. - Les 12 Règles OLAP de E.F Codd OLAP est le terme pour décrire l'approche dimensionnelle de l'aide à la décision. Tout comme OLTP, OLAP a été proposé par E. F. Codd. Cette philosophie comprend douze critères qui représentent l'étalon de mesure servant à comparer les systèmes d'aide à la décision. A ces douze critères, 6 ont été ajoutés en 1995. Il faut noter que ces six critères supplémentaires sont rarement cités et utilisés [HES03]. 1 - Vue multidimensionnelle Permet d'avoir une vision multidimensionnelle des données. 2 – Transparence du serveur OLAP à différents types de logiciels L'utilisateur ne doit pas se rendre compte de la provenance des données si celles-ci proviennent de sources hétérogènes; ces sources peuvent être un fichier Excel, une base de données de production ou même un fichier texte. 3 – Accessibilité à de nombreuses sources de données OLAP est décrit comme un middleware qui se place entre les sources de données hétérogènes et un front-end (sous la forme d'un data warehouse). Il doit donner accès aux données nécessaires aux analyses demandées afin de présenter à l'utilisateur une vue simple et cohérente. Ils doivent aussi savoir de quel type de systèmes proviennent les données. 4 - Performance du système de Reporting Les performances ne doivent pas être diminuées lors de l'augmentation du nombre de dimension ou de la taille de la base de données, mais proportionnelles à la taille des réponses retournées. PARTIE I: SYSTEME D’INFORMATION DECISIONNEL▐ 16 5 - Architecture Client/Serveur Il est essentiel que le produit soit en Client-Serveur mais aussi que les composants serveurs d'un produit OLAP intègrent facilement ses différents clients. 6 - Dimensions Génériques Chaque dimension doit être équivalente par rapport à sa structure et à ses capacités opérationnelles. 7 - Gestion dynamique des matrices creuses Le système OLAP ajuste automatiquement son schéma physique pour s'adapter au type du modèle et au volume des données (plus on dispose de place plus on peut agréger). 8 - Support Multi-Utilisateurs Les outils OLAP doivent fournir des accès concurrents, l'intégrité et la sécurité. 9 - Calculs à travers les dimensions Les calculs doivent être possibles à travers toutes les dimensions (les agrégats doivent être faits dans toutes les dimensions). 10 - Manipulation intuitive des données La manipulation des données se fait directement à travers les cellules d'une feuille de calcul, sans recourir aux menus ou aux actions multiples. Il doit permettre l'analyse intuitive dans plusieurs dimensions au final. 11 - Souplesse et facilité de constitution des rapports Lors de la création de rapport, les dimensions peuvent être présentées de n'importe quelle manière. 12 - Nombre illimité de niveaux d'agrégation et de dimensions Dimensions et niveaux d'agrégations illimités. PARTIE I: SYSTEME D’INFORMATION DECISIONNEL▐ 17 I.1.6.3.Comparaison des caractéristiques des processus OLAP et OLTP Processus OLTP Processus OLAP Données Exhaustives Courantes Dynamiques Orientées applications Résumées Historiques Statiques Orientées sujets (d'analyse) Utilisateurs Nombreux Variés (employés, directeurs,…) Concurrents Mises à jours et interrogations Requêtes prédéfinies Réponses immédiates Accès à peu d'information Peu nombreux Uniquement les décideurs Non concurrents Interrogations Requêtes imprévisibles et complexes Réponses moins rapides Accès à de nombreuses informations Administration Des Données Forte disponibilité Sauvegardes fréquentes Peu de maintenance off- line Disponibilité faible Sauvegardes peu fréquentes mais très volumineuses Beaucoup de maintenance mais en off-line Tableau 1: Comparaison des processus OLTP et OLAP. I.2. CYCLE DE VIE DECISIONNEL: La réussite de l'implémentation d'un entrepôt de données dépend de l'intégration adéquate de nombreux composants et taches, Il ne suffit pas de posséder le modèle de données parfait ou la meilleur technologie; il s'agit de PARTIE I: SYSTEME D’INFORMATION DECISIONNEL▐ 18 coordonner les multiples facettes du projet de data warehouse. Donc une exposition d'une méthodologie globale pour l'implémentation d'entrepôt de données par le cycle de vie dimensionnel est nécessaire, le schéma ci-dessous représente une succession de taches de haut niveau nécessaire à la conception au développement et au déploiement d'un entrepôt de données efficace [KIM00]. Figure N° 3 : Schéma d’un cycle de vie multidimensionnel [KIM00]. I.2.1. Planification du projet: La planification du projet aborde la définition et l'étendue du projet de data warehouse, elle se concentre sur les besoins en termes de ressources et de niveau de qualification, couples aux affectations des taches, a leurs durées et a leurs séquencement. La planification dépend des besoins comme l'indique la flèche double dans le schéma. PARTIE I: SYSTEME D’INFORMATION DECISIONNEL▐ 19 I.2.2. Définition des besoins: Il est essentiel de bien comprendre les utilisateurs et leurs besoins, sinon l'entrepôt deviendra rapidement un exercice vain de la part de l'équipe des concepteurs. L'approche utilisée pour identifier les besoins analytiques diffère de manière significative de la traditionnelle analyse des besoins basés sur les données. Les besoins une fois définis constituent le point de départ de trois trajectoires parallèles que sont la technologie, les données et les interfaces utilisateurs. I.2.3 Modélisation dimensionnelle C'est la définition des besoins qui détermine quelles sont les données requises pour répondre aux besoins d'analyse des utilisateurs. La conception du modèle logique de données commence par la construction d'une matrice représentant les processus métier clé et leurs dimensionnalités. A partir de cette matrice, il faut effectuer une analyse plus détaillée des données du (des) système(s) source(s) opérationnels. Le résultat de cette analyse est le modèle dimensionnel. Ce modèle identifie la granularité de la table de fait, les dimensions associées avec leurs attributs et leurs hiérarchisations. Cet ensemble d'activités s'achèvera sur le développement d'une mise en correspondance des données sources et cibles dans des méta données. I.2.4. Conception du modèle physique La conception physique d'une base de données définit les structures nécessaires pour l'implémentation du modèle dimensionnel. Les éléments fondamentaux sont la détermination des règles de nommage des objets, la mise en place de l'environnement de la base de données. L'indexation primaire, les stratégies de partitionnement et les agrégations primaires sont également définies. La PARTIE I: SYSTEME D’INFORMATION DECISIONNEL▐ 20 conception du modèle physique est fortement dépendante de la machine utilisée pour l'entrepôt. I.2.5. Conception et développement de la zone de préparation des données La conception de la zone de préparation des données (staging area) constitue généralement la tache la plus sous-estimée du projet entrepôt de données. Le processus de préparation se déroule en trois phases majeures : • Extraction • Transformation • Chargement (Loading) Le processus d'extraction des données révèle généralement le problème de la qualité des données, qui influence de manière significative la crédibilité de l'entrepôt. L'extraction est compliquée par le fait qu'il faut la construire avec deux processus distincts, le peuplement initial et le chargement régulier et incrémentiel. I.2.6. Définition de l'architecture technique Cette étape définit la vision globale de l'architecture technique à mettre en Œuvre. Elle nécessite la prise en compte de trois facteurs : • Les besoins • L'environnement existant • Les orientations techniques stratégiques planifiées En plus de l'architecture supportant l'entrepôt, il est nécessaire de mener des réflexions sur les outils de conception de la zone de préparation des données et des outils de restitutions I.2.7. Choix technologique et mise en œuvre A partir de l'étude de l'architecture technique il faut sélectionner les composants spécifiques, telle plate-forme(s)matérielle(s)et logicielle(s), SGBD PARTIE I: SYSTEME D’INFORMATION DECISIONNEL▐ 21 outils d'extraction et restitution à mettre en Œuvre. Une fois les produits évalués et sélectionnés, ceux-ci doivent être installés et testés méticuleusement afin de garantir une intégration adéquate d'un bout à l'autre de l'environnement de l'entrepôt. I.2.8. Développement de l'application utilisateur Il est recommandé de définir une série d'applications standard destinées aux utilisateurs finaux, car tous n'ont pas besoin d'un accès ad hoc à l'entrepôt. Les spécifications de l'application décrivent les maquettes d'états, les critères de sélection laissés à l'utilisateur et les calculs nécessaires. I.2.9. Déploiement: Le déploiement est le point de convergence de la technologie, des données et des applications utilisateurs. Une planification est indispensable pour gérer le déploiement qui comprend également la formation des utilisateurs, les processus de communication, le support utilisateur, la prise en compte des demandes d'évolution et de correction. I.2.10. Maintenance et croissance: Après le déploiement initial de l'entrepôt, c'est sa vie qui commence. Il faut s'assurer de fournir un service de support et de formation continue. Il faut également s'assurer que les processus mis en place pour la gestion de la zone de construction vont faire fonctionner l'entrepôt en continu et efficacement. Il est également important de mesurer périodiquement les performances de l'entrepôt et de son acceptation dans l'entreprise. L'entrepôt va donc évoluer et croître et le changement doit être perçu comme un facteur de succès et non d'échec. Des processus de hiérarchisation des priorités doivent bien sur être mis en place afin de gérer les demandes des utilisateurs en termes d'évolution et de croissance. PARTIE I: SYSTEME D’INFORMATION DECISIONNEL▐ 22 I.2.11. Gestion du Projet: La gestion du projet garantit que les activités du cycle de vie restent sur la bonne voie et sont bien synchronisées. Cela consiste à contrôler l'état d'avancement du projet, la détection et la résolution des problèmes et le contrôle des changements afin de garantir l'accès aux objectifs du projet. PARTIE II: ARCHITECTURE D'UN SYSTEME DECISIONNEL▐ 23 PARTIE II: ARCHITECTURE D'UN SYSTEMES DECISIONNELS: II.1 - ARCHITECTURE D'UN SYSTEMES DECISIONNELS: Un système décisionnel est un système d'information dédié aux applications décisionnelles [Test00], dans cette partie nous allons présenter l'ensemble des concepts de base de l'architecture du data Warehouse et qui regroupe l'ensemble d'informations et d'outils mis à la disposition des décideurs pour supporter de manière efficace la prise de décision. Figure N° 4 : Architecture détaillée d’un système décisionnel II.1.1. Intégration/Construction/Réorganisation/Interrogation : II.1.1.1 L'intégration Se propose de résoudre les problèmes d'hétérogénéité (systèmes, modèles, formats et sémantiques des données,…) des différentes sources de données en intégrant celles-ci dans une source globale. Cette source globale est virtuelle, S 1 I N T E G R A T I O N C O N S T R U C T I O N I N T E R R O G A T I O N R E O R G A N I S A T I O N MD1 MD1 MD1 S 2 S n -Requêtes -Analyse OLAP -Data Mining Extraction Exploitation ED SG -SG: Source Globale -ED : entrepôt de donnée -MD1: Magasin de donnée 1 -S1 : Source 1 PARTIE II: ARCHITECTURE D'UN SYSTEME DECISIONNEL▐ 24 c'est à dire que les données utilisées pour la décision restent stockées dans les sources de données et sont extraites uniquement au moment des mises à jour de l'entrepôt [TEST00]. Diverses architectures réalisent la production de données intégrées. Elles ont en commun les composantes suivantes [EVO99] : (1) - Des méta données, (2) - Intégration des schémas des sources (3) - Des outils d'extraction de données, (4) - Des outils de nettoyage de données, (5) - Des outils d'intégration de données. II.1.1.1.1- Les meta-données Dans le contexte d'un entrepôt de données, "décrire une donnée" consiste principalement à indiquer comment l'obtenir à partir des sources. Les meta- données jouent un rôle important d'une part dans les algorithmes d'extraction, de rafraîchissement et d'intégration, et d'autre part dans la présentation d'une vision globale des données aux administrateurs et aux utilisateurs. Les meta-donnees regroupent l'ensemble des informations concernant le Date Warehouse et les processus associés. Elles sont intégrées dans un référentiel. Les principales informations sont destinées [FRA00] : A l'utilisateur final (Information sur la sémantique des données utilisées). Aux équipes responsables de l'acquisition des données du Date warehouse (Information sur la localisation de la donnée dans le système de production, etc.). Aux équipes d'administration de la base de données (Information sur la structure de la base de données qui implémente le Data Warehouse). Aux équipes de production (Information sur les procédures de chargement, historique des Mise a jour, etc.). PARTIE II: ARCHITECTURE D'UN SYSTEME DECISIONNEL▐ 25 Une partie des meta-données est propre à une application (ex : description des attributs des sources), et des données de connaissances générales (ex : tables de conversion de monnaies). D'autres sont obtenues par personnalisation de connaissances générales (ex : dictionnaire de synonymes). Généralement, elles représentent toutes les informations nécessaires à l’accès, à la compréhension et à l’exploitation des données du Data Warehouse. [CNAM98], [FRA00]. Type d’information et Signification Sémantique : Que signifie la donnée ? A quoi sert cette donnée? Origine : D’où vient-elle, où, par qui est-elle créée ou mise à jour Règle de calcul : Règle de calcul. Règle d’agrégation : Périmètre de consolidation Stockage, format : Où, comment est-elle stockée, sous quel format II.1.1.1.2- Intégration des schémas des sources L'intégration des schémas des sources fait apparaître des conflits, depuis longtemps bien répertoriés dans la littérature. Les principaux conflits pouvant survenir entre deux schémas sont les suivants : o - Problèmes de terminologie. o - Incompatibilités de contraintes. o - Conflits de structures. o - Conflits de représentation. II.1.1.1.3- L'extraction des données L'hétérogénéité physique des sources est traitée par l'ajout au-dessus de chaque source d'un extracteur -en anglais "wrapper"- qui extrait les données désirées et les formate dans un modèle commun. Ce modèle commun est PARTIE II: ARCHITECTURE D'UN SYSTEME DECISIONNEL▐ 26 généralement le modèle relationnel, principalement du fait que les données extraites représentent un gigantesque volume d'informations, et donc sont dans un premier temps stockées à l'aide d'un SGBD relationnel adapté, tel ORACLE 7 ou SYBASE. L‘idéal est de ne recharger l‘entrepôt qu‘avec les données modifiées ou ajoutées depuis la dernière extraction. Certains outils fournissent ce type de fonctionnalité, et s‘appuie par exemple sur un mécanisme de marquage des données (date de la dernière modification associée à la donnée) [EVO99]. II.1.1.1.4- Le nettoyage des données Le "nettoyage" (appelé aussi "épuration", ou "analyse de la qualité des données") des données ont pour but de résoudre le problème de la consistance des données. Ces inconsistances peuvent être locales à un enregistrement (ex : une erreur de frappe), locales à une source (ex : une même personne a deux adresses différentes), ou peuvent survenir lors de la mise en commun de deux sources (ex: une personne a une adresse différente dans chaque source). Une centaine de type d'inconsistances ont été répertoriées. Elles peuvent être dues : 1- à la présence de données fausses dès leur saisie, 2- à la persistance de données obsolètes, 3- à la confrontation de données exactes, sémantiquement identiques, mais syntaxiquement différentes. De nombreux outils comme ACTAWorks, EDD Datacleanser et GENIO, sont disponibles sur le marché pour nettoyer les données. La plupart des outils de nettoyage traitent en profondeur le problème des adresses et des noms de clients. C'est en effet un des problèmes pratiques les plus cruciaux des entrepôts de données, cette donnée étant d'une part de la plus haute importance, et d'autre part à la fois subjective, sans format fixe et volatile. PARTIE II: ARCHITECTURE D'UN SYSTEME DECISIONNEL▐ 27 II.1.1.1.5- L'intégration des données Deux principales approches permettent un accès unifié à des sources de données hétérogènes : une approche virtuelle (souvent appelée approche par médiateur) et une approche matérialisée (approche par entrepôt). - Les approches virtuelles: Sont basées sur une hiérarchie de médiateurs, correspondant à des vues virtuelles, au-dessus des extracteurs. Les données ne sont stockées que dans leur source d'origine. - L'approche matérialisée : les données sont effectivement extraites, nettoyées, intégrées et stockées dans un entrepôt. Les requêtes sont posées directement sur les données de l'entrepôt, un des problèmes majeurs à résoudre dans cette approche est celui de la répercussion dans l'entrepôt des mises à jour effectuées sur les sources. L'approche virtuelle a été traditionnellement utilisée pour des systèmes répartis et hétérogènes. II.1.1.2 La construction Consiste à extraire les données pertinentes pour la prise de décision, puis à recopier dans l’entrepôt de donnée [TEST00]. II.1.1.3 La réorganisation Permet de restructurer les données dans des magasins de données la réorganisation des données vise à supporter efficacement les processus d'interrogation et d'analyse tels que les applications OLAP [TEST00]. II.1.1.4 L'interrogation Consiste à manipuler les données multidimensionnelles afin d'analyser les tendances passées pour prendre des décisions. Les données sont représentées sous une forme visant à faciliter leur compréhension et leur manipulation pour les décideurs non informaticiens (tableaux à n dimensions, graphiques,…). PARTIE II: ARCHITECTURE D'UN SYSTEME DECISIONNEL▐ 28 Le Tableau 2 résume le rôle de chaque module constituant le système décisionnel. A chacun de ces modules correspond des problématiques distinctes et spécifiques. Tableau 2: les modules constituent le système décisionnel et leur rôle II.2. Les différentes architectures d'un data warehouse: Pour implémenter un Data Warehouse, trois types d’architectures sont possibles [CNAM98]: • L’architecture réelle, • L’architecture virtuelle, • L’architecture remote. II.2.1. L'architecture réelle Elle est généralement retenue pour les systèmes décisionnels. Le stockage des données est réalisé dans un SGBD séparé du système de production. Le SGBD est alimenté par des extractions périodiques. Avant le chargement, les données subissent d’importants processus d’intégration, de nettoyage, de transformation. L’avantage est de disposer de données préparées pour les besoins de la décision et répondant aux objectifs du Data Warehouse. PARTIE II: ARCHITECTURE D'UN SYSTEME DECISIONNEL▐ 29 Les inconvénients sont le coût de stockage supplémentaire et le manque d’accès en temps réel. II.2.2. L'architecture Virtuelle Cette architecture n’est pratiquement pas utilisée pour le Data Warehouse. Les données résident dans le système de production. Elles sont rendues visibles par des produits middleware ou par des passerelles. Il en résulte deux avantages : pas de coût de stockage supplémentaire et l’accès se fait en temps réel. L’inconvénient est que les données ne sont pas préparées. II.2.3. L’architecture Remote C’est une combinaison de l’architecture réelle et de l’architecture virtuelle. Elle est rarement utilisée. L’objectif est d’implémenter physiquement les niveaux agrégés afin d’en faciliter l’accès et de garder le niveau de détail dans le système de production en y donnant l’accès par le biais de middleware ou de passerelle. PARTIE III: LES CONCEPTS DE BASE DE LA MODELISATION▐ 30 PARTIE III: LES CONCEPTS DE BASE DE LA MODELISATION MULTIDIMENSIONNELLE III.1 LA MODELISATION MULTIDIMENSIONNELLE III.1.1. Concepts de bases Multidimensionnels III.1.1.1. Concept de Cube: Le Cube de données offre une abstraction très proche de la façon dont l'analyse voit et interroge les données. Il organise les données en une ou plusieurs Dimensions qui déterminent une mesure d'intérêt. Une dimension spécifie la manière dont on regarde les données pour les analyser, alors qu'une mesure est un objet d'analyse. Chaque dimension est formée par un ensemble d'attributs et chaque attribut peut prendre différentes valeurs. Les dimensions possèdent en général des hiérarchies associées qui organisent les attributs à différents niveaux pour observer les données à différentes granularités. Une dimension peut avoir plusieurs hiérarchies associées, chacune spécifiant différentes relations d'ordre entre ses attributs [BEL00]. Produit Vente de Joint en 1999 pour la région Est sentant la Fonction VenteséLe Cube Repr: 5° Figure N Ecrous Vis Boulons Joint Ressort 1999 1998 1997 Est Ouest Centre Date Région PARTIE III: LES CONCEPTS DE BASE DE LA MODELISATION▐ 31 Plus formellement, la structure d'un cube de données est la suivante [AGR96]: Chacune des d dimensions porte un nom Di. A chaque dimension Di est associe un domaine de valeur Domdi. Une référence de cellule est un n-uple < v1,v2,...,vd> appartenant à DomD1X DomD2X….DomDd. Le contenu d'une cellule d'un cube est soit la constante 0, soit la constante 1, soit un n-uple < v'1,v'2,...,v'k> appartenant a DomD'1X DomD'2X….DomD'k On dit encore que v1,v2,...,vd sont les dimensions membres et que v'1,v'2,...,v'k sont les dimension mesures. Un cube C de d dimensions est une fonction FC associant à chaque cellule de coordonnées l'un des éléments suivants: - La constante 0 si la cellule de référence < v1,v2,...,vd> n'existe pas pour C. - La constante 1 si la cellule de référence < v1,v2,...,vd> existe mais ne contient pas de mesure; - Un n-uple < v'1,v'2,...,v'k> si la cellule de coordonnées < v1,v2,...,vd> contient < v'1,v'2,...,v'k>. Pour illustrer les opérations liées à la structure multidimensionnelle (Pivot, swith, Slice, Dice), et Opérations liées à la granularités (Roll-up, et Drill-down) nous utilisons l’exemple Suivant : Produit Région Vente Période: 97 Produit Région Vente Période: 98 Produit Région Vente Période: 99 P1 Centre 15 P1 Centre 34 P1 Centre 33 P2 Centre 24 P2 Centre 25 P2 Centre 15 P3 Centre 43 P3 Centre 37 P3 Centre 26 P2 Est 54 P1 Est 41 P2 Est 21 P3 Est 59 P3 Est 26 P3 Est 35 P1 Sud 23 P1 Sud 43 P1 Sud 12 P3 Sud 34 P3 Sud 44 P3 Sud 19 Tableau 3 les Données d’une activité de Vente PARTIE III: LES CONCEPTS DE BASE DE LA MODELISATION▐ 32 III.1.1.1.1. Opérations liées à la structure : Les opérations agissant sur cette structure multidimensionnelle de l'information sont motivées par l'aspect interactif de l'analyse en ligne de données, et le souci d'offrir des possibilités d'animation de la représentation. De plus, elles illustrent l'importante des liens entre la manipulation des données et la représentation du cube à l'écran. Ces opérations sont regroupées sous le nom de restructuration. Tout cube obtenu par une opération de restructuration d'un cube initial contient tout ce qu'il faut pour régénérer le cube initial par restructuration réciproque. Ces opérations sont [BEL00] : - Slicing : Cette opération consiste en général à filtrer une dimension selon une valeur ou une plage de valeurs afin de se concentrer sur une partie de données, exemple : Slice (1998) : on ne retient que la partie du cube qui correspond à cette période. Figure N° 6 : L’opération SLICE sur un Cube 1997 1999 1998 SLICE(1998) P3 P2 P1 Année 1998 P1 P2 P3 Centre 34 25 37 Est 41 0 26 Sud 43 0 44 15 23 0 43 33 34 0 12 41 0 54 24 34 59 43 44 0 19 0 SLICE Centre Est Sud PARTIE III: LES CONCEPTS DE BASE DE LA MODELISATION▐ 33 - Dicing : Cette opération consiste à l’extraction d’un sous cube. Figure N° 7 : L’opération DICE sur un Cube - Pivot : Cette opération consiste à faire effectuer à un cube une rotation autour d'un des trois axes passant par le centre de deux faces opposées, de manière à présenter un ensemble de faces différent. Figure N° 8 : L’opération PIVOT sur un Cube 1997 1999 1998 P3 P2 P1 15 33 34 0 23 0 43 12 41 15 25 24 26 37 43 44 0 19 0 1997 1998 1999 P3 P2 P1 15 23 0 43 33 34 0 12 41 0 54 24 34 59 43 44 0 19 0 Centre Est Sud Centre Sud Est Pivot au tour de l’axe Dimension Produit 1997 1999 1998 P2 P1 15 23 0 43 33 34 0 12 41 0 54 24 34 59 43 44 0 19 0 DICE 54 0 0 23 43 0 41 Est Sud P3 P2 P1 1997 1998 Centre Est Sud PARTIE III: LES CONCEPTS DE BASE DE LA MODELISATION▐ 34 - Switch : Cette opération consister à interchanger la position des membres d'une dimension. Figure N° 9 : L’opération SWITCH sur un Cube III.1.1.1. Opérations liées à la granularités: Le deuxième aspect de la vision de l'analyse est de hiérarchiser l'information en différents niveaux de détail appelés niveaux de granularité. Les opérations permettant la hiérarchisation sont [BEL00] : Roll-up et drill-down. Ces deux opérations autorisent l'analyse de données à différents niveaux d'agrégations en utilisant des hiérarchies associées à chaque dimension. - Roll-up: Cette opération effectue l'agrégation des mesures en allant d'un niveau particulier de la hiérarchie vers un niveau général. 1997 1999 1998 P3 P2 P1 15 23 0 43 33 34 0 12 41 0 54 24 34 59 43 44 0 19 0 Centre Est Sud Switch entre les membres 1997 et 1999 de la Dimension Période P3 P2 P1 15 23 0 43 33 34 0 12 41 0 21 15 19 35 26 44 0 34 0 Centre Est Sud 1999 1997 1998 PARTIE III: LES CONCEPTS DE BASE DE LA MODELISATION▐ 35 Figure N° 10 : L’opération ROULL-UP sur un Cube - Drill-down: Elle consiste à représenter les données d'un cube à un niveau inférieur, et donc sous une forme détaillée. Elle peut être vue comme l'opération réciproque du Roll-up. Figure N° 11 : L’opération DRILL-DOWN sur un Cube 1997 1999 1998 P3 P2 P1 Alger Blida Batna Mila El Oued Biskra 7 8 0 0 13 10 9 25 21 20 26 17 13 10 2 0 10 0 10 14 24 30 0 0 23 20 19 40 12 22 9 7 O O Drill-down sur le Niveau Région 1997 1999 1998 P3 P2 P1 Centre Est Sud 15 23 0 43 33 34 0 12 41 0 54 24 34 59 43 44 0 19 0 Roull-Up Sur Toute la Période P3 P2 P1 82 106 120 97 78 64 75 0 41 Centre Est Sud PARTIE III: LES CONCEPTS DE BASE DE LA MODELISATION▐ 36 III.1.1.2. Concept de Faits: Le fait modélise le sujet de l'analyse. Un fait est formé de mesures correspondant aux informations de l'activité analysée [TEST00]. Figure N° 12 : Schéma d’un Fait Les mesures d'un fait sont numériques et généralement valorisées de manière continue [KIM96]. Les mesures sont numériques pour permettre de résumer un grand nombre d'enregistrements en quelques enregistrements (on peut les additionner, les dénombrer ou bien calculer le minimum, le maximum ou la moyenne). Les mesures sont valorisées de façon continue car il est important de ne pas valoriser le fait avec des valeurs nulles. Elles sont aussi souvent : • Additives : C'est-à-dire que l’opérateur d’agrégation (représenté par SUM) peut être appliqué pour regrouper les valeurs des mesures au cours de tous les dimensions (exemple : Quantités vendus, Chiffre d’affaire ….). • Semi-additives : Additives selon quelques dimensions (exemple : Nombre de transactions d’un client). • Non-additives : C'est-à-dire que l’opérateur d’agrégation (représenté par SUM) n’est pas applicable sur aucune dimension (exemple : un ratio de gestion). VENTE Quantite Montant Mesures PARTIE III: LES CONCEPTS DE BASE DE LA MODELISATION▐ 37 III.1.1.2. Concept de Dimension: Le sujet analysé, c'est à dire le fait, est analysé suivant différentes perspectives. Ces perspectives correspondent à une catégorie utilisée pour caractériser les mesures d'activité analysées [MAR98], on parle de dimensions. Une dimension modélise une perspective de l'analyse. Une dimension se compose de paramètres correspondant aux informations faisant varier les mesures de l'activité. Les dimensions servent à enregistrer les valeurs pour lesquelles sont analysées les mesures de l'activité. Une dimension est généralement formée de paramètres (ou attributs) textuels et discrets. Les paramètres textuels sont utilisés pour restreindre la portée des requêtes afin de limiter la taille des réponses. Les paramètres sont discrets, c'est à dire que les valeurs possibles sont bien déterminées et sont des descripteurs constants. Figure N°13 : Exemple des dimensions d'un Fait Temps GeographieCategorie TypeProd Gamme NomProd Couleur Region Departement Ville Annee Trimestre Saison Mois Paramètres Dimensions PARTIE III: LES CONCEPTS DE BASE DE LA MODELISATION▐ 38 III.1.1.4. Concept d'hiérarchie Une hiérarchie organise les paramètres d'une dimension selon une relation "est_plus_fin" conformément à leur niveau de détail [TEST00]. On distingue deux types d'hiérarchies Simple et Multiple: Figure N°14 : Différents Types d'hiérarchies III.1.2. Schémas Multidimensionnels: D'une manière très générale, le modèle dimensionnel possède une table de faits centrale et des tables de dimensions situées autour. Chaque enregistrement de la table de faits stocke les clés des tables de dimensions et les mesures faites à un instant précis. La taille de la table de faits est de plusieurs millions d'enregistrements, et peut nécessiter plusieurs giga, voire tera octets d'occupation sur disque [PROB01]. Pays Canton Ville Quartier Simple Forage vers le haut (Rolling-up) Forage vers le bas (Rolling-Down) Année Trimestre Semaine Saison Mois Date Multiple PARTIE III: LES CONCEPTS DE BASE DE LA MODELISATION▐ 39 III.1.2.1. Schéma en Etoile : A partir des faits et des dimensions, il est possible d'établir une structure de données simple qui correspond au besoin de la modélisation multidimensionnelle. Cette structure est constituée du fait central et des dimensions. Ce modèle représente visuellement une étoile, on parle de modèle en étoile [KIM96], [TEST00]. - La table des faits contient des mesures (par exemple le prix des produits vendus, la quantité de produits vendus) qui peut être agrégée de diverses façons. - Les tables de dimension fournissent la base pour l'agrégation des mesures de la table de fait. - La table de fait est liée avec toutes les tables de dimension par des relations "Un-à-Plusieurs". - La clef primaire de la table de fait est la concaténation des clefs primaires de toutes les tables de dimension. L'avantage d'employer les schémas en étoile pour représenter les données est la réduction du nombre de tables, et le nombre de relations entre ces tables et donc le nombre de jointures exigé dans les requêtes des utilisateurs [Kim96]. Figure N°15 : Schéma en Etoile Produit CodeProd Categorie NomProd Couleur Temps Numtemps Année Trimestre Saison Mois Jour Geographie NumGeo Region Departement Ville VENTE CodeProd NumGeo Numtemps Quantité Montant PARTIE III: LES CONCEPTS DE BASE DE LA MODELISATION▐ 40 III.1.2.2. Schéma en Flocon Dans une étoile, les dimensions sont dénormalisées : les hiérarchies d'agrégation sont implicites. Un flocon de neige est une étoile où les hiérarchies sont respectées et explicites. Un flocon peut être formé depuis une étoile en normalisant les dimensions. Le flocon diffère de l'étoile de par sa constitution : un flocon reste relativement normalisé alors qu'une étoile est dénormalisée [PROB01]. Une modélisation en flocon consiste à décomposer les dimensions du modèle en étoile en sous hiérarchies. La modélisation en flocon est donc une émanation de la modélisation en étoile, le fait est conservé et les dimensions sont éclatées conformément à sa hiérarchie des paramètres. PARTIE III: LES CONCEPTS DE BASE DE LA MODELISATION▐ 41 Figure N°16 : Schéma en Flocon de Neige Le modèle en Flocon est plus propre (3eme Forme Normale), la hiérarchie multiple est simplifiée et il offre un gain d'espace de stockage (même s'il est négligeable par rapport à la table de Fait). III.1.2.3. Schéma en Constellation : Le schéma en constellation consiste à placer plusieurs schémas en étoile avec des tables de faits reliées hiérarchiquement. Les liens entre les différentes tables de faits permettent de visionner les différents niveaux de détail Dim: Location IdLoc LocNom IdTypeLoc IdRegLoc Fait: Ventes DateVente DateEnvoi IdClient IdLoc totEscompt Dim: Clients IdClient ClientNom IdTypeClient IdRegClient Dim: Region IdRegion RegionNom IdEtat Dim: Etat IdEtat EtatNom Dim: TypeLocation IdTypeLoc NomTypeLoc Dim: TypeClient IdTypeClient NomTypeClient PARTIE III: LES CONCEPTS DE BASE DE LA MODELISATION▐ 42 [PROB01]. Donc ce schéma consiste à fusionner plusieurs modèles en étoile qui utilisent des dimensions Communes [TEST00]. Figure N°17 : Schéma en Constellation III.1.2.4. Schéma en Grappe: Ce schéma est apparu car il n'existe pas de schéma en étoile ou de schéma en flocon parfait. Le schéma en grappe est une dérivation de ces deux schémas pour en former un troisième. Kimball déclare qu'un schéma en flocon n'est pas optimal, car il est trop complexe. Toujours pour les mêmes raisons de simplifications des tables, afin de pouvoir trouver facilement les informations dans l'entrepôt, le schéma en grappe apparaît alors comme un compromis entre le schéma en étoile et le schéma en flocon. Produit CodeProd Categorie NomProd Couleur Temps Numtemps Année Trimestre Saison Mois Jour Geographie NumGeo Region Departement Ville VENTE CodeProd NumGeo Numtemps Quantité Montant Prescriptions NumGeo NumMed Numtemps NbMedicam Honoraires Medicament NumMed Categorie Molecules EffectSecond Posologie PARTIE III: LES CONCEPTS DE BASE DE LA MODELISATION▐ 43 Figure N°18 : Schéma en Grappe Si l'on prend la figure N°18, on remarque que les tables Location et Clients dépendent toutes deux des tables Région et Etat. De plus, Client dépend de TypeClient, et Location dépend de TypeLocation. La table des faits restant la table Ventes. Ainsi, par une agrégation des entités, le schéma en grappe permet de regrouper les tables TypeLocation dans la table Location, la table Etat dans la table Region, et la table TypeClient dans la table Client pour ne former que quatre tables. La figure n°18 donne un exemple d'un schéma en grappe [PROB01]. III.1.2.5. Complexité Vs Redondance Tous ces modèles sont des modèles dimensionnels, que l'on peut ou non implémenter lors de la création d'un entrepôt de données. Cependant, il faut savoir que ces modèles augmentent soit la complexité des tables, soit la redondance des données. Chaque cas est unique, et on doit bien réfléchir au schéma que l'on va adopter. La figure N°19 illustre le classement des modèles présentés en fonction de la complexité ou de la redondance des données. Dim: Location IdLoc LocNom IdTypeLoc NomTypeLoc IdRegLoc Fait: Ventes DateVente DateEnvoi IdClient IdLoc totEscompt Dim: Clients IdClient ClientNom IdTypeClient NomTypeClient IdRegClient Dim: Region IdRegion RegionNom IdEtat NomEtat PARTIE III: LES CONCEPTS DE BASE DE LA MODELISATION▐ 44 Figure N°19 : Complexité Vs Redondance III.1.2.6 Agrégations : L’utilisation de récapitulation préenregistrées (agrégats) est l’outils le plus efficace dont dispose le concepteur d’entrepôt de données pour améliorer les performances. Un agrégat est un enregistrement de table de faits représentant la récapitulation d’enregistrements élémentaires de cette table. Un enregistrement d’une table de faits agrégés est associé à un ou plusieurs enregistrements de tables de dimensions d’agrégats [KIM97]. III.1.3 Les implémentations des modèles multidimensionnels Selon la façon dont le cube de données est stocké, il existe deux approches fondamentales pour construire des systèmes basés sur un modèle multidimensionnel et une troisième Hybride. L'approche MOLAP (Multidimensionnel OLAP) implémente le cube de données dans un tableau multidimensionnel (multidimensionnelle array). Par contre, l'approche ROLAP (Relationnel OLAP) utilise un SGBD relationnel pour gérer et stocker le cube de données [BEL03]. PARTIE III: LES CONCEPTS DE BASE DE LA MODELISATION▐ 45 III.1.3.1 Les systèmes MOLAP Les systèmes de type MOLAP stockent les données dans un SGBD multidimensionnel sous la forme d'un tableau multidimensionnel (multidimensionnelle array). Chaque dimension de ce tableau est associée à une dimension du cube. Seules les valeurs de données correspondant aux données de chaque cellule sont stockées. Ces systèmes demandent un pré calcul de toutes les agrégations possibles. En conséquence, ils sont plus performants que les systèmes traditionnels, mais difficiles à mettre à jour et à gérer [BEL03]. Les systèmes MOLAP apparaissent comme une solution acceptable pour le stockage et l'analyse d'un entrepôt lorsque la quantité estimée des données d'un entrepôt ne dépasse pas quelques gigaoctets et lorsque Le modèle multidimensionnel évolue peu. Mais, lorsque les données sont éparses, ces systèmes sont consommateurs d'espace [CHA97] et des techniques de compression doivent être utilisées. III.1.3.2 Les systèmes ROLAP Les systèmes de type ROLAP utilisent un SGBD relationnel pour stocker les données de l'entrepôt. Ils représentent une interface multidimensionnelle pour le SGBD relationnel. Le moteur OLAP est un élément supplémentaire qui fournit une vision multidimensionnelle de l'entrepôt, des calculs de données dérivées et des agrégations à différents niveaux. Il est aussi responsable de la génération des requêtes SQL mieux adaptées au schéma relationnel. Les mesures (par exemple les quantités vendues) sont stockées dans une table qu'on appelle la table des faits. Pour chaque dimension du modèle multidimensionnel, il existe une table qu'on appelle la table de dimension (comme Produit, Temps, Client) avec tous les niveaux d'agrégation et les propriétés de chaque niveau [BEL03]. PARTIE III: LES CONCEPTS DE BASE DE LA MODELISATION▐ 46 Ces systèmes peuvent stocker de grands volumes de données, mais ils peuvent présenter un temps de réponse élevé. Les principaux avantages de ces systèmes sont : 1- Une facilité d'intégration dans les SGBDs relationnels existants. 2- Une bonne efficacité pour stocker les données multidimensionnelles. Les exemples de produits de cette famille sont DSS Agent de MicroStrategy et MetaCube d'Informix. III.1.3.3 Les systèmes HOLAP Les données des cubes sont stockées dans une structure relationnelle et les agrégats dans une structure multidimensionnelle. L’utilisateur formule une requête sur la base de données relationnelle et le résultat s’affiche sous une forme multidimensionnelle. La convivialité et ainsi respecté tout en permettant le stockage de grand volume de données. PARTIE IV : LES APPROCHES DE CONCEPTION MULTIDIMENSIONNELLE▐ 47 PARTIE IV: LES APPROCHES DE CONCEPTION MULTIDIMENSIONNELLE IV.1- Conception d'un schéma conceptuel selon l'approche KIMBALL [KIM97] Considérée comme étant la référence dans le monde de la conception des entrepôts de données la méthode de conception d'une base de données multidimensionnelles suivant la démarche KIMBALL est abordée d'une manière systématique, en envisageant quatre étapes dans un ordre bien défini. • Première étape o Choisir le processus d'activité à modéliser. Un processus d'activité est un processus opérationnel important pour l'organisation, étaye par une application existante à partir de laquelle des données peuvent être collectées au profit de l'entrepôt de données. Exemples de processus d'activité : Facturation, Ventes…. • Deuxième étape o Choisir le Grain du processus d'activité. Le Grain est le niveau de détail fondamental, atomique, des données figurant dans la table des faits pour ce processus. Des grains typiques sont des transactions individuelles, des récapitulations individuelles quotidiennes. • Troisième étape o Choisir les dimensions applicables a chaque enregistrement de la table de faits. Des dimensions typiques sont le temps, le produit, le magasin, le client. Le choix d'une dimension s'accompagne de la définition de tous les attributs textuels qui garniront la table de dimension • Quatrième étape o Choisir les faits mesures que contiendra chaque enregistrement de la table de faits. Des faits mesures typiques sont des quantités numériques additives. PARTIE IV : LES APPROCHES DE CONCEPTION MULTIDIMENSIONNELLE▐ 48 Sachant qu'aucune méthode automatique ou semi-automatique n'est envisagée, mais KIMBALL se base sur une approche intuitive. La construction d'un entrepôt de donnée multidimensionnel selon KIMBALL revient à faire correspondre les besoins de la communauté utilisateurs avec la réalité des informations disponibles. Les neuf décisions majeures qui jalonnent la conception de la base de données sont toutes subordonnées aux besoins des utilisateurs et aux réalités que représentent les données. IV.2- Les neuf décisions Les neuf décisions à prendre pour la conception complète d'un entrepôt de données dimensionnel portent sur les points suivants: 1. Les processus, et partant, l'identité des tables de faits. 2. Le grain de chaque table de fait. 3. Les dimensions de chaque table de faits. 4. Les faits, y compris les faits précalculés. 5. Les attributs des dimensions, avec des descriptions complètes et la terminologie adéquate. 6. Comment suivre les dimensions à évolution lente. 7. Les agrégats, les dimensions hétérogènes, les minidimensions, les modes de requêtes et autres décisions sur le stockage physique. 8. L'étendue historique de la base de données. 9. L'urgence avec laquelle les données doivent être extraites et chargées dans l'entrepôt de données. Cette méthodologie est une méthodologie descendante, qui commence par identifier les processus majeurs de l'entreprise dans la quelle les informations sont collectées. Car les concepteurs d'entrepôt de donnée d'après KIMBALL doivent commencer avec des sources des données existantes et réellement PARTIE IV : LES APPROCHES DE CONCEPTION MULTIDIMENSIONNELLE▐ 49 utilisées, pour éviter de perdre du temps en rêvant à des sources d'information qui n'existent pas. Une fois les processus identifies, une ou plusieurs tables de faits sont construites à partir de chacun des processus choisis. Avant de pouvoir concevoir en détail une table de faits, une décision doit être prise sur la signification précise d'un enregistrement de plus bas niveau dans la table de faits. Cette signification est le grain de la table de faits. Lorsque le grain de la table de faits est connu, les dimensions et leurs grains respectifs peuvent être identifiés. Il y aura des dimensions supplémentaires qui ne seront pas strictement requises pour décider du grain de la table de faits. Le choix des dimensions est le point clé de la conception, une fois les dimensions choisies, il faut définir toutes les mesures de la table de faits, on peut ensuite définir complètement le contenu des enregistrements de dimension. A ce stade la conception de la structure logique principale est terminée, et nous pouvons porter notre attention sur les aspects les plus généraux de la structure physique. Ces aspects incluent la manière à suivre les dimensions à évolution lente, l’inclusion d’agrégats, les dimensions hétérogènes, les minidimensions et le mode de requêtes. IV.2. Conception d'un schéma conceptuel selon l'approche M. Kortink et D.L.Moody IV.2.1. Introduction: D'après [Kor00], on peut arriver à un modèle dimensionnel en partant du modèle d'entreprise s'il existe. Ils donnent une méthode de conception basée sur un modèle existant. Ils proposent de définir le modèle de l'entrepôt de données à partir du modèle d'entreprise, dont la mise en place est en général très onéreuse. PARTIE IV : LES APPROCHES DE CONCEPTION MULTIDIMENSIONNELLE▐ 50 IV.2.2. Phase 01: Classification des entités La première étape pour créer un modèle multidimensionnel à partir du modèle l'entreprise est de classer ses entités. Elles se décomposent en trois catégories IV.2.2.1 Entité de transaction : Elles enregistrent les détails d'événements particuliers comme les salaires, les réservations d'hôtels. Ce sont ces événements, entre autres, que les décideurs veulent analyser. Les caractéristiques des entités de transaction sont : 1°) Elles décrivent un événement qui se produit à un instant donné. 2°) Elles contiennent les mesures, comme le montant, le poids, les volumes. Ces mesures forment la base des résultats que l'entrepôt permet d'étudier. Periode Date Mois Quart Année Année_Fisc Vente NumVent DateVente DatePoster CodeClient CodeLoc EscomptMnt Location CodeLoc NomLoc CodeRegLoc CodeTypeLoc TypeLocation CodeTypeLoc NomTypeLoc Ville CodeVille NomVille Région CodeRégion NomRégion CodeVille TypeClient CodeTypeClient NomTypeClient Client CodeClient NomClient CodeTypeClient CodeRégionClient DétailVente NumVent CodeArticle Qte Tarif_Unité Article CodeArticle NomArticle CodeTypeArt TypeArticle CodeTypArt NomTypeArt PrixVente NumVent CodeTypePrix Prix TypePrix CodeTypePrix NomTypePrix Vente Poster Figure N°20 : Exemple de Modèle de donnée PARTIE IV : LES APPROCHES DE CONCEPTION MULTIDIMENSIONNELLE▐ 51 Les entités de transaction forment le noyau à partir duquel la table des faits d'un schéma en étoile peut être créée. Toutes les entités de transaction ne sont pas bonnes pour l'aide à la décision, et l'on doit choisir et identifier les plus intéressantes. IV.2.2.2 Entité Composante : Elle est directement liée à l'entité de transaction par une relation (un à plusieurs). Ces entités définissent la finesse des détails ou composants de chaque transaction. Les composants répondent aux questions Qui, Quoi, Où, Quand, Combien, Pourquoi, d'un événement business (commercial): - Client : Qui a fait l'achat. - Produit : ce qui a été vendu, le Quoi. - Emplacement : Où il a été vendu. - Période : Quand il a été vendu. Les entités composantes forment la base des tables de dimension dans les schémas en étoile. Chaque table de dimension correspond à une ou plusieurs entités composantes. IV.2.2.3 Entité de classification : Ce sont des entités qui sont apparentées à des entités composantes par une chaîne de relations (un à plusieurs). Ces entités représentent la hiérarchie entre les entités dans le schéma en étoile. PARTIE IV : LES APPROCHES DE CONCEPTION MULTIDIMENSIONNELLE▐ 52 Les entités en noir représentent les entités de transaction. Les entités en gris représentent les entités composantes. Les entités en blanc représentent les entités de classification. IV.2.2.4 Ambiguïtés : Parfois, des entités sont présentes dans plusieurs catégories. Les auteurs définissent la priorité des hiérarchies comme suit : 1°) Transaction : la plus haute. 2°) Classification : La Moyenne. 3°) Composante : la plus basse. Période Vente Location TypeLocation Ville Région TypeClient Client DétailVente Article TypeArticle PrixVente TypePrix Vente Poster Figure N°21 : Classification des entités PARTIE IV : LES APPROCHES DE CONCEPTION MULTIDIMENSIONNELLE▐ 53 IV.2.3. Phase 02 : Identification des hiérarchies La hiérarchie est un concept extrêmement important dans le modèle multidimensionnel, car c'est par la hiérarchie que l'on va pouvoir passer du modèle relationnel au modèle multidimensionnel. Une hiérarchie est un modèle d'entité-association qui est identifié par des séquences d'entités reliées par des relations (un à plusieurs), toutes alignées dans le même sens. Nous parlons alors d'un schéma normalisé. Hiérarchie maximale Une hiérarchie est maximale si l'on ne peut l'étendre vers le haut ou vers le bas en ajoutant de nouvelles entités. Une entité est dite minimale si elle est placée au bas d'une hiérarchie maximale. Une entité est dite maximale si elle est située au plus haut de la hiérarchie. Dans l'exemple de la figure N°21, il y a deux entités minimales, DétailVente et PrixVente, alors qu'il y a six entités maximales : Periode, TypeClient, Ville, Type Location, TypeArticle et TypePrix. Les entités minimales sont facilement identifiables car ce sont des entités qui n'ont pas de relations (un à plusieurs) ou Entités "feuille" dans la terminologie hiérarchique. A l'inverse, les entités maximales se décrivent par des entités qui n'ont pas de relations monovaluées (plusieurs à un) ou Entités "Racine" dans terminologie hiérarchique. IV.2.4 Phase 03: Production du Modèle multidimensionnel IV.2.4.1. Opérateur 01: Réduction de la hiérarchie Des entités de rang supérieur peuvent être concaténées à des entités inférieures en respectant la hiérarchie. Ainsi, l'attribut NomVille peut être mis dans la table Région. Cela introduit une redondance et forme une dépendance transitive, ce qui viole la troisième forme normale de [COD70]. On introduit alors le concept de base dénormalisée. On peut aller plus loin, en concaténant les PARTIE IV : LES APPROCHES DE CONCEPTION MULTIDIMENSIONNELLE▐ 54 attributs NomRégion, CodeVille et NomVille à l'entité Location. Il faut alors continuer dans le même sens pour se retrouver avec une seule table, la table DétailVente qui contient la concaténation de tous les attributs des autres tables. IV.2.4.2. Opérateur 02: L'agrégation une fonction des entités de transaction Une agrégation peut être appliquée à une entité de transaction pour former une nouvelle entité de transaction, constituée d'une synthèse de données. Cette fonction n'est possible qu'avec des attributs numériques, afin de faire ressortir des champs calculés, par exemple. La clé de cette nouvelle entité est une combinaison des attributs utilisés par l'agrégation. Attention, l'agrégation perd des informations, et l'on ne peut reconstruire les détails de la table DétailVente depuis la table Récap_Article, comme la montre la figure n°22 ci-dessous. Il y a un large choix d'options pour la production des Modèles multidimensionnels à partir d'un modèle Entité Relation, et qui incluent : √ Schéma Plat (Flat) √ Schéma En terrasses (Terrace) √ Schéma d'étoile (Star) √ Schéma de Flocon de neige (Snowflake) √ Schéma en grappe (Star Cluster) DétailVente NumVente CodeArt Date Qte Unité_Tarif Récap_Article CodeArt Date Total_Ventes Qte_ Moy Tarif_Moy Figure N°22 : Agrégation d’entité PARTIE IV : LES APPROCHES DE CONCEPTION MULTIDIMENSIONNELLE▐ 55 Chacune de ces différentes options représente le compromis entre la complexité et la redondance. Ici nous récapitulons comment les opérateurs précédemment définis peuvent être employés pour Produire des différents modèles multidimensionnels (.Schéma d'étoile, Schéma de Flocon de neige (Snowflake), Schéma en grappe (Star Cluster)) Option : 01 Le schéma à plat : Ce schéma est le plus simple à réaliser sans perte de données. Il est formé par agrégation des entités dans le modèle de données vers une entité minimale. Cela minimalise le nombre de tables dans la base de données, mais sans perdre aucune information du modèle original, comme la montre la figure N°23. PARTIE IV : LES APPROCHES DE CONCEPTION MULTIDIMENSIONNELLE▐ 56 Le problème de ce type de schéma est qu'il peut engendrer des erreurs lorsqu'il existe une relation entre les entités de transaction. Lorsque l'on agrège les montants numériques d'une entité de transaction vers une autre, cet agrégat est alors répété. Dans l'exemple de la figure n°23, si une vente contient trois articles de Ventes, le montant des ventes sera répété dans trois DétailVente NNuummVVeennttee CCooddeeAArrtt Qte Value NomArt CodeTypeArt NomTypeArt DateVente MoisVente QuatVente AnnéeVente AnnéeFiscVente DatePoster MoisPoster QuatPoster AnnéePoster AnnéeFiscPoster Discount CodeClient NomClient CodeTypeClient NomTypeClient CodeRégionClient NomRégionClient CodeVilleClient NomVilleClient CodeLoc NomLoc CodeTypeLoc NomTypeLoc CodeRégionLoc NomRégionLoc CodeVilleLoc NomVilleLoc Figure N°23 : Schéma à Plat PrixVente NNuummVVeennttee CCooddeeTTyyppeePPrriixx Prix NomTypePrix DateVente MoisVente QuatVente AnnéeVente AnnéeFiscVente DatePoster MoisPoster QuatPoster AnnéePoster AnnéeFiscPoster Discount CodeClient NomClient CodeTypeClient NomTypeClient CodeRégionClient NomRégionClient CodeVilleClient NomVilleClient CodeLoc NomLoc CodeTypeLoc NomTypeLoc CodeRégionLoc NomRégionLoc CodeVilleLoc NomVilleLoc PARTIE IV : LES APPROCHES DE CONCEPTION MULTIDIMENSIONNELLE▐ 57 enregistrements différents dans la table DétailVente. Ainsi, ces ajouts engendrent deux, voire trois, comptages. Un autre problème de ce schéma est qu'il propose un grand nombre d'attributs dans les tables, ce qui ne facilite pas la lecture et la compréhension. Lorsque le nombre de tables est minimal, la complexité de chaque table s'accroît. Option 02 : Le schéma en terrasse : Ce schéma est créé à partir d'une agrégation d'entités en dessous d'entités maximales, ainsi l'on s'arrête lorsque l'on rencontre une entité de transaction. Il en résulte une table pour chaque entité de transaction dans le modèle de données. Ce schéma n'est pas très apprécié car il peut poser des problèmes de compréhension aux utilisateurs non avertis, dus à la séparation entre les niveaux de transaction. PARTIE IV : LES APPROCHES DE CONCEPTION MULTIDIMENSIONNELLE▐ 58 Option 03 : Le schéma en étoile: Un schéma en étoile peut être facilement tiré d'un modèle entité -relation. Chaque schéma en étoile est construit comme suit: - Une table de fait est formée pour chaque entité de transaction. La clef de la table est la combinaison des clefs de ses entités associées composantes. - Une table de dimension est formée pour chaque entité de composante, par réduction de la hiérarchie liée aux entités de classification dans cette entité composante. DétailVente NNuummVVeennttee CCooddeeAArrtt Qte Value NomArt CodeTypeArt NomTypeArt Figure N°24: Le schéma en terrasse PrixVente NNuummVVeennttee CCooddeeTTyyppeePPrriixx Prix NomTypePrix Vente NNuummVVeennttee DateVente MoisVente QuatVente AnnéeVente AnnéeFiscVente DatePoster MoisPoster QuatPoster AnnéePoster AnnéeFiscPoster Discount CodeClient NomClient CodeTypeClient NomTypeClient CodeRégionClient NomRégionClient CodeVilleClient NomVilleClient CodeLoc NomLoc CodeTypeLoc NomTypeLoc CodeRégionLoc NomRégionLoc CodeVilleLoc NomVilleLoc PARTIE IV : LES APPROCHES DE CONCEPTION MULTIDIMENSIONNELLE▐ 59 - Quand des relations hiérarchiques existent entre des entités de transaction, l'entité d'enfant hérite toutes les dimensions (et clefs d'attributs) de l'entité parentale. Cela fournit la capacité de " Drill Down " entre les niveaux de transaction - Attributs numériques dans entités de transaction doit être agrégé par des attributs clefs (des dimensions). Figure N°25 : Le schéma en étoile pour les Ventes Periode DDaattee Mois Quart Année AnnéeFisc Location CCooddeeLLoocc NNoommLLoocc CodeTypeLoc NomTypeLoc CodeRégionLoc NomRégion CodeVille NomVille Vente DateVente DatePoster CodeClient CodeLoc Sum(EscomptMnt) Client CCooddeeCClliieenntt NNoommCClliieenntt CodeTypeClient NomTypeClient CodeRégionClient NomRégion CodeVille NomVille Vente Poster PARTIE IV : LES APPROCHES DE CONCEPTION MULTIDIMENSIONNELLE▐ 60 Schéma en Constellation: Au lieu de quelques schémas d'étoile discrets, le modèle de données peut être transformé dans un schéma en constellation. Un schéma de constellation consiste en un ensemble de schémas d'étoile avec des tables de fait hiérarchiquement liées. Les liaisons entre les diverses tables de fait fournissent la Capacité de " Drill Down " (forer en bas) entre les niveaux de détail (exemple. De Vente vers DétailVente). Figure N°26 : Le schéma en étoile pour Le Détail des Ventes Periode DDaattee Mois Quart Année AnnéeFisc Location CCooddeeLLoocc NNoommLLoocc CodeTypeLoc NomTypeLoc CodeRégionLoc NomRégion CodeVille NomVille DétailVente DateVente DatePoster CodeClient CodeLoc CodeArt Sum(Qte) SunPrixDétail Client CCooddeeCClliieenntt NNoommCClliieenntt CodeTypeClient NomTypeClient CodeRégionClient NomRégion CodeVille NomVille Vente Poster Article CCooddeeAArrtt NNoommAArrtt CodeTypeArt NomTypeArt PARTIE IV : LES APPROCHES DE CONCEPTION MULTIDIMENSIONNELLE▐ 61 Schéma de Galaxie Plus généralement, un ensemble de schémas d'étoile ou constellations Peuvent être combinés ensemble pour former une galaxie. A La galaxie a d'une collection de schémas d'étoile avec des dimensions partagées, a la différence d'un schéma en constellation, les tables de fait dans une galaxie ne doivent pas être directement liées. Figure N°27: Le schéma en Constellation pour les Ventes Periode DDaattee Mois Quart Année AnnéeFisc Location CCooddeeLLoocc NNoommLLoocc CodeTypeLoc NomTypeLoc CodeRégionLoc NomRégion CodeVille NomVille Vente DateVente DatePoster CodeClient CodeLoc Sum(EscomptMnt) Client CCooddeeCClliieenntt NNoommCClliieenntt CodeTypeClient NomTypeClient CodeRégionClient NomRégion CodeVille NomVille Vente Poster DétailVente DateVente DatePoster CodeClient CodeLoc CodeArt Sum(Qte) SunPrixDétail Article CCooddeeAArrtt NNoommAArrtt CodeTypeArt NomTypeArt PrixVente DDaatteeVVeennttee DDaatteePPoosstteerr CodeClient CodeLoc CodeTypePrix SumPrix TypePrix CCooddeeTTyyppeePPrriixx NNoommTTyyppeePPrriixx NomTypeArt PARTIE IV : LES APPROCHES DE CONCEPTION MULTIDIMENSIONNELLE▐ 62 Option 04 : Le schéma en Flocon de neige: Le schéma en flocon de neige peut être formé d'un schéma d'étoile en étendant des hiérarchies dans chaque dimension (la normalisation). Alternativement, un schéma de flocon de neige peut être Produit directement d'un modèle de Entité Relation Selon la procédure suivante : - Une table de fait est formée pour chaque entité de transaction. La clef de la table est la combinaison des clefs de ses entités associées composantes. - Chaque entité composante devient une table de dimension. - Quand des relations hiérarchiques existent entre des entités de transaction, l'entité d'enfant hérite toutes les dimensions (et clefs d'attributs) de l'entité parentale. Cela fournit la capacité de " Drill Down " entre les niveaux de transaction - Attributs numériques dans entités de transaction doit être agrégé par des attributs clefs (des dimensions). PARTIE IV : LES APPROCHES DE CONCEPTION MULTIDIMENSIONNELLE▐ 63 Option 05 : Le schéma en groupe d'étoiles: Le problème de chevauchement sur des dimensions peut être identifié via "Fourchettes" dans les hiérarchies. Une fourchette arrive quand une entité se présente comme "un parent" dans deux hiérarchies dimensionnelles différentes Cela aboutit à l'effondrement de l'entité et tous ses ancêtres dans deux tables de dimension séparées. Les entités de fourchette peuvent être identifiées comme des entités de classification avec des relations multiples (un à plusieurs). Dans l'exemple du modèle de données, une fourchette arrive à l'entité Région. La région est un parent de : l'emplacement et le Client, Qui sont tous des composants de la transaction Vente. Periode DDaattee Mois Quart Année AnnéeFisc Location CCooddeeLLoocc NNoommLLoocc CodeTypeLoc NomTypeLoc CodeRégionLoc Vente DateVente DatePoster CodeClient CodeLoc Sum(EscomptMnt) Client CCooddeeCClliieenntt NNoommCClliieenntt CodeTypeClient NomTypeClient CodeRégionClient Vente Poster TypeLocation CCooddeeTTyyppeeLLoocc NNoommTTyyppeeLLoocc Figure N°28 : Le schéma en Flocon de Neige pour les Ventes Ville CCooddeeVViillllee NNoommVViillllee TypeClient CCooddeeTTyyppeeCClliieenntt NNoommTTyyppeeCClliieenntt Région CCooddeeRRééggiioonn NNoommRRééggiioonn CodeVille PAR