• Aucun résultat trouvé

Partie III: Implémentation et déploiement

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.