Integration Donnees - These Bonnet - Mediation

THÈSE
présentée par
Philippe BONNET
pour obtenir le grade de
Docteur de l'Université de Savoie
Spécialité Informatique
Prise en compte des sources de données indisponibles

dans les systèmes de médiation
Soutenue le 25 janvier 1999

Composition du jury :
M. : Georges Gardarin Président et rapporteur
M. : Dennis Shasha Rapporteur
MM. : André Flory Co-directeurs de thèse
Michel Riveill
MM. : Mauricio Lopez Examinateurs
Patrick Valduriez
Anthony Tomasic
Thèse préparée au sein de l'INRIA Rhône Alpes (action Médiation du GIE Dyade)
1
Je remercie André Flory,

je remercie Stéphane Bressan, qui m'a tout appris,
leur conance et leur engagement m'ont permis de me lancer.
Je remercie Mauricio Lopez, mon chef,
je remercie Patrick Valduriez,
ils m'ont permis d'eectuer ma thèse dans les meilleures conditions.
Je remercie Anthony Tomasic, à qui je dois encore quelques bières,
j'ai eu grand plaisir à travailler avec lui sur ce sujet qu'il a initialement déni,
il me fait l'honneur de venir de loin pour participer à mon jury de thèse et
j'en suis très touché.
Je remercie Michel Riveill,
qui a accepté d'être directeur de ma thèse.
Je remercie Georges Gardarin,
je remercie Dennis Shasha,
ils ont accepté de juger mon travail et ont été une grande source de
motivation durant la rédaction du manuscrit.
Je remercie Olga Kapitskaia (ses relectures implacables), Hubert Naacke
(sa connaissance d'Avignon) et Rémy Amouroux (ses arrêts décisifs),
ils ont animé l'action Médiation et ses à-côtés.
Je remercie Alex, Claude, Olivier, Roland, Pitch (son soutien constant), Pascal,
Povl (son Alfa et tout le reste), Hanner, Thierry et Xavier,
travailler à Grenoble m'a surtout permis de les côtoyer.
Je remercie mes amis de Carcassonne, de l'INSA, de l'ECRC, de Grenoble et d'ailleurs,
leur présence et leurs messages, à l'occasion de ma soutenance, me sont chers.
Enn, je remercie ma mère,
pour tout.
2
Table des matières 3
Table des matières
1 Introduction 7
1.1 Origine de l'étude . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2 Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.3 Plan du Manuscrit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2 Les systèmes de médiation 13

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2 Besoins et Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.1 Complexe hospitalier . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.2 Catalogues documentaires . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.3 Autres applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.4 Bilan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3.1 Architecture Naïve . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.3.2 Entrepôt de données . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3.3 Système de médiation . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.3.4 Bilan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.4 Systèmes de médiation existants . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.4.1 Systèmes fédérés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.4.2 Systèmes à grande échelle . . . . . . . . . . . . . . . . . . . . . . . . 27
2.4.3 Systèmes commerciaux . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.4.4 Problématique associée aux systèmes de médiation . . . . . . . . . . 33
4 Table des matières
2.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3 Systèmes de médiation et sources de données indisponibles 41

3.1 Problèmes dues aux sources de données indisponibles . . . . . . . . . . . . . 41
3.1.1 Indisponibilité des sources de données . . . . . . . . . . . . . . . . . . 41
3.1.2 Exigences des utilisateurs . . . . . . . . . . . . . . . . . . . . . . . . 43
3.1.3 Impact sur le traitement de requêtes . . . . . . . . . . . . . . . . . . 44
3.2 Limitation des systèmes de médiation existants . . . . . . . . . . . . . . . . 45
3.3 Approches existantes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.3.1 Réplication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.3.2 Traitement approché des requêtes . . . . . . . . . . . . . . . . . . . . 46
3.3.3 Utilisation de caches sémantiques . . . . . . . . . . . . . . . . . . . . 49
3.3.4 Bilan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4 Traitement incrémental des requêtes 53

4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.2 Architecture d'un système incrémental . . . . . . . . . . . . . . . . . . . . . 55
4.2.1 Composants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.2.2 Fonctionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.2.3 Implantation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.3 Détection des sources indisponibles . . . . . . . . . . . . . . . . . . . . . . . 60
4.4 Matérialisation des données disponibles . . . . . . . . . . . . . . . . . . . . . 62
4.5 Construction de la requête incrémentale . . . . . . . . . . . . . . . . . . . . 65
4.6 Comparaison avec des travaux existants . . . . . . . . . . . . . . . . . . . . . 68
4.7 Conclusions et perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5 Extraction d'informations partielles 73

5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
5.1.1 Requêtes parachutes . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Table des matières 5
5.1.2 Formulation des requêtes parachutes . . . . . . . . . . . . . . . . . . 75
5.1.3 Évaluation des requêtes parachutes . . . . . . . . . . . . . . . . . . . 76
5.2 Génération de requêtes parachutes . . . . . . . . . . . . . . . . . . . . . . . . 76
5.2.1 Cadre général . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
5.2.2 Algorithme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
5.2.3 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
5.3 Optimisation sous contrainte . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
5.3.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
5.3.2 Algorithme d'optimisation . . . . . . . . . . . . . . . . . . . . . . . . 92
5.3.3 Politique de matérialisation . . . . . . . . . . . . . . . . . . . . . . . 101
5.3.4 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
5.4 Comparaison avec des travaux existants . . . . . . . . . . . . . . . . . . . . . 102
5.4.1 Extraction d'informations partielles . . . . . . . . . . . . . . . . . . . 103
5.4.2 Optimisation d'un ensemble de requêtes . . . . . . . . . . . . . . . . 106
5.5 Conclusions et Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
6 Évaluation 109
6.1 Cadre Expérimental . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
6.1.1 Modèle Analytique . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
6.1.2 Environnement de simulation . . . . . . . . . . . . . . . . . . . . . . 111
6.1.3 Charge de Travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
6.2 Traitement incrémental des requêtes . . . . . . . . . . . . . . . . . . . . . . . 115
6.2.1 Temps de traitement . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
6.2.2 Nombre de soumissions pour obtenir la réponse complète . . . . . . . 120
6.3 Optimisation sous contrainte . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
6.3.1 Présentation des requêtes parachutes . . . . . . . . . . . . . . . . . . 128
6.3.2 Résultats de l'optimisation sous contrainte . . . . . . . . . . . . . . . 129
6.3.3 Comparaison des politiques de matérialisation . . . . . . . . . . . . . 130
6.3.4 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
6 Table des matières
6.4 Disponibilité des sources dans l'application Redoc . . . . . . . . . . . . . . . 134
6.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
7 Conclusion 139
7.1 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
7.2 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
A Glossaire 153
7
Chapitre 1
Introduction
1.1 Origine de l'étude
La plupart des systèmes d'information peuvent aujourd'hui être décomposés en sous-
systèmes autonomes. Chaque sous-système peut ainsi fournir à un groupe d'utilisateurs les
moyens informatiques les plus adaptés à ses besoins. Les fusions ou les regroupement d'entre-
prises conduisent naturellement à un tel morcellement du système d'information. De manière
générale, le système d'information ne peut plus être considéré comme un bloc monolithique.
Dans un hôpital par exemple, chaque service gère de manière autonome un ensemble de
logiciels : le service de chirurgie, le service de radiologie, ou le service administratif disposent
de logiciels diérents pour la gestion des actes médicaux et le suivi des patients.
Une autre facteur important pour l'évolution des systèmes d'informations est le dévelop-
pement du World Wide Web (WWW). De nombreuses sources d'informations sont désormais
accessibles à l'extérieur des organisations. Il est ainsi possible d'échanger des informations
avec des partenaires ou d'intégrer dans les processus de décisions des informations fournies
par des concurrents.
Ces évolutions des systèmes d'information conduisent à la constitution d'îlots d'informa-
tion autonomes et cependant interconnectés. Un réseau Intranet permet en eet de relier
toutes les composantes du système d'information d'une organisation. L'Internet et le WWW
permettent d'accéder des sources de données externes.
Ce grand volume d'information, qui est désormais accessible, doit pouvoir être utilisé
pour faire face au besoin qu'ont les organisations de contrôler leur activité ou de réagir
rapidement aux événements (internes ou externes). Dans un hôpital, le système d'informa-
tion doit permettre aux docteurs d'améliorer leur suivi des patients et aux gestionnaires de
contrôler les dépenses.
Dans ce contexte, un problème essentiel est de gérer l'hétérogénéité et la répartition des
diérentes sources de données. Une source fournit un service d'accès aux données qu'elle
gère sous forme de bases de données, de chiers ou de documents. Des sources de données
8 Introduction
diérentes ont en général des caractéristiques diérentes. Un serveur Notes-Domino qui ren-
voie des pages HTML sur le World Wide Web, un système de gestion de chiers structurés
AS/400 accessibles via ftp et une base relationnelle Oracle accessible via SQL*Net ont des
protocoles d'accès, des langages d'interrogation et des représentations des données très dié-
rentes. Accéder à un ensemble de sources d'informations sans outil particulier demande donc
à l'utilisateur beaucoup de compétences et de temps.
L'intégration de sources de données nécessite des outils qui prennent en charge ces pro-
blèmes de répartition et d'hétérogénéité et qui fournissent un accès ecace à un ensemble de
sources de données. Faciliter l'intégration des sources de données est l'objectif des systèmes
de médiation tels que Disco, un prototype au développement duquel nous avons participé
dans le contexte de l'action Médiation du GIE Dyade [101, 100].
Un système de médiation permet à une application d'obtenir des données provenant de
diérentes sources de données en formulant une requête. Lorsqu'une requête est soumise au
système de médiation, elle est optimisée et ensuite exécutée. Lors de l'exécution, le système
de médiation envoie des sous-requêtes vers les sources de données. Chacune d'elles renvoie
une réponse. Le système de médiation combine les données qu'il obtient pour retourner la
réponse à la requête qui lui a été posée. Dans le domaine hospitalier, par exemple, un système
de médiation peut fournir une vue uniforme sur toutes les données concernant les patients
(ces données étant gérées par les diérents services de manière autonome).
Tous les systèmes de médiation existants font l'hypothèse qu'ils peuvent accéder à toutes
les sources de données impliquées dans une requête pour fournir leur réponse. Or, selon les
caractéristiques de ces sources de données et les caractéristiques du réseau auquel elles sont
connectées, il est probable qu'une ou plusieurs d'entre elles soient indisponibles lorsqu'elles
sont contactées. Une source de données est temporairement indisponible si aucune connexion
ne peut être établie avec elle, ou si elle ne transmet pas la réponse attendue, ou encore si le
temps nécessaire pour transmettre cette réponse dépasse un délai xé.
En fait, un réseau Intranet ou Internet n'ore aucune garantie au système de médiation
que les sources de données peuvent être contactées ou qu'elles vont transmettre leur réponse
dans des délais raisonnables. Les sources de données, étant elles autonomes, n'orent pas non
plus la garantie de répondre correctement à la requête qui leur est envoyée. Le déploiement
d'un système de médiation nécessite donc la prise en compte des sources de données
indisponibles 1.
Le problème des sources indisponibles se pose dans diérents contextes. Par exemple,
dans le contexte hospitalier, une source de données est indisponible lorsque le responsable
informatique du service dans lequel elle est située décide d'eectuer une opération de main-
tenance ou en cas de congestion du réseau qui relie les diérents services. De même dans le
contexte d'une application nancière, les congestions sur l'Internet peuvent rendre indispo-
nibles les sources de données des établissements bancaires ou des places boursières qui sont
intégrées.
1. Dans la suite du document, nous considérons qu'une source est indisponible si elle ne fournit pas
la réponse à la sous-requête qui lui est envoyée dans un délai raisonnable. Une source indisponible reste
accessible : le système de médiation peut la recontacter ultérieurement.
Objectifs 9
1.2 Objectifs
L'objectif de cette thèse est d'étudier les mécanismes permettant à un système de mé-
diation de fonctionner de manière satisfaisante pour l'application qui l'utilise dans le cas où
une ou plusieurs sources de données sont temporairement indisponibles.
Le problème des sources de données indisponibles a été mentionné dans le contexte de
l'intégration de données [22, 71]. Cependant, aucune solution n'a été proposée pour prendre
en compte le problème dans son ensemble. Les systèmes existants génèrent simplement une
erreur interne lorsqu'ils détectent qu'une source de données est indisponible et l'exécution
est interrompue. L'application peut soumettre à nouveau la requête si elle souhaite obtenir la
réponse. Ainsi, une application n'obtient des données du système de médiation que si toutes
les sources de données impliquées dans sa requête sont disponibles simultanément.
Les problèmes de réseau ou de panne d'un site ont par contre été traités dans le cadre
des bases de données réparties. Les solutions proposées mettent en oeuvre des techniques
de réplication [92]. Ces techniques ne sont pas applicables aux systèmes de médiation car
elles nécessitent une collaboration étroite entre les diérentes composantes du système. Un
système de médiation qui intègre des sources de données autonomes ne dispose pas, dans
le cas général, des services qui lui permettrait de répliquer les données. De plus, certaines
sources de données s'opposent à une approche basée sur la réplication pour des raisons
techniques, politiques ou légales.
Le comportement des systèmes de médiation existant lorsqu'il sont confrontés au pro-
blème des sources indisponibles présente deux inconvénients majeurs. Premièrement, des
traitements, éventuellement coûteux, sont répétés plusieurs fois pour obtenir la réponse com-
plète. Deuxièmement, ces systèmes ne permettent pas l'extraction d'informations partielles
dont l'utilisateur pourrait se satisfaire, plutôt que d'être bloqué en attendant la réponse
complète.
Dans le cas où l'application veut absolument la réponse à sa requête, le système de
médiation doit la lui fournir ecacement. En présence de sources indisponibles, le système
ne peut pas retourner la réponse lors de la première soumission de la requête ; celle-ci doit
être soumise plusieurs fois, jusqu'à ce que le système de médiation soit capable d'obtenir
et de retourner la réponse. Lors des exécutions successives de la même requête, un système
existant refait éventuellement les mêmes opérations plusieurs fois. Lorsqu'il traite la requête
consistant à obtenir les identiants des patients qui attendent d'être opérés et pour chacun
d'entre eux sélectionne son âge, le système va commencer par obtenir les données du site
de chirurgie avant de contacter le site administratif. Si le site administratif est indisponible,
le traitement de la requête est interrompu et les données qui ont déjà été obtenues sont
ignorées : le site de chirurgie a été contacté pour rien, le temps qui a été nécessaire pour
obtenir les données de cette source est perdu.
Dans certains cas, l'utilisateur peut se contenter d'informations partielles. Lorsqu'un doc-
teur consulte tous les épisodes thérapeutiques subis par un de ses patients, il peut éventuel-
lement se contenter des données se rapportant aux interventions chirurgicales pour prendre
10 Introduction
une décision. Le système de médiation doit alors être capable d'indiquer à une application
les réponses partielles qu'il peut lui fournir et de les retourner de manière ecace.
Ces exigences nous ont conduit à aborder ce travail selon les deux axes suivants :
le traitement incrémental des requêtes Plutôt que d'attendre que toutes les sources de
données soient disponibles simultanément, le système de médiation peut construire la
réponse à la requête de manière incrémentale, en tirant parti des sources disponibles
lors des exécutions successives. Le premier objectif de cette thèse est (1) de décrire les
mécanismes qui permettent à un système de médiation de construire la réponse à une
requête de manière incrémentale et (2) de démontrer l'ecacité de cette approche.
l'extraction d'informations partielles Le deuxième objectif de cette thèse est d'étudier
comment un système de médiation peut faciliter l'extraction d'informations partielles
par une application.
Ces deux axes sont complémentaires : lorsqu'une réponse est construite de manière in-
crémentale, des informations partielles peuvent être extraites des états intermédiaires du
traitement.
Nous nous sommes attachés à ce que nos résultats puissent être intégrés dans des systèmes
de médiation existants. Nous décrivons dans ce document une architecture pour les systèmes
de médiation étendus pour le traitement incrémental des requêtes et l'extraction d'informa-
tions partielles. Nous avons déni cette architecture en intégrant de nouveaux composants
dans l'architecture classique d'un système de médiation. Nous présentons un algorithme pour
chacun de ces nouveaux composants et nous étudions les performances des systèmes étendus
de cette manière.
1.3 Plan du Manuscrit

Nous présentons, dans un premier temps, un état de l'art sur les systèmes de médiation.
Nous nous concentrons ensuite sur le problème du fonctionnement d'un système de médiation
en présence de sources indisponibles. Ceci nous permet de motiver les deux axes de travail
introduits plus haut, c'est à dire le traitement incrémental des requêtes et l'extraction d'in-
formations partielles. Les deux chapitres suivants leur sont consacrés. Ils sont suivis d'un
chapitre sur l'évaluation des performances. Nous détaillons ci-dessous le contenu de chacun
de ces chapitres.
Chapitre 2 Ce chapitre présente un état de l'art sur les systèmes de médiation. Nous
décrivons tout d'abord plusieurs applications qui intègrent des sources de données réparties
sur un Intranet/Internet. Nous discutons ensuite des diérentes architectures possibles pour
ces applications, et notamment celle basée sur un système de médiation. Nous décrivons les
caractéristiques de plusieurs systèmes de médiation existants (des prototypes de recherche
Plan du Manuscrit 11
et des systèmes commerciaux) et nous donnons une vue globale des problèmes soulevés par
ces systèmes.
Chapitre 3 Ce chapitre est consacré au problème du fonctionnement du système de mé-

diation en présence de sources de données indisponibles. Nous dénissons plus précisément la
notion de source indisponible. Lorsqu'une ou plusieurs sources de données sont indisponibles
lors du traitement d'une requête, le système ne peut pas construire la réponse complète.
L'application doit à nouveau soumettre la requête pour obtenir la réponse complète. Nous
discutons les exigences des applications par rapport au système de médiation. Nous montrons
qu'en présence de sources indisponibles, les systèmes de médiation existants ne satisfont pas
ces exigences. Nous présentons des techniques qui pourraient être utilisées par les systèmes
de médiation pour faire face aux sources indisponibles. Nous montrons les limites de ces
techniques. En conclusion, nous faisons apparaître les deux axes majeurs de notre travail : le
traitement incrémental des requêtes et l'extraction d'informations partielles.
Chapitre 4 Ce chapitre concerne le traitement incrémental des requêtes. L'objectif est

d'améliorer le temps de réponse du système de médiation lorsqu'une requête doit être soumise
plusieurs fois pour obtenir la réponse complète. Nous proposons une approche incrémentale
du traitement des requêtes pour tirer parti des sources disponibles lors de chaque soumission.
Les problèmes pour mettre en ÷uvre un traitement incrémental des requêtes sont la détection
des sources indisponibles, et la réutilisation des résultats obtenus des sources disponibles.
Nous proposons une architecture qui reprend les composants classiques d'un système de
médiation et en ajoute de nouveaux pour (i) la détection des sources indisponibles, (ii)
la matérialisation des résultats obtenus des sources disponibles étant donné un espace de
stockage limité et (iii) la réécriture de la requête initiale en fonction des données matérialisées.
Nous présentons un algorithme pour chacun de ces nouveaux composants.
Chapitre 5 Ce chapitre décrit diérents aspects de l'extraction d'informations partielles.

Nous discutons tout d'abord comment le système peut interagir avec l'application pour lui
permettre d'extraire des informations partielles et pour indiquer précisément leur signi-
cation. Nous introduisons la notion de requête parachute, i.e. des requêtes qui permettent à
l'application d'extraire des informations partielles fournies par le système de médiation. Nous
distinguons le cas où le système fournit une aide à l'application pour qu'elle puisse formuler
ses requêtes parachutes et le cas où l'application formule ses requêtes parachutes sans l'aide
du système. Dans le premier cas, le problème est de prendre en compte les indications de
utilisateur, de générer des requêtes parachutes et d'en communiquer la signication exacte à
l'utilisateur. Nous proposons un algorithme qui génère un ensemble de requêtes parachutes
à partir de la requête initiale, d'indications fournies par le système et d'indications fournies
par l'utilisateur. Dans le deuxième cas, le problème est de dénir comment le système peut
tirer parti de la connaissance des requêtes parachutes pour s'assurer que les informations né-
cessaires à l'évaluation des requêtes parachutes sont obtenues et conservées. Nous proposons
un algorithme d'optimisation qui base le plan d'exécution sur les sous-requêtes partagées
entre la requête initiale et les requêtes parachutes. Nous proposons également une politique
12 Introduction
de matérialisation qui prend en compte les sous-requêtes partagées isolées dans l'algorithme
d'optimisation.
Chapitre 6 Ce chapitre est consacré à l'évaluation des algorithmes proposés dans les deux
chapitres précédents. Nous utilisons pour cela un modèle analytique et un simulateur. Ceux-
ci nous permettent d'étudier deux aspects du temps de réponse d'un système incrémental : le
nombre de soumissions nécessaires pour obtenir la réponse complète et le temps de traitement
lors de chaque soumission. Nous constatons (i) que le traitement incrémental des requêtes
permet de réduire le nombre de soumissions nécessaires pour obtenir la réponse complète
et (ii) que le traitement incrémental permet de réduire le temps de traitement en évitant la
répétition d'opérations coûteuses. Nous discutons également la capacité d'un système incré-
mental à répondre aux requêtes parachutes. Nous montrons que l'algorithme d'optimisation
décrit dans le chapitre 5 fournit un plan optimal dans la plupart des cas ; nous montrons
également, par simulation, que la politique de matérialisation des sous-requêtes partagées
permet d'améliorer les capacités du système à répondre aux requêtes parachutes.
Chapitre 7 Ce chapitre de conclusion résume les contributions de notre travail et suggère

des perspectives de recherche, notamment en ce qui concerne l'adaptabilité des systèmes de
médiation à des conditions changeantes et la capacité des utilisateurs à contrôler le travail
en cours.
13
Chapitre 2
Les systèmes de médiation
2.1 Introduction
Les systèmes de médiation ont pour objectif de favoriser l'intégration de sources de don-
nées hétérogènes et réparties. Ils fournissent à l'application un point d'entrée unique et une
vue uniforme sur un ensemble de sources de données. Celle-ci peut donc formuler des re-
quêtes impliquant des informations exportées par un sous-ensemble de sources de données
sans avoir à gérer de multiples connexions ou les particularités de chaque interface d'accès.
Nous donnons, en section 2.2, plusieurs exemples d'applications qui nécessitent l'inté-
gration de diérentes sources de données. Nous dénissons un ensemble de critères qui per-
mettent de caractériser ces applications.
Nous décrivons, en section 2.3, trois approches qui permettent de réaliser l'intégration
de sources de données : une approche naïve où l'application contacte elle même les sources
de données, une approche basée sur un entrepôt de données, et une approche basée sur
un système de médiation Nous comparons ces diérentes approches en les confrontant aux
critères dénis dans la section précédente.
Nous nous concentrons ensuite sur les systèmes de médiation. Nous présentons plusieurs
prototypes de recherche et systèmes commerciaux et nous discutons un ensemble de pro-
blèmes soulevés par de tels systèmes.
2.2 Besoins et Applications

Nous présentons dans cette section un ensemble d'applications qui intègrent des sources
de données distribuées sur un Intranet/Internet [15]. Nous décrivons en particulier deux
applications dans la réalisation desquelles l'action Médiation du GIE Dyade a été impliqué.
La première de ces applications concerne un complexe hospitalier et la seconde un réseau
de catalogues documentaires. Ces applications nous servirons d'exemples dans la suite du
14 Les systèmes de médiation
document.
2.2.1 Complexe hospitalier

La croissance de l'activité dans le domaine médical et les contraintes sur la maîtrise
des dépenses de santé ont conduit les complexes hospitaliers à moderniser leurs systèmes
d'information. C'est le cas du complexe des hôpitaux basques qui comprend trois hôpitaux.
Il y a quelques années, plusieurs systèmes d'informations coexistaient; chaque service avait
déni et développé une application adaptée à ses besoins. Un des objectifs de la modernisation
du système d'information est d'intégrer les données stockées dans les diérents services tout
en conservant les applications existantes. Un premier pas dans cette direction a été eectué
avec le développement et la mise en oeuvre de l'application CLINIC. L'objectif principal de
cette application était de permettre la consultation de toutes les données relatives au dossier
médical d'un patient. Cette application a été déployée en 1996.
L'application CLINIC a montré plusieurs limites. Premièrement, l'intégration des sources
de données situées dans les diérents services est encodée dans l'application elle même. L'in-
tégration de nouvelles sources de données due au rapprochement des services des diérents
hôpitaux est par conséquent extrêmement coûteuse dans l'architecture gée de CLINIC.
Deuxièmement, seules des requêtes prédénies, programmées dans l'application peuvent être
posées; il n'y a pas de support pour les requêtes ad-hoc. Troisièmement, l'application CLI-
NIC a été développée pour des médecins spécialistes. Un des nouveaux objectifs assigné au
système d'information du complexe hospitalier est de fournir des informations aux médecins
généralistes, pour que ceux-ci puissent suivre leur patients, ainsi qu'aux administrateurs du
complexe hospitalier, pour que ceux-ci puissent contrôler les diérents activités. Plusieurs
applications doivent donc intégrer les données provenant des diérentes sources . Ces limi-
tations de l'application CLINIC ont conduit les responsables informatiques des hôpitaux
basques à se joindre au projet Esprit MIRO-Web pour développer, en collaboration avec la
société de service Ibermatica, l'application Basque Health Service (BHS), une évolution de
l'application CLINIC dépassant les limitations décrites ci-dessus. Un document de spécica-
tion a été délivré dans le cadre du projet [36].
Les données administratives sont stockées avec un système AS/400. Les épisodes mé-
dicaux sont stockés dans des bases ORACLE situées dans chaque service (laboratoire, ra-
diologie, ...). Cinq bases ORACLE sont intégrées dans l'application CLINIC. Il est prévu
d'intégrer 20 sources de données de ce type dans l'application BHS. Les trois hôpitaux sont
reliés par un réseau métropolitain (MAN) de type FDDI (basé sur la bre optique).
Les utilisateurs de l'application BHS sont les médecins généralistes, les médecins spécia-
listes et les administrateurs de l'hôpital. L'interface utilisateur doit permettre de consulter
un ensemble de vues prédénies centrées sur un patient, ou de formuler une requête ad-hoc.
Chaque vue prédénie correspond à une requête sur un ensemble de source de données. Un
exemple de requête ad-hoc qui implique plusieurs sources de données est trouver les patients
dont le séjour dépasse 10 jours et qui attendent d' être opérés. D'autres exemples de requêtes
ad-hoc cités dans le document de spécication [36] sont: trouver les patients dont le séjour
Besoins et Applications 15
dépasse x jours et dont le diagnostic est y, ou trouver les médicaments pris par les patients
dont le diagnostic est x, ou encore trouver le nombre moyen de radios pour les patients dans
le service x.
L'application BHS doit par ailleurs garantir la fraîcheur des données qu'elles fournit à
ses utilisateurs. Elle se doit d'accéder directement aux sources de données pour fournir une
vue actuelle des données.
2.2.2 Catalogues documentaires

Le projet de réseau documentaire Grenoblois (Redoc) a débuté en 1993. Son objectif
est de développer et améliorer l'accès au nombreuses sources de documentation situées dans
l'agglomération grenobloise. Un des aspects de ce projet consiste à fournir une application,
déployée sur le World Wide Web (WWW), pour l'accès aux catalogues de documents fournis
par un réseau d'instituts publics et privés. Laction Médiation du GIE Dyade a amorcé une
collaboration avec le projet Redoc pour mettre en oeuvre cette application.
Chaque institut participant au réseau Redoc gère son propre catalogue de documents.
Chaque catalogue contient des notes bibliographiques sur des livres, des actes de conférences,
des périodiques, des thèses ou des CDs. Ces informations sont stockées dans des bases de
données relationnelles ou dans des chiers structurés. Ces catalogues sont déjà disponibles
sur le WWW via des moteurs de recherches booléens (seules les réponses qui correspondent
exactement à une requête sont renvoyées). Environ trente catalogues de documents parti-
cipent au réseau Redoc. Chacun d'eux comprend entre mille et plusieurs centaines de milliers
de notes bibliographiques.
L'objectif de l'application est de fournir aux utilisateurs un point d'entrée unique vers
les diérents catalogues documentaires. En utilisant cette application, un chercheur qui veut
une copie d'un article peut savoir si celui-ci est disponible localement. Il peut ainsi éviter
des demandes d'articles longues et coûteuses et obtenir son article rapidement en s'adressant
à l'organisme local qui le possède. Un étudiant qui utilise cette application peut se faire
une idée de la documentation disponible sur diérents sujets avant de choisir le sujet de son
mémoire.
Chaque source de données exporte un schéma similaire concernant les notes bibliogra-
phiques. La requête formulée par l'utilisateur via un formulaire de recherche correspond à
une union sur un sous-ensemble des sources de données.
2.2.3 Autres applications

2.2.3.1 Applications nancières
Le planning nancier et l'intelligence économique sont des applications qui peuvent gran-
dement bénécier des informations disponibles sur le World Wide Web [70]. De nombreuses
organisations (les entreprises, les établissements nanciers, les bourses) orent des services
en ligne (le cours des actions, les indices industriels, les comptes des entreprises, des recom-
mandations concernant les portefeuilles d'actions). Ces nombreuses sources d'informations
peuvent par exemple être utilisées pour fournir diérents services de type tableau de bord :
un service de gestion de portefeuille d'action par exemple [95] [96]. Un exemple de requête
exprimée dans une application de ce type est : quel est le prix courant des actions fortement
recommandées à l'achat dans le segment de marché "data processing, software" au NYSE.
Pour traiter cette requête, le système de médiation doit obtenir la liste des actions recomman-
dées à l'achat par un analyste nancier, retenir uniquement celles qui concernent le segment
de marché intéressant, et enn pour chacune des actions ainsi sélectionnée contacter le site
de la bourse de NY (NYSE) qui renvoie le cours actuel.
2.2.3.2 Guide d'achat

Avec le développement de l'Internet, un grand nombre de boutiques en-ligne sont apparues
qui permettent de commander des produits de toutes sortes que ce soit des ordinateurs,
des livres ou des produits régionaux. Junglee [60] propose, en association avec quelques
partenaires, un guide d'achat qui permet de rechercher le fournisseur d'un produit particulier.
Il est par exemple possible, grâce a ce guide d'achat, de rechercher les librairies en-ligne qui
fournissent le troisième volume du livre de D.Knuth : "The art of Computer Programming".
L'application retourne pour chaque produit le prix ainsi que l'URL du site fournisseur et elle
permet d'accèder à une description détaillée. Le guide d'achat se rapportant aux libraires
intègre à l'heure actuelle cinq fournisseurs.
2.2.3.3 Construction de sites WWW

Le WWW est un moyen privilégié pour la dissémination d'informations. La construction
d'un site WWW ne se cantonne plus à la dénition de quelques pages HTML ; de plus en
plus de services proposés via un serveur WWW nécessitent l'accès à des sources de données.
L'annuaire téléphonique est un exemple simple de service proposé via le WWW qui accède
une seule source de données. Le serveur d'une organisation telle qu'AT&T [41] accéde à
un ensemble de sources de données, relationnelles ou non, contenant des données sur le
personnel, les projets et l'organisation de l'entreprise. Lorsque ces données évoluent, un
moyen de garder le site WWW à jour est de construire dynamiquement les pages HTML à
partir des sources de données. La construction dynamique de pages HTML pose cependant
des problèmes de temps de réponse. Certains des aspects liés à l'intégration de sources de
données pour la construction de sites WWW ont été étudié dans le cadre du projet STRUDEL
à AT&T [41] [42].
Architecture 17
2.2.4 Bilan
Bien qu'elles aient un même besoin de vue uniforme et de point entrée unique vers un
ensemble de sources de données, les applications ci-dessus ont des caractéristiques diérentes.
Nous avons identié un ensemble de critères qui permettent de les dénir [15]:
critères concernant les sources de données : leur nombre, leur type (moteur de re-
cherche sur le WWW, SGBD relationnel, chiers structurés, base Notes, ...), la fré-
quence des mises à jours, le type de réseau permettant à l'application de les contacter,
l'exigence de cohérence (le respect de contrainte d'intégrités) entre des relations situées
sur diérentes sources ;
critères concernant les requêtes : leur type (union, star query, chain query 1 ), le nombre
de relations qu'elles impliquent, la présence d'agrégats, requête ad hoc ou prédénie.
Le tableau 2.1 présente ces critères appliqués aux applications du complexe hospitalier
(BHS) et des catalogues documentaires (Redoc).
Paramètre BHS Redoc
Nombre de sources 20 30
Type de sources chiers moteurs de
et SGBD relationnel recherche booléens
Fréquence des mises à jour journée semaine
Type de réseau MAN WAN
Exigence de cohérence non non
Type de requête star union
Nombre de relations par requête 3 30
Agrégats moyennes non
Requêtes ad-hoc oui oui
Tab. 2.1 Caractéristiques des applications BHS et Redoc.
2.3 Architecture
Nous avons, dans la section précédente, présenté des applications nécessitant l'intégration
de plusieurs sources de données. Trois architectures permettent de mettre en ÷uvre de telles
applications :
l'architecture naïve, où l'intégration des sources de données est eectuée par l'applica-
tion elle même; l'application contacte chaque source pour en extraire les données.
1. star query dénote les graphes de requêtes en forme d'étoile, et chain query dénote les graphes de requêtes
en forme de chaîne.
Utilisateur
Application
Source 1 Source 2 Source n
Fig. 2.1 Architecture naive.
l'architecture basée sur un entrepôt de données (data warehouse) : les données que
l'application utilise, sont extraites des sources de données et stockées dans une base
de données dédiée, appelée un entrepôt de données. L'application soumet des requêtes
déclaratives à l'entrepôt de données pour en extraire les données qui l'intéressent ;
l'architecture basée sur un système de médiation. L'application soumet des requêtes
déclaratives que le système de médiation évalue en contactant directement les sources
de données.
Nous détaillons ces trois architectures ci-dessous.
2.3.1 Architecture Naïve

L'application CLINIC, décrite en section 2.2.1, prend en charge l'accès aux diérentes
sources de données : elle établit les connections, envoie des requêtes Oracle ou des instructions
spéciques aux chiers AS/400 , transforme le format des données, et éventuellement les
combine pour pouvoir les présenter à l'utilisateur. L'application met ainsi en ÷uvre tout le
travail d'intégration des sources de données.
La gure 2.1 décrit l'architecture naïve des applications telles que CLINIC. L'utilisateur
interagit avec l'application qui contacte directement les sources de données (S1, à Sn sur le
schéma).
Une telle architecture a l'avantage de donner à l'application tout le contrôle sur l'accès
aux sources. Un grand nombre d'optimisations spéciques peut donc être mis en oeuvre. Les
désavantages de cette architecture sont les suivants. Premièrement, l'application doit être
reprogrammée pour pouvoir intégrer une nouvelle source de données. Deuxièmement, une
telle application prend en compte, en général, un petit nombre de requêtes prédénies; elle
ne permet pas à l'utilisateur de formuler des requêtes quelconques (requêtes ad hoc). En
résumé, une telle architecture permet de réaliser ecacement un accès prédéni à un petit
nombre de sources de données ; elle ne permet cependant pas à l'application d'évoluer.
Architecture 19
Utilisateur
Application
Entrepot
de
donnees
Extraction
Fig. 2.2 Architecture basée sur un entrepôt de données.
2.3.2 Entrepôt de données

Un entrepôt de données stocke, sous une forme intégrée, des données extraites d'un en-
semble de sources de données [58]. Les données sont extraites des sources de données, trans-
formées dans un format commun et combinée avec les données existantes dans l'entrepôt de
données. L'application analyse ces données et formule des requêtes. Par rapport à l'archi-
tecture naïve, le travail d'intégration et de traitement des requêtes n'est plus eectué par
l'application ; c'est l'entrepôt de données qui s'en charge.
La gure 2.2 décrit l'architecture d'une application utilisant un entrepôt de données.
L'utilisateur interagit avec l'application qui formule des requêtes vers l'entrepôt de données.
Celui-ci extraie, transforme et intégre les données avant de les stocker. L'extraction peut être
déclenchée par l'entrepôt de données de manière régulière (e.g., l'extraction a lieu tous les
matins), ou bien lorsque le contenu d'une source est modié. Dans le second cas, l'entrepôt de
données doit mettre en ÷uvre un mécanisme de détection des changements qui interviennent
sur les sources de données. Toutes les requêtes sont évaluées par l'entrepôt de données sans
que les sources ne soient contactées.
L'intégration des données a lieu indépendamment des requêtes. L'administrateur de l'en-
trepôt de données dénit (i) les sources qui doivent être intégrées et (ii) les données qui
doivent être extraites de chacune de ces sources. Ainsi tout le travail d'extraction des don-
nées, de transformation de format et de combinaison avec les données existantes a lieu avant
que les requêtes ne soient posées. L'évaluation des requêtes concerne uniquement les données
déjà intégrées et stockées localement dans l'entrepôt de données. Ceci a plusieurs avantages.
Tout d'abord, l'évaluation de requêtes n'a pas d'inuence sur la charge de travail des sources
de données. Réciproquement, le coût d'accès aux sources et d'intégration n'a pas a être payé
pour chaque évaluation de requêtes. Ainsi, un entrepôt de données traite ecacement des
requêtes complexes (impliquant par exemple des agrégats sur de larges collections de don-
nées). Il permet également d'implanter des techniques d'analyse de données (data mining).
De plus, la disponibilité des données n'est pas un problème lors de l'évaluation des requêtes.
Un entrepôt de données nécessite un espace de stockage important pour conserver les
données extraites et intégrées. Le coût des supports de stockage étant raisonnable, la taille de
l'entrepôt de données n'est pas véritablement un désavantage de cette architecture. D'autre
part, l'entrepôt de données doit être mis à jour pour reéter les mises à jour eectuées sur
les sources de données. Un ensemble de techniques ont été développées pour la mise à jour
d'un entrepôt de données[54]. Ces techniques peuvent être coûteuses à mettre en oeuvre,
notamment si les les sources de données sont fréquemment mises à jour et si l'application
requiert des données fraîches. Enn, le principal désavantage de cette architecture est que
certaines sources ne permettent pas l'extraction de données. En eet, prenons l'exemple d'une
source de données dans le cadre de l'application Redoc. Une telle source permet l'accès à des
références documentaires en eectuant une recherche sur le nom de l'auteur ou le titre de
l'ouvrage. Cette source ne permet pas d'accéder à toutes les références documentaires ; elle ne
permet pas non plus d'obtenir la liste des auteurs ou des titres d'ouvrage. Ainsi, il est possible
d'eectuer une recherche particulière, mais il n'est pas possible d'extraire toutes les références
d'ouvrages. Cette source ne se prête donc pas, pour des raisons techniques, à la constitution
d'un entrepôt de données. D'autres sources de données ne permettent pas l'extraction de
données pour des raisons politiques ou légales. Par exemple, dans l'application CLINIC, les
informations nominatives du dossier médical ne peuvent pas être transférées dans l'entrepôt.
2.3.3 Système de médiation

L'entrepôt de données eectue l'extraction et l'intégration de données indépendamment
des requêtes posées par l'application, ainsi les requêtes posées par l'application sont traitées
localement sur l'entrepôt de données. Une alternative est qu'un système de traitement de
requêtes contacte les sources de données lors du traitement des requêtes. Un tel système de
traitement de requête est un médiateur entre l'application et les sources de données.
Gio Wiederhold [109] a déni un cadre général pour les systèmes de médiation. Il propose
une organisation modulaire des systèmes d'informations 2 de manière à tirer parti de l'accès
à de nombreuses sources de données connectées par des réseaux rapides. La brique de base de
l'architecture modulaire proposée par Wiederhold est le médiateur. Un médiateur est chargé
des traitements permettant à l'application d'obtenir les données extraites des sources de
données. Pour cela, le médiateur encode les connaissances nécessaires aux transformations
sur les données des sources. Un médiateur peut être spécialisé pour un ensemble de sources ou
un domaine d'application. Plusieurs médiateurs peuvent être composés en une hiérarchie de
modules entre l'application et un grand nombre de sources de données. Wiederhold envisage
la dénition d'un langage pour la communication entre l'application et le médiateur 3 ; il
2. L'objectif qu'il assigne au système d'information est de fournir à l'utilisateur les informations nécessaires
à la prise de décision (support for decision making).
3. Buneman et al. [24] ont d'ailleurs fait une proposition de standardisation des langages d'accès au
Architecture 21
considère également une harmonisation des interfaces d'accès aux sources de données basée
sur les concepts des bases de données relationnelles (vues, sélection, ...).
L'infrastructure de médiateurs a pour but de rassembler les connaissances permettant
l'intégration des données dans des composants utilisables par plusieurs applications (par
opposition a l'architecture naïve où cette connaissance est encodée dans une seule applica-
tion). D'autre part, l'infrastructure de médiateurs se doit d'être modulaire par opposition à
l'entrepôt de données qui est un composant monolithique. Cette modularité doit permettre
à l'infrastructure de médiation d'évoluer facilement et notamment d'intégrer de nouvelles
sources.
Une telle infrastructure de médiation reprend et généralise un certain nombre d'idées
qui avaient notamment conduit à la dénition de systèmes de bases de données fédérés [90,
34]. Wiederhold décrit des techniques qui selon lui doivent être prises en compte pour la
dénition de médiateurs. Il cite notamment le domaine de l'intelligence articielle qui apporte
la notion de déclarativité, les capacités d'explication, et l'utilisation d'heuristiques pour
explorer de grands espaces de recherche. Il cite le domaine de la logique appliquée aux bases
de données qui permet une approche formelle des problèmes d'intégration [103]. Il cite enn
les techniques qui permettent un accès ecace aux sources de données, notamment les vues
matérialisées et l'optimisation sémantique.
Les idées présentées par Wiederhold ont été reprises dans le cadre du programme In-
telligent Integration of Information (I3) nancé par l'organisme américain DARPA [110].
Ainsi, la plupart des laboratoires de recherche travaillant dans ce domaine ont adopté une
même architecture pour leurs prototypes de système de médiation. La gure 2.3 décrit cette
architecture. A chaque source de données est associé un adaptateur (les rectangles annotés
avec un A sur la gure). Tous les adaptateurs fournissent la même interface d'accès vers les
sources de données et masquent ainsi l'hétérogénéité des sources. Le médiateur (le rectangle
annoté avec un M sur la gure) fournit un point d'entrée unique et une vue uniforme sur un
ensemble de sources de données. Médiateurs et adaptateurs sont les composants du système
de médiation. L'application soumet des requêtes déclaratives au médiateur de manière à
obtenir les données demandées par l'utilisateur.
Pour intégrer une nouvelle source de données un adaptateur doit être développé. Cet
adaptateur est ensuite enregistré auprés du médiateur. Lorsque l'application soumet une
requête, celle-ci est optimisée par le médiateur, elle est ensuite exécutée. Le moteur d'exé-
cution du médiateur envoie des sous-requêtes aux sources de données par l'intermédiaire des
adaptateurs : chaque sous-requête envoyée par le médiateur est transformée par un adapta-
teur en une requête au format de la source de données. La réponse de la source est ensuite
transformée par l'adaptateur au format du médiateur. Dans une dernière étape, le médiateur
rassemble les résultats fournis par toutes les sources de données impliquées dans la requête,
les combine et compose la réponse qu'il renvoie à l'application.
L'architecture basée sur un système de médiation présente l'avantage d'être modulaire.
L'intégration de nouvelles sources de données requiert le développement d'adaptateurs dont
médiateur.
Utilisateur
Application
A A A
Fig. 2.3 Architecture basée sur un système de médiation.
l'interface et les fonctionnalités sont précisément dénies. Un système de médiation se doit de

fournir les outils pour le développement rapide d'adaptateurs. Surtout, une architecture de
médiation permet d'intégrer des sources de données dont les capacités pour le traitement de
requêtes sont limitées. En particulier les sources de données qui ne permettent pas l'extraction
nécessaire dans le cadre des entrepôts de données peuvent être intégrées dans le cadre d'un
système de médiation.
Le principal désavantage de cette architecture est dû au fait que les sources de données
sont directement impliquées dans le traitement des requêtes. Le traitement des requêtes
entraîne des échanges sur le réseau et une charge sur les sources de données. Un système de
médiation ne peut raisonnablement traiter que des requêtes simples, n'impliquant ni un gros
volume de données transféré, ni une charge importante sur les sources de données. Il y a de
plus le risque que toutes les sources de données ne soient pas disponibles lors de l'évaluation
d'une requête.
2.3.4 Bilan
De manière à comparer les trois architectures présentées dans cette section, nous repre-
nons les critères établis dans la section précédente concernant les applications. Pour chaque
critère nous discutons dans quelle mesure l'architecture naïve, l'architecture basée sur l'en-
trepôt de données ou l'architecture basée sur un système de médiation sont adaptées.
Le tableau 2.2 décrit pour chaque critère l'adéquation des trois architectures. Lorsque
l'approche entrepôt de données est possible (i.e. la fréquences des mises à jour est faible et les
sources de données permettent toutes les extractions nécessaires), elle permet un traitement
ecace de tous types de requêtes indépendamment des caractéristiques du réseau ; elle peut
Architecture 23
Caractéristiques architecture architecture basée architecture basée
des applications naïve sur un entrepôt de données sur un système
de médiation
Nombre de sources faible indiérent indiérent
Type de sources peu hétérogènes extraction possible indiérent
Fréquence indiérente faible indiérente
des mises à jour
Type de réseau inue sur indiérent inue sur
les performances les performances
Exigence de cohérence impossible possible impossible
Requêtes ad-hoc non oui oui
Type de requête prédénies toutes union de requêtes
conjonctives
Nombre de relations faible indiérent faible pour les
par requête requêtes conjonctives
Agrégats non oui non
Tab. 2.2 Adéquation des diérentes architectures aux caractéristiques des applications.
également permettre de vérier des contraintes d'intégrité entre des relations situées sur
diérents sites [113]. L'approche naïve est, elle, dicile à mettre en oeuvre (il est préférable
que les sources à intégrer soient peu nombreuses et peu hétérogènes) et ne permet que le
traitement de requêtes prédénies.
Une application basée sur un système de médiation peut être mise en oeuvre quelles
que soient les sources de données à intégrer. Elle est cependant sensible aux caractéristiques
du réseau connectant les composants du système de médiation et les sources de données.
Il est préférable que l'application ne soumette que des requêtes conjonctives ou des unions
de requêtes conjonctives, et évite les opérations telles que les agrégats qui demandent de
manipuler les collections de données dans leur ensemble.
L'architecture de médiation est la mieux adaptée aux applications que nous avons présenté
dans l'introduction. En ce qui concerne les hôpitaux basques, la fréquence des mises à jour
et des problèmes d'administration empêchent la création et la maintenance d'un entrepôt
de données. Ils ont donc choisi de remplacer leur architecture naïve par une architecture
basée sur un système de médiation. Dans le cas des catalogues documentaires (ainsi que
pour les applications nancières ou pour le guide d'achat), certaines sources ne permettent
pas l'extraction de leur contenu. Il est donc impossible d'envisager un entrepôt de données
intégrant ces sources de données.
Il est à noter que la mise en oeuvre d'une infrastructure de médiation (comme celle d'un
entrepôt de données) nécessite que les administrateurs des sources de données acceptent que
leurs données soient intégrées par le médiateur et qu'ils acceptent la charge de travail ainsi
générée. Une forme de contrat doit donc être conclue entre le système de médiation et les
sources de données qu'il intègre.
Nous discutons dans la section suivante les systèmes de médiation existants sous forme
de prototypes de recherche et de systèmes commerciaux.
2.4 Systèmes de médiation existants
Wiederhold a introduit la notion de système de médiation [109] entre les applications
et les sources de données. Il cite Multibase comme exemple de système de médiation déjà
existant [90, 34]. Ce système permet d'intégrer diérentes bases de données autonomes.
L'émergence de l'Internet et des Intranet a permis d'envisager des systèmes de médiation
intégrant un grand nombre de sources de données relationnelles ou non, éventuellement
réparties sur un réseau à grande distance.
Nous distinguons deux catégories de systèmes de médiation : d'un côté les systèmes fédérés
dont l'objectif est l'intégration forte (permettant de formuler des requêtes et des mises à jours
sur un schéma unié) d'un petit nombre de bases de données peu hétérogènes, et d'un autre
côté, les systèmes à grande échelle dont l'objectif est de fournir un accès uniforme à un
grand nombre de sources de données fortement hétérogènes réparties sur un Intranet ou sur
l'Internet.
Pour ces deux catégories, nous présentons un ensemble de prototypes de recherche. Nous
présentons en particulier le prototype Disco que nous avons construit au sein de l'action
médiation du GIE Dyade. Nous faisons ensuite un point sur les systèmes de médiation
commerciaux disponibles sur le marché.
2.4.1 Systèmes fédérés

Un système fédéré, selon la dénition qu'en donne Sheth et Larson [89], contrôle et
coordonne la manipulation d'une collection de systèmes de gestion de bases de données
autonomes. Chacun des systèmes de base de données participant à une fédération continue
à être utilisé par un ensemble d'applications, de manière locale. Le système fédéré intègre
les bases de données locales en un ou plusieurs schémas fédérés et accepte les requêtes et les
mises à jour.
Won Kim [64] a listé les objectifs des systèmes fédérés :
respecter l'autonomie des bases de données locales ;

permettre une manipulation uniforme de toutes les données intégrées ;
supporter les transactions contenant des opérations de lecture et de mises à jour sur
l'ensemble des bases de la fédération ;
fournir tous les services d'un système de gestion de bases de données : dénition de
schéma, gestion des transactions, traitement des requêtes, interface interactive et ap-
plicative, outils d'administration, ...
orir des performances qui approchent celles des systèmes de bases de données distri-
buées.
Systèmes de médiation existants 25
Nous présentons ci-dessous les caractéristiques de deux prototypes de recherche : Mul-
tibase et IRO-DB. Nous discutons de manière plus large les problèmes attaqués par les
systèmes fédérés en section 2.4.4.
2.4.1.1 Multibase
Multibase [90, 68, 34] a été développé par la division Advanced Information Technology de
Computer Corporation of America 4. L'objectif du projet était de permettre l'interrogation de
bases de données existantes, réparties et hétérogènes, via un schéma global unié et un seul
langage de requête. Multibase a été utilisé dans une application de conception et production
assistée par ordinateur et dans une application de soutien logistique [98].
Le système a été déni avec les objectifs de conception suivants: (1) être général et
indépendant d'une application particulière, (2) être facilement étendu, et (3) ne pas nécessiter
de modications sur les bases de données existantes pour être mis en oeuvre. Le modèle de
données choisi est le modèle fonctionnel, et le langage de requêtes est DAPLEX.
L'architecture de Multibase correspond exactement à l'architecture des systèmes de mé-
diation, telle que Wiederhold l'a dénie. Un gestionnaire de requête global est chargé de
l'intégration des données et du traitement des requêtes (c'est le rôle du médiateur), et des
interfaces d'accès aux sources sont chargées des transformations requises pour l'intégration
d'une source particulière. L'interface entre ces deux types de composants est xée : le ges-
tionnaire de requête global envoie des sous-requêtes vers les interfaces d'accès aux sources
exprimées en DAPLEX, les données correspondantes lui sont retournées dans un format
commun à toutes les interfaces d'accès aux sources.
Les deux points essentiels dans Multibase sont l'intégration de schémas et le traitement
des requêtes. Trois niveaux de schémas sont dénis. Aux schémas locaux exprimés dans
des modèles de données diérents sont associés des schémas d'intégration exprimés, eux,
dans le modèle fonctionnel. Le schéma global fournit une vue uniée des diérents schémas
d'intégration. Des mises en correspondances ont été dénies entre le modèle fonctionnel et les
modèles relationnels, CODASYL et chier structuré pour permettre le passage des schémas
locaux au schéma d'intégration. La dénition du schéma global nécessite que soient fusionnés
les diérents schémas d'intégration. Cette fusion est implanté par un mécanisme de vues.
Les inconsistances éventuelles entre schémas d'intégration sont résolues grâce à un schéma
auxiliaire (qui dénit des données stockées par le gestionnaire de requête global).
Le traitement des requêtes pose des problèmes d'optimisation au niveau des deux types
de composants du système. Au niveau des interfaces d'accès aux sources, les sous-requêtes
exprimées en DAPLEX doivent être transformées en des requêtes vers les bases de données
locales. Pour être ecaces ces requêtes doivent prendre en compte les structures d'accès
fournies par les sources de données (CODASYL notamment). Au niveau du gestionnaire de
requête global, le problème est (1) de n'envoyer aux interfaces d'accès aux sources que des
sous-requêtes qu'elles puissent traiter et (2) de gérer les diérentes possibilités de transfert
4. Depuis rachetée par Xerox [98]
de données entre les interfaces d'accès aux sources et le gestionnaire de requêtes global.
Un langage est fourni à l'administrateur du système pour décrire les capacités de traite-
ment des diérentes sources de données (par exemple le cas où les opérations arithmétiques
ne sont pas supportées). Chaque sous-requête destinée à une source de données est ensuite
réécrite pour garantir que seules toutes les sous-requêtes qui sont envoyées peuvent être trai-
tées. Les traitements qui ne peuvent pas être eectués par la source sont pris en charge par
le gestionnaire de requête global.
Les stratégies de transfert de données prennent en compte le coût des opérations sur
les diérents sites, et les capacités de ces sites (y compris les sources de données) à créer
des relations temporaires pour matérialiser les données extraites des sources de données et
eectuer des traitements sur ces données.
Multibase était initialement destiné à intégrer des bases de données relationnelles, des
bases de données CODASYL, et des chiers structurés. Des interfaces d'accès aux sources
locales ont été construites pour plusieurs bases de données locales dont ORACLE et Focus.
L'architecture de Multibase permet d'intégrer d'autres sources de données. Des composants
ont d'ailleurs été dénis pour faciliter la construction de nouvelles interfaces d'accès aux
sources locales.
La mise en oeuvre de Multibase a montré les limitations du modèle fonctionnel pour
l'intégration des bases de données locales. Des outils pour l'administration du schéma intégré
sont apparus nécessaires.
2.4.1.2 IRO-DB
Le système IRO-DB [47, 43] a été développé dans le cadre du projet Européen ESPRIT-
P8929. L'objectif du projet était de construire un système fédéré permettant de formuler
requêtes et mises à jour sur des bases de données relationnelles et orientées objet. Le système
a notamment permis d'intégrer des bases INGRES et ONTOS dans le cadre d'une application
de production assistée par ordinateur (Computer Integrated Manufacturing) [85].
La caractéristique principale du système IRO-DB est qu'il met en oeuvre le standard
ODMG'93 [27]. Le schéma fédéré ainsi que les schémas locaux exportés sont exprimés dans le
modèle de données objet de l'ODMG. Les données exportées par les bases de données locales
sont considérées par le système comme des objets. Le langage OML permet de manipuler
ces objets ; les requêtes sont exprimées en OQL.
L'architecture d'IRO-DB est décomposée en trois couches. La couche locale (local layer)
adapte les bases de données relationnelles ou orientées objet, appelées bases locales, au
standard ODMG. La couche de communication (communication layer) transfère les sous-
requêtes OQL destinées aux bases locales et les réponses que celles-ci fournissent. La couche
d'interopérabilité (interoperable layer) permet l'intégration de données, le traitement des
requêtes et la gestion des transactions globales.
Un des problèmes principaux de la couche interopérable est de permettre à l'application
de manipuler et de référencer les objets exportés par les diérentes bases de données intégrées.
Des mécanismes de mise en correspondance entre références globales et locales sont donc mis
en oeuvre ainsi que des mécanismes de caches d'objets globaux [43].
L'intégration de données consiste à dénir une vue homogène sur plusieurs schémas au
format ODMG exportés par la couche locale. Un outil graphique, l'Integrator Workbench,
aide l'administrateur du système à identier les parties communes à plusieurs schémas et à
dénir les transformations entre schémas locaux et schémas intégrés.
Le choix du modèle ODMG permettait de surmonter les limitations identiées par Mul-
tibase. Ce choix, eectué en 1993, a cependant entraîné un gros eort de développement
pour la couche interoperable [40]. De plus, ce standard étant supporté par peu de sources de
données, le développement des composants de la couche locale s'est également avéré coûteux.
2.4.2 Systèmes à grande échelle

L'émergence d'Internet et des Intranet a remis en cause certaines des hypothèses faites
par les systèmes fédérés. Cela à conduit à la dénition de systèmes de médiation à grande
échelle dont les objectifs sont un peu diérents des systèmes fédérés.
Tout d'abord un grand nombre de sources de données peut être intégré ; il est donc im-
portant que l'intégration de nouvelles sources soit facile. Tous les systèmes à grande échelle
adoptent l'architecture des systèmes de médiation proposée par Wiederhold [109] : intégrer
une nouvelle source de données conduit à implanter un nouvel adaptateur et à le rendre
accessible par le médiateur. Par ailleurs, le schéma global apparaît comme une limite à l'évo-
lution des systèmes de médiation [101]. Les systèmes à grande échelle permettent d'accéder
aux relations rendues accessibles par les adaptateurs sans exiger qu'un schéma global soit
déni.
Internet et Intranet permettent de contacter des sources de données dépassant largement
le cadre des bases de données (relationnelles ou orientées objet). Il est par exemple important
de pouvoir intégrer des moteurs de recherche du WWW dans un système de médiation [40].
Pour intégrer un moteur de recherche qui indexe des documents HTML et permet la recherche
par mot-clés, (1) le médiateur doit prendre en compte ses capacités limités pour le traitement
des requêtes, et (2) l'adaptateur doit extraire les données à partir des documents HTML.
Enn, les sources de données à intégrer peuvent être réparties sur un réseau à grande
distance ce qui implique des problèmes accrus de latence dans les communications et de
disponibilité des sources de données.
Nous décrivons maintenant trois prototypes de recherche qui prennent en compte ces
nouvelles exigences : Information Manifold, Tsimmis et Disco. Nous discutons de manière
plus large les problèmes attaqués par les systèmes à grande échelle en section 2.4.4.
2.4.2.1 Information Manifold
Information Manifold [66] a été déni par AT&T Bell Laboratories. Ce projet a essen-
tiellement permis de démontrer l'intérêt d'une approche descendante pour l'intégration de
données dans les systèmes à grande échelle.
L'approche descendante d'Information Manifold peut être dénie comme suit. Un mé-
diateur exporte un schéma global, qui est déni par un ensemble de prédicats. Information
Manifold utilise un modèle issu de la logique de description et des règles de Horn pour re-
présenter le schéma global 5. Une application peut formuler des requêtes conjonctives basées
sur ces prédicats. En reprenant l'exemple des hôpitaux basques, le schéma global pourrait
être:
patient(PatientId, Nom, Prenom, Adresse, Sejour).

radiolo(RadioloId, Date, Description, Image).
chirurg(ChirurgId, Statut, Description).
map(PatientId, RadioloId, ChirurgId).
où map permet de mettre en correspondance les identiants spéciques à chaque relation
globale.
Chaque adaptateur associé à une source de données exporte une ou plusieurs vues. Cha-
cune de ces vues est exprimée en fonction des prédicats du schéma global. Par exemple
l'adaptateur associé à la source d'administration exporte la vue:
vue_admin(AdminId, Nom, Prenom, Adresse, Sejour) =>

patient(PatientId, Nom, Prenom, Adresse, Sejour).
L'ajout d'une nouvelle source demande (i) l'écriture de l'adaptateur associé et (ii) la
dénition, au niveau du médiateur, de la vue exportée par cet adaptateur en fonction des
prédicats du schéma global. L'avantage de l'approche descendante est que le schéma global
n'est pas modié par l'ajout d'un nouvel adaptateur. Il n'est, par contre, pas possible de
dénir que la combinaison de deux vues dénit un prédicat global ; ceci est une contrainte,
les relations auxilliaires telles que map dans notre exemple doivent obligatoirement apparaître
dans le schéma global.
Les requêtes formulées par l'application sont exprimées sur le schéma global. Le nom des
patients qui attendent d'être opérés peut ainsi être obtenu avec la requête suivante :
patient(PatientId, Nom, _, _, _),

chirurg(ChirurgId, 'attente', _),
map(PatientId, _, ChirurgId) =>
requête(Nom).
5. Datalog sans récursion représente une restriction de ce langage [103].
Le médiateur réécrit cette requête en utilisant les vues exportées par les adaptateurs. L'al-
gorithme d'optimisation garantit que le nombre minimum de vues nécessaires à l'évaluation
de la requête est utilisé [66]. La requête réécrite est dans notre exemple :
vue_admin(AdminId, Nom, Prenom, Adresse, Sejour),
vue_chiru(ChiruId, 'attente', _),
map(PatientId, AdminId, _, ChiruId)
=>requête(Nom).
L'algorithme de réécriture ne garantit pas que la requête obtenue par réécriture est équi-
valente à la requête initiale, il garantit que la requête obtenue est la requête maximum
contenue dans la requête initiale (maximally contained query). Il se peut en eet que les
sources enregistrées auprés d'Information Manifold ne permettent pas de couvrir entière-
ment le schéma global (e.g., le service de radiologie fournit uniquement les radios eectuées
lors du mois écoulé alors que le schéma global exporte toutes les radios eectuées). La ré-
ponse fournie par Information Manifold est donc toujours un sous-ensemble de la réponse
exacte à la requête posée sur le schéma global.
2.4.2.2 Tsimmis
Tsimmis [46] est un projet de l'université de Stanford. Son objectif principal est d'étudier
les techniques qui permettent d'intégrer rapidement des sources de données structurées ou
semi-structurées 6 .
Un modèle de données semi-structuré a été déni, OEM (Object Exchange Model), pour
l'intégration des données au niveau du médiateur. Ce modèle organise les données en objets,
atomiques ou complexes, formés d'un label, d'une valeur et éventuellement d'un type et d'un
identiant unique [74]. Le modèle OEM est dit semi-structuré car chaque objet contient la
description de son type. Il n'y a donc pas de schéma décrivant les données OEM.
Médiateurs et adaptateurs exportent un ou plusieurs objets racines qui sont composés
de sous-objets. Dans le cadre de l'application des hôpitaux basques, l'adaptateur associé à
la source d'administration exporte un objet racine qui a la forme suivante (chaque paire
label, valeur est encadré par des crochets < >, les ensembles de valeurs sont encadrés par des
accolades { }, les majuscules dénotent des variables et les minuscules des constantes) :
<admin, {<id I><nom N><prenom P><adresse A><sejour S>}>
Les objets OEM sont manipulés par le langage MSL (Mediator Specication Language).
C'est un langage de règles dont la tête et le corps sont composés d'objets OEM.
A chaque source de données est associé un adaptateur. Une architecture commune et
un ensemble de composants réutilisables ont été dénis pour faciliter le développement des
6. Les données semi-structurées sont des données sans schéma xé ou uniforme [103].
adaptateurs. Le composant principal d'un adaptateur est le converter qui se charge de la
transformation des requêtes du format médiateur au format particulier d'une source. Un
langage, QDTL (Query Description and Transformation Language), permet de congurer
ce composant, i.e. dénir les requêtes qu'accepte un adaptateur et, pour chacune d'elles, un
ensemble d'actions qui permettent de générer les commandes à envoyer à la source. Dans le
cadre de l'application des hôpitaux basques, l'adaptateur associé à la source d'administra-
tion a pour nom admin_source et il accepte toutes les sous-requêtes concernant les objets
OEM de type admin (dénis ci-dessus). En MSL, ces sous-requêtes s'expriment comme suit
(l'astérisque devant la variable dans la tête de la requête indique que tous les sous-objets
sont retournés avec l'objet racine) :
*Admin :- Admin:<admin, {<id I><nom N><prenom P><adresse A><sejour S>}>
Le médiateur exporte un ensemble de vues utilisateurs exprimé en fonction des requêtes

acceptées par les adaptateurs [74]. Ces vues sont dénies dans le langage MSL. En reprenant
l'exemple de l'application des hôpitaux basques, les vues utilisateurs suivantes sont dénies :
<patient, {<patientId PId><nom N><prenom P><adresse A><sejour S>}> :-

<admin, {<id AId><nom N><prenom P><adresse A><sejourS>}>@admin_source,
<map, {<patientId PId><adminId AId>}>.
<radiolo, {<patientId PId><date Da><description De><image I>}> :-
<radio, {<radioId RId><date Da><description De><image I>}>@radio_source,
<map, {<patientId PId><radioId RId>}>.
<chirurg, {<patientId PId><statut S><description D>}> :-
<chiru, {<chiruId RId><statut S><description D>}>@chiru_source,
<map, {<patientId PId><chiruId RId>}>.
où map dénote un ensemble d'objets OEM stocké sur le médiateur et qui permet de mettre
en correspondance les identiants des diérentes sources de données.
Ajouter une nouvelle source de données nécessite (1) le développement et la conguration
d'un adaptateur et (2) la dénition dans le médiateur d'une nouvelle vue utilisateur ce qui
requiert une phase de compilation du schéma au niveau du médiateur.
L'application exprime des requêtes sur les vues utilisateurs. Dans notre exemple, le nom
des patients qui attendent d'être opérés peut être obtenu avec la requête suivante :
<réponse, {<nom N>}> :-

<patient, {<patientId PId><nom N>}>,
<chirurg, {<patientId PId><statut 'attente'>}>.
Tsimmis adopte une approche ascendante pour l'intégration de données : les vues expor-
tées par le médiateur sont dénies en fonction des vues exportées par les sources de données.
2.4.2.3 Disco
Nous avons développé Disco [101, 100] dans le contexte de l'action Médiation du GIE
Dyade. L'objectif est d'étudier les problèmes de déploiement d'un système à grande échelle.
Disco utilise le modèle relationnel : le médiateur accepte des requêtes conjonctives et
des unions de requêtes conjonctives exprimées en SQL ; chaque adaptateur exporte une vue
relationnelle de la source de données qui lui est associée. Nous avons développé des adapta-
teurs vers JDBC, Lotus Notes, des moteurs de recherche du WWW, les chiers structurés
AS/400. Le modèle relationnel s'est avéré susant dans le cadre des applications que nous
avons développées.
Nous avons déni une architecture commune à tous les adaptateurs, ainsi qu'un ensemble
de composants réutilisables et un atelier de construction d'adaptateurs. Un brevet est en
cours de dépôt concernant l'assemblage et la conguration des composants d'un adaptateur.
Un adaptateur exporte un schéma relationnel ainsi qu'une description de ses capacités
de traitement de requête [62] et des éléments concernant le modèle de coût [80]. Dans le
cadre de l'exemple des hôpitaux basques, le schéma exporté par l'adaptateur associé au site
administratif est le suivant:
CREATE TABLE admin (
id INT,
nom CHAR(30),
prenom CHAR(30),
adresse CHAR(60),
sejour INT
);
Les sous-requêtes envoyées par le médiateur aux adaptateurs sont fournies sous forme d'arbres
d'opérateurs algébriques. Chaque adaptateur transforme cet arbre d'opérateurs algébriques
en des appels vers la source de données à laquelle il est associé.
Pour enregistrer un adaptateur, l'administrateur du médiateur doit envoyer une com-
mande spécique au médiateur à travers l'interface JDBC:
INSERT WRAPPER
VALUES ('disco:adminWrapper');
Cette commande indique au médiateur qu'il doit charger dynamiquement l'adaptateur ad-
minWrapper. Une fois l'adaptateur chargé, le médiateur récupère les informations exportées
par l'adaptateur concernant le schéma, les capacités de traitement de requêtes et le modèle
de coût.
L'application peut exprimer des requêtes, via une interface JDBC, sur (a) les tables
exportées par les adaptateurs, ou (b) sur des tables crées sur le médiateur ou (c) sur des
vues qui peuvent être dénies en fonctions des tables et des vues déjà existantes. Dans notre
exemple, le nom des patients qui attendent d'être opérés peut être obtenu avec la requête
suivante (map est une table maintenue par le médiateur):
SELECT nom
FROM admin, map, chirur
WHERE admin.id = map.aid
AND chiru.id = map.cid
AND chiru.statut = 'attente';
Nous avons mis en oeuvre Disco dans le cadre de l'application de catalogue documentaire
Redoc (décrite en section 2.2.2).
2.4.3 Systèmes commerciaux

Dans le cadre du projet MIRO-Web [40], un ensemble de systèmes commerciaux permet-
tant l'accès à des sources de données hétérogènes et réparties ont été identiés [76]. Deux
catégories de produits apparaissent : les passerelles et les systèmes fédérés.
Une passerelle (gateway), par exemple Transport Gateway d'Oracle [82], permet d'établir
une connexion point à point entre l'application et une source de donnée. Ainsi plusieurs
sources de données diérentes (en général des SGBD relationnels ou des chiers structurés)
peuvent être accédées de manière uniforme. Une passerelle ne fournit pas par contre un
point d'accès unique à plusieurs sources de données. L'application doit contacter chaque
source individuellement.
Les systèmes fédérés ont des objectifs comparables aux prototypes de recherche étudiés en
section 2.4.1. DataJoiner d'IBM [56, 105], EDA d'Information Builders [21, 93] et Interviso
de Data Integration [57, 97] sont des systèmes qui permettent requêtes et mises à jour sur
diérentes sources de données autonomes fédérées par un schéma global.
DataJoiner est un produit d'IBM qui étend DB2 Universal Server [105, 26]. Son objec-
tif est de fournir un accès transparent à un ensemble de bases de données relationnelles.
DataJoiner fournit un service de nommage pour éviter les conits de noms entre les rela-
tions des diérentes bases de données intégrées. DataJoiner fournit également un service de
mise en correspondance des types de données et de fonctions. DataJoiner se charge enn
de l'optimisation des requêtes et décide notamment les portions des requêtes qui doivent
être traitées par les bases de données intégrées et les portions qui doivent être traitées par
DataJoiner lui-même en fonction d'un modèle de coût. IBM prévoit d'incorporer les résultats
de Garlic 7 dans la ligne de produit DB2 pour prendre en compte les sources de données non
relationnelles [26].
EDA/SQL d'Information Builders permet d'intégrer des sources de données fortement
hétérogènes. Il permet notamment d'accéder à des données stockées dans des outils bureau-
7. Garlic est un système à grande échelle qui a été développé à IBM Almaden [7, 25]
tiques. En eet, les adaptateurs fournis avec le système sont basés sur un outil de génération
de rapports (Focus) qui est capable de traiter ces types de données. EDA/SQl permet es-
sentiellement l'accès aux sources de données ; les mises à jour ne sont autorisées que vers les
bases de données relationnelles.
Une étude mené chez Daimler-Benz [35] a comparé la passerelle d'Oracle aux systèmes
fédérés DataJoiner et EDA. Dans le cadre d'un environnement pour la conception de mo-
teurs, plusieurs bases de données relationnelles (DB2 et ORACLE) réparties sur un Intranet
doivent être intégrées. Il ressort notamment de cette étude que la qualité de l'optimiseur
de requêtes est un facteur déterminant pour les performances. Comme les sources de don-
nées sont intégrées par des mécanismes de vues, chaque requête posée par l'utilisateur sur
le schéma global implique des sélections et des jointures entre les sources de données. De ce
point de vue, un système fédéré qui est capable de décider quelles sous-requêtes envoyer aux
sources de données et quelles sous-requêtes eectuer lui-même a l'avantage sur une passerelle
qui renvoie ces décisions à l'application.
Infomaster [39] d'Epistemics et Junglee [60] sont des systèmes commerciaux dont les ob-
jectifs sont comparables à ceux des systèmes à grande échelle. Le produit Infomaster dérive
directement du projet du même nom mené à Stanford. L'intégration des données est réali-
sée avec une approche descendante, similaire à celle décrite pour Information Manifold. Des
adaptateurs génériques ont été dénis vers des sources Z39.50, des bases SQL accessibles via
ODBC. Pour les serveurs WWW, des adaptateurs spéciques doivent être développés. Info-
master a notamment été utilisé pour intégrer des petites annonces concernant des locations
de logement.
Junglee ne commercialise pas de produit mais utilise un système à grande échelle pour
mettre en place des applications, notamment le guide d'achats décrit en section 2.2.3.2. Ce
système permet d'intégrer des sources de données telles que les moteurs de recherche sur
le WWW dont les capacités de traitement de requête sont limitées et qui exportent des
données faiblement structurées (des documents par exemple). Les adaptateurs fournissent
une vue relationnelle des sources de données. Ces vues sont accessibles directement depuis
l'interface JDBC du médiateur. Ainsi, le médiateur peut se conduire comme une passerelle
vers les sources de données. Le médiateur permet également de dénir des vues qui forment
un schéma global sur lequel des requêtes peuvent être exprimées. Dans les exemples fournis,
seules des requêtes conjonctives sont exprimées.
2.4.4 Problématique associée aux systèmes de médiation

Nous donnons ici une vue d'ensemble des problèmes qui se posent pour dénir un système
de médiation. Nous étudions les trois principaux aspects du traitement de requête dans un
système de médiation : l'intégration des sources de données, l'optimisation des requêtes et
leur exécution.
2.4.4.1 Intégration des sources de données
L'architecture des systèmes de médiation, présentée en section 2.3.3, conduit à considérer
deux étapes dans l'intégration des sources de données. Dans un premier temps, un adaptateur
doit être associé à une source de données, dans un deuxième temps le médiateur intègre
les diérentes sources et en donne éventuellement une vue uniée. Nous étudions ces deux
aspects ci-dessous.
Développement d'adaptateurs A chaque source de données est associée un adaptateur.

Un problème essentiel pour le déploiement d'un système de médiation est de développer
rapidement et ecacement les adaptateurs correspondant aux diérentes sources de données.
La maintenance et l'évolution de ces adaptateurs sont également des problèmes importants.
Les systèmes fédérés considèrent essentiellement l'intégration de systèmes de bases de
données hétérogènes. Ils font l'hypothèse que toutes les sources de données fournissent des
services de traitement de requêtes évolués. Les travaux concernant ces systèmes se sont
concentrés sur la mise en correspondance des diérents modèles de données (schema trans-
lation) et des langages de requête qui leur sont associés (command transformation) [89].
Les systèmes à grande échelle considèrent eux l'intégration de sources de données dont
les capacités de traitement de requêtes sont éventuellement limitées. Dans ce contexte, une
source de données n'exporte pas forcément de schéma et les techniques développées pour
les systèmes fédérés ne peuvent pas être systèmatiquement réutilisées. Le problème est de
réduire au minimum les développements spéciques qui doivent être réalisés pour mettre en
oeuvre un adaptateur particulier.
Bien que chaque adaptateur soit spécique à une source de données, tous les adaptateurs
sont chargés de (1) transformer les requêtes qui leur sont transmises par le médiateur en des
appels vers la source de données, et de (2) transformer les réponses fournies par la source de
données en un format accepté par le médiateur.
Tsimmis [83], Disco [2], Coin [20] 8 et Garlic [86] ont chacun déni une architecture au-
tour de ces deux fonctions essentielles. De telles architectures permettent d'identier les
composants d'un adaptateur. Il est ainsi possible de distinguer les composants qui peuvent
être réutilisés dans un ensemble d'adaptateurs et les composants qui doivent être développés
pour les besoins spéciques d'une source de données.
Le composant des adaptateurs qui a reçu le plus d'attention est celui qui permet d'extraire
des données structurées à partir d'une source de données semi-structurée [94]. Ce composant
est en particulier nécessaire pour intégrer un site WWW dans un système de médiation car
il extrait les données structurées contenues dans des pages HTML. Les techniques proposées
reposent toutes sur des mécanismes de reconnaissance de chaîne de caractères (string pattern
matching) [10].
8. Coin a été développé à Sloan School of Management, MIT [8, 18]

Intégration de schéma dans le médiateur Sheth et Larson [89] distinguent les systèmes
fédérés fortement intégrés (tight-coupling) et les systèmes faiblement intégrés (loose-coupling).
Les systèmes fortement intégrés permettent aux applications de formuler leurs requêtes sur
un schéma global unié. Les schémas exportés par les diérentes sources de données sont ainsi
intégrées en un schéma global unique. La dénition du schéma global demande d'une part
l'analyse et la comparaison des diérents schémas et d'autre part la résolution des conits
éventuels [65]. L'approche descendante pour l'intégration des sources de données, décrite
pour Information Manifold en section 2.4.2.1, permet de dénir a priori un schéma global
et donc d'éviter les problèmes de réconciliation entre les schémas des diérentes sources de
données.
Dénir un schéma global est une tâche dicile. C'est une contrainte forte qui limite
les capacités du système à évoluer et à intégrer de nouvelles sources [101]. Les systèmes
faiblement intégrés n'exigent pas la dénition d'un schéma global et laissent aux applications
la responsabilité de résoudre les éventuels conits sémantiques entre les schémas exportés
par le médiateur. C'est notamment le cas de Disco, où il sut d'enregistrer un adaptateur
pour pouvoir exprimer des requêtes concernant le schéma qu'il exporte. Tsimmis ne requiert
pas non plus de schéma global, il sut de dénir une vue utilisateur pour intégrer une
nouvelle source de données. Ces deux systèmes permettent d'intégrer simplement de nouvelles
sources de données, ils n'apportent par contre aucun support concernant d'éventuels conits
sémantiques.
Coin [19] propose une approche déclarative pour la résolution des conits sémantiques
au niveau du médiateur. A chaque schéma, ainsi qu'à l'application qui formule une requête,
est associé un contexte. Les requêtes sont exprimées par l'application sans tenir compte
des conits sémantiques éventuels. Le médiateur utilise les informations contenues dans les
contextes pour réécrire les requêtes en résolvant les conits.
Diérents modèles de données ont été utilisés pour représenter les données intégrées au
niveau du médiateur. Multibase utilise un modèle fonctionnel ; IRO-DB, Pegasus 9 et Garlic
utilisent un modèle orienté objet ; Disco et Coin utilisent le modèle relationnel ; Information
Manifold et SIMS 10 utilisent des modèles issus de la logique de description ; Tsimmis intro-
duit un modèle semi-structuré. Tous ces modèles fournissent des mécanismes de dénition de
vue et permettent ainsi la dénition d'un schéma global. Le modèle orienté objet (qui peut
être considéré comme une évolution du modèle fonctionnel) est particulièrement bien adapté
à l'intégration de données de types très diérents (des images par exemple [25]) . Les mo-
dèles issus de la logique de description permettent eux de dénir des ontologies [108]11 pour
représenter le schéma global unié dans un domaine particulier. Ces modèles sont lourds et
complexes à mettre en oeuvre pour de nombreuses applications [40]. Le modèle relationnel
est lui plutôt simple ; le pouvoir d'expression d'un langage de requête relationnel semble être
cependant satisfaisant pour la plupart des applications [81]. Ce modèle est par contre limité
aux types de données alphanumériques. Les modèles de données précédants demandent que
9. Pegasus a été développé à Hewlett-Packard Laboratories [88].
10. SIMS a été développé par Information Science Institute, University of Southern California [51, 5].
11. Une ontologie est constituée d'une hiérarchie de concepts se rapportant à un domaine particulier et de
relations entre ces concepts.
toutes les données d'une même collection se conforment à un schéma xé ; un modèle de
données semi-structuré tel qu'OEM (déni dans Tsimmis, cf section 2.4.2.2) introduit plus
de exibilité dans le sens où il n'impose pas de schéma aux données d'une même collec-
tion. Le traitement de requêtes doit encore être adapté aux caractéristiques des données
semi-structurées ; c'est un axe de recherche très actif.
2.4.4.2 Optimisation des requêtes

Le principal problème d'optimisation des requêtes dans un système de médiation est le
découpage d'un requête en sous-requêtes destinées aux sources de données. L'optimiseur doit
décider quelle est la part du travail qui doit être eectuée par les sources de données et quelle
est la part du travail qui doit être eectuée par le médiateur : ce problème est particulièrement
aigu dans les systèmes à grande échelle qui intègrent des sources de données avec des capacités
de traitement de requêtes variées. Le système de médiation doit (1) prendre en compte les
capacités limitées de certaines sources de données pour dénir les sous-requêtes valides et
(2) choisir la combinaison de sous-requêtes la moins coûteuse.
Les capacités limités d'une source sont prises en compte dans les diérents systèmes à
grande échelle. Dans Garlic [53, 86], les adaptateurs sont intégrés au processus de construction
du plan d'exécution. Un plan d'exécution est construit de manière ascendante en appliquant
un certain nombre de règles de production. Ces règles (STrategy Alternative Rules utilisées
dans DB2) transforment une description du travail à faire (sous forme de prédicat à appli-
quer sur un ou plusieurs plan d'exécutions) en un plan d'exécution auquel sont associées
des paramètres (properties), qui décrivent notamment les relations utilisées, les prédicats
appliqués, les sources de données contactées ou encore le fait que ce plan soit matérialisé
ou non. L'optimiseur de Garlic fournit à chaque adaptateur une description du travail le
concernant. L'adaptateur retourne un ou plusieurs plans d'exécution qu'il peut traiter mais
qui ne couvrent pas forcément tout le travail qui lui était proposé. En fonction des propriétés
des plans qui lui sont retournés, l'optimiseur compense les capacités limitées de certaines
sources en reportant sur le médiateur le travail que celles-ci ne peuvent pas eectuer.
Dans Information Manifold [66] et Tsimmis [74], chaque adaptateur décrit les capacités
de traitement de la source à laquelle il est associé. A chaque vue exportée par un adaptateur
correspond une description des capacités de traitement. Il est ainsi possible d'exprimer le
type de sélections acceptées sur cette vue, ainsi que les attributs qui doivent obligatoirement
être instanciés lorsque cette vue est utilisée. L'optimiseur prend en compte ces descriptions
pour pousser les sélections et ordonner les jointures (des opérateurs de bind join 12 sont
utilisés lorsqu'un attribut de la relation intérieure doit obligatoirement être instancié).
La solution initialement proposée dans Disco [62] consiste à spécier, pour chaque adapta-
teur, les opérateurs algébriques acceptés (scan, select, project, join) ainsi qu'une grammaire
qui décrit les arbres d'opérateurs valides. L'optimiseur utilise cette grammaire pour véri-
12. Un bind join, ou dependant join, est une boucle imbriquée où le médiateur passe des résultats inter-
médiaires (correspondant aux valeurs d'un prédicat de jointure) de la relation extérieure vers la relation
intérieure [53, 86].
er que les plans d'exécution qu'il génère contiennent des sous-requêtes que les adaptateurs
acceptent.
La prise en compte des capacités limités des sources permet à l'optimiseur de garantir que
les plans d'exécution générés sont acceptés par les adaptateurs. Un modèle de coût adapté
lui permet de choisir le plan d'exécution optimal. Li [73] propose un modèle de coût très
simple basé sur l'hypothèse que les interactions avec les sources de données sont les éléments
de coût dominant. Dans ce modèle simple, le coût d'un plan d'exécution est le nombre de
sous-requêtes envoyées vers les sources de données.
Un modèle de coût plus évolué doit prendre en compte les traitements eectués sur le
médiateur, les communications et les traitements eectués sur les sources de données [53].
Dénir un tel modèle de coût pose essentiellement deux problèmes. Il s'agit, d'une part, de
prendre en compte les variations dans le coût des communications d'un réseau Intranet ou
Internet : le coût des communications dans de tels réseaux varie signicativement selon le
moment où les transferts sont eectués. Il s'agit, d'autre part, de prendre en compte les
coûts de traitements eectués par les sources de données et les adapteurs qui leurs sont asso-
ciés. Ceci est particulièrement dicile car certaines sources n'exportent pas d'informations
concernant leur modèle de coût.
Hermes [1] 13 propose une solution à ces deux problèmes. Le médiateur enregistre des
informations de coût pour chaque sous-requête envoyée à une source de données et les réutilise
pour estimer le coût des nouvelles requêtes. Lorsque le médiateur envoie une sous-requête
à une source de données, il enregistre l'heure à laquelle le transfert a lieu et un certain
nombre d'informations de coût telles que le temps nécessaire pour obtenir le premier tuple,
le temps pour obtenir tous les tuples ou le nombre de tuples obtenus. Pour estimer le coût
d'une nouvelle requête, le médiateur retient la moyenne des coûts enregistrés pour les sous-
requêtes déjà posées qui se rapprochent le plus de la requête courante.
Pegasus [37] et IRO-DB [47] proposent un modèle de coût générique, pour les bases
de données relationnelles et orientées objet respectivement, ainsi qu'une procédure (dite de
calibration) pour obtenir une spécialisation de ce modèle valable pour un type de base de
données. Ce modèle générique, une fois instancié, permet d'estimer le coût des traitements
eectués sur une famille de source de données. Cette approche est ecace pour les bases
de données relationnelles ou orientés objet. Il est possible de calibrer une base Oracle par
exemple et de réutiliser le modèle de coût obtenu pour toutes les bases Oracles intégrées
par le système de médiation. Il semble dicile d'étendre cette approche à toutes les familles
de sources de données. Il est par exemple peu probable que le modèle de coût obtenu en
calibrant un moteur de recherche du WWW soit adapté à une autre source de données de
ce type.
Disco [80] génère un modèle de coût pour chaque source de données en intégrant à un
modèle générique les informations de coûts, éventuellement partielles, qu'exporte chaque
adaptateur. Cette solution a l'avantage d'être exible car elle permet au développeur d'adap-
tateur de ne spécier qu'une portion du modèle de coût. Dans Garlic [86] au contraire chaque
13. Hermes a été développé à l'Université du Maryland, College park [9].

adaptateur doit fournir un modèle de coût complet. Cette solution demande plus d'eort au
développeur d'adaptateur ; elle ore en contrepartie un modèle de coût plus précis à l'opti-
miseur.
2.4.4.3 Exécution des requêtes

L'exécution d'une requête dans un système de médiation requiert l'envoi de sous-requêtes
vers les sources de données. Pour construire la réponse à une requête, le système de médiation
doit contacter toutes les sources de données impliquées dans cette requête. Ceci pose tout
d'abord un problème de performance : contacter une source de données distante est générale-
ment une opération coûteuse. Le temps de réponse du système doit pouvoir être amélioré en
réutilisant des données déjà obtenues et en évitant ainsi un transfert sur le réseau pendant
l'exécution d'une requête.
Les techniques de gestion de cache permettent traditionnellement de répondre à ce pro-
blème de performance. Dans le contexte d'un système de médiation, les données qui peuvent
être conservées dans un cache sont les réponses aux requêtes. Les données d'un tel cache,
parfois appelé cache sémantique, peuvent être considérées comme des vues matérialisées. Le
problème dans ce contexte est double. Premièrement le médiateur doit gérer le contenu de
son cache ; il doit notamment décider quelles réponses il stocke, et quelles réponses il sup-
prime de son cache lorsque celui-ci est plein. Deuxièmement, le médiateur doit utiliser les
données du cache de manière ecace lors du traitement des requêtes.
Une solution simple pour gérer le contenu d'un cache sémantique (ou d'un ensemble de
vues matérialisées) est (1) de stocker toutes les réponses obtenues des sources de données,
et (2) de supprimer les réponses les moins récemment utilisées lorsqu'il n'y a plus d'espace
libre dans le cache. Le système ADMS [30] implante cette solution. Des techniques plus
sophistiquées ont été développées pour le choix des vues à matérialiser (i.e. des réponses à
conserver dans le cache) et le choix des vues à supprimer (i.e. des réponses à supprimer du
cache). Dans le cadre des entrepôts de données, des techniques de sélection de vues (view
selection) ont été développées pour choisir quelles vues matérialiser dans un plan d'exécution
étant donnés les coûts de mise à jour et un espace de stockage limité [52] [67]. En ce qui
concerne le choix des vues à supprimer, Dar et al [33], ont proposé d'utiliser une notion de
distance (e.g. distance de Manhattan) entre les vues matérialisées et la dernière requête. Les
vues les plus éloignées de la dernière requête posée sont les premières supprimées si le cache
est plein.
Une solution simple pour utiliser les données du cache lors de l'optimisation est de tester
si la requête courante est contenue 14 dans une des requêtes du cache. C'est la solution
implantée dans le système ADMS. Dans Hermes [1], le système teste si la requête courante
correspond exactement à une des sous-requêtes du cache. Si c'est le cas, la réponse est
directement obtenue du cache. Si ce n'est pas le cas, des règles (appelées des invariants)
permettent au système de déterminer la requête du cache qui répond partiellement à la
14. Une requête R est contenue dans une requête R' si, pour toutes bases de données, les réponses de R
sont un sous-ensemble des réponses de R' (query containment) [102].
Conclusion 39
requête courante. La requête initiale est réécrite en une requête qui utilise les données du
cache et en une requête résiduelle qui contacte un ensemble de sources de données. Des
solutions plus sophistiquées [63] [72] [84] [48] consistent à combiner plusieurs sous-requêtes
du cache pour réécrire la requête. Le système peut renvoyer une réponse partielle à la requête
qui lui est posée en considérant uniquement les données contenues dans le cache.
L'utilisation d'un cache sémantique renforce le problème de validité des réponses fournies
par un système de médiation. Un système de médiation ne peut pas garantir la propriété
d'isolation dans le traitement des requêtes : des mises à jour sur les sources de données locales
peuvent modier des données impliquées dans une requête globale. Si un cache sémantique
est utilisé, des mises à jour eectuées sur les sources de données peuvent rendre caduques
certaines données du cache. Des mécanismes doivent donc être mis en oeuvre pour garantir
la cohérence du cache sémantique. Ce problème n'est à notre connaissance pas traité dans
la littérature.
Un autre problème concernant l'exécution des requêtes provient de la diculté de prévoir
le délai avec lequel une source de données va fournir sa réponse. Ainsi le plan d'exécution
choisi pendant la phase d'optimisation peut s'avérer inecace selon les conditions de transfert
de données sur le réseau. Le système de médiation doit pouvoir masquer les délais de réponse
importants de certaines sources de données, en modiant dynamiquement le plan d'exécution
lors de l'exécution de la requête. Les techniques de query scrambling [4] [104] sont fondées
sur l'idée que du travail utile peut être eectué pendant qu'une ou plusieurs sources sont
bloquées (i.e., ne répondent pas rapidement). Le travail utile est ici (a) la matérialisation
de résultats intermédiaires ou (b) la synthèse de nouveaux opérateurs pour manipuler les
résultats intermédiaires disponibles. Lorsque tout le travail qui pouvait être eectué avec
les sources disponibles est réalisé, le système attend simplement que les sources bloquées
fournissent les données qui concernent la requête.
Dans un système de médiation, l'autonomie des sources et les caractéristiques des réseaux
utilisés ne permettent pas de garantir que les sources de données vont renvoyer la réponse à
la sous-requête qui leur est envoyée dans un délai raisonnable [3]. Les systèmes de médiation
doivent donc pouvoir faire face à l'indisponibilité temporaire des sources de données. Nous
détaillons ce problème du fonctionnement d'un médiateur en présence de sources de données
indisponibles dans le chapitre suivant.
2.5 Conclusion
Nous avons déni un ensemble de critères qui permettent de caractériser une application
décisionnelle intégrant plusieurs sources de données hétérogènes réparties sur un Intranet
ou Internet. Nous avons présenté trois architectures pour de telles applications : (1) une
architecture naïve, où l'application intègre directement les sources de données, (2) une ar-
chitecture reposant sur un entrepôt de données, où les données sont extraites du système
opérationnel et stockée dans l'entrepôt de données de manière à ce que l'application puisse
y accéder et (3) une architecture basée sur un système de médiation qui accède directement
aux sources de données et en fournit à l'application une vue uniforme. Nous avons comparé
ces diérentes architectures en fonction des caractéristiques des applications. Il apparaît que
les systèmes de médiation sont bien adaptés aux cas où les applications posent des requêtes
simples (i.e. des unions de requêtes conjonctives), où les exigences de performances ne sont
pas draconniennes et où les sources de données sont prêtes à accepter la charge de données
générées par le système de médiation.
Nous avons présenté les systèmes de médiation existants en distinguant les systèmes
fédérés (qui permettent une intégration forte d'un faible nombre de sources de données
faiblement hétérogènes) des systèmes à grande échelle (qui permettent l'accès à des sources
de données dont les capacités de traitement sont très diérentes et éventuellement réparties
sur un réseau à grande distance). Nous avons également abordé les problèmes posés par de
tels systèmes et les solutions qui ont été proposées.
Il existe aujourd'hui peu d'applications reposant sur des systèmes de médiation. On
peut trouver plusieurs raisons à cet état de fait. Premièrement, les applications d'aide à la
décision de type OLAP (On-Line Analytical Processing) nécessitent des requêtes complexes
ou des techniques d'analyse de données qui ne peuvent s'appliquer que sur des entrepôts de
données. De telles manipulations ne peuvent s'eectuer directement sur les sources de données
opérationnelles. Les systèmes de médiation ne peuvent donc pas être utilisés pour implanter
de telles applications. Une contribution de ce chapitre est de dénir les caractéristiques des
applications pour lesquelles un système de médiation est bien adapté.
Deuxièmement, un certain nombre d'applications intègre de manière ad-hoc un ensemble
de sources de données. Ces applications ont été développées parce que les sources de données
ne pouvaient pas être prises en compte par les systèmes de médiation existants. Les travaux
sur les adaptateurs et la prise en compte de sources de données disparates donnent aux
systèmes de médiations un argument convaincant sur ce point.
Troisièmement, l'intégration des sources de données par un système de médiation pose
des problèmes de performances. Les travaux sur les caches sémantiques proposent un premier
élément de réponse. De manière plus générale, le temps de réponse d'un système de médiation
est nécessairement supérieur au temps de réponse d'un système intégré. Il est donc important
que le système permette à l'utilisateur de suivre le déroulement du traitement d'un requête
et lui indique constamment l'état dans lequel il se trouve, les réponses qu'il a obtenue des
sources de données, le débit avec lequel il obtient ces réponses ou encore les opérations qu'il
exécute. La validité de cette approche a été démontrée dans le cas du calcul d'agrégats [55].
Enn, dans un système de médiation se pose le problème de la disponibilité des sources
de données lorsqu'elles sont contactées pendant le traitement d'une requête. Ce problème ne
se pose pas dans les entrepôts de données puisque les données sont rapatriées des sources
de données de manière régulière. Ce problème est un frein au déploiement des systèmes
de médiation. Cette thèse étudie ce problème et propose des solutions pour permettre un
fonctionnement satisfaisant des systèmes de médiation en présence de sources de données
indisponibles.
41
Chapitre 3
Systèmes de médiation et sources de
données indisponibles
Ce chapitre est consacré au problème que nous étudions dans cette thèse : le fonctionne-
ment d'un système de médiation en présence de sources de données indisponibles.
Nous précisons tout d'abord les causes d'indisponibilité des sources de données. Nous
discutons ensuite les services qu'un système de médiation doit fournir, en mode dégradé,
pour permettre aux applications d'interagir avec les utilisateurs de manière satisfaisante.
Nous résumons l'impact de ces services sur le système de médiation.
Nous discutons ensuite les limitations des systèmes de médiation existants et l'insusance
de plusieurs approches proposées pour traiter le problème des sites indisponibles ou des
données manquantes dans un système de bases de données.
Nous faisons apparaître en conclusion les deux fonctions principales que doit fournir un
système de médiation pour gérer l'indisponibité d'une ou plusieurs sources de données de
manière satisfaisante. Ces deux fonctions sont détaillées dans les chapitres suivants.
3.1 Problèmes dues aux sources de données indisponibles

3.1.1 Indisponibilité des sources de données
Denition 1 (Sources indisponibles) Une source de données est indisponible si elle ne
renvoie pas la réponse à la sous-requête qui lui est destinée dans des délais raisonnables.
Lors de l'exécution d'une requête, le système de médiation n'a aucune garantie que les
sources de données qu'il contacte sont disponibles. En eet, l'autonomie des sites et les
caractéristiques des réseaux ne permettent pas de garantir la disponibilité des sources de
données.
42 Systèmes de médiation et sources de données indisponibles
Chaque source de données contactée par un système de médiation est autonome. Si une
panne survient sur une source de données ou si une opération de maintenance est eectuée,
le système de médiation n'en est pas informé et cette source ne fournit pas la réponse à
la requête qui lui est envoyée. Gray et Reuter [50] ont identié les principales raisons pour
lesquelles un serveur est hors-service. Ils distinguent les interruptions dues à l'environnement
(panne de courant, intempéries, etc.), les interruptions dues à l'administration, à la main-
tenance ou à la réparation du système, et les interruptions dues à une erreur matérielle ou
logicielle. Par ailleurs, la source étant autonome, elle gère la charge de travail qu'elle accepte
du système de médiation. En cas de charge excessive, la source de données peut refuser des
connexions ou bien renvoyer un message explicite indiquant son indisponibilité (en utilisant
le code de retour 405 pour un serveur HTTP par exemple). Enn, la source de données peut
modier le format dans lequel elle exporte ses données. Tant que l'adaptateur qui lui est
associé n'est pas modié, le médiateur ne peut pas obtenir la réponse et considère que la
source de données est indisponible.
Les réseaux qui permettent au système de médiation de contacter les sources de don-
nées n'orent pas de garantie sur la disponibilité des sources de données : il se peut que la
connexion vers une source de données ne puisse pas être établie ou soit rompue. Un problème
matériel sur le réseau ou une congestion de celui-ci peuvent empêcher qu'une connexion soit
établie entre le système de médiation et une source de données même s'ils sont tous deux en
service. Une fois la connexion établie, il se peut qu'elle soit rompue si elle ne peut pas être
eectuée dans un temps déterminé. Un protocole de transport tel que TCP, utilise un timer
pour contrôler l'établissement d'une connexion. Si la connexion ne peut pas être établie au
bout de 75 secondes, alors la demande de connexion échoue [111]. Une ou plusieurs autres
demandes doivent être formulées pour que la connexion soit établie. TCP retransmet 13 fois
un message avant de rompre la connexion. Le temps entre chaque retransmission est calculé
dynamiquement; il est compris entre 1 et 64 secondes [111].
Nous avons de manière générale peu de résultats quantitatifs concernant la disponibilité
des sources de données dans les applications basées sur des systèmes de médiation. Ceci est
dû au petit nombre d'applications basées sur une infrastructure de médiateur et à la diculté
d'obtenir des informations sur la disponibilité des sources de données dans ces applications.
Nous présentons en section 6.4 une étude de la disponibilité des sources dans le cadre de
l'application Redoc. De manière plus générale, l'étude [106] fournit quelques éléments concer-
nant les connexions aux sources de données réparties sur l'Internet. Cette étude concerne
la disponibilité et la latence des serveurs WWW; nous considérons que ceux-ci constituent
l'essentiel des sources de données dans le contexte de l'Internet. Les expériences relatées
dans cette étude consistent à contacter, à plusieurs moments de la journée, 540 serveurs
WWW situés en Europe et aux États Unis à partir de l'Université de Virginie (connexion
à 1.5 mbit/sec vers l'Internet). Plusieurs aspects ressortent de cette étude. Premièrement,
il apparaît qu'au moins 90% des connexions vers les serveurs WWW peuvent être établies.
Deuxièmement, il apparaît qu'en aucun cas 100% des connexions peuvent être établies. Troi-
sièmement, une grande variation apparaît dans la disponibilité des serveurs WWW : 80%
des serveurs nord-américains étaient disponibles pour 95% des connexions alors que 5% des
serveurs étaient disponibles pour moins de 80% des connexions. Enn, il apparaît que 97%
Problèmes dues aux sources de données indisponibles 43
des connexions réussies sont établies en moins de 10 sec : il semble donc raisonnable, dans
ce contexte, de xer un temps limite pour létablissement de la connexion ou l'absence de
transfert (une limite inférieure à celle imposée par le protocole de transport).
3.1.2 Exigences des utilisateurs

Les exigences des utilisateurs que nous discutons ci-dessous ne sont pas le résultat d'études
ergonomiques; elles découlent plutôt de règles empiriques. Thomas [99] a étudié plusieurs
aspects de l'interaction entre utilisateurs et un système de gestion de base de données. Selon
lui, un point important est que le temps de réponse d'un système doit être prévisible. Lorsque
le temps de réponse varie de manière imprévisible l'utilisateur est frustré et peu satisfait du
système. Par conséquent dans le cadre de notre étude, le système doit notier à l'utilisateur
qu'il ne peut pas produire la réponse complète lorsqu'une ou plusieurs sources de données sont
détectées indisponibles. Cette notication doit être retournée dans des délais raisonnables :
si possible dans un délai inférieur au temps nécessaire pour produire la réponse complète.
Un système qui reste bloqué en attendant de pouvoir produire la réponse à une requête n'est
pas satisfaisant selon le principe de Thomas.
Lee [69] introduit la notion de coopération dans les interactions entre utilisateurs et SGBD.
Nous retenons de son étude le principe suivant : le système doit fournir à l'utilisateur autant
d'informations que possible concernant le traitement d'une requête. Les informations que le
système peut produire avant la réponse complète sont de deux ordres. Ce sont, d'une part,
des informations concernant le déroulement du traitement de la requête, e.g. quelles sont les
sources disponibles ou indisponibles, et d'autre part, des données partielles se rapportant à la
requête initiale. Ces données partielles peuvent être obtenues à partir des sources disponibles
ou à partir de sources de données alternatives qui ne sont pas impliquées dans la requête
initiale. Elles permettent à l'utilisateur d'obtenir des informations partielles en attendant
que la réponse complète puisse être fournie. C'est le cas par exemple dans l'application
du complexe hospitalier où le médecin doit pouvoir accéder au dossier médical même si
une ou plusieurs sources de données sont indisponibles ou dans l'application Redoc, où les
utilisateurs peuvent se satisfaire d'un sous ensemble de la réponse complète.
Dans l'application hospitalière, nous avons identié deux types de requêtes : première-
ment, les requêtes prédénies qui permettent de constituer le dossier médical d'un patient
donné, et deuxièmement, les requêtes ad-hoc concernant par exemple la gestion des ressources
ou une analyse médicale. Si une source de données située dans un service est indisponible
lorsque un médecin consulte le dossier médical d'un patient, il veut obtenir toutes les infor-
mations provenant des services disponibles. La consultation du dossier médical ne doit pas
être bloquée parce qu'une ou plusieurs sources de données sont indisponibles. Il se peut que
le médecin soit particulièrement intéressé par les informations concernant les clichés radio-
logiques alors que la source de donnée du service de radiologie est indisponible. Dans ce cas,
le médecin ne peut pas obtenir les données qui l'intéressent avant que le serveur du service
radiologie soit à nouveau disponible. Il est important que l'application puisse indiquer au
médecin que le serveur du service radiologie est indisponible; éventuellement, le médecin peut
interagir directement avec ce service pour obtenir l'information qui l'intéresse. Dans le cas où
le médecin est principalement intéressé par les épisodes chirurgicaux alors que le serveur du
site de radiologie est indisponible, le médecin ne veut pas attendre que ce site soit à nouveau
disponible pour obtenir les données qui l'intéressent et qui sont elles déjà disponibles. En ce
qui concerne les requêtes ad-hoc, si une ou plusieurs sources de données sont indisponibles,
l'utilisateur souhaite en être informé. Il peut alors décider de poser une autre requête pour
obtenir des informations partielles en attendant que les sources soient à nouveau disponibles
ou bien attendre avant de resoumettre la requête initiale.
Dans le cadre de l'application Redoc, les requêtes qui sont traitées par le médiateur sont
des unions sur un ensemble de sources de données. L'utilisateur doit être notié qu'une ou
plusieurs sources sont indisponibles. Il doit pouvoir consulter le sous-ensemble de la réponse
formé par les données obtenues des sites disponibles en attendant la réponse complète.
Les applications que nous considérons sont intéractives. Dans le cas d'une application
de type batch (e.g., l'approvisionnement d'un data warehouse), les problèmes d'interactions
avec les utilisateurs ne se posent pas. L'objectif principal du système de médiation dans ces
applications est de produire la réponse complète de manière ecace.
3.1.3 Impact sur le traitement de requêtes

Le premier problème du système de médiation est de détecter qu'une source de données
est indisponible. Un protocole de transport tel que TCP détecte et signale qu'une connexion
ne peut pas être établie ou est rompue. Le système de médiation peut se contenter de ce
service ou bien implanter à son niveau un mécanisme de time-out pour détecter les problèmes
de connexions. Le système de médiation doit en outre reconnaître les messages explicites
d'indisponibilité et les changements dans le format des réponses retournées par la source de
données. Ces mécanismes de détection des sources indisponibles sont spéciques à chaque
source de données et doivent donc être implantés au niveau des adaptateurs.
De manière classique, l'utilisateur soumet une requête et le système de traitement de
requête renvoie la réponse. Lorsqu'une source de données est indisponible, la sous-requête
qui lui est destinée ne peut pas être acheminée, ou le résultat qu'elle produit ne peut pas
être complètement obtenu par le système. La réponse à la requête courante ne peut donc
pas être produite et le système doit recontacter cette source de données pour construire sa
réponse complète.
Si le traitement de la requête est interrompu pour retourner une notication à l'utilisateur,
ce traitement doit être relancé, éventuellement plusieurs fois, pour que le système puisse
produire la réponse complète. L'utilisateur soumet donc plusieurs fois la même requête pour
obtenir la réponse complète.
L'objectif de fournir des informations avant que la réponse complète soit produite im-
plique d'abord que le système soit capable de recueillir ces informations durant le traitement
de la requête et qu'il soit ensuite capable de les fournir à l'utilisateur. Les mécanismes de
traitement des requêtes et l'interface du système sont donc potentiellement impactés par le
problème des sources indisponibles.
Limitation des systèmes de médiation existants 45
En terme de performances, les objectifs du système de médiation sont les suivants :
la notication, qui signale les sources indisponibles, doit être renvoyée dans un délai
inférieur au temps nécessaire pour produire la réponse complète de manière à ce que
le temps de réponse du système ne varie pas de manière imprévisible ;
le système doit minimiser le temps de réponse, i.e. le temps de traitement (lors des
interactions successives) et le temps d'attente (entre les interactions successives il
dépend donc du nombre de soumissions nécessaires pour obtenir la réponse complète).
3.2 Limitation des systèmes de médiation existants

Les systèmes de médiateurs existants, que nous avons présentés dans le chapitre pré-
cédent, échouent en présence de sources de données indisponibles. Lorsqu'ils traitent une
requête q, aucun mécanisme spécique n'est implanté pour détecter qu'une source de don-
nées est indisponible. Les systèmes les ignorent ou génèrent une erreur n. La détection des
sources indisponibles repose entièrement sur le protocole de transport. Un facteur important
du temps de réponse échappe ainsi au système de médiation.
Pour obtenir la réponse complète la requête doit être soumise à nouveau. Le traitement
de la requête repart de zéro et si certaines sources sont à nouveau indisponibles, le sys-
tème génère encore une erreur. La réponse complète a n'est construite que lorsque toutes
les sources de données sont disponibles simultanément. C'est une contrainte forte sur la
production des réponses complètes, surtout si le nombre de sources de données impliquées
dans une requête est important comme c'est le cas dans Redoc. Nous pouvons modéliser
la séquence d'interactions entre l'application et le médiateur comme la séquence d'étapes
suivantes: <q; n; q; n; : : : q; a>. La requête est soumise plusieurs fois pour obtenir la réponse
complète et elle est chaque fois traitée comme une nouvelle requête. Du travail pourrait être
conservé et réutilisé entre les évaluations successives d'une même requête.
Le laps de temps écoulé entre le moment où la requête est soumise pour la première fois
et le moment où la réponse complète est obtenue peut être important. Nous avons vu que
l'utilisateur pourrait être intéressé par des données se rapportant à la requête avant que la
réponse complète ne puisse lui être fournie. Un système classique n'apporte aucun support
particulier pour que l'utilisateur obtienne des données partielles se rapportant à une requête.
Seule la réponse complète lui est fournie.
3.3 Approches existantes

Des approches du problème des sites indisponibles ou des données manquantes ont été
proposées dans la littérature. Nous étudions ici dans quelle mesure ces techniques existantes
peuvent permettre un fonctionnement satisfaisant d'un système de médiation en présence de
sources de données indisponibles.
3.3.1 Réplication
La réplication est une solution classique aux problèmes d'indisponibilité des sites dans un
système distribué. Les systèmes de gestion de bases de données distribuées ont adaptés cer-
taines de ces techniques : les relations peuvent être copiées sur plusieurs sites pour améliorer
la disponibilité des données et les performances. Il existe ainsi (en général) une relation prin-
cipale et plusieurs réplicats. Cette solution est mise en oeuvre dans les principaux systèmes
relationnels du marché [92].
On distingue la réplication synchrone (eager replication), où tous les réplicats d'une re-
lation sont mis à jour simultanément, et la réplication asynchrone (lazy replication), où les
modications sont propagées vers les réplicats une fois que la relation principale a été mise
à jour. La réplication synchrone requiert que les sites sur lesquels se trouvent la relation
principale et les réplicats soient tous disponibles simultanément au moment des mises à jour.
La réplication asynchrone permet de gérer l'éventualité qu'un ou plusieurs sites soient in-
disponibles au moment de la propagation des mises à jour : les mises à jour vers les sites
disponibles sont eectuées immédiatement et les mises à jour vers les sites indisponibles sont
simplement conservées pour être propagées ultérieurement. Dans les deux approches, tous
les réplicats peuvent être consultés indépendamment.
La réplication soure de plusieurs inconvénients. Du point de vue économique, la répli-
cation est coûteuse. Répliquer une source de données implique que le matériel permettant
d'installer le serveur est présent sur diérents sites et que le logiciel a un coût élevé car sa
complexité augmente. La réplication a également (en général) un impact négatif sur le fonc-
tionnement et les performances des mises à jour [49]. Le principal désavantage, enn, est que
dans un contexte où les sources de données sont autonomes, il peut être impossible de répli-
quer une source de données simplement parce que celle-ci l'interdit. Lorsque les sources de
données sont autonomes, la réplication des données d'un site est souvent impossible pour des
raisons techniques, légales, ou politiques. Il est par exemple illusoire de vouloir répliquer le
site WWW Alta-Vista sans l'accord de Digital. En eet, l'interface d'accès à cette source de
données ne permet pas d'obtenir l'ensemble des données qu'elle contient ; il est uniquement
possible d'eectuer une recherche par mots-clés.
3.3.2 Traitement approché des requêtes

Les techniques de traitement approché des requêtes (approximate query processing) ont
été développées pour faire face au problème des données manquantes ou inconsistantes dans
les bases de données [75].
Réponses approchées et réponses exactes Le traitement approché des requêtes pro-

duit des résultats intermédiaires qui approchent peu à peu la réponse exacte [107]. Dans
le cas où l'exécution ne peut pas terminer, le résultat intermédiaire le plus approchant est
retourné. Cette approximation de la réponse exacte est dénie en terme de deux ensembles
de tuples qui l'encadrent (et forment ainsi un sandwich).
Approches existantes 47
Une relation d'ordre sur les ensembles de tuples est donc nécessaire pour dénir la réponse
approchée. La relation d'ordre la plus simple est l'inclusion ensembliste. Elle est utilisée dans
APPROXIMATE [107]. Dans ce système, la réponse approchée est un sur-ensemble de la
réponse exacte. La réponse approchée est en fait partitionnée en deux blocs : d'une part,
un ensemble de tuples qui appartiennent de manière certaine à la réponse exacte, les tuples
certains, et d'autre part, un ensemble de tuples qui appartiennent peut-être à la réponse
exacte, les tuples possibles.
Des relations d'ordres plus complexes sont dénies pour prendre en compte les tuples
incomplets. Dans MULTIPLEX [79], la réponse approchée est exprimée en terme de sous-
vue (subview) et de super-vue (superview) de la requête initiale. Une vue V1 est une sous-vue
d'une vue V2 si V2 est le résultat de sélections et de projections sur V1; V2 est alors une
super-vue de V1.
Enn, Buneman et al. [22, 23, 75], dénissent la réponse approchée en terme d'un sous-
ensemble généralisé et d'un sur-ensemble généralisé qui encadrent la réponse exacte. De
manière informelle, un ensemble de tuples E1 est un sur-ensemble généralisé de E2, si E1
contient plus de tuples et moins de colonnes que E2; E1 est un sous-ensemble généralisé de
E2, si E1 contient moins de tuples et moins de colonnes que E2.
Plus précisément, les ordres de Hoare (v[ ) et de Smyth (v] ) sont utilisés pour dénir
les sous-ensembles et sur-ensembles généralisés. Ces deux relations d'ordres concernent des
ensembles de tuples. Elles utilisent la même relation d'ordre sur les tuples, introduite dans
[23]. Nous présentons ces relations d'ordres formellement car nous les réutilisons dans la suite
de notre étude.
Denition 2 (Ordre sur les tuples) Soit V un domaine de valeurs contenant la valeur
nulle ?. V est muni d'un ordre partiel v, tels que deux valeurs non nulles et distinctes de
V sont incomparables et la valeur nulle est inférieure à toutes les autres valeurs. Soit L un
ensemble de labels.
Un tuple est une fonction dans L ! V , et l'ordre sur les tuples est dénit de la manière
suivante : t1 v t2 8l 2 L , t1(l) v t2(l)
Par exemple le tuple [name: 'Paul', address: 'Paris'] est supérieur au tuple [name: 'Paul']
dans l'ordre que nous venons de dénir . Les tuples [name: 'Paul', address: 'Paris'] et [name:
'Paul', workAdress: 'Rocquencourt'] ne sont pas comparables.
Denition 3 (ordre de Hoare (v[ )) Soient A et B deux ensembles de tuples. A est infé-
rieur à B dans l'ordre de Hoare, noté A v[ B , 8a 2 A; 9b 2 B tel que a v b
Intuitivement, A est inférieur à B dans l'ordre de Hoare alors A contient moins de colonnes
et plus de tuples que B.
Denition 4 (ordre de Smyth (v])) Soient A et B deux ensembles de tuples. A est in-
férieur à B dans l'ordre de Smyth, noté A v] B , 8b 2 B; 9a 2 A tel que a v b
Intuitivement, A est inférieur à B dans l'ordre de Smyth alors A contient moins de
colonnes et plus de tuples que B.
Ordre sur les réponses approchées Les diérents travaux dénissent un ordre partiel
sur les relations approchées pour dénir qu'une approximation est plus informative qu'une
autre. Dans APPROXIMATE ainsi que dans Buneman et al., l'ensemble des réponses ap-
prochées munies de cet ordre partiel constitue un treillis avec un élément minimal, l'élément
le moins informatif, et d'un élément maximal, la réponse exacte.
Opérations spéciques pour le traitement approché des requêtes Les relations

approchées, qui sont en fait chacune constituée de deux ensembles de tuples, ne peuvent pas
être manipulées avec les opérateurs classiques de l'algèbre relationnel [107]. APPROXIMATE
dénit de nouveaux opérateurs dont les opérandes sont des relations approchées : union,
diérence ensembliste, sélection, projection et produit cartésien sont ainsi redénis. Buneman
et al. dénissent un système de règles qui permet de dénir une requête et d'inférer la réponse
approchée correspondante (ce système de règle est une généralisation de datalog [23]). Les
opérateurs dénis dans APPROXIMATE et les inférences dénies par Buneman et al. sont
monotones par rapport à l'ordre partiel déni sur les approximations (plus les relations
qui participent à la requête sont complètes, plus la réponse approchée est informative).
La structure de treillis de cet ensemble ordonné permet de conclure que le traitement des
requêtes converge vers la réponse exacte.
Il est donc nécessaire d'implanter un moteur d'exécution avec des opérateurs spéciques
pour eectuer un traitement approché des requêtes. Ces solutions sont donc très lourdes à
mettre en oeuvre.
Application aux sources indisponibles Ces techniques sont avant tout adaptées aux
données manquantes ou aux inconsistances entre relations. Elles peuvent cependant être
appliquées aux cas où des sources de données sont indisponibles et où donc des relations
entières sont manquantes. APPROXIMATE requiert des informations sémantiques sur les
diérentes relations impliquées dans une requête. Sans ces informations sur les domaines
des diérents attributs le système ne peut pas établir l'approximation initiale d'une relation
indisponible et il échoue. MULTIPLEX, lui, fournit une approximation uniquement dans
le cas où une vue matérialisée (ou une source alternative) couvre partiellement la relation
indisponible. Ces deux systèmes nécessitent donc des conditions particulières pour prendre
en compte les relations indisponibles.
Les techniques proposées par Buneman et al. [23] permettent, elles, de prendre en compte
des relations indisponibles. Considérons l'exemple de la règle datalog suivante
c(X,Y,Z) :- a(X,Y), b(Y,Z).
où a est disponible et b indisponible. La relation a étant disponible son approximation est

Approches existantes 49
la plus informative possible. Le sous-ensemble généralisé et le sur-ensemble généralisé sont
égaux ; ils contiennent tous les tuples de la relation a :
X Y X Y
a1 a2 a1 a2
a3 a4 a3 a4
Pour la relation b au contraire, l'approximation est l'élément le moins informatif : le sur-
ensemble généralisé est le singleton contenant l'élément nul, et le sous-ensemble généralisé
est l'ensemble vide (dans le tableau - dénote une valeur nulle).
Y Z Y Z
- -
c n'est initialement pas connu, son approximation initiale est donc également l'élément
le moins informatif.
X Y Z X Y Z
- - -
Buneman et al. ont déni un ensemble de règles d'inférences qui permettent de construire
des approximations plus précises pour les relations d'une règle. Dans notre exemple, il est
possible de raner le sur-ensemble généralisé de c. En eet, la règle d'existence (existence
inference) permet d'inférer que l'ensemble des tuples possibles pour c (i.e. le sur-ensemble
généralisé) est restreint aux tuples dont les valeurs pour X et Y sont celles fournies par a.
L'ensemble des tuples certains pour c (i.e. le sous-ensemble généralisé)reste vide puisqu'il est
possible que b soit vide. On obtient donc pour c l'approximation suivante :
X Y Z X Y Z
a1 a2 -
a3 a4 -
3.3.3 Utilisation de caches sémantiques

Nous avons vu en section 2.4.4.3 que dans un système de médiation, un cache séman-
tique (qui stocke les réponses déjà obtenues ainsi que les requêtes associées, i.e. des vues
matérialisées) est un moyen d'améliorer les performances. Le système peut ainsi réutiliser
des données déjà obtenues lors des exécutions précédentes pour construire la réponse à une
nouvelle requête.
Le système réécrit la requête courante de manière à utiliser les vues dont il dispose. La
requête réécrite implique une ou plusieurs vues ainsi que des sous-requêtes vers les sources
de données.
Une variante de cette approche construit des réécritures complètes, i.e. la requête réécrite
contient uniquement des références vers les vues matérialisées. La requête ainsi obtenue, si
elle existe, peut être évaluée sans contacter les sources de données distantes. Levy et al. [72]
ont déni un algorithme qui génère la réécriture maximale contenue dans la requête initiale
(maximally-contained query) 1. La réponse à cette requête réécrite est un sous-ensemble de
la réponse à la requête initiale.
En utilisant un cache sémantique il est donc possible de retourner des informations par-
tielles à l'utilisateur. Ceci pose cependant plusieurs problèmes. Premièrement, l'algorithme
qui cherche une réécriture complète de la requête initiale (sans contacter les sources de don-
nées) n'est appelé que dans un mode de fonctionnement dégradé du système de médiation.
Comment le système de médiation décide-t-il de fonctionner en mode dégradé ? Deuxiè-
mement, le système retourne en mode dégradé un sous-ensemble de la réponse complète.
L'application peut-elle se satisfaire de savoir que ces données représentent un sous-ensemble
de la réponse complète sans connaître leur sémantique exacte? Pourquoi ne retourner qu'un
sous-ensemble, y-a-t-il d'autres ensembles de données qui peuvent constituer une information
partielle intéressante pour l'utilisateur?
L'utilisation de caches sémantiques pour fournir des informations partielles a plusieurs
fois été évoqué [23] [72] [84]. Elle n'a cependant jamais été mise en oeuvre.
3.3.4 Bilan
Les trois approches que nous avons présentées sont insusantes pour fournir une solu-
tion correcte au problème posé. Premièrement, les techniques de réplication ne peuvent en
général pas être appliquées avec des sources de données dont les capacités de traitement des
requêtes sont limitées. Deuxièmement, les techniques de traitement de requêtes sont lourdes
à mettre en oeuvre puisqu'elles requièrent la dénition d'un moteur d'exécution et donc d'un
optimiseur spécique. Troisièmement, les caches sémantiques ne sont pas mis en oeuvre dans
les systèmes de médiation existants et leur utilisation lorsque des sources sont indisponibles
pose un certain nombre de problèmes.
Ces approches orent cependant des aspects intéressants. Les techniques de traitement
approché des requêtes fournissent un cadre concernant les informations partielles. Elles xent
notamment les relations entre les réponses partielles qui sont fournies et la réponse exacte qui
ne peut pas être calculée. L'utilisation des caches sémantiques montre l'intérêt d'utiliser des
données matérialisées sur le médiateur. Ces données pourraient être utilisées pour obtenir
la réponse complète de manière incrémentale ou fournir à l'application des informations
partielles.
3.4 Conclusion
Le déploiement des systèmes de médiation fait apparaître le problème des sources de
données indisponibles lors du traitement d'une requête. Ce problème est particulièrement
1. Cet algorithme est utilisé dans Information Manifold. Dans ce système cependant les vues ne sont pas
matérialisées mais dénissent les données exportées par les adaptateurs.
Conclusion 51
aigu dans des environnements où un grand nombre de sources de données sont intégrées via
un réseau à grande distance tel qu'Internet.
Face à ce problème, les systèmes existants génèrent une erreur interne. Ils imposent, par
conséquent, que toutes les sources de données soient disponibles simultanément pour fournir
la réponse à une requête. De plus, ils ne produisent aucune information partielle concernant
la requête avant que la réponse complète ne soit fournie.
Les approches du problème des sites indisponibles ou des données manquantes ne sont
pas satisfaisantes dans le contexte de notre étude. C'est le cas de la réplication, qui permet
d'améliorer la disponibilité dans les systèmes distribués, et du traitement incrémental des
requêtes, qui permet de gérer les données manquantes ou inconsistantes dans une base de
données. La réplication d'une source de données ne peut dans le cas général pas être mise
en oeuvre. Le traitement approché des requêtes est lourd à mettre en oeuvre et n'est pas
adapté au cas où des relations entières sont indisponibles. D'autre part, l'utilisation d'un
cache sémantique pour fournir des informations partielles lorsqu'une ou plusieurs sources de
données pose plusieurs problèmes non résolus.
Nous avons fait apparaître deux aspects complémentaires concernant le traitement des
requêtes en présence de sources de données indisponibles qui nous permettent de dénir une
nouvelle approche :
le système doit produire ecacement la réponse complète. Plutôt que de reprendre le
traitement d'une requête dans sa totalité lorsqu'une source de données est indisponible,
le système pourrait proter des sources disponibles et ainsi obtenir la réponse complète
incrémentalement;
dans certains cas, l'utilisateur veut accéder des informations partielles concernant sa
requête avant que la réponse complète ne soit produite. Le système pourrait proter
des informations accumulées pendant le traitement de la requête en présence de sources
indisponibles pour aider l'utilisateur à extraire des informations partielles pertinentes.
Les deux chapitres suivants seront consacrés aux deux aspects mentionnés ci-dessus: le
traitement incrémental des requêtes et l'extraction d'informations partielles.
53
Chapitre 4
Traitement incrémental des requêtes
4.1 Introduction
Un système de médiation contacte un ensemble de sources de données lors de l'exécution
d'une requête. Il envoie une sous-requête à chacune d'elles et récupère le résultat qu'elles
fournissent ; il peut ainsi construire la réponse et la renvoyer à l'application. Or rien ne
garantit au système que toutes les sources de données peuvent lui renvoyer un résultat
lorsqu'il les contacte. En eet les congestions du réseau ou la surcharge des serveurs peuvent
rendre certaines sources temporairement indisponibles 1.
Si une ou plusieurs sources de donnés sont indisponibles lorsque le système les contacte,
ce dernier ne peut pas construire la réponse à la requête qui lui a été soumise. En eet le
système a besoin des résultats de toutes les sources de données qu'il contacte pour fournir
une réponse complète à l'application.
Les systèmes existants ne fonctionnent correctement que dans le cas où toutes les sources
de données sont disponibles. Lorsqu'une source de données est indisponible, le système consi-
dère qu'il s'agit d'une erreur interne. L'évaluation de la requête est interrompue et un message
d'erreur est retourné à l'application. Celle-ci doit soumettre la requête à nouveau, éventuel-
lement plusieurs fois, pour obtenir la réponse complète. A chaque fois, le système contacte
le même ensemble de sources de données, commence à combiner les réponses obtenues des
sources disponibles et arrête l'exécution si une des sources s'avère être indisponible. Un sys-
tème existant présente donc les limitations suivantes lorsqu'il doit traiter plusieurs fois la
même requête :
le travail qui est eectué avec les sources disponibles est perdu si une source est indis-
ponible ; il n'est pas réutilisé lors des exécutions successives ;
1. Nous avons listé les principales causes d'indisponibilité des sources de données dans la section 3.1.1. Il
est à noter que ces observations sont valables même si un cache sémantique (Cf section 3.3.3) est utilisé par
le système de médiation. En eet, la requête résiduelle (qui complète les données du cache dans la réécriture
de la requête initiale) concerne un ensemble de sources de données.
54 Traitement incrémental des requêtes
toutes les sources de données doivent être disponibles simultanément pour que le sys-
tème retourne une réponse.
Notre objectif est de proposer une extension des systèmes de médiation existants de
manière à dépasser ces limitations et améliorer le temps de réponse lorsqu'une même requête
doit être soumise plusieurs fois pour obtenir la réponse complète.
Exemple Considérons le traitement d'une requête ad-hoc dans le cadre de l'applica-
tion du complexe hospitalier (voir section 2.2.1) : trouver les informations personnelles et
radiologiques des patients dont le séjour dépasse 10 jours et qui attendent d'être opérés
SELECT PATIENT.NAME, PATIENT.ROOM, RADIOLOGY.ID, RADIOLOGY.COMMENT

FROM PATIENT, MAP, SURGERY, RADIOLOGY
WHERE PATIENT.ID = MAP.PID AND PATIENT.STAY > 10
AND MAP.SID = SURGERY.ID AND SURGERY.STATUS = 'WAITING'
AND MAP.RID = RADIOLOGY.ID;
Les relations PATIENT, SURGERY et RADIOLOGY sont situées sur trois sources de données
diérentes, i.e. respectivement la source du service d'administration, la source du service de
chirurgie et la source du service de radiologie. La relation MAP met en correspondance les
identiants des patients dans les diérentes relations. C'est une relation auxiliaire dénie
pour l'intégration de schéma ; elle est stockée par le système de médiation.
Considérons maintenant que la source du service de radiologie n'est pas disponible lorsque
le système exécute cette requête.
Un système existant commence l'exécution de la requête, il contacte les sources de don-
nées en fonction du plan d'exécution qui a été choisi, il obtient éventuellement des données
des sources disponibles. Lorsqu'il contacte la source de radiologie un problème survient. Le
traitement de la requête est arrêté. Les données déjà obtenues des sources disponibles sont
ignorées et un message d'erreur est retourné à l'application. L'application soumet ultérieu-
rement la même requête. Le système génère le même plan d'exécution pour la requête, il
commence donc par contacter les sources qu'il avait déjà contactées lors de l'exécution pré-
cédente. Il ne retourne une réponse que si toutes les sources de données sont disponibles
simultanément. En particulier, si une source de données (par exemple celle du service d'ad-
ministration) qui était disponible lors de la première exécution est maintenant indisponible,
le système ne peut pas construire la réponse : il n'a pas conservé les données qu'il a déjà
obtenu de cette source. 2
Notre approche est basée sur l'observation que le système de médiation peut tirer parti des
sources disponibles lors des exécutions successives d'une même requête. Plutôt que d'arrêter
le traitement d'une requête lorsqu'une source de données est indisponible et d'ignorer les
résultats déjà obtenus des sources disponibles, un système de médiation peut s'assurer qu'il
récupère les résultats fournis par les sources disponibles, qu'il les conserve et qu'il les réutilise
lors des exécutions successives.
Architecture d un système incrémental 55
Nous proposons donc une approche incrémentale du traitement des requêtes. Les
problèmes pour mettre en ÷uvre un traitement incrémental des requêtes sont les suivants:
détecter les sources indisponibles ;

obtenir et conserver les réponses des sources disponibles ;
réutiliser ces réponses lors des exécutions successives de la même requête.
La contribution majeure de ce chapitre est une architecture et un ensemble d'algorithmes

qui permettent de mettre en ÷uvre un traitement incrémental des requêtes dans un système
de médiation. Nous présentons tout d'abord l'architecture d'un système de médiation in-
crémental en identiant les composants qui doivent être modiés par rapport à un système
existant et les nouveaux composants qui doivent être mis en ÷uvre. Nous décrivons un al-
gorithme pour chacun des nouveaux composants. Nous avons mis en ÷uvre une première
version de ces algorithmes dans le système Disco [100].
Nous discutons dans ce chapitre des aspects fonctionnels du traitement incrémental des
requêtes. Les aspects liés aux performances sont étudiés dans le chapitre 6.
4.2 Architecture d'un système incrémental

Nous proposons d'étendre les fonctionnalités des systèmes de médiation existants en
mettant en ÷uvre un traitement incrémental des requêtes. La gure 4.1 décrit l'architecture
générale d'un système incrémental 2 tel que nous le proposons. Les composants grisés sont
les composants classiques d'un système existant, i.e. l'optimiseur et le moteur d'exécution
(l'architecture que nous présentons pour le système incrémental concerne essentiellement le
médiateur ; nous considérons que les adaptateurs sont intégrés au moteur d'exécution). Les
autres composants sont ajoutés pour prendre en compte diérents aspects du traitement
incrémental des requêtes. Notre objectif est de pouvoir implanter le traitement incrémental
des requêtes dans un système existant en eectuant un minimum de modications.
4.2.1 Composants
Les composants spéciques au système incrémental correspondent à de nouvelles étapes
dans le traitement des requêtes.
Détection des sources indisponibles Après que l'optimiseur ait généré un plan d'exé-
cution, le système incrémental procède à une phase de détection des sources indisponibles.
2. Par abus de langage, nous nommons système incrémental un système de médiation qui met en ÷uvre
un traitement incrémental des requêtes.
Requete
Optimiseur
au moins une source est indisponible

Sense
toutes les sources

sont disponibles
Moteur d’execution Materialize
Construct
Reponse Requete
incrementale
Fig. 4.1 Architecture incrémentale.
Nous décrivons, en section 4.3, l'algorithme sense qui identie un ensemble de sources in-
disponibles et détermine les portions du plan d'exécution qui peuvent être évaluées avec les
sources (a priori) disponibles et les portions du plan d'exécution qui ne peuvent pas être
évaluées à cause des sources indisponibles.
On peut se poser la question suivante : pourquoi introduire une phase de détection des
sources disponibles et ne pas attendre qu'un problème survienne durant l'exécution de la
requête? La réponse est la suivante : en procédant à une première identication des sources
indisponibles, le système obtient des informations qu'il peut utiliser pour décider d'une stra-
tégie d'évaluation diérente de celle imposée par le moteur d'exécution. C'est important,
notamment dans le cas où le moteur d'exécution arrête l'évaluation dès qu'un problème
survient en contactant une source.
Inversement, on peut se demander : pourquoi ne pas détecter les sources indisponibles
avant la phase d'optimisation? Pour pouvoir utiliser les informations concernant la disponi-
bilité des sources, le système doit être capable d'associer des portions de la requête courante
aux diérentes sources de données. C'est précisément la phase d'optimisation qui permet de
dénir quelles sous-requêtes sont destinées aux diérentes sources de données. Pour mettre
en ÷uvre un traitement incrémental des requêtes il n'est donc pas utile de détecter les sources
indisponibles avant la phase d'optimisation.
Notre algorithme considère qu'une source est disponible si le système peut récupérer
le résultat qu'elle envoie. Des sources qui sont ainsi détectées disponibles peuvent se révéler
indisponibles. C'est le cas lorsque le résultat fourni ne peut pas être acheminé vers le système
de médiation dans un délai raisonnable. Dans ce cas, l'exécution est interrompue et les
portions du plan d'exécution qui peuvent être évaluées sont redénies.
Lorsque l'ensemble du plan d'éxécution peut être évalué (i.e. toutes les sources sont dé-
tectées disponibles), le moteur d'exécution est invoqué pour construire la réponse complète.
Lorsque seules certaines portions du plan d'exécution sont évaluables (i.e. une ou plusieurs
sources de données sont indisponibles), le système incrémental procède a une phase de ma-
térialisation.
Matérialisation des données disponibles L'objectif de la phase de matérialisation est

d'obtenir des données des sources disponibles et de les conserver de manière à ce qu'elles
puissent être utilisées ultérieurement. Nous décrivons, en section 4.4, l'algorithme materialize
qui, à partir des informations fournies par la phase de détection des sources indisponibles,
obtient les données de certaines sources disponibles et les stocke dans des relations tempo-
raires selon une politique de matérialisation donnée. Cet algorithme prend en compte un
espace de stockage limité.
On peut se poser la question suivante : pourquoi matérialiser les données plutôt que de
conserver le plan d'exécution partiellement exécuté 3 ? Nous avons deux raisons pour favoriser
la matérialisation des données disponibles. Premièrement, exécuter un plan partiellement
évalué demande une modication des opérateurs du moteur d'exécution 4 . Deuxièmement,
les données matérialisées sont conservées par le système sous une forme exploitable par
l'application : l'application peut ainsi extraire des informations partielles se rapportant à la
requête initiale.
Construction de la requête incrémentale Le système utilise les relations temporaires

créées lors de la phase de matérialisation pour construire une requête incrémentale. La requête
incrémentale est la réécriture de la requête initiale en utilisant les relations temporaires.
Nous décrivons en section 4.5 l'algorithme construct qui génère la requête incrémentale.
L'application peut récupérer la requête incrémentale générée par le système et la soumettre
ultérieurement pour obtenir ecacement la réponse complète à sa requête initiale.
L'évaluation de la requête incrémentale fournit le même résultat que la requête initiale à
la condition qu'aucune mise à jour eectuée sur les sources de données n'impacte la validité
des données matérialisées. Si de telles mises à jour ont lieu, les données qui sont matérialisées
ne correspondent plus aux données de la source, et par conséquent l'exécution simultanée de
la requête initiale et de la requête incrémentale donnent des résultats diérents (sous réserve
que les deux requêtes puissent être évaluées).
3. Nous appelons plan partiellement évalué, un plan d'exécution où les structures de données internes déjà
initialisés lors des exécutions précédentes sont conservées
4. Nous avons implanté une solution basée sur la réutilisation du plan partiellement exécuté dans notre
simulateur : le système plan_partiel. Cela nous a demandé de réécrire toute la partie des opérateurs concer-
nant la création, l'initialisation et la destruction des structures de données internes de manière à pouvoir les
conserver entre deux exécutions successives.
On peut considérer deux solutions à ce problème. Dans une première solution, le système
garantit la validité des données matérialisées en assurant leur mise à jour. Le système doit
alors (1) détecter les modications eectuées sur les sources et (2) répercuter les mises à jour
sur les données matérialisées [77].
Dans une deuxième solution, le système laisse à l'application le soin de décider si elle peut
tolérer les diérences éventuelles entre la réponse à la requête incrémentale et la réponse à
la requête initiale.
Nous avons opté pour la deuxième solution de manière à nous concentrer sur la construc-
tion des requêtes incrémentales. Il sera cependant intéressant d'étudier dans quelle mesure
il est possible et raisonnable de mettre en ÷uvre des techniques de maintenance des vues
matérialisées et de les comparer à des techniques d'invalidation de cache par exemple. Cette
étude devrait pouvoir être étendu au cadre des caches sémantiques.
Il est par ailleurs important de noter que, de manière générale, la propriété d'isolation
n'est jamais garantie dans un système de médiation : si des données sont matérialisées lors de
l'exécution d'une requête (par exemple une table de hachage sur la relation intérieure d'un
hash join), rien ne garantit que ces données ne sont pas modiées sur la source de données.
On peut se poser la question suivante : pourquoi proposer à l'application une requête
incrémentale plutôt que de lui laisser soumettre la requête initiale et de la réécrire en utilisant
les relations temporaires? La réponse est la suivante. Pour que le système puisse réécrire la
requête initiale en utilisant les relations temporaires, il doit implanter un algorithme de
type answering queries using views [72]. Notre algorithme de construction de la requête
incrémentale peut être considéré comme une version simpliée de cet algorithme qui prend
en compte le fait que les relations temporaires correspondent à des sous-requêtes de la requête
initiale.
Un autre problème pour l'application consiste à savoir quand soumettre la requête incré-
mentale. En eet, c'est l'application qui décide de soumettre la requête incrémentale pour
obtenir la réponse complète. Il serait intéressant que le système fournisse à l'application
une notication lorsque les sources qui étaient indisponibles redeviennent disponibles. Il doit
pour cela contrôler l'évolution des sources de données (monitoring) [112]. Nous n'avons pas
étudié la mise en ÷uvre de tels mécanismes.
4.2.2 Fonctionnement
Dans un système existant, lorsqu'une requête est soumise, l'optimiseur génère un plan
d'exécution qui est ensuite évalué. Si toutes les sources de données sont disponibles, la réponse
est construite et retournée à l'application. Au cas où un problème survient lorsqu'une source
de données est contactée , une erreur interne est générée. Les résultats intermédiaires produits
par le moteur d'exécution sont supprimés. Un message d'erreur est retourné à l'application.
Dans un système incrémental, lorsqu'une requête q est soumise, le système l'optimise
et procède à la détection des sources indisponibles. Si toutes les sources sont disponibles,
la réponse est construite de manière classique. Si une ou plusieurs sources de données sont
indisponibles, le système procède à la phase de matérialisation : les données des sites dispo-
nibles sont obtenues et stockées dans des relations temporaires. Une requête incrémentale
est construite en utilisant ces relations temporaires. Une fois que la requête incrémentale est
construite, une notication est retournée à l'utilisateur.
Le modèle d'interaction d'un système incrémental est : <q; n1; qi1; n2; : : : ; qik ; a>, où ni
est une notication retournée à l'application, qii est une requête incrémentale, et a est la
réponse complète. Une requête incrémentale diérente est, en général, utilisée à diérentes
étapes de la séquence puisque le système progresse partiellement vers la réponse complète a
en fonction des sources disponibles.
Exemple Considérons à nouveau la requête présentée dans l'exemple précédent. Cette
requête est soumise à un système de médiation incrémental. La source du service de radiologie
n'est pas disponible lorsque le système exécute la requête.
Un système incrémental détecte d'abord que cette source de données est indisponible et
matérialise ensuite les données obtenues à partir des sources de chirurgie et d'administration
qui sont, elles, disponibles. Dans notre exemple, une relation temporaire V1 est crée pour
stocker le résultat de la jointure entre les relations PATIENT, MAP et SURGERY. V1 résulte de
l'expression suivante :
INSERT INTO V1
SELECT *
FROM PATIENT, MAP, SURGERY
AND MAP.SID = SURGERY.ID AND SURGERY.STATUS = 'WAITING';
Une notication est retournée à l'application. Cette notication lui permet d'accéder à la
requête incrémentale que le système a construit. L'application décide de la soumettre au sys-
tème de manière à obtenir la réponse complète. Dans notre exemple la requête incrémentale
générée est la suivante :
SELECT V1.NAME, V1.ROOM, RADIOLOGY.ID, RADIOLOGY.COMMENT

FROM V1, RADIOLOGY
WHERE V1.RID = RADIOLOGY.ID;
4.2.3 Implantation
L'implantation des nouveaux composants mentionnés ci-dessus concerne essentiellement
le médiateur. L'optimiseur classique n'est pas aecté. Des informations particulières doivent
être obtenues concernant les opérateurs algébriques ; il est possible, pour gérer ces infor-
mations de modier les opérateurs ou de manipuler une structure de données annexe. Les
adaptateurs sont eux impactés : ils doivent être capables de détecter les sources indisponibles.
La notication que le système retourne à l'application quand il ne peut pas construire
de réponse à la requête qui lui a été soumise peut être implantée sans modier une inter-
face standard telle que JDBC. Elle peut être dénie comme un type particulier d'exception
retourné par le système de médiation.
Tous les algorithmes que nous décrivons dans les sections suivantes prennent en entrée
un plan d'exécution. Les feuilles de ce plan sont des sous-requêtes soumises aux sources de
données. Les noeuds intérieurs sont des opérateurs algébriques classiques, des jointures par
exemple. La gure 4.2 décrit un plan d'exécution possible pour la requête présentée dans
les exemples précédents. Les lignes pleines relient les opérateurs exécutés sur le médiateur.
Les lignes pointillés relient les opérateurs exécutés sur les sources de données. L'opérateur
submit, toujours situé sur le médiateur, marque l'envoi d'une sous-requête vers une source
de données (via un adaptateur).
Nous utilisons ce plan d'exécution dans le reste du chapitre pour illustrer le fonctionne-
ment des diérents algorithmes.
Π
submit
RADIOLOGY submit
MAP submit submit
σ σ
PATIENT SURGERY
Fig. 4.2 Plan d'exécution pour la requête trouver les patients dont le séjour dépasse 10
jours et qui attendent d' être opérés
4.3 Détection des sources indisponibles

L'algorithme sense détecte les sources disponibles et indisponibles et en déduit les por-
tions du plan d'exécution qui sont évaluables et celles qui ne le sont pas.
Dans un système de médiation, la détection des sources indisponibles est la responsabilité
des adaptateurs. Nous considérons ici que les adaptateurs mettent en ÷uvre des mécanismes
qui leur permettent (1) de détecter qu'ils ne peuvent pas récupérer de réponse d'une source de
données particulière (parce que la connexion ne peut pas être établie, ou parce que la source
Détection des sources indisponibles 61
entrée: un plan d'exécution dont la racine est operateur
sortie: un plan d'exécution annoté
sense (operateur) {
pour tout sous-plan parmi les ls d'operateur {
sense(sous-plan)
}
si (source est disponible) ou
(tous les ls sont disponibles) alors {
marquer operateur disponible
} sinon {
marquer operateur indisponible
}
}
Fig. 4.3 L'algorithme sense de détection des sources indisponibles. L'expression pour
tout évalue ses arguments en parallèle.
renvoie un message explicite indiquant son indisponibilité, ou encore parce que le format des
données retournées par la source a été modié), et (2) de décider que le temps de réponse
d'une source de données n'est pas raisonnable. Nous considérons encore que les adaptateurs
implantent un mécanisme spécique pour détecter qu'une connexion ne peut pas être établie
ou doit être rompue : si la connexion ne peut pas être établie dans un délai inférieur à un délai
donné (i.e. un paramètre du système) alors la source est considérée comme indisponible ; de
même, si aucune donnée n'a été reçue après un délai donné la source est considérée comme
indisponible.
L'algorithme sense est détaillé dans la gure 4.3. Cet algorithme descend récursivement,
et en parallèle, les diérentes branches du plan d'exécution. Quand une sous requête desti-
née à une source de données est rencontrée, l'algorithme teste si cette source de données est
disponible en demandant à l'adaptateur qui lui est associé si une réponse peut être obtenue.
Si c'est le cas, la source est considérée comme disponible, sinon elle est indisponible. L'algo-
rithme sense examine toutes les sources de données en parallèle, superposant ainsi les délais
d'accés aux sources. Une fois les sources de données contactées, le plan d'exécution est par-
couru récursivement des feuilles vers la racine. Chaque noeud dont tous les enfants sont tous
disponibles est marqué disponible (i.e. évaluable); les autres sont marqués indisponibles. Une
fois que le plan est parcouru entièrement, la racine est marquée disponible ou indisponible.
Les sous-plans marqués disponibles peuvent être évalués avec les sources de données qui sont
en état de fournir des réponses.
Une source de données qui est détectée disponible dans un premier temps peut s'avérer
être indisponible lors de l'exécution (dans le cas où elle fournit sa réponse trop lentement).
Dans ce cas, l'exécution est suspendue et l'algorithme sense est appliqué à nouveau. Les
portions du plan d'exécution qui sont évaluables sont ainsi redénies.
I
Π
I D
submit
D D
RADIOLOGY
MAP
D D
submit submit
σ σ
PATIENT SURGERY
Fig. 4.4 Plan d'exécution annoté obtenu en sortie de l'algorithme sense.
Exemple Nous reprenons notre exemple et nous considérons que la source du service
radiologie est indisponible. La gure 4.4 représente le plan d'exécution annoté obtenu en
exécutant l'algorithme de détection des sources. Le plan d'exécution est parcouru récur-
sivement. La connexion avec la source du service radiologie ne peut pas être établie. Par
conséquent l'opérateur qui contacte cette source est marqué indisponible (représenté par un
I sur la gure). Les opérateurs qui contactent les autres sources sont marqués disponibles
(et annotés avec un D sur la gure). Les opérateurs dont tous les ls sont disponibles sont
marqués disponibles. Le sous-arbre qui comprend la jointure des relations MAP, PATIENT et
SURGERY est donc marqué disponible. La racine du plan d'exécution est elle marquée indis-
ponible puisqu'un de ses ls est indisponible. 2
4.4 Matérialisation des données disponibles

Dans le cas où seules certaines portions du plan d'exécution sont évaluables, le système
procède à une deuxième passe sur le plan d'exécution qui consiste à matérialiser certaines
portions du plan en fonction d'une politique de matérialisation.
Nous considérons deux politiques de matérialisation:
la politique des sous arbres maximaux disponibles, appelée max, consiste à matérialiser
les sous-plans les plus larges possibles dont la racine est disponible.
la politique de matérialisation des feuilles du plan d'exécution, appelée feuille, consiste
à matérialiser les sous-requêtes destinées aux sources de données disponibles (i.e. les
feuilles du plan d'exécution).
Exemple En reprenant le plan d'exécution annoté présenté dans la gure 4.4, la politique
max conduit à matérialiser (map ./ (patient ./ surgery ). La politique feuilles conduit elle à
matérialiser le résultat de la sélection sur SURGERY et le résultat de la sélection sur PATIENT
indépendamment. 2
Matérialisation des données disponibles 63
Le principal problème de l'algorithme de matérialisation est de prendre en compte un
espace de stockage limité. Ce problème comporte deux aspects. D'une part, le système doit
gérer l'espace de stockage, et en particulier l'allocation et la libération de l'espace. D'autre
part, l'algorithme de matérialisation doit choisir quelles sous-requêtes matérialiser en fonction
de l'espace de stockage disponible.
Nous considérons qu'une portion de l'espace de stockage est allouée pour le traitement
de chaque requête. L'espace de stockage est nécessaire pour l'évaluation des requêtes ainsi
que pour les matérialisations éventuelles. Dans un modèle d'exécution pipeline, l'espace de
stockage est nécessaire pour stocker les résultats intermédiaires tels que les partitions pour
un hash join ou les blocs de données pour un blocked nested loop join. L'introduction de
matérialisations peut casser le pipeline et donc introduire des besoins en terme de stockage
qui dépassent largement l'espace nécessaire pour exécuter la requête 5
Une solution simple est d'allouer une portion identique de l'espace de stockage pour toutes
les requêtes. Des solutions plus exibles ont également été étudiées [16]. L'espace alloué pour
le traitement d'une requête est libéré dès que la réponse à cette requête est construite ou
après un temps xé (cela permet de prendre en compte les cas où la réponse complète n'est
jamais produite). Dans le cas où le système ne dispose plus d'espace de stockage libre, il doit
libérer l'espace alloué en suivant une politique de remplacement de type LRU.
La gure 4.5 montre l'algorithme de matérialisation. Cet algorithme prend en entrée un
plan d'exécution où chaque noeud est marqué disponible ou indisponible et le nombre de
pages allouées pour l'exécution de ce plan. Dans un premier temps, le plan d'exécution est
traversé pour estimer l'espace nécessaire pour stockage des résultats intermédiaires durant
l'exécution. Le nombre de pages obtenu est retranché du nombre de pages alloué pour le
traitement de la requête. Le nombre de pages obtenu est l'espace restant à disposition pour
les matérialisations. Si ce nombre est inférieur à zéro, alors aucune matérialisation n'est
eectuée. En fait, dans ce cas, il est très probable qu'une erreur survienne durant l'exécution
de la requête puisque l'espace alloué pour ce plan est estimé insusant. Séparer l'espace
nécessaire pour l'exécution de la requête de l'espace utilisé pour les matérialisations est une
approche conservatrice. Elle garantit que la requête peut être exécutée quelles que soient les
matérialisations eectuées.
L'ensemble des sous-plans candidats à la matérialisation est déterminé par la politique
de matérialisation 6 Pour chaque sous-plan candidat à la matérialisation, l'estimation de
l'espace qui lui est nécessaire est calculé et est comparé à l'espace restant disponible pour
les matérialisations. Si l'espace restant est estimé susant, alors le sous-plan candidat est
matérialisé : un opérateur de matérialisation est inséré dans le plan d'exécution et le sous-
plan dont il devient la racine est évalué. Une relation temporaire tmp est créée pour stocker
les données qu'il produit. Les relations temporaires existantes éventuellement utilisées pour
5. Les problèmes sont les mêmes dans le cas d'une exécution non-pipeline. Des résultats intermédiaires
sont stockés après chaque jointure. Certains de ces résultats temporaires sont conservés par l'algorithme
de matérialisation. Ceci entraîne des besoins en terme de stockage qui dépassent l'espace nécessaire pour
exécuter la requête.
6. Dans l'implémentation que nous utilisons pour les simulations (cf. section 6.1.2), les sous-plans candidats
sont considérés selon un parcours en profondeur d'abord du plan d'exécution.
entrées: un plan d'exécution plan

un nombre de pages N
sorties: relations matérialisées
materialize (plan, N) {
Nexec := nombre de pages nécessaires pour exécuter plan
Nleft := N - Nexec
si Nleft <= 0 alors retour
pour tout sous-plan à matérialiser dans plan {
si space-estimate(sous-plan) < Nleft alors {
try {
stocker le résultat de sous-plan dans une relation temporaire tmp
détruire les résultats temporaires utilisés dans sous-plan
Nleft := Nleft + espace libéré par les relations temporaires détruites
- espace eectivement occupé par la relation temporaire tmp
} catch l'espace requis pour matérialisation est supérieur à Nleft pages {
détruire la relation temporaire tmp
}
}
}
Fig. 4.5 L'algorithme de matérialisation des données disponibles prenant en compte un

espace de stockage limité.
Construction de la requête incrémentale 65
I
Π
I V1
submit materialize
RADIOLOGY D
D D
MAP
D D
submit submit
σ σ
PATIENT SURGERY
Fig. 4.6 Plan d'exécution annoté après l'introduction des opérateurs de matérialisation.
construire tmp sont détruites. Si durant la matérialisation, l'espace eectivement utilisé est
supérieur à l'espace restant disponible, alors la relation temporaire courante est détruite.
Autrement, l'espace qui a été eectivement utilisé pour matérialiser le sous-plan est soustrait
de l'espace restant pour les matérialisations.
Nous étudions les caractéristiques de cet algorithme dans la section 6.2.2.
Exemple Reprenons notre exemple, et considérons que la politique max est appliquée
lors de la phase de matérialisation et que l'espace de stockage est susant. La gure 4.6
illustre le plan d'exécution qui est obtenu en introduisant l'opérateur de matérialisation
(materialize) à la racine du sous-plan (map ./ (patient ./ surgery). La relation temporaire
V1 est créée pour stocker le résultat produit par ce sous-plan. 2
En résumé, l'algorithme de matérialisation contacte un sous-ensemble des sources de don-
nés disponibles et créé des relations temporaires pour stocker les données qu'elles fournissent
en fonction de l'espace de stockage dont il dispose. Le fonctionnement de l'algorithme est
illustré lors de l'évaluation en section 6.2.2.
4.5 Construction de la requête incrémentale

La requête incrémentale est une réécriture de la requête initiale qui utilise les relations
temporaires créées lors de la phase de matérialisation. L'algorithme construct que nous
proposons génère la requête incrémentale à partir du plan d'exécution modié et annoté lors
de la phase de matérialisation. Ce plan d'exécution est annoté avec des informations concer-
nant les prédicats de jointures, les attributs projetés, la disponibilité du noeud, la relation
temporaire associée à un opérateur de matérialisation, etc. L'algorithme construct utilise
ces informations pour construire une requête déclarative de manière ascendante (bottom-up).
L'algorithme construct construit la requête incrémentale en utilisant le plan d'exécution
et les relations temporaires créées lors de la phase de matérialisation. La gure 4.7 décrit
l'algorithme construct. Cet algorithme renvoie un 4-uplet contenant une liste de projec-
tion, une liste de relations, une liste de conditions, et une table de mapping (map). Les
trois premières listes permettent de construire une requête SQL. La table de mapping est
utilisée dans l'algorithme pour renommer les variables de manière à ce que les expressions
générées référencent les relations temporaires (contenant les données matérialisées) plutôt
que les relations d'origine. Les sous-plans matérialisés génèrent les expressions déclaratives
qui accèdent aux relations temporaires matérialisées. Ce sont des expressions de la forme
select from r où r est le nom d'une relation temporaire.
Cet algorithme, qui considère uniquement les requêtes conjonctives, peut être étendu au
cas d'une union de requêtes conjonctives u. En fait, il sut de transformer le plan d'exécution
de u en une forme normale disjonctive (i.e. la racine est le seul opérateur d'union dans le plan
d'exécution), d'appliquer l'algorithme construct sur chaque branche du plan correspondant
à une requête conjonctive et de construire l'union des requêtes ainsi construites.
La preuve que la requête incrémentale qui est construite correspond bien au plan d'exé-
cution peut être établie simplement par récurrence (en partant de l'expression déclarative
correspondant à un opérateurs materialize ou scan, il s'agit de montrer que si un opéra-
teur select, project, ou join est ajouté dans le plan d'exécution alors l'expression déclarative
qui est générée est correcte). Le théorème de Codd [61] garantit que chaque expression de
l'algèbre relationnelle peut être transformée dans une expression équivalente dans le calcul
relationnel).
Une requête incrémentale est évaluée en utilisant des relations temporaires qu'elle réfé-
rence. Il est possible que ces relations temporaires aient été détruites avant que la requête
incrémentale soit soumise (parce que le médiateur a du libérer de l'espace de stockage ou
parce que le délai entre la soumission de la requête initiale et de la requête incrémentale est
important). Dans ce cas, le système retourne une notication à l'application qui doit sou-
mettre à nouveau la requête initiale. C'est le prix à payer pour la simplicité de l'algorithme
de construction de la requête incrémentale. Cet inconvénient n'existerait pas si la requête ini-
tiale était réécrite lors de chaque soumissions avec un algorithme de type answering queries
using views où seules les relations temporaires présentes sont utilisées.
Exemple Nous pouvons illustrer l'algorithme de construction de la requête incrémentale
dans le cadre de notre exemple. Nous reprenons le plan d'exécution annoté, présenté dans la
gure 4.4, en considérant que le sous-arbre (map ./ (patient ./ surgery)) a été matérialisé
par l'algorithme materialize dans la relation temporaire V1.
Le résultat de l'algorithme construct appliqué à ce plan d'exécution annoté est un 4-
uplet composé de la liste de projection, de la liste de relations, de la liste de conditions qui
permettent de formuler une requête en SQL et d'un tableau de mise en correspondance pour
les variables manipulés dans les trois listes précédentes. Tout d'abord, la liste des relations est
obtenue récursivement: chaque nom de relation est obtenu d'un opérateur matérialisé ou d'un
opérateur de scan sur une relation. A chaque relation est associée une variable de renommage.
La liste de relation est donc {(x1, r1), (radiology, r2)}. Le tableau de mise en correspondance
Construction de la requête incrémentale 67
entrée: un plan d'exécution annoté operateur

sortie: un 4-uplet (S; F; W; M )
construct (operateur) {
S : = la liste de projection associée à operateur
W : = la liste de conditions associée à operateur
si operateur est matérialisé alors {
x : = une variable unique
X : = l'identiant de la relation matérialisée
V : = l'ensemble des variables qui apparaissent dans la
sous-plan opérateur
M : = (V; x)
retourner (map(M; S ), f(x; X )g, ;, M)
} sinon si operateur est un join alors {
(S1; F1; W1 ; M1) : =construct(sous , arbre , gauche(operateur))
(S2; F2; W2 ; M2) : =construct(sous , arbre , droit(operateur))
M : = M1 [ M2
retourner (map(M; S1 [ S2), F1 [ F2,
map(M; W ) [ W1 [ W2 , M )
} sinon si operateur est un project alors {
(S1; F1; W1 ; M1) : =construct(fils(operator))
retourner (map(M1,S ), F1 , W1 , M1)
} sinon si operateur est un select alors {
(S1; F1; W1 ; M1) : =construct(fils(operator))
retourner (S1, F1 , W [ W1 , M1)
} sinon si operateur est un scan alors {
x : = une variable unique
X : = l'identiant de la relation operateur
V : = la variable qui apparait dans le scan operateur
retourner (S , (x; X ), ;, (V; x))
}
}
Fig. 4.7 Construction de la requête incrémentale. La fontion map remplace les occurences
des variables en fonction d'un mapping donné.
associe à chacune des variables ainsi dénies l'ensemble des variables de renommage de la
requête initiale à laquelle elle correspond. Dans le cas où la variable est générée à partir d'un
opérateur matérialisé, cette variable est associée à toutes les relations couvertes par ce sous-
arbre. Dans notre exemple, le tableau de mise en correspondance contient les associations
suivantes: {(r1, {map, patient, surgery}), (r2, radiology)}. La liste de projection est obtenue
à partir de l'opérateur project à la racine du plan d'exécution. Cette liste de projection
est transformée en utilisant le tableau de mise en correspondance de manière à ce que les
variables de renommage référencées dans la liste de relations soient utilisées dans la liste
de projection: {r1.name, r1.room, r2.id, r2.comment}. La liste de conditions est obtenue
récursivement à partir des opérateurs de sélections et de jointures (uniquement à partir
d'un opérateur de jointure dans notre exemple). Ici aussi les conditions sont transformées
en utilisant la table de mise en correspondance: {r1.rid = r2.id}. La requête incrémentale
construite à partir de ce 4-uplet est la suivante:
SELECT r1.NAME, r1.ROOM, r2.ID, r2.COMMENT
FROM V1 r1, RADIOLOGY r2
WHERE r1.RID = r2.ID;
4.6 Comparaison avec des travaux existants

Nous discutons ici des travaux eectués dans trois domaines se rapprochant de diérents
aspects du traitement incrémental des requêtes.
Query Scrambling L'approche incrémentale du traitement des requêtes est fortement

liée à la technique de query scrambling : une technique d'optimisation dynamique des re-
quêtes [3] [4] [104]. Les deux approches sont basées sur l'idée que du travail utile peut être
eectué pendant qu'une ou plusieurs sources sont bloquées (i.e., ne répondent pas rapide-
ment). Le travail utile est ici (a) la matérialisation de résultats intermédiaires ou (b) la
synthèse de nouveaux opérateurs pour manipuler les résultats intermédiaires disponibles.
La technique de query scrambling fait l'hypothèse que toutes les sources de données
répondent dans un délai raisonnable. Lorsque tout le travail utile a été eectué, le système
attend simplement que les sources bloquées produisent leurs données. Or, nous avons vu
que certaines sources de données peuvent être temporairement indisponibles, ou fournir leur
réponse dans un délai qui n'est pas raisonnable. Les sources indisponibles ne sont pas prises
en compte par les techniques de query scrambling.
Choix des vues à matérialiser Le problème de matérialiser une partie d'un plan d'exé-
cution étant donné un espace de stockage limité a été abordé dans diérents contextes. Des
techniques de sélection de vues (view selection) ont été développées pour choisir quelles vues
Conclusions et perspectives 69
matérialiser dans un plan d'exécution étant donnés les coûts de mise à jour et un espace de
stockage limité dans un entrepôt de données [52] [67]. Ces techniques ne correspondent pas
au cadre de notre étude. Premièrement, elles considèrent les coûts de mise à jour que nous
ne considérons pas. Deuxièmement, l'objectif de ces techniques est de fournir une solution
optimale. Cet objectif n'est pas raisonnable dans notre contexte, d'une part, parce que les
estimations de taille des sous-requêtes qui doivent être utilisées pour la sélection de vues ne
sont pas ables, et d'autre part, parce que le problème de l'espace de stockage limité est
relativement marginal dans notre étude (l'espace de stockage n'est pas cher); nous sommes
donc intéressés par une solution simple qui garantisse l'exécution des requêtes avec l'espace
de stockage alloué.
Construction de la requête incrémentale Nous avons vu qu'une alternative à la

construction de la requête incrémentale est d'intégrer un algorithme de type answering que-
ries using views dans le système.
L'algorithme answering queries using views de Levy et al. [72] est par exemple décom-
posé en deux phases. Premièrement, les vues contenues dans la requête sont identiées et
concaténées à la requête intiale. Dans un deuxième temps, les éléments redondants sont
éliminés.
L'exemple suivant est tiré de l'article de Levy et al. [72].
Soient une requête Q et une vue V :
Q : q(X,U) p(X,Y) ^ p0(Y,Z) ^ p1(X,W) ^ p2(W,U)
V : v(A,B) p(A,C) ^ p0(C,B) ^ p1(A,D)
La requête peut être réécrite en utilisant V de la manière suivante :
Q': q(X,U) v(X,Z) ^ ^ p1(X,W) ^ p2(W,U)
Notre algorithme de construction de la requête incrémentale est une forme spécialisée de

l'algorithme answering queries using views. La phase d'identication des vues matérialisées
contenues dans la requête n'est pas nécessaire puisque seules des sous-requêtes matérialisées
sont utilisées pour la réécriture. Les sous-requêtes matérialisées sont simplement remplacées
dans la requête réécrite par les relations temporaires correspondantes.
4.7 Conclusions et perspectives

Dans ce chapitre, nous avons proposé un ensemble d'algorithmes pour le traitement in-
crémental des requêtes en présence de sources de données indisponibles. L'algorithme de
détection des sources disponible établit les portions du plan d'exécution qui sont évaluables
et celles qui ne le sont pas. L'algorithme de matérialisation permet de stocker les données
obtenues des sites disponibles dans des relations temporaires en fonction d'un espace de
stockage limité. L'algorithme de construction de la requête incrémentale permet d'obtenir
une requête équivalente à la requête initiale basée sur les relations temporaires qui ont été
matérialisées.
Nous avons implanté une première version de ces algorithmes dans Disco [100]. Cela
nous a permis de vérier la faisabilité de notre approche. Nous avons par la suite implanté la
version des algorithmes présentés dans ce chapitre dans notre simulateur. Nous avons ainsi
pu étudier les aspects des performances relatifs au temps de traitement dans un système
incrémental ainsi que les aspects liés aux nombres de soumissions nécessaires pour obtenir
la réponse complète. L'évaluation des performances est présentée dans le chapitre 6.
Les algorithmes que nous proposons peuvent être implantés dans un système de médiation
existant sans modication de l'optimiseur ou du moteur d'exécution. Il sera intéressant de
spécier le traitement incrémental des requêtes pour un système de médiation existant autre
que Disco pour vérier l'impact de nos algorithmes sur les architectures existantes et pour
dénir les modications que nous devrons apporter à nos algorithmes pour prendre en compte
les requêtes autres que les unions de requêtes conjonctives (contenant notamment des tris,
des agrégats ou des requêtes imbriquées)
Il sera également intéressant d'adapter ces algorithmes à un système de médiation inté-
grant un algorithme de type answering queries using views. Le problème de la détection des
sources indisponibles et de la matérialisation des données étant donné un espace de stockage
limité se posent de la même manière. L'intérêt des requêtes incrémentales reste à discuter
dans ce contexte.
L'algorithme de matérialisation est basé sur l'hypothèse que toutes les sources de données
ont la même probabilité d'être indisponible. Aucune distinction n'est faite entre les diérentes
sources. Or, si une source s'avère être souvent indisponible, le système pourrait faire un eort
particulier chaque fois qu'elle est détectée disponible : le système pourrait s'assurer qu'il a
les moyens de matérialiser les données qu'il peut obtenir de cette source en augmentant
éventuellement l'espace de stockage alloué à la requête et en considérant la sous-requête
destinée à cette source en priorité. Inversement, le système pourrait s'abstenir de matérialiser
les données obtenues des sources très souvent disponibles. Le problème dans ce contexte est
de distinguer les sources souvent disponibles des sources souvent indisponibles. Le système
pourrait gérer des statistiques sur la disponibilité des sources (basées sur les résultats de
l'algorithme sense) ou bien fournir les moyens à un utilisateur privilégié d'associer à chaque
source un type de disponibilité.
Deux éléments permettront d'améliorer le traitement incrémental des requêtes. Premiè-
rement, le contrôle de la disponibilité des sources (monitoring) devrait permettre au système
de notier l'application que des sources jusque là indisponibles sont à nouveau disponibles.
Le problème est de dénir un mécanisme de contrôle des sources de données qui soit ecace
(i.e. qui détecte rapidement qu'une source est à nouveau disponible), facile à gérer pour le
système et qui n'entraîne pas une augmentation trop importante du nombre de messages
échangés sur le réseau. Deuxièmement, les algorithmes que nous avons présentés concernent
le traitement incrémental de chaque requête indépendamment. Il sera important d'étudier
comment les données obtenues lors du traitement incrémental d'une requête peuvent être
réutilisées pour d'autres requêtes. C'est en fait le problème du lien entre le traitement incré-
Conclusions et perspectives 71
mental des requêtes et les techniques de cache sémantique.
73
Chapitre 5
Extraction d'informations partielles
5.1 Introduction
Un utilisateur peut parfois se contenter d'une réponse partielle 1 à la requête qu'il a
posée. Notamment dans le cas où une ou plusieurs sources de données sont temporairement
indisponibles, un système de médiation ne peut pas construire la réponse complète à une
requête les concernant ; il peut par contre fournir des informations partielles. Si l'on considère
la requête ad-hoc issue de l'application du complexe hospitalier permettant de trouver les
informations administratives et les informations radiologiques des patients dont le séjour
dépasse 10 jours et qui attendent d'être opérés, le nom des personnes qui attendent d'être
opéré peut représenter, du moins dans un premier temps, une réponse partielle satisfaisante.
Dans le cas de l'application Redoc, l'utilisateur peut en général se contenter d'un sous-
ensemble de la réponse complète.
5.1.1 Requêtes parachutes

L'extraction d'informations partielles pose plusieurs problèmes :
Quelles sont les informations partielles que le système est capable de fournir?
Comment l'application interagit-elle avec le système pour extraire des informations
partielles? Comment l'application communique-t-elle à l'utilisateur la signication de
ces informations partielles?
Comment l'utilisateur communique-t-il à l'application les informations partielles qui
l'intéressent ou non?
1. Nous avons dans [11]et [14] utilisé le terme réponse partielle pour désigner la notication retournée à
l'utilisateur. Nous utilisons dans ce document une dénition plus intuitive de ce terme (cf. le glossaire de
l'annexe A).
74 Extraction d informations partielles
Nous sommes dans un scénario où l'application a soumis une requête et le système ne peut
pas construire de réponse exacte car une ou plusieurs sources de données sont indisponibles.
Nous considérons que le système de médiation met en oeuvre le traitement incrémental des
requêtes décrit dans le chapitre précédent.
Le premier problème est de dénir quelles sont les informations partielles que le système
peut fournir. Nous distinguons trois cas de gure : (i) les données partielles peuvent être
obtenues en contactant des sources de données alternatives dont le contenu correspond , au
moins partiellement, à celui des sources de données indisponibles ; (ii) les données partielles
peuvent être obtenues d'un cache sémantique, i.e. de réponses à des requêtes déjà exécutées ;
(iii) dans le cadre d'un système incrémental, les données partielles peuvent être extraites des
relations temporaires où sont stockées les données obtenues des sources disponibles. Nous
nous concentrons dans ce chapitre sur ce dernier aspect : les données partielles que le
système peut fournir ont été obtenues des sources disponibles lors de l'exécution
de la requête initiale.
Le deuxième problème concerne l'interaction entre l'application et le système pour l'ex-
traction d'informations partielles. Cette extraction peut être implicite : si le système ne peut
pas construire la réponse exacte à la requête qui lui est posée, alors il renvoie des informations
partielles. C'est l'approche choisie par les techniques de traitement approché des requêtes
(voir section 3.3.2), ou par Information Manifold (voir section 2.4.2.1). La relation entre
la réponse partielle et la réponse exacte est dénie une fois pour toutes, c'est par exemple
la relation d'inclusion dans Information Manifold. L'application ne connaît cependant pas
la signication exacte des informations partielles qu'elle obtient. Une alternative est que
l'extraction des informations partielles soit explicite. L'application indique au système de
médiation les informations partielles qu'elle souhaite extraire. Le moyen naturel pour une
application de spécier les données qu'elle souhaite extraire est de formuler une requête.
Denition 5 (Requête parachute) Nous appelons requête parachute une requête qui
permet d'obtenir de l'information partielle au cas où la requête initiale ne peut pas être
évaluée.
Nous nous intéressons dans le reste du chapitre à l'approche explicite et à l'utilisation de
requêtes parachutes.
Exemple Dans l'exemple de requête ad-hoc issu de l'application hospitalière permettant
de trouver les informations administratives et les informations radiologiques des patients dont
le séjour dépasse 10 jours et qui attendent d'être opérés, une requête parachute permettant
à l'utilisateur d'accéder à des données partielles pourrait être : trouver le nom et le numéro
de chambre des patients qui attendent d'être opérés
SELECT PATIENT.NAME, PATIENT.ROOM
WHERE PATIENT.ID = MAP.PID
AND MAP.SID = SURGERY.ID
AND SURGERY.STATUS = 'WAITING';
Introduction 75
2
L'utilisation des requêtes parachutes pose deux problèmes essentiels : comment l'appli-
cation peut-elle formuler des requêtes parachutes et comment le système peut-il évaluer ces
requêtes parachutes?
5.1.2 Formulation des requêtes parachutes

Nous distinguons deux scénarios pour la formulation de requêtes parachutes. Dans le
premier scénario, l'application transmet une requête à laquelle le système de médiation ne
peut répondre parce qu'une ou plusieurs sources de données sont indisponibles. Le système
envoie donc une notication à l'application et lui donne des indications sur les informations
partielles qu'il peut lui fournir.
Ceci pose plusieurs problèmes :
comment le système décide-t-il quelles sont les informations partielles qu'il permet
d'extraire?
comment l'application peut- elle prendre en compte ces indications pour générer des
requêtes parachutes?
comment l'application peut- elle communiquer avec l'utilisateur pour lui permettre de
sélectionner les requêtes parachutes qui l'intéressent?
Dans ce scénario les requêtes parachutes sont générées après que la requête initiale (ou
la requête incrémentale) ait été évaluée. Un exemple de séquence d'interaction est donc
<q; n1; 1; 1 ; qi1; : : : ; nk ; qik ; a>, où q désigne la requête initiale, i une requête parachute, i
la réponse à une requête parachute, i.e. une réponse partielle, qi1 une requête incrémentale, ni
une notication renvoyée par le système lorsque la réponse complète ne peut pas être fournie
et a désigne la réponse complète. Il est bien sûr possible que l'utilisateur se contente de la
réponse à une requête parachute et ne demande pas la réponse complète à sa requête initiale.
Les requêtes parachutes et les requêtes incrémentales peuvent être mélangées librement. Nous
appelons ce modèle d'interaction un modèle sans contrainte car l'optimisation de q n'est pas
contrainte par la connaissance de i.
Dans le deuxième scénario, l'application permet à l'utilisateur, lorsqu'il formule une re-
quête, d'indiquer les informations partielles qu'il peut gérer. On peut par exemple considé-
rer que l'interface utilisateur des hôpitaux basques permet, lorsqu'une requête ad-hoc est
formulée, d'indiquer quels attributs sont indispensables pour que le résultat soit intéres-
sant et quels attributs ou quelles relations peuvent être omis de la réponse. Ainsi, dans
ce scénario, l'application peut générer un ensemble de requêtes parachutes associées à la
requête initiale. Le problème dans ce cas pour le système de médiation est de tirer parti
de la connaissance a priori des requêtes parachutes qui intéressent l'utilisateur pour aug-
menter ses chances d'y apporter une réponse dans le cas où une ou plusieurs sources de
données sont indisponibles. Nous dénissons le modèle sous contrainte où le système de mé-
diation optimise simultanément la requête initiale et les requêtes parachutes pour assurer
que les informations nécessaires à l'évaluation de ces dernières se trouveront dans l'état du
médiateur (sous réserve que les sources de données concernées par les requêtes parachutes
soient disponibles). Un exemple de séquence d'interaction dans un système sous contrainte
est <(q; 1; 2 ); (n1; 1; 2); (i1 ; 3); : : : ; a>. Les requêtes parachutes sont soumises avec la
requête initiale. La réponse aux requêtes parachutes peut être obtenue une fois que la noti-
cation est retournée à l'utilisateur.
5.1.3 Évaluation des requêtes parachutes

Nous avons vu qu'une requête parachute permet d'extraire des informations partielles des
états intermédiaires du traitement d'une requête, i.e. des relations temporaires qui stockent
les données obtenues des sources disponibles lors de l'exécution de la requête initiale.
Dans le cas général, l'évaluation d'une requête parachute en utilisant ces relations tempo-
raires nécessite une étape de réécriture. La requête parachute doit en eet être réécrite pour
utiliser les relations temporaires. L'algorithme de génération de requête parachute que nous
présentons inclut une étape de réécriture. Un système de médiation, modié pour mettre en
÷uvre le traitement incrémental des requêtes est ainsi capable d'extraire des informations
partielles sans implanter un algorithme de type answering queries using views.
Avec le modèle sous contrainte où les requêtes parachutes sont soumises en même temps
que la requête initiale, les plans d'exécution pour les requêtes parachutes sont générés pendant
la phase d'optimisation. Les informations partielles sont obtenues en demandant l'évaluation
d'un de ces plans d'exécution.
5.2 Génération de requêtes parachutes

5.2.1 Cadre général
La gure 5.1 présente le cadre général pour la génération de requêtes parachutes. Un
ensemble de requêtes parachutes PQ est généré à partir (i) de la requête initiale Q, (ii)
d'informations fournies par l'utilisateur et (iii) d'informations fournies par le système.
Nous nous plaçons dans cette section du point de vue d'une application ou d'un outil
de génération de requêtes parachutes interfacé avec le système d'un côté et l'utilisateur de
l'autre.
Nous avons, en introduction, identié les problèmes essentiels pour la génération de re-
quêtes parachutes : (1) quelles sont les informations partielles que le système permet d'ex-
traire? (2) Comment l'utilisateur indique-t-il les informations partielles qui l'intéressent? (3)
Comment générer un ensemble de requêtes parachutes à partir des indications fournies par
Génération de requêtes parachutes 77
Informations utilisateur
Generation de requetes
Q PQ
parachutes
Informations systeme
Fig. 5.1 Génération des requêtes parachutes.
le système et des indications fournies par l'utilisateur? (4) Comment présenter à l'utilisateur
la ou les requêtes parachutes générées? Nous discutons chacun de ces points ci-dessous.
Indications fournies par les système Nous nous concentrons dans ce chapitre sur les
informations partielles obtenues à partir des états intermédiaires d'un traitement incrémen-
tal des requêtes. Les informations partielles sont donc extraites des relations temporaires
qui stocke les résultats des sous-requêtes disponibles matérialisées par le système incrémen-
tal (la phase de matérialisation dans un système incrémental est décrite dans le chapitre
précédent). Le système indique à l'application les informations partielles qu'il permet d'ex-
traire en donnant une liste de vues matérialisées, i.e. la liste des sous-requêtes qui ont été
matérialisées.
Indications fournies par l'utilisateur L'utilisateur doit pouvoir indiquer à l'application

les requêtes parachutes qui l'intéressent. Dans le premier scénario que nous avons identié,
l'application donne à l'utilisateur des indications sur les réponses partielles qu'elle peut
lui fournir. Elle peut notamment présenter la liste des sources disponibles et des sources
indisponibles. L'utilisateur utilise ces indications pour spécier les informations partielles
qu'il peut gérer. Dans le deuxième scénario, l'utilisateur indique les informations partielles
qui l'intéressent sans aide du système.
L'utilisateur a plusieurs moyens pour indiquer les réponses partielles qui l'intéressent.
Une première possibilité est que l'utilisateur formule explicitement les requêtes parachutes en
utilisant un langage de requête, comme SQL, ou un langage visuel, tel que QBE par exemple.
L'avantage de cette approche est que l'utilisateur indique très précisément les informations
partielles qui l'intéressent. L'inconvénient est que tout le travail de génération des requêtes
parachutes est eectué par l'utilisateur.
Une deuxième possibilité est que l'utilisateur donne des indications sur les réponses par-
tielles qu'il accepte en laissant à l'application le soin de générer les requêtes parachutes
correspondantes. Un moyen pour l'utilisateur de spécier les réponses partielles qu'il peut
gérer est d'indiquer leur relation avec la réponse complète. Cette approche a l'avantage de la
simplicité pour l'utilisateur. Elle demande cependant à l'application de gérer une interface
11111111
00000000 111111
000000
00000000
11111111
00000000
11111111 000000
111111
000000
111111
00000000
11111111 000000
111111
00000000
11111111 000000
111111
11111111
00000000 00000000
11111111
00000000
11111111 11111
00000 000000
111111
000000
111111
00000000
11111111 00000000
11111111 00000
11111 000000
111111
00000000
11111111 00000000
11111111 00000
11111 000000
111111
00000000
11111111
00000000
11111111 00000000
11111111 00000
11111
00000
11111 000000
111111
00000000
11111111 00000000
11111111 00000
11111 000000
111111
00000000
11111111 00000000
11111111 00000
11111 000000
111111
00000000
11111111 00000000
11111111 00000
11111 000000
111111
00000000
11111111 00000000
11111111
00000000
11111111 00000
11111 000000
111111
000000
111111
00000000
11111111 00000000
11111111 00000
11111 000000
111111
00000000
11111111 00000000
11111111 00000
11111 000000
111111
00000000
11111111
00000000
11111111 000000
111111
000000
111111
00000000
11111111 000000
111111
00000000
11111111 000000
111111
(a) (b) (c) (d)
1111
0000
0000
1111
0000
1111
0000
1111
0000
1111
0000
1111
0000
1111
0000
1111
0000
1111
0000
1111
0000
1111
0000
1111
0000
1111
0000
1111
0000
1111
0000
1111
(e)
Fig. 5.2 Relation entre réponse complète et réponse partielle (en grisé) : (a) la réponse
partielle est en (a) un sous-ensemble, en (b) un sur-ensemble, en (c) un sous-ensemble
généralisé, en (d) un sur-ensemble généralisé de la requête initiale. (e) représente le cas où
la réponse complète et la réponse partielle ont une intersection non vide mais où la relation
entre les deux ensembles ne peut pas être établie.
utilisateur plus complexe (qui donne les moyens à l'utilisateur de spécier la relation entre
la requête initiale et la requête parachute) et d'implanter un algorithme de génération de
La gure 5.2 représente les diérentes relations qui peuvent exister entre une réponse
partielle et la réponse complète. Nous nous intéressons dans la suite du chapitre uniquement
aux cas où tous les attributs d'une réponse partielle apparaissent dans la réponse complète.
Cette hypothèse est restrictive, car elle empêche une réponse partielle de contenir des attri-
buts n'apparaissant pas dans la requête initiale. Cette hypothèse est cependant raisonnable ;
elle signie que l'utilisateur peut se passer de certains attributs qui sont projetés dans la
requête initiale.
De manière informelle un réponse partielle peut :
(a) être un sous-ensemble de la réponse complète, elle contient les mêmes attributs et
moins de tuples ;
(b) être un sur-ensemble de la réponse complète, elle contient les mêmes attributs et
plus de tuples (tous les tuples de la réponse complète apparaissent dans la réponse
partielle) ;
(c) être un sous-ensemble généralisé de la réponse complète, elle contient moins d'at-
tributs et moins de tuples (ou éventuellement autant) que la réponse complète ;
(d) être un sur-ensemble généralisé de la réponse complète, elle contient moins d'attri-
buts et plus de tuples (ou éventuellement autant) que la réponse complète ;
(e) avoir une intersection non nulle avec la réponse complète sans qu'aucune des re-
lations ci-dessus ne soit vériée. La réponse partielle contient moins d'attributs (ou
éventuellement autant) que la réponse complète. Elle contient des tuples qui n'appa-
raissent pas dans la réponse complète et il existe des tuples de la réponse complète qui
n'apparaissent pas dans la réponse partielle.
Ces relations entre les réponses partielles qui sont intéressantes pour l'utilisateur et la
réponse complète sont traduites en des relations entre les requêtes parachutes et la requête
initiale. Les dénitions des relations de sous-ensemble, sur-ensemble, sous-ensemble généralisé
et sur-ensemble généralisé concernant les requêtes sont dénies comme suit.
Denition 6 (Sous-ensemble) Q1 est un sous-ensemble de Q2, noté Q1 Q2 , pour

toutes bases de données D, Q1 (D) Q2 (D)
Qi(D) dénote l'ensemble des réponses à Qi dans la base de données D.
Denition 7 (Sur-ensemble) Q1 est un sur-ensemble de Q2 , noté Q1 Q2 , pour toutes

bases de données D, Q1 (D) Q2 (D)
Il est à noter que lorsque Q1 est un sous-ensemble de Q2 alors Q2 est un sur-ensemble de

Q1 .
Denition 8 (Sous-ensemble généralisé) Q1 est un sous-ensemble généralisé de Q2 , noté

Q1 ,! Q2 , pour toutes bases de données D, Q1 (D) v[ Q2 (D)
Denition 9 (Sur-ensemble généralisé) Q1 est un sur-ensemble généralisé de Q2 , noté

Q1 ,! Q2 , pour toutes bases de données D, Q1 (D) v] Q2 (D)
Les ordres de Hoare et de Smyth sont dénis en section 3.3.2. Il est à noter que lorsque
Q1 est un sous-ensemble généralisé de Q2 alors Q2 n'est pas un sur-ensemble généralisé de
Q1 .
Indiquer une relation acceptable entre une réponse partielle et la réponse complète est
un moyen pour l'utilisateur de spécier les réponses partielles qui l'intéressent. L'utilisateur
peut interagir avec l'application de manière plus précise et spécier les attributs qu'il veut
absolument voir apparaître dans la réponse partielle et ceux qui peuvent en être absents. Il
peut éventuellement indiquer les conditions qui peuvent être relâchées ou renforcées.
Exemple En pratique l'interaction entre l'application et l'utilisateur peut être assez
simple. Dans le cas de l'application du complexe hospitalier, il est possible d'étendre l'inter-
face graphique pour permettre à l'utilisateur de spécier les attributs et les relations dont il
a absolument besoin et ceux dont il peut se passer. 2
Exemple Dans le cas de Redoc, l'interface utilisateur permet une recherche par mots-
clés sur un ensemble de sources. La requête initiale générée par l'application est une union
sur les relations exportées par les diérentes sources de données. Lorsqu'une ou plusieurs
sources de données sont indisponibles, les données obtenues des sources disponibles forment
un sous-ensemble de la réponse complète. Il n'est donc pas nécessaire au niveau de l'interface
utilisateur de demander quelle relation peut exister entre la réponse partielle et la réponse
complète. Il sut de demander à l'utilisateur s'il est intéressé par un sous-ensemble de la
réponse complète. 2
Algorithme de génération de requêtes parachutes Étant donnés la requête initiale

et les indications du système et des utilisateurs, un algorithme de transformation de requête
génère un ensemble de requêtes parachutes. Nous présentons un algorithme de génération de
requêtes parachutes dans la section suivante.
Communication des informations partielles Une fois les requêtes parachutes générées,
l'application doit les présenter à l'utilisateur pour que celui-ci choisisse les réponses partielles
qu'il souhaite obtenir ou simplement pour qu'il prenne connaissance de la signication précise
des réponses partielles qu'il obtient.
Une possibilité pour l'application est de présenter explicitement la requête parachute, par
exemple, en achant le code SQL de la requête. Il est beaucoup plus facile à un utilisateur de
comprendre du code SQL que d'en écrire 2. Si la requête a été formulée de manière graphique,
avec une interface QBE par exemple, la requête parachute peut être présentée comme un
formulaire QBE pré-rempli. Une formulation de la requête en langage naturel peut permettre
une meilleure acceptation par l'utilisateur nal.
Une autre possibilité est de présenter les éléments de la requête qui permettent à l'utili-
sateur de comprendre précisément le sens des réponses partielles qu'il reçoit. Dans le cadre
de l'application Redoc par exemple, il sut de présenter la liste des sources disponibles pour
que la réponse partielle soit parfaitement identiée.
5.2.2 Algorithme
5.2.2.1 Exemple et Problèmes
Pour illustrer les problèmes liées à la génération de requêtes parachutes, nous prenons un
exemple plus complexe que celui du complexe hospitalier, nous reviendrons sur cet exemple
2. C'est du moins ce que défend A.Motro.
à la n de cette section.
Exemple Un concessionnaire de voitures utilise une application qui repose sur un système
de médiation. Ce dernier intègre quatre sources de données : la première de ces source décrit
les constructeurs et les modèles de voitures allemandes, la deuxième source donne le prix des
voitures allemandes, la troisièmes source décrit les constructeurs et les modèles de voitures
italiennes, la quatrième source donne le prix des voitures italiennes, et la cinquième source
donne la couleur des modèles de voitures européennes. Le concessionnaire pose la requête
suivante : trouver les modèles et le prix de voitures italiennes et allemandes disponibles en
rouge. L'application génère donc la requête suivante qu'elle soumet au système de médiation :
SELECT ITALIAN_CAR.MANUF, ITALIAN_CAR.MODEL, ITALIAN_PRICE.PRICE,
CAR_COLOR.COLOR
FROM ITALIAN_CAR, ITALIAN_PRICE, CAR_COLOR
WHERE ITALIAN_CAR.MODEL = CAR_COLOR.MODEL
AND ITALIAN_CAR.MODEL = ITALIAN_PRICE.MODEL
AND CAR_COLOR.COLOR = 'RED'
UNION
SELECT GERMAN_CAR.MANUF, GERMAN_CAR.MODEL, GERMAN_PRICE.PRICE,
CAR_COLOR.COLOR
FROM GERMAN_CAR, GERMAN_PRICE, CAR_COLOR
WHERE GERMAN_CAR.MODEL = CAR_COLOR.MODEL
AND GERMAN_CAR.MODEL = GERMAN_PRICE.MODEL
AND CAR_COLOR.COLOR = 'RED' ;
submit submit
Π submit submit
Π submit submit
Π σ Π σ
ITALIAN_PRICE GERMAN_PRICE
ITALIAN_CAR Π GERMAN_CAR Π
CAR_COLOR CAR_COLOR
Fig. 5.3 Plan d'exécution pour la requête trouver les modèles et le prix de voitures italiennes
et allemandes disponibles en rouge .
Considérons maintenant le cas où la sources de données décrivant les couleurs et la
source de données donnant le prix des voitures allemandes sont indisponibles. Le système
de médiation incrémental détecte l'indisponibilité de ces sources et procède à une phase de
matérialisation (le plan d' exécution choisi est présenté sur la gure 5.3). La politique de
matérialisation des feuilles est utilisée. L'espace de stockage nécessaire étant disponible, trois
relations temporaires sont créées :
V1 contient tous les modèles de voitures italiennes
SELECT MANUF, MODEL FROM ITALIAN_CAR ;
V2 contient les prix de certains modèles de voitures italiennes

SELECT MODEL, PRICE FROM ITALIAN_PRICE ;
V3 contient tous les modèles de voitures allemandes

SELECT MANUF, MODEL FROM GERMAN_CAR ;
La gure 5.4 représente le contenu de ces trois relations temporaires par rapport à la réponse
complète.
Si l'utilisateur n'impose pas de relations entre la requête initiale et les requêtes parachutes,
il doit pouvoir obtenir les modèles, les constructeurs et les prix des voitures italiennes, les
modèles et constructeurs de voitures allemandes ainsi que les modèles et constructeurs de
voitures allemandes et italiennes. 2
V1
V2
MANUF MODEL PRICE COLOR
V3
Fig. 5.4 Position des relations temporaires stockées sur le médiateur (V1, V2, V3) par
rapport à la réponse complète (représentée par une table possédant deux colonnes - de gauche
à droite le constructeur, le modèle de voiture, le prix et la couleur).
Le problème de la génération des requêtes parachutes est de grouper les vues exportées
par le système de manière à obtenir une information partielle la plus informative et la plus
complète possible.
5.2.2.2 Algorithme gen-n-pq
Pour répondre à ce problème nous avons déni l'algorithme gen-n-pq. Cet algorithme
génère un ensemble de requêtes parachutes étant donnés :
la requête initiale Q : une union de requêtes conjonctives Q = Q1 [ [ Qn ;

un ensemble de vues exportées par le système V = {V1 ; : : : ; Vn}. Chaque vue est une
association entre une sous-requête et la relation temporaire dans laquelle elle est ma-
térialisée. Les vues exportées par le système sont les sous-requêtes de Q matérialisées
pendant le traitement incrémental de la requête initiale. Chacune des vues est une
requête conjonctive ;
la relation R attendue entre la requête initiale et la requête parachute : sous-ensemble,
ou sur-ensemble, ou sous-ensemble généralisé, ou sur-ensemble généralisé, ou encore
intersection.
Dans un premier temps, l'algorithme gen-n-pq associe à chacune des requêtes conjonc-
tives Qi, l'ensemble des vues qui correspondent à ses sous-requêtes. On obtient ainsi une
association entre chaque Qi et un ensemble de vues. La deuxième étape de l'algorithme
consiste à combiner certaines des sous-requêtes associées à Qi en respectant les conditions
de sélection et de jointure de celle-ci. La troisième étape consiste à établir les unions pos-
sibles entre les requêtes parachutes générées dans l'étape 2. Les requêtes obtenues lors de la
deuxième et de la troisième étape sont des requêtes parachutes potentielles. Dans un dernier
temps, la relation qui existe entre la requête initiale et ces requêtes parachutes potentielles
est établie. Seules sont conservées les requêtes parachutes dont la relation avec la requête
initiale correspond à la relation R requise par l'utilisateur.
Notre algorithme tire parti du fait que les vues Vi sont des sous-requêtes des Qi (où Qi
est une requête conjonctive). Nous faisons les observations suivantes :
Si Vi est une sous-requête de Qi , alors

les attributs ont les mêmes noms dans Vi et dans Qi ;
la clause FROM de Vi implique un sous-ensemble des relations de Qi ;
la clause WHERE de Vi contient un sous-ensemble des conditions de Qi.
Si Vi et Vj sont deux sous-requêtes de Qi alors
les attributs ont les mêmes noms dans Vi et dans Vj ;
les clauses FROM de Vi et Vj impliquent des relations diérentes ;
les clauses WHERE Vi et Vj contiennent des sous-ensemble de conditions distincts.
Nous détaillons maintenant chacune des quatre étapes de l'algorithme gen-n-pq.

Etape 1 Etant donnés un ensemble de requêtes conjonctives Q1 [ [ Qn et un ensemble
de vues V = {V1; : : : ; Vn}, le problème est de déterminer, pour chaque bloc Qi, quelles vues
Vi sont ses sous-requêtes.
Srivastava et al. [91] ont présenté un ensemble de conditions, qui, si elles sont respectées,
permettent d'établir dans le cas général qu'une vue Vi peut être utilisée pour réécrire une
requête conjonctive Qi .
Ces conditions peuvent être simpliées dans notre contexte puisque les vues Vi sont
des sous-requêtes des Qi : une association existe entre une vue Vi et une requête Qi si les
conditions suivantes sont respectées.
Condition C1 toutes les relations impliquées dans Vi apparaissent dans Qi.

Condition C2 toutes les conditions de Vi apparaissent dans Qi .
Exemple Q, la requête initiale concerne le modèle et le prix des voitures italiennes et
allemandes disponibles en rouge. C'est l'union de deux requêtes conjonctives : Q1 qui concerne
les voitures italiennes et Q2 qui concerne les voitures allemandes. Le système exporte les vues
V1, V2 et V3. L'utilisateur n'impose pas de relation particulière entre les requêtes parachutes
générées et la requête initiale.
L'étape 1 associe à Q1 les vues V1 et V2 et à Q2 la vue V3 . 2
Une fois l'étape 1 terminée, un ensemble de vues est associé à chaque bloc Qi de la requête
initiale (dont ils sont des sous-requêtes). L'étape suivante consiste à combiner ces vues tout
en respectant les conditions exprimées dans les blocs de la requête initiale.
Etape 2 Etant donné une requête conjonctive Qi et un ensemble de vues V1, : : :, Vk (qui
sont ses sous-requêtes), le problème est de trouver les sous-ensembles maximum de vues qui
peuvent être joints en respectant les conditions exprimées dans Qi . L'objectif est d'obtenir
des requêtes parachutes qui se rapprochent le plus possible des blocs, Qi, de la requête
initiale.
Notre algorithme supprime de Qi tous les éléments qui n'apparaissent pas dans les Vi.
On peut se représenter qu'à partir du graphe de requête de Qi , on enlève toutes les relations
n'apparaissant pas dans les vues ainsi que les conditions qui leurs sont associées. On remplace
les éléments du graphe (relations et conditions) correspondant aux vues par les Vi. Le fait
que les Vi soient des sous-requêtes de Qi nous assure que ce remplacement peut s'eectuer
sans perte d'information. On obtient donc des sous-graphes connectés qui dénissent des
jointures entre les diérentes vues Vi. La représentation déclarative de chacun de ces sous-
graphes connecté est une requête parachute.
Plus précisément l'algorithme est subdivisé en cinq parties :
1. le graphe de requête de Qi est construit. Dans un graphe de requête, les sommets

représentent les relations et les arêtes représentent des conditions spéciées dans la
clause where (auxquelles s'ajoutent les conditions déduites par fermeture transitive) ;
2. le graphe de requête de Qi est modié en remplaçant les sous-graphes contenant les
relations et les conditions présentes dans une vue Vi par la relation temporaire corres-
pondante. Ceci est possible car chaque Vi est une sous-requête de Qi ;
3. le graphe de requête de Qi est modié en supprimant toutes les tables de Qi qui
n'apparaissent pas dans les vues, et en supprimant les conditions basées sur ces tables.
Le graphe ainsi obtenu n'est pas forcément connecté ;
4. la liste de projection associée à chaque sous-graphe connecté est l'intersection des
attributs qui apparaissent dans ce sous-graphe avec les attributs de la requête initiale ;
5. une requête parachute est générée pour chacun des sous-graphes connectés.
V1 MANUF MODEL PRICE COLOR
PQ1 V2
V2
PQ2
Fig. 5.5 Représentation de la réponse

à la requête parachute PQ1 par rap- Fig. 5.6 Représentation de la réponse
port à la réponse complète (représentée à la requête parachute PQ2 par rap-
par une table possédant deux colonnes port à la réponse complète (représentée
- de gauche à droite le constructeur, par une table possédant deux colonnes
le modèle de voiture, le prix et la cou- - de gauche à droite le constructeur,
leur). Intuitivement, la réponse para- le modèle de voiture, le prix et la cou-
chute couvre les colonnes constructeur, leur). Intuitivement, la réponse para-
et modèle de voiture pour la jointure des chute couvre les colonnes constructeur,
vues V1 et V2. et modèle de voiture de la vue V3 .
Exemple Une requête parachute, PQ1, est obtenue en joignant les vues V1 et V2 sur le
modèle de voiture. On obtient la requête parachute suivante, illustrée sur la gure 5.5:
SELECT MANUF, MODEL, PRICE
FROM V1, V2
WHERE V1.MODEL = V2.MODEL ;
Une autre requête parachute, PQ2, est obtenue en sélectionnant les attributs MANUF et
MODEL de la vue V3 (qui ne peut être jointe avec aucune autre vue) :
SELECT MANUF, MODEL

FROM V3 ;
Cette requête parachute est illustrée sur la gure 5.6 2

A la n de l'étape 2, un ensemble de requêtes parachutes ont été générées. Ces requêtes
sont obtenues en eectuant des jointures entre diérentes vues et en respectant les conditions
exprimées dans la requête initiale. L'étape suivante consiste à identier les unions possibles
entre les requêtes ainsi générées.
Etape 3 Etant donné un ensemble de requêtes parachutes PQ = {PQ1; : : : ; PQl} générées

dans l'étape 2, le problème est de déterminer les unions qui peuvent être eectuées entre ces
requêtes.
Dans un premier temps, la liste des attributs projetés dans la requête initiale Q est
constituée. Cette liste est appelée AQ. Pour chacune des requêtes parachutes PQi, la liste des
attributs, notée Ai est l'ensemble des attributs projetés dans cette requête (par construction
Ai AQ pour tout i).
AQ : = ensemble d'attributs dans Q
pour tout i 2 f1; : : : ; ng {
Ai : = ensemble d'attributs de PQi
}
Exemple AQ = {MANUF, MODEL, PRICE, COLOR} ; c'est la liste des attributs qui
apparaissent dans la requête initiale. La liste des attributs qui apparaissent dans PQ1 est
A1 = {MANUF, MODEL, PRICE} ; la liste des attributs qui apparaissent dans PQ2 est A2
= {MANUF, MODEL}. 2
Dans un deuxième temps, l'algorithme isole les attributs communs à des ensembles le plus
large possible de requêtes parachutes, de manière à en construire l'union (les associations
entre attributs et ensembles de requêtes parachutes sont stockées dans la table UnionCandi-
dates).
pour chaque sous-ensemble PQi d'arité supérieure à 2 dans PQ {

CommonAtts = T Aj pour tout PQj dans PQi
si CommonAtts n'a pas d'entrée dans la table UnionCandidates
alors créer une entrée UnionCandidates(CommonAtts, PQi )
sinon {
une entrée UnionCandidates(CommonAtts, PQk ) existe
la remplacer par UnionCandidates(CommonAtts, PQi [ PQk )
}
}
Ainsi, a chaque sous-ensemble d'attributs CommonAtts est associé l'ensemble maximum

de requêtes parachutes dans lesquelles tous ces attributs apparaissent ensemble. Il est main-
tenant possible de construire les unions de requêtes parachutes existantes.
pour chaque entrée de UnionCandidates(CommonAtts, PQi) {

PQUj := union des requêtes de PQi projetées sur CommonAtts
}
PQ3 PQ1
PQ2
Fig. 5.7 Représentation de la réponse à la requête parachute PQ3 par rapport à la ré-
ponse complète (représentée par une table possédant deux colonnes - de gauche à droite le
constructeur, le modèle de voiture, le prix et la couleur). Intuitivement, la réponse parachute
couvre les colonnes constructeur, et modèle de voiture, i.e. la portion de la réponse à PQ1
se rapportant à ces attributs et la réponse à PQ2 dans son intégralité.
Exemple La gure 5.7 représente la requête parachute générée dans cette troisième
étape. Elle concerne les attributs MANUF et MODEL ; c'est l'union entre les modèles de voitures
italiennes et allemandes :
SELECT MANUF, MODEL

FROM PQ1
UNION
SELECT MANUF, MODEL
FROM PQ2
2
Etape 4 L'objectif de cette étape est de dénir la relation qui existe entre les requêtes
parachutes qui ont été générées dans les deux étapes précédentes et la requête initiale. Les
informations obtenues lors des étapes précédentes permettent de dénir la relation entre une
requête parachute et la requête initiale en eectuant des tests simples.
A chaque bloc d'une requête parachute est associé un bloc Qi de la requête initiale. Cette
information permet d'établir la relation entre la requête parachute et la requête initiale :
si chaque bloc de la requête parachute PQi contient dans sa clause select toutes les
tables qui apparaissent dans le bloc de la requête initiale auquel il est associé, alors
PQi est un sous-ensemble de Q. En eet, les requêtes parachutes construites lors de
l'étape 2 sont obtenues en enlevant d'un bloc Qi de la requête initiale les relations qui
n'apparaissent pas dans les vues exportées par le système. Si toutes les relations de Qi
apparaissent dans les Vi alors la requête parachute qui est générée dans l'étape 2 est
équivalente à Qi. L'union de plusieurs requêtes parachutes équivalente à des Qi est un
sous-ensemble de la requête initiale ;
si les blocs de la requête parachute PQi sont associés à tous les blocs Qi de la requête
initiale, alors PQi est un sur-ensemble généralisé de Q. En eet, lors de l'étape 2 chaque
requête parachute est obtenue en supprimant des attributs de la liste de projection et
des conditions par rapport au bloc de la requête initiale auquel il est associé. Chacun
des blocs de PQ est donc un sur-ensemble généralisé d'un bloc de Q. Pour que l'union
des blocs PQi soit un sur-ensemble généralisé de Q, il est donc susant de garantir
que ces blocs PQi sont associés à tous les blocs de Q ;
dans tous les autres cas, l'algorithme garantit seulement que l'intersection entre PQ et
Q est non vide.
L'algorithme retourne les requêtes parachutes dont la relation à la requête initiale est
conforme à la relation R souhaitée par l'utilisateur.
Exemple PQ3 est un sur-ensemble généralisé de la requête initiale. Les requêtes para-
chutes PQ1 et PQ2 ne sont ni des sous-ensembles, ni des sur-ensembles généralisés de la
requête initiale.
L'utilisateur n'ayant pas imposé de relation entre la requête initiale et la requête para-
chute l'algorithme retourne trois requêtes parachutes : PQ1 qui dénote les modèles de voitures
allemandes, PQ2 qui dénote le modèle et le prix des voitures italiennes, et PQ3 qui dénote
les modèles de voitures allemandes et italiennes. 2
Exemple Le cas de l'application du complexe hospitalier est beaucoup plus simple.
La requête posée est toujours trouver les informations administratives et les informations
radiologiques des patients dont le séjour dépasse 10 jours et qui attendent d'être opérés:
SELECT PATIENT.NAME, PATIENT.ROOM, RADIOLOGY.ID, RADIOLOGY.COMMENT
FROM PATIENT, MAP, SURGERY, RADIOLOGY
AND MAP.SID = SURGERY.ID AND SURGERY.STATUS = 'WAITING'
AND MAP.RID = RADIOLOGY.ID;
Considérons tout d'abord le cas où la source du service de radiologie est indisponible

lorsque cette requête est exécutée. Les données des sources chirurgie et administration étant
disponibles, les données correspondant aux sous-requêtes qui leur étaient destinées ont été
récupérées par le système de médiation incrémental. Une relation temporaire V1 a été crée
pour les stocker. Le système propose donc à l'algorithme de génération des requêtes para-
chutes la vue V1, dénie comme suit :
SELECT PATIENT.NAME, PATIENT.ROOM, MAP.RID
AND MAP.SID = SURGERY.ID AND SURGERY.STATUS = 'WAITING';
L'utilisateur indique de son côté qu'il accepte toutes les requêtes parachutes qui peuvent
être générées.
La première étape de l'algorithme est triviale : la requête initiale étant une requête
conjonctive, la vue exportée par le système lui est naturellement associée. La deuxième étape
est également très simple, puisqu'une seule vue est exportée : V1. La requête parachute PQ1
est générée
SELECT NAME, ROOM
FROM V1
Cette requête parachute est un sur-ensemble généralisé de la requête initiale. Lors de la

troisième étape, la liste des attributs participant à plusieurs requêtes parachutes est vide,
puisque PQ1 est la seule requête parachute générée lors de la deuxième étape. L'algorithme
gen-n-pq génère donc la requête parachute PQ1.
Considérons maintenant le cas où la source de chirurgie est indisponible. Les données
obtenues des sources de radiologie et d'administration sont stockées dans deux relations
temporaires et les vues ainsi dénies sont exportées par le système :
V2 matérialise la sous-requête
SELECT PATIENT.ID, PATIENT.NAME, PATIENT.ROOM
FROM PATIENT
WHERE PATIENT.STAY > 10
V3 matérialise la sous-requête
SELECT RADIOLOGY.ID, RADIOLOGY.COMMENT
FROM RADIOLOGY
L'utilisateur indique encore qu'il accepte toutes les requêtes parachutes qui peuvent être
générées.
La requête initiale étant conjonctive, les deux vues V2 et V3 lui sont associées lors de la
première étape. La deuxième étape permet d'obtenir deux sous-graphes connectés à partir
de la requête initiale. Les requêtes parachutes qui sont générées sont :
PQ2 :
SELECT NAME, ROOM
FROM V2
PQ3 :
SELECT ID, COMMENT
FROM V3
Ces requêtes parachutes sont des sur-ensemble généralisés de la requête initiale. Comme
précédemment, la troisième étape ne produit rien et l'algorithme gen-n-pq génère les requêtes
parachutes PQ2 et PQ3. 2
5.2.3 Discussion
Les requêtes parachutes générées par gen-n-pq, référencent uniquement les relations tem-
poraires stockées par le système de médiation incrémental . Elles extraient donc les données
sans nécessiter de mécanisme particulier pour leur évaluation. Le travail de réécriture en
fonction des relations matérialisées est eectué par gen-n-pq.
Un problème pour implanter cet algorithme est de déterminer dans quelle mesure un
système peut fournir un ensemble de vues à l'algorithme gen-n-pq tout en respectant une
interface standard telle que JDBC. L'accès aux dénitions des vues est une fonctionnalité
classique pour l'administrateur d'une base de données. Elle est notamment prévue dans
JDBC. Il est possible de spécier qu'une relation du catalogue correspond à une vue et
d'associer au nom de la table une chaîne de caractère qui peut notamment décrire la sous-
requête qui est matérialisée. la mise en oeuvre de gen-n-pq n'impacte donc pas l'interface
d'un système de médiation tel que Disco qui supporte l'interface JDBC.
Nous avons, dans [12], dénit l'algorithme gen-1-pq. Cet algorithme permet de générer
une requête parachute lorsque la requête initiale est conjonctive. Cet algorithme a plusieurs
limitations. Premièrement, il garantit que des produits cartésiens ne sont pas introduits
dans la requête parachute. Il existe donc des cas de gures où aucune requête parachute
n'est générée alors que des données ont été obtenues des sites disponibles, par exemple dans
tous les cas où le graphe de requête initiale a une forme de chaîne et une des relations du
milieu de la chaîne est indisponible. Deuxièmement, cet algorithme ne permet pas de prendre
Optimisation sous contrainte 91
en compte les unions de requêtes conjonctives. L'algorithme gen-n-pq permet de surmonter
ces limitations.
L'algorithme gen-n-pq s'applique au cas où les vues exportées par le système sont des
sous-requêtes de la requête initiale. Est il possible de généraliser cet algorithme pour prendre
en compte les vues stockées dans un cache sémantique? Le principe des quatre étapes de notre
algorithme est applicable au cas général où les vues sont quelconques : il s'agit toujours (1)
d'identier les vues se rapportant aux blocs de la requête initiale, (2) d'eectuer les jointures
entre ces vues tout en respectant les conditions de la requête initiale, on obtient ainsi un
premier lot de requêtes parachutes, (3) d'eectuer les unions possibles entre les requêtes
parachutes ainsi générées et (4) d'établir la relation entre les requêtes parachutes et la requête
initiale. La mise en oeuvre de chacune de ces étapes est cependant plus complexe dans le cas
général, car aucune simplication ne peut a priori être appliquée. Il semble ainsi nécessaire
d'utiliser un algorithme de réécriture utilisant les vues (i) dans l'étape 1 pour reconnaître les
vues associées à un bloc de la requête initiale, (ii) dans l'étape 2 pour introduire les vues dans
le graphe de requête initial, (iii) et dans l'étape 4 pour établir la relation entre les requêtes
parachutes et la requête initiale.
Un autre problème est de prendre en compte d'autres informations que le système peut
fournir pour la génération de requêtes parachutes. Il serait par exemple intéressant d'étudier
l'utilisation des dépendances fonctionnelles ou des contraintes d'intégrité stockées dans le
système pour la génération de requêtes parachutes.
5.3 Optimisation sous contrainte

Nous considérons dans cette section le scénario où l'utilisateur formule les requête pa-
rachutes a priori, sans utiliser d'informations fournies par le système. L'application soumet
donc simultanément une requête et les requêtes parachutes qui lui sont associées. Le pro-
blème est de dénir comment le système de médiation peut tirer prot de la connaissance
des requêtes parachutes pour s'assurer que les informations nécessaires à l'évaluation des
requêtes parachutes sont obtenues et conservées.
5.3.1 Architecture
Nous dénissons un système de médiation incrémental sous contrainte, où l'optimisation
de la requête initiale est contrainte par la connaissance des requêtes parachutes. Ainsi, les
sous-requêtes communes à la requête initiale et aux requêtes parachutes peuvent être identi-
ées. Cette information permet de dénir une politique de matérialisation spécique pour sto-
cker le résultat des sous-requêtes partagées. De cette manière le système sous contrainte ga-
rantit que les requêtes parachutes peuvent être évaluées si les sources de données qu'elles im-
pliquent sont disponibles. Les deux politiques de matérialisation d'un système sans contrainte
n'orent pas cette garantie. La politique de matérialisation des sous-arbres maximums (max)
peut perdre des éléments de réponse à une requête parachute en combinant une sous-requête
Requete Requetes
initiale parachutes
Optimiseur
sous contrainte
au moins une source est indisponible

Sense
toutes les sources

sont disponibles
Moteur d’execution Materialize
Construct
Reponse Requete
incrementale
Fig. 5.8 Architecture d'un système incrémental sous contrainte.
intéressante pour les requêtes parachutes avec une autre sous-requête qui ne l'est pas. La
politique de matérialisation des feuilles du plan d'exécution (feuilles) ne garantit pas, si l'es-
pace de stockage est limité, qu'une sous-requête sans intérêt (du point de vue des requêtes
parachutes) ne sera pas matérialisée à la place d'une sous-requête nécessaire à l'évaluation
d'une ou plusieurs requêtes parachutes.
La gure 5.8 présente l'architecture d'un système incrémental sous contrainte. L'optimi-
seur doit être étendu pour identier les sous requêtes partagées entre la requête initiale et les
requêtes parachutes. Une nouvelle politique de matérialisation peut ainsi être mise en oeuvre.
Nous détaillons notre algorithme d'optimisation sous contrainte dans la section suivante.
5.3.2 Algorithme d'optimisation

L'algorithme d'optimisation sous contrainte accepte une requête conjonctive q, ainsi qu'un
ensemble de requêtes parachutes qui lui sont associées 0 n (les requêtes parachutes sont
également conjonctives).
Cet algorithme produit en sortie un plan d'exécution pour q où la racine de chaque sous-
requête partagée entre la requête initiale et les requêtes parachute est identiée et annotée.
Ces annotations sont utilisées par l'algorithme de matérialisation pour stocker le résultat
des sous-requêtes partagées. Un plan d'exécution est également produit pour chaque requête
parachute en utilisant les sous-requêtes partagées.
Les problèmes lors de l'optimisation sous contrainte sont les suivants. L'optimiseur doit :
identier les sous-requêtes partagées entre la requête initiale et les requêtes parachutes ;
construire des plans d'exécution ecaces pour la requête initiale et les requêtes para-
chutes basés sur ces sous-requêtes partagées.
Notre algorithme procède en trois étapes. La première étape construit les sous-requêtes
partagées (SRP) entre la requête initiale et les requêtes parachutes. Une fois ces SRP iden-
tiées, il s'agit de décider comment elles vont être matérialisées. C'est le rôle de la deuxième
étape de proposer des stratégies de découpage des SRP en vue de leur matérialisation. Enn,
dans la troisième étape, un plan d'exécution optimal de la requête initiale est généré pour
chacune de ces stratégies. La stratégie la moins coûteuse est retenue et un plan d'exécution
est construit pour chacune des requêtes parachutes.
5.3.2.1 Ensembles de sous-requêtes partagées

Avant de décrire chaque étape en détail, nous dénissons l'ensemble des sous-requêtes
partagées entre la requête initiale q et un ensemble de requêtes parachutes 0 n . Intui-
tivement, l'ensemble des SRP correspond à l'ensemble des intersections possibles entre la
requête initiale et les requêtes parachutes (les SRP sont deux à deux disjointes).
E1
E2
E3
Fig. 5.9 Toutes les intersections possibles entre trois ensembles.

Plus précisément, l'ensemble des intersections possibles de n ensembles E1 ; ; En est
l'ensemble S dénit comme suit.
Denition 10 (Intersections possibles entre n ensembles)
\n
S = f FijFi 2 fEi; Eigg
i=1
où Ei désigne le complément de Ei. L'ensemble S contient 2n intersections, qui sont deux à
deux disjointes 3. La gure 5.9 illustre toutes les intersections possibles entre trois ensembles.
Pour pouvoir adapter cette dénition au contexte de notre étude, il nous faut dénir
les notion d'intersection et de complément pour les requêtes conjonctives. Pour simplier la
présentation, les requêtes conjonctives (notamment la requête q et les requêtes parachutes
0 :::n) sont représentées en Datalog [102].
Nous dénissons tout d'abord la notion de containment mapping qui nous servira à dénir
la notion d'intersection.
Denition 11 (Containment mapping) Un ensemble de littéraux L est contenu dans un

ensemble de littéraux L0 , noté L L0 , il existe une fonction des variables de L vers les
variables de L0 , appelée containment mapping, telle que tous les littéraux de L correspondent
à un littéral de L0 4.
Par abus de notation, nous écrivons qu'un ensemble de littéraux est contenu dans une
requête, s'il est contenu dans le corps de cette requête.
Exemple Soient l1 et l2 dénis comme suit :
l1 := { map(PID; SID; RID); surgery(SID;0 WAITING0; _);
radiology(RID; Rcomment; _); patient(PID; Pname; Proom; Stay; _; _); Stay > 10g
et
l2 := { map(PID; SID; _); surgery(SID;0 WAITING0; _);
patient(PID; PName; Proom; Stay; PAddress; _); Stay > 10 }
On a l2 l1 2
Nous utilisons la notion de containment mapping pour dénir l'intersection de deux
requêtes : l'ensemble maximal de littéraux contenu dans les deux requêtes.
Denition 12 (Intersection de deux requêtes) L'intersection de deux requêtes Q1 et

Q2, noté Q1 \ Q2, est un ensemble de littéraux SR tel que
SR Q1
SR Q2
6 9 SR' tel que SR SR' Q1 et SR SR' Q2
3. L'intersection de tous les compléments est par dénition vide et peut être soustraite de l'ensemble S.
4. Cette dénition n'est pas celle donnée par Ullman [102]. Dans sa dénition Ullman considère le contain-
ment mapping entre deux requêtes. La dénition que nous utilisons a été proposée par Levy et al. [72].
Exemple L'intersection entre la requêtes q1 dont le corps est l'ensemble de littéraux l1
décrit dans l'exemple ci-dessus et une requête q2 dont le corps est l'ensemble de littéraux l2
est : {map(X 1; X 2; X 3), surgery(X 2;0 WAITING0; X 6), patient(X 3; X 8; X 9; X 10; X 11; X 12),
X 10 > 10} 2
Dans la dénition des intersections possibles entre n ensembles intervient une notion
de complément. Le complément d'un ensemble est l'ensemble des éléments qui ne sont pas
contenus dans cet ensemble. Par analogie, nous disons qu'un ensemble de littéraux fait partie
du complément d'une requête s'il n'est pas contenu (au sens du containment mapping) dans
cette requête.
Denition 13 (Complément d'une requête) Le complément d'une requête Q, noté Q,
est un ensemble d'ensembles de littéraux L tel que L 6 Q.
Avec les notions d'intersection et de complément que nous venons d'introduire, nous
pouvons dénir précisemment l'ensemble des sous-requêtes partagées comme suit :
Denition 14 (Ensemble des sous-requêtes partagées) L'ensemble des sous-requêtes
partagées entre une requête Q et un ensemble de requêtes parachutes PQ0 , , PQn est
l'ensemble S ainsi déni
\n
S = fQ QijQi 2 fPQi; PQigg , fQ \ PQ1 \ : : : \ PQng
i=1
Par rapport à la dénition des intersections possibles entre n ensembles, nous ne consi-
dérons pas les intersections entre toutes les requêtes mais seulement les intersections des
requêtes parachutes avec la requête initiale.
Q
PQ1
SRP2
PQ3
SRP1
SRP3 PQ2
SRP4
Fig. 5.10 Représentation de l'ensemble des sous-requêtes partagées entre une requête Q et
trois requêtes parachutes PQ1, PQ2 et PQ3.
La gure 5.10 illustre l'ensemble des sous-requêtes partagées entre une requête Q et trois
requêtes parachutes PQ1, PQ2 et PQ3. Il existe, dans cet exemple, quatre sous-requêtes
partagées.
5.3.2.2 Etapes de l'algorithme d'optimisation
Nous décrivons maintenant les trois étapes de notre algorithme d'optimisation sous
contrainte.
Etape 1 Le problème est d'identier l'ensemble des sous-requêtes partagées (SRP), étant
donné la requête initiale q et un ensemble de requêtes parachutes 0 n.
La brique de base de cette étape est l'algorithme 2-requêtes-srp qui isole la SRP de deux
requêtes, i.e. l'intersection de deux requêtes. Cet algorithme est détaillé sur la gure 5.11. La
SRP est constituée des littéraux communs aux deux requêtes. Initialement, les littéraux com-
muns les plus généraux sont construits en introduisant de nouvelles variables. Les constantes
et les égalités entre variables de plusieurs littéraux sont par la suite introduites dans la SRP
si elles apparaissent dans les deux requêtes. L'algorithme 2-requêtes-srp utilise la notion de
containment mapping que nous avons déni ci-dessus.
in: deux requêtes conjonctives qi et qj
out: la SRP entre qi et qj
2-requêtes-srp (qi , qj ) {
soit x le corps de qi
eacer tous les littéraux de x dont le prédicat n'apparait pas dans un littéral du corps de qj
remplacer toutes les variables et constantes dans x par des variables
les containment mapping sont construits entre (1) x et qi et entre (2) x et qj
l'intersection de ces deux mappings est appelée b,
i.e. b associe des variables de x à des constantes ou dénit des relations d'égalités entre variables de x
b est appliqué à x pour obtenir la SRP entre qi et qj
}
Fig. 5.11 Construction de la sous-requête partagée (SRP) entre deux requêtes conjonctives.
L'algorithme 2-requêtes-srp est utilisé pour construire l'ensemble des SRP entre la requête
initiale et toutes les requêtes parachutes 0 n. Il sert dans un premier temps à identier les
SRP entre la requête initiale et chacune des requêtes parachutes. Il permet ensuite d'énumérer
toutes les intersections possibles entre plusieurs requêtes parachutes.
L'ensemble des SRP est construit en suivant les sept sous-étapes suivantes :
Sous-étape 1.1 Utiliser l'algorithme 2-requêtes-srp pour construire l'intersection entre
la requête originale q et chacune des requêtes parachutes. L'intersection ainsi obtenue
avec la requête parachute i est notée Ii1 . L'ensemble des intersections de niveau 1, noté
I 1 , correspond aux intersections entre une requête parachute et la requête initiale..
Sous-étape 1.2 Si I 1 ne contient qu'un seul élément ou est vide alors eectuer direc-
tement la sous-étape 1.5, sinon eectuer la sous-étape 1.3. Le niveau d'intersection l est
initialisé à 1. L'ensemble des intersections de niveau l correspondent aux intersections
non vides entre la requête initiale et l requêtes parachutes.
Sous-étape 1.3 Pour chaque paire d'éléments dans I l générer leur intersection, en
utilisant l'algorithme 2-requêtes-srp. L'ensemble des intersections ainsi obtenu forme
l'ensemble I l+1
Sous-étape 1.4 l := l+1. Si I l contient un seul élément ou si cet ensemble est vide,
alors eectuer la sous-étape 1.5, sinon eectuer à nouveau la sous-étape 1.3.
Sous-étape 1.5 Dénir le niveau maximum d'intersection : si I l est vide alors lmax :=
l-1, sinon lmax := l. Initialiser l'ensemble des SRP avec l'ensemble des intersections de
niveau maximum : SRP := I lmax .
Sous-étape 1.6 Si lmax == 1 alors retourner SRP ; sinon lmax := lmax - 1.
Sous-étape 1.7 Chaque élément de I lmax est réécrit en fonction des l SRP de SRP
en utilisant un algorithme de type Answering Queries Using Views 5 : Ii max = SRP0 [
[ SRPm [ Rklmax , où Rkllmax est l'ensemble des littéraux qui n'apparaissent pas dans
les SRP déjà dénis. Si Rk n'est pas vide alors SRP = SRP [ {Rk }. lmax :=
max l max
lmax - 1. Répéter la sous-étape 1.6.
L'objectif de ces sous-étapes est d'identier l'ensemble des sous-requêtes partagées (SRP)
entre la requête initiale et les requêtes parachutes. Chaque SRP est de la forme Q \ : : : PQi
\ : : : \ PQj . Si nous prenons l'exemple de la gure 5.10 :
Q \PQ1 \ PQ2 \ PQ3
Q \PQ1 \ PQ2 \ PQ3
Q \PQ1 \ PQ2 \ PQ3
Q \PQ1 \ PQ2 \ PQ3
Q \PQ1 \ PQ2 \ PQ3
Q \PQ1 \ PQ2 \ PQ3
Q \PQ1 \ PQ2 \ PQ3
Dans une première phase, les sous-étapes 1.1 à 1.5 permettent d'obtenir toutes les inter-
sections entre Q et une ou plusieurs requêtes parachutes. La sous-étape 1.1 permet d'obtenir
les intersections entre la requête initiale et chaque requête parachute : Q \PQi . La sous-étape
1.1 permet d'obtenir les intersections entre la requête initiale et chaque requête parachute :
Q \PQi. Ces intersections forment l'ensemble des intersections de niveau 1. Les sous-étapes
1.2 à 1.4 permettent d'obtenir toutes les intersections de niveau l, i.e. l'intersection entre
5. Par abus de language nous décrivons un algorithme de type answering queries using views appliqué à
des ensembles de littéraux. Il sut d'associer, à chaque ensemble de littéraux, une tête, composée d'un nom
de prédicat quelconque et de l'ensemble des variables qu'il contient pour pouvoir appliquer cet algorithme.
Un algorithme de type answering queries using views permet de réécrire une requête en utilisant un ensemble
de vues et un ensemble de littéraux qui n'apparaissent pas dans les vues. Nous notons Iilmax comme l'union
d'ensembles de littéraux.
l requêtes parachutes et la requête initiale : Q \PQ1 \ : : : \ PQl . Il y a au maximum Cnl
intersections non vides au niveau l 6 . Si n requêtes parachutes sont soumises avec la requête
initiale, il y a au maximum n niveaux d'intersection :
En fait notre algorithme permet d'éliminer au fur et à mesure les intersections vides.
Ainsi, le niveau maximum d'intersection. est atteint lorsque l'ensemble des intersections
contient un seul élément, ou lorsque l'ensemble des intersection de niveau supérieur est vide.
Le niveau maximum d'intersection est donc éventuellement inférieur au nombre de requêtes
parachutes. Les éléments du niveau maximum d'intersection sont par construction disjoints
et le principe décrit ci-dessous pour la deuxième phase peut être appliqué.
Q \PQ1
Q \PQ2
Q \PQ3
Q \PQ1 \ PQ2
Q \PQ1 \ PQ3
Q \PQ2 \ PQ3
Q \PQ1 \ PQ2 \ PQ3
Dans une deuxième phase, les sous-étapes 1.6 et 1.7 permettent d'obtenir l'ensemble des
sous-requêtes partagées en utilisant toutes les intersections déjà calculées. La sous-étape 1.7
repose sur une procédure qui, étant donné un ensemble de littéraux L et un sous-ensemble
de ce dernier L1, calcule l'ensemble de littéraux L2 tel que L = L1 [ L2 . En utilisant cette
procédure avec Q \PQ2 \ PQ3 et Q \PQ1 \ PQ2 \ PQ3 en paramètres, on obtient la sous-
requête partagée Q \PQ1 \ PQ2 \ PQ3. Ainsi, en partant du niveau maximum d'intersection
et de proche en proche, l'algorithme obtient toutes les SRP.
Etape 2 Etant donné l'ensemble des sous-requêtes partagées (SRP) identiées dans
l'étape précédente, le problème est de déterminer comment les SRP participent à la construc-
tion du plan d'exécution.
Notre objectif est double. Nous voulons construire un plan d'exécution ecace tout en
isolant les SRP de manière à pouvoir les identier dans la phase de matérialisation.
Pour cela, nous considérons que la requête initiale est constituée d'un ensemble de blocs
logiques qui sont optimisés indépendamment ; le plan d'exécution est obtenu en composant
(merging) les plans d'exécutions obtenus pour les diérents blocs logiques.
Le problème est donc de réécrire la requête initiale en un ensemble de blocs logiques
correspondant à des portions de SRP. Nous considérons deux stratégies de découpage des
SRP en un ensemble de blocs logiques. Chacun de ces blocs logiques est une règle Datalog
composée d'une tête et d'un corps.
Dans la première stratégie, chaque SRP identiée dans l'etape 1 est considérée comme
un seul bloc : c'est la stratégie maximale. Le corps de chaque bloc logique est formé par une
6. Nombre de combinaisons de l éléments parmi n
SRP identiée précédement; leur tête est obtenue avec un nouveau symbole de prédicat et
la liste des variables qui apparaissent dans le corps de la règle et qui sont nécessaires pour
l'évaluation de q et des requêtes parachutes.
Dans la seconde stratégie, chaque littéral apparaissant dans une SRP est considéré comme
un bloc séparé (avec les littéraux built-in qui lui sont associés, si possible) : c'est la stratégie
minimale. Le corps de chaque bloc logique est donc composé d'un littéral (et éventuellement
de littéraux built-in); leur tête est obtenue avec un nouveau symbole de prédicat et la liste
des variables qui apparaissent dans le corps de la vue et sont nécessaires à l'évaluation de q
et des requêtes parachutes.
Pour chaque groupe de blocs logiques, q est réécrite. La requête réécrite q0 est exprimée
en fonction des blocs logiques et des littéraux n'apparaissant pas dans les SRP La réécriture
est eectuée avec un algorithme de type answering queries using views [72].
Etape 3 Pour les deux stratégies, l'optimiseur est appelé pour générer le plan d'exécution
de chaque bloc logique ainsi que de la requête réécrite q0 qui leur est associée.
Le coût total pour une stratégie est la somme des coûts d'exécution des blocs logiques
auquel s'ajoute le coût d'exécution de la requête réécrite q0 associée. La stratégie la moins
coûteuse est retenue. Si les deux stratégies ont le même coût, alors la stratégie maximale est
retenue.
Le plan d'exécution pour q est obtenu en composant (merging) le plan d'exécution pour
0
q et les plans d'exécution des blocs logiques. La racine de chaque bloc logique est annotée
de manière à pouvoir être reconnue par l'algorithme de matérialisation.
Chaque requête parachute est réécrite en utilisant les blocs logiques retenus (selon le
principe de l'étape 2). L'optimiseur est appelé pour générer le plan d'exécution pour chaque
requête parachute.
L'algorithme d'optimisation sous contrainte identie ainsi les sous-requêtes partagées
entre la requête initiale et les requêtes parachutes et génère le plan d'exécution le moins
cher, d'abord pour q puis pour les , en suivant une stratégie maximale ou minimale pour
la matérialisation des SRP.
Exemple Nous considérons comme exemple, la requête ad-hoc de l'application hospi-
talière que nous avons déjà utilisée: trouver les informations personnelles et radiologiques
patients dont le séjour dépasse 10 jours et qui attendent d' être opérés. Cette requête s'écrit
en Datalog comme suit 7 :
q(Pname; Proom; RID; Rcomment)
map(PID; SID; RID)^
surgery(SID;0 WAITING0; _)^
radiology(RID; Rcomment; _)^
patient(PID; Pname; Proom; Stay; _; _) ^ Stay > 10
7. Pour des raisons de simplicité, nous considérons que les relations surgery et radiology sont d'arité 3 et
que la relation patient est d'arité 6.
L'application associe à cette requête q, la requête parachute suivante : trouver le nom, le
numéro de chambre et l'adresse des patients dont le séjour dépasse 10 jours et qui attendent
d'être opérés. :
pq(PName; Proom; PAddress)
map(PID; SID; _)^
surgery(SID;0 WAITING0; _)^
patient(PID; PName; Proom; Stay; PAddress; _) ^ Stay > 10
Dans notre exemple, étant donné la requête q et la requête parachute pq données ci-dessus,
l'algorithme 2-requêtes-srp est appliqué dans la sous-étape 1.1 et x vaut :
fmap(X 1; X 2; X 3); surgery(X 4; X 5; X 6);
patient(X 7; X 8; X 9; X 10; X 11; X 12); X 13 > X 14g:
Les associations identiées entre x et q sont
bq = fX 2 = X 4; X 1 = X 7; X 5 =0 WAITING0; X 10 = X 13; X 14 = 10g
les associations identiées entre x et pq sont bpq = bq . 8
Nous appliquons bq à x pour obtenir :
I 1 = fmap(X 1; X 2; X 3); surgery(X 2;0 WAITING0; X 6);
patient(X 3; X 8; X 9; X 10; X 11; X 12); X 10 > 10g:
Dans la sous-étape 1.2, l est initialisé à 1. Comme I 1 ne contient qu'un seul élément,
nous eectuons directement la sous-étape 1.5.
Les initialisations suivantes sont réalisées : lmax vaut 1 et SRP contient I 1.
Dans l'étape 1.6, comme lmax est égal à 1, SRP est retourné. L'ensemble des sous requêtes
partagés entre q et pq contient donc un seul élément :
SRP = ffmap(X 1; X 2; X 3); surgery(X 2;0 WAITING0; X 6);
patient(X 3; X 8; X 9; X 10; X 11; X 12); X 10 > 10gg:
Dans l'étape 2, la stratégie maximale identie un bloc logique :
fscsq1(X 1; X 8; X 9; X 11)
map(X 1; X 2; X 3)^
surgery(X 2;0 WAITING0; X 6)^
patient(X 3; X 8; X 9; X 10; X 11; X 12)^
X 10 > 10g
8. Les associations sont les mêmes car, dans notre exemple, les conditions de sélection et de jointures de
la requête parachute apparaissent également dans la requête initiale, alors que les listes de projection sont
diérentes.
La stratégie minimale identie les blocs logiques suivants :
fscsq2(X 1; X 2; X 3) map(X 1; X 2; X 3);
scsq3(X 1) surgery(X 1;0 WAITING0; X 2);
scsq4(X 1; X 2; X 3; X 5)
patient(X 1; X 2; X 3; X 4; X 5; X 6) ^ X 4 > 10g
Il est à noter que les listes de variables retenues pour la tête des blocs logiques permet
de satisfaire la requête initiale et la requête parachute.
Dans l'étape 2, avec la stratégie maximale, q est réécrite de la manière suivante :
q0(Pname; Proom; RID; Rcomment)
scsq1 (RID; Pname; Proom; _)^
radiology(RID; Rcomment; _)
Avec la stratégie minimale, q est réécrite de la manière suivante :
q0(Pname; Proom; RID; Rcomment)
scsq2 (PID; SID; RID)^
scsq3 (SID)^
scsq4 (PID; PName; Proom; PAddress)^
radiology(RID; Rcomment; _)
Dans l'étape 3, les plans d'exécutions obtenus avec la stratégie minimale et avec la stra-
tégie maximale ont la même forme (ce plan d'exécution est présenté en gure 4.2 dans la
section 4.2) et le même coût. Le plan d'exécution annoté avec la stratégie maximale est donc
retenu. 2
5.3.3 Politique de matérialisation

Une fois le plan d'exécution généré pour la requête initiale et les requêtes parachutes, le
système incrémental sous contrainte procède à la phase de détection des sources indisponibles.
Si une ou plusieurs sources sont indisponibles, l'algorithme de matérialisation est utilisé.
Nous avons proposé une politique de matérialisation qui prend en compte les sous-requêtes
partagées (SRP) identiées lors de l'optimisation sous contrainte. Les sous-requêtes candi-
dates pour la matérialisation sont partitionnées en trois groupes. Les SRP disponibles font
partie du groupe dont la priorité est maximale. Les SRP partiellement disponibles font partie
du groupe suivant. Les sous-requêtes disponibles distinctes des SRP font partie du groupe
dont la priorité est minimale.
Ainsi, si l'espace de stockage est susant, toutes les sous-requêtes disponibles sont ma-
térialisées en prenant garde à conserver les SRP telles quelles. Si l'espace de stockage est
insusant, les SRP sont matérialisées en priorité.
Nous avons déni, dans [12] une politique de matérialisation naïve, où seules les SRP
sont matérialisées si elles sont complètement disponibles. Cette politique ne permet pas de
matérialiser toutes les relations disponibles et ne prend pas en compte l'éventualité d'un
espace de stockage limité. La politique de matérialisation que nous présentons ici dépasse
ces limitations.
5.3.4 Discussion
Nous avons implanté l'algorithme d'optimisation sous contrainte. Cela nous a permis de
simuler un système sous contrainte et d'étudier ses performances. Nous avons étudié (1)
dans quelle mesure les requêtes parachutes sont satisfaites, (2) les bénéces de la politique
de matérialisation des SRP par rapport aux deux politiques des systèmes sans contraintes, et
(3) les caractéristiques du plan d'exécution étudié par rapport au plan optimal généré dans
le système sans contrainte. Ces résultats sont présentés en section 6.3.
Nous avons utilisé le langage Prolog pour l'implantation de l'algorithme d'optimisation
sous contrainte. Le principal problème d'implantation concerne la procédure de subsump-
tion qui est à la base de l'algorithme 2-requêtes-srp et de l'algorithme answering queries
using views. Prolog se prête bien à la réalisation de cette procédure grâce au mécanisme de
substitution intégré à l'évaluateur.
Un autre problème pour implanter cet algorithme consiste à déterminer dans quelle me-
sure un système de médiation peut (i) accepter plusieurs requêtes simultanément et (ii)
permettre d'évaluer les requêtes parachutes tout en respectant une interface standard telle
que JDBC. La réponse est double. D'une part, les requêtes sont soumises à l'interface JDBC
sous forme de chaînes de caractère. Il est donc possible de fournir plusieurs requêtes dans une
même chaîne de caractère. D'autre part, la notication qui est retournée à l'utilisateur (une
sous-classe des exceptions prévues par JDBC) peut lui permettre de commander l'exécution
d'une requête parachute et de récupérer la réponse partielle ainsi construite.
L'algorithme d'optimisation sous contrainte que nous présentons est limité aux requêtes
conjonctives. Un problème est de prendre en compte les unions de requêtes conjonctives. Nous
avons, dans [13], proposé un premier algorithme pour construire la SRP de deux requêtes
lorsque celles-ci sont des unions de requêtes conjonctives. Il reste cependant à dénir un
cadre uniforme pour l'optimisation sous contrainte des unions de requêtes conjonctives.
5.4 Comparaison avec des travaux existants

Les objectifs que nous nous sommes xés pour l'extraction d'informations partielles se
rapprochent des objectifs des systèmes de traitement de requêtes coopératifs. La notion de
système de traitement de requêtes coopératif est décrite dans [45] et [78]. Ces systèmes
mettent l'accent sur les interactions entre l'application et les systèmes de bases de données ;
ils étendent le schéma classique d'interaction où l'application soumet une requête précise à
Comparaison avec des travaux existants 103
laquelle le système fournit une réponse exacte. A.Motro [78] identie deux classes de systèmes
de traitement de requêtes coopératif. La première assiste l'utilisateur et l'aide à formuler des
requêtes précises. La seconde a pour objectif de retourner des réponses intéressantes en
présence de données manquantes ou inconsistantes.
Nous détaillons ci-dessous les techniques existantes pour l'extraction d'informations par-
tielles. Nous comparons également notre algorithme d'optimisation sous contraintes aux al-
gorithmes existants pour l'optimisation de plusieurs requêtes.
5.4.1 Extraction d'informations partielles

Nous avons en section 5.1 distingué deux approches pour l'extraction d'informations
partielles en présence de sources de données indisponibles : d'une part l'approche implicite
où le système retourne par défaut des informations partielles s'il ne peut pas construire la
réponse exacte à une requête, et d'autre part l'approche explicite où l'application indique au
système les informations partielles qu'elle souhaite extraire.
Nous détaillons ici les solutions existantes pour ces deux approches et nous les comparons
à notre solution qui est basée sur la formulation de requêtes parachutes.
5.4.1.1 Approche implicite

Deux catégories de systèmes retournent, par défaut, une réponse partielle à la requête
qui leur est posée. Ce sont les systèmes qui mettent en oeuvre un traitement approché des
requêtes et les systèmes qui réécrivent les requêtes qui leurs sont soumises en fonction de
vues existantes.
Traitement approché des requêtes Nous avons détaillé, en section 3.3.2, les techniques
de traitement approché des requêtes. Un système qui met en oeuvre un traitement approché
des requêtes retourne une approximation, dans le cas où ils ne peut pas construire la réponse
exacte. Cette approximation est formée de deux ensembles de tuples qui encadrent la réponse
exacte : APPROXIMATE [107] retourne un sous-ensemble et un sur-ensemble de la réponse
exacte, MULTIPLEX [79] retourne un sous-ensemble généralisé et un ensemble de tuple dont
la réponse exacte est un sous-ensemble généralisé, Buneman et al. [23] proposent de retourner
un sous-ensemble généralisé et un sur-ensemble généralisé.
Nous nous sommes inspirés de ces travaux pour dénir les relations qui peuvent exister
entre la requête initiale et les requêtes parachutes. Nous avons d'autre part montré qu'il
est intéressant de proposer à l'application plusieurs ensembles de réponses partielles. Cette
remarque a également été formulée par L.Libkin [75].
Réécriture en utilisant des vues Information Manifold réécrit les requêtes qui lui sont
soumises en fonction des vues exportées par les adaptateurs (voir section 2.4.2.1). Il obtient
ainsi la requête maximum contenue dans la requête initiale (maximally contained query) et
retourne systématiquement un sous-ensemble de la réponse exacte.
Plusieurs travaux mentionnent la possibilité qu'un cache sémantique (stockant dans des
relations temporaires les réponses aux requêtes déjà exécutées) puisse être utilisé pour fournir
une réponse partielle à la requête qui est posée si une ou plusieurs sources de données sont
indisponibles. Nous avons discuté cette possibilité en section 3.3.3. Le principe est identique
à celui d'Information Manifold : une réécriture maximale est recherchée pour la requête cou-
rante et un sous-ensemble de la réponse est retourné à l'application. Cette idée appararait
dans les travaux sur Hermes [1] et sur Query Folding [84] [48]. Les techniques proposées per-
mettent de tirer partie des vues stockées dans le cache sémantique ainsi que d'informations
sémantiques comme les dépendances fonctionnelles, les dépendances d'inclusion ou des règles
plus générales 9 pour trouver une réécriture maximale de la requête initiale. L'utilisation d'in-
formations sémantiques pour la génération de requêtes parachutes et plus généralement pour
la réécriture de requêtes est une piste de travail prometteuse [17]. Les travaux que nous ve-
nons de mentionner s'intéressent seulement à la possibilité de retourner un sous-ensemble
de la réponse complète. Nous avons montré que des informations partielles autres que des
sous-ensembles de la réponse complète peuvent être intéressantes.
5.4.1.2 Approche explicite

Lorsqu'une application formule une ou plusieurs requêtes parachutes, elle dénit des
formes dégradées de la requête initiale qui restent intéressantes pour elle. Cette notion de
transformation acceptable de la requête initiale est à la base du système CoBase [31].
CoBase est un système de traitement de requête qui se caractérise par sa capacité à
modier une requête lorsque sa réponse est vide (query relaxation). Lorsqu'une requête a une
réponse vide, CoBase la modie en supprimant ou en modiant une ou plusieurs conditions
qu'elle contient. La requête est ainsi modiée jusqu'à ce qu'une réponse non vide soit obtenue
(lorsqu'elle existe).
Dans CoBase, la modication des requêtes est basée sur une classication hiérarchique
des relations de base. Les valeurs des attributs de chaque relation sont partitionnées en une
hiérarchie de concepts (une ontologie) : chaque niveau fournit une représentation des données
plus abstraite que les niveaux inférieurs. Une telle classication hiérarchique des relations de
base est comparable aux hiérarchies de dimensions dans les systèmes OLAP. Les opérations
sur cette hiérarchie sont la généralisation (roll up) et la spécialisation (drill down).
Les requêtes acceptées par Cobase sont exprimées dans une version modiée de SQL. Ce
langage fournit, premièrement, des opérateurs pour la dénition de conditions (dans la clause
WHERE) basées sur la représentation abstraite des attributs, i.e. plutôt que de fournir une
condition d'égalité sur un attribut il est ainsi possible de spécier un intervalle où cette valeur
peut apparaître. Deuxièmement, une clause WITH est ajoutée pour contrôler le mécanisme
9. Hermes introduit la notion d'invariant. Un invariant est une règle, valable pour toutes les vues du cache
sémantique, qui dénit dans quelles conditions une vue est incluse ou équivalente à une autre.
Comparaison avec des travaux existants 105
de généralisation ou de spécialisation, i.e. il est ainsi possible de spécier que le relâchement
des conditions peut concerner un attribut particulier et pas un autre.
Exemple Considérons une relation AIRPORT qui associe la ville où l'aéroport est im-
planté et la longueur de sa piste d'atterrissage. Les pistes sont divisées en trois catégories :
courtes (de 0 à 4000 mètres), moyennes (de 4000 à 8000 mètres) ou longues (de 8000 à 10000
mètres).
Considérons maintenant que la requête suivante a une réponse vide.
SELECT a_location
FROM airport
WHERE runway_length > 7500 ;
En utilisant le mécanisme de généralisation il est possible d'obtenir la requête suivante dont

la réponse n'est pas vide :
SELECT a_location
FROM airport
WHERE runway_length >= 4000
AND runway_length <= 8000 ;
Il est ainsi possible de suggérer à l'utilisateur une requête approchant sa requête initiale et
dont la réponse n'est pas vide. 2
L'objectif de CoBase est de remédier à des imprécisions dans les requêtes posées par
l'utilisateur ; on peut cependant penser à adapter les techniques de généralisation et de
spécialisation dans le contexte des sources indisponibles. L'application de ces techniques est
limitée. D'une part, CoBase ne prend pas du tout en compte les modications des clauses
SELECT et FROM qui sont nécessaires lorsque des relations entières sont indisponibles.
D'autre part, lorsqu'une relation est indisponible aucune des valeurs qu'elle contient ne
peut être obtenue. Ceci implique une généralisation jusqu'au niveau de représentation le
plus abstrait (i.e. la racine de la hiérarchie) pour chacun de leurs attributs. L'intérêt de la
hiérarchie de concepts est donc perdu.
CoBase suggère un ensemble de requêtes à l'application. Le système en fournit une des-
cription en langage naturel ainsi qu'une description des conditions qu'il a modiées. Cette
description peut être présentée à l'utilisateur pour lui communiquer la signication des in-
formations qui lui sont proposées.
Dyreson [38] étudie le problème des données manquantes dans un système représentant
les données sous forme multi-dimensionnelle (data cube). Les requêtes qu'il considère sont des
agrégats sur des ensembles de valeurs. Un algorithme est fourni pour suggérer des requêtes
moins informatives que la requête initiale si celle-ci ne peut pas être évaluée : les requêtes
générées sont des agrégats sur des sous-ensembles des valeurs dénies dans la requête initiale.
Cet algorithme suit un principe de spécialisation (drill down) sur les hiérarchies de dimensions
comparable à celui de CoBase.
5.4.2 Optimisation d'un ensemble de requêtes
T. Sellis a étudié le problème de l'optimisation d'un ensemble de requêtes [87]. Il formule
le problème comme suit : étant donnés n ensembles de plans d'exécutions locaux, chacun cor-
respondant à une requête diérente, trouver le plan d'exécution global optimal, permettant
de construire les réponses à toutes les requêtes, en mélangeant (merging) n plans d'accès (un
par ensemble).
Le problème principal est d'identier les redondances entre les plans locaux qui parti-
cipent au plan d'exécution global. En eet, l'avantage d'exécuter le plan global par rapport
à exécuter chacun des plans locaux séparément est que les résultats temporaires produits
par les sous-requêtes communes aux diérents plans locaux sont partagés. Nous détaillons
les aspects liés à l'identication des sous-requêtes en section 5.4.2.1.
T. Sellis présente deux classes d'algorithmes [87]. Dans la première classe d'algorithmes,
seuls les plans d'exécutions optimaux sont considérés. Les ensembles de plans locaux se
réduisent donc à un seul élément. L'algorithme IE (Interleaved Execution) identie les sous-
requêtes partagées entre ces plans d'exécutions optimaux pour construire le plan d'exécution
global.
Dans la deuxième classe d'algorithmes, tous les plans d'accès sont considérés (même ceux
qui ne sont pas localement optimum). L'algorithme HA (Heuristic Algorithm) recherche la
combinaison de plans qui permet de construire le plan d'exécution global le moins coûteux.
La recherche est conduite en suivant un algorithme A* qui évite une énumération exhaustive
de toutes les combinaisons possibles.
La diérence principale entre l'algorithme sous contrainte que nous proposons et ces
algorithmes est que notre objectif n'est pas seulement d'optimiser une fonction de coût,
mais avant tout d'identier toutes les sous-requêtes partagées entre la requête initiale et les
5.4.2.1 Identication de sous-requêtes partagées
L'identication de sous-requêtes partagées entre diérentes requêtes est nécessaire dans

plusieurs contextes, i.e. l'optimisation de requêtes multiples [87], l'optimisation sémantique [29],
la réécriture de requête prenant en compte les capacités limités des sources [83], ou la
construction d'adaptateurs [83].
Tous les algorithmes proposés dans ces diérents contextes sont pratiquement identiques.
Ils ressemblent beaucoup à l'algorithme 2-requêtes-srp présenté dans l'étape 1 de l'optimisa-
tion sous contrainte. Tous ces algorithmes reposent sur une procédure de subsumption [28].
Conclusions et Perspectives 107
5.5 Conclusions et Perspectives
Nous avons considéré dans ce chapitre l'extraction d'informations partielles dans un sys-
tème de médiation incrémental. Les informations partielles qui sont extraites sont les données
obtenues des sources disponibles lors de l'exécution de la requête initiale.
Nous avons introduit la notion de requête parachute qui permet à l'application de formuler
explicitement les informations partielles qu'elle souhaite extraire.
L'utilisation des requêtes parachutes pose plusieurs problèmes à l'application. Un premier
problème est de générer des requêtes parachutes conformes aux exigence de l'utilisateur et
aux possibilités du système. Nous avons proposé un algorithme permettant de résoudre ce
problème.
Un deuxième problème est l'interface avec l'utilisateur. Celle-ci doit permettre à l'uti-
lisateur d'indiquer ses exigences et surtout permettre à l'application de communiquer la
signication exacte des réponses partielles qu'elle fournit. Ce problème d'interface graphique
se rapproche du problème qu'ont les systèmes de Data Mining pour guider la génération
de règles associatives et pour présenter les règles obtenues. Dans les deux cas, il s'agit de
communiquer à l'utilisateur des informations sémantiques sur les données qui lui sont pré-
sentées. La présentation en langage naturel des requêtes générées, telle qu'elle est proposée
dans CoBase [31], semble une piste intéressante. Ce problème reste cependant ouvert.
La formulation explicite de requêtes parachutes introduit une complexité supplémentaire
au niveau de l'application. Un développeur d'application qui souhaite proter de l'opportu-
nité d'extraire des informations partielles doit faire un eort particulier concernant l'interface
avec l'utilisateur et la génération de requêtes parachutes. Il semble nécessaire de lui faciliter
la tâche en fournissant des composants et des outils, au dessus du système de médiation,
qui prennent en charge les aspects liés à l'extraction d'informations partielles. Le cadre gé-
néral pour l'extraction d'informations partielles et l'algorithme gen-n-pq sont des premières
étapes dans cette direction. Une des perspectives de notre travail est d'évaluer plus concrè-
tement comment l'extraction d'informations partielles peut être prise en charge au niveau
des applications.
Enn, dans le scénario, où l'application formule une ou plusieurs requêtes parachutes
sans utiliser d'informations fournies par le système, celui-ci doit optimiser ses chances d'y
répondre. Nous avons déni (i) un algorithme d'optimisation sous contrainte qui identie les
sous-requêtes partagées entre la requête initiale et les requêtes parachutes, et (ii) une politique
de matérialisation qui tire parti de ces informations. Cet algorithme dière des algorithmes
existants d'optimisation d'un ensemble de requêtes dans le sens où son objectif n'est pas
seulement de minimiser les coûts mais surtout d'isoler l'ensemble des sous-requêtes partagées
entre la requête initiale et les requêtes parachutes. Diérents aspects des performances de
cet algorithme sont étudiés dans le chapitre suivant.
109
Chapitre 6
Évaluation
Les techniques de traitement incrémental des requêtes (présentées dans le chapitre 4)
et d'optimisation sous contrainte (présentées en section 5.3) ont des objectifs en terme de
performance.
Nous avons utilisé un modèle analytique et un simulateur pour l'évaluation des perfor-
mances. Leurs caractéristiques sont décrites en section 6.1 ainsi que la charge de travail qui
nous a permis de mener nos expériences.
L'objectif du traitement incrémental des requêtes est de permettre d'améliorer le temps
de réponse du système de médiation lorsqu'une même requête doit être soumise plusieurs fois
pour obtenir la réponse complète. Une des composantes principales du temps de réponse est
le temps d'attente entre les soumissions successives. Ce facteur échappe au système puisque
c'est l'application qui décide de soumettre une requête incrémentale (ou bien de soumettre à
nouveau la même requête). Les composantes du temps de réponse qui dépendent du système
sont le temps de traitement et le nombre de soumissions qui sont nécessaires pour obtenir la
réponse complète. Nous étudions ces deux aspects en section 6.2.
L'optimisation sous contrainte a pour objectif d'augmenter la probabilité de répondre aux
requêtes parachutes tout en conservant des performances raisonnables. Nous avons étudié
l'inuence de l'optimisation sous contrainte et de la politique de matérialisation SRP sur (1)
le temps de traitement et (2) les capacité du système a répondre aux requêtes parachutes.
Les résultats sont présentés en section 6.3.
La disponibilité des sources de données est un paramètre important dans notre modèle
analytique et dans certaines expériences menées avec le simulateur. Nous avons réalisé une
expérience pour estimer la disponibilité des sources de données dans l'application Redoc.
Nous présentons les résultats obtenus en section 6.4.
110 Évaluation
6.1 Cadre Expérimental
6.1.1 Modèle Analytique
En présence de sources de données indisponibles, une application a besoin de soumettre
une même requête plusieurs fois pour obtenir la réponse complète. Nous appelons chacune
de ces soumissions, un essai. A chaque essai le système tente de contacter un ensemble de
sources de données. Chaque source de données est soit disponible, soit indisponible. Une
source de données disponible renvoie une réponse à la sous-requête qui lui a été envoyée, une
source indisponible ne renvoie pas de réponse. Nous considérons que chaque essai concernant
une source est un événement aléatoire indépendant où la source de données est disponible
avec la probabilité p et indisponible avec la probabilité 1 , p. Nous dénissons dans cette
section, le modèle analytique d'un système classique et d'un système incrémental.
Un système classique peut être modélisé comme suit. Lorsqu'une requête est soumise à un
système classique, le système contacte les n sources de données pendant t essais. Il retourne
une réponse complète si les sources de données sont toutes disponibles lors d'au moins un des
essais eectués. La gure 6.1 illustre quatre sources de données pendant trois essais. Chaque
essai est représenté de manière horizontale, comme la concaténation de n ronds ou croix. Un
rond représente une source indisponible, et une croix une source disponible. Sur la gure, le
système classique retourne une réponse complète au troisième essai (représentée par la ligne
droite entre les croix): toutes les sources de données sont disponibles simultanément.
Trials Trials
3 3
2 2
1 1
A B C D A B C D
Data Sources Data Sources
Fig. 6.1 Système classique Fig. 6.2 Système incrémental

Pour exprimer la probabilité qu'a un système classique de fournir au moins une réponse
complète en t essais, nous établissons la probabilité que n sources soient disponibles simul-
tanément au moins une fois en t essais. La probabilité que n sources de données soient
disponibles durant un essai est pn. La probabilité que toutes les sources ne soient pas dis-
ponibles pendant un essai est 1 , pn. Pour t essais, la probabilité que toutes les sources ne
soient pas disponibles est de (1 , pn)t. Pour t essais, la probabilité que, lors d'au moins un
essai toutes les sources de données soient disponibles est
1 , (1 , pn)t (6.1)
L'équation 6.1 représente la probabilité qu'a un système classique, qui contacte n sources de
données, de fournir au moins une réponse complète en t essais.
Cadre Expérimental 111
Un système incrémental matérialise les données obtenues de toutes les sources disponibles,
si l'espace de stockage le permet (le cas de l'espace de stockage limité n'est pas pris en
compte dans le modèle analytique, cet aspect est étudié avec le simulateur en section 6.2.2.2).
Lorsqu'une requête est soumise, le système contacte les n sources de données et obtient les
données fournies par les sources nouvellement disponibles à chaque essai. Après t essais, une
réponse complète peut être retournée si les données ont été obtenues de toutes les n sources.
Une source de données a besoin d'être disponible une seule fois pour participer à la réponse
complète. La gure 6.2 illustre encore quatre sources de données pendant trois essais dans
le cas du système incrémental. Sur la gure, le système incrémental retourne une réponse
complète dés le deuxième essai (représentée par une ligne brisée entre les croix) : toutes les
sources de données ont été disponibles au moins une fois dans les essais précédents.
Pour exprimer la probabilité qu'a un système incrémental de fournir au moins une réponse
complète en t essais, nous exprimons la probabilité que n sources soient disponibles au moins
une fois en t essais. La probabilité qu'une source de données ne soit jamais disponible en t
essais est (1 , p)t. La probabilité qu'une source de données soit disponible au moins une fois
en t essais est 1 , (1 , p)t . la probabilité que les n sources soient disponibles au moins une
fois en t essais est
(1 , (1 , p)t)n (6.2)
L'équation 6.2 représente la probabilité qu'a un système incrémental, qui contacte n sources
de données, de fournir au moins une réponse complète en t essais. Notez que les équations
6.1 et 6.2 sont égales si p = 0 ou p = 1 ou t = 1 ou n = 1.
6.1.2 Environnement de simulation

Pour étudier les caractéristiques d'un système incrémental, nous avons étendu le simula-
teur SIUMEI 1 [44, 33, 104]. Celui-ci modélise un ensemble de serveurs de bases de données
interconnectés (peer-to-peer database system). Nous décrivons brièvement ce simulateur et
présentons les extensions que nous avons implantés pour simuler un système incrémental.
La table 6.1 décrit les principaux paramètres du simulateur et les valeurs que nous uti-
lisons pour nos expériences. Le système de médiation est modélisé comme un serveur. Il est
connecté à NumSites sources de données. Chaque source de données est également modélisée
comme un serveur. Chacune d'elles stocke une relation. Le système de médiation peut maté-
rialiser les résultats temporaires sur disque. Chaque serveur est caractérisé par la vitesse de
son CPU spéciée dans le paramètre Mips, NumDisks disques, et un buer en mémoire de
taille Memory. Les serveurs sont connectés par un réseau caractérisé par sa bande passante
NetBw. Le réseau est modélisé comme une le FIFO. Bien que les serveurs soient congurés
avec de la mémoire, les relations de base et les relations matérialisées sont toujours lues à
partir du disque du serveur où elles sont situées, i.e. il n'y a pas de caching entre les requêtes
et les relations sont accédées une seule fois par requête.
1. SIUMEI a été développé à l'Université du Maryland, College Park. Nous remercions Mike Franklin
pour avoir mis ce système a notre disposition et Björn Jònsson pour le support qu'il nous a fourni.
112 Évaluation
Paramètre Valeur Description
NumSites 3 ou 5 nombre de sources de données
Mips 200 puissance CPU (106 instr/sec)
NumDisks 1 nombre de disques par source de données
DskPageSize 4096 taille d'une page disque (en octets)
NetBw 0.5 bande passante réseau (en Mbit/sec)
NetPageSize 4096 taille d'une page réseau (en octets)
Compare 4 instr. pour évaluer un prédicat
HashInst 25 instr. pour réaliser le hash d'un tuple
Move 2 instr.pour copier 4 octets
memory 2048 taille mémoire (en pages disque)
time-out 10 time-out pour detect (en sec)
Tab. 6.1 Paramètres du simulateur.
Nous étendons le simulateur en introduisant les algorithmes sense et materialize, pré-

sentés dans le chapitre 4. Dans la phase de détection, les sources indisponibles sont modélisées
simplement comme suit. Lorsqu'un serveur, représentant une source de données, est contacté,
il est soit disponible soit indisponible. Si le serveur est disponible, il répond immédiatement.
Si le serveur est indisponible, le système de médiation le détecte après time-out secondes.
Dans nos expériences, nous utilisons un time-out de 10 secondes. Nous utilisons cette va-
leur de manière à ce que l'inuence du time-out puisse être clairement distinguée dans le
comportement du système de médiation. En ce qui concerne l'algorithme de matérialisation,
nous avons implémenté les politiques max et feuilles, présentées en section 4.4, ainsi que la
politique des sous-arbres partagés, présentée en section 5.3.3 .
Pour la simulation des systèmes classique et incrémental nous utilisons un optimiseur
muni d'un modèle de coût implémenté en Prolog. L'objectif de notre optimiseur est de
minimiser le temps de réponse. Le parallélisme potentiel entre opérateurs est donc pris en
compte; les coûts induits par les communications sur le réseau sont également pris en compte
(en ajoutant le temps de transmission et le coût logiciel du au protocole réseau). Pour la
simulation du système incrémental sous contrainte, nous utilisons une implémentation Pro-
log de l'algorithme d'optimisation sous-contrainte présenté en section 5.3.2. Cet algorithme
utilise l'optimiseur basé sur les coûts décrit ci-dessus. Les résultats décrits dans les sec-
tions suivantes n'incluent ni le temps d'optimisation, ni le temps nécessaire pour exécuter
l'algorithme construct.
6.1.3 Charge de Travail

Nous examinons les performances d'un système incrémental en utilisant une charge de
travail dérivée de TPC-D. Le schéma est constitué de : fournisseurs (suppliers - S), produits
(P), la relation entre produits et fournisseurs (PS), clients (C), ordres (O), lignes de com-
mandes (L), nations (N) et regions (R). La base de données est constituée en utilisant un
facteur d'échelle de 1. Par conséquent, S contient 10000 tuples, P contient 200000 tuples,
PS contient 800000 tuples, C contient 150000 tuples, O contient 1500000 tuples, L contient
Cadre Expérimental 113
6000000 tuples, N contient 25 tuples et R contient 5 tuples. Les détails du benchmark TPC-D
sont disponibles dans le document de spécication [32].
Les deux relations régions et nations, qui contiennent peu de tuples sont stockées sur
le site du système de médiation. Les autres relations de bases sont placées chacune sur
une source de données. L'optimiseur décide si les opérations de sélection et de projection
sont exécutées sur le site du système de médiation où sur la source de données. Dans nos
expériences, nous modélisons les eets des projections en xant la taille des tuples projetés
(40 octets).
Nous utilisons, pour nos expériences, deux requêtes conjonctives exprimées sur le schéma
présenté ci-dessus, MQ2 et MQ8. Ces deux requêtes sont dérivées des requêtes Q2 et Q8 du
benchmark TPC-D. Ces requêtes, détaillées ci-dessous, ont été introduites dans [104]. Leur
complexité est raisonnable et elles nous permettent d'étudier notre approche en utilisant des
graphes de jointures, des sélectivités et des cardinalités réalistes. La taille des relations étant
conséquente et le débit du réseau étant faible dans notre environnement de simulation, nous
attendons des temps de réponse élevés.
6.1.3.1 MQ2
La requête MQ2 permet d'obtenir les coordonnées des fournisseurs de produits d'un
certain type et d'une certaine taille ainsi que la clé et le constructeur du produit. Cette
requête, dont le code SQL est présenté dans la gure 6.3 est une jointure entre 5 relations;
elle implique trois relations situées sur des sources de données (P, PS et S) et deux relations
stockées par le système de médiation (R et N).
SELECT S.ACCTBAL, S.NAME, N.NAME, P.PARTKEY, P.MFGR,
S.ADDRESS, S.PHONE, S.COMMENT
FROM PART P, SUPPLIER S, PARTSUPP PS,
NATION N, REGION R
WHERE N.NATIONKEY = S.NATIONKEY AND R.NAME = 'EUROPE'
AND N.NATIONKEY = R.NATIONKEY AND PS.SUPPKEY = S.SUPPKEY
AND PS.PARTKEY = P.PARTKEY AND P.SIZE = 15
AND P.TYPE LIKE 'BRASS';
Fig. 6.3 MQ2 en SQL.

La gure 6.4 décrit le graphe de requête pour MQ2. Chaque relation de base est repré-
sentée par son nom. Les arcs entre les relations sont annotés par la sélectivité des jointures
correspondantes. Les prédicats de sélection sont représentés par des carrés entourant les
relations sur lesquelles ils s'appliquent et leur sélectivité est indiquée au dessus de ce carré.
La gure 6.5 présente le plan d'exécution pour la requête MQ2. Ce plan d'exécution est
obtenu avec l'optimiseur basé sur les coûts. Il s'agit d'un peigne (right linear tree), où les
jointures sont des hash join et où les phases de construction des tables de hachage sont
114 Évaluation
Π
submit
1/250 1/5
1/200000 1/10000 1/25 1/5

P PS S N R Π
submit
Π
Fig. 6.4 Graphe de requête pour
submit
σ
MQ2. PS Π N
σ
P
S
R
Fig. 6.5 Plan d'exécution pour MQ2.
eectuées en parallèle.
6.1.3.2 MQ8
La requête MQ8 permet d'obtenir la date à laquelle un ordre sur un produit particulier a
été passé par un client européen avec le prix d'achat ainsi que la nationalité du fournisseur.
Cette requête est une jointure entre 7 relations avec des sélections sur les relations produits
(P), ordre (O) et régions (R). La gure 6.6 présente le code SQL de cette requête ; la gure 6.7
décrit son graphe de requête.
SELECT O.ORDERDATE, L.EXTENDEDPRICE, N2.NAME

FROM PART P, CUSTOMER C, ORDER O, LINEITEM L,
SUPPLIER S, NATION N1, NATION N2, REGION R
WHERE P.PARTKEY = L.PARTKEY AND L.SUPPKEY = S.SUPPKEY
AND O.ORDERKEY = L.ORDERKEY AND C.CUSTKEY = O.CUSTKEY
AND C.NATIONKEY = N1.NATIONKEY AND N1.REGIONKEY = R.REGIONKEY
AND R.NAME = 'EUROPE' AND S.NATIONKEY = N2.NATIONKEY
AND O.ORDERDATE BETWEEN '94-01-01' AND '95-12-31'
AND P.TYPE = 'SMALL PLATED STEEL';
Fig. 6.6 MQ8 en SQL.
La gure 6.8 présente le plan d'exécution pour MQ8 obtenu avec l'optimiseur basé sur
les coûts. Avec une mémoire de 2048 pages, aucun partitionnement n'est nécessaire.
Traitement incrémental des requêtes 115
Π
1/150 2/7 1/5 submit

N2
1/200000 1/1500000 1/150000 1/25 1/5
P L O C N1 R Π
1/10000
S
S submit submit
submit
1/25
Π Π Π
σ
N2 σ L
σ
Fig. 6.7 Graphe de requête pour MQ8.

N1 submit R
P O
Π
Fig. 6.8 Plan d'éxécution

pour MQ8.
6.2 Traitement incrémental des requêtes

Le temps de réponse, lorsqu'une requête doit être soumise plusieurs fois pour obtenir la
réponse complète, est la combinaison (i) du temps d'attente entre les soumissions, (ii) du
temps de traitement lors de chaque soumission et (iii) du nombre de soumissions nécessaires.
Le premier point dépend uniquement de l'application, les deux autres points sont de la
responsabilité du système. Nous étudions donc ici le temps de traitement et le nombre de
soumissions nécessaires pour obtenir la réponse complète.
6.2.1 Temps de traitement

Le problème pour mesurer le temps de traitement en présence de sources de données
indisponibles est que ce dernier dépend du nombre d'essais qui sont eectués et des con-
gurations de sources disponibles. Pour pouvoir discuter simplement des aspects essentiels
liés au temps de traitement nous avons donc déni une nouvelle expérience, l'expérience des
deux essais, où le nombre d'essais est xé et où nous étudions toutes les congurations de
sources disponibles.
6.2.1.1 Expérience des deux essais

Nous avons mis en place l'expérience des deux essais pour mesurer le temps de traite-
ment dans les systèmes de médiation que nous simulons. Lors du premier essai, certaines
116 Évaluation
sources de données sont indisponibles (nous examinons toutes les combinaisons de sources
indisponibles) ; lors du deuxième essai, toutes les sources sont disponibles. Nous mesurons
le temps de réponse lors de chaque essai. La première mesure donne le temps de notica-
tion, la deuxième essai donne le temps jusqu'à la réponse complète. Noter que dans le cas
où toutes les sources de données sont disponibles lors du premier essai, la réponse retournée
par le système est la réponse complète. Le temps de notication est dans ce cas le temps
jusqu'à la réponse complète et il n'y a pas de deuxième essai. Nous additionnons le temps
de notication et le temps jusqu'à la réponse complète pour obtenir le temps de traitement
de la requête.
Nous réalisons l'expérience des deux essais avec les systèmes classique, incrémental et
plan_partiel 2. Ce dernier système conserve le plan partiellement exécuté obtenu après le
premier essai et le réutilise lors du deuxième essai.
Avec le système classique, lors du premier essai, la requête est soumise, optimisée et
exécutée ; l'exécution continue jusqu'à ce qu'une source soit détectée indisponible. Lors du
second essai, la même requête est soumise, elle est à nouveau optimisée (le même plan
d'exécution est obtenu) et ré-exécutée complètement ; toutes les sources de données sont
disponibles, la réponse complète est donc obtenue.
Le système plan_partiel fonctionne lors du premier essai comme le système classique. La
requête est soumise, optimisée (l'optimiseur est le même que dans le système classique, le
même plan d'exécution est donc choisi) et exécutée jusqu'à ce qu'une source de données soit
détectée indisponible. Le plan d'exécution contenant des résultats intermédiaires (les tables
de hachage obtenues lors de la phase build des hash join) est conservé et réutilisé lors du
deuxième essai ; la réponse complète est obtenue en utilisant ces structures intermédiaires et
les données obtenues des sources de données auparavant indisponibles.
Le système incrémental implémente l'algorithme materialize avec la politique max et un
espace de stockage illimité 3. Lors du premier essai, la requête est soumise et optimisée (le plan
d'exécution choisi est similaire à celui choisi par le système classique). L'exécution commence
par la phase de détection des sources indisponibles. Si toutes les sources sont disponibles, la
réponse complète est produite. Si une ou plusieurs sources sont indisponibles, l'algorithme
de matérialisation est appelé et une requête incrémentale est produite. Lors du deuxième
essai, la requête incrémentale est soumise, optimisée et exécutée; la réponse complète est
produite en utilisant les données matérialisées lors du premier essai et les données obtenues
des sources auparavant indisponibles.
Nous montrons tout d'abord les résultats de l'expérience des deux essais avec la requête
MQ8. La gure 6.8 de la section 6.1.3.2 représente le plan d'exécution choisi pour MQ8.
Avec une mémoire de 2048 pages, aucun partitionnement n'est nécessaire lors de l'exécution
des hash join. Les plans d'exécution choisis pour les requêtes incrémentales sont similaires
au plan d'exécution choisi pour MQ8. Les coûts de transfert de données sur le réseau sont
moins importants avec les requêtes incrémentales qu'avec la requête initiale ; cela ne conduit
2. Nous avons évoqué le système plan_partiel en section 4.2.1
3. Toutes les données disponibles sont donc matérialisées. Nous étudions les eets de la politique de
matérialisation sur le temps de traitement en section 6.3.3.1.
cependant pas notre optimiseur a choisir un plan d'exécution de forme diérente 4 .
10000
9000
8000
7000
6000
temps en sec
plan_partiel
classique
5000
incremental
4000
3000
2000
1000
0
all L-O- P-O- P-L- P-L- P-L- O-C- L-C- L-O- L-O- P-C- P-O- P-O- P-L- P-L- P-L- C-S O-S O-C L-S L-C L-O P-S P-C P-O P-L S C O L P none
C-S C-S C-S O-S O-C S S S C S S C S C O
sources disponibles
Fig. 6.9 MQ8 - Temps de traitement total pour toutes les congurations de sources dispo-
nibles - Trois systèmes: plan_partiel, classique et incrémental.
La gure 6.9 montre les résultats de l'expérience des deux essais avec la requête MQ8.
L'axe des abscisses indique la conguration des sources disponibles dans le premier essai et
l'axe des ordonnées indique le temps de traitement total en seconde (i.e. la somme des temps
de réponse mesurés lors du premier et du second essai). Les lignes entre les points sont juste
une aide qui permet au lecteur de facilement distinguer les diérents systèmes.
Dans le cas où toutes les sources sont disponibles, la réponse complète est retournée lors
du premier essai, en 4330 secondes. Ceci est valable pour les trois systèmes que nous étudions.
L'approche incrémentale n'introduit donc pas de surcoût par rapport à l'approche classique
dans le cas où toutes les sources de données sont disponibles.
Le temps de traitement pour le système plan_partiel est à peu prés constant. Ce système
n'est pas sensible aux congurations de sources disponibles. En eet, l'évaluation interrompue
lors du premier essai (dès qu'une source est détectée indisponible) reprend et termine lors
du deuxième essai (toutes les sources sont alors disponibles). Tous les traitements eectués
4. Le coût de transfert des données est limité dans notre optimiseur aux coûts liées au protocole et aux
coûts d'envoi de message. Un modèle de coût plus ané pourrait conduire l'optimiseur a choisir un plan
d'exécution de forme diérente entre la requête initiale et certaines requêtes incrémentales.
118 Évaluation
lors du premier essai sont donc réutilisés lors du deuxième. Le temps de traitement avec le
système plan réutilisé correspond donc au temps de traitement lorsque la réponse complète
est obtenue en un seul essai.
Le temps de traitement pour le système classique dépend fortement de la conguration
de sources disponibles. Dans toutes les congurations où les relations P et L sont toutes deux
disponibles, le temps de traitement est approximativement de 8500 secondes ; dans toutes
les autres congurations, le temps de traitement n'excède pas 4700 secondes. Lorsque P et
L sont disponibles, la jointure entre ces deux relations est exécutée lors de chaque essai. Par
conséquent, le coût élevé de cette jointure est payé deux fois. Ce double paiement résulte
du principal handicap du système classique : le travail n'est pas réutilisé entre les essais
successifs.
Le temps de traitement dans un système incrémental est également sensible à la congu-
ration des sources disponibles, mais dans une moindre mesure. Dans toutes les congurations
où L est disponible et P ne l'est pas, L est matérialisé. Le coût de la matérialisation de cette
très grosse relation lors du premier essai ajouté au coût de la lecture locale lors du deuxième
essai induit une augmentation du temps de traitement (autour de 5000 secondes) par rapport
aux autres congurations (autour de 4330 secondes). Lorsque P et L sont toutes les deux
disponibles, leur jointure est exécutée (car la politique de matérialisation des sous-arbres
maximaux est utilisée ici), L n'est pas matérialisé et le temps de traitement est moindre.
1200
1000
800
temps en sec
plan_partiel
incremental
600
classique
400
200
0
all PS-S P-S P-PS S PS P none
sources disponibles
Fig. 6.10 MQ2 - Temps de traitement total pour toutes les congurations de sources dis-
ponibles - Trois systèmes: plan_partiel, classique et incrémental.
La gure 6.10 présente les résultats de l'expérience des deux essais avec la requête MQ2.
Ces résultats sont identiques à ceux décrits précédemment avec MQ8. Le cas où le temps
de traitement du système incrémental est supérieur à celui du système classique n'apparait
cependant pas ici. Nous détaillons avec les gures suivantes le temps de traitement lors du
600
600
500
500
400 400
temps en sec
temps en sec
1er essai 1er essai
300 2eme essai 300 2eme essai
200
200
100
100
0
all PS-S P-S P-PS S PS P none 0
sources disponibles all PS-S P-S P-PS S PS P none
sources disponibles
Fig. 6.11 MQ2 - 2 essais - système Fig. 6.12 MQ2 - 2 essais - système clas-
plan_partiel. sique.
700
600
500
400
temps en sec
1er essai
2eme essai
300
200
100

sources disponibles
Page 1
Fig. 6.13 MQ2 - 2 essais - système incré-

mental.
premier et du deuxième essai.

La gure 6.11 montre le temps de réponse du système plan_partiel lors du premier et du
deuxième essai de notre expérience avec la requête MQ2. Lorsque toutes les sources de don-
nées sont disponibles lors du premier essai, la réponse complète est obtenue en 543 secondes.
Le temps de traitement (somme des temps mesurés pour les deux essais) est pratiquement
constant avec le système plan_partiel (voir gure 6.10). Tout le travail eectué lors du pre-
mier essai est réutilisé lors du deuxième essai. Il apparait dans la gure 6.11 que le temps de
traitement est dominé par la relation PS. Dans toutes les congurations où la source PS est
disponible lors du premier essai, le temps mesuré pour le premier essai est entre 520 et 530
secondes, alors que le temps mesuré pour le deuxième essai est entre 10 et 20 secondes. Dans
les congurations où PS n'est pas disponible lors du premier essai, c'est la situation inverse.
La gure 6.12 montre le temps de réponse du système classique lors du premier et du
deuxième essai. Dans les trois congurations où PS est disponible lors du premier essai, le
prix de la construction de la table de hachage sur cette relation est payé lors des deux essais.
Ainsi, lors des deux essais, le temps de réponse est supérieur à 500 secondes et le temps de
120 Évaluation
traitement total est bien supérieur au temps de traitement total des deux autres systèmes.
La gure 6.13 montre le temps de réponse du système incrémental lors du premier et du
deuxième essai. De manière générale le temps mesuré pour le deuxième essai est inversement
proportionnel au temps mesuré pour le premier essai. Le travail de matérialisation eectué
lors du premier essai rend l'évaluation de la requête incrémentale ecace lors du deuxième
essai. Comme dans les deux cas précédents, le temps de traitement est dominé par la relation
PS. Lorsque celle-ci est disponible lors du premier essai, l'essentiel du travail est eectué à
cette occasion.
Dans les congurations P-PS et PS, le temps mesuré lors du premier essai est supérieur
à 600 secondes, i.e. supérieur au temps nécessaire pour fournir la réponse complète en un
essai. C'est la matérialisation de la relation PS qui entraîne ce surcoût. Dans la conguration
où PS et S sont disponibles, leur jointure est eectuée lors du premier essai. Le résultat de
la jointure est matérialisé ; cette relation temporaire contient moins de tuples que la relation
PS seule et entraîne donc un surcoût moindre. Ainsi, il existe des congurations où le temps
de notication d'un système incrémental est important ; c'est le prix à payer en terme de
temps de réponse pour le traitement incrémental des requêtes (et la possibilité de fournir
des informations partielles).
6.2.1.2 Discussion
L'expérience des deux essais démontre que le système incrémental ne pénalise pas les
performances dans le cas où toutes les sources de données sont disponibles lors du premier
essai. Si une ou plusieurs sources de données sont indisponibles, des relations temporaires
sont créées et ensuite lues localement. Ceci implique une augmentation dans le temps de
traitement total. Si les relations temporaires sont petites, l'impact sur les performances est
faible. Autrement, la dégradation des performances est plus limité que dans un système
classique où des opérations coûteuses sont exécutées plusieurs fois selon la conguration des
sources disponibles.
Le temps de traitement permet de comparer les caractéristiques des diérents systèmes.
Cependant, dans la réalité le temps d'attente domine le temps de réponse. Le nombre de
soumissions nécessaires pour obtenir la réponse complète est un facteur essentiel, puisque
lorsque le nombre de soumissions diminue, le nombre d'intervalles où l'application est forcée
d'attendre diminue.
6.2.2 Nombre de soumissions pour obtenir la réponse complète

Lorsqu'une ou plusieurs sources de données sont indisponibles lors du traitement d'une
requête, un système incrémental obtient des données des sources disponibles. Ces données
sont réutilisées lorsque la requête est soumise à nouveau. Nous étudions le nombre de sou-
missions nécessaires pour obtenir la réponse complète dans un système classique 5 et dans
un système incrémental. Dans un premier temps nous ne tenons pas compte des limitations
éventuelles sur l'espace de stockage (c'est le cas où les données de toutes les sources dispo-
nibles peuvent être matérialisées). Dans un deuxième temps nous étudions le comportement
des deux systèmes avec un espace de stockage limité.
6.2.2.1 Espace de stockage illimité

Nous utilisons le modèle analytique, décrit en section 6.1.1 pour étudier la probabilité
d'obtenir une réponse complète dans les systèmes classique et incrémental. Nous considérons
ici que l'espace de stockage est illimité, i.e. le système incrémental matérialise les données
obtenues de toutes les sources disponibles.
1 1
Probabilite d’obtenir au moins une reponse

0.8 0.8
0.6 0.6
0.4 0.4
0.2 classique 0.2 classique

incremental incremental
0 0
0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1
Disponibilite des sources Disponibilite des sources
Fig. 6.14 Probabilité d'obtenir au moins Fig. 6.15 Probabilité d'obtenir au moins
une réponse complète en deux essais pour une réponse complète en deux essais pour
MQ2 MQ8
Les gures 6.14 et 6.15 présentent la probabilité d'obtenir au moins une réponse complète
en deux essais en fonction de la disponibilité des sources de données pour MQ2 (3 sources
de données contactées) et MQ8 (cinq sources de données) respectivement. Les gures 6.16
et 6.17 tracent la même fonction avec un nombre d'essais xé à quatre. L'axe des abscisses
indique la disponibilité des sources de données et l'axe des ordonnées indique la probabilité
d'obtenir au moins une réponse complète.
L'événement correspondant à un système classique retournant une réponse complète en
t essais est inclus dans l'événement correspondant à un système incrémental retournant une
réponse complète en t essais. En eet, si n sources sont disponibles simultanément au moins
une fois en t essais, alors chacune des n sources est disponible au moins une fois en t essais.
Par conséquent, la courbe correspondant à la probabilité d'obtenir au moins une réponse
complète en t essais pour le système incrémental constitue une borne supérieure pour la
courbe du système classique.
5. Un système classique contacte toutes les sources de données impliquées dans la requête pour construire
sa réponse.
122 Évaluation
1 1

0.8 0.8
0.6 0.6
0.4 0.4
0.2 classique 0.2 classique

incremental incremental
0 0
0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1
Fig. 6.16 Probabilité d'obtenir au moins Fig. 6.17 Probabilité d'obtenir au moins
une réponse complète en quatre essais pour une réponse complète en quatre essais pour
MQ2 MQ8
De manière générale, le système incrémental permet d'obtenir une probabilité non nulle
avec une disponibilité des sources plus faible que le système classique. D'autre part, et c'est
plus intéressant, le système incrémental permet d'atteindre une probabilité d'obtenir une
réponse complète proche de 100% avec une disponibilité des sources plus faible que le système
classique. Par exemple, dans la gure 6.16, le système incrémental permet d'obtenir une
probabilité d'obtenir au moins une réponse à MQ8 en 4 essais dès que la disponibilité des
sources atteint 85% alors qu'une disponibilité des sources de 95% est nécessaire pour atteindre
un résultat similaire avec un système classique.
Lorsque le nombre de sources de données impliqué dans la requête augmente (MQ2
implique trois sources de données, alors que MQ8 en implique cinq), la probabilité d'obtenir
une réponse complète diminue pour une disponibilité des sources particulière. Par exemple,
dans la gure 6.14, la probabilité d'obtenir au moins une réponse à MQ2 en deux essais pour
une disponibilité des sources de 80%, est légèrement inférieure à 80% ; dans la gure 6.15,
cette probabilité pour MQ8 est inférieure à 60%. Comme les valeurs aux bornes ne varient
pas avec le nombre de sources de données (lorsque la disponibilité est nulle la probabilité
d'obtenir une réponse est nulle, et inversement, lorsque toutes les sources de données sont
disponibles la probabilité d'obtenir une réponse est de 100%), la pente des courbes augmente
lorsque le nombre de sources de données impliquées dans la requête augmente.
Lorsque le nombre d'essais permettant d'obtenir la réponse complète augmente, la proba-
bilité d'obtenir une réponse complète augmente. Cette probabilité augmente plus vite dans
le cas d'un système incrémental que d'un système classique. Par exemple, la probabilité d'ob-
tenir une réponse à MQ2 en deux essais lorsque la disponibilité des sources est de 60%, est
de 60% avec un système incrémental et de 40% avec un système classique. Lorsque le nombre
d'essais passe à quatre, la probabilité d'obtenir une réponse avec un système incrémental est
supérieure à 90% alors qu'elle est de 60% avec un système classique.
En reprenant les équations du modèle analytique, il est possible d'exprimer le nombre
d'essais en fonction de la disponibilité des sources, du nombre de sources et de la probabilité
Nombre d’essais pour obtenir au moins une reponse

10 10
classique classique
9 incremental 9 incremental
8 8
7 7
6 6
5 5
4 4
3 3
2 2
1 1
0 0
0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1
Fig. 6.18 Nombre d'essais nécessaires pour Fig. 6.19 Nombre d'essais nécessaires pour
obtenir au moins une réponse complète à obtenir au moins une réponse complète à
MQ2 avec une probabilité de 90% MQ8 avec une probabilité de 90%
d'obtenir au moins une réponse. Bien sûr, seules les valeurs entières du nombre d'essais sont
signicatives dans ces nouvelles équations.
Les gures 6.18 et 6.19 représentent le nombre d'essais permettant d'obtenir une réponse
complète avec une probabilité de 90% pour MQ2 et MQ8 respectivement. Les gures 6.20
et 6.21 représentent le nombre d'essais permettant d'obtenir une réponse complète avec une
probabilité de 99% également pour MQ2 et MQ8. L'axe des abscisses indique la disponibilité
des sources, et l'axe des ordonnées indique le nombre d'essais (même si les courbes sont
continues, seules les valeurs entières de t sont signicatives).
Ici, la courbe du système incrémental est une borne inférieure à la courbe du système clas-
sique. Dans les quatre gures, l'écart entre les deux courbes augmente lorsque la disponibilité
des sources diminue.
Lorsque le nombre de sources augmente, la disponibilité des sources nécessaires pour
obtenir au moins une réponse en un nombre d'essais xé augmente fortement pour le système
classique alors qu'elle varie peu pour le système incrémental. Par exemple, pour obtenir une
réponse en cinq essais à MQ2 avec une probabilité de 90%, la disponibilité des sources peut
être légèrement inférieure à 50% pour un système incrémental et légèrement supérieur à 70%
pour un système classique. Dans le cas de MQ8, la disponibilité est légèrement supérieure à
50% pour le système incrémental et doit être supérieure à 80% pour le système classique. De
manière prévisible, le nombre d'essais nécessaires pour obtenir au moins une réponse avec
une probabilité de 99% est supérieur au nombre d'essais nécessaires pour obtenir au moins
une réponse avec une probabilité de 90%.
6.2.2.2 Espace de stockage limité

Dans cette section, nous étudions le nombre de soumissions nécessaires pour obtenir la
réponse complète dans un système incrémental dont l'espace de stockage est limité.
124 Évaluation

10 10
classique classique
9 incremental 9 incremental
8 8
7 7
6 6
5 5
4 4
3 3
2 2
1 1
0 0
0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1
Fig. 6.20 Nombre d'essais nécessaires pour Fig. 6.21 Nombre d'essais nécessaires pour
obtenir au moins une réponse complète à obtenir au moins une réponse complète à
MQ2 avec une probabilité de 99% MQ8 avec une probabilité de 99%
Nous utilisons le simulateur en réalisant l' expérience suivante (que nous décrivons dans
le détail pour la requête MQ2, nous avons eectué cette expérience avec MQ8 également et
nous discutons les résultats obtenus ci-dessous). Chaque source de données a la probabilité
p d'être disponible : chaque fois qu'une source est contactée, celle-ci détermine de manière
aléatoire si la source est disponible ou non. La requête MQ2 est évaluée avec un espace de
stockage xé. Si, une ou plusieurs sources de données sont détectées indisponibles les résultats
intermédiaires disponibles sont matérialisés selon l'algorithme materialize présenté dans la
section 4.4. Le plan d'exécution choisi pour les requêtes incrémentales est similaire à celui
présenté pour MQ2 dans la section 6.1.1, aucun partitionnement n'est nécessaire. Les requêtes
incrémentales sont construites et soumises jusqu'à ce que la réponse complète soit obtenue.
Nous eectuons plusieurs trains d'expérience en répétant l'expérience 100, 500 et 1000 fois.
Nous calculons pour chaque train d'expériences le nombre moyen d'essais nécessaires pour
obtenir la réponse complète. Nous retenons la moyenne de ces résultats en calculant son
intervalle de conance ; nous utilisons ici un intervalle de conance de 90% (calculé avec la
formule fournie dans [59]).
Etant donné la requête MQ2, il y a huit congurations possibles de sources disponibles
(car cette requête implique trois sources de données). Pour chaque conguration, les sous-
plans candidats à la matérialisation sont connus (en fonction de la politique de matériali-
sation) et le nombre de pages nécessaires à la matérialisation peut être associé à chacun de
ces sous-plans; ils sont présentés dans la table 6.2 pour la politique de matérialisation des
feuilles et dans la table 6.3 pour la politique de matérialisation des sous-arbres maximaux
disponibles. Selon l'algorithme materialize, un sous-plan est matérialisé si l'espace de sto-
ckage est susant. Par exemple, si l'espace de stockage est limité à 10000 pages tous les
sous-plans candidats peuvent être matérialisés. Si l'espace de stockage est limité à 25 pages,
seuls les sous-plans P et S peuvent être matérialisés avec la politique de matérialisation des
sous-arbres maximaux.
Conguration Sous-plans candidats Estimations Conguration Sous-plans candidats Estimations
aucun aucun aucun aucun
P P 8 P P 8
PS PS 8000 PS PS 8000
S S 100 S S ./ N ./ R 20
P-S P et S 8 + 100 P-S P et S ./ N ./ R 8 + 20
P-PS P et PS 8 + 8000 P-PS P et PS 8 + 8000
PS-S PS et S 8000 + 100 PS-S PS ./ S ./ N ./ R 1600
tous aucun tous aucun
Tab. 6.2 Politique de matérialisation des Tab. 6.3 Politique de matérialisation des
feuilles - Sous-plans candidats et estima- sous-arbres maximaux - Sous-plans candi-
tion de l'espace de stockage nécessaires pour dats et estimation de l'espace de stockage
toutes les congurations de sources concer- nécessaires pour toutes les congurations de
nant la requête MQ2. sources concernant la requête MQ2.
Nous avons choisi 10 nombres de pages diérents pour le traitement de la requête MQ2 6 :
0, 15, 25, 105, 700, 4000, 8005, 8050, 10000. Ces nombres couvrent tous les cas possibles de
matérialisation. Nous avons eectué cette expérience avec des probabilités de disponibilité
des sources diérentes (60% et de 90%).
Figure 6.22 présente le nombre moyen d'essais nécessaires pour obtenir la réponse com-
plète à la requête MQ2 avec deux systèmes incrémentaux lorsque la disponibilité des sources
est de 60%. Le premier système incrémental implante l'algorithme materialize avec la poli-
tique de matérialisation des sous-arbres maximaux, le second utilise la politique de matéria-
lisation des feuilles. L'axe des abscisses indique le nombre de pages alloué pour le traitement
de la requête et l'axe des ordonnées indique le nombre moyen d'essais nécessaires pour obtenir
la réponse complète.
Le résultat est, comme attendu, une courbe en escalier. Pour les deux politiques de
matérialisation quatre marches sont nettement marquées, ce sont les portions de courbes
consécutives pour lesquelles les intervalles de conance ne se chevauchent pas. A chaque
marche, le système a la possibilité de matérialiser les données provenant de nouvelles sources.
Tout d'abord, aucune donnée ne peut être matérialisée car l'espace de stockage n'est pas
susant. La deuxième grande marche correspond aux espaces de stockage permettant de
stocker d'abord P, puis P ou S. Ensuite, il est possible de stocker les relations temporaires
obtenues lorsque à la fois P et S sont disponibles. La marche suivante correspond à la
possibilité de matérialiser les données obtenues soit de PS soit des sources P et S. Enn,
les données obtenues dans toutes les congurations de sources peuvent être matérialisées.
A chaque marche, le nombre moyen d'essais décroit lorsque l'espace alloué pour le trai-
tement de la requête augmente. Le passage de la première marche a la seconde est le plus
signicatif. Le nombre moyen d'essais passe de 4.5 à 3.2 dès que les résultats obtenus de la
source P peuvent être matérialisés. Par conséquent, un système incrémental prote d'un es-
pace de stockage limité (dès qu'il permet de stocker les sous-requêtes obtenues d'une source)
6. l'exécution ne nécessite pas d'espace de stockage donc pour l'algorithme materialize Nexec = 0
126 Évaluation
5
max
max-error
leaves
leaves-error
Nombre d’essais moyen

4
2
1 10 100 1000 10000 100000
nombre de pages allouees pour le traitement d’une requete
Fig. 6.22 MQ2 - Nombre moyen d'essais nécessaires pour obtenir la réponse complète en
fonction du nombre de pages alloué pour l'espace de stockage - Deux systèmes incrémentaux
implémentant les politiques de matérialisation max et feuilles - La disponibilité des sources
est de 60%.
pour diminuer le nombre de soumissions nécessaires (toujours dans l'hypothèse que les sources
de données ont toutes la même chance d'être disponible).
La longueur de chaque marche dière entre les deux politiques de matérialisation. La
deuxième marche, par exemple, correspond à la situation où les données ne peuvent être
matérialisées que depuis la source P. Selon le tableau 6.2 et le tableau 6.3 cette situation
commence pour les deux politiques lorsque le nombre de pages allouées est de 8 ; elle s'arrête
lorsque le nombre de pages vaut 20 dans la politique max et lorsqu'il vaut 100 dans la politique
feuilles. La deuxième marche est donc plus courte avec la politique max, et par conséquent la
troisième marche démarre avec un nombre de pages plus faible. Ce phénomène est similaire
pour chaque étape. La courbe de la politique max présente une avance de phase sur la courbe
de la politique feuilles. Ceci est dû aux opérations de jointures qui sont eectuées avec la
politique max et qui réduisent la taille des relations temporaires à matérialiser. La politique
max réduit donc le nombre moyen d'essais nécessaires pour obtenir la réponse complète plus
vite que la politique feuilles lorsque l'espace alloué au traitement de la requête augmente.
Figure 6.23 présente le nombre moyen d'essais nécessaires pour obtenir la réponse com-
plète à la requête MQ2 lorsque la disponibilité des sources est de 90%. L'inuence de l'al-
gorithme de matérialisation est peu importante dans cette expérience : les marches ne sont
pas du tout marquées. En eet, lorsque la disponibilité des sources de données est impor-
tante, la réponse complète est très souvent obtenue un seul essai. La probabilité d'obtenir
la réponse complète en un seul essai est la probabilité que toutes les sources de données
soient disponibles simultanément ; c'est donc le produit des disponibilités des sources, dans
notre cas 73% des expériences permettent d'obtenir la réponse complète au premier essai
(0:93 = 0:73). Cette probabilité ne dépend pas de l'algorithme de matérialisation.
2
max
max-error
leaves
leaves-error
Nombre d’essais moyen
1
1 10 100 1000 10000 100000
nombre de pages allouees pour le traitement d’une requete
Fig. 6.23 MQ2 - Nombre moyen d'essais nécessaires pour obtenir la réponse complète en
fonction du nombre de pages alloué pour l'espace de stockage - Deux systèmes incrémentaux
implémentant les politiques de matérialisation max et feuilles - La disponibilité des sources
est de 90%.
6.2.2.3 Discussion
Les résultats obtenus avec le modèle incrémental et le simulateur montrent que le nombre
de soumissions nécessaires pour obtenir la réponse complète est moins important dans un
système incrémental que dans un système classique. Le système incrémental se comporte
d'autant mieux que la disponibilité des sources diminue ou que l'espace de stockage alloué
au traitement de la requête augmente.
Nous avons utilisé un modèle probabiliste de la disponibilité des sources de données dans
les expériences dont les résultats sont présentés ci-dessus. Ce modèle probabiliste suppose
que lors de chaque essai, chaque source de données a une probabilité p d'être disponible. Une
telle représentation des sources indisponibles pose plusieurs problèmes :
quelles sont les limites de ce modèle? Ce modèle est limité car il ne fait pas de diérence
entre les sources de données et qu'il ne prend pas en compte de composante temporelle
(si une panne survient sur une source de données il faut attendre un certain temps que
cette panne soit réparée pour que la source de donnée soit à nouveau disponible
quelle est la disponibilité des sources de données dans une application concrète? Nous
avons fait une expérience pour nous faire une idée de la disponibilité des sources de don-
nées dans l'application Redoc. Les résultats sont présentés en section 6.4. Ils conrment
les résultats présentés dans l'étude de Viles et French [106] : la disponibilité des sources
de données sur le WWW est de l'ordre de 90%.
128 Évaluation
6.3 Optimisation sous contrainte
L'objectif de l'optimiseur sous contrainte est d'augmenter la probabilité de répondre aux
requêtes parachutes tout en conservant des performances raisonnables. Pour étudier ces deux
aspects, nous avons associé deux requêtes parachutes à la requête MQ2. Nous décrivons
ces requêtes parachutes (en section 6.3.1) et nous étudions le plan d'exécution obtenu en
eectuant l'optimisation de MQ2 sous leur contrainte. La politique de matérialisation des
sous-requêtes partagées (SRP) est ensuite comparée aux politiques max et feuilles du point
de vue du temps de traitement et du point de vue de la probabilité qu'ont les requêtes
parachutes d'être satisfaites.
6.3.1 Présentation des requêtes parachutes

Nous associons deux requêtes parachutes à la requête MQ2 (dénie en section 6.1.3) que
nous nommons MQ2-PQ0 et MQ2-PQ1.
La requête MQ2-PQ0 permet d'obtenir les coordonnées de tous les fournisseurs en Europe.
Le code SQL pour cette requête est présenté dans la gure 6.24
SELECT S.ACCTBAL, S.NAME, N.NAME,
S.ADDRESS, S.PHONE, S.COMMENT
FROM SUPPLIER S, NATION N, REGION R
WHERE N.NATIONKEY = S.NATIONKEY AND R.NAME = 'EUROPE'
AND N.NATIONKEY = R.NATIONKEY ;
Fig. 6.24 MQ2-PQ0 en SQL.
La requête MQ2-PQ1 permet d'obtenir l'identiant de tous les fournisseurs de produits

d'un certain type et d'une certaine taille. Le code SQL pour cette requête est présenté dans
la gure 6.25
SELECT P.PARTKEY, P.MFGR, PS.SUPPKEY
FROM PART P, PARTSUPP PS
WHERE PS.PARTKEY = P.PARTKEY AND P.SIZE = 15
AND P.TYPE LIKE 'BRASS';
Fig. 6.25 MQ2-PQ1 en SQL.
Il est à noter que MQ2-PQ1 contient, dans sa liste de projection, un attribut qui n'ap-
paraît pas dans la liste de projection de MQ2.
6.3.2 Résultats de l'optimisation sous contrainte
L'algorithme d'optimisation sous-contrainte ne garantit pas que le plan qui est générée
est le plan optimal pour la requête initiale. En eet, si dans le plan optimal une sous-requête
doit être envoyé vers une source de données et que seulement une partie de cette sous-requête
est partagée entre la requête initiale et les requêtes parachutes, alors aucun des plans générés
par l'algorithme d'optimisation sous contrainte ne poussera la sous-requête entièrement vers
la source de données : la partie qui est partagée avec les requêtes parachutes sera isolée.
Π Π
SRP
submit submit
SRP SRP
submit submit
Π Π
Π submit Π submit
σ σ
PS Π PS Π
P
N
σ P
N
σ
S S
R R
Fig. 6.26 Plan d' exécution pour Fig. 6.27 Plan d'exécution pour
MQ2 contraint
Π
par MQ2-PQ0. MQ2 contraint par MQ2-PQ1.
SRP
submit
SRP
submit
Π
SRP
Π submit
σ
PS Π
P
N
σ
S
R
Fig. 6.28 Plan d'exécution pour

MQ2 contraint par MQ2-PQ0 et
MQ2-PQ1.
Nous détaillons maintenant le plan d'exécution obtenue par l'optimisation de MQ2 sous
la contrainte de MQ2-PQ0. La première étape isole les sous-requête partagées (SRP) entre
MQ2 et MQ2-PQ0. On obtient :
s(Sacct; Sname; Ssk; NK; Sadd; Sphone; Scom) ^
130 Évaluation
n(NK; RK; _) ^ r(RK;0 EUROPE 0)
La première stratégie de matérialisation consiste à considérer la SRP comme un bloc

indivisible dans le plan d'exécution. La deuxième stratégie consiste à considérer chaque
littéraux de la SRP séparément.
Ces deux stratégies permettent d'obtenir le plan optimal pour MQ2 (présenté en sec-
tion 6.1.3.1). En eet, celui-ci contient le plan d'exécution optimal pour la SRP. Le plan
d'exécution obtenu avec la première stratégie est retenu. Il est présenté dans la gure 6.26.
L'optimisation de MQ2 sous la contrainte de MQ2-PQ1 isole dans un premier temps la
SRP suivante :
p(PK; Pkind; 15) ^
like(Pkind; 0 BRASS 0) ^
ps(PK; SK )
La stratégie maximale, qui considère cette SRP comme un bloc indivisible conduit à
introduire la jointure entre les relations P et PS dans le plan d'exécution et donc à un plan
sous-optimal. La stratégie minimale, qui elle considère séparément les littéraux associés à
ces deux relations permet d'obtenir le plan optimal. C'est cette stratégie qui est retenue. Le
plan d'exécution annoté est présenté dans la gure 6.27.
L'optimisation de MQ2 sous la contrainte de MQ2-PQ0 et MQ2-PQ1 isole les deux SRP
présentées précédemment. En eet, les deux requêtes parachutes MQ2-PQ0 et MQ2-PQ1 ne
partagent aucun élément.
La stratégie maximale conduit à un plan d'exécution sous-optimal puisque les relations
P et PS sont considérées comme un bloc indivisible. La stratégie minimale conduit à un
plan optimal puisque les éléments de la requête relatifs à chaque relation sont considérés
séparément. Ce plan d'exécution annoté est présenté dans la gure 6.28.
Intuitivement, le plan idéal annote P et PS séparément et considère S, R et N comme un
bloc indivisible. Ce plan ne peut pas être obtenu avec notre algorithme d'optimisation sous
contrainte. En eet la stratégie de matérialisation qui doit être suivie pour obtenir le plan
idéal est un mélange entre les stratégies minimale et maximale. Considérer deux stratégies
simple ne nous permet pas de couvrir toutes les possibilités, cela nous permet cependant
de considérer un espace de recherche raisonnable et d'obtenir le plan optimal lorsque c'est
possible.
6.3.3 Comparaison des politiques de matérialisation

L'objectif de l'algorithme d'optimisation sous contrainte est d'augmenter les chances de
répondre aux requêtes parachutes tout en conservant un temps de réponse raisonnable.
Nous avons vu que l'optimisation sous contrainte permettait dans la plupart des cas
d'obtenir le plan d'exécution optimal. Nous étudions dans cette section les résultats obtenus
en comparant le temps de traitement et la disponibilité des requêtes parachutes avec les
diérentes politiques de matérialisation, i.e. max où les sous-plans maximaux disponibles
sont matérialisés, feuilles où seules les feuilles du plan d'exécution (coté médiateur) sont
matérialisés et SRP où les sous-requêtes partagées identiées pendant l'optimisation sous
contrainte sont matérialisées séparément et en priorité.
6.3.3.1 Temps de traitement

Nous avons eectué l'expérience des deux essais en exécutant la requête MQ2 avec les trois
politiques de matérialisation max, feuilles et SRP. Nous considérons pour cette expérience
le plan d'exécution résultant de l'optimisation de MQ2 sous la contrainte de MQ2-PQ0.
L'espace de stockage est susant pour stocker les données obtenues de toutes les sources
disponibles.
La gure 6.29 présente les résultats que nous avons obtenu. La courbe de la politique
max correspond à la courbe du système incrémental présentée dans la gure 6.10.
Les courbes des politiques feuilles et SRP sont pratiquement confondues. En fait, ces
deux politiques dièrent seulement par la manière dont la relation S est traitée. Lorsque
cette relation est disponible, elle est matérialisée avec la politique feuilles alors qu'elle est
jointe avec R et N avec la politique SRP (comme avec la politique max). La diérence entre
ces deux opérations ne s'avère pas importante, de l'ordre de la seconde.
680
660
640
620
temps en sec
600 max
feuilles
580 SRP
560
540
520
500
sources disponibles
Fig. 6.29 Comparaison des trois politiques de matérialisation : max, feuilles et SRP pour
le traitement de MQ2.
La politique max est plus ecace que les deux autres politiques dans la conguration où
PS et S sont disponibles (la diérence est de l'ordre de 60 secondes). Cette diérence est due
au fait que dans les politiques feuilles et SRP, la relation PS est matérialisée. Or la taille de
132 Évaluation
cette relation est importante et le temps utilisé pour la matérialiser lors du premier essai et
pour lire les données qu'elle contient lors du deuxième essai est signicatif. Avec la politique
max, dans la conguration où PS et S sont toutes les deux disponibles, ces relations sont
jointes avec les relations locales R et N : le prix de la matérialisation et de la lecture de PS
n'est donc pas à payer.
6.3.3.2 Réponses aux requêtes parachutes

Nous venons de voir que la politique de matérialisation SRP ne pénalise pas le temps de
réponse d'un système incrémental par rapport aux autres politiques de matérialisation max
et feuilles. Il nous reste à montrer que cette politique permet d'augmenter les chances qu'a
le système de fournir une réponse aux requêtes parachutes.
La gure 6.30 représente les chances qu'a le système de répondre à la requête parachute
MQ2-PQ0 en fonction de l'espace de stockage disponible (en abcisse) et en fonction des
congurations de sources disponibles (en ordonnées).
tous
PS-S
P-PS feuilles
Configuration
max
P-S SRP
PS
aucun
0 8 20 28 100 108 1600 8000 8008 8100
Nb pages allouees a la requete
Fig. 6.30 Réponses à la requête parachute MQ2-PQ0 en fonction des congurations de

sources disponibles et en fonction de l'espace de stockage disponible.
La requête parachute MQ2-PQ0 peut être satisfaite dés que la source de données qui
contient la relation S est disponible. Il existe donc 3 congurations où S est disponible.
Les politiques SRP et feuilles permettent de répondre à la requête parachute dans ces 3
congurations ; la politique max, elle, ne permet de répondre à la requête parachute que
dans 2 congurations. En eet, lorsque PS et S sont disponibles, la jointure entre ces deux
relations est eectuée et la requête parachute MQ2-PQ0 ne peut pas être satisfaite avec les
données matérialisées.
D'autre part, avec la politique de matérialisation SRP, la requête parachute MQ2-PQ0
peut être matérialisée dès que l'espace de stockage permet de matérialiser la jointure entre
S, R et N. La SRP est matérialisée en priorité. Ce n'est pas le cas dans les deux autres
politiques. Notre implantation de l'algorithme de matérialisation classe les sous-requêtes
candidates à la matérialisation par un parcours en profondeur d'abord du plan d'exécution.
Lorsque P (ou PS) et S sont disponibles simultanément alors P (ou PS) est matérialisée avant
S. Si l'espace de stockage permet de matérialiser l'une ou l'autre des sous-requêtes mais pas
les deux alors seul P (ou PS) est matérialisé. Ainsi, la politique max permet de répondre
à la requête parachute, dans la conguration P-S, uniquement lorsque l'espace de stockage
dépasse 28 pages (8 pages sont nécessaires pour matérialiser P et 20 pages sont nécessaires
pour matérialiser S ./ R ./ N). De même la politique feuille ne permet pas de répondre à
la requête parachute, dans la conguration PS-S, lorsque l'espace de stockage est compris
entre 8000 et 8100 pages. Dans cet intervalle c'est en eet la relation PS (qui demande 8000
pages) qui est matérialisée seule.
Il est également à noter que l'espace de stockage nécessaire pour répondre à la requête
parachute est plus important avec la politique feuille car la relation S est matérialisée (ce
qui demande 100 pages) alors que dans les autres politiques S ./ R ./ N est matérialisé (ce
qui demande 8 pages).
La gure 6.31 montre les chances qu'a le système de répondre à la requête parachute
MQ2-PQ1. Quelle que soit la politique de matérialisation, le système ne peut répondre à
cette requête que si P et PS sont disponibles simultanément et que l'espace de stockage
permet de matérialiser leurs données. La chance du système de répondre à cette requête
parachute est donc faible, pour les trois politiques de matérialisation.
tous
PS-S
P-PS feuilles
max
Configuration
P-S SRP
PS
aucun
0 8 20 28 100 108 1600 8000 8008 8100
Nb pages allouees a la requete
Fig. 6.31 Réponses à la requête parachute MQ2-PQ1 en fonction des congurations de

sources disponibles et en fonction de l'espace de stockage disponible.
6.3.4 Discussion
Nous avons constaté que l'optimisation sous contrainte génère dans la plupart des cas le
plan d'exécution optimal. Nous avons également constaté que la politique de matérialisation
des sous-requêtes partagées (qu'elle rend possible) ne pénalise pas le temps de traitement et
augmente la chance de répondre aux requêtes parachutes par rapport aux politiques max et
feuilles.
134 Évaluation
La chance de répondre aux requêtes parachutes, même avec la politique de matérialisation
SRP est faible. En eet, seules quelques congurations de sources disponibles permettent au
système de répondre aux requêtes parachutes posées a priori. C'est un désavantage provenant
du fait que la requête parachute a été posée sans utiliser les informations dont dispose le
système sur la disponibilité des sources. C'est surtout un désavantage de l'approche que nous
avons suivie pour l'évaluation des requêtes parachutes. L'utilisation d'un cache sémantique
ou de sources alternatives devrait permettre d'augmenter les chances qu'a le système de
renvoyer des réponses partielles en réponse à une requête parachute.
6.4 Disponibilité des sources dans l'application Redoc

la disponibilité des sources de données est un paramètre important des résultats présentés
dans ce chapitre. Nous avons fait l'expérience suivante pour déterminer la disponibilité des
sources de données dans une application que nous avons développée, i.e. l'application des
catalogues documentaires Redoc.
Le système de médiation installé dans l'application Redoc intègre 30 sources de données
que l'on peut regrouper en quatre grandes familles (chaque famille correspondant à un type
de moteur de recherche booléen diérent). Nous avons réalisé un programme, EXPRedoc, facile
à installer et à mettre en oeuvre, qui contacte en parallèle les trente sources de données, leur
envoie une requête correspondant à une recherche sur un auteur particulier et reçoit une
réponse.
Le programme EXPRedoc enregistre pour chaque source si le transfert de données a pu
s'eectuer correctement, si la connexion a pu être établie ou si la connexion a été rompue.
C'est donc TCP qui signale les sources indisponibles. Notre programme ne permet donc pas
de détecter toutes les conditions d'indisponibilité.
Nous avons installé ce programme sur trois sites: INRIA Rhône Alpes à Grenoble, INRIA
à Rocquencourt et National University à Singapour. Des connexions locales, nationales et
internationales sont donc représentées.
Les résultats que nous présentons ont été obtenus en exécutant le programme EXPRedoc
toutes les heures entre le 19/10/98 et le 26/10/98. L'étude ne porte que sur une semaine et
ne permet pas de tirer des conclusions dénitives sur la disponibilité des sources dans Redoc.
Elle permet cependant d'avoir une image instantanée.
Nous utilisons pour présenter les résultats deux mesures, décrites dans [106] : Wavail et
Savail qui sont dénies comme suit :
Wavail : = nombre de sources disponibles
nombre de sources contactees
Savail (S; t) : = nombre de fois ou S a ete disponible durantt
nombre de fois ou S a ete contactee durant t
où S est une source de données, et t est un intervalle de temps.
Disponibilité des sources dans l application Redoc 135
Qavail Famille 1 Famille 2 Famille 3 Famille 4 Redoc
Singapour 0.76 0.96 0.96 0.99 0.86
Paris 0.81 0.99 1 1 0.89
Grenoble 0.81 0.99 0.99 0.99 0.89
Tab. 6.4 Wavail pour les diérentes familles de sources de données ainsi que le total accédées
depuis Singapour, paris et Grenoble.
La table 6.4 contient les valeurs Wavail pour chaque famille de source ainsi que pour
l'ensemble de sources de Redoc contactées depuis Singapour, Paris et Grenoble.
La disponibilité des sources de Redoc est de 86% lorsqu'elles sont contactées depuis Singa-
pour, de 89% lorsqu'elles sont contactées depuis Paris et de 89% lorsqu'elles sont contactées
depuis Grenoble. La disponibilité est donc légèrement plus faible dans le cas où la connexion
réseau est internationale.
Il apparaît que les disponibilités de chaque famille de sources sont assez disparates. La
famille 1 est beaucoup moins disponibles que les trois autres. La disponibilité des familles 2,
3 et 4 est proche de 100%.
Les gures 6.32, 6.33 et 6.34 concernent Singapour, Paris et Grenoble respectivement.
Ces graphes représentent les valeurs de Savail en fonction des intervalles de temps t. Nous
avons partitionné la semaine en demi-journées : de 6h à 18h (au jour J), et de 18h à 6h (entre
les jours J et J+1).
Ces graphes mettent en évidence un problème survenu sur les sources de la famille 1 lors
des demi-journées 10 à 13. Aucun des trois sites n'a pu accéder aux sources de la famille 1 lors
des demi-journées 11 et 12. Les sources de la famille 1 sont toutes accédées par l'intermédiaire
d'une passerelle qui est, selon toute vraisemblance, restée hors service plus d'une journée.
Le graphe 6.32 montre une baisse de la disponibilité pour toutes les familles de sources
lors de la demi-journée 4 accédées depuis Singapour. Cela traduit un problème de congestion
sur le réseau depuis Singapour, puisque ce problème n'apparait pas sur les graphes de Paris
et de Grenoble.
Le problème survenu pour les sources de la famille 1 inuence beaucoup les résultats
que nous avons obtenu. Un problème est de savoir si de tels problèmes sont fréquents. Des
mesures eectuées sur une période plus longue permettront d'aner nos résultats.
Il est à noter que tous les cas de sources indisponibles sont dus à des connexions qui ne
peuvent pas être établies.
136 Évaluation
1 1
0.9 0.9
0.8 0.8
Savail 0.7 0.7
Savail
0.6 0.6
0.5 0.5
0.4 0.4
0.3 famille 1 0.3 famille 1
famille 2 famille 2
0.2 famille 3 0.2 famille 3
famille 4 famille 4
0.1 0.1
0 0
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
demi-journees demi-journees
Fig. 6.32 Disponilité des sources par demi- Fig. 6.33 Disponilité des sources par demi-
journées depuis Singapour. journées depuis Paris.
1
0.9
0.8
0.7
Savail
0.6
0.5
0.4
0.3 famille 1
famille 2
0.2 famille 3
famille 4
0.1
0
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
demi-journees
Fig. 6.34 Disponilité des sources par demi-

journées depuis Grenoble.
6.5 Conclusion
L'objectif de notre évaluation des performances était de montrer que (1) le traitement
incrémental des requêtes permet d'améliorer le temps de réponse en présence de sources
indisponibles par rapport à un système classique, et que (2) l'optimisation sous contrainte
permet d'augmenter les chances qu'a le système de répondre aux requêtes parachutes sans
pénaliser le temps de réponse.
Pour réaliser l'évaluation de performance, nous avons utilisé un modèle analytique et
un simulateur. Le modèle analytique nous a permis d'étudier le nombre de soumissions
nécessaires pour obtenir la réponse complète dans un système classique, et dans un système
incrémental, lorsque l'espace de stockage est illimité. Le simulateur nous a permis d'étudier
l'inuence des politiques de matérialisation et de l'espace de stockage limité sur le temps de
Conclusion 137
réponse et le nombre de soumissions.
Nous avons utilisé, pour mener nos expériences, deux requêtes conjonctives dérivées du
benchmark TPC-D. Il serait nécessaire de dénir une nouvelle requête pour étudier le compor-
tement d'un système incrémental lorsqu'il par rapport aux unions de requêtes conjonctives.
Les expériences que nous avons menées ne couvre pas tous les aspects des performances.
Nous n'avons par exemple pas étudié le lien entre stockage limité et temps de traitement. De
même, les requêtes que nous avons utilisées ne couvrent pas tous les cas de gures possibles
dans les expériences. Nous avons cependant mis en évidence les points importants concernant
les performances d'un système incrémental et d'un optimiseur sous contrainte.
Les expériences que nous avons présentées nous ont permis de formuler les observations
suivantes concernant le traitement incrémental des requêtes :
le traitement incrémental des requêtes ne pénalise pas le temps de réponse par rapport
à un système classique lorsque toutes les sources sont disponibles simultanément lors
du premier essai ;
la pénalité, en terme de temps de réponse, inhérente aux systèmes incrémentaux (les
relations temporaires doivent être créées et ensuite lues localement) est moins impor-
tante que la pénalité inhérente aux systèmes classiques (les mêmes opérations sont
eectuées plusieurs fois) ;
un système incrémental permet de diminuer le nombre de soumissions nécessaires pour
obtenir la réponse complète. L'apport du système incrémental est d'autant plus im-
portant que le nombre de sources impliqué dans la requête est important et que les
sources sont peu disponibles ;
le temps mis par le système incrémental pour fournir une notication à l'application
est parfois supérieur au temps nécessaire pour construire la réponse complète si toutes
les sources sont disponibles.
Les expériences concernant l'optimisation sous contrainte nous ont permis de faire les
observations suivantes :
l'optimisation sous contrainte génère le plan d'exécution optimal dans la plupart des
cas ;
la politique de matérialisation des SRP ne pénalise pas le temps de traitement des
requêtes par rapport aux politiques max ou feuilles ;
la politique SRP permet d'augmenter les chances qu'a le système de répondre aux
requêtes parachutes par rapport aux deux autres politiques de matérialisation ;
de manière générale le système a peu de chance de répondre aux requêtes parachutes
en utilisant les données disponibles lors des traitements précédents.
138 Évaluation
Il sera intéressant de voir dans quelle mesure les sources alternatives ou les caches sé-
mantiques permettent de fournir plus d'information partielle que les données matérialisées à
partir des sources disponibles.
Finalement, nous avons eectué une expérience pour nous rendre compte de la disponibi-
lité des sources de données dans une application telle que Redoc. Nos résultats préliminaires
montrent que la disponibilité des sources est importante (supérieure à 90%). Il sera inté-
ressant de continuer les mesures dans le cadre de l'application Redoc et d'eectuer une
expérience similaire dans le cadre de l'application du complexe hospitalier.
139
Chapitre 7
Conclusion
7.1 Contributions
L'indisponibilité des sources de données est une éventualité à laquelle les systèmes de
médiation doivent faire face. En eet, rien ne garantit à un système de médiation que les
sources qu'il doit contacter pour construire une réponse sont disponibles : des pannes, des
congestions ou des changements peuvent survenir aussi bien sur les sites autonomes qui
abritent les sources de données que sur le réseau.
L'objectif de notre travail est d'améliorer le fonctionnement des systèmes de médiation
en présence de sources de données indisponibles.
Dans cette optique , nous avons identié deux axes de travail :
le traitement incrémental des requêtes pour que le système construise ecacement la

réponse complète à une requête ;
l'extraction d'informations partielles pour que le système permette à l'application d'ob-
tenir des informations pertinentes avant que la réponse complète puisse être construite.
Nous avons déni l'approche incrémentale du traitement des requêtes. Lorsqu'une requête
ne peut pas être complètement évaluée, elle est partiellement évaluée, les résultats intermé-
diaires sont matérialisés, la requête initiale est réécrite en utilisant ces vues temporaires en
une requête incrémentale qui permet d'obtenir la réponse complète ecacement.
Nous avons proposé une architecture et des algorithmes qui permettent d'intégrer le
traitement incrémental des requêtes dans les systèmes de médiation existants. Nous avons
comparé un système de médiation mettant en ÷uvre le traitement incrémental des requêtes
à un système classique en utilisant un modèle analytique et un simulateur. Les résultats
que nous avons obtenu montrent (i) que le traitement incrémental des requêtes permet de
réduire le nombre de soumissions nécessaires pour obtenir la réponse complète et (ii) que
140 Conclusion
le traitement incrémental permet de réduire le temps de traitement en évitant la répétition
d'opérations coûteuses.
Nous avons déni un cadre général pour l'extraction d'informations partielles dans les
systèmes de médiation. Nous avons favorisé une approche explicite, où l'application formule
des requêtes parachutes pour obtenir des informations partielles. Dans notre étude, les in-
formations partielles sont obtenues des états intermédiaires du traitement incrémental de la
requête. Nous avons déni un algorithme qui utilise les informations fournies par le système
et par l'utilisateur pour générer des requêtes parachutes.
Dans le scénario où l'application dénit les requêtes parachutes sans tenir compte des
indications du système (et peut donc soumettre en même temps la requête initiale et les
requêtes parachutes qui lui sont associées), nous avons décrit un algorithme pour améliorer la
capacité du système à répondre aux requêtes parachutes tout en conservant des performances
raisonnables. Cet algorithme d'optimisation isole les sous-requêtes partagées entre la requête
initiale et les requêtes parachutes. Nous avons déni une politique de matérialisation qui
permet de prendre en compte ces informations et de matérialiser en priorité les sous-requêtes
partagées (qui pourront être utilisées pour répondre aux requêtes parachutes). Nous avons
montré que l'algorithme d'optimisation fournit un plan optimal dans la plupart des cas ; nous
avons également montré, par simulation, que la politique de matérialisation des sous-requêtes
partagées permet d'améliorer les capacités du système à répondre aux requêtes parachutes.
7.2 Perspectives
Nous avons implanté le traitement incrémental des requêtes dans la première version de
Disco [100]. Nous avons ainsi démontré la faisabilité de notre approche. Il sera important
de la valider en étudiant comment implanter le traitement incrémental des requêtes dans
d'autres systèmes de médiation. Nous pourrons ainsi vérier dans quelle mesure les systèmes
existants peuvent adapter leur fonctionnement en présence de sources de données indispo-
nibles et quel est l'impact précis de l'architecture et des algorithmes que nous proposons sur
les systèmes existants.
Une nouvelle étape sera de mettre en ÷uvre un système de médiation incrémental dans des
applications telles que l'application du complexe hospitalier ou Redoc. Cela nous permettra :
d'étudier les problèmes de construction d'application au dessus d'un système incré-

mental : dans quelle mesure une application peut facilement utiliser les requêtes in-
crémentales ou générer des requêtes parachutes? Est ce que la validité des données
matérialisées pose problème?
d'étudier les problèmes d'administration du système incrémental : quels sont les ré-
glages à eectuer pour la détection des sources indisponibles, pour la gestion de l'espace
de stockage?
Perspectives 141
de valider notre modèle expérimental en vériant l'apport concret du traitement incré-
mental des requêtes et de l'optimisation sous contrainte au niveau des performances.
Nous avons déjà identié un certain nombre d'extensions possibles aux algorithmes et
aux mécanismes que nous avons proposé. Ces extensions concernent :
la prise en compte des agrégats, des requêtes imbriquées et de manière générale de
toutes les extensions aux unions de requêtes conjonctives ;
la prise en compte des sources alternatives, et plus généralement des informations
sémantiques contenues dans le système, pour la génération de requêtes parachutes ;
un mécanisme qui permette de notier à l'application la disponibilité des sources pour
optimiser le temps d'attente des applications (et des utilisateurs) entre les soumissions
successives.
Nous avons dans notre travail considéré que chaque requête est traitée indépendamment.
Il est naturel de considérer dans une prochaine étape les liens qui peuvent exister entre dié-
rentes requêtes, i.e. dans quelle mesure les données matérialisées pour une requête ne peuvent
pas être réutilisées par une autre requête. Ce problème est celui du rapprochement des tech-
niques que nous avons proposé avec les techniques de cache sémantique. Ces techniques sont
complémentaires : nos propositions concernent notamment la détection des sources indispo-
nibles et le choix des sous-requêtes à matérialiser dans un espace de stockage limité, les
techniques de cache sémantique concernent la réutilisation des données matérialisées et les
politiques de remplacement. Le rapprochement des deux techniques laisse cependant ouvert
le problème de la validité des données matérialisées.
L'extraction d'information partielle soulève un problème d'interface utilisateur. Le pro-
blème est pour l'application de communiquer à l'utilisateur la signication exacte des données
qu'elle lui fournit. De manière générale, un système de médiation doit permettre à ses uti-
lisateurs de suivre le travail qui est en cours (l'extraction d'information partielle étant une
étape dans le traitement de la requête initiale). Une piste intéressante est suivie dans le cadre
du projet CONTROL [6] à l'Université de Berkeley où sont développés des composants IHM
spéciques aux bases de données. Tous ces composants ont pour objectif de fournir à l'uti-
lisateur plus de contrôle sur l'évaluation des requêtes (un composant permet par exemple
de contrôler la précision des estimations pour des valeurs d'agrégats). Il serait par exemple
intéressant de développer des composants graphiques qui permettent à une application d'in-
diquer précisément la relation entre la requête initiale et une requête parachute. Il reste
beaucoup de travail à faire dans cette direction.
La prise en compte des sources indisponibles est un aspect d'un problème plus large
qui concerne l'adaptation des systèmes de médiation à des sources de données qui évoluent
et à des conditions changeantes sur le réseau. Ce travail, ainsi que les travaux sur Query
scrambling [4, 3] ou sur les modèles de coût [1] sont des premiers éléments qui devront être
développés et combinés pour améliorer les performances des systèmes de médiation.
142 Conclusion
Bibliographie 143
Bibliographie
[1] S. Adali, K. S. Candan, Y. Papakonstantinou, and V. S. Subrahmanian. Query caching
and optimization in distributed mediator systems. In ACM SIGMOD International
Conference on Management of Data, pages 137148, Montreal, Canada, 1996.
[2] R. Amouroux, Ph. Bonnet, M. Lopez, and D. Smith. The design and construction of
adapters for information mediation. Brevet en preparation, 1997.
[3] L. Amsaleg, Ph. Bonnet, M. J. Franklin, A. Tomasic, and T. Urhan. Improving res-
ponsiveness for wide-area data access. Bulletin of the Technical Committee on Data
Engineering, 20(3):311, 1997.
[4] L. Amsaleg, M. J. Franklin, A. Tomasic, and T. Urhan. Scrambling query plans to
cope with unexpected delays. In International Conference on Parallel and Distribution
Information Systems (PDIS), Miami Beach, Florida, 1996.
[5] C.A. Arens, Y. Knoblock. Retrieving and integrating data from multiple information
sources. In Proceedings of the ACM SIGMOD International Conference on Manage-
ment of Data, 1993.
[6] Control Group at Berkeley. CONTROL home page. http://control.cs.berkeley.edu/.
[7] Garlic Group at IBM Almaden. Garlic project home page.
http://www.almaden.ibm.com/cs/garlic/homepage.html.
[8] COIN Group at MIT Sloan School of Management. MINT home page.
http://context.mit.edu/ coin/demos/.
[9] Hermes Group at University of Maryland College park. Hermes project home page.
http://www.cs.umd.edu/projects/hermes/index.html.
[10] Ph. Bonnet and S. Bressan. Extraction and integration of data from semi-structured
documents into business applications. In Industrial Applications of Prolog (INAP),
Kobe, Japan, 1997.
[11] Ph. Bonnet and A. Tomasic. Partial answers for unavailable data sources. Technical
Report RR-3127, INRIA, 1997.
[12] Ph. Bonnet and A. Tomasic. Parachute queries in the presence of unavailable data
sources. In 14ème Journées Bases de Données Avancées, Hammamet, Tunisie, 1998.
144 Bibliographie
[13] Ph. Bonnet and A. Tomasic. Parachute queries in the presence of unavailable data
sources. Technical Report RR-3429, INRIA, 1998.
[14] Ph. Bonnet and A. Tomasic. Partial answers for unavailable data sources. In Pro-
ceedings of the Conference on Flexible Query Answering Systems, Roskilde, Denmark,
1998.
[15] Ph. Bonnet and A. Tomasic. Unavailable data sources in mediator based applications.
In First International Workshop on Practical Information Mediation and Brokering,
and the Commerce of Information on the Internet (I'MEDIAT'98, Tokyo, Japan, 1998.
[16] L. Bouganim, O. Kapitskaia, and P. Valduriez. Memory-adaptive scheduling for large
query execution. In International Conference on Information and Knowledge Mana-
gement (CIKM), Washington, DC, USA, 1998.
[17] S. Bressan and Ph. Bonnet. Answering queries using views and integrity constraints.
In preparation.
[18] S. Bressan, C.H. Goh, et al. The COntext INterchange mediator prototype. In Procee-
dings of the ACM SIGMOD International Conference on Management of Data, Tucson,
Arizona, 1997.
[19] S. Bressan, T. Lee, S. Madnick, and M. Siegel. A procedure for context mediation
of queries to disparate sources. In International Logic Programming Symposium, New
York, NY, USA, 1997.
[20] S. Bressan and Lee. T. Information brokering on the world wide web. In WebNet world
Conference, 1997.
[21] Information Builders. Description of EDA/SQL.
http://www.ibi.com/products/index.html.
[22] P. Buneman, S. Davidson, and A. Watters. Querying independant databases. Infor-
mation Sciences, nov 1989.
[23] P. Buneman, S. Davidson, and A. Watters. A semantics for complex objects and
approximate answers. Journal of Computer and System Sciences, 43, 1991.
[24] P. Buneman, L. Raschid, and J.D. Ullman. Mediator langauges - a proposal for a
standard. ftp://ftp.umiacs.umd.edu/pub/ONRrept/medmodel96.ps.
[25] M.J. Carey, L. M. Haas, P. M. Schwarz, M. Arya, W. F. Cody, R. Fagin, M. Flickner,
A. Luniewski, W. Niblack, D. Petkovic, J. Thomas, J. H. Williams, and E. L. Wim-
mers. Towards heterogeneous multimedia information systems: The garlic approach.
In RIDE-DOM '95, Fifth Int. Workshop on Research Issues in Data Engineering -
Distributed Object Management, pages 124131, Taipei, Taiwan, 1995.
[26] M.J. Carey, L.M. Haas, J. Kleewein, and B. Reinwald. Data access interoperability in
the ibm database family. Bulletin of the Technical Committee on Data Engineering,
21(3), September 1998.
Bibliographie 145
[27] R. G. G. Cattell. The Object Database Standard: ODMG-93 Release 1.2. Morgan-
Kaufmann, San Mateo, CA, December 1995.
[28] S. Ceri, G. Gottlob, and L. Tanca. Logic Programming and Databases. Springer-Verlag,
1990.
[29] U.S. Chakravarthy, J. Grant, and J. Minker. Logic-based approach to semantic query
optimization. TODS, 15(2), 1990.
[30] C.M. Chen and N. Roussopoulos. The implementation and performance evaluation
of the ADMS query optimizer: Integrating query result caching and matching. In
Proceedings of the 4th International Conference on Extending Database Technology,
1994.
[31] W. Chu, H. Yang, K. Chian, M. Minock, G.. Chow, and C. Larson. Cobase: A scalable
and extensible cooperative information system. Journal of Intelligent Information
Systems, 6(1), 1996.
[32] Transaction Processing Performance Council. Tpc-d benchmark specication.
http://www.tpc.org/dspec.html.
[33] S. Dar, M.J. Franklin, B.T. Jònsson, D. Srivastava, and M. Tan. Semantic data caching
and replacement. In Proceedings of the 22nd International Conference on Very Large
Databases, Bombay, India, 1996.
[34] U. Dayal and H.Y. Hwang. View denition and generalization for database integration
in a multidatabase system. IEEE Transactions on Software Engineering, 10(6):628
645, 1983.
[35] F. de Ferreira Rezende and K. Hergula. The heterogeneity problem and middleware
technology: Experiences with and perfromance of database gateway. In Proceedings of
the 24th International Conference on Very Large Data Bases, New York, NY, USA,
1998.
[36] I. Dorronsoro, I. Portillo, J.M. Munoz, and I. Mokoroa. Hospital application require-
ments denition (d7a.1). MIRO-WEB EP 25208 Deliverable, 1998.
[37] W. Du and M-C. Shan. Query Processing in Pegasus, pages 449468. Prentice Hall,
1995.
[38] C. Dyreson. Information retrieval from an incomplete data cube. In Proceedings of the
22nd International Conference on Very Large Databases, Bombay, India, 1996.
[39] Epistemics. Infomaster. http://www.epistemics.com/infomaster.html.
[40] P. Fankhauser, G. Gardarin, M. Lopez, J. Munoz, and A. Tomasic. Experiences in
federated databases: From iro-db to miro-web. In Proceedings of the 24th International
Conference on Very Large Data Bases (Industrial Sessions), New York, NY, USA, 1998.
146 Bibliographie
[41] M.F. Fernandez, D. Florescu, J. Kang, A.Y. Levy, and D. Suciu. Catching the boat
with strudel: Experiences with a web-site management system. In Proceedings of the
ACM SIGMOD International Conference on Management of Data, Seattle, Washing-
ton, USA, 1998.
[42] M.F. Fernandez, D. Florescu, A.Y. Levy, and D. Suciu. Warehousing and incremental
evaluation for web site management. In 14ème journées Bases de Données Avancées,
Hammamet, Tunisie, 1998.
[43] B. Finance, V. Smahi, and J. Fessy. Query processing in iro-db. In Proceedings
of the Fourth International Conference on Deductive and Object-Oriented Databases
(DOOD95), Singapore, 1995.
[44] M.J. Franklin, B.T. Jònsson, and D. Kossmann. Performance tradeos for client-server
query processing. In Proceedings of the ACM SIGMOD International Conference on
Management of Data, Montréal, Canada, 1996.
[45] T. Gaasterland, P. Godfrey, and J. Minker. An overview of cooperative answering.
Journal of Intelligent Information Systems, 1(2):123157, 1992.
[46] H. Garcia-Molina, J. Hammer, K. Ireland, Y. Papakonstantinou, J.D. Ullman, and
J. Widom. The TSIMMIS project - integration of heterogeneous information sources.
In Proc. of the 100th Anniversary Meeting of Information Processing Society of Japan,
pages 718, Tokyo, Japan, 1994.
[47] G. Gardarin, S. Gannouni, B. Finance, P. Fankhauser, W. Klas, D. Pastre, and R. Le-
go. Iro-db : Making relational and object-oriented database systems interoperable. In
Object-Oriented Multidatabase Systems: A Solution for Advanced Applications, pages
449468. Prentice Hall, 1995.
[48] P. Godfrey and J. Gryz. Answering queries by semantic caches.
http://www.cs.umd.edu/ godfrey, 1998.
[49] J. Gray, P. Helland, P. O'Neil, and D. Shasha. The dangers of replication and a solu-
tion. In ACM SIGMOD International Conference on Management of Data, Montreal,
Canada, 1996.
[50] J. Gray and A. Reuter. Transaction Processing: concepts and techniques. Morgan-
Kaufmann, San Mateo, CA, 1994.
[51] SIMS group at ISI. SIMS project home page. http://www.isi.edu/sims/sims-
homepage.html.
[52] H. Gupta. Selection of views to materialize in a data warehouse. In Proceedings of the
International Conference on Database Theory ICDT'97, Athens, Greece, 1997.
[53] L.M. Haas, D. Kossmann, E.L. Wimmers, and J. Yang. Optimizing queries across
diverse data sources. In VLDB'97, Proc. of 23rd Int. Conf. on Very Large Data Bases,
Athens, Greece, 1997.
Bibliographie 147
[54] J. Hammer, H. Garcia-Molina, J. Widom, W. Labio, and Y. Zhuge. The stanford
data warehousing project. Bulletin of the Technical Committee on Data Engineering,
18(2):4148, 1995.
[55] J. M. Hellerstein, P. J. Haas, and H.J. Wang. Online aggregations. In Proceedings of the
ACM SIGMOD International Conference on Management of Data, Tucson, Arizona,
USA, 1997.
[56] IBM. DB2 DataJoiner case studies. http://www.software.ibm.com/data/datajoiner/casestudy.html.
[57] Data Integration Inc. An introduction to InterViso. http://www.cerfnet.com/ mar-
gie/dii/index.html.
[58] W. Inmon. Building the data bridge - the ten critical success factors of building a data
warehouse. Database Programming & Design, April 1992.
[59] R. Jain. The Art of Computer Systems Performance Analysis. Wiley professional
Computing, 1991.
[60] Junglee. Junglee technology. http://www.junglee.com/tech/index.html.
[61] P. Kanellakis. Elements of relational database theory. In J. van Leeuwen, editor,
Handbook of Theoretical Computer Science, chapter 17. Elsevier Science Publishers
B.V., 1990.
[62] O. Kapitskaia, A. Tomasic, and P. Valduriez. Dealing with discrepencies in wrapper
functionality. In 13ème Journées Bases de Données Avancées, Grenoble, France, 1997.
[63] A. Keller and J. Basu. A predicate-based caching scheme for client-server database
architectures. In Proceedings of the International Conference on parallel and distributed
Information Systems, 1994.
[64] W. Kim. Modern database systems : the object model, interoperability, and beyond.
Addison-Wesley, 1994.
[65] W. Kim, I. Choi, S. Gala, and M. Scheevel. On resolving schematic heterogeneity in
multidatabase systems. In Modern database systems : the object model, interoperability,
and beyond, pages 649663. Addison-Wesley, 1994.
[66] T. Kirk, A. Y. Levy, Y. Sagiv, and D. Srivastava. The information manifold. In AAAI
Spring Symposium on Information Gathering in Distributed Heterogeneous Environ-
ments, Stanford, California, USA, 1995.
[67] W.J. Labio, D. Quass, and B. Adelberg. Physical database design for data warehouses.
In Proceedings of the International Conference on Data Engineering ICDE'97, Orlando,
Florida, 1997.
[68] T. Landers and R.L. Rosenberg. An overview of Multibase. In Distributed Databases,
pages 1533184. North Holland, 1982.
148 Bibliographie
[69] R.M. Lee. Conversational aspects of database interactions. In Proceedings of the Fourth
International Conference on Very Lage Data Bases, West Berlin, Germany, 1978.
[70] T.Y. Lee and S. Bressan. Multimodal integration of disparate information sources with
attribution. In Entity Relationship Workshop on Information Retrieval and Conceptual
Modeling, 1997.
[71] A. Y. Levy, A. Rajaraman, and J. J. Ordille. Querying heterogeneous information
sources using source descriptions. In Proceedings of the 22nd International Conference
on Very Large Databases, Bombay, India, 1996.
[72] A.Y. Levy, A. Mendelzon, Y. Sagiv, and D. Srivastava. Answering queries using views.
In Proceedings of the 14th ACM SIGACT-SIGMOD-SIGART Symposium on Principles
of Database Systems, PODS-95, San Jose, California, USA, 1995.
[73] C. Li, R. Yerneri, J.D. Ullman, and H. Garcia-Molina. Optimizing large join queries
in mediation systems. In Proceedings of the International Conference on Database
Theory, 1999.
[74] C. Li, R. Yerneri, V. Vassalos, H. Garcia-Molina, Y. Papakonstantinou, J.D. Ullman,
and M. Valiveti. Capability based mediation in tsimmis. In Proceedings of the ACM
SIGMOD International Conference on Management of Data, New York, NY, USA.,
1998.
[75] L. Libkin. Approximation in databases. In Proceedings of the International Conference
on Database Theory, 1995.
[76] M. Lopez, J. López, J.M. Muñoz, H. Laude, and G. Gardarin. Product denition
(d2.1.1). MIRO-WEB EP 25208 Deliverable, 1998.
[77] J.J. Lu, G. Moerkotte, J. Schü, and V.S. Subrahmanian. Ecient maintenance of mate-
rialized mediated views. In Proceedings of the ACM SIGMOD International Conference
on Management of Data, San Jose, California, USA, 1995.
[78] A. Motro. Cooperative database systems. In Proceedings of the 1994 Workshop on
Flexible Query-Answering Systems (FQAS '94), pages 116, 1994.
[79] A. Motro. Multiplex: A formal model for multidatabases and its implementation.
Technical Report ISSE-TR-95-103, George Mason University, 1995.
[80] H. Naacke, A. Tomasic, and G. Gardarin. Leveraging mediator cost model with hete-
rogeneous data sources. In Proceedings of the 11th International Conference on Data
Engineering, Orlando, Florida, USA, 1998.
[81] Intelligent Integration of Information (I3). Reference architecture.
http://mole.dc.isx.com/I3/html/briefs/I3brief.html#ref.
[82] Oracle. Oracle open gateways. http://www.oracle.com/products/gateways/.
Bibliographie 149
[83] Y. Papakonstantinou, A. Gupta, H. Garcia-Molina, and J.D. Ullman. A query transla-
tion scheme for rapid implementation of wrappers. In Proceedings of the International
Conference on Deductive and Object Oriented Databases, Singapore, 1995.
[84] X. Qian. Query folding. In Proceedings of the 12th International Conference on Data
Engineering, 1996.
[85] A. Ramfos, J. Fessy, B. Finance, and V. Smahi. Iro-db : A solution for computer inte-
grated manufacturing applications. In Proceedings of the 3rd International Conference
on Cooperative Information Systems (CoopIS95), Vienna, Austria, 1995.
[86] M.T. Roth and P. Schwarz. Don't scrap it, wrap it! a wrapper architecture for le-
gacy data sources. In Proceedings of the 23rd International Conference on Very Large
Databases, Athens, Greece, 1997.
[87] T. Sellis. Multiple-query optimization. ACM Transactions on Database Systems,
13(1):2352, March 1988.
[88] M-C. Shan, R. Ahmen, J. Davis, W. Du, and W. Kent. Modern Database Systems:
The Object Model, Interoperability, and Beyond, chapter Pegasus: A Heterogeneous
Information Management System, pages 664682. ACM Press, 1995.
[89] A.P. Sheth and J.A. Larson. Federated database systems for managing distributed, he-
terogeneous, and autonomous databases. ACM Computing Surveys, 22(3), September
1990.
[90] J.M. Smith, P. Bernstein, U. Dayal, N. Goodman, T. Landers, K.W.T. Lin, and
E. Wong. MULTIBASE - integrating heterogeneous distributed database systems.
In Proc. AFIPS NCC, pages 487499, 1981.
[91] D. Srivastava, S. Dar, Jagadish H.V., and A.Y. Levy. Answering queries with aggrega-
tion using views. In Proceedings of the 22nd International Conference on Very Large
Databases, Bombay, India, 1996.
[92] D. Stacey. Replication: Db2, oracle, or sybase. Sigmod Record, 21(4), December 1995.
[93] R. Stout. Eda/sql. In Modern database systems : the object model interoperability, and
beyond, pages 649663. Addison-Wesley, 1994.
[94] D. Suciu. Workshop on management of semistructured data.
http://www.research.att.com/ suciu/workshop-papers.html, 1997.
[95] The COIN team. Démonstration coin. http://context.mit.edu/ coin/demos/.
[96] The Tsimmis team. Démonstration tsimmis. http://www-
db.stanford.edu/tsimmis/tsimmis.html.
[97] M. Templeton, H. Henley, E. Maros, and D. Van Buer. InterViso : Dealing with the
complexity of federated database access. VLDB Journal, 4(2), 1995.
150 Bibliographie
[98] G. Thomas, G.R. Thompson, C.W. Chung, E. Barkmeyer, F. Carter, M. Templeton,
S. Fox, and B. Hartman. Heterogeneous distributed database systems for production
use. In Modern database systems : the object model, interoperability, and beyond, pages
237266. Addison-Wesley, 1994.
[99] J.C. Thomas. Psychological issues in data base management. In Proceedings of the
Third International Conference on Very Lage Data Bases, Tokyo, Japan, 1977.
[100] A. Tomasic, R. Amouroux, Ph. Bonnet, O. Kapitskaia, H. Naacke, and L. Raschid.
The distributed information search component (disco) and the world-wide web. In
Proceedings of the ACM SIGMOD International Conference on Management of Data,
Tucson, Arizona, USA, 1997.
[101] A. Tomasic, L. Raschid, and P. Valduriez. Scaling heterogeneous database and the
design of Disco. In Proceedings of the 16th International Conference on Distributed
Computing Systems (ICDCS-16), pages 449457, Hong Kong, May 1996. IEEE Com-
puter Society Press.
[102] J. D. Ullman. Principals of Database and Knowledge-Base Systems, volume 2. Com-
puter Science Press, 1989.
[103] J.D. Ullman. Information integration using logical views. In Proceedings of the Inter-
national Conference on Database Theory, 1997.
[104] T. Urhan, M. J. Franklin, and L. Amsaleg. Cost based query scrambling. In Procee-
dings of the ACM SIGMOD International Conference on Management of Data, Seattle,
Washington, USA, 1998.
[105] S. Venkataram and T. Zhang. Heterogeneous database query optimization in db2
universal datajoiner. In Proceedings of the 24th International Conference on Very
Large Data Bases (Industrial Sessions), New York, NY, USA, 1998.
[106] C.L. Viles and J.C. French. Availability and latency of world wide web information
servers. The USENIX Association, Computing Systems, 8(1), 1995.
[107] S. V. Vrbsky and J. W. S. Liu. APPROXIMATE: A query processor that produces
monotonically improving approximate answers. Transactions on Knowledge and Data
Engineering, 5(6):10561068, December 1993.
[108] G. Wiederhold. I3 glossary. http://www-db.stanford.edu/pub/gio/1996/glossat.ps.
[109] G. Wiederhold. Mediators in the architecture of future information systems. IEEE
Computer, March 1992.
[110] G. Wiederhold. Intelligent integration of information. In Proceedings of the 1993
ACM SIGMOD International Conference on Management of Data, pages 434437,
Washington, D.C., USA, 1993.
[111] G.R. Wright and W.R. Stevens. TCP/IP Illustrated: The Implementation, volume 2.
Addison-Wesley, 1995.
Bibliographie 151
[112] Y. Zhuge, H. Garcia-Molina, J. Hammer, and J. Widom. View maintenance in a ware-
housing environment. In Proceedings of the ACM SIGMOD International Conference
on Management of Data, San Jose, California, USA, 1995.
[113] Y. Zhuge, H. Garcia-Molina, and J.L. Wiener. Consistency algorithms for multi-source
warehouse view maintenance. Distributed and Parallel Databases, 6(1):740, 1998.
152 Bibliographie
153
Annexe A
Glossaire
conguration de sources Un ensemble de sources disponibles et indisponibles.
construct L'algorithme de construction de la requête incrémentale à partir de l'état du
médiateur.
containment mapping Un ensemble de littéraux L est contenu dans une requête conjonc-
tive Q, noté L Q si et seulement si il existe une fonction des variables de L vers
les variables de Q, appelée containment mapping, telle que tous les littéraux de L
correspondent à un littéral dans le corps de Q.
disponible une source est disponible si elle renvoie complètement la réponse à la sous-
requête qui lui est envoyée.
données semi-structurées les données semi-structurées sont des données sans schéma xé
ou uniforme [103].
évaluation classique Un modèle d'évaluation où la requête initiale est soumise jusqu'à ce
qu'elle soit évaluée.
évaluation incrémentale Un modèle d'évaluation oú une requête incrémentale est géné-
rée lorsqu'une ou plusieurs sources de données sont indisponibles et oú les requêtes
parachutes permettent d'extraire de l'information de l'état du médiateur.
évaluation sous contraintes Un modèle d'évaluation oú une requête et ses requêtes pa-
rachutes sont soumises simultanément au médiateur.
feuilles Les feuilles du plan d'exécution par rapport au médiateur (les sous-requêtes en-
voyées aux sources de données sont des feuilles d'après notre dénition).
materialize L'algorithme de matérialisation des sous-requêtes disponibles en fonction d'une
politique de matérialisation et d'un espace de stockage limité.
médiateur Le système de traitement des requêtes intégrant diérentes sources de données.
154 Glossaire
politique de matérialisation Le principe qui dénit quelles sous-requêtes sont candidates
à la matérialisation dans l'algorithme materialize. Nous considérons les politiques
suivantes: sous arbres maximaux disponibles, feuilles, et sous-requêtes partagées.
réécriture de requête en fonction de vues Un algorithme qui accepte comme arguments
une requête et un ensemble de vues et réécrit la requête en utilisant les vues, si possible.
relation matérialisée Une relation dans l'état du médiateur qui contient la réponse à une
sous-requête.
réponse complète La réponse à une requête initiale.
réponse incrémentale La réponse à une requête incrémentale. Cette réponse, lorsqu'elle
est obtenue, est équivalente à la réponse complète à condition qu'aucune mise à jour
concernant la requête ne soit eectuée sur les sources de données.
réponse partielle Ensemble d'informations partielles se rapportant à la requête initiale ;
la réponse à une requête parachute.
requête une requête conjonctive (requête relationnelle composée uniquement de sélections,
projections et jointures) ou une union de requêtes conjonctives.
requête incrémentale Une réécriture de la requête initiale qui utilise l'état du médiateur.
requête parachute Une requête utilisée pour extraire de l'information partielle de l'état
du médiateur.
source de données Une source de données autonome.
sous-arbre maximal disponible La sous-requête qui correspond à un sous-arbre maximal
du plan d'exécution dont les feuilles sont toutes disponibles dans une conguration
donnée.
sous-réponse La réponse à une sous-requête.
sous-requête Une partie de la requête qui résulte de sa décomposition. Des sous-requêtes
sont envoyées aux sources de données qui renvoient des sous-réponses. Des sous-requêtes
sont également matérialisées dans l'état du médiateur. Chaque sous-arbre du plan
d'exécution possède une sous-requête associée. Il est à noter que la notion de sous-
requêtes ainsi dénie n'est pas celle utilisée par Ullman [102] qui appelle sous-requête
une expression de type select-from-where utilisée dans la clause where d'une requête.
sous-requête partagée (SRP) La sous-requête la plus spécique dont le corps contient
un ensemble de requêtes parachutes et la requête initiale (au sens du containment
mapping).
temps de traitement Temps de traitement de la requête lors des évaluations successives.
Le temps de réponse est composé du temps de traitement et du temps d'attente entre
les soumissions des requêtes incrémentales.
155
variable range restricted Une variable qui apparait dans un prédicat correspondant à une
relation, dans le corps d'une règle datalog.

Integration Donnees - These Bonnet - Mediation

Transféré par

Droits d'auteur :

Formats disponibles

Integration Donnees - These Bonnet - Mediation

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Integration Donnees - These Bonnet - Mediation

Transféré par

Droits d'auteur :

Formats disponibles

THÈSE

Prise en compte des sources de données indisponibles

Soutenue le 25 janvier 1999

Je remercie André Flory,

Table des matières

2 Les systèmes de médiation 13

3 Systèmes de médiation et sources de données indisponibles 41

4 Traitement incrémental des requêtes 53

5 Extraction d'informations partielles 73

1.3 Plan du Manuscrit

Chapitre 3 Ce chapitre est consacré au problème du fonctionnement du système de mé-

Chapitre 4 Ce chapitre concerne le traitement incrémental des requêtes. L'objectif est

Chapitre 5 Ce chapitre décrit diérents aspects de l'extraction d'informations partielles.

Chapitre 7 Ce chapitre de conclusion résume les contributions de notre travail et suggère

2.2 Besoins et Applications

2.2.1 Complexe hospitalier

2.2.2 Catalogues documentaires

2.2.3 Autres applications

2.2.3.2 Guide d'achat

2.2.3.3 Construction de sites WWW

Tab. 2.1  Caractéristiques des applications BHS et Redoc.

Source 1 Source 2 Source n

Fig. 2.1  Architecture naive.

2.3.1 Architecture Naïve

Source 1 Source 2 Source n

Fig. 2.2  Architecture basée sur un entrepôt de données.

2.3.2 Entrepôt de données

2.3.3 Système de médiation

Source 1 Source 2 Source n

Fig. 2.3  Architecture basée sur un système de médiation.

l'interface et les fonctionnalités sont précisément dénies. Un système de médiation se doit de

2.4.1 Systèmes fédérés

 respecter l'autonomie des bases de données locales ;

2.4.2 Systèmes à grande échelle

patient(PatientId, Nom, Prenom, Adresse, Sejour).

vue_admin(AdminId, Nom, Prenom, Adresse, Sejour) =>

patient(PatientId, Nom, _, _, _),

*Admin :- Admin:<admin, {<id I><nom N><prenom P><adresse A><sejour S>}>

Le médiateur exporte un ensemble de vues utilisateurs exprimé en fonction des requêtes

<patient, {<patientId PId><nom N><prenom P><adresse A><sejour S>}> :-

<réponse, {<nom N>}> :-

2.4.3 Systèmes commerciaux

2.4.4 Problématique associée aux systèmes de médiation

Développement d'adaptateurs A chaque source de données est associée un adaptateur.

8. Coin a été développé à Sloan School of Management, MIT [8, 18]

2.4.4.2 Optimisation des requêtes

13. Hermes a été développé à l'Université du Maryland, College park [9].

2.4.4.3 Exécution des requêtes

3.1 Problèmes dues aux sources de données indisponibles

3.1.2 Exigences des utilisateurs

3.1.3 Impact sur le traitement de requêtes

3.2 Limitation des systèmes de médiation existants

3.3 Approches existantes

3.3.2 Traitement approché des requêtes

Réponses approchées et réponses exactes Le traitement approché des requêtes pro-

Opérations spéciques pour le traitement approché des requêtes Les relations

c(X,Y,Z) :- a(X,Y), b(Y,Z).

où a est disponible et b indisponible. La relation a étant disponible son approximation est

3.3.3 Utilisation de caches sémantiques

Chapitre 5 Ce chapitre décrit diérents aspects de l'extraction d'informations partielles.

Tab. 2.1 Caractéristiques des applications BHS et Redoc.

Fig. 2.1 Architecture naive.

Fig. 2.2 Architecture basée sur un entrepôt de données.

Fig. 2.3 Architecture basée sur un système de médiation.

l'interface et les fonctionnalités sont précisément dénies. Un système de médiation se doit de

respecter l'autonomie des bases de données locales ;

Opérations spéciques pour le traitement approché des requêtes Les relations

détecter les sources indisponibles ;

Fig. 4.1 Architecture incrémentale.

Fig. 4.4 Plan d'exécution annoté obtenu en sortie de l'algorithme sense.

Fig. 4.5 L'algorithme de matérialisation des données disponibles prenant en compte un

Fig. 5.1 Génération des requêtes parachutes.

Denition 6 (Sous-ensemble) Q1 est un sous-ensemble de Q2, noté Q1 Q2 , pour

Denition 7 (Sur-ensemble) Q1 est un sur-ensemble de Q2 , noté Q1 Q2 , pour toutes

Denition 8 (Sous-ensemble généralisé) Q1 est un sous-ensemble généralisé de Q2 , noté

Denition 9 (Sur-ensemble généralisé) Q1 est un sur-ensemble généralisé de Q2 , noté

V2 contient les prix de certains modèles de voitures italiennes

V3 contient tous les modèles de voitures allemandes

la requête initiale Q : une union de requêtes conjonctives Q = Q1 [ [ Qn ;

Si Vi est une sous-requête de Qi , alors

Fig. 5.5 Représentation de la réponse

Cette requête parachute est illustrée sur la gure 5.6 2

Fig. 5.8 Architecture d'un système incrémental sous contrainte.

Fig. 5.9 Toutes les intersections possibles entre trois ensembles.

Denition 11 (Containment mapping) Un ensemble de littéraux L est contenu dans un

Denition 12 (Intersection de deux requêtes) L'intersection de deux requêtes Q1 et