Conception et construction d’entrepôts en XML

Présentation au sujet: "Conception et construction d’entrepôts en XML"— Transcription de la présentation:

1 Conception et construction d’entrepôts en XML
Omar Boussaid – Riadh Ben Messaoud – Rémy Choquet – Stéphane Anthoard Laboratoire ERIC, Université Lyon 2 Campus Porte des Alpes, 69676 Bron Cedex - EDA - Versailles, juin 2006

2  Il est alors nécessaire de les structurer et de les homogénéiser.
Motivation Données complexes : formats différents, supports différents. Exemple : dossier d’un patient (informations générales sur le patient : age, sexe, etc, + images de scanner, des interrogatoires sous forme d’enregistrements sonores + compte-rendus manuscrits de médecins)  Il est alors nécessaire de les structurer et de les homogénéiser.  XML représente les données de façon semi-structurée. Sa capacité d’auto-description et sa structure arborescente donne à ce formalisme une grande flexibilité et une puissance suffisante pour décrire des données complexes, hétérogènes et réparties EDA, Versailles 19 juin 2006

3 Motivation EDA, Versailles 19 juin 2006
X-Warehousing est une approche pilotée par les besoins d’analyse. Elle part des objectifs d’analyse d’un utilisateur représentés par un modèle conceptuel multidimensionnel (MCM). Elle utilise un ensemble de données complexes structurées dans des documents XML pour générer une base organisée de façon ultidimensionnelle exprimant un contexte d’analyse. Il n’est pas utile de chercher au départ une structure commune multidimensionnelle dans les documents XML sources, car elle n’existe pas a priori. Ainsi, nous nous focalisons plutôt sur les besoins d’analyse de l’utilisateur que nous représentons par un schéma en étoile. Ce dernier exprime comment représenter conceptuellement les données pour les orienter vers l’analyse et cela indépendamment de la manière de les organiser aux niveaux logiques ou physiques. Le MCM et les documents XML sources sont initialement exprimés à l’aide de schémas XML pour être appariés. Cependant pour les rendre comparables, ils sont alors traduits sous forme d’arbre d’attributs, Golfarelli et al. (1998); Golfarelli et Rizzi (1999). Les deux arbres d’attributs représentant respectivement le MCM et les documents XML sources qui seront fusionnés selon une certaine stratégie à l’aide d’opérations de fusion par élagage (pruning) et/ou par greffe (grafting), Golfarelli et al. (2001a,b). Le MCM est une grammaire du cube XML comme c’est le cas du schéma XML et le document XML EDA, Versailles 19 juin 2006

4 Plan Motivation Etat de l’art Notre approche X-Warehousing
Formalisation Construction d’un cube XML Implémentation Etude de cas Conclusion et prespectives EDA, Versailles 19 juin 2006

5 Etat de l’art Baril et Bellahsène (2000) : Dawax, Modèle de vues (View Manager) Pokorny (2001) : XML Stars schema Golfarelli et al. (2001) : Modèle Dimensionnel de Faits ; arbres d’attributs Hümmer et al. (2003) : Xcube Rajugan et al. (2003) : utilisation des packages UML Trujillo et al. (2004) : l’approche orientée objet(OO) Pokorný (2001) : structure de données, appelée XMLStar schema avec des hiérarchies de dimensions explicites utilisant des DTDs pour décrire la structure des objets. Une dimension est modélisée comme une séquence de DTDs logiquement associées, telle l’intégrité référentielle dans les BDR. Notion d’intégrité référentielle XML et ses propriétés requises pour caractériser des collections de XML.  Golfarelli et al. (2001a), XML solution pour l’intégration des sources d’information dans des SD basé sur la représentation d’arbre d’attributs. Possibilité de recourir aux schémas XML pour représenter des modèles multidimensionnels en exprimant les relations à l’aide de sous-éléments et de clef REF/IDREF.  Trujillo et al. (2004). A des niveaux structurel et dynamique, un modèle conceptuel standard doit considérer toutes les propriétés multidimensionnelles. L’approche OO avec UML. Pour faciliter l’échange du MCM les auteurs produisent une DTD à partir de laquelle des docs XML valides sont générés pour représenter des MMD à un niveau conceptuel.  Nassis et al. (2004). : approche OO similaire pour développer un modèle conceptuel d’un entrepôt de docs XML (XDW), Concevoir et construire un repository (une collection) de docs XML appelé xFACT.  Rajugan et al. (2003) : utilisent des diagrammes de packages UML pour construire des vues concept. hiérarchiques.  Baril et Bellahsène (2000): approche de manipulation d’une BD XML, appelée Modèle de Vues: mécanisme de vues pour restructurer les données contenues dans des docs XML et répondre aux besoins d’analyse de l’utilisateur. Ils ont défini un modèle de données pour chaque vue pour représenter des données semi-structurées. Dans Baril et Bellahsène (2003), les auteurs proposent DAWAX, un entrepôt de docs XML basé sur le modèle des vues. Leur système consiste en un gestionnaire de vues (View Manager), une interface entre les sources XML et les clients.  Hümmer et al. (2003): XCube supporte un modèle MD sur divers sources de données. Il a 3 schémas XML décrivant entièrement un cube: (1) XCubeSchema pour décrire le schéma MD; (2) XCubeDimension pour décrire la structure hiérarchique des dimensions ; et (3) XCubeFact qui contient l’ensemble des faits. Cette approche utilise XML pour l’échange des cubes de données via Internet, plutôt que la modélisation MD avec XML.  Park et al. (2005): démarche XML-OLAP, assez proche de X-Warehousing. Elle consiste à créer un entrepôt XML composé d’un ensemble de collections de docs XML représentant les faits et les dimensions. Ils utilisent XQuery et le langage MDX de Microsoft qu’ils ont adapté à XML pour construire des cubes XML. Nassis et al. (2004) :approche OO , repository xFacts et Dimensions virtuelles Rusu et al. (2005) : Entrepôts XML Park et al. (2005) : XML-OLAP EDA, Versailles 19 juin 2006

6 Deux approches différentes :
Etat de l’art Deux approches différentes : 1°) Stockage physique des documents XML dans des ED. Les documents XML alimentent alors les ED et XML est considéré comme une technologie efficace supportant des données faiblement structurées et adaptée à l’interopérabilité et à l’échange des données. 2°) Utilisation du formalisme XML pour concevoir des ED.  Selon les modèles multidimensionnels classiques tels que les schémas en étoile ou en flocons de neige. EDA, Versailles 19 juin 2006

7 L’approche X-Warehousing
Contexte général de notre approche EDA, Versailles 19 juin 2006

8 Formalisation Définition : Schéma en étoile XML
Soit (F,D) un schéma en étoile, où : F est un ensemble de faits ayant m mesure {F.Mq, 1 ≤ q ≤ m} et D = {Ds, 1 ≤ s ≤ r} un ensemble de r dimension où chaque Ds contient un ensemble de ns attributs {Ds.Ai, 1 ≤ i ≤ ns}. Le Schéma en étoile XML de (F,D) est un schéma XML tel que : – F définit l’élément racine dans le schéma XML ; –  q  {1, ,m}, F.Mq définit un attribut XML inclus dans l’élément racine ; – s  {1, , r}, Ds est un sous éléments XML de l’élément racine XML. Il y a autant de sous éléments XML que de dimensions liées à l’ensemble des faits F ; – s  {1, , r} et  i  {1, , ns}, Ds.Ai définit un attribut XML inclus dans l’élément XML Ds. EDA, Versailles 19 juin 2006

9 Description d’un cube par un schéma XML
<xs:element name="F"> <xs:complexType> <xs:sequence> <xs:element name="D1" type="D1_Type" /> <xs:element name="D2" type="D2_Type" /> <xs:element name="D3" type="D3_Type" /> <xs:element name="D4" type="D4_Type" /> </xs:sequence> <xs:attribute name="F.M1" type="xs:integer" /> <xs:attribute name="F.M2" type="xs:integer" /> </xs:complexType> </xs:element> <xs:complexType name="D1_Type"> <xs:attribute name="D1.A1" type="xs:string" /> <xs:complexType name="D2_Type"> <xs:attribute name="D2.A1" type="xs:string" /> <xs:attribute name="D2.A2" type="xs:string" /> <xs:complexType name="D3_Type"> <xs:attribute name="D3.A1" type="xs:string" /> <xs:attribute name="D3.A2" type="xs:string" /> <xs:complexType name="D4_Type"> <xs:attribute name="D4.A1" type="xs:string" /> EDA, Versailles 19 juin 2006

10 Formalisation Définition Dimension Hiérarchisée XML :
Soit H = {D1, ,Dt, ,Dl } une dimension hiérarchisée. La dimension hiérarchisée XML est une partie d’un schéma XML tel que : – D1 définit un élément XML ; –   t  {2, , l }, Dt définit un sous élément XML de l’élément XML Dt−1 ; –  t  {1, , l }, chaque attribut dans Dt définit un attribut XML inclus dans l’élément XML Dt. Définition Modèle en flocons de neige XML : Soit (F,H), un modèle en flocons de neige où F est un ensemble de faits ayant m mesures {F.Mq, ≤ q ≤ m} et H = {Hs, ≤ s ≤ r} est un ensemble de r hiérarchies indépendantes. Le modèle en flocons de neige XML de (F,H) est un schéma XML tel que : – F définit l’élément XML racine du schéma XML ; – q  {1, ,m}, F.Mq définit un attribut XML inclus dans l’élément racine XML ; – s  {1, , r}, Hs définit autant de fois des dimensions hiérarchisées XML, comme des sous éléments de l’élément XML racine qu’elle est liée à l’ensemble de faits F. EDA, Versailles 19 juin 2006

11 Exemple d’un fait XML <?xml version="1.0" encoding="UTF-8" ?>
<Suspicious_region Region_length="287" Number_of_regions="6"> <Patient Patient_age="60" > <Age_class Age_class_name="Between 60 and 69 years old" /> </Patient> <Lesion_type Lesion_type_name="calcification type round_and_regular distribution n/a"> <Lesion_category Lesion_category_name="calcification type round_and_regular" /> </Lesion_type> <Assessment Assessment_code="2" /> <Subtlety Subtlety_code="4" /> <Pathology Pathology_name="benign_without_callback" /> <Date_of_study Date=" "> <Day Day_name="June 4, 1998"> <Month Month_name="June, 1998"> <Year Year_name="1998" /> </Month> </Day> </Date_of_study> <Date_of_digitization Date=" "> <Day Day_name="July 20, 1998"> <Month Month_name="July, 1998"> </Date_of_digitization> <Digitizer Digitizer_name="lumisys laser" /> <Scanner_image Scanner_file_name="B_3162_1.RIGHT_CC.LJPEG" /> </Suspicious_region> EDA, Versailles 19 juin 2006

12 Construction des cubes XML
 MCM : besoins d’analyses  Documents XML  Algorithmes d’appriement basés sur des opérations de fusion par élagage et de fusion par greffe Notion d’arbre d’attributs (Golfarelli et al , Golfarelli er Rizzi 1999, Golfarelli et al. 2001 EDA, Versailles 19 juin 2006

13 Construction des cubes XML
Fusion des arbres d’attributs : MCM : besoins d’analyses  arbre d’attributs Documents XML  arbre d’attributs  Schéma XML d’un cube XML Opérations de fusion des arbres d’attributs Notion de contenu minimal EDA, Versailles 19 juin 2006

14 Construction des cubes XML
Fusion des arbres d’attributs Fusion par élagage (pruning) : supprimer des parties des 2 arbres. : sommets communs conservés dans l’arbre fusionné. : sont élagués avec les sous-arbres associés cercles blancs cercles noirs Fusion par greffe (grafting) : sous-arbres communs n’ayant pas la même structure de relations. : certains sommets non communs sont éliminés et : sommets identiques et leurs relations sont maintenus dans l’arbre fusionné. Les descendants d’un sommet éliminé sont conservés dans l’arbre fusionné. cercles blancs cercles noirs EDA, Versailles 19 juin 2006

15 Construction des cubes XML
Contenu minimal d’un document XML Le document XML doit contenir suffisamment d ’information pour répondre aux besoins d’analyse de l’utilisateur : contrôle sur l’arbre d’attributs. L’’utilisateur définit les éléments (mesures, dimension, hiérarchis et leurs attributs) dans le MCM nécessaires ou pas (obligatoires ou optionnels) pour ses objectifs d’analyse. Le contenu minimal d’un document XML corresponds donc à la partie obligatoire de l’arbre d’attributs associé au MCM. EDA, Versailles 19 juin 2006

16 Implémentation EDA, Versailles 19 juin 2006

17 Implémentation Function WriteTreeDeep(document,tree)
root=GetRootElement(document) nodeList=GetNodes(tree,root) While Not(end(nodeList)) Graphe.AddVertex(nodeList.name) Call Function ReadTreeDeep(nodeList.name,tree) End While End Function Function ReadTreeDeep(root,tree) nodeList=GetNodes(tree,root) While Not(end(nodeList)) Graphe.AddVertex(nodeList.name) Call Function ReadTreeDeep(nodeList.name,tree) End While End Function Lorsque le MCM est saisi manuellement, il est automatiquement décrit en schéma XML, stocké dans un fichier XSD et ensuite transformé en arbre d’attributs. Lorsque l’utilisateur charge un fichier XSD, ce dernier est considéré comme un type document JDOM. Il est alors analysé par un algorithme de l’interface JDOMAPI et l’arbre d’attributs correspondant est construit. Les fonctions recursives WriteTreeDeep et ReadTreeDeep que nous avons créées pour manipuler les arbres d’attributs. Le module de chargement charge respectivement le MCM et les documents XML en entrée. Ces derniers, le MCM et leurs arbres d’attributs sont tous décrits en schémas XML pour faciliter leur manipulation par les algorithmes de traitements. L’arbre d’attributs est un arbre orienté, acyclique et a un centre. Il est entièrement compatible avec la structure XML des documents en entrée. - Fonctions recursives WriteTreeDeep et ReadTreeDeep pour manipuler les arbres d’attributs EDA, Versailles 19 juin 2006

18 Implémentation Function MergeTree(tree1,tree2)
tree3=DuplicateTree(tree1) While Not(end(nodeList(tree3))) vertex1=GetVertex(tree3) While Not(end(nodeList(tree2))) vertex2=GetVertex(tree2) If vertex2=vertex1 Then vertex1.arc = 0 End While Tree3=WriteTree(tree3) End Function Le module de fusion utilise les opérations de fusion par élagage et par greffe. La fonction MergeTree que nous avons développée pour fusionner deux arbres d’attributs. Cette fonction lit les deux arbres respectifs du MCM et du document XML source et génère l’arbre fusionné. Celui-ci correspond au schéma du cube XML à partir duquel les documents XML valides générés vont alimenter le cube XML. Quand un sommet de l’arbre du MCM ne correspond pas à un noeud de l’arbre du document source, nous plaçons la valeur d’arc à zéro. Nous réécrivons ensuite l’arbre seulement avec les arcs non nuls. - Fonction MergeTree pour fusionner deux arbres d’attributs EDA, Versailles 19 juin 2006

19 Etude de cas : Contexte DDSM (Digital Database for Screening Mammography) : une BD complexes (2 604 dossiers de patients ; Un volume total de 230,9 Go) Un dossier est composé de : 1 fichier .ics décrivant en format ASCII, les informations générales d’un dossier de patient. 4 fichiers images .LJPEG (LOSSLESS JPEG) des radios numérisées. Chaque radio présente une angle de vue du sein : Left_CC, Left_MLO, Right_CC, Right_MLO (CC: Cranio-Caudal ; MLO: Medio-Latral Oblique). Pour chaque radio présentant une ou des zones anormales, est associé un fichier .OVERLAY en format ASCII, décrivant une anomalie du sein. 1 fichier image .16_PGM regroupant les 4 radios et présentant un aperçu rapide pour la visualisation d’un dossier de patient. EDA, Versailles 19 juin 2006

20 Etude de cas : Contexte EDA, Versailles 19 juin 2006

21 Etude de cas : Corpus XML
Documents XML (http ://eric.univ-lyon2.fr/rbenmessaoud/ ?page=donnees&section=3) EDA, Versailles 19 juin 2006

22 Etude de cas : Modèle Conceptuel des besoins
Cas des ”Régions suspectées” EDA, Versailles 19 juin 2006

23 Étude de cas : arbres d’attributs
- Arbre d’attributs associé au MCM des ”Régions suspectes”. - Arbre d’attributs des documents XML en entrée EDA, Versailles 19 juin 2006

24 Etude de cas : Modèle logique du cube XML
.Schéma XML du cube “Régions susupectes” : <?xml version=”1.0” encoding=”UTF-8” ?> <xs:schema xmlns=” <xs:element name=”Suspicious region”> <xs:complexType> <xs:sequence> <xs:element name=”Patient” type=”Patient Type” /> <xs:element name=”Lesion Type” type=”Lesion Type” /> <xs:element name=”Subtlety” type=”Subtlety Type” /> <xs:element name=”Pathology” type=”Pathology Type” /> <xs:element name=”Date of study” type=”Date Type” /> <xs:element name=”Date of digitization” type=”Date Type” /> <xs:element name=”Digitizer” type=”Digitizer Type” /> <xs:element name=”Scanner image” type=”Scanner Type” /> </xs:sequence> <xs:attribute name=”Region length” type=”xs:integer” /> <xs:attribute name=”Number of regions” type=”xs:integer” /> </xs:complexType> </xs:element> <xs:complexType name=”Patient Type”> <xs:element name=”Age class”> <xs:attribute name=”Age class name” type=”xs:string”/> EDA, Versailles 19 juin 2006

25 Etude de cas : Modèle logique du cube XML
….. <xs:complexType name=”Lesion Type Type”> <xs:sequence> <xs:element name=”Lesion category”> <xs:complexType> <xs:attribute name=”Lesion category name” type=”xs:string”/> </xs:complexType> </xs:element> </xs:sequence> <xs:attribute name=”Lesion type name” type=”xs:string”/> <xs:complexType name=”Subtlety Type”> <xs:attribute name=”Subtlety code” type=”xs:integer”/> <xs:complexType name=”Pathology Type”> <xs:attribute name=”Pathology name” type=”xs:string”/> <xs:complexType name=”Digitizer Type”> <xs:attribute name=”Digitizer name” type=”xs:string”/> <xs:complexType name=”Scanner Type”> <xs:attribute name=”Scanner file name” type=”xs:string”/> EDA, Versailles 19 juin 2006

26 Etude de cas : Modèle logique du cube XML
.Schéma XML du cube “Régions susupectes” : <xs:complexType name=”Date Type”> <xs:sequence> <xs:element name=”Day”> <xs:complexType> <xs:element name=”Month”> <xs:element name=”Year”> <xs:attribute name=”Year name” type=”xs:integer”/> </xs:complexType> </xs:element> </xs:sequence> <xs:attribute name=”Month name” type=”xs:string”/> <xs:attribute name=”Day name” type=”xs:string”/> <xs:attribute name=”Date” type=”xs:date”/> </xs:schema> EDA, Versailles 19 juin 2006

27 Conclusion et perspectives
 méthodologie basée sur le formalisme XML pour entreposer des données complexes. Exprimer un niveau d’abstraction intéressant pour préparer les données à l’analyse. Alimenter une structure multidimensionnelle à l’aide de documents XML. Une formalisation des schémas en étoile ou en flocons de neige en XML. ( utilisation des arbre d’attributs, Golfarelli et al., 2001a,b) Finalement à travers cette étude de cas nous avons validé notre approche X-Warehousing. Cette dernière permet de concevoir des entrepôts XML (ou des magasins XML) et de les alimenter avec des données complexes contenues dans des documents XML ; et cela conformément aux besoins d’analyses d’un utilisateur définis dans un MCM. Par conséquent XML peut être considéré comme une description logique d’un entrepôt de données complexes. Une application Java qui produit un modèle logique et un modèle physique pour un cube composé de documents XML homogènes Une étude de cas sur les régions suspectes sur des mammographies a montré l’intérêt de notre approche sur des applications réelles EDA, Versailles 19 juin 2006

28 Conclusion et perspectives
Interrogation du cube XML : une extension du langage XQuery est nécessaire pour permettre de réaliser l’opération du Group-by. Mesures non numériques : recours à des opérateurs appropriés. L’exemple de l’opérateur OpAC ( Ben Messaoud et al., 2004), Une étude de performance des requêtes OLAP dans le cadre de cube XML Problème de mise à jour du cube XML lors des changements dans les données sources ou des besoins d’analyse de l’utilisateur Modèle physique du cube XML EDA, Versailles 19 juin 2006