Interrogation OLAP d un entrepôt de données XML

Remy Choquet, Omar BoussaÔd Laboratoire ERIC - Université Lyon II Campus Porte des Alpes, 69676 Bron Cedex Remy.Choquet@gmail.com Omar.Boussaid@univ-lyon2.fr Résumé. XML (extended Markup Language) est aujourd hui un standard d échange de données inter applicatives, nous pensons que ce formalisme structuré va devenir un standard pour le stockage des données. Dans Boussaid et al. (2006), nous avons présenté XML-Wharehousing, une approche complète pour le stockage de cubes OLAP (On Line Analytical Processing) dans un entrepôt de données XML (exist). Nous avons défini un modèle pour la structuration des faits et la validation des documents XML à l entrée de l entrepôt. Il était donc logique d étendre notre approche à l interrogation de ces faits (ou cubes) sur base XML native. Nous aborderons celle-ci suivant 4 axes: modélisation, stockage, interrogation et indexation. 1 Introduction Il est en premier lieu important de situer ce travail dans le monde des bases de données. De nos jours, les bases relationnelles sont capables d effectuer des opérations OLAP sur cubes avec d excellents temps de réponse (< 1s) sur de très grands volumes de données. Cependant, ces systèmes sont peu flexibles, et permettent difficilement de prendre en compte les métadonnées. Comme nous l avons montré dans Boussaid et al. (2006), le formalisme XML nous permet de restructurer les données "à la volée" ainsi que de définir et de valider les axes d analyse basés sur les instructions utilisateur. Dans la continuité de notre travail sur l analyse de données sur documents XML, ce papier va présenter une approche d interrogation des données XML en utilisant la terminologie OLAP. A titre de rappel, dans Boussaid et al. (2006), nous avons présenté 3 concepts : les arbres d attributs(golfarelli et al. (1998)). l arbre minimum d analyse. la modélisation des cubes de données XML. Ces concepts ont mené à la construction d un entrepôt de données XML basé sur des cubes XML. Après le stockage des cubes dans exist, nous allons proposer une solution d interrogation de ces cubes en observant 4 axes : Modélisation : Nous définissons un cube XML comme un seul document XML structuré selon la demande d analyse définie par l utilisateur : schéma en étoile, en flocon de neige, etc...

Stockage : exist, est à ce jour la solution de stockage XML native la plus aboutie. Elle a été développée de manière conforme aux recommandations W3C et en respectant les spécifications DOM (Document Object Model) Interrogation : XQuery et XPath sont deux standards W3C pour interroger des documents XML Indexation : Les requêtes OLAP doivent être très performantes, c est un point essentiel de recherche à ce jour. Dans ce papier, nous allons revoir les travaux déjà effectués en section 2. Dans la section 3, nous allons aborder les méthodologies basées sur les 4 axes décrits ci-dessus. Nous allons ensuite mettre en place une plate-forme de test pour valider notre méthodologie en section 4. Nous proposerons des axes de recherche en conclusion. 2 Etat de l ART Depuis que XML est reconnu comme standard pour le transport de données, certaines recherches ont été effectuées pour utiliser XML à l entrée et à la sortie d entrepôts relationnels en construisant des couches logiques pour adapter et transformer les flux XML. Le projet XCube (H mmer et al. (2003)) présente un système d échange en utilisant le formalisme XML : les cubes de données (XCubeFact), les hiérarchies (XCubeDimensions) et les schémas (XCubeSchema). XMLA, dans Borkar et Carey (2001), développé par Hypérion, Microsoft, SAS et SAP, est une spécification proposant de standardiser l accès au moteur OLAP via des Web Services basés sur XML et SOAP (Simple Object Access Protocol). Ces deux propositions sont similaires puisqu elles utilisent XML comme outil de transport plutôt que comme un outil de stockage. Bordawekar et Lang (2005) introduit un entrepôt de données XML natif après avoir démontré les limites des modèles multidimensionnels pour l entreposage XML. Ils suggèrent de renverser l arbre XML habituellement utilisé dans le modèle relationnel. Pokorny (2001) propose une structure de données : XMLStar schema, composé de hiérarchies de dimension utilisant des DTDs pour décrire la structure des objets, il propose aussi un mécanisme de vérification d intégrité référentielle XML. Nassis et al. (2004) présentent une approche orientée objet avec XDW en utilisant des dimensions virtuelles et des vues conceptuelles. Baril et BellahsËne présentent DAWAX, un entrepôt XML basé sur un concept de vues modélisées en créant des vues sur des fragments de données, puis en les stockant dans une base relationnelle. En 2005, nous proposons dans dans Boussaid et al. (2006), une solution d entreposage de données XML avec XML-Warehousing. Nous proposons le concept d arbre minimum d analyse et la modélisation des cubes XML par faits. Chaque fait étant stocké and un fichier XML unique. Celui-ci sera validé en utilisant les algorithmes de transformation d arbre proposés par Golfarelli et al. (1998).

R. Choquet et O. Boussaid 3 Méthodologie d interrogation 3.1 Modélisation Le terme OLAP à été proposé par Codd et al. (1993). Il définit 12 règles pour la construction d entrepôts de données. Nous allons mettre en avant dans ce papier les règles suivantes : vue multidimensionnelle, consistance des temps de réponse, indépendance des dimensions et un nombre illimité de dimensions. FIG. 1 Un cube de données OLAP Nous définissons un cube comme un groupe de données agrégeable suivant une dimension (Fig. 1). Une dimension étant un attribut structurel de la donnée sur le cube (ex : product). Une mesure est une dimension spécifique représentée par une valeur numérique (ex : price). Une mesure peut être agrégée sur chaque dimension du cube. Dans dans Boussaid et al. (2006), nous définissons un fait (ou cube) comme étant un document XML unique. Chacun d eux étant alors stockés dans une collection de documents XML que l on nommera un cube XML. Un document XML est constitué de différentes structures et sous structures d éléments débutant par un élément racine. Cette modélisation de type arbre de données est conforme aux règles de Codd. Définition 1 (schéma en étoile XML) Soit (F, D) un schéma en étoile, où F est une table de fait ayant m attributs de mesure {F.M q, 1 q m} et D = {D s, 1 s r} est un ensemble où r dimensions indépendantes où chaque D s contient un ensemble de n s attributs {D s.a i, 1 i n s }. Le "schéma en étoile XML" de (F, D) est un schéma XML qui vérifie : F définit l élément racine XML dans le schéma XML ; q {1,..., m}, F.M q définit un attribut XML inclu dans l élément racine XML ; s {1,..., r}, Ds définit autant de sous-éléments de l élément racine XML tant qu ils sont liés à l élément racine ; s {1,..., r} et i {1,..., ns}, D s.a i définit un attribut XML inclu dans l élément XML D s. Dans la Fig. 2, nous remarquerons que chaque arbre XML valide ne comporte pas de clé IDRef pour définir les sommets. En effet, nous utilisons la sous-structure de XML pour définir les liens entre les sommets à travers les hiérarchies. Ici, le fait observé est sell. Les mesures sont price et quantity. Les dimensions sont product, client et seller.

FIG. 2 Collection de faits XML En superposant différents fichiers, ou faits, nous obtenons une collection de documents XML que nous nommerons fait XML (Fig. 2). La jointure implicite des dimensions aux faits de chacun des fichiers XML permet de vérifier l intégrité référentielle de l entrepôt. 3.2 Stockage Le projet exist (Meier) est une implémentation open source d un système de gestion de base de données XML native interfaáable à l aide de XPath, XQuery et XUpdate. exist permet de stocker sans schéma des documents XML dans des collections hiérarchiques. Une collection étant un ensemble pouvant contenir d autres collections ou des documents XML. Les documents sont stockés en respectant le modèle DOM (Document Object Model) du W3C. Les données sont séparées du coeur d exist. Tous les appels au système de stockage se font par des brokers. Voici en Fig. 3 une illustration de ce propos. FIG. 3 Architecture d exist

R. Choquet et O. Boussaid 3.3 Interrogation XQuery (Melton et S.Muralidhar) est présenté par le W3C en 1998 afin de permettre à la communauté toujours grandissante de XML d interroger ces données de manière plus flexible. XQuery v1.0 sera une extension de XPath 2.0. XQuery opère de manière abstraite sur la structure logique d un document XML plutôt que sur sa syntaxe. XPath est un langage d interrogation basé sur les chemins d arbres. Il permet de localiser facilement des sommets dans un arbre XML. On décrira ces requêtes comme axées. Un étape d expression retournera une séquence de sommets atteignables depuis le sommet de référence du contexte étudié via un axe spécifique. Un bloc de construction type XQuery est une expression composée d une chaóne de caractères décrivant des mots-clés, des symboles ou des opérateurs. Il est possible d encapsuler les expressions dans XQuery. XQuery introduit les expressions FLOWR (For Let Order by Where Return) et est par nature, équivalente en terme de finalité à XPath. Nous pouvons considérer FLOWR comme le select from where de SQL. La Fig. 4 représente le plan d ordonnancement de ce type d expression. Voici un exemple de requête utilisant XPath et XQuery : FLOWR: for $v in $doc//video return $v XPath: $doc//video Ces deux expressions retournent le même résultat. Cependant, il faut distinguer 3 différences de traitement : L opérateur f or est accompagné d une variable $v qui sera utilisée dans la clause return pour référer à chaque élément successif dans la séquence d entrée, alors qu une Path Expression utilise la notion d élément de contexte, auquel on peut se référer comme à ".". Dans cet exemple, //video est la contraction de./root()//video, la référence à l élément contexte est implicite. Avec l opérateur "/", l expression de gauche doit toujours sélectionner des sommets plutôt que des valeurs atomiques. Dans l exemple précédent, //video/count(actorref), l expression de droite retourne un nombre, alors que celle de gauche doit toujours retourner des sommets. Quand une opération sur chemins sélectionne un sommet, ils sont toujours retournés dans l ordre du document, les entrées dupliquées en moins. Par exemple, l expression $doc//section/para retourne chaque élément <para> exactement une fois, même s il apparaót dans plusieurs <section> d éléments. Si on utilise l expression équivalente FLOWR for $s in $doc//section return $s//para, alors <para> qui apparaót plusieurs fois dans des sections différentes, apparaótra autant de fois en sortie. 3.4 Indexation 3.4.1 Indexation structurelle Le coeur de la recherche en matière d indexation XML se penche actuellement sur ce type d indexation. Elle se base exclusivement sur une notion de plan de numérotation des sommets.

FIG. 4 Ordre d ordonnancement des opérateurs FLOWR Toute la problématique, et les recherches effectuées à ce jour portent sur la manière dont cette numérotation sera effectuée. En généralisant, nous pouvons dire que ce plan est construit en assignant un identificateur unique à chaque sommet de l arbre du document XML en traversant l arbre par niveau. Ces identificateurs sont ensuite utilisés dans le plan d indexation. Il est important dans ce type de plan, de pouvoir rapidement trouver les relations structurelles entre les noeuds, leur nature, leur emplacement. Tous les index d exist sont basés sur des arbres B+ (Bayer et McCreight). Un arbre B+ Tree est un type d arbre structuré pour données qui représente des données triées de telle manière qu on puisse insérer ou enlever des éléments. Les données sont stockées dans les feuilles de l arbre, les autres sommets ne contenant que les clés et les pointeurs. On dira que ce type d indexation est basé sur les valeurs. Depuis fin 2005, le plan d indexation DLN (Dynamic Level Numbers) de Bˆhme et Rahm (2004) est implémenté dans exist. Ce plan permet d indexer n importe quel document XML, qu elle que soit sa taille et sa complexité. Il permet aussi d insérer ou d enlever des éléments sans réindexation complète de l arbre. C est en fait, un plan de numérotation virtuelle par niveau qui a été implémenté. Il est basé sur des k aires : qui est un système de numérotation ou k est le nombre maximum de sommets fils d un élément dans un document XML. Un identificateur unique sera assigné à chaque sommet à l aide d un parcours de l arbre par niveaux. Pour compléter l arbre, des identificateurs vides seront insérés. Le problème majeur du système des k-aires, est que l index aura une structure ayant un maximum, et donc non-évolutive. Cependant, cette technique d indexation permet de retrouver rapidement des sommets via leur affiliation à travers des formules mathématiques élémentaires : parenti = (((i 2)/k) + 1) pour obtenir l identificateur du parent de i parenti, j = k(i 1) + j + 1 pour obtenir l identificateur du jeme fils Afin de garder une flexibilité dans le plan d indexation, les développeurs d exist ont implémenté un plan de numérotation alternatif en lieu et place de la contrainte de complétude

R. Choquet et O. Boussaid de l arbre. Le document ne sera plus vu comme un arbre k-aire complet, en fait, le nombre d enfants d un sommet sera recalculé pour chaque niveau de l arbre de cette manière : Pour 2 sommets x et y d un arbre, size(x) = size(y) si level(x) = level(y), où size(n) est le nombre d enfants d un sommet n et level(n) est la longueur du chemin entre le sommet racine et le sommet n. Intuitivement, on sait que plus on descend dans l arbre, plus il y aura de sommets. On augmente de beaucoup la taille des documents indexables de cette manière. Cette technique permet de ne pas ré-indexer un arbre en cas de modification de sa structure, mais garde pour autant les avantages de calcul sur les relations des sommets vus précédemment. Pour organiser ses index et ses données, exist utilise 4 fichiers d index : collections.dbx : gère la hiérarchie de collections comme le système de fichiers UNIX dom.dbx : contient les sommets des documents XML, associé à leur identificateur unique, ce fichier est paginé. elements.dbx : index les éléments et les attributs words.dbx : garde une trace des mots et de leurs occurrences. Plus utilisé en recherche textuelle. Il est important de savoir que tous les indexes pour les éléments, les attributs et les motsclés sont organisés par collection plutôt que par document XML. Ce qui signifie que toutes les occurrences d un élément article dans une collection seront stockées comme une seule entrée dans l index des éléments. Ceci diminue les temps d accès aux données et les performances du moteur d une manière générale. Le magasin XML dom.dbx est le composant central de l architecture de stockage d exist. Il contient tous les sommets des documents XML stockés dans une collection. Il est stocké à l aide d arbres B+ multi-racines dans le même fichier et associe à chaque identificateur de sommet unique sont adresse de stockage dans la partie des données du fichier dom.dbx. Dans ce plan, afin de naviguer rapidement entre les sommets, il n est pas nécessaire de garder une trace des liens entre les sommets (avec un pointeur par exemple) puisque l implémentation DOM dépend entièrement du plan de numérotation pour déterminer les relations structurelles entre les sommets. 3.4.2 Index de portée Les index de portée sont basés sur les valeurs. Ils sont spécifiques aux types de données des valeurs des sommets d un document XML. A l opposé des indexes structurés, l index de portée est créé par l utilisateur, exist n étant pas capable de déterminer le type des valeurs des noeuds de l arbre XML. Il le pourrait cependant à l aide d un XML Schéma, mais cela n est pas encore à l étude. Ces index sont utilisés au besoin lorsqu une comparaison est explicitement demandée via les opérateurs et fonctions de XPath, si ils sont définis par l utilisateur. Si ce n est pas le cas, exist procède à une inspection en mode brute-force du fichier dom.dbx. Il faut, généralement, respecter 3 conditions pour optimiser la recherche en utilisant ce type d index : L index de portée doit être défini sur tous les éléments sur lesquels porte la requête Le type de données à indexer doit correspondre au type de données testées L argument de droite ne doit pas dépendre du contexte courant

4 Mise en pratique Nous allons travailler sur exist, avec un jeu de faits d une base de données fictive de ventes. Celle-ci, assez simple, va aisément nous permettre de mettre en place des requêtes d analyse avec les concepts introduits jusqu ici. Cette base comporte 10 faits au format XML et sont stockés dans une collection exist. Le modèle utilisé est celui présenté en Fig. 2. 4.1 Requête sur 3 axes Voici une requête OLAP simple interrogeant l entrepôt sur les ventes effectuées par produit, vendeur et client : for $p in distinct-values(/vente/produit), $v in distinct-values(/vente/vendeur), $c in distinct-values(/vente/client) let $o := /vente[produit = $p and vendeur = $v and client = $c] order by $p, $v, $c return if (exists($o)) then <group> <produit> {$p} </produit> <vendeur> {$v} </vendeur> <client> {$c} </client> <montant_ventes> {sum($o/prix)} </montant_ventes> </group> else() Voici cette même requête en utilisant les index de portée : for $p in distinct-values(/vente/produit), $v in distinct-values(/vente/vendeur), $c in distinct-values(/vente/client) let $o := /vente[produit = xs:string($p) and vendeur = xs:string($v) and client = xs:string($c)] order by $p, $v, $c return if (exists($o)) then <group> <produit> {$p} </produit> <vendeur> {$v} </vendeur> <client> {$c} </client> <montant_ventes> {sum($o/prix)} </montant_ventes> </group> else() La différence de temps de traitement pour ces deux requêtes est sensible puisqu il faudra 0,2 secondes sans les index de portée, alors qu il suffira de 0,093 secondes avec les index de portée (2 fois plus rapide). 4.2 Slice L opérateur slice permet de découper suivant une tranche, un cube XML. Par exemple, avoir le nombre de ventes en coupant sur le produit= VTT :

R. Choquet et O. Boussaid for $v in distinct-values(/vente/vendeur), $c in distinct-values(/vente/client) let $p:= VTT ou let $p:=xs:string( VTT ) en optimisant let $o := /vente[produit/nomproduit = $p and vendeur = $v and client = $c] order by $v, $c return if (exists($o)) then <group> <produit> {$p} </produit> <vendeur> {$v} </vendeur> <client> {$c} </client> <montant_ventes> {sum($o/prix)} </montant_ventes> </group> else() De même, l utilisation d index de portée permet de réduire grandement le co t de traitement de cette requête (1,1690 à 0,0830 c est à dire, 14 fois plus rapide). 4.3 L opérateur GroupBy Afin de valider notre démarche, il est nécessaire d augmenter le nombre de faits dans notre entrepôt. Pour ce faire, nous allons augmenter le nombre de faits à 4480. Voici le résultat de nos requêtes : Sur 3 axes : 17 secondes (pour 0,093 secondes sur 10 faits) Slice : 5 secondes (pour 0,0830 secondes sur 10 faits) La limitation de l utilisation des requêtes FLOWR telles qu implémentées dans exist en utilisant l opérateur distinct values qui requière une atomisation des sommets lourde en temps de traitement. L utilisation d un groupby réduirait considérablement le temps de traitement de ce type de requêtes. Dans la Fig. 5, nous constatons que l augmentation du temps de traitement sur des volumétries limitées (4480 faits) est très importante. Encore une fois, l utilisation d un groupby sera indispensable. Bayer et al. (2005) proposent un opérateur group by pour XQuery. Celui-ci s articulant de la manière suivante : FLOWRExpr ::= (ForClause LetClause)+ WhereClause? (GroupByClause LetClause* WhereClause?)? OrderByClause? ReturnClause GroupByClause ::= "group" "by" Expr "into" "$" VarName ("," Expr "into" "$" VarName)* ("nest" Expr "into" "$" VarName ("," Expr "into" "$" VarName)* )? Voici la requête sur 3 axes écrite à l aide de l opérateur groupby de Beyer : for $v in //vente group by $v/vendeur into $v, $v/client into $c, $v/produit into $p return <group> {$v, $c, $p} </group>

FIG. 5 Synthèse des tests Malheureusement, la version d exist comportant cet opérateur groupby est toujours en développement (Verhaegen (2006)). Mais l opérateur permettra d effectuer des regroupements avec un temps de traitement constant indépendemment de la volumétrie de la base. FIG. 6 Variation du temps de traitement de 100k éléments entre exist et le nouvel opérateur groupby (script) 4.4 Conclusions et Perspectives L entreposage de données XML native est actuellement en pleine effervescence. Nombre de recherches dans des domaines aussi divers que la modélisation, le stockage, l indexation ou bien le requêtage sont actuellement à l étude.

R. Choquet et O. Boussaid X-Warehousing, tel que nous l avons présenté dans Boussaid et al. (2006) propose une solution ETL (Extract Transform Load) XML permettant la génération de faits valides dans un contexte d analyse donné par l utilisateur. Nous avons choisi, dans ce contexte, de profiter de la structure XML sous-jacente à chaque document XML (ou fait) et donc, de ne pas utiliser d IDRef pour établir de relation entre les sommets. La modélisation la plus simple (sans index) est aujourd hui valide en terme d interrogation de données. exist, base de données native XML open-source, est à ce jour le produit le plus évolué et le plus flexible que l on puisse trouver. Dans notre approche full XML, et grâce à la gestion par collection de documents, nous estimons que le stockage de données est convaincant et tout à fait adapté à des besoins d analyse OLAP XML. En terme d index, le système d exist basé sur un plan de numérotation en arbre k-aire par niveau amélioré ne correspond pas directement aux besoins d un entrepôt de données XML qui normalement, est peu amené à évoluer dans le temps au niveau structurel. Si évolution il y a, généralement, on est habitué à reconstruire le plan d indexation entièrement. Il serait peut-être judicieux d utiliser dans exist un système d indexage moins souple en terme de mise à jour, mais plus performant pour des volumes de données importantes. Enfin, concernant XQuery et XPath pour l interrogation de données, nous avons remarqué un manquement important (outre la mise à jour de données) : l opérateur groupby. En effet, le plan d indexage étant trop sollicité lors de l interrogation OLAP, le passage à l échelle (plusieurs giga-octets) posera des problèmes importants si on utilise l imbrication de requêtes for disctinctvalues(). Références Baril, X. et Z. BellahsËne. Data management : Native xml and xml-enabled database systems (first ed.). Bayer, K., D. Chamberlin, L. Colby, F. Ozcan, H. Pirahesh, et Y. Xu (2005). Extending xquery for analytics. IBM Almaden research center. Bayer, R. et E. McCreight. Binary b-trees for virtual memory. Proceedings of the ACM SIGFIDET Workshop. Bordawekar, R. et C. Lang (2005). Analytical processing of xml documents: Opportunities and challenges. Proceedings of the SIGMD. Borkar, V. et M. Carey (2001). Xml for analysis specification. Microsoft Specification. Boussaid, O., R. B. Messaoud, R. Choquet, et S. Anthoard (2006). Conception et construction d entrepùts de donnèes en xml. EDA 06. Bˆhme, T. et E. Rahm (2004). Supporting efficient streaming and insertion of xml data in rdbms. Proceedings of the DIWeb. Codd, E., S. Codd, et C. Salley (1993). Technical report, Arborsoft. Providing olap to user-analysts: An it mandate. Golfarelli, M., D. Maio, et S. Rizzi (1998). Conceptual designs of data wharehouses from e/r schema. HICSS 98: Proceedings of the Thirty-First Annual Hawaii International Conference on Systm Science-Volume 7.

H mmer, W., A. Bauer, et G. Harde (2003). Xcube: Xml for data warehouses. DOLAP 2003: ACM Sixth International Workshop on Data Wharehousing and OLAP. Meier, W. exist: An open source native xml database. Proceedings of WWSDS. Melton, J. et S.Muralidhar. Xml syntax for xquery 1.0 (xqueryx). W3C Candidate Recommandation. Nassis, V., R. Rajugan, T. S. Dillon, et J. Rahayu (2004). Conceptual design of xml document warehouses. DAWAK, Volume 3181 of Lecture Notes in Computer Science. Pokorny, J. (2001). Modelling stars using xml. DOLAP 01: Proc of the 4th ACM int. workshop on Data warehousing and OLAP. Verhaegen, B. (2006). Requêtes olap sur documents xml. Summary XML is today a standard for exchanging data between applications, we think that this structured formalism is about to become a standard for data storage. XML-Warehousing was presented in Boussaid et al. (2006), which is a global approach to OLAP cubes storage in a XML data warehouse (exist). We have thus defined a model for structuring facts and validating XML documents that are entering the data warehouse. Consequently, we decided to extend our approach to querying these facts (or cubes) on a XML native database. These queries will be considered according to four axes: modelling, storing, querying and indexing.