9.3 Conclusions et perspectives
Dans ce chapitre, nous avons pr´esent´e l’algorithme g´en´eral que nous avons d´efini pour g´en´erer automatiquement des transactions de BD relationnelles `a partir de d´efinitions d’attributs eb3. Ces transactions ont ´et´e pr´evues pour ˆetre utilis´ees dans le cadre du projet apis. Ainsi, elles sont appel´ees par l’outil eb3
pai (voir section9.1) pour faire des requˆetes ou pour mettre `a jour la BD, lorsque les ´ev´enements correspondants sont consid´er´es comme valides par interpr´etation des expressions de processus eb3.
Les ´enonc´es SQL g´en´er´es pour les UPDATE et les INSERT peuvent par-fois ˆetre simplifi´es en analysant les d´efinitions de cl´e. Soit k une valeur de cl´e appartenant `a KChange(T , a). Pour chaque attribut non cl´e b de la table T dans Att (a), si k appartient `a KIU(b), alors on recherche dans la d´efinition d’at-tribut de la cl´e de T s’il existe une clause d’entr´ee pour l’action a contenant le symbole “∪”. S’il n’en existe pas, alors l’´enonc´e DUI pour k ne peut ˆetre qu’une mise `a jour de type UPDATE, car une insertion requiert aussi une union dans la d´efinition de cl´e pour repr´esenter l’ajout de la cl´e correspondante. Dans les autres cas, il est impossible de distinguer les insertions des mises `a jour, sans une analyse compl´ementaire des expressions de processus eb3. Parmi nos perspectives de travail, nous comptons apporter quelques am´eliorations `a notre algorithme lors de son int´egration avec les autres outils de l’environnement apis. En particulier, l’interpr´eteur eb3
pai des expressions de processus eb3peut ˆetre utilis´e pour distinguer les actions de type producteur et modificateur.
Chapitre 10
Patrons SELECT
“Un g´enie ´ecrit des programmes que mˆeme un idiot peut comprendre, alors qu’un idiot ´ecrit des programmes que mˆeme le compilateur ne peut pas comprendre.”
— David Harel
Dans le chapitre 9, nous avons montr´e comment g´en´erer des transactions de BD relationnelles qui correspondent aux d´efinitions d’attributs eb3. Lors de la synth`ese des transactions, l’algorithme pr´evoit notamment d’analyser les pr´edicats des termes conditionnels des d´efinitions d’attributs pour d´eterminer les tuples `a ins´erer, `a mettre `a jour ou `a supprimer. Dans ce chapitre, nous mon-trons comment g´en´erer les ´enonc´es SELECT qui correspondent `a ces pr´edicats et qui permettent de retrouver les tuples en question. Dans ce but, nous avons d´efini une biblioth`eque de patrons d’´enonc´es SELECT pour les formes les plus typiques des pr´edicats rencontr´es dans les d´efinitions d’attributs. La section10.1
commence par pr´esenter quelques notations utilis´ees pour les besoins de ce cha-pitre. Dans la section10.2, nous pr´esentons les patrons de base qui sont utilis´es par nos algorithmes. Puis, la section10.3pr´esente des patrons plus complexes qui permettent de r´eutiliser les patrons de base. La section10.4indique comment g´en´erer l’´enonc´e SQL qui correspond `a une conjonction de pr´edicats. Enfin, la section10.5conclut ce chapitre par une discussion sur les techniques de synth`ese par patrons pr´esent´ees dans cette th`ese.
10.1 Introduction
Dans ce chapitre, on consid`ere les clauses d’entr´ee d’une d´efinition d’attribut b qui a la forme suivante :
b(s : T (main),−→ k :−→
T ) : T0 =∆ . . .
a(−→p ) : if Pred then FctTerm else Expression end . . .
o`u−→
k est la liste des param`etres qui repr´esentent les attributs cl´e de la table de b, −→p est la liste des param`etres de l’action a, Pred est un pr´edicat, FctTerm est
un terme fonctionnel et Expression peut ˆetre soit un terme fonctionnel, soit une autre expression if then else end de cette forme. Dans le probl`eme qui suit, les valeurs de −→p sont connues, puisque le filtrage permet de relier ces param`etres aux valeurs indiqu´ees dans l’´ev´enement `a ex´ecuter, tandis que les variables de−→ k sont les inconnues `a d´eterminer grˆace `a un ´enonc´e SELECT d´eduit du pr´edicat Pred . Dans la suite, chaque attribut est pr´efix´e par sa table pour ´eviter des confusions de noms. La forme g´en´erale de l’expression Pred est une conjonction de pr´edicats, P1 ∧ P2 ∧ ... ∧ Pn, o`u chaque Pi est une instance I de l’un des patrons de pr´edicats, ou de sa n´egation, not´ee alors par ¬I .
Le langage de d´efinition d’attribut pr´econise qu’au moins un des pr´edicats Pi de la conjonction soit un pr´edicat positif, o`u les valeurs de−→
k sont born´ees par des valeurs de la BD. Par exemple, la d´efinition d’attribut suivante n’est pas autoris´ee, parce qu’elle repr´esente une mise `a jour de tous les membres dont l’attribut cl´e memberKey a une valeur sup´erieure `a 10, qu’ils appartiennent ou non `a la BD :
nbLoans(s : T (main), mId : memberKey Set ) : N=∆ ..
.
a(−→p ) : if mId > 10 then . . . end ..
.
La d´efinition suivante, qui restreint mId aux tuples existant dans la BD, est plus appropri´ee :
a(−→p ) : if mId > 10 ∧ mId ∈ memberKey(front (s)) then . . . end
Pour les besoins de description de nos patrons, l’expression attname(vi, g) est d´efinie comme le nom de l’attribut dans la table de g qui correspond `a la variable vi dans la clause d’entr´ee, table(g) repr´esente la table dans laquelle l’attribut g est stock´e et l’expression T .key(j ) d´esigne le j -`eme attribut cl´e de la table T .