XQuery [XQu] est à l’origine un langage destiné à l’interrogation des données XML. Récem- ment, il est devenu un langage à multi-usage servant aussi bien pour poser des requêtes sur des col- lections de documents XML que pour effectuer différents types de traitements tels que la recherche textuelle, l’intégration de données, etc. La plupart de ces traitements ne requièrent pas les fonc- tionnalités complexes des SGBD relationnels telles que la gestion des transactions ou le stockage d’index en mémoire secondaire. Ceci a encouragé le développement de moteurs mémoire-centrale tels que [gal], [exi],[saxb] ou [qizb] qui manipulent les données directement en mémoire centrale. Les avantages qu’offrent ces moteurs comparés aux systèmes utilisant la mémoire secondaire sont la facilité de déploiement et d’utilisation. Cependant, ils restent limités par la taille de la mémoire centrale disponible et sont en particulier incapables de traiter des documents volumineux.
La projection XML est une technique d’optimisation introduite par [MS03] pour résoudre ce problème. Son principe est très simple et consiste à charger en mémoire uniquement les parties du document qui sont nécessaires à son traitement. Le scénario de la projection pour le cas de l’éva- luation d’une requêteQ sur un document t suit deux étapes. La première étape vise à déterminer de manière statique, c’est à dire en analysant la requête Q et éventuellement le schéma du document interrogé, s’il est disponible, la partiet′du documentt qui est nécessaire à l’évaluation de Q. L’in-
formation inférée pendant cette étape est utilisée lors du chargement du document t pour élaguer les parties qui ne sont pas accédées lors de l’évaluation de Q. L’évaluation de Q s’effectue sur la projection t′ qui permet d’obtenir le même résultat que si l’évaluation était effectuée sur le docu-
ment original t. L’efficacité de la technique de projection tient du fait qu’en général, les requêtes sont assez sélectives, c’est dire qu’elles nécessitent uniquement une partie du document interrogé. Exemple 22. Afin d’illustrer la projection, considérons la requête Q et le document t présentés dans la Figure 3.1. Cette requête extrait les éléments satellite de t qui sont fils des noeuds planet satisfaisant une condition particulière (le fils name de planet doit contenir le texte "Mars"). La projection de t pour cette requête doit alors contenir les noeuds Solar, planet et name qui sont utilisés par la requête Q soit pour la navigation soit pour exprimer une condition, ainsi que le
sous-élément desatellite qui est retourné par la requête. Dans le but de faciliter la compréhension de l’effet de la projection sur le document t, nous utilisons un seul document représentant à la fois le document originalt et sa projection. Les noeuds grisés sont ceux élagués par la projection. L’évaluation deQ sur le document original retourne l’élément satellite dont la racine est encadrée. Il aisé de constater que l’évaluation deQ sur la projection retourne le même résultat.
let$x := self :: Solar/planet
where$x/name/text()=’Mars’ return$x/satellite (a) La requêteQ Solar galaxy "The milky .." star "The sun" planet name "Mercury" orbit "57.9" planet name "Earth" diameter "4880" satellite name "Moon" note "..." planet name "Mars" diameter "2880" satellite name "Phobos" note "..." comet desc ".." note ".." (b) Le documentt
FIGURE3.1 – Illustration de la projection
Déterminer la meilleure projection pour une requête est l’objectif principal des différentes ap- proches proposées dans la littérature [MS03, BCL+05, BCCN06] dont l’objectif est clairement de minimiser la quantité de mémoire nécessaire pour l’évaluation des requêtes. L’analyse des requêtes constitue le point central de chacune de ces approches puisqu’elle permet d’inférer données néces- saires à leur évaluation. Dans [MS03], les auteurs proposent d’extraire les chemins exprimés dans la requêteQ et de les utiliser pour élaguer le document interrogé t. Lors du chargement de t, les chemins extraits deQ sont évalués afin d’identifier et d’élaguer les noeuds de t qui ne sont pas ac- cédés parQ. Cette approche possède deux avantages : (i) elle ne nécessite aucune information sur la structure du document interrogé et (ii) elle peut être utilisée dans le cas où un ensemble de requêtes est appliqué sur un seul document. Cependant, elle souffre de plusieurs limitations. La première limitation est liée à la faisabilité de la technique et concerne le type de chemins pris en compte. Les chemins contenant des axes arrière (parent et ancs) ou exprimant des prédicats (conditions) ne peuvent pas être évalués au vol et donc ne peuvent pas être considérés par cette technique. La deuxième limitation, liée à l’efficacité de la technique, découle du point (i) et survient lorsque les chemins contenant l’axe desc-or-self (//) sont utilisés pour l’élagage. L’évaluation de tels che- mins requiert de tester tous les descendants d’un noeud donné et peut ralentir considérablement l’étape l’élagage.
La technique développée dans [BCCN06] permet de résoudre ces deux problèmes en exploitant l’information sur le type (schéma) des documents interrogés. Elle considère que le document inter- rogé est valide relativement à une DTD et utilise cette dernière lors de l’analyse de la requêteQ pour extraire les étiquettes des noeuds accédés parQ. Cet ensemble d’étiquettes constitue le projecteur. L’élagage se trouve alors simplifié puisque il suffit de charger uniquement les noeuds du document
dont l’étiquette appartient au projecteur. Cette approche possède plusieurs avantages comparée à [MS03]. Premièrement, comme les chemins sont utilisés uniquement au niveau de l’analyse sta- tique (ils ne servent pas effectuer l’élagage du document) tous les types de chemins.Deuxièmement, l’élagage du document interrogé s’effectue de manière efficace puisqu’il repose sur un processus simple : la décision de projeter un noeud ou non repose sur le test d’appartenance de son étiquette au projecteur. La technique de [BCL+05] possède un point en commun avec la technique de [BCCN06] qui concerne l’utilisation de l’information sur la structure du document. Elle se base sur l’utilisation d’un DataGuide construit à partir du document interrogé et sur la transformation de la requête Q en une représentation arborescente. L’élagage consiste à établir la correspondance entre les noeuds det et ceux de cette représentation. Des indexes construits à partir du data guide sont utilisés pour accélérer cette phase d’élagage. L’avantage de cette technique est qu’elle est précise du fait de l’uti- lisation du data guide. Ses inconvénients sont liés d’abord à la nécessité de transformer la requêteQ en une représentation intermédiaire rendant l’approche inutilisable dans le cas où plusieurs requêtes sont utilisées. Cette technique se limite aussi aux chemins qui utilisent des axes en avant seulement et qui n’expriment pas de condition. Enfin, cette technique nécessite de construire des index dans le but d’accélérer l’étape d’élagage.
Dans de ce chapitre nous présentons les techniques de projection développées dans [MS03] et [BCCN06] sur lesquelles se base notre travail. Nous présentons d’abord l’approche proposée dans [MS03] basée sur les chemins qui s’applique dans le cas général en l’absence de schéma pour les documents interrogés. Nous présentons ensuite la technique de projection basée sur les schémas proposée dans [BCCN06] qui suppose que les documents respectent un schéma donné.