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

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 1 

(Schema 1) 


Source 2 

(Schema 2) 

ETL 


Data Warehouse 

(Schema of DW) 


Source X 

(Schema X) 

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


etc. 

SGBD1 


source 

ETL 

SGBD2 


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 

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


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 : . Le tag fermant correspondant est . 

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

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

– ou sous la forme contractée (exemple : ). 

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 est différent de , lui-même différent de , 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 (... ou ). 

– 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 

 

< personslist > 

 

< firstname >Johnny 

< middlename >Shele 

< lastname >Tsheke 

 

 

< firstname >Pierre 

< middlename /> 

< lastname > Manneback 

 

 

< firstname > Esteban 

< middlename > Borrageiros 

< lastname > Zimanyi 

 


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 

 

 

 

 

 

 

 

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


Listing 2.3 – Exemple d’un XML Schema -XSD 

 

 

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

 

 

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


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) 

(Element) 

firstname 

(Text) 

Johnny 

(Element) 

person 

(Element) 

middlename 

(Text) 

Shele 

(Element) 

lastname 

(Text) 

Tsheke 

(Element) 

firstname 

(Text) 

Pierre 

(Root Element) 

personslist 

(Element) 

person 

(Element) 

middlename 

(Element) 

lastname 

(Text) 

Manneback 

(Element) 

firstname 

(Text) 

Esteban 

Fig. 2.1 – Exemple d’une arborescence XML 

2.5 Parcours d’un arbre XML 

(Element) 

person 

(Element) 

middlename 

(Text) 

Borrageiros 

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 

(Element) 

lastname 

(Text) 

Zimanyi 

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



personslist 

firstChild 

lastChild 

(Element) 

person 

(Element) 

person 

(Element) 

person 

parent 

children 

(Element) 

firstname 

(Element) 

middlename 

(Element) 

lastname 

Fig. 2.2 – Parcours d’un arbre XML 

parent 

parent 

(Text) 

Pierre 

(Text) 

Manneback 

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.


(Document) 


personslist 

firstChild 

lastChild 

(Text) 

(Element) 

person 

(Text) 

(Element) 

person 

(Text) 

(Element) 

person 

(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


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.


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


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


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


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 

 


 

< firstname /> 

< middlename /> 

< lastname /> 

 

 

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 

 

 


< xs:element name =" personslist "> 

< xs:complexType > 

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

 

 






 

 

Dans le code du listing 5.2, l’élément person est déclaré directement à l’intérieur de la 

définition de l’élément personslist. Le fait de déclarer person avec un attribut type=”personType” 

permet de donner sa définition à l’extérieur (dans un xs :complexType). Remarquez que ce 

même schéma peut encore s’écrire comme dans le listing 5.3. 

Listing 5.3 – Encore une autre manière d’écrire le schéma du listing 2.3 

 

 




< xs:element name =" person "> 






 

 

 

 


Dans la méthode du listing 5.3, les éléments fils sont toujours définis à l’intérieur de la 

déclaration de l’élément père. Si nous devrions dessiner les arbres des schémas des listings 

2.3, 5.2 et 5.3, nous verrions sans doute que les branches ont des structures différentes. Et 

pourtant, ils définissent exactement le même type de document. 

En parcourant l’arborescence du schéma pour extraire le type de document qui y est défini, on 

se rend compte que la définition des éléments fils peut être dans les sous-arbres descendants 

de la branche courante ou carrément dans une autre branche (de l’arbre du schéma). D’où la 

difficulté de trouver la définition des éléments fils et des attributs éventuels dans un parcours 

automatique. 

Une question qui nous revient à l’esprit est de savoir si toutes ces méthodes d’écriture des 

schémas sont adaptées pour les entrepôts de données. Si dans un entrepôt de données (XML) 

on évite la répétition inutile des informations, pourquoi ne pas avoir la même exigence dans 

la définition des schémas ? 

5.3 Eviter les redondances dans les schémas 

Comme nous venons de le voir au paragraphe 5.2, un schéma peut s’écrire de plusieurs 

methodes. Malheureusement, il arrive que dans certains cas, on trouve des parties entières de 

code qui se répètent. 

Considérons le schéma du listing 2.3, si nous voulons définir une liste de personnes subdivisée 

en une sous-liste de femmes et une sous-liste d’hommes, la méthode utilisée dans le listing 5.3 

risque de produire des redondances parce que chacune des deux sous-listes pourra contenir la 

définition des mêmes informations définissant les identités d’une personne (firstname,name, 

...). Ce qui donnerait le code du listing 5.4, par exemple. 

Listing 5.4 – Illustration des redondances dans un XSD 

 

 




 

< xs:element name =" menlist "> 


< xs:element name =" man "> 






 

 

 

 

 

< xs:element name =" womenlist "> 


< xs:element name =" woman "> 

< xs:complexType >






 

 

 

 

 

 

 

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 () 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 (). 

– La définition d’un élément se fait en spécifiant son nom dans l’attribut name de l’élément 

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 : 

 

De manière générale, on définit un élément de type simple comme suit.


 

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 

 

 

 

 

 

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. 

 

 

 

 

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.


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

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






 

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 (). 

– 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 

 

 


< xs:element name =" personslist " type =" personslistType "/> 

< xs:complexType name =" personslistType "> 

< xs:element name =" menlist " type =" menlistType "/> 

< xs:element name =" womenlist " type =" womenlistType "/> 

 

< xs:complexType name =" menlistType "> 

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

 

< xs:complexType name =" womenlistType "> 

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

 

1 voir [4, 10, 15]







 

 

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. 

6.2 XQuery 

Tab. 6.1 – Qeulques expressions XPath 

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 

ou 

 

En ajoutant les attributs utiles, nous obtenons 

 

ou 

 

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 

 

dont l’attribut match permet de préciser le noeud ciblé. 

1 Voir le paragraphe 6.2.2


value-of permet d’extraire la valeur du noeud sélectionné. On utilise l’élement 

 

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 

 

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 

 

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


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 ," \ 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 ," \n"); 

// close the " xslt : transform " tag 

fclose ( filexsl ) 

// close the output file 

}


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 ," ") ; 

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



} 


" 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 


// close creation of attribute 

} 

else 

if( attribdst is an element ) then 

{ 

fwrite ( filexsl ," < attribdst >\n"); 

fwrite ( filexsl ," < xsl : value -of select =\" @attribsrc \"/ >\ 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.


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-


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, 

Shele 

Tsheke 

la fusion donnerait : 

ou encore 

Tsheke Shele 

Shele Tsheke 

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 

Shele Tsheke 

la séparation donnerait : 

Shele 

Tsheke 

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, 

Shele 

Tsheke 

la transformation donnerait : 

Tsheke 

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.


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 ) 

{ 


if " tagName is ’xs: element ’" then returnval := true ; 


} 

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 ) 

{ 


if " tagName is ’xs: attribute ’" then returnval := true ; 


} 

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 "); 

} 


} 

2 Voir le chapitre 5 pour la définition de schéma XSD


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 "); 

} 


} 

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 )


} 

} 

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

} 

} 

} 

} 


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


// run query 

elemlist := array (); 

// list of elements and attributes 

tmplst := array (); 

// the name of the current element and its attributes 

foreach ( elem in xpathquery ) 

{


} 

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


} 

} 

} 

{ 

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 


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


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 

 

 


< xs:element name =" listepersonnes " type =" typeListePersonnes "/> 

< xs:complexType name =" typeListePersonnes "> 

< xs:element name =" personne " type =" typePersonne "/> 

 

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

 

 

Fig. 8.1 – Page d’accueil de XML ETL 

Listing 8.2 – Données XML d’une source 

 

< listepersonnes > 

< personne datenais =" 2008 -12 -12 "> 

Johnny 

< nomdefamille >Tsheke 

français 

 

< personne datenais =" 2009 -06 -12 "> 

Pierre 

< nomdefamille > Manneback 

français 

 

< personne datenais =" 2004 -10 -08 ">


Esteban 

< nomdefamille > Zimanyi 

français 

 

 

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 

 

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



 

 

 

< xsl:template match =" personne "> 

 

< xsl:attribute name =" birthdate "> 

 

 

 

 

 

< xsl:template match =" prenom "> 

< firstname > 

 

 

 

Fig. 8.3 – Un choix d’une transformation


< xsl:template match =" nomdefamille "> 

< lastname > 

 

 

 

< xsl:template match =" langue "> 

 

 

 

 

 

Le code XSLT généré automatiquement (voir listing 8.3 p. 53) est ensuite appliqué aux données 

de la source (voir listing 8.2 p. 52) pour produire les données du listing 8.4 (p. 55) que l’on 

charge dans l’entrepôt. 

Listing 8.4 – Résultat du processus ETL du paragraphe 8.3 sur les données du listing 8.2 

 


 

< firstname >Johnny 

< lastname >Tsheke 

 

 

< firstname >Pierre 

< lastname > Manneback 

 

 

< firstname > Esteban 

< lastname > Zimanyi 

 

 

8.4 Un autre choix de correspondances 

Supposons à présent que l’on souhaite plutôt conserver une liste d’anniversaires dans 

l’entrepôt de données et que la source soit la même que celle du paragraphe 8.3. Le schéma 

de destination est celui du listing 8.5 (p. 55). 

Listing 8.5 – Schéma de destination du processus ETL du paragraphe 8.4 

 

 


< xs:element name =" listeanniv " type =" typeListeAnniv "/> 

< xs:complexType name =" typeListeAnniv "> 

< xs:element name =" anniv " type =" typeAnniv "/> 

 

< xs:complexType name =" typeAnniv "> 

< xs:element name =" dateanniv " type =" xs:date "/> 

< xs:element name =" nom " type =" xs:string "/>


 

 

En choisissant les correspondances comme à la figure 8.4, le système génère le fichier XSLT 

du listing 8.6 et transforme les données du listing 8.2 (p. 52) en celles qui sont dans le listing 

B.1. Les données extraites et transformées sont ensuite chargées dans l’entrepôt de données 

XML. 

Listing 8.6 – XSLT généré suite aux choix du paragraphe 8.4 

 

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

< listeanniv > 

 

 

 

< xsl:template match =" personne "> 

 

< dateanniv > 

 

 

 

 

 

< xsl:template match =" prenom "> 

 

 

 

 

< xsl:template match =" nomdefamille "> 

 

 

 

 

< xsl:template match =" langue "> 

 

 

 

 

 

Listing 8.7 – Résultats de l’ETL éxécuté au paragraphe 8.4 

 

< listeanniv > 

 

< dateanniv >2008 -12 -12 

Tsheke


 

 

< dateanniv >2009 -06 -12 

Manneback 

 

 

< dateanniv >2004 -10 -08 

Zimanyi 

 

 

Fig. 8.4 – Un autre choix de transformation

Chapitre 9 

Conclusions et perspectives 

9.1 Conclusions 

Dans les entrepôts de données XML, on acquiert les informations à partir des sources de 

données XML. Ces sources sont indépendantes et peuvent avoir chacune un schéma XSD à la 

fois différent des autres et de celui de l’entrepôt. Les données à stocker dans l’entrepôt doivent 

cependant être valides par rapport au schéma de l’entrepôt de données XML. 

Pour transférer les informations d’une source vers l’entrepôt, il faut les extraire puis les 

transformer pour qu’elles respectent les exigences du schéma de destination et les charger par 

la suite dans l’entrepôt de données XML. C’est ce qu’on appelle communément un processus 

ETL (Extract, Transform, Load). 

Le but de ce travail était de définir un processus ETL permettant d’alimenter un entrepôt 

de données XML à partir des sources de données XML. Il était aussi question de développer 

un prototype d’outil associé. 

Nous avons montré qu’une bonne conception d’un processus ETL de données XML pouvait 

résoudre, non pas seulement le problème d’approvisionnement des entrepôt de données XML, 

mais aussi beaucoup d’autres problèmes de transformation de format de données. Un petit 

rappel sur le langage XML a été donné en survol pour rafraichir les mémoires sur les concepts 

fondamentaux qu’on allait utiliser par la suite. 

Les bases de données XML, les entrepôts de données, les entrepôt de données XML et leurs 

fonctionnements ont été revus sans entrer trop en détail. Une petite comparaison entre un 

entrepôt de données XML et un entrepôt de données a été donnée tout en rappelant que la 

frontière entre les deux n’était pas très étanche. 

Nous avons regardé par la suite l’évolution du processus ETL tant sur le plan conceptuel 

que sur le plan logiciel. Quelques techniques et logiciels ont été parcourus pour donner une 

idée générale de ce qu’on peut trouver sur le marché. 

58

CHAPITRE 9. CONCLUSIONS ET PERSPECTIVES 59 

Après un bref rappel sur les schémas XML (XML schema - XSD), nous avons proposé 

quelques règles canoniques permettant d’écrire un fichier XSD plus compact. La préoccupation 

était de ne pas alourdir inutilement le processus ETL au cours de la manipulation des schémas 

source et destination. 

Sachant que si on a un fichier XSLT, on peut l’appliquer sur la source XML pour extraire et 

transformer les données, nous avons proposé un générateur automatique de fichier XSLT. La 

création de ce fichier se fait en fonction des schémas XSD source et destination. Ce concept 

de générateur automatique de fichier XSLT rend l’ETL utilisable tant dans les entrpôts de 

données XML que dans d’autres domaines comme les systèmes d’informations géographiques 

(Geographic Information System - GIS). 

Dans cet ouvrage, nous avons donné une implémentation quasi complète du noyau de l’ETL 

que nous avons défini. Les algorithmes ont été proposés en métalangage pour permettre au 

programmeur d’utiliser sa méthodologie et son langage de programmation favoris. 

Les algorithmes proposés ont été testés dans le prototype que nous avons développé en 

PHP5 sur un serveur apache. Un exemple d’application a d’ailleurs été donné pour montrer 

son fonctionnement. 

9.2 Perspectives 

Nous admettons que par manque de temps, nous n’avons pas pu optimiser toutes les fonctions 

proposées dans le cadre de ce travail de fin d’études. Les recherches futures éventuelles 

pourraient s’orienter vers : 

– l’optimisation des algorithmes ; 

– l’implémentation des opérateurs proposés à la section 6.6 (p. 41) ; 

– l’amélioration du générateur de fichier XSLT pour prendre en charge des cas où il y 

aurait une très grande différence entre les formes des arbres source et destination ; 

– l’étude de la possibilité d’insérer du code XQuery dans le fichier XSLT généré dans le 

cadre d’un processus ETL des données XML ; 

– la conception et l’implémentation d’une interface permettant à l’ETL de se connecter à 

la plupart des SGBD capables d’exporter/importer les données en XML ; 

– la conception d’une interface permettant de charger les données dans un entrepôt de 

données XML de manière incrémentale.

Bibliographie 

[1] Serge Abiteboul. Cours de XML et données semi-structurées. INRIA, 2005. http: 

//www-rocq.inria.fr/ ∼ abitebou/DEA-III. 

[2] Serge Abiteboul, Peter Buneman, and Dan Suciu. Data on the Web. From relations to 

semistructured data and XML. Morgan Kaufmann Publishers, 2000. 

[3] Akmal B. Chaudhri, Awais Rachid, and Roberto Zicari. XML Data Management : Native 

XML and XML Enabled Database Systems. Addison-Wesley Professional, 2003. 

[4] Pierre Gaspart. Cours de technologies XML -info370. ULB, 2006. http://www.sfp. 

ulb.ac.be. 

[5] Michael Kay. XSLT. Wrox Press Ltd, second edition, 2001. 

[6] Michael Kay. Comparing xslt and xquery. XTech 2005 Conference Proceedings, 2005. 

http://www.idealliance.org/proceedings/xtech05. 

[7] Michael Kay. Blooming flower - an introduction to the xquery flower expression. Stylus 

Studio, 2006. http://www.stylusstudio.com/whitepapers/blooming flower.pdf. 

[8] Brian Knight, Allan Mitchell, Darren Green, Douglas Hinson, Kathi Kellenberger, Andy 

Leonard, Erik Veerman, Jason Gerard, Haidong Ji, and Mike Murphy. Professional SQL 

Server 2005, Integration services. Wiley Publishing, Inc, 2007. 

[9] Casey Kochmer and Erica Frandsen. JSP and XML, Integrating XML and Web services 

in your JSP application. Addison-Wesley, 2002. 

[10] Pierre Manneback. Cours de technologies du web. FPMS, 2006. https://elearning. 

student.fpms.ac.be/. 

[11] Hiroshi Maruyama, Kent Tamura, and Naohiko Uramoto. XML and Java, Developing 

Web Applications. Addison-Wesley, 1999. 

[12] Brett McLaughlin. Java and XML. O’Reilly, second edition, 2001. 

[13] Erik T. Ray. Learning XML. O’Reilly, 2001. 

[14] Arizona State University. Asu data warehouse overview. Arizona State University, 2002. 

http://www.asu.edu/data admin/data warehouse-overview.html. 

[15] w3cschools. Xml schema tutorial. w3cschools, 2007. http://www.w3cschools.com. 

[16] Wikipédia. Extensible 3d. Wikipédia, 2007. http://fr.wikipedia.org/wiki/X3D. 

[17] Wikipédia. Extract, transform, load. Wikipédia, 2007. http://en.wikipedia.org/ 

wiki/Extract, transform, load. 

[18] Wikipédia. Xml database. Wikipédia, 2007. http://en.wikipedia.org/wiki/XML 

database. 

[19] Pierre Wolper. Cours de base de données. ULG, 2006. http://www.montefiore.ulg. 

ac.be/ ∼ pw. 

60

Annexe A 

Code PHP5 du prototype ETL 

développé 

A.1 Fichier index.php 

Ce fichier contient entre autre, le formulaire de chargement des schémas. 

Listing A.1 – Fichier Index.php 

 

 

 

XML ETL designed by Johnny Tsheke : si.fpms - code .ulb 

 

 

 

 

 

 

 

 

Upload source schema ( xsd file ) 

 

 

 

Upload destination schema ( xsd file ) 

 

 

 

Upload source data ( xml file ) 

61

ANNEXE A. CODE PHP5 DU PROTOTYPE ETL DÉVELOPPÉ 62 

 

 

 

 

 

 

 

 

 

 

 

XML ETL -- author : Johnny Tsheke Shele , si.fpms - code .ulb 

 

< frameset rows ="10% ,*" > 

 

< frameset cols ="30% ,* ,30%" > 

 

 

 

 

Pas moyen d’ afficher les frames 

 

 

 

 


A.2 Fichier viewsrc.php 

Ce fichier permet de visualiser l’arbre de la structure définie dans le schéma source. 

setxsdsrc (src ); 

trans -> setxsddst (dst ); 

trans -> loadschemas (); 

trans -> extractelem (" SRC "); 

trans -> extractelem (" DST "); 

srctree =" input /". strtok ( basename (trans -> xsdsrc ) ,".") .". xml "; 

dsttree =" input /". strtok ( basename (trans -> xsddst ) ,".") .". xml "; 

trans -> parseSchema (srctree ," SRC "); 

trans -> parseSchema (dsttree ," DST "); 

trans = null ; 

header (’ Location : input / srcxsd .xml ’); 

?> 

A.3 Fichier viewdst.php 

Ce fichier permet de visualiser l’arbre de la structure définie dans le schéma destination 

(entrepôt de données XML). 

Listing A.3 – Fichier viewdst.php 

setxsdsrc (src ); 

trans -> setxsddst (dst ); 

trans -> loadschemas (); 

trans -> extractelem (" SRC "); 

trans -> extractelem (" DST "); 

srctree =" input /". strtok ( basename (trans -> xsdsrc ) ,".") .". xml "; 

dsttree =" input /". strtok ( basename (trans -> xsddst ) ,".") .". xml "; 

trans -> parseSchema (srctree ," SRC "); 

trans -> parseSchema (dsttree ," DST "); 

trans = null ; 

header (’ Location : input / dstxsd .xml ’); 

?>


A.4 Fichier mapping.php 

Ce fichier permet de visualiser l’interface des correspondances. 

Listing A.4 – Fichier mapping.php 

initEtl (_POST [ nbsrcelem ]); 

?>

Annexe B 

Code source de la classe 

XmlTransform 

ANNEXE B. CODE SOURCE DE LA CLASSE XMLTRANSFORM 66 

{ 

if (! is_null (newname )) 

{ 

this -> xsdsrc =newname ; 

} 

// return this -> xsdsrc ; 

}// fin fonction setxsdsrc 

//---------------------------------------------------------/ 

// assignation du nom de fichier xsd destination / 

//-------------------------------------------------------- / 

function setxsddst (newname = NULL ) 

{ 

if (! is_null (newname )) 

{ 

this -> xsddst =newname ; 

} 

}// fin fonction setxsddst 

//--------------------------------------------------------------/ 

// La fonction suivante arrete la transformation en cas d’ erreur / 

//--------------------------------------------------------------/ 

function stopetl (message = NULL ) 

{ 

print (" ") ; 

print (" Error ... ") ; 

if (! is_null (message )) 

{ 

print (message ); 

} 

else { 

print (" No message received "); 

} 

print (" ETL stoped !!! ") ; 

print (" ") ; 

exit (1) ; 

} // fin stopetl 

//-------------------------------------------------------------/ 

// La fonction suivante test si un type passe en argument / 

// est simple cad built -in. Dans ce cas le systeme retourne true / 

// rapelons que les types built -in sont prefxes par xs: ou xsd : / 

// exemple : xs: string xs: integer .... / 

//-------------------------------------------------------------/ 

function isSimpleType (typeName = null ) 

{ 

returnval = false ; 

slength = strlen (typeName ); 

if(slength >3) 

{// le nom du type doit doit avoir plus de 3 caracteres 

if (( substr (typeName ,0 ,3) == "xs :") ||( substr (typeName ,0 ,4) == " 

xsd :") ) 

{


returnval = true ; 

} 

} 


} 

//--------------------------------------------------------------/ 

// la fonction suivante test une entree xs ou xsd pour voir si / 

// on definit un element / 

//--------------------------------------------------------------/ 

function isElement (tagName = null ) 

{ 


slength = strlen (tagName ); 


{// le nom du tag doit avoir plus de 9 caracteres 

if (( substr (tagName ,0 ,10) == "xs: element ") ||( substr (tagName ,0 ,11) 

== " xsd : element ")) 

{ 


} 

} 


} 

//--------------------------------------------------------------/ 

// la fonction suivante test une entree xs ou xsd pour voir si / 

// on definit un attribut / 

//--------------------------------------------------------------/ 

function isAttribute (tagName = null ) 

{ 


slength = strlen (tagName ); 


{// le nom du tag doit avoir plus de 11 caracteres 

if (( substr (tagName ,0 ,12) == "xs: attribute ") ||( substr (tagName 

,0 ,13) == " xsd : attribute ")) 

{ 


} 

} 


} 

//-------------------------------------------------------------/ 

// la fonction suivante return le nom de l’element , attribut / 

// ou complexType definie par le noeud (de xs: schema ) passe en / 

// argument / 

//-------------------------------------------------------------/ 

function elemName (node = null ) 

{returnval = null ; 

nm =" name "; 

if (!( is_null (node ))) 

{if(node -> hasAttributes ())


{ 

returnval =node -> getAttribute (nm ); 

} 

} 


}// fin de la fonction elemName 

//-------------------------------------------------------------/ 

// La fonction suivante returne le type d’un element definie / 

// dans le noeud (de xs: schema ) passe en argument / 

//-------------------------------------------------------------/ 

function elemType (node = null ) 

{returnval = null ; 

tp =" type "; 

if (!( is_null (node ))) 

{if(node -> hasAttributes ()) 

{ 

returnval =node -> getAttribute (tp ); 

} 

} 


}// fin de la fonction elemType 

//-------------------------------------------------------------/ 

// La fonction suivante retourne la liste des noms des tags / 

// fils directs ( attributs ) du noeud passe en argument ( ainsi / 

// que les attributs / 

//-------------------------------------------------------------/ 

function sonsAndAttributes (xpath =null ,node = null ) 

{ //xpath est le DOMpath d’ou vient le noeud node 

tagName = null ;// le nom du noeud 

elemName = null ;// le nom de l’ element defini par le tag 

sonName = null ; // le noeud d’un element fils si possible 

attName = null ; // le nom d’un attribut si possible 

elemType = null ;// type de l’ element 

returnval = null ; // tableau array des noms a renvoyer 

if (!(( is_null (node )) ||( is_null (xpath )))) 

{// si un noeud et un chemin sont passes en argument 

if(this -> isElement (node -> tagName )) 

{ 

elemName =this -> elemName (node ); 

returnval []= elemName ; // nom de l’ element 

elemType =this -> elemType (node ); 

if (!(this -> isSimpleType (elemType ))) 

{// si pas type simple alors type complexe . 

// on cherche les fils dans la definition du type 

// selectionner la defintion du schema de 

//l’ element xs: complexType 

query ="// xs: complexType [ @name =’elemType ’]/*";


xpathquery =xpath -> query (query ); 

// extraction des element fils et attributs 

foreach (xpathquery as son ) 

{ 

sonTagName = son -> tagName ; 

sonName =this -> elemName (son ); 

{ 

else 

{ 

} 

} 

if(this -> isElement (sonTagName )) 

// possibilite de traiter les elements fils direct 

} 

if(this -> isAttribute (sonTagName )) 

{ 

returnval []=" elemName /[ @sonName ]"; 

} 

} 

} 

} 


} // fin de la fonction sonsAndAttributes 

//-------------------------------------------------------------/ 

// La fonction suivante charge les schemas src et dst dans les / 

// document XML DOM ( php5 ) en vue de les traiter comme dans / 

// dans un parser / 

//-------------------------------------------------------------/ 

function loadschemas () 

{ 

if (( is_null (this -> xsdsrc )) ||( is_null (this -> xsddst ))) 

{ 

this -> stopetl (" source and /or destination schema unknown "); 

} 

if ((! file_exists (this -> xsdsrc ))) 

{ 

print (" The source schema ".this -> 

xsdsrc . " does not exists "); 

exit (1) ; 

} 

if ((! file_exists (this -> xsddst ))) 

{ 

print (" The schema ".this -> xsddst 

. " does not exists "); 

exit (1) ; 

}


this -> xmlsrcdoc = new DOMDocument (); 

this -> xmlsrcdoc -> validateOnParse = true ; 

this -> xmldstdoc = new DOMDocument (); 

this -> xmldstdoc -> validateOnParse = true ; 

// chargement du schema source 

if (!this -> xmlsrcdoc -> load (this -> xsdsrc )) 

{ 

this -> stopetl (" cannot load ".this -> xsdsrc ); 

} 

if (!this -> xmldstdoc -> load (this -> xsddst )) 

{ 

this -> stopetl (" cannot load ".this -> xsddst ); 

} 

// creation de DOM path 

this -> xpathsrc = new DOMXPath (this -> xmlsrcdoc ); 

this -> xpathdst = new DOMXPath (this -> xmldstdoc ); 

}// fin loadschemas 

//-----------------------------------------------------------------/ 

// La fonction suivante initialise le document de travail 

/ 

//-----------------------------------------------------------------/ 

function initDoc (srcordst = null ) 

{ 

src =" SRC "; 

dst =" DST "; 

xmldoc = null ; 

if (( strcasecmp (srcordst ,src ) !=0) &&( strcasecmp (srcordst ,dst ) 

!=0) ) 

{ 

this -> stopetl (" argument of initDoc must be: SRC or DST "); 

} 

// si on cherche a extraire les elements de la source 

if( strcasecmp (srcordst ,src ) ==0) 

{ 

xmldoc =this -> xmlsrcdoc ; 

} 

else 

{// si on cherche a extraire les elements de la destination 

xmldoc =this -> xmldstdoc ; 

} 

return xmldoc ; 

} // fin initDoc 

//-----------------------------------------------------------------/


// La fonction suivante initialise le xpath de travail 

/ 

//-----------------------------------------------------------------/ 

function initXpath (srcordst = null ) 

{ 

src =" SRC "; 

dst =" DST "; 

xpath = null ; 

if (( strcasecmp (srcordst ,src ) !=0) &&( strcasecmp (srcordst ,dst ) 

!=0) ) 

{ 

this -> stopetl (" argument of initXpath must be: SRC or DST "); 

} 

// si on cherche a extraire les elements de la source 


{ 

xpath =this -> xpathsrc ;// chemin du schema source 

} 

else 


xpath =this -> xpathdst ;// chemin du schema destination 

} 

return xpath ; 

} // fin initXpath 

//------------------------------------------------------------------/ 

// La fonction suivante extrait les elements ( attribut ) du documents 

/ 

// et les place dans un tableau 

/ 

//------------------------------------------------------------------/ 

function extractelem (srcordst = NULL ) 

{xmldoc = NULL ; 

xmldoc = NULL ; 

returnval = array () ;// tableau des elements / attributs extrait du 

document 

src =" SRC "; 

dst =" DST "; 

xsdSchema =" xsd : schema ";// noeud special indiquant un schema xsd 

rootNode = NULL ; 

xmldoc =this -> initDoc (srcordst ) ;// initialisation document de 

travail 

xpath =this -> initXpath (srcordst ) ;// xpath de travail 

rootNode =xmldoc -> documentElement ; 

rootNodeName =rootNode -> tagName ; 

sons =rootNode -> childNodes ;


// extraire toutes les declaration d’ elements 

query ="// xs: element [ @name ]"; 


nb =xpathquery -> length ; 

elemlist = array (); 

foreach (xpathquery as elem ) 

{ 

tmlst =this -> sonsAndAttributes (xpath ,elem ); 

elemlist = array_merge (elemlist ,tmlst ); 

} 


{// si on cherche a extraire les elements de la source 

this -> srcelemlist =elemlist ; 

} 

else 


this -> dstelemlist =elemlist ; 

} 

}// fin de la fonction extractelem 

//-------------------------------------------------------/ 

// La fonction suivante fait le parsing du noeud / 

// on fait un appel recursif s’il y a des fils eventuels / 

//-------------------------------------------------------/ 

function parseNode (file =null ,node =null ,prefix =null ,xpath = null ) 

{ 

// prefix est le prefixe de xml schema . ex: xsd , xs 

newtag = null ; // tag a cree dans le fichier 

if (( is_null (node )) ||( is_null (file )) ||( is_null (prefix )) ||( 

is_null (xpath ))) 

{ 

this -> stop (" Argument incorrects a la fonction parseNode "); 

} 

tagName =node -> tagName ; 

if(this -> isElement (tagName )) 

{// si c’est noeud element xs: element 

elemName =this -> elemName (node ) ;// le nom de l’ element 

newtag =elemName ;// le nom du tag . on doit encore trouver 

// les attrubutseventuels 

elemType =this -> elemType (node ); 

if(this -> isSimpleType (elemType )) 

{// Si un element de type simple 

fwrite (file ," \n"); 

} 

else { 

// si un element de type complex 

query ="//". prefix .": complexType [ @name =’elemType ’]//". prefix .":


attribute [ @name ]"; 

attributes =xpath -> query (query ); 

// on vient de recuperer tous les attributs 

attlst = null ; 

foreach (attributes as attribute ) 

{// recuperation de la liste des attributs 

atname =this -> elemName (attribute ); 

attype =this -> elemType (attribute ); 

attlst =attlst ." ".atname ."=\"". attype ."\""; 

} 


// on va maintenant recuperer les elements fils 

query ="//". prefix .": complexType [ @name =’elemType ’]//". prefix 

.": element [ @name ]"; 

elements =xpath -> query (query ); 

foreach (elements as element ) 

{ 

this -> parseNode (file ,element ,prefix ,xpath ); 

} 

} 


} 

else 

{// si pas un noued element 

if(node -> hasChilds ()) 

{ // Si le noeud a des fils on fait un appel recursif 

// ceci permet de couvrir les cas de par 

exemple 

children =node -> childNodes ; 

foreach (children as child ) 

{ 

parseNode (file ,child ,prefix ,xpath ); 

} 

} 

} 

}// fin parseNode 

//-------------------------------------------------------/ 

// La fonction suivante cree un fichier xml compose / 

// uniquement des tags et de l’ eborescente correspondant / 

// au fichier xsd passe en argument / 

//-------------------------------------------------------/ 

function parseSchema (outputfile =null ,srcordst = null ) 

{ 

xmldoc = null ; 


filename = null ; 

prefix =" xs :";// prefix xsd 

if( is_null (outputfile )) 

{


this -> stop (" Il faut specifier le nom du fichier de sortie "); 

} 

filename =outputfile ; 

xmldoc =this -> initDoc (srcordst ) ;// initialisation document 

de travail 

xpath =this -> initXpath (srcordst ) ;// xpath de travail 

// extraction du prefix 

rootNode =xmldoc -> documentElement ; 

rootName =rootNode -> tagName ; 

prefix = strtok (rootName ,":") ; // prefixe utiliser dans le 

fichier xsd 

query ="//". prefix .": schema /". prefix .": element [ @name ]"; 

rootNode = null ; // liberation de la memoire 


if (( is_null (xpathquery )) ||( xpathquery -> length stop (" Aucun element declar~A dans ce fichier xml schema ") 

; 

} 

file = fopen ("filename " ,"w") ;// descripteur de fichier 

fwrite (file ," \ n"); 

fwrite (file ," parseSchema -->\n"); 

rootElem =xpathquery -> item (0) ; 

// parsing de l’ element 

this -> parseNode (file ,rootElem ,prefix ,xpath ); 

fclose (file ); 

xmldoc = null ;// liberation de la memoire 


} // fin de la fonction parseSchema 

//--------------------------------------------------------/ 

// La fonction suivante affiche l’ interface d’ equivalence / 

// c’est ici que l’ utilisateur choisi les correspondances / 

// des elements / 

// on suppose que les noms des elemenst / attributs de / 

// de la source et de la destionation sont deja extraits / 

//--------------------------------------------------------/ 

function mapping (srctree ,dsttree ) 

{ 

nbsrcelem = null ; // nombre d’ element / attributs definis dans le 

schema source 

nbdstelem = null ; // nombre d’ element / attributs definis dans le 

schema destination 

if (( is_null (this -> srcelemlist )) ||( is_null (this -> dstelemlist ))) 

{


this -> stop (" Elements not extratced yet "); 

} 

else { 

nbdstelem = count (this -> dstelemlist ); 

nbsrcelem = count (this -> srcelemlist ); 

echo "< form method =\" post \" action =\" mapping . php \" >"; 

echo "< table cellspacing =3 cellpadding =0 border =1 >"; 

echo ""; 

echo " FROM "; 

echo "TO "; 

echo " "; 

for (i =0;i dstelemlist [j ]." "; 

} 

echo " "; 

echo " "; 

echo " "; 

} 

echo " "; 

echo " "; 

echo "< input type =\" hidden \" name =\" nbdstelem \" value =\" nbdstelem 

\" >"; 

echo "< input type =\" hidden \" name =\" nbsrcelem \" value =\" nbsrcelem 

\" >"; 

echo "< input type =\" hidden \" name =\" srctree \" value =\" srctree 

\" >"; 

echo "< input type =\" hidden \" name =\" dsttree \" value =\" dsttree 

\" >"; 

echo "< input type =\" submit \" name =\" submit \" value =\" Transforme 

\" >"; 

echo " "; 

} 

}// fin de la fonction mapping 

//--------------------------------------------------------------/ 

// La fonction suivante effectue l’ extraction et la transformation / 

// selon les equivalances choisies par l’ utilisateur dans mapping / 

//---------------------------------------------------------------/ 

function extractTransform (datafile ,nbelem =null ,dsttree = null ) 

{


mapping = array (); 

outfilexsl = null ; // nom du fichier xsl resultant 

filexsl = null ;// descripteur de fichier xsl 

//nbelem est le nombre maximum d’ element de produire 

for (i =0;i load (datafile ); 

outfilexsl = strtok (dsttree ,".") .". xsl "; // fichier xsl resultant 

filexsl = fopen (outfilexsl ,"w"); // ouverture du fichier en 

ecriture 

// ecriture des entetes xsl 

fwrite (filexsl ," \ n 

"); 

fwrite (filexsl ," < xsl : transform xmlns : xsl =\" http :// www .w3.org 

/1999/ XSL / Transform \" version =\"1.0\" >\ n"); 

fwrite (filexsl ," < xsl : output method =\" xml \" encoding =\" ISO 

-8859 -1\"/ >\ n"); 

// generer le contenu xsl ici 

ne =0; 

while (ne 0) 

{ 

//s’il y a un element correspondant 

fwrite (filexsl ," \n"); 

} 

j =1; 

stop = false ; 

while (((ne +j)


// regarde s’il faut transformer les attribut de l’ element 

en cours 

// de traitement 

attribpos = strpos (elsrclst [ne +j ] ,"/") ; 

if(attribpos !== false ) 

{ 

// si l’ element suivant est un attribut , on regarde s’il se 

transforme 

// ~A un attribut ou un element 

ind =ne +j; // indice de l’ attribut 

start =attribpos +3; 

atln = strlen (elsrclst [ind ]) -start -1;// on elenve le 

dernier caractere [ 

attribsrc = substr (elsrclst [ind ],start ,atln ); 

attribdstpos = strpos (eldstlst [ne +j ] ,"/") ; 

if(attribdstpos !== false ) 

{ 

start =attribdstpos +3; 

atln = strlen (eldstlst [ind ]) -start -1;// on elenve le 

dernier caractere [ 

attribdst = substr (eldstlst [ind ],start ,atln ); 

if(eldstln >0) 

{ 

// l’ attribut se transforme ~A un attribut 

fwrite (filexsl ," < xsl : attribute name =\" attribdst \" >\n"); 

fwrite (filexsl ," < xsl : value -of select =\" @attribsrc 

\"/ >\ n"); 


} 

} 

else 

{ 

// l’ attribut se transforme 

ind =ne +j; 

if (( strlen (eldstlst [ind ])) >0) 

{ 

~A un element 

//s’il 

} 

j ++; 

y a effectivement un element correspondant 


fwrite (filexsl ," < xsl : value -of select =\" @attribsrc 

\"/ >\ n"); 


} 

} 

else 

{ 

// l’ element 

stop = true ; 

} 

suivant n’est pas un attribut et on arrete


} 

if(eldstln >0) 

{ 

//s’il y a un element correspondant 

fwrite (filexsl ," < xsl : apply - templates / >\n"); 


} 

else 

{ //s’il n’y a aucun element correspondant a l’ element en cours 

de traitement 

fwrite (filexsl ," < xsl :if test =\" child ::*\" >\ n"); 

fwrite (filexsl ," < xsl : apply - templates / >\n"); 


} 


ne =ne +j; 

} 

// fin contenu xsl 


fclose (filexsl ); 

// on va maintenant applique le fichier xsl sur l’ arbre 

outputdata =" output /". strtok ( basename (datafile ) ,".") ." etl . xml ";// 

donnees tranformees 

// Attention : la partie suivante est specifique a php5 

// nouvelle instance du processeur xslt 

xslt = new XSLTProcessor (); 

// chargement du fichier XSLT 

xsl = new DOMDocument (); 

xsl -> load (outfilexsl ); 

// importation de xsl 

xslt -> importStylesheet (xsl ); 

// on applique la transformation sur le fichier data 

if(xslt -> transformToUri (docdata ,outputdata )) 

{ 

echo " Data \" ETLed \" successfully "; 

//--- AFFICHAGE DES FICHIERS GENERES PAR L’ OUTIL ETL ----/ 

echo "< center >"; 

echo " Click on the link for wich you want to see / download the file 

"; 

echo " Source schema tree "; 

echo " Destination schema tree "; 

echo " XSL generated by the ETL tool "; 

echo " Input data file "; 

echo " Output data file ( from ETL tool ) 

"; 

echo " "; 

}


} // fin de la fonction extractTransform 

//--------------------------------------------/ 

// La fonction suivante initialise les operations ETL / 

//---------------------------------------------/ 

// function initEtl (nbdstelem = null ) 

function initEtl (nbsrcelem = null ) 

{ 

?> 

 

XML ETL -- author : Johnny Tsheke , si.fpms - code .ulb 

 

 

 Mapping Interface 

 

xsddst ) ,".") ." xsd . xml 

"; 

this -> parseSchema (srctree ," SRC "); 

this -> srctree =srctree ; 

this -> parseSchema (dsttree ," DST "); 

this -> dsttree =dsttree ; 

//---- fin parseschema --- 

this -> mapping (srctree ,dsttree ); 

} 

else 

{ // Effectuer l’ extraction et la transformation 

// suivi du chargement 

dsttree =_POST [ dsttree ]; // arbre de destination 

//this -> extractTransform (" personcd2 . xml ",nbdstelem ,dsttree ); 

//this -> extractTransform (" personcd2 . xml ",nbsrcelem ,dsttree ) 

; 

this -> extractTransform (" input / srcdata . xml ",nbsrcelem ,


} 

dsttree ); 

} 

}// fin de la fonction initEtl 

//************************************************** 

// FIN CLASSE XMLTRANSFORM * 

//************************************************** 

trans = new XmlTransform ;// objet de transformation 

?>

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

Create successful ePaper yourself

Delete template?

Save as template?