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