Requêtes OLAP sur une base de données XML native - Cercle ...

Faculté des Sciences
Département d’Informatique
Requêtes OLAP sur une base de données XML
native
Boris Verhaegen
Mémoire présenté sous la direction du Prof. Esteban Zimányi
en vue de l’obtention du grade de Licencié en Informatique
Année académique 2005–2006

Remerciements
Je tiens à remercier tout particulièrement Esteban Zimányi, mon promoteur, pour m’avoir
aidé à trouver ce thème intéressant et pour ses nombreux encouragements, impulsions, relectures
et corrections.
Merci également à mes jurés, Gianluca Bontempi et Roel Wuyts ainsi qu’au président du
jury, Raymond Devillers, qui prendront du temps pour lire et évaluer ce document.
Je voulais aussi exprimer ma gratitude envers ma famille et mes amis pour leur confiance et
leur soutien, tout particulièrement envers mon père pour ses relectures et corrections orthographiques
et grammaticales.
Enfin, je tiens à exprimer ma reconnaissance aux développeurs du logiciel libre eXist, Wolfgang
Meier et Pierrick Brihaye, pour leur sympathie et leurs explications.

TABLE DES MATIÈRES iii
Table des matières
Remerciements ii
1 Introduction 1
2 Les entrepôts de données 3
2.1 Motivations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Définitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3 Le modèle multidimensionnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3.1 Notions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3.2 Modèles de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4 Collecte et intégration des données . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.5 Analyse des données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.6 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3 Les documents XML 13
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2 Historique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3 Motivations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.4 Le document XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.4.1 Les outils de base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.4.2 Notions générales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.4.3 Types de documents XML . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.4.4 Les éléments, ses attributs et les données textuelles . . . . . . . . . . . . . 18
3.4.5 L’espace de nom . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.5 Les DTD et les Schémas XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.6 Modélisation des documents XML . . . . . . . . . . . . . . . . . . . . . . . . . . 22

TABLE DES MATIÈRES iv
3.6.1 Ordres . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.6.2 SAX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.6.3 Infoset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.6.4 DOM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.6.5 Modèle de données XQuery . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.7 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4 Les langages d’interrogation XML 27
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.2 XPath . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.2.1 Les axes XPath . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.3 XQuery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.3.2 Expressions FLWR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.3.3 Quantificateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.3.4 Opérateurs de comparaison d’ordre . . . . . . . . . . . . . . . . . . . . . . 33
4.3.5 Fonctions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.3.6 Traitement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.3.7 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.4 Autres langages d’interrogation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.4.1 XSLT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.4.2 Lorel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.4.3 CDuce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.4.4 SQL/XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.5 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

TABLE DES MATIÈRES v
5 Les bases de données XML 40
5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.2 Types de bases de données XML . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.2.1 Bases de données relationnelles . . . . . . . . . . . . . . . . . . . . . . . . 41
5.2.2 Bases de données objet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.2.3 Bases de données XML natives . . . . . . . . . . . . . . . . . . . . . . . . 42
5.3 Bases de données XML natives . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.3.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.3.2 Utilisations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.3.3 Systèmes existants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.3.4 Indexation des documents XML . . . . . . . . . . . . . . . . . . . . . . . 45
5.3.5 Traitement des requêtes grâce aux indexes . . . . . . . . . . . . . . . . . . 55
5.4 eXist, une base de données XML native libre . . . . . . . . . . . . . . . . . . . . 58
5.4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.4.2 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.4.3 Indexation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.4.4 Traitement des requêtes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.5 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
6 Les entrepôts de données XML natifs 70
6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
6.2 Systèmes d’analyse (OLAP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
6.2.1 Sources et résultats en XML . . . . . . . . . . . . . . . . . . . . . . . . . 71
6.2.2 Systèmes natifs XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
6.3 Besoins d’un système OLAP basé sur XML . . . . . . . . . . . . . . . . . . . . . 74
6.3.1 Modélisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
6.3.2 Indexation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
6.3.3 Langage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
6.4 Le test TPC-H . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
6.4.1 Traduction des données sources . . . . . . . . . . . . . . . . . . . . . . . . 77
6.4.2 Traduction des requêtes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
6.5 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

TABLE DES MATIÈRES vi
7 Les groupements en XQuery 84
7.1 Base de données source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
7.2 Requêtes d’analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
7.2.1 Opérateur GROUP BY en SQL . . . . . . . . . . . . . . . . . . . . . . . . . 86
7.3 Groupements en XQuery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
7.4 Scénario d’évaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
7.4.1 Méthodes d’évaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
7.4.2 Génération de l’échantillon . . . . . . . . . . . . . . . . . . . . . . . . . . 93
7.4.3 Conditions du test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
7.4.4 Mesures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
7.4.5 Paramètres . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
7.4.6 Requêtes effectuées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
7.5 Analyse des résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
7.6 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
8 Conclusions et travaux futurs 100
8.1 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
8.2 Travaux Futurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

Chapitre 1
Introduction
Le but de ce mémoire est d’analyser la possibilité de créer des outils d’analyse (OLAP) sur
un entrepôt de données, le tout entièrement en XML.
Cela sous-entend plusieurs parties. Tout d’abord, nous étudierons les différentes techniques
de gestion des données XML via des bases de données. Ensuite, nous analyserons les rares articles
scientifiques publiés au sujet des entrepôts de données et des systèmes d’analyse XML. Pour finir,
nous identifierons les besoins d’un tel système et nous émettrons quelques propositions afin d’y
répondre.
Le second chapitre traite des entrepôts de données. Nous analyserons les notions nécessaires
à leur compréhension comme la modélisation multidimensionnelle. Nous étudierons ensuite les
systèmes gravitant autour de l’entrepôt de données, c’est-à-dire les outils d’intégration de données
(ETL) ainsi que les outils d’analyse (OLAP et forage de données).
Dans le troisième chapitre, nous introduirons le langage de balisage extensible XML. Nous
commencerons par un historique expliquant son évolution et ensuite, nous expliquerons les notions
essentielles de ce langage, nécessaires à la compréhension de ce mémoire, comme les différentes
modèles de données XML.
Ensuite, dans le quatrième chapitre, nous analyserons en détail les différents langages d’interrogation
pour XML en nous focalisant sur XPath et XQuery, deux langages très prometteurs
dans le domaine des bases de données XML.
Le cinquième chapitre consiste en une analyse des différents types de bases de données
permettant de gérer des documents XML. Nous nous attarderons principalement sur les bases
de données XML natives en accordant une grande importance aux techniques d’indexation des
documents XML ainsi qu’aux algorithmes associés. Pour finir, nous introduirons eXist, un moteur
de base de données XML natif libre implémentant XQuery, que nous utiliserons par la suite dans
ce mémoire.
Dans le sixième chapitre, nous identifierons les besoins d’un entrepôt de données XML natif
et tout particulièrement ceux d’un système d’analyse organisé sur une base de donnée XML
native. Nous les étudierons selon les points de vue modélisation, indexation et langage, en nous
concentrant sur ce dernier.
1

Le septième et dernier chapitre est dédié aux groupements de données XML à l’aide de
XQuery. Nous y découvrirons que ce langage ne possède pas d’opérateur de groupement par
valeur et nous analyserons le gain qu’un tel opérateur permettrait d’obtenir via une évaluation
de performances.
2

Chapitre 2
Les entrepôts de données
Dans ce chapitre, nous présentons les entrepôts de données et les concepts nécessaires à leur
compréhension. Nous détaillons également les différents outils nécessaires à la construction et à
l’utilisation de ce type particulier de base de données.
Contenu
2.1 Motivations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Définitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3 Le modèle multidimensionnel . . . . . . . . . . . . . . . . . . . . . . . 5
2.4 Collecte et intégration des données . . . . . . . . . . . . . . . . . . . . 10
2.5 Analyse des données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.6 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.1 Motivations
Les entreprises, de par leur taille importante et leur ancienneté ont de plus en plus de
difficultés à accéder à l’ensemble de leurs données, à regrouper leurs différentes bases de données
disséminées dans leurs différents services afin de les analyser et de prendre des décisions rapidement.
Dans la grande distribution, par exemple, on aimerait déterminer les produits à succès, les
modes, les habitudes d’achat des consommateurs globalement ou par secteur géographique. Dans
le domaine des services tels que les banques, les entreprises de télécommunication, les assurances
et mutualités, on aimerait pouvoir classifier les clients, détecter des fraudes ou les clients qui
risquent d’être infidèles, etc.
Pour réaliser ces analyses facilement et rapidement, il convient de rassembler toutes les informations
de l’entreprise dans une base unique, spécialement conçue pour l’analyse : un entrepôt
de données (data warehouse). Celui-ci doit par exemple permettre aux décideurs de visualiser des
données agrégées suivant différents critères : axes temporels, géographiques, types de produits,
. . .
3

2.2 Définitions 4
2.2 Définitions
Un entrepôt de données (data warehouse) est un lieu de stockage intermédiaire de différentes
données en vue de la constitution d’un système d’informations décisionnelles. Un des précurseurs
du concept d’entrepôt de données, Bill Inmon [1], le définit comme suit :
« Un entrepôt est une collection de données orientées sujet, intégrées, non volatiles
et historisées, organisées pour le support d’un processus d’aide à la décision. »
Analysons point par point cette définition. Les données d’un entrepôt sont donc :
⊲ Orientées sujet Les données sont orientées métier et donc triées par thèmes. L’intégration
dans une structure unique est indispensable pour éviter aux données concernées par
plusieurs sujets d’être dupliquées. Cependant, dans la pratique, il existe également des
entrepôts plus petits, les magasins de données (data marts) : l’entrepôt est fragmenté en
plusieurs bases qui supportent l’orientation sujet.
⊲ Intégrées Les données proviennent de plusieurs sources hétérogènes. Avant d’être intégrées
dans l’entrepôt, les données doivent êtres mises en forme et unifiées afin d’avoir un
état cohérent. Cela nécessite un gros travail de normalisation, de gestion des référentiels
et de cohérence.
⊲ Non volatiles Les données sont stables et non modifiables. Un entrepôt de données doit
garantir qu’une requête lancée à différentes dates sur les mêmes données donne toujours
les mêmes résultats. De plus, les données d’un entrepôt sont mise à jour périodiquement,
ce ne sont donc pas des informations en temps réel.
⊲ Historisées Les données sont historisées et donc datées : l’historisation est nécessaire
pour suivre dans le temps l’évolution des différentes valeurs des indicateurs à analyser.
Ainsi, un référentiel temps doit être associé aux données afin de permettre l’identification
de valeurs précises dans la durée.
Un entrepôt est donc une sorte de point focal stockant en un point unique toute l’information
utile provenant des systèmes de production et des sources externes. Avant d’être intégrée,
l’information doit être extraite des différentes sources et nettoyée.
Ralph Kimball, l’auteur de The Data Warehouse Toolkit [2], propose une autre définition :
« A data warehouse is a copy of transaction data specifically structured for query
and analysis. »
« Un entrepôt de données est une copie de données transactionnelles spécifiquement
structurée pour l’interrogation et l’analyse. »
Un entrepôt de données, comme indiqué dans les motivations, doit permettre l’analyse de
données suivant plusieurs dimensions. Il convient donc d’utiliser un modèle multidimensionnel.
Avant de pouvoir intégrer les données, il faut concevoir intelligemment l’entrepôt en fonction
des analyses que l’on veut pouvoir réaliser.
Trois fonctions essentielles sont donc nécessaires pour créer et utiliser un entrepôt :

2.3 Le modèle multidimensionnel 5
Sources
Bases de
données
diverses
Fichiers
Internet
Extraction,
Transformation,
Chargement
(ETL)
Analyse de
données
(OLAP)
Entrepôt de données
Fig. 2.1 – Architecture d’un entrepôt de données.
Forage de
données
(data mining)
⊲ la collecte de données des différentes sources d’informations et leur intégration
⊲ l’organisation des données dans l’entrepôt
⊲ l’analyse de données pour la prise de décision en interaction avec les analyses.
Une vision schématique de l’architecture nécessaire à un entrepôt de données est illustrée à
la figure 2.1. Les chapitres suivants introduisent ces concepts.
2.3 Le modèle multidimensionnel
Comme nous l’avons vu en début de chapitre, un entrepôt de données est orienté sujet
et doit permettre d’analyser des données suivant plusieurs dimensions. Les bases de données
multidimensionnelles, à la différence des bases de données relationnelles classiques permettent
d’effectuer des traitements sur des données en prenant en compte plus de deux axes : les données
ne sont pas modélisées sous forme tabulaire mais sous forme d’hyper-cubes (ou « cubes de
données » ou encore « data cubes »).
Ces structures sont essentiellement utilisées par des analystes qui cherchent à trouver des
tendances dans de grandes quantités de données. Par exemple, rechercher les facteurs de risques
(âge, sexe, traitement, . . . ) de maladies pour une étude médicale, caractériser des données (type
d’objet, siècle, . . . ) dans le cadre de fouilles archéologiques ou déterminer des corrélations entre
produits-magasin-vendeur pour le directeur de ressources humaines de chaînes de distribution.

2.3 Le modèle multidimensionnel 6
2.3.1 Notions
Un sujet est défini par un ensemble de mesures et un ensemble de dimensions. Par exemple,
les mesures d’une vente peuvent être son numéro, son prix et sa quantité : ce sont les valeurs
numériques que l’on veut comparer. Les dimensions seraient la date, le type de produit et la
région : ce sont les points de vue depuis lesquels les mesures peuvent être observées.
Une dimension est une liste d’éléments organisés de façon hiérarchique. La granularité d’une
dimension est son nombre de niveaux hiérarchiques. Par exemple, pour le temps, nous pourrions
avoir la hiérarchie suivante : année, semestre, trimestre, mois, semaine, jour, soit six niveaux.
Les axes de dimensions doivent fournir des règles de calculs d’agrégat pour chaque mesure.
Par exemple, le nombre de ventes du premier trimestre est la somme du nombre de ventes
de janvier, février et mars. Les dimensions sont stockées dans des tables de dimensions qui
contiennent les niveaux hiérarchiques des dimensions ainsi que les formules à appliquer sur les
données numériques (les faits) pour passer d’un niveau à un autre. Certains cas spéciaux sont
à gérer si les dimensions sont organisées en hiérarchies multiples : les magasins d’une entreprise
peuvent être organisées par ville, par province, par secteur ou par région de vente. Une région
de vente peut regrouper certaines villes de provinces différentes. Elzbieta Malinowski et Esteban
Zimányi ont fait une étude complète des différents types de hiérarchies de dimensions dans [3].
Un fait représente la valeur d’une mesure, mesurée ou calculée, selon un membre de chacune
des dimensions. Par exemple, « 10000 » est un fait qui exprime la valeur de la mesure « coût
des travaux » pour le membre « 2002 » du niveau « année » de la dimension « temps » et
le membre « Bruxelles » du niveau « ville » de la dimension « géographie ». Les mesures sont
stockées dans des tables de faits qui contiennent les valeurs des mesures et les clés vers les tables
de dimensions.
Dimension Temps
PK jour
semaine
mois
trimestre
année
Dimension Produit
PK id_produit
nom_produit
id_categorie
nom_categorie
id_famille
nom_famille
Fait Vente
PK id_vente
nombre
montant
FK1 id_produit
FK2 jour
FK3 id_vendeur
FK4 id_magasin
Dimensions Vendeurs
PK id_vendeur
nom_vendeur
groupe
departement
Dimension Géographie
PK id_magasin
nom_magasin
commune
region
pays
Fig. 2.2 – Modélisation d’un entrepôt à l’aide d’un schéma en étoile.
A titre d’illustration, observons le schéma relationnel de la figure 2.2. La table placée au centre
représente les faits et leurs mesures respectives : nombre et montant. Les quatre tables gravitant

2.3 Le modèle multidimensionnel 7
autour de la table des faits représentent les dimensions : temps, géographie, produit et vendeur.
Chaque table de dimension contient les différents niveaux de la hiérarchie de dimension. Pour la
dimension géographique, représentée figure 2.3, nous avons 4 niveaux de granularité : le magasin,
sa commune, sa région et son pays. Il s’agit ici d’une hiérarchie de dimension symétrique, c’est
à dire qu’un magasin n’est inclus dans une seule commune, une commune dans une seule région
et ainsi de suite.
Géographie Magasins Communes Régions Pays
Fig. 2.3 – Hiérarchie symétrique d’une dimension géographique.
Ces différents mécanismes nous permettront de placer les données dans des matrices multidimensionnelles
appelées cubes. Un exemple d’un tel cube est présenté à la figure 2.4 Ces cubes
sont parfois appelés hyper-cubes s’il y a plus de 3 dimensions. Les données pourront être interrogées
directement et facilement sur n’importe quelle combinaison de dimensions, sans utiliser de
requêtes trop complexes. Passer d’une hiérarchie de dimension à une autre est réalisée facilement
dans un cube de données par la technique de pivot, de rotation. Par cette technique, le cube peut
être pivoté pour afficher différentes orientations des axes. Par exemple, on peut pivoter un cube
pour afficher les régions en lignes, les trimestres en colonnes et les produits dans la troisième
dimension. Cette technique est équivalente à avoir une table de vente par région pour chaque
produit, où chaque table affiche les ventes par trimestre et par région du produit.
clavier
2003
2004
2005
souris
écran
120 230 210
132 198 256
145 259 237
Bruxelles Wallonie Flandre
78 176 142
137 258 232
Régions
276 187
245 196
Produits
Fig. 2.4 – Représentation d’un cube de données.
Les opérations slice et dice permettent respectivement d’extraire une tranche du cube et un
sous-cube selon des prédicats sur les dimensions. Ces opérations sont illustrées respectivement
aux figures 2.5 et 2.6.
Années

2.3 Le modèle multidimensionnel 8
clavier
2003
2004
2005
2003
2004
2005
souris
écran
120 230 210
132 198 256
145 259 237
Bruxelles Wallonie Flandre
78 176 142
137 258 232
276 187
(Slice)
245 196 Coupe sur 2005
écran
souris
clavier
Bruxelles Wallonie Flandre
60 125 196
157 287 245
145 259 237
Fig. 2.5 – Opération slice, extraction d’une tranche d’un cube.
clavier
souris
écran
120 230 210
132 198 256
145 259 237
Bruxelles Wallonie Flandre
78 176 142
137 258 232
276 187
245 196
Extraction d’un
sous-cube
(Dice)
clavier
souris
2004 132 198
2005
145 259
Fig. 2.6 – Opération dice, extraction d’un sous-cube.
Bruxelles Wallonie
Deux autres opérations importantes sont possibles sur les bases de données multidimensionnelles
: roll-up et drill-down. Nous n’avons pas trouvé de traduction concise pour ces termes,
nous les utiliserons donc en anglais par la suite. Ces deux opérations permettent de naviguer
dans les données en suivant les hiérarchies de dimensions. La première, roll-up, permet d’agréger
les données suivant une dimension. La deuxième, drill-down, permet de faire le contraire, c’est à
dire de détailler les données. Par exemple, un roll-up sur la dimension temporelle nous permet
de passer d’une vue par trimestre à une vue par année. Un drill-down de passer d’une vue par
année à une vue par trimestre.
2.3.2 Modèles de données
Modèle en étoile
La modélisation dimensionnelle agence les données d’une façon très différente de la structure
en 3FN (3 e forme normale) fréquemment utilisée par les modélisateurs des systèmes OLTP. La
modélisation dimensionnelle produit ce qu’on appelle le modèle dimensionnel ou, communément,
le schéma en étoile (star schema). Un tel schéma est présenté à la figure 2.2. C’est la structure de
données la plus utilisée et la plus appropriée aux requêtes et analyses des utilisateurs d’entrepôts
de données. Elle est simple à créer, stable et intuitivement compréhensible par les utilisateurs
finaux. Le modèle dimensionnel est la fondation même de la construction des cubes OLAP. Il
142
145
176

2.3 Le modèle multidimensionnel 9
consiste en une grande table de faits et un cercle d’autres tables qui contiennent les éléments
descriptifs du fait, les dimensions. Quand il est illustré, le modèle ressemble à une étoile, d’où
sa dénomination « En étoile ».
On peut citer, comme avantages, la facilité de lecture et la faible complexité des requêtes.
En effet, peu de jointures sont nécessaires car le nombre de tables reste faible. Par contre, il
y a de la redondance dans les tables de dimensions, ce qui entraîne un stockage lourd et une
alimentation complexe de la base de données.
Modèle en flocons de neige
Dimension Produit
PK id_produit
nom_produit
FK1 id_categorie
Catégories
PK id_categorie
nom_catégorie
FK1 id_famille
Familles
PK id_famille
nom_famille
Trimestres
PK trimestre
FK1 année
Mois
PK mois
FK1 année
FK2 trimestre
Fait Vente
PK id_vente
nombre
montant
FK1 id_produit
FK2 jour
FK3 id_vendeur
FK4 id_magasin
Dimension Géographie
PK id_magasin
nom_magasin
FK1 id_commune
Régions
PK id_region
nom_region
FK1 id_pays
Années
PK année
Dimension Temps
PK jour
FK1 mois
FK2 semaine
Dimensions Vendeurs
PK id_vendeur
nom_vendeur
FK1 id_groupe
Communes
PK id_commune
nom_commune
FK1 id_region
Pays
PK id_pays
nom_pays
Semaines
PK semaine
FK1 année
Départements
PK id_departement
nom_departement
Groupes
PK id_groupe
nom_groupe
FK1 id_departement
Fig. 2.7 – Modélisation d’un entrepôt à l’aide d’un schéma en flocons.
Le schéma en flocons de neige (snowflake schema) est une variante du schéma en étoile.
Un exemple est présenté à la figure 2.7. Dans la théorie, la différence réside dans la simple
normalisation des tables de dimensions en 3FN. Il est donc tout simplement question de mettre
les attributs de chaque niveau hiérarchique dans une table de dimension distincte pour éviter la
redondance. Bien que ce modèle permet de gagner de l’espace disque et facilite l’alimentation,

2.4 Collecte et intégration des données 10
il implique de nombreuses jointures dans les requêtes et donc une difficulté d’écriture de ces
dernières.
Quand il s’agit de choisir une modélisation plutôt qu’une autre, de nombreux paramètres
sont à prendre en compte : la nature des requêtes, les besoins d’analyse, les besoins de flexibilité,
l’évolution des dimensions dans le temps, etc. Ce n’est donc jamais une question simple et il
convient de l’étudier avec le plus grand soin. En effet, une mauvaise modélisation peut conduire
à l’inutilité d’un entrepôt avec les pertes de temps et d’argent que cela implique.
2.4 Collecte et intégration des données
L’intégration des données est certainement la partie la plus complexe, justifiant ainsi la timidité
des entreprises à fabriquer un tel entrepôt de données. Il convient d’uniformiser et de fédérer
les différentes sources d’informations de l’entreprise. Bien souvent, les entreprises possèdent une
multitude de bases de données de structures différentes : bases de données relationnelles, fichiers,
sources Web, . . . Il faut donc définir un schéma global qui intègre les données utiles à l’analyse,
d’où une gestion stricte des méta-données telles que la description des sources ou des éventuelles
vues exportées des bases de données.
Ces opérations sont connues sous le terme ETL (Extract-Transform-Load) ou data pumping.
Il s’agit d’un système intergiciel (middleware) qui permet de faire des synchronisations d’informations
d’une base de données vers une autre. Ces systèmes sont basés sur des connecteurs
servant à exporter et importer des données, des transformateurs pour manipuler les données et
les convertir dans le schéma de la base de données de destination. Le but est l’intégration des
données de toute l’entreprise dans une base de données commune, l’entrepôt de données.
Il s’agit ici d’un processus très complexe et très coûteux : Ralph Kimball [4], après 18 mois
d’études sur les ETL, en a défini 38 sous-systèmes et a évalué à 70% la part de l’intégration dans
un projet d’entrepôt de données.
2.5 Analyse des données
Il faut différencier deux types d’analyses de données : le Data Mining ou forage de données
et l’analyse multidimensionnelle (OLAP). Dans ce mémoire, nous nous concentrerons principalement
sur l’analyse multidimensionnelle.
Le forage de données (Data Mining) a pour but de mettre en évidence des corrélations
éventuelles dans un volume important de données afin de dégager des tendances. Il s’appuie sur
des techniques d’intelligence artificielle comme des réseaux de neurones ou sur des techniques
statistiques afin de mettre en évidence des liens cachés entre les données et ainsi prévoir des
tendances.
Online Analytical Processing (OLAP) est un terme commercial qui désigne les bases de
données multidimensionnelles (aussi appelées cubes ou hyper-cubes) destinées à l’analyse et il
s’oppose au terme OLTP qui désigne les systèmes transactionnels. Ce terme a été défini par E.

2.5 Analyse des données 11
F. Codd [5] il y a plus de 10 ans au travers de 12 règles que doit respecter une base de données
si elle veut adhérer au concept OLAP. Les 12 règles de Codd sont :
⊲ Vue conceptuelle multidimensionnelle
⊲ Transparence
⊲ Accessibilité
⊲ Constance des temps de réponses
⊲ Architecture Client/Serveur
⊲ Indépendance des dimensions
⊲ Gestion des matrices creuses
⊲ Accès multi-utilisateurs
⊲ Pas de restrictions sur les opérations inter et intra dimensions
⊲ Manipulation des données aisée
⊲ Simplicité des rapports
⊲ Nombre illimité de dimensions et nombre illimité d’éléments sur les dimensions
Codd a défini ces règles sur demande de la compagnie Arbor Software, devenue aujourd’hui
Hyperion, un grand nom dans les entrepôts de données. C’est pourquoi ces règles sont controversées
de par leur origine commerciale. De plus, ce terme ne donne ni une définition ni une
description claire de ce que signifie OLAP. Il ne donne non plus aucune indication des motifs
d’utilisation d’outils OLAP, ni de leurs particularités. Nigel Pendse [6] a redéfini le terme OLAP
comme un « système d’analyse rapide d’informations multidimensionnelles partagées » (FASMI,
Fast Analysis of Shared Multidimensional Information), ce qui nous paraît être une définition
plus appropriée.
Ce concept est appliqué à un modèle virtuel de représentation de données appelé cube ou
hyper-cube OLAP. Il existe ensuite plusieurs déclinaisons qui permettent d’adapter le stockage
des données sur différents types de bases de données pour implémenter le concept OLAP :
⊲ R-OLAP : outils OLAP sur des bases relationnelles
⊲ M-OLAP : outils OLAP implémentés à l’aide de structures multidimensionnelles
⊲ H-OLAP : outils OLAP implémentés par un mélange de relationnel et de multidimensionnel
Le choix d’une implémentation ou d’une autre n’est pas aisé. Si le R-OLAP est plus échelonnable,
il est moins performant que le M-OLAP, qui, lui, peut conduire à une explosion de la taille
de la base de données. Ce choix mérite donc une réflexion importante. Les outils existants sur
le marché, comme SQL Server Analysis Tools de Microsoft, implémentent parfois les différents
types et fournissent à l’utilisateur des évaluations de performances et de taille afin de l’aider à
se décider.
La grande idée sous-jacente est que la représentation des données ne doit plus être tabulaire
comme c’est le cas pour les bases de données relationnelles. On doit être capable, et c’est le cas
avec les outils actuellement sur le marché, de pouvoir présenter les données sous la forme que
l’on souhaite.

2.6 Conclusions 12
Les opérations que l’on souhaite pouvoir faire grâce à ce genre d’outils sont les opérations
classiques que l’on peut effectuer sur un cube ou un hyper-cube. Nous avons détaillé ces différentes
opérations un peu plus haut dans ce chapitre, à la page 7. Bien souvent, ces opérations
demandent l’agrégation de mesures suivant plusieurs dimensions. Les outils OLAP procèdent
généralement à des pré-agrégations qui permettent d’accélérer les requêtes.
Il existe des langages spécifiques, comme Microsoft MDX, qui permettent d’écrire ces opérations
de manière très simple. Ces langages combinés à des outils graphiques permettent aux
décideurs d’utiliser ces outils sans assistance. Il faut bien se rendre compte que ce genre de système
est destiné à être utilisé par des personnes non informaticiennes et donc leur accessibilité
est importante.
Les produits les plus utilisés actuellement, selon une étude de olapreport.com, un site
influent dans le domaine, sont SQL Server (28% du marché), Hyperion (19%) et Cognos (14%).
Le marché paraît donc encore assez ouvert, même si Microsoft semble le dominer. Etrangement,
SAP et Oracle se placent respectivement à la 5 e et 10 e place. Il existe aussi quelques systèmes
libres comme Mondrian et Palo.
2.6 Conclusions
Les entrepôts de données et leurs outils deviennent indispensables dans le monde des entreprises.
De nombreux systèmes existent mais la création et la gestion d’un système d’aide à la
décision reste très coûteux. Dans ce mémoire, nous allons étudier ce que XML peut apporter à
ce domaine.
Pour ce faire, dans les chapitres suivants, nous allons introduire le langage XML, ses méthodes
d’interrogation et les systèmes permettant de gérer les documents XML.

Chapitre 3
Les documents XML
Ce chapitre présente les fondements du langage de balisage extensible XML et les technologies
qui lui sont associées.
Contenu
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2 Historique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3 Motivations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.4 Le document XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.5 Les DTD et les Schémas XML . . . . . . . . . . . . . . . . . . . . . . 19
3.6 Modélisation des documents XML . . . . . . . . . . . . . . . . . . . . 22
3.7 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.1 Introduction
XML (eXtensible Markup Language) a été défini en 1998 par le W3C (World Wide Web
Consortium). Voici une traduction d’une partie de la recommandation 1.0 [7] :
« Le langage de balisage extensible (eXtensible Markup Language, XML) est un
sous-ensemble de SGML [...]. Son but est de permettre au SGML générique d’être
transmis, reçu et traité sur le Web de la même manière que l’est HTML aujourd’hui.
XML a été conçu pour être facile à mettre en œuvre et interopérable avec SGML et
HTML. »
XML est une notation permettant de décrire un langage sous la forme d’une grammaire
d’arbre. Il permet de stocker des données structurées dans un fichier texte à l’aide de balises
extensibles. Les balises peuvent être définies par les utilisateurs au contraire de l’HTML. Ce
formalisme regroupe sous le nom d’XML une boite à outils extensible et évolutive dont le but
est de simplifier l’organisation, l’échange et la structure des données. XML n’est pas uniquement
un langage à balises mais un ensemble de règles pour organiser des données et un ensemble de
technologies permettant de manipuler ces données organisées.
13

3.2 Historique 14
3.2 Historique
Comme nous l’avons vu dans l’introduction de ce chapitre, XML est un sous-ensemble de
SGML [8] (Standard General Markup Language). SGML est un standard ISO datant de 1985
décrivant un méta-langage flexible destiné à structurer des documents. Il est basé sur GML [9]
(Graphics Markup Language) développé chez IBM par Goldfarb, Mosher et Lorie (d’où l’acronyme)
afin de décrire et structurer des documents légaux. Le SGML est ensuite devenu un
standard de représentation de données textuelles dans un format indépendant du système. Il
a été utilisé par l’industrie pour produire des catalogues et des documentations techniques.
Cependant, le SGML était très complexe à utiliser et peu pratique.
En 1989, Tim Berners-Lee définit l’HTML [10] (HyperText Markup Language), le langage de
mise en forme bien connu. C’est le début du Web tel que l’on le connaît. HTML est un dialecte
allégé du SGML mais qui reste assez limité malgré de nombreuses adaptations au fil du temps.
Peu après, le W3C a été créé dans le but de garantir un accès universel au Web. C’est un
arbitre neutre en ce qui concerne l’architecture, l’interface et les technologies relatives au Web.
Cet organisme produit des papiers de travail (Working Drafts) et des recommandations à propos
des standards de la toile en ayant toujours comme objectif l’interopérabilité et l’universalité des
technologies utilisées sur le Web.
A cette époque, le marché du SGML est assez confidentiel et sa communauté a peur de ne
pas profiter de l’essor de son fils, l’HTML. De son côté, le W3C trouve que le Web est mal
organisé du fait du mélange entre présentation et structure (par exemple la balise au
lieu de ). Un partenariat avec la communauté des développeurs SGML est fait au sein du
W3C et un groupe de travail est constitué : SGML-Light Working Group.
Le W3C et la communauté SGML ont un but commun : ré-aiguiller le Web vers un successeur
de SGML. En 1996, l’idée du XML est née : on veut un SGML simple, facile à manipuler et
permettant un échange d’informations structurées traitables par ordinateur. XML se doit de
supporter un grand nombre d’applications et donc permettre aux utilisateurs de spécifier leurs
propres structures de données. Ce groupe de travail va reprendre les meilleurs parties du SGML
et profiter de l’expérience de l’HTML pour produire une technologie toute aussi puissante que
SGML mais beaucoup plus régulière et simple à utiliser.
Les exigences (requirements) d’XML peuvent être résumés par les 10 points suivants [7] :
1. XML doit être facilement utilisable sur le Web.
2. XML doit supporter une grande variété d’applications.
3. XML doit être compatible avec SGML.
4. Il doit être facile d’écrire des programmes qui traitent des documents XML.
5. Le nombre d’options doit être réduit au minimum, idéalement à zéro.
6. Les documents XML doivent être lisibles et raisonnablement clairs.
7. La conception de XML doit être menée rapidement.
8. La description de XML doit être formelle et concise.

3.3 Motivations 15
9. Les documents XML doivent être faciles à créer.
10. La concision du balisage XML est d’une importance minime.
En 1998, le groupe de travail XML du W3C fixe le format dans la recommandation XML 1.0.
Très vite, le support natif de ce langage arrive dans les navigateurs (Microsoft Internet Explorer
5.0, Netscape 6.0), les suites bureautiques (Microsoft Office 2000, OpenOffice.org), . . .
L’utilisation d’XML ne cesse de croître, il est utilisé partout : sur Internet, dans les bases de
données, dans les fichiers de configuration, pour représenter des données spatiales (GML), des
formules mathématiques (MathML), des composants chimiques (CML), etc. La recommandation
originale de XML a très peu évolué depuis sa sortie : sa simplicité permet de décrire n’importe
quel type de données.
3.3 Motivations
XML est une méthode utilisée pour stocker des données structurées dans un fichier texte.
On entend par données structurées des éléments tels qu’agendas, paramètres de configuration,
fiches clients, dessins vectoriels, . . . : n’importe quel élément pouvant être modélisé à l’aide d’une
structure arborescente.
Bien souvent, les logiciels stockent ces données sur disque dans un format binaire, compréhensible
par un nombre limité d’applications. L’avantage du format texte est de pouvoir être
manipulé au besoin indépendamment du programme source. Bien que stocké sous format textuel,
un fichier XML n’est pas destiné à être lu par des personnes mais il offre la possibilité pour
les développeurs de déboguer plus facilement leur application en corrigeant à la main (à l’aide
d’un éditeur de texte) un fichier XML endommagé.
XML est donc un ensemble de règles, de conventions permettant de concevoir des fichiers
comprenant des données structurées de manière non ambiguë, facile à générer et à lire par ordinateur
et ayant un bon support de l’internationalisation et de la compatibilité entre différentes
plates-formes.
XML est un méta-langage qui utilise des balises et des attributs. Une balise est un ensemble
de mots encadrés par les symboles < et >. Un attribut est un couple nom - valeur, défini par
nom="valeur". Ces balises ne sont pas fixées : l’utilisateur peut définir ses propres balises, son
propre format XML. Les balises en XML, au contraire de l’HTML, n’ont pas de signification
précise : elles sont présentes pour délimiter les données et XML laisse l’entière interprétation
des données à l’application qui les lit. Par exemple, une balise en XML ne représente pas
nécessairement un paragraphe comme en HTML. Cela peut être un prix, une personne, un
produit, . . . Les règles en XML sont aussi beaucoup plus strictes qu’en HTML : par exemple,
toute balise ouverte doit être fermée et les attributs doivent obligatoirement être entourés de
guillemets.
Du fait de l’utilisation du format texte et de nombreuses balises pour délimiter les données,
un fichier XML est presque toujours plus volumineux que son équivalent binaire. C’est le prix
à payer pour obtenir les facilités évoquées plus haut dans cette section. Néanmoins, ce prix

3.4 Le document XML 16
est à relativiser car l’espace disque n’est plus aussi coûteux qu’auparavant et qu’il existe de
très bon compresseurs/décompresseurs rapides. Il est utile de noter que le protocole HTTP/1.1
(HyperText Transfer Protocol, le protocole du Web) permet de compresser des données à la volée,
ce qui économise la bande passante de la même manière que les fichiers binaires.
XML n’est pas seulement un méta-langage ; c’est une boîte à outils. Autour de la recommandation
XML 1.0 du W3C qui définit principalement ce que sont les balises et les attributs, un
nombre croissant de modules ont été définis. Ce sont des modules facultatifs qui fournissent des
ensembles de balises et d’attributs, des règles pour certaines tâches particulières, des méthodes
pour les exploiter, . . . Citons en quelques uns comme XLink qui décrit une méthode pour ajouter
des liens hyper-textes à un fichier XML. XPointer permet de se référer à des parties de document
XML. XPath est un outil pour accéder aux données d’un fichier XML à l’aide de chemins
de type UNIX. XQuery est un langage d’interrogation type SQL. D’autres outils importants
sont les espaces de noms (namespaces) qui permettent d’éviter toute confusion lors de noms
identiques et les Schémas XML qui offrent aux développeurs la possibilité de définir leur propre
format XML. De nombreux autres modules existent et leur nombre est en constante croissance.
Dans les chapitres suivants, nous détaillerons certains de ces concepts, jugés intéressants dans le
domaine des bases de données.
Les avantages principaux d’XML sont donc sa simplicité, sa modularité, sa stabilité (le
format a peu évolué depuis son arrivée en 1998) et son universalité. De plus, il est libre de
droit et possède un nombre grandissant d’outils et d’utilisateurs. Cela facilite grandement les
recherches, la réutilisation et diminue la dépendance vis-à-vis des fournisseurs et applications.
Enfin, XML est beaucoup plus souple que le relationnel pour modéliser le monde réel.
Nous clôturons ces motivations par une citation de Bert Bos, membre du W3C :
« XML n’est pas toujours la meilleure solution, mais il vaut toujours la peine d’être
pris en considération »
3.4 Le document XML
Dans ce chapitre, nous introduirons brièvement les concepts relatifs aux documents XML
que nous utiliserons dans la suite de ce mémoire.
3.4.1 Les outils de base
Un fichier XML étant avant tout un fichier texte, il peut être édité avec n’importe quel
éditeur de texte comme Emacs par exemple. Il existe aussi des éditeurs spécialisés orientés XML
tels que oXygen qui permettent de visualiser de façon graphique les documents XML.
La plupart des navigateurs récents permettent d’afficher les documents XML de façon hiérarchique
de telle sorte que l’on peut se déplacer dans le fichier comme dans un arbre. Ceux-ci
permettent aussi de vérifier la validité d’un fichier XML, nous en parlerons au point 3.5. Cependant,
rappellons que le but premier d’XML est de décrire des données et non pas de les

3.4 Le document XML 17
présenter. XML est aussi indépendant du système utilisé : l’utilisation d’un navigateur est donc
loin d’être nécessaire pour valider les données. De nombreux analyseurs syntaxiques (parsers)
existent pour cela : citons Expat et Xerces qui sont deux projets libres.
3.4.2 Notions générales
Document XML
Marc Dupond
1234567
7654321
Prologue
Attribut
Elément
Fig. 3.1 – Exemple de fichier XML.
Contenu
(PCDATA)
Un exemple de fichier XML très simple est illustré à la figure 3.1. Comme on peut le remarquer,
chaque section est marquée à l’aide de balises descriptives permettant d’identifier le type
de données qu’elle contient.
Un document XML est soit bien formé, soit valide. Il peut en outre être illégal mais, dans ce
cas, nous ne pouvons le considérer en tant que fichier XML. Introduisons ces deux concepts et
les notions nécessaires à leur compréhension :
Un document XML bien formé est un document qui suit la recommandation XML, c’est-àdire
qu’il est conforme aux règles en ce qui concerne les éléments et les attributs, qu’il contient
les déclarations essentielles et qu’il respecte parfaitement une structure arborescente.
Un document XML est valide s’il est bien formé et qu’il suit les règles d’une définition de
type de document (DTD) ou d’un Schéma XML. Une DTD permet d’imposer une structure à
un document XML : un document XML peut donc se conformer à un ensemble de règles afin
d’éviter des erreurs de forme. Un Schéma XML permet en plus de typer les données se trouvant
dans le document auquel il est associé alors que la DTD ne se préoccupe pas du typage. Nous
verrons plus en détail ces outils par la suite, au point 3.5.
3.4.3 Types de documents XML
Les documents XML peuvent se classer en deux grandes catégories : orientés données et
orientés présentation.

3.4 Le document XML 18
Documents orientés données
Les documents orientés données (data-centric) sont ceux où XML est utilisé pour transporter
des données. Ils incluent les ordres de ventes, les enregistrements de patients et les données scientifiques.
Leur structure physique (l’ordre des éléments, l’utilisation de PCDATA ou d’attributs)
n’est pas importante dans la majorité des cas.
Documents orientés présentation
Les documents orientés présentation (document-centric) sont ceux dans lesquels XML est
utilisé pour ses capacités similaires à SGML, comme dans un manuel d’utilisateur, une page
web statique en XHTML ou des brochures. Ils sont caractérisés par leur structure irrégulière
et leur contenu mixte. A l’opposé des documents orientés données, leur structure physique est
importante. Par exemple, pour un manuel d’utilisateur, l’ordre des chapitres est important. Par
contre, pour une facture, l’ordre des articles ne l’est pas ou l’est moins.
3.4.4 Les éléments, ses attributs et les données textuelles
Dans le document XML, après le prologue, se trouve une série d’éléments. Un élément est
l’unité de base d’un document XML, composé de données textuelles et de balises. Les frontières
d’un élément sont définies par une balise de début et une balise de fin. Un élément peut contenir
des attributs additionnels. Par exemple, Jean Dupond est un élément
et Jean Dupond est un élément contenant un attribut.
Notons qu’XML permet la définition d’éléments vides : ils n’ont pas de contenu et pas de
balise fermante. Ces éléments sont formés en ajoutant une barre oblique à la fin de la balise
ouvrante. est un élément vide.
Du point de vue de la syntaxe, le nom d’un élément doit toujours commencer par une lettre
et est sensible à la casse. Un élément ne peut contenir que du texte ou une combinaison de textes
d’autres éléments : Jean Dupont18 est une combinaison
valide.
Un document XML bien formé doit contenir au moins un, et un seul élément non vide, appelé
élément racine. Celui-ci peut contenir d’autres éléments définissant ainsi un arbre.
Comme le précise la spécification XML, tout texte qui n’est pas du balisage est une donnée
textuelle du document. Précisons toutefois que certains symboles sont interdits comme et
&. Pour utiliser ces caractères, il faut les remplacer par leur représentation hexadécimale.
Les éléments peuvent, comme indiqué plus haut, contenir des attributs qui fournissent
des informations supplémentaires. Ces attributs sont des couples (nom, valeur) de la forme
nom="valeur". Ils doivent se trouver dans la balise ouvrante après le nom de l’élément. Notons
que les noms d’attributs sont aussi sensibles à la casse, qu’ils doivent être uniques au sein d’un
même élément et que les valeurs des attributs se trouvent obligatoirement entre guillemets. La
décision d’utiliser un attribut plutôt qu’un élément peut être un problème complexe car leurs

3.5 Les DTD et les Schémas XML 19
fonctionnalités sont similaire. Les deux formes suivantes sont correctes et permettent d’obtenir
le même effet :
Jean Dupond
Jean Dupondm
Des raisons valides pour utiliser des attributs au lieu d’éléments sont l’affectation d’un identificateur
à un élément ou la description de caractéristiques de l’élément lui même :
Jean Dupond
Jonagold
Notons qu’il est aussi possible de limiter les valeurs possibles d’un attribut grâce à une DTD
ou un Schéma XML afin d’éviter les erreurs. Nous en parlerons au point 3.5.
3.4.5 L’espace de nom
Un document XML peut contenir des éléments et des attributs correspondants à plusieurs
domaines distincts, par exemple plusieurs dialectes. Il se peut donc qu’il y ait des collisions au
niveau des noms d’éléments et d’attributs.
Peu après la première recommandation XML de 1998, une solution à ce problème est établie :
les espaces de noms (namespaces en anglais). Les espaces de noms permettent d’introduire une
collection de noms utilisables pour les éléments et attributs d’un document XML. Une collection
est identifiée par un URI.
On peut donc utiliser un espace de nom par défaut ou plusieurs espaces de nom au sein d’un
même document XML à l’aide de préfixes. Nous ne rentrerons pas dans les détails de ce concept.
3.5 Les DTD et les Schémas XML
Les DTD et les XML Schémas sont des langages utilisés pour définir la structure des documents
XML. Ils déterminent quels éléments peuvent être contenus dans un document XML,
quels éléments peuvent être imbriqués dans d’autres, quelle valeur par défaut leurs attributs
peuvent avoir, etc. A l’aide d’une DTD ou d’un Schéma XML et du document XML correspondant,
un analyseur syntaxique peut confirmer que le document est conforme à la structure et
aux contraintes désirées. Un tel document est dit valide.
Les DTD XML[7] sont un sous-ensemble des DTD SGML. Une DTD définit la structure du
document à l’aide d’une liste d’éléments légaux. Le mot-clé !ELEMENT définit le type de l’élément
et le mot-clé !ATTLIST précise ses attributs. La DTD permet également de déclarer le nombre
de fois qu’un élément fils peut apparaître dans un élément parent : un ou plus (+), zéro ou plus
(*) ou zéro ou un ( ?). Les attributs de type ID et IDREF permettent de créer des relations entre
les attributs, à l’image des clés étrangères utilisées dans les systèmes relationnels.
Les types d’éléments possibles sont les suivants :
⊲ #PCDATA désigne les données textuelles devant être traitées par l’analyseur ;

3.5 Les DTD et les Schémas XML 20
⊲ #CDATA désigne les données textuelles qui ne doivent pas être traitées par l’analyseur ;
⊲ EMPTY signifie que l’élément ne peut rien contenir ;
⊲ ANY signifie que l’élément peut contenir ce que l’on veut.
Pour illustrer, analysons l’exemple suivant :
]>
L’art de l’intrusion
< auteurs >
< personne > Mitnick < prenom >Kevin
< personne >Simon < prenom > William
Il s’agit d’un document XML valide précédé de sa DTD. Cette DTD peut être interprétée comme
suit :
⊲ !DOCTYPE livre définit qu’il s’agit d’un document de type livre.
⊲ !ELEMENT livre (titre, auteurs) définit qu’un élément livre doit contenir comme
fils un élément titre et un élément auteurs.
⊲ !ATTLIST livre ISBN CDATA #REQUIRED définit l’attribut ISBN d’un élément livre.
Cet attribut est obligatoire pour chaque livre. S’il n’est pas spécifié, le document ne sera
pas validé.
⊲ !ELEMENT titre #CDATA et les autres lignes similaires définissent que les éléments titre,
nom et prenom doivent contenir des données CDATA. Rien d’autre n’est précisé à propos
de ces données, si ce n’est que ce sont des données textuelles.
⊲ !ELEMENT auteurs (personne+) définit qu’un élément auteurs doit être composé d’au
moins un élément personne.
⊲ !ELEMENT personne (nom,prenom) définit qu’un élément personne est composé d’un
élément nom et d’un élément prenom.
Cependant, un des gros défauts des DTD, malgré leur simplicité, est qu’il n’est pas possible
de définir des contraintes comme le nombre de fois qu’un élément particulier doit apparaître
dans le document, le type des données de chaque élément, etc. Il faut se rappeler que les DTD
ont été inventées à l’époque du SGML, utilisé pour décrire des documents. Des contraintes
d’instanciation et de typage sont moins critiques pour des documents XML orientés présentation,

3.5 Les DTD et les Schémas XML 21
que nous pouvons comparer avec les documents SGML. Pour plus d’informations à propos des
DTD, nous vous invitons à consulter les références suivantes [7, 11].
XML Schéma [12, 13] est un langage de description de format de document XML permettant
de définir la structure et la grammaire d’un document XML. Il a fait l’objet de la recommandation
du W3C datant en 2001. Le document produit à l’aide de ce langage est un fichier de
description de structure (XML Scheme Description ou fichier XSD). Ce dernier est, au contraire
de la DTD, un document XML bien formé. Il n’y a donc plus de balises telles que < !ELEMENT>,
< !ATTLIST>, . . .
Le rôle d’un fichier XSD est un peu équivalent à celui d’une DTD ; c’est-à-dire qu’il permet
de valider un document XML. XML Schéma comporte cependant quelques différences : les types
de données de base utilisables dans les DTD (#PCDATA, ANY, EMPTY) ont été enrichis (entiers,
réels, chaîne, date, liste, . . . ). Les types de données sont dérivables : on peut donc réutiliser un
type défini pour l’enrichir. Il est également possible de grouper les attributs en factorisant leurs
définitions afin de faciliter leur réutilisation. L’on peut également définir précisément le nombre
d’occurrences d’un élément au sein d’un document XML.
Il est intéressant de remarquer que XML Schéma est lui même défini par un schéma, dont
les balises de définition s’auto-définissent, ce qui en fait un exemple de définition récursive.
Contrairement aux DTD, les XML Schémas ont été développés par des gens non documentalistes,
mais appartenant au monde des bases de données et des langages. Le design est donc puissant
et moderne mais complexe.
Précisons que XML Schéma utilise les espaces de noms XML (namespaces). Un document
XSD devra donc indiquer l’URL de l’espace de nom consacré à XML Schéma. Les déclarations
devront donc être contenues dans l’élément XML suivant :
< xsd:schema xmlns =" http: // www .w3.org /2001/ XMLSchema ">
(...)
A titre d’illustration, voici le Schéma XML suivant, qui correspond à l’exemple de la page
précédente.
< xsd:schema xmlns:xsd =" http: // www .w3.org /2001/ XMLSchema ">
< xsd:element name =" livre ">
< xsd:complexType >
< xsd:sequence >
< xsd:element name =" titre " type =" xsd:string "/>
< xsd:element name =" auteurs ">
< xsd:element name =" personne " maxOccurs =" unbounded ">
< xsd:complexType >
< xsd:sequence >
< xsd:element name =" nom " type =" xsd:string "/>
< xsd:element name =" prenom " type =" xsd:string "/>

3.6 Modélisation des documents XML 22
< xsd:attribute name =" ISBN " type =" xsd:string " use =" required "/>
Introduire manuellement ce genre de document n’est pas une tâche aisée. Il existe bien sûr
moult logiciels permettant de détecter des schémas à partir de documents XML ou de les créer
à l’aide d’une interface graphique ergonomique comme par exemple le logiciel oXygen 1 .
Les Schémas XML sont donc plus adaptés pour définir des documents XML structurés. Cela
nous intéresse particulièrement dans le domaine des bases de données, car nous pouvons définir
très précisément le type de ces données afin de garantir leur intégrité dans la base.
D’autres langages similaires existent comme, par exemple, RelaxNG [14], développé par OA-
SIS. Il est, selon ses auteurs, plus simple et plus compact que les Schémas XML. Nous ne nous
attarderons pas plus sur ces langages de définition de structure.
3.6 Modélisation des documents XML
Un document XML est habituellement modélisé comme un graphe dont les nœuds correspondent
aux éléments et attributs XML. Le graphe est généralement un arbre, si nous supposons
qu’il n’y a pas d’attribut de type IDREF/IDREFS. Ce type d’attribut permet de lier des éléments
à l’aide d’un système de clés comme dans les bases de données relationnelles. Nous l’apellerons
l’arbre XML par la suite. Un attribut est modélisé comme un fils de l’élément correspondant. Les
valeurs textuelles des éléments ou des attributs apparaissent comme des feuilles de l’arbre XML.
Une caractéristique commune des langages d’interrogation XML (dont nous parlerons dans le
chapitre 4) est la possibilité de formuler des chemins dans le graphe XML.
Pour illustrer, observons un document XML et son arbre, représenté à la figure 3.2. Dans
cette illustration, les éléments sont représentés par des cercles, les attributs par un triangle et
les valeurs des éléments ou attributs par des rectangles.
Dans les sections suivantes, nous parlerons des différents ordres d’un document XML ainsi
que différentes sortes de modélisation.
3.6.1 Ordres
Dans la suite de ce document, nous allons parler de trois ordres différents. Bien que cela
semble être trivial, nous nous permettons de les introduire brièvement dans ce chapitre. Les
trois ordres que nous allons utiliser sont les suivants :
⊲ L’ordre du document
⊲ L’ordre des nœuds en parcours post-fixé
⊲ L’ordre des nœuds en parcours pré-fixé
1 http://www.oxygenxml.com/

3.6 Modélisation des documents XML 23
Ordre du document

In Figure 1.2 the preorder and postorder traversal of an XML tree are shown. The document
order is a < b < c < d < e < f < g < h < i < j, and thus pre(a) = 0, pre(b) = 1, . . . ,
pre(j) = 9. The postorder traversal is acquired: post(d) = 0, post(e) = 1, post(c) = 2,
post(f) = 3, post(b) = 4, post(i) = 5, post(j) = 6, post(h) = 7, post(g) = 8, post(a) = 9.
3.6 Modélisation des documents XML 24
(2)
c
(1)
(3) d (4)
b
e
(5)
f
(a)
a
(0)
g
h
(6)
(7)
i (8) j (9)
(2)
c
(4)
(0) d (1)
Fig. 3.3 1.2. – (a) Parcours Preorderpré-ordre and (b) postorder et (b) parcours traversal post-ordre of and’un XMLarbre. tree
b
e
(3)
f
(b)
a
i
(9)
g
h
(8)
(7)
(5) j (6)
SAX n’est pas à proprement parlé un modèle pour les documents XML mais il peut être
vu comme un modèle événementiel pour XML. En effet, SAX permet de parcourir le document
XML séquentiellement. A chaque nouvel élément et à chaque fin d’élément, un événement est
1.4 déclenché. XML Cet outilQuery sert donc àLanguages interroger un document XML à l’aide d’un programme tiers de
façon séquentielle. Il est donc impossible de remonter dans le document XML ou de réordonner
To les obtain nœuds, specified ce qu’il est data possible from de anfaire XMLavec database le modèle a number DOM. of special query languages have
been developed, e.g. XML-QL [20], XQL [66], XPath [81], and XQuery [80]. A common
L’avantage de SAX est qu’il ne nécessite pas beaucoup de place en mémoire contrairement
feature of these languages is a possibility to formulate paths in the XML graph. Such a
à DOM dont nous parlerons au point 3.6.4.
path is a sequence of element or attribute names from the root element to a leaf. Regular
expressions provide a valuable method for paths specifications. In fact, most of XML
query 3.6.3 languages Infoset are based on the XPath language that uses a form of path expressions for
composing more general queries.
Infoset [16] est une représentation abstraite des informations contenues dans un document
XML. Infoset définit un document XML bien formé comme un ensemble d’éléments d’informations.
Il y a onze éléments d’information et chaque élément possède un ensemble de propriétés.
Par exemple, pour un élément XML, les propriétés sont les suivantes : une liste d’éléments
enfants, l’élément parent, les attributs, le nom de l’élément, l’espace de nom et son préfixe.
Il est à noter que toutes les informations du document XML ne sont pas représentées dans
l’Infoset comme, par exemple, l’ordre des attributs et les éléments XML vides. Le but d’Infoset est
de représenter les informations généralement utiles à un analyseur XML. Le groupe s’occupant
de la recommandation Infoset a donc jugé inutile de garder des informations comme les éléments
vides. Cependant, Infoset est devenu la base de plusieurs modèles de données plus sophistiqués
utilisés par les processeurs XML.
3.6.4 DOM
Le DOM [17], Document Object Model ou modèle objet de document XML, est fondamentalement
différent d’Infoset. Infoset est un modèle de données, il définit une représentation abstraite
des données d’un document XML. DOM est plutôt une API, il définit une interface pour les données
et la structure d’un document XML afin qu’un programme puisse naviguer dans l’arbre et

3.6 Modélisation des documents XML 25
manipuler les informations contenues. Il est intéressant de constater que DOM est indépendant
des langages de programmation et des plateformes.
Le DOM a été défini par le W3C. La spécification DOM de niveau 1 définit un ensemble
d’objets, dans le sens de la programmation orientée objet, qui peuvent représenter n’importe quel
document structuré, comme un document XML. La spécification de niveau 2 ajoute le support
des dates et des espaces des noms. Le niveau 3 introduit des possibilités de chargement et de
sauvegarde, ainsi que de validation.
Le DOM est une API basée sur un arbre, par opposition aux API basées sur les événements
comme SAX. DOM définit une hiérarchie des nœuds. Cette hiérarchie, appelée DOM Structure
Model ou modèle de structure DOM, peut se voir comme un modèle de données pour des
documents XML.
Le principal défaut de DOM en tant que modèle de données est qu’il ne stocke pas les types
de données. Toutes les valeurs sont traitées comme des données textuelles de type DOMString.
Des versions propriétaires de DOM ont été créées, par Microsoft notamment, pour pallier à ce
problème.
DOM permet donc à un programme de manipuler le document XML en mémoire. Il donne
accès aux informations contenues dans les éléments ou les attributs via un parcours d’arbre (où
tous les axes de navigation classique sont permis) ou via le nom des éléments ou des attributs.
Il est à noter que DOM utilise beaucoup de mémoire par rapport à un document XML. Par
exemple, pour un document de 100Mo, l’image DOM en mémoire peut faire 400Mo. Les bases
de données XML natives, par exemple, devront y être attentives lors du stockage et de l’interrogation
de documents XML conséquents. Ces derniers points sont des désavantages si l’on
utilise DOM pour interroger un document XML, via XPath par exemple. Cela dit, DOM est
un moyen très populaire d’accéder et de manipuler un document XML en mémoire et beaucoup
d’implémentations de moteurs de requêtes l’utilisent.
3.6.5 Modèle de données XQuery
Un modèle spécifique pour XPath et XQuery a été créé par le W3C [18]. Il s’agit d’un Infoset
étendu pour XQuery, une représentation abstraite d’un document XML sous forme d’arbre ou
de séquence spécialement conçu pour les besoins d’un moteur XQuery.
En effet, le modèle de données Infoset n’était pas suffisant pour deux raisons :
1. Infoset ne gère pas les types de données. Un langage de requête raisonnable ne peut pas se
passer de connaître les types des données qu’il traite. En effet, cela poserait des problèmes
lors de comparaisons ou d’ordonnancements.
2. Infoset ne peut représenter que des documents XML bien formés. Or, XQuery a besoin de
pouvoir représenter un résultat intermédiaire, une valeur, une séquence de nœuds, . . . Ces
types de données ne sont pas gérées par Infoset.
Le modèle de données XQuery possède six types de nœuds, chacun contenant un ensemble
de propriétés et de caractéristiques, à l’image d’Infoset : élément XML, texte, attribut, espace
de nom, instructions de traitement et commentaire.

3.7 Conclusions 26
3.7 Conclusions
Dans ce chapitre, nous avons décrit le langage XML et les outils de base qui lui sont associés.
Nous avons vu que XML permet de décrire très facilement le monde réel et avec plus une grande
flexibilité que la représentation relationnelle.
Dans le chapitre suivant, nous allons d’abord détailler les langages destinés à interroger et
extraire des informations de ces documents XML Nous présenterons ensuite les différents types
de bases de données permettant de gérer des documents XML.

Chapitre 4
Les langages d’interrogation XML
Dans ce chapitre, nous allons présenter les différents langages d’interrogation pour XML.
Nous nous attarderons principalement sur XPath et XQuery que nous allons utiliser abondamment
par la suite.
Contenu
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.2 XPath . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.3 XQuery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.4 Autres langages d’interrogation . . . . . . . . . . . . . . . . . . . . . . 37
4.5 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.1 Introduction
Il existe différents types de langages afin d’interroger des données XML :
⊲ Les langages d’adressage : Ces langages permettent d’écrire des requêtes afin de naviguer
à l’intérieur d’un ensemble de données, à l’aide d’expressions de chemin. Ces
expressions de chemin sont souvent représentées de la même manière que dans les systèmes
de fichiers UNIX. Le standard des langages d’adressage est XPath [19] qui sert de
fondation pour les autres langages d’interrogation de documents XML.
⊲ Les langages de transformations : Ces langages permettent de restructurer et de
reformater des documents XML à l’aide de règles. Le standard actuel est XSLT [20]. Il
en existe d’autres comme par exemple CDuce [21].
⊲ Les langages de requêtes : Ces langages permettent d’émettre des requêtes complexes
sur des documents XML, comme SQL pour les bases de données relationnelles. XQuery
[22] et Lorel [23] sont des exemples de tels langages, le premier étant recommandé par le
W3C.
Par la suite, nous nous concentrerons sur les langages de requêtes et d’adressage et, tout
particulièrement, sur XPath et XQuery.
27

4.2 XPath 28
4.2 XPath
Le langage d’expression de chemin XML, XPath, a été publié comme recommandation par
le W3C en 1999 [19]. Jim Melton en fait une description complète dans son livre Querying
XML [24]. Selon sa spécification, XPath a été créé pour fournir une syntaxe commune pour les
fonctionnalités partagées entre XSLT et XPointer. Son but est de pouvoir adresser des parties
d’un document XML. Autrement dit, XPath permet de sélectionner un ensemble de nœuds de
l’arbre XML à l’aide d’une expression de chemin.
La notation choisie pour XPath ressemble délibérément à la notation utilisée pour parcourir
les systèmes de fichiers de type UNIX et à celle utilisée dans les URL sur Internet. Une expression
typique XPath ressemble à la suivante :
/ clients / client [ @id ="1548"]/ nom
Cette expression se lit très facilement, du moins pour ceux qui sont habitués à utiliser un système
de fichier. Si nous ne tenons pas compte de l’expression entre crochets, cette expression permet de
sélectionner les éléments nom des éléments client contenus dans l’élément clients. L’expression
entre crochets est un filtre. Celui-ci est constitué d’un prédicat. Ce filtre permet de sélectionner le
ou les élément(s) client dont l’attribut id est égal à 1548. Pour illustrer, observons les résultats
de cette requête sur le document suivant :
< clients >
Marc Dupont
1958 -03 -06
Independant
Luc Dubois
1967 -12 -20
Le résultat de notre requête sera donc Luc Dubois.
Les expressions de chemin sont composées d’étapes. Les étapes sont représentées à l’aide d’un
axe, d’un nom d’élément et d’un prédicat éventuel. Les axes permettent de définir le sens de
parcours du document XML. XPath définit un grand nombre d’axes comme enfant, descendant,
parent, ancêtre, frère suivant, . . . Nous présenterons les principaux axes XPath plus loin dans
ce chapitre, au point 4.2.1. Les noms d’éléments sont similaires aux noms de dossiers ou de
répertoires des systèmes de fichiers. Ils permettent de définir les éléments XML par lesquels le
chemin doit passer. Les prédicats sont des expressions logiques relatives à un élément. Ils doivent
être écrits entre crochets et permettent de filtrer les éléments lors du parcours.
Les expressions XPath sont ainsi faites qu’il est très facile de les comprendre en les lisant.
Nous ne nous attarderons donc pas sur leur définition formelle. Cependant, certains concepts ne

4.2 XPath 29
sont peut être pas évidents d’un premier abord. Nous allons donc les détailler dans la suite de
ce chapitre.
XPath n’est pas exactement un langage de requêtes, car, bien qu’il permette de poser des
conditions et d’obtenir des informations sur un document, il ne permet pas de changer, par
exemple, la structure du document. Malgré cela, XPath est très utile et relativement simple à
comprendre et à assimiler. Cela en fait le standard pour l’expression de chemin sur un arbre
XML. Il est utilisé à la fois pour XSLT et pour XQuery, le langage de requêtes recommandé par
le W3C.
4.2.1 Les axes XPath
Axes Ensemble de nœuds résultant
parent Le premier nœud sur le chemin de u vers le nœud racine
ancestor Tous les nœuds sur le chemin de u vers la racine
ancestor-or-self u et tous les nœuds sur le chemin vers la racine
child Les descendants directs du nœud u
descendant Tous les nœuds dont u est l’ancêtre
descendant-or-self u et tous les nœuds dont u est l’ancêtre
preceding Les nœuds précédents le nœud u (exceptés les ancêtres) dans l’ordre
du document
following Les nœuds suivants le nœud u (exceptés les descendants) dans l’ordre
du document
preceding-sibling Les frères précédents du nœud u dans l’ordre du document
following-sibling Les frères suivants du nœud u dans l’ordre du document
attribute Les attributs du nœud u
self u
16 Tab. 4.1 – Sémantique Chapter des1. axes Extensible XPath pour Mark-up le nœud u. Language (XML)
2
1
3 4
5
0
6
7
8 9
2
1
3 4
5
0
6
7
8 9
2
1
3 4
(a) (b) (c)
5
0
6
7
8 9
Fig. 4.1 – Sémantique des axes XPath : (a) parent : :*, (b) ancestor : :* et (c) ancestor-
Fig. or-self 1.3. : :* XPath à partir semantics: du nœud 7. signposted nodes are nodes of the result forest if an
(a) parent::*, (b) ancestor::*, and (c) ancestor-or-self::* step is taken from context
nodeXPath 7. définit une famille de 13 axes. Un axe est un type de relation qu’un élément du document
XML entretient avec les autres éléments. Les axes les plus courants sont l’axe « enfant »
0
0
0
(child) et l’axe « descendant ou soi » (descedant-or-self ). Ces deux axes peuvent être abrégés res-
1
6
1
6
1
6
pectivement grâce aux symboles / et //. Ainsi, les deux expressions suivantes sont équivalentes.
2
3 4
5
7
8 9
2
3 4
5
7
8 9
2
3 4
(a) (b) (c)
5
7
8 9
Fig. 1.4. XPath semantics: signposted nodes are nodes of the result forest if an

(a) (b) (c)
Fig. 1.3. XPath semantics: signposted nodes are nodes of the result forest if an
(a) 4.2parent::*, XPath (b) ancestor::*, and (c) ancestor-or-self::* step is taken from context 30
node 7.
2
1
3 4
5
0
6
7
8 9
2
1
3 4
5
0
6
7
8 9
2
1
3 4
5
0
6
7
8 9
(a) (b) (c)
1.5. Another XML Technologies 17
Fig.
1.5.
4.2
Another
– Sémantique
XML Technologies
des axes XPath : (a) child : :*, (b) descendant : :*
17
et (c)
Fig. descendant-or-self 1.4. XPath semantics: : : à 0partirsignposted
du nœud 1. nodes are nodes of the result forest if an
0
(a) child::*, (b) descendant::*, 1
6 and (c) descendant-or-self::* 1
6 step is taken from
context node 1.
0
0
1.4.2 XQuery2
2
3 4
The XQuery [80] is a hopeful XML query language today. A subset of the XPath is a
part of the XQuery but more (a) complex constructs are put into the (b) language. Therefore, the
XQuery Fig. is1.5. said to XPath be too semantics: complex. signposted nodes are nodes of the result forest if an
Fig. (a) 4.3 preceding::* – Sémantique and des axes (b) following::* XPath : (a) preceding step is taken : :*, from(b) context following node : 6 and :* à1, partir re- du
Fig. 1.5. XPath semantics: signposted nodes are nodes of the result forest if an
Example nœud spectively. 6 et 11.9 respectivement.
(XQuery queries).
(a) preceding::* and (b) following::* step is taken from context node 6 and 1, respectively.
0
In Listing 1.6 three XQuery queries are shown.
0
1. doc(’books.xml’)/books/book[price50
Fig. order 4.4 by – $x/name Sémantique des (a) axes XPath : (a) preceding-sibling (b) : :*, (b) followingsibling
return Fig. $x/name : 1.6. :* àXPath partir du semantics: nœud 6 et signposted 2 respectivement. nodes are nodes of the result forest if an
(a) preceding-sibling::* and (b) following-sibling::* step is taken from context
3. node Fig. 61.6. and 2, XPath respectively. semantics: signposted nodes are nodes of the result forest if an
La { première (a) preceding-sibling::* est réduite, l’autre est and complète (b) following-sibling::* :
step is taken from context
node for $b 6 and in doc(’books.xml’)/books/book,
2, respectively.
/ clients / client $n in $b/name, [ @id ="1548"]/ nom
/ child :: clients $a in $b/author / child :: client [ @id ="1548"]/ child :: nom
return $n in $b/name,
D’autres raccourcis $a in $b/author sont fournis par XPath, par exemple,
return { $n }
⊲ l’expression { $a } ./ décrit le nœud contexte.
{ $n }
⊲ l’expression } { $a ../ } indique le nœud parent.
⊲ l’expression // dénote le nœud racine, mais pour une expression de type a//b, cette
}
expression dénote n’importe quel nœud b descendant du nœud a.
1.5 Another XML Technologies
6
1
3
2
4
3 2 4
5
5
0
7
6
8
7
9
8 9
76
8 7 9
Le tableau 4.1 liste les axes XPath et explique brièvement leur sémantique. Les figures 4.1,
4.2, 1.5 4.3 et 4.4 Another illustrent la sémantique XML Technologies
des principaux axes XPath.
There are a lot of technologies related to the XML. Due to the fact that this book is aimed
only to indexing XML data some of them are briefly described. SOAP [91] is the Simple
Object There are Access a lotProtocol of technologies used forrelated invoketo code theoffered XML. by Due Web to the services fact that overthis the Internet book is aimed using
XML only to and indexing HTTP. XML data some of them are briefly described. SOAP [91] is the Simple
Object Access Protocol used for invoke code offered by Web services over the Internet using
XML and HTTP.
2
1
5
6

4.3 XQuery 31
4.3 XQuery
4.3.1 Introduction
En 1998, le W3C a commencé à étudier un langage de requêtes pour XML. Un groupe de
travail a ainsi été constitué et une étude comparative de nombreux langages a été faite [25].
Celle-ci a mis en évidence l’importance de décomposer une requête en trois parties :
⊲ un motif qui associe des variables à des portions de documents,
⊲ un filtre optionnel qui sélectionne une partie des résultats obtenus grâce au motif et
⊲ un constructeur qui définit la structure de chaque résultat de la requête.
Un peu plus tard, un document du W3C [26] posera le cadre du futur XQuery. Les objectifs
principaux y sont décrits et une notion importante y est définie : les requêtes devront pouvoir
porter sur un simple document XML ou sur une collection de documents. Elles devront pouvoir
sélectionner des documents entiers ou ne garder que des sous-arbres qui remplissent certaines
conditions de contenu ou de structure.
Les objectifs principaux repris dans ce document sont les suivants :
⊲ l’importance de la déclarativité pour une requête, avec le découpage de la requête en
trois parties,
⊲ la possibilité de porter une condition sur du texte,
⊲ la présence de quantificateurs existentiels et universels (ce qui manque cruellement à
SQL),
⊲ la combinaison d’informations de différentes parties d’un ou de plusieurs documents,
⊲ l’agrégation d’informations à partir de documents proches,
⊲ le tri sur les éléments,
⊲ l’imbrication de requêtes (nesting),
⊲ et l’opération sur les noms des éléments XML.
XQuery [22] est donc né à partir de ces recommandations et objectifs. Le langage a été conçu
pour permettre des requêtes précises et facilement compréhensibles. Il introduit un type de requête
nouveau, basé sur des expressions FLWR (prononcez flower) comparables aux expressions
select-from-where de SQL. XQuery est un langage basé sur Quilt [27] et emprunte de nombreuses
idées à XQL [28], XML-QL [29], SQL et OQL [30].
XQuery est un langage fonctionnel dont chaque requête est une expression de différents types
comme des expressions de chemin, des expressions FLWR, des expressions conditionnelles ou
des fonctions. Les expressions de chemin sont basées sur la syntaxe XPath. La recommandation
XPath 2.0 est entièrement liée à XQuery.

4.3 XQuery 32
4.3.2 Expressions FLWR
La caractéristique principale de XQuery est qu’il utilise des expressions FLWR pour l’écriture
de requêtes. Son nom vient des 4 clauses principales suivantes :
⊲ for : mécanisme d’itération sur un ensemble de nœuds.
⊲ let : permet l’assignation de variables.
⊲ where : les clauses for et let génèrent un ensemble de nœuds XML qui peuvent être
filtrés par des prédicats de la clause where.
⊲ return : construit le résultat pour chaque nœud vérifiant la clause where.
Une expression FLWR peut se comparer à une expression type SQL select-from-where
mais leurs fonctionnements respectifs sont assez différents. En effet, le principe est inversé d’un
type d’expression à l’autre. Par exemple, en SQL, la construction des résultats se fait à l’aide
de la clause select, au début de la requête. Tandis qu’en XQuery, elle se fait à l’aide de la
clause return en fin de requête. Le fonctionnement et la syntaxe principale de ces expressions
est illustré à la figure 4.5 et 4.6.
clause for
clause let clause where clause order by
Fig. 4.5 – Expression FLWR.
for et let
where
order by
return
Liste de tuples et variables
Tuples et variables filtrés
Tuples ordonnés
Résultats XML (arbre de tuples)
clause return
Fig. 4.6 – Représentation schématique du fonctionnement d’une expression FLWR.

4.3 XQuery 33
A titre d’illustration, observons la requête FLWR suivante qui liste les noms de tous les
clients ayant acheté au moins deux produits :
for $client in // client
let $produits := // commande [ client = $client / @id ]// article
where count ( $produits ) >= 2
return
{ $client / nom / text () }
La clause for permet d’itérer sur tous les clients du fichier. Pour chaque client, la clause let va
sélectionner la liste de tous les produits achetés par ce client. C’est ici qu’a lieu la jointure, grâce
à un prédicat sur les commandes. En effet, on ne sélectionne que les commandes relatives au
client courant, retenu par la clause for. Ensuite, la clause where filtre les résultats, en appliquant
la fonction d’agrégation count() sur les résultats de la clause let. Pour finir, on construit le
résultat à l’aide de la clause return.
4.3.3 Quantificateurs
Tout comme SQL, XQuery possède un quantificateur existentiel : some. XQuery définit aussi
un quantificateur universel every. Ce quantificateur manque cruellement à SQL. Lors des cours
de bases de données suivis pendant mon cursus universitaire [31], de nombreux exemples de cette
limitation ont été abordés. En effet, comme il n’y a pas de quantificateur universel dans SQL,
il était nécessaire de s’aider de la logique pour transformer les requêtes universelles en requêtes
utilisant des quantificateurs existentiels niés. Cela rend ces requêtes SQL particulièrement difficiles
à lire et à comprendre et donc compliquées à maintenir. Un tel quantificateur universel est
donc plus que bienvenu dans XQuery. La syntaxe de ces quantificateurs est illustrée à la figure
4.7.
Fig. 4.7 – Fonctionnement des quantificateurs XQuery.
4.3.4 Opérateurs de comparaison d’ordre
Comme nous l’avons vu précédemment au point 3.6.1, l’ordre d’un document XML peut être
de la plus grande importance. Le groupe de travail autour d’XQuery a pris en compte ce constat
et XQuery fournit donc des opérateurs supplémentaires permettant de tester si un élément est
situé après ou avant dans l’ordre du document XML. Ces deux opérateurs sont < < et > > et
signifient respectivement avant et après.

4.3 XQuery 34
Pour illustrer la nécessité de tels opérateurs de comparaison, considérons un document XML
traitant de la cardiologie. Cet exemple est repris de [32]. Ce document contient diverses informations
comme des diagnostics, des stratégies de traitement et des procédures médicales détaillées.
Il peut être intéressant d’utiliser XQuery pour trouver des cas d’exceptions comme, par exemple,
une procédure médicale dans laquelle la première incision est faite avant d’administrer un anesthésiant
au patient.
Il est à noter que l’ordre du document n’a rien à voir avec la clause order by disponible
également. Cette dernière trie les résultats dans un ordre alphabétique ou numérique sur base
d’un ou plusieurs paramètres. Elle a le même comportement que son équivalent SQL.
4.3.5 Fonctions
XQuery permet de définir et d’utiliser des fonctions. Le prototype de base d’une fonction est
illustré à la figure 4.8.
Fig. 4.8 – Prototype d’une fonction en XQuery.
Les fonctions XQuery doivent respecter certaines règles comme le fait que tous les types
utilisés doivent l’être fortement, qu’ils soient des types d’arguments ou le type de sortie. Les
fonctions peuvent s’appeller elles-mêmes ou en appeller d’autres.
4.3.6 Traitement
Il faut différencier deux grandes familles de traitement des requêtes XQuery : traitement en
flux ou traitement basé sur les indexes.
Dans le premier cas, le moteur XQuery ne connaît pas les données sur lesquelles il doit
exécuter la requête. Le document XML à interroger arrive comme un flot (stream) dans le
moteur de requête. Le document est donc lu séquentiellement par le moteur de requête et ne
peut être lu qu’une seule fois.
Dans le deuxième cas, les documents sur lesquels porte la requête XQuery sont connus et
indexés. Le traitement de la requête sera donc différent, puisqu’une bonne partie des informations
– comme la structure du document – est déjà connue et qu’il ne faut pas lire les documents XML
séquentiellement parce que ceux-ci sont déjà été indexés.
Le traitement des requêtes sera donc totalement différent dans les deux cas de figure.

4.3 XQuery 35
4.3.7 Limitations
De nombreuses discussions à propos d’XQuery dans des articles scientifiques [33, 34, 35, 36],
dans les listes de discussions et des livres [24] mettent en évidence les limitations d’XQuery et
proposent des solutions.
XQueryX
Pour commencer, XQuery, bien qu’il soit un langage d’interrogation pour XML, ne respecte
pas la syntaxe XML. XQueryX [35] a donc été proposé. XQueryX est une syntaxe alternative
pour XQuery, où une requête est représentée comme un document XML bien formé. XQueryX
a été développé pour répondre au sentiment d’une partie des personnes du monde XML :
« XML est une bonne façon de représenter des choses, et par conséquent, chaque
chose devrait être représentée en XML »
Par exemple, un des avantages de XML Schéma par rapport aux DTD est qu’un Schéma
XML est un document XML tandis qu’une DTD ne l’est pas. Les avantages principaux de la
représentation XML de XQuery sont les suivants :
⊲ valider les requêtes XQueryX à l’aide d’un Schéma XML.
⊲ créer des requêtes à l’aide d’un outil graphique XML existant.
⊲ sauvegarder les requêtes de la même manière que les autres documents XML.
⊲ transférer des requêtes via un protocole comme SOAP.
⊲ interroger les requêtes XQueryX à l’aide XPath ou d’XQuery.
⊲ intégrer des requêtes dans un document XML.
Un défaut d’XQueryX est qu’il est plus difficile à lire par une personne et plus verbeux
que XQuery, nous en verrons un exemple plus loin. Un argument en réponse à cela est que
de moins en moins de personnes introduisent leurs requêtes manuellement. Il utilisent plutôt
des applications graphiques ou écrivent des programmes pour les aider à rédiger leurs requêtes.
Cet argument n’est pas partagé par toute la communauté XML. Néanmoins, la traduction d’un
type vers un autre est très facile et bien documentée. Les deux représentations devraient donc
exister en parallèle, chacune adaptée à certains types d’utilisation. Pour illustrer cela, observons
la différence entre les deux requêtes suivantes, empruntées au W3C, la première en XQuery et
la seconde en XQueryX.
for $b in document (" bib . xml ") // book
where $b/ publisher = " Morgan Kaufmann "
and $b/ year = "1998"
return $b/ title
< q:forAssignment variable ="$b">
< q:function name =" document ">
< q:constant datatype =" charstring ">

4.3 XQuery 36
bib . xml
< q:identifier >
book
< q:where >...
< q:return >...
Recherche textuelle
XPath et XQuery ne disposent pas d’opérateurs et de fonctions adaptées à la recherche
textuelle (full-text query) dans un document XML. Par exemple, il n’existe ni de fonction de
recherche insensible à la casse, ni de fonction de recherche de texte à la structure du document.
Or, XML étant énormément utilisé dans les sites Web, de telles fonctionnalités seraient les
bienvenues pour fabriquer aisément un moteur de recherche efficace.
eXist, une base de données XML native, implémente une série d’opérateurs et d’indexes pour
pallier à ce manque. Nous en parlerons en détail au point 5.4 consacré à eXist.
Mise à jour
Un autre manque de XQuery est qu’il ne possède pas d’opérateur permettant d’ajouter des
données ou de les mettre à jour. XQuery permet uniquement de consulter des informations sans
pouvoir les modifier. Dans le contexte des bases de données, il s’agit d’un défaut important. Par
contre, pour les processeurs XQuery qui travaillent en lecture séquentielle, cela ne pose pas de
problème car leur but n’est jamais de modifier les données sources.
Les moteurs commerciaux qui ont implémenté XQuery proposent des extensions permettant
d’éviter ce problème, mais rien n’est standardisé. XML:DB 1 , la communauté du logiciel libre
autour des bases de données XML, propose un langage de mise à jour : XUpdate [37]. Celui ci
est implémenté dans eXist, une base de données XML native dont nous reparlerons.
Groupement
Dans le domaine de l’analyse de données (OLAP), les groupements de données en fonction
de la valeur d’un ou plusieurs de leurs attributs sont très fréquents. C’est d’ailleurs l’opération la
plus utilisée dans ce domaine. Par exemple, le dirigeant d’une entreprise peut avoir besoin d’un
tableau représentant son chiffre d’affaires par région du pays, par magasin et par couleur pour
les chaussures qu’il vend. Il pourra ainsi prévoir la quantité de chaussures vertes à stocker dans
1 http://xmldb-org.sourceforge.net

4.4 Autres langages d’interrogation 37
son magasin de Liège pour les mois suivants. En SQL, le mot clé GROUP BY existe et permet de
faire ce genre de requêtes. Des extensions sont disponibles comme ROLLUP et CUBE. Ces mots clés
permettent de grouper des tuples selon plusieurs critères et aident à ce que les requêtes soient
plus facilement lisibles.
XQuery ne possède pas un tel opérateur de groupement. Les groupements sont possibles
grâce à une combinaison de fonctions distinct-values() mais les requêtes sont difficiles à
écrire et à lire. Elles peuvent aussi être compliquées à utiliser. Plusieurs études [36, 38, 39, 40]
ont été faites sur la nécessité d’ajouter une clause group by au squelette des expressions FLWR
d’XQuery. Nous en reparlerons plus loin dans le chapitre 7 entièrement consacré à ce problème.
4.4 Autres langages d’interrogation
4.4.1 XSLT
XSLT, Extensible Stylesheet Language Transformations est un langage de transformation de
documents XML. Il permet de transformer un document XML d’un certain type, comme une
page XHTML en un document XML d’un autre type, comme un document PDF. La syntaxe
XSLT respecte la syntaxe XML. Une requête XSLT sera donc un document XML bien formé.
Ce langage a été créé en 1999 par le W3C [20]. Il utilise les expressions de chemin XPath.
Le langage XSLT est un langage déclaratif. Une requête XSLT, ou plutôt une feuille de style
(stylesheet) XSLT, consiste en un ensemble de règles spécifiant ce qu’il faut ajouter à l’arbre de
sortie quand le processeur XSLT trouve un nœud qui rencontre les conditions de la règle.
XSLT est le langage de transformation XML le plus répandu à l’heure actuelle. Le site du
Service Informatique et Réseaux de l’Ecole Polytechnique de l’ULB 2 l’utilisait pour générer les
pages relatives à son catalogue de publications. De nombreuses implémentations de processeurs
XSLT existent. Citons SAXON (saxon.sourceforge.net) de Michael Kay, une personne éminente
dans le domaine des langages XML. Son processeur SAXON est souvent cité comme la
référence en la matière.
Ce langage ne nous intéresse pas dans le domaine des bases de données car son mode de
traitement est séquentiel. Il n’est pas fait pour utiliser des données indexées, ce qui le rend moins
performant pour traiter un grand nombre de données. XSLT a été étudié pour transformer des
documents, comme par exemple proposer une fonctionnalité de transformation en PDF des pages
XHTML d’un site Web.
Comparaison entre XSLT et XQuery
Une comparaison entre XQuery et XSLT [41] montre une zone de recouvrement entre les
fonctionnalités fournies par les deux langages. L’article montre que les use cases de XQuery [42]
peuvent se réécrire sans problèmes en XSLT. Une grande partie de ce recouvrement vient du
fait que XPath est utilisé dans les deux langages.
2 http://cs.ulb.ac.be

4.4 Autres langages d’interrogation 38
L’avantage principal d’XQuery réside en sa facilité d’utilisation et de compréhension, dans
son typage fort des données et sa capacité d’optimisation. En effet, les expressions FLWR sont
faciles à lire et à écrire. Les différentes clauses sont bien séparées, comme en SQL. En XSLT, les
règles tiennent en une seule ligne, les conditions étant mélangées avec l’expression, ce qui les rend
difficiles à lire et à comprendre. XQuery utilise un typage fort des données, ce qui permet d’avoir
une programmation plus sûre, les erreurs de type étant détectées au moment de la compilation
de la requête. Pour finir, de par la séparation des clauses des expressions FLWR, XQuery peut
bénéficier d’optimisations physiques, logiques ou de réécritures comme celles proposées dans [43].
4.4.2 Lorel
Lorel [23] a été conçu comme un langage de requêtes pour des données semi-structurées, puis
a été étendu pour XML. Il est inspiré de SQL et de OQL. La syntaxe de base d’une requête
Lorel est une expression de la forme :
select constructeur
from motif
where filtre
Un motif définit une relation en associant des variables à des sous-ensembles, comme en
OQL, le langage des bases de données objets. Le constructeur crée un nouvel objet complexe
pour chaque tuple de cette relation. La clause where est classique, il s’agit d’un filtre.
Cette syntaxe est plus déclarative que le FLWR de XQuery mais reste assez verbeuse. Lorel
dispose d’expressions de chemin très puissantes (dans un graphe ou dans un arbre XML) mais
n’est pas typé et repose sur une utilisation intensive de règles de conversion.
4.4.3 CDuce
CDuce est un langage fonctionnel pour la transformation de structures. Il est orienté XML,
centré sur les types et basé sur le filtrage par expressions régulières. Il est issu d’une thèse de
l’ENS de Paris en 2003. CDuce [21] est élaboré sur base de XDuce (prononcez transduce), un
langage fonctionnel pour la manipulation de structures XML.
La particularité principale de CDuce est l’accent mis sur les types. En effet, les types sont
utilisés partout : dans la validation des requêtes, dans la sémantique des fonctions et dans la
compilation, qui est dirigée et optimisée selon les types, un peu comme XQuery.
A l’heure actuelle, CDuce est encore un outil d’expérimentation et n’est pas totalement
opérationnel.
4.4.4 SQL/XML
SQL/XML [44] n’est pas, à proprement parlé, un langage d’interrogation XML. Il s’agit
principalement d’extensions et de fonctions pour SQL destinées à traiter des documents XML

4.5 Conclusions 39
ou à produire des résultats sous forme de documents XML. Ce langage a été développé principalement
par Microsoft et Oracle pour répondre aux demandes de leurs clients à propos de
XML. SQL/XML permet également d’utiliser des expressions XQuery sur des documents XML
convertis en tables relationnelles. A titre d’illustration, une requête XQuery encapsulée dans une
requête SQL/XML est présentée ci-dessous :
SELECT XMLQUERY (
’for $m in $col / commande
where $m/ client / continent = ’EUROPE ’
return $m/ client /nom ’
PASSING commande AS ’COL ’
RETURNING CONTENT NULL ON EMPTY
) AS result FROM COMMANDES_XML
COMMANDES_XML est une table relationnelle dans laquelle chaque ligne représente une commande
dans son format XML. Les résultats de cette requête sont les suivants :
Paul Dupond
Louis Dubois
...
Ce langage ne nous intéresse pas dans le cadre de ce mémoire, car il est basé sur des techniques
relationnelles alors que nous nous occupons principalement du traitement de requêtes dans des
bases de données XML natives. Cependant, nous trouvions important d’en parler ici à titre
d’information et de comparaison.
4.5 Conclusions
Dans ce chapitre, nous avons analysé les différents langages d’interrogation pour XML. Nous
nous sommes focalisés principalement sur XPath et XQuery, des langages très prometteurs dont
nous avons toutefois identifié certains problèmes ou manquements.
Dans le chapitre suivant, nous allons introduire les différents types de bases de données
permettant d’interroger des documents XML à l’aide de ces langages, et tout particulièrement
à l’aide de XQuery. Nous accorderons une grande importance à l’indexation de ces documents
XML afin de pouvoir utiliser ces langages de façon performante.

Chapitre 5
Les bases de données XML
Dans ce chapitre, nous allons analyser les différents types de bases de données permettant
de gérer des documents XML. Nous nous attarderons tout particulièrement sur les bases de
données XML natives, en détaillant leurs structures d’indexes ainsi que les algorithmes associés.
Pour finir, nous analyserons en détail eXist, un moteur de base de données XML native libre
qui implémente XQuery.
Contenu
5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.2 Types de bases de données XML . . . . . . . . . . . . . . . . . . . . . 41
5.3 Bases de données XML natives . . . . . . . . . . . . . . . . . . . . . . 43
5.4 eXist, une base de données XML native libre . . . . . . . . . . . . . 58
5.5 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.1 Introduction
XML est un format d’échange de données de plus en plus utilisé. Il est alors logique de
posséder des outils permettant de les stocker, de les interroger, de garantir leur intégrité, etc.
C’est le rôle d’un système de gestion de base de données (SGDB). Généralement, on attend d’un
tel système les caractéristiques suivantes :
⊲ Des outils d’interrogation, tels que les langages SQL ou XQuery.
⊲ Des capacités de transactions, incluant les propriétés ACID 1 . C’est à dire qu’un tel système
doit offrir l’atomicité des opérations, la consistance de la base de données dans
son ensemble, l’isolation des opérations des différents utilisateurs et la résistance des
opérations à un problème système.
⊲ L’échelonnabilité (scalability) et la robustesse.
⊲ Une gestion de la sécurité et des performances. Par exemple, la gestion des utilisateurs,
des index, de l’optimisation, etc.
1 ACID sont les initiales de « Atomicity », « Concistency », « Isolation » et « Durabitily ».
40

5.2 Types de bases de données XML 41
Plusieurs sortes d’outils permettent de stocker et gérer des documents XML. Les principaux
outils existants sont les bases de données relationnelles avec support XML, les bases de données
XML natives et les bases de données objets.
Il est important de remarquer que des données XML peuvent être très différentes des données
relationnelles classiques. Nous en ferons une analyse détaillée dans le chapitre suivant, mais
notons déjà les différences suivantes :
⊲ L’ordre d’un document XML est important.
⊲ Les documents XML peuvent contenir des données non numériques.
⊲ La structure d’un document XML est arborescente.
⊲ Un document XML ne respecte pas nécessairement un schéma strict comme les données
relationnelles.
⊲ La structure d’un document XML contient une sémantique intrinsèque.
En considérant les points soulevés ici, nous introduirons un à un les différents types de
bases de données XML en nous concentrant tout particulièrement sur les bases de données XML
natives, systèmes particulièrement flexibles et prometteurs.
5.2 Types de bases de données XML
5.2.1 Bases de données relationnelles
Depuis les années 1980, les bases de données relationnelles (SGDBR) sont les plus utilisées
pour stocker et interroger des informations. La plupart des entreprises dépendent d’un tel système
pour stocker et protéger leurs données. Les milliards de dollars investis dans les systèmes
commerciaux comme Oracle et IBM DB2 leur ont donné une énorme force dans le domaine de la
gestion de données. De tels systèmes sont aujourd’hui très performants, echelonnables (scalable)
et fiables.
Dans le début des années 2000, la plupart des moteurs relationnels commerciaux ont intégré
le support de l’XML. Au départ, il ne s’agissait que de stocker et de récupérer l’entièreté d’un
document XML, sans traitement particulier des données contenues dans le document. Certains
systèmes stockaient les documents XML à la façon d’une longue chaîne de caractères dans des
colonnes CLOB 2 tandis que d’autres découpaient les données XML comme les éléments et les
attributs en plusieurs tables. Ce mécanisme est appelé shredding, ou « mise en lambeau » d’un
document XML.
L’expérience aidant et les besoins d’utiliser XML grandissant, les moteurs relationnels ont
intégré un support direct de XML, à l’aide d’un type de données spécialisé. Un type natif XML
a été défini et de nouvelles fonctions ont été développées comme, par exemple, transformer
des données relationnelles en XML. De plus, une multitude de moyens ont été inventés pour
interroger le contenu des documents XML stockés dans ce type natif XML. Les principaux sont
2 CLOB, Character Large Object, objet pouvant contenir une longue chaîne de caractères.

5.2 Types de bases de données XML 42
XPath, XQuery et SQL/XML. Enfin, ces systèmes offrent un support des méta-données, bien
souvent à l’aide d’XML Schéma.
De par leur ancienneté et leur fiabilité, les bases de données relationnelles sont une bonne
solution pour gérer des données XML mais sont malheureusement conceptuellement inadaptées
à l’XML. En effet, un document XML représente un arbre et n’est pas nécessairement aussi bien
structuré qu’une table relationnelle. De plus, la mise en lambeau des documents XML conduit
souvent à une perte de performance et à une difficulté d’écriture des requêtes de par la structure
relationnelle complexe qu’elle implique.
5.2.2 Bases de données objet
A la fin des années 80, une nouvelle forme de système de gestion de base de données a été
introduite sur le marché. Il s’agit des SGDBOO, les Systèmes de Gestion de Base de Données
Orientées-Objet. Ces systèmes gèrent les données comme des objets, plutôt que comme des
tables, des lignes ou des colonnes. En effet, il est plus naturel de représenter le monde réel
comme une collection d’objets, chacun ayant un état et des comportements spécifiques. De plus,
les langages de programmations orientés-objet commençant à être à la mode à cette époque, les
développeurs voulaient pouvoir stocker de manière persistante leurs objets, ce que les SGDBOO
permettent de faire assez proprement.
Malheureusement, les SGDBOO souffrent de ne pas avoir un langage de requête commun
et standardisé, comme l’est SQL pour les SGBDR. La communauté existante autour des bases
de données orientées-objet a donc décidé d’adapter SQL. Le résultat en est OQL, un langage
permettant uniquement de chercher et de récupérer des données, mais pas de les mettre à jour.
Ce type de base de données aurait pu être très intéressant pour notre étude car on peut
considérer un document XML comme une collection hiérarchisée d’objets. En effet, chaque nœud
d’un document XML a une identité unique, comme les objets et un objet peut en inclure d’autres.
Malheureusement, l’ODMG, le groupe de gestion des bases de données objets, n’a jamais publié
de version permettant de gérer l’XML. Seul un groupe de chercheurs a créé un tel système, devenu
libre par la suite, Ozone, qui, selon eux, est totalement compatible avec le DOM du W3C. Il n’y
a donc pas sur le marché des SGBDOO commerciaux de produit qui intègre un support explicite
du XML, au sens d’Ozone. Une des raisons est probablement qu’aucun SGBDOO n’a réussi à
percer parmi les géants comme Microsoft et Oracle, sociétés qui ont intégré une gestion partielle
des objets dans leurs systèmes relationnels.
5.2.3 Bases de données XML natives
Depuis quelques années, on voit apparaître sur le marché des systèmes s’auto-décrivant
comme des bases de données XML natives. Ces systèmes supportent le document XML comme
unité fondamentale de stockage, implémentent des langages étudiés pour traiter du XML comme
XQuery et stockent les document XML suivant un modèle propre, compatible avec XML. Le
chapitre suivant est entièrement consacré à ce nouveau type de base de données.

5.3 Bases de données XML natives 43
5.3 Bases de données XML natives
5.3.1 Définition
Le terme Native XML Database (NXD), ou base de données XML native, est apparu pour la
première fois dans la campagne de publicité pour Tamino, une base de données XML native de
Software AG [45]. Depuis, grâce au succès de cette campagne, le terme est arrivé dans l’usage
courant par différentes entreprises développant des produits similaires. Etant devenu un terme
publicitaire, il n’a jamais eu de définition technique formelle. Une définition possible de ce qu’est
une base de données XML native serait la suivante :
⊲ Une base de données XML native définit un modèle logique pour un document XML.
Elle stocke et récupère les documents suivant ce modèle de données. Au minimum, il doit
inclure les éléments, les attributs, les PCDATA et l’ordre du document. Des exemples de
tels modèles sont le modèle XPath, le XML Infoset et les modèles utilisés par DOM.
⊲ Une base de données XML native gère le document XML comme une unité fondamentale
de stockage, comme une ligne dans une table relationnelle.
⊲ Les bases de données XML natives n’ont pas un modèle physique sous-jacent particulier.
Par exemple, le modèle physique peut être relationnel, hiérarchique, orienté objet ou
utiliser un format de stockage propriétaire comme des fichiers compressés indexés.
La première partie de cette définition est similaire à celle des autres types de bases de données,
définissant le modèle utilisé pour le stockage et l’interrogation. Dans le cas des bases de données
XML natives, le modèle de données peut être différent : il pourrait notamment supporter des
requêtes basées sur le modèle XPath en stockant les documents comme du texte. Dans ce cas, des
parties, comme les sections CDATA et l’usage des entités, sont stockées dans la base de données
mais pas incluses dans le modèle. Il existe un certain nombre de modèles pour XML comme
Infoset et DOM. Le modèle choisi pour faire une base de données XML native est toutefois
moins important que sa capacité à supporter arbitrairement la profondeur de l’imbrication des
nœuds, la complexité de leurs relations, leur ordre, leur identité, etc.
La seconde partie de cette définition considère que l’unité de stockage fondamentale dans une
base de données native XML est le document XML. Bien qu’il semble possible qu’une base de
données XML native puisse assigner ce rôle à des fragments de documents, l’unité de stockage
fondamentale reste effectivement le document XML dans la plupart des bases de données XML
actuelles.
La troisième partie de la définition pose que le modèle physique sous-jacent n’est pas important.
C’est exact et c’est certainement le cas pour toutes les sortes de base de données. Le
format de stockage physique utilisé par une base de données relationnelle n’est pas une condition
nécessaire au caractère relationnel de la base. De plus, il est tout à fait envisageable d’utiliser
un support relationnel pour fabriquer un moteur de base de données XML native comme eXist
l’a fait à ses débuts. Il est également possible dans un système relationnel d’utiliser un autre
support que des tableaux.
Les bases de données XML natives sont donc des bases données conçues spécialement pour
stocker des documents XML. Comme les autres bases de données, elles gèrent les transactions, la

5.3 Bases de données XML natives 44
sécurité, l’accès multi-utilisateurs, offrent des API de programmations, les langages de requêtes,
etc. La seule différence par rapport aux autres bases de données est que leur modèle de structure
interne est basé sur XML et sur rien d’autre, contrairement au modèle relationnel utilisé pour
les bases de données « XML-enabled ».
5.3.2 Utilisations
Les bases de données natives XML sont communément utilisées pour stocker des documents
XML orientés présentation. La raison principale en est leur support pour les langages de requêtes
XML. Ceux-ci permettent de poser des questions comme « Donnez moi tous les documents dans
lesquels le troisième paragraphe contient un mot en gras » ou encore pour limiter les recherches
textuelles à certaines portions d’un document. Ce genre de requêtes est difficile à écrire dans
un langage comme SQL. Une autre raison est que les bases de données natives XML préservent
l’ordre du document, les instructions de traitement ou les commentaires, ce que les bases de
données « XML-enabled » ne font pas nécessairement.
Les bases de données natives XML sont aussi utilisées pour intégrer des données. L’intégration
de données a été historiquement traitée au moyen de bases de données relationnelles fédérées et
celles-ci requièrent que toutes les sources de données soient adaptées au modèle relationnel. Or, ce
procédé est impossible ou complexe pour beaucoup de types de données et le modèle de données
XML fournit dès lors une plus grande flexibilité. Les bases de données XML natives gèrent
également les changements de schéma plus facilement que les bases de données relationnelles.
De plus, elles peuvent gérer des données sans schéma. Ces deux remarques sont importantes
quand on intègre des données de sources qu’on ne contrôle pas directement. Dans le cas de la
fédération des données pour un entrepôt, le fait que la base puisse supporter les changements de
schéma est très intéressant pour le développement des ETL, dont nous avons parlé au point 2.4
Une autre utilisation des bases de données XML natives est le stockage des données semistructurées,
comme les données financières ou biologiques, qui changent si fréquemment que
la définition d’un schéma complet est impossible. Les bases de données XML natives peuvent
gérer ce type de données car elles ne requièrent pas de schéma comme les bases de données
relationnelles.
La dernière utilisation principale d’une base de données XML native est la gestion de l’évolution
des schémas. Bien que les bases de données XML natives ne fournissent pas de solutions
complètes pour chaque besoin, elles fournissent plus de flexibilité que les bases de données relationnelles.
Par exemple, les bases de données natives XML ne requièrent pas que les données
existantes soient migrées vers un nouveau schéma. Elles peuvent prendre en charge les changements
de schéma et peuvent stocker des données même si elles ne sont pas conformes au
schéma.
5.3.3 Systèmes existants
Depuis quelques années, une multitude de bases de données XML natives apparaît sur le
marché. La plus connue est Tamino, de Software AG [45]. Berkeley DB [46] propose également

5.3 Bases de données XML natives 45
une version XML de son moteur. Ronald Bourret propose sur son site web [47] une liste détaillée
des produits existants. Nous vous invitons à consulter cette page pour de plus amples détails.
eXist est un moteur de base de données XML native libre qui implémente XQuery. Nous
avons choisi d’utiliser ce produit pour nos expérimentations, le moteur étant complet et implémentant
XQuery. De plus, les développeurs sont très réactifs et sympathiques. La section 5.4 de
ce mémoire est totalement consacrée à eXist.
5.3.4 Indexation des documents XML
Pré-requis
D’un point de vue base de données, le format XML est une nouvelle approche pour modéliser
l’information. L’implémentation d’un système nous permettant de stocker et d’interroger
efficacement des documents requiert le développement de nouvelles techniques d’indexation.
Expressions de chemin Les langages de requêtes XML comme XPath, Quilt ou XQuery utilisent
des expressions de chemin pour naviguer à travers la structure logique et hiérarchique d’un
document XML. Ce dernier est modélisé comme un arbre ordonné. Une expression de chemin
représente un ensemble de nœuds de l’arbre. Par exemple, l’expression commande//article/nom
sélectionne tous les éléments nom qui sont des enfants des éléments article qui ont un élément
ancêtre dénommé commande. Le double slash dans la sous-expression commande//article
spécifie qu’il doit y avoir un chemin menant d’un élément commande à un élément article.
Cela correspond à la relation ancêtre-descendant. Dans cet exemple, seuls les éléments article
descendants d’un élément commande seront sélectionnés. Le simple slash dans la sous-expression
article/nom représente une relation parent-enfant. Cela va sélectionner uniquement les noms
dont le parent est un élément article. Le slash et le double slash sont respectivement des
abréviations pour les relations parent-enfant et ancêtre-descendant. Par exemple, l’expression
//article est un diminutif pour /descendant-or-self::node()/child::article.
Il est à noter que XPath définit également des relations supplémentaires entre les nœuds
comme frère-suivant et frère-précédent. Le résultat d’une expression de chemin est une séquence
de nœuds différents ordonnée selon l’ordre du document XML.
Prédicats Les nœuds sélectionnés à l’aide d’une expression de chemin peuvent être filtrés à
l’aide de prédicats. Un prédicat est une expression entourée de crochets. Le prédicat est évalué
pour chaque nœud de la séquence et renvoie une valeur de vérité, vrai ou faux. Les nœuds
sélectionnés pour lesquels le prédicat est faux sont éliminés de la sélection. Par exemple, pour
trouver toutes les commandes dont le nom d’un article contient la chaîne « Lampe », on peut
utiliser l’expression suivante :
commande // article [ contains (nom ,’ Lampe ’)]

5.3 Bases de données XML natives 46
La sous-expression de prédicat représente une sélection basée sur les valeurs tandis que la sousexpression
commande//article représente une sélection structurelle. Les sélections basées sur
les valeurs peuvent être faites sur les noms d’éléments, sur les noms et valeurs d’attributs et sur
les chaînes de caractères contenues dans un élément. Les sélections structurelles sont basées sur
les relations structurelles entre les nœuds, comme ancêtre-descendant ou parent-enfant.
De manière intuitive, on pourrait évaluer des expressions de chemin en parcourant tout
l’arbre de haut en bas ou de bas en haut. Cependant, malgré sa conception simple et propre,
cette approche s’avère inefficace pour de grandes collections de documents XML. Des travaux
à ce propos confirment ces dires [48, 49, 50]. Par exemple, considérons une expression XPath
sélectionnant tous les noms d’articles dans une collection de commandes :
/ commandes // article / nom
Dans une approche conventionnelle en amont (top-down), le processeur de requêtes devra suivre
tous les chemins commençant par commande pour tester si un descendant article existe. En
effet, il n’y a aucun moyen de déterminer les emplacements possibles des descendants article
à l’avance. Cela implique qu’un grand nombre de nœuds doivent être analysés pour tester si le
nœud est un élément et si son nom est article.
Il est donc évident qu’une structure d’index est nécessaire pour traiter efficacement des
requêtes sur des grandes collections de documents. Le plan d’indexation devra fournir de quoi
traiter des sélections basées sur les valeurs ainsi que des sélections structurelles. En ce qui
concerne la sélection basée sur les valeurs, des indexes classiques peuvent être utilisés comme les
arbres B+ dont nous parlerons au point suivant. Par contre, pour les sélections structurelles, ce
n’est pas aussi simple. En effet, pour accélérer le traitement d’une expression de chemin basée
sur des relations structurelles, le plan d’indexation devra supporter une identification rapide
de telles relations entre les nœuds comme les relations parent-enfant et ancêtre-descendant. Le
traitement des expressions se fera au maximum sur base des informations d’index et il faudra
donc limiter au maximum la nécessité d’accéder au document XML.
Indexation basée sur les valeurs
Pour indexer des données selon leurs valeurs, les structures de données communément utilisées
dans les bases de données sont les arbres B ou B-tree et leurs variantes, comme le B+-tree ou
arbre B+.
Les arbres B [51] sont des arbres balancés et triés qui permettent l’insertion et la suppression
de nœuds en complexité amortie logarithmique. La recherche dans un tel arbre est similaire
à celle effectuée dans un arbre binaire de recherche, c’est-à-dire en parcourant l’arbre de haut
en bas et en choisissant à chaque fois le fils correspondant à la fourchette de valeur que l’on
recherche.
L’idée principale des arbres B est que ses nœuds peuvent avoir un nombre variable de fils
dans une fourchette déterminée. Quand un nœud est inséré ou supprimé de l’arbre, le nombre
de fils d’un nœud varie et les nœuds sont restructurés afin de garder la structure définie. Ce
type d’arbre ne doit pas être re-balancé aussi fréquemment qu’un arbre binaire de recherche

5.3 Bases de données XML natives 47
Fig. 5.1 – Structure d’index basée sur les valeurs : arbre B+ simple (Source : Wikipedia).
auto-balancé classique mais peut prendre plus de place en mémoire car certains nœuds peuvent
ne pas être complètement remplis.
Une variante très utilisée dans l’indexation, l’arbre B+ [52], diffère des arbres B dans le
fait que toutes les données sont sauvegardées dans les feuilles de l’arbre. Les nœuds internes ne
contiennent que des clés et des pointeurs. Toutes les feuilles sont au même niveau et sont liées
ensemble à la manière d’une liste afin de gérer facilement les requêtes portant sur des fourchettes
de valeurs. Un exemple d’arbre B+ très simple, tiré de Wikipedia, est illustré à la figure 5.1.
Indexation structurelle
Un nombre important de recherches ont été faites récemment afin de concevoir des structures
d’index correspondants aux besoins spécifiques de XML. Plusieurs plans de numérotation pour
les documents XML ont été proposés [53, 54, 48, 55, 50, 49]. Un plan de numérotation assigne
un identificateur unique à chaque nœud dans l’arbre logique du document, comme en traversant
l’arbre en pré-ordre ou par niveau. Les identificateurs ainsi générés sont utilisés, dans le
plan d’indexation, comme référence au nœud actuel. Un plan de numérotation doit fournir des
mécanismes pour déterminer rapidement les relations structurelles entre une paire de nœuds et
identifier toutes les occurrences d’une telle relation dans un document ou dans une collection de
documents XML.
En résumé, un plan de numérotation doit supporter deux opérations basiques :
⊲ La décision : Pour deux nœuds donnés, décider s’ils ont une relation spécifique, comme
parent-enfant, ancêtre-descendant, frère-suivant, frère-précédent.
⊲ La reconstruction : Pour un nœud donné, déterminer les identificateurs des nœuds
de son voisinage comme, par exemple, le père, le frère suivant, le premier enfant, . . .
Dans les pages suivantes, nous allons détailler différents plan de numérotations. Nous nous
attarderons particulièrement sur ceux utilisés dans eXist.

language. Often, the processing XML queries is not too efficient, or algorithms and data
structures are not possible to apply for indexing huge volume XML data. Consequently,
these approaches are evaluated as well: the extent of implemented query language subset
and the efficiency of the query processing are compared.
5.3 Bases de données XML natives 48
2.1 Numbering Scheme
Numérotation To facilitatede XML Dietz query processing it is crucial to provide mechanisms to quickly determine
the ancestor-descendant relationship between XML tree nodes.
Le plan The de Dietz’s numérotation numbering de Dietz scheme [56] [22, est 23] le premier was theà first utiliser to use l’ordre treedetraversal parcoursorder de l’arbre to
pour déterminer determine the les relations ancestor-descendant structurellesrelationship ancêtre-descendant between any entre pair uneofpaire tree de nodes. nœuds Author donnée.
proposition was: for two given nodes x and y of a tree T , x is an ancestor of y if and only
La proposition originale est la suivante : Pour deux nœuds donnés x et y d’un arbre T , x est un
if x occurs before y in the preorder traversal of T and after y in the postorder traversal.
ancêtre d’y si et seulement si x apparaît avant y dans le parcours en pré-ordre de T et après y
dans leExample parcours 2.1 en post-ordre. (Dietz’s numbering scheme).
In Figure 2.1 an XML tree whose nodes are annotated by Dietz’s numbering scheme is
La figure 5.2 illustre un arbre XML numéroté avec ce plan de numérotation. Chaque nœud
shown. Each node is labeled with a pair of preorder and postorder numbers. In the tree,
possède weun canlabel tell composé node (1,4) deissa anplace ancestor dans ofl’ordre node (5,3), préfixe because et postfixe node (1,4) respectivement. comes beforeDans nodecet
arbre, (5,3) on voit in the quepreorder le nœud (i.e., (1, 4) 1 < est5) un and ancêtre after node du nœud (5,3) in (5, the 3) car postorder le nœud (i.e., (1, 4 4) > vient 3). Due avant
le nœud to (5, the3) fact enthat parcours 2 < 5 préordre but 2 < 3(1 node < 5) (2,2) et après is notle annœud ancestor (5, 3) of node dans (5,3). le parcours postordre
(4 > 3). Le nœud (2, 2) n’est pas un ancêtre du nœud (5, 3) car 2 < 3.
(2,2)
(1,4)
(3,0) (4,1)
(5,3)
(0,9)
(6,8)
(7,7)
(8,5) (9,6)
Fig. 5.2 – Arbre XML numéroté suivant la numérotation de Dietz.
Fig. 2.1. An XML tree whose node are annotated by Dietz’s numbering scheme
L’avantage de cette méthode est que la relation ancêtre-descendant peut être déterminée
en temps An constant obviousenbenefit examinant from this les approach labels desisnœuds. that thePar ancestor-descendant contre, en cas derelationship mise à jour, canune
réindexation
be determined
complète
in
de
constant
l’arbre
time
est nécessaire,
by examining
ce qui
the
fait
preorder
que cette
and
méthode
postorder
ne
numbers
sera pas
of
efficace
tree
nodes.
dans le domaine des bases de données, où les ajouts de données sont fréquents.
Numérotation basée sur la position des nœuds et leur profondeur.
Un plan d’indexation basé sur l’identificateur du document, la position des nœuds et sur leur
profondeur a été proposé par Zhang et al. [50] en 2001. Dans ce plan, un élément est identifié
par un quadruplet : l’identificateur du document, la position de départ dans le document, la
position de fin et le niveau de profondeur. Les positions sont exprimées en terme de nombre de
mots à partir du début du document XML. La proposition suivante permet de déterminer les
relations ancêtre-descendant entre une paire de nœuds : Un nœud x identifié par le quadruplet
(D1, S1, E1, L1) 3 est un descendant du nœud (D2, S2, E2, L2) si et seulement si
⊲ D1 = D2 et
⊲ S1 < S2 et
⊲ E1 > E2.
3 L’attribut L est utilisé uniquement pour les relations parent-enfant.

5.3 Bases de données XML natives 49
Numérotation XISS
Le système XISS, par Li et Moon en 2001 [48], propose un plan de numérotation basé sur
un parcours pré-ordre étendu. C’est une extension du plan de Dietz qui répond à son manque
de flexibilité en laissant des trous dans la numérotation. Ce plan assigne une paire de nombres
order et size à chaque nœud tel que :
⊲ Pour un nœud y et son parent x, order(x) < order(y) et order(y)+size(y)

5.3 Bases de données XML natives 50
Numérotation en arbre k-aire par niveau
Lee et al. [54] ont proposé un plan de numérotation qui modélise l’arbre du document XML
comme un arbre k-aire complet, où k est égal au nombre maximum de nœuds fils d’un élément
dans le document. Un identificateur unique est assigné à chaque nœud à l’aide d’un parcours
par niveau de l’arbre. La figure 5.4 montre les identificateurs assignés aux nœuds d’un simple
document XML, qui est modélisé par un arbre binaire (2-aire) complet. Comme l’arbre doit être
complet, des identificateurs vides sont insérés à différentes positions.
Marc Dupond
1234567
7654321
4
Marc Dupond
2
nom
5
1
contact
6
bureau
3
telephone
Identificateur
clairsemé
7
maison
12
14
8 9 10 11 13 15
1234567
7654321
Fig. 5.4 – Numérotation en arbre binaire complet.
Les identificateurs uniques générés par ce plan de numérotation ont quelques propriétés
importantes. En effet, depuis un identificateur donné, on peut déterminer facilement l’identificateur
de son nœud parent, de son nœud frère ou de ses nœuds enfants. Par exemple, pour un
arbre k-aire, on peut obtenir l’identificateur du parent d’un nœud identifié par i par la fonction
suivante :
(i − 2)
parenti = + 1
k
Pour obtenir l’identificateur du j e fils d’un nœud identifié par i, on utilise la fonction suivante :
parenti,j = k(i − 1) + j + 1
Cependant, la contrainte de complétude de l’arbre impose une restriction majeure sur la taille
maximale d’un document à indexer avec ce plan de numérotation. Par exemple, une commande
typique aura un nombre limité de sous-éléments comme un client et un magasin tandis que la
majorité des nœuds sont des articles, situés plus bas dans le parcours par niveau de l’arbre. Intuitivement,
on constate que, dans beaucoup de cas, un nombre trop important d’identificateurs
clairsermés seront utilisés, ce qui limitera la taille des documents que l’on pourra indexer en
fonction de leur structure.

5.3 Bases de données XML natives 51
Numérotation virtuelle par niveau
Le plan de numérotation implémenté dans eXist fournit une extension basée sur les arbres
k-aires vu au point précédent. Pour surmonter le problème de limitation de taille du document
à indexer, la contrainte de complétude de l’arbre a été partiellement oubliée en faveur d’un plan
de numérotation alternatif. Le document n’est plus vu comme un arbre k-aire complet. A la
place, le nombre d’enfants d’un nœud doit être recalculé pour chaque niveau de l’arbre de la
manière suivante : pour deux nœuds x et y d’un arbre, size(x) = size(y) si level(x) = level(y),
où size(n) est le nombre d’enfants d’un nœud n et level(m) est la longueur du chemin entre le
nœud racine de l’arbre et le nœud m. L’information additionnelle sur le nombre d’enfants qu’un
nœud peut avoir à chaque niveau de l’arbre est stockée avec le document dans un simple tableau.
La figure 5.5 montre les identificateurs générés par cette méthode pour le même exemple que
celui de la page précédente.
Marc Dupond
1234567
7654321
4
Marc Dupond
2
nom
8 9
5
1
contact
6
bureau
10
1234567
3
telephone
Identificateur
clairsemé
(nœud virtuel)
Fig. 5.5 – Numérotation virtuelle par niveaux.
7
maison
11
7654321
Cette approche tient compte du fait que les documents XML typiques ont généralement
un nombre beaucoup plus important de nœuds dans les couches basses de l’arbre que dans les
couches hautes. La limite de la taille des documents indexables est augmentée considérablement.
On peut donc indexer des documents plus grands, tout en consommant moins de mémoire car il
y a beaucoup moins d’identificateurs clairsemés (appelés ici nœuds virtuels, pour numérotation
virtuelle).
De même, insérer un nœud à un niveau bas de l’arbre n’a pas d’effet sur les identificateurs
uniques assignés aux nœuds des niveaux supérieurs. Il est aussi possible de laisser des identificateurs
clairsemés entre les nœuds existants pour éviter un réordonnancement fréquent des nœuds
lors des mises à jour des documents.

5.3 Bases de données XML natives 52
Ce plan de numérotation alternatif n’affecte pas les propriétés générales des arbres k-aires
vues au point précédent. Pour un nœud, il est toujours possible de calculer son parent, ses frères
ou ses enfants en utilisant les informations additionnelles sur le nombre de fils que chaque nœud
peut avoir à chaque niveau de l’arbre. On peut voir l’arbre ainsi construit comme un arbre
contenant des arbres k-aires où k est déterminé pour chaque nœud. Chaque axe de navigation
XPath est donc supporté par ce plan de numérotation.
Ce plan réduit significativement la taille de stockage d’un nœud dans le magasin XML d’eXist.
Il n’est en effet pas nécessaire de sauver des liens symboliques ou physiques vers le parent,
les frères, les enfants et les attributs. Pour accéder au parent d’un nœud, il suffit de calculer
son identificateur et de le rechercher dans l’index. Avec cette méthode, le nœud d’un élément
n’occupe pas plus que 4 ou 8 bytes dans le magasin XML d’eXist.
De plus, avec ce plan d’indexation, il est possible d’évaluer des expressions de chemin multiples,
ce qu’il est possible de faire avec XQuery. En effet, l’on peut réutiliser les informations
d’index d’une première expression dans le traitement d’une seconde expression.
Pour conclure, observons les avantages et inconvénients de cette approche. Les avantages
sont les suivants :
⊲ Le calcul des relations structurelles entre les nœuds est simple (opération de décision).
⊲ Depuis un identificateur, on peut reconstruire les identificateurs de tout le voisinage
(opération de reconstruction).
⊲ Tous les axes XPath sont supportés : enfant, descendant, ancêtre, parent, . . .
⊲ La méthode est efficace du point de vue de la place : tous les identificateurs peuvent être
restructurés facilement car on ne doit pas stocker les identificateurs de nœuds dans le
DOM.
Les désavantages sont les suivants :
⊲ L’encodage est clairsemé : on a besoin d’insérer des nœuds virtuels à cause de la contrainte
de complétude des arbres.
⊲ La taille d’un document est limitée. Bien que ce plan de numérotation augmente cette
limite significativement, il reste toujours une taille limite sur le nombre de bits utilisé
pour un identificateur (couramment 32 ou 64 bits).
⊲ La taille limite du document dépend de la structure de l’arbre et est compliquée à prédire.
⊲ La mise à jour peut entraîner une renumérotation complète de l’arbre.
Numérotation dynamique par niveau
En 2004, Boëhme et Rahm ont proposé un plan de numérotation intéressant permettant de
supprimer la limite de la taille des documents indexables et de mettre à jour les nœuds sans
ré-indexation complète [57]. Ce plan est nommé « numérotation dynamique par niveau » ou
DLN. Il est basé sur des identificateurs à longueur variable.
Les identificateurs de ce plan de numérotation, appelés « nombres dynamiques de niveau »,
sont inspirés de la classification décimale de Dewey, numérotation utilisée pour classer les livres

5.3 Bases de données XML natives 53
dans les bibliothèques. Les identificateurs de Dewey sont une séquence de valeurs numériques
séparées par des caractères spéciaux. Ils sont hiérarchiques. La racine du document possède
l’identificateur 1 tandis que tous les autres nœuds sont numérotés à l’aide de l’identificateur de
leur nœud parent comme préfixe, suivit d’une valeur de niveau. Par exemple, pour un arbre
simple : 1, 1.1, 1.2, 1.2.1, 1.2.2, 1.3, etc. Dans ce cas, 1 représente le nœud racine, 1.1 est le
premier nœud du second niveau, 1.2 le second et ainsi de suite. Une illustration de cet arbre est
proposée à la figure 5.6.
…
…
…
…
1.1
chapitre
1.1.1
section
1
document
1.2
chapitre
1.2.1
section
1.3.1
section
1.3
chapitre
Fig. 5.6 – Numérotation dynamique par niveaux (DLN).
1.3.2
section
A l’aide de ce plan de numérotation, déterminer la relation entre deux nœuds donnés est une
opération triviale et fonctionne aussi bien pour l’axe ancêtre-descendant que pour les relations
frère-suivant et frère-précédent. Tous les axes de navigation XPath peuvent donc être gérés efficacement.
Le problème principal est que ces identificateurs risquent d’avoir besoin d’un nombre
plus important de bits pour leur encodage que dans les plans précédents. Il faut donc trouver
un encodage efficace qui
⊲ restreint l’espace de stockage nécessaire pour un identificateur et
⊲ garantit une comparaison binaire correcte des identificateurs, en respectant l’ordre du
document.
En effet, en fonction du niveau d’encapsulation des éléments dans le document XML, les identificateurs
peuvent devenir très longs. Il est à noter qu’il n’est pas rare qu’un document XML
contienne plus de 15 niveaux.
La proposition originale de Böhme et Rahm décrit différentes approches pour encoder les
identificateurs DLN. Nous allons détailler la technique d’encodage implémentée dans eXist en
juillet 2006. Il s’agit d’un encodage efficace à bits variables et qui supporte une des caractéristiques
principales des bases de données XML natives : le fait que le document XML ne doit pas
avoir une structure déterminée. Cet encodage utilise des unités de largeur fixe (4 bits) pour les
identificateurs de niveau. Un identificateur de niveau commence avec une unité, en utilisant les
3 bits de poids faible pour le numéro de niveau et le bit de poids fort comme drapeau. Si l’on
ne sait plus encoder le numéro de niveau sur 3 bits, c’est-à-dire s’il est plus grand que 7, une
seconde unité est ajoutée et le bit de poids le plus fort de la première unité est mis à 1. Les

5.3 Bases de données XML natives 54
bits de poids fort indiquent donc le nombre d’unités utilisées pour l’identificateur. Le tableau
5.1 détaille cet encodage.
Unités Bits Valeurs
1 0XXX 1..7
2 10XX XXXX 8..71
3 110X XXXX XXXX 72..583
4 1110 XXXX XXXX XXXX 584..4679
5 1111 0XXX XXXX XXXX XXXX 4680...37447
6 1111 10XX XXXX XXXX XXXX XXXX 37448..299591
Tab. 5.1 – Encodage DLN.
Le nombre de numéros de niveaux possible augmente exponentiellement selon le nombre
d’unités utilisé. Avec cet algorithme, un identificateur comme 1.58.70.6.547.4500 peut être encodé
sur 52 bits, ce qui est plus efficace que l’encodage en nombres entiers de l’identificateur vu au
point 5.3.4 qui aurait pris 64 bits pour autant que le document ne soit pas trop grand pour être
indexé.
En plus de supprimer la limite de taille du document XML indexable, ce plan de numérotation
permet d’insérer facilement des nœuds dans l’arbre XML. En effet, pour éviter de devoir
renuméroter les nœuds après chaque insertion, suppression ou mise à jour, Boehme et Rahm
proposent l’idée de sous-niveaux. Entre deux nœuds 1.1 et 1.2, un nouveau nœud peut être inséré
en 1.1/1, où / est le séparateur de sous-niveaux. Le / ne commence pas un nouveau niveau.
1.1 et 1.1/1 sont tous les deux sur le même niveau de l’arbre. La figure 5.7 montre l’arbre logique
après insertion de ce nœud. Dans l’encodage binaire, le séparateur de niveau . est représenté par
un bit à 0 tandis que / par un bit à 1. Le tableau 5.2 montre quelques exemples d’identificateurs
DLN ainsi que leur encodage et leur taille en bits.
Id. Encodage Nb. bits
1.3 0001 0 0011 9
1.80 0001 0 1100 0000 1001 17
1.10000.1 0001 0 11110001010011001001 0 0001 30
1.1/7 0001 0 0001 1 0111 14
Tab. 5.2 – Encodage DLN, exemples.
Avec cette technique d’identificateurs de sous-niveau, on peut théoriquement insérer un
nombre arbitraire de nouveaux nœuds à n’importe quelle position de l’arbre sans avoir besoin
de renuméroter tous les nœuds. Bien sûr, il serait intéressant de renuméroter l’entièreté
du document de temps en temps pour ne pas perdre du temps dans les calculs de relations
structurelles. En effet, les identificateurs grandissent très rapidement. Par exemple, si on insère
consécutivement des nœuds entre 1.1 et 1.2, leurs identificateurs seront : 1.1/1 puis 1.1/0/1,
1.1/0/0/1, 1.1/0/0/0/1, . . . Pour gérer cet effet de bord, eXist prévoit une défragmentation de
l’arbre après un certain nombre d’insertions.

5.3 Bases de données XML natives 55
…
…
…
…
…
1.0/1
chapitre
1.0/1.1
section
1.1.1
section
1.1
chapitre
1
document
1.1.2
section
1.1/1
chapitre
1.1/1.1
section
insertions
1.2
chapitre
1.2.1
section
Fig. 5.7 – Insertions dans la numérotation dynamique par niveaux (DLN).
Il est à noter que, bien qu’il soit trivial, l’algorithme de comparaison pour deux identificateurs
DLN est plus lent que celui pour deux identificateurs entiers vu au point 5.3.4. En effet, beaucoup
d’opérations sont nécessaires pour traduire la chaîne de bits représentant l’identificateur. Il faut
donc y faire attention et éviter les comparaisons inutiles. Par contre, ce plan de numérotation
facilite grandement l’insertion de nœuds car il n’est pas nécessaire de réindexer l’arbre XML.
Cette méthode a été implémentée dans eXist pendant l’année 2006 et est disponible en version
de test depuis juillet 2006. Cette version a été présentée à la conférence XMLPrague 2006 par
Wolfgang Meier. Ce travail a été sponsorisé par l’Université de Victoria.
5.3.5 Traitement des requêtes grâce aux indexes
Les structures d’indexes vues précédemment dans ce chapitre vont servir au moteur de requête
des bases de données XML natives pour traiter efficacement les requêtes. De nombreuses
recherches ont été faites à ce sujet ces dernières années.
Nous avons vu qu’il était enfantin de retrouver un ensemble de nœuds selon leur chemin ou
leur valeur à l’aide des multiples indexes. Cependant, nous n’avons pas encore abordé la façon
avec laquelle on peut facilement joindre ces différents ensembles de nœuds. Par exemple, trouver
tous les articles à l’aide de l’expression //article ou trouver tous les nœuds prix dont la valeur
est inférieure à 1000 via l’expression //[prix

5.3 Bases de données XML natives 56
Algorithme de jointure fusion à prédicats multiples
Zhang et al. [50] ont exploré l’efficacité des algorithmes de jointures traditionnels utilisés dans
les systèmes relationnels appliqués au traitement de documents XML. Ils ont proposé un nouvel
algorithme, l’algorithme de jointure à prédicats multiples (multi-predicate merge join algorithm)
qui serait, selon eux, plus performant que les jointures standards des systèmes relationnels, du
moins pour les documents XML. Nous ne nous attarderons pas sur cet algorithme car il ne
concerne pas les bases de données XML natives.
Algorithmes de fusion d’arbre et d’arbre pile
Deux autres familles d’algorithmes de jointure structurelle ont été proposées par Srivatava et
al. : la fusion d’arbre (tree-merge) et l’arbre pile (stack-tree). Les algorithmes de fusion d’arbres
étendent les algorithmes traditionnels de jointure fusion tandis que les algorithmes d’arbres piles
ont été spécialement optimisés pour les jointures de chemins, concept souvent utilisé pour traiter
les requêtes sur du XML.
Le principe de base de ce dernier algorithme est de placer dans une pile les nœuds d’un
document XML en le parcourant en profondeur d’abord. Ainsi, les nœuds descendants se trouveront
plus haut dans la pile que les nœuds ancêtres. Srivatava et al. ont proposé un algorithme
permettant d’utiliser ce principe sans parcourir l’arbre XML en entier, mais en parcourant uniquement
les deux listes en entrée. Les algorithmes précis ainsi qu’une évaluation de performance
sont disponibles dans l’article [49].
Algorithmes de jointures XISS
Les algorithmes principaux de jointure de chemins basés sur le plan de numérotation XISS
ont été proposés et testés par Li et Moon, créateurs du plan XISS [48]. Ces auteurs proposent
des algorithmes de jointure de chemins pour évaluer les requêtes basées sur des expressions de
chemin.
L’idée principale des algorithmes de jointure de chemins proposés est qu’une expression de
chemin complexe peut être décomposée en une série d’expressions simples. Chaque expression
simple produit un ensemble de résultats intermédiaires qui peuvent être utilisés plus tard dans
le traitement de la requête. Les résultats des expressions simples peuvent être combinés ou joints
pour obtenir le résultat final d’une requête.
Considérons la requête /commandes//client[@id=58758]. Une expression de chemin peut
être décomposée en une combinaison des expressions basiques suivantes :
1. Une sous-expression avec un seul élément ou un seul attribut
2. Une sous-expression avec un élément et un attribut (client[@id=58758] dans notre requête
d’exemple)
3. Une sous-expression avec deux éléments en relation ancêtre-descendant (commandes/client
ou commandes//client)

5.3 Bases de données XML natives 57
4. Une sous-expression représentant une fermeture de Kleene (+,∗) d’une autre sous-expression
(commandes* ou commande+)
5. Une sous-expression représentant une union de deux autres sous-expressions
Une sous-expression de type (1) peut être traitée par un parcours d’index. Une sous-expression
de type (5) peut être traitée en fusionnant deux résultats intermédiaires. Pour les trois autres
types sous-expressions (2), (3) et (4), les auteurs proposent trois algorithmes de jointures de
chemins nommés respectivement EA-Join, EE-Join et KC-Join.
L’algorithme EA-Join joint deux résultats intermédiaires : une liste d’éléments et une liste
d’attributs obtenues par une sous-expression de type (2). Chacune de ces listes est parcourue
séquentiellement. Un attribut et un élément sont fusionnés s’ils viennent du même document et
si l’élément est le parent de l’attribut.
L’algorithme EE-Join joint également deux résultats intermédiaires : deux listes d’éléments
obtenus par une sous-expression de type (3). Les deux listes sont parcourues séquentiellement,
comme dans l’algorithme EA-Join. Deux éléments sont fusionnés s’ils viennent du même document
et s’ils ont une relation ancêtre-descendant ou parent-enfant.
L’algorithme KC-Join traite une expression de chemin qui représente zéro, une ou plusieurs
occurrences d’une sous-expression. A chaque étape du traitement, l’algorithme KC-Join applique
EE-Join sur le résultat obtenu à l’étape précédente jusqu’à ce qu’il n’y ait plus de résultat à
produire.
Selon les tests expérimentaux des auteurs de ces algorithmes, ils sont très efficaces, aussi
bien sur des données fictives que sur des données réelles. Cela est dû au fait que le plan de
numérotation XISS est très performant pour déterminer les relations ancêtres-descendants. En
effet, grâce à ce plan, on peut déterminer cette relation entre deux nœuds instantanément. Par
contre, il n’est pas évident qu’il soit efficace pour d’autres types de requêtes incluant des axes
XPath différents qu’ancêtre-descendant, comme frère-suivant, frère-précédent. eXist, la base de
donnée XML native que nous allons présenter dans les lignes suivantes, utilise un algorithme
similaire.

5.4 eXist, une base de données XML native libre 58
5.4 eXist, une base de données XML native libre
5.4.1 Introduction
Le projet eXist est une implémentation open source d’un système de gestion de base de
données XML native, interfaçable à l’aide de XPath, de XQuery et de XUpdate. Le projet a
été entamé en 2000 par Wolgang Meier, un développeur allemand. Il en est toujours développeur
principal et s’est basé sur les travaux de Shin, Jang et Jin [55] qui proposaient un système
efficace d’indexation des documents structurés. Ce fut tout d’abord une expérience d’implémentation
d’une indexation de documents XML à l’aide d’un système relationnel. Aujourd’hui, eXist
n’utilise plus de relationnel et fonctionne sur un système de stockage propre. La communauté
autour d’eXist ne cessant de croître et les développeurs étant très actifs, eXist est devenu un
SGDB XML natif complet. La base de données est complètement écrite en Java et peut être
déployée de multiple façons, aussi bien comme un processus serveur que dans un moteur de
servlet ou encore directement intégré dans une application.
eXist fournit un stockage sans schéma des documents XML dans des collections hiérarchiques.
Une collection est un ensemble qui peut contenir d’autres collections ou des documents XML.
En utilisant une syntaxe étendue d’XPath et d’XQuery, les utilisateurs peuvent interroger différentes
parties de la hiérarchie de collections, ou tous les documents contenus dans la base
de données. A défaut d’être léger, le moteur de requêtes d’eXist implémente un traitement de
requête efficace et basé sur les indexes. Le plan d’indexation permet une identification rapide
des relations structurelles entre les nœuds, comme la relation parent-enfant, ancêtre-descendant
et frère-suivant, frère-précédent. Basé sur des algorithmes de jointures de chemins, une large
fourchette d’expressions de chemin est traitée en utilisant uniquement les informations d’index.
L’accès aux nœuds courants, stockés dans le magasin central de documents XML, n’est pas
nécessaire pour ce type d’expressions.
La base de données convient bien aux applications manipulant des petites ou larges collections
de documents XML qui sont occasionnellement mises à jour. Le logiciel a été conçu de sorte
qu’il supporte les documents orientés données ou présentation. Cependant, l’interrogation de
ces derniers n’est pas très bien supporté par les langages de requêtes XML comme XPath.
eXist fournit donc un certain nombre d’extensions au standard XPath et XQuery pour traiter
efficacement des requêtes de recherche textuelle, incluant entre autres la recherche par mot clé
ou via des expressions régulières.
5.4.2 Architecture
eXist est bel et bien un système de gestion de base de données XML natif, conformément
à notre définition vue au point 5.3.1. En effet, un modèle logique pour les documents XML est
défini et le document XML est son unité de stockage fondamentale.
Au départ, eXist reposait sur un SGDB relationnel pour le stockage des données. Très vite,
celui-ci fut abandonné et remplacé par un magasin de données maison. Pendant la période

5.4 eXist, une base de données XML native libre 59
transition, l’utilisateur avait le choix d’utiliser soit l’un soit l’autre. Les documents XML sont
stockés en respectant le modèle DOM du W3C.
Les détails d’implémentations concernant le stockage des données sont totalement séparés
du cœur d’eXist. Tous les appels au système de stockage se font par des « courtiers » (brokers).
Un courtier peut être vu comme une interface entre le cœur d’eXist et les systèmes de stockages.
Ces classes « courtiers » fournissent un set d’instructions basiques comme ajouter, supprimer ou
récupérer des documents ou des fragments. De plus, elles possèdent des méthodes pour utiliser les
indexes, comme par exemple récupérer un ensemble de nœuds correspondant à un certain nom.
Les moteurs de requête XPath et XQuery sont implémentés de la même manière, comme des
Introducing eXist Node Identification Schemes and Indexing XQuery Processing Outlook
modules gravitant autour du cœur d’eXist. Nous remarquons ici un excellent découpage objet
du logiciel et ce, dès le début, dans le respect des principes du génie logiciel. Il devrait donc
être aisé Architecture de modifier ou d’ajouter Overview certaines parties comme un nouveau langage ou un nouveau
système de stockage. Une illustration de l’architecture d’eXist est proposée à la figure 5.8.
Système de stockage
Fig. 5.8 – Architecture d’eXist c○Wolfgang Meier.
eXist, au départ, utilisait uniquement un système relationnel. En effet, Wolfgang Meier voulait
se concentrer sur la partie indexation des données. Les premières versions du logiciel ont servi
à tester le système d’indexation pour vérifier son efficacité et évaluer ses performances. Depuis
la version 0.6 en 2002, le système relationnel a été remplacé par un système maison. Pendant
la période de transition, l’utilisateur avait le choix entre les systèmes de stockage, via un fichier
de configuration. Cette option a maintenant disparu, depuis que de nombreuses recherches aient
été effectuées sur le stockage efficace d’XML [58, 59, 60, 50]. Le test de ces différentes méthodes
a pu se faire facilement, grâce à l’architecture modulaire bien pensée d’eXist.

5.4 eXist, une base de données XML native libre 60
Collections de documents
A l’intérieur d’eXist, les documents sont gérés dans des collections hiérarchiques, d’une manière
comparable aux fichiers dans un système de fichier. Le magasin de documents XML est
indépendant au schéma : les collections ne doivent pas être liées à des schémas prédéfinis et le
nombre de documents utilisés dans une collection n’est pas une contrainte. En effet, des documents
arbitraires peuvent être mélangés dans une même collection. De même, les documents ne
doivent pas nécessairement avoir un XML Schéma ou une DTD propre. La seul contrainte est
que le document soit bien formé, au sens d’XML. Bien sûr, si une DTD ou un XML Schéma est
défini, le document XML doit être validé.
Déploiement
eXist offre plusieurs modes de déploiement. Le moteur de base de données peut :
⊲ s’exécuter comme un processus serveur, fournissant des interfaces HTTP, RESP et XML-
RPC pour l’accès distant.
⊲ être intégré dans d’autres applications, qui auront un accès direct à la base de données
via l’API XML:DB
⊲ s’exécuter dans un moteur de servlet comme Apache Tomcat. Les Servlets ou les Java
Server Pages (JSP) s’exécutant dans la même contexte d’application pourront accéder
directement à la base. L’accès distant est assuré par XML-RPC, SOAP, REST et Web-
DAV.
Il est donc très facile d’utiliser eXist dans un grand nombre d’applications. Par exemple,
pour faire un service web, on choisira l’interface SOAP. Pour l’intégrer dans une application, on
utilisera l’API XML:DB, etc. XML:DB est la méthode préférée pour accéder à eXist depuis une
application Java. XML:DB est une initiative indépendante qui propose une interface commune
pour l’accès aux bases de données XML natives ou toute autre base de données supportant XML.
Cela permet aux développeurs d’écrire des applications portables, en travaillant avec différents
produits implémentant l’interface XML:DB.
5.4.3 Indexation
Depuis juillet 2006, eXist est disponible en deux versions. La première, la branche 1.0, utilise
le plan de numérotation virtuelle par niveau. Beaucoup d’utilisateurs se plaignaient de ne pas
pouvoir stocker certains documents XML, car ils étaient composés d’un nombre trop important
de nœuds ou possédaient une structure trop complexe pour être indexés avec ce plan de numérotation.
Fin 2005, les développeurs d’eXist ont donc décidé d’implémenter le plan d’indexation
DLN de Boëhme et Rahm. Ce plan de numérotation permet d’indexer n’importe quel document
XML, quelle que soit sa taille et sa complexité. Il permet également l’insertion et la suppression
d’éléments sans réindexation complète de l’arbre. La branche 1.1 sortie en juillet 2006 utilise ce
plan de numérotation des nœuds et est disponible en version d’essai (release candidate) depuis
peu. C’est maintenant la branche principale de développement.

5.4 eXist, une base de données XML native libre 61
Organisation de l’index et des données
Dans cette section, nous allons expliquer quelques détails d’implémentation concernant l’organisation
de l’index et des données et expliquer comment le plan de numérotation et les structures
d’index sont utilisées dans le traitement des requêtes.
eXist utilise quatre fichiers d’index :
⊲ collextions.dbx qui gère la hiérarchie de collections, à la manière d’un système de
fichiers UNIX.
⊲ dom.dbx qui contient les nœuds des documents XML proprement dits, associés à leur
identificateur unique. Ce fichier est paginé.
⊲ elements.dbx qui indexe les éléments et les attributs
⊲ words.dbx qui garde une trace des mots et de leurs occurrences. Ce fichier est utilisé par
les extensions de recherches textuelles d’eXist.
Tous les indexes d’eXist sont basés sur des arbres B+ (B+trees). Nous en avons déjà parlé
au point 5.3.4. Il est important de prendre en compte que tous les indexes pour les éléments,
les attributs et mots-clés sont organisés par collection et pas par document XML. Par exemple,
toutes les occurrences d’un élément article dans une collection seront stockées comme une
seule entrée dans l’index des éléments. Cela aide à garder un petit nombre de pages d’arbres
B+ et conduit à une meilleure performance pour les requêtes sur l’entièreté d’une collection. Les
développeurs ont essayé dans le passé d’élaborer un index par document dans une collection.
Cela a induit une diminution des performances pour les collections contenant un grand nombre
de petits documents.
Stockage des données Le magasin XML dom.dbx représente le composant central de l’architecture
de stockage native d’eXist. Il consiste en un fichier paginé dans lequel tous les nœuds
du document sont stockés, avec respect du modèle DOM du W3C. Le magasin de données est
stocké à l’aide d’un arbre B+ à plusieurs racines dans le même fichier et associe à chaque identificateur
de nœud unique son adresse de stockage dans la partie données du fichier dom.dbx.
Une illustration de ce concept est disponible aux figures 5.9 et 5.10.
Il est important de noter qu’il n’est pas nécessaire de garder une trace des liens entre les
nœuds, comme, par exemple, en utilisant un pointeur pour le frère suivant, le premier enfant et le
parent. L’implémentation DOM dépend complètement du plan de numérotation pour déterminer
les relations structurelles entre les nœuds. Par exemple, pour obtenir le parent d’un nœud,
l’identificateur du parent est calculé à partir de l’identificateur du nœud et le nœud correspondant
est accédé via une recherche dans l’index.
Cependant, un accès séquentiel et ordonné aux données est nécessaire dans certains cas,
comme pour transformer un document ou un fragment de sa représentation interne à sa représentation
XML originale (cette technique est appelée sérialisation). Pour y parvenir, les nœuds
sont stockés dans l’ordre du document XML original, et situés physiquement dans des pages de
données consécutives.

5.4 eXist, une base de données XML native libre 62
Fig. 4. XML Data Store Organization
Multi-root B+-Tree
Document d 1
Node-id
...
Address
...
Introducing eXist
Document d 2 Node Identification Schemes and Indexing XQuery Processing Outlook
Node-id
Address
Data pages
...
Document Storage
...
Node n 1 Node n 2 ...
DOM nodes
Fig. 5.9 – Structure du fichier dom.dbx dans eXist c○Wolfgang Meier.
Please note again that it is not necessary to keep track of links between nodes, e.g.
by using pointers to the next sibling, first child or parent. The DOM implementation
completely relies on the numbering scheme to determine node relationships. For example,
to get the parent of a node, the parent’s unique identifier is calculated from the
node's identifier and the corresponding node is retrieved via an index lookup.
However, ordered sequential access to the data is desirable in many cases, e.g. to
serialize a document or fragment from the internal data model back into it's XML representation.
To achieve this, nodes are stored in document order, physically located
in subsequent data pages.
Thus only a single initial index lookup is required to serialize a document or fragment.
eXist's serializer will generate a stream of SAX [17] events by sequentially
walking nodes in document order, beginning at the fragment's root node. Any XML
tool implementing SAX may be used to post-process the generated stream.
Fig. 5. Index Organization for Elements and Attributes
B+-Tree keys
doc-id node-id node-id ...
doc-id
B+-Tree value: array of node-ids seperated
by doc-id
Fig. 5.10 – Architecture de stockage d’eXist c○Wolfgang Meier.
Pour passer de la représentation interne à la représentation XML, une seule recherche dans
l’index est nécessaire. Pour ce faire, le transformateur d’eXist génère un flux d’événements SAX
en parcourant séquentiellement les nœuds dans l’ordre du document, en commençant par le
nœud racine. Ainsi, tous les outils XML implémentant SAX peuvent être utilisés pour le posttraitement
de ce flux.
...

5.4 eXist, une base de données XML native libre 63
Indexes structurels
Collections. Le fichier d’index collections.dbx gère la hiérarchie de collection et associe
les noms de collections aux objets de la collection. Les descriptions de documents sont stockées
avec les objets de la collection. Un identificateur unique est assigné à chaque collection et à
chaque document durant l’indexation.
Eléments et attributs. Les noms d’éléments et d’attributs sont associés à leur identificateur
unique dans le fichier elements.dbx, représenté à la figure 5.11. Pour gagner de l’espace de
stockage, les noms des nœuds ne sont pas utilisés directement comme clés. En effet, on associe
les noms des attributs et des éléments avec des clés entières dans une table de noms. Chaque entrée
de l’index consiste en une clé et un tableau contenant une liste ordonnée des identificateurs
de documents et de nœuds. Ceux-ci se réfèrent aux éléments et attributs correspondants aux
noms représentés par chaque clé. Pour répertorier, par exemple, tous les clients d’une collection
de commandes, le moteur de requête se limitera à une seule recherche dans l’index et trouvera
l’ensemble complet des identificateurs de nœuds pointant vers ces éléments clients.
Introducing eXist Node Identification Schemes and Indexing XQuery Processing Outlook
Index Usage and Structural Joins
Structural Index
Fig. 5.11 – Structure du fichier elements.dbx d’eXist c○Wolfgang Meier.
Maps element and attribute QNames to a list of docId,
nodeId
Indexes basés sur les valeurs des nœuds
Created by default for every element or attribute in a
document
Index inversé. Le fichier words.dbx correspond à un index inversé. C’est un index basé
sur les valeurs, par opposition aux indexes structurels. Ce type d’index existe dans la plupart
des systèmes de gestion de bases de données. L’index inversé est utilisé spécifiquement pour
associer un mot à l’ensemble des documents dans lesquels il a été trouvé et à la position exacte
dans laquelle il apparaît dans ces documents. L’index inversé d’eXist diffère des indexes inversés
classiques car, au lieu de stocker la position des mots, il associe les mots aux identificateurs
uniques de nœuds. Par défaut, eXist indexe tous les contenus des nœuds ainsi que les valeurs des
attributs en les découpant en mots clés. Le fichier words.dbx suit la même structure que celle
du fichier elements.dbx, c’est-à-dire qu’il utilise une clé associée à un tableau contenant les

5.4 eXist, une base de données XML native libre 64
identificateurs des nœuds. Bien sûr, il est possible de désactiver cet index inversé, ou d’exclure
certaines parties d’un document donné.
Index de portée. Un troisième type d’index est disponible dans eXist, l’index de portée
(range index). Il s’agit d’un index basé sur les valeurs. Cet index est spécifique aux types de
données des valeurs des nœuds du document. Ces indexes fournissent un raccourci à la base
de données afin de sélectionner les nœuds directement selon de leurs valeurs. Au contraire des
indexes structurels et inversés, l’index de portée peut, et doit, être créé et configuré par l’utilisateur.
Dans ce sens, il est similaire aux indexes utilisés dans les bases de données relationnelles,
qui doivent aussi être spécifiés par l’administrateur de la base. eXist, par défaut, n’utilise pas
cet index car il est incapable de déterminer le type des valeurs des nœuds de l’arbre XML. Il
le pourrait à l’aide d’un XML Schéma mais cette fonctionnalité n’est pas encore implémentée.
De plus, il pourrait ne pas être efficace d’indexer tous les champs de la base. Cependant, si des
indexes de portée sont utilisés, ils sont créés par eXist lors du chargement du document et sont
actualisés automatiquement lors de ses mises à jour.
Les indexes de portée sont utilisés au besoin lors des comparaisons explicitement demandées
via les opérateurs et fonctions XPath standards, si, bien sûr, ces indexes sont définis par l’utilisateur.
Par défaut, si un tel index n’est pas défini, eXist procède à une inspection en force brute
(brute-force) du fichier dom.dbx. Il s’agit ici donc d’un point important si l’on compte gérer une
base de données importante avec eXist et que l’on a besoin de performance.
Pour comprendre comment fonctionnent ces indexes de portée, considérons le fragment XML
suivant :
< articles >
< article id="1">
Lampe de Bureau
299.99
< article id="2">
Lampe de Chevet
199.99
Dans cet exemple, les éléments prix en euros sont exprimés en nombre à virgule flottante.
Les nombres flottants correspondent au type de donnée XSD xs:double. En utilisant ce type
pour définir un index de portée, nous pouvons améliorer l’efficacité des recherches de valeur des
éléments prix. Durant l’indexation, eXist va considérer que toutes les valeurs des éléments prix
sont des nombres réels et va ajouter à l’index les valeurs correspondantes. Si toutefois certaines
valeurs des éléments prix ne correspondaient pas à des nombres réels, ils seraient ignorés lors
de l’indexation. Cet index de portée peut être utilisé dans n’importe quelle expression XPath
qui compare la valeur d’un élément prix à une valeur numérique en virgule flottante, comme
par exemple dans l’expression suivante :
// article [ prix > xs: double (100.0) ]

5.4 eXist, une base de données XML native libre 65
Pour les types de données hors des chaînes de caractères, l’index de portée fournit au moteur
de requête d’eXist une méthode plus efficace de conversion de données : au lieu de récupérer la
valeur de chaque élément sélectionné et de la transformer en nombre réel afin de la comparer,
eXist peut évaluer l’expression en utilisant l’index de portée par un simple parcours.
Les avantages de ce type d’index peuvent également s’appliquer aux chaînes de caractères.
Quand aucun index de portée n’est défini, eXist emploie la recherche textuelle pour retrouver
les nœuds correspondants. Il est alors nécessaire qu’eXist parcoure les résultats obtenus par
recherche textuelle pour en éliminer ceux qui ne correspondent pas à la requête. En utilisant
l’index de portée, ce parcours supplémentaire n’est pas nécessaire. En plus, les indexes de portée
peuvent être utilisés pour des comparaisons d’égalité, des comparaisons plus petits / plus grands
et des comparaisons basées sur des expressions régulières.
Pour illustrer cette dernière fonctionnalité, reprenons l’exemple précédent de la page 64. Si
nous définissons un index de portée sur le type xs :string pour les éléments nom, une requête
pour sélectionner toutes les lampes pourrait s’écrire de la façon suivante :
// article [fn: contains (nom ,’[ Ll]ampe ’)]
Un autre avantage de ce type d’index pour les chaînes de caractères est qu’il peut être défini
pour les éléments au contenu mixte. Par exemple, prenons en compte l’élément suivant :
< synonyme > ecran
moniteur
Dans ce cas, nous pouvons interroger eXist en utilisant une expression régulière s’appliquant sur
l’élément synonyme en entier. Par exemple :
//[ fn: matches ( synonyme ,’ ecran .* ’)]
En général, trois conditions sont à respecter afin d’optimiser la recherche en utilisant un
index de portée :
1. L’index de portée doit être défini sur tous les éléments sur lesquels porte la requête.
2. Le type de donnée à indexer doit correspondre au type de donnée testé.
3. L’argument de droite dans la comparaison ne doit pas dépendre du contexte courant.
Les détails concernant la configuration de ces indexes sortent du cadre de ce mémoire. Ils
sont disponibles dans la documentation disponible sur le site d’eXist 4 .
5.4.4 Traitement des requêtes
eXist va utiliser activement ses structures d’indexes pour traiter les requêtes XPath et
XQuery. En effet, à l’aide de ces indexes, eXist est capable d’accéder aux différents nœuds par
leur identificateur unique, de récupérer un ensemble d’identificateurs de nœuds correspondant à
un certain nom d’élément ou à des mots clés. D’un point de vue implémentation, les courtiers
ont des méthodes pour chacune de ces opérations simples.
4 http ://exist.sourceforge.net

5.4 eXist, une base de données XML native libre 66
Dans ce chapitre, nous allons voir comment eXist utilise ses indexes pour traiter efficacement
les requêtes XPath et XQuery. Il est à noter qu’eXist n’inclut le support d’XQuery que depuis
peu, au contraire d’XPath qui est implémenté depuis le début. C’est ici un point important car
nous allons voir qu’il est souvent préférable d’utiliser un maximum d’expressions XPath dans
les expressions XQuery. Il est donc important de comprendre comment eXist fonctionne pour
pouvoir optimiser les requêtes.
Algorithme de jointure de chemins
En utilisant les fonctionnalités fournies par le plan d’indexation, le moteur de requête d’eXist
est capable d’utiliser des algorithmes rapides de jointure de chemins pour traiter efficacement
les expressions de chemin. Un certain nombre de tels algorithmes ont été proposés récemment.
Celui utilisé dans eXist est basé sur l’algorithme proposé par Li et Moon [48] dont nous avons
déjà parlé au point 5.3.5.
Le processeur de requête d’eXist va d’abord décomposer l’expression de chemin donnée en
une série d’étapes simples. Considérons l’expression XPath suivante :
/ commande // client [ Nom =" Dupond "]
Cette expression est décomposée en 3 sous-expressions :
1. commande//client
2. client[Nom]
3. Nom="Dupond"
Notons l’ordre des sous-expressions : celles nécessitant un accès éventuel au magasin de données
sont mises en fin de chaîne. En effet, sans index de portée configuré correctement, la troisième
sous-expression impliquera un parcours du magasin de données, stocké sur disque, avec toutes les
conséquences que cela peut avoir en terme de performances. L’évaluation de cette sous-expression
est différée pour pouvoir filtrer les nœuds à récupérer dans le magasin de données afin de les
comparer, de sorte qu’il y ait le moins de nœuds possibles à aller chercher sur disque.
Les positions exactes des éléments commande, client et nom sont fournis par le fichier d’index
elements.dbx. Pour traiter la première sous-expression, le moteur de requêtes va charger les
éléments racines (commande) pour tous les documents de l’ensemble d’entrée. Ensuite, l’ensemble
des éléments client est récupéré par un parcours d’index classique. Nous possédons maintenant
deux ensembles de nœuds contenant des ancêtres et descendants potentiels pour chaque document
en question. Chaque ensemble de nœuds consiste en une liste ordonnée de paires contenant
l’identificateur du document et l’identificateur du nœud. Ces ensembles sont implémentés par
des tableaux Java.
Pour trouver toutes les relations ancêtre-descendant de ces ensembles de nœuds, eXist utilise
un algorithme de jointure de chemins similaire à celui présenté par Li et Moon dans [48].
Cependant, le plan de numérotation dans eXist n’est pas le même que celui pour lequel a été
développé l’algorithme de jointure de chemins XISS.

5.4 eXist, une base de données XML native libre 67
Selon son principe de base, l’algorithme prend en entrée deux ensembles de nœuds ordonnés :
le premier contient les ancêtres potentiels, le second les descendants potentiels. Chaque nœud
des deux listes est décrit par une paire contenant l’identificateur du document et du nœud.
L’algorithme remplace récursivement tous les identificateurs de nœuds dans l’ensemble des descendants
par l’identificateur de leur nœud parent. A chaque étape, on compare les paires de
nœuds. Si une paire de nœuds avec le même identificateur de document et le même identificateur
de nœud est trouvée, alors le nœud ancêtre et son descendant original sont donnés en sortie.
L’algorithme s’achève quand il n’y a plus de parents pour les nœuds contenus dans l’ensemble
des nœuds descendants. Des détails sur cet algorithmes sont disponibles dans [61]. Le résultat
renvoyé par l’algorithme va devenir un des ensembles de nœuds en entrée pour la sous-expression
suivante dans la liste. On va donc appeller une nouvelle fois l’algorithme avec le résultat obtenu
et le résultat de la seconde sous-expression et procéder de la même manière tant que la liste de
sous-expressions n’est pas vide.
Pour évaluer les sous-expressions commande//client et client[Nom], eXist n’a pas besoin
d’accès aux nœuds XML stockés dans le magasin de données. Les deux sous-expressions sont
entièrement traitées en se basant sur les identificateurs uniques fournis par les fichiers d’index.
Par contre, pour la troisième sous-expression, Nom="Dupond", eXist va devoir récupérer tous les
nœuds correspondants dans le magasin de données pour comparer leur valeur avec la chaîne de
caractère « Dupond ». Ce comportement, très lourd et gourmand en ressources, peut être évité
en utilisant correctement les indexes de portée. Une autre solution serait d’utiliser la recherche
textuelle, via l’index inversé, pour optimiser ce type de sous-expressions. Pour ce faire, il faut
utiliser les opérateurs prévus pour utiliser cet index inversé. Ceux-ci ne sont pas standardisés
dans la norme XPath/XQuery. Ces opérateurs sont décrits à la page 68.
Optimisation des requêtes
Cette découpe d’expression en sous-expression dans un ordre optimal n’est pas sans conséquence.
Par exemple, eXist préfère des expressions XPath plutôt que leur équivalent FLWR
utilisant une clause where. En effet, l’expression for force le moteur de requête à itérer étape
par étape sur la séquence d’entrée et à évaluer la clause where à chaque étape. Par exemple,
prenons l’expression FLWR suivante :
for $i in // commande
where $i/ client / @type =’ salarie ’ or $i/ client / @type =’ independant ’
or $i/ client / @type =’ etudiant ’
return $i
Cette expression peut se réécrire très facilement et plus lisiblement en utilisant l’expression
XPath suivante :
// commande / client [ @type = (’ salarie ’,’ independant ’,’ etudiant ’)]
eXist a aussi tendance à calculer les relations entre les nœuds en partant du bas plutôt qu’en
partant du haut de l’arbre. Les requêtes utilisant les axes parent ou ancêtre sont rapides et
il est souvent préférable d’explorer le contexte d’un nœud donné en remontant l’axe ancêtre

5.4 eXist, une base de données XML native libre 68
plutôt qu’en traversant l’arbre depuis sa racine. Par exemple, la requête suivante utilise une
approche en amont (top-down) pour afficher le contexte de chaque article dans une requête sur
les commandes :
for $commande in // commande
for $article in $commande // article / nom [ contains (. ," Lampe ")]
return
{ $commande / @id / text () }
{ $article }
Cela semble être une façon naturelle d’écrire une telle requête mais cela force eXist à évaluer
$commande//article/nom[contains(.,"Lampe")] pour chaque commande. Le moteur de requête
va essayer d’optimiser un peu cela mais cependant, une meilleure performance peut être
obtenue en reformulant la requête de façon à utiliser l’axe ancêtre de la façon suivante :
for $article in // commande // article / nom [ contains (. ," Lampe ")]
return
{ $article / ancestor :: @id / text () }
{ $article }
Extensions à XPath
La spécification XPath ne définit qu’un ensemble limité de fonctions pour rechercher une
chaîne de caractères dans le contenu d’un nœud. Cela peut être gênant si l’on veut traiter des
documents XML contenant beaucoup de texte comme les documents XML orientés présentation.
Pour rechercher des chapitres à propos des bases de données XML en respectant la norme XPath,
il faudrait écrire une expression du type de la suivante (cet exemple est tiré du site web d’eXist) :
// chapitre [ contains (. , XML ) and contains (. , databases )]
L’exécution de cette requête peut être assez lente car le moteur XPath va scanner entièrement
le contenu des nœuds chapitre et de leurs descendants. De plus, il est possible que le mot
database soit écrit avec une majuscule en début de phrase, de même si ce mot est utilisé au
singulier. Dans ces cas, l’expression précédente n’est pas suffisante.
Pour résoudre ce problème, eXist fournit des opérateurs et des fonctions pour accéder efficacement
au contenu textuel des nœuds, en utilisant l’index inversé dont nous avons parlé à la
page 63. Par exemple, eXist permet d’écrire la requête précédente de la façon suivante :
// chapitre [ near (.,’ XML database ? ’ ,50)]
Cette expression va renvoyer tous les chapitres contenant les deux mots XML et database et dont
la distance entre ces deux mots est inférieure à 50 mots. De plus, le caractère ? dans database ?
permet de trouver les occurrences du mot qu’il soit au pluriel ou au singulier. Il est également

5.5 Conclusions 69
intéressant de constater que ces recherches ne sont pas sensibles à la casse. Cela résout donc
entièrement le problème soulevé plus haut. Pour conclure sur cet exemple, comme la requête est
basée sur les indexes, celle-ci va s’exécuter plus rapidement que son équivalent XPath standard.
eXist fournit deux opérateurs supplémentaires de comparaison afin d’améliorer la recherche
textuelle dans des documents XML. Ces deux opérateurs sont &= et |=. Le premier opérateur
permet de retrouver les nœuds contenant tous les mots d’une chaîne de caractères tandis que le
second permet de déterminer les nœuds contenant au moins un mot d’une chaîne de caractères.
Ces deux opérateurs utilisent bien sûr l’index inversé pour améliorer l’efficacité des requêtes.
De plus, cette recherche n’est pas sensible à la casse. Tous ces opérateurs et extensions sont
utilisables également avec des expressions régulières.
5.5 Conclusions
Dans ce chapitre, nous avons analysé les différents types de bases de données permettant de
gérer des documents XML en détaillant principalement les bases de données XML natives, leurs
techniques d’indexation et les algorithmes associés. Enfin, nous avons présenté eXist, une base
de donnée XML native libre très prometteuse.
Dans le chapitre suivant, nous allons étudier la manière d’utiliser ces systèmes XML natifs
dans le domaine des entrepôts de données et tout particulièrement de l’analyse. Nous pensons
que le format XML est plus adapté pour représenter le monde réel que le format relationnel car
sa structure est beaucoup plus souple. Dès lors, pourquoi ne pas imaginer un système d’aide à
la décision basé sur une base de données XML native, base de données spécifiquement étudiée
pour gérer du contenu XML. C’est ce que nous allons analyser dans les chapitres suivants.

Chapitre 6
Les entrepôts de données XML natifs
Dans ce chapitre, nous allons analyser les différentes études traitant du langage XML dans
le domaine des entrepôts de données. Nous étudierons ensuite les différents besoins d’un système
d’analyse de données entièrement en XML des points de vue modélisation, indexation et langage.
Nous nous concentrerons principalement sur ce dernier point, à l’aide de XQuery.
Contenu
6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
6.2 Systèmes d’analyse (OLAP) . . . . . . . . . . . . . . . . . . . . . . . . 70
6.3 Besoins d’un système OLAP basé sur XML . . . . . . . . . . . . . . 74
6.4 Le test TPC-H . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
6.5 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
6.1 Introduction
XML est un format de plus en plus utilisé pour le stockage et la transmission d’informations.
Grâce à ses qualités en matière de flexibilité pour modéliser des données, on peut s’attendre
à ce que ce format soit encore plus utilisé dans le futur. Depuis que XML est devenu le langage
de choix pour représenter les données, le besoin de pouvoir analyser ces données augmente
constamment. Il convient donc de disposer d’outils adéquats pour stocker et interroger ces informations
XML. Le stockage de ces données est le rôle d’un entrepôt de données et l’interrogation
de celles-ci revient à des outils d’analyse OLAP et de data-mining. Cependant, peu d’études ont
été réalisées sur le sujet. Dans ce chapitre, nous allons en présenter quelques unes. Nous tenterons
également d’identifier les outils nécessaires à un système d’entrepôt de données entièrement en
XML. Par la suite, nous nous focaliserons principalement sur les systèmes d’analyse OLAP.
6.2 Systèmes d’analyse (OLAP)
Pour commencer, notons qu’il y a deux manières d’utiliser XML dans les systèmes d’analyse.
La première consiste à utiliser XML pour représenter les données sources et/ou les résultats
70

6.2 Systèmes d’analyse (OLAP) 71
des requêtes. Tout le traitement des requêtes se fait à l’aide d’outils OLAP existants, basés sur
des structures relationnelles ou multidimensionnelles. La seconde approche utilise XML aussi
bien pour la représentation des données que pour leur traitement. Nous détaillerons ici ces deux
approches, en nous concentrant sur la deuxième, et présenterons les outils et études existants.
6.2.1 Sources et résultats en XML
XML peut être utilisé pour représenter les données sources d’un système d’analyse. Dans
cette approche, les informations intéressantes des documents XML sont extraites vers un moteur
OLAP existant via un langage de traitement pour XML comme XSLT ou XQuery. L’analyse
des données se fait à l’aide d’un moteur OLAP classique, basé sur des structures relationnelles
ou multidimensionnelles comme SQL Server de Microsoft.
Fédération de données
Les données sources d’un système d’analyse peuvent ne pas être uniquement des documents
XML mais également des bases de données relationnelles classiques. En général, les sources de
données sont hétérogènes. Il convient donc de féderer ces différentes sources de données afin de
pouvoir les analyser uniformément.
Des travaux à ce sujet ont été effectuées par Pedersen et al. dans [62, 63]. Les auteurs proposent
une approche pour fédérer des sources de données XML avec des cubes OLAP existants.
Ils proposent également une architecture permettant d’interroger différentes sources de données
de manière transparente, une extension à SQL permettant d’utiliser des expressions XPath
(SQL/XM) ainsi qu’une évaluation de performances.
Echange de données
XML peut également servir de format d’échange entre les différents composants d’un système
d’analyse. Plusieurs standards ont été définis dans ce but comme XCube [64] et Microsoft XMLA
[65] (XML for Analysis).
Le projet XCube [64] propose une représentation XML dans le but d’échanger, sur un réseau,
des informations d’analyse comme des cubes de données (XCubeFact), des hiérarchies de
dimensions (XCubeDimension) et leurs schémas (XCubeSchema). Des mécanismes sont également
fournis afin d’envoyer des requêtes et recevoir des résultats dans le but de créer un système
d’analyse indépendamment de l’entrepôt de données. Les modèles définis par XCube sont très
souples. En effet, il est possible de modéliser toutes sortes de hiérarchies de dimensions. En
conclusion XCube peut servir comme format d’échange entre entrepôts de données et outils
d’analyse dans une architecture client-serveur.
XMLA [65] est une spécification élaborée par Hyperion, Microsoft, SAS et SAP afin de
standardiser l’accès aux moteurs OLAP par le biais de services Web basés sur XML comme
SOAP. XMLA est donc une API qui fournit des méthodes afin d’interroger des entrepôts de
données et d’analyser de façon transparente ces données à l’aide d’outils OLAP. De ce fait, cette
spécification est très similaire à celle proposée par le projet XCube.

6.2 Systèmes d’analyse (OLAP) 72
6.2.2 Systèmes natifs XML
Cette approche utilise XML aussi bien pour la représentation des données que pour leur traitement.
Les données sont représentées par des arbres XML dans le moteur OLAP et sont traitées
à l’aide de langages d’interrogation pour XML comme XQuery. Cette approche n’a pas encore
été largement étudiée. En effet, très peu d’études sur le sujet ont été menées. Une de ces études,
menée par Bordawekar et al. de chez IBM mi-2005 [39], montre que le modèle multidimensionnel
OLAP n’est pas adapté à l’analyse des documents XML et propose donc une approche pour
analyser des documents XML en utilisant le modèle de données XML. Les différences principales
entre les données XML et les données structurées classiques sont les suivantes :
salaire
division
département département
département groupe
groupe groupe
employé employé employé
date de
naissance
salaire
date de
naissance
salaire
date de
naissance
Fig. 6.1 – Exemple de modélisation XML pour un outil OLAP.
Dimension
Faits
Mesures
⊲ Tout d’abord, les documents XML contiennent une sémantique intrinsèque de par leur
structure d’arbre. En effet, les différents axes dans les données XML peuvent représenter
soit une relation de contenance (HAS-A), soit une relation de sous-classe (IS-A).
Les nœuds d’un arbre XML peuvent être vus comme des membres d’une dimension, dimension
déterminée par leurs éléments parents. Les feuilles de l’arbre peuvent être vues
comme des mesures. Une illustration de ce modèle est présenté à la figure 6.1. Avec cette
modélisation, les éléments XML représentant les niveaux de granularité peuvent contenir

6.2 Systèmes d’analyse (OLAP) 73
des attributs, qui sont en fait des mesures ou des pré-agrégations. Dans notre exemple,
les éléments groupe pourraient contenir des mesures tels que leur budget ou des calculs
d’agrégats comme la somme des salaires de leur personnel.
⊲ Les données XML ne respectent pas nécessairement un schéma rigide comme les données
relationnelles et peuvent contenir une structure plus ou moins irrégulière. C’est pour
cela qu’on parle souvent de documents semi-structurés : les documents respectent une
certaine structure mais cette structure est assez souple. Par exemple, un document XML
peut contenir des hiérarchies récursives (figure 6.1) ou des hiérarchies contenant différents
membres. De plus, comme un document XML a un ordre, les différentes mesures qu’il
contient peuvent être sémantiquement reliées entre elles via cette relation d’ordre.
⊲ Les documents XML peuvent se parcourir suivant différents axes, comme les axes XPath
dont nous avons parlé dans le chapitre 4 sur les langages d’interrogation XML. Un nœud
d’un arbre XML peut être accédé par de multiples chemins au contraire d’une case d’un
hyper-cube dans un système OLAP.
⊲ Les documents XML peuvent contenir des données non-numériques, comme par exemple
des génomes, ce qu’il n’est pas possible de gérer avec la modélisation OLAP cubique
traditionnelle.
En prenant en compte ces différences de modèle de données, on peut voir apparaître des
différences dans les types d’interrogations que l’on aimerait pouvoir exécuter sur de telles données
XML. Bordawekar et al. dans [39] en ont identifié certaines à propos du type de requêtes et du
type de traitement :
⊲ Premièrement, l’ordre d’un document XML est important. Il a une sémantique. Les requêtes
doivent donc pouvoir exploiter cet ordre. Par exemple, si nous avons un document
XML médical qui décrit différentes procédures de soins détaillées avec une liste ordonnée
d’opérations à effectuer sur un patient, il serait intéressant de pouvoir interroger la base
de données de façon à trouver les traitements dans lesquels une première incision est faite
au patient avant de l’anesthésier.
⊲ Deuxièmement, l’on peut vouloir grouper des éléments XML non seulement selon la
valeur de certains de leurs attributs comme dans les systèmes classiques mais aussi selon
leur chemin, exprimé par exemple par une expression XPath. Par exemple, sur la base
illustrée à la figure 6.1, si l’on veut grouper les employés par département, on aimerait
pouvoir utiliser l’expression de chemin //departement comme clé de groupement.
⊲ Il est également nécessaire de pouvoir faire des requêtes sur des données non-numériques
comme des chaînes d’ADN ou des vidéos MPEG-7.
⊲ De par leur structure hiérarchique, les opérations de projection des cubes de données
peuvent se faire simplement en éliminant les sous-arbres correspondant aux dimensions
non choisies dans la projection, à l’aide de l’opérateur XPath // par exemple.
⊲ Prévoir des tendances futures est une opération commune dans les systèmes OLAP traditionnels.
Cela consiste à modifier certaines mesures et à étudier les impacts de ces
changements sur toutes les données. La structure d’arbre d’un document XML permet
de faire aisément une analyse structurelle, en modifiant simplement la structure de l’arbre.

6.3 Besoins d’un système OLAP basé sur XML 74
Par exemple, si l’on veut analyser l’impact qu’aurait une réorganisation des départements
et des groupes, il suffit de déplacer les éléments groupes dans d’autres éléments départements
et de comparer les résultats des requêtes sur cette nouvelle structure. Dans les
systèmes OLAP traditionnels, ces analyses structurelles sont compliquées car elles nécessitent
un changement dans le schéma de la base de données, ce qui est une opération
ardue.
Pour toutes ces raisons, les systèmes OLAP traditionnels ne conviennent pas entièrement
à l’analyse de données XML. Des études doivent donc être faites dans ce domaine pour créer
un système OLAP permettant de gérer correctement ce type de données en prenant en compte
les points soulevés ci-dessus. Il s’agit d’identifier les manquements des outils XML comme les
langages et bases de données natives afin de pouvoir les utiliser pour faire de l’analyse de données
XML. Il faudra adapter les langages existants, trouver des techniques pour gérer d’immenses
documents XML (de l’ordre du Tera-octet), déterminer des interfaces utilisateurs pour visualiser
ces données hiérarchiques semi-structurées, etc. Ceci est un sujet très novateur. Le nombre
d’études sur le sujet est très limité et aucun outil existant ne permet de faire de l’analyse
performante sur des données XML.
6.3 Besoins d’un système OLAP basé sur XML
Dans cette section, nous allons prendre en compte les différents points soulevés dans la section
précédente à propos des systèmes OLAP XML natifs et essayer d’identifier les caractéristiques
nécessaires à un tel système. Au besoin, nous exposerons brièvement des pistes de solutions. Nous
commencerons par parler des aspects modélisation et indexation, en présentant le problème et
en proposant des débuts de solutions. Ensuite, nous nous attarderons plus longuement sur les
problèmes de langage en analysant la faisabilité d’utiliser XQuery pour des requêtes d’analyse.
6.3.1 Modélisation
D’un point de vue modélisation, il est intéressant d’utiliser la structure d’arbre intrinsèque
aux documents XML pour représenter les hiérarchies de dimension. Un modèle comme celui
présenté à la figure 6.1 paraît approprié. Cependant, ce modèle tel qu’il est présenté ne permet
de gérer qu’une hiérarchie de dimension. Dans les systèmes OLAP, on s’attend à pouvoir gérer
plusieurs dimensions comme les dimensions temporelles ou géographiques. Il faudrait donc
adapter ce modèle pour pouvoir gérer plusieurs dimensions.
Dans le modèle de Bordawekar et al. (figure 6.1), les dimensions, les faits et les mesures
sont contenus dans le même document, ce qui empêche la gestion de plusieurs dimensions. Nous
proposons donc de séparer les dimensions et les faits, un peu à l’image d’un schéma en étoile. Nous
aurions donc n arbres XML représentant chacun une dimension parmi les n et un document XML
comprenant les faits et mesures. Les feuilles des arbres de dimensions contiendraient une liste de
références aux faits associés. Ainsi, les données seraient déjà groupées par leur plus fins niveaux
de granularité de leurs dimensions. On peut comparer cette modélisation à un hyper-cube OLAP

6.3 Besoins d’un système OLAP basé sur XML 75
semestre1
2006
dimension
temporelle
semestre2
mars novembre octobre
Flandre
Belgique
Anvers
Namur
Wallonie
dimension
géographique
Liège
Fig. 6.2 – Exemple de modélisation pour un cube OLAP en XML.
classique. Les unités des différentes arêtes correspondraient aux valeurs de ces plus fins niveaux
de granularité, chaque arête représenterait une dimension et les cases représentants les mesures
des faits corresponderaient à ses coordonnées. Ces cases seraient obtenues par l’intersection des
listes de références aux faits en fonction de leur dimension. Les requêtes sur un hyper-cube
OLAP sont principalement des projections des faits sur un ou plusieurs axes de dimensions.
Il s’agit donc d’extraire des tranches du cube. Dans notre modèle, si nous voulions réaliser
une projection du cube sur les axes géographique et temporel, il suffirait de faire l’intersection
des listes de références contenues dans les feuilles des arbres de dimensions. Pour illustrer ce
concept, nous avons représenté ce modèle dans la figure 6.2 et un exemple de code XQuery
simplifié permettant de réaliser cette projection en figure 6.3.
for $region in // geographique // region
for $mois in // temporelle // mois
let $bons_faits := ( $region // faits intersect $mois // faits )
return
{ $region }
{ $mois }
{ count ( $bons_faits )}
Fig. 6.3 – Exemple de projection sur le modèle de la figure 6.2.
Nous n’entrerons pas dans les détails de ce sujet car nous avons voulu nous focaliser principalement
sur l’utilisation d’XQuery à des fins d’analyse.
faits

6.3 Besoins d’un système OLAP basé sur XML 76
6.3.2 Indexation
Les requêtes sur un moteur OLAP sont principalement multidimensionnelles. On a besoin
de pouvoir rapidement accéder à un ensemble de faits qui respectent un nombre variable de
conditions. Les expressions XPath du type de celles illustrées à la figure 6.4 doivent pouvoir
s’exécuter très rapidement. Il convient donc d’avoir des structures d’index multidimensionnelles
performantes dans ces différents cas. Ces indexes permettent de sélectionner rapidement les
éléments dont les clés ont une valeur exacte mais également ceux dont les clés sont comprises
dans un intervalle donné. Idéalement, il faudrait qu’un seul parcours d’index soit nécessaire
pour évaluer ce genre d’expressions. Des structures ayant des propriétés similaires aux arbres B
devraient permettre d’effectuer ce genre d’opérations rapidement.
// objet [ dimension1 = 23 and dimension2 = 47 and dimension3 = 98]
// objet [ dimension1 > 10 and dimension1 < 25 and ...]
Fig. 6.4 – Exemple d’expression XPath multidimensionnelle.
Il serait donc utile d’analyser les structures multidimensionnelles existantes comme les arbres
R [66], variante multidimensionnelle des arbres B présentés précédemment au point 46. En
effet, de nombreuses structures multidimensionnelles ont été étudiées abondamment ces dernières
années et il conviendrait donc d’évaluer leur performance dans notre cas précis et au besoin les
adapter aux spécifications du domaine comme, par exemple, les expressions de chemin XPath.
En l’occurence, ces structures d’index doivent être suffisamment efficaces en terme de recherche
et également en terme de place. En effet, les indexes, pour être efficaces, doivent être
copiés en mémoire vive afin d’accélerer leur accès. Il ne faut pas qu’ils prennent trop de place
sinon les performances seraient nettement diminuées et l’on perdrait l’avantage de l’indexation.
Ces structures doivent pouvoir supporter un nombre petit comme élevé de dimensions car on
ne peut prévoir le nombre de dimensions à gérer. Il conviendrait donc de trouver des structures
dont la taille et la complexité d’accès ne soient pas trop dépendantes du nombre de dimensions.
Comme pour la modélisation, ce sujet sort un peu du cadre de ce mémoire. En effet, nous
avons voulu nous concentrer sur la faisabilité d’utiliser le langage XQuery pour écrire des requêtes
d’analyses.
6.3.3 Langage
Comme nous l’avons vu dans l’introduction, il existe plusieurs langages d’interrogation de
données XML. XQuery nous paraît être le plus prometteur, se définissant comme le SQL pour
XML. Afin de se rendre compte de la faisabilité d’utiliser ce langage pour des requêtes d’analyse
sur des documents XML, nous nous sommes mis à la recherche d’exemples d’entrepôts existants.
Ne trouvant pas un tel exemple complet, nous avions décidé de créer un scénario d’entrepôt de
données pour un opérateur téléphonique. Nous avons créé un schéma de base de données en étoile
ainsi que différentes requêtes types d’analyse. Pendant nos recherches, nous avons découvert qu’il

6.4 Le test TPC-H 77
existait des scénarios d’évaluation de performances pour des entrepôts, notamment le test TPC-
H. Nous avons donc décidé de nous baser sur ce test afin d’évaluer s’il était raisonnable d’utiliser
XQuery dans notre cas particulier. Pour arriver à ces fins, nous avons retenu le moteur de base
de données XML natif eXist, qui implémente XQuery de façon complète. La section suivante est
entièrement consacrée à ce test et aux conclusions que l’on peut en tirer.
6.4 Le test TPC-H
TPC, Transaction Processing Performance Council, est un organisme sans but lucratif qui
édite des scénarios d’évaluation de performance destiné aux systèmes de gestion de base de
données. Son objectif est de fournir des données d’évaluation objectives à l’industrie. TPC est
composé de membres venant de l’industrie informatique parmi lesquels Microsoft, Oracle, Intel,
Sun, HP, . . . TPC propose plusieurs types de scénarios en fonction du type de bases de données.
TPC-App est un test pour les serveurs d’applications et les services Web, TPC-C pour les
systèmes transactionnels classiques et TPC-H pour les systèmes d’aide à la décision.
TPC Benchmark H (TPC-H) [67] est une évaluation des performances pour un système d’aide
à la décision. Elle comprend une série de 22 requêtes orientées business, requêtes typiquement
exécutées sur des entrepôts de données. Les données à analyser sont obtenues à l’aide d’un
générateur fourni. Pour valider les requêtes, les résultats attendus sont fournis. Ce test a pour
but de comparer les performances des systèmes décisionnels. Il a été exécuté sur des systèmes
comme SQL Server, IDB DB2 et Oracle, cela pour différentes sortes de serveurs et d’architectures.
Nous avons décidé d’utiliser ces requêtes afin d’évaluer leur faisabilité pour un entrepôt
XML. Le but n’est pas de comparer les performances d’une base de données XML par rapport
aux systèmes relationnels commerciaux mais de profiter de la pertinence de ces requêtes dans
le domaine des entrepôts de données, et tout particulièrement vérifier que le langage XQuery
permet d’écrire facilement ce genre de requêtes.
6.4.1 Traduction des données sources
Dans cette optique, nous avons commencé par traduire les données relationnelles fournies en
documents XML. Le schéma logique des tables de données relationnelles fournies par TPC-H est
illustré à la figure 6.5. Il s’agit d’une modélisation en flocons de neige articulée autour des tables
de faits LINEITEMS et ORDERS, modélisation dont nous avons déjà parlé lors de l’introduction
sur les entrepôts de données, au chapitre 2. Pour faire simple, nous avons traduit ces tables
de la manière suivante : chaque table sera représentée par un document XML. Ce document
contiendra toutes les lignes de la table traduites en éléments XML. Cette traduction est très
simple et peut donc être réalisée à l’aide d’un script, ce que nous avons fait. Par exemple, pour
la table REGION de la figure 6.5, la traduction XML est présentée à la figure 6.6.

6.4 Le test TPC-H 78
PART (P_)
SF*200,000
PARTKEY
NAME
MFGR
BRAND
TYPE
SIZE
CONTAINER
RETAILPRICE
COMMENT
SUPPLIER (S_)
SF*10,000
SUPPKEY
NAME
ADDRESS
NATIONKEY
PHONE
ACCTBAL
COMMENT
PARTSUPP (PS_)
SF*800,000
PARTKEY
SUPPKEY
AVAILQTY
SUPPLYCOST
COMMENT
CUSTOMER (C_)
SF*150,000
CUSTKEY
NAME
ADDRESS
NATIONKEY
PHONE
ACCTBAL
MKTSEGMENT
COMMENT
NATION (N_)
25
NATIONKEY
NAME
REGIONKEY
COMMENT
< regions >
Europe
< comment >None
(...)
LINEITEM (L_)
SF*6,000,000
ORDERKEY
PARTKEY
SUPPKEY
LINENUMBER
QUANTITY
EXTENDEDPRICE
DISCOUNT
TAX
RETURNFLAG
LINESTATUS
SHIPDATE
COMMITDATE
RECEIPTDATE
SHIPINSTRUCT
SHIPMODE
COMMENT
REGION (R_)
5
REGIONKEY
NAME
COMMENT
ORDERS (O_)
SF*1,500,000
ORDERKEY
CUSTKEY
ORDERSTATUS
TOTALPRICE
ORDERDATE
ORDER-
PRIORITY
CLERK
Fig. 6.5 – Schéma logique de la base TPC-H c○TPC.
SHIP-
PRIORITY
COMMENT
Fig. 6.6 – Fragment de traduction XML des données sources du test TPC-H.
6.4.2 Traduction des requêtes
Une fois ces données traduites et intégrées dans eXist, nous nous sommes lancés dans la
traduction des requêtes fournies par TPC-H. Ces requêtes sont écrites en SQL standard. Nous
avons donc dû les traduire en XQuery. Comme ces requêtes sont très longues et prennent donc
beaucoup de place, nous avons décidé de n’en présenter que quelques unes, jugées intéressantes.

6.4 Le test TPC-H 79
Requête simple
Pour commencer, observons la requête numéro 6 du test TPC-H. Il s’agit d’une simple requête
SQL qui a pour but de quantifier la somme de revenus supplémentaires qu’une entreprise pourrait
gagner en éliminant certaines réductions de prix sur un intervalle d’un an. Cette requête peut
aider une entreprise à trouver des sources de revenus. La figure 6.7 présente cette requête en
SQL telle que fournie par TPC-H et la figure 6.8 sa traduction en XQuery sur les données XML
telles que nous les avons définies.
SELECT sum ( l_extendedprice * l_discount ) as revenue
FROM lineitem
WHERE l_shipdate >= date ’1994 -01 -01 ’
AND l_shipdate < date ’1994 -01 -01 ’ + interval ’1’ year
AND l_discount between 0.06 - 0.01 and 0.06 + 0.01
AND l_quantity < 24;
Fig. 6.7 – Requête 6 du test TPC-H en SQL.
let $lineitem := document (" lineitem . xml ")/ lineitems / lineitem
[xs: date (./ shipdate ) >= xs: date ("1994 -01 -01")
and xs: date (./ shipdate ) < (xs: date ("1994 -01 -01") + xdt :
yearMonthDuration (" P1Y "))
and xs: double (./ discount ) >= xs: double (0.06) - xs: double (0.01)
and xs: double (./ discount )

6.4 Le test TPC-H 80
telle que fournie par TPC-H et la figure 6.10 sa traduction en XQuery sur notre base de données
XML.
SELECT l_orderkey ,
sum ( l_extendedprice *(1 - l_discount )) as revenue ,
o_orderdate ,
o_shippriority
FROM customer , orders , lineitem
WHERE c_mktsegment = ’[ SEGMENT ]’
AND c_custkey = o_custkey
AND l_orderkey = o_orderkey
AND o_orderdate < date ’[ DATE ]’
AND l_shipdate > date ’[ DATE ]’
GROUP BY l_orderkey , o_orderdate , o_shippriority
ORDER BY revenue desc , o_orderdate ;
Fig. 6.9 – Requête 3 du test TPC-H en SQL.
for $o_orderdate in distinct - values ( document (" order . xml ") // order [
orderdate lt xs: date ("[ DATE ]") ]/ orderdate )
for $o_shippriority in distinct - values ( document (" order . xml ") // order /
shippriority )
for $l_orderkey in distinct - values ( document (" lineitem . xml ") // lineitem /
orderkey )
let $order := document (" order . xml ") // order [ @id = $l_orderkey
and orderdate eq $o_orderdate
and shippriority eq $o_shippriority ]
let $lineitems := document (" lineitem . xml ") // lineitem [ orderkey = $order /
@id ]
let $customer := document (" customer . xml ") // customer [ @id = $order / custkey
]
let $revenue := sum ( $lineitems ( extendedprice *(1 - discount )))
where fn: exists ( $order )
and $customer / mktsegment = "[ SEGMENT ]"
and $lineitems / shipdate gt xs: date ("[ DATE ]")
order by revenue descending , $o_orderdate
return
{ $l_orderkey }
{ $revenue }
{ $o_orderdate }
< o_shippriority >{ $o_shippriority }
Fig. 6.10 – Requête 3 du test TPC-H en XQuery.
La traduction de cette requête est beaucoup plus compliquée que celle de la requête 6

6.4 Le test TPC-H 81
précédemment traduite. Il s’agit d’une triple boucle, chacune itérant sur les valeurs distinctes
(distinct-values()) des clés de groupement. A l’intérieur de ces boucles, nous sélectionnons les
éléments correspondant aux valeurs actuelles des clés de groupement et respectant les conditions
telles que le segment du client et la date de la commande. Il est à noter que dans la clause where,
nous devons tester l’existence d’un tel groupe pour que les résultats soient similaires à ceux de
la requête en SQL. En effet, l’opérateur GROUP BY en SQL ne renvoie pas les groupes vides, il
faut donc utiliser la fonction XQuery exists() afin de s’assurer que les éventuels groupes vides
ne se retrouvent pas dans les résultats. Par contre, une clause ORDER BY est disponible dans les
deux langages et leur fonctionnement est similaire. Il n’y a donc pas de problème de ce côté là.
Nous pouvons remarquer ici que cette traduction n’est pas simple. En effet, il faut écrire la
requête XQuery dans le sens opposé de celle en SQL. En SQL, on utilise l’opérateur GROUP BY
à la fin de la requête. Celui-ci agit comme un filtre, qui va grouper les tuples renvoyés par la
clause WHERE en post-traitement. En XQuery, il n’existe pas d’opérateur de groupement. Il faut
donc cycler sur les différentes valeurs des clés de groupement et à chaque cycle, sélectionner les
éléments XML correspondants à ces clés. Le groupement doit donc être pensé au début de la
requête, à l’aide des clauses for. Nous verrons dans le chapitre suivant que ce type de groupement
a un effet désastreux sur les performances, comparé à un groupement en post-traitement comme
en SQL. Le chapitre suivant est entièrement consacré aux groupements à l’aide d’XQuery. Nous y
proposerons un opérateur GROUP BY pour XQuery ainsi qu’un algorithme permettant d’effectuer
ce groupement en post-traitement.
Requêtes imbriquées
La requête numéro 4 du test TPC-H permet de déterminer si le système de priorité des
commandes d’une entreprise fonctionne et donne une évaluation de la satisfaction des clients.
Cette requête sélectionne les commandes pour lesquels au moins un article n’a pas été livré en
temps et en heure au client, cela sur une période d’un trimestre. Les résultats renvoyés sont une
liste du nombre de ces commandes par niveau de priorité. Il s’agit d’une requête de groupement
dans laquelle une autre requête est imbriquée. La requête imbriquée permet de détecter les
lignes des commandes dont les produits n’ont pas été livrés à temps et donc de sélectionner les
commandes associées à ces lignes. La figure 6.11 présente cette requête en SQL telle que fournie
par TPC-H et la figure 6.12 sa traduction en XQuery sur notre base de données XML.
De nouveau, il s’agit d’un groupement et donc, en XQuery, il faut cycler sur les différentes
valeurs des clés de groupement. Dans chaque cycle, nous sélectionnons les commandes qui satisfont
les conditions temporelles ainsi que la valeur de la clé de groupement. Pour ces commandes,
nous sélectionnons les lignes qui correspondent aux produits qui n’ont pas été livrés à temps.
Nous filtrons ensuite les commandes ainsi sélectionnées pour ne garder que celles dont au moins
un produit a été livré en retard. Tout cette sélection se fait dans une requête imbriquée (remarquez
les { }). Une fois de plus, la traduction en XQuery ne ressemble pas directement à la
requête originale en SQL mais nous pouvons remarquer que l’imbrication de requêtes ne pose
pas de problème en XQuery. Il faut se rendre compte que SQL et XQuery sont des langages assez
différents bien qu’ils possèdent des caractéristiques similaires comme le découpage en plusieurs

6.4 Le test TPC-H 82
SELECT o_orderpriority , count (*) as order_count
FROM orders
WHERE o_orderdate >= date ’[ DATE ]’
AND o_orderdate < date ’[ DATE ]’ + interval ’3’ month
AND exists (
SELECT *
FROM lineitem
WHERE l_orderkey = o_orderkey
AND l_commitdate < l_receiptdate
)
GROUP BY o_orderpriority
ORDER BY o_orderpriority
Fig. 6.11 – Requête 4 du test TPC-H en SQL.
for $o_orderpriority in distinct - values ( document (" order . xml ") // order /
orderpriority )
let $orders := {
for $order in document (" order . xml ") // order [ priority eq
$o_orderpriority
and orderdate ge xs: date ("[ DATE ]")
and orderdate lt op:add - dayTimeDuration -from - date (
xs: date ("[ DATE ]") ,xs: dateTimeDuration (" P90D "))]
let $lineitems := document (" lineitem . xml ") // lineitem [ orderkey eq
$order / @id
and commitdate lt receiptdate ]
where exists ( $lineitems )
return { $order }
}
where exists ( $orders )
order by $o_orderpriority
return
< o_orderpriority >{ $o_orderpriority }
{ count ( $orders )}
Fig. 6.12 – Requête 4 du test TPC-H en XQuery.
clauses. En effet, nous ne gérons pas ici des ensembles de lignes venant d’un tableau, mais plutôt
des ensembles d’éléments XML plus ou moins structurés en provenance d’un arbre. Une réflexion
est donc souvent nécessaire pour traduire une requête SQL en XQuery ou l’inverse. Cependant,
ces deux langages sont assez simples à comprendre et les requêtes ne sont pas plus difficiles à
écrire dans un langage que dans l’autre. Les requêtes de groupement forcent toutefois à retourner
totalement la requête et donc la façon de procéder pour parvenir aux mêmes résultats.

6.5 Conclusions 83
6.5 Conclusions
En conclusion, nous pouvons constater qu’il manque à XQuery au moins un mécanisme
approprié destiné à effectuer des groupements de données par valeurs. Le chapitre suivant y est
entièrement consacré.
Hormis ce point, bien que les requêtes ne soient pas aisées à traduire de par la nature différente
des données qu’elles traitent et de par leurs syntaxes hétérogènes, nous ne voyons pas d’autre
manquement grave à la syntaxe de XQuery pour rédiger des requêtes d’analyse sur un entrepôt
de données. Des améliorations devront être faites en termes d’indexation multidimensionnelle et
d’optimisation des requêtes afin d’atteindre des performances acceptables. Cependant, il semble
que le pouvoir d’expression de XQuery, contrairement à sa syntaxe, soit largement suffisant pour
notre problème.
Dans le chapitre suivant, nous allons faire une analyse des performances que l’on pourrait
gagner grâce à un opérateur de groupement dans XQuery.

Chapitre 7
Les groupements en XQuery
Dans le chapitre précédent, nous avons analysé la manière dont XQuery peut être utilisé à des
fins d’analyse. Les requêtes d’analyse se basant essentiellement sur des groupements de données
par valeurs, dans ce chapitre, nous nous attarderons particulièrement sur ceux-ci. XQuery ne
possède pas d’opérateur spécifique de groupement au contraire de SQL. Les groupements sont
possibles en XQuery à l’aide d’une combinaison de fonctions mais celle-ci entraîne un nombre
important d’itérations. Nous allons donc proposer un opérateur de groupement pour XQuery et
faire une analyse des gains de performance obtenus.
Contenu
7.1 Base de données source . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
7.2 Requêtes d’analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
7.3 Groupements en XQuery . . . . . . . . . . . . . . . . . . . . . . . . . . 88
7.4 Scénario d’évaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
7.5 Analyse des résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
7.6 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
7.1 Base de données source
Considérons une base de données XML composée d’un seul fichier plat commandes.xml représenté
partiellement sur la figure 7.1. Considérons également son équivalent relationnel présenté
à la figure 7.2. Dans la suite de ce chapitre, nous nous référerons à ces exemples.
Une commande a comme dimensions le client, le magasin, la date, le vendeur et les articles
vendus. Les mesures sont le prixTTC et le statut de la commande. Les différents niveaux
de granularité de la dimension géographique (magasin) sont endroit, codePostal, ville, pays
et continent. Nous supposons que les hiérarchies de dimensions sont symétriques (un codePostal
est inclus dans une seule ville, une ville dans un seul pays et ainsi de suite). Les autres
dimensions sont organisées d’une manière similaire.
84

7.1 Base de données source 85
< commandes >
< commande id="1">
Verhaegen Boris
< endroit >Rue des Metaux , 11
Bruxelles
< codePostal >1040
Belgique
< continent >UE
Etudiant
< magasin id="1">
Magasin Central
< endroit > Chaussee de Wavre , 23
Bruxelles
< codePostal >1050
Belgique
< continent >UE
Grossiste
2006 05 01
< vendeur id=" 5985 ">
Dupond
Pierre
3
< prixTTC unit =" EUR ">724 ,19
< article id=" 256 ">
Lampe de bureau
< famille > Eclairage
< categorie > Materiel de bureau
59 ,85
21
< quantite >10
paye
(...)
Fig. 7.1 – Exemple de base de données XML plate.

7.2 Requêtes d’analyse 86
La modélisation de la base de données XML n’est pas optimale en terme de taille. En effet,
pour éviter la redondance, les éléments client, magasin, vendeur et article devraient se
trouver dans d’autres fichiers XML. Cependant, nous utiliserons cette modélisation pour simplifier
les requêtes XQuery en éliminant les jointures et ainsi mettre en évidence la nécessité de
l’opérateur group by.
Commandes
id client id magasin id date vendeur id prixTTC statut
Localisations
id endroit ville code postal continent
Clients
id nom location id type
Magasins
id nom location id classe
Articles
id nom famille categorie prixHT TVA
Lignes
id commande id article id quantité
Vendeurs
id nom prenom niveau
Fig. 7.2 – Version relationnelle de la base de données d’exemple.
7.2 Requêtes d’analyse
Les requêtes OLAP classiques groupent des résultats suivant différents critères. Par exemple,
dans notre entrepôt défini ci-dessus, nous aimerions pouvoir obtenir le chiffre d’affaire en 2005
par ville de Belgique ainsi que par type de client. Le type d’un client pourrait être, par exemple,
étudiant, employé, profession libérale ou sans emploi.
7.2.1 Opérateur GROUP BY en SQL
En SQL standard, une telle requête s’écrirait classiquement comme sur la figure 7.3. Notons
l’utilisation du mot clé GROUP BY qui, comme son nom l’indique, groupe les données jointes en
calculant la fonction d’agrégation SUM(). Les résultats obtenus sont illustrés sur le tableau 7.1.
Extensions
Il existe des extensions à l’opérateur GROUP BY disponibles dans les systèmes d’analyse :
ROLLUP et CUBE [68]. La fonction ROLLUP permet de créer des sous-totaux triés à chaque niveau
d’un agrégat, jusqu’au total. Pour ce faire, elle commence par calculer les agrégats spécifiés dans

7.2 Requêtes d’analyse 87
SELECT LO.ville , CL.type , SUM ( prix )
FROM commandes CO , clients CL , locations LO
WHERE CO. date >= date (" 2005 -01 -01 ")
and CO. date = date (" 2005 -01 -01 ")
and CO. date

7.3 Groupements en XQuery 88
Ville Type SUM(prix)
Bruxelles Etudiant 2600
Bruxelles Employé 7800
Bruxelles NULL 10400
Liège Etudiant 1500
Liège Employé 5400
Liège Sans Emploi 700
Liège NULL 7600
NULL NULL 18000
Tab. 7.2 – Résultats de la requête de la figure 7.4 (ROLLUP).
Ville Type SUM(prix)
Bruxelles Etudiant 2600
Bruxelles Employé 7800
Bruxelles NULL 10400
Liège Etudiant 1500
Liège Employé 5400
Liège Sans Emploi 700
Liège NULL 7600
NULL Etudiant 4100
NULL Employé 13200
NULL Sans Emploi 700
NULL NULL 18000
Tab. 7.3 – Résultats de la requête de la figure 7.3 étendue avec CUBE.
7.3 Groupements en XQuery
Avant d’aller plus loin, il est important de noter qu’il existe différents types de groupements
dans le domaine des documents XML : le groupement par valeur et le groupement positionnel.
Le but du groupement par valeur est de regrouper des données en fonction de la valeur d’une ou
plusieurs de ses dimensions (appelées clés de groupement). Nous prenons le terme valeur dans
le sens défini par la spécification XML, c’est à dire les valeurs atomiques d’un attribut ou d’un
élément XML. Le groupement par valeur sert donc par exemple à regrouper une collection de
livres par auteur et par année. Ce groupement, pour XQuery, a fait l’objet de plusieurs recherches
scientifiques, que nous présenterons un peu plus loin dans ce même chapitre, à la page 90.
Par ailleurs, si nous voulons, par exemple, grouper un document XHTML contenant une
suite d’éléments H2, P, P, P, H2, P, P en deux sections comprenant chacune un élément H2
et les éléments P qui le suivent jusqu’au prochain élément H2. Il s’agit ici d’un groupement
positionnel. Ce type de groupement est possible en XQuery mais demande l’écriture de fonctions
récursives et de requêtes trop compliquées pour un utilisateur classique d’XQuery. Michael Kay,
le développeur de SAXON a identifié les cas d’utilisations d’un tel groupement et proposé très
récemment une syntaxe ad-hoc dans [69].

7.3 Groupements en XQuery 89
Ces deux types de groupement sont très différents et ne peuvent donc pas être traités de
la même manière. Nous allons nous focaliser sur le groupement par valeur, très utile pour les
requêtes d’analyse dans les entrepôts de données, contrairement au groupement positionnel. Il
nous semblait toutefois important de présenter les deux types de groupement afin d’éviter la
confusion.
Le langage XQuery ne possède pas de mécanisme particulier, comme un mot clé GROUP BY,
afin d’effectuer des groupements de données par valeur. Pour obtenir un résultat équivalent à
la requête SQL de la figure 7.3, nous devons donc écrire une requête à l’image de la figure
7.5. Il s’agit d’une double boucle sur les valeurs différentes des clés de groupement (distinctvalues()
1 ) dans lesquels on opère une jointure propre 2 et le calcul de la fonction d’agrégat. La
jointure propre est nécessaire car la fonction distinct-values(expression XPath) ne renvoie
que les valeurs des éléments sélectionnés par l’expression XPath et pas les nœuds eux-mêmes.
Cela suppose, sans optimisation, autant de passes sur les données ou sur les indexes qu’il y a de
groupes. De plus, ce code est difficile à lire et à optimiser.
for $ville in distinct - values (// commande / magasin [ pays =" Belgique "]/ ville )
for $type in distinct - values (// commande / client / type )
let $commandes := // commande [ magasin / ville = $ville
and client / type = $type ]
where exists ( $commandes )
return
{ $ville }
{ $type }
{ sum ( $commandes / prixTTC )}
Fig. 7.5 – Requête de groupement en XQuery standard.
for $commande in // commande
let $ville := $commande / magasin / ville
let $type := $commande / client / type
group by $ville , $type
return
{ $ville }
{ $type }
{ sum ( $commande / prix )}
Fig. 7.6 – Requête de groupement en XQuery à l’aide du mot clé group by.
1 fonction XQuery qui renvoie une collection composée des différentes valeurs demandées. On perd donc le lien
avec les éléments XML.
2 self-join, jointure d’un fichier avec lui même.

7.3 Groupements en XQuery 90
< results >
Bruxelles
Etudiant
2600
(...)
Fig. 7.7 – Résultats des requêtes des figures 7.5 et 7.6.
Le fait de devoir faire une itération par groupe (figure 7.5) n’est bien sûr pas la manière
la plus optimale d’obtenir un tel résultat. La complexité de cet algorithme en terme de grand
O est donc d’O(n m ) – m étant le nombre de groupes et O(n) la complexité d’un accès à la
base de données. Cette complexité peut certainement être réduite à O(log(n)) si les indexes sont
utilisés. Quoi qu’il en soit, cette complexité quadratique n’est pas admissible pour une grande
quantité de données. De plus, un optimiseur de requête aurait des difficultés à détecter que cette
combinaison de jointures propres associées aux méthodes distinct-values() et exists() est
en fait une requête de groupement et donc ne pourra pas l’optimiser.
Intuitivement, une seule passe sur les données devrait suffire pour effectuer un tel groupement.
Malheureusement, l’emploi de boucles for imbriquées avec XQuery suppose un nombre
important de parcours d’index ou de données. Un opérateur group by serait donc bienvenu, ce
qui permettrait de réécrire une requête de groupement à l’aide d’une seule boucle for sur les
données. Par exemple, si un tel opérateur était présent, la requête de la figure 7.5 pourrait se
traduire de la manière présentée en figure 7.6. Il s’agit d’un cycle sur toutes les commandes
dans lequel on instancie les clés de groupement $ville et $type. Les commandes sont groupées
avant la clause return qui ne renvoie les résultats qu’une fois les groupes entièrement constitués.
Intuitivement, cette requête, sans optimisation toujours, devrait parcourir une seule fois les commandes
(ou l’index de la collection) et les grouper par ville et par type. Les mêmes performances
devraient être également observées pour les extensions spécifiques à l’analyse comme ROLLUP et
CUBE, car il ne s’agit que de petits calculs supplémentaires une fois les groupes constitués. Cet
opérateur ajouté devrait donc permettre d’accélérer grandement les requêtes d’analyse. Pour
être complet, un fragment des résultats obtenus par ces deux requêtes est illustré à la figure 7.7.
Un tel opérateur a déjà été proposé par Beyer et al. [38] et par Borkar [40]. Une autre étude à
ce sujet a été menée par Deutsch et al. [43]. Ils proposent également un opérateur de groupement
pour XQuery ainsi qu’un ensemble de règles permettant de traduire les requêtes utilisant la
fonction distinct-values() en une forme minimisée et optimisée. Cette minimisation n’est
possible que si un tel opérateur est implémenté dans XQuery. Ces règles peuvent être réutilisées,
par exemple, à des fins d’optimisations interne.
Il y a quelques petites différences sans réelle importance entre ces différentes propositions
d’opérateurs. Dans certains cas, le mot clé group by se place après la clause return et, dans

7.4 Scénario d’évaluation 91
d’autres, il se place juste avant la clause order. Une autre différence réside dans la syntaxe de
cet opérateur. Nous avons choisi la forme la plus simple à des fins pédagogiques, comme utilisée
à la figure 7.6, c’est à dire que l’opérateur de groupement se place entre la clause where et order.
Son fonctionnement schématique est illustré à la figure 7.8.
for $c in //commande
let $ville := //commande/magasin/ville
let $type := //commande/client/type
($c = C1 , $ville = Bruxelles, $type = étudiant)
($c = C2 , $ville = Bruxelles, $type = etudiant)
($c = C3 , $ville = Bruxelles, $type = employé)
...
group by $ville,$type
($c = C1,C2 , $ville = Bruxelles, $type = étudiant)
($c = C3 , $ville = Bruxelles, $type = employé)
...
return
{$ville}
{$type}
{sum($c/prixTTC)}
for et let
where
group by
order by
return
Liste de tuples et variables
Tuples et variables filtrés
Tuples groupés
Tuples ordonnés
Résultats XML (arbre de tuples)
Fig. 7.8 – Schéma de fonctionnement de l’opérateur group by.
Il est bien entendu que cet opérateur n’ajoute rien au pouvoir d’expressivité du langage,
comme l’ont démontré Deutsch et al. [43]. Cependant, nous pensons que cet ajout permettrait
d’écrire des requêtes de groupement beaucoup plus facilement. En effet, il semble plus logique
d’utiliser explicitement un opérateur de groupement plutôt que de devoir cycler sur les valeurs
distinctes des clés de groupement. En plus d’être plus faciles à écrire, les requêtes seraient plus
aisées à lire et donc à maintenir.
Il nous paraît pertinent que le groupe de travail du W3C à propos d’XQuery puisse en
tenir compte lors de l’élaboration de sa prochaine version. Il serait en effet dommage de voir
apparaître une série d’implémentations propriétaires différentes de cet opérateur. Cela pourrait
semer la confusion parmi les utilisateurs d’XQuery, certaines requêtes ne fonctionnant pas d’une
implémentation à l’autre.
7.4 Scénario d’évaluation
A notre connaissance, il n’existe pas encore d’implémentation de XQuery possédant ce mot
clé group by. Nous allons donc faire une évaluation des performances que l’on pourrait gagner

7.4 Scénario d’évaluation 92
Méthode A
eXist XML DB
Résultats
(XML + temps)
Requête de groupement en
XQuery officiel
XML docs
Comparaison
Fig. 7.9 – Diagramme du scénario d’évaluation.
Traduction
Simulation
du group by
(Script)
Résultats
(XML + temps)
Méthode B
en implémentant un tel mot clé dans XQuery. La figure 7.9 représente la manière dont nous
comptons évaluer les performances.
7.4.1 Méthodes d’évaluation
Sur la gauche de la figure 7.9, est représentée la méthode à suivre pour tester des requêtes
de groupement en XQuery officiel, sans mot clé group by. On exécute la requête classiquement
en utilisant une combinaison des méthodes distincts-values(), exists() et des jointures
propres comme conformément à l’exemple vu en figure 7.6.
La méthode à suivre pour simuler le mot clé group by est schématisée sur la droite de la
figure 7.9. Nous allons procéder en deux étapes. Tout d’abord, nous traduirons la requête afin que
l’on puisse l’exécuter à l’aide du script de groupement. L’algorithme de groupement n’effectuera
qu’une passe sur les données et créera les groupes dynamiquement lorsque le premier tuple
correspondant sera lu. Il calculera également la fonction d’agrégation de la même manière. Un

7.4 Scénario d’évaluation 93
pour tout tuple dans les resultats intermediaires {
groupe = ( tuple . ville , tuple . type )
si ( groupe existe ) {
groupe . somme += tuple . prix
}
sinon {
creer groupe
groupe . somme = tuple . prix
}
}
Fig. 7.10 – Algorithme de groupement (2 clés) en pseudo-code pour une somme.
exemple du fonctionnement de l’algorithme pour une fonction d’agrégation sum() et pour des
groupes à deux clés est présenté sur la figure 7.10. Il est de complexité O(n), n étant le nombre
d’éléments à grouper, ce qui est évidemment plus acceptable pour une masse importante de
données.
Cet algorithme est aisément extensible pour les fonctions rollup et cube. L’extension nécessaire
à notre algorithme est triviale : il s’agit de parcourir les groupes en post-traitement et
d’y insérer les résultats agrégés de la même manière qu’en relationnel[68]. Cette extension est de
complexité O(m), où m est le nombre de groupes. Comme m sera généralement beaucoup plus
petit que n, cette extension ne change rien à la complexité de notre algorithme de groupement.
Il va sans dire que les résultats générés par les deux méthodes devront être identiques afin
de valider le test et de comparer les performances des deux méthodes.
7.4.2 Génération de l’échantillon
Nous avons généré une base de données simple dans le style de celle vue au tout début de
ce chapitre. Les tuples ont été calculés de telle manière que chaque valeur de paramètre soit
équiprobable. Ainsi, chaque valeur correspond plus ou moins à un même nombre de tuples. Par
exemple, il y aura statistiquement le même nombre de commande dans chaque commune. Nous
espérons ainsi tester le pire cas de groupement : celui où il n’y aurait pas de groupe vide et où
chaque groupe contiendrait à peu près le même nombre d’éléments.
Ce fichier XML est généré à l’aide d’un script Python qui prend en argument le nombre
d’éléments commande à produire. Les valeurs des paramètres sont résumées dans le tableau 7.4.
Ces valeurs sont distribuées équiprobablement à l’aide d’un générateur de nombres aléatoires
fourni. Il est à noter qu’aucune supposition n’est faite quand à la proximité d’un client et d’un
magasin : un client européen peut avoir fait tous ses achats en Asie par exemple. Les résultats
des requêtes ne représenteront donc pas une situation similaire à la réalité.

7.4 Scénario d’évaluation 94
Nombre de commandes n
Nombre de magasins 100
Nombre de clients 1000
Nombre de vendeurs 200
Nombre d’articles 10000
Nombre de valeurs pour 4
Nombre de valeurs pour 2
Date minimale 01-01-1996
Date maximale 01-01-2006
Nombre de valeurs pour 5
Nombre de par 50
Nombre de par 100
Nombre de par 20
Nombre d’ par 10
Prix minimal d’un article 10
Prix maximal d’un article 1000
Quantité minimale d’un article par commande 1
Quantité maximale d’un article par commande 10
Nombre de valeurs pour 5
Nombre de par 10
Nombre de valeurs pour 5
Nombre de valeurs pour 3
Tab. 7.4 – Paramètres de l’échantillon.
Processeur AMD64 3000+ 1800Mhz
Mémoire vive 1024Mo
Système d’exploitation Linux 2.6
Machine Java Sun j2re 1.5
eXist Version de développement SVN rev3915 (07-2006)
7.4.3 Conditions du test
Tab. 7.5 – Spécifications de la station de test.
Le test a été effectué sur une station de travail dont les caractéristiques sont présentées sur
le tableau 7.5. Nous utiliserons le logiciel eXist qui est une base de données native XML en Java.
eXist est à nos yeux l’implémentation libre la plus complète du langage XQuery.
7.4.4 Mesures
Afin de comparer les deux méthodes illustrées sur la figure 7.9, la première sans group by
et la seconde avec, nous disposons des mesures suivantes :

7.4 Scénario d’évaluation 95
⊲ le temps d’exécution
⊲ le nombre de groupes résultants
⊲ le nombre d’éléments à grouper
⊲ le nombre de clés du groupement
7.4.5 Paramètres
Les paramètres sur lesquels nous pouvons jouer sont le nombre d’éléments de la base de
données, le nombre de groupes résultants (par exemple, une requête de groupement sur les
communes de Bruxelles nous donnerait 19 groupes) et le nombre de clés de groupement (par
exemple, une clé si on groupe par ville, deux si on groupe par ville et par statut, . . . ).
En ce qui concerne le nombre de commandes, nous avons utilisé les valeurs suivantes : 100,
10K, 100K. Nous voulions également faire le test sur des échantillons plus grands (1M et 10M)
mais, dans ce cas, eXist n’avait pas assez de mémoire à sa disposition et la machine copiait sans
cesse des données entre la mémoire virtuelle et la mémoire vive. Nous avons donc abandonné
notre expérience sur ces échantillons trop importants de peur de fausser les résultats. eXist est
selon nous fiable mais il ne peut encore gérer de larges collections de données en économisant la
mémoire vive.
Les nombres de groupes obtenus dépendent directement des requêtes effectuées sur l’échantillon.
Les valeurs choisies sont les suivantes : 2, 5, 6, 10, 15, 24, 50 et 100. Le nombre de
clés groupement dépendent également des requêtes. Nous nous sommes limités aux valeurs suivantes
: 1, 2 et 3. Ces valeurs sont suffisantes pour montrer le gain de performance obtenu grâce
au groupement séquentiel.
7.4.6 Requêtes effectuées
Numéro Clé(s) Groupes
R1 client/classe 2
R2 magasin/continent 5
R3 article/categorie 10
R11 article/famille 50
R4 magasin/classe et vendeur/niveau 6
R5 magasin/classe et magasin/continent 10
R6 client/type et vendeur/niveau 15
R7 article/categorie et magasin/continent 50
R8 magasin/classe, vendeur/niveau et statut 24
R9 magasin/classe, magasin/continent et client/type 50
R10 magasin/classe, magasin/continent et magasin/classe 100
Tab. 7.6 – Requêtes de l’évaluation.

7.5 Analyse des résultats 96
Pour mener à bien ce test de performance, nous avons utilisé les onze requêtes illustrées dans
le tableau 7.6. Ces requêtes sont directement inspirées de celle de la figure 7.5 pour leur version
XQuery officielle. Celles-ci ont été exécutées sur nos collections à l’aide d’eXist. Pour simuler le
fonctionnement d’un opérateur group by, nous avons écrit un script Python utilisant l’API SAX
respectant l’algorithme précédemment présenté à la figure 7.10. Ce script prend en argument le
fichier XML à grouper ainsi que les clés de groupement. Il renvoie un fichier XML contenant les
résultats de ce groupement. Ce résultat a ensuite été comparé avec les résultats obtenus pour la
requête XQuery correspondante exécutée avec eXist.
7.5 Analyse des résultats
Temps (ms)
7000
6000
5000
4000
3000
2000
1000
10k, eXist
10k, script
0
0 10 20 30 40 50 60 70 80 90 100
Nombre de groupes
(a) 1000 éléments
Temps (ms)
800000
700000
600000
500000
400000
300000
200000
100000
Temps (ms)
70000
60000
50000
40000
30000
20000
10000
10k, eXist
10k, script
0
0 10 20 30 40 50 60 70 80 90 100
Nombre de groupes
(c) 100K éléments
10k, eXist
10k, script
0
0 10 20 30 40 50 60 70 80 90 100
Nombre de groupes
(b) 10K éléments
Fig. 7.11 – Temps d’exécution des requêtes en fonction du nombre de groupes (respectivement
pour R1, R2, R4, R5, R6, R8, R9 et R10).
Comme nous l’escomptions, notre méthode de groupement présentée au point 7.4.1 est bien
plus performante que celle utilisant la syntaxe officielle d’XQuery et exécutée à l’aide d’eXist. Sur
la figure 7.11, nous pouvons constater que le temps pris par notre méthode groupement croit très
lentement en fonction du nombre de groupes résultants, contrairement à l’autre procédé. Cela
n’a rien d’étonnant, la durée de notre groupement étant directement proportionnelle à la taille
des données à traiter. En effet, comme nous l’avons déjà précisé au point 7.4.1, sa complexité
est de O(n).

7.6 Conclusions 97
Temps (ms)
800000
700000
600000
500000
400000
300000
200000
100000
0
20 30 40 50 60 70 80 90 100
Nombre de groupes résultants
1k, eXist
1k, script
Fig. 7.12 – Temps d’exécution des deux méthodes en fonction du nombre de groupes pour des
groupements à 3 clés (R8, R9 et R10 respectivement).
Par comparaison, le temps utilisé par la méthode basée sur la syntaxe officielle paraît dépendre,
en plus de la taille des donnes, du nombre de groupes ainsi que du nombre clés de
groupement comme l’on peut le constater sur les figure 7.12 et 7.13.
Les deux figures 7.14 et 7.15 montrent le rapport entre les temps d’exécution des deux
méthodes. T (eXist) est le temps en milli-secondes mis par eXist pour exécuter les requêtes de
la méthode A et T (script) est celui utilisé par notre algorithme de groupement pour les mêmes
requêtes. Le rapport utilisé en ordonnée est T (eXist) sur T (script). Nous pouvons constater
que, sauf pour un très petit nombre de groupes (2 et 5 dans notre test), le gain obtenu via notre
méthode est supérieure à 1 et ne cesse de croître en fonction du nombre de groupes ainsi que du
nombre de clés de groupement. Le fait que notre rapport est inférieur à 1 pour un petit nombre
de groupes réside certainement dans le fait qu’eXist indexe les données et peut donc accéder
très rapidement aux nœuds correspondant à un groupe. Malheureusement, de par le fait que le
langage XQuery officiel impose un grand nombre d’itérations afin de grouper des données, le
temps gagné grâce à l’indexation n’a pas beaucoup d’effets sur les performances quand un grand
nombre de groupes résultants sont à traiter.
7.6 Conclusions
Pour conclure, il apparaît évident que si nous voulions utiliser XQuery à des fins d’analyse sur
un importante base de données, un opérateur de groupement s’avérerait indispensable. Il est en
effet peu concevable qu’un groupement s’exécute avec une complexité quadratique, surtout pour
de larges collections d’informations typiques aux entrepôts de données. Comme nous l’avons vu

7.6 Conclusions 98
Temps (ms)
400000
350000
300000
250000
200000
150000
100000
50000
0
1 1.5 2 2.5 3
Nombre de clés de groupement
1k, eXist
1k, Script
Fig. 7.13 – Temps d’exécution des deux méthodes en fonction du nombre de clés de groupement
pour 50 groupes résultants (respectivement R11, R7 et R9).
en début de ce chapitre, d’autres aspects doivent encore être approfondis comme l’indexation et
la modélisation afin de construire un système d’analyse entièrement basé sur XML.

7.6 Conclusions 99
T(eXist)/T(script)
18
16
14
12
10
8
6
4
2
0
1K commandes
10K commandes
100K commandes
2 5 6 10 15 24 50 100
Nombre de groupes résultants
Fig. 7.14 – Rapport du temps d’exécution des deux méthodes en fonction du nombre de groupes
(respectivement pour R1, R2, R4, R5, R6, R8, R9 et R10).
T(eXist)/T(script)
9
8
7
6
5
4
3
2
1
1K commandes
10K commandes
100K commandes
1 2 3
Nombre de clés de groupement
Fig. 7.15 – Rapport du temps d’exécution des deux méthodes en fonction du nombre de clés de
groupement (50 groupes) (respectivement R11, R7 et R9).

Chapitre 8
Conclusions et travaux futurs
8.1 Conclusions
Le format XML, de par sa simplicité et sa flexibilité, est devenu aujourd’hui le format de choix
pour représenter des données structurées ou semi-structurées. De nombreux langages permettent
d’interroger du contenu XML et différents logiciels existent pour gérer ces documents.
Depuis quelques années, de plus en plus d’entreprises centralisent leurs informations dans
des entrepôts de données afin de les analyser et d’en dégager des tendances. Cependant, bien
que XML soit très utilisé, il n’existe pas de système d’entrepôt de données entièrement en XML
et seules quelques études scientifiques sont parues sur le sujet. Dans ce mémoire, nous avons
décidé d’analyser la faisabilité d’un entrepôt de données, basé entièrement sur XML.
Nous avons d’abord dû nous familiariser avec les entrepôts de données et les technologies
XML dans le domaine des bases de données : les différentes modélisations, les langages d’interrogation
et les bases de données natives XML. Tout ceci étant très récent et novateur, nous y
avons consacré une bonne partie de ce travail, en nous concentrant sur les aspects modélisation
et indexation des données XML dans les bases de données. Nous avons également analysé en profondeur
le logiciel libre eXist, un système de gestion de base de données natif XML implémentant
XQuery, qui nous paraît prometteur.
Ensuite, nous avons étudié les différents articles publiées à propos de XML dans le domaine
des entrepôts de données et des systèmes d’analyse OLAP. Lorsque cela était nécessaire, nous
avons émis des propositions comme une modélisation adéquate de documents XML pour un
système OLAP et des idées d’indexation multidimensionnelle.
Nous avons également détecté un manquement dans la syntaxe de XQuery. Celui-ci ne possède
pas d’opérateur de groupement par valeur, contrairement à SQL. Les groupements sont
des opérations très utilisées dans le domaine des entrepôts de données et de l’analyse. En effet,
les requêtes au sein de tels systèmes sont principalement des groupements de faits selon une ou
plusieurs dimensions.
Nous avons dès lors décidé d’analyser le gain de performance que l’on pourrait obtenir en
implémentant un tel opérateur dans XQuery. Les résultats sont très favorables à cette innovation.
100

8.2 Travaux Futurs 101
Cet opérateur n’ajoute rien au pouvoir d’expression de XQuery mais permet à la fois d’écrire
plus facilement ces requêtes de groupement et surtout de gagner du temps de calcul lors de leur
exécution.
Il paraît donc évident qu’en cas d’utilisation de XQuery à des fins d’analyse sur une large
base de données, un opérateur de groupement est indispensable. En effet, il permet d’optimiser le
traitement des requêtes de groupement. Cette optimisation est d’une grande importance quand
on considère les masses considérables d’informations constituant un entrepôt de données. Dans ce
but, nous pouvons recommander qu’une version ultérieure des spécifications XQuery ajoute à sa
syntaxe une telle clause. Cela éviterait que de multiples implémentations maison apparaissent sur
la marché et détruisent, de ce fait, une bonne partie des bénéfices apportées par la standardisation
des langages.
8.2 Travaux Futurs
Le sujet dans lequel nous nous sommes lancés dans cette étude est très novateur et peu
exploré. De nombreux aspects pourraient encore être analysés lors de recherches, de mémoires
voir de thèses de doctorats. Ces aspects sont, entre autres, les suivants :
⊲ Indexation : De nombreuses structures d’indexes multidimensionnels existent comme
les arbres UB [70] et les arbres R [66]. Il conviendrait donc d’étudier leur application
dans le cas spécifique des documents XML.
⊲ Modélisation : Dans ce mémoire, nous avons proposé une idée de modélisation multidimensionnelle
pour un outil OLAP. Il serait intéressant de trouver d’autres modélisations
en se basant peut être sur les techniques existantes dans les moteurs OLAP classiques
et en les adaptant au cas spécifique de XML. Une évaluation comparative de ces modélisations
pourrait être faite. La modélisation est fortement liée à l’indexation. En effet,
pour réaliser un plan d’indexation efficace, la structure générale des données à indexer
est importante à connaître.
⊲ Stockage : Les systèmes d’aide à la décision gèrent habituellement une masse énorme de
données. Pour l’instant, les bases de données XML natives matérialisent les documents
XML entiers en mémoire vive, ce qui est clairement inadapté. Il faut donc trouver des
techniques de stockage et de récupération qui soient adaptées à de très grands documents
⊲ Visualisation : Les systèmes d’analyse OLAP ne sont habituellement pas utilisés par
des informaticiens, mais plutôt par des analystes financiers ou des décideurs. L’aspect
visualisation est donc très important. De plus, la structure souple des documents XML
est très différente de celle des cubes OLAP classiques. Il s’agirait donc de trouver des
moyens d’affichage de gros ensembles de données hiérarchisées en temps réel, tout en
économisant de la mémoire vive.

BIBLIOGRAPHIE 102
Bibliographie
[1] B. Inmon. Building the Data Warehouse. John Wiley, 1992.
[2] R. Kimball. The Data Warehouse Toolkit. John Wiley, 1996.
[3] E. Malinowski and E. Zimányi. Hierarchies in a multidimensional model : From conceptual
modeling to logical representation. Data & Knowledge Engineering, 2006. Unpublished
paper. Paper available from http://code.ulb.ac.be/dbfiles/media256.pdf.
[4] R. Kimball. The Data Warehouse ETL Toolkit. John Wiley, 2004.
[5] E.F. Codd, S.B. Codd, and C.T. Salley. Providing OLAP (on-line analytical processing) to
user-analysts : An IT mandate. Technical report, Arborsoft, 1993. White paper available
from http://www.arborsoft.com/papers/.
[6] N. Pendse and R. Creeth. The OLAP Report. Business Intelligence Incorporated, 1998.
[7] T. Bray, J. Paoli, and C. Michael. Extensible Markup Language (XML) Version 1.0. W3C
Recommandation, 1998.
[8] C. Goldfarb. Information processing : text and office systems : Standard Generalized Markup
Language (SGML). ANSI, 1985.
[9] C. F. Goldfarb. A Generalized Approach to Document Markup. In Proceedings of the
SIGOA STM, pages 68–73, 1981.
[10] T. Berners-Lee and D. Connolly. Hypertext Markup Language (HTML). RFC 1866, 1995.
[11] S. St. Laurent. Inside XML DTDs. McGraw Hill, 1999.
[12] D. Fallside. XML Schema. W3C Recommendation, 2001.
[13] E. van der Vlist. XML Schema. O’Reilly & Associates, Inc., 2002.
[14] J. Clark. RELAX NG Specification. OASIS Committee Specification, 2001.
[15] D. Megginson. SAX 2.0 : The Simple API for XML. Web page, 2000. http://www.
megginson.com/SAX/index.html.
[16] E. Wilde. The Extensible XML Information Set. Technical report, Computer Engineering
and Networks Laboratory, 2003.
[17] L. Wood, V. Apparao, and S. Byrne. Document Object Model (DOM). W3C Recommandation,
1998.
[18] M. Fernández, A. Malhotra, J. Marsh, M. Nagy, and N. Walsh. XQuery 1.0 and XPath 2.0
Data Model (XDM). W3C Candidate Recommendation, 2006.

BIBLIOGRAPHIE 103
[19] J. Clark and S. DeRose. XML Path Language (XPath) Version 1.0. W3C Recommendation,
1999.
[20] J. Clark. XML Transformations (XSLT) Version 1.0. W3C Recommendation, 1999.
[21] V. Benzaken, G. Castagna, and A. Frisch. CDuce : An XML-centric general-purpose language.
In Proceedings of the ICFP, pages 51–63, 2003.
[22] D. Chamberlin, D. Florescu, J. Robie, J. Siméon, and M. Stefanescu. XQuery 1.0 : A Query
Language for XML. W3C Candidate Recommendation, 2006.
[23] S. Abiteboul, D. Quass, J. McHugh, J. Widom, and J. Wiener. The Lorel Query Language
for Semistructured Data. In International Journal on Digital Libraries, pages 68–88, 1997.
[24] J. Melton and S. Buxton. Querying XML - XQuery, XPath, and SQL/XML in Context.
Morgan Kaufmann, 2006.
[25] M. Fernández, J. Siméon, P. Wadler, S. Cluet, A. Deutsch, D. Florescu, A. Levy, D. Maier,
J. McHugh, J. Robie, D. Suciu, and J. Widom. XML Query Languages : Experiences and
Exemplars. 1999. Paper available from http://www-db.research.belllabs.com/user/
simeon/xquery.ps.
[26] J. Robie, D. Chamberlin, M. Marchiori, and P. Fankhauser. XML Query (XQuery) Requirements.
W3C Working Draft, 2005.
[27] J. Robie, D. Chamberlin, and D. Florescu. Quilt : An XML Query Language. In Proceedings
of XML Europe 2000, 2000.
[28] J. Robie, J. Lapp, and D. Schach. XML Query Language (XQL). W3C Proposal, 1998.
[29] A. Deutsch, M. Fernandez, and D. Florescu. XML-QL : A Query Language For XML. W3C
Proposal, 1998.
[30] A. M. Alashqur, S. Y. W. Su, and H. Lam. OQL : A Query Language for Manipulating
Object-oriented Databases. In Proceedings of the ICVLDB, pages 433–442, 1989.
[31] E. Zimányi. Cours de Base de Données (ULB INFO-364). Web page, 2005. http://cs.
ulb.ac.be/cours/info364.
[32] Mark Logic Corporation. MarkLogic Server : Introduction to XQuery, 2005.
[33] D. Chamberlin and J. Robie. XQuery Update Facility Requirements. W3C Working Draft,
2005.
[34] S. Buxton and M. Rys. XQuery and XPath Full-Text Requirements. W3C Working Draft,
2003.
[35] J. Melton and S. Muralidhar. XML Syntax for XQuery 1.0 (XQueryX). W3C Candidate
Recommendation, 2006.
[36] K. Beyer, R. Cochrane, L. Colby, F. Ozcan, and H. Pirahesh. XQuery for Analytics :
Challenges and Requirements. In Proceedings of the XIME-P, pages 3–8, 2004.
[37] A. Laux and L. Martin. XUpdate XML Update Language. XML :DB Working Draft, 2000.
[38] K. Beyer, D. Chamberlin, L. Colby, F. Ozcan, H. Pirahesh, and Y. Xu. Extending XQuery
for Analytics. In Proceedings of the ICMD, pages 503–514, 2005.

BIBLIOGRAPHIE 104
[39] R. Bordawekar and C. Lang. Analytical Processing of XML Documents : Opportunities
and Challenges. In Proceedings of the SIGMD, pages 27–32, 2005.
[40] V. Borkar and M. Carey. Extending XQuery for Grouping, Duplicate Elimination, and
Outer Joins. In Proceedings of XML 2004, 2005.
[41] E. Lenz. Xquery : Reinventing the wheel ? Web page, 2001. http://www.xmlportfolio.
com/xquery.html.
[42] D. Chamberlin, P. Fankhauser, D. Florescu, M. Marchiori, and J. Robie. XML Query Use
Cases. W3C Working Draft, 2006.
[43] A. Deutsch, Y. Papakonstantinou, and Y. Xu. Minimization and group-by detection for
nested xqueries. In Proceedings of the ICDI, pages 839–854, 2004.
[44] T. Pankowski. XML-SQL : An XML Query Language Based on SQL and Path Tables. In
Proceedings of the EDBT, pages 184–209, 2002.
[45] H. Schöning. Tamino - A DBMS Designed for XML. In Proceedings of the ICDE, pages
149–154, 2001.
[46] M. Olson, K. Bostic, and M. Seltzer. Berkeley DB. In Proceedings of the FREENIX Track,
pages 183–192, 1999.
[47] R. Bourret. XML and Databases. Web page, 2006. http://www.rpbourret.com/xml/
XMLAndDatabases.htm.
[48] Q. Li and B. Moon. Indexing and Querying XML Data for Regular Path Expressions. In
Proceedings of the ICVLDB, pages 361–370, 2001.
[49] S. Al-Khalifa, H. V. Jagadish, J. M. Patel, Y. Wu, N. Koudas, and D. Srivastava. Structural
joins : A primitive for efficient XML query pattern matching. In Proceedings of the ICDE,
pages 141–152, 2002.
[50] C. Zhang, J. Naughton, D. DeWitt, Q. Luo, and G. Lohman. On Supporting Containment
Queries in Relational Database Management Systems. In Proceedings of the ICMD, pages
425–436, 2001.
[51] R. Bayer and E. M. McCreight. Binary B-trees for virtual memory. In Proceedings of the
ACM SIGFIDET Workshop, pages 219–235, 1971.
[52] R. Bayer and E. M. McCreight. Organization and Maintenance of Large Ordered Indexes.
In Proceedings of the ACM SIGFIDET Workshop, pages 107–141, 1972.
[53] S. Chien, V. J. Tsotras, C. Zaniolo, and D. Zhang. Efficient Complex Query Support for
Multiversion XML Documents. In Proceedings of the EDBT, pages 161–178, 2002.
[54] Y. Kyu Lee, S. Yoo, and K. Yoon. Index Structures for Structured Documents. In Proceedings
of the ICDL, pages 91–99, 1996.
[55] D. Shin, H. Jang, and H. Jin. BUS : An Effective Indexing and Retrieval Scheme in
Structured Documents. In Proceedings of the ICDL, pages 235–243, 1998.
[56] P. F. Dietz. Maintaining Order in a Linked List. In Proceedings of the STOC, pages 122–127,
1982.
[57] T. Böhme and E. Rahm. Supporting Efficient Streaming and Insertion of XML Data in
RDBMS. In Proceedings of the DIWeb, 2004.

BIBLIOGRAPHIE 105
[58] D. Florescu and D. Kossmann. A Performance Evaluation of Alternative Mapping Schemes
for Storing XML Data in a Relational Database. Technical report, INRIA, 1999.
[59] T. Grust. Accelerating XPath Location Steps. In Proceedings of the ICMD, pages 109–120,
2002.
[60] J. Shanmugasundaram, K. Tufte, G. He, C. Zhang, D. DeWitt, and J. Naughton. Relational
Databases for Querying XML Documents : Limitations and Opportunities. In Proceedings
of the ICVLDB, pages 302–314, 1999.
[61] W. Meier. eXist : An Open Source Native XML Database. In Proceedings of WWSDS,
pages 169–183, 2002.
[62] D. Pedersen, K. Riis, and T. B. Pedersen. Query Optimization for OLAP-XML Federations.
In Proceedings of the DOLAP, pages 57–64, 2002.
[63] D. Pedersen and T. B. Pedersen. Achieving adaptivity for OLAP-XML federations. In
Proceedings of the DOLAP, pages 25–32, 2003.
[64] W. Hümmer, A. Bauer, and G. Harde. XCube : XML for Data Warehouses. In Proceedings
of the DOLAP, pages 33–40, 2003.
[65] V. Borkar and M. Carey. XML for Analysis Specification. Microsoft Specification, 2001.
[66] A. Guttman. R-Trees : A Dynamic Index Structure for Spatial Searching. In SIGMOD’84,
Proceedings of Annual Meeting, pages 47–57, 1984.
[67] S. Subramanian, F. Raab, L. Livingtree, and J. Buggert. TPC-H Benchmark. Technical
report, TPC, 2003.
[68] J. Gray, S. Chaudhuri, A. Basworth, A. Layman, D. Reichart, M. Venkatrao, F. Pellow, and
Pirahesh H. Data cube : A relational aggregation operator generalizing group-by, cross-tab,
and sub-totals. In Proceedings of the ICDE, pages 152–159, 1996.
[69] M. Kay. Positional Grouping in XQuery. In Proceedings of the XIME-P, pages 22–28, 2006.
[70] R. Bayer. The Universal B-Tree for Multidimensional Indexing : general Concepts. In
Proceedings of the WWCA, pages 198–209, 1997.