Conception et Réalisation d'un Data Warehouse
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
4,145
On Slideshare
4,145
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
1,096
Comments
0
Likes
6

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Mémoire de fin d’études Pour l’obtention du diplôme d’Ingénieur d’Etat en Informatique Option : Systèmes d’information ThèmeConception et réalisation d’un Data Warehouse pour la mise en place d’un système décisionnel Document de base Réalisé par Encadré par - FILALI ABDERRAHMANE - MERABET SOUAD - KEDJNANE SOFIANE - MEDJAOUI NADJI Promotion : 2009/2010
  • 2. Remerciements Nos remerciements vont tout spécialement à nos familles, qui ont sus nous supporter etencourager tout au long de notre vie, ainsi que pour leur aide inestimable, leur patience etleur soutien indéfectible. Nous tenons aussi, à remercier tout les enseignants qui ont contribué de près ou de loinà notre formation. Nous remercions Mme Souad Merbet et M. Nadji Medjaoui pour avoir assurél’encadrement de ce projet, qui n’a pas toujours été de tout repos. On remercie monsieurMedjaoui pour nos séances de travail agréables et fructueuses, ses remarques pertinentes,mais aussi pour son écoute et son discours bienveillants. Nous remercions Mme Merabet pour la confiance quelle nous a accordé et de nousavoir donné l’opportunité de travailler sur un projet d’une tel envergure. Nous remercions Mme Ait Ali Yahia pour ces critiques constructives qui nous ontpermis d’améliorer ce mémoire. Nous nous devons de mentionner la précieuse et totale collaboration que nous avonsreçu au sein de ELIT, de part les moyens mis à notre disposition et l’aide et le support apportépar l’ensemble des employés et des cadres. On remercie vivement Mesdames et Messieurs les membres du jury d’avoir accepterd’évaluer ce travail. Pour finir, et afin de n’oublier personne (amis, membre de la famille et tous ceux quinous sont chers) nous utiliserons la formule : « Merci à… ». ^xw}ÇtÇx 9 Y|ÄtÄ|
  • 3. DédicacesJe dédie ce modeste travail à : M es parents, qui n’ont jamais cessé de m’encourager et me soutenir, M on frère : M oham med, et m es sœurs :A mina et Soum ia M on binôm e et ami Sofiane et sa famille, M es amis : Amine, M ouhata, M oham med, Lotfi … Tous les m embres de ma famille, Ceux qui me sont chers, M on cousin : Samir, puisse dieu l’accueillir dans son vaste paradis. TuwxÜÜt{ÅtÇx
  • 4. DédicacesA: M es parents, pour leur soutient indéniable et leur aide précieuse « Pourrais-je jamais vous dire tous mon am our», M a grand-mère, pour sa patience et pour avoir su me supporter, M a sœur Linda, et mes frères Tareq et Yacine, pour leurs encouragements et leur amour, Tous les m embres de la famille, pour l’intérêt qu’ils m’ont montré, M on binôme (et ami) Abderrahmane « H amza » et toute sa famille, pour ce qu’ils m’ont apporté, M es amis, pour tous ce qu’on a partagé ensemble, Toutes les personnes proches que je n’ai pas citées Je dédie ce travail. fÉy|tÇx
  • 5. SommaireRésumé :………………………………………………………………………………………..IAbréviations :………………………………………………………………………………….IIListe des tableaux …………………………………………………………………………….IVListe des figures ……………………………………………………………………………...VIIntroduction générale ................................................................................................................. 9 1. Problématique .............................................................................................................. 10 2. Objectifs du projet ........................................................................................................ 11 Partie I: Synthèse Bibliographique.I. Introduction ...................................................................................................................... 15 I.1. Les systèmes décisionnels ........................................................................................ 15 I.1.1. La place du décisionnel dans l’entreprise .............................................................. 16 I.1.2. Les différents composantes du décisionnel ............................................................ 17 I.2. Décisionnel vs transactionnel ................................................................................... 18II. Le Data Warehouse .......................................................................................................... 19 II.1 Qu’est ce qu’un Data Warehouse ............................................................................. 19 II.2 Historique des Data Warehouse ............................................................................... 20 II.3 Structure des données d’un Data Warehouse ........................................................... 21 II.4 Les éléments d’un Data Warehouse ......................................................................... 22 II.5 Architecture d’un Data Warehouse .......................................................................... 25III. Modélisation des données de l’entrepôt ........................................................................... 26 III.1 La modélisation dimensionnelle et ses concepts ...................................................... 26 III.1.1 Concept de fait .................................................................................................. 27 III.1.2 Concept de dimension ....................................................................................... 27 III.1.3 Comparatif entre les tables de faits et les tables de dimensions ........................ 28 III.2 Différents modèles de la modélisation dimensionnelle ............................................. 28 III.3 Le concept OLAP ..................................................................................................... 29 III.3.1 Généralités ......................................................................................................... 29 III.3.2 Architectures des serveurs OLAP ..................................................................... 29 III.4 La navigation dans les données ................................................................................ 31 III.4.1 Slice & Dice ...................................................................................................... 31 III.4.2 Drill-down & Roll-up ......................................................................................... 32IV. Démarche de Construction d’un Data Warehouse ........................................................... 34 IV.1 Modélisation et conception du Data Warehouse ...................................................... 34 IV.1.1 Approche « Besoins d’analyse » ....................................................................... 34
  • 6. IV.1.2 Approche « Source de données » ...................................................................... 35 IV.1.3 Approche mixte ................................................................................................. 36 IV.2 Alimentation du Data Warehouse.............................................................................. 37 IV.2.1 Les phases de l’alimentation « E.T.L. » ............................................................ 37 IV.2.2 Politiques de l’alimentation ............................................................................... 38 IV.2.3 Les outils E.T.L. ................................................................................................ 40 IV.3 Mise en œuvre du Data Warehouse .......................................................................... 40 IV.4 Maintenance et expansion ........................................................................................ 42V. Conclusion ....................................................................................................................... 43 PartieII: Conception de la solution.Chapitre 1: Présentation de lorganisme daccueil.I. Présentation de SONELGAZ ............................................................................................ 46 I.1 Historique ...................................................................................................................... 46 I.1.1 Organisation du groupe SONELGAZ ................................................................... 47 I.1.2 Le groupe SONELGAZ en chiffres ...................................................................... 49 I.2 Le métier de la distribution .......................................................................................... 50 I.2.1 Organisation des sociétés de distribution ............................................................... 51 I.2.2 La clientèle de la distribution ................................................................................ 52 I.3 L’informatique au sein du groupe SONELGAZ .......................................................... 53 I.3.1 Présentation de la filiale « ELIT » ........................................................................ 53II. Conclusion ....................................................................................................................... 56Chapitre 2: Léxistant décisionnel.I. Introduction ...................................................................................................................... 58II. Etat du décisionnel au sein du groupe............................................................................... 58 II.1 Niveau Groupe .......................................................................................................... 58 II.2 Niveau Société de Distribution ................................................................................. 60 II.3 Niveau Direction de Distribution ............................................................................. 61III. Conclusion ....................................................................................................................... 62Chapitre 3:Etude des besoins.I. Introduction ....................................................................................................................... 64 I.1 Description de la démarche détude des besoins ........................................................... 65 1. Étude préliminaire des systèmes sources et interviews sommaires avec les DBA.... 65 2. Détection des postes susceptibles dêtre porteur dinformations utiles ...................... 65 3. Planification, préparation et conduite des interviews ................................................ 66 4. Autres moyens utilisés pour la détection des besoins ............................................... 67
  • 7. 5. Rédaction et validation du recueil récapitulatif des besoins ..................................... 68 I.2 Problèmes et obstacles rencontrés ................................................................................ 69II. Conclusion ....................................................................................................................... 70Chapitre 4: Conception de la zone « entreposage des données ».I. Introduction ...................................................................................................................... 73II. Processus de la modélisation dimensionnelle .................................................................. 73 II.1 Volet « vente » ......................................................................................................... 74 II.2 Volet « recouvrement » ............................................................................................ 89 II.3 Volet « suivi des affaires » ........................................................................................ 93 II.4 Volet « Suivi des abonnés » ..................................................................................... 99III. Conclusion ..................................................................................................................... 103Chapitre 5: Conception de la zone « Alimentation ».I. Introduction .................................................................................................................... 105II. Etude et planification ..................................................................................................... 105 II.1 Les sources de données ........................................................................................... 105 II.2 Détection des emplacements des données sources ................................................. 106 II.3 Définition de la périodicité de chargement .............................................................. 106III. Architecture du processus d’alimentation ...................................................................... 107IV. Processus de chargement ............................................................................................... 109 IV.1 Processus de chargement de dimension .................................................................. 110 IV.2 Processus de chargement des table de fait .............................................................. 112 IV.3 Processus de chargement particulier ....................................................................... 114 IV.3.1 Processus de chargement de la dimension « temps » ...................................... 114 IV.3.2 Processus de construction d’agrégats .............................................................. 114V. Conclusion ..................................................................................................................... 115Chapitre 6: Conception des cubes dimensionnels.I. Définition des niveaux et des hiérarchies ...................................................................... 117II. La liste des cubes ........................................................................................................... 121III. Présentation des cubes dimensionnels ........................................................................... 123IV. Conclusion ..................................................................................................................... 123Chapitre 7: Conception des Meta Data.I. Les « Meta Data » ou « méta données » de l’entrepôt ................................................... 129II. Rôle des méta données ................................................................................................... 129III. Exploitation des métas données ..................................................................................... 133 III.1 Présentation de la partie navigation ....................................................................... 133
  • 8. III.2 Présentation de la partie supervision ...................................................................... 133IV. Conclusion ..................................................................................................................... 133 Partie III: Implémentation et déploiement.I. Introduction .................................................................................................................... 135II. Implémentation .............................................................................................................. 135 II.1 Périmètre technique et fonctionnel ......................................................................... 135 II.1.1 Matériel ............................................................................................................... 135 II.1.2 Systèmes d’exploitation ...................................................................................... 135 II.2 Architecture technique de la solution ..................................................................... 136 II.3 Zone de stockage .................................................................................................... 136 II.4 Zone d’alimentation de l’entrepôt ........................................................................... 137 II.5 Zone de restitution .................................................................................................. 137III. Déploiement ................................................................................................................... 139 III.1 Déploiement de la zone d’alimentation .................................................................. 139 III.2 Déploiement de la zone de restitution .................................................................... 140IV. Conclusion …………………………………………..……………………………….141Conclusion générale et perspectives ………………...……………………………………142Bibliographie ........................................................................................................................ 145
  • 9. Résumé :Le groupe SONELGAZ, premier opérateur énergétique en Algérie, assure plusieurs missionsdans le domaine de l’énergie. Ces dernières, allant de la gestion du réseau électrique et gazierà la distribution et commercialisation de l’électricité et du gaz au profit tant des professionnelsque des particuliers, font de SONELGAZ un acteur incontournable de l’économie nationale.Le groupe SONELGAZ rencontre, dans le cadre de son activité de distribution, quelquesproblèmes dans sa politique de Reporting clientèle. Ces difficultés sont liées notamment à lalenteur et au coût de la procédure, du fait du nombre important d’intermédiaires et/ouintervenants. Ces difficultés ont rendu tout effort d’analyse vain ; et c’est pourquoi lesdirigeants du groupe aspirent à la mise en place d’un système qui procure aux décideurs lesinformations nécessaires et fiables, les aidant ainsi à pendre dans les meilleurs délais lesdécisions les plus appropriées. Dans ce contexte, et afin de répondre à ces attentesgrandissantes le groupe a sollicité sa filiale spécialisée dans les systèmes d’information et lesnouvelles technologies « Elit ». Le But recherché étant d’aller vers la mise en place d’un système s’inscrivant dans le cadredu Système de Gestion de la Clientèle « S.G.C ». Ce système sera construit autour d’unebase de données dédiée totalement aux décisionnel un « Data Warehouse » et répondant àtout les besoins d’analyse du groupe dans sa fonction de distribution. Ce présent projet a doncpour vocation première de réaliser une telle base de données.Mots clés : Data Warehouse « Entrepôt de données », Décisionnel, Business Intelligence« B.I », intégration de données, solutions « BI » Open Source. I
  • 10. Abréviations :BI : Business Intelligence.BT : Basse Tension.BP : Basse Pression.CTI : Centre de Traitement Informatique.DAP : Direction Analyses et Prévision.DAR : Direction Affaires De Régulation.DBA : Data Base Administrator.DCF : Direction Comptabilité et Finance.DCM: Direction Commercial Et Marketing.DD : Direction de Distribution.DED : Département Etudes et Développement.DGDS : Direction Générale du Développement et de la Stratégie.DIM : Dimension.DR : direction régionale(DD).DRD : Direction de Distribution Régionale.DW : Data Warehouse (Entrepôt de données).ED : Etude et développent.EDW : Entreprise Data Warehouse.EGA : Electricité et Gaz d’Algérie.ELIT : EL-djazaïr Information Technology.EPIC : Etablissement Publique à caractère Industriel et Commercial.ETL : Extract, Transform and Load (ETC).FK: Foreign Key.FTP : File Transfer Protocol.HOLAP: Hybrid On Line Analytical Process.HP : Haute Pression.HT : Haute Tension.MOLAP: Multidimensional On Line Analytical Process.MP: Moyenne Pression.MT : Moyenne Tension.OLAP : On Line Analytical Process.OLTP: On Line Transactional Process. II
  • 11. PDG: Président Directeur General.PK : Primary Key.ROLAP : Relational On Line Analytical Process.SD : Socièté de Distribution.SGC : Système de Gestion de la Clientèle.SI : Systèmes d’Information.SID: Systèmes d’Information Décisionnels.SID : Systèmes d’information de la distribution.SIAD : Systèmes d’Information d’Aide à la DécisionSGBD : Système de Gestion de Base de Données.SMTP : Server Mail Transfer Protocol.SONELGAZ : Société Nationale de l’Electricité et du GAZ.SPA : Société Par Action.SQL : Structured Query Language. III
  • 12. Liste des tableaux Partie I : Synthèse Bibliographique.Tableau I.1 : Tableau comparatif entre les systèmes transactionnels et les systèmesdécisionnels... ............................................................................................................................. 6Tableau I.2 : Tableau comparatif entre les tables de faits et les tables de dimensions............ 16Tableau I.3 : Avantages et inconvénients de l’approche « Besoins d’analyse » ..................... 23Tableau I.4 : Avantages et inconvénients de l’approche « Sources de données »................... 24 Partie II: Conception de la solution.Tableau II.1 : Le groupe SONELGAZ en chiffres ................................................................ 38Tableau II.2 : Présentation des sociétés de distribution ........................................................ 40Tableau II.3 : Tableau présentant la population a interviewé ............................................... 54Tableau II.4 : Synthétisation des besoins détectés ................................................................ 56Tableau II.5 : Tableau descriptif de la dimension « Temps » .............................................. 63Tableau II.6 : Tableau descriptif de la dimension « Client » ............................................... 65Tableau II.7 : Tableau descriptif de la dimension « Facture » .............................................. 67Tableau II.8 : Tableau descriptif de la dimension « Zone géographique » ........................... 69Tableau II.9 : Tableau descriptif de la dimension « Activité » ............................................. 70Tableau II.10 : Tableau descriptif de la dimension « Tarif » .................................................. 70Tableau II.11 : Tableau descriptif de la dimension « Energie » ............................................. 71Tableau II.12 : Liste des agrégats potentiels de l’activité « Vente » ...................................... 75Tableau II.13 : Liste des agrégats utiles de l’activité « Vente » ............................................ 75Tableau II.14 : Détection des dimensions communes entre les volets « Vente » et« Recouvrement »..................................................................................................................... 76Tableau II.15 : Tableau descriptif de la dimension « Nature » ............................................... 77Tableau II.16 : Tableau descriptif des agrégats potentiel du modèle « Recouvrement » ....... 79Tableau II.17 : Tableau descriptif des agrégats utiles du modèle « Recouvrement » ............. 79Tableau II.18 : Détection des dimensions communes entre les volets « Vente »,« Recouvrement » et « Suivi des affaires »…………………..…………….…………………80Tableau II.19 : Tableau descriptif de la dimension « Affaire» ............................................... 81Tableau II.20 : Tableau descriptif de la dimension « Type affaire » ....................................... 8Tableau II.21 : Tableau descriptif de la dimension « Phase »................................................. 83Tableau II.22 : Tableau descriptif des agrégats potentiel du modèle « suivi des affaires » .... 85Tableau II.23 : Tableau descriptif de des agrégats utiles du modèle « Suivi des affaires ».... 85Tableau II.24 : Détection des dimensions communes entre les volets « Vente »,« Recouvrement », « Suivi des affaires » et « suivi des abonnés ». ......................................... 86Tableau II.25 : Tableau descriptif de la dimension « Type abonné » ..................................... 87 IV
  • 13. Tableau II.26 : Tableau descriptif des agrégats potentiels du modèle « Suivi abonnés » ....... 89Tableau II.27 : Tableau descriptif des agrégats utiles du modèle « Suivi abonnés ».............. 89Tableau II.28 : Tableau donnant les nivaux hiérarchiques de chaque dimension ................... 10Tableau II.29 : Listes des cubes dimensionnels .................................................................... 107 V
  • 14. Liste des figures Figure I.1 : Le décisionnel au sein du système d’information ............................................ 9 Figure I.2 : Les différentes composantes du décisionnel .................................................... 5 Figure I.3 : Historique des bases de données décisionnelles ............................................... 8 Figure I.4 : Structure des données d’un Data Warehouse ................................................... 9 Figure I.5 : Les Data Mart dans un entrepôt de données selon l’architecture proposée par B. Inmon dite Entreprise Data Warehouse ........................................................................... 11 Figure I.6 : Les Data Mart dans un entrepôt de données selon l’architecture proposée par R. kimball dite approche bus ................................................................................................ 13 Figure I.7 : Architecture globale d’un Data Warehouse.................................................... 13 Figure I.8 : Considération d’un sujet d’analyse comme un cube à plusieurs dimensions . 14 Figure I.9 : Un modèle dimensionnel typique ................................................................... 15 Figure I.10 : Principe de l’architecture MOLAP ................................................................. 18 Figure I.11 : Principe de l’architecture ROLAP .................................................................. 18 Figure I.12 : Exemple de Slicing ......................................................................................... 20 Figure I.13 : Exemple de Dicing ......................................................................................... 20 Figure I.14 : Exemple de Roll up ........................................................................................ 21 Figure I.15 : Exemple de Drill Down .................................................................................. 21 Figure I.16 : Illustration de l’approche « Besoin d’analyse » grâce au cycle de vie dimensionnel de kimball ....................................................................................................... 22 Figure I.17 : Illustration de l’approche « source de données » grâce au cycle de développement du Data Warehouse de Inmon ..................................................................... 23 Figure I.18 : Illustration de l’approche mixte ...................................................................... 24 Figure I.19 : Objectif de qualité de données dans un processus E.T.L ............................... 27 Figure II.1 : Planification de la conduite du projet ............................................................. 34 Figure II.2 : Organigramme représentant l’organisation du Groupe SONELGAZ ............ 37 Figure II.3 : Evolution du chiffre d’affaire du groupe publiée dans le rapport d’activité de l’année 2008 ………………………………………………………………………………38 Figure II.4 : Répartition du chiffre d’affaire publiée dans le rapport d’activité de l’année 2008………… ...................................................................................................................... 39 Figure II.5 : Organisation des sociétés de distribution ....................................................... 40 Figure II.6 : Organisation des directions de distribution .................................................... 41 Figure II.7 : Organisation de la filiale ELIT ....................................................................... 44 Figure II.8 : Organisation de la direction d’étude et de développement............................. 44 Figure II.9 : Diagramme d’activité modélisant l’édition de rapport pour le niveau groupe48 VI
  • 15. Figure II.10 : La place de l’étape de définition des besoins dans un projet DataWarehouse………………………………………………………………………………….52Figure II.11 : Analyse des priorités du cas de la distribution « SONELGAZ »................ 60Figure II.12 : La dimension du Temps de l’activité « Vente » ......................................... 64Figure II.13 : La dimension client de l’activité « Vente » ................................................ 65Figure II.14 : La dimension facture de l’activité « Vente » .............................................. 68Figure II.15 : La dimension zone de l’activité « Vente ».................................................. 70Figure II.16 : La dimension activité de l’activité « Vente » ............................................. 70Figure II.17 : La dimension Tarif de l’activité « Vente » ................................................. 70Figure II.18 : La dimension énergie de l’activité « Vente » ............................................. 71Figure II.19 : Modèle en étoile de l’activité « Vente » ..................................................... 74Figure II.20 : La dimension Nature de l’activité « Recouvrement »................................. 78Figure II.21 : Modèle en étoile de l’activité « Recouvrement » ....................................... 79Figure II.22 : La dimension affaire de l’activité «Suivi des affaires ».............................. 83Figure II.23 : La dimension type affaire de l’activité « Suivi des affaires »..................... 82Figure II.24 : La dimension phase de l’activité « suivie des affaires » ............................. 83Figure II.25 : Modèle en étoile de l’activité « Suivie des affaires » ................................. 84Figure II.26 : La dimension type abonné de l’activité « Suivi des abonné » .................... 87Figure II.27 : Modèle en étoile de l’activité « Suivi des abonné » ................................... 88Figure II.28 : Architecture global du processus E.T.L ...................................................... 95Figure II.29 : Diagramme d’activité du processus d’alimentation .................................... 94Figure II.30 : Diagramme d’activité du processus de chargement de dimension ............. 98Figure II.31 : Diagramme d’activité du processus de chargement de fait......................... 99Figure II.32 : Cube dimensionnel « Suivi des ventes ». .................................................. 109Figure II.33 : Cube dimensionnel « Suivi des ventes et des consommations ». ............. 110Figure II.34 : Cube dimensionnel « Suivi des abonnés ». ............................................... 111Figure II.35 : Cube dimensionnel « Suivi des recouvrements ». .................................... 111Figure II.36 : Cube dimensionnel « Suivi des affaires ». ................................................ 112Figure II.37 : Diagramme de classe des métadonnées .................................................... 115Figure II.38 : DCU navigation dans les métadonnées et administration des MAJutilisateurs………… ........................................................................................................... 116Figure II.39 : DCU de supervision. ................................................................................. 117Figure II.40 : Architecture technique de la solution. ...................................................... 121Figure II.41 : Digramme de déploiement de la zone d’alimentation. ............................. 125Figure II.42 : Diagramme de déploiement de la zone de restitution. .............................. 126 VII
  • 16. Introduction générale 8
  • 17. Contexte général C’est dans un environnement fortement complexe et hautement concurrentielqu’évolue la majeure partie, si ce n’est la totalité, des entreprises. Ce climat de forteconcurrence exige de ces entreprises une surveillance très étroite du marché afin de ne pas selaisser distancer par les concurrents et cela en répondant, le plus rapidement possible, auxattentes du marché, de leur clientèle et de leurs partenaires. Pour se faire, les dirigeants de l’entreprise, quelque en soit d’ailleurs le domained’activité, doivent être en mesure de mener à bien les missions qui leur incombent en lamatière. Ils devront prendre notamment les décisions les plus opportunes. Ces décisions, quiinflueront grandement sur la stratégie de l’entreprise et donc sur son devenir, ne doivent pasêtre prises ni à la légère, ni de manière trop hâtive, compte tenu de leurs conséquences sur lasurvie de l’entreprise. Il s’agit de prendre des décisions fondées, basées sur des informationsclaires, fiables et pertinentes. Le problème est de savoir donc comment identifier et présenterces informations à qui de droit, sachant par ailleurs que les entreprises croulent d’une partsous une masse considérable de données et que d’autre part les systèmes opérationnels« transactionnels » s’avèrent limités, voire inaptes à fournir de telles informations etconstituer par la même un support appréciable à la prise de décision. C’est dans ce contexte que les « systèmes décisionnels » ont vu le jour. Ils offrentaux décideurs des informations de qualité sur lesquelles ils pourront s’appuyer pour arrêterleurs choix décisionnels. Pour se faire, ces systèmes utilisent un large éventail de technologieset de méthodes, dont les « entrepôts de données » (Data Warehouse) représentent l’élémentprincipal et incontournable pour la mise en place d’un bon système décisionnel. De part sa dimension économique et sa position sur le marché énergétique algérien,l’activité journalière de la SONELGAZ génère des données complexes et volumineuses. Cesdonnées représentent une source précieuse d’informations, qui serait à même d’améliorer defaçon significative le processus de prise de décision. Cependant, ces données ne sont pasexploitées de manière satisfaisante, hypothéquant ainsi le processus de prise de décision àtous les niveaux du groupe. Le présent projet tend à la mise en place d’un système en mesure de consolider lesdonnées issues des systèmes transactionnels, et d’offrir des informations de qualité pour lesdécideurs. Il s’agit en fait de mettre à la disposition des décideurs des données à même deles éclairer et leur faciliter une prise de décision prompte en connaissance de cause. Un telsystème requiert la mise en place d’un entrepôt de données fiables contenant les informationsnécessaires à l’accomplissement des processus décisionnels. 9
  • 18. 1. Problématique Le groupe SONELGAZ est l’opérateur historique et leader du domaine énergétique enAlgérie, notamment dans le domaine de la distribution de l’électricité et du gaz pour lesprofessionnels et les particuliers. Appelé à interagir avec ses clients sur différentes phases de la distribution (demandede branchement, facturation, résiliation,…etc.), le groupe s’est doté, dans un souci de suivi dela clientèle et de gestion de la distribution, d’un « Système de Gestion de la Clientèle –S.G.C.- » constitué de 35 applications, développées en interne et exploité par plus de 2900utilisateurs. Ce système est déployé dans chacune des 58 directions de distributions « D.D. »exploitant une base de donnée décentralisée au niveau de chaque « D.D. ». Dans un pareil contexte, la plus simple des opérations d’analyse devient une tâcheardue. En effet, les sociétés de distributions « SD » se trouvent dans l’incapacité de faire desanalyses fiables, efficaces et à des moments opportuns sans engager des moyens considérablessur des périodes plus ou moins longues. Ainsi, les principales difficultés rencontrées peuventêtre résumées en :• Difficultés dans l’élaboration des rapports d’activité : L’élaboration des rapports d’activité fait intervenir, généralement, plusieurs intermédiaires. En effet, à chaque fois qu’il est nécessaire d’élaborer un rapport d’activité , il faudra procéder d’abord à l’ extraction les données à partir des 58 bases de données installées au niveau des directions de distribution, pour les acheminer ensuite manuellement vers une structure centralisée, qui en fera enfin la consolidation. Il s’agit là d’une procédure lourde outre les éventuelles incohérences et erreurs. Les retards enregistrés, parfois, font que le rapport d’activité est élaboré sur la base d’une consolidation antérieure, en sachant pertinemment que les données ne sont pas à jour.• Lenteur de la procédure de Reporting : La politique de Reporting actuelle, qui du reste est quasi manuelle, connait des lenteurs qui n’arrangent pas les décideurs. Ceux ci ont besoin d’informations fiables et dans des délais raisonnables. À titre indicatif, l’édition d’un rapport national peut prendre, en moyenne, plus d’un mois ce qui est plus que pénalisant pour une bonne prise de décision.• Coût de la procédure de Reporting1 : la procédure de Reporting est jugé très couteuse pour l’entreprise, et cela est principalement du au nombre d’intervenant et des moyens mis en place pour cette dernière.• Insuffisance du module « Statistique » : Afin de produire et offrir un moyen de suivi des activités de la distribution, un module « Statistique » a été développé et intégré dans le système « SGC ». Ce dernier fournit des états statistiques permettant, aux décideurs de niveau D.D., l’analyse et la prise de décision. Cependant, ce module connait quelques1 Voir annexe A 10
  • 19. problèmes dû au fait qu’il interroge directement la base de données en production. En effet le lancement de la production de n’importe quel rapport du module pénalise le système. Pour éviter cela le module n’est accessible qu’au chef du CTI de la DD. 2. Objectifs du projet Afin de palier aux problèmes précédemment cités, le groupe a initié, à travers sa filialeElit, le présent projet. Ce projet a pour but d’introduire, en premier lieu, une informatique décisionnelle ausein du groupe, tout en conférant aux décideurs un support fiable pour une meilleure prise dedécision. Ainsi, les principaux objectifs assignés au projet sont : • La réduction de la durée globale de l’élaboration des rapports, en essayant de ramener cette durée, au moins, en dessous de la barre des 48 heures. • La Réduction des coûts de la procédure de Reporting actuelle. • La réduction du nombre d’intervenants lors de la production de rapports. • Offrir aux décideurs et aux analystes la possibilité de faire des analyses appropriées. • Offrir des informations fiables, cohérentes et pertinentes, contenant la logique business souhaitée. 11
  • 20. Planification et conduite du projet L’initiation de tout projet nécessite une phase de planification. Celle out Celle-ci permetde définir les tâches à réaliser, maîtriser les risques et rendre compte de l’état d’avancementdu projet. « Planifier optimise ainsi les chances de réussite dun projet en améliorant laproductivité grâce à une meilleure maîtrise de la qualité. » [Soler, 2001]. Pour garantir le bon déroulement du projet, tout en respectant les délais, nous avonsélaboré une planification globale de conduite du projet. Le diagramme suivant décrit cetteplanification ainsi que l’ordonnancement prévu des phases du projet. Conception E.T.L Figure : Planification et conduite du projet. Afin de présenter notre travail, le présent mémoire est organisé en trois parties et seprésente comme suit : Après une introduction générale dans laquelle nous présentons le contexte général duprojet, ainsi que la problématique et les objectifs visés. La première partie présente les aspectsthéoriques du domaine des systèmes d’information d’aide à la décision, en évoquant leursdéfinitions et les concepts de bases relatifs aux « entrepôts de données » et à la modélisationdimensionnelle. 12
  • 21. Dans la deuxième partie, nous présentons le travail réalisé au sein du GroupeSONELGAZ à travers les six suivants chapitres: Le chapitre un, présente l’organisme d’accueil, sa structure organisationnelle, sonactivité et la culture de l’entreprise en matière d’utilisation des technologies de l’information. Le chapitre deux a pour vocation de présenter l’existant décisionnel au sein del’entreprise et selon différents niveaux de prise de décision. Le chapitre trois présente une synthèse de la collecte des besoins des utilisateurs, ainsique son déroulement. Le chapitre quatre contient la conception de la partie d’entreposage de notre solution.Il présente entre autre les modèles dimensionnels des activités recensées. Le chapitre cinq à pour but de présenter la conception de la zone d’alimentation, ainsique les stratégies adoptées. Le chapitre six, quant à lui, donne la conception des cubes dimensionnels en détaillantles différentes caractéristiques de chaque cube (dimensions, mesurables et hiérarchies). La troisième partie décrie l’architecture globale de la solution, et cela en présentant lesdifférents outils intégrés et les volets de la solution développés. Elle décrit aussi la manièredont se passe le déploiement de la solution. Une conclusion générale est proposée afin de synthétiser le travail réalisé et de citerles perspectives du projet. 13
  • 22. Partie I : Synthèse bibliographique« Un entrepôt de données ne sachète pas, il se construit. »Bill Inmon 14
  • 23. I. Introduction Toutes les entreprises du monde disposent d’une masse de données plus ou moinsconsidérable. Ces informations proviennent soit de sources internes (générées par leurssystèmes opérationnels au fil des activités journalières), ou bien de sources externes (web,partenaire, .. etc.). Cette surabondance de données, et l’impossibilité des systèmes opérationnels de lesexploiter à des fins d’analyse conduit, inévitablement, l’entreprise à se tourner vers unenouvelle informatique dite décisionnelle qui met l’accent sur la compréhension del’environnement de l’entreprise et l’exploitation de ces données à bon escient.En effet, les décideurs de l’entreprise ont besoin d’avoir une meilleure vision de leurenvironnement et de son évolution, ainsi, que des informations auxquelles ils peuvent se fier.Cela ne peut se faire qu’en mettant en place des indicateurs « business » clairs et pertinentspermettant la sauvegarde, l’utilisation de la mémoire de l’entreprise et offrant à ses décideursla possibilité de se reporter à ces indicateurs pour une bonne prise de décision. Le « Data Warehouse », « Entrepôt de données » en français, constitue, dans cesconditions, une structure informatique et une fondation des plus incontournables pour la miseen place d’applications décisionnelles. Le concept de Data Warehouse, tel que connu aujourd’hui, est apparu pour la premièrefois en 1980 ; l’idée consistait alors à réaliser une base de données destinée exclusivement auprocessus décisionnel. Les nouveaux besoins de l’entreprise, les quantités importantes dedonnées produites par les systèmes opérationnels et l’apparition des technologies aptes à samise en œuvre ont contribué à l’apparition du concept « Data Warehouse » comme supportaux systèmes décisionnels. I.1. Les systèmes décisionnels La raison d’être d’un entrepôt de données, comme évoqué précédemment, est la mise enplace d’une informatique décisionnelle au sein de l’entreprise. Pour cela il serait assezintéressant de définir quelques concepts clés autour du décisionnel. Afin de mieux comprendre la finalité des systèmes décisionnels, nous nous devons de lesplacer dans leurs contextes et rappeler ce qu’est un système d’information. «Le système d’information est l’ensemble des méthodes et moyens de recueil de contrôleet de distribution des informations nécessaires à l’exercice de l’activité en tout point del’organisation. Il a pour fonction de produire et de mémoriser les informations, de l’activitédu système opérant (système opérationnel), puis de les mettre à disposition du système dedécision (système de pilotage)»[Le Moigne, 1977]. Les différences qui existent entre le système de pilotage et le système opérationnel, dupoint de vue fonctionnel ou des tâches à effectuer, conduit à l’apparition des « systèmesd’information décisionnels » (S.I.D.). Ces différences seront clairement illustrées un peu plusloin dans notre document. 15
  • 24. Les origines des SID remontent au début de l’informatique et des systèmes d’informationqui ont, tous deux, connu une grande et complexe évolution liée notamment à la technologie.Cette évolution se poursuit à ce jour2.Parmi les différentes définitions du décisionnel « business intelligence B.I. » qui ont étédonnées on trouve : • "Le Décisionnel est le processus visant à transformer les données en informations et, par lintermédiaire dinterrogations successives, transformer ces informations en connaissances." [Dresner, 2001]. I.1.1. La place du décisionnel dans l’entreprise: Figure I.1 : Le décisionnel au sein du Système d’information [Goglin, 1998] nnel 1998]. La figure ci-dessus illustre parfaitement la place qu revient au décisi dessus qui décisionnel au seind’une entreprise. Cette place, comprend plusieurs fonctions clés de l’entreprise. Les finalités ,décisionnelles, étant différentes selon le poste et la fonction occupée on pour but occupée, ontd’engendrer plusieurs composantes.2 Synthétisation à partir de la thèse de Bouzghoub A. « Modélisation des entrepôts de données XML:application au domaine de la sécurité sociale » [Bouzghoub, 2008]. 16
  • 25. I.1.2. Les différentes composantes du décisionnel s En relation étroite avec les nouvelles technologies de l’information et destélécommunications, le système décisionnel se manifeste à différents niveaux selon leurs eutilités et leurs missions principales comme illustré dans la figure suivante : principales, Figure I.2 : Les différentes composantes du décisionnel [Goglin, 1998] 1998]. 17
  • 26. I.3. Décisionnel vs transactionnel Le tableau suivant résume de façon non exhaustive les différences qu’il peut y avoirentre les systèmes transactionnels et les systèmes décisionnels selon les données et l’usage faitdes systèmes. Différence Systèmes transactionnels SID Orienté applications Orienté thèmes et sujets Situation instantanée Situation historique par les données Donnée détaillées et codées non Informations agrégées cohérentes redondantes souvent avec redondance Données changeantes constamment Informations stables et synchronisées dans le temps Pas de référentiel commun Un référentiel unique Assure l’activité au quotidien Permet l’analyse et la prise de décision Pour les opérationnels Pour les décideurs Mises à jour et requêtes simples Lecture unique et requêtes complexes L’usage transparentes Temps de réponse immédiats Temps de réponse moins critiques Faibles volumes à chaque transaction Large volume manipulé Conçu pour la mise à jour Conçue pour l’extraction Usage maîtrisé Usage aléatoire Tableau I.1 : Tableau comparatif entre les systèmes transactionnels et les systèmes décisionnels. Ces différences font ressortir la nécessité de mettre en place un système répondant auxbesoins décisionnels. Ce système n’est rien d’autre que le « Data Warehouse ». 18
  • 27. II. Le Data Warehouse II.1 Qu’est ce qu’un Data Warehouse Bill Inmon définit le Data Warehouse, dans son livre considéré comme étant la référencedans le domaine “Building the Data Warehouse” [Inmon, 2002] comme suit: « Le Data Warehouse est une collection de données orientées sujet, intégrées, nonvolatiles et évolutives dans le temps, organisées pour le support d’un processus d’aide àla décision. » Les paragraphes suivants illustrent les caractéristiques citées dans la définition d’Inmon.Orienté sujet : le Data Warehouse est organisé autour des sujets majeurs de l’entreprise,contrairement à l’approche transactionnelle utilisée dans les systèmes opérationnels, qui sontconçus autour d’applications et de fonctions telles que : cartes bancaires, solvabilité client…,les Data Warehouse sont organisés autour de sujets majeurs de l’entreprise tels que : clientèle,ventes, produits…. Cette organisation affecte forcément la conception et l’implémentation desdonnées contenues dans le Data Warehouse. Le contenu en données et en relations entre ellesdiffère aussi. Dans un système opérationnel, les données sont essentiellement destinées àsatisfaire un processus fonctionnel et obéit à des règles de gestion, alors que celles d’un DataWarehouse sont destinées à un processus analytique.Intégrée : le Data Warehouse va intégrer des données en provenance de différentes sources.Cela nécessite la gestion de toute incohérence.Evolutives dans le temps : Dans un système décisionnel il est important de conserver lesdifférentes valeurs d’une donnée, cela permet les comparaisons et le suivi de l’évolution desvaleurs dans le temps, alors que dans un système opérationnel la valeur d’une donnée estsimplement mise à jour. Dans un Data Warehouse chaque valeur est associée à un moment« Every key structure in the data warehouse contains - implicitly or explicitly -an element oftime » [Inmon, 2000].Non volatiles : c’est ce qui est, en quelque sorte la conséquence de l’historisation décriteprécédemment. Une donnée dans un environnement opérationnel peut être mise à jour ousupprimée, de telles opérations n’existent pas dans un environnement Data Warehouse.Organisées pour le support d’un processus d’aide à la décision : Les données du DataWarehouse sont organisées de manière à permettre l’exécution des processus d’aide à ladécision (Reporting, Data Mining…). 19
  • 28. II.2 Historique des Data Warehouse L’origine du concept « Data Warehouse » D.W (entrepôt de données en français) remonteaux années 80, durant lesquelles un intérêt croissant au système décisionnel a vu le jour, dûessentiellement à l’émergence des SGBD relationnel et la simplicité du modèle relationnel etla puissance offerte par le langage SQL, Au début, le Data Warehouse n’était rien d’autre qu’une copie des données du systèmeopérationnel prise de façon périodique, dédiée à un environnement de support à la prise dedécision. Ainsi, les données étaient extraites du système opérationnel, stockées dans unenouvelle base de données «concept d’infocentre », le motif principal étant de répondre auxrequêtes des décideurs sans pour autant altérer les performances des systèmes opérationnels. Le Data Warehouse, tel qu’on le connaît actuellement, n’est plus vu comme une copie-ou un cumul de copies prises de façon périodique- des données du système opérationnel. Ilest devenu une nouvelle source d’information, alimenté avec des données recueillies etconsolidées des différentes sources internes et externes. Entrepôt de données Infocentre bases de données opérationnelles 1970 1980 1990 Figure I.3 : évolution des bases de données décisionnelles. 20
  • 29. II.3 Structure des données d’un Data Warehouse Le Data Warehouse a une structure bien définie, selon différents niveaux d’agrégation et de détail des données. Cette structure est définie par Inmon [Inmon, 2000] comme suit : Données fortement agrégéesM Données agrégéesETADONN Données détailléesÉES Données détaillées archivées Figure I.4 : Structure des données d’un Data Warehouse. Données détaillées : ce sont les données qui reflètent les événements les plus récents, fréquemment consultées, généralement volumineuses car elles sont d’un niveau détaillé. Données détaillées archivées : anciennes données rarement sollicitées, généralement stockées dans un disque de stockage de masse, peu coûteux, à un même niveau de détail que les données détaillées. Données agrégées : données agrégées à partir des données détaillées. Données fortement agrégées : données agrégées à partir des données détaillées, à un niveau d’agrégation plus élevé que les données agrégées. 21
  • 30. Meta données : ce sont les informations relatives à la structure des données, les méthodesd’agrégation et le lien entre les données opérationnelles et celles du Data Warehouse. Lesmétadonnées doivent renseigner sur : • Le modèle de données, • La structure des données telle qu’elle est vue par les développeurs, • La structure des données telle qu’elle est vue par les utilisateurs, • Les sources des données, • Les transformations nécessaires, • Suivi des alimentations, II.4 Les éléments d’un Data Warehouse L’environnement du Data Warehouse est constitué essentiellement de quatrecomposantes : les applications opérationnelles, la zone de préparation des données, laprésentation des données et les outils d’accès aux données.Les applications opérationnelles : ce sont les applications du système opérationnel del’entreprise et dont la priorité est d’assurer le fonctionnement de ce dernier et sa performance.Ces applications sont extérieures au Data Warehouse.Préparation des données : la préparation englobe tout ce qu’il y a entre les applicationsopérationnelles et la présentation des données. Elle est constituée d’un ensemble de processusappelé ETL, « Extract, transform and Load », les données sont extraites et stockées pour subirles transformations nécessaires avant leur chargement. « Un point très important, dans l’aménagement d’un entrepôt de données, estd’interdire aux utilisateurs l’accès à la zone de préparation des données, qui ne fournit aucunservice de requête ou de présentation » [Kimball, 2002].Présentation des données : c’est l’entrepôt où les données sont organisées et stockées. Si lesdonnées de la zone de préparation sont interdites aux utilisateurs, la zone de présentation esttout ce que l’utilisateur voit et touche par le biais des outils d’accès. L’entrepôt de données est constitué d’un ensemble de Data Mart. Ce dernier est définicomme étant une miniaturisation d’un Data Warehouse, construit autour d’un sujet précisd’analyse ou consacré à un niveau départemental3. Cette différence de construction, autour d’un sujet ou au niveau départemental, définitla façon d’implémentation du Data Mart au niveau de l’entrepôt. On distingue, en effet, deuxarchitectures internes du Data Warehouse :3 Synthétisation [Chuck, 1998] page 86. 22
  • 31. 1. Data Mart indépendant Les Data Mart sont des versions miniaturisées du Data Warehouse au niveaudépartemental, alimentées par le Data Warehouse et basées sur les besoins départementaux en s sinformations [Inmon, 2002].Figure I.5 : les Data Mart dans un entrepôt de données selon l’architecture Entreprise Data Warehouse (E.D.W) [Inmon, 2002]. 23
  • 32. 2. Data Mart interconnectés Les Data Mart sont construi autour de sujets, interconnectés grâce aux tables des es construitsfaits contenues dans le Data Warehouse, ce dernier se compose alors des Data Mart et cestables des faits, appelées bus4.Figure I.6 : les Data Mart dans un entrepôt de données selon l’architecture bus de données [Kimball, 2002].Zone d’outils d’accès : c’est l’ensemble des moyens fournis aux utilisateurs du DataWarehouse pour exploiter la zone de présentation des données en vue de la prise de décision.Ces outils varient des simples requêtes ad hoc aux outils permettant l’application de forage dedonnées plus complexes. Environ 80 à 90% des utilisateurs sont desservis par des applications .d’analyses préfabriquées, consista essentiellement en des requêtes préétablies. ant s.4 Appellation proposée par R. Kimball dans son ouvrage [Kimball, 2002]. 24
  • 33. II.5 Architecture d’un Data Warehouse Après avoir exposé et défini chacun des éléments constituant l’environnement d’un DataWarehouse, il serait intéressant de connaitre le positionnement de ces éléments dans unearchitecture globale d’un Data Warehouse : Figure I.7 : Architecture globale d’un Data Warehouse5.5 http://www.formations-sas.fr/data-warehouse 25
  • 34. III. Modélisation des données de l’entrepôt III.1 La modélisation dimensionnelle et ses concepts Les Data Warehouse sont destinés à la mise en place de systèmes décisionnels. Cessystèmes, devant répondre à des objectifs différents des systèmes transactionnels, ont faitressortir très vite la nécessité de recourir à un modèle de données simplifié et aisémentcompréhensible. La modélisation dimensionnelle permet cela. Elle consiste à considérer unsujet d’analyse comme un cube à plusieurs dimensions, offrant des vues en tranches ou desanalyses selon différents axes. Figure I.8 : Considération d’un sujet d’analyse comme un cube à plusieurs dimensions. En plus de la perception intuitive qu’offre la modélisation dimensionnelle, celle-ci estréputée pour ses performances élevées. La nomination « schéma des jointures en étoile » a longtemps été adoptée pour décrireun modèle dimensionnel. Cette nomination est due au fait que le diagramme qui représente unmodèle dimensionnel ressemble à une étoile, avec une grande table centrale et un jeu depetites tables auxiliaires disposées en étoile autour de la table centrale. Celle-ci est appeléetable de faits et les autres tables sont appelées tables de dimensions. La figure suivanteillustre untel modèle : 26
  • 35. Figure I.9 : Un modèle dimensionnel typique [Kimball, 1996]. III.1.1 Concept de fait Une table de faits est la table centrale d’un modèle dimensionnel, où les mesures deperformances sont stockées. Une ligne d’une table de faits correspond à une mesure. Cesmesures sont généralement des valeurs numériques, additives ; cependant des mesurestextuelles peuvent exister mais sont rares. Le concepteur doit faire son possible pour faire desmesures textuelles des dimensions, car elles peuvent êtres corrélées efficacement avec lesautres attributs textuels de dimensions. Une table de faits assure les liens plusieurs à plusieurs entre les dimensions. Ellescomportent des clés étrangères, qui ne sont autres que les clés primaires des tables dedimension. III.1.2 Concept de dimension Les tables de dimension sont les tables qui raccompagnent une table de faits, ellescontiennent les descriptions textuelles de l’activité. Une table de dimension est constituée denombreuses colonnes qui décrivent une ligne. C’est grâce à cette table que l’entrepôt dedonnées est compréhensible et utilisable; elles permettent des analyses en tranches et en dés. Une dimension est généralement constituée : d’une clé artificielle, une clé naturelle etdes attributs. « Une table de dimension établit l’interface homme / entrepôt, elle comporte une cléprimaire » [Kimball, 2002]. 27
  • 36. III.1.3 Comparatif entre les tables de faits et les tables de dimensions Le tableau suivant récapitule les différences au niveau des données de ces tables : Tables de faits Tables de dimensionsStructure Peu de colonnes beaucoup de lignes Peu de lignes beaucoup de colonnesDonnées Mesurable, généralement numérique Descriptives généralement textuellesRéférentiel Plusieurs clés étrangères Une clé primaireValeur Prend de nombreuses valeurs Plus ou moins constantesManipulation Participe à des calculs Participe à des contraintesSignification Valeurs de mesure DescriptiveRôle Assure les relations entre les Assure l’interface homme / entrepôt dimensions de données Tableau I.2 : Tableau comparatif entre les tables de faits et les tables de dimensions. III.2 Différents modèles de la modélisation dimensionnelle Modèle en étoile : comme indiqué précédemment, ce modèle se présente comme uneétoile dont le centre n’est autre que la table des faits et les branches sont les tables dedimension. La force de ce type de modélisation est sa lisibilité et sa performance. Modèle en flocon : identique au modèle en étoile, sauf que ses branches sont éclatéesen hiérarchies. Cette modélisation est généralement justifiée par l’économie d’espace destockage, cependant elle peut s’avérer moins compréhensible pour l’utilisateur final, et trèscouteuse en terme de performances. Modèle en constellation : Ce n’est rien d’autre que plusieurs modèles en étoile liésentre eux par des dimensions communes. 28
  • 37. III.3 Le concept OLAP III.3.1 Généralités Le terme OLAP (On-Line Analytical Processing) désigne une classe de technologiesconçue pour l’accès aux données et pour une analyse instantanée de ces dernières, dans le butde répondre aux besoins de Reporting et d’analyse. R. Kimball définit le concept « OLAP » comme «Activité globale de requêtage et deprésentation de données textuelles et numériques contenues dans l’entrepôt de données; Styled’interrogation spécifiquement dimensionnel » [Kimball, 2005]. C’est en continuant sur sa lancée, qui lui a permis de définir le model OLTP pour lesbases de données relationnelles, que le concept OLAP fut introduit et défini6 en 1993 par E.FCodd, le père des bases de données relationnelles, dans un document technique portant le titrede « Providing OLAP (On-Line Analytical Processing) to User-Analysts : An IT Man-date »[Codd, 1993]. III.3.2 Architectures des serveurs OLAP Le noyau d’un système OLAP est son serveur. Ces serveurs sont classés selon la politiquerégissant l’architecture du serveur. Ainsi, ces architectures peuvent être distinguées commesuit: III.3.2.1 Les systèmes à architecture MOLAP Ces systèmes MOLAP « Multidimentional On-line Analytical Processing » sontconçus exceptionnellement pour l’analyse multidimensionnelle. R. Kimball définit ces systèmes comme étant un « Ensemble d’interfaces utilisateur,d’applications et de technologies de bases de données propriétaire dont l’aspect dimensionnelest prépondérant » [Kimball, 2005]. Ainsi donc cette base adopte réellement la structure multidimensionnelle, exploitant dece fait ces capacités au maximum. En effet MOLAP offre des temps d’accès optimisés et celaen prédéfinissant les opérations de manipulation et de chemin d’accès prédéfinis. Autre caractéristique du MOLAP c’est qu’il agrège tout par défaut, pénalisant du couple système lorsque la quantité de données à traiter augmente. On parle généralement devolume de l’ordre du giga-octet pas plus.6 Cette définition passe par l’introduction de 12 règles. Six autres règles furent par la suite, en 1995, ajoutéesaux 12 précédentes et le terme « règles » remplacé par dispositif «features » par le même auteur à savoirCodd (Voir annexe B). 29
  • 38. Data Warehouse Moteur MOLAP Aide à la décision Données Traitements Présentation Stockage des Rapports données détaillées (et Multi-Dimensionnel agrégées) Figure I.10 :Principe de l’architecture MOLAP [Nakache, 1998]. III.3.2.2 Les systèmes à architecture ROLAP « Ensemble d’interfaces utilisateurs et d’applications qui donnent une visiondimensionnelle à des bases de données relationnelles » [Kimball, 2005]. Les systèmes ROLAP « Relationnel On-line Analytical Processing » sont en mesurede simuler le comportement d’une SGBD multidimensionnel en exploitant un SGBDrelationnel. L’utilisateur aura ainsi l’impression d’interroger un cube multidimensionnel alorsqu’en réalité il ne fait qu’adresser des requêtes sur une base de données relationnelles. ROLAP n’agrège rien. Les règles d’agrégations sont crées au préalable et représentéesdans une table relationnelle ce qui cause une lourdeur d’administration mais confère unecertaine performance et un gage de cohérence lors de l’utilisation. Cette structure est généralement adoptée dans le but de se dispenser de l’acquisitiond’un SGBD relationnel. Data Warehouse Moteur ROLAP Aide à la décision Données Traitements Présentation Stockage des Génération de plans Rapports données détaillées (et dexécution SQL Multi-Dimensionnel agrégées) et afin dobtenir des des méta-données fonctionnalités OLAP. Figure I.11 : Principe de l’architecture ROLAP [Nakache, 1998]. 30
  • 39. III.2.2.3 Les systèmes à architecture HOLAP Les systèmes HOLAP « Hybride On-line Analytical Processing » sont une sorte decompromis entre les différents systèmes précités. Cette combinaison donne à ce type desystème les avantages du ROLAP et du MOLAP en utilisant tour à tour l’un ou l’autre selonle type de données.III.2.2.4 Autres architecture OLAP Bien que les architectures évoquées ci-dessus soient les plus répandues et les plusadoptées par les fournisseurs de solutions OLAP, d’autres systèmes se basent sur desarchitectures différentes telles que l’architecture OOLAP « Object On-line AnalyticalProcessing », ou alors DOLAP « Desktop On-line Analytical Processing » qui décrit unecatégorie de produits qui ne sont pas nécessairement connectés à un serveur et qui s’appuientsur une source de données (un cube) construites, stockées et exploitées en local sur la machinede l’utilisateur. III.4 La navigation dans les données Une fois que le serveur OLAP a construit le cube multidimensionnel « ou simulé cecube selon l’architecture du serveur », plusieurs opérations sont possibles sur ce dernieroffrant ainsi la possibilité de naviguer dans les données qui le constituent. Ces opérations denavigation « Data Surfing » doivent être, d’une part, assez complexes pour adresserl’ensemble des données et, d’autre part, assez simples afin de permettre à l’utilisateur decirculer de manière libre et intuitive dans le modèle dimensionnel. Afin de répondre à ces attentes, un ensemble de mécanismes est exploité, permettantune navigation par rapport à la dimension et par rapport à la granularité d’une dimension. III.4.1 Slice & Dice Le « Slicing » et le « Dicing » sont des techniques qui offrent la possibilité de fairedes tranches « trancher » dans les données par rapport à des filtres de dimension bien précis,se classant de fait comme des opérations liées à la structure « se font sur les dimensions ». Ladifférence entre eux se manifestent dans le fait que : Le Slicing consiste à faire une sélection de tranches du cube selon des prédicats etselon une dimension « filtrer une dimension selon une valeur » [Chouder, 2008]. 31
  • 40. Figure I I.12 : Exemple de Slicing.Le Dicing, quant à lui, peut être vu comme étant une extraction d’un sous cube. Figure I I.13 : Exemple de Dicing. III.4.2 Drill-down & Roll-up up Ces méthodes, appelées aussi « forage vers le bas/vers le haut », sont les méthodes lesplus répandues pour une navigation dans un entrepôt de données. Elles consistent àreprésenter les données du cube à un niveau de granularité inf rieur, dans le cas du « Drill - inférieur,down », ou un niveau supérieur, c’est le « Roll-up ». En somme, ces deux opérationspermettent de contrôler le niveau de détail des données du cube. 32
  • 41. Ces opérations ne sont pas aussi faciles à implémenter car basées sur la notion d’unebonne hiérarchisation des attributs d’une dimension et la différenciation entre tous les niveauxde hiérarchie disponibles dans les différentes dimensions. Figure I.14 : Exemple de Roll up « moins de détails sur les années». Figure I.15 : Exemple de Drill-Down « plus de détails sur les régions ». 33
  • 42. IV. Démarche de Construction d’un Data Warehouse Plusieurs chercheurs ou équipes de recherche ont essayé de proposer des démarchespour la réalisation d’un projet Data Warehouse, ces démarches se croisent essentiellementdans les étapes suivantes : • Modélisation et conception du Data Warehouse, • Alimentation du Data Warehouse, • Mise en œuvre du Data Warehouse, • Administration et maintenance du Data Warehouse, IV.1 Modélisation et conception du Data WarehouseLes deux approches les plus connues dans la conception des Data Warehouse sont : • L’approche basée sur les besoins d’analyse, • L’approche basée sur les sources de données, Aucune des deux approches citées n’est ni parfaite, ni applicable à tous les cas. Toutesdeux doivent être étudiées pour choisir celle qui s’adapte le mieux à notre cas. Quelque soit l’approche adoptée pour la conception d’un Data Warehouse, ladéfinition de celui-là reste la même. En étant un support d’aide à la décision, le DataWarehouse se base sur une architecture dimensionnelle. IV.1.1 Approche « Besoins d’analyse » Le contenu du Data Warehouse sera déterminé selon les besoins de l’utilisateur final.Cette approche est aussi appelée « approche descendante » (Top-Down Approach) et estillustrée par R. Kimball grâce à son cycle de vie dimensionnel comme suit : Figure I.16 : illustration de l’approche « Besoins d’analyse » grâce au cycle de vie dimensionnel de Kimball [Kimball, 2004]. 34
  • 43. Avantages InconvénientsAucun risque de concevoir une solution Pas de prise en compte de l’évolution desobsolète avant d’être opérationnelle besoins de l’utilisateur. Nécessite une modification de la structure du Data Warehouse en cas de nouveau besoin Négligence du système opérationnel Difficulté de déterminer les besoins des utilisateurs Tableau I.3 : Avantages et inconvénients de l’approche « Besoins d’analyse ». IV.1.2 Approche « Source de données » Le contenu du Data Warehouse est déterminé selon les sources de données. Cetteapproche est appelée : Approche ascendante (Bottom-up Approach). Figure I.17 : Illustration de l’approche « Source de données » grâce au cycle de développement du DW de Inmon [Inmon, 2002]. 35
  • 44. Inmon considère que l’utilisateur ne peut jamais déterminer ses besoins dès le départ,« Donnez moi ce que je vous demande, et je vous direz ce dont j’ai vraiment besoin »7, ilconsidère que les besoins sont en constante évolution. Avantages InconvénientsMeilleure prise en charge de l’évolution des Risque de concevoir une solution obsolètebesoins avant qu’elle soit opérationnelle Evolution du schéma des données source Complexité de source de données Tableau I.4 : Avantages et inconvénients de l’approche « Sources de données». IV.1.3 Approche mixte Une combinaison des deux approches appelée hybride ou mixte peut s’avérer efficace.Elle prend en considération les sources de données et les besoins des utilisateurs. Cette approche consiste à construire des schémas dimensionnels à partir des structuresdes données du système opérationnel, et les valider par rapport aux besoins analytiques. Cetteapproche cumule les avantages et quelques inconvénients des deux approches déjà citées,telles que la complexité des sources de données et la difficulté quant à la détermination desbesoins analytiques. Figure I.18 : Illustration de l’approche mixte. “Give me what I tell you I want, then I can tell you what I really want.”[Inmon, 2002]7 36
  • 45. Cette étape aboutit à l’établissement du modèle dimensionnel validé du DataWarehouse. Ce modèle dimensionnel sera transformé en modèle physique, qui différera dumodèle dimensionnel.IV.2 Alimentation du Data Warehouse Une fois le Data Warehouse conçu, il faut l’alimenter et le charger en données. Cettealimentation (le plus souvent appelée processus ETL « Extract-Transform-Load ») se dérouleen 3 phases qui sont : • Extraction des données primaires (issues par exemple des systèmes de production), • Transformation des données, • Le chargement des données traitées dans l’entrepôt de données, Ces trois étapes décrivent une mécanique cyclique qui a pour but de garantirl’alimentation du Data Warehouse en données homogènes, propres et fiables. IV.2.1 Les phases de l’alimentation « E.T.L. » Les phases du processus E.T.L. représentent la mécanique d’alimentation du DataWarehouse. Ainsi elles se déroulent comme suit : a) L’extraction des données « L’extraction est la première étape du processus d’apport de données à l’entrepôt dedonnées. Extraire, cela veut dire lire et interpréter les données sources et les copier dans lazone de préparation en vue de manipulations ultérieures. » [Kimball, 2005]. Elle consiste en : • Cibler les données, • Appliquer les filtres nécessaires, • Définir la fréquence de chargement, Lors du chargement des données, il faut extraire les nouvelles données ainsi que leschangements intervenus sur ces données. Pour cela, il existe trois stratégies de capture dechangement : • Colonnes d’audit : la colonne d’audit, est une colonne qui enregistre la dated’insertion ou du dernier changement d’un enregistrement. Cette colonne est mise à jour soitpar des triggers ou par les applications opérationnelles, d’où la nécessité de vérifier leurfiabilité. • Capture des logs : certains outils ETL utilisent les fichiers logs des systèmes sourcesafin de détecter les changements (généralement logs du SGBD). En plus de l’absence de cettefonctionnalité sur certains outils ETL du marché, l’effacement des fichiers logs engendre laperte de toute information relative aux transactions. 37
  • 46. • Comparaison avec le dernier chargement : le processus d’extraction sauvegarde descopies des chargements antérieurs, de manière à procéder à une comparaison lors de chaquenouvelle extraction. Il est impossible de rater un nouvel enregistrement avec cette méthode. b) La transformation des données La transformation est la seconde phase du processus. Cette étape, qui du reste est trèsimportante, assure en réalité plusieurs tâches qui garantissent la fiabilité des données et leursqualités. Ces tâches sont : • Consolidation des données. • Correction des données et élimination de toute ambiguïté. • Elimination des données redondantes. • Compléter et renseigner les valeurs manquantes. Cette opération se solde par la production d’informations dignes d’intérêt pour l’entrepriseet de et sont donc prêtes à être entreposées. c) Le chargement des données C’est la dernière phase de l’alimentation d’un entrepôt de données, le chargement est uneétape indispensable. Elle reste toute fois très délicate et exige une certaine connaissance desstructures du système de gestion de la base de données (tables et index) afin d’optimiser aumieux le processus. IV.2.2 Politiques de l’alimentation Le processus de l’alimentation peut se faire de différentes manières. Le choix de lapolitique de chargement dépend des sources : disponibilité et accessibilité. Ces politiquessont8 : • Push : dans cette méthode, la logique de chargement est dans le système de production. Il " pousse " les données vers la zone de préparation quand il en a loccasion. Linconvénient est que si le système est occupé, il ne poussera jamais les données. • Pull : contrairement de la méthode précédente, le Pull " tire " les données de la source vers la zone de préparation. Linconvénient de cette méthode est quelle peut surcharger le système sil est en cours dutilisation. • Push-pull : cest la combinaison des deux méthodes. La source prépare les données à envoyer et indique à la zone de préparation quelle est prête. La zone de préparation va alors récupérer les données.8 http://grim.developpez.com/articles/concepts/etl/ 38
  • 47. Aussi, le processus d’alimentation doit répondre à certaines exigences illustrées par lafigure suivante : Être correctif Être rapide Être sûr Processus ETL Être transparent Figure I.19 : Objectif de qualité de données dans un processus ETL [Kimball, 2004]. • Sûr : assure l’acheminement des données et leur livraison. • Rapide : la quantité de données manipulées peut causer des lenteurs. Le processusd’alimentation doit palier à ce problème et assurer le chargement du Data Warehouse dans desdélais acceptables. • Correctif : le processus d’alimentation doit apporter les correctifs nécessaires pouraméliorer la qualité des données. • Transparent : le processus de l’ETL doit être transparent afin d’améliorer la qualitédes données. 39
  • 48. IV.2.3 Les outils E.T.L. Les outils E.T.L, en français E.T.C « Extraction-Transformation-Chargement » [Kimball,2005], sont des outils qui garantissent la faisabilité et facilitent le déroulement des trois phasescitées précédemment. D’où leur importance dans un projet Data Warehouse. IV.3 Mise en œuvre du Data Warehouse C’est la dernière étape d’un projet Data Warehouse, soit son exploitation. L’exploitationdu Data Warehouse se fait par le biais d’un ensemble d’outils analytiques développés autourdu Data Warehouse. Donc cette étape nécessite l’achèvement du développement, ou de lamise en place, de ces outils qui peuvent accomplir les fonctions suivantes: a. Requêtage ad-hoc : Le requêtage ad-hoc reste très fréquent dans ce type de projet. En effet, les utilisateursde l’entrepôt de données, et spécialement les analystes, seront amenés à interagir avec le DWvia des requêtes ad-hoc dans le but de faire les analyses requises par leurs métiers et,d’élaborer aussi, des rapports et des tableaux de bords spécifiques. L’accès à ce genre de service peut se faire via différentes méthodes et outils.Cependant, les spécialistes en la matière préconisent de laisser la possibilité à l’utilisateur dechoisir les outils qui lui paraissent les plus adéquats. b. Reporting : Destiné essentiellement à la production de rapports et de tableaux de bord, « il est laprésentation périodique de rapports sur les activités et résultats dune organisation, duneunité de travail ou du responsable dune fonction, destinée à en informer ceux chargés de lessuperviser en interne ou en externe, ou tout simplement concernés par ces activités ourésultants »9. Ces outils de Reporting ne sont pas, à proprement parler, des instruments daide à ladécision, mais, lorsqu’ils sont utilisés de manière appropriée, ils peuvent fournir une précieusevue d’ensemble. Les rapports sont alors crées par le biais d’outils de Reporting qui permettent de leurdonner un format prédéterminé. Les requêtes sont constituées lors de l’élaboration desrapports qui seront ensuite diffusés périodiquement en automatique ou ponctuellement à lademande.9 http://fr.wikipedia.org/wiki/Reporting 40
  • 49. c. Analyse dimensionnelle des données: L’analyse dimensionnelle est sans doute celle qui exploite et fait ressortir au mieux lescapacités de l’entrepôt de données. Le but par l’analyse dimensionnelle est d’offrir auxutilisateurs la possibilité d’analyser les données selon différents critères afin de confirmer unetendance ou suivre les performances de l’entreprise. Cette analyse se fait selon le principe OLAP, offrant de ce fait aux utilisateurs lespossibilités de recourir à différentes opérations facilitant la navigation dans les données. Lamise en place de ces outils est une option très intéressante dans la mesure où les donnéesseront accessibles en analyses instantanées. Plusieurs fournisseurs de solution OLAP existentsur le marché et offrent des solutions construites sur des méthodes et technologies différentes.C’est d’ailleurs pour cela que le choix de la solution doit se faire au préalable, selon lesbesoins en utilisation, la taille de l’entrepôt et les moyens techniques disponibles. d. Tableaux de bord : Les tableaux de bord sont un outil de pilotage qui donne une vision sur l’évolutiond’un processus, afin de permettre aux responsables de mettre en place des actions correctives. « Le tableau de bord est un ensemble d’indicateurs peu nombreux conçus pourpermettre aux gestionnaires de prendre connaissance de l’état et de l’évolution des systèmesqu’ils pilotent et d’identifier les tendances qui les influenceront sur un horizon cohérent avecla nature de leurs fonctions » [Bouquin, 2003]. Cette forme de restitution a la particularité de se limiter à l’essentiel, cest-à-dire lamise en évidence de l’état d’un indicateur par rapport à un objectif, tout en adoptant unereprésentation graphique de l’information. e. Data Mining : Au sens littéral du terme, le Data Mining signifie le forage de données. Le but de ceforage est d’extraire de la matière brute qui, dans notre cas, représente de nouvellesconnaissances. L’idée de départ veut qu’il existe dans toute entreprise des connaissancesutiles, cachées sous des gisements de données. Le Data Mining permet donc, grâce à uncertain nombre de techniques, de découvrir ces connaissances en faisant apparaître descorrélations entre ces données. Le Data Warehouse constituera alors la première source de données sur laquelles’exécutera le processus de découverte de connaissances. Dans la majeure partie du temps,l’entrepôt de données représente un pré requis indispensable à toute fouille de données. Le recours à ce genre de méthode est de plus en plus utilisé dans les entreprisesmodernes. Les applications et outils implémentant ces solutions sont rarement développés eninterne. En effet, les entreprises préfèrent se reposer sur des valeurs sûres du marché afind’exploiter au plus vite les données en leur possession. 41
  • 50. IV.4 Maintenance et expansion La mise en service du Data Warehouse ne signifie pas la fin du projet, car un projetData Warehouse nécessite un suivi constant compte tenu des besoins d’optimisation deperformance et ou d’expansion. Il est donc nécessaire d’investir dans les domaines suivants[Kimball, 2002] : Support : assurer un support aux utilisateurs pour leur faire apprécier l’utilisation del’entrepôt de données. En outre, la relation directe avec les utilisateurs permet de détecter lescorrectifs nécessaires à apporter. Formation : il est indispensable d’offrir un programme de formation permanant auxutilisateurs de l’entrepôt de données. Support technique : un entrepôt de données est considéré comme un environnementde production. Naturellement le support technique doit surveiller avec la plus grande vigilanceles performances et les tendances en ce qui concerne la charge du système. Management de l’évolution : il faut toujours s’assurer que l’implémentation répondaux besoins de l’entreprise. Les revues systématiques à certain point de contrôle sont un outilclé pour détecter et définir les possibilités d’amélioration. En plus du suivi et de lamaintenance du Data Warehouse, des demandes d’expansion sont envisageables pour denouveaux besoins, de nouvelles données ou pour des améliorations. Ces travaux d’expansion sont à prévoir de façon à faciliter l’évolution du schéma duData Warehouse. 42
  • 51. V. Conclusion Le concept « Data Warehouse » est apparu comme une réponse à des besoinsgrandissants dans le domaine décisionnel. Son adaptabilité et sa capacité de fournir lesdonnées nécessaires à une bonne analyse, ont fait de lui un atout majeur et incontournablepour toute entreprise soucieuse du suivi de ces performances. Afin de mettre en place ce genre de système, il est nécessaire de choisir et d’adopterune démarche précise qui doit tenir compte des réalités de l’entreprise et des contraintes duprojet. La modélisation de l’entrepôt se fait dans tous les cas grâce à la modélisationdimensionnelle. L’alimentation en données constitue l’étape à laquelle il faut accorder le plusd’attention et de temps. En effet, elle est le garant de contenance de l’entrepôt en donnéesfiables et correctes. Une fois l’alimentation terminée, l’exploitation des données peut alors sefaire par différentes méthodes. L’utilisation d’outil OLAP reste, cependant, l’aspect le plusintéressant dans cette exploitation permettant la navigation dans les données de l’entrepôt à lademande. Au cours de la seconde partie de cette étude, nous allons essayer d’utiliser lesconcepts présentés dans la synthèse bibliographique, et cela afin de mettre en œuvre notresystème. 43
  • 52. Partie II : Cas pratique « filiales de distribution SONELGAZ » 44
  • 53. Chapitre I : Présentation de l’organisme d’accueil. 45
  • 54. I. Présentation de SONELGAZ I.1 Historique SONELGAZ est l’opérateur historique dans le domaine de la fourniture des énergiesélectrique et gazière en Algérie. Ses missions principales sont la production, le transport et ladistribution de l’électricité ainsi que le transport et la distribution du gaz par canalisations.Son nouveau statut lui confère la possibilité d’intervenir dans d’autres segments d’activitésprésentant un intérêt pour l’entreprise et notamment dans le domaine de la commercialisationde l’électricité et du gaz à l’étranger. Durant son existence le groupe a connu des évolutionsmajeures qui peuvent être résumées comme suit :1947, Création d’EGA : C’est le décret du 5 juin 1947 qui a crée l’Etablissement PublicNational « Electricité et Gaz d’Algérie » (EGA par abréviation). Par décret du 16 août 1947,seize sociétés qui se partageaient les concessions électriques ont été transférées à EGA. Cessociétés détenaient alors 90% des propriétés industrielles électriques et gazières du pays.1962, Le défi de la relève : Cette année représente la prise en main de l’Algérie indépendantede la SONELGAZ –alors Electricité et Gaz d’Algérie – et cela en faisant face au départmassif de cadres et techniciens français.Période allant de 1962 à 1969 : Cette période a été caractérisée par la baisse de laconsommation (une baisse de prés de 33% en deux ans) dû au départ massive des étrangersqui représentaient plus de 87% de la clientèle. Par ailleurs, les tâches les plus urgentes ont étéde reprendre le fichier des abonnés, reconstituer les plans des ouvrages et des réseaux,procéder au recrutement et à la formation dans tous les domaines et de ramener le niveau deconsommation de l’énergie à celui de 1961.1969, création de SONELGAZ: C’est l’ordonnance n° 69-59 du 28 juillet 1969) portantdissolution de l’EGA et création de la nouvelle Société Nationale de l’Electricité et du GAZ -SONELGAZ-. Ce texte s’inscrit dans le cadre des mesures de nationalisation des secteurs clésde l’économie nationale. L’ordonnance précitée a attribué à l’entreprise le monopole de laproduction, du transport, de la distribution, de l’importation et de l’exportation de l’électricitéet du gaz manufacturé (art. 4 et 7). L’ensemble des biens de l’ex-EGA lui a été légué.1977, le plan national d’électrification : Dès le milieu des années 70, l’Algérie s’estengagée dans un ambitieux plan national d’électrification qui avait objectif l’amélioration desconditions de vie des populations des campagnes tout en assurant un développementharmonieux de l’espace rural.1983, naissance des entreprises travaux : six entreprises autonomes voient le jour :KAHRIF pour l’électrification; KAHRAKIB - Infrastructures et installations électriques;KANAGAZ - Réalisation des réseaux gaz; INERGA - Génie civil; ETTERKIB – Montageindustriel et l’entreprise AMC - Fabrication des compteurs et appareils de mesure et decontrôle. 46
  • 55. 1991, SONELGAZ EPIC : SONELGAZ change de nature juridique et devient EtablissementPublic à caractère Industriel et Commercial (EPIC) en vertu du décret exécutif n° 91-475 du14 décembre 1991, portant transformation de la nature juridique de la Société Nationale del’Electricité et du Gaz. Le décret exécutif n° 95-280 du 17 septembre 1995 confirme la naturede SONELGAZ en tant qu’Etablissement Public à caractère Industriel et Commercial.1998, création de filiales périphériques : Le 1er janvier 1998, neuf filiales périphériques ontvu le jour.2002, promulgation de la loi 02 / 01 du 5 février 2002 : Promulguée en février 2002, lanouvelle loi relative à l’électricité et à la distribution du gaz par canalisations est venuesupprimer le monopole exercé jusque là par SONELGAZ, en ouvrant le secteur del’électricité et du gaz à la concurrence, sauf pour les activités de Transport qui ont uncaractère de monopole naturel.Juin 2002, SONELGAZ SPA : En vertu du décret présidentiel n° 02-195 du 1er juin 2002portant statuts de la Société algérienne de l’électricité et du gaz dénommée "SONELGAZ.Spa", SONELGAZ est passé d’Etablissement Public à caractère Industriel et Commercial àune Société Par Actions dont le capital est détenu par l’Etat.Sur le plan de son fonctionnement, SONELGAZ Spa est dotée d’une Assemblée Générale etd’un Conseil d’Administration. Elle est dirigée par un Président directeur général. I.1.1 Organisation du groupe SONELGAZ, et afin de se mettre en conformité avec les dispositions de la loi defévrier 2002, qui lui confère le statut de Société Par Actions, s’est érigée en un GroupeIndustriel constitué de sociétés opérationnelles et d’une Société Mère. Chacune des sociétésayant des missions et objectifs différents, il en ressort les principes d’organisation suivants : Maison Mère : elle est chargée essentiellement de l’élaboration de la stratégie et depilotage du Groupe, le contrôle des filiales, l’élaboration et la mise en œuvre de la politiquefinancière et la définition de la politique de développement de la Ressource Humaine. Filiales Métiers de base : Durant ces cinq dernières années, les métiers de base deSONELGAZ ont été érigés en filiales. Au nombre de huit, ces dernières activent dans lesdomaines de la production, la gestion du réseau de transport, la gestion du systèmeproduction / transport, la distribution de l’électricité et du gaz (quatre sociétés). Filiales Travaux : Les entreprises de réalisation érigées en entreprises autonomes à lafaveur de la restructuration de 1984 ont été réintégrées, depuis janvier 2006, au sein duGroupe SONELGAZ. Filiales Périphériques : SONELGAZ a externalisé ses activités périphériques et les aconfiées à des filiales dont elle détient entièrement le capital. Ces filiales sont au nombre dequatorze et opèrent dans des activités diverses. 47
  • 56. Sociétés en Participation : SONELGAZ s’est investie dans des domaines clés à hautevaleur technologique tels que les télécommunications ou la maintenance de turbines à gaz. L’organigramme suivant donne une vision claire et précise de la structure del’entreprise et de son administration : Figure II.1 : Organigramme représentant l’organisation du Groupe SONELGAZ. 48
  • 57. I.1.2 Le groupe en chiffres Le tableau suivant donne les chiffres relatifs à l’activité du groupe pour l’année 2008:Critères ChiffresChiffre d’affaire groupe 137 529 millions de DAInvestissements groupe 190 828 millions de DA Electricité 32 584 millions de kWhVentes Gaz 7.44 Milliards de m3 Electricité 6 298 682Nombre de clients Gaz 2 638 963Production Production SPE 28 970 millions de kWhd’électricité groupe Production IPP 11 017 millions de kWhPersonnel en activité Permanents 35 633 agentsdu groupe Temporaires 24 761 agents Tableau II.1 : Le groupe SONELGAZ en chiffres « année 2008 ». La figure suivante illustre l’évolution du chiffre d’affaire du groupe depuis l’année 2001 :Figure II.2 : Evolution du chiffre d’affaire du groupe « rapport d’activité de l’année 2008 ». 49
  • 58. La répartition du chiffre d’affaire du groupe pour l’année 2008 est de la manière suivante : Figure II.3 : Répartition du chiffre d’affaire publiée dans le rapport d’activité de l’année 2008. I.2 Le métier de la distribution L’un des métiers les plus importants du groupe, et dans lequel s’inscrit notre projet, est lafourniture et la distribution de l’énergie électrique et gazière. Ce métier, vu l’organisation dugroupe, est assuré par quatre filiales qui sont les « Sociétés de Distribution ». Les sociétéssont : • Sociétés de Distribution d’Electricité et du Gaz de l’Ouest (SDO). • Sociétés de Distribution d’Electricité et du Gaz du Centre (SDC). • Sociétés de Distribution d’Electricité et du Gaz d’Alger (SDA). • Sociétés de Distribution d’Electricité et du Gaz de l’Est (SDE). 50
  • 59. Les Sociétés de Distribution d’Electricité et du Gaz ont pour principales mission d’assurer : missions • L’exploitation et la maintenance du réseau de distribution de l’électricité et du gaz. ’exploitation distribution • Le développement des réseaux électricité et gaz permettant le raccordement des e raccordement nouveaux clients. • La commercialisation de l’électricité et du gaz. tionLe tableau suivant donne une vue d’ensemble des chiffres d’affaires des sociétés dedistribution : SDO SDC SDA SDECréation Jan. 2006 Jan. 2006 Jan. 2006 Jan. 2006Chiffre d’affaire (MDA) 26.366,14 16.242 17.713 39,752 ELEC 1.668.668 1.290.058 810.636 2.069.266Nombre de clients GAZ 549.904 389.410 383.583 893.750Nombre d’employés 4406 3211 2412 4887 Tableau II.2 : Présentation des sociétés de distribution en chiffres « année 2008 ». I.2.1 Organisation des sociétés de distributionChaque société de distribution compte cinq directions centrales, situées au niveau de sonsiège, et gère un certain nombre de « Directions de distribution ». Chacune de ces Directionsde Distributions gère des « Services Commerciaux ». L’organigramme suivant illustre : Figure II.4 : Organisation des sociétés de distribution. 51
  • 60. L’organisation des directions de distribution se présente comme suit : Figure II.5 : Organisation des Directions de Distribution. I.2.2 La clientèle de la distribution La segmentation des clients se fait selon la puissance de l’énergie à laquelle est abonné le quelleclient. Ainsi, on distingue : a. en électricité : • Client « Basse Tension-BT » : jusqu’à une puissance de 40 KVA, l’abonné est BT , considéré comme un client BT. La tension délivrée est 220 V ou 380 V. • Client « Moyenne Tension Tension-MT » : d’une puissance de 50 KVA jusqu’à 630 KVA, l’abonné est considéré comme un client MT La tension d’alimentation est de 10 KV ou 30 KV. • Client « Haute Tension-HT » : est considéré comme client « Haute Tension HT Tension-HT » tout client dont la tension d’alimentation est supérieure à 60 KV. b. En gaz : • Client « Basse Pression-BP » : tout client alimenté sous une pression de 21 bars à BP travers un détendeur. • Client « Moyenne Pression ression-MP » : tout client alimenté sous une pression de 4 bars avec un poste de détente gaz gaz. • Client « Haute Pression-HP » : tout client alimenté sous une pression sup HP supérieure à 4 bars avec un poste de détente gaz. 52
  • 61. En BT/BP, on distingue plusieurs types de clients : • Clients ménages : il s’agit des clients domestiques. • Clients non ménages : il s’agit des clients non domestiques (Activités commerciales). • Clients FSM (Facturation sur mémoire). I.3 L’informatique au sein du groupe SONELGAZ L’informatique occupe une place très importante au sein du groupe SONELGAZ. Eneffet, la taille du groupe et son activité l’oblige à se doter des moyens technologiques depointe afin d’assurer ses activités métiers et de gestion.L’informatique au sein du groupe a évolué au fil des années comme suit : • Jusqu’à la fin des années 80, l’informatique était essentiellement présente au niveau central sur gros systèmes. Cette période a vu le développement de systèmes de gestion de l’entreprise et l’acquisition de modèles scientifiques de calcul pour la planification des réseaux Electricité et Gaz (CARAT et APHYRE). • La réorganisation de SONELGAZ en 1991 et l’avènement des mini et micro- ordinateurs ont précipité la décentralisation de l’informatique. • En 1996, le schéma directeur informatique de l’entreprise a défini la stratégie de décentralisation de l’informatique vers une informatique distribuée, se basant sur l’interconnexion des réseaux locaux à travers un réseau de télécommunication propre. • En 2006, le Groupe centralise l’activité informatique par la création de la DirectionGénérale des Systèmes d’Information (DGSI), chargée de la maîtrise d’œuvre dans ledomaine de l’informatique. • En 2009, la DGSI s’est érigée au rang de filiale spécialisée dans le domaine dessystèmes d’information et technologies nouvelles sous le nom de « ELIT ». I.3.1 Présentation de « ELIT » Elit « El-Djazaïr Information Technology » élabore et met en œuvre les systèmesd’information destinés au pilotage et à la gestion des différentes activités du groupeSONELGAZ, assure l’accès à l’information et aux applications, en garantit la sécurité,l’intégrité et la fiabilité et met à la disposition de ses clients l’expertise techniqueindispensable à la satisfaction de leurs besoins. 53
  • 62. L’organigramme suivant illustre la manière dont est organisée la filiale « ELIT » et ladistribution de son effectif: Figure II.6 : Organisation de la filiale ELIT.La direction études et développement Notre stage se déroule au sein de la direction d’étude et de développement. Cedépartement a pour mission de faire : l’étude, la conception, le développement et ledéploiement de solutions nouvelles et la mise en place des systèmes d’information du groupe.Aussi, il offre l’assistance nécessaire et le suivi des solutions déployées. 54
  • 63. L’organigramme et l’effectif de la direction « études et développement » se présentecomme suit : Figure II.7 : Organisation de la direction d’étude et de développement. Remarque : au niveau de chaque « DD » il existe une « Division Gestion des SystèmesInformatique ». Cette dernière s’occupe essentiellement du suivie et de la maintenance dessystèmes déjà déployés, ainsi que de la gestion du matériel informatique au niveau de la DDet des agences affiliées. 55
  • 64. II. Conclusion Avec ses décennies d’activité dans le domaine de l’énergie et une réputation quidépasse les frontières du pays, le groupe SONELGAZ représente un acteur majeur etincontournable de l’économie nationale. Cette brève présentation nous a permis de connaîtreun peu plus le groupe SONELGAZ, notamment dans sa nouvelle configuration de holdingindustriel. Par ailleurs, cette présentation nous a fait comprendre la structuration et l’organisationdu métier de la distribution, qui est le premier visé par ce projet, et de nous pencher surl’informatique du groupe désormais gérée, au niveau national, par la filiale « ELIT ». Dans le chapitre suivant, une étude détaillée de l’existant décisionnel du groupe, danssa fonction de distribution, sera présentée. 56
  • 65. Chapitre II : étude de l’existant 57
  • 66. I. Introduction Le groupe SONELGAZ veut, par le biais de ce projet, palier à un manque important enmatière de décisionnel. Ce manque se caractérise par la quasi inexistence de support d’aide àla décision, et l’indisponibilité de moyens de Reporting efficaces, en mesure de fournir desinformations adéquates en temps voulu. Partant de ce constat, nous allons essayer, à travers ce chapitre, de présenter une analyseaussi complète que possible de l’existant décisionnel du groupe dans le cadre de sa fonctionde distribution. Ce chapitre a aussi pour but de faire connaître les procédures et les méthodesde Reporting et de prise de décision, ainsi que les éventuelles lacunes qui peuvent exister.II. Etat du décisionnel au sein du groupe Il est intéressant de signaler que le groupe, dans sa fonction de distribution, ne disposed’aucun système d’aide à la décision automatique ou semi-automatique. Aussi, tout processusd’analyse et de prise de décision à tous les niveaux se base essentiellement sur des rapportsdont les données sont extraites et consolidées à partir des systèmes transactionnels d’unemanière manuelle. Lors de notre étude de l’existant, nous avons pu recenser deux procédés pour l’élaborationdes rapports. Les deux procédés se distinguent par leurs utilisateurs finaux, la structurechargée de leur élaboration et le niveau de consolidation. II.1 Niveau Groupe A ce niveau de hiérarchie, les utilisateurs ont besoin de chiffres qui concernent l’ensembledu groupe, dans sa fonction de distribution. Ces rapports sont essentiellement livrés par lafiliale « ELIT ». Les données étant consolidées à partir des bases de production des « DD »des quatre filiales de distribution. Cela suppose donc, la participation de différents acteursdispersés sur l’ensemble du territoire national ainsi que sur l’ensemble des filialesdistributions. Dans le meilleur des cas, le rapport demandé concerne des données déjà consolidées etprêtes à l’utilisation. L’élaboration du rapport se fait donc sans grandes difficultés. Sinon, leprocédé d’extraction et de consolidation est relancé. Le diagramme suivant donne une visionclaire de la manière dont sont consolidées les données et les rapports élaborés en partant de lademande d’un état donné jusquà sa production : 58
  • 67. Figure II.8 : Diagramme d’activité modélisant l’édition de rapport pour le niveau groupe. À partir de ce diagramme on peut d’ores et déjà avoir une idée sur le nombred’intervenants dans cette procédure qui reste une tâche très fastidieuse, surtout dans sa partieconsolidation des données. Cette procédure se déroule comme suit: Phase 1 : les utilisateurs de niveau groupe, principalement des analystes et desdécideurs de la DGDS et de la maison mère, formulent leurs requêtes qui sont transmises audépartement « Systèmes d’information de la distribution » (SID) de la filiale « ELIT ». Phase 2 : le département SID, en recevant une demande de la part des utilisateurs deniveau groupe, lance la procédure de consolidation des données à partir des différentes DD dugroupe. Cette procédure doit faire l’objet d’une validation de la part du directeur études etdéveloppement. La demande est ensuite transmise au chef de CTI de chaque DD. Phase 3 : Les chefs de CTI, en recevant la demande d’extraction, programment unetranche horaire et préparent les scripts d’extraction. L’étape d’extraction aboutit à latransmission de fichier texte vers le département SID. 59
  • 68. Remarque : les fichiers, étant d’une taille assez volumineuse, peuvent atteindre unecentaine de mégas voire plus. Ces dits fichiers subissent parfois des altérations durant letransfert ou deviennent carrément inutilisables. Dans ce cas les « D.D. » concernées sontrecontactées pour une nouvelle extraction ou un nouvel envoi selon la nature du problème. Ilarrive parfois, suite à des problèmes réseaux, de recourir au transfert des données sursupport physique transportable (CD, clé USB). Phase 4 : Une fois les données reçues en totalité, la consolidation se fait au niveau dudépartement « SID » manuellement. Cette consolidation permet d’élaborer les rapportsvoulus. Phase 5 : Le rapport est validé par le chef de département est et envoyé auxutilisateurs finaux. Remarque : la procédure se répète généralement quatre fois par an, la consolidationdes chiffres se faisant chaque trimestre. Mais cela n’empêche pas le lancement de cetteprocédure en cas de nécessité. Sauf en cas de problèmes, toute échange d’information « demandes et fichiers joints »se fait par le biais de la messagerie interne du groupe. II.2 Niveau Sociétés de Distribution Pour le niveau « SD », la procédure se déroule exactement comme pour le niveaugroupe. A cela près que « ELIT » n’intervient pas à ce niveau là. C’est alors aux ingénieurs dela structure concernée de prendre en charge la consolidation et l’élaboration des rapports. Lesdifférences notées sont : Emission de la demande : La demande est formulée par les analystes et décideurs desdeux directions Commerciale Marketing « DCM » et Comptabilité et Finance « DCF ». Extraction des données: l’extraction se fait toujours aux niveaux des DD affiliées à laSD. Dans la plupart du temps les données sont transférées directement sous forme derapports10. Consolidation des données : la consolidation se fait soit à partir des fichiers dedonnées, soit en se basant sur les rapports transmis par les DD. Cette consolidation se faittoujours de façon manuelle et monopolise les ingénieurs et techniciens de SD. Remarque : la procédure d’élaboration de rapports au niveau SD se faitgénéralement chaque fin de mois. Elle peut aussi être lancée en cas de nécessité.10 Ces rapports obéissent à des canevas prédéfinis. 60
  • 69. II.3 Niveau Directions de Distribution Les consommateurs de rapports au niveau des DD utilisent des rapports livrésdirectement par leurs CTI. Ces rapports, basés exclusivement sur les données des systèmestransactionnels, sont élaborés et transmis à la demande des managers. Le schéma suivantmontre la manière dont sont traitées les demandes de rapport au niveau DD. La demande est transmise directement du manager vers le chef de CTI via lamessagerie interne «lotus de l’entreprise ». Le chef de CTI charge son équipe technique del’élaboration du rapport demandé qu’il contrôle avant sa transmission à qui de droit. L’élaboration des rapports se fait à ce niveau soit par le bais du module« Statistique11 » du SGC, Soit par des requêtes SQL. La présentation du rapport se fait alorsselon le canevas demandé. Remarque : Vu le nombre important de demandes et de sollicitations, certaines DDont mis à la disposition des managers et des décideurs des systèmes qui fournissent des étatsstatistiques à la demande. Cependant, ces systèmes, en interrogeant directement la base dedonnées transactionnelle en production, offrent des services limités avec des temps deréponse non satisfaisants. Cette mise en place de systèmes, ne fait qu’encourager le groupe à uniformiser lesprocédures et méthodes de prise de décision.11 Ce module a été développé pour fournir un certain nombre de rapports statistiques au niveau DD. Il interagitdirectement avec la base de données en production et pénalise souvent le système transactionnel. 61
  • 70. III. Conclusion Cette étude nous permet d’avoir une vision générale des procédures d’élaboration derapports et de consolidation des données. Elle constitue aussi le point de départ pour définir lepérimètre du projet en général et de l’étude des besoins en particulier. Elle fait ressortir lesinsuffisances du système actuel en soulignant les points faibles ou les goulots d’étranglementsde ce dernier. Le chapitre suivant consacré à l’étude des besoins, aidera à détecter ceux desutilisateurs de manière à pouvoir y répondre. 62
  • 71. Chapitre III : Définition des besoins. 63
  • 72. I. Introduction Tout Data Warehouse doit être en mesure de répondre aux attentes des utilisateurs.Cela ne peut, évidemment, se faire sans une étude approfondie de leurs besoins. e Ainsi, il existe deux démarches qui ont été décrites lors de notre synthèsebibliographique, et qui sont: lapproche « Buttom Up » et lapproche « Top Down ». Lapplication exclusive de l e lune de ces deux approches ne produit nullement desrésultats satisfaisants. La démarche généralement adoptée est une démarche mixte, qui allieentre les deux précédentes dans un souci de prise en considération des besoins des décideurssans perdre de vue toute possibilit et opportunité offerte par les données sources Cette possibilité sources.approche permet donc de recueillir, corriger et de modérer les attentes des utilisateurs dès ledépart, tout en détectant déventuels besoins non exprimés. Durant l’étude des besoins on ne peut se limiter aux interviews avec les utilisateurs limiter utilisateurs,néanmoins, il faudrait absolument prendre en compte l’avis des Administrateurs des bases dedonnées des systèmes sources« Les DBA sont les principaux experts sur les applicationsexistantes susceptibles daliment dalimenter lentrepôt de données. Leurs interviews servent àconfronter aux réalités certains des thèmes qui surgissent lors des rencontres avec lesutilisateurs finaux. » [Kimball, 96] Figure II.9 : La place de l’étape d’étude des besoins dans un projet Data Warehouse. 64
  • 73. Ce chapitre a pour principale vocation d’exposer et de décrire la démarche adoptéepour la détection des besoins ainsi que la présentation de la synthèse qui en sera faite. I.1 Description de la démarche détude des besoins Afin de faire une étude aussi complète que possible, nous avons choisi dadopter unedémarche qui nous a permis de combiner, d’une manière assez satisfaisante, entre lapproche« Buttom Up » et lapproche « Top Down ».Ainsi, notre démarche peut se résumer au travers des étapes suivantes: • Étude préliminaire des systèmes sources et interviews sommaires avec les DBA, • Détection des postes susceptibles dêtre porteurs dinformations utiles, • Planification, préparation et conduite des interviews: • Utilisation d’autres moyens pour la détection des besoins, • Rédaction et validation du recueil récapitulatif des besoins, a. Étude préliminaire des systèmes sources et interviews sommaires avec les DBA Cette étude représente une étape de compréhension des systèmes opérationnels et de leurenvironnement. Elle a pour mérite de consolider les connaissances acquises durant l’étude del’existant, ainsi que le jargon et le fonctionnement de l’entreprise. En outre, cette étape permetde détecter, de manière succincte, les postes susceptibles d’interagir avec le Data Warehouse.Elle est de ce fait indispensable pour un bon recensement des besoins. Outre les DBA, qui sont pour la plupart des chefs de CTI, les gestionnaires qui se trouventau sein de l’Elit, et dont la fonction principale est de définir les règles de gestion desapplications et de s’assurer du respect des procédures propres à la distribution, ont été unesource d’information assez bénéfique, eu égard à leur connaissance des applications du SGCet de leur maîtrise du métier du groupe. b. Détection des postes susceptibles dêtre porteurs dinformations utiles Vu le grand nombre d’employés activant au sein du groupe SONELGAZ, notammentdans la fonction de distribution, ainsi que la dispersion géographique des filiales, il nous a été,bien sûr, impossible de voir et d’interviewer toute cette population. Ainsi, notre étude s’estaxée sur les utilisateurs SDA, SDC. Cette étape nous a permis, donc, d’identifier, en premier lieu, les services qui peuventêtre porteurs d’informations tangibles et qui représentent la population potentiellementutilisatrice du projet. Ces dits services sont classés selon leur appartenance aux différentesstructures, indiqué dans le tableau suivant: 65
  • 74. Structure Intitulé du poste Nombre total de postesDirection de distribution Directeur régional de distribution 58 (1 chef par DD) Commercial 58 (1 chef par DD) Division finance et comptabilité 58 (1 comptable par DD) Administrateur 58 (1 administrateur par DD)Société de distribution P.D.G de la SD 4 D.C.M 4 Directeur finance et comptabilité 4Groupe P.D.G 1 DGDS 3 - DAP - DAR - ED Total 248 Tableau II.3 : Tableau présentant la population à interviewer. c. Planification, préparation et conduite des interviews Avant de détailler cette étape, il est nécessaire de justifier notre choix de l’entretien «interviews » comme méthode de collecte des besoins.Bien qu’il existe d’autres méthodes d’identification des besoins, les entretiens s’imposentcomme étant la valeur sûre dans un tel projet. En effet, cette méthode a l’avantage d’être, plusou moins, facilement planifiable et d’ouvrir le dialogue avec les interviewés, qui sont pour laplus part des décideurs et des analystes. Dans le souci de conduire à bien cette étape, qui du reste est très critique et délicate, il estnécessaire de passer par différentes phases, à savoir :1 La phase de planification La planification se fait généralement plusieurs jours à l’avance. Elle nous permet deprendre les rendez-vous nécessaires et de prévenir les futurs interviewés de notre arrivée et dumotif de cet entretien. Cette phase, qui est un préalable indispensable, s’est avérée être une tâche très ardue. Eneffet, la nature organisationnelle et la dispersion des structures liées à la distribution ont posédes problèmes que nous évoquerons plus loin. Cependant ces mêmes facteurs nous ont 66
  • 75. poussés à entreprendre ce genre de démarches dans un souci de bonne conduite du projet etafin de ne pas perdre de temps dans des allers et retours improductifs. Aussi, nous avons essayé de planifier nos entretiens de manière à avoir une certainealternance entre les interviews des potentiels utilisateurs et les entretiens avec les DBA et lesgestionnaires de manière à combiner entre les besoins d’analyse et les potentialités dessystèmes sources et de leurs données.2 La phase de préparation Une fois la planification de l’entretien terminée, sa préparation doit se faire de telle sorte àce qu’il se déroule dans les meilleures conditions possibles. La préparation se résume essentiellement en l’identification des questions à poser, despoints à soulever et des thèmes à éviter afin de ne pas trop s’éparpiller. Les questions à poser sont classées en deux catégories, selon le poste de la personneinterviewée. Ainsi certaines questions sont destinées aux décideurs alors que d’autres sontdestinées aux analystes.3 La conduite des entretiens Dernière phase de l’étape, la conduite des interviews représente la réalisation sur le terraindes phases précédentes. Le but escompté étant d’amener les interviewés, au travers de leursréponse à nos questions, de présenter leur travail et la manière dont ils procèdent pour le faire.L’identification des besoins se fera alors en détectant les métriques qu’ils utilisent et lesinformations sur lesquelles ils s’appuient pour la prise de décision. d. Autres moyens utilisés pour la détection des besoins Bien que les entretiens représentent une source importante d’informations et aidentgrandement à l’identification des besoins des utilisateurs, leur utilisation exclusive n’est pasconseillée dans la construction d’un entrepôt de données. Cela tient principalement au fait queles utilisateurs ne peuvent, même avec la meilleure volonté du monde, exprimer tous leursbesoins. De ce fait, il est fait appel à l’étude des rapports déjà demandés et des donnéesdisponibles a même de fournir des informations exploitables.L’étude des rapports offre un certain apport à notre démarche d’études des besoins, dans lamesure où les utilisateurs peuvent ne pas mentionner des besoins qui leur paraissent évidentsou qui ne leur viennent pas à l’esprit durant nos interviews, ces derniers peuvent être, en effet,influencés par nos questions. L’étude des données, quant à elle, sert à détecter des besoins non déclarés et quipeuvent se faire sentir ultérieurement, le but de cette démarche étant de construire un entrepôtde données capable de répondre à ces éventuels nouveaux besoins. 67
  • 76. e. Rédaction et validation du recueil récapitulatif des besoins L’étude des besoins nous a permis de recenser les besoins que nous avons classés parvolets spécifiques. Ils peuvent être présentés de la manière suivante : Volet Détecté Besoins enregistrés (Les critères d’analyse) Utilisateurs : Ce volet a été évoqué et solliciter à tous les niveaux et par différents postes. Cependant les utilisateurs des services Commerciaux et marketing, de la DCM et de la DFC ont exprimé un vif intérêt pour ce Suivi des volet. ventes Besoins : Les utilisateurs ont besoin de connaître l’évolution des ventes et des consommations dans le temps et selon différents critères à savoir : (Zone géographique, type d’abonnement, secteur d’activité) Utilisateurs : Services commerciaux, DCM, utilisateurs de la DGDS. Besoins : ce volet contient les informations relatives à l’apport abonné Suivi des (résiliations, nouveaux clients,…etc.), l’utilisateur devrait être en mesure abonnés de suivre l’évolution de ces chiffres selon différents critères d’analyse: (Zone géographique, temps, type abonnement, activités). Utilisateurs : Services commerciaux, DCM. Besoins : Avoir une vue d’ensemble de l’évolution des affaires et le Suivi des suivi des taux et les délais de réalisations. L’utilisateur doit être en affaires mesure de faire des analyses selon les critères : (Zone, Type de l’affaire, énergie, temps) Utilisateurs : Services commerciaux, DCM, DFC. Suivi des Besoins :Disposer de la possibilité d’analyse par rapport à des axes bienrecouvrements déterminés, qui sont :(Zone, Type d’abonnée, client, énergie, temps) Tableau II.4 : Synthétisation des besoins recensés. 68
  • 77. I.2 Problèmes et obstacles rencontrés Bien que notre étude des besoins ait donné lieu aux résultats escomptés, à savoir leuridentification et leur prise en charge, il n’empêche que le travail ne s’est pas effectué sansobstacles, dont les plus importants sont :Difficulté de planifier les entretiens à cause de : - La charge de travail qui nous incombe, - L’emploi du temps chargé des interviewés, - L’organisation du groupe par filiale a limité notre libre circulation au sein du groupe, - Dispersion géographique des structures d’hébergement d’hébergent des services et les personnes à interviewer, • L’indisponibilité de personnes concernées par les entretiens et les annulations de dernière minute, • Les résistances au changement notamment au sein de quelques directions régionales, • La rétention d’informations sous couvert de confidentialité, • L’appréhension, par les utilisateurs, du projet et de sa faisabilité, 69
  • 78. II. Conclusion L’étude des besoins est une étape plus que nécessaire dans un projet Data Warehouse.C’est, en effet, à partir de cette étude que se décidera la manière de construction de l’entrepôtde données et de son architecture. Cette étude des besoins s’est déroulée sur vingt trois entretiens et a concerné quinzepersonnes occupant différents postes à des niveaux hiérarchiques différents. L’ensemble desentretiens a duré plus de 33 heures et nous ont permis tout d’abord d’appliquer les méthodesd’analyse et de collecte d’information. Il nous a permis de connaître d’avantage de détails surles rouages de l’entreprise et d’identifier les besoins analytiques de l’entreprise. Les besoins étant recensés, la construction du Data Warehouse peut alors commencer.Cette construction fera l’objet du chapitre suivant. 70
  • 79. Chapitre IV : Conception de la solution 71
  • 80. Conception de la zone d’entreposage 72
  • 81. I. Introduction Une fois les besoins des utilisateurs connus, nous pouvons commencer à concevoir lesvolets de notre Data Warehouse. Pour cela, nous avons eu recours à la modélisationdimensionnelle qui est souvent associée aux entrepôts de données compte tenu de sesavantages. Cependant, avant de se lancer dans la modélisation, il est intéressant de classer lessujets recensés selon l’intérêt qu’ils représentent pour l’entreprise et les facilités de sréalisation. Ce classement nous aidera à choisir l’activité à modéliser en premier lieu demanière à garantir des résultats satisfaisant pour l’entreprise. satisfaisantsII. Processus de la modélisation dimensionnelle La conception d’un modèle dimensionnel passe par cinq étapes essentielles : • Choix de l’activité à modéliser : ce choix se fait après classement des activités dans une matrice dite d’analyse des priorités [Kimball, 2004]. Cette matrice permet de ’analyse connaître quelle activité choisir en premier. Le classement des sujets recensés, qui s’est fait en collaboration avec les décideurs et les techniciens de l’entreprise, est illustré dans la figure suivante : Figure II.10 : Analyse des priorités du cas « Distribution SONELGAZ ». ONELGAZ • Définition de l’activité et de son grain, • Définition des dimensions qui décrivent une ligne de la table de fait, • Définir les mesurables du fait, éfinir • Définir les agrégats. 73
  • 82. II.1 Volet « Vente » a) Présentation de l’activité « Vente » « Une vente est la cession d’un bien ou dun service en échange dune somme d’argentconvenue entre le vendeur, celui qui cède le bien ou le service, et lacheteur, celui qui paie »[Larousse, 2008]. SONELGAZ, par le biais de ses quatre filiales, propose la vente d’énergie, (électricité ougaz), livré par canalisation jusqu’au lieu de consommation, dans le cadre d’un contrat defourniture. La vente d’énergie, électrique ou gazière, demeure comme l’activité principale des filialesde distribution du groupe SONELGAZ, réalisant la plus grande partie du chiffre d’affaire dugroupe. Les chiffres liés aux ventes se présentent comme des indicateurs d’une grandesignification par rapport à la performance du groupe. Ainsi la disponibilité de cesinformations s’avère indispensable pour les décideurs de l’entreprise. b) Grain de l’activité Le choix du grain le plus fin donne un maximum de flexibilité. Dans le cas des ventesle grain le plus fin, ou le niveau de détail le plus bas, correspond à une opération defacturation12, d’où une ligne de table de fait correspondant à : Suivi de la quantité et du montant de la vente d’une énergie par tarif à un client activant dans un certain domaine à une date donnée.12 Ce n’est qu’après facturation que la quantité et le montant consommé sont arrêtés, d’où la vente. 74
  • 83. c) Les dimensions participantes du modèle sions Les dimensions ont pour objectif de décrire le fait, donc on essaye de recens toutes les recenserinformations qui décrivent une vente et qui peuvent intéresser les décideurs. formations 1. Dimension Temps La dimension temps est « la seule dimension qui figure systématiquement dans toutentrepôt de données, car en pratique tout entrepôt de données est une série temporelle. Letemps est le plus souvent la première dimension dans le classement sous jacent de la base dedonnées » [Kimball, 2001]. La dimension temps se présente com suit : comme Figure II.11 : La Dimension Temps de l’activité « Vente ». 11 Le niveau de détail le plus bas de cette dimension est la journée. En effet, les utilisateursont fait ressortir le besoin de suivre les chiffres au jour le jour et d d’en garder l’historique deces derniers. Dans cette dimension, il est utilisé une clé artificielle comme clé primair Cette clé primaire.artificielle sert à faciliter la manipulation de la dimension. Le tableau suivant donne plus dedétails sur cette dimension : 75
  • 84. Désignation DétailsCode_temps Clé artificielle de la dimension temps.Date La date au format complet.Jour Position du Jour dans le mois.Jour_semaine Nom des jours de la semaine.Mois Nom du mois.Mois_annee Numéro du mois dans l’année.Annee_mois Année et mois (concaténation).Semaine_dans_annee Numéro de la semaine dans l’année.Annee Année de la date.Trimestre Trimestre de la date.Trimestre_annee Trimestre et année (concaténation).Saison Saison à la quelle appartient une date.Evénement Evénement survenu lors de cette date. Tableau II.5 : Tableau descriptif de la dimension « Temps ». 76
  • 85. 2. Dimension client Le client s’impose comme un élément important dans l’analyse et intéresse les l’analyse,analystes et les décideurs de l’entreprise. Outre ce qu’il représente dans une opération devente, l’analyse du comportement du client peut aider l’entreprise à mieux le satisfaire. analyse Figure II.12 : 12 La Dimension Client de l’activité « Vente ». imension La dimension client décrit un client, l’acheteur. Un client est référencié par son lieu deconsommation, cest-à-dire quatre clients qui ont habité le même lieu, sont considérés comme direun seul client. Pour permettre la traçabilité et le suivi d’un client on a introduit une cléartificielle. Celle-ci aide à pallier à l’insuffisance de la codification en vigueur, notammentpour une finalité décisionnelle. Les caractéristiques qui décrivent un client sont: le. 77
  • 86. Désignation DétailsCode_client Clé artificielleReference La référence du lieu de consommationNumero_client Le numéro affecté à un client FSM 13(ce champ est utilisé si le client est un abonné FSM)Nom_client Le nom du client.Adresse_client Adresse du client.Code_postal Code postal du lieu de consommation.Commune Commune du lieu de consommation.Agence Agence à laquelle le lieu de consommation est affilié.Direction_regionale La direction régionale où le lieu de consommation est affilié.Wilaya La wilaya du lieu de consommation.Filiale La filiale à laquelle le lieu de consommation est affilié.Secteur_activite Secteur d’activité du client dans le lieu de consommation.Debit_gaz Débit gaz installé sur le lieu de consommation.Debit_electricite Débit électricité installé sur le lieu de consommation.Type Type du client (ordinaire ou FSM).Groupe Le groupe de facturation du client (Chaque client appartient à un groupe de facturation. Il existe 60 groupes de facturation).Tournee La tournée de relève à laquelle appartient le client. Tableau II.6 : Tableau descriptif de la dimension « Client ».13 FSM : Facturation sur mémoire. 78
  • 87. 3. Dimension facture Une facture est un document relatif au fait de vente. Cette dernière contient un certainnombre d’informations intéressantes pour une analyse. Elle décrit les différentescaractéristiques d’une facture, et qui caractérisent aussi une vente. Figure II.13 : La Dimension Facture de l’activité « Vente ». La facture est identifiée par un numéro facture. Ce même numéro est affecté dans le cas affecté,présent, à la facture en cas d’annulation. L différence entre les deux se fait alors grâce au La ifférencechamp type facture. On pourrait dans ce cas penser à l’adoption d’une clé primaire composée.Cependant une telle clé nuirait fortement aux performances du système. Pour cela, et dans un .souci de performance, on a introduit une clé artificielle à cette table. Ce choix est d’autant artificielleplus justifiable que la dimension est une dimension à évolution rapide. La facture estcaractérisée par : 79
  • 88. Désignation DétailsNumero_facture Clé artificielleNumero_facture_SGC Le numéro facture dans le système source.Date_facture Date de la facturation.Cycle Cycle d’émission de la facture.Type Type de la facture (Emission ou Annulation).Type_releve Type de la relève (les relèves d’index se font de différentes manières).Montant_HT Montant hors taxe.Montant_TTC Montant toutes taxes comprises.Taxe_habitation Taxe habitation.Montant_timbre Montant du timbre.Montant_TVA Montant TVA.Droit_fixes Montant droit fixes.Soutient_etat Montant du soutient de l’état (les wilayas du sud). Tableau II.7 : Tableau descriptif de la dimension « Facture ». 80
  • 89. 4. Dimension zone géographique La dimension zone géographique décrit la zone où le fait a eu lieu. Après l’étude desbesoins au sein du groupe, il parait intéressant de faire des comparaisons par rapport à deszones géographiques. Le grain le plus bas de cette dimension correspond aux communes. Cesdernières sont susceptibles d’évolution dans le temps (appartenance a une filiale ou unewilaya). On jugé donc nécessaire d’introduire une clé artificielle pour permettre le suivi del’évolution de la dimension et d’assurer la cohérence des données. Figure II.14 : La D Dimension Zone géographique de l’activité « Vente ». Les caractéristiques de la dimension « Zone géographique » sont explicitées dans letableau suivant : 81
  • 90. Désignation DétailsCode_zone Clé artificielle.Code_commune Code de la commune.Nom_commune Nom de la commune.Code_agence Code de l’agence (une agence regroupe plusieurs communes).Nom_agence Nom de l’agence.Adresse_agence Adresse de l’agence.Tel_agence Téléphone de l’agence.Code_dd Code de la direction de distribution.Nom_dd Nom de la direction de distribution.Adresse_dd Adresse de la direction de distribution.Tel_dd Téléphone de la direction de distribution.Code_wilaya Code de la wilaya.Nom_wilaya Nom de la wilaya.Code_filiale Code de la filiale de distribution (il y a quatre filiales).Adresse_filiale Adresse de la filiale de distribution.Tel_filiale Téléphone de la filiale de distribution. Tableau II.8 : Tableau descriptif de la dimension « Zone géographique ». 82
  • 91. 5. Dimension activité Figure II.15 : La Dimension Activité de l’activité « Vente ». Cette dimension décrit les différents secteurs d’activités économiques. Celle-ci est schargée à partir d’un tableau transmit par le ministère des finances, et très importante, dès lorsque beaucoup d’analyses observée pendant l’étude des besoins, se base sur cette dimension. observéesDésignation DétailsCode_activité Le code de l’activité.Libellé_activité Libellé de l’activité. Tableau II.9 : Tableau descriptif de la dimension « Activité ». 6. Dimension tarif Figure II.16 : La Dimension Tarif de l’activité « Vente ». 16 Souvent, des analyses sont faite par rapport aux tarifs affectés au client. Cette faitestarification est affectée de manière étudiée selon le type du client. En plus du « code_tarif »,cette dimension contient :Désignation DétailsCode_tarif Le code tarif qui est appliqué actuellement.Abreviation_tarif Abréviation du tarif telle qu’utilisée dans l’entreprise et codifiée sur les documents officiels.Description_tarif Une description sommaire du tarif. Tableau II.10 : Tableau descriptif de la dimension « Tarif ». 10 83
  • 92. 7. Dimension énergie Figure II.17 : La Dimension énergie de l’activité « Vente ». 17 Les filiales de distribution de SONELGAZ livrent plusieurs types d’énergie quidifférent par un certain nombre de caractéristiques Avoir une segmentation par rapport à une caractéristiques. voircaractéristique ou à une autre est très intéressant lors d’une analyse. Une énergie est décrite nepar les caractéristiques suivantes :Désignation DétailsCode_energie Code énergie débit/typeType_energie Type de l’énergieDebit DébitUnite_mesure Unité de mesure de l’énergie Tableau II.11 : Tableau descriptif de la dimension « Energie». 11 8. Dimension dégénéré « Puissance maximale » dégénérée Les clés étrangères de la table de fait référencent les dimensions qui représentent lecontexte du fait. Cependant il existe des clés ne référençant aucune dimension, ces dernièressont dites dimensions dégénérées. La dimension puissance maxmaximale est dans ce cas un exemple de ce type de stdimension. En effet, celle-ci ne contient aucune description textuelle et elle ne peut êtreassimilée à aucune autre dimension. Elle est identifiée par sa valeur dans la ta table des faits etfournie grâce à ce dernier la possibilité d’analyser les ventes selon la puissance maximale ventesdemandée par le client. 84
  • 93. d) Les mesurables Les mesurables qui correspondent à l’activité des ventes et qui permettent de mesurer lesperformances de cette activité, sont la « quantité vendue » et le« montant de la vente en horstaxe » et les « primes fixes ». 85
  • 94. e) Le modèle en étoile de l’activité « Vente » Figure II.18 : Modèle en étoile de l’activité « Vente ». 86
  • 95. f) Les agrégats Les tables d’agrégats améliorent les performances du Data Warehouse, en réduisant lenombre de lignes que le SGBD manipule afin de répondre à une requête. Cela se fait grâce àl’agrégation des données contenues dans les tables de faits détaillées et qui sont stockées dansde nouvelles tables de faits. La construction des agrégats se base sur le modèle en étoile détaillée, et ellepeut nécessiter: • La création de nouvelles dimensions dérivées : la construction d’un modèle agrégé nécessitera la suppression de quelques attributs d’une dimension qui désigne le grain le plus fin. • La suppression de quelques dimensions : le modèle agrégé peut engendrer l’élimination de certaines dimensions qui n’apparaissent pas au niveau de détail voulu. On peut aussi : • Créer de nouveaux faits: lors de la création de la table de faits agrégée on peut rajouter quelques faits qui n’existaient pas dans la modèle de base. En effet, l’usage et la signification des tables agrégées peuvent différer du modèle de base. • Créer des tables pré-jointes : une table d’agrégat peut être construite à partir d’une jointure entre la table de faits et une ou plusieurs dimensions. Le résultat est stocké dans une seule table dite pré-jointure. Une table d’agrégat peut être invisible ou visible à l’utilisateur final : • Elle est invisible lorsqu’elle reflète exactement le modèle de base • Elle est visible lorsqu’elle contient des faits supplémentaires. Les résultats issus d’une table agrégée ou du modèle de base doivent être identique. Pour cette phase, on s’inspire de la démarche décrite par C. Adamson dans son livre« Mastering the Data Warehouse Aggregates, Solution for Star Schema Performance ». Ladémarche consiste à : 1- Enumérer les agrégats potentiels à partir d’une étoile détaillée : pour détecter les agrégats potentiels et choisir ceux à implémenter dans le Data Warehouse. Il est nécessaire de bien décrire chaque agrégat. 2- Détecter les agrégats utiles : choisir des agrégats utiles à partir des agrégats potentiels. 3- Construire le modèle agrégé : enfin on construit le modèle agrégé tout en prenant en considération les dimensions dérivées commune entre les différents modèles. Les agrégats sont conçus, en général, comme des modèles dimensionnels. 87
  • 96. 1) Les agrégats potentiels Le tableau suivant décrit, d’une manière simple et efficace, les agrégats potentiels dumodèle dimensionnel de base de l’activité des ventes: Nombre Dimension Agrégats potentiels d’agrégats possiblesTemps Mois, trimestre, année, saison 4Energie Type, débit 3Activité Code activité 1Tarif Tarif 1Zone Tournée, agence, commune, DR, wilaya, filiale 6Facture Date, cycle, type, relève 4 Numéro, commune, agence, DR, wilaya, filiale, activité,Client 10 débit gaz, débit électricité, type Tableau II.12 : Liste des agrégats potentiels pour l’activité « Vente ». 2) Les agrégats utiles : Les agrégats potentiels ne sont pas en effet tous utiles, soit par le nombre de lignesagrégées ou par les informations fournies. Pour cela on réduit la liste des agrégats à ce quisuit : Dimension Agrégats utiles Nombre d’agrégats retenusTemps Mois, trimestre, année, saison 4Energie Type, débit 3Activité Code activité 1Tarif Tarif 1Zone Commune, agence, DR, wilaya, filiale 5Facture Cycle, type, relève 4 Tableau II.13 : Liste des agrégats utiles de l’activité « Vente ». A partir du tableau précédent nous choisissons les agrégats qui nous semblent les pluspertinents et susceptibles de faire l’objet d’accès fréquents. nous arrêtons la liste des modèlesagrégats suivants : • Ventes journalières par type d’énergie par activité par commune. • Ventes mensuelles par DR (agrégation de plus de dix mille lignes). • Ventes mensuelles par cycle par type de relève (agrégation de plus de trois millions lignes). La modélisation des agrégats se fait grâce aux principes de la modélisationdimensionnelle. 88
  • 97. II.2 Volet « Recouvrement » a) Présentation de l’activité « Recouvrement » « Action de recouvrer, de retrouver ce qui était perdu, des sommes dues ». [Larousse,2008] Une suite logique au fait de vente, c’est le recouvrement des sommes dues aux clients.Une somme peut passer par plusieurs phases ou états : facturée, impayée, payée, prés-contentieux, contentieux et apurée. Cette terminologie obéit à un jargon au sein del’organisation pour définir une créance ou un avoir. Ces états correspondent aux différents comptes de recouvrement. Le mouvement d’uncompte à l’autre se fait par rapport aux délais de recouvrement. L’entreprise s’intéresse ausuivi de l’état journalier de ces comptes afin de suivre de près cette activité très importante. b) Grain de l’activité : Le grain le plus fin de l’activité correspond à : Suivi du montant et de l’état d’une facture d’un client appartenant à une zone géographique et activant dans un certain domaine à une date donnée c) Les dimensions participantes du modèle Les dimensions communes Après la détection des dimensions de la nouvelle étoile, on procède à une mise enconformité des dimensions communes. Pour ce faire, on construit un tableau qui croise lesétoiles conçues avec leurs dimensions. Le but étant de détecter les dimensions communespour leurs mises en conformité. Le tableau suivant illustre cela : Etoile Vente Recouvrement Dimensions Client √ √ Zone géographique √ √ Temps √ √ Facture √ √ Activité √ √ Nature √ Tableau II.14 : Détection des dimensions communes entre les volets « Vente » et « Recouvrement ». A cette étape il existe quatre dimensions communes. Ces dimensions étant trèsdétaillées dans la première étoile, il n’y a pas eu nécessité de recourir à une mise enconformité. Cette remarque reste valable pour l’ensemble du document, ainsi il n’y a pas lieude détailler les dimensions communes à la présentation de chaque étoile. 89
  • 98. 1. Dimension nature Figure II.19 : La Dimension nature de l’activité « Recouvrement ». La dimension « nature » décrit la nature du montant contenu dans le fait, ou plusprécisément le compte dont il est comptabilisé à un moment donné. La dimension contient lesinformations listées dans le tableau suivant :Désignation DétailsCode_nature Clé artificielleLibelle Libellé de la nature du montantOperation Libellé de l’opération relative au montant Tableau II.15 : Tableau descriptif de la dimension « Nature ». 15 d) Les mesurables Le mesurable qui correspond à l’activité « recouvrement » et qui permet de mesurerles performances de cette activité, est le « montant de l’opération en tout taxes toutescomprises ». 90
  • 99. e) Le modèle en étoile de l’activité « Recouvrement » Figure II.20 : Modèle en étoile de l’activité « Recouvrement ». 91
  • 100. f) Les agrégats 1) Les agrégats potentiels NombreDimension Agrégats potentiels d’agrégats possiblesTemps Mois, trimestre, année, saison 4Nature Opération, nature 2Activité Code activité 1Zone Tournée, agence, commune, DR, wilaya, filiale 6Facture Date, cycle, type, relève 4 Numéro, commune, agence, DR, wilaya, filiale, activité,Client 10 débit gaz, débit électricité, type Tableau II.16 : Tableau descriptif des agrégats potentiels du modèle « Recouvrement ». 2) Les agrégats utilesDimension Agrégats utiles Nombre d’agrégats possiblesTemps Mois, trimestre, année, saison 4Activité Code activité 1Zone Commune, agence, DR, wilaya, filiale 5Facture Cycle, type, relève 4 Tableau II.17 : Tableau descriptif des agrégats utiles du modèle « Recouvrement ».Nous arrêtons la liste des agrégats suivants : • Montant et nombre des factures des comptes de recouvrement journalier. par nature par activité par commune. • Montant et nombre de facture mensuel par opération par commune. • Montant et nombre de facture par nature par type client. 92
  • 101. II.3 Volet « Suivi des affaires » a) Présentation de l’activité « Suivi des affaires » Une affaire est une demande initiée soit par la clientèle ou par l’agence et qui nécessite unemise à jour de la base de données. Cet événement se traduit par l’enregistrement d’une affairequi sera suivie jusqu’à son aboutissement. Parmi les modules du « SGC », le module « Gestion des Affaires » gère les affaires liées ala « Basse Moyenne Pression, Basse Moyenne Tension » depuis leurs enregistrements jusquàleurs réalisations. Ce module génère chaque jour, et au niveau de chaque direction dedistribution, une masse de données considérable. Ces données représentent une sourced’information plus qu’indispensables pour le groupe et ses filiales de distribution. D’où lanécessité de suivre cette activité. b) Grain de l’activité Le grain le plus fin de l’activité suivi des affaires représente, en réalité, la possibilité desuivre une affaire selon des critères différents. Le grain peut alors être donné comme suit : Suivi dans le temps, et selon leur type, les affaires qui concerne un client selon son activité et qui sont initiées au niveau de chaque commune. c) Les dimensions participantes Les dimensions communes D’après le grain de l’activité on peut déjà savoir les dimensions qui seront présentes dansnotre étoile et qui sont listées dans le tableau. Ces dimensions sont indispensables pourrépondre au grain de l’activité. Aussi, et afin d’offrir un suivi plus complet et plus aisé, on ajugé nécessaire d’introduire la «Dimension phase affaire ». Etoile Vente Recouvrement Suivi des affaires Dimension Client √ √ √ Zone géographique √ √ √ Temps √ √ √ Facture √ √ √ Activité √ √ √ Affaire √ Type affaire √ Phase √ Tableau II.18 : Détection des dimensions communes entre les volets « Vente », « Recouvrement » et « Suivi des affaires ». 93
  • 102. 1. Dimension affaire La dimension affaire est une dimension indispensable pour faire une bonne analyse dans tcette étoile. En effet, afin de bien suivre une affaire nous avons besoin du maximumd’information la concernant. Cette dimension décrit donc une affaire qui est identifiée par sonnuméro « le numéro de l’affaire est unique au niveau national » et qui est caractérisée par sondegré d’urgence et son initiateur itiateur. Figure II.21 : La D Dimension affaire de l’activité « Suivi des affaires ». uivi Cette dimension est une dimension à évolution rapide. Cela se vérifie par le nombre dimensiond’affaires initiées quotidiennement par agence Cette dimension fournie les informations agence.suivantes :Désignation DétailsNumero_affaire Un numéro d’ordre donné par le système et qui évolue à chaque enregistrement.Degre_urgence Représente le degré d’urgence de l’affaire. Certaine affaires Certaines sont plus urgentes que d’autres.Observation Observation relative à l’affaire.Initier_par Permet de connaitre l’initiateur de l’affaire (agence, client, DD). Tableau II.19 : Tableau descriptif de la dimension « Affaire ». 19 94
  • 103. 2. Dimension type affaire Cette dimension nous renseigne sur le type de l’affaire. Les types sont classés en catégories igne Lesd’après la nature de l’affaire, ensuite en sous catégories d’après l’énergie concernée. En plusde l’appartenance d’une affaire à une catégorie, cette dimension nous renseigne sur d’autrescaractéristiques à savoir l’énergie de l’affaire et sa durée approximative. nergie a Figure II.22 : La Dimension type affaire de l’activité « Suivi des affaires ». imension uivi La dimension est une dimension à évolution lente. En effet, l’ajout d’une catégorie estpeu fréquent. Le détail de cette dimension est le suivant :Désignation DétailsCode_affaire Code de l’affaire tel qu’il est connu au sein du groupe.Intitule_affaire Intitulé du type de l’affaire.Code_categorie Le code de la catégorie à laquelle appartient un type quelle d’affaires.Intitule_categorie L’intitulé de la catégorie à laquelle appartient un type quelle d’affaires.Code_ss_categorie Code de la sous catégorie. Chaque catégorie est divisé en divisée sous catégories.Intitule_ss_categorie Intitulé de la sous catégorie.Duree_aproximative Une approximation en jours de la durée de l’affaire. Tableau II.20 : Tableau descriptif de la dimension « Type affaire». 95
  • 104. 3. Dimension phase Chaque affaire transite, durant son cycle de vie, par un certain nombre de phases. CeCelles-ciont été normalisées et codifiée de manière à ce qu’elles puissent être utilisées conjointement es ssentpar toutes les affaires. La dimension phase reprend donc la codification utilisée par le« SGC » pour identifier ces phases. L’utilisation d’une telle dimension facilite grandement lacompréhension du modèle dimensionnel et conférera une certaine aisance d’implémentationet de gestion de l’alimentation de l’étoile. Figure II.23 : La Dimension phase de l’activité « Suivi des affaires ». uiviLe tableau suivant donne le détail de cette dimension :Désignation DétailsCode_phase Code des phases par lesquelles transitent les affaires. ntIntitule_phase Intitulé de chaque phase.Description_phase Description textuelle de chaque phase. Tableau II.21 : Tableau descriptif de la dimension « Phase». 21 d) Les faits mesurés Cette étoile n’a pas de mesurables a proprement parlé. La table de fait dans ce cas est faitsappelée une « Table de faits sans faits ». Ce genre de table permet de renseigner sur le nombreet l’évolution des affaires dans le temps. 96
  • 105. e) Modèle en étoile de l’activité « suivi des affaires » Figure II.24 : Modèle en étoile de l’activité « Suivi des affaires ». 97
  • 106. f) Les agrégats 1) Les agrégats potentiels NombreDimension Agrégats potentiels d’agrégats possiblesTemps Mois, trimestre, année, saison 4Activité Code activité 1Zone Tournée, agence, commune, DR, wilaya, filiale 6 Numéro, commune, agence, DR, wilaya, filiale, activité,Client 10 débit gaz, débit électricité, typeType affaire Code catégorie, code sous catégorie 2 Tableau II.22 : Tableau descriptif des agrégats potentiels du modèle « Suivi des affaires ». 2) Les agrégats utilesDimension Agrégats utiles Nombre d’agrégats possibleTemps Mois, trimestre, année, saison 4Activité Code activité 1Zone Commune, agence, DR, wilaya, filiale 6Type affaire Code catégorie, code sous catégorie 2 Tableau II.23 : Tableau descriptif des agrégats utiles du modèle « Suivi des affaires ». On va arrêter la liste des agrégats suivants : • Nombre et durée des affaires par commune. • Nombre et durée des affaires par secteur d’activité. 98
  • 107. II.4 Volet « Suivi des abonnés » a) Présentation de l’activité « Suivi des abonné » Un abonnement électrique (ou gazier) est une contrepartie aux services qui sont renduspar le gestionnaire du réseau public de distribution. Principalement l’acheminement del’électricité, et du gaz de la centrale au lieu de consommation de l’abonné. L’abonné est la partie bénéficiaire du service, en contrepartie il doit honorer sesengagements relatifs au contrat d’abonnement. Lors de notre étude des besoins, un des sujets auquel s’intéressent les décideurs est lesuivi des abonnés : abonnement, mise en service, résiliation…. En effet, le nombre d’abonnésse présente comme un des indicateurs de performances de l’entreprise, d’où l’intérêt desuivre la réalisation des objectifs tracés. b) Grain de l’activité : Le grain le plus fin de l’activité correspond à : L’historique complet d’un abonné par type, zone géographique et par activité. c) Les dimensions participantes du modèle : 1. Les dimensions communes Le tableau suivant nous donne la liste des dimensions communes entre toutes lesétoiles :Etoile Vente Recouvrement Suivi des Suivi desDimension abonnés abonnésClient √ √ √ √Zone √ √ √ √géographiqueTemps √ √ √ √Activité √ √ √ √Type abonné √ √ Tableau II.24 : Détection des dimensions communes entre les volets « Vente », « Recouvrement », « Suivi des affaires » et « Suivi des abonnés ». 99
  • 108. 2. Dimension type abonné La dimension type abonné contient une description d’un abonné par le type depaiement (domicilié ou non domicilié) et par rapport au type du lieu de consommation. domicilié) Figure II.25 : la Dimension T Type abonné de l’activité « Suivi des abonné ». abonnésDésignation DétailsCode_type_abonne Clé artificielle du type abonnéType_paiement Type abonné selon ses paiementsType_ lieu Type abonné selon le lieu de consommation Tableau II.25 : Tableau descriptif de la dimension « Type abonné ». d) Les mesurables Dans ce cas on se retrouve avec une table de faits sans faits. Cette table a pour objectifs detracer l’historique d’un abonné du jour de son abonnement à son éventuelle résiliation. éventuelle 100
  • 109. e) Le modèle en étoile de l’activité « Suivi des abonnés » Figure II.26 : Modèle en étoile de l’activité « Suivi des abonnés ». 101
  • 110. f) Les agrégats 1. Les agrégats potentiels NombreDimension Agrégats potentiels d’agrégats possiblesTemps Mois, trimestre, année, saison 4Type abonné Lieu, paiement 2Activité Code activité 1Zone Tournée, agence, commune, DR, wilaya, filiale 6 Numéro, commune, agence, DR, wilaya, filiale, activité,Client 10 débit gaz, débit électricité, type Tableau II.26 : Tableau descriptif des agrégats potentiels du modèle « suivi abonnés ». 2. Les agrégats utilesDimension Agrégats utiles Nombre d’agrégats possiblesTemps Mois, trimestre, année, saison 4Activité Code activité 1Zone Commune, agence, DR, wilaya, filiale 6Type abonné Lieu, paiement 2 Tableau II.27 : Tableau descriptif des agrégats utiles du modèle « suivi abonnés ».On va arrêter la liste des agrégats suivants : • Nombre d’abonnements par commune par jour. • Nombre de résiliations par commune par jour. • Nombre de mises en service par commune par jour. 102
  • 111. III. Conclusion La zone d’entreposage constitue la zone exploitable par les utilisateurs. La modélisationde cette zone se fait grâce à la modélisation dimensionnelle. Cette manière de représenter lesdonnées offre aux utilisateurs des modèles intuitifs et compréhensibles permettant denaviguer et de manipuler les données, détaillées ou agrégées, sans difficulté afin de satisfaireleurs besoins en analyse. La finalisation de la conception d’une étoile de l’entrepôt, nous permet de passer à laconstruction de la zone d’alimentation. Cette zone d’alimentation constitue l’objet duprochain chapitre. 103
  • 112. Conception de la zone « alimentation » 104
  • 113. I. Introduction L’ETL, ou l’alimentation du Data Warehouse, est une étape des plus importantes dansun projet Data Warehouse, elle représente 80% de la charge de travail. Cette étape a pourobjectif d’assurer l’acheminement des données des systèmes sources jusqu’à l’entrepôt dedonnées, en passant par les différentes phases de nettoyage et de transformations nécessaires. La conception du processus d’alimentation nécessite les étapes suivantes : • Etude et planification, • Choix de l’architecture, • Conception des processus de chargement : o Processus de chargement des tables de dimension, o Processus de chargement des tables de faits, o Processus de chargement de table temps,II. Etude et planification : Cette phase représente une phase préliminaire à l’ensemble du processus. Elle consisteen : • L’étude des sources de données, • La détection des emplacements des données source, • La Définition de la périodicité du chargement, II.1 Les sources de données : Les sources de données de notre entrepôt sont : • Le système SGC, avec ses 35 modules (voire annexe C), • Le système de gestion de la distribution HT/HP, • Les fichiers plats, en provenance d’autres structures (pour les achats), ou d’organismes externes (le ministère des finances), Les sources de données en chiffres: • 58 sources de données, éparpillées sur l’ensemble du territoire national, • Plus de 6 millions de clients, • Plus de cent trente intégrations d’abonnés jour, • Soixante-dix mille factures jour, 105
  • 114. II.2 Détection des emplacements des données sources : Afin de définir l’emplacement des informations dans les différents systèmes source etd’en choisir les emplacements les plus fiables, nous avons travaillé de manière étroite avec lesDBA et les gestionnaires. Le nombre important de tables, la redondance des données et l’intervention dedifférents systèmes, rendent cette tâche très ardue. Afin de mener à bien cette détection, nousdevons : • Lister les données nécessaires à partir des étoiles conçues, • Lister les emplacements de chaque donnée, • Choisir la source la plus fiable et la valider comme source de chargement, • Dresser un tableau14 qui établi le lien entre données sources et donnée cibles avec les transformations nécessaires, Cette étape s’achève par l’élaboration d’une carte logique entre données sources etdonnées cibles15. Il est important de valider les sources de données (donc le tableau citéprécédemment), afin de vérifier leurs intégrités et leurs fiabilités. II.3 Définition de la périodicité de chargement La périodicité de chargement est étudiée pour chaque étoile séparément. , ce quin’empêche pas une synchronisation dans les chargements des dimensions communes. Avant de décider de la périodicité du chargement, les contraintes suivantes doiventêtre prises considération : • La quantité de données à charger, • Le temps de non activité des systèmes sources, L’étoile qui engendrera les chargements les plus importants, en termes de volume,n’est autre que l’étoile des ventes. En effet, le système de facturation, établit annuellementplus de six millions de factures, ce qui représente plus de dix millions de lignes de faits« ventes ». Ce processus s’exécute de façon journalière (soixante-dix mille lieux deconsommation par jour). Aussi, le module de gestion des affaires (Système source) présenteune forte volatilité de ses données. Cette volatilité est due au fait que le passage, d’une affairedonnée, d’une phase à une autre, ne laisse aucune trace sur la base de données opérationnelle.14 Ce tableau est décrit dans le livre [Kimball 2004].15 Voire Annexe D 106
  • 115. De ce fait, l’idéal est de procéder à des chargements journaliers, pendant les heures denon activité des systèmes sources, cest-à-dire, durant la période qui s’étend entre dix-huitheures et huit heures du matin. Pourquoi pas des chargements hebdomadaires Même si pendant les week-ends le nombre d’heures de non activité des systèmes estplus important, la quantité de données à charger sera, elle, plus conséquente, et affectera lesperformances du processus de chargement. Par ailleurs, la volatilité de certaines donnéesnous contraint à appliquer une telle politique de chargementIII. Architecture du processus d’alimentation L’élaboration d’une architecture du processus de l’alimentation « ETL » dès le débutdu projet est très importante. En effet, le choix d’une architecture affecte pratiquement toutesles composantes du projet. Tout changement de celle-ci engendrera nécessairementd’importants changements dans l’ensemble du projet. Partant de ce constat, il est nécessaire de mettre en place une architecture consistante àmême de prendre en charge toutes les contraintes auxquelles on doit faire face. Le processus de l’ETL peut se faire de différentes manières. Dans le cas d’espècenous avons choisi la méthode « Push-Pull ». En plus des avantages qu’elle présente, cetteméthode pallie aux contraintes rencontrées au sein de l’entreprise et permet d’exploiter toutesles opportunités offertes. Parmi les contraintes et opportunités il peut être cité : • L’impossibilité d’accès distant aux systèmes source : l’entreprise n’autorise pas des accès distants aux systèmes sources. L’accès se fera par le biais d’une base de données intermédiaire. Cette restriction est due à la structure organisationnelle de l’entreprise16. • Les problèmes du réseau actuel17 : le réseau actuel subi des perturbations au niveau de quelques directions de distribution. Ces dernières ne sont pas encore équipées de connexion ADSL18. • Le nombre important des sources de données et la quantité des données : Cette politique (push-pull) permettra le lancement de chargements parallèles. • L’existence de serveurs au niveau sources : les cinquante-huit directions de distribution disposent de matériel informatique important, permettant de lancer des processus de préparation de données au niveau des « DD ». • Maintenance facile: même si les sites sont éparpillés, la tâche d’une éventuelle maintenance sera facilitée par le biais des équipes informatiques en place.16 Le découpage juridique de l’entreprise ne permet pas aux filiales de partager des informations d’une façondirecte.17 Voire annexe F.18 Plus de quarante D.D sont équipées de connexion ADSL. 107
  • 116. Pourquoi adopter cette architecture ? Outre un chargement sûr, Cette architecture permet de:• Réduire les temps de chargement : grâce au chargement parallèle, le temps de traitements sera réduit.• L’impact réduit d’un chargement échoué : l’échec d’un chargement aura un impact réduit sur les données du Data Warehouse.• La possibilité de mise en place d’une nouvelle façon d’accès : dans une architecture « Push-Pull » il est préférable de faire un transfert de fichiers, par exemple via FTP. cette méthode très performante « testée » est difficile à déployer, elle sera donc mise en perspective. La figure suivante illustre l’architecture du processus d’alimentation adoptée : Figure II.27 : Architecture globale du processus E.T.L. Dans la zone de préparation« Staging area » les données sont extraites à partir dessources de données, transformées et préparées pour le chargement final. Au niveau duserveur « ELIT » il est procédé à l’affectation de clés artificielles et à quelquestransformations nécessaires avant le chargement final dans la zone d’entreposage. Aprèschaque chargement, une mise à jour des Meta Data doit être faite. 108
  • 117. IV. Processus de chargement Le diagramme d’activités suivant décrit le processus général de l’alimentation del’entrepôt de données dés sa mise en service : Figure II.29 : Diagramme d’activité du processus d’alimentation. 109
  • 118. Deux types de tables dans l’entrepôt de données « faits, dimensions » doivent êtredistingués. Chaque type de table diffère dans les d’informations qu’il contient, et d’où doncl’adoption de deux processus de chargement. La stratégie d’extraction adoptée consiste à comparer des chargements successifs afin dedétecter les changements. Cette stratégie, étant la plus fiable, est incontournable pour lacapture des changements pour des raisons de non fiabilité des champs date, généralement nonrenseignés. Cette détection se fait au niveau de la zone de préparation améliorantsensiblement les performances. IV.1 Processus de chargement de dimension Les tables de dimension constituent le contexte de la table de faits. Elles représentent lepoint d’entrée au Data Warehouse. Une dimension est généralement constituée : d’une cléartificielle, d’une clé naturelle et des attributs. Le processus de chargement de dimension doit, outre le chargement des données, assurer : • La gestion des clés artificielles: affectation des clés et mise en correspondance avec les clés naturelles. • La gestion de l’évolution de dimension : gérer les changements que subissent les dimensions. Il existe trois types de traitement par rapport à l’évolution d’une dimension : o Type 1 « écrasement » : consiste à mettre à jour l’attribut subissant un changement. o Type 2 « création d’un nouvel enregistrement » : consiste à créer un nouvel enregistrement afin de sauvegarder tout le cycle d’évolution de la dimension. o Type 3 « déplacement de la valeur a changé dans un attribut ancien » : consiste à prévoir des attributs pour enregistrer les changements éventuels. Il permet de sauvegarder un nombre défini de changements. 110
  • 119. Le digramme suivant illustre la politique que nous avons retenue : Figure II.30 : diagramme d’activité du processus de chargement de dimension. 111
  • 120. La stratégie adoptée pour la détection des changements se fait grâce à la comparaisonentre le dernier chargement et le chargement actuel. Cette méthode, comme décrite lors de lasynthèse bibliographique, est la plus fiable pour la capture des changements. Les mises à jour de type 3 sont traitées comme de nouvelles insertions, avec la mise à jourde la table références. IV.2 Processus de chargement des tables de faits L’extraction des faits se fait avec les clés naturelles utilisées dans les systèmes sources.L’étape qui précède le chargement de la table des faits consiste à remplacer les clés naturellespar les clés artificielles. La substitution peut se faire directement par le biais des tables dedimension, ce qui est correct mais très lent. Pour cela on utilise des tables de référencement. Le processus de chargement des tables des faits doit garantir l’intégrité référentielle vis-à-vis des tables de dimensions. Le diagramme d’activité suivant illustre le processus de chargement adopté pour une tablede faits : 112
  • 121. Figure II.31 : diagramme d’activité du processus de chargement de faits. Le chargement de la table de fait peut être une insertion, ou une mise à jour des tables defaits. 113
  • 122. IV.3 Processus de chargement particulier Dans un entrepôt de données il y a des tables particulières, soit : la table de la dimensiontemps et les tables d’agrégats, nécessites un traitement à part. IV.3.1 Processus de chargement de la dimension temps Contrairement aux autres dimensions, la dimension temps contient uniquement des datesqui ne sont pas forcément extraites à partir des systèmes sources. Cette dimension doitcontenir, en effet, toutes les dates qui coïncident, ou coïncideront, avec un fait donné. Elleparticipe à toutes les étoiles et assure l’historisation. Dès lors, il est préférable de construire uncalendrier : « La dimension date est plus souvent construite comme étant un calendrier avec unegranularité journalière ». [Kimball, 2004]. IV.3.2 Processus de construction d’agrégats Après le chargement d’une étoile, les tables d’agrégats doivent être chargées par le biaisde l’ETL et à partir des données détaillées. En plus du calcul des agrégats et de leur insertion,des mises à jour fréquentes de ces tables sont indispensables. 114
  • 123. V. Conclusion Un processus E.T.L a pour mission d’assurer la livraison de données conformes,cohérentes et correctes tout en assurant des performances acceptables. Lors de la conceptiondu processus de l’ETL il a été envisagé d’atteindre les objectifs suivants: • Assurer le chargement des données et leur qualité, • Assurer la transparence des processus de chargement et de consolidation qui assure la qualité des données, • Ne pas nuire aux performances des systèmes sources, • Utiliser des sources, autres que les sources opérationnelles pour donner une valeur ajoutée aux informations, • Permettre un suivi de l’avancement des chargements, et corrections en cas d’erreur, • Offrir une documentation complète du processus, afin de faciliter la maintenance ainsi que l’amélioration, • Offrir une performance optimale grâce aux chargements parallèles et séparation des données selon l’opération de chargement (mise à jour ou nouvelle insertion), • Mettre en œuvre des solutions secours pour faire face aux problèmes réseau, • Mise à jour des Meta data, pour la maintenance et l’assurance de la qualité de données, 115
  • 124. Conception des cubes dimensionnels 116
  • 125. I. Introduction Afin de faciliter l’analyse et la navigation dans les données, il est important que lescubes dimensionnels soient bien conçues et définis de manière claire pour une utilisationintuitive. La conception des cubes dimensionnels passe par la définition des mesurables, desdimensions et des hiérarchies présentes au sein des dimensions, ainsi que les différentsniveaux de détails de chaque hiérarchie. Le but de la mise en place de ces cubes est d’offrirune représentation abstraite dinformations multidimensionnelles à des fins d’analyse. Le choix des cubes à construire, des mesurables qu’ils contiendront, des dimensionsparticipantes dans chacun d’entre eux et des hiérarchies qui constituera chaque dimensiondépend essentiellement des besoins recensés et de l’utilisation finale.II. Définition des niveaux et des hiérarchies La définition des différentes hiérarchies présente dans une dimension est une étapecruciale et indispensable pour la conception des cubes. En effet, c’est grâce à ces hiérarchiesque l’utilisateur pourra naviguer et explorer à bon escient les informations offertes par uncube donné.Cette étape se déroule en deux phases: • Identification des attributs d’un même niveau pour chaque dimension. • Construction des hiérarchies (Une dimension peut avoir plusieurs hiérarchies).Au final nous obtiendrons le tableau récapitulatif suivant : Dimension Colonne Niveaux Hiérarchies code_activite Hierarchy_1 : dim_activite Niveau_1 : N1 libele_activite N1 ALL numero_affaire observation degre_urgence Hierarchy_1 : dim_affaire Niveau_1 : N1 N1 ALL initier_par commune wilaya 117
  • 126. code_client reference_lc Niveau_1 : N1 Hierarchy_1 : type N1 N2 N3 ALLdim_client numero_client Niveau_2 : N2 Hirarchy_2 : N1 N3 ALL Groupe Niveau_3 : N3 numero_facture numero_facture_s gc date_facture taux_tva Niveau_1 : N1 Hierarchy_1 : soutient_etat N1 N2 N3 N4 ALL conso_moy_enrgidim_facture e_jour Hierarchy_2 : N1 N2 N4 N3 ALL reference_lc type_facture Niveau_2 : N2 type_releve Niveau_3 : N3 type_cycle Niveau_4 : N4 code_energie Hierarchy_1 : type_energie Niveau_1 : N1 N2 N1 ALLdim_energie unite_mesure Hierarchy_2 : Debit Niveau_2: N2 N2 N1 code_nature Niveau_1 : N1 Hierarchy_1 : lib_naturedim_nature N2 N1 ALL operation Niveau_2 : N2 code_phase intitule_phase Hierarchy_1 :dim_phase desc_phase Niveau_1 : N1 N1 ALL durree_estimee_p hase code_tarif description_tarif Niveau_1 : N1 Hierarchy_1 : dim_tarif abreviation_tarif N1 N2 ALL Energie Niveau_2 : N2 118
  • 127. code_temps date jour_du_mois Niveau_1 : N1 jours evenement semaine_dans_ann Niveau_2 : N2 ee mois_annee Hierarchy_1 : Niveau_3 : N3 N1 N2 N3 N4 annee_mois dim_temps N5 N6 ALL mois annee_trimestre Niveau_4 : N4 trimestre Saison Niveau_5 : N5 Annee Niveau_6 : N6 code_type_abonne Niveau_1 : N1 e Hierarchy_1 : N1 N2 N3 All type_client_domic Niveau_2 : N2dim_type_abonn iliation Hierarchy_2 : e N1 N3 N2 All type_client_paiem Niveau_3 : N3 ent code_affaire intitule_affaire energie_affaire Niveau_1 : N1 durree_approxima tive Hierarchy_1 :dim_type_affair N1 N2 N3 All code_ss_categorie e Niveau_2 : N2 intitule_ss_categor ie code_categorie Niveau_3 : N3 intitule_categorie 119
  • 128. code_zone code_commune Niveau_1 : N1 commune code_agence Niveau_2 : N2 agence code_dr Hierarchy_1 : dr Niveau_3 : N3 N1 N2 N3 N4 dim_zone N5 ALL code_wilaya Niveau_4 : N4 wilaya code_filiale filiale Niveau_5 : N5 adresse_filiale tel_filiale Tableau II.28 : Tableau donnant les niveaux et les hiérarchies de chaque dimension. Le niveau « All » : Ce niveau représente le niveau le plus haut d’une hiérarchie. De cefait, il est le niveau le plus agrégé. Le niveau « ALL » n’apparaît pas systématiquement danstoutes les hiérarchies. 120
  • 129. III. La liste des cubes Dans ce qui suit nous allons dresser la liste des cubes à mettre en place. Pour chaquecube on donnera les dimensions participantes ainsi que les mesurables présents dans cescubes. Il est à signaler aussi que la dimension « dim_nature » n’apparaitra nul part dans ladescription des cubes. En effet, cette dimension a été remplacée par l’utilisation demesurables dans les cubes concernés. Le tableau suivant donne le détail de la conception deces cubes : Les Hiérarchies Nom du cube Les mesurables Les dimensions de la dimension Dim_client Hierarchy_1 Hierarchy_1 Dim_facture Hierarchy_2 Hierarchy_1 Dim_energie 1. Chiffre d’affaires Hierarchy_2 Suivi des ventes 2. Nombre de factures Dim_zone Hierarchy_1 Dim_temps Hierarchy_1 Dim_tarif Hierarchy_1 Dim_client Hierarchy_1 Dim_facture Hierarchy_1 1. Chiffre d’affaires Dim_energie Hierarchy_2Suivi des ventes et 2. Consommationdes consommations 3. Nombre de consommations nulles Dim_zone Hierarchy_1 Dim_temps Hierarchy_1 Dim_tarif Hierarchy_1 Hierarchy_1 Dim_type_abonné Hierarchy_2 Dim_zone Hierarchy_1 Suivi de l’apport 1. Nombre de raccordements abonné Dim_client Hierarchy_1 Dim_temps Hierarchy_1 121
  • 130. Hierarchy_1 Dim_type_abonné Hierarchy_2 Dim_zone Hierarchy_1 Suivi des 1. Nombre de résiliations résiliations Dim_client Hierarchy_1 Dim_temps Hierarchy_1 Hierarchy_1 Dim_type_abonné Hierarchy_2 Dim_zone Hierarchy_1Suivi des mises en 1. Nombre de mises en service. service Dim_client Hierarchy_1 Dim_temps Hierarchy_1 Dim_client Hierarchy_1 Dim_energie Hierarchy_1 Dim_zone Hierarchy_1 1. Nombre d’affairesSuivi des affaires Dim_temps Hierarchy_1 2. Durée dim_type_affaire Hierarchy_1 dim_phase Hierarchy_1 dim_affaire Hierarchy_1 Dim_temps Hierarchy_1 1. Montant créances 2. Montant avoir. Dim_client Hierarchy_1 Suivi des 3. Montant factures fraîches. recouvrements Hierarchy_1 4. Montant factures impayées. Dim_facture 5. Montant précontentieux. Hierarchy_2 Dim_zone Hierarchy_1 Tableau II.29 : Liste des cubes dimensionnels. 122
  • 131. IV. Présentation des cubes dimensionnels Dim_zone code_zone <N1> code_commune commune code_agence <N2> agence code_dd <N3> dd code_wilaya <N4> wilaya Dim_client Dim_enrgie code_filiale <N5> filiale code_client <N1> code_energie <N1> reference_lc type_energie Hierarchie_1 <Default> <h> type unite_mesure numero_client <N2> debit <N2> Hierarchie_1 <Default> <h> Hierarchie_1 <Default> <h1> Hierarchie_2 <h2> Cube_suivi_vente - Dim_zone Cube_suivi_vente - Dim_enrgie Cube_suivi_vente - Dim_client Cube_suivi_vente chiffre_affaire nombre_facture Fait_vente Cube_suivi_vente - Dim_facture Cube_suivi_vente - Dim_tarif Cube_suivi_vente - Dim_temps Dim_facturenumero_facture <N1> Dim_tarifnumero_facture_sgc code_tarif <N1> Dim_tempsdate_facture description_tarifsoutient_etat code_temps <N1> abreviation_tarifconso_moy_enrgie_jour date energie <N2>type_facture <N2> jour_du_mois jours Hierarchie_1 <Default> <h>type_releve <N3>type_cycle <N4> evenement semaine_dans_annee <N2>Hierarchie_1 <Default> <h1> mois_annee <N3>Hierarchie_2 <h2> mois annee_trimestre <N4> trimestre saison <N5> annee <N6> Hierarchie_1 <Default> <h> Figure II.32 : Cube dimensionnel « Suivi des ventes ». 123
  • 132. Dim_zone code_zone <N1> code_commune commune code_agence <N2> agence code_dd <N3> dd code_wilaya <N4> wilaya code_filiale <N5> Dim_client filiale code_client <N1> Dim_enrgie Hierarchie_1 <Default> <h> reference_lccode_energie <N1> typetype_energie numero_client <N2>unite_mesure Hierarchie_1 <Default> <h>debit <N2>Hierarchie_2 <Default> <h> Cube_suivi_vente_conso - Dim_zone Cube_suivi_vente_conso - Dim_enrgie Cube_suivi_vente_conso - Dim_client Cube_suivi_vente_conso chiffre_affaire nombre_facture nombre_conso_nul Fait_vente Cube_suivi_vente_conso - Dim_facture Cube_suivi_vente_conso - Dim_tarif Cube_suivi_vente_conso - Dim_temps Dim_facture Dim_tarif numero_facture <N1> code_tarif <N1> numero_facture_sgc description_tarif date_facture abreviation_tarif Dim_temps energie <N2> soutient_etat conso_moy_enrgie_jour code_temps <N1> Hierarchie_1 <Default> <h> type_facture <N2> date type_releve <N3> jour_du_mois type_cycle <N4> jours evenement Hierarchie_1 <Default> <h1> semaine_dans_annee <N2> Hierarchie_2 <h2> mois_annee <N3> mois annee_trimestre <N4> trimestre saison <N5> annee <N6> Hierarchie_1 <Default> <h> Figure II.33 : Cube dimensionnel « Suivi des ventes et des consommations ». 124
  • 133. Dim_zone Dim_temps code_temps <N1> code_zone <N1> date code_commune jour_du_mois commune code_agence <N2> Cube_suivi_des_abonnes - Dim_zone Cube_suivi_des_abonnes - Dim_temps jours agence evenement semaine_dans_annee <N2> code_dd <N3> mois_annee <N3> dd mois code_wilaya <N4> wilaya annee_trimestre <N4> code_filiale <N5> trimestre saison <N5> filiale annee <N6> Hierarchie_1 <Default> <h> Hierarchie_1 <Default> <h> Cube_suivi_des_abonnes Nombre_raccordements Nombre_resiliations Nombre_mise_service Fait_suivi_abonnes ... Dim_client Dim_type_abonne code_client <N1>code_type_abonnee <N1> reference_lctype_client_domiciliation <N2> type Cube_suivi_des_abonnes - Dim_client numero_client <N2>type_client_paiement <N3> Cube_suivi_des_abonnes - Dim_type_abonneHierarchie_1 <Default> <h> Hierarchie_1 <Default> <h> Figure II.34 : Cube dimensionnel « Suivi des abonnés ». Dim_zone Dim_tempscode_zone <N1> code_temps <N1>code_commune datecommune jour_du_moiscode_agence <N2> jours Cube_suivi_recouvrement - Dim_zone Cube_suivi_recouvrement - Dim_temps evenementagencecode_dd <N3> semaine_dans_annee <N2>dd mois_annee <N3>code_wilaya <N4> moiswilaya annee_trimestre <N4>code_filiale <N5> trimestrefiliale saison <N5> annee <N6>Hierarchie_1 <Default> <h> Hierarchie_1 <Default> <h> Cube_suivi_recouvrement Montant_creances Montant_avoir Montant_factures_fraiches Montant_facture_impayee Montant_precontentieux Fait_suivi_abonnes Dim_facture numero_facture <N1> numero_facture_sgc Dim_client date_facture code_client <N1> soutient_etat reference_lc conso_moy_enrgie_jour type type_facture <N2> type_releve <N3> Cube_suivi_recouvrement - Dim_facture Cube_suivi_recouvrement - Dim_client numero_client <N2> type_cycle <N4> Hierarchie_1 <Default> <h> Hierarchie_1 <Default> <h1> Hierarchie_2 <h2> Figure II.35 : Cube dimensionnel « Suivi des recouvrements ». 125
  • 134. Dim_zone code_zone <N1> code_commune commune code_agence <N2> agence code_dd <N3> dd Dim_temps code_wilaya <N4> wilaya code_temps <N1> code_filiale <N5> date filiale jour_du_mois Dim_type_affaire jours code_affaire <N1> Hierarchie_1 <Default> <h> evenement intitule_affaire semaine_dans_annee <N2> durree_approximative mois_annee <N3> code_ss_categorie <N2> mois intitule_ss_categorie annee_trimestre <N4> code_categorie <N3> trimestre intitule_categorie saison <N5> Hierarchie_1 <Default> <h> annee <N6> Hierarchie_1 <Default> <h> Cube_suivi_affaire - Dim_zoneCube_suivi_affaire - Dim_type_affaire Cube_suivi_affaire - Dim_temps Dim_client Cube_suivi_affaire code_client <N1> nombre_affaire Cube_suivi_affaire - Dim_client reference_lc durre_moyen type Fait_suivi_affaire numero_client <N2> Hierarchie_1 <Default> <h> Cube_suivi_affaire - Dim_energie Cube_suivi_affaire - Dim_affaire Cube_suivi_affaire - Dim_phase Dim_phase Dim_affaire code_phase <N1> numero_affaire <N1> intitule_phase degre_urgence Dim_energie durree_estimee_phase initier_par code_energie <N1> desc_phase observation type_energie Hierarchie_1 <Default> <h> Hierarchie_1 <Default> <h> unite_mesure debit <N2> Hierarchie_1 <Default> <h1> Hierarchie_2 <h2> Figure II.36 : Cube dimensionnel « Suivi des affaires ». 126
  • 135. V. Conclusion Les cubes dimensionnels est une étape très importante dans tout projet Data Warehouse.C’est grâce à cette dernière que l’utilisateur pourra utiliser et exploiter au mieux les donnéescontenues dans l’entrepôt de données de manière correcte et intuitive. Dans ce chapitre nous avons essayé donc de définir les cubes dimensionnels enexplicitant les dimensions participantes dans chacun d’entre eux. Ensuite nous avons défini,pour chacune des dimensions, les différentes hiérarchies présentes ainsi que les niveaux quicomposent ces dernières. 127
  • 136. Meta Data 128
  • 137. I. Les « Méta Data » ou « métas données » de l’entrepôt Un entrepôt de données, étant en production constante, doit être suivi de prés.Ladministration dun Data Warehouse revient à mettre en place des processus et desmécanismes de gestion. Ces mécanismes sont là pour assurer un meilleur fonctionnement del’entrepôt. Aussi ils doivent garantir l’alimentation en données quelques soient lescirconstances. Afin d’assurer la mise à jour de l’entrepôt de données, il est nécessaire de suivre sonalimentation au jour le jour, surtout dans le cas présent où les sources de données sontgéographiquement dispersées. Un tel suivi peut être garantie grâce au recours au méta data del’entrepôt.II. Rôle des métas données Les métas données ont un rôle très important dans le cycle de vie d’un entrepôt dedonnées. En effet, elles donnent une description ainsi qu’un sens aux données contenues dansl’entrepôt, afin que l’utilisateur comprenne et puisse utiliser au mieux ces données.Cependant, leur rôle peut dépasser le cadre de cette description en se présentant comme unmoyen de supervision et de suivi de l’évolution de l’entrepôt. Le diagramme illustré sur lafigure II.37 montre la conception des métas données. Ce diagramme représente, de manière claire, la structure de l’entrepôt de données,renseignant de ce fait sur sa contenance en données. En plus de cela, il offre la possibilité desuperviser les chargements en donnant une vue générale sur l’alimentation de l’entrepôt dedonnées. 129
  • 138. Figure II.37 : Diagramme de classe des métas données. 130
  • 139. III. Exploitation des métas données III.1 Présentation de la partie navigation La fonction première des métadonnées est d’offrir un catalogue complet et détaillé surle contenu de l’entrepôt. Ce catalogue est bien sûr appelé à évoluer. De ce fait l’utilisateurdoit être en mesure de consulter ce catalogue et d’y proposer des mises à jour, si cela estnécessaire. Le diagramme des cas d’utilisation suivant illustre ces différents volets : Figure II.38 : DCU navigation dans les 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 quel’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 del’alimentation et avoir la possibilité de recourir à des solutions secours. Ces solutions desupervision et de chargement secours sont : 131
  • 140. 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. 132
  • 141. IV. Conclusion La couche méta données est très importante dans un projet Data Warehouse, dans lamesure où elle en permet la maintenance de ce dernier, garantit son intégrité et facilite sonexpansion. Ainsi il est plus que nécessaire de concevoir les métas données et de développer unecouche applicative permettant de les maintenir. Dans ce chapitre nous avons essayé deconcevoir un sous système d’administration de l’entrepôt de données qui répond auxexigences d’un tel projet. 133
  • 142. Partie III : Réalisation et déploiement 134
  • 143. I. Introduction Pour la réalisation et la mise en place de la solution, il a été nécessaire de recourir à uncertain 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 outilsutilisé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 pourrontengendrer 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 à certainsproblèmes, tels que la non compatibilité des machines AIX 5.2 avec la version du JREnécessaire pour l’exécution des programmes d’extractions. 135
  • 144. II.2 Architecture technique de la solutionLa figure suivante illustre la structure et l’architecture technique de la solution proposée : Figure III : Architecture technique de la solution. III.1 II.3 Zone de stockage Lors de la conception, il a été question de concevoir et mettre en place deux bases de données : 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 la finalitéde chaque base de données, de son utilisation et des données qu’elle contiendra. des 1) Base de données « Data Warehouse » : La base de données, Data Warehouse, a été implémentée sous l SGBD open le source PostgresPlus. CCette distribution de PostgreSQL, en plus du noyau PostgreSQL connu pour ses performances par rapport aux bases de données volumineuses19, intègre un ensemble d’outil d’administration et de configuration. Aussi ce SGBD est d’outils pré configuré pour la mise en place d’un Data Warehouse.19 Voir annexe F. 136
  • 145. 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 estconstituée d’un ensemble d’outils qui doivent permettre aux utilisateurs d’exploiter lesystème mis en place dans les meilleures conditions possibles. . Ainsi plusieurs outils etserveurs 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. 137
  • 146. • 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 untravail d’intégration et de conception afin de donner une valeur ajoutée aux étatsimplémentés. En plus de la mise en place de ces outils, il était nécessaire de développer certainsvolets: • 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’extensionweb du langage Java. Le développement s’est fait avec la version 6.5 de l’IDE NetBeans. Lechoix 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. 138
  • 147. III. Déploiement Pour mieux décrire le déploiement de la solution, on utilise le modèle de déploiementU.M.L qui permet de présenter l’architecture de déploiement d’une manière simple etcompré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 dedéploiements : Un diagramme pour la zone d’alimentation et un autre diagramme pour lazone de restitution. La zone de stockage étant liée directement aux deux autres zones seradé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. 139
  • 148. III.2 Déploiement de la zone de restitution Figure III.3 : Diagramme de déploiement de la zone de restitution. 140
  • 149. IV. Conclusion La partie de restitution est la partie sur laquelle l’utilisateur final aura à interagir. Cettedernière a été mise en place en intégrant des solutions « Open Source », et en développantcertains 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’assurerl’alimentation de la zone de stockage en données. Cette dernière a été implémentée sous leSGBD PostgreSQL, dans sa distribution « PostgreSQLPLUS ». Le déploiement de la solution se fait suivant les diagrammes de déploiement illustrésdans 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. 141
  • 150. Conclusion générale et perspectives 142
  • 151. Conclusion générale et Perspectives Exploiter les données à disposition de l’entreprise afin de leur donner de la valeurajouté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 prisede décision, SONELGAZ a initié le projet de réalisation d’un Data Warehouse pour permettrela 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é desuivre une démarche mixte, alliant de ce fait entre Deux approches connues dans le domainedu Data Warehousing, à savoir l’approche « Besoins d’analyse » et l’approche « Sources dedonnées ». Cette démarche a permis de répondre aux attentes et besoins des utilisateurs touten 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 besoinsdans ce travail (en effet, le milieu et l’organisation du groupe ont rendu toute autre approchepratiquement impossible), l’étude des besoins déjà exprimés sous forme de rapports et deprocessus de prise de décision nous ont été d’une grande utilité pour définir de manière clairele périmètre et les besoins réels des utilisateurs. Cette étude a fait ressortir quatre sujetsd’analyse dignes d’intérêt pour l’entreprise qui sont : Les ventes, les affaires, les nouveauxabonnés, le recouvrement. Dans un deuxième temps, la modélisation de la zone de stockage des données s’estfaite grâce aux principes de la modélisation dimensionnelle. Cette modélisation offre unevision claire et une compréhension intuitive des modèles proposés. Nous avons de ce faitproposé des modèles en étoiles des quartes activités recensés. Partant de chaque modèledimensionnel, nous avons donné les modèles agrégés afin d’améliorer les performances dufutur système. La partie d’alimentation de la zone de stockage « implémentation physique desmodèles dimensionnels sur un SGBD relationnel » a été sans nul doute la partie du projet laplus fastidieuse et consommatrice en temps ; nous permettant de vérifier le postula disantqu’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, lesroutines d’extraction, transformation et chargement des données. L’utilisation d’outils et de solutions open source est un volet très important dans ceprojet. En effet, l’orientation Open Source du projet a été décidée dés l’initiation de cedernier. Cette orientation, qui se fait ressentir durant les étapes sus citées, est plus présentedans 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 navigationdans les données complètement open source, offrant à l’utilisateur la possibilité d’exploiter lesdonnées de l’entrepôt via n’importe quel client léger. La partie restitution a aussi nécessité le 143
  • 152. développement des volets de gestion des utilisateurs, d’administration de l’entrepôt et desupervision de ce dernier. Pour la mise en route de la solution, nous avons entamé le travail de déploiement enchoisissant 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 stageau niveau de SONELGAZ nous a permis d’acquérir une très bonne expérience professionnelleet d’évoluer dans un domaine qui nous était totalement inconnu à savoir le domaine dessystèmes décisionnels, et au sein d’un environnement regroupant des équipes deprofessionnels du métier représentant la filiale « ELIT ». Comme un projet Data Warehouse n’est jamais complètement terminé, nous pouvonsciter 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. 144
  • 153. BibliographieOuvrages[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. 145
  • 154. Articles et Thèses[Bouzghoub, 2008] : Abdenour Bouzghoub ; « Modélisation des Entrepôts de données XML : Application au domaine de la sécurité sociale » ; Thèse de Magistère Option : SISCSD ; Institut National de Formation en Informatique (I.N.I) 2008.[Chouder, 2007] : Lamri Chouder ; « Entrepôt Distribué de Données » ; Thèse de Magistère Option : SI; Institut National de Formation en Informatique (I.N.I) 2007.[Chuck, 1998] : Chuck Ballard, Dirk Herreman, Don Schau, Rhonda Bell, Eunsaeng Kim, Ann Valencic; Data Modeling Techniques for Data 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.[Haciane, 2006] : Ahmed Haciane ; « Conception d’un datawarehouse Orienté CRM »; Thèse de magistère Option : SI ; Institut National de Formation en Informatique (I.N.I); 2006.[Hugh, 2009] : Hugh Watson, Dorothea L. Abraham, Daniel Chen, David Preston; Dominic Thomas,Data Warehousing ROI: Justifying and Assessing a Data Warehouse; http://www.bi-bestpractices.com/view- articles/4780; 2009.[Inmon, 2000]: B. Inmon; What is a Data Warehouse; Article; http://www.billinmon.com; 2000.[Inmon, 1998]: B. Inmon ;Data Mart Does Not Equal Data Warehouse; http://www.information- management.com/infodirect/19991120/1675- 1.html ;1998.[Soler, 2001] : Y.Soler; PLANIFICATION ET SUIVI DUN PROJET ; Centre national de la recherche scientifique Direction des systèmes dinformation ; http://www.dsi.cnrs.fr/conduite- 146
  • 155. projet/phasedefinition/gestion-de-projet/planification-suivi-projet/guide-planif-suivi-projet.pdf ;2001. 147