Soutenance mémoire
Entrepôt de données
La définition informatique d’un entrepôt de données introduite par (Inmon, 2005) dans son ouvrage de référence « Building the Data Warehouse » est la suivante : «A data warehouse is a subject-oriented, integrated, non-volatile, and time-variant collection of data in support of management’s decisions». Données orientées sujet (parfois traduit par: données orientées métier) Cette approche des données orientées sujet (parfois traduit par: données orientées métier) permet de développer le système décisionnel (entrepôt de données) via une incrémentation sujet par sujet. Cette orientation permet d’éviter la redondance des données concernées par plusieurs sujets. La Figure 1.1 présente un exemple des données orientées sujet dans un entrepôt de données telles que Client, Vendeur, Produit (Vangenot, 2005). Données intégrées L’entrepôt de données est alimenté par plusieurs sources de données opérationnelles ou transactionnelles déjà existantes dans l’entreprise.
Une donnée issue de l’opérationnel peut avoir des formats différents, des attributs différents, des descriptions différentes, etc. Pour avoir une image physique unique des données dans l’entrepôt de données, les données doivent être intégrées c’est-à-dire converties, reformatées, résumées, etc. (Inmon, 2005). Données historisées L’analyse de l’évolution des données dans le temps est fondamentale pour un système décisionnel. Elle permet à la fois de prendre des décisions et de mesurer leurs effets (Inmon, 2005). Données non-volatiles La non-volatilité dans un système décisionnel consiste à historiser les données tout en gardant les versions de mise à jour durant leurs existences. Il s’agit toujours d’une opération d’insertion dans l’historique et non de mise à jour. 7 La Figure 1.2 illustre la non-volatilité des données dans un entrepôt de données. Dans une base de données opérationnelle (à gauche de la Figure 1.2), les données sont fréquemment manipulées, consultées et mises à jour à chaque enregistrement. Alors que dans un entrepôt de données (à droite de la Figure 1.2), les données sont chargées généralement en masse et accessibles en lecture. Toutes les modifications ultérieures se traduisent par des insertions d’enregistrements avec conservation de l’historique (Inmon, 2005).
Architecture d’un entrepôt de données (Adamson, 2010) a donné une représentation simplifiée de l’architecture d’Inmon telle qu’elle apparaît dans la Figure 1.3. Cette architecture est composée de trois parties:
• l’ETL un processus qui collecte les données du système opérationnel sous différents formats pour les homogénéiser;
• les bases de données qui englobent une base de données normalisée (entrepôt de données) et des bases de données multidimensionnelles orientées sujets alimentées par l’entrepôt de données;
• la partie exploitation et visualisation des données pour l’analyse, la fouille et l’exploration des données afin d’aider l’utilisateur final à prendre les bonnes décisions. Des exemples d’outils ETL et d’outils d’analyses et d’explorations sont présentés et détaillés à l’ANNEXE II.
Sur cette approche d’architecture, Adamson a voulu corriger un mythe: «Le projet de loi Inmon est anti-schéma en étoile». En effet, Inmon préconise la modélisation en étoile au niveau des magasins de données (« Data Marts ») et ceci est justifié par ses propres travaux de recherche. Par contre (Kimball, 1996) a introduit une autre architecture d’entrepôts de données (Voir Figure 1.4) dont l’approche est similaire à l’architecture d’Inmon pour ce qui est de l’utilisation des données opérationnelles par la couche ETL. Ce qui la différencie de la méthode d’Inmon est la vision sur la construction de l’entrepôt de données : Kimball construit l’entrepôt de données à partir des besoins des utilisateurs avec la modélisation multidimensionnelle. Les données sont organisées dans une série de dimensions en utilisant la modélisation de « schéma en étoile » ou de cubes analysés à partir des besoins identifiés. Ces deux approches d’architectures d’Inmon et Kimball ont fait l’objet de discussions sur Internet sous le slogan « Inmon versus Kimball »: les discussions sont pratiquement de même type et ne font que répéter plus ou moins les mêmes points. Une critique qui nous parait plus complète est celle de (Breslin, 2004) qui a soulevé les similitudes et les différences entre Inmon et Kimball (Voir le Tableau 1.1).
Passer du sur mesure à l’infrastructure La Figure 1.7 illustre un exemple de la situation traditionnelle d’un hôpital et montre que le Labo IRM, les soins intensifs et la maternité ont une opération commune qui est l’enregistrement du patient. Cette prise en charge est un service qui peut s’acquérir pour toute l’organisation. Avec la SOA, les services (Régime d’alimentation, Opération, Médiation, Diagnostic, etc.) sont des services métiers et peuvent être réutilisés au sein de l’organisation, tels qu’ils apparaissent dans la Figure 1.8. Avec ces services métiers différents, la SOA permet la réutilisation pour dégager d’autres services communs tels qu’ils apparaissent dans la Figure 1.9. Ces services sont des outils standards ou services techniques (sécurité, autorisations, etc.) qui facilitent la maintenance et la rapidité au niveau développement. La Figure 1.10 présente ainsi la nouvelle organisation du travail sous une architecture SOA. Dans cette architecture, les applications (maternité, soins intensifs, R.H, Soins intensifs, etc.) sont des processus métiers situés dans la couche supérieure appelée processus métiers. Ces processus font appel à des services métiers réutilisables (régime et alimentations, opération, médication, etc.) et présentés dans la couche sous-jacente appelée services métiers. Ces services métiers font appel à des services techniques réutilisables (sécurité, transformation, journalisation, etc.) dans la couche appelée services techniques. Enfin une quatrième couche appelée couche infrastructure physique ou couche technologique où on trouve les bases de données, les serveurs d’applications, etc. et sont appelés directement par les services techniques.
SOA et Entrepôt de données
Dans la littérature, certains auteurs ont parlé de l’intégration de l’entrepôt de données dans la SOA. Selon (El akkaoui, 2009), l’outil ETL est une composante essentielle pour la consolidation des données dans un système décisionnel. La diversité des modèles d’outils ETL a posé un problème de communication de ces outils avec d’autres modèles d’outils et auquel s’ajoutent la complexité et le coût. Pour trouver une solution au problème de communication, (El akkoui, 2009) dans sa thèse propose une modélisation des processus ETL dans une architecture SOA. Ce modèle s’appuie sur le standard « Business Process Model and Notation (BPMN)» pour la modélisation conceptuelle des processus ETL. Ce modèle utilise aussi le « Web Services Business Process Execution Language (WS-BPEL)» un processus qui se base sur les opérations décrites dans le WSDL (les types de messages, les ports utilisés, les opérations, etc.) pour spécifier les interactions entre les différents services Web.
Ce processus est décrit dans un document en XML et exécuté par un moteur d’orchestration. Les avantages de cette modélisation (El akkaoui , 2009) sont de masquer les détails techniques de chaque processus ETL, d’utiliser un langage exécutable standard et de transformer les processus ETL en des processus d’affaires gérés par les utilisateurs finaux. Sur un autre plan de recherche, (Ronnie, 2008) présente un prototype sur l’intégration de l’entrepôt de données quasi temps réel dans la SOA et ce pour le partage des connaissances stratégiques à travers une grande distribution. Dans l’architecture proposée (Voir Figure 1.13), (Ronnie, 2008) utilise l’entrepôt de données et l’entrepôt de données quasi temps réel comme sources de données pour la SOA. L’entrepôt de données quasi temps réel est alimenté par un processus cycle de chargement des données «Change data capture- CDC» qui fait une capture des données modifiées dans les sources de données opérationnelles à partir d’un fichier LOG. L’objectif est de minimiser les ressources requises par l’ETL. L’entrepôt de données est mis à jour par l’entrepôt de données quasi temps réel à une fréquence déterminée. L’architecture SOA et l’architecture entrepôt de données communiquent via le middleware ESB.
|
Table des matières
INTRODUCTION
CHAPITRE 1 ÉTAT DE l’ART
1.1 Entrepôt de données
1.1.1 Définitions
1.1.2 Architecture d’un entrepôt de données
1.2 Architecture orientée service
1.2.1 Définitions
1.2.2 Les technologies standards de mise en oeuvre de la SOA
1.2.2.1 Les services web
1.2.2.2 Entreprise Service Bus (ESB)
1.3 SOA et Entrepôt de données
1.4 Pourquoi combiner les entrepôts de données et la SOA
1.5 Sommaire du chapitre
CHAPITRE 2 LA PROBLÉMATIQUE DE LA RECHERCHE
2.1 But et objectifs de la recherche
2.2 Limites de la recherche
2.3 Méthodologie de la recherche
2.4 Sommaire du chapitre
CHAPITRE 3 ENTREPÔT DE DONNÉES ORIENTÉ SERVICES
3.1 Les concepts clés de la SODWA
3.2 Justifications de la SODWA
3.3 Vue détaillée de la SODWA
3.4 Exemple d’utilisation de la SODWA
3.5 Évaluation qualitative partielle et préliminaire de la SODWA
3.6 Sommaire du chapitre
CONCLUSION
ANNEXE I LES PHASES DE DÉVELOPPEMENT D’UN PROJET D’ENTREPÔT DE DONNÉES
ANNEXE II LES LOGICIELS ETL ET LES LOGICIELS D’ANALYSES ET DE RAPPORTS
BIBLIOGRAPHIE
Télécharger le rapport complet
