Remerciements. Nous tenons aussi à remercier notre encadrant professionnel : Monsieur MOHA- MED KOBAA pour son assistance et son suivi permanent.

Transcription

1 Remerciements C'est avec un grand plaisir que je réserve ces lignes en signe de gratitude et de reconnaissance à tous ceux qui ont contribué de près ou de loin à l'élaboration de ce travail. Nous tenons à exprimer mes remerciements les plus vifs en premier lieu à ceux qui nous font l'honneur de participer et de siéger dans ce jury et être les rapporteurs de ce travail. Nous tenons aussi à remercier notre encadrant professionnel : Monsieur MOHA- MED KOBAA pour son assistance et son suivi permanent. Nous tenons à remercier Monsieur ELYES JRAD, ingénieur à TALAN, pour son soutien aussi bien moral que technique. Nous remercions particulièrement Monsieur BAHJET BOUSAFARA, Directeur de TALAN Tunisie International ainsi que l'ensemble de l'équipe pour avoir eu l'amabilité de nous accueillir au sein de leur organisme et de nous avoir procuré leurs précieux conseils. Enn, Nos remerciements s'adressent aussi à tous nos enseignants pour la qualité de l'enseignement qu'ils nous ont prodigué durant nos études.

2 Table des matières Liste des gures Liste des tableaux vii x Glossaire 1 Introduction générale 2 1 Cadre du projet Introduction Présentation de Talan Secteurs d'activités Historique Talan tunisie Présentation du cathédrale Objectifs Cadre de notre projet Problématique Présentation du projet

3 TABLE DES MATIÈRES iii 1.5 Conclusion Etude préalable Introduction Etat de l'art Informatique décisionnelle Dénition Le processus de prise de décision Le système d'information décisionnel Les briques du décisionnel Entrepôt de données Dénition Caractéristiques de l'entrepôt de données Modélisation multidimentionnelle Dénition : Les concepts de base : Les schémas multidimensionnels Méthode de conception d'un schéma multidimensionnel Aperçu sur les outils décisionnels existants Les serveurs OLAP PALO Mondrian \ JPivot Les outils ETL Talend open source

4 TABLE DES MATIÈRES iv Pentaho Data Integration (Kettle) Oracle Warehouse Builder Comparaison Conclusion Spécication Introduction Etude du système existant Processus et fonctionnement Besoin d'un système décisionnel Spécication des besoins Besoins fonctionnels Besoins non fonctionnels Analyse des besoins Les acteurs du système Diagrammes de cas d'utilisation général Description de cas d'utilisation Gestion de l'entrepôt de données Diagramme de cas d'utilisation Description textuelle de cas d'utilisation Extraire les données : Description de cas d'utilisation Analyse des données Diagramme de cas d'utilisation Description textuelle des cas d'utilisation Analyser les données :

5 TABLE DES MATIÈRES v Diagramme de séquence Description de cas d'utilisation Extraire les données Diagramme de cas d'utilisation Description textuelle des cas d'utilisation Diagramme de séquence : Conclusion Conception Introduction Architecture globale de la solution Conception détaillée Architecture du datawarehouse Démarche adoptée Conception du datawarehouse Architecture du module ETL Flux de contrôle Flux de données Conclusion Réalisation Introduction Environnement de travail Environnement matériel Environnement logiciel Choix des outils de travail

6 TABLE DES MATIÈRES vi 5.3 Implémentation Construction de l'entrepôt de données (ETL) Importation de la base du système d'information Construction des dimensions Construction des tables de fait Exportation du job nal de l'extraction et exécution Création et dénition des cubes avec schéma workbench Interface Homme/Machine L'analyse des données Génération des documents décisionnels Problèmes rencontrés Chronogramme Conclusion Conclusion générale 64 Bibliographie 66 Annexe A 67 Annexe B 70 Annexe C 72

7 Liste des gures 1.1 Les secteurs d'activité de TALAN Organisation de Talan Tunisie International Processus de prise de décision Briques de l'informatique décisionnelle Données intégrées Données non volatiles Architecture mondrian Diagramme de cas d'utilisation général de Cathedrale Diagramme de cas d'utilisation : Gestion de l'entrepôt de données Diagramme de cas d'utilisation : Analyse des données Diagramme de séquence : Analyse des données Diagramme de cas d'utilisation : " Extraire les données" Diagramme de séquence : Extraire les données Architecture globale de la solution Schéma de l'entrepôt de données La hiérarchie " Temps_Semestre "

8 LISTE DES FIGURES viii 4.4 La hiérarchie " Temps_Trimestre" La hiérarchie " Mission " La hiérarchie " Mission_tache " Flux de contrôle Traitement de la dimension "Temps" Traitement de la dimension "Resource humaine" Traitement des autres dimensions Traitement de la mesure charge projet de construction d'axe temporel d'extraction Projet de construction d'axe temporel d'analyse Projet de construction de la dimension ressource humaine Projet de construction de la table de fait aectation_tache Projet nal d'extraction Dénition des cubes Page d'accueil Analyse croisée Explication des Outils Analyse du nombre de jour chargés pour tous le personnel en fonction du temps Exemple d'analyse avec le language MDX Analyse du nombre de jours chargés pour tous les collaborateurs Analyse du nombre de jours chargés en fonction du qualication et de la mission

9 LISTE DES FIGURES ix 5.14 Chronogramme du stage

10 Liste des tableaux 2.1 Comparaison entre les outils ETL

11 Glossaire BI : Business Intelligence. OLAP : On-Line Analytical Processing. MOLAP : Multidimensional On-Line Analytical Processing ROLAP : Relational On-Line Analytical Processing. MDX : MultiDimensional expressions. CSV : Comma-Separated Values XML : extensible Markup Language SWT : Standard Widget Toolkit ETL : Extract Transform Load.

12 Introduction générale D e nos jours, nous ne cessons d'évoluer et de toucher ecacement diérents domaines. Ce progrès vient contrer le phénomène de blocage du processus normal d'amélioration et d'expansion de l'entreprise dû à une organisation traditionnelle. En eet, l'informatisation de l'entreprise a permis à celle-ci de subir une véritable métamorphose tout en protant de multiples avantages. Mais, confrontés à une masse énorme et diversiée de données, les systèmes d'informations de type relationnel qui représentent depuis de nombreuses années la référence en matière de stockage de l'information ne répondent plus aux besoins des décideurs. La qualité de l'information et la rapidité de son acquisition augmente l'ecacité des prises de décisions et par la suite le développement rapide de l'entreprise. L'adoption de nouvelles technologies sur lesquelles reposent les systèmes d'information est désormais inévitable surtout avec la concurrence ascendante sur le marché. Dans ce sens, l'informatique décisionnelle permet aux entreprises une meilleure homogénéité des données et y ajoute de l'intelligence an de rendre les décisions plus adéquates. Ceci permet à l'entreprise d'être plus réactive et évolutive pour mieux répondre aux attentes des clients. Les divers avantages de cette technologie poussent un grand nombre d'entreprises à l'adopter et à bâtir dessus leurs systèmes d'information. Dans ce cadre, s'inscrit notre projet de stage d'immersion en entreprise qui a pour but la conception et la réalisation d'un outil d'analyse et de reporting multidimensionnel. Le présent document décrit le travail réalisé pendant notre stage eectué au sein de l'entreprise TALAN Tunisie International. Ce rapport est organisé comme suit :

13 INTRODUCTION GÉNÉRALE 3 Le premier chapitre présente l'organisme d'accueil et le sujet à traiter. Le second chapitre consiste en une étude théorique qui introduit quelques notions de base dont la maîtrise est indispensable pour le déroulement de ce projet. De plus une brève présentation de l'étude de l'existant. Le troisième chapitre présente tout d'abord une analyse des besoins, ensuite la formalisation de la spécication du projet. Ceci permet de procéder à la représentation de l'interaction de l'utilisateur avec le système. Le quatrième chapitre englobe toute la partie conception. Le dernier chapitre traite tous les détails de la réalisation : les outils de travail, les diérentes étapes de la réalisation du système ainsi que quelques captures d'écran illustrant les fonctionnalités.

14 Chapitre 1 Cadre du projet 1.1 Introduction Le présent chapitre a pour objectif de présenter dans une première section l'entreprise accueillante Talan Tunisie International. Ensuite, nous présentons le projet Cathédrale comme le système d'informations de l'entreprise TALAN. 1.2 Présentation de Talan Talan [N1] est un acteur alternatif aux grandes sociétés de conseil et de services, spécialisée dans le domaine de la refonte des processus métiers et l'intégration des nouvelles technologies et qui concentre son expertise sectorielle sur les Grands opérateurs de Services (Finance, Télécom, Utilities et Service Public). Ce groupe est composé de plus de trois cents consultants qui orent leurs services aux grands groupes tels que Société Générale, BNP Paribas, CALyon, Caisse d'épargne, Natixis, Groupama, NPower, Gaz de France, Bouygues Telecom, Neuf-Cegetel, Stade de France Secteurs d'activités L'activité de Talan se partage entre les prestations : De conseil et d'assistance à la Maîtrise d'ouvrage, de la refonte et l'optimisation des processus métiers, de support aux grands projets de transformation, de l'alignement des systèmes d'information aux

15 Chapitre 1. Cadre du projet 5 changements d'organisation et à l'accompagnement au changement. Comme le montre la gure 1.1, l'activité de TALAN s'étend à trois grands domaines : - Le développement de la performance des entreprises. - L'intégration des nouvelles technologies dans les systèmes d'information des entreprises. - Les fonctions de supports des systèmes d'informations des entreprises. Figure 1.1 Les secteurs d'activité de TALAN Historique Juin 2002 : création Septembre 2002 : Lancement de l'activité en France, au Royaume-Uni et au Benelux. Janvier 2006 : Ouverture du bureau de New York. Mars 2006 : Lancement de l'activité "near-shore" en Tunisie. Février 2007 : Ouverture du bureau de Hong-Kong.

16 Chapitre 1. Cadre du projet 6 Décembre 2008 : 320 consultants, 27 M de CA, 14% de résultat d'exploitation, 9,3% de résultat net. À venir : Tokyo, Dubaï. 1.3 Talan tunisie Talan délivre ses savoir-faire métiers, fonctionnels et technologiques à l'échelle internationale, avec des bureaux à Paris, Londres, Tunis, New York et Hong Kong. En 2006, Talan a mis en place son centre de développement " near-shore " en Tunisie, regroupant à ce jour plus de 80 ingénieurs de développement dans les nouvelles technologies. L'organisation de cette entreprise est présentée dans la gure suivante. Figure 1.2 Organisation de Talan Tunisie International

17 Chapitre 1. Cadre du projet Présentation du cathédrale Cathédrale est le nom du système d'information de Talan. Parmi les fonctionnalités de Cathédrale citons : - La gestion des ressources humaines : collaborateurs, candidats et compétences de ces derniers; - La gestion des projets : clients, contacts et surtout missions; - La gestion commerciale; - La facturation Objectifs Un système d'information a pour objectif d'améliorer les processus de gestion, de maîtriser les aspects nanciers de l'entreprise dont l'objectif nal est d'anticiper les besoins futurs. Le besoin de collecter, de traiter et de diuser des informations de l'entreprise, le besoin de coordination croissant des activités au sein et entre les entreprises sont les nouvelles sources de l'avantage concurrentiel. C'est au système d'information de prendre en charge ces besoins grâce aux nouvelles technologies de l'information qui peuvent accélérer les ux d'information, supprimer des tâches sans valeur ajoutée et renforcer la abilité et la qualité des processus. Toutefois, parmi ces nouvelles technologies le reporting et l'analyse multidimensionnelle Cadre de notre projet Problématique Les données stockées au niveau de la base du système d'information ne sont pas exploitées à travers des rapports couvrant le besoin des utilisateurs et des managers qui ne cesse de croître avec le développement de l'activité. Le besoin analytique est traité

18 Chapitre 1. Cadre du projet 8 d'une manière manuelle et non précise. Ce contexte de travail pénalise la réactivité de l'entreprise dans la prise de décision et dans ses choix stratégiques. A cet eet, TALAN souhaite intégrer une solution à ce problème dans son nouveau système d'information Cathédrale en mode Web Présentation du projet Notre mission consiste à intégrer une solution d'intelligence métier suivant le besoin de l'entreprise. La solution permettra de faire l'extraction des données, de naviguer dans les cubes OLAP de la base multidimensionnelle conçue pour cette solution et générer les rapports jugés utiles pour la prise de décision. Cette application visera l'amélioration et la modernisation des fonctions de reporting, d'analyse de données et de suivi. 1.5 Conclusion Ce chapitre constitue une partie introductive dans laquelle une présentation des organismes d'accueil a été élaborée en premier lieu. En second lieu, une présentation des grandes lignes du sujet a été établie. Compte tenu de cette présentation, une étude de l'état de l'art est indispensable an de dénir les grands axes à développer puis d'extraire les principales fonctionnalités à satisfaire.

19 Chapitre 2 Etude préalable 2.1 Introduction An de réussir les phases de conception et de développement, nous estimons qu'une étude préalable doit être élaborée. Pour ceci nous dénissons, en premier lieu, le concept décisionnel, ensuite nous expliquons les diérentes étapes du processus de prise de décision. En second lieu, nous étudions quelques concepts de base permettant de situer le projet dans son contexte. En troisième lieu, nous nissons cette étude par une description des outils décisionnels existants. 2.2 Etat de l'art Comme notre travail consiste en une solution d'aide à la décision, nous consacrerons cette partie à une présentation de l'informatique décisionnelle ainsi que d'autres concepts directement reliés Informatique décisionnelle Dénition Le décisionnel en anglais Business Intelligence est "un système interprétant des données complexes permettant aux dirigeants d'entreprise de prendre des décisions en

20 Chapitre 2. Etude préalable 10 connaissance de cause". Le décisionnel couvre l'ensemble des technologies permettant, en n de chemin, d'apporter une aide à la décision, en fournissant au décideur des informations sûres lui permettant de juger son activité. Cette démarche critique permet une clairvoyance et, par conséquent une grande rapidité dans le processus de prise de décision [N3] Le processus de prise de décision Une décision est le résultat d'un processus comportant le choix conscient entre plusieurs solutions, en vue d'atteindre un objectif. Les étapes qui constituent le processus de prise de décision sont les suivantes : Dénir le problème; Rassembler les faits et les données; Evaluer et interpréter les faits et les données; Etablir plusieurs solutions; Décider (choisir une solution). La gure 2.1 montre les étapes de prise de décision décrites ci-dessus. Figure 2.1 Processus de prise de décision

21 Chapitre 2. Etude préalable 11 Comme l'illustre déjà la gure 2.1, les systèmes d'information décisionnels interviennent dans la deuxième et la troisième étape. Nous allons dans la suite présenter le système d'information décisionnel ainsi que les briques du décisionnel Le système d'information décisionnel Le système d'information décisionnel est un ensemble de données organisées de façon spécique, facilement accessibles et appropriées à la prise de décision. Les systèmes décisionnels sont généralement dédiés aux cadres de l'entreprise pour les aider au pilotage de l'activité. Ils consistent en une synthèse d'informations opérationnelles internes ou externes, choisies pour leur pertinence et leur transversalité fonctionnelle, et sont basés sur des structures particulières de stockage volumineux. Le principal intérêt d'un système décisionnel est d'orir au décideur une vision transversale de l'entreprise intégrant toutes ses dimensions [N4] Les briques du décisionnel Pour bien mener un projet décisionnel, les plateformes d'informatique décisionnelles se basent sur un ensemble de briques. Ces briques (appelées aussi des outils de l'informatique décisionnelle) sont classées en quatre catégories correspondant chacune à une fonction spécique : Collecter, nettoyer et consolider les données; Traiter les données; Stocker les données; Restituer les données. Le schéma de la gure 2.2 illustre les diérentes briques de l'informatique décisionnelles.

22 Chapitre 2. Etude préalable 12 Figure 2.2 Briques de l'informatique décisionnelle Dans ce qui suit, nous détaillons les diérentes fonctions des outils de l'informatique décisionnelle. Collecte et traitement des données : La phase de collecte et de préparation de données est la phase la plus importante dans un projet décisionnel. L'objectif majeur de cette étape est de transformer des sources diverses de données (bases de données relationnelles, chiers plat, chier XML ou autres) vers une base de données centrale appelée entrepôt de données. Cette phase est assurée par l'implication des outils d'extraction, de transformation et de chargement (noté ETC et appelé ETL en anglais pour Extract, Transform and Load). En eet, l'etc est un outil permettant d'extraire des données d'une base de production, les modier et éventuellement les remettre dans un entrepôt de données.[n5] Les principales fonctionnalités d'un ETC sont : L'Extraction : permet l'accès aux diérents systèmes de stockage de données an de récupérer les données les plus importantes après leurs identications et sélection.

23 Chapitre 2. Etude préalable 13 La Transformation : les données extraites ne sont pas toutes correctes, c'est pour cette raison quelles nécessitent certaines vérications et transformations. C'est à ce niveau qu'intervient la fonctionnalité de la transformation qui a pour but de nettoyer et reformater les données an d'éliminer les redondances. Le Chargement : consiste à consolider les données extraites et nettoyées dans un entrepôt de données. Stockage des données : Après avoir collecté et préparé les données pertinentes, nous procédons à leur stockage dans un entrepôt ou un magasin de données. Celles-ci sont stockées selon une organisation propre au concept décisionnel axé sur les besoins d'analyse et d'accessibilité. Restitution des données Une fois nettoyées, stockées, consolidées et rendues accessibles, les données sont maintenant utilisables. Selon les besoins, diérents types d'exploitations seront envisagés : - Analyser les données avec les outils de type OLAP pour les analyses multidimensionnelles; - Assister les décideurs avec les tableaux de bord 1 présentant les indicateurs clé de performance; - Communiquer la performance avec le Reporting Entrepôt de données Dénition La dénition la plus communément acceptée d'un entrepôt de données (appelé aussi datawarehouse) tourne autour de quatre caractéristiques (l'intégration, l'orientation sujet, la sensibilité au temps et la non-volatilité) et d'un objectif : l'aide à la 1. Un tableau de bord est un instrument de mesure de la performance facilitant le pilotage d'une ou plusieurs activités dans le cadre d'une démarche de progrès 2. Reporting : Action d'extraction de données pour une présentation synthétiques sous forme de rapport

24 Chapitre 2. Etude préalable 14 décision. Cette dénition a été proposée en 1990 par Bill Inmon 3 et est la suivante : " Le datawarehouse est une collection de données orientées sujet, intégrées, non volatiles et historisées, organisées pour le support d'un processus d'aide à la décision " [1] Caractéristiques de l'entrepôt de données Données orientées sujet : Le datawarehouse est orienté sujets, cela signie que les données collectées doivent être triées par thème (sujets majeurs, métiers) vs systèmes de production : processus fonctionnels. Données intégrées : (voir gure 2.3) Le datawarehouse est composé de données intégrées, elles proviennent de systèmes sources hétérogènes donc un nettoyage préalable des données est nécessaire dans le but d'assuré la cohérence, la normalisation et la prise en compte des contraintes référentielles et des règles de gestion. Figure 2.3 Données intégrées Données non volatiles(voir gure 2.4) Les données du datawarehouse sont non volatiles ce qui signie que les données ne disparaissent pas et ne changent ni au l des traitements ni au l du temps (Read Only). 3. Bill Inmon, reconnu comme le " père d'entreposage de données ". C'est un expert en gestion de base de données et en conception d'entrepôt de données

25 Chapitre 2. Etude préalable 15 Figure 2.4 Données non volatiles Données historisées Les données du datawarehouse sont aussi historisées, donc horodatées et par suite on peut visualiser l'évolution dans le temps d'une valeur donnée Modélisation multidimentionnelle Dénition : La modélisation multidimensionnelle souvent appelée modélisation OLAP se présente comme une alternative au modèle relationnel. Elle correspond mieux aux besoins du décideur tout en intégrant la modélisation par sujet [B2]. En eet, la modélisation multidimensionnelle est une méthode de conception logique qui vise à présenter les données sous une forme standardisée intuitive et qui permet des accès hautement performants. Elle aboutit à présenter les données non pas sous forme de table mais de cubes centrés sur une activité. Ce type de modélisation considère les données comme des points dans un espace à plusieurs dimensions. Ces points représentent les centres d'intérêt décisionnels (sujets) analysés en fonction des diérents axes d'analyse.[3]

26 Chapitre 2. Etude préalable Les concepts de base : Fait : C'est un sujet d'analyse c'est-à-dire un centre d'intérêt décisionnel. Il regroupe un ensemble d'attributs numériques représentant les mesures d'activité. Mesure : C'est un sujet d'analyse c'est-à-dire un centre d'intérêt décisionnel. Il regroupe un ensemble d'attributs numériques représentant les mesures d'activité. Dimension : C'est un axe d'analyse selon lequel sont visualisées les mesures d'activité d'un sujet d'analyse. Paramètre : C'est un attribut appartenant à une dimension. Il représente un niveau de détail selon lequel sont visualisées les mesures d'activité d'un sujet d'analyse. Hiérarchie : C'est une perspective d'analyse dénie dans une dimension. Elle regroupe un ensemble de paramètres organisés de la granularité la plus petite vers la granularité la plus générale Les schémas multidimensionnels Les schémas multidimensionnels les plus connus sont : Schéma en étoile : Il comporte un seul sujet d'analyse (fait) englobant un ou plusieurs indicateurs (mesures). Ce schéma opère selon plusieurs axes d'analyse (dimensions) comportant la description des paramètres selon plusieurs perspectives d'analyse (hiérarchie) organisant les paramètres en diérentes granularités. Schéma en ocon de neige : Il est, en fait, le modèle en étoile avec une normalisation des dimensions lorsque

27 Chapitre 2. Etude préalable 17 celles-ci s'avèrent trop volumineuses. Schéma en constellation : Il comporte plusieurs sujets d'analyse (fait) et plusieurs axes d'analyse (dimensions) pouvant être partagés entre les diérents faits Méthode de conception d'un schéma multidimensionnel Les méthodes ascendantes : Elles utilisent les sources de données pour dénir les besoins des décideurs et pour concevoir les schémas dimensionnels. Ces méthodes considèrent que les informations pertinentes pour la prise de décision se trouvent dans la source. Seulement, les besoins des utilisateurs sont très évolutifs et diciles à dénir d'où le risque d'obtenir un schéma instable en se basant sur ces besoins dans la modélisation dimensionnelle. Les méthodes descendantes : les données des sources ne sont pas prises en compte car ces méthodes considèrent que l'objectif d'un modèle dimensionnel est de répondre aux besoins des utilisateurs. Elles se basent uniquement sur la spécication de ces besoins pour dénir les sujets et les axes de l'analyse en négligeant la structure et le contenu des sources à partir desquelles les données décisionnelles sont extraites. Les méthodes mixtes : Elles combinent les deux méthodes précédentes et essayent de combler les lacunes de chacune d'elles. Ces méthodes se basent sur les données sources pour dénir le schéma dimensionnel en y intégrant les besoins des utilisateurs. 2.3 Aperçu sur les outils décisionnels existants An de développer une solution compétitive, une étude des outils déjà existants est indispensable. En eet, il existe divers outils d'analyse et de reporting répondant à des fonctionnalités bien spéciques. Nous allons nous focaliser dans cette étude aux

28 Chapitre 2. Etude préalable 18 serveurs OLAP et aux diérents ETL Les serveurs OLAP Pour choisir un moteur OLAP performant et ecace, nous avons disposé de deux Moteur (Mondrian et Palo ) pour les étudier, les comparer et enn faire le bon choix PALO Palo fait de la catégorie M-OLAP, ce qui lui permet d'obtenir de très bons temps de réponse. Il s'intégre dans le tableur Excel et permet d'insérer des données multidimensionnelles dans les feuilles de calcul. Cette intégration permet de tirer partie des fonctionnalités graphiques d'excel, il peut être utilisé avec les langages Java et PHP. Cependant, il ne supporte pas le langage MDX Mondrian \ JPivot Mondrian[N6] est un serveur OLAP disponible sous licence open source. Il fait partie de la catégorie des serveurs R-OLAP, c'est-à-dire qu'il accède à des données contenues dans une base relationnelle. Mondrian exécute des requêtes utilisant le langage MDX. Ce langage permet de créer des requêtes dont l'équivalent en langue SQL nécessiterait un grand nombre de requêtes et des temps d'exécution beaucoup plus longs. Ce serveur est le plus souvent utilisé conjointement avec JPivot 5. Un cube Mondrian peut également être implémenté dans une plateforme telle que Jasper, Pentaho ou SpagoBI. L'interrogation se fera alors à travers l'outil " JPivot ", en 4. Le MDX (de l'anglais Multidimensional Expressions, expressions multidimensionnelles ) est un langage de requête pour les bases de données OLAP, analogue au rôle de SQL pour les Bases de données relationnelles. C'est aussi un langage de calcul avec une syntaxe similaire à celle des tableurs 5. un outil qui est un outil qui propose une interface graphique de consultation et manipulation des données.cette librairie permet d'extraire et de présenter les données d'une base relationnelle à travers une représentation sous forme de cube OLAP. La présentation se fait en mode web, intégrable dans un portail ou des pages dédiées.

29 Chapitre 2. Etude préalable 19 mode web. Ci-dessous le schéma d'architecture nous permet de comprendre les mécanismes mis en uvre : 1. L'outil client transmet une requête au format MDX au serveur MONDRIAN. 2. Après validation du format de la requête, celui-ci utilise le schéma XML correspondant aux données à traiter an de transmettre une demande formatée à la couche de requêtage SQL. 3. La couche de requêtage accède à la base physique et extrait les données correspondantes à la requête. 4. Les résultats sont transmis à l'outil client. Figure 2.5 Architecture mondrian Synthése Le choix de l'une ou l'autre solution doit être fait selon les besoins des utilisateurs naux et la capacité d'intégration des équipes techniques. Pour Mondrian, un gros eort doit être fait par celles-ci pour appréhender les mécanismes de fonctionnement et d'intégration ainsi que l'écriture de schéma de description. Dans notre stage d'été, nous nous intéressons à la plateforme décisionnelle open source Pentaho Mondrian /JPivot. Ce choix est xé en faisant référence aux exigences

30 Chapitre 2. Etude préalable 20 et aux besoins de l'entreprise d'une part et à la performance du serveur d'autre part. En eet, les fonctionnalités oertes par la solution Mondrian répond bien aux exigences on na pas besoin de la gestion des utilisateurs oerte dans Palo puisque cette fonctionnalité est déjà implementé dans le projet Cathedrale Les outils ETL Le choix le plus dicile dans tout projet décisionnel consiste à déterminer quelle méthode doit être mise en uvre pour l'extraction des données : On a opté pour l'utilisation d'un ETL Open Source. On bénécie ainsi des avantages d'un ETL tout en gardant une maîtrise lissée des coûts et être plus ecace que écrire un code spécique (procédures SQL, code Java ou autre). Nous avons disposé de trois ETL (Talend Open Studio, Pentaho Data Integration et Oracle Warehouse Builder ) pour les étudier, les comparer et enn faire le bon choix Talend open source Talend[N8] est un ETL Open Source qui permet de migrer des données d'une base à une autre, comme il permet le traitement des projets décisionnels (génération de la datawarehouse, du cube olap et de reporting) Talend est un ETL générateur de code (pour chaque traitement d'intégration de données, un code est généré) Pentaho Data Integration (Kettle) Kettle [N9] est distribué sous licence open source. Il permet de concevoir et exécuter des opérations de manipulation et de transformation de données. Grâce à un modèle graphique à base d'étapes, il est possible de créer sans programmation des processus composés d'imports et d' export de données et de diérents opérations de

31 Chapitre 2. Etude préalable 21 transformation, telles que conversions, des jointures, l'application de ltres ou même l'exécution de fonctions JavaScript. Pentaho est un moteur de transformation (les données traitées et les traitements à eectuer sont parfaitement séparés) Oracle Warehouse Builder OWB est un ETL propriétaire. Il ore une interface graphique pour une construire les dimensions, faits, mapping, fonctions, etc. Il est plus qu'un simple outil ETL; il s'agit également d'un outil de conception d'entrepôt de donnés et de prise en charge son cycle de développement. Il ore en outre une structure extensible pour l'intégration des diérentes sources de données, ainsi que pour l'intégration aux outils décisionnels Comparaison Le tableau suivant présente une comparaison des outils ETL décrits précédemment.

32 Chapitre 2. Etude préalable 22 Environnement Langages Sources de travail de programmation de données utilisées Talend Talend utilise une interface Java PostgresSQL graphique " Job Designer " Perl MySQL basée sur la plateforme Eclipse. SQL Server Access Oracle XML CSV Excel Kettle Pentaho utilise une interface XML PostgresSQL "spoon" basée sur SWT MySQL SQL Server Access Oracle XML CSV Excel OWB C'est un Design ETL graphique XML Oracle Génération incrémentale du code SAP R/3 en utilisant le mapper Flat Files ODBC DB2 Sybase Informix SQL Server Tableau 2.1 Comparaison entre les outils ETL Synthése En comparant ces outils, on dégage que Talend qui génére le code java des projets

33 Chapitre 2. Etude préalable 23 peut être plus simple et plus facile a comprendre et à manipuler. Aussi, les sources de données les plus utilisées dans les sociétés sont celles de Talend et Kettle comme les chiers CSV et les bases Oracle et MySQL. 2.4 Conclusion Tout au long de ce chapitre nous avons essayé d'expliquer quelques concepts de base de l'informatique décisionnelle qui présente le centre d'intérêt de notre projet. Ensuite, nous avons élaboré une étude des solutions décisionnelles existantes et ce an de pouvoir développer une solution compétitive et évolutive. Ceci fait, nous pouvons entamer l'analyse et la spécication des besoins.

34 Chapitre 3 Spécication 3.1 Introduction Nous nous intéressons dans ce chapitre à la phase analyse qui est la première phase de la méthodologie adoptée. Nous commencerons dans ce chapitre par une étude de système d'information de TALAN pour montrer l'utilité de notre projet qui va s'intégrer dans ce système ensuite nous abordons la spécication des besoins fonctionnels et non fonctionnels an de dégager les diagrammes des cas d'utilisation et des scénarios d'exécution qui constituent le dernier volet de ce chapitre. 3.2 Etude du système existant Processus et fonctionnement Le système d'information de TALAN est composé de deux modules reliés entre eux. Le premier module permet la gestion des Ressources Humaines (Gestion des Collaborateurs). Ce module doit permettre la gestion des collaborateurs de TALAN tels que la création, la modication, la recherche et la consultation. Les collaborateurs TA- LAN présentent son principal point fort ce qui requiert un besoin important de suivre leurs carrière et répondre à leurs attentes à travers la " Cathédrale ". Le deuxième module permet la gestion des projets. Ce module permet de maintenir la base des clients de TALAN et d'avoir une vision exhaustive sur les contacts identiés

35 Chapitre 3. Spécication 25 chez les clients ainsi que sur les projets en cours chez ces clients avec les ressources qui y sont rattachées. Tous les utilisateurs de la Cathédrale peuvent bénécier des services de ce module telles que la recherche et la consultation mais la création et la modication est restreinte aux responsables RH. Les fonctionnalités oertes par ce module sont : Gestion des contacts de TALAN (création, consultation et modication des contacts); Gestion des clients de TALAN (création, consultation et modication des clients); Gestion des missions réalisées par TALAN chez ses clients (création, consultation et modication des missions); Le suivi des projets; Aectation des ressources et des tâches; L'évolution des plannings des missions eectuées Besoin d'un système décisionnel Le système d'information CATHEDRALE a pour objectif principal, la gestion des Ressources Humaines ainsi que la gestion des projets. La Base de données a cumulé un patrimoine informationnel très important. Ainsi, des écrans de consultations ont été développés, ces consultations sont prédénies. Les informations recueillies lors des réunions avec le chef de projet permettent de conclure qu'un système d'aide à la décision est indispensable pour générer des rapports plus conviviaux et des graphiques plus signicatifs pour suivre l'évolution des projets et des ressources humaines. Ainsi, le portail décisionnel sera un outil de travail quotidien qui permettra aux utilisateurs de gagner du temps dans leurs analyses multidimensionnelles.

36 Chapitre 3. Spécication Spécication des besoins Dans cette partie, nous allons dénir les diérents besoins fonctionnels et non fonctionnels de notre solution Business Intelligence Besoins fonctionnels Les principaux besoins fonctionnels de notre solution se résument dans les points suivants : Collecter et préparer les données de l'entreprise; Stocker les données dans l'entrepôt de données (Data warehouse); Organiser et représenter les données d'une façon structurée; Mise en place et installation de serveur OLAP; Création des cubes; Disposer de trois centres d'analyse : Une analyse sur les ressources humaines,une analyse sur les projets de l'entreprise et une analyse sur les tâches d'un projet; Générer des rapports selon un format prédéterminé permettant au responsable de disposer d'une précieuse vue d'ensemble de son activité Besoins non fonctionnels Les principaux besoins non fonctionnels sont : L'intégrabilité : La solution doit s'intégrer dans le système d'information de l'entreprise; La performance : La solution proposée doit être rapide, able et opérationnel d'une façon continue; La modularité : La solution doit être modulaire pour garantir la souplesse et l'évolutivité; L'ergonomie des interfaces et la facilité d'utilisation :

37 Chapitre 3. Spécication 27 Le module doit présenter une interface claire, ergonomique et intuitive. 3.4 Analyse des besoins Dans ce qui suit nous allons approfondir la description des besoins précédemment spéciés par construction des diagrammes de cas d'utilisation correspondants avec une description des scénaris associés, par la suite nous proposons quelques diagrammes de séquence pour une meilleure visibilité de l'application conçue Les acteurs du système Les principaux acteurs qui interviennent dans notre système sont : L'administrateur : qui a le droit de gérer les privilèges de chaque utilisateur et la gestion de l'entrepôt de données. Le décideur : qui est le gérant de l'entreprise et qui peut être le directeur général, le chef de département, le responsable des ressources humaine ou bien le chef de projet Diagrammes de cas d'utilisation général La gure 3.1 illustre les diérents cas d'utilisation de l'application Cathedrale des acteurs précédemment identiés. Ce diagramme décrit les grandes fonctionnalités de l'application de point de vue des acteurs, mais n'expose pas de façon détaillée le dialogue entre les acteurs et les cas d'utilisation.

38 Chapitre 3. Spécication 28 Figure 3.1 Diagramme de cas d'utilisation général de Cathedrale Une description détaillée des diérents cas d'utilisation que nous avons développé (Gérer l'entrepôt de donnés, Faire des analyses, Extraire les données) sera alors faite dans la suite.

39 Chapitre 3. Spécication Description de cas d'utilisation Gestion de l'entrepôt de données Diagramme de cas d'utilisation Le diagramme de cas d'utilisation de la gure 3.2 présente les étapes par lesquelles l'administrateur doit passer pour arriver à construire son DataWarehouse. Figure 3.2 Diagramme de cas d'utilisation : Gestion de l'entrepôt de données

40 Chapitre 3. Spécication Description textuelle de cas d'utilisation Extraire les données : Résumé : ce cas d'utilisation présente les étapes par lesquelles l'administrateur doit passer pour arriver à construire son Data Warehouse à savoir Extraction, Transformation et Chargement des données. Pré condition : Les sources de données sont déjà mises en place et accessibles. Scénario nominale : 1- Congurer l'outil ETL. 2- Se connecter à la base de production. 3- Conçevoir et réaliser des projets d'extraction des données. 4- Conçevoir et réaliser des projets de transformation des données. 5- Conçevoir et réaliser des projets de chargement des données. 6- Exporter le projet nal de l'extraction sous forme de projet web. 7- Déployer le projet exporté sur le serveur. Enchaînement d'échec : E1 : L'extraction de données n'a pas pu se dérouler. L'enchaînement E1 démarre au point 3 du scénario nominal. Vérier les connexions à la base. E2 : Une erreur de compilation est achée. L'enchaînement E1 démarre au point 3,4 ou 5 du scénario nominal. Vérier les diérents jobs. Post condition : Le module d'extraction est généré avec succès Description de cas d'utilisation Analyse des données Diagramme de cas d'utilisation L'analyse et le reporting des données est une tache spécique au décideur. Le diagramme de cas d'utilisation de la gure 3.3 présente les actions réalisées par le décideur au cours de la phase d'analyse.

41 Chapitre 3. Spécication 31 Figure 3.3 Diagramme de cas d'utilisation : Analyse des données Description textuelle des cas d'utilisation Analyser les données : Résumé : ce cas d'utilisation permet au décideur de faire les analyses des données. Pré condition : s'authentier en tant que décideur, au moins une extraction de données a été déjà réaliser. Scénario nominale : 1- Sélectionner le cube. 2- Choisir la date extraction. 3- Sélectionner les dimensions. 4- Sélectionner les mesures. 5-Valider le choix. 6-Achage de données.

42 Chapitre 3. Spécication 32 7-Sélectionner le format de graphe. 8-Acher le graphe. 9-Enregistrer le rapport. Enchaînement d'échec : E1 : Date d'extraction non sélectionnée.l'enchaînement E1 démarre au point 5 du scénario nominal. Sélection de la date d'extraction de données. Post condition : Analyse achevée avec succès et rapport enregistré Diagramme de séquence Le diagramme de séquence système qu'illustre la gure 3.4 suivante décrit le cas d'utilisation "Analyse des données "

43 Chapitre 3. Spécication 33 Figure 3.4 Diagramme de séquence : Analyse des données Description de cas d'utilisation Extraire les données Diagramme de cas d'utilisation L'exécution d'extraction des données est une tâche spécique au décideur. Le diagramme de séquence de la gure 3.5 présente les actions réalisées par le décideur relative à cette phase.

44 Chapitre 3. Spécication 34 Figure 3.5 Diagramme de cas d'utilisation : " Extraire les données" Description textuelle des cas d'utilisation Résumé : Ce cas d'utilisation permet au décideur de faire une nouvelle extraction des données vers l'entrepôt de données avec comme date d'extraction la date actuelle. Pré condition : S'authentier en tant que décideur. Scénario nominale : 1- Accéder à la page d'accueil du système d'information. 2- Lancer le module "reporting" 3-Lancer l'extraction des données Enchaînement d'échec : E1 : L'extraction a été déjà lancée avec cette date Une seule extraction par jour est permise. E2 : Des messages d'erreurs relatifs à l'extraction sont achés. Vérier que les données sont cohérentes. Post condition : L'extraction est achevée avec succès. Des messages de conrmation de succès sont achés.

45 Chapitre 3. Spécication Diagramme de séquence : Le diagramme de séquence illustré par la gure 3.6 décrit le cas d'utilisation " Extraire les données "

46 Chapitre 3. Spécication 36 Figure 3.6 Diagramme de séquence : Extraire les données 3.5 Conclusion Dans ce chapitre, nous avons cerné les objectifs de notre application. Ces objectifs doivent tenir compte des problèmes de la solution existante. Cette phase va nous permettre de bien élaborer le modèle de conception de l'application. Dans le prochain chapitre nous aborderons la partie conception décrivant la modélisation des besoins exprimés dans cette section.

47 Chapitre 4 Conception 4.1 Introduction La conception est un processus créatif et d'importance majeure dans le cycle de développement d'un projet. Ainsi ce chapitre sera consacré à la présentation des différentes étapes de la conception de notre application, et an de présenter au mieux cette partie nous allons donner une vue globale décrivant l'architecture générale de notre système, puis, la conception multidimensionnelle et enn, nous allons détailler la conception de l'etl. 4.2 Architecture globale de la solution Notre projet consiste en une solution commençant de la base de données de production jusqu'à la visualisation des documents décisionnels. La gure 4.1 ci-dessous illustre l'architecture globale de la solution.

48 Chapitre 4. Conception 38 Cubes de serveur OLAP ETL Base de données du SI CATHEDRALE Entrepôt de données OLAPCATHEDRALE Décideurs utilisant l application Figure 4.1 Architecture globale de la solution 4.3 Conception détaillée Dans cette partie nous allons détailler chaque composant de notre solution, précédemment décrite, d'une façon globale Architecture du datawarehouse Nous présenterons dans cette partie la démarche adoptée durant la conception de notre entrepôt de données en premier lieu et le schéma multidimensionnel de notre base d'analyse avec les détails concernant chaque fait et dimension Démarche adoptée Dans notre projet nous avons opté pour la méthode descendante et le schéma en constellation. En eet notre choix repose sur plusieurs critères. Le schéma en constellation : Ce schéma s'avère être le schéma le plus approprié dans notre cas. En eet, il facilite en un premier lieu les corrélations entre les diérents sujets d'analyse et spécie, en second lieu, la modélisation avec la possibilité de partager les dimensions.

49 Chapitre 4. Conception 39 La méthode descendante : Son but est de concevoir un schéma décisionnel en se basant sur les besoins des décideurs. Cette méthode ne prend pas en compte les données sources, ce qui la rend plus ecace et plus appropriée. En eet, la base de données source était non seulement volumineuse mais aussi contient des données dupliquées et mal structurées Conception du datawarehouse Nous commençons par la présentation du schéma de l'entrepôt de données cidessous que nous expliquerons en détails. Qualification PK idqualification Libellé resource humaine PKidresource humaine nom prenom date naissance tel mobile competence adresse Tache PK idtache FK idmission Libellé cloture Phase Pk idphase Libellé PK affectation tache idaffectation tache FK1 tache idtache FK2 temps mesure idtemps mesure FK3 Qualification idqualification FK4 temps idtemps FK5 resource humaine idresource humaine nbre jours chargés nbre jours non chargés PK Fait tache idfait tache FK1 tache idtache FK2 temps mesure idtemps mesure FK3 phase idphase FK4 temps idtemps charge dépensé charge restante charge totale délai total délai dépensé délai restant Temps PK idtemps jour mois année quart date trimestre semestre jour de année mois de année semaines de année Temps mesure PKidtemps mesure date jour mois année quart trimestre semestre jour de année mois de année semaines de année Mission Pk idmission Libellé PK Fait mission idfait mission FK1 temps idtemps FK2temps mesure idtemps mesure FK3 Mission idmission charge dépensé charge restante charge totale délai total délai dépensé délai restant Figure 4.2 Schéma de l'entrepôt de données Les tables de fait La table de fait " fait_mission " : Contient tous les critères d'un projet comme son nom, son état. Cette table admet aussi des mesures comme :charge estimée, délai estimé, délai dépensé, charge dépensée et à partir de ces mesures nous déduisons la

50 Chapitre 4. Conception 40 charge restante et le délai restant. La table de fait " fait_tache " : Cette table contient tous les critères d'une tache dans un projet comme son état. Elle admet aussi des mesures comme charge estimée, délai estimé, délai dépensé, charge dépensée et a partir de ces mesures nous déduisons la charge restante et le délai restant. La table de fait "aectation_tache" : Cette table concerne les ressources humaines et leur aectation. Elle admet des mesures comme nombre de jours chargés et nombre de jours non chargés. Les dimensions La dimension " Temps " : C'est une dimension temporelle qui est la base de chaque datawarehouse utile pour l'historisation des données et avoir un suivi de l'évolution des informations. Dans notre cas cette dimension est associée aux tables suivantes : La table de fait " fait_mission " : à travers la date de début de mission et la date de n de celle-ci. La table de fait " fait_tache " : à travers la date du début d'aectation de la tâche à une ressource humaine et la n de cette aectation. La table de fait " aectation_tache " : à travers la date du début d'aectation de la tâche à une ressource humaine et la n de cette aectation. La dimension " Temps_mesure " : C'est une dimension temporelle qui sert à l'enregistrement des dates d'extraction; c'est une sorte de journalisation des données. Dans notre cas cette dimension est associée aux tables suivantes : fait_tache, aectation_tache et fait_mission. La dimension " Mission " : Cette dimension contient tout les informations des projets comme l'entreprise, le client et les noms complet des projets. Cette dimension est associé à la table fait_mission. La dimension " Phase " : Cette dimension contient la phase de la tache pour

51 Chapitre 4. Conception 41 la table " fait_tache " La dimension " Ressource_humaine " : Cette dimension est associé à la table " aectation_tache " Elle contient toutes les informations concernant la resource humaine aectée à la tache. La dimension " Qualication " : Cette dimension est associée à la table "affectation_tache". Elle nous renseigne sur la qualication des colloborateurs. Les hiérarchies C'est une perspective d'analyse dénie dans une dimension permettant une analyse des données en profondeur pour détailler les analyses ou les généraliser. Nous avons utilisé dans notre solution quatre hiérarchies qui sont les suivantes. La hiérarchie "Temps-Semestre " Cette hiérarchie est contenue dans la dimension temporelle " Temps ", elle divise l'année en semestres puis des quarts, des mois, etc... Elle est dénie en détail par la gure cidessous. Hiérarchie Temps-semestre date année mois semestre quart Figure 4.3 La hiérarchie " Temps_Semestre " La hiérarchie " Temps_Trimestre " Comme la hiérarchie présentée précédemment la hiérarchie " Temps-Trimestre " gure dans la dimension temporelle. Cette hiérarchie se caractérise par rapport à la hiérarchie précédente par la division de l'année en trois trimestres. La gure ci-dessous décrit notre présente hiérarchie.

52 Chapitre 4. Conception 42 hierarchie Temps trimestre date année mois trimestre Figure 4.4 La hiérarchie " Temps_Trimestre" La hiérarchie " Mission" Cette hiérarchie gure dans la dimension Mission.La gure ci-dessous décrit notre présente hiérarchie Hierarchie Mission Nom entreprise Nom mission Figure 4.5 La hiérarchie " Mission " La hiérarchie " Mission_tache" : Cette hiérarchie relie les deux dimensions Mission et Tache en utilisant la notion de jointure. La gure ci-dessous décrit notre présente hiérarchie

53 Chapitre 4. Conception 43 Hierarchie Mission tache Mission Tache Figure 4.6 La hiérarchie " Mission_tache " 4.4 Architecture du module ETL Notre objectif est d'importer les données de la base relationnelle relative au système d'information CATHEDRALE (voir Annexe A), dans notre datawarehouse. Pour cela, il nous faudra spécier dans un premier temps la source de données. Puis dans un second temps, il nous faudra réaliser la transformation de données an que les formats de celles-ci soient compatibles pour l'insertion. Enn, en destination nous identierons la base multidimensionnelle, plus précisément les tables de faits et les dimensions décrites ci-dessus. Dans cette partie nous allons exposer quelques graphes de ux de données réalisés dans l'etl ainsi que le ux de contrôle Flux de contrôle Le ux de contrôle permet de contrôler, ordonner et dissocier les tâches à réaliser par le module. Dans notre cas, le ux de contrôle regroupe les diérents traitements agissants sur les mesures et dimensions. Le traitement des mesures et dimensions se déroule dans des ux de données.

54 Chapitre 4. Conception Flux de données Figure 4.7 Flux de contrôle Le ux de données permet de contrôler, d'ordonner et de dissocier l'ensemble des données à traiter. C'est à cette étape que la sélection, la transformation et l'insertion des données sont réalisées. Par la suite, nous allons présenter quelques ux de ce type conçus lors de notre projet.

55 Chapitre 4. Conception 45 Traitement des dimensions Il s'agit dans cette partie de récupérer les données jugées utiles à partir de la base initiale, d'eectuer les transformations nécessaires et de les charger dans les dimensions conçues auparavant. Traitement de la dimension Date Le traitement de la dimension Date nécessite la récupération de toutes les dates éparpillées dans les tables Aection et Mission. Des transformations d'unication sont nécessaires avant le chargement dans la dimension. Les gures suivantes représentent les traitements eectués sur les diérentes dimensions : Dimension Temps, Temps Mesure, Aectation, Qualication, Mission et Tache. Figure 4.8 Traitement de la dimension "Temps"

56 Chapitre 4. Conception 46 Figure 4.9 Traitement de la dimension "Resource humaine" Figure 4.10 Traitement des autres dimensions Traitement des mesures Le traitement des mesures (tables de fait) se fait de la même manière que les dimensions. La gure suivante illustre les transformations appliquées an d'aboutir à la mesure

57 Chapitre 4. Conception 47 Charge du table de fait "fait_mission". Figure 4.11 Traitement de la mesure charge 4.5 Conclusion Dans ce chapitre nous avons abordé l'architecture globale de notre solution. Par la suite, nous avons présenté les méthodologies adoptées pour la modélisation multidimensionnelle. Ce chapitre inclut aussi le schéma complet de l'entrepôt de données et la conception du module ETL. La conception de notre travail étant ainsi achevée, nous pouvons passer au dernier volet de notre rapport et qui est l'exposition des diérents éléments du travail.

58 Chapitre 5 Réalisation 5.1 Introduction Ce chapitre constitue le dernier volet de ce rapport, il a pour objectif d'exposer le travail achevé. Pour ce faire, nous commençons par la description des outils de travail. Ensuite, nous exposons les diérentes étapes de construction de l'entrepôt de données. Enn, nous clôturons ce chapitre par la présentation des étapes de l'analyse multidimensionnelle avec quelques captures d'écran de l'interface homme/machine. 5.2 Environnement de travail La réalisation de ce projet a nécessité l'utilisation d'un nombre d'outils et de technologies cités ci-dessous Environnement matériel Un ordinateur de bureau hp avec les caractéristiques suivantes : Processeur :Pentium4 CPU 3.20 GHz, 3.19GHz; RAM :2 Go; Cache :2Mo.

59 Chapitre 5. Réalisation Environnement logiciel Le long de la phase de développement, nous avons utilisé l'environnement logiciel suivant : Système d'exploitation : Microsoft Windows XP Professionnel Version 2002 SP2; Outils de développement : Eclipse,DBDesigner 4, Schéma workbench; Serveur OLAP : Pentaho Mondrian/JPivot 3.1, Serveur d'application : Apache Tomcat 5; ETL : Talend open studio 3.1; Navigateur web : Mozilla Firefox ; SGBD : oracle 10g; Outils de gestion de base de données : SQLDeveloper; La rédaction du rapport : Latex en utilisant l'éditeur WinEdt 5.4 et miktex Choix des outils de travail ETL : talend open studio A partir des recherches eectuées sur les fonctionnalités des ETL open source existants on a choisi de travailler avec Talend Open Studio pour les raisons suivantes : Les engagements de Talend : Talend est une solution d'intégration de données Open Source able, construite avec des technologies récentes (elle est fondée sur les standards Eclipse RCP, java, Perl, SQL, SOA), et disponibles sous licence GPL v2. Il est plus performant que les solutions commerciales de point de vue fonctionnalités. Bénéces immédiats : //- Meilleure performance est montée en charge; - Meilleur niveau fonctionnel et facilité d'utilisation, meilleure connectivité; - Facilité de démarrage; - Cycle de développement raccourcis.

60 Chapitre 5. Réalisation 50 Fonctionnalités de Talend : - Modélisation des processus orientée métier - Développement graphique - Performance, abilité et montée en charge - Connectivité à tous les systèmes - Design et exécution orientés métadonnées - Debugging en temps réel Outil OLAP :Mondrian/JPivot À partir des recherches eectuées sur les fonctionnalités des analyseurs OLAP existants, on a choisi d'installer (voir annexe C) et travailler avec Pentaho Mondrian/JPivot 3.1 [N5] pour les raisons suivantes : - licence open source; - la possibilité de modier et ajouter des fonctionnalités; - solution légère facile à intégrer dans le système d'information CATHEDRALE. 5.3 Implémentation Construction de l'entrepôt de données (ETL) La première étape de l'implémentation repose sur la construction de l'entrepôt de données. Dans cette partie nous allons présenter quelques captures d'écran expliquant toutes l'élaboration d'un entrepôt de données Importation de la base du système d'information C'est une étape très importante vu que la base de données sources du système d'information CATHEDRALE est volumineuse(voir l'annexe A). En eet, nous devons parcourir toutes les tables et détecter les dépendances existantes entre elles an de localiser les données dont nous avons besoin.

61 Chapitre 5. Réalisation Construction des dimensions Dimension Temps_mesure Le projet permet d'enregistrer à chaque extraction la date actuelle. Cette date sera utile pour l'historisation des données. La gure suivante 5.1 décrit la méthode adoptée pour charger la dimension Temps_mesure. Figure 5.1 projet de construction d'axe temporel d'extraction Dimension Temps Le projet de la gure 5.2 permet d'extraire les dates du début et de la n de l'aectation de tâche et du début et de la n de la mission. La méthode adoptée est de récupérer les deux dates, de début et de n avec le composant (tflowtoiterate) puis avec une boucle (tloop) on dénit les dates entre ces deux dates comme un ux de données sortant du (tfixedflowinput) et entrant pour le (tunite). Enn, on réalise le mapping pour créer la dimension Temps.

62 Chapitre 5. Réalisation 52 Figure 5.2 Projet de construction d'axe temporel d'analyse Dimension Resource_humaine Le mapping entre les tables sources " Collaborateur " et " Personne " et la table destination " Resource_humaine " permet la création de dimension "Resource_humaine".La gure suivante (gure 5.3) décrit cette correspondance. Figure 5.3 Projet de construction de la dimension ressource humaine

63 Chapitre 5. Réalisation 53 De même les dimensions Phase, Qualication, Mission, Tâche, et Ressource humaine sont créés Construction des tables de fait Une fois les dimensions sont crées on aborde la création du cube de donnée affectation tout en spéciant la correspondance des données sources et destination en utilisant le composant "tmap". Ce composant nous permet d'une part de remplir les faits conçus précédemment à partir des données sources, et d'autre part, d'eectuer les transformations nécessaires. La gure suivante (gure 5.4) illustre le projet qui permet le mapping relatif au fait aectation_tache.

64 Chapitre 5. Réalisation 54 Figure 5.4 Projet de construction de la table de fait aectation_tache De même nous chargeons les tables " fait_mission "et " fait_tache" Exportation du job nal de l'extraction et exécution Le projet nal (gure 5.5) contient les sous projets suivants : TempsMesure et temps : La création des dimensions temporelles. Loadtables :La création des dimensions utiles pour les cubes de données. Fait_aectation : chargement de la table de fait " aectation_tache " ainsi le cube aectation. Fait_mission : chargement de la table de fait " fait_mission " ainsi le cube projets. Fait_tache : chargement de la table de fait " fait_tache " ainsi le cube tache. L'exécution du projet est accompagnée par la génération des messages d'erreur et de validation. " tmsgbox ". Ce projet est exporté en tant que Webservice grâce aux options oertes par Talend. En eet, l'archive WAR générée comprend tous les chiers de conguration nécessaires à l'exécution ou au déploiement pour une application Web.

65 Chapitre 5. Réalisation 55 Figure 5.5 Projet nal d'extraction Une fois que l'archive est générée, on place le chier WAR dans le répertoire de notre serveur d'application Web. L'URL utilisée pour déployer notre job ressemble à la suivante : //http ://localhost :8080/ ProjetOlapCathedrale_0.1/services/OlapCathedrale?method=runJobargs=null Création et dénition des cubes avec schéma workbench Selon les besoins des décideurs et la conception faite précédemment nous avons dénit les dimensions et les cubes pour le serveur OLAP. Cette étape réside dans la dénition des cubes, des hiérarchies,des dimensions et des mesures appropriés. En fait, cette étape conduit à la génération d'un chier XML (Voir annexe B) qui sera utilisé par Mondrian/JPivot pour la visualisation des données des cubes. La gure 5.6 suivante montre un exemple de dénition de la dimension Mission pour le cube projets à l'aide de l'outil " Schema workbench". Le schéma obtenu dénit notre base de données multidimensionnelle. Il contient le

66 Chapitre 5. Réalisation 56 Figure 5.6 Dénition des cubes modèle logique des cubes, des hiérarchies, des membres et de la mise en correspondance (mapping) qui transforme ce modèle logique en un modèle physique. Le modèle logique consiste à dénir les structures utilisées dans une requête MDX : cubes, dimensions, hiérarchies, niveaux et membres. Il donne également la source des données représentées dans le modèle logique Interface Homme/Machine Cette section présente quelques interface homme/machine du projet. Page d'accueil En se connectant à l'aide d'un navigateur web au système d'information et en choisissant le module " reporting " la page suivante apparaît (gure 5.7).

67 Chapitre 5. Réalisation 57 Figure 5.7 Page d'accueil L'analyse des données La gure 5.8 suivante donne un aperçu sur une analyse qui a été conçue à l'aide du moteur JPivot/Mondrian. En eet, JPivot est un client OLAP disposant d'une interface Web. Il permet de représenter un cube OLAP sous forme de tableau croisé et d'eectuer les opérations classiques d'analyse de façon interactive.

68 Chapitre 5. Réalisation 58 Figure 5.8 Analyse croisée Les outils essentiels du Mondrian/JPivot Figure 5.9 Explication des Outils

69 Chapitre 5. Réalisation 59 Mondrian nous permet via les outils précédents de représenter à l'aide d'un graphique les données que nous venons d'agréger comme le montre la gure 5.10 suivante. Figure 5.10 Analyse du nombre de jour chargés pour tous le personnel en fonction du temps Mondrian nous permet d'ajouter ou d'enlever des champs (colonnes ou lignes) ou des ltres. Il est possible à tout moment de visualiser ou de modier une requête MDX comme le montre la gure suivante 5.11

70 Chapitre 5. Réalisation 60 Figure 5.11 Exemple d'analyse avec le language MDX

71 Chapitre 5. Réalisation Génération des documents décisionnels Les gures 5.12 et 5.13 suivantes illustrent des exemples de rapports indiquant l'évolution du nombre de jours chargés suivant plusieurs axes d'analyse. Figure 5.12 Analyse du nombre de jours chargés pour tous les collaborateurs

72 Chapitre 5. Réalisation 62 Figure 5.13 Analyse du nombre de jours chargés en fonction du qualication et de la mission 5.4 Problèmes rencontrés Dans cette partie nous énumérons les problèmes rencontrés tout au long de la réalisation de ce projet : -la navigation dans les cubes de données ne permet pas souvent de trouver des résultats intéressants. La diculté de la navigation dans les données s'accroît avec l'augmentation de la dimensionnalité du cube. -L'installation technique du Mondrian/JPivot et la connection à la base de données avec les drivers spéciques a posé quelques problèmes.

73 Chapitre 5. Réalisation Chronogramme Ce travail a été réalisé durant une période d'environ un mois et demi. L'évolution de la réalisation de notre projet est décrite dans le chronogramme suivant. Figure 5.14 Chronogramme du stage 5.6 Conclusion Dans ce chapitre nous avons présenté l'environnement du travail ainsi que les choix techniques adoptés lors de l'implémentation. Nous avons exposé les diérentes interfaces de travail, les problèmes rencontrés et enn un chronogramme du projet détaillant son évolution.