Rapport Eda Pfe

Projet Fin dEtude
Ddicaces
Je ddie ce modeste travail
A toutes les personnes qui mont toujours soutenue et encourag :
ma mre le trsor de bont, de gnrosit et de tendresse, mon pre quaucun mot puisse tmoigner de ltendue des sentiments que jprouve son gard, mes chers frres, mes amis et mes collgues,
Projet Fin dEtude
Remerciement
Je souhaite tout dabord exprimer ma sincre gratitude envers mon encadreur : Monsieur Jalel Eddine Hajlaoui. Ses efforts en terme dencadrement actif, dencouragemenet surtout de patience ainsi que ses qualits scientiques et humaines ont contribu lpanouissement de ce travail. Je suis trs reconnaissante Monsieur Hugues Aubuchon, je le remercie vivement pour limplication quil a pu avoir tout au long de ce travail, son aide, et ses prcieux conseils mont t dune aide prcieuse. Je saisis cette occasion pour remercier les membres du jury tout en esprant quils trouvent dans ce rapport les qualits de clart et de motivation quils attendent. Enn, Je tiens remercier vivement tout le personnel et le corps professoral de LISSAT et tous ceux, qui mont apport de laide mme minime
ii
TABLE DES MATIRES
Projet Fin dEtude
Table des matires

Introduction Gnrale 1 Concepts de base 1.1 Entrepts de donnes . . . . . . . . . . . . . . . . . . . . . 1.1.1 Les caractristiques des entrepts de donnes . . . . 1.1.2 Architecture des entrepts de donnes . . . . . . . . 1.1.3 Entrept et les bases de donnes relationnelles . . . 1.2 Modlisation multidimensionnelle . . . . . . . . . . . . . . 1.2.1 Modlisation conceptuelle . . . . . . . . . . . . . . 1.2.2 Modlisation physique . . . . . . . . . . . . . . . . 1.3 Architecture dun systme dcisionnel . . . . . . . . . . . . 1.3.1 Alimentation (ETL) dun entrept de donnes . . . . 1.4 Linterrogation des bases des donnes multidimensionnelles 1.4.1 Le modle de donnes dans notre contexte . . . . . . 1.4.2 Les langages de manipulation de donnes . . . . . . 1.4.2.1 Algbre pour la manipulation OLAP . . . 1.4.3 Le langage utilis dans notre approche . . . . . . . . 1.4.3.1 Les concepts de MDX : . . . . . . . . . . 1 3 4 5 6 6 7 7 9 10 11 12 13 13 14 16 17 20 21 21 24 25 25 26 28 29 30
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
Etat de lart 2.1 Les bases de donnes actives . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1 Les bases de donnes actives . . . . . . . . . . . . . . . . . . . . . 2.1.2 Les rgles ECA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Les entrepts de donnes actifs . . . . . . . . . . . . . . . . . . . . . . . . 2.2.1 Les entrepts de donnes passifs vers les entrepts de donnes actifs 2.2.2 Les rgles danalyse . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.3 Les graphes danalyse . . . . . . . . . . . . . . . . . . . . . . . . 2.2.4 Lanalyse multidimensionnelle . . . . . . . . . . . . . . . . . . . . 2.2.5 Dclencheur (Trigger) . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
iii
TABLE DES MATIRES

2.2.5.1 Processus dclencheur de nettoyage . Requtes Continues . . . . . . . . . . . . . . . . . . . . 2.3.1 Smantique continue . . . . . . . . . . . . . . . 2.3.2 Requtes continues vs. rgles ECA . . . . . . . Personnalisation et recommandation des systmes OLAP 2.4.1 Personnalisation du schma OLAP . . . . . . . . 2.4.2 Personnalisation de requtes . . . . . . . . . . . 2.4.3 Personnalisation de linterrogation des BDM . . 2.4.4 Recommandation de requtes . . . . . . . . . . Positionnement et proposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Projet Fin dEtude . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 33 34 35 35 35 36 36 37 38 42 43 43 44 49 50 50 50 51 54 54 54 55 57 59 60 62 70 70 70 72 79 79 83
2.3
2.4
2.5 3
Formalisation des rgles danalyse 3.1 Notations et terminologies . . . . . 3.1.1 Modle de cube de donnes 3.1.2 Oprateurs complmentaires 3.2 Rgle danalyse . . . . . . . . . . . 3.2.1 Conjonction dvnements . 3.2.2 Ensembles de conditions . . 3.2.3 Graphe danalyse . . . . . . 3.2.4 Sous-graphe danalyse . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
Exprimentations 4.1 Architecture dapplication . . . . . . 4.1.1 Architecture dapplication . . 4.1.2 Technologies employes . . . 4.2 Etude de cas . . . . . . . . . . . . . . 4.2.1 Exemple dune rgle danalyse 4.3 Modlisation XML de la rgle . . . . 4.4 Validation de lexemple . . . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
Conclusion et perspectives 4.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Bibliographie Annexes A Le Moteur Mondrian . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B La Plate-forme Pentaho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
iv
TABLE DES FIGURES
Projet Fin dEtude
Table des gures

1.1 1.2 1.3 1.4 2.1 2.2 2.3 2.4 2.5 3.1 3.2 3.3 3.4 3.5 3.6 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10 4.11 4.12 Architecture dEntrept de Donnes [Sand07] . . . . . . . . . . . . . Exemple danalyse des ventes dune chaine de magasins informatiques Architecture dun systme dcisionnel . . . . . . . . . . . . . . . . . Rsultat dune requte MDX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 9 10 19 23 26 28 30 32 43 45 47 48 51 52 55 58 59 61 62 63 64 65 66 66 67 68
Architecture de gestionnaire de rgles Oracle et exemple de code [Oracle 2006] Entrept de donnes actif [TSM01] . . . . . . . . . . . . . . . . . . . . . . . . Graphe danalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Dmarche gnrale dun entrept de donnes actif . . . . . . . . . . . . . . . . Modle dobjet dynamique dun dclencheur [Ezek et Mari.06] . . . . . . . . . Exemple dun cube de donnes de location de vhicules . . . . . . . Exemple dun oprateur dunion entre deux cubes de donnes . . . Exemple dun oprateur dintersection entre deux cubes de donnes Exemple dun oprateur de diffrence entre deux cubes de donnes Reprsentation graphique dun chemin danalyse . . . . . . . . . . Graphe danalyse associ au cube des locations de vhicules . . . . Architecture de systme . . . . . . . . . . . . . . . . Exemple de modlisation en toile du cube Locations Schma du cube Locations . . . . . . . . . . . . . . Modlisation XML de la rgle danalyse . . . . . . . Prototype dEntrept de Donnes Actif (PEDA) . . . Fichier XML associ lexemple . . . . . . . . . . . Rsultat nal de notre exemple . . . . . . . . . . . . Graphe danalyse associ lexemple . . . . . . . . Authentication dutilisateur . . . . . . . . . . . . . Accs au cube Locations . . . . . . . . . . . . . . . Rsultat nal de notre exemple . . . . . . . . . . . . Opration Slice effectue sur le cube Locations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
TABLE DES FIGURES

4.13 4.14 4.15 4.16 4.17 4.18 4.19 4.20 4.21 4.22 Histogramme de lopration Slice . . . . . . . . . . Tables de la base foodmart . . . . . . . . . . . . . . Interface Mondrian . . . . . . . . . . . . . . . . . . XML for Analysis Tester . . . . . . . . . . . . . . . Rsultat XML . . . . . . . . . . . . . . . . . . . . . Capture dcran de la table de fait et des dimensions . Connexion la base de donnes . . . . . . . . . . . Schma du cube Locations . . . . . . . . . . . . . . Publication de chier XML . . . . . . . . . . . . . . Console de Pentaho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Projet Fin dEtude . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 80 80 81 81 83 84 84 85 85
vi
LISTE DES TABLEAUX
Projet Fin dEtude
Liste des tableaux

1.1 2.1 2.2 Diffrences principales entre les systmes OLPT et OLAP [Kelly97 ] . . . . . . . 5 33 40
Patients souffrants dune maladie respiratoire [Ezek et Mari.06] . . . . . . . . . . . Synthse des travaux sur les entrepts de donnes actifs . . . . . . . . . . . . . .
vii
Introduction Gnrale
Projet Fin dEtude
Introduction Gnrale
ans les annes 80, nous avons assister lmergence des bases de donnes dductives [Ull82]. Ces dernires se basent sur des langages de requtes de type programmation logique qui expriment des rgles dductives. Il sagit de driver de nouvelles informations partir des informations existantes. Cependant, cette gnration des bases de donnes ne traite pas laspect comportemental des objets. Avec lapparition des techniques des systmes de gestion de bases de donnes objets relationnels, dans les annes 90, les bases de donnes actives [Bar04] sont apparues pour pallier les limites des bases de donnes dductives. Ces bases de donnes, dites actives [Bar04], ont permis de grer non seulement les aspects statiques des objets mais aussi leur comportement et ceci a t effectu grce aux technologies des prdicats, le mcanisme ECA (Evnement-Condition- Action), les triggers et les procdures centralises. Avec laccroissement exponentiel de la volumtrie des donnes, les entreprises privilgient le dcisionnel et passent dune simple gestion de donnes une logique danalyse des donnes. Pour faire face aux nouveaux enjeux, lentreprise doit collecter, traiter, analyser les donnes de son environnement pour anticiper. Mais linformation produite par lentreprise est surabondante, non organise et parpille dans de multiples systmes oprationnels htrognes. Il est devenu fondamental de rassembler et dhomogniser les donnes an de permettre lanalyse dindicateurs pertinents pour faciliter la prise de dcisions. Les systmes dcisionnels (SD) visent transformer les donnes mtiers en informations pouvant tre interprtes par les dcideurs. Ils sont souvent constitus par des espaces de stockage appels entrepts de donnes. Alors, ces derniers taient la solution pour rpondre aux exigences de lentreprise. Il a t formalis dans les dbuts des annes 90 par Inmon [IRH94]. Les SGBDs (Systmes de Gestion des Bases de Donnes ) et les entrept de donnes ont des objectifs qui diffrent avec des traitements et stockage des donnes diffrentes et font lobjet galement de requtes diffrentes. Les SGBDs sont des systmes dont le mode de travail est transactionnel (OLTP On-line Transaction Processing), permettant linsertion, la modication, linterrogation des informations avec efcacit et scurit. Les deux objectifs principaux sont : en premier lieu la slection, lajout, la mise jour et la suppression des tuples, et en second lieu lexcution de ces oprations. Ces tches seffectuent trs rapidement et simultanment par de nombreux utilisateurs. Les entrept de donnes sont des systmes conus pour laide la prise de dcision (OLAP On-Line Analytical Processing), frquemment utiliss en lecture (utilisateurs), avec pour objectifs principaux de regrouper, dorganiser les informations provenant de sources diverses, les intgrer et les stocker pour donner lutilisateur une vue oriente mtier, retrouver et analyser linformation avec facilit et rapidit.
Introduction Gnrale
Projet Fin dEtude
An dacclrer la prise de dcision et n de doter lentrept dun aspect actif, une solution possible pour ce problme consiste sinspirer des techniques utilises dans les bases de donnes actives. La technologie des entrepts de donnes actifs rpond de manire ractive la croissance constante des volumes de donnes et aux besoins des utilisateurs. Une des fonctionnalits de base dun entrept de donnes actif est de dtecter des vnements. Cest seulement aprs quun vnement dintrt soit produit et soit dtect et que les rgles soient dclenches, les actions appropries sont excutes. Ainsi, plus un entrept de donnes actif dtecte plusieurs types dvnements, plus quil est capable de rpondre une plus grande varit de situations relles et y ragit en consquence. De ce fait, le besoin de disposer dun entrept de donnes actif plus puissant et expressif, tellement accentu par la capacit de dtection dune taxonomie de diffrentes catgories dvnements, est souvent traduit en un besoin de supporter plus dvnements complexes. Notre objectif dans ce projet est de proposer une architecture dentrept de donnes actif efcace de dtection dvnements complexes au sein dun entrept permettant doffrir une smantique non ambige des expressions dvnements formes par divers oprateurs OLAP dans diffrents contextes danalyse. Un entrept de donnes actif se base sur la transformation du mcanisme ECA en un mcanisme dECG (Evnements-Conditions-Graphes danalyses). Par la spcication dun ECG, les connaissances implicites propos des procdures de dcisions excutes par les dcideurs seront transformes en des scnarios explicites. Le prsent projet est organis de la manire suivante : le premier chapitre, voquera les concepts de base sur les systmes de bases de donnes multidimensionnelles. Le deuxime chapitre sera consacr une tude bibliographique qui portera sur les bases de donnes actives et les entrepts de donnes. Le troisime chapitre prsentera notre proposition de formalisation des rgles danalyse. Le quatrime chapitre , exposera larchitecture de notre application et exprimentation. Enn, nous conclurons en voquant de nouvelles perspectives relatives nos objectifs et notre proposition.
CHAPITRE 1. CONCEPTS DE BASE
Projet Fin dEtude
Chapitre 1 Concepts de base
Introduction
information reprsente un capital immatriel dont la bonne gestion est un facteur primordial pour la russite de toute organisation. Les systmes dinformation ont pour objectif de supporter la ralisation des activits dune organisation. Ils sont construits partir des exigences des mtiers et des processus dnis par lentreprise an de stocker, traiter et communiquer les informations. Avec laugmentation des capacits de stockage, nous avons assist durant ces dernires annes une croissance importante des moyens de gnration et de collection des donnes. Le besoin dinterprter et danalyser ces donnes an den extraire des connaissances forte valeur ajoute, contribuant la prise de dcision, est devenu imprieux. Il sest ainsi cre une obligation dacquisition de nouvelles techniques et mthodes intelligentes de gestion. Les systmes de bases de donnes multidimensionnelles deviennent de plus en plus populaires pour contrler et analyser de grands volumes de donnes issues de lentrept de donnes. Le principal avantage de ces systmes de bases de donnes est quils permettent lexcution efcace de requtes complexes donnant ainsi la possibilit aux utilisateurs dexplorer interactivement les donnes et de rechercher des informations intressantes. Ainsi, ce chapitre est organis de la faon suivante. Tout dabord, nous voquons dans la section 1 les entrepts de donnes, en expliquant les caractristiques, larchitecture dentrept de donnes et enn la diffrence entre les bases relationnelles et lentrept de donnes. Puis, dans la section 2, nous prsentons la modlisation multidimensionnelle, les principaux lments relatifs leur modlisation, tel que les diffrents concepts de la modlisation conceptuelle et physique. Dans la section 3, nous nous focalisons sur larchitecture de systme dcisionnel en prsentant le processus
Projet Fin dEtude
qui est le responsable dans lalimentation dentrept de donnes. Par la suite, dans la section 4, nous voquons linterrogation des bases de donnes multidimensionnelles en expliquant les langages de manipulation de donnes. Enn, nous concluons ce chapitre en introduisant le problme de lvolution dans le contexte des entrepts de donnes.
1.1
Entrepts de donnes
Les entrepts de donnes sont apparus vers les annes 1990 en rponse la ncessit de rassembler toutes les informations de lentreprise en une base de donnes unique destine aux analystes et aux gestionnaires [[Cod93], [DG01]] . Lensemble des donnes, y compris leur historique, est utilis dans de nombreux domaines, tels que : lanalyse de donnes et laide la dcision (gestion et analyse de march, gestion et analyse du risque, gestion et dtection ; des fraudes,...) ; dans autres applications (recherches dans des textes, dans les documents web, dans lastronomie,...) [[Adi02], [BCA01] ]. Les entrepts de donnes des entreprises ncessitent un espace mmoire de centaines de gigaoctets ou traoctets [CD97]. Les Systmes de Gestion de Bases de Donnes (SGBDs) traditionnels permettent de faire des oprations sur une base de donnes (insertion, modication, suppression, consultation) et ont donc un mode de travail transactionnel OLTP 1 . Par contre, les entrepts de donnes sont conus pour laide la dcision et utilisent la technologie OLAP 2 ( La notion dOLAP, introduite par Codd dans son article de rfrence en 1993 [CCS93], se rfre une technique pour raliser des analyses complexes sur les informations stockes dans un entrept de donnes. Dans lOLAP, les donnes sont modlises de faon multidimensionnelle, partir dune varit de sources et sont stockes dans un entrept de donnes [Pow07].) pour principaux objectifs de regrouper et dintgrer des informations provenant de sources htrognes, de les stocker et de donner une vue oriente mtier de ces donnes, de pouvoir les retrouver et les analyser avec facilit et rapidit. Les requtes OLAP ncessitent la lecture dune norme quantit de donnes pour produire un ensemble de valeurs numriques. Les diffrences principales entre les systmes OLTP et OLAP rsumes par Kelly [Kelly97 ] sont soulignes dans le Tableau 1.1.
1. On-Line Transaction Processing 2. On-Line Analytical Processing
CHAPITRE 1. CONCEPTS DE BASE OLTP - Gestion des transactions - Orient application - Rcentes, dtailles, - Relationnelle, - Accessibles de faon individuelle - Base de donnes unique - Lecture / Ecriture - Simples, nombreuses, rgulires, rptitives - Prvisibles - Agents oprationnels -Nombreux (des milliers) , Concurrents - 100MB 1GB
Projet Fin dEtude OLAP - Aide la dcision - Orient utilisateurs - Historiques, agrges -Multidimensionnelles, - Accessibles de faon ensembliste - Plusieurs bases de donnes - Lecture - Complexes, peu nombreuses, irrgulires, -Non prvisibles - Managers / analystes , -Peu (dizaines ou centaines) - Non concurrents - 100GB 1TB
Utilisation Conception Donnes
Source Accs Requtes / Utilisation
Utilisateurs
Taille de la base
TABLE 1.1 Diffrences principales entre les systmes OLPT et OLAP [Kelly97 ] Nous prsentons dans la suite larchitecture qui se compose de trois composants : un entrept de donnes, un serveur OLAP et un client OLAP. Nous dcrivons aussi les caractristiques des entrepts et les bases de donnes relationnelles.
1.1.1
Les caractristiques des entrepts de donnes
Lentrept de donnes est dni par Bill Inmon (1996) comme "une collection de donnes thmatiques (oriente sujet), intgres, non volatiles et histories pour le support dun processus daide la dcision. Il sagit dune collection de donnes pour le support dun processus daide la dcision. Les donnes dun entrept possdent les caractristiques suivantes [[Fra97] ,[DG01]] : Orientation sujet : les donnes dun entrept sorganisent par sujets ou thmes. Cette organisation permet de rassembler toutes les donnes, pertinentes un sujet et ncessaires aux besoins danalyse, qui se trouvent rpandues travers les structures fonctionnelles dune entreprise. Intgration : les donnes dun entrept sont le rsultat de lintgration de donnes en provenance de multiples sources ; ainsi, toutes les donnes ncessaires pour raliser une analyse particulire se trouvent dans lentrept. Lintgration est le rsultat dun processus qui peut devenir trs complexe du lhtrognit des sources.
Projet Fin dEtude
Histoire : les donnes dun entrept reprsentent lactivit dune entreprise pendant une longue priode ou il est important de grer les diffrentes valeurs quune donne prises au cours du temps. Cette caractristique donne la possibilit de suivre une donne dans le temps pour analyser ses variations. Non-volatilit : les donnes charges dans lentrept sont surtout utilises en interrogation et ne peuvent pas tre modies, sauf dans certains cas de rafraichissement.
1.1.2
Architecture des entrepts de donnes
Lentrept de donnes joue un rle stratgique dans la vie dune entreprise. Il stocke des donnes pertinentes aux besoins de prise de dcision en provenance des systmes oprationnels de lentreprise et dautres sources externes. Un datawarehouse (ou entrept de donnes) est un serveur informatique dans lequel est centralis un volume important de donnes consolides partir des diffrentes sources de renseignements dune entreprise (notamment les bases de donnes internes). Les architectures des systmes dentrepts de donnes sont classiquement des architectures trois niveaux, comme le montr la Figure 1.1 tir de[Sand07], constitues par un entrept de donnes, un serveur OLAP et un client OLAP.
F IGURE 1.1 Architecture dEntrept de Donnes [Sand07]
1.1.3
Entrept et les bases de donnes relationnelles
Dans lenvironnement des entrepts de donnes, les oprations, lorganisation des donnes, les critres de performance, la gestion des mta-donnes, la gestion des transactions et le processus de requtes sont trs diffrents des systmes de bases de donnes oprationnels. Par consquent, les
Projet Fin dEtude
SGBDR 3 orients vers lenvironnement oprationnel, ne peuvent pas tre directement transplants dans un systme dentrept de donnes [WMB97]. Les SGBDs ont t crs pour grer de grands volumes dinformation contenus dans les diffrents systmes oprationnels qui appartiennent lentreprise. Ces donnes sont manipules en utilisant des processus transactionnels en ligne [Cod93]. Par contre, les entrepts de donnes ont t conus pour laide la prise de dcision. Ils intgrent les informations qui ont pour objectif de fournir une vue globale de linformation aux analystes et aux dcideurs. Paralllement lexploitation de linformation contenue dans ces systmes oprationnels, les dirigeants des entreprises ont besoin davoir une vision globale concernant toute cette information pour faire des calculs prvisionnels, des statistiques ou pour tablir des stratgies de dveloppement et des analyses des tendances.
1.2
Modlisation multidimensionnelle
La conception des bases de donnes est en gnral base sur le modle Entit-Association. Ce modle permet de dcrire des relations entre les donnes lmentaires (entits) liminant des redondances, ce qui provoque lintroduction dun nombre important de nouvelles entits. De ce fait, laccs aux donnes devient compliqu et le diagramme gnr difcile comprendre pour un utilisateur. Cest pour cette raison que lutilisation de la modlisation (Entit-Relation) (E-R) pour la conception dun entrept nest pas considre comme appropri. De nombreux autres axes (ou dimensions) peuvent tre dnis, notamment en fonction de la zone gographique, du prix, ou de lvolution dans le temps. Daprs [Tes00], la modlisation multidimensionnelle est dnie comme suit : Dnition 2.1. (Modlisation multidimensionnelle) La modlisation multidimensionnelle consiste considrer un sujet analys comme un point dans un espace plusieurs dimensions. Les donnes sont organises de manire mettre en vidence le sujet analys et les diffrentes perspectives danalyse. Une base de donnes multidimensionnelle stocke alors les donnes de manire permettre des analyses dcisionnelles. lintersection de plusieurs dimensions, se trouvent des valeurs galement nommes indicateurs ou variables. Elles peuvent tre par exemple le montant des ventes, ou le chiffre daffaire. Ces valeurs sont extraites de la base de production, ou peuvent tre calcules par le moteur OLAP.
1.2.1
Modlisation conceptuelle
Le modle multidimensionnel est une alternative mieux adquate aux besoins de lanalyse des donnes dun entrept. Conceptuellement, la modlisation multidimensionnelle a donn naissance
3. Systmes de Gestion de Bases de Donnes Relationnelles
Projet Fin dEtude
diffrents concepts dont les principaux sont les suivants : Dimension : cest une instance de relation appele table de dimensions. Chaque dimension est compose dattributs qui reprsentent les niveaux de granularit de visualisation des donnes ( organiss en hirarchie ). Une dimension spcie la manire dont on regarde les donnes pour les analyser, alors quune mesure est un objet danalyse. Fait : il modlise le sujet de lanalyse. Un fait est form de mesures correspondant aux informations des donnes analyser via des fonctions dagrgation. Les valeurs de mesures sont majoritairement numriques, non nulles et donc aptes tre manipules via des fonctions dagrgation. Donc, ces mesures sont stockes dans les tables de faits. Table de faits (cl multiple) : elle contient les valeurs des mesures et les cls vers les tables de dimensions. Toute table de faits a une cl primaire composite constitue partir dun ensemble de cls trangres. Les faits les plus utiles dune table de faits sont numriques et additifs. Hirarchie : elle organise les paramtres dune dimension selon un ordre conformment leur niveau de dtail. La hirarchie est considre comme tant un lment fondamental dans la structure dun contexte. Elle organise les attributs dune dimension de la granularit la plus ne vers la granularit la plus gnrale. Certains de ces chemins sont connus (par exemple : Jour, Mois, Trimestre), dautres doivent tre reprs par une analyse prcise du vocabulaire des utilisateurs (par exemple : Produit, Gamme, Marque). On peut alors observer les donnes dans un espace trois dimensions : la dimension ville, la dimension produit et la dimension temps. Chaque intersection de ces dimensions reprsente une cellule comportant le montant des ventes. Prenons le cube dcrit par la Figure 1.2 tir de [Ronan07], contient un groupe de mesures comprenant deux mesures Quantits et les Montants des ventes, organises en fonction de trois dimensions nommes Magasins o les ventes ont t effectues, les Dates correspondantes aux dates de ventes et les Produits vendus. Chacune de ces dimensions dispose de plusieurs niveaux de dtail (ville, pays, continent. . . ) et permettent dobtenir une vision plus ou moins dtaille lors des analyses. Les petites valeurs alphanumriques autour du cube reprsentent les membres des dimensions. Les membres sont par exemple Paris (membre de la dimension Magasin), Sun Ultra (membre de la dimension Produit) et Nov.05 (membre de la dimension Dates).
Projet Fin dEtude
F IGURE 1.2 Exemple danalyse des ventes dune chaine de magasins informatiques
1.2.2
Modlisation physique
De nos jours, les volumes de donnes traiter sont de plus en plus importants [LVC03]. Apparus pour grer de tels volumes de donnes issues de sources htrognes, les entrepts de donnes constituent loutil essentiel de collecte et de mise disposition des donnes en vue de leur analyse interactive, rapide et dynamique [[Inm92],[JLVV01]]. Lobjectif des entrepts de donnes est dtre un support pour les applications danalyse en ligne. Ce type dapplications est caractris par une vision multidimensionnelle des donnes de lentrept. Il sagit essentiellement danalyser des indicateurs (mesures) dune activit selon diffrents axes danalyse (dimensions). Par exemple, la direction dune entreprise souhaite observer lvolution des ventes en terme de chiffre daffaire en fonction des axes danalyse produit, magasin et anne. Les concepts dnis dans une structure multidimensionnelle ont t reprsents par diffrentes techniques de modlisation multidimensionnelle physique. Les plus courants sont les trois schmas que nous prsentons ci-dessous. Le schma en toile (star schema [[Kim96], [JLVV01]] ) : une table de faits centrale en BCNF 4 [AHV95] contenant les faits analyser est relie aux tables de dimensions par des cls trangres. Elle reprsente visuellement une toile. Les tables de dimension nont pas de lien entre elles.
4. la Forme Normale de Boyce-Codd ]
Projet Fin dEtude
Le schma en ocon (snowake schema [JLS99]) : le schma en ocon est driv du schma en toile o les tables de dimensions sont normalises (la table de faits reste inchange) an de permettre une reprsentation plus explicite de la hirarchie et de rduire les redondances. Le schma en constellation (factake schema [CD97]) : la modlisation en constellation consiste fusionner plusieurs modles en toile qui utilisent des dimensions communes. Ces diffrentes relations de faits composent une famille qui partage les dimensions mais o chaque relation de faits a ses propres dimensions[BCA01] .
1.3
Architecture dun systme dcisionnel
Les systmes daide la dcision sont employs dans tous les domaines o la prise de dcision est ncessaire, savoir, les domaines du commerce (marketing, ventes), de la logistique, de la sant (aide la dcision mdicale), de la science (par exemple en bioinformatique), des tlcommunications, des transports (trac autoroutier), des banques, ... Ces outils permettent aux dcideurs davoir une vision globale sur les activits dune entreprise par un accs rapide et interactif un ensemble de vues des donnes organises pour reter laspect multidimensionnel des donnes de lentreprise [Colliat96]. Dnition 3.1 (Systme daide la dcision) Lensemble des outils informatiques (matriels et logiciels) qui permettent lanalyse des donnes oprationnelles issues du systme dinformation des entreprises. Ces donnes sont transformes en une vision oriente dcideur puis analyses au moyen de manipulations et restitutions adaptes.
F IGURE 1.3 Architecture dun systme dcisionnel Larchitecture type dun systme dcisionnel est compose de deux niveaux de stockage
10
Projet Fin dEtude
(entrept et magasin de donnes) et de deux niveaux fonctionnels (outils ETL 5 et outils de restitution et danalyse) . Donc, elle peut tre reprsente en quatre niveaux [Alain09] comme se dcrit dans la Figure 1.3 tir de [Ronan07] : 1. Le premier niveau est celui des sources de donnes, celui des systmes source, savoir le systme de gestion de lentreprise contenant les bases de donnes oprationnelles ainsi que des sources externes. La collecte des donnes fait gnralement appel un logiciel ETL (Extract, Transform, Load) pour prparer les donnes qui seront stockes dans des bases spcialises par mtier et organises en vue de leur analyse. 2. Le deuxime niveau concerne la rcupration, la transformation des donnes, puis lalimentation dun entrept de donnes qui est un espace de stockage centralis et uniforme. Ainsi, son organisation permet de faciliter lintgration des donnes et de conserver leurs volutions. Donc, les donnes brutes du SGBDR de production ne se prtent pas facilement des analyses, les donnes sont donc stockes dans les bases spcialises entrept et magasin de donnes. 3. Le troisime niveau est celui de lexploitation de lentrept en question, celui ci tant organis de telle manire que lon puisse, par fonction de lentreprise, rcuprer linformation mais avec une capacit dagrgation des donnes par mtier. Les magasins de donnes, considrs comme des bases de donnes mtier, sont en fait extraits des entrepts de donnes. 4. Le quatrime et dernier niveau fournit lutilisateur le moyen de composer sa propre analyse et de restituer les donnes sous une forme adapte aux dcideurs. Les donnes sont alors accessibles et exploitables par diffrentes familles doutils : des tableaux de bords, des outils de datamining, des outils OLAP.
1.3.1
Alimentation (ETL) dun entrept de donnes
Pour rsumer, nous venons de voir que la BI 6 permet de transformer des donnes en information et linformation en savoir, an de gnrer des indicateurs trs utiles. Pour analyser les donnes, il est indispensable de les rassembler en un seul endroit. Or, les donnes dune entreprise se trouvent dans de multiples endroits et, souvent, elles ne sont pas cohrentes. An de rassembler et de nettoyer les donnes, nous utilisons un logiciel de type ETL qui se dnit daprs [Natacha et al.12]. 3.1 Dnition (Extract, Transform and Load) Un outil appel ETL extrait, nettoie et importe les donnes dans diffrentes sources et les charge dans un entrept de donnes. Il permet doffrir un environnement de dveloppement et des outils de gestion des oprations et de maintenance.
5. Extract, Transform, Load 6. Business Intelligence
11
Projet Fin dEtude
Pour ce faire, le processus dETL respecte les trois tapes dextraction, de transformation et de chargement daprs [Alain09] : 1. La phase dextraction : consiste en identication et puration des donnes, seules les donnes destines lexploitation pour analyser un sujet bien prcis seront gardes. Pour extraire les donnes utiles, loutil dETL doit pouvoir se connecter aux diffrentes sources disposition, quil sagisse dapplications ou des bases en production. En consquence, les ETL utilisent des moteurs dextraction ou des programmes ad hoc gnrs par des outils ddis. En ce sens, ils jouent un rle dintgration au niveau des donnes. 2. La phase de transformation : regroupe les oprations de mise au format ncessaire des donnes, de calcul des donnes secondaires et de fusion ou dclatement des informations composites. Cette tape de transformation comprend aussi une phase dagrgation des donnes. Le niveau dagrgation est choisi au moment de la construction de lentrept et les donnes initiales seront perdues. Cest effectivement ce qui permet davoir des temps de rponse trs courts. 3. La phase de chargement : a pour rle de stocker les informations dans les entrepts de donnes. Ce stockage dpend de la manire dont est administr lentrept de donnes, le chargement de nouvelles donnes peut bien parfois craser les donnes dj existantes.
1.4
Linterrogation des bases des donnes multidimensionnelles
Dans un contexte danalyse dcisionnelle, lutilisateur a besoin dinformations agrges, rsumes et observables sur plusieurs niveaux de prcision. Lintrt des dcideurs ne se situe alors plus dans lanalyse dtaille des individus mais plutt dans la recherche de tendances gnrales concernant un ensemble dindividus. Ds lors, un modle de traitement OLTP pour raliser de telles oprations est inadquat car de nombreuses et couteuses jointures seraient ncessaires et dgraderaient les performances du systme. Une base de donnes multidimensionnelle stocke alors les donnes de manire permettre des analyses dcisionnelles. A lintersection de plusieurs dimensions, se trouvent des valeurs, galement nommes indicateurs ou variables. Ces valeurs sont extraites de la base de production, ou peuvent tre calcules par le moteur OLAP. Ce modle de traitement OLAP reprsente la solution adquate pour le systme plus performant. Ainsi, il permet aux dcideurs davoir accs rapidement et de manire interactive une information pertinente prsente sous des angles divers et multiples, selon leurs besoins particuliers. Pour rpondre a ce besoin et permettre des rponses effectues a des requtes complexes poses sur un grand volume de donnes, les entrepts de donnes sont apparus.
12
Projet Fin dEtude
1.4.1
Le modle de donnes dans notre contexte
Nous modlisons un cube de donnes de manire classique et frquemment utilise comme un schma en toile. Ainsi, dun point de vue conceptuel, la modlisation multidimensionnelle est lie aux concepts de cube, de fait et de dimension. [Lamia06] qui sest base sur les travaux de [Ravat et al.] relatifs la modlisation et la fusion de donnes multidimensionnelles, a montr que les concepts de base de la modlisation multidimensionnelle ont t dnis formellement, : Dnition 4.1.1 (Fait). Un fait Fj est dni par (NFj , MFj , IFj ) o : NFj est le nom de fait, MFj = {m1 , m2 ,...., mw } est un ensemble de mesures (ou indicateurs danalyse), IFj = {IF1, IF2 , .....,IFw } est lensemble des instances de F. Dnition 4.1.2 (Dimension). Une dimension Di est dnie par (NDi , ADi , HDi , IDi ) o : NDi est le nom de la dimension, ADi = {aDi-1 ,aDi-2 ,....., aDi-u } est un ensemble dattributs, ADi = {hDi-1 ,hDi-2 ,....., hDi-y } est un ensemble des hirarchies, IDi = {IDi-1 , IDi-1 } est lensemble des instances de Di . Dnition 4.1.3 (Hirarchie). Une hirarchie hDix dnie sur la dimension Di est un chemin lmentaire acyclique dbutant sur lattribut de plus faible granularit et se terminant par u attribut de plus forte granularit. Elle est dnie par (NDi-x , ParamaDi-x , SuppDi-x ) o : NDi-x est le nom de la hirarchie, ParamaDi-x = < aDi-x , aDi-1 ,...., aDi-z > est un ensemble ordonn dcrivant la hirarchie des attributs (chaque attribut est appel paramtre de la hirarchie et correspond un niveau de granularit danalyse), SuppDi-x : ParamaDi-x -> 2^ADi-ParamaDi-x est une application spciant les attributs faibles qui compltent la smantique des paramtres (chaque paramtre est associ un ensemble dattributs faibles). Dnition 4.1.4 (Cube de Donnes). Un cube est un ensemble de donnes organises selon des dimensions. On appelle mesure la valeur contenue dans une cellule du cube, associe aux valeurs prises sur les dimensions composant le cube. Un cube de donnes contient le sujet danalyse (les mesures du fait) qui est plac au centre dun espace plusieurs perspectives danalyses (les dimensions). Une cellule reprsente lunique intersection logique dans un cube dun membre de chaque dimension du cube.
1.4.2
Les langages de manipulation de donnes
En termes de manipulation multidimensionnelle, les premiers travaux sur les manipulations OLAP ont tendu les oprateurs de lalgbre relationnelle pour le modle en cube [Gray et al.97],
13
Projet Fin dEtude
[Agrawal et al.97] (une transcription SQL 7 des oprations est disponible dans [Agrawal et al.95]), [Li et Wan.96], [Gyss et Laksh97] et [Datt et Thom99]. Pour contourner linadaptabilit de lalgbre relationnelle en ce qui concerne la manipulation de structures multidimensionnelles dans un contexte OLAP, de nombreux travaux ont propos des oprateurs et des oprations pour spcier et manipuler un cube[Cabi et Torlo.97], [Cabi et Torlo.98], [Abell et al.03], [Pedersen et al.01] et [Fran et Kam.04] . An dexplorer un cube, lutilisateur a besoin doprations et dun langage de manipulation de donnes. Dans le domaine des bases de donnes relationnelles, il existe des oprations relationnelles et le langage standard est le langage SQL. Nous prsentons dans cette section les oprations propres au requtage multidimensionnel ainsi quun langage appropri. 1.4.2.1 Algbre pour la manipulation OLAP
Les oprations OLAP lmentaires [[CD97],[RA07]] sont traditionnellement rparties en trois catgories : 1. Les oprateurs de restructuration : permettent de changer la structure selon laquelle les donnes sont visualises : ADDCHARACTERISTIC : ajout dune caractristique , DLTCHARACTERISTIC : suppression dune caractristique, NEST : imbrication dun attribut, ADDMODALITY : ajout dune modalit, PULL : conversion dune mesure , PUSH : conversion dune dimension. 2. Les oprateurs de navigation : permettent de naviguer travers des donnes multidimensionnelles selon plusieurs niveaux de granularit 3. Les oprateurs n-aires : qui permettent la manipulation de donnes multidimensionnelles qui sont : UNION : union de deux cubes de donnes , INTERSECT : intersection de deux cubes de donnes, DIFFERENCE : diffrence de deux cubes de donnes. Nous ne rentrerons pas dans le dtail de chaque catgorie doprations. Notons cependant que les oprations OLAP les plus utilises sont les oprateurs de navigation [JLVV01] : Roll-up / Consolidate : naviguer vers une granularit plus grossire. Un roll-up correspond donc un zoom-out du cube actuel, ce qui entraine un rsultat de granularit rduite. Par exemple roll-up du cube (catgorie/ mois/ ville) vers (type/ mois/ ville). Cette opration peut porter sur une ou plusieurs dimensions la fois. Il est galement possible de naviguer
7. Structured Query Language
14
Projet Fin dEtude
vers la racine TopD (TopDimension) cest dire vers le niveau ALL dune ou de plusieurs dimensions. Drill-down : naviguer vers une granularit plus ne. Drill-down est lopration inverse de Roll-Up. Il rend possible la navigation dune granularit donne vers une granularit plus ne pour une ou plusieurs dimensions (zoom-in). Par exemple de (type / trimestre / ville) vers
(type / mois / ville).
Drill-out / Split : ajouter une ou plusieurs dimension. Lors dun drill-out (aussi nomm split), cube n dimensions est complt par k dimensions de granularit plus ne que TopD, o k >= 1. Le rsultat est un cube (n+k) dimensions. Comme drill-down, drill-out navigue vers des donnes plus dtailles. Contrairement drill-down, le dtail nest pas augment par laugmentation de la granularit dune dimension existante, mais par lajout de nouvelles informations dune nouvelle dimension. Drill-in / Merge : rduire le cube dune ou de plusieurs dimensions. Opration inverse de drill-out. Un drill-in (nomm galement merge) efface k dimensions dun cube n-dimensionnel, o k < n. Le rsultat est un cube (n-k) dimensions. Comme pour roll-up, les donnes rsultant dun drill-in sont moins dtailles que les donnes dentre de lopration. Contrairement au roll-up, le degr de dtail nest pas rduit par rduction de la granularit, mais par llimination de dimensions. Slice : slectionner des donnes en appliquant un critre de slection une dimension. Permet lobtention dun extrait des informations reprsentes par un cube en fonction des termes dnis pour une dimension. Le paramtre de loprateur slice est un critre de slection (range query, point query) portant sur une dimension. Le critre de slection avec AND, OR et NOT. Par exemple (mois > fev.) AND (mois <= nov.) AND (mois NOT avr). Dice : slectionner des donnes en appliquant une slection plusieurs dimensions. Application de loprateur slice plusieurs dimensions. Par exemple slice(mois = jan, Temps) AND slice (ville = Berlin, Lieu) . Slice ne peut produire que des tranches du cube, du fait quune slection nest possible que sur une dimension, alors que Dice peut produire des sous-cubes arbitraires. Pivot (ou Rotate) : cet oprateur de restructuration roriente la vue multidimensionnelle en tournant le cube. Donc, une visualisation 3D (3 Dimesions) des sries de plans 2D (2 Dimesions). La communaut des bases de donnes sest intresse la dnition dun langage ddi aux donnes multidimensionnelles. Plusieurs travaux ont t proposs, citons par exemple, [[AGS97], [GL97], [CT98]], le travail de synthse [JLVV01] ou, plus rcemment [RTTZ08]. Chaque langage prsente des proprits qui lui sont spciques et aucun langage multidimensionnel formel standard na t tabli. Notons cependant quen pratique, le langage utilis par tous les serveurs OLAP, que ce soit
15
Projet Fin dEtude
[[SAS09], [Pen09]] ou rcemment[ORA09], est le langage MDX 8 propos par [Mic98]. Il est dot dune syntaxe de type SQL et reprsente un moyen syntaxique dinterrogation des donnes multidimensionnelles dun cube.
1.4.3
Le langage utilis dans notre approche
Dans notre approche, le langage utilis est MDX qui est le langage le plus utilis pour la manipulation de donnes multidimensionnelles. En particulier, nous nous intressons un sous-ensemble du langage MDX. Nous en donnons une dnition simple dans ce qui suit. Notons quune tentative de formalisation complte a t propose par [MVSV03]. Le serveur OLAP interroge une base multidimensionnelle en utilisant gnralement le langage MDX, introduit par Microsoft avec SQL Server Analysis Services (Microsoft, 2005 ) mais aussi employ par dautres produits tels que Hyperion Essbase et le serveur OLAP open source Mondrian (Pentaho, 2007), le langage MDX sencapsule aujourdhui dans des balises XMLA 9 . XMLA dnit laccs des systmes analytiques comme OLAP ou les outils de datamining. Contrairement SQL, MDX nest pas maintenu par une organisation indpendante de normalisation et daprs Julian Hyde, fondateur du serveur Mondrian, linteroprabilit entre clients et serveurs OLAP nest pas pour aujourdhui [July09]. A la diffrence SQL, MDX est fait pour naviguer dans les bases multidimensionnelles et pour dnir des requtes sur tous leurs objets (dimensions, hirarchies, niveaux, membres et cellules) an dobtenir (simplement) une reprsentation sous forme de tableaux croiss. MDX est un langage dinterrogation des bases multidimensionnelles plus adapt que le classique SQL pour le traitement des requtes de type OLAP. Il ressemble SQL par ses mots cl SELECT, FROM, WHERE, mais, SQL construit des vues relationnelles alors que MDX construits des vues multidimensionnelles des donnes. Exemple 4.3.1 Considrons la requte suivante : SELECT Crossjoin({[Vehicule].[Marque].[Peugeot]}, {[Agence].[Ville].[Jerba], [Agence].[Ville].[Bizert] }) ON ROWS, {[Temps].[Anne].Members} ON COLUMNS FROM [Locations] WHERE {[Mesures].[Montant]} ; Cette expression MDX recherche les cellules contenant le Montant (clause WHERE) des locations (clause FROM) de vhicules Peugeot en villes Jerba et Bizert pour toutes les annes possibles (clause SELECT). Elle indique aussi que les membres des dimensions Vehicules
8. Multi Dimensionnelle eXpression 9. XML for Analysis
16
Projet Fin dEtude
et Agence seront imbriqus (Crossjoin) et seront afchs en lignes (ON ROWS), tandis que les membres de la dimension Temps apparatront en colonnes (ON COLUMNS). La structure dafchage du rsultat est donc spcie par lutilisateur grce aux clauses CROSSJOIN et ON dans la clause SELECT. En effet, MDX fournit plusieurs faons avec lesquelles un cube peuvent tre interroges, il fournit des fonctions diffrentes. Avec MDX, nous pouvons mme crer, modier et supprimer des cubes si ncessaire. Plus prcisment, la forme syntaxique des requtes MDX quest prsente ci-dessus et leur reprsentation peut tre faite sous forme de tuple, comme dni ci-dessous daprs [Elsa.09]. Dnition 4.3.2 (Requte MDX) Soit un cube de donnes N-dimensionnel C = <D1 ,...,DN , F> et une requte MDX sur C note qMDX , est une requte exprime dans le langage MDX qui peut se reprsenter par un n-uplet : qMDX = <q1 ,....,qN } o : i [1,N], qi est une requte de lalgbre relationnelle. Elle permet dobtenir les membres de la dimension Di . Les rfrences de la requte qMDX sont lensemble des rfrences de qMDX , ref (qMDX ) = q1 (D1 ) x .... qN(DN ) = xi=1 N qi (Di ). 1.4.3.1 Les concepts de MDX :
MDX est fait pour naviguer dans les bases multidimensionnelles et pour dnir des requtes sur tous les objets (dimensions, hirarchies, niveaux, membres et cellules) an dobtenir une reprsentation sous forme de tableaux. La structure dune requte MDX est identique la structure des clauses SELECT-FROM-WHERE en SQL, mais la smantique est diffrente. La structure gnrale dune requte MDX est [Bern.09] : SELECT [<axis_specication> [<spcication_des_axes>...]] FROM [<spcication_d_un_cube>] [WHERE [<spcication_de_ltres>]] MDX est caractris par diffrents lments [Daniel], [Bern.09] qui sont : 1. Spcication de Membre : cest une instance dun niveau dune dimension, spci entre crochets [..]. Un membre dsigne la valeur dun attribut de dimension, notamment la dimension de mesures. Au sein dune hirarchie, un membre peut tre un membre feuille, un membre parent, un membre de donnes ou un membre (All). Par exemple [Food], [Drink] sont des membres de la dimension "Products" au niveau 1. Les enfants (children) dun membre sont tous les membres du niveau immdiatement en dessous de celui-ci comme : [Product].[All Products].[Food].[Baked Goods] 2. Spcication de tuple : un tuple identie de manire unique une cellule sur la base dune combinaison de membres dattribut composs dun attribut issu de chaque hirarchie dattribut au sein du cube. Lorsque vous dnissez un tuple dans une requte ou une
17
Projet Fin dEtude
expression MDX, vous navez pas besoin dinclure le membre dattribut de chaque hirarchie dattribut de manire explicite. Chaque membre est spar par une virgule. Par exemple, le tuple ([Time].[1997],[Product].[Food]) croisera les donnes du membre de la dimension spatiale Time et du membre de la dimension temporelle Product . 3. Spcification de sets : MDX propose des fonctions classiques de thorie des ensembles, pour des ensembles (set) de membres ou de tuples. Dans un set , la seule restriction est que tous les lments ont la mme structure. Un ensemble ordonn de n-uplets. Prx et sufx des crochets, les lments qui le compose sont spars par une virgule. Voil un exemple qui explique un sets : Select { ([Measures].[Unit Sales], [Product].[All Products].[Food].[Baked Goods]), ([Measures].[Store Sales], [Product].[All Products].[Food].[Baked Goods]) } on columns { ([Time].[1997]), ([Time].[1998]) } on rows from [Sales] 4. Spcication daxe : plusieurs spcications possibles pour un mme axe en MDX. Un set suivi du mot clef ON suivi dun nom daxe spcique fait rfrence un numro dordre sil y a plus de deux axes de restitution, ou simplement aux noms daxes explicites COLUMNS et ROWS. Par exemple : Select { ([Measures].[Unit Sales], [Product].[Food])} on columns, { ([Time].[1997])} on rows from [Sales] 5. Spcication de ltres (Slicers) : dans MDX , lopration de Slice est traite par une clause WHERE. On suppose que nous souhaitons navoir que les ventes concernant les consommateurs de sexe masculin. Nous obtenons ce rsultat avec la requte suivante : Select { ([Measures].[Unit Sales], [Product].[Drink]) }on columns, { ([Time].[1997]), ([Time].[1998]) } on rows from [Sales] where { ([Gender].[M]) Exemple 2.1.5 : Considrons la requte suivante : SELECT CROSSJOIN({Berlin, Stuttgart} {kiosque, [grande surface]} ON ROWS, { 2010.CHILDREN } ON COLUMNS FROM [CubeVentes] WHERE ( Measures.Ventes, Temps.[2010], Produit.[mdias] ) Le rsultat de cette requte est reprsente dans la gure suivante :
18
Projet Fin dEtude
F IGURE 1.4 Rsultat dune requte MDX Parmi les fonctions sur ( sets), on cite la fonction CrossJoin permet de croiser des sets et ainsi raliser des tableaux croiss. Etant donn un set A et un set B, CrossJoin construit un nouveau set contenant tous les tuples (a,b) o a est dans A et b dans B. Cest une projection de deux dimensions en une seule.
Conclusion
Au cours de ce chapitre, nous avons prsent une vue densemble des entrepts de donnes, puis un aperu de modle de donnes de notre contexte pour linterrogation de donnes multidimensionnelles en passant par les langages de manipulation de donnes. Une fois que les donnes sont charges, les dcideurs ralisent des sessions danalyses en utilisant des outils OLAP tels que des requtes MDX sur les cubes de donnes an de trouver les solutions diffrentes tches dcisionnelles. En effet, les systmes dinformation deviennent de plus en plus complexes. On parle dsormais dobjets obissant des rgles statiques (contraintes dintgrit par exemple) et dynamiques (rgles de comportement). Lexploration des donnes dans un cube OLAP ncessite une connaissance du mtier pour dceler et bien comprendre la smantique lie certaines donnes agrges. Sans cette connaissance, un utilisateur nest pas apte interprter la constance ou la variation des agrgats mensuels au cours dune anne dans un environnement de grande distribution par exemple. Do, lintrt dintgrer des scnarios danalyse dans un entrept pour aider un utilisateur effectuer des analyses pertinentes. Nous abordons alors dans le chapitre 3 les travaux traitant de cette problmatique dvolution, qui constitue notre contexte de travail. Donc, lobjectif de ce projet est de proposer une modlisation des vnements complexes et leur intgration dans un entrept de donnes pour automatiser des scnario danalyse.
19
CHAPITRE 2. ETAT DE LART
Projet Fin dEtude
Chapitre 2 Etat de lart
Introduction
ans les annes 1980, les recherches sur les rgles dductives permettent de driver de nouvelles informations partir de linformation existante, ou de tester la cohrence de linformation contenue dans la base de donnes. Un SGBD 1 dductif est un systme qui comporte des possibilits pour dnir des rgles qui peuvent dduire ou infrer des informations partir de faits stocks dans une base de donnes. Dans Un SGBD dductif, un langage dclaratif est utilis pour spcier des rgles. Un mcanisme dinfrence (ou mcanisme de dduction) peut alors dduire de nouveaux faits partir de la base de donnes en interprtant les rgles. Malheureusement, les recherches sur les bases de donnes dductives ne donnent pas naissance des technologies facilement utilisables sur le terrain. Dans la dcennie suivante, les technologies des systmes de gestion de bases de donnes objet-relationnels apparaissent en permettant de construire des bases de donnes dites actives. Selon Barros, par le biais de prdicats, du mcanisme ECA 2 , des dclencheurs (triggers) et de procdures stockes, il est dsormais possible de grer non seulement les aspects statiques des objets mais aussi leur comportement [Bar04]. Dans ce chapitre, nous proposons dans un premier temps de se familiariser avec les concepts de bases de donnes actives. Dans un deuxime temps, nous prsentons le nouveau concept dentrept de donnes actif. Enn, nous prsentons notre positionnement et notre proposition.
1. Systme de Gestion de Base de donnes 2. Evnement-Condition-Action
20
CHAPITRE 2. LETAT DE LART
Projet Fin dEtude
2.1
Les bases de donnes actives
Les systmes de gestion de bases de donnes permettent le stockage de gros volumes de donnes et fournissent des langages puissants dinterrogation et de manipulation des donnes quils stockent. Toutefois, ces systmes restent passifs car tout traitement sur la base de donnes se fait sur demande explicite (requte ou commande) dun utilisateur ou dun programme dapplication. Dans les systmes de gestion de bases de donnes actives (ADBMS 3 ), les transactions ont la capacit de surveiller les objets de la base de donnes et de prendre des mesures spciques quand un vnement particulier se produit dans les objets de base de donnes. Par exemple, lorsque la quantit en stock dun produit devient infrieure un certain seuil, une demande dapprovisionnement est dclenche automatiquement. Ceci est indiqu au moyen des rgles dvnement-Condition-Action (ou rgles ECA). Les vnements, dans une base de donnes active, peuvent se produire suite une transaction qui dcrit un changement dtat dans un objet ou en raison des changements dtat produits, dans des objets, par dautres transactions fonctionnant en parallle. Cependant, les systmes de gestion de bases de donnes se rvlent souvent trs limits pour grer explicitement la dynamique des bases de donnes, et en particulier de ragir aux changements dtats des bases de donnes. En effet, dans ces systmes, toutes les oprations de manipulation de donnes sont effectues explicitement suite une demande dun utilisateur ou dun programme dapplication. Ces derniers sont qualis de passifs, par opposition aux systmes actifs, qui eux, sont capables deffectuer automatiquement des actions prdnies, en rponse des vnements spciques, lorsque certaines conditions sont satisfaites.
2.1.1
Les bases de donnes actives
Les bases de donnes actives vues par Smith, Dayal et al. offrent toutes les fonctionnalits dune base de donnes traditionnelle et, en plus, sont capables de ragir, avec ou sans lintervention de lutilisateur, des modications dans ltat de la base de donnes ou de son environnement [Smi92] et [DHW95]. Cette capacit de ragir est due lintgration de rgles de production dans la base de donnes. Ces rgles sont dclenches par des transitions dtat dans la base de donnes. Elles valuent ensuite des prdicats qui portent sur ltat de cette base et excutent les actions associes. Les rgles de production permettent la dnition doprations de base de donnes qui sont excutes automatiquement quand certains vnements ont lieu ou quand des conditions sont satisfaites. Une autre approche consiste raliser des SGBD qui sont capables de ragir face certains vnements : cette forme dinteraction est appele (HADP) 4 . Utilisant ce modle dinteraction,
3. Active Database Management Systems 4. Human-Active Database-Passive
21
Projet Fin dEtude
il nest pas possible de demander au systme denvoyer des notications quand les situations prdnies sont dtectes. Des systmes de base de donnes actifs ont t dvelopps pour surmonter cette limitation : on peut les voir comme une extension de DBMSs 5 classique o le comportement ractif peut tre dplac, totalement ou en partie, de la couche dapplication dans le DBMS. Il y a plusieurs outils classs comme des systmes de base de donnes actifs, avec diffrentes architectures logicielles, orients vers les domaines dapplication. Ainsi, il est possible de les classier sur la base de leur modle de connaissance et dexcution [Pato et Diaz.99]. Le premier dcrit la sorte des rgles actives qui peuvent tre exprimes, tandis que le dernier dnit le comportement pendant lexcution du systme. Le modle de connaissance considre toujours que les rgles actives sont composes en trois parties : Evnement : dnit quelles sont les sources qui peuvent tre considres comme des gnrateurs dvnements : quelques systmes considrent seulement des oprateurs internes, comme une insertion ou un mise jour de tuple. Tandis que dautres permettent aussi des vnements externes, comme ceux augments par des montres ou des capteurs externes. Condition : spcie quand un vnement doit tre pris en compte, par exemple nous pouvons tre intress seulement par quelques donnes si elles dpassent une limite dnie. Action : identie lensemble des tches qui devraient tre excutes comme une rponse une dtection dvnement : quelques systmes permettent uniquement des modication de base de donnes internes,alors que dautres permettent lapplication dtre noti propos de la situation identie. Le modle dexcution dnit comment ces rgles ECA sont traites au temps dexcution. Donc, cinq phases ont t identies : Signalisation : dtection dun vnement, Dclenchement : association dun vnement avec lensemble de rgles qui sont dj dnies, valuation : valuation de la partie conditionnelle pour chaque rgle dclenche, Planication : dnition dun ordre dexcution entre des rgles choisies, Excution : excution de toutes les actions associes aux rgles choisies. Les systmes de base de donnes actifs sont utiliss dans trois contextes : comme une extension de bases de donnes, dans les applications de bases de donnes fermes et ouvertes. Comme une extension de bases de donnes, les rgles actives se rfrent seulement ltat interne de la base de donnes, par exemple, mettre en uvre une raction automatique aux violations de contrainte. Dans les applications de base de donnes fermes, les rgles actives peuvent supporter la smantique de lapplication, mais les sources externes dvnements ne sont pas autoriss. Finalement, dans les applications de base de donnes ouvertes, les vnements peuvent venir des sources externes en
5. Data Stream Management Systems
22
Projet Fin dEtude
tant de lintrieur de la base de donnes. Le gestionnaire des rgles qui est inclus dans le systme de la gestion de la base de donnes dOracle, excute les rgles ECA avec la rgle de la terminologie de langage IF THEN. Alors les procdures daction peuvent tre mis en uvre par les procdures SQL. Ces rgles et ces actions correspondantes sont stockes dans les tables de la base de donnes [Han et Davi.07]. La Figure 2.1 reprsente un exemple de la dnition des vnements, des rgles et des actions dans le SGBD Oracle [Oracle 2006]
F IGURE 2.1 Architecture de gestionnaire de rgles Oracle et exemple de code [Oracle 2006] Une rgle est une directive visant guider ou inuencer un comportement du processus. Elle se compose dune expression conditionnelle qui est spcie en utilisant des attributs dnis dans la structure de lvnement correspondant et dune action de rgle ayant lieu lorsque la condition est satisfaite par une instance de lvnement. Les composants ECA sont dnies comme suit : vnement : les informations dtat pour le processus, Condition : la condition boolenne qui renvoie vrai ou faux pour un vnement, Action : laction effectuer si la condition de la rgle est value vrai pour lvnement. La notation standard pour les rgles ECA est la suivante : ON <event structure> IF <condition>
23
Projet Fin dEtude
THEN <action> Les rgles actives ont t utilises tout dabord pour la vrication et lvaluation des contraintes dintgrit. La seule action possible en cas de violation dune contrainte dintgrit tait le rejet de toute opration qui provoquait son viol. Avec les rgles actives, dautres types dactions sont pris en compte. Par exemple, des actions correctives (comme la rpercussion des mises jour), des avertissements et des exceptions. Les rgles ont ainsi permit la spcication dune classe plus grande de contraintes dintgrit. Les bases de donnes actives [Bar04] sont apparues pour pallier les limites des bases de donnes dductives et de grer non seulement les aspects statiques des objets mais aussi leur comportement et ceci a t effectu grce aux technologies des prdicats, le mcanisme ECA, les triggers et les procdures centralises. Avec laccroissement exponentiel de la volumtrie des donnes, les entreprises privilgient le dcisionnel et passent dune simple gestion de donnes une logique danalyse des donnes. Cependant, les travaux prcits se sont montrs intresss par les bases de donnes actives. Alors que les chercheurs ont nglig les entrepts de de donnes actifs. En effet, pour faire face aux nouveaux enjeux, lentreprise doit collecter, traiter et analyser les donnes de son environnement pour anticiper. Cest pour cel, on est cens de crer les moyens ncessaires pour rpondre aux exigences de lentreprise.
2.1.2
Les rgles ECA
Les rgles actives ECA, vues par Bailey et al., gnralisent la notion de dclencheur, elles utilisent gnralement le formalisme Evnement-Condition-Action [BDR04]. La smantique la plus gnrale dune rgle ECA est la suivante : lorsque survient un vnement E, si la condition C est satisfaite alors excuter laction A. Les rgles ECA sont parfois aflies aux rgles de production des systmes dductifs, gnralement de la forme Evnement-Action. Le modle dexcution des rgles actives introduit plus prcisment la smantique du concept de rgle. Il est possible de distinguer trois tapes dans lexcution dune rgle : son activation partir de lvnement dni, lvaluation de la condition et lexcution de laction. Lvnement dans les rgles ECA est utilis pour spcier le fait qui doit se raliser dans la base de donnes active pour que la rgle soit active, la condition soit value et laction soit excute si la condition est bien videmment varie. La partie "action", quant elle, peut tre un ordre arbitraire dinsertion, de mise jour, de suppression, de rapports transactionnels, etc. Enn la partie "condition" dune rgle ECA reprsente un simple attribut boolen ou une question, qui empche la rgle dexcuter laction si jamais la condition est viole. Depuis que les rgles danalyse sont fondamentalement dtermines par une horloge, le modle dvnement dun entrept de donnes actif est plus primitif que le modle dvnement des systmes des bases de donnes actives. Les concepts de rgle danalyse et dentrept de donnes
24
CHAPITRE 2. LETAT DE LART actif feront lobjet de la section suivante.
Projet Fin dEtude
2.2
Les entrepts de donnes actifs
Nous pouvons galement citer des travaux qui se sont intresss rendre les entrepts de donnes actifs. Il sagit de les munir des rgles danalyse devant tre dnie par les dcideurs. En effet, ces travaux ont pour objectif de reproduire le travail de lanalyste an dautomatiser certaines tches danalyse rcurrentes et ventuellement impacter les donnes sources de lentrept en fonction des rsultats de ces analyses [TSM01] ,[TS02].
2.2.1
Les entrepts de donnes passifs vers les entrepts de donnes actifs
En intgrant la notion dentrept de donnes, le processus dcisionnel apporte une premire rponse au problme de la croissance continuelle des donnes. De plus, il supporte efcacement les processus danalyse en ligne OLAP, et de fouille de donnes (data mining) permettant ainsi lanalyse des donnes et lextraction des connaissances partir des donnes. Le but danalyse et la prise de dcision savre difcile et fastidieuse lors dexploitation des donnes stockes dans des systmes oprationnels de lentreprise. Selon Thalhammer et al., les entrepts de donnes et le systme OLAP traditionnels offrent un support limit pour automatiser les tches de prise de dcision : Les entrept passifs. Donc, toutes les taches relies lanalyse des donnes et la prise de dcision doivent tre effectues manuellement par les analystes. Cependant, selon Thalhammer et al., les entrepts de donnes et le systme OLAP traditionnels offrent un support limit pour automatiser les tches de prise de dcision qui se produisent frquemment et pour lesquelles des procdures bien tablies de dcision sont disponibles, [TSM01]. Les auteurs considrent les entrepts de donnes conventionnels comme des entrepts passifs. Ils partent dune architecture classique dun entrept de donnes et intgrent une couche supplmentaire qui permet de grer des rgles danalyse. Un nouveau concept dit entrept de donnes actif qui adopte la stratgie automatise pour la prise de dcision t propos par [TSM01] et reprsent dans la Figure 2.2, ainsi le processus automatis sappelle : les rgles danalyse. Daprs Polyzotis et al., un entrept de donnes actif est rgnr en ligne et ralise ainsi une uniformit du temps plus leve entre linformation stocke et les dernires mises jour de donnes [PSV02]. Le besoin de rafraichissement en ligne dentrept prsente plusieurs ds dans lexcution des transformations de lentrept, en ce qui concerne leur temps dexcution et leurs frais gnraux aux processus dentrept. [TSM01] essayent de combiner des mcanismes actifs bass sur des rgles ECA. Pour ce faire, ils essayent dintgrer des possibilits ractives dans lenvironnement danalyse des entrepts de donnes dans le but de prolonger ces systmes passifs. Les rgles ECA qui imitent la tche
25
Projet Fin dEtude
dun analyste sappellent les rgles danalyse. Lide fondamentale derrire les rgles danalyse, est de prolonger les rgles conventionnelles ECA des systmes actifs de base de donnes avec des dispositifs multidimensionnels (cubes, oprateurs OLAP) des entrepts de donnes et dune approche pour la prise de dcision.
F IGURE 2.2 Entrept de donnes actif [TSM01]
2.2.2
Les rgles danalyse
Selon Thalhammer et al. [TSM01], les rgles danalyse ont la mme structure que les rgles ECA, mais elles effectuent des analyses beaucoup plus complexes laide doprateurs OLAP sur des donnes dentrept au lieu dvaluer des conditions simples comme le cas des rgles ECA. La partie "vnement" dune rgle danalyse reprsente les points de temps au cours desquels des procds de dcision devraient tre lancs. Donc, un vnement peut correspondre un point xe du calendrier (par exemple la n du mois) ou bien un changement dtat dans les bases de donnes de production (par exemple le chiffre daffaire relatif certains produits dpasse une valeur dun seuil dni par les utilisateurs). Cependant, compar une rgle ECA dans une base de donnes active, celle-ci offre une varit dvnements (par exemple opration de structure, invocation de comportement, transaction, exception, horloge, ...) alors que la partie "vnement" dune rgle danalyse selon Thalhammer et al. est limite soit un vnement temporel, un vnement absolu ou un vnement relatif excut sur une base OLTP . La partie "condition" prsente lapproche Top-Down qui est habituellement effectue manuellement par lanalyste laide des outils OLAP. Contrairement aux rgles conventionnelles ECA, la partie "condition" des rgles danalyse nest pas un attribut boolen simple mais se
26
Projet Fin dEtude
compose dattributs hirarchiquement organiss qui exigent dvaluer dune faon incrmentale lexcution de lanalyse multidimensionnelle. La partie "action" dune rgle danalyse est la directive pour excuter une transaction particulire sur le systme OLTP, reprsentant la dcision pour laquelle les analyses ont t effectues. Laction pourrait galement tre une recommandation ou un avis provenant des utilisateurs pour davantage danalyses dans le cas o une dcision ne peut pas tre prise. Compares la partie "action" des rgles ECA, nous pouvons constater que les actions provenant des rgles danalyse sont plus simples [Bou07]. Pour rendre lentrept de donnes plus actif, Tho et al. proposent une nouvelle approche qui essaye de minimiser le retard se produisant lors du chargement des donnes continues partir des sources de donnes htrognes dans lentrept de donnes [TT04]. Ce chargement doit seffectuer sans interruption et doit se produire en temps rel permettant une consultation des donnes en parallle. Cette approche est une combinaison du concept dintgration continue des donnes dune part, et du concept dentrept de donnes actif dautre part en adoptant des protocoles qui permettent la collaboration entre les deux concepts. Pour les entrepts de donnes actifs, Tho et al. reprennent les rgles actives ou les rgles ECA qui reprsentent une technique drive des bases de donnes actives. Le systme peut donc traiter la saisie de donnes en temps rel, leur chargement continu mettre jour de nouvelles donnes, analyse autonome et excuter les actions accomplir dans lentrept de donnes. Bruckner et al. suggrent une approche pour modliser les problmes daccorder lhorodateur correct aux tuples de donnes et le stockage des donnes dans lentrept de donnes dans luniformit de temps[BM01]. La notion du temps est fondamentale et reprsente un aspect important des phnomnes rels. Normalement, le temps est considr comme une variable indpendante qui dtermine lordre des tats dun systme. Donc, lordre temporel peut tre tabli pendant lintgration de donnes en employant un modle fondamental de donnes qui fournit luniformit temporelle qui reprsente une caractristique cite par Bruckner et al. Les rgles danalyse sexcutent selon le mcanisme ECA et permettent une analyse en ligne complexe moyennant des oprateurs OLAP (e.g. Roll up, Drill Down, Slice and dice...). Thalhammer et al. proposent une dmarche quils qualient de multidimensionnelle pour dnir ces rgles danalyse et pour aider des dcideurs modier les prix de certains produits (au niveau des bases de donnes sources) an damliorer les ventes. Les rgles danalyse suivent une analyse multidimensionnelle utilisant le concept de graphes danalyse. Ceux-ci sont une reprsentation conceptuelle des rgles danalyse faisant intervenir des vues multidimensionnelles, ou des cubes de donnes. Pour parvenir extraire justement les rgles danalyse qui vont servir au rafraichissement de la base, Thalhammer et al. proposent une dmarche quils qualient de multidimensionnelle. Celle-ci suit une analyse multidimensionnelle utilisant le concept des graphes danalyse reprsent dans la sous-section ci-aprs.
27
Projet Fin dEtude
2.2.3
Les graphes danalyse
Les graphes danalyse, prsents dans la Figure 2.3, reprsentent tous les cubes qui sont ncessaires pour une analyse multidimensionnelle. Ces cubes sont indiqus en adoptant la mme approche Top-Down que lanalyste utilise dans la prise de dcision manuelle. Il existe deux type de cubes : les cubes locaux et les cubes globaux. Les cubes qui composent le graphe danalyse dune certaine rgle danalyse sappellent les cubes locaux, puisquils peuvent tre utiliss seulement par la rgle danalyse dans laquelle ils ont t indiqus [TSM01]. Le graphe danalyse a un seul cube racine, cest le cube le plus grossier qui est ncessaire dans la prise de dcision dune rgle danalyse. Ce cube peut tre ascendant un cube de base en adoptant lapproche Bottom-Up ou Top-Down cr partir du cube global, qui reprsente les donnes pr-agrges disponibles pour indiquer les cubes racines de plusieurs rgles danalyse.
F IGURE 2.3 Graphe danalyse Le cube racine de graphe danalyse est cr en appliquant loprateur RollUp de OLAP sur un cube de base ou en appliquant les oprateurs DrillDown, Slice ou Intersection sur les cubes globaux disponibles. Chaque cube se trouvant lintrieur du graphe danalyse est driv directement ou indirectement du cube racine en appliquant les oprateurs : DrillDown, Slice ou Intersection. Des oprateurs OLAP sont utiliss au niveau du cube grossier savoir : DrillDown, Slice et Intersection pour le rafner et par consquent avoir un cube plus spcique. Loprateur Slice permet de slectionner un sous-ensemble de cellules dans un cube. Loprateur DrillDown permet de passer dun niveau grossier de dimension un niveau de dimension plus n en prsentant les mesures avec un niveau de granularit plus n. Loprateur Intersection cre un cube plus spcique qui
28
Projet Fin dEtude
reprsente un sous-ensemble de cellules, pour lesquelles la mesure possde un niveau de granularit plus n. Pour automatiser la prise de dcision, le graphe danalyse constitue une partie indispensable aux rgles danalyse. Ces rgles doivent connaitre les cubes qui sont ncessaires lanalyse multidimensionnelle. Cette notion fera lobjet de la sous-section ci-aprs.
2.2.4
Lanalyse multidimensionnelle
Un cube OLAP contient des donnes servant des analyses. Cependant, il ne donne aucune indication sur les diffrentes oprations excuter pour aboutir un rsultat. Dailleurs, ceci constitue une limitation des entrepts classiques. Lexploration des donnes dans un cube OLAP ncessite une connaissance du mtier pour dceler et bien comprendre la smantique lie certaines donnes agrges. Sans cette connaissance, un utilisateur nest pas apte interprter la constance ou la variation des agrgats mensuels au cours dune anne dans un environnement de grande distribution par exemple. Do lintrt dintgrer des scnarios danalyse dans un entrept pour aider un utilisateur effectuer des analyses pertinentes [Bou et al.07]. Lanalyse multidimensionnelle est semblable lapproche incrmentale Top-Down que fait un analyste lors de son examen des donnes dans lentrept pour crer et analyser les cubes ncessaires la prise de dcision. Lanalyste spcie le scnario danalyse multidimensionnelle. Une rgle danalyse mule exactement la manire quun analyste examine les donnes multidimensionnelles en suivant lapproche Top-Down. Lanalyste cre diffrents cubes en utilisant les oprateurs OLAP (RollUp, DrillDown, Slice et Intersection). Ces cubes constituent le graphe danalyse correspondant lexcution dune rgle. Les cubes caractrisent les niveaux de dimension pour lesquels une dcision devrait tre prise. Pour ce faire, lanalyste examine dabord le cube grossier. Les niveaux dinstances pour lesquels une dcision peut tre prise sont marqus comme dcids et seront retirs des autres analyses. Le niveau dinstance pour lequel une dcision ne peut pas tre prise sera analys en utilisant un cube plus dtaill. Ce modle est appliqu par les rgles danalyse dans la prise de dcision [Bou07]. Un cube du graphe danalyse contient les cellules qui dcrivent les instances du niveau de la dimension primaire pour lequel la rgle danalyse devrait tre excute. Chaque cube du graphe va tre "analys" en adoptant des tapes de dcision cest--dire la condition qui doit tre satisfaite pour excuter laction de la rgle en premier et la condition qui doit tre satisfaite pour lancer des analyses plus dtailles (cubes reprsentant des donnes plus dtailles).
29
Projet Fin dEtude
F IGURE 2.4 Dmarche gnrale dun entrept de donnes actif En effet, lutilisateur gnre le graphe danalyse qui dcrit la suite doprations excuter partir de la rgle danalyse. Ainsi, nous pouvons numrer les tapes de la dclaration dun scnario danalyse relatif une rgle danalyse comme suit : Dnition des vnements, Dnition des conditions, Dnition du graphe danalyse.
2.2.5
Dclencheur (Trigger)
Ces dernires annes, il y a eu beaucoup defforts pour soutenir les tches de prparation des donnes pour lentreposage de donnes et lexploration de donnes. Bien que toutes les activits de prparation des donnes peut tre rsolu en utilisant des outils automatiss, une varit des outils logiciels qui rpondent diffrents types des tches de prparation de donnes [Abit et al.99], [Rahm et Doh.00]. Ces outils comprennent des outils de conception de bases de donnes et des outils d Extraction-Transformation-Chargement (ETL). La prparation des donnes est considre comme lune des activits qui consomme beaucoup de temps dans un entrept de donnes passif et les entreprises pourraient perdre de largent tout en attente de donnes tre nettoy. Ainsi, cette phase tend tre une tche unique avant lanalyse des donnes. Donc, pour traiter cette limitation,[Ezek et Mari.03] ont propos un mcanisme de dclenchement destin la prparation des donnes dans un environnement dynamique. Ils utilisent
30
Projet Fin dEtude
un dclencheur avec des capacits dynamiques pour soutenir les tches de prparation de donnes dans des environnements actifs ou dynamiques. Ainsi, un dclencheur mis en uvre pour raliser certaines activits de prparation des donnes (ajout, suppression, modication) depuis les concepts sous-jacents qui sont stocks dans une base de donnes. Les approches existantes sont inefcace pour lvolution rapide des donnes. Laccent est mis sur laspect syntaxique de correction des donnes, tandis que lapproche de Ezekiel et Marir met laccent sur laspect smantique laide de dclencheurs pour corriger les donnes. En manipulant et en modiant les dclencheurs, ils corrigent la signication des donnes pour les rendre prt pour lanalyse en un peu de temps et en vitant les retards de traitement. Ici, lintrt est accord au mcanisme efcient des dclencheurs qui amliorent la prparation de donnes smantique. Dnition 2.1 (Trigger). Dans les plupart des systmes de bases de donnes actives, un dclencheur (Trigger) aussi connu sous le nom des rgles ECA qui sont utilises pour suivre lvolution et dappliquer des contraintes dintgrit. Pour les environnements dentrepts de donnes actifs, les rgles ECA sont requis pour la vrication des donnes et lautomatisation des dcisions danalyse. Un dclencheur contient des informations sur les objets dynamiques qui sont Evnement, Condition et Action. Le diagramme UML dans la Figure 2.5 dcrit les spcications de dclenchement en utilisant la technologie DOM 6 .
6. Dynamic Object Model
31
Projet Fin dEtude
F IGURE 2.5 Modle dobjet dynamique dun dclencheur [Ezek et Mari.06] Lutilisation de triggers avec des capacits dynamiques permettent lutilisateur de crer rapidement et modier les rgles an dacclrer la ltration. Donc, lide propose par [Ezek et Mari.06] est dincorporer le dclencheur avec des capacits dynamiques en utilisant le concept DOM qui est un objet orient aux techniques de modlisation pour soutenir les changements dans les bases de donnes actives. 2.2.5.1 Processus dclencheur de nettoyage
La prparation des donnes amliore les rponses en rduisant le temps de prparation et permet aux analystes de prendre des dcisions plus rapides et efcaces. Une bonne prparation des donnes permet aux analystes de produire des rsultats efcaces. En ralit, TCA 7 est base sur les actions prises pour nettoyer les donnes [Ezek et Mari.06]. Ces mesures dpendent des rgles considres comme des dclencheurs et stockes dans la base de donnes. La partie dvnement dun dclencheur peut tre utilis pour effectuer des oprations telles que la mise jour, linsertion, le chargement, etc. Il est ncessaire de prciser les critres de la condition pour accepter que les valeurs qui sont nettoys et pour identier les problmes. Une fois lidentication a t faite, certaines rgles de transformation doivent tre mises en uvre. La rgle de transformation spcie laction prendre pour transformer les donnes. Cela pourrait tre lomission dun dossier, substituer une valeur de conrmation des oprations, telles que envoyer des messages dalerte ou des oprations de base de donnes, etc. Donc, lorsque la condition est
7. Trigger Cleaning Approach
32
Projet Fin dEtude
satisfaite, la partie daction dun dclencheur est active. La dnition dun dclencheur pour les processus de nettoyage consiste : 1. tablir des donnes pr-traites pour le nettoyage (Event), 2. Spcication des critres dacceptation (Condition), 3. Les rgles de transformation pour donner un ensemble de donnes plus propre (Action). Exemple 2.3.1 (Ensemble de donnes sur la maladie respiratoire) Cet exemple fait une tude sur les patients atteints dune maladie respiratoire. Le besoin danalyse (objectif mtier / rgle) tait de fournir un certain nombre de patients de plus de 50 ans souffrant dune maladie respiratoire.
TABLE 2.1 Patients souffrants dune maladie respiratoire [Ezek et Mari.06] Le dclencheur suivant sera stock dans la base de donnes pour nettoyer les donnes (Tableau 2.1). Nom du dclencheur : Plus de 50 patients respiratoire Evnement : Insert Condition : ge <50 Action : Effacer la ligne
2.3
Requtes Continues
Les requtes continues contrlent les mises jour qui attentent les seuils spcies et les rsultats de retour [Ling et al.01]. Une requte continue est constitue de trois composants cls : la requte, le dclencheur et la condition darrt. Contrairement aux requtes ad-hoc dans les SGBD conventionnels ou les systmes de requte. Une requte continue, est publie une fois et fonctionne en permanence sur lensemble des sources dinformation. A Chaque fois que la condition de dclenchement devient vraie, le nouveau rsultat sera retourn depuis lexcution prcdente de la requte. La partie de dclenchement dune requte continue spcie les vnements ou les situations surveiller. Les vnements primitifs pour la modlisation des oprations de base de donnes de base sont comme (INSERT, DELETE, UPDATE) et les vnements de temps de base sont comme ( 10h00 15 Septembre 1998 chaque 10 minutes, et aprs une heure).
33
Projet Fin dEtude
Dnition 1.2.3 (Requte continue). Une Requte continue ( CQ 8 ) est dnie par un triplet (Q, Tcq, Stop), composant dune requte normale Q (par exemple, crit en SQL), une condition de dclenchement Tcq 9 , et une condition darrt Stop. Ainsi, les requtes continues sont dnies sur des donnes passes, prsentes et futures, tandis que le domaine de requtes est limit aux donnes passes et prsentes [Ling et al.01]. Exemple 1.2.3. Supposons que nous avons une installation de demande dune requte continue "Signaler le gestionnaire de location de voiture tous les jours 8 :00 pm par toutes les activits de cette journe pour les vhicules dont le total de la dure de location atteint 60 heures" Create CQ inventory_monitoring as Query : SELECT Annee, Ville, Immat FROM location GROUP BY Immat having SUM(DUREE_LOC) > 60 ; Trigger : 8 :00 pm chaque jour ; Stop : cinq mois Query : SELECT Annee, Ville, Immat FROM Locations GROUP BY Immat having SUM(DUREE_LOC) > 60 ; Trigger : 8 :00 hr chaque jour Stop : cinq mois
2.3.1
Smantique continue
Le rsultat dexcution dune requte Q sur ltat de la base de donnes Si est comme Q (Si ). Ainsi, le rsultat dexcution dune requte continue en tant quune squence de rponses de requte {Q (S1 ), Q (S2 )..., Q (Sn )} obtenue en excutant la requte Q sur la squence dtats de base de donnes Si , 1 i n, chaque tat donne Si (i > 0), Q (Si ) est dclenche par Tcq ^ Stop. Les vnements de base qui causent des requtes continues nouveau peuvent tre les oprations de base de donnes standard telles que INSERT, DELETE, UPDATE ou les vnements qui provoquent des signaux dhorloge (par exemple, vrier le montant de location de vhicules sousse 17h00 tous les jours), ou des signaux dutilisateur ou dapplication gnres (par exemple, un signal de dfaillance dun diagnostic de routine sur une vhicule). En outre, les conditions de dclenchement surveiller peuvent tre complexe, et peuvent tre dnie non seulement sur les valeurs de donnes uniques ou des tats de bases de donnes individuelles, mais aussi sur des ensembles dobjets de donnes (par exemple, le total des commandes darticles dpasse le niveau de stock actuel).
8. Continual Query 9. Trigger condition
34
Projet Fin dEtude
2.3.2
Requtes continues vs. rgles ECA
Les requtes continues semblent tre un sous-ensemble de rgles ECA. Cependant, elles sont assez diffrentes non seulement dans la couverture des fonctionnalits et de la perspective dutilisation, mais aussi dans le modle dexcution et de larchitecture mise en uvre. Les vnements de mise jour des rgles ECA sont spcis explicitement par les utilisateurs, tandis que les vnements de mise jour des requtes continue sont implicitement impliqus dans la condition de dclenchement et drivs par le systme lors de la phase dinstallation des requtes continues. Pour les requtes continues , il y a une condition darrt STOP, par contre, les rgles ECA terminent lexcution de la rgle lorsque lutilisateur supprime manuellement la rgle de la base de rgles. Ainsi la rgle ECA utilise pour lexemple prcdent 1.2.3 est : event : insertion de la dure de location de vhicule condition : SUM(DUREE_LOC) > 60 action : envoie un ordre
2.4
Personnalisation et recommandation des systmes OLAP
La personnalisation de linformation est vue comme laction dadapter laccs linformation en fonction dinformations sur un usager ou sur un groupe dusagers. Certains travaux limitent la dnition de la personnalisation de laccs linformation ladaptation du rsultat dune requte au prol utilisateur. Daprs [Jerbi12], une dnition plus gnrale de la personnalisation est dans laquelle le service de recommandation est inclus. Une recommandation ne peut sortir du cadre de la personnalisation. Mme si la gnration dune recommandation nest pas totalement base sur le prol de lusager, elle serait calcule selon des heuristiques ou par des fonctions dutilit qui considrent indirectement des proprits du prol. Ainsi, la recommandation reprsente un service de la personnalisation. Cependant, une recommandation peut tre personnalise aprs sa gnration en triant ou en ltrant la liste de ses lments. Si la motivation mise en avant dans ces travaux nest pas la personnalisation, il nous semble intressant dvoquer ces travaux qui permettent tout de mme de placer les utilisateurs (autrement dit les analystes) au cur du systme.
2.4.1
Personnalisation du schma OLAP
Aprs la conception du schma de la BDM 10 , les besoins de lusager peuvent voluer dans le temps ([Favre et al.07], [Hurtado et al.99], [Garrigs et al.09]). Les travaux sur la personnalisation du schma multidimensionnel rpondent la problmatique suivante : Comment adapter le
10. Base de Donnes Multidimensionnelle
35
Projet Fin dEtude
schma dune base de donnes multidimensionnelles aux besoins volutifs de chaque usager ? Lapproche de personnalisation du schma propose par [Garrigs et al.09], permet de gnrer une vue personnalise du schma en fonction du prol de lusager courant. Il sagit de cacher des lments de la constellation lusager. La personnalisation du schma est rpartie en deux tapes. Les prols utilisateurs sont dnis durant la phase de conception. Ils sont ensuite combins des rgles ECA an de gnrer des vues personnalises du schma au moment de sa consultation ou de son interrogation. Cette approche ninduit pas de modication du schma physique de la base. Son inconvnient majeur est limpossibilit dajout dun lment de la constellation pour rpondre un nouveau besoin de lusager.
2.4.2
Personnalisation de requtes
Ainsi, dans [BGM05], la personnalisation de requte est considre comme un ajout de contraintes, issues du prol de lutilisateur, une requte donne et se traduit par lajout de conditions de slection. La dmarche de personnalisation, partir dune requte Q sur une instance de la base de donnes, renvoie une requte Q* telle que Q* Q au sens de linclusion de requtes MDX telle que dnie dans [BGMM06]. La personnalisation de requte est base sur le constat que des usagers peuvent juger des rsultats diffrents pertinents lors du requtage des donnes [Pitkow et al.02]. Lobjectif de lapproche de [Jerbi12] est de restituer les donnes les plus pertinentes pour chaque usager et dnit la personnalisation de requte par La personnalisation de requte est un mcanisme effectu avant ou aprs lvaluation de la requte an de changer la requte ou lordre du rsultat. Exemple 3.2.1. Supposons que la requte Q personnaliser concerne les locations de vhicules Tours en 2007, et supposons que les prfrences de lutilisateur se portent uniquement sur les vhicules bleus ou rouges, une requte personnalise Q* de la requte Q sera, par exemple, les locations de vhicules bleus ou rouges Tours en 2007.
2.4.3
Personnalisation de linterrogation des BDM
Les travaux de [Golfarelli et al.11] traitent la problmatique des rsultats volumineux ou vides des requtes OLAP. En ce qui concerne lapproche, il sagit dune approche de personnalisation de requte. La requte est excute sans personnalisation, puis les prfrences sont exploites pour dterminer les tuples du rsultat qui sont meilleurs que tous les autres. Plus prcisment, lexcution de la requte suit une dmarche non proactive qui value dune manire incrmentale des requtes enrichies par des combinaisons de prfrences jusqu trouver une requte qui renvoie un rsultat non vide. Les travaux de personnalisation de linterrogation des donnes [Garrigs et al.09], se situent au niveau restitution et analyse du systme OLAP. Ils rpondent la problmatique suivante : Parmi
36
Projet Fin dEtude
les lments du schma multidimensionnel et le volume important des donnes stockes, comment dterminer une requte qui rpond au mieux aux besoins de lusager et comment renvoyer ensuite un rsultat pertinent ? Ainsi, ces travaux permettent de personnaliser linterrogation du schma et/ou des instances de la base de donnes multidimensionnelles. Deux catgories de travaux peuvent tre distingues : Des travaux permettant la personnalisation des requtes de lusager. Des travaux visant assister lusager dans la dnition des requtes, appels communment des travaux de recommandation.
2.4.4
Recommandation de requtes
Contrairement au domaine du web o les objets recommands sont de diffrents niveaux de granularit (un article, plusieurs articles, une page web, . . . ), les travaux en OLAP se focalisent sur la recommandation de requtes [Marc et Negre.11] an de prendre en compte laspect navigationnel de linterrogation des donnes OLAP. Ils rpondent la problmatique suivante : comment guider lusager dans lexploration de la BDM an de laider dans son processus de prise de dcision ? . Lapproche de [Giacometti et al.09] est base sur la recherche dune certaine similarit entre les requtes de lutilisateur actuel (en cours dinteraction avec lentrept de donnes) et les requtes employes par dautres utilisateurs qui ont interrog le cube avant lui an de lui recommander la requte excute prochainement. La similarit en question est capture en comparant les squences des requtes dans les sessions (la navigation dun utilisateur a travers un entrept de donnes) prcdentes avec celles de la session actuelle. Une requte recommande est une requte existante, par exemple issue dun ensemble de requtes dj poses sur la base de donnes ou une requte calcule, par exemple partir des requtes dj poses sur la base de donnes. La requte recommande peut, par consquent, tre compltement diffrente de la requte initiale car elles ne vont pas forcment avoir le mme schma. Contrairement la personnalisation, la dmarche de recommandation, partir dune requte initiale Q sur une instance de la base de donnes, renvoie une requte Q telle que Q c Q*. Donc, les requtes recommandes pourront tre personnalises et rciproquement [Negre09]. Exemple 3.4.1 Supposons que la requte Q de lutilisateur concerne les ventes de vhicules Tours en 2007, une requte recommande pour la requte Q pourrait tre, par exemple, la requte Q* concernant les ventes de vhicules en rgion Centre en 2008. Notons que la slection sur lanne Q* (la recommandation). ayant change, Q (la requte initiale) c Daprs [Jerbi12], la dnition de la recommandation est comme suit :
37
CHAPITRE 2. LETAT DE LART Dnition 3.4.1 (Recommandation de requtes).
Projet Fin dEtude
La recommandation de requte est laction de proposer lusager une requte ou des parties de requte dune manire adapte ses intrts et/ou son analyse en cours an de lassister dans lexploration des donnes. [Jerbi12] dnit une dmarche de personnalisation globale qui couvre toutes les tapes de lanalyse OLAP. Plus particulirement, notre dmarche permettra dassister lusager formuler une requte OLAP, de personnaliser des requtes dnies par lusager et de renvoyer, en plus du rsultat de requtes, des recommandations. Divers scnarios de recommandation sont proposs, la recommandation par anticipation permet de guider lusager vers ltape suivante danalyse, ainsi la recommandation dalternative permet de guider lusager vers des nouvelles tapes juges dans son analyse.
2.5
Positionnement et proposition
A la lumire de cette tude bibliographique, nous distinguons quatre approches prometteuses lies aux entrepts de donnes actifs. La premire, adopte principalement par Thalhammer et al. ont dj avanc la notion de rgles danalyse et de graphes danalyse en exploitant le formalisme des rgles danalyse an de faire des rafraichissements au niveau des systmes sources OLTP. Cependant, cette proposition savre trs spcique un domaine dapplication particulier. La seconde approche, propose par Tho et al. consiste en une minimisation du temps dattente entre lintgration continue des donnes et la consultation de ces donnes dans lentrept. La solution propose, par ces auteurs, est daccompagner les tuples de mise jour par des messages qui donnent des indicateurs temporels. Ensuite, lapproche qui a t adopte par Bruckner et al., son principe est de permettre des mises jour en ligne de lentrept de donnes an de modliser lintervention des nouveaux faits en temps rel. Cette approche permet de respecter le problme duniformit du temps tout en insistant sur la validit dans le temps de la composante "Evnement" dune rgle danalyse. Enn, la dernire approche reprsente lapproche la plus rcente. Elle a t propose par Ezekiel et al. qui met laccent sur laspect smantique laide de dclencheurs avec des capacits dynamiques qui sont destines la prparation des donnes dans un environnement dynamique. Donc, lide est dincorporer le dclencheur avec des capacits dynamiques en utilisant le concept DOM. Il est claire daprs notre tude bibliographique, que les diffrentes approches dcrites ci-dessus ([Garrigs et al.09],[Golfarelli et al.11]) abordent les problmes de personnalisation et de recommandation de diffrentes faons, telle que labsence dune approche mixte qui intgre les deux fonctionnalits de personnalisation de requte et de recommandation pour les analyses
38
Projet Fin dEtude
OLAP. Les travaux de [Giacometti et al.09] permettent de personnaliser une requte recommande sans personnaliser la requte initiale de lusager. Nous avons galement not labsence de travaux sur lassistance la formulation des requtes OLAP. Ainsi, [Jerbi12] propose un mcanisme global combinant les fonctionnalits de personnalisation et de recommandation. La synthse de ces approches est donne par la table comparative ci-dessous. Le symbole - signie quaucun lment na t dni par rapport au critre nonc.
39
CHAPITRE 2. LETAT DE LART Approche Objectif Rgle
Projet Fin dEtude Rapports Points positifs danalyse Rgles Semi -Formalisation danalyse automatique des rgles danalyse Points ngatifs -Spcique un domaine dapplication particulier. - Manque des rgles danalyse et dautomatisation - Stockage des donnes dans lentrept de donnes dans luniformit de temps - Manque des rgles danalyse
Thalhammer-Analyse et al. multidimensionnelle (2001) utilisant le concept des graphes danalyse Bruckner -Modliser les etal. problmes daccorder (2001) lhorodateur correct aux tuples de donnes, Tho et al. -Minimiser le retard qui (2004) se produit lors du chargement des donnes continues dans lentrept de donnes Ezek et Mari. (2006) -Incorporer le dclencheur avec des capacits dynamiques en utilisant le concept DOM -Assistance la dnition de requte
Manuelle
- Accomplir luniformit du temps
Rgles ECA
Rgles ECA
Automatique -Automatisation des tches daide la dcision courantes, non-courantes et semi-courantes Semi -Prparation et automatique nettoyage de donnes
Garrigs et al. (2009)
Rgles ECA
Giacometti -Recommandation de et al. requtes (2009)
-Rduction de lespace multidimensionnel explorer -Aspect collaboratif
-Pas de personnalisation des valeurs -Gnration non personnalise des recommandations -Pas de recommandation de nouvelles requtes -Effort manuel et congnitif - Excution de plusieurs requtes intermdiaires pour chaque requte utilisateur -Personnalisation exploite seulement le prol de lusager courant
Golfarelli et al. (2011)
-Personnalisation de requte
Modle (BMO : Best Matches Only)
- Expressivit du modle de prfrences
Jerbi (2012)
-Intgration les deux fonctionnalits de personnalisation de requte et de recommandation pour les analyses OLAP.
-Modlisation globale des analyses OLAP
TABLE 2.2 Synthse des travaux sur les entrepts de donnes actifs
40
Projet Fin dEtude
En effet, les travaux dj proposs restent thoriques et assez spcique. Les rgles actives ECA, gnralisent la notion de dclencheur, elles utilisent gnralement le formalisme Evnement-Condition-Action. Notre approche, dans ce mmoire, consiste proposer une solution pour lautomatisation des scnarios danalyse. Les scnarios programms permettent de modier les donnes au niveau des bases sources pour dployer une stratgie commerciale. Nous estimons que la formalisation originelle des rgles danalyse nest pas simple et ne se prte pas une utilisation intuitive par un utilisateur OLAP. Lintgration dun volet actif dans un entrept par le biais des rgles danalyse a pour but de gnrer automatiquement des rapports danalyse. Ceci revient automatiser des rgles danalyse dnies pralablement par un utilisateur dune faon dclarative. Il ne sagit pas de gnrer automatiquement des rgles danalyse, mais dautomatiser leur excution de faon conditionnelle. La dnition des rgles danalyse se fait donc de faon dclarative par le biais dune API permettant lutilisateur de dnir la squence doprations OLAP ncessaires lexcution dun scnario danalyse. Celui-ci exprim laide dune rgle danalyse sera intgr dans lentrept. Lexcution automatique du scnario se fait laide du mcanisme inspir de celui dECA. Notre objectif est de proposer une architecture dentrept de donnes actif (EDA) efcace de dtection dvnements complexes au sein dun entrept permettant doffrir une smantique non ambige des expressions dvnements formes par divers oprateurs OLAP dans diffrents contextes danalyse. Un EDA se base sur la transformation du mcanisme ECA en un mcanisme dECG (Evnements-Conditions-Graphes danalyses).
41
CHAPITRE 3. FORMALISATION DES RGLES DANALYSE
Projet Fin dEtude
Chapitre 3 Formalisation des rgles danalyse
Introduction
approche propose par Thalhammer et al. est une application portant sur la modication des donnes sources OLTP suite une dcision issue dune analyse conduite automatiquement [TSM01]. Dans ce chapitre, en sinspirant du formalisme des rgles ECA connues dans les bases de donnes actives et encore appeles "rgles danalyse" par Thalhammer et al. dans le contexte des entrepts de donnes. Nous allons proposer une nouvelle une architecture efcace de dtection dvnements complexes dans un EDA permettant doffrir une smantique non ambige des expressions dvnements formes par divers oprateurs dans diffrents contextes. Cette formalisation est ddie lautomatisation des scnarios danalyse dune manire simplie et intuitive. Il est aussi ncessaire de dnir un mcanisme adquat pour la modlisation et la dtection des vnements composites permettant la reprsentation des expressions dvnements. Notre approche fournit un cadre thorique complet capable de couvrir tous les besoins danalyse dans un entrept de donnes. Dans la suite, nous prsentons dans un premier temps les notations, les outils et la terminologie que nous allons adopter pour la formalisation de nos rgles danalyse. Nous introduisons, particulirement, un modle pour les cubes de donnes et une algbre comprenant un ensemble complet doprateurs OLAP. Dans un second temps, nous entamons la formalisation des rgles danalyse. Nous dnissons alors les notions de rgle danalyse, graphe danalyse et sous-graphe danalyse.
42
CHAPITRE 3. Formalisation des Rgles danalyse
Projet Fin dEtude
3.1
3.1.1
Notations et terminologies
Modle de cube de donnes
Soit U un ensemble ni et non vide des cubes de donnes {U1 ,U2 ,...., US }. Dans notre approche, nous nous servons du formalisme prsent dans [BM06] pour modliser un cube de donnes U. Dnition 1.1(Cube de donnes). Un cube de donnes, not U, est un quintuplet de la forme : <C, A, M, L, F>, o : C = <C,d> est un espace de caractristiques. C est un ensemble de noms de caractristiques et d est une fonction boolenne qui partitionne C en un sous-ensemble de caractristiques dimensionnelles et un sous-ensemble de caractristiques mtriques ; A = <A, f, OA > est un espace dattributs. A est un ensemble de noms dattributs. f est une bijection qui fait correspondre chaque caractristique c C un sous-ensemble dattributs dans A. OA est un ensemble dordres partiels, o chaque ordre exprime un ordre hirarchique entre les attributs de A,
F IGURE 3.1 Exemple dun cube de donnes de location de vhicules M = <M , g, OM , h> est un espace de modalits. M est un ensemble de noms de modalits. g est une fonction qui associe chaque attribut a A un sous-ensemble non vide de modalits dans M. g permet didentier pour chaque attributs de A son domaine de dnition. OM est un ensemble dordres totaux, o chaque ordre intervient dans un sous-ensemble dattributs g(a). Cet ordre correspond un ordonnancement lexical des modalits dun niveau de granularit dune caractristique. h est une fonction dappartenance qui associe une modalit un ensemble de modalits qui lui appartiennent selon un ordre smantique, L est un ensemble ni et non vide de cellules , F est un ensemble ni et non vide de fonctions dagrgation comme la somme (SUM) et la
43
CHAPITRE 3. Formalisation des Rgles danalyse moyenne (AVG).
Projet Fin dEtude
3.1.2
Oprateurs complmentaires
Ajout dune modalit : Ajout dune modalit Loprateur (AddModality) consiste rajouter une nouvelle modalit bnew dans un attribut a f(c), o c est une caractristique dun cube U0 . U1 = AddModality (U0 , {bnew }, a) = {C0 , A0 , M1 , L1 , F0 } avec : M1 = <M1 , g, OM1 , h> , o M1 = M0 U bnew L1 est lensemble des cellules engendres par lensemble des modalits M1 . Il est noter que dans lalgbre de [BM06], lauteur se limite des oprateurs unaires qui nacceptent quun seul cube de donnes en entre. Cette algbre est incomplte au regard des besoins de formalisation des graphes danalyse du fait quelle ne comprend pas les oprateurs ensemblistes, notamment, lunion, lintersection et la diffrence. Dautre part, nous avons veill dans cette algbre respecter la notion de noyau minimal qui prsente un ensemble contenant le minimum doprateurs OLAP (oprateurs lmentaires) que nous pouvons combiner inniment an de produire nimporte quelle opration complexe dans un contexte danalyse donn. En vue de fournir une formalisation plus complte dun graphe danalyse, nous proposons denrichir cette algbre par des oprateurs ensemblistes n-aires comprenant lunion (Union), lintersection (Intersect) et la diffrence (Diff). Dans la suite, nous considrons deux cubes de donnes ayant la mme structure : UI = < CI , AI , MI , LI , FI > UII = < CII , AII , MII , LII ,FII > avec : CI = CII d au fait que UI et UII ont la mme structure , AI = AII d au fait que UI et UII ont la mme structure , MI MII . Les espaces de modalits MI et MII de UI et UII sont diffrents d au fait que les ensembles de modalits MI et MII sont diffrents. En revanche, les deux ensembles de modalits obissent au mme ordre total, cest--dire OMI = OMII . Par exemple, il sagit dun ordre alphabtique ou dun ordre chronologique pour les caractristiques temporelles , LI LII d au fait que les cellules dans UI sont diffrentes des cellules de UII vue que MI MII , FI FII d au fait que les fonctions dagrgation dans UI sont diffrentes de celles de UII . Lunion Cet oprateur (Union) permet de faire lunion des modalits de deux ou de plusieurs cubes ayant la mme structure. Il sagit dun oprateur compos qui peut tre obtenu par succession de plusieurs ajouts de modalits dans les attributs communs des cubes concerns. Formellement : Un = Union ( UI , UII ) = < Cn , An , Mn , Ln , Fn > avec : Cn = CII = CI et An = AII = AI ; le cube rsultant de lunion conserve la mme structure que
44
Projet Fin dEtude
les deux cubes de dpart ; Mn = < Mn , g, OMn , h >, o Mn = MI MII . Les modalits du cube Un, rsultent de lunion des deux ensembles de modalits des deux cubes de dpart. OMn est un ordre total sur lensemble des modalits Mn . Par exemple, dans la Figure 4.2(a), lordre suivi est un ordre alphabtique ; Ln est un ensemble de cellules engendres par Mn , Fn = FI FII . Dans la Figure 3.2(a), les deux cubes UI et UII ont respectivement les fonctions SUM et AVG. Le cube rsultant, aprs lunion, aura lensemble des fonctions dagrgation des cubes de dpart comme est montr dans la Figure 3.2(a).
F IGURE 3.2 Exemple dun oprateur dunion entre deux cubes de donnes En respectant les contraintes de la compltude de lalgbre et celle des oprateurs lmentaires, lunion peut tre vue comme une opration compose de plusieurs ajouts de modalits AddModality. Soit : M = MII \ MI lensemble de modalits prsentes dans UII et qui sont absentes dans UI . Dans la gure 10 M = {d, g}. On note n le nombre de modalits dans M (cest--dire card (M0 ) = n ) avec M0 = {b1 , b2 ,........, bn }. Dans notre exemple de la Figure 3.2, n est gal 2 et reprsente le nombre ditrations faire pour aboutir au cube rsultat.
45
CHAPITRE 3. Formalisation des Rgles danalyse U1 = AddModality ( UI , b1 , g-1 (b1 ) ) U2 = AddModality (U1 , b2 , g-1 (b2 ) ) . . . .
Projet Fin dEtude
Un = AddModality (Un-1 , bn , g-1 (bn ) )
Un = Union (UI , UII ) avec : g-1 reprsente la fonction inverse qui permet de renvoyer lattribut auquel sera rajoute la nouvelle modalit. Lintersection Cet oprateur (Intersect) permet de faire une intersection entre deux cubes de mme structure. Il sagit dun oprateur compos qui peut tre obtenu par lapplication de plusieurs slections de modalits. Un = Intersect (UI , UII ) = < Cn , An , Mn , Ln , Fn > avec : Cn = CII = CI et An = AII = AI ; le cube rsultant de lintersection conserve la mme structure que les deux cubes de dpart , Mn = < Mn , g, OMn , h >, o Mn = MI \ MII . Les modalits du cube rsultant de lintersection sont les modalits communes entre les deux cubes de dpart. OMn reprsente un ordre total sur lensemble des modalits Mn . Par exemple, dans la Figure 3.3(a) lordre suivi est aussi un ordre alphabtique , Ln est un ensemble de cellules engendres par Mn , Fn = FI FII . Dans la Figure 3.3(a), les deux cubes UI et UII possdent les fonctions SUM et AVG. Le cube rsultant, aprs lintersection, aura lensemble des fonctions dagrgation communes aux deux cubes de dpart comme est montr dans la Figure 3.3(a). Lintersection peut tre vu comme une opration compose de plusieurs slections (Slice). Soit : M= MI MII lensemble de modalits communes entre UI et UII . On note n le nombre de caractristiques de UII et UI ayant au moins une modalit commune.
46
Projet Fin dEtude
F IGURE 3.3 Exemple dun oprateur dintersection entre deux cubes de donnes U1 = SLICE ( UI , C1 , P1 ) U2 = SLICE ( U1 ,C2 , P2 ) . . . .
Un = SLICE (Un-1 , Cn , Pn )
Un = Intersect (UI , UII ) avec : Ci {1,......., n} est lensemble des caractristiques ayant des modalits dans M , Pi {1,......., n} est une condition logique sur les modalits communes de Ci .
47
Projet Fin dEtude
La diffrence Cet oprateur (Diff) permet de faire la diffrence entre deux cubes de mme structure. Il sagit dun oprateur compos qui peut tre obtenu par succession de plusieurs slections de modalits dans les attributs communs des cubes de donnes.
F IGURE 3.4 Exemple dun oprateur de diffrence entre deux cubes de donnes Un = Diff (UI ,UII ) = < Cn , An , Mn , Ln , Fn > avec : Cn = CII = CI et An = AII = AI ; le cube rsultant de lunion conserve la mme structure que les deux cubes de dpart , Mn = < Mn , g ,OMn , h >, o Mn = MI \ MII . Les modalits du cube rsultant de la diffrence sont les modalits appartenant au premier cube et nappartenant pas au deuxime comme le montre la Figure 3.4(a). OMn reprsente un ordre total sur lensemble des modalits Mn . Par exemple, dans la Figure 3.4(a) lordre suivi est aussi un ordre alphabtique , Ln est un ensemble de cellules engendres par Mn , Fn = FI FII . Dans la Figure 3.4(a), les deux cubes UI et UII ont respectivement les fonctions SUM et AVG. Le cube rsultant, comme le montre la Figure 3.4(a), aura lensemble des
48
Projet Fin dEtude
fonctions dagrgation du premier cube aprs avoir dduit les fonctions dagrgation quil a en commun avec le deuxime cube. La diffrence peut tre vu comme une opration compose de plusieurs slections Slice. Soit : M0 = MI \ MII lensemble de modalits de UI diffrentes de celles de UII . Dans la Figure 3.4(a), M0 = c ; f. On note n le nombre de caractristiques de UII et UI ayant au moins une modalit dans M0 . Dans la Figure 3.4(b), n reprsente aussi le nombre ditrations aboutissant au cube rsultat et est gale 2. U1 = SLICE ( UI , C1 , P1 ) U2 = SLICE ( U1 ,C2 , P2 ) . . . .
Un = SLICE (Un-1 , Cn , Pn )
Un = Diff (UI , UII ) avec : Ci {1,....., n} est lensemble des caractristiques ayant des modalits dans M0 . La Figure 3.4(b) reprsente deux caractristiques ayant des modalits dans M0 savoir C1 et C2 , Pi {1,......, n} est une condition logique sur les modalits communes de Ci . Dans la Figure 3.3(b), la premire itration prsente une condition P1 = {c} lie la caractristique C1 . La deuxime itration reprsente, quant elle, une deuxime condition P2 = {f} lie la caractristique C2 .
3.2
Rgle danalyse
Dnition 2.1 (Rgle danalyse). Une rgle danalyse, note R, est un triplet de la forme < , N , G > o : est une conjonction dvnements ; N est un ensemble de conditions ; G est un graphe danalyse.
49
Projet Fin dEtude
3.2.1
Conjonction dvnements
Dnition 2.1.1(Conjonction dvnements). La conjonction dvnements E dnit le dclenchement dune rgle danalyse. Elle scrit sous la forme dune conjonction de disjonctions dun ensemble ni dvnements {E1 , E2 ,......., En }. Un vnement Ei peut tre un point xe du calendrier ou bien un changement dtat dans une base de donnes OLTP. Prenons notre exemple de location de vhicules, nous considrons lensemble des vnements { E1 , E2 } o : E1 reprsente le dbut de chaque mois , E2 est lvnement correspondant un montant de location infrieur 400 dinars. Ainsi, partir de cet ensemble dvnements, nous pouvons obtenir : = E1 : est une conjonction, comportant un seul vnement, qui dclenche mensuellement des analyses ordinaires dcrivant les tats des vhicules de lentreprise , = E1 E2 : cette conjonction est responsable du dclenchement dune analyse due au fait que le montant de location de vhicule est infrieur 400 dinars au dbut de chaque mois. Cette analyse pourrait expliquer par exemple les raisons de la dcroissance du montant de location de vhicule.
3.2.2
Ensembles de conditions
Dnition 2.2.1(Ensemble de conditions). Un ensemble de conditions N reprsente un nombre dni de conditions {N1 ,N2 ,....,Nn } qui vont intervenir dans le scnario danalyse. Ces conditions rpondent aux besoins danalyse et reprsentent les tapes dexcution de la requte avant quune dcision ne soit prise. Par exemple, en se basant sur le cube de location des vhicules de la Figure 3.1, soit lensemble des conditions {N1 , N 2 , N 3 } o : N1 est une slection sur la famille de vhicules Peugeot , N2 est une slection sur lagence Sousse , N3 est une restriction sur la dure de location de vhicule suprieure 50 heures. Ces conditions permettent de dnir une suite doprations OLAP dans un scnario danalyse quon peut formaliser par un graphe danalyse.
3.2.3
Graphe danalyse
Dnition 2.2.2( Graphe danalyse). Un graphe danalyse, not G, est une reprsentation graphique dun processus danalyse. Elle est de la forme (U, P), o :
50
Projet Fin dEtude
U est un ensemble de cubes de donnes , P est un ensemble de chemins danalyse reprsentant des oprations OLAP. Chemin danalyse P est un ensemble ni de r chemins danalyse {P1 , P2 ,......., Pr }. Nous dnissons un chemin danalyse comme suit : Dnition (Chemin danalyse) Un chemin danalyse, not P, est une fonction de Un dans U qui fait associer un ou plusieurs cubes de donnes un autre cube P(U) qui rsulte dune opration OLAP. Formellement, nous crivons : P : Un > U (U1 ,U2 ,.......,Un ) >P(U) Graphiquement, comme le montre la Figure 4.5, nous reprsentons un chemin danalyse par un lien orient dun ensemble de cubes de dpart vers un cube rsultat P(U).
F IGURE 3.5 Reprsentation graphique dun chemin danalyse Un chemin danalyse reprsente une opration OLAP. Nous adoptons lensemble complet des oprateurs OLAP, que nous avons dj dnis dans le chapitre prcdant, pour les utiliser dans le cadre des graphes danalyse. Dans notre formalisme, un graphe danalyse est un moyen qui permet de reprsenter graphiquement un processus danalyse an de produire, par exemple, des rapports danalyse (reportings) automatiques. Ces scnario automatiques donnent lentrept de donnes un caractre actif. Dun point de vue graphique, un graphe danalyse G est schmatis par un ensemble de noeuds U (cubes de donnes) et un ensemble darcs P (chemins danalyse).
3.2.4
Sous-graphe danalyse
An de rpondre des besoins de la modlisation logique dun graphe danalyse, que nous allons aborder dans le chapitre suivant, nous introduisons la notion dun sous-graphe danalyse. Dnition 2.2.3 ( Sous-graphe danalyse).
51
Projet Fin dEtude
Un sous-graphe danalyse, not SG ayant la forme <U, P>, est une sous-partie dun graphe danalyse G = <U, P>, o U C U et P C P. En plus, SG vrie les proprits suivantes : SG commence par un cube dentre dans G, ou deux cubes intervenant dans une opration binaire , SG dnit par un cube de sortie dans G, ou un cube intervenant dans une opration binaire.
F IGURE 3.6 Graphe danalyse associ au cube des locations de vhicules Par exemple, conformment cette dnition, le graphe danalyse de la Figure 3.6 comporte trois sous-graphes danalyse : 1. Le premier sous-graphe SG1 commence par le premier cube dentre U1 du graphe danalyse qui reprsente les donnes du systme informationnel relatif la region "Sud" par mois. Ce sous-graphe suit un enchainement doprations OLAP jusqu U3 qui reprsente les locations des vhicules de type "Sport" et qui intervient dans une opration binaire (Union). 2. Le deuxime sous-graphe SG2 commence par le second cube dentre U2 du graphe danalyse reprsentant les donnes du systme informationnel de "Est" par mois. Ce sous-graphe suit un enchanement doprations OLAP jusqu U4 dsignant les locations des vhicules de type "Commercial" et qui intervient dans une opration binaire (Union). 3. Le troisime sous-graphe SG3 commence, quant lui, par les deux cubes naux (U1 et U2) des deux prcdents sous-graphes. Le cube de donnes de sortie U5 du graphe danalyse
52
CHAPITRE 3. Formalisation des Rgles danalyse reprsente la n de ce sous-graphe.
Projet Fin dEtude
Nous tenons souligner, que la dnition du sous-graphe que nous adoptons est plus spcique que celle connue dans la thorie des graphes. Il sagit dun dcoupage du graphe danalyse adapt des ns.
Conclusion
Un entrept de donnes actif EDA est considr comme un systme permettant dintgrer dans une mme base cible des donnes et des traitements. Dun point de vue technique, les EDAs sinspirent des techniques utilises dans les bases de donnes actives savoir : les rgles ECA. Grce ce mcanisme, il est possible alors de penser stocker des donnes et des traitements dans un entrept. Ce mcanisme dECA permet de construire des rgles danalyse, exprimes sous la forme de scripts, qui dnissent des tches danalyse par exemple ou dautomatiser toute autre tche du processus dentreposage. Une des fonctionnalits de base dun EDA est de dtecter des vnements. Cest seulement aprs quun vnement dintrt soit produit et soit dtect que les rgles soient dclenches el les actions appropries sont excutes. Ainsi, plus un EDA dtecte plusieurs types dvnements, plus quil est capable de rpondre une plus grande varit de situations relles et y ragit en consquence. En effet, le besoin de disposer dun entrept de donnes actif plus puissant, expressif et tellement capable de dtecter une taxonomie dvnements, exige une capacit de supporter plus dvnements complexes.
53
CHAPITRE 4. EXPRIMENTATIONS
Projet Fin dEtude
Chapitre 4 Exprimentations
Introduction
ans les chapitres prcdents, nous avons prsent une formalisation conceptuelle des rgles danalyse et une modlisation pour celles-ci an de prsenter les niveaux logique et physique. Dans ce chapitre, nous prsentons dans un premier lieu larchitecture et les technologies utilises dans notre application. Nous allons proposer en deuxime lieu une tude de cas ralise sur des donnes du cube des locations des vhicules.
D
4.1
Architecture dapplication
Architecture dapplication
4.1.1
Larchitecture de notre application peut tre reprsent par le schma suivant : Les lments caractristiques de larchitecture prsente ci-dessus sont les suivants : Entrept de donnes avec stockage des donnes au format OLAP. Les schmas en toile et en ocons sont grs par Mondrian, ainsi que de nombreux autres concepts propres lOLAP, Serveur web J2EE Pentaho : ce serveur embarque le moteur ROLAP Mondrian qui permet deffectuer des requtes multidimensionnelles (langage MDX) sur des donnes stockes dans un SGBD relationnel (interrogation SQL). Pour la partie conception, les cubes sont modliss avec Pentaho Schma Workbench , un client riche open source (en java) de modlisation et de publication de schmas Mondrian sur un serveur Pentaho, Pour la partie restitution, les vues mtiers sont accessibles en client lger via un navigateur web (Internet, Explorer, Firefox,Opera, . . . ). La mise en place dun serveur Pentaho Entreprise permettra deffectuer des analyses avances avec le composant Pentaho Analyser,
54
CHAPITRE 4. Exprimentations
Projet Fin dEtude
F IGURE 4.1 Architecture de systme si on veut rester en open source on utilisera JPivot, qui reste encore malgr son grand ge un outil de requtage puissant et stable, en attendant un digne successeur, probablement Pentaho Analysis Tool. . .
4.1.2
Technologies employes
Daprs la Figure 5.1, on peut distinguer plusieurs technologies participes dans la ralisation de ce systme tel que : Tomcat : Issu du projet Jakarta, Tomcat est dsormais un projet principal de la fondation Apache. Tomcat implmente les spcications des servlets et des JSP de Sun Microsystems. Il inclut des outils pour la conguration et la gestion, mais peut galement tre congur en ditant des chiers de conguration XML. Comme Tomcat inclut un serveur HTTP interne, il est aussi considr comme un serveur HTTP. Tomcat a t crit en langage Java, il peut donc sexcuter via la JVM (machine virtuelle java) sur nimporte quel systme dexploitation la supportant. MysqlServer : Est un systme de gestion de base de donnes (SGBD). Selon le type dapplication, sa licence est libre ou propritaire. Il fait partie des logiciels de gestion de base de donnes les plus utiliss au monde, autant par le grand public (applications web principalement) que par des professionnels, en concurrence avec Oracle ou Microsoft SQL Server. Java : Apparu en 1991, le langage JAVA a commenc tre intressant partir de 1995 avec sa prise en charge par le navigateur phare de lpoque, Netscape. Ce langage ne cesse de se dvelopper. Il sagit dun langage orient objet dont la syntaxe est trs proche de celle du C++. Cest galement un langage portable, cest dire quil sadapte une foule de
55
Projet Fin dEtude
plate-formes diffrentes. Cest l lune des qualits de JAVA. Eclipse : Appel aussi Eclipse Project ou encore Eclipse Platform. La caractristique essentielle dEclipse est lextensibilit de lenvironnement. Plus que de se focaliser sur un environnement de dveloppement Java, les concepteurs dEclipse se sont efforcs avant tout de crer un socle applicatif sur lequel viennent se greffer des modules et/ou plugins. Eclipse est un projet, dclin et organis en un ensemble de sous-projets de dveloppements logiciels, de la fondation Eclipse visant dvelopper un environnement de production de logiciels libres qui soit extensible, universel et polyvalent. Mondrian : Est un moteur OLAP (Online Analytical Processing) crit en Java par Julian Hyde qui permet la conception, la publication et le requtage de cubes multidimensionnels. Mondrian permet lexcution de requtes en langage MDX sur des entrepts de donnes sappuyant sur des SGBDR, do sa caractrisation de ROLAP (Relational OLAP). Mondrian permet daccder aux rsultats dans un format multidimensionnel comprhensible par une API de prsentation ct client, le plus souvent en mode Web, avec par exemple JPivot (est un client OLAP disposant dune interface Web permettant de reprsenter un cube OLAP sous forme de tableau crois multidimensionnel) et Pentaho Business Analytics. Mondrian sappuie sur une modlisation OLAP standard et peut donc se connecter nimporte quel entrept de donnes conu dans les rgles de lart de la Business Intelligence (BI). Il est intressant de noter que Mondrian est le composant OLAP utilis par la plupart des suites de BI Open Source notamment Pentaho et JasperServer Pentaho : Etant lditeur qui hberge et soutient la communaut Mondrian (mondrian.pentaho.org). Pentaho fournit de nouvelles fonctionnalits orientes utilisateur pour une visualisation et exploration des donnes interactives qui donnent accs toutes les sources de donnes. La valeur ajoute unique de Pentaho repose sur une plate-forme qui lie troitement lintgration de donnes. Elle est conue pour permettre aux services informatiques et utilisateurs mtiers de collaborer et faire une mise au point plus rapidement et facilement pour obtenir de meilleures analyses et prendre de meilleures dcisions. Pentaho est une plate-forme dcisionnelle open source complte possdant les caractristiques suivantes : 1. Une couverture globale des fonctionnalits de la Business Intelligence : ETL (intgration de donnes), reporting, tableaux de bord ("Dashboards"), analyse ad hoc (requtes la demande), analyse multidimensionnelle (OLAP) ; 2. Le serveur Web Pentaho comporte galement une plate-forme dadministration (Pentaho Administration Console) pour la gestion des droits daccs, la planication dvnements, la gestion centralise des sources de donnes... ; 3. Pentaho est une suite dcisionnelle open source commerciale qui reste trs ouverte.
56
Projet Fin dEtude
Pentaho Schma Workbench : Pentaho Schma Workbench est un client riche open source (crit en Java) qui permet de crer des schmas de cubes sans avoir connaitre la syntaxe XML de Mondrian. Le moteur Mondrian traite les requtes MDX avec les (Relational OLAP) schmas ROLAP. Ces chiers schma sont des modles de mtadonnes XML qui sont crs dans une structure spcique utilis par le moteur Mondrian. Ces modles XML peuvent tre considrs comme des structures cubiques qui utilisent les tables de fait et de dimension trouvs dans votre SGBDR. Il nexige pas quun cube physique relle est construit ou maintenu, mais seulement que le modle de mtadonnes est cr. Cet outil prsente une interface avance qui permet deffectuer les actions suivantes : 1. Connexion lentrept de donnes (via JDBC) , 2. Cration de schmas et cubes Mondrian Cration des mesures, dimensions et hirarchies dun cube , 3. Jointures pour les tables oconnes , 4. Tables dagrgation utiliser (le cas chant), 5. Cration de membres calculs, de dimensions partages, de cubes virtuels, 6. Dnition des rles (gestion de la scurit daccs lintrieur dun cube), 7. Publication des cubes sur le serveur Pentaho.
4.2
Etude de cas
Nous allons proposer dans cette section une tude de cas ralise sur des donnes du cube des locations des vhicules. Exemple 5.2.1 : Considrons lexemple du cube Locations dont le schma conceptuel en toile est donn Figure 4.2. La table de faits FACT dtaille les valeurs des mesures des locations ralises de vhicules diffrentes dates dans diffrents agences. Les dimensions sont Temps, Agence, Vhicule. Dans ce cas, un utilisateur accde aux donnes du cube laide dune requte OLAP dont la rponse est compose dun ensemble de tuples de donnes dtailles ou agrges, prsentes sous forme de tableau crois. Pour cela, on peut utiliser un langage spcique tel que MDX.
57
Projet Fin dEtude
F IGURE 4.2 Exemple de modlisation en toile du cube Locations
Lentrept de donnes :
Les donnes de cet entrept (base de donnes de location de vhicules) sont stocks sur le serveur de base de donnes utilisant MySqlServer, avec lensemble des tables de dimensions suivant : Vehicule : stocke les informations concernant les vhicules (Immat, Marque, Categorie, Type), Agence : stocke les informations concernant la gographie (Cod_Ag, Ville, Region, Pays), Temps : stocke la date correspond la location de vhicule (Date_Loc, Mois, Trimestre, Annee), et la table de fait : Fact : cette tabe contient deux mesures tel que : - Montant : cout de la location de la vhicule, - Durr : dure de location de vhicule.. Les donnes de lentrept sont interroges indirectement par le systme. Par le baie de Mondrian, un serveur OLAP destine a lexcution des requtes multidimensionnelles (MDX) sur les donnes dun entrept de donnes et le formatage des rsultats sous forme dune table croise. Le schma logique de notre exemple sur Pentaho Schma Workbench qui correspond au cube Locations est reprsent comme se dcrit dans la Figure 4.3. Ce schma montre le cube Locations qui correspond la table de fait (fact) qui est lie trois dimensions (Vehicule, Agence, Type). Ainsi, chaque dimension est caractrise par une hirarchie de niveaux par exemple pour la dimension Agence on a (Pays > Region > Ville).
58
Projet Fin dEtude
F IGURE 4.3 Schma du cube Locations
4.2.1
Exemple dune rgle danalyse
Prenons un exemple de scnario danalyse pour notre tude de cas. A partir du cube de locations des vhicules, nous allons essayer de rpondre au scnario qui permet de comparer les locations des types de vhicules" dans le mois "Janvier" dans deux villes diffrentes "Jerba" et "Bizert". Les vnements correspondant notre rgle danalyse sont deux vnement qui sont : 1- E = "Evenement1" contient : BOW(Begin Of Weekend) pour dsigner le dbut de la semaine, Lorsque le Montant dpasse les 600 dinars. 2- E = "Evenement2" contient : Quand la Dure de location de vhicule dpasse les 10 heures. Ces vnements sont reprsents par la balise <event> dans la Figure 4.5. Ainsi, cette conjonction de ces deux vnements est responsable du dclenchement dune analyse due au fait que le montant de location de vhicule dpasse les 600 dinars au dbut de chaque semaine et la dure de location est suprieure 10 heures. Cette analyse pourrait expliquer par exemple les raisons de la dcroissance du montant de location de vhicule. La conditions relative cette rgle danalyse est : Annee = "2011". Cette condition est reprsente par la balise <conditions>. Nous rsumons lexemple prcdent par le document XML reprsent dans la Figure 4.5.
59
Projet Fin dEtude
4.3
Modlisation XML de la rgle
Linterface ci-dessous de notre application permet le chargement dun chier XML qui contient la rgle danalyse. Cette dernire est constitue de trois balises principales : <events>, <conditions> et <AnalysisGraph> reprsentant respectivement les vnements, les conditions et le graphe danalyse. Un graphe danalyse peut tre dcompos son tour en un ou en plusieurs sous-graphes danalyse reprsents par la balise <SubGraph>. Par exemple, dans notre cas, le graphe danalyse comporte trois sous-graphes danalyse comme le montre la Figure 4.4 ci-dessous. A chaque sous-graphe nous associons une balise <inputcubes> pour dsigner les cubes dentre et une balise <AnalysisPaths> qui reprsente les chemins danalyse. Chaque chemin danalyse, qui reprsente une opration OLAP, est modlis par la balise <path> pour dsigner les diffrentes oprations dOLAP.
60
< ?xml version="1.0" encoding="UTF-8" ?> <AnalysisRule name="Comparaison des montant de location des vehicules"> <events> <event E="Evennement1"> <when>T=BOW</when> <where>Montant > 600</where> <agregation> MIN </agregation> </event> <event E="Evennement2"> <where>Duree > 10</where> </event></events> <conditions><where>Annee = 2011</where> </conditions> <AnalysisGraph> <SubGraph name="SubGraph I"> <input_cubes> <cube> name = "Cube de location des Vehicules par Ville et par Annee" </cube> </input_cubes> <AnalysisPaths> <path number="1"> <Slice caracteristic="Agence" predicate="Ville=Jerba" /></path> <path number="2"> <DrillDown caracteristic="Temps" attribute_old="Annee" attribute_new="Mois" /> </path> <path number="3"> <RollUp caracteristic="Temps" attribute_old="Marque" attribute_new="Type" /> </path> <path number="4"> <Slice caracteristic="Vehicule" predicate="Mois=Janvier" /></path> </AnalysisPaths> </SubGraph> <SubGraph name="SubGraph II"> <input_cubes> <cube> name = "Cube des Vehicules par Ville et par Trimestre" </cube> </input_cubes> <AnalysisPaths> <path number="5"> <Slice caracteristic="Agence" predicate="Ville=Bizert" /></path> <path number="6"> <DrillDown caracteristic="Temps" attribute_old="Trimestre" attribute_new="Mois" /> </path> <path number="7"> <RollUp caracteristic="Vehicule" attribute_old="Marque" attribute_new="Type" /> </path> <path number="8"> <Slice caracteristic="Vehicule" predicate="Mois=Janvier" /></path> </AnalysisPaths> </SubGraph> <SubGraph name="SubGraph III"> <input_cubes> <cube> name= "ResultOf :SubGraph I" </cube> <cube> name = name="ResultOf :SubGraph II" </cube> </input_cubes> <AnalysisPaths> <path number="5"> <Slice caracteristic="Vehicule" predicate="Type=Sport" /></path> </AnalysisPaths></SubGraph></AnalysisGraph></AnalysisRule>
Projet Fin dEtude
F IGURE 4.4 Modlisation XML de la rgle danalyse 61
Projet Fin dEtude
4.4
Validation de lexemple
Pour notre tude de cas, nous avons utilis Pentaho Business Analytics qui contient le moteur OLAP pour manipuler les diffrents oprateurs OLAP sur le cube de donnes des locations. Nous dtaillons, dans la suite, lenchanement des oprations OLAP selon les trois sous-graphes qui sont identis prcdemment dans le chier XML dans la Figure 4.4. Tout dabord, nous allons expliqu par dtail notre Prototype dEntrept de Donnes Actif babtis "PEDA" comme le montre la Figure 4.5 ci-dessous. La premire tache faire, est de xer la Date Systme (Le Dimanche 13 Juin) en correspondance ce qui est dnit dans le chier XML dans la balise <event><when> "BOW" (Begin Of Weekend).
F IGURE 4.5 Prototype dEntrept de Donnes Actif (PEDA) Ensuite, nous allons charger le chier XML qui contient la rgle danalyse qui va tre excute comme se dcrit dans la Figure 4.6. Lorsque, nous cliquons sur le bouton "Excution Automatique", comme le montre la Figure 4.5, si les vnements (BOW, Montant > 600 et Duree > 10) sont dclenchs et la condition (Annee = 2011) est vrie, alors les requtes MDX vont tres excutes automatiquement. Ici, il ya une conjonction des vnements entre "Evenement1" (BOW, Montant > 600 ) et "Evenement2" (Duree > 10).
62
Projet Fin dEtude
F IGURE 4.6 Fichier XML associ lexemple En effet, les rsultats des oprations OLAP (Slice, DrillDown et RollUp) de chier XML qui est ci-dessus, sont excutes automatiquement sous forme de requtes MDX lors de dclenchement dvnement et lorsque la condition est vrie. Donc, le rsultat de chaque requte MDX est afche dans une table ans la partie droite de linterface "PEDA" comme le montre la gure ci-dessous. Ainsi, notre prototype "PEDA" prsente le graphe danalyse associ la rgle danalyse prsente ci-dessus en montrant les diffrents chemins danalyse ( dsigne lopration OLAP excute lors de passage dun cube un autre).
63
Projet Fin dEtude
F IGURE 4.7 Rsultat nal de notre exemple Ce graphe danalyse comporte trois sous-graphes danalyse (SG1, SG2, SG3) comme le montre la Figure 4.8. Nous allons expliqu alors lenchanement des oprations OLAP qui correspond notre scnario danalyse. Dans le sous-graphe SG1, en utilisant les oprateurs : 1. Slice, nous slectionnons la modalit "Jerba" dans lattribut "Ville" de la caractristique (dimension) "Agence" ; 2. DrillDown, nous effectuons sur le cube dentre un forage vers le bas en passant de lattribut "Annee" lattribut "Mois" de la caractristique "Temps" ; 3. RollUp, nous effectuons un forage vers le haut en passant de lattribut "Marque" lattribut "Type" dans la dimension "Vehicule". 4. Slice, nous slectionnons le mois "Janvier" dans lattribut "Mois" de la caractristique "Temps" ;
64
Projet Fin dEtude
F IGURE 4.8 Graphe danalyse associ lexemple Dans le sous-graphe SG2, en utilisant les oprateurs : 1. Slice, nous slectionnons la modalit "Bizert" dans lattribut "Ville" de la caractristique "Agence" ; 2. DrillDown, nous effectuons sur le cube dentre un forage vers le bas en passant de lattribut "Trimestre" lattribut "Mois" de la caractristique "Temps" ; 3. RollUp, nous effectuons un forage vers le haut en passant de lattribut "Marque" lattribut "Type" dans la dimension "Vehicule". 4. Slice, nous slectionnons le mois "Janvier" dans lattribut "Mois" de la caractristique "Temps" ; Dans le sous-graphe SG3, en utilisant les oprateurs : 1. Union, nous effectuons lunion entre U3 et U4 pour obtenir un cube permettant de comparer les ventes entre les deux villes (Jerba et Bizert) pour les types de vhicules dans le mois "Janvier ", 2. Slice, nous slectionnons les locations ayant la modalit "Sport" dans lattribut "Type" de la dimension "Vehicule". Dans la cot gauche de linterface ci-dessous, nous incluons la page de serveur Pentaho pour que lutilisateur puisse vrier les rsultats des requtes MDX. Laccs au console Pentaho demande une authentication dutilisateur avec le "Nom dutilisateur = joe" et le "Mot de passe = password".
65
Projet Fin dEtude
F IGURE 4.9 Authentication dutilisateur Aprs lauthetication, nous avons choisi le schma "New Schema3" que nous lavons publi sous Pentaho Schma Workbench. Donc, le cube associ ce schma est apparu automatiquement.
F IGURE 4.10 Accs au cube Locations
66
Projet Fin dEtude
Nous avons expliqu dans la section 4.1 que Mondrian et JPivot sont intgrs dans Pentaho. En fait, aprs la publication du schma du cube "Locations" sous Pentaho Schma Workbench, JPivot permet de reprsenter ce cube sous une vue analytique en forme de tableau multidimensionnel crois ce qui rend la navigation et linterrogation de lentrept de donnes plus simple et rapide comme le montre la capture dcran ci-dessous. Il est possible au dcideur de visualiser et modier la requte MDX. Ainsi, la barre de commandes de JPIVOT qui se trouve au dessus de cette table croise, permet lutilisateur deffectuer diffrentes taches pour mieux manipuler les donnes. Le dcideur peut accder la dnition des axes afcher, ainsi que les fonctions de graphes simplis partir ces icnes.
F IGURE 4.11 Rsultat nal de notre exemple Donc, nous pouvons extraire, consulter et manipuler les donnes de notre base partir cette interface graphique JPivot qui va envoyer des requtes MDX au moteur OLAP Mondrian. Ainsi, pour vrier les rsultats des requtes MDX qui sont expliques prcdemment, nous avons test le premier chemin ( <Slice> (Ville =Jerba) du sous-graphe (SG1) sur le console Pentaho, nous avons obtenu le mme rsultat comme le montre la Figure 4.12.
67
Projet Fin dEtude
F IGURE 4.12 Opration Slice effectue sur le cube Locations Le serveur Pentaho permet aussi dafcher lhistogramme selon la requte MDX excute. Le graphique dans la Figure 4.13 ci-dessous illustre les montant de la location des vhicules relatif la ville Jerba pour lanne 2011. Cette visualisation permet de clarier la vision du dcideur concernant lvolution de ces montants an de prendre la meilleure dcision. Donc, sans une connaissance de ses statistiques, le dcideur nest pas apte interprter la constance ou la variation des agrgats mensuels (Somme de montants) au cours dune anne dans un environnement de grand volume de donnes.
68
Projet Fin dEtude
F IGURE 4.13 Histogramme de lopration Slice
Conclusion
Dans ce chapitre, nous avons prsent larchitecture de systme et lenvironnement de dveloppement logiciel avec lequel ce projet a t ralis. Ensuite, nous avons expliqu une tude de cas sur le cube Locations des vhicules en proposant un scnario danalyse qui permet de comparer les locations des types de vhicules dans le mois "Janvier" dans deux villes diffrentes "Jerba" et "Bizert". En effet, nous avons expliqu lenchainnement de ce scnario par lexcution automatique des requtes MDX qui sont relatives aux oprations OLAP de la rgle danalyse an dobtenir un graphe danalyse. Ainsi, nous avons intgr dans linterface graphique la page du console de Pentah. Cette interface visuelle qui est en ligne avec le paradigme OLAP, permet aux dcideurs de vrier les rsultats de requtes MDX et dinteragir directement avec les cubes de donnes.
69
Conclusion et perspectives
Projet Fin dEtude
Conclusion et perspectives 4.5 Conclusion
l est claire daprs notre tude bibliographique dans le chapitre Etat de lart, nous constatons que les diffrents travaux abordent le problme dautomatisation des scnarios danalyse. Les rgles actives ECA, gnralisent la notion de dclencheur, elles utilisent gnralement le formalisme Evnement-Condition-Action. Donc, rappelons que notre objectif est de proposer une architecture dentrept de donnes actif pour dtecter les vnements complexes. Cest seulement aprs quun vnement dintrt soit produit et soit dtect, les rgles soient dclenches et les actions appropries sont excutes. Lentrept de donnes actif dtecte plusieurs types dvnements pour rpondre diffrentes situations, alors la conjonction de ces vnements facilite le dclenchement dune rgle danalyse. En sinspirant du formalisme des rgles ECA connu dans les bases de donnes actives, nous avons pu dnir un nouveau formalisme pour les rgles danalyse : Evnement-Condition-Graphe danalyse. Nous avons pu prsenter une algbre complte des oprateurs OLAP dans le contexte de graphe danalyse et pour cela, nous sommes servi dune algbre dj existante que nous avons enrichi avec des oprateurs n-aires : lunion (Union), lintersection (Intersect), la diffrence (Diff) et loprateur unaire AddModality pour lajout de modalit. Nous avons prsent une modlisation XML des rgles danalyse. Dans cette modlisation, nous avons respect le formalisme Evnement-Condition-Graphe danalyse. Nous avons prsent, galement, un modle dentrept de donnes actif qui dcrit lintgration des rgles danalyse dans le processus dentreposage. Dans la section suivante, nous prsentons dans quelles directions ce travail pourra tre poursuivi.
4.6
Perspectives
ne des pistes possibles, dans la continuit de nos travaux, est de faire voluer notre entrept de donnes actif vers la personnalisation et la recommandation dans le mcanisme dECG. Ce mcanisme contient une squence des oprations OLAP qui est exprime par des requtes MDX. Un entrept de donnes actif organise les donnes dans des cubes de donnes en classant les donnes en faits et dimensions. Les faits contiennent les donnes analyser, tandis que les dimensions reprsentent les diffrentes perspectives de visualisation des donnes. Une fois que les donnes sont charges, les dcideurs ralisent des sessions danalyses en utilisant des outils OLAP tels que des requtes MDX sur les cubes de donnes an de trouver les solutions diffrentes tches dcisionnelles.
70
Conclusion et perspectives
Projet Fin dEtude
Au cours de notre tude bibliographique, nous avons vu que le lien entre les recommandations et les bases de donnes nest pas trs dvelopp. Cependant, il apparat que : La recommandation consiste guider lutilisateur lors de son exploration de la base de donnes, Un utilisateur explore un cube de donnes en lanant une squence de requtes, Plusieurs utilisateurs diffrents peuvent explorer des parties proches du cube de donnes. Certaines recommandations ne sont pas encore possibles, comme, par exemple, lorsque deux sessions S1 et S2 ne diffrent que dune slection. En effet, dans ce cas, nous voudrions proposer comme recommandation la suite de S2, une des requtes de S1 o seule la slection est modie. Ainsi, et toujours comme perspective dans ce qui concerne le mcanisme dECG, on peut proposer de gnrer une synthse des prfrences pour le prol dutilisateur an de lexploiter dans le processus de personnalisation puisque les conditions de mcanisme dECG sont considres comme des prfrences. Le principe de cette synthse est de souligner toutes les correspondances qui existent entre les prfrences de lutilisateur dans lentrept de donnes an dutiliser ces informations lors de processus de personnalisation pour liminer les lments menant a des rsultats nuls (cellules vides). On obtient ainsi un entrept de donnes actif personnalis. Une autre perspective qui demeure envisageable pour notre ralisation, est dexploiter les requtes dans des sessions ultrieures par des utilisateurs experts an de les dclencher suite loccurrence des vnements correspondants aux prfrences du dcideur. Une telle solution est faisable en appliquant des techniques de fouille de donnes sur lhistorique dinterrogation multidimensionnelle appel Log OLAP.
71
BIBLIOGRAPHIE
Projet Fin dEtude
Bibliographie
[1] [Abell et al.03] Alberto Abell, Jos Samos, Flix Saltor, Implementing operations to navigate semantic star schemas, 6th ACM Intl. Workshop on Data Warehousing and OLAP (DOLAP), ACM Press, p. 5662, 2003. M. Adiba. Entrepts de donnes et fouille de donnes, Introduction, Supports de cours, 2002.
[Adi02]
[Agrawal et al.95] Rakesh Agrawal, Ashish Gupta, Sunita Sarawagi, Modeling Multidimensional Databases, 13th Intl. Conf. on Data Engineering (ICDE), IEEE Computer Society, p. 232243, 1997. [Agrawal et al.97] Rakesh Agrawal, Ashish Gupta, Sunita Sarawagi, Modeling Multidimensional Databases, IBM Research Report, http ://rakesh.agrawalfamily. com/papers/icde97olap_rj.pdf 1995. [Alain09] Alain Fernandez. La Business Intelligence, lInformatique Dcisionnelle. [en ligne]. http ://www.piloter.org/ business-intelligence/business-intelligence.htm (consult le 30 avril 2009). Serge Abiteboul, Richard Hull, and Victor Vianu. Foundations of Databases. Addison- Wesley, 1995 Abiteboul S, Tova S C, and Zohar S, 1999, Tools for Data Translation and Integration. IEEE Data Eng. Bulletin, Volume 22, pp3-8 Rakesh Agrawal, Ashish Gupta, and Sunita Sarawagi. Modeling Multidimensional Databases. In ICDE, pages 232243, 1997. E. Benitez, C. Collet, and M. Adiba. Entrepts de donnes : caractristiques et problmatique. Revue TSI, 20(2), 2001. Bernard ESPINASSE ,Professeur lUniversit dAix-Marseille / cours : Entrepts de donnes : Introduction au langage MDX (Multi-Dimensional eXtensions) pour OLAP, 2009, p18
[AHV95] [Abit et al.99] [AGS97]
[BCA01] [Bern.09]
72
Bibliographie [Bou et al.07]
Projet Fin dEtude Bouattour S., Ben Messaoud R., Boussaid O., Modlisation de rgles danalyse ddies aux entrepts de donnes actifs. , Deuxime Atelier des Systmes Dcisionnels (ASD2007), Sousse, Tunisie. Octobre, 2007. Robert M. Bruckner and Tjoa A. M. Managing Time Consistency for Active Data Warehouse Environments. Lecture Notes in Computer Science, 2001. Sonia BOUATTOUR. Les entrepts de donnes actifs : automatisation des scnarios danalyse, 2006-2007,p10 Jessica Barros. Etat de lart des bases de donnes actives. In IHM04, 2004. James Bailey, Guozhu Dong, and Kotagiri Ramamohanarao. On the Decidability of the Termination Problem of Active Database Systems. Theoretical Computer Science, 2004. Ladjel Bellatreche, Arnaud Giacometti, Patrick Marcel, Hassina Mouloudi, and Dominique Laurent. A personalization framework for OLAP queries. In DOLAP, pages 918, 2005. Ladjel Bellatreche, Arnaud Giacometti, Patrick Marcel, and Hassina Mouloudi. Personalization of MDX Queries. In BDA, 2006. Riadh Ben Messaoud. Couplage de lanalyse en ligne et de la fouille de donnes pour lexploration, lagrgation et lexplication des donnes complexes. PhD thesis, Universit Lyon2, France, Novembre 2006. Luca Cabibbo, Riccardo Torlone, Querying Multidimensional Databases, 6th Intl. Workshop Database Programming Languages (DBPL), LNCS 1369, Springer, p. 319335, 1997. Luca Cabibbo, Riccardo Torlone, From a Procedural to a Visual Query Language for OLAP, 10th Intl. Conf. on Scientic and Statistical Database Management (SSDBM), IEEE Computer Society, p. 7483, 1998. E.F. Codd. Providing OLAP (On-Line Analytical useranalystes : an IT mandate. Technical report, 1993 Processing) to
[BM01] [Bou07] [Bar04] [BDR04]
[BGM05]
[BGMM06] [BM06]
[Cabi et Torlo.97]
[Cabi et Torlo.98]
[Cod93] [CCS93]
E.F. Codd, S.B. Codd, and C.T. Salley. Providing olap (on-line analytical processing) to user-analysts : an it mandate. Technical report, Arbor Software (now Hyperion Solutions), 1993. Surajit Chaudhuri and Umeshwar Dayal. An Overview of Data Warehousing and OLAP Technology. SIGMOD Record, 26(1) :6574, 1997. Luca Cabibbo and Riccardo Torlone. From a Procedural to a Visual Query Language for OLAP. In Maurizio Rafanelli and Matthias Jarke, editors, 10th
[CD97] [CT98]
73
Bibliographie
Projet Fin dEtude International Conference on Scientic and Statistical Database Management, Proceedings, Capri, Italy, July 1-3, pages 7483. IEEE Computer Society, 1998.
[Colliat96] [Datt et Thom99]
George Colliat, OLAP, relational, and multidimensional database systems, ACM SIGMOD Record, vol.25(3), ACM Press, p. 6469, septembre 1996. Anindya Datta, Helen Thomas, The cube data model : a conceptual model and algebra for on-line analytical processing in data warehouses, Decision Support Systems (DSS), vol.27(3), Elsevier, p. 289301, dcembre 1999. Daniel Lumier, Linformatique des entrepots de donnes, http ://benhur.teluq.uquebec.ca/SPIP.inf9004/IMG/pdf_semaine10-5.pdf A. Doucet and S. Gangarski. Entrepts de donnes et Bases de Donnes Multidimensionnelles, Chapitre 12 du livre : Bases de Donnes et Internet, Modles, langages et systmes. Editions Herms, 2001. Umeshwar Dayal, Eric N. Hanson, and Jennifer Widom. Active Database Systems. In Modern Database Systems, pages 434456. 1995. Elsa NEGRE, Thse : Exploration Collaborative de Cubes de Donnes, 01 dcembre 2009, page22 Ezekiel, K. and Marir F, 2003. A conceptual model for managing knowledge represented as triggers in active databases : 4th European Conference on Knowledge Management, pp. 323-333 Ezekiel, K. and Marir F. Enhancing Data Preparation Processus Using Trigger For Avctive DataWarehousing. Conference on Data Mining , 2006, pp. 150,158 Enrico Franconi, Anand Kamble, The GMD Data Model and Algebra for Multidimensional Information, 16th Intl. Conf. on Advanced Information Systems Engineering (CAiSE), LNCS 3084, Springer, p. 446462, 2004. J-M Franco. Le Data Warehouse (Le Data Mining). Editions Eyrolles, Paris, 1997. Favre, C., Bentayeb, F., & Boussaid, O. (2007). Evolution of Data Warehouses Optimization : a Workload Perspective. Intl. Conf. on Data Warehousing and Knowledge Discovery (DaWaK), Springer, pages 1322. Jim Gray, Adam Bosworth, Andrew Layman, Hamid Pirahesh, Data Cube : A Relational Aggregation Operator Generalizing Group-By, Cross-Tab, and Sub- Total, 12th Intl. Conf. on Data Engineering (ICDE), IEEE Computer Society, p. 152 159, 1997.
[Daniel] [DG01]
[DHW95] [Elsa.09] [Ezek et Mari.03]
[Ezek et Mari.06]
[Fran et Kam.04]
[Fra97] [Favre et al.07]
[Gray et al.97]
74
Bibliographie
Projet Fin dEtude
[Gyss et Laksh97] Marc Gyssens, Laks V. S. Lakshmanan, A Foundation for Multi-dimensional Databases, 23rd Intl. Conf. on Very Large Data Bases (VLDB), Morgan Kaufmann, p. 106115, 1997. [GL97] Marc Gyssens and Laks V. S. Lakshmanan. A Foundation for Multi-dimensional Databases. In VLDB, pages 106115, 1997
[Garrigs et al.09] Garrigs, I., Pardillo, J., Mazn, J., Trujillo, J. (2009). A Conceptual Modeling Approach for OLAP Personalization. Intl. Conf. on Conceptual Modeling (ER), pages 401414. [Golfarelli et al.11] Golfarelli, M., Rizzi, S., Biondi, P. (2011). myOLAP : An Approach to Express and Evaluate OLAP Preferences. IEEE Transactions on Knowledge and Data Engineering (TKDE), Vol. 23, No. 7, pages 10501064. [Giacometti et al.09] Giacometti, A, Marcel, P., Negre, E. (2009). Recommending Multidimensional Queries. Intl. Conf. on Data Warehousing and Knowledge Discovery (DaWaK), Springer, pages 453 466. [Han et Davi.07] [Hurtado et al.99] Hans M, and G. Complex Event Processing in the context of Business Activity Monitoring, 2007, p168 Hurtado, C. A., Mendelzon, A. O., Vaisman, A. A. (1999). Maintaining Data Cubes under Dimension Updates. Intl. Conf. on Data Engineering (ICDE), IEEE Computer Society, pages 346355. W. H. Inmon. Building the data warehouse. QED Information Sciences, Inc.,Wellesley, MA, USA, 1992. W.H. (1996). Building the Data Warehouse, John Wiley and Sons, New York, NY, ISBN : 0764599445, 1996 (2me ed.), 4me ed. 2005. W. H. Inmon and D. Richard Hackathorn. Using the Data Warehouse. Wiley-QED Publishing, Somerset, NJ, USA, 1994. H. Jerbi. thse : Personnalisation danalyses dcisionnelles sur des donnes multidimensionnelles.Universit Toulouse 1 Capitole,20 janvier 2012,p10 Matthias Jarke, Maurizio Lenzerini, Yannis Vassiliou, and Panos Vassiliadis. Fundamentals of Data Warehouses. Springer-Verlag New York, Inc., Secaucus, NJ, USA, 2001 Julyan Hyde. Julian Hyde on Open Source OLAP. And Stuff. [en ligne]. http ://julianhyde.blogspot.com/ (30 avril 2009)
[Inm92] [Inm96] [IRH94] [Jerbi12] [JLVV01]
[July09]
75
Bibliographie [JLS99] [Kelly97 ] [Kim96] [Lamia06] [Li et Wan.96]
Projet Fin dEtude H. V. Jagadish, Laks V. S. Lakshmanan, and Divesh Srivastava. What can Hierarchies do for Data Warehouses ? In VLDB, pages 530541, 1999. KELLY Sean. Data warehousing in action. Chichester, West Sussex, England : John Wiley & Sons, 1997, 334 p. Ralph Kimball. The Data Warehouse Toolkit : Practical Techniques for Building Dimensional Data Warehouses. John Wiley, 1996. Lamiaa NAOUM.Un modle multidimensionnel pour un processus danalyse en ligne de rsums ous, Universit de Nantes, 22 novembre 2006, p18 Chang Li, Xiaoyang Sean Wang, A Data Model for Supporting On- Line Analytical Processing, 5th Intl. Conf. on Information and Knowledge Management (CIKM), ACM Press, p. 8188, 1996. Ling Liu, Calton Pu, Wie Tang, Contunial Query For Internet Scale Event-Driven Information Delivry, 2001 Peter Lyman, Hal R. Varian, Peter Charles, Nathan Good, Laheem L. Jordan, and Joyojeet Pal. How much information ? Available at http ://www2.sims.berkeley. edu/research/projects/how-much-info-2003/, 2003. Microsoft Corporation. Multidimensional Expressions (MDX) Reference. Available at http ://msdn.microsoft.com/en-us/library/ms145506.aspx, 1998. Andreas S. Maniatis, Panos Vassiliadis, Spiros Skiadopoulos, and Yannis Vassiliou. CPM : A Cube Presentation Model for OLAP. In DaWaK, pages 413, 2003. Microsoft Corporation, Multidimensional Expressions (MDX) Reference (documentation en ligne), 2007, http ://msdn2.microsoft.com/en-us/library/ms145506.aspx Melanie Herschel/ cours : Bases de Donnes OLAP/ Hiver 2012/2013, p 65
[Ling et al.01] [LVC03]
[Mic98] [MVSV03]
[Microsoft]
[Mela12/13]
[Marc et Negre.11] Marcel, P., Negre, E. (2011). A survey of query recommendation techniques for datawarehouse exploration. Journes francophones sur les Entrepts de Donnes et lAnalyse en ligne (EDA). [Natacha et al.12] [Negre09] [ORA09] Natacha SKRZYPCZAK et al. Thse Professionnelle. Linformatique dcisionnelle. Maxime Poletto,01 Juin 2012 E.Negre. Thse : Exploration collaborative de cube de donnes. Universit Franois Rabelais Tours, 01 dcembre 2009, p31 ORACLE. Oracle OLAP 11g. Available http ://www.oracle.com/technology/ products/bi/olap, 2009. at
76
Bibliographie [Oracle 2006]
Projet Fin dEtude Oracle : Rules Manager. 2006. http ://downloaduk. oracle.com/docs/cd/B19306_01/appdev.102/b14288/exprn_part1.htm#CHDBF ICB. downloaded 2007-05-17 D. J. Power. Decision support systems glossary, dssresources.com, world wide web, 2007. Last updated November 18, 2009. 3 Pentaho, Pentaho Analysis Services : Mondrian Project, site Web, Pentaho Corporation, 2007, http ://mondrian.pentaho.org . Pentaho Corporation. Mondrian open source OLAP engine. Available at http :// mondrian.pentaho.org, 2009.
[Pow07] [Pentaho] [Pen09]
[Pedersen et al.01] Torben Bach Pedersen, Christian S. Jensen, Curtis E. Dyreson, A foundation for capturing and querying complex multidimensional data, Information Systems (IS), vol.26(5), Elsevier, p. 383423, juillet 2001. [PSV02] Neoklis Polyzotis, Spiros Skiadopoulos, Panos Vassiliadis, Alkis Simitsis, and Nils- Erik Frantzell. Supporting Streaming Updates in an Active Data Warehouse. In Personal and Ubiquitous Computing. Paton, N. W. and Diaz, O. 1999. Active database systems. ACM Comput. Surv. 31, 1, 63{103. Pietzuch, P., Ledlie, J., Shneidman, J., Roussopoulos, M., Welsh, M., and Seltzer, M. 2006. Network-aware operator placement for stream-processing systems. In ICDE 06 : Proceedings of the 22nd International Conference on Data Engineering. IEEE Computer Society, Washington, DC, USA, 49. Pitkow, J. E., Schutze, H., Cass, T. A., Cooley, R., Turnbull, D., Edmonds, A., Adar, E., Breuel, T. M. (2002). Personalized Search. Communications of the ACM, Vol. 45, No. 9, pages 5055. Ronan Tournier. Thse : Analyse en ligne (OLAP) de documents, Universit Toulouse III Paul Sabatier, 13 dcembre 2007, p.19-21 F. Ravat, O. Teste et G. Zuruh. Manipulation et fusion de donnes multidimensionnelles. In RNTI-E-3 Revue des Nouvelles Technologies de lIn- formation, rd., Extraction et Gestion des Connaissances (EGC2005) Vol. I, pages 349354, Paris, France, Janvier 2005. Cpadues (ed.). Franck Ravat, Olivier Teste, Ronan Tournier, and Gilles Zuruh. Algebraic and graphic languages for olap manipulations. IJDWM, 4(1) :1746, 2008. Oscar Romero and Alberto Abell. On the Need of a Reference Algebra for OLAP. In DaWaK, pages 99110, 2007.
[Pato et Diaz.99]
[Pitkow et al.02]
[Ronan07] [Ravat et al.]
[RTTZ08] [RA07]
77
Bibliographie
Projet Fin dEtude
[Rahm et Doh.00] Rahm. E, and Do. HH, 2000,Data Cleaning : Problems and Current Approaches, IEEE Bulletin of the Technical Committee on Data Engineering,Volume 23 No. 4 [Sand07] Sandro Bimonte. Intgration de linformation gographique dans les entrepts de donnes et lanalyse en ligne : de la modlisation la visualisation.18 Dcembre 2007,p18 SAS. SAS OLAP Server. Available at http ://www.sas.com/technologies/dw/ storage/mddb, 2009. Kenneth Paul Smith. Managing Rules in Active Databases. PhD thesis, Champaign, IL, USA, 1992. O. Teste. Modlisation et manipulation dentrepts de donnes complexes et historises. PhD thesis, Universit Paul Sabatier de Toulouse, Dcembre 2000. T Thalhammer, M Schre, and M Mohania. Active Data Warehouses : Complementing OLAP with Analysis Rules. Data and Knowledge Engineering, 39(3) :241269, 2001. T Thalhammer and M Schre. Realizing Active Data Warehouses with O-the-Shelf Database Technology. Software Practice and Experience, 32(12) :11931222, 2002. M. Nguyen Tho and A. Min Tjoa. Zero-Latency Data Warehousing For Heterogeneous Data Sources and Continuous Data Streams. In Services Computing, pages 357 365, 2004. J.D. Ullman. Principles of Database Systems. 1982 Wu,M.-C. et A. Buchmann (1997). Research issues in data warehousing. in Datenbanksysteme in Bro, Technik und Wissenschaft(BTW97), 6182..
[SAS09] [Smi92] [Tes00] [TSM01]
[TS02]
[TT04]
[Ull82] [WMB97]
78
Annexe A : Mondrian
Projet Fin dEtude
Annexes Annexe A : Le Moteur Mondrian Installation de Mondrian/Tomcat/MySQL

Nous essayons au dbut de travailler avec Mondrian dans ce projet, nous arrivons linstaller, mais nous trouvons des problmes dintgration de notre base de donnes qui est cre sous MySQL dans Mondrian. Donc, dans ce cas, nous cherchons une solutions et nous trouvons un autre logiciel qui contient le moteur Mondrian et dautres options supplmentaires. En fait, voil ce lien ( http ://eric.univ-lyon2.fr/~kaouiche/inf9002/mdx.html ) qui explique les tapes dinstallation qui sont : 1. Installer Tomcat 2. Installer MySQl 3. Installer Mondrian : a- Dcompresser le chier mondrian.war dans le rpertoire webapps de tomcat : ( la dcompression de chier.war se fait comme a : ouverture de ce chier avec WinRaR e extraire leur contenu dans le wapps) b- Cration de base de donnes foodmart : -Tlcharger foodmart_mysql.tar et le dcompresser dans le rpertoire \MySQL\MySQL Server 5.0\bin\ (voir les liens :http ://www.ismll.uni-hildesheim.de/lehre/bi-12s/exercises/ Jaspersoft-OLAP-Ultimate-Guide.4.0.pdf et http ://codeissue.com/articles/a04e979108dea7f/ saiku-analytics-datasource-conguration-in-pentaho-cdf-with-mysql-foodmart) - Ouvrir mysql - Cre une base de donnes test foodmart : create database foodmart ; - grant all privileges on *.* to foodmart@localhost identied by foodmart ; - Show databases ; - Use foodmart ; database changed - Pour excuter le script.sql : mysql> source C :\Program Files\MySQL\MySQL Server 5.0\bin\foodmart_mysql.sql ; - Show tables ;
79
Annexe A : Mondrian
Projet Fin dEtude
F IGURE 4.14 Tables de la base foodmart c- Conguration de mondrian avec MySQL : voir lien : ( http ://tranchant.name/2011/ 12/mondrian-en-serveur-xmla/ ) : - Modiez le chier WEB-INF/datasources.xml. Effacez tout, et remplacez par ce contenu ( datasource se trouve dans : C :\Program Files\Apache Software Foundation\Tomcat 5.5\webapps\mondrian\WEB-INF) -Copier le mysql-connector-java-5.1.18-bin.jar dans le rpertoire lib de lapplication (C :\ Program Files\Apache Software Foundation\Tomcat 5.5\webapps\mondrian\WEB-INF\lib) > Pour le test : - Lancez Tomcat an de vrier le bon fonctionnement de base. En atteignant lURL par dfaut de Mondrian : ( http ://localhost :8080/mondrian/ ), vous aurez un capture dcran de ce genre comme le montre la Figure 7.2 :
F IGURE 4.15 Interface Mondrian - Cliquez sur XML for Analysis Tester comme lindique la Figure 7.3 :
80
Annexe A : Mondrian
Projet Fin dEtude
F IGURE 4.16 XML for Analysis Tester - Puis cliquez sur Run en bas de la grande zone de texte. Si tout est bien congur, vous devriez obtenir un rsultat XML similaire la cature dcran dans la Figure 7.4 :
F IGURE 4.17 Rsultat XML
81
Annexe A : Mondrian
Projet Fin dEtude
d- Mondrian et JPivot : ( voir le lien : http ://tranchant.name/2011/12/mondrian-jpivot/) : -Editez le chier C :\Program Files\Apache Software Foundation\Tomcat 5.5\webapps\ mondrian\WEB-INF\mondrian.properties : -Editez le chier WEB-INF/web.xml.
82
Annexe B : Pentaho
Projet Fin dEtude
Annexe B : La Plate-forme Pentaho Installation de Pentaho/Tomcat/MySQL/SchemaWork- bench

Installation de Pentaho/Tomcat/MySQL/Schema Workbench Lorsque nous arrivons pas dintgrer notre base de donnes dans Mondrian, alors nous avons travaill avec Pentaho. Les tapes dinstallation sont comme suit : 1. Installer Tomcat 2. Installer MySQL 3. Installer Pentaho Schma Workbench 4. Installer Pentaho Business Analytics - Tout dabord, il faut crer la base de donnes et les tables correspondantes sous MySQL.
F IGURE 4.18 Capture dcran de la table de fait et des dimensions Ensuite, il faut connecter la base de donnes qui a dj cre sous MySQL sous Pentaho Schma Workbench comme le montre la capture dcran ci-dessous en saisissant (Connection Name, HostName, Database Name et le Password). Puis, un message de comrmation est apparu si le test est vrai.
83
Annexe B : Pentaho
Projet Fin dEtude
F IGURE 4.19 Connexion la base de donnes Aprs linstallation de ces logiciels, nous allons crer sous Pentaho Schma Workbench tout dabord le schma du cube qui correspond notre base de donnes cre sous MySQL. Alors , nous obtenons le schma comme lindique la Figure 7.6.
F IGURE 4.20 Schma du cube Locations
84
Annexe B : Pentaho
Projet Fin dEtude
Ensuite, on va publier se schma sur le serveur Pentaho : Mettre le chier.xml sous C :\Users\tt\Desktop\Pentaho_Business_Analytics\biserver-ce\pentaho-solutions\s Copier le pilote jdbc mysql-connector-java-5.1.23-bin sous C :\Users\tt\Desktop\Pentaho _Business_Analytics_3.6\administration-console\jdbc Copier le pilote jdbc mysql-connector-java-5.1.23-bin sous C :\Users\tt\Desktop\Pentaho _Business_Analytics_3.6\biserver-ce\tomcat\webapps\pentaho\WEB-INF\lib
F IGURE 4.21 Publication de chier XML Aprs la publication de schma du cube, on accde sur le console Pentaho pour manipulet et interrger notre base de donnes facilement.
F IGURE 4.22 Console de Pentaho
85

Rapport Eda Pfe

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Rapport Eda Pfe

Загружено:

Авторское право:

Доступные форматы

Projet Fin dEtude

Projet Fin dEtude

TABLE DES MATIRES

Projet Fin dEtude

Table des matires

TABLE DES MATIRES

Projet Fin dEtude . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 33 34 35 35 35 36 36 37 38 42 43 43 44 49 50 50 50 51 54 54 54 55 57 59 60 62 70 70 70 72 79 79 83

TABLE DES FIGURES

Projet Fin dEtude

Table des gures

TABLE DES FIGURES

Projet Fin dEtude . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 80 80 81 81 83 84 84 85 85

LISTE DES TABLEAUX

Projet Fin dEtude

Liste des tableaux

Projet Fin dEtude

Projet Fin dEtude

CHAPITRE 1. CONCEPTS DE BASE

Projet Fin dEtude

Chapitre 1 Concepts de base

CHAPITRE 1. CONCEPTS DE BASE

Projet Fin dEtude

Utilisation Conception Donnes

Source Accs Requtes / Utilisation

Les caractristiques des entrepts de donnes

CHAPITRE 1. CONCEPTS DE BASE

Projet Fin dEtude

Architecture des entrepts de donnes

F IGURE 1.1 Architecture dEntrept de Donnes [Sand07]

Entrept et les bases de donnes relationnelles

CHAPITRE 1. CONCEPTS DE BASE

Projet Fin dEtude

CHAPITRE 1. CONCEPTS DE BASE

Projet Fin dEtude

CHAPITRE 1. CONCEPTS DE BASE

Projet Fin dEtude

CHAPITRE 1. CONCEPTS DE BASE

Projet Fin dEtude

Architecture dun systme dcisionnel

CHAPITRE 1. CONCEPTS DE BASE

Projet Fin dEtude

Alimentation (ETL) dun entrept de donnes

CHAPITRE 1. CONCEPTS DE BASE

Projet Fin dEtude

Linterrogation des bases des donnes multidimensionnelles

CHAPITRE 1. CONCEPTS DE BASE

Projet Fin dEtude

Le modle de donnes dans notre contexte

Les langages de manipulation de donnes

CHAPITRE 1. CONCEPTS DE BASE

Projet Fin dEtude

CHAPITRE 1. CONCEPTS DE BASE

Projet Fin dEtude

CHAPITRE 1. CONCEPTS DE BASE

Projet Fin dEtude

Le langage utilis dans notre approche

CHAPITRE 1. CONCEPTS DE BASE

Projet Fin dEtude

CHAPITRE 1. CONCEPTS DE BASE

Projet Fin dEtude

CHAPITRE 1. CONCEPTS DE BASE

Projet Fin dEtude

CHAPITRE 2. ETAT DE LART

Projet Fin dEtude