dwh dm - these sur autre sujet qui aborde speed notions

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 M. : Dennis MM. : Andr Michel MM. : Mauricio Patrick Anthony
Gardarin Shasha Flory Riveill Lopez Valduriez Tomasic

Pr sident et rapporteur Rapporteur Co-directeurs de th se Examinateurs

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 con ance et leur engagement m'ont permis de me lancer. Je remercie Mauricio Lopez, mon chef, je remercie Patrick Valduriez, ils m'ont permis d'e ectuer 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. En n, 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
2.1 Introduction . . . . . . . . . . . . . . . 2.2 Besoins et Applications . . . . . . . . . 2.2.1 Complexe hospitalier . . . . . . 2.2.2 Catalogues documentaires . . . 2.2.3 Autres applications . . . . . . . 2.2.4 Bilan . . . . . . . . . . . . . . . 2.3 Architecture . . . . . . . . . . . . . . . 2.3.1 Architecture Na ve . . . . . . . 2.3.2 Entrep t de donn es . . . . . . 2.3.3 Syst me de m diation . . . . . 2.3.4 Bilan . . . . . . . . . . . . . . . 2.4 Syst mes de m diation existants . . . . 2.4.1 Syst mes f d r s . . . . . . . . 2.4.2 Syst mes grande chelle . . . 2.4.3 Syst mes commerciaux . . . . . 2.4.4 Probl matique associ e aux syst ........... ........... ........... ........... ........... ........... ........... ........... ........... ........... ........... ........... ........... ........... ........... mes de m diation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13
13 13 14 15 15 17 17 18 19 20 22 24 24 27 32 33

4

Table des mati res 2.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3 Syst mes de m diation et sources de donn es indisponibles
3.1 Probl mes dues aux sources de donn es indisponibles 3.1.1 Indisponibilit des sources de donn es . . . . . 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.1 R plication . . . . . . . . . . . . . . . . . . . 3.3.2 Traitement approch des requ tes . . . . . . . 3.3.3 Utilisation de caches s mantiques . . . . . . . 3.3.4 Bilan . . . . . . . . . . . . . . . . . . . . . . . 3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

41
41 41 43 44 45 45 46 46 49 50 50

4 Traitement incr mental des requ tes
4.1 Introduction . . . . . . . . . . . . . . . . 4.2 Architecture d'un syst me incr mental . 4.2.1 Composants . . . . . . . . . . . . 4.2.2 Fonctionnement . . . . . . . . . . 4.2.3 Implantation . . . . . . . . . . . 4.3 D tection des sources indisponibles . . . 4.4 Mat rialisation des donn es disponibles . 4.5 Construction de la requ te incr mentale 4.6 Comparaison avec des travaux existants . 4.7 Conclusions et perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

53
53 55 55 58 59 60 62 65 68 69

5 Extraction d'informations partielles

73

5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 5.1.1 Requ tes parachutes . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

Table des mati res 5.1.2 Formulation des requ tes parachutes . . 5.1.3 valuation des requ tes parachutes . . . G n ration de requ tes parachutes . . . . . . . . 5.2.1 Cadre g n ral . . . . . . . . . . . . . . . 5.2.2 Algorithme . . . . . . . . . . . . . . . . 5.2.3 Discussion . . . . . . . . . . . . . . . . . Optimisation sous contrainte . . . . . . . . . . . 5.3.1 Architecture . . . . . . . . . . . . . . . . 5.3.2 Algorithme d'optimisation . . . . . . . . 5.3.3 Politique de mat rialisation . . . . . . . 5.3.4 Discussion . . . . . . . . . . . . . . . . . Comparaison avec des travaux existants . . . . . 5.4.1 Extraction d'informations partielles . . . 5.4.2 Optimisation d'un ensemble de requ tes Conclusions et Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5 75 76 76 76 80 90 91 91 92 101 102 102 103 106 107

5.2

5.3

5.4

5.5

6

valuation
6.1 Cadre Exp rimental . . . . . . . . . . . . . . . . . . . . . . . . 6.1.1 Mod le Analytique . . . . . . . . . . . . . . . . . . . . . 6.1.2 Environnement de simulation . . . . . . . . . . . . . . . 6.1.3 Charge de Travail . . . . . . . . . . . . . . . . . . . . . . 6.2 Traitement incr mental des requ tes . . . . . . . . . . . . . . . . 6.2.1 Temps de traitement . . . . . . . . . . . . . . . . . . . . 6.2.2 Nombre de soumissions pour obtenir la r ponse compl te 6.3 Optimisation sous contrainte . . . . . . . . . . . . . . . . . . . . 6.3.1 Pr sentation des requ tes parachutes . . . . . . . . . . . 6.3.2 R sultats de l'optimisation sous contrainte . . . . . . . . 6.3.3 Comparaison des politiques de mat rialisation . . . . . . 6.3.4 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . .

109
110 110 111 112 115 115 120 128 128 129 130 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 soussyst 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'entreprises 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 veloppement 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'information autonomes et cependant interconnect s. Un r seau Intranet permet en e et 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'information 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 renvoie 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 probl mes de r partition et d'h t rog n it et qui fournissent un acc s e cace 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'o re 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'o rent 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'e ectuer une op ration de maintenance 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 indisponibles 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 probl 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 compl 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 e cacement. 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 identi ants 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 docteur consulte tous les pisodes th rapeutiques subis par un de ses patients, il peut ventuellement 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 e cace. 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'e cacit de cette approche. comment un syst me de m diation peut faciliter l'extraction d'informations partielles par une application.

l'extraction d'informations partielles Le deuxi me objectif de cette th se est d' tudier

Ces deux axes sont compl mentaires : lorsqu'une r ponse est construite de mani re incr 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'informations 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'informations 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 signi cation 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. Ceuxci 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 donn 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 requ 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 permettent 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 probl 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 document.

Les syst mes de m diation

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 e ectu 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'int 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 CLINIC 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 limitations 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 ci cation 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, radiologie, .... 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 cialistes 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 ci cation 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 participent 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 bibliographiques. 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 grandement b n cier des informations disponibles sur le World Wide Web 70 . De nombreuses

16

Les syst mes de m diation

organisations les entreprises, les tablissements nanciers, les bourses o rent des services en ligne le cours des actions, les indices industriels, les comptes des entreprises, des recommandations 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 recommand es l'achat par un analyste nancier, retenir uniquement celles qui concernent le segment de march int ressant, et en n 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 recherche 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 Nombre de sources Type de sources BHS Redoc 20 30 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 e ectu e par l'application 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.

18
Utilisateur

Les syst mes de m diation

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 ci ques 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 ci ques 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 e cacement un acc s pr d ni un petit nombre de sources de donn es ; elle ne permet cependant pas l'application d' voluer.

Architecture
Utilisateur

19

Application

Entrepot de donnees

Extraction

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
Un entrep t de donn es stocke, sous une forme int gr e, des donn es extraites d'un ensemble de sources de donn es 58 . Les donn es sont extraites des sources de donn es, transform 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'architecture na ve, le travail d'int gration et de traitement des requ tes n'est plus e ectu 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'entrep 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 donn 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'in uence 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 e cacement des

20

Les syst mes de m diation

requ tes complexes impliquant par exemple des agr gats sur de larges collections de donn 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 e ectu 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. En n, le principal d savantage de cette architecture est que certaines sources ne permettent pas l'extraction de donn es. En e et, 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 e ectuant 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'e ectuer 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 e ectue 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 application. 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 arti cielle 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 en n les techniques qui permettent un acc s e cace 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 Intelligent 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 adaptateur 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.

22
Utilisateur

Les syst mes de m diation

Application

M

A

A

A

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 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 reprenons 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'entrep 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 e cace de tous types de requ tes ind pendamment des caract ristiques du r seau ; elle peut

Architecture
Caract ristiques des applications
Nombre de sources Type de sources Fr quence des mises jour Type de r seau

23
architecture architecture bas e na ve sur un entrep t de donn es faible peu h t rog nes indi rente indi rent extraction possible faible indi rent possible oui toutes indi rent oui architecture bas e sur un syst me de m diation indi rent indi rent indi rente in ue sur les performances impossible oui union de requ tes conjonctives faible pour les requ tes conjonctives non

in ue sur les performances Exigence de coh rence impossible Requ tes ad-hoc non Type de requ te pr d nies
Nombre de relations par requ te Agr gats

faible non

Tab. 2.2  Ad quation des di rentes architectures aux caract ristiques des applications.

galement permettre de v ri er des contraintes d'int grit entre des relations situ es sur di rents sites 113 . L'approche na ve est, elle, di cile 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.

24

Les syst mes de m diation

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 applicative, outils d'administration, ...  o rir des performances qui approchent celles des syst mes de bases de donn es distribu es.

Syst mes de m diation existants

25

Nous pr sentons ci-dessous les caract ristiques de deux prototypes de recherche : Multibase 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 modi cations 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 gestionnaire 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 e caces 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

26

Les syst mes de m diation

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 traitement 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 trait es. Les traitements qui ne peuvent pas tre e ectu 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 e ectuer 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 ESPRITP8929. 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 sousrequ 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

Syst mes de m diation existants

27

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 identi er 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 Multibase. Ce choix, e ectu en 1993, a cependant entra n un gros e ort 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 important 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' volution 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. En n, 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.

28

Les syst mes de m diation

2.4.2.1 Information Manifold
Information Manifold 66 a t d ni par AT&T Bell Laboratories. Ce projet a essentiellement 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 repr 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:

patientPatientId, Nom, Prenom, Adresse, Sejour. radioloRadioloId, Date, Description, Image. chirurgChirurgId, Statut, Description. mapPatientId, RadioloId, ChirurgId.
o map permet de mettre en correspondance les identi ants sp ci ques chaque relation globale. Chaque adaptateur associ une source de donn es exporte une ou plusieurs vues. Chacune 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_adminAdminId, Nom, Prenom, Adresse, Sejour = patientPatientId, 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 :

patientPatientId, Nom, _, _, _, chirurgChirurgId, 'attente', _, mapPatientId, _, ChirurgId =
requ teNom.
5. Datalog sans r cursion repr sente une restriction de ce langage 103 .

Syst mes de m diation existants

29

Le m diateur r crit cette requ te en utilisant les vues export es par les adaptateurs. L'algorithme 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_adminAdminId, Nom, Prenom, Adresse, Sejour, vue_chiruChiruId, 'attente', _, mapPatientId, AdminId, _, ChiruId = requ teNom. L'algorithme de r criture ne garantit pas que la requ te obtenue par r criture est quivalente 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 e et que les sources enregistr es aupr s d'Information Manifold ne permettent pas de couvrir enti rement le sch ma global e.g., le service de radiologie fournit uniquement les radios e ectu es lors du mois coul alors que le sch ma global exporte toutes les radios e ectu 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 identi ant 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 Speci cation 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 .

30

Les syst mes de m diation

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 con gurer 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'administration 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 admin, id AId map, patientId radiolo, patientId PId radio, radioId map, patientId chirurg, patientId PId chiru, chiruId map, patientId nom N prenom P adresse A sejour S :nom N prenom P adresse A sejourS @admin_source, PId adminId AId . date Da description De image I :RId date Da description De image I @radio_source, PId radioId RId . statut S description D :RId statut S description D @chiru_source, 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 identi ants des di rentes sources de donn es. Ajouter une nouvelle source de donn es n cessite 1 le d veloppement et la con guration 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, chirurg, :patientId PId patientId PId nom N , statut 'attente'

.

Tsimmis adopte une approche ascendante pour l'int gration de donn es : les vues export es par le m diateur sont d nies en fonction des vues export es par les sources de donn es.

Syst mes de m diation existants

31

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 adaptateurs vers JDBC, Lotus Notes, des moteurs de recherche du WWW, les chiers structur s AS 400. Le mod le relationnel s'est av r su sant 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 con guration 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 CHAR30, prenom CHAR30, adresse CHAR60, 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 commande sp ci que 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 adminWrapper. 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

32

Les syst mes de m diation

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 FROM WHERE AND AND nom admin, map, chirur admin.id = map.aid chiru.id = map.cid 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 permettant 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 objectif est de fournir un acc s transparent un ensemble de bases de donn es relationnelles. DataJoiner fournit un service de nommage pour viter les con its de noms entre les relations 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 en n 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 bureau7. Garlic est un syst me grande chelle qui a t d velopp IBM Almaden 7, 25

Syst mes de m diation existants

33

tiques. En e et, 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 essentiellement 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 moteurs, 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 donn 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 e ectuer 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 objectifs 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 alis 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 ci ques doivent tre d velopp s. Infomaster 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.

34

Les syst mes de m diation

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 e cacement 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 translation 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 ci ques qui doivent tre r alis s pour mettre en oeuvre un adaptateur particulier. Bien que chaque adaptateur soit sp ci que 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 autour de ces deux fonctions essentielles. De telles architectures permettent d'identi er 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 ci ques 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

Syst mes de m diation existants

35

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 con its 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 di cile. 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 con its s mantiques entre les sch mas export s par le m diateur. C'est notamment le cas de Disco, o il su t 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 su t 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 con its s mantiques. Coin 19 propose une approche d clarative pour la r solution des con its 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 con its s mantiques ventuels. Le m diateur utilise les informations contenues dans les contextes pour r crire les requ tes en r solvant les con its. 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 introduit 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 mod 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.

36

Les syst mes de m diation

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 collection. 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 e ectu e par les sources de donn es et quelle est la part du travail qui doit tre e ectu 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 appliquer 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 e ectuer. 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 ci er, pour chaque adaptateur, 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 ri12. Un bind join, ou dependant join, est une boucle imbriqu e o le m diateur passe des r sultats interm diaires correspondant aux valeurs d'un pr dicat de jointure de la relation ext rieure vers la relation int rieure 53, 86 .

Syst mes de m diation existants

37

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 e ectu s sur le m diateur, les communications et les traitements e ectu 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 signi cativement selon le moment o les transferts sont e ectu s. Il s'agit, d'autre part, de prendre en compte les co ts de traitements e ectu s par les sources de donn es et les adapteurs qui leurs sont associ s. Ceci est particuli rement di cile 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 sousrequ 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 e ectu s sur une famille de source de donn es. Cette approche est e cace 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 di cile 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'adaptateur de ne sp ci er 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 .

38

Les syst mes de m diation

adaptateur doit fournir un mod le de co t complet. Cette solution demande plus d'e ort au d veloppeur d'adaptateur ; elle o re en contrepartie un mod le de co t plus pr cis l'optimiseur.

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 ralement 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 probl 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 supprime de son cache lorsque celui-ci est plein. Deuxi mement, le m diateur doit utiliser les donn es du cache de mani re e cace 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 modi er des donn es impliqu es dans une requ te globale. Si un cache s mantique est utilis , des mises jour e ectu 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 di cult 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 ine cace 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 modi ant 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 e ectu 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 e ectu 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 architecture 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

40

Les syst mes de m diation

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'e ectuer 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 . En n, 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 fonctionnement 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'insu sance 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
De nition 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 e et, 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 e ectu 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 maintenance 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. En n, la source de donn es peut modi er 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 donn es n'o rent 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 e ectu 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 di cult 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 concernant 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. Troisi 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. En n, 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 noti er 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 noti cation 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 rement, 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 informations 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 radiologiques 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

44

Syst mes de m diation et sources de donn es indisponibles

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 e cace.

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 ci ques 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 noti cation 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 implique 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 En terme de performances, les objectifs du syst me de m diation sont les suivants :

45 

la noti cation, 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 ci que n'est implant pour d tecter qu'une source de donn 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 syst 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.

46

Syst mes de m diation et 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 certaines 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 principale 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 relation sont mis jour simultan ment, et la r plication asynchrone lazy replication, o les modi cations 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 indisponibles au moment de la propagation des mises jour : les mises jour vers les sites disponibles sont e ectu 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 sou re de plusieurs inconv nients. Du point de vue conomique, la r plication 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 fonctionnement et les performances des mises jour 49 . Le principal d savantage, en n, est que dans un contexte o les sources de donn es sont autonomes, il peut tre impossible de r pliquer 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 e et, 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'e ectuer 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 produit 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 sousvue 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. En n, Buneman et al. 22, 23, 75 , d nissent la r ponse approch e en terme d'un sousensemble 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.

De nition 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 , t1l v t2l

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.

De nition 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.

De nition 4 ordre de Smyth v  Soient A et B deux ensembles de tuples. A est inf rieur B dans l'ordre de Smyth, not A v B , 8b 2 B; 9a 2 A tel que a v b

48

Syst mes de m diation et sources de donn es indisponibles B dans l'ordre de Smyth alors A contient moins de

Intuitivement, A est inf rieur 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 approch 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 ci ques 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 ci ques pour e ectuer 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
cX,Y,Z :- aX,Y, bY,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 surensemble 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 ra ner le sur-ensemble g n ralis de c. En e et, 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 mantique 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

50

Syst mes de m diation et sources de donn es indisponibles 

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 partielles 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 donn 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 insu santes pour fournir une solution 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 ci que. 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 o rent 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 e cacement 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 pro ter 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 pro ter 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.

52

Syst mes de m diation et sources de donn es indisponibles

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 e et 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 e et 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 consid 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, ventuellement 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 syst me existant pr sente donc les limitations suivantes lorsqu'il doit traiter plusieurs fois la m me requ te :  le travail qui est e ectu avec les sources disponibles est perdu si une source est indisponible ; 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 e et, 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 syst 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'application 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 identi ants 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 donn 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 rieurement 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'administration 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 incr mental en identi ant 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 algorithme 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 e ectuant un minimum de modi cations.

4.2.1 Composants
Les composants sp ci ques 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.

56
Requete

Traitement incr mental des requ tes

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 identi e un ensemble de sources indisponibles 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 identi cation des sources indisponibles, le syst me obtient des informations qu'il peut utiliser pour d cider d'une strat 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 disponibilit 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

Architecture d un syst me incr mental

57

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 mat 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 temporaires 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 modi cation 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 e cacement 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 e ectu 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 concernant 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.

58

Traitement incr mental des requ tes

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 modi cations e ectu 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 construction 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 e et, 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 noti cation 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,

Architecture d un syst me incr mental

59

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 disponibles 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 noti cation 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 noti cation 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 WHERE PATIENT.ID = MAP.PID AND MAP.SID = SURGERY.ID

AND PATIENT.STAY 10 AND SURGERY.STATUS = 'WAITING';

Une noti cation est retourn e l'application. Cette noti cation lui permet d'acc der la requ te incr mentale que le syst me a construit. L'application d cide de la soumettre au syst 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;

2

4.2.3 Implantation
L'implantation des nouveaux composants mentionn s ci-dessus concerne essentiellement le m diateur. L'optimiseur classique n'est pas a ect . Des informations particuli res doivent

60

Traitement incr mental des requ tes

tre obtenues concernant les op rateurs alg briques ; il est possible, pour g rer ces informations de modi er 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 noti cation 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 modi er une interface 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 fonctionnement 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 portions 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 sensesous-plan

si source est disponible ou sinon 

tous les ls sont disponibles alors marquer operateur disponible marquer operateur indisponible
sense

Fig. 4.3  L'algorithme

tout value ses arguments en parall le.

de d tection des sources indisponibles. L'expression pour

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 ci que 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 destin 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'algorithme 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 parcouru 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.

62
Π
I I

Traitement incr mental des requ tes

submit

I

D

RADIOLOGY MAP

D

D

submit

D

submit

D

σ
PATIENT

σ
SURGERY

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

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 cursivement. 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 indisponible puisqu'un de ses ls est indisponible. 2

Exemple Nous reprenons notre exemple et nous consid rons que la source du service

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 e ectu 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 insu sant. 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 e ectu 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 su sant, 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 sousplan 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.

64

Traitement incr mental des requ tes

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-estimatesous-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 e ectivement 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
Π
I I

65

submit

I

materialize

V1

RADIOLOGY

D

D

D

MAP submit
D

submit

D

σ
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 e ectivement utilis est sup rieur l'espace restant disponible, alors la relation temporaire courante est d truite. Autrement, l'espace qui a t e ectivement 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 su sant. 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 donn 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 concernant 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.

66

Traitement incr mental des requ tes

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 projection, 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 su t 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 rateur 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 noti cation l'application qui doit soumettre 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 initiale 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 4uplet 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'identi ant de la relation mat rialis e V : = l'ensemble des variables qui apparaissent dans la sous-plan op rateur M : = V; x retourner mapM; S , fx; X g, ;, M sinon si operateur est un join alors S1; F1; W1 ; M1 : =constructsous , arbre , gaucheoperateur S2; F2; W2 ; M2 : =constructsous , arbre , droitoperateur M : = M1 M2 retourner mapM; S1 S2, F1 F2, mapM; W  W1 W2 , M  sinon si operateur est un project alors S1; F1; W1 ; M1 : =constructfilsoperator retourner mapM1,S , F1 , W1 , M1 sinon si operateur est un select alors S1; F1; W1 ; M1 : =constructfilsoperator retourner S1, F1 , W W1 , M1 sinon si operateur est un scan alors x : = une variable unique X : = l'identi ant 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 .

68

Traitement incr mental des requ tes

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 sousarbre. 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;

2

4.6 Comparaison avec des travaux existants
Nous discutons ici des travaux e ectu 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 requ tes 3 4 104 . Les deux approches sont bas es sur l'id e que du travail utile peut tre e ectu 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. 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 e ectu , 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 queries using views dans le syst me. L'algorithme answering queries using views de Levy et al. 72 est par exemple d compos 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 : qX,U  pX,Y ^ p0Y,Z ^ p1X,W ^ p2W,U V : vA,B  pA,C ^ p0C,B ^ p1A,D La requ te peut tre r crite en utilisant V de la mani re suivante : Q': qX,U  vX,Z ^ ^ p1X,W ^ p2W,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'identi cation 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 incr 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

70

Traitement incr mental des requ tes

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 ri er 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 modi cation de l'optimiseur ou du moteur d'ex cution. Il sera int ressant de sp ci er le traitement incr mental des requ tes pour un syst me de m diation existant autre que Disco pour v ri er l'impact de nos algorithmes sur les architectures existantes et pour d nir les modi cations 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 e ort 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 noti er 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 e cace 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 mental des requ tes et les techniques de cache s mantique.

71

72

Traitement incr mental des requ tes

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 sousensemble 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 signi cation 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 noti cation 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'extraction 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 signi cation 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 ci er les donn es qu'elle souhaite extraire est de formuler une requ te.

De nition 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 FROM PATIENT, MAP, SURGERY 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'application 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 noti cation 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 noti cation 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 requ 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 ressant 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 augmenter ses chances d'y apporter une r ponse dans le cas o une ou plusieurs sources de

76

Extraction d informations partielles

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 notication 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 temporaires n cessite une tape de r criture. La requ te parachute doit en e et 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 requ tes parachutes : 1 quelles sont les informations partielles que le syst me permet d'extraire? 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
Informations utilisateur

77

Q

Generation de requetes parachutes

PQ

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 mental 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 mental 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'extraire 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 ci er 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 e ectu par l'utilisateur. Une deuxi me possibilit est que l'utilisateur donne des indications sur les r ponses partielles 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 ci er 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

78
11111111 00000000 11111111 00000000 11111111 00000000 11111111 00000000 11111111 00000000 11111111 00000000 11111111 00000000 11111111 00000000 11111111 00000000 11111111 00000000 11111111 00000000 11111111 00000000 11111111 00000000 11111111 00000000 11111111 00000000 11111111 00000000 11111111 00000000 11111111 00000000 11111111 00000000 11111111 00000000 11111111 00000000 11111111 00000000 11111111 00000000 11111111 00000000 11111111 00000000 11111111 00000000 11111111 00000000 11111111 00000000 11111111 00000000 11111111 00000000 11111111 00000000 11111111 00000000

Extraction d informations partielles
11111 00000 11111 00000 11111 00000 11111 00000 11111 00000 11111 00000 11111 00000 11111 00000 11111 00000 11111 00000 11111 00000 111111 000000 111111 000000 111111 000000 111111 000000 111111 000000 111111 000000 111111 000000 111111 000000 111111 000000 111111 000000 111111 000000 111111 000000 111111 000000 111111 000000 111111 000000 111111 000000 111111 000000 111111 000000 111111 000000 111111 000000 111111 000000

(a)

(b)

(c)

(d)

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 0000 1111 0000

(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 ci er la relation entre la requ te initiale et la requ te parachute et d'implanter un algorithme de g n ration de requ tes parachutes. 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 attributs n'apparaissant pas dans la requ te initiale. Cette hypoth se est cependant raisonnable ; elle signi e 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'attributs et moins de tuples ou ventuellement autant que la r ponse compl te ;

G n ration de requ tes parachutes

79 

d tre un sur-ensemble g n ralis de la r ponse compl te, elle contient moins d'attributs 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 relations 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'apparaissent 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.

De nition 6 Sous-ensemble Q1 est un sous-ensemble de Q2, not Q1 Q2 , pour toutes bases de donn es D, Q1 D Q2 D
QiD d note l'ensemble des r ponses Qi dans la base de donn es D.

De nition 7 Sur-ensemble Q1 est un sur-ensemble de Q2 , not Q1 Q2 , pour toutes bases de donn es D, Q1 D Q2 D
Q1 .
Il est noter que lorsque Q1 est un sous-ensemble de Q2 alors Q2 est un sur-ensemble de

De nition 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 De nition 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 ci er les r ponses partielles qui l'int ressent. L'utilisateur peut interagir avec l'application de mani re plus pr cise et sp ci er 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.

80

Extraction d informations partielles

simple. Dans le cas de l'application du complexe hospitalier, il est possible d' tendre l'interface graphique pour permettre l'utilisateur de sp ci er 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 motscl 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 su t de demander l'utilisateur s'il est int ress par un sous-ensemble de la r ponse compl te. 2

Exemple En pratique l'interaction entre l'application et l'utilisateur peut tre assez

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 signi cation 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 a chant 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'utilisateur 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 su t 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.

G n ration de requ tes parachutes

81

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' ;
Π

U

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

82

Extraction d informations partielles

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.

G n ration de requ tes parachutes

83

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 mat 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 conjonctives 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 possibles 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.

84

Extraction d informations partielles

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'e ectuer 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 sousgraphes 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

G n ration de requ tes parachutes

85

2. 3. 4. 5.

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 ; 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 correspondante. Ceci est possible car chaque Vi est une sous-requ te de Qi ; 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 ; 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 ; une requ te parachute est g n r e pour chacun des sous-graphes connect s.
V1
MANUF MODEL PRICE COLOR

PQ1
MANUF MODEL

V2
PRICE COLOR

V2

PQ2

Fig. 5.5  Repr sentation de la r ponse

la requ te parachute PQ1 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 pour la jointure des vues V1 et V2.

Fig. 5.6  Repr sentation de la r ponse

la requ te parachute PQ2 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 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 ;

86

Extraction d informations partielles
MANUF

Une autre requ te parachute, PQ2, est obtenue en s lectionnant les attributs MODEL de la vue V3 qui ne peut tre jointe avec aucune autre vue :
SELECT MANUF, MODEL FROM V3 ;

et

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 e ectuant des jointures entre di rentes vues et en respectant les conditions exprim es dans la requ te initiale. L' tape suivante consiste identi er 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 e ectu 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 UnionCandidates. 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 UnionCandidatesCommonAtts, PQi  sinon une entr e UnionCandidatesCommonAtts, PQk  existe la remplacer par UnionCandidatesCommonAtts, PQi PQk 

G n ration de requ tes parachutes

87

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 maintenant possible de construire les unions de requ tes parachutes existantes.

pour chaque entr e de UnionCandidatesCommonAtts, PQi PQUj := union des requ tes de PQi projet es sur CommonAtts

PQ3
MANUF

PQ1
MODEL PRICE COLOR

PQ2

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 .
Fig. 5.7  Repr sentation de la r ponse

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

88

Extraction d informations partielles

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 e ectuant 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 e et, 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 e et, 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 su sant 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 parachutes 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 parachute 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 WHERE PATIENT.ID = MAP.PID AND PATIENT.STAY 10

G n ration de requ tes parachutes
AND MAP.SID AND MAP.RID = SURGERY.ID AND SURGERY.STATUS = 'WAITING' = RADIOLOGY.ID;

89

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 parachutes la vue V1, d nie comme suit :
SELECT PATIENT.NAME, PATIENT.ROOM, MAP.RID FROM PATIENT, MAP, SURGERY WHERE PATIENT.ID = MAP.PID AND PATIENT.STAY 10 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, FROM RADIOLOGY RADIOLOGY.COMMENT

90

Extraction d informations partielles

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 temporaires 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 e ectu 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 ci er 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 sousrequ 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'identi er les vues se rapportant aux blocs de la requ te initiale, 2 d'e ectuer 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'e ectuer 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 simpli cation 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 parachutes 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 probl me est de d nir comment le syst me de m diation peut tirer pro t 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 identies. Cette information permet de d nir une politique de mat rialisation sp ci que pour stocker le r sultat des sous-requ tes partag es. De cette mani re le syst me sous contrainte garantit que les requ tes parachutes peuvent tre valu es si les sources de donn es qu'elles impliquent sont disponibles. Les deux politiques de mat rialisation d'un syst me sans contrainte n'o rent 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

92
Requete initiale Requetes parachutes

Extraction d informations partielles

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'espace 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'optimiseur doit tre tendu pour identi er 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 sousrequ 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.

Optimisation sous contrainte

93

Les probl mes lors de l'optimisation sous contrainte sont les suivants. L'optimiseur doit :  identi er les sous-requ tes partag es entre la requ te initiale et les requ tes parachutes ;  construire des plans d'ex cution e caces pour la requ te initiale et les requ tes parachutes 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 identi 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. En n, 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 . Intuitivement, 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.

De nition 10 Intersections possibles entre n ensembles
S = f FijFi 2 fEi; Eigg
i=1 n

94

Extraction d informations partielles

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 simpli er 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.

De nition 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 := mapPID; SID; RID; surgerySID;0 WAITING0; _; radiologyRID; Rcomment; _; patientPID; Pname; Proom; Stay; _; _; Stay 10g et l2 := mapPID; SID; _; surgerySID;0 WAITING0; _; patientPID; 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.

De nition 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 containment mapping entre deux requ tes. La d nition que nous utilisons a t propos e par Levy et al. 72 .

Optimisation sous contrainte

95

d crit dans l'exemple ci-dessus et une requ te q2 dont le corps est l'ensemble de litt raux l2 est : mapX 1; X 2; X 3, surgeryX 2;0 WAITING0; X 6, patientX 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.

Exemple L'intersection entre la requ tes q1 dont le corps est l'ensemble de litt raux l1

De nition 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 :

De nition 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

S = fQ

n

i=1

QijQi 2 fPQi; PQigg , fQ PQ1 : : : PQng

Par rapport la d nition des intersections possibles entre n ensembles, nous ne consid 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 SRP4

PQ2

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.

96

Extraction d informations partielles

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'identi er 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 communs 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 e acer 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 identi er 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 e ectuer directement la sous- tape 1.5, sinon e ectuer la sous- tape 1.3. Le niveau d'intersection l est

Optimisation sous contrainte

97 

   

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 e ectuer la sous- tape 1.5, sinon e ectuer 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 l l    SRPm Rkmax , o Rklmax est l'ensemble des litt raux qui n'apparaissent pas dans l les SRP d j d nis. Si Rkmax n'est pas vide alors SRP = SRP Rkmax . lmax := lmax - 1. R p ter la sous- tape 1.6.

L'objectif de ces sous- tapes est d'identi er 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 Q Q Q Q Q Q

PQ1 PQ1 PQ1 PQ1 PQ1 PQ1 PQ1

PQ2 PQ2 PQ2 PQ2 PQ2 PQ2 PQ2

PQ3 PQ3 PQ3 PQ3 PQ3 PQ3 PQ3

Dans une premi re phase, les sous- tapes 1.1 1.5 permettent d'obtenir toutes les intersections 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 su t 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.

98

Extraction d informations partielles

l l requ tes parachutes et la requ te initiale : Q PQ1 : : : PQl . Il y a au maximum Cn 6 intersections non vides au niveau l . 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 Q Q Q Q Q Q

PQ1 PQ2 PQ3 PQ1 PQ1 PQ2 PQ1

PQ2 PQ3 PQ3 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 sousrequ 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 construction du plan d'ex cution. Notre objectif est double. Nous voulons construire un plan d'ex cution e cace tout en isolant les SRP de mani re pouvoir les identi er 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

Optimisation sous contrainte

99

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 e ectu 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 et les plans d'ex cution des blocs logiques. La racine de chaque bloc logique est annot e q 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 identi e 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 hospitali 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 :

qPname; Proom; RID; Rcomment  mapPID; SID; RID^ surgerySID;0 WAITING0; _^ radiologyRID; Rcomment; _^ patientPID; 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.

100

Extraction d informations partielles

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. :

pqPName; Proom; PAddress  mapPID; SID; _^ surgerySID;0 WAITING0; _^ patientPID; 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 : fmapX 1; X 2; X 3; surgeryX 4; X 5; X 6; patientX 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 = fmapX 1; X 2; X 3; surgeryX 2;0 WAITING0; X 6; patientX 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 e ectuons 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 = ffmapX 1; X 2; X 3; surgeryX 2;0 WAITING0; X 6; patientX 3; X 8; X 9; X 10; X 11; X 12; X 10 10gg: Dans l' tape 2, la strat gie maximale identi e un bloc logique :

fscsq1X 1; X 8; X 9; X 11  mapX 1; X 2; X 3^

surgeryX 2;0 WAITING0; X 6^ patientX 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.

Optimisation sous contrainte La strat gie minimale identi e les blocs logiques suivants :

101

fscsq2X 1; X 2; X 3  mapX 1; X 2; X 3; scsq3X 1  surgeryX 1;0 WAITING0; X 2; scsq4X 1; X 2; X 3; X 5  patientX 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 :

q0Pname; Proom; RID; Rcomment  scsq1 RID; Pname; Proom; _^ radiologyRID; Rcomment; _
Avec la strat gie minimale, q est r crite de la mani re suivante :

q0Pname; Proom; RID; Rcomment  scsq2 PID; SID; RID^ scsq3 SID^ scsq4 PID; PName; Proom; PAddress^ radiologyRID; Rcomment; _
Dans l' tape 3, les plans d'ex cutions obtenus avec la strat gie minimale et avec la strat 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 candidates 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 su sant, toutes les sous-requ tes disponibles sont mat rialis es en prenant garde conserver les SRP telles quelles. Si l'espace de stockage est insu sant, les SRP sont mat rialis es en priorit .

102

Extraction d informations partielles

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 subsumption 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 mesure 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 noti cation 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 identi e 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 partielles. Nous comparons galement notre algorithme d'optimisation sous contraintes aux algorithmes 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

104

Extraction d informations partielles

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 courante 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 permettent 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'informations 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 venons 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 modi er une requ te lorsque sa r ponse est vide query relaxation. Lorsqu'une requ te a une r ponse vide, CoBase la modi e en supprimant ou en modi ant 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 modi cation des requ tes est bas e sur une classi cation 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 classi cation 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 ci er 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 ci er 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 implant 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 AND runway_length

= 4000 = 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 modi cations 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 description 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 signi cation des informations 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.

106

Extraction d informations partielles

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 correspondant 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'identi er les redondances entre les plans locaux qui participent au plan d'ex cution global. En e et, 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'identi cation 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 identi e les sousrequ 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'identi er toutes les sous-requ tes partag es entre la requ te initiale et les requ tes parachutes.

5.4.2.1 Identi cation de sous-requ tes partag es
L'identi cation 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'optimisation 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 syst 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'utilisateur d'indiquer ses exigences et surtout permettre l'application de communiquer la signi cation 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 pro ter de l'opportunit d'extraire des informations partielles doit faire un e ort 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. En n, 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 identi e 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.

108

Extraction d informations partielles

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 performances. 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'in uence 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 e ectu 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 3 2 1 A B C D
Trials 3 2 1 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 simultan 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 disponibles pendant un essai est 1 , pn. Pour t essais, la probabilit que toutes les sources ne soient pas disponibles est de 1 , pnt. Pour t essais, la probabilit que, lors d'au moins un essai toutes les sources de donn es soient disponibles est 1 , 1 , pnt 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 , pt. La probabilit qu'une source de donn es soit disponible au moins une fois en t essais est 1 , 1 , pt . la probabilit que les n sources soient disponibles au moins une fois en t essais est 1 , 1 , ptn 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 simulateur 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 utilisons 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 bu er 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 con gur 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
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

valuation

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 valeur de mani re ce que l'in uence 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 Prolog 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 sections 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 commandes 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 ci cation 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 e ets 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

P

PS

1/10000

S

1/25

N

1/5

R

Π

submit

Fig. 6.4  Graphe de requ te pour

MQ2.

σ
P

Π
PS

submit

Π

N

σ

S R

Fig. 6.5  Plan d'ex cution pour MQ2.

e ectu 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 AND O.ORDERKEY = L.ORDERKEY AND C.CUSTKEY AND C.NATIONKEY = N1.NATIONKEY AND N1.REGIONKEY AND R.NAME = 'EUROPE' AND S.NATIONKEY AND O.ORDERDATE BETWEEN '94-01-01' AND '95-12-31' AND P.TYPE = 'SMALL PLATED STEEL';

= = = =

S.SUPPKEY O.CUSTKEY R.REGIONKEY N2.NATIONKEY

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/200000

1/5 1/150000

submit

N2

P

L

1/1500000

O

C

1/25

N1

1/5

R

Π

1/10000

S

S
1/25

submit

submit

submit

Π

Π
L

Π

σ

N2

σ
P

σ
N1 O submit R

Fig. 6.7  Graphe de requ te pour MQ8.

Π
C

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 e ectu 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 con gurations 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 traitement 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 noti cation, 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 noti cation 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 noti cation 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 e ets de la politique de mat rialisation sur le temps de traitement en section 6.3.3.1.

Traitement incr mental des requ tes cependant pas notre optimiseur a choisir un plan d'ex cution de forme di rente 4 .
10000

117

9000

8000

7000

6000 temps en sec

plan_partiel 5000 classique 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 C-S C-S C-S O-S O-C S S S C S S C S C O sources disponibles L-S L-C L-O P-S P-C P-O P-L S C O L P none

Fig. 6.9  MQ8 - Temps de traitement total pour toutes les con gurations 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 con guration 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 con gurations de sources disponibles. En e et, 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 e ectu 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 a n 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 con guration de sources disponibles. Dans toutes les con gurations o les relations P et L sont toutes deux disponibles, le temps de traitement est approximativement de 8500 secondes ; dans toutes les autres con gurations, 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 con guration des sources disponibles, mais dans une moindre mesure. Dans toutes les con gurations 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 con gurations 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 classique

600

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 con gurations 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

Traitement incr mental des requ tes
600
600

119
500

500

400 temps en sec 1er essai 2eme essai

400 temps en sec 1er essai 2eme essai

300

300

200

200

100

100

0

all

PS-S

P-S

P-PS

S

PS

P

none

0 all PS-S P-S P-PS S PS sources disponibles P none

sources disponibles

Fig. 6.11  MQ2 - 2 essais - syst me Fig. 6.12  MQ2 - 2 essais - syst me clas-

plan_partiel.
700 600

sique.

500

400 temps en sec 1er essai 2eme essai

300

200

100

0

all

PS-S

P-S

P-PS
sources disponibles

S
Page 1

PS

P

none

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 donn 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 e ectu lors du premier 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 con gurations 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 con gurations 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 con gurations 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 e ectu lors du premier essai rend l' valuation de la requ te incr mentale e cace 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 e ectu cette occasion. Dans les con gurations 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 con guration o PS et S sont disponibles, leur jointure est e ectu 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 con gurations o le temps de noti cation 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 con guration 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-

Traitement incr mental des requ tes

121

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 disponibles 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.
Probabilite d’obtenir au moins une reponse 0.8 Probabilite d’obtenir au moins une reponse 1 1 0.8

0.6

0.6

0.4

0.4

0.2

classique incremental

0.2

classique incremental

0 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 Disponibilite des sources 0.8 0.9 1

0 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 Disponibilite des sources 0.8 0.9 1

Fig. 6.14  Probabilit d'obtenir au moins

une r ponse compl te en deux essais pour MQ2

Fig. 6.15  Probabilit d'obtenir au moins

une r ponse compl te en deux essais pour 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 e et, 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
Probabilite d’obtenir au moins une reponse Probabilite d’obtenir au moins une reponse 1 1

valuation

0.8

0.8

0.6

0.6

0.4

0.4

0.2

classique incremental

0.2

classique incremental

0 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 Disponibilite des sources 0.8 0.9 1

0 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 Disponibilite des sources 0.8 0.9 1

Fig. 6.16  Probabilit d'obtenir au moins

une r ponse compl te en quatre essais pour MQ2

Fig. 6.17  Probabilit d'obtenir au moins

une r ponse compl te en quatre essais pour 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 probabilit 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'obtenir 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

Traitement incr mental des requ tes
Nombre d’essais pour obtenir au moins une reponse 10 9 8 7 6 5 4 3 2 1 0 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 Disponibilite des sources 0.8 0.9 1 classique incremental Nombre d’essais pour obtenir au moins une reponse 10 9 8 7 6 5 4 3 2 1 0 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 Disponibilite des sources 0.8 0.9 classique incremental

123

1

Fig. 6.18  Nombre d'essais n cessaires pour

obtenir au moins une r ponse compl te MQ2 avec une probabilit de 90

Fig. 6.19  Nombre d'essais n cessaires pour

obtenir au moins une r ponse compl te 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 signi catives 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 signi catives. Ici, la courbe du syst me incr mental est une borne inf rieure la courbe du syst me classique. 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
Nombre d’essais pour obtenir au moins une reponse 10 9 8 7 6 5 4 3 2 1 0 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 Disponibilite des sources 0.8 0.9 1 classique incremental Nombre d’essais pour obtenir au moins une reponse 10 9 8 7 6 5 4 3 2 1 0 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 Disponibilite des sources

valuation
classique incremental

0.8

0.9

1

Fig. 6.20  Nombre d'essais n cessaires pour

obtenir au moins une r ponse compl te MQ2 avec une probabilit de 99

Fig. 6.21  Nombre d'essais n cessaires pour

obtenir au moins une r ponse compl te 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 e ectu 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 e ectuons 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 con ance ; nous utilisons ici un intervalle de con ance de 90 calcul avec la formule fournie dans 59 . Etant donn la requ te MQ2, il y a huit con gurations possibles de sources disponibles car cette requ te implique trois sources de donn es. Pour chaque con guration, les sousplans candidats la mat rialisation sont connus en fonction de la politique de mat rialisation 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 stockage est su sant. 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.

Traitement incr mental des requ tes
Con guration aucun P PS S P-S P-PS PS-S tous Sous-plans candidats Estimations aucun P 8 PS 8000 S 100 P et S 8 + 100 P et PS 8 + 8000 PS et S 8000 + 100 aucun Con guration aucun P PS S P-S P-PS PS-S tous

125
Sous-plans candidats Estimations aucun P 8 PS 8000 S. N. R 20 P et S . N . R 8 + 20 P et PS 8 + 8000 PS . S . N . R 1600 aucun

Tab. 6.2  Politique de mat rialisation des

feuilles - Sous-plans candidats et estimation de l'espace de stockage n cessaires pour toutes les con gurations de sources concernant la requ te MQ2.

Tab. 6.3  Politique de mat rialisation des

sous-arbres maximaux - Sous-plans candidats et estimation de l'espace de stockage n cessaires pour toutes les con gurations de 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 e ectu 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 compl 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 politique de mat rialisation des sous-arbres maximaux, le second utilise la politique de mat rialisation 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 con ance 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 su sant. 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. En n, les donn es obtenues dans toutes les con gurations de sources peuvent tre mat rialis es. A chaque marche, le nombre moyen d'essais d croit lorsque l'espace allou pour le traitement de la requ te augmente. Le passage de la premi re marche a la seconde est le plus signi catif. 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 pro te d'un espace 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
5 max max-error leaves leaves-error 4

valuation

Nombre d’essais moyen

3

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 e ectu 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 compl te la requ te MQ2 lorsque la disponibilit des sources est de 90. L'in uence de l'algorithme de mat rialisation est peu importante dans cette exp rience : les marches ne sont pas du tout marqu es. En e et, lorsque la disponibilit des sources de donn es est importante, 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.

Traitement incr mental des requ tes
2 max max-error leaves leaves-error

127

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 donn es dans l'application Redoc. Les r sultats sont pr sent s en section 6.4. Ils con rment 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 e ectuant 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 AND N.NATIONKEY = R.NATIONKEY ;

= 'EUROPE'

Fig. 6.24  MQ2-PQ0 en SQL.

La requ te MQ2-PQ1 permet d'obtenir l'identi ant 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 AND P.TYPE LIKE 'BRASS';

= 15

Fig. 6.25  MQ2-PQ1 en SQL.

Il est noter que MQ2-PQ1 contient, dans sa liste de projection, un attribut qui n'appara t pas dans la liste de projection de MQ2.

Optimisation sous contrainte

129

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 e et, 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 SRP submit SRP

Π

submit

Π
submit

submit

σ
P

Π
PS

σ
N

Π
PS

submit

Π

σ

Π

N

P S

σ

S R

R

Fig. 6.26  Plan d' ex cution pour

MQ2 contraint par MQ2-PQ0. Π
SRP submit SRP

Fig. 6.27  Plan d'ex cution pour

MQ2 contraint par MQ2-PQ1.

Π

submit SRP

σ
P

Π
PS

submit

Π

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 : sSacct; Sname; Ssk; NK; Sadd; Sphone; Scom ^

130

valuation

nNK; RK; _ ^ rRK;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 section 6.1.3.1. En e et, 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 :

pPK; Pkind; 15 ^ likePkind; 0 BRASS 0 ^ psPK; 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 e et, 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 e et 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.

Optimisation sous contrainte

131

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 e ectu 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 su sant 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 580 560 540 520 500 all PS-S P-S P-PS S PS P none sources disponibles max feuilles SRP

Fig. 6.29  Comparaison des trois politiques de mat rialisation : max, feuilles et SRP pour

le traitement de MQ2.

La politique max est plus e cace que les deux autres politiques dans la con guration 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 signi catif. Avec la politique max, dans la con guration 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 con gurations de sources disponibles en ordonn es.
tous PS-S P-PS Configuration P-S S PS P aucun 0 8 20 28 100 108 1600 8000 8008 8100 feuilles max SRP

Nb pages allouees a la requete

Fig. 6.30  R ponses

la requ te parachute MQ2-PQ0 en fonction des con gurations 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 con gurations o S est disponible. Les politiques SRP et feuilles permettent de r pondre la requ te parachute dans ces 3 con gurations ; la politique max, elle, ne permet de r pondre la requ te parachute que dans 2 con gurations. En e et, lorsque PS et S sont disponibles, la jointure entre ces deux relations est e ectu 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

Optimisation sous contrainte

133

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 con guration 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 con guration PS-S, lorsque l'espace de stockage est compris entre 8000 et 8100 pages. Dans cet intervalle c'est en e et 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 Configuration P-S S PS P aucun 0 8 20 28 100 108 1600 8000 8008 8100 feuilles max SRP

Nb pages allouees a la requete

Fig. 6.31  R ponses

la requ te parachute MQ2-PQ1 en fonction des con gurations 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 e et, seules quelques con gurations 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'e ectuer 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 durant Savail S; t : = nombre de fois ou S a ete disponible durant tt nombre de fois ou S a ete contactee

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 Singapour, 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 in uence beaucoup les r sultats que nous avons obtenu. Un probl me est de savoir si de tels probl mes sont fr quents. Des mesures e ectu es sur une p riode plus longue permettront d'a ner nos r sultats. Il est noter que tous les cas de sources indisponibles sont dus des connexions qui ne peuvent pas tre tablies.

136
1 0.9 0.8 0.7 Savail 0.6 0.5 0.4 0.3 0.2 0.1 0 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 demi-journees famille 1 famille 2 famille 3 famille 4 Savail 1 0.9 0.8 0.7 0.6 0.5 0.4 0.3 0.2 0.1 0 0 1 2 3 4 5 famille 1 famille 2 famille 3 famille 4

valuation

6 7 8 9 10 11 12 13 14 15 demi-journees

Fig. 6.32  Disponilit des sources par demi- Fig. 6.33  Disponilit des sources par demi-

journ es depuis Singapour.
1 0.9 0.8 0.7 Savail 0.6 0.5 0.4 0.3 0.2 0.1 0 0 1 2 3 4 5 famille 1 famille 2 famille 3 famille 4

journ es depuis Paris.

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'in uence 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 comportement 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 importante que la p nalit inh rente aux syst mes classiques les m mes op rations sont e ectu 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 important 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 noti cation 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 e ectu une exp rience pour nous rendre compte de la disponibilit 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'e ectuer 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 e et, 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 e cacement la r ponse compl te une requ te ;  l'extraction d'informations partielles pour que le syst me permette l'application d'obtenir 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 e cacement. 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 informations 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 ri er dans quelle mesure les syst mes existants peuvent adapter leur fonctionnement en pr sence de sources de donn es indisponibles 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 incr 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 e ectuer 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 ri ant 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 noti er 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 techniques 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 indisponibles 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 probl me est pour l'application de communiquer l'utilisateur la signi cation exacte des donn es qu'elle lui fournit. De mani re g n rale, un syst me de m diation doit permettre ses utilisateurs 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 ci ques aux bases de donn es. Tous ces composants ont pour objectif de fournir l'utilisateur 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'indiquer 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 responsiveness for wide-area data access. Bulletin of the Technical Committee on Data Engineering, 203: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 Management 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 Proceedings 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 Management 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 Proceedings 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. Information 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. Wimmers. 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, 213, September 1998.

Bibliographie

145

27 R. G. G. Cattell. The Object Database Standard: ODMG-93 Release 1.2. MorganKaufmann, 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, 152, 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, 61, 1996. 32 Transaction Processing Performance Council. http: www.tpc.org dspec.html. Tpc-d benchmark speci cation.

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 de nition and generalization for database integration in a multidatabase system. IEEE Transactions on Software Engineering, 106: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 requirements de nition 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, Washington, 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 tradeo s 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, 12: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. Lego . 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 solution. In ACM SIGMOD International Conference on Management of Data, Montreal, Canada, 1996. 50 J. Gray and A. Reuter. Transaction Processing: concepts and techniques. MorganKaufmann, San Mateo, CA, 1994. 51 SIMS group at ISI. SIMS project home page. http: www.isi.edu sims simshomepage.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, 182: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 margie 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 Environments, 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 de nition d2.1.1. MIRO-WEB EP 25208 Deliverable, 1998. 77 J.J. Lu, G. Moerkotte, J. Sch , and V.S. Subrahmanian. E cient maintenance of materialized 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 heterogeneous data sources. In Proceedings of the 11th International Conference on Data Engineering, Orlando, Florida, USA, 1998. 81 Intelligent Integration of Information I3. http: mole.dc.isx.com I3 html briefs I3brief.htmlref. Reference architecture.

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 translation 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 integrated 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 legacy 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, 131: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, heterogeneous, and autonomous databases. ACM Computing Surveys, 223, 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 aggregation 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, 214, 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 http: www.research.att.com suciu workshop-papers.html, 1997. data.

95 The COIN team. D monstration coin. http: context.mit.edu coin demos . 96 The Tsimmis team. D monstration tsimmis. http: wwwdb.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, 42, 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 Computer Society Press. 102 J. D. Ullman. Principals of Database and Knowledge-Base Systems, volume 2. Computer Science Press, 1989. 103 J.D. Ullman. Information integration using logical views. In Proceedings of the International Conference on Database Theory, 1997. 104 T. Urhan, M. J. Franklin, and L. Amsaleg. Cost based query scrambling. In Proceedings 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, 81, 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, 56: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 warehousing 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, 61:740, 1998.

152

Bibliographie

153

Annexe A Glossaire
con guration 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 conjonctive 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. requ te qui lui est envoy e. ou uniforme 103 .

disponible une source est disponible si elle renvoie compl tement la r ponse la sousdonn es semi-structur es les donn es semi-structur es sont des donn es sans sch ma x 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. rachutes sont soumises simultan ment au m diateur.

valuation sous contraintes Un mod le d' valuation o une requ te et ses requ tes pafeuilles Les feuilles du plan d'ex cution par rapport au m diateur les sous-requ tes envoy es aux sources de donn es sont des feuilles d'apr s notre d nition. politique de mat rialisation et d'un espace de stockage limit .

materialize L'algorithme de mat rialisation des sous-requ tes disponibles en fonction d'une 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 e ectu e sur les sources de donn es. la r ponse une requ te parachute.

r ponse partielle Ensemble d'informations partielles se rapportant la requ te initiale ; 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 con guration 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 sousrequ 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. un ensemble de requ tes parachutes et la requ te initiale au sens du containment mapping. Le temps de r ponse est compos du temps de traitement et du temps d'attente entre les soumissions des requ tes incr mentales.

sous-requ te partag e SRP La sous-requ te la plus sp ci que dont le corps contient temps de traitement Temps de traitement de la requ te lors des valuations successives.

155

variable range restricted Une variable qui apparait dans un pr dicat correspondant une
relation, dans le corps d'une r gle datalog.

Sign up to vote on this title
UsefulNot useful