UNIVERSITÉ PAUL CÉZANNE AIX

Transcription

UNIVERSITÉ PAUL CÉZANNE AIX-MARSEILLE III
Faculté des Sciences et Techniques de Saint-Jérôme
No 2008AIX30050
THÈSE
pour obtenir le grade de
DOCTEUR DE L’UNIVERSITÉ PAUL CÉZANNE
Discipline : Informatique
présentée et soutenue publiquement par
François-Marie Colonna
le 08 Décembre 2008
TITRE :
Intégration de données hétérogènes et distribuées sur le Web
et applications à la biologie
Directeur de Thèse : Omar Boucelma
École Doctorale 184 - Mathématiques et Informatique
JURY
Mokrane Bouzeghoub
Professeur à l’Université de Versailles
(Président)
Marie-Dominique Devignes
Chargée de Recherches au CNRS
(Rapportrice)
Thérèse Rouge-Libourel
Professeur à l’Université de Montpellier II
(Rapportrice)
Jacques Le Maitre
Professeur à l’Université du Sud Toulon-Var
(Examinateur)
Omar Boucelma
Professeur à l’Université Paul Cézanne
(Directeur)
ANNÉE : 2008
UNIVERSITÉ PAUL CÉZANNE AIX-MARSEILLE III
Faculté des Sciences et Techniques de Saint-Jérôme
No 2008AIX30050
THÈSE
pour obtenir le grade de
DOCTEUR DE L’UNIVERSITÉ PAUL CÉZANNE
Discipline : Informatique
présentée et soutenue publiquement par
François-Marie Colonna
le 08 Décembre 2008
TITRE :
Intégration de données hétérogènes et distribuées sur le Web
et applications à la biologie
Directeur de Thèse : Omar Boucelma
École Doctorale 184 - Mathématiques et Informatique
JURY
Mokrane Bouzeghoub
Professeur à l’Université de Versailles
(Président)
Chargée de Recherches au CNRS
(Rapportrice)
Thérèse Rouge-Libourel
Professeur à l’Université de Montpellier II
(Rapportrice)
Jacques Le Maitre
Professeur à l’Université du Sud Toulon-Var
(Examinateur)
Omar Boucelma
Professeur à l’Université Paul Cézanne
(Directeur)
ANNÉE : 2008
École doctorale 184
Département Mathématiques Informatique et Systèmes
Intégration de données distribuées et
hétérogènes sur le Web et applications
à la biologie
THÈSE
présentée et soutenue publiquement le 08 Décembre 2008
pour l’obtention du
Doctorat de l’Université Paul Cézanne - Aix-Marseille III
(Spécialité Informatique)
par
François-Marie Colonna
Composition du jury
Président :
Mokrane Bouzeghoub
(Professeur, Université de Versailles)
Rapporteurs :
Thérèse Libourel
(Chargée de recherches au CNRS)
(Professeur, Université de Montpellier II)
Examinateurs :
Jacques Le Maitre
Omar Boucelma
(Professeur, Université du Sud Toulon-Var)
(Professeur, Université Paul Cézanne)
Laboratoire des Sciences de l’Information
et des Systèmes – UMR CNRS 6168
Région Provence - Alpes
Côte d’Azur
Mis en page avec la classe thloria.
Remerciements
– Merci à Omar Boucelma d’avoir encadré ma thèse.
– Merci à Thérèse Rouge-Libourel et Marie-Dominique Devignes d’avoir accepté d’évaluer cette thèse.
– Merci à Jacques Le Maitre et Mokrane Bouzeghoub d’avoir accepté de faire partie
de mon jury.
– Merci à la Région PACA de m’avoir soutenu financièrement au travers de l’ADER,
ainsi qu’à la société Cosmosbay∼Vectis pour avoir rendu cette convention tripartite
possible.
– Merci également à ceux qui m’ont fait confiance en tant que vacataire et ATER.
– Merci aux auteurs respectifs de LATEX, d’Emacs et Subversion, qui m’ont permis de
gérer la rédaction du manuscrit on ne peut plus proprement.
– Merci à tous ceux et celles rencontrés au fil de ces années, et qui m’ont connu et
apprécié.
– Un grand merci enfin à ma famille pour m’avoir soutenu moralement (et financièrement !) pendant toutes ces années.
i
ii
En informatique, la majeure partie des bugs se situent entre la chaise et le clavier.
Auteur inconnu.
iii
iv
Table des matières
Table des figures
ix
Liste des tableaux
xi
Liste des algorithmes
xiii
Notes au lecteur
1
Des données géographiques aux données biologiques
3
Introduction générale
5
1
Problématique et motivations . . . . . . . . . . . . . . . . . . . . . . .
2
Objectifs et contributions . . . . . . . . . . . . . . . . . . . . . . . . . 11
3
Structuration du document . . . . . . . . . . . . . . . . . . . . . . . . 12
Partie I
6
Hétérogénéité et intégration de données : état de l’art 15
Chapitre 1 Introduction
19
1.1 Intégrer des données : pour qui ? pourquoi ? . . . . . . . . . . . . . . . 20
1.2 Des différences multiples . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.2.1
Variété des données . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.2.2
De l’hétérogénéité... . . . . . . . . . . . . . . . . . . . . . . . . 22
1.2.3
1.2.2.1
...au niveau syntaxique : . . . . . . . . . . . . . . . . . 23
1.2.2.2
...au niveau sémantique . . . . . . . . . . . . . . . . . 23
1.2.2.3
...au niveau qualitatif . . . . . . . . . . . . . . . . . . 26
Autonomie et capacités d’interrogation . . . . . . . . . . . . . . 27
v
Chapitre 2 Classification des approches d’intégration
29
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.2 L’entrepôt de données . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.3 La navigation entre les sources . . . . . . . . . . . . . . . . . . . . . . 38
2.4 Les accès par les portails et les plateformes logicielles . . . . . . . . . . 39
2.5 La fédération de données . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.6 L’approche multi-agents . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.7 La médiation de données . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.8 L’intégration P2P . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
2.9 Wrapper les sources, un problème commun à toutes les approches . . . 47
2.10 Synthèse et discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
2.11 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Partie II
Automatisation de recoupements manuels de données 53
Chapitre 3 Partage de références entre sources biologiques
57
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
3.2 Objectifs et exemple illustratif . . . . . . . . . . . . . . . . . . . . . . . 58
3.3 Formulaires Web et interrogations limitées . . . . . . . . . . . . . . . . 60
3.4 Exploitation des références croisées . . . . . . . . . . . . . . . . . . . . 62
Chapitre 4 Intégration par union de jointures
69
4.1 Formalisation des descriptions des sources . . . . . . . . . . . . . . . . 70
4.2 Représentation des patterns d’accès par des termes d’attributs . . . . . 72
4.2.1
Identification des différents types de patterns . . . . . . . . . . 72
4.2.2
Description du formalisme et exemple illustratif . . . . . . . . . 73
4.2.3
Expression des requêtes . . . . . . . . . . . . . . . . . . . . . . 80
4.3 Traitement des requêtes d’intégration de données . . . . . . . . . . . . 81
4.3.1
Choix des vues initiales . . . . . . . . . . . . . . . . . . . . . . 82
4.3.2
Algorithme de calcul des chemins de jointure
4.3.3
Algorithme de traitement des requêtes . . . . . . . . . . . . . . 86
. . . . . . . . . . 84
4.4 Prototypage et illustration par l’exemple . . . . . . . . . . . . . . . . . 88
vi
4.4.1
Format XML des termes d’attributs . . . . . . . . . . . . . . . 88
4.4.2
Extraction des données avec Lixto . . . . . . . . . . . . . . . . 89
4.4.3
Prototype développé, tests et performances
. . . . . . . . . . . 92
4.5 Applications sur des données biologiques . . . . . . . . . . . . . . . . . 99
4.5.1
Intégration de données et prédiction de gènes candidats . . . . . 99
4.5.2
Construction d’un méta-moteur de recherche de gènes candidats 100
4.5.3
Complétion et vérification de données de puces à ADN . . . . . 103
4.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Partie III
Médiation de données biologiques du Web
Chapitre 5 Atouts et insuffisances des solutions actuelles
111
115
5.1 Contexte de nos travaux . . . . . . . . . . . . . . . . . . . . . . . . . . 116
5.2 Ecueils des approches classiques de médiation . . . . . . . . . . . . . . 117
5.2.1
Médiation de schéma . . . . . . . . . . . . . . . . . . . . . . . . 117
5.2.2
Médiation de contexte . . . . . . . . . . . . . . . . . . . . . . . 121
5.3 Médiation et réseaux pair à pair . . . . . . . . . . . . . . . . . . . . . . 122
5.4 Fédération lâche et langages multi-bases . . . . . . . . . . . . . . . . . 124
5.5 Une architecture BGLAV basée sur XML et XQuery . . . . . . . . . . 125
5.5.1
Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
5.5.2
Travaux liés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Chapitre 6 Réécriture de requêtes biologiques BGLAV
6.1 Intégration BGLAV de données biologiques
131
. . . . . . . . . . . . . . . 132
6.1.1
Exemple illustratif et taxonomie des conflits . . . . . . . . . . . 133
6.1.2
Formalisation du système d’intégration de données . . . . . . . 138
6.1.3
Identification et correspondance des éléments XML . . . . . . . 140
6.1.3.1
Restrictions d’accès et valuation obligatoire de nœuds 140
6.1.3.2
Clefs d’un schéma XML . . . . . . . . . . . . . . . . . 141
6.1.3.3
Association entre requêtes de correspondance et clefs XML144
6.2 Décomposition et recomposition des requêtes . . . . . . . . . . . . . . . 145
6.2.1
Classification des types de requêtes . . . . . . . . . . . . . . . . 148
6.2.2
Algorithme de réécriture BGLAV adapté aux sources Web . . . 150
6.2.2.1
Choix des sources participantes . . . . . . . . . . . . . 150
vii
6.2.2.2
6.2.3
Génération d’un plan de requêtes . . . . . . . . . . . . 153
Extensibilité du système . . . . . . . . . . . . . . . . . . . . . . 156
6.3 Prototypage, tests et performances . . . . . . . . . . . . . . . . . . . . 156
6.4 Application sur des données biologiques . . . . . . . . . . . . . . . . . 157
6.4.1
Intégration de données tirées de la base Ensembl . . . . . . . . 158
6.5 Conclusion et ouvertures . . . . . . . . . . . . . . . . . . . . . . . . . . 165
Conclusions et perspectives
167
1
Résumé des contributions . . . . . . . . . . . . . . . . . . . . . . . . . 167
2
Ouverture et pistes de recherche . . . . . . . . . . . . . . . . . . . . . . 168
Annexes
Annexe A Projets d’intégration de données biologiques
173
Annexe B Approches d’intégration et prototypes associés
177
Annexe C Index des méthodes d’extraction de données Web
179
Annexe D Schéma XSD des termes d’attributs
181
Glossaire
185
Bibliographie
189
Index
217
viii
Table des figures
1
2
3
Nombre d’entrées de la base EMBL (en millions) . . . . . . . . . . . . . . . 6
Nombre d’entrées de la version 56.5 de la base UniProtKB/Swiss-Prot (×103 ) 7
Evolution du nombre de bases de données ouvertes sur le Web . . . . . . . 8
1.1 Micro-réseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1.2 Réseau de régulation génétique . . . . . . . . . . . . . . . . . . . . . . . . 22
1.3 Divers formats pour les mêmes données . . . . . . . . . . . . . . . . . . . . 24
2.1
2.2
2.3
2.4
2.5
Classification des approches d’intégration (de
Organigramme des systèmes d’intégration .
Architecture d’un entrepôt de données . . .
Fédération de bases de données . . . . . . .
Architecture de médiation DARPA I3 . . . .
0 / faible à 5 / fort) . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
31
32
34
41
42
3.1 Phases de l’étude d’une zone d’intérêt sur le chromosome 5 . . . . . . . . . 59
3.2 Exemple de partage de références entre des sources . . . . . . . . . . . . . 63
3.3 Liens présents entre plusieurs sources . . . . . . . . . . . . . . . . . . . . . 65
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
4.9
4.10
4.11
4.12
Formulaire de requête... . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
...et terme d’attributs associé . . . . . . . . . . . . . . . . . . . . . . . . . 75
Hypergraphe des sources bibliographiques . . . . . . . . . . . . . . . . . . 78
Contenu des vues exemples . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Chemins de jointures entre les sources S1 , S2 , S3 et S4 . . . . . . . . . . . . 79
Ensembles de sources contenant les vues utilisées pour traiter les requêtes . 82
Notation classique d’un FT . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Notation XML d’un FT . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Exemple de règles Elog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Cycle d’interrogation entre plusieurs sources . . . . . . . . . . . . . . . . . 91
Chemins de jointure entre les sources bibliographiques . . . . . . . . . . . . 95
Interface graphique pour l’intégration de données basée sur le partage de références 96
ix
4.13
4.14
4.15
4.16
4.17
4.18
4.19
4.20
Parcours effectué par le premier scénario . . . . . . . . . . . . . . . .
Gènes prioritaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sources utilisée par le méta-moteur . . . . . . . . . . . . . . . . . . .
Formulaire proposé par la source Suspects . . . . . . . . . . . . . . .
Formulaire proposé par la source PosMed . . . . . . . . . . . . . . . .
Interface graphique du métamoteur de recherche de gènes candidats .
Références croisées sur des données Affymetrix . . . . . . . . . . . . .
Interface graphique du détecteur de conflits pour les puces Affymetrix
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
99
99
101
102
102
104
106
107
5.1 Intégrations GAV et LAV . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
6.1
6.2
6.3
6.4
6.5
6.6
6.7
6.8
6.9
Schémas exportés par les sources distantes . . . . . . . . . . . . . . . . . . 134
Schéma global sur lequel vont s’apparier les sources locales . . . . . . . . . 135
Taxonomie des conflits entre schémas locaux et schéma global . . . . . . . 136
Expression de correspondances avec XQuery . . . . . . . . . . . . . . . . . 137
Nœuds XML à valuation obligatoire . . . . . . . . . . . . . . . . . . . . . . 140
Exemples de clefs des éléments d’un schéma XML (en gras) . . . . . . . . . 142
Couvertures possibles d’un élément du schéma métier par les schémas dérivés149
Traitement des requêtes par le médiateur BGLAV . . . . . . . . . . . . . . 151
Interface graphique du médiateur BGLAV . . . . . . . . . . . . . . . . . . 157
x
Liste des tableaux
1.1 Références croisées de sources différentes concernant le gène IL12B . . . . . 25
1.2 Provenance des données : Chercheurs(C), Publications(P), Autres bases(BD) 26
2.1 Entrepôts commerciaux et entrepôts biologiques . . . . . . . . . . . . . . . 35
3.1 Deux déroulements possibles . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
4.9
4.10
4.11
4.12
4.13
4.14
4.15
Syntaxe des termes d’attributs . . . . . . . . . . . . . . . .
Compatibilités entre les patterns associés à un attribut . .
Quatre sources bibliographiques . . . . . . . . . . . . . . .
Détails du prototype . . . . . . . . . . . . . . . . . . . . .
Patterns d’accès des vues sélectionnées . . . . . . . . . . .
Contenu de la vue V17 . . . . . . . . . . . . . . . . . . . .
Sources intermédiaires utilisées pour compléter les chemins
Descriptif des jeux de données générés . . . . . . . . . . .
Résultats des tests . . . . . . . . . . . . . . . . . . . . . .
Durée de la phase d’intégration de données . . . . . . . . .
Résultats de la phase d’analyse . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
74
76
77
93
93
94
94
94
94
94
95
97
98
108
108
6.1 Conflits entre les schémas XML locaux et globaux . . . . . . . . . . . . . . 135
xi
xii
Liste des algorithmes
1
2
3
4
5
6
ChercherVuesInitiales(S , Iv) . . . . . . . . . . . . . . . . . . . . . . . .
ChercherCheminComplet(C, S, EChemins) . . . . . . . . . . . . . . . . . .
TraiterRequete(Q ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
S2 (T ) : sélection des sources candidates . . . . . . . . . . . . . . . . .
Réécriture d’une requête (1/2) : GenerePlanPartiel(Q(TG)) . . . . . .
Réécriture d’une requête (2/2) : CompletePlanPartiel(P , SAV ,CSAVMin )
xiii
.
.
.
.
.
.
.
.
.
.
.
.
83
85
86
152
154
155
xiv
Notes au lecteur
Dans la suite du document, les termes marqués par
1
⋆
seront définis dans le glossaire.
2
Des données géographiques aux
données biologiques
Dans la partie introductive de cette thèse, avant d’aborder dans le détail nos travaux,
il nous semble important d’effectuer un bref rappel de nos recherches passées, qui ont
concerné le domaine de l’intégration de données géographiques. Bien que se distinguant
clairement du domaine d’expertise des sciences de la vie, autour duquel s’articule ce mémoire, les réflexions que nous avons menées dans le domaine géographique ont influencé
fortement le développement des éléments constitutifs de cette thèse.
Nos travaux dans le domaine applicatif géographique ont eu pour objectif de développer une architecture d’intégration de données virtuelle destinée à intégrer des données
cartographiques, dans le cadre du projet RNTL1 VirGIS2 [BCE04, ECBB06].
Les deux éléments principaux de ce médiateur sont le moteur de requêtes GQuery
[BC04a, BC04b], qui étend les capacités du langage XQuery en y ajoutant des opérateurs
géographiques, et le module de réécriture de requêtes [BEL02, EBCL04, Ess05], qui décompose et réécrit la requête posée par l’utilisateur en un ensemble de requêtes envoyées
aux sources de données distribuées et hétérogènes. L’accès aux sources s’avère simplifié
dans le domaine géographique, grâce à un effort conséquent visant à la standardisation
des échanges, mené par le consortium OpenGIS [Ope03].
Ces travaux ont été une source d’enrichissement à deux niveaux : d’une part, afin de
circonscrire la problématique de l’intégration de données du Web ; et d’autre part, ils ont
constitué un apprentissage des étapes à suivre lors de l’opérationalisation d’une démarche
théorique.
1 Réseau
2
National des Technologies Logicielles.
Virtual Geographic Information System.
3
4
Intégration de données sur le Web :
Etude générale et applications au
domaine biologique
En seulement une centaine d’années, un pas de géant a été franchi en médecine depuis
les découvertes essentielles de Pasteur, Koch, ou Hoffmann datant de la fin du XIXème
siècle. La révélation de la structure en double hélice de l’ADN⋆ par Watson et Crick en
1953 [WC53] a ensuite ouvert des champs de recherche dont nous avons encore peine à
imaginer les limites.
Les investigations dans le domaine biologique ont connu un essor sans précédent au
cours des vingt dernières années. La première phase s’est produite lors du passage des
expérimentations menées uniquement in vitro ou in vivo par l’homme, à l’automatisation
de ces dernières, par la mise au point des machines de séquençage automatique, et ce dès
1986 [SSK+ 86].
Les sciences du vivant ont ensuite connu une deuxième impulsion, par le développement
de l’informatique, qui a donné naissance au domaine de la bioinformatique. Ces avancées
n’auraient jamais eu l’ampleur que nous leur connaissons aujourd’hui sans l’extension
mondiale du réseau internet. Il peut sembler banal de le préciser tant cet outil est devenu
d’utilisation courante dans le domaine de la recherche, mais il nous semble indispensable
de le rappeler, avec d’autant plus de force que nos travaux se situent dans le cadre des
bases de données hétérogènes et distribuées sur le Web 3 .
De leur isolement des origines, ces dernières se sont ouvertes sur le monde, résolvant par
là même le problème de leur accès parfois difficile ou impossible, mais en posant un autre
3 Dans
la suite de ce document, les expressions source de données, base de données, ou source d’information désigneront indistinctement “un ensemble de données non indépendantes interrogeables par le
contenu [...] selon n’importe quel critère”, et pour lesquelles “il doit être aussi possible de retrouver leur
structure”, conformément à la définition donnée par Georges Gardarin [Gar03].
5
plus crucial aujourd’hui, celui de leur interopérabilité.
Fig. 1 – Nombre d’entrées de la base EMBL (en millions)
1
Problématique et motivations
Les pratiques concernant le stockage et la mise à disposition des données produites
par les laboratoires de recherche ont évolué au cours du temps. Au début du stockage
informatisé des données, les résultats produits étaient sauvegardés localement, dans des
bases de données développées et maintenues en interne, destinées uniquement à un usage
interne. L’accent était uniquement mis sur la sauvegarde rapide et fiable des résultats.
La prise en compte d’une ouverture future sur le monde (donc sur le Web) n’étant pas
envisagée, les problématiques des accès et des modifications concurrentes, ainsi que la
documentation destinée à l’utilisateur étaient souvent laissées de côté. En l’absence de
consensus sur le modèle de données à utiliser, ou le langage de requêtes destiné à exploiter les enregistrements, les solutions individuelles se sont multipliées : formats binaires,
fichiers plats, bases de données relationnelles, ou plus récemment encore, bases de données
objet et natives XML [HM04]. Associés à ces bases de données, nous trouvons pêle-mêle
les langages Perl [Wal00], SQL [Lan89], OQL [ASL89], XQuery [KCD+ 03], ou simplement
des adresses Web, qui à base de couples clefs-valeurs sont parfois - trop souvent - le seul
moyen d’extraire les informations qui intéressent le chercheur. Cette façon de procéder
nous a amené à la situation que nous connaissons aujourd’hui avec des bases de données
qui proposent certes souvent un format d’exportation commun (XML par exemple), mais
dont les schémas sont hétérogènes, et les langages de requêtes incompatibles. La syntaxe et
6
la sémantique⋆ diffèrent d’une base à l’autre, ce qui oblige l’utilisateur à un apprentissage
préalable multiple : tant sur la signification des données enregistrées et des opérateurs que
l’on peut leur appliquer, que sur la façon d’y accéder, par le biais de formulaires Web ou
par une connexion directe au SGBD⋆.
De nos jours, la masse formidable de données produites par les centres de recherche
atteint des quantités de plusieurs gigaoctets par jour, entreposés dans une multitude de
systèmes, répartis dans le monde entier ; à titre d’exemple, la version 168 de GenBank
[BBLO97] occupe 371 giga-octets, et la version 51 d’Ensembl [CCCR04] 713 giga-octets.
Cette accumulation d’informations a engagé la biologie dans une phase de transition d’une
science expérimentale à une science de plus en plus orientée par les données [Com05]. Les
histogrammes présentés en Figure 1 et en Figure 2 montrent respectivement l’évolution
du nombre d’entrées des bases EMBL et UniProtKB/Swiss-Prot.
Fig. 2 – Nombre d’entrées de la version 56.5 de la base UniProtKB/Swiss-Prot (×103 )
L’enregistrement des séquences brutes, de la cartographie des chromosomes, des données structurales ou d’expression des gènes ont obligé à apporter une attention toute
particulière aux sources de données qui les contiennent. La connexion au Web ouvre ces
sources à un nombre d’utilisateurs potentiellement illimité, même si en pratique, il est rare
de dépasser le cap de plusieurs milliers de connexions simultanées. Cet état de fait oblige
leurs concepteurs à une réflexion approfondie en amont, afin d’éviter l’asphyxie rapide du
7
Fig. 3 – Evolution du nombre de bases de données ouvertes sur le Web
système, causée par la redondance, des structures de données inadaptées ou une mauvaise
optimisation4 qui font s’écrouler les performances lors d’un grand nombre d’accès. La majeure partie des sources sont basées sur des technologies éprouvées et robustes, comme des
serveurs Oracle [ATLB03] ou MySQL [SR04] (souvent montées en cluster⋆ ), donc aptes à
répondre à une telle montée en charge. 5
L’un des principaux problèmes auxquels sont confrontés les biologistes aujourd’hui ne
concerne donc plus la consultation individuelle d’une seule et unique source, mais plutôt
l’interopération de plusieurs. Nous ne considérons dans la suite de cette introduction et la
présentation de nos travaux que les sources de données qui correspondent aux critères décrits chaque année dans le journal Nucleic Acid Research [Gal07], à savoir les banques de
données ouvertes au public sans installation de logiciels complémentaires, et qui autorisent
l’exploration du contenu stocké sans compensation financière6 . Le graphique présenté en
4
La plupart des tables de la base Ensembl ont un index dont la taille dépasse celle des données ellesmêmes. La rapidité d’accès a été privilégiée - sciemment et avec succès - au détriment de l’espace de
stockage [Col06].
5 Au 13 Juillet 2006, le serveur MySQL de la base de données Ensembl [CCCR04], démarré depuis 30
jours, avait exécuté 505 602 993 commandes et reçu 224 625 322 requêtes SELECT, soit une moyenne de
7 millions par jour. Toutes opérations confondues, le serveur a répondu en moyenne à 229 requêtes/sec,
avec des pointes à 855.
6
Des restrictions d’accès peuvent néanmoins exister afin de n’autoriser que certains types de requêtes.
8
Figure 3, tiré des classements opérés par ce journal [Gal08], témoigne de l’évolution du
nombre de sources au fil des ans. La liste s’est accrue de façon considérable depuis la fin
du siècle dernier, avec une augmentation moyenne de 20,83% par an.
Une des problématiques centrales des biologistes d’aujourd’hui consiste donc à rassembler les données extraites de plusieurs de ces sources, de la façon la plus automatisée
possible. Dans le cadre de nos travaux, nous nous sommes intéressés uniquement aux problèmes posés par l’intégration de données, que nous allons détailler un peu plus loin dans
la suite de cette introduction. Un bon moyen de se rendre compte des difficultés éprouvées
aujourd’hui pour la collecte de données consiste à s’intéresser à un scénario typique, résolu
manuellement.
Considérons une question biologique simple à propos de la nomenclature de localisation⋆
des chromosomes :
“Quelles sont les publications concernant la région q31 du chromosome 5 ? ”
Une réponse possible à cette question met en œuvre deux sources : UCSC [KBD+ 03]
(contenant la cartographie du génome humain) et PubMed [Nat06] (base de données bibliographique). La première étape consiste à extraire les listes de gènes depuis UCSC, et
à reporter ensuite les références obtenues dans le formulaire de requête proposé par le
site de PubMed. Le croisement manuel des informations fournies individuellement nous
apporte donc un ensemble de résultats, qui ne constitue qu’une partie des réponses possibles, puisque d’autres sources disponibles sur le Web nous auraient permis de répondre
à cette même question7 . Le travail demandé pour ce faible nombre de sources est déjà
fastidieux, et prend des proportions qui deviennent difficiles à gérer à partir de cinq ou
dix sources. Des simplifications existent, puisque des liens hypertexte permettent souvent
de basculer d’une source à l’autre selon la valeur d’un paramètre ; c’est notamment le cas
dans les bases de données les plus connues telles que GenBank [BBLO97], ou SwissProt
[OMG+ 02]. D’un point de vue informatique, ces hyperliens entre objets hébergés dans
des sources distribuées permettent d’obtenir une jointure, mais ces solutions bien que très
utiles pour collecter rapidement des données, sont insuffisantes : l’intervention humaine
reste prépondérante ; de plus, l’expressivité de la requête est très limitée, pour ne pas dire
inexistante.
Comme nous venons de l’évoquer, la diversité des formats, des interfaces, des langages
de requêtes rend l’intégration de données (biologiques ou non) sur le Web difficile. Des
solutions ont été proposées pour la collecte centralisée de données au travers d’une inter7 Cette
problématique fait partie de celles que nous avons abordées dans nos travaux présentés en
Partie II.
9
face unique : soit en exploitant les liens entre sources (intégration navigationnelle), soit
dans le cadre des approches d’intégration matérialisées (entrepôt de données) ou virtuelles
(architectures de médiation).
L’intégration navigationnelle consiste à regrouper les bases de données entre elles à
partir des identifiants qu’elles partagent. Il s’agit de la méthode la plus simple, accessible
à tous les utilisateurs sans apprentissage préalable. Elle reprend le principe appliqué lors
de l’extraction manuelle, en sélectionnant les attributs à extraire de chacune des sources
demandées.
Les deux dernières approches, la construction d’un entrepôt de données ou l’intégration
de données virtuelle à l’aide de vues ont besoin toutes les deux d’un modèle de données
commun afin de représenter les données extraites des sources locales.
La démarche de création d’un entrepôt consiste à traduire massivement les données
extraites des sources locales, afin de les rendre compatibles avec le modèle de données
proposé à l’utilisateur. Cette adaptation des données présente un certain nombre d’inconvénients, tels que l’espace nécessaire au stockage et la mise à jour qui est très coûteuse en
temps et en trafic sur le réseau. Le système offre généralement un langage de requêtes qui
permet d’appliquer des opérateurs d’extraction de données pour vérifier des hypothèses,
ou bien réaliser des expérimentations in silico. Hammer et Schneider [HS03] vont jusqu’à
préconiser la mise en place d’une seule et gigantesque base de données, qui serait selon eux
l’unique solution aux problèmes d’intégration de données biologiques8 . Cette proposition
s’apparente à de la science-fiction : l’espace physique occupé serait trop important, tant
par les données que la conservation de leur traçabilité 9 , et les phases de mises à jour
occuperaient la majorité du temps de fonctionnement du système.
La médiation de données permet d’intégrer uniquement les données souhaitées par
l’utilisateur, qui exprime ses besoins au travers d’une requête posée sur un schéma global
préalablement défini. Les données sont à jour en permanence, puisque relues à chaque
fois qu’une nouvelle demande parvient au système. L’espace démandé pour stocker les
données est faible, et dédié au mécanisme de mise en cache des requêtes s’il a été mis en
place par les concepteurs. Les difficultés majeures de la médiation reposent essentiellement
sur la transformation de requêtes destinées aux sources de données locales, et la facilité
d’évolution du schéma global en cas d’ajout ou de retrait d’une source, ce qui se produit
très fréquemment sur le Web.
Les deux approches que nous venons d’évoquer se rejoignent par le fait que dans
8 Voir
également à ce propos l’article de Lincoln Stein [Ste03].
importante pour les biologistes, la provenance des données a un impact sur leur qualité et le
crédit qui leur est accordé. SwissProt [Swi06], manuellement annotée par 51 curateurs (effectif de l’année
2006), est ainsi très estimée, et sert de socle à la création d’autres bases.
9 Très
10
certains cas, les instances du schéma défini pour la médiation servent d’étape de transformation préalable au peuplement d’un entrepôt de données [CGM98].
2
Objectifs et contributions
L’intégration de données dans le cadre relationnel, objet ou semi-structuré avec XML,
s’est exprimée ces dernières années au travers de projets d’intégration génériques [KLSS95,
CGMH+ 94, ACV+ 00], ou orientés vers un domaine précis, qu’il s’agisse de la géographie
[BCE04, SM04] ou de la biologie [DCB+ 01, SBB+ 00, DW03].
Nos travaux dans le domaine de l’intégration de données sur le Web ont été appliqués
à la biologie et se sont articulés autour de deux axes majeurs :
1. la collecte de données entre sources aux capacités d’accès limitées, ce qui est le cas
d’un très grand nombre de sources biologiques ouvertes sur internet
2. l’intégration de données flexible, basée sur la philosophie lecture seule de la médiation, et proposant un langage de requêtes évolué, tout en s’affranchissant des
difficultés posées par la construction et la maintenance du schéma global inhérente
à l’utilisation d’un médiateur
Nous nous sommes placés dans le cadre biologique, mais les approches et les méthodes
présentées dans ce mémoire de thèse peuvent être adaptées et utilisées sur n’importe quelle
thématique autre que celle des sciences de la vie.
Le premier aspect que nous avons traité est destiné à répondre au besoin de regroupement de données formulé par les biologistes, sans nécessité d’apprentissage de langage,
ni de construction d’un schéma métier. Nous sommes partis du constat que l’approche
manuelle consiste pour l’essentiel, à partir d’un petit nombre de paramètres et d’une liste
de sources, à extraire des tuples de certaines des sources, puis d’en réinterroger d’autres à
partir du résultat fourni. Nous avons donc automatisé l’exécution manuelle de cette tâche
fastidieuse, à partir d’un formalisme simple basé sur la logique des attributs, modélisant
les paramètres d’entrée, les sources de données, et l’ensemble des références partagées
entre les sources. Cette approche a été validée par la réalisation d’un logiciel d’intégration
utilisant des descriptions des capacités des sources basées sur le modèle semi-structuré
proposé par le langage XML10 .
10
Le modèle relationnel avait été mis en œuvre dans la première version de l’outil développé.
11
Le deuxième aspect de nos travaux traite de l’intégration flexible de données sur le
Web. Notre réflexion a été guidée par les conclusions tirées de nos précédentes recherches
dans le domaine de la médiation de données [BC04b, BL02], mais aussi sur les difficultés
présentées par le traitement des requêtes portant sur un schéma global [CLL01, LMS95].
Dans le domaine du Web, l’intégration de données devient de fait très complexe quand le
nombre de sources augmente, et les difficultés rencontrées sont accentuées par leur volatilité. De plus, le langage de requêtes proposé à l’utilisateur doit être riche pour permettre
l’expression simple de requêtes complexes. Nous avons donc privilégié une solution qui
s’affranchit des difficultés de construction de schéma rencontrées habituellement, puisque
l’utilisateur définit préalablement le schéma métier, indépendamment des sources, puis
se contente d’associer à ce schéma tout ou partie des sources qui selon lui présentent un
intérêt. À partir de méta-données décrivant les capacités des sources ainsi que les préférences de l’utilisateur, la phase de réécriture sélectionne uniquement les sources pouvant
produire des résultats ; s’ensuit alors une phase d’extraction, puis de de fusion des tuples
renvoyés, phase qui détecte et résout les éventuelles incohérences entre les données. Cette
approche d’intégration a également été validée par le développement d’un prototype destiné à illustrer sa mise en œuvre sur plusieurs exemples.
3
Structuration du document
Dans la première partie de cette thèse, nous présentons les problèmes généraux rencontrés en intégration de données. Notre état de l’art comporte une description des différents
niveaux d’hétérogénéité entre les sources, et une présentation des réponses théoriques apportées par la communauté pour faciliter leur intégration. Nous illustrons chacune des
approches par les descriptions de quelques-unes des solutions logicielles majeures qui y
sont associées, qu’elles soient prototypiques ou commerciales. Nous discutons également
les forces et les faiblesses de nos travaux précédents, qui ont justifié les orientations de
nos recherches.
Dans la seconde partie, nous présentons une contribution apportée à la problématique
de collecte de données sur le Web, dans le cadre de sources aux capacités d’accès limitées. Cette approche se justifie par le constat que la très grande majorité des sources
aujourd’hui disponibles [Gal07] ne le sont qu’au travers d’interfaces rudimentaires, majoritairement des formulaires en langage de balisage HTML. Ces interfaces demandent peu
de paramètres en entrée, et en renvoient beaucoup en résultat ; les paramètres supplémentaires obtenus peuvent donc à leur tour être utilisés pour adresser une nouvelle requête,
et ainsi réaliser de proche en proche une jointure entre toutes les sources. La méthode que
12
nous avons mise en œuvre raisonne sur les capacités des sources à l’aide de la logique des
attributs. Elle permet d’automatiser ce qui est fait aujourd’hui encore manuellement. De
plus, la confrontation de données tirées de plusieurs jointures permet de complèter des
informations partielles, ou de mettre en évidence des incohérences entre les données de
plusieurs sources.
Enfin, la troisième partie de ce mémoire propose un formalisme mixte de construction
de schéma global adapté au modèle semi-structuré, afin d’aboutir à une intégration flexible
de données, qui s’affranchit des limitations actuelles des systèmes basés sur l’intégration de
schémas utilisant les approches GAV11 ou LAV12 . Forts de l’expérience tirée de recherches
que nous avons menées précédemment [BCE04], nous avons suivi une approche inspirée
de celle définie par Xu et Embley [XE04], en y associant un algorithme de réécriture de
requêtes apte à résoudre les conflits rencontrés lors de la fusion des données intégrées.
Dans le dernier chapitre, nous résumons les contributions de nos recherches et concluons
en ouvrant des perspectives sur nos travaux futurs.
11 Global-As-View,
12
qui définit les relations dans le schéma global comme des vues sur les sources locales.
Local-As-View, qui définit les relations dans les sources locales comme des vues sur le schéma global.
13
14
Première partie
Hétérogénéité et intégration de
données : état de l’art
15
Dans la première partie de cette thèse, nous nous appliquons à dresser l’état de l’art de
l’hétérogénéité des données biologiques disponibles sur le Web, et des différentes approches
théoriques qui visent à leur intégration. Nous illustrons ces descriptions par la présentation
de solutions proposées par la communauté pour chacune des approches. Enfin, à partir de
la discussion des forces et des faiblesses des solutions existantes et des travaux que nous
avons menés, nous introduisons les deux axes majeurs de nos travaux, répondant chacun
à une classe précise de problèmes, et les contributions que nous avons apportées à leur
résolution.
17
18
Chapitre 1
Introduction
Dans ce premier chapitre, nous rappelons brièvement la définition de l’intégration de
données, puis nous présentons les grandes dimensions de variation des données, qui se
situent au niveau de leur syntaxe, de leur sémantique et de leur qualité. Nous illustrons
notre propos par des exemples tirés de sources de données biologiques, et concluons en
explicitant les problèmes supplémentaires causés par la grande autonomie des sources et
leurs capacités d’interrogation limitées.
Sommaire
1.1
Intégrer des données : pour qui ? pourquoi ? . . . . . . . .
20
1.2
Des différences multiples . . . . . . . . . . . . . . . . . . . .
21
1.2.1
Variété des données . . . . . . . . . . . . . . . . . . . . . .
21
1.2.2
De l’hétérogénéité... . . . . . . . . . . . . . . . . . . . . . .
22
1.2.3
Autonomie et capacités d’interrogation . . . . . . . . . . .
27
19
1.1
Intégrer des données : pour qui ? pourquoi ?
Dans la partie introductive de l’ouvrage Introduction to algorithms [CLRS01], à la
question “Quels sont les types de problèmes susceptibles d’être résolus par des algorithmes ? ”,
la première réponse fournie par les auteurs est “identifier les 100000 gènes de l’ADN humain [...] stocker ces informations dans des bases de données et développer des outils
d’analyse de données”.
Cette remarque va dans le sens de notre argumentation présentée à l’aide de chiffres
et d’exemples dans la partie liminaire de cette thèse : intégrer les données biologiques
issues des laboratoires et proposées sur internet est devenu une préoccupation majeure de
l’informatique d’aujourd’hui. La recherche sur les gènes, les protéines, ou les publications
scientifiques - à des fins d’annotation ou de prédiction - amène souvent les chercheurs à
soumettre des requêtes multiples sur des sources de données hétérogènes disponibles sur
le Web.
Plusieurs études ont démontré l’apport de l’intégration de différents types de données
en recherche. Ainsi, Mootha et al. ont découvert un des gènes responsables du syndrome de
Leigh 13 , en intégrant des données d’expression, des données génomiques et de localisation
sub-cellulaire [MLM+ 03]. Stuart et son équipe ont déduit des fonctions de gènes à partir de
données de puces à ADN disponibles sur plusieurs espèces [SSKK03]. D’autre part, Kaplan
a souligné l’intérêt de confronter des données génomiques, protéiques, épidémiologiques
ainsi que des outils d’analyse génétique pour la compréhension des maladies polygéniques
et le développement de nouveaux outils de diagnostic et thérapeutiques [Kap02].
La complexité de la tâche d’intégration repose tout à la fois sur l’obligation pour le
chercheur de maı̂triser une palette d’outils informatiques et de langages dédiés, et sur la
collecte manuelle et fastidieuse - voire dans certains cas impossible - des fragments de
réponse à recombiner.
Le but de l’intégration est d’offrir à l’utilisateur un accès uniforme et transparent aux
données, le système se chargeant de la répartition des requêtes aux sources qui participeront à la construction du résultat. Le problème de combinaison de sources de données
hétérogènes sous une seule interface de requête n’est pas récent : le développement rapide
des bases de données dans les années 70 a naturellement fait surgir le besoin de partager
et d’intégrer les données déjà entreposées.
13 Le
syndrome de Leigh est une maladie rare (1 cas sur 40 000 naissances en Europe) qui génère des
lésions au niveau du thalamus et du tronc cérébral et entraı̂ne des symptômes neurologiques et musculaires,
mortels à brève échéance.
20
En biologie (mais aussi plus généralement dans le monde industriel 14 et des domaines
différents tels que la géographie ou les sciences physiques...), les défis à relever pour parvenir à un résultat intégré sont nombreux, et conséquences directes des caractéristiques
des données et des systèmes destinés à leur stockage.
1.2
Des différences multiples
À l’image d’une tendance générale transdisciplines scientifiques, le nombre de sources
de données et d’outils à la disposition des biologistes sur le Web n’a cessé de croı̂tre ces
dernières années. Cette augmentation colossale de la masse de données disponibles a généré
une grande variété d’interfaces d’accès, mais aussi et surtout une profonde hétérogénéité
syntaxique, sémantique et qualitative. Jusqu’à présent, les recoupements effectués par
les biologistes entre plusieurs sources de données étaient réalisés à la main, au cas par
cas. Les interrogations des sources devaient se faire une à une, puis dans l’ensemble de
résultats obtenus, il fallait faire la part des redondances et des complémentarités, ainsi
que des éventuelles inconsistances. Désormais, la compréhension des processus globaux des
phénomènes vitaux doit faire appel à une automatisation des traitements. Cet objectif,
pour être atteint, nécessite la résolution des incompatibilités intersources.
1.2.1
Variété des données
Une des particularités du domaine biologique est son étendue. Ce sujet très vaste est
morcellé en de nombreuses sous-disciplines (comme la biochimie, la cytologie⋆ , la génétique
des populations) en fonction du niveau auquel se situent les observations (respectivement
moléculaire, microscopique, et populationnel).
Ce découpage a conduit à une grande diversité des données stockées. Nous pouvons en
distinguer deux classes : d’une part des données alpha-numériques (séquences ADN, descriptions des structures tri-dimensionnelles des protéines, informations phénotypiques,
publications médicales...) et d’autre part des données spécifiques au domaine (images
[BAD+05, KGKN02], graphes...). La variété des contenus a une influence directe sur la
variété des contenants ; l’information à stocker a souvent dicté les choix de conception
ou de solutions logicielles : l’image de micro-réseau⋆ tirée de la base SMD [GBB+ 03] et
représentée sur la Figure 1.1 est en pratique plus facilement enregistrable et manipulable
en tant que type binaire dans un serveur Oracle [ATLB03] qu’en tant que lien XLink
[WL02a] dans un fichier semi-structuré.
14 Une
entreprise gère en moyenne 40 bases de données et consacre 35% de ses investissements informatiques à leur intégration [KK02].
21
À l’inverse, un réseau de régulation génétique⋆ tel que celui de la Figure 1.2, (tiré d’un article de Gambin et al. [GLR06]) aux interactions nombreuses et souvent bi-directionnelles,
peut être aussi bien représenté suivant le modèle relationnel qu’à l’aide d’un schéma XML.
Les conflits qui surviennent entre les données résultent des différences de perception,
de modélisation et d’interprétation des entités du monde réel par les concepteurs des
systèmes d’information15 .
Fig. 1.1 – Micro-réseau
1.2.2
Fig. 1.2 – Réseau de régulation génétique
De l’hétérogénéité...
En évoluant indépendamment, les sources ont adopté chacune leur propre modèle de
données, leur langage de requêtes, et leur format d’exportation, que la littérature a détaillés à de nombreuses reprises [HK04, DOB95, FB02, OJ03]. La résolution de ces conflits
est l’objectif de nombreuses approches qui diffèrent par les méthodes et les moyens qu’elles
mettent en œuvre. La taxonomie⋆ des conflits peut être définie suivant trois grandes dimensions de variation, mais celles-ci ne sont pas spécifiques et limitées au domaine biologique,
15 Le
fait que le point du vue du concepteur ait un poids prépondérant sur la modélisation est appelé
relativisme sémantique par Parent et Spaccapietra [PS96].
22
puisque des problématiques similaires se retrouvent également en géographie par exemple
[Bis98, AMR06]. Précisons que même lors de l’utilisation d’applications informatiques
strictement identiques, des différences au niveau de l’implantation physique des données
schématisées, de leur typage ou du choix d’une modélisation structurelle différente16 introduisent une difficulté supplémentaire pour permettre à au moins deux systèmes de
s’échanger des données de manière cohérente.
1.2.2.1
...au niveau syntaxique :
L’hétérogénéité syntaxique est causée par les différences entre plateformes logicielles, et
les formats qu’elles manipulent. Des informations identiques peuvent donc être enregistrées
soit en utilisant des notations formelles telles qu’ASN 1.0 [ASN] ou Fasta [NCB06a], soit
du XML, du HTML ou des SGBD relationnels ou objets. Ainsi, nous pouvons voir sur la
Figure 1.3 un même gène modélisé selon quatre formats de représentation différents.
L’utilisation de fichiers plats est encore aujourd’hui le standard de facto, ce qui nécessite
une phase d’extraction de données afin de retrouver la structure des données originelles.
Le développement du langage XML et des technologies qui y sont liées (notamment autour
du langage Java avec par exemple les API⋆ JAXP [Gri05], JAXB [McL02], ou le médiateur
XQuare [Odo05]) permet de plus en plus de simplifier les échanges de données biologiques
[AVB01]. L’interprétation de l’information intégrée reste malgré tout un problème crucial
à résoudre.
1.2.2.2
...au niveau sémantique
L’hétérogénéité sémantique peut être considérée à deux niveaux, décrits par Bishr
[Bis98] :
☞ au niveau cognitif, elle révèle les visions conceptuelles opposées qu’ont les communautés de recherche à propos d’entités du monde réel à modéliser. Un des exemples
les plus marquants sur les différences de conceptualisation concerne l’entité gène.
Steffen Schulze-Kremer [SK98] en compare deux définitions : dans la base de données GDB [Int06], un gène est un brin d’ADN qui peut être transcrit et traduit
en protéine ; dans GenBank [NCB06b] et GSDB [KBC+ 96], un gène est un fragment d’ADN d’intérêt biologique, portant un nom précis et qui est vecteur d’un
trait génétique ou phénotypique particulier. Cette dernière définition prend donc en
compte des morceaux d’ADN qui n’interviennent pas dans la constitution d’une
protéine, et il en ressort une contradiction avec la première définition.
même gène de souris est identifié par un locus⋆ dans la base MGD [MGD06] et par l’aggrégation
de plusieurs exons⋆ dans GenBank [NCB06b].
16 Un
23
HTML
<table border="0" width="100%" cellpadding="1" cellspacing="1">
<tr>
<td nowrap="nowrap">Entry name</td>
<td width="100%">
<b>IL12B_HUMAN</b>
</td>
</tr>
<tr>
<td nowrap="nowrap">Primary accession number</td>
<td>
<b>P29460</b>
</td>
</tr>
<tr>
<td nowrap="nowrap">Integrated into Swiss-Prot on</td>
<td>April 1, 1993</td>
</tr>
</table>
ASN 1.0
Seq-entry : := set {
descr {title "Interleukin-12 subunit beta" ,
update-date std {year 1991 ,month 5 ,day 17} ,
source { org {taxname "Homo sapiens" , common "human" ,
db {db "taxon" , tag id 9606}}}
}}
FASTA
>IL12B|chr5|-|158674369|158690059
GATTACAAAGAAGAGTTTTTATTAGTTCAGCCTCAGAATGCAAAAATAAA
ATACATTACTTAAAAGTAGCACCTTCATGGAGCCATATTTTCTGGTCATA...
XML
<SNPPER-RPC SOURCE="*RPCSERV-NAME*" VERSION="$Revision : 1.38$" GENOME="hg17"
DBSNP="123">
<GENEINFO>
<GENEID>16348</GENEID>
<NAME>IL12B</NAME>
<CHROM>chr5</CHROM>
<STRAND>-</STRAND>
<TRANSCRIPT><START>158674369</START><END>158690059</END></TRANSCRIPT>
</GENEINFO>
</SNPPER-RPC>
Fig. 1.3 – Divers formats pour les mêmes données
24
☞ au niveau de la nomenclature, elle se manifeste par des entités équivalentes identifiées par ou contenant des valeurs17 différentes. La Table 1.1 en montre un exemple,
où un même objet peut se trouver associé à des identifiants distincts. À l’inverse,
un seul et unique identifiant peut désigner plusieurs entités différentes. Cette situation peut également se produire au sein d’une seule et unique source, introduisant
des contradictions qui impactent la qualité de la source et la confiance qui lui est
accordée. La dénomination d’une information est une cause de conflit sémantique
(synonymie⋆ , homonymie⋆ ...), et engendre une incompréhension entre sources ayant
choisi des taxonomies distinctes. Un morceau d’ADN peut ainsi être indistinctement associé aux termes brin ou séquence. De la même façon, les conflits de valeurs
associées à un attribut peuvent fausser les interprétations : ceci se produit dans le
cas où les domaines de valeurs sont disjoints, si des différences linguistiques ou
des conflits d’échelle existent entre les sources, ou si l’échantillonnage d’une même
donnée s’est fait de façon continue ou discrète.
SwissProt Accession Number
P29460
EMBL
M65272, M65290
AY008847, AF180563
AF512686
GeneW
HGNC : 5970, IL12B
GeneCard
IL12B
Prosite
PS50853, PS01354
PS50835
Tab. 1.1 – Références croisées de sources différentes concernant le gène IL12B
Les conflits sémantiques sont donc dûs à la présence de données sujettes à des interprétations différentes, en fonction du contexte local dans lequel elles ont été utilisées. Le
contexte regroupe l’ensemble des informations implicites et explicites qui ont été prises en
considération lors de la phase de conceptualisation du monde réel, il a un impact direct
sur la qualité des données.
17 Des
tentatives d’uniformisation des identifiants utilisés par les bases de données bioinformatiques
voient peu à peu le jour ; le Consensus CDS [CCD06] s’est constitué autour de l’EBI [EBI06], du NCBI
[NCB06c], du WTSI [WTS06], et de la base UCSC [KBD+ 03] afin d’identifier un ensemble de régions
codant des protéines dans le génome humain, dont l’annotation serait de grande qualité. Les gènes intégrés
à l’ensemble CCDS se voient attribuer un identifiant unique, qui est désormais incorporé sur plusieurs
bases de données biologiques telles qu’Entrez Gene et Ensembl.
25
1.2.2.3
...au niveau qualitatif
La différence de qualité entre les sources est une notion subjective, puisque liée à
l’intérêt que portent les utilisateurs aux données. Elle s’explique par l’attention accordée
au raffinement des informations brutes directement issues des laboratoires. Les bases de
données biologiques peuvent être séparées en deux familles :
☞ les primaires contenant les données de base, typiquement ce sont des séquences de
gènes ou de protéines découvertes par des laboratoires de séquençage (Swiss-Prot
[Swi06], EMBL [EMB07], GenBank [NCB06b], DDBJ [DDB06]).
☞ les secondaires, des banques plus spécialisées, contenant des données raffinées soit
sur des domaines tels que la localisation d’un gène [Loc06], la structure d’une protéine [RSC06], le phénotype⋆ [OMI06], soit sur des espèces telles que la mouche
[Fly06] ou la souris [MGD06], soit des références sur des publications médicales
[Med06, Nat06].
Les bases primaires constituent la matière première à partir de laquelle la bioinformatique va produire les données des bases secondaires et construire de nouvelles connaissances.
Le Tableau 1.2, tiré d’un article de Lambrix et Jakoniene [LJ03], nous montre les provenances diverses et variées de données disponibles dans plusieurs sources. “La traçabilité
des données leur apporte une plus value non négligeable”, comme l’ont souligné Simmhan,
Plale et Gannon [SPG05], mais le raffinement d’informations en provenance d’une autre
base de données peut aussi entraı̂ner la répercussion d’une erreur d’une base à l’autre.
Source de données
C
GenBank
EMBL
DDBJ
ENZYME
PDB
MMDB
PROSITE
PRINTS
BLOCKS
SwissProt
×
×
×
×
×
P
BD
×
EMBL, DDBJ
GenBank, DDBJ
EMBL, GenBank
IUBMB
×
×
×
×
×
×
PDB
SwissProt
SwissProt
InterPro
GenBank, EMBL, DDBJ
Tab. 1.2 – Provenance des données : Chercheurs(C), Publications(P), Autres bases(BD)
26
Le crédit accordé à une source n’est pas le même suivant que l’information qu’elle
contient a été curée manuellement ou de façon automatique18 ; de même, le niveau de détail
varie d’une source à l’autre. La coopération entre deux sources de qualités différentes mais
traitant du même domaine peut aboutir à une incohérence dans le résultat si les données
sont contradictoires. L’utilisateur d’un système d’intégration, s’il a le choix entre plusieurs
sources à interroger, optera plus certainement pour celles qui offrent le meilleur rapport
entre qualité et coût d’exécution de la requête. L’indépendance des sources les unes visà-vis des autres et leur politique d’administration système (avec la plupart du temps la
mise en place de restrictions d’accès aux données) sont également deux autres facteurs
importants à prendre en compte.
1.2.3
Autonomie et capacités d’interrogation
La majorité des sources disponibles sur internet fonctionnent en mode totalement autonome. Autrement dit, les administrateurs et curateurs de ces sources sont tout à fait
libres de modifier leur schéma ou de mettre à jour leur contenu (ces sources fonctionnent
souvent sur le principe de mises à jour régulières, comme SwissProt [Swi06] par exemple)
sans en faire état préalablement aux utilisateurs. Aucune source ne tient compte des éventuelles références dont elle est l’objet ; or, en intégration de données, l’indisponibilité d’une
source pendant sa maintenance va influer plus ou moins fortement sur la qualité et la complétude du résultat d’une requête, problème qu’un outil d’intégration de données du Web
doit prendre en compte et résoudre, ou tout au moins signaler à l’utilisateur. La seule
solution afin d’avoir en permanence les données intégrées les plus à jour, est d’accéder à
celles-ci lors de l’exécution des requêtes.
Un facteur d’inconsistance supplémentaire des sources de données orientées Web est
leur grande dépendance vis-à-vis du réseau. Les performances des transferts sur internet
étant imprévisibles, “n’importe quel système d’intégration qui accède à des données du Web
hérite de cette imprévision” comme l’ont souligné Jagadish et Olken [JO03]. Les accès aux
données peuvent être effectués via un navigateur HTTP ou un logiciel client FTP, par
connexion directe sur la base de données (client dédié ou JDBC [Ree01] par exemple), ou
plus récemment encore via des appels de services Web. Concernant les interfaces hommemachine, chaque source propose ses propres fonctionnalités, ce qui suppose et impose à
l’utilisateur une phase d’apprentissage pour chacune des interfaces qu’il devra utiliser.
Des restrictions d’accès existent sur les sources, et certaines requêtes ne peuvent tout
simplement pas être exécutées. Ces limitations empêchent dans certains cas l’extraction
18 Ensembl
est annotée automatiquement [CEA+ 04] et SwissProt possède une équipe de curateurs
+
[OMG 02].
27
d’informations pertinentes, même si les données pour y répondre sont disponibles [Suj01].
Les motivations de ces choix s’expliquent :
☞ soit par la volonté d’assurer une qualité de service identique à tous les utilisateurs :
il n’est donc pas envisageable qu’un seul d’entre eux mobilise des heures durant la
puissance de calcul d’une source par une requête trop complexe
☞ soit pour des raisons de droits de copie des données : l’extraction massive d’informations est alors limitée volontairement par les propriétaires de la source
Souvent, les langages de requêtes proposés n’en sont pas réellement : le système d’interrogation est constitué uniquement d’un index de taille plus ou moins importante, et via des
formulaires accessibles dans des pages HTML, va chercher dans une ou plusieurs sources
les valeurs associées aux attributs choisis. Des langages de plus haut niveau plus expressifs
sont également utilisés, tels que SQL ou OQL.
L’intégration ne doit d’ailleurs pas simplement concerner les données brutes, mais aussi
permettre l’utilisation de ressources biologiques, telles que Blast⋆ [AGM+ 90], ou Fasta⋆
[LP85]. Ces opérateurs peuvent être disponibles ou non sur une source, et à l’instar des
données sur lesquelles ils s’appliquent, ne pas être équivalents en fonction de la source
considérée19 .
L’autonomie des sources les unes par rapport aux autres, l’hétérogénéité de leurs représentations, mais aussi les interfaces d’accès différentes et aux capacités d’interrogation
inégales rendent difficile, voire impossible leur utilisation combinée par des biologistes.
Les procédures permettant de collecter les données doivent autant que possible être automatisées, et c’est cette tâche qui échoit au système d’intégration, avec plus ou moins de
facilité en fonction de l’approche suivie.
19 Ceci
se produit en fonction de l’implémentation qui en a été faite : Blast par exemple existe en deux
versions, NCBI-Blast2 (développé au NCBI) et WU-Blast2 (développé à l’Université de Washington). Des
outils utilisant la première version de l’algorithme sont encore utilisés.
28
Chapitre 2
Classification des approches
d’intégration
Dans ce second chapitre, nous présentons un état de l’art articulé autour des différentes techniques d’intégration de données proposées jusqu’à aujourd’hui, et illustré par la
présentation d’architectures et de prototypes issus des recherches menées par les communautés informatiques et bio-informatiques. À partir de cette présentation et de la synthèse
de nos expériences précédentes, nous introduisons les choix qui nous ont orienté vers les
travaux présentés dans les deuxièmes et troisièmes parties de cette thèse.
Sommaire
2.1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
2.2
L’entrepôt de données . . . . . . . . . . . . . . . . . . . . .
32
2.3
La navigation entre les sources . . . . . . . . . . . . . . . .
38
2.4
Les accès par les portails et les plateformes logicielles . .
39
2.5
La fédération de données . . . . . . . . . . . . . . . . . . . .
40
2.6
L’approche multi-agents . . . . . . . . . . . . . . . . . . . .
41
2.7
La médiation de données . . . . . . . . . . . . . . . . . . . .
42
2.8
L’intégration P2P . . . . . . . . . . . . . . . . . . . . . . . .
45
2.9
Wrapper les sources, un problème commun à toutes les approches 47
2.10 Synthèse et discussion . . . . . . . . . . . . . . . . . . . . .
48
2.11 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . .
51
29
2.1
Introduction
À propos de l’évolution des méthodes d’analyse d’information, les auteurs de l’outil
d’intégration GeneCards [RCCPL98] avaient constaté, dès 1998, que la biologie moderne
est passée de l’époque“un gène, un post-doc”, à la manipulation de plusieurs milliers d’entités simultanément, ce qui “nécessite le développement de méthodes d’intégration efficaces”.
La classification des méthodes d’intégration peut se faire suivant plusieurs dimensions,
résumées sur la Figure 2.1. Deux axes20 principaux correspondent à ceux décrits par Susan
Davidson [DOB95] : le degré d’intégration des données, et la matérialisation ou non du
résultat intégré. Il faut ajouter à ces deux critères le temps de réponse, l’évolutivité du
système, et la fraı̂cheur des données intégrées.
Les méthodologies adoptées prennent souvent en compte la particularité des données
biologiques (Kleisli [DW03] par exemple utilise des types de données dédiés), mais seraient également de nature - moyennant quelques adaptations - à résoudre des problèmes
d’intégration dans des domaines différents de celui des sciences de la vie21 .
Détaillons tout d’abord les degrés de variation suivant le degré d’intégration en Figure 2.1. Une approche faiblement couplée se contente d’unir uniquement l’ensemble des
schémas locaux sous-jacents en un seul schéma. Les systèmes basés sur la collecte de données via des hyperliens suivent ce principe. L’utilisateur doit dans ce cas faire la part des
données complémentaires et redondantes : les étapes de nettoyage et de transformation
manuelles réclament donc un effort d’intégration humain supplémentaire. A contrario,
l’intégration fortement couplée de données nécéssite que les schémas locaux aient été
transformés en un modèle commun, et les correspondances résolues jusqu’au niveau sémantique ; typiquement, la construction d’un entrepôt valide ces étapes : dans ce cas,
l’intervention de l’utilisateur est minimale.
Relativement aux niveaux d’hétérogénéité définis en Section 1.2.2, différents niveaux
d’intégration sont donc possibles. L’intégration de données peut se faire uniquement au
niveau syntaxique, ou bien aller jusqu’au niveau sémantique. L’intégration syntaxique
20 Un
troisième axe est évoqué dans l’article que nous référençons, qui prend en compte le caractère
autonome ou coopératif du développement des sources de données ; il ne nous apparaı̂t plus utile d’en
tenir compte ici, puisque depuis 1995, date de parution de l’article, la coopération entre sources reste un
phénomène que l’on pourrait qualifier d’anecdotique.
21 Les Annexes A et B présentent respectivement un tableau récapitulatif des différents projets d’intégration de données biologiques, et un tableau comparatif des approches détaillées dans notre état de
l’art.
30
Fig. 2.1 – Classification des approches d’intégration (de 0 / faible à 5 / fort)
procède par l’emploi d’adaptateurs22 et consiste à convertir l’ensemble des données des
sources (qui peuvent suivre un modèle semi-structuré, relationnel, objet ou ne pas avoir
de structure particulière) dans le modèle unique choisi. À l’issue de cette phase, le schéma
global est uniquement constitué de l’union des schémas des sources. Il est question dans
ce cas d’intégration légère ou lâche23 . Si les sources offrent chacune des informations sur
des entités différentes, cette intégration est suffisante pour n’avoir aucune redondance au
niveau du schéma global. Mais si l’on souhaite intégrer plusieurs sources offrant des informations sur une même entité, une intégration sémantique avec correspondance de schémas
est nécessaire pour faire disparaı̂tre toute redondance au niveau du schéma global.
L’intégration sémantique est fondée sur la construction d’un schéma global intégrateur
(DTD⋆, schéma XML, schéma relationnel ou objet) et vise à convertir suivant ce schéma
les données des sources. Il est alors question d’intégration forte ou serrée24 . Elle peut se
faire selon deux axes : intégration horizontale ou verticale, appelées également intentionelle
ou extensionnelle 25. D’une part, l’intégration horizontale vise à intégrer les données en
créant une correspondance entre le schéma des sources locales et celui intégré.
22
L’anglicisme wrappers est également fréquemment utilisé.
loose coupling est utilisée dans la littérature anglo-saxonne traitant de ce sujet.
24 L’expression anglo-saxonne consacrée dans ce cas est tight coupling.
25 Les notions de sémantique intentionnelle et de sémantique extensionnelle se retrouvent chez Goh et
Bressan [GBMS99] sous les dénominations de knowledge-level et data-level, ainsi que chez Colomb [Col97]
sous les dénominations de fundamental semantic et structural semantic.
23 L’expression
31
Systèmes d’intégration ...
es
pié
co
t re
n
s so
les
do
e
né
nn
ée
sn
es
on
n
o
sd
le
... matérialisés
Base de données
universelles
tp
as
co
pié
es
... virtuels
Entrepôt de données
(Meta) moteurs
de recherche
Bases de données
fédérées
Médiateurs
P2P
Fig. 2.2 – Organigramme des systèmes d’intégration
D’autre part, l’intégration verticale vise à intégrer les données en identifiant la présence
des mêmes objets dans les sources ; ils sont donc regroupés cette fois-ci entre eux.
Le deuxième élément de distinction des approches d’intégration repose sur le fait que les
données sont ou ne sont pas matérialisées, comme le montre la Figure 2.2. À une extrémité
de l’arbre, nous trouvons donc les médiateurs de données, qui se contentent de décrire les
règles de transformation entre les schémas locaux et globaux, règles qui seront utilisées lors
de l’exécution des requêtes. Les seules instances accessibles à l’utilisateur sont dans ce cas
celles qui correspondent à la question posée au système. À l’extrémité opposée se trouvent
les entrepôts de données, qui produisent une copie physique des données intégrées.
Faire évoluer le système est une manœuvre plus ou moins simple en fonction de l’approche choisie ; restructurer un entrepôt est plus coûteux qu’un simple changement effectué
dans l’index des pages d’un outil d’intégration navigationnelle.
Enfin, le temps de réponse et la fraı̂cheur des données varient ensemble mais inversement selon que l’approche privilégie l’accès aux sources, ou les recopie localement ; ainsi
la médiation offre des données mises à jour mais le temps d’exécution de la requête peut
en pâtir, a contrario d’un entrepôt de données, qui accélère les traitements, mais est mis
à jour moins souvent.
2.2
L’entrepôt de données
Construire un entrepôt consiste à matérialiser localement les données récupérées sur
les sources, les transformer afin de les rendre compatibles avec le schéma global préalablement défini, faire la part des redondances et des complémentarités, puis exécuter des
requêtes sur les données consolidées. L’entrepôt de données, ou datawarehouse, est un
concept spécifique de l’informatique décisionnelle, issu du constat suivant : les données
de l’informatique de production (également appelée “informatique transactionnelle”) ne
32
se prêtent pas à une exploitation dans un cadre d’analyse décisionnelle. Les systèmes de
production sont en effet construits dans le but de traiter des opérations individuelles qui
peuvent impliquer différents métiers du laboratoire ou de l’entreprise, et surtout, ne se
préoccupent pas de leur compilation ou de leur historisation dans le temps. À l’inverse,
les systèmes décisionnels doivent permettre l’analyse par sujets ou par métiers et le suivi
dans le temps d’indicateurs calculés ou agrégés. Il est donc souvent indispensable de séparer ces deux mondes et de repenser les schémas de données, ce qui implique l’unification
des différents gisements de données en un entrepôt de données global (datawarehouse) ou
dédié à un sujet ou un métier (datamart).
Père du concept, Bill Inmon dans son livre “Building the Data Warehouse” [Inm02],
le décrit ainsi : “L’entrepôt de données est une collection de données orientées sujet,
intégrées, non volatiles et historisées, organisées pour le support d’un processus d’aide à
la décision.” Le datawarehouse n’est pas une simple copie des données de production. Il
est organisé et structuré, et se caractérise par des données :
☞
☞
☞
☞
☞
orientées métier
présentées selon différents axes d’analyse, appelés les dimensions
non volatiles : stables, en lecture seule, non modifiables
intégrées en provenance de sources hétérogènes ou d’origines diverses
historisées et donc datées : avec une conservation de l’historique et de son évolution
pour permettre les analyses comparatives (d’une année sur l’autre, par exemple)
Ces données sont conservées dans le datawarehouse :
➱ de préférence sous forme élémentaire et détaillée si la volumétrie le permet
➱ éventuellement sous forme agrégée selon les axes ou dimensions d’analyse prévus
(mais ces agrégations sont plutôt réalisées dans les datamarts que dans les datawarehouses proprement dits).
Les données élémentaires présentent des avantages évidents (conservation de la profondeur et du niveau de détail, possibilité d’appliquer de nouveaux axes d’analyse et même de
revenir a posteriori dans le passé) mais représentent un plus grand volume et nécessitent
donc l’utilisation de matériels plus performants. Les données agrégées présentent d’autres
avantages (facilité d’analyse, rapidité d’accès, moindre volume) mais il n’est pas toujours
possible de retrouver le détail et la profondeur des indicateurs une fois ceux-ci agrégés : les
données risquent d’être figées suivant une certaine vue, selon les axes d’agrégation retenus,
et il ne sera plus possible de revenir plus tard sur ces critères si le détail n’en a pas été
conservé. La Figure 2.3 détaille les différentes couches d’une architecture d’entrepôt de
données.
33
Sources hétérogènes et distribuées
Sources
OLAP
Extraire
Transformer
Charger
Mettre à jour
OLAP
Data Warehouse
Analyse
Requêtes
Rapports
OLAP
Data Marts
OLAP
Intégration
Stockage
OLAP
Fig. 2.3 – Architecture d’un entrepôt de données
La mise en place d’un système d’alimentation fiable du datawarehouse est souvent le
poste budgétaire le plus coûteux dans un projet d’informatique décisionnelle.
Le datawarehousing est donc un processus en perpétuelle évolution. L’entrepôt de données peut être vu comme une architecture décisionnelle capable à la fois de gérer l’hétérogénéité et le changement, et dont l’enjeu est de transformer les données en informations
directement exploitables par les utilisateurs du métier concerné.
Comparativement aux données classiques, la construction d’un entrepôt biologique
pose des problèmes spécifiques, que résume le Tableau 2.1 tiré d’un article de Dubitzky,
Krebs et Eils [DKE01].
Avantages et inconvénients de la construction d’un entrepôt
Construire un entrepôt nécessite d’abord une étude des sources à intégrer pour en dégager les informations pertinentes à stocker, puis une phase d’extraction des données.
L’insertion des données dans l’entrepôt est souvent précédée d’une série de nettoyages et
de filtrages visant à supprimer les redondances et possibles incohérences des données des
sources. Ces trois phases sont explicitées par la Figure 2.3.
L’architecture entrepôt est très utilisée dans le domaine biomédical ; elle est bien adaptée à certains besoins du domaine, et motivée par l’un au moins des trois points suivants :
1. certains domaines de recherche imposent une complète confidentialité des requêtes
et un contrôle total des données où l’accès distribué est alors impossible
2. les recherches biomédicales font souvent appel à des traitements nouveaux ou trop
complexes pour être effectués sur des données non rapatriées localement
34
Données classiques
Données biologiques
Grand nombre de requêtes sur des données connues a priori
Pré-agrégation facile puisque les processus sont évidents, stables et connus
Changements fréquents des requêtes
causés par de nouvelles hypothèses
Pré-agrégation difficile car les connaissances évoluent vite et se compliquent
Données stockées sur des systèmes propriétés de multiples organisations
Structures de données complexes difficilement réductibles à de faibles dimensions
Vue temporelle importante mais plus
complexe
Données propriétaires
Construction de N-cubes de dimensions
simples
Vue temporelle des données
Tab. 2.1 – Entrepôts commerciaux et entrepôts biologiques
3. l’architecture entrepôt, lorsqu’une intégration sémantique est effectuée, permet de
n’accéder qu’à des données nettoyées et sur lesquelles la confiance accordée apporte
une valeur ajoutée
Posséder une copie locale des données autorise un accès direct aux informations, l’exécution des requêtes s’en trouve facilitée et accélérée, car il n’y pas de risques d’engorgement
du réseau, ce qui peut se produire lors d’une connexion à des sources distantes. Le schéma
est adaptable suivant les besoins de l’utilisateur, et la création de vues concrètes optimise
les traitements des données fréquemment utilisées. Des cubes de données peuvent être
construits pour extraire les connaissances, en fonction des aspects à explorer ; ils peuvent
être retravaillés à la discrétion de l’utilisateur ; ces modifications, même si leur utilité peut
être avérée, ne seront évidemment pas répercutées sur les sources locales.
Néanmoins, la construction [Kim96, AH96] et la maintenance d’un entrepôt posent
de nombreuses difficultés [ECL03, AASY97, DLW00]. Tout d’abord, la recopie des données des sources a un coût matériel, donc financier. Une nécessité est d’être capable de
maintenir à jour les copies par rapport à des sources qui évoluent très rapidement, ce
qui est particulièrement le cas dans le domaine biomédical. Les changements intervenus
sur les données doivent être détectés et répercutés, rendant la mise à jour de l’entrepôt
difficile et souvent longue, même si elle se fait de façon incrémentale. Il faut aussi être
capable de prévoir un processus de rafraı̂chissement des annotations et des résultats des
traitements en fonction de l’évolution des données des sources. L’ajout d’une source ou le
remplacement d’une source obsolète obligent à recommencer la phase de construction. Les
35
entrepôts sont surtout basés sur le modèle relationnel et OLAP26 , qui sont peu adaptés à
la variabilité des données en biologie ; l’extraction de cubes peut s’avérer délicate car les
données y sont difficilement réductibles à de faibles dimensions. Enfin, les droits de copie
peuvent ne pas être acquis sur toutes les données servant à alimenter l’entrepôt.
Quelques exemples d’entrepôts
GEDAW Gene Expression DAta Warehouse [GMB+ 05] est un entrepôt de données développé au sein de l’équipe bioinformatique de l’INSERM U522 (Régulations des équilibres
fonctionnels du foie normal et pathologique) en collaboration avec l’IRISA de Rennes. Il
est spécialisé dans les données du transcriptome⋆ hépatique et dédié à l’analyse des données générées par son étude. Ces données sont de natures et d’origines variées, dont une
bonne partie se trouve disséminée dans des sources biomédicales sur le Web très disparates (au niveau des contenus et des structures), qu’il faut intégrer. La finalité de GEDAW
est de fournir une aide à la décision permettant d’orienter les recherches biologiques. La
fouille précise des données expérimentales enrichies par les données intégrées est destinée
à émettre des hypothèses qui vont ainsi guider la recherche sur le foie.
GEDAW utilise des techniques d’intégration à partir de sources de données structurées
ou semi-structurées uniquement (GenBank au format XML, GeneOntology, UMLS, et le
Transcriptome au format relationnel). GEDAW propose des règles de correspondance
pour regrouper plusieurs fiches de GenBank qui décrivent une même instance biologique,
en l’occurrence un même gène. Ces règles de correspondance peuvent être définies en
utilisant des alignements de séquences (si un BLAST entre deux séquences renvoie un fort
score de similarité alors les deux séquences sont relatives au même gène), ou encore en
utilisant l’inclusion de séquences (la séquence contenue dans une fiche est incluse dans
celle contenue dans une autre). Par son expertise, le chercheur biologiste peut lui aussi
émettre des règles de nettoyage des données.
Dans GEDAW, l’intégration se fait donc au niveau des schémas, essentiellement les
schémas de GenBank (définis par des DTDs), mais surtout au niveau des instances elles
mêmes avec une intégration horizontale et verticale. Dans le premier cas, des techniques de
détection des analogies structurelles et des correspondances ont été mises en place afin de
transformer les structures des sources vers une forme canonique (le schéma global). Dans le
second cas, la réconciliation des données se fait par regroupement d’entrées pour identifier
26 Online
Analytical Processing désigne les bases de données multidimensionnelles (aussi appelées cubes
ou hypercubes) destinées à des analyses complexes. Ce terme a été défini par Ted Codd en 1993 [CCS93]
au travers de 12 règles que doit respecter une base de données si elle veut adhérer au concept OLAP.
36
les instances. Cette identification se fait donc à l’aide de l’expression de critères pour faire
correspondre les entrées et éliminer les redondances et les divergences des informations.
GUS L’entrepôt GUS (Genomics Unified Schema [DCB+ 01, GUS05]) est le premier
grand entrepôt de données biologiques, et il est encore à l’heure actuelle le plus important. GUS est une plate-forme générique de gestion de données sur les organismes modèles
ou sur les maladies. GUS intègre des données très diverses, depuis les données génomiques
aux protéomiques en passant par les données transcriptomiques. Il offre en outre un support pour l’annotation semi-automatique, le nettoyage des données, la fouille de données
et l’analyse de requêtes complexes. GUS a un schéma générique. Il est en effet utilisé pour
stocker des données diverses : du génome complet (Plasmodb.org [BBC+ 02]) aux données
biomédicales liées au pancréas (EPConDB [MBG+ 07]).
Le schéma de GUS comporte plus de 180 tables divisées en 5 domaines distincts (provenance des données, ontologies utilisées pour annoter les données, séquences et annotations, données d’expression, données de régulation des gènes). GUS intègre de nombreuses
sources, notamment GenBank, SwissProt, Prodom, InterPro, GO, dbEST et dbSNP. Le
schéma de GUS est constitué de l’union des schémas des sources mais il possède aussi un
ensemble de tables fortement intégrées où les données sont le résultat d’une série d’algorithmes qui permettent l’unification des instances. Une sous-partie des données de GUS
est donc intégrée au niveau sémantique. C’est là la particularité de GUS : chaque utilisateur peut définir des traitements sur les données de l’entrepôt et choisir de regrouper les
entrées de son choix, il contribue ainsi un peu plus à l’intégration verticale.
gRNA genomic Research Network Architecture [LBC+ 02] est un environnement dédié
au développement d’outils destinés à l’intégration de sources biologiques. Son originalité
vient du fait que l’entrepôt est peuplé par des adaptateurs XML, qui transforment selon
des DTDs dédiées les données extraites des sources locales. Les données récupérées au
niveau des sources sont stockées dans une base de données relationnelle, interrogée grâce au
langage XomatiQ27 [BCL03] couplé à un transformateur de requêtes en SQL. Le résultat
est renvoyé à l’utilisateur après traduction des données relationnelles en XML. Deux
points négatifs sont à souligner : d’une part, les transformations de données qui ajoutent
une lourdeur importante aux traitements, et les DTDs de transformation des données qui
doivent être écrites à la main.
27
Ce langage est basé sur XQuery [KCD+ 03].
37
2.3
La navigation entre les sources
Cette approche s’inspire de ce que font habituellement les utilisateurs lors d’une recherche d’information sur le Web, qui implique une recherche de page en page par clic de
souris. Elle ne nécessite aucun apprentissage particulier d’un langage de requêtes dédié et
permet de choisir les sources à utiliser. Le schéma global présenté à l’utilisateur est facile
à construire, car il se contente d’unir ceux des sources entre eux. Les données des banques
sont ensuite intégrées en se basant sur leurs références croisées. En pratique, les requêtes
sont générées à partir de formulaires sur le Web, dont les paramétrages choisis sont transformés en expressions de chemin. Les résultats fournis par une première requête peuvent
être utilisés comme point de départ pour de nouvelles interrogations, qui peuvent ainsi
s’enchaı̂ner en cascade, à l’image de ce que proposent SRS [EUA96], DBGET/LinkDB
[FGM+ 98], ou Entrez [WBB+ 05].
Notons que comparé au nombre important de sources de données actuellement disponibles sur le Web, nombre qui a atteint 1078 selon les critères de Michael Galperin dans
son référencement publié chaque année dans le journal Nucleic Acids Research [Gal08],
le nombre de références croisées est faible. Les sources les plus importantes partagent
des identifiants, mais nombreuses sont celles, plus petites, qui soit adoptent un système
d’identification propriétaire, soit ne proposent que partiellement des références partagées.
Les systèmes basés sur le partage de références souffrent d’un manque de flexibilité lors
de l’ajout d’une source ; le calcul de toutes les interconnexions fait surgir le problème
N 2 [Mor03]. L’intégration navigationnelle atteint donc rapidement ses limites lorsque le
nombre de sources qui intéressent l’utilisateur augmente, et peut mener à des problèmes
de désorientation et de surcharge cognitive [Mar96]. L’expression des vues et des jointures
est difficile, puisque souvent limitée par le manque d’expressivité inhérent aux formulaires
de requêtes utilisés sur internet. Malgré ses défauts, l’intégration navigationnelle peut
avoir des avantages pour interroger rapidement des sources hétérogènes et distribuées et
confronter leurs informations. Elle ne nécessite pas d’apprentissage, et se présente comme
un moyen simple d’accélérer ce qui est fait encore aujourd’hui manuellement.
Quelques exemples d’outils navigationnels
SRS Sequence Retrieval System [EUA96, ZLAE02] s’apparente à un outil de recherche
basé sur des mots clefs, et non à un réel système d’intégration. SRS parcourt des fichiers
plats ou des bases de données, afin de créer un index des données, et les récupérer plus
rapidement lors de l’exécution des requêtes posées au système. Le résultat obtenu est une
liste de documents et de liens en relation avec les mots clefs fournis par l’utilisateur. SRS
utilise un modèle orienté objet, et propose l’interrogation de 130 bases de données, à l’aide
38
du langage Icarus (Interpreter of Commands And Recursive Syntax [MM97]).
GeneCards GeneCards [RCCPL98] est un outil d’intégration navigationnelle qui emprunte également un peu à l’approche entrepôt, puisqu’il stocke localement une partie des
données extraites des sources. GeneCards est dédié au regroupement d’informations sur
les gènes liés à des maladies humaines. Les pages Web qui présentent le résultat intégré
sont générées à la volée, par des scripts CGI28 qui accèdent à la fiche (card ) souhaitée et
la renvoient à l’utilisateur. L’extraction automatique d’informations à partir de plusieurs
sources est délicate sans vocabulaire standardisé ; forts de ce constat, les auteurs ont basé
le système sur l’utilisation d’une nomenclature standard issue des travaux du consortium
HGNC (HUGO Gene Nomenclature Committee [EDS+ 06]). GeneCards n’intègre d’ailleurs
que les sources facilement interrogeables via les termes de cette nomenclature, au moyen
de scripts CGI/Perl, regroupés dans le paquetage PLUK (Package for Locating Useful
Knowledge).
Les sources intégrées29 ont été sélectionnées pour leur fiabilité, et les facilités d’extraction de données qu’elles offrent. Afin de générer une fiche concernant un gène, des
scripts ad hoc procèdent à l’extraction de données à partir de copies textuelles des bases
concernées, ou via leur interface Web, à l’aide de la librairie dédiée LWP30 [Bur02]. Les
données ainsi obtenues sont ensuite vérifiées semi-automatiquement, et les faux-positifs
sont éliminés de l’ensemble. L’utilisation intensive de scripts différents pour chaque source,
et la lourde tâche de vérification manuelle du résultat intégré contrastent avec la volonté
de simplification à l’origine du choix d’un vocabulaire commun.
2.4
Les accès par les portails et les plateformes logicielles
Contrairement à l’intégration navigationnelle, les portails tels que Genera [LBié], Expasy [GGH+ 03], GenomeNet [KS99] ou Ensembl [BAB+ 04], ne font pas partie des systèmes multi-bases, et se contentent de donner accès, au travers d’interfaces plus ou moins
évoluées, à une ou plusieurs sources de données. La couche logicielle destinée à les interroger peut être constituée d’une page Web statique ou dynamique ; des restrictions sont
imposées aux utilisateurs, notamment pour l’exécution de requêtes qui sont jugées trop
28 Common
Gateway Interface (“Interface passerelle commune”) est une interface normalisée utilisée par
les serveurs HTTP.
29 GDB, MGD, OMIM, SwissProt, HGMD, Genatlas, et Doctor’s Guide.
30
Abréviation de libwwww-perl, ensemble de modules Perl dédiés à l’accès au Web.
39
coûteuses, comme celles contenant des jointures multiples, ou faisant appel à de nombreux
opérateurs.
Une autre forme d’accès aux données peut se faire via des plateformes logicielles telles
que Iogma/Genostar [Gen02] ou Imagene [MRDV99], qui fournissent des fonctions d’accès
aux données et une panoplie d’outils d’analyse. L’approche d’intégration utilisant des
clients lourds a été délaissée ces dernières années ; l’accent est aujourd’hui plutôt mis sur
l’utilisation de briques logicielles élémentaires, composables en fonction des besoins de
l’utilisateur.
2.5
La fédération de données
D’après Sheth et Larson [SL90], une base de données fédérée est “un système de bases
de données distribuées, hétérogènes et autonomes”. En se basant sur ce principe, ils ont
proposé un schéma d’architecture à cinq niveaux, qui reprend et augmente l’architecture
à trois niveaux ANSI/SPARC originelle [Dat03]. Une base de données fédérée est obtenue en considérant l’interopérabilité des différents systèmes de bases de données, appelés
composants. La Figure 2.4 en détaille les cinq niveaux :
1. le schéma local est celui d’une source attachée au système
2. le schéma de composant est le produit de la transformation d’un schéma local vers
un modèle commun de données préalablement choisi
3. le schéma d’exportation est un sous-ensemble du schéma de composant accessible à
la fédération
4. le schéma fédéré résulte de l’intégration de plusieurs schémas d’exportation
5. le schéma externe définit un schéma destiné à un utilisateur ou une application
particulière
Batini, Lenzerini et Navathe [BLN86] présentent plusieurs méthodes d’intégration des
schémas des sources afin d’aboutir à la construction du schéma commun ; cette phase
d’intégration peut être découpée en 4 étapes détaillées par Zisman et Kramer [ZK95] :
pré-intégration, comparaison des schémas, mise en conformité des schémas, et étape de
fusion/restructuration.
Plusieurs projets d’intégration de données biologiques ont adopté l’approche fédérée :
ENQUire [JMS96], Docking-D [Abe95], GDB [Fas94] ou TINet [EKJ01]. Ce dernier projet
utilise une approche de type base de données fédérée inspirée des travaux de Heimbigner
et McLeod [HM85]. Basé sur le modèle objet OPM [CM95], TINet propose un langage
40
...
...
Processeur de filtrage
Modèle
de données
commun
Schéma externe
...
Schéma externe
...
...
Modèle
utilisateur
Schéma externe
Schéma fédérateur
Processeur de construction
Schéma d’exportation
Schéma de composant
Processeur de transformation
Schéma local
...
Schéma local
...
Schéma local
Modèle
local
BD ou Composant
BD ou Composant
BD ou Composant
Fig. 2.4 – Fédération de bases de données
de requêtes proche de SQL, ainsi que la possibilité de stocker les résultats d’opérations
bioinformatiques, telles que des comparaisons BLAST.
2.6
L’approche multi-agents
Cette approche a été utilisée dans le cadre des projets ISYS et IGD-GIS. Le projet ISYS (Integrated SYStem) [STF+ 01] offre une architecture “plug and play” orientée
agents, grâce à laquelle les biologistes peuvent manipuler les données et les outils de leur
choix. Ces outils peuvent avoir été développés et être maintenus indépendamment les uns
des autres. Les composants échangent des informations sans avoir connaissance les uns
des autres, mais en s’adressant uniquement à des médiateurs en charge de diffuser leurs
messages. La manipulation des composants enregistrés auprès du système se fait à la discrétion de l’utilisateur ; ISYS se contente uniquement de suggérer les composants offrant
les traitements les plus adaptés aux données sélectionnées.
Dans IGD-GIS (Integrated Genomic Database - Genome Information System) [BLR97],
l’architecture proposée fait appel à un réseau d’agents communiquant entre eux via Corba
[GGM99] et KQML [FFMM94]. Tous ont une fonction bien précise, tel que l’agent EIA
41
(External Interface Agent) qui gère l’interface utilisateur, ou l’agent SCA (Selector Composer Agent) qui s’occupe de décomposer la requête globale en sous-requêtes destinées aux
sources de données locales. C’est une approche très modulaire et facilement extensible.
2.7
La médiation de données
Sources
Médiateurs
Clients
La médiation de données a été présentée pour la première fois par Wiederhold [Wie92]
qui en a donné la définition suivante : “un médiateur est une brique logicielle qui exploite
des connaissances sur des ensembles de données afin de créer de l’information pour les
applications des couches supérieures”.31 Un médiateur présente à l’utilisateur un schéma
global et un langage de requêtes qui lui donnent l’illusion de manipuler une seule et unique
source de données.
Application
Interface graphique
Navigateur
Facilitateur
Facilitateur
Médiateur
interaction
coordination
intégration
Médiateur
Adaptateur
Adaptateur
Adaptateur
Source de données
Source de données
Source de données
traduction
accès
Fig. 2.5 – Architecture de médiation DARPA I3
L’architecture de médiation de référence DARPA I3 représentée sur la Figure 2.5 comprend trois niveaux distincts :
☞ les sources de données : chaque source est couplée à un adaptateur qui assure la
communication avec les couches supérieures. L’adaptateur propose une vue homogène de la source à laquelle il est rattaché, et transforme les données afin qu’elles
correspondent au modèle de données commun utilisé par le médiateur. Son fonctionnement se résume à trois actions principales : accepter une requête exprimée
31“A
mediator is a software module that exploits encoded knowledge about some sets or subsets of data
to create information for a higher layer of applications.”
42
dans le langage compris par le médiateur, la traduire dans le langage de la source,
puis renvoyer le résultat calculé suivant le modèle de données du médiateur.
☞ les médiateurs : ils œuvrent à l’intégration de l’ensemble des sources de données
disponibles en présentant à l’utilisateur une vue globale des sources hétérogènes
et distribuées ; c’est le schéma global, ou virtuel, ou encore de médiation. Le médiateur32 est la pièce du système qui doit réécrire la requête globale en requêtes
locales destinées aux adaptateurs.
☞ les applications clientes : elles peuvent être de différentes natures, tels que des
clients lourds, des applications Web, ou bien un autre médiateur.
L’utilisation d’un médiateur pour intégrer les sources de données s’appuie sur une
transformation des requêtes lors de l’exécution. Une première phase, dite de réécriture
transforme l’expression de la requête globale en termes des sources locales, à partir de
règles de correspondance inter-schémas33 . Une fois les requêtes locales obtenues à partir de
la requête globale, le médiateur génère un plan d’exécution. Les réponses produites par ce
plan sont filtrées pour éliminer les éventuelles incohérences, puis retournées à l’utilisateur.
L’étape la plus importante lors de l’utilisation d’un médiateur est la création du schéma
global, et l’établissement des correspondances (mapping) avec les schémas locaux. Contrairement à l’entrepôt de données, ici le mapping concerne les relations qui existent entre
le schéma global et les sources locales. La spécification de ces correspondances - selon
la méthode utilisée - déterminera la difficulté de reformulation des requêtes, ainsi que la
facilité d’ajout ou de suppression de sources au sein du système. Deux méthodes sont couramment utilisées afin d’établir le schéma global. Soit les sources locales sont considérées
comme des vues34 sur le schéma global (LAV - Local-As-View), soit, à l’inverse, le schéma
global est considéré comme une vue sur les sources locales (GAV - Global-As-View).
Dans l’approche GAV [GMPQ+ 97, ACPS96], les relations du schéma global sont constituées à partir de celles des sources locales, et dans ce cas, la réécriture de requêtes s’avère
très simple, puisqu’il suffit de réaliser un simple chaı̂nage arrière sur les relations des
sources. Par contre, l’inconvénient majeur réside dans l’ajout ou la suppression d’une
source, puisque cela oblige à revoir le schéma global dans sa totalité.
Afin d’éviter ce genre de problème, l’approche LAV [LRO96a, FW97] définit chaque source
comme une vue sur le schéma global, ce qui facilite grandement l’ajout ou le retrait d’une
source, mais complique la réécriture de requêtes. En fait, ces deux approches ne sont pas
32 Au
niveau de la couche de coordination présentée en Figure 2.5 peuvent se trouver également des
facilitateurs, modules qui réalisent des rapprochements sémantiques, l’unification ou la réconciliation de
contextes, ou des conversions de formats.
33 Ces règles sont des méta-données fournies par l’utilisateur ou bien générées semi-automatiquement à
partir de la comparaison des schémas [RB01, RDM04].
34
Une vue est une relation virtuelle définie par une requête.
43
opposées, mais complémentaires, tout dépend du problème qui doit être résolu. Pour intégrer peu de sources, dont la plupart sont stables, mieux vaut utiliser la méthode GAV. Par
contre, dans le cadre d’une intégration à grande échelle, la méthode LAV est préférable,
car un changement important au niveau d’une source locale aura peu ou pas d’impact sur
le schéma global.
Pour dépasser les limites des approches précédentes et combiner les avantages de chacune,
des variantes ont été proposées par la communauté. Par exemple l’approche BAV (BothAs-View ) [MP03], qui utilise un ensemble de règles de transformation séquentielles bidirectionnelles entre les schémas, ou l’approche GLAV (Global-Local-As-View ) [FLM99],
qui associe à un ensemble de relations présentes dans les sources locales, un ensemble de
relations présentes dans le schéma de médiation. Commme nous venons de le voir, quelle
que soit l’approche adoptée pour l’établissement des correspondances, la construction et
l’évolution du schéma global est parfois ardue. La phase cruciale de réécriture devient
dans certains cas compliquée : NP-difficile si l’opérateur de différence peut être utilisé
dans la requête globale, ou si l’opérateur d’union peut être utilisé dans la définition des
vues [AD98, Hal01]. Enfin, la médiation accédant aux sources locales lors de chaque requête, la charge nécessaire au transfert des données sur le réseau peut être très importante,
obligeant rapidement à la mise en place de techniques de mise en cache [AKS98, HN96].
Quelques exemples de médiateurs
K2/Kleisli À l’origine, BioKleisli [DOTW97] intégrait des bases de données en proposant un médiateur qui utilisait un langage de requêtes fonctionnel dédié appelé CPL
[Won94]. CPL manipule des types de données complexes bien adaptés à la biologie, et
possède des librairies de fonctions spécialisées. La nouvelle version de BioKleisli, appelée
K2 [DCB+ 01] est une API qui permet d’interroger des sources de données génomiques via
le langage de requêtes OQL [CBB+ 00], en utilisant un modèle de données objet. L’utilisateur a la possibilité de définir ses propres types de données en K2MDL, un langage qui
combine les syntaxes d’ODL et OQL afin de spécifier les transformations de données en
provenance de multiples sources vers une seule cible.
Tambis Tambis [SBB+ 00] est un système d’intégration de données en temps réel basé
sur l’utilisation d’une ontologie de domaine pour la biologie moléculaire et la bioinformatique. Il propose une architecture de médiation et permet un accès transparent aux bases
de données. Etant construit sur une ontologie, il permet un classement automatique des
44
concepts grâce à l’utilisation d’une logique de description nommée GRAIL35 [RBG+ 97].
Son langage de requêtes est simple, car induit par l’ontologie, ce qui permet une uniformité quant à la dénomination et la signification des entités manipulées. Tambis utilise des
adaptateurs issus du projet BioKleisli afin d’accéder aux sources locales.
DiscoveryLink Ce projet d’IBM résulte de la fusion de Garlic [RS97] et de DataJoiner
[GL94] (qui lui-même était basé sur DB2 [Cha98]) et utilise une architecture de médiation
et des wrappers afin de proposer une couche intermédiaire d’accès aux données de plusieurs
sources biologiques. DiscoveryLink [HSK+ 01] utilise le modèle de données relationnelobjet ; il résout les problèmes d’hétérogénéité syntaxique, mais ne prend pas en compte
les différences sémantiques. Les requêtes sont soumises en SQL sur le schéma global, un
plan d’exécution est généré puis optimisé ; l’utilisateur n’a pas à se préoccuper des sources
locales, dont l’accès est géré par les adaptateurs. DiscoveryLink a désormais changé son
nom en Information Integrator [Are03], mais fonctionne toujours selon le même principe.
BACIIS Biological And Chemical Information Integration System [BMLL+ 04] est un
médiateur utilisant une base de connaissances ; celle-ci contient une ontologie de domaine
qui est utilisée comme schéma global. La base de connaissances contient également le mapping des sources locales vers l’ontologie. BACIIS intègre des bases de données traditionnelles mais également des sources de données Web ; les wrappers sont créés et maintenus
à jour par un système d’induction semi-automatique [MMD+ 05].
BioHavasu BioHavasu est une version biologique de Havasu [KNNV02]. Suivant l’approche Local-As-View, il intègre les bases de données UniGene, OMIM et Entrez-PubMed,
créées par le NCBI. Il s’apparente à un système d’agrégation de données, puisqu’il travaille
surtout sur des sources contenant toutes l’information souhaitée, plutôt que des informations complémentaires. Le processus de sélection entre les sources est basé sur celui de
BibFinder [NKH03, NFKWié].
2.8
L’intégration P2P
Les systèmes d’intégration actuellement les plus répandus proposent tous un schéma
global au travers duquel sont interrogées les sources de données. Ces architectures donnent
de bons résultats, mais passent relativement mal à l’échelle. La limitation principale
concerne le schéma métier, qui si les données sont très variées peut être difficile à construire,
35 GALEN
(Generalised Architecture for Languages, Encyclopedia and Nomenclatures in medicine) Representation and Integration Language.
45
mais aussi le fait que de nombreux utilisateurs souhaitent partager leurs données sans avoir
à en référer à un médiateur central.
La médiation de données dans des systèmes pair à pair (Peer Data Management Systems ou PDMS) est fondée sur une architecture décentralisée constituée d’un ensemble de
pairs, qui présentent chacun tout ou partie des données qu’ils contiennent. Les mappings
sont établis entre petits ensembles de pairs. Les systèmes P2P sont une généralisation
des systèmes de médiation, puisque certains pairs jouent le rôle de médiateurs vis-à-vis
des autres. Dans un système pair à pair, chaque participant est à la fois consommateur
(client) et producteur (serveur) de ressources et de services.
De manière à fournir aux usagers un accès uniforme aux sources de données, il faut être
capable de traiter les requêtes émises sur un tel réseau. Les besoins pour un PDMS sont à
l’intersection de ceux des systèmes distribués et des bases de données. Les problématiques
introduites par les PDMS par rapport aux SGBD classiques concernent la localisation des
données, la médiation dynamique (avec intégration de schémas et réécriture de requêtes),
ainsi que la volatilité des sources et l’évolution de la taille du système.
Quelques exemples de PDMS biologiques
Promethea Ce projet présenté par Claypool et Madria [CM06] classe les pairs constituant le réseau en deux catégories : les permanents et les passagers. Les nœuds permanents
doivent se conformer à une ontologie globale, PrOnto. Les nœuds passagers sont par contre
tenus de fournir les règles de correspondance entre leurs ontologies locales et l’ontologie
globale. N’importe lequel des pairs attachés au système peut être utilisé comme destinataire d’une requête.
The SEED Partis du constat que l’analyse comparée des génomes fait appel à des données publiques, privées36 et personnelles, Overbeek, Disz et Stevens ont créé et distribué
SEED [ODS04]. Cette suite d’outils est destinée à faciliter le travail collaboratif des chercheurs. Chaque instance de SEED permet aux utilisateurs d’accéder, de mettre à jour
et d’étendre la base de données d’annotations, tout en travaillant localement avec leurs
propres données, qui ne seront pas obligatoirement partagées avec le reste des pairs.
36
Mais dans de nombreux cas tout de même accessibles sous licence aux chercheurs.
46
2.9
Wrapper les sources, un problème commun à toutes
les approches
Quelles que soient les approches que nous ayons considérées dans les sections qui
précèdent, un problème apparaı̂t quant à l’utilisation d’adaptateurs. Au niveau des couches
les plus basses des architectures, matérialisées ou non, les wrappers sont directement au
contact des sources et vont, dans l’ordre :
1. traduire les requêtes provenant du système et les rendre compréhensibles par la
source
2. traduire les données provenant de la source pour les rendre compatibles avec le
système
En biologie, nous sommes la plupart du temps confrontés à des sources de données
ouvertes sur le Web, qui ne proposent pas de format de communication commun. Or, que
ce soit pour remplir un entrepôt de données, ou servir d’interface de communication entre
un médiateur et les sources qu’il intègre, les adaptateurs jouent un rôle prépondérant dans
l’une et l’autre de ces architectures. Dans le cas d’un entrepôt de données, le fonctionnement du système est articulé autour de la traduction des données, afin de les adapter au
format de la base qui va les intégrer. L’adaptateur joue dans ce cas le rôle d’intermédiaire
dont la fonction consiste à extraire massivement les données de la source concernée. Ceci
n’est pas le cas dans une architecture de médiation, puisque les adaptateurs jouent le rôle
de transformateurs des requêtes provenant du système vers les sources de données locales,
et en retour fournissent au médiateur les données dans un format précis, tel que le HTML,
le CSV ou le XML.
De façon pragmatique, la première solution envisageable consiste à écrire manuellement
des adaptateurs pour chaque source attachée au système. Cette phase de développement,
possible pour un nombre restreint de sources, devient rapidement irréalisable lorsque le
nombre de sources de données augmente fortement. Le développement d’adaptateurs dédiés à chaque source nécessite au préalable d’en faire une étude approfondie : les deux
objectifs d’une telle étude étant tout à la fois de comprendre le fonctionnement des moyens
d’interrogation disponibles sur la source, mais également le format dans lequel les données
seront renvoyées au système, puisqu’il faudra définir les règles de traduction de ce format
vers celui utilisé dans le schéma global. La génération entièrement manuelle d’adaptateurs
n’est pas une solution à privilégier dans le cadre de l’intégration, mais actuellement, l’écriture de wrappers ad hoc reste pourtant la solution la plus généralement mise en œuvre.
47
De nombreux travaux sur la mise au point automatique d’adaptateurs ont pourtant vu
le jour depuis plusieurs années37 ; une présentation globale de ces solutions peut être trouvée dans un article de Kuhlins et Tredwell [KT03], et dans un tutoriel donné par Sarawagi
[Sar02]. L’Annexe C présente un tableau récapitulatif des différents projets existants. Le
but de ces méthodes est dans la majorité des cas de reconstruire à partir des données
accédées tout ou partie de la structure contenue dans la base de données sous-jacente,
afin d’en extraire plus facilement les données ; cette approche est suivie par exemple par
le projet RoadRunner [CMM01]. Les techniques utilisées se basent principalement :
☞ sur l’apprentissage automatique à partir d’un ensemble de documents exemples ou
d’annotations fournies par l’utilisateur [MMK01, KWD97]
☞ sur l’identification de motifs répétitifs [BLP01a, EJN99]
☞ sur la création d’adaptateurs semi-automatisée, par l’utilisation d’expressions régulières [CL01]
Ces approches ne conviennent toutefois pas pour un grand nombre de bases biologiques.
C’est le cas notamment si elles font appel à des techniques d’apprentissage et que les
ensembles exemples ne sont pas disponibles, ou impossibles à constituer car les sources
n’ont pas assez de points communs pour en extraire une généralisation. Certaines sources
fournissent les données avec une absence complète de structure ; or la plupart des méthodes
nécéssitent une structure pré-existante et exploitent dans leur grande majorité la hiérarchie
des balises HTML ou XML.
D’autres approches semi-automatiques destinées aux sources du Web, telles que l’outil
d’extraction de données interactive Lixto [GKB+04] semblent les plus prometteuses car
plus faciles à mettre en œuvre : un adaptateur est généré à partir des sélections opérées
visuellement par l’utilisateur sur la source de son choix. Il est ensuite possible de le réutiliser dans d’autres pages à la structure similaire, ce qui suppose malgré tout une certaine
stabilité quant au formatage des résultats renvoyés par la source.
De façon synthétique, nous pouvons noter que l’extraction de données à partir des
sources reste en règle générale problématique, même dans le cadre de travaux d’intégration
de données du Web très récents [EBG+ 07].
2.10
Synthèse et discussion
Nous avons discuté dans cet état de l’art des principales architectures issues de la
recherche ou du monde industriel, et qui sont soit de réels systèmes d’intégration, matérialisée ou non (par la création d’entrepôts ou d’architectures de médiation), soit des
37 Ces
travaux ne concernent pas spécifiquement le domaine biologique, mais sont génériques, et peuvent
donc s’y adapter.
48
accès aux bases de données via des portails sur le Web. L’intégration réalisée par ces
projets est soit horizontale, soit verticale, selon que les données considérées se complètent
ou se chevauchent. Leur spécialisation respective les rend complémentaires, et aucun ne
peut prétendre s’imposer comme la solution universelle au problème d’intégration de données biologiques. L’utilisateur doit donc faire son choix en fonction de la complexité du
problème qu’il a à traiter.
Malgré les spécificités de chacune des approches disponibles, il est possible d’extraire un
certain nombre de caractéristiques communes que doivent présenter les outils d’intégration
de données sur le Web. Nos réflexions ont été alimentées par les retours d’expérience et les
conclusions que nous avons tirées de travaux précédents, qui traitaient respectivement :
☞ de la construction d’un médiateur de données géographiques en XML [BCE04]
☞ de l’alimentation d’un entrepôt biologique basé sur le modèle relationnel [Rog04]
Dans le premier cas, le modèle de données standardisé GML (Geography Markup Language) proposé par le consortium OpenGIS [Ope03], et très largement adopté par les
acteurs du domaine, a permis de simplifier les échanges en uniformisant le dialecte de
communication. Sur cette syntaxe XML a été développé un protocole de services Web
géographiques nommé WFS (Web Feature Service), qui facilite l’intégration syntaxique
des données. Nous avons donc mis en œuvre les langages GML et WFS pour construire
une architecture de médiation. Le modèle de données semi-structuré s’est avéré suffisament riche et flexible, tant pour l’expression du schéma global que pour l’échange de
données. Les requêtes écrites dans le langage GQuery [BC04a] basé sur XQuery [KCD+ 03]
permettent d’exprimer de façon simple des questions très complexes. Cependant, cette approche présente plusieurs inconvénients. En cause tout d’abord l’expressivité limitée du
langage WFS, qui oblige à rapatrier une quantité importante de données au niveau du
médiateur, pour leur appliquer opérateurs et traitements. Ensuite la difficulté de construction et de maintenance du schéma global sur lequel s’appuie le médiateur ; l’ajout ou le
retrait d’une source oblige soit à le revoir entièrement (dans le cas de l’approche GAV),
soit à ajouter un certain nombre de règles de correspondance (dans le cas de l’approche
LAV), qui risquent de compliquer d’autant la phase de réécriture de requêtes.
Dans le second cas, nous avons été confrontés à des sources de données biologiques dont
les modélisations sont très différentes, et pour lesquelles aucun standard d’échange n’a été
adopté. Les accès aux données par un navigateur Web ou une API dédiée et les langages
de requêtes (s’il en existe sur la source considérée) sont très différents et compliquent
la tâche d’intégration syntaxique. Le modèle relationnel n’est pas suffisamment flexible
pour s’adapter facilement aux changements de structure éventuels. Le langage SQL, très
performant pour les requêtes sur des données alpha-numériques, manque d’opérateurs
dédiés au domaine biologique, et il est difficile de lui en adjoindre.
49
Ces éléments de réflexion, accompagnés de contraintes spécifiques à la biologie, comme
la flexibilité dans le choix des sources, la traçabilité de la provenance des données, ou la
prise en compte de leur qualité, plaident pour une mise en œuvre flexible de l’intégration
de données, en laissant une grande marge de manœuvre à l’utilisateur.
Les systèmes d’intégration ne prennent pas ou peu en compte le problème crucial de
l’ajout et du retrait des sources participantes. Dans la majorité des cas, l’ensemble de
sources utilisé est fixe. Les choix sont donc limités au niveau de la sélection de sources
lors de l’écriture d’une requête adressée au système. Or, la présence ou l’absence d’une
source est un problème important qu’il faut prendre en compte, sans pour autant avoir à
reconstruire complètement le système.
Un modèle répandu comme le modèle objet-relationnel autorise l’utilisation d’une
grande diversité de types de données et de requêtes. Il a été utilisé avec succès dans
des domaines tels que la géographie. Le domaine biologique manipule des structures de
données très variées. Cette variété va du simple entier identifiant une séquence jusqu’au
graphe modélisant les influences mutuelles d’un groupe de gènes au sein d’une cellule. Il
est facile de stocker des graphes dans un SGBDRO, mais difficile d’exprimer des requêtes
qui testeraient l’isomorphisme 38 de deux graphes. Le modèle de données relationnel utilisé par Rogier [Rog04] permet d’interroger le système par des requêtes complexes écrites
en SQL, mais il est difficile d’y intégrer des outils de calcul de similarités de séquences
par exemple.
Le choix du modèle de données utilisé par le système d’intégration conditionne la richesse
d’expression des requêtes et les possibilités de faire évoluer les capacités du système par
extension de ce modèle.
Le contenu d’une source de données est un paramètre à utiliser, en plus de la connaissance de son schéma ; si le schéma de la source existe mais qu’elle ne contient aucune
donnée pertinente pour la requête à traiter, il n’est pas intéressant de la faire participer
au processus d’intégration. L’utilisation de méta-données associées aux sources est un
impératif dans la phase de traitement des requêtes.
Les fonctionnalités offertes par l’outil d’intégration doivent s’accompagner également
d’un certain nombre de contraintes à respecter, qui sont caractéristiques du domaine biologique. La possibilité de sélectionner les sources est une caractéristique souhaitée, de même
que la traçabilité du résultat, qui doit également être conservée. Les références partagées
entre les sources doivent être utilisées dans la phase d’intégration afin d’identifier leurs
éléments communs plus facilement, et ainsi mettre en évidence les éventuelles incohérences
38 L’isomorphisme
est une bijection qui permet de passer des arêtes de l’un à celles de l’autre ; typiquement cette opération est utilisée lors de la recherche de motifs dans les réseaux de régulation génétique,
qui modélisent les interactions entre gènes d’un organisme.
50
entre données d’origines diverses.
La recherche de l’efficacité est un objectif majeur à atteindre, puisque les volumes
de données à traiter sont très importants. Les requêtes adressées aux sources de données
doivent utiliser leurs caractéristiques, telles que la capacité à traiter des requêtes évoluées,
ou leur puissance de calcul.
Concernant la qualité des données, la biologie a ceci de particulier que des résultats
peuvent s’avérer intéressants, même si preuve est faite de leur incomplétude. Cet état de
fait plaide pour l’utilisation d’un modèle de données semi-structuré, qui permet une plus
grande flexibilité.
2.11
Conclusion
Nous avons rédigé dans cette première partie un état de l’art des problèmes actuels,
et présenté une liste exhaustive des solutions proposées jusqu’à présent pour l’intégration
de données, en particulier biologiques.
L’objectif de l’intégration est de combler le fossé qui existe entre créateurs et utilisateurs de données, mais vouloir intégrer l’ensemble des bases de données actuellement
disponibles et en partie listées par Galperin annuellement [Gal08] ne serait ni raisonnable,
ni crédible.
Les sections précédentes ont mis en évidence qu’il est important de proposer des solutions d’intégration suffisamment génériques et flexibles, capable de faciliter l’ajout et le
retrait des sources et des ressources attachées au système.
Il ressort de nos différents constats une demande de plus en plus pressante de la part
des biologistes pour le développement de méthodes et d’outils capables d’automatiser ce
qui est réalisé manuellement aujourd’hui, mais aussi capables de joindre de façon simple
les informations extraites de plusieurs sources. Nous traitons ce problème dans la première
partie de cette thèse, en proposant un formalisme de description des sources associé à une
méthode de calcul des jointures entre les données qu’elles partagent.
Le problème d’hétérogénéité syntaxique entre les sources est le plus simple à résoudre,
alors que l’hétérogénéité sémantique demeure difficile à identifier et à traiter. C’est à
cette problématique que nous nous attaquons dans la deuxième partie de cette thèse, en
proposant une architecture d’intégration des sources basée sur XQuery, où l’utilisateur
définit lui-même l’association entre les sources et le système, le tout accompagné d’un
algorithme de réécriture de requêtes prenant en compte l’hétérogénéité sémantique.
51
52
Deuxième partie
Automatisation de recoupements
manuels de données
53
Dans la deuxième partie de cette thèse, nous nous intéressons à l’utilisation des références
croisées entre des sources qui limitent les interrogations possibles sur leur contenu. Nous
présentons un formalisme de description des capacités des sources de données du Web, qui
est ensuite associé à une méthode de résolution basée sur la logique des attributs destinée
à calculer l’ensemble des jointures qui peuvent être établies entre les sources qui partagent
certains de leurs paramètres. Nous mettons ces méthodes en œuvre afin d’automatiser la
collecte de données dans le cadre de la recherche de gènes impliqués dans des maladies
multi-factorielles et la vérification croisée de données contenues dans des puces à ADN.
55
56
Chapitre 3
Partage de références entre sources
biologiques
Dans ce chapitre, nous présentons la première problématique d’intégration de données
que nous avons abordée, tirée d’un besoin concret soumis par des biologistes. Notre approche vise à l’intégration maximale des données présentes, à partir d’un petit nombre de
paramètres d’entrée fournis et d’une liste de sources visées. Les sources biologiques présentent des capacités d’interrogation limitées, tout en partageant de nombreuses références
les unes avec les autres. Nous montrons comment l’utilisation de ces liens syntaxiques peut
mettre en relation des données distribuées, et permet de contourner dans certains cas le
problème posé par les restrictions d’accès. Nous exposons comment, faute de pouvoir trouver une référence commune entre deux sources, l’utilisation de sources intermédiaires est
nécessaire et suffisante afin d’y récupérer des références supplémentaires, et ainsi poursuivre la phase d’intégration.
Sommaire
3.1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . .
58
3.2
Objectifs et exemple illustratif . . . . . . . . . . . . . . . .
58
3.3
Formulaires Web et interrogations limitées . . . . . . . . .
60
3.4
Exploitation des références croisées . . . . . . . . . . . . .
62
57
3.1
Introduction
Nous avons été amenés à nous intéresser à la conception d’un outil d’intégration de
données, capable de confronter rapidement des informations extraites de sources du Web,
en réponse à un problème posé par des biologistes à propos de la malaria. Cette maladie
parasitaire demeure l’une des plus dangereuses, responsable de la mort de 2 millions de
personnes par an, et de l’infection de 300 à 500 millions d’autres. Il s’agit d’un problème de
santé majeur, non seulement parce qu’un tiers des humains vit dans des zones impaludées,
mais aussi parce que le réchauffement climatique actuel déplace les maladies tropicales
sous d’autres latitudes.
3.2
Objectifs et exemple illustratif
La malaria dépend de plusieurs facteurs, tels que des structures de santé inadaptées,
des conditions socio-économiques difficiles, l’environnement, et les caractéristiques génétiques de l’hôte et du parasite : il s’agit très clairement d’une maladie multi-factorielle.
Par analyse de liens génétiques au Burkina Faso, deux groupes de gènes probablement impliqués ont été découverts sur deux zones chromosomiques. La première est en 5q31-q33
sur le chromosome 5 [FKA+ 03, RTA+ 98], et la seconde en 6p21-p23 sur le chromosome
6 [RAT+ 98]. Ces régions contiennent respectivement 400 et 700 gènes, déjà connus ou
non. Les zones d’intérêt sur les chromosomes ont donc été clairement circonscrites, mais
il existe trop de sources de données pour prédire manuellement quel gène est plus qu’un
autre susceptible d’être impliqué dans l’évolution de cette parasitose. Nous avions abordé
un exemple typique mettant en œuvre cette succession de manipulations dans des travaux menés précédemment [Rog04, Dai04], et avions mis en pratique une première fois
nos réflexions à l’aide du médiateur de données Médience [Méd03], qui utilise le modèle
relationnel. Puis nous avions fait évoluer notre outil afin de privilégier la médiation de
données semi-structurées avec XML [CSB06].
Vu la complexité de ce problème et l’évolutivité des sources, il existe donc toujours une
demande forte afin d’établir des listes de gènes prioritaires en leur attribuant un score et
guider les études des généticiens. La maladie étant multi-factorielle, les sources à intégrer
peuvent être très nombreuses, mais dans le cadre de notre scénario, nous nous sommes
limités aux sources de données biologiques proposées par nos collaborateurs. Il serait très
facile d’étendre la liste à d’autres sources de données, par exemple traitant des habitudes
alimentaires, et qui pourraient mettre en évidence un facteur de résistance jusque-là passé
inaperçu.
La découverte de gènes impliqués dans une maladie multi-factorielle est l’un des pro58
blèmes typiques que l’intégration de données peut aider à résoudre. Cette question biologique a été le point de départ de notre réflexion.
Chromosome 5
Phase 1
Collecte de données
Liste complete
Phase 2
Calcule des scores
Liste prioritaire
Phase 3
Vérifications expérimentales
5q31−q33
Fig. 3.1 – Phases de l’étude d’une zone d’intérêt sur le chromosome 5
L’approche de collecte39 que nous présentons ici répond à une problématique simple :
confronter rapidement des données, pour ensuite leur appliquer des méthodes de prédiction
et d’extraction d’information. L’outil de regroupement a donc pour but d’être utilisé afin
d’alimenter en données un logiciel ou un entrepôt, qui leur appliqueront des opérateurs
d’analyse de données définis par l’utilisateur. Ces différentes étapes sont présentées en
Figure 3.1, nos travaux s’intéressant particulièrement à la première phase. Les difficultés
sont grandes et les contraintes à prendre en compte nombreuses : les sources et ressources
biologiques du Web sont multiples, réparties, redondantes, évolutives, contradictoires et
de fiabilité parfois difficile à estimer. Les données renvoyées par le système doivent ensuite
être traitées afin d’éliminer les éventuelles incohérences qui peuvent exister. Nous n’aborderons pas complètement ce problème dans les sections suivantes, puisque les phases de
curation et de prédiction se rattachent à d’autres thématiques de recherche, et non uniquement à l’intégration de données.
Le formalisme de description que nous avons défini, associé à la méthode d’appariement des sources que nous proposons va permettre à l’utilisateur, à partir d’un ensemble
d’attributs fournis, et des sources de son choix, d’obtenir un nombre d’éléments maximal
en relation avec ses paramètres d’entrée. Notre objectif est donc d’automatiser la join39
Nous utiliserons indifféremment les termes collecte et intégration dans les sections suivantes.
59
ture de proche en proche. Dans le cas où le résultat provenant d’une source ne peut pas
servir à interroger la source suivante, notre système ajoutera une (ou plusieurs) source(s)
intermédiaire(s) afin de compléter le parcours, et ainsi mener la phase d’intégration à son
terme.
Notre démarche a donc été de proposer une solution qui prenne en compte les capacités
d’interrogation limitées des sources, mais qui tire également parti du partage de références
afin de rassembler un maximum de données. Nous détaillons successivement ces deux
aspects dans les sections qui suivent.
3.3
Formulaires Web et interrogations limitées
Extraire des données à partir de sources ouvertes sur le Web se fait habituellement au
travers d’un interfaçage qui permet à l’utilisateur d’accéder aux SGBD sous-jacents, et
d’en obtenir un ensemble de tuples d’intérêt. Dans la littérature, la limitation de capacité
des sources est une problématique qui a été abordée suivant deux interprétations. La première fait référence au fait que de nombreuses sources nécessitent que certains paramètres
leur soient impérativement fournis [YLGMU99]. La seconde considère les capacités comme
l’ensemble des requêtes que la source peut exécuter conformément à un langage de requêtes
[VP02]. Dans nos travaux, nous ne considérons que la première signification, puisque les
capacités ainsi que l’expressivité des requêtes sont étroitement liées aux formulaires dédiés
à l’interrogation.
Jusqu’à présent, exceptées les sources d’importance majeure telles que SwissProt
[OMG+ 02], EMBL [EMB07], ou GenBank [BBLO97], la majorité des sources biologiques
librement accessibles sur le Web, listées par Galperin [Gal07] chaque année ne proposent
que des interfaces d’accès rudimentaires, et de fait leurs capacités d’interrogation se
trouvent limitées. Cette situation est causée par les politiques de partage des données
mises en œuvre par les instituts de recherche, dont des exemples peuvent être trouvés
dans les rapports de Genome Canada [Can05] ou du Wellcome Trust [Tru03].
L’utilisateur est en droit de se demander pourquoi les sources présentent de telles
restrictions ; les raisons sont multiples et peuvent être justifiées :
☞ simplement par le choix de fournir une interface d’accès simplifiée même si des
requêtes complexes peuvent être traitées par le système
☞ par la volonté de masquer certains attributs
☞ parce que l’administrateur souhaite que soient interrogées uniquement les données
sur lesquelles ont été mis en place des mécanismes d’optimisation d’accès, tels que
des index
☞ par le manque de moyens qui peuvent être mis en œuvre afin de proposer et main60
tenir une méthode d’accès plus évoluée, situation très fréquente dans les petits
laboratoires
Cette somme de motivations a été résumée en une phrase par Jamison [Jam03] :
“publier des données sur internet au travers d’une interface d’accès limitée est de loin le
compromis habituel entre la protection de la propriété intellectuelle et l’accès libre”.40
Plusieurs projets d’intégration de données du Web ont pris en compte les limitations
d’accès. Dans Information Manifold [LRO96b], les limitations d’accès aux sources sont
enregistrées dans des empreintes de capacité 41 ; les auteurs justifient leur utilisation par
le fait que les “sources d’information ne permettent en général qu’un sous ensemble de requêtes sur leurs relations”, il faut donc s’assurer que les “plans de requête générés puissent
être exécutés” effectivement. Les vues de recherche 42 présentées par Zoé Lacroix [Lac02]
représentent les “capacités des sources grâce à leurs attributs”, qui forment “un ensemble
de points d’entrée dans un script CGI, [...] une requête doit donc correspondre à l’un de
ces points d’entrée”. Quant au médiateur TSIMMIS [YLGMU99, LC00, LC01], développé
à l’université de Stanford, il utilise les capacités d’interrogation des sources afin de prendre
en compte le fait que les requêtes supportées par le système sont directement affectées
par leurs limitations.
Les sources de données du Web présentent des capacités d’interrogation limitées, ce
qui peut rendre le traitement des requêtes, même les plus simples, compliqué à mettre en
œuvre. Elles ne proposent comme informations sur leurs points d’entrée que la consultation d’un formulaire Web dans lequel l’utilisateur insère un ou plusieurs paramètres. Les
limitations des capacités d’interrogation empêchent le plus souvent d’obtenir massivement
les données : il est nécessaire de fournir impérativement des valeurs pour certains paramètres afin de pouvoir obtenir les enregistrements voulus. Dans le cas où les sources de
données ne peuvent pas directement répondre aux requêtes de l’utilisateur à cause de ces
restrictions, l’interrogation de sources intermédiaires peut donc s’avérer nécessaire.
Illustration par l’exemple : si nous considérons deux sources bibliographiques, MedLine
qui donne accès aux résumés des articles et DBLP qui liste les conférences. Supposons
qu’elles proposent respectivement des recherches par [titre ou auteur] et [conférence
ou auteur ou date]. Une recherche directe sur MedLine des résumés de la conférence
DILS’05 impose de connaı̂tre au moins l’un des deux critères. Il est donc plus simple
d’interroger d’abord la source DBLP sur le seul critère conférence, puis de reporter la
liste des auteurs obtenus dans le formulaire du site MedLine. Des sources qui ne sont
40“WWW
interfaces are by far the most common means of compromising between the need for IP
protection and making an algorithm freely available”.
41 Capability records.
42
Search views.
61
pas mentionnées dans la requête peuvent donc contribuer au résultat ; inversement, des
sources qui sont demandées peuvent ne rien apporter au résultat.
Nous exploitons donc une des caractéristiques particulières des sources biologiques sur
le Web, le partage de références communes, afin de pouvoir intégrer complètement les
données souhaitées en contournant les restrictions d’accès.
3.4
Exploitation des références croisées
En biologie, joindre les résultats des travaux de plusieurs laboratoires se fait aujourd’hui encore la plupart du temps par extractions successives à partir des interfaces simplistes présentées en Section 3.3. 43 . L’association entre les éléments de chacun des ensembles obtenus se fait ensuite de façon manuelle. Considérons par exemple une question
biologique simple à propos de la nomenclature de localisation⋆ des chromosomes :
“Quelles sont les publications concernant la région q31 du chromosome 5 ? ”
Plusieurs réponses sont possibles en fonction du choix, fait par le biologiste, des sources
à interroger. Une réponse typique à cette question met en œuvre deux sources : UCSC
[KBD+ 03] (contenant la cartographie du génome humain) et Pubmed [Nat06] (base de
données bibliographiques). La première étape consiste à extraire les listes de gènes depuis
UCSC, et à reporter ensuite les références obtenues dans le formulaire de PubMed. Le
croisement manuel des résultats nous apporte donc l’ensemble des résultats accessibles
sur ces sources, en fonction des paramètres qui ont été fournis. Le travail demandé pour
ce faible nombre de sources est déjà fastidieux, et prend des proportions qui deviennent
difficiles à gérer à partir de cinq ou dix sources, surtout lorsque l’utilisateur doit composer
avec les limitations d’accès aux données que nous avons déjà évoquées. Des simplifications
existent, puisque des liens hypertextes permettent souvent de basculer d’une source à
l’autre selon la valeur d’un paramètre ; c’est notamment le cas dans les bases de données
les plus connues telles que GenBank, ou SwissProt, que nous avons citées précédemment.
Quels que soient les objectifs de l’approche suivie, collecter sur internet des données de
proche en proche est possible et se trouve facilité dans le domaine biologique grâce à un
partage très important de références qui existe entre les sources. Même s’il est vrai que les
habitudes ou les enjeux financiers font que parfois “les scientifiques préfèreraient échanger
leurs sous-vêtements que leurs nomenclatures”44, la plupart des sources font référence à
des identifiants communs sur lesquels il est possible de s’appuyer afin de rassembler les
43 Le
plus souvent, il s’agit d’un formulaire dans le langage HTML, associé à un langage de script
hébergé sur le serveur.
44 Cette expression est attribuée à Keith Yamamoto, professeur de biochimie à l’Université de San
Francisco.
62
données. Les liens que nous considérons sont purement syntaxiques, basés sur la présence
d’un nom d’attribut commun entre deux sources, comme le montre l’exemple de la Figure
3.2. En cela, nous suivons la définition associée par Ullman [Ull90] aux relations universelles : “différents attributs partageant le même nom dans différentes relations ont la
même signification”. Nous ne prendrons pas en compte ces liens afin d’établir une relation
sémantique entre des entités biologiques hébergées sur des sites distants, l’interprétation
des données intégrées et la résolution des incohérences éventuelles restant à la charge de
l’utilisateur.
Source2
Source1
id2
référence
auteur
id3
id4
id1
date
gène
id2
Source3
Source4
id3
description
date
id1
id2
id4
publication
année
id5
Fig. 3.2 – Exemple de partage de références entre des sources
Regardons en détail les brèves descriptions des quatre sources présentées dans l’exemple
de la Figure 3.2 ; nous voyons que chacune possède un identifiant unique pour les données
qu’elle contient (indiqué en gras), mais aussi des références aux identifiants des autres
sources (indiquées en italique).
Sur notre exemple illustratif, plusieurs chemins peuvent être empruntés pour obtenir les
mêmes données. Supposons par exemple que l’utilisateur souhaite intégrer la description,
la référence et l’identifiant d’un gène à partir de l’attribut date de découverte qu’il connaı̂t,
en utilisant les sources Source1, Source2 et Source3 ; deux possibilités se présentent à lui :
☞ soit en interrogeant Source1, puis Source2 grâce à id2, et enfin Source3 grâce à id3
☞ soit en interrogeant d’abord Source3, pour ensuite réutiliser les identifiants qu’elle
possède afin d’interroger Source1 et Source2
La Tableau 3.1 synthétise les deux scénarios possibles. La collecte s’arrête dès qu’une
63
boucle apparaı̂t dans le parcours des sources.
Collecte de données entre S1, S2 et S3 à partir d’une date
Scénario 1
Requ^
ete avec une date sur S1
Scénario 2
Requ^
ete avec une date sur S3
➩
➩
Requ^
ete sur S2
à partir de id2 tiré de S1
Requ^
ete sur S1 et S2
à partir de id1 et id2 tirés de S3
➩
Requ^
ete sur S3
Tab. 3.1 – Deux déroulements possibles
Il faut noter que contrairement aux clefs étrangères des bases de données relationnelles, rien ne garantit entre sources du Web que la valeur de l’identifiant référençant
correspond bien à une valeur présente dans la source référencée45 . Aucun mécanisme d’intégrité référentielle n’est mis en œuvre entre sources distribuées ; ceci peut être la cause
d’incohérences dans le résultat intégré.
Cet exemple simple nous a permis de mettre en évidence qu’il existe plusieurs chemins
possibles pour obtenir les attributs demandés. Dans le cas d’un scénario réel, une difficulté
supplémentaire apparaı̂t à cause de la présence de façon certaine ou non d’un identifiant
entre deux sources, et par le fait que cet identifiant partagé le soit sous la forme d’un hyperlien ou non. Cette incertitude influe directement sur la cardinalité du résultat obtenu.
En fonction des sources utilisées pour la collecte, et par conséquent le chemin parcouru
pour intégrer les données, l’ensemble résultat sera donc différent. Dans le cadre de notre
approche, nous avons choisi de prendre en compte la totalité des chemins qui existent
entre les sources.
Dans un certain nombre de cas, il est impossible de satisfaire la requête de l’utilisateur
simplement à partir des sources qu’il a choisies. Cette situation est provoquée par les
limitations d’accès que nous avons présentées en Section 3.3. Sur notre exemple précédent,
ce cas de figure apparaı̂t si l’on souhaite extraire les publications de la source Source4
associées à des gènes extraits de la source Source1. Il est impossible de joindre les données
de ces deux sources sans passer par une source intermédiaire. La source Source2 doit donc
être utilisée alors qu’elle ne fait pas partie du choix de l’utilisateur, et qu’elle n’apporte
aucune information supplémentaire.
45
Un nom de gène par exemple peut avoir plusieurs dizaines de synonymes.
64
La Figure 3.3 montre la complexité des liens entretenus par des sources de données
dans un cadre réel ; cet exemple illustratif ne considère que quelques-unes des sources les
plus connues. Le nombre de liens n’est bien sûr pas aussi important en fonction de la
popularité de celles choisies par l’utilisateur ; nous donnerons les définitions des différents
types de liens que nous avons considérés en Section 4.1.
OMIM
PubMed
UCSC
SNPper
LocusLink
SwissProt
dbSNP
HGVbase
direct permanent
indirect permanent
direct potentiel
indirect potentiel
Fig. 3.3 – Liens présents entre plusieurs sources
L’exploitation des références partagées entre les sources biologiques afin d’intégrer les
données a déjà été le centre d’intérêt de plusieurs projets. Dans GenMapper [DR04], Do
et Rahm proposent une architecture basée sur un entrepôt qui enregistre en plus des données intégrées leurs références croisées, qui sont utilisées ultérieurement pour associer la
sémantique des différentes sources. Basés sur XML, les projets XMap [DSS02] et XProm
[DS04] ont pour objectif de formaliser le processus de collecte de données en une succession
d’étapes constituées par l’interrogation de ressources distantes ou locales. L’utilisateur a
la liberté de choisir les sources dont il a besoin ou bien celles qu’il préfère lors de la définition du scénario de collecte ; ces spécifications sont ensuite utilisées afin d’exécuter l’étape
d’extraction de données, puis l’utilisation des données extraites pour interroger la source
suivante du scénario ainsi programmé. De proche en proche, cette démarche produit le
résultat intégré attendu. XMap fonctionne en deux versions ; l’une interactive, nécessite
l’intervention de l’utilisateur pour spécifier le choix de la source, et réaliser l’extraction de
65
données, alors que la version automatique ne considère que la meilleure source (selon les
préférences fournies par l’utilisateur) et extrait automatiquement les données des pages
Web rencontrées.
Proposé par Mork et Halevy [MSHTH02], le langage PQL (“pickle”) est utilisé pour exprimer le plus simplement possible les types de chemins à suivre entre les sources, sans
les énumérer tous explicitement. Ces expressions de chemins sont utilisées dans le projet
d’intégration GeneSeek [MHTH01] afin de générer les plans d’exécution de requêtes.
Enfin, les travaux présentés par Lacroix [LMNR04, LPV+ 05] utilisent les URLs⋆ et les
clef étrangères afin d’établir des relations logiques entre des objets scientifiques hébergés
dans des sources distribuées et hétérogènes. Le graphe formé par ces références partagées
est mis à profit afin d’estimer le coût d’exécution obtenu en fonction du parcours effectué
entre les sources. Les cardinalités des liaisons entretenues par les sources sont utilisées
afin d’estimer la taille des résultats intermédiaires et finaux, et ainsi orienter en amont
l’écriture de requêtes.
Dans un domaine applicatif non plus biologique mais générique, les pages liées par des
références partagées sont regroupées sous forme de data webs dans l’article de Friedman et
Levy [FLM99] qui présente l’approche de médiation GLAV ; obtenir les données nécessite
donc de naviguer entre les pages considérées en suivant un chemin précis. Le projet Sight
[AMJR04] encapsule quant à lui les sites Web à l’intérieur d’agents logiciels, et crée des
workflows d’intégration de données en connectant la réponse provenant d’un agent aux
champs de requête d’un autre, de proche en proche.
Les propositions précédentes ont toutes exploité les références croisées entre sources
de données. Il s’agit à l’heure actuelle du moyen le plus simple et efficace, au vu des
contraintes rencontrées46 afin de mettre en relation des données biologiques distantes sur
le Web. Les attentes des biologistes étant de rassembler ces données et de leur appliquer
des méthodes de prédiction dont le but final est de détecter de nouvelles corrélations, de
mettre en évidence des relations biologiques encore inconnues, et d’ouvrir de nouvelles
pistes de recherche. Le manque de documentation sur les sources accédées ainsi que leur
multiplicité constituent souvent un handicap pour trouver où adresser les requêtes. Cette
situation particulière peut devenir avantageuse quand il s’agit de complèter ou vérifier une
information, tout en prenant en compte le fait que des données contradictoires peuvent
exister dans des sources concurrentes.
Néanmoins, les différentes approches que nous avons évoquées ne prennent pas en
46 Des
interfaces d’accès très hétérogènes, pas de méthode d’extraction de données générique, et un
traitement des requêtes limité.
66
compte plusieurs contraintes. En premier lieu, la possibilité qui existe qu’une source ait
plusieurs patterns d’accès différents sur un seul et même formulaire de requête, en fonction
de la combinaison opérée par l’utilisateur sur les paramètres obligatoires et facultatifs.
D’autre part, l’évaluation de tous les chemins qu’il est possible de suivre, en appliquant
deux méthodes :
☞ par le calcul des jointures possibles entre toutes les sources choisies par l’utilisateur
☞ si une jointure n’est pas possible, par l’utilisation le cas échéant de sources intermédiaires qui ne participent pas à la construction de la réponse, mais qui vont
permettre de propager la jointure entre deux sources
Nous présentons dans le chapitre suivant nos choix quant à la formalisation de ce
problème, basée sur la représentation des patterns d’accès aux sources par des termes de la
logique des attributs. Puis nous exposons un algorithme de calcul du parcours à effectuer
entre les sources. Nous suivons une approche orientée source : à partir d’une requête
posée, nous utilisons les caractéristiques des sources afin de générer des plans d’exécution
susceptibles de participer à la construction du résultat. Notre démarche s’inscrit dans
le cadre de l’intégration de données sans apprentissage d’aucune notion particulière en
programmation, ni construction de schéma intégré, ce qui lui confère une plus grande
flexibilité.
67
68
Chapitre 4
Intégration par union de jointures
Nous avons vu que les sources biologiques du Web présentent deux caractéristiques
principales : le partage de références communes, et des capacités d’interrogation limitées.
Forts de ces constats, nous proposons dans ce chapitre un formalisme de description des
capacités et une méthode de calcul du parcours à effectuer entre les sources. Nous présentons ensuite le prototype développé, destiné à automatiser la collecte de données.
Sommaire
4.1
Formalisation des descriptions des sources . . . . . . . . .
4.2
Représentation des patterns d’accès par des termes d’attributs 72
4.3
4.4
4.5
4.6
70
4.2.1
Identification des différents types de patterns . . . . . . . .
72
4.2.2
Description du formalisme et exemple illustratif . . . . . .
73
4.2.3
Expression des requêtes . . . . . . . . . . . . . . . . . . . .
80
Traitement des requêtes d’intégration de données . . . . .
81
4.3.1
Choix des vues initiales . . . . . . . . . . . . . . . . . . . .
82
4.3.2
Algorithme de calcul des chemins de jointure . . . . . . . .
84
4.3.3
Algorithme de traitement des requêtes . . . . . . . . . . . .
86
Prototypage et illustration par l’exemple . . . . . . . . . .
88
4.4.1
Format XML des termes d’attributs . . . . . . . . . . . . .
88
4.4.2
Extraction des données avec Lixto . . . . . . . . . . . . . .
89
4.4.3
Prototype développé, tests et performances . . . . . . . . .
92
Applications sur des données biologiques . . . . . . . . . .
99
4.5.1
Intégration de données et prédiction de gènes candidats . .
99
4.5.2
Construction d’un méta-moteur de recherche de gènes candidats100
4.5.3
Complétion et vérification de données de puces à ADN . . 103
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
69
4.1
Formalisation des descriptions des sources
L’un des objectifs principaux de l’intégration est d’offrir un accès simple et transparent
aux sources de données. Les sources biologiques auxquelles nous nous intéressons dans
cette deuxième partie se situent dans un contexte précis, dont nous avons détaillé les
éléments centraux en Sections 3.3 et 3.4 :
☞ les requêtes ne sont exprimées qu’au travers de formulaires Web, et il est souvent impossible d’accéder à une source uniquement à l’aide du critère fourni par
l’utilisateur
☞ le partage de références entre les sources permet de contourner les limitations imposées par les interfaces
Afin de formaliser le problème posé, nous allons tout d’abord préciser quelques définitions concernant les sources, leurs contenus, et les différents liens virtuels induits par le
partage de références.
Définition 4.1.1 (Source de données)
Une source de données S est une URL accessible sur le Web. Elle exporte vers
l’utilisateur un ensemble de vues sur les données qu’elle contient, qui seront notées Vi , i ∈ [1, m].
Une source de données contiendra donc une ou plusieurs vues. Nous avons préféré
utiliser le terme vue plutôt que le terme relation afin d’une part de ne pas prêter à
confusion avec la dénomination propre aux SGDB relationnels, mais aussi pour insister
sur le fait que les données accessibles peuvent être restructurées par rapport à leur format
original sous-jacent.
Définition 4.1.2 (Vue appartenant à une source)
Une vue V dans une source de données S est une entité scientifique définie par un
ensemble d’attributs, et notée V (a1 , ..., an). Pour chaque vue V , il existe i ∈ [1, n]
tel que ai soit l’identifiant unique de chaque tuple de la vue V . Pour tout j ∈ [1, n],
j 6= i, a j peut ne pas avoir de valeur. Nous noterons l’absence de valeur à l’aide
du symbole ⊥.
Comme nous l’avons détaillé en Section 3.4, la prise en compte du partage des références entre sources est fondamentale pour la problématique de collecte de données que
nous avons abordée. Nous définissons un lien entre deux vues comme suit :
70
Définition 4.1.3 (Lien entre vues)
Un lien existe entre deux vues V1 et V2 appartenant à la même source S ou à deux
sources distinctes S1 et S2 si les deux vues possèdent un attribut en commun.
Cette définition seule ne saurait suffire à prendre en compte la variété des liens qui
existent entre les sources. Nous complétons donc la définition précédente en précisant
plusieurs cas particuliers.
Définition 4.1.4 (Lien direct permanent)
Soient une vue VA (a1 , a2 , ...an) et une vue VB (b1 , b2 , ..., bm), avec a1 et b1 leurs
identifiants uniques. Le lien L entre VA et VB est qualifié de direct permanent
si et seulement si, ∃ i ∈ [2; n], j ∈ [1; m], ∀ T un tuple extrait de VA , ai = b j , et
un hyperlien permettant de passer directement de la page résultat de la source
contenant VA à la page résultat de la source contenant VB .
Définition 4.1.5 (Lien indirect permanent)
identifiants uniques. Le lien L entre VA et VB est qualifié d’ indirect permanent
si et seulement si, ∃ i ∈ [2; n], j ∈ [1; m], ∀ T un tuple extrait de VA , ai = b j . Cet
attribut ai pourra être utilisé afin d’interroger la source contenant VB .
Les liens permanents garantissent la possibilité de passer d’une source à l’autre en
collectant des données de façon certaine. Il est donc possible d’estimer la cardinalité du
résultat obtenu. A contrario, la présence de liens potentiels dont nous donnons la définition
ci-après introduit une incertitude sur la présence d’une valeur pour l’attribut concerné et
va jouer sur la cardinalité du résultat. Le fait que le lien soit direct ou non est pris en
compte uniquement lors de la phase d’extraction de données.
Définition 4.1.6 (Lien direct potentiel)
identifiants uniques. Le lien L entre VA et VB est qualifié de direct potentiel si et
seulement si, ∃ i ∈ [2; n], j ∈ [1; m], et ∃ au moins un tuple T extrait de VA tel que
ai = b j , et un hyperlien permettant de passer directement de la page résultat de
la source contenant VA à la page résultat de la source contenant VB .
71
Définition 4.1.7 (Lien indirect potentiel)
identifiants uniques. Le lien L entre VA et VB est qualifié d’ indirect potentiel si et
seulement si, ∃ i ∈ [2; n], j ∈ [1; m], et ∃ au moins un tuple T extrait de VA tel que
ai = b j . Cet attribut ai pourra être utilisé afin d’interroger la source contenant la
vue VB .
Les tuples de ces vues ne peuvent pas être extraits sous n’importe quelles conditions,
puisqu’existent des limitations d’accès, dont nous avions exposé les raisons de la mise
en place en Section 3.3. Ces limitations d’accès aux données peuvent être modélisées à
l’aide de patterns d’accès47 . Nous avons choisi de représenter ces patterns en utilisant le
formalisme proposé par la logique des attributs.
4.2
Représentation des patterns d’accès par des termes
d’attributs
Nous devons représenter par des patterns d’accès les limitations imposées par l’utilisation des formulaires destinés à interroger les sources de données. Or, plusieurs types
de patterns d’accès peuvent être attachés à une seule et même vue, dans le cas où plusieurs combinaisons peuvent exister entre attributs obligatoires ou facultatifs par exemple ;
chaque pattern représente donc une méthode d’interrogation de la vue. D’autre part, il
nous faut une méthode de comparaison entre patterns associés à deux vues distinctes, afin
de pouvoir déterminer si elles partagent des attributs, et si la valeur d’un attribut extrait
de la première source peut être utilisée pour interroger la seconde. Afin de prendre en
compte ces contraintes, notre choix s’est porté sur la logique des attributs. Ce formalisme
a déjà été mis en œuvre dans des approches d’intégration de données utilisant le contexte
telle que celle proposée par Mott [MR99], mais nous l’avions également utilisée dans des
travaux précédents, mais uniquement en ce qui concernait la description et la composition
de services [SCB06].
4.2.1
Identification des différents types de patterns
Un pattern d’accès sur une vue spécifie les attributs qui doivent être fournis ou non
à un formulaire afin d’obtenir les tuples correspondant à cette vue. Nous considérons
dans la suite qu’un pattern d’accès modélisera non seulement les champs obligatoires
47
Binding patterns.
72
et facultatifs d’un formulaire Web, mais également les attributs qui seront renvoyés à
l’utilisateur dans la réponse. Nous associons à un attribut d’une vue la lettre v s’il doit
être impérativement valué, la lettre l s’il est libre (facultatif dans la requête mais pouvant
être utilisé afin d’imposer plus de contraintes sur les résultats renvoyés) et la lettre o
s’il est potentiellement obtenable, c’est à dire faisant partie ou non du résultat sans qu’il
soit évidemment possible de préciser sa valeur lors de la requête. Un pattern d’accès sera
donc constitué d’un ensemble de règles de correspondances entre l’ensemble des attributs
définissant une vue V et l’ensemble de symboles {v, l, o}.
Définition 4.2.1 (Attributs et restrictions d’accès à une vue)
Soit une vue V (a1 , a2, ..., an). Nous noterons A (V ) l’ensemble des attributs de
cette vue. Pour un pattern d’accès P donné, les ensembles BP (V ), FP (V ) et GP (V )
désigneront respectivement les ensembles des attributs valués, libres et obtenables
de cette vue tels que :
• BP (V ) ∪ FP (V ) ∪ GP (V ) = A (V )
• BP (V ) ∩ FP (V ) ∩ GP (V ) = ∅
Plusieurs patterns d’accès pourront être associés à une même vue : par exemple, les
tuples d’une vue V (a, b, c, d), associée aux patterns d’accès {vvlo} et {llvo} pourront être
accédés en fournissant obligatoirement :
1. soit une valeur à l’attribut a, à l’attribut b et facultativement à c
2. soit une valeur à l’attribut c et facultativement aux attributs a et b
L’attribut d peut être obtenu dans la réponse, mais ne pourra pas servir de critère
discriminant pour la requête envoyée sur la vue. Nous allons maintenant exposer en détails
la représentation des patterns d’accès à l’aide de termes d’attributs.
4.2.2
Description du formalisme et exemple illustratif
Nous allons présenter brièvement la logique des attributs, dont une description détaillée peut être trouvée dans les articles de Rounds et Carpenter [Rou94, Car92]. La
logique des attributs est une logique de description qui inclut la quantification, la disjonction et la négation sur des termes d’attributs, telle que la définit Gert Smolka [Smo92]. Un
terme d’attributs48 dénote un ensemble d’objets caractérisés par leurs attributs. Dans leur
forme la plus simple, les termes d’attributs consistent en des conjonctions de paires [attribut : valeur ] nommées slots. La valeur d’un attribut peut être un littéral, une variable, ou
des termes d’attributs imbriqués. La syntaxe des termes d’attributs est synthétisée dans le
48
Feature term ou FT.
73
Tableau 4.1, où les attributs sont notés par les lettres f, g et h, et les termes d’attributs par
les lettres S et T. La logique des attributs capture les bénéfices des logiques de description
ainsi que des logiques du premier ordre : quantification, disjonction, intersection, union,
négation sur les attributs. Les termes d’attributs forment une algèbre booléenne, la distribution et les lois de Morgan s’y appliquent. Nous choisissons de noter |T | la cardinalité
d’un terme d’attributs T ; ceci donnera par exemple |[a1 : v1 , a2 : v2 , a3 : v3 ]| = 3.
Notation
Nom
Interprétation
⊤ ou []
⊥ ou {}
f :⊤
f↑
f↓g
f↑g
∽S
S⊓T
S⊔T
S⊒T
Top
Bottom
Existence
Indéfini
Convergence
Divergence
Complément
Intersection
Union
Subsomption
S =F T
Equivalence
Univers
Ensemble vide, inconsistance
L’attribut f est défini
L’attribut f n’est pas défini
Les attributs f et g sont égaux
Les attributs f et g ne sont pas égaux
Les termes d’attributs autres que S
Attributs communs aux deux termes
Union des attributs des deux termes
S subsume T (T est une spécialisation
de S)
Les deux termes d’attributs décrivent
le même ensemble d’objets
Tab. 4.1 – Syntaxe des termes d’attributs
Un terme d’attributs peut être qualifié de :
• clos, s’il n’a pas de variables libres
• fondamental, s’il est sans variables, convergence, ni divergence
• basique, s’il n’a pas de quantificateurs, d’implications, et si les compléments portent
uniquement sur les valeurs des attributs
• simple, s’il est basique et ne contient pas d’unions
• forme normale disjonctive, s’il est de la forme F1 ⊔ ... ⊔ Fn , où les Fi sont des termes
d’attributs simples
Enfin, deux termes d’attributs seront qualifiés d’orthogonaux s’ils n’ont en commun
aucun attribut. Afin de prendre en compte les différentes alternatives d’interrogation qui
existent sur un formulaire pour extraire des données, nous représentons l’accès à une vue
au travers d’un formulaire par un terme d’attributs en forme normale disjonctive.
74
Définition 4.2.2 (Pattern d’accès à une vue)
Un pattern global P d’accès à une vue exportée par une source de données sera
noté comme un terme d’attributs en forme normale disjonctive
P = {P1 , P2 , ..., Pn},
où chaque Pi est un terme d’attributs décrivant la vue et le caractère obligatoire
ou facultatif de ses attributs : ∀i, j ∈ [1, n], i 6= j ⇒ Pi 6= Pj
La Figure 4.1 et la Figure 4.2 présentent respectivement un formulaire de requête proposé par la base de données Esther [HRC+ 04], et la représentation d’une interrogation
possible de ce formulaire par le formalisme de la logique des attributs. Le pattern d’accès
associé est représenté par le terme d’attributs Author={[address :’v’,city :’v’,
e_mail :’o’],[address :’o’,city :’o’,e_mail :’v’]}, et la requête décrite en Figure 4.2 demande la liste des adresses email correspondant à une adresse et à une ville.
Maintenant que nous avons précisé la syntaxe de description des patterns d’accès aux
données, nous pouvons donc aborder l’autre partie de la problématique : comment utiliser ces représentations afin de joindre les données présentes dans plusieurs sources sur le
Web ? Puisqu’il nous faut réaliser une jointure de proche en proche, notre objectif est de
savoir, en considérant deux sources de données, si le résultat provenant de l’une peut être
utilisé afin d’interroger l’autre.
Author = { [address:"78 La Canebiere",
city:"Marseille",
e_mail:⊤ ]}
Fig. 4.2 – ...et terme d’attributs associé
Fig. 4.1 – Formulaire de requête...
Ceci revient à comparer les patterns associés à un même attribut présent dans les
deux descriptions des vues considérées. Deux patterns P1 et P2 seront compatibles entre
75
eux uniquement si au minimum tous les attributs marqués v de P2 sont valués par un
sous-ensemble des attributs de P1 ; si tous les attributs marqués l de P2 peuvent également prendre leur valeur dans le résultat fourni par P1 , nous dirons que les patterns sont
maximalement compatibles. Le Tableau 4.2 définit les compatibilités entre les attributs
des patterns d’accès P1 et P2 .
P1
P2
Compatibilité
Compatibles
v
v
oui
l
v
oui
o v
oui
Compatibles si les attributs v de P2 sont déjà valués
v
l
oui
l
l
oui
o l
oui
Incompatibles
v
o non
l
o non
o o non
Tab. 4.2 – Compatibilités entre les patterns associés à un attribut
La logique des attributs s’appuie sur une notion de consistance simple : chaque attribut
d’un terme ne peut avoir qu’une valeur. Si nous considérons le terme d’attributs T =
[con f erence : V LDB, con f erence : EDBT ], nous pouvons donc dire qu’il est inconsistant.
Sa valeur est l’ensemble vide : T = ⊥. L’unification de termes est l’opérateur utilisé pour
déterminer la consistance de termes d’attributs. Elle implique que l’intersection de termes
dont les attributs communs ont même valeur soit non vide. Pour comparer nos patterns
d’accès, nous avons donc besoin d’un opérateur supplémentaire, que nous désignerons par
opérateur de compatibilité.
Définition 4.2.3 (Opérateur de compatibilité)
Soient T1 
= [a1 : v1 , a2 : v2 , ..., an : vn ] et T2 = [b1 : w1 , b2 : w2 , ..., bm : wm ].



⊤ si ∀ j ∈ [1, m], b j : “v”, ∃ i ∈ [1, n], b j = ai (1)
T1 ⋓ T2 = ⊤ si (1) et si ∀ j ∈ [1, m], b j :“l”, ∃ i ∈ [1, n], b j = ai



⊥ sinon
76
L’opérateur de compatibilité ⋓ n’est pas commutatif, puisque l’ordre des vues importe,
s’agissant pour nous de savoir quelle est celle qui fournit les valeurs d’attributs qui seront
utilisées pour interroger la vue qui lui succède immédiatement. Nous mettons en œuvre
cet opérateur de compatibilité dans l’algorithme de calcul des liens entre vues, et dans
l’implémentation que nous exposons en Section 4.4.
Définition 4.2.4 (Vues joignables)
Deux vues V1 et V2 de patterns globaux P1 et P2 seront joignables si P1 ⋓ P2 = ⊤.
Maintenant que nous avons défini l’opérateur de compatibilité entre patterns d’accès,
il ne nous reste plus qu’à résoudre le problème d’intégration de données proprement dit,
à savoir qu’à partir d’un ensemble d’attributs dont il connaı̂t la valeur, et d’un ensemble
d’attributs qu’il souhaite extraire des vues, l’utilisateur doit établir une jointure entre les
vues des sources qu’il a choisies.
Considérons les sources présentées dans le Tableau 4.3 et les vues qu’elles contiennent.
Pour plus de simplicité, nous associons dans cet exemple une seule vue à chacune des
sources, et un seul pattern à chaque vue ; l’extension éventuelle à plusieurs vues par
source et plusieurs patterns par vue peut se faire sans difficulté particulière.
Source
Vue
Pattern d’accès
S1
S2
S3
S4
V1 (Article,Journal,Année)
V2 (Article,Journal)
V3 (Journal,Editeur,Prix)
V4 (Journal,Editeur,Prix)
P1 = {[Article : v, Journal : l, Année : o]}
P2 = {[Article : l, Journal : v]}
P3 = {[Journal : v, Editeur : l, Prix : l]}
P4 = {[Journal : l, Editeur : v, Prix : l]}
Tab. 4.3 – Quatre sources bibliographiques
Les liens entre les vues créées à partir de l’ensemble des attributs Article, Journal,
Editeur, Prix et Année peuvent être modélisés par un hypergraphe dont les nœuds sont
les attributs et les hyperarcs les vues, comme le montre la Figure 4.3.
Supposons qu’un utilisateur souhaite acheter en ligne un article dont le titre est a1, et
qu’il cherche à l’obtenir pour le prix le moins cher. La réponse sera calculée en réalisant
l’union des semi-jointures naturelles V1 ⋉V3 , V1 ⋉V4 , V2 ⋉V3 et V2 ⋉V4 , pour lesquelles le
titre sera a1.
En observant le contenu des vues détaillées en Figure 4.4, nous voyons que l’article
a1 est disponible sur les sites des journaux j1, j4, et j5. En examinant le contenu des
quatre vues, sans tenir compte de leurs restrictions d’accès, nous pouvons calculer la liste
77
V3
Prix
Editeur
V2
V4
Journal
Article
Année
V1
Fig. 4.3 – Hypergraphe des sources bibliographiques
des différents prix de l’article a1. Il s’agit de l’ensemble de valeurs {6e, 4e, 2e, 1e},
qui constitue la réponse complète à la requête posée par l’utilisateur. Si nous prenons
maintenant en compte les capacités d’accès limitées présentes sur les vues, le résultat est
bien évidemment totalement différent. D’après le Tableau 4.3, seul le prix de 6e peut
être obtenu ; en effet, nous ne possèdons comme point de départ que le titre de l’article,
utilisé dans la semi-jointure V1 ⋉ V3 ; nous appellerons ce résultat la réponse minimale,
qui n’est obtenue qu’à l’aide des vues participant directement à la réponse. Les autres
jointures ne produisent aucun résultat : V1 ⋉V4 requiert l’attribut éditeur, V2 ⋉V3 impose
de connaı̂tre le nom du journal, et V2 ⋉ V4 nécessite de fournir les attributs journal et
éditeur. En se basant uniquement sur les références disponibles, l’utilisateur n’obtient
donc en guise de résultat que le prix le plus élevé. L’utilisation de la vue intermédiaire
V3 dans la jointure V1 ⋉V4 aurait pu permettre d’obtenir l’article pour 2e de moins, en
utilisant l’affectation supplémentaire Journal =e1 sur la vue V4 . Par l’utilisation de vues
intermédiaires, nous obtenons l’ensemble résultat {6e, 4e} que nous appellerons réponse
maximale à la requête. La réponse maximale est un sous-ensemble de la réponse complète.
V1
a1
a2
j1
j3
V4
V2
2001
1998
a1
a1
a2
V3
j4
j5
j2
j1
j3
e1
e3
6e
5e
Fig. 4.4 – Contenu des vues exemples
78
j1
j2
j5
j4
e1
e1
e5
e3
4e
3e
2e
1e
C2
S
S3
S1
C1
S4
C4
S2
C3
Fig. 4.5 – Chemins de jointures entre les sources S1 , S2 , S3 et S4
Dans le cadre de cet exemple illustratif, nous voyons que la prise en compte de vues
présentes dans des sources qui ne font pas partie de la sélection opérée par l’utilisateur peut
aider à renvoyer un nombre plus important de résultats. Dans la suite, nous supposerons
que les vues sont toutes définies à partir d’un ensemble global d’attributs, et que deux vues
peuvent partager le même ensemble d’attributs. Nous appellerons chemin de jointure le
parcours qu’il est possible de réaliser entre les vues en fonction de leurs limitations d’accès.
Définition 4.2.5 (Chemin de jointure entre les vues)
Soient un ensemble S de sources Si , i ∈ [1, n], et l’ensemble V des vues Vi, j , j ∈
[1, m] qu’elles contiennent. Un chemin de jointure C entre ces sources est la liste
n
ordonnée des vues Vk ∈ V , dont les patterns Pk vérifient ⋓ Pk = ⊤. La vue V1 est
appelée vue initiale, et la vue Vn vue finale.
k=1
Etant donné un ensemble de sources, il peut exister plusieurs chemins de jointure
différents entre leurs vues, en fonction des valeurs initiales que fournit l’utilisateur, et des
attributs qu’il souhaite intégrer. Afin d’exprimer une requête sur un ensemble de sources,
nous utilisons également le formalisme de la logique des attributs. Notre algorithme de
calcul de chemins a pour objectif d’établir toutes les jointures possibles pour peupler
le résultat, en considérant la possibilité de rajouter des sources intermédiaires afin de
propager la jointure.
La Figure 4.5 schématise l’ensemble de sources S1 , S2 , S3 et S4 de notre exemple
précédent, et les différents chemins qui peuvent être empruntés pour intégrer les données
souhaitées par l’utilisateur. Une vue peut être initiale dans un chemin, et intermédiaire
ou finale dans un autre. Notre objectif est de parcourir tous les chemins possibles afin
79
d’intégrer un maximum d’informations, puisque comme nous l’avons vu précédemment
dans nos exemples, les données obtenues seront différentes en fonction des patterns d’accès
présents sur les sources.
4.2.3
Expression des requêtes
Suite à ces définitions préliminaires, nous pouvons maintenant donner la description
d’une requête exprimée en utilisant la logique des attributs. Ce formalisme présente l’avantage d’être simple et concis, et correspond précisément aux données que l’utilisateur a en
sa possession lorsqu’il souhaite intégrer des données.
Définition 4.2.6 (Expression d’une requête)
Une requête de collecte de données Q sur un ensemble de sources S sera notée
Q =< I , O , S , C >. Ce quadruplet est constitué des éléments :
☞ I = [a1 : {v1,1 , ..., v1,m}, ..., ak : {vk,1 , ..., vk,n}], liste des paramètres fournis par
l’utilisateur, sous la forme d’un terme d’attributs où chaque ai peut avoir une
ou plusieurs valeurs
☞ O = [ak+1 : ⊤, ak+2 : ⊤, ..., al : ⊤], liste des attributs présents dans les vues et
que l’utilisateur souhaite extraire, vérifiant ∀ i ∈ [k + 1, l], ∄ j ∈ [1, k], ai = a j
☞ S : ensemble des sources choisies par l’utilisateur parmi celles connues
☞ C = {C1 ,C2 , ...,Cn} : ensemble des chemins de jointure de la requête
Les termes d’attributs I et O vérifient |I ⊓ O | = |I | + |O |. Dans le cas contraire, cela
signifiera que les deux termes d’attributs ont un ou plusieurs éléments communs, ce qui
va à l’encontre de la Définition 4.2.6 : la requête sera considérée comme non valide.
Les chemins de jointure d’une requête Q vérifient deux propriétés supplémentaires qui
viennent complèter la Définition 4.2.5 des chemins que nous avons énoncée.
Définition 4.2.7 (Chemin de jointure d’une requête)
Un chemin de jointure Ci,i∈N∗+ = (V1 ,V2 , ...,Vn) appartenant à l’ensemble C d’une
requête Q =< I , O , S , C > est un chemin de jointure vérifiant les deux propriétés
suivantes :
• un attribut au moins de la vue V1 appartient au terme I , qui lui fournit ses
valeurs : ∃ j ∈ [1, k], a j : ⊤ ⊒ V1 et a j : ⊤ ⊒ I
• chacun des attributs du terme O est présent dans une des vues Vi , i ∈ [1, n] :
∀ h ∈ [k + 1, l], ∃ Vi,∈[1,n] , ah : ⊤ ⊒ Vi , et n vérifie n ≥ l − k + 1
Les vues qui ne vérifient pas la deuxième condition exposée en Définition 4.2.7 seront
appelées des vues intermédiaires. Pour les vues de l’exemple présenté dans le Tableau 4.3,
80
la requête cherchant les prix de l’article a1 sera représentée par Q =< I , O , S , C >, avec
I = [Article : {a1}], O = [Prix : ⊤], S = {S1 , S2 , S3 , S4 } et C = {C1 ,C2 , ...,Cn}, où chaque
Ci est un chemin de jointure de la requête. Il nous faut raisonner sur le terme I , le terme
O et les patterns d’accès aux vues afin de pouvoir calculer le contenu de l’ensemble C de
tous les chemins de jointure.
Nous avons donc développé un algorithme qui à partir d’une requête posée, essaye de
trouver le maximum de réponses possibles :
☞ soit directement à partir des sources choisies, si un chemin de jointure existe entre
leurs vues
☞ soit en ajoutant des sources intermédiaires à celles déjà sélectionnées, s’il n’est possible que d’obtenir un chemin de jointure partiel en utilisant seulement les sources
initialement choisies
Notre objectif est ici de récupérer autant d’informations que possible afin de répondre
à la requête de l’utilisateur. Les attributs redondants mais ayant des valeurs différentes
entre deux chemins de jointure sont mis à profit afin de confronter les données, et porter à
la connaissance de l’utilisateur que des contradictions existent sur certains éléments de la
réponse fournie. Le résultat final sera constitué par l’union de toutes les données extraites
des sources par le parcours des chemins de jointure, puis de la projection du résultat de
cette union sur les attributs appartenant aux termes I et O .
4.3
Traitement des requêtes d’intégration de données
À partir des informations fournies par le quadruplet Q =< I , O , S , C >, nous calculons
tous les chemins qu’il est possible de suivre pour répondre à la question de l’utilisateur,
et la réponse sera l’union des valeurs récupérées sur chacun des chemins parcourus. Le
traitement d’une requête se déroule en trois étapes :
1. d’abord le choix des vues initiales possibles parmi les sources que l’utilisateur a
sélectionnées
2. ensuite le calcul de proche en proche des chemins de jointures, éventuellement augmentés de sources intermédiaires
3. enfin la fusion des résultats tirés des chemins parcourus
Avant de présenter l’algorithme de calcul des chemins, exprimé en pseudo-langage,
nous allons détailler les principales étapes de la première phase.
81
SC
SI
ST
ST (ensemble des sources)
SC (sources choisies par l’utilisateur)
SI (sources intermédiaires potentielles)
Fig. 4.6 – Ensembles de sources contenant les vues utilisées pour traiter les requêtes
4.3.1
Choix des vues initiales
À partir des valeurs fournies par le terme d’attributs I de la requête Q , nous devons
trouver quelles sont les vues qui seront susceptibles d’être les vues initiales des chemins
de jointure. Ces vues sont extraites des sources choisies par l’utilisateur, qui font partie de l’ensemble SC sur la Figure 4.6 ; nous avons représenté également l’ensemble SI
des sources intermédiaires (qui peuvent être potentiellement utilisées pour joindre deux
sources de l’ensemble SC ), et l’ensemble ST , qui contient la totalité des sources connues.
Ces trois ensembles vérifient les propriétés :
• SC ∪ SI ⊆ ST
• SC ∩ SI = ∅
Pour savoir si une vue V peut être une vue initiale, nous devons examiner les attributs
communs que la vue possède avec le terme I . Si tous les attributs valués de la vue peuvent
être affectés à partir des valeurs fournies par I , alors la vue peut être sélectionnée.
Pour détecter les attributs communs aux termes d’attributs respectifs, nous ne pouvons
pas nous servir de l’opérateur d’intersection classique fourni par la logique des attributs.
En effet, si nous considérons les termes T1 = [a1 : val1 , a2 : val2 ] et T2 = [a2 : val2 ], leur
intersection T1 ⊓ T2 = [a1 : val1 , a2 : [val2 , val2 ]] = [a1 : val1 , a2 : val2 ] = [a1 : val1 , a2 : val2 ], car
l’opérateur calcule l’intersection des valeurs des termes d’attributs identiques, mais ajoute
les termes distincts présents dans les deux membres. T1 ⊓ T2 contient donc l’attribut a1 , ce
qui dans notre cas fausserait notre test. Nous avons donc défini un opérateur d’intersection
exclusive, qui ne considère que les attributs similaires dans le résultat de l’intersection de
deux termes.
82
Définition 4.3.1 (Intersection exclusive de termes d’attributs)
Soient T1 = [a1 : v1 , ..., an : vn ] et T2 = [b1 : w1 , ..., bm : wm ] deux termes d’attributs.
L’ intersection exclusive des termes T1 et T2 , notée T1 ⊓χ T2 est un terme d’attributs T non vide dont les attributs ai vérifient :
∀ i ∈ [1, n] et j ∈ [1, m], ai = b j ⇒ ai : vi ⊓ b j : w j = ai : vi
Si nous appliquons l’opérateur ⊓χ aux termes T1 et T2 de l’exemple précédent, nous
obtenons T1 ⊓χ T2 = [a2 : val2 ]. Afin de sélectionner les vues initiales, nous utilisons l’intersection exclusive entre le terme I dont les attributs sont marqués à la valeur v, et les patterns d’accès aux vues. Illustration par l’exemple : soient les termes I = [a1 : v, a2 : v, a3 : v]
et V = [a1 : o, a2 : v, a3 : o] ; le terme I ⊓χV = [a2 : v] montre que seul l’attribut a2 peut être
utilisé pour interroger la vue V . Le terme d’attribut I dont tous les attributs sont valués
à v sera noté I v .
Nous présentons ci-dessous l’algorithme de sélection des vues initiales que nous avons
développé, mis en œuvre dans la méthode SélectionVuesInitiales. Cette méthode prend
en paramètres l’ensemble de sources S d’une requête, et le terme d’attributs I v ; nous
obtenons en sortie la liste L I des vues initiales associées à une requête Q .
Algorithme 1 ChercherVuesInitiales(S , Iv)
Entrées: Un ensemble de sources S et le terme d’attributs I v
Sorties: La liste L I de vues initiales de la requête Q
LI ⇐ ∅
Tant que S 6= ∅ Faire
Choisir une source Si ∈ S
Pour toutes les vues Vi contenues dans Si Faire
Si Vi ⊓χ I v 6= {} Alors
Conserver le pattern d’accès de Vi tel que |Vi ⊓χ I v | soit le plus grand
L I ⇐ L I ∪Vi
Fin Si
Fin Pour
S ⇐ S −{Si }
Fin Tant que
Retourner L I
Nous utiliserons les attributs de l’ensemble I v restants afin de valuer des attributs de
type libre lors de la phase de parcours des chemins.
83
Analyse de la complexité de l’algorithme
Notre algorithme consiste en un parcours de l’ensemble des sources, et une comparaison
des patterns d’accès de leurs vues afin de trouver les vues initiales. Si nous désignons par
NV le nombre total de vues,la complexité sera de l’ordre de O(NV ).
4.3.2
Algorithme de calcul des chemins de jointure
À partir de l’ensemble des vues initiales, nous allons établir tous les chemins de jointure
qu’il est possible de tracer entre les sources sélectionnées pour la requête. L’algorithme
considère tout d’abord une vue initiale et cherche dans l’ensemble S les vues qui peuvent
être interrogées à partir des valeurs que la vue initiale fournit en résultat. Si plusieurs
sources peuvent convenir, nous dupliquons le chemin de jointure déjà créé, et ajoutons
les deux nouvelles vues respectivement à chacun des chemins. Dans le cas où aucune vue
de l’ensemble S ne satisfait, nous cherchons une source intermédiaire capable de nous
apporter des valuations d’attributs supplémentaires susceptibles de faire progresser notre
jointure.
L’Algorithme 2 présente le déroulement de la méthode ChercherCheminComplet, qui
à partir d’un chemin de jointure et de l’ensemble de sources, cherche à découvrir tous les
chemins de jointure possibles entre la vue finale du chemin et les sources restantes. Le
premier appel de cette méthode dans le cadre d’une requête Q est réalisé en fournissant
un chemin initialisé avec une vue initiale, et l’ensemble S tiré de la requête.
Les vues intermédiaires VI extraites de l’ensemble des sources SI vérifient :

V ⋓V = ⊤ si V est la vue finale du chemin de jointure courant
F
I
VI ⋓V = ⊤
F
pour au moins une vue V ∈ S
L’algorithme de construction des chemins de jointure énumère tous les chemins qu’il est
possible de suivre à partir d’une vue initiale. En désignant par NS le nombre de sources de
l’ensemble S, nous voyons que la complexité dans le meilleur des cas se produit lorsqu’il
existe une seule vue joignable à chaque étape de l’algorithme ; ceci donne une complexité
de l’ordre de O(NV ). Le pire des cas se produit si à chaque étape de l’algorithme, le
nombre de vues joignables est égal à la cardinalité de l’ensemble S ; la complexité est alors
de l’ordre de O(NV !). Si nous supposons qu’en moyenne, la moitié des vues sont joignables,
nous obtenons une complexité aussi élevée que celle dans le pire des cas. En pratique, un
très petit nombre de vues seront fortement similaires, nous serons donc toujours plus
proches de la complexité dans le meilleur des cas.
84
Algorithme 2 ChercherCheminComplet(C, S, EChemins)
Entrées: Un chemin de jointure C contenant sa vue initiale
Un ensemble de sources S
L’ensemble vide EChemins
Sorties: L’ensemble des chemins complets EChemins générés à partir du contenu de C
ListeVtmp ⇐ {}
Tant que S 6= ∅ Faire
VF ⇐ ChercherVueFinale(C)
ListeVtmp ⇐ ChercherVuesJoignables(VF , S)
Si Cardinalité(ListeVtmp ) = 1 Alors
Ajouter la vue de ListeVtmp en fin du chemin C
ChercherCheminComplet(C, S − {Vtmp}, EChemins )
Sinon Si Cardinalité(ListeVtmp ) > 1 Alors
Pour chacune des vues Vtmp de ListeVtmp Faire
Ajouter la vue Vtmp en fin du chemin C
ChercherCheminComplet(C, S − {Vtmp}, EChemins )
Retirer la vue Vtmp en fin du chemin C
Fin Pour
Sinon
Chercher une vue intermediaire VI dans l’ensemble des sources ST
Si une telle vue VI existe Alors
Ajouter la vue VI en fin du chemin C
ChercherCheminComplet(C, S, EChemins)
Fin Si
Fin Si
Fin Tant que
Ajouter le chemin C complet à EChemins
85
4.3.3
Algorithme de traitement des requêtes
Maintenant que nous avons défini les différentes phases nécessaires à la constitution de
l’ensemble des vues initiales et au calcul d’un chemin de jointure à partir d’un ensemble
de sources, nous pouvons détailler l’Algorithme 3, qui met en œuvre les procédures précédentes afin de traiter complètement la requête Q soumise par l’utilisateur. Nous mettons
en œuvre la sélection des vues initiales et le calcul des chemins entre les vues dans cet
algorithme plus général, qui s’occupe d’effectuer les jointures de proche en proche, ainsi
que d’unir les résultats.
Algorithme 3 TraiterRequete(Q )
Entrées: Une requête Q
Sorties: Un ensemble de tuples correspondant aux données voulues par l’utilisateur
/* L’ensemble de chemins de jointure est vide au début de l’exécution. */
C ⇐ {}
L I ⇐ ChercherVuesInitiales(S , I v)
Pour toutes les vues VI de L I Faire
/* Initialise un chemin de jointure avec la vue passée en paramètre. */
Ctmp ⇐ InitialiserChemindeJointure(VI)
EChemins ⇐ ∅
/* Recherche des chemins complets à partir de la vue initiale choisie. */
ChercherCheminComplet(Ctmp, S ,EChemins)
/* Si un chemin complet a pu être généré... */
Si EChemins 6= ∅ Alors
/* ...on l’ajoute à la liste. */
C ⇐ C ∪ EChemins
Fin Si
Fin Pour
Pour toutes les chemins Ci de C Faire
Interroger la vue initiale de Ci à partir des données de I
Tant que le chemin Ci n’a pas été parcouru Faire
Interroger la vue suivante de Ci avec les tuples obtenus de la vue précédente
Fin Tant que
Fin Pour
Pour chaque ensemble de tuples extrait d’un chemin de jointure Faire
Projeter le résultat sur les attributs du terme O
Fin Pour
Retourner l’ensemble des tuples produits par le parcours des chemins
86
À l’issue de l’exécution de la procédure de traitement d’une requête, l’ensemble résultat
peut éventuellement contenir des données redondantes, ce qui doit être pris en compte
par l’application de méthodes de filtrage des résultats, à la discrétion de l’utilisateur.
87
4.4
Prototypage et illustration par l’exemple
Nous avons mis en œuvre la représentation des patterns d’accès par des termes d’attributs, ainsi que les trois algorithmes présentés dans les Sections 4.3.1 et 4.3.2 en développant un logiciel permettant à l’utilisateur de spécifier les valeurs d’entrée de son choix, les
attributs qu’il souhaite obtenir (et qui seront utilisés dans la projection des tuples à la fin
de l’Algorithme 3), et les sources à utiliser. L’outil que nous avons développé calcule les
différents chemins possibles, et s’occupe de projeter et fusionner les résultats. Nous allons
détailler les choix que nous avons opérés concernant les éléments principaux du système,
à savoir :
• la représentation des patterns d’accès
• l’extraction de données des sources du Web de proche en proche
• l’union des résultats produits
4.4.1
Format XML des termes d’attributs
Nous nous sommes basés sur une représentation des termes d’attributs en langage
XML. Cette représentation est fondée sur un schéma XSD normalisé par l’ISO, dont les
groupes de travail s’occupent de définir une grammaire pour les structures de traits. Il
s’agit de la norme ISO 24610-1-2006, dont le schéma complet est détaillé en Annexe D.
Les Figures 4.7 et 4.8 montrent respectivement un terme d’attributs suivant la notation
classique utilisée dans les sections précédentes, et sa modélisation en XML.
<?xml version="1.0" encoding="UTF-8"?>
<fs>
<f name="attribut1">
<sym value="valeur1"/>
</f>
<f name="attribut2">
<sym value="valeur2"/>
</f>
</fs>
[attribut1:valeur1,
attribut2:valeur2]
Fig. 4.7 – Notation classique d’un FT
Fig. 4.8 – Notation XML d’un FT
Les modélisations XML sont ensuite lues et transformées en classes Java. Nous avons
utilisé une bibliothèque Java proposant les manipulations élémentaires sur les termes
d’attributs (création, unification et subsomption). Cette bibliothèque a été développée au
88
sein de l’équipe “Langue & Dialogue”49 du Loria [Dub03]. Nous lui avons ajouté la prise
en compte de la disjonction généralisée que nous utilisons pour représenter les patterns
d’accès. Nous lui avons également adjoint les opérateurs de compatibilité et d’intersection
exclusive qui correspondent aux Définitions 4.2.3 et 4.3.1. Conventionnellement, les fichiers
contenant les termes d’attributs portent l’extension .fsml, dont l’acronyme signifie Feature
Structure Markup Language.
Dans un souci de flexibilité plus important quant à l’évolution du schéma décrivant les
termes d’attributs, l’analyseur permettant la transformation des données XML en classes
Java est généré directement à partir du schéma XSD, à l’aide de JAXB50 [McL02]. JAXB
est une API⋆ fournie par Sun qui permet de créer des classes Java à partir d’un schéma
XSD, et inversement de créer un schéma XSD à partir de classes Java.
4.4.2
Extraction des données avec Lixto
D’une façon générale, pour qu’une application puisse exploiter les diverses et nombreuses informations disponibles sur le Web, ces informations doivent être extraites et
transformées aux formats de représentation avec lesquels elle est compatible. Cette tâche
est appelée Extraction d’Information (EI ). D’une manière plus formelle, une tâche d’extraction d’information est définie par ses entrées (documents textes, pages Web, etc.) et
par la nature des informations à extraire : des relations entre attributs ou des régularités
dans les documents. Il s’agit en général d’une relation entre attributs définie en extension
sous forme de k -uplets (enregistrements), où k est le nombre d’attributs. Une méthode
d’extraction est appelée “single-slot” (resp. “multiple-slot”) quand k vaut 1 (resp. k > 1).
Une page contenant un seul (resp. plusieurs) enregistrements d’intérêt, est appelée page
à enregistrement unique51 (resp. page à enregistrements multiples52 ).
Le programme permettant d’effectuer la tâche d’extraction d’informations est appelé
extracteur, ou plus couramment wrapper . Un wrapper est une procédure fondée sur le principe du “pattern-matching” qui, étant donné un ensemble de règles d’extraction, effectue
une recherche de motifs dans des documents. Une manière simple d’effectuer cette opération consiste à décrire manuellement les règles d’extraction pour un ensemble de pages
en entrée. Ces méthodes nécessitent généralement une bonne expertise en programmation
à l’aide des langages Java ou Perl par exemple. De plus, elles sont souvent inefficaces
en temps et sujettes à un taux d’erreurs important. Nous avions déjà mené l’expérience
49 Le
projet est disponible sur le site d’Azim Roussanaly, à l’adresse http://www.loria.fr/~azim/.
Architecture for XML Binding.
51 Single-Record page.
52
Multiple-Record page.
50 Java
89
1 S w i s s P r o t (X0 , X1) :−
2
n u l l ( , X0 ) ,
3
getDocument (X0 , X1 , d e f a u l t ) .
4 Entry name (X0 , X1) :−
5
S w i s s P r o t ( , X0 ) ,
6
subelem (X0 , ( . ∗ . body . ∗ . t a b l e . ∗ . t r . ∗ . td . ∗ . p . ∗ . con ten t ,
7
[ ( ” e l e m e n t t e x t ” , ” ” , s u b s t r i n g ) ] ) , X1 ) ,
8
b e f o r e (X0 , X1 , ( . ∗ . body . ∗ . t a b l e . ∗ . t r . ∗ . td . ∗ . p . ∗ . con ten t ,
9
[ ( ” e l e m e n t t e x t ” , ”Entry name ” , s u b s t r i n g ) ] ) ,
10
0 . 1 2 8 , 0 . 1 9 2 , X2 , X3 ) .
11 PrimaryAccessionNumber (X0 , X1) :−
12
S w i s s P r o t ( , X0 ) ,
13
subelem (X0 , ( . ∗ . body . ∗ . t a b l e . ∗ . t r . ∗ . td . ∗ . p . ∗ . con ten t ,
14
[ ( ”elementtext ” ,
15
” [ O, P ,Q] [ 0 − 9 ] [ A−Z , 0 − 9][A−Z , 0 − 9][A−Z , 0 −9][0 −9] ” , r e g e x p ) ,
16
( ”b ” , ” ” , s u b s t r i n g ) , ( ” f o n t −w eigh t ” , ”” , s u b s t r i n g ) ] ) , X1 ) .
Fig. 4.9 – Exemple de règles Elog
d’écriture d’adaptateurs ad-hoc dans le cadre du projet décrit dans le mémoire de DEA
rédigé par Rogier [Rog04] ; nous avions constaté à quel point ce type d’extracteur s’avère
fragile, en particulier du point de vue de la prise en compte des modifications des pages
ciblées : le moindre changement rend le wrapper inopérant.
De multiples approches permettent aujourd’hui d’extraire de l’information, ou plus
exactement de générer des wrappers, en intégrant les techniques d’apprentissage (approches semi-automatiques) ou en exploitant les régularités dans les documents (approches
automatiques).
Ces approches ne nous semblent pas adaptées :
• soit parce qu’elles font appel à des techniques d’apprentissage et que les ensembles
exemples ne sont pas disponibles, ou impossibles à constituer car les sources n’ont
pas assez de points communs pour en extraire une généralisation
• soit parce qu’elles cherchent à extraire des données suivant la régularité des pages,
et que l’utilisateur doit ensuite filtrer uniquement les informations qui l’intéressent.
Nous donnons une classification détaillée des différents outils selon l’approche qu’ils
suivent en Annexe C. La seule exception est l’outil Lixto [GKB+04] qui permet de générer des wrappers d’une manière interactive, en assistant l’utilisateur à la création de
programmes d’extraction très expressifs. À partir des sélections opérées visuellement par
90
Génération des U RLS
x


Requête X Query
−−−→
Extraction


y
←−−− Sauvegarde au f ormat X ML
Fig. 4.10 – Cycle d’interrogation entre plusieurs sources
l’utilisateur, Lixto génère un ensemble de règles exprimée en langage Elog53 [BFG01]. La
Figure 4.9 montre un exemple de wrapper qui extrait de la page Web du site SwissProt
la clef primaire des tuples renvoyés par la source de données. Le langage Elog extrait
les informations des pages Web à partir des balises englobantes, du contenu, de l’ordre
d’apparition dans le document HTML et des concepts sémantiques qui peuvent y être
rattachés. Lixto utilise ensuite les règles Elog ainsi définies pour extraire les informations
du document HTML et les traduire en format XML. Le document retourné à l’utilisateur
peut ainsi être aisément interrogé avec le langage XQuery, enregistré dans une base de
données native XML comme eXist [Mei03] ou bien relationnelle avec le transformateur
XQuare [Odo05].
Nous avons associé à chaque source de données un extracteur, soit écrit en langage
Elog, soit utilisant le protocole HTTP afin de rapatrier localement les résultats fournis par
la source au format XML 54 . Afin de générer automatiquement les requêtes adressées à
une source de données du Web, nous utilisons la possibilité d’interrogation offerte par les
URLs complétées de couples clefs-valeurs. Le cycle de génération de requêtes à l’adresse
des sites Web à partir des informations fournies par les données tirées du site précédent
est détaillé sur la Figure 4.10.
Les différentes étapes de ce cycle correspondent à l’exécution du parcours d’un chemin
de jointure entre plusieurs sources. Le double cadre entourant la phase de génération des
URLs est là pour signifier que cette étape est amorcée par les attributs fournis par le
terme I . L’initialisation se fait donc à l’aide des données fournies par l’utilisateur, puis se
poursuit de proche en proche à l’aide des données extraites d’une source qui sont utilisées
pour interroger la source suivante.
53 Un
langage basé sur des règles Datalog, qui utilise la structure arborescente des documents HTML
afin de localiser et extraire les informations.
54 Il est utile de préciser que lors de la phase d’implémentation et de test sur des données réelles, nous
avons pu constater combien les fichiers exportés au format XML sont parfois mal structurés, et la difficulté
que rencontrent les moteurs de requête XQuery lorsque les fichiers deviennent volumineux.
91
4.4.3
Prototype développé, tests et performances
Nous avons développé le logiciel dont l’interface est présentée en Figure 4.12 à l’aide
du Java Development Kit 5.0. Nous avons utilisé pour cela la bibliothèque graphique
Java SWT55 à partir de laquelle a été développé l’EDI⋆ Eclipse [GB06]. L’utilisation
de cette librairie graphique permet d’accéder directement à la gestion des composants
graphiques du système d’exploitation sur lequel l’application est exécutée. Ceci permet,
sans avoir à rien modifier au niveau du code source, d’obtenir le meilleur rendu visuel
disponible56 , puisque les boutons, menus et autres éléments graphiques manipulés seront
dessinés à l’écran à partir des modèles du système d’exploitation. Il faut également noter
un gain au niveau de la rapidité de l’interface développée par rapport à l’utilisation de
la bibliothèque Swing57 . Le Tableau 4.4 montre quelques-uns des chiffres significatifs du
prototype développé 58 .
Notre outil propose les éléments nécessaires au traitement d’une requête de la forme
Q =< I , O , S , C >. L’interface graphique est divisée en 5 zones présentées sur la Figure
4.12, et qui correspondent respectivement à :
1. la sélection des paramètres d’entrée I , des attributs O et de la liste de sources à
utiliser
2. la zone de choix des sources que l’utilisateur veut utiliser pour l’intégration de données
3. l’affichage du descriptif de la source de données
4. la liste des chemins de jointure générés
5. la présentation du résultat intégré après le parcours des chemins sélectionnés
Le bouton de sélection aléatoire de sources sélectionne un nombre de sources choisi par
déplacement du curseur situé en dessous ; les valeurs que peut prendre le curseur varient
entre 5 au minimum, et le nombre total de sources disponibles dans la liste complète. Cette
fonctionnalité a été utilisée principalement pour tester de façon aléatoire le comportement
de notre programme.
Exemple illustratif
Considérons l’ensemble de sources bibliographiques et les patterns d’accès de leurs vues
55 Standard
Widget Toolkit.
rencontrer les problèmes de positionnement ou de taille des composants comme lorsqu’une
application Java tourne sous Motif ou Windows.
57 Swing produit de multiples objets pour chaque élément graphique affiché, ce qui accroı̂t la lenteur
d’exécution ; voir l’ouvrage de Scarpino et al. [SHNM05] pour une discussion des forces et des faiblesses
de chacune des approches.
58
Ces statistiques ont été obtenues par le plugin Eclipse Metrics - http://metrics.sourceforge.net/
56 Sans
92
Lignes de code
Méthodes
Classes
Paquetages
7842
509
67
12
Jours/Homme
30
Tab. 4.4 – Détails du prototype
présentées dans le Tableau 4.5. La requête posée au système comprend les termes d’attributs :
I = [Article : {“TRDB - The Tandem Repeats Database”,
“OLAP over uncertain and imprecise data”}]
O = [Auteur : ⊤, Journal : ⊤, Prix : ⊤, Année : ⊤, Rédacteur en che f : ⊤]
Les sources choisies par l’utilisateur sont listées dans le Tableau 4.5 ci-dessous :
Source
Vue
Pattern d’accès
S17
S22
S23
S20
S25
V17
V22
V23
V20
V25
P = {[Article : v, Journal : o]}
P = {[Prix : o, Journal : v, Propriétaire : o, Pays : o]}
P = {[Auteurs : v, Année : o, ISSN : o, Editeur : o]}
P = {[ISSN : v, Editeur : l, Rédacteur en che f : o, Mois : o]}
P = {[Article : v, Pays : v, Auteurs : o]}
Tab. 4.5 – Patterns d’accès des vues sélectionnées
La requête ainsi exprimée cherche à obtenir les attributs du terme O à partir des
titres d’articles fournis dans le terme I . Sans prendre en compte de sources intermédiaires, nous n’obtiendrions que le chemin complet numéro 1, présenté en Figure 4.11.
La prise en compte des sources supplémentaires S3 et S34 (encadrées sur le chemin complet numéro 2) nous a permis d’intégrer plus de données et d’obtenir plus de tuples
< Auteur, Journal, Prix, Année, Rédacteur en che f >. Les éléments associés à l’article“OLAP
over uncertain and imprecise data” sont intégrés au résultat grâce à l’utilisation de ces
vues intermédiaires.
Nous avons mis en œuvre cet exemple en utilisant un ensemble total de 45 sources
de données, comprenant chacune une vue59 contenant en moyenne 5 attributs parmi 20
choix possibles. Nous avons également associé un poids à chaque chemin calculé par le
59
La prise en compte de plusieurs vues ne présente aucune difficulté supplémentaire.
93
Article
Journal
Genomic sweeping for hypermethylated genes
OLAP over uncertain and imprecise data
TRDB - The Tandem Repeats Database
GCD of Random Linear Combinations
Bioinformatics
VLDB Journal
Nucleic Acids Research
Algorithmica
Tab. 4.6 – Contenu de la vue V17
Prix
Journal
Propriétaire
Pays
5e
10e
8e
18e
Bioinformatics
VLDB Journal
Algorithmica
Nucleic Acids Research
Oxford
Springer-Verlag
Springer
Oxford
Royaume-Uni
Etats-Unis
Etats-Unis
Auteur
Année
ISSN
Editeur
Liang Goh
Douglas Burdick
Yevgeniy Gelfand
Igor Shparlinski
2007
2007
2007
2007
0395-2037
Alex Bateman
John Morris
Kevin Adam
Mike Phillips
0478-1234
0425-8954
ISSN
Editeur
Rédacteur en chef
Mois
0395-2037
0478-1234
Alex Bateman
Kevin Adams
Alfonso Valencia
Mika Jones
Janvier
Février
Article
Pays
Auteur
Genomic sweeping for hypermethylated genes
OLAP over uncertain and imprecise data
TRDB - The Tandem Repeats Database
GCD of Random Linear Combinations
Royaume-Uni
Allemagne
Etats-Unis
Etats-Unis
Liang Goh
Douglas Burdick
Yevgeniy Gelfand
Igor Shparlinski
94
Source
Vue
Pattern d’accès
S34
S3
V34
V3
P = {[Propriétaire : v, Pays : o]}
P = {[Editeur : v, Journal : v, ISSN : o]}
Tab. 4.11 – Sources intermédiaires utilisées pour compléter les chemins
prototype, afin que l’utilisateur choisisse les chemins qu’il souhaite parcourir. Initialisé à
la valeur 0, le poids total du chemin est augmenté de 5 lorsque une vue sélectionnée par
l’utilisateur y est ajoutée, et diminué de 5 lorsqu’une vue intermédiaire y est insérée pour
propager la jointure. Les chemins les plus directs auront donc un poids plus important que
ceux présentant de nombreux nœuds intermédiaires. Les chemins 1 et 2 de notre exemple
ont respectivement un poids de 25 et 15. Nous avons fixé la valeur 5 arbitrairement, mais
il est tout à fait envisageable de fournir une valeur qui illustrerait la fiabilité de la source
ou la confiance que lui accorde l’utilisateur.
Chemin 1 :
17
−−−→ 22 −−−→ 25 −−−→ 23 −−−→ 20
Chemin 2 :
17
−−−→ 22 −−−→ 34 −−−→ 25 −−−→ 23 −−−→ 3 −−−→ 20
Fig. 4.11 – Chemins de jointure entre les sources bibliographiques
Le temps demandé pour calculer les deux chemins complets en Figure 4.11 est de
80ms60 .
60
Pour un AMD Athlon cadencé à 1400Mhz, 512 Mo de RAM, sous Linux.
95
1
2
3
96
4
5
Fig. 4.12 – Interface graphique pour l’intégration de données basée sur le partage de références
Génération de jeux de données Nous avons également testé notre outil sur des jeux
de données générés automatiquement, en faisant varier plusieurs critères : nombre total de
sources, nombre total d’attributs différents, et nombre d’attributs différents par source.
La répartition des patterns {“v”, “l”, “o”} a également varié en pourcentage du nombre
total d’attributs par vue considérée, tout en respectant le critère qu’au moins un attribut
de chaque vue considérée soit associé au pattern “v”.
Jeu de test
A
B
C
D
Nombre de sources
10
25
75
150
Total d’attributs
5
10
10
20
Nombre d’attributs par vue
entre 2 et 5
entre 2 et 10
entre 2 et 10
entre 2 et 20
Tab. 4.12 – Descriptif des jeux de données générés
Quelques chiffres
Nous avons effectué ces tests afin d’estimer plus justement le comportement de notre
algorithme de parcours de chemin en fonction du nombre de sources sélectionnées, et du
nombre total de sources. Les ensembles considérés sont de différentes sortes, et présentés
en détail dans le Tableau 4.12. Pour chaque jeu de données, les patterns d’accès ont été
générés avec une répartition aléatoire respectivement de 30% de “v”, 20% de “l”, et 50%
de “o” que nous noterons R1 , de 50% de “v”, 20% de “l”, et 30% de “o” que nous noterons
R2 , et de 70% de “v”, 10% de “l”, et 20% de “o” que nous noterons R3 .
Commentaires
Les résultats exposés dans le Tableau 4.13 montrent le comportement du prototype en
fonction du type de sources considérées. Les colonnes du tableau représentent respectivement :
• le jeu de données considéré, associé aux répartitions R1 , R2 ou R3
• le nombre de sources sélectionnées
• le temps d’exécution moyen
• le nombre de chemins partiels et complets générés
Les résultats des tests sont une moyenne calculée sur 10 essais successifs.
Interprétation des résultats
Quand le nombre total d’attributs augmente, il devient plus difficile de pouvoir trouver un chemin entre les sources choisies au hasard. Nous constatons le même phénomène
97
Jeu
Sélection
Tps (ms)
Chemins
Jeu
Sélection
Tps (ms)
Chemins
A.R1
A.R2
A.R3
5
5
5
42.6
29.8
13
1.8 (1.8)
3.8 (0)
2.4 (0)
B.R1
B.R2
B.R3
B.R1
B.R2
B.R3
B.R1
B.R2
B.R3
5
5
5
15
15
15
20
20
20
41
13
28
347.6
38.8
75.8
326.6
56.2
69
2.6 (2.6)
1 (0)
2.6 (0)
6 (1)
3.6 (0)
6.2 (0)
7 (1.4)
4.6 (0)
7.4 (0)
C.R1
C.R2
C.R3
C.R1
C.R2
C.R3
5
5
5
20
20
20
69.8
105.8
132.4
347.2
329
566.2
2.8 (2.8)
3 (0)
3.2 (0)
6.8 (6.8)
11.6 (0)
11 (0)
D.R1
D.R2
D.R3
D.R1
D.R2
D.R3
5
5
5
20
20
20
53
221.6
210.2
342
566.6
1006.6
1 (0)
3 (0)
3(0)
4.4 (0)
7 (0)
8 (0)
Tab. 4.13 – Résultats des tests
lorsque le nombre d’attributs moyen par vue croı̂t. Il devient impossible de générer des
chemins complets lorsque le nombre d’attributs qu’il faut valuer pour interroger une source
est important : ceci se produit notamment avec la répartition aléatoire R3 . Quelles que
soient les configurations testées, le temps d’exécution de notre programme reste relativement raisonnable.
98
4.5
Applications sur des données biologiques
L’exploitation du partage de références entre sources de données biologiques est dans
certains cas la seule opportunité qui existe afin de vérifier ou de recouper une information.
Nous avons donc mis en œuvre notre approche sur trois cas d’utilisation réels qui ont été
définis dans le cadre de notre collaboration avec nos partenaires biologistes61 .
4.5.1
Intégration de données et prédiction de gènes candidats
Nous avons mis en œuvre le parcours de chemin afin d’établir des listes de gènes
potentiellement impliqués dans la malaria.
Pour la première approche développée, la liste des sources de données à intégrer établie
par nos collègues biologistes comprenait les sources SwissProt, dbSNP, HGVBase, SNPper,
PubMed, UCSC et LocusLink. Les différents chemins possibles entre ces sources sont
présentés en Figure 3.3. Parmi tous les chemins qu’il est possible de suivre entre ces
sources, nous avons utilisé le parcours présenté en Figure 4.13.
Marqueurs
UCSC
Liste de gènes de l’intervalle
S
O
U
R
C
E
S
SNPper
A
T
T
R
I
B
U
T
S
dbSNP
HGV
PubMed
Identifiant
IL12B
CYFIP2
IL13
CD14
ETF1
NRG2
IL5
G3BP
LocusLink
SwissProt
SNPs
Articles
Termes GO
Termes IPR
Fig. 4.14 – Gènes prioritaires
Calcul du score
Liste de gènes prioritaires
Fig. 4.13 – Parcours effectué par le premier scénario
Les données extraites de chacune des sources permettent d’obtenir des identifiants, et
61
Merci à Alexandre Atkinson et Pascal Rihet pour leur aide précieuse.
99
le calcul de l’importance du gène se fait au regard du nombre de réponses obtenues.
Résultats obtenus
Nous avons suivi une approche de calcul naı̈ve : si le gène est lié à de nombreux articles,
à des termes InterPro ou GeneOntology ou possède des SNPs reliés à la malaria, son score
sera augmenté de 1. Après stockage des informations extraites dans une base de données,
nous avons pu exécuter des requêtes d’agrégation qui nous ont permis d’établir la liste
présentée dans le Tableau 4.14.
La méthode de calcul utilisée ne se base que sur le nombre de réponses obtenues ; ceci
donne néanmoins des résultats intéressants, en particulier les gènes IL12B, IL13 et IL5,
qui sont connus pour être impliqués dans la maladie. Mais la liste présente également des
résultats tel que G3BP, qui semblent moins pertinents en l’état actuel des connaissances.
4.5.2
Construction d’un méta-moteur de recherche de gènes candidats
Comme nous l’avons vu, intégrer directement les sources afin de calculer nous même
les scores s’avère difficile, car la méthode utilisée pour prioritiser les gènes est d’une
importance capitale pour la pertinence du résultat. Nous nous sommes donc orientés sur
d’autres sources de données interconnectées, qui proposent directement des listes de gènes
classés par leur degré d’intérêt. Le parcours de chemins est ici mis en oeuvre afin de
construire un méta-moteur destiné à établir des listes de gènes candidats. À partir d’une
localisation précise sur un chromosome, notre prototype collecte les données extraites de
plusieurs outils de prioritisation de gènes, et fusionne les résultats obtenus par les différents
chemins parcourus, détaillés sur la Figure 4.15.
L’utilisation de ces trois outils nous a confronté aux problèmes détaillés en Section 3.3 :
le seul point d’accès pour leur interrogation est un formulaire Web, et l’un des trois outils
ne peut pas être interrogé directement à l’aide des paramètres connus par l’utilisateur, il
faut utiliser une source intermédiaire. Nous donnons la description et la formalisation des
sources accédées dans les paragraphes suivants.
Suspects - http://www.genetics.med.ed.ac.uk/suspects/search.shtml
Suspects [AAE+ 06] prend en paramètres une pathologie, un numéro de chromosome et
un intervalle en paire de bases. À partir de là, il cherche des noms de gènes connus pour
être impliqués dans la maladie étudiée. Il compare ensuite la liste de gènes présents dans
l’intervalle fourni par l’utilisateur aux autres gènes listés et effectivement liés à la maladie
demandée, et établit une liste ordonnée selon leur implication probable croissante. Les
100
Paramètres
Pathologie
Liste de gènes
connus pour
être impliqués
dans la pathologie
Num. Chromosome
Suspects
Début Intervalle
PosMed
Fin intervalle
Prioritizer
Sources
BioMart
Liste de gènes
candidats
Liste de gènes
candidats
Liste de gènes
candidats
Fusion en une seule liste
Fig. 4.15 – Sources utilisée par le méta-moteur
limitations d’accès à cette source sont modélisés par le terme d’attributs suivant :
Suspects = {[{[Marker1 : v, Marker2 : v], [ChrCoord1 : v,ChrCoord2 : v, NumChr : v],
[Band : v, NumChr : v]}, {[Disease : v], [GenesList : v]}, [PeakMarkers : l], [Score : o],
[Length : o]], [{[Marker1 : v], [Gene1 : v]}, {[Disease : v], [GenesList : v]},
[PeakMarkers : l], [Score : o], [Length : o]], [{[Description : v], [GeneRIF : v],
[Annotation : v], [Implication : v], [GenesList : v]},
{[Disease : v], [GenesList : v]}, [Score : o], [Length : o]]}
Le terme d’attributs ci-dessus correspond aux formulaires détaillés en Figure 4.16.
PosMed - http://omicspace.riken.jp/
PosMed [THH+ 06] a un fonctionnement similaire à celui de Suspects. La Figure 4.17
présente le formulaire d’accès à PosMed.
Son pattern d’accès est détaillé ci-dessous :
PosMed = {[Disease : v, NumChr : v,ChrCoord1 : v,ChrCoord2 : v, IdGene : o, EnsemblID :
o, Score : o, Length : o]}
Prioritizer - http://humgen.med.uu.nl/~lude/prioritizer/
Prioritizer [FBF+06] est un outil auquel il faut fournir 3 régions où le biologiste pense
que des gènes sont associés à une même pathologie, contrairement aux deux autres qui
n’en demandent qu’une seule. Il récupère ensuite la liste des gènes présents dans les 3
régions, puis leurs protéines correspondantes, et trace un réseau d’interaction entre toutes
101
Fig. 4.16 – Formulaire proposé par la source Suspects
Fig. 4.17 – Formulaire proposé par la source PosMed
102
ces protéines. Le principe sous-jacent étant lié au fait que le ou les gènes associés à la
pathologie sont en interaction entre eux.
Afin de fournir 3 régions à Prioritizer, nous utilisons une source intermédiaire supplémentaire, BioMart. Nous interrogeons BioMart à l’aide des listes de gènes impliqués dans
la pathologie fournie par Suspects : avec les identifiants de la base Ensembl62 obtenus, il
est ainsi possible d’extraire de BioMart les données nécessaires à Prioritizer.
Le pattern d’accès à Prioritizer est le suivant :
Prioritizer = {[Disease : v, NumChr : v,ChrCoord1 : v,ChrCoord2 : v, IdGene : o, EnsemblID :
o, Score : o, Length : o]}
Résultats obtenus
Nous avons pu atteindre le principal objectif que nous nous étions fixés, à savoir automatiser un traitement manuel fastidieux, et permettre à des biologistes de confronter
rapidement des informations extraites de multiples sources. Afin de simplifier les manipulations, nous avons développé une interface graphique dédiée à la fusion des données de ces
3 sources, présentée en Figure 4.18. Cette interface allégée permet d’affranchir l’utilisateur
biologiste de la manipulation des termes d’attributs sous-jacents.
Les résultats intégrés mettent en évidence principalement les gènes IL12B, NR3C1, IL13
et NRG2, dont le classement par les trois sources est approximativement identique. Pour de
nombreux autres gènes, la différence entre les rangs affectés par chacune des sources met
en évidence des divergences assez marquées entre les méthodes de prioritisation utilisées,
dont une étude ultérieure approfondie semble indispensable afin de comprendre les critères
prédominants à la divergence du classement.
Il faut noter que des problèmes imprévus peuvent survenir même si toutes les précautions semblent avoir été prises : ainsi, le fichier XML renvoyé par PosMed est parfois mal
formé : des balises XML ouvrantes se trouvent au milieu de données textuelles, ce qui
provoque des erreurs lors de l’exécution des requêtes XQuery.
4.5.3
Complétion et vérification de données de puces à ADN
Les puces à ADN sont une biotechnologie récente qui permet de quantifier le niveau
d’expression des gènes transcrits dans une cellule d’un tissu donné63 , à un stade donné du
développement64 et dans un état donné65 . La puce est une plaque de petite taille (1 cm2 )
62 BioMart
(http://www.biomart.org/) est un outil d’exploration de la base Ensembl.
le foie ou l’intestin par exemple.
64 Embryon, enfant, adulte.
65
Malade ou sain.
63 Comme
103
Fig. 4.18 – Interface graphique du métamoteur de recherche de gènes candidats
104
sur laquelle sont fixés des brins monocaténaires d’ADN. Les courtes séquences d’ADN
connues fixées sur la puce sont mises en présence d’un mélange d’ADN complémentaire
(ADNc) qui reflète assez bien la composition en ARN du mélange à analyser puisque
synthétisé comme une copie de cet ARN. Cette transcription inverse (de l’ARN vers
l’ADNc) est importante car c’est à cette étape que l’on marque l’ADNc (par incorporation
de composés fluorescents) en vue de le détecter ultérieurement sur la puce.
Le système est conçu de sorte à ne détecter que les paires qui se sont hybridées. Il est
donc facile d’en déduire les séquences des ARN présents dans le mélange étudié, et, par
mesure de l’intensité des signaux d’hybridation, la quantité respective de chaque espèce
d’ARN.
Le principe des puces à ADN repose sur la particularité de reformer spontanément
la double hélice de l’acide désoxyribonucléique face au brin complémentaire. Les quatre
molécules de base de l’ADN (A pour Adénine, T pour Thymine, C pour Cytosine et G
pour Guanine) ont en effet la particularité de s’unir deux à deux, A avec T et C avec G. Si
un patient est porteur d’une maladie, les brins extraits de son ADN vont s’hybrider avec
les brins d’ADN synthétiques représentatifs de la maladie, et ainsi mettre en évidence la
pathologie.
La société Affymetrix66 propose une liste de correspondances entre les identifiants
qu’elle utilise pour les gènes stockés sur ses puces à ADN, et les identifiants utilisés
sur des sources de données biologiques telles qu’Ensembl ou sur le site du NCBI67 . Il
est difficile de relier ces identifiants propriétaires à des données diffusées sur les sources
publiques d’internet, pour au moins deux raisons. D’abord parce que la complétude des
informations fournies est partielle : tous les identifiants n’y sont pas, ou bien y figurent
à plusieurs reprises. De plus, même si l’outil Biomart68 peut être utilisé pour compléter
l’information, il propose parfois plusieurs identifiants Ensembl pour une seule référence
fournie par Affymetrix.
Nous avons donc mis en oeuvre l’intégration par partage de références afin de résoudre
ce problème. La puce utilisée est le modèle HG-U133A, qui fait partie de la série des puces
HG-U133. Elle contient 22283 sondes, ce qui rend impossible le croisement manuel des
références afin d’identifier précisément les références partagées correctes et incorrectes que
fournit le fabricant.
Il faut donc confronter les données tirées de plusieurs sources, et utiliser leurs références croisées afin de savoir quel gène présent sur la puce à ADN correspond exactement
aux gènes contenus dans les sources de données biologiques accessibles sur le Web. La
66 Fabricant
californien de puces à ADN : http://www.affymetrix.com/
Center for Biotechnology Information.
68
http://www.ensembl.org/biomart/martview/
67 National
105
Ensembl
Affymetrix
BioMart
Ncbi
Résultat fusionné
RefSeq
Entrez
Symbole du gène
Fig. 4.19 – Références croisées sur des données Affymetrix
Figure 4.19 montre les liens que nous avons suivis afin d’une part de compléter le résultat,
mais aussi de croiser les informations afin de mettre en évidence la valeur à conserver lors
de l’obtention de réponses redondantes.
Formalisation des capacités d’interrogation des sources
Source de données Affymetrix :
A f f ymetrix = {[A f f y ID : v, Public ID : l, Ensembl : o, NCBI : o, Re f Seq : o, Gene Symbol :
o, Array ID : o, Gene Title : o]}
Source de données BioMart :
BioMart = {[A f f y ID : v, Array ID : l, DB Version : l, Organism : l, ID Type : l], [NCBI : v, Array ID :
l, DB Version : l, Organism : l, ID Type : l], [Re f Seq : v, Array ID : l, DB Version : l, Organism :
l, ID Type : l], [Gene Symbol : v, Array ID : l, DB Version : l, Organism : l, ID Type : l]}
Source de données Entrez :
Entrez = {[NCBI : v, DB Name : l, Gene Symbol : o, Gene Title : o]}
Résultats obtenus
Nous avons intégré trois sources de données : Affymetrix, une source locale qui contient
les données de notre puce à ADN, Ensembl, une source distante hébergée au RoyaumeUni, et Entrez Gene, hébergée par le NCBI aux Etats-Unis. Nous avons croisé leurs informations afin d’identifier précisément les références fournies par Affymetrix qui sont
incohérentes avec les données des sources, ou bien compléter celles qui ne sont fournies
que partiellement. L’interface de l’outil que nous avons développé est présentée en Figure
4.20.
Les Tableaux 4.14 et 4.15 présentent respectivement le temps nécessaire à l’intégration
de données, et les incohérences mises en évidence lors de la phase d’analyse. La phase
106
Fig. 4.20 – Interface graphique du détecteur de conflits pour les puces Affymetrix
107
d’intégration est longue, à cause de l’échange de requêtes HTTP avec les sources distantes
qui présente un temps de latence important dû au transfert sur le réseau.
Nombre de sondes
100
1000
5000
10000
15000
22283
Durée en secondes
524
5801
31357
65059
98082
131637
Durée en heures
0,145 (≈ 9 mins)
1.61 (≈ 97 mins)
8.71 (≈ 523 mins)
18.07 (≈ 1084 mins)
27.24 (≈ 1634 mins)
36.56 (≈ 2193 mins)
Tab. 4.14 – Durée de la phase d’intégration de données
À partir du seuil de 5000 sondes, les durées présentées sont des valeurs cumulées : nous
avons en effet découpé les identifiants Affymetrix en lots de tailles différentes, contenant
respectivement 5000, 5000, et 7283 éléments, afin de pouvoir mener les tests à leur terme
en l’espace d’une journée69 .
La phase d’analyse a consisté en l’utilisation de vues relationnelles sur les données
volumineuses que nous avons stockées dans un serveur MySQL : pour chaque identifiant
Affymetrix, nous avons comparé les références croisées fournies par le fabricant à celles
réellement trouvées sur les sources distantes, ceci respectivement pour les identifiants
Ensembl, GeneBank, RefSeq, EntrezGene et le symbole du gène.
Sondes
100
1000
5000
10000
15000
22283
Pourcentage d’incohérences
1% (1/100)
7.3% (73/1000)
7.92% (396/5000)
6.94% (694/10000)
5.87% (881/15000)
5.24% (1169/22283)
Pourcentage d’incomplétude
9% (9/100)
10.9% (109/1000)
9.52% (476/5000)
9.81% (981/10000)
8.82% (1324/15000)
8.91% (1986/22283)
Tab. 4.15 – Résultats de la phase d’analyse
Le pourcentage d’incohérence est calculé à partir des références qui contiennent une
ou plusieurs erreurs, celle-ci pouvant provenir du fabricant de puces aussi bien que du
fournisseur de données distant : nous voulons simplement faire ressortir la référence des
69
Le test de 7283 sondes n’a jamais excédé 10 heures.
108
sondes pour lesquelles il subsiste un doute, qui pourrait être préjudiciable à l’utilisateur
lors de recoupements de données ultérieurs.
109
4.6
Conclusion
Nous avons présenté dans ce chapitre notre approche d’intégration de données par
parcours de chemins de jointure basée sur la logique des attributs. Nous avons vu avec
quelle facilité le raisonnement sur les patterns d’accès aux données permet d’identifier
les compatibilités entre les sources et ainsi propager la jointure de proche en proche. En
nous basant sur un formalisme bien définit et en lui ajoutant des opérateurs spécifiques,
nous avons pu résoudre le problème qui nous était posé en le structurant dans un cadre
formel clair. La mise en œuvre à l’aide du prototype développé montre la faisabilité de
notre approche dans un contexte réel. L’ajout de compléments d’information associés à la
représentation de chaque pattern est directe, et ne présente aucune difficulté majeure : il
suffirait d’inclure ces informations dans le terme d’attributs pour les prendre ensuite en
compte dans le raisonnement sur les sources. Un des avantages du parcours de chemins est
qu’il permet de conserver la trace du mode opératoire qui a permis d’aboutir au résultat
intégré, ce qui garantit un niveau de transparence conséquent à l’utilisateur.
Cependant, quelques difficultés résident encore au niveau de la création et la maintenance des adaptateurs destinés à rapatrier les données des sources 70 . Nous nous sommes
pour l’instant basés sur un accès aux données relativement classique à l’aide d’extraction
de données des pages Web, mais l’extensibilité de notre approche à un contexte orienté
service est tout à fait envisageable. Plusieurs projets tendent aujourd’hui à développer
les services Web biologiques, BioMoby [WL02b] et GBIF71 [GHL07] par exemple. Nous
pourrons mettre en œuvre notre approche dans ce contexte dès que le nombre de services
Web dédiés à la biologie sera devenu plus conséquent. De plus, l’émergence du standard
XForms [W3C07] 72 permettra à la fois le processus d’intégration de services à partir d’interfaces Web, mais aussi la procédure inverse, donnant ainsi naissance à un Web toujours
accessible à l’homme, mais aussi de mieux en mieux accessible à la machine.
70 Ces
problèmes ont été présentés par Lincoln Stein [Ste02] dans un article où l’auteur compare le screen
scraping à une torture moyenâgeuse et plaide pour la mise en œuvre de solutions à base de services Web.
71 Global Biodiversity Information Facility : http: // www. secretariat. gbif. net/ portal/ index. jsp
72
XForms remplacera à terme les formulaires HTML traditionnels.
110
Troisième partie
Médiation de données biologiques du
Web
111
Dans la troisième partie de cette thèse, nous présentons une approche d’intégration de
données hétérogènes et distribuées non matérialisée et flexible, destinée à intégrer des
sources thématiquement proches. Nos travaux dans le domaine de l’intégration nous ont
montré que c’est à cause des phases de construction et de maintenance de la vue unifiée
des données qu’apparaissent ensuite les difficultés majeures de l’intégration sur le Web,
lors de la phase de traitement des requêtes. En conséquence, nous basons notre architecture sur une approche mixte d’intégration de données, puisque le schéma global est défini
indépendamment des schémas locaux, qui sont eux-mêmes mis en correspondance avec
le schéma global indépendamment les uns des autres. Nous présentons ensuite les deux
étapes de décomposition et de recomposition de requêtes, détaillons le prototype développé,
ainsi qu’un exemple concret d’application.
113
114
5
Atouts et insuffisances des solutions
actuelles
Dans ce premier chapitre, nous présentons un bref rappel des approches d’intégration non matérialisées les plus connues basées sur l’intégration de vues, la médiation de
contexte, les réseaux pair à pair ou les langages multi-bases. Nous montrons pourquoi la
plupart de ces approches ne sont pas adaptées au besoin de flexibilité et d’évolutivité imposé par l’intégration de données biologiques sur le Web, et pourquoi les spécificités des
bases de données dans ce domaine nous imposent d’accorder à l’utilisateur la possibilité
de choisir et de structurer selon ses besoins et ses préférences les éléments qu’il souhaite
intégrer.
Sommaire
5.1
Contexte de nos travaux . . . . . . . . . . . . . . . . . . . . 116
5.2
Ecueils des approches classiques de médiation . . . . . . . 117
5.2.1
Médiation de schéma . . . . . . . . . . . . . . . . . . . . . 117
5.2.2
Médiation de contexte . . . . . . . . . . . . . . . . . . . . . 121
5.3
Médiation et réseaux pair à pair . . . . . . . . . . . . . . . 122
5.4
Fédération lâche et langages multi-bases . . . . . . . . . . 124
5.5
Une architecture BGLAV basée sur XML et XQuery . . 125
5.5.1
Contributions . . . . . . . . . . . . . . . . . . . . . . . . . 126
5.5.2
Travaux liés . . . . . . . . . . . . . . . . . . . . . . . . . . 128
115
5.1
Contexte de nos travaux
Comme nous l’avons détaillé dans l’état de l’art présenté en Partie I de ce mémoire,
les approches d’intégration de données sur le Web sont diverses et variées. Intuitivement,
l’exploitation des références croisées entre sources de données biologiques nous a amené
à développer les travaux que nous avons présentés en Partie II. Bien que donnant de
bons résultats, les limitations de cette démarche se situent au niveau de l’expressivité des
formulations et la difficulté de détection et de traitement des conflits en amont de l’exécution de la requête. De plus, il est difficile pour l’utilisateur d’exprimer des contraintes
complexes entre des ensembles de données distincts. Les requêtes s’apparentent plus à
celles exprimables par un moteur de recherche qu’à celles que peut proposer un langage
de requêtes de haut niveau associé à un outil d’intégration. Parcourir des chemins afin de
joindre les données de proche en proche peut également s’avérer être une opération coûteuse alors que parfois l’utilisateur ne souhaite qu’une projection sur quelques attributs
tirés du résultat de la jointure 73 . Enfin, mis à part pour la requête amorçant le parcours,
toutes les autres dépendent de celle qui les précède, ce qui restreint l’utilisation de cet
outil à des cas bien précis, tels que ceux détaillés dans le cadre des tests de notre prototype.
Dans la troisième partie de ce mémoire, nous présentons une démarche qui prend en
compte les spécificités des sources du Web, qui sont majoritairement accessibles en lecture
seule, avec des capacités d’interrogation limitées et qui peuvent apparaı̂tre ou disparaı̂tre
à tout moment, tout en proposant un langage de requêtes suffisamment expressif afin
d’intégrer facilement aussi bien les sources que les ressources biologiques, en laissant la
plus grande marge de manœuvre possible à l’utilisateur. Pour faire face au dynamisme
imposé par le contexte du Web, nous nous sommes naturellement orientés vers une approche d’intégration de données non matérialisée 74 : dans cette catégorie d’architectures,
les systèmes, fondés dans un premier temps sur la fédération de données [HM85] ont évolué vers la médiation de données.
Sur le Web, la médiation de données est l’une des techniques qui a jusqu’à présent été
privilégiée afin d’intégrer virtuellement les données, et dont “le Web sémantique devrait
tirer largement bénéfice”, comme l’ont souligné Laublet et Reynaud [LRC02]. Telle qu’elle
a été introduite par Wiederhold [Wie92], la médiation consiste à proposer à l’utilisateur un
schéma intégré d’un ensemble de schémas de sources de données distribuées, autonomes
et hétérogènes. Ce schéma est un schéma virtuel donnant l’illusion d’une unique source de
73 Notre
approche n’est pas basée sur le modèle relationnel, mais le vocabulaire qui y est associé illustre
parfaitement la problématique.
74
Les différentes architectures existantes sont détaillées en Partie I.
116
données homogène. Un système de médiation doit donc posséder un langage de requêtes
unique et un modèle de données commun. La principale difficulté lors de l’utilisation
d’un médiateur réside justement en la construction puis l’évolution du schéma virtuel, qui
constitue un obstacle majeur à l’extensibilité du système.
Nous avons donc réfléchi à la mise en place d’une architecture d’intégration non matérialisée flexible afin de contourner les principales limitations des méthodes mises en œuvre
par les techniques de médiation.
5.2
Ecueils des approches classiques de médiation
Dans les approches de médiation, deux composants sont chargés de résoudre les différents conflits à la place de l’utilisateur : l’adaptateur qui s’occupe des conflits syntaxiques,
et le médiateur qui résout les conflits sémantiques.
L’adaptateur fournit juste un moyen d’accès homogène aux sources d’information, assure la traduction de la requête, des données, et un éventuel changement de représentation.
Le médiateur peut assurer la conversion d’unités, de structures, la traduction de noms
et les regroupements sémantiques. La plupart des auteurs distinguent deux catégories
fondamentales de médiations pour la résolution des conflits sémantiques : la médiation de
schéma qui est une extension directe de l’approche fédérée et la médiation de contexte
reposant sur la distance sémantique et l’unification de contextes [Jou00].
5.2.1
Médiation de schéma
La médiation de schéma est essentiellement une évolution de l’architecture fédérée
fortement couplée. Le rapprochement à effectuer entre un traducteur et un adaptateur et
entre un intégrateur et un médiateur est que les premiers sont directement les ancêtres des
seconds. À l’origine, les chercheurs travaillant sur l’approche fédérée fortement couplée ont
simplement décidé d’adapter leur vocabulaire à celui de Wiederhold. Il existe dans cette
approche, comme dans l’approche fédérée fortement couplée, un schéma conceptuel global,
auquel doivent s’apparier les différents schémas locaux : il y a donc intégration des schémas
locaux au schéma global. De plus, comme dans l’approche de fédération fortement couplée,
la construction du schéma global repose en général sur l’analyse préalable des schémas
locaux et ceux-ci sont intégrés d’une manière statique au schéma global. Les phases de préintégration, de recherche des correspondances, d’intégration et de restructuration doivent
être réalisées comme dans l’approche fédérée.
Ces systèmes se distinguent par contre d’une approche d’intégration par fédération
fortement couplée en résolvant certains problèmes comme l’indisponibilité des sources
117
et la combinaison des informations d’une manière plus flexible, en offrant un ensemble
d’outils de haut niveau permettant de combiner et de restructurer les informations dans
le schéma de médiation. Comme pour toute architecture de médiation, le système est
normalement en lecture seule, bien que le passage à une solution en lecture-écriture puisse
être dans certains cas théoriquement possible 75 .
Le médiateur a pour rôle de transformer une requête exprimée sur le schéma global en
fonction des termes des schémas des sources réelles. Cette tâche est basée essentiellement
sur le modèle d’intégration adopté qui décrit le schéma global et les articulations qui
le relient aux schémas des sources réelles. Selon la façon dont les correspondances entre
les schémas globaux et locaux sont spécifiées, il existe principalement deux approches
opposées pour définir le modèle d’intégration.
L’approche GAV (Global-As-View) [GMPQ+ 97, ACPS96] définit le schéma global
comme une vue sur les schémas des sources locales. Chaque relation du schéma global
est alors décrite par une règle76 de la forme suivante :
g(X) : − l1 (X 1 ), . . ., l j (X j )
où g est une relation du schéma global et les l j représentent des relations des schémas
des sources réelles. X, X 1 , . . . , X n sont des tuples composés de variables et de constantes,
vérifiant X ⊂ X 1 ∪ . . . ∪ X n . L’approche GAV suppose que toutes les sources sont connues
au moment de la définition du schéma global, et que l’union des données se trouvant dans
les sources constitue l’ensemble des données interrogées.
À l’inverse, l’approche LAV (Local-As-View ) [LRO96a, FW97] impose que le schéma
global soit défini indépendamment des sources. La définition de ce dernier se fait donc
par rapport à un centre d’intérêt, à la discrétion de l’utilisateur. Les sources réelles sont
ensuite décrites comme des vues locales sur le schéma global préalablement conçu. Une
relation du schéma d’une source réelle est alors décrite par une règle de la forme suivante :
l(X) : − g1 (X 1 ), . . . , g j (X j )
où l est une relation d’une source locale et les g j représentent des relations définies dans
le schéma global.
Dans l’approche GAV, la transformation des requêtes revient simplement à remplacer
les vues utilisées par leurs définitions. Dans le cas d’une approche LAV, elle est plus
compliquée. En effet, les règles doivent être combinées pour reformuler les requêtes en
fonction des termes des schémas des sources locales.
75 Bien
que cela pose ensuite des problèmes similaires à ceux rencontrés lors de la mise à jour de vues
dans les bases de données relationnelles.
76
La syntaxe utilisée est celle de Datalog [GM78].
118
La modification d’une source locale (ajout ou suppression d’une source, modification
du schéma d’une source) dans une approche GAV, entraı̂ne la reconsidération complète
du schéma global. Ainsi, cette approche n’est pas conseillée quand il s’agit d’un système
intégrant un grand nombre de sources autonomes (dont la stabilité est donc incertaine)
contrairement à l’approche LAV qui favorise ce genre de systèmes. Cet avantage vient
du fait que chaque source locale est décrite indépendamment des autres. La Figure 5.1
résume les deux méthodologies principales de construction du schéma global : GAV peut
être qualifiée d’approche bottom-up 77 , alors que LAV est une approche top-down 78 .
Intégration de données
GAV
LAV
Schéma global
Schéma global
Vues complexes sur l’ensemble des sources
Processeur de requêtes LAV
Description de
la source
Description de
la source
Description de
la source
Description de
la source
Source structurée
Source semi−structurée
Source structurée
Source semi−structurée
Fig. 5.1 – Intégrations GAV et LAV
Notons que, dans une approche LAV, le schéma global doit contenir l’ensemble des
attributs partagés par l’ensemble des sources réelles même si l’application d’intégration
ne s’y intéresse pas. Dans une approche GAV, toutes les relations existantes dans les
sources réelles doivent être représentées par des relations du schéma global ou par des
requêtes conjonctives sur ces dernières.
Pour compenser les limites et insuffisances de l’une et l’autre de ces approches, des solutions mixtes ont été développées. Par exemple, l’approche GLAV (Global-Local-As-View)
[FLM99] utilise la puissance expressive des deux approches LAV et GAV, permettant
ainsi une définition de schéma flexible et indépendante des détails propres aux sources.
Elle consiste à exprimer un ensemble de relations du schéma global comme une vue sur
un ensemble de relations des schémas des sources réelles.
77 De
78
bas en haut.
Du haut vers le bas.
119
Les règles de correspondance GLAV prennent alors la forme suivante :
g1 (X 1 ), . . ., g j (X j ) : − L(X )
où les g j sont des relations du schéma global et L est une conjonction de relations des
schémas des sources réelles. Friedman et Levy [FLM99] montrent que la complexité du
problème de réécriture en utilisant l’approche GLAV ne dépasse pas celle utilisant l’approche LAV.
Dans l’approche BAV (Both-As-View) [MP03], les schémas sont transformés de façon
incrémentale en leur appliquant une séquence de transformations primitives t1 , t2 , . . . , tn .
Chaque ti apporte un changement ∆ sur le schéma en ajoutant, supprimant ou renommant un élément. Les correspondances entre le schéma global et les schémas locaux sont
exprimées à l’aide de chemins composés de transformations primitives bi-directionnelles.
Une relation g du schéma global peut donc être décrite en fonction d’une relation l d’une
source locale par une règle de la forme suivante :
g(X) : − tn o tn−1 o . . . o t1 (l(Y ))
et inversement, une relation l présente dans une source locale peut être décrite en fonction
d’une relation g tirée du schéma global par une règle de la forme :
l(Y ) : − t1−1 o t2−1 o . . . o tn−1 (g(X))
Parmi les avantages de cette approche figurent les possibilités offertes par les primitives de transformation pour faire évoluer les schémas locaux et le schéma global. Mais
l’inconvénient majeur de la méthodologie BAV réside dans le fait que les schémas intermédiaires rendent le processus d’intégration plus difficile. Cette approche a été utilisée
dans le système AutoMed [BKL+ 04].
Enfin, l’approche BGLAV (BYU-Global-Local-As-View)79 [XE04] a pour objectif de
combiner l’extensibilité de l’approche LAV et la facilité de réécriture de l’approche GAV.
Chaque source est décrite en fonction du schéma global en associant à chaque élément
dérivé du schéma de la source, un élément du schéma global. Un élément du schéma global
correspond donc à l’union des éléments des sources locales qui lui sont associés :
g(X) : − f1 (l1 (X 1 ))
g(X) : − f2 (l2 (X 2 ))
...
g(X) : − fn (ln (X n ))
79
BYU est l’acronyme de Brigham Young University.
120
où chaque fi est une opération de transformation qui crée à partir d’une relation li une
relation dérivée li′ , possédant une correspondance directe avec la relation g appartenant
au schéma global.
Cette approche a deux avantages principaux :
☞ la réécriture de requêtes est un simple dépliement des correspondances : sa complexité est donc de l’ordre de celle de l’approche GAV.
☞ l’ajout, la modification et la suppression des sources n’ont pas de conséquences sur
le schéma global : seules les correspondances de la source concernée avec le schéma
cible, qui lui reste fixe, doivent être mises à jour.
Les approches d’intégration mettant en oeuvre la médiation de schéma sont très concernées par les problèmes de scalabilité à l’échelle du Web. D’une part parce que la création
et la maintenance du schéma global est problématique quand le nombre de sources est
variable, mais aussi, comme l’a montré Goasdoué [Goa01], à cause de la complexité de la
phase de réécriture des requêtes.
5.2.2
Médiation de contexte
La médiation de contexte a été proposée dans le but d’adapter la médiation de schéma
à des environnements ouverts et dynamiques tels que le Web, environnement dans lequel l’intégration d’informations issues d’une multitude de sources susceptibles d’évoluer,
d’apparaı̂tre, ou de disparaı̂tre à tout moment devient vite irréalisable. La médiation de
contexte est caractérisée par une prise en charge automatisée de la sémantique grâce aux
mécanismes d’unification ou de réconciliation des contextes. La distinction fondamentale
entre une médiation de schémas et une médiation de contextes est que, dans la médiation de contextes, aucune information d’intégration statique n’est nécessaire, les liens
entre adaptateurs et médiateurs sont établis dynamiquement lors de la résolution d’une
requête. Dans le cas où la sémantique des informations contenues dans les sources est
unique, il est donc possible de les comparer directement.Le médiateur peut se contenter
de faire appel à une seule ontologie. Si le médiateur intègre des sources décrites chacune à
partir d’un univers conceptuel spécifique, il est nécessaire de mettre en place des règles de
correspondance sémantique entre les différentes interprétations. Il existe essentiellement
deux sous-catégories de systèmes de médiation de contextes :
1. La médiation de contexte à sémantique non-stricte
Ces systèmes utilisent des métadonnées (structurées ou non), aux formats disparates
et aucune ontologie explicite. Les systèmes à sémantique non-stricte se basent en
général sur des calculs de distances sémantiques (le rapprochement sémantique) et la
121
réconciliation de contextes pour intégrer les informations. Ces systèmes retournent
des résultats qui peuvent s’avérer non conformes à la requête initiale, en fonction
du calcul de distance qui a été opéré par le système.
2. La médiation de contexte à sémantique stricte
Ces systèmes utilisent des métadonnées exprimées dans le même format et la même
ontologie, ou dans plusieurs ontologies mais avec des liens explicites entre elles permettant leur traduction de l’une à l’autre. L’unification de contextes est le mécanisme utilisé par les systèmes à sémantique stricte ; ce mécanisme utilise des règles
de logique formelle pour manipuler les contextes. Ces systèmes retournent des résultats toujours conformes à la requête initiale. Les déductions logiques permettent
de s’assurer de la correction des correspondances qui ont été établies.
Comme le soulignent Benslimane et al. [BJL+ 99], la médiation de contexte est l’approche qui prend en compte le plus de critères d’interopérabilité. Cependant, elle apparaı̂t
comme une solution en partie satisfaisante dans le domaine biologique, où les interprétations peuvent être sujettes à une grande variabilité. De plus, il n’existe pas d’ontologie
suffisamment complète qui puisse englober l’ensemble des relations qui existent entre
toutes les entités biologiques. Comme l’a montré Garcia-Solaco [GSSC95], la sémantique
des données intégrées est de toute façon relative, et il serait illusoire de penser qu’une ontologie universelle résoudrait tous les problèmes, puisque des différences de langue entre
les termes subsisteront toujours, et que de nouvelles relations apparaissent sans cesse au
gré des progrès de la recherche et de l’évolution des connaissances scientifiques.
La médiation de contexte est une approche qui doit donc faire face à deux limitations :
☞ si elle est basée sur une seule ontologie, elle semble difficile à mettre en oeuvre. Vu
le degré de disparité des données biologiques sur le Web, utiliser un seul référentiel
pour la signification des entités manipulées est difficilement envisageable.
☞ si plusieurs significations des mêmes objets doivent coexister, l’exploitation des
liens inter-ontologiques oblige à réaliser de la médiation d’ontologies, ce qui nous
ramène aux limitations rencontrées lors de la mise en œuvre de l’intégration de
schémas.
5.3
Médiation et réseaux pair à pair
Dans un contexte dynamique et à large échelle tel que le Web, la médiation basée
sur des réseaux pair à pair à pris ces dernières années une place de plus en plus grande.
L’orientation vers ces nouvelles architectures s’explique par le manque de scalabilité du
modèle client-serveur n-tiers traditionnel : face aux demandes d’un grand nombre de
clients, la charge de calcul devient trop lourde et la bande passante offerte insuffisante.
122
L’idée est donc de répartir les tâches tout en masquant la distribution, la localisation et
l’hétérogénéité des sources.
Trois typologies différentes coexistent :
☞ non structurée : les pairs sont tous égaux et se découvrent soit par interrogation
d’un serveur central, soit par diffusion de la requête de proche en proche.
☞ structurée : comme pour les architectures non structurées, les pairs sont tous égaux,
mais une table de hachage distribuée permet de router la requête de proche en
proche en un nombre d’étapes qui est logarithmique par rapport au nombre de
nœuds.
☞ hybride : les pairs ne sont plus égaux entre eux, et certains se distinguent des autres
en devenant de super-pairs, qui gèrent des index sur les données contenues par les
pairs.
Le P2P, partant du principe que le schéma global s’avère être le goulot d’étranglement
des systèmes basés sur l’intégration de vues, le supprime, et permet donc de s’affranchir
de sa création et sa maintenance. Mais la qualité de service offerte par les typologies pair
à pair et leur capacité à répondre de manière fiable aux requêtes posées est très variable.
L’approche non structurée n’offre par exemple aucune garantie quant au temps nécessaire
au traitement et à la qualité d’une requête. La traçabilité des éléments constitutifs de la
réponse est difficile à conserver, et la diffusion des requêtes à tout ou partie80 des pairs
augmente la charge sur le réseau.
La localisation des informations pertinentes à l’aide d’une table de hachage distribuée81
dans une typologie structurée est difficile à mettre en oeuvre en biologie, à cause des
difficultés à identifier précisément les données proposées par le pair, mais aussi à cause de
la limitation qu’entraı̂ne une indexation à l’aide de clés, qui pour être efficace suppose un
consensus sur les dénominations utilisées.
Enfin, l’approche hybride fait ressurgir les problèmes de robustesse dûs à la centralisation, et l’opacité du regroupement des pairs en grappe selon la proximité de leurs contenus
rend difficile l’identification de la provenance des données formant le résultat.
Dans le domaine biologique, l’utilisation d’un SGBD pair à pair82 masque trop les
spécificités de chaque nœud. Il est difficile d’exprimer des opérateurs complexes entre
les données de plusieurs sources, puisque l’un des objectifs des systèmes pair à pair est
justement de dissimuler les différences entre les sources. L’organisation en clusters des
nœuds du réseau ne résout pas tous les problèmes : l’opacité de la grappe ainsi constituée
ne laisse plus apparaı̂tre à l’utilisateur que le schéma unifié exporté par les pairs.
80 Les
techniques d’inondation (flooding) peuvent être volontairement restreintes aux noeuds situés à
une certaine distance de l’instigateur de la requête.
81 THD.
82
Système de Gestion de Bases de Données pair à pair : Peer Data Management System.
123
5.4
Fédération lâche et langages multi-bases
Les approches d’intégration multi-bases [LMR90, HDRK97] ont été proposées afin
d’atteindre l’objectif d’interopérabilité entre bases de données à un niveau intermédiaire :
chaque utilisateur est libre de définir sa vision unifiée et persistante de l’ensemble des
données accessibles, en agglomérant tout ou partie des schémas locaux. Appartenant à la
catégorie des approches d’intégration faiblement couplées, un système multi-base considère
la fédération à manipuler comme une collection nommée de bases de données autonomes.
L’utilisateur connaı̂t l’existence de toutes les sources attachées au système, mais leur localisation précise demeure transparente. Une des caractéristiques des fédérations lâches
multi-bases est de ne pas masquer à l’utilisateur les problèmes schématiques et sémantiques, mais de s’appuyer sur un langage suffisamment expressif et qui puisse fournir les
primitives qui permettent de les résoudre.
Une grande partie des facilités apportées par les langages multi-bases relationnels
MSQL [LAZ+ 89] ou MDSL [LA87] ne peuvent pas être adaptées au contexte du Web : en
particulier la création et la manipulation de types de données et de relations, ou l’importexport de données entre plusieurs multi-bases. Ceci s’explique par le fait que les sources
ne supportent pas l’interrogation de leur contenu selon n’importe quel critère, et qu’elles
sont accessibles en lecture uniquement. Un possible accès en écriture ne changerait rien :
leurs éloignements respectifs sur le réseau, et l’absence de toute contrainte qualitative
quant au temps de réponse rendrait difficile la mise en place d’un protocole de validation
à deux phases traditionnel. D’autre part, le fait de se baser sur le langage SQL limite les
possibilités d’évolution des requêtes et de restructuration des résultats.
Dans le domaine semi-structuré et orienté Web, les travaux de Nachouki et al. [NQC05]
proposent un regroupement des schémas des sources et des conflits qui existent entre
elles sous la seule arborescence d’une description de l’organisation des sources, définie
par une DTD. Cette approche distingue des sources actives et passives, selon que celles-ci
proposent ou non des opérateurs en plus de l’accès aux données. Le langage d’interrogation
du schéma fédéré ainsi constitué est une extension de XQuery, permettant d’affranchir
l’utilisateur de l’écriture de multiples requêtes d’extraction de données sémantiquement
liées.
Bien que proposant des pistes intéressantes pour le domaine biologique, comme le
regroupement thématique des sources, cette solution ne s’accompagne pas d’un algorithme
de réécriture qui prenne en compte les limitations d’accès aux sources de données et
la composition de services afin de résoudre l’hétérogénéité sémantique. Pour un même
ensemble de sources, il existe une multitude de schéma fédérés possibles83 , ce qui pose
83
Puisque l’utilisateur est seul en charge de constituer son schéma, le regroupement des sources est
124
des problèmes quant à la qualité du regroupement : il n’y a pas de critères définis afin de
juger de la proximité de deux sources regroupées sous un même nœud. Enfin, l’intégration
d’un grand nombre de sources au système produit un schéma fédéré de taille imposante,
ce qui peut conduire aux problèmes de désorientation et de surcharge cognitive que nous
avions évoquée en Section 2.3 à propos de l’outil d’intégration SRS [EUA96].
5.5
Une architecture BGLAV basée sur XML et XQuery
Proposer un système d’intégration de données biologiques simple à interroger, évolutif,
et couplé à un langage de requêtes expressif n’est pas chose aisée dans le domaine du Web.
Pour guider nos choix de conception, nous sommes tout d’abord partis d’un double constat,
basé d’une part sur les retours d’expérience de nos collaborations avec des biologistes
(notamment les problématiques des sources exposées dans l’état de l’art en Partie I, et
l’absence de consensus sur la signification des données hébergées), et d’autre part de
notre expérience84 dans le domaine de l’intégration de données : nous avons voulu éviter
en particulier les écueils existant en intégration de schémas85 , tout en bénéficiant des
avantages que peut proposer une telle approche pour la facilité d’expression de requêtes
complexes sur des ensembles de données répartis et hétérogènes.
Nous nous sommes focalisés sur plusieurs points afin d’offrir un moyen simple pour
intégrer des données complexes :
☞ donner aux utilisateurs la possibilité de manipuler une vision unifiée stable des
données
☞ prendre en compte les capacités limitées des sources
☞ simplifier la phase de réécriture de requêtes
☞ proposer une solution d’intégration qui soit exploitable sur la majorité des sources
de données actuelles
À partir des forces et des faiblesses des approches d’intégration exposées dans les Sections 5.2 à 5.4 précédentes, nous nous sommes orientés vers une solution d’intégration de
schémas basée sur le modèle BGLAV proposé par Xu et Embley [XE04]. Cette méthodologie de construction d’une vue intégrée des données permet de s’affranchir des limitations
classiques rencontrées par l’intégration de schéma, qu’il s’agisse de la phase de réécriture
trop complexe, ou de la maintenance difficile du schéma global.
totalement subjectif.
84 Nous avions utilisé pour deux de nos prototypes une approche GAV basée sur le modèle relationnel,
et une approche GLAV basée sur le modèle XML.
85 Naveen Ashish [HAB+ 05] qualifie la gestion de multiples schémas provenant de sources hétérogènes
de chaos schématique (“schema-chaos”).
125
5.5.1
Contributions
Le modèle BGLAV a été initialement basé sur le modèle relationnel, et utilisé pour
le projet TIQS 86 [Xu03]. Dans ce contexte, les extensions apportées par Xu et Embley à
l’algèbre relationnelle ont servi de support à la mise en œuvre de techniques de détection
d’équivalences afin de pouvoir spécifier les correspondances entre les schémas sources et le
schéma global de façon semi-automatique [XE06, XE03]. Une architecture conçue suivant
BGLAV fait bénéficier aux utilisateurs d’un schéma clairement défini, dont les entités
manipulées sont identifiées sans ambiguı̈té, tout en réduisant la réécriture de requêtes à
un simple dépliement de vues. L’ajout ou la suppression de sources n’est donc plus un
problème comme dans le cas de GAV.
Nous avons repris et augmenté cette vision alternative de l’intégration de schémas afin
de la mettre en œuvre dans le cadre de sources de données biologiques sur le Web. Nos
principales contributions se situent au niveau :
☞ de la possibilité pour l’utilisateur de créer sa vision stable et unifiée des éléments
qu’il souhaite extraire des sources
☞ de l’utilisation de XML et du langage XQuery afin de simplifier l’expression des
requêtes
☞ d’un algorithme de réécriture de requêtes qui prend en compte les limitations d’accès imposées par les sources distantes dans la constitution du plan d’exécution de
la requête
☞ de la prise en compte des préférences de l’utilisateur lors de l’union de résultats
conflictuels extraits des sources
Nous voulons proposer une grande flexibilité quant à la définition du schéma manipulé par l’utilisateur, tout en permettant d’identifier les correspondances entre les sources
locales et le schéma cible. Le schéma global est défini indépendamment des sources, et
chaque schéma local est associé au schéma global individuellement. Dans un contexte
d’intégration sur le Web, tout plaide pour la modularité : selon le modèle BGLAV, si une
source locale est ajoutée ou modifiée, il suffit de créer ou modifier les règles de correspondance qui la lient au schéma global. Le schéma global est supposé avoir une certaine
stabilité, mais dans le cas où il serait modifié, il suffit d’ajuster les règles concernées par
la modification.
Le problème de la réécriture de requêtes demeure un problème crucial, qui nécessite
dans une première phase de raisonner sur les caractéristiques des sources, et dans une
deuxième phase d’analyser les résultats fournis afin de fusionner les réponses locales sans
nuire à la qualité de la réponse globale transmise à l’utilisateur. Lors de l’écriture d’une
86
Target-based Integration Query System.
126
requête sur le schéma global, les conflits sont transparents à l’utilisateur, puisqu’ils ont
été résolus par les règles de correspondance, mais la phase de réécriture doit malgré tout
les prendre en considération afin de les résoudre.
Les conflits qu’a à gérer la phase de réécriture peuvent donc être de plusieurs types :
☞ au niveau syntaxique, ils résultent de l’utilisation de modèles de données différents
d’un système à l’autre. Des concepts différents sont utilisés pour structurer la même
information, au travers d’une relation, d’une classe, ou d’une balise XML.
☞ au niveau schématique, ils résultent d’une structuration et d’une classification différente des informations, et sont liés étroitement aux choix de conception.
☞ au niveau sémantique, ils proviennent des différences d’interprétation des informations partagées entre différents domaines d’application. Plusieurs types de conflits
sémantiques peuvent apparaı̂tre : conflits de noms (problèmes taxonomiques et
linguistiques), conflits de valeurs (problèmes d’unités ou d’échelles), et conflits cognitifs (signification).
Pendant la phase de réconciliation des réponses, quand les données renvoyées par
les sources sont conflictuelles, les préférences de l’utilisateur sont prises en compte afin
de décider celle qui sera utilisée. Elles peuvent être exprimées de façon simple par des
coefficients de qualité attribués par les utilisateurs, comme dans le projet H-KIS [BFL04].
Notre modèle de données est XML. Dans le cas où les sources ne sont pas XML natives,
beaucoup aujourd’hui proposent d’exporter les résultats dans ce format, leur adaptation
à un format pivot en XML est donc relativement aisée. Si ce type de fonctionnalité n’est
pas proposée, des outils tels que XQuare [Odo05] ou Datadirect [CR07] peuvent assurer
la phase de traduction du relationnel ou relationnel-objet vers le format XML. Dès 1994,
Aberer [Abe94] avait justifié l’utilisation du modèle objet en biologie ; de nos jours, la
manipulation de données semi-structurées en biologie présente un grand intérêt puisque
les résultats peuvent souvent être incomplets, et qu’un modèle de données XML est très
évolutif et auto-descriptif.
Notre langage de requêtes est basé sur XQuery : d’une part parce que SQL n’est
pas probant dans le cadre de données très évolutives, il est fortement structuré et ne
convient pas aux requêtes qui vont générer des réponses contenant beaucoup d’absences
de valeur, et d’autre part par l’emploi de plus en plus répandu de XQuery, justifié par la
puissance expressive de ce langage, son extensibilité et la facilité d’écriture des requêtes,
sans apprentissage préalable compliqué.
Nous ne nous occupons pas de l’automatisation de la phase d’appariemment de schémas lors de l’ajout d’une source, ni de la spécification des conflits qui peuvent exister
entre les sources, qui l’une et l’autre restent à la charge de l’utilisateur.
127
5.5.2
Travaux liés
Ces dernières années, plusieurs pistes de recherche se sont focalisées sur le développement de systèmes d’intégrations plus ou moins faiblement couplés, afin d’assurer scalabilité
du système à l’échelle du Web et une plus grande liberté de conception d’une vue intégrée
pour l’utilisateur.
En plus de celles que nous avons exposées dans le Chapitre 2, l’idée d’architectures
d’intégration adaptatives qui permettent l’interrogation de vues personnalisées plutôt que
définies de façon statique dans le système avait été évoquée par Liu et Pu dans DIOM87
[LP95]. Cependant, ce projet ne proposait qu’un formulaire HTML pour transmettre les
requêtes au médiateur, exprimées en langage IQL88 .
Dans le cadre du projet MIX89 [BGL+ 99], inspiré de Tsimmis [GMPQ+ 97], Baru et
al. ont proposé une architecture de médiation GAV basée sur le format XML ; l’utilisateur
a la charge de définir sa propre vue métier, et les requêtes posées sur le médiateur sont
exprimées en langage XMAS90 .
Maluf et al. ont présenté dans le cadre du projet NETMARK [MBA05] une architecture alliant la scalabilité à une réduction des coûts de maintenance. Cependant, la
structuration des données en un modèle commun qui n’est pas formellement imposée au
coeur du système est déplacée côté client, et réalisée à la volée, ce qui alourdit la charge
de calcul supportée par les utilisateurs. Or, Halevy [HAB+ 05] a très justement souligné
que la simplicité d’utilisation et la rapidité de mise en place sont la plupart du temps
inversement proportionnelles à la généralité d’un tel système.
Dans le domaine pair à pair, les approches hybrides telles que XPeer [SMGC04] ou
MediaPeer [DGY05] agrègent les schémas des pairs en un seul super-pair, afin de faciliter
le traitement des requêtes, mais la provenance des résultats n’est plus transparente pour
l’utilisateur, ce qui pose des problèmes de traçabilité dans le domaine biologique.
Plus spécifiquement consacrés au domaine biologique, les travaux de Rahm sur iFuice
[RTA+ 05] et de Kirsten sur BioFuice [KR06] exploitent les références partagées entre
les sources pour proposer à l’utilisateur une mise en relation des entités hébergées par
les sources, afin d’aboutir à un résultat intégré. Cette approche est intéressante afin de
contourner la rigidité des solutions traditionnelles, mais elle suppose une grande qualité
au niveau des références croisées proposées.
BioMediator [MSTH05] permet à l’utilisateur de construire son propre schéma métier,
centré autour des entités et des relations qui intéressent le biologiste. Enfin, le projet
87 Distributed
Interoperable Object Model.
Query Language.
89 Mediation of Information using XML.
90
XML Matching And Structuring language.
88 Interface
128
INDUS91 [CBP+ 05] privilégie une approche d’intégration GAV utilisant des ontologies
dans le but de laisser à l’utilisateur la liberté de composer et d’interpréter selon son point
de vue les données stockées dans les sources.
91
INtelligent Data Understanding System.
129
130
6
Réécriture de requêtes biologiques
BGLAV
Dans ce chapitre, nous présentons notre approche d’intégration de données virtuelle,
dans laquelle l’utilisateur est en charge de construire sa vision intégrée à partir de tout ou
partie des schémas décrivant les sources du Web qu’il souhaite utiliser. Les sources sont
associées individuellement au schéma unifié à l’aide de vues qui les transforment et les
relient directement aux éléments du schéma global. Nous détaillons la phase de réécriture
de requêtes, qui en plus de la décomposition en termes des sources locales, prend également
en compte leurs capacités d’accès limitées afin de générer des plans d’exécution valides.
Sommaire
6.1
6.2
Intégration BGLAV de données biologiques . . . . . . . . 132
6.1.1
Exemple illustratif et taxonomie des conflits . . . . . . . . 133
6.1.2
Formalisation du système d’intégration de données . . . . . 138
6.1.3
Identification et correspondance des éléments XML . . . . 140
Décomposition et recomposition des requêtes . . . . . . . 145
6.2.1
Classification des types de requêtes . . . . . . . . . . . . . 148
6.2.2
Algorithme de réécriture BGLAV adapté aux sources Web
6.2.3
Extensibilité du système . . . . . . . . . . . . . . . . . . . 156
150
6.3
Prototypage, tests et performances . . . . . . . . . . . . . 156
6.4
Application sur des données biologiques
6.4.1
. . . . . . . . . . 157
Intégration de données tirées de la base Ensembl . . . . . . 158
6.5
Conclusion et ouvertures . . . . . . . . . . . . . . . . . . . . 165
1
Résumé des contributions . . . . . . . . . . . . . . . . . . . 167
2
Ouverture et pistes de recherche . . . . . . . . . . . . . . . 168
131
Pour intégrer et créer des connaissances à partir des données biologiques, Brenton Louie
et al. [LMMS+ 07] ont classé les défis à relever en deux grandes catégories : la représentation
des connaissances et la mise en relation d’ensembles de données hétérogènes. Bien que
la plupart des problèmes d’intégration trouvent leur place dans la seconde catégorie, les
auteurs concluent leur étude détaillée par deux constats : aucune solution à l’heure actuelle
ne couvre les besoins exprimés par les plus grands domaines de recherche biologique92 ,
et il reste de nombreux défis à relever (comme nous l’avons vu en Section 5.5) avant de
proposer aux biologistes une méthode simple pour exprimer des requêtes complexes.
6.1
Intégration BGLAV de données biologiques
Précisons une dernière fois le contexte dans lequel se situent ces travaux : notre objectif
n’est pas de proposer une intégration à grande échelle93 (même si nous nous sommes attardés sur la scalabilité du projet), ni d’intégrer massivement des données volumineuses94 .
Nous nous plaçons dans l’hypothèse d’un nombre variable mais modéré de sources (50
sources intégrées peut être considéré comme une marge haute raisonnable), qui concernent
un domaine d’intérêt précis95 . Nous ciblons les utilisateurs souhaitant principalement poser des requêtes de sélection, de projection et de jointure sur ces sources.
Afin de répondre à cette attente, nous avons opté pour une solution d’intégration
de données virtuelle puisque plusieurs conditions sont réunies dans le contexte de nos
travaux :
☞ les sources sont mises à jour fréquemment
☞ il est impossible de prédire les requêtes de l’utilisateur
Dans le domaine biologique, afin de répondre aux contraintes imposées par les sources,
une approche d’intégration mixte telle que BGLAV96 est une solution adaptée. La pierre
angulaire de ce système, tirant parti de GAV et LAV, repose sur le schéma global défini
par l’utilisateur, et les règles de correspondance et de transformation associant individuellement les schémas locaux au schéma global. Nous allons voir au travers d’un exemple
comment sont construites ces correspondances, puis nous donnerons une définition formelle de notre système d’intégration.
92 Génétique,
pharmacogénétique, puces à ADN, conception de médicaments, suivi médical personnalisé.
Les projets qui mettent en œuvre des réseaux de pairs ou des grilles de calcul se focalisent déjà sur
ce problème précis.
94 Ce sont des entrepôts de données qui sont à considérer dans ce cas là.
95 Dans le cadre du projet ST X [ABFS02], Amann et al. ont souligné que cette condition est cruciale
Y
pour le déploiement réussi d’un système d’intégration.
96
BYU(Brigham Young University)-Global-Local-As-View.
93
132
6.1.1
Exemple illustratif et taxonomie des conflits
Considérons les schémas XML présentés en Figure 6.1. Ils représentent le schéma
exporté par un ensemble de sources distantes, et constituent donc une vue sur les données
hébergées par les bases de données sous-jacentes. Notre format pivot est XML, mais les
données peuvent également être stockées sous la forme de fichiers plats, ou de bases de
données relationnelles : nous supposons qu’une vue semi-structurée des données peut être
obtenue à partir de n’importe lequel de ces formats à l’aide d’outils de transformation
dédiés 97 .
Sur la Figure 6.1, les schémas S1 et S2 correspondent à des sources fournissant des
données génomiques. Les schémas S3 et S4 informent respectivement sur des données
relatives aux protéines et aux variations de paires de bases, les SNP98 . Enfin, S5 et S6
sont des sources de données bibliographiques, qui permettent respectivement d’obtenir
des informations sur les publications relatives à un gène dans des conférences ou des
journaux.
Les schémas des sources sont structurés de façon plus ou moins complexe selon la
profondeur de l’arborescence, et le nombre de nœuds fils associés à un nœud père. Ce
que nous pouvons constater en observant les schémas XML qui définissent ces sources,
c’est avant tout qu’ils présentent des similitudes, mais qu’en même temps de nombreuses
contradictions existent dans la façon dont sont représentées les données similaires :
☞ au niveau des hiérarchies XML, avec par exemple, une date dans S1 qui correspond
à la concaténation des 3 champs jour, mois et année dans S2
☞ au niveau de l’utilisation d’unités de mesure différentes, la longueur dans S1 est
exprimée en nombre de codons, alors qu’elle est exprimée en nombre de nucléotides⋆
dans S2
Supposons que nous ayons à associer ces sources au schéma global représenté en Figure
6.2. Ce schéma constitue une vue unifiée des données que souhaite intégrer le biologiste,
centrée autour des séquences ADN. Les informations concernant les séquences protéiques,
les références des publications et les polymorphismes y sont également partiellement représentées. Le schéma global, défini indépendamment des sources, représente le schéma
métier sur lequel le biologiste souhaite poser ses requêtes. Celui qui le définit est donc seul
responsable du choix de structuration des données ; dans le cadre de notre exemple, une
97 Halevy
[Lev00] avait souligné que le format XML réduirait sensiblement les problèmes de construction
d’adaptateurs : “Clearly, the emergence of XML as a standard for data exchange on the WWW will
alleviate much of the wrapper building problem”. Bien que XML ne puisse résoudre à lui seul tous les
problèmes d’adaptation et d’extraction des données, son utilisation a, il est vrai, nettement facilité les
échanges.
98
Single Nucleotide Polymorphisms.
133
S1
brins
S2
liste gènes
adn∗
id
gène∗
date seq
brin
nom
citations∗
prot id
journal
num
brin
refs
longueur chr
article séquence
journal∗
date seq
séquence
longueur chr snps
jour
snp id∗
mois
S4
S3
nom
num
id
séquence
longueur
chr
date
localisation
seq
longueur
séquence orig
fréquence pop
séquence mut
num
S5
S6
publications
id gene
nom
snp∗
protéine∗
date
art
année
variations
protéines
identifiant
conf∗
journal∗
conférence∗
année
publications
article+
nom
titre
numéro
auteur+
nom
gene id
titre article+
titre
prénom
auteur+
nom
prénom
Fig. 6.1 – Schémas exportés par les sources distantes
134
papier
date dans le schéma global sera représentée par la concaténation du jour, du mois, et de
l’année : la correspondance est donc directe entre les dates de S1 et SG , mais une étape
de transformation sera nécessaire pour apparier celles de S2 et SG .
séquences
SG
séquence adn∗
protéine
id contenu
num chr
id
longueur snps∗ date seq
snp id
freq
publis
journal∗
nom
article num
titre
auteurs
conférence∗
nom
article année
titre
auteurs
Fig. 6.2 – Schéma global sur lequel vont s’apparier les sources locales
Nous avons donc d’un côté les schémas des sources locales, et de l’autre côté un schéma
unique défini par l’utilisateur. Toute la difficulté de mise en place d’un solution de médiation BGLAV va désormais consister à mettre en relation les schémas sources et le schéma
cible, tout en résolvant les conflits existants avec les sources locales, afin de décharger
l’utilisateur d’une phase de réconciliation des réponses par trop exigeante. Les conflits
que nous considérons sont identiques à ceux d’une taxonomie définie par Lee [LBGR99],
et détaillée en Figure 6.3. À titre d’exemple, plusieurs conflits entre les éléments des schémas décrivant les sources S1 , S2 , S4 et S5 et le schéma intégré SG sont listés selon leur type
dans le Tableau 6.1 : nous définissons un conflit comme une absence de correspondance
directe entre les feuilles de deux sous-arbres appartenant chacun à un schéma.
Source Csi
CG
Conflit
S1
S2
S2
S4
S5
/brins/adn/brin/chr
/séquence_adn/contenu/num_chr
/liste_gènes/gène/brin/date_seq
/séquence_adn/contenu/date_seq
/liste_gènes/gène/brin/longueur
/séquence_adn/contenu/longueur
/variations/snp/localisation/num
/séquence_adn/publis/journal/num
/publication/conférence/année
/séquence_adn/publis/conférence/année
nommage
agrégation
échelle
confusion
intentionnel
Tab. 6.1 – Conflits entre les schémas XML locaux et globaux
Ces conflits doivent être résolus lors de la définition des correspondances entre les
sources et le schéma métier. En effet, la phase la plus importante lors de la construction
135
Conflits de données
Conflits sémantiques
Conflits de nommage
Conflits de graduation ou d’échelle
Conflits confondants
Conflits schématiques
Conflits de types
Conflits de labels
Conflits d’agrégation
Conflits de généralisation
Conflits de intentionnels
Conflits de domaines
Conflits de contraintes d’intégrité
Fig. 6.3 – Taxonomie des conflits entre schémas locaux et schéma global
d’un système d’intégration basé sur BGLAV repose sur la définition des associations entre
les schémas locaux et le schéma global. Dans le cadre de notre exemple, cette phase
consiste à établir des relations entre les éléments des sources Si,i∈[1;6] et la source virtuelle
SG . Etablir ces règles de correspondance se fait isolément pour chacune des sources. Cette
méthodologie de construction des correspondances présente deux avantages :
☞ chaque règle résout les hétérogénéités entre un élément d’un schéma local et son
correspondant global
☞ la reformulation des requêtes posées sur le schéma global se ramène à une simple
transformation de vues
Notre approche se base sur le langage XML pour représenter les données, et sur le
langage XQuery pour les interroger. Nous avons donc décidé de profiter de la puissance
expressive de ce langage de requêtes afin de spécifier les règles de correspondance. Ces
règles définies en langage XQuery, que nous appellerons requêtes de correspondance, seront
ou non accompagnées d’un ensemble de contraintes spécifiées en clause WHERE, et destinées
à préciser les correspondances entre sous-arbres XML locaux et globaux. La Figure 6.4
détaille la requête associant une date de séquençage dans la source S2 à une date de
séquençage dans le schéma global SG , et une longueur de séquence dans la source S1 à une
longueur de séquence dans le schéma global SG .
Pour chacune des sources de données distantes, un ensemble de requêtes de correspondance associe les éléments sélectionnés dans la source à certains éléments du schéma
global. Ces requêtes sont substituées pendant la phase de réécriture aux éléments du
schéma global demandés par l’utilisateur. Les requêtes de correspondance ne prennent
pas en compte l’intégration horizontale : chaque élément des sources est transformé et
136
1
2
3
4
5
6
7
8
9
10
11
12
13
( : Règle de c o r r e s p o n d a n c e e n t r e l e s d a t e s d es schémas S2 e t SG : )
<date seq>
f o r $x i n c o l l e c t i o n ( ’ S2 ’ )/ l i s t e g è n e s / gène / b r i n / d a t e s e q
r e t u r n c o n c a t ( $x/ j o u r , ’ / ’ , $x/ mois , ’ / ’ , $x/ année )
</ date seq>
( : Règle de c o r r e s p o n d a n c e e n t r e l e s l o n g u e u r s dans S1 e t SG : )
<longueur>
f o r $x i n c o l l e c t i o n ( ’ S1 ’ )/ l i s t e g è n e s / gène / b r i n / l o n g u e u r
r e t u r n $x /3
</longueur>
Fig. 6.4 – Expression de correspondances avec XQuery
associé à son correspondant dans le schéma global, de façon isolée pour chacun des schémas locaux. L’intégration verticale est quant à elle réalisée lors de la fusion des résultats
extraits des sources.
La définition préalable d’un schéma global permet de spécifier clairement les entités
qui intéressent le biologiste, et ainsi faciliter l’expression des requêtes. Les requêtes de
correspondance individuelles résolvent les problèmes de disparition des sources, et évitent
une perte d’information. Si nous considérons un schéma global construit selon l’approche
GAV, dans lequel l’un des éléments serait le résultat d’une jointure entre des éléments
de plusieurs schémas locaux, l’absence de l’une des sources impliquées dans la jointure
invalide de fait l’exécution d’une requête portant sur l’élément. Cet écueil est évité en
suivant une approche d’intégration BGLAV. Si nous considérons maintenant un schéma
global construit selon l’approche LAV, le temps de traitement nécessaire aux requêtes
peut être prohibitif99 : le dépliement de vues utilisé dans BGLAV réduit la complexité de
la phase de réécriture, et diminue de fait le temps nécessaire à son exécution100 .
Sur le Web, un problème d’accès aux données existe : chaque source a des points
d’entrée, qui doivent être valués lors de l’accès aux sources, que cet accès soit direct
ou se fasse au travers d’adaptateurs [Lac01]. Ces limitations d’accès aux données ont
99 L’algorithme
Bucket [LRO96b] par exemple, à partir d’une requête sur le schéma global, crée un tas
pour chaque sous-but de cette requête, chacun d’eux contenant les sources à partir desquelles les éléments
de ce sous-but peuvent être extraits, puis considère toutes les combinaisons possibles des sources. Pour
chaque réécriture candidate obtenue, le test d’inclusion dans la requête initiale est π2p -complet.
100 Le coût de l’exécution d’une requête dans un système d’intégration que nous évoquons ici ne prend
pas en compte les éventuels délais de transfert imprévisibles soulignés par Levy [Lev00].
137
servi de socle à nos travaux présentés dans la seconde partie de ce mémoire, et doivent
à nouveau être prises en compte dans ce contexte de médiation, sous peine de rendre
impossible la résolution d’une requête posée par l’utilisateur. En effet, la nécessité de
fournir impérativement certaines valeurs impose que la phase de décomposition de la
requête s’assure que pour chaque source qui sera accédée, ses patterns d’accès soient
satisfaits.
Au niveau d’un schéma XML, imposer de connaı̂tre la valeur de certains nœuds afin
d’obtenir celle d’un ensemble d’autres nœuds instaure une relation de dépendance fonctionnelle entre éléments du document. L’algorithme de réécriture que nous proposons a
donc la charge d’organiser les requêtes afin de satisfaire toutes les dépendances fonctionnelles nécessaires pour que le plan de requêtes obtenu après décomposition de la requête
posée sur le schéma global puisse s’exécuter effectivement.
Nous allons maintenant définir formellement la représentation BGLAV du système
d’intégration exposé au travers de l’exemple précédent, pour ensuite nous intéresser précisément aux problèmes posés par l’hétérogénéité sémantique, le déroulement de la phase
de réécriture, et la fusion des résultats obtenus.
6.1.2
Formalisation du système d’intégration de données
Notre système d’intégration de données est composé d’un schéma global spécifié par
l’utilisateur, d’un ensemble de schémas exportés par les sources, et des requêtes de correspondance entre les schémas locaux et le schéma global. Formellement, il peut être défini
de la façon suivante :
Définition 6.1.1 (Système d’intégration de données)
Un système d’intégration de données est constitué d’un triplet
I= hG , {Si}, {Mi}i, i ∈ N, 1 ≤ i ≤ n, où respectivement :
G est le schéma global défini par l’utilisateur



{Si } est un ensemble de schémas sources



chaque Mi est un ensemble de requêtes de correspondances entre Si et G
Les requêtes de correspondance entre schémas locaux et global sont importantes. Nous
en donnons la définition suivante :
138
Définition 6.1.2 (Requête de correspondance)
Soient un schéma local Sl , et un schéma global G .
Soient TSl et TG deux sous-arbres appartenant respectivement à Sl et G .
Une requête de correspondance R est un ensemble d’opérations de transformation
appliquées à TSl et produisant un arbre T ′ Sl , dont les feuilles sont en correspondance directe avec celles de TG .
Pour un élément donné du schéma global, les requêtes de correspondance peuvent être
considérées comme des fonctions surjectives qui associent un élément local à cet élément
global. Les requêtes de correspondance reprennent tout en l’augmentant le principe des
règles de correspondance de chemins XPath utilisées dans Xyleme [CVV01], mais en établissant cette fois-ci des correspondances entre arbres. L’application de toutes les requêtes
de correspondance sur un schéma source produit en résultat un schéma dérivé, dont les
feuilles peuvent être associées directement au schéma global :
Définition 6.1.3 (Schéma dérivé d’une source)
Soit un schéma local Sl et Ml l’ensemble de requêtes de correspondance associant
Sl au schéma global défini par l’utilisateur.
L’application des requêtes Ml sur le schéma local produit un schéma dérivé, noté
Vl , pour lequel les conflits syntaxiques et sémantiques sont résolus, et dont les
éléments transformés sont en correspondance directe avec le schéma global.
Etablir des correspondances entre les schémas dérivés des sources et le schéma global induit un ensemble de dépendances d’inclusion, dont nous précisons la définition cidessous :
Définition 6.1.4 (Dépendance d’inclusion)
Soit {Vi,i∈[1;n]} l’ensemble des schémas dérivés des sources et G le schéma global.
Pour chaque sous-arbre du schéma global TG correspondant à un ou plusieurs
sous-arbres locaux Ti, j , les instances de ces sous-arbres vérifient une dépendance
d’inclusion telle que ∀ i ∈ [1; n], I(Ti, j ) ⊆ I(TG ).
Les dépendances d’inclusion suivent l’hypothèse du monde ouvert, puisque chaque
élément du schéma global est associé à un ou plusieurs éléments extraits de schémas
locaux, qui chacun fournissent une partie de l’ensemble des instances attendues.
139
6.1.3
Identification et correspondance des éléments XML
Répondre à des requêtes à l’aide d’un moteur de médiation BGLAV intégrant des
sources du Web suppose dans notre cas d’identifier précisément deux types de nœuds au
niveau des schémas locaux :
☞ d’une part ceux pour lesquels il est nécessaire de fournir impérativement une valeur
afin que l’exécution de la requête transmise à la source soit effective
☞ d’autre part ceux utilisés pour identifier précisément les éléments intégrés, ce qui
est indispensable lors de la phase de construction de la réponse, afin d’éliminer les
doublons inutiles et identifier les données conflictuelles
Ces deux types de nœuds peuvent être totalement distincts, ou se confondre dans
certains cas. À titre d’exemple, une recherche d’information d’après la date de découverte d’un gène ne permet pas d’identifier de façon unique le gène concerné, alors que la
connaissance de son identifiant le permet.
6.1.3.1
Restrictions d’accès et valuation obligatoire de nœuds
Dans un système de médiation de données du Web, l’analyse d’une source en vue
de son rattachement au système doit prendre en compte ses restrictions d’accès. Dans
notre approche, les sources distantes sont vues par le médiateur comme un schéma XML
exporté : nous avons fait le choix de considérer les restrictions d’accès comme les nœuds du
schéma dont la valuation est obligatoire, quelle que soit la syntaxe du langage de requêtes
utilisé. Il découlera donc de cet impératif une restriction sur la structure des requêtes que
pourra traiter la source. Considérons la base de données S1 définie précédemment. Les
nœuds pour lesquels il est impératif de fournir une valeur sont indiqués en caractères gras
sur la Figure 6.5.
S1
brins
adn∗
id
date seq
brin
prot id
citations∗
journal num article
séquence
longueur chr snps
snp id∗
Fig. 6.5 – Nœuds XML à valuation obligatoire
140
Plus précisément, des combinaisons à l’aide d’opérateurs logiques peuvent exister entre
les différents paramètres à valuer, comme nous l’avons détaillé en Partie II. Dans le cas de
la source S1 , il s’agit de la combinaison entre les éléments date seq ou journal et num.
Dans le cadre du projet Information Manifold [KLSS95], Levy a proposé des enregistrements des capacités des sources, associés aux données relationnelles. Dans notre
contexte semi-structuré, nous avons choisi de spécifier les capacités comme une disjonction de conjonctions (éventuellement imbriquées) d’expressions de chemins XPath, dont
nous donnons la définition suivante :
Définition 6.1.5 (Restriction d’accès à une source)
Soit un schéma S décrivant le contenu d’une source locale. Les restrictions d’acS
cès à cette source sont représentées par un ensemble R = nj=1 C j , où chacun des
C j est un ensemble de chemins vers les nœuds du document XML qui doivent être
valués de façon simultanée pour qu’une requête puisse être traitée par la source
locale.
Si nous appliquons cette définition à la source S1 de notre exemple, nous obtenons :
R = {[/brins/adn/date seq], [/brins/adn/citations/journal, /brins/adn/citations/num]}.
Nous considérons que si aucune restriction n’est précisée, une source pourra être interrogée suivant n’importe quel critère. Dans le cas contraire, la phase de réécriture doit
s’assurer que la requête transmise à la source distante affecte bien une valeur aux nœuds
qui requièrent une valuation. En pratique, ceci signifie qu’une requête XQuery transmise
à la source S1 doit contenir une affectation pour l’un au moins des ensembles de chemins
de l’ensemble R . Il faut noter que les restrictions imposées par le concepteur ou l’administrateur d’une source sur son contenu ne peuvent pas forcément aider à déterminer de
façon unique les éléments qui en sont extraits. Ainsi dans la source S1 , la valuation des
nœuds journal et num ne détermine pas sans ambiguı̈té la valeur des nœuds de l’élément citation, contrairement au nœud id qui peut être utilisé comme clef de l’élément
adn. Ajoutons que pour déterminer sans ambiguı̈té un élément citation contenu dans le
document, il est nécessaire de connaı̂tre non seulement sa clef article, mais aussi celle de
l’élément qui l’englobe directement, c’est à dire l’élément id, qui est la clef de adn.
6.1.3.2
Clefs d’un schéma XML
Avant de définir la notion de clefs dans les schémas XML, nous devons rappeller ce
que sont les dépendances fonctionnelles entre nœuds d’un document, qui ont été abordées
notamment dans les travaux d’Arenas et Libkin [AL04]101 , et ceux de Vincent et Liu
101 Les
documents XML sont mis sous forme normale XNF (XML Normal Form), qui généralise la forme
normale BCNF au modèle semi-structuré.
141
[VLL04]102 .
En règle générale, il existe une dépendance fonctionnelle entre deux nœuds d’un document XML si la connaissance de la valeur du premier détermine de façon précise la valeur
du second. Les nœuds d’un document XML appelés nœuds cibles sont alors en dépendance
fonctionnelle avec le(s) nœud(s) faisant office de clef et appelés nœuds sources.
Ceci nous amène à aborder de façon précise l’identification des éléments d’un document XML. Depuis les travaux de Fang [FHM91] sur les systèmes multi-bases, jusqu’au
développement des architectures de médiation, identifier précisément les éléments intégrés a été une préoccupation de premier ordre ; dans le projet Tsimmis [GMPQ+ 97] par
exemple, des spécifications exprimées dans le langage MSL103 [PGMU96] définissent des
identifiants sémantiques, utilisés lors de la fusion des données.
Dans le cadre de notre système de médiation BGLAV, nous devons considérer des clefs
présentes à la fois dans les schémas locaux et le schéma global104 . Nous appellerons clefs
locales les clefs qui identifient de façon précise les données dans chaque source, et clefs
globales celles utilisées afin de distinguer les éléments du schéma métier les uns des autres.
De la même façon que les requêtes de correspondance définies précédemment associent
un élément d’un schéma local à un élément du schéma global, elles associent également
certains éléments locaux à une clef du schéma global.
Nous allons dans un premier temps présenter les règles qui définissent une clef, puis
nous préciserons comment ces règles sont utilisées par notre système de médiation BGLAV
pendant la phase de réécriture de requêtes.
S1
brins
adn∗
id
date seq
brin
prot id
citations∗
journal
séquence
num
article
longueur chr snps
snp id∗
Fig. 6.6 – Exemples de clefs des éléments d’un schéma XML (en gras)
102 Les
dépendances fonctionnelles modélisées sous la forme de documents XFD sont utilisées afin d’obtenir un document XML sous forme normale (XNF).
103 Mediator Specification Language.
104 Les spécifications XML Schema permettent de spécifier des contraintes de clef ou d’unicité à l’aide
des balises key et unique.
142
La définition de clef d’un élément XML présentée ci-dessous suit celle proposée dans
les travaux de Buneman [BDF+ 03], et déjà utilisée dans le cadre du projet d’intégration
de données géographiques VirGIS [EBB06]. La spécification de clef que nous utilisons
permet de définir une clef pour chaque nœud d’un document XML. Les opérateurs =v
et 6=v signifient respectivement l’égalité et la différence entre les valeurs des nœuds du
document.
Définition 6.1.6 (Spécification de clef dans un schéma XML)
Dans un document XML, un nœud n satisfait une spécification de clef notée
K = (Q, {P1, P2 , ..., Pk }), où Q est un chemin partant de la racine du document
jusqu’au nœud n, et {P1 , P2 , ..., Pk} est l’ensemble des chemins partant de Q, si
pour la même spécification de clef K, ∄ n′ , Q/n′ =v Q/n, pour lequel ∃ i ∈ [1; k],
Pin 6=v Pin′ .
La clef d’un élément XML e s’écrira Ke = (Q, {e1, ..., en}), où Q est le chemin
partant de la racine du document jusqu’à l’élément e, et {e1 , ..., en} l’ensemble
des éléments composant la clef.
Cette définition peut être étendue de façon directe à un ensemble de nœuds N ,
dans le cas où la clef serait composite. Toujours dans le cadre de la source S1 donnée
en exemple, nous pouvons donc écrire que le nœud id vérifie la spécification de clef
K = (/brins/adn, {id}). La clef de l’élément adn s’écrira Kadn = (/brins/adn, {id}).
De la même façon, le nœud article vérifie la spécification de clef K = (/brins/adn/citations,
{journal,num,article}). La clef de l’élément citations s’écrira Kcitations = (/brins/adn/citations,
{article}), puisque le titre de l’article détermine précisément la citation, contrairement au
nom du journal et son numéro qui ne le permettent pas.
Il peut y avoir plusieurs clefs dans un document XML, en fonction de l’élément et
du niveau de profondeur considéré dans le document. De la spécification d’une clef dans
un document XML découle directement celle de clef relative, puisque l’imbrication des
éléments induit une relation hiérarchique entre les différentes clefs présentes dans le document :
Définition 6.1.7 (Clef relative dans un schéma XML)
Soit un chemin Q à partir de la racine du document,et K une spécification de clef
dans ce document. Une clef K ′ = (Q, K) est une clef relative dans ce document si
les nœuds de chemin Q satisfont la spécification de clef K.
Dans la source S1 , nous pouvons par exemple définir les clefs relatives :
= (/, (/brins, {})),
′
Kbrins
143
′
Kadn
= (/brins/adn, (/brins/adn, {id})),
′
Kcitations = (/brins/adn, (/citations, {journal, num})).
Lorsque l’ensemble de chemins d’une clef est vide (noté par des accolades {}), cela
signifie que l’élément qui vérifie cette spécification de clef doit être unique : c’est le cas de
l’élément brins dans la source S1 .
Afin d’identifier précisément un élément dans un document XML, il est nécessaire de
connaı̂tre toutes les clefs des éléments qui composent la hiérarchie du document depuis
sa racine jusqu’à l’élément considéré ; en effet, un document peut sans problème contenir
deux éléments possédant des clefs de valeur identique, à partir du moment où ils sont
englobés par des éléments dont les clefs ont des valeurs différentes.
La hiérarchie qui existe entre les clefs d’un document XML situées à des profondeurs
différentes nécessite donc de définir précisément la notion de précédence entre deux clefs
relatives :
Définition 6.1.8 (Précédence et succession de clefs)
Une clef relative K1 = (Q1 , (Q′1 , S1 )) précède la clef K2 = (Q2 , (Q′2, S2 ), si leurs
chemins respectifs verifient Q2 = Q1 /Q′1 . La précédence de la clef K1 par rapport
p
à la clef K2 sera notée K1 → K2 .
De la définition 6.1.8 précédente découle celle de la transitivité d’un ensemble de clefs :
Définition 6.1.9 (Transitivité des clefs)
Un ensemble de clefs relatives C est transitif, si ∀ K ∈ C , ∃ K ′ ∈ C telle que
p
K ′ → K.
Les clefs des éléments XML sont utiles au médiateur lors de l’intégration des résultats
extraits des sources, afin d’une part d’identifier précisément les données, et éventuellement
compléter les résultats partiels, en utilisant les clefs lors de la jointure entre l’élément
incomplet et une source susceptible de fournir les données manquantes.
6.1.3.3
Association entre requêtes de correspondance et clefs XML
Maintenant que nous avons définit ce qu’est une requête de correspondance interschémas et ce qu’est une clef d’un élément XML, nous allons lier ces deux notions à l’aide
d’une définition qui impose des contraintes sur la formulation des requêtes de correspondance utilisées par notre médiateur :
144
Définition 6.1.10 (Requête de correspondance valide)
Pour tout ensemble Mi,i∈[1;n] d’un système d’intégration I, la requête de correspondance entre un élément el d’un schéma local et un élément eg du schéma
global sera valide si elle transforme un ou plusieurs nœud fils de el en la clef de
eg .
Nous ne considèrerons plus désormais que des requêtes de correspondance valides entre
les schémas locaux et le schéma global. Dans notre architecture de médiation, nous avons
donc d’un côté les requêtes de correspondance valides qui sont définies intentionnellement,
c’est à dire au niveau des schémas, et de l’autre les correspondances au niveau extensionnel,
c’est à dire au niveau des données intégrées, qui seront vérifiées lors de la phase de fusion
des résultats extraits des sources. Entre les deux, la décomposition de la requête posée sur
le schéma global puis la recomposition des résultats extraits des sources vont s’appuyer
à la fois sur la description des limitations d’accès et sur les clefs des éléments XML afin
d’assurer l’exécution de la requête, puis éliminer les doublons du résultat intégré.
6.2
Décomposition et recomposition des requêtes
Dans les sections précédentes, nous avons tout d’abord défini formellement le système
d’intégration, puis les correspondances établies entre les schémas locaux et le schéma global. Nous allons nous attacher dans cette section à présenter les procédures mises en œuvre
par le système pour répondre aux requêtes posées par l’utilisateur. Nous nous intéressons
dans le cadre de nos travaux uniquement à des requêtes conjonctives sur l’ensemble des
éléments contenus dans le schéma global. Ces requêtes contiennent des opérations de sélection, de projection, et de jointure105 , dont nous donnons la définition formelle ci-dessous :
105
De type équi-jointure ou théta-jointure.
145
Définition 6.2.1 (Requête sur le schéma global)
Une requête Q sur le schéma global est représentée par une règle de la forme
Q(T ) : − T1 , T2 , . . . , T p , CQ , où respectivement :
 G

• les Ti,i∈[1;p] sont des sous-arbres du schéma XML global, vérifiant :






∄ i, ∄ j ∈ [1; p], i 6= j, Ti est un sous-arbre de T j






• CQ est un ensemble de conditions de la forme :




Sp


 f (a) Θ g(b), où a et b ⊆ i=1
Ti


et f et g sont des fonctions du langage de requêtes (y compris l’identité),




ou





Sp




 f (a) Θ c, où a ⊆ i=1 Ti , c est une valeur atomique



et f est une fonction du langage de requêtes (y compris l’identité),






et Θ ∈ {=, 6=, <, >, ≤, ≥}
L’ensemble de conditions CQ sera traité de deux façons différentes selon que la partie
gauche et la partie droite d’une condition peuvent être extraits ou non de la même source
distante :
☞ si une contrainte dans CQ porte sur deux éléments a et b contenus dans la même
source, la condition sera intégrée à la requête envoyée à la source
☞ si au contraire, les éléments liés par la condition font partie de deux sources différentes, les données seront rapatriées localement, puis la comparaison sera effectuée
par le médiateur
Les restrictions que nous avons imposées à la Définition 6.2.1 sur le format des types de
requêtes qui peuvent être posées sur le schéma global sont moins importantes que celles
d’autres projets d’intégration XML tels que le projet STY X [FABS02] : la clause WHERE de
nos requêtes n’est par exemple pas uniquement constituée de simples prédicats comparés
à une valeur atomique.
Les requêtes posées sur le schéma global vont devoir être réécrites en termes des sources
locales, mais ces dernières peuvent ne pas être capables de répondre à des requêtes arbitraires sur leur contenu, à cause des restrictions d’accès qui existent. La phase de réécriture
va donc prendre en compte ces limitations, afin de s’assurer que la décomposition de la
requête soit exécutable et conforme à la requête posée par l’utilisateur. Avant d’aborder
la présentation de l’algorithme associé à notre médiateur BGLAV, nous allons préciser
quelques-unes des définitions relatives au domaine de la réécriture de requêtes, qui seront
utilisées dans les sections suivantes.
146
Définition 6.2.2 (Inclusion de requêtes)
Une requête Q1 est incluse dans une requête Q2 , notée Q1 ⊑ Q2 , si pour toute
base de données D, l’ensemble de tuples renvoyés par la requête Q1 est un sousensemble des tuples renvoyés par la requête Q2 , noté Q1 (D) ⊆ Q2 (D).
Découlant directement de la définition précédente, nous pouvons écrire la définition
de l’équivalence de deux requêtes :
Définition 6.2.3 (Equivalence de requêtes)
Deux requêtes Q1 et Q2 sont équivalentes si elles vérifient Q1 ⊑ Q2 et Q2 ⊑ Q1 .
De façon générale, la requête posée sur le schéma global n’est pas celle qui sera effectivement exécutée par le système, car même dans les cas simples où elle ne porte que sur
une entité extraite d’une seule source, l’équivalence entre la requête posée et celle réécrite
peut ne pas être exacte. Ceci est causé par la présence de contraintes spécifiques aux données dans chaque source ; ainsi, la requête “quels sont les identifiants des séquences dont
la date de séquençage est postérieure au 01/01/2003 ? ” posée sur le schéma SG en Figure
6.2, bien que formulée à l’identique, n’aura pas d’équivalent exact sur S1 , si cette source
ne contient que des séquences postérieures au 01/01/2005. Néanmoins, ce sous-ensemble
des instances attendues ne contredit pas la contrainte de date spécifiée par l’utilisateur,
et sera donc tout de même pertinent.
Dans les cas plus complexes, le médiateur produit puis exécute une réécriture équivalente à la requête initiale, dont nous donnons la définition suivante :
Définition 6.2.4 (Equivalence de réécritures)
Soient une requête Q et un ensemble de requêtes de correspondance {Mi }.
′
Une
 requête Q est une réécriture équivalente de Q suivant {Mi } si :
Q′ est exprimée uniquement en fonction des requêtes de correspondance
Q′ est équivalente à Q
Alors que l’équivalence de requêtes est plutôt utilisée dans une optique d’optimisation
des requêtes, dans un contexte d’intégration de données, il est plus fréquemment question
de réécriture maximalement incluse, puisqu’une stricte équivalence est plus difficile à obtenir, tant à cause de l’incomplétude des sources que des spécificités des données évoquées
au paragraphe précédent :
147
Définition 6.2.5 (Réécriture maximalement incluse)
Soient une requête Q définie dans un langage L et un ensemble de requêtes de
correspondance {Mi }.
Une requête Q′ est une réécriture maximalement incluse de Q si :


Q′ est une requête exprimée dans le langage L en fonction de {Mi }




Q′ est incluse dans Q


∄ de réécriture Q′′ exprimée dans le langage L vérifiant Q′ ⊑ Q′′ ⊑ Q




et Q′′ 6⊑ Q′
Usuellement, un médiateur doit reformuler la requête posée sur le schéma qu’il présente
à l’utilisateur, tout en atteignant deux objectifs106 :
☞ d’une part la reformulation doit apporter une réponse correcte à la requête initiale
☞ d’autre part les réponses extraites des sources doivent être complètes, c’est à dire
identiques à ce qu’il aurait été possible d’extraire si le schéma global était une seule
et unique source de données
Sur le Web, la seconde condition ne peut en général pas être satisfaite, puisque des
restrictions d’accès limitent les capacités des sources à traiter des requêtes arbitraires
sur leur contenu. Suivant notre approche basée sur une construction de schéma global
BGLAV, les types de requêtes que devra être capable de traiter notre médiateur peuvent
être distinguées en fonction des correspondances qui existent entre les éléments demandés
dans la requête et les sources locales.
6.2.1
Classification des types de requêtes
D’après la méthodologie de construction du schéma global suivant l’approche BGLAV,
nous sommes confrontés à plusieurs types de requêtes, selon qu’un sous-arbre Ti,i∈[1;p]
contenu dans le schéma global, et demandé dans la requête Q(TG ), est respectivement
couvert :
☞ totalement par plusieurs sous-arbres appartenant aux schémas dérivés des sources
☞ partiellement par certains sous-arbres dérivés et totalement par d’autres
☞ partiellement par plusieurs sous-arbres dérivés
La Figure 6.7 détaille les trois possibilités précédentes en s’appuyant sur notre exemple
illustratif basé sur le schéma SG et les schémas des sources Si,i∈[1;6]. Elles correspondent
106 Déjà
soulignés par Alon Halevy dans le cadre de la réécriture dans l’approche LAV : “Clearly, we
would like the reformulation to be sound and complete.” [Lev00].
148
chacune à une façon d’aborder la résolution de la requête107 :
☞ dans le premier cas, la réponse obtenue est l’union des réponses locales
☞ dans le second cas, la réponse sera partielle en fonction de la source accédée
☞ enfin dans le troisième cas, les résultats partiels tirés de chaque source seront joints
à l’aide des clefs des éléments XML qu’ils ont en commun
1
séquences
SG
id contenu
num chr
S1
brins
S2
séquence adn∗
protéine
snp id
freq
id
publis
journal∗
id
gène∗
date seq
brin
citations∗
prot id
conférence∗
nom
journal num article
séquence
nom article num nom article année
titre
S1
jour
S2
id
publis
journal∗
journal∗
mois
art
année
freq
id
date seq
brin
citations∗
prot id
conférence∗
nom
journal num article
séquence
3
auteurs
titre
brin
refs
longueur chr
séquence
journal∗
conf∗
jour
mois
art
année
nom num nom
papier
auteurs
séquences
SG
S5
séquence adn∗
protéine
id
S6
publications
id gene
id contenu
num chr
papier
longueur chr snps
snp id∗
titre
nom num nom
gène∗
date seq
snp id
conf∗
liste gènes
adn∗
protéine
longueur chr
date seq
brins
séquence adn∗
id contenu
refs
auteurs
séquences
SG
num chr
auteurs
brin
séquence
longueur chr snps
snp id∗
titre
2
liste gènes
adn∗
freq
gene id
publis
journal∗
année
conférence∗
article+
nom
titre
snp id
publications
journal∗
conférence∗
auteur+
nom
titre
auteurs
titre
prénom
numéro
titre article+
titre
auteur+
nom
prénom
auteurs
Fig. 6.7 – Couvertures possibles d’un élément du schéma métier par les schémas dérivés
L’analyse du type de couverture d’un sous-arbre du schéma global par ceux extraits
des sources locales va prendre en compte les clefs des éléments XML exposées dans la
section précédente, puisqu’elles seront utilisées lors de la jointure des données extraites
de plusieurs sources. En présence de clefs partagées, une jointure entre des réponses partielles nous permettra donc de compléter le résultat calculé. Le fait d’associer un élément
d’une source locale à un sous-arbre Tl du schéma global lui-même contenu dans l’un des
sous-arbres Ti demandés dans la requête peut sembler contradictoire avec la philosophie
véhiculée par BGLAV, où l’association des sources au schéma métier se veut individuelle,
mais elle ne l’est pas : si la source en correspondance avec le sous-arbre englobé est in107 Dans
les trois cas, ceci ne sera possible bien entendu que si les valuations demandées par la source
sont satisfaites, ce que vérifiera l’algorithme de réécriture.
149
disponible, la requête fournira un résultat partiel, mais néanmoins exploitable, avec un
sous-arbre englobant en partie complet. C’est le cas présenté sur le troisième exemple de
la Figure 6.7 ; cet exemple est relativement simple, et pour des cas plus compliqués, où les
sous-arbres ont un plus grand nombre d’éléments en commun, il est nécessaire de s’assurer
que les clefs successives partagées depuis la racine du sous-arbre englobé ont des valeurs
identiques à celles du sous-arbre englobant.
Nous allons maintenant pouvoir détailler les procédures qui transforment une requête
posée sur le schéma global en un ensemble de requêtes exécutées à la fois directement sur
les sources et localement par le médiateur.
6.2.2
Algorithme de réécriture BGLAV adapté aux sources Web
La plupart des algorithmes de réécriture de requêtes associés aux architectures de
médiation ont été proposés dans les approches GAV et LAV. Ceux utilisés dans l’approche GAV sont les plus simples, puisque leur fonctionnement est basé sur le dépliement
de vues, comme dans le système Tsimmis [GMPQ+ 97]. Dans les architectures LAV, les
deux familles d’algorithmes existants sont centrées autour des règles inversées, utilisées
dans le prototype InfoMaster [DG97], et de Bucket 108 , utilisé dans Information Manifold
[LRO96b].
Le prototype TIQS109 [BE03, Xu03] conçu et développé autour de BGLAV et du
modèle relationnel n’a pas traité le problème de réécriture de requêtes, puisque son objectif
était l’automatisation de la découverte des règles de correspondance inter-schémas.
L’avantage de la réécriture BGLAV que nous proposons par rapport à un algorithme tel
que Bucket est qu’il est inutile de vérifier pour chaque combinaison des requêtes adressées
aux sources locales si le résultat sera inclus ou égal à celui demandé, ce qui évite des tests
pour lesquels Pottinger [PH00] a démontré que le coût est excessif. Un autre avantage de
la réécriture que nous proposons par rapport à un dépliement de vues tel qu’il est réalisé
dans l’approche GAV réside dans le fait que le schéma métier n’a pas à être altéré lors de
la modification des sources. La Figure 6.8 synthétise les différentes étapes de traitement
d’une requête que nous allons détailler dans les sections qui suivent.
6.2.2.1
Choix des sources participantes
Une première étape afin de traiter une requête Q(TG ) posée sur le schéma global
consiste à identifier, pour chaque sous-arbre Ti,i∈[1;p] , les requêtes de correspondance associées à ce sous-arbre grâce auxquelles le médiateur va pouvoir extraire les données
108 Duquel
109
dérivent les algorithmes Minicon [PH00], SVB [Mit01], et B [FABS02].
Target-based Integration Query System.
150
Requête sur le schéma métier
Résultat intégré final
Reformulation en fonction
des sources
Elimination des doublons
Ordonnancement des requêtes
adressées aux sources
Résolution des conflits
Exécution des requêtes
Adaptateur
Adaptateur
...
Résultats partiaux conflictuels
Adaptateur
...
Fig. 6.8 – Traitement des requêtes par le médiateur BGLAV
demandées, par simple remplacement de l’arbre Ti par les requêtes de correspondance
trouvées. Cette phase ne se contente pas simplement de constituer la liste des requêtes
de correspondance qui permettent d’obtenir une couverture complète du sous-arbre, mais
pour les requêtes de correspondance partielles, l’algorithme tente de compléter la couverture à l’aide de requêtes de correspondance associées au sous-arbre non-couvert. Les
instances des deux sous-arbres sont ensuite jointes à l’aide des clefs qu’ils partagent et qui
définissent sans ambiguı̈té les éléments. L’Algorithme 4 détaille la fonction S2 (Sélection
de Sources) prenant en paramètre un sous-arbre demandé dans la requête, et renvoyant
une liste de requêtes de correspondance qui remplaceront ce sous-arbre lors de la réécriture
de la requête globale.
Dans le cas où, suite à un appel récursif, la fonction S2 renvoie l’ensemble LS 7→T
qu’elle a reçu en paramètre, les doublons ainsi ajoutés à l’ensemble passé en paramètre
ne poseront pas de problème, puisque nous réalisons l’union des deux ensembles. Il est
également important de noter que les couvertures partielles que nous prenons en compte
sont du type du troisième exemple présenté en Figure 6.7, et non pas des couvertures
partielles où les sous-arbres ne partagent pas de clefs communes jusqu’au nœud qu’il est
souhaitable de compléter. En conséquence, l’opérateur de jointure ⊲⊳K réalise une jointure
entre les sous-arbres selon la valeur des clefs partagées depuis la racine de T .
151
Algorithme 4 S2 (T ) : sélection des sources candidates
Entrées: un sous-arbre T du schéma global,
un ensemble M contenant n requêtes de correspondance
Sorties: une liste LS 7→T de requêtes de correspondance (ou leurs jointures) qui couvrent
totalement T
/* Au début, la liste est vide */
LS 7→T ⇐ ∅
/* Parcours de l’ensemble des requêtes de correspondance */
Tant que M 6= ∅ Faire
Si une requête Mi couvre totalement T Alors
LS 7→T ⇐ LS 7→T ∪ Mi
M ⇐ M − Mi
Sinon Si Mi couvre partiellement T Alors
T ′ ⇐ T \ Arbre couvert par Mi
/* Rappel récursif de la fonction sur le sous-arbre et la liste de correspondances */
LS 7→T ⇐ LS 7→T ∪ (Mi ⊲⊳K S2 (T ′ , M − Mi ))
Sinon
/* Suppression de la requête de l’ensemble M */
M ⇐ M − Mi
Fin Si
Fin Tant que
Retourner la liste LS 7→T
152
Le meilleur des cas se produit lorsque les requêtes de correspondance contenues dans
l’ensemble M couvrent totalement ou non, mais jamais partiellement, le sous-arbre T .
Si n est le nombre de requêtes de correspondances, la complexité sera ainsi de l’ordre de
O(n). Le pire des cas se produira lorsque aucune requête de correspondance ne couvre
totalement le sous-arbre T , et s’il est impossible de compléter la couverture par jointure
avec d’autres requêtes de correspondance : la complexité à cause des appels récursifs
répétés sera donc de l’ordre de O(n!). En pratique, les requêtes de correspondance ont
pour objectif d’être définies afin de s’associer à des sous-arbres du schéma global en les
couvrant au maximum ; nous pouvons donc affirmer que la complexité moyenne sera en
règle générale proche de O(n).
6.2.2.2
Génération d’un plan de requêtes
Lorsqu’une requête est posée sur le schéma global, le médiateur vérifie tout d’abord la
correction de cette requête par rapport à la Définition 6.2.1, puis l’algorithme de réécriture
la décompose et la transforme en une succession de requêtes, qui sont ordonnées de sorte
à répondre à la question de l’utilisateur. Ce plan de requêtes est constitué d’une séquence
d’accès aux sources de données distantes, entrecoupée d’opérations exécutées localement,
telles que des jointures entre des ensembles de données distribuées, ou l’application de
fonctions d’agrégation.
Notre algorithme de réécriture produit des plans d’exécution de requêtes dont nous
donnons la définition ci-dessous :
Définition 6.2.6 (Plan d’exécution de requêtes)
Un plan de requêtes P , constitué d’étapes Ei,i∈[1;n] sera qualifié d’exécutable si
∀ j ∈ [1; n], les valuations nécessaires à l’exécution de E j sont satisfaites par E j ,
ou par une étape Ei , avec i < j, à laquelle les valuations nécessaires à E j sont
liées par une jointure.
La réécriture de requêtes est mise en œuvre dans notre système par les Algorithmes
5 et 6. Le premier prend en entrée une requête sur le schéma global et produit en sortie
un plan d’exécution de requêtes dans lequel figurent les éléments dont les valuations sont
satisfaites. Ce plan peut s’avérer être partiel, c’est pourquoi le second algorithme prend en
paramètre le premier plan d’exécution obtenu, et les sous-arbres de la requête restants s’il
y en a, et tente de compléter le plan d’exécution afin de fournir un ensemble de réponses
exhaustif. Cette complétion s’obtient en ajoutant des étapes d’extraction de données dont
les valuations sont satisfaites à l’aide de valeurs trouvées dans les jointures auxquelles
participent les sous-arbres restants.
153
Il est important de noter qu’une requête dont le résultat peut provenir d’une seule
source constitue déjà en elle-même un plan de requêtes, et que l’union ou la jointure de
deux plans de requêtes est également un plan de requêtes.
Algorithme 5 Réécriture d’une requête (1/2) : GenerePlanPartiel(Q(TG))
Entrées: une requête Q(TG ) portant sur le schéma global
Sorties: un plan d’exécution de requêtes P
P ⇐ ∅ /* Initialisation du plan d’exécution */
SAQ ⇐ T1 , . . . , T p /* Ensemble des sous-arbres demandés dans la requête */
SAV ⇐ ∅ /* Ensemble des sous-arbres dont les valuations ne sont pas satisfaites */
/* Compteur du nombre d’étapes du plan de requêtes */
k⇐1
Tant que SAQ 6= ∅ Faire
Vi ⇐ Valuations(Ti) /* Valuations à satisfaire */
Si SatisfaitValuation(Vi ) Alors
Ek ⇐ S2 (Ti ) /* Création d’une étape */
L
P ⇐P
Ek /* Ajout de cette étape au plan d’exécution */
k ⇐ k+1
SAQ ⇐ SAQ \ Ti
Sinon
S
SAV ⇐ SAV
Ti
SAQ ⇐ SAQ \ Ti
Fin Si
Fin Tant que
Ordonner(P ,CQ ) /* Réordonnancement des sous-requêtes du plan d’exécution */
Retourner P , SAV
La fonction Ordonner utilisée dans l’Algorithme 5 prend en paramètre le plan d’exécution des requêtes, et l’ordonne en fonction des jointures qui existent entre les sous-arbres
dont les valuations sont satisfaites, de sorte que deux ou plusieurs étapes Ei , E j , . . . et Ek
liées par une jointure se succèdent dans le plan d’exécution.
La fonction GenerePlanPartiel effectue un parcours de l’ensemble SAQ , qui contient au
maximum n éléments. Sa complexité est donc de l’ordre de O(n).
154
Algorithme 6 Réécriture d’une requête (2/2) : CompletePlanPartiel(P , SAV ,CSAVMin )
Entrées: un plan partiel P , un ensemble SAV de sous-arbres,
la cardinalité minimum de SAV
Sorties: un plan d’exécution de requêtes P complété au maximum
/* Nombre d’étapes dans le plan P */
kMax ⇐ Card(P )
/* Pour tous les arbres T contenus dans l’ensemble SAV */
Pour T ∈ SAV Faire
i⇐1
Tant que i ≤ kMax Faire
Si ∃ jointure avec Ei à laquelle participe T et satisfaisant ses valuations Alors
/* Création d’une étape */
EkMax +1 ⇐ S2 (T )
/* Rappel récursif */
L
CompletePlanPartiel(P
EkMax +1 , SAV \ T ,CSAVMin )
i ⇐ kMax + 1
Sinon
i ⇐ i+1
Fin Si
Fin Tant que
Fin Pour
/* Comparaison de la cardinalité de SAV avec la valeur CSAVMin */
Si |SAV | < CSAVMin Alors
Enregistrer P
CSAVMin ⇐ |SAV |
Fin Si
La complétion du plan partiel n’est effectuée que lorsque l’ensemble SAV n’est pas vide.
Dans le meilleur des cas, la plan partiel ne peut être complété par aucun des éléments de
l’ensemble SAV . La complexité sera alors de l’ordre de O(|SAV |), puisqu’une seule passe
sera réalisée. Dans le pire des cas, il existe |SAV |! possibilités pour compléter le plan de
requêtes partiel, la complexité sera alors de l’ordre de O(|SAV |!).
Plusieurs plans d’exécution peuvent exister et compter un nombre maximal d’étapes :
nous ne nous attachons pas à les comparer, le seul but de l’algorithme étant d’obtenir un
plan complété au maximum.
155
Certitude et inclusion maximale des réponses
Le plan d’exécution produit par notre algorithme de réécriture de requêtes BGLAV
va fournir des réponses certaines et maximalement incluses dans la requête posée sur
le schéma global, comme cela a été prouvé pour les règles de correspondance BGLAV
utilisées dans le cadre relationnel [XE04]. Dans le cas où aucun réordonnancement des
étapes ne permet d’obtenir des valuations pour les éléments de l’ensemble SAV , le plan
obtenu ne sera qu’un plan partiel, mais néanmoins exécutable par le médiateur.
6.2.3
Extensibilité du système
La complexité du problème de réécriture de requêtes utilisant des vues a été largement
abordé par Halevy [Hal01]. Parmi les approches classiques, alors que GAV bénéficie d’une
complexité polynomiale puisque basée uniquement sur le remplacement d’une vue par sa
définition, dans le cas des approches LAV et GLAV, trouver une réécriture équivalente à
une requête devient un problème NP-complet. La décidabilité et la complexité de la phase
de réécriture de requêtes sont liées aux règles de correspondance. Dans le cadre de notre
approche BGLAV, la complexité est du même ordre que GAV, puisque les sources sont
associées au schéma global individuellement.
L’architecture d’intégration développée dans le cadre de nos travaux n’a pas comme
objectif d’intégrer massivement des centaines de sources à l’image de ce qui a été mis en
œuvre dans Information Manifold110 , ou d’atteindre les objectifs fixé par les architectures
d’intégration de services ou les applications composites 111 qui visent à combiner ensemble
des dizaines de sources ou ressources. Même si son cadre d’utilisation est clairement circonscrit, notre médiateur BGLAV bénéficie néanmoins, du fait de la technologie mise en
œuvre, d’une bonne scalabilité à l’échelle du Web.
6.3
Prototypage, tests et performances
Nous avons prototypé un outil qui met en œuvre la médiation de données basée sur
le modèle d’intégration BGLAV. Le logiciel développé assure les étapes de reformulation,
et d’exécution de la requête posée sur le schéma global que nous avons détaillées dans les
Algorithmes 4, 5 et 6 ; le médiateur gère également les accès aux sources.
L’interface du logiciel présentée en Figure 6.9 a été construite à l’aide de la bibliothèque
SWT, dont le rendu à l’écran est plus esthétique et l’affichage plus rapide que celui produit par la librairie SWING utilisée classiquement. La syntaxe de la requête est vérifiée
110 Plus
111
de cent sources intégrées.
Mashups.
156
conformément à une grammaire BNF de XQuery définie par le W3C112 , et utilisée par le
générateur JavaCC [Proié]. Ceci nous permet d’obtenir une représentation arborescente
de la requête que les primitives fournies par le langage Java nous permettent de parcourir
ou de modifier. Une fois le plan d’exécution constitué, les requêtes sont exécutées soit par
le moteur Saxon [Sax08] dans le cas de requêtes exécutées localement, soit par le moteur
XQuare [Odo05] qui nous sert d’interface avec les bases de données relationnelles utilisées
pour nos exemples illustratifs, soit par le moteur de requêtes fourni par la base de données
eXist [Mei03] dans le cas de données XML natives 113 .
Ecriture de la requête sur le schéma métier
Choix du schéma global
Edition des requêtes de correspondance
Affichage de la réponse
Fig. 6.9 – Interface graphique du médiateur BGLAV
6.4
Application sur des données biologiques
Nous avons utilisé notre prototype et l’algorithme qu’il met en œuvre sur des données
biologiques réelles. Le scénario illustratif que nous présentons en Section 6.4.1 est basé sur
112 La
page http://www.w3.org/2007/01/applets/ propose des grammaires pour XQuery, XPath et
XUpdate.
113 Saxon et eXist passent respectivement à 100% et 99.4% les tests XQTS (XQuery Test Suite) 1.0.2
du W3C qui indiquent le degré de conformité d’une implémentation vis-à-vis de la norme XQuery.
157
des données tirées de la base de données Ensembl [CCCR04], et qui concernent l’ADN.
Nous avons défini un schéma métier, découpé les données et introduit des conflits structurels et syntaxiques (dans le cas où ils n’existaient pas) afin de bien mettre en évidence
les traitements effectués sur la requête posée sur le schéma global.
6.4.1
Intégration de données tirées de la base Ensembl
Cet exemple illustratif utilise les données sur l’ADN du chromosome X humain114 .
Ces données sont fournies par la base Ensembl sous la forme de fichiers SQL compatibles
avec le SGBD MySQL. Nous les avons réduits en taille, puis découpés afin de simuler
des redondances, tout en introduisant des conflits d’échelle et de nommage : nous avons
ainsi obtenu trois schémas locaux SL1 , SL2 et SL3 . Les sources ainsi simulées sont de deux
types : soit des fichiers XML (obtenus par transformation des données sources), soit des
données relationnelles associées à un transformateur relationnel-XML.
Schéma global et schémas locaux
Le schéma global SG est composé d’éléments EnsemblGeneID, qui contiennent les balises
ID (identifiant Ensembl), Description (brève description), GeneStart (zone de début du
gène), GeneEnd (zone de fin du gène), AssociatedName (nom du gène), GO_ID (identifiant
GO), et Affy (identifiant Affymetrix).
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
< !−− Schéma g l o b a l −−>
<?xml version=” 1 . 0 ” e n c o d i n g=”UTF−8”?>
<xs :s ch em a x m l n s : x s=” h t t p : //www. w3 . or g /2001/XMLSchema”>
<xs:element name=”Gene Chr X”>
<xs:element name=”EnsemblGeneID ”>
<xs:complexType>
<x s : s e q u e n c e>
<xs:element name=”ID ” typ e=” x s : s t r i n g ”/>
<xs:element name=” D e s c r i p t i o n ” typ e=” x s : s t r i n g ”/>
<xs:element name=”Gen eS tar t ” typ e=” x s : i n t e g e r ”/>
<xs:element name=”GeneEnd ” typ e=” x s : i n t e g e r ”/>
<xs:element name=”AssociatedName ” typ e=” x s : s t r i n g ”/>
<xs:element name=”Ids GO ”>
<xs:element name=”GO ID” typ e=” x s : s t r i n g ”/>
</ xs:element>
114 Nous
aurions pu choisir n’importe quel autre chromosome parmi les très nombreuses données fournies
par Ensembl.
158
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
<xs:element name=”Af f y ” typ e=” x s : s t r i n g ”/>
</ x s : s e q u e n c e>
</ xs:complexType>
</ xs:element>
</ xs:element>
</ xs :s ch em a>
< !−− Schéma l o c a l 1 −−>
<xs:element name=” L i s t e g e n e s X ”>
<xs:element name=”Gene ”>
<xs:complexType>
<xs:complexType>
< x s : a t t r i b u t e name=”GO ID” typ e=” x s : i n t e g e r ”/>
</ xs:complexType>
</ xs:element>
</ xs:complexType>
</ xs:element>
</ xs:element>
</ xs :s ch em a>
< !−− Schéma l o c a l 2 −−>
<xs:element name=” L i s t e ”>
<xs:element name=”EnsemblGene ID ”>
<xs:complexType>
159
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
</ xs:element>
</ xs:complexType>
</ xs:element>
</ xs:element>
</ xs :s ch em a>
< !−− Schéma l o c a l 3 −−>
<xs:element name=” L i s t e ”>
<xs:element name=”EnsemblGeneID ”>
<xs:complexType>
</ xs:element>
</ xs:complexType>
</ xs:element>
</ xs:element>
</ xs :s ch em a>
160
Requêtes de correspondance
Les requêtes de correspondance spécifient les associations entre éléments des schémas
locaux et globaux. Dans le cadre de cet exemple, l’élément EnsemblGeneID (ou une balise
de nom différent mais qui soit son équivalent) dans chaque source locale est associé à celui
du schéma global. Chacune des requêtes résout les conflits, comme par exemple le conflit
d’échelle entre les éléments GeneStart et GeneEnd qui sont en paires de bases dans le
schéma global, mais qui sont exprimés en kilo paires de bases dans les schémas locaux SL1
et SL2 , ou le conflit structurel entre GO_ID qui est attribut de l’élément Ids_GO dans le
schéma SL1 .
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
( : Requête de c o r r e s p o n d a n c e e n t r e l e s schémas SL1 e t SG : )
f o r $x i n c o l l e c t i o n ( ’ SL1 ’ )/ L i s t e g e n e s X /Gene
return
<EnsemblGeneID>
{$x/ID , $x/ D e s c r i p t i o n , $x/ Gen eS tar t ∗1000 , $x/GeneEnd ∗1000 ,
$x/ AssociatedName , $x/ Affy ,
<Ids GO><GO ID>$x/ Ids GO/@GO ID</GO ID></Ids GO>}
</EnsemblGeneID>
f o r $x i n c o l l e c t i o n ( ’ SL2 ’ )/ L i s t e / EnsemblGene ID
return
<EnsemblGeneID>
$x/ AssociatedName , $x/ Affy , $x/ Ids GO}
</EnsemblGeneID>
f o r $x i n c o l l e c t i o n ( ’ SL3 ’ )/ L i s t e /EnsemblGeneID
return
<EnsemblGeneID>
{$x/ID , $x/ D e s c r i p t i o n , $x/ GeneStart , $x/GeneEnd ,
</EnsemblGeneID>
Restrictions d’accès
Pour chacun des schémas locaux, nous avons défini des restrictions d’accès, qui correspondent aux valeurs que la source doit impérativement connaı̂tre afin de pouvoir traiter
une requête qui lui est adressée, et qui sont, respectivement :
161
R1 = {[/Liste Genes X/Gene/ID]} pour SL1 .
R2 = {[/Liste/EnsemblGene ID/ID]} pour SL2 .
R3 = {[/Liste/EnsemblGeneID/GeneStart, /Liste/EnsemblGeneID/GeneEnd]} pour SL3 .
Exemples de requêtes
Chacun des exemples ci-dessous présente une requête posée sur le schéma global, et
les requêtes obtenues après décomposition qui seront adressées aux sources locales. Dans
la version actuelle de l’outil développé, les requêtes de recomposition des résultats (qui
ne sont pas présentées dans les exemples qui suivent) consistent en l’union des réponses
obtenues de chacune des sources. La charge de faire le tri des éléments redondants est
donc pour l’instant à la charge de l’utilisateur.
1
Cette première requête cherche à extraire des sources différentes valeurs associées à un
gène en fonction des identifiants Ensembl qui y sont associés.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
( : Requête g l o b a l e : )
f o r $x i n c o l l e c t i o n ( ’ SG ’ )/ Gene Chr X/EnsemblGeneID
where $x/ID = ’ ENSG00000101849 ’ or $x/ID = ’ ENSG00000146950 ’
return
<R e s u l t a t>
{$x/ID , $x/ D e s c r i p t i o n , $x/ GeneStart , $x/GeneEnd}
</ R e s u l t a t>
( : Requêtes s u r l e s schémas l o c a u x : )
( : SL1 : )
return
<EnsemblGeneID>
<Ids GO><GO ID>$x/Ids GO /@GO ID</GO ID></Ids GO>}
</EnsemblGeneID>
( : SL2 : )
162
24
25
26
27
28
return
<EnsemblGeneID>
</EnsemblGeneID>
Les deux seules sources impliquées dans la construction de la réponse sont SL1 et SL2
car les restrictions d’accès de SL3 ne permettent pas d’obtenir une réponse si les valeurs
des éléments GeneStart et GeneEnd ne sont pas fournies.
2
Cette seconde requête cherche à extraire des sources différentes valeurs associées à un
gène en fonction de sa localisation spécifiée en paires de bases.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
( : Rèquête g l o b a l e : )
where ($x/ Gen eS tar t > 7770303) and ( $x/GeneEnd < 9092647)
return
<EnsemblGeneID>
</EnsemblGeneID>
( : SL3 : )
where ($x/ Gen eS tar t > 7770303) and ( $x/GeneEnd < 9092647)
return
<EnsemblGeneID>
</EnsemblGeneID>
La seule source qui puisse participer au résultat est dans ce cas précis la source SL3 ,
puisque les valuations nécessaires à l’interrogation de SL1 et SL2 ne peuvent pas être
satisfaites.
3
163
Cette troisième requête cherche à extraire des sources différentes valeurs associées à
un gène en fonction de son identifiant Ensembl ou de sa localisation spécifiée en paires de
bases.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
( : Rèquête g l o b a l e : )
where ( $x/ID = ’ ENSG00000101849 ’ ) or
( ( $x/ Gen eS tar t > 7770303) and ( $x/GeneEnd < 9 0 9 2 6 4 7 ) )
return
<EnsemblGeneID>
$x/ AssociatedName , $x/ Affy , $x/Ids GO }
</EnsemblGeneID>
( : SL1 : )
where ( $x/ID = ’ ENSG00000101849 ’ )
return
<EnsemblGeneID>
<Ids GO><GO ID>$x/Ids GO /@GO ID</GO ID></Ids GO>}
</EnsemblGeneID>
( : SL2 : )
where ( $x/ID = ’ ENSG00000101849 ’ )
return
<EnsemblGeneID>
$x/ AssociatedName , $x/ Affy , $x/Ids GO }
</EnsemblGeneID>
( : SL3 : )
f o r $x i n c o l l e c t i o n ( ’ SL3 ’ )/ L i s t e / EnsemblGeneID
where ( ( $x/ Gen eS tar t > 7770303) and ( $x/GeneEnd < 9 0 9 2 6 4 7 ) )
return
164
37
38
39
40
<EnsemblGeneID>
</EnsemblGeneID>
Les trois sources peuvent être impliquées dans la composition du résultat final, puisque
toutes les valeurs à fournir sont présentes dans la requête posée sur le schéma global.
6.5
Conclusion et ouvertures
Nous avons présenté dans cette partie une approche d’intégration de schémas suivant le modèle BGLAV, adaptée au modèle XML. Cette méthodologie de construction du
schéma métier manipulé par l’utilisateur donne de bons résultats en biologie. L’utilisation
du langage XML offre de grands avantages : il permet de représenter les données indépendamment de leur modélisation et de leur stockage. Cependant, il ne permet pas d’éviter
les problèmes de conflits structurels et sémantiques, c’est pourquoi nous avons proposé
une formalisation de l’intégration destinée à résoudre ce type de conflits, en amont de la
phase de réécriture de requêtes, et de façon transparente pour l’utilisateur. L’algorithme
de réécriture associé au système permet de décomposer la requête posée sur le schéma
global, puis de réconcilier les réponses sans que l’utilisateur n’ait à assumer une charge
cognitive supplémentaire.
Au niveau des améliorations que nous avons à apporter au système, l’une des pistes
de recherche à explorer est celle ayant pour but d’automatiser la phase de rapprochement
entre schémas locaux et schéma global. Générer des requêtes de correspondance de façon
semi-automatique sera possible avec d’autant plus de facilité lorsque les sources proposeront des méta-données suffisamment complètes et dans un format exploitable par la
machine.
La prise en compte de sous-requêtes corrélées et imbriquées par l’algorithme de réécriture est une amélioration à envisager afin d’augmenter la richesse d’expression des
requêtes. Concernant l’exécution du plan de requêtes que nous générons, une amélioration possible consisterait à faire s’exécuter en parallèle des étapes d’extraction qui ne sont
pas liées les unes aux autres ; ceci constituerait un gain de temps intéressant, puisque
l’extraction de données distantes est la phase la plus chronophage à cause du temps de
transit des données sur le réseau.
Nous avons pris en compte non seulement des correspondances entre schémas complètes, mais aussi des correspondances partielles, contrairement à ce qui avait été défini
pour l’approche BGLAV utilisée dans le modèle relationnel. La modularité de notre approche et la puissance expressive du langage utilisé nous permet d’envisager sereinement
165
son utilisation future sur des services Web biologiques, mais aussi l’intégration simple et
rapide de ressources Web existantes, telles que des comparateurs de séquences.
Au niveau du prototypage, la version actuelle de l’outil développé afin d’illustrer la
mise en œuvre de la médiation BGLAV ne couvre pour l’instant pas toutes les possibilités détaillées dans les définitions que nous avons données. La phase de développement
du module d’analyse et de décomposition de requêtes est très délicate, et nécessite d’y
apporter encore des améliorations. Ainsi l’analyse de la couverture des éléments globaux
par les sources locales n’est pour l’instant opérationnelle que dans le cas où les sources
fournissent toutes les informations concernant un élément du schéma global ; la phase de
suppression des doublons lors de la recomposition des résultats n’applique pour l’instant
qu’une union des résultats locaux, des données dupliquées peuvent donc figurer dans la
réponse finale.
166
Conclusions et perspectives
Dans cette thèse, nous nous sommes intéressés au problème d’intégration de données
sur le Web, en nous focalisant particulièrement sur les problèmes posés par les sources de
données biologiques. Les deux parties de ce mémoire s’articulent autour de deux objectifs
à la fois distincts et complémentaires :
☞ dans la première partie, nous avons proposé une solution d’intégration basée sur le
partage de références entre les sources.
☞ dans la seconde partie, nous avons adapté une méthodologie d’intégration de schémas au domaine semi-structuré, afin de proposer une solution d’intégration à la
fois simple et flexible.
Pour chacune des solutions exposées, nous avons également développé des outils destinés à
les mettre en œuvre et à montrer la faisabilité de nos propositions sur des cas d’utilisation
réels.
1
Résumé des contributions
Conscients du fait que les sources biologiques aujourd’hui ouvertes sur le Web ne
fournissent pas encore les méta-données, ou ne garantissent pas les droits nécessaires
à leur exploitation de façon aisée par le biais de procédures (semi-)automatisées, nos
travaux se sont concentrés sur la résolution d’une classe de problèmes d’intégration qui
se rencontrent principalement à l’échelle individuelle : l’objectif visé étant d’automatiser
autant que possible les phases d’interrogation des sources locales et de réconciliation des
résultats partiels. Les contributions de nos travaux concernent plusieurs points :
Formalisation logique des formulaires d’accès aux sources
La majorité des sources de données actuellement disponibles sur le Web diffusent leur
contenu en se basant sur le modèle client-serveur classique mettant en œuvre le couple
formulaire Web/base de données. Joindre les données de proche en proche est un travail fastidieux, et aisément source d’erreur. Dans ce contexte, automatiser la jointure de
données nécessite de pouvoir comparer et combiner les patterns d’accès aux données. En
167
nous basant sur le formalisme bien défini de la logique des attributs et en lui ajoutant
des opérateurs de comparaison spécifiques, nous avons pu résoudre le problème qui nous
était posé en le structurant dans un cadre formel clair. La définition d’une nouvelle source
et son ajout au système d’intégration en langage XML rendent accessible son utilisation
même à des utilisateurs non informaticiens.
Algorithme de réécriture adapté au modèle BGLAV XML
Les architectures de médiation basées sur les modèles GAV ou LAV montrent leurs limites lorsqu’il s’agit d’intégrer des sources de données dont la disponibilité est incertaine
et les hétérogénéités nombreuses. Nous avons adapté la médiation BGLAV au modèle
XML. Cette méthodologie de construction du schéma métier manipulé par l’utilisateur
donne des résultats probants sur des sources de données du Web. L’utilisation du langage
XML offre de grands avantages, parmi lesquels celui de représenter les données indépendamment de leur modélisation et du format dans lequel elles sont stockées. Cependant,
il ne permet pas d’éviter les problèmes de conflits structurels et sémantiques, c’est pourquoi notre formalisation des données intégrées est tournée vers l’objectif de résoudre les
conflits en amont de la phase de rééecriture de requêtes, et de façon transparente pour
l’utilisateur.
Développement de prototypes
La création d’outils destinés à mettre en pratique les structures de données et les algorithmes que nous proposons sont un point fort de nos travaux. Les prototypes créés
nous ont permis de valider la faisabilité des approches proposées à l’aide d’un langage de
programmation de haut niveau tel que Java, mais nous avons également pu établir un état
des lieux précis des technologies actuelles et émergentes en ce qui concerne l’extraction de
données du Web.
2
Ouverture et pistes de recherche
La récente expansion des sources de données biologiques sur le Web les a mises à disposition d’un nombre sans cesse croissant de chercheurs, ouvrant ainsi de très nombreuses
perspectives d’innovation. La biologie a ainsi pris une nouvelle dimension : anciennement
divisée en plusieurs disciplines, elle est devenue intégrative et offre désormais de belles
perspectives d’appréhension de la complexité du monde vivant. L’intégration de données
vise à combler le fossé qui existe entre producteurs et consommateurs de données, particulièrement dans ce domaine. Dans le cadre de cette thèse, nous avons orienté nos recherches
afin de rapprocher ces différents acteurs.
168
Nous pensons améliorer à court terme les travaux que nous avons exposés, en nous
focalisant sur plusieurs points particuliers :
• concernant l’intégration basée sur le partage de références :
– intégrer non seulement des sources de données, mais aussi des services Web : cette
techonologie s’est grandement développée ces dernières années dans le domaine
biologique, et les perspectives offertes semblent très prometteuses
– associer notre outil a des méthodes d’analyse et de prédiction plus évoluée que
celles que nous avons utilisées pour fouiller et extraire des critères pertinents à
partir des données intégrées
• concernant l’architecture de médiation BGLAV :
– associer des méta-données décrivant plus précisément la confiance accordée à la
source et sa qualité estimée115
– améliorer l’algorithme de réécriture afin de permettre le traitement de requêtes
plus complexes, acceptant l’imbrication et la corrélation de sous-requêtes sur plusieurs niveaux
– automatiser la recherche de correspondances entre éléments des schémas locaux
et globaux
115 L’importance
de la prise en compte des erreurs avait déjà été soulignée par Brenner [Bre99] et Müller
[MN03]. Informer l’utilisateur des incertitudes qui peuvent exister sur les bases qu’il utilise est indispensable, comme l’avait confié Terri Attwood, auteur de la base PRINTS [Att02] : “Nous devons former les
chercheurs afin qu’ils sachent que les bases de données qu’ils utilisent ne contiennent pas forcément des
informations exactes.”
169
170
Annexes
171
172
A
Projets d’intégration de données
biologiques
173
Description et articles de référence des principaux projets d’intégration de données biologiques
Nom
Technologie
Modèle de données
174
GEDAW
[GMB+ 05]
Langage de requêtes
ObjetRelationnel
gRNA
[LBC+ 02]
ObjetRelationnel
GUS
[DCB+ 01]
Relationnel
ENQUire
[JMS96]
TINet [EKJ01]
suite page suivante...
Types de sources
Apprentissage
Entrepôts de données
Complémentaires Apprentissage
du langage de
requêtes
du langage de
requêtes
du langage de
requêtes
Fédération de données
Orienté-objet
Complémentaires Aucun apprenou non
tissage
Orienté-objet
Complémentaires
Apprentissage
du langage de
requêtes
Transparence
Type
d’intégration
Sources imposées
Entrepôt
Sources imposées
Entrepôt
Sources imposées
Entrepôt
Sources choisies par l’utilisateur
Sources imposées
Fédération
Multibase
...suite de la page précédente
ISYS [STF+ 01]
IGD-GIS
[BLR97]
175
BioNavigator
[Gaë00]
Entrez [NCB]
Portail Web
GeneCards
[RCCPL98]
SRS [ZLAE02]
Portail Web
BACIIS
[BMLBL03]
DiscoveryLink
[HSK+ 01]
Portail Web
Portail Web
suite page suivante...
Architectures à base d’agents logiciels
Orienté-objet
ou non
du langage de
requêtes
Orienté-objet
ou non
du langage de
requêtes
Intégration navigationnelle
Fichers plats
Complémentaires Aucun apprentissage
Enregistrements Complémentaires Aucun apprenhyperliés
tissage
Fichiers plats Complémentaires Aucun apprenindexés
tissage
Ensemble d’en- Complémentaires Aucune
registrements
avec
quelques connaissance
hyperliés
redondances
requise
ObjetRelationnel
ObjetRelationnel
Médiation de données
Complémentaires Interactif
Complémentaires
avec
quelques
redondances
Apprentissage
du langage de
requêtes
Agents
Choix par l’utilisateur
Sources imposées
Navigationnelle
Sources imposées
Sources imposées
Médiation
Agents
Navigationnelle
Navigation /
Entrepôt
Navigationnelle
Médiation
K2/BioKleisli
[DCB+ 01]
Semi-structuré
Complémentaires
Kind [GLM00]
Semi-structuré
Complémentaires
TAMBIS
[SBB+ 00]
ObjetRelationnel
Complémentaires
Apprentissage
du langage de
requêtes
Apprentissage
du langage de
requêtes
Interactif
...suite de la page précédente
Choix par l’uti- Médiation
lisateur
Médiation
Sources imposées
Médiation
176
B
Approches d’intégration et
prototypes associés
177
Projets et prototypes associés aux approches d’intégration de données biologiques
Entrepôt de données
Intégration de vues
Multi-agents
Fédération
Collecte de données
SRS
LinkDB/DBGet
Entrez
BioNavigator
Expasy
WebDBGet
Genera
GenomeNet
GUS
IGD-I
BioMolQuest
Gedaw
gRNA
Genobase
InterPro
WCS
Limbo
DataFoundry
GIMS
Atlas
BioKleisli/K2
Pizzkel/Kleisli
P/FDM
OPM
Tambis
Semeda
ABCKB
BioTrifu
BACIIS
IBM DiscoveryLink
KIND
BioMediator
ISYS
IGD-GID
GDB
Docking-D
TinET
INDUS
Genecards
UniProt
Enquire
178
Fédération par hyperliens
Intégration pair à pair
Promethea
The SEED
BioFuice
C
Index des méthodes d’extraction de
données Web
179
Classification et articles de référence des principales méthodes d’extraction de données du Web
Apprentissage supervisé
Extraction automatique de régularités
Induction interactive
WIEN [KWD97]
Stalker [MMK01]
SoftMealy [HD98]
LP2 [CDWP02]
RoadRunner [CMM01]
IEPAD [CL01]
ExALG [AGM03]
BYU [ECJ+ 99]
MDR [LGZ03]
OMINI [BLP01b]
Lixto [GKB+ 04]
W4F [SA99]
NoDoSE [Ade98]
WetDL [HQ04]
180
D
Schéma XSD des termes d’attributs
181
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
<?xml ve rsi o n=” 1 . 0 ” e n c o d i n g=”UTF−8 ”?>
<x s : s c h e m a x m l n s : x s=” h t t p : //www. w3 . o r g /2001/ XMLSchema”>
<xs:element name=” f s ”>
<x s : c o m p l e x T y p e>
< x s : c h o i c e m i n O ccu r s=”0 ” maxOccurs=”unbounded ”>
<xs:element r e f=” f ”/>
<xs:element r e f=” f A l t ”/>
</ x s : c h o i c e>
< x s : a t t r i b u t e name=” i d ” t y p e=” x s : I D ”/>
< x s : a t t r i b u t e name=”n ” t y p e=” x s : s t r i n g ”/>
< x s : a t t r i b u t e name=” t y p e ” t y p e=” x s : s t r i n g ”/>
< x s : a t t r i b u t e name=” f e a t s ” t y p e=”xs:IDREFS ”/>
< x s : a t t r i b u t e name=” c o p y o f ” t y p e=”xs:IDREF ” />
< x s : a t t r i b u t e name=” r e l ” d e f a u l t=” sb ”>
<x s : s i m p l e T y p e>
< x s : r e s t r i c t i o n b a s e=” x s : s t r i n g ”>
<x s : e n u m e r a t i o n v a l u e=”eq ”/>
<x s : e n u m e r a t i o n v a l u e=”ne ”/>
<x s : e n u m e r a t i o n v a l u e=”sb ”/>
<x s : e n u m e r a t i o n v a l u e=”n s ”/>
</ x s : r e s t r i c t i o n>
</ x s : s i m p l e T y p e>
</ x s : a t t r i b u t e>
</ x s : c o m p l e x T y p e>
</ xs:element>
<xs:element name=” f ”>
< x s : c h o i c e>
<xs:element r e f=”sym ”/>
<xs:element r e f=” s t r i n g ”/>
<xs:element r e f=”number ”/>
<xs:element r e f=” b o o l e a n ”/>
<xs:element r e f=” d a t e ”/>
<xs:element r e f=” v A l t ”/>
<xs:element r e f=” f s ” m i n O ccu r s=”0 ” maxOccurs=”unbounded”/>
</ x s : c h o i c e>
< x s : a t t r i b u t e name=”name ” t y p e=”xs:NMTOKEN ” u s e=” r e q u i r e d ”/>
< x s : a t t r i b u t e name=” l a b e l ” t y p e=” x s : s t r i n g ”/>
< x s : a t t r i b u t e name=” o r g ”>
< x s : r e s t r i c t i o n b a s e=”xs:NMTOKEN ”>
<x s : e n u m e r a t i o n v a l u e=” s i n g l e ”/>
<x s : e n u m e r a t i o n v a l u e=” s e t ”/>
<x s : e n u m e r a t i o n v a l u e=”bag ”/>
<x s : e n u m e r a t i o n v a l u e=” l i s t ”/>
< x s : a t t r i b u t e name=” r e l ” d e f a u l t=”eq ”>
<x s : e n u m e r a t i o n v a l u e=” sb ”/>
<x s : e n u m e r a t i o n v a l u e=” n s ”/>
< x s : a t t r i b u t e name=” f V a l ” t y p e=”xs:IDREFS ”/>
</ xs:element>
<xs:element name=” f L i b ”>
< x s : c h o i c e m i n O ccu r s=”0 ” maxOccurs=”unbounded ”>
</ x s : c h o i c e>
</ xs:element>
182
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
<xs:element name=” f s L i b ”>
< x s : c h o i c e m i n O ccu r s=”0 ” maxOccurs=”unbounded”>
<xs:element r e f=” f s ”/>
</ x s : c h o i c e>
</ xs:element>
<xs:element name=”sym ”>
< x s : a t t r i b u t e name=” v a l u e ” t y p e=” x s : s t r i n g ” u s e=” r e q u i r e d ”/>
</ xs:element>
<xs:element name=” s t r i n g ”>
< x s : a t t r i b u t e name=” v a l u e ” t y p e=” x s : s t r i n g ” u s e=” r e q u i r e d ”/>
</ xs:element>
<xs:element name=”number ”>
< x s : a t t r i b u t e name=” v a l u e ” t y p e=” x s : d o u b l e ” u s e=” r e q u i r e d ”/>
< x s : a t t r i b u t e name=” val u eTo ” t y p e=” x s : d o u b l e ”/>
<x s : e n u m e r a t i o n v a l u e=” l t ”/>
<x s : e n u m e r a t i o n v a l u e=” l e ”/>
<x s : e n u m e r a t i o n v a l u e=” g t ”/>
<x s : e n u m e r a t i o n v a l u e=” ge ”/>
</ xs:element>
<xs:element name=” b o o l e a n ”>
< x s : a t t r i b u t e name=” v a l u e ” t y p e=” x s : b o o l e a n ” u s e=” r e q u i r e d ”/>
183
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
<x s : e n u m e r a t i o n
<x s : e n u m e r a t i o n
</ xs:element>
v a l u e=” g t ”/>
v a l u e=” ge ”/>
<xs:element name=” d a t e ”>
< x s : a t t r i b u t e name=” v a l u e ” t y p e=” x s : d a t e ” u s e=” r e q u i r e d ”/>
<x s : e n u m e r a t i o n v a l u e=” g t ”/>
<x s : e n u m e r a t i o n v a l u e=” ge ”/>
</ xs:element>
<xs:element name=” f A l t ”>
</ x s : c h o i c e>
< x s : a t t r i b u t e name=”mutExcl ”>
< x s : r e s t r i c t i o n b a s e=”xs:NMTOKEN ”>
<x s : e n u m e r a t i o n v a l u e=”Y”/>
<x s : e n u m e r a t i o n v a l u e=”N”/>
</ xs:element>
<xs:element name=” v A l t ”>
<xs:element r e f=”sym ”/>
<xs:element r e f=” s t r i n g ”/>
<xs:element r e f=”number ”/>
<xs:element r e f=” b o o l e a n ”/>
<xs:element r e f=” d a t e ”/>
</ x s : c h o i c e>
</ xs:element>
</ x s : s c h e m a>
184
Glossaire
ADN : Acide DésoxyriboNucléique. L’ADN est le support de l’hérédité ou de l’information
génétique, car il constitue le génome des êtres vivants et se transmet en totalité
ou en partie lors des processus de reproduction. L’ADN détermine la synthèse des
protéines. La molécule d’ADN est formée de répétitions de nucléosides constitués
de quatres bases différentes (adénine, guanine, thymine, cytosine) qui se présentent
en simple brin ou en double brin (complémentaires et antiparallèles).
API : Application Programming Interface (Interface de programmation publique). Bibliothèque de fonctions destinées à être utilisées par les programmeurs dans leurs
applications. Ces fonctions facilitent l’écriture des programmes en fournissant des
procédures pour gérer des éléments particuliers : affichage, connexion à une base
de données, pilotage de périphériques...
BLAST : Basic Local Alignment Search Tool est un algorithme de comparaison de séquences. En fonction du site sur lequel l’utilisateur pose sa requête, l’algorithme
utilisé pourra s’avérer différent, donc fournir des résultats divergents.
cluster : (grappe en français) Architecture de groupes d’ordinateurs, utilisée pour former
de gros serveurs. Chaque machine est un nœud du cluster, l’ensemble est considéré
comme une seule et unique machine, permettant d’obtenir une grande puissance de
traitement. Ce type d’architecture est utilisé principalement pour le décisionnel,
le transactionnel et l’entrepôt de données.
cytologie : Partie de la biologie qui étudie la cellule.
DTD : Une DTD, acronyme anglais signifiant Document Type Definition, se traduisant
par Définition de Type de Document, est un document permettant de décrire un
modèle de document SGML ou XML. Une DTD indique les noms des éléments
pouvant apparaı̂tre et leur contenu constitué par leurs sous-éléments et leurs attributs.
EDI : Environnement de Développement Intégré. Dans ce genre d’environnement, le programmeur dispose, à partir de la même interface, d’outils comme l’éditeur, le
185
compilateur, l’éditeur de liens ou le débogueur. Des exemples d’EDI sont Visual
Studio de Microsoft, le projet Eclipse ou VisualAge d’IBM.
exon : Chez les organismes eucaryotes, les gènes qui codent pour des protéines sont
constitués d’une suite d’exons et d’introns alternés. Par exemple : Exon1-Intron1Exon2-Intron2-Exon3. Après la phase de transcription, l’ARN synthétisé va subir
un certain nombre de modifications dont l’épissage, au cours duquel les exons vont
être raboutés et les introns vont être excisés de l’ARN. Les exons représentent
donc la partie codante de l’ARNm, c’est-à-dire celle qui est traduite en protéine.
Les introns ne jouent aucun rôle dans la suite du devenir de l’ARN (protéine pour
l’ARNm, ribosome pour l’ARNr, traduction pour l’ARNt) ; leurs fonctions ne sont
pas très bien déterminées à ce jour. Le rôle le plus important des introns est de
permettre une combinatoire dans le raboutage des exons lors de l’épissage. Ceci
permet aux gènes à ARNm de coder pour plusieurs protéines.
FASTA : FASTA est un outil d’alignement de séquences ADN ou protéiques proposé par
David J. Lipman et William R. Pearson en 1985 dans l’article “Rapid and sensitive
protein similarity searches”. Le programme original “FASTP” était destiné à la
recherche de similarités entre protéines.
homonymie : Caractère d’un mot identique à un autre par la prononciation, mais de
sens différent. Des mots homonymes peuvent de plus être homographes : ils se
prononcent de la même façon, ont des sens différents, mais s’écrivent de manière
identique. Homonymes simples : vers, vert, ver et verre. Homonymes et homographes : sais-tu qu’il s’est tu ?
locus : Emplacement d’un gène sur un chromosome.
micro-réseau : Un micro-réseau (ou micro-array) est une matrice dans laquelle sont
placés un ensemble de gènes ; chaque case qui s’illumine indique qu’un gène s’y
est exprimé. Les micro-réseaux sont utilisés afin de détecter le développement des
maladies, en fonction des gènes exprimés chez le patient.
nomenclature de localisation : Les chromosomes adoptent presque tous une forme en
X et ont le plus souvent 2 bras courts et 2 bras longs. Grâce à des colorations
effectuées en laboratoire, il est possible de diviser chaque bras en zones appelées
régions, qui sont subdivisées elles-mêmes en bandes et en sous-bandes. Ceci a été
fixé arbitrairement à la convention de Paris en 1971. Elles correspondent à la
localisation d’informations sur les chromosomes. Ainsi, “5q31q33” signifie “chromosome 5”, “grand bras” (désigné par la lettre q, p pour le petit), entre les zones
“31” et “33” (plus le chiffre est grand, et plus l’on s’éloigne du centromère).
186
nucléotides : Les nucléotides sont des acides désoxyribonucléiques pour l’ADN et ribonucléiques pour l’ARN. Ils sont conventionnellement représentés par les lettres
A,T,C,G pour l’ADN, et A,U,C,G pour l’ARN.
réseau de régulation : Les réseaux de régulation concernent des ensembles d’entités en
relation pouvant interagir les unes avec les autres et avec elles-mêmes. Il s’agit
de systèmes complexes, notamment en présence de boucles de rétroaction. En
sciences de la vie, notamment en biologie, les réseaux de régulation sont à la
base de modèles en plein développement, permettant de mieux comprendre le
fonctionnement des organismes vivants. L’approche la plus traditionnelle est celle
des voies métaboliques, auxquelles sont intégrées les interactions entre protéines
et/ou substrats. Cependant, des travaux récents se concentrent sur les gènes euxmêmes.
sémantique : La sémantique est, dans les sciences du langage, opposée à la syntaxe. La
syntaxe concerne les règles formelles, alors que la sémantique concerne la signification. Dans le domaine informatique, le but du “Semantic Web” est de permettre
aux machines d’échanger des informations en utilisant le sens des mots comme
dans les langages naturels. Cet objectif ambitieux nécessite un travail important
sur les langages, la structure des systèmes, et les ontologies.
SGBD : Système de Gestion de Bases de Données.
synonymie : Relation sémantique entre des mots ou des expressions dont les sens sont
identiques ou très proches. Le synonyme d’un mot appartient nécessairement à
la même catégorie grammaticale que celui-ci. La synonymie absolue, qui fait que
deux mots sont interchangeables dans tous les contextes, est très rare. Dans la
majorité des cas, la synonymie est relative ou partielle et les deux mots ne sont
interchangeables que dans certains contextes.
taxinomie : (ou taxonomie) Science, lois, ou principes de classification systématique qui
permettent la division en groupes ordonnés ou en catégories.
transcriptome : Le transcriptome est l’ensemble des ARN messagers (molécules servant
de matrice pour la synthèse des protéines) issu de l’expression d’une partie du
génome d’un tissu cellulaire ou d’un type de cellule. La caractérisation et la quantification du transcriptome dans un tissu donné et dans des conditions données
permet d’identifier les gènes actifs, de déterminer les mécanismes de régulation
d’expression des gènes et de définir les réseaux d’expression des gènes.
URL : Cet acronyme signifie Uniform Resource Locator, qui se traduit littéralement par
localisateur uniforme de ressource, et désigne une chaı̂ne de caractères (codée en
187
ASCII, donc utilisant l’alphabet anglais, ce qui signifie qu’elle ne présente aucun
accent comme é ou ı̂) qui est utilisée pour adresser les ressources du World Wide
Web telles que des documents HTML, des images ou des sons.
188
Bibliographie
[AAE+ 06]
Euan A. Adie, Richard R. Adams, Kathryn L. Evans, David J. Porteous, et
Ben S. Pickard. SUSPECTS : enabling fast and effective prioritization of
positional candidates. Bioinformatics, 22(6) pages 773–774, 2006.
[AASY97]
Divyakant Agrawal, Amr El Abbadi, Ambuj K. Singh, et Tolga Yurek. Efficient view maintenance at data warehouses. Dans Joan Peckham, éditeur,
Proceedings of the 1997 ACM SIGMOD International Conference on Management of Data (SIGMOD ’97), pages 417–427, New York, Etats-Unis,
1997. ACM Press.
[Abe94]
Karl Aberer. The Use of Object-oriented Data Models in Biomolecular Databases. Dans Proceedings of the 1st International Workshop on ObjectOriented Computing in the Natural Sciences (OOCNS’94), Heidelberg, Allemagne, 22–25 Novembre 1994.
[Abe95]
Karl Aberer. The Use of Object-oriented Data Models in Biomolecular Databases. Dans Proceedings of the 2nd International Workshop on
Object-Oriented Computing in the Natural Sciences (OOCNS’95), Grenoble,
France, 21–24 Novembre 1995.
[ABFS02]
Bernd Amann, Catriel Beeri, Irini Fundulaki, et Michel Scholl. Querying
XML Sources Using an Ontology-Based Mediator. Dans Proceedings of the
On the Move (OTM) Conferences : Confederated International Conferences
on Distributed Objects and Applications (DOA), Cooperative Information
Systems (CoopIS) and Ontologies, Databases and Applications of Semantics (ODBASE) 2002, pages 429–448, Londres, Royaume-Uni, Octobre 2002.
Springer-Verlag.
[ACPS96]
Sibel Adali, Kasim Selçuk Candan, Yannis Papakonstantinou, et Venkatramanan Siva Subrahmanian. Query Caching and Optimization in Distributed
Mediator Systems. Dans H. V. Jagadish et Inderpal Singh Mumick, éditeurs,
Proceedings of the 1996 ACM SIGMOD International Conference on Management of Data (SIGMOD ’96), pages 137–148. ACM Press, Juin 1996.
189
[ACV+ 00]
Vincent Aguilera, Sophie Cluet, Pierangelo Veltri, Dan Vodislav, et Fanny
Wattez. Querying XML documents in Xyleme. Rapport de recherche, Technical Report 182, Verso/INRIA, 2000.
[AD98]
Serge Abiteboul et Oliver M. Duschka. Complexity of answering queries
using materialized views. Dans Proceedings of the 17th ACM Special Interest Group on Algorithms and Computation Theory (SIGACT), Management Of Data (SIGMOD) and Artificial Intelligence (SIGART) Symposium
on Principles of Database Systems (PODS ’98), pages 254–263, New York,
Etats-Unis, 1998. ACM Press.
[Ade98]
Brad Adelberg. NoDoSE - a tool for semi-automatically extracting structured and semistructured data from text documents. Dans Proceedings of
the 1998 ACM SIGMOD International Conference on Management of Data
(SIGMOD ’98), pages 283–294, New York, Etats-Unis, 1998. ACM Press.
[AGM+ 90]
Stephen F. Altschul, Warren Gish, Webb Miller, Eugene W. Myers, et David J. Lipman. Basic Local Alignment Search Tool. Journal of Molecular
Biology, 215(3) pages 403–410, Octobre 1990.
[AGM03]
Arvind Arasu et Hector Garcia-Molina. Extracting structured data from
Web pages. Dans Proceedings of the 2003 ACM SIGMOD International
Conference on Management of Data (SIGMOD ’03), pages 337–348, New
York, Etats-Unis, 2003. ACM Press.
[AH96]
Karl Aberer et Klemens Hemm. A Methodology for Building a Data Warehouse in a Scientific Environment. Dans Proceedings of the 1st IFCIS
International Conference on Cooperative Information Systems (CoopIS’96),
pages 90–101, 1996.
[AKS98]
Naveen Ashish, Craig A. Knoblock, et Cyrus Shahabi. Intelligent Caching
for Information Mediators : A KR Based Approach. Dans Alexander Borgida, Vinay K. Chaudhri, et Martin Staudt, éditeurs, Proceedings of the 5th
International Workshop on Knowledge Representation Meets Databases : Innovative Application Programming and Query Interfaces (KRDB ’98), volume 10 of CEUR Workshop Proceedings, pages 3.1–3.7. CEUR-WS, Mai
1998.
[AL04]
Marcelo Arenas et Leonid Libkin. A normal form for XML documents. ACM
Transactions on Database Systems, 29(1) pages 195–232, Mars 2004.
[AMJR04]
Frank Lehmann-Horn Audrius Meskauskas et Karin Jurkat-Rott. Sight : automating genomic data-mining without programming skills. Bioinformatics,
20(11) pages 1718–1720, Juillet 2004.
190
[AMR06]
Koen Aerts, Karel Maesen, et Anton Van Rompaey. A Practical Example
of Semantic Interoperability of Large-Scale Topographic Databases Using
Semantic Web Technologies. Dans Proceedings of the 9th AGILE Conference
on Geographic Information Science, pages 35–42, Visegrád, Hongrie, 2006.
[Are03]
Andrew D. Arenson. Software review : Federating data with Information
Integrator. Briefings in Bioinformatics, 4(4) pages 375–381, Décembre 2003.
[ASL89]
A. M. Alashqur, Stanley Y. W. Su, et Herman Lam. OQL : A Query Language for Manipulating Object-oriented Databases. Dans Peter M. G. Apers
et Gio Wiederhold, éditeurs, Proceedings of the 15th International Conference on Very Large Data Bases (VLDB ’89), pages 433–442. Morgan Kaufmann, 22–25 Août 1989.
[ASN]
ASN.1. Abstract Syntax Notation One. http://asn1.elibel.tm.fr/en/.
[ATLB03]
Mike Ault, Madhu Tumma, Daniel Liu, et Don Burleson. Oracle Database
10g New Features : Oracle10g Reference for Advanced Tuning and Administration. Rampant TechPress, 2003.
[Att02]
Terri K. Attwood. The PRINTS database, a resource for identification of
protein families. Briefings in Bioinformatics, (3(3)) pages 252–263, Mars
2002.
[AVB01]
Frédéric Achard, Guy Vaysseix, et Emmanuel Barillot. XML, bioinformatics,
and data integration. Bioinformatics, 17(2) pages 115–125, 2001.
[BAB+ 04]
Ewan Birney, T. Daniel Andrews, Paul Bevan, Mario Cáccamo, Graham
Cameron, Yuan Chen, Laura Clarke, G. Coates, Tony Cox, James A. Cuff,
Val Curwen, Tim Cutts, Thomas Down, Richard Durbin, Eduardo Eyras,
X. M. Fernandez-Suarez, P. Gane, B. Gibbins, J. Gilbert, Martin Hammond,
H. Hotz, V. Iyer, Andreas Kähäri, K. Jekosch, Arek Kasprzyk, Damian
Keefe, S. Keenan, Heikki Lehväslaiho, Graham P. McVicker, Craig Melsopp,
Patrick Meidl, Emmanuel Mongin, Roger Pettett, S. Potter, Glenn Proctor,
M. Rae, S. Searle, Guy Slater, Damian Smedley, James Smith, W. Spooner,
Arne Stabenau, Jim Stalker, R. Storey, Abel Ureta-Vidal, Cara Woodwark,
Michele E. Clamp, et Tim J. P. Hubbard. Ensembl 2004. Nucleic Acids
Research, Database Issue, 32 pages 468–470, 2004.
[BAD+05]
Catherine A. Ball, Ihab A. B. Awad, Janos Demeter, Jeremy Gollub, Joan M.
Hebert, Tina Hernandez-Boussard, Heng Jin, John C. Matese, Michael Nitzberg, Farrell Wymore, Zachariah K. Zachariah, Patrick O. Brown, et Gavin Sherlock. The Stanford Microarray Database accommodates additional
191
microarray platforms and data formats. Nucleic Acids Research, 33 pages
580–582, 2005.
[BBC+ 02]
Amit Bahl, Brian Brunk, Ross L. Coppel, Jonathan Crabtree, Sharon J.
Diskin, Martin J. Fraunholz, Gregory R. Grant, Dinesh Gupta, Robert L.
Huestis, Jessica C. Kissinger, Philip Labo, Li Li, Shannon K. McWeeney,
Arthur J. Milgram, David S. Roos, Jonathan Schug, et Christian J. Stoeckert Jr. PlasmoDB : the Plasmodium genome resource. An integrated database providing tools for accessing, analyzing and mapping expression and
sequence data (both finished and unfinished). Nucleic Acids Research, 30(1)
pages 87–90, Janvier 2002.
[BBLO97]
Dennis A. Benson, Mark S. Boguski, David J. Lipman, et James Ostell.
GenBank. Nucleic Acids Research, 25(1) pages 1–6, 1997.
[BC04a]
Omar Boucelma et François-Marie Colonna. GQuery : A Query Language
for GML. Dans Elfriede Fendel et Massimo Rumor, éditeurs, Proceedings of
the 24th Urban Data Management Symposium (UDMS 2004), pages 23–32,
Chioggia, Italie, 27–29 Octobre 2004.
[BC04b]
Omar Boucelma et François-Marie Colonna. Mediation for Online Geoservices. Dans Proceedings of the 4th Web and Wireless Geographical Information Systems International Workshop (W2GIS 2004), pages 81–93, Hang
Kong, Corée, 2004. Springer.
[BCE04]
Omar Boucelma, François-Marie Colonna, et Mehdi Essid. The VirGIS Geographic Integration System. Dans Actes des Vingtièmes Journées Bases de
Données Avancées (BDA 2004), Montpellier, France, 19–22 Octobre 2004.
[BCL03]
Sourav S. Bhowmick, Pedro Cruz, et Amey V. Laud. XomatiQ : Living With
Genomes, Proteomes, Relations and a Little Bit of XML. Dans Proceedings
of the 19th International Conference on Data Engineering (ICDE 2003),
pages 857–868, 2003.
[BDF+ 03]
Peter Buneman, Susan Davidson, Wenfei Fan, Carmem Hara, et WangChiew Tan. Reasoning about keys for XML. Information Systems, 28(8)
pages 1037–1063, 2003.
[BE03]
Joachim Biskup et David W. Embley. Extracting information from heterogeneous information sources using ontologically specified target views. Information Systems, 28(3) pages 169–212, 2003.
[BEL02]
Omar Boucelma, Mehdi Essid, et Zoé Lacroix. A WFS-based mediation system for GIS interoperability. Dans Proceedings of the 10th ACM Internatio192
nal Symposium on Advances in Geographic Information Systems (ACM-GIS
2002, pages 23–28, McLean, Virginie, Etats-Unis, 8–9 Novembre 2002.
[BFG01]
Robert Baumgartner, Sergio Flesca, et Georg Gottlob. The Elog Web Extraction Language. Dans Proceedings of 8th International Conference on
Logic for Programming, Artificial Intelligence and Reasoning (LPAR 2001),
volume 2250 of Lecture Notes in Computer Science, pages 548–560, Londres,
Royaume-Uni, 3–7 Décembre 2001. Springer-Verlag.
[BFL04]
Sarah Cohen Boulakia, Christine Froidevaux, et Séverine Lair. Interrogation
de sources biomédicales : prise en compte des préférences de l’utilisateur.
Dans Actes des 4èmes journées Extraction et Gestion des Connaissances
(EGC’2004), Revue des Nouvelles Technologies de l’Information, pages 53–
64, Clermont-Ferrand, France, 20–23 Janvier 2004. Cépaduès-Éditions.
[BGL+99]
Chaitan Baru, Amarnath Gupta, Bertram Ludäscher, Richard Marciano,
Yannis Papakonstantinou, Pavel Velikhov, et Vincent Chu. XML-based information mediation with MIX. SIGMOD Records, 28(2) pages 597–599,
1999.
[Bis98]
Yaser A. Bishr. Overcoming the Semantic and Other Barriers to GIS Interoperability. International Journal of Geographical Information Science,
12(4) pages 299–314, 1998.
[BJL+ 99]
Djamal Benslimane, Fabrice Jouanot, Robert Laurini, Kokou Yétongnon,
Nadine Cullot, et Marinette Savonnet. Interopérabilité de SIG : un état de
l’art. Revue Internationale de Géomatique, 9(3) pages 279–316, 1999.
[BKL+ 04]
Michael Boyd, Sasivimol Kittivoravitkul, Charalambos Lazanitis, Peter McBrien, et Nikos Rizopoulos. AutoMed : A BAV Data Integration System
for Heterogeneous Data Sources. Dans Proceedings of the 16th International
Conference on Advanced Information Systems Engineering (CAiSE 2004),
volume 3084 of Lecture Notes in Computer Science, pages 82–97, Riga, Lettonie, 7–11 June 2004. Springer.
[BL02]
Omar Boucelma et Zoé Lacroix. Mediation-based Integration of Heterogeneous Biological Resources. Dans Proceedings of the 13th ISMIS Workshop
on Bioinformatics (ISMIS 2002), Lyon, France, Juin 2002.
[BLN86]
Carlo Batini, Maurizio Lenzerini, et Shamkant B. Navathe. A comparative
analysis of methodologies for database schema integration. ACM Computing
Survey, 18(4) pages 323–364, 1986.
[BLP01a]
David Buttler, Ling Liu, et Calton Pu. A Fully Automated Object Extraction System for the World Wide Web. Dans Proceedings of the 21st
193
International Conference on Distributed Computing Systems (ICDCS ’01),
page 361, Washington, Etats-Unis, 2001. IEEE Computer Society.
[BLP01b]
David Buttler, Ling Liu, et Carlton Pu. A Fully Automated Object Extraction System for the World Wide Web. Dans Proceedings of the 2001
International Conference on Distributed Computing Systems (ICDCS’01),
pages 361–370, Phoenix, Arizona, Mai 2001.
[BLR97]
Ekard Burger, Johannes Link, et Otto Ritter. A Multi-Agent Architecture
for the Integration of Genomic Information. Dans Proceedings of the 1st
International Workshop on Intelligent Information Integration (III’97), Fribourg, Allemagne, Septembre 1997.
[BMLBL03] Zina Ben-Miled, Nianhua Li, Mark Baumgartner, et Yang Liu. A Decentralized Approach to the Integration of Life Science Web Databases. Informatica,
27(1) pages 3–14, 2003.
[BMLL+ 04] Zina Ben-Miled, Nianhua Li, Yang Liu, Yue He, Eric Lynch, et Omran A.
Bukhres. On the Integration of a Large Number of Life Science Web Databases. Dans Proceedings of the 1st Database Integration in the Life Sciences
Workshop (DILS 2004), pages 172–186, 25–26 Mars 2004.
[Bre99]
Steven E. Brenner. Errors in genome annotation. Trends in Genetics, 15
pages 132–133, 1999.
[Bur02]
Sean M. Burke. Perl and LWP : fetching Web pages, parsing HTML, writing
spiders and more. O’Reilly, 2002.
[Can05]
Génome Canada. Politique sur la diffusion des données et le partage des
ressources. Rapport de recherche, Génome Canada, Juillet 2005.
[Car92]
Robert L. Carpenter. The Logic of Typed Feature Structures. Cambridge
University Press, Nomvembre 1992.
[CBB+ 00]
Roderic G. G. Cattell, Douglas K. Barry, Mark Berler, Jeff Eastman, David
Jordan, Craig Russell, Olaf Schadow, Torsten Stanienda, et Fernando Velez.
The Object Data Standard : ODMG 3.0. Morgan Kaufmann, Janvier 2000.
[CBP+ 05]
Doina Caragea, Jie Bao, Jyotishman Pathak, Adrian Silvescu, Carson M.
Andorf, Drena Dobbs, et Vasant Honavar. Information Integration from Semantically Heterogeneous Biological Data Sources. Dans Proceedings of the
16th International Workshop on Database and Expert Systems Applications
(DEXA 2005), pages 580–584, Copenhague, Danemark, 22–26 Août 2005.
[CCCR04]
James A. Cuff, Guy M.P. Coates, Tim J.R. Cutts, et Mark Rae. The Ensembl
Computing Architecture. Genome Research, 14(5) pages 971–975, Mai 2004.
194
[CCD06]
CCDS.
Consensus
CDS
http://www.ncbi.nlm.nih.gov/CCDS/, 2006.
protein
set.
[CCS93]
Edgar Frank Codd, Sharon B. Codd, et Clynch T. Salley. Providing OLAP
(On-line Analytical Processing) to User-Analysts : An IT Mandate. Rapport
de recherche, 1993.
[CDWP02]
Fabio Ciravegna, Alexiei Dingli, Yorick Wilks, et Daniela Petrelli. Adaptive
information extraction for document annotation in amilcare. Dans Proceedings of the 25th Annual International ACM SIGIR Conference on Research
and Development in information retrieval (SIGIR ’02), pages 451–451, New
[CEA+ 04]
Val Curwen, Eduardo Eyras, Daniel T. Andrews, Laura Clarke, Emmanuel
Mongin, , Steven M. Searle, et Michele Clamp. The Ensembl Automatic
Gene Annotation System. Genome Research, 14(5) pages 942–950, Mai 2004.
[CGM98]
Terence Critchlow, Madhavan Ganesh, et Ron Musick. Automatic Generation of Warehouse Mediators using an Ontology Engine. Dans Knowledge
Representation Meets Databases, Proceedings of the 5th KRDB Workshop
(KRDB ’98), pages 8.1–8.8, Seattle, Etats-Unis, 31 Mai 1998.
[CGMH+ 94] Sudarshan Chawathe, Hector Garcia-Molina, Joachim Hammer, Kelly Ireland, Yannis Papakonstantinou, Jeffrey D. Ullman, et Jennifer Widom. The
TSIMMIS Project : Integration of heterogeneous information sources. Dans
Proceedings of the 16th Meeting of the Information Processing Society of
Japan, pages 7–18, Tokyo, Japon, 1994.
[Cha98]
Don Chamberlin. A Complete Guide to DB2 Universal Database. Morgan
Kaufmann Publishers, San Francisco, Californie, 1998.
[CL01]
Chia-Hui Chang et Shao-Chen Lui. IEPAD : information extraction based
on pattern discovery. Dans Proceedings of the 10th International World
Wide Web Conference (WWW 10), pages 681–688, Hong Kong, Chine, 1–5
Mai 2001.
[CLL01]
Diego Calvanese, Domenico Lembo, et Maurizio Lenzerini. Survey on methods for query rewriting and query answering using views. Rapport de
recherche D1.R5, Université de Rome ”La Sapienza”, Rome, Italie, Avril
2001.
[CLRS01]
Thomas H. Cormen, Charles E. Leiserson, Ronald L. Rivest, et Clifford
Stein. Introduction to Algorithms. MIT Press, Octobre 2001.
[CM95]
I-Min A. Chen et Victor M. Markowitz. An overview of the object protocol
195
model (OPM) and the OPM data management tools. Information Systems,
20(5) pages 393–418, 1995.
[CM06]
Kajal T. Claypool et Sanjay Madria. A P2P Integration Architecture for
Protein Resources. Dans Proceedings of the 17th International Conference
on Database and Expert Systems Applications (DEXA ’06), pages 717–721,
Washington, Etats-Unis, 2006. IEEE Computer Society.
[CMM01]
Valter Crescenzi, Giansalvatore Mecca, et Paolo Merialdo. RoadRunner : Towards Automatic Data Extraction from Large Web Sites. Dans Proceedings
of the 27th International Conference on Very Large Data Bases (VLDB ’01),
pages 109–118, 2001.
[Col97]
Robert M. Colomb. Impact of Semantic Heterogeneity and Federating Databases. The Computer Journal, 40(5) pages 235–244, 1997.
[Col06]
François-Marie Colonna. Communication personnelle avec Bert Overduin
du service Ensembl Helpdesk, Juin 2006.
[Com05]
Committee on Frontiers at the Interface of Computing and Biology. Catalyzing Inquiry at the Interface of Computing and Biology. National Research
Council of the National Academies, Washington, Etats-Unis, 2005.
[CR07]
Marc Van Cappellen et Jonathan Robie. White Paper : Performance Tips
for DataDirect XQuery. DataDirect Technologies, 2007.
[CSB06]
François-Marie Colonna, Yacine Sam, et Omar Boucelma. Database Integration for Predisposition Genes Discovery. Dans Challenges and Opportunities
of Healthgrids, Proceedings of 4th HealthGrid Annual Conference, volume
120 of Studies in Health Technology and Informatics. IOS Press, 7–9 Juin
2006.
[CVV01]
Sophie Cluet, Pierangelo Veltri, et Dan Vodislav. Views in a Large Scale
XML Repository. Dans Proceedings of the 27th International Conference
on Very Large Data Bases (VLDB, pages 271–280, Rome, Italie, 11–14 Septembre 2001.
[Dai04]
Fabrice Daian. Fouille et intégration de données génomiques. Mémoire de
Master, DEA Informatique, Faculté des Sciences de Luminy, Marseille, 2004.
[Dat03]
Christopher J. Date. An Introduction to Database Systems. Addison Wesley
Longman, 2003.
[DCB+ 01]
Susan B. Davidson, Jonathan Crabtree, Brian P. Brunk, Jonathan Schug,
Val Tannen, G. Christian Overton, et Christian J. Stoeckert Jr. K2/Kleisli
and GUS : experiments in integrated access to genomic data sources. IBM
Systems Journal, 40(2) pages 512–531, 2001.
196
[DDB06]
DDBJ. DNA Data Bank of Japan. http://www.ddbj.nig.ac.jp, 2006.
[DG97]
Oliver M. Duschka et M R. Genesereth. Query Planning in Infomaster. Dans
Proceedings of the 12th ACM Symposium on Applied Computing (SAC ’97),
pages 109–111, San José, Etats-Unis, 28 Février–2 Mars 1997. ACM Press.
[DGY05]
Florin Dragan, Georges Gardarin, et Laurent Yeh. MediaPeer : A Safe, Scalable P2P Architecture for XML Query Processing. Dans Proceedings of the
16th International Workshop on Database and Expert Systems Applications
(DEXA 2005), pages 368–373, Copenhague, Danemark, 22–26 August 2005.
IEEE Computer Society.
[DKE01]
Werner Dubitzky, Olga Krebs, et Roland Eils. Minding, OLAPing, and
mining biological data : towards a data warehousing concept in biology. Dans
Proceedings of the 1st Network Tools and Applications in Biology (NETTAB
2001), CORBA and XML : Towards a Bioinformatics Integrated Network
Environment, pages 78–82, 2001.
[DLW00]
Susan B. Davidson, Hartmut Liefke, et Limsoon Wong. Creating and Maintaining Curated View Databases. Rapport de recherche, World Scientific
Publishing Company, Juin 2000.
[DOB95]
Susan B. Davidson, G. Christian Overton, et Peter Buneman. Challenges
in Integrating Biological Data Sources. Journal of Computational Biology,
2(4) pages 557–572, 1995.
[DOTW97] Susan B. Davidson, G. Christian Overton, Val Tannen, et Limsoon Wong.
BioKleisli : A Digital Library for Biomedical Researchers. International
Journal on Digital Libraries, 1(1) pages 36–53, 1997.
[DR04]
Hong Hai Do et Erhard Rahm. Flexible Integration of Molecular-Biological
Annotation Data : The GenMapper Approach. Dans Proceedings of the 9th
International Conference on Extending Database Technology (EDBT 2004),
volume 2992 of Lecture Notes in Computer Science, pages 811–822. Springer,
14–18 Mars 2004.
[DS04]
Marie-Dominique Devignes et Malika Smaı̈l. Integration of biological data
from web resources : Management of multiple answers through metadata
retrieval. Dans Proceedings of 12th International Conference on Intelligent
Systems for Molecular Biology - 3rd European Conference on Computational
Biology (ISMB-ECCB 2004), Août 2004.
[DSS02]
Marie-Dominique Devignes, André Schaaff, et Malika Smaı̈l. Collecte et
intégration de données biologiques hétérogènes sur le web. Ingénierie des
Systèmes d’Information, 7(1-2) pages 45–61, 2002.
197
[Dub03]
Nicolas Dubois. Package Feature Structure : Rapport de stage. Equipe
Langue & Dialogue, LORIA, Août 2003.
[DW03]
Susan Davidson et Limsoon Wong. The Kleisli Approach to Data Transformation and Integration. Dans The Functional Approach to Data Management : Modeling, Analyzing, and Integrating Heterogeneous Data, chapitre 6,
pages 135–165. Springer-Verlag, Septembre 2003.
[EBB06]
Mehdi Essid, Omar Boucelma, et Stéphane Bressan. Answering Queries
in the Presence of XML Keys. Dans Proceedings of the 17th International Workshop on Database and Expert Systems Applications (DEXA 2006),
pages 476–481, Cracovie, Pologne, 4–8 Septembre 2006. IEEE Computer
Society.
[EBCL04]
Mehdi Essid, Omar Boucelma, François-Marie Colonna, et Yassine Lassoued.
Query Processing in a Geographic Mediation System. Dans 12th ACM International Workshop on Geographic Information Systems (ACM-GIS 2004),
pages 101–108, Washington DC, Etats-Unis, 12–13 Novembre 2004. ACM.
[EBG+ 07]
Robert Ennals, Eric A. Brewer, Minos N. Garofalakis, Michael Shadle, et
Prashant Gandhi. Intel Mash Maker : join the web. SIGMOD Record, 36(4)
pages 27–33, Décembre 2007.
[EBI06]
EBI. European Bioinformatics Institute. http://www.ebi.ac.uk/, 2006.
[ECBB06]
Mehdi Essid, François-Marie Colonna, Omar Boucelma, et Abdelkader Bétari. Querying Mediated Geographic Data Sources. Dans Advances in Database Technology - EDBT 2006, 10th International Conference on Extending Database Technology (EDBT 2006), volume 3896 of Lecture Notes in
Computer Science, pages 1176–1181, Munich, Allemagne, 26–31 Mars 2006.
Springer.
[ECJ+ 99]
David W. Embley, Douglas M. Campbell, Y. S. Jiang, Stephen W. Liddle,
Deryle W. Lonsdale, Yiu-Kai Ng, et Randy D. Smith. Conceptual-modelbased data extraction from multiple-record Web pages. Data & Knowledge
Engineering, 31(3) pages 227–251, 1999.
[ECL03]
Henrik Engström, Sharma Chakravarthy, et Brian Lings. Maintenance policy
selection in heterogeneous data warehouse environments : a heuristics-based
approach. Dans Proceedings of the 6th ACM International Workshop on
Data warehousing and OLAP (DOLAP ’03), pages 71–78, New York, EtatsUnis, 2003. ACM Press.
[EDS+ 06]
Tina A. Eyre, Fabrice Ducluzeau, Tam P. Sneddon, Sue Povey, Elspeth A.
198
Bruford, et Michael J. Lush. The HUGO Gene Nomenclature Database,
2006 updates. Nucleic Acids Research, 34 pages 319–321, 2006.
[EJN99]
David W. Embley, Y. S. Jiang, et Yiu-Kai Ng. Record-Boundary Discovery
in Web Documents. Dans Alex Delis, Christos Faloutsos, et Shahram Ghandeharizadeh, éditeurs, Proceedings of the 1999 ACM SIGMOD International
Conference on Management of Data (SIGMOD ’99), pages 467–478. ACM
Press, 1–3 Juin 1999.
[EKJ01]
Barbara A. Eckman, Anthony S. Kosky, et Leonardo A. Laroco Jr. Extending traditional query-based integration approaches for functional characterization of post-genomic data. Bioinformatics, 17(7) pages 587–601,
2001.
[EMB07]
EMBL. Nucleotide Sequence Database. http://www.ebi.ac.uk/embl/,
2007.
[Ess05]
Mehdi Essid. Intégration des données et applications hétérogènes et distribuées sur le Web. Thèse de doctorat, Université de Provence, Marseille,
France, 2005.
[EUA96]
Thure Etzold, Anatoly Ulyanov, et Patrick Argos. SRS : Information Retrievat System for Molecular Biology Databanks. Methods in Enzymology,
266 pages 114–128, 1996.
[FABS02]
Irini Fundulaki, Bernd Amann, Catriel Beeri, et Michel Scholl. STYX :
Connecting the XML World to the World of Semantics. Dans Proceedings of
the 8th International Conference on Extending Database Technology (EDBT
2002), Prague, République Tchèque, Mars 2002.
[Fas94]
Ken Fasman. Restructuring the Genome Data Base : A model for a federation of biological databases. Journal of Computational Biology, 1(2) pages
165–171, 1994.
[FB02]
Christine Froidevaux et Sarah Cohen Boulakia. Intégration de Sources de
Données Génomiques du Web. Dans Actes électroniques des Journées scientifiques du Web Sémantique, Sorbonne, Paris, 2002.
[FBF+06]
Lude Franke, Harmvan Bakel, Like Fokkens, Edwin D. de Jong, Michael Egmont Petersen, et Cisca Wijmenga. Reconstruction of a Functional Human
Gene Network, with an Application for Prioritizing Positional Candidate
Genes. The American Journal of Human Genetics, 78(6) pages 1011–1025,
2006.
[FFMM94]
T. Finin, R. Fritzson, D. McKay, et R. McEntire. KQML as an Agent Communication Language. Dans N. Adam, B. Bhargava, et Y. Yesha, éditeurs,
199
Proceedings of the 3rd International Conference on Information and Knowledge Management (CIKM ’94), pages 456–463, Gaithersburg, Etats-Unis,
1994. ACM Press.
[FGM+ 98]
Wataru Fujibuchi, Susumu Goto, Hiroshi Migimatsu, Ikuo Uchiyama, Atsushi Ogiwara, Yutaka Akiyama, et Minoru Kanehisa. DBGET/linkDB : an
integrated database retrieval system. Dans Proceedings of the 3rd Pacific
Symposium on Biocomputing, pages 681–692, 1998.
[FHM91]
Douglas Fang, Joachim Hammer, et Dennis McLeod. The identification
and resolution of semantic heterogeneity in multidatabase systems. Dans
Proceedings of International Workshop on Interoperability in Multidatabase
Systems, pages 136–143, Kyoto, Japon, 7–9 Avril 1991.
[FKA+ 03]
Laurence Flori, Brice Kumulungui, Christophe Aucan, Christelle Esnault,
Alfred S. Traoré, Francis Fumoux, et Pascal Rihet. Linkage and association between Plasmodium falciparum blood infection levels and chromosome
5q31-q33. Genes and Immunity, 4(4) pages 265–268, 2003.
[FLM99]
Marc Friedman, Alon Levy, et Todd Millstein. Navigational plans for data
integration. Dans Proceedings of the 16th National Conference on Artificial
Intelligence (AAAI ’99) and the 11th Innovative Applications of Artificial
Intelligence Conference (IAAI ’99), pages 67–73, Menlo Park, Californie,
Etats-Unis, 1999. American Association for Artificial Intelligence.
[Fly06]
FlyBase.
A
database
of
the
http://flybase.bio.indiana.edu, 2006.
[FW97]
Marc Friedman et Daniel S. Weld. Efficiently Executing InformationGathering Plans. Dans Proceedings of the 15th International Joint Conference on Artificial Intelligence (IJCAI ’97), pages 785–791, 1997.
[Gal07]
Michael Y. Galperin. The Molecular Biology Database Collection : 2007
update. Nucleic Acids Research, Database Issue, 35, 2007.
[Gal08]
Michael Y. Galperin. The Molecular Biology Database Collection : 2008
update. Nucleic Acids Research, 36(1) pages 2–4, 2008.
[Gar03]
Georges Gardarin. Bases de données. Eyrolles, Août 2003.
[Gaë00]
Bruno André Gaëta. BioNavigator : an integrated web front-end for bioinformatics analysis. Australasian Biotechnology, 10(2), 2000.
[GB06]
Erich Gamma et Kent Beck. Eclipse : Principes, patterns et plug-in. Campus
Press, 2006.
200
Drosophila
Genome.
[GBB+03]
Jeremy Gollub, Catherine A. Ball, Gail Binkley, David B. Finkelstein Janos Demeter, Joan M. Hebert, Tina Hernandez-Boussard, Heng Jin, Miroslava Kaloper, John C. Matese, Mark Schroeder, Patrick O. Brown, David
Botstein, et Gavin Sherlock. The Stanford Microarray Database : data access and quality assessment tools. Nucleic Acids Research, 31(1) pages 94–96,
2003.
[GBMS99]
Cheng Hian Goh, Stéphane Bressan, Stuart Madnick, et Michael Siegel.
Context interchange : new features and formalisms for the intelligent integration of information. ACM Transactions on Information Systems, 17(3)
pages 270–292, 1999.
[Gen02]
Consortium Genostar. Genostar : an integrated bioinformatics platform for
exploratory genomics. http://www.genostar.com/, 2002.
[GGH+03]
Elisabeth Gasteiger, Alexandre Gattiker, Christine Hoogland, Ivan Ivanyi,
Ron D. Appel, et Amos Bairoch. ExPASy : The proteomics server for indepth protein knowledge and analysis. Nucleic Acids Research, 31(13) pages
3784–3788, Juillet 2003.
[GGM99]
Jean-Marc Geib, Christophe Gransart, et Philippe Merle.
concepts à la pratique. InterEditions, 1999.
[GHL07]
Robert P. Guralnick, Andrew W. Hill, et Meredith Lane. Towards a collaborative, global infrastructure for biodiversity assessment. Ecology Letters,
10(8) pages 663–672, Août 2007.
[GKB+04]
Georg Gottlob, Christoph Koch, Robert Baumgartner, Marcus Herzog, et
Sergio Flesca. The Lixto data extraction project : back and forth between
theory and practice. Dans Proceedings of the 23rd ACM Special Interest
Group on Algorithms and Computation Theory (SIGACT), Management
Of Data (SIGMOD) and Artificial Intelligence (SIGART) Symposium on
Principles of Database Systems (PODS ’04), pages 1–12, New York, EtatsUnis, 2004. ACM Press.
[GL94]
Piyush Gupta et Eileen Lin. DataJoiner : a practical approach to multidatabase access. Dans Proceedings of the 3rd International Conference on
Parallel and Distributed Information Systems (PDIS ’94), pages 264–264,
Los Alamitos, Californie, Etats-Unis, 1994. IEEE Computer Society Press.
[GLM00]
Amarnath Gupta, Bertram Ludascher, et Maryann E. Martone. KnowledgeBased Integration of Neuroscience Data Sources. Dans Proceedings of the
12th International Conference on Scientic and Statistical Database Manage201
Corba, des
ment (SSDBM), pages 39–52, Berlin, Allemagne, Juillet 2000. IEEE Computer Society.
[GLR06]
Anna Gambin, Slawomir Lasota, et Michal Rutkowski. Analyzing stationary
states of gene regulatory network using Petri nets. In Silico Biology, 6 pages
93–109, 2006.
[GM78]
Hervé Gallaire et Jack Minker, éditeurs. Proceedings of the Symposium on
Logic and Data Bases, Advances in Data Base Theory, Centre d’études et
de recherches de Toulouse, 1978. Plemum Press.
[GMB+ 05]
Emilie Guérin, Gwenaëlle Marquet, Anita Burgun, Olivier Loréal, Laure
Berti-Equille, Ulf Leser, et Fouzia Moussouni. Integrating and Warehousing
Liver Gene Expression Data and Related Biomedical Resources in GEDAW.
Dans Proceedings of the 2nd Database Integration in the Life Sciences Workshop (DILS 2005), pages 158–174, 20–22 Juillet 2005.
[GMPQ+ 97] Hector Garcia-Molina, Yannis Papakonstantinou, Dallan Quass, Anand Rajaraman, Yehoshua Sagiv, Jeffrey Ullman, Vasilis Vassalos, et Jennifer Widom. The TSIMMIS Approach to Mediation : Data Models and Languages.
Journal of Intelligent Information Systems, 8(2) pages 117–132, 1997.
[Goa01]
François Goasdoué. Réécriture de requêtes en termes de vues dans CARIN
et intégration d’informations. Thèse de doctorat, Université de Paris XI,
Orsay, 2001.
[Gri05]
Arthur Griffith. Java, XML, and the JAXP. Wiley, 2005.
[GSSC95]
Manuel Garcı́a-Solaco, Fèlix Saltor, et Malú Castellanos. Semantic heterogeneity in multidatabase systems. pages 129–202. Prentice Hall International
Ltd., Hertfordshire, Royaume-Uni, 1995.
[GUS05]
GUS.
GUS platform for functional genomics - Release 3.5.1.
http://www.gusdb.org, 2005.
[HAB+ 05]
Alon Y. Halevy, Naveen Ashish, Dina Bitton, Michael Carey, Denise Draper, Jeff Pollock, Arnon Rosenthal, et Vishal Sikka. Enterprise information
integration : successes, challenges and controversies. Dans Proceedings of
the 2005 ACM SIGMOD international conference on Management of data
(SIGMOD ’05), pages 778–787, New York, Etats-Unis, 2005. ACM.
[Hal01]
Alon Y. Halevy. Answering queries using views : A survey. VLDB Journal,
10(4) pages 270–294, 2001.
[HD98]
Chun-Nan Hsu et Ming-Tzung Dung. Generating finite-state transducers for
semi-structured data extraction from the Web. Information Systems, 23(9)
pages 521–538, 1998.
202
[HDRK97]
Sean Hamill, Maurice Dixon, Brian J. Read, et John R. Kalmus. Interoperating Database Systems : Issues and Architectures. Rapport de recherche TR97-063, Council for the central laboratory of the research councils, RoyaumeUni, 1997.
[HK04]
Thomas Hernandez et Subbarao Kambhampati. Integration of biological
sources : current systems and challenges ahead. SIGMOD Records, 33(3)
pages 51–60, 2004.
[HM85]
Dennis Heimbigner et Dennis McLeod. A federated architecture for information management. ACM Transactions on Information Systems, 3(3) pages
253–278, 1985.
[HM04]
Eliot Rusty Harold et William Scott Means. XML in a Nutshell, Third
Edition. O’Reilly Media, Inc., Octobre 2004.
[HN96]
Joseph M. Hellerstein et Jeffrey F. Naughton. Query execution techniques for
caching expensive methods. Dans Proceedings of the 1996 ACM SIGMOD
International Conference on Management of Data (SIGMOD ’96), pages
423–434, New York, Etats-Unis, 1996. ACM Press.
[HQ04]
Benjamin Habegger et Mohamed Quafafou. Building Web Information Extraction Tasks. Dans Proceedings of the 2004 IEEE/WIC/ACM International Conference on Web Intelligence, pages 349–355, Washington, Etats-Unis,
2004. IEEE Computer Society.
[HRC+ 04]
Thierry Hotelier, Ludovic Renault, Xavier Cousin, Vincent Negre, Pascale
Marchot, et Arnaud Chatonnet. ESTHER, the database of the alpha/betahydrolase fold superfamily of proteins. Nucleic Acids Research, 32(1) pages
145–147, 2004.
[HS03]
Joachim Hammer et Markus Schneider. Going Back to Our Database Roots
for Managing Genomic Data. OMICS, 7(1) pages 117–120, 2003.
[HSK+ 01]
Laura M. Haas, Peter M. Schwarz, Prasad Kodali, Elon Kotlar, Julia E.
Rice, et William C. Swope. DiscoveryLink : a system for integrated access
to life sciences data sources. IBM Systems Journal, 40(2) pages 489–511,
2001.
[Inm02]
William H. Inmon. Building the Data Warehouse, Third Edition. John Wiley
& Sons, Inc., New York, Etats-Unis, 2002.
[Int06]
RTI International.
The
http://www.gdb.org, 2006.
[Jam03]
D. Curtis Jamison. Open Bioinformatics. Bioinformatics, 19(6) pages 679–
680, 2003.
203
GDB
Human
Genome
Database.
[JMS96]
D. Curtis Jamison, Brad Mills, et Bruce Schatz. An extensible network
query unification system for biological databases. Computer Applications In
the Biosciences, 12(2) pages 145–150, 1996.
[JO03]
H. V. Jagadish et Frank Olken. Data Management for the Biosciences,
Report of the NSF/NLM Workshop on Data Management for Molecular
and Cell Biology. Rapport de recherche LBNL-52767, Lawrence Berkeley
National Laboratory, Novembre 2003.
[Jou00]
Fabrice Jouanot. Un modèle sémantique pour l’interopération de systèmes
d’information. Dans Actes du XVIIIème Congrès INFORSID, pages 347–
364, Lyon, France, 16–19 Mai 2000.
[Kap02]
Jean-Claude Kaplan. Genomics and medicine : hopes and challenges. Gene
Therapy, 9(11) pages 658–661, Juin 2002.
[KBC+ 96]
Gifford Keen, Jillian Burton, David Crowley, Emily Dickinson, Ada
Espinosa-Lujan, Ed Franks, Carol Harger, Mo Manning, Shelley March, Mia
McLeod, John O’Neill, Alicia Power, Maria Pumilia, Rhonda Reinert, David Rider, John Rohrlich, Jolene Schwertfeger, Linda Smyth, Nina Thayer,
Charles Troup, et Chris Fields. The Genome Sequence DataBase (GSDB) :
meeting the challenge of genomic sequencing. Nucleic Acids Research, 24(1)
pages 13–16, 1996.
[KBD+ 03]
Donna Karolchik, Robert Baertsch, Mark Diekhans, Terrence S. Furey, Angie
Hinrichs, Y. T. Lu, K. M. Roskin, M. Schwartz, C. W. Sugnet, D. J. Thomas,
R. J. Weber, D. Haussler, et W. J. Kent. The UCSC Genome Browser
Database. Nucleic Acids Research, 31(1) pages 51–54, Janvier 2003.
[KCD+ 03]
Howard Katz, Don Chamberlin, Denise Draper, Mary Fernández, Michael
Kay, Jonathan Robie, Michael Rys, Jérôme Siméon, Jim Tivy, et Philip Wadler. XQuery from the Experts : A Guide to the W3C XML Query Language.
Addison Wesley, Août 2003.
[KGKN02]
Minoru Kanehisa, Susumu Goto, Shuichi Kawashima, et Akihiro Nakaya.
The KEGG databases at GenomeNet. Nucleic Acids Research, 30(1) pages
42–46, Janvier 2002.
[Kim96]
Ralph Kimball. The Data Warehouse Toolkit : Practical Techniques for
Building Dimensional Data Warehouses. John Wiley, 1996.
[KK02]
Craig Knoblock et Subbarao Kambhampati. Information Integration on the
Web, AAAI Tutorial. Rapport de recherche DOC 95/11, Association for the
Advancement of Artificial Intelligence (AAAI), Juillet 2002.
204
[KLSS95]
Thomas Kirk, Alon Y. Levy, Yehoshua Sagiv, et Divesh Srivastava. The Information Manifold. Dans C. Knoblock et A. Levy, éditeurs, Working Notes
of the 4th Artifical Intelligence Spring Symposium on Information Gathering
from Heterogeneous, Distributed Environments, pages 85–91, Université de
Stanford, Californie, 1995.
[KNNV02]
Subbarao Kambhampati, Ullas Nambiar, Zaiqing Nie, et Sreelakshmi Vaddi.
Havasu : A Multi-Objective, Adaptive Query Processing Framework for Web
Data Integration. Rapport de recherche CSE TR-02-005, Arizona State
University, Avril 2002.
[KR06]
Toralf Kirsten et Erhard Rahm. BioFuice : Mapping-Based Data Integration in Bioinformatics. Dans Proceedings of the 3rd Database Integration in
the Life Sciences Workshop (DILS 2006), volume 4075 of Lecture Notes in
Computer Science, pages 124–135. Springer, 20–22 Juillet 2006.
[KS99]
Takao Kataoka et Kenji Satou. A Full-Text Search System Covering the
Whole GenomeNet. Dans Proceedings of the 10th Workshop on Genome Informatics (GIW ’99), volume 10, pages 308–309, Tokyo, Japon, 1999. Universal Academy Press.
[KT03]
Stefan Kuhlins et Ross Tredwell. Toolkits for Generating Wrappers. Dans
Revised Papers from the 3rd International Conference NetObjectDays on
Objects, Components, Architectures, Services, and Applications for a Networked World (NODe ’02), pages 184–198, Londres, Royaume-Uni, 2003.
Springer-Verlag.
[KWD97]
Nickolas Kushmerick, Daniel S. Weld, et Robert B. Doorenbos. Wrapper
Induction for Information Extraction. Dans Proceedings of the 15th International Joint Conference on Artificial Intelligence (IJCAI ’99), pages
729–737, Nagoya, Japon, 23–29 Août 1997.
[LA87]
Witold Litwin et Abdelaziz Abdellatif. An overview of the multi-database
manipulation language MDSL. Proceedings of the IEEE, 75 pages 621–632,
Mai 1987.
[Lac01]
Zoé Lacroix. Retrieving and Extracting Web Data with Search Views and an
XML engine. Dans Proceedings of the First International Data Integration
over the Web Workshop (DIWeb 2001), pages 76–90, Les Entrelacs, Suisse,
4 Juin 2001.
[Lac02]
Zoé Lacroix. Biological Data Integration : Wrapping Data and Tools. IEEE
Transactions on Information Technology in Biomedicine, 6(2) pages 123–
128, 2002.
205
[Lan89]
Rick F. Van Der Lans. The SQL standard : a complete guide reference.
Prentice Hall International Ltd., Hertfordshire, Royaume-Uni, 1989.
[LAZ+ 89]
Witold Litwin, Abdelaziz Abdellatif, Abdelmalek Zeroual, Bertrand Nicolas, et Philippe Vigier. MSQL : A Multidatabase Language. Information
Sciences, 49 pages 59–101, 1989.
[LBié]
Stanley Ian Letovsky et Mary B. Berlyn. Genera : A specification driven
Web/database gateway tool. 1994 (non publié).
[LBC+ 02]
Amey V. Laud, Sourav S. Bhowmick, Pedro Cruz, Dadabhai T. Singh, et
George Rajesh. The gRNA : A Highly Programmable Infrastructure for Prototyping, Developing and Deploying Genomics-Centric Applications. Dans
Proceedings of the 28th International Conference on Very Large Data Bases
(VLDB ’02), pages 928–939, Hong Kong, Chine, 20–23 Août 2002.
[LBGR99]
Mong Li Lee, Stéphane Bressan, Cheng Hian Goh, et Raghu Ramakrishnan.
Integration of Disparate Information Sources : A Short Survey. Dans Proceedings of the Workshop on Logic Programming and Distributed Knowledge
Management, Londres, Royaume-Uni, Avril 1999.
[LC00]
Chen Li et Edward Y. Chang. Query Planning with Limited Source Capabilities. Dans Proceedings of the 16th International Conference on Data
Engineering (ICDE 2000), pages 401–412, 2000.
[LC01]
Chen Li et Edward Y. Chang. On Answering Queries in the Presence of Limited Access Patterns. Dans Proceedings of the 8th International Conference
on Database Technology (ICDT 2001), pages 219–233, 2001.
[Lev00]
Alon Y. Levy. Logic-based techniques in data integration. pages 575–595,
2000.
[LGZ03]
Bing Liu, Robert Grossman, et Yanhong Zhai. Mining data records in Web
pages. Dans Proceedings of the 9th ACM SIGKDD International Conference
on Knowledge Discovery and Data mining (KDD ’03), pages 601–606, New
[LJ03]
Patrick Lambrix et Vaida Jakoniene. Towards transparent access to multiple
biological databanks. Dans Proceedings of t(e 1st Asia-Pacific Bioinformatics Conference 2003 (APBC ’03), pages 53–60, Darlinghurst, Australie,
2003. Australian Computer Society, Inc.
[LMMS+ 07] Brenton Louie, Peter Mork, Fernando Martin-Sanchez, Alon Halevy, et Peter Tarczy-Hornoch. Data integration and genomic medicine. Journal of
Biomedical Informatics, 40 pages 5–16, Février 2007.
206
[LMNR04]
Zoé Lacroix, Hyma Murthy, Felix Naumann, et Louiqa Raschid. Links and
paths through life sciences data sources. Dans Proceedings of the 1st Database Integration in the Life Sciences Forum (DILS 2004), pages 203–211,
25–26 Mars 2004.
[LMR90]
Witold Litwin, Leo Mark, et Nick Roussopoulos. Interoperability of Multiple
Autonomous Databases. ACM Computing Surveys, 22(3) pages 267–293,
1990.
[LMS95]
Alon Y. Levy, Alberto O. Mendelzon, et Yehoshua Sagiv. Answering queries
using views. Dans Proceedings of the 14th ACM Special Interest Group
on Algorithms and Computation Theory (SIGACT), Management Of Data
(SIGMOD) and Artificial Intelligence (SIGART) Symposium on Principles
of Database Systems (PODS ’95), pages 95–104, New York, Etats-Unis, 1995.
ACM Press.
[Loc06]
LocusLink.
Information
about
Genetic
http://www.ncbi.nlm.nih.gov/projects/LocusLink/, 2006.
[LP85]
David J. Lipman et William R. Pearson. Rapid and sensitive protein similarity searches. Science, 227(4693) pages 1435–1441, 1985.
[LP95]
Ling Liu et Carlton Pu. The DIOM Approach to Large-scale Interoperable
Database Systems. Rapport de recherche TR95-16, Department of Computing Science, University of Alberta, 1995.
[LPV+ 05]
Zoé Lacroix, Kaushal Parekh, Maria-Esther Vidal, Marelis Cardenas, et Natalia Marquez. Bionavigation : Selecting optimum paths through biological
resources to evaluate ontological navigational queries. Dans Proceedings of
the 2nd Database Integration in the Life Sciences Forum (DILS 2005), pages
275–283, 20–22 Juillet 2005.
[LRC02]
Phlippe Laublet, Chantal Reynaud, et Jean Charlet. Sur quelques aspects
du Web Sémantique. Dans Actes des Assises du GDR I3, Nancy, France,
2002. Editions Cépadues.
[LRO96a]
Alon Y. Levy, Anand Rajaraman, et Joann J. Ordille. Query-Answering
Algorithms for Information Agents. Dans Proceedings of the 13th National Conference on Artificial Intelligence (AAAI ’96) and the 8th Innovative
Applications of Artificial Intelligence Conference (IAAI’ 96), pages 40–47,
Menlo Park, Californie, Etats-Unis, 1996. AAAI Press / MIT Press.
[LRO96b]
Alon Y. Levy, Anand Rajaraman, et Joann J. Ordille. Querying Heterogeneous Information Sources Using Source Descriptions. Dans Proceedings of
207
Loci.
the 22nd International Conference on Very Large Data Bases (VLDB ’96),
pages 251–262, 1996.
[Mar96]
Philippe Martin. Exploitation de graphes conceptuels et de documents structurés et hypertextes pour l’acquisition de connaissances et la recherche d’informations. Thèse de doctorat, Université de Nice Sophia Antipolis, Nice,
France, 1996.
[MBA05]
David A. Maluf, David G. Bell, et Naveen Ashish. Lean middleware. Dans
Proceedings of the 2005 ACM SIGMOD international conference on Management of data (SIGMOD ’05), pages 788–791, New York, Etats-Unis, 2005.
ACM.
[MBG+ 07]
Joan M. Mazzarelli, John Brestelli, Regina K. Gorski, Junmin Liu, Elisabetta Manduchi, Deborah F. Pinney, Jonathan Schug, Peter White, Klaus H.
Kaestner, et Christian J. Stoeckert Jr. EPConDB : a web resource for gene
expression related to pancreatic development, beta-cell function and diabetes. Nucleic Acids Research, 35(suppl 1) pages 751–755, Janvier 2007.
[McL02]
Brett McLaughlin. Java & XML Data Binding. O’Reilly & Associates, Inc.,
2002.
[Med06]
MedLine. MedLine. http://www.ncbi.nlm.nih.gov, 2006.
[Mei03]
Wolfgang Meier. eXist : An Open Source Native XML Database. Dans Revised Papers from the NODe 2002 Web and Database-Related Workshops on
Web, Web-Services, and Database Systems, volume 2593 of Lecture Notes in
Computer Science, pages 169–183, Londres, Royaume-Uni, 2003. SpringerVerlag.
[MGD06]
MGD. Mouse Genome Database. http://www.informatics.jax.org/,
2006.
[MHTH01]
Peter Mork, Alon Halevy, et Peter Tarczy-Hornoch. A model for data integration systems of biomedical data applied to online genetic databases. Dans
Proceedings of the 25th American Medical Informatics Association Annual
Symposium (AMIA 2001), pages 473–477, Novembre 2001.
[Mit01]
Prasenjit Mitra. An algorithm for answering queries efficiently using views.
Dans Proceedings of the 12th Australasian database conference (ADC ’01),
pages 99–106, Washington, Etats-Unis, 2001. IEEE Computer Society.
[MLM+ 03]
Vamsi K. Mootha, Pierre Lepage, Kathleen Miller, Jakob Bunkenborg, Michael Reich, Majbrit Hjerrild, Terrye Delmonte, Amelie Villeneuve, Robert
Sladek, Fenghao Xu, Grant A. Mitchell, Charles Morin, Matthias Mann,
208
Thomas J. Hudson, Brian Robinson, John D. Rioux, et Eric S. Lander. Identification of a gene causing human cytochrome c oxidase deficiency by integrative genomics. Proceedings of the National Academy of Sciences, 100(2)
pages 605–610, 2003.
[MM97]
David May et Henk L. Müller. Icarus language definition. Rapport de recherche CSTR-97-007, Department of Computer Science, University of Bristol, Janvier 1997.
[MMD+ 05]
Zina Ben Miled, Malika Mahoui, Mindi Dippold, Ali Farooq, Nianhua Li, et
Omran Bukhres. A Wrapper Induction Application with Knowledge Base
Support : A Use Case for Initiation and Maintenance of Wrappers. Dans Proceedings of the 5th IEEE Symposium on Bioinformatics and Bioengineering
(BIBE ’05), pages 65–72, Washington, Etats-Unis, 2005. IEEE Computer
Society.
[MMK01]
Ion Muslea, Steven Minton, et Craig A. Knoblock. Hierarchical Wrapper
Induction for Semistructured Information Sources. Autonomous Agents and
Multi-Agent Systems, 4(1-2) pages 93–114, 2001.
[MN03]
Heiko Müller et Felix Naumann. Data Quality in Genome Databases. Dans
Proceedings of the 8th International Conference on Information Quality (IQ
2003), pages 269–284, Novembre 2003.
[Mor03]
Stephen Morris. Network Management, MIBs and MPLS : Principles, Design and Implementation. Prentice Hall Professional Technical Reference,
2003.
[MP03]
Peter McBrien et Alexandra Poulovassilis.
Data Integration by BiDirectional Schema Transformation Rules. Dans Proceedings of the 19th
International Conference on Data Engineering (ICDE 2003), pages 227–238,
2003.
[MR99]
Peter Mott et Stuart Roberts. A Formalism for Context Mediation Based on
Feature Logic. International Journal of Cooperative Information Systems,
8(4) pages 255–274, Décembre 1999.
[MRDV99]
Claudine Médigue, François Rechenmann, Antoine Danchin, et Alain Viari.
Imagene : an integrated computer environment for sequence annotation and
analysis. Bioinformatics, 15(1) pages 2–15, 1999.
[MSHTH02] Peter Mork, Ron Shaker, Alon Halevy, et Peter Tarczy-Hornoch. PQL : A
Declarative Query Language over Dynamic Biological Schemata. Dans Proceedings of the 26th American Medical Informatics Association Fall Symposium (AMIA 2002), pages 533–537, 2002.
209
[MSTH05]
Peter Mork, Ron Shaker, et Peter Tarczy-Hornoch. The Multiple Roles
of Ontologies in the BioMediator Data Integration System. Dans Bertram
Ludäscher et Louiqa Raschid, éditeurs, Proceedings of the 2nd Database Integration in the Life Sciences Workshop (DILS 2005), volume 3615 of Lecture
Notes in Computer Science, pages 96–104, San Diego, Californie, Juillet 20–
22 2005. Springer.
[Méd03]
Médience SA. Médience Server : Guide de l’utilisateur, Version 1.0. INRIA
et Médience SA, Décembre 2003.
[Nat06]
National Library of Medicine of United States.
PubMed
:
National
Library
of
Medicine’s
search
service.
http://www.ncbi.nlm.nih.gov/entrez/query.fcgi?db=PubMed, 2006.
[NCB]
NCBI.
Entrez,
The
Life
Sciences
Search
Engine.
http://www.ncbi.nlm.nih.gov/gquery/gquery.fcgi?itool=toolbar.
[NCB06a]
NCBI. FASTA format. http://www.ncbi.nlm.nih.gov/blast/fasta.shtml,
2006.
[NCB06b]
NCBI. GenBank. http://www.ncbi.nlm.nih.gov/Genbank/, 2006.
[NCB06c]
NCBI.
National
Center
for
http://www.ncbi.nlm.nih.gov/, 2006.
[NFKWié]
Zaiqing Nie, Jianchun Fan, Subbarao Kambhampati, et Garrett Wolf. BibFinder : A Computer Science Bibliography Mediator. 2007 (non publié).
[NKH03]
Zaiqing Nie, Subbarao Kambhampati, et Thomas Hernandez. BibFinder/StatMiner : Effectively Mining and Using Coverage and Overlap Statistics in
Data Integration. Dans Proceedings of the 29th International Conference
on Very Large Data Bases (VLDB ’03), pages 1097–1100, 9–12 Septembre
2003.
[NQC05]
Gilles Nachouki, Mohamed Quafafou, et Marie-Pierre Chastang. MDSManager : A System Based on Multidatasource Approach for Data Integration.
Dans Proceedings of the 4th Web Intelligence Conference (WI 2005), pages
438–441, Compiègne, France, 19–22 Septembre 2005.
[Odo05]
Odonata. XQuare Bridge and Fusion Documentation, Version 1.1.1. Objectweb Consortium, Septembre 2005.
[ODS04]
Ross Overbeek, Terry Disz, et Rick Stevens. The SEED : a peer-to-peer
environment for genome annotation. Communications of the ACM, 47(11)
pages 46–51, 2004.
210
Biotechnology
Information.
[OJ03]
Frank Olken et H. V. Jagadish. Data Management for Integrative Biology.
OMICS, 7(1) pages 1–2, 2003.
[OMG+ 02]
Claire O’Donovan, Maria Jesus Martin, Alexandre Gattiker, Elisabeth Gasteiger, Amos Bairoch, et Rolf Apweiler. High-quality protein knowledge
resource : SWISS-PROT and TrEMBL. Briefings in Bioinformatics, 3(3)
pages 275–284, 2002.
[OMI06]
OMIM.
Online
Mendelian
Inheritance
in
Man.
http://www.ncbi.nlm.nih.gov/entrez/query.fcgi?db=OMIM, 2006.
[Ope03]
OpenGIS.
Geographic
http://www.opengeospatial.org, 2003.
[PGMU96]
Yannis Papakonstantinou, Hector Garcia-Molina, et Jeffrey D. Ullman. Medmaker : A mediation system based on declarative specifications. Dans Stanley Y. W. Su, éditeur, Proceedings of the 12th International Conference on
Data Engineering, pages 132–141. IEEE Computer Society, 26 Février - 1er
Mars 1996.
[PH00]
Rachel Pottinger et Alon Y. Halevy. A Scalable Algorithm for Answering
Queries Using Views. Dans Proceedings of the 26th International Conference
on Very Large Data Bases (VLDB ’00), pages 484–495, Le Caire, Egypte,
10–14 Septembre 2000. Morgan Kaufmann.
[Proié]
JavaCC Project. JavaCC : Documentation Index. 2008 (non publié).
[PS96]
Christine Parent et Stefano Spaccapietra. Intégration de bases de données :
Panorama des problèmes et des approches. Ingénierie des Systèmes d’Information, 4(3) pages 45–61, 1996.
[RAT+ 98]
Pascal Rihet, Laurent Abel, Yves Traoré, Thérèse Traoré-Leroux, Christophe
Aucan, et Francis Fumoux. Human malaria : Segregation analysis of blood
infection levels in a suburban area and a rural area in Burkina Faso. Genetic
Epidemiology, 15(5) pages 435–450, 1998.
[RB01]
Erhard Rahm et Philip A. Bernstein. A survey of approaches to automatic
schema matching. The VLDB Journal, 10(4) pages 334–350, 2001.
[RBG+97]
A.L. Rector, Sean Bechhofer, Carole Goble, Ian Horrocks, W.A. Nowlan,
et W.D. Solomon. The GRAIL Concept Modelling Language for Medical
Terminology. Artificial Intelligence in Medicine, 9 pages 139–171, 1997.
Markup
Language.
[RCCPL98] Michael Rebhan, Vered Chalifa-Caspi, Jaime Prilusky, et Doron Lancet. GeneCards : a novel functional genomics compendium with automated data mining and query reformulation support. Bioinformatics, 14(8) pages 656–664,
1998.
211
[RDM04]
Erhard Rahm, Hong-Hai Do, et Sabine Mabmann. Matching large XML
schemas. SIGMOD Records, 33(4) pages 26–31, 2004.
[Ree01]
George Reese.
O’Reilly, 2001.
[Rog04]
Odile Rogier. Un outil pour la recherche de gènes candidats impliqués dans
le paludisme. Mémoire de Master, DEA BBSG, Faculté des Sciences de
Luminy, Marseille, 2004.
[Rou94]
William C. Rounds. Feature Logics. Dans Johan van Benthem et Alice ter
Meulen, éditeurs, Handbook of Logic and Language, pages 475–533. Elsevier
Science, Amsterdam, 1994.
[RS97]
Mary Tork Roth et Peter M. Schwarz. Don’t Scrap It, Wrap It ! A Wrapper
Architecture for Legacy Data Sources. Dans Matthias Jarke, Michael J.
Carey, Klaus R. Dittrich, Frederick H. Lochovsky, Pericles Loucopoulos, et
Manfred A. Jeusfeld, éditeurs, Proceedings of 23rd International Conference
on Very Large Data Bases (VLDB ’97), pages 266–275. Morgan Kaufmann,
25–29 Août 1997.
[RSC06]
RSCB. Protein Data Bank. http://www.rcsb.org/pdb/, 2006.
[RTA+ 98]
Pascal Rihet, Yves Traoré, Laurent Abel, Christophe Aucan, Thérèse TraoréLeroux, et Francis Fumoux. Malaria in Humans : Plasmodium falciparum
Blood Infection Levels Are Linked to Chromosome 5q31-q33. The American
Journal of Human Genetics, 63 pages 498–505, 1998.
[RTA+ 05]
Erhard Rahm, Andreas Thor, David Aumueller, Hong Hai Do, Nick Golovin, et Toralf Kirsten. iFuice - Information Fusion utilizing Instance Correspondences and Peer Mappings. Dans Proceedings of the 8th International
Workshop on the Web & Databases (WebDB 2005), pages 7–12, 16–17 Juin
2005.
[SA99]
Arnaud Sahuguet et Fabien Azavant. Building Light-Weight Wrappers for
Legacy Web Data-Sources Using W4F. Dans Proceedings of the 25th International Conference on Very Large Data Bases (VLDB ’99), pages 738–741,
San Francisco, Californie, Etats-Unis, 1999. Morgan Kaufmann Publishers
Inc.
[Sar02]
Sunita Sarawagi. Tutorial on Automation in Information Extraction and
Data Integration. Dans Proceedings of the 28th International Conference on
Very Large Data Bases (VLDB ’02), 20–23 Août 2002.
[Sax08]
Saxonica. SAXON - The XSLT and XQuery processor. 2008.
JDBC et Java - Guide du programmeur, 2ème édition.
212
[SBB+ 00]
Robert Stevens, Patricia Baker, Sean Bechhofer, Gary Ng, Alex Jacoby, Norman W. Paton, Carole A. Goble, et Andy Brass. Tambis : Transparent Access to Multiple Bioinformatics Information Sources. Bioinformatics, 16(2)
pages 184–185, 2000.
[SCB06]
Yacine Sam, François-Marie Colonna, et Omar Boucelma. CustomizableResources Description, Selection, and Composition : A Feature Logic Based
Approach. Dans Proceedings of the On the Move (OTM) Conferences :
Confederated International Conferences on Distributed Objects and Applications (DOA), Cooperative Information Systems (CoopIS) and Ontologies,
Databases and Applications of Semantics (ODBASE) 2006, Lecture Notes
in Computer Science, pages 377–390, Montpellier, France, Novembre 2006.
Springer-Verlag.
[SHNM05]
Matthew Scarpino, Stephen Holder, Stanford Ng, et Laurent Mihalkovic.
SWT/JFace in action. Manning Publications, 2005.
[SK98]
Steffen Schulze-Kremer. Ontologies for Molecular Biology. Dans Proceedings
of the 3rd Pacific Symposium on Biocomputing, pages 705–716, 1998.
[SL90]
Amit P. Sheth et James A. Larson. Federated database systems for managing
distributed, heterogeneous, and autonomous databases. ACM Computing
Survey, 22(3) pages 183–236, 1990.
[SM04]
Genoveva Vargas Solar et José Luis Zechinelli Martini. SPatial data Integration from Distributed and HEteRogeneous Sources (SPIDHERS). e-Gnosis,
Journal of Universidad de Guadalajara, 2 pages 1–6, 2004.
[SMGC04]
Carlo Sartiani, Paolo Manghi, Giorgio Ghelli, et Giovanni Conforti. XPeer :
A Self-Organizing XML P2P Database System. Dans Current Trends in
Database Technology - EDBT 2004 Workshops Revised Selected Papers, volume 3268 of Lecture Notes in Computer Science, pages 456–465, Heraklion,
Grèce, 14–18 Mars 2004. Springer.
[Smo92]
Gert Smolka. Feature-constrained logics for unification grammars. Journal
of Logic Programming, 12 pages 51–87, 1992.
[SPG05]
Yogesh L. Simmhan, Beth Plale, et Dennis Gannon. A Survey of Data
Provenance in e-Science. SIGMOD Records, 34(3) pages 31–36, Septembre
2005.
[SR04]
Jon Stephens et Chad Russell. Beginning MySQL Database Design and
Optimization. Springer-Verlag, New York Inc., 2004.
[SSK+ 86]
Lloyd Smith, Jane Sanders, Robert Kaiser, Peter Hugues, Chris Dodd,
Charles Connell, Cheryl Heiner, Stephen Kent, et Leroy Hood. Fluores213
cence detection in automated DNA sequence analysis. Nature, 321 pages
674–679, 1986.
[SSKK03]
Joshua M. Stuart, Eran Segal, Daphne Koller, et Stuart K. Kim. A Gene
Co-Expression Network for Global Discovery of Conserved Genetic Modules.
Science, 302(5643) pages 249–255, Octobre 2003.
[Ste02]
Lincoln Stein. Creating a bioinformatics nation. Nature, 417(6885) pages
119–120, Mai 2002.
[Ste03]
Lincoln D. Stein. Integrating Biological Databases. Nature Review Genetics,
4(5) pages 337–345, Mai 2003.
[STF+ 01]
Adam C. Siepel, Andrew N. Tolopko, Andrew D. Farmer, Peter A. Steadman, Faye D. Schilkey, Dawn Perry, et William D. Beavis. An integration
platform for heterogeneous bioinformatics software components. IBM Systems Journal, 40(2) pages 570–591, 2001.
[Suj01]
Walter Sujansky. Heterogenous Database Integration in Biomedecine. Methological Review, Journal of Biomedical Informatics, 34 pages 285–298,
2001.
[Swi06]
Swiss Institute for BioInformatics. Swiss-Prot : Protein KnowledgeBase.
http://us.expasy.org/sprot/, 2006.
[THH+ 06]
Tetsuro Toyoda, Naohiko Heida, Noriko Hashida, Norio Kobayashi, Hiroshi Masuya, Yoshiyuki Sakaki, Shigeharu Wakana, et Toshihiko Shiroishi.
PosMed : an inferential method connecting mouse resources and molecular
functions. Experimental Animals, 55(3), 2006.
[Tru03]
Wellcome Trust. Sharing Data from Large-scale Biological Research Projects : A System of Tripartite Responsibility. Rapport de recherche, Wellcome Trust Institute, Janvier 2003.
[Ull90]
Jeffrey D. Ullman. Principles of Database and Knowledge-Base Systems :
Volume II : The New Technologies. W. H. Freeman & Co., New York, EtatsUnis, 1990.
[VLL04]
Millist W. Vincent, Jixue Liu, et Chengfei Liu. Strong functional dependencies and their application to normal forms in xml. ACM Transactions on
Database Systems, 29(3) pages 445–462, Septembre 2004.
[VP02]
Vasilis Vassalos et Yannis Papakonstantinou. Expressive Capabilities Description Languages and Query Rewriting Algorithms. Journal of Logic Programming, 43(1) pages 75–122, Avril 2002.
214
[W3C07]
W3C. Xforms 1.1 - w3c working draft. http://www.w3.org/TR/xforms11/,
2007.
[Wal00]
Larry Wall. Programming Perl. O’Reilly & Associates, Inc., Sebastopol,
Californie, Etats-Unis, 2000.
[WBB+ 05]
David L. Wheeler, Tanya Barrett, Dennis A. Benson, Stephen H. Bryant,
Kathi Canese, Deanna M. Church, Michael DiCuccio, Ron Edgar, Scott Federhen, Wolfgang Helmberg, David L. Kenton, Oleg Khovayko, David J.
Lipman, Thomas L. Madden, Donna R. Maglott, James Ostell, Joan U. Pontius, Kim D. Pruitt, Gregory D. Schuler, Lynn M. Schriml, Edwin Sequeira,
Steven T. Sherry, Karl Sirotkin, Grigory Starchenko, Tugba O. Suzek, Roman Tatusov, Tatiana A. Tatusova, Lukas Wagner, et Eugene Yaschenko.
Database resources of the National Center for Biotechnology Information.
Nucleic Acids Research, 33 pages 39–45, 2005.
[WC53]
James D. Watson et Francis H. C. Crick. A Structure for Desoxyribose
Nucleic Acid. Nature, 171 pages 737–738, Avril 1953.
[Wie92]
Gio Wiederhold. Mediators in the Architecture of Future Information Systems. IEEE Computer, 25(3) pages 38–49, 1992.
[WL02a]
Erik Wilde et David Lowe. XPath, XLink, XPointer, and XML : A Practical
Guide to Web Hyperlinking and Transclusion. Pearson Education, 2002.
[WL02b]
Mark D. Wilkinson et Matthew Links. BioMOBY : An open source biological
web services proposal. Briefings in Bioinformatics, 3(4) pages 331–341, 2002.
[Won94]
Limsoon Wong. Querying Nested Collections. Thèse de doctorat, Department of Computer and Information Science, University of Pennsylvania, Philadelphie, Etats-Unis, 1994.
[WTS06]
WTSI. The Wellcome Trust Sanger Institute. http://www.sanger.ac.uk/,
2006.
[XE03]
Li Xu et David W. Embley. Discovering Direct and Indirect Matches for
Schema Elements. Dans Proceedings of the 8th International Conference on
Database Systems for Advanced Applications (DASFAA ’03), pages 39–46,
Kyoto, Japon, 26–28 Mars 2003. IEEE Computer Society.
[XE04]
Li Xu et David W. Embley. Combining the Best of Global-as-View and
Local-as-View for Data Integration. Dans Proceedings of the 3rd International Conference on Information Systems Technology and its Applications
(ISTA’2004), pages 123–136, Salt Lake City, Utah, Etats-Unis, 15–17 June
2004.
215
[XE06]
Li Xu et David W. Embley. A composite approach to automating direct
and indirect schema mappings. Information Systems, 31(8) pages 697–732,
2006.
[Xu03]
Li Xu. Source Discovery and Schema Mapping for Data Integration. Thèse
de doctorat, Brigham Young University, 2003.
[YLGMU99] Ramana Yerneni, Chen Li, Hector Garcia-Molina, et Jeffrey Ullman. Computing capabilities of mediators. Dans Proceedings of the 1999 ACM SIGMOD
International Conference on Management of Data (SIGMOD ’99), pages
443–454, New York, Etats-Unis, 1999. ACM Press.
[ZK95]
Andrea Zisman et Jeff Kramer. Towards interoperability in heterogeneous
database systems. Rapport de recherche DOC 95/11, Department of Computing, Imperial College of Science Technology and Medicine, 1995.
[ZLAE02]
Evgeni M. Zdobnov, Rodrigo Lopez, Rolf Apweiler, et Thure Etzold. The
EBI SRS server recent developments. Bioinformatics, 18(2) pages 368–373,
2002.
216
Index
accès limités, 12, 60
adaptateurs, 42, 46, 89
ADN, 5, 21
puces à, 103
agents, 41, 66
augmentation des volumes, 9
automatisation, 9
autonomie, 27
base de données, 6
BAV, 44, 120
BGLAV, 120, 125, 126, 132, 135, 140
cluster, 8
conflits, 22
sémantiques, 25
contexte, 25
cube de données, 35
curateurs, 10
dépendance d’inclusion, 139
entrepôt de données, 10, 32, 47
fédération de données, 40
fichiers
plats, 23
fichiers plats, 38
GAV, 43, 49, 118, 150
GLAV, 44, 66, 119
hétérogénéité
des données, 21
sémantique, 23, 51
syntaxique, 23
HTML, 48
hyperliens, 30
intégration
de données, 9, 11, 58
flexible, 11
forte, 31
fortement couplée, 30
horizontale, 31, 48
lâche, 31
multi-bases, 124
navigationnelle, 10, 32, 38
niveaux d’, 30
pair à pair, 45
sémantique, 31
syntaxique, 30
verticale, 32, 48
virtuelle, 10
intégrité référentielle, 64
intéropération, 8
internet, 5
interopérabilité, 6
jointure, 51, 67
calcul des chemins de, 81
chemin de, 79
LAV, 43, 49, 118, 150
liens hypertexte, 9, 62
Lixto, 48
logique des attributs, 67, 72, 73, 76
217
médiateur, 32, 42, 43, 47, 117
médiation, 10, 42, 58, 116
de contexte, 117, 121
de schéma, 117
méthodes d’intégration, 30
modèle
relationnel, 58
montée en charge, 8
multi-agents, 41
XML, 6, 48
clef d’un document, 142
XQuery, 49, 51, 126, 136
pattern d’accès, 67
portails, 39
qualité
de service, 28
des données, 26
réécriture de requêtes, 43, 126, 145
complexité de la, 156
références croisées, 38, 62, 65
restrictions d’accès, 27, 60, 140
séquençage, 5
séquence ADN, 133
scénario de collecte, 9
schéma
global, 10, 43
intégré, 67
métier, 11
schéma dérivé, 139
stockage, 6
taxonomie des conflits, 22
termes d’attributs, 74
format XML des, 88
unification de, 76
Web, 7, 125
workflows, 66
wrapper, 46, 89
218
Résumé
Depuis une vingtaine d’années, la masse de données générée par la génomique et la
biologie a cru de façon exponentielle. L’accumulation de ces informations, publiques ou
propriétés privées des laboratoires, a conduit à une hétérogénéité syntaxique et sémantique importante entre les sources que l’ouverture sur Internet a rendues accessibles au
plus grand nombre, mais qui sont incapables de communiquer entre elles : les formats
d’accès aux données, les schémas qui les modélisent, et les langages de requêtes varient
d’une base à une autre. Intégrer ces données distribuées et hétérogènes est donc devenu
un des champs principaux de recherche en bases de données, puisque l’écriture de requêtes
complexes, sur tout ou partie de ces bases, joue un rôle important, en médecine prédictive
par exemple. À partir des forces et des faiblesses des approches existantes, les travaux
présentés dans cette thèse se sont orientés autour de deux axes principaux, répondant
chacun de façon théorique - par une formalisation précise - et pratique - par le développement de prototypes illustratifs - à une classe de problèmes. Le premier axe de nos travaux
s’intéresse à la jointure de données de source en source, et automatise les extractions
manuelles habituellement destinées à recouper les données. Cette méthode est basée sur
une description des capacités des sources à l’aide de la logique des attributs. Le deuxième
axe de nos travaux s’articule autour du développement d’une architecture de médiation
BGLAV basée sur le modèle de données semi-structuré, dans le but d’intégrer les sources
de façon simple et flexible, tout en associant au système un langage de requêtes évolué et
évolutif, le langage XQuery.
Mots-clés: bases de données, BGLAV, biologie, logique des attributs, médiation, réécriture de requêtes, Web, XML, XQuery.
219
220
Abstract
Over the past twenty years, the volume of data generated by genomics and biology
has grown exponentially. Interoperation of publicly available or copyrighted datasources
is difficult due to syntactic and semantic heterogeneity between them. Thus, integrating
heterogeneous data is nowadays one of the most important field of research in databases,
especially in the biological domain, for example for predictive medicine purposes. The
work presented in this thesis is organised around two classes of integration problems. The
first part of our work deals with joining data sets across several datasources. This method
is based on a description of sources capabilities using feature logics. The second part of
our work is a contribution to the development of a BGLAV mediation architecture based
on semi-structured data, for an effortless and flexible data integration using the XQuery
language.
Keywords: databases, BGLAV, biology, feature logics, mediation, query rewriting, Web,
XML, XQuery.
221
222
223
RÉSUMÉ en français
Depuis une vingtaine d’années, la masse de données générée par la génomique et la biologie a cru de façon exponentielle. L’accumulation de ces informations, publiques ou propriétés privées des laboratoires, a conduit à une hétérogénéité
syntaxique et sémantique importante entre les sources que l’ouverture sur Internet a rendues accessibles au plus grand
nombre, mais incapables de communiquer entre elles : les formats d’accès aux données, les schémas qui les modélisent
varient d’une base à une autre. Intégrer ces données est donc devenu un des champs principaux de recherche en bases
de données, puisque l’écriture de requêtes complexes, sur tout ou partie de ces bases, joue un rôle important, en médecine prédictive par exemple. À partir des forces et des faiblesses des approches existantes, les travaux présentés dans
cette thèse se sont orientés autour de deux axes principaux, répondant chacun à une classe de problèmes. Le premier
axe de nos travaux s’intéresse à la jointure de données de source en source, qui automatise les extractions manuelles
habituellement destinées à recouper les données. Cette méthode est basée sur une description des capacités des sources
à l’aide de la logique des attributs. Le deuxième axe de nos travaux s’articule autour du développement d’une architecture
de médiation BGLAV basée sur le modèle de données semi-structuré, dans le but d’intégrer les sources de façon simple
et flexible, tout en associant au système un langage de requêtes évolué et évolutif, le langage XQuery.
TITRE en anglais
Integration of distributed and heterogeneous data on the Web and applications to biological datasources
RÉSUMÉ en anglais
Over the past twenty years, the volume of data generated by genomics and biology has grown exponentially. Interoperation
of publicly available or copyrighted datasources is difficult due to syntactic and semantic heterogeneity between them.
Thus, integrating heterogeneous data is nowadays one of the most important field of research in databases, especially in
the biological domain, for example for predictive medicine purposes. The work presented in this thesis is organised around
two classes of integration problems. The first part of our work deals with joining data sets across several datasources. This
method is based on a description of sources capabilities using feature logics. The second part of our work is a contribution
to the development of a BGLAV mediation architecture based on semi-structured data, for an effortless and flexible data
integration using the XQuery language.
DISCIPLINE
Informatique
MOTS-CLÉS
bases de données, BGLAV, biologie, logique des attributs, médiation, réécriture de requêtes, Web, XML, XQuery
INTITULÉ ET ADRESSE DU LABORATOIRE :
Laboratoire des Sciences de l’Information et des Systèmes - UMR CNRS 6168
Domaine Universitaire de Saint-Jérôme, Avenue Escadrille Normandie-Niemen, 13397 Marseille CEDEX 20

UNIVERSITÉ PAUL CÉZANNE AIX

Transcription

Documents pareils

Université Antilles–Guyane DEUG MIAS 1e année UFR Sciences

Chapitre 5 Intégration numérique

Primitives de P(x)e

S´EMINAIRE du GROUPE TH´EORIE Etude des états

Jonathan Jung

TD n°8 - Membres

RÉSOLUTION NUMÉRIQUE DE L`ÉQUATION DE LA CHALEUR Le

Proj` Courte

Ingénieur Java/J2EE

Université Antonine Année 2012-2013 Faculté de Gestion Mati`ere