Transformations physiques ´equivalentes

Les transformations physiques ´equivalentes sont des transformations qui pr´eservent l’´equivalence tout en utilisant comme base de connaissance celles des TGV et celles des annotations ext´erieures (section 4.2). Ainsi, les informations physiques

prove-nant des sources comme les m´eta-donn´ees, les informations de coˆut, les capacit´es fonctionnelles, les choix d’algorithme, le contexte de m´ediation, etc... peuvent ˆetre utilis´es par les transformations physiques ´equivalentes pour am´eliorer les TGV Phy-siques. Afin d’illustrer ce concept, nous proposons deux exemples de transformations physiques ´equivalentes : la permutation de la jointure et la modification d’algorithme de jointure.

Permutation de la jointure Lorsqu’une requˆete contient une jointure entre deux ensembles d’arbres, il peut ˆetre int´eressant de d´efinir un ordre pour effectuer la join-ture. En effet, l’ordre d’ex´ecution de la jointure influe sur les performances d’´eva-luation d´ependant de la cardinalit´e de chacun des ensembles li´es par la jointure. Dans le cas o`u les sources fournissent des informations de cardinalit´e des ´el´ements, l’optimiseur doit ˆetre capable de connaˆıtre la meilleure mani`ere d’´evaluer la jointure. La r`egle de transformation R2 du tableau 4.7 illustre la permutation de la jointure. La clause F OR prend l’ensemble des hyperliens de jointure du TGV ($JH). La clause IF v´erifie tout d’abord si l’annotation d’algorithme de la jointure est une boucle imbriqu´ee (BI ). L’annotation de jointure est r´ecup´er´ee (ligne 3, 4, 5 et 6), puis la v´erification est effectu´ee (ligne 7). Puis, la r`egle identifie les nœuds de gauche et de droite de la jointure (ligne 8 et 9). Pour ceux-ci, leurs statuts doit ˆetre obligatoire (ligne 10 et 11). De plus, la jointure doit ˆetre une ´equi-jointure pour que celle-ci ne modifie pas le r´esultat (ligne 12). Des lignes 13 `a 19 (et de 20 `a 26) sont v´erifi´es l’ensemble des annotations associ´ees aux nœuds (ligne 13 et 20), puis pour chacune d’elles, cette annotation doit ˆetre de type cardinalit´e (ligne 17 et 24). Dans ce cas, la cardinalit´e est assign´ee `a la variable $card<sub>x</sub> (ligne 18 et 25). Enfin, la r`egle doit v´erifier si la cardinalit´e a ´et´e assign´ee dans les deux cas (ligne 19 et 26), dans le cas contraire, la r`egle n’est pas appliqu´ee. La ligne 27 donne la derni`ere condition de permutation de la jointure, si la cardinalit´e de $n₂ est inf´erieure `a celle de $n<sub>1</sub>, alors la r`egle est enfin appliqu´ee. La clause T HEN fait alors permuter les deux ´el´ements de la jointure (ligne 29 et 30). $n => = $HJ 1 = $HJ $n 2 $n 2 $n 1 (CARDINALITE, $card ) (CARDINALITE, $card ) 2 1 $card 1 $card 2 < R2: (CARDINALITE, $card ) (CARDINALITE, $card ) 2 1

(ALGORIHTME, BI) (ALGORIHTME, BI)

4.4.3 R`egles de transformation 127 R2 :

1 : FOR $JH ǫ JoinHyperlink, $AS ǫ AnnotationSet 2 : IF

3 : $as1:= getListAnnotation($AS, $n1) 4 : FOR $i in 0 .. sizeAS($as1)

5 : $a := getAS($as1, $i)

6 : getAnnotation($a) instanceof ”ALGORIT HM E” 7 : (getInf ormation(getAnnotation($a)) == ”BI”)

8 : $n1:= lef tJH($JH) 9 : $n2:= rigthJH($JH)

10 : isM andatory(getN odeLink($n1)) == true 11 : isM andatory(getN odeLink($n2)) == true 12 : getConstraintN ame(getConstraint($JH)) ==′ =′ 13 : $as1:= getListAnnotation($AS, $n1) 14 : $card1:= −1 15 : FOR $i in 0 .. sizeAS($as1) 16 : $a := getAS($as1, $i)

17 : getAnnotation($a) instanceof ”CARDIN ALIT E” 18 : $card1:= getInf ormation(getAnnotation($a)) 19 : $card1! = −1

20 : $as2:= getListAnnotation($AS, $n2) 21 : $card2:= −1

22 : FOR $i in 0 .. sizeAS($as2) 23 : $a := getAS($as2, $i)

24 : getAnnotation($a)instanceof ”CARDIN ALIT E” 25 : $card2:= getInf ormation(getAnnotation($a)) 26 : $card2! = −1

27 : $card2< $card1 28 : THEN

29 : $setLef tJH($JH, $n2) 30 : $setRightJH($JH, $n1)

Tab.4.7 – R`egle de transformation physique de permutation de jointure

La figure 4.5 repr´esente le motif de r`egle correspondant `a la r`egle de transformation du tableau 4.7. Nous observons, dans le motif de r`egle condition, les variables d´ecla-r´ees dans les diff´erentes clauses d´efinissant la jointure, les noeuds, leur ascendance obligatoire et les annotations de cardinalit´e (couleurs rouge et bleu) et d’algorithme de boucle imbriqu´e (violet). Nous pouvons voir que dans le cas o`u la cardinalit´e de $n<sub>2</sub> est inf´erieure `a $n₁, alors la jointure est permut´ee. Le motif de r`egle conclusion montre la permutation des deux nœuds de l’hyperlien de jointure.

Algorithme de la jointure Pour ´evaluer un TGV, il faut pouvoir d´efinir `a l’aide de l’alg`ebre des algorithmes. L’exemple que nous pr´esentons ici permet de modifier un algorithme de jointure. Il transforme une jointure par boucle imbriqu´e (BI ) en algorithme de jointure par hachage (HJ ). Ainsi, la r`egle de transformation manipule des annotations de type Algorithme et des annotations de type Cardinalit´e pour v´erifier dans quel cas de jointure nous aurons `a modifier l’algorithme.

La r`egle de transformation R3 du tableau 4.8 illustre la modification de l’alogirhtme de jointure. Le principe est identique `a la permuation `a ceci prˆet que l’on garde l’annotation de jointure dans la variable $aj (ligne 10). Les lignes 7 `a 10 d´efinisse une condition d’entr´ee dans la r`egle. Si la condition de la ligne 8 est v´erifi´ee, alors on applique la ligne 10, sinon on passe `a l’occurrence suivante. Pour la suite, la condition de la ligne 30 change par rapport `a la permutation. En effet, une jointure par hachage est plus int´eressante qu’une boucle imbriqu´ee si la cardinalit´e du r´esultat de la jointure R1 x R2 est plus faible que la v´erification directe R1 * R2. La cardinalit´e du r´esultat de la jointure est calcul´ee grˆace le mod`ele de coˆut `a l’aide de l’op´eration card(). Ainsi, la formule «$card(card1 × $card2) < (card1 ∗ card2)» v´erifie si la modification de l’algorithme est int´eressante. Dans ce cas, l’algorithme est modifi´e `

a la ligne 32.

R3 :

1 : FOR $JH ǫ JoinHyperlink, $AS ǫ AnnotationSet 2 : IF

3 : $as1:= getListAnnotation($AS, $n1) 4 : FOR $i in 0 .. sizeAS($as1)

5 : $a := getAS($as1, $i)

6 : getAnnotation($aj) instanceof ”ALGORIT HM E”

7 : IF

8 : getInf ormation(getAnnotation($a) == ”BI”)

9 : THEN

10 : $aj := $a

11 : $n1:= lef tJH($JH) 12 : $n2:= rigthJH($JH)

13 : isM andatory(getN odeLink($n1)) == true 14 : isM andatory(getN odeLink($n2)) == true 15 : getConstraintN ame(getConstraint($JH)) ==′ =′ 16 : $as1:= getListAnnotation($AS, $n1) 17 : $card1:= −1 18 : FOR $i in 0 .. sizeAS($as1) 19 : $a := getAS($as1, $i)

20 : getAnnotation($a) instanceof ”CARDIN ALIT E” 21 : $card1:= getInf ormation(getAnnotation($a)) 22 : $card1! = −1

23 : $as2:= getListAnnotation($AS, $n2) 24 : $card2:= −1

25 : FOR $i in 0 .. sizeAS($as2) 26 : $a := getAS($as2, $i)

27 : getAnnotation($a)instanceof ”CARDIN ALIT E” 28 : $card2:= getInf ormation(getAnnotation($a)) 29 : $card2! = −1

30 : $card(card1× $card2) < (card1∗ card2) 31 : THEN

32 : $modif yAnnotationInf ormation($aj, ”HJ”)

4.4.3 R`egles de transformation 129 $n => = $HJ 1 = $HJ $n 2 (COST, $card ) (COST, $card ) 2 1 $card 1 $card 2 x R3:

(ALGORIHTME, BI) (ALGORIHTME, HJ)

(COST, $card ) (COST, $card ) 2 1 $n 1 $n 2 card( ) $card 1 $card 2 * <

Fig. 4.6 – Motif de r`egle physique de modification d’algorithme de jointure

La figure 4.6 repr´esente le motif de r`egle correspondant `a la r`egle de transforma-tion du tableau 4.8. Nous observons, dans le motif de r`egle conditransforma-tion, les variables d´eclar´ees dans les diff´erentes clauses d´efinissant la jointure, les noeuds, leur ascen-dance obligatoire et les annotations de cardinalit´e et d’algorihtme de jointure. La v´erification des annotations est repr´esent´ee en dessous `a l’aide de la formule corres-pondante. Le motif de r`egle conclusion montre la modification de l’algorithme de jointure (couleur diff´erente et information diff´erente).