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