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

(1)

Facult´ e Polytechnique de Mons

Johnny TSHEKE SHELE

Le processus d’Extraction, Transformation et Load (ETL) dans des entrepˆ ots de donn´ ees XML

Travail de fin d’études présenté en vue de l’obtention du grade d’Ingénieur Civil en Informatique et Gestion

Ann´ee acad´emique 2006-2007

Promoteurs:

Prof. Pierre Manneback (FPMs) et Prof. Esteban Zim´anyi (ULB)

(2)

`a Brian

1

(3)

Table des mati` eres

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´eclaration d’un document XML . . . 13

2.1.4 Exemple d’un document XML . . . 13

2.2 Types et sch´emas 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´e etvalide . . . 15

2.3.1 Document bien form´e . . . 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´ees XML . . . 19

3.3 Classification des bases de donn´ees XML . . . 19

3.3.1 Base de donn´ees avec support XML . . . 19

3.3.2 Base de donn´ees XML Native . . . 20

3.4 Entrepˆot de donn´ees . . . 20

3.4.1 Source des donn´ees de l’entrepˆot . . . 20

3.4.2 Structure de données d’un entrepôt de données . . . 20

3.4.3 Interrogation de l’entrepˆot de donn´ees . . . 20

3.5 Entrepˆot de donn´ees 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

(4)

TABLE DES MATI `ERES 3

4 ETL : ´Etat de l’art 24

4.1 Ex´ecution parall`ele . . . 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´e avec les syst`emes d’exploitation . . . 25

4.4 ETL spatial . . . 25

4.5 Quelques logiciels ETL . . . 26

4.5.1 ETLs propri´etaires . . . 26

4.5.2 ETLs open source . . . 27

5 Sch´ema 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´emas . . . 30

5.4 Règles génerales d’écriture d’un XSD . . . 31

5.4.1 Un ´el´ement de type simple . . . 31

5.4.2 Un ´el´ement de type complexe . . . 32

5.5 R`egles canoniques . . . 33

5.6 Comment parcourir un sch´ema canonique . . . 34

6 G´en´erateur 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´eclaration 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´en´erer un fichier XSLT automatiquement . . . 38

6.5.1 Programme principal . . . 38

6.5.2 Code XSLT selon la transformation demand´ee . . . 39

6.5.3 Transformation des attributs de l’´el´ement courant . . . 40

6.5.4 Comment trouver l’´el´ement ou l’attribut correspondant ?. . . 40

6.6 Autres op´erations possibles . . . 41

6.6.1 Op´erateur de fusion . . . 42

6.6.2 Op´erateur de s´eparation . . . 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´erateurs arithm´etiques . . . 42

6.6.6 Op´erateur de manipulation desinstructions de traitement . . . 43

6.6.7 Opérateurs d’exécution paralèlle d’un processus ETL . . . 43

(5)

TABLE DES MATI `ERES 4

7 R´ealisation de l’ETL 44

7.1 Quelques algorithmes du processus ETL des donn´ees 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´erifier si un tag de XSD d´efinit 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 ´el´ement et de ses fils directs . . . 46

7.1.7 Chargement des sch´emas . . . 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 ´eventuels . . . 48

7.1.10 Parsing de la structure d´efinie dans un fichier XSD . . . 49

7.1.11 Cr´eation de l’interface des correspondances . . . 49

7.1.12 Compilation d’un processus ETL . . . 49

7.2 Prototype ETL d´evelopp´e . . . 50

8 Exemple d’application 51 8.1 Chargement des fichiers dans l’ETL . . . 51

8.2 Visualisation des sch´emas charg´es. . . 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´evelopp´e 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

(6)

Table des figures

1.1 Le processus ETL dans un entrepˆot de donn´ees XML. . . 9

1.2 Exportation/importation de donn´ees d’un SGBD `a 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´eellement obtenus avec l’API DOM . . . 18

3.1 Exemple de l’entrepˆot de donn´ees d’Arizona State University [14] . . . 21

3.2 Exemple d’un entrepˆot de donn´ees 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´efinies dans les sch´emas. . . 53

8.3 Un choix d’une transformation . . . 54

8.4 Un autre choix de transformation . . . 57

5

(7)

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´efinie dans le listing 2.3 . . . 28

5.2 Autre fa¸con d’´ecrire le sch´ema 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´ema canonique . . . 33

6.1 La fonction qui g´en`ere 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´efinit 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´efini dans un XSD . . . 48

7.9 Parsing d’une structure d´efinie dans un fichier XSD. . . 49

7.10 Compilation d’un processus ETL . . . 50

8.1 Schema XSD d’une source . . . 51

8.2 Donn´ees 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

(8)

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 In- formatique 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

(9)

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¹ 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 indispen- sables 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

´egalement en XML.

1.2 Autres int´ erˆ ets de l’ETL de donn´ ees 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´erence des sch´emas ;

1Data Warehouses

8

(10)

CHAPITRE 1. INTRODUCTION 9

XML

Source 1 (Schema 1)

XML

Data Warehouse (Schema of DW)

ETL XML

Source 2 (Schema 2)

XML

Source X (Schema X)

Fig. 1.1 – Le processus ETL dans un entrepˆot de donn´ees 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)² , 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

(11)

CHAPITRE 1. INTRODUCTION 10

XML

source

XML

Destination

SGBD1 SGBD2

ETL

Fig. 1.2 – Exportation/importation de donn´ees d’un SGBD `a un autre

GML

source

SVG

Destination

ETL

Fig.1.3 – Transformation d’un document GML en SVG

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 figure1.3).

etc.

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´e au chapitre 2,

– Le chapitre3 introduira ensuite, les entrepˆots de donn´ees XML.

– L’´etat de l’art du processus ETL sera donn´e au chapitre 4.

– Au chapitre5, nous expliquons une fa¸con d’´ecrire un sch´ema 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 chapitre6.

– 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 chapitre8sous forme d’un

(12)

CHAPITRE 1. INTRODUCTION 11 exemple d’application.

– Au chapitre9, nous tirerons des conclusions et proposerons quelques pistes de recherche pour le futur.

Compte tenu de la limitation du nombre³ 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

(13)

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 (eXtendedMarkup 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´ees [13],

– un ensemble de r`egles permettant de cr´eer 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¹. 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´ee (exemple : <person/>).

En XML, les Tags (annotations) respectent les r`egles 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.

1annotations ou balises

12

(14)

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`egles suivantes.

– Avoir un et un seul élément racine (Root Element). Cet élement est aussi appeléDocu- ment 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 ˆetre ferm´e comme il faut (<person>...</person>ou<person/>).

– Les attributs sont des propri´et´es contenues dans l’annotation d’ouverture.

– Dans un tag, deux attributs ne peuvent pas porter un mˆeme nom [9, 13].

– Il y a une valeurunique par attribut.

– Un ´el´ement peut avoir plusieurs attributs [13].

2.1.3 D´eclaration 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’attributencodingpour 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 >

(15)

CHAPITRE 2. XML EN BREF 14

2.2 Types et sch´ emas 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 parDocument 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 ´el´ements 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 listing2.1, une DTD correspondant pourrait ˆetre 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 ´ecrit en XML [4, 9, 13, 15],

– il permet de sp´ecifier le type de donn´ees [4, 15], – il est extensible,

– il supporte les espaces de noms, – etc.

On parle deXML Schema Definition (XSD)pour d´esigner la grammaire de XML Schema.

Devenu une recommandation² du W3C depuis le 2 Mai 2001 et ´etant 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 enXML 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 listing2.3, un exemple d’un XML Schema qui peut définir le document XML du listing2.1.

2XML Schema est un standard W3C

(16)

Listing 2.3 – Exemple d’un XML Schema -XSD

<! -- 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´ e et valide

2.3.1 Document bien form´e

Un document XML est dit bien formé³ s’il est syntaxiquement correct [1, 2, 9, 15, 19] ; c’est-à-dire qu’il respecte les règles énoncées au paragraphe2.1.2(p.13). Il est exigé que tout document XML à traiter soitbien formé.

2.3.2 Document valide

Un document XML sera ditvalide s’il estbien formé etconforme à 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 estvalide à 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⁴ à partir de laquelle l’utilisateur

3En Anglais, on ditWell formed

4Le fichier XSLT sera généré en fonction des choix faits sur cette interface

(17)

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 `a la figure2.1une illustration de l’arborescence correspondant au document XML du listing2.1(p.13)

(Root Element) personslist

(Element) person

(Element) firstname

(Element) lastname

(Text) Shele

(Text) Tsheke

(Element) person

(Element) lastname

(Text) Pierre

(Text) Manneback

(Element) person

(Element) lastname

(Text) Esteban

(Text) Borrageiros

(Text) Zimanyi (Element)

middlename

(Element) firstname

(Text) Johnny

(Element) middlename

(Element) firstname

(Element) middlename

Fig. 2.1 – Exemple d’une arborescence XML

2.5 Parcours d’un arbre XML

Dans un arbre de repr´esentation 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´eenfant (child),

– A part la racine, chaque noeud a un et un seul parent direct (p`ere), – Un noeud peut avoir 0 ou plusieurs enfants,

– Unefeuille 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`eres suivantes.

– En allant vers un descendant (child). Ceci n’est pas possible pour unefeuille.

– En allant vers un fr`ere (next,previous) si possible.

– En remontant vers le noeud p`ere (parent) si on n’est pas `a la racine.

La figure2.2illustre 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 noeuddocument (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 figure2.2, on obtiendrait en réalité celui de la figure 2.3. Il faut donc être attentif dans la sélection des

(18)

(Element) person (Element)

person

(Element) lastname

(Text) Pierre

(Text) Manneback (Element)

person

(Element) firstname

(Element) middlename firstChild

lastChild

parent

parent children

Fig.2.2 – Parcours d’un arbre XML noeuds utiles pour ´eviter 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 leXSL 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 chapitre6. 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.

(19)

(Element) person (Element)

person

(Text) (Element)

person firstChild

lastChild

(Text) (Text)

(Text) (Document)

Fig. 2.3 – Illustration des noeuds r´eellement obtenus avec l’API DOM

(20)

Chapitre 3

Les entrepˆ ots de donn´ ees XML

3.1 Base de donn´ ees XML

On appelle base de données XML, un logiciel capable de stocker, importer, exporter et rendre accessible lesdonnées XML [18]. Le paragraphe3.2 survole les manières de conserver ces types d’informations.

3.2 Stockage des donn´ ees XML

Il y a plusieurs fa¸cons de stocker les donn´ees XML. Les techniques les plus utilis´ees 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 descollections 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´ ees XML

On classifie habituellement les bases de donn´ees XML en deux grands groupes : cellesavec support XMLet celles qu’on qualifie de natives.

3.3.1 Base de donn´ees avec support XML

Dans ce groupe, on trouve les bases de donn´ees traditionnelles (relationnelle, objet, ...) – avec une couche ou interface permettant l’importation et/ou l’exportation des donn´ees

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 unebase de données objet. Dans le

19

(21)

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´ees 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ˆ ot de donn´ ees

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 figure3.1illustre 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´ees de l’entrepˆot

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’ana- lyse.

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 encube.

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ˆetes SQL et – M-OLAP (Multidimensional On-Line Analytical Porcessing) : si on a un mod`ele encube

de plusieurs dimensions.

De manière plus générale, on parle de OLAP qui englobe aussi d’autres approches (H-OLAP¹, S-OLAP² et D-OLAP³)⁴

1Hybrid OLAP

2Spatial OLAP

3Dynamic ou Desktop OLAP

4Voir http ://fr.wikipedia.org/wiki/OLAP

(22)

CHAPITRE 3. LES ENTREP ˆOTS DE DONN ´EES XML 21

Fig. 3.1 – Exemple de l’entrepˆot de donn´ees d’Arizona State University [14]

3.5 Entrepˆ ot de donn´ ees 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´ees 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¸cons 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¸cu général.

(23)

Fig. 3.2 – Exemple d’un entrepˆot de donn´ees XML : DAWAX [3]

3.6 Entrepˆ ot de donn´ ees XML et ´ echange 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 APIproprié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. DansSQL 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ˆ ot de donn´ ees vs entrepˆ ot de donn´ ees XML

Dans la table3.1nous reprenons une synthèse d’éléments distinguant, de manière générale, unEntrepôt de donnéesd’unentrepô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⁵ n’aurait-il pas dit : “Un Data Warehouse ne s’achète

5On le considère généralement comme le père du conceptData Warehouse

(24)

Entrepôt de données Entrpôt de données XML Données Données relationnelles XML

Valeurs num´eriques 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”⁶. On peut donc utiliser telle ou telle autre technique pour mieux exploiter les donn´ees.

6http ://fr.wikipedia.org/wiki/Entrepˆot de donn´ees

(25)

Chapitre 4

ETL : ´ Etat 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´ ecution parall` ele

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´elisme [17]. Ce dernier peut s’appliquer lorsqu’il faut traiter :

– un gros fichier source, – les donn´ees en pipeline ou – plusieurs sources de donn´ees.

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´eeseXist par exemple, fonctionnent moins bien lorsque le nombre d’entr´ees 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 simul- tané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

(26)

CHAPITRE 4. ETL : ´ETAT 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`ere on gagne en temps parce que le traitement du 2e fichier commence plus tˆot que si on devait attendre de finir le tri du 1er.

Signalons tout de même que leMulti-processing/Multi-threadingn’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´ e avec les syst` emes d’exploitation

A part les ETL incorpor´es dans les produits Microsoft comme SQL Server Integration Service qui ne fonctionnent essentiellement que sous Windows, la plupart des fabricants es- saient de rendre compatibles leurs produits avec un grand nombre de syst`emes 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¹ que l’on peut télécharger gratuitement sur le sitehttp://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

1Open source

(27)

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 ex- ploitant les données,

– importer les donn´ees XML dans le syst`eme de destination.

On obtient ainsi les donn´ees dans l’autre format. Les figures1.2et 1.3illustrent cette possibilit´e.

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 ETLsopen source des ETLs propriétaires. Habituelle- ment 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´etaires

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². 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³ 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⁴ qui a été rachetée parOracle en 2006.

4.5.1.3 Oxio Data Integration

La société fran¸caise 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 .Netnous semble limiter les possibilités de son installation sur d’autres systèmes d’exploitation comme Linux, Mac-Os, etc.

2voirhttp://www.microsoft.com/france/sql/sql2005/decouvrez/presentation.mspx

3 voirhttp://www.oracle.com

4voirhttp://www.oracle.com/sunopsis

(28)

CHAPITRE 4. ETL : ´ETAT DE L’ART 27

4.5.2 ETLs open source 4.5.2.1 Talend open studio

Talend Open Studioest 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¸cons aller éditer un fichier XML pour préciser les informations de connexion (host, login, ...) et les requêtes éventuelles à exécuter.

(29)

Chapitre 5

Sch´ ema XML canonique pour un processus ETL

Dans ce chapitre, nous expliquerons comment ´ecrire un sch´ema 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 duParsing) 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 listing2.3 (p.15), nous voulons quelque chose comme ce qui est dans le listing5.1.

Listing 5.1 – Visualisation de la structure d´efinie dans le listing 2.3

< personslist >

< person birthdate = " xs:date " >

< firstname / >

< middlename / >

< lastname / >

</ person >

</ personslist >

De cette manière l’utilisateur voit directement et de fa¸con 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´e c’est de pouvoir parcourir automatiquement tout sch´ema XML d’une source ou 28

(30)

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´ e d’extraire une structure d´ efinie dans un sch´ ema

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. LeXML schema du listing2.3(p.2.3) par exemple, pourrait encore s’écrire comme dans le listing5.2.

Listing 5.2 – Autre fa¸con d’´ecrire le sch´ema du listing2.3

<! -- Sch´ema d une liste des personnes -- >

< xs:element name = " personslist " >

< xs:complexType >

< xs:element name = " person " type = " personType "/ >

</ xs:complexType >

</ xs:element >

</ 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émentpersonslist. Le fait de déclarerpersonavec un attributtype=”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 listing5.3.

Listing 5.3 – Encore une autre manière d’écrire le schéma du listing2.3

<! -- Sch´ema d une liste des personnes -- >

< 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 >

(31)

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´ emas

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 listing2.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 listing5.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 listing5.4, par exemple.

Listing 5.4 – Illustration des redondances dans un XSD

< 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 >

(32)

CHAPITRE 5. SCH ´EMA 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´ema 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¸con 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` egles g´ enerales d’´ ecriture 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écialschema (<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’attributname de l’élément attribute (<xs:attribute>).

– La définition d’un élément se fait en spécifiant son nom dans l’attributname de l’élément element (<xs:element>).

On distingue deux types d’´el´ements : le typesimple et le typecomplexe.

5.4.1 Un ´el´ement 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émentfirstname défini dans le listing2.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.

(33)

<xs:element name="elemname" type="elemtype"/>

oùelemname est le nom de l’élément que l’on veut définir etelemtype un type simple. Parmi les types simples, on peut citer :

xs:string une chaˆıne de caract`eres

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´eenne qui peut ˆetretrue (vrai) ou false (faux). Les valeurs 1 et 0 indiquent respectivement true etfalse.

xs:date la date qui doit s’encoder au format AAAA-MM-JJ o`uAAAA est l’ann´ee, MM le mois et JJ le jour du mois.

xs:time l’heure au format HH : M M : SS o`u HH, MM et SS d´esignent respectivement l’heure, les minutes et les secondes.

5.4.2 Un ´el´ement de type complexe

Un élément de type complexe peut contenir d’autres éléments et/ou des attributs. Il y deux fa¸cons 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>

</xs:complexType>

</xs:element>

Les élémentsmanetwomandu listing5.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´ethode, on d´efinit 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écialtype. On aura donc les codes suivants dans le fichier XSD.

<xs:element name="elemname" type="complexTypeName"/>

<xs:complexType name="complexTypeName">

</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.

(34)

Listing 5.5 – Exemple de définition d’un élément de type complexe

< xs:element name =" man " type = " personType " / >

</ xs:complexType >

5.5 R` egles 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`egles propos´ees 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émentschema(<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¹ 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`egles, on ´evite de gonfler le code inutilement comme dans le listing 5.4.

L’élementman etwoman sont de même type. Il faut définir le type complexe une seule fois.

Le listing 5.6 montre un exemple de sch´ema canonique ´eliminant les redondances du listing 5.4.

Listing 5.6 – Exemple d’un sch´ema canonique

< 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]

(35)

</ 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´ ema 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´efini par l’utilisateur) dans l’attributtype, – chercher la branche qui d´efinit 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´ecursion sont abondament utilis´ees dans ce travail.