Fédération de données semi-structurées avec XML Tuyêt Trâm DANG NGOC PRESENTATION Bonjour, je m'appelle Tuyêt Trâm Dang Ngoc et je suis doctorante au Laboratoire PRiSM dans l'équipe de Monsieur Georges Gardarin. Cette équipe travaille sur le thème de l'intégration et la fouille de données complexes (IFDOCS). Je vais vous présenter les travaux effectués durant ma thèse sur le sujet de la fédération de données semi-structurées avec XML. Cette thèse s'est effectuée dans un cadre à la fois industriel et un cadre de recherche à travers 3 projets de recherche dont 2 européens et 1 national. [PAGE] Laboratoire PRiSM Université de Versailles-Saint-Quentin <dntt@prism.uvsq.fr> Présentation du Mardi 10 juin 2003

Tuyêt Trâm DANG NGOC - Université de Versailles Plan Contexte Intégration de données Évaluation de requêtes Validation Optimisation Conclusion et perspectives PLAN DE LA PRESENTATION Ceci est le plan de la présentation de l'exposé que je vais vous présenter. [CLIC] Représentation du monde réel (données semi-structurées) SGBD classiques sur données régulières (tableaux) Données non-régulières Tout d'abord, je situerai le contexte de cette thèse en introduisant la notion de données semi-structurées dont la principale représentation est XML, un langage standardisé de plus en plus utilisé. Nous verrons que dans la plupart des représentations informatique des données actuelles sont rigides (tableaux) et ne permettent pas de représenter des données du monde réel. Pour pallier à ce problème, un nouveau type de donnée appelé semi-structuré a fait son apparition et a introduit de nouveaux concepts, mais aussi de nouveaux problèmes. Intégration de ces données (médiateur) Avec des systèmes et données existants Avec des sources très hétérogènes (web, SGBD) Il a fallu en particulier composer avec les sources de données et les applications existantes. De plus, avec l'émergence du web, les sources de données se sont faites de plus en plus nombreuses mais aussi de plus en plus différentes (pages web, tableurs, SGBD relationnels, objets, etc.) Il faut donc pouvoir "regrouper" toutes ces données tout en tenant compte de leur différence pour pouvoir les interroger de façon cohérente. C'est le principe de la médiation. Dans cette partie, je vous présenterai l’architecture de médiation que j'ai réalisée tout au long de ma thèse. Evaluation des requêtes (algèbre) Une fois toutes ces sources regroupées, on dira "intégrées" par un médiateur, on doit pouvoir les interroger de façon efficace. Pour cela, j'ai conçu une algèbre permettant d'évaluer efficacement une requête portant sur de telles données. [CLIC] Validation Ces travaux de conception ont été suivi ensuite d'implémentations permettant de les prouver leur validité. Une phase de mesures et de comparaison a ensuite été réalisée afin de pouvoir juger des performances du système. A partir des conclusions de ces mesures, nous pouvons ensuite en déduire où se trouvent les goulots d'étrangement, et ce qu'il faudrait améliorer ou ajouter par la suite. [CLIC] Optimisation Evaluer les performances de ces évaluations (modèle de coût) Optimisation de ces évaluations (utilisation de cache) Nous envisageons dans l'immédiat deux optimisations possibles, et pour cela, j’ai étudié conceptuellement dans ma thèse deux méthodes. La première optimisation est que lorsqu'on a plusieurs choix d'évaluation possibles d'une requête, il serait utile d'estimer à l'avance leur différents coûts afin de choisir la meilleure méthode possible. La seconde optimisation est de pouvoir réutiliser des résultats de requêtes déjà posées pour répondre à d'autres requêtes. [CLIC] Conclusion et perspectives Le domaine des données semi-structurées et de la médiation étant vaste, en plus des propositions d'optimisation que nous proposons, beaucoup de travail de recherche est encore nécessaire. J'exposerai enfin comment j'envisage la suite de mes travaux. [PAGE] Tuyêt Trâm DANG NGOC - Université de Versailles

Tuyêt Trâm DANG NGOC - Université de Versailles Plan Contexte Intégration de données Évaluation de requêtes Validation Optimisation Conclusion et perspectives Contexte : Représentation du monde réel Données non-régulières (données semi-structurées) Représentation (XML) et langage de requêtes (XQuery) REPRESENTATION DU MONDE REEL Pour commencer, je vais situer le contexte de cette présentation, et introduire les notions nécessaires au bon suivi de cet exposé. [CLIC] Données non-régulières (données semi-structurées) SGBD classiques sur données régulières (tableaux) J'introduirai les données semi-structurées en montrant pourquoi la représentation des données "classiques" ne suffit pas. Je montrerai ensuite les propriétés de ce nouveau type de données et les nouvelles notions mais aussi les nouvelles difficultés qu'elles apportent [CLIC] Représentation (XML) et langage de requêtes (XQuery) Normalisation du W3C Ce nouveau type de donnée doit pouvoir être représenté. Pour cela, une normalisation a été définie par un organisme nommé W3C. Il s'agit du format XML. Un langage de requête permettant d'interroger ce nouveau type de données a aussi été inventé et normalisé, il s'agit du langage XQuery. Nous étudierons aussi ces normalisations dans cette section. [PAGE] Tuyêt Trâm DANG NGOC - Université de Versailles

Inconvénients des modèles de données classiques bar nom adresse rue ville telephone boisson L'Envol NULL LaCépède Paris Maple Kiss, Gin Tonic Le Frog's 25, Cour Saint Emilion, Paris 0143407071 L'apparement Café 0148871222, 0148874942 Café, Thé, Chocolat, Margarita, Gin Tonic INCONVENIENT DES MODELES DE DONNEES CLASSIQUES Les données classiques sont souvent représentées en informatique par des tableaux (tables dans les SGBD-R). Ce modèle a fait ses preuves dans la plupart des applications notamment en bases de données et atteint aujourd'hui de grande performance. En effet, une structure tabulaire ligne+colonne permet de récupérer, trier, chercher une information très rapidement. Par exemple, par l'intermédiaire de langage comme SQL. Si ce modèle est satisfaisant, il pose certains problèmes dans la représentation des données du monde réel. Valeurs nulles coûteux Dans le monde réel, des données peuvent manquer, par exemple, si on remplit une table représentant des bars, il se peut lorsqu'on ajoute une nouvelle entrée, que certaines informations manquent, soit car l'information est incomplète, soit parce qu'elle n'existe pas. Par exemple, pour la première entrée, on peut ne pas connaître l'adresse du bar "l'Envol", et que ce bar n'ait pas de numéro de téléphone. Une solution est de laisser nulle les cases où les informations sont manquantes. Ceci peut s'avérer à la longue si beaucoup de type d'informations sont représentées mais que beaucoup les entrées ont des informations incomplètes. Attributs multi-valués difficultés de manipulation A l'inverse, dans certains cas, il peut y avoir plusieurs informations de même type. Par exemple, la troisième entrée de la table "bar" possède deux informations "téléphone". Une solution est de créer un typage spécial pour ces cases (liste, tableau), ou encore de regrouper telles quelles toutes l'information dans une seule chaîne et de l'analyser ensuite. Dans un cas comme dans l'autre, la manipulation des données est rendue difficile. Typages différents Il peut aussi arriver qu'une même information soit donnée sous différentes forme. Par exemple, une adresse peut être décomposée en une rue et une ville pour une entrée, et écrite telle quelle sous forme de chaîne de caractère dans une autre entrée. Une solution est d'utiliser des modèles génériques comme dans le modèle objet. Difficultés d'extensions Ajout ou suppression d'un objet ayant un nouveau type d'attribut relationnel : rajouter encore des NULL et/ou créer un nouveau schéma objets : types génériques ou modification du schéma Un autre problème se pose lors de l'ajout ou de la suppression d'un objet ayant un nouveau type d'attribut. Par exemple, si je veux rajouter une nouvelle entrée "bar" avec une information supplémentaire comme le "pays", je serais obligé de rajouter une colonne, et de mettre des valeurs vraisemblablement nulles sur toutes les autres entrées. Cette opération consistant à la fois dans la modification du "schéma" de la table mais aussi de l'ensemble des entrées se fait par des méthodes coûteuse d'importation-exportation ou de mise à jour. Dans le modèle objet, même si celui-ci est plus souple que le modèle relationnel, les schémas et les types de données sont toujours assez figées et ne permettent pas d'accueillir simplement une nouvelle entrée possédant des informations très différentes. [PAGE] Valeurs nulles Attributs multi-valués Typages différents Difficultés d'extensions Tuyêt Trâm DANG NGOC - Université de Versailles

Données semi-structurées <bar> <nom> L’Envol </nom> <adresse> <rue> Lacépegrave;de </rue> <ville> Paris </ville> </adresse> <boisson> Maple Kiss </boisson> <boisson> Gin Tonic </boisson> </bar> <nom> Le Frog’s </nom> <telephone> 01 43 40 70 71</telephone> <adresse> 25, cour Saint-Emilion Paris</adresse> bar nom adresse rue ville boisson telephone L'Envol Lacépède Paris Maple Kiss Gin Tonic Le Frog's 01 43 40 70 71 25, cour Saint-Emilion Structure implicite définie dans les données elles-mêmes Structure irrégulière données manquantes données multi-valuées données de types différents Structure arborescente Schéma éventuel Représentation SGML, OEM, XML DONNEES SEMI-STRUCTUREES Pour résoudre ces problèmes de représentations de données du monde réel, un nouveau type de données : les données semi-structurées ont été introduites. Leur caractéristique est d'être suffisamment souple pour représenter des données dont la structure est imprécise (informations incomplète, informations multiples, de type différents, pouvant évoluer). Structure implicite définie dans les données elles-mêmes Le point le plus important est que pour pouvoir représenter une information de la manière la plus précise possible sans superflue est de joindre la structure décrivant la donnée à la donnée elle même. On dit aussi "encapsuler" la structure dans la donnée. Structure irrégulière données multi-valuées données manquantes données de types différents De cette façon, les données peuvent toutes ne pas répondre à la même structure. Et en particulier, les données peuvent être multi-valuées, manquante ou de différents types. Ainsi, le premier "bar" a plusieurs boissons, n'a pas de téléphone comme le second "bar", et le type de l'information "adresse" est représenté comme composé de "rue" et "ville" dans le premier "bar" et comme une unique chaîne de caractère dans le deuxième. Structure arborescente La façon la plus complète de représenter une donnée du monde réel est d'utiliser une structure arborescente. Ainsi, un bar est représenté par un nom, une adresse qui elle-même est représentée par une rue et une ville, et des boissons. Représentation XML, OEM Plusieurs formats ont été proposés pour représenter des données semi-structurées, et les plus connus sont OEM, SGML et XML. Le standard communément accepté est XML. [CLIC] XML est un langage balisé constitué d'éléments, d'attributs et de contenu. Les valeurs sont encadrés par deux balises. Les balises servent à décrire l'information et forment la structure de la donnée. Les données semi-structurées sont idéales pour représenter des entités du monde réel. Elles sont assez souples pour pouvoir représenter n'importe quel type d'information, Mais pouvoir être quand même manipulables, on conserve une structure partiellement défini par la donnée elle-même et encapsulé dans cette dernière. C'est pour cela que l'on parle de données semi-structurées. Cette absence de schéma prédéfini ainsi que la structure arborescente des données semi-structurées rend la manipulation de ses données complexes. [PAGE] Manipulation et traitement complexe Tuyêt Trâm DANG NGOC - Université de Versailles

Langage de requête sur XML : XQuery F Collection d’arbres utilisés Equivalent du FROM de SQL for $var in expr let $var := expr where expr order-by $var return expr L Mémorisation d’arbres Affectation de variables locales W Condition (élagage) Equivalent du WHERE de SQL XQUERY Le langage XQuery se présente sous la forme que l'on appelle FLWOR, qui correspond aux premières lettres des instructions utilisées pour formuler une requête dans ce langage. [CLIC] for permet de spécifier quelles collections de parties de document on utilise let permet de mémoriser une sous-collection where permet d'exprimer des contraintes order-by permet de trier les résultats return permet de sélectionner les résultat et d'exprimer sous quelle forme les présenter [PAGE] Ordonnancement Equivalent de ORDER-BY de SQL O Sous-arbres sélectionnés Présentation des sous-arbres Equivalent du SELECT de SQL avec une reconstruction R Tuyêt Trâm DANG NGOC - Université de Versailles

Tuyêt Trâm DANG NGOC - Université de Versailles Exemple XQuery <voyage> <vol> <num> 19660128 </num> <trajet> <depart> Paris </depart> <arrivee> Berlin </depart> </trajet> </vol> <temperature> 18 </temperature> <hotels> <hotel> <nom> schönes Murmeltier </nom> <adresse> <rue> Mauerstrasse </rue> <ville> Berlin </ville> </adresse> </hotel> <nom> grosser Pinguin </nom> <rue> Lindestrasse </rue> </hotels> </voyage> <num> 19760103 </num> ... vols temps trajet arrivee depart numero guide ville tpmoy restaurant nom adresse for $v in Collection ("*")/vols for $g in Collection ("*")/guide where $v/temps < 4 and $v/trajet/arrivee = $g/ville return <voyage> <vol> <num> {$v/numero} </num> <trajet> {$v/trajet} </trajet> </vol> <temperature> {$g/tpmoy} </temperature> <hotels> { for $h in Collection ("*")/hotels where $h/categorie = "5" and $v/trajet/arrivee = $h/adresse/ville <hotel> <nom> {$h/nom} </nom> <adresse> {$h/adresse} </adresse> </hotel> } </hotels> </voyage> hotels nom adresse rue ville categorie gerant prenom note EXEMPLE XQUERY Nous allons voir un exemple XQuery. On cherche à afficher tous les vols dont le temps de trajet est inférieur à 4 heures. Et pour chacun de ces vols, on affiche son numéro de vol, son trajet, ainsi que tous les hôtels de catégorie 5 situés dans la même ville. Pour chacun de ces hôtels, on affichera son nom et son adresse. Pour formuler cette question en XQuery, on se sert d’une requête imbriquée. La requête principale va sélectionner les vols de durée inférieure à 4 heures et va construire le résultat de cette requête dans la clause return colorée en bleu. Dans l’affichage des résultats de chacun des cols, on veut afficher les hôtels situés dans la même ville que la destination du vol. On crée donc pour cela une sous-requête portant sur hôtel avec une jointure sur la ville. La présentation du résultat de la sous-requête d’hôtel est colorée en rouge. [CLIC] A l’exécution, la présentation du résultat sera alors affichée de la manière suivante. Les zones colorées indiquent bien quelles parties de la requête de construction ont servit à créer le résultat. [PAGE] Tuyêt Trâm DANG NGOC - Université de Versailles

Tuyêt Trâm DANG NGOC - Université de Versailles Plan Contexte Intégration de données Evaluation de requêtes Validation Optimisation Conclusion et perspectives Intégration de données : Architecture de médiation Sources hétérogènes (adaptateurs) Sources distribuées (médiateurs) INTEGRATION DE DONNEES Il faut pouvoir adapter ce nouveau type de données avec les sources de données existantes. Il faut aussi considérer de plus en plus de données sont disponibles sur l’Internet sous différentes forme : des accès aux bases de données, des pages web et des moteurs de recherches, ainsi que divers serveurs d’applications. Deux problèmes se posent alors dans l’interrogation des données. [CLIC] Avec des sources très hétérogènes Protocoles Socket, RMI, ODBC/JDBC applicatifs pages web, moteurs de recherches, fichiers textes SGBD relationnels, objets, XML Les sources d’informations sont très hétérogènes. Au niveau des protocoles par exemple, les connections se font au niveau socket, RMI ou par des protocoles de plus haut niveau comme ODBC ou JDBC. Ensuite, au niveau applicatifs, les sources de données peuvent être très disparates. Ainsi, on trouve des pages web, des fichiers, des SGBD qui eux-même peuvent être relationnels, objet ou même XML. Avec des sources distribuées différents sites sur l'Internet différents SGBD sur le réseau interne ou vers des organismes collaborateurs Les sources d’informations sont aussi distribués, et nous pourrions avoir à formuler une question portant sur plusieurs sources à la fois toutes dispersées sur différents sites de l’Internet ou du réseau local. Pour traiter du problème de la dispersion et de l’hétérogénéité des sources qu’il faut recourir à un mécanisme d’intégration de données que l’on appelle « médiation ». [PAGE] Tuyêt Trâm DANG NGOC - Université de Versailles

Architecture de médiation ? Médiateur Adaptateur SQL OQL tuples objets API instances Moteur de recherche textes XQuery XML langage commun de requête format de résultat commun SQL tuples OQL objets XQuery Moteur de recherches textes API instances XML ARCHITECTURE DE MEDIATION Supposons qu'on cherche à savoir où passer ses vacances. [CLIC] On peut consulter la base de données relationnelle d'une agence de voyage, pour cela, on utilise le langage de requête SQL et on récupère des tuples représentant les données. Ensuite, on se renseigne sur les hôtels en consultant par exemple une base de données objet donnant des informations sur les différentes chaînes hôtelières. Ici, on utilisera le langage OQL et on récupèrera des objets. Ensuite on cherche des horaires de vols, pour cela, on peut consulter une base de données semi-structurées s'occupant des vols d'avion. On l'interroge via le langage XQuery des documents XML résultats. Ensuite, on cherche des informations sur les pays susceptibles de nous intéresser, pour cela, on utilise un moteur de recherche et on récupère des pages web HTML représentant les résultats de notre recherche. Enfin, on consulte la météo par l'intermédiaire d'un logiciel accédant à une application donnant des informations météo. Tout ceci est très compliqué au niveau de l'utilisateur qui doit non seulement savoir se débrouiller pour décomposer sa requête en plusieurs petites requêtes spécifique à chaque source. Puis connaître chacun des moyens d'accès et chacun des langages d'interrogation ou de programmation permettant d'accéder à la source de données. Il lui faudra ensuite composer les résultats qui sont tous dans un format différents et les intégrer pour obtenir un résultat cohérent. Un médiateur qui s'insèrerait entre l'utilisateur et les sources de données et qui lui offrirait une vue unique de toutes les sources. Une architecture de médiation se compose de deux parties : un ensemble d’adaptateurs : ils traitent de l’hétérogénéité des données. Ils sont spécifiques à la source de données qu’ils gèrent, c’est à dire qu’ils interrogent la source suivant le langage de requête natif de la source (par exemple, un adaptateur de la base relationnelle interrogera sa source en SQL) et récupère le résultat suivant le format natif de résultat de la source (par exemple, l’adaptateur de la base relationnelle récupèrera les résultats sous forme de tuples). La communication entre les adaptateurs et le médiateur se fait par contre par un langage commun, aussi bien pour les requêtes que pour les résultats. De la sorte, le médiateur ne voit plus les sources que comme un ensemble de sources homogènes que l’on interroge tous de la même façon et dont les résultats se font tous suivant le même format. un médiateur : le rôle du médiateur est de s’occuper de la distribution des sources. Il doit pouvoir décomposer une requête en sous-requête qu’il enverra aux sources qui sauront y répondre. Il doit pouvoir récupérer les résultats des sources et les composer pour former un résultat cohérent pour l’utilisateur. L’architecture que nous venons de voir est typique des architectures de médiation. Nous pouvons noter que grâce à ce principe médiateur-adaptateur, il suffirait de créer un adaptateur dédié à l’architecture de médiation pour pouvoir gérer le médiateur comme une source de donnée et pouvoir créer ainsi récursivement des arborescence de médiation. Suivant les implémentations, le langage commun peut varier, certains utilise un langage interne, d’autres OQL, etc. Nous utilisons comme langage de requête commun XQuery et XML comme format de données commun. [PAGE] SGBD relationnel SGBD objet SGBD Semi-Structuré Fichiers texte Application Fichiers texte Fichiers HTML Agence de voyage Chaîne hôtelière Horaire des vols Informations Pays Météo Tuyêt Trâm DANG NGOC - Université de Versailles

Architectures de médiation de données semi-structurées Médiation avec modèle relationnel Hermes AGORA/LeSelect, XPeranto, SilkRoute Médiation avec modèle objet DIOM, MOMIS IRO-DB, DISCO Médiation avec modèle semi-structuré GARLIC, TSIMMIS, STRUDEL, YAT, MIX, Nimble, LiquidData ARCHITECTURES DE MEDIATION Plusieurs architecture de médiation ont été proposées pour l’intégration des données. Avec l’apparition des données semi-structurées, quelques architectures de médiation basées sur ce nouveau type de données ont été proposées. LAV, GAV GARLIC, TSIMMIS, MIX STRUDEL : approche matérialisée (warehousing) YAT AGORA/LeSelect XPeranto Nimble LiquidData [PAGE] Tuyêt Trâm DANG NGOC - Université de Versailles

Architecture « Tout-XML » Langage de requête : XQuery Format du résultat : XML Communication avec les adaptateurs : XML/DBC Méta-données : XML-Schema Formules et statistiques de coût : XML + MathML Capacités : XML Exécution de requêtes : XQuery + XML Evaluation de requêtes : XAlgèbre Structures internes : SAX, DOM, XTuple Intégration de données hétérogènes : XML, Relationnel, Web ARCHITECTURE "TOUT-XML" L'originalité de notre architecture est de se fonder au maximum sur les standards XML. Langage de requête : XQuery Le langage de requête utilisé pour interroger le médiateur est XQuery. Format du résultat : XML Le format du résultat est XML. Intégration de données hétérogènes : XML, Relationnel, Web Les sources de données interrogés par le médiateur peuvent être très différentes. Il suffit juste d'avoir l’adaptateur associé. Les sources qui sont supportées actuellement : SGBD relationnel oracle, un SGBD XML natif : e-XMLRepository. Communication avec les adaptateurs : XML/DBC XML/DBC est une interface de programmation qui permet de communiquer avec des SGBD. Elle peut aussi bien servir à communiquer des informations relatifs à l’adaptateur - typiquement lors de l’enregistrement de l’adaptateur- que pour soumettre et répondre à des requêtes. Métadonnées : XML-Schema Une collection de données semi-structurées peut avoir néanmoins une structure commune appelée schéma. Ce schéma peut être définie a priori et caractérise cette collection de données. Les données relationnelles, objets, etc. possède aussi des méta-données. La représentation des méta-données est représentée dans le standard XML-Schéma, et est communiqué sous forme de document XML. XML-Schéma étant lui-même défini en XML contrairement à un autre standard de définition de schéma XML : les DTD. Un adaptateur nouvellement enregistré, communique au médiateur l’ensemble des méta-données de la source qu’il gère. La communication se fait à l’aide de XML-Schéma. Formules et statistiques de coût : XML + MathML Le médiateur peut avoir besoin de modéliser par des formules le coût d’une exécution, mais aussi de communiquer des informations statistiques (nombre de documents, de données, taille moyenne d’une information, etc.). Ceci afin que le médiateur puisse avoir une idée du coût d’une exécution sur l’adaptateur. Le format utilisé pour la communication du coût se fait suivant en MathML. MathML est un format basé sur XML utilisé par les mathématiciens pour représenter des formules mathématique en XML. Capacités : XML Une source peut plus ou moins être limitée dans ses possibilités d’interrogation. Par exemple, un SGBD peut répondre à des requêtes plus complexes qu’un simple moteur de recherche. Il faut que les adaptateurs puissent communiquer leurs capacités de traitement au médiateur afin que celui-ci puisse en tenir compte. Cette communication se fait suivant un ensemble de règles basé sur XML. Exécution de requêtes : XQuery + XML Une requête s’exprime en XQuery et la réponse est renvoyée en XML. Évaluation de requêtes : Algèbre XML Pour pouvoir évaluer une requête, il faut pouvoir modéliser ses opérateurs et son domaine de définition. C’est à dire une algèbre. Je détaillerai tout à l’heure l’algèbre que j’ai conçu pour évaluer des requêtes XQuery. Structures internes : SAX, DOM, XTuple Enfin, dans l’implémentation, un maximum d’interface de programmation standard défini pour XML a été utilisé. [PAGE] Tuyêt Trâm DANG NGOC - Université de Versailles

Architecture de médiation Application utilisateur Métadonnées Métadonnées XQuery XML Gestionnaire de coûts Gestionnaire de coûts Analyseur Recomposeur Structure XQuery XTuple Générateur de plans d’exécution Gestionnaire de capacités Gestionnaire de pilotes XML/DBC ARCHITECTURE DE MEDIATION Ceci est notre architecture de médiation. [CLIC] L’utilisateur soumet sa requête XQuery. L’analyseur décompose la requête sous forme de structure interne. Cette structure interne est ensuite transformé en une liste d’arbre algébrique représentant la suite des opérations à exécuter pour évaluer la requête. Chaque arbre algébrique est envoyée à l’adaptateur de la source correspondant via le protocole XML/DBC. L’interrogation se fait en XQuery. L’adaptateur se charge ensuite de convertir la requête XQuery en langage natif de la source. Le résultat sous forme natif de la source est ensuite renvoyée à l’adaptateur qui le convertit en XML. Le résultat XML est ensuite accessible par le médiateur via XML/DBC. Les résultats sous alors traité sous forme de tuples d’arbre appelé XTuple, et le résultat final est alors créé sous forme de XTuple. Le recomposeur se charge enfin de transformer les XTuples en document XML résultat. ut a étét implémenté dans l’architecture du médiateur, excepté les composants grisés. [PAGE] XTuple XAlgèbre Pilote Médiateur Pilote SGBD-R Pilote SGBD-SS executeQuery(XQuery) XML Adaptateur Adaptateur Adaptateur SQL XPath XQuery Tuples XML SGBD-SS SGBD-R Médiateur Tuyêt Trâm DANG NGOC - Université de Versailles

Tuyêt Trâm DANG NGOC - Université de Versailles Plan Contexte Intégration de données Evaluation de requêtes Validation Optimisation Conclusion et perspectives Evaluation de requêtes Construction d'un plan d'exécution (XAlgèbre) Evaluation EVALUATION DE DONNEES [CLIC] Construction d'un plan d'exécution (XAlgebre) Une requête XQuery est transformé en un plan d’exécution après une phase de traitement préalable. Ce plan d’exécution est exprimée suivant une algèbre nommée XAlgèbre. Je développerai la définition de la XAlgèbre. Comme toute algèbre, elle est composée d’un domaine de définition et d’opérateurs. Le domaine de définition est composé de XRelation composé de XTuples et les opérateurs sont les opérateurs relationnels étendus, que l’on appellera XOpérateurs. Evaluation L’évaluation de l’algèbre se fait en deux temps : une phase de préparation et une phase d’évaluation en flux. [PAGE] Tuyêt Trâm DANG NGOC - Université de Versailles

Évaluation de requêtes distribuées semi-structurées Intégration de données Analyse de la requête Création du plan d’exécution identification des opérations à réaliser localisation des sources optimisation Évaluation et recomposition des résultats Cas des données semi-structurées Restructuration Objets multi-valués Composition de graphes Construction de l’arbre algébrique EVALUATION DE REQUETES DISTRIBUEES SEMI-STRUCTUREES Intégration de données L’évaluation de requête dans un contexte d’intégration de données a fait l’objet de plusieurs recherches. Toute passent par les étapes suivantes : Analyse de la requête Analyser la requête exprimé dans le langage de requête pour la vérifier syntaxiquement et créer une représentation de cette requête en mémoire. Création du plan d’exécution La représentation de la requête est ensuite traitée afin de générer la suite des opérations nécessaires à l’évaluation de la requête. identification d’une suite d’opérations à réaliser Une série de transformation (normalisation, analyse poussée de la requête) permet d’identifier la suite d’opérations à réaliser pour évaluer cette requête. On utilise en général des opérateurs comme les restrictions, les jointures, les projections, union, intersection, ou même des boucles d’itération etc. pour décrire le processus d’évaluation de la requête. localisation des sources Comme on se place dans le cadre de données distribuées, il faut pouvoir identifier les sources répondant à tel ou tel partie de la requête. Il faut alors en général décomposer la requête en sous-requêtes spécifiques à chaque sources. optimisation Une fois la suite d’opérations connue –et elle est souvent représentée sous forme d’arbre algébrique- on peut l’optimiser pour générer une suite d’opération équivalente mais dont l’exécution sera moins coûteuse. Evaluation et recomposition des résultats Une fois le plan d’exécution généré, il ne reste plus qu’à l’évaluer. Le traitement consiste à suivre les instructions données par les opérations pour générer le résultat. Cas des données semi-structurées Dans le cas des données semi-structurées, il faut tenir compte de plus de certains problèmes : Restructuration On peut demander au résultat final d’être structuré d’une certaine façon (clause return). Pour cela, des méthodes de restructuration du résultat doit être présents. Objets multi-valués Les objets multivalués sont fréquent en semi-structuré, il faut en tenir compte. Composition de graphes Enfin, lors de jointures, produits, sélections etc. on peut avoir à fusionner, dissocier, parcourir des données arborescentes. Ceci sont des opérations complexes sur des arbres. [PAGE] Tuyêt Trâm DANG NGOC - Université de Versailles

Construction du plan d’exécution for $v in vols where $v/temps < 4 return ($v/numero, $v/trajet, $v/trajet/arrivee) for $g in guide return ($g/tpmoy) $v/trajet/arrivee = $g/ville $t1/trajet/arrivee = $h/adresse/ville for $h in hotels where $h/categorie = "5 "   return ($h/nom, $h/adresse, $h/adresse/ville) U Résultat <voyage> <vol> <num> {$v/numero} </num> <trajet> {$v/trajet} </trajet> </vol> <temperature> {$g/tpmoy} </temperature> <hotels> <hotel> <nom> {$h/nom} </nom> <adresse> {$h/adresse} </adresse> </hotel> </hotels> </voyage> S1 S2 S3 let t1 := for $v in Collection ("*")/vols for $g in Collection ("*")/guide where $v/temps < 4 and $v/trajet/arrivee = $g/ville return ($v/numero, $v/trajet, $v/trajet/arrivee, $g/tpmoy) let t2 := for $v in $t1 for $h in Collection ("*")/hotels where $h/categorie = "5«  and $t1/trajet/arrivee = $h/adresse/ville return ($h/nom, $h/adresse, $h/adresse/ville) <voyage> <vol> <num> {$v/numero} </num> <trajet> {$v/trajet} </trajet> </vol> <temperature> {$g/tpmoy} </temperature> <hotels> <hotel> <nom> {$h/nom} </nom> <adresse> {$h/adresse} </adresse> </hotel> </hotels> </voyage> Req. élément. 2 Reconstruction Req. élément. 1 for $v in Collection ("*")/vols where $v/temps < 4 return ($v/numero, $v/trajet, $v/trajet/arrivee) for $g in Collection ("*")/guide return ($g/tpmoy) for $h in Collection ("*")/hotels where $h/categorie = "5 "   return ($h/nom, $h/adresse, $h/adresse/ville) $v/trajet/arrivee = $g/ville for $v in $t1 return ($t1/trajet/arrivee ) $t1/trajet/arrivee = $h/adresse/ville Atom. 1.1 Atom. 1.2 Atom. 2.1 Atom. 2.2 Recomp. 1 Recomp. 2 <voyage> <vol> <num> {$v/numero} </num> <trajet> {$v/trajet} </trajet> </vol> <temperature> {$g/tpmoy} </temperature> <hotels> <hotel> <nom> {$h/nom} </nom> <adresse> {$h/adresse} </adresse> </hotel> </hotels> </voyage> Reconstruction for $v in vols where $v/temps < 4 return ($v/numero, $v/trajet, $v/trajet/arrivee) for $g in guide return ($g/tpmoy) $v/trajet/arrivee = $g/ville $t1/trajet/arrivee = $h/adresse/ville for $h in hotels where $h/categorie = "5 "   return ($h/nom, $h/adresse, $h/adresse/ville) U Résultat <voyage> <vol> <num> {$v/numero} </num> <trajet> {$v/trajet} </trajet> </vol> <temperature> {$g/tpmoy} </temperature> <hotels> <hotel> <nom> {$h/nom} </nom> <adresse> {$h/adresse} </adresse> </hotel> </hotels> </voyage> S1 S2 S3 Construction du plan d’exécution for $v in Collection ("*")/vols for $g in Collection ("*")/guide where $v/temps < 4 and $v/trajet/arrivee = $g/ville return <voyage> <vol> <num> {$v/numero} </num> <trajet> {$v/trajet} </trajet> </vol> <temperature> {$g/tpmoy} </temperature> <hotels> { for $h in Collection ("*")/hotels where $h/categorie = "5" and $v/trajet/arrivee = $h/adresse/ville <hotel> <nom> {$h/nom} </nom> <adresse> {$h/adresse} </adresse> </hotel> } </hotels> </voyage> S1 S2 S1, S3 Normalisation Suppression des affectations (clauses « LET ») Canonisation Désimbrication des requêtes imbriquées Atomisation Séparation des collections Identification des sources Identification des sources gérant chaque collection Création du plan d’exécution Transformation en un arbre algébrique Optimisation du plan d’exécution Optimisation de l’arbre algébrique CONSTRUCTION DE L'ARBRE ALGEBRIQUE Il s’agit de déterminer les différentes opérations à effectuer pour évaluer une requête. Cet ensemble d’opération est appelé « plan d’exécution ». On peut les représenter par un arbre d’opérateurs appelé arbre algébrique. Pour construire un arbre algébrique à partir d’une requête XQuery, on passe par plusieurs étapes. Normalisation Suppression des affectations (clauses « LET ») Une phase de normalisation qui consiste à remplacer toutes les variables temporaires en leur valeur absolue. Pour cela un certain nombre de règle d’équivalence sont utilisé. Canonisation Désimbrication des requêtes imbriquées On identifie les requêtes imbriquées et on les désimbrique. Pour suivre toutes les étapes, nous allons étudier la requête exemple que l’on a vu précédemment. [CLIC] On construit ensuite des sous-requêtes nommés requêtes élémentaires ainsi qu’une requête de reconstruction. Dans notre cas, on voit deux requêtes imbriquées et on construit donc... ... deux requêtes élémentaires et une requête de reconstruction. Atomisation Séparation des collections Il s’agit ensuite dans chaque requête élémentaire, de séparer les différentes collections qui interviennent. On crée pour chacune des collections, une requête atomique, ainsi qu’une requête de recomposition ou requête de jointure. Dans notre exemple, on voit qu’il y a dans la première requête élémentaire cas deux collections : vols et guide, et dans le deuxième cas : la collection résultat de la première requête élémentaire et la collection hotel. On obtient ainsi deux requêtes atomique pour la première et la seconde requête requête ainsi qu’un critère de jointure pour chacun d’eux. Identification des sources Identification des sources gérant chaque collection Une fois ce travail de préparation exécuté, on consulte les métadonnées pour déterminer où chacune des sous-requêtes vont s’exécuter. Par exemple, la source pouvant s’occuper des vols peut être situé sur un SGBD relationnel nommé S1. La source s’occupant des guides peut se trouver sur une page web nommée S2 Et enfin il peut y avoir deux sources s’occupant des hôtels : un SGBD nommé S3 et le SGBD S1 vu avant. Création du plan d’exécution Transformation en un arbre algébrique Enfin on construit le plan d’exécution. Il se présente sous la forme d’un arbre algébrique. Optimisation du plan d’exécution Optimisation de l’arbre algébrique On peut ensuite appliquer des règles d’optimisation sur cet arbre algébrique, par exemple des optimisations classiques (remontée de restriction) ou encore, suivant des informations statistiques qu’on pourrait avoir, réorganiser l’ordre des jointures par exemple. [PAGE] Tuyêt Trâm DANG NGOC - Université de Versailles

Tuyêt Trâm DANG NGOC - Université de Versailles Algèbre Besoins Recherche de chemin Filtrage Construction XML Puissance d’interrogation Support pour un typage flexible Support pour l’optimisation Type d’algèbre Extension de l’algèbre classique : IBM, NIAGARA, TAX, YAT Transformation en algèbre relationnelle : AGORA Evaluation sémantique par boucles : AT&T Répond aux mêmes critères que le langage de requête ALGEBRE Pour pouvoir construire un plan d’exécution permettant de décrire les suites d’opérations à effectuer, une algèbre est nécessaire. Une algèbre est composé d’une domaine de définition et d’opérateurs. Besoins Les besoins d’une algèbre adaptée aux données semi-structurées sont les suivantes : Tout d’abord, répondre aux mêmes pré-requis que le langage de requête adapté à XML, c’est à dire la navigation, le filtrage, la possibilité de reconstruction, une puissance d’interrogation similaire ou supérieure à celle des langages relationnels, et supporter un typage flexible. Support pour l’optimisation En plus, de ces critères, un support pour l’optimisation est nécessaire. Cela passe par des règles d’équivalences entre les opérateurs. Type d’algèbre Les types d’algèbres définis pour les données semi-structurées sont nombreux. Extension de l’algèbre classique : IBM, NIAGARA, TAX, YAT Certains se basent sur une extension de l’algèbre classique comme l’algèbre IBM, NIAGARA (qui est une extension de l’algèbre IBM), TAX et YAT. Leur principe est d’étendre les opérateurs relationnels classique (jointure, sélection, projection, union, etc.) aux données semi-structurées, par des opérations directe sur des arbres ou des identifiants. Transformation en algèbre relationnelle : AGORA Une autre méthode d’évaluation qui est celle du projet AGORA, est de mettre à plat les arbres demandés et de travailler ainsi sur une structure tabulaire à l’aide d’opérations relationnelles classique. Puis recomposer le résultat en arbre. Evaluation sémantique par boucles : AT&T Une dernière approche est de ne pas utiliser du tout d’opérateurs, et d’évaluer directement la requête par boucle imbriquée. C’est l’approche qu’a choisi l’AT&T [PAGE] Tuyêt Trâm DANG NGOC - Université de Versailles

Tuyêt Trâm DANG NGOC - Université de Versailles bar nom adresse rue ville boisson L'Envol Lacépède Paris Maple Kiss Gin Tonic telephone Le Frog's 0143407071 25, cour Saint- Emilion Paris bar/nom bar/adresse bar/nom bar/adresse bar/adresse/rue bar/boisson bar/adresse/ville bar/telephone bar Xtuples : motivations bar/adresse/rue bar/adresse/ville L’Envol Lacépède Paris Maple Kiss Gin Tonic Le Frog’s 0143407071 25, cour Saint- Emilion Paris bar/nom bar/adresse bar/boisson bar/telephone bar nom adresse rue ville boisson L'Envol Lacépède Paris Maple Kiss Gin Tonic telephone Le Frog's 0143407071 25, cour Saint- Emilion Paris bar nom adresse rue ville L'Envol Lacépède Paris Le Frog's 25, cour Saint- Emilion Paris bar nom adresse rue ville boisson L'Envol Lacépède Paris Maple Kiss Gin Tonic telephone Le Frog's 0143407071 25, cour Saint- Emilion Paris bar nom adresse rue ville boisson L'Envol Lacépède Paris Maple Kiss Gin Tonic telephone Le Frog's 0143407071 25, cour Saint- Emilion Paris « Projection sur le nom et l’adresse de chaque bar. » bar nom adresse rue ville boisson L'Envol Lacépède Paris Maple Kiss Gin Tonic telephone Le Frog's 0143407071 25, cour Saint- Emilion Paris Opération directe sur arbres Pb : coût de navigation Transformation en tableau et opération relationnelle sur table Pb: coût de construction du tableau et la reconstruction de l’arbre bar nom adresse rue ville L'Envol Lacépède Paris Le Frog's 25, cour Saint- Emilion Paris Référencement dans un tableau et opération relationnelle sur table ET évaluation en flux Conservation de l’arbre et peu de navigation Tuyêt Trâm DANG NGOC - Université de Versailles

Tuyêt Trâm DANG NGOC - Université de Versailles XTuples : définition Un XTuple est composé de un ensemble d’arbre A un ensemble de références R sur A. Ces références sont appelées XAttributs. Les opérations relationnelles se font sur R. Les parcours et recomposition se font sur A. Un ensemble de XTuples du même type forment une XRelation R A a/b a/c f/h/i f/g b A C a c e d B f E g h i D F j XTUPLES : DEFINITION Nous définissons un XTuple par un ensemble d’arbre et un ensemble de références pointant sur les noeuds utiles de l’arbre. Les opérations de type relationnelles se font sur les XAttributs (R) et les opérations d’arbres se font sur la forêt A. Un ensemble des XTuples de même type est appelé XRelation. [PAGE] b G I a c e d H f K g h i J L j Tuyêt Trâm DANG NGOC - Université de Versailles

Tuyêt Trâm DANG NGOC - Université de Versailles Evaluation en flux Les documents XML sont remontés sous forme de flux d’évènements (SAX). Les XTuples sont construits au vol sur les flux. Les XOpérateurs (s’ils ne sont pas bloquants) traitent les XTuples au fur et à mesure. Les XOpérateurs N-aire parallélisent les différents flux de XTuples d’entrées. EVALUATION EN FLUX Le principe de l’évaluation en flux exploite le standard SAX qui permet de décrire un document XML sous forme de flux d’évènements. Les documents XML sont remontés sous forme de flux d’évènements (SAX). Un document XML peut être vu sous forme de flux d’évènement appelé évènement SAX. Cette représentation a fait l’objet d’une normalisation du W3C. Les XTuples sont construits au vol sur les flux. Partant de ce flux d’évènement, on construit les XTuples suivant les paramètres demandés. C’est à dire qu’on ne conserve et ne référence que les chemins utiles. Les XOpérateurs (s’ils ne sont pas bloquants) traitent les XTuples au fur et à mesure. Les XOpérateurs traitent les XTuples au fur et à mesure. Si leur buffer est plein ou s’ils sont bloquants (de nature ou par paramétrage), le flux est bloqué. Les XOpérateurs N-aire parallélisent les différents flux de XTuples d’entrées. Les opérateurs qui possèdent plusieurs flux d’entrée peuvent paralléliser les flux si possible et si nécessaire. [PAGE] Tuyêt Trâm DANG NGOC - Université de Versailles

XSource XProject Evaluation en flux <b>x</b> <c> <d>y</d> <e>z</e> <f>t</f> <d>u</d> <a> <b>x1</b> <c> <d>y1</d> <e>z1</e> <f>t1</f> <d>u1</d> <a> <b>x1</b> <c> <d>y1</d> <e>z1</e> <f>t1</f> <d>u1</d> XSource XProject Requête X sur source S1 références a, a/b et a/c Projection sur a et a/b <a> <b>x</b> <c> <d>y</d> <e>z</e> <f>t</f> <d>u</d> <a> <b>x2</b> <c> <d>y2</d> <e>z2</e> <f>t2</f> <d>u2</d> <a> <b>x2</b> <c> <d>y2</d> <e>z2</e> <f>t2</f> <d>u</d> On va voir sur un exemple comment fonctionne l’évaluation en flux. Pour cela, on va prendre pour exemple un opérateur XSource suivi d’un opérateur de XProjection. Soit le document XML envoyé sous forme de flux SAX. On va supposer qu’il y a trois arbres répondant à la requête XSource. [CLIC] Dès que l’opérateur XSource reçoit du flux SAX de quoi fabriquer le premier XTuple, il crée le XTuple et le met dans la XRelation sur le flux de sortie. La XProjection en attente du flux de sortie de XSource, donc de son propre flux d’entrée, voit un premier XTuple lui arriver. Il le prend donc en traitement. Par exemple, ici, il s’agit de faire une projection sur R1 et R2. Pendant ce temps XSource reçoit sur son flux d’entrée de quoi créer le second XTuple. Il le crée et le met en attente sur son flux de sortie. Pendant ce temps, XProjection a fini son traitement et renvoie son XTuple en attente dans sa XRelation sur son flux de sortie. Un autre XOpérateur le prendra en charge de la même façon. XSource reçoit enfin le dernier XTuple, comme le précédent n’est pas encore écoulé, il remplit la suite du buffer (la XRelation). A noter que quand la XRelation est pleine, c’est à dire, lorsqu’il atteint une certaine taille limite paramétrée, le XOpérateur devient bloquant tant que la XRelation sera pleine. La XProjection prend le XTuple suivant et le traite de la même manière. etc. [PAGE] a a/b a/c T1 a a/b T1 <a> <b>x</b> <c> <d>y</d> <e>z</e> <f>t</f> <d>u</d> <a> <b>x3</b> <c> <d>y3</d> <e>z3</e> <f>t3</f> <d>u3</d> <a> <b>x2</b> <c> <d>y2</d> <e>z2</e> <f>t2</f> <d>u2</d> Tuyêt Trâm DANG NGOC - Université de Versailles

Arbre algébrique hotels vols XSource for $v in Collection ("*")/vols $v/temps<4 $h/categorie="5" $v/trajet/arrivee=$h/adresse/ville Arbre algébrique ($v/temps, $v/num, $v/trajet, $v/trajet/arrivee) ($h/categorie, $h/adresse/ville, $h/nom, $h/adresse) ($h/adresse/ville, $v/trajet, $v/trajet/arrivee ,($h/adresse/ville, $h/nom, $h/adresse)) ($v/num, $v/trajet, ($h/nom, $h/adresse)) for $v in Collection ("*")/vols where $v/temps < 4 return <voyage> <vol> <num>$v/num</num> <trajet>$v/trajet</trajet> </vol> <hotels> for $h in Collection ("*")/hotels where $h/categorie="5" and $v/trajet/arrivee=$h/adresse/ville <hotel> <nom>$h/nom</nom> <adresse>$h/adresse</adresse> </hotel> </hotels> </voyage> CONSTRUCTION DE L'ARBRE ALGEBRIQUE Comme nous l’avons vu précédemment, on peut générer un arbre algébrique à partir d’une requête XQuery. [CLIC] Les différents opérateurs que l’on choisit d’utiliser sont semblables aux opérateurs relationnels et ils sont appelés XOpérateurs. Ils sont paramétrés par les chemins dont ils ont besoin dans la XRelation. Pour cela, lors de la phase de construction, on détermine quels sont les chemins utiles dont les XOpérateurs auront besoin dans les XRelations qu’ils manipuleront. De la sorte, on n’indexera pas tous les noeuds d’un document XML, mais seulement ceux dont on a et aura besoin dans chaque opérateur. [PAGE] Tuyêt Trâm DANG NGOC - Université de Versailles

Tuyêt Trâm DANG NGOC - Université de Versailles XOpérateurs a b c XSource <SAX/> XSource Opérateurs relationnels XProjection XRestriction XJointure Opérateurs ensemblistes XUnion XIntersection XDifférence Tris XOrder-By Agrégats XMin XMax XCount XReconstruction a b c XUnion XJointure a b c d e f XProjection b c a Tri a b c XRestriction a b c XMin a b c g Je vais vous présenter les XOpérateurs de la XAlgèbre. Tous sont paramétrés avec les chemins XPath dont ils ont besoin, par manque de place,je les appellerai a, b, c mais en réalité, il s’agit de noms comme personne/nom, personne/adresse/rue ou voiture/couleur. XSource Le premier opérateur est XSource, il prend comme paramètre en plus des chemins à considerer, une requête et une source sur laquelle l’appliquer. Son rôle est de construire les XTuples en créant la forêt d’arbre et en effectuant les référencements nécessaires dans les XAttributs. Lors de évaluation, le flux d’entrée est le flux SAX donné par l’adaptateur. L’ordre des XTuples est l’ordre donné par la source, et l’opérateur est non-bloquant, c’est à dire que l’opérateur suivant peut commencer à traiter les premiers XTuples pendant que XSource accumule les suivant. XProjection XProjection prend comme paramètre les chemins sur lesquels projeter. Par exemple, ici les colonnes b et c. L’évaluation se fait en détruisant simplement les colonnes non désirées et en supprimant les sous arbres qui y étaient référencés. L’ordre est préservé et l’opérateur est non bloquant. XRestriction La XRestriction se fait en détruisant les XTuples dont les critères ne correspondent pas à ceux donnés en paramètres. Encore ici, l’opérateur est non-bloquant et l’ordre est préservé. [PAGE] XReconstruct a b c <SAX/> Tuyêt Trâm DANG NGOC - Université de Versailles

Tuyêt Trâm DANG NGOC - Université de Versailles Plan Contexte Intégration de données Évaluation de requêtes Validation Optimisation Conclusion et perspectives Validation Prototypes (projets MIROWEB, XML-KM et MUSE) Cas d'utilisation (use-case du XQuery Working Group) Performance (benchmark TPC-R adapté) VALIDATION Mon travail sur les médiateur s’est fait tout au long de trois projets et a été implémenté à chaque fois en suivant l’évolution de la technologie standard. [CLIC] Tout d’abord je situerai les prototypes dans lesquels l’implémentation du médiateur s’est effectué. Ce qui démontrera la faisabilité de l’architecture. Ensuite, nous avons eu une approche qualitative en essayant de répondre à éventail de cas d’utilisation recommandée par le W3C. Enfin, nous verrons une approche quantitative en regardant des mesures de performance sur un banc d’essai spécifique. [PAGE] Tuyêt Trâm DANG NGOC - Université de Versailles

Tuyêt Trâm DANG NGOC - Université de Versailles Evaluation (1/2) 1400 1200 1000 nombre de documents résultats temps (en ms) 800 600 400 200 500 1500 2000 2500 3000 Total Eval_Med Init Wrapper rapport des temps 500 1000 1500 2000 2500 3000 nombre de documents résultats 1 2 3 4 5 6 7 8 9 Rapport On teste l’évaluation d’une requête XQuery sur un médiateur au dessus d’un seul adaptateur pour se faire une idée du surcoût induit par l’architecture de médiation. La première courbe porte sur le temps d’exécution en millisecondes en fonction du nombre de noeuds résultat. La courbe la plus au dessus représente le temps total d’exécution. La courbe du dessous le temps d’évaluation sur le médiateur seul. La courbe encore en dessous le temps passé sur l’adaptateur. Et enfin la courbe la plus en dessous, représente le temps d’initialisation de la requête. Dans la courbe de droite, il s’agit des rapport entre le temps passé sur le médiateur et le temps passé sur l ’adaptateur. On voit que le rapport est constant. Cet expérience montre le coût élevé de communication pour l’échange de documents XML entre les adaptateurs et les médiateurs. L’une des premières amélioration à apporter est la réduction du coût de communication. [PAGE] M1 A1 col1 S1 Temps d’exécution en millisecondes en fonction du nombre de documents résultat sur différentes étapes Rapport des temps médiateur et adaptateur Coût de communication Tuyêt Trâm DANG NGOC - Université de Versailles

Tuyêt Trâm DANG NGOC - Université de Versailles Evaluation (2/2) S1 S2 col1 col2 M2 A1 A2 S3 col2 col1 M3 A3 nombre de documents résultats temps (en ms) 60000 50000 40000 30000 20000 10000 1000 2000 3000 4000 5000 6000 7000 Médiateur M2 Dans cette expérience ont effectue une requête faisant intervenir une jointure entre des collection situées sur deux sites différents. L’algorithme de jointure utilisée ici est une jointure : produit cartésien suivit d’une restriction. C’est évidemment long et cela montre aussi le coût de communication dominant. Une solution serait d’avoir une batterie d’implémentation d’algorithme pour chaque opérateur et choisir la plus appropriées suivant le contexte. Pour la jointure, on pourrait avoir par exemple avoir dans cette batteires, les algorithmes de jointure par boucle imbriquée, requête sur un site avec les résultats de l’autres, jointure par boucle imbriquées, etc. [PAGE] Jointure inter-sites Algorithmes de jointures à optimiser Temps de communication dominant Tuyêt Trâm DANG NGOC - Université de Versailles

Tuyêt Trâm DANG NGOC - Université de Versailles Plan Contexte Intégration de données Evaluation de requêtes Validation Optimisation Conclusion et perspectives OPTIMISATION Nous avons vu dans les expériences précédentes qu’il y avait certains points à améliorer pour augmenter les performances du médiateur. Cela passe par l’amélioration des algorithmes d’évaluation des différents opérateurs (jointure en particulier) mais d’autres stratégies sont aussi proposées. [CLIC] Evaluation des performances (modèle de coût) Avant d’évaluer une requête, on peut vouloir estimer le temps que son évaluation prendra grace à des statistiques, des formules, etc. De la sorte, si on a plusieurs manière de résoudre une requête, en estimant le coût de chacun de ces méthodes, on saura choisir celle de moindre coût. Réutilisation des résultats (cache sémantique) Une autre façon d ’améliorer les performances est de conserver les résultats de requêtes qui ont déjà été évaluées afin de pouvoir répondre à des requêtes de même type. Prise en compte des limitation des sources Enfin, pour optimiser le travail de développement des adaptateurs, il faut intégrer le fait que certains adaptateurs ont des capacités de traitement limité. [PAGE] Optimisation Evaluation des performances (modèle de coût) Réutilisation des résultats (cache sémantique) Prise en compte des limitations des sources Tuyêt Trâm DANG NGOC - Université de Versailles

Tuyêt Trâm DANG NGOC - Université de Versailles Modèle de coût Coût d’une architecture de médiation Calibration [PEGASUS] pour données objet [IRO-DB] requêtes types pour calibrer paramètres de la source Historique [HERMES] s’appuie sur les statistiques des requêtes précédentes Défini par les adaptateurs [GARLIC] défini séparément pour chaque adaptateur + coût par défaut Générique [DISCO] intégrer coût des adaptateurs + coût par défaut + hiérarchie de coût Coût sur données semi-structurées Coût sur modèle semi-structuré dans un entrepôt [LORE] Modèle de coût générique + adaptation au semi-structuré coût des XOpérateurs langage de coût en XML MODELE DE COUT Coût d’une architecture de médiation Définir un modèle de coût pour des architectures de médiation n’est pas nouveau, et a fait l’objet de plusieurs travaux. Calibration [PEGASUS] Il s’agit de rechercher des requêtes-types afin de déterminer les constantes de la source à étudier et d’estimer les paramètres qui la régissent. Cette méthode a ensuite été affinée par échantillonnage, s’adaptant à l’environnement, et étendu à des modèles objets en introduisant les coûts de suivis de pointeurs. Historique [HERMES] Cette méthode s’appuie sur les statistiques des requêtes précédentes, tant en unités de temps qu’en cardinalité des résultats obtenus. Défini par les adaptateurs [GARLIC] Le coût des sous-requêtes traités par les adaptateurs et leur source doit être estimé par un modèle de coût défini séparément par chaque adaptateur. Générique [DISCO] DISCO étend ce modèle en proposant une hiérarchie de modèle de coût pouvant utiliser aussi bien un modèle de coût par défaut que des coûts par calibration, échantillonnage et par historique. L’originalité de cette méthode est basé sur deux aspect principaux : La première est qu’elle propose en plus de la hiérarchie des modèle de coût (coût défini par l’adaptateur pour une certaine collection plus significative qu’un coût par défaut de cet adaptateur). La seconde est un langage d’exportation de coût permettant aux adaptateurs de communiquer ses formules et statistiques de coût au médiateur. Coût sur données semi-structurées Les travaux sur les modèles de coût sur les données semi-structurées sont plus récents et moins nombreux. Coût sur modèle semi-structuré dans un entrepôt [LORE] On peut citer surtout des modèles de coûts sur une source de données semi-structurées. Coût sur architecture de médiation de données semi-structurées Les travaux sur les modèles de coût sur les architectures de médiation de données semi-structurées sont à ce jour quasi-inexistant. [PAGE] Tuyêt Trâm DANG NGOC - Université de Versailles

Langage de communication de coût <cost-model> ... <math xmlns="http://www.w3.org/1998/Math/MathML"> <declare type="real"> <ci> ma_var2 </ci> <apply> <plus> <ci> MA_VAR1 </ci> <ci> ma_fonction </ci> <ci> ES </ci> <cn> 36 </cn> </apply> </plus> </declare> </math> Communication du coût entre l'adaptateur et le médiateur Basé sur XML Utilise le format mathématique MathML Communication du coût entre l'adaptateur et le médiateur Pour pouvoir permettre aux adaptateurs de communiquer leurs statistiques et formule de coût au médiateur, j’ai défini un langage de coût à l’instar du langage d’exportation de coût de DISCO. Basé sur XML Mais pour coller à l’architecture de médiation « tout XML » que nous avons défini, j’ai choisi d’utiliser un langage de coût basé sur XML. Utilise le format mathématique MathML Ce langage de coût utilise pour définir les formules, MathML. MathML est un langage basé sur XML utilisé par les mathématiciens et reconnu par plusieurs logiciels mathématiques comme Maple et Mathematica. Ce qui en passant, pourrait servir à utiliser un calculateur externe pour calculer des statistiques sur les coûts des opération. [CLIC] Adapté au semi-structuré J’ai de plus défini certaines balises utilisable dans un contexte semi-structuré : la profondeur des documents XML, les nombre de fils moyen par noeuds, etc. [PAGE] ma_var2 := MA_VAR1 + ma_fonction (ES, 36) Adapté au semi-structuré Profondeur des arbres Temps de référencement d’un noeud fils Nombre de fils moyen par noeuds Tuyêt Trâm DANG NGOC - Université de Versailles

Tuyêt Trâm DANG NGOC - Université de Versailles Cache sémantique Contenance des prédicats Garder un historique des prédicats de requêtes déjà posées. requête dans le cache local requête complémentaire actualiser le cache Utiliser un SGBD semi-structuré natif comme cache PDOM, NatiX, Tamino, ReposiX identifiants uniques d’éléments date > 1966 date > 1976 Contenance des chemins a/b a/b/c a b c d e On constate que les sources étant réparties un peu près partout sur l’Internet, il peut s’avérer très coûteux d’accéder à une source. Et donc, on essaye d’économiser au maximum les connexions à une source distante. Garder un historique des prédicats de requêtes déjà posées Le principe est de se dire qu’on pourrait utiliser les résultats de requêtes déjà posées pour pouvoir répondre à des requêtes similaires. [CLIC] Par exemple soit la requête portant sur une date comprise entre 1966 et 1981. Imaginons qu’on pose une nouvelle requête portant sur une date comprise entre 1976 et 1980. On voit que si l’on avait conservé les résultats de la requête précédente dans un cache, on pourrait alors l’utiliser pour répondre à la requête sans avoir à re-interroger les sources. Dans ce cas-ci, la requête s’est faite entièrement dans le cache local et la source n’a pas eu besoin d’être interrogée. Soit une autre requête portant sur une date comprise entre 1977 et 2000. On constate dans ce cas que le cache ne suffit pas pour répondre entièrement à la requête, mais peut y répondre en partie. Dans ce cas le cache est exploitée pour répondre à la requête : date comprise entre 1977 et 1981, et la source distante sera interrogée sur les dates comprises entre 1981 et 2000. Cela permet de limiter le nombre de tuples renvoyé et donc le temps de communication total. Le cache doit ensuite être mis à jour. Enfin, il peut arriver des cas où le cache ne peut pas du tout répondre à la question, par exemple pour chercher les dates supérieures à 2002. Dans ce cas la source distante est interrogée, et le cache doit être mis à jour. Utiliser un SGBD semi-structuré natif comme cache L’idée pour pouvoir stocker les résultats de requêtes déjà posée est d’utiliser un SGBD natif XML, c’est à dire un SGBD dédié à XML. Ce SGBD natif peut être pris parmi les SGBD commerciaux comme tamino ou les prototypes de recherche comme PDOM, NatiX ou ReposiX. Dans notre architecture intégrant un cache, on choisira un SGBD natif utilisant des identifiants uniques permettant d’accéder aux éléments stockés. [PAGE] Tuyêt Trâm DANG NGOC - Université de Versailles

Langage de description des capacités d’interrogation <ruleset> <rule num="10"> <permission> allow </permission> <relationalop> scan </relationalop> </rule> <rule num="100"> <relationalop> select </relationalop> <collection1> <hotel><categorie></categorie></hotel> </collection1> <operator> less </operator> <rule num="200"> <permission> deny </permission> <rule num= "300"> <relationalop> project </relationalop> <collection1> voiture </collection1> <rule num="65535"> </ruleset> Sources de capacités d’interrogation différentes Adaptateur peut pallier certaines déficiences de la source Le médiateur pallie les déficiences de l’adaptateur+source J’ai proposé un langage de communication de capacité de traitement entièrement basé sur XML. Les capacités sont exprimés sous forme de règles (accepté/non accepté) ordonnées portant sur les opérations, les collections et les chemins. Des règles de simplification étant données pour l’évaluation de ces règles. [PAGE] num perm operat coll att comp 10 allow scan 100 select hotel categorie less 200 deny 300 project 65535 Tuyêt Trâm DANG NGOC - Université de Versailles

Tuyêt Trâm DANG NGOC - Université de Versailles Plan Contexte Intégration de données Évaluation de requêtes Validation Optimisation Conclusion et perspectives CONCLUSION Nous allons à présent conclure en : [CLIC] Résumant et en montrant les contributions que j’ai apporté par mon travail de recherche ET en montrant les perspectives d’évolution de mon travail. [PAGE] Conclusion et perspectives Synthèse & Contributions Perspectives Tuyêt Trâm DANG NGOC - Université de Versailles

Synthèse & contributions Architecture « Tout-XML » respecte les standards XML au maximum évolutivité et modularité XAlgèbre : définition et évaluation Extension de l’algèbre relationnelle : simple Phase de compilation + Évaluation en flux Module d’optimisation modèle de coût + langage d’exportation cache sémantique en utilisant un SGBD natif XML Extensions langage d’exportation de capacité adaptation de TPC-R à un contexte distribué hétérogène Je vais exposer les contributions que j’ai pu apporter par cette thèse. Par manque de temps, toutes n’ont pas été exposées dans cette présentation. Certaines ont été implémentées et validées. D’autres ont juste fait l’objet d’une étude théorique . Architecture « Tout-XML » respecte les standards XML au maximum évolutivité et modularité j’ai défini un cadre pour l’évaluation de requête hétérogènes semi-structurées en utilisant au maximum les standards actuels. J’ai défini une architecture « tout-XML », c’est à dire entièrement basée sur la technologie XML. Ainsi, j’ai utilisé des interfaces applicatives entièrement basées sur XML, des langages d’information de coût, de capacité, de métadonnées et de définition d’adaptateurs tous, utilisant le format XML. Le langage de requête à base de XQuery et la programmation basée sur la normalisation XML avec SAX et DOM ainsi que l’utilisation de XML comme pivot d’échange. Tout cela permet une modularité maximale de chacun des composants et une évolutivité rapide. XAlgebre : définition et évaluation Extension de l’algèbre relationnelle : simple Phase de compilation + Evaluation en flux J’ai proposé une structure d’algèbre permettant d’évaluer simplement et efficacement des requête XQuery sur des données XML. Cette structure d’algèbre est basée sur les flux de données SAX standard et comporte un mécanisme d’indexation d’arbre rangés de façon tabulaire pour allier la complexité des arbres de données semi-structurées à l ’efficacité des opérations sur les tableaux. Module d’optimisation modèle de coût + langage d’exportation Pour estimer le coût des requêtes, nous proposons des formules de coût pour ces nouveaux opérateurs. Afin d’intégrer les informations de coût des différentes sources, j’ai proposé un langage de coût adapté aux formules de coût semi-structuré. Ce langage de coût présente la nouveauté d’être exprimé en XML utilisant MathML un format XML utilisé en mathématique pour décrire des formules. cache J’ai montré comment un entrepôt natif XML peut s’intégrer dans une architecture de médiation en tant que SGBD local conservant les résultats de requêtes déjà effectuées. Nous avons vu aussi comment une nouvelle requête peut être comparée à des requêtes précédemment effectuées. Extensions langage d’exportation de capacité Pour permettre aux adaptateurs de communiquer les capacités des sources qui leur sont associées, un langage d’exportation de capacité basé sur XML a aussi été proposée. adaptation de TPC-R à un contexte distribué hétérogène dont des données semi-structurées En constatant pour réaliser des tests de performance du médiateur qu’il n’existe pas de banc d’essai permettant de tester à la fois la distribution des données et à la fois des données XML, j’ai proposé une extension du banc d’essai TPC-R. [PAGE] Tuyêt Trâm DANG NGOC - Université de Versailles

Tuyêt Trâm DANG NGOC - Université de Versailles Perspectives Optimisation des plans d’exécution trouver des règles d’équivalence sur l’algèbre générateur de plans d’exécution implémentation de meilleurs algorithmes pour les XOpérateurs requête paramétrée indicateurs (hints) intégrer la gestion des capacités dans la construction des plans d’exécution Modules d’optimisation compression des données échangées modèle de coût cache sémantique indexation des données Extensions intégration de fonctions externes : pour intégrer des sources multimédia utilisation du web sémantique En plus de l’approfondissement des travaux que je viens d’exposer. Je pense par la suite me consacrer à un certain nombre de recherche qui permettront de compléter utilement ces travaux. Ceux-ci portent : optimisation des plans algébriques Dans l’étude des plans algébrique et de leur optimisations. trouver des règles d’équivalence sur l’algèbre Un des objectifs est d’approfondir la XAlgèbre en trouvant des propriétés, des règles d’équivalence et en complétant cette XAlgèbre afin qu’elle soit la plus complète possible. générateur de plans d’exécution A partir des règles d ’équivalences on pourra à partir d’un plan d’exécution, créer un générateur de plans d’exécution équivalent (c-à-d donnant les mêmes résultats à l’exécution) intégration de la gestion des capacités Il faudra aussi pouvoir intégrer dans les calculs de coût et dans le générateur de plans d’exécution, la prise en charge des opérations non traitables par les adaptateurs. approfondir modules d’optimisation : modèle de coût Les formules de coût des XOpérateurs doivent être aussi affinées. cache sémantique Le cache sémantique devra être développé et intégré à la gestion des coûts et au générateur de plan d’exécution Enfin d’autres extensions pourront voir le jour compression des données échangées comme la compression des données échangées afin de réduire le coût de communication intégration de fonctions externes pour intégrer des sources multimédia l’intégration de fonctions externes afin d’intégrer des sources multimédia opérateurs de recherche plein texte nouvelle architecture : XLive + adaptateur web pour la catégorisation et de nouveaux adaptateurs comme un adaptateur web pour la recherche sémantique sur le web [PAGE] Tuyêt Trâm DANG NGOC - Université de Versailles

Questions ? Voilà, ma présentation est terminée, avez-vous des questions ? [PAGE] ?

Annexes XQuery Publications Banc d’essai Flux SAX et arbre DOM Use-cases Evolution technique Prototypes Exportation plan d’exécution Formules de coût Cache Métadonnées XTuple XLive Bibliographie XOpérateurs

Tuyêt Trâm DANG NGOC - Université de Versailles Publications (1/3) Projet MIROWEB G. Gardarin, F. Sha, T.-T. Dang-Ngoc, « XML-based Components for Federating Multiple Heterogeneous Data Sources. » ER 1999: 506-519 L. Bouganim, T. Chan-Sine-Ying, T.-T. Dang-Ngoc, J.-L. Darroux, G. Gardarin, F. Sha, « Miro Web: Integrating Multiple Data Sources through Semistructured Data Types. » VLDB 1999: 750-753 T.-T. Dang-Ngoc (Osis/PRiSM), D. Artal (Osis), C. Campanaro (Osis), P. Kirkham (Osis), H. Laude (Osis), A. Vuillier (Osis), « Integration Plan (ESPRIT-25208 Deliverable D3-1-2) », 1998 T.T. Dang-Ngoc (Osis/PRiSM), T. Chan-Sine-Ying (PRiSM), F. Chéron (Osis), G. Gardarin (PRiSM), P. Kirkham (Osis), H. Laude (Osis), « Browser Interface Specification (ESPRIT-25208 Deliverable D6-2-1) », 1998 T. Chan-Sine-Ying (PRiSM), T.T. Dang-Ngoc (Osis/PRiSM), D. Florescu (Inria), C. Campanaro (Osis), P. Kirkham (Osis), « Message Manager Specification (ESPRIT-25208 Deliverable D5-1-1) », 1998 Tuyêt Trâm DANG NGOC - Université de Versailles

Tuyêt Trâm DANG NGOC - Université de Versailles Publications (2/3) Projet XML-KM T.-T. Dang-Ngoc, G. Gardarin, « The XML Mediator. » Document technique interne à e-XMLMedia, 26p. Projet MUSE T.-S. Yeh, T.T. Dang-Ngoc, « Repository de méta-données (RNTL Specification SP-3) », 2001 G. Gardarin, A. Mensch, T.-T. Dang-Ngoc, L. Smit, « Integrating Heterogeneous Data Sources with XML and XQuery. » DEXA Workshops 2002: 839-846 Tuyêt Trâm DANG NGOC - Université de Versailles

Tuyêt Trâm DANG NGOC - Université de Versailles Publications (3/3) En cours de soumission T.T. Dang-Ngoc, G. Gardarin « Evaluating XQuery in a full-XML Mediation architecture » Soumis à BDA’2003 T.T. Dang-Ngoc, G. Gardarin « Integrating Heterogeneous Data Sources » En cours de soumission à IASTED 2003 T.T. Dang-Ngoc, G. Gardarin « Architecture de médiation "Tout-XML". » En cours de soumission à la revue ISI (Integration de systèmes d'information) T.T. Dans-Ngoc, H. Kouh, G. Gardarin « Semantic Integration and XML Mediation For Web Information Search » En cours d'écriture pour WIDM’2003 Tuyêt Trâm DANG NGOC - Université de Versailles

Tuyêt Trâm DANG NGOC - Université de Versailles Mise en oeuvre (1/3) MIROWEB (médiateur v0) Lab. PRiSM + SSII Osis Ecriture d’un analyseur XML-QL Implémentation d’un médiateur simple basé sur une mise à plat des documents OEM Formation de document XML résultat Implémentation d’un adaptateur SQLX sur repository OEM et d’un adaptateur SQL sur oracle avec pour langage commun OEM Création d’un mini-dataguide Protocole d’envoi de message entre médiateur et interface client par socket et RMI Conception d’une interface graphique cliente Tuyêt Trâm DANG NGOC - Université de Versailles

Tuyêt Trâm DANG NGOC - Université de Versailles Mise en oeuvre (2/3) XML-KM (médiateur v1) lab. PRiSM puis éditeur e-XMLMédia Conception et implémentation d’un médiateur basé sur des documents OEM utilisant un mécanisme d’association (« binding ») sur variable. Reprise de l’analyseur XML-QL de MIROWEB Prise en charge simple de déficience de capacité de traitement des adaptateurs Création d’une base de méta-données Formation de document XML résultat Implémentation d’un adaptateur SQLX sur repository OEM et d’un adaptateur SQL sur oracle avec pour langage commun XML Conception d’une première version d’interface graphique d’administration simple. Tuyêt Trâm DANG NGOC - Université de Versailles

Tuyêt Trâm DANG NGOC - Université de Versailles Mise en oeuvre (3/3) MUSE (médiateur v2) Lab. PRiSM + éditeur e-XMLMédia Conception et implémentation d’un médiateur basé sur des documents XML utilisant la XAlgèbra. Conception et implémentation de la XAlgèbra Conception et implémentation d’un gestionnaire de métadonnées utilisant des XML-Schéma et différents index Création d’un adaptateur XML/DBC pour le médiateur. Participation aux spécifications d’un repository natif XML : ReposiX et implémentation d’un module d’indexation. Tuyêt Trâm DANG NGOC - Université de Versailles

Tuyêt Trâm DANG NGOC - Université de Versailles Reference Part ( R ) XTuples XAttributes person/lastname person/address Tree Part ( T ) person/name car/color Tree person car name name lastname address color age Superman Clark Kent street town blue 657 42 Metropolis person car color age name name lastname address Batman blue 1 Bruce Wayne street town 17 Gotham person car name lastname address color age Lois Lane street town blue 4 28 Metropolis person car age name name address color Spiderman Parker blue 13 street town Tuyêt Trâm DANG NGOC - Université de Versailles 121 New York

Tuyêt Trâm DANG NGOC - Université de Versailles XOpérateurs (1/3) XSource construction XAttribut construction forêt ordre de la source non-bloquant a b c XSource <SAX/> XProjection destruction de colonnes destruction de (sous-)arbres ordre préservé non-bloquant Je vais vous présenter les XOpérateurs de la XAlgèbre. Tous sont paramétrés avec les chemins XPath dont ils ont besoin, par manque de place,je les appellerai a, b, c mais en réalité, il s’agit de noms comme personne/nom, personne/adresse/rue ou voiture/couleur. XSource Le premier opérateur est XSource, il prend comme paramètre en plus des chemins à considerer, une requête et une source sur laquelle l’appliquer. Son rôle est de construire les XTuples en créant la forêt d’arbre et en effectuant les référencements nécessaires dans les XAttributs. Lors de évaluation, le flux d’entrée est le flux SAX donné par l’adaptateur. L’ordre des XTuples est l’ordre donné par la source, et l’opérateur est non-bloquant, c’est à dire que l’opérateur suivant peut commencer à traiter les premiers XTuples pendant que XSource accumule les suivant. XProjection XProjection prend comme paramètre les chemins sur lesquels projeter. Par exemple, ici les colonnes b et c. L’évaluation se fait en détruisant simplement les colonnes non désirées et en supprimant les sous arbres qui y étaient référencés. L’ordre est préservé et l’opérateur est non bloquant. XRestriction La XRestriction se fait en détruisant les XTuples dont les critères ne correspondent pas à ceux donnés en paramètres. Encore ici, l’opérateur est non-bloquant et l’ordre est préservé. [PAGE] a b c b c XProjection XRestriction destruction de lignes complète ordre préservé non bloquant a b c a b c XRestriction Tuyêt Trâm DANG NGOC - Université de Versailles

Tuyêt Trâm DANG NGOC - Université de Versailles XOpérateurs (2/3) a b c XUnion ordre préservé en mode bloquant, non préservé sinon bloquant ou non suivant paramétrage XUnion a b c a b c XJointure ajout de colonnes ajout/concaténation d’arbres ordre préservé en mode bloquant, non préservé sinon bloquant ou non suivant paramétrage On peut avoir aussi des XOpérateurs binaires, c-à-d qu’ils prennent deux flux d’entrées qu’ils peuvent paralléliser si nécessaire XUnion L’opérateur XUnion regroupe deux ensembles de tuples de même XAttributs. Il est parallélisable (les flux d’entrées peuvent être évalué indépendamment) et donc non bloquant. Cela entraîne un ordre non conservé (il y a enchevêtrement des tuples de chacune des entrées). En paramétrant pour que l’opérateur soit bloquant sur un des flux on peut néanmoins conserver l’ordre de chaque ensemble des tuples d’entrées. XJointure La XJointure regroupe deux ensembles de tuples suivant certains critères, en fusionnant les XAttributs. De la même manière que pour l’union, en paramétrant pour que l’opérateur soit bloquant sur un des flux on peut néanmoins conserver un certain ordre par rapport aux ordres d’arrivée. [PAGE] a b c XJointure d e d e f a b c Tuyêt Trâm DANG NGOC - Université de Versailles

Tuyêt Trâm DANG NGOC - Université de Versailles XOpérateurs (3/3) Tri (XSORT-BY) déplacement de lignes complètes bloquant a b c a b c Tri Fonction d’agrégat (Xmin, Xmax, Xcount) nouvelle colonne (1 ligne) nouveau arbre d’un noeud bloquant Tri Fonction d’agrégat Enfin, d’autres opérateurs comme le tri ou les agrégats sont définis dans la XAlgèbre. XReconstruct XReconstruct est le dernier XOpérateur de la XAlgèbre. Il permet à partir d’un flux de XTuple en entrée de générer un flux SAX à partir d’une requête de reconstruction donnée en paramètre. Ce flux SAX pourra alors être utilisé pour reconstruire le document XML final. [PAGE] Agrégat a b c g XReconstruct génération d’un flux SAX résultat A partir d’une requête de reconstruction a b c XReconstruct <SAX/> Tuyêt Trâm DANG NGOC - Université de Versailles

Tuyêt Trâm DANG NGOC - Université de Versailles XProjection Tuyêt Trâm DANG NGOC - Université de Versailles

Tuyêt Trâm DANG NGOC - Université de Versailles XJointure Tuyêt Trâm DANG NGOC - Université de Versailles

Tuyêt Trâm DANG NGOC - Université de Versailles XProduit Tuyêt Trâm DANG NGOC - Université de Versailles

Tuyêt Trâm DANG NGOC - Université de Versailles XNest Tuyêt Trâm DANG NGOC - Université de Versailles

XLive (XML Light Integration Virtual Engine) USER XML GUI HTML XQuery XQuery parser Capability manager Presentation XSL XQuery internal structure XPlan generator Cost manager XML Native Database MEDIATOR SAX event flow XAlgebra Metadata manager Indexation XPlan optimizer Flow evaluation Cache SAX event flow XML-Schema XQuery Connection manager XQuery XQuery XQuery XML XML XML SOAP SOAP SOAP SOURCE Oracle 9i wrapper Web wrapper Web wrapper oracle XDB GET, POST HTML GET, POST HTML Oracle 9i WEB Tuyêt Trâm DANG NGOC - Université de Versailles

Evolution technique XML parse XML -> DOM -> SAX SQLX -> XML-QL -> XQuery dataguide, DTD -> XML-Schema OEM -> XML socket -> RMI -> SOAP Tuyêt Trâm DANG NGOC - Université de Versailles

Tuyêt Trâm DANG NGOC - Université de Versailles Use-cases traité non-traité domaine description numéro de requêtes 1 XMP exemples généraux 1 2 3 4 5 6 7 8 9 10 11 12 2 TREE préservant la hiérarchie 1 2 3 4 5 6 3 SEQ basées sur les séquences 1 2 3 4 5 4 R accès aux données relationnelles 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 5 SGML basé sur tests SGML 1 2 3 4 5 6 7 8 9 10 6 STRING recherche de chaîne de caractères 7 NS utilisant les espaces de noms 1 2 3 4 5 6 7 8 8 PARTS récursivité et références externes 1 9 STRONG utilisant des données fortement typées Tuyêt Trâm DANG NGOC - Université de Versailles

Tuyêt Trâm DANG NGOC - Université de Versailles Métadonnées (1/2) Tuyêt Trâm DANG NGOC - Université de Versailles

Tuyêt Trâm DANG NGOC - Université de Versailles Métadonnées (2/2) Tuyêt Trâm DANG NGOC - Université de Versailles

Tuyêt Trâm DANG NGOC - Université de Versailles Bancs d’essai (1/2) M0 (b) M1 M2 M3 A1 A2 A3 A4 A5 A6 A1 A2 A3 A4 A5 A6 M4 A7 (c) (a) Tuyêt Trâm DANG NGOC - Université de Versailles

Tuyêt Trâm DANG NGOC - Université de Versailles Banc d’essai (2/2) Tuyêt Trâm DANG NGOC - Université de Versailles

Exportation du plan d’exécution en XML... pour garder des requêtes « compilées » pour interroger un adaptateur avec un autre (ex. pour jointure inter-site) <pl:plan> <pl:xrecompose> <pl:param> <hotel> <name>$h/nom</name> <adresse>$h/adresse</> </hotel> </pl:param> <pl:xrestrict> <pl:constraint> <pl:left>$h/category</> [...] M W W Tuyêt Trâm DANG NGOC - Université de Versailles

Tuyêt Trâm DANG NGOC - Université de Versailles LAV/GAV Base de données « vue universelle » Schéma fédéré vue complexe, multi-relation qui transforme les sources et combine les informations processeur de requêtes LAV Profil de la source Profil de la source Tuyêt Trâm DANG NGOC - Université de Versailles

Tuyêt Trâm DANG NGOC - Université de Versailles Compression Pour gagner en temps de communication Compression par blocs Compression par chemins [...] <a> <b>b1</b> <c> <d>d1</d> </c> </a> <b>b2</b> <d>d2</d> <b>b3</b> [...] <a> <b> b5 </b> <c> <d> d5 </d> </c> </a> <b> b6 </b> <d> d6 </d> <a> <b> b3 </b> <c> <d> d3 </d> </c> </a> <b> b4 </b> <d> d4 </d> <a> <b> b1 </b> <c> <d> d1 </d> </c> </a> <b> b2 </b> <d> d2 </d> 1 : b1 2 : d1 / 1 : b2 2 : d2 1 : b3 2 : d3 a/b : 1 a/c/d : 2 [...] Tuyêt Trâm DANG NGOC - Université de Versailles

Tuyêt Trâm DANG NGOC - Université de Versailles Réplication Utilisation de deux sources identiques ou partielles pour aller plus vite Mises à jour Information au générateur de plan d’exécution Peer-to-peer (information sur les voisins, répartition, sources tombant en panne) Pour gérer des sources tombant en panne Médiateur Adaptateur S1 Tuyêt Trâm DANG NGOC - Université de Versailles

Langages d’interrogation Besoins : Opérateurs standards de requêtes sur bases de données Navigation dans les données Recherche par motifs Interrogation du schéma et des données Construction du résultat Type de langages Extension de langages classiques : SGMLQL, HyOQL, LOREL/OEM-QL Conçus pour le semi-structuré : XML-QL, XQL, QUILT Normalisation : XPath, XQuery XQuery FLWRExpr ::= (ForClause | LetClause)+ WhereClause? "return" Expr ForClause ::= "for" Variable "in" Expr ("," Variable "in" Expr)* LetClause ::= "let" Variable ":=" Expr ("," Variable ":=" Expr)* WhereClause ::= "where" Expr LANGAGES D'INTERROGATION Il faut pouvoir interroger les données et définir un langage d'interrogation. Dans le modèle relationnel, on utilise par exemple SQL, dans le modèle objet, on peut utiliser le langage OQL. Pour le modèle de donnée semi-structurée un langage approprié a du être inventé. Pour s'adapter à ce type de donnée, ses caractéristiques doivent être : Besoins : Opérateurs standards de requêtes sur bases de données être assez puissant pour formuler des requêtes complexes de sélection, restriction, jointure, union, intersection, etc. à l'instar des langages de requêtes sur SGBD classiques. Navigation dans les données Les données sont arborescentes et n'ont pas de schéma fixe, il faut pouvoir parcourir les structures pour récupérer les informations demandées. Recherche par motifs Les données peuvent être documentaires et sont souvent utilisées pour présenter des informations sur le web. Il faut pouvoir faire des recherches de mots dans un texte. Les chemins étant imprécis du fait de la structure floue des données, on doit utiliser des Interrogation du schéma et des données Comme la structure n'est pas connue, on doit aussi bien pouvoir faire des recherches sur les données que sur leur structure. Construction du résultat Enfin, il faut pouvoir récupérer le résultat et le présenter sous une structure voulue. Pour cela le langage doit permettre de construire un résultat. Type de langages Différents langages ont été proposés : Extension de langages classiques : SGMLQL, HyOQL, LOREL/OEM-QL Certains ont simplement étendu des langages classiques relationnels ou objet aux données semi-structurées comme SGMLQL, HyOQL, et OEM-QL Conçus pour le semi-structuré : XML-QL, XQL, QUILT D'autres langages ont été conçu spécialement pour les données semi-structurées, et en particulier pour le format XML. Normalisation : XPath, XQuery Le langage de requête a finalement été normalisé par l'organisme de standardisation W3C, le langage XQuery a été retenu. XPath est un sous-ensemble de XQuery normalisé lui aussi, permettant de sélectionner des points précis d'une information. [PAGE] Tuyêt Trâm DANG NGOC - Université de Versailles

Gestion de vues et trigger Gestion de vues matérialisée. Mise à jour par déclencheurs (trigger) actifs /passifs Utilisation de cache pour vues matérialisées sous la forme d’un SGBD XML natif Web Site Loader Warehouse SEWISE View Manager XQuery Processor XML Coordinator Client XQuery Logger OK Tuyêt Trâm DANG NGOC - Université de Versailles

Document XML – Flux SAX – Arbre DOM startDocument () startElement (personne) startElement (nom) characters (Cover) endElement (nom) startElement (prenom) characters (Harry) endElement (prenom) startElement (adresse) startElement (rue) characters (Stendhal) endElement (rue) startElement (ville) characters (Paris) endElement (ville) endElement (adresse) endElement (personne) endDocument () <personne> <nom> Cover </nom> <prenom> Harry </prenom> <adresse> <rue> Stendhal </rue> <ville> Paris </ville> </adresse> </personne> personne nom prenom adresse rue ville #text: Cover #text: Paris #text: Stendhal #text: Harry [PAGE] Tuyêt Trâm DANG NGOC - Université de Versailles

Tuyêt Trâm DANG NGOC - Université de Versailles Intégration du cache Evaluateur du médiateur date > 1976 date > 1966 Contenance des prédicats id3 id4 id8 Base d’histo- rique id2 id9 id2 id10 [CLIC] Intégration du cache dans le médiateur L’intégration du cache dans le médiateur se fait de la manière suivante. Plutôt que d’interroger les sources, l’évaluateur du médiateur interroge une base d’historique qui donnera la réponse à la requête soit en interrogeant le cache local, soit en interrogeant la source distante et en réactualisant le cache local. Le cache local est un SGBD XML natif. Les noeuds de documents sont représentés par des identifiants unique permettant de les répertorier dans la base d’historique. Contenance des prédicats [HERMES] La mise en oeuvre d’un cache sémantique pour architecture de médiation fait intervenir des algorithmes sur les contenance de prédicat c-a-d vérifier si un prédicat est plus restrictif qu’un autre pour déterminer quelle partie sera résolue par le cache et quelle partie sera résolue par la source. Contenance des chemins [XCache] Dans une architecture de médiation pour données semi-structurées, il faut en plus tenir compte des chemins. Ainsi a/b/c est contenu dans a/b [PAGE] CACHE … id3 Adaptateur id4 Entrepôt natif de données semi- struc- turées a/b a/b/c a b c d e Contenance des chemins … Source Mémoire secondaire Tuyêt Trâm DANG NGOC - Université de Versailles

Modèle de coût pour médiation de données semi-structurées (1/2) Modèle de coût générique + adaptation au semi-structuré Intégration du modèle de coût communiqué par les adaptateurs Modèle de coûts suivant des formules et statistiques communiquées modèle de coût par défaut hiérarchie des coûts Modèle de coût au niveau du médiateur Formule de coût des XOpérateurs coût d’un opérateur XSource coût = coût_source + communication + construction_XTuple L’approche que nous avons est une extension du modèle de coût générique proposé défini dans DISCO au modèle semi-structuré. C’est à dire qu’on peut utiliser plusieurs sorte de modèle de coût : par calibration, par historique, par échantillonnage, etc. suivant les formules de coûts données par les adaptateurs. Dans le cas où les formules de coûts ne sont pas communiquées, on utilise un modèle de coût par défaut (cout = temps à froid + (n – 1) * temps à chaud) Lors de l’évaluation du coût, on utilise le modèle de coût le plus spécifique pour les adaptateurs. Pour le coût au niveau du médiateur, il s’agit de définir le coût de chaque XOpérateur. Coût d’un opérateur XSource Pour un opérateur XSource, il s’agit du coût de la source comme intégrée précédemment plus un coût de communication plus le coût de construction du XTuple. [PAGE] Tuyêt Trâm DANG NGOC - Université de Versailles

Coût des Xopérateurs (2/2) fils1 … filsn coût d’un opérateur autre que XSource coût= coûts_fils + coût_op où coûts_fils  [max (coût_filsi), (coût_filsi) suivant le degré de parallélisme Due à la structure des XTuples, le coût d’un XOpérateur est celui de l’opérateur relationnel plus un éventuel coût de manipulation sur les arbres Exécution d'un XOpérateur phase de pré-compilation (effectuée une seule fois) phase d'exécution (effectuée pour chaque XTuple) Dans le cas d’autre XOpérateur que XSource, le coût d’exécution est égal au coût de chacun de ses fils plus le coût du XOpérateur lui-même. Suivant le degré de parallélisme, le coût des fils sera compris entre le coût maximal des fils (si le parallélisme est parfait) et leur somme (dans le cas où l’exécution sur les fils est sérialisé) On a vu que les XTuples se comportaient comme l’opérateur relationnel équivalent. Il faut néanmoins intégrer pour certains XOpérateurs un certain coût de manipulation d’arbres (élagation, recherche dans un sous-arbre, fusion d’arbre) Exécution d’un XOpérateur L’évaluation se déroule en deux parties : une phase de compilation. Elle est effectuée une fois pour toute et permet de décider quel morceau d’arbre devra être élagué, quel XAttribut en inclue un autre, etc. Une phase d’exécution qui est effectuée pour chaque XTuple suivant le résultat de la compilation. [PAGE] Tuyêt Trâm DANG NGOC - Université de Versailles

Tuyêt Trâm DANG NGOC - Université de Versailles Bibliographie (1/2) Données semi-structurées [Abiteboul1997] S. Abiteboul. Querying Semistructured Data. In proc of the 6th Intl. Conf. on Database Theory, 1997 Architecture de médiation [Wierderhold1992] G. Wiederhold. Mediator in the Architecture of Future Information System. Computer, 25 (3), 1992 Algèbre XML [Beech et al.1999] D. Beech, A. Malhotra, et M. Rys. A Formal Data Model and Algebra for XML. 1999. [McHugh et Widom1999] J. McHugh, S. Abiteboul, R. Goldman, D. Quass, et J. Widom. LORE: A Database Management System for Semistructured Data. SIGMOD Record, 26(3):54-66, 1997. [Fernandez et al.2001] M. Fernandez, J. Simeon, et P. Walder. A Semi-Monad for Semi-structured Data. In International Conference on Database Theory, Janvier 2001. Tuyêt Trâm DANG NGOC - Université de Versailles

Tuyêt Trâm DANG NGOC - Université de Versailles Bibliographie (2/2) Modèles de coût calibration [Du1992] W. Du, R. Krishnamurthy, et M.-C. Shan. Query optimization in a heterogeneous DBMS. In proc. VLDB, 1992. historique [Adali1996] S. Adali, K. Candan, et Y. Papakonstantinou. Query Caching and Optimization in Distributed Mediator Systems. In ACM SIGMOD, 1996. par adaptateur [Haas1997] L.M. Haas, D. Kossmann, E.L. Wimmers, et J. Yang. Optimizing Queries Across Diverse DataSources. In VLDB, 1997. générique [Naacke1998] H. Naacke, G. Gardarin, et A. Tomasic. Leveraging Mediator Cost Models with Heterogeneous Data Sources. In ICDE, 1998. semi-structuré [Widom1999] J. McHugh et J. Widom. Query Optimization for XML. In proc. VLDB, 1999. Caches sémantique [Adali1996] S. Adali, K. Candan, et Y. Papakonstantinou. Query Caching and Optimization in Distributed Mediator Systems. In ACM SIGMOD, 1996. Tuyêt Trâm DANG NGOC - Université de Versailles

Transparents supprimés

Cas d’utilisation et bancs d’essai Prototype projet ESPRIT MIROWEB projet ESPRIT XML-KM projet RNTL MUSE Tous ont inclus le médiateur sous différentes versions. Cas d’utilisation Parmi les cas d’utilisation proposés par le W3C, tout ceux spécifiques à l’orientation actuelle du médiateur sont évalués correctement (requêtes sur SGBD relationnels, médiation de différentes sources) Bancs d’essai Adaptation de TPC-R à un modèle distribué et hétérogène dont semi-structuré Premières mesures de performances encourageantes version 0 : XML-QL version 1 : XML-QL version 2 : XQuery [CLIC] Prototype projet ESPRIT MIROWEB Partenaires du projet : Ibermatica (Espagne), Bull (France), OSIS (France), BHS (Espagne), TIS (Autriche) et l'INRIA (France) L'objectif du projet MIROWEB est de construire un système d'accès à des sources de données hétérogènes sur le Web. Nous avons pour cela conçu une architecture de médiation à base de médiateur et adaptateurs sur le modèle DARPA I3. Le modèle de données commun est un modèle de type OEM, le langage d'interrogation est XML-QL et les résultats sont exprimés en XML. L'expérimentation a été effectuée sur deux applications pilote : un système d'information hospitalier et une application basée sur le tourisme. Les sources intégrées ont été un entrepôt XML basées sur Oracle 8, et le SGBD relationnel Oracle 8i. projet ESPRIT XML-KM Partenaires du projet : Ibermatica S.A (Espagne), e-XMLMedia (France), SITESA (Espagne), TIS GmbH (Autriche), Cámara Oficial de Comercio, Industria y Navegación de Gipuzcoa (Espagne) Le projet XML-KM consiste en l'intégration d'applications existantes sur le commerce et le tourisme avec un système d'information géographique et un entrepôt de données. Nous sommes pour cela parti des bases du médiateur de MIROWEB, et nous avons fait évoluer la définition des adaptateurs afin de permettre la définition générique d'autres adaptateurs (un adaptateur de descripteur de cartes réalisés par SITESA (Espagne). projet RNTL MUSE Partenaires du projet : Editing, PRiSM, ECL, ICCT, e-XMLMedia Le projet MUSE a pour objectif la conception et la réalisation d'un moteur de recherche ciblé permettant de découvrir rapidement des données XML pouvant inclure des documents multimédia. La version v1 du médiateur a été réécrite afin de de supporter le langage XQuery au lieu de XML-QL, avoir pour modèle commun et modèle résultat XML, coller autant que possible aux normes du W3C. Et définir une interface normalisée d'interaction d'importation et d'exportation entre les adaptateurs et le médiateur. Tous ont inclus le médiateur sous différentes versions. Cas d’utilisation Le «  XML Query working group » du W3C a publié une liste de cas d’utilisation illustrant les applications du langage XQuery. Ces cas d’utilisation ou scénario sont regroupé en 9 domaines définissant chacune un ensemble de requête spécifique à un type d’application. Nous nous sommes orienté prioritairement sur l’aspect données plutôt que sur l’aspect requête, et nous avons ajouté certains cas d’utilisation permettant de mettre en valeur des requête sur des données distribuées. Bancs d’essai Adaptation de TPC-R à un modèle distribué et hétérogène Premières mesures de performances encourageantes Les bancs d’essai existants sont soit spécifique à des architectures de médiation classiques, c’est-à-dire qui sont soit objet, soit relationnel, soit spécifique à des évaluations de requête dans un document XML. Il n’existe pas de bancs d’essai portant sur une médiation de données semi-structuré. C’est pour cela que j’ai adapté le banc d’essai standard TPC-R à un modèle distribué hétérogène comprenant des données semi-structuré. Les premières mesures sont encourageantes. [PAGE] Tuyêt Trâm DANG NGOC - Université de Versailles

Tuyêt Trâm DANG NGOC - Université de Versailles Modèle de coût Coût d’une architecture de médiation Calibration [PEGASUS] requêtes types pour calibrer paramètres de la source affinée avec échantillonnage pour données objets [IRO-DB] Historique [HERMES] s’appuie sur les statistiques des requêtes précédentes Défini par les adaptateurs [GARLIC] modèle de coût défini séparément pour chaque adaptateur et coût par défaut pour coût manquant d’un adaptateur Générique [DISCO] intégrer modèle de coût des adaptateurs + hiérarchie de coût et coût par défaut pour coût manquant d’un adaptateur Coût sur données semi-structurées Coût sur modèle semi-structuré dans un entrepôt [LORE] MODELE DE COUT Coût d’une architecture de médiation Définir un modèle de coût pour des architectures de médiation n’est pas nouveau, et a fait l’objet de plusieurs travaux. Calibration [PEGASUS] Il s’agit de rechercher des requêtes-types afin de déterminer les constantes de la source à étudier et d’estimer les paramètres qui la régissent. Cette méthode a ensuite été affinée par échantillonnage, s’adaptant à l’environnement, et étendu à des modèles objets en introduisant les coûts de suivis de pointeurs. Historique [HERMES] Cette méthode s’appuie sur les statistiques des requêtes précédentes, tant en unités de temps qu’en cardinalité des résultats obtenus. Défini par les adaptateurs [GARLIC] Le coût des sous-requêtes traités par les adaptateurs et leur source doit être estimé par un modèle de coût défini séparément par chaque adaptateur. Générique [DISCO] DISCO étend ce modèle en proposant une hiérarchie de modèle de coût pouvant utiliser aussi bien un modèle de coût par défaut que des coûts par calibration, échantillonnage et par historique. L’originalité de cette méthode est basé sur deux aspect principaux : La première est qu’elle propose en plus de la hiérarchie des modèle de coût (coût défini par l’adaptateur pour une certaine collection plus significative qu’un coût par défaut de cet adaptateur). La seconde est un langage d’exportation de coût permettant aux adaptateurs de communiquer ses formules et statistiques de coût au médiateur. Coût sur données semi-structurées Les travaux sur les modèles de coût sur les données semi-structurées sont plus récents et moins nombreux. Coût sur modèle semi-structuré dans un entrepôt [LORE] On peut citer surtout des modèles de coûts sur une source de données semi-structurées. Coût sur architecture de médiation de données semi-structurées Les travaux sur les modèles de coût sur les architectures de médiation de données semi-structurées sont à ce jour quasi-inexistant. [PAGE] Tuyêt Trâm DANG NGOC - Université de Versailles

Tuyêt Trâm DANG NGOC - Université de Versailles Cache sémantique Garder un historique des prédicats de requêtes déjà posées. requête dans le cache local requête complémentaire actualiser le cache Utiliser un SGBD semi-structuré natif comme cache PDOM, NatiX, Tamino, ReposiX identifiants unique d’élément date > 1966 and date < 1981 cache = R source = Ø date > 1976 and date < 1980 On constate que les sources étant réparties un peu près partout sur l’Internet, il peut s’avérer très coûteux d’accéder à une source. Et donc, on essaye d’économiser au maximum les connexions à une source distante. Garder un historique des prédicats de requêtes déjà posées Le principe est de se dire qu’on pourrait utiliser les résultats de requêtes déjà posées pour pouvoir répondre à des requêtes similaires. [CLIC] Par exemple soit la requête portant sur une date comprise entre 1966 et 1981. Imaginons qu’on pose une nouvelle requête portant sur une date comprise entre 1976 et 1980. On voit que si l’on avait conservé les résultats de la requête précédente dans un cache, on pourrait alors l’utiliser pour répondre à la requête sans avoir à re-interroger les sources. Dans ce cas-ci, la requête s’est faite entièrement dans le cache local et la source n’a pas eu besoin d’être interrogée. Soit une autre requête portant sur une date comprise entre 1977 et 2000. On constate dans ce cas que le cache ne suffit pas pour répondre entièrement à la requête, mais peut y répondre en partie. Dans ce cas le cache est exploitée pour répondre à la requête : date comprise entre 1977 et 1981, et la source distante sera interrogée sur les dates comprises entre 1981 et 2000. Cela permet de limiter le nombre de tuples renvoyé et donc le temps de communication total. Le cache doit ensuite être mis à jour. Enfin, il peut arriver des cas où le cache ne peut pas du tout répondre à la question, par exemple pour chercher les dates supérieures à 2002. Dans ce cas la source distante est interrogée, et le cache doit être mis à jour. Utiliser un SGBD semi-structuré natif comme cache L’idée pour pouvoir stocker les résultats de requêtes déjà posée est d’utiliser un SGBD natif XML, c’est à dire un SGBD dédié à XML. Ce SGBD natif peut être pris parmi les SGBD commerciaux comme tamino ou les prototypes de recherche comme PDOM, NatiX ou ReposiX. Dans notre architecture intégrant un cache, on choisira un SGBD natif utilisant des identifiants uniques permettant d’accéder aux éléments stockés. [PAGE] cache = R source = R – Rc date > 1977 and date < 2000 cache = Ø source = R date > 2002 Tuyêt Trâm DANG NGOC - Université de Versailles

Prise en compte des capacités d’interrogation des sources Source de capacité d’interrogation différentes Ex. SGBD-R: requête complexes, mises à jours, etc. Ex. Page web ou moteur de recherche : possibilité d’interrogation limitée (formulaire) Adaptateur peut pallier certaines déficiences de la source complexe pour les développeurs d’adaptateurs Le médiateur pallie les déficiences de l’adaptateur+source prise en compte dans la création du plan d’exécution prise en compte dans le calcul du modèle de coût et le choix du plan optimal Source de capacité d’interrogation différentes Les sources de données peuvent varier énormément au niveau de leur capacité de traitement. Ainsi, un SGBD relationnel est capable de résoudre des requêtes très complexes, faisant intervenir des jointures, des restrictions, des opérations algébriques et relationnelles. A l’inverse, un moteur de recherche a des capacités de requêtes se limitant souvent à de simple recherche de mots-clefs. Adaptateur peut pallier certaines déficiences de la source Une des solutions pour intégrer de telles sources à une architecture de médiation, est de créer faire pallier les déficiences de la source par l’adaptateur associé. Cela rend par contre complexe le développement de nouveaux adaptateurs pour chaque nouvelle source. Le médiateur pallie les déficiences de l’adaptateur+source Une autre solution est de faire pallier les déficiences des sources par le médiateur et non plus par les adaptateurs, de sorte que le développement d’un adaptateur pour une nouvelle source ne consiste plus qu’à une simple traduction du langage commun au langage natif. Dans ce cas là, il faut que l’adaptateur soit capable de communiquer ses limites de capacité de traitement au médiateur. [PAGE] Tuyêt Trâm DANG NGOC - Université de Versailles

Langage de description des capacités d’interrogation <ruleset> <rule num="10"> <permission> allow </permission> <relationalop> scan </relationalop> </rule> <rule num="100"> <relationalop> select </relationalop> <collection1> <hotel><categorie></categorie></hotel> </collection1> <operator> less </operator> <rule num="200"> <permission> deny </permission> <rule num= "300"> <relationalop> project </relationalop> <collection1> voiture </collection1> <rule num="65535"> </ruleset> Basé sur XML Règles ordonnées Permissions par défaut : autorisation ou interdiction J’ai proposé un langage de communication de capacité de traitement entièrement basé sur XML. Les capacités sont exprimés sous forme de règles (accepté/non accepté) ordonnées portant sur les opérations, les collections et les chemins. Des règles de simplification étant données pour l’évaluation de ces règles. [PAGE] num perm operat coll att comp 10 allow scan 100 select hotel categorie less 200 deny 300 project 65535 Tuyêt Trâm DANG NGOC - Université de Versailles

Tuyêt Trâm DANG NGOC - Université de Versailles Xtuples : motivations « Projection sur les enseignes des établissements gérés par chaque tenancier. » $t/nom $t/etablissement/enseigne $t/nom $t/etablissement/enseigne Opération directe sur arbres tenancier « Wild Geese » nom établissement enseigne « Joe » tenancier « Wild Geese » nom établissement enseigne « Joe » etablissement « Le Falstaff » « John » tenancier « Wild Geese » nom établissement enseigne « Joe » etablissement « Le Falstaff » « John » tenancier « Wild Geese » nom établissement enseigne « Joe » etablissement « Le Falstaff » « John » tenancier « Wild Geese » nom établissement enseigne « Joe » etablissement « Le Falstaff » « John » Pb : coût de navigation Je vais introduire ici ce qui a motivé la création des XTuple, notion principale de l’algèbre que j’ai nommé XAlgèbre. Pour cela, je vais exposer comment les différentes façon d’évaluer une requête sur XML. Soit par exemple la requête sur la projection de l’enseigne des établissement gérés par chaque tenancier. [CLIC] Une première solution est de manipuler directement les arbres. Cela nécessite des parcours d’arbre qui peuvent s’avérer très coûteux si l’arbre est profond. Une autre solution est d’aplatir l’arbre, c’est-à-dire de créer un tableau de les chemins possibles et ensuite de travailler sur le tableau comme sur du relationnel. Le résultat trouvé. Il faut ensuite reconstruire l’arbre. Le problème ici, se pose quand à la construction du tableau et la reconstruction de l’arbre La solution que nous proposons, est d’indexer les parties de l’arbre dont nous aurons besoin, suivant un format tabulaire, et de travailler sur la partie tabulaire. [PAGE] « Joe » « Wild Geese » « John » « Le Falstaff » Transformation en tableau et opération relationnelle sur table Pb: coût de construction du tableau et la reconstruction de l’arbre tenancier nom etablissement enseigne « Le Falstaff » « John » Référencement dans un tableau et opération relationnelle sur table ET évaluation en flux Conservation de l’arbre et peu de navigation Tuyêt Trâm DANG NGOC - Université de Versailles