dans des entrepôts de données XML - CoDE - Université Libre de ...

More documents

Recommendations

Info

CHAPITRE 5. SCHÉMA XML CANONIQUE POUR UN PROCESSUS ETL 29 de la destination en vue d’extraire non pas l’arborescence du schéma XSD comme telle mais celle du type de document qu’il définit. Arrêtons-nous un instant sur cette problématique et regardons dans la section suivante, d’où proviendrait le problème. 5.2 Difficulté d’extraire une structure définie dans un schéma Un schéma XSD étant un fichier XML, on peut l’écrire de plusieurs manières. A chaque présentation du schéma, correspond une arborescence différente mais l’arbre défini lui-même garde la même structure. Le XML schema du listing 2.3 (p. 2.3) par exemple, pourrait encore s’écrire comme dans le listing 5.2. Listing 5.2 – Autre façon d’écrire le schéma du listing 2.3 < xs:schema xmlns:xs =" http: // www .w3.org /2001/ XMLSchema "> < xs:element name =" personslist "> < xs:complexType > < xs:element name =" person " type =" personType "/> < xs:complexType name =" personType "> < xs:element name =" firstname " type =" xs:string "/> < xs:element name =" middlename " type =" xs:string "/> < xs:element name =" lastname " type =" xs:string " use =" require "/> < xs:attribute name =" birthdate " type =" xs:date "/> Dans le code du listing 5.2, l’élément person est déclaré directement à l’intérieur de la définition de l’élément personslist. Le fait de déclarer person avec un attribut type=”personType” permet de donner sa définition à l’extérieur (dans un xs :complexType). Remarquez que ce même schéma peut encore s’écrire comme dans le listing 5.3. Listing 5.3 – Encore une autre manière d’écrire le schéma du listing 2.3 < xs:schema xmlns:xs =" http: // www .w3.org /2001/ XMLSchema "> < xs:element name =" personslist "> < xs:complexType > < xs:element name =" person "> < xs:complexType > < xs:element name =" firstname " type =" xs:string "/> < xs:element name =" middlename " type =" xs:string "/> < xs:element name =" lastname " type =" xs:string " use =" require "/> < xs:attribute name =" birthdate " type =" xs:date "/>
CHAPITRE 5. SCHÉMA XML CANONIQUE POUR UN PROCESSUS ETL 30 Dans la méthode du listing 5.3, les éléments fils sont toujours définis à l’intérieur de la déclaration de l’élément père. Si nous devrions dessiner les arbres des schémas des listings 2.3, 5.2 et 5.3, nous verrions sans doute que les branches ont des structures différentes. Et pourtant, ils définissent exactement le même type de document. En parcourant l’arborescence du schéma pour extraire le type de document qui y est défini, on se rend compte que la définition des éléments fils peut être dans les sous-arbres descendants de la branche courante ou carrément dans une autre branche (de l’arbre du schéma). D’où la difficulté de trouver la définition des éléments fils et des attributs éventuels dans un parcours automatique. Une question qui nous revient à l’esprit est de savoir si toutes ces méthodes d’écriture des schémas sont adaptées pour les entrepôts de données. Si dans un entrepôt de données (XML) on évite la répétition inutile des informations, pourquoi ne pas avoir la même exigence dans la définition des schémas ? 5.3 Eviter les redondances dans les schémas Comme nous venons de le voir au paragraphe 5.2, un schéma peut s’écrire de plusieurs methodes. Malheureusement, il arrive que dans certains cas, on trouve des parties entières de code qui se répètent. Considérons le schéma du listing 2.3, si nous voulons définir une liste de personnes subdivisée en une sous-liste de femmes et une sous-liste d’hommes, la méthode utilisée dans le listing 5.3 risque de produire des redondances parce que chacune des deux sous-listes pourra contenir la définition des mêmes informations définissant les identités d’une personne (firstname,name, ...). Ce qui donnerait le code du listing 5.4, par exemple. Listing 5.4 – Illustration des redondances dans un XSD < xs:schema xmlns:xs =" http: // www .w3.org /2001/ XMLSchema "> < xs:element name =" personslist "> < xs:complexType > < xs:element name =" menlist "> < xs:complexType > < xs:element name =" man "> < xs:complexType > < xs:element name =" firstname " type =" xs:string "/> < xs:element name =" middlename " type =" xs:string "/> < xs:element name =" lastname " type =" xs:string " use =" require "/> < xs:attribute name =" birthdate " type =" xs:date "/> < xs:element name =" womenlist "> < xs:complexType > < xs:element name =" woman "> < xs:complexType >
Page 1 and 2: Faculté Polytechnique de Mons John
Page 3 and 4: Table des matières 1 Introduction
Page 5 and 6: TABLE DES MATIÈRES 4 7 Réalisatio
Page 7 and 8: Listings 2.1 Exemple d’un documen
Page 9 and 10: Chapitre 1 Introduction Ce chapitre
Page 11 and 12: CHAPITRE 1. INTRODUCTION 10 etc. SG
Page 13 and 14: Chapitre 2 XML en bref Vous trouver
Page 15 and 16: CHAPITRE 2. XML EN BREF 14 2.2 Type
Page 17 and 18: CHAPITRE 2. XML EN BREF 16 choisira
Page 19 and 20: CHAPITRE 2. XML EN BREF 18 (Documen
Page 21 and 22: CHAPITRE 3. LES ENTREPÔTS DE DONN
Page 23 and 24: CHAPITRE 3. LES ENTREPÔTS DE DONN
Page 25 and 26: Chapitre 4 ETL : État de l’art D
Page 27 and 28: CHAPITRE 4. ETL : ÉTAT DE L’ART
Page 29: Chapitre 5 Schéma XML canonique po
Page 33 and 34: CHAPITRE 5. SCHÉMA XML CANONIQUE P
Page 35 and 36: CHAPITRE 5. SCHÉMA XML CANONIQUE P
Page 37 and 38: CHAPITRE 6. GÉNÉRATEUR AUTOMATIQU
Page 45 and 46: Chapitre 7 Réalisation de l’ETL
Page 47 and 48: CHAPITRE 7. RÉALISATION DE L’ETL
Page 53 and 54: CHAPITRE 8. EXEMPLE D’APPLICATION
Page 59 and 60: Chapitre 9 Conclusions et perspecti
Page 61 and 62: Bibliographie [1] Serge Abiteboul.
Page 63 and 64: ANNEXE A. CODE PHP5 DU PROTOTYPE ET
Page 65 and 66: ANNEXE A. CODE PHP5 DU PROTOTYPE ET
Page 67 and 68: ANNEXE B. CODE SOURCE DE LA CLASSE
Page 81:
ANNEXE B. CODE SOURCE DE LA CLASSE
show all

dans des entrepôts de données XML - CoDE - Université Libre de ...

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?