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

Transcription

1 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

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

3 TABLE DES MATIÈRES iii Table des matières Remerciements ii 1 Introduction 1 2 Les entrepôts de données Motivations Définitions Le modèle multidimensionnel Notions Modèles de données Collecte et intégration des données Analyse des données Conclusions Les documents XML Introduction Historique Motivations Le document XML Les outils de base Notions générales Types de documents XML Les éléments, ses attributs et les données textuelles L espace de nom Les DTD et les Schémas XML Modélisation des documents XML

4 TABLE DES MATIÈRES iv Ordres SAX Infoset DOM Modèle de données XQuery Conclusions Les langages d interrogation XML Introduction XPath Les axes XPath XQuery Introduction Expressions FLWR Quantificateurs Opérateurs de comparaison d ordre Fonctions Traitement Limitations Autres langages d interrogation XSLT Lorel CDuce SQL/XML Conclusions

5 TABLE DES MATIÈRES v 5 Les bases de données XML Introduction Types de bases de données XML Bases de données relationnelles Bases de données objet Bases de données XML natives Bases de données XML natives Définition Utilisations Systèmes existants Indexation des documents XML Traitement des requêtes grâce aux indexes exist, une base de données XML native libre Introduction Architecture Indexation Traitement des requêtes Conclusions Les entrepôts de données XML natifs Introduction Systèmes d analyse (OLAP) Sources et résultats en XML Systèmes natifs XML Besoins d un système OLAP basé sur XML Modélisation Indexation Langage Le test TPC-H Traduction des données sources Traduction des requêtes Conclusions

6 TABLE DES MATIÈRES vi 7 Les groupements en XQuery Base de données source Requêtes d analyse Opérateur GROUP BY en SQL Groupements en XQuery Scénario d évaluation Méthodes d évaluation Génération de l échantillon Conditions du test Mesures Paramètres Requêtes effectuées Analyse des résultats Conclusions Conclusions et travaux futurs Conclusions Travaux Futurs

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

8 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

9 3 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 Définitions Le modèle multidimensionnel Collecte et intégration des données Analyse des données Conclusions 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,...

10 2.2 Définitions 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 :

11 2.3 Le modèle multidimensionnel 5 Sources Analyse de données (OLAP) Bases de données diverses Extraction, Transformation, Chargement Entrepôt de données Fichiers (ETL) Internet Forage de données (data mining) Fig. 2.1 Architecture d un entrepôt de données. 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.

12 2.3 Le modèle multidimensionnel 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 Produit PK Dimension Temps PK jour semaine mois trimestre année 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 Dimension Géographie PK id_vendeur nom_vendeur groupe departement 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

13 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. Bruxelles Wallonie Flandre souris écran clavier Années Produits Régions 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.

14 2.3 Le modèle multidimensionnel 8 Bruxelles Wallonie Flandre écran souris Bruxelles Wallonie Flandre clavier écran Coupe sur 2005 (Slice) souris clavier Fig. 2.5 Opération slice, extraction d une tranche d un cube. Bruxelles Wallonie Flandre souris écran Bruxelles Wallonie clavier souris Extraction d un sous-cube (Dice) clavier Fig. 2.6 Opération dice, extraction d un sous-cube. 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 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

15 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 Trimestres PK trimestre Années PK année Semaines PK semaine FK1 année FK1 année Mois PK mois Dimension Temps PK jour Départements PK id_departement FK1 FK2 année trimestre FK1 FK2 mois semaine nom_departement Fait Vente Dimension Produit PK id_vente Dimensions Vendeurs Groupes PK id_produit nom_produit FK1 id_categorie FK1 FK2 FK3 FK4 nombre montant id_produit jour id_vendeur id_magasin PK id_vendeur nom_vendeur FK1 id_groupe PK id_groupe nom_groupe FK1 id_departement Catégories Dimension Géographie Communes PK id_categorie PK id_magasin PK id_commune FK1 nom_catégorie id_famille FK1 nom_magasin id_commune FK1 nom_commune id_region Familles PK id_famille nom_famille Régions PK id_region nom_region FK1 id_pays Pays PK id_pays nom_pays 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,

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

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

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

19 13 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 Historique Motivations Le document XML Les DTD et les Schémas XML Modélisation des documents XML Conclusions 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.

20 3.2 Historique 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 <font> au lieu de <H1>). 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.

21 3.3 Motivations 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 <p> 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

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

23 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 Notions générales Document XML <?xml version = 1.0'?> Prologue Attribut <contact id= 245' > <nom>marc Dupond</nom> <telephone> <bureau> </bureau> <maison> </maison> </telephone> </contact> Elément Contenu (PCDATA) Fig. 3.1 Exemple de fichier XML. 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 Types de documents XML Les documents XML peuvent se classer en deux grandes catégories : orientés données et orientés présentation.

24 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 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, <personne>jean Dupond</personne> est un élément et <personne id="3876">jean Dupond</personne> 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. <a href="http :// 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 : <personne>jean Dupont<age>18</age></personne> 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

25 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 : <personne sexe="m">jean Dupond</personne> <personne><nom>jean Dupond</nom><sexe>m</sexe></personne> 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 : <personne id="3876">jean Dupond</personne> <pomme couleur="vert">jonagold</pomme> 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 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 ;

26 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 : <? xml version =" 1.0 " standalone =" yes "?> <! DOCTYPE livre [ <! ELEMENT livre ( titre, auteurs ) > <! ATTLIST livre ISBN CDATA # REQUIRED > <! ELEMENT titre # CDATA > <! ELEMENT auteurs ( personne +) > <! ELEMENT personne ( nom, prenom ) > <! ELEMENT nom # CDATA > <! ELEMENT prenom # CDATA > ]> <livre ISBN =" "> <titre >L art de l intrusion </ titre > < auteurs > < personne ><nom > Mitnick </ nom >< prenom >Kevin </ prenom ></ personne > < personne ><nom >Simon </ nom >< prenom > William </ prenom ></ personne > </ auteurs > </ livre > 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,

27 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 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: // /2001/ XMLSchema "> (...) </ xsd:schema > A titre d illustration, voici le Schéma XML suivant, qui correspond à l exemple de la page précédente. <? xml version =" 1.0 "> < xsd:schema xmlns:xsd =" http: // /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 "/> </ xsd:sequence > </ xsd: complextype >

28 3.6 Modélisation des documents XML 22 </ xsd:element > </ xsd:element > </ xsd:sequence > < xsd:attribute name =" ISBN " type =" xsd:string " use =" required "/> </ xsd: complextype > </ xsd:element > </ xsd:schema > 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 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

29 3.6 Modélisation des documents XML 23 <contact id= 245' > <nom>marc Dupond</nom> <telephone> <bureau> </bureau> <maison> </maison> </telephone> </contact> contact id nom telephone 245 Marc Dupond bureau maison Fig. 3.2 Modélisation graphique d un document XML. Ordre du document L ordre d un document XML peut être très important. Par exemple, dans le cas d un document XML orienté présentation comme, par exemple, un manuel d utilisation, l ordre des chapitres est essentiel. L ordre d un document XML est l ordre séquentiel de lecture du document, de gauche à droite et de haut en bas. Ordre des nœuds Comme nous l avons vu précédemment au point 3.6, un document XML peut se représenter comme un arbre. Nous utilisons donc les ordres de parcours classiques de l algorithmique des arbres. Dans un parcours pré-fixé, ou pré-ordre, un nœud v est visité et son numéro d ordre pre(v) est assigné avant que ses enfants soient parcourus récursivement de gauche à droite. Dans un parcours post-fixé, ou post-ordre, un nœud v est visité et son numéro d ordre post(v) lui est assigné après que tous ses fils aient été parcourus récursivement de gauche à droite. Ces deux ordres de parcours sont illustrés à la figure SAX SAX, Simple API for XML [15], est une API (Application Programming Interface) pour XML basée sur les événements, afin d utiliser XML dans les applications. De nombreux analyseurs syntaxiques SAX sont disponibles comme SAXON.

30 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) = Modélisation des documents XML 24 a (0) a (9) (1) b g (6) (4) b g (8) (2) c (5) f h (7) (2) c (3) f h (7) (3) d (4) e (a) i (8) j (9) (0) d (1) e (b) i (5) j (6) Fig (a) Parcours Preorderpré-ordre and (b) postorder et (b) parcours traversal post-ordre of and un XMLarbre. tree 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 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 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 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

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

32 3.7 Conclusions 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.

33 27 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 XPath XQuery Autres langages d interrogation Conclusions 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.

34 4.2 XPath 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 ="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 à Pour illustrer, observons les résultats de cette requête sur le document suivant : < clients > <client id=" 1547 "> <nom >Marc Dupont </ nom > <dob > </ dob > <type > Independant </ type > </ client > <client id=" 1548 "> <nom >Luc Dubois </ nom > <dob > </ dob > </ client > </ clients > Le résultat de notre requête sera donc <nom>luc Dubois</nom>. 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 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

35 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 Les axes XPath Axes parent ancestor ancestor-or-self child descendant descendant-or-self preceding following preceding-sibling following-sibling attribute self Ensemble de nœuds résultant Le premier nœud sur le chemin de u vers le nœud racine Tous les nœuds sur le chemin de u vers la racine u et tous les nœuds sur le chemin vers la racine Les descendants directs du nœud u Tous les nœuds dont u est l ancêtre u et tous les nœuds dont u est l ancêtre Les nœuds précédents le nœud u (exceptés les ancêtres) dans l ordre du document Les nœuds suivants le nœud u (exceptés les descendants) dans l ordre du document Les frères précédents du nœud u dans l ordre du document Les frères suivants du nœud u dans l ordre du document Les attributs du nœud u u 16 Tab. 4.1 Sémantique Chapter des1. axes Extensible XPath pour Mark-up le nœud u. Language (XML) (a) (b) (c) 8 9 Fig. 4.1 Sémantique des axes XPath : (a) parent : :*, (b) ancestor : :* et (c) ancestoror-self 1.3. : :* XPath à partir semantics: du nœud 7. signposted nodes are nodes of the result forest if an Fig. (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» (child) et l axe «descendant ou soi» (descedant-or-self ). Ces deux axes peuvent être abrégés respectivement grâce aux symboles / et //. Ainsi, les deux expressions suivantes sont équivalentes (a) (b) (c) 8 9 Fig XPath semantics: signposted nodes are nodes of the result forest if an

36 (a) (b) (c) Fig 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 (a) (b) (c) 1.5. Another XML Technologies 17 Fig 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 XQuery 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 respectively. 6 et 1.9 respectivement. (XQuery queries). du Fig XPath semantics: signposted nodes are nodes of the result forest if an Example nœud (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 doc( books.xml )/books/book[price<50] (a) Listing Example of XQuery 2 queries for $x in doc( books.xml )/books/book 3 4 (a) 8 9 (b) where $x/price>50 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. <results> node Fig 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, ="1548"]/ nom / child :: clients $a in $b/author / child :: client ="1548"]/ child :: nom return $n in $b/name, <result> D autres raccourcis $a in $b/author sont fournis par XPath, par exemple, return { $n } l expression <result> { $a }./ décrit le nœud contexte. </result> { $n } l expression } { $a../ } indique le nœud parent. </results> </result> l expression // dénote le nœud racine, mais pour une expression de type a//b, cette } </results> expression dénote n importe quel nœud b descendant du nœud a. 1.5 Another XML Technologies Le tableau 4.1 liste les axes XPath et explique brièvement leur sémantique. Les figures 4.1, 4.2, 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 (b) 5 6

37 4.3 XQuery XQuery 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.

38 4.3 XQuery 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 return clause let clause where clause order by Fig. 4.5 Expression FLWR. for et let Liste de tuples et variables where Tuples et variables filtrés order by Tuples ordonnés return Résultats XML (arbre de tuples) Fig. 4.6 Représentation schématique du fonctionnement d une expression FLWR.

39 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 : <results > for $client in // client let $produits := // commande [ client = $client ]// article where count ( $produits ) >= 2 return <nom >{ $client / nom / text () }</ nom > </ results > 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 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 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.

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

41 4.3 XQuery 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:flwr > < q:forassignment variable ="$b"> <q:step axis =" slashslash "> < q:function name =" document "> < q:constant datatype =" charstring ">

42 4.3 XQuery 36 bib. xml </ q:constant > </ q:function > < q:identifier > book </ q:identifier > </ q:step > </ q: forassignment > < q:where >... </ q:where > < q:return >... </ q:return > </ q:flwr > 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

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

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

45 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 : <nom > Paul Dupond </ nom > <nom > Louis Dubois </ nom >... 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.

46 40 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 Types de bases de données XML Bases de données XML natives exist, une base de données XML native libre Conclusions 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».

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

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

49 5.3 Bases de données XML natives Bases de données XML natives 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

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

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

52 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

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

54 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 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 treede traversal parcoursorder l arbre to pour déterminer determine the les relations ancestor-descendant structurellesrelationship ancêtre-descendant between any entre pair uneofpaire 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, 44) > 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. (0,9) (1,4) (6,8) (2,2) (3,0) (4,1) (5,3) (7,7) (8,5) (9,6) Fig. 5.2 Arbre XML numéroté suivant la numérotation de Dietz. Fig 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 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 (D 1, S 1, E 1, L 1 ) 3 est un descendant du nœud (D 2, S 2, E 2, L 2 ) si et seulement si D 1 = D 2 et S 1 < S 2 et E 1 > E 2. 3 L attribut L est utilisé uniquement pour les relations parent-enfant.

55 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) <= order(x)+ size(x). Pour deux nœuds frères x et y, si x est le prédécesseur d y dans un parcours en pré-ordre de l arbre, alors order(x) + size(x) < order(y). L ordre (order) est assigné en conformité avec un parcours pré-ordre de l arbre du document XML. La taille d un nœud (size) est un entier arbitrairement plus grand que le nombre total de ses descendants. La relation ancêtre-descendant entre deux nœuds peut être déterminée par la proposition suivante : Pour deux nœuds x et y, x est un ancêtre de y si et seulement si order(x) < order(y) et order(y) <= order(x) + size(x) L avantage majeur de XISS est que la relation ancêtre-descendant peut être déterminée en temps constant grâce à la proposition précédente. De plus, XISS supporte les mises à jour de document, via des insertions et suppressions de nœuds en introduisant des identificateurs clairsemés entre les nœuds. En effet, comme la taille d un nœud est un entier arbitrairement plus grand que le nombre de ses descendants, des identificateurs restent disponibles et peuvent donc être utilisés pour l ajout de nœuds. Il n est donc pas nécessaire de re-numéroter l arbre du 2.2. document Approaches avant quebased tous leson identificateurs Relation Decomposition clairsemés ne soient utilisés. La figure 5.3 compare 23 le plan de Dietz et le plan XISS. (0,9) (1,100) (1,4) (6,8) (10,30) (45,30) (2,2) (5,3) (7,7) (11,15) (30,10) (50,20) (3,0) (4,1) (a) (8,5) (9,6) (15,5) (22,5) (b) (55,5) (65,5) Fig. 5.3 (a) numérotation de Dietz (b) numérotation XISS. Fig Numbering schemes of an XML tree: (a) Dietz s numbering scheme (b) XISS numbering Comparativement scheme avec le plan de Dietz, ce plan de numérotation est plus flexible et peut gérer plus efficacement les mises à jour dynamiques du document XML. C est une technique commune pour gérer les insertions dans un document XML : des espaces dans la numérotation Global des identificateurs reordering sont is not réservés necessary pouruntil les insertions all the reserved futures. spaces Le réordonnancement (i.e., unused order des nœuds values) are n estconsumed. pas nécessaire Note tant that qu il for reste both desnumbering valeurs d identificateurs schemes, deleting inutilisées. a node does note cause renumbering the nodes. However, it is easier for the numbering scheme to recycle the order values XISS of définit deleted également nodes. une structure d index et des algorithmes de traitement d expressions de chemin, Nous en reparlerons au point Index Structure The index structure of XISS is composed of three major components: element index, attribute index, and structure index. All distinct name strings are collected in the name index, which is implemented as a B + -tree. Then, each distinct name string is uniquely identified by a name identifier (or nid) returned from the name index. All string values

56 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. <contact> <nom>marc Dupond</nom> <telephone> <bureau> </bureau> <maison> </maison> </telephone> </contact> 1 contact Identificateur clairsemé 2 nom 3 telephone 4 Marc Dupond 5 6 bureau 7 maison 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) parent i = + 1 k Pour obtenir l identificateur du j e fils d un nœud identifié par i, on utilise la fonction suivante : parent i,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.

57 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. <contact> <nom>marc Dupond</nom> <telephone> <bureau> </bureau> <maison> </maison> </telephone> </contact> 1 contact Identificateur clairsemé (nœud virtuel) 2 nom 3 telephone 4 Marc Dupond 5 6 bureau 7 maison Fig. 5.5 Numérotation virtuelle par niveaux. 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.

58 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

59 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. <document> <chapitre> <section> </section> </chapitre> <chapitre> <section> </section> </chapitre> <chapitre> <section> </section> <section> </section> </chapitre> </document> 1.1 chapitre section 1 document 1.2 chapitre section section 1.3 chapitre section Fig. 5.6 Numérotation dynamique par niveaux (DLN). 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 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

60 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 XX XXXX X XXXX XXXX XXXX XXXX XXXX XXX XXXX XXXX XXXX XX XXXX XXXX XXXX XXXX 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 peut être encodé sur 52 bits, ce qui est plus efficace que l encodage en nombres entiers de l identificateur vu au point 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 / 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.

61 5.3 Bases de données XML natives 55 <document> <chapitre> <section> </section> </chapitre> <chapitre> <section> </section> <section> </section> </chapitre> <chapitre> <section> </section> </chapitre> <chapitre> <section> </section> </chapitre> </document> 1.0/1 chapitre 1.0/1.1 section section 1.1 chapitre 1 document section 1.1/1 chapitre 1.1/1.1 section insertions 1.2 chapitre 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 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 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 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<1000.0] sont deux opérations très simples. Par contre, la jointure de ces deux ensembles de nœuds nécessite une attention particulière. Dans cette section, nous allons introduire différentes méthodes permettant de faire de telles jointures efficacement. Ces algorithmes sont appelés algorithmes de jointure structurelle. Ils prennent en entrée deux listes de nœuds ou d identificateurs de nœuds ordonnés selon l ordre du document et doivent donner en sortie une liste de nœuds ou d identificateurs ordonnés selon l ordre d une des deux listes d entrée. L algorithme doit déterminer si les nœuds de la première liste sont des ancêtres ou des parents des nœuds de la deuxième et renvoyer la liste des nœuds satisfaisant cette condition.

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

63 5.3 Bases de données XML natives 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.

64 5.4 exist, une base de données XML native libre exist, une base de données XML native libre 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 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 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

65 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. Fig. 5.8 Architecture d exist c Wolfgang Meier. Système de stockage 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.

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

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

68 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 Node n 1 Node n 2... DOM nodes Document d Introducing exist Node 2 Identification Schemes and Indexing XQuery Processing Outlook Node-id Address Data pages... Document Storage... 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 <collection-id, name-id> doc-id node-id node-id... doc-id... B+-Tree value: array of node-ids seperated by doc-id Fig Architecture de stockage d exist c Wolfgang Meier. B+-Tree keys 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.

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

70 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"> <nom >Lampe de Bureau </ nom > <prix > </ prix > </ article > < article id="2"> <nom >Lampe de Chevet </ nom > <prix > </ prix > </ article > </ articles > 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) ]

71 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 > <mot >ecran </ mot > <mot > moniteur </ mot > </ synonyme > 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 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

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

73 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 = salarie or $i/ client = independant or $i/ client = etudiant return $i Cette expression peut se réécrire très facilement et plus lisiblement en utilisant l expression XPath suivante : // commande / client = ( 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

74 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 <resultat > <commande >{ $commande / text () } </ commande > { $article } </ resultat > 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 <resultat > <commande >{ $article / ancestor / text () }</ commande > { $article } </ resultat > 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

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

76 70 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 Systèmes d analyse (OLAP) Besoins d un système OLAP basé sur XML Le test TPC-H Conclusions 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

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

78 6.2 Systèmes d analyse (OLAP) 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 : division département département Dimension département groupe groupe groupe employé employé employé Faits salaire date de naissance salaire date de naissance salaire date de naissance Mesures Fig. 6.1 Exemple de modélisation XML pour un outil OLAP. 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

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

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

81 6.3 Besoins d un système OLAP basé sur XML dimension temporelle Belgique dimension géographique semestre1 semestre2 Flandre Wallonie mars novembre octobre Anvers Namur Liège faits 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 <group > { $region } { $mois } <count >{ count ( $bons_faits )}</ count > </ group > 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.

82 6.3 Besoins d un système OLAP basé sur XML 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 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

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

84 6.4 Le test TPC-H 78 PART (P_) SF*200,000 PARTKEY PARTSUPP (PS_) SF*800,000 PARTKEY LINEITEM (L_) SF*6,000,000 ORDERKEY ORDERS (O_) SF*1,500,000 ORDERKEY NAME SUPPKEY PARTKEY CUSTKEY MFGR AVAIL QTY SUPPKEY ORDERSTATUS BRAND SUPPLYCOST LINENUMBER TOTALPRICE TYPE COMMENT QUANTITY ORDERDATE SIZE CONTAINER RETAILPRICE COMMENT SUPPLIER (S_) SF*10,000 SUPPKEY NAME ADDRESS NATIONKEY CUSTOMER (C_) SF*150,000 CUSTKEY NAME ADDRESS NATIONKEY PHONE ACCTBAL MKTSEGMENT COMMENT EXTENDEDPRICE DISCOUNT TAX RETURNFLAG LINESTATUS SHIPDATE COMMITDATE RECEIPTDATE SHIPINSTRUCT SHIPMODE ORDER- PRIORITY CLERK SHIP- PRIORITY COMMENT PHONE ACCTBAL COMMENT NATION (N_) 25 NATIONKEY NAME REGIONKEY COMMENT COMMENT REGION (R_) 5 REGIONKEY NAME COMMENT Fig. 6.5 Schéma logique de la base TPC-H c TPC. < regions > <region regionkey = 1 > <name >Europe </ name > < comment >None </ comment > </ region > (...) </ regions > Fig. 6.6 Fragment de traduction XML des données sources du test TPC-H 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.

85 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 AND l_ shipdate < date interval 1 year AND l_ discount between and 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 (" ") and xs: date (./ shipdate ) < (xs: date (" ") + xdt : yearmonthduration (" P1Y ")) and xs: double (./ discount ) >= xs: double (0.06) - xs: double (0.01) and xs: double (./ discount ) <= xs: double (0.06) + xs: double (0.01) and xs: double (./ quantity ) < 24] return <case > <revenue >{ sum (xs: double ( $lineitem / extendedprice )*xs: double ( $lineitem / discount ))}</ revenue > </case > Fig. 6.8 Requête 6 du test TPC-H en XQuery. Comme nous pouvons le constater, la traduction de cette requête ne pose aucun problème. Il s agit d une longue expression XPath sélectionnant tous les éléments satisfaisants les conditions données, c est à dire les lignes de commandes passées en 2004 dont la quantité d articles est inférieure à 24 et dont la réduction associée se situe entre 5 % et 7 %. La variable XQuery $lineitem contient donc tous ces éléments et la somme est calculée dans la clause return. Requête de groupement La requête numéro 3 du test TPC-H permet de trouver les commandes non encore livrées classées en fonction du revenu qu elles apporteraient à l entreprise si elles étaient livrées. Ce genre de requête peut aider à identifier les commandes prioritaires qu il faut livrer rapidement afin de faire rentrer de l argent dans l entreprise. La figure 6.9 présente cette requête en SQL

86 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 = $l_ orderkey and orderdate eq $o_ orderdate and shippriority eq $o_ shippriority ] let $lineitems := document (" lineitem. xml ") // lineitem [ orderkey = $order ] let $customer := document (" customer. xml ") // customer = $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 <case > <l_orderkey >{ $l_orderkey }</ l_orderkey > <revenue >{ $revenue }</ revenue > <o_orderdate >{ $o_orderdate }</ o_orderdate > < o_ shippriority >{ $o_ shippriority } </ o_ shippriority > </case > Fig 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

87 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

88 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 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 and commitdate lt receiptdate ] where exists ( $lineitems ) return { $order } } where exists ( $orders ) order by $o_ orderpriority return <case > < o_ orderpriority >{ $o_ orderpriority } </ o_ orderpriority > <order_count >{ count ( $orders )}</ order_count > </case > Fig 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.

89 6.5 Conclusions 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.

90 84 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 Requêtes d analyse Groupements en XQuery Scénario d évaluation Analyse des résultats Conclusions 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.

91 7.1 Base de données source 85 < commandes > < commande id="1"> <client id=" "> <nom > Verhaegen Boris </ nom > < endroit >Rue des Metaux, 11 </ endroit > <ville > Bruxelles </ ville > < codepostal >1040 </ codepostal > <pays > Belgique </ pays > < continent >UE </ continent > <type > Etudiant </ type > </ client > < magasin id="1"> <nom > Magasin Central </ nom > < endroit > Chaussee de Wavre, 23 </ endroit > <ville > Bruxelles </ ville > < codepostal >1050 </ codepostal > <pays > Belgique </ pays > < continent >UE </ continent > <classe > Grossiste </ classe > </ magasin > <date > </ date > < vendeur id=" 5985 "> <nom >Dupond </ nom > <prenom >Pierre </ prenom > <niveau >3</ niveau > </ vendeur > < prixttc unit =" EUR ">724,19 </ prixttc > <lignes > <ligne > < article id=" 256 "> <nom >Lampe de bureau </ nom > < famille > Eclairage </ famille > < categorie > Materiel de bureau </ categorie > <prixht unit =" EUR ">59,85 </ prixht > <tva >21 </ tva > </ article > < quantite >10 </ quantite > </ ligne > </ lignes > <statut >paye </ statut > </ commande > (...) </ commandes > Fig. 7.1 Exemple de base de données XML plate.

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

93 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 (" ") and CO. date <= date (" ") and CO. client_id = CL.id and CO. location_id = LO.id and LO. pays = " Belgique " GROUP BY LO.ville, CL. type Fig. 7.3 Requête de groupement en SQL à l aide de l opérateur GROUP BY. Ville Type SUM(prix) Bruxelles Etudiant 2600 Bruxelles Employé 7800 Liège Etudiant 1500 Liège Employé 5400 Liège Sans Emploi 700 Tab. 7.1 Résultats de la requête de la figure 7.3. la clause GROUB BY et les sous-totaux des niveaux plus élevés sont ensuite créés progressivement en parcourant de gauche à droite les clés des groupes calculés. ROLLUP et CUBE équivalent à une opération UNION sur un ensemble de requêtes de groupement. A titre d illustration, reprenons la requête SQL de la figure 7.3, ajoutons-y l extension ROLLUP (figure 7.4) et observons les résultats obtenus (tableau 7.2). SELECT LO.ville, CL.type, SUM ( prix ) FROM commandes CO, clients CL, locations LO WHERE CO. date >= date (" ") and CO. date <= date (" ") and CO. client_id = CL.id and CO. location_id = LO.id and LO. pays = " Belgique " GROUP BY ROLLUP LO. ville, CL. type Fig. 7.4 Requête de groupement en SQL à l aide de l opérateur GROUP BY. Alors que ROLLUP ne renvoie qu une partie des combinaisons de sous-totaux possibles, la fonction CUBE retourne toutes les combinaisons possibles des groupes spécifiés dans le GROUP BY ainsi qu un total. Par exemple, les résultats de notre requête de la figure 7.3 étendue avec CUBE sont présentés sur le tableau 7.3.

94 7.3 Groupements en XQuery 88 Ville Type SUM(prix) Bruxelles Etudiant 2600 Bruxelles Employé 7800 Bruxelles NULL Liège Etudiant 1500 Liège Employé 5400 Liège Sans Emploi 700 Liège NULL 7600 NULL NULL 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 Liège Etudiant 1500 Liège Employé 5400 Liège Sans Emploi 700 Liège NULL 7600 NULL Etudiant 4100 NULL Employé NULL Sans Emploi 700 NULL NULL 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].

95 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 <group > <ville >{ $ville }</ ville > <type >{ $type }</ type > <CA >{ sum ( $commandes / prixttc )}</CA > </ group > 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 <group > { $ville } { $type } <CA >{ sum ( $commande / prix )}</CA > </ group > 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.

96 7.3 Groupements en XQuery 90 < results > <group > <ville > Bruxelles </ ville > <type > Etudiant </ type > <CA >2600 </CA > </ group > (...) </ results > 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

97 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 for et let ($c = C1, $ville = Bruxelles, $type = étudiant) ($c = C2, $ville = Bruxelles, $type = etudiant) ($c = C3, $ville = Bruxelles, $type = employé)... where Liste de tuples et variables Tuples et variables filtrés group by $ville,$type group by ($c = C1,C2, $ville = Bruxelles, $type = étudiant) ($c = C3, $ville = Bruxelles, $type = employé)... order by Tuples groupés return <group> <ville>{$ville}</ville> <type>{$type}</type> <CA>{sum($c/prixTTC)}</CA> </group> return 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

98 7.4 Scénario d évaluation 92 Requête de groupement en XQuery officiel Méthode A Méthode B Traduction exist XML DB XML docs Simulation du group by (Script) Résultats (XML + temps) Résultats (XML + temps) Comparaison Fig. 7.9 Diagramme du scénario d évaluation. en implémentant un tel mot clé dans XQuery. La figure 7.9 représente la manière dont nous comptons évaluer les performances 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

99 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 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 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 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é.

100 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 Nombre de valeurs pour <statut> 4 Nombre de valeurs pour <classe> 2 Date minimale Date maximale Nombre de valeurs pour <continent> 5 Nombre de <pays> par <continent> 50 Nombre de <villes> par <pays> 100 Nombre de <codepostal> par <ville> 20 Nombre d <endroit> par <codepostal> 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 <categorie> 5 Nombre de <famille> par <categorie> 10 Nombre de valeurs pour <type> 5 Nombre de valeurs pour <niveau> 3 Tab. 7.4 Paramètres de l échantillon. Processeur AMD Mhz Mémoire vive 1024Mo Système d exploitation Linux 2.6 Machine Java Sun j2re 1.5 exist Version de développement SVN rev3915 ( ) Tab. 7.5 Spécifications de la station de test Conditions du 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 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 :

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

102 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 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 k, exist 10k, script k, exist 10k, script Temps (ms) Temps (ms) Nombre de groupes (a) 1000 éléments Nombre de groupes (b) 10K éléments Temps (ms) k, exist 10k, script Nombre de groupes (c) 100K éléments Fig 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 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).

103 7.6 Conclusions k, exist 1k, script Temps (ms) Nombre de groupes résultants Fig 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 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

104 7.6 Conclusions k, exist 1k, Script Temps (ms) Nombre de clés de groupement Fig 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.

105 7.6 Conclusions K commandes 10K commandes 100K commandes T(eXist)/T(script) Nombre de groupes résultants Fig 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) K commandes 10K commandes 100K commandes 7 T(eXist)/T(script) Nombre de clés de groupement Fig 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).

106 100 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.

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

108 BIBLIOGRAPHIE 102 Bibliographie [1] B. Inmon. Building the Data Warehouse. John Wiley, [2] R. Kimball. The Data Warehouse Toolkit. John Wiley, [3] E. Malinowski and E. Zimányi. Hierarchies in a multidimensional model : From conceptual modeling to logical representation. Data & Knowledge Engineering, Unpublished paper. Paper available from [4] R. Kimball. The Data Warehouse ETL Toolkit. John Wiley, [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, White paper available from [6] N. Pendse and R. Creeth. The OLAP Report. Business Intelligence Incorporated, [7] T. Bray, J. Paoli, and C. Michael. Extensible Markup Language (XML) Version 1.0. W3C Recommandation, [8] C. Goldfarb. Information processing : text and office systems : Standard Generalized Markup Language (SGML). ANSI, [9] C. F. Goldfarb. A Generalized Approach to Document Markup. In Proceedings of the SIGOA STM, pages 68 73, [10] T. Berners-Lee and D. Connolly. Hypertext Markup Language (HTML). RFC 1866, [11] S. St. Laurent. Inside XML DTDs. McGraw Hill, [12] D. Fallside. XML Schema. W3C Recommendation, [13] E. van der Vlist. XML Schema. O Reilly & Associates, Inc., [14] J. Clark. RELAX NG Specification. OASIS Committee Specification, [15] D. Megginson. SAX 2.0 : The Simple API for XML. Web page, megginson.com/sax/index.html. [16] E. Wilde. The Extensible XML Information Set. Technical report, Computer Engineering and Networks Laboratory, [17] L. Wood, V. Apparao, and S. Byrne. Document Object Model (DOM). W3C Recommandation, [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.

109 BIBLIOGRAPHIE 103 [19] J. Clark and S. DeRose. XML Path Language (XPath) Version 1.0. W3C Recommendation, [20] J. Clark. XML Transformations (XSLT) Version 1.0. W3C Recommendation, [21] V. Benzaken, G. Castagna, and A. Frisch. CDuce : An XML-centric general-purpose language. In Proceedings of the ICFP, pages 51 63, [22] D. Chamberlin, D. Florescu, J. Robie, J. Siméon, and M. Stefanescu. XQuery 1.0 : A Query Language for XML. W3C Candidate Recommendation, [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, [24] J. Melton and S. Buxton. Querying XML - XQuery, XPath, and SQL/XML in Context. Morgan Kaufmann, [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 Paper available from simeon/xquery.ps. [26] J. Robie, D. Chamberlin, M. Marchiori, and P. Fankhauser. XML Query (XQuery) Requirements. W3C Working Draft, [27] J. Robie, D. Chamberlin, and D. Florescu. Quilt : An XML Query Language. In Proceedings of XML Europe 2000, [28] J. Robie, J. Lapp, and D. Schach. XML Query Language (XQL). W3C Proposal, [29] A. Deutsch, M. Fernandez, and D. Florescu. XML-QL : A Query Language For XML. W3C Proposal, [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 , [31] E. Zimányi. Cours de Base de Données (ULB INFO-364). Web page, ulb.ac.be/cours/info364. [32] Mark Logic Corporation. MarkLogic Server : Introduction to XQuery, [33] D. Chamberlin and J. Robie. XQuery Update Facility Requirements. W3C Working Draft, [34] S. Buxton and M. Rys. XQuery and XPath Full-Text Requirements. W3C Working Draft, [35] J. Melton and S. Muralidhar. XML Syntax for XQuery 1.0 (XQueryX). W3C Candidate Recommendation, [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, [37] A. Laux and L. Martin. XUpdate XML Update Language. XML :DB Working Draft, [38] K. Beyer, D. Chamberlin, L. Colby, F. Ozcan, H. Pirahesh, and Y. Xu. Extending XQuery for Analytics. In Proceedings of the ICMD, pages , 2005.

110 BIBLIOGRAPHIE 104 [39] R. Bordawekar and C. Lang. Analytical Processing of XML Documents : Opportunities and Challenges. In Proceedings of the SIGMD, pages 27 32, [40] V. Borkar and M. Carey. Extending XQuery for Grouping, Duplicate Elimination, and Outer Joins. In Proceedings of XML 2004, [41] E. Lenz. Xquery : Reinventing the wheel? Web page, com/xquery.html. [42] D. Chamberlin, P. Fankhauser, D. Florescu, M. Marchiori, and J. Robie. XML Query Use Cases. W3C Working Draft, [43] A. Deutsch, Y. Papakonstantinou, and Y. Xu. Minimization and group-by detection for nested xqueries. In Proceedings of the ICDI, pages , [44] T. Pankowski. XML-SQL : An XML Query Language Based on SQL and Path Tables. In Proceedings of the EDBT, pages , [45] H. Schöning. Tamino - A DBMS Designed for XML. In Proceedings of the ICDE, pages , [46] M. Olson, K. Bostic, and M. Seltzer. Berkeley DB. In Proceedings of the FREENIX Track, pages , [47] R. Bourret. XML and Databases. Web page, XMLAndDatabases.htm. [48] Q. Li and B. Moon. Indexing and Querying XML Data for Regular Path Expressions. In Proceedings of the ICVLDB, pages , [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 , [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 , [51] R. Bayer and E. M. McCreight. Binary B-trees for virtual memory. In Proceedings of the ACM SIGFIDET Workshop, pages , [52] R. Bayer and E. M. McCreight. Organization and Maintenance of Large Ordered Indexes. In Proceedings of the ACM SIGFIDET Workshop, pages , [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 , [54] Y. Kyu Lee, S. Yoo, and K. Yoon. Index Structures for Structured Documents. In Proceedings of the ICDL, pages 91 99, [55] D. Shin, H. Jang, and H. Jin. BUS : An Effective Indexing and Retrieval Scheme in Structured Documents. In Proceedings of the ICDL, pages , [56] P. F. Dietz. Maintaining Order in a Linked List. In Proceedings of the STOC, pages , [57] T. Böhme and E. Rahm. Supporting Efficient Streaming and Insertion of XML Data in RDBMS. In Proceedings of the DIWeb, 2004.

111 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, [59] T. Grust. Accelerating XPath Location Steps. In Proceedings of the ICMD, pages , [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 , [61] W. Meier. exist : An Open Source Native XML Database. In Proceedings of WWSDS, pages , [62] D. Pedersen, K. Riis, and T. B. Pedersen. Query Optimization for OLAP-XML Federations. In Proceedings of the DOLAP, pages 57 64, [63] D. Pedersen and T. B. Pedersen. Achieving adaptivity for OLAP-XML federations. In Proceedings of the DOLAP, pages 25 32, [64] W. Hümmer, A. Bauer, and G. Harde. XCube : XML for Data Warehouses. In Proceedings of the DOLAP, pages 33 40, [65] V. Borkar and M. Carey. XML for Analysis Specification. Microsoft Specification, [66] A. Guttman. R-Trees : A Dynamic Index Structure for Spatial Searching. In SIGMOD 84, Proceedings of Annual Meeting, pages 47 57, [67] S. Subramanian, F. Raab, L. Livingtree, and J. Buggert. TPC-H Benchmark. Technical report, TPC, [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 , [69] M. Kay. Positional Grouping in XQuery. In Proceedings of the XIME-P, pages 22 28, [70] R. Bayer. The Universal B-Tree for Multidimensional Indexing : general Concepts. In Proceedings of the WWCA, pages , 1997.