4.2.1 Idées de base du processus d’interrogation
Dans SenPeer, une requête est formulée par un pair sur son schéma et donc dans le langage d’inter- rogation de son schéma (SQL, XQuery, etc.). Les réponses attendues ne sont pas seulement ses données locales mais aussi celles des pairs de sa communauté ou des communautés alliées distantes. Dans le premier cas, l’interrogation se fait comme dans un système de gestion de données traditionnel. Dans le second cas, la requête est envoyée au parrain du pair qui va se charger de superviser son exécution au sein de la communauté, mais aussi de l’envoyer vers les communautés alliées pertinentes pour la requête. Nous pouvons résumer le traitement des requêtes par les étapes suivantes:
1. Une requête est exprimée par un utilisateur à l’aide de l’interface graphique utilisateur du pair, sur le schéma du pair mais aussi avec son langage d’interrogation. La requête est d’abord exécutée sur les données locales comme dans un système de gestion de données traditionnel. Si les résul- tats de cette phase ne sont pas suffisants (par exemple l’ensemble de réponses est vide), la phase d’interrogation du reste du réseau est initiée.
2. La requête est reformulée dans un format d’échange de requêtes appelé SQUEL( SenPeer Query
Exchange Language). Elle est ensuite envoyée à son parrain super-pair. En accord avec les infor-
mations que le pair initiateur de la requête avait envoyé au super-pair en intégrant la communauté, le parrain extraie le sujet de la requête. Le sujet de la requête est un résumé de la requête exprimé dans le même formalisme logique que les expertises détenues par le super-pair.
3. En s’aidant de la topologie sémantique formée lors de la phase de réconciliation sémantique, le parrain procède à un routage sémantique de la requête en se basant sur les (super-)pairs pertinents pour la requête. La capacité des pairs à prendre en charge une requête est évaluée en comparant le sujet de la requête avec l’ensemble des expertises des voisins sémantiques stockées dans les tables d’expertises intra et inter-communautés. Cette étape produit une requête sémantique annotée avec l’ensemble des pairs ou super-pairs pouvant la prendre en charge.
4. Chaque sous requête est réécrite du vocabulaire du pair initiateur de la requête vers ceux des (super-)pairs devant contribuer à la réponse finale. Ceci est fait par le biais d’un algorithme de reformulation de requête tenant en compte les matrices de correspondance MSP/SP et MSP/P. 5. La requête annotée est ensuite passée au générateur de plan qui a la charge de créer un plan de
requête distribuée qui va superviser l’exécution de la requête distribuée en tenant compte de la dis- tribution des (super-)pairs contribuant à la requête. Ce plan est ensuite optimisé en tenant compte des coûts de transmission des données entre les nœuds contribuant à la requête mais aussi le coût traitement de chaque opérateur. Les sous-plans locaux à la communauté sont ensuite instanciés et distribués aux pairs concernés tandis que ceux concernant les communautés distantes sont envoyés vers les parrains de ces communautés qui vont ensuite continuer le routage et l’optimisation au sein de leurs communautés respectives.
6. Les résultats de chacun de ces sous-plans sont ensuite fusionnés puis renvoyés au pair ayant initié la requête.
4.2.2 Sémantique de l’interrogation
Nous pouvons formaliser la sémantique des requêtes comme suit. Supposons un PDMS P = (G, M). Une requête Q est initiée par un pair Pi dans une communauté sémantique Cj et sur son propre schéma
Si. Les réponses attendues ne sont pas seulement des données Q(D) incluses dans l’instance I(Si) du schéma Si, mais aussi les données des pairs distants appartenant à la même communauté ou dans
les communautés alliées. Pour interroger les pairs distants, la requête est envoyée au parrain super-pair de la communauté sémantique Cj qui va ensuite décomposer la requête en un ensemble de requêtes
{Q(1), . . . , Q(p)}(p < |SP∪P|) où chaque requête Q(k)est définie sur le schéma Skd’un pair prometteur
pour la requête ou sur le schéma suggéré SSkdu parrain d’une communauté sémantique alliée. Le parrain
fait suivre la requête aux (super-)pairs via une reformulation sémantique guidée par les correspondances sémantiques M. Dans ce cas, la réponse à la requête est l’ensemble {Q(1)(Di1), . . . , Q(p)(Dip)} avec Q(k)(Dik) un sous ensemble des données I(Sk) du pair Pk ou un sous ensemble des données fournies
par les pairs de la communauté Ck.
4.2.3 Format d’échange de requêtes SQUEL
Quand un pair formule une requête avec son langage d’interrogation (SQL, XQuery, etc.) celle-ci est d’abord exécutée localement puis réécrite dans le formalisme d’échange de requêtes SQUEL(SenPeer
Query Exchange Language) et enfin envoyée à son super-pair pour pouvoir interroger les pairs distants
sans connaître leur langage d’interrogation mais aussi pour éviter les multiples réécritures entre langages de requêtes différents. Une requête SQUEL est un arbre constitué de deux sous-arbres : sous arbre- condition et sous-arbre résultat. De plus, pour faciliter la découverte des pairs pertinents pour la requête nous associons à chaque nœud racine, attribut ou sous-requête l’ensemble des synonymes du nœud cor- respondant sémantiquement dans le sGraph du pair initiateur de la requête. Il est important de noter que tout nœud attribut, racine ou sous-requête mentionné dans une requête SQUEL doit être défini dans le
sGraph associé.
Si par exemple le pair SAED de la figure 3.12 exprime la requête SQL suivante : SELECT nom_sol,taux_sel,humidite
FROM culture,sol
WHERE culture.nom_sol=sol.nom AND nomC=’riz’
La requête enrichie exprimée en SQUEL sera alors celle représentée par la figure 6.
La définition de la classe représentant un nœud d’une requête SQUEL est donnée dans la Table 4.1. Les requêtes SQUEL échangées à travers le réseau sont représentées sous forme de messages XML (voir annexes).
4.2.4 Navigation dans un graphe de requête SQUEL
Dans le but de naviguer dans un graphe de requête SQUEL, nous définissons un ensemble d’opéra- tions qui nous permettent d’identifier les concepts représentant les nœuds importants pour la reformula- tion des requêtes. Nous introduisons d’abord les notations suivantes :
• N ode(c) est le nœud étiqueté par le concept c ; • Child(n) dénote un fils du nœud n ;
• P arent(n) représente un nœud parent de n .
Figure 4.2 – Une requête SQL et la requête SQUEL correspondante.
< QN ode > ::= class {
name :< word >
synonym : {}|{< syn − set >} type :< typeN ode >
constraint :< constraint > return :< return >
operand :< operand >}
< syn − set >::=< word > | < word >, < synset >
< typeN ode >::= {} |root | subQuery | operator | f unction |attribute | literal < result >::= {} | {< QN ode >}
< constraint >::= {} | {< QN ode >} < operand >::= {} | {< QN ode >}
Table 4.1 – Définition de la classe représentant un nœud du format d’échange de requêtes.
• inComing
n2 ∈ inComing(n1, r) ssi n2= P arent(n1) ∧ (n2, n1) = r. (4.1)
De façon informelle, cette relation retourne les nœuds parents d’un nœud n en suivant un arc de type r
• outGoing
n2 ∈ outGoing(n1, r) ssi n2 = Child(n1) ∧ (n1, n2) = r. (4.2)
Cette relation retourne les nœuds fils d’un nœud n en suivant un arc de type r A partir de ces opérations de navigation, nous définissons les prédicats suivants :
T ype(n1, n2) =
vrai Si outGoing(n1, "typeOf") = n2∧
n1 ∈ inComing(n2, "typeOf") f aux Sinon