Ministère de l Enseignement Supérieur et de la Recherche Scientifique Ecole nationale Supérieure d Informatique (E.S.I) Oued-Smar Alger.

Transcription

1 Ministère de l Enseignement Supérieur et de la Recherche Scientifique Ecole nationale Supérieure d Informatique (E.S.I) Oued-Smar Alger École Doctorale Sciences et Technologies de l'information et de la Communication Mémoire Pour l obtention du diplôme de magistère Option : Systèmes d Informations et de Connaissances (SIC) Présenté par Selma KHOURI Modélisation conceptuelle à base ontologique d un entrepôt de données Soutenue devant le jury : Thouraya TEBIBEL Maître de Conférences à l'esi Présidente Walid HIDOUCI Maître de Conférences à l'esi Rapporteur Réda GHOMARI Maître de Conférences à l'esi Rapporteur Ladjel BELLATRECHE Maître de Conférences à l'université de Poitiers Directeur de mémoire ANNEE UNIVERSITAIRE 2008/2009

2 Remerciements Je tiens à adresser mes sincères remerciements à monsieur Ladjel Bellatreche, pour avoir encadré mon travail de magistère. Je le remercie vivement pour son entière disponibilité, sa rigueur, et tous ses conseils avisés. Je tiens également à remercier monsieur Yamine Ait-Amer, directeur du laboratoire LISI, pour m avoir accueillie au sein de son laboratoire pour un stage de trois mois, et pour avoir fait que ce stage se passe dans d excellentes conditions. Je remercie vivement les membres du jury qui m ont fait l honneur d accepter de juger mon travail. Je remercie Mesadames Thouraya Tebibel et Nacira Cherid, pour leur disponibilité et leur aide. Je remercie Chimène Fankam, pour son aide et ses conseils. Je remercie tous les membres du LISI, qui ont fait que mon stage soit aussi agréable, particulièrement Nacima, Linda, Chedlia, Ahmed, Idir, Salem. Je n oublie pas de remercier mes amies Zakia, Yasmine, Soumia, Dalal et Amel pour m avoir encouragé tout au long de ce travail. Merci à tous ceux qui ont contribué, de près ou de loin, à l aboutissement de ce travail.

3 Résumé Concevoir un entrepôt de données est reconnu actuellement comme une tâche cruciale sur laquelle peut reposer la réussite d un projet d entreposage. L étude des approches de développement d un entrepôt de données nous a permis de soulever le constat suivant : un entrepôt de données, dans sa construction, peut être assimilé à un système d intégration matérialisé par des concepts multidimensionnels. Différentes approches d intégration ont conclu sur l utilisation des ontologies pour assurer une intégration sémantique des données de manière automatique. Les ontologies apportent de plus, des avantages très intéressants pour la spécification d un modèle conceptuel. Nous proposons dans cette étude une méthode de conception d un entrepôt de données à base ontologique. Une seule méthode de conception à base ontologique a été proposée dans la littérature, et prend en compte uniquement les sources de données. Nous proposons une méthode reposant sur une ontologie intégrant les différentes sources de données alimentant l entrepôt à développer, sur laquelle on exprime un ensemble de besoins décisionnels. Les sources et les besoins sont exprimés au niveau ontologique (sémantique), ce qui permet d obtenir un modèle multidimensionnel de l entrepôt contenant la sémantique des données qu il représente. Nous proposons également un outil validant cette méthode. Mots clés: Entrepôt de données, modélisation conceptuelle, ontologie, intégration, outil de génie logiciel.

4 Abstract Designing a data warehouse (DW) is currently recognized as a critical task contributing to the success of a DW project. The study of the different DW development approaches leads us to the following observations: a data warehouse can be assimilated to an integration system materialized by multi-dimensional concepts. Different integration approaches have used ontologies to assure a semantic and automatic integration of data. Besides, ontologies provide interesting advantages for the specification of a conceptual model. We propose in this study a method for a conceptually designing a DW based on ontologies. Only one ontological design method has been proposed in the literature, which considers only data sources. We propose a method based on an ontology integrating different data sources, on which we express a set of decisional requirements. Sources and requirements are expressed in an ontological (semantic) way, and provide a multidimensional DW model containing the semantics of the data it represents. We also present a tool validating the proposed method. Key words: data warehouse, conceptual design, ontology, integration, software engineering tool.

5 Sommaire CHAPITRE INTRODUCTION GÉNÉRALE CONTRIBUTION DU MEMOIRE ORGANISATION DU MEMOIRE CHAPITRE LES ENTREPÔTS DE DONNÉES DEFINITION D UN ENTREPOT DE DONNEES BASE DE DONNEES VS ENTREPOT DE DONNEES ARCHITECTURE D UN ENTREPOT DE DONNEES LA MODELISATION D UN ED LES IMPLEMENTATIONS D UN CUBE MULTIDIMENSIONNEL L approche MOLAP L approche ROLAP Le schéma en étoile Le schéma en flocon de neige Le schéma en constellation L approche HOLAP CYCLE DE VIE D UN ENTREPOT DE DONNEES Conception d un entrepôt de données Analyse des besoins Modélisation conceptuelle Modélisation logique Processus ETL (Extract-Transform-Load) Modélisation physique CONCLUSION CHAPITRE APPROCHES DE CONCEPTION DES PROJETS D ENTREPOSAGE CLASSIFICATION DES APPROCHES DE CONCEPTION D UN ENTREPOT DE DONNEES Les approches directes Principe Travaux Analyse Les approches traditionnelles Les méthodes orientées sources Principe et travaux Les méthodes orientées besoins utilisateurs... 44

6 Analyse des besoins utilisateurs dans un projet d ED Mapping sources / Besoins Les approches ontologiques LIMITES DES APPROCHES EXISTANTES BILAN CHAPITRE ENTREPÔT DE DONNÉES VU COMME UN SYSTÈME D INTÉGRATION PROBLEMATIQUE D INTEGRATION Hétérogénéité des données Hétérogénéité structurelle Hétérogénéité sémantique CLASSIFICATION DES APPROCHES D INTEGRATION La représentation des données intégrées Approche virtuelle Approche matérialisée Le sens de mise en correspondance entre schéma global et schémas locaux Approche GaV Approche LaV La nature du processus d intégration Les approches manuelles Les approches semi-automatiques Les approches automatiques Quel type de système d intégration voulons-nous concevoir? NOTIONS SUR LES ONTOLOGIES Définition d une ontologie Les notions clés dans une ontologie Formalisation d une ontologie Domaines d émergence des ontologies Ontologies et modèles conceptuels Taxonomie des ontologies Les langages d ontologies LES ONTOLOGIES, SCHEMAS INTEGRANT DES SOURCES DE DONNEES ED Ontologie unique ED Multiples ontologies à postériori ED Multiples ontologies à priori CONCLUSION CHAPITRE MÉTHODE DE CONCEPTION À BASE ONTOLOGIQUE D UN ENTREPÔT DE DONNÉES APPORT DE LA METHODE SISRO M2C CONCLUSION... 91

7 CHAPITRE MISE EN ŒUVRE DE SISRO M2C ENVIRONNEMENT DE DEVELOPPEMENT ETAPES D IMPLEMENTATION ET INTERFACES CONCLUSION CONCLUSION CONCLUSION PERSPECTIVES ANNEXE LE LANGAGE D ONTOLOGIES OWL LES DECLINAISONS D OWL CONSTRUCTION D UNE ONTOLOGIE OWL Les Classes Les propriétés Les annotations Les restrictions BIBLIOGRAPHIE

8 Liste des figures Figure 1.1. Approches de conception des projets d entreposage Figure 1.2. Approche ontologique proposée Figure 2.1. Données orienté sujet dans un ED [BEL00] Figure 2.2. Non volatilité des données [INM92] Figure 2.3. Architecture d un entrepôt de données Figure 2.4. Le cube multidimensionnel Vente Figure 2.5. Représentation du cube multidimensionnel selon MOLAP Figure 2.6. Représentation du cube multidimensionnel selon ROLAP Figure 2.7. Exemple d un schéma en flocon de neige Figure 3.1 : Conception d un ED à partir des sources (selon Inmon) Figure 3.2. Conception d un ED à partir des besoins organisationnels (selon Kimball) Figure 3.3. Méthodes orientées sources Figure 3.4. Exemple d un schéma StarER Figure 3.5. Dimensional fact schema Figure 3.6. Exemple d un diagramme rationnel du framework i* Figure 3.7. Exemple d un modèle MAP [GS06] Figure 3.8. mapping sources/besoins selon une approche postérieure Figure 3.9. mapping Sources/Besoins selon une approche médiane Figure Mapping Sources/Besoins selon une approche antérieure Figure Approche ontologique Figure 4.1. Système d intégration des données [NGU06] Figure 4.2. Hétérogénéité sémantique des données [INM92] Figure 4.3. Intégration virtuelle [GIR05] Figure 4.4. Intégration matérialisée [NGU06] Figure 4.5. Approches GaV et LaV Figure 4.6. Intégration des sources à base d ontologies Figure 4.7. Le système d intégration à concevoir Figure 4.8. Modèle en oignon [FJP09] Figure 4.9. Approches d intégration à base d ontologies conceptuelles Figure Classification des approches d intégration Figure Architecture du système d intégration COIN [GBM99] Figure Architecture du système d intégration PICSEL [RG03] Figure Architecture du système ONION Figure 6.1. Mise en œuvre de la méthode SISROM2C Figure 6.2. Architecture d implémentation de SISRO M2C... 94

9 Liste des tableaux Tableau 2.1. Base de données Vs Entrepôt de données Tableau 2.2. ROLAP Vs MOLAP Tableau 4.1 : Tableau récapitulatif des approches d intégration à base ontologiques... 87

10 Chapitre 1 Introduction générale Un des capitaux les plus importants d une organisation sont les données et informations qu elle traite. Les applications qui manipulent ces données n ont cessé de connaître des progrès permanents en termes de traitements, de stockages, de performances, etc. Stockées tout d abord dans des fichiers, puis dans des bases de données (BDDs), les données représentent une réelle mine de connaissances pour les entreprises. Grâce aux bases de données, les entreprises pouvaient alors gérer des données orientées applications servant à exécuter des transactions journalières. Ces applications utilisent des processus appelés OLTP (On-Line Transaction Processing) permettant de gérer des données variées et d effectuer des traitements et transactions sur ces données. L évolution fulgurante des technologies a permis de générer de très grandes quantités de données produites et manipulées par les entreprises. Le besoin de faire plus que de simples traitements sur ces données s est fait alors ressentir. L informatique décisionnelle est ainsi apparue durant les années 70, permettant d exploiter ces grandes quantités de données manipulées, dans un but d analyse afin de comprendre les informations disponibles et de définir des indicateurs qui facilitent la prise de décision opérationnelle. De nouveaux systèmes d aide à la décision ont été proposés afin de faciliter la tâche des gestionnaires et décideurs. Ces applications utilisent des processus d'analyse en ligne de données OLAP (On-Line Analytical Processing) répondant à des besoins d analyse de l information. Le premier outil commercial OLAP, nommé Express, a été disponible en Plusieurs autres outils OLAP ont suivis [HAY02]. Pour rendre cette analyse possible, les entreprises avaient besoin de nouvelles données agrégées, consolidées, historisées et synthétisées selon plusieurs dimensions. Le besoin d une nouvelle architecture, qui stocke et traite ce type de données, s est présenté, ce qui a donné 10

11 Introduction générale naissance à l architecture d entrepôts de données (EDs). Plusieurs projets de construction d ED expérimental ont ainsi commencé à émerger. La première application d entreposage a été développée en 1983 par Teradata 1. Le terme «business data warehouse» a été introduit pour la première fois par deux chercheurs de la compagnie IBM, Barry Devlin and Paul Murphy, dans leur article «An architecture for a business and information systems», et l ont décrit comme composant clé d un système d informations décisionnel [DM88]. Au milieu des années 90, pas moins de 4,5 billions de dollars ont été investi dans des projets d entreposage [BU99]. En 1992, Bill Inmon, considéré comme un des précurseurs du concept d'entrepôt de données fournit un guide pratique de construction d un ED, dans son ouvrage de référence «Building the data warehouse» [INM92]. Il propose ainsi de développer les EDs à partir des sources de données existantes. Ralph Kimball, un autre pionnier du domaine, a également fournit sa vision pour la construction des EDs dans son ouvrage «the DW toolkit» en 1996 [KIM96], et propose quant à lui de construire l ED à partir des besoins des utilisateurs. Cet ouvrage a également contribué à populariser la modélisation multidimensionnelle d un ED, largement accepté aujourd hui comme la modélisation idéale permettant d organiser les données d un entrepôt afin de faciliter leur analyse. Ces deux ouvrages ont ouvert une nouvelle voie de recherche portant sur la conception des projets d entreposage. Comme pour tout système informatique, cette conception passe généralement par les trois niveaux de conception habituels: conceptuel, logique et physique. Les premiers travaux de projets d entreposage généraient directement le schéma logique de l entrepôt sans passer par une étape de modélisation conceptuelle. Cette conception s effectue soit selon la vision d Inmon, en construisant le schéma logique ensuite physique de l ED à partir des sources de données par une approche itérative ; soit selon la vision de Kimball à partir des besoins des décideurs et utilisateurs de l ED. Le passage direct aux phases logiques et physiques présente plusieurs inconvénients. La modélisation conceptuelle a longtemps été négligée dans les projets de développement des EDs. 1 Teradata : constructeur et un éditeur de solutions informatiques spécialisées en matière d entrepôt de données et d applications analytiques 11

12 Introduction générale Cet axe de recherche de conception des EDs a commencé à présenter un certain intérêt lorsque des études ont montré que les principales causes possibles d échec des projets d entreposage à constituer un support au processus de prise de décision, est l absence d une vue globale du processus ou l absence d une méthodologie de conception de l entrepôt de données [GMR98]. Pour remédier à cette problématique, certains travaux se sont intéressées à mettre en place une vraie phase de conception lors de la construction d un entrepôt. Ainsi, dès la fin des années 90, des travaux, se sont basés sur la définition d Inmon [INM92] qui indique que le développement d un ED repose essentiellement sur les données des sources ; et ont proposé de générer un schéma conceptuel multidimensionnel d un ED en analysant les schémas des sources de données. Ces méthodes ignorent cependant les besoins des décideurs qui sont les premiers concernés par l entrepôt à développer. L implication des décideurs et utilisateurs, dès le début d un projet d entreposage, est apparue par la suite comme une étape indispensable. Une deuxième vague de méthodes de conception a donc été proposée en début des années 2000, suivant la philosophie de conception des BDs, permettant de prendre en compte les besoins des utilisateurs de l entrepôt. Les sources de données restent cependant le cœur de construction de l entrepôt. Une phase de mapping entre les sources et les besoins doit être effectuée. Dans toutes ces approches de conception proposées jusque là (à base de sources ou de besoins), l analyse des schémas des sources qui alimenteront l entrepôt, est une étape obligatoire. Les schémas de données dans une organisation sont souvent fortement hétérogènes. Cette hétérogénéité pose une problématique essentielle : l intégration des sources de données, dont le but est d avoir une vue globale et synthétisée des données. Cet exercice d intégration devient une tâche délicate et complexe, dans laquelle le concepteur devra gérer les différents conflits syntaxiques et sémantiques entre les sources. Les conflits sémantiques, qui sont les plus difficiles à gérer, peuvent être de différentes natures : conflits de représentations, conflits de noms, conflits de contexte et conflits de mesures. Les différentes méthodes proposées ne peuvent être appliquées que sur un schéma intégré des sources. Ce schéma intégré n est facilement obtenu que dans le cas où l on a affaire à un nombre restreint de sources, qui sont faciles à analyser par le concepteur. Ceci est rarement le cas dans un scénario réel. L obtention d un tel schéma devient rapidement un problème 12

13 Introduction générale important à partir d un certain nombre de sources. Cette forte hypothèse d existence d un schéma intégré est souvent masquée ou complètement ignorée dans les méthodes de conception proposées. L étude des différentes méthodes et approches de conception des EDs, nous a ainsi permis de souligner la forte similarité existante entre les EDs et les systèmes d intégration (SI) dans leur processus de construction. Partant de ce constat, on remarque que plusieurs travaux sur les SI proposent l utilisation des ontologies afin de permettre une intégration sémantique et de manière automatique. Les ontologies ayant prouvé leur efficacité pour le développement des SI, nous pensons qu il est très intéressant d utiliser les ontologies pour le développement des EDs. Dans ce cadre là, un seul travail [RA07] a proposé de générer le modèle conceptuel d un ED à partir d une ontologie couvrant les sources de données. L hypothèse d existence d une telle ontologie n est pas étudiée dans cette méthode, et les besoins utilisateurs ne sont pas réellement considérés. 1 Contribution du mémoire A partir de ce bref historique des méthodes de conception des projets d entreposage, nous proposons une nouvelle classification des méthodes de conception où l on distingue trois grandes générations d approches de conception : les approches directes (passage direct au modèle logique), les approches traditionnelles (orientées sources ou orientées besoins), et une nouvelle génération d approches ontologiques. On remarque l ajout d un niveau d abstraction d une génération d approches à une autre. 13

14 Introduction générale Sources Besoins Modèle logique Modèle physique Approches directes Sources Besoins Modèle conceptuel Modèle logique Modèle physique Approches traditionnelles Sources Ontologie intégrante Modèle conceptuel Modèle logique Modèle physique Approches ontologiques Figure 1.1. Approches de conception des projets d entreposage 1 Concevoir un entrepôt de données est reconnu aujourd hui comme une tâche cruciale pour la réussite d un projet d entreposage [GOL09]. On propose ainsi une nouvelle méthode de conception d un ED à base ontologique dans laquelle les sources de données et les besoins décisionnels sont exprimés en utilisant les concepts et propriétés ontologiques. La contribution principale de cette méthode est qu elle représente la première méthode de conception effectuant le rapprochement entre les sources et les besoins d un entrepôt de données au niveau ontologique et permettant l obtention d un modèle conceptuel défini au niveau sémantique. L avantage de cette méthode étant de faciliter à l administrateur ou au concepteur sa tâche de conception, en le guidant dans cet exercice tout en lui offrant une réelle autonomie de conception. 1 On remarque une prise de conscience de la nécessité d impliquer les besoins des utilisateurs à partir des approches traditionnelles. 14

15 Introduction générale Sources Besoins Ontologie intégrante Modèle conceptuel sémantique Modèle logique Modèle physique Figure 1.2. Approche ontologique proposée 1 En plus d assurer une intégration sémantique des sources, et une représentation ontologique des besoins décisionnels, l ontologie permet de décrire les concepts et propriétés d un domaine donné indépendamment de tout objectif applicatif (une ontologie est orientée domaine). Un modèle conceptuel d un entrepôt par contre, permet de prescrire les concepts d un domaine selon les besoins d une application décisionnelle donnée (un modèle conceptuel est orienté application). Il est ainsi intéressant de considérer une ontologie comme premier niveau de spécification d un modèle conceptuel. En nous penchant sur les approches de conception des bases de données, certains travaux (comme [SS06], [FBD08]) ont dernièrement proposé une conception à partir d ontologies de domaine. D une manière générale, ces méthodes proposent de concevoir une BDD selon les étapes suivantes : (1) choisir une ontologie couvrant le domaine de la BDD à concevoir, (2) étendre, si nécessaire, cette ontologie manuellement par de nouveaux concepts ou propriétés, (3) sélectionner une partie de cette ontologie de manière à ce que cette partie couvre les besoins de la BDD à concevoir et (4) implanter le modèle conceptuel dans la base (en le traduisant en un modèle logique puis physique). La méthode que nous proposons, s inspire de ces approches de conception, et comporte quatre principales étapes : 1. Définition d une ontologie intégrant les sources de données au niveau sémantique 1 On s intéresse dans cette étude au niveau conceptuel uniquement. 15

16 Introduction générale 2. Génération automatique d une ontologie «locale» à partir de l ontologie intégrante représentant les besoins décisionnels. Cette ontologie peut être étendue afin de représenter au mieux les besoins de l application décisionnelle cible. 3. Définition du schéma conceptuel multidimensionnel de l entrepôt de données à partir de l ontologie locale. 4. Validation du schéma conceptuel par un ensemble de recommandations proposées et manuellement par le concepteur. Le modèle conceptuel d ED obtenu est défini au niveau sémantique. Un cadre formel de définition et de représentation de ce modèle est proposé. Un outil visuel validant la méthode proposée est développé. Le but de la mise en œuvre de cette méthode est de présenter un outil de génie logiciel (niveau conceptuel) dédié aux applications décisionnelles. Cet outil implémente l ensemble des étapes de la méthode. Certaine étapes se font en interaction avec le concepteur. 2 Organisation du mémoire Afin de répondre à la problématique posée pour ce travail de magistère, nous présentons dans ce rapport une étude des différentes notions qui nous ont permis d aboutir à une proposition d une nouvelle méthode de conception. Ce document s organise en sept chapitres. Le deuxième chapitre porte sur les principales notions liées au concept d entrepôt de données, nécessaires à la compréhension des autres chapitres. Le troisième chapitre présente un état de l art sur les différentes méthodes de conception des projets d entreposage que nous classifions en trois approches. Pour chaque approche, nous décrivons son principe ainsi que les principales méthodes proposées pour cette approche. Nous conclurons par une analyse de ces différentes approches en montrant la forte similarité existante entre la conception des EDs et celle des systèmes d intégration. Le quatrième chapitre présente les principales notions relatives aux systèmes d intégration et nous montrons comment et à quels niveaux les ontologies ont contribué dans la construction et le développement de ces derniers. 16

17 Introduction générale Le cinquième chapitre porte sur notre contribution, où l on présente une nouvelle méthode de conception ontologique d un ED. Le sixième chapitre propose une mise en œuvre de la méthode proposée, où l on décrit l environnement de développement, l architecture d implémentation ainsi que les interfaces du prototype développé. Le septième et dernier chapitre conclut notre travail, en récapitulant les principaux résultats, et en suggérant des directions de recherche futures. 17

18 Chapitre 2 Les entrepôts de données Une des préoccupations essentielles pour les dirigeants et décideurs d une entreprise réside dans l exploitation des informations contenues dans les systèmes opérationnels pour une meilleure prise de décision. Aujourd hui, les bases de données des entreprises contiennent d extraordinaires quantités de données, dont la taille se compte parfois en téraoctets (2 40 octets), voire en petaoctets (2 50 octets). On estime également que la quantité des données collectée et numérisée dans le monde double tous les 20 mois [HA04]. Devant cette mine d informations à leur disposition, les entreprises sont à la recherche de systèmes efficaces permettant leur exploitation à des fins d analyse et de prise de décision. Les systèmes décisionnels ont été élaborés dans ce but. Un système décisionnel est un système d'information dédié aux applications décisionnelles. Un élément clé dans l architecture d un système décisionnel est l entrepôt de données. Ce chapitre présente les principales notions relatives aux entrepôts de données. Dans les premières sections, nous présentons la définition, l architecture, les spécificités et les objectifs d un entrepôt de données. Nous décrivons par la suite la modélisation multidimensionnelle utilisée pour la conception des entrepôts de données ainsi que les différents modèles de données associés aux entrepôts. Nous nous intéressons pour finir au cycle de vie d un entrepôt afin d y situer notre problématique. 18

19 Chapitre 2 : Les entrepôts de données 1 Définition d un entrepôt de données Les EDs deviennent aujourd hui des outils incontournables dans plusieurs domaines (universités, compagnies aériennes, banques, compagnies d assurances ). Le concept d entrepôt de données a été introduit pour décrire une plateforme logique facilitant l accès aux diverses données d une organisation, et permettant l utilisation de ces données à des fins d analyse et de prise de décision. Plusieurs définitions ont été données au concept ED. Au risque de ne pas être original, nous retenons la définition de W.H. Inmon, qui, dans son ouvrage de référence "Building the Data Warehouse" [INM92], décrit un ED comme "Une collection de données orientées sujet, intégrées, non volatiles et historisées, organisées pour supporter un processus d aide à la décision ". Cette définition englobe les termes clés suivants [BEL00]: - Orientées sujet : les données des systèmes d informations sont organisées selon les applications d une entreprise. Ces données sont orientées applications. Les données d un ED sont organisées par thèmes ou par sujets (Exemple : Production, Vente, Marketing ). Cette organisation permet de rassembler toutes les informations relatives à un thème précis afin de faciliter la prise de décision. Ces données sont orientées sujet. Systèmes opérationnels Entrepôt de données Production Clients Gestion de stock Vendeur Facturation Livraison Produit Applications Sujets Figure 2.1. Données orienté sujet dans un ED [BEL00] 19

20 Chapitre 2 : Les entrepôts de données - Intégrées : les données d un ED proviennent de différentes sources hétérogènes. Cette hétérogénéité donne lieu à des conflits syntaxiques et sémantiques (conflits de représentation, de noms, de contexte et de mesure) entre les données des sources. L intégration des données permet d éliminer l ensemble de ces conflits afin d avoir une représentation uniforme et cohérente des données lors de leur chargement au niveau de l ED. Selon [INM92], de toutes les caractéristiques d un ED, l intégration est l aspect le plus important. - Non volatiles : Les données d un entrepôt sont généralement utilisées en mode consultation. Elles peuvent être interrogées mais ne sont ni modifiées, ni supprimées (sauf dans les cas de rafraichissement de l entrepôt). Ceci permet de conserver la traçabilité des informations afin de pouvoir effectuer des analyses sur une longue période. Access Update Delete Données Access Acces s Update Insert Charger Système Opérationnel Entrepôt de données Figure 2.2. Non volatilité des données [INM92] - Historisées : les données d un entrepôt doivent être associées à un référentiel temps afin de refléter l activité de l entreprise sur une période. L historique des données peut s étendre sur plusieurs années. Ceci permet de suivre et d analyser les variations des données et d effectuer des analyses comparatives dans le temps. - Organisées pour supporter un processus d aide à la décision : les données provenant des sources doivent être agrégées afin de faciliter leur analyse. Ces données peuvent être consultées à travers des outils (requêtes, outils OLAP, outils de data mining, outils de statistiques ) permettant leur manipulation et leur analyse. 20

21 Chapitre 2 : Les entrepôts de données 2 Base de données Vs Entrepôt de données L objectif premier d un ED est de stocker les données pertinentes aux besoins de prise de décision. Contrairement aux bases de données opérationnelles qui sont conçues pour supporter des opérations journalières, un entrepôt est conçu pour supporter des opérations d analyse utile à la prise de décision. Le tableau suivant récapitule les principales différences entre les BDDs opérationnelles et les EDs [BEL00]. Caractéristiques Systèmes opérationnels Entrepôts de données But Exécution d un processus métier Evaluation d un processus métier Usage Support à la gestion courante Support à la prise de décision Principe de Troisième forme normale Conception multidimensionnelle conception Données Actuelles, brutes Historiques, agrégées Opérations Lecture et écriture Lecture et rafraîchissement Utilisateurs Employé Analyste et décideur Taille Des giga-octets Plutôt des téra-octets Tableau 2.1. Base de données Vs Entrepôt de données 3 Architecture d un entrepôt de données Le processus de construction d un ED, comme illustré dans la figure 2.4, peut être structuré en quatre axes : Figure 2.3. Architecture d un entrepôt de données 21

22 Chapitre 2 : Les entrepôts de données Les sources de données L entrepôt de données stocke des données provenant de différentes sources d informations hétérogènes et distribuées. Ces sources peuvent être des bases de données, des fichiers de données, des sources externes à l entreprise Stockage Avant de pouvoir être stockées, les données des sources doivent d abord être nettoyées. Le processus de nettoyage consiste à sélectionner et à épurer les données pour éliminer toute erreur et réconcilier les différences sémantiques entre ces données. Une fois nettoyées, ces données, seront intégrées dans l entrepôt. Le processus de rafraîchissement consiste à propager vers l entrepôt, les changements effectués sur les données des sources. Les données concernant la création, la gestion, et l usage de l entrepôt sont stockées dans un répertoire indépendant de l entrepôt. Ces données sont appelées «méta-données». Les méta-données peuvent contenir des informations sur les sources et leurs contenus, le schéma de l entrepôt, les règles de rafraîchissement, les profils et groupes d usagers Un ED peut comporter plusieurs magasins de données (data marts). Les magasins sont des extraits de l'entrepôt consacrés à un type d'utilisateurs et répondant à un besoin spécifique. Ils sont dédiés aux analyses décisionnelles de type OLAP. Serveur OLAP Un serveur OLAP permet d accéder à l entrepôt, il convertit les requêtes des clients en requêtes d accès à l ED et fournit des vues multidimensionnelles des données à des outils d aide à la décision. Outils de front end Ces outils formatent les données, conformément aux besoins des utilisateurs, sous différentes formes : tableaux, courbes, rapports, statistiques 22

23 Chapitre 2 : Les entrepôts de données 4 La modélisation d un ED Les modèles de conception des systèmes transactionnels OLTP ne sont pas adaptés aux systèmes OLAP dont les requêtes sont souvent très complexes, utilisent beaucoup de jointure, demandent beaucoup de temps de calcul et sont de nature ad hoc. Pour ce type d environnement OLAP, une nouvelle approche de modélisation a été proposée : la modélisation multidimensionnelle. Popularisée par Ralph Kimball dans les années 90, cette modélisation est aujourd hui reconnue comme la modélisation la plus appropriée aux besoins d analyse et de prise de décision [ADA06]. La modélisation multidimensionnelle est une technique de conceptualisation et de visualisation des modèles de données. Elle offre une structuration et une organisation des données facilitant leur analyse. Elle a pour principal objectif d avoir une vision multidimensionnelle des données. Les données sont organisées de manière à mettre en évidence le sujet analysé et les différentes perspectives d'analyse. Cette modélisation est intéressante d une part parce qu elle représente une modélisation assez proche de la manière de penser des analystes, et d autre part, elle facilite aux utilisateurs la compréhension des données. Le modèle multidimensionnel renferme les deux concepts fondamentaux de fait et de dimension. - Un fait représente le sujet ou le thème analysé. Il présente un centre d intérêt de l entreprise et est considéré comme un concept clé sur lequel repose le processus de prise de décision. Un fait est formé de «mesures» ou attributs du fait (atomiques ou dérivés) qui correspondent aux informations liées au thème analysé. Par exemple pour la gestion des commandes, les mesures peuvent être la quantité du produit commandé et le montant de la commande. - Une dimension représente un contexte d analyse d un fait, par exemple la gestion des commandes peut être analysée selon les dimensions Client, Magasin, et Temps. Les dimensions se présentent sous forme d une liste d éléments organisés de façon hiérarchique. Par exemple, pour la dimension temps, nous pouvons avoir la hiérarchie suivante : année, semestre, trimestre, mois, semaine et jour. Les dimensions sont caractérisées par des attributs de dimensions. Une hiérarchie est dite complète si tous les objets d un niveau de la hiérarchie appartiennent à une seule classe d objets d un niveau supérieur et forment cette classe. 23

24 Chapitre 2 : Les entrepôts de données Le principal constructeur des modèles multidimensionnels est le cube de données. Un cube de données est composé de cellules qui représentent les mesures (les attributs du fait). Le cube ci-dessous permet d analyser les mesures selon les différentes dimensions : produit, site et temps. Les hiérarchies définies sur une dimension peuvent être simples ou multiples. Figure 2.4. Le cube multidimensionnel Vente Plusieurs opérations OLAP peuvent être effectuées sur cette structure multidimensionnelle appelées opérations de restructuration qui sont : pivot, switch, split, nest, et push. - L opération Pivot permet d effectuer une rotation du cube autour d un des axes de manière à permettre une représentation d un ensemble de faces différent. - L opération Switch consiste à inter-changer la position des membres d une dimension. - L opération Split coupe le cube de manière à permettre à l utilisateur de visualiser une partie du cube en réduisant le nombre de dimensions d une représentation. - L opération Nest permet d imbriquer des membres de dimensions. - L opération Push permet de combiner les membres d une dimension aux mesures du cube. D autres opérations sont liées à la granularité permettant ainsi la hiérarchisation des données. Ces opérations sont Roll up et Drill down. 24

25 Chapitre 2 : Les entrepôts de données - L opération Roll up permet de visualiser les données de manière résumée (en allant d un niveau particulier de la hiérarchie vers un niveau plus général). - L opération Drill down permet de naviguer vers des données d un niveau inférieur et donc plus détaillé. Le paradigme multidimensionnel doit être utilisé tout au long du processus de développement de l ED. Il est nécessaire de définir des modèles conceptuels, logiques et physiques de l entrepôt, ainsi qu une méthodologie spécifiant le passage entre ces modèles, adaptés au paradigme multidimensionnel [CPM01]. Il n y a cependant aucun consensus ou standard permettant de représenter un modèle multidimensionnel. Plusieurs auteurs ont proposé des modèles de données adaptés au paradigme multidimensionnel pour le développement d un ED, on peut citer : Sapia et al. [SBH98] qui présentent le modèle ME/R (Multidimensional Entity Relationship) qui est une spécialisation du modèle E/A, et l adaptent pour la modélisation conceptuelle des systèmes OLAP. Le modèle E/A est ainsi adapté en lui ajoutant de nouvelles entités et relations spéciales accompagnées de leur représentation graphique permettant de représenter les faits, les dimensions et les hiérarchies de dimensions. Dans la même lignée, Cavero et al. [CPM01] proposent un modèle IDEA, qui étend le modèle E/A par les concepts d héritage, et de généralisation de hiérarchies afin de représenter sémantiques multidimensionnelles. Bulos et al. [BF98] présentent une modélisation ADAPT se basant sur deux principaux objets de modélisation multidimensionnels : les hyper cubes (ou cubes) et les dimensions ainsi que d autres objets supplémentaires. Lujn-mora et al. [LTS02] proposent une modélisation multidimensionnelle se basant sur la notation UML. Différents packages on été introduits (package fait, package dimension et package étoile), représentés par des stéréotypes particuliers qui étendent la notation UML. Abello et al. [ASS01] effectuent une classification des modèles de données multidimensionnels proposés dans la littérature. Cette classification s effectue selon les différentes phases de modélisation proposées par les auteurs et les différents concepts utilisés. 25

26 Chapitre 2 : Les entrepôts de données 5 Les implémentations d un cube multidimensionnel Il existe deux manières principales pour construire un système basé sur un modèle multidimensionnel, selon la manière dont le cube est stocké : l approche MOLAP et l approche ROLAP. 5.1 L approche MOLAP Les systèmes MOLAP (Multidimensional On-Line Analytical Processing) implémente le cube sous forme d un tableau multidimensionnel (SGBD multidimensionnel). Chaque dimension du tableau représente une dimension du cube. Les données de chaque cellule sont stockées. Par exemple, le cube multidimensionnel de la figure 2.6 peut être représenté par le tableau multidimensionnel suivant : Temps Trimestre 1 Trimestre 2 Trimestre 3 Trimestre 4 Total Produit Site N S Total N S Total N S Total N S Total N S Total Produits laitiers Viennoiseries Viandes Total Figure 2.5. Représentation du cube multidimensionnel selon MOLAP Le principal avantage d un système MOLAP est sa performance en temps d accès (l accès aux données est direct). Outre le fait que ce système ne présente aucun standard, ses principaux inconvénients sont [BEL00]: - Le besoin de redéfinir des opérations pour manipuler les structures multidimensionnelles. - Difficulté de la mise à jour et de la gestion du modèle. - Consommation de l espace lorsque les données sont éparses, ce qui nécessite l utilisation des techniques de compression. 26

27 Chapitre 2 : Les entrepôts de données 5.2 L approche ROLAP Les systèmes ROLAP (Relational On-Line Analytical Processing) stockent les données du cube en utilisant un SGBD relationnel. Chaque dimension du cube est représentée sous forme d une table appelée table de dimension. Chaque fait est représenté par une table de fait. Les mesures sont stockées dans les tables de faits qui contiennent les valeurs des mesures et les clés vers les tables de dimensions. Par exemple, le cube multidimensionnel de la figure 2.5 peut être représenté par les tables suivantes : Table de dimension Produit Table de dimension Temps TID Jour Mois Trimestre Année Table de fait Ventes TID PID MID PrixUnitaire Montant PID Description Marque Catégorie Emballage Table de dimension Magasin MID Nom Ville Adresse Figure 2.6. Représentation du cube multidimensionnel selon ROLAP Le principal inconvénient de ces systèmes est qu ils peuvent présenter un temps de réponse aux requêtes élevé. Leurs principaux avantages sont : - Exploitation des capacités d un standard bien établi et maîtrisé le relationnel, ce qui facilite leur intégration dans les SGBD relationnels existants. - Stockage de grandes quantités de données. Trois schémas sont utilisés pour modéliser les systèmes ROLAP : - Le schéma en étoile - Le schéma en flocon de neige - Le schéma en constellation 27

28 Chapitre 2 : Les entrepôts de données Le schéma en étoile Chaque dimension du cube est représentée par une table de dimension et les mesures par une table de faits qui référence les tables de dimension en utilisant une clé étrangère pour chacune d elles. La table de faits est normalisée, les tables de dimension sont généralement dénormalisées. Cette représentation facilite l analyse selon différentes perspectives. Les requêtes généralement appliquées sur ce schéma sont appelées «requêtes de jointure en étoile», et ont les propriétés suivantes [BEL00] : - il y a des jointures multiples entre la table des faits et les tables de dimension. - il n y a pas de jointure entre les tables de dimensions. - chaque table de dimension impliquée dans une opération de jointure à plusieurs prédicats de sélection sur ses attributs descriptifs. La figure 2.7 présente un exemple d un schéma en étoile Le schéma en flocon de neige Le schéma en flocon de neige est une extension du schéma en étoile. Dans un schéma en étoile, les informations associées à une hiérarchie de dimension, sont représentées dans une seule table, même si les différents niveaux de la hiérarchie ont des propriétés différentes. Le schéma en flocon est le résultat de la décomposition d une ou plusieurs dimensions en plusieurs niveaux formant une hiérarchie. Les tables de dimensions sont ainsi éclatées en plusieurs tables, ce qui peut être vu come une normalisation des tables de dimensions. La table de faits reste inchangée. Ce type de schéma offre une meilleure visualisation et compréhension des données, mais peut altérer les performances de l entrepôt lors de son utilisation. En effet, une requête nécessitera plusieurs jointures ce qui augmente son temps de réponse. 28

29 Chapitre 2 : Les entrepôts de données Table de dimension Produit Table de dimension AID Année Année Table de dimension Mois MID Mois Trimestre Table de dimension TID Date Temps Table de fait Ventes TID PID MID PrixUnitaire Montant PID Description Marque Catégorie Emballage Table de dimension Site MID Nom Ville Adresse Figure 2.7. Exemple d un schéma en flocon de neige Le schéma en constellation Les schémas en constellations sont des schémas où plusieurs modèles dimensionnels se partagent les mêmes dimensions, c'est-à-dire les tables de faits ont des tables de dimensions en commun. Les tables de dimensions partagées par plusieurs tables de fait doivent être exactement les mêmes. 5.3 L approche HOLAP Les systèmes HOLAP (Hybrid On-Line Analytical Processing) sont des systèmes où les données fréquemment utilisées (généralement les données agrégées) sont maintenues par un SGBD multidimensionnel, et les données non fréquemment utilisées dans un SGBD relationnel. Ceci afin de bénéficier des avantages des deux systèmes cités précédemment. La séparation des données doit être transparente à l utilisateur final. 29

30 Chapitre 2 : Les entrepôts de données Mendelzon propose une comparaison entre les deux approches ROLAP et MOLAP [BEL00] : Stockage Avantages Inconvénients ROLAP Technologie familière Lenteur Scalable (capacité d expansion élevée) Ouvert MOLAP Modèle multidimensionnel Technologie non prouvée Traitement de requête spécialisé Non scalable Techniques d indexation spécialisées Tableau 2.2. ROLAP Vs MOLAP 6 Cycle de vie d un entrepôt de données Le cycle de vie d un ED peut être structuré en trois principales phases [GOL09] : - Planification : cette phase vise à préparer le terrain pour le développement de l entrepôt. Elle inclut les tâches suivantes o Déterminer l étendue du projet ainsi que les buts et objectifs de l entrepôt à développer o Evaluer la faisabilité technique et économique de l entrepôt o Identifier les futurs utilisateurs de l entrepôt - Conception et implémentation : cette phase consiste à développer le schéma de l entrepôt, et à mettre en place toutes les ressources nécessaires à son implémentation et à son déploiement. Cette conception comporte cinq principales étapes. Notre problématique se situant dans cette phase, nous allons détailler ces étapes dans le point suivant (point 6.1). - Maintenance et évolution : la maintenance de l entrepôt implique l optimisation de ses performances périodiquement. L évolution de l entrepôt concerne la mise à jour de son schéma en fonction des différents changements survenant au niveau des sources ou des besoins des utilisateurs. 30

31 Chapitre 2 : Les entrepôts de données Pour les besoins de notre problématique, nous détaillons davantage la deuxième phase «conception et implémentation». 6.1 Conception d un entrepôt de données Même s il n existe actuellement aucun consensus sur une méthode de conception précise, la plupart des travaux s accordent à distinguer les étapes suivantes pour la conception d un ED : analyse des besoins, modélisation conceptuelle, modélisation logique, processus ETL et modélisation physique Analyse des besoins L analyse des besoins joue un rôle clé dans tout projet logiciel en permettant de réduire significativement le risque d échec du projet [RAL06]. L ingénierie des besoins a été définie comme le processus de développement des besoins selon un processus itératif et coopératif d analyse du problème, de documentation des observations résultantes dans divers formats de représentation et de vérification des résultats obtenus [BRL94]. La spécification des besoins d un projet d entrepôt de données permet de déterminer quelles seront les différentes fonctions de l entrepôt ainsi que l ensemble des informations requises que ce dernier doit couvrir (quelles sont les données qui doivent être accessibles, comment ces données sont transformées, organisées, calculées et agrégées) [BLS01][SLB02]. Deux méthodes sont utilisées pour collecter les besoins : une collecte orientée source et une collecte orientée utilisateur. Une approche orientée source se limite à identifier les besoins de l ED à partir de l ensemble des données disponibles au niveau des sources. La collecte orientée utilisateurs identifie les besoins des utilisateurs et décideurs de l entreprise et présente l avantage principal de se concentrer à fournir un modèle répondant à ce qui est exigé plutôt que ce qui est disponible. Un ED, par essence, doit être construit à partir des sources de données. Une collecte orientée sources est par conséquent indispensable. Les besoins utilisateurs n ont cependant pas toujours été considérés lors du développement des EDs. Ce sont généralement les travaux récents qui prennent en compte les besoins utilisateurs. Même si les méthodologies de développement d un ED diffèrent généralement, elles reconnaissent de plus en plus la nécessité d identifier et de modéliser les besoins des utilisateurs [SS05]. 31

32 Chapitre 2 : Les entrepôts de données La modélisation des besoins (collectés à partir des sources et/ou des utilisateurs) passe par les activités suivantes [BHS98] : La collecte des besoins, l analyse des besoins, la validation des besoins et la modélisation des besoins. - La collecte des besoins consiste à collecter les besoins souvent selon des approches itératives. La collecte à partir des sources passe par une analyse détaillée des sources de données. la collecte orientée utilisateur passe par des techniques de réunions, d étude de la documentation existante, d interviews et de brainstorming. Ces besoins sont ensuite documentés (généralement de manière informelle). La collecte a pour but de comprendre le domaine qui devra être modélisé. - L analyse des besoins consiste à étudier les besoins collectés, où des modèles initiaux peuvent être construits. - La validation des besoins consiste à valider les modèles initiaux construits lors de l analyse des besoins, avec les utilisateurs ainsi qu avec les sources de données existantes. L entrepôt est ainsi construit de manière itérative, ce qui garantit selon [BHS98] un développement rapide. L expérience a montré que même après implémentation de l entrepôt de données, un retour vers la phase d identification des besoins est possible. L utilisation et la maintenance du modèle de données est effectué continuellement durant tout le cycle de vie de l entrepôt. Les travaux sur l analyse des besoins en ED restent assez limités. Certains travaux suggèrent l utilisation des techniques utilisés pour l analyse des besoins en BD, d autres estiment qu il faut des méthodes adaptées aux spécificités des EDs. On retrouve quelques travaux portant sur des méthodologies présentant des directives générales permettant de mener à bien l analyse des besoins dans un projet d ED. Nous présentons deux travaux (Rilston et al., Winter et al.) souvent référencés : Rilston et al. [RPJ03] proposent une méthodologie comprenant quatre phases : - Phase d initialisation qui consiste à identifier les utilisateurs cibles ainsi que le type d application d analyse le plus dominant ce qui permettra de choisir les modèles de données à utiliser, les sources de données pertinentes et les processus de décisions devant être considérés. - Une deuxième phase d analyse des sources de données existantes et les rapports utilisés régulièrement par les utilisateurs, et à développer des schémas de données agrégés. 32

33 Chapitre 2 : Les entrepôts de données - Une troisième phase qui consiste à établir des priorités entre les besoins en informations. - Une quatrième phase consistant à concevoir un modèle des besoins initial servant de base au modèle conceptuel. Winter et al. [WS04] proposent également une méthodologie comprenant quatre phases : - Planning de gestion des besoins : consiste à définir les objectifs du projet par les utilisateurs et les concepteurs, définir les règles d intégration des sources de données et à établir un planning de gestion des besoins du projet (contraintes de temps, délimiter les frontières du projet ). - Spécification des besoins : s effectue par un processus itératif d acquisition, représentation et validation des besoins. La spécification s effectue à travers plusieurs (sous) processus en plusieurs itérations en utilisant un modèle en spirale, où chaque itération produit un ensemble de spécifications plus raffiné. - Validation des besoins par l équipe de développement, les utilisateurs, et les experts du domaine. L équipe de validation attache une liste d actions à chaque problème identifié et des retours arrière vers les phases précédentes peuvent être envisagés. - Suivi et gestion de l évolution des besoins : la gestion doit être effectuée à deux niveaux : une gestion de l évolution des besoins utilisateurs, et une gestion de l évolution de l architecture des bases de données sources afin d étudier l impact d éventuels changements sur les modèles suivants (conceptuels, logiques et physiques) Modélisation conceptuelle Cette étape consiste à établir une méthode permettant de définir le schéma conceptuel d un entrepôt, annoté par les concepts multidimensionnels (faits, mesures et dimensions). Le but de cette modélisation est de fournir une représentation abstraite de la situation en cours d étude indépendamment de tout logiciel technique. Un modèle conceptuel est caractérisé par le domaine concerné, le formalisme utilisé pour modéliser le schéma conceptuel, et le point de vue correspondant aux besoins des utilisateurs [FJP09]. Le modèle conceptuel obtenu doit se conformer à la modélisation multidimensionnelle adaptée aux modèles d EDs permettant d organiser les données entreposées de manière à faciliter leur analyse décisionnelle. Une 33

34 Chapitre 2 : Les entrepôts de données synthèse des travaux proposant des méthodes de conception de projets d entreposage est présentée au chapitre suivant Modélisation logique Cette étape consiste à dériver le schéma logique de l entrepôt à partir de son schéma conceptuel, et à l adapter aux particularités du serveur de l entrepôt choisi (ROLAP, MOLAP ou HOLAP). Ce passage implique la gestion de certains aspects techniques comme la fragmentation des dimensions en hiérarchies, la gestion de l agrégation des données, la gestion des dimensions génériques 1 et des mesures non additives Processus ETL (Extract-Transform-Load) Cette étape consiste à effectuer les transformations nécessaires au chargement des données des sources au niveau du schéma logique de l entrepôt. Ceci se fait en trois étapes [MAR06] : - Extraction : consiste à récupérer les données à partir des systèmes sources. Cette étape nécessite de gérer la synchronisation des processus d extraction afin d assurer l intégrité des données chargées. - Transformation : consiste en une série de règles permettant le formatage des données extraites selon le schéma cible de l entrepôt, comme par exemple assigner de la sémantique aux données sources et associer les champs sources aux champs cibles. - Chargement : permet l alimentation de l entrepôt par les données en respectant les contraintes du SGBD cible. Cette étape doit être validée afin de détecter et corriger toute erreur ayant survenue durant le chargement. 1 Une dimension générique est une dimension qui doit avoir la même signification selon les différents contextes auxquels elle peut être associée. 2 Une mesure est dite additive pour une dimension s il est possible d utiliser l opération d addition SUM pour agréger cette mesure tout au long des hiérarchies de cette dimension. Si une mesure est non additive, cette agrégation donne un résultat incohérent [TPG01]. 34

35 Chapitre 2 : Les entrepôts de données Modélisation physique Cette étape consiste à implémenter physiquement le schéma de l entrepôt, et à spécifier les techniques et schémas d optimisation de l entrepôt. Les techniques d optimisation peuvent être [BEL00] : - les vues matérialisées : une vue matérialisée est une table contenant les résultats d une requête. - les techniques d indexation : représentées par des structures permettant d'associer à une clé d un n-uplet l'adresse relative de ce n-uplet. Plusieurs types d index ont été proposés, on distingue les index définis sur une seule table ou vue (index en B-arbre, index de hachage et index bitmap) et les index de jointures définis sur plusieurs tables dans un schéma en étoile. - la fragmentation : technique consistant à partitionner le schéma d une base en plusieurs sous schémas pour réduire le temps d exécution des requêtes. On distingue la fragmentation horizontale (en fonction des tuples) de la fragmentation verticale (en fonction des attributs). 7 Conclusion Ce premier chapitre présente un état de l art des notions et concepts fondamentaux concernant les entrepôts de données à travers sa définition, son architecture, ses modèles de données utilisant le paradigme multidimensionnel (MOLAP, ROLAP et HOLAP), et son cycle de développement comprenant trois principales phases (planification, conception et implémentation, évolution et maintenance). Cette étude nous permet de cerner les principaux concepts clé des EDs dont on aura besoin pour tenter de répondre à notre problématique de conception d un ED. Pour cela, on se positionne selon le cycle de vie d un ED dans la deuxième phase «conception et implémentation», plus particulièrement la deuxième étape de modélisation conceptuelle. Le chapitre 3 présente un état de l art sur les différentes approches et méthodes de conception d EDs proposées dans la littérature, que nous avons classées en trois grandes approches. 35

36 Chapitre 3 Approches de conception des projets d entreposage Un retour sur l historique de conception des projets d entreposage nous a permis de mieux analyser les différentes approches et méthodes de conception proposées. Cet historique remonte aux années 90, peu après la naissance du concept d ED. La notion d entrepôt de données étant issue de l industrie, les premières approches de conception généraient directement le schéma logique de l entrepôt sans passer par une phase de modélisation conceptuelle. La mise en place d une vraie phase de conception pour le développement des entrepôts s est imposée par la suite afin de réduire le risque d échec du projet d entreposage. Deux principales catégories de méthodes ont ainsi été proposées : une première catégorie se basant uniquement sur les sources de données et une deuxième catégorie reconnaissant la nécessité d inclure les besoins des utilisateurs de l entrepôt lors de sa conception. Toutes ces méthodes ont cependant ignoré une problématique primordiale qui est l intégration des données dûe à l hétérogénéité des sources. Une toute nouvelle génération d approches proposant la conception des entrepôts en utilisant des ontologies se met en place. Différentes études ont prouvé l efficacité des ontologies pour assurer une intégration sémantique des données de manière automatique. Ce chapitre, s appuyant sur l historique de conception des projets d EDs, propose de classifier les méthodes de conception en trois grandes générations d approches : approches directes (passage direct au modèle logique), approches traditionnelles (basées sur les sources et/ou sur les besoins), et les approches ontologiques. Nous analysons pour chaque type d approche, son principe ainsi que les différentes méthodes de conception proposées dans la littérature. Nous ressortons les principales difficultés liés à ces approches, et mettons en avant les problèmes sur lesquels nous allons tenter d apporter des solutions. 36

37 Chapitre 3 : Approches de conception des projets d entreposage 1 Classification des approches de conception d un entrepôt de données Nous classons les approches de conception d un ED en trois principales approches : les approches directes (génération directe du schéma logique), les approches traditionnelles (mise en place d une vraie phase de conception), et les approches ontologiques (conception à base d ontologies). Nous remarquons que d une approche à l autre, on passe à un plus haut niveau d abstraction de conception. 1.1 Les approches directes Principe Les approches de conception directes définissent le schéma logique d un ED sans passer par une phase de modélisation conceptuelle. Cette manière de faire s explique par le fait que les entrepôts soient issus originellement de l'industrie qui s intéresse aux aspects pratiques et ne donne pas suffisamment d importance aux problèmes de conceptualisation, mais également par le fait que les modèles logique et physique d un entrepôt, jouent un rôle important dans l amélioration et l optimisation des performances du système décisionnel final, ce qui représente une des principales préoccupations des entrepôts. Ce schéma logique est défini à partir des sources de données (selon Inmon) ou des besoins organisationnels ou des deux (selon Kimball). Selon la vision d Inmon [INM92], un schéma de données de l entrepôt est construit à partir des sources de données selon un processus itératif. L analyse des sources s effectue selon les étapes suivantes : - Trouver les données - Accéder aux données - Intégrer les données - Fusionner les données Un modèle de données est généré à chaque itération, qui servira comme schéma de base pour l itération suivante. A chaque itération des tables de l entrepôt sont conçues et permettent de construire une version de l entrepôt de données. La mise en place de cet entrepôt auprès des utilisateurs permet de mieux cerner les besoins en informations. 37

38 Chapitre 3 : Approches de conception des projets d entreposage L itération qui suit alimente l entrepôt de l itération précédente par de nouvelles données et organise davantage ses données. Ce développement itératif peut s étendre sur plusieurs années. Applications Itération n Schéma de données de l ED ED Entrepôt 1- Trouver les données 2- Accéder aux données 3- Intégrer les données 4- Fusionner les données Processus itératif Figure 3.1 : Conception d un ED à partir des sources (selon Inmon) Selon la vision de Kimball [KIM96], un schéma en étoile de l entrepôt est construit en analysant les besoins de l entreprise. Ceci s effectue en identifiant les besoins organisationnels, en déterminant la granularité des données à représenter dans le schéma, et en identifiant les faits et dimensions de ce schéma. Selon cette vision, les décideurs et analystes d une organisation ont une connaissance sur les faits qu il souhaite analyser, ainsi que les dimensions selon lesquelles il souhaite analyser ces faits. Il communique ces informations au concepteur, qui pioche ensuite dans les sources afin d identifier les données qui peuvent correspondre aux faits et aux dimensions communiqués. Figure 3.2. Conception d un ED à partir des besoins organisationnels (selon Kimball) 38

39 Chapitre 3 : Approches de conception des projets d entreposage Travaux Les travaux s inscrivant dans ce type d approches, génèrent généralement le schéma logique de l ED à partir des sources comme Boehnlein et Moody, ou à partir des besoins comme Kimball. Boehnlein [BU99] dérive un schéma en étoile de l entrepôt à partir des schémas E/A des BDDs sources, où les attributs quantitatifs sont considérés comme mesures potentielles. Les dimensions sont choisies parmi les entités liées aux mesures et dépendant d elles. Moody [MK00] propose de développer un schéma multidimensionnel à partir des schémas E/A à travers les étapes suivantes : classer les entités en entités faits (ce sont les entités enregistrant des détails concernant des évènements particuliers) et en entités dimensions (ce sont les entités directement reliées aux entités faits par une relation (1,n)), identifier les hiérarchies qui correspondent à toute séquence d entités reliées entre elles par des relations (1,n), et raffiner le modèle obtenu. Kimball [KIM96] propose une méthode appuyant sa vision. Le schéma en étoile de l entrepôt est construit en analysant les besoins identifiés à partir des processus organisationnels, selon les étapes suivantes : - Sélectionner les processus organisationnels à analyser : un processus est défini comme activité naturelle effectuée dans l organisation qui est généralement appuyée par une source de données d un système transactionnel. - Déterminer la granularité des données à prendre en compte, i.e le niveau de détail des données à analyser qui doit être représenté dans le schéma en étoile. Il est recommandé de considérer les données de granularité très fine qui sont très détaillées et ne peuvent être divisées. Ces données dites «atomiques» peuvent être agrégées de différentes manières. - Choisir les dimensions ou axes d analyse possibles, en répondant à la question : Comment les analystes décrivent-ils les données résultantes des processus organisationnels sélectionnés? - Déterminer les tables de faits représentant l objet de l analyse pour chaque processus en répondant à la question : «que doit-on mesurer?» 39

40 Chapitre 3 : Approches de conception des projets d entreposage Analyse Cette façon de faire des approches directes implique un important travail d abstraction, et aussi une connaissance préalable du modèle multidimensionnel (faits et dimensions) par les décideurs (pour les méthodes se basant sur la vision de Kimball). De plus, le passage direct au schéma logique présente certaines limites. En effet, ces schémas : - N offrent pas un niveau d abstraction indépendant de toute problématique d implémentation o Impliquent le choix d une implémentation relationnelle o Impliquent de prendre des décisions concernant le niveau physique (normalisation des tables) - Ne permettent pas d instaurer une communication entre les concepteurs et les utilisateurs, ce qui est reconnu par plusieurs travaux et études comme un risque important de rejet du projet final [GS06]. - Omettent la détection des éventuelles erreurs de conception qui doivent être décelées et corrigées dès le départ avant le passage au modèle logique ou physique. Un autre problème important concerne l hétérogénéité des schémas des sources de données. Le concepteur doit analyser les sources de données afin de construire le schéma logique. Il se trouve ainsi devant une tâche complexe, où il doit gérer les différents conflits (syntaxiques et sémantiques) entre les données des sources. Imaginons par exemple que le décideur souhaite analyser le prix de vente d un produit selon certaines périodes, et qu au niveau des sources, on trouve les attributs Prix dans source 1, Price dans source 2 et Prix de vente dans source n. le concepteur se retrouve confronté à des questions du style : l attribut Prix désigne-t-il le prix de vente ou le prix de production? l attribut Price est-il un synonyme de l attribut Prix, l attribut Prix de vente représente-t-il le prix hors taxe ou le prix TTC? Un travail important doit être fait par le concepteur pour assigner une sémantique à ces différents concepts. Ce travail se complique davantage lorsqu on a affaire à un grand nombre de sources de données et qu il n existe aucune documentation disponible sur les sources de données. 40

41 Chapitre 3 : Approches de conception des projets d entreposage 1.2 Les approches traditionnelles Les approches traditionnelles de conception ont été proposées lorsque différentes études ont montré que le manque ou l absence d une phase de modélisation conceptuelle est une cause possible d échec des projets d entreposage [GMR98]. Ces approches s intéressent à mettre en place une vraie phase de conception lors du développement d un ED. Les premiers travaux ont proposé de concevoir un ED principalement à partir des sources de données. D autres travaux ont suivi, s inspirant de la conception des BDs, et ont mis le point sur la nécessité d inclure les besoins des utilisateurs, en plus des sources de données. Diverses études ont même été menées prouvant l importance d impliquer les besoins des utilisateurs dans la conception d un ED [GS06]. On distingue ainsi deux catégories de méthodes dans les approches traditionnelles : les méthodes orientées sources (ou approches ascendantes) et les méthodes orientées besoins (ou approches descendantes 1 ). La mise en place d une phase conceptuelle a pour but de [GOL09] : - Instaurer un dialogue entre le concepteur et les futurs utilisateurs de l entrepôt (spécialement pour les méthodes orientées besoins où les besoins utilisateurs sont modélisés et formalisés). - Fournir une base stable pour la phase de modélisation logique. - Fournir une documentation expressive et non ambiguë du processus de conception Les méthodes orientées sources Principe et travaux Les premières méthodes découlent de la définition d Inmon [INM92], qui indique que le développement d un ED repose sur les données des sources par opposition aux méthodes de développement des bases de données traditionnelles qui reposent sur les besoins des utilisateurs. Ces méthodes étendent les schémas E/A par des faits et des dimensions (Tryfona et al.), ou bien dérivent un modèle multidimensionnel de l entrepôt à partir des schémas E/A ou des schémas relationnels des sources en utilisant des règles de transformation (Golfarelli et al., Husemann). 1 Les méthodes ascendantes/descendantes est la classification que l on retrouve généralement dans la littérature. 41

42 Chapitre 3 : Approches de conception des projets d entreposage Figure 3.3. Méthodes orientées sources Tryfona et al. [TBC99] propose un modèle conceptuel d un ED nommé "starer" qui consiste à étendre un schéma E/A aux concepts de faits et de dimensions inhérents aux modèles multidimensionnels, ainsi que les différentes relations entre les niveaux de dimensions et les faits comme la spécialisation, la généralisation et l agrégation. Ce modèle est accompagné d une représentation graphique. Les faits sont représentés graphiquement par un cercle et correspondent aux sujets analysés. Les entités correspondant à un ensemble d objets du mode réel partageant les mêmes propriétés, sont représentées par un rectangle. Les relations entre les entités et les faits sont représentées par un diamant. Les cardinalités possibles de ces associations ne doivent être que de type (n,m), (m,1) ou (1,m). Des attributs peuvent être associés aux entités faits et sont représentés par des ovales. Figure 3.4. Exemple d un schéma StarER Golfarelli et al. [GMR98] proposent une méthode semi automatisée, souvent référencée par d autres travaux, pour concevoir un modèle conceptuel d un ED baptisé Dimensional Fact model (DF model) à partir des modèles E/A décrivant les BDDs sources. Le modèle conceptuel proposé consiste en un ensemble de schémas de fait (fact schemes) représentés graphiquement sous forme d un arbre dont la racine est le fait. 42

43 Chapitre 3 : Approches de conception des projets d entreposage Figure 3.5. Dimensional fact schema La construction du modèle DF est constituée de six étapes : Définir les faits (les entités et relations ayant subi le plus de modifications et de mises à jour sont considérés comme de bons candidats). Un fait peut être représenté par une ou plusieurs entités. Pour chaque fait défini, la deuxième étape consiste à construire l arbre des attributs (les attributs des entités sélectionnées comme Fait), dont la racine est l identifiant du fait et les nœuds ses attributs, affiner l arbre en éliminant les attributs les moins intéressants pour l utilisateur, définir les dimensions qui correspondent aux nœuds enfants de la racine de l arbre, définir les mesures des faits (généralement c est le nombre d instances du fait, ou bien une expression du type sum/average/maximum/minimum évalués sur les attributs de l arbre), et finalement définir les hiérarchies entre attributs. Husemann et al. [HLV00] présentent une méthode permettant de générer un schéma conceptuel d un entrepôt à partir des BDDs existantes. Le processus de conception s effectue en analysant les attributs pertinents des bases pour spécifier leur rôle (fait, mesure ou dimension). Un fait représente un élément d informations atomique. Les mesures sont représentées par des éléments quantifiant le fait, et les dimensions comme des éléments le qualifiant. Les mesures doivent respectées les contraintes d agrégation. Les hiérarchies de dimension sont définies en déterminant les dépendances fonctionnelles entre les différents niveaux de la hiérarchie. Un modèle conceptuel défini uniquement à partir des sources de données risque de ne pas être en concordance avec les attentes des décideurs d une organisation. Impliquer les décideurs qui sont les futurs utilisateurs de l entrepôt est une étape primordiale. Des travaux 43

44 Chapitre 3 : Approches de conception des projets d entreposage se sont ainsi inspirés de la philosophie des bases de données, et se sont intéressés à développer des méthodes de conception d EDs prenant en compte les besoins décisionnels Les méthodes orientées besoins utilisateurs Analyse des besoins utilisateurs dans un projet d ED De plus en plus de travaux comme [GS06], [GRG05] reconnaissent la nécessité d identifier et de modéliser les besoins des utilisateurs pour la conception d un ED. Différentes études ont en effet démontré qu 1/3 des projets d entrepôt de données échouent à atteindre leurs objectifs, principalement à cause du [GS06] : - Manque de communication entre les concepteurs et les utilisateurs (décideurs) - Une mauvaise gestion du projet On retrouve ainsi des travaux portant la formalisation des besoins d un entrepôt. La modélisation de ces besoins s effectue soit en utilisant des modèles spécifiques proposés par les auteurs mêmes comme [GS06] avec le modèle MAP, en utilisant les modèles fournis par le framework i* 1 comme [GRG05], ou en utilisant une modélisation objet comme [FIR97], [LST00], [MPS08]). 1 I* [YU97] est un framework qui repose sur les notions d agent et de but dans les différentes phases de développement d un système et permet d identifier les utilisateurs du système et les modéliser en acteurs sociaux dépendants les uns des autres à travers les buts à réaliser, les tâches à effectuer et les ressources à utiliser. La modélisation des besoins s effectue en utilisant les diagrammes d acteurs et les diagrammes rationnels fournis par le framework i*. 44

45 Chapitre 3 : Approches de conception des projets d entreposage Transfer amount record transfer amount manage bank transfres AND Transfe r a/c record transfer a/c record transfer motivation record transfer description record transfer currency Transfer motivation Transfer descriptio n Transfer date record transfer date record transfer dest. a/c Transfer destination a/c compute transfer currency Transfer currency Figure 3.6. Exemple d un diagramme rationnel du framework i* a Start By reducing cost product (1) By increasing the number of customers (2) Adjust price position b By reducing the net indebtedness (1) By selling non strategic and non profitable business (2) By improvement of financial ratios (3) Imrove profitability of International Business c Figure 3.7. Exemple d un modèle MAP [GS06] Ces besoins peuvent être exprimés sous différentes formes. L objet d analyse de ces besoins peut être les buts de l organisation, les processus de l organisation ou les besoins de chaque utilisateur cible. L analyse orientée processus (travaux de [LST00], [BLS01], [SLB02]) analyse les besoins en identifiant les processus métiers de l organisation. Un processus est décrit dans ce cas 45

46 Chapitre 3 : Approches de conception des projets d entreposage comme un ensemble structuré et mesuré d activités, permettant de fournir un produit spécifique pour un client ou un marché particulier. Un processus métier est décrit comme un ensemble d activité ordonné dans l espace et le temps (s effectuant dans un intervalle précis de temps) ayant des entrées et des sorties bien définies. Les auteurs mettent cependant le point sur le fait que l analyse des processus clés n est pas toujours faisable. La raison est que ces processus de décision se constituent souvent de tâches non structurées, de plus les décideurs refusent généralement de divulguer ce type d informations. L analyse orientée but (travaux de [FIR97], [GS06], [FS03], [BCC01], [PG03], [GRG05], [MPS08]) analyse les besoins en identifiant les buts et objectifs de l organisation. Les buts peuvent être définis comme des objectifs de haut niveau de l organisation ou du système. Ils guident les diverses décisions de différents niveaux de l entreprise. L analyse orientée utilisateurs (travaux de [BG06]) s intéresse à identifier les utilisateurs cibles et à spécifier et analyser leur besoins individuels pour les intégrer dans un modèle de besoins unifié Mapping sources / Besoins Les méthodes basées sur les besoins permettent de générer un schéma conceptuel multidimensionnel de l entrepôt en prenant en compte les besoins des décisionnels de l organisation. Les sources de données restent cependant le cœur de construction de l ED. Un mapping entre les sources et les besoins doit être effectué. Ce mapping nécessite une étape d intégration. Le mapping Sources/Besoins peut s effectuer de trois manières, que nous classons comme suit : Approche postérieure Dans cette approche, des schémas conceptuels multidimensionnels sont définis à partir des sources de données. D autres schémas conceptuels multidimensionnels sont générés à partir de l analyse des besoins. Un mapping entre ces deux ensembles de schémas est ensuite effectué afin de générer le schéma conceptuel final de l ED. Ce type de méthodes présente deux principaux inconvénients : - Le premier réside dans la possibilité de générer un nombre de schémas inutiles qui ne seront pas exploités. 46

47 Chapitre 3 : Approches de conception des projets d entreposage - Le deuxième inconvénient se présente dans la difficulté d effectuer un mapping entre les schémas. Les problèmes d hétérogénéité et donc d intégration apparaissent à deux niveaux : une intégration des sources lors de la génération du premier ensemble de schémas conceptuels ; et une intégration lors du mapping entre les schémas obtenus à partir des sources et à partir des besoins. Figure 3.8. mapping sources/besoins selon une approche postérieure Bonifati et al. [BCC01] proposent une méthode de conception orientée besoins, où le mapping Sources/Besoins se fait selon une approche postérieure. Un ensemble de schéma multidimensionnels sont dérivés à partir des buts organisationnels (en adaptant une technique GQM 1 ). Un deuxième ensemble de schémas multidimensionnels est dérivés à partir de schémas E/A des BDDs sources à travers un algorithme qui identifie les faits comme les entités ayant des attributs numériques, et les dimensions comme les entités liées aux entités Fait par une relation (1,1) ou (1,n). Une dernière étape consiste à intégrer les deux ensembles de schémas multidimensionnels en un schéma unifié. Ce mapping est effectué manuellement par le concepteur. Approche médiane Dans cette approche, un schéma conceptuel est généré à partir des sources (resp. besoins) et validé par les besoins (resp. sources). Dans ces deux cas, un inconvénient majeur réside dans l exploitation minime d une des sources d informations (sources de données ou besoins utilisateurs). 1 GQM est une technique permettant de fournir des métriques afin de mesurer des programmes. Cette technique a été adaptée afin d identifier les buts d une organisation et de les analyser, dans le but d avoir un maximum d informations sur les besoins de l organisation concernant l ED qu elle souhaite concevoir. 47

48 Chapitre 3 : Approches de conception des projets d entreposage Dans le premier cas (exp : travaux de Phipps et al.), un schéma conceptuel est défini à partir de l analyse des sources. Une étape d intégration doit être effectuée à ce niveau là. Ce schéma est ensuite validé par les besoins afin de définir le schéma conceptuel final. Cette validation est généralement effectuée manuellement par le concepteur en fin de conception. Dans le deuxième cas (exp : travaux de Giorgini et al.), un schéma conceptuel est défini à partir des besoins et est ensuite validé en analysant les sources. Cette validation nécessite une étape d intégration lors du matching entre les concepts du premier modèle conceptuel (généré à partir des besoins) et les données se trouvant au niveau des sources. Figure 3.9. mapping Sources/Besoins selon une approche médiane Phipps et al. [PD02] proposent de définir le schéma conceptuel de l ED où le mapping sources/besoins se fait selon une approche médiane. Un premier modèle multidimensionnel est généré à partir des sources de données, où les entités ayant des attributs numériques représentent des faits, leurs attributs numériques représentent des mesures, et les autres attributs (attribut non numérique, non clé et ne représentant pas une date) représentent les dimensions de ce fait. Une dimension Temps est associée à toutes les entités faits. Un ensemble de schémas multidimensionnels est généré par cet algorithme. Ces schémas sont ensuite validés et raffinés par les besoins utilisateurs formalisés par des requêtes SQL. La pertinence des schémas est évaluée selon les règles suivantes : - Si un schéma ne contient pas de tables se trouvant dans la clause From d une requête, alors ce schéma est considéré comme non pertinent pour cette requête. - Un schéma est considéré comme pertinent si les attributs numériques de son fait se trouvent dans la clause Select. 48

49 Chapitre 3 : Approches de conception des projets d entreposage Giorgini et al. [GRG05] proposent également de définir le schéma conceptuel de l ED où le mapping sources/besoins se fait selon une approche médiane. Un schéma conceptuel multidimensionnel de l entrepôt est défini à partir de l analyse des besoins (qui s effectue selon une approche orientée but). Les concepts multidimensionnels du schéma conceptuel sont ensuite mappé avec les entités des schémas relationnels des sources de données afin de les valider et de déterminer les hiérarchies de dimensions. Ce mapping est effectué manuellement par le concepteur en associant chaque fait, dimension ou mesure du schéma conceptuel à une table ou à un attribut dans les sources. Le schéma est ensuite présenté aux utilisateurs pour une deuxième validation. Approche antérieure Dans cette approche, un mapping entre les sources et les besoins est effectué en début de conception avant la génération d un schéma conceptuel intermédiaire. [ART06] recommande ce type de mapping. Confronter les besoins aux sources de données nécessite une étape d intégration, dans laquelle il faudra identifier au niveau des sources, les concepts correspondants aux concepts utilisés pour exprimer les besoins. Figure Mapping Sources/Besoins selon une approche antérieure Romero et al. [RA06] proposent de générer un schéma conceptuel de l ED selon cette approche. Les besoins utilisateurs sont exprimés sous forme de requêtes Sql sur des schémas de données relationnels. Un ensemble de schémas multidimensionnels modélisés sous forme de graphes sont générés en analysant les classes et attributs des requêtes Sql. Nous estimons, pour notre part, que la confrontation entre les sources et les besoins utilisateurs selon une approche antérieure est préférable aux autres approches. Les deux sources d informations (sources et besoins) sont autant exploitées l une que l autre, de plus elle présente un gain de temps important en évitant de générer des schémas intermédiaires possiblement inutiles. 49

50 Chapitre 3 : Approches de conception des projets d entreposage On voit bien que pour ces approches traditionnelles, le problème d intégration est toujours présent à différents stages de la conception quelque soit la méthode de conception (en début de conception pour les méthodes basées sur les sources ; et en début de conception ou pendant le mapping sources/besoins pour les méthodes impliquant les besoins). Ce problème d intégration des schémas des sources peut cacher d autres difficultés de conception comme l effort d un travail de rétro-conception (dû au fait que les bases données sources soient stockées selon leur modèle logique). 1.3 Les approches ontologiques Les ontologies ont été proposées pour résoudre ce problème d intégration inhérent à la conception d un ED. Une ontologie peut être définie comme une spécification d'une conceptualisation d'un domaine. Elle permet de décrire explicitement la sémantique des données. Dans ces approches ontologiques, on retrouve un seul et unique travail, celui de Romero et al. [RA07] qui présentent une méthode semi automatique de conception multidimensionnelle d un ED, basée sur une ontologie représentant le domaine d intérêt de l ED. Cette méthode étudie les multiplicités entre les concepts de l ontologie pour définir les concepts multidimensionnels faits et dimensions du schéma conceptuel. Ainsi, un concept de l ontologie est considéré comme un fait potentiel s il est relié à autant de dimensions et mesures que possible. Les mesures sont désignées comme les attributs numériques permettant l agrégation des données. Ils sont reliés au concept représentant le fait par une relation (1,1). Un concept de l ontologie est considéré comme dimension potentielle s il est rattaché à un fait par une relation (1,n). Les hiérarchies de dimensions sont déterminées en recherchant les relations (n,1) entre les concepts identifiés comme dimensions. Cette identification peut se faire de manière automatique. Les résultats sont ensuite présentés au concepteur qui doit les valider. 50

51 Chapitre 3 : Approches de conception des projets d entreposage Figure Approche ontologique Cette méthode présente trois principaux inconvénients : - Dans cette méthode, les auteurs proposent de gérer l hétérogénéité des sources de données en utilisant une ontologie couvrant les sources. Même si le problème d intégration est mis en avant dans cette approche, l existence d une telle ontologie intégrant ou couvrant les sources n a pas été étudiée. - Le deuxième inconvénient réside dans la présence limitée du concepteur et des utilisateurs. La tâche du concepteur se réduit à valider un schéma conceptuel généré automatiquement par un programme reposant sur les multiplicités entre les concepts ontologiques, ce qui ne donne pas toujours des résultats fiables. Les utilisateurs, également, jouent un rôle secondaire par rapport aux sources de données. Leurs besoins sont pris en compte en fin de conception, selon une approche médiane. - Un troisième inconvénient est l autonomie limitée de conception. Le schéma conceptuel de l ED est obtenu à partir d une ontologie figée qui n est pas extensible. Cette ontologie représente un domaine en général, elle ne comporte pas forcément tous les concepts locaux nécessaires aux besoins applicatifs. 2 Limites des approches existantes De l analyse de ces différents travaux de conception que l on vient d étudier, nous dégageons certaines limites : (i) la difficulté de conception, (ii) l automatisation de la démarche de construction, (iii) la difficulté d'utilisation ultérieure de l entrepôt et (iv) l intégration des données. 51

52 Chapitre 3 : Approches de conception des projets d entreposage - Difficulté de conception : cette difficulté de conception s exprime dans toutes les approches de conception. Dans les approches directes, un effort d abstraction important doit être effectué par le concepteur durant le cycle de développement de l entrepôt. Dans les approches traditionnelles, pour les méthodes orientées sources, une analyse détaillée et exhaustive des sources ne peut être possible que dans le cas où les sources sont détaillées, présentées dans des schémas de données suffisamment clairs et compréhensibles, spécialement si la méthode de génération du schéma est manuelle. On retrouve ce même problème dans les méthodes orientées besoins, en plus de la difficulté d effectuer des correspondances entre les sources et les besoins. Ce mapping Source/Besoins est généralement fait manuellement par le concepteur. Certains travaux suggèrent l utilisation d un thésaurus afin de guider le concepteur mais sans détailler davantage. Certaines méthodes présentent de plus des directives ou des étapes difficilement applicables comme par exemple un fait est une entité enregistrant des détails concernant des évènements particuliers [MK00]. - Automatisation de la démarche de construction: même si nous estimons qu une méthode de conception ne doit pas être complètement automatique (une méthode de conception n a pas pour but de remplacer un concepteur mais d interagir avec ce dernier afin de profiter de son expertise et de son savoir faire), apporter une part d automatisation peut s avérer indispensable. Dans toute méthode de conception, l analyse des sources de données passe nécessairement par une étape d intégration sémantique de ces sources. L automatisation de l intégration des sources devient nécessaire lorsqu on a affaire à un grand nombre de sources de données. une autre conséquence de cette automatisation est de faciliter l évolution de l ED par l ajout de nouvelles sources de données. - Difficulté d'utilisation ultérieure de l entrepôt de données généré : le modèle conceptuel d un ED doit permettre d'exprimer à la fois les besoins applicatifs et la connaissance du domaine sous une forme intelligible pour un utilisateur ultérieur. Malheureusement, c'est le modèle logique (issu de diverses règles de transformations comme la normalisation des tables de dimensions) qui est exploité, et qui est en général très différent du modèle conceptuel. Une part importante de la sémantique du modèle conceptuel est perdue lors de sa traduction en un modèle logique. Ainsi, l'absence de représentation du modèle conceptuel dans l ED rend l'interrogation de celui-ci très 52

53 Chapitre 3 : Approches de conception des projets d entreposage difficile même pour les utilisateurs ayant une bonne connaissance du domaine d'application. - L intégration des données : la problématique la plus importante dans toutes les méthodes citées reste, à notre avis, l intégration des données. De toutes les caractéristiques d un ED, l intégration est l aspect le plus important [INM92]. Un ED, par définition, intègre des données hétérogènes provenant de sources réparties. L intégration de ces données pose une problématique importante dûe aux conflits syntaxiques et sémantiques survenant entre les données. on a vu tout au long de ce chapitre que cette problématique est présente dans toutes les approches et méthodes de conception existantes. Ces méthodes de conception, pour la plupart, ne peuvent être appliquées que sur un schéma intégré des sources de données. Dans toutes ces méthodes, cette forte hypothèse d existence d un schéma intégré est soit complètement ignorée (approches directes, et approches traditionnelles), soit non étudiée (approche ontologique). Afin de remédier à ces difficultés, nous allons proposer une nouvelle méthode de conception à base ontologique où nous allons tenter d apporter des solutions ces principales problématiques. Nous verrons, dans le chapitre 5, l apport de notre méthode pour résoudre les limites identifiées ci-dessus. 3 Bilan L étude de l ensemble des approches de conception d EDs nous a permis de les classer en trois catégories d approches : directes, traditionnelles et ontologiques. Une problématique essentielle qui revient dans ces trois catégories est la problématique d intégration des données dûe aux différents conflits syntaxiques et sémantiques. La conception de ce schéma passe nécessairement par une phase d intégration des données. Cette tâche d intégration est toujours un exercice complexe et fastidieux. Extraire des données de plusieurs sources et les intégrer en une image unifiée est un problème complexe [INM92]. Cet exercice d intégration devient rapidement critique pour le concepteur, spécialement s il a affaire à un nombre important des sources et si, de plus, ces sources ne sont pas documentées. Pour ces trois types d approches, la construction d un ED se fait de la manière suivante : l ED est construit à partir des données stockées dans les sources opérationnelles. Il est possible de prendre en compte les besoins des décideurs et utilisateurs du futur ED, et de les 53

54 Chapitre 3 : Approches de conception des projets d entreposage confronter aux données des sources afin de développer un entrepôt répondant au mieux aux besoins de l organisation. L ensemble de ces informations (sources et besoins) permet de concevoir un modèle de données multidimensionnel permettant de développer l ED. De l analyse des méthodes de développement des EDs, on peut ainsi affirmer qu un ED dans sa construction peut être assimilé à un système d intégration (SI) intégrant les schémas des sources et les modèles des besoins, matérialisé par des concepts multidimensionnels (identification des faits et dimensions). L identification des éléments multidimensionnels peut se faire avant ou après l étape d intégration, tout dépend de la méthode de conception. Pour notre part, nous estimons qu il est préférable de gérer les problèmes d intégration dès le début de la conception, afin de faciliter le travail du concepteur et de fournir un schéma intégré sur lequel exprimer les différents besoins décisionnels. Partant de ce constat (ED = SI + couche multidimensionnelle), on juge important de se pencher sur les différentes approches d intégration existantes afin de s y inspirer pour proposer une nouvelle méthode de conception d un ED. Dans ce domaine là, les ontologies ont largement contribué dans la conception des systèmes d intégration aussi bien dans les travaux de recherche que dans des projets industriels, où elles permettent de résoudre les différents conflits (de nommage, de mesure, de contexte, etc.) rencontrés lors du processus d intégration. Nous allons dans le prochain chapitre, analyser les différentes approches et systèmes d intégration existants, et étudier les principales notions relatives aux ontologies et leur contribution dans la conception des SI. 54

55 Chapitre 4 Entrepôt de données vu comme un système d intégration Un entrepôt de données permet de fournir une plateforme uniforme aux données provenant de sources réparties et hétérogènes. Cette définition fait d un entrepôt, un cas particulier d un système d intégration. Un entrepôt de données peut, en effet, être assimilé à un système d intégration matérialisé par des concepts multidimensionnels. L intégration des sources de données représente aujourd hui un champ de recherche important dû à l explosion des sources sur le web, notamment grâce à la popularisation d Internet. L intégration des sources a ainsi pour but de fournir une interface uniforme et transparente aux données pertinentes des différentes sources via un schéma global [GIR05]. La difficulté de la tâche d intégration des sources d informations est essentiellement due à l hétérogénéité des données. Cette hétérogénéité concerne à la fois la structure et la sémantique des données. L hétérogénéité sémantique est une problématique très complexe à gérer ; elle provient du fait qu un même concept peut avoir différentes sémantiques d une source à une autre (et vice versa). Les ontologies, conçues pour assigner de la sémantique aux concepts d un domaine, sont intervenues à ce niveau, afin de gérer les différents conflits syntaxiques et sémantiques. Les ontologies sont d ailleurs considérées comme le seul artefact permettant de réconcilier des données hétérogènes au niveau sémantique [JPA07]. Leur aspect formel permet, de plus, d automatiser le processus d intégration, ce qui représente un apport très intéressant lorsqu on a affaire à un grand nombre de sources de données. Nous n avons pas l ambition de fournir dans ce chapitre un état de l art exhaustif sur ce large domaine qu est l intégration des données, mais nous allons étudier et analyser les principales approches de développement des systèmes d intégration afin de s y inspirer pour 55

56 Chapitre 4 : Entrepôt de données Vs Systèmes d intégration proposer une méthode de conception d un ED. Plus particulièrement, nous allons étudier l existence d un schéma intégrant des sources de données, qui rappelons le, est une forte hypothèse à la base de toutes les méthodes de conception proposées. Pour ce faire, nous étudierons dans un premier temps l hétérogénéité des données et les différents conflits qu elle génère. Nous présentons ensuite une classification des systèmes d intégration proposée par [NGU06] afin de nous positionner selon une approche entrepôt de données. Nous étudierons pour finir les approches d intégration à base ontologique, où nous passerons en revue les principales notions relatives aux ontologies, ainsi que leur rôle dans l intégration des sources de données. 56

57 Chapitre 4 : Entrepôt de données Vs Systèmes d intégration 1 Problématique d intégration Un système d intégration a pour but de fournir un schéma cohérent des données provenant de multiples sources d informations autonomes, réparties et hétérogènes, de manière à faciliter aux utilisateurs l accès et l interrogation de ces données, comme s ils accédaient à une seule source de données [GIR05]. Un système d intégration comporte deux parties [NGU06]: une partie externe représentée par les utilisateurs du système intégré ; et une partie interne correspondant aux sources de données et à une interface (schéma global) à travers laquelle les utilisateurs accèdent aux sources. Figure 4.1. Système d intégration des données [NGU06] 1.1 Hétérogénéité des données L hétérogénéité des sources de données est à l origine de la complexité de la tâche d intégration. Cette hétérogénéité peut être de deux natures : hétérogénéité structurelle (ou syntaxique) et hétérogénéité sémantique. L intégration des données implique l identification des conflits syntaxiques et sémantiques ensuite leur résolution. 57

58 Chapitre 4 : Entrepôt de données Vs Systèmes d intégration Hétérogénéité structurelle L hétérogénéité structurelle provient du fait que les sources de données peuvent avoir différentes structures ou différents formats de stockage. Les différences structurelles peuvent être regroupées dans différentes catégories [JEA04] : - Choix de type de données : ces conflits se posent lorsqu on utilise des types de données différents pour la même information. Par exemple, dans le domaine des transactions commerciales, la quantité d un produit est représentée par un réel dans une source S1, et par une chaîne de caractère dans une autre source S2. - Choix du nombre de constructeurs : ces conflits se présentent lorsque le nombre de constructeurs modélisant une information est différent d une source à une autre. Par exemple, l attribut nom d un client, est modélisé par un seul attribut servant à stocker le nom et le prénom d un client dans une source S1, alors que deux attributs sont utilisés dans une autre source 2. - Choix des informations représentées : ces conflits se posent lorsqu une information est représentée dans des sources alors qu elle ne l est pas dans d autres. Par exemple, l adresse d un client n est pas connue pour tous les clients d une source S1, alors que c est une donnée obligatoire dans une source S Hétérogénéité sémantique L hétérogénéité sémantique représente une problématique plus difficile à gérer. Elle provient du fait que les sources sont conçues par différents concepteurs, qui ont des objectifs applicatifs différents, et ne partagent donc pas forcément la même sémantique des mêmes concepts [NGU06]. Les conflits sémantiques peuvent être de différentes natures. [GBM99] distinguent les trois types de conflits sémantiques suivants : conflits de noms, conflits de contextes et conflit de mesures. - Conflits de noms : Les conflits de noms se produisent lorsqu on utilise soit des noms différents pour le même concept ou propriété (synonyme), ou plus rarement des noms identiques pour des concepts différents (homonyme). 58

59 Chapitre 4 : Entrepôt de données Vs Systèmes d intégration Un simple exemple se produit si l on trouve le concept Produit dans la source S1, et Article dans la source S2, alors que les deux concepts portent le même sens dans les deux sources. Ou dans un autre cas, on retrouve l attribut Prix dans les deux sources, mais qu il signifie le prix de vente d un produit dans la source S1, et le prix de production d un produit dans la source S2. - Conflits de contextes : Les conflits de contexte se produisent lorsque des concepts semblent avoir la même signification, mais ils sont évalués dans différents contextes. Par exemple, la propriété Prix ne s applique que pour les produits neufs dans la source S1, alors qu elle est appliquée pour tous les produits dans la source S2. - Conflits de mesures : Les conflits de mesures ou de valeurs se trouvent dans le cas où des unités de mesure différentes ont été utilisées pour mesurer certaines propriétés de certains concepts. Par exemple, la valeur de l attribut prix d un produit est calculée en dinars dans la source S1, et elle est calculée en euros dans la source S2. Figure 4.2. Hétérogénéité sémantique des données [INM92] 59

60 Chapitre 4 : Entrepôt de données Vs Systèmes d intégration 2 Classification des approches d intégration On s appuie dans ce qui suit sur la classification des approches d intégration proposée par [NGU06] qui classifie ces approches selon les trois critères orthogonaux suivants : (1) la représentation des données intégrées, (2) le sens de mise en correspondance entre schéma global et schémas locaux, et (3) la nature du processus d intégration. 2.1 La représentation des données intégrées Ce critère permet de distinguer les approches d intégration selon la manière dont elles stockent les données. On distingue ainsi : l approche virtuelle et l approche matérialisée Approche virtuelle L approche virtuelle stocke les données uniquement au niveau des sources. Les systèmes d intégration construits selon cette approche, appelés systèmes médiateurs, reposent sur deux composants : le médiateur dont le rôle est de localiser les données pertinentes à une requête d utilisateur, et l adaptateur dont le rôle est d accéder au contenu de ces sources. Figure 4.3. Intégration virtuelle [GIR05] 60

61 Chapitre 4 : Entrepôt de données Vs Systèmes d intégration Une requête d utilisateur est formulée selon le schéma global du médiateur. Des vues abstraites décrivent le contenu de chaque source dans les termes du médiateur. Le médiateur sélectionne les sources pertinentes pour la requête en utilisant ces vues. La requête doit être reformulée afin qu elle puisse être évaluée sur les sources pertinentes (c est ce qu on appelle réécriture des requêtes). Le résultat de cette réécriture est un ensemble de sous requêtes posées sur les sources. Les adaptateurs, contenant les correspondances entre les données du schéma global et ceux des sources, traduisent les sous requêtes dans le langage spécifique de chaque source. Plusieurs systèmes d intégration ont été développés selon cette approche : projets Tsimmis [CGH94], Projet Padoue [LUM05], Projet Picsel [GIR05] Approche matérialisée L approche matérialisée transfère les données des sources au niveau d un entrepôt (il ya donc duplication des données). L interrogation des données se fait directement sur les données de l entrepôt et non sur les sources d origine. La conception d un système d intégration selon une architecture matérialisée est similaire à celle d un entrepôt de données [GIR05]. Certaines entreprises, pour des raisons de sécurité, préfèrent opter pour une solution d ED, même si cela implique un coût de stockage et de maintenance des données. Quelques systèmes d intégration ont été développés selon l approche matérialisée comme le projet américain WHIPS [HGW95], le projet européen DWQ (Data Warehouse Quality) [JV97] et le projet français OntoDawa [NGU06]. 61

62 Chapitre 4 : Entrepôt de données Vs Systèmes d intégration Figure 4.4. Intégration matérialisée [NGU06] Il apparaît clairement que le développement d un entrepôt de données suit une approche matérialisée. On se positionne ainsi pour ce premier critère dans une approche matérialisée. 2.2 Le sens de mise en correspondance entre schéma global et schémas locaux Ce critère permet de distinguer les approches d intégration selon la liaison entre le schéma global et les schémas locaux des sources à intégrer. On distingue pour ce critère deux approches : GaV (Global as View) et LaV (Local as View) Approche GaV L approche GaV définit le schéma global en fonction des schémas des sources (schéma locaux). Chaque schéma (local ou global) est défini comme étant un ensemble de relations. Les relations globales sont définies comme des vues sur les relations des schémas locaux 62

63 Chapitre 4 : Entrepôt de données Vs Systèmes d intégration Parmi les systèmes utilisant l approche GaV, on peut citer les systèmes TSIMMIS [CGH94], Momis [BBC00], et Whips [HGW95] Approche LaV L approche LaV est l approche duale de GaV. Elle définit les schémas des sources à intégrer en fonction du schéma global. Les relations des schémas des sources (relations locales) sont définies comme des vues sur les relations globales. Parmi les systèmes utilisant l approche LaV, on peut citer les systèmes InfoMaster [GKD97], Picsel [GIR05], et Information Manifold [LRO96]. Figure 4.5. Approches GaV et LaV Ce deuxième critère est important pour deux problématiques : la réécriture des requêtes (réécriture des requêtes utilisateurs sur les sources et construction de la réponse) et la scalabilité du système d intégration (ajout ou suppression de sources de données) [NGU06]. L approche GaV facilite la réécriture des requêtes mais l approche LaV est plus intéressante pour assurer la scalabilité du système d intégration. En effet, une requête utilisateur s exprime en termes des relations du schéma global, sa réécriture en fonction des schémas des sources, dans une approche GaV, nécessite un simple 63

64 Chapitre 4 : Entrepôt de données Vs Systèmes d intégration dépliement des relations utilisées dans la requête par leurs définitions locales. Cette réécriture, dans une approche LaV, devient un problème complexe nécessitant des inférences [BEL07]. D autre part, l ajout d une nouvelle source de données, pouvant nécessiter une mise à jour du schéma global dans une approche GaV, est facilité dans une approche LaV. Seules les vues des nouvelles sources doivent être rajoutées (sous réserve que le schéma global ait été bien défini initialement). 2.3 La nature du processus d intégration Ce dernier critère permet de distinguer les approches d intégration selon le degré d automaticité du processus d intégration. Notons que cette automaticité concerne la résolution ou l élimination des conflits sémantiques entre les sources durant le processus d intégration. On distingue les approches manuelles, semi-automatiques et automatiques Les approches manuelles Les premières approches proposées étaient des approches manuelles. Ces approches permettent d automatiser l intégration des données au niveau syntaxique. Les conflits sémantiques sont gérés manuellement et nécessitent la présence d un expert humain pour interpréter la sémantique des données. Plusieurs systèmes ont été développés selon cette approche comme les systèmes multi-bases de données 1, la fédération des bases de données 2, le système Tsimmis [CGH94]. Ces approches manuelles deviennent impraticables lorsque le nombre de sources de données à intégrer est important, ou lorsque les sources évoluent fréquemment. 1 Un système multi bases de données vise à construire un système d accès à de multiples bases de données. L utilisateur spécifie sa requête textuellement en précisant les sources interrogées. Toutes les hétérogénéités sont traitées par l utilisateur [NGU06]. 2 La fédération des bases de données vise à fournir un schéma global représenté par l union de toutes les bases de données. Des schémas externes sont définis pour chaque BDD, qui seront ensuite convertis en un formalisme commun (relationnel par exemple), et intégrés dans un schéma global. La construction du schéma global est faite manuellement [NGU06]. 64

65 Chapitre 4 : Entrepôt de données Vs Systèmes d intégration Les approches semi-automatiques Afin d apporter plus d automatisation dans la résolution des conflits sémantiques, plusieurs travaux se sont tournés vers les ontologies. Une ontologie permet de fournir la sémantique des concepts d un domaine de manière formelle. Les approches semi-automatiques reposent sur des ontologies linguistiques 1 et permettent d automatiser partiellement la gestion des conflits sémantiques. Les ontologies linguistiques traitent des termes, et non des concepts. Ceci peut créer des conflits de noms. Momis [BBC00] est un exemple de projet reposant sur l ontologie linguistique Wordnet 2 pour l intégration des sources Les approches automatiques Les approches automatiques consistent à associer aux données des sources une ontologie conceptuelle qui en définit le sens. Une ontologie conceptuelle traite les concepts d un domaine donné. Elle est définit comme «une spécification formelle et explicite d'une conceptualisation partagée d'un domaine de connaissance» [GRU95]. La sémantique du domaine est ainsi spécifiée formellement à travers des concepts, leurs propriétés ainsi que les relations entre les concepts. La référence à une ontologie permet d éliminer automatiquement les conflits sémantiques entre les sources. La connexion entre les sources et les ontologies peut se faire de plusieurs manières [WVV01] : définition des termes de la BD par les concepts ontologiques (Projet Buster [SWV00]), annotation des données (Projet SHOE [HHL99]), enrichissement de la source par des règles logiques (logique de description) (Projet Picsel [GLR99]) 1 Une ontologie linguistique définit le sens des mots utilisés dans un domaine d étude. Ces mots sont essentiellement liés par des relations linguistiques telles que la synonymie, l antinomie, l hyperonymie, etc. 2 Wordnet est une base de données lexicale développée par des linguistes du laboratoire des sciences cognitives de l'université de Princeton ( 65

66 Chapitre 4 : Entrepôt de données Vs Systèmes d intégration Figure 4.6. Intégration des sources à base d ontologies 2.4 Quel type de système d intégration voulons-nous concevoir? Constatant qu un ED peut être assimilé à un système d intégration, nous souhaitons savoir quel type de système d intégration correspond l entrepôt à concevoir. Ce tour d horizon des différentes approches d intégration selon les trois critères définis par [NGU06] nous permet de positionner la manière d effectuer l étape d intégration dans une méthode de conception d un ED. Les différentes approches de conception d un ED qu on a citées au chapitre 2 (directes et traditionnelles) sont applicables sur un schéma intégré des sources de données. Ce schéma intégré ne comporte pas la sémantique des données qu il représente. La construction de ce schéma correspond ainsi à la configuration (ED - GaV ou LaV- Manuelle ou semiautomatique). On se place pour notre travail dans le cas d une approche matérialisée (entrepôt de données). On souhaite effectuer une intégration sémantique de manière automatique. On s intéresse donc aux approches à base d ontologies conceptuelles. Ceci correspond à la configuration (ED - GaV ou LaV - Automatique). Un entrepôt de données peut être construit selon une approche GaV ou LaV. Ce deuxième critère (GaV-LaV) est pertinent pour deux problématiques (réécriture des requêtes et scalabilité du système). Le problème de réécriture des requêtes ne se pose pas dans le cas 66

67 Chapitre 4 : Entrepôt de données Vs Systèmes d intégration d une approche matérialisée, puisque l interrogation des données se fait directement sur l ED. Le problème de scalabilité peut être limité si le schéma global est défini de manière à couvrir l ensemble du domaine (ontologie). Ce deuxième critère est donc peu pertinent pour notre problématique. Représentation des données Automaticité d intégration sémantique Sens correspondance entre schémas Figure 4.7. Le système d intégration à concevoir Le troisième critère (intégration automatique à l aide d ontologies conceptuelles) nécessite davantage de détails. Une intégration des données selon une approche à base d ontologies revient à une intégration d ontologies (Définir une ontologie intégrante). On s intéresse dans ce qui suit à présenter quelques notions sur les ontologies, et à l intégration à base ontologique. 3 Notions sur les ontologies Dans cette section, nous présentons les principales notions relatives aux ontologies. Nous définissons le concept d ontologie, nous comparons les ontologies aux modèles conceptuels, et nous présentons une classification des ontologies ainsi que les principaux langages permettant leur définition. L ontologie est une technologie informatique appartenant au champ de l ingénierie des connaissances. Apparue dans les années 80, cette technologie a suscité l intérêt de la communauté scientifique. 67

68 Chapitre 4 : Entrepôt de données Vs Systèmes d intégration 3.1 Définition d une ontologie Plusieurs définitions d ontologies ont été proposées. Nous retenons ici la définition de [JPA07], qui définit l ontologie comme «une représentation formelle, explicite, référençable et consensuelle de l ensemble des concepts partagés d un domaine sous forme de classes, de propriétés et de relations qui les lient». Les termes les plus importants dans cette définition sont donc : - Formelle : l ontologie est définie dans un langage traitable par machine. - Explicite : l ensemble des concepts et propriétés d une ontologie sont spécifiés explicitement indépendamment d un point de vue particulier ou d un contexte implicite. - Référençable : signifie que tout concept de l ontologie peut être référencé de manière unique afin d expliciter la sémantique de l élément référençant. - Consensuelle : signifie que l ontologie est admise et acceptée par l ensemble des acteurs d une communauté. 3.2 Les notions clés dans une ontologie Même si les modèles d ontologies peuvent différer, ils reposent tous sur les mêmes notions qui sont : les concepts d un domaine modélisés par les classes et leurs attributs, les relations entre ces concepts, et les axiomes. Le concept : un concept peut se définir comme une entité composée de trois éléments distincts : o Le terme : exprimant le concept en langage naturel. o Notion ou intension du concept : la signification du concept. o Les objets dénotés par le concept, appelés également «réalisations» ou «extensions» du concept. Prenons l exemple du concept VOITURE. Le terme de ce concept est le nom commun voiture. Sa notion est d être un véhicule de transport à roues. Son extension est l ensemble des marques de voitures existantes (Renault, Kia ). Les concepts d une ontologie peuvent être classés en deux catégories [GRU95]: 68

69 Chapitre 4 : Entrepôt de données Vs Systèmes d intégration o Les concepts primitifs : ce sont les concepts de base à partir desquels d autres concepts de l ontologie peuvent être définis. Ces sont des concepts dont l ontologie ne fournit pas de définitions complètes. Leurs définitions reposent sur une documentation textuelle ou sur un savoir partagé par les membres d une communauté. o Les concepts définis : ce sont les concepts définis par une définition complète, i.e par des conditions nécessaires et suffisantes exprimées en termes d autres concepts (primitifs ou définis). Les classes : elles représentent le centre d intérêt de l ontologie et décrivent les concepts d un domaine. Une classe peut avoir des sous-classes qui représentent des concepts plus spécifiques que la super classe (ou classe supérieure). Une classe peut avoir des instances. Ces instances sont des entités réelles de cette classe, elles sont une représentation des extensions du concept. Exemple : Renault est une instance de la classe Voiture. Il est à noter qu une ontologie ainsi que l ensemble des instances de toutes ses classes constituent une base de connaissances. Les attributs : Les attributs décrivent les propriétés des classes et des instances de l ontologie. Les relations : désignent les associations prédéfinies qui existent entre les concepts de l ontologie, comme la relation de subsomption «is-a» ou «est-un» (sous classe d une classe). Les axiomes : désignent les assertions acceptées comme vraies dans le domaine étudié. Les axiomes et les règles permettent de vérifier la cohérence d une ontologie, et aussi d inférer de nouvelles connaissances. Exemple : «Si deux personnes sont frères, alors il existe quelqu un qui est la mère de chacun d eux». 3.3 Formalisation d une ontologie Une ontologie a été définie de manière formelle par le 4-tuples suivants : O : <C, P, Sub, Applic>, tel que [FBD08]: - C : l ensemble des classes utilisées pour décrire les concepts d un domaine donné. 69

70 Chapitre 4 : Entrepôt de données Vs Systèmes d intégration - P : l ensemble des propriétés utilisées pour décrire les instances des classes de C. - Sub : C 2 C, fonction de subsomption qui associe à chaque classe Ci ses classes subsumées directes. Notons que C1 subsume C2 ssi x C1, x C2. - Applic : C 2 P, fonction qui associe à chaque classe de l ontologie, les propriétés applicables à chaque instance de cette classe. 3.4 Domaines d émergence des ontologies Les ontologies ont été utilisées durant ces dix dernières années à différentes fins dans plusieurs domaines comme le traitement du langage naturel, l interopérabilité des logiciels, le web sémantique, et conception des bases de données [JEA07] : Dans le domaine du traitement automatique du langage naturel, la sémantique apportée par les ontologies permet la résolution des plusieurs problèmes lors de l analyse syntaxique et sémantique d un texte (polysémie, synonymie, ). Pour l interopérabilité des systèmes, les ontologies peuvent permettre de faire interagir des logiciels d un même domaine. Dans un logiciel, un lien formel existe entre le code de l application, et le modèle à partir duquel est généré ce code. Grâce à l aspect consensuel des ontologies, différents modèles d un même domaine définis pour plusieurs logiciels peuvent être liés à une ontologie de domaine, ce qui permet de faire interagir ces logiciels. Cette approche est appelée «ingénierie logicielle dirigée par les ontologies» [JEA07]. Dans le domaine du web sémantique, les ontologies sont utilisées pour indexer les services disponibles sur le réseau Internet. Un même service peut être décrit par plusieurs noms différents attribués par des créateurs de services différents, ce qui rend difficile pour un utilisateur débutant ou même expérimenté la recherche de ces services. L utilisation d ontologies de domaine pour décrire ces services, contribue à rendre la recherche automatisable et réalisable par des agents logiciels [JEA07]. Dans le domaine des bases de données, les ontologies ont été utilisées pour : - L échange des données : une des caractéristiques des ontologies est qu elle est référençable, ce qui signifie que tout concept de l ontologie peut être identifié de manière unique. Ainsi, pour des bases de données référençant une ontologie, la 70

71 Chapitre 4 : Entrepôt de données Vs Systèmes d intégration signification de chaque élément d information peut être définie localement en référençant des identifiants de concepts d une ontologie, ce qui facilite considérablement l échange de données entre ces bases. - La conception des BDDs : une ontologie étant une conceptualisation d un domaine de connaissances, elle peut être utilisée comme une base pour la conception d une BDD. Plusieurs travaux ont ainsi exploité les ontologies comme premier niveau de spécification d un modèle conceptuel d une BDD comme les travaux de [SS06] ou [FBD08]. Nous analysons dans la section qui suit la contribution des ontologies dans une démarche de modélisation conceptuelle. 3.5 Ontologies et modèles conceptuels Les ontologies présentent des similitudes aux modèles conceptuels classiques sur le principe de la modélisation car tous deux définissent une conceptualisation de l univers du discours au moyen d un ensemble de classes associées à des propriétés [FBD08]. Les ontologies et les modèles conceptuels divergent cependant sur un point essentiel qui est l objectif de modélisation, qui est à la base de la contribution que peut apporter une ontologie pour un modèle conceptuel. Une ontologie est ainsi construite selon une approche descriptive, par contre un modèle conceptuel est construit selon une approche prescriptive. Cette approche prescriptive a plusieurs implications [JEA04] : - Seules les données pertinentes pour l application cible sont décrites. - Les données doivent respecter les définitions et contraintes définies dans le modèle conceptuel - Aucun fait n est inconnu : c est l hypothèse du monde fermé - La conceptualisation est faite selon le point de vue des concepteurs et avec leurs conventions - Le modèle conceptuel est optimisé pour l application cible Ces caractéristiques, dûes au fait qu un modèle conceptuel dépend fortement du contexte dans lequel il a été conçu, sont d ailleurs à l origine des hétérogénéités entre les schémas des BDDs, qui rendent leur intégration difficile. 71

72 Chapitre 4 : Entrepôt de données Vs Systèmes d intégration Contrairement à un modèle conceptuel qui prescrit une base de données selon des besoins applicatifs (orienté application), une ontologie est développée selon une approche descriptive. Elle permet de décrire les concepts et propriétés d un domaine donné indépendamment de tout contexte mise à part le domaine sur lequel porte l ontologie, et de tout objectif applicatif (orientée domaine). A la lumière de ces différences, il est par conséquent intéressant de considérer une ontologie comme premier niveau de spécification d un modèle conceptuel. Dans le domaine des bases de données, trois principaux travaux récemment proposés par Roldan-Garcia et al. [RNA05], Sugumaran et al. [SS06] et Fankam et al. [FBD08] ; permettent de définir le MCD (modèle conceptuel des données) d une base à partir d une ontologie supposée préexistante. Roldan-Garcia et al. [RNA05] ébauchent une méthodologie de conception passant par deux étapes : - L extension si besoin de l ontologie de domaine par de nouveaux concepts et propriétés, nécessaires pour l application à mettre en œuvre. - L extraction d un sous ensemble de classe de cette ontologie, représentant le modèle conceptuel de la BD. Sugumaran et al. [SS06] propose une méthode et un outil d aide à la conception reposant sur une ontologie linguistique. Ainsi, le système analyse les termes d une expression en langage naturel du cahier des charges, et par référence à l ontologie linguistique, suggère différents éléments à introduire dans le modèle conceptuel. Les auteurs proposent également d ajouter à l ontologie des contraintes d intégrité existentielles permettant de valider le modèle conceptuel. Par exemple la contrainte ontologique prerequisite liant le terme acheteur au terme article à vendre. Si le MCD possède la notion d acheteur et pas celle d article, le système propose de compléter le modèle par une entité article. Ce travail contribue à faciliter la tâche de conception de manière significative, mais aucun mécanisme pour étendre ou spécialiser l ontologie existante afin de répondre aux besoins applicatifs cibles. Fankam et al. [FBD08] propose une méthode de conception de BD nommée SISRO (Spécialisation, Importation Sélective et Représentation des Ontologies). Cette méthode se base sur la sélection d une ontologie conceptuelle supposée existante couvrant le domaine de 72

73 Chapitre 4 : Entrepôt de données Vs Systèmes d intégration la base à concevoir. Cette ontologie peut être étendue manuellement par de nouveaux concepts ou propriétés. Le concepteur sélectionne un sous ensemble de cette ontologie considéré comme modèle conceptuel de la base, qui sera traduit en modèle logique puis physique. Cette méthode s inscrit dans la même démarche que la méthode proposée par Roldan-Garcia et al. [RNA05], mais conserve en plus les correspondances entre l ontologie et le MCD généré. De la même manière que pour les BDDs, les ontologies peuvent également être exploitées pour la conception des EDs. On s inspire d ailleurs des méthodes de conception des BDDs à base d ontologies, dans la méthode de conception d ED que nous proposons, et que allons présenter dans le chapitre suivant. 3.6 Taxonomie des ontologies Avec l émergence des ontologies dans plusieurs domaines, la notion d ontologie a été utilisée par plusieurs communautés de recherche. Initialement utilisée par la communauté de l intelligence artificielle pour la gestion des connaissances, les ontologies ont ensuite été exploitées dans le domaine de la linguistique et celui des bases de données. L usage des ontologies diffère d une communauté à une autre selon la manière de conceptualiser un domaine. Dans le domaine de la linguistique, les ontologies décrivent et manipulent des mots et les relations entre ces mots tels que les similarités et l antonymie. Ces ontologies sont dites ontologies linguistiques (OL). Dans les deux autres communautés, on s intéresse aux ontologies dites «conceptuelles» qui manipulent des concepts et non des mots. Dans le domaine des bases de données, on s intéresse aux concepts primitifs (qui ne peuvent être dérivés d autres concepts). Ces concepts, possédant une représentation unique, sont utiles pour la conception des BDs où les redondances sont exclues, et également dans les formats d échange où il doit exister une seule représentation possible pour chaque information échangée. Les ontologies ne contenant que des concepts primitifs sont appelées ontologies conceptuelles canoniques (OCC) [JPA07]. Par exemple, on peut considérer une OCC avec une classe Personne caractérisée par deux propriétés Nom et Sexe (masculin ou féminin). Dans l intelligence artificielle, et afin d avoir la possibilité de faire des déductions, on s intéresse aux concepts définis. Ces concepts sont exprimés en utilisant d autres concepts 73

74 Chapitre 4 : Entrepôt de données Vs Systèmes d intégration (primitifs ou définis) par des relations d équivalence entre concepts. Ces relations peuvent être des relations entre classes appelées opérateurs de classes comme les opérateurs orientés ensembles (comme l union, l intersection et la différence) et les opérateurs de restrictions sur les valeurs de propriétés (comme les cardinalités des propriétés et les quantificateurs universel et existentiel appliqués sur des propriétés). Elles peuvent également être des relations entre propriétés, appelés opérateurs de propriétés, tels que les relations algébriques ou logiques (propriétés transitives, symétriques ) [NGU06]. Les ontologies contenant des concepts primitifs et définis sont appelées ontologies conceptuelles non canoniques (OCNC) [JPA07]. En reprenant l exemple précédent du concept primitif Personne, qu on spécialise par les deux concepts définis Homme (Personne de sexe masculin) et Femme (Personne de sexe féminin), constituent les concepts d une OCNC. L usage fait des ontologies par ces trois communautés (sans vouloir dire que ces catégories d ontologies sont réservées à une seule communauté particulière) permet ainsi de les classer selon la taxonomie proposée par [JPA07] illustrée par le modèle en couches suivant : Figure 4.8. Modèle en oignon [FJP09] 74

75 Chapitre 4 : Entrepôt de données Vs Systèmes d intégration Ce modèle, appelé modèle en oignon représente les trois catégories d ontologies. La base de ce modèle est formée par les ontologies OCC qui fournissent une base formelle pour modéliser et échanger les connaissances d un domaine. Une deuxième couche est formée par les OCNC, qui fournissent des mécanismes permettant de représenter les connaissances d un domaine par différentes conceptualisations. La dernière couche est formée par les OL qui fournissent une représentation des concepts d un domaine en termes de langage naturel éventuellement dans plusieurs langues possibles. Cette classification des ontologies nous est utile afin de bien cerner les ontologies que nous allons exploiter dans la méthode de conception que nous allons proposer. L étude des approches d intégration nous a permis de constater qu une intégration sémantique automatique n est possible qu en utilisant des ontologies conceptuelles. Par rapport au modèle en oignon, on se positionne dans la deuxième et troisième couche, et on considère les ontologies conceptuelles canoniques et non canoniques. Les OCC permettent en effet, de fournir une base formelle pour l échange des données entre plusieurs sources ; et les opérateurs des OCNC permettent de lier différentes ontologies et de représenter les concepts définis comme des vues sur les concepts primitifs. Certains projets d intégration utilisent des OCC pour construire leurs ontologies, tels que les systèmes d intégration OntoDawa [NGU06]. D autres systèmes comme OBSERVER [MKS96] et SHOE [HHL99] utilisent des OCNC. 3.7 Les langages d ontologies Plusieurs langages d ontologies ont été développés ces dernières années. On distingue les modèles d ontologies supportant la définition des concepts primitifs uniquement (OCC) comme le modèle PLIB [PIE02] développé pour le domaine de l ingénierie ; et ceux supportant la définition des concepts définis (OCNC) comme les langages du web sémantique RDF, RDF Schema, DAML+OIL et OWL. PLIB PLIB a été conçu initialement afin de caractériser de manière précise les produits du domaine technique. Partant du constat qu on ne peut définir de nouveaux termes qu à partir de termes primitifs, et que les termes primitifs d un domaine technique sont eux-mêmes très 75

76 Chapitre 4 : Entrepôt de données Vs Systèmes d intégration nombreux et difficiles à appréhender, l objectif essentiel d une ontologie PLIB est de définir, de la façon la plus précise et la plus concise possible, les catégories et propriétés primitives qui caractérisent les objets d'un domaine du monde réel [PIE02]. Ce modèle permet ainsi de créer des ontologies conceptuelles canoniques en utilisant les constructeurs proposés. Une ontologie PLIB permet la définition de classes, de propriétés, de domaine de valeurs et d instances, et permet également de définir la hiérarchisation des classes et des propriétés. L ensemble de ces concepts sont identifiés de manière unique par un GUI (Globally Unique Identifier). Resource Description Framework (RDF) L information sur le Web étant compréhensible au niveau lexical syntaxique seulement, les outils logiciels indépendants ne sont pas en mesure de traiter l information en l absence des méta-informations 1. Ceci a amené le W3C (World Wide Web Consortium) à élaborer une couche supplémentaire au dessus de XML (extensible Markup Language) appelée Ressource Description Framework (RDF) pour traiter ces métas informations. Le W3C a développé RDF, un langage d'encodage de la connaissance sur les pages Web pour rendre cette connaissance compréhensible aux agents électroniques qui effectuent des recherches d'informations. RDF permet de décrire des ressources simplement et sans ambiguïté. Toute ressource est décrite par des phrases minimales, composées d'un sujet, d'un verbe et d'un complément, on parle alors de déclaration RDF. RDF Schema (RDF(S)) Le langage RDF n introduit que très peu de prédicats prédéfinis, il ne propose pas de constructeurs pour la conception d ontologies. Il a donc été étendu par de nouveaux constructeurs pour permettre la définition d ontologies, ce qui a donné lieu au modèle RDF(S). RDF(S) est un des piliers du web sémantique car il permet de bâtir des concepts, définis par rapport à d'autres concepts, ayant la particularité d'être partagés à travers le web. RDF(S) permet de définir des vocabulaires. Il définit la connaissance d un domaine sous forme de classes, de sous classes, d instance de classes et de relations entre les classes. Ce 1 Une méta-information est une information complémentaire d une autre information permettant le traitement de cette dernière par un outil logiciel indépendant. Celui qui fournit la méta information est le même qui produit l information traitée. 76

77 Chapitre 4 : Entrepôt de données Vs Systèmes d intégration langage est cependant limité et ne permet que la description des vocabulaires simples (pas de cardinalités, deux classes ne peuvent pas avoir des instances communes, pas de liens précis entre les classes et entre les propriétés ). Pour des vocabulaires plus complexes, on s est tourné vers DAML+OIL ou OWL. DAML+OIL (DARPA Agent Markup Language + Ontology Inference Layer) DAML+OIL a été crée suite à la fusion de deux travaux d équipes de recherche qui sont : DARPA Agent Markup Language (DAML) du ministère de la défense américain, et Ontology Inference Layer (OIL) développé par la communauté de recherche européenne. DAML est un langage de représentation qui fournit une sémantique formelle pour l information ce qui permet l exploitation de cette information par un ordinateur. OIL a enrichi RDF(S) en offrant de nouvelles primitives permettant de définir les classes comme l union de classes, l intersection de classes et le complémentaire d une classe. La fusion des deux langages a donné lieu à DAML+OIL, écrit en RDF, permettant d enrichir le pouvoir d expression de RDF(S). Le W3C a utilisé le DAML+OIL comme base à la construction de son propre langage d ontologies : le langage OWL. OWL (Ontology Web Language) OWL est un langage de description d ontologies conçu au départ pour la publication et le partage d ontologies sur le web sémantique. Il définit un vocabulaire riche pour la description d'ontologies complexes. Issu des logiques de description, OWL est basé sur une sémantique formelle définie par une syntaxe rigoureuse. Il dispose de fonctions facilitant la réutilisation d autres ontologies et permet de définir des rapports complexes entre les ressources. Il intègre par exemple des outils de comparaison des propriétés et des classes comme l identité, l équivalence, contraire, cardinalité, symétrie, transitivité, disjonction, etc. Cette revue des différents langages d ontologies nous a permis d étudier les caractéristiques et spécificités de ces langages. Le langage d ontologies sur lequel se base notre méthode de conception est le langage OWL. Ce choix est principalement motivé par le fait qu OWL est un langage très répandu, permettant de définir des OCC et des OCNC, qui est rapidement devenu le standard le plus utilisé, et qui de plus possède un caractère descriptif assez riche que l on peut exploiter pour raffiner le modèle conceptuel obtenu. Davantage de détails concernant le langage OWL sont fournis dans l annexe 1. 77

78 Chapitre 4 : Entrepôt de données Vs Systèmes d intégration Les principales notions relatives aux ontologies étant acquises à ce niveau, nous étudions dans la section suivante la contribution des ontologies conceptuelles comme schémas intégrant les sources de données. 4 Les ontologies, schémas intégrant des sources de données La classification des approches d intégration (Section 2), nous a permis de préciser quel type de système d intégration nous voulons concevoir et de nous positionner dans la configuration (ED- GaV ou LaV- automatique). Le troisième critère (automaticité de l intégration) nécessite d être détaillé davantage. Nous avons vu que la clé de l automatisation de l intégration sémantique est l utilisation des ontologies conceptuelles. Nous allons étudier dans cette section les différentes configurations possibles d existence d une ontologie 1 couvrant un ensemble de sources de données. Deux structures principales sont utilisées dans un système d intégration à base ontologique : (1) structure à base d une ontologie unique, et (2) structure à base d ontologies multiples [BNP06]. Figure 4.9. Approches d intégration à base d ontologies conceptuelles Dans les approches à base d une seule ontologie, chaque source de données est liée à une unique ontologie (Projets OntoBroker, SIMS, COIN, Picsel ). Ces approches peuvent être utilisées uniquement lorsque les sources à intégrer fournissent globalement la même vue du domaine, autrement il sera difficile de trouver un vocabulaire minimal commun partagé entre 1 Nous utiliserons dans cette section le terme ontologie pour désigner les ontologies conceptuelles. 78

79 Chapitre 4 : Entrepôt de données Vs Systèmes d intégration les sources. De plus, des changements au niveau des sources peuvent affecter la conceptualisation du domaine représenté par l ontologie [WVV01]. Les sources de données ne peuvent alors évoluer indépendamment, leur autonomie schématique 1 est donc restreinte. Un autre inconvénient est que la scalabilité du système d intégration est limitée par la portée de l ontologie (ajouter de nouvelles sources peut nécessiter la redéfinition de l ontologie globale). Les approches à base d ontologies multiples ont été proposées pour gérer ces inconvénients. Dans ces approches, on retrouve les notions d ontologie globale et d ontologies locales. Chaque source est décrite sémantiquement par sa propre ontologie, qu on appelle ontologie locale. Afin de faciliter le mapping entre les ontologies locales, elles sont mises en correspondance avec une ontologie partagée modélisant un domaine particulier, qu on appelle ontologie globale. L intégration dans ces approches passe par trois étapes [NGU06]: - Associer à chaque source son ontologie locale. - Intégrer les ontologies des sources en établissant des relations sémantiques (équivalence, subsomption ) entre leurs concepts. - Peupler les données dans l entrepôt en exploitant les correspondances ontologiques établies dans l étape précédente. La mise en correspondance (ou l alignement) entre les ontologies locales et l ontologie globale (étape 2), permet d identifier les relations entre les entités des différentes ontologies. Cet alignement peut se faire par plusieurs techniques : terminologiques (basées sur les chaînes de caractères ou sur des connaissances linguistiques), linguistiques (basées sur les propriétés morphologiques et syntaxiques des termes ou sur des ressources externes comme les dictionnaires), structurelles (basées sur les attributs des entités ou sur les relations de subsomption entre les entités), extensionnelles (basées sur les instances des concepts), ou sémantiques (en utilisant une ontologie intermédiaire définissant un contexte commun) [GHO09]. 1 L autonomie schématique d une source de données est sa capacité à faire évoluer son schéma local indépendamment. 79

80 Chapitre 4 : Entrepôt de données Vs Systèmes d intégration Cet alignement entre les ontologies locales et l ontologie globale (étape 2) peut être effectuée de deux manières : à postériori ou à priori 1 [BNP06]. Dans une approche à postériori, les correspondances entre les différentes ontologies utilisées sont définies à postériori. Chaque source possède sa propre ontologie locale. Les ontologies locales sont définies de manière indépendante les unes des autres. Une fois ces ontologies locales définies, elles sont alignées avec l ontologie globale. Une approche à priori repose sur une ontologie globale préexistante. Cette approche est caractérisée par le fait que les administrateurs veulent une communication directe entre les sources de données à intégrer, i.e, il existe une volonté de fusion à priori dès la conception de la source de données. Chaque source possède une ontologie locale qui définit sa sémantique. Ces ontologies locales sont construites à partir de l ontologie globale en la référençant. En revenant à la classification des approches d intégration selon les trois critères de [NGU06], et se positionnant dans le cas (ED - GaV ou LaV - automatique), on retient les configurations suivantes : (1) ED - Ontologie unique (2) ED Multiple ontologies à postériori (3) ED Multiples ontologies à priori Représentation des données Automaticité d intégration sémantique Sens correspondance entre schémas Figure Classification des approches d intégration 1 Notons que les approches d intégration à base d une seule ontologie peuvent également se faire à priori (si la source est construite par rapport à une ontologie pré-existante) ou à postériori (si la connexion entre sources et ontologie se fait après le développement des sources). L obtention d un schéma intégré dans les deux cas se fait de la même manière. 80

81 Chapitre 4 : Entrepôt de données Vs Systèmes d intégration 4.1 ED Ŕ Ontologie unique Chaque source de données dans ce cas là référence une ontologie globale partagée entre l ensemble des sources. Cette approche suppose l existence d une ontologie partagée qui couvre le domaine des sources. Ces sources peuvent être définies comme un fragment (sous ensemble) de l ontologie comme dans le projet COIN par exemple. Ce scénario est applicable dans le cas où il existe une relation donneur d ordre sous traitant, où le donneur d ordre fournit un vocabulaire commun auquel les sources doivent s y référer. Les sources peuvent également être définies comme une vue de l ontologie globale comme dans le projet PICSEL par exemple, où de nouvelles relations entre les concepts ontologiques sont introduits pour définir la vue. Dans ce cas, les sources ont plus d autonomie schématique, mais qui reste cependant assez réduite. Dans ces approches à base d une seule ontologie, toutes les données des sources sont représentées par une seule ontologie qui est l ontologie globale. L ontologie intégrante est ainsi représentée par l ontologie globale. Exemple de projet : nous présentons ici les deux exemples de projets cités Coin et Picsel. La figure 4.11 présente l architecture du système d intégration COIN. Figure Architecture du système d intégration COIN [GBM99] 81

82 Chapitre 4 : Entrepôt de données Vs Systèmes d intégration Le système développé pour le projet COIN [GBM99] est un système de médiation pour l intégration de systèmes hétérogènes, dont l application porte sur l échange des données financières. La sémantique des données de chaque source est représentée explicitement en référençant un modèle du domaine (ontologie). Chaque source est représentée par un fragment de l ontologie. Le lien entre les sources et l ontologie intégrante est assuré par des axiomes : elevation axioms qui associe chaque attribut d une source à son objet sémantique dans l ontologie, et context axioms qui associe chaque source à un contexte particulier d interprétation des objets sémantique de l ontologie. Les requêtes envoyées au système (exprimées en termes des concepts de l ontologie) sont interceptées par le composant Context Mediator qui a pour rôle de réécrire les requêtes utilisateurs en des requêtes intermédiaires (exécutables sur les sources). Un optimiseur de requêtes transforme ces requêtes en sous requêtes optimisées (selon un modèle de coût), qui seront ensuite envoyées aux sources correspondantes. Un Executioner permet l exécution de ces requêtes sur les sources, collecte les résultats et envoie les réponses à l utilisateur. La figure 4.12 présente l architecture du système d intégration Picsel [RG03]. Picsel a pour objectif de fournir un système médiateur intégrant différents services du web. Figure Architecture du système d intégration PICSEL [RG03] 82

83 Chapitre 4 : Entrepôt de données Vs Systèmes d intégration Ce système est composé d un schéma intégrant les sources représentées par une ontologie décrivant le domaine d intérêt des sources à intégrer. Le domaine sur lequel a été testé ce système est le domaine du tourisme, l ontologie intégrante est construite en utilisant un vocabulaire standard OTA (Open Travel Alliance). Chaque source est décrite en termes de vues sur l ontologie intégrante. Chaque source est représentée par un ensemble de relations constituant une vue (intersection entre classes, sélection de classes, restriction des rangs des propriétés ) que la source peut couvrir. Les requêtes des utilisateurs sont exprimées en utilisant les concepts et propriétés de l ontologie. Ces requêtes sont traduites en sous requêtes applicables sur les schémas des sources en utilisant les vues décrivant les sources. Des wrappers permettent d exécuter les sous requêtes sur les sources et de construire la réponse finale. 4.2 ED Ŕ Multiples ontologies à postériori Chaque source de données dans ce cas définit sa sémantique par une ontologie locale. Les ontologies locales sont par la suite mises en correspondance avec une ontologie partagée. Cette approche suppose ainsi l existence d une ontologie globale. Elle est conditionnée par une volonté de fusion de la part des administrateurs de chaque source, qui doivent faire des efforts d alignement et de mapping entre les ontologies locales et l ontologie globale (à postériori). L avantage de cette approche est que chaque ontologie locale est développée indépendamment des autres. Son inconvénient est que l intégration des ontologies des sources, consistant à établir des relations sémantiques (équivalence, subsomption, ) entre les concepts de ces ontologies, ne peut être effectuée que manuellement ou semiautomatiquement [NGU06]. L ontologie intégrant l ensemble des sources est représentée dans ce cas, par l union entre l ontologie globale et l ensemble des ontologies locales et les relations entre ces deux derniers. Exemple de projet : le système ONION [MWK00], dont l architecture est représentée dans la figure 4.13, est un exemple de système d intégration qui se base sur cette approche. Chaque source de données dans ONION possède sa propre ontologie locale construite indépendamment des autres sources. Des mappings entre les ontologies locales sont construits afin de définir l ontologie unifiant les sources (intégrante). Cette ontologie est représentée par l union des ontologies des sources, et les articulations entre elles. 83

84 Chapitre 4 : Entrepôt de données Vs Systèmes d intégration Figure Architecture du système ONION Toutes ces ontologies sont gérés et maintenues par le module Onion data layer. Les règles d articulations sont établies semi automatiquement en présence d un expert humain. Elles permettent de lier les concepts d une ontologie O i aux concepts d une ontologie O j par un des labels (sous classe de, attribut de, instance de, implication sémantique). Les requêtes des utilisateurs sont formulées en utilisant l ontologie intégrante. Un module de requêtes (query engine) reformule les requêtes et dérive un plan d exécution des requêtes sur les schémas des sources. 4.3 ED Ŕ Multiples ontologies à priori Chaque source possède, dans cette configuration, son ontologie locale. Chaque ontologie locale est définie à partir de l ontologie partagée. Les sources également peuvent être construites à partir de l ontologie partagée. Cette configuration suppose l existence d une ontologie partagée par tous les participants. Elle nécessite des efforts de modélisation à priori, de la part des concepteurs ou des administrateurs, qui doivent modéliser les ontologies locales et parfois même les sources par rapport à une ontologie globale. Les ontologies locales peuvent être définies comme un fragment de l ontologie partagée. L ontologie intégrante est 84

85 Chapitre 4 : Entrepôt de données Vs Systèmes d intégration représentée par l ontologie partagée dans ce cas. Les sources peuvent aussi être définies par leur propre vocabulaire, mais référencent l ontologie partagée. L ontologie intégrante est représentée dans ce cas par l union de l ontologie partagée et des ontologies locales. L avantage de cette approche réside dans une intégration des ontologies des sources effectuée de manière complètement automatique. Son inconvénient réside dans l autonomie schématique réduite des sources. Cet inconvénient a été résolu dans l approche d intégration proposée par [NGU06] qui propose une intégration matérialisée des sources, à priori, où les ontologies locales peuvent étendre l ontologie partagée afin de satisfaire leurs besoins. Cette approche permet d obtenir une intégration des ontologies complètement automatique. De plus, elle offre une autonomie schématique des sources qu on ne retrouve pas dans les autres méthodes d intégration à priori. Elle est basée sur trois principes : - Chaque source participante au processus d intégration doit contenir sa propre ontologie (appelée base de données à base ontologique (BDBO 1 )) - Chaque ontologie locale s articule à priori avec une (ou des) ontologie(s) partagée(s) - Chaque ontologie locale étend l ontologie partagée pour satisfaire ses besoins. Exemple de projet : le système d intégration Buster [SWV00] se base sur cette approche. Buster est composé d une ontologie globale préexistante. Chaque source de données est associée à une ontologie locale, qui représente un fragment ou une partie de l ontologie globale. L intégration s effectue en deux phases. Une première phase où l utilisateur formule sa requête sur l ontologie globale. Le système détermine les sources pertinentes pour la requête, et les affiche à l utilisateur qui doit choisir une ou plusieurs sources et reformuler sa requête sur les sources sélectionnées. Une deuxième phase d acquisition des données consiste à collecter les informations des sources. Ces données sont stockées dans un fichier xml créé 1 Une base de données à base ontologique (BDBO) est une base de données qui contient des ontologies, un ensemble de données et des liens entre ces données et les éléments ontologiques qui en définissent le sens [PDA05]. L ontologie et les données sont toutes deux représentées dans la base de données et peuvent faire l objet des mêmes traitements (insertion, mise à jour, interrogation ). L avantage des BDBOs est que le modèle conceptuel de la BD (représenté par l ontologie) est stocké au niveau de la BD, ce qui facilite l interrogation de la base ainsi que l échange des données entre les BDs. 85

86 Ontologie unique Ontologie Unique Chapitre 4 : Entrepôt de données Vs Systèmes d intégration manuellement pour chaque source contenant aussi des méta-données sur la source (données techniques, syntaxe, ). Un module d intégration permet de faire le lien entre ces fichiers afin de construire la réponse finale à la requête de l utilisateur. Cette étude nous a permis de ressortir les différents cas d existence d un schéma intégrant des sources de données (représenté par une ontologie intégrante). Tous ces scénarios d intégration supposent que l ontologie partagée est suffisante pour couvrir toutes les sources locales. Dans les domaines où de telles ontologies de domaine existent, le tableau suivant récapitule les différentes approches d intégration à base ontologique des sources de données : Principe Conditions d utilisation Avantages/ Inconvénients Ontologie intégrante Source est un fragment de l ontologie partagée (OP). Exp: Projet COIN Source est une vue sur l ontologie partagée. Exp : Projet Picsel - Existence d une ontologie globale couvrant les sources - Relation Donneur d ordre Sous traitants - Existence d une ontologie globale couvrant les sources - Indépendance des sources réduite - Autonomie schématique des sources réduite - Scalabilité réduite du système + Plus d autonomie schématique des sources - Indépendance des sources réduite - Scalabilité réduite du système O Int = OP O Int = OP 86

87 Multiple ontologies à priori Multiple ontologies à postériori Chapitre 4 : Entrepôt de données Vs Systèmes d intégration - Chaque source possède son ontologie locale - Alignement des ontologies locales avec une ontologie partagée. - Existence d une ontologie globale couvrant les sources - Volonté de fusion des administrateurs (efforts de mapping à postériori) + ontologies locales indépendantes - Intégration des ontologies semiautomatique ou manuelle O Int = OP U OL i Exp : projet ONION - Ontologie partagée préexistante - Ontologies locales construites par référence à l ontologie partagée - Ontologie partagée par tous les participants - Efforts de modélisation à priori + Intégration automatique des ontologies - Autonomie schématique réduite (Problème géré dans l approche d intégration de [NGU06]) - O Int = OP (OLi fragment de OP) - O Int = OP U OL i (OL i référence OP) Exp : Projet OntoDawa Tableau 4.1 : Tableau récapitulatif des approches d intégration à base ontologiques 5 Conclusion Partant du constat qu un entrepôt de données est similaire à un système d intégration matérialisé par des concepts multidimensionnels, nous avons jugé utile d étudier les principales approches et systèmes d intégration des sources d informations. Cette étude nous a permis de souligner qu une intégration sémantique des données de manière automatique ne peut se faire que par l utilisation d ontologies conceptuelles référencées par les sources à intégrer. Nous avons ainsi étudié les principales notions relatives aux ontologies et leur aspect descriptif d un domaine présentant un apport certain dans une approche de modélisation conceptuelle. Nous avons également étudié leur contribution en tant que schémas d intégration des sources de données. Nous avons ainsi présenté les approches d intégration à 87

88 Chapitre 4 : Entrepôt de données Vs Systèmes d intégration base ontologique ; nous avons étudié comment s effectue le lien entre sources et ontologies (labels, règles logiques, axiomes ), et nous avons établi les différentes configurations possibles d existence d une ontologie couvrant et intégrant un ensemble de sources. Nous estimons, à ce niveau, avoir les assises nécessaires pour proposer une méthode de conception d un entrepôt de données à base ontologique, qui fera l objet d étude du prochain chapitre. 88

89 Chapitre 5 Méthode de conception à base ontologique d un entrepôt de données Les méthodes de conception des projets d entreposage peuvent être classifiées en trois générations d approches : les approches directes (génération du schéma logique sans passer par une phase de conception), les approches traditionnelles (mise en place d une vraie phase de conception orientée sources ou besoins), et nouvelle génération d approches ontologiques. Les sources de données, étant au cœur de la construction d un entrepôt, leur intégration au sein du schéma global de l entrepôt est souvent un problème délicat qui nécessite la résolution de plusieurs conflits entre les données. Différentes approches d intégration ont conclu sur l utilisation des ontologies pour assurer une intégration sémantique des données de manière automatique. Les ontologies apportent de plus, des avantages très intéressants pour la spécification d un modèle conceptuel. Partant de ces constats, nous proposons une nouvelle méthode de conception d un entrepôt de données s inscrivant dans les approches ontologiques. Pour ces approches là, un seul travail a été proposé [RA07] présentant une méthode de conception dérivant le schéma conceptuel de l entrepôt uniquement à partir des sources de données. Nous proposons, dans notre méthode, de prendre en compte les sources de données et les besoins des utilisateurs, tous deux représentés au niveau ontologique ; afin de fournir un modèle conceptuel représenté au niveau sémantique. Nous décrivons dans ce qui suit la méthode de conception que nous proposons. Nous commencerons par positionner la méthode proposée dans le cadre des approches ontologiques, en soulignant les nouvelles contributions qu elle apporte. Nous soulignons l apport de l utilisation des ontologies dans cette méthode de conception. Nous présentons par la suite la méthode proposée à travers une formalisation du problème de conception, les étapes 89

90 Chapitre 5 : Méthode de conception ontologique d un entrepôt de données de la méthode, et l apport de la méthode proposée par rapport aux limites des approches existantes identifiées au chapitre 3 (Section 2). 1 Apport de la méthode SISRO M2C Lors de l analyse des méthodes de conception d EDs existantes, nous avons dégagé certaines limites, qui sont : (i) la difficulté de conception, (ii) l automatisation de la démarche de construction, (iii) la difficulté d'utilisation ultérieure de l entrepôt et (iv) l intégration des données. La méthode SISRO M2C que nous proposons présente certains apports qui permettent de résoudre complètement ou partiellement ces limites : - Simplifier la tâche de conception : en considérant l ontologie intégrante comme base et référence de conception, le concepteur gagne en temps et en efforts pour maîtriser le domaine de l entrepôt à développer. L ontologie facilite aussi l intégration des données au niveau sémantique et de manière automatique, mais également le chargement des données au niveau de l entrepôt lors du processus ETL. - Interaction et autonomie de conception : l objectif de cette méthode de conception est d offrir un cadre de conception permettant de guider le concepteur tout au long de sa tâche en interagissant avec lui, en profitant de son expertise et en automatisant les étapes fastidieuses qui peuvent être automatisées, tout en offrant au concepteur une réelle autonomie dans cette tâche de conception. - Sémantique du modèle conceptuel : un modèle conceptuel a pour but d expliciter les besoins applicatifs et la connaissance du domaine une forme intelligible pour un utilisateur ultérieur. Le passage du niveau conceptuel au niveau logique cause nécessairement une perte de la sémantique du modèle conceptuel dûe aux différentes règles de transformation (normalisation, ). La présence d une dimension sémantique au niveau du modèle conceptuel permet d assurer une représentation de ce modèle au niveau de l entrepôt final lors des passages aux niveaux logiques et physiques ; ce qui permet de faciliter interrogation de l entrepôt par les utilisateurs finaux. 90

91 Chapitre 5 : Méthode de conception ontologique d un entrepôt de données 2 Conclusion Nous avons proposé dans ce chapitre une nouvelle méthode de conception d un ED à base ontologique. Cette méthode est, à notre connaissance, la première méthode effectuant le rapprochement entre les sources et les besoins d un entrepôt au niveau ontologique. L avantage de l exploitation d une ou plusieurs ontologies est présent à plusieurs niveaux : lors de l intégration des sources hétérogènes, tout au long du processus de conception, mais également lors de l utilisation de l entrepôt final une fois construit. Nous présentons dans le chapitre suivant la mise en œuvre de SISRO M2C proposée à travers un outil implémentant cette méthode. 91

92 Chapitre 6 Mise en œuvre de SISRO M2C Afin de valider la méthode de conception à base ontologique SISRO M2C que nous avons présenté, nous proposons un outil qui accompagne cette méthode. Nous avons pensé cet outil comme un outil de génie logiciel (phase conceptuelle) dédié aux applications décisionnelles, à l instar des outils de génie logiciels existants pour les BDs tels que Visio ou PowerAMC. Rappelons qu il n existe que quelques outils très peu nombreux de représentation graphique du modèle conceptuel d un entrepôt, comme par exemple ADAPT [BF98] ou GOLD [LTS02]. Comme ces outils, l outil que nous proposons permet la visualisation et la manipulation du modèle conceptuel d un ED, mais implémente également toutes les étapes de SISRO M2C. Nous présentons dans ce chapitre l environnement de développement du prototype proposé, les étapes d implémentation, et les interfaces de l outil. 92

93 Chapitre 6 : Mise en œuvre de SISRO M2C 1 Environnement de développement L outil implémentant la méthode SISRO M2C a été développé dans un environnement Windows XP, en langage de programmation Java, JDK 1.6. Les ontologies manipulées par cet outil sont au format OWL. L accès et la manipulation de l ontologie se fait à travers l API de déveoppement ProtegeOWL fournie par l éditeur de développement d ontologie Protege. Cet outil prend en compte des bases de données relationnelles référençant une ou plusieurs ontologies. Le modèle conceptuel de l entrepôt obtenu est modélisé selon le diagramme de classes d UML dans lequel on distingue deux de classes Fait et Dimension (voir chapitre 5, section ). Le schéma ci-dessous explicite l environnement d implémentation de l outil développé lors des différentes étapes d implémentation. Figure 6.1. Mise en œuvre de la méthode SISROM2C 93