D´efinition des transformations

Pour optimiser le mod`ele TGV, un ensemble de r`egles de transformation doit ˆetre d´efini dans l’optimiseur pour donner une repr´esentation optimale d’une requˆete. Toutefois, l’ensemble des r`egles d´efinies dans l’optimiseur peut varier au cours du temps et n´ecessiter des ajouts ou des suppressions, d´ependant des besoins du contexte ou de l’administrateur du m´ediateur. Ainsi, un optimiseur extensible correspond `a ces besoins, car en donnant un langage de d´efinition de r`egles, l’optimiseur peut int´egrer de nouvelles r`egles au syst`eme sans le modifier int´egralement. Le langage de d´efinition de r`egles permet ainsi d’int´egrer de nouvelles transformations en utilisant simplement les d´efinitions de notre mod`ele. Pour rester dans un mod`ele intuitif de repr´esentation de requˆetes `a l’aide des TGV, un mod`ele de repr´esentation de r`egles appel´e Rule Pattern sera propos´e pour permettre de visualiser la transformation cr´e´ee. $a catalog book title author $b reviews review author = books contains ("Hobb") $a catalog book title author $b reviews review author = books contains ("Hobb") contains ("Hobb") =>

Fig. 4.3 – Transformation d’un TGV

L’exemple de la figure 4.3 repr´esente sur le tgv de gauche une requˆete de jointure entre deux collections : «catalog» et «review ». Une contrainte est li´ee `a l’auteur de la revue qui doit contenir le mot «Hobb». Puis les deux noms d’auteur sont joins et enfin tous les titres contenus dans les livres sont retourn´es.

Le TGV de droite est une transformation ´equivalente du TGV de gauche apr`es application de r`egles de transformation. Deux modifications sont notables, le lien de nœuds entre book et title, et la contrainte sur le nœud author de la collection catalog. La premi`ere transformation `a modifier lien ancˆetre/descendant en un lien parent/enfant, compte tenu des informations fournies par les sources, la balise title n’existe qu’`a un seul endroit dans la collection catalog, et ainsi, le chemin a pu ˆetre compl´et´e. La seconde transformation correspond `a une copie de contrainte `a

travers l’´equi-jointure, en effet, si l’auteur de la collection review doit contenir le mot «Hobb» et ˆetre ´egal `a l’auteur de la collection catalog, alors, l’auteur de cette mˆeme collection doit contenir le mot «Hobb».

Ainsi, nous allons d´efinir le langage de d´efinition de r`egles de transformation pour nous permettre d’optimiser les TGV, et d´efinir une repr´esentation de ces r`egles de transformation.

4.3.1.1 Langage de r`egles

Un optimiseur est dit «extensible» si l’on peut l’enrichir `a l’aide de d´efinitions de nouvelles r`egles de transformation sans avoir `a modifier le syst`eme. Pour cela, il nous faut d´efinir un langage de d´efinition de r`egles. Celui-ci doit pouvoir d´ecrire la manipulation des TGV et l’utilisation des op´erations de transformation.

Ainsi, le langage de d´efinition de r`egles doit pouvoir modifier un TGV logique ou physique (avec annotations) pour d´eterminer la s´electivit´e de la transformation et la transformation `a effectuer. Ainsi, le langage de d´efinition de r`egles est d´ecompos´e en deux parties : la condition de la r`egle (ou Rule Condition) et le r´esultat de la r`egle (ou Rule Conclusion).

Puisque l’optimiseur travaille sur le mod`ele TGV, le langage de r`egle doit d´efinir des op´erations sur celui-ci. Les types abstraits de donn´ees (ADT) d´efinissant les TGV permettent `a la fois de d´efinir les ´el´ements `a s´electionner, les conditions d’application de la r`egle, et les op´erations de transformation. Il est donc naturel d’utiliser les types abstraits pour d´efinir le langage de r`egles. De plus, l’expressivit´e du langage en sera d’autant plus grande que toute modification sur les TGV sera possible (d´efinition pr´ecise de chaque ´el´ement). Alors, nous pouvons d´efinir le langage de d´efinition de r`egles par les trois clauses ci-dessous :

[Identifiant] : FOR [Variables] IF [Conditions] THEN [Modifications]

Tab. 4.4 – Langage de d´efinition de r`egles de transformation

Dans le tableau 4.4, nous pouvons voir la d´efinition de notre langage en un identifiant de r`egle et trois clauses principales : FOR, IF, THEN. Chacune permet de d´efinir une propri´et´e de la r`egle :

– FOR : Variables d’entr´ee de la r`egle en fonction de son type d´efinissant l’espace de recherche des ´el´ements concern´es. Ces types peuvent ˆetre : Node, NodeLink, TreePattern, Hyperlink, Constraint, Annotation ;

4.4.3 R`egles de transformation 121

clause FOR. Les op´erations des types abstraits sont utilis´ees pour d´efinir les condi-tions (grˆace aux axiomes et aux pr´e-condicondi-tions), et des variables temporaires sont utilis´ees pour faciliter la manipulation, chacune d’elle est d´eclar´ee de la sorte : $var := ... ;

– THEN (Rule Conclusion) : Transformations `a appliquer dans le cas o`u les condi-tions de la clause IF sont v´erifi´ees. Les variables temporaires peuvent ˆetre r´eutili-s´ees pour modifier leurs valeurs associ´ees. Les op´erations de transformations sont celles d´efinies dans les types abstraits (cr´eation, destruction, mise `a jour, cf. An-nexe D).

La r`egle de transformation R1 du tableau 4.5 illustre le langage de d´efinition de r`egles de transformation. Cette r`egle correspond `a l’exemple donn´e dans la figure 4.3 dans laquelle la jointure a permis de copier la contrainte d’un nœud vers celui qui lui ´etait li´e par une ´equi-jointure.

R1 : 1 : FOR $H1ǫHJ, $iǫInteger 2 : IF 3 : $n1:= getLef tJH($H1) 4 : getConstraintN ame(getConstraint($H1)) ==′ =′ 5 : $c := getConstraint($n1, $i) 6 : $n2:= getRightJH($H1) 7 : THEN 8 : createConstraint($n2, $c)

Tab. 4.5 – R`egle de transformation de distributivit´e de la jointure

La condition de la r`egle (ou Rule Condition) parcourt l’ensemble des hyperliens de jointure auquel est associ´e un entier (ligne 1). Pour cet ensemble d’hyperliens, chacun d’eux est associ´e `a une variable $H₁, et les entiers `a la variable $i. Les lignes 2 `a 6 d´efinissent la s´electivit´e de la r`egle `a l’aide des op´erations des types abstraits des TGV. A la ligne 3, la variable $n1 d´efinit le nœud gauche de l’hyperlien de jointure, alors que le nœud de droite est associ´e `a la variable $n<sub>2</sub>`a la ligne 6. Ensuite, la contrainte de jointure (getConstraint) doit ˆetre un op´erateur d’´egalit´e (ligne 4). Enfin, le nœud $n1 (celui de gauche) doit ˆetre associ´e `a une contrainte pour l’entier $i (ligne 5) et associ´ee `a la variable $c. Si ces conditions sont v´erifi´ees, c’est `a dire si la jointure contient l’op´erateur ’=’ et s’il existe une contrainte $c associ´ee `a $n₁ `

a la position $i, alors, la conclusion de la r`egle peut ˆetre appliqu´ee. Celle-ci doit pouvoir copier la contrainte du nœud de gauche au nœud de droite. Ainsi, `a la ligne 8, l’op´eration createConstraint associe la variable $c d´efinie `a la ligne 5 au nœud $n<sub>2</sub> d´efini `a la ligne 6.

Ainsi, `a l’aide de l’expressivit´e des types abstraits de donn´ees d´efinis pour les TGV et de leurs annotations, le langage de r`egle est capable d’exprimer un large ensemble de r`egles de transformation sur les TGV et ainsi de les optimiser. Par la suite, nous allons ´etudier une repr´esentation de ces r`egles en utilisant celle d´efinie pour les TGV pour repr´esenter un motif `a appliquer sur ceux-ci.

4.3.1.2 Motifs de R`egles

Maintenant que nous avons un langage de r`egle permettant de d´efinir des trans-formations sur les TGV, nous proposons un mod`ele de repr´esentation de r`egles de transformation : les motifs de r`egles (ou Rule Patterns). Comme le mod`ele TGV repr´esente un mapping entre des documents XML et un ensemble de motifs d’arbre, les motifs de r`egles seront repr´esent´es comme un motif applicable sur un TGV. Ainsi, nous avons une repr´esentation intuitive des r`egles de transformation.

Comme la repr´esentation des T GV provient de sa formalisation `a base de types abstraits de donn´ees, nous pouvons utiliser naturellement cette repr´esentation pour les motifs de r`egles, mais sp´ecialis´ee `a certaines parties du TGV. Les diff´erences entre le mod`ele TGV et le mod`ele Rule Patterns viennent des variables d´efinies dans la condition de la r`egle, et les ´el´ements s´electionn´es par la clause FOR. Pour repr´esenter ces motifs de r`egles, chaque ´el´ement d´eclar´e dans les clauses FOR et IF sera repr´esent´e. Nous leur associerons les variables d´eclar´ees dans la clause IF. Les op´erations de comparaisons de type ’==’ seront repr´esent´es par leurs valeurs de comparaison pour montrer ce que le motif requi`erent pour ˆetre s´electionn´e.

R : Motif de r`egle condition => Motif de r`egle conclusion Tab.4.6 – Repr´esentation d’une r`egle de transformation

Deux motifs sont n´ecessaires pour repr´esenter une r`egle de transformation. En effet, le premier motif appel´e «motif de r`egle condition» (ou Condition Rule Pattern) doit repr´esenter les conditions d’application de la r`egle des clauses FOR et IF. Le second motif «motif de r`egle conclusion» (ou Conclusion Rule Pattern) repr´esente l’´etat final apr`es application de la r`egle en utilisant les variables d´efinies dans le motif pr´ec´edent. Les diff´erences entre les deux motifs de r`egles correspondent aux modi-fications appliqu´ees dans la clause THEN. Le tableau 4.6 donne la repr´esentation d’une r`egle de transformation avec le nom de la r`egle tout `a gauche, le motif de r`egle condition `a gauche et le motif de r`egle conclusion `a droite.

$n

=>

$n

$n

$n

R1:

Fig.4.4 – Motifs de R`egles de distributivit´e de la jointure

Afin d’illustrer les motifs de r`egles, la r`egle d´efinie dans le tableau 4.5 est repr´esen-t´ee dans la figure 4.4. Le motif de gauche repr´esente le motif de r`egle condition ou Condition Rule Pattern, avec un hyperlien de jointure annot´e par la variable $H<sub>1</sub>, la contrainte de jointure est associ´ee `a la jointure par le symbole ’=’ puisqu’il corres-pond `a la valeur qu’il doit avoir dans le motif de r`egle. La variable $n1 correspond au noeud gauche de l’hyperlien et remplace le nom du nœud qui n’est pas sp´ecifi´e. La

4.4.3 R`egles de transformation 123

contrainte $c est associ´ee `a la variable $n<sub>1</sub> sous celle-ci, comme pour une contrainte li´ee `a un nœud. Enfin, la variable $n₂ correspond au noeud droit de l’hyperlien. Le motif de r`egle de droite repr´esente le motif de r`egle conclusion ou Conclusion Rule Pattern. Il est obtenu apr`es transformations sur le motif de r`egle condition. Ici, la contrainte $c reli´ee au nœud $n₁est dupliqu´ee (mˆeme nom de variable) et associ´ee au nœud $n2 de l’autre cˆot´e de l’hyperlien. Cette r`egle de transformation permet de r´eduire le nombre de r´esultats produits dans l’ensemble de droite grˆace `a la nouvelle contrainte associ´ee (de plus amples d´etails sont donn´es dans la section suivante). Ainsi, nous obtenons grˆace aux deux motifs de r`egles un motif global permettant de d´efinir visuellement une r`egle de transformation que nous pouvons appliquer sur un TGV.

4.3.1.3 Conclusion

Nous avons d´efini un langage de d´efinition de r`egles de transformation applicable sur les TGVs, auquel nous avons associ´e de la mˆeme mani`ere que les TGV un mod`ele de repr´esentation : Rule Patterns. Ces repr´esentations sont des motifs que nous pouvons appliquer sur un TGV et ainsi nous permettre de les optimiser.

Le langage de r`egles de transformations est bas´e sur les types abstraits de donn´ees. Ce choix nous permet de d´efinir des r`egles de transformation tr`es pr´ecises sur les modifications effectu´ees sur les TGV. De plus, la m´ethode de repr´esentation des TGV `a partir des types abstraits facilite la repr´esentation des motifs de r`egles. Par la suite, nous avons besoin d’orienter la strat´egie de recherche d´efinie dans l’optimiseur, `a cette fin, une classification des r`egles de transformation est n´ecessaire pour d´efinir diff´erents ensembles de transformations.