SlideShare une entreprise Scribd logo
1  sur  155
Télécharger pour lire hors ligne
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ème
Conception 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
Remerciements


        Nos remerciements vont tout spécialement à nos familles, qui ont sus nous supporter et
encourager tout au long de notre vie, ainsi que pour leur aide inestimable, leur patience et
leur 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 monsieur
Medjaoui 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 nous
avoir donné l’opportunité de travailler sur un projet d’une tel envergure.

       Nous remercions Mme Ait Ali Yahia pour ces critiques constructives qui nous ont
permis d’améliorer ce mémoire.

        Nous nous devons de mentionner la précieuse et totale collaboration que nous avons
reç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 accepter
d’évaluer ce travail.

       Pour finir, et afin de n’oublier personne (amis, membre de la famille et tous ceux qui
nous sont chers) nous utiliserons la formule : « Merci à… ».




                                                                  ^xw}ÇtÇx 9 Y|ÄtÄ|
Dédicaces


Je 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
Dédicaces


A:
           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
Sommaire
Résumé :………………………………………………………………………………………..I
Abréviations :………………………………………………………………………………….II
Liste des tableaux …………………………………………………………………………….IV
Liste des figures ……………………………………………………………………………...VI
Introduction 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 ................................................................................... 18
II. 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 .......................................................................... 25
III. 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 ......................................................................................... 32
IV. 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
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 ........................................................................................ 42
V. Conclusion ....................................................................................................................... 43

                                     PartieII: Conception de la solution.
Chapitre 1: Présentation de l'organisme d'accueil.
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 » ........................................................................ 53
II. Conclusion ....................................................................................................................... 56

Chapitre 2: L'éxistant décisionnel.
I. Introduction ...................................................................................................................... 58
II. 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 ............................................................................. 61
III. Conclusion ....................................................................................................................... 62

Chapitre 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 d'informations utiles ...................... 65
      3.     Planification, préparation et conduite des interviews ................................................ 66
      4.     Autres moyens utilisés pour la détection des besoins ............................................... 67
5.     Rédaction et validation du recueil récapitulatif des besoins ..................................... 68
   I.2 Problèmes et obstacles rencontrés ................................................................................ 69
II. Conclusion ....................................................................................................................... 70

Chapitre 4: Conception de la zone « entreposage des données ».
I. Introduction ...................................................................................................................... 73
II. 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 » ..................................................................................... 99
III. Conclusion ..................................................................................................................... 103

Chapitre 5: Conception de la zone « Alimentation ».
I. Introduction .................................................................................................................... 105
II. 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 .............................................................. 106
III. Architecture du processus d’alimentation ...................................................................... 107
IV. 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 .............................................................. 114
V. Conclusion ..................................................................................................................... 115

Chapitre 6: Conception des cubes dimensionnels.
I. Définition des niveaux et des hiérarchies ...................................................................... 117
II. La liste des cubes ........................................................................................................... 121
III. Présentation des cubes dimensionnels ........................................................................... 123
IV. Conclusion ..................................................................................................................... 123


Chapitre 7: Conception des Meta Data.
I. Les « Meta Data » ou « méta données » de l’entrepôt ................................................... 129
II. Rôle des méta données ................................................................................................... 129
III. Exploitation des métas données ..................................................................................... 133
      III.1 Présentation de la partie navigation ....................................................................... 133
III.2 Présentation de la partie supervision ...................................................................... 133
IV. Conclusion ..................................................................................................................... 133

                               Partie III: Implémentation et déploiement.
I.     Introduction .................................................................................................................... 135
II. 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 .................................................................................................. 137
III. Déploiement ................................................................................................................... 139
     III.1   Déploiement de la zone d’alimentation .................................................................. 139
     III.2   Déploiement de la zone de restitution .................................................................... 140
IV.         Conclusion …………………………………………..……………………………….141

Conclusion générale et perspectives ………………...……………………………………142
Bibliographie ........................................................................................................................ 145
Résumé :
Le groupe SONELGAZ, premier opérateur énergétique en Algérie, assure plusieurs missions
dans 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 professionnels
que des particuliers, font de SONELGAZ un acteur incontournable de l’économie nationale.
Le groupe SONELGAZ rencontre, dans le cadre de son activité de distribution, quelques
problèmes dans sa politique de Reporting clientèle. Ces difficultés sont liées notamment à la
lenteur et au coût de la procédure, du fait du nombre important d’intermédiaires et/ou
intervenants. Ces difficultés ont rendu tout effort d’analyse vain ; et c’est pourquoi les
dirigeants du groupe aspirent à la mise en place d’un système qui procure aux décideurs les
informations nécessaires et fiables, les aidant ainsi à pendre dans les meilleurs délais les
décisions les plus appropriées. Dans ce contexte, et afin de répondre à ces attentes
grandissantes le groupe a sollicité sa filiale spécialisée dans les systèmes d’information et les
nouvelles technologies « Elit ».
 Le But recherché étant d’aller vers la mise en place d’un système s’inscrivant dans le cadre
du Système de Gestion de la Clientèle « S.G.C ». Ce système sera construit autour d’une
base 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 donc
pour 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
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
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écision
SGBD : 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
Liste des tableaux

                                     Partie I : Synthèse Bibliographique.
Tableau I.1 : Tableau comparatif entre les systèmes transactionnels et les systèmes
décisionnels... ............................................................................................................................. 6
Tableau I.2 : Tableau comparatif entre les tables de faits et les tables de dimensions............ 16
Tableau I.3 : Avantages et inconvénients de l’approche « Besoins d’analyse » ..................... 23
Tableau 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 ................................................................ 38
Tableau II.2 :          Présentation des sociétés de distribution ........................................................ 40
Tableau II.3 :          Tableau présentant la population a interviewé ............................................... 54
Tableau II.4 :          Synthétisation des besoins détectés ................................................................ 56
Tableau II.5 :          Tableau descriptif de la dimension « Temps » .............................................. 63
Tableau II.6 :          Tableau descriptif de la dimension « Client » ............................................... 65
Tableau II.7 :          Tableau descriptif de la dimension « Facture » .............................................. 67
Tableau II.8 :          Tableau descriptif de la dimension « Zone géographique » ........................... 69
Tableau II.9 :          Tableau descriptif de la dimension « Activité » ............................................. 70
Tableau II.10 : Tableau descriptif de la dimension « Tarif » .................................................. 70
Tableau II.11 : Tableau descriptif de la dimension « Energie » ............................................. 71
Tableau II.12 : Liste des agrégats potentiels de l’activité « Vente » ...................................... 75
Tableau II.13 : Liste des agrégats utiles de l’activité « Vente » ............................................ 75
Tableau II.14 : Détection des dimensions communes entre les volets « Vente » et
« Recouvrement »..................................................................................................................... 76
Tableau II.15 : Tableau descriptif de la dimension « Nature » ............................................... 77
Tableau II.16 : Tableau descriptif des agrégats potentiel du modèle « Recouvrement » ....... 79
Tableau II.17 : Tableau descriptif des agrégats utiles du modèle « Recouvrement » ............. 79
Tableau II.18 : Détection des dimensions communes entre les volets « Vente »,
« Recouvrement » et « Suivi des affaires »…………………..…………….…………………80
Tableau II.19 : Tableau descriptif de la dimension « Affaire» ............................................... 81
Tableau II.20 : Tableau descriptif de la dimension « Type affaire » ....................................... 8
Tableau II.21 : Tableau descriptif de la dimension « Phase »................................................. 83
Tableau II.22 : Tableau descriptif des agrégats potentiel du modèle « suivi des affaires » .... 85
Tableau II.23 : Tableau descriptif de des agrégats utiles du modèle « Suivi des affaires ».... 85
Tableau II.24 : Détection des dimensions communes entre les volets « Vente »,
« Recouvrement », « Suivi des affaires » et « suivi des abonnés ». ......................................... 86
Tableau II.25 : Tableau descriptif de la dimension « Type abonné » ..................................... 87


                                                                                                                                            IV
Tableau II.26 : Tableau descriptif des agrégats potentiels du modèle « Suivi abonnés » ....... 89
Tableau II.27 : Tableau descriptif des agrégats utiles du modèle « Suivi abonnés ».............. 89
Tableau II.28 : Tableau donnant les nivaux hiérarchiques de chaque dimension ................... 10
Tableau II.29 : Listes des cubes dimensionnels .................................................................... 107




                                                                                                                     V
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
Figure II.10 : La place de l’étape de définition des besoins dans un projet Data
Warehouse………………………………………………………………………………….52
Figure II.11 :        Analyse des priorités du cas de la distribution « SONELGAZ »................ 60
Figure II.12 :        La dimension du Temps de l’activité « Vente » ......................................... 64
Figure II.13 :        La dimension client de l’activité « Vente » ................................................ 65
Figure II.14 :        La dimension facture de l’activité « Vente » .............................................. 68
Figure II.15 :        La dimension zone de l’activité « Vente ».................................................. 70
Figure II.16 :        La dimension activité de l’activité « Vente » ............................................. 70
Figure II.17 :        La dimension Tarif de l’activité « Vente » ................................................. 70
Figure II.18 :        La dimension énergie de l’activité « Vente » ............................................. 71
Figure II.19 :        Modèle en étoile de l’activité « Vente » ..................................................... 74
Figure II.20 :        La dimension Nature de l’activité « Recouvrement »................................. 78
Figure II.21 :        Modèle en étoile de l’activité « Recouvrement » ....................................... 79
Figure II.22 :        La dimension affaire de l’activité «Suivi des affaires ».............................. 83
Figure II.23 :        La dimension type affaire de l’activité « Suivi des affaires »..................... 82
Figure II.24 :        La dimension phase de l’activité « suivie des affaires » ............................. 83
Figure II.25 :        Modèle en étoile de l’activité « Suivie des affaires » ................................. 84
Figure II.26 :        La dimension type abonné de l’activité « Suivi des abonné » .................... 87
Figure II.27 :        Modèle en étoile de l’activité « Suivi des abonné » ................................... 88
Figure II.28 :        Architecture global du processus E.T.L ...................................................... 95
Figure II.29 :        Diagramme d’activité du processus d’alimentation .................................... 94
Figure II.30 :        Diagramme d’activité du processus de chargement de dimension ............. 98
Figure II.31 :        Diagramme d’activité du processus de chargement de fait......................... 99
Figure II.32 :        Cube dimensionnel « Suivi des ventes ». .................................................. 109
Figure II.33 :        Cube dimensionnel « Suivi des ventes et des consommations ». ............. 110
Figure II.34 :        Cube dimensionnel « Suivi des abonnés ». ............................................... 111
Figure II.35 :        Cube dimensionnel « Suivi des recouvrements ». .................................... 111
Figure II.36 :        Cube dimensionnel « Suivi des affaires ». ................................................ 112
Figure II.37 :        Diagramme de classe des métadonnées .................................................... 115
Figure II.38 : DCU navigation dans les métadonnées et administration des MAJ
utilisateurs………… ........................................................................................................... 116
Figure II.39 :        DCU de supervision. ................................................................................. 117
Figure II.40 :        Architecture technique de la solution. ...................................................... 121
Figure II.41 :        Digramme de déploiement de la zone d’alimentation. ............................. 125
Figure II.42 :        Diagramme de déploiement de la zone de restitution. .............................. 126




                                                                                                                             VII
Introduction générale




                        8
Contexte général
        C’est dans un environnement fortement complexe et hautement concurrentiel
qu’évolue la majeure partie, si ce n’est la totalité, des entreprises. Ce climat de forte
concurrence exige de ces entreprises une surveillance très étroite du marché afin de ne pas se
laisser distancer par les concurrents et cela en répondant, le plus rapidement possible, aux
attentes du marché, de leur clientèle et de leurs partenaires.

        Pour se faire, les dirigeants de l’entreprise, quelque en soit d’ailleurs le domaine
d’activité, doivent être en mesure de mener à bien les missions qui leur incombent en la
matière. Ils devront prendre notamment les décisions les plus opportunes. Ces décisions, qui
influeront 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 la
survie de l’entreprise. Il s’agit de prendre des décisions fondées, basées sur des informations
claires, fiables et pertinentes. Le problème est de savoir donc comment identifier et présenter
ces informations à qui de droit, sachant par ailleurs que les entreprises croulent d’une part
sous 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 et
constituer 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 offrent
aux décideurs des informations de qualité sur lesquelles ils pourront s’appuyer pour arrêter
leurs choix décisionnels. Pour se faire, ces systèmes utilisent un large éventail de technologies
et de méthodes, dont les « entrepôts de données » (Data Warehouse) représentent l’élément
principal 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. Ces
données représentent une source précieuse d’informations, qui serait à même d’améliorer de
façon significative le processus de prise de décision. Cependant, ces données ne sont pas
exploité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 les
données issues des systèmes transactionnels, et d’offrir des informations de qualité pour les
décideurs. Il s’agit en fait de mettre à la disposition des décideurs des données à même de
les éclairer et leur faciliter une prise de décision prompte en connaissance de cause. Un tel
système requiert la mise en place d’un entrepôt de données fiables contenant les informations
nécessaires à l’accomplissement des processus décisionnels.




                                                                                               9
1. Problématique
       Le groupe SONELGAZ est l’opérateur historique et leader du domaine énergétique en
Algérie, notamment dans le domaine de la distribution de l’électricité et du gaz pour les
professionnels et les particuliers.

        Appelé à interagir avec ses clients sur différentes phases de la distribution (demande
de branchement, facturation, résiliation,…etc.), le groupe s’est doté, dans un souci de suivi de
la 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 2900
utilisateurs. 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âche
ardue. En effet, les sociétés de distributions « SD » se trouvent dans l’incapacité de faire des
analyses fiables, efficaces et à des moments opportuns sans engager des moyens considérables
sur 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 quelques

1
    Voir annexe A

                                                                                                10
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 filiale
Elit, le présent projet.

       Ce projet a pour but d’introduire, en premier lieu, une informatique décisionnelle au
sein du groupe, tout en conférant aux décideurs un support fiable pour une meilleure prise de
dé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
Planification et conduite du projet

       L’initiation de tout projet nécessite une phase de planification. Celle
                         out                                                    Celle-ci permet
de définir les tâches à réaliser, maîtriser les risques et rendre compte de l’état d’avancement
du projet.

      « Planifier optimise ainsi les chances de réussite d'un projet en améliorant la
productivité 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 cette
planification 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 se
présente comme suit :

        Après une introduction générale dans laquelle nous présentons le contexte général du
projet, ainsi que la problématique et les objectifs visés. La première partie présente les aspects
théoriques du domaine des systèmes d’information d’aide à la décision, en évoquant leurs
définitions et les concepts de bases relatifs aux « entrepôts de données » et à la modélisation
dimensionnelle.



                                                                                                       12
Dans la deuxième partie, nous présentons le travail réalisé au sein du Groupe
SONELGAZ à travers les six suivants chapitres:

        Le chapitre un, présente l’organisme d’accueil, sa structure organisationnelle, son
activité 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 de
l’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, ainsi
que 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, ainsi
que les stratégies adoptées.

        Le chapitre six, quant à lui, donne la conception des cubes dimensionnels en détaillant
les 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 les
différents outils intégrés et les volets de la solution développés. Elle décrit aussi la manière
dont 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 citer
les perspectives du projet.




                                                                                                13
Partie I : Synthèse
 bibliographique

« Un entrepôt de données ne s'achète pas, il se construit. »
Bill Inmon




                                                          14
I.    Introduction
    Toutes les entreprises du monde disposent d’une masse de données plus ou moins
considérable. Ces informations proviennent soit de sources internes (générées par leurs
systè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 les
exploiter à des fins d’analyse conduit, inévitablement, l’entreprise à se tourner vers une
nouvelle informatique dite décisionnelle qui met l’accent sur la compréhension de
l’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 leur
environnement 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 pertinents
permettant la sauvegarde, l’utilisation de la mémoire de l’entreprise et offrant à ses décideurs
la 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 ces
conditions, une structure informatique et une fondation des plus incontournables pour la mise
en place d’applications décisionnelles.

   Le concept de Data Warehouse, tel que connu aujourd’hui, est apparu pour la première
fois en 1980 ; l’idée consistait alors à réaliser une base de données destinée exclusivement au
processus décisionnel. Les nouveaux besoins de l’entreprise, les quantités importantes de
données produites par les systèmes opérationnels et l’apparition des technologies aptes à sa
mise en œuvre ont contribué à l’apparition du concept « Data Warehouse » comme support
aux 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 en
place d’une informatique décisionnelle au sein de l’entreprise. Pour cela il serait assez
inté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 les
placer 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ôle
et de distribution des informations nécessaires à l’exercice de l’activité en tout point de
l’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 de
dé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, du
point de vue fonctionnel ou des tâches à effectuer, conduit à l’apparition des « systèmes
d’information décisionnels » (S.I.D.). Ces différences seront clairement illustrées un peu plus
loin dans notre document.

                                                                                             15
Les origines des SID remontent au début de l’informatique et des systèmes d’information
qui 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 l'intermédiaire d'interrogations 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 sein
d’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, ont
d’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
I.1.2. Les différentes composantes du décisionnel
                            s

         En relation étroite avec les nouvelles technologies de l’information et des
télécommunications, le système décisionnel se manifeste à différents niveaux selon leurs
                                  e
utilité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
I.3. Décisionnel vs transactionnel
    Le tableau suivant résume de façon non exhaustive les différences qu’il peut y avoir
entre les systèmes transactionnels et les systèmes décisionnels selon les données et l’usage fait
des 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 aux
besoins décisionnels. Ce système n’est rien d’autre que le « Data Warehouse ».




                                                                                                  18
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érence
dans 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, non
volatiles 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 sont
conç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 des
données contenues dans le Data Warehouse. Le contenu en données et en relations entre elles
diffè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 Data
Warehouse 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 les
différentes valeurs d’une donnée, cela permet les comparaisons et le suivi de l’évolution des
valeurs dans le temps, alors que dans un système opérationnel la valeur d’une donnée est
simplement 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 of
time » [Inmon, 2000].

Non volatiles : c’est ce qui est, en quelque sorte la conséquence de l’historisation décrite
précédemment. Une donnée dans un environnement opérationnel peut être mise à jour ou
supprimé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 Data
Warehouse sont organisées de manière à permettre l’exécution des processus d’aide à la
décision (Reporting, Data Mining…).




                                                                                                 19
II.2       Historique des Data Warehouse
    L’origine du concept « Data Warehouse » D.W (entrepôt de données en français) remonte
aux 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 et
la 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ème
opérationnel prise de façon périodique, dédiée à un environnement de support à la prise de
décision. Ainsi, les données étaient extraites du système opérationnel, stockées dans une
nouvelle base de données «concept d’infocentre », le motif principal étant de répondre aux
requê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. Il
est devenu une nouvelle source d’information, alimenté avec des données recueillies et
consolidé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
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ées




M                                        Données agrégées
E
T
A
D
O
N
N                                        Données détaillées
É
E
S



                                   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
Meta données : ce sont les informations relatives à la structure des données, les méthodes
d’agrégation et le lien entre les données opérationnelles et celles du Data Warehouse. Les
mé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 quatre
composantes : les applications opérationnelles, la zone de préparation des données, la
pré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 de
l’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 applications
opérationnelles et la présentation des données. Elle est constituée d’un ensemble de processus
appelé ETL, « Extract, transform and Load », les données sont extraites et stockées pour subir
les transformations nécessaires avant leur chargement.

        « Un point très important, dans l’aménagement d’un entrepôt de données, est
d’interdire aux utilisateurs l’accès à la zone de préparation des données, qui ne fournit aucun
service 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 les
données de la zone de préparation sont interdites aux utilisateurs, la zone de présentation est
tout 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éfini
comme étant une miniaturisation d’un Data Warehouse, construit autour d’un sujet précis
d’analyse ou consacré à un niveau départemental3.

        Cette différence de construction, autour d’un sujet ou au niveau départemental, définit
la façon d’implémentation du Data Mart au niveau de l’entrepôt. On distingue, en effet, deux
architectures internes du Data Warehouse :



3
    Synthétisation [Chuck, 1998] page 86.

                                                                                              22
1. Data Mart indépendant

       Les Data Mart sont des versions miniaturisées du Data Warehouse au niveau
départemental, alimentées par le Data Warehouse et basées sur les besoins départementaux en
                        s                               s
informations [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
2. Data Mart interconnectés

        Les Data Mart sont construi autour de sujets, interconnectés grâce aux tables des
         es                   construits
faits contenues dans le Data Warehouse, ce dernier se compose alors des Data Mart et ces
tables 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 Data
Warehouse 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 de
donné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
II.5       Architecture d’un Data Warehouse
    Après avoir exposé et défini chacun des éléments constituant l’environnement d’un Data
Warehouse, il serait intéressant de connaitre le positionnement de ces éléments dans une
architecture globale d’un Data Warehouse :




                     Figure I.7 : Architecture globale d’un Data Warehouse5.




5
    http://www.formations-sas.fr/data-warehouse

                                                                                       25
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. Ces
systèmes, devant répondre à des objectifs différents des systèmes transactionnels, ont fait
ressortir très vite la nécessité de recourir à un modèle de données simplifié et aisément
compréhensible. La modélisation dimensionnelle permet cela. Elle consiste à considérer un
sujet d’analyse comme un cube à plusieurs dimensions, offrant des vues en tranches ou des
analyses 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 est
réputée pour ses performances élevées.

         La nomination « schéma des jointures en étoile » a longtemps été adoptée pour décrire
un modèle dimensionnel. Cette nomination est due au fait que le diagramme qui représente un
modèle dimensionnel ressemble à une étoile, avec une grande table centrale et un jeu de
petites tables auxiliaires disposées en étoile autour de la table centrale. Celle-ci est appelée
table de faits et les autres tables sont appelées tables de dimensions. La figure suivante
illustre untel modèle :




                                                                                             26
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 de
performances sont stockées. Une ligne d’une table de faits correspond à une mesure. Ces
mesures sont généralement des valeurs numériques, additives ; cependant des mesures
textuelles peuvent exister mais sont rares. Le concepteur doit faire son possible pour faire des
mesures textuelles des dimensions, car elles peuvent êtres corrélées efficacement avec les
autres attributs textuels de dimensions.

      Une table de faits assure les liens plusieurs à plusieurs entre les dimensions. Elles
comportent des clés étrangères, qui ne sont autres que les clés primaires des tables de
dimension.

   III.1.2 Concept de dimension

       Les tables de dimension sont les tables qui raccompagnent une table de faits, elles
contiennent les descriptions textuelles de l’activité. Une table de dimension est constituée de
nombreuses colonnes qui décrivent une ligne. C’est grâce à cette table que l’entrepôt de
donné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 et
des attributs.

       « Une table de dimension établit l’interface homme / entrepôt, elle comporte une clé
primaire » [Kimball, 2002].



                                                                                             27
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 dimensions
Structure         Peu de colonnes beaucoup de lignes     Peu de lignes beaucoup de colonnes
Données           Mesurable, généralement numérique      Descriptives généralement textuelles
Référentiel       Plusieurs clés étrangères              Une clé primaire
Valeur            Prend de nombreuses valeurs            Plus ou moins constantes
Manipulation      Participe à des calculs                Participe à des contraintes
Signification     Valeurs de mesure                      Descriptive
Rô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 de
dimension. 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ées
en hiérarchies. Cette modélisation est généralement justifiée par l’économie d’espace de
stockage, cependant elle peut s’avérer moins compréhensible pour l’utilisateur final, et très
couteuse en terme de performances.

        Modèle en constellation : Ce n’est rien d’autre que plusieurs modèles en étoile liés
entre eux par des dimensions communes.




                                                                                             28
III.3         Le concept OLAP
    III.3.1 Généralités

       Le terme OLAP (On-Line Analytical Processing) désigne une classe de technologies
conçue pour l’accès aux données et pour une analyse instantanée de ces dernières, dans le but
de répondre aux besoins de Reporting et d’analyse.

        R. Kimball définit le concept « OLAP » comme «Activité globale de requêtage et de
présentation de données textuelles et numériques contenues dans l’entrepôt de données; Style
d’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 les
bases de données relationnelles, que le concept OLAP fut introduit et défini6 en 1993 par E.F
Codd, le père des bases de données relationnelles, dans un document technique portant le titre
de « 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 politique
régissant l’architecture du serveur. Ainsi, ces architectures peuvent être distinguées comme
suit:

    III.3.2.1     Les systèmes à architecture MOLAP
       Ces systèmes MOLAP « Multidimentional On-line Analytical Processing » sont
conç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 dimensionnel
est prépondérant » [Kimball, 2005].
        Ainsi donc cette base adopte réellement la structure multidimensionnelle, exploitant de
ce fait ces capacités au maximum. En effet MOLAP offre des temps d’accès optimisés et cela
en 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 coup
le système lorsque la quantité de données à traiter augmente. On parle généralement de
volume 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ées
aux 12 précédentes et le terme « règles » remplacé par dispositif «features » par le même auteur à savoir
Codd (Voir annexe B).

                                                                                                                    29
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 vision
dimensionnelle à des bases de données relationnelles » [Kimball, 2005].
        Les systèmes ROLAP « Relationnel On-line Analytical Processing » sont en mesure
de simuler le comportement d’une SGBD multidimensionnel en exploitant un SGBD
relationnel. L’utilisateur aura ainsi l’impression d’interroger un cube multidimensionnel alors
qu’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ées
dans une table relationnelle ce qui cause une lourdeur d’administration mais confère une
certaine 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’acquisition
d’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             d'exécution SQL                 Multi-Dimensionnel
       agrégées) et                  afin d'obtenir des
    des méta-données               fonctionnalités OLAP.
               Figure I.11 :    Principe de l’architecture ROLAP [Nakache, 1998].

                                                                                            30
III.2.2.3 Les systèmes à architecture HOLAP
        Les systèmes HOLAP « Hybride On-line Analytical Processing » sont une sorte de
compromis entre les différents systèmes précités. Cette combinaison donne à ce type de
système les avantages du ROLAP et du MOLAP en utilisant tour à tour l’un ou l’autre selon
le 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 plus
adoptées par les fournisseurs de solutions OLAP, d’autres systèmes se basent sur des
architectures différentes telles que l’architecture OOLAP « Object On-line Analytical
Processing », ou alors DOLAP « Desktop On-line Analytical Processing » qui décrit une
catégorie de produits qui ne sont pas nécessairement connectés à un serveur et qui s’appuient
sur une source de données (un cube) construites, stockées et exploitées en local sur la machine
de l’utilisateur.

   III.4      La navigation dans les données
        Une fois que le serveur OLAP a construit le cube multidimensionnel « ou simulé ce
cube selon l’architecture du serveur », plusieurs opérations sont possibles sur ce dernier
offrant ainsi la possibilité de naviguer dans les données qui le constituent. Ces opérations de
navigation « Data Surfing » doivent être, d’une part, assez complexes pour adresser
l’ensemble des données et, d’autre part, assez simples afin de permettre à l’utilisateur de
circuler de manière libre et intuitive dans le modèle dimensionnel.
       Afin de répondre à ces attentes, un ensemble de mécanismes est exploité, permettant
une 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 faire
des 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 ». La
différence entre eux se manifestent dans le fait que :
       Le Slicing consiste à faire une sélection de tranches du cube selon des prédicats et
selon une dimension « filtrer une dimension selon une valeur » [Chouder, 2008].




                                                                                             31
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 les
plus 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érations
permettent de contrôler le niveau de détail des données du cube.




                                                                                           32
Ces opérations ne sont pas aussi faciles à implémenter car basées sur la notion d’une
bonne hiérarchisation des attributs d’une dimension et la différenciation entre tous les niveaux
de 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
IV.          Démarche de Construction d’un Data Warehouse
       Plusieurs chercheurs ou équipes de recherche ont essayé de proposer des démarches
pour la réalisation d’un projet Data Warehouse, ces démarches se croisent essentiellement
dans 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 Warehouse
Les 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. Toutes
deux 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, la
définition de celui-là reste la même. En étant un support d’aide à la décision, le Data
Warehouse 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 est
illustré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
Avantages                                     Inconvénients
Aucun risque de concevoir une solution Pas de prise en compte de l’évolution des
obsolè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. Cette
approche 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
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, il
considère que les besoins sont en constante évolution.


                    Avantages                                        Inconvénients
Meilleure prise en charge de l’évolution des Risque de concevoir une solution obsolète
besoins                                      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 structures
des données du système opérationnel, et les valider par rapport aux besoins analytiques. Cette
approche 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 des
besoins 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
Cette étape aboutit à l’établissement du modèle dimensionnel validé du Data
Warehouse. Ce modèle dimensionnel sera transformé en modèle physique, qui différera du
modè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. Cette
alimentation (le plus souvent appelée processus ETL « Extract-Transform-Load ») se déroule
en 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 garantir
l’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 Data
Warehouse. 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 de
données. Extraire, cela veut dire lire et interpréter les données sources et les copier dans la
zone 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 les
changements intervenus sur ces données. Pour cela, il existe trois stratégies de capture de
changement :

     • Colonnes d’audit : la colonne d’audit, est une colonne qui enregistre la date
d’insertion ou du dernier changement d’un enregistrement. Cette colonne est mise à jour soit
par des triggers ou par les applications opérationnelles, d’où la nécessité de vérifier leur
fiabilité.

    • Capture des logs : certains outils ETL utilisent les fichiers logs des systèmes sources
afin de détecter les changements (généralement logs du SGBD). En plus de l’absence de cette
fonctionnalité sur certains outils ETL du marché, l’effacement des fichiers logs engendre la
perte de toute information relative aux transactions.

                                                                                            37
• Comparaison avec le dernier chargement : le processus d’extraction sauvegarde des
copies des chargements antérieurs, de manière à procéder à une comparaison lors de chaque
nouvelle 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ès
importante, assure en réalité plusieurs tâches qui garantissent la fiabilité des données et leurs
qualité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’entreprise
et 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 des
structures du système de gestion de la base de données (tables et index) afin d’optimiser au
mieux 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 la
politique de chargement dépend des sources : disponibilité et accessibilité. Ces politiques
sont8 :

      •    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
           l'occasion. L'inconvé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. L'inconvénient de cette méthode est qu'elle peut
           surcharger le système s'il est en cours d'utilisation.

      •    Push-pull : c'est la combinaison des deux méthodes. La source prépare les données à
           envoyer et indique à la zone de préparation qu'elle 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
Aussi, le processus d’alimentation doit répondre à certaines exigences illustrées par la
figure 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 processus
d’alimentation doit palier à ce problème et assurer le chargement du Data Warehouse dans des
délais acceptables.

   • Correctif : le processus d’alimentation doit apporter les correctifs nécessaires pour
amé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
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 phases
cité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’exploitation
du Data Warehouse se fait par le biais d’un ensemble d’outils analytiques développés autour
du Data Warehouse. Donc cette étape nécessite l’achèvement du développement, ou de la
mise 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 utilisateurs
de l’entrepôt de données, et spécialement les analystes, seront amenés à interagir avec le DW
via 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 de
choisir les outils qui lui paraissent les plus adéquats.

           b. Reporting :

       Destiné essentiellement à la production de rapports et de tableaux de bord, « il est la
présentation périodique de rapports sur les activités et résultats d'une organisation, d'une
unité de travail ou du responsable d'une fonction, destinée à en informer ceux chargés de les
superviser en interne ou en externe, ou tout simplement concernés par ces activités ou
résultants »9.

       Ces outils de Reporting ne sont pas, à proprement parler, des instruments d'aide à la
décision, mais, lorsqu’ils sont utilisés de manière appropriée, ils peuvent fournir une précieuse
vue d’ensemble.

       Les rapports sont alors crées par le biais d’outils de Reporting qui permettent de leur
donner un format prédéterminé. Les requêtes sont constituées lors de l’élaboration des
rapports qui seront ensuite diffusés périodiquement en automatique ou ponctuellement à la
demande.




9
    http://fr.wikipedia.org/wiki/Reporting

                                                                                                 40
c. Analyse dimensionnelle des données:

        L’analyse dimensionnelle est sans doute celle qui exploite et fait ressortir au mieux les
capacités de l’entrepôt de données. Le but par l’analyse dimensionnelle est d’offrir aux
utilisateurs la possibilité d’analyser les données selon différents critères afin de confirmer une
tendance ou suivre les performances de l’entreprise.
         Cette analyse se fait selon le principe OLAP, offrant de ce fait aux utilisateurs les
possibilités de recourir à différentes opérations facilitant la navigation dans les données. La
mise en place de ces outils est une option très intéressante dans la mesure où les données
seront accessibles en analyses instantanées. Plusieurs fournisseurs de solution OLAP existent
sur 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 les
besoins 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’évolution
d’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 pour
permettre aux gestionnaires de prendre connaissance de l’état et de l’évolution des systèmes
qu’ils pilotent et d’identifier les tendances qui les influenceront sur un horizon cohérent avec
la nature de leurs fonctions » [Bouquin, 2003].

       Cette forme de restitution a la particularité de se limiter à l’essentiel, c'est-à-dire la
mise en évidence de l’état d’un indicateur par rapport à un objectif, tout en adoptant une
repré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 ce
forage est d’extraire de la matière brute qui, dans notre cas, représente de nouvelles
connaissances. L’idée de départ veut qu’il existe dans toute entreprise des connaissances
utiles, cachées sous des gisements de données. Le Data Mining permet donc, grâce à un
certain nombre de techniques, de découvrir ces connaissances en faisant apparaître des
corrélations entre ces données.

        Le Data Warehouse constituera alors la première source de données sur laquelle
s’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 entreprises
modernes. Les applications et outils implémentant ces solutions sont rarement développés en
interne. En effet, les entreprises préfèrent se reposer sur des valeurs sûres du marché afin
d’exploiter au plus vite les données en leur possession.



                                                                                               41
IV.4        Maintenance et expansion
      La mise en service du Data Warehouse ne signifie pas la fin du projet, car un projet
Data Warehouse nécessite un suivi constant compte tenu des besoins d’optimisation de
performance 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 de
l’entrepôt de données. En outre, la relation directe avec les utilisateurs permet de détecter les
correctifs nécessaires à apporter.

        Formation : il est indispensable d’offrir un programme de formation permanant aux
utilisateurs de l’entrepôt de données.

        Support technique : un entrepôt de données est considéré comme un environnement
de production. Naturellement le support technique doit surveiller avec la plus grande vigilance
les 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épond
aux besoins de l’entreprise. Les revues systématiques à certain point de contrôle sont un outil
clé pour détecter et définir les possibilités d’amélioration. En plus du suivi et de la
maintenance du Data Warehouse, des demandes d’expansion sont envisageables pour de
nouveaux 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 du
Data Warehouse.




                                                                                              42
V.     Conclusion
       Le concept « Data Warehouse » est apparu comme une réponse à des besoins
grandissants dans le domaine décisionnel. Son adaptabilité et sa capacité de fournir les
données nécessaires à une bonne analyse, ont fait de lui un atout majeur et incontournable
pour 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’adopter
une démarche précise qui doit tenir compte des réalités de l’entreprise et des contraintes du
projet. La modélisation de l’entrepôt se fait dans tous les cas grâce à la modélisation
dimensionnelle. L’alimentation en données constitue l’étape à laquelle il faut accorder le plus
d’attention et de temps. En effet, elle est le garant de contenance de l’entrepôt en données
fiables et correctes. Une fois l’alimentation terminée, l’exploitation des données peut alors se
faire par différentes méthodes. L’utilisation d’outil OLAP reste, cependant, l’aspect le plus
intéressant dans cette exploitation permettant la navigation dans les données de l’entrepôt à la
demande.

      Au cours de la seconde partie de cette étude, nous allons essayer d’utiliser les
concepts présentés dans la synthèse bibliographique, et cela afin de mettre en œuvre notre
système.




                                                                                             43
Partie II : Cas pratique « filiales de
 distribution SONELGAZ »




                                         44
Chapitre I :   Présentation   de   l’organisme
               d’accueil.




                                             45
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse

Contenu connexe

Tendances

CONCEPTION ET REALISATION D ’ UNE APPLICATION WEB POUR GESTION DE P ROJETS DE...
CONCEPTION ET REALISATION D ’ UNE APPLICATION WEB POUR GESTION DE P ROJETS DE...CONCEPTION ET REALISATION D ’ UNE APPLICATION WEB POUR GESTION DE P ROJETS DE...
CONCEPTION ET REALISATION D ’ UNE APPLICATION WEB POUR GESTION DE P ROJETS DE...Madjid Meddah
 
RapportPFE_IngenieurInformatique_ESPRIT
RapportPFE_IngenieurInformatique_ESPRITRapportPFE_IngenieurInformatique_ESPRIT
RapportPFE_IngenieurInformatique_ESPRITLina Meddeb
 
Rapport du Projet de Fin d'année Génie informatique
Rapport du Projet de Fin d'année Génie informatique Rapport du Projet de Fin d'année Génie informatique
Rapport du Projet de Fin d'année Génie informatique ayoub daoudi
 
Conception et Réalisation Application Web Laravel PFE BTS
Conception et Réalisation Application Web Laravel PFE BTSConception et Réalisation Application Web Laravel PFE BTS
Conception et Réalisation Application Web Laravel PFE BTSFaissoilMkavavo
 
Pfe conception et réalisation d'une application de gestion des processus d'ac...
Pfe conception et réalisation d'une application de gestion des processus d'ac...Pfe conception et réalisation d'une application de gestion des processus d'ac...
Pfe conception et réalisation d'une application de gestion des processus d'ac...Ahmed Makni
 
Chp3 - Modélisation Multidimensionnelle
Chp3 - Modélisation MultidimensionnelleChp3 - Modélisation Multidimensionnelle
Chp3 - Modélisation MultidimensionnelleLilia Sfaxi
 
Rapport de projet de fin d'étude licence informatique et multimédia
Rapport de projet de fin d'étude licence informatique et multimédiaRapport de projet de fin d'étude licence informatique et multimédia
Rapport de projet de fin d'étude licence informatique et multimédiaNazih Heni
 
Rapport Projet de Fin d'Etudes
Rapport Projet de Fin d'EtudesRapport Projet de Fin d'Etudes
Rapport Projet de Fin d'EtudesHosni Mansour
 
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...Yasmine Lachheb
 
Les systèmes d'information décisionnel pour les assurances
Les systèmes d'information décisionnel pour les assurancesLes systèmes d'information décisionnel pour les assurances
Les systèmes d'information décisionnel pour les assurancesdihiaselma
 
Concéption et réalisation d'un processus décisionnel, tableau de bord social.
Concéption et réalisation d'un processus décisionnel, tableau de bord social.Concéption et réalisation d'un processus décisionnel, tableau de bord social.
Concéption et réalisation d'un processus décisionnel, tableau de bord social.Rim ENNOUR
 
Rapport Pfe Application Web e-commerce Symfony2
Rapport Pfe Application Web e-commerce Symfony2Rapport Pfe Application Web e-commerce Symfony2
Rapport Pfe Application Web e-commerce Symfony2Ben Abdelwahed Slim
 
BigData_Chp4: NOSQL
BigData_Chp4: NOSQLBigData_Chp4: NOSQL
BigData_Chp4: NOSQLLilia Sfaxi
 
rapport de projet de fin d'étude_PFE
rapport de projet de fin d'étude_PFErapport de projet de fin d'étude_PFE
rapport de projet de fin d'étude_PFEDonia Hammami
 
Cours Big Data Chap1
Cours Big Data Chap1Cours Big Data Chap1
Cours Big Data Chap1Amal Abid
 
Rapport PFE ingénieur réseaux marwen SAADAOUI ( Juin 2018 )
Rapport PFE ingénieur réseaux marwen SAADAOUI ( Juin 2018 )Rapport PFE ingénieur réseaux marwen SAADAOUI ( Juin 2018 )
Rapport PFE ingénieur réseaux marwen SAADAOUI ( Juin 2018 )Saadaoui Marwen
 
Conception d’une plateforme web d’e-Commerce au sein d’une entreprise commerc...
Conception d’une plateforme web d’e-Commerce au sein d’une entreprise commerc...Conception d’une plateforme web d’e-Commerce au sein d’une entreprise commerc...
Conception d’une plateforme web d’e-Commerce au sein d’une entreprise commerc...Symphorien Niyonzima
 

Tendances (20)

CONCEPTION ET REALISATION D ’ UNE APPLICATION WEB POUR GESTION DE P ROJETS DE...
CONCEPTION ET REALISATION D ’ UNE APPLICATION WEB POUR GESTION DE P ROJETS DE...CONCEPTION ET REALISATION D ’ UNE APPLICATION WEB POUR GESTION DE P ROJETS DE...
CONCEPTION ET REALISATION D ’ UNE APPLICATION WEB POUR GESTION DE P ROJETS DE...
 
RapportPFE_IngenieurInformatique_ESPRIT
RapportPFE_IngenieurInformatique_ESPRITRapportPFE_IngenieurInformatique_ESPRIT
RapportPFE_IngenieurInformatique_ESPRIT
 
Rapport du Projet de Fin d'année Génie informatique
Rapport du Projet de Fin d'année Génie informatique Rapport du Projet de Fin d'année Génie informatique
Rapport du Projet de Fin d'année Génie informatique
 
Rapport pfe
Rapport pfeRapport pfe
Rapport pfe
 
Conception et Réalisation Application Web Laravel PFE BTS
Conception et Réalisation Application Web Laravel PFE BTSConception et Réalisation Application Web Laravel PFE BTS
Conception et Réalisation Application Web Laravel PFE BTS
 
Pfe conception et réalisation d'une application de gestion des processus d'ac...
Pfe conception et réalisation d'une application de gestion des processus d'ac...Pfe conception et réalisation d'une application de gestion des processus d'ac...
Pfe conception et réalisation d'une application de gestion des processus d'ac...
 
Rapport PFE
Rapport PFERapport PFE
Rapport PFE
 
Chp3 - Modélisation Multidimensionnelle
Chp3 - Modélisation MultidimensionnelleChp3 - Modélisation Multidimensionnelle
Chp3 - Modélisation Multidimensionnelle
 
Rapport de projet de fin d'étude licence informatique et multimédia
Rapport de projet de fin d'étude licence informatique et multimédiaRapport de projet de fin d'étude licence informatique et multimédia
Rapport de projet de fin d'étude licence informatique et multimédia
 
Rapport Projet de Fin d'Etudes
Rapport Projet de Fin d'EtudesRapport Projet de Fin d'Etudes
Rapport Projet de Fin d'Etudes
 
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...
 
Les systèmes d'information décisionnel pour les assurances
Les systèmes d'information décisionnel pour les assurancesLes systèmes d'information décisionnel pour les assurances
Les systèmes d'information décisionnel pour les assurances
 
Concéption et réalisation d'un processus décisionnel, tableau de bord social.
Concéption et réalisation d'un processus décisionnel, tableau de bord social.Concéption et réalisation d'un processus décisionnel, tableau de bord social.
Concéption et réalisation d'un processus décisionnel, tableau de bord social.
 
Rapport Pfe Application Web e-commerce Symfony2
Rapport Pfe Application Web e-commerce Symfony2Rapport Pfe Application Web e-commerce Symfony2
Rapport Pfe Application Web e-commerce Symfony2
 
BigData_Chp4: NOSQL
BigData_Chp4: NOSQLBigData_Chp4: NOSQL
BigData_Chp4: NOSQL
 
rapport de projet de fin d'étude_PFE
rapport de projet de fin d'étude_PFErapport de projet de fin d'étude_PFE
rapport de projet de fin d'étude_PFE
 
Rapport Projet de fin d’études
Rapport Projet de fin d’étudesRapport Projet de fin d’études
Rapport Projet de fin d’études
 
Cours Big Data Chap1
Cours Big Data Chap1Cours Big Data Chap1
Cours Big Data Chap1
 
Rapport PFE ingénieur réseaux marwen SAADAOUI ( Juin 2018 )
Rapport PFE ingénieur réseaux marwen SAADAOUI ( Juin 2018 )Rapport PFE ingénieur réseaux marwen SAADAOUI ( Juin 2018 )
Rapport PFE ingénieur réseaux marwen SAADAOUI ( Juin 2018 )
 
Conception d’une plateforme web d’e-Commerce au sein d’une entreprise commerc...
Conception d’une plateforme web d’e-Commerce au sein d’une entreprise commerc...Conception d’une plateforme web d’e-Commerce au sein d’une entreprise commerc...
Conception d’une plateforme web d’e-Commerce au sein d’une entreprise commerc...
 

En vedette

Conception datawarehouse
Conception datawarehouseConception datawarehouse
Conception datawarehouseHassane Dkhissi
 
MS Experiences 17 - Comment le contrôle de gestion améliore le pilotage de l’...
MS Experiences 17 - Comment le contrôle de gestion améliore le pilotage de l’...MS Experiences 17 - Comment le contrôle de gestion améliore le pilotage de l’...
MS Experiences 17 - Comment le contrôle de gestion améliore le pilotage de l’...Jean-Pierre Riehl
 
Business Intelligence : Transformer les données en information.
Business Intelligence : Transformer les données en information.Business Intelligence : Transformer les données en information.
Business Intelligence : Transformer les données en information.arnaudm
 
Projet de fin d'études licence Pro TCF Université Ibn Zohr Agadir {Gestion de...
Projet de fin d'études licence Pro TCF Université Ibn Zohr Agadir {Gestion de...Projet de fin d'études licence Pro TCF Université Ibn Zohr Agadir {Gestion de...
Projet de fin d'études licence Pro TCF Université Ibn Zohr Agadir {Gestion de...HAFID Ait Bihi
 
Intégration des données avec Talend ETL
Intégration des données avec Talend ETLIntégration des données avec Talend ETL
Intégration des données avec Talend ETLLilia Sfaxi
 
Integration de donnees_etl
Integration de donnees_etlIntegration de donnees_etl
Integration de donnees_etlhoracio lassey
 

En vedette (9)

Conception datawarehouse
Conception datawarehouseConception datawarehouse
Conception datawarehouse
 
MS Experiences 17 - Comment le contrôle de gestion améliore le pilotage de l’...
MS Experiences 17 - Comment le contrôle de gestion améliore le pilotage de l’...MS Experiences 17 - Comment le contrôle de gestion améliore le pilotage de l’...
MS Experiences 17 - Comment le contrôle de gestion améliore le pilotage de l’...
 
Qu'est-ce qu'un ETL ?
Qu'est-ce qu'un ETL ?Qu'est-ce qu'un ETL ?
Qu'est-ce qu'un ETL ?
 
Rapport De PFE
Rapport De PFERapport De PFE
Rapport De PFE
 
Business Intelligence : Transformer les données en information.
Business Intelligence : Transformer les données en information.Business Intelligence : Transformer les données en information.
Business Intelligence : Transformer les données en information.
 
Projet de fin d'études licence Pro TCF Université Ibn Zohr Agadir {Gestion de...
Projet de fin d'études licence Pro TCF Université Ibn Zohr Agadir {Gestion de...Projet de fin d'études licence Pro TCF Université Ibn Zohr Agadir {Gestion de...
Projet de fin d'études licence Pro TCF Université Ibn Zohr Agadir {Gestion de...
 
Intégration des données avec Talend ETL
Intégration des données avec Talend ETLIntégration des données avec Talend ETL
Intégration des données avec Talend ETL
 
Integration de donnees_etl
Integration de donnees_etlIntegration de donnees_etl
Integration de donnees_etl
 
Le processus ETL (Extraction, Transformation, Chargement)
Le processus ETL (Extraction, Transformation, Chargement)Le processus ETL (Extraction, Transformation, Chargement)
Le processus ETL (Extraction, Transformation, Chargement)
 

Similaire à Conception et Réalisation d'un Data Warehouse

RAPPORT DE PROJET DE FIN D’ETUDES
RAPPORT DE PROJET DE FIN D’ETUDESRAPPORT DE PROJET DE FIN D’ETUDES
RAPPORT DE PROJET DE FIN D’ETUDESTombariAhmed
 
YouTaQA : Système de Questions-Réponses Intelligent basé sur le Deep Learning...
YouTaQA : Système de Questions-Réponses Intelligent basé sur le Deep Learning...YouTaQA : Système de Questions-Réponses Intelligent basé sur le Deep Learning...
YouTaQA : Système de Questions-Réponses Intelligent basé sur le Deep Learning...YounesAGABI
 
Application mobile bancaire sous la plateforme Android
Application mobile bancaire sous la plateforme AndroidApplication mobile bancaire sous la plateforme Android
Application mobile bancaire sous la plateforme AndroidKhaled Fayala
 
Rapport_PFE_Securite (1).pdf
Rapport_PFE_Securite (1).pdfRapport_PFE_Securite (1).pdf
Rapport_PFE_Securite (1).pdfAhmedDhib6
 
Torkhanikarima-MémoireMastereProRx&telecom-FST2015-, Supervision et Monitorin...
Torkhanikarima-MémoireMastereProRx&telecom-FST2015-, Supervision et Monitorin...Torkhanikarima-MémoireMastereProRx&telecom-FST2015-, Supervision et Monitorin...
Torkhanikarima-MémoireMastereProRx&telecom-FST2015-, Supervision et Monitorin...Karima Torkhani
 
Torkhani karima-MémoireMastereProRx&telecom-FST2015-, Supervision et Monitori...
Torkhani karima-MémoireMastereProRx&telecom-FST2015-, Supervision et Monitori...Torkhani karima-MémoireMastereProRx&telecom-FST2015-, Supervision et Monitori...
Torkhani karima-MémoireMastereProRx&telecom-FST2015-, Supervision et Monitori...karimatorkhani
 
orkhanikarima-MémoireMastereProRx&telecom-FST2015-, Supervision et Monitoring...
orkhanikarima-MémoireMastereProRx&telecom-FST2015-, Supervision et Monitoring...orkhanikarima-MémoireMastereProRx&telecom-FST2015-, Supervision et Monitoring...
orkhanikarima-MémoireMastereProRx&telecom-FST2015-, Supervision et Monitoring...Karima Torkhani
 
Pfe master fst_final_decembre2015
Pfe master fst_final_decembre2015Pfe master fst_final_decembre2015
Pfe master fst_final_decembre2015Ghali Rahma
 
Rapport_PFE_analyse_de_données_BI_2021.pdf
Rapport_PFE_analyse_de_données_BI_2021.pdfRapport_PFE_analyse_de_données_BI_2021.pdf
Rapport_PFE_analyse_de_données_BI_2021.pdfRihabBenSalem5
 
Rapport pfe 2017 Système de gestion des rendez-vous médicaux
Rapport pfe 2017 Système de gestion des rendez-vous médicaux Rapport pfe 2017 Système de gestion des rendez-vous médicaux
Rapport pfe 2017 Système de gestion des rendez-vous médicaux fehmi arbi
 
AUTOMATISATION D’UNE MACHINE EXTRUDEUSE ET MISE EN PLACE D’UNE INTERFACE HOMM...
AUTOMATISATION D’UNE MACHINE EXTRUDEUSE ET MISE EN PLACE D’UNE INTERFACE HOMM...AUTOMATISATION D’UNE MACHINE EXTRUDEUSE ET MISE EN PLACE D’UNE INTERFACE HOMM...
AUTOMATISATION D’UNE MACHINE EXTRUDEUSE ET MISE EN PLACE D’UNE INTERFACE HOMM...RidhaChayeh1
 
Conception et réalisation d'une application mobile cross-platform "Taki Academy"
Conception et réalisation d'une application mobile cross-platform "Taki Academy"Conception et réalisation d'une application mobile cross-platform "Taki Academy"
Conception et réalisation d'une application mobile cross-platform "Taki Academy"Ibtihel El Bache
 
392327755-Conception-Et-Realisation-d-Un-Site-Web-Et-Une-Application-Mobile-d...
392327755-Conception-Et-Realisation-d-Un-Site-Web-Et-Une-Application-Mobile-d...392327755-Conception-Et-Realisation-d-Un-Site-Web-Et-Une-Application-Mobile-d...
392327755-Conception-Et-Realisation-d-Un-Site-Web-Et-Une-Application-Mobile-d...ElAzzabAbdeSsamad
 
Rapport PFE réalisation d’un Framework Kinect
Rapport PFE réalisation d’un Framework KinectRapport PFE réalisation d’un Framework Kinect
Rapport PFE réalisation d’un Framework KinectAmine MEGDICHE
 
rapport-170608045227 (1).pdf
rapport-170608045227 (1).pdfrapport-170608045227 (1).pdf
rapport-170608045227 (1).pdfMahmoudiOussama
 
rapport-170608045227 (1).pdf
rapport-170608045227 (1).pdfrapport-170608045227 (1).pdf
rapport-170608045227 (1).pdfMahmoudiOussama
 
Rapport PFE Développent d'une application bancaire mobile
Rapport PFE Développent d'une application bancaire mobileRapport PFE Développent d'une application bancaire mobile
Rapport PFE Développent d'une application bancaire mobileNader Somrani
 
Les aidants de personnes âgées dépendantes. Quelle place dans les services de...
Les aidants de personnes âgées dépendantes. Quelle place dans les services de...Les aidants de personnes âgées dépendantes. Quelle place dans les services de...
Les aidants de personnes âgées dépendantes. Quelle place dans les services de...Kévin BISIAUX
 
Rapport stage pfe
Rapport stage  pfe Rapport stage  pfe
Rapport stage pfe rimeh moussi
 

Similaire à Conception et Réalisation d'un Data Warehouse (20)

RAPPORT DE PROJET DE FIN D’ETUDES
RAPPORT DE PROJET DE FIN D’ETUDESRAPPORT DE PROJET DE FIN D’ETUDES
RAPPORT DE PROJET DE FIN D’ETUDES
 
YouTaQA : Système de Questions-Réponses Intelligent basé sur le Deep Learning...
YouTaQA : Système de Questions-Réponses Intelligent basé sur le Deep Learning...YouTaQA : Système de Questions-Réponses Intelligent basé sur le Deep Learning...
YouTaQA : Système de Questions-Réponses Intelligent basé sur le Deep Learning...
 
Application mobile bancaire sous la plateforme Android
Application mobile bancaire sous la plateforme AndroidApplication mobile bancaire sous la plateforme Android
Application mobile bancaire sous la plateforme Android
 
Rapport_PFE_Securite (1).pdf
Rapport_PFE_Securite (1).pdfRapport_PFE_Securite (1).pdf
Rapport_PFE_Securite (1).pdf
 
Torkhanikarima-MémoireMastereProRx&telecom-FST2015-, Supervision et Monitorin...
Torkhanikarima-MémoireMastereProRx&telecom-FST2015-, Supervision et Monitorin...Torkhanikarima-MémoireMastereProRx&telecom-FST2015-, Supervision et Monitorin...
Torkhanikarima-MémoireMastereProRx&telecom-FST2015-, Supervision et Monitorin...
 
Torkhani karima-MémoireMastereProRx&telecom-FST2015-, Supervision et Monitori...
Torkhani karima-MémoireMastereProRx&telecom-FST2015-, Supervision et Monitori...Torkhani karima-MémoireMastereProRx&telecom-FST2015-, Supervision et Monitori...
Torkhani karima-MémoireMastereProRx&telecom-FST2015-, Supervision et Monitori...
 
orkhanikarima-MémoireMastereProRx&telecom-FST2015-, Supervision et Monitoring...
orkhanikarima-MémoireMastereProRx&telecom-FST2015-, Supervision et Monitoring...orkhanikarima-MémoireMastereProRx&telecom-FST2015-, Supervision et Monitoring...
orkhanikarima-MémoireMastereProRx&telecom-FST2015-, Supervision et Monitoring...
 
Pfe master fst_final_decembre2015
Pfe master fst_final_decembre2015Pfe master fst_final_decembre2015
Pfe master fst_final_decembre2015
 
Rapport_PFE_analyse_de_données_BI_2021.pdf
Rapport_PFE_analyse_de_données_BI_2021.pdfRapport_PFE_analyse_de_données_BI_2021.pdf
Rapport_PFE_analyse_de_données_BI_2021.pdf
 
Rapport pfe 2017 Système de gestion des rendez-vous médicaux
Rapport pfe 2017 Système de gestion des rendez-vous médicaux Rapport pfe 2017 Système de gestion des rendez-vous médicaux
Rapport pfe 2017 Système de gestion des rendez-vous médicaux
 
AUTOMATISATION D’UNE MACHINE EXTRUDEUSE ET MISE EN PLACE D’UNE INTERFACE HOMM...
AUTOMATISATION D’UNE MACHINE EXTRUDEUSE ET MISE EN PLACE D’UNE INTERFACE HOMM...AUTOMATISATION D’UNE MACHINE EXTRUDEUSE ET MISE EN PLACE D’UNE INTERFACE HOMM...
AUTOMATISATION D’UNE MACHINE EXTRUDEUSE ET MISE EN PLACE D’UNE INTERFACE HOMM...
 
Conception et réalisation d'une application mobile cross-platform "Taki Academy"
Conception et réalisation d'une application mobile cross-platform "Taki Academy"Conception et réalisation d'une application mobile cross-platform "Taki Academy"
Conception et réalisation d'une application mobile cross-platform "Taki Academy"
 
Pfe
PfePfe
Pfe
 
392327755-Conception-Et-Realisation-d-Un-Site-Web-Et-Une-Application-Mobile-d...
392327755-Conception-Et-Realisation-d-Un-Site-Web-Et-Une-Application-Mobile-d...392327755-Conception-Et-Realisation-d-Un-Site-Web-Et-Une-Application-Mobile-d...
392327755-Conception-Et-Realisation-d-Un-Site-Web-Et-Une-Application-Mobile-d...
 
Rapport PFE réalisation d’un Framework Kinect
Rapport PFE réalisation d’un Framework KinectRapport PFE réalisation d’un Framework Kinect
Rapport PFE réalisation d’un Framework Kinect
 
rapport-170608045227 (1).pdf
rapport-170608045227 (1).pdfrapport-170608045227 (1).pdf
rapport-170608045227 (1).pdf
 
rapport-170608045227 (1).pdf
rapport-170608045227 (1).pdfrapport-170608045227 (1).pdf
rapport-170608045227 (1).pdf
 
Rapport PFE Développent d'une application bancaire mobile
Rapport PFE Développent d'une application bancaire mobileRapport PFE Développent d'une application bancaire mobile
Rapport PFE Développent d'une application bancaire mobile
 
Les aidants de personnes âgées dépendantes. Quelle place dans les services de...
Les aidants de personnes âgées dépendantes. Quelle place dans les services de...Les aidants de personnes âgées dépendantes. Quelle place dans les services de...
Les aidants de personnes âgées dépendantes. Quelle place dans les services de...
 
Rapport stage pfe
Rapport stage  pfe Rapport stage  pfe
Rapport stage pfe
 

Conception et Réalisation d'un Data Warehouse

  • 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ème Conception 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 et encourager tout au long de notre vie, ainsi que pour leur aide inestimable, leur patience et leur 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 monsieur Medjaoui 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 nous avoir donné l’opportunité de travailler sur un projet d’une tel envergure. Nous remercions Mme Ait Ali Yahia pour ces critiques constructives qui nous ont permis d’améliorer ce mémoire. Nous nous devons de mentionner la précieuse et totale collaboration que nous avons reç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 accepter d’évaluer ce travail. Pour finir, et afin de n’oublier personne (amis, membre de la famille et tous ceux qui nous sont chers) nous utiliserons la formule : « Merci à… ». ^xw}ÇtÇx 9 Y|ÄtÄ|
  • 3. Dédicaces Je 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édicaces A: 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. Sommaire Résumé :………………………………………………………………………………………..I Abréviations :………………………………………………………………………………….II Liste des tableaux …………………………………………………………………………….IV Liste des figures ……………………………………………………………………………...VI Introduction 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 ................................................................................... 18 II. 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 .......................................................................... 25 III. 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 ......................................................................................... 32 IV. 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 ........................................................................................ 42 V. Conclusion ....................................................................................................................... 43 PartieII: Conception de la solution. Chapitre 1: Présentation de l'organisme d'accueil. 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 » ........................................................................ 53 II. Conclusion ....................................................................................................................... 56 Chapitre 2: L'éxistant décisionnel. I. Introduction ...................................................................................................................... 58 II. 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 ............................................................................. 61 III. Conclusion ....................................................................................................................... 62 Chapitre 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 d'informations 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 ................................................................................ 69 II. Conclusion ....................................................................................................................... 70 Chapitre 4: Conception de la zone « entreposage des données ». I. Introduction ...................................................................................................................... 73 II. 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 » ..................................................................................... 99 III. Conclusion ..................................................................................................................... 103 Chapitre 5: Conception de la zone « Alimentation ». I. Introduction .................................................................................................................... 105 II. 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 .............................................................. 106 III. Architecture du processus d’alimentation ...................................................................... 107 IV. 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 .............................................................. 114 V. Conclusion ..................................................................................................................... 115 Chapitre 6: Conception des cubes dimensionnels. I. Définition des niveaux et des hiérarchies ...................................................................... 117 II. La liste des cubes ........................................................................................................... 121 III. Présentation des cubes dimensionnels ........................................................................... 123 IV. Conclusion ..................................................................................................................... 123 Chapitre 7: Conception des Meta Data. I. Les « Meta Data » ou « méta données » de l’entrepôt ................................................... 129 II. Rôle des méta données ................................................................................................... 129 III. 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 ...................................................................... 133 IV. Conclusion ..................................................................................................................... 133 Partie III: Implémentation et déploiement. I. Introduction .................................................................................................................... 135 II. 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 .................................................................................................. 137 III. Déploiement ................................................................................................................... 139 III.1 Déploiement de la zone d’alimentation .................................................................. 139 III.2 Déploiement de la zone de restitution .................................................................... 140 IV. Conclusion …………………………………………..……………………………….141 Conclusion générale et perspectives ………………...……………………………………142 Bibliographie ........................................................................................................................ 145
  • 9. Résumé : Le groupe SONELGAZ, premier opérateur énergétique en Algérie, assure plusieurs missions dans 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 professionnels que des particuliers, font de SONELGAZ un acteur incontournable de l’économie nationale. Le groupe SONELGAZ rencontre, dans le cadre de son activité de distribution, quelques problèmes dans sa politique de Reporting clientèle. Ces difficultés sont liées notamment à la lenteur et au coût de la procédure, du fait du nombre important d’intermédiaires et/ou intervenants. Ces difficultés ont rendu tout effort d’analyse vain ; et c’est pourquoi les dirigeants du groupe aspirent à la mise en place d’un système qui procure aux décideurs les informations nécessaires et fiables, les aidant ainsi à pendre dans les meilleurs délais les décisions les plus appropriées. Dans ce contexte, et afin de répondre à ces attentes grandissantes le groupe a sollicité sa filiale spécialisée dans les systèmes d’information et les nouvelles technologies « Elit ». Le But recherché étant d’aller vers la mise en place d’un système s’inscrivant dans le cadre du Système de Gestion de la Clientèle « S.G.C ». Ce système sera construit autour d’une base 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 donc pour 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écision SGBD : 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èmes décisionnels... ............................................................................................................................. 6 Tableau I.2 : Tableau comparatif entre les tables de faits et les tables de dimensions............ 16 Tableau I.3 : Avantages et inconvénients de l’approche « Besoins d’analyse » ..................... 23 Tableau 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 ................................................................ 38 Tableau II.2 : Présentation des sociétés de distribution ........................................................ 40 Tableau II.3 : Tableau présentant la population a interviewé ............................................... 54 Tableau II.4 : Synthétisation des besoins détectés ................................................................ 56 Tableau II.5 : Tableau descriptif de la dimension « Temps » .............................................. 63 Tableau II.6 : Tableau descriptif de la dimension « Client » ............................................... 65 Tableau II.7 : Tableau descriptif de la dimension « Facture » .............................................. 67 Tableau II.8 : Tableau descriptif de la dimension « Zone géographique » ........................... 69 Tableau II.9 : Tableau descriptif de la dimension « Activité » ............................................. 70 Tableau II.10 : Tableau descriptif de la dimension « Tarif » .................................................. 70 Tableau II.11 : Tableau descriptif de la dimension « Energie » ............................................. 71 Tableau II.12 : Liste des agrégats potentiels de l’activité « Vente » ...................................... 75 Tableau II.13 : Liste des agrégats utiles de l’activité « Vente » ............................................ 75 Tableau II.14 : Détection des dimensions communes entre les volets « Vente » et « Recouvrement »..................................................................................................................... 76 Tableau II.15 : Tableau descriptif de la dimension « Nature » ............................................... 77 Tableau II.16 : Tableau descriptif des agrégats potentiel du modèle « Recouvrement » ....... 79 Tableau II.17 : Tableau descriptif des agrégats utiles du modèle « Recouvrement » ............. 79 Tableau II.18 : Détection des dimensions communes entre les volets « Vente », « Recouvrement » et « Suivi des affaires »…………………..…………….…………………80 Tableau II.19 : Tableau descriptif de la dimension « Affaire» ............................................... 81 Tableau II.20 : Tableau descriptif de la dimension « Type affaire » ....................................... 8 Tableau II.21 : Tableau descriptif de la dimension « Phase »................................................. 83 Tableau II.22 : Tableau descriptif des agrégats potentiel du modèle « suivi des affaires » .... 85 Tableau II.23 : Tableau descriptif de des agrégats utiles du modèle « Suivi des affaires ».... 85 Tableau II.24 : Détection des dimensions communes entre les volets « Vente », « Recouvrement », « Suivi des affaires » et « suivi des abonnés ». ......................................... 86 Tableau 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 » ....... 89 Tableau II.27 : Tableau descriptif des agrégats utiles du modèle « Suivi abonnés ».............. 89 Tableau II.28 : Tableau donnant les nivaux hiérarchiques de chaque dimension ................... 10 Tableau 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 Data Warehouse………………………………………………………………………………….52 Figure II.11 : Analyse des priorités du cas de la distribution « SONELGAZ »................ 60 Figure II.12 : La dimension du Temps de l’activité « Vente » ......................................... 64 Figure II.13 : La dimension client de l’activité « Vente » ................................................ 65 Figure II.14 : La dimension facture de l’activité « Vente » .............................................. 68 Figure II.15 : La dimension zone de l’activité « Vente ».................................................. 70 Figure II.16 : La dimension activité de l’activité « Vente » ............................................. 70 Figure II.17 : La dimension Tarif de l’activité « Vente » ................................................. 70 Figure II.18 : La dimension énergie de l’activité « Vente » ............................................. 71 Figure II.19 : Modèle en étoile de l’activité « Vente » ..................................................... 74 Figure II.20 : La dimension Nature de l’activité « Recouvrement »................................. 78 Figure II.21 : Modèle en étoile de l’activité « Recouvrement » ....................................... 79 Figure II.22 : La dimension affaire de l’activité «Suivi des affaires ».............................. 83 Figure II.23 : La dimension type affaire de l’activité « Suivi des affaires »..................... 82 Figure II.24 : La dimension phase de l’activité « suivie des affaires » ............................. 83 Figure II.25 : Modèle en étoile de l’activité « Suivie des affaires » ................................. 84 Figure II.26 : La dimension type abonné de l’activité « Suivi des abonné » .................... 87 Figure II.27 : Modèle en étoile de l’activité « Suivi des abonné » ................................... 88 Figure II.28 : Architecture global du processus E.T.L ...................................................... 95 Figure II.29 : Diagramme d’activité du processus d’alimentation .................................... 94 Figure II.30 : Diagramme d’activité du processus de chargement de dimension ............. 98 Figure II.31 : Diagramme d’activité du processus de chargement de fait......................... 99 Figure II.32 : Cube dimensionnel « Suivi des ventes ». .................................................. 109 Figure II.33 : Cube dimensionnel « Suivi des ventes et des consommations ». ............. 110 Figure II.34 : Cube dimensionnel « Suivi des abonnés ». ............................................... 111 Figure II.35 : Cube dimensionnel « Suivi des recouvrements ». .................................... 111 Figure II.36 : Cube dimensionnel « Suivi des affaires ». ................................................ 112 Figure II.37 : Diagramme de classe des métadonnées .................................................... 115 Figure II.38 : DCU navigation dans les métadonnées et administration des MAJ utilisateurs………… ........................................................................................................... 116 Figure II.39 : DCU de supervision. ................................................................................. 117 Figure II.40 : Architecture technique de la solution. ...................................................... 121 Figure II.41 : Digramme de déploiement de la zone d’alimentation. ............................. 125 Figure II.42 : Diagramme de déploiement de la zone de restitution. .............................. 126 VII
  • 17. Contexte général C’est dans un environnement fortement complexe et hautement concurrentiel qu’évolue la majeure partie, si ce n’est la totalité, des entreprises. Ce climat de forte concurrence exige de ces entreprises une surveillance très étroite du marché afin de ne pas se laisser distancer par les concurrents et cela en répondant, le plus rapidement possible, aux attentes du marché, de leur clientèle et de leurs partenaires. Pour se faire, les dirigeants de l’entreprise, quelque en soit d’ailleurs le domaine d’activité, doivent être en mesure de mener à bien les missions qui leur incombent en la matière. Ils devront prendre notamment les décisions les plus opportunes. Ces décisions, qui influeront 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 la survie de l’entreprise. Il s’agit de prendre des décisions fondées, basées sur des informations claires, fiables et pertinentes. Le problème est de savoir donc comment identifier et présenter ces informations à qui de droit, sachant par ailleurs que les entreprises croulent d’une part sous 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 et constituer 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 offrent aux décideurs des informations de qualité sur lesquelles ils pourront s’appuyer pour arrêter leurs choix décisionnels. Pour se faire, ces systèmes utilisent un large éventail de technologies et de méthodes, dont les « entrepôts de données » (Data Warehouse) représentent l’élément principal 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. Ces données représentent une source précieuse d’informations, qui serait à même d’améliorer de façon significative le processus de prise de décision. Cependant, ces données ne sont pas exploité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 les données issues des systèmes transactionnels, et d’offrir des informations de qualité pour les décideurs. Il s’agit en fait de mettre à la disposition des décideurs des données à même de les éclairer et leur faciliter une prise de décision prompte en connaissance de cause. Un tel système requiert la mise en place d’un entrepôt de données fiables contenant les informations né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 en Algérie, notamment dans le domaine de la distribution de l’électricité et du gaz pour les professionnels et les particuliers. Appelé à interagir avec ses clients sur différentes phases de la distribution (demande de branchement, facturation, résiliation,…etc.), le groupe s’est doté, dans un souci de suivi de la 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 2900 utilisateurs. 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âche ardue. En effet, les sociétés de distributions « SD » se trouvent dans l’incapacité de faire des analyses fiables, efficaces et à des moments opportuns sans engager des moyens considérables sur 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 quelques 1 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 filiale Elit, le présent projet. Ce projet a pour but d’introduire, en premier lieu, une informatique décisionnelle au sein du groupe, tout en conférant aux décideurs un support fiable pour une meilleure prise de dé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 permet de définir les tâches à réaliser, maîtriser les risques et rendre compte de l’état d’avancement du projet. « Planifier optimise ainsi les chances de réussite d'un projet en améliorant la productivité 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 cette planification 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 se présente comme suit : Après une introduction générale dans laquelle nous présentons le contexte général du projet, ainsi que la problématique et les objectifs visés. La première partie présente les aspects théoriques du domaine des systèmes d’information d’aide à la décision, en évoquant leurs définitions et les concepts de bases relatifs aux « entrepôts de données » et à la modélisation dimensionnelle. 12
  • 21. Dans la deuxième partie, nous présentons le travail réalisé au sein du Groupe SONELGAZ à travers les six suivants chapitres: Le chapitre un, présente l’organisme d’accueil, sa structure organisationnelle, son activité 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 de l’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, ainsi que 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, ainsi que les stratégies adoptées. Le chapitre six, quant à lui, donne la conception des cubes dimensionnels en détaillant les 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 les différents outils intégrés et les volets de la solution développés. Elle décrit aussi la manière dont 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 citer les perspectives du projet. 13
  • 22. Partie I : Synthèse bibliographique « Un entrepôt de données ne s'achè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 moins considérable. Ces informations proviennent soit de sources internes (générées par leurs systè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 les exploiter à des fins d’analyse conduit, inévitablement, l’entreprise à se tourner vers une nouvelle informatique dite décisionnelle qui met l’accent sur la compréhension de l’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 leur environnement 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 pertinents permettant la sauvegarde, l’utilisation de la mémoire de l’entreprise et offrant à ses décideurs la 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 ces conditions, une structure informatique et une fondation des plus incontournables pour la mise en place d’applications décisionnelles. Le concept de Data Warehouse, tel que connu aujourd’hui, est apparu pour la première fois en 1980 ; l’idée consistait alors à réaliser une base de données destinée exclusivement au processus décisionnel. Les nouveaux besoins de l’entreprise, les quantités importantes de données produites par les systèmes opérationnels et l’apparition des technologies aptes à sa mise en œuvre ont contribué à l’apparition du concept « Data Warehouse » comme support aux 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 en place d’une informatique décisionnelle au sein de l’entreprise. Pour cela il serait assez inté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 les placer 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ôle et de distribution des informations nécessaires à l’exercice de l’activité en tout point de l’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 de dé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, du point de vue fonctionnel ou des tâches à effectuer, conduit à l’apparition des « systèmes d’information décisionnels » (S.I.D.). Ces différences seront clairement illustrées un peu plus loin dans notre document. 15
  • 24. Les origines des SID remontent au début de l’informatique et des systèmes d’information qui 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 l'intermédiaire d'interrogations 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 sein d’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, ont d’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 des télécommunications, le système décisionnel se manifeste à différents niveaux selon leurs e utilité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 avoir entre les systèmes transactionnels et les systèmes décisionnels selon les données et l’usage fait des 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 aux besoins 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érence dans 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, non volatiles 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 sont conç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 des données contenues dans le Data Warehouse. Le contenu en données et en relations entre elles diffè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 Data Warehouse 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 les différentes valeurs d’une donnée, cela permet les comparaisons et le suivi de l’évolution des valeurs dans le temps, alors que dans un système opérationnel la valeur d’une donnée est simplement 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 of time » [Inmon, 2000]. Non volatiles : c’est ce qui est, en quelque sorte la conséquence de l’historisation décrite précédemment. Une donnée dans un environnement opérationnel peut être mise à jour ou supprimé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 Data Warehouse sont organisées de manière à permettre l’exécution des processus d’aide à la dé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) remonte aux 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 et la 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ème opérationnel prise de façon périodique, dédiée à un environnement de support à la prise de décision. Ainsi, les données étaient extraites du système opérationnel, stockées dans une nouvelle base de données «concept d’infocentre », le motif principal étant de répondre aux requê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. Il est devenu une nouvelle source d’information, alimenté avec des données recueillies et consolidé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ées M Données agrégées E T A D O N N Données détaillées É E S 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éthodes d’agrégation et le lien entre les données opérationnelles et celles du Data Warehouse. Les mé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 quatre composantes : les applications opérationnelles, la zone de préparation des données, la pré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 de l’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 applications opérationnelles et la présentation des données. Elle est constituée d’un ensemble de processus appelé ETL, « Extract, transform and Load », les données sont extraites et stockées pour subir les transformations nécessaires avant leur chargement. « Un point très important, dans l’aménagement d’un entrepôt de données, est d’interdire aux utilisateurs l’accès à la zone de préparation des données, qui ne fournit aucun service 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 les données de la zone de préparation sont interdites aux utilisateurs, la zone de présentation est tout 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éfini comme étant une miniaturisation d’un Data Warehouse, construit autour d’un sujet précis d’analyse ou consacré à un niveau départemental3. Cette différence de construction, autour d’un sujet ou au niveau départemental, définit la façon d’implémentation du Data Mart au niveau de l’entrepôt. On distingue, en effet, deux architectures 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 niveau départemental, alimentées par le Data Warehouse et basées sur les besoins départementaux en s s informations [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 construits faits contenues dans le Data Warehouse, ce dernier se compose alors des Data Mart et ces tables 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 Data Warehouse 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 de donné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 Data Warehouse, il serait intéressant de connaitre le positionnement de ces éléments dans une architecture 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. Ces systèmes, devant répondre à des objectifs différents des systèmes transactionnels, ont fait ressortir très vite la nécessité de recourir à un modèle de données simplifié et aisément compréhensible. La modélisation dimensionnelle permet cela. Elle consiste à considérer un sujet d’analyse comme un cube à plusieurs dimensions, offrant des vues en tranches ou des analyses 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 est réputée pour ses performances élevées. La nomination « schéma des jointures en étoile » a longtemps été adoptée pour décrire un modèle dimensionnel. Cette nomination est due au fait que le diagramme qui représente un modèle dimensionnel ressemble à une étoile, avec une grande table centrale et un jeu de petites tables auxiliaires disposées en étoile autour de la table centrale. Celle-ci est appelée table de faits et les autres tables sont appelées tables de dimensions. La figure suivante illustre 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 de performances sont stockées. Une ligne d’une table de faits correspond à une mesure. Ces mesures sont généralement des valeurs numériques, additives ; cependant des mesures textuelles peuvent exister mais sont rares. Le concepteur doit faire son possible pour faire des mesures textuelles des dimensions, car elles peuvent êtres corrélées efficacement avec les autres attributs textuels de dimensions. Une table de faits assure les liens plusieurs à plusieurs entre les dimensions. Elles comportent des clés étrangères, qui ne sont autres que les clés primaires des tables de dimension. III.1.2 Concept de dimension Les tables de dimension sont les tables qui raccompagnent une table de faits, elles contiennent les descriptions textuelles de l’activité. Une table de dimension est constituée de nombreuses colonnes qui décrivent une ligne. C’est grâce à cette table que l’entrepôt de donné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 et des 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 dimensions Structure Peu de colonnes beaucoup de lignes Peu de lignes beaucoup de colonnes Données Mesurable, généralement numérique Descriptives généralement textuelles Référentiel Plusieurs clés étrangères Une clé primaire Valeur Prend de nombreuses valeurs Plus ou moins constantes Manipulation Participe à des calculs Participe à des contraintes Signification Valeurs de mesure Descriptive Rô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 de dimension. 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ées en hiérarchies. Cette modélisation est généralement justifiée par l’économie d’espace de stockage, cependant elle peut s’avérer moins compréhensible pour l’utilisateur final, et très couteuse en terme de performances. Modèle en constellation : Ce n’est rien d’autre que plusieurs modèles en étoile liés entre 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 technologies conçue pour l’accès aux données et pour une analyse instantanée de ces dernières, dans le but de répondre aux besoins de Reporting et d’analyse. R. Kimball définit le concept « OLAP » comme «Activité globale de requêtage et de présentation de données textuelles et numériques contenues dans l’entrepôt de données; Style d’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 les bases de données relationnelles, que le concept OLAP fut introduit et défini6 en 1993 par E.F Codd, le père des bases de données relationnelles, dans un document technique portant le titre de « 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 politique régissant l’architecture du serveur. Ainsi, ces architectures peuvent être distinguées comme suit: III.3.2.1 Les systèmes à architecture MOLAP Ces systèmes MOLAP « Multidimentional On-line Analytical Processing » sont conç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 dimensionnel est prépondérant » [Kimball, 2005]. Ainsi donc cette base adopte réellement la structure multidimensionnelle, exploitant de ce fait ces capacités au maximum. En effet MOLAP offre des temps d’accès optimisés et cela en 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 coup le système lorsque la quantité de données à traiter augmente. On parle généralement de volume 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ées aux 12 précédentes et le terme « règles » remplacé par dispositif «features » par le même auteur à savoir Codd (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 vision dimensionnelle à des bases de données relationnelles » [Kimball, 2005]. Les systèmes ROLAP « Relationnel On-line Analytical Processing » sont en mesure de simuler le comportement d’une SGBD multidimensionnel en exploitant un SGBD relationnel. L’utilisateur aura ainsi l’impression d’interroger un cube multidimensionnel alors qu’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ées dans une table relationnelle ce qui cause une lourdeur d’administration mais confère une certaine 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’acquisition d’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 d'exécution SQL Multi-Dimensionnel agrégées) et afin d'obtenir 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 de compromis entre les différents systèmes précités. Cette combinaison donne à ce type de système les avantages du ROLAP et du MOLAP en utilisant tour à tour l’un ou l’autre selon le 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 plus adoptées par les fournisseurs de solutions OLAP, d’autres systèmes se basent sur des architectures différentes telles que l’architecture OOLAP « Object On-line Analytical Processing », ou alors DOLAP « Desktop On-line Analytical Processing » qui décrit une catégorie de produits qui ne sont pas nécessairement connectés à un serveur et qui s’appuient sur une source de données (un cube) construites, stockées et exploitées en local sur la machine de l’utilisateur. III.4 La navigation dans les données Une fois que le serveur OLAP a construit le cube multidimensionnel « ou simulé ce cube selon l’architecture du serveur », plusieurs opérations sont possibles sur ce dernier offrant ainsi la possibilité de naviguer dans les données qui le constituent. Ces opérations de navigation « Data Surfing » doivent être, d’une part, assez complexes pour adresser l’ensemble des données et, d’autre part, assez simples afin de permettre à l’utilisateur de circuler de manière libre et intuitive dans le modèle dimensionnel. Afin de répondre à ces attentes, un ensemble de mécanismes est exploité, permettant une 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 faire des 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 ». La différence entre eux se manifestent dans le fait que : Le Slicing consiste à faire une sélection de tranches du cube selon des prédicats et selon 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 les plus 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érations permettent 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’une bonne hiérarchisation des attributs d’une dimension et la différenciation entre tous les niveaux de 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émarches pour la réalisation d’un projet Data Warehouse, ces démarches se croisent essentiellement dans 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 Warehouse Les 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. Toutes deux 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, la définition de celui-là reste la même. En étant un support d’aide à la décision, le Data Warehouse 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 est illustré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énients Aucun risque de concevoir une solution Pas de prise en compte de l’évolution des obsolè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. Cette approche 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, il considère que les besoins sont en constante évolution. Avantages Inconvénients Meilleure prise en charge de l’évolution des Risque de concevoir une solution obsolète besoins 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 structures des données du système opérationnel, et les valider par rapport aux besoins analytiques. Cette approche 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 des besoins 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 Data Warehouse. Ce modèle dimensionnel sera transformé en modèle physique, qui différera du modè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. Cette alimentation (le plus souvent appelée processus ETL « Extract-Transform-Load ») se déroule en 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 garantir l’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 Data Warehouse. 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 de données. Extraire, cela veut dire lire et interpréter les données sources et les copier dans la zone 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 les changements intervenus sur ces données. Pour cela, il existe trois stratégies de capture de changement : • Colonnes d’audit : la colonne d’audit, est une colonne qui enregistre la date d’insertion ou du dernier changement d’un enregistrement. Cette colonne est mise à jour soit par des triggers ou par les applications opérationnelles, d’où la nécessité de vérifier leur fiabilité. • Capture des logs : certains outils ETL utilisent les fichiers logs des systèmes sources afin de détecter les changements (généralement logs du SGBD). En plus de l’absence de cette fonctionnalité sur certains outils ETL du marché, l’effacement des fichiers logs engendre la perte de toute information relative aux transactions. 37
  • 46. • Comparaison avec le dernier chargement : le processus d’extraction sauvegarde des copies des chargements antérieurs, de manière à procéder à une comparaison lors de chaque nouvelle 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ès importante, assure en réalité plusieurs tâches qui garantissent la fiabilité des données et leurs qualité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’entreprise et 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 des structures du système de gestion de la base de données (tables et index) afin d’optimiser au mieux 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 la politique de chargement dépend des sources : disponibilité et accessibilité. Ces politiques sont8 : • 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 l'occasion. L'inconvé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. L'inconvénient de cette méthode est qu'elle peut surcharger le système s'il est en cours d'utilisation. • Push-pull : c'est la combinaison des deux méthodes. La source prépare les données à envoyer et indique à la zone de préparation qu'elle 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 la figure 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 processus d’alimentation doit palier à ce problème et assurer le chargement du Data Warehouse dans des délais acceptables. • Correctif : le processus d’alimentation doit apporter les correctifs nécessaires pour amé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 phases cité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’exploitation du Data Warehouse se fait par le biais d’un ensemble d’outils analytiques développés autour du Data Warehouse. Donc cette étape nécessite l’achèvement du développement, ou de la mise 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 utilisateurs de l’entrepôt de données, et spécialement les analystes, seront amenés à interagir avec le DW via 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 de choisir les outils qui lui paraissent les plus adéquats. b. Reporting : Destiné essentiellement à la production de rapports et de tableaux de bord, « il est la présentation périodique de rapports sur les activités et résultats d'une organisation, d'une unité de travail ou du responsable d'une fonction, destinée à en informer ceux chargés de les superviser en interne ou en externe, ou tout simplement concernés par ces activités ou résultants »9. Ces outils de Reporting ne sont pas, à proprement parler, des instruments d'aide à la décision, mais, lorsqu’ils sont utilisés de manière appropriée, ils peuvent fournir une précieuse vue d’ensemble. Les rapports sont alors crées par le biais d’outils de Reporting qui permettent de leur donner un format prédéterminé. Les requêtes sont constituées lors de l’élaboration des rapports qui seront ensuite diffusés périodiquement en automatique ou ponctuellement à la demande. 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 les capacités de l’entrepôt de données. Le but par l’analyse dimensionnelle est d’offrir aux utilisateurs la possibilité d’analyser les données selon différents critères afin de confirmer une tendance ou suivre les performances de l’entreprise. Cette analyse se fait selon le principe OLAP, offrant de ce fait aux utilisateurs les possibilités de recourir à différentes opérations facilitant la navigation dans les données. La mise en place de ces outils est une option très intéressante dans la mesure où les données seront accessibles en analyses instantanées. Plusieurs fournisseurs de solution OLAP existent sur 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 les besoins 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’évolution d’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 pour permettre aux gestionnaires de prendre connaissance de l’état et de l’évolution des systèmes qu’ils pilotent et d’identifier les tendances qui les influenceront sur un horizon cohérent avec la nature de leurs fonctions » [Bouquin, 2003]. Cette forme de restitution a la particularité de se limiter à l’essentiel, c'est-à-dire la mise en évidence de l’état d’un indicateur par rapport à un objectif, tout en adoptant une repré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 ce forage est d’extraire de la matière brute qui, dans notre cas, représente de nouvelles connaissances. L’idée de départ veut qu’il existe dans toute entreprise des connaissances utiles, cachées sous des gisements de données. Le Data Mining permet donc, grâce à un certain nombre de techniques, de découvrir ces connaissances en faisant apparaître des corrélations entre ces données. Le Data Warehouse constituera alors la première source de données sur laquelle s’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 entreprises modernes. Les applications et outils implémentant ces solutions sont rarement développés en interne. En effet, les entreprises préfèrent se reposer sur des valeurs sûres du marché afin d’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 projet Data Warehouse nécessite un suivi constant compte tenu des besoins d’optimisation de performance 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 de l’entrepôt de données. En outre, la relation directe avec les utilisateurs permet de détecter les correctifs nécessaires à apporter. Formation : il est indispensable d’offrir un programme de formation permanant aux utilisateurs de l’entrepôt de données. Support technique : un entrepôt de données est considéré comme un environnement de production. Naturellement le support technique doit surveiller avec la plus grande vigilance les 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épond aux besoins de l’entreprise. Les revues systématiques à certain point de contrôle sont un outil clé pour détecter et définir les possibilités d’amélioration. En plus du suivi et de la maintenance du Data Warehouse, des demandes d’expansion sont envisageables pour de nouveaux 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 du Data Warehouse. 42
  • 51. V. Conclusion Le concept « Data Warehouse » est apparu comme une réponse à des besoins grandissants dans le domaine décisionnel. Son adaptabilité et sa capacité de fournir les données nécessaires à une bonne analyse, ont fait de lui un atout majeur et incontournable pour 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’adopter une démarche précise qui doit tenir compte des réalités de l’entreprise et des contraintes du projet. La modélisation de l’entrepôt se fait dans tous les cas grâce à la modélisation dimensionnelle. L’alimentation en données constitue l’étape à laquelle il faut accorder le plus d’attention et de temps. En effet, elle est le garant de contenance de l’entrepôt en données fiables et correctes. Une fois l’alimentation terminée, l’exploitation des données peut alors se faire par différentes méthodes. L’utilisation d’outil OLAP reste, cependant, l’aspect le plus intéressant dans cette exploitation permettant la navigation dans les données de l’entrepôt à la demande. Au cours de la seconde partie de cette étude, nous allons essayer d’utiliser les concepts présentés dans la synthèse bibliographique, et cela afin de mettre en œuvre notre système. 43
  • 52. Partie II : Cas pratique « filiales de distribution SONELGAZ » 44
  • 53. Chapitre I : Présentation de l’organisme d’accueil. 45