III. LES APPROCHES D’INTÉGRATION EN BIOINFORMATIQUE
2. LES APPROCHES EN BIOINFORMATIQUE
2.2. L’approche matérialisée : entrepôt de données
2.2.1. Principe de l’approche entrepôt de données
L’entrepôt de données (data warehouse) est un système d’information particulier, qualifié de décisionnel, permettant à ses utilisateurs de disposer d’informations pertinentes et d’outils d’analyse puissants pour faciliter la prise de décision. Le concept d’entrepôt est né dans l’entreprise et plus spécifiquement dans les secteurs du commerce et du marketing où pour faire face à la concurrence, l’informatique décisionnelle s’est développée. Aujourd’hui, l’utilisation de l’entrepôt de données s’est répandue dans divers domaines tels que, entre autre, la biologie et la géographie.
2.2.1.1. Système d’information transactionnel versus décisionnel
L’entrepôt de données est différent des systèmes d’informations classiques qualifiés de Systèmes d’Information transactionnel, car les besoins pour lesquels on veut le construire sont différents (Franco, 1997).
Les systèmes d’information transactionnels sont communément appelés OLTP* (On Line Transactionnel Processing) pour indiquer qu’ils servent à traiter des processus transactionnels en ligne. Ces systèmes sont caractérisés par un nombre d’utilisateurs important, des interrogations et des modifications fréquentes, et des volumes de données par transaction relativement faibles. Dans ce cadre, le modèle de données est destiné à minimiser les redondances pour préserver la fiabilité et la cohérence du système. De cette manière le système garantit une réduction des temps d’exécution et facilite les procédures d’ajout, de suppression et de modification.
À l'inverse, les entrepôts de données sont dédiés à la prise de décision. Ils sont qualifiés de OLAP* (On Line Analytical Processing) car l’exploitation des informations contenues dans ces systèmes est réalisée par des processus d’analyse en ligne des données (Codd, 1993). Ces systèmes sont utilisés par un nombre restreint d’utilisateurs et privilégient le fait de pouvoir poser une grande variété de requêtes de manière interactive et plus rapide qu’en OLTP sur de grands volumes de données. Ces requêtes peuvent être simples, ou au contraire plus complexes, permettant ainsi de mettre en relation des éléments qui a priori ne sont pas corrélés au départ. Il faut donc une organisation qui permet de mémoriser de grands jeux de données et qui facilite la recherche de connaissance. Ainsi, l’entrepôt de données est entièrement construit selon une approche dimensionnelle. De plus, l’information qu’il contient est mise à jour par des sources de données externes lors de procédures de chargement.
Aussi, le modèle de données doit assurer l’intégrité* des données lors de l’intégration. Ceci implique une cohérence du schéma global de l’entrepôt et une alimentation réfléchie et planifiée dans le temps.
2.2.1.2. La définition d’entrepôt
Inmon, précurseur du concept de l’entrepôt de données, fournit la définition suivante (Inmon, 2002) : « Le data warehouse est une collection de données orientées sujet, intégrées, non volatiles, historisées et disponibles pour le support d’un processus d’aide à la décision. » Orientation sujet – Les données d’un entrepôt s’organisent par sujets ou thèmes. L’intérêt de ce type d’organisation est de disposer de l’ensemble des informations sur un sujet, et de développer des analyses décisionnelles via une approche incrémentale sujet après sujet.
L’intégration des différents sujets dans une structure unique est nécessaire car les informations communes à plusieurs sujets ne doivent pas être dupliquées. Dans la pratique, ce sont les datamarts* qui supportent l’orientation sujet, ils représentent physiquement des sous-ensembles de l’entrepôt de données.
Données intégrées – Les données d’un entrepôt sont le résultat de l’intégration de données en provenance de multiples sources. L’intégration implique une mise en forme et une unification des données afin d’avoir un état de cohérence.
Données historisées – Dans une base de données, la donnée est mise à jour à chaque nouvelle transaction. Dans un entrepôt de données, l’historique de la valeur des données est conservé. Un référentiel de temps doit alors être associé aux données afin d’identifier les valeurs particulières dans le temps.
Données non volatiles – La non volatilité est la conséquence de l’historisation décrite précédemment. Une requête lancée à différentes dates, en précisant la date de référence de l’information recherchée, donnera le même résultat. Les données sont non volatiles, elles ne disparaissent pas après les mises à jour.
Données disponibles pour le support d’un processus d’aide à la décision – Des outils d’analyse et d’interrogation doivent permettre aux utilisateurs de consulter facilement les données.
Une schématisation de l’architecture d’un entrepôt de données est représentée figure 16.
Figure 16 – Architecture d’un entrepôt de données
La zone de préparation des données représente un ensemble de processus chargés d’extraire les données de la zone source, de les transformer, de les charger et de les stocker dans l’entrepôt. La zone de présentation des données est chargée de répondre aux requêtes émises par les utilisateurs. Elle offre donc des services d’interrogation contrairement à la zone de préparation. C’est au niveau de la zone de présentation que se situent les datamarts, alimentés depuis la zone de préparation et interrogés par les outils d’analyse de types OLAP, fouille de données, communément appelée data mining et visualisation de la zone de restitution.
Extraction Transformation Chargement
Alimentation
Zone source Zone de préparation Zone de présentation Zone de restitution
Sources de données
Briques de
données Datamarts Outils d’analyse
(OLAP, data mining et visualisation) Analyse
Les données d’un entrepôt se structurent selon deux axes : synthétique et historique (figure 17).
Figure 17 - Architecture des données dans un entrepôt
L’axe synthétique établit une hiérarchie d’agrégation. Il comprend les données détaillées (qui représentent les évènements les plus récents au bas de la hiérarchie), les données agrégées (qui synthétisent les données détaillées) et les données fortement agrégées (qui synthétisent à un niveau supérieur les données agrégées). L’axe historique comprend les données détaillées historisées, qui représentent des évènements passés. Les méta-données contiennent des informations concernant les données de l’entrepôt telles que leur provenance et leur structure, ainsi que les méthodes pour réaliser l’agrégation.
2.2.1.3. La modélisation de l’entrepôt de données
La conception d’un entrepôt de données est très différente de celle des bases de données transactionnelles, puisque les besoins en termes d’analyses sont différents. Un entrepôt de données repose sur un modèle multidimensionnel de données.
(1) Le modèle multidimensionnel de données
Le modèle multidimensionnel de données est adapté aux besoins de l’analyse des données d’un entrepôt. Ce modèle permet d’observer des données selon plusieurs perspectives ou axes d’analyses. Ainsi, l’accès aux données par les utilisateurs est intuitif et l’interrogation plus facile.
Le constructeur fondamental du modèle multidimensionnel est le cube de données. Un cube organise les données en plusieurs dimensions* qui déterminent une mesure d’intérêt appelée fait*. Une dimension spécifie la manière dont on regarde les données pour les analyser alors qu’un fait est un objet d’analyse. Chaque dimension est formée par un ensemble d’attributs et chaque attribut peut prendre différentes valeurs.
Données fortement agrégées
Données agrégées
Données détaillées
Données détaillées historisées
z z
Niveau de synthèse
Niveau d’historique
Métadonnées
Les dimensions possèdent en général des hiérarchies associées qui organisent les attributs à différents niveaux pour observer les données selon différentes granularités. Une dimension peut avoir plusieurs hiérarchies associées, chacune spécifiant différentes relations d’ordre entre ses attributs. Un exemple de cube de données est représenté figure 18.
Figure 18 - Exemple de cube de données
Dans ce cube, la mesure d’intérêt est la Quantité de Protéine produite dans un Organe à un Temps donné. Le cube présente alors trois dimensions : Protéine, Organe et Temps. La mesure ou fait est la Quantité de protéine.
(2) Les schémas de données
Le modèle multidimensionnel décrit précédemment est implanté directement par des systèmes appelés SGBD* (Systèmes de Gestion de Bases de Données) pouvant être de différents types, ils sont décrits dans la section suivante (section III.2.2.1.4).
Différents schémas peuvent être utilisés pour la représentation des données au sein de ces SGBD. Ces schémas sont constitués du fait central et des dimensions. On distingue les modèles en étoile, en flocon et en constellation (figure 19).
Modélisation en étoile – Une table centrale réunit tous les faits qui partagent le même ensemble de dimensions, on parle de table de faits. Autour de cette table figurent tous les éléments caractérisant les dimensions d’analyse. Ces caractéristiques sont regroupées dans des tables de dimensions. Le modèle en étoile part du principe que ce sont principalement les analyses des faits qui intéresseront l’utilisateur.
Modélisation en flocon – Le flocon est simplement une étoile dont les branches sont elles-mêmes décomposées en sous-hiérarchies. Modéliser en flocon c’est donc conserver le cœur de l’étoile et affiner la modélisation des tables de dimensions pour les éclater en sous-tables.
Modélisation en constellation – Ce type de modélisation fusionne plusieurs modèles en étoile qui utilisent des dimensions communes. Un modèle en constellation comprend donc plusieurs faits et des dimensions communes.
Temps H12 H0
H24 FoieCerveau
Rate Organe CyclineA
CyclineB CyclineD1 Protéine
Quantité
Figure 19 - Les différents schémas pour la représentation de données multidimensionnelles
Fait 1 Mesure 1 Mesure 2
Dimension A Attribut 1 Attribut 2
Dimension 1 Attribut 1 Attribut 2
Dimension 2 Attribut 1 Attribut 2
Dimension B Attribut 1 Attribut 2
Fait 2 Mesure 1 Mesure 2
Dimension 2 Attribut 1 Attribut 2
Dimension 2 Attribut 1 Attribut 2 Fait 1
Mesure 1 Mesure 2
Dimension A Attribut 1 Attribut 2 Dimension A
Attribut 1 Attribut 2
Dimension 1 Attribut 1 Attribut 2 Dimension 1
Attribut 1 Attribut 2
Dimension 2 Attribut 1 Attribut 2 Dimension 2
Attribut 1 Attribut 2
Dimension B Attribut 1 Attribut 2 Dimension B
Attribut 1 Attribut 2
Fait 2 Mesure 1 Mesure 2
Dimension 2 Attribut 1 Attribut 2 Dimension 2
Attribut 1 Attribut 2
Dimension 2 Attribut 1 Attribut 2 Dimension 2
Attribut 1 Attribut 2
Modèle en constellation Fait
Mesure 1 Mesure 2 Dimension 2
Attribut 1 Attribut 2
Dimension 1 Attribut 1 Attribut 2
Dimension 4 Attribut 1 Attribut 2
Dimension 3 Attribut 1 Attribut 2 Fait
Mesure 1 Mesure 2 Dimension 2
Attribut 1 Attribut 2 Dimension 2
Attribut 1 Attribut 2
Dimension 1 Attribut 1 Attribut 2 Dimension 1
Attribut 1 Attribut 2
Dimension 4 Attribut 1 Attribut 2 Dimension 4
Attribut 1 Attribut 2
Dimension 3 Attribut 1 Attribut 2 Dimension 3
Attribut 1 Attribut 2
Fait Mesure 1 Mesure 2 Dimension 2
Attribut 1 Attribut 2
Dimension 1 Attribut 1 Attribut 2
Dimension 4 Attribut 1 Attribut 2
Dimension 3 Attribut 1 Attribut 2
Sous-type Attribut 1 Attribut 2
Type Attribut 1 Attribut 2
Sous-Cat Attribut 1 Attribut 2
Ss-ss-Cat Attribut 1 Attribut 2 Catégorie Attribut 1 Attribut 2
Fait Mesure 1 Mesure 2 Dimension 2
Attribut 1 Attribut 2 Dimension 2
Attribut 1 Attribut 2
Dimension 1 Attribut 1 Attribut 2 Dimension 1
Attribut 1 Attribut 2
Dimension 4 Attribut 1 Attribut 2 Dimension 4
Attribut 1 Attribut 2
Dimension 3 Attribut 1 Attribut 2 Dimension 3
Attribut 1 Attribut 2
Sous-type Attribut 1 Attribut 2 Sous-type Attribut 1 Attribut 2
Type Attribut 1 Attribut 2
Type Attribut 1 Attribut 2
Sous-Cat Attribut 1 Attribut 2
Ss-ss-Cat Attribut 1 Attribut 2 Ss-ss-Cat Attribut 1 Attribut 2 Catégorie Attribut 1 Attribut 2 Catégorie Attribut 1 Attribut 2
Modèle en étoile
Modèle en flocon
2.2.1.4. Stockage et gestion
Les systèmes OLAP sont souvent classés par rapport au SGBD utilisé pour le stockage et la gestion des données.
Les systèmes MOLAP (Multidimensionnal On Line Analytical Processing) – Ils utilisent un SGBDM (SGBD Multidimensionnel) qui gère de manière native les structures dimensionnelles. Ces systèmes présentent un temps de réponse faible aux calculs puisqu’ils effectuent la pré-agrégation et le pré-calcul des données.
Les systèmes ROLAP (Relational On Line Analytical Processing) – Ils utilisent un SGBDR (SGBD Relationnel). Dans ce cas, chaque fait correspond à une table et chaque dimension correspond à une table. Ces systèmes peuvent stocker de grands volumes de données mais peuvent présenter un temps de réponse élevé.
Les systèmes HOLAP (Hybrid On Line Analytical Processing) – Ils constituent des systèmes hybrides ROLAP MOLAP. Dans ce cas, les données agrégées sont stockées dans un SGBDM et les données détaillées sont stockées dans un SGBDR. Ainsi, il est possible de gérer une grande quantité de données, et en même temps d’avoir un temps de réponse acceptable.
Les systèmes OOLAP (Object On Line Analytical Processing) – Ils utilisent un SGBDO (SGDBD orienté Objet). Un fait devient une classe de fait et une dimension devient une classe de dimension. L’intérêt de l’approche OOLAP par rapport à ROLAP est sa plus grande richesse de modélisation.
2.2.1.5. Analyse des données dans l’entrepôt (1) Analyse multidimensionnelle
Les données dimensionnelles sont visualisées sous la forme d’un cube, qui représente un schéma en étoile comportant trois dimensions (les trois dimensions du cube) et l’intersection dans l’espace de ces axes constitue la mesure analysée. Bien sûr, lorsque le schéma comporte plus de trois dimensions, il faut dessiner une forme à n dimensions, n étant le nombre de dimensions du schéma en étoile considéré.
Ensuite, différentes opérations permettent de manipuler les données multidimensionnelles. Ce sont les outils OLAP qui implantent ces opérations. On distingue les opérations classiques (sélection, projection, produit cartésien, …), les opérations agissant sur la structure multidimensionnelle (rotation, extraction) et les opérations agissant sur la granularité (forage).
OPÉRATIONS AGISSANT SUR LA STRUCTURE
Les opérations agissant sur la structure multidimensionnelle visent à changer le point de vue des données observées.
Parmi les opérations les plus courantes, la rotation et l’extraction.
La rotation (slice) – Elle consiste à effectuer une rotation du cube, de manière à représenter une face différente. La rotation est illustrée figure 20 ci-dessous.
Figure 20 – La rotation
L’extraction (dice) – Elle consiste à extraire une sous partie du cube de données, il en résulte un sous-cube. L’extraction est illustrée figure 21 ci-dessous.
Figure 21 – L’extraction
OPÉRATIONS AGISSANT SUR LA GRANULARITÉ
Le forage vers le haut (ou roll-up) – Il consiste à représenter les données du cube à un niveau de granularité supérieur conformément à la hiérarchie définie sur la dimension. Une fonction d’agrégation* (somme, moyenne, …) spécifiée pour la mesure et la dimension indique comment sont calculées les valeurs du niveau supérieur à partir de celles du niveau inférieur.
Le forage vers le bas (ou drill-down) – Il consiste à représenter les données du cube à un niveau de granularité inférieur, donc sous une forme plus détaillée.
CyclineA CyclineB CyclineD1 Protéine
Temps H12 H0
H24
Foie Cerveau Rate Organe
Quantité
CyclineA CyclineB CyclineD1 Protéine
Temps H12
H0 H24 Foie
Cerveau Rate Organe
Quantité Slice
CyclineA CyclineB CyclineD1 Protéine
Temps H12
H0 H24
Foie Cerveau Rate Organe
Quantité
CyclineA CyclineD1 Protéine
Temps H0
H24
Foie Rate Organe
Quantité Dice
La figure 22 illustre un exemple de forage.
Figure 22 – Application des opérations roll-up et drill-down sur la dimension Protéine
(2) Data Mining
Le terme de data mining est souvent employé de manière abusive pour désigner des outils permettant d’analyser des données volumineuses. En réalité, le terme de data mining doit être attribué à un certain type d’analyse qui permet la recherche de connaissance cachée dans les données, sous forme de modèles de comportement.
Contrairement aux outils OLAP, où l’utilisateur choisit les éléments qu’il veut observer ou analyser, dans le cas du data mining, le système a l’initiative et découvre lui-même les associations entre données, sans intervention de l’utilisateur. Il est alors possible de prédire des évènements ou comportements, et de détecter des données inusuelles, exceptionnelles.
Plusieurs techniques de data mining ont été utilisées dans des outils statistiques spécialisés pour l’analyse de quantités réduites de données, elles ont évolué pour s’intégrer avec les entrepôts de données. Ainsi, le succès de l’entrepôt de données a dynamisé l’offre de data mining.
D’un côté les techniques de data mining sont plus performantes lorsqu’elles sont utilisées pour analyser les données d’un entrepôt, parce que les données de qualité qu’il intègre évitent que l’outil passe du temps à faire des tâches préalables, tel que le nettoyage de données. De l’autre côté, la capacité d’analyse unique que ces outils fournissent aux utilisateurs de l’entrepôt provoque une augmentation de sa valeur stratégique.
2.2.1.6. Construction d’un entrepôt de données
D’après Inmon, « L’entrepôt de données n’est pas un produit ou un logiciel mais un environnement. Il ne s’achète pas, il se bâtit. » (Inmon, 2002).
La construction d’un entrepôt de données se déroule en plusieurs étapes, et comprend la définition des besoins, la conception du modèle de données, et enfin l’intégration des données.
CyclineA CyclineB
CyclineD1
Cyclines
Protéines du cycle cellulaire
Drill-down Roll-up
(1) La définition des besoins
Cette étape est préalable à l’implantation de tout nouveau système d’information. L’étude des besoins doit déterminer le contenu de l’entrepôt et son organisation, ainsi que les requêtes que les utilisateurs formuleront. Cette étape est réalisée par le biais d’interviews auprès des futurs utilisateurs du système.
Les interviews permettent de recenser les données à étudier et dans quelles dimensions. Il faut ensuite identifier les sources requises pour l’intégration de ces données.
La variété des besoins peut entraîner un découpage de l’entrepôt en plusieurs parties que sont les datamarts.
(2) La conception du modèle de données
L’ambition de l’entrepôt de données est de fédérer un ensemble de données provenant de sources variées, via un modèle global. La pertinence du système en termes de réponses aux requêtes repose alors entièrement sur la pertinence de ce modèle global.
Pour réaliser ce modèle global, il faut agréger les données provenant des différentes sources.
Ainsi, des efforts sont à fournir pour :
Respecter la fiabilité de l’information.
Respecter la cohérence des informations, une même donnée pouvant provenir de deux sources différentes, il faut alors choisir la plus judicieuse.
Assurer la consolidation des informations, c'est-à-dire définir de manière unique une donnée.
Unifier la représentation des données.
Vérifier la non-redondance des informations.
(3) L’intégration des données
L’intégration est la procédure qui permet de transférer les données des sources externes vers l’entrepôt de données, en les adaptant. Elle est divisée en quatre étapes qui sont : 1) l’extraction des données des sources, 2) la transformation des données aux niveaux structurel et sémantique, 3) l’intégration des données et enfin 4) le stockage des données intégrées dans le système cible.
Il faut noter que cette décomposition est seulement logique. L’étape d’extraction et une partie de l’étape de transformation peuvent être groupées dans le même composant logiciel, tel qu’un adaptateur (wrapper) ou un outil de migration de données. L’étape d’intégration est souvent couplée avec des possibilités de transformation de données dans un même composant logiciel, qui, habituellement, réalise le chargement dans l’entrepôt de données.
Toutes les étapes de traitement peuvent aussi être groupées dans un même logiciel. Quand les étapes d’extraction et d’intégration sont séparées, les données nécessitent d’être stockées entre les deux. Ceci peut être fait en utilisant un média par source ou un média pour toutes les sources.
Une vue opérationnelle typique de ces composants est donnée par la figure 23.
Figure 23 – Vue opérationnelle des composants utilisés pour la construction d’entrepôts de données
Les composants logiciels sont représentés par des rectangles. Les ellipses désignent des stockages intermédiaires des résultats de l’étape d’extraction/transformation. Toutes les données qui sont en entrée du composant intégration utilisent le même modèle de représentation de données. Finalement, un « wrapper » est associé à chaque source, fournissant ainsi une interface API à la source.
L’un des principaux problèmes posés par l’intégration des données consiste à effectuer la transformation des données du format des sources vers le format de l’entrepôt de données.
Ce processus de transformation requiert la mise en correspondance structurelle et sémantique entre le schéma des sources de données et le schéma global de l’entrepôt de données (Bernstein and Rahm, 2000). Il s’agit de la correspondance inter-schémas ou appariement de schémas (schema matching).
Il existe différentes approches de correspondance inter-schémas. Elles dépendent du type d’information du schéma qui est utilisé et comment cette information est interprétée (Rahm and Bernstein, 2001). Commençons par rappeler les définitions de schéma et de correspondance inter-schémas.
Un schéma est un ensemble d’éléments connectés par une certaine structure. En pratique, il existe différentes représentations, qui sont le modèle relationnel, le modèle orienté objet ou le XML. Dans chacune des représentations, on distingue des éléments et des structures : les entités et les relations dans le modèle relationnel, les objets et les relations dans le modèle orienté objet et les éléments et les sous-éléments dans le XML.
Etant donné un schéma global G et une source de données dont le schéma est noté S, la correspondance inter-schémas consiste à identifier les éléments des deux schémas (S et G) qui se correspondent, et comment ces éléments sont reliés. On distingue différents types de relations entre les éléments de deux schémas. Ils peuvent être directionnels (un élément de S correspond à un élément de G) ou non directionnels (une combinaison d’éléments de S et G se correspondent). Il peut s’agir de relations par le biais d’opérateurs (= ; > …) ou de fonctions (addition, concaténation). Il peut s’agir de relations d’ensembles (chevauchement, contenance) ou toute autre relation exprimée en langage naturel.
L’implémentation des correspondances inter-schémas se fait par des algorithmes, qui se basent sur différents critères pour établir les correspondances. On distingue les critères de classification suivants (Rahm and Bernstein, 2001) :
Source
Source
Adaptateur
Entrepôt
Extraction / Transformation
Intégration/
Transformation/
Chargement Extraction / Transformation
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.