Le fenêtrage en XQuery

Transcription

1 UNIVERSITÉ LIBRE DE BRUXELLES Faculté des Sciences Département d'informatique Le fenêtrage en XQuery NGUYEN Thanh Yên Promoteur : Prof. Esteban ZIMANYI Mémoire présenté en vue de l'obtention du grade de Master en Sciences Informatiques Année académique

2

3 Remerciements Je tiens à remercier mon promoteur, le professeur Esteban Zimanyi, pour ses deux années de cours intéressants qui m'ont permis de faire mes premiers pas dans le monde de bases de données. Ses encouragements, ses conseils, ses relectures et sa sympathie ont été pour moi d'un grand support. J'aimerais exprimer toute ma gratitude à mon superviseur, Boris Verhaegen. Je garderai mille et un souvenirs de sa disponibilité et du temps passé dans une ambiance agréable. Sa patience, son écoute, ses précieux conseils, ses remarques judicieux, ses relectures et ses corrections m'ont guidée tout au long de la préparation de ce mémoire. Je tiens à remercier mon cher professeur de langue, Marie Thérèse VDC, qui par ses nombreuses relectures et ses corrections dévouées m'a aidée à terminer ce travail, qui me projettera dans ma future carrière.

4 Table des matières 1 Introduction Contexte et objectifs du mémoire Structure du mémoire Contributions du mémoire XML Introduction Document XML Représentation textuelle d'un document XML Langages de schéma Conclusion XQuery Introduction XPath Chemin de localisation Relation entre XPath et XQuery FLWOR XQuery Groupement Problèmes du groupement Syntaxe du groupement Conclusion Le fenêtrage Introduction Extension de SQL avec les fonctions de fenêtrage Clause PARTITION BY Clause cadres de fenêtrage Tri et classement au sein d'une fenêtre i

5 4.3 Extension de XQuery avec les fonctions de fenêtrage Introduction Syntaxe de la clause de fenêtrage Comment une fenêtre est-elle établie? Fenêtre disjointe Fenêtre glissante et fenêtre glissante sans contraintes Conclusion Exemples de requêtes de comparaison entre SQL et XQuery Introduction Première requête Deuxième requête Troisième requête Quatrième requête Conclusion exist et les bases de données XML natives Introduction XML est-il une base de données? Bases de données XML natives Introduction Architectures de la base de données XML native Bases de données XML natives sur base textuelle Bases de données XML natives sur base de modèle Conclusion exist, une bases de données XML native Indexation et stockage du XML Introduction Système de numérotation Déroulement d'une requête XQuery Conclusion Implémentation de la clause de fenêtrage dans exist Introduction Grammaire Analyse de l'arbre syntaxique Classes de travail WindowCondition WindowValueSequence WindowValueSequenceTable ii

6 7.4.4 WindowExpr Les tests d'unité Scénario Fenêtre disjointe Fenêtre glissante Conclusion Résultats expérimentaux Introduction Générateur Données de travail Requêtes Analyse de données Collection simple Modèle avec et sans WindowEndCondition Modèle avec et sans modulo Modèle de types de fenêtres Collections multiples Conclusion Conclusion 87 A Les uses case du test d'unité 89 B A propos du stage 97 iii

7 Chapitre 1 Introduction 1.1 Contexte et objectifs du mémoire Dans le cadre du développement intense du langage XML et de ses technologies en l'occurrence, il joue de plus en plus un rôle important dans le monde informatique, en particulier dans le monde des bases de données. Par conséquent, la nécessité d'un moyen exible, qui permet de naviguer au sein de la structure arborescente des documents XML et de les faire interagir, a suscité la naissance d'un langage de requête puissant spéci- é pour XML, à savoir XQuery, inspiré de SQL, un langage d'interrogation destiné aux bases de données relationnelles. Ainsi, XQuery utilise le langage XPath pour parcourir les diérents niveaux de l'arbre XML, et avec son expression FLWOR, le monde XML a été bien exploré. Pourtant, la puissance que possède XQuery 1.0 semble loin d'atteindre la plus haute satisfaction, étant donné que ce dernier manque de propriétés intéressantes dont une de celles-ci est la fonctionnalité fenêtrage. En conséquence, ceci amène à l'objectif principal de ce mémoire. Plus précisément, nous allons y étudier soigneusement la notion de fenêtrage pour nalement l'implémenter dans une base de données XML native, à savoir exist, un logiciel Open Source. 1.2 Structure du mémoire Le deuxième chapitre est une brève présentation de XML, un langage de balisage dont la structure est exprimée conceptuellement sous forme hiérarchique. Une représentation textuelle de XML est également discutée. Ceci nous permet d'introduire les diérents langages de schéma dont le rôle est d'assurer la structure bien-formée d'un document XML. Nous abordons par la suite une introduction de XQuery, dans le troisième chapitre. Ainsi, la syntaxe de XPath est étudiée, ce qui dénit sa relation avec XQuery. Ce chapitre ore également une occasion favorable d'envisager l'expression de base de XQuery, à 1

8 savoir FLWOR. Finalement, une succincte discussion portant sur le groupement, une propriété importante qui est absente en XQuery 1.0, est également présentée. Le sujet principal du mémoire est entamé dans le quatrième chapitre. Pour obtenir une vue élargie du fenêtrage, cette notion est étudiée tant dans le monde SQL que XQuery. A propos de XQuery, la syntaxe de la clause de fenêtrage, y compris ses deux principaux types de fenêtres, à savoir fenêtre disjointe et fenêtre glissante, est explorée méticuleusement dans ce chapitre. Dès lors, une comparaison entre les deux langages, SQL et XQuery, est réalisée pratiquement dans le cinquième chapitre. Une série de quatre requêtes mentionnées successivement dans ce chapitre nous montre que la transformation de SQL à XQuery et inversement n'est pas évidente. Dans le chapitre suivant, après une introduction sur les bases de données XML natives, une discussion détaillée sur exist est entreprise. Grâce à l'étude portant sur son indexation et son stockage, nous donnons un point de vue explicite sur le déroulement d'une requête XQuery dans exist. La combinaison du quatrième et du sixième chapitres, nous fournit une connaissance susante pour procéder à une intégration de la notion de fenêtrage dans exist, ce qui est présenté dans ce septième chapitre. Une brève discussion sur la phase sémantique et d'analyse de l'arbre syntaxique est abordée avant d'entamer la réalisation des classes de travail. Pour terminer, un scénario portant sur deux types de fenêtres, fenêtre disjointe et fenêtre glissante, est également introduit. Un banc d'essai est réalisé dans le huitième chapitre en supposant diérents modèles à étudier. Ceci nous permet d'obtenir des résultats expérimentaux sur la nouvelle fonctionnalité implémentée dans exist, à savoir le fenêtrage. Une conclusion est introduite dans le dernier chapitre. Celle-ci inclut quelques opinions personnelles sur l'achèvement du mémoire. Ainsi, des perspectives futures sont également explorées dans celui-ci. 1.3 Contributions du mémoire Voici la liste qui présente nos principales contributions : 1. Une série de requêtes de comparaison entre deux langages de requête, à savoir SQL et XQuery, est présentée au chapitre La réalisation de l'implémentation de la clause de fenêtrage dans la base de données exist est détaillée au chapitre Un banc d'essai est entrepris sur divers modèles, pour tester le fonctionnement du système après avoir intégré le fenêtrage dans exist. Ceci est abordé au chapitre 8. 2

9 Chapitre 2 XML 2.1 Introduction XML, l'acronyme de Extensible Markup Language, est eectivement une notation standard pour les langages de balisage. Par rapport à HTML (Hyper-Text Markup Language), il n'existe aucune limitation sur l'ensemble de balises utilisées dans XML. Plus précisément, XML ore la possibilité de dénir nos propres balises en faveur des types d'information que nous représentons. Chaque langage XML est spécique à un domaine particulier, pourtant ils partagent la même syntaxe de balisage de base, et ils bénécient en plus d'un ensemble commun d'outils génériques pour le traitement des documents. En général, XML est destiné à devenir l'avenir de toutes les informations structurées, voire les informations stockées dans des bases de données relationnelles. Ce qui a incité le développement d'un langage de requête puissant, à savoir XQuery qui sera détaillé au chapitre 3. Le développement de XML a commencé au milieu des années 90, et en novembre 1996, son ébauche initiale a été réalisée en tant que sous-ensemble de SGML (Standard Generalized Markup Language) [4]. Il s'agit en eet d'une simplication de SGML. XML a été conçu an d'amener la puissance de SGML au domaine web. Ainsi, en février 2004, les spécications XML 1.1 sont devenues une recommandation de World Wide Web Consortium (W3C). La section suivante, inspirée de [39], décrit la représentation d'un document XML ainsi que les langages de schéma permettant de vérier la bonne syntaxe du document XML. 2.2 Document XML Conceptuellement, un document XML est une structure hiérarchique représentée sous forme arborescente qui consiste en divers types de n uds. Un arbre XML est ordonné, ce qui signie que l'ordre établi entre les n uds est signicatif. La structure de l'arbre permet de dénir les relations entre les n uds (voir gure 2.1). Elle est analogue à la 3

10 A Le père de D A Les fils ou le contenu de A A Les frères de C B C D B C D B C D E F E F E F A Les descendants de A A Les ancêtres de F B C D B C D E F E F Figure 2.1 Types de relations entre les n uds dans un arbre XML [39]. représentation d'un système de chiers, qui est également une structure arborescente, mais non ordonnée cette fois. En eet, la racine du système de chiers est également celle du document XML. Ainsi, les chiers apparaissent comme les feuilles de l'arbre XML et les répertoires correspondent aux n uds possédants des enfants. Dans un arbre XML, nous pouvons retrouver les diérents types de n uds tels que dénis ci-dessous 1 : Les textes : ils correspondent à une partie de l'information représentée par le document XML. Chaque n ud de type texte est étiqueté avec une chaîne de caractères non vide contenant l'information. Ces n uds n'acceptent pas d'enfants, ils sont eectivement les feuilles de l'arbre. Les éléments : un élément dénit un regroupement logique de l'information représentée par ses descendants. Chaque élément possède un nom, un mot décrit le regroupement. Les attributs : un attribut est associé à un n ud d'élément. Typiquement, les attributs représentent une subtilité du nom de l'élément qui en décrivent les propriétés. Plus précisément, un attribut est un couple (nom, valeur) où le nom décrit la propriété et la valeur représente une chaîne de caractères. Chaque élément ne peut posséder qu'au plus un seul attribut avec un nom donné. Les commentaires : il s'agit de feuilles spéciales étiquetées avec une chaine de caractères. Plus précisément, elles contiennent des informations informelles que nous pouvons ignorer. De manière analogue à HTML, les commentaires XML commencent par un <!-- et se terminent par un -->. La racine : chaque arbre XML commence par une seule racine qui se trouve en tête 1. en se référant au modèle de données XPath. 4

11 de l'arbre Représentation textuelle d'un document XML Indépendamment du modèle de données utilisé, la représentation textuelle d'un document XML reste la même. Chaque élément est dénoté par des balisages, par exemple : <product dept="wmn"> Le contenu du produit </product> Où <product> est une balise ouvrante dont le nom est product, et </product> est une balise fermante correspondante. Le texte se trouvant au milieu est susceptible de contenir le balisage. Il s'agit donc du contenu de l'élément correspondant aux descendants de celuici. Les attributs sont écrits à l'intérieur de la balise ouvrante. Dans ce cas, l'élément en question possède un seul attribut dont le nom est dept associé à une valeur WMN. Il est à noter que contrairement à l'ordre des n uds dans un arbre XML, l'ordre des attributs au sein de la balise ouvrante n'est pas signicatif. Un élément est vide s'il n'a pas de contenu. Un tel élément peut être décrit par <product></product> ou encore <product/> en forme abrégée. Un document XML commence généralement avec un élément de déclaration XML qui précède l'élément racine : <?xml version="1.0" encoding="utf-8"?> Où la partie version indique la version XML en cours d'utilisation. La partie encoding représente la déclaration d'encodage dans laquelle est construit le document. Un exemple complet illustré de ces notions est donné ci-dessous. Il s'agit d'un exemple de base de données extrait du cours Systèmes distribués d'information donné par le professeur Esteban Zimányi [53] : <?xml version="1.0" encoding="utf-8"?> <catalog> <product dept="wmn"> <number>557</number> <name language="en">fleece Pullover</name> <colorchoices>navy black</colorchoices> </product> <product dept="acc"> <number>563</number> <name language="en">floppy Sun Hat</name> </product> 5

12 ... </catalog> <!-- Voici des commentaires XML --> Un document XML dans sa forme textuelle doit être bien-formé (well-formed). Ce qui veut dire qu'il doit dénir une structure arborescente telle qu'elle a été décrite précédemment. Dans ce cas, une balise ouvrante doit toujours être terminée par une balise fermante correspondante, de manière à ce que l'imbrication soit introduite correctement 2. Contrairement à HTML, XML est sensible à la caisse, ce qui signie qu'un document XML ne serait pas bien-formé si la balise ouvrante et la balise fermante correspondante dièrent, suite à l'emploi de lettres majuscules et minuscules. Ainsi, un document bienformé doit avoir un élément racine. Une syntaxe plus subtile pour vérier la propriété bien-formée d'un document XML est représentée dans DTD (Document Type Denition) ou Schéma XML. Celles-ci seront abordées dans la section suivante Langages de schéma Un schéma est une dénition formelle pour déterminer la syntaxe d'une famille de documents XML. Un langage de schéma est un langage formel pour exprimer des schémas. Il est à noter qu'il en existe une variété, en particulier le DTD et le schéma XML. Chaque langage de schéma est implémenté sous la forme d'un processeur de schéma. Il s'agit en eet d'outils qui prennent en input un document XML X, appelé l'instance de document et un schéma S, écrit dans un langage de schéma particulier. Ensuite, ils vérient si le document X est syntaxiquement correcte selon S. Dans le cas où la réponse est positive, X est valide conformément à S. Dans le cas contraire, la plupart des processeurs de schéma renverront un message d'erreur. Il est possible, qu'après la vérication du processeur de schéma qui détermine que X se conforme en eet à S, il pourrait normaliser X selon des règles spéciées par S, ce qui est illustré à la gure 2.2. Il est à noter qu'en fonction du choix de chaque langage de schéma, la normalisation peut impliquer l'insertion des attributs et des éléments par défaut, la suppression des espaces blancs non signicatifs, et l'addition des informations. DTD Le DTD est conçu comme un sous-ensemble du formalisme DTD de SGML. Il s'agit en eet d'un langage de schéma intégré de XML 1.0. Ce dernier spécie une puissance expressive assez limitée. Pourtant il permet de fournir un point de départ pour le développement d'autres langages de schéma plus expressifs. Nous ne détaillerons pas la 2. Il est à noter que ceci est contraire à HTML qui lui accepte l'absence de certaines balises, en particulier, des balises fermantes. 6

13 L instance de document X Schéma S Processeur de schéma L instance de document normalisée Messages d erreur Figure 2.2 Schéma de traitement [39]. description de DTD, en revanche, nous citerons quelques limitations remarquables de ce dernier : DTD ne peut pas utiliser lui-même la syntaxe de XML. DTD ne supporte pas les namespaces, puisque que ce dernier a été introduit avant le mécanisme namespace. DTD ne supporte pas les datatypes pour des données de caractères et des valeurs d'attribut. Schéma XML Après DTD, le W3C a décidé de développer une prochaine génération de langage de schéma pour remédier aux problèmes existants avec DTD, en introduisant la notion de types, à savoir le schéma XML. Il s'agit d'un langage plus expressif que DTD qui peut utiliser la syntaxe de XML. En plus, ce langage de schéma supporte les namespaces et les datatypes. Pourtant il n'est pas simple à utiliser. N'étant pas complètement autodescriptif, il n'est donc pas possible de décrire la syntaxe de schéma XML dans le langage de schéma XML lui-même. Des limitations existent dans ce langage [39]. 2.3 Conclusion Dans ce chapitre, nous avons passé en revue la représentation conceptuelle de la structure hiérarchique ainsi que celle textuelle du document XML. Un concept central, à savoir la propriété bien-formée d'un document XML, a également été abordée. Ceci amène la néccessité des langages de schéma tels que DTD et Shéma XML pour en justier la validité. En outre, une propriété intéressante qu'ore XML est la possibilité de stocker 7

14 des informations de manière structurée, qui mène au développement d'un langage de requête puissant que nous étudierons au chapitre suivant : XQuery, à savoir qu'il joue un rôle principal dans l'étude du mémoire. 8

15 Chapitre 3 XQuery 3.1 Introduction XML étant reconnu comme un format standard pour le stockage et l'échange de données, il nécessite un langage pour être interrogé. Ce langage doit être bien adapté, pour exprimer des requêtes qui permettent d'eectuer la recherche et la navigation au travers de multiples niveaux d'éléments XML. XQuery [50, 15, 25] étant un langage de programmation fonctionnelle, spécié par le W3C, apparaît comme un bon candidat pour satisfaire les besoins décrits ci-dessus. Il permet non seulement d'extraire des informations d'un document XML, ou d'une collection de documents XML, mais également d'eectuer des calculs complexes à partir d'informations extraites et de reconstruire de nouveaux documents ou fragments XML. Le développement de XQuery poursuit un certain nombre de projets de recherche indépendants. Chacun d'eux a procédé à des tentatives, an de résoudre le problème fondamental de généralisation SQL [10] avec des arbres XML. Par conséquent, XQuery joue, par rapport aux données XML, un rôle similaire à celui du langage SQL 1. Il existe des analogies entre ces deux langages. 3.2 XPath L'accroissement de diérentes technologies XML a spécié un besoin commun de notation exible pour la sélection et la navigation des documents XML. Ce qui donne naissance au langage XPath, qui a été recommandé par le W3C en novembre 1999 [21]. XPath s'est développé en premier, en tant que simple langage, à savoir XPath 1.0 [12]. Postérieurement, à cause de son interaction avec le développement du langage XQuery, il a évolué vers un langage plus étendu, à savoir XPath 2.0 [18]. Cette section se réfère à 1. qui lui travaille avec des données relationnelles. 9

16 [39] Chemin de localisation En XPath, un chemin de localisation est évalué à une séquence de n uds d'un arbre XML donné. La séquence résultante sera triée dans l'ordre du document et ne contient jamais de n uds identiques. Plus précisément, un chemin de localisation est semblable aux expressions utilisées pour indiquer les noms de chiers, dans de nombreux systèmes d'exploitation. Il s'agit d'une série d'étapes de localisation, séparées par des barres obliques, dont chacune se compose d'un axe, d'un test de n ud, et de zéro à plusieurs prédicats 2 : axe :: testnoeud [exp1] [exp2]... Voici un exemple illustre d'un chemin de localisation : Étape de localisa-on Étape de localisa-on Étape de localisa-on descendant :: C / child :: E[a1ribute : : id] / child :: F child :: E [a1ribute : : id] axe testnœud prédicat Une étape de localisation se commence à un n ud de contexte et est évaluée ensuite à une séquence de n uds. En principe, nous procédons en général, par une transformation d'une séquence de n uds vers une nouvelle séquence de n uds, en remplaçant chaque n ud de la première séquence, qui sert, comme étant un n ud de contexte, par le résultat de l'évaluation de cette étape. Dès lors, le comportement d'un chemin de localisation sera facilement déni en combinant les comportements de chaque étape qu'il contient. Une illustration est montrée à la gure 3.1 en prenant le chemin de localisation descendant :: C/child :: E/child :: F [39]. Axes Un axe est une séquence de n uds situés par rapport au n ud de contexte. Il fournit en eet une première approximation de la séquence résultante pour une étape de localisation. XPath supporte douze axes diérents que représente le tableau ci-dessous : 2. qui sont des expressions XPath. 10

17 nœud de contexte nœud résultant A A A B B B B B B C C D C C D C C D E F C E E F C E E F C E F F F E E F F F F E E F F F F E E F F F F descendant :: C descendant :: C/child :: E descendant :: C/child :: E/child :: F Figure 3.1 L'évaluation d'un chemin de localisation [39]. child descendant parent ancestor following-sibling preceding-sibling following preceding attribute self descendant-or-self ancestor-or-self Les enfants du n ud de contexte dont les n uds d'attribut ne sont pas compris. Les descendants du n ud de contexte qui ne contiennent pas les n uds d'attribut. Le seul n ud père du n ud de contexte. Il sera la séquence vide dans le cas où le n ud de contexte est un n ud racine. Tous les ancêtres du n ud de contexte, à partir de son père jusqu'à la racine. Les frères se trouvant au côté droit du n ud de contexte, ou la séquence vide pour les n uds d'attribut. Les frères se trouvant au côté gauche du n ud de contexte, ou la séquence vide pour les n uds d'attribut. Tous les n uds apparaissent strictement et postérieurement par rapport au n ud de contexte dans le document, à l'exclusion des descendants. Tous les n uds apparaissent strictement et antérieurement par rapport au n ud de contexte dans le document, à l'exclusion des ancêtres. Les attributs du n ud de contexte. Le n ud de contexte lui-même. La concaténation de la séquence self et celle de descendant. La concaténation de la séquence self et celle de ancestor. 11

18 nœud de contexte nœud résultant A A A B B B B B B C C D C C D C C D E F C E E F C E E F C E F F F E E F F F F E E F F F F E E F descendant F ancestor F following- sibling F A A A B B B B B B C C D C C D C C D E F C E E F C E E F C E F F F E E F F F F E E F F F F E E F F preceding- sibling following preceding F F Figure 3.2 Illustration de certains axes. Les axes principaux sont illustrés à la gure 3.2. Chaque axe possède une direction qui détermine l'ordre dans lequel sont positionnés les n uds dans la séquence. Un axe forward renvoie les n uds dans l'ordre du document, alors qu'un axe backward utilise l'ordre inverse. Plus précisément, les axes forward sont child, descendant, following-sibling, following, self, et descendant-or-self ; les axes backward sont parent, ancestor, preceding-sibling, et preceding. Pour l'axe attribute, l'ordre dépend malheureusement de l'implémentation. Pourtant il doit être stable, ce qui signie que l'implémentation doit toujours utiliser le même ordre pour un input donné. Il est à noter qu'étant donné un n ud de contexte quelconque, les axes self, ancestor, descendant, preceding, et following constituent une partition disjointe des n uds dans un arbre XML. 12

19 Prédicat La dernière partie d'une étape de localisation consiste en : de zéro à plusieurs prédicats. Il s'agit des expressions XPath de divers types qui sont évaluées en tant que conditions booléennes tels que : Un nombre correspondra à vrai, si sa valeur est égale à la position du contexte courant. Un string correspondra à vrai, s'il n'est pas de longueur nulle. Une séquence correspondra à vrai, si elle n'est pas de longueur nulle. Chaque expression sera évaluée à une séquence d'éléments qui sont soit des valeurs atomiques 3 soit des n uds. Les expressions de diérents types peuvent être combinées en tant que booléens, en utilisant des opérateurs tels que : and, or et la fonction not. Les prédicats permettent de ltrer les éléments ou les attributs qui ne satisfont pas à un certain critère. Un exemple de chemin de localisation est donné comme suit, en prenant la base de données citée à la section Ceci permet de sélectionner les produits pour lesquels leur valeur d'attribut dept est ACC : /descendant::catalog/descendant::product [attribute :: dept = "ACC"] (I) Pour renvoyer la position du contexte courant, la fonction position () est à notre disposition. Par exemple, le deuxième élément product est facilement trouvé via ce chemin de localisation : descendant::catalog/descendant::product [position () = 2](II) Abréviation En s'étant inspiré par des expressions de chemin pour les systèmes de chiers Unix, XPath fournit un certain nombre d'abréviations qui rendent les chemins de localisation plus facile à écrire : Manipuler les attributs en utilisant le Indiquer n'importe quel nom de l'élément avec *. Retour des éléments qui apparaissent n'importe où dans le document à partir d'un certain n ud avec //. Dès lors, (I) et (II) peuvent être réécrit sous leur forme abrégée comme suit : (I) /catalog/product[@dept = "ACC"] 3. une valeur atomique peut être un nombre, un booléen, une chaine de caractères Unicode, ou des datatypes. 13

20 (II) /catalog/product[2] Relation entre XPath et XQuery Le langage XQuery 1.0 est conçu pour devenir un sur-ensemble strict du langage XPath 2.0. Autrement dit, chaque expression XPath 2.0 est directement une expression XQuery 1.0. La seule diérence dont a besoin XQuery est la possibilité de rassembler des informations à partir de diérentes sources et de générer de nouveaux fragments XML. Ainsi, XQuery introduit des fonctions dénies par l'utilisateur (user-dened) qui permettent donc des calculs arbitraires. En revanche, XPath permet des fonctions dénies par l'implémentation (implementation-dened), où les implémentations spéciques peuvent étendre les fonctions de librairies. 3.3 FLWOR L'expression FLWOR est une structure de base de nombreuse requêtes XQuery. Elle est une puissante expression permettant de restructurer et ainsi de joindre des informations. Avec de nombreuses fonctionnalités, l'expression FLOWR fonctionne de manière analogue avec des clauses de SQL. Une version de syntaxe simpliée de l'expression FL- WOR dans la spécication de XQuery [14] est illustrée par la suite : FLWORExpr ::= (ForClause LetClause)+ WhereClause? OrderByClause? ReturnClause Elle consiste principalement en cinq clauses : ForClause, LetClause, WhereClause, OrderbyClause, ReturnClause dont chacune est détaillée par la suite : ForClause : elle met en place une itération en l'associant à une variable de travail, permettant d'évaluer plusieurs fois le reste de l'expression FLWOR. Donc une fois pour chaque élément qui se trouve dans la séquence 4 retournée par l'expression se situant après le mot-clé in. Remarquons que la séquence retournée peut contenir de zéro à plusieurs éléments. Si elle est vide, le reste de FLWOR ne sera pas évalué. Exemple : itérons sur l'ensemble des éléments employee se trouvant dans le document example.xml en utilisant la variable de travail e : for $e in doc("example.xml")//employee LetClause : elle permet d'assigner une variable à une valeur ou à une séquence en utilisant := Exemple : assignons la nouvelles variable DNo au numéro du département pour chaque employé : 4. Il s'agit d'une liste triée dont chaque élément représente soit un n ud, soit une valeur atomique. 14

21 let $DNo := $e/dno WhereClause : elle est similaire à la clause where de SQL ayant pour but de ltrer les résultats des clauses précédentes en respectant certaines conditions. Grâce à la clause where, il est possible d'écrire des jointures internes ou externes. Exemple : choisissons les employés dont le numéro du département est soit 5 soit 4 : where $DNo = 5 or $DNo = 4 OrderbyClause : par défaut, les résultats de FLWOR sont basés sur l'ordre de la séquence fournie par la clause For. An de pourvoir préciser un ordre particulier, OrderbyClause est utilisée pour trier des données dans un ordre autre que l'ordre du document. Exemple : trions les employés dans l'ordre ascendant de leurs salaires : order by $e/salary ReturnClause : à chaque itération, elle retourne des éléments de résultat. En plus, elle ore la possibilité d'en construire des nouveaux. Exemple : construisons de nouveaux éléments représentants des employés du département 5 et 4. Chaque élément possède un attribut indiquant le prénom de l'employé et contient également le salaire de cet employé : return element emp{ } attribute name {data($e/fname)}, $e/salary Voici un exemple complet de l'expression FLWOR qui renvoie le prénom ainsi que le salaire de chaque employé du département 5 et 4. Le résultat est trié par l'ordre croissant de salaire de l'employé : for $e in doc("example.xml")//employee let $DNo := $e/dno where $DNo = 5 or $DNo = 4 order by $e/salary return element emp{ attribute name {data($e/fname)}, $e/salary } Et le résultat obtenu correspondant : 15

22 <emp name="alicia"> <Salary> </Salary> </emp> <emp name="joyce"> <Salary> </Salary> </emp> <emp name="ahmad"> <Salary> </Salary> </emp> <emp name="john"> <Salary> </Salary> </emp> <emp name="ramesh"> <Salary> </Salary> </emp> <emp name="franklin"> <Salary> </Salary> </emp> <emp name="jennifer"> <Salary> </Salary> </emp> 3.4 XQuery 1.1 Jusqu'à présent, nous avons introduit XQuery, ses expressions FLWOR ainsi que les exemples d'illustrations nous permettant de comprendre plus concrètement ce langage de requête. Manifestement, XQuery est construit en ayant pour objectif de remplacer le rôle de SQL visà-vis du monde XML. Pourtant, il existe des faiblesses du côté de XQuery version 1.0. Celui-ci n'inclut pas la possibilité d'eectuer les requêtes concernant le regroupement, le classement, l'agrégation sur les fenêtres déplaçables et les comparaisons entre les diérents niveaux de partitions. XQuery 1.1 a comblé ces inconvénients. Dans XQuery version 1.1, le groupement et la fonction de fenêtrage (window function) y sont rajoutés. Cette dernière ore la possibilité de découper une séquence d'entrée selon des conditions booléennes que nous discuterons plus en détail au chapitre Groupement Comme précédemment, la diérence entre SQL et XQuery 1.0 est que ce dernier et ses versions antérieures ne supportent pas le groupement. L'absence de la construction du groupement rend les requêtes d'analyse diciles à exprimer et à exécuter ecacement. 16

23 Considérons une base de données contenant une table appelée WorksOn qui consiste en trois champs : ESSN : représente le numéro identiant un employé. PNo : le numéro du projet pour lequel un employé travaille. Hours : le temps de travail qu'un employé a consacré pour un projet particulier. Prenons ensuite la requête suivante : Déterminer pour chaque employé, le nombre total d'heures qu'il a travaillé. Cette requête exprimée sous la version SQL est illustrée par la suite : select w.essn, sum(w.hours) as Htotal from WorksOn w group by w.essn order by w.essn A l'opposé de SQL, XQuery 1.0 l'exprime comme ci-dessous : for $ssn in distinct-values(doc("example.xml")//workson/essn) let $w := doc("example.xml")//workson[essn = $ssn] order by $ssn return <group> {$w[1]/essn} <HTotal>{sum($w/hours)}</HTotal> </group> Il est évident que la version de XQuery est de taille plus longue et d'une complexité plus importante que celle de SQL. Examinons ensuite un exemple pris de [14] de manière plus détaillée Problèmes du groupement Cet exemple se base sur un document de bibliographie contenant plusieurs livres. Un livre peut avoir zéro ou plusieurs auteurs et zéro ou un éditeur. Sa structure peut être représentée comme ci-dessous : <book> <title>transaction Processing</title> <author>jim Gray</author> <author>andreas Reuter</author> <publisher>morgan Kaufmann</publisher> 17

24 <year>1993</year> <price>59.00</price> <discount>6.00</discount> </book> Requête :Trouver le prix net moyen de livres selon leur éditeur et leur année. Si nous exprimons cette requête en utilisant la syntaxe courante de XQuery (version 1.0), cela donne comme suit : for $p in distinct-values(//book/publisher), $y in distinct-values(//book/year) let $netprices := //book[publisher = $p and year = $y]/ where fn:exists($netprices) order by $p, $y return <group> <publisher>{$p}</publisher> <year>{$y}</year> (price - discount) <avg-net-price>{avg($netprices)}</avg-net-price> </group> Cette expression consiste tout d'abord à chercher les éditeurs distincts ainsi que les années distinctes ; à trouver ensuite les groupes de livres correspondants à chaque couple de valeurs (éditeur, année) et à calculer nalement le prix net moyen de chaque groupe non-vide de livres. Nous pouvons voir par cette méthode qu'il s'agit de problèmes diérents. L'exécution de cette requête serait inecace parce qu'elle impliquerait de nombreux passages sur l'ensemble des livres, ce qui rend coûteux et oblige d'eectuer des navigations redondantes ainsi que des auto-jointures (self-join). Un autre problème est la possibilité d'avoir des lignes manquantes dans le cas où un livre ne possède aucun éditeur. Ceci est la conséquence du fait, qu'un élément éditeur non-existant, ne sera pas représenté dans la séquence produite par l'expression //book/publisher dans la première clause. Par conséquent, cela nécessite une amélioration pour XQuery 1.0 au niveau du groupement. Plus précisément il faudra déterminer une clause group by permettant d'accomplir cette mission, ce qui est représenté dans la section Syntaxe du groupement Dans ce qui est proposé par l'article [14], la clause de groupement peut être dénie au sein d'une expression FLWOR sans nécessiter un grand changement dans le modèle courant de XQuery 1.0. Il propose d'étendre la syntaxe FLWOR, par l'introduction d'une 18

25 clause group by qui suit la clause courante where. Dans le cas où la clause group by est présente, elle peut être suivie à son tour par une clause let et ensuite par une clause where. La syntaxe est décrite ci-dessous : FLWORExpr ::= (ForClause LetClause)+ WhereClause? (GroupByClause LetClause* WhereClause?)? OrderByClause? ReturnClause En utilisant cette nouvelle syntaxe de FLWOR, nous pouvons exprimer la première requête dans la section comme suit : for $b in //book group by $b/publisher, $b/year let $netprices := $b/price - $b/discount return <group> {$b/publisher, $b/year} <avg-net-price>{avg($netprices)}</avg-net-price> </group> Dans cette requête, la séquence générée par la clause group by est utilisée par après par la clause return an de l'appliquer à la fonction d'agrégation. Cette fois, il sut d'utiliser le mot-clé group by, an de grouper les livres selon leur éditeur et leur année de publication et de générer par la suite une nouvelles variable $netprices. Celle-ci est associée à une séquence de valeurs atomiques représentant le prix des livres, pour lesquels l'éditeur et l'année sont les mêmes. Parce qu'une séquence vide peut être considérée comme un élément distinct dans la syntaxe du groupement, les livres sans éditeur apparaissent eectivement dans le résultat nal de la requête. 3.5 Conclusion Dans ce chapitre, nous avons examiné XQuery en détail, ce qui nous permet de constater sa relation avec XPath, un langage permettant de naviguer au travers de documents XML. En outre, l'expression fameuse FLWOR de XQuery a également été abordée. Les points de faiblesse qui apparaissent dans XQuery 1.0 ont donné naissance à sa version 1.1. Une première extension du langage XQuery, à savoir la syntaxe de la clause de groupement, a été étudiée. Cette syntaxe est inspirée en général de celle dénie en SQL. Constatons qu'elle permet non seulement de simplier l'écriture des requêtes pour le groupement, mais également d'améliorer leur complexité. Par la suite, nous envisagerons une deuxième extension pour XQuery qui permettra de renforcer la puissance de ce langage dans le monde de base de données XML, à savoir le fenêtrage. 19

26 Chapitre 4 Le fenêtrage 4.1 Introduction Nous abordons dans ce chapitre le sujet principal du mémoire, le fenêtrage, une fonctionnalité intéressante dont disposent des langages de requête tels que SQL et XQuery. Cet aspect existant déjà dans le monde SQL, il reste encore tout nouveau dans le domaine XQuery. Nous allons donc l'étudier en détail tout au long de la suite de ce mémoire. Dans ce chapitre, pour avoir une vue globale de la notion de fenêtrage, la section 4.2 va la représenter dans le monde SQL en se basant sur [23], et, la section 4.3 dans le monde XQuery en se référant à [17, 49]. Ceci ore également l'occasion de comparer cette fonctionnalité dans deux mondes de requêtes diérents. 4.2 Extension de SQL avec les fonctions de fenêtrage Les fonctions de fenêtrage en SQL [27] (window functions) orent la possibilité de voir les diérents niveaux d'agrégation en une même ligne de résultat. Elles facilitent des calculs tels que la somme cumulative 1, la moyenne mobile 2, et de nombreux autres calculs. Les fonctions de fenêtrage sont prises en charge dans Oracle [26] (où elles sont connues en tant que fonctions analytiques), DB2 [35] (où elles sont appelées fonctions OLAP 3 ), et elles sont partiellement prises en charge dans SQL Server 2005 [43]. Le rôle déterminant de la fonction de fenêtrage est de spécier une fenêtre qui est une partition de lignes, sur laquelle les fonctions d'agrégations vont s'appliquer. Elles calculent en fait, une valeur de résultat pour chaque ligne, en prenant en compte les 1. où la somme est calculée de manière cumulative pour chaque ligne appartenant à la partition de lignes considérée, autrement dit à la fenêtre considérée. 2. où la moyenne est calculée au travers de diérentes fenêtres, à savoir des partitions de lignes. 3. Online Analytical Processing [40] désignait à l'origine les bases de données multidimensionnelles, appelées également cubes ou hypercubes, destinées à des analyses complexes de données. 20

27 valeurs de la partition de lignes, dont la taille est déterminée (voir section 4.2.2). La clause de fenêtrage en SQL se base principalement sur : la clause PARTITION BY (partition clause), la clause ORDER BY (order clause), et la clause cadres de fenêtrage (frame clause). Ces clauses sont illustrées comme telles : Func/on(arg) OVER ( par//on- clause order- clause frame- clause ) Nous allons, par la suite, étudier les deux clauses PARTITION BY et cadres de fenêtrage Clause PARTITION BY En SQL 2003 [23], la clause PARTITION BY permet de fractionner des lignes en différents groupes. En général, elle ressemble à la clause GROUP BY que nous avons vue précédemment, sauf que dans ce cas, toutes les lignes sont susceptibles d'être maintenues, ce qui nous permet d'inclure plus de données dans le résultat nal (voir gure 4.1). Dans le cas où la clause PARTITION BY n'est pas spéciée, alors il y aura une seule partition contenant la table toute entière. Exemple avec PARTITION BY : SELECT empnum, dept, salary, AVG(salary) OVER (PARTITION BY dept) as dept_avg FROM emptab Exemple avec GROUP BY : SELECT dept, AVG(salary) as dept_avg FROM emptab GROUP BY dept Les résultats obtenus à la gure 4.1 illustrent la diérence entre PARTITION BY et GROUP BY. La clause PARTITION BY à l'intérieur de OVER partitionne des lignes en groupes qui partagent la même valeur dept. La fonction AVG, qui calcule la moyenne, est appliquée ensuite sur tous les groupes dont chaque ligne contiendra, par conséquent, la valeur du résultat. La clause GROUP BY quant à elle, ne garde qu'une seule ligne contenant le résultat nal pour chaque groupe. Remarquons qu'une clause OVER, sans indication entre les parenthèses, désigne simplement une fonction d'agrégation qui est utilisée comme une fonction de fenêtrage. 21

28 Figure 4.1 Comparaison entre PARTITION BY et GROUP BY Clause cadres de fenêtrage Nous avons donc maintenant une vue globale de la notion de fenêtrage. Dès lors, nous détaillerons ses propriétés, en particulier la dimension de la fenêtre. Nous savons que chaque ligne de données est groupée en un ensemble que nous appelons fenêtre, sur laquelle peuvent s'appliquer les fonctions d'agrégation, an de calculer des attributs supplémentaires. Pour que ces calculs soient réalisables, chaque fenêtre doit posséder une taille nie, ce qui détermine les bords de la fenêtre. Par défaut, les fenêtres dont les bords ne sont pas précisés, sont dénies par toutes les lignes précédentes de la ligne courante, elle-même incluse. Or il existe évidemment des cas où nous voulons les dénir de manière plus dynamique. D'où la notion de cadres de fenêtrage (window frames). Il permet eectivement d'aner un ensemble de lignes selon les diérents besoins avec une condition, que ORDER BY soit présent. Une présentation de la syntaxe est la suivante [23] : 22

29 frame- clause ROWS RANGE endpoint- spec BETWEEN endpoint- spec AND endpoint- spec UNBOUNDED PRECEDING unsigned- value- spec PRECEDING CURRENT- ROW unsigned- value- spec FOLLOWING UNBOUNDED FOLLOWING Le mot-clé ROWS permet de déterminer la fenêtre en tenant compte de la position des lignes. Exemple 1 : Trouver la moyenne sur les prix d'actions d'ibm durant les trois derniers jours, et ceci pour chaque jour ouvrable. SELECT date, symbol, close_price, AVG(close_price) OVER (ORDER BY date ROWS 2 preceding) as smooth_cp FROM stocktab date symbol close_price smooth_cp 02/08/1999 IBM /08/1999 IBM /08/1999 IBM /08/1999 IBM /08/1999 IBM Valeurs manquantes pour le week-end 09/08/1999 IBM Table 4.1 Résultat de l'exemple 1. Le résultat correspondant est donné au tableau 4.1 ci-dessus. Nous constatons que ROWS permet de donner un résultat valide dans le cas où la base de données est dense. Si il existe des valeurs dupliquées ou des lignes manquantes dans les données, par exemple si l'action n'a pas de données pendant le week-end, alors ceci peut très facilement causer 23

30 date close_price avg_7_rows avg_7_range 02/08/1999 Lundi /08/1999 Mardi /08/1999 Mercredi /08/1999 Jeudi /08/1999 Vendredi /08/1999 Lundi /08/1999 Mardi Table 4.2 Résultat de l'exemple 2. problèmes. Cela permet de nous diriger vers un deuxième choix dont l'idée est d'utiliser des valeurs de données, pour spécier les groupes d'agrégation à la place des positions des lignes. D'où l'option RANGE est introduite. Exemple 2 : Dans le stock d'actions d'ibm, calculer pour chaque jour du mois d'août la moyenne des prix sur les sept derniers jours en les considérant, soit en tant que jours calendrier, soit en tant que jours ouvrables. La requête en SQL de cet exemple est exprimée ci-dessous et son résultat est illustré au tableau 4.2 : SELECT date, substr(dayname(date),1,9), close_price, AVG(close_price) OVER (order by date ROWS 6 preceding) as avg_7_rows, AVG(close_price) OVER (order by date RANGE interval '6' day preceding) FROM stocktab as avg_7_range Pour être convaincu d'une large diérence entre l'utilisation de l'option ROWS et celle de RANGE, examinons par exemple les résultats donnés pour le mardi 10/08 : en utilisant ROWS, la moyenne des prix est calculée en tenant compte des valeurs se situant sur les six dernières lignes à compter de la ligne courante et celle-ci incluse, à savoir du lundi 02/08 au mardi 10/08. Il est évident qu'avec cette méthode, le résultat obtenu ne sera pas satisfaisant, si nous voulons seulement calculer la moyenne pour la semaine précédente. En eet, dans le cas où les données sont manquantes pour le week-end, en regardant les six dernières lignes, ceci nous donne un cadre plus large qu'une semaine. Avec RANGE, contrairement au ROWS, ceci nous permet de nous baser sur les dates auxquelles les prix se publient. Cette fois, la moyenne des prix est calculée en tenant compte des 6 derniers jours par rapport au jour que nous considérons et ce dernier inclus, à savoir du mercredi 04/08 au mardi 10/08. 24

31 Voici un exemple complet illustré de la syntaxe de fenêtrage en SQL. Cet exemple est pris de la formation Business Intelligence avec SQL Server 2005 animée par le professeur Esteban Zimanyi. Il consiste à calculer, pour chaque ligne, la somme cumulative des quantités gurées dans les lignes précédentes de la ligne courante, sachant que la base de données est divisée selon le numéro d'identication de l'employé et que la date est ordonnée. Autrement dit, l'exemple calcule pour chaque employé, la quantité de commandes qu'il a obtenu jusqu'à une date donnée : SELECT EmpId, YearMonth, Qty, SUM(Qty) OVER (PARTITION BY EmpId ORDER BY YearMonth ROWS unbounded preceding) as TotalQty FROM EmpOrders Le résultat correspondant est représenté comme suit : Tri et classement au sein d'une fenêtre Pour établir un ordre au sein d'une partition, nous utilisons la clause ORDER BY. Ainsi, après avoir obtenu des lignes triées, nous pouvons également les classer selon diérentes manières. Nous disposons pour ceci de trois fonctions : 1. ROW_NUMBER() : permet de distribuer un nombre dans l'ordre croissant séquentiel à chaque ligne de la fenêtre. 25

32 2. RANK() : retourne le même résultat que ROW_NUMBER(), sauf pour le cas où il y a deux lignes possédant la même valeur, alors elles vont recevoir le même nombre. RANK() devrait ensuite sauter des valeurs, pour assurer que le rang attribué à une ligne donnée est toujours plus grand de un que le nombre de lignes qui sont classées précédemment. 3. DENSE_RANK() : même chose que RANK() sauf qu'aucun saut ne sera considéré dans le cas d'égalité des valeurs. Il est à noter que la présence d'un tri est évidemment indispensable avant d'eectuer un classement. Exemple : SELECT empnum, dept, salary, FROM emptab ; RANK() OVER (ORDER BY salary desc nulls last) as rank, DENSE_RANK() OVER (ORDER BY salary desc nulls last) as denserank, ROW_NUMBER() OVER (ORDER BY salary desc nulls last) as rownum empnum dept salary rank denserank rownum Table 4.3 Les classements. Le résultat de cet exemple est représenté par le tableau 4.3 ci-dessus. En regardant ceci, nous pouvons constater que la colonne rownum contient pour chaque ligne un nombre naturel croissant séquentiel, sans tenir compte du cas d'égalité des valeurs. Contrairement 26

33 rownum, rank quant à elle, distribue un même nombre aux lignes qui possèdent le même salary. Par exemple, citons le cas pour les employés dont les numéros sont 2, 7, 12 possédant un même salaire 75000, ils sont tous distribués avec un même rang qui est 4. Pour l'employé suivant possédant le numéro 10 dont le salaire est diérent de (55000 dans ce cas), il reçoit un rang de 7. Ceci peut être expliqué par la raison qu'il y a 6 employés déjà classés se trouvant avant lui. La colonne denserank, contrairement à rank, donne un rang de 5 à la place. 4.3 Extension de XQuery avec les fonctions de fenêtrage Introduction Bien que XQuery 1.0 est extrêmement puissant, il lui manque pourtant des fonctionnalités importantes. En particulier, XQuery 1.0 manque de support pour des requêtes de fenêtrage. Ceci peut créer des inconvénients dans les cas où, par exemple, une compagnie de carte de crédit aimerait savoir si une carte de crédit est souvent utilisée ; en particulier au cours d'une semaine par rapport à d'autres semaines. Dès lors, la mise en uvre de cette vérication requiert une requête de fenêtrage. Un autre exemple plus concret [17] est considéré par la suite : Exemple : Dans un blog, trouvons tous les auteurs qui ont postés trois éléments consécutifs dans un ux RSS. L'exemple de l'élément RSS est illustré en XML comme suit : <rss:item>... <rss:author>...</rss:author>... </rss:item> Selon [17], cette requête, en utilisant XQuery 1.0, étant montrée à la gure 4.2, nécessite trois auto-jointures qui sont non seulement fastidieuses, mais aussi diciles à optimiser. Comme nous avons vu à la section précédente, les requêtes de fenêtrage ont été étudiées en détail dans le modèle de SQL. Ce travail, cependant, n'est pas applicable dans le monde XML. La première raison qui semble évidente est que SQL n'est pas approprié pour traiter des données XML. Il ne peut ni lire, ni générer des données XML. Le but ici est par conséquent d'étendre XQuery an de lui permettre également de supporter des requêtes de fenêtrage. Évidemment, ce travail est basé sur plusieurs idées et expériences acquises dans le monde SQL. Néanmoins, il existe des diérences importantes entre ces deux langages. 27

34 for $first at $i in $rssfeed let $second := $rssfeed[$i+1], let $third := $rssfeed[$i+2] where ($first/author eq $second/author) and ($first/author eq $third/author) return $first/author Figure 4.2 Requête exprimée en XQuery 1.0. En eet, il est plus facile d'eectuer l'extension de XQuery, parce qu'il est basé sur des séquences d'éléments qui correspondent idéalement à la représentation des ux de données et des fenêtres. Par conséquent, les extensions proposées s'associent à merveille avec toutes les constructions existantes de XQuery, ainsi que toutes ses techniques d'optimisation. En revanche, l'extension de SQL pour des requêtes de fenêtrage, requiert une extension radicale de la base de données relationnelle, et beaucoup d'eorts dans le monde SQL y ont été consacrés. Par exemple, CQL [9] a déni des opérateurs spéciques pour associer des relations aux ux de données. Pour la mise en uvre, nous pouvons étendre l'expression FLWOR dénie par XQuery 1.0 en y rajoutant la clause de fenêtrage, WindowClause, au même niveau de ForClause et LetClause [49]. Dans cette extension, l'expression FLWOR peut avoir également des clauses optionnelles telles que WhereClause, OrderByClause, GroupByClause, CountClause et nalement une clause ReturnClause obligatoire tout en respectant l'expression FL- WOR original. Ainsi, la nouvelle clause WindowClause peut être composée avec d'autres clauses telles que ForClause, LetClause. Voici la syntaxe de FLWOR en tenant compte de la nouvelle extension publiée sur le site de W3C en 2007 [49] : FLWORExpr ::= InitialClause IntermediateClause* ReturnClause InitialClause ::= ForClause LetClause WindowClause IntermediateClause ::= InitialClause WhereClause GroupByClause OrderByClause CountClause Dès lors, l'exemple du ux RSS précédent, peut être exprimé en utilisant cette nouvelle syntaxe de fenêtrage, ceci est illustré à la gure 4.3. Le blog cette fois est divisé en des sous-séquences diérentes de messages de même auteur. Autrement dit, les fenêtres qui peuvent être appliquées par la suite, par la fonction d'agrégation count. Celle-ci 28

35 for tumbling window $w in $rssfeed start $first next $second when $first/author eq $second/author end $last next $lookahead when $last/author ne $lookahead/author where count($w) eq 3 return $w[1]/author Figure 4.3 Requête exprimée en XQuery 1.1. permettant de compter le nombre d'éléments contenus dans une fenêtre. Les bords de chaque fenêtre sont déterminés par les expressions booléennes spéciées après le mot-clé when, se trouvant dans la partie pour déterminer le début et également dans celle pour dénir la n d'une fenêtre. A partir de l'exemple, nous pouvons remarquer que dans le cas de la clause de fenêtrage de XQuery 1.1, il existe également une boucle avec for comme celui de ForClause, an d'associer une variable à une séquence d'éléments. La distinction entre celles-ci est que ForClause associe la variable à un élément de la séquence d'entrée an de l'itérer à chaque tour, alors que la clause de fenêtrage utilise la boucle avec for pour associer la variable à une sous-séquence (fenêtre) de la séquence d'entrée. Par exemple avec la requête à la gure 4.3, en nal, la variable $w sera associée aux séquences de messages consécutifs postés par un même auteur. Le premier élément de la fenêtre est déterminé lorsqu'il partage le même auteur avec le prochain élément. En revanche, le dernier élément est déni une fois que son auteur n'est plus le même que celui de l'élément suivant. Après avoir précisé la condition dans WhereClause, qui permet de ltrer des fenêtres contenant trois éléments, nous pouvons alors trouver les auteurs ayant postés trois éléments consécutifs. Remarquons que la variable de travail de la clause de fenêtrage, par exemple $w de l'exemple, peut être utilisée non seulement au sein de la clause elle-même mais également dans les clauses suivantes. Selon SQL, les fenêtres sont susceptibles de diviser en trois types [17] : les fenêtres disjointes (tumbling window), les fenêtres glissantes (sliding window), et les fenêtres glissantes sans contraintes (landmark window). XQuery 1.1 est alors construit en considérant également ces diérents types de fenêtres. Plus précisément, ces derniers permettent de dénir la façon dont les fenêtres se chevauchent : 1. Fenêtre disjointe : les diérentes fenêtres ne se chevauchent pas. 2. Fenêtre glissante : les diérentes fenêtres peuvent se chevaucher, à l'exception du premier élément. 3. Fenêtre glissante sans contraintes : les diérentes fenêtres peuvent se chevaucher 29

36 de n'importe quelle manière. Il est pourtant à remarquer que XQuery 1.1 déni par W3C ne supporte que les deux premiers types de fenêtres : fenêtre disjointe et fenêtre glissante. Ces diérents types de fenêtres sont illustrés par un exemple donné à la gure 4.4. En regardant cet exemple, nous avons une séquence d'entrée de sept éléments qui va être appliquée alternativement aux deux types de fenêtres, an de générer des fenêtres de trois éléments. Si nous regardons en premier le type fenêtre disjointe, nous constatons que les trois premiers éléments de la séquence appartiennent à la première fenêtre. Les trois éléments suivants appartiennent à la deuxième. Nous obtenons alors deux fenêtres distinctes. Quant au type fenêtre glissante, nous avons une fenêtre ouverte pour chaque élément. Cela signie que pendant qu'une fenêtre n'est pas encore fermée, une autre fenêtre a déjà été inaugurée. Ce qui donne un ensemble de cinq fenêtres chevauchées pour ce type de fenêtres. Tumbling window Sliding window Figure 4.4 Une séquence d'entrée de sept éléments qui va être appliquée alternativement aux deux types de fenêtres, an de générer des fenêtres de trois éléments Syntaxe de la clause de fenêtrage De manière analogue à ForClause, nous savons que WindowClause itère sur la séquence d'entrée, an de générer des sous-séquences représentant un ensemble de fenêtres. Autrement dit, chaque fenêtre est une séquence consécutive d'éléments provenant de la séquence d'entrée. La syntaxe de la clause de fenêtrage a été dénie par le W3C dans la version 1.1 de XQuery [49]. Voici sa représentation complète : 30

37 WindowClause ::= "for" (TumblingWindowClause SlidingWindowClause) TumblingWindowClause ::= "tumbling" "window" "$" VarName TypeDeclaration? "in" ExprSingle WindowStartCondition WindowEndCondition? SlidingWindowClause ::= "sliding" "window" "$" VarName TypeDeclaration? "in" ExprSingle WindowStartCondition WindowEndCondition WindowStartCondition ::= "start" WindowVars "when" ExprSingle WindowEndCondition ::= "only"? "end" WindowVars "when" ExprSingle WindowVars ::= ("$" CurrentItem)? PositionalVar? ("previous" "$" PreviousItem)? ("next" "$" NextItem)? Dès lors, nous pouvons remarquer que chaque fenêtre est représentée par au plus neuf variables. Leur rôles sont spéciés par la suite : La variable de travail de fenêtrage (VarName) : cette variable est associée à l'ensemble des éléments venant de la séquence d'entrée formant une fenêtre. La variable du premier élément (CurrentItem) : elle est associée au premier élément de la fenêtre. La variable de position du premier élément (PositionalVar) : elle représente la position du premier élément de la fenêtre dans la séquence d'entrée. Elle est une variable positionnelle qui se commence avec le mot-clé at, son type est xs : integer. La variable de l'élément précédent le premier élément (PreviousItem) : elle est associée à l'élément dans la séquence d'entrée se trouvant juste avant le premier élément de la fenêtre. Elle renvoie une séquence vide dans le cas où l'élément n'existe pas. La variable de l'élément suivant le premier élément (NextItem) : elle est associée à l'élément dans la séquence d'entrée se trouvant juste après le premier élément de la fenêtre. Elle renvoie une séquence vide dans le cas où l'élément n'existe pas. La variable du dernier élément (CurrentItem) : elle est associée au dernier élément de la fenêtre. 31

38 La variable de position du dernier élément (PositionalVar) : elle représente la position du dernier élément de la fenêtre dans la séquence d'entrée. Elle est une variable positionnelle qui se commence avec le mot-clé at, son type est xs : integer. La variable de l'élément précédent le dernier élément (PreviousItem) : elle est associée à l'élément dans la séquence d'entrée se trouvant juste avant le dernier élément de la fenêtre. Elle renvoie une séquence vide dans le cas où l'élément n'existe pas. La variable de l'élément suivant le dernier élément (NextItem) : elle est associée à l'élément dans la séquence d'entrée se trouvant juste après le dernier élément de la fenêtre. Elle renvoie une séquence vide dans le cas où l'élément n'existe pas. Après la syntaxe donnée ci-dessus, nous constatons que les huit dernières variables sont toutes optionnelles. En particulier, il s'agit ici d'une contrainte imposée telle que toutes les variables de la clause de fenêtrage doivent posséder des noms diérents, sinon une erreur statique est censée se produire Comment une fenêtre est-elle établie? WindowStartCondi.on : WindowEndCondi.on : vraie S fausse S vraie E fausse E S S E E E E Séquence d entrée Une fenêtre Figure 4.5 La création d'une fenêtre avec WindowClause. Au fur et à mesure que nous itérons sur la séquence d'entrée, les fenêtres sont successivement créées. Ceci est dû à deux clauses : WindowStartCondition et WindowEndCondition. Plus précisément, la clause WindowStartCondition permet d'identier le premier élément de la fenêtre. La clause WindowEndCondition permet de déterminer le dernier élément de la fenêtre. Cela fonctionne eectivement grâce à une expression booléenne spéciée après le mot-clé when se trouvant dans ces deux clauses. En partant du début de la séquence d'entrée, le premier élément de la fenêtre sera identié une fois qu'il rend l'expression booléenne de WindowStartCondition vraie. Autrement dit, aucune fenêtre ne pourra commencer tant que le bon élément n'est pas encore trouvé. Ce qui explique la raison 32

39 pour laquelle, il est possible que certains éléments ne font partie d'aucune fenêtre. Une fois que le début de la fenêtre est déterminé, nous continuons à examiner les éléments suivants dans la séquence d'entrée avec l'expression booléenne de WindowEndCondition, pour dénir la n de cette dernière. En conséquence, chaque fenêtre contient son premier élément, son dernier élément ainsi que tous les éléments qui se trouvent entre les deux, dans la séquence d'entrée (voir gure 4.5). A présent, plusieurs cas possibles sont à considérer. Si le dernier élément est lui-même le premier élément, la fenêtre contiendra alors un seul élément. Si le premier élément a été identié, mais en parcourant la séquence d'entrée, aucun élément ne satisfait la clause WindowEndCondition, alors l'option only sera intervenue : En mettant le mot-clé only devant la clause WindowEndCondition, il est spécié dans ce cas qu'aucune fenêtre ne sera générée. Sinon, en absence de ce mot-clé, une fenêtre sera générée en associant son dernier élément au dernier élément de la séquence d'entrée. Remarquons que les principes dénis ci-dessus sont partagés par les deux types de fenêtres dont nous avons discuté à la section précédente : fenêtre disjointe et fenêtre glissante. Il existe pourtant des diérences entre ces deux types, plus précisément la manière de déterminer le premier élément de chaque fenêtre. Nous allons les détailler aux sections suivantes Fenêtre disjointe Le premier type de fenêtres dont nous allons discuter maintenant est fenêtre disjointe. Fenêtre disjointe partitionne en eet la séquence d'entrée en des sous-séquences distinctes. Ce qui a été montré dans l'exemple de requête précédent à la gure 4.3, pour lequel chaque fenêtre est déterminée comme une séquence de messages, postés par un auteur particulier dans un blog. La recherche du début de la première fenêtre commence avec le premier élément de la séquence d'entrée. Rappelons que pour ce type, les fenêtres ne se chevauchent pas. Cela revient à dire qu'une fois que le premier élément d'une fenêtre est identié, la recherche du début de la prochaine fenêtre sur la séquence d'entrée ne pourra être lancée qu'après la terminaison de la dernière fenêtre. Par conséquent, aucun élément appartenant à une fenêtre ne peut apparaître à une autre, pour la même séquence d'entrée. Une autre diérence à remarquer est que la clause WindowEndCondition est optionnelle pour le type fenêtre disjointe. Il existe plusieurs cas d'utilisation pour lesquels la condition de la clause WindowStartCondition devrait déterminer implicitement la n de la fenêtre. Par exemple, la journée d'une personne commence chaque matin lorsque son réveil sonne, ce qui termine également la journée précédente. Par conséquent, dans le cas d'absence de cette dernière, la condition de WindowStartCondition est appliquée sur la séquence d'entrée pour dénir le début des fenêtres. Ainsi, chaque fenêtre est détermi- 33

40 née en commençant avec son premier élément jusqu'à l'élément se trouvant juste avant le premier élément de la prochaine fenêtre, ou, jusqu'au dernier élément de la séquence d'entrée. An de pouvoir spécier des conditions plus complexes, nous pouvons introduire des variables, dénies à la section 4.3.2, dans les expressions booléennes. Par exemple, la requête présentée ci-dessous extraite du site W3C [49] utilise les variables positionnelles an de diviser la séquence d'entrée en diérentes fenêtres de taille trois : for tumbling window $w in (2, 4, 6, 8, 10, 12, 14) start at $s when fn:true() end at $e when $e - $s eq 2 return <window>{ $w }</window> Étant donné une séquence d'entrée qui consiste en sept éléments, sur laquelle va itérer la variable de travail $w, nous déterminons le début et la n des fenêtres. Dans la clause WindowStartCondition, la variable positionnelle $s dénit la position du premier élément de la fenêtre, avec la condition de l'expression booléenne qui est vraie dans tous les cas. Quant à la clause WindowEndCondition, elle utilise une variable de position $e qui dénit la position du dernier élément de la fenêtre. An de fermer une fenêtre, il faut que la position de son dernier élément ait une diérence de deux par rapport à celle de son premier élément. Ce qui nous permet de générer des fenêtres de résultats de taille trois comme suit : <window>2 4 6</window> <window> </window> <window>14</window> Nous pouvons remarquer que seulement les deux premières fenêtres, dans le résultat, possèdent trois éléments. La dernière n'en a qu'un seul. Il est évident que cet élément ne satisfait pas la condition de WindowEndCondition, pourtant une fenêtre a été générée. Pour éviter qu'une telle situation ne se produise, nous pouvons introduire l'option only, discutée à la section La requête précédente devient cette fois : for tumbling window $w in (2, 4, 6, 8, 10, 12, 14) start at $s when fn:true() only end at $e when $e - $s eq 2 return <window>{ $w }</window> Et voici le résultat correspondant où la dernière fenêtre n'a pas été créée : <window>2 4 6</window> <window> </window> 34

41 4.3.5 Fenêtre glissante et fenêtre glissante sans contraintes Outre fenêtre disjointe, les deux autres types de fenêtres, fenêtre glissante et fenêtre glissante sans contraintes sont également utilisées dans de nombreuses applications. Mais contrairement à fenêtre disjointe, ils acceptent le cas où les fenêtres se chevauchent. La diérence entre ces deux types est que, pour fenêtre glissante, il n'accepte jamais que deux fenêtres aient le même premier élément, alors que fenêtre glissante sans contraintes n'impose pas cette obligation. Leur sémantique est en général analogue à celle de fenêtre disjointe, sauf que : si chaque élément satisfait la condition de la clause WindowStartCondition, il peut potentiellement en ouvrir une (pour fenêtre glissante) ou plusieurs (pour fenêtre glissante sans contraintes). Pour l'instant, la syntaxe de fenêtre glissante sans contraintes n'est pas encore supportée par XQuery 1.1, nous allons donc discuter seulement sur des exemples de fenêtre glissante, venant de [49] : Exemple : for sliding window $w in (2, 4, 6, 8, 10, 12, 14) start at $s when fn:true() only end at $e when $e - $s eq 2 return <window>{ $w }</window> Remarquons qu'il apparaît approximativement la même requête que celle introduite dans le cas de fenêtre disjointe. Cette fois, elle ouvre pour chaque élément de la séquence d'entrée, une fenêtre contenant l'élément courant ainsi que les deux éléments qui le suivent, an de former des fenêtres de taille trois. Comme il s'agit du type fenêtre glissante, il existe donc des intersections entre les fenêtres. L'option only est également utilisée dans la requête, ce qui permet d'enlever les deux dernières fenêtres correspondantes aux éléments 12 et 14. Le résultat obtenu est donné ci-dessous : <window>2 4 6</window> <window>4 6 8</window> <window>6 8 10</window> <window> </window> <window> </window> 4.4 Conclusion Ce chapitre nous a donné : Une présentation des extensions de SQL, à savoir : le fenêtrage avec les clauses PARTITION BY et cadres de fenêtrage. les classements avec ROW_NUMBER(), RANK(), et DENSE_RANK(), 35

42 Ainsi qu'une explication de la nouvelle version XQuery 1.1 à propos de la notion de fenêtrage et de diérents types de fenêtres, notamment fenêtre disjointe et fenêtre glissante. Grâce aux exemples illustrés dans les divers cas de traitement de données de ce chapitre, nous pouvons donc maintenant passer au chapitre 5. Il consiste à mettre en uvre des exemples diérents de requêtes tant en SQL qu'en XQuery. Pour obtenir une comparaison cohérente, toutes les requêtes établies de ces deux langages seront manipulées sur une même base de données qui est exprimée à la fois sous la forme relationnelle et arborescente. 36

43 Chapitre 5 Exemples de requêtes de comparaison entre SQL et XQuery 5.1 Introduction Le chapitre précédent nous a permis d'obtenir une vue détaillé de la notion de fenêtrage tant en SQL qu'en XQuery. Bien que ces deux langages permettent de créer des fenêtres avec leurs propres notions, ils sont pourtant de nature très diérente. Pour cette raison, une série de requêtes ont été réalisées à la fois sous les deux versions sur une base de données similaire, an de pouvoir comparer ces deux langages. Toutefois, il existe des cas où la transformation d'une version vers l'autre n'est pas du tout évidente, voire même impossible de la mettre en uvre de manière simple. Remarquons que XQuery 1.1 n'est pas encore implémenté dans la plupart des bases de données. Nous allons donc eectuer des requêtes de fenêtrage à l'aide de Zorba, un processeur XQuery dont il sera discuté par la suite. Zorba [11], un processeur XQuery implémenté en C++ supporte la nouvelle norme XQuery 1.1. Il ne s'agit pas ici d'une base de données XML mais plutôt d'un processeur de requêtes. Ce dernier a été conçu pour être utilisé dans des environnements divers, tels que les autres langages de programmation de traitement XML, les navigateurs, les serveurs de bases de données, ou les smartphones. Son architecture utilise une conception modulaire permettant de le personnaliser à l'environnement correspondant à ses besoins. Zorba s'exécute sur la plupart des plates-formes et est disponible sous la licence Apache v2 [8]. Les exemples ci-dessous ont été réalisés sous Microsoft SQL Server 2008 pour SQL et Zorba pour XQuery. La base de données dans laquelle sont exécutées les requêtes XQuery se trouve dans un document XML, appelé example.xml, alors que les données de travail pour SQL sont importées directement dans Microsoft SQL Server Voici un scénario portant sur les éléments utilisés dans la base de données, et ensuite le schéma relationnel correspondant : 37

44 Employee (1,1) (1,n) Work for Department (0,n) WorksOn (0,n) Project Employee SSN FName MInit LName BDate Address Sex Salary SuperSSN DNo HireDate SuperSSN référence Employee(SSN) DNo référence Departement(DNumber) Department DNumber DName MgrSSN MgrStartDate NbrEmployees MgrSSN référence Employee(SSN) WorksOn ESSN PNo Hours ESSN référence Employee(SSN) PNo référence Project(PNumber) Voici un exemple de l'élément employee, de l'élément department, et de l'élément workson extrait du document XML example.xml : <employee> <FName>Franklin</FName> <MInit>T</MInit> <LName>Wong</LName> <SSN> </SSN> <BDate> </BDate> <Address>638 Voss, Houston, TX</Address> <Sex>M</Sex> <Salary> </Salary> <SuperSSN> </SuperSSN> <DNo>5</DNo> 38

45 <HireDate> </HireDate> </employee>... <department> <DName>Administration</DName> <DNumber>4</DNumber> <MgrSSN> </MgrSSN> <MgrStartDate> </MgrStartDate> <nbremployees>3</nbremployees> </department>... <workson> <ESSN> </ESSN> <PNo>1</PNo> <hours>32.5</hours> </workson> Première requête Nous avons vu à la section 4.2.1, la puissance de la clause PARTITION BY que fournit SQL 2003 permettant de générer des groupements de manière plus souple que GROUP BY. Malgré que XQuery 1.1 ait été équipé de la syntaxe de groupement, il manque pourtant la propriété intéressante PARTITION BY de SQL Pour commencer la série de comparaison, nous allons réaliser une requête SQL avec PARTITION BY, et essayons ensuite de l'exprimer sous version XQuery. Plus précisément, cette requête SQL va diviser la table WorksOn en sous-partitions diérentes, selon le numéro identiant l'employé, an de calculer le nombre total d'heures que ce dernier a travaillé. Elle renvoie également, pour chaque employé, son numéro d'identication, les numéros des projets sur lesquelles il travaille, ainsi que le nombre d'heures de travail correspondant à chaque projet. Voici la requête exprimée en SQL : select ESSN, PNo, hours, SUM(hours) over (partition by ESSN) as total from WorksOn order by ESSN Et ensuite, la requête correspondante exprimée en XQuery : 39

46 let $result:= ( ) } for $SSN in fn:distinct-values(doc("example.xml")//workson/essn) let $w := doc("example.xml")//workson[essn = $SSN] let $sum := sum($w/hours) return element workson{ <SSN>{$SSN}</SSN>, <sum> {$sum}</sum> } for $i in doc("example.xml")//workson order by $i/essn let $sum := $result[ssn = $i/essn]/sum return element Requete3{ <SSN>{data($i/ESSN)}</SSN>, <PNo>{data($i/PNo)}</PNo>, <hours> {data($i/hours)}</hours>, <total>{data($sum)}</total> Le résultat obtenu pour SQL est donné ci-dessous : ESSN PNo hours total En voici un extrait du résultat en XML : <Requete3> 40

47 <SSN> </SSN> <PNo>1</PNo> <hours>32.5</hours> <total>40</total> </Requete3> <Requete3> <SSN> </SSN> <PNo>2</PNo> <hours>7.5</hours> <total>40</total> </Requete3> <Requete3> <SSN> </SSN> <PNo>1</PNo> <hours>10.0</hours> <total>40</total> </Requete3>... Il est clair que la version de XQuery est beaucoup plus compliquée que celle de SQL. Elle nécessite en eet deux fois la réalisation de la clause ForClause pour obtenir un même résultat en SQL. 5.3 Deuxième requête D'un autre côté, une propriété intéressante qu'apporte SQL 2003 est la possibilité d'eectuer des classements. Dès lors, nous allons, par la suite, étudier l'implémentation des classements de SQL en XQuery. A cause des propriétés particulières de RANK(), et DENSE_RANK(), il n'existe pas de procédés simples de les rendre sous la version XQuery. Nous nous limitons dans ce cas à ROW_NUMBER(). Il sut d'utiliser la variable positionnelle de XQuery pour renvoyer les bons ordres. Voici la requête en SQL : select ESSN, row_number() over (order by ESSN ) as num from WorksOn Et la version correspondante en XQuery : for $w at $i in (doc("example.xml")//workson) 41

48 order by $w//essn descending return <row_num> {$w//essn},<num>{$i}</num> </row_num> Nous obtenons le résultat correspondant en SQL comme suit : ESSN num Et voici ci-dessous un extrait du résultat pour la version en XQuery : <row_num><essn> </essn>,<num>15</num></row_num> <row_num><essn> </essn>,<num>16</num></row_num> <row_num><essn> </essn>,<num>13</num></row_num> <row_num><essn> </essn>,<num>14</num></row_num> <row_num><essn> </essn>,<num>10</num></row_num> <row_num><essn> </essn>,<num>11</num></row_num> <row_num><essn> </essn>,<num>12</num></row_num> <row_num><essn> </essn>,<num>9</num></row_num>... 42

49 5.4 Troisième requête Par la suite, essayons de trouver une version correspondante en SQL de type fenêtre disjointe de XQuery. Mais en passant en revue les diérentes possibilités fournies par la clause cadres de fenêtrage, nous sommes dans l'impossibilité de trouver une solution simple correspondante avec SQL Server 2008, voire pour une requête modeste en XQuery telle que suivante : for tumbling window $w in (2, 4, 6, 8, 10, 12, 14) start at $s when fn:true() end at $e when $e - $s eq 2 return avg($w) Rappelons que cette requête exprimée en XQuery cherche à créer des fenêtres distinctes de taille trois, avec la condition de WindowStartCondition vraie pour tous les cas. Ensuite, la moyenne est calculée pour chacune des fenêtres résultantes, ce qui donne le résultat en XML ci-dessous : <?xml version="1.0" encoding="utf-8"?> Intuitivement, la syntaxe de la clause cadres de fenêtrage que fournit la norme de SQL 2003 permet en général de construire des fenêtres qui possèdent des intersections. Dès lors, il est évident que sa caractéristique n'est pas cohérente avec celle de fenêtre disjointe. Par conséquent, aucune version simple de cette requête en SQL n'a été découverte. 5.5 Quatrième requête Il semble que la propriété de cadres de fenêtrage en SQL 2003 est compatible avec fenêtre glissante de XQuery. Nous abordons donc maintenant ce deuxième type de fenêtrage. Cette quatrième requête illustre un exemple de fenêtre glissante. Néanmoins, la syntaxe de la clause cadres de fenêtrage n'est pas encore supportée par SQL Server Nous implémentons donc cette requête en se basant sur ce qui est proposé dans la norme SQL 2003 [23]. Cette dernière calcule, la moyenne de salaires en tenant compte, pour chaque employé de son salaire et de celui de deux employés se situant juste après. Voici la requête de fenêtre glissante en XQuery : <Requete4>{ for sliding window $w in (doc("example.xml")//employee) start at $s when fn:true() end at $e when $e - $s eq 2 43

50 return <group> {$w[1]/ssn} <avg>{avg($w/salary)}</avg> </group> }</Requete4> Et un extrait du résultat en XML : <Requete4> <group><ssn> </ssn>><avg> </avg></group> <group><ssn> </ssn>><avg>36000</avg></group>... </Requete4> Et celle correspondante en SQL, respectant la norme SQL 2003 : select SSN, avg(salary)over(order by SSN rows 2 following) as avg from Employee 5.6 Conclusion Dans ce chapitre, une série de comparaisons ont été réalisées entre SQL et XQuery. Grâce à celles-ci, nous avons constaté que la transformation de la clause PARTITION BY en SQL en la version XQuery n'est pas du tout évidente, même pour une requête de complexité étroite. La même situation a été rencontrée dans le cas de classements. Seul le cas de ROW_NUMBER() a été opéré en ayant recours à la variable positionnelle de XQuery. Ainsi, il n'existe pas de méthode simple en SQL pour exprimer la requête XQuery de type fenêtre disjointe, vu leur non compatibilité. Par contre, un exemple de requête de fenêtre glissante a été examiné pour XQuery et sa version équivalente en SQL a également été réalisée. 44

51 Chapitre 6 exist et les bases de données XML natives 6.1 Introduction Dans ce chapitre, une première discussion portant sur XML avec la question estil une base de données? sera représentée à la section 6.2. Une explication détaillée à 6.3 sera abordée sur le concept de base de données XML native avec ses diérentes dénitions et ses architectures. Ces deux sections seront étudiées en se basant sur [16]. Par la suite, à 6.4, une base de données XML native dans laquelle va implémenter la fonctionnalité de fenêtrage, à savoir exist et son principe d'indexation, seront également examinés en se référant à l'arctile [37] publié par Wolfgang Meie. La sous-section consistera à expliquer le scénario du déroulement d'une requête XQuery dans le système exist. 6.2 XML est-il une base de données? Avant d'entamer la discussion sur les bases de données XML natives, une question triviale à se poser avant tout : XML est-il lui-même une base de données?. Dans [16], la réponse à ce propos peut être positive dans le sens le plus strict du terme : en eet, XML est une collection de données. De plus, étant un format de base de données, XML fournit quelques avantages. Par exemple, il permet l'auto-description où des balises décrivent la structure et le type des noms de données ; en plus il est portable et rend susceptible le stockage des données sous forme arborescente. A l'opposé chez XML, apparaît également des désavantages tels qu'être verbeux et suite à une phase d'analyse du parseur et à une conversion du texte, l'accès aux données est ralenti. Une deuxième question est que : XML et ses technologies accompagnées constituentils un système de gestion de base de données (SGDB)?. La réponse est oui et non. 45

52 Positivement, XML fournit eectivement plusieurs fonctionnalités nécessaires pour une base de données : le stockage tel que les documents XML, les langages de schéma tels que DTDs, XML Schemas, RELAX NG [22, 31, 20], etc., les langages de requête tels que XQuery, XPath, XQL [45, 51], XML-QL [24], etc., les interfaces de programmation telles que SAX [44], DOM [5, 28, 48], JDOM [2]. Négativement, XML manque de plusieurs fonctionnalités propres à une vraie base de données, telles que le stockage ecient, les index, la sécurité et l'intégrité des données, etc. Par conséquent, il est possible d'utiliser un ou plusieurs document(s) XML comme base de données, dans un environnement avec une quantité limitée de données, d'utilisateurs et une faible exigence de performance. En revanche, il n'est surtout pas applicable dans un environnement de production dont l'exigence sur l'intégrité des données est stricte, dont la demande d'une bonne performance est obligatoire et le support de multiutilisateur est nécessaire. 6.3 Bases de données XML natives Introduction D'après [16], les bases de données XML natives (Native XML databases) sont des bases de données conçues spécialement pour le stockage de documents XML. Comme d'autres bases de données, elles supportent des fonctionnalités telles que la transaction, la sécurité, l'accès de multiutilisateur, les langages de requête, etc. La seule diérence à noter est que leur modèle interne ne s'est basé que sur XML. Un historique sur la naissance du terme base de données XML native apparaît pour la première fois lors d'une campagne de marketing pour Tamino [13], une base de données XML native de Software AG. Il est possible que suite au succès de cette campagne, le terme devient populaire et est utilisé en commun entre les entreprises qui développent des produits similaires. Néanmoins, étant propre au marketing, il n'a jamais été déni de manière formelle. Les dénitions possibles d'une base de données XML native sont les suivantes : Une base de données XML native permet de déterminer un modèle logique pour un document XML, dans lequel le stockage et l'extraction des documents sont dénis. De plus, au minimum, ce modèle doit inclure les éléments, les attributs, les PCDATAs et l'ordre du document. Un tel modèle est illustré par : le modèle de données XPath, le XML Infoset et les modèles utilisés par DOM et SAX. Pour dénir l'unité fondamentale de son stockage logique : une base de données XML native emploie un document XML, de même qu'une base de données relationnelle utilise une ligne dans une table. Une base de données XML native ne se réclame d'aucun modèle de stockage physique sous-jacent particulier. Par exemple, elle peut soit être construite sur une base 46

53 de données relationnelle, hiérarchique, ou orienté-objet ; soit utiliser un format de stockage propriétaire tel que des chiers indexés ou compressés. Il est à remarquer que la première partie de cette dénition est similaire aux dénitions d'autres types de bases de données, en se basant sur le modèle. Il faut noter qu'une base de données XML native est susceptible de stocker plus d'information que son modèle. Par exemple, elle peut supporter des requêtes basées sur le modèle de données XPath et stocker des documents sous forme de texte. Dans ce cas, les sections CDATA, par exemple, seront stockées dans la base de données mais pas dans le modèle. La deuxième partie de la dénition stipule que l'unité fondamentale de stockage dans une base de données XML native est un document XML. Il faut rappeler qu'une unité de stockage est le niveau de contexte le plus bas correspondant à une pièce de données, ainsi elle est équivalente à une ligne dans une base de données relationnelle. Néanmoins, il existe d'autres unités de données plus petites, telles que les fragments de documents, les éléments individuels ou la combinaison des fragments d'un document avec ceux d'un autre document. De même, la présence d'une ligne n'empêche pas l'existence d'autres unités de données plus petites, telles que les valeurs individuelles dans chaque colonne ou les nouvelles lignes construites à partir des lignes existantes. Bien qu'une base de données XML native pourrait attribuer le rôle de l'unité fondamentale à des fragments de documents, dans la plupart des bases de données XML native actuelles, ce rôle reste consacré aux documents. La troisième partie de la dénition spécie que le format de stockage de données sous-jacent n'est pas important. En eet, ceci est analogue à armer, que le format de stockage physique utilisé par une base de données relationnelle, n'inuence pas le fait que celle-ci soit relationnelle ou non Architectures de la base de données XML native Bases de données XML natives sur base textuelle Une base de données XML native sur base textuelle (text-based native XML database) stocke XML sous forme de texte. Par exemple, ceci peut être un chier dans un système de chiers. Toutes les bases de données XML natives sur base textuelle sont indexées. Ce qui permet au moteur de recherche d'eectuer des sauts facilement, à n'importe quel endroit au sein d'un document XML. Ceci ore un grand avantage au niveau de l'extraction des documents ou des fragments de documents. En eet, une fois que la tête du disque est positionnée, la base de données peut eectuer une seule recherche au niveau de l'index et extraire l'entièreté du document ou du fragment, en une seule lecture, en supposant que le fragment nécessaire est stocké dans des octets contigus du disque. En revanche, le réassemblage d'un document exige de multiples recherches au niveau de l'index, ainsi 47

54 que de multiples lectures du disque. Ceci est pratiqué de même manière dans une base de données relationnelle et dans certaines bases de données XML natives sur base de modèle Bases de données XML natives sur base de modèle La deuxième catégorie des bases de données XML natives est les bases de données XML natives sur base de modèle (model-based native XML databases). Cette fois, plutôt que de stocker le document XML sous forme de texte, les bases de données XML natives sur base de modèle construisent un modèle objet interne à partir de ce document et ensuite stocke ce modèle. La façon de stocker le modèle dépend eectivement de chaque base de données. Parmi celles-ci, certaines les enregistrent dans une base de données relationnelle ou dans celle orientée-objet. Par exemple, le stockage d'un DOM dans une base de données relationnelle peut donner comme résultat un ensemble de tables telles que Eléments, Attributs, PCDATA, Entités, et EntitésRefs. D'autres bases de données utilisent un format de stockage propriétaire optimisé pour leur modèle. Les bases de données XML natives sur base de modèle, construites sur d'autres bases de données, sont susceptibles d'avoir la même performance que ces dernières. En eet, elles reposent sur leurs systèmes pour l'extraction des données. Cependant, la conception de la base de données, en particulier pour les bases de données XML natives construites sur les bases de données relationnelles, comporte des variation signicatives [16]. En outre, les bases de données XML natives sur base de modèle, en utilisant un format de stockage propriétaire, sont susceptibles d'avoir une performance similaire aux bases de données XML natives sur base textuelle, lors de l'extraction des données, selon un ordre dans lequel elles sont enregistrées. En eet, la plupart de ces bases de données utilisent des pointeurs physiques entre les n uds, ce qui devrait amener la même performance à l'extraction du texte. Cependant, le format de sortie que chacun doit générer permet de déterminer qui est le plus rapide. Plus précisément, les systèmes sur base textuelle sont plus rapides, en renvoyant des documents sous forme de texte. Au contraire, les systèmes sur base de modèle sont plus rapides, en fournissant en sortie, des documents comme des DOMs, en supposant que leur modèle corresponde facilement au DOM. Finalement, les bases de données XML natives sur base de modèle, comme celles sur base textuelle, sont susceptibles de rencontrer des problèmes, au niveau de la performance, lors de l'extraction et du retour des données dans une forme autre que celle où elles ont été stockées Conclusion Par conséquent, la notion des bases de données XML natives nous est désormais familière. Ce qui nous permet d'entamer, dans la section suivante, un des sujets principaux 48

55 dans le cadre de ce mémoire, à savoir exist [38], une base de données XML native. 6.4 exist, une bases de données XML native exist [37] mis en uvre par Wolfgang Meie en 2000, est un logiciel Open Source pour développer un système de base de données XML native et est susceptible de s'intégrer facilement dans des applications associées à XML, dans des circonstances variées. Cette base de données est écrite en Java. Ainsi, le but est d'orir la possibilité de la développer de diérentes manières : soit comme un serveur stand-alone à l'intérieur d'un moteur de servlet, soit en l'imbriquant directement dans une application. exist fournit un schéma de stockage où les documents XML s'organisent dans les collections hiérarchiques. En utilisant la syntaxe étendue de XPath, nous sommes capables d'interroger chaque partie diérente de la collection hiérarchique, ou voire tous les documents se trouvant dans la base de données. Le moteur de recherche d'exist est mis en uvre de manière eciente, avec un traitement de requêtes fondé sur l'indexation. Un schéma d'indexation amélioré permet d'identier de manière rapide la structure des relations entre les n uds, telles qu'entre parents-enfants, entre ancêtres-descendants ou entre frères-s urs. En se basant sur des algorithmes de jointure des chemins (path join algorithms [34, 47, 52]), une large variation de requêtes sont utilisées, des expressions de chemin sont développées à l'aide de l'information d'indexation. La base de données est actuellement une meilleure adaptation pour des applications de traitement des collections de documents XML dont la taille peut être variable. exist fournit, en outre, de nombreuses extensions à la version standard de XPath, an de traiter de manière ecace des requêtes en plein texte, y compris des recherches par motclé, des requêtes renvoyant une proximité sur des termes de recherche ou des expressions régulières. De plus, pour les développeurs, l'accès via HTTP, XML-RPC, SOAP [6] et WebDAV [29] est également fourni. Les applications Java peuvent utiliser l'api XML :DB [42], une interface commune pour l'accès aux bases de données XML actives (XMLenabled databases) ou natives. Cette dernière a été proposée initialement par le vendeur indépendant XML :DB Indexation et stockage du XML Introduction Au chapitre 3, nous avons discuté XQuery et XPath qui, étant des langages de requête XML, utilisent des expressions de chemin pour naviguer au sein de la structure hiérarchique d'un document XML. Cette structure est modélisée sous forme arborescente dans laquelle les n uds sont organisés dans un ordre déni. Un grand nombre de diérentes implémentations des langages de requête XML sont 49

56 actuellement disponibles aux développeurs XML. Cependant, la plupart des implémentations disponibles en tant que logiciel Open Source, sont fondées sur un parcours d'arbre de type conventionnel top-down ou bottom-up, pour évaluer des expressions de chemin. Il est évident que ces derniers deviennent très inecaces pour des larges collections de documents tels qu'ils sont montrés dans [34, 47, 52]. Par exemple, considérons une telle expression XPath suivante pour sélectionner les titres de toutes les gures se trouvant dans une collection de livres : /livre//figure/titre Dans le parcours de type conventionnel top-down, le processeur doit suivre tous les chemins en commençant avec un nom d'élément livre pour vérier si tous les descendants sont potentiellement figure. Ceci parce qu'il est impossible de déterminer à l'avance l'endroit où se situent les descendants figure. Ce qui signie qu'un grand nombre de n uds n'étant pas figure doivent être également accédés pour vérier, premièrement, si ceux-ci sont éléments et deuxièmement, si ils sont étiquetés par le nom figure. Ainsi, des structures basées sur l'indexation sont nécessaires pour eectuer ecacement des requêtes sur des larges collections de documents. Un schéma d'indexation doit fournir des moyens pour traiter la sélection basée sur valeur (value-based selections) aussi bien que celle basée sur structure (structural selections). La sélection basée sur valeur s'appuie sur le nom d'élément, sur le couple (nom, valeur) d'attribut ou sur le texte contenu dans l'élément. La sélection basée sur structure s'applique sur la structure des relations entre les n uds. La sélection basée sur valeur est généralement bien prise en charge, en étendant les schémas d'indexation traditionnels, tel que B+-trees [36] ; par contre la sélection sur structure est plus dicile à gérer. En plus, pour accélérer le traitement des expressions de chemin en se basant sur la structure des relations, un schéma d'indexation devrait supporter une manière ecace permettant d'identier rapidement les relations entre les n uds Système de numérotation Un nombre considérable de recherches ont été entreprises récemment, pour la conception de la structure d'indexation an de répondre à ces exigences. A ce propos, plusieurs systèmes de numérotation pour les documents XML ont été proposés [19, 32, 34, 46, 47, 52]. Un système de numérotation attribue eectivement un identicateur unique à chaque n ud dans la structure arborescente du document, en employant un parcours par ordre de niveau ou un parcours préxe. Ces identicateurs seront ensuite utilisés comme des index associés à chaque n ud. En plus, un système de numérotation devrait fournir un mécanisme, étant susceptible de déterminer rapidement la structure des relations entre chaque couple de n uds et d'identier toutes les occurrences d'une telle relation, au sein d'un document ou d'une collection de documents. 50

57 <contact> <name>franklin</name> <phone> <office>112233</office> <home>445566</home> </phone> </contact> 1 contact Id clairsemé 2 name 3 phone 4 Franklin 5 6 office 7 home Figure 6.1 Les identicateurs uniques assignés par le système de numérotation exist. Le système de numérotation implémenté dans exist, représente une extension d'un système par ordre de niveau, proposé par Lee et al. [32]. Ce dernier, étant un système de numérotation, il représente l'arbre du document sous forme d'un arbre k-aires complet où k est égal au nombre maximum de n uds ls d'un élément dans le document. Un identicateur unique est assigné à chaque n ud, en traversant l'arbre avec un parcours par ordre de niveau. Comme l'arbre est supposé être complet, alors de nombreux identicateurs clairsemés ont été rajoutés à des endroits diérents dans l'arbre. En conséquence, ceci suscite une restriction importante sur la taille maximum du document à indexer. Le système exist a surmonté le problème de limitation de taille du document en supprimant partiellement la contrainte de la propriété complète. Désormais, le document n'est plus considéré comme un arbre k-aires complet. En revanche, le nombre de ls que pourrait avoir chaque n ud est recalculé pour chaque niveau de l'arbre de telle manière que : Pour deux n uds x et y d'un arbre, taille(x) = taille(y) si niveau(x) = niveau(y), où taille(n) dénote le nombre de ls d'un n ud n et niveau(m) est la longueur du chemin allant de la racine à ce n ud. L'information supplémentaire sur le nombre de ls que peut avoir un n ud à chaque niveau de l'arbre, est stockée dans un simple tableau avec le document. La gure 6.1 illustre les identicateurs uniques générés par exist [37]. Par rapport au système de numérotation original, moins d'identicateurs clairsemés doivent être insérés. Il est à noter que, l'insertion d'un n ud à un niveau plus bas dans l'arbre, ne suscite aucun impact sur les identicateurs uniques assignés aux n uds se situant aux niveaux 51

58 supérieurs. En eet, il est possible de laisser des identicateurs clairsemés entre les n uds existants, an d'éviter une réorganisation fréquente de ceux-ci sur la dernière version du document. Ces techniques sont décrites dans [19, 34]. Désormais, exist s'est adapté an de supporter XUpdate, un mécanisme de mise à jour avancé tel qu'il est déni dans [41]. Il est à noter que, l'utilisation d'un système de numérotation n'inuence pas les propriétés générales de l'assignation des identicateurs par ordre de niveau. En eet, à partir d'un identicateur unique donné, il est toujours possible de calculer les identicateurs de son père, de son frère, et de son ls, en utilisant l'information supplémentaire sur le nombre de ls que peut avoir chaque n ud à chaque niveau de l'arbre. Nous allons maintenant argumenter en faveur du système de numérotation actuellement implémenté dans exist. Contrairement à notre approche, les systèmes d'indexation alternatifs se concentrent sur un sous-ensemble limité des expressions de chemin. Plus précisément, ils mettent l'accent sur le support des axes de navigation tels que child, attribute et descendant. Puisque exist a été conçu dans le but de fournir une implémentation complète pour le langage de requête XPath, la possibilité de supporter tous les axes de XPath a requis une grande importance durant le développement exist. Par exemple dans le document example.xml, considérons une expression qui prend tous les éléments employee dont l'élément Sex contenant la chaine 'M' : //Sex[contains(., 'M')]/.. Le.. étant une abréviation de parent::node() prendra l'élément père de chaque n ud dans le contexte courant de l'ensemble de n uds. En utilisant notre système de numérotation, il est facile de calculer l'identicateur du n ud père pour chaque n ud donné, an d'évaluer l'expression ci-dessus. De même, il est également susceptible de calculer les identicateurs du n ud frère et du n ud ls. Dès lors, tous les axes de navigation peuvent être implémentés dans le système de numérotation. De plus, ceci permet de réduire considérablement la taille de stockage d'un n ud dans le magasin XML : l'enregistrement des liens associés au père, au frère, au ls et à l'attribut de ce n ud dans son objet n'est pas nécessaire. En eet, pour accéder au père d'un n ud, il sut de calculer son identicateur unique et ensuite d'eectuer une recherche au niveau de l'index de celui-ci. Comme le stockage des liens entre les n uds n'est plus réclamé, un élément n'occupera pas plus de 4 à 8 octets dans le magasin XML d'exist. En outre, avec le système d'indexation d'exist, n'importe quel n ud dans un document XML est susceptible de servir comme point de départ pour une expression XPath. Par exemple, l'ensemble de n uds sélectionnés par la première expression XPath peut être traité ensuite par la deuxième. Ceci est un point important à l'égard de XQuery qui permet à des expressions de chemin multiples d'être imbriquées dans une expression XQuery. 52

59 Requête XQuery Indexa7on Requête Grammaire? XPath ANTLR eval Résultat Ok Réponse Figure 6.2 Déroulement d'une requête XQuery Déroulement d'une requête XQuery Lorsqu'une requête XQuery est rédigé dans un terminal d'exist, elle sera en premier passée à la phase syntaxique pour vérier si elle respecte la grammaire qu'a déni exist. Plus précisément, la requête sera découpée en tokens. Ces tokens vont être par la suite examinés par l'outil ANTLR [7], an d'assurer que la grammaire soit bien respectée. Si ce n'est pas le cas, une erreur est censée se produire au niveau du parseur. En revanche, si aucune erreur ne s'est déclenchée, alors un arbre syntaxique intermédiaire correspondant est construit. A la phase suivante, la requête cette fois sera entièrement transformée en classes d'objets. Ceux-ci sont en eet des classes dénies auparavant par exist. Ainsi, des variables nécessaires seront passées éventuellement aux objets récemment créés. Par la suite, les expressions booléennes seront évaluées dans le cas d'une requête de fenêtrage, an de déterminer le début et la n d'une fenêtre. Ceci est entrepris via une fonction appelée eval. Lorsque cette dernière est lancée, elle va aller chercher les données nécessaires pour accomplir sa tâche dans le stockage d'exist en ayant recours à XPath. En eet, grâce au système d'indexation fourni par exist, le parcours au sein des données s'eectue de manière simple et rapide. Il est à noter qu'il est possible que les fonctions eval soient imbriquées. Par conséquent, après avoir évalué l'expression, le résultat sera renvoyé au niveau supérieur, et le déroulement de la requête se continue jusqu'à la n de celle-ci. La gure 6.2 illustre le processus d'une requête au sein de la base de données XML native 53

60 exist. 6.5 Conclusion Après avoir passé en revue le contenu de ce chapitre, nos connaissances s'élargissent sur les bases de données XML natives tels que : d'où vient cette notion?, de quoi s'agitil?, quelles sont les architectures disponibles pour cette dernière?. Dès lors, à partir de cette base de connaissances, nous progressons dans un cas particulier des bases de données XML natives, à savoir exist, un environnement de travail dont sera implémenté la nouvelle fonctionnalité de XQuery, à savoir le fenêtrage. Ainsi, le système d'indexation d'exist est également détaillé. Il s'agit d'une extension d'un système d'indexation existant par ordre de niveau. Ce dernier nous a permis de mieux comprendre pourquoi le système d'exist est bien adapté, en particulier au langage de requête XQuery. Finalement, une explication du déroulement général d'une requête XQuery dans la base de données exist a été réalisée. Dans le chapitre suivant, des exemples concrets du processus de requête de fenêtrage XQuery seront examinés. Ainsi, une description détaillée de la mise en uvre de la clause de fenêtrage dans exist sera abordée. 54

61 Chapitre 7 Implémentation de la clause de fenêtrage dans exist 7.1 Introduction Aux chapitres précédents, une représentation du langage de requête puissant XQuery pour les documents XML a été introduite. Ainsi, la nécessité d'engager une nouvelle fonctionnalité telle que le fenêtrage dans le monde XQuery a également été exposée. Et pour la mettre en uvre, nous avons choisi exist, une base de données XML native du type Open Source, dû à son ecacité d'indexation et son développement réussi dans le monde XML. Ce travail réclame plusieurs modications au niveau du parseur ainsi qu'au niveau d'implémentation du code Java, an de pouvoir adapter la notion de fenêtrage dans le code existant d'exist. Nous allons le détailler par la suite. Par conséquent, la syntaxe de fenêtrage a été intégrée avec succès dans la base de données exist. Comme il s'agit ici d'une première version de l'implémentation de la clause de fenêtrage, il reste encore à l'améliorer. 7.2 Grammaire Dans cette section, nous allons modier la grammaire actuelle d'exist an de rendre possible la nouvelle syntaxe de fenêtrage, en se basant sur la dénition fournie par le site W3C [49]. A cet eet, nous entamons le chier XQuery.g qui consiste à faire l'analyse syntaxique, la construction d'un arbre syntaxique intermédiaire, en se référant à la syntaxe d'antlr [7], un outil de grammaire dont le rôle est similaire aux Lex et Yacc [33]. Comme les clauses forclause et windowclause partagent le mot-clé for, nous créons alors la clause forwinclause le contenant pour ces deux dernières. A partir de ce n ud père, l'arbre se divise en deux branches : soit nous rencontrons un dollar et en- 55

62 for forwinclause $ tumbling window / sliding window forclause windowclause sliding window tumbling window slidingwindow Clause tumblingwindow Clause Figure 7.1 Arbre syntaxique. suite un nom de variable, alors nous sommes sur la branche de forclause ; soit nous rencontrons l'ensemble de mots tumbling window ou sliding window et nous sommes alors sur la branche de windowclause (voir gure 7.1). Détaillons maintenant cette deuxième branche. Comme expliqué précédemment, nous pouvons tomber soit sur le cas de fenêtre disjointe (tumbling window), soit sur celui de fenêtre glissante (sliding window). Supposons que nous sommes dans le premier cas. Après les mots clés tumbling window, nous rencontrons une déclaration de variable, une déclaration de type optionnelle, un motclé in, une expression booléenne, ensuite la clause windowstartcondition et nalement la clause windowendcondition qui est également optionnelle, le tout en respectant la syntaxe de XQuery 1.1 : tumblingwindowclause throws XPathException : ; "tumbling"! "window"! windowvarbinding windowstartcondition (windowendcondition)? {#tumblingwindowclause= #([TUMBLING_WINDOW, "tumbling window"], #tumblingwindowclause); } windowvarbinding throws XPathException { String winvarname; } : DOLLAR! winvarname=qname! ( typedeclaration )? "in"! exprsingle {#windowvarbinding= #(#[VARIABLE_BINDING, winvarname], #windowvarbinding); } 56

63 ; windowstartcondition throws XPathException : "start"^ windowvars "when"! exprsingle ; windowvars throws XPathException : (currentvar)? (positionalvar)? (previousvar)? (nextvar)? ; windowendcondition throws XPathException : ("only"^)? "end"^ windowvars "when"! exprsingle ; La clause windowstartcondition commence par le mot-clé start et ensuite les quatre types de variables qui sont toutes optionnelles : currentvar : représente le premier (ou dernier) élément de la fenêtre. positionalvar : représente la position du premier (ou dernier) élément de la fenêtre dans la séquence d'entrée. previousvar : représente l'élément précédent le premier (ou dernier) élément de la fenêtre dans la séquence d'entrée. nextvar : représente l'élément suivant le premier (ou dernier) élément de la fenêtre dans la séquence d'entrée. La clause se termine avec le mot-clé when suivi d'une expression booléenne. La clause windowendcondition quant à elle ressemble très fort à windowstartcondition, elle commence avec le mot-clé end ou only si cette option est présente. Le cas de fenêtre glissante est tout à faire similaire à fenêtre disjointe, excepté que la clause windowendcondition est obligatoire dans ce cas. 7.3 Analyse de l'arbre syntaxique Une fois que l'arbre syntaxique intermédiaire est construit, nous passons à la phase suivante qui consiste à l'analyser et à générer une représentation des requêtes XQuery 57

64 Figure 7.2 Diagramme de classes des classes de travail. sous forme d'objets, an de les exécuter. Cette tâche est réalisée via le chier XQuery- Tree.g. Grâce à cette étape, le type de fenêtrage, les noms des variables, les conditions de WindowStartCondition et WindowEndCondition etc. sont passés aux objets. Il s'agit en eet des nouvelles classes d'objets consacrées à la syntaxe de fenêtrage que nous allons aborder dans la section suivante. 7.4 Classes de travail Comme précédemment, les requêtes XQuery seront transformées en objets. Ces classes seront composées avec pour objectif de rendre réel le fenêtrage dans exist. Cette section consiste donc à les présenter systématiquement. Leur diagramme de classes conceptuel est illustré à la gure 7.2. Remarquons que l'environnement dans lequel exist est implémenté, est Java. Ces classes suivantes seront donc construites à l'aide de Eclipse, un environnement de développement intégré libre [1] WindowCondition Rappelons qu'une fenêtre considère qu'un élément lui appartient, si ce dernier satisfait à ses conditions. Cette classe représente alors les conditions que les clauses WindowStartCondition et WindowEndCondition contiennent. Elle consiste concrètement en trois attributs : Le contexte dans lequel nous travaillons. L'expression qu'elle représente. Le vecteur contenant trois variables de WindowClause rangées selon un ordre à respecter : 58

65 Index 0 Index 1 Index 2 currentvar previousvar nextvar WindowValueSequence Cette classe est instaurée, en se basant généralement sur la classe GroupedValueSequence. Elle représente une séquence d'éléments formant une fenêtre. Ces éléments sont déterminés par les conditions de la fenêtre. Remarquons que nous retenons la position du premier élément de la fenêtre dans la séquence d'entrée, qui servira ultérieurement pour la méthode add de la classe WindowValueSequenceTable WindowValueSequenceTable Remarquons que plusieurs fenêtres peuvent être créées au fur et à mesure que nous appliquons les conditions sur la séquence d'entrée. Ce qui amène à la nécessité d'un objet qui est capable de contenir toutes les fenêtres générées. Ceci est le rôle de la classe WindowValueSequenceTable. La structure de celle-ci basée sur un HashTable qui distribue à chaque fenêtre une clé permettant de l'identier. Dans cette classe, la méthode la plus intéressante à discuter, est la méthode add qui consiste à rajouter un élément à une fenêtre existante ou à générer une nouvelle fenêtre avec cet élément. Ses paramètres se composent d'un élément à traiter et d'une variable p permettant de mémoriser la position du premier élément d'une fenêtre. Cette dernière servira ultérieurement à l'étape de l'assignation de valeurs aux objets résultats. La méthode add présente donc deux cas : le cas de fenêtre glissante et celui de fenêtre disjointe. Nous allons les détailler de manière systématique. Fenêtre disjointe Présentons d'abord les variables de travail : startitem : assigné au premier élément de la fenêtre courante et égal à null si cette dernière n'existe pas. currentwindow : représente la fenêtre en cours de traitement. Les deux conditions de la fenêtre sont ensuite évaluées pour l'élément traité, an d'obtenir leur valeur booléenne. Rappelons que pour ce type de fenêtres, la clause WindowEndCondition peut être absente. Nous abordons d'abord ce cas. Si l'élément rend la condition de la clause WindowStartCondition vraie, nous ouvrons alors une nouvelle fenêtre, ajoutonsla dans HashTable et nous assignons l'élément à startitem, ce qui marque la terminaison de la fenêtre précédente. En revanche, si la condition est fausse et qu'une fenêtre est déjà ouverte, ce qui peut être détecté par startitem, nous devons ajouter l'élément à la fenêtre courante. 59

66 Dans le cas où la clause WindowEndCondition est présente. Si la condition de la clause WindowStartCondition est rendue vraie par l'élément et qu'aucune fenêtre n'est créée auparavant, l'élément devient alors le premier d'une nouvelle fenêtre. Si une fenêtre est déjà ouverte, nous ajoutons l'élément courant à cette dernière et nous vérions ensuite la valeur de la condition booléenne de WindowEndCondition. Si cette valeur est vraie, nous marquons la n de la fenêtre courante en mettant startitem à null. Fenêtre glissante Ce deuxième cas est diérent du précédent. Ceci est dû à l'autorisation de la présence des fenêtres chevauchées. Ce qui veut dire qu'en ajoutant un élément, nous pouvons avoir plusieurs fenêtres à traiter à la fois. Cette diérence se présente notamment sur les variables de travail : startpositions : un vecteur retient la position du premier élément des fenêtres à traiter. currentstartposition : permet de retenir en particulier la position du premier élément de la fenêtre en cours d'exécution. canenterendclause : représente une valeur booléenne. Dans ce type de fenêtres, la mise à jour des variables de travail de la fenêtre est diérente pour les clauses WindowStartCondition et WindowEndCondition (voir org.exist.xquery.window- Expr). Elle permet donc, après avoir traité le cas de WindowStartCondition, d'entrer dans le cas de WindowEndCondition. isslidingtype : une valeur booléenne permet de distinguer le cas de fenêtre glissante de celui de fenêtre disjointe. Pour le cas de WindowStartCondition : si sa valeur condition est vraie pour l'élément, nous créons une nouvelle fenêtre et mettons à jour le vecteur startpositions. Pour le cas de WindowEndCondition : nous ajoutons l'élément aux fenêtres déjà ouvertes et vérions si la condition de WindowEndCondition est vraie pour cet élément. Si tel est le cas, nous retirons sa fenêtre correspondante de la liste des fenêtres à traiter en mettant -1 dans le vecteur startpositions WindowExpr Cette classe est construite en se basant sur la classe ForExpr. Elle est créée spécialement pour WindowClause. Nous allons discuter le principe de fonctionnement de la méthode eval(sequence contextsequence, Item contextitem, Sequence resultsequence, GroupedValueSequenceTable groupedsequence, WindowValueSequenceTable windowsequence), notamment celui de WindowClause, qui consiste à manipuler les objets résultats, à savoir les fenêtres, an de les associer aux valeurs nales. La procédure est divisée en deux cas : fenêtre disjointe et fenêtre glissante. 60

67 Fenêtre disjointe A l'intérieur de la boucle for parcourant la séquence d'entrée, nous mettons à jour les types de variables de fenêtrage qui serviront ultérieurement à évaluer les tests de conditions de WindowStartCondition et WindowEndCondition. A cet eet, deux variables de travail sont créées : startposition, représentant la position du premier élément de la fenêtre, et endposition, la position du dernier élément de la fenêtre. Ainsi il y a deux cas à traiter : Soit on est dans l'absence de la clause WindowEndCondition. A ce moment là, endposition ne sert absolument à rien. Nous mettons à jour startposition comme un compteur p. Soit la clause WindowEndCondition est bien présente. Alors au début, startposition et endposition commencent au même endroit. Ce qui dénote le début de la séquence d'entrée. Une fois qu'une fenêtre est créée, startposition s'associe au premier élément de la fenêtre, et endposition continue à parcourir la séquence d'entrée, jusqu'à atteindre le dernier élément de la fenêtre et ainsi de suite. Après la boucle for, il faut attribuer les valeurs obtenues aux objets an de les renvoyer. Cette fois startposition et endposition correspondent à leur vraies positions de la fenêtre. Fenêtre glissante Comme nous avons discuté précédemment, les types de variables de fenêtrage sont mises à jour diéremment pour WindowStartCondition et WindowEndCondition. Ainsi, dans WindowStartCondition, startposition et endposition sont associés au compteur p pour trouver l'élément satisfaisant sa condition. Lorsqu'il existe déjà une ou plusieurs fenêtres ouvertes, nous passons dans le cas de WindowEndCondition. La variable endposition, cette fois reste associée au compteur p. Le vecteur startpositions, renvoyé par la classe WindowValueSequenceTable, retient la position du premier élément des fenêtres à traiter. Donc chaque fois qu'une fenêtre est créée, sa position est mise dans ce vecteur. Ainsi une boucle est construite pour parcourir tous les éléments du vecteur startpositions. Ce qui revient à dire que : nous travaillons avec la position du premier élément d'une fenêtre, à chaque tour de la boucle, an d'appeler la méthode add de WindowValueSequenceTable. Il est à noter que l'option only, qui consiste à retirer des fenêtres dont la condition de WindowEndCondition n'est pas satisfaite, n'est pas implémentée. Ceci est dû à une erreur qui s'est produite au niveau du parseur. Cette tâche est à accomplir lors de la prochaine version. 61

68 7.5 Les tests d'unité Les tests d'unité permettent de garantir le bon fonctionnement du programme, notamment les unités comme les classes et les méthodes. Son principe de fonctionnement est d'écrire de simples tests qui sont des méthodes en Java, sans paramètre, sans type de retour et de les exécuter. Les tests sont considérés réussis si la sortie est prévue et en échec dans les autres cas. Ils peuvent être exécutés en n'encombrant pas le code source et en n'aectant pas sa performance ou sa taille. Comme notre environnement d'implémentation est Java, nous avons réalisé une série de tests d'unité à l'aide de JUnit, un simple framework de test d'unité qui fait partie de l'architecture xunit. Les bases de données de travail consistent en : Une simple séquence de sept éléments (2, 4, 6, 8, 10, 12, 14), Un extrait de la base de données example.xml. Voici une description des tests principaux pour le premier type de base de données : Une requête de type fenêtre disjointe avec l'absence de WindowEndCondition. Une requête de type fenêtre disjointe, la clause WindowEndCondition est présente. Le test consiste à vérier la variable de travail VarName. Une requête de type fenêtre disjointe, la clause WindowEndCondition est présente. Le test consiste à vérier les variables positionnelles positionalvar. Une requête de type fenêtre disjointe, la clause WindowEndCondition est présente. Le test consiste à vérier les variables currentvar. Une requête de type fenêtre disjointe, la clause WindowEndCondition est présente. Le test consiste à vérier les variables nextvar. Une requête de type fenêtre disjointe, la clause WindowEndCondition est présente. Le test consiste à vérier les variables previousvar. Une requête de type fenêtre disjointe, les clauses WindowEndCondition et Orderby- Clause sont présentes. Une requête de type fenêtre disjointe, les clauses WindowEndCondition et LetClause sont présentes. Une requête de type fenêtre glissante. ReturnClause est imbriquée avec ForClause. Une requête de type fenêtre glissante, LetClause est présente. Voici une description des tests principaux pour le deuxième type de base de données : Une requête de type fenêtre disjointe, les clauses WindowEndCondition et Orderby- Clause sont présentes. ReturnClause construit de nouveaux éléments. Une requête de type fenêtre disjointe, la clause WindowEndCondition est présente. Le test consiste à vérier que les noms des variables sont diérents. Une requête de type fenêtre disjointe, les clauses WindowEndCondition et WhereClause sont présentes. Une requête de type fenêtre disjointe, la clause WindowEndCondition est présente. 62

69 ReturnClause est imbriquée avec une ForClause. 7.6 Scénario Nous avons passé en détail les explications de l'implémentation de la syntaxe de fenêtrage dans la base de données exist. Nous obtenons donc son fonctionnement. Ce qui nous permet de l'étudier à l'aide d'exemples concrets. Ceux-ci sont pris du site de XQuery 1.1 [49] et capables de satisfaire nos besoins. Chacun d'eux sera étudié successivement via deux niveaux de développement : le général et l'approfondi techniquement Fenêtre disjointe for tumbling window $w in (2, 4, 6, 8, 10, 12, 14) start at $s when fn:true() end at $e when $e - $s eq 2 return <windo>{ $w }</windo> Explication générale Remarquons d'abord que la requête est de type fenêtre disjointe, ce qui revient à dire que les fenêtres résultats seront distinguées. A partir de la séquence d'entrée, les éléments sont successivement passés aux conditions de la clause WindowStartCondition et ensuite de la clause WindowEndCondition. La première fenêtre est ouverte avec son premier élément 2, puisque la condition de WindowStartCondition est vraie dans tous les cas. Tant que la fenêtre est ouverte et que la condition de WindowEndCondition reste non satisfaite, les éléments de la séquence d'entrée seront rajoutés à la fenêtre courante. Cette dernière est donc élargie avec l'élément 4, et ensuite 6 qui la termine puisqu'il satisfait la condition de WindowEndCondition. La première fenêtre déterminée est donc : (2, 4, 6). Une fois que la fenêtre courante est terminée, nous pouvons alors ouvrir une nouvelle fenêtre. Cette dernière sera créée avec son premier élément 8. Elle sera agrandie jusqu'à l'élément 12 qui rendra la condition de WindowEndCondition vraie. La deuxième fenêtre déterminée est donc : (8, 10, 12). De même, la troisième fenêtre est créée avec l'élément 14 qui est le dernier élément de la séquence d'entrée. La troisième fenêtre déterminée est donc : (14). Nous pouvons maintenant terminer l'exécution et renvoyer l'ensemble de fenêtres au terminal. Voici le résultat obtenu : <windo>2 4 6</windo> <windo> </windo> 63

70 <windo>14</windo> Explication technique L'entièreté de la requête est d'abord analysée en se basant sur la grammaire qui est décrite dans XQuery.g. Les tokens sont ensuite déterminés pour garantir la bonne syntaxe de la structure. Si jamais il existe au moins un token qui n'est pas prévu, une erreur sera déclenchée au niveau du parseur. Ainsi, l'arbre syntaxique abstrait intermédiaire est construit et passé à la phase suivante, dénie dans XqueryTree.g. Celle-ci permettant de transformer la requête aux objets prédénis. A ce moment, le type de requêtes donc fenêtrage et le type de fenêtres donc fenêtre disjointe sont déterminés. Par conséquent, un objet WindowExpr est créé en prenant en compte son contexte. De même, la variable de travail w ainsi que les variables positionnelles s et e sont dénies et passées à l'objet. Les deux conditions de WindowStartCondition et WindowEndCondition sont également prises en compte et les deux objets WindowCondition correspondants sont créés. La méthode analyze de WindowExpr est ensuite appelée an de déclarer les variables de travail qui sont w, s et e dans ce cas. Ainsi, un test impose, à ce moment, la vérication de noms distincts des variables de fenêtrage. Si toutes les conditions sont bien respectées, nous pouvons désormais passer à l'étape de construction des fenêtres résultats. Celle-ci sera réalisée par la méthode eval de WindowExpr. Cette méthode est appelée au travers de classes prédénies illustrée à la gure 7.3. La variable de travail w est maintenant passée à la variable windowvar. Les variables positionnelles s, e sont passées respectivement au vecteur positionalvariables indexé 0 et 1. La séquence d'entrée (2, 4, 6, 8, 10, 12, 14) est dénie et passée à windowvar. Une boucle for parcourant élément par élément de la séquence d'entrée est établie. A chaque tour, la position du premier et dernier élément de la fenêtre sont dénies, à savoir startposition et endposition. Nous pouvons les considérer comme des compteurs de travail permettant de déterminer la valeur des conditions booléennes. Comme nous sommes en type fenêtre disjointe, deux cas sont apparus : avec ou sans WindowEndCondition. Il est clair dans ce cas que la deuxième option est prise. Si aucune fenêtre n'est ouverte, startposition et endposition prennent la valeur du compteur p, donc 0 qui indique le premier élément 2 de la séquence d'entrée. Les variables positionnelles sont mises à jour en se basant sur startposition et endposition. Elles sont égales à 1 dans un premier temps. Ensuite, la méthode add de WindowValueSequenceTable est appelée, en lui passant comme paramètre l'élément à rajouter et sa position dans la séquence d'entrée. Les deux conditions seront évaluées en premier an de connaître leurs valeurs. La première est toujours vraie dans tous les cas, quant à la deuxième, sa valeur dépend de celle des variables positionnelles. Elle sera vraie si $e - $s eq 2, or 1 1 = 0, ce qui, dans ce cas, la rend fausse. La clause WindowStartCondition étant vraie, startitem 64

71 Figure 7.3 Chemin permettant accéder à eval. étant égal à null et aucune fenêtre ouverte auparavant n'existant, nous sommes sur le point d'ouvrir la première fenêtre avec l'élément 2 en retenant sa position. Cette dernière sera ensuite rajoutée à windowsequence qui est un objet de WindowValueSequenceTable. La condition de la clause WindowEndCondition étant fausse, nous ne faisons rien et nous passons à l'élément suivant, donc 4. Désormais, startposition prend la position du premier élément de la fenêtre courante, donc 0, et endposition prend la valeur du compteur p, donc 1. Les variables s et e sont égales à 1 et 2 respectivement. Ce qui donne comme résultat pour deux conditions WindowStartCondition et WindowEndCondition : (vrai, faux). Ce résultat amène à rajouter simplement cet élément à la fenêtre courante. Pour l'élément suivant, le 6, les variables positionnelles s et e ont respectivement les valeurs suivantes : (1, 3), ce qui rend les deux conditions vraies. Cette fois l'élément 6 est rajouté à la fenêtre courante et il termine également cette dernière, et ainsi de suite. En résumé, l'exécution peut être récapitulée par le tableau suivant : 65

72 Élément s et e start et end clause Fenêtres construites 2 (1,1) (vrai,faux) {(2)} 4 (1,2) (vrai,faux) {(2,4)} 6 (1,3) (vrai,vrai) {(2,4,6),} 8 (4,4) (vrai,faux) {(2,4,6),(8)} 10 (4,5) (vrai,faux) {(2,4,6),(8,10)} 12 (4,6) (vrai,vrai) {(2,4,6),(8,10,12),} 14 (7,7) (vrai,faux) {(2,4,6),(8,10,12),(14)} Après avoir obtenu la séquence de fenêtres stockées dans l'objet windowsequence, ces fenêtres sont renvoyées successivement au terminal Fenêtre glissante Cette fois, nous nous intéressons au type fenêtre glissante, un exemple similaire [49] est choisi an d'illustrer son exécution. for sliding window $w in (2, 4, 6, 8, 10, 12, 14) start at $s when fn:true() end at $e when $e - $s eq 2 return <windo>{ $w }</windo> Explication générale Comme le type fenêtre disjointe, les éléments de la séquence d'entrée sont successivement passés aux conditions de WindowStartCondition et WindowEndCondition. Cette fois nous pouvons avoir plusieurs fenêtres ouvertes à la fois. En prenant le premier élément de la séquence d'entrée, donc le 2, nous ouvrons alors la première fenêtre. Pour l'élément suivant, donc le 4, deux choses se passent : une nouvelle fenêtre est créée avec l'élément 4 et ce dernier est également rajouté à la fenêtre existante, donc celle de l'élément 2. Ensuite, l'élément 6 provoque la création de la troisième fenêtre dont il est le premier élément. Ce dernier agrandit également la fenêtre de l'élément 4 et termine celle de l'élément 2, vu qu'il satisfait sa condition WindowEndCondition. En résumé, à cet instant, nous avons trois fenêtres, deux d'entre elles sont ouvertes et la troisième est terminée : {(2, 4, 6), (4,6), (6)}. De même, une nouvelle fenêtre est créée pour l'élément 8 et celui-ci est rajouté également à deux fenêtres ouvertes, et ainsi de suite. Finalement, nous obtenons un résultat comme suit : {(2, 4, 6), (4, 6, 8), (6, 8, 10), (8, 10, 12), (10, 12, 14), (12, 14), (14)}. Voici le résultat en XML : <windo>2 4 6</windo> 66

73 <windo>4 6 8</windo> <windo>6 8 10</windo> <windo> </windo> <windo> </windo> <windo>12 14</windo> <windo>14</windo> Explication technique Tout reste similaire au niveau de l'analyse syntaxique, de la transformation aux objets et de la déclaration des variables pour ce type de fenêtres. Nous nous intéressons dans ce cas à la façon dont les objets fenêtres sont construits. Comme discuté précédemment, nous avons besoins d'un vecteur startpositions pour stocker toutes les positions du premier élément des fenêtres ouvertes et des deux variables de travail : startposition et endposition. La tâche qui consiste à mettre à jour les diérents types de variables de fenêtrage est séparée de la clause WindowStartCondition et la clause WindowEndCondition. Pour le premier élément 2, la condition de WindowStartCondition est vraie. La première fenêtre est générée avec cet élément. La position de celui-ci est mise au vecteur startpositions. La fenêtre récemment créée est rajoutée à windowsequence. Passons au deuxième élément, donc le 4. De même, une nouvelle fenêtre est créée pour cet élément, et sa position est également rajoutée au vecteur startpositions. Une boucle est établie pour parcourir chaque élément de startpositions an d'évaluer la condition de WindowEndCondition. Au premier tour, les valeurs des variables positionnelles s et e sont respectivement égales à 1 et 2, ce qui rend la condition de WindowEndCondition fausse. Nous rajoutons simplement 4 à la fenêtre de l'élément 2. Le deuxième tour de la boucle correspond à la fenêtre de l'élément 4, mais rien se passe, comme la condition de WindowEndCondition est également fausse avec les valeurs (2, 2) de (s, e). Nous abordons le troisième élément 6. Une nouvelle fenêtre est également créée pour lui, ce qui agrandit la taille du vecteur startpositions à 3. Au premier tour, la valeur de (s, e) étant égale à (1, 3) rend la condition de WindowEndCondition vraie. Ce qui permet non seulement de rajouter l'élément 6 à la fenêtre de l'élément 2 mais de terminer également cette fenêtre en marquant -1 à sa position dans le vecteur startpositions. Pareillement, l'élément 6 est rajouté, au deuxième tour de la boucle, à la fenêtre de l'élément 4 et ainsi de suite. L'exécution de la requête est récapitulée via le tableau ci-dessous : 67

74 Élt s et e start et end Fenêtres construites 2 (1,1) (vrai,faux) {(2)} 4 (1,2) (vrai,faux) {(2,4),(4)} (2,2) (vrai,faux) {(2,4),(4)} 6 (1,3) (vrai,vrai) {(2,4,6),(4),(6)} (2,3) (vrai,faux) {(2,4,6),(4,6),(6)} (3,3) (vrai,faux) {(2,4,6),(4,6),(6)} 8 (2,4) (vrai,vrai) {(2,4,6),(4,6,8),(6),(8)} (3,4) (vrai,faux) {(2,4,6),(4,6,8),(6,8),(8)} (4,4) (vrai,faux) {(2,4,6),(4,6,8),(6,8),(8)} 10 (3,5) (vrai,vrai) {(2,4,6),(4,6,8),(6,8,10),(8),(10)} (4,5) (vrai,faux) {(2,4,6),(4,6,8),(6,8,10),(8,10),(10)} (5,5) (vrai,faux) {(2,4,6),(4,6,8),(6,8,10),(8,10),(10)} 12 (4,6) (vrai,vrai) {(2,4,6),(4,6,8),(6,8,10),(8,10,12),(10),(12)} (5,6) (vrai,faux) {(2,4,6),(4,6,8),(6,8,10),(8,10,12),(10,12),(12)} (6,6) (vrai,faux) {(2,4,6),(4,6,8),(6,8,10),(8,10,12),(10,12),(12)} 14 (5,7) (vrai,vrai) {(2,4,6),(4,6,8),(6,8,10),(8,10,12),(10,12,14),(12),(14)} (6,7) (vrai,faux) {(2,4,6),(4,6,8),(6,8,10),(8,10,12),(10,12,14),(12,14),(14)} (7,7) (vrai,faux) {(2,4,6),(4,6,8),(6,8,10),(8,10,12),(10,12,14),(12,14),(14)} 7.7 Conclusion Ce chapitre explique en détail la mise en uvre de la clause de fenêtrage, plus précisément les deux types de fenêtrage : fenêtre disjointe et fenêtre glissante, dans la base de données exist. En eet, la grammaire et le code existant d'exist ont été étudiés et modiés ainsi qu'une série de nouvelles classes y ont été ajoutées. Ceci an d'adapter au mieux cette nouvelle syntaxe dans exist. Plusieurs tests d'unité ont également été réalisés an d'assurer le bon fonctionnement du nouveau programme. Pour illustrer le déroulement du système renouvelé, le scénario de deux requêtes spéciques pour fenêtre disjointe et fenêtre glissante a été introduit. Suite à cette expérience, deux niveaux de développement d'une requête de fenêtrage ont été étudiés : avec ou sans détail technique. Cependant, avec un délai restreint, dans un cadre de stage, le travail n'arrive pas à compléter toute la syntaxe de fenêtrage. Les points suivants peuvent encore être développés : 1. Les fenêtres fournies en résultat ne sont pas en ordre, ceci est à cause de l'utilisation de HasMap pour les stocker. 2. L'option only dans la clause WindowEndCondition n'est pas encore réalisée, ceci est dû à une erreur qui s'est produite durant le stage, au niveau du parseur. 68

75 3. WindowClause fonctionne seule mais pas en se combinant avec ForClause et LetClause. Pour obtenir leur association, il faut que nous adaptions le cas de WindowClause dans les deux classes LetExpr et ForExpr. 69

76 Chapitre 8 Résultats expérimentaux 8.1 Introduction Après avoir introduit et implémenté la syntaxe WindowClause, nous allons réaliser dans ce chapitre un banc d'essai pour tester la performance du système, an d'en tirer des conclusions pratiques. Ce sont des tests exécutés sur des bases de données de tailles diérentes et qui mesurent le temps d'exécution des diérents types de requêtes. Ce qui permet de faire une comparaison, non seulement entre les divers types de requêtes mais aussi entre les multiples dimensions des bases de données. 8.2 Générateur Données de travail Pour pouvoir eectuer notre analyse, nous avons besoin de créer un ensemble de bases de données dans lesquelles nous allons travailler. Elles sont générées de manière automatique, à l'aide d'un simple code de Java écrit dans l'environnement Eclipse version 3.4 sous le Java Development Kit version 6. Il s'agit, pour chacune d'elles, d'un ensemble d'éléments dont le cardinal permet de déterminer sa dimension. Ces éléments sont les nombres naturels classés dans l'ordre croissant à partir de zéro. Un exemple de base de données est illustré à la gure 8.1. Par conséquent, nous disposons de quatre bases de données de l'ordre de grandeur suivant : Collection Nombre d'éléments 1K.xml K.xml K.xml K.xml

77 <?xml version="1.0" encoding="utf-8"?> <doc> <item>0</item> <item>1</item> <item>2</item> <item>3</item> <item>4</item> <item>5</item>... </doc> Figure 8.1 Exemple de base de données Requêtes Désormais, les bases de données sont prêtes à servir. Il ne nous reste maintenant qu'à dénir les diérents types de requêtes que nous allons examiner. Il apparaît évident que deux requêtes qui nous viennent à l'esprit en premier sont destinées aux types de fenêtres que nous avons discuté à la section 4.3. Ceci nous permet d'étudier si deux manières diérentes de générer des fenêtres se comportent diéremment, compte tenu de la performance. D'autre part, lorsque nous sommes dans le type fenêtre disjointe, rappelons que d'après la dénition de sa syntaxe, la clause WindowEndCondition peut être absente. Il est alors intéressant dans cette situation, de pouvoir étudier le temps d'exécution lorsque la clause WindowEndCondition est omise et lorsqu'elle ne l'est pas. De plus, durant le processus d'exécution, nous avons constaté que la présence d'un modulo peut aecter le temps d'exécution de la requête pour une collection particulière. Par exemple, ces deux requêtes ci-dessous travaillent sur une même base de données et renvoient le même résultat. La seule diérence entre elles est que, l'une utilise le modulo pour évaluer l'expression booléenne et l'autre d'autres opérateurs mathématiques que le modulo : for tumbling window $w in doc("mycollection.xml")//item start $first when fn:true() end $last when $last mod 2 = 1 return <windo>{$w}</windo> for tumbling window $w in doc("mycollection.xml")//item start $first when fn:true() end $last when $last - $first eq 1 return <windo>{$w}</windo> 71

78 Nous avons constaté que le résultat obtenu par ces deux requêtes présente une différence au niveau du temps d'exécution. Plus précisément, celle utilisant le modulo, a tendance à fournir un résultat plus rapide que l'autre. Dès lors, il est intéressant d'examiner son comportement sur l'ensemble de collections. Nous créons donc un nouveau type de requêtes en prenant en compte le modulo. En conséquence, voici un tableau qui représente la liste des types de requêtes que nous allons étudier : TE TNE TNM S type de fenêtres est fenêtre disjointe avec la présence de WindowEndCondition et en utilisant le modulo. type de fenêtres est fenêtre disjointe avec l'absence de WindowEndCondition et en utilisant le modulo. type de fenêtres est fenêtre disjointe avec la présence de WindowEndCondition, le modulo n'est pas utilisé. type de fenêtres est fenêtre glissante, le modulo n'est pas utilisé. En outre, la taille de la fenêtre peut-elle entraîner une inuence particulière sur la performance du système?. An d'y répondre, chaque type de requêtes discuté précédemment, va être exécuté en générant des fenêtres de tailles diérentes. A cet eet, nous avons créé explicitement un ensemble de cinq tailles distinctes qui sont successivement : T2, T4, T8, T16, T32, avec comme exemple T2 représentant le cardinal deux de la fenêtre. Par conséquent, l'ensemble de 4x5 requêtes vont être étudiées successivement sur notre ensemble de quatre bases de données. Nous avons donc approximativement une collection de 80 requêtes, dont chacune est lancée selon un type particulier, en générant des fenêtres de taille précise et en s'exécutant sur une base de données de dimension spécique. Une illustration globale est représentée au tableau Analyse de données Après avoir conçu les bases de données ainsi que les requêtes nécessaires à réaliser le banc d'essai, nous arrivons désormais à les implémenter. Pour pouvoir calculer le temps d'exécution de ces requêtes, des scripts écrits en Python ont été construits. Leur tâche consiste premièrement à se connecter au serveur d'exist. Ceci est réalisé par le biais du module XML-RPC [3] fourni par Python. Ce dernier est eectivement un protocole RPC (Remote Procedure Call) permettant à un client d'eectuer des méthodes paramétrables sur un serveur à distance, au travers du protocole HTTP et en recevant des données en retour. Par la suite, l'ensemble de requêtes choisies vont être réalisées plusieurs fois, an de calculer leur temps d'exécution (voir le tableau 8.2). Plus précisément, chaque requête va être lancée n fois de suite, ensuite son temps d'exécution nal sera calculé en prenant 72

79 TE1 T2 T4 T8 T16 T32 TNE1 T2 T4 T8 T16 T32 TNM1 T2 T4 T8 T16 T32 S1 T2 T4 T8 T16 T32 TE10 T2 T4 T8 T16 T32 TNE10 T2 T4 T8 T16 T32 TNM10 T2 T4 T8 T16 T32 S10 T2 T4 T8 T16 T32 TE50 T2 T4 T8 T16 T32 TNE50 T2 T4 T8 T16 T32 TNM50 T2 T4 T8 T16 T32 S50 T2 T4 T8 T16 T32 TE100 T2 T4 T8 T16 T32 TNE100 T2 T4 T8 T16 T32 TNM100 T2 T4 T8 T16 T32 S100 X X X X X 1K 10K 50K 100K Table 8.1 Une collection de requêtes. Types de requêtes 1K 10K 50K 100K TE TNE TNM S X Table 8.2 Nombre d'exécutions pour chaque type de requêtes, sur chaque taille de base de données. la moyenne de n 1 derniers résultats. La raison pour laquelle nous ne prenons pas le premier résultat est qu'il faut négliger le temps où le système met en cache des données et le temps où la connexion au serveur doit s'établir, etc. Le tout a pour but d'obtenir le temps le plus réaliste possible. En conséquence, les temps d'exécution des requêtes, après avoir été calculés, sont réorganisés et stockés dans un chier particulier qui va servir ultérieurement comme données pour Gnuplot version 4.4 [30] : un outil de représentation graphique de données distribué sous une licence de logiciel libre. Finalement, les tests sont réalisés sur un processeur Intel Core 2 Duo T7300, cadencé à 2.00 GHz, 2GB de mémoire RAM, tourné sous le système d'exploitation Window Vista Home Premium et la version Python utilisée est celle de

80 8.3.1 Collection simple An d'avoir une vue locale sur des comportements distincts des types de requêtes cités plus haut à la section 8.2.2, les tests seront eectués successivement sur les diérentes bases de données dans l'ordre croissant de leur dimension. En plus, chaque propriété sera représentée en faisant varier la taille de la fenêtre. Ceci nous ore donc une vue globale sur le temps d'exécution au travers de tailles diérentes de la fenêtre Modèle avec et sans WindowEndCondition Nous avons discuté à la section que le type fenêtre disjointe nous ore la possibilité d'omettre la clause WindowEndCondition. Ainsi, dans ce cas, la clause WindowStartCondition prend à la fois deux rôles importants : déterminer non seulement le début mais également la n d'une fenêtre. Bien que nous arrivons aux cas, où le fait que la clause WindowEndCondition est absente ou non, n'aecte pas le résultat nal. Ceci suscite la question : cette absence peut-elle causer une inuence au niveau de la performance du système?. Pour la mise en oeuvre du test, nous avons créé explicitement deux types de requêtes, l'un supporte la présence de WindowEndCondition et l'autre non. Un exemple de ces deux types de requêtes, pour générer une fenêtre de taille deux, est illustré successivement aux gures 8.2 et 8.3, où mycollection représente la collection sur laquelle nous sommes en train de travailler. for tumbling window $w in doc("mycollection.xml")//item start $first when fn:true() end $last when $last mod 2 = 1 return <windo>{$w}</windo> Figure 8.2 Requête avec WindowEndCondition. for tumbling window $w in doc("mycollection.xml")//item start $first when $first mod 2 = 0 return <windo>{$w}</windo> Figure 8.3 Requête sans WindowEndCondition. Collection 1K Nous abordons en premier, le test sur la collection dont la dimension est la plus petite, autrement dit l'ensemble de 1000 éléments. Il est évident que les deux types de requêtes cités ci-dessus, vont générer les mêmes nombres de fenêtres résultats, et ceux-ci restent 74

81 Taille de la fenêtre T2 T4 T8 T16 T32 Nombre de fenêtres Table 8.3 Nombres de fenêtres résultats - 1K. vrais pour chaque taille diérente de la fenêtre. Le nombre exact de fenêtres produit par ces deux types de requêtes correspondant à une taille particulière de la fenêtre, est représenté au tableau 8.3. Remarquons que du fait de la propriété fournie par le type fenêtre disjointe, signie qu'on génère des fenêtres complètement distinctes : une nouvelle fenêtre ne peut être créée qu'une fois que la précédente se termine. Le résultat obtenu au tableau 8.3 sur les nombres de fenêtres apparaît alors cohérent, puisqu'en doublant à chaque fois la taille de la fenêtre, le nombre de fenêtres générées correspondant est divisé par deux. Ceci peut être représenté formellement comme ci-dessous : Nombre de fenêtres T i = Nombre de fenêtres T i 2 2 où i = 4, 8, 16, 32 Pour calculer i = 2, il sut de remplacer le numérateur de la formule ci-dessus par le nombre total des éléments de l'ensemble. 60 Tumbling window, avec et sans end clause, 1K Avec End Clause Sans End Clause 55 Temps (ms) T2 T4 T8 T16 T32 Taille de la fenêtre Une représentation graphique des types de requêtes avec et sans WindowEndCondition sur l'ensemble de données 1K est illustrée ci-dessus. En l'examinant, nous constatons que le temps d'exécution sans WindowEndCondition est nettement inférieur à celui avec 75

82 WindowEndCondition. Ceci est vrai quelque soit la taille de la fenêtre. Plus précisément, le rapport entre le type de requêtes avec WindowEndCondition et sans WindowEndCondition est de l'ordre de 1,098. Collection 10K Taille de la fenêtre T2 T4 T8 T16 T32 Nombre de fenêtres Table 8.4 Nombres de fenêtres résultats - 10K. Eectuons ce même test sur l'ensemble de données 10K. Ainsi, un tableau représentant le nombre de fenêtres résultats correspondant à chaque taille de la fenêtre a été établi au tableau 8.4. Nous pouvons remarquer qu'il n'est pas dicile de calculer ces nombres de fenêtres. Il sut de multiplier par dix le résultat donné à la collection 1K (sans prendre leur plafond), an de les obtenir. Il ne nous reste maintenant qu'à tracer le graphique selon les données calculées. Ce dernier est représenté ci-après : 600 Tumbling window, avec et sans end clause, 10K Avec End Clause Sans End Clause 550 Temps (ms) T2 T4 T8 T16 T32 Taille de la fenêtre Nous obtenons le même résultat que celui de 1K. En eet, nous observons que les temps d'exécution correspondants à cinq tailles de la fenêtre de type sans WindowEndCondition se trouvent complètement en-dessous de ceux de type avec WindowEndCondition. Si nous calculons la diérence de ces deux types au niveau du temps d'exécution pour chaque taille de la fenêtre et prenons la moyenne de ces résultats, nous obtenons alors une moyenne de 47,938 ms. Le rapport entre le type TE et TNE est de l'ordre de 1,

83 Ce qui prouve clairement une augmentation par rapport à ce que nous avons obtenu à la collection 1K. Collection 50K Comme il apparaît une croissance du taux de rapport entre TE et TNE à la collection 10K, il est intéressant d'examiner davantage au niveau de la dimension de données an de voir si ce type de comportement reste stable. Nous abordons donc l'ensemble 50K. A nouveau, le tableau représentant le nombre de fenêtres résultats correspondant à chaque taille de la fenêtre, est fourni au tableau 8.5. Taille de la fenêtre T2 T4 T8 T16 T32 Nombre de fenêtres Table 8.5 Nombres de fenêtres résultats - 50K. Nous gardons toujours le même raisonnement pour le calcul de ces nombres de fenêtres, sauf que cette fois, ils sont chacun multipliés par cinq par rapport à ceux de la collection 10K. Ainsi, le graphique correspondant à cet ensemble de données, est représenté ci-dessous : 2800 Tumbling window, avec et sans end clause, 50K Avec End Clause Sans End Clause 2600 Temps (ms) T2 T4 T8 T16 T32 Taille de la fenêtre La courbe représentant le type de requêtes TNE cette fois se trouve à nouveau inférieure à celle de type TE. Le rapport entre TE et TNE a été calculé et il vaut 1,078. La moyenne des diérences entre ces deux types est de 181,24 ms, ce qui donne approximativement 4 fois celle de la collection 10K. Par conséquent, nous constatons que le 77

84 comportement de ces deux types de requêtes dans cette dimension de base de données, reste cohérent. Conclusion L'étude sur les trois collections pour comparer la performance entre le type de requêtes avec WindowEndCondition et celui sans WindowEndCondition nous a permis de tirer une même conclusion : une requête, en utilisant la clause WindowEndCondition, prend plus de temps par rapport à celle qui ne l'utilise pas. Nous avons également lancé le test sur l'ensemble 100K pour vérier si ce phénomène persiste toujours. Nous acquérons un rapport de l'ordre 1,07 entre TE et TNE. Ceci permet de renforcer la conclusion obtenue. Cette dernière n'est pas dicile à comprendre. Avec le modèle sans WindowEndCondition, chaque fenêtre est créée en se basant complètement sur WindowStartCondition de la requête. Ceci permet de ne pas prendre en compte l'évaluation de la condition booléenne pour déterminer le dernier élément de chaque fenêtre, qui possède un temps non négligeable (voir section suivante). La requête prend donc moins de temps à être exécutée Modèle avec et sans modulo Au fur et à mesure que nous travaillons avec des requêtes, nous avons remarqué un phénomène concernant l'utilisation ou non de modulo qui peut amener un eet sur leur temps d'exécution. Ainsi, nous avons lancé un nouveau test de comparaison entre deux types de requêtes qui supportent la clause WindowEndCondition, dont l'un utilise le modulo (illustré à la gure 8.2 pour l'exemple de génération de fenêtres de taille deux) et l'autre pas (illustré à la gure 8.4). Ceux-ci génèrent un même nombre de fenêtres résultats pour chaque taille de la fenêtre. De même, nous avons eectué ce test sur les trois ensembles de données : 1K, 10K, 50K dont les nombres de fenêtres résultats correspondants à chaque ensemble sont fournis respectivement au tableau 8.3, 8.4 et 8.5. for tumbling window $w in doc("mycollection.xml")//item start $first when fn:true() end $last when $last - $first eq 1 return <windo>{$w}</windo> Figure 8.4 Requête sans mode modulo. 78

85 Collection 1K Nous discutons d'abord la première collection. La représentation graphique de cette dernière est la suivante : 80 Tumbling window, avec et sans modulo, 1K Avec Modulo Sans Modulo 70 Temps (ms) T2 T4 T8 T16 T32 Taille de la fenêtre Il apparaît en premier que tous les résultats de type TE sont en-dessous de ceux de type TNM. Le rapport entre TNM et TE est de l'ordre de 1,266. Ce rapport permet d'avoir une idée positive de notre remarque. En plus, la représentation graphique permet de tirer une conclusion temporaire : une requête, en utilisant le mode modulo pour eectuer son travail est plus rapide que lorsqu'elle ne l'utilise pas. Ce qui signie que l'évaluation de l'expression booléenne dans les deux clauses WindowStartCondition et WindowEndCondition apporte une complexité qui n'est pas du tout négligeable. Notamment, l'opérateur modulo donne un temps d'exécution favorable dans ce cas. Néanmoins, cette conclusion reste encore à conrmer. Nous allons donc l'examiner par la suite dans les collections de tailles plus grandes. Collection 10K Pour vérier notre conclusion, nous avons continué notre test sur la deuxième collection, l'ensemble 10K. Voici la représentation graphique de données obtenues : 79

86 750 Tumbling window, avec et sans modulo, 10K Avec Modulo Sans Modulo Temps (ms) T2 T4 T8 T16 T32 Taille de la fenêtre Cette fois, en regardant le graphique, il est clair que le temps nécessaire à exécuter la requête de type TE est nettement plus rapide que celui de type TNM. Ceci en raison des cinq points correspondants aux tailles de la fenêtre de type TE se trouvant complètement en-dessous de ceux de type TNM. Le rapport entre TNM et TE maintenant s'élève à 1,376. Ce qui signie que nous avons même gagné un ordre de 0,11 pour ce rapport, dans cette collection 10K. Collection 50K L'étude de la collection 10K nous a fourni un résultat intéressant qui porte sur la croissance du rapport entre TNM et TE. An de justier notre conclusion donnée à la collection 1K, nous passons à celle 50K. La représentation graphique correspondante à cette collection est illustrée ci-dessous. Encore une fois, nous obtenons le même comportement par rapport aux collections précédentes. En regardant le graphique, la diérence au niveau du temps d'exécution entre les deux types TE et TNM est nettement représentée. Plus précisément, le rapport entre TNM et TE est de l'ordre de 1,368 et pour l'ensemble 100K, celui-ci est de l'ordre de 1,418. Ce qui signie qu'il ne fait que croître. 80

87 Tumbling window, avec et sans modulo, 50K 3600 Avec Modulo Sans Modulo Temps (ms) T2 T4 T8 T16 T32 Taille de la fenêtre Conclusion Suite aux expériences eectuées sur les diérents ensembles de données, nous concluons qu'en utilisant la requête avec le mode modulo, celle-ci s'exécute en moins de temps. Ceci signie que le temps portant sur l'évaluation des expressions booléennes est signicatif. Nous pouvons l'expliquer, en supposant que dans le système existant d'exist, le calcul portant sur le modulo est évalué de manière eciente par rapport aux autres calculs. Utiliser le modulo pour déterminer la fenêtre, ore un avantage au niveau de la performance Modèle de types de fenêtres Comme nous avons discuté à la section 8.2.2, un des tests les plus intéressants est de comparer le type fenêtre disjointe au type fenêtre glissante, en fonction du temps d'exécution. Selon la propriété diérente fournie par chacun des types de fenêtres, ils sont donc implémentés de manière diérente. Ce qui mène à une complexité propre à chaque type. Avec le type fenêtre disjointe, chaque élément de la séquence d'entrée est traité une seule fois. Autrement dit, étant donné n, le nombre d'éléments fournis en input, la complexité de ce type de fenêtres sera donc en O(n). Par contre, avec le type fenêtre glissante, ceci ne se vérie plus. En eet, un élément peut être repassé plusieurs fois jusqu'au moment où il est retiré du vecteur startpositions. Autrement dit, jusqu'au moment où la fenêtre dont il est le premier élément, est fermée. Etant donné m, la taille du vecteur startpositions tel que 0 m n, la complexité de ce type de fenêtres sera 81

88 donc en O(mn). En pratique, nous avons réalisé un test sur les deux types de requêtes tels que TNM, illustré à la gure 8.4, et S, illustré à la gure 8.5, au travers de diérentes collections de données. for sliding window $w in doc("mycollection.xml")//item start $first when fn:true() end $last when $last - $first eq 1 return <windo>{$w}</windo> Figure 8.5 Requête de type fenêtre glissante. Collection 1K Pour commencer, nous abordons le test sur la première collection. Et voici la représentation graphique obtenue : 2000 Tumbling window et Sliding window, 1K Tumbling Window Sliding Window Temps (ms) T2 T4 T8 T16 T32 Taille de la fenêtre A la première observation, nous constatons que les temps d'exécution des cinq tailles diérentes de la fenêtre de type TNM, sont tous nettement inférieurs à ceux de type S. Le rapport entre S et TNM est de l'ordre de 11,98. Ce qui représente une des plus grandes valeurs obtenue actuellement. D'autre part, nous constatons clairement que par rapport au type S, le temps d'exécution de type TNM ne dépend presque pas de la taille de la fenêtre qu'il génère. En eet, nous obtenons, pour ce type de requêtes, une courbe presque rectiligne. Quant au type S, la courbe tracée est approximativement exponentielle dans l'ordre croissant de la taille de la fenêtre. Plus précisément, le rapport entre un point 82

89 de la courbe et son précédent a la plus petite valeur de 1,78 et la plus grande de 2,025. Ce qui permet de tirer une conclusion à vérier : la complexité de type fenêtre glissante dépend de la taille de la fenêtre générée. Collections 10K et 50K Par la suite, notre test est également eectué sur les collections 10K et 50K. Puisque la diérence en temps d'exécution entre ces deux types de fenêtres devient de plus en plus importante, nous allons les présenter sous une échelle logarithmique an d'assurer la visibilité. Les représentations graphiques correspondantes de ces deux collections sont les suivantes : Tumbling window et Sliding window, 10K Tumbling window et Sliding window, 50K Tumbling Window Sliding Window Tumbling Window Sliding Window Temps (ms) 2900 Temps (ms) T2 T4 T8 T16 T32 Taille de la fenêtre 3700 T2 T4 T8 T16 T32 Taille de la fenêtre A nouveau, nous obtenons à partir de ces graphiques une grande diérence au niveau du temps d'exécution de type S par rapport au type TNM. Ce dernier type apparaît clairement inférieur. Plus en détail, le rapport entre S et TNM cette fois est de 11,75 pour l'ensemble 10K et s'élève à 22,5 pour l'ensemble 50K. Ce chire ne fait qu'augmenter. La moyenne des diérences en temps d'exécution est de 7316,872 ms pour la collection 10K et elle est de 73420,446 ms pour la collection 50K. Ce qui signie que plus nous travaillons sur une base de données de grande taille, plus la diérence du temps d'exécution entre les deux types devient signicative. La courbe représentant les temps d'exécution de type S dans l'ordre croissant de la taille de la fenêtre semble tendre moins vers un ordre exponentiel, suite à ce que nous avons obtenu à la collection 1K. Plus précisément, pour l'ensemble 10K, le rapport entre un point et son précédent varie dans l'intervalle [1,32 ; 1,81] et pour l'ensemble 50K, dans l'intervalle [1,077 ; 1,508]. Notre conclusion est vériée dans ces deux collections. 83

90 Conclusion Les diérentes bases de données ayant subi le même test, nous constatons que : les rapports de ce modèle variant entre 11,75 et 22,5, sont plus importants qu'aux deux précédents, présentés aux sections , , qui eux varient entre 1 et 2. Ce qui signie que le temps d'exécution de type fenêtre disjointe est considérablement plus rapide que celui de type fenêtre glissante. En plus, en regardant les graphiques, le type fenêtre glissante présente une courbe croissante par rapport à la taille de la fenêtre. Quant au type fenêtre disjointe, nous obtenons une courbe presque droite. Ceci permet de justier que la complexité de type fenêtre glissante est importante et qu'elle dépend de la taille de la fenêtre générée Collections multiples Les tests que nous avons réalisés jusqu'à maintenant sont eectués séparément sur chaque ensemble de données, de taille diérente. Ceci nous permet d'avoir une vue locale en fonction de la collection. Dès lors, il est temps de considérer un test nous permettant d'avoir une vue globale sur l'ensemble des collections. Ainsi, nous avons choisi de mettre en oeuvre le test de comparaison de deux types de fenêtres, en raison des propriétés intéressantes que nous avons discutées à la section Pour construire ce modèle de test, tout d'abord, nous avons calculé la somme des temps d'exécution de type TNM et de type S, selon chaque taille diérente de la collection. Cette dernière est représentée via le tableau suivant : Taille de la collection 1K 10K 50K Fenêtre disjointe (ms) 316, , ,78 Fenêtre glissante (ms) 3797, , Remarquons que dans ce tableau, nous n'avons pas présenté les données correspondantes à la collection 100K pour le type fenêtre glissante, ceci à cause d'une erreur qui s'est produite lors de l'exécution de cette dernière. Nous nous sommes contentés d'expliquer que le temps d'exécution de la requête pour cette collection est trop grand et excède le temps admis par la classe RpcConnection d'exist. Voici une représentation graphique correspondante à ce modèle : 84

91 Tumbling window et Sliding window, temps total d exécution selon différentes tailles de BD Tumbling Window Sliding Window Temps total (ms) K 10K 50K Taille de BD En regardant ce graphique, nous constatons que les deux lignes correspondantes à deux types S et TNM, au travers d'ensembles de données, se trouvent nettement loin l'une de l'autre. Ce qui prouve que le temps d'exécution de type fenêtre glissante est toujours plus grand que celui de type fenêtre disjointe et que le temps d'exécution croît en augmentant la taille de l'ensemble de données quelque soit le type de fenêtrage. Encore une propriété intéressante à discuter : calculons le rapport du temps total d'exécution, lors du passage d'un ensemble de données vers le suivant pour les deux types S et TNM. Voici le tableau représentant le rapport entre les collections pour chaque type de fenêtres : Rapport des collections 10K/1K 50K/10K Fenêtre disjointe 10,734 5,0183 Fenêtre glissante 10,53 9,6 Si nous regardons en premier le type fenêtre disjointe, nous constatons que pour le passage de la collection 1K vers 10K, le rapport est approximativement de l'ordre de 10. Ce qui est parfaitement raisonnable vu que la taille de la base de données a augmenté d'un facteur 10. Nous obtenons le même résultat pour le passage de l'ensemble 10K vers celui de 50K, avec un facteur croissant de 5. Ceci explique que le temps d'exécution de type fenêtre disjointe est croissant linéairement par rapport à la taille de la base de données avec laquelle nous travaillons. D'un autre côté, nous observons que la situation n'est plus du tout la même pour le cas de fenêtre glissante. Plus précisément, nous obtenons un facteur de 10,53 pour le passage de l'ensemble 1K vers celui 10K, et, une augmentation jusqu'à 9,6 pour le passage de 10K vers 50K. Ce qui est approximativement le double du 85

92 premier. Ceci conrme encore une fois que, le temps d'exécution de type fenêtre glissante dépend non seulement de la taille de la base de données, mais encore de la taille de la fenêtre. 8.4 Conclusion Un banc d'essai a été réalisé dans ce chapitre sur plusieurs types de requêtes possibles et également sur les bases de données de tailles diérentes. Ceci nous permet de mieux comprendre le comportement de la nouvelle fonctionnalité de XQuery, à savoir le fenêtrage, lorsque ce dernier est intégré dans la base de données XML native libre exist. Plus précisément, nous remarquons les points suivants : L'absence de la clause WindowEndCondition permet une augmentation du temps d'exécution de la requête. Ceci a été illustré via un test de comparaison entre, d'une part une requête sans WindowEndCondition et d'autre part une requête avec WindowEndCondition, entrepris sur une séquence de bases de données dans l'ordre croissant de leur dimension. L'utilisation du modulo dans la condition booléenne, pour déterminer le début et la n d'une fenêtre, peut apporter un gain au niveau du temps d'exécution de la requête. Ceci montre que le temps d'exécution consacré à l'évaluation des expressions booléennes n'est pas du tout négligeable, puisque ce dernier peut accélérer aussi bien que ralentir signicativement le temps total d'exécution. De même, un test de comparaison a été réalisé sur les diérentes bases de données an de justier cette propriété. Et le cas le plus intéressant est celui de la comparaison entre deux types de fenêtres que supporte XQuery 1.1, à savoir fenêtre disjointe et fenêtre glissante. Après les résultats expérimentaux obtenus, le temps d'exécution de type fenêtre glissante est manifestement supérieur à celui de type fenêtre disjointe, qui possède une complexité linéaire de O(n). De plus, nous observons un phénomène de croissance approximativement exponentielle dans le cas de fenêtre glissante. Ce qui nous permet de conclure : le temps d'exécution de ce type de requêtes dont la complexité est en O(mn), augmente proportionnellement selon la dimension de la base de données et selon la taille de la fenêtre que génère la requête. 86

93 Chapitre 9 Conclusion Dans ce mémoire, nous avons étudié XML au chapitre 2 et un langage de requête spécique pour XML, à savoir XQuery au chapitre 3. Dès lors, la raison pour laquelle le fonctionnement de XQuery 1.0 n'est pas totalement apprécié est que ce dernier n'est pas encore équipé de propriétés importantes, tel que le fenêtrage. Cette dernière notion s'avère le sujet principal du mémoire et sa description a été abordée en détail au chapitre 4, pour les deux langages de requête telles que SQL et XQuery. Bien que dans le monde XML, XQuery joue un rôle similaire à SQL qui lui travaille dans le monde des bases de données relationnelles. Nous avons constaté que ces deux langages semblent dicilement traductibles de l'un vers l'autre, suite aux exemples des requêtes abordées au chapitre 5. L'inconvénient de l'absence de la fonctionnalité importante de XQuery, à savoir le fenêtrage, a mené à l'objectif du stage. Ceci consiste à combler XQuery par une implémentation de la syntaxe de fenêtrage dans exist, une base de données XML native qui a été discutée au chapitre 6. Plus précisément dans le chapitre 7, une série de modications ont été entreprises notamment au niveau sémantique et syntaxique du système exist. Ainsi, de nouvelles classes ont également été construites an d'adapter les deux types de fenêtres, fenêtre disjointe et fenêtre glissante, dans exist. Après l'intégration de la clause de fenêtrage dans exist, une séquence de tests d'unité ont été eectués en utilisant JUnit, an de justier le bon fonctionnement du système. Au chapitre 8, un banc d'essai a également été réalisé au travers de divers modèles. Après les résultats expérimentaux obtenus, nous avons constaté d'une part, que l'omission de la clause WindowEndCondition ainsi que l'utilisation du modulo dans les expressions booléennes peuvent inuencer signicativement le temps d'exécution de la requête ; et d'autre part, la complexité d'exécution de type fenêtre glissante est considérablement plus importante que celle de type fenêtre disjointe. En eet, le temps d'exécution de type fenêtre glissante dépend non seulement de la taille de la base de données dans laquelle il travaille mais encore de la taille de la fenêtre qu'il génère. Finalement, il est à noter toutefois que, dans le cadre de ce travail, une version complète du fenêtrage n'est pourtant pas encore réali- 87

94 sée. Dès lors, suite à ce mémoire, il nous reste encore des perspectives futures à explorer, tel que : Améliorer l'implémentation dans le cas fenêtre glissante, autrement dit, de trouver des moyens optimaux an de rendre l'exécution de ce type plus ecace. Synchroniser la clause de fenêtrage avec d'autres clauses telles que ForClause et LetClause, pour rendre la combinaison de ces clauses possible. Ajouter l'option only dans les deux types de fenêtres an d'enlever des fenêtres qui ne satisfont pas la condition booléenne de WindowEndCondition. 88

95 Annexe A Les uses case du test d'unité query = "for tumbling window $w in (2,4,6,8,10,12,14)"+ "start at $s when fn:true()"+ "return <windo>{ $w }</windo>"; result = service.query( query ); assertequals( "XQuery: " + query, 7, result.getsize() ); A.1 Une requête de type fenêtre disjointe avec l'absence de la clause Figure WindowEndCondition. query = "for tumbling window $w in (2,4,6,8,10,12,14)"+ "start at $s when $s mod 3 =1"+ "return <windo>{ $w }</windo>"; result = service.query( query ); assertequals( "XQuery: " + query, 3, result.getsize() ); Figure A.2 Une autre requête de type fenêtre disjointe avec l'absence de la clause WindowEndCondition. 89

96 query = "for tumbling window $w in (2,4,6,8,10,12,14)"+ "start at $s when fn:true()"+ "end at $e when $e - $s eq 2"+ "return <windo>{ $w }</windo>"; result = service.query(query ); assertxmlequal("<windo> </windo>",((XMLResource) result.getresource(0)).getcontent().tostring()); assertxmlequal("<windo>14</windo>", ((XMLResource) result.getresource(1)).getcontent().tostring()); assertxmlequal("<windo>2 4 6</windo>", ((XMLResource) result.getresource(2)).getcontent().tostring()); Figure A.3 Une requête de type fenêtre disjointe, la clause WindowEndCondition est présente. Le test consiste à vérier la variable de travail VarName. query = "for tumbling window $w in (2,4,6,8,10,12,14)"+ "start at $s when fn:true()"+ "end at $e when $e - $s eq 2"+ "return <windo>{$s,$e}</windo>"; result = service.query(query ); assertxmlequal("<windo>4 6</windo>", ((XMLResource) result.getresource(0)).getcontent().tostring()); assertxmlequal("<windo>7 7</windo>", ((XMLResource) result.getresource(1)).getcontent().tostring()); assertxmlequal("<windo>1 3</windo>", ((XMLResource) result.getresource(2)).getcontent().tostring()); Figure A.4 Une requête de type fenêtre disjointe, la clause WindowEndCondition est présente. Le test consiste à vérier les variables positionnelles positionalvar. 90

97 query = "for tumbling window $w in (2,4,6,8,10,12,14)"+ "start $first at $s when fn:true()"+ "end $last at $e when $e - $s eq 2"+ "return <windo>{$first,$last}</windo>"; result = service.query(query ); assertxmlequal("<windo>8 12</windo>", ((XMLResource) result.getresource(0)).getcontent().tostring()); assertxmlequal("<windo>14 14</windo>", ((XMLResource) result.getresource(1)).getcontent().tostring()); assertxmlequal("<windo>2 6</windo>", ((XMLResource) result.getresource(2)).getcontent().tostring()); Figure A.5 Une requête de type fenêtre disjointe, la clause WindowEndCondition est présente. Le test consiste à vérier les variables currentvar. query = "for tumbling window $w in (2,4,6,8,10,12,14)"+ "start at $s next $second when fn:true()"+ "end at $e next $beyond when $e - $s eq 2"+ "return <windo>{$second,$beyond}</windo>"; result = service.query(query ); assertxmlequal("<windo>10 14</windo>", ((XMLResource) result.getresource(0)).getcontent().tostring()); assertxmlequal("<windo/>", ((XMLResource) result.getresource(1)).getcontent().tostring()); assertxmlequal("<windo>4 8</windo>", ((XMLResource) result.getresource(2)).getcontent().tostring()); Figure A.6 Une requête de type fenêtre disjointe, la clause WindowEndCondition est présente. Le test consiste à vérier les variables nextvar. 91

98 query = "for tumbling window $w in (2,4,6,8,10,12,14)"+ "start at $s previous $prestart when fn:true()"+ "end at $e previous $preend when $e - $s eq 2"+ "return <windo>{$prestart,$preend}</windo>"; result = service.query(query ); assertxmlequal("<windo>6 10</windo>", ((XMLResource) result.getresource(0)).getcontent().tostring()); assertxmlequal("<windo>12 12</windo>", ((XMLResource) result.getresource(1)).getcontent().tostring()); assertxmlequal("<windo>4</windo>", ((XMLResource) result.getresource(2)).getcontent().tostring()); Figure A.7 Une requête de type fenêtre disjointe, la clause WindowEndCondition est présente. Le test consiste à vérier les variables previousvar. query = "for tumbling window $w in (2,4,6,8,10,12,14)"+ "start $first at $s when $s mod 3 =1"+ "end at $e when $e - $s eq 2"+ "order by $first\n"+ "return <windo>{$w}</windo>"; result = service.query(query ); assertxmlequal("<windo>2 4 6</windo>", ((XMLResource) result.getresource(0)).getcontent().tostring()); assertxmlequal("<windo> </windo>", ((XMLResource) result.getresource(1)).getcontent().tostring()); assertxmlequal("<windo>14</windo>", ((XMLResource) result.getresource(2)).getcontent().tostring()); Figure A.8 Une requête de type fenêtre disjointe, les clauses WindowEndCondition et OrderbyClause sont présentes. 92

99 query = "let $k:=(2,4,6,8,10,12,14) \n"+ "for tumbling window $w in $k"+ "start at $s when fn:true()"+ "end at $e when $e - $s eq 2"+ "return <windo>{ $w }</windo>"; result = service.query(query ); assertxmlequal("<windo> </windo>",((XMLResource) result.getresource(0)).getcontent().tostring()); assertxmlequal("<windo>14</windo>", ((XMLResource) result.getresource(1)).getcontent().tostring()); assertxmlequal("<windo>2 4 6</windo>", ((XMLResource) result.getresource(2)).getcontent().tostring()); Figure A.9 Une requête de type fenêtre disjointe, les clauses WindowEndCondition et LetClause sont présentes. query = "for tumbling window $w in //employee"+ "start $first next $second when $first//dno = $second//dno"+ "end $last next $beyond when $last//dno ne $beyond//dno\n"+ "order by $w[1]/dno\n"+ "return element windo{\n"+ "attribute dept {$w[1]/dno},\n"+ "<employee>{$w/ssn}</employee>,\n"+ "<number>{count($w)}</number>\n" + "}"; result = service.queryresource(employee_xml, query ); assertequals( "XQuery: " + query, 3, result.getsize() ); assertequals("xquery: " + query, "<windodept=\"4\">" + "<employee>" + "<SSN> </SSN>" + "<SSN> </SSN>" + "</employee>" + "<number>2</number>"+ "</windo>",((xmlresource)result.getresource(0)).getcontent().tostring().replaceall("\\s", "")); Figure A.10 Une requête de type fenêtre disjointe, les clauses WindowEndCondition et OrderbyClause sont présentes. La clause ReturnClause construit de nouveaux éléments. 93

100 query = "for tumbling window $w in //employee\n"+ " start $first next $second when $first//dno = $second//dno\n"+ " end $first next $beyond when $first//dno ne $beyond//dno\n"+ "return element item{\n"+ "$w/ssn}"; result = service.queryresource(employee_xml, query ); fail("$window variables have the same name!"); Figure A.11 Une requête de type fenêtre disjointe, la clause WindowEndCondition est présente. Le test consiste à vérier que les noms des variables sont diérents. query = "for tumbling window $w in //employee\n"+ " start $first next $second when $first//dno = $second//dno\n"+ " end $last next $beyond when $last//dno ne $beyond//dno\n"+ "where $w/dno = 5 \n"+ "return element item{\n"+ "$w/ssn}"; result = service.queryresource(employee_xml, query ); assertequals( "XQuery: " + query, 2, result.getsize() ); assertequals("xquery: " + query,"<item><ssn> </ssn> <SSN> </SSN></item>", ((XMLResource) result.getresource(0)). getcontent().tostring().replaceall("\\s","")); Figure A.12 Une requête de type fenêtre disjointe, les clauses WindowEndCondition et WhereClause sont présentes. query = "for tumbling window $w in //employee\n"+ " start $first next $second when $first//dno = $second//dno\n"+ " end $last next $beyond when $last//dno ne $beyond//dno\n"+ "return for $i in $w return $i/ssn"; result = service.queryresource(employee_xml, query ); assertequals( "XQuery: " + query, 6, result.getsize() ); assertequals("xquery: " + query,"<ssn> </ssn>", ((XMLResource) result.getresource(0)).getcontent().tostring()); Figure A.13 Une requête de type fenêtre disjointe, la clause WindowEndCondition est présente. ReturnClause est imbriquée avec une ForClause. 94

101 query = "for sliding window $w in (2,4,6,8,10,12,14)"+ "start at $s when fn:true()"+ "end at $e when $e - $s eq 2"+ "return avg($w)"; result = service.query(query ); assertequals( "XQuery: " + query, 7, result.getsize() ); Figure A.14 Une requête de type fenêtre glissante. query = "for sliding window $w in (2,4,6,8,10,12,14)"+ "start $first when $first mod 4 =0"+ "end $last when $last - $first eq 6"+ "return <windo>{ $w }</windo>"; result = service.query(query ); assertequals( "XQuery: " + query, 3, result.getsize() ); assertxmlequal("<windo>12 14</windo>",((XMLResource) result.getresource(0)).getcontent().tostring()); assertxmlequal("<windo> </windo>", ((XMLResource) result.getresource(1)).getcontent().tostring()); assertxmlequal("<windo> </windo>", ((XMLResource) result.getresource(2)).getcontent().tostring()); Figure A.15 Une autre requête de type fenêtre glissante. query = "let $k := (2, 4, 6, 8, 10, 12, 14)" + "for sliding window $w in $k"+ "start at $s when fn:true()"+ "end at $e when $e - $s eq 2"+ "return avg($w)"; result = service.query(query ); assertequals( "XQuery: " + query, 7, result.getsize() ); Figure A.16 Une requête de type fenêtre glissante, LetClause est présente. 95

102 query = "for sliding window $w in (2,4,6,8,10,12,14)"+ "start at $s when fn:true()"+ "end at $e when $e - $s eq 2"+ "return for $i in $w return <windo>{ $i }</windo>"; result = service.query(query ); assertequals( "XQuery: " + query, 18, result.getsize() ); Figure A.17 Une requête de type fenêtre glissante. ReturnClause est imbriquée avec une ForClause. 96

103 Annexe B A propos du stage Le stage a lieu au bureau de notre superviseur, qui se trouve au bâtiment UB4.131 du campus du solbosch à l'ulb. Etant un endroit parfaitement calme, il permet d'atteindre aisément une concentration excellente. En outre, la facilité de communiquer avec le superviseur chaque fois que nous rencontrons un problème, a largement favorisé l'avancement du stage. Au début de cette période, le travail a progressé lentement suite à la diculté de compréhension de la syntaxe ANTLR, ainsi que du code existant de exist. En outre, la conguration de la compilation et de l'exécution du programme de logiciel exist ont pris du temps et du travail an d'être mis en fonction. La première tâche a été de modier la grammaire existante de exist. Pour ceci, il est nécessaire d'eectuer une étude sur la syntaxe ANTLR an d'en acquérir une connaissance susante. A ce moment, lors de la production d'un bug, il est dicile de localiser l'endroit où se trouve l'erreur puisque le compilateur du programme ne sert pas à ce niveau. La seule solution possible est de consulter la documentation de ANTLR pour eectuer les modications appropriées, an d'éliminer l'erreur. Ceci a pris deux semaines de travail avant que nous puissions aborder le niveau des classes de Java. Il s'agit maintenant d'étudier les classes existantes, la façon dont elles sont construites et la relation entre celles-ci. Après cette étape, nous pouvons désormais planier un ensemble de nouvelles classes de travail, pour que chaque classe assume une tâche particulière, et ensuite établir leur relation an de garantir que l'ensemble de ces classes puissent représenter l'entièreté de la requête demandée. Le travail de débuggage du programme devient plus simple cette fois, à l'aide de l'outil compilateur. Il est à noter qu' il a pris du temps pour placer des breaks points et suivre le chemin de l'exécution, an de localiser l'erreur. Après des semaines de travail, nous obtenons un programme qui fonctionne, avec la nouvelle syntaxe de fenêtrage. Son comportement adéquat a nalement été justié par des tests d'unité JUnit de Java. 97

104 Bibliographie [1] Eclipse. [2] JDOM. [3] xmlrpclib : XMLRPC client access. xmlrpclib.html. [4] Overview of SGML Resources, [5] Document Object Model (DOM) Level 1 Specication Version 1.0, October [6] SOAP Version 1.2 Part 1 : Messaging Framework (Second Edition), W3C Recommendation, 27 April [7] ANTLR v3 documentation, september display/antlr3/antlr+v3+documentation. [8] FLWOR Foundation. Zorba - The XQuery Processor, march zorba-xquery.org. [9] Arvind Arasu, Shivnath Babu, and Jennifer Widom. The CQL continuous query language : semantic foundations and query execution. The VLDB Journal, 15(2) : , [10] Mark Ashworth. SQL and beyond. StandardView, 2(3) :175178, [11] Roger Bamford, Vinayak Borkar, Matthias Brantner, Peter M. Fischer, Daniela Florescu, David Graf, Donald Kossmann, Tim Kraska, Dan Muresan, Sorin Nasoi, and Markos Zacharioudakis. XQuery reloaded. Proc. VLDB Endowment, 2(2) : , [12] Michael Benedikt and Christoph Koch. XPath leashed. ACM Computing Surveys, 41(1) :154, [13] Springer Berlin and Heidelberg. Tamino : A Database System Combining Text Retrieval and XML. In Intelligent Search on XML Data, pages 7789, [14] Kevin Beyer, Don Chamberlin, Latha S. Colby, Fatma Özcan, Hamid Pirahesh, and Yu Xu. Extending XQuery for Analytics. SIGMOD,

105 [15] Peter Boncz, Torsten Grust, Maurice van Keulen, Stefan Manegold, Jan Rittinger, and Jens Teubner. Pathnder : XQuerythe relational way. In VLDB '05 : Proceedings of the 31st international conference on Very large data bases, pages VLDB Endowment, [16] Ronald Bourret. XML and Databases. september [17] Irina Carabus, Peter M. Fischer, Daniela Florescu, Donald Kossmann, Tim Kraska, and Rokas Tamosevicius. Extending XQuery with Window Functions. [18] Balder ten Cate and Carsten Lutz. The complexity of query containment in expressive fragments of XPath 2.0. J. ACM, 56(6) :148, [19] Shu-Yao Chien, Vassilis J. Tsotras, Carlo Zaniolo, and Donghui Zhang. Ecient Complex Query Support for Multiversion XML Documents. In EDBT '02 : Proceedings of the 8th International Conference on Extending Database Technology, pages , London, UK, Springer-Verlag. [20] James Clark. Modularization of XHTML in RELAX NG. Thai Open Source Software Center Ltd, [21] James Clark and Steve DeRose. XML Path Language (XPath) Version 1.0. W3C Recommendation, 16 November [22] James Clark and MURATA Makoto. RELAX NG Specication. OASIS Committee Specication, [23] Stefan Debloch. Chapter 6 - Window Tables and Window Functions in SQL. [24] Alin Deutsch, Mary Fernandez, Daniela Florescu, Alon Levy, and Dan Suciu. XML- QL : A Query Language for XML, August NOTE-xml-ql [25] Ghislain Fourny, Markus Pilman, Daniela Florescu, Donald Kossmann, Tim Kraska, and Darin McBeath. XQuery in the browser. In WWW '09 : Proceedings of the 18th international conference on World wide web, pages , New York, NY, USA, ACM. [26] Deiter Gawlick and Shailendra Mishra. Information sharing with the Oracle database. In DEBS '03 : Proceedings of the 2nd international workshop on Distributed event-based systems, pages 16, New York, NY, USA, ACM. [27] Jonathan Gennicklist. SQL Pocket Guide. O'Reilly Media, second edition. [28] Christian Heilmann. Beginning JavaScript with DOM Scripting and Ajax : From Novice to Professional [29] Luis O. Hernández and Mahmoud Pegah. WebDAV : what it is, what it does, why you need it. In SIGUCCS '03 : Proceedings of the 31st annual ACM SIGUCCS conference on User services, pages , New York, NY, USA, ACM. 99

106 [30] Philipp K. Janert. Gnuplot in Action, understanding Data with Graphs [31] Jirka Kosek and Petr Nálevka. Relaxed : on the way towards true validation of compound documents. In WWW '06 : Proceedings of the 15th international conference on World Wide Web, pages , New York, NY, USA, ACM. [32] Yong Kyu Lee, Seong-Joon Yoo, Kyoungro Yoon, and P. Bruce Berra. Index structures for structured documents. In DL '96 : Proceedings of the rst ACM international conference on Digital libraries, pages 9199, New York, NY, USA, ACM. [33] John Levine, Tony Mason, and Doug Brown. Lex & yacc, 2nd edition. O'Reilly, [34] Quanzhong Li and Bongki Moon. Indexing and Querying XML Data for Regular Path Expressions. In VLDB '01 : Proceedings of the 27th International Conference on Very Large Data Bases, pages , San Francisco, CA, USA, Morgan Kaufmann Publishers Inc. [35] Sam S. Lightstone, Guy Lohman, and Danny Zilio. Toward autonomic computing with DB2 universal database. SIGMOD Rec., 31(3) :5561, [36] Hung-Yi Lin. Compressed B+-trees. W. Trans. on Comp., 7(12) : , [37] Wolfgang Meier. exist : An Open Source Native XML Database. In Revised Papers from the NODe 2002 Web and Database-Related Workshops on Web, Web-Services, and Database Systems, pages , London, UK, Springer-Verlag. [38] Wolfgang Meier and the group of developers. exist, sourceforge.net/. [39] Anders Møller and Michael I. Schwartzbach. An Introduction to XML and Web Technologies. Addison-Wesley, January [40] Torben Bach Pedersen, Junmin Gu, Arie Shoshani, and Christian S. Jensen. Objectextended OLAP querying. Data Knowl. Eng., 68(5) :453480, [41] The XML :DB Project. XUpdate Working Draft, sourceforge.net/xupdate/xupdate-wd.html. [42] The XML :DB project. XML :DB Database API Working Draft, http: // [43] Ray Rankins, Paul Bertucci, Chris Gallelli, and Alex T. Silverstein. Microsoft(R) SQL Server 2005 Unleashed. Sams, Indianapolis, IN, USA, [44] Robert Richards. Simple API for XML (SAX). In Pro PHP XML and Web Services, pages , [45] J. Robie, J. Lapp, and D. Schach. XML Query Language (XQL). In The XSL Working Group, World Wide Web Consortium, QL/QL98/pp/xql.html. 100

107 [46] Dongwook Shin, Hyuncheol Jang, and Honglan Jin. BUS : an eective indexing and retrieval scheme in structured documents. In DL '98 : Proceedings of the third ACM conference on Digital libraries, pages , New York, NY, USA, ACM. [47] Divesh Srivastava, Shurug Al-Khalifa, H.V. Jagadish, Nick Koudas, Jignesh M. Patel, and Yuqing Wu. Structural Joins : A Primitive for Ecient XML Query Pattern Matching. In Proceedings of the International Conference on Data Engineering, page 141, Washington, DC, USA, IEEE Computer Society. [48] Neel Sundaresan and Reshad Moussa. Algorithms and programming models for ecient representation of XML for Internet applications. In WWW '01 : Proceedings of the 10th international conference on World Wide Web, pages , New York, NY, USA, ACM. [49] W3C. XQuery 1.1 : An XML Query Language, 15 december w3.org/tr/xquery-11/. [50] Priscilla Walmsley. XQuery. O'Reilly Media, Inc., [51] Raymond K. Wong. The extended XQL for querying and updating large XML databases. In DocEng '01 : Proceedings of the 2001 ACM Symposium on Document engineering, pages 95104, New York, NY, USA, ACM. [52] Chun Zhang, Jerey Naughton, David DeWitt, Qiong Luo, and Guy Lohman. On supporting containment queries in relational database management systems. SIG- MOD Rec., 30(2) :425436, [53] Esteban Zimányi. Base de données XML-Systèmes distribués d'information. ULB. 101