Intégration des bases de données

L'intégration des données est un sujet de recherche très actif depuis plusieurs années. L'objectif initial, était de pouvoir gérer des données manipulées par des propriétaires et des applications différentes au moyen d'un système centralisé de gestion de bases de données. Des besoins incessants se sont faits sentir par la suite pour regrouper l'ensemble des données qui sont gérées par des SGBDs différents. Les premiers travaux sur les systèmes multibases des données ont été proposés par [48]. Le terme fédération de bases de données a été introduit par la suite afin de décrire des systèmes qui ont pour tâche de fournir un moyen pour pouvoir accéder d'une manière unifiée aux données qui sont stockées dans diverses sources. Depuis la recherche sur les bases de données fédérées est devenue un domaine très actif caractérisé par des techniques permettant un accès intégré à des bases de données distribuées, hétérogènes et autonomes ainsi qu'en témoignent les travaux de Sherth et Larson [81]. Ces auteurs ont effectué une synthèse des résultats qui sont obtenus dans ce domaine et ont proposé une référence de classification la plus communément retenue pour les systèmes distribués. Ces derniers sont divisés en deux familles: les SGBDDs non fédérés ou fortement couplés et les SGBDDs fédérés ou faiblement couplés.

Chapitre 5. Mise en œuvre et extension de l'approche MVDB 104

3.1.1. Les SGBDs fortement couplés

Les systèmes fortement couplés ont un schéma global unifié accédé par les utilisateurs. Ainsi, tous les schémas des différentes ressources sont intégrés dans un seul schéma global. Différentes méthodologies pour l'intégration des schémas sont proposées. Nous renvoyons le lecteur aux travaux de Batini et al. [66] pour une étude détaillée et comparative de ces méthodologies.

Le processus d'intégration devrait alors supprimer toutes les incohérences, les erreurs et les redondances issues des différents schémas. Cependant, cette intégration des schémas fait perdre à ces derniers toute leur autonomie. En effet, il n'existe qu'un seul niveau de gestion où toutes les opérations sont exécutées d'une façon uniforme. Aucune distinction n'est alors faite entre utilisation locale et utilisation globale des données.

Nous remarquons que l'objectif de l'intégration dans ces systèmes n'est pas de prendre en compte les descriptions des utilisateurs pour construire un schéma conceptuel structuré relativement à ces derniers. Le schéma conceptuel résultant de l'intégration ne diffère pas dans sa forme de celui issu d'une conception directe. Les spécificités relatives aux points de vue des utilisateurs sont perdues à l'issue de la conception par intégration. Cette approche ne répond donc pas aux besoins de structuration d'un schéma de bases de données selon des points de vue différents exprimés en §****. Nous verrons dans ce qui suit que l'approche des systèmes fédérés, par contre, permet de préserver cette description multi-points de vue des données.

3.1.2. Les SGBDs faiblement couplés

Les systèmes faiblement couplés n'ont pas un schéma global mais offrent en général un langage commun pour l'accès aux données. Dans les travaux sur l'intégration des BDDs dans un système faiblement couplé, la nouvelle base de données ne contient pas d'informations propres. Elle exploite les informations issues des composants à la façon des schémas vues. Cette base de données est désignée sous le nom de base de donnée fédérée. Un système de bases de données fédérées offre à ses clients la possibilité de percevoir et de manipuler de façon transparente les données de l'ensemble des composants décrites par un schéma intégré, appelé schéma fédéré. Scheth [81] indique q'une fédération peut également détenir ses propres informations qui sont des méta-données utilisées pour assurer une bonne gestion des composants. Parmi les objectifs principaux de la fédération, nous citons :

ü Assurer la transparence vis-à-vis des clients de la base de données fédérée.

ü Permettre la récupération, lors de l'exploitation, des données issues des différents composants.

ü Une fois intégrées, les ressources doivent continuer à mener leur propre existence. ü Préserver l'autonomie des composants, c'est-à-dire que l'intégration doit être

transparente pour leurs clients.

Nous constatons que ces objectifs suivent directement la perspective et la motivation principale de l'approche multi-points de vues à laquelle nous nous intéressons. Nous proposons donc l'adoption d'un tel environnement pour le support de l'intégration de bases de données décrivant un même univers de discours selon des points de vue différents.

Chapitre 5. Mise en œuvre et extension de l'approche MVDB 105

Les extensions que nous proposons pour notre approche s'inspirent essentiellement de l'architecture de référence des systèmes fédérés proposée dans [81] et de quelques techniques d'intégration utilisées dans le cadre du modèle "objet". Nous commençons d'abord par donner un bref aperçu de l'existant avant de détailler nos propos.

3.1.3. Architecture d'une base de donnés fédérée

L’architecture adoptée par la plupart des travaux dans le domaine des bases fédérées est donnée dans [81]. A l’image de l’architecture ANSI/X3/SPARC [ANSI75] à trois niveaux, l’architecture de [81] contient cinq niveaux. La figure 15 illustre cette architecture à cinq niveaux.

• niveau local : niveau composé des schémas des composants (encore appelés

schéma s locaux) ;

• niveau "composant" : niveau composé des schémas "composants". Un schéma "composant" est un schéma local traduit dans son intégralité dans le modèle de données commun. Entre le niveau local et le niveau "composant", un processeur de transformation assure la traduction des requêtes et des données dans les deux sens;

• niveau "export" : niveau composé des schémas exportés. Un schéma exporté est un schémavue d’un composant. Il est exprimé dans le modèle de données commun. Il décrit l’ensemble des informations d’un composant pertinentes pour la fédération. Un processeur de filtrage assure l’extraction des informations pertinentes entre le niveau "composant" et le niveau "export" ;

• niveau fédéré : le schéma fédéré est le résultat de l’intégration complète des schémas exportés. On peut donc considérer qu’il s’agit aussi d’un schéma-vue sur l’union des

niveau "composant"

niveau externe

niveau fédéré

niveau "export"

niveau local

Chapitre 5. Mise en œuvre et extension de l'approche MVDB 106

schémas exportés. Un processeur de construction s’occupe de la distribution des requêtes provenant des clients de la base fédérée et de l’intégration des résultats issus des ces requêtes distribuées. Lors de l’exploitation, il assure l’articulation entre le niveau fédéré et le niveau "export" ;

• niveau externe : niveau composé de schémas-vues externes. Un schéma-vue du niveau externe décrit les informations de la fédération pertinentes pour un de ses clients. On retrouve un processeur de filtrage entre le niveau fédéré et le niveau externe. Tous les niveaux de cette architecture ne sont pas forcément tous présents dans une base de données fédérée.