Partie I: Synthèse Bibliographique
Chapitre 7: Conception des Meta Data
III. Exploitation des métas données
III.2 Présentation de la partie supervision
Vu le nombre de sources de données et leurs dispersions géographiques, il se peut que l’alimentation en données d’une des directions de distribution ne se déroule pas comme prévu.
Dans ce cas, l’administrateur doit être en mesure de détecter les erreurs survenues lors de l’alimentation et avoir la possibilité de recourir à des solutions secours. Ces solutions de supervision et de chargement secours sont :
III.2.1 Supervision : l’administrateur aura la possibilité de suivre l’état des chargements journaliers de l’entrepôt de données. Ainsi, il aura une situation précise des chargements par direction de distribution, lui offrant de ce fait la possibilité de détecter les chargements échoués et la date de l’échec de manière à recouvrir les données non chargées.
III.2.2 Solutions secours : lors d’un chargement échoué l’administrateur de l’entrepôt de données pourra utiliser l’une des méthodes suivantes pour mettre à jour les données de l’entrepôt :
a. Le chargement paramétré : le chargement peut se faire à distance en spécifiant les directions concernées par ce chargement et le jour du chargement concerné.
Cependant, cette solution n’est utilisable que pour le jour suivant l’échec du chargement et cela, soit à cause de la volatilité des données, soit à cause de la quantité trop importante des données. Le paramètre de ce chargement n’est autre que les Directions de distribution concernées par le chargement.
b. Le chargement à partir des fichiers de sauvegarde : durant la présentation de la partie « alimentation de l’entrepôt » nous avons évoqué les fichiers de sauvegarde.
Ces fichiers sont utilisés afin de charger les données manquantes en cas de problèmes. Ces fichiers, qui sont générés après chaque extraction de données au niveau des directions de distribution, sont transférés et utilisés. Une durée de sauvegarde de ces fichiers est nécessaire, cette durée a été arrêtée à une semaine.
Le diagramme des cas d’utilisation suivant illustre les cas cités précédemment :
Figure II.39 : DCU supervision.
IV. Conclusion
La couche méta données est très importante dans un projet Data Warehouse, dans la mesure où elle en permet la maintenance de ce dernier, garantit son intégrité et facilite son expansion.
Ainsi il est plus que nécessaire de concevoir les métas données et de développer une couche applicative permettant de les maintenir. Dans ce chapitre nous avons essayé de concevoir un sous système d’administration de l’entrepôt de données qui répond aux exigences d’un tel projet.
Partie III :
Réalisation et déploiementRéalisation et déploiementRéalisation et déploiementRéalisation et déploiementI. Introduction
Pour la réalisation et la mise en place de la solution, il a été nécessaire de recourir à un certain nombre d’outils et mettre en place des environnements d’exécution.
Ce chapitre a pour objectif, de décrire l’environnement mis en place et les outils utilisés, ainsi que de décrire l’environnement existant (matériels et logiciels), et dans lequel évoluera notre système.
II. Implémentation
II.1 Périmètre technique et fonctionnel
Cette partie décrit les infrastructures déjà en place. En effet, cette dernière est une étape à ne pas négliger, car la diversité des sources et leurs plateformes techniques pourront engendrer des problèmes de compatibilité.
II.1.1 Matériel
Les systèmes sources sont installés sur différentes plateformes :
• Machine IBM,
• Machine INTEL : HP ou DELL, II.1.2 Systèmes d’exploitation
Lors de notre étude il a été recensé les systèmes suivants :
• AIX 5.1, 5.2 pour les machines IBM,
• LINUX : RedHat 4.5,
• Windows Server 2003,
• Solaris Sparc,
L’étude du matériel existant nous a permis de prévoir des solutions à certains problèmes, tels que la non compatibilité des machines AIX 5.2 avec la version du JRE nécessaire pour l’exécution des programmes d’extractions.
II.2 Architecture
La figure suivante illustre la structure
Figure III
II.3 Zone de stockage
Lors de la conception, il données : la base de données
Le choix du système de gestion de base de données s’est fait de chaque base de données, de son utilisation et d
1) Base de données «
La base de données, Data Warehouse, a été implémentée sous l source PostgresPlus. C
connu pour ses performances par rapport aux bases de données volumineuses intègre un ensemble d’outil
pré configuré pour la mise en place d’un Data Warehouse.
19 Voir annexe F.
Architecture technique de la solution
La figure suivante illustre la structure et l’architecture technique de la solution proposée
Figure III.1 : Architecture technique de la solution.
Zone de stockage
conception, il a été question de concevoir et mettre en place deux bases de : la base de données de la zone d’entreposage et celle des Meta data.
Le choix du système de gestion de base de données s’est fait en fonction de de données, de son utilisation et des données qu’elle contiendra.
Data Warehouse » :
La base de données, Data Warehouse, a été implémentée sous l source PostgresPlus. Cette distribution de PostgreSQL, en plus du
connu pour ses performances par rapport aux bases de données volumineuses intègre un ensemble d’outils d’administration et de configuration. Aussi ce SGBD est
configuré pour la mise en place d’un Data Warehouse.
technique de la solution proposée :
été question de concevoir et mettre en place deux bases de et celle des Meta data. d’administration et de configuration. Aussi ce SGBD est
2) Base de données Meta Data :
La base de données, Meta data, a été implémentée sous le SGBD MySQL, qui est un SGBD open source simple d’utilisation et performant pour les petites bases de données.
II.4 Zone d’alimentation de l’entrepôt
L’implémentation du processus de chargement peut se faire par le biais d’outils disponibles sur le marché. Une multitude de choix s’offre à nous. Cependant, et vu l’orientation de l’entreprise vers l’open source notre étude s’est limité à cette classe de produit.
Après une étude comparative, le choix a été porté sur « Talend Open Studio » dans sa version « 3.1.4r2 », connu comme l’outil le plus performant de sa catégorie open source [Daan, 2007]. Ce dernier basé sur l’IDE « Eclipse » intègre un ensemble de composants implémentés en JAVA et permet de rajouter son propre code JAVA.
Les points forts de cet outil sont :
• Assurer une indépendance totale vis-à-vis du SGBD source, ou celui implémentant l’entrepôt de données.
• Sa richesse en nombre de composants, permet l’extraction de toute source de données connue et standard.
• Génère des programmes en java s’exécutant sur différentes plateformes.
• Développé par une communauté importante qui ne cesse d’augmenter.
• Permet d’ajouter du code java afin d’implémenter notre solution telle qu’elle a été conçue.
II.5 Zone de restitution
Cette zone représente l’interface entre l’utilisateur et le Data Warehouse. Elle est constituée d’un ensemble d’outils qui doivent permettre aux utilisateurs d’exploiter le système mis en place dans les meilleures conditions possibles. . Ainsi plusieurs outils et serveurs ont été mis en place:
• Un serveur web Apache permettant un accès distant.
• Une plateforme BI « SpagoBI » pour la gestion et la diffusion des documents, ainsi que pour son module de création de requêtes à la demande « Querry by exemple ».
• Un moteur ROLAP « Mondrian », pour l’implémentation des cubes conçus pour l’analyse multidimensionnelle. Ce dernier est connu comme leader des moteurs ROLAP open source.
• Un serveur de reporting « JasperReports », pour l’édition des rapports préétablis.
Ces derniers sont conçus séparément et intégrés dans la plateforme « SpagoBI ».
• Un serveur SMTP, pour la diffusion des rapports.
• Implémentation des tableaux de bord conçus avec l’outil « Open Slazio » pour une représentation graphiques efficace et compréhensible.
Même si ces outils se présentent comme des solutions clé en main, ils nécessitent un travail d’intégration et de conception afin de donner une valeur ajoutée aux états implémentés.
En plus de la mise en place de ces outils, il était nécessaire de développer certains volets:
• Gestion des utilisateurs : ce module permettra la gestion des utilisateurs et des droits d’accès.
• Administration et supervision de l’entrepôt de données :
• Navigation dans les Meta data : cela offrira un support aux utilisateurs finaux.
Ces deux modules ont été développés en JavaServer Pages (JSP), qui est l’extension web du langage Java. Le développement s’est fait avec la version 6.5 de l’IDE NetBeans. Le choix de ce langage est en rapport avec les points suivants :
• Les possibilités offertes par ce langage.
• La portabilité des modules développés.
• L’intégration au sein du même serveur web.
• L’intégration dans la plateforme SpagoBI. Cette dernière étant développée en JSP.
• L’exécution au niveau serveur, offrant un niveau de sécurité optimum.
III. Déploiement
Pour mieux décrire le déploiement de la solution, on utilise le modèle de déploiement U.M.L qui permet de présenter l’architecture de déploiement d’une manière simple et compréhensible.
Comme on peut le voir, notre solution comporte trois zones : zone d’alimentation, zone de stockage et zone de restitution. Afin d’illustrer cela, on propose deux diagrammes de déploiements : Un diagramme pour la zone d’alimentation et un autre diagramme pour la zone de restitution. La zone de stockage étant liée directement aux deux autres zones sera décrite dans les deux modèles.
III.1 Déploiement de la zone d’alimentation
Figure III.2 : Digramme de déploiement de la zone d’alimentation.
III.2 Déploiement de la zone de restitution
Figure III.3 : Diagramme de déploiement de la zone de restitution.
IV. Conclusion
La partie de restitution est la partie sur laquelle l’utilisateur final aura à interagir. Cette dernière a été mise en place en intégrant des solutions « Open Source », et en développant certains volets de manière à assurer une bonne utilisation du système.
Des programmes ont été développés, au préalable, en JAVA, afin d’assurer l’alimentation de la zone de stockage en données. Cette dernière a été implémentée sous le SGBD PostgreSQL, dans sa distribution « PostgreSQLPLUS ».
Le déploiement de la solution se fait suivant les diagrammes de déploiement illustrés dans la figure III.2 et la figure III.3, et se divise en deux parties :
• Déploiement de la zone d’alimentation.
• Déploiement de la zone de restitution.
Le déploiement se fait pour le moment sur trois sites pilotes, et sera étendu à l’ensemble du territoire des que les résultats des tests fonctionnels auront été approuvés.
C
onclusion générale et perspectivesConclusion générale et Perspectives
Exploiter les données à disposition de l’entreprise afin de leur donner de la valeur ajoutée, tel est le défi des entreprises modernes.
Dans ce cadre, et afin de palier à des problèmes récurrents dans le processus de prise de décision, SONELGAZ a initié le projet de réalisation d’un Data Warehouse pour permettre la mise en place d’un système décisionnel fiable et efficace.
Tout au long de notre travail de conception et de réalisation, nous avons essayé de suivre une démarche mixte, alliant de ce fait entre Deux approches connues dans le domaine du Data Warehousing, à savoir l’approche « Besoins d’analyse » et l’approche « Sources de données ». Cette démarche a permis de répondre aux attentes et besoins des utilisateurs tout en exploitant au mieux les données générées par les systèmes opérationnels de manière à anticiper sur des besoins non exprimés.
Bien que la méthode des entretiens soit l’outil principal pour la collecte des besoins dans ce travail (en effet, le milieu et l’organisation du groupe ont rendu toute autre approche pratiquement impossible), l’étude des besoins déjà exprimés sous forme de rapports et de processus de prise de décision nous ont été d’une grande utilité pour définir de manière claire le périmètre et les besoins réels des utilisateurs. Cette étude a fait ressortir quatre sujets d’analyse dignes d’intérêt pour l’entreprise qui sont : Les ventes, les affaires, les nouveaux abonnés, le recouvrement.
Dans un deuxième temps, la modélisation de la zone de stockage des données s’est faite grâce aux principes de la modélisation dimensionnelle. Cette modélisation offre une vision claire et une compréhension intuitive des modèles proposés. Nous avons de ce fait proposé des modèles en étoiles des quartes activités recensés. Partant de chaque modèle dimensionnel, nous avons donné les modèles agrégés afin d’améliorer les performances du futur système.
La partie d’alimentation de la zone de stockage « implémentation physique des modèles dimensionnels sur un SGBD relationnel » a été sans nul doute la partie du projet la plus fastidieuse et consommatrice en temps ; nous permettant de vérifier le postula disant qu’il est nécessaire d’y consacrer plus de 80% du temps de réalisation d’un Data Warehouse.
Cette étape nous a permis de concevoir et de réaliser, grâce à des outils open source, les routines d’extraction, transformation et chargement des données.
L’utilisation d’outils et de solutions open source est un volet très important dans ce projet. En effet, l’orientation Open Source du projet a été décidée dés l’initiation de ce dernier. Cette orientation, qui se fait ressentir durant les étapes sus citées, est plus présente dans la partie « réalisation de la zone de restitution » grâce à l’intégration d’une plateforme
« BI », pour la diffusion et la gestion des documents, et d’outils de Reporting et de navigation dans les données complètement open source, offrant à l’utilisateur la possibilité d’exploiter les données de l’entrepôt via n’importe quel client léger. La partie restitution a aussi nécessité le
développement des volets de gestion des utilisateurs, d’administration de l’entrepôt et de supervision de ce dernier.
Pour la mise en route de la solution, nous avons entamé le travail de déploiement en choisissant des sites pilotes. Ce déploiement obéit à une démarche clairement illustrée grâce à des digrammes de déploiement présentés dans le dernier chapitre du rapport.
Pour finir, et avant de citer les perspectives du projet, nous pouvons dire que ce stage au niveau de SONELGAZ nous a permis d’acquérir une très bonne expérience professionnelle et d’évoluer dans un domaine qui nous était totalement inconnu à savoir le domaine des systèmes décisionnels, et au sein d’un environnement regroupant des équipes de professionnels du métier représentant la filiale « ELIT ».
Comme un projet Data Warehouse n’est jamais complètement terminé, nous pouvons citer les perspectives et les développements suivants :
• Suivre le déploiement actuel et recueillir les correctifs et remarques des utilisateurs.
• Etendre le déploiement de manière à couvrir, à terme, la totalité du territoire national.
• Etendre le système vers d’autres systèmes opérationnels notamment les systèmes de la HP/HT et de la ressource humaine.
• Utilisation des méthodes et algorithmes de Data Mining pour une meilleure exploitation des données.
• Continuer le développement du portail de restitution.
Bibliographie
Ouvrages
[Bouquin, 2003] : Bouquin Henry ; « Le contrôle de gestion » ; P.U.F ; 2003.
[Dresner, 2001] : H. Dresner ; « BI : Making the Data Make Sens » ; Gartner Group 2001.
[Franco, 1997] : Jean-Michel Franco; « Le Data Warehouse, le Data Mining » ; Eyrolles 1997.
[Goglin, 1998] : J.F. Goglin; « La Construction du Datawarehouse : du Datamart au Dataweb »; Hermes 1998.
[Inmon, 2002]: W. H. Inmon ; « Building the Data Warehouse Third Edition» ; Wiley Computer Publishing 2002.
[Kimball, 2004] : R. Kimball et J. Caserta ; « The Data warehouse ETL Toolkit» ;Wiley Publisshing, INC 2004
[Kimball, 2002] : R. Kimball et M. Ross ; « Entrepôts de Données : Guide Pratique de Modélisation Dimensionnelle 2ème édition » ; Vuibert 2002.
[Kimball,1996] : R. Kimball ; « Entrepôts de données : Guide pratique du concepteur de Data Warehouse » ;Wiley Computer Publishing 1996.
[Le Moigne, 1977] : Le Moigne J.L., « La théorie du système général, théorie de la modélisation », P.U.F., 1977.
[Nakache, 1998] : Didier Nakache; « Data Warehouse et Data Mining »; Conservatoire National des Arts et Métiers de Lille; Version 1.1; 15 juin 1998.
Articles et Thèses
Warehousing; International Technical Support Organization;
http://www.redbooks.ibm.com; février 1998.
[Codd, 93] : E. F. Codd ; « Providing OLAP (On-Line Analytical Processing) to User- Analysts : an IT mandate. » ; Technical report ; E.F. Codd &
Associates; 1993.
[Daan, 2007] : Daan Van Beck, Norman Manley, The ETL product survey 2007, A passionned International research paper, 2007.
[Favre, 2008] : Cécile Favre; «Évolution de schémas dans les entrepôts de données»;
Thèse de doctorat ; Université Lumière Lyon 2 «École Doctorale Informatique et Information pour la Société» ; Décembre
2007. national de la recherche scientifique Direction des systèmes d'information ;
http://www.dsi.cnrs.fr/conduite- projet/phasedefinition/gestion-de-projet/planification-suivi-projet/guide-planif-suivi-projet.pdf ;2001.