Espace de Recherche

L’espace de recherche est un ensemble de TGV pouvant ˆetre g´en´er´e `a l’aide des r`egles de transformations d´efinies dans l’optimiseur. Si aucune strat´egie de recherche n’est d´efinie dans l’optimiseur, alors, l’espace de recherche g´en`ere l’ensemble de tous les TGV possible, le TGV optimal est alors celui dont le coˆut d’´evaluation, d´efini par le mod`ele de coˆut, est le moins cher. Toutefois, la g´en´eration de tous les TGV est souvent plus longue que l’´evaluation du TGV initial, il n’est donc pas utile de g´en´erer tout l’espace de recherche. C’est pour cela qu’une strat´egie de recherche doit ˆetre d´efinie pour r´eduire l’espace de recherche et ainsi obtenir un TGV optimal dit ”local” `

a l’espace g´en´er´e. Ainsi, la strat´egie de recherche oriente le choix d’utilisation des r`egles de transformation pour r´eduire l’espace de recherche pour obtenir le TGV optimal local.

L’optimiseur EXODUS [Carey et al. 1990] propose une strat´egie de recherche bas´ee sur la valuation des r`egles de transformations avec un coefficient d’am´elioration. Ce coefficient est d´efini entre 0 et 1 par un calibrage des r`egles `a l’initialisation du syst`eme, plus le coefficient est proche de z´ero, plus le gain de performance est grand, plus il est proche de 1, plus le gain est petit (coˆut identique `a l’initial). Ainsi, l’optimiseur choisit, pour une requˆete donn´ee, la r`egle de transformation dont le coefficient d’am´elioration est le plus proche de z´ero, dans l’ensemble des r`egles applicables sur cette requˆete. La strat´egie de recherche incr´ementale n’est certes pas la plus efficace puisqu’elle ne g´en`ere pas forc´ement le meilleure plan. Toutefois, nous avons choisi cette solution en premier lieu pour ´etablir un cadre d’optimisation nous permettant de tester les performances de l’optimiseur extensible. La strat´egie de recherche peut ˆetre modifi´ee pour am´eliorer les performances, ce choix sera propos´e dans le cadre d’une autre th`ese de recherche [Liu to appear].

Comme pour EXODUS, notre strat´egie de recherche sera orient´ee par l’attribution d’un coefficient d’am´elioration `a chaque r`egle de transformation. Toutefois, le choix de la valeur du coefficient ne peut ˆetre attribu´e de la mˆeme mani`ere que pour EXO-DUS. En effet, dans le cadre de la m´ediation, le coefficient d’am´elioration des r`egles de transformation peut varier en fonction du coˆut d’´evaluation des requˆetes sur les sources distantes ou entre deux sources distinctes. Seul le mod`ele de coˆut peut nous permettre de donner ces d´etails. Ainsi, le coefficient d’am´elioration sera calibr´e puis raffin´e par historique pour lui permettre de rester `a jour. Nous pouvons d´efinir le coefficient d’am´elioration grˆace au mod`ele de coˆut grˆace `a la formule suivante :

coef f = ^{cost(ϕ(tgv))}_cost(tgv)

4.4.4 Strat´egie de recherche 135

du TGV modifi´e sur le coˆut d’´evaluation th´eorique du TGV initial.

Toutefois, le mod`ele de coˆut seul ne suffit pas pour d´efinir le coefficient d’am´eliora-tion d’une r`egle de transformad’am´eliora-tion. En effet, les cat´egorisad’am´eliora-tions des r`egles d´efinies pr´ec´edemment influent sur le coˆut d’´evaluation du TGV. Chaque cat´egorie apporte une information particuli`ere d´ependant de ses propres caract´eristiques. Concernant les r`egles de transformations logiques, celles-ci ne tiennent pas compte des infor-mations pr´esentes sur les sources distantes. Alors que les r`egles de transforinfor-mations physiques tiennent compte des informations provenant des sources.

Ainsi, cette diff´erence, entre les transformations logiques et physiques, influe sur le coefficient d’am´elioration puisque les transformations logiques pr´eparent le TGV `a l’´evaluation physique. Ainsi, le coefficient des transformations logiques doit ˆetre plus int´eressant que les transformations physiques, celui-ci sera donc affect´e d’un facteur d’influence de ×0.5 pour repr´esenter cette importance. Concernant les transforma-tions utilisateurs, celles-ci peuvent aussi bien influencer les transformatransforma-tions logiques et physiques, changer le coˆut d’´evaluation (exemple de la fonction contains), il n’est donc pas possible de d´eterminer de mani`ere automatique son influence sur l’opti-misation. Ainsi, son facteur d’influence sera d´etermin´e par l’utilisateur qui pourra d´eterminer l’importance de la transformation.

Ainsi, grˆace `a un coefficient d’am´elioration d´efini pour chaque r`egle de transforma-tion de l’optimiseur, nous pouvons orienter la strat´egie de recherche. Ce coefficient d´efini par le rapport du coˆut d’´evaluation th´eorique apr`es transformation sur le coˆut apr`es transformation est raffin´e par un historique du coˆut d’´evaluation fait sur les sources. De plus, un facteur d’influence est affect´e `a chaque r`egle de transforma-tion d´efinie en fonctransforma-tion de sa cat´egorisatransforma-tion permettant de donner une plus grande importance aux transformations logiques et transformations utilisateurs sp´ecifiques.

4.4.3 Conclusion

La strat´egie de recherche d´efinie dans l’optimiseur s’appuie sur un mod`ele de coˆut d´efini par calibrage des sources avec raffinage sur historique. Cette strat´egie incr´e-mentale d´efinie un cadre d’optimisation pour effectuer des tests de performances (section 5.5). Ue strat´egie plus efficace sera d´efinie dans la th`ese de [Liu to appear], plus adapt´ee au mod`ele de coˆut permettant d’annoter des estimations sur les TGV. L’annotation des TGV permet de donner une estimation du coˆut d’´evaluation sur des ensembles d’´el´ements pr´esents dans le TGV. Le parcours de l’espace de recherche des plans est orient´e grˆace `a l’attribution d’un coefficient d’am´elioration des r`egles de transformations. Ce coefficient est orient´e lui-mˆeme par calibrage de celles-ci grˆace au mod`ele de coˆut avec raffinage par historique. Ces coefficients sont influenc´es par un facteur d´etermin´e grˆace `a la cat´egorisation des r`egles de transformation.

4.5 Conclusion

L’optimiseur bas´e sur le mod`ele TGV propose un ensemble d’outils permettant de manipuler les TGV : une alg`ebre abstraite, une base d’annotation, un langage de d´efinition de r`egles de transformation, une cat´egorisation des transformations, un mod`ele de coˆut g´en´erique et une strat´egie de recherche.

Une alg`ebre abstraite est propos´ee pour d´efinir une ´evaluation des TGV de mani`ere intuitive ind´ependante d’une alg`ebre physique. Celle-ci repose sur une d´ecomposi-tion des ensembles caract´eristiques des TGV pour donner un ensemble d’op´erateurs fonctionnels capables d’´evaluer des documents XML grˆace `a notre mod`ele de repr´e-sentation.

Une base d’annotation g´en´erique est associ´ee au mod`ele pour repr´esenter n’importe quelle information que nous souhaitons int´egrer `a la repr´esentation. Ces annotations regroupent des ensembles d’´el´ements de TGV pour leur associer une annotation quel-conque. Ainsi, il est possible de d´efinir des annotations de m´eta-donn´ees, capacit´es fonctionnelles, coˆut d’´evaluation, choix d’algorithmes flexibles [Calm`es et al. 2003]... Un TGV qui a ´et´e annot´e est appel´e TGV physique. Ce TGV annot´e peut alors ˆetre optimis´e.

L’optimiseur modifie un TGV `a l’aide de r`egles de transformation. Ces r`egles de transformation peuvent ˆetre int´egr´ees dans le syst`eme grˆace `a un langage de d´efi-nition de r`egles de transformation. Ce langage repose sur les op´erations des types abstraits de donn´ees d´efinies par le mod`ele, permettant ainsi de sp´ecifier librement toute r`egle possible. Grˆace `a ce langage de r`egle, l’optimiseur est extensible, car l’ensemble des r`egles de transformation peut ˆetre modifi´e.

Chaque r`egle de transformation d´eclar´ee dans l’optimiseur est class´ee dans une ca-t´egorie. Trois classes sont d´efinies. Les transformations logiques ´equivalentes trans-forment un TGV `a l’aide des simples connaissances des TGV sans modifier le r´esultat de l’´evaluation. Les transformations physiques ´equivalentes transforment un TGV `

a l’aide des informations pr´esentent dans le TGV et dans les annotations tout en pr´eservant le r´esultat de l’´evaluation. Les transformations utilisateurs sont d´efinies en fonction du contexte dans lequel s’int`egre l’optimiseur. Il est parfois utile de ne pas pr´eserver l’´equivalence pour r´epondre de mani`ere plus «correcte» `a une re-quˆete. L’exemple de r`egles de transformations s´emantiques permet de r´epondre `a une requˆete en fonction du th`eme choisi, et non du sch´ema exacte des donn´ees (qui peut ˆetre bien diff´erent). Cette cat´egorisation des r`egles de transformation permet d’orienter la strat´egie de recherche de l’optimiseur.

Pour permettre `a l’optimiseur d’am´eliorer les TGV `a l’aide des r`egles de transfor-mation sans g´en´erer l’ensemble des TGV possibles, une strat´egie de recherche a ´et´e d´efinie ; elle permet donc de r´eduire l’espace de recherche. Pour cela, un mod`ele de coˆut est n´ecessaire pour d´eterminer le coˆut d’´evaluation de chaque TGV, celui-ci est d´efini par calibrage des sources et raffin´e par historique. Chaque ensemble

d’´el´e-4.4.5 Conclusion 137

ments d’un TGV est annot´e par son coˆut d’´evaluation, le coˆut d’´evaluation du TGV est alors d´efini par un syst`eme de formules. La strat´egie de recherche s’appuie sur ce mod`ele de coˆut pour d´efinir un coefficient d’am´elioration pour chaque r`egle de transformation. Ce coefficient d´efini entre 0 et 1, est fix´e par calibrage des r`egles et par raffinage par historique. De plus, le coefficient d’am´elioration est orient´e par un facteur d’influence r´egl´e par la cat´egorisation de la r`egle de transformation. Au final, l’optimiseur choisi la r`egle applicable ayant le meilleur coefficient d’am´elioration. Ainsi, nous avons propos´e un optimiseur extensible bas´e sur le mod`ele des TGV capable de d´efinir son ´evaluation, son coˆut et ses transformations. L’optimiseur d´e-termine ainsi un TGV quasi-optimal qui peut ˆetre ´evalu´e par le m´ediateur.

Une partie des techniques d´ecrites dans ce chapitre a ´et´e mise en œuvre dans le cadre du m´ediateur XLive. La d´ecomposition des TGV ainsi que les annotations permettent de g´en´erer les plans logiques et physiques dans le m´ediateur. Un mod`ele de coˆut g´en´erique a ´et´e int´egr´e dans les annotations pour permettre `a l’optimiseur de donner un coˆut th´eorique `a chaque plan. Pour le moment, les r`egles de transformation sont impl´ement´ees dans l’optimiseur ; le parseur sp´ecifique au langage de r`egle de transformation est en cours d’impl´ementation.

Chapitre 5

XLive : un syst`eme de

m´ediation

Le syst`eme de m´ediation pr´esent´e dans cette th`ese r´esulte de l’´evolution du syst`eme de m´ediation XMLMediator de e-XMLMedia [Gardarin et al. 2002] et de l’int´egration des diff´erentes techniques que nous avons pu aborder dans cette th`ese. XMLMediator a ´et´e d´evelopp´e au sein de la soci´et´e e-XMLMedia, les bases de cette architecture ont ´et´e utilis´ees pour d´evelopper le syst`eme de m´ediation XLive au laboratoire PRiSM. L’objectif du projet XLive est de pouvoir f´ed´erer des sources de donn´ees h´et´ero-g`enes et distribu´ees, tout en utilisant les technologies ”XML”. Ainsi, XLive est une architecture de m´ediation ”tout-XML” permettant `a un utilisateur d’interroger le m´ediateur dans le langage XQuery et de r´ecup´erer un r´esultat sous forme d’un do-cument XML. Les requˆetes sont repr´esent´ees en interne par les TGV. L’´evaluation des donn´ees XML est facilit´ee par l’utilisation d’une XAlgebre (appel´ee aussi XAl-gebra). Des adaptateurs permettent la communication avec toutes sortes de sources de donn´ees : natives XML (Xyleme, eXist, Xhive), relationnelles (Oracle, MySQL, Microsoft Access), fichiers XML, Web Services (Google API, Amazon).

Dans ce chapitre, nous pr´esentons le fonctionnement du syst`eme XLive avec son architecture, les adaptateurs et la XAlgebre (section 5.1). Nous proposons ensuite une ´etude qualitative des TGV grˆace aux cas d’usage du W3C (section 5.2). Le m´ediateur XLive est alors test´e sur le cas d’usage XMP dont les performances sont d´evelopp´ees dans la section 5.3. Puis, une description de l’optimiseur extensible est propos´ee dans la section 5.4. Enfin, une ´etude quantitative `a l’aide de bancs d’essai [Dragan et Gardarin 2005] valident nos travaux (section 5.5).

5.1 Architecture de M´ediation

XLive est un syst`eme de m´ediation ”tout-XML” impl´ement´e en Java permettant de f´ed´erer des sources de donn´ees h´et´erog`enes et distribu´ees. L’architecture de m´edia-tion DARPA I3 a ´et´e retenue. Elle permet dans notre contexte de traiter les requˆetes XQuery pour produire un r´esultat pouvant int´egrer des donn´ees extraites par l’en-semble des sources reli´ees au m´ediateur. La XAlg`ebre permet de traiter les donn´ees sous forme de flux XML provenant des diff´erentes sources int´egr´ees pour construire un r´esultat final. Les adaptateurs dialoguent avec les sources et permettent au m´e-diateur de connaˆıtre les informations n´ecessaires pour l’´evaluation et l’optimisation des requˆetes.

Nous allons tout d’abord ´etudier l’architecture de XLive (section 5.1.1), puis nous d´etaillons les op´erateurs de la XAlg`ebre (section 5.1.2).