INTEGRATION DES BASES DE DONNEES CLASSIQUES ET GEOGRAPHIQUES

INTEGRATION DES BASES DE DONNEES CLASSIQUES ET GEOGRAPHIQUES

LE PROBLEME D’INTEGRATION

Selon la définition du dictionnaire [Rey-Debove et Rey 1988], l’intégration désigne « l’établissement d’une interdépendance plus étroite entre les parties d’un être vivant ou les membres d’une société ». C’est également une « opération par laquelle un individu ou un groupe s’incorpore à une collectivité, à un milieu ». Le dictionnaire renvoi par ailleurs le lecteur à la définition des termes assimilation, fusion, incorporation, insertion et unification. L’intégration désigne usuellement l’opération qui consiste à incorporer une chose dans une autre. En informatique, l’intégration est liée à la notion d’interopérabilité [Parent et Spaccapietra 2001]. Celle-ci se traduit par la capacité d’un système ou des composants d’un système à partager ses données et ses fonctions avec d’autres systèmes [Bishr 1997]. Plus précisément, l’interopérabilité est assurée si des messages et des requêtes peuvent être échangés entre deux systèmes et s’il est possible de les faire opérer comme une unité pour réaliser une tâche commune [Solar et Doucet 2002]. L’intégration désigne une opération qui permet de rendre plusieurs systèmes interopérables. L’intégration fait donc davantage référence à la notion d’association, de connectivité, de coopération. Dans cette thèse, nous nous intéressons à l’intégration de systèmes qui sont des bases de données (BD). Un base de données est constituée d’un schéma et de données relatives à un domaine. Le schéma est une « description au moyen d’un langage particulier d’un ensemble de données particulier » [Gardarin 1999, p.16]. Un schéma est donc définit dans un langage. Un langage de description de données est un « langage supportant un modèle et permettant de décrire les données d’une base d’une manière assimilable par une machine » [Gardarin 1999, p.16]. Le langage UML (« Unified Modelling Language ») est un exemple [Muller 1997]. Un langage repose donc sur un modèle. Un modèle de description de données est un « ensemble de concepts et de règles de composition de ces concepts permettant de décrire des données » [Gardarin 1999, p.16]. UML repose ainsi sur le modèle orienté-objet (O.O.). On distingue différents schémas pour une base de données. Ces schémas sont associés aux trois niveaux de description d’une BD (niveaux définis par le groupe de normalisation ANSI/X3/SPARC) : niveau conceptuel, niveau interne (logico-physique) et niveau externe. Le schéma conceptuel décrit la structure de la base sans se soucier de l’implémentation machine. Nous verrons beaucoup d’exemples de ce type de schéma dans ce mémoire. Le schéma logique est une traduction du schéma conceptuel selon le modèle du système qui gère les données de la base, le SGBD (Système de Gestion de Base de Données). Il est donc cette fois lié au système informatique adopté. Le schéma interne donne finalement une description des données en termes de représentation physique (structure de stockage supportant les données). Il suit la définition du schéma logique. Il existe également le schéma externe (qu’on qualifie aussi de vue externe). Il se définit comme la « description d’une partie de la base extraite ou calculée à partir de la base physique, correspondant à une vision d’un programme ou d’un utilisateur, donc à un arrangement particulier de certaines données » [Gardarin 1999, p.20]. Le modèle sur lequel repose ce schéma est le même que celui du niveau logique. Contrairement aux schémas conceptuel et interne, il peut exister plusieurs schémas externes qui correspondent à plusieurs « visions » de la base.

INTEGRATION DE BASES DE DONNEES CLASSIQUES

Nous nous focalisons dans cette partie sur le problème d’intégration des bases de données dites classiques, par opposition aux bases de données géographiques. Nous présentons d’abord les différents types de systèmes intégrés, c’est-à-dire les architectures qu’il est possible de mettre en place pour faire coopérer des bases de données (partie A.3.1.). Nous les classons en fonction du degré d’intégration. Nous exposons ensuite un processus d’intégration et détaillons les différentes étapes le composant (partie A.3.2). Cette première partie permet de mettre en évidence la complexité du problème d’intégration et la diversité des approches existantes pour répondre à ce problème. Notre objectif n’est pas de recenser de manière exhaustive l’ensemble des travaux sur le sujet. C’est une tâche qui s’avère impossible aujourd’hui en raison du nombre même de contributions existantes. Nous souhaitons plutôt fournir un aperçu des grandes approches proposées dans la littérature et préciser la terminologie couramment utilisée dans le domaine de l’intégration.

TYPOLOGIE DES SYSTEMES INTEGRES

Il existe plusieurs taxonomies des systèmes intégrés [Sheth et Larson 1990, Solar et Doucet 2002]. Celles-ci se fondent sur différents critères tels que le degré d’intégration (systèmes faiblement couplés, fortement couplés), le type de données à intégrer (BD, données peu structurées), les dimensions des systèmes d’informations (distribution, autonomie, hétérogénéité). Nous avons adopté la classification de [Busse et al. 1999] qui se fonde sur le degré d’intégration des données. C’est un critère qui est souvent retenu dans la littérature. Nous discuterons ainsi des systèmes faiblement couplés que sont les systèmes multibases [Rusinkiewitz et al. 1989, Litwin et al. 1989]. Leurs caractéristiques sont présentées dans la section A.3.1.1. Nous découvrirons également les systèmes fortement couplés correspondant aux systèmes fédérés [Sheth et Larson 1990, Ahmed et al. 1991]. Leur présentation fait l’objet de la section A.3.1.2. Les systèmes de médiation présentent aussi un niveau d’intégration élevé. Ils diffèrent cependant des approches fédérées sur plusieurs aspects. Nous les présenterons donc séparément dans la section A.3.1.3. Enfin, il existe aujourd’hui les entrepôts de données qui sont construits à partir d’un ensemble d’informations extraites de différentes bases [Doucet et Gançarski 2001]. Ces systèmes sont différents des précédents. L’intégration est cette fois matérialisée. Nous les exposerons dans la section A.3.1.4. Il faut préciser qu’il n’existe pas un véritable consensus sur la terminologie utilisée. Certains auteurs qualifient les systèmes multibases de systèmes fédérés particuliers faiblement couplés [Jakobovits 1997], tandis que d’autres utilisent le Chapitre A : Intégration de bases de données classiques et géographiques – 23 – terme « multibase » (plus exactement « multidatabase ») d’une manière plus générale, pour désigner tout système intégré [Sheth et Larson 1990].

SYSTEMES MULTIBASES

Les systèmes multibases sont des systèmes dits faiblement couplés [Busse et al. 1999]. On les caractérise de cette manière car ils n’offrent pas une vision unifiée des données. Il n’existe pas de schéma global permettant un accès transparent aux différentes sources de données. La coopération est seulement assurée par l’intermédiaire d’un langage commun : le langage multibase (de type SQL notamment [Litwin et al. 1989]). L’utilisateur peut poser une requête aux différentes systèmes à l’aide de ce langage commun, sans se soucier de l’hétérogénéité des systèmes source. Ceci ne signifie pas qu’une requête nécessitant l’accès à diverses sources est exécutée en une seule fois. L’utilisateur doit envoyer autant de requêtes qu’il y a de sources impliquées. C’est donc a l’utilisateur de relier les différents réponses aux requêtes formulées. Ces systèmes sont donc faiblement intégrés et gardent une grande autonomie. Les sources peuvent évoluer de manière indépendante, sans conséquence sur leur accès. Cependant, la cohérence entre ces sources n’est pas assurée. L’hétérogénéité n’est pas traitée en amont. L’intégration est dynamique : les correspondances entre les données ne sont pas prédéfinies. Certains systèmes offrent la possibilité de rendre les correspondances persistantes entre les sources par la création de vues multibases. Les requêtes multibases sont exprimées sur ces vues multi-bases. C’est le cas du système MSQL [Litwin et al. 1989].