Traitement des requêtes dépendant de la localisation avec des contraintes de temps réel

UNIVERSITE TOULOUSE III - PAUL SABATIER U.F.R MIG, Laboratoire IRIT

THESE

en vue de l’obtention du

DOCTORAT DE L’UNIVERSITE DE TOULOUSE délivré par l’Université Toulouse III – Paul Sabatier

Discipline : Informatique présentée et soutenue par Nadhem Marsit le 14 Décembre 2007 Titre :

Traitement des requêtes dépendant de la localisation avec des

contraintes de temps réel

JURY

Claude CHRISMENT Professeur à l’Université Paul Sabatier (Président) Thierry DELTHEIL Ingénieur à Silogic

Abdelkader HAMEURLAIN Professeur à l’Université Paul Sabatier (Directeur de thèse) Francine KRIEF Professeur à l’ENSEIRB de Bordeaux

Sylvain LECOMTE Professeur à Université de Valenciennes (Rapporteur) Zoubir MAMMERI Professeur à l’Université Paul Sabatier (Codirecteur de thèse) Franck MORVAN Maître de Conférences – HDR à l’Université Paul Sabatier

Résumé

La mobilité des unités a connu un fort essor depuis quelques années. Les progrès réalisés dans les technologies des réseaux sans fil ajoutés au développement des systèmes de localisation ont contribué à l’émergence d’un grand nombre de services et d’applications basés sur la localisation. Une des conséquences directes dans le domaine des bases de données est l’apparition de nouveaux types de requêtes tels que les Requêtes Dépendant de la Localisation (RDL). Ces requêtes soulèvent des problèmes qui font depuis quelques années l’objet de plusieurs recherches. En dépit de l’abondance des travaux liés à ce domaine, les différents types de requêtes étudiés jusqu’ici ne répondent pas à tous les besoins applicatifs. En effet, des nouveaux besoins donnent naissance à des requêtes mobiles avec des contraintes de temps réel. Par exemple, un ambulancier demande de sélectionner les hôpitaux situés à moins de 5 km de sa position et précise que le résultat doit être délivré dans un délai maximum d’une minute. La prise en compte à la fois des contraintes de temps réel et de mobilité lors du traitement des requêtes est un problème important à résoudre.

Ainsi, notre principal objectif dans cette thèse est de proposer une solution pour le traitement des requêtes dépendant de la localisation avec des contraintes de temps réel. D’abord, nous classifions les différents types de requêtes mobiles et nous présentons une synthèse des principales solutions proposées pour résoudre leurs problèmes sous-jacents. Nous proposons ensuite un langage permettant d’exprimer les requêtes classifiées. D’un autre côté, nous concevons une architecture permettant de traiter des requêtes RDL avec des contraintes de temps réel. Les modules conçus sont destinés à être implantés au-dessus de SGBD existants (e.g. Oracle). Dans le cadre de cette architecture, nous proposons des méthodes permettant de tenir compte de la localisation du client et de son déplacement après l’envoi de la requête. Nous proposons aussi des méthodes permettant de maximiser le taux de requêtes respectant leurs échéances. Enfin, nous validons nos propositions par une mise en œuvre et des évaluations des performances des méthodes proposées.

Mots–clés : Bases de données, mobilité des unités, traitement des requêtes dépendant

À ma mère Leïla, mon père Habib et ma soeur Souhir pour leur patience, leur soutien indéfectible

Remerciements

Je tiens tout d'abord à remercier Monsieur Luis Fariñas del Cerro, Directeur de l'Institut de Recherche en Informatique de Toulouse IRIT, pour m'avoir accueilli au sein de son laboratoire.

J’adresse également mes sincères remerciements à Monsieur le Professeur Sylvain Lecomte et Monsieur Bruno Sadeg, Maître de Conférences habilité à diriger les recherches pour l’intérêt qu’ils ont porté à mon travail en acceptant d'être les rapporteurs de ma thèse. Je tiens aussi à remercier Madame le Professeur Francine Krief, Monsieur le Professeur Claude Chrisment et Monsieur Thierry Deltheil, membres du jury, pour le travail et le temps consacrés à l’examen de ma thèse.

Toute ma gratitude s’adresse à Monsieur le Professeur Abdelkader Hameurlain, mon directeur de thèse qui m’a patiemment formé à la recherche. Il m’a apporté bien plus qu’un encadrement scientifique. Je le remercie pour sa disponibilité, ses précieux conseils et ses encouragements qui m’ont toujours poussé à m’améliorer. Toute ma reconnaissance va aussi à Monsieur le Professeur Zoubir Mammeri mon codirecteur de thèse. Ses critiques constructives, ses suggestions, ses avis et ses conseils se sont avérés d’une valeur inestimable et m’ont permis d’améliorer considérablement mon travail. Un grand merci à Monsieur Franck Morvan, Maître de Conférences habilité à diriger les recherches, qui a encadré et suivi de près mes travaux. Ses remarques, son soutien et ses encouragements ont été d’un précieux apport et m’ont beaucoup aidé dans mes investigations.

Je tiens également à remercier vivement, tous les membres de l’équipe PYRAMIDE, pour la bonne humeur et l’ambiance formidable qu’ils font régner au sein de l’équipe : Christelle, Mahmoud, Raddad et Riad. Sans oublier Belgin et Mohammad avec qui des liens d’amitié sincère se sont tissés malgré les distances.

Je ne remercierai jamais assez mes amis de l’IRIT qui sont devenus ma seconde famille. Merci à Sandrine et Nico pour tant de complicité et de moments partagés, Cecile et Guillaume pour leur amitié sincère, Chantal, Lucila, Bernard et Colin pour leur gentillesse et leur spontanéité. Un grand merci également à Asma pour m’avoir soutenu pendant les moments de doutes, ainsi que les amis de toujours Mehdi et Olfa. Je n’oublie pas non plus Eli, Farida, Ilhem et Syrine pour m’avoir écouté et trouvé les mots pour m’encourager.

Mes sentiments les plus sincères vont à Nathalie Valles et Alain Berro pour leur confiance qui m’a permis d’enrichir considérablement mon expérience en enseignement.

Je tiens à remercier tout le personnel de l’IRIT qui m’ont permis de mener mes travaux dans de bonnes conditions.

J’adresse un merci tout spécial à tous mes amis de Toulouse, qui ont rendu mon séjour dans cette ville très agréable. Chacun à sa manière m’a soutenu pendant les moments difficiles. Merci Haithem et Gatoussa qui ont eu l’amabilité de corriger les coquilles du manuscrit.

Une pensée toute spéciale va aux membres de ma famille pour leurs encouragements durant mes longues études. Ma mère pour avoir relu mon manuscrit, corrigé mes fautes et pour m’avoir donné tant d’amour. Mon père pour avoir suscité en moi l’envie de faire de la recherche et su me donner confiance en moi. Ma sœur pour m’avoir toujours dit « tu finiras bien par l’avoir cette thèse ! », sans oublier ma tante Faouzia et mes cousins Amin et Yazide.

Table des matières

Chapitre I Introduction ... 17

1. Contexte ... 17

2. Problématique et objectif ... 18

3. Contenu de la thèse et contribution... 19

4. Organisation du document ... 20

Chapitre II Traitement des requêtes en environnements mobiles : état de l’art... 22

1. Introduction ... 22

2. Classification des requêtes ... 23

2.1. Critères de classification ... 23

2.2. Requêtes mobiles non spatiales... 25

2.3. Requêtes spatiales ... 25

2.4. Requêtes dépendant de la localisation... 26

2.5. Requêtes relatives à des objets mobiles ... 26

2.6. Requêtes spatio-temporelles... 27

2.7. Requêtes continues ... 27

2.8. Récapitulatif des types de requêtes classifiés et discussion ... 28

3. Traitement des requêtes spatiales... 29

3.1. Modèles de données spatiales ... 29

3.1.1. Types abstraits de données ... 30

3.1.2. Modèle de données contraintes ... 31

3.2. Indexation et évaluation des requêtes spatiales... 32

3.2.1. Index spatiaux ... 32

3.2.2. Evaluation des requêtes de zone et K-NN ... 33

4. Traitement des requêtes dépendant de la localisation ... 34

4.1. Expression des requêtes RDL ... 35

4.2. Prise en compte de la localisation du client ... 36

4.2.1. Modèle de localisation ... 36

4.2.2. Incorporation de la localisation du client à la requête RDL... 36

4.2.3. Prise en compte des conditions de proximité et d’orientation ... 37

4.3. Validité des résultats d’une requête RDL ... 38

5. Traitement de requêtes relatives à des objets mobiles ... 40

5.1. Modélisation des objets mobiles ... 40

5.1.1. Les types abstraits de données spatio-temporelles ... 41

5.1.2. Application du modèle de données contraintes aux données spatio- temporelles ... 42

5.1.3. Modèle basé sur les attributs dynamiques... 43

5.2. Mise à jour de la localisation et incertitude... 44

5.2.1. Mise à jour de la localisation des objets mobiles ... 44

5.2.2. Interrogation des données avec incertitude ... 45

6. Autres formes de requêtes... 45

Chapitre III Langage d’expression des requêtes dépendant de la localisation ... 49

1. Introduction ... 49

2. Types de requêtes RDL... 50

3. Différentes parties d’une requête RDL ... 51

4. Expression des conditions de dépendance par rapport à la localisation... 52

4.1. Conditions de proximité ... 53

4.2. Conditions d’orientations ... 54

4.3. Conditions sur la localisation du client ... 55

5. Expression des contraintes temporelles ... 55

6. Expression des requêtes à résultats partiels ... 56

7. Conclusion... 57

Chapitre IV Architecture logicielle pour traiter des requêtes dépendant de la localisation avec des contraintes de temps réel... 59

1. Introduction ... 59

2. Contexte de travail et principes de l’architecture... 60

2.1. Contexte ... 60

2.2. Contraintes à prendre en compte ... 60

2.2.1. Contraintes de temps réel ... 60

2.2.2. Contraintes liées aux spécificités des requêtes RDL... 61

2.3. Choix du SGBD sous-jacent ... 62

2.3.1. Utilisation d’un SGBD Temps Réel... 62

2.3.2. Utilisation d’un SGBD existant... 63

3. Description de l’architecture logicielle ... 63

3.1. Vue générale de l’architecture... 63

3.2. Rôle du SGBD... 65

3.3. Gestion de la dépendance des résultats par rapport à la localisation du client... 66

3.4. Interrogation de données relatives à des objets mobiles ... 68

3.5. Gestion des contraintes de temps réel ... 68

3.6. Vérification de la validité spatiale et temporelle des résultats ... 70

4. Etapes de traitement des requêtes dépendant de la localisation ... 71

4.1. Requêtes RDL avec des contraintes de temps réel... 72

4.2. Requêtes RDL continues ... 73

4.3. Requêtes RDL à résultats partiels avec des contraintes de temps réel... 75

5. Conclusion... 77

Chapitre V Traitement des requêtes dépendant de la localisation ... 79

1. Introduction ... 79

2. Méthodes de traitement des requêtes RDL ... 79

2.1. Détermination des contraintes de la requête et de son type ... 80

2.1.1. Détermination des contraintes de la requête ... 80

2.1.2. Détermination du type de la requête ... 81

2.2. Détermination de la localisation du client... 82

2.3. Dérivation de prédicats spatiaux ... 84

2.3.1. Recherche d’objets cibles dans une zone ... 85

2.3.2. Recherche des plus proches voisins ... 87

2.5. Vérification de la validité spatiale des résultats ... 90

3. Méthodes de traitement des requêtes RDL continues ... 91

3.1. Problème de l’évaluation des requêtes RDL continues... 91

3.2. Méthode basée sur une réévaluation périodique de la requête... 91

3.3. Méthode basée sur le calcul de tous les résultats potentiellement corrects... 94

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

5. Conclusion... 99

Chapitre VI Prise en compte des contraintes de temps réel lors du traitement des requêtes ... 100

1. Introduction ... 100

2. Détermination de l’échéance... 101

2.1. Echéances déterminées en fonction d’un facteur temps précisé dans la requête ... 101

2.2. Echéances déterminées en fonction de la validité spatiale des résultats ... 103

3. Traitement de requêtes avec des contraintes de temps réel... 104

3.1. Calcul des estimations ... 104

3.1.1. Estimation des temps de traitement de la requête par le SGBD sous-jacent.. 105

3.1.2. Estimation du temps de transfert ... 106

3.2. Test d’admission et ordonnancement temps réel ... 106

3.3. Election des requêtes ... 108

3.4. Vérification de la validité temporelle avant le transfert des résultats ... 109

4. Evaluation des performances de l’ordonnancement des requêtes et des tests d’admission ... 111

4.1. Modèle de Simulation ... 111

4.1.1. Génération des requêtes ... 111

4.1.2. Calcul des estimations ... 112

4.1.3. Méthodes simulées ... 112

4.2. Analyse des résultats ... 113

4.2.1. Pourcentage de requêtes ratant leurs échéances ... 113

4.2.2. Données transmises sur le réseau ... 115

4.2.3. Impact des erreurs d’estimation sur les décisions prises au niveau des tests d’admission ... 118

5. Conclusion... 119

Chapitre VII Mise en œuvre et validation... 121

1. Introduction ... 121

2. Environnement et prototype d’expérimentation... 122

2.1. Limites et avantages de l’utilisation d’Oracle dans notre contexte... 122

2.2. Architecture du prototype... 124

2.3. Exemple de requêtes expérimentées ... 126

2.3.1. Exemples de requêtes RDL ... 127

2.3.2. Exemple d’une requête RDL continue ... 130

2.3.3. Exemples de requêtes RDL à résultats partiels avec des contraintes de temps réel ... 132

3. Evaluation des performances des requêtes RDL... 134

3.1. Requêtes étudiées et données interrogées ... 135

3.2. Apport de la vérification de la validité spatiale... 136

3.2.2. Surcoût de la méthode de vérification de la validité spatiale ... 138

3.2.3. Réduction des coûts de communication ... 139

3.3. Apport du module gestion des contraintes temps réel... 140

3.3.1. Pourcentage de requêtes ratant leurs échéances ... 140

3.3.2. Pourcentage de résultats incorrects ... 142

4. Conclusion... 143

Chapitre VIII Conclusion et perspectives... 145

1. Synthèse et bilan ... 145

2. Perspectives... 147

2.1. Extension des méthodes de prise en compte des contraintes de temps réel ... 147

2.2. Extension des méthodes de prise en compte des contraintes liées à la mobilité .... 149

Références ... 151

Glossaire ... 163

Annexe A ... 164

Liste des Figures

Figure 1 : Critères de classification et types de requêtes mobiles obtenus selon ces critères .. 24

Figure 2 : Un exemple d’arbre R... 32

Figure 3 : Exemple illustrant la recherche du plus proche voisin selon l’algorithme par séparation et évaluation [RKV 95]... 33

Figure 4 : Exemple illustrant la recherche des plus proches voisins selon l’algorithme meilleur d’abord [HS 99]... 34

Figure 5 : Diagramme de Voronoi ... 39

Figure 6 : Architecture matérielle ... 60

Figure 7 : Architecture pour traiter des requêtes RDL avec des contraintes de temps réel ... 64

Figure 8 : Principales composantes du module Transformations ... 66

Figure 9 : Principales composantes du module Gestion des Contraintes de Temps Réel... 69

Figure 10 : Composantes du module Vérification et Transfert des Résultats ... 71

Figure 11 : Etapes de traitement d’une requête RDL avec des contraintes de temps réel ... 73

Figure 12 : Etapes de traitement d’une requête RDL continue lorsqu’une solution basée sur une réévaluation périodique est adoptée ... 74

Figure 13 : Etapes de traitement d’une requête RDL continue lorsqu’une solution basée sur la détermination de tous les résultats potentiellement corrects est adoptée ... 75

Figure 14 : Etapes de traitement d’une requête RDL à résultats partiels avec des contraintes de temps réel selon une solution par décomposition de la surface de sélection. ... 77

Figure 15 : Fonction de détermination du type de la requête... 81

Figure 16 : Fonction de détermination de la localisation du client avant l’évaluation de la requête ... 83

Figure 17 : Procédure de dérivation de prédicats spatiaux en fonction des opérateurs de proximité et d’orientation... 85

Figure 18 : Forme de la surface de sélection selon les conditions d’orientation ... 86

Figure 19 : Fonction de détermination de la surface de sélection des requêtes de zone ... 87

Figure 20 : Exemple de prise en compte des conditions d’orientation ... 88

Figure 21 : Fonction de vérification de la validité spatiale des résultats par rapport à la localisation du client avant le transfert... 90

Figure 22 : Procédure de détermination des résultats de requêtes continues à transmettre au client ... 93

Figure 23 : Illustration de surfaces de sélection déterminées au cours de deux transformations successives ... 93

Figure 24 : Procédure de détermination de la surface de sélection pour des requêtes continues... 94

Figure 25 : Zone de résultats potentiellement corrects ... 95

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

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

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

Figure 29 : Fonction de détermination de l’échéance ... 102

Figure 30 : Illustration d’un cas où tous les objets cibles retournés sont incorrects à cause du déplacement du client entre l’envoi et la réception des résultats. ... 103

Figure 31 : Procédure combinant un test d’admission et un algorithme d’ordonnancement

pour la prise en compte des contraintes de temps réel ... 107

Figure 32 : Fonction de détermination des résultats partiels à transmettre ... 110

Figure 33 : Pourcentage de requêtes ratant leurs échéances ... 114

Figure 34 : Nombre moyen de requêtes soumises simultanément au SGBD sous-jacent... 115

Figure 35 : Réduction des coûts de communication par chacun des tests d’admission ... 116

Figure 36 : Pourcentage de données transmises inutilement... 117

Figure 37 : Pourcentage de données délivrées avant expiration de l’échéance ... 117

Figure 38 : Pourcentage de requêtes acceptées à tort à cause de la sous-estimation du temps de traitement de la requête par le SGBD... 118

Figure 39 : Pourcentage de requêtes rejetées à tort à cause de la surestimation du temps de traitement par le SGBD. ... 119

Figure 40 : Exemple de plan d’exécution... 123

Figure 41 : Architecture du prototype ... 124

Figure 42 : Résultats d’une requête RDL de Zone... 128

Figure 43 : Résultats d’une requête RDL de zone avec condition d’orientation ... 128

Figure 44 : Résultats d’une requête RDL de recherche des plus proches voisins... 129

Figure 45 : Résultats de la recherche des objets cibles en fonction du temps mis pour les atteindre. ... 130

Figure 46 : Résultats d’une requête RDL continue reçus à deux instants différents ... 131

Figure 47 : Résultats d’une requête RDL à résultats partiels avec un délai critique égal à 4 secondes ... 133

Figure 48 : Résultats d’une requête RDL à résultats partiels avec un délai critique égal à 3 secondes ... 134

Figure 49 : Requêtes étudiées... 135

Figure 50 : Pourcentage de résultats incorrects... 137

Figure 51 : Temps de vérification de la validité spatiale en fonction de la taille de la surface de sélection. ... 138

Figure 52 : Réduction des coûts de communication ... 139

Figure 53 : Pourcentages de requêtes ratant leurs échéances avec et sans le module Gestion des Contraintes de Temps Réel (GCTR) (expérimentation et simulation) ... 141

Figure 54 : Pourcentage de résultats incorrects avec et sans utilisation du module Gestion des Contraintes de Temps Réel (GCTR). ... 142

Liste des Tableaux

Tableau 1 : Récapitulatif des types de requêtes mobiles... 28 Tableau 2 : Paramètres de simulation ... 113 Tableau 3 : Taille des relations opérandes et densité des objets cibles représentés... 135

Chapitre I

Introduction

1. Contexte

Depuis le début des années 1990, la mobilité des unités1 connaît un succès croissant. Grâce aux progrès technologiques réalisés dans ce domaine, les terminaux mobiles sont devenus beaucoup plus performants et accessibles au grand public. De même, nous assistons à une importante évolution des réseaux sans fil. Les débits sont de plus en plus élevés et la surface couverte est plus large. Au départ, l’objectif principal des réseaux sans fil était de permettre aux différents terminaux mobiles de communiquer entre eux. Aujourd’hui, ces réseaux sont le support d’une variété de nouveaux services et de nouvelles applications. En effet, ces avancées technologiques considérables ajoutées au développement des systèmes de localisation tel que GPS (Global Positioning System) ont contribué à l’émergence d’un grand nombre de services et d’applications basés sur la localisation. Par exemple, un utilisateur mobile peut consulter des informations relatives à sa localisation, comme le restaurant le plus proche ou la météo locale. Ces applications sont en passe de devenir l’un des enjeux économiques majeurs des années à venir. Une étude parue dans [Abi 06] prévoit que le marché des applications basées sur la localisation aurait un taux de croissance annuel de 52% pour les quatre années à venir. Selon les estimations de l’agence spatiale européenne (ESA), le système européen de navigation par satellite Galiléo pourrait générer 9 milliards d’euros par an de contrats de services et d’équipements [Cne 07]. Ainsi, les applications basées sur la localisation ont engendré un engouement considérable dans le milieu scientifique et industriel. Comme tout progrès technologique est accompagné de nouveaux défis, les applications basées sur la localisation ont généré de nouveaux problèmes auxquels ont été consacrées plusieurs recherches. Une des conséquences directes dans le domaine des bases de données est l’apparition de nouveaux types de requêtes. En environnements mobiles, nous distinguons deux catégories de requêtes (i.e. requêtes mobiles) [MHM+ 06a] : (i) les requêtes issues de terminaux mobiles invoquant des données relatives à des objets fixes (e.g. hôpitaux), et (ii) les requêtes issues de terminaux fixes ou mobiles invoquant des données relatives à des objets mobiles (e.g. ambulances). Dans ces deux catégories, plusieurs types de requêtes peuvent encore être distingués selon certains critères, comme la dépendance des résultats par rapport à la localisation (e.g. sélectionner l’hôpital le plus proche) ou l’association de la dimension spatiale à la dimension temporelle (e.g. sélectionner les ambulances disponibles pouvant atteindre le lieu d’intervention en moins de 10 minutes). Ces requêtes ont des spécificités et des contraintes différentes et soulèvent des problèmes variés qui ont suscité l’intérêt d’une part importante de la communauté bases de données [SWC+ 97, PS 01, GBE+ 00, SDK 01a, JT 04, ZLL 04, IMI 06].

1

La mobilité peut être logicielle ou physique. La première concerne la mobilité du code et la deuxième celle des unités (téléphones portables, palm pilot, ordinateurs portables, véhicules …). Dans cette thèse nous ne nous intéressons qu’à la mobilité des unités.

Dans le cadre de cette thèse, nous nous intéressons au traitement des requêtes mobiles. La plupart des exemples cités dans ce document sont liés au domaine des urgences médicales. C’est dans ce contexte que nous avons participé au projet Géo Urgence [Geo 07] qui rassemble deux entreprises (SILOGIC [Sil 07] et NOVACOM [NOV 07]), une institution du domaine des urgences (SAMU des hôpitaux de Toulouse [Sam 07]) et les deux équipes PYRAMIDE et ASTRE du laboratoire IRIT [Iri 07]. Ce projet génère le besoin d’étudier plusieurs types de requêtes mobiles. En effet, le projet Géo Urgence vise à fournir aux médecins régulateurs2 du SAMU un outil permettant d’optimiser la supervision en temps réel des unités mobiles hospitalières (véhicules hospitaliers, ambulances, hélicoptères). Cet outil permet la simulation de scénarii d’intervention en tenant compte, entre autres, des localisations des unités mobiles, des données relatives aux centres hospitaliers (e.g. disponibilité des lits) et des paramètres « contraintes » géolocalisés concernant les conditions de déplacement (trafic, coupures de routes). Actuellement, un prototype est en cours de développement.

2. Problématique et objectif

Les recherches liées au traitement des requêtes en environnements mobiles ont principalement étudié deux classes de problèmes. Premièrement, plusieurs solutions ont été proposées pour résoudre les problèmes relatifs au traitement des requêtes dépendant de la localisation (RDL) (i.e. requête dont les résultats dépendent de la localisation du client mobile la soumettant) [SDK 01a, ZZP+ 03, ZLL 04, TD 04, JT 04, TDL 05, IMI 06]. Un exemple de ce type de requêtes est celui d’un ambulancier qui interroge une base de données pour sélectionner les hôpitaux qui se trouvent à moins de 5 km de sa position. Deuxièmement, de nombreux travaux se sont focalisés sur les problèmes liés au traitement des requêtes issues de terminaux mobiles ou fixes et invoquant des données relatives à la localisation des objets mobiles [SWC+ 97, GBE+ 00, RSS+ 03, WY 03, TWH+ 04, TDS 05]. Par exemple, un gestionnaire de moyens mobiles3 soumet une requête pour sélectionner les ambulances situées à moins de 15 km du lieu d’intervention.

En dépit de l’abondance des travaux liés au traitement des requêtes en environnements mobiles, certains problèmes méritent davantage de recherches. En effet, les requêtes étudiées jusqu’ici ne répondent pas à tous les besoins applicatifs. Nous pensons particulièrement à l’aspect temps réel exigé par certaines applications basées sur la localisation. Ces nouveaux besoins donnent naissance à des requêtes mobiles avec des contraintes de temps réel. Ces contraintes se présentent souvent sous la forme d’échéances associées aux requêtes. Le besoin d’évaluer ce type de requêtes est crucial dans plusieurs domaines, comme la gestion de crise, le domaine militaire ou l’urgence médicale. Par exemple, un médecin utilise son assistant personnel (PDA) pour envoyer une requête mobile, afin de connaître l’adresse de l’établissement privé le plus proche de sa position et pouvant accueillir un patient en service pédiatrie et demande que le résultat lui soit délivré avant une échéance (D). Après cette échéance, le patient est envoyé à un établissement public. Ce type de requêtes (les requêtes mobiles avec des contraintes de temps réel) a été peu étudié dans la littérature. Pourtant, ce besoin est concret. En fait, bien que plusieurs travaux aient été consacrés au développement

2

Il s’agit d’un médecin du centre 15 qui, suite à un appel, décide de l’envoi et du mode d’intervention d’une unité mobile hospitalière.

3

Un gestionnaire de moyens mobiles est un permanencier du centre des urgences qui attribue à des unités mobiles hospitalières disponibles les interventions demandées par des médecins régulateurs.

des SGBD temps réel, ces derniers ne tiennent pas compte des contraintes liées à la mobilité (e.g. spécificités des requêtes mobiles). Ainsi, la prise en compte à la fois des contraintes de temps réel et de mobilité lors du traitement des requêtes est un problème important à résoudre.

Notre principal objectif dans cette thèse est de proposer une solution au problème ouvert du traitement des requêtes mobiles avec des contraintes de temps réel. Nous accordons une attention particulière à l’évaluation des requêtes dépendant de la localisation avec des contraintes de temps réel. Par exemple, un ambulancier demande de sélectionner les hôpitaux qui se trouvent à moins de 5 km de sa position. Le résultat doit être délivré dans un délai d’une minute.

3. Contenu de la thèse et contribution

Dans un premier temps, nous classifions les différents types de requêtes mobiles afin d’identifier leurs contraintes et leurs problèmes sous-jacents. Ensuite, nous proposons une synthèse des principaux travaux liés au traitement des requêtes en environnements mobiles. Nous nous concentrons sur trois axes représentatifs de la recherche dans ce domaine, à savoir : (i) le traitement des requêtes spatiales (e.g., un médecin interroge la base de données pour connaître l’adresse de l’hôpital le plus proche du lieu d’intervention), (ii) le traitement des requêtes dépendant de la localisation , et (iii) l’interrogation des données relatives à des objets mobiles.

Dans la suite du travail, nous nous concentrons sur un type particulier de requêtes mobiles : les requêtes dépendant de la localisation avec des contraintes de temps réel. L’expression de ces requêtes nécessite de rajouter des opérateurs pour exprimer, entre autres, les conditions de dépendance par rapport à la localisation d’un client mobile ou les contraintes temporelles. Ainsi, une étape de notre travail consiste à proposer un langage, appelé LDQL (Location Dependent Query Language) permettant d’exprimer différents types de requêtes dépendant de la localisation avec des contraintes de temps réel. Nous avons d’abord identifié les différents types de requêtes RDL et distingué leurs contraintes (e.g. dépendance des résultats par rapport à la localisation, contraintes temporelles). Ensuite, nous avons défini la syntaxe du langage proposé.

D’un autre côté, nous proposons une architecture logicielle générique, extensible et modulaire, permettant de traiter différents types de requêtes RDL avec des contraintes de temps réel. Cette architecture ne dépend pas d’un SGBD particulier, des technologies des réseaux et des techniques de localisation. En fait, nous concevons des modules destinés à être implantés au-dessus d’un SGBD existant (e.g. Oracle). Ces modules assurent un ensemble de fonctionnalités que nous pouvons classer selon deux catégories (pas forcément disjointes) : des fonctionnalités permettant de tenir compte des contraintes de temps réel, et (ii) des fonctionnalités permettant de tenir compte des contraintes liées à la mobilité.

Après avoir défini les principaux modules de cette architecture et leurs interactions, nous nous intéressons particulièrement au traitement des requêtes, dépendant de la localisation, exprimées à l’aide du langage LDQL. Plus précisément, nous proposons des méthodes permettant de tenir compte de la localisation du client et de son orientation. De plus, nous proposons une méthode permettant d’éviter de transmettre au client des résultats incorrects en tenant compte de son déplacement entre l’envoi de la requête et la réception des résultats. Les méthodes proposées tiennent également compte des requêtes RDL continues et des requêtes RDL à résultats partiels. Lorsque le client soumet une requête continue, il s’attend à recevoir

pendant un intervalle de temps des résultats éventuellement changeant en fonction de sa localisation sans avoir à soumettre la requête de façon répétitive [CDT+ 00]. Par exemple, un ambulancier reçoit pendant 30 minutes au fur et à mesure qu’il se déplace la liste des hôpitaux se trouvant à moins de 5 km de sa position. Lorsqu’un client soumet une requête à résultats partiels, il tolère que seulement un sous-ensemble des résultats lui soit délivré (e.g. afin de respecter l’échéance précisée). Par exemple, un médecin demande la liste des pharmacies situées à moins de 20 km et tolère que seulement trois résultats lui soient envoyés.

Par la suite, nous nous intéressons à la prise en compte des contraintes de temps réel dans le cadre de l’architecture proposée. Dans l’objectif d’optimiser le taux de requêtes respectant leurs échéances, nous proposons d’ordonnancer les requêtes, avant de les soumettre au SGBD sous-jacent. De plus, nous proposons d’appliquer un test d’admission permettant de rejeter les requêtes n’ayant aucune chance de respecter leurs échéances. Ce test nécessite de disposer de certaines estimations (e.g. le temps de traitement de la requête par le SGBD et le temps de transfert des résultats). Nous présentons dans cette partie notre démarche pour l’obtention de ces estimations. Nous menons également des simulations pour évaluer l’apport des tests d’admission.

Enfin, nous mettons en œuvre un prototype permettant de traiter différents types de requêtes RDL en implémentant une partie des modules de notre architecture au-dessus du SGBD commercial Oracle. Nous exploitons ce prototype pour évaluer l’apport de certaines méthodes proposées.

En résumé, dans cette thèse nous apportons une contribution au traitement des requêtes en environnement mobile par la proposition de méthodes permettant de traiter de manière efficace des requêtes RDL avec des contraintes de temps réel. En effet, ces méthodes permettent d’augmenter le pourcentage de requêtes respectant leurs échéances et le pourcentage de résultats corrects transmis aux utilisateurs (vis-à-vis de leurs localisations à la réception des résultats). De plus, elles permettent de réduire les coûts de communication.

4. Organisation du document

Après avoir introduit le contexte, présenté notre problématique, précisé notre objectif et décrit de manière synthétique le contenu de cette thèse, nous organisons le reste du mémoire comme suit :

Dans le deuxième chapitre, nous classifions les différents types de requêtes mobiles et nous identifions leurs problèmes sous-jacents. Nous présentons ensuite une synthèse des principaux travaux liés au traitement des requêtes en environnement mobile.

Dans le troisième chapitre, nous présentons un langage d’expression des requêtes dépendant de la localisation avec des contraintes de temps réel. Nous expliquons comment les conditions de dépendance par rapport à la localisation, les contraintes temporelles et les conditions sur les résultats partiels peuvent être exprimées à l’aide du langage proposé.

Dans le quatrième chapitre, nous présentons une architecture pour le traitement de différents types de requêtes RDL avec des contraintes de temps réel. Nous expliquons les principes de cette architecture et nous décrivons ses modules et leurs interactions.

Dans le cinquième chapitre, nous nous concentrons sur le problème de prise en compte de la dépendance des résultats par rapport à la localisation. Nous détaillons les méthodes proposées pour le traitement des requêtes RDL, ainsi que celui des requêtes RDL continues et des requêtes RDL à résultats partiels.

Dans le sixième chapitre, nous détaillons les méthodes proposées pour tenir compte des contraintes de temps réel. Nous présentons les évaluations de performances, par simulation, des tests d’admission étudiés.

Dans le septième chapitre, nous décrivons un prototype mis en œuvre pour évaluer des requêtes RDL avec des contraintes de temps réel. Nous présentons les principaux modules de ce prototype et nous décrivons des expérimentations menées avec des exemples concrets de requêtes RDL. Ensuite, nous exploitons ce prototype pour évaluer l’apport des méthodes proposées.

Dans la conclusion, nous présentons d’abord une synthèse des aspects abordés dans cette thèse et nous dressons un bilan des principaux résultats de nos travaux. Ensuite, nous exposons les directions dans lesquelles nos futurs travaux peuvent être poursuivis.

Chapitre II

Traitement des requêtes en environnements mobiles : état de l’art

1. Introduction

L’émergence des applications basées sur la localisation a généré de nouveaux défis. Dans le domaine des bases de données, cela s’est notamment traduit par l’apparition de nouveaux types de requêtes. Rappelons que deux catégories de requêtes mobiles peuvent être distinguées : (i) les requêtes issues de terminaux mobiles invoquant des données relatives à des objets fixes (e.g. un ambulancier demande l’adresse de l’hôpital le plus proche de sa position), et (ii) les requêtes issues de terminaux fixes ou mobiles invoquant des données relatives à des objets mobiles (e.g. sélectionner les positions des ambulances ou des hélicoptères disponibles dans une agglomération donnée).

Dans ces deux catégories, plusieurs types de requêtes ayant des spécificités et des contraintes différentes et soulevant des problèmes variés peuvent encore être distingués. Ceci a suscité l’intérêt d’une grande partie de la communauté Base de Données qui a proposé de nombreuses solutions à différents problèmes liés au traitement de ces requêtes [SWC+ 97, PS 01, GBE+ 00, SDK 01a, JT 04, ZLL 04, IMI 06].

Notre principal objectif dans ce chapitre est de présenter une synthèse des travaux relatifs au traitement des requêtes en environnements mobiles. D’abord, nous proposons une classification des types de requêtes mobiles rencontrés dans la littérature. Cette étape est centrale, car elle permet de dégager les contraintes associées à chaque type de requêtes et d’identifier leurs problèmes sous-jacents. Ensuite, nous abordons les problèmes qui nous semblent les plus importants et nous décrivons quelques solutions proposées pour les résoudre. Ainsi, nous nous concentrons sur trois axes représentatifs de la recherche dans ce domaine, à savoir : (i) le traitement des requêtes spatiales (e.g. un médecin interroge la base de données pour connaître l’adresse de l’hôpital le plus proche du lieu d’intervention), (ii) le traitement des requêtes dépendant de la localisation (i.e. requêtes dont les résultats dépendent de la localisation du client mobile les soumettant) (e.g. un ambulancier cherche l’hôpital le plus proche de sa position), et (iii) l’interrogation des données relatives à des objets mobiles (e.g. un gestionnaire de moyens mobiles demande les positions de toutes les ambulances de retour d’intervention). Avant de clore ce chapitre, nous discutons de quelques problèmes ouverts qui nous semblent importants.

2. Classification des requêtes

Pour répondre aux besoins des applications basées sur la localisation, il est nécessaire de traiter de manière efficace les différents types de requêtes. Dans cette section, nous classifions les requêtes mobiles les plus étudiées dans la littérature.

2.1. Critères de classification

En environnements mobiles, certaines entités peuvent être en mouvement (e.g. les ambulances) alors que d’autres sont fixes (e.g. les hôpitaux). Il est donc indispensable de préciser ce que signifie pour nous la mobilité [MHM+ 06a] :

Client mobile : est l’entité mobile émettant une requête. Serveur mobile : est l’entité mobile évaluant une requête.

Objet mobile : est une entité mobile à laquelle sont relatives les données interrogées (e.g.

ambulances ou hélicoptères).

Dans ce contexte, nous mettons en évidence certains critères de classification en nous basant sur les contraintes pouvant être associées aux requêtes.

Grâce au premier critère, qui est la mobilité, nous distinguons les deux catégories de requêtes citées dans l’introduction de ce chapitre, à savoir : (i) les requêtes issues de terminaux mobiles et invoquant des données relatives à des objets fixes (mobilité du client), et (ii) les requêtes issues de terminaux fixes ou mobiles et invoquant des données relatives à des objets mobiles (mobilité des objets). Notons que la mobilité du serveur n’ajoute pas de types supplémentaires de requêtes. Toutefois, celle-ci influence leurs modèles d’exécution, car des problèmes liés à la mobilité doivent être considérés (e.g. connexion réseaux, localisation des serveurs, distribution des données sur les différents serveurs mobiles) [HAA 02 STV 05, KMB+ 06].

Dans les deux catégories de requêtes mentionnées, plusieurs types peuvent encore être identifiés. En effet, notre second critère de classification est la présence ou non de la dimension spatiale. Il permet de distinguer les requêtes spatiales des requêtes non spatiales.

Le troisième critère est la dépendance du résultat par rapport à la localisation du client mobile. Il permet de distinguer un type de requêtes mobiles particulièrement étudié dans la littérature, appelé requêtes dépendant de la localisation (RDL). Notons que les résultats d’une requête invoquant des données relatives à des objets mobiles (ROM) dépendent de localisation des objets mobiles (ambulances, hélicoptères), mais pas nécessairement de celle du client qui soumet la requête.

Le quatrième critère correspond à l’association de la dimension temporelle à la dimension spatiale et permet de distinguer les requêtes spatio-temporelles. Dans la littérature liée au traitement des requêtes en environnements mobiles, ce type est associé soit aux requêtes ROM (e.g. quelles seront les positions des ambulances de retour d’intervention dans 5 minutes), soit aux requêtes RDL (e.g. un ambulancier cherche les hôpitaux qu’il peut atteindre en 10 minutes).

Le cinquième critère concerne le mode d’évaluation des requêtes. En effet, une requête peut être soumise comme continue ou « sporadique ». Nous expliquons les requêtes continues dans la sous-section 2.7.

Mobiles non spatiales

Mobiles spatiales

RDL ROM ROM

Spatio-temporelles RDL-ROM RDL-ROM-spatio-temporelle T y pe s de re q u ête s ob te n u s CM et OF (CM ou CF) et OM NSP NSPSP SP IL DL DL NST ST STNST IL Dépendance par rapport à la localisation du client Dimension spatio-temporelle Dimension spatiale Mobilité CF : Client Fixe OF : Objet Fixe CM : Client Mobile OM : Objet Mobile SP : Spatiale NSP : Non Spatiale DL : Dépendant de la Localisation IL : Indépendant de la Localisation ST : Spatio-Temporelle NST : Non Spatio-Temporelle

ROM : Requêtes relatives à des Objets Mobiles

NST ST RDL Spatio-temporelles C ri tèr es d e cl a ssi fi ca ti o n

Figure 1 : Critères de classification et types de requêtes mobiles obtenus selon ces critères

La Figure 1 résume les différents types de requêtes obtenus selon les quatre premiers critères de classification. Pour simplifier le schéma, nous ne représentons pas le cinquième critère (mode d’évaluation continue) qui ajoute à la liste des types de requêtes identifiés les requêtes continues. Ainsi, à l’aide de ces critères de classification, nous retenons six types de base de requêtes :

(i) Requêtes mobiles non spatiales (ii) Requêtes mobiles spatiales (iii)Requêtes RDL

(iv) Requêtes ROM

(v) Requêtes spatio-temporelles (vi) Requêtes continues

Notons que des types « composés » peuvent résulter de l’association de plusieurs contraintes (e.g. ROM-RDL, ROM Spatio-temporelles).

Dans la suite, nous expliquons ces requêtes en donnant des exemples et en identifiant brièvement les problèmes sous-jacents à chaque type. Nous consacrons la dernière partie de cette section à la discussion des différences entres les types classifiés et leurs problèmes communs.

2.2. Requêtes mobiles non spatiales

Il s’agit du type de requêtes mobiles le plus simple parmi ceux classifiés. En fait, la seule différence par rapport aux requêtes traditionnelles4 réside dans le fait que les requêtes de ce type sont issues de terminaux mobiles. Ainsi, un client mobile peut envoyer sa requête de n’importe quel endroit tout en continuant son déplacement. Par exemple, le médecin d’une unité mobile hospitalière envoie au serveur, en utilisant un terminal mobile, une requête pour connaître des informations médicales sur un patient. L’évaluation de cette requête nécessite de prendre en considération des problèmes liés aux caractéristiques des environnements mobiles. Par exemple, les terminaux mobiles possèdent des capacités de traitement réduites et des problèmes d’alimentation électriques ; ils peuvent changer de localisation et se déconnectent fréquemment. Les réseaux sans fils, qui sont le contexte de cet exemple, se caractérisent par des débits faibles et des latences fortes. Ces aspects ont fait l’objet de plusieurs études depuis le début des années 1990. Ainsi, de nouveaux modèles d’exécution adaptés à l’évaluation des requêtes mobiles non spatiales ont vu le jour [IB 92, DH 95, PS 01].

2.3. Requêtes spatiales

Le succès de certaines applications, comme celles basées sur des Systèmes d’Informations Géographiques SIG, a motivé le développement de SGBD particuliers, dits « SGBD spatiaux ». Ces SGBD permettent la gestion d’objets géométriques (e.g. routes, parcelles). Ces objets possèdent des propriétés descriptives et des propriétés spatiales [Rig 02]. Par exemple, un hôpital possède un identifiant et un nom comme propriétés descriptives et une localisation comme propriété spatiale. Nous pouvons alors parler d’attributs descriptifs et d’attributs spatiaux. Ainsi, les requêtes spatiales peuvent être définies comme des requêtes impliquant au moins un prédicat spatial. Un prédicat spatial implique au moins un attribut ou une opération spatiale (e.g. Distance, Inclusion) [SA 94]. Bien que les requêtes spatiales ne soient pas forcément liées à la mobilité des unités, le développement d’applications basées sur la localisation nécessite de prendre en considération ce type de requêtes. En effet, les localisations des objets (fixes ou mobiles) sont souvent considérées comme des données spatiales interrogées par des requêtes issues de terminaux mobiles.

Deux formes de requêtes spatiales ont particulièrement été étudiées dans la littérature : (i) les requêtes spatiales d’intervalle ou de zone (en anglais « range/window queries »), et (ii) les requêtes spatiales de recherche des plus proches voisins, notées K-NN « K- Nearest Neighbors ».

Les requêtes de zone permettent de sélectionner un ensemble d’objets dans une région géographique précise donnée comme argument (e.g. sélectionner tous les hôpitaux qui se trouvent dans une zone de 15 km autour du lieu d’intervention).

Les requêtes K-NN permettent de sélectionner les K voisins les plus proches d’un objet spatial (e.g. sélectionner les trois hôpitaux les plus proches du lieu d’intervention).

Le traitement des requêtes spatiales soulève plusieurs problèmes liés à la représentation des données spatiales et à la nécessité de développer des méthodes permettant un accès efficace à

4

Nous considérons les requêtes issues de terminaux fixes et interrogeant des données de types standards (e.g non géométriques) et qui ne sont pas relatives aux localisations des objets mobiles comme des requêtes traditionnelles.

ces données. Lorsque les requêtes spatiales sont issues de terminaux mobiles, ces problèmes s’ajoutent à ceux cités dans la sous-section 2.2 concernant les requêtes mobiles non spatiales. Nous détaillons ces problèmes et les solutions proposées pour les résoudre dans la troisième section.

2.4. Requêtes dépendant de la localisation

Une requête est appelée requête dépendant de la localisation lorsque ses résultats dépendent de la localisation du client mobile qui la soumet. Par exemple, à partir d’une ambulance, un utilisateur cherche l’hôpital le plus proche de sa position.

Les requêtes RDL introduisent de nouveaux problèmes par rapport aux requêtes mobiles non spatiales et aux requêtes spatiales. Premièrement, de nouveaux opérateurs permettant de tenir compte de la proximité et de l’orientation des clients mobiles doivent être définis. Deuxièmement, des étapes supplémentaires sont requises afin de prendre en compte la localisation du client, lors de l’évaluation de la requête. Cette information (la localisation) peut être récupérée à partir de différentes sources (e.g. les bases de données des opérateurs de réseaux sans fil ou les systèmes de localisation tels que GPS). De plus, il est parfois nécessaire de tenir compte des éventuelles différences de niveaux de granularité des localisations (i.e. lorsque la localisation du client mobile est déterminée avec une granularité différente de celles des données interrogées). Un autre problème concernant la validité des résultats des requêtes RDL doit être pris en compte. En effet, comme le client continue son déplacement après l’envoi de la requête et que les résultats dépendent donc de sa localisation, il devient parfois difficile de produire des résultats corrects. Ces différents problèmes font, depuis quelques années, l’objet de nombreuses recherches dont nous présentons une synthèse dans la section 4.

2.5. Requêtes relatives à des objets mobiles

Ce type de requêtes, noté ROM, regroupe les requêtes issues de terminaux mobiles ou fixes invoquant des données relatives à des objets mobiles (e.g. ambulances, hélicoptères). Ces requêtes ont fait leur apparition avec l’émergence d’un grand nombre d’applications nécessitant de stocker dans des bases de données, des informations sur des objets mobiles [WM 05]. Dans la littérature liée au traitement des requêtes mobiles, on parle de bases de données d’objets mobiles MOD (Moving Objects Databases) [SWC+ 97]. Un exemple de scénario nécessitant l’évaluation de requêtes ROM peut être : un gestionnaire de moyens mobiles qui interroge la base de données pour connaître les identifiants et les positions de toutes les ambulances de retour d’intervention et qui sont actuellement dans une zone de 15 km autour du lieu d’intervention.

Dans cette catégorie de requêtes, la taille et la forme de l’objet ne sont pas importantes. C’est généralement l’information sur sa localisation qui est la plus demandée. Par conséquent, de nombreux problèmes ont été soulevés comme : (i) la modélisation et l’interrogation des données qui changent de manière continue telles que les positions des objets mobiles, et (ii) le suivi et la mise à jour de ces informations, ainsi que la gestion de l’incertitude sur la localisation due à l’imprécision des systèmes de positionnement et au mouvement des objets. Ces sujets ont suscité l’intérêt d’une part importante de la communauté bases de données (cf. section 5).

2.6. Requêtes spatio-temporelles

Le type spatio-temporel englobe les requêtes associant la dimension spatiale à la dimension temporelle. Les résultats de ces requêtes ne dépendent pas seulement des positions des objets mobiles ou du client les soumettant, mais aussi de leurs positions à un instant donné ou de leurs trajectoires pendant un intervalle de temps. La notion temporelle implique généralement le passé, le présent ou le futur. Ainsi, nous pouvons distinguer deux formes de requêtes spatio-temporelles.

La première, considère des trajectoires décrivant un historique des déplacements de l’objet mobile pendant un intervalle de temps (e.g. sélectionner toutes les ambulances dont la trajectoire passe par le centre ville entre 16h30 et 17h30).

La deuxième forme, s’intéresse plutôt à la position actuelle de l’objet ou du client mobile et éventuellement à sa position future [MR 00] (e.g. sélectionner les ambulances qui se trouveront à moins de 30 km du lieu de l’accident dans 10 minutes ; ou sélectionner les hôpitaux situés à moins de 5 km de la position à laquelle je serai dans 30 minutes).

Les requêtes spatio-temporelles soulèvent des problèmes à plusieurs niveaux. La représentation des données qui varient continuellement (e.g. la position) est sans doute une des préoccupations majeures de plusieurs chercheurs, depuis plusieurs années. En fait, il est nécessaire de gérer des structures de données complexes afin de représenter les trajectoires des objets mobiles. De plus, il est indispensable de proposer des méthodes efficaces pour représenter le mouvement des objets et éventuellement anticiper leurs positions futures. L’interrogation des données spatio-temporelles constitue également un axe de recherche très important. En effet, bien que des extensions des langages traditionnels permettent l’interrogation des données spatiales ou temporelles, ces extensions ne sont pas suffisantes pour exprimer la forte relation entre l’espace et le temps caractérisant les requêtes spatio-temporelles. D’un autre côté, il faut prendre en compte la notion d’incertitude spécifique à la mobilité des objets, que ce soit dans les modèles de données ou dans les extensions de langages proposées. Nous présentons dans la section 5 les différentes propositions développées à ce sujet.

2.7. Requêtes continues

Une requête continue (RC) permet aux utilisateurs d’obtenir, à partir d’une base de données, les résultats changeant sans avoir à la soumettre de façon répétitive [CDT+ 00]. Supposons qu’un médecin régulateur souhaite connaître les identifiants des ambulances qui entrent dans une région R. Si cette requête est soumise comme requête « sporadique », elle est évaluée et l’ensemble des résultats est immédiatement renvoyé à l’utilisateur. Dans le cas où cette même requête est soumise comme requête continue, le résultat (l’ensemble des ambulances sélectionnées) varie « continuellement » avec le déplacement des ambulances pendant une certaine durée (e.g. précisée par l’utilisateur).

Dans un contexte mobile, les requêtes continues exigent des modifications notables dans les algorithmes d’évaluation. En effet, il faut trouver combien de fois la requête doit être réévaluée et à quel moment les résultats doivent être transmis à l’utilisateur. Il faut aussi étudier les possibilités d’une réévaluation partielle ou incrémentale des requêtes continues [HLC+ 03, LUL+ 01, MXA 04].

2.8. Récapitulatif des types de requêtes classifiés et discussion

Dans cette section, nous avons présenté les types de requêtes qui nous semblent les plus importants en environnements mobiles. Cependant, nous voulons insister ici sur deux points essentiels : (i) les types de requêtes présentés constituent des ensembles qui ne sont pas forcément disjoints ; et (ii) plusieurs types de requêtes partagent des problèmes communs.

Effectivement, des combinaisons parmi les types classifiés donnent lieu à d’autres types de requêtes qui méritent d’être étudiés. Par exemple, nous pouvons rencontrer des requêtes dont les résultats dépendent à la fois de la localisation du client (RDL) et de celles des objets (ROM) (e.g. un ambulancier cherche les véhicules de police à moins de 5 km de sa position). Ces requêtes ont été appelées RDL dans [SDK 01a, IMI 06] et ROM dans [SWC+ 97] alors que nous les appelons RDL-ROM, selon notre classification. De même, les requêtes RDL continues ou ROM continues répondent aux besoins de plusieurs applications basées sur la localisation (e.g. un utilisateur mobile souhaite être notifié lorsqu’il passe à moins de 5 km d’une pharmacie, pendant les 30 prochaines minutes). Avec notre classification, nous avons choisi de marquer les différences entre ces différents types de requêtes afin de les étudier séparément.

Dans le Tableau 1, nous récapitulons les six types de requêtes mobiles présentés. Nous observons que les trois premiers types de requêtes (mobiles non spatiales, spatiales et RDL) impliquent la mobilité du client, mais pas celle des objets. A part les requêtes mobiles non spatiales, toutes les autres requêtes impliquent la dimension spatiale. Les requêtes RDL ajoutent la dépendance du résultat par rapport à la localisation du client. Les requêtes ROM et spatio-temporelles impliquent la mobilité des objets et éventuellement celle du client. Les requêtes spatio-temporelles ajoutent la dimension temporelle à la dimension spatiale. Enfin, notons que les requêtes continues constituent un type transversal pouvant être associé à tous les autres types de requêtes.

Tableau 1 : récapitulatif des types de requêtes mobiles

Le deuxième point concerne les problèmes communs aux différents types de requêtes. En effet, certains problèmes concernent plusieurs types de requêtes tel que le besoin de localiser les terminaux mobiles (ne serait-ce que pour transférer les résultats au bon endroit). Toutes les requêtes interrogeant des données spatiales (e.g. requêtes spatiales, requêtes RDL, requêtes ROM, requêtes spatio-temporelles) partagent des problèmes liés à la représentation et la manipulation des données spatiales dans des bases de données. La modélisation des données représentant des objets mobiles et la modélisation des données spatio-temporelles sur les objets mobiles sont également des problématiques très proches. C’est ainsi que plusieurs travaux ont été menés pour modéliser les données relatives aux objets mobiles dans la perspective de supporter les requêtes spatio-temporelles [SWC+ 97, GBE+ 00, GRS 00]. Au

Types de requêtes Client mobile

Objet mobile

Dimension spatiale

Dépendance par rapport à la localisation du client

Dimension temporelle

Mobiles non spatiales Oui Non Non Non Non

Spatiales Oui Non Oui Non Non

Dépendant de la

localisation Oui Non Oui Oui Non

Relatives à des objets

mobiles Oui/Non Oui Oui Non (celle des objets) Non Spatio-temporelles Oui/Non Oui/Non Oui Oui/Non (celle des objets) Oui

niveau de l’expression des requêtes, nous retrouvons aussi des problèmes communs comme la nécessité d’étendre certains langages, afin de supporter de nouveaux opérateurs spécifiques qui peuvent être utilisés pour différents types de requêtes.

Dans cette section, nous avons présenté une classification des différents types de requêtes mobiles. Dans la suite, nous détaillons les principaux travaux effectués visant à résoudre les problèmes liés au traitement des requêtes en environnements mobiles.

3. Traitement des requêtes spatiales

Bien que le traitement des requêtes spatiales ait été étudié indépendamment du contexte de mobilité et des applications basées sur la localisation, il est important de comprendre les problèmes qu’il soulève et les méthodes proposées pour les résoudre. En effet, la plupart des applications basées sur la localisation nécessitent la manipulation de données spatiales (e.g. les localisations des objets, les distances entre objets). Les solutions proposées pour résoudre les problèmes liés au traitement de requêtes mobiles plus complexes (e.g. RDL, ROM, spatio-temporelles) s’appuient souvent sur les méthodes développées dans le domaine des bases de données spatiales. En fait, ces méthodes ont été réutilisées et adaptées afin de tenir compte des contraintes supplémentaires ajoutées par ces types de requêtes (e.g. la dépendance par rapport à la localisation du client mobile) [ZZP+ 03, TP 02]. Ceci justifie notre intérêt pour les travaux relatifs au traitement des requêtes spatiales auxquels nous consacrons cette section.

La représentation des données multidimensionnelles (e.g. spatiales) et les traitements effectués sur ces données ont nécessité, entre autres, la proposition de modèles de données adaptés, de nouveaux langages d’interrogation et de nouvelles méthodes d’indexation. Depuis plus de deux décennies, des recherches ont été menées sur des sujets divers dans le domaine des bases de données spatiales. Vu l’abondance des travaux, nous n’avons pas l’ambition de dresser un état de l’art exhaustif sur le traitement des requêtes spatiales. Nous allons plutôt présenter quelques concepts de base permettant de comprendre comment une requête spatiale est évaluée. Nous nous intéressons d’abord aux modèles de données permettant la représentation et l’interrogation des données spatiales. Ensuite, nous présentons quelques index spatiaux et quelques algorithmes de recherche de données spatiales proposés dans la littérature.

3.1. Modèles de données spatiales

La complexité de la modélisation des données spatiales vient de la nécessité de représenter des informations de nature géométrique. En effet, plusieurs travaux ont proposé d’enrichir les SGBD par des fonctions dites « spatiales ». Parmi les solutions développées, nous citons d’abord les travaux de Chang et Fu. qui ont proposé le système IMAID dans [CF 81]. Ce système se base sur le modèle relationnel pour représenter des objets géométriques. Par exemple, les tuples d’une relation représentent des segments et quatre attributs représentent les coordonnées (X, Y) des extrémités de ce segment. Un langage de requête a également été proposé avec le système IMAID [CF 80]. Ce langage permet de manipuler des données relatives à des objets géométriques (e.g. Points, Lignes). D’autres approches ont été proposées pour étendre les SGBD afin de permettre le traitement des requêtes spatiales [Gut 89, Gut 94, RSS+ 03]. Dans cette section, nous nous intéressons à deux approches connues qui ont par la suite été étendue pour représenter des données spatio-temporelles relatives à des objets mobiles. La première vise à étendre les SGBD traditionnels par des Types Abstrait de Données TAD [Gut 89, Gut 94]. La deuxième se base sur un modèle de données dit « avec

contraintes » [RSS+ 03, GAS 03]. Dans la suite, nous détaillons ces deux approches et nous discutons dans la section 5.1 leur extension pour représenter les données spatio-temporelles relatives à des objets mobiles.

3.1.1. Types abstraits de données

Afin de combler certaines insuffisances des SGBD traditionnels au niveau de la représentation et de l’interrogation des données spatiales, une première approche consiste à enrichir le modèle relationnel avec des TAD spatiaux. Il s’agit principalement de définir : (i) un ensemble de types de données permettant de représenter différentes figures géométriques et (ii) un ensemble d’opérations sur ces types. Par exemple, grâce au type Point, il est possible de représenter, dans une base de données, un point dans un espace 2D. Grâce au type Path qui est une liste de segments connectés deux à deux, il est possible de représenter une partie d’une route. L’espace couvert par une zone géographique peut avoir le type Polygone. Parmi les exemples d’opérations sur des types abstraits, nous pouvons citer l’opération LENGTH(path) permettant de calculer la longueur d’une route ou l’opération INSIDE(point,polygone) permettant de vérifier si un polygone contient un point donné. L’idée d’étendre le modèle relationnel avec un système de types et un ensemble d’opérations associées à ces types pour construire des SGBD spatiaux a été initialement introduite dans [Gut 89]. Dans cet article, l’objectif premier de l’auteur était de proposer un SGBD relationnel opérationnel, appelé Gral, extensible par des types de données et des opérations pouvant être définis par les utilisateurs. Par la suite, plusieurs travaux se sont basés sur les TAD, non seulement dans le but d’interroger des données spatiales [Gut 94], mais aussi pour manipuler des données spatio-temporelles [GBE+ 00]. De plus, plusieurs SGBD connus ont adopté cette approche tels que ORACLE [Sha 99] ou PostgreSQL [Pos 06]. Ces SGBD se basent sur la norme « OGC

OpenGIS Simple Features Specification For SQL » [Ope 07]. Cette norme définit une

structure pour les types géométriques et décrit les fonctions et les opérateurs agissant sur ces types. Avant de clore cette partie, nous illustrons par un exemple l’utilisation des TAD avec PostgreSQL.

Soit la relation ZoneGeo(idZone:Int, idCent:String, GeomZone:Polygone)

Supposons que chaque zone géographique possède un centre de pompiers identifié par l’attribut idCent. L’attribut spatial GeomZone de type Polygone permet de représenter la couverture spatiale de cette zone.

Supposons maintenant qu’un utilisateur souhaite savoir quel centre de pompiers contacter suite à un accident. Soit le point P de coordonnées (400,500) correspondant à la localisation du lieu d’intervention. Il s’agit, en fait, de chercher la zone géographique contenant le point P. Cette requête peut être exprimée de la manière suivante, sous PostgreSQL [Pos 06] :

Select idCent From ZoneGeo

Where GeomZone @> Point(‘(400,500)’) ;

Dans PostgreSQL l’opération spatiale @> permet de vérifier si une zone (e.g. Polygone, cercle, rectangle) contient un point donné.

3.1.2. Modèle de données contraintes

Une approche complètement différente est basée sur le modèle de données contraintes. Selon cette approche, il est soutenu que les limites des systèmes relationnels ne sont pas dues à la faiblesse du typage, mais plutôt, à l’impossibilité de gérer des ensembles infinis [Rig 02]. Le modèle de données contraintes a initialement été introduit en 1990 dans [KKR 90]. Bien que le paradigme présenté permette la représentation de tous les types de données, c’est son application à la représentation des données spatiales et, nous le verrons plus loin, spatio-temporelles qui a été la plus étudiée [RCK+ 00, RSS+ 03, GAS 03]. Le principe est de considérer les objets spatiaux comme des ensembles infinis de points satisfaisant des formules de la logique du premier ordre (ces formules correspondent aux contraintes). La représentation avec contraintes peut être vue comme une extension de la représentation, finie, relationnelle [MR 00]. Par exemple, un polygone peut être modélisé par une relation avec deux attributs (l’abscisse et l’ordonnée) et possédant une infinité de tuples. Ce modèle donne donc la possibilité à l’utilisateur de raisonner sur des ensembles infinis de points sans se soucier de leur représentation finie. Celle-ci se base sur des contraintes définies dans un langage comprenant des opérateurs arithmétiques [Rig 02]. La particularité de ce modèle réside dans le fait que la complexité liée à la modélisation des données est cachée à l’utilisateur. Ainsi, les requêtes spatiales peuvent être exprimées grâce à des langages assez intuitifs.

Pour illustrer nos propos, prenons le scénario suivant : un utilisateur cherche les numéros de téléphone des sociétés d’ambulances privées pouvant intervenir dans la zone du lieu d’intervention. Supposons que chaque société d’ambulance couvre un secteur (géographique) de garde précis. Soit Rect(Xmin,Xmax,Ymin,Ymax) une zone rectangulaire autour du lieu d’intervention. Ce scénario nécessite l’évaluation d’une requête spatiale permettant de déterminer les secteurs de garde ayant au moins un point commun avec la zone rectangulaire autour du lieu d’intervention. Nous utilisons le langage proposé avec le prototype DEDALE (basé sur un modèle de données contraintes) pour exprimer cette requête [RSS+ 03].

Soit la relation SocieteAmb(idS, nom, numTel, GeomSect[x,y]).

Remarquons que la relation possède trois attributs non spatiaux et une relation imbriquée

GeomSect qui donne la géométrie du secteur de garde dans le plan Euclidien. La notion de

relation imbriquée représentant un ensemble infini de points est expliquée dans [RSS+ 03]. La requête s’exprime de la manière suivante :

Select SA.numTel

From SocieteAmb as SA, GeomSect as P Where P.x between Xmin and Xmax And P.y between Ymin and Ymax ;

En plus du prototype DEDALE développé en France [RSS+ 03], d’autres prototypes se basant sur le modèle de données contraintes ont été proposés [RCK+ 00], [GAS 03]. Ces prototypes montrent que les principes des modèles de données contraintes sont en pratique applicables à la gestion des données multidimensionnelles et donc spatiales. De plus, grâce à ces modèles, il est possible de proposer des langages intuitifs. Les utilisateurs ne sont donc pas obligés d’utiliser une panoplie de nouvelles opérations sur de nouveaux types de données (comme dans le cas des TAD). Toutefois, ces modèles présentent quelques limites lorsqu’il s’agit d’implanter certaines fonctions très utiles, comme la distance entre deux points