1 REPARATION AUTOMATIQUE DANS UN ENVIRONNEMENT COLLABORATIF Rapport de stage de DEA efféctué par : Doratti RAZAFIMAHATRATRA au sein de l équipe ECOO du LORIA soutenu le 23 juin 2004 Encadrants : Hala Skaf-Molli Pascal Molli Jury : N. Carbonell D. Mery D. Galmiche
Remerciements Je tiens à exprimer en ces quelques lignes le témoignage de ma réconnaissance envers plusieurs personnes : Monsieur Dominique Mery, Responsable du DEA, pour m avoir donné la chance de suivre la formation, Monsieur Jean Claude GODART, Professeur à l Université Henri Poincaré, de m avoir accueilli au sein de l Equipe ECOO, Monsieur Pascal et Madame Hala-Skaf Molli, Maîtres de Conférence à l Université Henri Poincaré, pour l opportunité qu ils m ont offert et d avoir su me montrer le chemin dans le labyrinthe de la recherche, Gerald, toute l équipe ECOO et les membres enseignants du DEA pour leur compréhension, Ma Famille pour leur amour, leur confiance et leur sacrifice. Daddy et Toky : manantena anareo i zoky... Au membres du Ceah et tous mes amis qui m ont soutenus tout au long de ma formation. Mes collègues et toutes les personnes qui ont contribués de près ou de loin à la rédaction de ce rapport. 2
Table des matières 1 INTRODUCTION 5 2 PROBLEMATIQUE 6 2.1 Transformées opérationnelles.................................. 8 2.2 Cohérence sémantique et transformées opérationnelles.................... 10 3 ETAT DE L ART 11 3.1 La réparation dans les Bases de données............................ 11 3.1.1 Approche de Moerkotte & Lockemann......................... 11 3.1.2 Approche de Ceri et al.................................. 13 3.1.3 Approche de Teniente et Antoni Olivé......................... 15 3.1.4 Approche de Barcelo et Bertossi............................ 16 3.1.5 Approche de M. Gertz et U. W. Lipeck........................ 18 3.2 Cohérence des données et réplication optimiste........................ 20 3.2.1 Bayou........................................... 20 3.2.2 IceCube.......................................... 22 3.3 XLinkIt.............................................. 24 4 PROPOSITION 27 4.1 La réparation........................................... 27 4.1.1 Algorithme de réparation automatique......................... 27 4.1.2 Résolution d exemples.................................. 28 4.1.3 Interaction avec le processus de réparation....................... 32 4.1.4 Changement minimal.................................. 34 4.1.5 Priorités.......................................... 34 4.2 Synthèse.............................................. 34 5 IMPLEMENTATION 35 5.1 Le projet SO6........................................... 35 5.2 Validation de la proposition................................... 36 5.2.1 Expression des contraintes sémantiques........................ 36 5.2.2 Démarche de réparation................................. 36 5.2.3 Génération des actions de réparation.......................... 37 6 CONCLUSIONS 39 7 ANNEXES 40 7.1 Annexe 1 : Events method.................................... 40 7.2 Annexe 2 : XLinkIt........................................ 41 7.2.1 Exemple de DocumentSet................................ 41 7.2.2 Exemple de RuleSet................................... 41 7.2.3 Exemple de ConsistencyRule.............................. 41 7.2.4 Exemple de ConsistencyLink.............................. 41 7.3 Annexe 3 : Algorithmes du Framework............................. 42 7.3.1 Hypothetical extension.................................. 42 7.3.2 procedure add_repair_transaction(l, i, pre) ;..................... 42 7.3.3 function hitting_set(h c,, i, n ) : m ;......................... 42 3
TABLE DES MATIÈRES 4 7.4 Annexe 4 : Syntaxe des contraintes............................... 43 7.4.1 exists........................................... 43 7.4.2 implies........................................... 43 7.4.3 and............................................ 43 7.4.4 or............................................. 43 7.4.5 not............................................. 43 7.4.6 equal............................................ 43 7.5 Extension des actions de réparation automatique....................... 44 7.5.1 Syntaxe de AND..................................... 44 7.5.2 Syntaxe de OR...................................... 44
Chapitre 1 INTRODUCTION La mobilité est caractérisée par des phases de connexion et de déconnexion fréquentes. Une façon de supporter le travail mobile consiste à répliquer les données sur le support mobile avant la déconnexion et à réconcilier les données répliquées à la reconnection. Cette façon de travailler suppose l existence de synchroniseurs fiables et efficaces. Le travail coopératif présente les mêmes caractéristiques. Plusieurs utilisateurs voulant travailler sur les mêmes données en même temps peuvent répliquer ces données, travailler en parallèle chacun sur sa copie et ensuite réconcilier ces différentes copies. La aussi, cela suppose l existence de synchroniseurs performants. Synchroniser des données ayant divergées est un problème complexe. Il est impossible de garantir que la fusion de deux programmes corrects donne un programme correct, que les contributions de deux personnes à un article donnent un article cohérent etc... Simplement un synchroniseur performant doit se rapprocher le plus possible de ce synchroniseur idéal. Si l on examine de près les synchroniseurs existants, on s aperçoit assez vite que les réconciliations proposées sont souvent grossières et nécessitent une intervention lourde des utilisateurs. Les résultats de synchronisation peuvent être parfois catastrophiques et se terminer par des pertes de données ou des données corrompues. L équipe ECOO a développé un algorithme de synchronisation basé sur les transformées opérationnelles performant [11, 19, 20]. Cependant cet algorithme peut générer des résultats incohérents d un point de vue sémantique. Dans ce DEA nous montrons comment nous pouvons utiliser les algorithmes de réparations automatiques développés dans le domaine des bases de données pour fournir une synchronisation performante et correcte d un point de vue sémantique. 5
Chapitre 2 PROBLEMATIQUE Dans ce chapitre, nous allons détailler le problème auquel nous s intéressons. Pour cela, nous commencerons par un exemple de situation pratique de travail collaboratif. Supposons trois personnes qui collaborent ensemble pour éditer un document XML[28](Utilisateurs U, V et W). Chaque personne travaille sur un site et fait une copie de l objet partagé. Ce document est représenté par la Figure 2.1. <EXEMPLE> <DONNEES> <TITRE>TITRE-1</TITRE> <A>attribut-A</A> <B>attribut-B</B> <C>attribut-C</C> </DONNEES> <DONNEES> <TITRE>TITRE-2</TITRE> <A>attribut-A</A> <B>attribut-B</B> <C>attribut-C</C> </DONNEES> </EXEMPLE> Fig. 2.1 Document XML de départ Ce document respecte des contraintes (par exemple un DTD ) stipulant que : chaque <DONNEES></DONNEES> doit avoir un titre unique, s il y a un attribut <A></A>, alors il doit y avoir un attribut <B></B>, s il y a déjà un attribut <C></C>, il ne doit plus avoir d attribut <D></D>. Chaque utilisateur commence à effectuer des opérations qui sont exécutées sur sa copie local du document. L utilisateur U exécute les opérations suivantes sur sa copie 1. La figure 2.2 illustre les changements. Utilisateur U : : operation op1 = modification de <C>attribut-C</C> en <C>attribut-U</C> dans /EXEMPLE/DONNEES[2] operation op2 = modification de <TITRE>TITRE-1</TITRE> en <TITRE>TITRE-U</TITRE> dans /EXEMPLE/DONNEES[1] operation op3 = suppression de <A>attribut-A</A> dans /EXEMPLE/DONNEES[1] Le déroulement de ces opérations sur le document de l utilisateur U est montré par la Figure 2.2. Fig. 2.2 Trace des opérations de l utilisateur U 1 Nous utiliserons un pseudo-notation XPath[29]... pour désigner les données cibles. 6
CHAPITRE 2. PROBLEMATIQUE 7 Nous pouvons constater que le résultat des modifications de l utilisateur U respecte les contraintes de DTD : unicité du titre, présence des attributs A et B, exclusion entre les attributs C et D. L utilisateur V exécute les opérations suivantes sur sa copie : Utilisateur V : : operation op4 = modification de <TITRE>TITRE-1</TITRE> en <TITRE>TITRE-V</TITRE> dans /EXEMPLE/DONNEES[1] operation op5 = insertion de <D>attribut-V</D> dans /EXEMPLE/DONNEES[1] operation op6 = suppression de <C>attribut-C</C> dans /EXEMPLE/DONNEES[1] Le déroulement de ces opérations sur le document de l utilisateur V est montré par la Figure 2.3. Fig. 2.3 Trace des opérations de l utilisateur V De la même façon que pour l utilisateur U, nous pouvons constater que le résultat de V respecte les contraintes définies précédemment. A son tour, l utilisateur W exécute les opérations suivantes sur sa copie : Utilisateur W : : operation op7 = suppression de <C>attribut-C</C> dans /EXEMPLE/DONNEES[2] operation op8 = insértion de <D>attribut-W</D> dans /EXEMPLE/DONNEES[2] Le déroulement et résultat de ces opérations sur le document de l utilisateur W sont montrés par la Figure 2.4. Fig. 2.4 Trace des opérations de l utilisateur W Comme nous l avons dit précédemment, après exécution des opérations de chaque utilisateur, chaque document local obtenu vérifie les contraintes DTD. Un des objectifs d un environnement collaboratif est de permettre le travail simultané de plusieurs utilisateurs. Ensuite, on recueille le travail de chaque utilisateur afin de produire un document unique contenant le fruit du travail de chacun. Afin d arriver à un état de convergence à partir des différents documents locaux, il faut synchroniser ces documents. Dans notre cas, l utilisation d algorithme ou d outils de fusion comme SO6[20] permet d obtenir un document XML unique issu des documents locaux de chaque utilisateur. La figure 2.5 illustre le résultat de synchronisation.
CHAPITRE 2. PROBLEMATIQUE 8 <EXEMPLE> <DONNEES> <TITRE>TITRE-U</TITRE> <TITRE>TITRE-V</TITRE> <B>attribut-B</B> <D>attribut-V</D> </DONNEES> <DONNEES> <TITRE>TITRE-2</TITRE> <A>attribut-A</A> <B>attribut-B</B> <C>attribut-U</C> <D>attribut-W</D> </DONNEES> </EXEMPLE> résultat de op2 résultat de op4 résultat de op3 résultat de op6 résultat de op5 résultat de op7 résultat de op1 résultat de op8 Fig. 2.5 Exemple de trace d execution d une fusion Alors que pour chaque utilisateur, le résultat des opérations locales a produit un document local conforme au DTD, nous pouvons voir que le résultat de la fusion ne respecte plus les contraintes DTD que nous avons défini précédemment. En effet : 1 - /EXEMPLE/DONNEES[1] a plusieurs <TITRE></TITRE> 2 - /EXEMPLE/DONNEES[2] possède à la fois un attribut <C></C> et un attribut </D></D> Ceci montre qu un état obtenu après fusion ne respecte pas forcément les contraintes. En d autres termes, un état de convergence n est pas forcément un état cohérent. On peut, dans un premier temps, attribuer ce problème à l algorithme de synchronisation. En effet, si l algorithme de synchronisation n est pas capable de générer un état cohérent, alors il faut changer l algorithme de synchronisation. L algorithme de synchronisation est basé sur l approche des transformées opérationnelles. La section suivante contient une brève présentation de cette approche. 2.1 Transformées opérationnelles Le modèle des transformées opérationnelles est issu de l étude des environnements collaboratifs synchrones [19]. Le modèle considère n sites. Chaque site possède une copie des objets partagés. Quand un objet est modifié sur un site, l opération correspondante est exécutée immédiatement sur ce site, puis diffusée aux autres sites pour y être également exécutée. Autrement dit, une opération est traitée en quatre étapes : (a) génération sur un site ; (b) diffusion aux autres sites ; (c) réception par les autres sites ; (d) exécution sur ces autres sites. Fig. 2.6 Approche transformées opérationnelles Lorsqu une opération op est reçue, son contexte d exécution peut être différent de celui sur lequel elle a été générée. Dans ce cas, l intégration de op sur les autres sites peut conduire à des incohérences entre
CHAPITRE 2. PROBLEMATIQUE 9 les différentes copies. La figure 2.6(a) illustre un tel cas. Soient deux sites site1 et site2 partageant un objet de type chaine de caractere s. Un objet de ce type peut être modifié par une opération Ins(p, c) qui a pour effet d insérer le caractère c à la position p dans la chaîne (0 étant la position du premier caractère). Les utilisateurs user1 et user2 génèrent deux opérations concurrentes op1 = Ins(2, f) et op2 = Ins(5, s). Quand op1 est reçue et exécutée sur site2, elle produit l état attendu "effects". Mais, lorsque op2 est reçue sur site1, comme celle-ci ne tient pas compte de l exécution de op1 avant elle, l état obtenu est "effecst". Les deux copies sont divergentes. Dans le modèle des transformées opérationnelles, les opérations reçues doivent être transformées par rapport aux opérations locales concurrentes avant d être exécutées. Cette transformation est effectuée en utilisant des fonctions de transformation. Cette fonction notée T prend en paramètre deux opérations concurrentes op1 et op2 définies sur un même état s de l objet partagé et calcule en résultat une opération op1. Cette opération est équivalente à op1 en terme d effet, mais elle est définie sur l état s résultant de l exécution de op2 sur l état s. La figure 2.6(b) illustre l effet d une telle transformation. Ainsi, dans l exemple précédent, lorsque op2 est reçue par site1, elle doit être transformée par rapport à op1. Dans ce cas, la transformation se fait de la manière suivante : La position d insertion de op2 est alors incrémentée puisque l opération op1 a inséré le caractère f avant le point d insertion de s sur l état "efect". Ensuite, op2 est exécutée sur site1. De la même façon, lorsque op1 est reçue sur site2, la transformation suivante est effectuée : Dans ce cas, la fonction de transformation retourne l opération op1 = op1 puisque, la lettre f est insérée avant la lettre s. Intuitivement, on peut écrire cette fonction de transformation de la façon suivante : Cet exemple montre que le modèle des transformées opérationnelles met en jeu deux composants majeurs : un algorithme d intégration et un ensemble de fonctions de transformation. L algorithme d intégration est responsable de la réception, de la diffusion et de l exécution des opérations. Il est indépendant du type de données manipulées. Si nécessaire, il fait appel aux fonctions de transformations. Ces fonctions ont la charge de la fusion des modifications en transformant deux opérations concurrentes définies sur un même état. Elles sont spécifiques à un type de données particulier (chaine de caractere dans notre exemple). Il a été montré que pour être correct[19], un algorithme d intégration doit assurer deux propriétés générales : Convergence : lorsque le système est stable, c est à dire que toutes les opérations ont été diffusées et intégrées, toutes les copies doivent être identiques. Causalité : si sur un site, une opération op2 a été exécutée après op1, alors op2 doit être exécutée après op1 sur tous les sites. Plusieurs algorithmes d intégration ont été proposés tels que SOCT 2,3,4, dopt, adopted, GOTO. Il a été prouvé que leur correction repose uniquement sur les fonctions de transformation qui doivent satisfaire les deux conditions suivantes : 1. la condition C1 définie une égalité d état. L état obtenu par l exécution de op1 suivi de l exécution de T (op2, op1) doit être le même que celui obtenu par l exécution de op2 suivi par T (op1, op2 ) : C1 : op1 o T (op2, op1) = op2 o T (op1, op2)
CHAPITRE 2. PROBLEMATIQUE 10 2. la condition C2 garantit que la transformation d une opération par rapport à une séquence d opérations concurrentes ne dépend pas de l ordre dans lequel les opérations de la séquence ont été transformées : C2 : T (op3, op1 o T (op2, op1)) = T (op3, op2 o T (op1, op2)) En résumé, pour utiliser le modèle des transformées opérationnelles, nous devons suivre les étapes suivantes : 1. Choisir un algorithme d intégration. Certains algorithmes lesquels de par leur construction, ne requièrent que la satisfaction de la condition C1 par l ensemble des fonctions de transformation. 2. Définir les types des données partagées et leurs opérations associées. 3. Écrire les fonctions de transformation pour tous les couples d opérations. 4. Prouver que les conditions C1 et C2 sont vérifiées par les fonctions de transformation. 2.2 Cohérence sémantique et transformées opérationnelles Pour fusionner les données de l exemple 2.5, nous avons utilisé un jeu de transformées basé sur un objet arbre XML muni des opérations insertnode, DeleteNode, AddAttribute, ChangeAttribute et deleteattribute. Nous avons utilisé un algorithme dérivé de SOCT4 qui ne nécessite que la preuve de la condition C1. Cela nous a fait tout de même écrire 5x5 transformées opérationnelles et prouver C1 sur ces 25 fonctions à l aide du prouveur de théorème SPIKE[ 2 ]. Si nous voulons maintenant tenir compte des contraintes de l exemple s appliquant sur les données de la figure 2.1, alors nous ne pouvons plus nous contenter des 5 opérations élémentaires d un arbre XML. Il nous faut des opérations de plus haut-niveau ; une pour chaque balise du document XML. Il nous faut donc insertexemple, deleteexemple, insertdonnees, deletedonnees, inserttitre, DeleteTitre, inserta, deletea, insertb, deleteb, insertc, deletec, insertd, deleted plus les opérations élémentaires... Il nous faudra donc écrire 19x19 fonctions de transformation et refaire la preuve de la condition C1 sur toutes ces fonctions. L exemple que nous avons donné est bien loin de la réalité d une DTD réelle XML qui peut compter plusieurs centaines de balises différentes. Pour une DTD de 200 balises, il faudra écrire et prouver 200x200 fonctions de transformations. Nous pouvons dire que cette approche n est pas viable. Une autre approche est possible basée sur la réparation. Au lieu d intégrer les contraintes au niveau de l algorithme de synchronisation, nous allons laisser cet algorithme produire des résultats incohérents mais sur la base d un objet XML muni de 5 opérations élémentaires. Ensuite, nous voulons utiliser les algorithmes de réparation automatique développés dans le domaine des bases de données pour rétablir la cohérence après fusion. Les questions suivantes se posent : Quels sont ces algorithmes? Comment les intégrer avec des algorithmes de fusion? Sont-ils adaptés à nos besoin? Une approche basée sur la fusion + la réparation est elle viable? 2 Adel Bouhoula and Michael Rusinowitch. Implicit induction in conditional theories. Journal of Automated Reasoning, 14(2) :189 235, 1995
Chapitre 3 ETAT DE L ART Nous présenterons dans ce chapitre quelques approches proposées pour réparer automatiquement la violation des contraintes. La réparation automatique est un sujet qui a sa place dans plusieurs domaines de recherche actuelle. Dans notre cas, nous allons essayer d explorer les approches existantes et les propositions de solutions de ce problème dans les bases de données, dans les systèmes réparties et distribués. 3.1 La réparation dans les Bases de données Parmi les articles que nous avons lues dans le domaine des bases de données, cinq approches nous semblent offrir des pistes pour la résolution de notre problème. 3.1.1 Approche de Moerkotte & Lockemann C est une approche réactive applicable dans le cas des bases de données déductives[17]. Afin de mieux expliquer plus en détail l approche proposée, nous allons voir quelques notations et définitions utilisées. Notations et définitions Base Une base est un triplet DB := (DB a, DB d, DB c ) avec DB a est un ensemble de faits, DB d un ensemble de règles, et DB c un ensemble de contraintes. Extension Pour une base DB := (DB a, DB d, DB c ), une extension M(DB) := {a aestunfait, DB a} Extension complète Pour une base DB := (DB a, DB d, DB c ), une extension complète C(DB) := M(DB) { a a est un fait, DB a} Cohérence Une base DB := (DB a, DB d, DB c ) est cohérente si C(DB) DB c ne comporte pas de contradiction. Algorithme de réparation La cohérence est vérifiée à l aide des règles et méthodes classiques d évaluation de la logique, des bases de données déductives et de quelques méthodes additionnelles : :IMPL, :NOT, :AND, :OR pour les connecteurs booléens, :ALL, :EX pour les quantifieurs, :LOOK-UP pour voir si un fait appartient à la base, :APPLY-RULE pour déduire un fait à partir des règles s il n appartient pas à la base, :ATOM pour l évaluation des atomes en utilisant les deux méthodes précédentes, :CHECK-CONSTRAINT pour vérifier une contrainte de la base, :CHECK-OVERALL-CONSISTENCY qui utilise la précédente et les autres méthodes récursivement pour vérifier la cohérence de tout le système. En appliquant ces méthodes et les connecteurs à chaque contrainte, on obtient la trace de la cohérence sous forme d arbre avec un état à chaque branche (incohérent :fail ou cohérent :success). 11
CHAPITRE 3. ETAT DE L ART 12 Quand une transaction exécutée viole une contrainte, cette approche génère automatiquement des actions de réparation en trois étapes. D abord, un ensemble de «symptômes» est extrait du ou des contraintes violées (parcours de l arbre de trace). Ensuite, à partir de ces symptômes, un ensemble de «causes» est généré. Enfin, les causes sont transformées en actions de réparation par modification syntaxique. POUR CHAQUE contrainte violée (*état :fail*) extraire les «symptômes» POUR CHAQUE symptôme extraire les «causes» POUR CHAQUE cause Générer les actions de réparation FIN POUR FIN POUR FIN POUR Algorithm 1 Algorithme de réparation de Moerkotte et Lockermann Recommandations Ensuite, après obtention de toutes les actions de réparation, les auteurs définissent trois critères pour limiter leurs nombre. Ces critères sont : la simplicité : une action de réparation doit être simple, la taille : une action de réparation doit être la plus courte possible, le résultat de la réparation doit supprimer le moins d information possible. Exemple Considérons la base suivante : DB = ({isa(car, automobile), isa(automobile,vehicle), isa(vehicle,mob_obj), is(loc,at), dom(loc,vehicle), ran(loc,coord), is(bmw,automobile), is(bmwpos,coord), is(bike,vehicle),is(bikepos,coord), loc(bmw,bmwpos),loc(bike,bikepos)}, { x y isa(x, y) isa*(x, y), x y z isa(x, y), isa*(y, z) isa*(x, z), x y is(x, y) is*(x, z), x y z is(x, y), isa*(y, z) is*(x, z)}, { x z is(x, at) dom(x, z), x 1 x 2 z loc(x 1, x 2), dom(loc, z) is*(x 1, z)}). Après exécution de la transaction TA := del(isa(automobile, vehicle)) add(isa(automobile, mob_obj)). la contrainte x 1 y 2 z loc(x 1, x 2 ), dom(loc, z) is*(x 1, z) n est plus respectée. Suivant l algorithme, on cherche les symptômes à partir de cette contrainte non respectée. La figure suivante montre la trace de cette recherche. Fig. 3.1 Trace de recherche des symptômes
CHAPITRE 3. ETAT DE L ART 13 En commençant à partir de la racine de l arbre, on relie chaque noeud avec leur connecteur en introduisant la négation si son état est :succeed. On a : ( :AND( :OR loc(bmw, bmwpos) dom(loc, vehicle) not is*(bmw, vehicle))). Comme :AND ne s applique qu à une seule opérande, on peut simplifier - et on a trois symptômes : ( :OR loc(bmw, bmwpos) dom(loc, vehicle) not is*(bmw, vehicle))). Les symptômes avec des littéraux positifs sont des causes possibles. Donc, jusqu ici on a 2 causes possibles. Pour les littéraux négatifs, la combinaison avec les conclusions des contraintes permet d avoir les causes dérivées. Ainsi, avec not is(bmw, vehicle), on génère 4 causes dérivées : not is(bmw, vehicle) not isa(car, vehicle) not isa(auto, vehicle) not isa(mob_obj,vehicle) Ce qui nous donnent 6 causes. On fait de même pour tous les symptômes jusqu à ce qu on ne trouve plus de causes à partir des symptômes. Ensuite, pour chaque cause, on cherche à l étendre pour savoir si elle pourrait générer d autres causes, en faisant la même démarche qu avec les symptômes. Ainsi, on obtient toutes les causes : loc(bmw, bmwpos) dom(loc, vehicle), not dom(loc, mob_obj) not is(bmw, vehicle), is(bmw, car) not isa(car, vehicle), isa(car, auto) not isa(auto, vehicle), isa(auto, mob_obj) not isa(mob_obj, vehicle), isa(vehicle, mob_obj) La transformation des causes en actions de réparation s effectue avec des règles simples : chaque littéral positif se transforme en suppression, et chaque littéral négatif se transforme en insertion. D où, les actions de réparation : Synthèse del(loc(bmw, bmwpos)) del(dom(loc, vehicle)), add(not dom(loc, mob_obj)) add(is(bmw, vehicle)), del(is(bmw, car)) add(isa(car, vehicle)), del(isa(car, auto)) add(isa(auto, vehicle)), del(isa(auto, mob_obj)) add(isa(mob_obj, vehicle)), del(isa(vehicle, mob_obj)) Cette approche n est pas applicable dans notre cas essentiellement du fait qu elle se base sur la déduction à partir des règles. En effet, on ne dispose que des données (document XML), des contraintes et de la violation de ces contraintes pour tenter de remettre en état le document. Par contre, la démarche et les recommandations proposées sont intéressantes et utilisables. 3.1.2 Approche de Ceri et al. L approche utilisée se fonde sur les règles de production[21]. Pour chaque violation de contrainte, des règles sont générées afin de restaurer un état cohérent de la base. Notations et définitions La forme standard conjonctive (s.c.f.) d une contrainte est une formule ayant la forme x w (p 1 ( x ) p n ( x ) q 1 ( x, w ) q m ( x, w ) G( x )) La violation d une contrainte C notée C* = w C. Algorithme de réparation La violation d une contrainte C est obtenue par négation de sa formule et en libérant toutes les variables liées par le quantificateur existentiel. La base n est pas cohérente si elle ne respecte pas toutes les contraintes définies. Les actions de réparation de la base s obtiennent à partir des contraintes violées C* et sont composées des opérations :
CHAPITRE 3. ETAT DE L ART 14 d insertion : insert (P (t 1,..., t n )), de suppression : delete (P (t 1,..., t n )), de remplacement : replace (P (t 1,..., t n, t k t, k )), Avec ces opérations, ainsi que des contraintes s.c.f., l algorithme suivant permet d avoir les actions de réparation. POUR CHAQUE contrainte POUR CHAQUE litteral négatif q i dans C* qui n a pas de pair positif q, i Générer une règle d insertion sur q i FIN POUR POUR CHAQUE litteral positif p j dans C* qui n a pas de pair négatif p, j Générer une règle de suppression sur p j FIN POUR POUR CHAQUE litteral positif p k dans C* qui n a pas de pair positif p, k POUR CHAQUE variable x k dans p k Générer une règle de remplacement sur x k, p k FIN POUR FIN POUR FIN POUR Algorithm 2 Algorithme de réparation de Ceri et al. Exemple Considérons la contrainte C suivante : max volt, max pow, wire section (W IRE(wire type,...) W IRE T Y P E(wire type, max volt, max pow, wire section)) qui se traduit : chaque wire-type mentionné dans la table WIRE doit figurer dans la table WIRE-TYPE. La violation de la contrainte C* est max volt, max pow, wire section (W IRE(wire type,...) W IRE T Y P E(wire type, max volt, max pow, wire section)) Suivant l algorithme, les actions de réparation que l on pourraient avoir sont : avec W IRE(wire type,...) : > delete(wire(wire-type,...)) > replace(wire(wire-type wire-type )) avec W IRE T Y P E(wire type, max volt, max pow, wire section)) : > insert(wire-type(wire-type,?,?,?)) > replace(wire-type(wire-type wire-type )) On peut voir que, si la contrainte C définie ci-dessus n est pas respectée, la façon de la réparer est : soit de supprimer l enregistrement correpondant à ce wire-type dans WIRE(), soit de remplacer le clé wire-type de WIRE(), soit d insérer le wire-type correspondant dans WIRE-TYPE(), ou enfin soit de remplacer la clé wire-type de WIRE-TYPE(). Synthèse Cette approche n est pas applicable directement dans notre cas. Par contre, avec des adaptations dans le contexte XML, l idée de base et l algorithme qu elle propose pourraient être intéressants après l obtention des violations de contraintes du document fusionné. En effet, l expression des contrainte est assez souple, et pourra permettre d exprimer une certaine complexité. De plus, pour les données, actuellement on dispose déjà de plusieurs moyens pour convertir une donnée XML en relations ou inversement.
CHAPITRE 3. ETAT DE L ART 15 3.1.3 Approche de Teniente et Antoni Olivé Cette approche est axée sur les théories de la logique du premier ordre et des concepts relatifs aux bases de connaissances[24]. Pour voir plus en détail cette approche, nous allons voir quelques notations et définitions. Notations et définitions Une règle de déduction est une formule de la forme P (t 1,..., t m ) L 1... L n avec m 0 et n 1. P (t 1,..., t m ) est un atôme dénotant la conclusion, et est appelé «tête». L 1... L n représente des conditions et est appelé «corps». Une contrainte d intégrité est une formule que la base de connaissance doit satisfaire. Elle aura comme forme : L 1... L n avec n 1. Un prédicat d incohérence Icn est associé à une contrainte d intégrité pour avoir une règle d intégrité. Une règle d intégrité aura comme forme : Icn L 1... L n. Une base de connaissance K est un triplet K = (F, DR, IC) avec : F un ensemble de faits - nommé extension, DR un ensemble de règles de déduction - nommé intention, IC un ensemble de contraintes d intégrité. Les évènements sont des opérations modifiant l état de la base K en un nouvel état K. Un évènement peut être un évènement de base ou un évènement dérivé, c est à dire déductible à partir des faits de base et des règles de déduction. Un évènement peut introduire des mises à jour dans les prédicats dérivés ou incohérents de K, par exemple P. P exprime le même prédicat évalué dans K. Un évènement peut être : une insertion ιp défini par : x(ιp (x) P (x) P (x)) une suppression δp défini par : x(δp (x) P (x) P (x)) Les règles de transition sont des règles issues des prédicats dérivés ou incohérents P de la base. Si P est défini comme P (x) P 1 (x)... P m ) avec m 1, alors les règles de transitions issues de P peuvent être obtenues en : 1. en considérant P dans le nouvel état K, on obtient : (1) P (x) P 1 (x)... P m ) 2. avec les équivalences : (2) x(p (x) (P (x) δp (x)) ιp (x)) (3) x( P (x) ( P (x) ιp (x)) δp (x)) on substitue les littéraux de (1) positifs en utilisant (2) et les littéraux négatifs par (3). 3. Après distribution de par rapport à, on obtient les règles de transition pour P (x). Une base de connaissances augmentée notée A(K) est l ensemble formé par K et des transitions, des évènements d insertion et de suppression pour K. Une translation T d un évènement d insertion ιp (C) (respectivement de suppression δp (C) ) est un ensemble d insertions et/ou de suppression de faits qui permet d avoir P (C) (respectivement l absence P (C)) dans la base après avoir appliqué T. Algorithme de réparation L approche se base sur ce que les auteurs appellent events method (méthode des évènements). Cette méthode regroupe leurs théories pour le traitement des mises à jour (insertion ou suppression) de la base en considérant les règles de déduction et de transition (définies et dérivées) ainsi que les translations [24]. La méthode est composée de deux étapes de dérivation : dérivation constructive : pour construire de nouvelles règles, translations, transitions et nouveaux faits à partir des règles et faits existants.
CHAPITRE 3. ETAT DE L ART 16 dérivation de cohérence : pour l intégration des résultats issus de la première dérivation (avec vérification de la cohérence). Les règles à appliquer dans chaque dérivation dépendent du type de littéral considéré : ancien prédicat de base, ancien prédicat dérivé, nouveau prédicat, fait de base, fait dérivé, vrai ou faux[24]. Une translation T correspondant à une requête de mise à jour u viole une contrainte d intégrité Icn si : T inclut des évènements dont les faits iicn deviennent vrai dans la transition de l ancien état vers le nouvel état de la base. Les réparations s effectuent à partir des évènements et de la transition T qui définissent les mises à jour de la base. Pour ne pas violer la contrainte, la méthode ne considère que les transitions qui ne violent pas Icn càd ne considérer que les { u ιicn} 1. Synthèse On peut donc voir qu avec cette approche, la «réparation» fait déjà partie intégrante du traitement des évènements. Cette approche adopte la même technique que l intégration des contraintes dans l approche transformée opérationnelle. Ce que nous voudrions éviter pour une solution plus logique, pratique : la réparation automatique après la fusion. 3.1.4 Approche de Barcelo et Bertossi Cette approche est applicable dans les bases de données relationnelles[3]. Pour cela, elle se base sur les modèles de la logique du premier ordre munis de quelques notations additionnelles ainsi que des théories sur l Annotated Predicate Calculus 2. Notations et définitions Contrainte d intégrité (IC) : est une clause de la forme n i=1 p i ( t i ) m j=1 q j ( s j ) ϕ avec : p i et q j sont des prédicats, t i et s j des tuples contenant des constantes et des variables, ϕ une formule contenant des prédicats. Valeurs de vérité sur les contraintes : t c et f c indiquant la satisfaction d une contrainte. Valeurs de vérité sur la base : t d et f d selon la présence des données dans la base. Résolution des conflits entre base et contraintes : t a et f a pour résoudre les conflits entre la satisfaction d une contrainte et la base. Leurs valeurs sont calculées suivant les formules : lub(t d,f c ) = f a et lub(f d,t c ) = t a. Algorithme de réparation Les auteurs ne proposent pas de méthodes pour la vérification de la cohérence de la base dans l article. Ils situent leurs recherches dans une axe où cette vérification peut être obtenue. Le programme logique de réparation pour une base DB et la contrainte IC, notée (DB, IC), est effectué à partir des prédicats de la base. Ensuite, on applique les règles suivantes : 1. Pour chaque atome p(ā) DB, (DB, IC) contient le fait p(ā, t d ). 2. Pour chaque prédicat p, (DB, IC) contient les clauses : p( x, t ) p( x, t d ) p( x, f ) not p( x, t d ) p( x, t ) p( x, t a) p( x, f ) p( x, f a) 3. Pour chaque contrainte, W n (DB, IC) contient les clauses : i=1 pi ( t i, f a) W m j=1 qj ( sj, ta) V n i=1 pi ( t i, t ) V m j=1 qj ( sj, f ) ϕ 4. Pour chaque prédicat p, élimination des p(ā, t a ) et p(ā, f a ). 1 Cf. définition évènement insertion. 2 Kifer, M. and Lozinski, E.L. «A Logic for reasonning with inconsistency». Journal of Automated reasonning, 1992, 9(2) :179-215.
CHAPITRE 3. ETAT DE L ART 17 5. A partir de (DB, IC), obtenir (DB, IC) avec clauses : p(ā, f ) p(ā, f a) p(ā, t ) p(ā, t a) p(ā, f ) not p(ā, t d ), not p(ā, t a) p(ā, t ) p(ā, t d ), not p(ā, f a) 6. Les réparations de la cohérence de la base DB par rapport aux ICs sont extraites à partir de (DB, IC) = {p(ā) p(ā, t )} pour les insertions, et {p(ā) p(ā, f )} pour les suppressions. Pour les contraintes existentielles de la forme p( x) y (q( x,, y)) avec x, s effectuer par insertion de valeur null (f a ) ou par suppression (t a ). Pour cela, (DB, IC) doit être étendu avec les clauses suivantes : x, la réparation peut p( x, f a) q( x,, null, t a) p( x, t ), not aux( x, ), not q( x,, null, t d ) aux( x, ) q( x,, y, t d ), not q( x,, y, f a) aux( x, ) q( x,, y, t a) Application Considérons les schémas de base de données : Book(author, name, publy ear) et EuroBook(author, name, publy ear). Avec ces schémas, on considère l instance de la base de données : DB = {Book(kaf ka, metamorph, 1915), Book(kaf ka, metamorph, 1919), EuroBook(kaf ka, metamorph, 1919)}. La contrainte IC : Book(x, y, z) Book(x, y, w) z = w. Et les dépendances fonctionnelles : author, name publy ear et EuroBook(x, y, z) Book(x, y, z). On peut voir que la base DB n est pas cohérente vis à vis de la contrainte. En appliquant l algorithme proposé, on a : 1. EuroBook(kafka, metamorph, 1919, t d ) Book(kafka, metamorph, 1919, t d ) Book(kafka, metamorph, 1915, t d ) 2. Book(x, y, z, t ) Book(x, y, z, t d ) Book(x, y, z, t ) Book(x, y, z, t a) Book(x, y, z, f ) Book(x, y, z, f a) Book(x, y, z, f ) not Book(x, y, z, t d ) EuroBook(x, y, z, t ) Book(x, y, z, t d ) EuroBook(x, y, z, t ) Book(x, y, z, t a) EuroBook(x, y, z, f ) Book(x, y, z, f a) EuroBook(x, y, z, f ) not Book(x, y, z, t d ) 3. Book(x, y, z, f a) Book(x, y, w, f a) Book(x, y, z, t ) Book(x, y, w, f ) z w. EuroBook(x, y, z, f a) Book(x, y, z, t a) EuroBook(x, y, z, t ) Book(x, y, z, f ) 4. En appliquant (3.) on a : M1= {Book(kafka, metamorph, 1919, t d ), Book(kafka, metamorph, 1919, t ), Book(kafka, metamorph, 1915, t d ), Book(kafka, metamorph, 1915, t ), Book(kafka, metamorph, 1915, f a), Book(kafka, metamorph, 1915, f ), EuroBook(kafka, metamorph, 1919, t d ), EuroBook(kafka, metamorph, 1919, t )} M2= {Book(kafka, metamorph, 1919, t d ), Book(kafka, metamorph, 1919, t ), Book(kafka, metamorph, 1919, f a), Book(kafka, metamorph, 1919, f ), Book(kafka, metamorph, 1915, t d ), Book(kafka, metamorph, 1915, t ), EuroBook(kafka, metamorph, 1919, t d ), EuroBook(kafka, metamorph, 1919, t ), EuroBook(kafka, metamorph, 1919, f a), EuroBook(kafka, metamorph, 1919, f )} 5. extension de M1 avec {Book(kafka, metamorph, 1919, t ), Book(kafka, metamorph, 1915, f ), EuroBook(kafka, metamorph, 1919, t )} M2 avec {Book(kafka, metamorph, 1919, f ), Book(kafka, metamorph, 1915, t ), EuroBook(kafka, metamorph, 1919, f )} Comme réparation, l algorithme nous a donné comme solutions (M1) : l insertion des faits : Book(kaf ka, metamorph, 1919), et EuroBook(kaf ka, metamorph, 1919) la suppression des faits : Book(kaf ka, metamorph, 1915).
CHAPITRE 3. ETAT DE L ART 18 Synthèse A la limite, sans considération des dépendances fonctionnelles, cette approche pourra être appliquée à notre problème, de la même façon que l approche proposée par Ceri et Al. Dans ce cas, sans les dépendances fonctionnelles, elle peut ne pas donner toutes les solutions possibles. Ensuite, Elle n est pas très pratique. En effet, nous pouvons constater que la démarche à suivre pour avoir la solution est assez longue. De plus, avec un nombre restreint de données, on génère un nombre important de données intermédiaires qu il faut stocker avant d obtenir la solution. 3.1.5 Approche de M. Gertz et U. W. Lipeck Les auteurs proposent un framework extensible pour la réparation en se basant sur le «Model-based diagnosis»[15]. Avant d aborder leur algorithme de réparation, nous allons voir quelques notions, définitions et notations qu ils utilisent. Notations et définitions Contraintes : une contrainte C est une implication de la forme : C x : (p 1 ( x p1 )... p n ( x pn )) y : (q 1 ( x q1, y q1 )... q m ( x qm, yqm )) Une contrainte est évaluée (contrôlée) avec sa forme C telle que : C { x p 1 ( x p1 )... p n ( x pn ) : q 1 ( x q1, y q1 )... yqm : q m ( x qm, yqm ))}. y q1 Système : un système est un couple (SD, COMP) où SD est un ensemble de phrases de premier ordre qui définit la relation entre les composants du système. COMP est un ensemble de constantes composant le système. Le littéral ab(c) traduit qu un composant c de COMP est anormal. Observation : une observation OBS sur un système et ses composants est ensemble fini de phrases de premier ordre. Diagnosis : un diagnosis pour (SD, COMP, OBS) est un sous-ensemble COMP tel que : SD OBS {ab(c) c } { ab(c) c COMP } est cohérent. Un diagnostic est minimal s il n a pas un sous-ensemble propre qui est aussi un diagnosis. Conflict set : pour (SD, COMP, OBS) est un ensemble {c 1,, c n } COMP tel que SD OBS { ab(c 1 ),..., ab(c n )}est incohérent. Il est minimal s il n a pas un sous-ensemble propre qui est aussi un conflict set. Hitting set : un hitting set pour S est un ensemble H M S tel que H M {} pour chaque M S. Il est minimal s il n a pas un sous-ensemble propre qui est aussi un hitting set. Algorithme de réparation Afin de pouvoir réparer une base, on liste tout d abord toutes les réparations possibles [algorithme 3] à partir de l état incohérent constaté. Ensuite, pour chaque réparation appliquée, un nouvel état de la base est obtenu. On itère cette démarche jusqu à ce qu on trouve plus de conflits. Cette démarche a pour effet de produire un arbre représentant le cheminement, les opérations de réparation et les bases cohérentes aux feuilles de l arbre comme nous pouvons le voir sur la figure 3.2. Fig. 3.2 Enumération des réparation possibles. Mais au lieu d appliquer directement les réparations sur la base, on stocke les opérations dans des relations auxiliaires qui se nomment : differential relations respectivement I p A 1, A n, level, num, pre et D p A 1, A n, level, num, pre.
CHAPITRE 3. ETAT DE L ART 19 I p (respectivement D p ) contiendra les opérations d insertion (respectivement de suppression) pour la réparation de la base de données. Les bases sur chaque niveau obtenues àprès exécution des réparations se nomment : hypothetical databases (B level, num, pre ). Pour tout p relation de la base, ˆp hypothetical extension de p pour B level, num, pre est la relation issus de p : augmentée par les opérations d insertion pour la réparation des incohérences, diminuée par les opérations de suppression pour la réparation des incohérences. ˆp peut être calculé selon l algorithme Hypothetical extension [algorithme 9 de la page 42]. Ainsi, la contrainte C doit être modifiée afin de refléter les modifications sur ˆp : «hypothetical state constraint» C hyp de la forme C hyp x : (p 1 ( x p1 )... p n ( x pn )) y : (q 1 ( x q1, y q1 )... q m ( x qm, yqm )) Pour énumérer la liste des réparations minimales possibles d une base incohérente, l algorithme 3 est utilisé. variables /* initial (inconsistent) database B 0, 1, 0 is at level 0 */ l := 0 ; /* B 0, 1, 0is the olny hypothetical database at level 0 */ hyp_dbs_at_l := 1 ; /* violation in hypothetical database found */ violation_found := false ; /* number of hypothetical databases at level+1 */ new_dbs := 0 ; /* number of state diagnoses on a hypothetical database */ diagnoses := 0 ; /* collection of determined repair transactions */ T := {} ; /* collection of sets of critical facts */ H C := {} ; repeat violation_found :=false ; for i :=1 to hyp_dbs_at_l do /* consider hypothetical database B l, i, pre (pre is determined by l and i ) */ for each p P do determine hypothetical extension ˆp for B level, num, pre according algo 9 ; end for ; /* check hypothetical database constraints based on the ˆp s in B l, i, pre */ for each C hyp C hyp do viol C := {} ; insert result of the evaluation of violation query C ehyp into viol C ; end for ; if all violation relations are empty then if l = 0 then user transaction led to consistent database ; exit ; else /* repair transaction leading to B l, i, pre has been determinated */ add_repair_transaction(l, i, pre ) ; else violation_found := true ; H C := {} ; /* determine set of critical facts for database B l, i, pre */ for each non-empty violation relation viol C do H C = H C {set of critical facts determinated for violations in viol C } end for ; /* determine number of minimal state diagnoses on B l, i, pre using H C */ diagnoses := hitting_sets(h C, l, i, new_dbs ) ; /* increase number of hypothetical states to be considerer at next level */ new_dbs := new_dbs + diagnoses ; end for ; l := l+1 ; hyp_dbs_at_l := new_dbs ; new_dbs := 0 ; until violation_found :=false ; Algorithm 3 Recherche des réparations minimales. Recommendations En plus de l algorithme, les auteurs proposent aussi certaines critères qui seraient utiles pour toute application de réparation : changement minimal : éviter de défaire les actions précédemment effectuées par la transaction précédente,
CHAPITRE 3. ETAT DE L ART 20 adopter un système de priorité pour le choix des actions de réparation à faire, permettre l interaction avec le processus de réparation. Synthèse L approche proposée ici est un framework. Dans notre problème, il est un candidat possible pour servir de base solide à la solution que nous voudrions mettre en place. De plus, les recommandations sont très utiles si nous voulons construire une solution pratique. Nous avons vu quelques approches proposées pour la réparation dans les cadres des bases de données. Mais les recherches et l état de l art actuel ne se limite pas qu à ce domaine. La section suivante présentera deux systèmes pour le maintien de la cohérence pour les données répliquées : Bayou et IceCube. 3.2 Cohérence des données et réplication optimiste 3.2.1 Bayou Description générale Bayou est un système de gestion de données pour des applications collaboratives dans un environnement mobile[19, 2]. Les données sont répliquées entre les différents serveurs sous forme d une base de données. Une application Bayou est un client qui interagit avec un serveur pouvant cohabiter sur la même machine. Un client peut effectuer des lectures sur le serveur et envoyer des écritures. Une fois qu une écriture a été acceptée par un serveur, le client n est plus responsable de celle-ci. En particulier, il n a pas se soucier de la propagation vers les autres serveurs. Bien que les lectures et les écritures d un client soient effectuées sur un seul serveur, le client peut interagir avec plusieurs serveurs. La cohérence entre les copies des différents serveurs est maintenue par un protocole anti-entropique. Protocole Anti-Entropie Le protocole anti-entropie assure que toutes les copies tendent vers un même état cohérent et stable. Ce protocole requiert que chaque serveur maintienne trois structures de données : un journal des opérations qui contient toutes les opérations ayant été reçue par le serveur. A chaque opération est associée l identité du site émetteur et le vecteur d état sur lequel elle a été générée ; un premier vecteur d estampille qui mémorise l estampille de la dernière opération reçue par le serveur ; un second vecteur d estampille qui mémorise les acquittements de réception des opérations reçus des autres sites. A intervalle régulier, un serveur sélectionne un autre serveur parmis l ensemble des serveurs pour démarrer une session d anti-entropie. Les deux serveurs commencent par s échanger leur vecteur d estampille. En les comparant, ils peuvent ainsi détecter les opérations qu ils n ont pas encore reçues. Ces opérations sont alors extraites du journal du serveur qui les possède, puis sont envoyées à l autre serveur. De session en session, les opérations vont être propagées de manière épidémique l ensemble des serveurs. Une session respecte certaines propriétés définies : propagation épidémique : toutes les mises à jour seront propagées à tous les réplicas ordre globale sur les mises à jour : garantie que tous les sites auront appliquées les même mises à jour dans le même ordre détection des conflits déterministe : tous les sites détecteront les même conflits résolution des conflits déterministe : tous les sites résoudront de la même manière les conflits propagation progressive des opérations : seulement les écritures inconnues sont transférées entre deux serveurs (monodirectionnel) ordonnancement des écritures : le protocole «primary commit» est appliqué pour stabiliser les écritures dans le système. La copie primaire effectue l ordonnancement des écritures, elle associe pour chaque écriture un numéro d ordre nommé CSN (commit sequence number). Détection des conflits Bayou_Write = { update = {insert, Meeting, 12/18/95, 1 :30pm, 60mn, Budget Meeting }, dependency_check = { query = SELECT key FROM Meetings WHERE day = 12/18/95
CHAPITRE 3. ETAT DE L ART 21 } AND start < 2 :30pm AND end > 1 :30pm, expected_result = EMPTY }, mergeproc = { alternates = {{12/18/95, 3 :00pm}, {12/19/95, 9 :30am}} ; newupdate = {} ; FOREACH a IN alternates { #check if there would be a conflict IF (NOT EMPTY( SELECT key FROM Meetings WHERE day = a.date AND start < a.time + 60mn AND end > a.time)) CONTINUE ; #no conflict, can shedule meeting at that time newupdate = {insert, Meetings, a.date, a.time, 60mn, Budget Meeting } ; BREAK ; } IF (newupdate = {}) # no alternate is acceptable newupdate = {insert, ErrorLog, 12/18/95, 1 :30pm, 60mn, Budget Meeting ) ; RETURN newupdate ; } Algorithm 4 Algorithme sous Bayou Le système Bayou permet de détecter des conflits spécifiques à une application donnée. A chaque demande de mise à jour est associée une procédure dependency checks qui sert à vérifier les préconditions de celle-ci. Cette procédure consiste en une requête sur la base et la valeur du résultat attendu. Un conflit est détecté si l exécution de cette requête sur l état courant de la base retourne un résultat différent de celui escompté. Prenons par exemple la gestion des réunions. La procédure «dependency check» de l opération de mise à jour illustrée par l exemple d algorithme 4 vérifie si, sur l état actuel de la base, il n existe pas de réunion chevauchant le même créneau horaire que celui que l on veut réserver. Pour cela, la procédure sélectionne dans la base tous les réunions qui ont lieu le même jour, et qui commence avant la fin de la réunion à ajouter, ou qui se termine après son début. Le résultat attendu de cette requête est bien entendu l ensemble vide. Comme dans les autres systèmes distribués qui utilisent des vecteur d état, les procédures dependency checks du système Bayou permettent de détecter les conflits de mise à jour écriture/écriture. Elles peuvent être utilisées pour détecter un conflit lorsque deux utilisateurs mettent à jour la même donnée, sans qu aucun des deux utilisateurs n ait vu la modification de l autre pour plusieurs raisons possibles. Ce genre de conflit peut être détecté en déclarant dans la procédure «dependency check» une requête qui vérifie la valeur actuelle de chaque données modifiées, et en s assurant qu elles n ont pas changées depuis que la mise à jour a été envoyée. Mais le mécanisme mis en place dans Bayou est plus évolué car il peut également détecter les conflits lecture/écriture. En effet, chaque demande de mise à jour peut spécifier la valeur de chaque donnée dont dépend la mise à jour ; pas uniquement les valeurs mises à jour, mais aussi les valeurs n ont été que consultées. Résolution des conflits Dans le cas où un conflit est détecté, la mise à jour n est pas effectuée et le serveur invoque une procédure de résolution. Cette procédure appelée «merge procedure» est associée à chaque opération d écriture. Elle a la charge de résoudre tous les conflits détectés par la procédure «dependency checks» en produisant une nouvelle opération de mise à jour. Cette procédure est exprimée dans un langage de haut niveau et peut embarquer des données nécessaires à la représentation de la sémantique de l application lors de cette phase de résolution. Par exemple, dans le cas d une application de gestion de réunion, comme illustrée par l exemple d algorithme 4, la procédure de résolution embarque une liste contenant d autres créneaux horaires possibles pour la réunion. La procédure va donc parcourir cette liste, et pour chaque élément de cette liste vérifier si le créneau n est pas utilisé. Lorsqu elle a trouvé un créneau libre, elle modifie l opération de mise à jour en définissant ce nouveau créneau comme le nouveau créneau de la réunion. Dans le cas où aucun des créneaux embarqués ne seraient libres, l opération de mise à jour n est pas exécutée ; celle-ci est consignée dans un journal.
CHAPITRE 3. ETAT DE L ART 22 Synthèse Nous pouvons donc voir que l approche de la réparation dans Bayou suppose que le concepteur «informe» le système sur les données et des possibilités de résolution de conflit pour que cela puisse fonctionner (dependency check et merge procedure). Le système peut se trouver dans un état où il n arrive pas à trouver une solution pour éviter le conflit. Dans ce cas, les actions et les mises à jour de l utilisateur sont «perdues» car elles ne sont pas prises en compte mais sont seulement consignées dans le journal. 3.2.2 IceCube Projet de recherche du laboratoire Microsoft Research, IceCube est un système de réconciliation générique[2]. Ce système traite la réconciliation comme un problème d optimisation : celui d exécuter une combinaison optimale de mises à jour déconnectées. IceCube repose sur une approche dite «basée sur les opérations» en enregistrant les actions de mise à jour dans un journal. A partir des différents journaux qui ont été générés sur les différents sites, IceCube va calculer un journal optimal unique contenant le maximum de mise à jour non conflictuelles. Pour cela, IceCube utilise la sémantique des mises à jour exprimée sous forme de contraintes. Modélisation Dans IceCube, les mises à jour sont modélisées par des actions. Une action est composée de : pré-condition : (équivalente à la procédure «Dependency check» de l action Bayou). Elle permet de détecter les conflits éventuels lors de l exécution et durant la phase de simulation. une opération : un sous programme accédant aux objets partagés post-condition : Elle est exécutée si un conflit détecté n est pas résolu par les politiques de réconciliation prédéfinies (équivalente à la procédure «Merge procedure» de Bayou). Les pré-conditions et les post-conditions sont exprimées dans un langage de logique du premier ordre. Ce qui permet au système de définir des dépendances sémantiques entre les opérations sous forme de contraintes. Réconciliation Fig. 3.3 Fonctionnement de IceCube Fig. 1.3 IceCube La réconciliation se déroule en trois phases et est illustrée par la Figure 3.3 : 1. une phase symbolique : Durant cette phase, le système construit toutes les histoires qu il est possible d obtenir en combinant les différentes actions issues des journaux des différents sites avec un algorithme de recherche heuristique. L espace de recherche est limitée par les contraintes statiques. 2. une phase de simulation : on simule les différents résultats possibles de l application des différents ordres trouvés pendant la phase symbolique. 3. une phase de sélection : choix d un journal parmi les différents journaux possibles.
CHAPITRE 3. ETAT DE L ART 23 Synthèse Nous pouvons voir que IceCube et notre problème partagent des caractéristiques communes : approche basée sur les opérations et existance de pré-conditions en guise de contraintes. Néanmoins, le mécanisme de résolution proposé dans IceCube n est pas applicable dans notre cas. En effet, d un côté, chaque action doit posséder une post-condition. Dans notre cas, une action correspond à une opération où son exécution n est conditionnée ni par la pré-condition ni par le post-condition. De plus, la phase combinaison et simulation pourraient générer une explosion combinatoire des possibilités comme pour l intégration des contraintes dans les transformées opérationnelles.
CHAPITRE 3. ETAT DE L ART 24 3.3 XLinkIt XLinkIt est un framework destiné pour contrôler la cohérence de documents distribués et hétérogènes[6]. Il est composé : d un langage d expression des contraintes, basé sur la logique du premier ordre, d un mécanisme de gestion de document (données et contraintes), d un moteur de vérification de contraintes. Il est implémenté avec les technologies libres XML[28] et XPath[29]. Ce qui le permet d être un outil indépendant, facilement utilisable et intégrable. Notations et définitions Document est un fichier XML contenant les données dont la cohérence est à vérifier par rapport à une règle (rule) ou à un ensemble de règles (ruleset). DocumentSet est un ensemble de Document XML 3. RuleFile est un fichier contenant les règles exprimant les contraintes à respecter. RuleSet est un ensemble de rules 4. Formula est une formule logique de premier ordre combinée avec des chemins XPath de la forme : formula : := var XP ath(formula) var XP ath(formula) formula formula formula formula formula formula formula RelativeP ath = RelativeP ath Consistency rule est une règle décrivant la contrainte à respecter. Elles sont listées dans les RuleFile 5. Consistency Link est un résultat de la vérification de la cohérence d un Document/DocumentSet par rapport à une ConsistencyRule 6. Il contient la liste des liens vers les données contrôlées, le lien vers la règle utilisée et l état de la contrainte (cohérente ou incohérente). Action est une type de modification que l on peut faire avec un document. Action : := add Accessor delete Accessor change Accessor Accessor accesseur vers un noeud de l arbre XML issu d un Document ou Rule. Path chemin absolu ou relatif XPath désignant un noeud. Algorithme de réparation A partir de la constatation d incohérence d une règle et de son ConsistencyLink, les auteurs proposent les formules de réparation suivantes[5] : Cas des formules «positives» D i : formula ( (Action)) 1. D i[ var XP ath (formula)] σ,τ = {{delete Direct locator(var)}} x D i[formula] ({var,xp ath} σ),({var} τ) 2. D i[ var XP ath (formula)] σ,τ = {{add Lookup XP ath}} x N i[formula] {(var,xp ath)} σ,τ 3. D i[formula and formula] σ,τ = D i[formula 1] σ,τ D i[formula 2] σ,τ (D i[formula 1] σ,τ x D i[formula 2] σ,τ ) 4. D i[formula 1 or formula 2] σ,τ = D i[formula 1] σ,τ x D i[formula 2] σ,τ 5. D i[formula 1 implies formula 2] σ,τ = D c[formula 1] σ,τ x D i[formula 2] σ,τ 6. D i[not formula] σ,τ = D c[formula] σ,τ 7. D i[relativep ath 1 = RelativeP ath 2] σ,τ = change(relativep ath 1, σ, τ) x change(relativep ath 2, σ, τ) Algorithm 5 Reparation : Cas des D i : formula ( (Action)) 3 Cf. exemple en Annexe7.2. 4 Cf. exemple en Annexe 7.2. 5 Cf. exemple en Annexe 7.2. 6 Cf. exemple en Annexe 7.2.
CHAPITRE 3. ETAT DE L ART 25 Cas des formules «négatives» D c : formula ( (Action)) 1. D c[ var XP ath (formula)] σ,τ = {{add Lookup XP ath}} x N i[formula] {(var,xp ath)} σ,τ 2. D c[ var XP ath (formula)] σ,τ = {{delete Direct locator(var)}} x D c[formula] ({var,xp ath} σ),({var} τ) 3. D c[formula and formula] σ,τ = D c[formula 1] σ,τ x D c[formula 2] σ,τ 4. D c[formula 1 or formula 2] σ,τ = D c[formula 1] σ,τ D c[formula 2] σ,τ (D c[formula 1] σ,τ x D c[formula 2] σ,τ ) 5. D c[formula 1 implies formula 2] σ,τ = D i[formula 1] σ,τ x D c[formula 2] σ,τ 6. D c[not formula] σ,τ = D i[formula] σ,τ 7. D c[relativep ath 1 = RelativeP ath 2] σ,τ = change(relativep ath 1, σ, τ) x change(relativep ath 2, σ, τ) Algorithm 6 Reparation : Cas des D c : formula ( (Action)) Cas des N i : formula ( (Action)) 1. N i[ var XP ath (formula)] σ,τ = {{delete Lookup XP ath}} x N c[formula] {(var,xp ath)} σ,τ 2. N i[ var XP ath (formula)] σ,τ = {{add Lookup XP ath}} x N i[formula] {(var,xp ath)} σ,τ 3. N i[formula and formula] σ,τ = N i[formula 1] σ,τ x N i[formula 2] σ,τ 4. N i[formula 1 or formula 2] σ,τ = N i[formula 1] σ,τ x N i[formula 2] σ,τ 5. N i[formula 1 implies formula 2] σ,τ = N c[formula 1] σ,τ x N i[formula 2] σ,τ 6. N i[not formula] σ,τ = N c[formula] σ,τ 7. N i[relativep ath 1 = RelativeP ath 2] σ,τ = change(relativep ath 1, σ, τ) x change(relativep ath 2, σ, τ) Algorithm 7 Reparation : Cas des N i : formula ( (Action)) Cas des N c : formula ( (Action)) 1. N c[ var XP ath (formula)] σ,τ = {{add Lookup XP ath}} x N i[formula] {(var,xp ath)} σ,τ 2. N c[ var XP ath (formula)] σ,τ = {{delete Lookup XP ath}} x N c[formula] {(var,xp ath)} σ,τ 3. N c[formula and formula] σ,τ = N c[formula 1] σ,τ x N c[formula 2] σ,τ 4. N c[formula 1 or formula 2] σ,τ = N c[formula 1] σ,τ x N c[formula 2] σ,τ 5. N c[formula 1 implies formula 2] σ,τ = N i[formula 1] σ,τ x N c[formula 2] σ,τ 6. N c[not formula] σ,τ = N i[formula] σ,τ 7. N c[relativep ath 1 = RelativeP ath 2] σ,τ = change(relativep ath 1, σ, τ) x change(relativep ath 2, σ, τ) Algorithm 8 Reparation : Cas des N c : formula ( (Action)) Exemple Considérons la contrainte : x /a ( y /b ($x/@name = $y/@name)). qui peut se traduire comme : pour tout attribut a, s il existe un attribut b correspondant, ils doivent avoir le même nom. Si cette contrainte n est pas respectée, les actions de réparation seront obtenues à partir de la formule D i [ var XP ath (formula)] σ,τ (1). 1. Cette formule va générer, une action de suppression sur x : {{Delete 1}} 1 designe la référence de location retourné par Xlinkit. 2. Ensuite appele D i [ var XP ath(formula)] σ,τ qui a son tour va permettre d avoir {{AddLookup /b }}, 3. Enfin, se termine par l appel de N i [$x/@name = $y/@name] σ,τ qui va avoir comme résultat Change Direct 1 @name, Change Lookup /b @name. On peut donc voir que les actions de réparation générées en vue de respecter la contrainte sont : soit la suppression du noeud «/a», soit l insertion d un noeud «/b» correspondant à un noeud «/a», soit le changement de l attribut «@name» de «/a» correspondant à un noeud «/b», soit inversement le changement de l attribut «@name» de «/b» correspondant à un noeud «/a».
CHAPITRE 3. ETAT DE L ART 26 Synthèse L algorithme proposé ici est applicable à notre problème. De plus, il est peut donner toutes les solutions possibles (complétude). En outre, cette approche a l avantage d avoir une implantation disponible pour l expression des contraintes, la vérification et le rapport de la cohérence des documents par rapport aux contraintes définies. Ce qui le distingue des tous les autres approches que nous avons vu jusqu ici.
Chapitre 4 PROPOSITION Dans ce chapitre nous commencerons par proposer un algorithme de réparation. Ensuite, nous allons essayer de l appliquer sur quelques exemples d incohérence à partir de cette algorithme. Puis, nous essayerons d intégrer dans l algorithme et la démarche les recommandations qui ont été proposées par les différents auteurs que nous avons vus. Pour compléter la démarche, nous verrons le moyen d expression et de vérification des contraintes. Enfin, nous terminerons par proposer un moyen de refléter les actions de réparation générées sur tous les site impliqués. 4.1 La réparation 4.1.1 Algorithme de réparation automatique Nous avons vu plusieurs approches de réparation dans l état de l art. Parmi ces approches, trois nous semblent intéressantes : approche de Ceri et al. (que nous allons noter : [a-1]), approche de Gertz et Lipeck (que nous allons noter : [a-2]), approche de C. Nentwich, W. Emmerich et A. Finkelstein (que nous allons noter : [a-3]). Ces approches ont été exprimées dans différentes notations et conçues pour différents domaines d application. D un côté, les deux premières, pour les bases de données et de l autre côté, la dernière, pour les documents distribués (XML). Malgré cela, elles ont une caractéristique commune : exprimer des contraintes en logique du premier ordre. A partir de cette constatation, nous pouvons faire une comparaison entre ces trois approches afin de déterminer l approche la plus adéquate pour notre problème. Pour [a-1], la contrainte s exprime dans une forme standard conjonctive (s.c.f.) : x w (p 1 ( x ) p n ( x ) q 1 ( x, w ) q m ( x, w ) G( x )) La génération des actions de réparation se fait sur la base de la négation de la contrainte : C* = w C : w (p 1 ( x ) p n ( x ) q 1 ( x, w ) q m ( x, w ) G( x )). L opération de réparation générée sur une violation de cette contrainte est : l insertion pour les p i positif. la suppression pour les q i négatif. Pour [a-3], l algorithme de génération s effectue à partir de la contrainte même (non pas sa négation). La violation de cette contrainte entraîne la génération des actions de réparation : D c [ p XP ath ()] σ,τ = {{add Lookup XP ath}}+n i [ var XP ath ()] σ,τ pour x (p 1 ( x ) p n ( x )), N i [ q XP ath ()] σ,τ = {{delete Lookup XP ath}} pour w ( q 1 ( x, w ) q m ( x, w )). Notons que add correspond à une insertion de noeud, delete à une suppression de noeud. Un noeud correspond à une variable (ici p i et q i ). De même pour [a-2], à partir de la contrainte et selon la fonction hitting_set(), nous allons avoir comme action de réparation : for each negative literal p( x ), insert ( x, l + 1, n + m + 1, i) into I p : autrement dit la réparation = insertion pour les littéraux p i, 27
CHAPITRE 4. PROPOSITION 28 for each positive literal q( w ), insert ( w, l+1, n+m+1, i) into D q : autrement dit la réparation = suppression pour les littéraux q i. Nous pouvons voir donc que les trois algorithmes utilisent le même raisonnement pour générer les actions de réparation. On pourra utiliser chacun des trois approches mais il est plus judicieux de se baser sur l approche [a-3] du fait qu il offre déjà une notation, une utilisation pratique et que nous travaillons avec des documents XML. de plus, la raison la plus importante c est sa complétude. Néanmoins, le framework défini par l approche [a-2] se différentie et offre plus d efficacité par rapport aux autres approches par l utilisation de l arbre de recherche des états cohérents [3.2] que nous proposons d utiliser dans la suite. 4.1.2 Résolution d exemples Afin de montrer le fonctionnement et l efficacité de la solution proposée, nous allons l utiliser pour réparer les incohérences et violations des contraintes constatées dans l exemple suivant. Fig. 4.1 Exemple de document XML issu d une fusion Cet exemple montre des données qui sont correctes du point de vue syntaxique XML : balise de début et balise de fin. Toutefois, du point de vue sémantique et selon les contraintes définies dans la problématique, il comporte des incohérences. En effet, nous pouvons constater de visu dans les extraits issus de ce fichier des exemples de données conformes, respectivement non-conformes, à ces contraintes : Exemple de contrainte 1 : Unicité de titre
CHAPITRE 4. PROPOSITION 29 Exemple de contrainte 2 : Présence d attribut Exemple de contrainte 3 : Exclusion d attribut Résolution de l exemple 1 : Unicité La contrainte «un document ne doit avoir qu un seul titre» peut s exprimer comme : d /exemple/donnees ( ( t $d/titre ) ( x $d/titre ( y $d/titre ( $x = $y )) ) Cette contrainte génère des liens d incohérence pour les données : /EXEMPLE/DONNEES[2] : il y a deux titres, et /EXEMPLE/DONNEES[3] : aucun titre n est présent. Les actions de réparation pour cette contrainte sont obtenues par D i [ var XP ath (formula)] σ,τ, D i [ var XP ath (formula)] σ,τ et D i [formula and formula] σ,τ. Donc en partant de l expression de la contrainte et en suivant l algorithme, on aura : 1. D i [ d /exemple/donnees ] := {{delete Direct locator(d)}}. := on supprime le noeud pointé par d.
CHAPITRE 4. PROPOSITION 30 2. ensuite, on a D i [ t $d/titre ] := {{add Lookup $d/titre }} (car N i [formula] ne s applique pas). := on insère un titre pour les données qui n en a pas. 3. puis, on continue avec D i [ x $d/titre ] := {{delete Direct locator(x)}}. := on supprime le titre référencé par x. Le résultat est le même que l application de la réparation suivante mais avec la variable x au lieu de y. 4. enfin D i [ y $d/titre ] := {{delete Direct locator(y)}}. := on supprime le titre référencé par y. Résolution de l exemple 2 : Présence la contrainte «Un Document doit avoir un attribut de type «b» s il possède un attribut de type «a»» peut s exprimer comme : d /exemple/donnees ( ( x $d/a ( y $d/b ) ) Cette contrainte génère un lien d incohérence pour la donnée /EXEMPLE/DONNEES[2]. Les actions de réparation pour cette contrainte sont obtenues par D i [ var XP ath (formula)] σ,τ, D i [ var XP ath (formula)] σ,τ. Ce qui donne : 1. D i [ d /exemple/donnees ] := {{delete Direct locator(d)}} := on supprime le noeud pointé par d.
CHAPITRE 4. PROPOSITION 31 2. puis, on a D i [ x $d/a ] := {{delete Direct locator(x)}} := on supprime l attribut «a» qui n a pas de «b». 3. enfin avec D i [ y $d/b ] := {{add Lookup $d/b }} := on insère un attribut «b» pour compléter «a». Résolution de l exemple 3 : Exclusion la contrainte «Un Document ne doit plus avoir un attribut de type «d» s il possède déjà un attribut de type «c»» peut se traduire en : x /exemple/donnees ( y $x/c ( ( z $x/d )) ) Cette contrainte génère un lien d incohérence pour les données : /EXEMPLE/DONNEES[2] et /EXEMPLE/DONNEES[3] car il y a à la fois un atribut C et un attribut D. Les actions de réparation pour cette contrainte sont obtenues par D i [ var XP ath(formula)] σ,τ, D i [not(formula)] σ,τ et D c [ var XP ath(formula)] σ,τ. Ce qui donne :
CHAPITRE 4. PROPOSITION 32 1. D i [ x exemple/donnees ] := {{delete Direct locator(x)}} := on supprime le noeud pointé par x. 2. puis, on procède avec D i [ y $x/c ] := {{delete Direct locator(y)}} := on supprime l attribut «c» référencé par y. 3. enfin, on traite D c [ z $x/d ] := {{delete Direct locator(z)}} (car D c [formula] ne s applique pas) := on supprime l attribut «d» référencé par z. Le résultat est le même que l application de la réparation précédente mais avec la variable z au lieu de y. 4.1.3 Interaction avec le processus de réparation Certaines contraintes peuvent nécessiter des traitements particuliers du fait de leur nature. Par exemple, nous savons que les modifications (update) peuvent être remplacées par une succession de suppression et d insertion. Malheureusement, les valeurs qui seront utilisées peuvent être : null, par défaut, à demander l utilisateur. Pour éviter cela, et pour se conformer aux recommendations de Gertz et Lipeck[15], nous devons offrir d autres moyens que la réparation automatique définis précédemment : une forme d interaction avec le processus.
CHAPITRE 4. PROPOSITION 33 Nous proposons de mettre en oeuvre l interaction par l intermédiaire d un fichier XML. Ce fichier contiendra une liste d actions de réparation personnalisée de cette forme : <consistencyrepair name = «repairname» rule = «ruleid» > <header> <description> Description de la reparation </description> <author>auteur</author> <comment> Commentaire pour cette action de réparation </comment> </header> <repairaction> <actionlist/> </repairaction> </consistencyrepair>. Dans ce cas, la propriété <repairaction></repairaction> est constituée d une liste d actions de réparation actionlist à faire. Cette liste est un ensemble défini composé d une seule action ou de plusieurs actionlist combinées avec les opérateurs «and» et «or». actionlist := action and or [Détail du syntaxe de AND et OR : voir Annexe 7.5] action peut être soit une action de réparation, soit une assignation d une valeur pour un attribut. Cette valeur pourra être une valeur par défaut ou une valeur calculée. action := repair assign repair est une action de réparation. Elle peut être soit une insertion soit une suppression d un couple attribut-valeur. En effet, la modification peut être remplacée par une succession d insertin et de suppression. repair := insert delete Syntaxe de INSERT <insert> <attribute = «attr» value = «valeur» /> </insert> Syntaxe de DELETE <delete> <attribute = «attr» /> </delete> Syntaxe de ASSIGN <assign> <attribute = «attr» value = «valeur» /> </assign> Pour insert, delete et assign, attr peut être une variable définie dans la contrainte sémantique «ruleid» ou un numéro qui indique le lien incohérent (utilisation de consistencylink). valeur est une constante ou/et une expression XPath évaluable à partir de attr. attr := var link Exemple Si on considère la contrainte d unicité du titre de notre exemple, nous pouvons créer une action de réparation de la forme : <consistencyrepair name = «reparation-perso-titre» rule = «rule-titre» > <!-- header --> <repairaction> <and> <delete><attribute = «1» /></delete> <and> <delete><attribute = «2» /></delete> <insert> <attribute = «1» value = «1/value() ou 2/value()»/> </insert>
CHAPITRE 4. PROPOSITION 34 </and> </and> </repairaction> </consistencyrepair> Ce qui peut être interprété comme : la suppression des deux titres redondants du noeud document numéro 2, l insertion d un nouveau attribut titre avec comme valeur «TITRE-2 ou TITRE-3». 4.1.4 Changement minimal Les recommandations de Gertz et Lipeck [15] nous préconise d intégrer dans le processus de réparation : l élimination des actions qui annulent les actions précédemment effectuées : ceci afin d éviter par exemple le désagrément du boucle infini! le choix des opérations d insertion (ou de modification) plutôt que de suppression afin de préserver les données (ou l historique des données). Pendant la construction de l arbre de recherche des états cohérents, nous pouvons intégrer ces critères en adoptant la démarche de l algorithme de la fonction hitting_set() 1. 4.1.5 Priorités En attribuant des priorités (poids) aux actions de réparation, nous pouvons indiquer au système notre préférence pour un ensemble d actions de réparation. En effet, chaque opération de réparation peut avoir une «qualité», un temps d exécution, manipuler des données plus ou moins sensibles avant d arriver à un état cohérent recherché. Les actions de réparation automatique auront une priorité par défaut de 1. L interaction avec le processus de réparation doit ainsi être modifiée avec l introduction de cette notion de priorité. Pour cela, la syntaxe des actions de réparation personnalisées sera : <consistencyrepair name = «reparation-perso-titre» rule = «rule-titre» priority = «valeur» > <header> <!--... --> </header> <repairaction> <!--... --> </repairaction> </consistencyrepair> Une action de réparation action-1 est préférable à une autre action-2 si la priorité de action-1 est inférieur à celle de action-2. 4.2 Synthèse Parmi les algorithmes de réparation que nous avons étudié, trois approches nous semblent intéressantes pour la réparation automatique à savoir : l approche de Ceri et al., le framework de Gertz et Lipeck, et la réparation des documents distribués XML de Nentwich et al. C est sur dernier que s est porté notre choix du fait de sa simplicité, ses fonctionnalités et sa complétude. Néanmoins, cet algorithme seul ne pouvait suffire pour traiter tous les cas possibles. Nous avons donc, sous l influence des recommandations de Gertz et Lipeck, proposé de considérer l aspect minimal des changements apportés aux données pendant la réparation, ainsi que le système de priorité afin de privilégier une action de réparation par rapport à une autre selon la situation. Le chapitre présentera le projet que nous avons réalisé pour valider notre proposition. 1 Cf. page 42
Chapitre 5 IMPLEMENTATION 5.1 Le projet SO6 Notre travail puise sa source et sa continuité à partir du projet SO6 de LibreSource [20]. LibreSource est une plate-forme logiciel permettant l animation de communautés distribuées, de développeurs, par l intermédiaire d une interface web standard. Véritable alternative au site SourceForge, LibreSource a pour ambition de devenir une alternative européenne s inscrivant dans le long terme. C est un projet de plate-forme du Réseau National de recherche et d innovation en Technologies Logicielles (RNTL), développé au sein d un consortium composé de la société Artenum, de l équipe ECOO, de l INRIA, et de l Université Paris 7-Denis Diderot. Quant à SO6, c est un synchroniseur de fichiers et système de fichier utilisé dans LibreSource. Il se base sur la fusion de données XML et les transformées opérationnelles. L exemple de démonstration cité en référence du projet est la fusion de deux dessins de deux utilisateurs à partir d un dessin initial. Ce dessin initial est stocké sous forme de fichier SVG/XML. Fig. 5.1 Dessin initial partagé et stocké sous forme de fichier SVG/XML Le déroulement de la collaboration est exactement le même que nous avons présenté dans le chapitre problématique de ce rapport. Chaque utilisateur effectue des modifications locales à partir de l objet partagé. Puis, SO6 effectue la fusion et produit un fichier SVG/XML représentant le dessin contenant les modifications de tous les utilisateurs. C est après cette fusion qu intervient notre travail afin de vérifier que le document fusionné correspond à certaines contraintes qui ont été définies. Dans le cas contraire, de remettre en état ce document suivant les contraintes. 35
CHAPITRE 5. IMPLEMENTATION 36 5.2 Validation de la proposition En considerant le problématique et l algorithme de réparation proposé, l utilisation de XLinkIt[6] nous offre la solution concernant l expression des contraintes et la vérification de la cohérence. Les paragraphes suivantes illustrerons le langage d expression des contraintes et la manière dont XLinkIt fonctionne pour vérifier la cohérence des documents. 5.2.1 Expression des contraintes sémantiques La plupart des approches de réparation dans les bases de données que nous avons présentées se basent sur la logique du premier ordre pour l expression des contraintes et pour la génération des actions de réparation. XLinkIt en se basant sur CLiX (Constraint Language in XML) [7] permet l expression des contraintes en langage logique du premier ordre et de profiter des avantages offerts par XPath. Sous XLinkIt, les contraintes sont exprimées sous forme de formules de cette forme : formula forall Formula traduit toute formule logique du premier ordre de la forme : formula := forall exists implies and or not equal var XP ath (formula) est traduit par : <forall var = «variablename» in = «quantifierpath» > <formula/> <forall> L annexe 7.4 de la page 43 présente la syntaxe de toutes les autres formules restantes non présentées ici. 5.2.2 Démarche de réparation Muni de la notation, du fonctionnement, de la syntaxe d expression des contraintes de XLinkIt et de l algorithme de réparation, nous pouvons résumer dans la figure suivante la démarche de réparation que nous proposons. Fig. 5.2 Procédure de réparation.
CHAPITRE 5. IMPLEMENTATION 37 On prend un ensemble de contraintes (1,3) et de données (2,4). Le «checker» (5) effectue la vérification de la cohérence et retourne un ensemble de liens d incohérence (6). Muni de ces liens et des actions de réparation personnalisées(7,8), le «repaire generator» (9) construit l arbre de recherche des états cohérents (10). Ensuite, en ajoutant les informations de priorité dans l arbre (chaque fois qu on y ajoute une opération de réparation), le choix des actions de réparation pour une contrainte peut être fait facilement et automatiquement (11) par le calcul de la somme des priorités de la racine aux feuilles. Enfin, l ensemble des actions de réparation approprié choisie (12), on effectue la réparation proprement dite afin de retourner un document conforme aux contraintes sémantiques définies (14). 5.2.3 Génération des actions de réparation Pour valider notre proposition, nous l avons implémentée en suivant la démarche proposée. Pour cela, nous avons utilisé les contraintes du fichier Rule.xml et les données du fichier Document.xml de la Figure 5.3. Fig. 5.3 Contraintes et données utilisées pour la validation de la proposition Si on suit l algorithme proposé manuellement, les données suivantes seront incohérentes par rapport aux contraintes définies : 1. pour la contrainte «exclusion-c-et-d» : /EXEMPLE/DONNEES[3] : il y a à la fois un attribut C et un attribut D. 2. pour la contrainte «unicite-titre» : /EXEMPLE/DONNEES[2] : il existe deux titres /EXEMPLE/DONNEES[3] : la donnée n a pas de titre 3. pour la contrainte «presence-a-et-b» : /EXEMPLE/DONNEES[1] : l attribut A est présent alors qu il n y a pas d attribut B
CHAPITRE 5. IMPLEMENTATION 38 La trace d exécution, les liens d incohérence (ConsistencyLink) et les actions de réparation générées par notre programme à partir de ces deux fichiers sont listés dans la Figure 5.4. Fig. 5.4 Les actions de réparations générées. Nous pouvons voir que la procédure de détection de notre programme fournit les mêmes liens d incohérence que le déroulement manuel. Ensuite, le programme génère aussi toutes les actions de réparations possibles pour chaque violation constatée.