Intgration de bases de donnes: Panorama des problmes et des approches

Christine Parent - Stefano Spaccapietra

cole Polytechnique Fdrale de Lausanne, CH 1015 Lausanne Tl.: +41 21 693.5211 Fax: +41 21 693.5195 (Parent, Spaccapietra)@di.epfl.ch http://diwww.epfl.ch/w3lbd

________________________________________________________________________________
RSUM La conception de nouvelles applications de traitement de donnes ne se fait plus ex nihilo, mais dans un contexte o la plupart des donnes ncessaires sont dj stockes dans des bases de donnes ou dans des fichiers construits de faon autonome pour les besoins des applications existantes. Pour faciliter leur rutilisation, les donnes rutiliser peuvent tre redfinies sous forme d'une base de donnes virtuelle, assurant lintgration logique des donnes sousjacentes. Cet article fournit une vision globale des problmes soulevs et des approches qui ont t proposes pour raliser l'intgration de bases de donnes. ABSTRACT. New data processing applications are no more built from scratch. They have to re-use existing data, which are already stored in computer files or databases. In fact, they are most likely to use data from several autonomous sources. To facilitate application development, the data to be re-used should preferably be redefined as a virtual database, providing for the logical unification of the underlying data sets. This unification process is called database integration. This article provides a global picture of the issues raised and the approaches which have been proposed to tackle the problem. MOTS-CLS : bases de donnes, systmes distribus, fdrations, htrognit, intgration, smantique, systmes rpartis. KEY WORDS : databases, distributed systems, federated systems, heterogeneity, integration, semantics.

________________________________________________________________________________

1. Introduction De nos jours, le dveloppement d'une nouvelle application de traitement de donnes fait le plus souvent appel des donnes dj mmorises dans l'ordinateur, que ce soit dans des fichiers, ou dans une, voire plusieurs bases de donnes indpendantes. C'est le cas, notamment, des grandes entreprises o l'usage largement rpandu de l'informatique se traduit par un dveloppement indpendant de plusieurs bases de donnes pour les applications spcifiques de chaque service ou filiale. Or, les structures des entreprises voluent, surtout dans l'environnement conomique actuel. Les frontires entre services ou entre socits sont alors susceptibles de bouger, crant de nouveaux centres d'intrts, demandant de nouvelles applications qui devront tre construites avec des donnes prises ici et l, plus qu'avec de nouvelles donnes spcifiques. Ainsi, le dveloppement des nouveaux systmes d'informations repose dsormais sur la capacit du systme informatique de raliser l'interoprabilit entre bases de donnes existantes. Cette interoprabilit peut tre ralise trois niveaux: - au niveau le plus interne dans l'architecture des systmes, travers des passerelles (gateways), i.e. des programmes spcifiques qui tablissent des connections entre systmes de telle manire qu'un systme donn peut accder aux donnes d'un autre systme. De telles passerelles sont actuellement disponibles entre plusieurs systmes de gestion de bases de donnes (SGBD). - un niveau intermdiaire, en installant un systme dit multi-bases de donnes [LIT 90], i.e. une couche logicielle permettant chaque utilisateur de dfinir sa vue, persistante, sur un ensemble de bases de donnes. Ces systmes garantissent les connections appropries, tablies d'aprs la dfinition de la vue. Ils permettent donc l'accs aux donnes rparties, mais ne prennent pas en charge les contraintes de cohrence entre les diffrentes sources de donnes.

Ingnierie des sytmes d'information Vol.4, N3, 1996

- au niveau le plus lev, en dveloppant, au dessus des systmes existants, un systme global pour fournir le niveau dsir d'intgration des sources de donnes. Dans cette optique les SGBD rpartis [CER 87] ont d'abord t proposs. Ces systmes s'appuient sur une intgration totale et un contrle centralis: toutes les donnes existantes sont intgres en une base de donnes logique unique (la BD rpartie), et dsormais gres d'une manire cohrente par une seule autorit globale de contrle. Cette approche a dmontr qu'elle ne satisfaisait pas la demande des entreprises dont le besoin d'accder plusieurs sources de donnes doit tre satisfait sans interfrer avec l'exploitation normale de ces sources par leurs propritaires respectifs. Afin de fournir des solutions plus flexibles, les chercheurs ont rcemment dvelopp les systmes de bases de donnes fdres (BDF) [SET 90]. Ces systmes fdrs visent une intgration flexible en fonction de la demande, permettant une coexistence harmonieuse entre le besoin d'intgration de donnes et celui d'autonomie des sites. Ils donnent chaque administrateur de donnes la possibilit de dfinir le sous-ensemble des donnes locales mis disposition des utilisateurs du systme fdr. Ces sous-ensembles sont intgrs en une (ou plusieurs) bases de donnes virtuelles, appeles BDF. L'intgration, l'importation de donnes dans les BDF et l'exportation vers les BDF sont gres par le systme fdr, dont le rle caractristique est de faire respecter les accords de coopration (en termes de smantique de donnes, de rgles d'accs, de gestions des copies, etc.) tablis par les administrateurs. Alors que les passerelles et les systmes multi-bases de donnes fournissent aux utilisateurs un langage d'accs multi-bases de donnes (habituellement de type SQL), sans aucune tentative d'unifier les smantiques des donnes des diffrentes sources, les systmes de bases de donnes distribues ou fdres basent leurs services sur une description intgre des donnes qu'ils grent. Ceci permet leurs utilisateurs d'accder aux donnes comme sur une base de donnes centralise, sans avoir s'inquiter de la localisation physique des donnes accdes ni du type de SGBD qui les gre localement. Cet avantage explique pourquoi chercheurs et entreprises sont trs intresss par l'approche fdre. Nanmoins, plusieurs problmes restent rsoudre avant que cette approche devienne commercialisable. Ni les aspects de conception (comment construire une vision commune des donnes partages), ni les aspects systme (o les techniques doivent tre adaptes un environnement distribu) ne sont compltement rsolus. Les recherches actuelles en conception portent notamment sur l'intgration des schmas et des bases, le travail coopratif, l'volution des schmas et des bases; cot systme, elles portent sur les nouveaux types de transaction (transactions longues, transactions embotes, ), le traitement des requtes, la scurit des donnes, etc. Le coeur du problme de conception est le processus d'intgration des bases de donnes. Il consiste prendre en entre un ensemble de bases de donnes (schmas et populations), et produire en sortie une description unifie des schmas initiaux (le schma intgr) et les rgles de traduction (mapping) qui vont permettre l'accs aux donnes existantes partir du schma intgr. L'intgration de bases de donnes est un problme complexe. Un nombre considrable d'articles en ont tudi diffrents aspects: il en rsulte une multitude de contributions techniques, quelques mthodologies et quelques prototypes. Le but de cet article est de donner une image claire de ces approches, de montrer ce que les solutions actuelles peuvent raliser et de cerner le travail restant faire. Nous nous focalisons sur les concepts, le principe des solutions et des alternatives, en laissant de cot les considrations techniques dtailles pour lesquelles nous invitons le lecteur consulter les rfrences. Les arguments sont illustrs sur un exemple acadmique. La prsentation est organise selon la squence chronologique des actions qui composent le processus d'intgration de bases de donnes. Nous identifions trois tapes principales dans ce processus (cf. figure 1): - pr-intgration, une tape dans laquelle les schmas en entre sont transforms de diffrentes manires pour les rendre plus homognes (sur les plans smantique et syntaxique); - recherche des correspondances, une tape consacre l'identification des lments semblables dans les schmas initiaux et la description prcise de ces liens inter-schmas; - intgration, l'tape finale qui unifie les types en correspondance en un schma intgr et produit les rgles de traduction associes entre le schma intgr et les schmas initiaux. L'article se termine par une discussion des aspects mthodologiques et des indications sur les directions de travail poursuivre.

Ingnierie des sytmes d'information Vol.4, N3, 1996

schmas initiaux

transformation des schmas

rgles

recherche des correspondances correspondances inter-schmas intgration des schmas

rgles

Administrateur

rgles

schma intgr + mappings Figure 1. Le processus global d'intgration 2. L'exemple L'exemple que nous allons utiliser concerne l'intgration des bases de deux bibliothques d'informatique. La premire bibliothque (schma S1) utilise un modle entit-relation tendu. Cette base contient les donnes sur les articles paru dans des revues ou des confrences. Un objet gnrique "Publication" reprsente soit un numro d'une revue (par exemple, CACM avril 1994) soit les actes d'une confrence (par exemple, VLDB 1993). La deuxime bibliothque (schma S2) utilise un modle orient-objets et s'intresse uniquement aux articles publis lors de confrences. Il y a un objet par type de confrence (par exemple, VLDB). Les actes des confrences (VLDB 1993, VLDB 1994, ) sont reprsents par un attribut multivalu (une valeur par anne), o chaque valeur contient un ensemble de rfrences aux articles publis cette anne-l dans cette confrence. Un accord entre les deux bibliothques nous permet d'assurer que les deux bases de donnes enregistrent les mmes confrences.

Ingnierie des sytmes d'information Vol.4, N3, 1996

S1 (ER) Auteur Ecrit Article Contient Publication Vol. N. Revue ISN nom anne titre mots-cls nom affiliation titre

S2 (OO) Article mots-cls auteurs nom prnoms Confrence nom domaine N. eds lieu actes

ISN anne Narticles

Confrence

Chaque publication est dcrite par des proprits gnriques: ISN (International Standard Number, dont le domaine est l'ensemble des nombres ISSN et ISBN), nom, anne. Les actes des confrences ont un lieu, des diteurs et un numro d'ordre (20, 21, ). Chaque publication contient au moins un article, et chaque article enregistr appartient au moins une publication. Les dessin des lignes reprsente les cardinalits: une ligne continue signifie une cardinalit 1:1 (obligatoire et monovalu), une ligne double pointille signifie une cardinalit 0:n (optionnel et multivalu), une ligne double mixte signifie une cardinalit 1:n (obligatoire et multivalu). Les flches paisses reprsentent les liens de gnralisation/spcialisation, les flches fines reprsentent une rfrence un objet.

Figure 2. L'exemple des bibliothques 3. L'tape de pr-intgration Dans la plupart des cas, les bases de donnes intgrer auront t dveloppes indpendamment et seront par consquent htrognes. La diffrence la plus vidente est lorsque les bases de donnes existantes ont t installes avec des SGBD utilisant des modles de donnes diffrents (relationnel, CODASYL, orient- objets, ...). Mais, mme en admettant que toutes les bases de donnes soient converties dans un mme modle, des diffrences subsisteront dans la richesse de la description obtenue. En effet, certains modles de donnes possdent dans leurs concepts plus de smantique que d'autres modles. Par exemple, un schma entit-association utilise des concepts spars pour les entits et pour les associations, tandis que le schma relationnel quivalent va dcrire les mmes donnes sans faire de distinction explicite entre entits et associations. Pour parvenir un mme niveau de comprhension des deux schmas, on doit tre mme d'identifier, dans le schma relationnel, quelles relations dcrivent des entits et quelles relations dcrivent des associations. Une autre cause d'htrognit rside dans le non-dterminisme du processus de modlisation. Deux concepteurs qui doivent reprsenter la mme ralit avec le mme modle de donnes vont invitablement crer deux schmas diffrents. Nous discutons ci-dessous des manires d'aborder ces trois problmes.

3.1. Htrognit des modles de donnes Le problme ici est la transformation des structures de donnes et des oprations d'un SGBD dans les structures de donnes et oprations d'un autre SGBD. La grande majorit des chercheurs en intgration supposent que les schmas initiaux sont tous exprims dans un mme modle de donnes, appel modle commun, sur lequel le logiciel d'intgration est construit. L'tape de traduction devient un pr-requis indispensable l'intgration et est traite comme un problme part. Les traductions requises sont celles entre les modles de donnes locaux et le modle commun. Malheureusement, il existe peu d'outils
Ingnierie des sytmes d'information Vol.4, N3, 1996 4

capables d'effectuer ces traductions automatiquement (sauf pour passer d'un schma entit-association un schma relationnel). Les dveloppements en cours se focalisent sur les traductions entre modles orient-objets et relationnel. Seuls quelques chercheurs ont aussi tudi le problme complmentaire de la traduction des oprations. Ceci est pourtant indispensable pour obtenir un systme totalement polyglotte, c'est dire un systme dans lequel chaque participant parle son propre langage. L'un des points non rsolus reste le choix du modle de donnes commun. Typiquement, deux choix ont leurs partisans. La majorit prfre actuellement l'approche orient-objets car elle possde tout les concepts smantiques des autres modles et que des mthodes peuvent tre utilises pour implanter des rgles de traduction spcifiques. Le problme est de trouver lequel des nombreux modles orient-objets existants est le meilleur dans ce rle. Un second problme est que plus un modle est riche en concepts, plus le processus d'intgration sera complexe puisqu'il devra rsoudre les nombreuses divergences dues aux diffrents choix de modlisation faits par les divers concepteurs. Pour rendre l'intgration plus simple, l'alternative est de choisir un modle de donnes avec un minimum de smantique, o la reprsentation des donnes est assure par des faits lmentaires pour lesquels il n'y a pas d'alternative de modlisation. Les modles binaires sont alors les meilleurs candidats comme modle commun. Plusieurs chercheurs tudient la spcification d'outils gnriques, capables de raliser n'importe quelle traduction. Les outils traditionnels mettent en oeuvre des algorithmes spcifiques traduisant des schmas exprims dans un modle Mi en des schmas exprims dans le modle commun MC (et vice versa). Ajouter un nouveau modle de donnes Mj la fdration signifie ajouter deux nouveaux algorithmes: Mj MC et MC Mj. Les approches gnriques utilisent un mta-modle (i.e. un modle adapt la description des modles de donnes) comme pivot pour les traductions [URB 91]. Le mta-modle connat tout les concepts de modlisation et sait comment transformer des structures de donnes entre elles (par exemple, comment combiner des tuples plats pour obtenir des tuples imbriqus). Ajouter un nouveau modle Mj signifie dans ce cas dcrire les concepts de Mj avec les concepts du mta-modle. Par exemple, une relation du modle relationnel sera dcrite comme un tuple plat d'attributs valeurs atomiques. Traduire un schma d'un modle Mi dans un modle Mj se ramne un processus de restructuration de donnes l'intrieur de la base de donnes du mta-modle. 3.2. Htrognit des puissances d'expression Les traductions soulvent des problmes difficiles et il est peu probable qu'elles puissent tre totalement automatises. En effet, les modles de donnes ne peuvent exprimer toute la smantique du monde rel. L'incompltude de leurs spcifications conduit des ambiguts sur l'interprtation d'un schma. Des interactions avec les administrateurs de donnes sont ncessaires pour rsoudre ces ambiguts, et acqurir ainsi des informations supplmentaires sur la smantique d'un schma: ce processus est appel enrichissement smantique. Des problmes importants surviennent lorsqu'il s'agit de comprendre un schma pauvre en smantique. Le cas le plus difficile se prsente lorsque les donnes sont dans des fichiers, mais les bases de donnes relationnelles posent galement un srieux dfi pour leur r-interprtation avec des concepts plus sophistiqus (par exemple, avec les concepts orient-objets). Des techniques de rtro-ingnirie sont actuellement ltude pour permettre de distinguer parmi les relations d'un schma celles qui reprsentent des objets et leurs attributs (et les regrouper), celles qui reprsentent des liens d'association, et celles qui reprsentent des liens de gnralisation/spcialisation. Ce processus d'analyse se base sur toutes les informations que peut donner le schma: cls primaires, cls candidates, cls externes et dpendances. Mais les anciens systmes relationnels mmorisent uniquement la description des relations et de leurs attributs, sans aucune autre indication. De plus, les relations dans les bases de donnes existantes ne sont pas ncessairement normalises. Les techniques de rtro-ingnirie doivent deviner l'information sur les cls et sur les dpendances partir de l'analyse du schma, mais aussi des index, des requtes et des occurrences. Les hypothses formules doivent tre confirmes par l'administrateur. Par exemple, des conditions de jointure dans les requtes peuvent indiquer, mais non affirmer, l'existence d'une cl externe; l'utilisation de la clause DISTINCT dans une requte SQL peut conduire la conclusion que l'attribut extrait n'est pas une cl primaire [AND 94]. L'enrichissement smantique est typiquement un processus de dcision humain, utilis pour fournir plus d'information soit sur la manire dont un schma dcrit la ralit, soit sur le schma lui-mme. Un
Ingnierie des sytmes d'information Vol.4, N3, 1996 5

exemple du premier type denrichissement est la dfinition explicite de la smantique d'un objet: par exemple, dfinir "Employ" comme "les personnes qui ont un contrat de travail en cours avec lentreprise". Un exemple du second type est de spcifier que l'attribut "directeur" dans la relation "Dpartement" est une cl externe vers la relation "Employ". L'enrichissement smantique n'est pas spcifique au modle relationnel. On peut aussi avoir besoin dtendre des schmas orient-objets avec des informations sur les cardinalits ou sur les dpendances (qui ne sont pas reprsentes mais sont ncessaires, par exemple pour une traduction correcte des attributs multivalus). De mme, la ringnirie dun schma orient-objets peut promouvoir un attribut en un objet; la question qui se pose immdiatement est de savoir si deux valeurs identiques de cet attribut doivent tre traduites en un seul objet ou en deux objets. La dcision ne peut pas tre automatique, car la rponse dpend de la smantique du monde rel. 3.3. Htrognit des modlisations Comme nous l'avons crit prcdemment, le processus de modlisation n'est pas dterministe. Ce relativisme smantique (i.e. les schmas dpendent du point de vue du concepteur) est le prix payer pour la richesse smantique du modle de donnes. Les diffrences peuvent nanmoins tre rduites, au niveau de l'organisation en imposant des rgles de modlisation (y compris des rgles terminologiques), et au niveau technique en appliquant des rgles de normalisation. Ces dernires sont bien connues dans le contexte relationnel, mais doivent encore tre labores pour les bases de donnes orient-objets. On peut dfinir deux familles de rgles de normalisation. La premire vise imposer des rgles de conception, par exemple: - un type avec un attribut optionnel doit tre remplac par une structure supertype/sous-type o le sous-type contient ncessairement cet attribut; - un attribut multivalu doit tre remplac par un objet dsign par un attribut rfrence; - un type avec un attribut dont le domaine est numr (par exemple, sexe) doit tre remplac par une structure supertype/sous-types. Ces rgles imposent une normalisation syntaxique, en ignorant les aspects smantiques. L'autre famille de rgles met le schma en conformit avec les dpendances sous-jacentes. Ceci ressemble la normalisation relationnelle, mais en diffre par le but vis. Les formes normales relationnelles ont pour but de rduire la duplication de donnes afin d'viter les anomalies de mise jour. Les formes normales orient-objets auxquelles nous nous rfrons visent enrichir la smantique d'un schma. Un exemple d'une rgle de ce type est: s'il existe une dpendance entre deux attributs A et B d'un type d'objet, et que A n'est pas une cl, remplacer ces attributs par un attribut complexe (tuple) compos de A et B. Ces rgles de normalisation orient-objets ne sont pas encore mures, et il reste du travail faire avant d'arriver un consensus. 4. L'tape d'identification des correspondances Lorsque les schmas initiaux ont atteint le niveau de conformit souhait, l'tape suivante consiste identifier les lments communs des bases existantes. Les bases de donnes contiennent des reprsentations d'objets du monde rel, avec leurs liens et leurs proprits. L'intgration de bases de donnes, toutefois, dpasse les reprsentations, pour considrer en premier lieu ce qui est reprsent plutt que comment il est reprsent. Par exemple, nous voulons savoir si Arthur Durand, reprsent dans la base A, est aussi reprsent dans la base B, mme si les deux occurrences possdent des attributs compltement diffrents. Par consquent, nous disons que deux bases de donnes ont quelque chose ont commun si les portions de monde rel qu'elles reprsentent ont des lments communs (i.e. une intersection non vide), ou ont des lments en relation entre eux par un lien d'intrt pour des applications futures. Ce dernier cas est, par exemple, celui d'une entreprise multi-filiales o la bases de donnes de chaque filiale enregistre les employs de la filiale et o l'on voudrait dans la base de donnes intgre voir un type d'objet Employ reprsentant la population globale des employs de toutes les filiales. Nous disons que deux lments (occurrence, valeur, tuple, ) de deux bases de donnes sont e n correspondance s'ils dcrivent le mme lment du monde rel (objet, lien ou proprit). A chaque fois que cela est possible, les correspondances sont dfinies, non en extension (au niveau des donnes, par exemple: l'article <Intgration de bases de donnes> de S2 correspond l'article <Intgration de bases de
Ingnierie des sytmes d'information Vol.4, N3, 1996 6

donnes> de S1), mais en intention (au niveau du type, par exemple: chaque article de S2 correspond

l'article de S1 qui a le mme titre). La dfinition intentionnelle d'une correspondance est appele une assertion de correspondance inter-schmas . Le processus d'intgration consiste trouver ces correspondances entre les lments des bases de donnes existantes et pour chaque correspondance offrir aux utilisateurs de la base fdre un lment global virtuel (non matrialis) qui inclut toutes les informations utilisables sur cet lment. La base fdre enregistre uniquement la dfinition de l'lment global et des rgles de traduction entre l'lment global et ses correspondants locaux. Ces rgles font partie du rsultat du processus d'intgration. Les spcifications suivantes doivent tre fournies pour dfinir compltement une assertion de correspondance inter-schmas: a/ quels sont les lments en correspondance b/ comment leurs extensions sont lies c/ comment les instances correspondantes sont identifies dans les extensions d/ comment leurs reprsentations sont lies. Ci-dessous, nous examinons chaque aspect en dtail. a/ quels sont les lments en correspondance

Les lments en correspondence peuvent tre soit des occurrences ou des valeurs (par exemple les auteurs, les articles), soit des chemins reliant des occurrences et/ou des valeurs (par exemple le chemin liant un auteur et les articles qu'il a crit). Dans le premier cas, les lments lis sont simplement dsigns par leurs noms qualifis. Par exemple, une assertion peut relier S1.Auteur S2.Article.auteurs, puisque les deux lments reprsentent des personnes qui ont crit un article. Dans le second cas, les chemins sont nots en numrant les lments qu'ils traversent. Par exemple, une assertion relie S1.(Auteur-Ecrit-Article) S2.(auteurs-Article) pour spcifier que ces deux chemins ont la mme smantique. Ce qui signifie que, si dans S1 l'auteur X a crit l'article Y et si X et Y appartiennent aussi S2, alors dans S2 la valeur X apparat dans l'attribut auteurs de l'Article Y. Dans notre exemple, seuls les articles de S1 qui sont publis dans une confrence apparaissent dans S2. Une dfinition prcise de l'assertion ncessite une spcification prcise du sous-ensemble d'articles concerns. Cette spcification peut tre faite au moyen d'expressions algbriques: dans ce cas particulier l'oprateur de slection convient. L'assertion est alors dcrite comme suit: ["est un article contenu dans une Publication de type Confrence"] S1.Article S2.Article Les expressions utilises peuvent inclure des oprateurs plus complexes (union, jointure, ) pour identifier l'ensemble des objets communs deux schmas diffrents. Cette situation est appele un conflit de fragmentation [DUP 94]. b/ comment leurs extensions potentielles sont lies Pour construire le schma intgr, la relation entre les extensions des lments, dans le monde rel, doit tre connue. Etant donn que les extensions sont considres comme tant des ensembles d'objets du monde rel, chaque assertion dcrit la relation ensembliste pertinente: quivalence ( ), inclusion ( ), intersection () ou disjonction () des deux ensembles. Dans l'exemple, on a: S1.Article S2.Article puisque tous les articles reprsents dans S2 le sont dans S1 et que la rciproque est fausse. D'un autre cot, on a: S1.Confrence S2.Confrence.actes parce que les deux lments reprsentent le mme ensemble de confrences malgr le fait que leurs reprsentations sont structures diffremment dans les deux bases de donnes. c/ comment les instances en correspondance sont identifies. Quand l'utilisateur cherche accder un objet via le schma intgr, le systme peut avoir accder certaines de ses proprits dans une base de donnes et d'autres dans une autre base. Le systme doit donc savoir trouver dans une base l'objet (occurrence ou valeur) correspondant un objet donn (occurrence ou valeur) d'une autre base. Pour ce faire, chaque assertion doit comprendre une clause de spcification de la correspondance entre instances: nous appelons ceci la clause "Avec Identifiants

Ingnierie des sytmes d'information Vol.4, N3, 1996

Correspondants" (AIC). Dans l'exemple, en supposant qu'il n'y ait pas d'homonymie dans les titres des articles, cela donne: S1.Article S2.Article AIC titre qui spcifie que les articles des deux bases de donnes ont un identifiant commun, l'attribut titre. C'est le cas le plus simple. Dans le cas gnral une clause AIC requiert pour chaque base de donnes un prdicat spcifiant les valeurs/occurrences en correspondance. d/ comment les reprsentations sont lies Les reprsentations des lments en correspondance possdent gnralement des proprits communes, au del de celles utilises pour leur identification. S1.Confrence et S2.Confrence.actes, par exemple, partagent, en plus de l'identifiant ISN, les proprits anne et N. Pour viter la duplication des proprits dans le schma intgr, des assertions dcrivent de telles correspondances en utilisant une clause "Avec Attributs Correspondants" (AAC). Ainsi, l'assertion de correspondance interschma s'crit: S1.Confrence S2.Confrence.actes AIC ISN AAC anne, N Le format gnral pour dcrire une correspondance entre deux proprits A and B est: f(A) R g(B), o R est une relation ensembliste (, , , ) et f et g sont deux fonctions utilises, si ncessaire, pour rsoudre un conflit de reprsentation. La smantique de la clause AAC est que, si X et Y sont les lments vrifiant l'assertion de correspondance, les ensembles de valeurs X.A and Y.B (ventuellement convertis par les fonctions f et g, respectivement) sont lis par la relation R. 4.1. Cohrence des correspondances tant donn un ensemble d'assertions entre deux bases de donnes, il convient de tester s'il est cohrent et minimum. Supposons, par exemple, qu'un schma contienne un lien de gnralisation entre A et B (A est-un B) et que l'autre contienne un lien de mme type entre C et D (C est-un D). Un exemple d'assertions de correspondance incohrentes est: A D, B C. Les deux ne peuvent tre simultanment vraies. Certaines assertions sont dductibles d'autres. Par exemple, si, pour les mmes schmas, la correspondance A C est dclare, les correspondances B C et D A peuvent alors tre dduites. Aussi, seules les assertions qui expriment des correspondances non drivables doivent tre explicites. Un ensemble appropri d'assertions pour l'exemple des bibliothques est dcrit en figure 3. La figure 4 dcrit le schma intgr construit en prenant en compte ces assertions. Correspondances S1 / S2 : Auteur auteurs AIC nom Article Article AIC titre AAC mots-cls Confrence actes AIC ISN AAC anne, N Publication.nom Confrence AIC nom AuteurEcritArticle auteursArticle ConfrencePublicationContientArticle actesarticles:Article Publication.nomPublicationConfrence Confrenceactes

1 2 3 4 5 6 7

Figure 3. L'ensemble des assertions de correspondance pour l'exemple bibliothques

Ingnierie des sytmes d'information Vol.4, N3, 1996

Auteur nom prnoms affiliation articles

inv

Article titre mots-cls dans auteurs

inv

Publication ISN anne articles

Revue Vol N nom N eds

Acte lieu confrence

inv

Confrence nom domaine actes

Figure 4. Un schma intgr orient-objets pour l'exemple bibliothques 4.2. Recherche des correspondances Dans les cas o l'intgration porte sur un nombre important de schmas, comme dans les cas de schmas avec un nombre important de types d'objets, l'identification de toutes les correspondances utiles est loin d'tre triviale. Des efforts significatifs ont t faits pour dfinir des outils pour l'identification automatique des correspondances plausibles [GOT 92]. Ces outils mesurent la similitude entre deux lments de schmas en recherchant des caractristiques identiques ou similaires: noms, identifiants, composants, proprits, attributs (noms, domaines, contraintes), mthodes. Le calcul du taux des similitudes par rapport aux divergences donne une valuation de la probabilit d'une correspondance. L'tape finale est l'interaction avec l'administrateur des donnes pour confirmer ou infirmer les correspondances et pour obtenir les informations ncessaires la dfinition complte des assertions (en particulier les relations ensemblistes entre les extensions). La plupart des outils n'analysent que les aspects syntaxiques et structurels, et sont par consquent confronts aux problmes usuels des synonymes et homonymes. Pour limiter ces problmes certains outils ont recours des bases terminologiques qui permettent de dcrire les termes utiliss dans le domaine de l'application et les liens qui peuvent exister entre eux [FAN 92]. 5. Les conflits: taxonomie et solutions Une fois que les correspondances ont t dcrites, l'intgration proprement dite peut commencer. Chaque assertion est analyse pour dterminer quelle est la reprsentation des lments en correspondance qui doit tre incluse dans le schma intgr et pour dfinir quelles sont les rgles de traduction entre le schma intgr et les schmas initiaux. Ces rgles seront utilises par l'valuateur de requtes fdres pour transformer chaque requte dfinie sur le schma intgr en un ensemble de
Ingnierie des sytmes d'information Vol.4, N3, 1996 9

requtes locales qui sont soumises aux SGBD locaux pour rcuprer toutes les informations locales qui permettent de construire l'information souhaite. Lorsqu'une assertion dcrit les types en correspondance comme tant identiques (i.e. ils ont la mme reprsentation et des populations quivalentes) leur intgration est vidente: le type intgr est identique aux types en entre et le mapping est l'identit. C'est une simple rplication du type. La plupart du temps, toutefois, les types en correspondance vont prsenter des diffrences, que ce soit dans leurs reprsentations ou dans leurs populations. Cette situation est appele un conflit. Plusieurs taxonomies des conflits on t proposes. Une taxonomie particulirement dtaille peut tre trouve dans [SET 92]. Pour cet article nous utilisons une version plus simple, dcrite dans la table 1. Table 1 Une taxonomie des conflits entre deux types en correspondance Classification Description Structure Htrognit Mta-donnes Donnes les populations du monde rel reprsentes par les deux types sont diffrentes les types ont des ensembles diffrents de proprits et/ou leurs proprits sont reprsentes de manire diffrente. les concepts utiliss pour dcrire les types sont diffrents les modles de donnes utiliss sont diffrents la correspondance relie un type un mta-type (un ensemble de noms de types) des instances en correspondance ont des valeurs diffrentes pour des proprits en correspondance.

Beaucoup de propositions ont t faites pour la rsolution des conflits de classification et de description [KIM 93]. Les conflits de mta-donnes ont t abords plus rcemment, notamment par [SAL 92]. Les conflits de structure, d'htrognit et de donnes ont fait l'objet de quelques travaux [SPA 91, SHE 94]. Il n'existe pas de mthode d'intgration complte qui rsolve chaque type de conflit, encore moins de mthode qui puisse tre automatise. Ci-aprs, nous discutons brivement les diffrents types de conflits, indiquant les solutions existantes et les problmes non rsolus. Une autre faiblesse de la recherche actuelle est de ne pas spcifier explicitement le but prcis recherch dans cette tape d'intgration proprement dite. Il existe, en effet, plusieurs objectifs possibles, produisant des rsultats sensiblement diffrents. Par exemple, on peut rechercher la simplicit, et donc produire un schma intgr avec un nombre minimal de types d'objets, de faon ce que le schma reste lisible avec un effort raisonnable. On peut rechercher la compltude, au sens o chaque lment des schmas initiaux apparat dans le schma intgr. Ceci permet aux administrateurs locaux de retrouver facilement leurs donnes dans le schma rsultat, et facilite la mise jour lorsque les schmas des bases locales voluent. On peut aussi vouloir tre exhaustif, en faisant apparatre dans le rsultat tous les types d'objets drivables partir des types initiaux (ceux qui existent localement et ceux que l'on peut en dduire par leur intersection/union). Ceci alourdit le schma intgr mais, inversement, prpare l'intgration de nouvelles bases de donnes qui viendraient s'ajouter la fdration existante. 5.1. Conflits de classification On a un conflit de classification lorsque les types en correspondance dcrivent des ensembles diffrents, mais smantiquement lis, d'lments du monde rel. Dans l'exemple des bibliothques, S1 dcrit les articles de revues et confrences, alors que S2 ne dcrit que les articles de confrences. Un conflit de classification se traduit dans une assertion par l'utilisation d'une relation ensembliste autre que l'quivalence ( , , ). Une solution standard pour ces conflits est d'inclure dans le schma intgr la hirarchie de gnralisation/spcialisation approprie, telle que dcrite dans la table 2 [LAR 89, GOT 92]. Cette solution vise l'objectif de compltude: les types initiaux sont copis dans le schma intgr et relis par des liens IS-A. Si ncessaire, un sous type (ou supertype) commun est ajout pour raliser la connectivit de la hirarchie de gnralisation/spcialisation. Ceci a pour effet de rduire les traductions entre schma intgr et schmas initiaux des simples fonctions d'identit.

Ingnierie des sytmes d'information Vol.4, N3, 1996

10

Une solution diffrente, base sur l'objectif de simplicit, est d'insrer dans le schma intgr un seul type d'objet (voir table 2b Technique de fusion). Le schma intgr dcrit alors l'union des extensions. Les rgles de traduction utilisent l'oprateur de slection pour driver les populations initiales de la population globale. Enfin, l'objectif oppos, savoir crer un schma exhaustif (voir table 2b Technique exhaustive), conduit inclure dans le schma intgr les types initiaux, plus leur union (un super-type) ainsi que leur intersection et les complments de l'intersection (trois sous-types).
Table 2: Rsolution des conflits de classification Conflit E1 E1 E2 E2 E1 E2 E1 E1 E2 E2 ou E1 E2 E1 E1 E2 E1 E2 E1 E2 E2 Schma intgr

E1 E2

2a: la solution standard: prservation des types locaux Schma intgr Conflit Technique de fusion E1 E2 E1 E2 E1 E2 E1 E2 E1 E2 E1 E1 E2 E1 E2 E1 E2 2b: autres solutions E1 E2 E2 E2 E1 Technique exhaustive E1 E1 E2

Les stratgies pour les conflits de classification ont parfois t tendues l'intgration de hirarchies de gnralisation mises en correspondance par plusieurs assertions. Les deux hirarchies sont fusionnes en dterminant, pour chaque classe d'une hirarchie, la place que cette classe doit prendre dans l'autre hirarchie. Le placement est bas sur la smantique d'inclusion des populations [MAN 88, RED 94]. Il est par contre bas sur la smantique d'hritage dans les mthodologies d'intgration de vues (o il n'existe pas de populations intgrer). Le processus de placement obtient de meilleurs rsultats si l'on connat les critres de spcialisation des sous-classes existants dans les schmas initiaux.
Ingnierie des sytmes d'information Vol.4, N3, 1996 11

5.2. Conflits structurels Un conflit structurel survient lorsque les lments en correspondance sont dcrits par des concepts de niveaux de reprsentation diffrents ou soumis des contraintes diffrentes: par exemple, une classe d'objets et un attribut, ou un type d'entit et un type d'association. Dans l'exemple des bibliothques, l'assertion sur les auteurs et celle sur les confrences montrent des conflits structurels. Ce type de conflit a t peu tudi dans la littrature et uniquement pour des modles de donnes particuliers [KIM 93, SHO 91]. La solution des conflits structurels [SPA 91] part du principe que le schma intgr doit pouvoir dcrire la population des deux lments en conflit. L'lment intgr doit donc reflter les possibilits des lments initiaux: en termes de capacit dcrire l'information (pour laquelle on adopte la borne suprieure minimale) mais aussi en termes des contraintes implicites et explicites attaches aux lments (en adoptant la borne infrieure maximale). La capacit d'un concept nous dit quelle combinaison de identit/valeur/liens le concept modlise. Par exemple, un attribut dans les modles orient-objets et relationnel modlise soit une valeur soit un lien, mais un attribut dans un modle entit-association modlise uniquement une valeur. Une relation du modle relationnel modlise une valeur et ventuellement des liens (par les cls externes), mais pas l'identit. Si une assertion entre schmas relationnels met en correspondance une relation (valeur+liens) et un attribut (valeur ou lien), l'lment correspondant dans le schma intgr sera une relation. Parmi les contraintes prendre en compte, on trouve typiquement les contraintes de cardinalit et les dpendances d'existence. Par exemple, l'existence d'un attribut dpend de celle de son propritaire, mais un objet n'est pas, en gnral, soumis des contraintes d'existence. Si, comme c'est le cas pour les auteurs dans notre exemple, une assertion met en correspondance une classe d'objets (S1.Auteur) avec un attribut (S2.Article.auteurs), c'est la classe qui est inscrite dans le schma intgr (la borne infrieure maximale est dans ce cas l'absence de contraintes). La table 3 montre le concept choisir pour le schma intgr en fonction du type de conflit structurel. Les conflits structurels peuvent tre plus complexes que ceux montrs dans cette table. Ils peuvent, par exemple, faire appel des expressions de jointure [KIM 93, DUP 94]. Une solution gnrale reste trouver.

Ingnierie des sytmes d'information Vol.4, N3, 1996

12

Table 3: Solutions pour les conflits structurels cas Schma1 Schma2 T1 1 T0 T0 T1 T1 T1 2 T0 T2 T2 T1 3 T2 T1 4 T2 T0 T3 T0 0 T2 T1 T0 T1 T0 T2 T0 T3 T1 T0 T0 T0 Schma intgr T0

Ces diagrammes sont exprims sur la base d'un modle de donnes gnrique, o: reprsente un type d'objet (classe, type d'entit, relation, ou type d'article) reprsente une relation entre types d'objets (attribut rfrence, type de relation, cl externe, ou set CODASYL ) reprsente un attribut reprsente une assertion de correspondance de type quivalence

Ingnierie des sytmes d'information Vol.4, N3, 1996

13

5.3. Conflits Descriptifs Un conflit descriptif survient ds qu'il y a une diffrence entre les proprits des types en correspondance. Ces conflits ont t abondamment tudis [LAR 89, KIM 93], soit pour proposer une rsolution automatique soit pour guider un intgrateur humain. La table 4 rsume plusieurs taxonomies existantes. Table 4: Conflits descriptifs 1. Les types d'objets en correspondance peuvent diffrer selon leurs: - noms: - cls: - attributs: homonymes et synonymes cl primaire ou cls candidates diffrentes les ensembles d'attributs sont diffrents des attributs en correspondance sont en conflit (voir point 2) - mthodes: les ensembles de mthodes sont diffrents des mthodes en correspondance diffrent (voir point 3) - contraintes d'intgrit - droits d'accs 2. Les attributs en correspondance peuvent diffrer selon leurs: - noms: - portes: homonymes et synonymes locale une base de donnes ou globale (i.e., conserve sa signification dans la base intgre) - structures: - simple ou complexe (i.e. compose d'autres attributs) - cardinalits: monovalu ou multivalu, facultatif ou obligatoire - constructeurs multivalus diffrents (ensemble, multi-ensemble, liste, tableau) - types de donnes: diffrentes chelles, units, valeurs par dfaut, oprations - contraintes d'intgrit - droits d'accs 3. Les mthodes en correspondance peuvent diffrer selon leurs: - noms: - signatures: homonymes et synonymes nombre de paramtres, types de paramtres, rsultats

Les solutions traditionnelles sont: - conflit de nom: renommer en utilisant l'un des noms (en cas de synonyme) ou en utilisant un prfixe (en cas d'homonyme). Le prfixe est gnralement le nom de la base de donnes source. - conflit de type de donnes: une fonction de conversion est utilise pour passer du domaine d'un attribut au domaine de l'autre attribut. - conflit de cl: une fonction de conversion est utilise pour associer chaque valeur d'une cl une valeur de l'autre cl. La fonction doit tre une application bijective (1-1) pour tre oprationnelle. - contraintes d'intgrit: utiliser l'approche de la borne infrieure maximale. - structures d'attributs: aucune solution vraiment disponible. Les mthodologies actuelles traitent les attributs simples monovalus, rarement les attributs multivalus [LAR 89], et ignorent les attributs complexes (i.e. les attributs composs d'autres attributs). 5.4. Conflits d'htrognit des modle de donnes Les mthodologies d'intgration actuelles sont monomodle. Elles n'intgrent que des schmas qui sont exprims dans leur propre modle de donnes. Comme nous l'avons dit prcdemment, les schmas qui ne sont pas exprims dans ce modle de donnes doivent tre traduits pendant la phase de printgration, avant d'tre pris en considration pour l'intgration.
Ingnierie des sytmes d'information Vol.4, N3, 1996 14

Une approche diffrents a t propose dans [SPA 91]. Les auteurs montrent que les problmes et les solutions pour chaque type de conflit sont la base les mmes quelque soit le modle de donnes. Il devrait ainsi tre possible d'identifier l'ensemble des rgles d'intgration fondamentales qui sont ncessaires et de dfinir, pour chaque modle de donnes spcifique, comment chaque rgle s'applique en reformulant la rgle selon les particularits du modle considr. On peut alors construire un outil capable d'assurer directement l'intgration de schmas htrognes et de produire un schma intgr dans n'importe quel modle. Les logiques d'ordre suprieur ont aussi t proposes comme formalismes capables de rsoudre tous les types de conflits, y compris d'htrognit [LAK 93]. Un langage de ce type permet l'utilisateur de dfinir lui-mme le schma intgr partir des schmas initiaux htrognes sans avoir les traduire. 5.5. Conflits donnes/mta-donnes Les conflits de ce type surviennent lorsqu'une donne dans une base est en correspondance avec une mta-donne (le nom d'un type) dans le schma d'une autre base. Ces conflits ont t illustrs en utilisant un exemple relationnel de gestion de bourse (figure 5), dans lequel une valeur pour action dans BD1 correspond un nom d'attribut dans BD2 et un nom de relation dans BD3.

BD1: Cours ( date , 951001 951002 ........... 951001 951002 ........... BD2: Cours ( date , 951001 951002 ..........

action , cotation ) IBM 77.72 IBM 79.23 ........ ......... HP 60.02 HP 61.45 ........ ......... IBM , 77.72 79.23 ........ HP , 60.02 61.45 ........ ... ) ... ... ... cotation) 60.02 61.45 ........... .......

BD3: IBM ( date , cotation) 951001 77.72 951002 79.23 ........... ........

HP ( date , 951001 951002 .........

Figure 5. Un exemple de conflit donnes/mta-donnes Les langages relationnels traditionnels ne peuvent pas transformer un nom d'attribut ou de relation en valeur, et vice versa. Avec ces langages, on peut facilement passer de BD2 BD3 et inversement, de mme que l'on passe de BD1 BD2 ou BD3. Par contre on ne peut pas passer de BD2 ou BD3 BD1. Ces conflits peuvent tre rsolus si le langage de correspondance permet la manipulation simultane des donnes et des mta-donnes. L'algbre relationnelle tendue de [SAL 92] et la logique d'ordre suprieure de [LAK 93] sont des exemples de tels langages. Ces conflits peuvent aussi tre limins en utilisant un modle de donnes qui ne permet pas de donner des noms significatifs aux lments d'un schma [MIL 93]. Plus probablement, les approches orient-objets fourniront des oprations de transformation de schma pour effectuer toutes les mises en correspondance ncessaires, en particulier partitionner une classe en sous-classes selon la valeur d'un attribut discriminant (passage de BD1 BD3), crer une super-classe commune plusieurs classes avec un nouvel attribut discriminant (passage de BD3 BD1), etc.

Ingnierie des sytmes d'information Vol.4, N3, 1996

15

5.6. Conflits de donnes Ce dernier type de conflit survient au niveau des instances lorsque des occurrences en correspondance ont des valeurs en conflit pour des attributs en correspondance. Par exemple, un mme article est stock dans les deux bases de donnes des bibliothques avec des mots cls diffrents. Les causes d'un conflit de donnes peuvent tre: erreurs de saisie, sources d'information diffrentes, versions diffrentes, mises jours diffres, etc. Les conflits de donnes sont normalement dtects lors de l'excution d'une requte d'accs aux donnes. Le systme peut se contenter de signaler l'erreur l'utilisateur, mais il peut aussi appliquer une heuristique pour produire une valeur approprie. Les heuristiques courantes sont: choisir la valeur dans la base qui est la plus "crdible", unifier les valeurs en conflit d'une certaine faon (agrgation des valeurs simples, union des ensembles de valeurs). Une autre possibilit est de fournir aux utilisateurs un langage pour manipuler eux-mmes toutes les valeurs candidates, l'ensemble des valeurs possibles tant la rponse la requte chaque fois que le conflit survient [TSE 93]. 6. Stratgies d'intgration Nous avons jusqu' prsent analys les principes et les techniques de l'intgration de schmas. Dans ce chapitre nous abordons le problme soulev par la possibilit d'adopter diffrentes stratgies pour diriger le processus d'intgration. Plusieurs choix sont possibles: - manuel ou semi-automatique. Puisque seul l'administrateur connat de faon certaine la smantique des donnes, les stratgies manuelles laissent l'administrateur diriger le processus d'intgration. Ces mthodes fournissent un langage de manipulation de schmas que l'administrateur va utiliser pour construire lui-mme (si le langage est procdural) ou spcifier (si le langage est dclaratif) le schma intgr. Les langages procduraux offrent des primitives de transformation de schma qui permettent de restructurer les schmas initiaux jusqu' ce qu'ils puissent tre fusionns en un seul schma. Le systme gnre automatiquement les rgles de traduction entre les schmas initiaux et le schma intgr [MOT 87]. Les langages dclaratifs sont plus faciles utiliser, mais l'tablissement des rgles de traduction par le systme est plus dlicat. Les stratgies manuelles supposent que l'administrateur sache comment structurer le schma intgr qui doit tre cr. Inversement, les stratgies semiautomatiques ont pour but de construire un outil qui effectue automatiquement l'intgration lorsque les assertions de correspondance ont t dfinies. L'outil dtermine aussi automatiquement les rgles de traduction [SPA 91]. L'administrateur est seulement impliqu dans l'identification des assertions de correspondance, et ventuellement dans le choix de la stratgie d'intgration (voir table 2). - en un coup ou par incrments. Dans les stratgies en un coup, l'intgration est vue comme un processus atomique qui produit un rsultat final. Elles ne se proccupent pas des possibilits d'utilisation des rsultats intermdiaires. Cette vision est mise en dfaut par la complexit des applications relles, pour lesquelles l'intgration peut tre un processus trs long et pnible, alors qu'il est exclu de suspendre l'exploitation des bases en attendant la fin de l'intgration. Les stratgies par incrments permettent d'effectuer graduellement l'intgration tout en continuant utiliser les systmes existants. Elles permettent d'intgrer deux occurrences en correspondance ou deux types en correspondance chaque fois qu'une telle correspondance est dtecte et semble intressante. En d'autre mots, l'intgration peut tre effectue petit petit au fil des jours [SCH 92]. - ex nihilo ou partir d'un thesaurus. La plupart des mthodes d'intgration supposent qu'un nouveau schma intgr est construit directement partir des schmas initiaux. Si une nouvelle base doit tre intgre aprs que le schma intgr ait t construit, le processus est reconduit avec comme schmas initiaux le nouveau schma et le schma intgr existant. Une alternative consiste donner un rle particulier au schma intgr existant, celui de thesaurus de toute la connaissance de l'entreprise. Si des nouvelle bases sont prendre en compte, elles sont utilises uniquement pour enrichir le thesaurus avec les connaissances supplmentaires qu'elles peuvent contenir. En d'autres mots, elles sont absorbes par le thesaurus. En cas de conflit, c'est le thesaurus qui prime sur les nouvelles bases [COL 91].

Ingnierie des sytmes d'information Vol.4, N3, 1996

16

7. Conclusion L'intgration de bases de donnes est certainement une tche complexe. C'est pourtant une tche que les entreprises peuvent difficilement viter si elle veulent mettre en route de nouvelles applications ou rorganiser le systme d'information existant pour une meilleure productivit. Nous avons montr dans cet article que les problmes resoudre sont bien identifiables et que des (voire plusieurs) solutions existent pour nombre d'entre-eux. Nous nous sommes attachs dcrire les concepts et techniques fondamentaux, en insistant sur les alternatives et les critres de choix. Des informations plus dtailles peuvent tre facilement trouves dans la littrature. Bien que la recherche ait t active dans ce domaine depuis vingt ans, avec une croissance significative des efforts ces dernires annes, plusieurs problmes importants doivent encore tre rsolus. A titre d'exemple nous citerons: l'intgration des objets complexes (tels qu'on les trouve dans les bases orientobjets), les correspondances complexes entre plusieurs types (et non plus uniquement entre deux types), la prise en compte des contraintes d'intgrit et des mthodes, l'intgration directe de bases htrognes. Des tudes thoriques sont ncessaires pour valider les rgles d'intgration et leurs proprits (commutativit, associativit, ...). Il est donc important que l'effort pour rsoudre les problmes d'intgration soit poursuivi et que les mthodes proposes puissent tre values lors d'exprimentations avec des applications relles.

Rfrences [AND 94] Andersson M. Extracting an Entity Relationship Schema from a Relational Database Through Reverse Engineering. In Entity-Relationship Approach - ER'94, P. Loucopoulos Ed., LNCS 881, Springer-Verlag, 1994, pp. 403-419 [CER 87] Ceri S., Pelagatti G. Distributed databases: principles & systems. McGraw-Hill, 1987 [COL 91] Collet C., Huhns M.N., Shen W.-M. Resource Integration Using a Large Knowledge Base in Carnot. Computer 24, 12 (Dec. 1991), pp. 55-62 [DUP 94] Dupont Y. Resolving Fragmentation Conflicts in Schema Integration. In Entity-Relationship Approach - ER'94, P. Loucopoulos Ed., LNCS 881, Springer-Verlag, 1994, pp. 513-532 [FAN 92] Fankhauser P., Neuhold E.J. Knowledge based integration of heterogeneous databases. In Proceedings of IFIP DS-5 Conference on Semantics of Interoperable Database Systems (Nov. 16-20. Lorne, Australia), 1992, pp. 150-170 [GOT 92] Gotthard W., Lockemann P.C., Neufeld A. System-Guided View Integration for ObjectOriented Databases, IEEE Transactions on Knowledge and Data Engineering 4 , 1 (Feb. 1992), pp. 122 [KIM 93] Kim W., Choi I., Gala S., Scheevel M. On Resolving Schematic Heterogeneity in Multidatabase Systems, Distributed and Parallel Databases 1, 3, (July 1993), pp. 251-279 [LAK 93] Lakshmanan L.V.S., Sadri F., Subramanian I.N. On the Logical Foundation of Schema Integration and Evolution in Heterogeneous Database Systems. In Deductive and Object-Oriented Databases, Ceri S., Tanaka K., Tsur S. (Eds.), LNCS 760, Springer-Verlag, 1993, pp. 81-100 [LAR 89] Larson J.A., Navathe S.B., Elmasri R. A Theory of Attribute Equivalence in Databases with Application to Schema Integration, IEEE Transactions On Software Engineering 15 , 4, (April 1989), pp. 449-463 [LIT 90] Litwin W., Mark L., Roussopoulos N. Interoperability of multiple autonomous databases, ACM Computer Surveys 22, 3 (Sept. 1990), pp. 267-293
Ingnierie des sytmes d'information Vol.4, N3, 1996 17

[MAN 88] Mannino M.V., Navathe S.B., Effelsberg W. A Rule-Based Approach for Merging Generalization Hierarchies, Information Systems 13, 3, 1988 [MIL 93] Miller R.J., Ioannidis Y.E., Ramakrishnan R. Understanding Schemas. In Proceedings of RIDE-IMS'93 Interoperability in Multidatabase Systems (April 19-20, Vienna, Austria), 1993, pp. 170173 [MOT 87] Motro A. Superviews: Virtual integration of multiple databases, Software Engineering 13 , 7, (July 1987), pp. 785-798 IEEE Transactions On

[RED 94] Reddy M.P., Prasad B.E., Reddy P.G., Gupta A. A Methodology for Integration of Heterogeneous Databases , IEEE Transactions on Knowledge and Data Engineering 6 , 6, (Dec. 1994), pp. 920-933 [SAL 92] Saltor F., Castellanos M.G., Garcia-Solaco M. Overcoming Schematic Discrepancies in Interoperable Databases, In Proceedings of IFIP DS-5 Conference Semantics of Interoperable Databases Systems, (Nov. 16-20. Lorne, Australia), 1992, pp. 184-198 [SCH 92] Scholl M.H., Schek H.-J., Tresch M. Object Algebra and Views for Multi-Objectbases. In Proceedings of International Workshop on Distributed Object Management (August, Edmonton, Canada), 1992 [SHE 90] Sheth A., Larson J. Federated database systems for managing distributed, heterogeneous, and autonomous databases, ACM Computer Surveys 22, 3 (Sept. 1990), pp. 183-236 [SHE 92] Sheth A., Kashyap V. So Far (Schematically) yet So Near (Semantically), In Proceedings of IFIP DS-5 Conference Semantics of Interoperable Databases Systems, (Nov. 16-20. Lorne, Australia), 1992, pp. 272-301 [SHE 94] Sheuermann P., Chong E.I. Role-Based Query Processing in Multidatabase Systems. In Advances in Database Technology - EDBT'94, Jarke M., Bubenko J. Jeffery K. (Eds.), LNCS 779, Springer-Verlag, 1994, pp. 95-108 [SHO 91] Shoval P., Zohn S. Binary-relationship integration methodology. Data & Knowledge Engineering 6, (1991), pp. 225-250 [SPA 91] Spaccapietra S., Parent C., Dupont Y. Model Independent Assertions for Integration of Heterogeneous Schemas. VLDB Journal 1, 1 (July 1992), pp. 81-126 [TSE 93] Tseng F.S.C., Chen A.L.P., Yang W.-P. Answering Heterogeneous Database Queries with Degrees of Uncertainty. Distributed and Parallel Databases 1, (1993), pp. 281-302 [URB 91] Urban S.D. A Semantic Framework for Heterogeneous Database Environments In Proceedings of RIDE-IMS'91 Interoperability in Multidatabase Systems (April 7-9, Kyoto, Japan), 1991, pp. 156-163

Ingnierie des sytmes d'information Vol.4, N3, 1996

18