Faculté Polytechnique de Mons. Le processus d Extraction, Transformation et Load (ETL) dans des entrepôts de données XML

Faculté Polytechnique de Mons Johnny TSHEKE SHELE Le processus d Extraction, Transformation et Load (ETL) dans des entrepôts de données XML Travail de fin d études présenté en vue de l obtention du grade d Ingénieur Civil en Informatique et Gestion Année académique 2006-2007 Promoteurs: Prof. Pierre Manneback (FPMs) et Prof. Esteban Zimányi (ULB)

1 à Brian

Table des matières 1 Introduction 8 1.1 Description du sujet................................ 8 1.2 Autres intérêts de l ETL de données XML.................... 8 1.3 Structure de ce document............................. 10 2 XML en bref 12 2.1 XML : Rappel................................... 12 2.1.1 Quelques règles élémentaires en XML.................. 12 2.1.2 Syntaxe d un document XML....................... 13 2.1.3 Déclaration d un document XML..................... 13 2.1.4 Exemple d un document XML...................... 13 2.2 Types et schémas des documents en XML.................... 14 2.2.1 Document Type Definition - DTD.................... 14 2.2.2 XML Schema................................ 14 2.3 Document XML bien formé et valide....................... 15 2.3.1 Document bien formé........................... 15 2.3.2 Document valide.............................. 15 2.4 Arborescence d un document XML - DOM................... 15 2.5 Parcours d un arbre XML............................. 16 2.6 Remarque importante sur l utilisation de l API DOM.............. 16 2.7 Transformation d un document XML - XSLT.................. 17 3 Les entrepôts de données XML 19 3.1 Base de données XML............................... 19 3.2 Stockage des données XML............................ 19 3.3 Classification des bases de données XML..................... 19 3.3.1 Base de données avec support XML................... 19 3.3.2 Base de données XML Native....................... 20 3.4 Entrepôt de données................................ 20 3.4.1 Source des données de l entrepôt..................... 20 3.4.2 Structure de données d un entrepôt de données............. 20 3.4.3 Interrogation de l entrepôt de données.................. 20 3.5 Entrepôt de données XML............................. 21 3.6 Entrepôt de données XML et échange d informations.............. 22 3.7 Entrepôt de données vs entrepôt de données XML............... 22 2

TABLE DES MATIÈRES 3 4 ETL : État de l art 24 4.1 Exécution parallèle................................. 24 4.1.1 Un gros fichier source........................... 24 4.1.2 Pipeline................................... 24 4.1.3 Plusieurs sources.............................. 25 4.2 Evolution avec le temps.............................. 25 4.3 Compatibilité avec les systèmes d exploitation.................. 25 4.4 ETL spatial..................................... 25 4.5 Quelques logiciels ETL............................... 26 4.5.1 ETLs propriétaires............................. 26 4.5.2 ETLs open source............................. 27 5 Schéma XML canonique pour un processus ETL 28 5.1 Motivations..................................... 28 5.2 Difficulté d extraire une structure définie dans un schéma........... 29 5.3 Eviter les redondances dans les schémas..................... 30 5.4 Règles génerales d écriture d un XSD....................... 31 5.4.1 Un élément de type simple........................ 31 5.4.2 Un élément de type complexe....................... 32 5.5 Règles canoniques................................. 33 5.6 Comment parcourir un schéma canonique.................... 34 6 Générateur automatique de fichier XSLT 35 6.1 XPath........................................ 35 6.2 XQuery....................................... 35 6.2.1 Ouverture des fichiers........................... 36 6.2.2 Expressions FLWOR............................ 36 6.3 XSLT........................................ 36 6.3.1 Déclaration d un document XSLT.................... 36 6.3.2 Quelques notions de base......................... 36 6.4 Pourquoi XSLT et pas XQuery?......................... 37 6.5 Comment générer un fichier XSLT automatiquement.............. 38 6.5.1 Programme principal............................ 38 6.5.2 Code XSLT selon la transformation demandée............. 39 6.5.3 Transformation des attributs de l élément courant........... 40 6.5.4 Comment trouver l élément ou l attribut correspondant?........ 40 6.6 Autres opérations possibles............................ 41 6.6.1 Opérateur de fusion............................ 42 6.6.2 Opérateur de séparation.......................... 42 6.6.3 Opérateur de transformation d un élément en attribut......... 42 6.6.4 Opérateur de vérification de compatibilité................ 42 6.6.5 Opérateurs arithmétiques......................... 42 6.6.6 Opérateur de manipulation des instructions de traitement....... 43 6.6.7 Opérateurs d exécution paralèlle d un processus ETL.......... 43

TABLE DES MATIÈRES 4 7 Réalisation de l ETL 44 7.1 Quelques algorithmes du processus ETL des données XML........... 44 7.1.1 Vérifier si un type est prédéfini en XSD................. 44 7.1.2 Vérifier si un tag de XSD définit un élément............... 45 7.1.3 Vérifier si un tag de XSD définit un attribut.............. 45 7.1.4 Extraction du nom d un élément, attribut ou type défini........ 45 7.1.5 Extraction du type de l élément ou de l attribut défini......... 46 7.1.6 Traitement d un élément et de ses fils directs.............. 46 7.1.7 Chargement des schémas......................... 47 7.1.8 Extraction des éléments et attributs définis dans un XSD....... 47 7.1.9 Parsing d un noeud et de ses fils éventuels................ 48 7.1.10 Parsing de la structure définie dans un fichier XSD........... 49 7.1.11 Création de l interface des correspondances............... 49 7.1.12 Compilation d un processus ETL..................... 49 7.2 Prototype ETL développé............................. 50 8 Exemple d application 51 8.1 Chargement des fichiers dans l ETL....................... 51 8.2 Visualisation des schémas chargés......................... 53 8.3 Un choix de correspondances........................... 53 8.4 Un autre choix de correspondances........................ 55 9 Conclusions et perspectives 58 9.1 Conclusions..................................... 58 9.2 Perspectives..................................... 59 Bibliographie 60 A Code PHP5 du prototype ETL développé 61 A.1 Fichier index.php.................................. 61 A.2 Fichier viewsrc.php................................. 63 A.3 Fichier viewdst.php................................. 63 A.4 Fichier mapping.php................................ 64 B Code source de la classe XmlTransform 65

Table des figures 1.1 Le processus ETL dans un entrepôt de données XML.............. 9 1.2 Exportation/importation de données d un SGBD à un autre.......... 10 1.3 Transformation d un document GML en SVG.................. 10 2.1 Exemple d une arborescence XML........................ 16 2.2 Parcours d un arbre XML............................. 17 2.3 Illustration des noeuds réellement obtenus avec l API DOM.......... 18 3.1 Exemple de l entrepôt de données d Arizona State University [14]....... 21 3.2 Exemple d un entrepôt de données XML : DAWAX [3]............. 22 6.1 Interface des correspondances........................... 41 8.1 Page d accueil de XML ETL............................ 52 8.2 Visualisation des arborescences définies dans les schémas............ 53 8.3 Un choix d une transformation.......................... 54 8.4 Un autre choix de transformation......................... 57 5

Listings 2.1 Exemple d un document XML........................... 13 2.2 Exemple d une DTD................................ 14 2.3 Exemple d un XML Schema -XSD........................ 15 5.1 Visualisation de la structure définie dans le listing 2.3............. 28 5.2 Autre façon d écrire le schéma du listing 2.3................... 29 5.3 Encore une autre manière d écrire le schéma du listing 2.3........... 29 5.4 Illustration des redondances dans un XSD.................... 30 5.5 Exemple de définition d un élément de type complexe............. 33 5.6 Exemple d un schéma canonique......................... 33 6.1 La fonction qui génère le fichier XSLT...................... 38 6.2 Production du code XSLT selon le type de transformation choisie....... 39 6.3 Production du code XSLT pour transformer les attributs de l élément courant 40 7.1 Algorithme testant si un type est prédéfini.................... 44 7.2 Algorithme testant si un tag XSD définit un élément.............. 45 7.3 Algorithme testant si un tag XSD définit un attribut.............. 45 7.4 Algorithme d extraction du nom de l élément/attribut/type complexe défini. 45 7.5 Extraction du type de l élément ou attribut défini................ 46 7.6 Traitement de l élément défini et de ses fils................... 46 7.7 Traitement de l élément défini et de ses fils................... 47 7.8 Parsing d une branche d un arbre défini dans un XSD............. 48 7.9 Parsing d une structure définie dans un fichier XSD............... 49 7.10 Compilation d un processus ETL......................... 50 8.1 Schema XSD d une source............................. 51 8.2 Données XML d une source............................ 52 8.3 XSLT généré suite aux choix du paragraphe 8.3................. 53 8.4 Résultat du processus ETL du paragraphe 8.3 sur les données du listing 8.2. 55 8.5 Schéma de destination du processus ETL du paragraphe 8.4.......... 55 8.6 XSLT généré suite aux choix du paragraphe 8.4................. 56 8.7 Résultats de l ETL éxécuté au paragraphe 8.4.................. 56 A.1 Fichier Index.php.................................. 61 A.2 Fichier viewsrc.php................................. 63 A.3 Fichier viewdst.php................................. 63 A.4 Fichier mapping.php................................ 64 B.1 Fichier xmletl2.php................................. 65 6

Remerciements J aimerais tout d abord remercier mes promoteurs Pierre Manneback et Esteban Zimányi, tous les deux professeurs, respectivement, à la Faculté Polytechnique de Mons (FPMs) et à l Université Libre de Bruxelles (ULB). Leurs encouragements, conseils, suggestions, relectures et corrections ont vraiment été une aide précieuse pour la réalisation du présent mémoire. Je remercie également monsieur le professeur Philippe Fortemps, président de la section Informatique et Gestion, de m avoir suggéré monsieur Manneback pour superviser ce travail proposé par monsieur Zimànyi. J aimerais exprimer toute ma gratitute à ma famille et plus particulièrement à Jeannine et à Brian. Que cette oeuvre soit pour eux, le fruit des sacrifices qu ils ont consenti pour me soutenir durant ces études qui s achevent. Pour finir, je tiens à remercier tous mes collegues, amis et connaissances qui m ont soutenu et aidé d une manière ou d une autre pour la réalisation de ce travail. Parmi eux, je peux citer monsieur Marc Okoko pour la relecture et les corrections ainsi que les membres du laboratoire Informatique et Réseaux de l école polytechnique de l ULB. 7

Chapitre 1 Introduction Ce chapitre positionne le sujet dans son contexte. Il montre d une manière non exhaustive, quelques domaines confrontés aux problèmes pouvant être résolus par l outil que nous proposons. 1.1 Description du sujet Les entrepôts de données 1 constituent de nos jours l infrastructure de base des systèmes d aide à la décision. Ils permettent de garder des grands volumes d informations historiques permettant ainsi de découvrir des tendances et des informations similaires qui sont indispensables aux organisations. Les entrepôts de données obtiennent leurs informations des bases de données opérationnelles, c est-à-dire, des bases de données qui supportent les opérations journalières des organisations. Pour amener ces informations à l entrepôt, un processus communément appelé Extraction, Transformation et Load (ETL) est nécessaire. Celui-ci extrait les informations des systèmes opérationnels divers, les transforme de telle sorte qu elles puissent respecter aussi bien les règles que les formats de l entrepôt et les charge finalement dans ce dernier. Actuellement, le processus de ETL ainsi que les outils logiciels qui facilitent ce processus travaillent sur des bases de données relationnelles. Le but du mémoire est la définition d un processus ETL (voir la figure 1.1) et le développement d un prototype d outil associé qui permet d interroger des sources de données XML en vue d alimenter un entrepôt de données également en XML. 1.2 Autres intérêts de l ETL de données XML En dehors des entrepôts de données, le besoin de l ETL de données XML peut se faire sentir dans plusieurs domaines dont Exportation/Importation de données : Lorsqu on exporte les informations d une base de données (BD) à une autre (voir la figure 1.2), on est souvent confronté à plusieurs problèmes tels que : la différence des schémas ; 1 Data Warehouses 8

CHAPITRE 1. INTRODUCTION 9 XML Source 2 (Schema 2) XML Source 1 (Schema 1) ETL XML Source X (Schema X) XML Data Warehouse (Schema of DW) Fig. 1.1 Le processus ETL dans un entrepôt de données XML le Système de Gestion de Base de Données (SGBD) source n est pas toujours le même que celui de destination ; le type ou le format de données peut être différent. Exemple : d un côté une date est codée dans une chaîne de caractères (05-07-2007) de l autre, on code la date sur 3 nombres entiers (jours, mois, année) ; etc. Dans les bases de données relationnelles par exemple, il faut connaître la structure des tables pour bien écrire les requêtes permettant d extraire les informations. Si pour une raison ou une autre, le schéma de la base de données ou les formats des informations désirées change, il faut modifier ou adapter une à une les requêtes utilisées. Comme la plupart des SGBD actuels sont dotés d un outil permettant d exporter/importer les données en XML, un outil ETL pourrait se charger du passage automatique d un schéma/format à un autre. Ce qui permettrait une automatisation de l ensemble du processus. Traitement de données géographiques : Le langage GML (Geography Markup Language) permet d encoder des informations géographiques. Malheureusement, pour visualiser ces données de manière graphique (cartes,...), on a souvent besoin de les mettre sous un autre format comme SVG (Scalable Vector Graphics), X3D (extensible 3D) 2, etc. Ces langages (GML, SVG, X3D) utilisant le formalisme XML, on effectue souvent cette transformation au moyen d un fichier XSLT qu il faut écrire soi-même. 2 X3D est un format de fichier graphique et multimédia orienté 3D. Il peut être exprimé à l aide d une syntaxe basée sur XML [16]. Voir http ://www.web3d.org pour plus d informations sur X3D

CHAPITRE 1. INTRODUCTION 10 SGBD1 SGBD2 XML source ETL XML Destination Fig. 1.2 Exportation/importation de données d un SGBD à un autre GML source ETL SVG Destination Fig. 1.3 Transformation d un document GML en SVG etc. D un fichier de type XML vers un autre fichier de type XML, on peut utiliser un outil ETL qui aura comme source, le document GML et pour destination, un document SVG ou X3D (voir la figure 1.3). 1.3 Structure de ce document Outre ce premier chapitre introductif, le présent ouvrage est structuré de la manière suivante. Un survol du langage XML sera donné au chapitre 2, Le chapitre 3 introduira ensuite, les entrepôts de données XML. L état de l art du processus ETL sera donné au chapitre 4. Au chapitre 5, nous expliquons une façon d écrire un schéma XML (XML Schema) pour simplifier le parcours de son arborescence dans le cadre d un processus ETL. La conception d un générateur automatique de fichier XSLT à partir des schémas XML source et destination sera abordée au chapitre 6. Le chapitre 7 couvrira la réalisation d un processus ETL à partir d un fichier XSLT généré au chaipitre 6. Une illustration du prototype ETL développé sera donnée au chapitre 8 sous forme d un

CHAPITRE 1. INTRODUCTION 11 exemple d application. Au chapitre 9, nous tirerons des conclusions et proposerons quelques pistes de recherche pour le futur. Compte tenu de la limitation du nombre 3 de pages dans un travail de fin d études imposée par la faculté, le présent ouvrage est rédigé de manière à se focaliser essentiellement sur le processus ETL que nous proposons. 3 +/- 50 pages

Chapitre 2 XML en bref Vous trouverez dans ce chapitre, un petit rappel sur le XML. Le but n est pas de nous étendre sur ce sujet très vaste et que nous supposerons connu mais, de rappeler quelques notions fondamentales nécessaires à la compréhension de la suite du présent travail. 2.1 XML : Rappel XML (extended Markup Language) est un langage de balisage extensible, un langage du style HTML, un descendant de SGML (Standard Generalized Markup Language) un langage qui définit un cadre de représentation générique de données (semi-)structurées [19], une famille de technologies qui peut tout faire depuis le formatage de document jusqu au filtrage de données [13], un ensemble de règles permettant de créer ses propres balises [13] et qui facile l échange automatisé des informations entre systèmes (d informations) hétérogènes (sur Internet). 2.1.1 Quelques règles élémentaires en XML Un document XML est essentiellement composé de tags 1. Ces derniers forment les éléments. Exemple d un tag ouvrant : <person>. Le tag fermant correspondant est </person>. Un élément est constitué d un tag ouvrant, du tag fermant correspondant et d un contenu éventuel. Le contenu d un élément peut être d autres éléments, de données ou du texte [9]. Dans ce cas, une balise fermante est obligatoire. Exemple <person>brian</person>. Lorsqu un élément est vide (c est-à-dire, n a pas de contenu), on peut l écrire sous la forme d une annotation d ouverture et d une de fermeture (exemple : <person></person>) ou sous la forme contractée (exemple : <person/>). En XML, les Tags (annotations) respectent les règles suivantes [9, 13] sensibilité à la casse. C est-à-dire que les majuscules sont différenciées des minuscules. Le tag <person> est différent de <Person>, lui-même différent de <PERSON>, etc. 1 annotations ou balises 12

CHAPITRE 2. XML EN BREF 13 Le premier caractère du nom d un tag doit être une lettre ou un soulignement ( ) Le caractère blanc n est pas permis au début du tag mais à la fin. Le nom peut être composé des caractères alphanumériques,-,.,_. 2.1.2 Syntaxe d un document XML Un document XML doit respecter les règles suivantes. Avoir un et un seul élément racine (Root Element). Cet élement est aussi appelé Document element [9]. C est l élement qui contient tout le contenu du document. Les annotations d ouverture et de fermeture doivent se correspondre [9, 19]. Si un tag est ouvert à l intérieur d un élement, il doit être fermé à l intérieur de ce même élément. Tout tag doit être fermé comme il faut (<person>...</person> ou <person/>). Les attributs sont des propriétés contenues dans l annotation d ouverture. Dans un tag, deux attributs ne peuvent pas porter un même nom [9, 13]. Il y a une valeur unique par attribut. Un élément peut avoir plusieurs attributs [13]. 2.1.3 Déclaration d un document XML Un document XML est un fichier text dont la première ligne, appelée Déclaration XML (XML Declaration) [9] est de la forme <?xml version="1.0"?> où version précise le standard XML utilisé dans le document. On peut également spécifier le codage des caractères avec l attribut encoding pour permettre une lecture correcte du document [13]. A ce qui concerne les langues de l europe occidentale, on écrira : <?xml version="1.0"encoding="iso-8859-1"?> 2.1.4 Exemple d un document XML Listing 2.1 Exemple d un document XML <? xml version =" 1.0 " encoding ="ISO -8859-1 "?> < personslist > <person > < firstname >Johnny </ firstname > < middlename >Shele </ middlename > < lastname >Tsheke </ lastname > </ person > <person > < firstname >Pierre </ firstname > < middlename /> < lastname > Manneback </ lastname > </ person > <person > < firstname > Esteban </ firstname > < middlename > Borrageiros </ middlename > < lastname > Zimanyi </ lastname > </ person > </ personslist >

CHAPITRE 2. XML EN BREF 14 2.2 Types et schémas des documents en XML XML permet de créer ses propres balises et de définir un modèle (une structure) auquel les documents doivent se conformer. On peut créer un modèle de document XML par Document Type Definition (DTD) ou par XML schema. 2.2.1 Document Type Definition - DTD Une DTD est un modèle qui représente une classe de document [10] ou qui décrit les exigences structurales d un document XML [9]. Il peut définir : les éléments et attributs éventuels, les éléments fils, leurs nombres et l ordre dans lequel ils peuvent apparaître, les valeurs possibles et éventuellement, par défaut prises par les éléments et/ou les attributs, etc. Pour le document XML du listing 2.1, une DTD correspondant pourrait être celui du listing 2.2 Listing 2.2 Exemple d une DTD <? xml version ="1.0" encoding =" UTF -8"? > <! ELEMENT personslist ( person +) > <! ELEMENT person ( firstname, middlename, lastname ) > <! ATTLIST person birthdate CDATA # IMPLIED > <! ELEMENT firstname (# PCDATA ) > <! ELEMENT middlename (# PCDATA ) > <! ELEMENT lastname (# PCDATA ) > Le lecteur intéressé par les DTDs pourrait consulter [9, 10, 13] où il trouvera plus de détails. 2.2.2 XML Schema XML Schema est une alternative aux DTDs, basée sur XML [13,15]. Il définit un modèle de contenu pour une classe de documents XML et présente plusieurs avantages par rapport aux DTDs : il est écrit en XML [4, 9, 13, 15], il permet de spécifier le type de données [4, 15], il est extensible, il supporte les espaces de noms, etc. On parle de XML Schema Definition (XSD) pour désigner la grammaire de XML Schema. Devenu une recommandation 2 du W3C depuis le 2 Mai 2001 et étant plus riche et plus puissant, on admet actuellement que XML Schema sera le successeur des DTDs [15]. C est pour cette raison que nous n utiliserons pas de DTD dans le cadre de ce travail de fin d études. Nous ne considérerons que les schémas donnés en XML schema. Le lecteur trouvera quelques règles d écriture des schémas XSD au chaiptre 5, p.28. Dans l immédiat nous nous contentons de donner dans le listing 2.3, un exemple d un XML Schema qui peut définir le document XML du listing 2.1. 2 XML Schema est un standard W3C

CHAPITRE 2. XML EN BREF 15 Listing 2.3 Exemple d un XML Schema -XSD <? xml version =" 1.0 " encoding ="ISO -8859-1 "?> <! -- Une liste de personnes -- > < xs:schema xmlns:xs =" http: // www.w3.org /2001/ XMLSchema "> < xs:element name =" personslist " type =" personslisttype "/> < xs: complextype name =" personslisttype " > < xs:element name =" person " type =" persontype "/> </ xs: complextype > < 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 "/> </ xs: complextype > </ xs:schema > 2.3 Document XML bien formé et valide 2.3.1 Document bien formé Un document XML est dit bien formé 3 s il est syntaxiquement correct [1, 2, 9, 15, 19] ; c est-à-dire qu il respecte les règles énoncées au paragraphe 2.1.2 (p. 13). Il est exigé que tout document XML à traiter soit bien formé. 2.3.2 Document valide Un document XML sera dit valide s il est bien formé et conforme à la DTD ou au schéma XML (XML schema) qui définit sa structure. Cette condition est capitale dans la conception et l implémentation de l ETL parce qu il faut veuiller à ce que les informations importées dans l entrepôt de données XML soient stockées en conformité avec les exigences du schéma de ce dernier. Dans la suite du présent travail, nous supposerons que le document XML de données est valide à la source (Base de données opérationnelle). 2.4 Arborescence d un document XML - DOM Les deux API (Application Programming Interface) les plus utilisées pour accéder aux données et aux structures des documents XML sont le DOM (Document Object Model) et le SAX (Simple API for XML). Dans ce travail, nous utiliserons le DOM qui présente un document XML dans une structure arborescente où les éléments, les attributs et les textes sont définis comme des noeuds [15]. Cette structure est facile à manipuler et offre une certaine aisance à accéder à n importe quelle partie du document. Ceci nous sera particulièrement important pour l implémentation de l interface graphique 4 à partir de laquelle l utilisateur 3 En Anglais, on dit Well formed 4 Le fichier XSLT sera généré en fonction des choix faits sur cette interface

CHAPITRE 2. XML EN BREF 16 choisira les types d informations à importer dans l entrepôt de données. Nous n avons pas l intention de nous attarder sur le DOM. Nous voulons tout simplement donner à la figure 2.1 une illustration de l arborescence correspondant au document XML du listing 2.1 (p. 13) (Root Element) personslist (Element) person (Element) person (Element) person (Element) firstname (Element) middlename (Element) lastname (Element) firstname (Element) middlename (Element) lastname (Element) firstname (Element) middlename (Element) lastname (Text) Johnny (Text) Shele (Text) Tsheke (Text) Pierre (Text) Manneback (Text) Esteban (Text) Borrageiros (Text) Zimanyi Fig. 2.1 Exemple d une arborescence XML 2.5 Parcours d un arbre XML Dans un arbre de représentation d un document XML [15] : Le noeud supérieur (le premier noeud) est appelé Racine (Root), Un noeud ascendant est appelé parent, Un noeud descendant est appelé enfant (child), A part la racine, chaque noeud a un et un seul parent direct (père), Un noeud peut avoir 0 ou plusieurs enfants, Une feuille est un noeud qui n a pas d enfant, Les noeuds déscendants d un même père (direct) sont dits frères (siblings). A partir d un noeud, on peut parcourir l arbre d une des manières suivantes. En allant vers un descendant (child). Ceci n est pas possible pour une feuille. En allant vers un frère (next, previous) si possible. En remontant vers le noeud père (parent) si on n est pas à la racine. La figure 2.2 illustre le parcours d une partie de l arbre de la figure 2.1. 2.6 Remarque importante sur l utilisation de l API DOM Nous attirons l attention du lecteur et plus précisement du programmeur sur le fait qu indépendamment de la validité du document (voir paragraphe 2.3.2), la manipulation de l arbre XML avec l API DOM retourne (en PHP, JAVA,...) des noeuds Text de part et d autre d un noeud Element. Sauf l élément racine (Root Element) qui apparaît comme un fils du noeud document (Document) [11, 12]. Il sera particulièrement utile de tenir compte de cette réalité lors du processing des schémas XSD en vue de générer un fichier XSLT automatiquement. Pour l arbre de la figure 2.2, on obtiendrait en réalité celui de la figure 2.3. Il faut donc être attentif dans la sélection des

CHAPITRE 2. XML EN BREF 17 (Root Element) personslist firstchild (Element) person (Element) firstname parent (Text) Pierre (Element) person parent children (Element) middlename lastchild (Element) person (Element) lastname parent (Text) Manneback Fig. 2.2 Parcours d un arbre XML noeuds utiles pour éviter des surprises. Les algorithmes proposés dans la suite permettront de résoudre ce problème dans le cadre de l ETL. De manière plus générale, on peut tester le type du noeud présent puis effectuer un traitement approprié. Les personnes confrontées à ce problème pourront consulter [12]. 2.7 Transformation d un document XML - XSLT La transformation est l opération par laquelle on convertit un document XML (source) dans un autre format (destination) : HTML, XML,etc. Le langage de programmation le plus utilisé à cet effet est le XSL Transformation (XSLT). XSL (Extensible Stylesheet Language) est la composition des trois langages : XSLT, XPath qui permet de parcourir l arbre du document et XSL-FO qui permet le formatage. Dans le cadre de cette conception de l ETL de données XML, nous ne nous intéresserons qu à XSLT et XPath dont nous donnerons un petit rappel au chapitre 6. Notre préoccupation est de transformer à l aide de XSLT, un arbre XML valide par rapport au schéma source, en un arbre XML respectant le XSD de l entrepôt de données XML (destination). Les expressions XPath seront utilisées pour naviguer dans le document.

CHAPITRE 2. XML EN BREF 18 (Document) (Root Element) personslist firstchild (Text) (Element) person (Text) (Element) person (Text) (Element) person lastchild (Text) Fig. 2.3 Illustration des noeuds réellement obtenus avec l API DOM

Chapitre 3 Les entrepôts de données XML 3.1 Base de données XML On appelle base de données XML, un logiciel capable de stocker, importer, exporter et rendre accessible les données XML [18]. Le paragraphe 3.2 survole les manières de conserver ces types d informations. 3.2 Stockage des données XML Il y a plusieurs façons de stocker les données XML. Les techniques les plus utilisées sont les suivantes [3]. Dans des fichiers de type text : Les informations sont conservées dans les fichiers XML par exemple. La gestion de ces fichiers peut se faire éventuellement dans des collections structurées elles-mêmes en hierarchie comme dans un système de fichier (Linux, Unix). Dans une base de données traditionnelle : Ici, on extrait les données et on les garde au format du SGBD. On utilisera des tables, par exemple, si on a affaire à une base de données relationnelle. On veuillera à disposer d un modèle de données pour permettre la restitution en XML au moment d extraire les informations. Dans un système hybride : Cette technique fait le mixage des deux approches précédentes. 3.3 Classification des bases de données XML On classifie habituellement les bases de données XML en deux grands groupes : celles avec support XML et celles qu on qualifie de natives. 3.3.1 Base de données avec support XML Dans ce groupe, on trouve les bases de données traditionnelles (relationnelle, objet,...) avec une couche ou interface permettant l importation et/ou l exportation des données en XML, et stockent ces informations au format du SGBD. En se basant sur le modèle DOM où un document XML peut être vu comme un arbre (un objet), on peut stocker ce dernier comme un objet dans une base de données objet. Dans le 19

CHAPITRE 3. LES ENTREPÔTS DE DONNÉES XML 20 même ordre d idées, en définissant une certaine correspondance entre le document XML et certaines tables, on peut enregistrer les données XML dans une BD relationnelle. 3.3.2 Base de données XML Native Dans ce groupe, on définit un modèle logique du document en fonction de XML et on utilise un document XML comme unité fondamentale de stockage. Dans une base de données relationnelle, on a une ligne de table comme unité de stockage. Mais, dans une base de donnée XML Native (Native XML Database - NXD), c est un document XML qui est l unité de stockage [18]. Actuellement il existe plusieurs SGBD XML natifs : exist, Apache XIndice, Tamino,... 3.4 Entrepôt de données Dans une organisation, un entrépôt de données (Data Warehouse) est une base de données intégrant des informations [19] : issues des sources hétérogènes, datées (historisées), non modifiables (lecture seule), et organisées de manière à permettre des analyses statistiques et une exploitation en gestion stratégique. La figure 3.1 illustre l implémentation d un entrepôt de données à l université d état d Arizona aux USA (Arizona State University - ASU ). 3.4.1 Source des données de l entrepôt Les données sont issues des BD opérationnelles qui ont, en général, des schémas différents. La mise à jour ne se fait pas toujours périodiquement mais parfois sporadiquement. Ces données seront agrégées pour éviter les redondances et permettre la facilité d accès et d analyse. 3.4.2 Structure de données d un entrepôt de données Dans un entrepôt de données, les informations sont en géneral représentées dans un modèle de données en étoile ou en cube. 3.4.3 Interrogation de l entrepôt de données Les deux approches les plus utilisées sont R-OLAP (Relational On-Line Analytical Porcessing) : lorsqu on a des requêtes SQL et M-OLAP (Multidimensional On-Line Analytical Porcessing) : si on a un modèle en cube de plusieurs dimensions. De manière plus générale, on parle de OLAP qui englobe aussi d autres approches (H-OLAP 1, S-OLAP 2 et D-OLAP 3 ) 4 1 Hybrid OLAP 2 Spatial OLAP 3 Dynamic ou Desktop OLAP 4 Voir http ://fr.wikipedia.org/wiki/olap

CHAPITRE 3. LES ENTREPÔTS DE DONNÉES XML 21 Fig. 3.1 Exemple de l entrepôt de données d Arizona State University [14] 3.5 Entrepôt de données XML Un entrepôt de données XML est un entrepôt de données capable de accepter des sources de données XML, fournir les données ou document XML en output, supporter les techniques de manipulation habituelle des documents XML (XSLT, XPATH,...) et, agréger les données issues des différentes sources de sorte qu elles soient valides par rapport aux schémas de stockage. La figure FIG.3.2 illustre l entrepôt de données XML proposé dans [3]. Comme nous l avons dit au paragraphe 3.2 (p.19), il y a plusieurs façons de stocker les documents XML. Cette réalité implique une diversité de manières d implémenter un entrepôt de données XML. Dans ce chapitre, le but n est pas d expliquer la conception ou l implémentation d un entrepôt de données XML dans sa globalité mais de donner un aperçu général.

CHAPITRE 3. LES ENTREPÔTS DE DONNÉES XML 22 Fig. 3.2 Exemple d un entrepôt de données XML : DAWAX [3] 3.6 Entrepôt de données XML et échange d informations Un des avantages que peut offrir un entrepôt de données XML est notament la possibilité d échanger les informations par http en intranet ou Internet. Grâce à la technologie XML, on peut utiliser des standards. Ce qui ne nécessite pas d avoir une API propriétaire quelconque. Cette solution est particulièrement intéressante pour une organisation (societé mutinationale, grosse administration,...) répartie sur plusieurs sites ou qui inter-agit avec des sous-traitants par exemple. On notera que la plupart des SGBD actuels prévoient au moins la possibilté d intégrer les données XML. Dans SQL Server 2005, Integration Service [8] par exemple, malgré le stockage des informations dans une base de données relationnelles (SQL Server), on prévoit tout de même la possibilité d importer les données à partir d une source XML. Cette source peut être locale (un fichier) ou distante (accessible par http). Nous verrons plus tard que cette stratégie s intègre parfaitement dans l outil ETL que nous proposons. 3.7 Entrepôt de données vs entrepôt de données XML Dans la table 3.1 nous reprenons une synthèse d éléments distinguant, de manière générale, un Entrepôt de données d un entrepôt de données XML [1]. Rappelons que dans la pratique, la différence est un peu nuancée parce que de nos jours, les systèmes mis réellement en production sont souvent hybrides. c est-à-dire, qu on essaie de combiner les différentes approches pour tirer au mieux les avantages de chacune. Après tout, chacun construit son entrepôt de données (XML) selon ses besoins. Bill Inmon 5 n aurait-il pas dit : Un Data Warehouse ne s achète 5 On le considère généralement comme le père du concept Data Warehouse

CHAPITRE 3. LES ENTREPÔTS DE DONNÉES XML 23 Entrepôt de données Entrpôt de données XML Données Données relationnelles XML Valeurs numériques texte Approvisionnement filtrage filtrage classification, semantique..., Integration et vue relations XML cube Interrogation SQL XQuery, XSLT Exploitation OLAP lecture outils statistiques production des rapports production des rapports Tab. 3.1 Différence entre entrepôt de données et entrepôt de données XML [1] pas, il se construit 6. On peut donc utiliser telle ou telle autre technique pour mieux exploiter les données. 6 http ://fr.wikipedia.org/wiki/entrepôt de données

Chapitre 4 ETL : État de l art Dans ce chapitre, nous survolons l état de l art du processus ETL. Nous examinerons les possibilités offertes actuellement par l évolution technologique. Ceci permettra de mieux comprendre par la suite la contribution qu apporte la technique que nous proposons. 4.1 Exécution parallèle Compte tenu du développement des technologies de l information et de la communication, on est de plus en plus confronté à un volume de données important. Ceci néssecite d adapter les techniques d extraction et/ou de filtrage pour que l outil ETL ne prenne pas trop de temps. Actuellement, on utilise de plus en plus le parallélisme [17]. Ce dernier peut s appliquer lorsqu il faut traiter : un gros fichier source, les données en pipeline ou plusieurs sources de données. 4.1.1 Un gros fichier source Lorsque les données de la source se trouvent dans un fichier séquentiel par exemple, la taille de ce dernier peut avoir un impact non négligeable sur les applications qui doivent le manipuler. Dans le cas d un fichier XML, si on utilise une API DOM, on risque de rencontrer des difficultés en voulant charger l entièreté de l arbre en mémoire. Les bases de données exist par exemple, fonctionnent moins bien lorsque le nombre d entrées devient relativement important. Une solution consiste à découper (split) le fichier en des morceaux de tailles plus facilement manipulables. De cette manière, on peut accéder à plusieurs parties simultanément. 4.1.2 Pipeline La technique de pipeline permet de traiter plusieurs composants d un même fichier simultanément. Pendant que l on fait une opération ou une manipulation sur un élément on peut en même temps faire un autre traitement sur l élément suivant. 24

CHAPITRE 4. ETL : ÉTAT DE L ART 25 4.1.3 Plusieurs sources Lorsqu on est en présence de plusieurs sources (fichiers), on peut envisager de traiter un certain nombre en parallèle. Si un processus est occupé à trier un fichier par exemple, on peut demander à un autre processus de supprimer les doublons d un autre fichier. De cette manière on gagne en temps parce que le traitement du 2e fichier commence plus tôt que si on devait attendre de finir le tri du 1er. Signalons tout de même que le Multi-processing/Multi-threading n est pleinement opérationnel que sur des systèmes multi-processeurs! Heureusement qu aujourd hui la plupart des machines supportant les entrepôts de données sont multiprocesseurs. 4.2 Evolution avec le temps Comme pour les autres logiciels, il est indispensable que l outil ETL puisse évoluer avec le temps. On doit donc pouvoir le mettre à jour facilement et si possible garder la compatibilité avec les versions ou les applications antérieures. On doit par exemple pouvoir se connecter à des nouveaux SGBD capables de fournir des données au format supporté par l ETL. Il faut également pouvoir supporter une mise à jour éventuelle du/des SGBD constituant l entrepôt. Il convient de noter que les bases de données opérationnelles évoluent et qu on pourrait vouloir garder dans l entrepôt des informations auxquelles on n avait pas songé au moment de l implémentation de l entrepôt de données. A titre d exemple, à un moment, on peut vouloir conserver une liste de personnes (clientes) de l étranger. Malheureusement, la structure d adresse est différente de ce qu on a prévu initialement (certains champs en plus ou en moins,...). Il faut que l ETL puisse s adapter très facilement dans ces genres de problèmes. 4.3 Compatibilité avec les systèmes d exploitation A part les ETL incorporés dans les produits Microsoft comme SQL Server Integration Service qui ne fonctionnent essentiellement que sous Windows, la plupart des fabricants essaient de rendre compatibles leurs produits avec un grand nombre de systèmes d exploitation (Windows, Linux/Unix, Mac-OS,...). Notre prototype a été développé en PHP. Ce qui permet de l intégrer facilement dans n importe quel serveur web supportant ce langage. On pourrait utiliser le serveur web Apache 1 que l on peut télécharger gratuitement sur le site http://httpd.apache.org. 4.4 ETL spatial L ETL spatial est poussé par le geographic information system (GIS) pour permettre l interopérabilité entre les divers formats des données géographiques [17]. Malgré le fait que plusieurs fabricants des logiciels ETL commencent à incorporer les spécifications de l ETL spatial, le problème est encore loin d être résolu. Nous pensons tout de même que le noyau de notre ETL pourrait s adapter aux besoins de GIS. En effet, comme nous l avons dit précédemment, plusieurs technologies actuelles supportent l importation et l exportation de données en XML. Le fait que notre ETL effectue 1 Open source

CHAPITRE 4. ETL : ÉTAT DE L ART 26 une transformation de XML vers XML fait qu on peut avoir une interopérabilité en allant séquentiellemment de la manière suivante. exporter les données en XML (à partir de la source), passer les données source XML dans l ETL, obtenir les données destination XML conformes au schéma accepté par le système exploitant les données, importer les données XML dans le système de destination. On obtient ainsi les données dans l autre format. Les figures 1.2 et 1.3 illustrent cette possibilité. 4.5 Quelques logiciels ETL Dans cette section nous présentons quelques principaux logiciels ETL que l on peut trouver actuellement sur le marché. La liste est loin d être exhaustive mais elle donne une idée générale des tendances actuelles. Dans cette liste, nous distinguons les ETLs open source des ETLs propriétaires. Habituellement les prémiers sont téléchargeables gratuitement mais pour les autres, seule une version dévalution peut être téléchargée et installée de manière gratuite. 4.5.1 ETLs propriétaires 4.5.1.1 SQL Server Integration Services Le SQL Server 2005 Integration Services (SSIS) comporte un outil ETL permettant d intégrer les données en provenance des diverses sources hétérogènes 2. Comme SQL server 2005 prend en charge les données XML en mode natif, on peut manipuler ces types d informations. Le problème est que cet outil ETL ne fonctionne que dans un SSIS qui ne peut lui même être installé que sous Windows. Ce qui ne permet pas de l installer dans un autre environnement. 4.5.1.2 Oracle Data Integrator Il s agit d un ETL de Oracle 3 pouvant tourner sur plusieurs systèmes d exploitation. Il peut se connecter sur plusieurs plateformes d entrepôt de données (Teradata, IBM DB, Oracle,...) ainsi qu à des technologies ERP, LDAP, XML, etc. A l origine, ce produit appartenait à la société Sunopsis 4 qui a été rachetée par Oracle en 2006. 4.5.1.3 Oxio Data Integration La société française Oxio (http://www.oxio.fr) développe un ETL 100% web. Cette solution, comme dans notre prototype, a l avantage de ne pas nécessiter des applications clientes. Il suffit de disposer d un navigateur web et d un accès réseau pour pourvoir utiliser l application selon les autorisations accordées. Le fait qu il soit développé en SQL server et.net nous semble limiter les possibilités de son installation sur d autres systèmes d exploitation comme Linux, Mac-Os, etc. 2 voir http://www.microsoft.com/france/sql/sql2005/decouvrez/presentation.mspx 3 voir http://www.oracle.com 4 voir http://www.oracle.com/sunopsis

CHAPITRE 4. ETL : ÉTAT DE L ART 27 4.5.2 ETLs open source 4.5.2.1 Talend open studio Talend Open Studio est un ETL graphique et open source développé en Java/Eclipse. Pour un fichier XML se présentant en entrée, il le lit ligne par ligne pour le scinder en champs et envoie ces derniers tels que définis dans le schéma au composant suivant du job, via un lien Row. L approche peut paraître relativement lente pour l accès aux éléments mais si on tient compte de la lourdeur des applications java, il ne serait peut-être pas optimal d envisager le chargement d un grand-t-arbre XML en mémoire. Le lecteur trouvera plus d informations sur http://www.talend.com. 4.5.2.2 Scriptella Scriptella (http://scriptella.javaforge.com) est un ETL open source développé en java. Il nous a semblé relativement moins approprié pour une production réelle. En effet, il utilise essentiellement le SQL pour les transformations. Ce qui n est pas spécialement adapté pour les données XML. Il faut de toutes les façons aller éditer un fichier XML pour préciser les informations de connexion (host, login,...) et les requêtes éventuelles à exécuter.

Chapitre 5 Schéma XML canonique pour un processus ETL Dans ce chapitre, nous expliquerons comment écrire un schéma XML en vue de simplifier le parcours automatique de son arborescence dans un processus ETL. Avant d y arriver, nous donnerons d abord un petit rappel sur les XSD. 5.1 Motivations Nous voulons permettre à l utilisateur de faire un mapping entre les schémas source et destination. Il nous faut donc lui présenter ces schémas graphiquement sur l écran. Notons également que nous souhaitons une application web la plus légère possible. Tenant compte du fait que les browsers web actuels sont presque tous capables d afficher (faire du Parsing) un fichier XML, une idée serait de passer tout simplement le schéma XSD au navigateur web pour affichage. Afficher un document XSD comme tel pourrait être extrêmement incorfortable pour un utilisateur dépourvu des notions solides de XML schema. Notre stratégie est donc de créer un fichier XML ne contenant que la structure (de l arbre) représenté dans le fichier XSD. Dans le cas du schéma du listing 2.3 (p. 15), nous voulons quelque chose comme ce qui est dans le listing 5.1. Listing 5.1 Visualisation de la structure définie dans le listing 2.3 <? xml version =" 1.0 " encoding ="ISO -8859-1 "?> < personslist > <person birthdate =" xs:date "> < firstname /> < middlename /> < lastname /> </ person > </ personslist > De cette manière l utilisateur voit directement et de façon plus claire l imbrication et la séquence des éléments. Chaque élément porte les attributs éventuels définis dans le fichier XSD. La difficulté c est de pouvoir parcourir automatiquement tout schéma XML d une source ou 28

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 <? xml version =" 1.0 " encoding ="ISO -8859-1 "?> <! -- Schéma d une liste des personnes -- > < xs:schema xmlns:xs =" http: // www.w3.org /2001/ XMLSchema "> < xs:element name =" personslist "> < xs: complextype > < xs:element name =" person " type =" persontype "/> </ xs: complextype > </ xs:element > < 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 "/> </ xs: complextype > </ xs:schema > 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 <? xml version =" 1.0 " encoding ="ISO -8859-1 "?> <! -- Schéma d une liste des personnes -- > < 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 "/> </ xs: complextype > </ xs:element > </ xs: conplextype > </ xs:element > </ xs:schema >

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 <? xml version =" 1.0 " encoding ="ISO -8859-1 "?> <! -- Une liste de personnes -- > < xs:schema xmlns:xs =" http: // www.w3.org /2001/ XMLSchema "> < xs:element name =" personslist "> < xs: complextype > <! -- sous liste d hommes --> < 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: complextype > </ xs:element > </ xs: complextype > </ xs:element > <! -- sous liste de femmes --> < xs:element name =" womenlist "> < xs: complextype > < xs:element name =" woman "> < xs: complextype >

CHAPITRE 5. SCHÉMA XML CANONIQUE POUR UN PROCESSUS ETL 31 < 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: complextype > </ xs:element > </ xs: complextype > </ xs:element > </ xs: complextype > </ xs:element > </ xs:schema > Le schéma du listing 5.4 est plus lourd à manipuler. On voit que les éléments man et woman sont de même type mais la manière dont ils sont définis agrandit inutilement l arbre du schéma. Dans un entrepôt de données XML, on peut faire face à des schémas relativement grands. Il faut donc éviter des répétions inutiles pour ne pas perdre trop de temps dans le traitement de XSD. Nous savons aussi qu une erreur sur le traitement de schéma peut avoir des conséquences sur : l interface utilisateur : l interface permettant de faire le mapping entre le schéma source et destination l extraction des données à la source et le chargement de données à la destination. Il nous faut donc proposer quelques règles claires permettant d écrire un XSD de façon plus appropriée au processus ETL et aux entrepôts de données XML. Voyons d abord, en général, comment écrire un XSD. 5.4 Règles génerales d écriture d un XSD Dans cette section, nous survolons quelques règles d écriture d un XSD. Nous ne reprenons que les points importants dont le rappel nous semble indispensable à la bonne compréhension des règles d écriture d un schéma canonique. Le lecteur trouvera plus d informations dans [4, 15]. Notons d abord que l élément spécial schema (<xs:schema>) est la racine (Root Element) de l arbre XSD. Pour définir les éléments et/ou les attributs on procède de la manière suivante. La définition d un attribut se fait en spécifiant son nom dans l attribut name de l élément attribute (<xs:attribute>). La définition d un élément se fait en spécifiant son nom dans l attribut name de l élément element (<xs:element>). On distingue deux types d éléments : le type simple et le type complexe. 5.4.1 Un élément de type simple Un élément de type simple ne peut contenir ni autre élément, ni attribut. Il ne peut contenir que du texte. L élément firstname défini dans le listing 2.3 (p. 15) par exemple, est de type simple : <xs:element name="firstname" type="xs:string"/> De manière générale, on définit un élément de type simple comme suit.

CHAPITRE 5. SCHÉMA XML CANONIQUE POUR UN PROCESSUS ETL 32 <xs:element name="elemname" type="elemtype"/> où elemname est le nom de l élément que l on veut définir et elemtype un type simple. Parmi les types simples, on peut citer : xs : string une chaîne de caractères xs : decimal une valeur numérique signée ou non signée composée de 18 chiffres tout au plus xs : integer une valeur entière xs : boolean une valeur booléenne qui peut être true (vrai) ou false (faux). Les valeurs 1 et 0 indiquent respectivement true et false. xs : date la date qui doit s encoder au format AAAA-MM-JJ où AAAA est l année, MM le mois et JJ le jour du mois. xs : time l heure au format HH : MM : SS où HH, MM et SS désignent respectivement l heure, les minutes et les secondes. 5.4.2 Un élément de type complexe Un élément de type complexe peut contenir d autres éléments et/ou des attributs. Il y deux façons de définir un élément de type complexe : 1. en définissant les éléments fils et les attributs éventuels à l intérieur de la définition de l élément de type complexe ; 2. en définissant les éléments fils et les attributs éventuels à l extérieur. 5.4.2.1 Définitions des fils à l intérieur La définition des éléments descendants à l intérieur se fait de la manière suivante <xs:element name="elemname"> <xs:complextype> <!--mettre les enfants ici --> </xs:complextype> </xs:element> Les éléments man et woman du listing 5.4 (p.30) par exemple, sont définis selon cette méthode. 5.4.2.2 Définitions des fils à l extérieur Dans cette méthode, on définit un type complexe qui contiendra les fils et les attributs éventuels. Les éléments de type complexe correspondants sont définis en précisant le nom de ce type dans l attribut spécial type. On aura donc les codes suivants dans le fichier XSD. <xs:element name="elemname" type="complextypename"/> <xs:complextype name="complextypename"> <!--mettre les enfants ici --> </xs:complextype> où elemname est le nom de l elément de type complexe que l on définit et complextype- Name, le nom du type complexe. Le listing 5.5 montre un exemple de définition utilisant cette méthode.

CHAPITRE 5. SCHÉMA XML CANONIQUE POUR UN PROCESSUS ETL 33 Listing 5.5 Exemple de définition d un élément de type complexe < xs:element name =" man " 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 "/> </ xs: complextype > 5.5 Règles canoniques Dans cette section, nous présentons quelques règles permettant d écrire un schéma XSD canonique dans le cadre d un processus ETL. Comme nous venons de le voir précédemment, la définition d un élément de type complexe peut avoir un impact important sur le nombre de noeuds de l arbre du schéma. Il nous faut établir quelques règles permettant de définir ce type d éléments sans augmenter inutilement le contenu du fichier XSD. Le schéma obtenu doit également respecter les normes du W3C. Les règles proposées dans le cadre de ce travail sont les suivantes : Seul l élément racine ne peut être défini comme fils direct de l élément schema (<xs:schema>). Tout autre élément ne peut être défini que dans un type complexe. Le nom d un type complexe ne peut en aucun cas avoir pour préfixe, celui défini dans l espace de nom 1 suivi du caractère :. Un élément complexe est toujours défini comme au paragraphe 5.4.2.2 (p.32). Les éléments de type complexe qui ont des définitions identiques doivent se déclarer comme étant de même type complexe. En appliquant ces règles, on évite de gonfler le code inutilement comme dans le listing 5.4. L élement man et woman sont de même type. Il faut définir le type complexe une seule fois. Le listing 5.6 montre un exemple de schéma canonique éliminant les redondances du listing 5.4. Listing 5.6 Exemple d un schéma canonique <? xml version =" 1.0 " encoding ="ISO -8859-1 "?> <! -- Une liste de personnes -- > < xs:schema xmlns:xs =" http: // www.w3.org /2001/ XMLSchema "> < xs:element name =" personslist " type =" personslisttype "/> < xs: complextype name =" personslisttype " > < xs:element name =" menlist " type =" menlisttype "/> < xs:element name =" womenlist " type =" womenlisttype "/> </ xs: complextype > < xs:complextype name =" menlisttype "> < xs:element name =" man " type =" persontype "/> </ xs: complextype > < xs: complextype name =" womenlisttype " > < xs:element name =" woman " type =" persontype "/> </ xs: complextype > 1 voir [4, 10, 15]

CHAPITRE 5. SCHÉMA XML CANONIQUE POUR UN PROCESSUS ETL 34 < 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 "/> </ xs: complextype > </ xs:schema > Un schéma canonique est plus compact et plus facile à parcourir. On peut à présent trouver une stratégie de parcourir systématiquement tout schéma canonique de la source ou de la destination pour extraire facilement la structure qui y est définie. 5.6 Comment parcourir un schéma canonique Le point clé du parcours d un schéma canonique XSD consiste à tester le type de l élément défini : Si c est un attribut, alors terminer pour cette branche, Si c est un élément de type prédéfini dans le langage XSD (type Simple), alors on a fini pour cette branche, Sinon, prendre le nom du type (complexe ou défini par l utilisateur) dans l attribut type, chercher la branche qui définit le type dont on vient de prendre le nom, effectuer un appel récursif sur chacun des fils éventuels déclarés dans ce type, terminer et remonter pour passer à l élément suivant si c est possible. Comme nous pouvons le constater dans ce parcours et dans les algorithmes qui vont suivre, les techniques de récursion sont abondament utilisées dans ce travail.

Chapitre 6 Générateur automatique de fichier XSLT Ce chapitre présente la conception d un générateur automatique de fichier XSLT à partir des schémas définis au chapitre 5. C est ce fichier qui sera appliqué aux données XML source pour extraire et transformer les informations. Nous savons que les langages les plus utilisés pour la transformation des documents XML sont XQuery et XSLT. Mais pourquoi a-t-on choisi XSLT et pas XQuery? Pour répondre à cette question, voyons d abord un petit rappel sur chacun de ces langages. 6.1 XPath XPath est un langage utilisé pour naviguer entre les éléments et les attributs dans un document XML [15]. Dans la table 6.1, nous reprenons quelques expressions XPath couramment utilisées. Expression Description / sélectionne depuis la racine // sélectionne les noeuds du document, qui correspondent à la sélection.. sélectionne le noeud courant @ sélectionne les attributs. Tab. 6.1 Qeulques expressions XPath 6.2 XQuery XQuery est un langage d interrogation des données XML. En d autres termes, c est un langage permettant d écrire les requêtes sur les documents XML comme on le fait avec SQL sur les bases de données relationnelles. XQuery utilise les expressions XPath pour accéder aux noeuds du document. Dans cette section, nous voulons tout simplement donner un aperçu général du langage XQuery. Le lecteur 35

CHAPITRE 6. GÉNÉRATEUR AUTOMATIQUE DE FICHIER XSLT 36 trouvera plus d informations sur http://www.w3schools.com/xquery. Les fonctions les plus élémentaires en XQuery sont celles d ouverture de document et les expressions FLWOR 1 [7]. 6.2.1 Ouverture des fichiers L ouverture des documents en XQuery se fait en utilisant la fonction spéciale doc. Pour ouvrir un fichier nommé personslist.xml, par exemple, on écrira doc("personslist.xml") 6.2.2 Expressions FLWOR Les expressions FLWOR sont les plus simples en XQuery : For : permet de sélectionner les éléments, Let : permet de déclarer une variable et de lui attribuer une valeur, Where : permet, comme en SQL, de spécifier les conditions à satisfaire, Ordered By : permet de préciser l ordre à suivre dans le tri. 6.3 XSLT XSLT est essentiellement utilisé pour la transformation des documents XML. Il définit ses opérations selon la représentation en arbre des documents XML [5] et utilise les expressions XPath pour accéder aux noeuds. Dans ce paragraphe, nous survolons quelques fonctions de base les plus utilisées en XSLT. Le lecteur pourrait approfondir ses connaissances en consultant [5, 15]. 6.3.1 Déclaration d un document XSLT Comme nous l avons dit précédemment, un document XSLT est un document XML. Pour déclarer un document XSLT, il faut que l élément racine soit <xsl:stylesheet> ou <xsl:transform> En ajoutant les attributs utiles, nous obtenons <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/xsl/transform"> ou <xsl:transform version="1.0" xmlns:xsl="http://www.w3.org/1999/xsl/transform"> 6.3.2 Quelques notions de base Ci-après, nous présentons quelques concepts XSLT en vue de donner au lecteur novice une idée générale lui permettant de comprendre la suite de ce travail. template contient les règles à appliquer lorsqu on rencontre un noeud précis. Pour définir un template, on utilise l élément <xsl:template> dont l attribut match permet de préciser le noeud ciblé. 1 Voir le paragraphe 6.2.2

CHAPITRE 6. GÉNÉRATEUR AUTOMATIQUE DE FICHIER XSLT 37 value-of permet d extraire la valeur du noeud sélectionné. On utilise l élement <xsl:value-of> dont l attribut select précise ce qu il faut sélectionner. if permet de tester une condition. On fait usage de l élément <xsl:if> dont l attribut test indique l expression à tester. apply-templates permet d appliquer un template à l élément courant ou aux noeuds descendants. L élement utilisé est <xsl:apply-templates> 6.4 Pourquoi XSLT et pas XQuery? Nous avons préféré d utiliser XSLT dans notre ETL pour les raisons suivantes. XSLT utilise la synthaxe XML. C est un document bien formé. Il est donc facilement extensible. Historiquement, XQuery a été conçu pour être un langage de requêtes alors que XSLT est fait pour les transformations. La transformation est sans doute, la partie la plus difficile dans un processus ETL. XSLT s adapte facilement aux systèmes fonctionnant en pipeline [6]. La version 1.0 de XSLT est une recommandation W3C depuis 1999 et la 2.0 vient d être recommandée en janvier 2007 alors que XQuery 1.0 n est recommandée qu en janvier 2007 2. XSLT permet de parcourir tout le document source alors XQuery ne vise que certaines de ses parties. Le concept de template présent dans XSLT n existe pas dans XQuery [6]. les templates facilitent l écriture des règles de transformation. XSLT 2.0 inclut le formatage des nombres, dates et heures [6]. Ainsi, on pourrait par exemple, convertir le nombre 1127 en 1.127,00. Chose qu on ne pourrait pas faire avec XQuery du moins pour le moment. Les 2 langages sont basés sur les expressions XPath. Fondamentalement, il n y a pas des grandes différences entre les deux langages mais sur le plan fonctionnel, XSLT 2.0 offre plus de possibilité que XQuery [6]. Actuellement, on admet aussi que le XSLT est plus adapté pour la manipulation des documents. Nous choisissons donc XSLT parce que tant à la source qu à la destination, nous avons affaire avec des documents XML. Le choix de XQuery se fera : dans le traitement des schémas en vue de créer une interface où l utilisateur pourrait choisir ses correspondances (Mapping Interface) et dans l extraction de la structure définie par le schéma XSD en vue de la montrer à l utilisateur. Ce choix s explique aussi par le fait que XQuery s incorpore plus facilement dans les langages de programmation comme le PHP. 2 voir http://fr.wikipedia.org/wiki/xquery

CHAPITRE 6. GÉNÉRATEUR AUTOMATIQUE DE FICHIER XSLT 38 6.5 Comment générer un fichier XSLT automatiquement Pour générer un fichier XSLT automatiquement, la stratégie consiste à ouvrir un fichier en écriture et y mettre les entêtes XSLT, parcourir l interface des correspondances (Mapping Interface) et à chaque type de correspondance, écrire le code XSLT adéquat dans le fichier, fermer le fichier XSLT. Dans notre implémentation dont le code PHP se trouve en annexe, ces tâches sont effectuées dans la fonction extracttransform. Ci-après, nous présentons une brève explication en métalangage pour garder la conception suffisamment indépendante du langage de programmation utilisé. Tous ces algorithmes propoés sont le résultat de notre propre conception. 6.5.1 Programme principal Le code du programme principal produisant le fichier XSLT se trouve dans le listing 6.1. Dans ce code : outfilexsl est le nom du fichier XSLT à créer, filexsl est le descripteur du fichier XSLT ouvert, fopen la primitive permettant d ouvrir un fichier, fclose la primitive de fermeture du fichier ouvert. Rappelons que ces deux primitives existent dans la plupart des langages de programmation et que l ouverture en écriture d un fichier qui n existe pas aura pour conséquence, la création d un nouveau fichier portant ce nom. Listing 6.1 La fonction qui génère le fichier XSLT function extracttransform ( nbelem ) outfilexsl :=" name of the output XSLT file "; filexsl := fopen ( outfilexsl," w"); // open file for writing fwrite ( filexsl," <? xml version =\"1.0\" encoding =\" ISO -8859-1\" >\ n"); // write the XML declaration in the output file fwrite ( filexsl," < xsl : transform xmlns : xsl =\" http :// www.w3.org /1999/ XSL / Transform \" version =\"1.0\" >\n >") ; // write the XSLT declaration in the output file fwrite ( filexsl," < xsl : output method =\" xml \" encoding =\" ISO -8859-1\"/ >\ n"); // The output method of the XSLT file is XML " generate the content of the XSLT file here!"; // process " nbelem " elements / attributes defined // in the source XSD fwrite ( filexsl," </ xsl : transform >\n"); // close the " xslt : transform " tag fclose ( filexsl ) // close the output file

CHAPITRE 6. GÉNÉRATEUR AUTOMATIQUE DE FICHIER XSLT 39 6.5.2 Code XSLT selon la transformation demandée Dans ce paragraphe, nous présentons une façon de générer le code XSLT selon le type de transformation choisie par l utilisateur. Nous signalons tout de suite que dans le prototype que nous avons développé, nous n avons couvert que quelques configurations des transformations. Notre objectif étant de montrer tout simplement la faisabilité de générer un XSLT automatiquement. Pour un ETL à mettre en production, il faut essayer de couvrir au mieux les types des conversions possibles. Nous avons implémenté les cas des transformations suivantes. Transformation d un élément en un autre élément. Transformation des attributs (que l élément lui-même soit transformé ou pas). Transformation des éléments descendants. Dans le code du listing 6.2, on utilise, notamment, les variables suivantes. elsrc est le nom de l élément source à transformer éventuellement, eldst est le nom de l élément destination correspondant à la transformation, attribsrc est le nom de l attribut qu on veut transformer, attribdst est le nom de l attribut/élément en quoi se transforme attribsrc, elsrclst est la liste des noms des éléments définis à la source, eldstlst est la liste des noms des éléments définis à la destination. Listing 6.2 Production du code XSLT selon le type de transformation choisie while (" elsrclst is not empty ") elsrc :=" the next elem in elsrclst "; eldst :=" corresponding elem in eldstlst "; fwrite ( filexsl," < xsl : template match =\" elsrc \" >\n"); // one founds an element called elsrc. What to do? if (" eldst is not empty ") then fwrite ( filexsl," < eldst >") ; // open the tag of the correspoding element " Generate XSLT code for translating attributes of elsrc, if needed "; // we have to check wether attributes should be transformed // even if the elemenent itself is not taken. if (" eldst is not empty ") then fwrite ( filexsl," < xsl : apply - templates / >\n"); // apply template of children fwrite ( filexsl," </ eldst >") ; // close the tag of the destination element. else // there is no direct corresponding element fwrite ( filexsl," < xsl :if test =\" child ::*\" >\ n"); // Test whether the current element has any children fwrite ( filexsl," < xsl : apply - templates / >\n"); // apply template of children

CHAPITRE 6. GÉNÉRATEUR AUTOMATIQUE DE FICHIER XSLT 40 fwrite ( filexsl," </ xsl :if >\n"); fwrite ( filexsl," </ xsl : template >\n"); " remove elsrc from elsrclst "; // elsrc is processed 6.5.3 Transformation des attributs de l élément courant Dans cette section nous proposons une stratégie permettant de créer le code XSLT pour transformer les attributs de l élément courant. Dans notre prototype, nous avons couvert les cas où : l attribut se transforme en un attribut de l élément correspondant au père dans la transformation, l attribut se transforme en élément. Dans le code du listing 6.3 (p.40) : attribsrclst est la liste des attributs de l élément courant de la source. Listing 6.3 Production du code XSLT pour transformer les attributs de l élément courant attribsrclst =" list of attributes of elsrc "; while ( attribsrclst is not empty ) // one must process all attributes attribsrc :=" the next attribute in attribsrclst "; attribdst :=" corresponding elem or attribute in eldstlst "; if( attribdst is an attribute of eldst ) then fwrite ( filexsl," < xsl : attribute name =\" attribdst \" >\n"); // create the attribute fwrite ( filexsl," < xsl : value -of select =\" @attribsrc \"/ >\ n"); // take the value of the attribute fwrite ( filexsl," </ xsl : attribute >\n"); // close creation of attribute else if( attribdst is an element ) then fwrite ( filexsl," < attribdst >\n"); fwrite ( filexsl," < xsl : value -of select =\" @attribsrc \"/ >\ n"); fwrite ( filexsl," </ attribdst >\n"); " remove attribsrc from attribsrclst "; 6.5.4 Comment trouver l élément ou l attribut correspondant? Avant d envisager toute transformation, il faut d abord trouver ce qui correspond à l attribut ou à l élément que l on veut transformer. La résolution de ce problème est fortement lié au langage de programmation utilisé et à l interface des correspondances implémentée.

CHAPITRE 6. GÉNÉRATEUR AUTOMATIQUE DE FICHIER XSLT 41 Fig. 6.1 Interface des correspondances Dans notre prototype, l interface de la figure 6.1 montre un formulaire dans lequel on peut sélectionner un correspondant pour chaque élément ou attribut source. Ce formulaire peut être recupéré sous forme de tableau à deux colonnes ou sous forme de 2 vecteurs de même dimension. Il suffit alors de parcourir la colonne source et regarder à chaque fois s il y a un correspondant à la destination. 6.6 Autres opérations possibles Comme nous venons de le voir, nous n avons implémenté qu un nombre d opérations relativement limité dans le prototype pour illustrer la faisabilité d une génération automatique d un fichier XSLT. Dans un environnement de production réel, il serait souhaitable d implémenter certaines opérations plus compliquées comme celles que nous citons ci-après (liste non ex-

CHAPITRE 6. GÉNÉRATEUR AUTOMATIQUE DE FICHIER XSLT 42 haustive). 6.6.1 Opérateur de fusion L opérateur de fusion permettra à l ETL de fusionner deux éléments suite à la demande de l utilisateur. Rappelons qu ici l utilisateur n est plus censé écrire la moindre ligne de code! Par exemple, si l entrée est la suivante, <middlename>shele</middlename> <lastname>tsheke</lastname> la fusion donnerait : ou encore <familyname>tsheke Shele</familyname> <familyname>shele Tsheke</familyname> 6.6.2 Opérateur de séparation C est l inverse de la fusion définie au paragraphe 6.6.1. Si nous mettons à l entrée <familyname>shele Tsheke</familyname> la séparation donnerait : <middlename>shele</middlename> <lastname>tsheke</lastname> 6.6.3 Opérateur de transformation d un élément en attribut C est plus ou moins l inverse de ce que nous avons implémenté dans le prototype. Ici, un élément donné deviendrait un attribut d un autre élément. Considérons un cas où on aurait les éléments suivants, <middlename>shele</middlename> <lastname>tsheke</lastname> la transformation donnerait : <familyname othername="shele">tsheke</familyname> 6.6.4 Opérateur de vérification de compatibilité Cet opérateur est fondamental dans un processus ETL. En effet, n importe quel élément ou attribut ne peut se transformer en n importe quel autre élément ou attribut. Il faut s assurer de la compatibilité des types pour éviter d avoir un document non valide à la destination. En particulier, on ne devrait pas arriver à une situation où on puisse mettre le nom d une personne à l endroit prévu pour la date de naissance. 6.6.5 Opérateurs arithmétiques Ces opérateurs de base (+,-,/,*) devraient permettre d effectuer quelques opérations sur les valeurs numériques au cours d un processus ETL.

CHAPITRE 6. GÉNÉRATEUR AUTOMATIQUE DE FICHIER XSLT 43 6.6.6 Opérateur de manipulation des instructions de traitement Cet opérateur devrait dire ce qu il faut faire quand on a affaire à une instruction de traitement. 6.6.7 Opérateurs d exécution paralèlle d un processus ETL Ces opérateurs devraient permettre le parallélisme dans un processus ETL tel que nous l avons abordé au paragraphe 4.1. On pourrait ainsi étudier la possibilité d une exécution sur les GRIDs ou sur des systèmes distribués.

Chapitre 7 Réalisation de l ETL Ce chapitre montre une façon de formaliser et de rassembler les fonctions et les concepts présentés dans les chapitres précédents en vue de réaliser un outil ETL réellement fonctionnel. Nous montrerons en particulier une manière dont on pourrait se servir du fichier XSLT généré au chapitre 6 pour Extraire, Transformer et Charger (Load) les données dans l entrepôt. Dans le souci de permettre au programmeur d utiliser la méthodologie et le langage de programmation de son choix, nous présenterons d abord les algorithmes les plus importants en métalangage et nous donnerons par la suite, une explication générale de la manière dont on a développé notre prototype ETL. 7.1 Quelques algorithmes du processus ETL des données XML Dans cette section, nous proposons quelques fonctions qui nous semblent indispensables ou du moins importantes dans le développement d un outil ETL de données XML. Le Développeur pourra apporter les adapations nécessaires à la méthode et/ou au langage de programmation qu il compte utiliser. Précisons tout de même que l absence de référence dans cettte section s explique par le fait que les algorithmes proposés sont le fruit de notre propre conception. 7.1.1 Vérifier si un type est prédéfini en XSD Comme nous l avons vu au paragraphe 5.4.1 (p.31), le nom d un type prédéfini commence par xs :. Le fait d avoir ce préfixe 1 signifie qu on est en présence d un type simple et prédéfini. Nous formalisons notre raisonnement dans le listing 7.1. Listing 7.1 Algorithme testant si un type est prédéfini function issimpletype ( typename ) returnval := false ; if " xs: is a prefix of typename " then returnval := true ; return returnval ; 1 On pourrait, éventuellement, considérer le prefixe xsd 44

CHAPITRE 7. RÉALISATION DE L ETL 45 7.1.2 Vérifier si un tag de XSD définit un élément Comme nous l avons vu au chapitre 5 (p. 28), la définition d un élément se fait avec le tag spécial xs : element (parfois on utilise xsd : element). Il suffit donc de vérifier si on a affaire avec ce tag pour savoir si on définit un élément. C est ce que nous faisons dans l algorithme du listing 7.2. Listing 7.2 Algorithme testant si un tag XSD définit un élément function iselement ( tagname ) returnval := false ; if " tagname is xs: element " then returnval := true ; return returnval ; 7.1.3 Vérifier si un tag de XSD définit un attribut En suivant un raisonnement analogue á celui du paragraphe 7.1.2, nous obtenons l algorithme du listing 7.3. Listing 7.3 Algorithme testant si un tag XSD définit un attribut function isattribute ( tagname ) returnval := false ; if " tagname is xs: attribute " then returnval := true ; return returnval ; 7.1.4 Extraction du nom d un élément, attribut ou type défini Ce paragraphe montre comment extraire le nom de l élément, de l attribut ou du type complexe défini dans le noeud courant de l arbre du schéma XSD. Pour trouver 2 cette information, il suffit de vérifier si le noeud a des attributs. Si c est le cas, alors prendre la valeur de l attribut name. Une fonction que nous proposons pour effectuer cette tâche est reprise dans le listing 7.4. Listing 7.4 Algorithme d extraction du nom de l élément/attribut/type complexe défini function elemname ( node ) if (" node is not null " and node - > hasattributes ()) then returnval := node -> getattribute (" name "); return returnval ; 2 Voir le chapitre 5 pour la définition de schéma XSD

CHAPITRE 7. RÉALISATION DE L ETL 46 7.1.5 Extraction du type de l élément ou de l attribut défini Dans le listing 7.5, nous proposons une fonction permettant d extraire le type de l élément ou de l attribut défini dans le noeud passé en argument. Listing 7.5 Extraction du type de l élément ou attribut défini function elemtype ( node ) if (" node is not null " and node - > hasattributes ()) then returnval := node -> getattribute (" type "); return returnval ; 7.1.6 Traitement d un élément et de ses fils directs L algorithme du listing 7.6 traite l élément défini dans le noeud passé en argument et ses fils éventuels définis dans un type complexe. La fonction retourne une liste contenant le nom de l élément et ceux de ses attributs. Listing 7.6 Traitement de l élément défini et de ses fils function sonsandattributes ( xpath, node ) // xpath is a DOMPath. // node is a node of this DOM tree. // variables initialisation tagname := NULL ; elemname := NULL ; sonname := NULL ; attname := NULL ; elemtype := NULL ; returnval := NULL ; if( ( node is not NULL ) and ( xpath is not NULL )) then if( iselement (node -> tagname )) then elemname := elemname ( node ); // take the name of the element returnval []:= elemname ; // insert the name of element in the table to return elemtype = elemtype ( node ); // take the type if( not ( issimpletype ( elemtype ))) then // complextype query :="// xs: complextype [ @name = elemtype ]/*"; // take all the children of the defined complextype element xpathquery := xpath -> query ( query ); // run query and return a list of sons ( nodes )

CHAPITRE 7. RÉALISATION DE L ETL 47 foreach ( son in xpathquery ) sontagname := son -> tagname ; //i.e xs: element sonname = elemname ( son ); if( iselement ( sontagname )) then // process the child element if needed else if( isattribute ( sontagname )) then // process the attribute returnval []:=" elemname /[ @sonname ]"; return returnval ; 7.1.7 Chargement des schémas Le chargement des schémas est intimément lié à la méthodologie et au langage de programmation utilisés. Nous invitons le lecteur à consulter la documentation des outils de développement dont il fait usage. Il trouvera néanmoins un exemple PHP dans le code source en annexe. 7.1.8 Extraction des éléments et attributs définis dans un XSD Une façon d extraire les éléments et les attributs définis dans un schéma XSD consiste à : prendre tous les éléments <xs : element>de XSD et extraire, pour chacun de ces éléments, les attributs éventuels. Nous illustrons cette démarche dans le listing 7.7. Listing 7.7 Traitement de l élément défini et de ses fils function extractelem () " initialize xmldoc to the XSD document "; " initialize xptah to xpath of the document "; query :="// xs: element [ @name ]"; // all defined elements xpathquery := xpath -> query ( query ); // run query elemlist := array (); // list of elements and attributes tmplst := array (); // the name of the current element and its attributes foreach ( elem in xpathquery )

CHAPITRE 7. RÉALISATION DE L ETL 48 tmplst := sonsandattributes ( xpath, elem ); elemlist := merge ( elemlist, tmplst ); " process elemlist "; 7.1.9 Parsing d un noeud et de ses fils éventuels La fonction définie dans le listing 7.8 permet notamment d insérer dans la visionneuse (viewer) des schémas, le sous arbre défini dans XSD et descendant à partir du noeud courant. Nous laissons au programmeur la latitude de définir le modèle de présentation dans lequel il souhaite visualiser la structure de document défini. Dans le prototype, nous avons simplement créé un fichier XML que l on peut visualiser facilement sur un navigateur web. Listing 7.8 Parsing d une branche d un arbre défini dans un XSD function parsenode ( node, xpath ) if (( node is not NULL ) and ( xpath is not NULL )) then tagname := node -> tagname (); if( iselement ( tagname )) then elemtype := elemtype ( node ); if( issimpletype ( elemtype )) then " insert element in the viewer "; else // an element of complex type. query :="// xs: complextype [ @name = elemtype ]// xs: attribute [ @name ]"; // attributes of the current element attributes := xpath -> query ( query ); // run query " insert element and its attributes in the viewer "; query :="// xs: complextype [ @name = elemtype ]// xs: element [ @name ]"; // children elements elements := xpath -> query ( query ); // list of children elements foreach ( element in elements ) parsenode ( element, xpath ); // recursive call else // the node doesn t define an element if(node -> haschilds ()) then

CHAPITRE 7. RÉALISATION DE L ETL 49 children := node -> childnodes ; // list of children nodes foreach ( child in children ) parsenode ( child, xpath ); // recursive call 7.1.10 Parsing de la structure définie dans un fichier XSD La fonction définie dans le listing 7.9, permet d extraire la structure de document défini dans un fichier XSD. Cette fonction est notamment utilisée pour créer une visionneuse (viewer) des schémas sans montrer le fichier XSD comme tel. Listing 7.9 Parsing d une structure définie dans un fichier XSD function parseschema () " initialization of the document "; " initilization of xpath "; query :="// xs: schema /xs: element [ @name ]"; // root element xpathquery := xpath -> query ( query ); // run query if( xpathquery is not NULL ) then " begin creation of viewer "; rootelem := xpathquery -> item (0) ; parsenode ( rootelem, xpath ); " end creation of viewer "; 7.1.11 Création de l interface des correspondances L interface des correspondances est la fenêtre dans laquelle l utilisateur déterminera les transformations à effectuer. Nous laissons au programmeur la liberté de créer l interface de son choix. Dans notre prototype, nous générons un formulaire illustré à la figure 6.1. La fonction extractelem définie dans le listing 7.7 peut aider à obtenir la liste des éléments et des attributs définis dans les schémas XSD source et destination. 7.1.12 Compilation d un processus ETL Dans ce paragraphe, nous illustrons une manière de rassembler (compiler) les différentes fonctions définies précédemment pour réaliser un processus ETL. C est ici où nous faisons usage du fichier XSLT généré au chapitre 6 (p. 35).

CHAPITRE 7. RÉALISATION DE L ETL 50 La connexion à la source de données se fera en fonction de son SGBD et des types de connexions autorisées. Les données extraites et transformées seront chargées dans l entrepôt de données XML selon les règles prévues pour le chargement. Listing 7.10 Compilation d un processus ETL function initetl () if (" There is no XSLT for the transformation ") " Load source and destination schemas "; " Run extractelem for XSD source "; " Run extractelem for XSD destination "; " Run parseschema for XSD source "; " Run parseschema for XSD destination "; " Create a mapping interface "; " Generate the XSLT file at request "; // run extracttransform " Apply the XSLT file on the source data "; // data are Extracted and Transformed " Load Transformed Data to the XML Warehouse "; // data Extracted, Transformed and Loaded 7.2 Prototype ETL développé Dans le prototype que nous avons développé, nous avons utilisé un serveur web apache et le langage de programmation PHP5. Quant à la méthologie de programmation, nous avons opté pour une approche orienté objet. Nous avons développé une application web pour permettre aux ayants droit de l utiliser à distance sans avoir à installer une quelconque application cliente mais d utiliser tout simplement un navigateur web (Internet Explorer, Fire Fox,...). Pour le chargement de données, nous nous sommes limité à stocker le fichier résultat dans un répertoire donné. Nous reprenons un exemple d application au chapitre 8 (p.51) pour illustrer le fonctionnement du prototype développé. Le lecteur intéressé trouvera le code source dans les annexes.

Chapitre 8 Exemple d application Dans ce chapitre, nous présentons un exemple d application du protype ETL que nous avons développé. Il y aura beaucoup d images de capture d écran parce qu il s agit d une application web dynamique. De manière générale, l application consiste en un chargement de schéma XSD source un chargement de schéma XSD destination (entrepôt de données XML) un fichier XML de données source une génération automatique d un fichier XSLT extraction, transformation et chargement (Load) de la source vers la destination. Dans ce prototype, le chargement à l entrepôt de données XML se fait en stockant le fichier XML produit par l ETL dans un répertoire précis (output). 8.1 Chargement des fichiers dans l ETL La page d accueil montrée à la figure 8.1 offre la possibilité de charger les schémas source et destination. Quant au fichier de données, en principe, l ETL se connecte à la source pour extraire les données mais dans ce prototype, nous avons prévu la possibilité d aller les chercher dans un répertoire donné ou de les charger sur l ETL (à la page d accueil). Pour tester l application, nous procédons de la manière suivante. Charger le schéma XSD source ( listing 8.1 p. 51). Charger le schéma XSD destination (listing 2.3 p. 15). Les données de la source sont celles du listing 8.2 (p. 52). cliquer sur le bouton Upload Files pour valider le chargement. Listing 8.1 Schema XSD d une source <? xml version =" 1.0 " encoding ="ISO -8859-1 "?> <! -- Une liste de personnes en Belgique -- > < xs:schema xmlns:xs =" http: // www.w3.org /2001/ XMLSchema "> < xs:element name =" listepersonnes " type =" typelistepersonnes "/> < xs: complextype name =" typelistepersonnes " > < xs:element name =" personne " type =" typepersonne "/> </ xs: complextype > 51

CHAPITRE 8. EXEMPLE D APPLICATION 52 < xs:complextype name =" typepersonne "> < xs:element name =" prenom " type =" xs:string "/> < xs:element name =" nomdefamille " type =" xs:string " use =" require "/> < xs:element name =" langue " type =" xs:string "/> < xs:attribute name =" datenais " type =" xs:date " use =" require "/> </ xs: complextype > </ xs:schema > Fig. 8.1 Page d accueil de XML ETL Listing 8.2 Données XML d une source <? xml version =" 1.0 " encoding ="ISO -8859-1 "?> < listepersonnes > < personne datenais =" 2008-12 -12 "> <prenom >Johnny </ prenom > < nomdefamille > Tsheke </ nomdefamille > <langue > français </ langue > </ personne > < personne datenais =" 2009-06 -12 "> <prenom >Pierre </ prenom > < nomdefamille > Manneback </ nomdefamille > <langue > français </ langue > </ personne > < personne datenais =" 2004-10 -08 ">

CHAPITRE 8. EXEMPLE D APPLICATION 53 <prenom > Esteban </ prenom > < nomdefamille > Zimanyi </ nomdefamille > <langue > français </ langue > </ personne > </ listepersonnes > 8.2 Visualisation des schémas chargés Une fois les fichiers chargés, on arrive à une page permettant de visualiser les structures des arborescences définies respectivement par le schéma source et le schéma destination. Fig. 8.2 Visualisation des arborescences définies dans les schémas Comme le montre la figure 8.2, le Mapping Interface permet de choisir les correspondances de la transformation qu on souhaite effectuer. 8.3 Un choix de correspondances Prenons par exemple un cas dans lequel on choisit toutes les informations relatives à une personne, à l exception de langue. (voir la figure 8.3). Cliquons ensuite sur le bouton Transforme de Mapping Interface. L ETL génère dès lors le code XSLT repris dans le listing 8.3 (p. 53). Listing 8.3 XSLT généré suite aux choix du paragraphe 8.3 <? xml version =" 1.0 " encoding ="ISO -8859-1 "?> < xsl:transform xmlns:xsl =" http: // www.w3.org /1999/ XSL / Transform " version =" 1.0 "> < xsl:output method =" xml " encoding ="ISO -8859-1 "/> < xsl: template match =" listepersonnes " >