Méthodes de traitement des requêtes RDL à résultats partiels

Dans le deuxième chapitre, nous avons justifié l’intérêt d’exprimer et de traiter des requêtes à résultats partiels. A l’aide du langage LDQL, le client mobile peut formuler des conditions liées aux résultats partiels. En fait, ces conditions guident les méthodes proposées dans la construction du résultat partiel. Nous distinguons deux types de conditions sur la cardinalité des résultats partiels d’une requête RDL : (i) préciser un nombre ou un pourcentage maximum d’objets cibles à ne pas dépasser et (ii) préciser un nombre ou un pourcentage minimum d’objets cibles attendu.

La prise en compte de ces deux types de conditions nécessite d’utiliser des méthodes différentes. D’abord, nous nous intéressons au premier type de conditions sur les résultats partiels. Un scénario où l’utilisateur formule une requête impliquant une condition sur le nombre maximum d’objets cibles est celui d’un pompier qui envoie la requête Q12

« Sélectionner les bouches d’incendie que je peux atteindre en 5 minutes, moins que 10 bouches d’incendie doivent être retournées ». La requête Q12 s’exprime à l’aide du langage LDQL de la manière suivante :

SELECT name, address FROM hospital

WHERE REACHABLE WITHIN(hospital,10mn) PARTIAL RESULT AT MAX(10);

Généralement, l’utilisateur est amené à préciser ce type de conditions lorsqu’il veut éviter d’obtenir un grand nombre de résultats et lorsqu’il sait que le nombre (ou le pourcentage) d’objets maximum précisé dans la requête serait satisfaisant. Il s’agit, en fait, d’arrêter le traitement lorsque la cardinalité du résultat atteint le nombre (ou le pourcentage) maximum précisé dans la requête. La prise en compte de cette condition est relativement simple comparée au deuxième type de conditions surtout si c’est le nombre d’objets cibles maximum (et non le pourcentage) qui est précisé. En effet, les SGBD existants fournissent des clauses à ajouter aux requêtes SQL permettant de ne renvoyer que les n premiers tuples trouvés. Par exemple, sous Oracle, la clause rownum<n peut être utilisée à cet effet. Cette clause peut être ajoutée lors de la réécriture de la requête. La fonction Get_Spatial_Query prend, en plus des paramètres d’entrées indiqués dans la sous-section 2.4, le nombre ou le pourcentage maximum d’objets cibles attendu. La requête Q12 devient, après transformation, la requête

Q12’ :

SELECT name, address, LocHosp FROM hospital

WHERE SDO_INSIDE(LocHosp,Q_SCOPE) and rownum<10;

Bien que la clause rownum ne fasse pas partie du standard SQL, la majorité des SGBD existants fournissent des clauses équivalentes (e.g. la clause Fetch first n rows only peut être utilisée sous DB2). Toutefois, ces clauses ne permettent pas de préciser un pourcentage maximum de résultats (e.g au maximum 50% des résultats). Dans ce cas, il est nécessaire de calculer le nombre d’objets cibles correspondant à ce pourcentage avant de réécrire la requête en ajoutant la clause rownum. Pour résoudre ce problème, nous proposons de nous appuyer sur une estimation de la cardinalité du résultat complet. Cette estimation peut être calculée par l’évaluateur de coût du SGBD (cf. chapitre IV). Ainsi, la requête est d’abord réécrite en ne tenant pas compte des conditions liées aux résultats partiels. Nous utilisons le module

Estimation Coûts pour déterminer une estimation de la cardinalité des résultats. Rappelons que

ce module soumet la requête au SGBD pour qu’elle soit optimisée afin d’obtenir un plan d’exécution annoté par ses coûts. Le nombre d’objets maximum peut alors être calculé. La requête est ensuite réécrite en ajoutant la clause rownum.

Function Get_Max_Object_Number

Input : listAttributs, targetObjects, Spatial_op, percentage Output: Card

Begin

1: Qcomp:= Get_Spatial_Query(listAttributs,targetObjects, Spatial_op) ; 2: Estimate_Query_Cost(Q,ETtratBD,EDs)

3: card := (percentage * EDs)/100; 4: return Card;

End Get_Max_Object_Number

Figure 26 : Fonction de détermination du nombre maximum d’objets cibles attendus

Nous nous intéressons, à présent, au deuxième type de conditions sur la cardinalité des résultats partiels (i.e. l’utilisateur précise un nombre ou un pourcentage minimum d’objets cibles acceptés). La prise en compte de ce type de conditions lors du traitement des requêtes est plus complexe. En fait, dans ce cas, le but n’est pas de limiter le nombre d’objets cibles à un maximum à ne pas dépasser, mais d’envoyer le plus de résultats possibles (au-dessus d’un certain nombre minimum précisé) tout en respectant la contrainte de temps réel. Nous proposons deux méthodes différentes pour tenir compte de ces conditions.

Selon la première méthode, le SGBD retourne un résultat complet suite à l’évaluation de la requête spatiale et c’est au moment de la vérification du respect de l’échéance, avant le transfert des résultats, qu’une décision est prise concernant le nombre d’objets cibles à envoyer au client. Puisque la requête évaluée par le SGBD sous-jacent retourne un résultat complet, les procédures et les fonctions du module Transformations ne changent pas. Ce qui n’est pas le cas du sous-module Vérification de la validité temporelle où des procédures sont ajoutées, afin de calculer le nombre d’objets cibles à transmettre en fonction du temps restant par rapport à l’échéance. Ainsi, cette partie sera détaillée lorsque nous aborderons la prise en compte des contraintes de temps réel dans le chapitre VI. Notons, néanmoins, que l’inconvénient de cette méthode est qu’aucun résultat partiel ne peut être délivré au client mobile avant la fin de l’exécution de la requête par le SGBD sous-jacent. Si les résultats complets de la requête sont passés au module Vérification de la validité temporelle après expiration de l’échéance, aucun résultat partiel ne sera transmis au client.

Ainsi, nous proposons une deuxième méthode qui prend en compte les conditions sur les résultats partiels avant l’évaluation de la requête par le SGBD. Cette méthode vise à délivrer au client mobile une première portion des résultats le plus tôt possible, sans avoir à attendre la fin de l’exécution de la requête par le SGBD sous-jacent pour commencer à envoyer des données. Le principe est le suivant : au lieu de soumettre au SGBD une requête spatiale retournant un résultat complet (ayant éventuellement un temps de réponse élevé), plusieurs requêtes ayant des temps de réponses plus courts et retournant chacune une partie des résultats sont soumises selon un ordre précis au SGBD.

Pour les requêtes de zone, l’idée est de décomposer la surface de sélection (q_scope) en plusieurs sous-surfaces disjointes (qi) afin d’obtenir un ensemble de requêtes spatiales

(sub_queryi) dont les temps de réponse sont plus courts que celui de la requête initiale (Q).

L’évaluation de chacune de ces requêtes permet d’obtenir une partie des résultats. Pour obtenir ces requêtes, il faut adapter la procédure Spatial_Op_Deriv présentée dans la sous- section 3.3. La procédure Partial_Spatial_Op_Derive prend les mêmes entrées que la procédure

Spatial_Op_Deriv et retourne les opérateurs spatiaux permettant d’écrire les requêtes sub_queryi. Pour simplifier notre explication, nous ne montrons qu’une partie de l’algorithme qui concerne la transformation de l’opérateur Close to Distance.

Procedure Part_Spatial_Op_Deriv

Input : proxim, Orientation, Loc_Client, idCl, Nbpart Output: Spatial_op, OrientCond

Begin

1: if proxim.op=”close to distance” then r:= proxim.query_dist; 2: q_Scope:= Determine_Query_Scope(Loc_Client,r,Orientation,idCl) 3: List_part_scope := Decompose_Scope(q_scope) ;

4: List_part_scope := Order_List_part_scope(List_part_scope,LocClient,dir) ; 5: For each part_scope in List_part_Scope

6: Spatial_op := Derive_Zone_Operator(part_scope,LocObj); 7: return Spatial_op

8: end for;

9: return List_Spatial_Op; End Part_Spatial_Op_Deriv

Figure 27 : Procédure de dérivation d’opérateurs spatiaux pour les requêtes à résultats partiels

Après la détermination de la surface de sélection de la requête initiale (Q) (ligne 2 de l’algorithme de la Figure 27), celle-ci est décomposée en N sous-surfaces égales comme le montre la Figure 28. Le nombre de sous-surfaces dépend des dimensions fixées de ces sous- surfaces (e.g. dim sur la Figure 28). Nous supposons que ces dimensions sont paramétrées selon l’application (plus précisément selon la distribution des localisations des objets cibles dans l’espace). En fait, les sous-surfaces doivent contenir un nombre suffisant d’objets cibles et ne doivent pas être très grandes pour éviter des temps de réponses élevés des requêtes générées. Suite à la décomposition, une liste de ces sous-surfaces est obtenue. Pour chacune des sous-surfaces de la liste, un opérateur spatial de zone est dérivé et retourné afin de réécrire une requête spatiale délivrant un sous-ensemble de résultats.

La manière dont est ordonnée la liste des sous-surfaces est très importante pour la construction du résultat partiel. Rappelons que le but est d’atteindre le minimum d’objest cibles attendus le plus rapidement possible. L’ordre entre les sous-surfaces est établi selon les critères suivants (par ordre de priorité) :

(i) Les plus proches du client d’abord : la distance entre le centre de chaque sous- surface et la localisation du client est calculée. Puis, les sous-surfaces sont triées par ordre croissant de ces distances.

(ii) La direction du client : lorsque deux surfaces sont à distances égales de la localisation du client, celles qui se trouvent dans la même direction que le client sont favorisées.

(iii) L’intersection avec la surface de sélection de la requête initiale q_scope : En fait, certaines sous-surfaces peuvent contenir des résultats qui n’appartiennent pas aux résultats complets de la requête (Q). Ces derniers vont être éliminés lors de la vérification de la validité spatiale des résultats. Ainsi, les sous- surfaces ayant une intersection plus grande avec la surface de la requête (Q) ont plus de chances de contenir des résultats qui font partie des résultats complets et ne sont donc pas éliminés.

Par exemple l’ordre des sous-surfaces de sélection obtenu en considérant la décomposition illustrée par la Figure 28 est le suivant : {q7,q11,q10,q6,q3,q8,q12,q15, q14,q9,q5,q2,q4,q16,q13,q1}. q_scope q1 q2 q3 q4 q5 q6 q7 q8 q9 q11 q10 q12 q13 q14 q15 q16 dim

Figure 28 : Exemple de décomposition de la surface de sélection

5. Conclusion

Dans ce chapitre, nous avons décrit nos propositions pour tenir compte des problèmes liés à l’évaluation de plusieurs types de requêtes dépendant de la localisation. Conformément à l’architecture proposée dans le précédent chapitre, ces méthodes sont implantées dans des modules au-dessus des SGBD. Nous avons particulièrement détaillé le module Transformations et le sous-module Vérification de la Validité spatiale. Puis, nous nous sommes intéressés aux requêtes continues et nous avons proposé deux méthodes différentes pour les traiter. De même, nous avons présenté des méthodes spécifiques au traitement des requêtes à résultats partiels. Cependant, dans ce chapitre, nous n’avons pas abordé les problèmes liés à la prise en compte des contraintes de temps réel. Cet aspect fait l’objet du chapitre suivant.