Les entrepôts de données en bioinformatique

Instance versus schéma – Les correspondances peuvent être effectuées à partir des instances (le contenu des données) ou seulement à partir de l’information contenue au niveau du schéma.

Elément versus structure – Les correspondances peuvent être effectuées pour des éléments individuels du schéma ou pour des combinaisons d’éléments, comme des sous-structures complexes de schémas.

Langage versus contrainte – Les correspondances peuvent se baser sur des approches linguistiques (en utilisant les noms des éléments du schéma, par exemple égalité de nom, synonymie, etc …) ou sur des approches de contraintes (en utilisant les relations).

Correspondance de cardinalité – La correspondance peut être basée sur la relation d’un ou plusieurs éléments d’un schéma avec un ou plusieurs éléments de l’autre schéma, ceci menant à quatre cas : 1:1, 1:n, n:1, n:m.

Information auxiliaire – Un certain nombre d’algorithmes de correspondance ne reposent pas uniquement sur les schémas en entrée mais sur des informations auxiliaires, telles que les dictionnaires, les schémas globaux ou des correspondances déjà effectuées.

Il faut noter que certains algorithmes effectuent les correspondances en se basant sur un seul de ces critères, alors que certains combinent plusieurs critères.

La transformation de données lors de l’intégration – Le processus de transformation des données avant leur intégration dans un schéma global permet de réconcilier les contenus provenant de sources de données chevauchantes (intégration verticale) et/ou complémentaires (intégration horizontale) (voir section III.1.4). Ce processus permet de résoudre les nombreux problèmes de nomenclature des gènes et de réconcilier cette connaissance au sein d’un même schéma.

La modification des données par l’utilisateur – Les données étant disponibles localement, l’utilisateur peut filtrer, valider ou invalider, rectifier ou annoter les données provenant des sources. Ainsi, l’expertise de l’utilisateur peut être prise en compte.

Les possibilités d’analyse – Dans une approche de type entrepôt de données, on peut combiner deux types d’analyse, les analyses « avec a priori » correspondant à des requêtes bien définies par l’utilisateur, et des analyse « sans a priori » qui correspondent à du data mining. Ainsi, on dispose d’un environnement qui permet 1) de naviguer au sein de données diverses et réconciliées et 2) d’extraire de la connaissance à partir de données jusqu’alors non confrontées.

On constate que parmi les entrepôts de données développés en bioinformatique, et décrits dans la littérature, aucun n’emploie l’ensemble de ces avantages. Aussi, aucun système ne correspond pour l’heure à l’architecture entrepôt de données tel qu’on l’a définie précédemment, avec toutes ses possibilités et ses caractéristiques. On constate plutôt que selon le type de données intégrées et les besoins en analyse, seules quelques particularités de l’approche entrepôt de données sont employées. Nous allons illustrer notre commentaire sur quatre entrepôts de données décrits dans la littérature.

Ainsi, l’entrepôt de données GUS (Genomics Unified Schema) (Davidson et al., 2001) tire profit de l’élaboration d’un schéma global et d’une intégration sémantique forte pour fournir un environnement qui associe un gène à ses éventuels transcrits et protéines. L’entrepôt Atlas (Shah et al., 2005) se base également sur un modèle relationnel comportant plusieurs sous-modèles par catégorie de données intégrées. Les mêmes tables sont utilisées pour décrire des entités équivalentes mais provenant de sources différentes. Atlas réalise ainsi une intégration sémantique. Les entrepôts de données Columba (Trissl et al., 2005) et EnsMart (Kasprzyk et al., 2004) exploitent quant à eux la modélisation multidimensionnelle en se basant sur des schémas étoile, où les sources de données sont vues comme des dimensions de l’entrepôt.

Ces entrepôts de données sont décrits plus en détail dans les sections qui suivent.

2.2.2.1. GUS

GUS (Genomics Unified Schema) est un entrepôt de données qui intègre des données sur les séquences nucléiques et protéiques identifiées chez l’homme et la souris (Davidson et al., 2001). Ces données sont intégrées à partir des principales banques de données de séquences que sont GenBank/EMBL/DDBJ, dbEST et Swiss-Prot, et elles peuvent être modifiées et/ou annotées par l’utilisateur.

GUS est basé sur un modèle relationnel et le schéma de données utilise le dogme biologique (ADN D ARN D Protéine) pour sa représentation. Ainsi, les tables de GUS gèrent les annotations sur les gènes, sur les ARNs dérivés de ces gènes et enfin sur les protéines dérivées de ces ARNs.

Dans GUS, on attache beaucoup d’importance à la provenance des données ainsi qu’à l’historique des annotations intégrées au fur et à mesure de la construction de l’entrepôt. Ceci permet d’archiver l’histoire d’une annotation et d’appréhender la qualité de celle-ci selon si elle a été obtenue par des méthodes prédictives ou bien par expérimentation. Le schéma de GUS comporte donc des tables spécialement dédiées pour le stockage de la provenance et de l’historique des données. Elles viennent s’ajouter aux tables servant à représenter les sources de données. Avec un total de 180 tables, le schéma de GUS est très dense, aussi, une couche objet a été ajoutée au dessus de l’implémentation relationnelle pour une meilleure manipulation des entités biologiques intégrées.

Les mises à jour dans GUS s’effectuent tous les deux ou trois mois. Toutes les sources sont analysées pour détecter les nouvelles entrées, les entrées modifiées ou intactes.

GUS peut être interrogé via le Web⁵⁸.

2.2.2.2. Atlas

Atlas est un entrepôt de données biologique qui intègre des données sur les séquences, les interactions moléculaires, les informations sur l’homologie, les annotations fonctionnelles de gènes, et des ontologies biologiques (Shah et al., 2005).

La particularité d’Atlas est de catégoriser les sources de données intégrées en quatre types de données que sont ‘séquence’, ‘interactions moléculaires’, ‘ressources génomiques’ et

‘ontologies’, et d’associer à chaque catégorie un modèle relationnel. Un seul modèle relationnel est par exemple utilisé pour décrire les données provenant des sources GenBank, RefSeq et UniProt, associées à la catégorie ‘séquence’.

Ensuite, les données sont interrogées par des APIs qui encapsulent le langage de requête SQL pour un accès plus fin aux données. Une ontologie spécifique à Atlas est utilisée pour cross-référencer les types biologiques intégrés, qui ne sont pas toujours reliés dans les sources.

Des outils reposant sur les APIs développées sont disponibles. Ils permettent soit d’effectuer des interrogations simples sur des types de données spécifiques, soit d’effectuer des requêtes plus complexes qui infèrent des interactions moléculaires.

Atlas est disponible sur le site Web de UBiC⁵⁹ (UBC (University of British Columbia) Bionformatics Center). L’application peut être téléchargée, elle est distribuée sous une licence publique GNU* (GNU’s Not UNIX).

58 http://www.allgenes.org/

59 http://bioinformatics.ubc.ca/atlas/

2.2.2.3. Columba

Columba est un entrepôt d’annotations sur les structures protéiques (Trissl et al., 2005). Il intègre les entrées provenant de PDB ainsi que les annotations provenant de diverses sources de données développées autour des protéines. Parmi les sources intégrées, citons KEGG pour les informations sur les réseaux métaboliques, ENZYME⁶⁰ (Bairoch, 2000) pour la nomenclature des enzymes, SCOP⁶¹ (Reedy and Bourne, 2003) et CATH⁶² (Pearl et al., 2003) pour les informations de repliement des protéines, Swiss-Prot et GO pour les annotations fonctionnelles et NCBI Taxonomy⁶³ pour les informations taxonomiques. Ainsi, Columba fournit une information plus riche que PDB.

Le schéma de Columba repose sur un modèle relationnel. Il s’agit d’un schéma en étoile où l’entrée de la source PDB est au centre et où chaque source qui renseigne la protéine représente une dimension. Chaque dimension se spécialise via un sous-schéma (figure 24).

Figure 24 – Schéma étoile de Columba (extrait de (Trissl et al., 2005))

La partie grise foncée du milieu correspond à un schéma de la source PDB. Les autres sous-schémas ou dimensions, sont représentés par des boîtes blanches indiquant le nom de la source de données et sont regroupés par type de contenu.

De cette manière les données de sources différentes ne sont jamais représentées dans une même table, il n’y a donc pas d’intégration sémantique forte, telle que décrite dans la section III.1.4.

60 http://www.expasy.org/enzyme/

61 http://scop.mrc-lmb.cam.ac.uk/scop/

62

Au contraire, dans le schéma de Columba, les redondances existent. Par exemple, on intègre dans Columba l’annotation fonctionnelle provenant de GO et celle provenant des mots clés de Swiss-Prot. Les concepteurs de Columba considèrent que les redondances ne sont pas des informations dupliquées mais plutôt des données complémentaires intéressantes puisque obtenues par différentes personnes et/ou dans différentes expériences. Il n’y a donc pas de discrimination à faire. De plus, ils estiment que les utilisateurs ont leur préférence en termes de choix des sources à interroger.

L’entrepôt de données Columba est accessible via le Web⁶⁴. Des requêtes peuvent être formulées soit à l’aide de mots clés et d’opérateurs de type AND, OR et NOT, soit par le biais de formulaires permettant de guider l’utilisateur dans sa formulation. De cette manière, l’utilisateur peut affiner sa requête pas à pas et ainsi obtenir des ensembles de structures protéiques qui partagent certaines propriétés.

2.2.2.4. EnsMart

EnsMart est un entrepôt de données qui conceptuellement suit la même approche que Columba. Il intègre des données génomiques multi-espèces, provenant des banques de Ensembl (Kasprzyk et al., 2004). Le système est basé sur un schéma en étoile, où le gène est placé au centre et où il est relié à différentes dimensions qui représentent les sources de données intégrées. Ainsi, le gène est relié à sa position génomique, ses facteurs de transcription et ses données d’expression.

EnsMart est accessible via le Web⁶⁵. L’utilisateur compose ses requêtes via des formulaires qui permettent de définir un ensemble de données à interroger, ainsi que des filtres à appliquer.

3. DISCUSSION SUR LES APPROCHES D’INTÉGRATION EN