155
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 - KEDJNANE SOFIANE - MERABET SOUAD - MEDJAOUI NADJI Promotion : 2009/2010

Conception et Réalisation d'un Data Warehouse

Embed Size (px)

DESCRIPTION

 

Citation preview

Page 1: Conception et Réalisation d'un Data Warehouse

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

- KEDJNANE SOFIANE

- MERABET SOUAD

- MEDJAOUI NADJI

Promotion : 2009/2010

Page 2: Conception et Réalisation d'un Data Warehouse

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Ä| ^xw}ÇtÇx 9 Y|ÄtÄ| ^xw}ÇtÇx 9 Y|ÄtÄ| ^xw}ÇtÇx 9 Y|ÄtÄ|

Page 3: Conception et Réalisation d'un Data Warehouse

DédicacesDédicacesDédicacesDédicaces

Je dédie ce m odeste travail à :

M es parents, qui n’ont jam ais cessé de m ’encourager et m e souten ir,

M on frère : M oham m ed, et m es sœurs :A m ina et Soum ia

M on binôm e et am i Sofiane et sa fam ille,

M es am is : A m ine, M ouhata, M oham m ed, L otfi …

Tous les m em bres de m a fam ille,

Ceux qui m e sont chers,

M on cousin : Sam ir, puisse d ieu l’accueillir dans son vaste paradis.

TuwxÜÜt{ÅtÇx

Page 4: Conception et Réalisation d'un Data Warehouse

DédicacesDédicacesDédicacesDédicaces

A :

M es parents, pour leur soutient indéniable et leur aide précieuse

« Pourrais-je jam ais vous dire tous m on am our»,

M a grand-m ère, pour sa patience et pour avoir su m e supporter,

M a sœur L inda, et m es frères Tareq et Yacine, pour leurs

encouragem ents et leur am our,

Tous les m em bres de la fam ille, pour l’intérêt qu’ils m ’ont m ontré,

M on binôm e (et am i) A bderrahm ane « H am za » et toute sa fam ille,

pour ce qu’ils m ’ont apporté,

M es am is, pour tous ce qu’on a partagé ensem ble,

Toutes les personnes proches que je n’ai pas citées

Je dédie ce travail.

fÉy|tÇx

Page 5: Conception et Réalisation d'un Data Warehouse

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

Page 6: Conception et Réalisation d'un Data Warehouse

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

Page 7: Conception et Réalisation d'un Data Warehouse

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

Page 8: Conception et Réalisation d'un Data Warehouse

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

Page 9: Conception et Réalisation d'un Data Warehouse

I

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.

Page 10: Conception et Réalisation d'un Data Warehouse

II

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.

Page 11: Conception et Réalisation d'un Data Warehouse

III

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.

Page 12: Conception et Réalisation d'un Data Warehouse

IV

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

Page 13: Conception et Réalisation d'un Data Warehouse

V

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

Page 14: Conception et Réalisation d'un Data Warehouse

VI

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

Page 15: Conception et Réalisation d'un Data Warehouse

VII

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

Page 16: Conception et Réalisation d'un Data Warehouse

8

Introduction générale

Page 17: Conception et Réalisation d'un Data Warehouse

9

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.

Page 18: Conception et Réalisation d'un Data Warehouse

10

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

Page 19: Conception et Réalisation d'un Data Warehouse

11

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.

Page 20: Conception et Réalisation d'un Data Warehouse

Planification et conduite du projet

L’initiation de tout projet 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é.

Pour garantir le bon déroulement du projet, tout en respectant les délais, é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.

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éraleprojet, ainsi que la problématique et les objectifs visés. théoriques du domaine des systèmes d’information d’aide à la décision, en évoquant leurs définitions et les concepts de bases dimensionnelle.

Planification et conduite du projet

out projet nécessite une phase de planification. Celledéfinir les tâches à réaliser, maîtriser les risques et rendre compte de l’état d’avancement

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, é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.

Figure : Planification et conduite du projet.

Afin de présenter notre travail, le présent mémoire est organisé en trois parties et se

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ésentethé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

Conception E.T.L

12

Celle-ci permet définir les tâches à réaliser, maîtriser les risques et rendre compte de l’état d’avancement

Planifier optimise ainsi les chances de réussite d'un projet en améliorant la

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

Afin de présenter notre travail, le présent mémoire est organisé en trois parties et se

le contexte général du présente les aspects

théoriques du domaine des systèmes d’information d’aide à la décision, en évoquant leurs la modélisation

Conception E.T.L

Page 21: Conception et Réalisation d'un Data Warehouse

13

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.

Page 22: Conception et Réalisation d'un Data Warehouse

14

Partie I : Synthèse bibliographique

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

Page 23: Conception et Réalisation d'un Data Warehouse

15

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.

Page 24: Conception et Réalisation d'un Data Warehouse

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 Cette évolution se poursuit à ce jour

Parmi les différentes définitions du décisionnel 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

La figure ci-dessus illustre parfaitement la place qud’une entreprise. Cette place, comprend plusieurs fonctions clés de l’entreprise. décisionnelles, étant différentes selon le poste et la fonction occupéed’engendrer plusieurs composantes.

2 Synthétisation à partir de la thèse de Bouzghoub A.

application au domaine de la sécurité sociale

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.

à ce jour2.

définitions du décisionnel « business intelligence B.I. »

"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

[Dresner, 2001].

décisionnel dans l’entreprise:

nnel au sein du Système d’information [Goglin, 1998]

dessus illustre parfaitement la place qui revient au décisi, comprend plusieurs fonctions clés de l’entreprise.

étant différentes selon le poste et la fonction occupée, ond’engendrer plusieurs composantes.

de Bouzghoub A. « Modélisation des entrepôts de données XML: application au domaine de la sécurité sociale » [Bouzghoub, 2008].

16

Les origines des SID remontent au début de l’informatique et des systèmes d’information la technologie.

» qui ont été

"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

[Goglin, 1998].

décisionnel au sein , comprend plusieurs fonctions clés de l’entreprise. Les finalités

ont pour but

Modélisation des entrepôts de données XML:

Page 25: Conception et Réalisation d'un Data Warehouse

I.1.2. Les différentes composantes du décisionnel

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 utilités et leurs missions principales

Figure I.2 : Les différentes composantes du décisionnel

s composantes du décisionnel

En relation étroite avec les nouvelles technologies de l’information et des e décisionnel se manifeste à différents niveaux selon leurs

utilités et leurs missions principales, comme illustré dans la figure suivante :

Les différentes composantes du décisionnel [Goglin, 1998]

17

En relation étroite avec les nouvelles technologies de l’information et des e décisionnel se manifeste à différents niveaux selon leurs

[Goglin, 1998].

Page 26: Conception et Réalisation d'un Data Warehouse

18

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

par

les

donn

ées

Orienté applications Orienté thèmes et sujets

Situation instantanée Situation historique

Donnée détaillées et codées non

redondantes

Informations agrégées cohérentes

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

L’u

sage

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

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 ».

Page 27: Conception et Réalisation d'un Data Warehouse

19

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…).

Page 28: Conception et Réalisation d'un Data Warehouse

20

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.

Figure I.3 : évolution des bases de données décisionnelles.

bases de données opérationnelles

Infocentre

Entrepôt de données

1980 1970 1990

Page 29: Conception et Réalisation d'un Data Warehouse

21

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 :

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.

ME

T

A

D

O

N

N

É

E

S

Données détaillées

Données détaillées archivées

Données agrégées

Données fortement agrégées

Page 30: Conception et Réalisation d'un Data Warehouse

22

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.

Page 31: Conception et Réalisation d'un Data Warehouse

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 Warehouseinformations [Inmon, 2002].

Figure I.5 : les Data Mart dans un entrepôt de données selon

Warehouse (E.D.W)

Data Mart sont des versions miniaturisées du Data Warehouse au niveau s par le Data Warehouse et basées sur les besoins départementaux en

Data Mart dans un entrepôt de données selon l’architecture Entreprise Data Warehouse (E.D.W) [Inmon, 2002].

23

Data Mart sont des versions miniaturisées du Data Warehouse au niveau s sur les besoins départementaux en

Entreprise Data

Page 32: Conception et Réalisation d'un Data Warehouse

2. Data Mart interconnectés

Les Data Mart sont construifaits 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

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 Ces outils varient des simples requêtes ad hoc aux données plus complexes. Environ 80 à 90% des utilisateurs sont desservis par des applications d’analyses préfabriquées, consista

4 Appellation proposée par R. Kimball dans son ouvrage [Kimball, 2002].

Data Mart interconnectés

es Data Mart sont construits autour de sujets, interconnectés grâce aux tables des faits contenues dans le Data Warehouse, ce dernier se compose alors des Data Mart et ces

les Data Mart dans un entrepôt de données selon l’architecture bus de [Kimball, 2002].

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

. Environ 80 à 90% des utilisateurs sont desservis par des applications ant essentiellement en des requêtes préétablies.

Appellation proposée par R. Kimball dans son ouvrage [Kimball, 2002].

24

autour de sujets, interconnectés grâce aux tables des faits contenues dans le Data Warehouse, ce dernier se compose alors des Data Mart et ces

bus de données

l’ensemble des moyens fournis aux utilisateurs du Data prise de décision.

outils permettant l’application de forage de . Environ 80 à 90% des utilisateurs sont desservis par des applications

s.

Page 33: Conception et Réalisation d'un Data Warehouse

25

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

Page 34: Conception et Réalisation d'un Data Warehouse

26

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 :

Page 35: Conception et Réalisation d'un Data Warehouse

27

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].

Page 36: Conception et Réalisation d'un Data Warehouse

28

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

dimensions Assure l’interface homme / entrepôt 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.

Page 37: Conception et Réalisation d'un Data Warehouse

29

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).

Page 38: Conception et Réalisation d'un Data Warehouse

30

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.

Figure I.11 : Principe de l’architecture ROLAP [Nakache, 1998].

Data Warehouse Moteur MOLAP Aide à la décision

Données Traitements Présentation

RapportsMulti-Dimensionnel

Stockage desdonnées détaillées (et

agrégées)

Data Warehouse Moteur ROLAP Aide à la décision

Données Traitements Présentation

RapportsMulti-Dimensionnel

Génération de plansd'exécution SQLafin d'obtenir des

fonctionnalités OLAP.

Stockage desdonnées détaillées (et

agrégées) etdes méta-données

Page 39: Conception et Réalisation d'un Data Warehouse

31

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].

Page 40: Conception et Réalisation d'un Data Warehouse

Figure I

Le Dicing, quant à lui, peut être vu comme étant une extraction d’un sous cube.

Figure I

III.4.2 Drill-down & Roll-up

Ces méthodes, appelées aussi «plus répandues pour une navigation dans un entrepôt représenter les données du cube à un niveau de granularité infdown », ou un niveau supérieur, c’est le «permettent de contrôler le niveau de détail des

Figure I.12 : Exemple de Slicing.

peut être vu comme étant une extraction d’un sous cube.

Figure I.13 : Exemple de Dicing.

up

aussi « forage vers le bas/vers le haut », sont les méthodes les navigation dans un entrepôt de données. Elles

représenter les données du cube à un niveau de granularité inférieur, dans le cas du «», ou un niveau supérieur, c’est le « Roll-up ». En somme, ces deux

permettent de contrôler le niveau de détail des données du cube.

32

», sont les méthodes les Elles consistent à

rieur, dans le cas du « Drill -ces deux opérations

Page 41: Conception et Réalisation d'un Data Warehouse

33

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 ».

Page 42: Conception et Réalisation d'un Data Warehouse

34

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].

Page 43: Conception et Réalisation d'un Data Warehouse

35

Avantages Inconvénients

Aucun risque de concevoir une solution obsolète avant d’être opérationnelle

Pas de prise en compte de l’évolution des 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].

Page 44: Conception et Réalisation d'un Data Warehouse

36

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 besoins

Risque de concevoir une solution obsolète 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.

7 “Give me what I tell you I want, then I can tell you what I really want.”[Inmon, 2002]

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

37

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.

Page 46: Conception et Réalisation d'un Data Warehouse

38

• 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/

Page 47: Conception et Réalisation d'un Data Warehouse

39

Aussi, le processus d’alimentation doit répondre à certaines exigences illustrées par la figure suivante :

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.

Processus ETL

Être sûr Être rapide

Être correctif

Être

tra

nsp

aren

t

Page 48: Conception et Réalisation d'un Data Warehouse

40

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

Page 49: Conception et Réalisation d'un Data Warehouse

41

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.

Page 50: Conception et Réalisation d'un Data Warehouse

42

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.

Page 51: Conception et Réalisation d'un Data Warehouse

43

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.

Page 52: Conception et Réalisation d'un Data Warehouse

44

Partie II : Cas pratique « filiales de distribution SONELGAZ »

Page 53: Conception et Réalisation d'un Data Warehouse

45

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

Page 54: Conception et Réalisation d'un Data Warehouse

46

I. Présentation de SONELGAZ

I.1 Historique

SONELGAZ est l’opérateur historique dans le domaine de la fourniture des énergies électrique et gazière en Algérie. Ses missions principales sont la production, le transport et la distribution de l’électricité ainsi que le transport et la distribution du gaz par canalisations. Son nouveau statut lui confère la possibilité d’intervenir dans d’autres segments d’activités présentant un intérêt pour l’entreprise et notamment dans le domaine de la commercialisation de l’électricité et du gaz à l’étranger. Durant son existence le groupe a connu des évolutions majeures qui peuvent être résumées comme suit :

1947, Création d’EGA : C’est le décret du 5 juin 1947 qui a crée l’Etablissement Public National « Electricité et Gaz d’Algérie » (EGA par abréviation). Par décret du 16 août 1947, seize sociétés qui se partageaient les concessions électriques ont été transférées à EGA. Ces sociétés détenaient alors 90% des propriétés industrielles électriques et gazières du pays. 1962, Le défi de la relève : Cette année représente la prise en main de l’Algérie indépendante de la SONELGAZ –alors Electricité et Gaz d’Algérie – et cela en faisant face au départ massif de cadres et techniciens français.

Période allant de 1962 à 1969 : Cette période a été caractérisée par la baisse de la consommation (une baisse de prés de 33% en deux ans) dû au départ massive des étrangers qui représentaient plus de 87% de la clientèle. Par ailleurs, les tâches les plus urgentes ont été de reprendre le fichier des abonnés, reconstituer les plans des ouvrages et des réseaux, procéder au recrutement et à la formation dans tous les domaines et de ramener le niveau de consommation de l’énergie à celui de 1961. 1969, création de SONELGAZ: C’est l’ordonnance n° 69-59 du 28 juillet 1969) portant dissolution de l’EGA et création de la nouvelle Société Nationale de l’Electricité et du GAZ - SONELGAZ-. Ce texte s’inscrit dans le cadre des mesures de nationalisation des secteurs clés de l’économie nationale. L’ordonnance précitée a attribué à l’entreprise le monopole de la production, du transport, de la distribution, de l’importation et de l’exportation de l’électricité et du gaz manufacturé (art. 4 et 7). L’ensemble des biens de l’ex-EGA lui a été légué. 1977, le plan national d’électrification : Dès le milieu des années 70, l’Algérie s’est engagée dans un ambitieux plan national d’électrification qui avait objectif l’amélioration des conditions de vie des populations des campagnes tout en assurant un développement harmonieux de l’espace rural.

1983, naissance des entreprises travaux : six entreprises autonomes voient le jour : KAHRIF pour l’électrification; KAHRAKIB - Infrastructures et installations électriques; KANAGAZ - Réalisation des réseaux gaz; INERGA - Génie civil; ETTERKIB – Montage industriel et l’entreprise AMC - Fabrication des compteurs et appareils de mesure et de contrôle.

Page 55: Conception et Réalisation d'un Data Warehouse

47

1991, SONELGAZ EPIC : SONELGAZ change de nature juridique et devient Etablissement Public à caractère Industriel et Commercial (EPIC) en vertu du décret exécutif n° 91-475 du 14 décembre 1991, portant transformation de la nature juridique de la Société Nationale de l’Electricité et du Gaz. Le décret exécutif n° 95-280 du 17 septembre 1995 confirme la nature de SONELGAZ en tant qu’Etablissement Public à caractère Industriel et Commercial.

1998, création de filiales périphériques : Le 1er janvier 1998, neuf filiales périphériques ont vu le jour.

2002, promulgation de la loi 02 / 01 du 5 février 2002 : Promulguée en février 2002, la nouvelle loi relative à l’électricité et à la distribution du gaz par canalisations est venue supprimer le monopole exercé jusque là par SONELGAZ, en ouvrant le secteur de l’électricité et du gaz à la concurrence, sauf pour les activités de Transport qui ont un caractère de monopole naturel.

Juin 2002, SONELGAZ SPA : En vertu du décret présidentiel n° 02-195 du 1er juin 2002 portant statuts de la Société algérienne de l’électricité et du gaz dénommée "SONELGAZ. Spa", SONELGAZ est passé d’Etablissement Public à caractère Industriel et Commercial à une Société Par Actions dont le capital est détenu par l’Etat. Sur le plan de son fonctionnement, SONELGAZ Spa est dotée d’une Assemblée Générale et d’un Conseil d’Administration. Elle est dirigée par un Président directeur général.

I.1.1 Organisation du groupe

SONELGAZ, et afin de se mettre en conformité avec les dispositions de la loi de février 2002, qui lui confère le statut de Société Par Actions, s’est érigée en un Groupe Industriel constitué de sociétés opérationnelles et d’une Société Mère. Chacune des sociétés ayant des missions et objectifs différents, il en ressort les principes d’organisation suivants :

Maison Mère : elle est chargée essentiellement de l’élaboration de la stratégie et de pilotage du Groupe, le contrôle des filiales, l’élaboration et la mise en œuvre de la politique financière et la définition de la politique de développement de la Ressource Humaine.

Filiales Métiers de base : Durant ces cinq dernières années, les métiers de base de SONELGAZ ont été érigés en filiales. Au nombre de huit, ces dernières activent dans les domaines de la production, la gestion du réseau de transport, la gestion du système production / transport, la distribution de l’électricité et du gaz (quatre sociétés).

Filiales Travaux : Les entreprises de réalisation érigées en entreprises autonomes à la faveur de la restructuration de 1984 ont été réintégrées, depuis janvier 2006, au sein du Groupe SONELGAZ.

Filiales Périphériques : SONELGAZ a externalisé ses activités périphériques et les a confiées à des filiales dont elle détient entièrement le capital. Ces filiales sont au nombre de quatorze et opèrent dans des activités diverses.

Page 56: Conception et Réalisation d'un Data Warehouse

48

Sociétés en Participation : SONELGAZ s’est investie dans des domaines clés à haute valeur technologique tels que les télécommunications ou la maintenance de turbines à gaz.

L’organigramme suivant donne une vision claire et précise de la structure de l’entreprise et de son administration :

Figure II.1 : Organigramme représentant l’organisation du Groupe SONELGAZ.

Page 57: Conception et Réalisation d'un Data Warehouse

49

I.1.2 Le groupe en chiffres

Le tableau suivant donne les chiffres relatifs à l’activité du groupe pour l’année 2008:

Critères Chiffres

Chiffre d’affaire groupe 137 529 millions de DA

Investissements groupe 190 828 millions de DA

Ventes Electricité 32 584 millions de kWh Gaz 7.44 Milliards de m3

Nombre de clients Electricité 6 298 682 Gaz 2 638 963

Production d’électricité groupe

Production SPE 28 970 millions de kWh Production IPP 11 017 millions de kWh

Personnel en activité du groupe

Permanents 35 633 agents Temporaires 24 761 agents

Tableau II.1 : Le groupe SONELGAZ en chiffres « année 2008 ».

La figure suivante illustre l’évolution du chiffre d’affaire du groupe depuis l’année 2001 :

Figure II.2 : Evolution du chiffre d’affaire du groupe « rapport d’activité de l’année 2008 ».

Page 58: Conception et Réalisation d'un Data Warehouse

50

La répartition du chiffre d’affaire du groupe pour l’année 2008 est de la manière suivante :

Figure II.3 : Répartition du chiffre d’affaire publiée dans le rapport d’activité de l’année 2008.

I.2 Le métier de la distribution

L’un des métiers les plus importants du groupe, et dans lequel s’inscrit notre projet, est la fourniture et la distribution de l’énergie électrique et gazière. Ce métier, vu l’organisation du groupe, est assuré par quatre filiales qui sont les « Sociétés de Distribution ». Les sociétés sont :

• Sociétés de Distribution d’Electricité et du Gaz de l’Ouest (SDO).

• Sociétés de Distribution d’Electricité et du Gaz du Centre (SDC).

• Sociétés de Distribution d’Electricité et du Gaz d’Alger (SDA).

• Sociétés de Distribution d’Electricité et du Gaz de l’Est (SDE).

Page 59: Conception et Réalisation d'un Data Warehouse

Les Sociétés de Distribution d’Electricité et du Gaz

• L’exploitation et la maintenance du réseau de distribu• Le développement des réseaux électricité et gaz permettant le ra

nouveaux clients. • La commercialisation de l’électricité et du gaz.

Le tableau suivant donne une vue d’ensemble des chiffresdistribution :

SDO

Création Jan. 2006

Chiffre d’affaire (MDA) 26.366,14

Nombre de clients ELEC 1.668.668

GAZ 549.904

Nombre d’employés 4406

Tableau II.2 : Présentation des sociétés de distribution en chiffres

I.2.1 Organisation des sociétés de distribution

Chaque société de distribution compte cinq siège, et gère un certain nombre de de Distributions gère des « Services Commerciaux

Figure II.4 :

de Distribution d’Electricité et du Gaz ont pour principales mission

’exploitation et la maintenance du réseau de distribution de l’électricité et du gaz.e développement des réseaux électricité et gaz permettant le raccordement des

tion de l’électricité et du gaz.

Le tableau suivant donne une vue d’ensemble des chiffres d’affaires des sociétés de

SDO SDC SDA SDE

Jan. 2006 Jan. 2006 Jan. 2006 Jan. 2006

26.366,14 16.242 17.713 39,752

1.668.668 1.290.058 810.636 2.069.266

549.904 389.410 383.583 893.750

4406 3211 2412 4887

Présentation des sociétés de distribution en chiffres « année 2008

des sociétés de distribution

Chaque société de distribution compte cinq directions centrales, situées au niveau de son siège, et gère un certain nombre de « Directions de distribution ». Chacune de ces Directions

Services Commerciaux ». L’organigramme suivant illustre

Organisation des sociétés de distribution.

51

missions d’assurer :

tion de l’électricité et du gaz. ccordement des

des sociétés de

Jan. 2006

39,752

2.069.266

893.750

année 2008 ».

directions centrales, situées au niveau de son Chacune de ces Directions

illustre :

Page 60: Conception et Réalisation d'un Data Warehouse

L’organisation des directions de distribution se présente comme suit

Figure II.5 : Organisation des Directions de Distribution.

I.2.2 La clientèle de la distribution

La segmentation des clients se fait selonclient. Ainsi, on distingue :

a. en électricité :

• Client « Basse Tension-BTconsidéré comme un client

• Client « Moyenne Tensionl’abonné est considéré commeou 30 KV.

• Client « Haute Tension-HTtout client dont la tension d’alimentation est

b. En gaz :

• Client « Basse Pression-BPtravers un détendeur.

• Client « Moyenne Pressionavec un poste de détente gaz

• Client « Haute Pression-HPbars avec un poste de détente gaz.

L’organisation des directions de distribution se présente comme suit :

Organisation des Directions de Distribution.

La clientèle de la distribution

La segmentation des clients se fait selon la puissance de l’énergie à laquelle est abonné le

BT » : jusqu’à une puissance de 40 KVA, un client BT. La tension délivrée est 220 V ou 380 V.

Moyenne Tension-MT » : d’une puissance de 50 KVA jusqu’àl’abonné est considéré comme un client MT La tension d’alimentation est de 10 KV

HT » : est considéré comme client « Haute Tensiontout client dont la tension d’alimentation est supérieure à 60 KV.

BP » : tout client alimenté sous une pression de

ression-MP » : tout client alimenté sous une pression de avec un poste de détente gaz.

HP » : tout client alimenté sous une pression supavec un poste de détente gaz.

52

quelle est abonné le

, l’abonné est

jusqu’à 630 KVA, La tension d’alimentation est de 10 KV

Haute Tension-HT »

alimenté sous une pression de 21 bars à

alimenté sous une pression de 4 bars

alimenté sous une pression supérieure à 4

Page 61: Conception et Réalisation d'un Data Warehouse

53

En BT/BP, on distingue plusieurs types de clients :

• Clients ménages : il s’agit des clients domestiques.

• Clients non ménages : il s’agit des clients non domestiques (Activités commerciales).

• Clients FSM (Facturation sur mémoire).

I.3 L’informatique au sein du groupe SONELGAZ

L’informatique occupe une place très importante au sein du groupe SONELGAZ. En effet, la taille du groupe et son activité l’oblige à se doter des moyens technologiques de pointe afin d’assurer ses activités métiers et de gestion.

L’informatique au sein du groupe a évolué au fil des années comme suit :

• Jusqu’à la fin des années 80, l’informatique était essentiellement présente au niveau central sur gros systèmes. Cette période a vu le développement de systèmes de gestion de l’entreprise et l’acquisition de modèles scientifiques de calcul pour la planification des réseaux Electricité et Gaz (CARAT et APHYRE).

• La réorganisation de SONELGAZ en 1991 et l’avènement des mini et micro-ordinateurs ont précipité la décentralisation de l’informatique.

• En 1996, le schéma directeur informatique de l’entreprise a défini la stratégie de décentralisation de l’informatique vers une informatique distribuée, se basant sur l’interconnexion des réseaux locaux à travers un réseau de télécommunication propre.

• En 2006, le Groupe centralise l’activité informatique par la création de la Direction Générale des Systèmes d’Information (DGSI), chargée de la maîtrise d’œuvre dans le domaine de l’informatique.

• En 2009, la DGSI s’est érigée au rang de filiale spécialisée dans le domaine des systèmes d’information et technologies nouvelles sous le nom de « ELIT ».

I.3.1 Présentation de « ELIT »

Elit « El-Djazaïr Information Technology » élabore et met en œuvre les systèmes d’information destinés au pilotage et à la gestion des différentes activités du groupe SONELGAZ, assure l’accès à l’information et aux applications, en garantit la sécurité, l’intégrité et la fiabilité et met à la disposition de ses clients l’expertise technique indispensable à la satisfaction de leurs besoins.

Page 62: Conception et Réalisation d'un Data Warehouse

54

L’organigramme suivant illustre la manière dont est organisée la filiale « ELIT » et la distribution de son effectif:

Figure II.6 : Organisation de la filiale ELIT.

La direction études et développement

Notre stage se déroule au sein de la direction d’étude et de développement. Ce département a pour mission de faire : l’étude, la conception, le développement et le déploiement de solutions nouvelles et la mise en place des systèmes d’information du groupe. Aussi, il offre l’assistance nécessaire et le suivi des solutions déployées.

Page 63: Conception et Réalisation d'un Data Warehouse

55

L’organigramme et l’effectif de la direction « études et développement » se présente comme suit :

Figure II.7 : Organisation de la direction d’étude et de développement.

Remarque : au niveau de chaque « DD » il existe une « Division Gestion des Systèmes

Informatique ». Cette dernière s’occupe essentiellement du suivie et de la maintenance des

systèmes déjà déployés, ainsi que de la gestion du matériel informatique au niveau de la DD

et des agences affiliées.

Page 64: Conception et Réalisation d'un Data Warehouse

56

II. Conclusion

Avec ses décennies d’activité dans le domaine de l’énergie et une réputation qui dépasse les frontières du pays, le groupe SONELGAZ représente un acteur majeur et incontournable de l’économie nationale. Cette brève présentation nous a permis de connaître un peu plus le groupe SONELGAZ, notamment dans sa nouvelle configuration de holding industriel.

Par ailleurs, cette présentation nous a fait comprendre la structuration et l’organisation du métier de la distribution, qui est le premier visé par ce projet, et de nous pencher sur l’informatique du groupe désormais gérée, au niveau national, par la filiale « ELIT ».

Dans le chapitre suivant, une étude détaillée de l’existant décisionnel du groupe, dans sa fonction de distribution, sera présentée.

Page 65: Conception et Réalisation d'un Data Warehouse

57

Chapitre II : étude de l’existant

Page 66: Conception et Réalisation d'un Data Warehouse

58

I. Introduction

Le groupe SONELGAZ veut, par le biais de ce projet, palier à un manque important en matière de décisionnel. Ce manque se caractérise par la quasi inexistence de support d’aide à la décision, et l’indisponibilité de moyens de Reporting efficaces, en mesure de fournir des informations adéquates en temps voulu.

Partant de ce constat, nous allons essayer, à travers ce chapitre, de présenter une analyse aussi complète que possible de l’existant décisionnel du groupe dans le cadre de sa fonction de distribution. Ce chapitre a aussi pour but de faire connaître les procédures et les méthodes de Reporting et de prise de décision, ainsi que les éventuelles lacunes qui peuvent exister.

II. Etat du décisionnel au sein du groupe

Il est intéressant de signaler que le groupe, dans sa fonction de distribution, ne dispose d’aucun système d’aide à la décision automatique ou semi-automatique. Aussi, tout processus d’analyse et de prise de décision à tous les niveaux se base essentiellement sur des rapports dont les données sont extraites et consolidées à partir des systèmes transactionnels d’une manière manuelle.

Lors de notre étude de l’existant, nous avons pu recenser deux procédés pour l’élaboration des rapports. Les deux procédés se distinguent par leurs utilisateurs finaux, la structure chargée de leur élaboration et le niveau de consolidation.

II.1 Niveau Groupe

A ce niveau de hiérarchie, les utilisateurs ont besoin de chiffres qui concernent l’ensemble du groupe, dans sa fonction de distribution. Ces rapports sont essentiellement livrés par la filiale « ELIT ». Les données étant consolidées à partir des bases de production des « DD » des quatre filiales de distribution. Cela suppose donc, la participation de différents acteurs dispersés sur l’ensemble du territoire national ainsi que sur l’ensemble des filiales distributions.

Dans le meilleur des cas, le rapport demandé concerne des données déjà consolidées et prêtes à l’utilisation. L’élaboration du rapport se fait donc sans grandes difficultés. Sinon, le procédé d’extraction et de consolidation est relancé. Le diagramme suivant donne une vision claire de la manière dont sont consolidées les données et les rapports élaborés en partant de la demande d’un état donné jusqu'à sa production :

Page 67: Conception et Réalisation d'un Data Warehouse

59

Figure II.8 : Diagramme d’activité modélisant l’édition de rapport pour le niveau groupe.

À partir de ce diagramme on peut d’ores et déjà avoir une idée sur le nombre d’intervenants dans cette procédure qui reste une tâche très fastidieuse, surtout dans sa partie consolidation des données. Cette procédure se déroule comme suit:

Phase 1 : les utilisateurs de niveau groupe, principalement des analystes et des décideurs de la DGDS et de la maison mère, formulent leurs requêtes qui sont transmises au département « Systèmes d’information de la distribution » (SID) de la filiale « ELIT ».

Phase 2 : le département SID, en recevant une demande de la part des utilisateurs de niveau groupe, lance la procédure de consolidation des données à partir des différentes DD du groupe. Cette procédure doit faire l’objet d’une validation de la part du directeur études et développement. La demande est ensuite transmise au chef de CTI de chaque DD.

Phase 3 : Les chefs de CTI, en recevant la demande d’extraction, programment une tranche horaire et préparent les scripts d’extraction. L’étape d’extraction aboutit à la transmission de fichier texte vers le département SID.

Page 68: Conception et Réalisation d'un Data Warehouse

60

Remarque : les fichiers, étant d’une taille assez volumineuse, peuvent atteindre une

centaine de mégas voire plus. Ces dits fichiers subissent parfois des altérations durant le

transfert ou deviennent carrément inutilisables. Dans ce cas les « D.D. » concernées sont

recontactées pour une nouvelle extraction ou un nouvel envoi selon la nature du problème. Il

arrive parfois, suite à des problèmes réseaux, de recourir au transfert des données sur

support physique transportable (CD, clé USB).

Phase 4 : Une fois les données reçues en totalité, la consolidation se fait au niveau du département « SID » manuellement. Cette consolidation permet d’élaborer les rapports voulus.

Phase 5 : Le rapport est validé par le chef de département est et envoyé aux utilisateurs finaux.

Remarque : la procédure se répète généralement quatre fois par an, la consolidation

des chiffres se faisant chaque trimestre. Mais cela n’empêche pas le lancement de cette

procédure en cas de nécessité.

Sauf en cas de problèmes, toute échange d’information « demandes et fichiers joints »

se fait par le biais de la messagerie interne du groupe.

II.2 Niveau Sociétés de Distribution

Pour le niveau « SD », la procédure se déroule exactement comme pour le niveau groupe. A cela près que « ELIT » n’intervient pas à ce niveau là. C’est alors aux ingénieurs de la structure concernée de prendre en charge la consolidation et l’élaboration des rapports. Les différences notées sont :

Emission de la demande : La demande est formulée par les analystes et décideurs des deux directions Commerciale Marketing « DCM » et Comptabilité et Finance « DCF ».

Extraction des données: l’extraction se fait toujours aux niveaux des DD affiliées à la SD. Dans la plupart du temps les données sont transférées directement sous forme de rapports10.

Consolidation des données : la consolidation se fait soit à partir des fichiers de données, soit en se basant sur les rapports transmis par les DD. Cette consolidation se fait toujours de façon manuelle et monopolise les ingénieurs et techniciens de SD.

Remarque : la procédure d’élaboration de rapports au niveau SD se fait

généralement chaque fin de mois. Elle peut aussi être lancée en cas de nécessité.

10

Ces rapports obéissent à des canevas prédéfinis.

Page 69: Conception et Réalisation d'un Data Warehouse

61

II.3 Niveau Directions de Distribution

Les consommateurs de rapports au niveau des DD utilisent des rapports livrés directement par leurs CTI. Ces rapports, basés exclusivement sur les données des systèmes transactionnels, sont élaborés et transmis à la demande des managers. Le schéma suivant montre la manière dont sont traitées les demandes de rapport au niveau DD.

La demande est transmise directement du manager vers le chef de CTI via la messagerie interne «lotus de l’entreprise ». Le chef de CTI charge son équipe technique de l’élaboration du rapport demandé qu’il contrôle avant sa transmission à qui de droit.

L’élaboration des rapports se fait à ce niveau soit par le bais du module « Statistique11 » du SGC, Soit par des requêtes SQL. La présentation du rapport se fait alors selon le canevas demandé.

Remarque : Vu le nombre important de demandes et de sollicitations, certaines DD

ont mis à la disposition des managers et des décideurs des systèmes qui fournissent des états

statistiques à la demande. Cependant, ces systèmes, en interrogeant directement la base de

données transactionnelle en production, offrent des services limités avec des temps de

réponse non satisfaisants.

Cette mise en place de systèmes, ne fait qu’encourager le groupe à uniformiser les

procédures et méthodes de prise de décision.

11

Ce module a été développé pour fournir un certain nombre de rapports statistiques au niveau DD. Il interagit directement avec la base de données en production et pénalise souvent le système transactionnel.

Page 70: Conception et Réalisation d'un Data Warehouse

62

III. Conclusion

Cette étude nous permet d’avoir une vision générale des procédures d’élaboration de rapports et de consolidation des données. Elle constitue aussi le point de départ pour définir le périmètre du projet en général et de l’étude des besoins en particulier. Elle fait ressortir les insuffisances du système actuel en soulignant les points faibles ou les goulots d’étranglements de ce dernier.

Le chapitre suivant consacré à l’étude des besoins, aidera à détecter ceux des utilisateurs de manière à pouvoir y répondre.

Page 71: Conception et Réalisation d'un Data Warehouse

63

Chapitre III : Définition des besoins.

Page 72: Conception et Réalisation d'un Data Warehouse

I. Introduction

Tout Data Warehouse doit être en mesure de répondre aux attentes des utilisateurs. Cela ne peut, évidemment, se faire sans une étude

Ainsi, il existe deux démarches qui ont été décrites bibliographique, et qui sont: l'approche «

L'application exclusive de lrésultats satisfaisants. La démarche généralement adoptée est une démarche mixte, qui allie entre les deux précédentes dans un souci de prise en considération des besoins des décideurs sans perdre de vue toute possibilitapproche permet donc de recueillir, corriger et de modérer les attentes des utilisateurs dès le départ, tout en détectant d'éventuels besoins non exprimés.

Durant l’étude des besoins on ne peut se limnéanmoins, il faudrait absolument prendre en comptedonnées des systèmes sources« Les DBA sont les principaux experts sur les applications

existantes susceptibles d'aliment

confronter aux réalités certains des thèmes qui surgissent lors des rencontres avec les

utilisateurs finaux. » [Kimball, 96]

Figure II.9 : La place de l’étape d’étude des besoins dans un projet Data Warehouse.

Tout Data Warehouse doit être en mesure de répondre aux attentes des utilisateurs. e sans une étude approfondie de leurs besoins.

Ainsi, il existe deux démarches qui ont été décrites lors de notre synthèse et qui sont: l'approche « Buttom Up » et l'approche « Top Down

e l'une de ces deux approches ne produit nullement des résultats satisfaisants. La démarche généralement adoptée est une démarche mixte, qui allie entre les deux précédentes dans un souci de prise en considération des besoins des décideurs sans perdre de vue toute possibilité et opportunité offerte par les données sourcesapproche permet donc de recueillir, corriger et de modérer les attentes des utilisateurs dès le départ, tout en détectant d'éventuels besoins non exprimés.

Durant l’étude des besoins on ne peut se limiter aux interviews avec les utilisateursabsolument prendre en compte l’avis des Administrateurs des bases de

Les DBA sont les principaux experts sur les applications

existantes susceptibles d'alimenter l'entrepôt de données. Leurs interviews servent à

confronter aux réalités certains des thèmes qui surgissent lors des rencontres avec les

[Kimball, 96]

La place de l’étape d’étude des besoins dans un projet Data Warehouse.

64

Tout Data Warehouse doit être en mesure de répondre aux attentes des utilisateurs.

notre synthèse Top Down ».

approches ne produit nullement des résultats satisfaisants. La démarche généralement adoptée est une démarche mixte, qui allie entre les deux précédentes dans un souci de prise en considération des besoins des décideurs

par les données sources. Cette approche permet donc de recueillir, corriger et de modérer les attentes des utilisateurs dès le

iter aux interviews avec les utilisateurs, Administrateurs des bases de

Les DBA sont les principaux experts sur les applications

données. Leurs interviews servent à

confronter aux réalités certains des thèmes qui surgissent lors des rencontres avec les

La place de l’étape d’étude des besoins dans un projet Data Warehouse.

Page 73: Conception et Réalisation d'un Data Warehouse

65

Ce chapitre a pour principale vocation d’exposer et de décrire la démarche adoptée pour la détection des besoins ainsi que la présentation de la synthèse qui en sera faite.

I.1 Description de la démarche d'étude des besoins

Afin de faire une étude aussi complète que possible, nous avons choisi d'adopter une démarche qui nous a permis de combiner, d’une manière assez satisfaisante, entre l'approche « Buttom Up » et l'approche « Top Down ».

Ainsi, notre démarche peut se résumer au travers des étapes suivantes:

• Étude préliminaire des systèmes sources et interviews sommaires avec les DBA,

• Détection des postes susceptibles d'être porteurs d'informations utiles,

• Planification, préparation et conduite des interviews:

• Utilisation d’autres moyens pour la détection des besoins,

• Rédaction et validation du recueil récapitulatif des besoins,

a. Étude préliminaire des systèmes sources et interviews sommaires avec les DBA

Cette étude représente une étape de compréhension des systèmes opérationnels et de leur environnement. Elle a pour mérite de consolider les connaissances acquises durant l’étude de l’existant, ainsi que le jargon et le fonctionnement de l’entreprise. En outre, cette étape permet de détecter, de manière succincte, les postes susceptibles d’interagir avec le Data Warehouse. Elle est de ce fait indispensable pour un bon recensement des besoins.

Outre les DBA, qui sont pour la plupart des chefs de CTI, les gestionnaires qui se trouvent au sein de l’Elit, et dont la fonction principale est de définir les règles de gestion des applications et de s’assurer du respect des procédures propres à la distribution, ont été une source d’information assez bénéfique, eu égard à leur connaissance des applications du SGC et de leur maîtrise du métier du groupe.

b. Détection des postes susceptibles d'être porteurs d'informations utiles

Vu le grand nombre d’employés activant au sein du groupe SONELGAZ, notamment dans la fonction de distribution, ainsi que la dispersion géographique des filiales, il nous a été, bien sûr, impossible de voir et d’interviewer toute cette population. Ainsi, notre étude s’est axée sur les utilisateurs SDA, SDC.

Cette étape nous a permis, donc, d’identifier, en premier lieu, les services qui peuvent être porteurs d’informations tangibles et qui représentent la population potentiellement utilisatrice du projet. Ces dits services sont classés selon leur appartenance aux différentes structures, indiqué dans le tableau suivant:

Page 74: Conception et Réalisation d'un Data Warehouse

66

Structure Intitulé du poste Nombre total de postes

Direction de distribution Directeur régional de distribution 58 (1 chef par DD)

Commercial 58 (1 chef par DD)

Division finance et comptabilité 58 (1 comptable par DD)

Administrateur 58 (1 administrateur par DD)

Société de distribution P.D.G de la SD 4

D.C.M 4

Directeur finance et comptabilité 4

Groupe P.D.G 1

DGDS

- DAP

- DAR

- ED

3

Total 248

Tableau II.3 : Tableau présentant la population à interviewer.

c. Planification, préparation et conduite des interviews

Avant de détailler cette étape, il est nécessaire de justifier notre choix de l’entretien « interviews » comme méthode de collecte des besoins. Bien qu’il existe d’autres méthodes d’identification des besoins, les entretiens s’imposent comme étant la valeur sûre dans un tel projet. En effet, cette méthode a l’avantage d’être, plus ou moins, facilement planifiable et d’ouvrir le dialogue avec les interviewés, qui sont pour la plus part des décideurs et des analystes.

Dans le souci de conduire à bien cette étape, qui du reste est très critique et délicate, il est nécessaire de passer par différentes phases, à savoir :

1 La phase de planification

La planification se fait généralement plusieurs jours à l’avance. Elle nous permet de prendre les rendez-vous nécessaires et de prévenir les futurs interviewés de notre arrivée et du motif de cet entretien.

Cette phase, qui est un préalable indispensable, s’est avérée être une tâche très ardue. En effet, la nature organisationnelle et la dispersion des structures liées à la distribution ont posé des problèmes que nous évoquerons plus loin. Cependant ces mêmes facteurs nous ont

Page 75: Conception et Réalisation d'un Data Warehouse

67

poussés à entreprendre ce genre de démarches dans un souci de bonne conduite du projet et afin de ne pas perdre de temps dans des allers et retours improductifs.

Aussi, nous avons essayé de planifier nos entretiens de manière à avoir une certaine alternance entre les interviews des potentiels utilisateurs et les entretiens avec les DBA et les gestionnaires de manière à combiner entre les besoins d’analyse et les potentialités des systèmes sources et de leurs données.

2 La phase de préparation

Une fois la planification de l’entretien terminée, sa préparation doit se faire de telle sorte à ce qu’il se déroule dans les meilleures conditions possibles.

La préparation se résume essentiellement en l’identification des questions à poser, des points à soulever et des thèmes à éviter afin de ne pas trop s’éparpiller.

Les questions à poser sont classées en deux catégories, selon le poste de la personne interviewée. Ainsi certaines questions sont destinées aux décideurs alors que d’autres sont destinées aux analystes.

3 La conduite des entretiens

Dernière phase de l’étape, la conduite des interviews représente la réalisation sur le terrain des phases précédentes. Le but escompté étant d’amener les interviewés, au travers de leurs réponse à nos questions, de présenter leur travail et la manière dont ils procèdent pour le faire. L’identification des besoins se fera alors en détectant les métriques qu’ils utilisent et les informations sur lesquelles ils s’appuient pour la prise de décision.

d. Autres moyens utilisés pour la détection des besoins

Bien que les entretiens représentent une source importante d’informations et aident grandement à l’identification des besoins des utilisateurs, leur utilisation exclusive n’est pas conseillée dans la construction d’un entrepôt de données. Cela tient principalement au fait que les utilisateurs ne peuvent, même avec la meilleure volonté du monde, exprimer tous leurs besoins.

De ce fait, il est fait appel à l’étude des rapports déjà demandés et des données disponibles a même de fournir des informations exploitables. L’étude des rapports offre un certain apport à notre démarche d’études des besoins, dans la mesure où les utilisateurs peuvent ne pas mentionner des besoins qui leur paraissent évidents ou qui ne leur viennent pas à l’esprit durant nos interviews, ces derniers peuvent être, en effet, influencés par nos questions.

L’étude des données, quant à elle, sert à détecter des besoins non déclarés et qui peuvent se faire sentir ultérieurement, le but de cette démarche étant de construire un entrepôt de données capable de répondre à ces éventuels nouveaux besoins.

Page 76: Conception et Réalisation d'un Data Warehouse

68

e. Rédaction et validation du recueil récapitulatif des besoins

L’étude des besoins nous a permis de recenser les besoins que nous avons classés par volets spécifiques. Ils peuvent être présentés de la manière suivante :

Volet Détecté Besoins enregistrés (Les critères d’analyse)

Suivi des ventes

Utilisateurs : Ce volet a été évoqué et solliciter à tous les niveaux et par différents postes. Cependant les utilisateurs des services Commerciaux et marketing, de la DCM et de la DFC ont exprimé un vif intérêt pour ce volet. Besoins : Les utilisateurs ont besoin de connaître l’évolution des ventes et des consommations dans le temps et selon différents critères à savoir : (Zone géographique, type d’abonnement, secteur d’activité)

Suivi des abonnés

Utilisateurs : Services commerciaux, DCM, utilisateurs de la DGDS. Besoins : ce volet contient les informations relatives à l’apport abonné (résiliations, nouveaux clients,…etc.), l’utilisateur devrait être en mesure de suivre l’évolution de ces chiffres selon différents critères d’analyse: (Zone géographique, temps, type abonnement, activités).

Suivi des affaires

Utilisateurs : Services commerciaux, DCM. Besoins : Avoir une vue d’ensemble de l’évolution des affaires et le suivi des taux et les délais de réalisations. L’utilisateur doit être en mesure de faire des analyses selon les critères : (Zone, Type de l’affaire, énergie, temps)

Suivi des recouvrements

Utilisateurs : Services commerciaux, DCM, DFC. Besoins :Disposer de la possibilité d’analyse par rapport à des axes bien déterminés, qui sont :(Zone, Type d’abonnée, client, énergie, temps)

Tableau II.4 : Synthétisation des besoins recensés.

Page 77: Conception et Réalisation d'un Data Warehouse

69

I.2 Problèmes et obstacles rencontrés

Bien que notre étude des besoins ait donné lieu aux résultats escomptés, à savoir leur identification et leur prise en charge, il n’empêche que le travail ne s’est pas effectué sans obstacles, dont les plus importants sont :

Difficulté de planifier les entretiens à cause de : - La charge de travail qui nous incombe,

- L’emploi du temps chargé des interviewés,

- L’organisation du groupe par filiale a limité notre libre circulation au sein du

groupe,

- Dispersion géographique des structures d’hébergement d’hébergent des

services et les personnes à interviewer,

• L’indisponibilité de personnes concernées par les entretiens et les annulations de

dernière minute,

• Les résistances au changement notamment au sein de quelques directions régionales,

• La rétention d’informations sous couvert de confidentialité,

• L’appréhension, par les utilisateurs, du projet et de sa faisabilité,

Page 78: Conception et Réalisation d'un Data Warehouse

70

II. Conclusion

L’étude des besoins est une étape plus que nécessaire dans un projet Data Warehouse. C’est, en effet, à partir de cette étude que se décidera la manière de construction de l’entrepôt de données et de son architecture.

Cette étude des besoins s’est déroulée sur vingt trois entretiens et a concerné quinze

personnes occupant différents postes à des niveaux hiérarchiques différents. L’ensemble des entretiens a duré plus de 33 heures et nous ont permis tout d’abord d’appliquer les méthodes d’analyse et de collecte d’information. Il nous a permis de connaître d’avantage de détails sur les rouages de l’entreprise et d’identifier les besoins analytiques de l’entreprise.

Les besoins étant recensés, la construction du Data Warehouse peut alors commencer. Cette construction fera l’objet du chapitre suivant.

Page 79: Conception et Réalisation d'un Data Warehouse

71

Chapitre IV : Conception de la solution

Page 80: Conception et Réalisation d'un Data Warehouse

72

Conception de la zone d’entreposage

Page 81: Conception et Réalisation d'un Data Warehouse

I. Introduction

Une fois les besoins des utilisateurs connus, volets de notre Data Warehouse. Pour cela, dimensionnelle qui est souvent associée aux entrepôts de données avantages.

Cependant, avant de se lancer dans la modélisation, il est intéressant de classer les sujets recensés selon l’intérêt réalisation. Ce classement nous aidera à choisir l’activité à modéliser en premiermanière à garantir des résultats satisfaisant

II. Processus de la modélisation dimensionnelle

La conception d’un modèle dimensionnel passe par cinq étapes essentielles

• Choix de l’activité à modéliserune matrice dite d’analyse des

connaître quelle activité choisir en premier.s’est fait en collaboration avec les décideurs et illustré dans la figure suivante

Figure II.10 : Analyse des priorités

• Définition de l’activité et de

• Définition des dimensions qui décrivent

• Définir les mesurables du fait,

• Définir les agrégats.

besoins des utilisateurs connus, nous pouvons commencer à concevoir les volets de notre Data Warehouse. Pour cela, nous avons eu recours à la modélisation dimensionnelle qui est souvent associée aux entrepôts de données compte tenu de ses

Cependant, avant de se lancer dans la modélisation, il est intéressant de classer les qu’ils représentent pour l’entreprise et les facilités de

réalisation. Ce classement nous aidera à choisir l’activité à modéliser en premiermanière à garantir des résultats satisfaisants pour l’entreprise.

Processus de la modélisation dimensionnelle

modèle dimensionnel passe par cinq étapes essentielles :

Choix de l’activité à modéliser : ce choix se fait après classement des activités dans ’analyse des priorités [Kimball, 2004]. Cette matrice permet de

choisir en premier. Le classement des sujets s’est fait en collaboration avec les décideurs et les techniciens de l’entreprise,illustré dans la figure suivante :

des priorités du cas « Distribution SONELGAZ

de son grain,

Définition des dimensions qui décrivent une ligne de la table de fait,

éfinir les mesurables du fait,

73

commencer à concevoir les à la modélisation

compte tenu de ses

Cependant, avant de se lancer dans la modélisation, il est intéressant de classer les s facilités de

réalisation. Ce classement nous aidera à choisir l’activité à modéliser en premier lieu de

:

classement des activités dans Cette matrice permet de

recensés, qui techniciens de l’entreprise, est

ONELGAZ ».

Page 82: Conception et Réalisation d'un Data Warehouse

74

II.1 Volet « Vente »

a) Présentation de l’activité « Vente »

« Une vente est la cession d’un bien ou d'un service en échange d'une somme d’argent

convenue entre le vendeur, celui qui cède le bien ou le service, et l'acheteur, celui qui paie »

[Larousse, 2008]. SONELGAZ, par le biais de ses quatre filiales, propose la vente d’énergie, (électricité ou

gaz), livré par canalisation jusqu’au lieu de consommation, dans le cadre d’un contrat de fourniture.

La vente d’énergie, électrique ou gazière, demeure comme l’activité principale des filiales de distribution du groupe SONELGAZ, réalisant la plus grande partie du chiffre d’affaire du groupe. Les chiffres liés aux ventes se présentent comme des indicateurs d’une grande signification par rapport à la performance du groupe. Ainsi la disponibilité de ces informations s’avère indispensable pour les décideurs de l’entreprise.

b) Grain de l’activité

Le choix du grain le plus fin donne un maximum de flexibilité. Dans le cas des ventes le grain le plus fin, ou le niveau de détail le plus bas, correspond à une opération de facturation12, d’où une ligne de table de fait correspondant à :

Suivi de la quantité et du montant de la vente d’une énergie par tarif à un client

activant dans un certain domaine à une date donnée.

12

Ce n’est qu’après facturation que la quantité et le montant consommé sont arrêtés, d’où la vente.

Page 83: Conception et Réalisation d'un Data Warehouse

c) Les dimensions participantes du modèleLes dimensions ont pour objectif de décrire le fait, donc on essaye de recens

informations qui décrivent une

1. Dimension TempsLa dimension temps est

entrepôt de données, car en pratique tout entrepôt de données est une série temporelle. Le temps est le plus souvent la première dimension dans le classement sous jacent de la base de données » [Kimball, 2001].

La dimension temps se présente com

Figure II. 11

Le niveau de détail le plus bas de cette dimension est la journée. En effet, les utilisateurs

ont fait ressortir le besoin de suivre les chiffres au jour le jour et dces derniers.

Dans cette dimension, il est artificielle sert à faciliter la manipulation de la dimension. Le tableau suivantdétails sur cette dimension :

sions participantes du modèle dimensions ont pour objectif de décrire le fait, donc on essaye de recens

formations qui décrivent une vente et qui peuvent intéresser les décideurs.

Dimension Temps La dimension temps est « la seule dimension qui figure systématiquement

entrepôt de données, car en pratique tout entrepôt de données est une série temporelle. Le temps est le plus souvent la première dimension dans le classement sous jacent de la base de

La dimension temps se présente comme suit :

11 : La Dimension Temps de l’activité « Vente

le plus bas de cette dimension est la journée. En effet, les utilisateurs fait ressortir le besoin de suivre les chiffres au jour le jour et d’en garder

il est utilisé une clé artificielle comme clé primairla manipulation de la dimension. Le tableau suivant

75

dimensions ont pour objectif de décrire le fait, donc on essaye de recenser toutes les vente et qui peuvent intéresser les décideurs.

la seule dimension qui figure systématiquement dans tout entrepôt de données, car en pratique tout entrepôt de données est une série temporelle. Le temps est le plus souvent la première dimension dans le classement sous jacent de la base de

».

le plus bas de cette dimension est la journée. En effet, les utilisateurs garder l’historique de

comme clé primaire. Cette clé la manipulation de la dimension. Le tableau suivant donne plus de

Page 84: Conception et Réalisation d'un Data Warehouse

76

Désignation Détails Code_temps Date Jour Jour_semaine Mois Mois_annee Annee_mois Semaine_dans_annee Annee Trimestre Trimestre_annee Saison Evénement

Clé artificielle de la dimension temps. La date au format complet. Position du Jour dans le mois. Nom des jours de la semaine. Nom du mois. Numéro du mois dans l’année. Année et mois (concaténation). Numéro de la semaine dans l’année. Année de la date. Trimestre de la date. Trimestre et année (concaténation). Saison à la quelle appartient une date. Evénement survenu lors de cette date.

Tableau II.5 : Tableau descriptif de la dimension « Temps ».

Page 85: Conception et Réalisation d'un Data Warehouse

2. Dimension client Le client s’impose comme un élément important dans l’analyse

analystes et les décideurs de l’entreprise. Outre ce qu’il représente dans une opération de vente, l’analyse du comportement du client peut aider l’entreprise à mieux

Figure II. 12

La dimension client décrit un client, l’acheteur. Un client est référencié par son lieu de consommation, c'est-à-dire quatre clients qui ont habité le même lieu, sont considérés comme un seul client. Pour permettre la traçabilité et le suivi d’un client on a artificielle. Celle-ci aide à pallier à l’insuffisance de la codification en pour une finalité décisionnelle

Le client s’impose comme un élément important dans l’analyse

analystes et les décideurs de l’entreprise. Outre ce qu’il représente dans une opération de analyse du comportement du client peut aider l’entreprise à mieux

12 : La Dimension Client de l’activité «

dimension client décrit un client, l’acheteur. Un client est référencié par son lieu de dire quatre clients qui ont habité le même lieu, sont considérés comme

un seul client. Pour permettre la traçabilité et le suivi d’un client on a aide à pallier à l’insuffisance de la codification en vigueur, notamment

le. Les caractéristiques qui décrivent un client sont:

77

Le client s’impose comme un élément important dans l’analyse, et intéresse les analystes et les décideurs de l’entreprise. Outre ce qu’il représente dans une opération de

analyse du comportement du client peut aider l’entreprise à mieux le satisfaire.

imension Client de l’activité « Vente ».

dimension client décrit un client, l’acheteur. Un client est référencié par son lieu de dire quatre clients qui ont habité le même lieu, sont considérés comme

un seul client. Pour permettre la traçabilité et le suivi d’un client on a introduit une clé vigueur, notamment

. Les caractéristiques qui décrivent un client sont:

Page 86: Conception et Réalisation d'un Data Warehouse

78

Désignation Détails Code_client Reference Numero_client Nom_client Adresse_client Code_postal Commune Agence Direction_regionale Wilaya Filiale Secteur_activite Debit_gaz Debit_electricite Type Groupe Tournee

Clé artificielle La référence du lieu de consommation Le numéro affecté à un client FSM 13(ce champ est utilisé si le client est un abonné FSM) Le nom du client. Adresse du client. Code postal du lieu de consommation. Commune du lieu de consommation. Agence à laquelle le lieu de consommation est affilié. La direction régionale où le lieu de consommation est affilié. La wilaya du lieu de consommation. La filiale à laquelle le lieu de consommation est affilié. Secteur d’activité du client dans le lieu de consommation. Débit gaz installé sur le lieu de consommation. Débit électricité installé sur le lieu de consommation. Type du client (ordinaire ou FSM). Le groupe de facturation du client (Chaque client appartient à un groupe de facturation. Il existe 60 groupes de facturation). La tournée de relève à laquelle appartient le client.

Tableau II.6 : Tableau descriptif de la dimension « Client ».

13

FSM : Facturation sur mémoire.

Page 87: Conception et Réalisation d'un Data Warehouse

3. Dimension factureUne facture est un document relatif au fait de vente. Cette dernière contient un certain

nombre d’informations intéressantes pour une analyse. Elle décrit les différentes caractéristiques d’une facture, et qui caractérisent aussi une vente.

Figure II.13 :

La facture est identifiée

présent, à la facture en cas d’annulation. Lchamp type facture. On pourrait dans ce cas penser àCependant une telle clé nuirait fortement aux performances souci de performance, on a introduit une clé artificiplus justifiable que la dimension est une dimension à évolution rapide.caractérisée par :

Dimension facture document relatif au fait de vente. Cette dernière contient un certain

nombre d’informations intéressantes pour une analyse. Elle décrit les différentes caractéristiques d’une facture, et qui caractérisent aussi une vente.

La Dimension Facture de l’activité « Vente

par un numéro facture. Ce même numéro est affectéla facture en cas d’annulation. La différence entre les deux se fait

champ type facture. On pourrait dans ce cas penser à l’adoption d’une clé primaire composée. nuirait fortement aux performances du système. Pour cela, et dans un

souci de performance, on a introduit une clé artificielle à cette table. Ce choix est d’autant plus justifiable que la dimension est une dimension à évolution rapide.

79

document relatif au fait de vente. Cette dernière contient un certain nombre d’informations intéressantes pour une analyse. Elle décrit les différentes

Vente ».

par un numéro facture. Ce même numéro est affecté, dans le cas ifférence entre les deux se fait alors grâce au

l’adoption d’une clé primaire composée. . Pour cela, et dans un

elle à cette table. Ce choix est d’autant plus justifiable que la dimension est une dimension à évolution rapide. La facture est

Page 88: Conception et Réalisation d'un Data Warehouse

80

Désignation Détails Numero_facture Numero_facture_SGC Date_facture Cycle Type Type_releve Montant_HT Montant_TTC Taxe_habitation Montant_timbre Montant_TVA Droit_fixes Soutient_etat

Clé artificielle Le numéro facture dans le système source. Date de la facturation. Cycle d’émission de la facture. Type de la facture (Emission ou Annulation). Type de la relève (les relèves d’index se font de différentes manières). Montant hors taxe. Montant toutes taxes comprises. Taxe habitation. Montant du timbre. Montant TVA. Montant droit fixes. Montant du soutient de l’état (les wilayas du sud).

Tableau II.7 : Tableau descriptif de la dimension « Facture ».

Page 89: Conception et Réalisation d'un Data Warehouse

4. Dimension zone géographiqueLa dimension zone géographique

besoins au sein du groupe, il parait zones géographiques. Le grain le plus basdernières sont susceptibles d’évolution dans le temps (appartenance a une filiale ou une wilaya). On jugé donc nécessairel’évolution de la dimension et

Figure II.14 : La D

Les caractéristiques de la dimension «

tableau suivant :

Dimension zone géographique géographique décrit la zone où le fait a eu lieu. Après l’étude des

besoins au sein du groupe, il parait intéressant de faire des comparaisons par rapport à des zones géographiques. Le grain le plus bas de cette dimension correspond aux

d’évolution dans le temps (appartenance a une filiale ou une nécessaire d’introduire une clé artificielle pour permettre le suivi de

et d’assurer la cohérence des données.

Dimension Zone géographique de l’activité «

de la dimension « Zone géographique » sont explicitées dans le

81

le fait a eu lieu. Après l’étude des intéressant de faire des comparaisons par rapport à des

de cette dimension correspond aux communes. Ces d’évolution dans le temps (appartenance a une filiale ou une

une clé artificielle pour permettre le suivi de

Vente ».

» sont explicitées dans le

Page 90: Conception et Réalisation d'un Data Warehouse

82

Désignation Détails Code_zone Code_commune Nom_commune Code_agence Nom_agence Adresse_agence Tel_agence Code_dd Nom_dd Adresse_dd Tel_dd Code_wilaya Nom_wilaya Code_filiale Adresse_filiale Tel_filiale

Clé artificielle. Code de la commune. Nom de la commune. Code de l’agence (une agence regroupe plusieurs communes). Nom de l’agence. Adresse de l’agence. Téléphone de l’agence. Code de la direction de distribution. Nom de la direction de distribution. Adresse de la direction de distribution. Téléphone de la direction de distribution. Code de la wilaya. Nom de la wilaya. Code de la filiale de distribution (il y a quatre filiales). Adresse de la filiale de distribution. Téléphone de la filiale de distribution.

Tableau II.8 : Tableau descriptif de la dimension « Zone géographique ».

Page 91: Conception et Réalisation d'un Data Warehouse

5. Dimension activité

Figure II.15 :

Cette dimension décrit les chargée à partir d’un tableau transmit par le ministère des finances, que beaucoup d’analyses observée

Désignation Code_activité Libellé_activité

Tableau II.9 :

6. Dimension tarif

Figure II. 16

Souvent, des analyses sont faitetarification est affectée de manière étudiée selon le type du client.cette dimension contient : Désignation Code_tarif Abreviation_tarif Description_tarif

Tableau II.10

Dimension activité

La Dimension Activité de l’activité « Vente

Cette dimension décrit les différents secteurs d’activités économiques.chargée à partir d’un tableau transmit par le ministère des finances, et très importante, dès lors

observées pendant l’étude des besoins, se base sur cette dimension.

Détails Le code de l’activité. Libellé de l’activité.

: Tableau descriptif de la dimension « Activité

16 : La Dimension Tarif de l’activité « Vente ».

des analyses sont faites par rapport aux tarifs affectéstarification est affectée de manière étudiée selon le type du client. En plus du

Détails Le code tarif qui est appliqué actuellement. Abréviation du tarif telle qu’utilisée dans l’entreprise et codifiée sur les documents officiels. Une description sommaire du tarif.

10 : Tableau descriptif de la dimension « Tarif ».

83

Vente ».

s économiques. Celle-ci est très importante, dès lors

pendant l’étude des besoins, se base sur cette dimension.

Activité ».

».

par rapport aux tarifs affectés au client. Cette En plus du « code_tarif »,

code tarif qui est appliqué actuellement.

dans l’entreprise et

Tarif ».

Page 92: Conception et Réalisation d'un Data Warehouse

7. Dimension énergie

Figure II. 17

Les filiales de distribution de SONELGAZ livrent plusieurs types d’énergiedifférent par un certain nombre de caractéristiquescaractéristique ou à une autre est trèspar les caractéristiques suivantes

Désignation Code_energie Type_energie Debit Unite_mesure

Tableau II.11

8. Dimension dégénéré

Les clés étrangères de la table de fait référencent les dimensions qui représentent le contexte du fait. Cependant il existe des clés ne référençant aucune sont dites dimensions dégénérées.

La dimension puissance maxdimension. En effet, celle-ci assimilée à aucune autre dimension. Ellefournie grâce à ce dernier la possibilité d’analyser les vendemandée par le client.

Dimension énergie

17 : La Dimension énergie de l’activité « Vente

filiales de distribution de SONELGAZ livrent plusieurs types d’énergiedifférent par un certain nombre de caractéristiques. Avoir une segmentation par rapport à une

une autre est très intéressant lors d’une analyse. Une énergie est décrite par les caractéristiques suivantes :

Détails Code énergie débit/type Type de l’énergie Débit Unité de mesure de l’énergie

11 : Tableau descriptif de la dimension « Energie».

Dimension dégénérée « Puissance maximale »

Les clés étrangères de la table de fait référencent les dimensions qui représentent le contexte du fait. Cependant il existe des clés ne référençant aucune dimension, ces dernières sont dites dimensions dégénérées.

La dimension puissance maximale est dans ce cas un exemple de ce type de ne contient aucune description textuelle et elle ne peut être

dimension. Elle est identifiée par sa valeur dans la tadernier la possibilité d’analyser les ventes selon la puissance maximale

84

Vente ».

filiales de distribution de SONELGAZ livrent plusieurs types d’énergie qui voir une segmentation par rapport à une

ne énergie est décrite

Energie».

Les clés étrangères de la table de fait référencent les dimensions qui représentent le dimension, ces dernières

st dans ce cas un exemple de ce type de et elle ne peut être

dans la table des faits et tes selon la puissance maximale

Page 93: Conception et Réalisation d'un Data Warehouse

85

d) Les mesurables

Les mesurables qui correspondent à l’activité des ventes et qui permettent de mesurer les performances de cette activité, sont la « quantité vendue » et le« montant de la vente en hors taxe » et les « primes fixes ».

Page 94: Conception et Réalisation d'un Data Warehouse

86

e) Le modèle en étoile de l’activité « Vente »

Figure II.18 : Modèle en étoile de l’activité « Vente ».

Page 95: Conception et Réalisation d'un Data Warehouse

87

f) Les agrégats Les tables d’agrégats améliorent les performances du Data Warehouse, en réduisant le

nombre de lignes que le SGBD manipule afin de répondre à une requête. Cela se fait grâce à l’agrégation des données contenues dans les tables de faits détaillées et qui sont stockées dans de nouvelles tables de faits.

La construction des agrégats se base sur le modèle en étoile détaillée, et elle peut nécessiter:

• La création de nouvelles dimensions dérivées : la construction d’un modèle agrégé

nécessitera la suppression de quelques attributs d’une dimension qui désigne le grain le plus fin.

• La suppression de quelques dimensions : le modèle agrégé peut engendrer l’élimination de certaines dimensions qui n’apparaissent pas au niveau de détail voulu.

On peut aussi :

• Créer de nouveaux faits: lors de la création de la table de faits agrégée on peut rajouter quelques faits qui n’existaient pas dans la modèle de base. En effet, l’usage et la signification des tables agrégées peuvent différer du modèle de base.

• Créer des tables pré-jointes : une table d’agrégat peut être construite à partir d’une jointure entre la table de faits et une ou plusieurs dimensions. Le résultat est stocké dans une seule table dite pré-jointure.

Une table d’agrégat peut être invisible ou visible à l’utilisateur final :

• Elle est invisible lorsqu’elle reflète exactement le modèle de base

• Elle est visible lorsqu’elle contient des faits supplémentaires.

Les résultats issus d’une table agrégée ou du modèle de base doivent être identique. Pour cette phase, on s’inspire de la démarche décrite par C. Adamson dans son livre

« Mastering the Data Warehouse Aggregates, Solution for Star Schema Performance ». La démarche consiste à :

1- Enumérer les agrégats potentiels à partir d’une étoile détaillée : pour détecter les

agrégats potentiels et choisir ceux à implémenter dans le Data Warehouse. Il est nécessaire de bien décrire chaque agrégat.

2- Détecter les agrégats utiles : choisir des agrégats utiles à partir des agrégats potentiels.

3- Construire le modèle agrégé : enfin on construit le modèle agrégé tout en prenant en considération les dimensions dérivées commune entre les différents modèles.

Les agrégats sont conçus, en général, comme des modèles dimensionnels.

Page 96: Conception et Réalisation d'un Data Warehouse

88

1) Les agrégats potentiels

Le tableau suivant décrit, d’une manière simple et efficace, les agrégats potentiels du modèle dimensionnel de base de l’activité des ventes:

Dimension Agrégats potentiels Nombre

d’agrégats possibles

Temps Mois, trimestre, année, saison 4 Energie Type, débit 3 Activité Code activité 1 Tarif Tarif 1 Zone Tournée, agence, commune, DR, wilaya, filiale 6 Facture Date, cycle, type, relève 4

Client Numéro, commune, agence, DR, wilaya, filiale, activité, débit gaz, débit électricité, type

10

Tableau II.12 : Liste des agrégats potentiels pour l’activité « Vente ».

2) Les agrégats utiles :

Les agrégats potentiels ne sont pas en effet tous utiles, soit par le nombre de lignes agrégées ou par les informations fournies. Pour cela on réduit la liste des agrégats à ce qui suit :

Dimension Agrégats utiles Nombre d’agrégats retenus

Temps Mois, trimestre, année, saison 4 Energie Type, débit 3 Activité Code activité 1 Tarif Tarif 1 Zone Commune, agence, DR, wilaya, filiale 5 Facture Cycle, type, relève 4

Tableau II.13 : Liste des agrégats utiles de l’activité « Vente ».

A partir du tableau précédent nous choisissons les agrégats qui nous semblent les plus

pertinents et susceptibles de faire l’objet d’accès fréquents. nous arrêtons la liste des modèles agrégats suivants :

• Ventes journalières par type d’énergie par activité par commune.

• Ventes mensuelles par DR (agrégation de plus de dix mille lignes).

• Ventes mensuelles par cycle par type de relève (agrégation de plus de trois

millions lignes).

La modélisation des agrégats se fait grâce aux principes de la modélisation dimensionnelle.

Page 97: Conception et Réalisation d'un Data Warehouse

89

II.2 Volet « Recouvrement »

a) Présentation de l’activité « Recouvrement »

« Action de recouvrer, de retrouver ce qui était perdu, des sommes dues ». [Larousse, 2008]

Une suite logique au fait de vente, c’est le recouvrement des sommes dues aux clients. Une somme peut passer par plusieurs phases ou états : facturée, impayée, payée, prés-contentieux, contentieux et apurée. Cette terminologie obéit à un jargon au sein de l’organisation pour définir une créance ou un avoir.

Ces états correspondent aux différents comptes de recouvrement. Le mouvement d’un compte à l’autre se fait par rapport aux délais de recouvrement. L’entreprise s’intéresse au suivi de l’état journalier de ces comptes afin de suivre de près cette activité très importante.

b) Grain de l’activité :

Le grain le plus fin de l’activité correspond à :

Suivi du montant et de l’état d’une facture d’un client appartenant à une zone géographique et activant dans un certain domaine à une date donnée

c) Les dimensions participantes du modèle

Les dimensions communes Après la détection des dimensions de la nouvelle étoile, on procède à une mise en

conformité des dimensions communes. Pour ce faire, on construit un tableau qui croise les étoiles conçues avec leurs dimensions. Le but étant de détecter les dimensions communes pour leurs mises en conformité. Le tableau suivant illustre cela :

Etoile Vente Recouvrement

Dimensions

Client √ √ Zone géographique √ √ Temps √ √ Facture √ √ Activité √ √ Nature √

Tableau II.14 : Détection des dimensions communes entre les volets « Vente » et

« Recouvrement ».

A cette étape il existe quatre dimensions communes. Ces dimensions étant très détaillées dans la première étoile, il n’y a pas eu nécessité de recourir à une mise en conformité. Cette remarque reste valable pour l’ensemble du document, ainsi il n’y a pas lieu de détailler les dimensions communes à la présentation de chaque étoile.

Page 98: Conception et Réalisation d'un Data Warehouse

1. Dimension nature

Figure II.19 : La

La dimension « natureprécisément le compte dont il est comptabilisé à un moment donné.informations listées dans le tableau suivant

Désignation Code_nature Libelle Operation

Tableau II.15

d) Les mesurables

Le mesurable qui correspond à l’activité les performances de cette activité, est le «comprises ».

Dimension nature

La Dimension nature de l’activité « Recouvrement

nature » décrit la nature du montant contenu dans leprécisément le compte dont il est comptabilisé à un moment donné. La dimension contient les informations listées dans le tableau suivant :

Détails Clé artificielle Libellé de la nature du montant Libellé de l’opération relative au montant

15 : Tableau descriptif de la dimension « Nature ».

Le mesurable qui correspond à l’activité « recouvrement » et qui permet de mesurer les performances de cette activité, est le « montant de l’opération en tout

90

Recouvrement ».

contenu dans le fait, ou plus La dimension contient les

de l’opération relative au montant

Nature ».

et qui permet de mesurer montant de l’opération en toutes taxes

Page 99: Conception et Réalisation d'un Data Warehouse

91

e) Le modèle en étoile de l’activité « Recouvrement »

Figure II.20 : Modèle en étoile de l’activité « Recouvrement ».

Page 100: Conception et Réalisation d'un Data Warehouse

92

f) Les agrégats 1) Les agrégats potentiels

Dimension Agrégats potentiels Nombre

d’agrégats possibles

Temps Mois, trimestre, année, saison 4 Nature Opération, nature 2 Activité Code activité 1 Zone Tournée, agence, commune, DR, wilaya, filiale 6 Facture Date, cycle, type, relève 4

Client Numéro, commune, agence, DR, wilaya, filiale, activité, débit gaz, débit électricité, type

10

Tableau II.16 : Tableau descriptif des agrégats potentiels du modèle

« Recouvrement ». 2) Les agrégats utiles

Dimension Agrégats utiles Nombre d’agrégats possibles Temps Mois, trimestre, année, saison 4 Activité Code activité 1 Zone Commune, agence, DR, wilaya, filiale 5 Facture Cycle, type, relève 4

Tableau II.17 : Tableau descriptif des agrégats utiles du modèle « Recouvrement ».

Nous arrêtons la liste des agrégats suivants :

• Montant et nombre des factures des comptes de recouvrement journalier.

par nature par activité par commune.

• Montant et nombre de facture mensuel par opération par commune.

• Montant et nombre de facture par nature par type client.

Page 101: Conception et Réalisation d'un Data Warehouse

93

II.3 Volet « Suivi des affaires »

a) Présentation de l’activité « Suivi des affaires »

Une affaire est une demande initiée soit par la clientèle ou par l’agence et qui nécessite une mise à jour de la base de données. Cet événement se traduit par l’enregistrement d’une affaire qui sera suivie jusqu’à son aboutissement.

Parmi les modules du « SGC », le module « Gestion des Affaires » gère les affaires liées a la « Basse Moyenne Pression, Basse Moyenne Tension » depuis leurs enregistrements jusqu'à leurs réalisations. Ce module génère chaque jour, et au niveau de chaque direction de distribution, une masse de données considérable. Ces données représentent une source d’information plus qu’indispensables pour le groupe et ses filiales de distribution. D’où la nécessité de suivre cette activité.

b) Grain de l’activité

Le grain le plus fin de l’activité suivi des affaires représente, en réalité, la possibilité de suivre une affaire selon des critères différents. Le grain peut alors être donné comme suit :

Suivi dans le temps, et selon leur type, les affaires qui concerne un client selon son activité et qui sont initiées au niveau de chaque commune.

c) Les dimensions participantes

Les dimensions communes

D’après le grain de l’activité on peut déjà savoir les dimensions qui seront présentes dans notre étoile et qui sont listées dans le tableau. Ces dimensions sont indispensables pour répondre au grain de l’activité. Aussi, et afin d’offrir un suivi plus complet et plus aisé, on a jugé nécessaire d’introduire la «Dimension phase affaire ».

Etoile Vente Recouvrement Suivi des affaires

Dimension

Client √ √ √ Zone géographique √ √ √

Temps √ √ √ Facture √ √ √ Activité √ √ √ Affaire √

Type affaire √ Phase √

Tableau II.18 : Détection des dimensions communes entre les volets « Vente »,

« Recouvrement » et « Suivi des affaires ».

Page 102: Conception et Réalisation d'un Data Warehouse

1. Dimension affaire

La dimension affaire est une dimension indispensable pour faire une bonne analyse dans cette étoile. En effet, afin de bien suivre une affaire d’information la concernant. Cette dimension décrit donc une affaire qui est identifiée par son numéro « le numéro de l’affaire est unique au niveau nationaldegré d’urgence et son initiateur

Figure II.21 : La D

Cette dimension est une dimensid’affaires initiées quotidiennement par agencesuivantes :

Désignation Numero_affaire Degre_urgence Observation Initier_par

Tableau II.19

t une dimension indispensable pour faire une bonne analyse dans cette étoile. En effet, afin de bien suivre une affaire nous avons besoin du maximum d’information la concernant. Cette dimension décrit donc une affaire qui est identifiée par son

le numéro de l’affaire est unique au niveau national » et qui est caractérisée par son itiateur.

Dimension affaire de l’activité « Suivi des affaires

Cette dimension est une dimension à évolution rapide. Cela se vérifie

quotidiennement par agence. Cette dimension fournie les informations

Détails Un numéro d’ordre donné par le système et qui évolue à chaque enregistrement. Représente le degré d’urgence de l’affaire. Certainesont plus urgentes que d’autres. Observation relative à l’affaire. Permet de connaitre l’initiateur de l’affaire (agence, client, DD).

19 : Tableau descriptif de la dimension « Affaire ».

94

t une dimension indispensable pour faire une bonne analyse dans besoin du maximum

d’information la concernant. Cette dimension décrit donc une affaire qui est identifiée par son » et qui est caractérisée par son

uivi des affaires ».

on à évolution rapide. Cela se vérifie par le nombre Cette dimension fournie les informations

Un numéro d’ordre donné par le système et qui évolue à

Représente le degré d’urgence de l’affaire. Certaines affaires

de l’affaire (agence, client,

Affaire ».

Page 103: Conception et Réalisation d'un Data Warehouse

2. Dimension type affaire

Cette dimension nous renseigne sur le type de l’affaire. Ld’après la nature de l’affaire, ensuite en sous catégories d’après l’énergie concernée. En plus de l’appartenance d’une affaire à une catégorie, cette dimension nous renseigne sur d’autres caractéristiques à savoir l’énergie de l’affaire et

Figure II.22 : La Dimension type affaire

La dimension est une dimension peu fréquent. Le détail de cette dimension est Désignation Code_affaire Intitule_affaire Code_categorie Intitule_categorie Code_ss_categorie Intitule_ss_categorie Duree_aproximative

Tableau II.20 :

igne sur le type de l’affaire. Les types sont classés en catégories d’après la nature de l’affaire, ensuite en sous catégories d’après l’énergie concernée. En plus de l’appartenance d’une affaire à une catégorie, cette dimension nous renseigne sur d’autres

nergie de l’affaire et sa durée approximative.

imension type affaire de l’activité « Suivi des affaires

La dimension est une dimension à évolution lente. En effet, l’ajout d’une catégorie est

Le détail de cette dimension est le suivant :

Détails Code de l’affaire tel qu’il est connu au sein du groupe. Intitulé du type de l’affaire. Le code de la catégorie à laquelle appartient un type d’affaires. L’intitulé de la catégorie à laquelle appartient un type d’affaires. Code de la sous catégorie. Chaque catégorie est divisésous catégories. Intitulé de la sous catégorie. Une approximation en jours de la durée de l’affaire.

: Tableau descriptif de la dimension « Type affaire».

95

es types sont classés en catégories d’après la nature de l’affaire, ensuite en sous catégories d’après l’énergie concernée. En plus de l’appartenance d’une affaire à une catégorie, cette dimension nous renseigne sur d’autres

a durée approximative.

uivi des affaires ».

à évolution lente. En effet, l’ajout d’une catégorie est

Code de l’affaire tel qu’il est connu au sein du groupe.

quelle appartient un type

quelle appartient un type

Code de la sous catégorie. Chaque catégorie est divisée en

Une approximation en jours de la durée de l’affaire.

Type affaire».

Page 104: Conception et Réalisation d'un Data Warehouse

3. Dimension phase

Chaque affaire transite, durant son cycle de vie, par un certain nombre de phases. Ceont été normalisées et codifiéepar toutes les affaires. La dimension phase reprend donc la codification utilisée par le « SGC » pour identifier ces phases. L’utilisation d’une telle dimension facilite grandement lacompréhension du modèle dimensionnel et conférera une certaine aisance d’implémentation et de gestion de l’alimentation de l’étoile.

Figure II.23 : La

Le tableau suivant donne le détail de cette dimension Désignation Code_phase Intitule_phase Description_phase

Tableau II.21

d) Les faits mesurés

Cette étoile n’a pas de mesurablesappelée une « Table de faits sans faitset l’évolution des affaires dans le temps.

Chaque affaire transite, durant son cycle de vie, par un certain nombre de phases. Cees de manière à ce qu’elles puissent être utilisées conjointement

toutes les affaires. La dimension phase reprend donc la codification utilisée par le » pour identifier ces phases. L’utilisation d’une telle dimension facilite grandement la

compréhension du modèle dimensionnel et conférera une certaine aisance d’implémentation et de gestion de l’alimentation de l’étoile.

La Dimension phase de l’activité « Suivi des affaires

Le tableau suivant donne le détail de cette dimension :

Détails Code des phases par lesquelles transitent Intitulé de chaque phase. Description textuelle de chaque phase.

21 : Tableau descriptif de la dimension « Phase».

pas de mesurables a proprement parlé. La table de faitTable de faits sans faits ». Ce genre de table permet de renseigner sur le nombre

et l’évolution des affaires dans le temps.

96

Chaque affaire transite, durant son cycle de vie, par un certain nombre de phases. Celles-ci ssent être utilisées conjointement

toutes les affaires. La dimension phase reprend donc la codification utilisée par le » pour identifier ces phases. L’utilisation d’une telle dimension facilite grandement la

compréhension du modèle dimensionnel et conférera une certaine aisance d’implémentation

uivi des affaires ».

nt les affaires.

Phase».

La table de faits dans ce cas est ». Ce genre de table permet de renseigner sur le nombre

Page 105: Conception et Réalisation d'un Data Warehouse

97

e) Modèle en étoile de l’activité « suivi des affaires »

Figure II.24 : Modèle en étoile de l’activité « Suivi des affaires ».

Page 106: Conception et Réalisation d'un Data Warehouse

98

f) Les agrégats 1) Les agrégats potentiels

Dimension Agrégats potentiels Nombre

d’agrégats possibles

Temps Mois, trimestre, année, saison 4 Activité Code activité 1 Zone Tournée, agence, commune, DR, wilaya, filiale 6

Client Numéro, commune, agence, DR, wilaya, filiale, activité, débit gaz, débit électricité, type

10

Type affaire Code catégorie, code sous catégorie 2 Tableau II.22 : Tableau descriptif des agrégats potentiels du modèle « Suivi des

affaires ».

2) Les agrégats utiles

Dimension Agrégats utiles Nombre d’agrégats possible Temps Mois, trimestre, année, saison 4 Activité Code activité 1 Zone Commune, agence, DR, wilaya, filiale 6 Type affaire Code catégorie, code sous catégorie 2

Tableau II.23 : Tableau descriptif des agrégats utiles du modèle « Suivi des affaires ».

On va arrêter la liste des agrégats suivants :

• Nombre et durée des affaires par commune.

• Nombre et durée des affaires par secteur d’activité.

Page 107: Conception et Réalisation d'un Data Warehouse

99

II.4 Volet « Suivi des abonnés »

a) Présentation de l’activité « Suivi des abonné »

Un abonnement électrique (ou gazier) est une contrepartie aux services qui sont rendus par le gestionnaire du réseau public de distribution. Principalement l’acheminement de l’électricité, et du gaz de la centrale au lieu de consommation de l’abonné.

L’abonné est la partie bénéficiaire du service, en contrepartie il doit honorer ses engagements relatifs au contrat d’abonnement.

Lors de notre étude des besoins, un des sujets auquel s’intéressent les décideurs est le suivi des abonnés : abonnement, mise en service, résiliation…. En effet, le nombre d’abonnés se présente comme un des indicateurs de performances de l’entreprise, d’où l’intérêt de suivre la réalisation des objectifs tracés.

b) Grain de l’activité :

Le grain le plus fin de l’activité correspond à :

L’historique complet d’un abonné par type, zone géographique et par activité.

c) Les dimensions participantes du modèle : 1. Les dimensions communes

Le tableau suivant nous donne la liste des dimensions communes entre toutes les étoiles :

Etoile Vente Recouvrement Suivi des

abonnés Suivi des abonnés Dimension

Client √ √ √ √ Zone géographique

√ √ √ √

Temps √ √ √ √ Activité √ √ √ √ Type abonné √ √

Tableau II.24 : Détection des dimensions communes entre les volets « Vente »,

« Recouvrement », « Suivi des affaires » et « Suivi des abonnés ».

Page 108: Conception et Réalisation d'un Data Warehouse

2. Dimension type abonné

La dimension type abonné contient une description d’un abonné parpaiement (domicilié ou non domicilié

Figure II.25 : la Dimension T

Désignation Code_type_abonne Type_paiement Type_ lieu

Tableau II.25 :

d) Les mesurables

Dans ce cas on se retrouve avec une table de faits tracer l’historique d’un abonné du jour de son abonnement à son éventuel

Dimension type abonné

La dimension type abonné contient une description d’un abonné parpaiement (domicilié ou non domicilié) et par rapport au type du lieu de consommation.

la Dimension Type abonné de l’activité « Suivi des abonné

Détails Clé artificielle du type abonné Type abonné selon ses paiements Type abonné selon le lieu de consommation

: Tableau descriptif de la dimension « Type abonné ».

Dans ce cas on se retrouve avec une table de faits sans faits. Cette tabletracer l’historique d’un abonné du jour de son abonnement à son éventuelle

100

La dimension type abonné contient une description d’un abonné par le type de ) et par rapport au type du lieu de consommation.

Suivi des abonnés ».

Type abonné selon le lieu de consommation

Tableau descriptif de la dimension « Type abonné ».

sans faits. Cette table a pour objectifs de le résiliation.

Page 109: Conception et Réalisation d'un Data Warehouse

101

e) Le modèle en étoile de l’activité « Suivi des abonnés »

Figure II.26 : Modèle en étoile de l’activité « Suivi des abonnés ».

Page 110: Conception et Réalisation d'un Data Warehouse

102

f) Les agrégats

1. Les agrégats potentiels

Dimension Agrégats potentiels Nombre

d’agrégats possibles

Temps Mois, trimestre, année, saison 4 Type abonné Lieu, paiement 2 Activité Code activité 1 Zone Tournée, agence, commune, DR, wilaya, filiale 6

Client Numéro, commune, agence, DR, wilaya, filiale, activité, débit gaz, débit électricité, type

10

Tableau II.26 : Tableau descriptif des agrégats potentiels du modèle « suivi abonnés ».

2. Les agrégats utiles

Dimension Agrégats utiles Nombre d’agrégats possibles Temps Mois, trimestre, année, saison 4 Activité Code activité 1 Zone Commune, agence, DR, wilaya, filiale 6 Type abonné Lieu, paiement 2

Tableau II.27 : Tableau descriptif des agrégats utiles du modèle « suivi abonnés ».

On va arrêter la liste des agrégats suivants :

• Nombre d’abonnements par commune par jour.

• Nombre de résiliations par commune par jour.

• Nombre de mises en service par commune par jour.

Page 111: Conception et Réalisation d'un Data Warehouse

103

III. Conclusion

La zone d’entreposage constitue la zone exploitable par les utilisateurs. La modélisation de cette zone se fait grâce à la modélisation dimensionnelle. Cette manière de représenter les données offre aux utilisateurs des modèles intuitifs et compréhensibles permettant de naviguer et de manipuler les données, détaillées ou agrégées, sans difficulté afin de satisfaire leurs besoins en analyse.

La finalisation de la conception d’une étoile de l’entrepôt, nous permet de passer à la construction de la zone d’alimentation. Cette zone d’alimentation constitue l’objet du prochain chapitre.

Page 112: Conception et Réalisation d'un Data Warehouse

104

Conception de la zone « alimentation »

Page 113: Conception et Réalisation d'un Data Warehouse

105

I. Introduction

L’ETL, ou l’alimentation du Data Warehouse, est une étape des plus importantes dans un projet Data Warehouse, elle représente 80% de la charge de travail. Cette étape a pour objectif d’assurer l’acheminement des données des systèmes sources jusqu’à l’entrepôt de données, en passant par les différentes phases de nettoyage et de transformations nécessaires.

La conception du processus d’alimentation nécessite les étapes suivantes : • Etude et planification,

• Choix de l’architecture,

• Conception des processus de chargement :

o Processus de chargement des tables de dimension,

o Processus de chargement des tables de faits,

o Processus de chargement de table temps,

II. Etude et planification :

Cette phase représente une phase préliminaire à l’ensemble du processus. Elle consiste en :

• L’étude des sources de données,

• La détection des emplacements des données source,

• La Définition de la périodicité du chargement,

II.1 Les sources de données :

Les sources de données de notre entrepôt sont :

• Le système SGC, avec ses 35 modules (voire annexe C),

• Le système de gestion de la distribution HT/HP,

• Les fichiers plats, en provenance d’autres structures (pour les achats), ou

d’organismes externes (le ministère des finances),

Les sources de données en chiffres:

• 58 sources de données, éparpillées sur l’ensemble du territoire national,

• Plus de 6 millions de clients,

• Plus de cent trente intégrations d’abonnés jour,

• Soixante-dix mille factures jour,

Page 114: Conception et Réalisation d'un Data Warehouse

106

II.2 Détection des emplacements des données sources :

Afin de définir l’emplacement des informations dans les différents systèmes source et d’en choisir les emplacements les plus fiables, nous avons travaillé de manière étroite avec les DBA et les gestionnaires.

Le nombre important de tables, la redondance des données et l’intervention de différents systèmes, rendent cette tâche très ardue. Afin de mener à bien cette détection, nous devons :

• Lister les données nécessaires à partir des étoiles conçues,

• Lister les emplacements de chaque donnée,

• Choisir la source la plus fiable et la valider comme source de chargement,

• Dresser un tableau14 qui établi le lien entre données sources et donnée cibles avec

les transformations nécessaires,

Cette étape s’achève par l’élaboration d’une carte logique entre données sources et données cibles15.

Il est important de valider les sources de données (donc le tableau cité précédemment), afin de vérifier leurs intégrités et leurs fiabilités.

II.3 Définition de la périodicité de chargement

La périodicité de chargement est étudiée pour chaque étoile séparément. , ce qui n’empêche pas une synchronisation dans les chargements des dimensions communes.

Avant de décider de la périodicité du chargement, les contraintes suivantes doivent être prises considération :

• La quantité de données à charger, • Le temps de non activité des systèmes sources,

L’étoile qui engendrera les chargements les plus importants, en termes de volume, n’est autre que l’étoile des ventes. En effet, le système de facturation, établit annuellement plus de six millions de factures, ce qui représente plus de dix millions de lignes de faits « ventes ». Ce processus s’exécute de façon journalière (soixante-dix mille lieux de consommation par jour). Aussi, le module de gestion des affaires (Système source) présente une forte volatilité de ses données. Cette volatilité est due au fait que le passage, d’une affaire donnée, d’une phase à une autre, ne laisse aucune trace sur la base de données opérationnelle.

14

Ce tableau est décrit dans le livre [Kimball 2004]. 15

Voire Annexe D

Page 115: Conception et Réalisation d'un Data Warehouse

107

De ce fait, l’idéal est de procéder à des chargements journaliers, pendant les heures de non activité des systèmes sources, c'est-à-dire, durant la période qui s’étend entre dix-huit heures et huit heures du matin.

Pourquoi pas des chargements hebdomadaires

Même si pendant les week-ends le nombre d’heures de non activité des systèmes est plus important, la quantité de données à charger sera, elle, plus conséquente, et affectera les performances du processus de chargement. Par ailleurs, la volatilité de certaines données nous contraint à appliquer une telle politique de chargement

III. Architecture du processus d’alimentation

L’élaboration d’une architecture du processus de l’alimentation « ETL » dès le début du projet est très importante. En effet, le choix d’une architecture affecte pratiquement toutes les composantes du projet. Tout changement de celle-ci engendrera nécessairement d’importants changements dans l’ensemble du projet.

Partant de ce constat, il est nécessaire de mettre en place une architecture consistante à même de prendre en charge toutes les contraintes auxquelles on doit faire face.

Le processus de l’ETL peut se faire de différentes manières. Dans le cas d’espèce nous avons choisi la méthode « Push-Pull ». En plus des avantages qu’elle présente, cette méthode pallie aux contraintes rencontrées au sein de l’entreprise et permet d’exploiter toutes les opportunités offertes. Parmi les contraintes et opportunités il peut être cité :

• L’impossibilité d’accès distant aux systèmes source : l’entreprise n’autorise pas des accès distants aux systèmes sources. L’accès se fera par le biais d’une base de données intermédiaire. Cette restriction est due à la structure organisationnelle de l’entreprise16.

• Les problèmes du réseau actuel17 : le réseau actuel subi des perturbations au niveau de quelques directions de distribution. Ces dernières ne sont pas encore équipées de connexion ADSL18.

• Le nombre important des sources de données et la quantité des données : Cette politique (push-pull) permettra le lancement de chargements parallèles.

• L’existence de serveurs au niveau sources : les cinquante-huit directions de distribution disposent de matériel informatique important, permettant de lancer des processus de préparation de données au niveau des « DD ».

• Maintenance facile: même si les sites sont éparpillés, la tâche d’une éventuelle maintenance sera facilitée par le biais des équipes informatiques en place.

16

Le découpage juridique de l’entreprise ne permet pas aux filiales de partager des informations d’une façon

directe. 17

Voire annexe F. 18

Plus de quarante D.D sont équipées de connexion ADSL.

Page 116: Conception et Réalisation d'un Data Warehouse

108

Pourquoi adopter cette architecture ?

Outre un chargement sûr, Cette architecture permet de:

• Réduire les temps de chargement : grâce au chargement parallèle, le temps de traitements sera réduit.

• L’impact réduit d’un chargement échoué : l’échec d’un chargement aura un impact réduit sur les données du Data Warehouse.

• La possibilité de mise en place d’une nouvelle façon d’accès : dans une architecture « Push-Pull » il est préférable de faire un transfert de fichiers, par exemple via FTP. cette méthode très performante « testée » est difficile à déployer, elle sera donc mise en perspective. La figure suivante illustre l’architecture du processus d’alimentation adoptée :

Figure II.27 : Architecture globale du processus E.T.L.

Dans la zone de préparation« Staging area » les données sont extraites à partir des

sources de données, transformées et préparées pour le chargement final. Au niveau du serveur « ELIT » il est procédé à l’affectation de clés artificielles et à quelques transformations nécessaires avant le chargement final dans la zone d’entreposage. Après chaque chargement, une mise à jour des Meta Data doit être faite.

Page 117: Conception et Réalisation d'un Data Warehouse

109

IV. Processus de chargement

Le diagramme d’activités suivant décrit le processus général de l’alimentation de l’entrepôt de données dés sa mise en service :

Figure II.29 : Diagramme d’activité du processus d’alimentation.

Page 118: Conception et Réalisation d'un Data Warehouse

110

Deux types de tables dans l’entrepôt de données « faits, dimensions » doivent être distingués. Chaque type de table diffère dans les d’informations qu’il contient, et d’où donc l’adoption de deux processus de chargement.

La stratégie d’extraction adoptée consiste à comparer des chargements successifs afin de détecter les changements. Cette stratégie, étant la plus fiable, est incontournable pour la capture des changements pour des raisons de non fiabilité des champs date, généralement non renseignés. Cette détection se fait au niveau de la zone de préparation améliorant sensiblement les performances.

IV.1 Processus de chargement de dimension

Les tables de dimension constituent le contexte de la table de faits. Elles représentent le point d’entrée au Data Warehouse. Une dimension est généralement constituée : d’une clé artificielle, d’une clé naturelle et des attributs.

Le processus de chargement de dimension doit, outre le chargement des données, assurer : • La gestion des clés artificielles: affectation des clés et mise en correspondance avec

les clés naturelles. • La gestion de l’évolution de dimension : gérer les changements que subissent les

dimensions. Il existe trois types de traitement par rapport à l’évolution d’une dimension :

o Type 1 « écrasement » : consiste à mettre à jour l’attribut subissant un changement.

o Type 2 « création d’un nouvel enregistrement » : consiste à créer un nouvel enregistrement afin de sauvegarder tout le cycle d’évolution de la dimension.

o Type 3 « déplacement de la valeur a changé dans un attribut ancien » :

consiste à prévoir des attributs pour enregistrer les changements éventuels. Il permet de sauvegarder un nombre défini de changements.

Page 119: Conception et Réalisation d'un Data Warehouse

111

Le digramme suivant illustre la politique que nous avons retenue :

Figure II.30 : diagramme d’activité du processus de chargement de dimension.

Page 120: Conception et Réalisation d'un Data Warehouse

112

La stratégie adoptée pour la détection des changements se fait grâce à la comparaison

entre le dernier chargement et le chargement actuel. Cette méthode, comme décrite lors de la synthèse bibliographique, est la plus fiable pour la capture des changements.

Les mises à jour de type 3 sont traitées comme de nouvelles insertions, avec la mise à jour de la table références.

IV.2 Processus de chargement des tables de faits

L’extraction des faits se fait avec les clés naturelles utilisées dans les systèmes sources. L’étape qui précède le chargement de la table des faits consiste à remplacer les clés naturelles par les clés artificielles. La substitution peut se faire directement par le biais des tables de dimension, ce qui est correct mais très lent. Pour cela on utilise des tables de référencement.

Le processus de chargement des tables des faits doit garantir l’intégrité référentielle vis-à-vis des tables de dimensions.

Le diagramme d’activité suivant illustre le processus de chargement adopté pour une table de faits :

Page 121: Conception et Réalisation d'un Data Warehouse

113

Figure II.31 : diagramme d’activité du processus de chargement de faits.

Le chargement de la table de fait peut être une insertion, ou une mise à jour des tables de

faits.

Page 122: Conception et Réalisation d'un Data Warehouse

114

IV.3 Processus de chargement particulier

Dans un entrepôt de données il y a des tables particulières, soit : la table de la dimension temps et les tables d’agrégats, nécessites un traitement à part.

IV.3.1 Processus de chargement de la dimension temps

Contrairement aux autres dimensions, la dimension temps contient uniquement des dates qui ne sont pas forcément extraites à partir des systèmes sources. Cette dimension doit contenir, en effet, toutes les dates qui coïncident, ou coïncideront, avec un fait donné. Elle participe à toutes les étoiles et assure l’historisation. Dès lors, il est préférable de construire un calendrier :

« La dimension date est plus souvent construite comme étant un calendrier avec une granularité journalière ». [Kimball, 2004].

IV.3.2 Processus de construction d’agrégats

Après le chargement d’une étoile, les tables d’agrégats doivent être chargées par le biais de l’ETL et à partir des données détaillées. En plus du calcul des agrégats et de leur insertion, des mises à jour fréquentes de ces tables sont indispensables.

Page 123: Conception et Réalisation d'un Data Warehouse

115

V. Conclusion

Un processus E.T.L a pour mission d’assurer la livraison de données conformes, cohérentes et correctes tout en assurant des performances acceptables. Lors de la conception du processus de l’ETL il a été envisagé d’atteindre les objectifs suivants:

• Assurer le chargement des données et leur qualité,

• Assurer la transparence des processus de chargement et de consolidation qui assure la qualité des données,

• Ne pas nuire aux performances des systèmes sources,

• Utiliser des sources, autres que les sources opérationnelles pour donner une valeur ajoutée aux informations,

• Permettre un suivi de l’avancement des chargements, et corrections en cas d’erreur,

• Offrir une documentation complète du processus, afin de faciliter la maintenance ainsi que l’amélioration,

• Offrir une performance optimale grâce aux chargements parallèles et séparation des données selon l’opération de chargement (mise à jour ou nouvelle insertion),

• Mettre en œuvre des solutions secours pour faire face aux problèmes réseau,

• Mise à jour des Meta data, pour la maintenance et l’assurance de la qualité de données,

Page 124: Conception et Réalisation d'un Data Warehouse

116

Conception des cubes dimensionnels

Page 125: Conception et Réalisation d'un Data Warehouse

117

I. Introduction

Afin de faciliter l’analyse et la navigation dans les données, il est important que les cubes dimensionnels soient bien conçues et définis de manière claire pour une utilisation intuitive.

La conception des cubes dimensionnels passe par la définition des mesurables, des dimensions et des hiérarchies présentes au sein des dimensions, ainsi que les différents niveaux de détails de chaque hiérarchie. Le but de la mise en place de ces cubes est d’offrir une représentation abstraite d'informations multidimensionnelles à des fins d’analyse.

Le choix des cubes à construire, des mesurables qu’ils contiendront, des dimensions participantes dans chacun d’entre eux et des hiérarchies qui constituera chaque dimension dépend essentiellement des besoins recensés et de l’utilisation finale.

II. Définition des niveaux et des hiérarchies

La définition des différentes hiérarchies présente dans une dimension est une étape cruciale et indispensable pour la conception des cubes. En effet, c’est grâce à ces hiérarchies que l’utilisateur pourra naviguer et explorer à bon escient les informations offertes par un cube donné.

Cette étape se déroule en deux phases:

• Identification des attributs d’un même niveau pour chaque dimension.

• Construction des hiérarchies (Une dimension peut avoir plusieurs hiérarchies).

Au final nous obtiendrons le tableau récapitulatif suivant :

Dimension Colonne Niveaux Hiérarchies

dim_activite

code_activite

libele_activite Niveau_1 : N1

Hierarchy_1 : N1 ALL

dim_affaire

numero_affaire

observation

degre_urgence

initier_par

commune

wilaya

Niveau_1 : N1 Hierarchy_1 :

N1 ALL

Page 126: Conception et Réalisation d'un Data Warehouse

118

dim_client

code_client

reference_lc

type

Niveau_1 : N1 Hierarchy_1 : N1 N2 N3 ALL

Hirarchy_2 :

N1 N3 ALL numero_client Niveau_2 : N2

Groupe Niveau_3 : N3

dim_facture

numero_facture

numero_facture_sgc

date_facture

taux_tva

soutient_etat

conso_moy_enrgie_jour

reference_lc

Niveau_1 : N1 Hierarchy_1 : N1 N2 N3 N4 ALL

Hierarchy_2 :

N1 N2 N4 N3 ALL

type_facture Niveau_2 : N2

type_releve Niveau_3 : N3

type_cycle Niveau_4 : N4

dim_energie

code_energie

type_energie

unite_mesure

Niveau_1 : N1 Hierarchy_1 :

N2 N1 ALL

Hierarchy_2 : N2 N1 Debit Niveau_2: N2

dim_nature

code_nature

lib_nature Niveau_1 : N1

Hierarchy_1 :

N2 N1 ALL operation Niveau_2 : N2

dim_phase

code_phase

intitule_phase

desc_phase

durree_estimee_phase

Niveau_1 : N1

Hierarchy_1 :

N1 ALL

dim_tarif

code_tarif

description_tarif

abreviation_tarif

Niveau_1 : N1 Hierarchy_1 :

N1 N2 ALL

Energie Niveau_2 : N2

Page 127: Conception et Réalisation d'un Data Warehouse

119

dim_temps

code_temps

date

jour_du_mois

jours

evenement

Niveau_1 : N1

Hierarchy_1 :

N1 N2 N3 N4N5 N6 ALL

semaine_dans_annee

Niveau_2 : N2

mois_annee

annee_mois

mois

Niveau_3 : N3

annee_trimestre

trimestre Niveau_4 : N4

Saison Niveau_5 : N5

Annee Niveau_6 : N6

dim_type_abonne

code_type_abonnee

Niveau_1 : N1

Hierarchy_1 : N1 N2 N3 All

Hierarchy_2 :

N1 N3 N2 All

type_client_domiciliation

Niveau_2 : N2

type_client_paiement

Niveau_3 : N3

dim_type_affaire

code_affaire

intitule_affaire

energie_affaire

durree_approximative

Niveau_1 : N1

Hierarchy_1 : N1 N2 N3 All

code_ss_categorie

intitule_ss_categorie

Niveau_2 : N2

code_categorie

intitule_categorie Niveau_3 : N3

Page 128: Conception et Réalisation d'un Data Warehouse

120

dim_zone

code_zone

code_commune

commune

Niveau_1 : N1

Hierarchy_1 : N1 N2 N3 N4

N5 ALL

code_agence

agence Niveau_2 : N2

code_dr

dr

Niveau_3 : N3

code_wilaya

wilaya Niveau_4 : N4

code_filiale

filiale

adresse_filiale

tel_filiale

Niveau_5 : N5

Tableau II.28 : Tableau donnant les niveaux et les hiérarchies de chaque dimension.

Le niveau « All » : Ce niveau représente le niveau le plus haut d’une hiérarchie. De ce

fait, il est le niveau le plus agrégé. Le niveau « ALL » n’apparaît pas systématiquement dans toutes les hiérarchies.

Page 129: Conception et Réalisation d'un Data Warehouse

121

III. La liste des cubes

Dans ce qui suit nous allons dresser la liste des cubes à mettre en place. Pour chaque cube on donnera les dimensions participantes ainsi que les mesurables présents dans ces cubes. Il est à signaler aussi que la dimension « dim_nature » n’apparaitra nul part dans la description des cubes. En effet, cette dimension a été remplacée par l’utilisation de mesurables dans les cubes concernés. Le tableau suivant donne le détail de la conception de ces cubes :

Nom du cube Les mesurables Les dimensions Les Hiérarchies de la dimension

Suivi des ventes 1. Chiffre d’affaires 2. Nombre de factures

Dim_client Hierarchy_1

Dim_facture Hierarchy_1 Hierarchy_2

Dim_energie Hierarchy_1 Hierarchy_2

Dim_zone Hierarchy_1

Dim_temps Hierarchy_1

Dim_tarif Hierarchy_1

Suivi des ventes et des consommations

1. Chiffre d’affaires 2. Consommation 3. Nombre de consommations

nulles

Dim_client Hierarchy_1

Dim_facture Hierarchy_1

Dim_energie Hierarchy_2

Dim_zone Hierarchy_1

Dim_temps Hierarchy_1

Dim_tarif Hierarchy_1

Suivi de l’apport abonné

1. Nombre de raccordements

Dim_type_abonné Hierarchy_1 Hierarchy_2

Dim_zone Hierarchy_1

Dim_client Hierarchy_1

Dim_temps Hierarchy_1

Page 130: Conception et Réalisation d'un Data Warehouse

122

Suivi des résiliations

1. Nombre de résiliations

Dim_type_abonné Hierarchy_1 Hierarchy_2

Dim_zone Hierarchy_1

Dim_client Hierarchy_1

Dim_temps Hierarchy_1

Suivi des mises en service

1. Nombre de mises en service.

Dim_type_abonné Hierarchy_1 Hierarchy_2

Dim_zone Hierarchy_1

Dim_client Hierarchy_1

Dim_temps Hierarchy_1

Suivi des affaires 1. Nombre d’affaires 2. Durée

Dim_client Hierarchy_1

Dim_energie Hierarchy_1

Dim_zone Hierarchy_1

Dim_temps Hierarchy_1

dim_type_affaire Hierarchy_1

dim_phase Hierarchy_1

dim_affaire Hierarchy_1

Suivi des recouvrements

1. Montant créances 2. Montant avoir. 3. Montant factures fraîches. 4. Montant factures impayées. 5. Montant précontentieux.

Dim_temps Hierarchy_1

Dim_client Hierarchy_1

Dim_facture Hierarchy_1 Hierarchy_2

Dim_zone Hierarchy_1

Tableau II.29 : Liste des cubes dimensionnels.

Page 131: Conception et Réalisation d'un Data Warehouse

123

IV. Présentation des cubes dimensionnels

Figure II.32 : Cube dimensionnel « Suivi des ventes ».

Cube_suivi_vente - Dim_client

Cube_suivi_vente - Dim_zone

Cube_suivi_vente - Dim_enrgie

Cube_suivi_vente - Dim_facture

Cube_suivi_vente - Dim_temps

Cube_suivi_vente - Dim_tarif

Dim_client

code_client <N1>reference_lctypenumero_client <N2>

Hierarchie_1 <Default> <h>

Cube_suivi_vente

chiffre_affairenombre_factureFait_vente

Dim_zone

code_zone <N1>code_communecommunecode_agence <N2>agencecode_dd <N3>ddcode_wilaya <N4>wilayacode_fil iale <N5>fil iale

Hierarchie_1 <Default> <h>

Dim_enrgie

code_energie <N1>type_energieunite_mesuredebit <N2>

Hierarchie_1 <Default>Hierarchie_2

<h1><h2>

Dim_temps

code_temps <N1>datejour_du_moisjoursevenementsemaine_dans_annee <N2>mois_annee <N3>moisannee_trimestre <N4>trimestresaison <N5>annee <N6>

Hierarchie_1 <Default> <h>

Dim_facture

numero_facture <N1>numero_facture_sgcdate_facturesoutient_etatconso_moy_enrgie_jourtype_facture <N2>type_releve <N3>type_cycle <N4>

Hierarchie_1 <Default>Hierarchie_2

<h1><h2>

Dim_tarif

code_tarif <N1>description_tarifabreviation_tarifenergie <N2>

Hierarchie_1 <Default> <h>

Page 132: Conception et Réalisation d'un Data Warehouse

124

Figure II.33 : Cube dimensionnel « Suivi des ventes et des consommations ».

Cube_suivi_vente_conso - Dim_client

Cube_suivi_vente_conso - Dim_zone

Cube_suivi_vente_conso - Dim_enrgie

Cube_suivi_vente_conso - Dim_facture

Cube_suivi_vente_conso - Dim_temps

Cube_suivi_vente_conso - Dim_tarif

Dim_client

code_client <N1>reference_lctypenumero_client <N2>

Hierarchie_1 <Default> <h>

Cube_suivi_vente_conso

chiffre_affairenombre_facturenombre_conso_nulFait_vente

Dim_zone

code_zone <N1>code_communecommunecode_agence <N2>agencecode_dd <N3>ddcode_wilaya <N4>wilayacode_fil iale <N5>fil iale

Hierarchie_1 <Default> <h>Dim_enrgie

code_energie <N1>type_energieunite_mesuredebit <N2>

Hierarchie_2 <Default> <h>

Dim_temps

code_temps <N1>datejour_du_moisjoursevenementsemaine_dans_annee <N2>mois_annee <N3>moisannee_trimestre <N4>trimestresaison <N5>annee <N6>

Hierarchie_1 <Default> <h>

Dim_facture

numero_facture <N1>numero_facture_sgcdate_facturesoutient_etatconso_moy_enrgie_jourtype_facture <N2>type_releve <N3>type_cycle <N4>

Hierarchie_1 <Default>Hierarchie_2

<h1><h2>

Dim_tarif

code_tarif <N1>description_tarifabreviation_tarifenergie <N2>

Hierarchie_1 <Default> <h>

Page 133: Conception et Réalisation d'un Data Warehouse

125

Figure II.34 : Cube dimensionnel « Suivi des abonnés ».

Figure II.35 : Cube dimensionnel « Suivi des recouvrements ».

Cube_suivi_des_abonnes - Dim_zone Cube_suivi_des_abonnes - Dim_temps

Cube_suivi_des_abonnes - Dim_type_abonne Cube_suivi_des_abonnes - Dim_client

Dim_zone

code_zone <N1>code_communecommunecode_agence <N2>agencecode_dd <N3>ddcode_wilaya <N4>wilayacode_fi l iale <N5>fil iale

Hierarchie_1 <Default> <h>

Dim_client

code_client <N1>reference_lctypenumero_client <N2>

Hierarchie_1 <Default> <h>

Dim_temps

code_temps <N1>datejour_du_moisjoursevenementsemaine_dans_annee <N2>mois_annee <N3>moisannee_trimestre <N4>trimestresaison <N5>annee <N6>

Hierarchie_1 <Default> <h>

Cube_suivi_des_abonnes

Nombre_raccordementsNombre_resil iationsNombre_mise_serviceFait_suivi_abonnes...

Dim_type_abonne

code_type_abonnee <N1>type_client_domicil iation <N2>type_client_paiement <N3>

Hierarchie_1 <Default> <h>

Cube_suivi_recouvrement - Dim_clientCube_suivi_recouvrement - Dim_facture

Cube_suivi_recouvrement - Dim_zone Cube_suivi_recouvrement - Dim_temps

Dim_zone

code_zone <N1>code_communecommunecode_agence <N2>agencecode_dd <N3>ddcode_wilaya <N4>wilayacode_fil iale <N5>fil iale

Hierarchie_1 <Default> <h>

Dim_client

code_client <N1>reference_lctypenumero_client <N2>

Hierarchie_1 <Default> <h>

Dim_temps

code_temps <N1>datejour_du_moisjoursevenementsemaine_dans_annee <N2>mois_annee <N3>moisannee_trimestre <N4>trimestresaison <N5>annee <N6>

Hierarchie_1 <Default> <h>

Cube_suivi_recouvrement

Montant_creancesMontant_avoirMontant_factures_fraichesMontant_facture_impayeeMontant_precontentieuxFait_suivi_abonnes

Dim_facture

numero_facture <N1>numero_facture_sgcdate_facturesoutient_etatconso_moy_enrgie_jourtype_facture <N2>type_releve <N3>type_cycle <N4>

Hierarchie_1 <Default>Hierarchie_2

<h1><h2>

Page 134: Conception et Réalisation d'un Data Warehouse

126

Figure II.36 : Cube dimensionnel « Suivi des affaires ».

Cube_suivi_affaire - Dim_zone

Cube_suivi_affaire - Dim_tempsCube_suivi_affaire - Dim_type_affaire

Cube_suivi_affaire - Dim_energie

Cube_suivi_affaire - Dim_client

Cube_suivi_affaire - Dim_affaire Cube_suivi_affaire - Dim_phase

Cube_suivi_affaire

nombre_affairedurre_moyenFait_suivi_affaire

Dim_zone

code_zone <N1>code_communecommunecode_agence <N2>agencecode_dd <N3>ddcode_wilaya <N4>wilayacode_fil iale <N5>fi l iale

Hierarchie_1 <Default> <h>

Dim_energie

code_energie <N1>type_energieunite_mesuredebit <N2>

Hierarchie_1 <Default>Hierarchie_2

<h1><h2>

Dim_client

code_client <N1>reference_lctypenumero_client <N2>

Hierarchie_1 <Default> <h>

Dim_temps

code_temps <N1>datejour_du_moisjoursevenementsemaine_dans_annee <N2>mois_annee <N3>moisannee_trimestre <N4>trimestresaison <N5>annee <N6>

Hierarchie_1 <Default> <h>

Dim_affaire

numero_affaire <N1>degre_urgenceinitier_parobservation

Hierarchie_1 <Default> <h>

Dim_type_affaire

code_affaire <N1>intitule_affairedurree_approximativecode_ss_categorie <N2>intitule_ss_categoriecode_categorie <N3>intitule_categorie

Hierarchie_1 <Default> <h>

Dim_phase

code_phase <N1>intitule_phasedurree_estimee_phasedesc_phase

Hierarchie_1 <Default> <h>

Page 135: Conception et Réalisation d'un Data Warehouse

127

V. Conclusion

Les cubes dimensionnels est une étape très importante dans tout projet Data Warehouse. C’est grâce à cette dernière que l’utilisateur pourra utiliser et exploiter au mieux les données contenues dans l’entrepôt de données de manière correcte et intuitive.

Dans ce chapitre nous avons essayé donc de définir les cubes dimensionnels en explicitant les dimensions participantes dans chacun d’entre eux. Ensuite nous avons défini, pour chacune des dimensions, les différentes hiérarchies présentes ainsi que les niveaux qui composent ces dernières.

Page 136: Conception et Réalisation d'un Data Warehouse

128

Meta Data

Page 137: Conception et Réalisation d'un Data Warehouse

129

I. Les « Méta Data » ou « métas données » de l’entrepôt

Un entrepôt de données, étant en production constante, doit être suivi de prés. L'administration d'un Data Warehouse revient à mettre en place des processus et des mécanismes de gestion. Ces mécanismes sont là pour assurer un meilleur fonctionnement de l’entrepôt. Aussi ils doivent garantir l’alimentation en données quelques soient les circonstances.

Afin d’assurer la mise à jour de l’entrepôt de données, il est nécessaire de suivre son alimentation au jour le jour, surtout dans le cas présent où les sources de données sont géographiquement dispersées. Un tel suivi peut être garantie grâce au recours au méta data de l’entrepôt.

II. Rôle des métas données

Les métas données ont un rôle très important dans le cycle de vie d’un entrepôt de données. En effet, elles donnent une description ainsi qu’un sens aux données contenues dans l’entrepôt, afin que l’utilisateur comprenne et puisse utiliser au mieux ces données. Cependant, leur rôle peut dépasser le cadre de cette description en se présentant comme un moyen de supervision et de suivi de l’évolution de l’entrepôt. Le diagramme illustré sur la figure II.37 montre la conception des métas données.

Ce diagramme représente, de manière claire, la structure de l’entrepôt de données, renseignant de ce fait sur sa contenance en données. En plus de cela, il offre la possibilité de superviser les chargements en donnant une vue générale sur l’alimentation de l’entrepôt de données.

Page 138: Conception et Réalisation d'un Data Warehouse

130

Figure II.37 : Diagramme de classe des métas données.

Page 139: Conception et Réalisation d'un Data Warehouse

131

III. Exploitation des métas données

III.1 Présentation de la partie navigation

La fonction première des métadonnées est d’offrir un catalogue complet et détaillé sur le contenu de l’entrepôt. Ce catalogue est bien sûr appelé à évoluer. De ce fait l’utilisateur doit être en mesure de consulter ce catalogue et d’y proposer des mises à jour, si cela est nécessaire. Le diagramme des cas d’utilisation suivant illustre ces différents volets :

Figure II.38 : DCU navigation dans les métas données.

III.2 Présentation de la partie supervision

Vu le nombre de sources de données et leurs dispersions géographiques, il se peut que l’alimentation en données d’une des directions de distribution ne se déroule pas comme prévu. Dans ce cas, l’administrateur doit être en mesure de détecter les erreurs survenues lors de l’alimentation et avoir la possibilité de recourir à des solutions secours. Ces solutions de supervision et de chargement secours sont :

Page 140: Conception et Réalisation d'un Data Warehouse

132

III.2.1 Supervision : l’administrateur aura la possibilité de suivre l’état des chargements journaliers de l’entrepôt de données. Ainsi, il aura une situation précise des chargements par direction de distribution, lui offrant de ce fait la possibilité de détecter les chargements échoués et la date de l’échec de manière à recouvrir les données non chargées.

III.2.2 Solutions secours : lors d’un chargement échoué l’administrateur de l’entrepôt de données pourra utiliser l’une des méthodes suivantes pour mettre à jour les données de l’entrepôt :

a. Le chargement paramétré : le chargement peut se faire à distance en spécifiant les directions concernées par ce chargement et le jour du chargement concerné. Cependant, cette solution n’est utilisable que pour le jour suivant l’échec du chargement et cela, soit à cause de la volatilité des données, soit à cause de la quantité trop importante des données. Le paramètre de ce chargement n’est autre que les Directions de distribution concernées par le chargement.

b. Le chargement à partir des fichiers de sauvegarde : durant la présentation de la partie « alimentation de l’entrepôt » nous avons évoqué les fichiers de sauvegarde. Ces fichiers sont utilisés afin de charger les données manquantes en cas de problèmes. Ces fichiers, qui sont générés après chaque extraction de données au niveau des directions de distribution, sont transférés et utilisés. Une durée de sauvegarde de ces fichiers est nécessaire, cette durée a été arrêtée à une semaine.

Le diagramme des cas d’utilisation suivant illustre les cas cités précédemment :

Figure II.39 : DCU supervision.

Page 141: Conception et Réalisation d'un Data Warehouse

133

IV. Conclusion

La couche méta données est très importante dans un projet Data Warehouse, dans la mesure où elle en permet la maintenance de ce dernier, garantit son intégrité et facilite son expansion.

Ainsi il est plus que nécessaire de concevoir les métas données et de développer une couche applicative permettant de les maintenir. Dans ce chapitre nous avons essayé de concevoir un sous système d’administration de l’entrepôt de données qui répond aux exigences d’un tel projet.

Page 142: Conception et Réalisation d'un Data Warehouse

134

Partie III : Réalisation et déploiementRéalisation et déploiementRéalisation et déploiementRéalisation et déploiement

Page 143: Conception et Réalisation d'un Data Warehouse

135

I. Introduction

Pour la réalisation et la mise en place de la solution, il a été nécessaire de recourir à un certain nombre d’outils et mettre en place des environnements d’exécution.

Ce chapitre a pour objectif, de décrire l’environnement mis en place et les outils utilisés, ainsi que de décrire l’environnement existant (matériels et logiciels), et dans lequel évoluera notre système.

II. Implémentation

II.1 Périmètre technique et fonctionnel

Cette partie décrit les infrastructures déjà en place. En effet, cette dernière est une étape à ne pas négliger, car la diversité des sources et leurs plateformes techniques pourront engendrer des problèmes de compatibilité.

II.1.1 Matériel

Les systèmes sources sont installés sur différentes plateformes :

• Machine IBM,

• Machine INTEL : HP ou DELL,

II.1.2 Systèmes d’exploitation

Lors de notre étude il a été recensé les systèmes suivants :

• AIX 5.1, 5.2 pour les machines IBM,

• LINUX : RedHat 4.5,

• Windows Server 2003,

• Solaris Sparc,

L’étude du matériel existant nous a permis de prévoir des solutions à certains problèmes, tels que la non compatibilité des machines AIX 5.2 avec la version du JRE nécessaire pour l’exécution des programmes d’extractions.

Page 144: Conception et Réalisation d'un Data Warehouse

II.2 Architecture

La figure suivante illustre la structure

Figure III

II.3 Zone de stockage

Lors de la conception, il données : la base de données

Le choix du système de gestion de base de données s’est fait de chaque base de données, de son utilisation et d

1) Base de données «

La base de données, Data Warehouse, a été implémentée sous lsource PostgresPlus. Cconnu pour ses performances par rapport aux bases de données volumineusesintègre un ensemble d’outilpré configuré pour la mise en place d’un Data Warehouse.

19

Voir annexe F.

Architecture technique de la solution

La figure suivante illustre la structure et l’architecture technique de la solution proposée

Figure III .1 : Architecture technique de la solution.

Zone de stockage

conception, il a été question de concevoir et mettre en place deux bases de : la base de données de la zone d’entreposage et celle des Meta data.

Le choix du système de gestion de base de données s’est fait en fonction dede données, de son utilisation et des données qu’elle contiendra.

Data Warehouse » :

La base de données, Data Warehouse, a été implémentée sous lsource PostgresPlus. Cette distribution de PostgreSQL, en plus du connu pour ses performances par rapport aux bases de données volumineusesintègre un ensemble d’outils d’administration et de configuration. Aussi ce SGBD est

configuré pour la mise en place d’un Data Warehouse.

136

technique de la solution proposée :

été question de concevoir et mettre en place deux bases de et celle des Meta data.

en fonction de la finalité es données qu’elle contiendra.

La base de données, Data Warehouse, a été implémentée sous le SGBD open noyau PostgreSQL

connu pour ses performances par rapport aux bases de données volumineuses19, d’administration et de configuration. Aussi ce SGBD est

Page 145: Conception et Réalisation d'un Data Warehouse

137

2) Base de données Meta Data :

La base de données, Meta data, a été implémentée sous le SGBD MySQL, qui est un SGBD open source simple d’utilisation et performant pour les petites bases de données.

II.4 Zone d’alimentation de l’entrepôt

L’implémentation du processus de chargement peut se faire par le biais d’outils disponibles sur le marché. Une multitude de choix s’offre à nous. Cependant, et vu l’orientation de l’entreprise vers l’open source notre étude s’est limité à cette classe de produit.

Après une étude comparative, le choix a été porté sur « Talend Open Studio » dans sa version « 3.1.4r2 », connu comme l’outil le plus performant de sa catégorie open source [Daan, 2007]. Ce dernier basé sur l’IDE « Eclipse » intègre un ensemble de composants implémentés en JAVA et permet de rajouter son propre code JAVA.

Les points forts de cet outil sont : • Assurer une indépendance totale vis-à-vis du SGBD source, ou celui

implémentant l’entrepôt de données.

• Sa richesse en nombre de composants, permet l’extraction de toute source de

données connue et standard.

• Génère des programmes en java s’exécutant sur différentes plateformes.

• Développé par une communauté importante qui ne cesse d’augmenter.

• Permet d’ajouter du code java afin d’implémenter notre solution telle qu’elle a été

conçue.

II.5 Zone de restitution

Cette zone représente l’interface entre l’utilisateur et le Data Warehouse. Elle est constituée d’un ensemble d’outils qui doivent permettre aux utilisateurs d’exploiter le système mis en place dans les meilleures conditions possibles. . Ainsi plusieurs outils et serveurs ont été mis en place:

• Un serveur web Apache permettant un accès distant.

• Une plateforme BI « SpagoBI » pour la gestion et la diffusion des documents, ainsi

que pour son module de création de requêtes à la demande « Querry by exemple ».

• Un moteur ROLAP « Mondrian », pour l’implémentation des cubes conçus pour

l’analyse multidimensionnelle. Ce dernier est connu comme leader des moteurs

ROLAP open source.

Page 146: Conception et Réalisation d'un Data Warehouse

138

• Un serveur de reporting « JasperReports », pour l’édition des rapports préétablis.

Ces derniers sont conçus séparément et intégrés dans la plateforme « SpagoBI ».

• Un serveur SMTP, pour la diffusion des rapports.

• Implémentation des tableaux de bord conçus avec l’outil « Open Slazio » pour une

représentation graphiques efficace et compréhensible.

Même si ces outils se présentent comme des solutions clé en main, ils nécessitent un travail d’intégration et de conception afin de donner une valeur ajoutée aux états implémentés.

En plus de la mise en place de ces outils, il était nécessaire de développer certains volets:

• Gestion des utilisateurs : ce module permettra la gestion des utilisateurs et des

droits d’accès.

• Administration et supervision de l’entrepôt de données :

• Navigation dans les Meta data : cela offrira un support aux utilisateurs finaux.

Ces deux modules ont été développés en JavaServer Pages (JSP), qui est l’extension web du langage Java. Le développement s’est fait avec la version 6.5 de l’IDE NetBeans. Le choix de ce langage est en rapport avec les points suivants :

• Les possibilités offertes par ce langage.

• La portabilité des modules développés.

• L’intégration au sein du même serveur web.

• L’intégration dans la plateforme SpagoBI. Cette dernière étant développée en JSP.

• L’exécution au niveau serveur, offrant un niveau de sécurité optimum.

Page 147: Conception et Réalisation d'un Data Warehouse

139

III. Déploiement

Pour mieux décrire le déploiement de la solution, on utilise le modèle de déploiement U.M.L qui permet de présenter l’architecture de déploiement d’une manière simple et compréhensible.

Comme on peut le voir, notre solution comporte trois zones : zone d’alimentation, zone de stockage et zone de restitution. Afin d’illustrer cela, on propose deux diagrammes de déploiements : Un diagramme pour la zone d’alimentation et un autre diagramme pour la zone de restitution. La zone de stockage étant liée directement aux deux autres zones sera décrite dans les deux modèles.

III.1 Déploiement de la zone d’alimentation

Figure III.2 : Digramme de déploiement de la zone d’alimentation.

Page 148: Conception et Réalisation d'un Data Warehouse

140

III.2 Déploiement de la zone de restitution

Figure III.3 : Diagramme de déploiement de la zone de restitution.

Page 149: Conception et Réalisation d'un Data Warehouse

141

IV. Conclusion

La partie de restitution est la partie sur laquelle l’utilisateur final aura à interagir. Cette dernière a été mise en place en intégrant des solutions « Open Source », et en développant certains volets de manière à assurer une bonne utilisation du système.

Des programmes ont été développés, au préalable, en JAVA, afin d’assurer l’alimentation de la zone de stockage en données. Cette dernière a été implémentée sous le SGBD PostgreSQL, dans sa distribution « PostgreSQLPLUS ».

Le déploiement de la solution se fait suivant les diagrammes de déploiement illustrés dans la figure III.2 et la figure III.3, et se divise en deux parties :

• Déploiement de la zone d’alimentation.

• Déploiement de la zone de restitution.

Le déploiement se fait pour le moment sur trois sites pilotes, et sera étendu à l’ensemble du territoire des que les résultats des tests fonctionnels auront été approuvés.

Page 150: Conception et Réalisation d'un Data Warehouse

142

Conclusion générale et perspectives

Page 151: Conception et Réalisation d'un Data Warehouse

143

Conclusion générale et Perspectives

Exploiter les données à disposition de l’entreprise afin de leur donner de la valeur ajoutée, tel est le défi des entreprises modernes.

Dans ce cadre, et afin de palier à des problèmes récurrents dans le processus de prise de décision, SONELGAZ a initié le projet de réalisation d’un Data Warehouse pour permettre la mise en place d’un système décisionnel fiable et efficace.

Tout au long de notre travail de conception et de réalisation, nous avons essayé de suivre une démarche mixte, alliant de ce fait entre Deux approches connues dans le domaine du Data Warehousing, à savoir l’approche « Besoins d’analyse » et l’approche « Sources de données ». Cette démarche a permis de répondre aux attentes et besoins des utilisateurs tout en exploitant au mieux les données générées par les systèmes opérationnels de manière à anticiper sur des besoins non exprimés.

Bien que la méthode des entretiens soit l’outil principal pour la collecte des besoins dans ce travail (en effet, le milieu et l’organisation du groupe ont rendu toute autre approche pratiquement impossible), l’étude des besoins déjà exprimés sous forme de rapports et de processus de prise de décision nous ont été d’une grande utilité pour définir de manière claire le périmètre et les besoins réels des utilisateurs. Cette étude a fait ressortir quatre sujets d’analyse dignes d’intérêt pour l’entreprise qui sont : Les ventes, les affaires, les nouveaux abonnés, le recouvrement.

Dans un deuxième temps, la modélisation de la zone de stockage des données s’est faite grâce aux principes de la modélisation dimensionnelle. Cette modélisation offre une vision claire et une compréhension intuitive des modèles proposés. Nous avons de ce fait proposé des modèles en étoiles des quartes activités recensés. Partant de chaque modèle dimensionnel, nous avons donné les modèles agrégés afin d’améliorer les performances du futur système.

La partie d’alimentation de la zone de stockage « implémentation physique des modèles dimensionnels sur un SGBD relationnel » a été sans nul doute la partie du projet la plus fastidieuse et consommatrice en temps ; nous permettant de vérifier le postula disant qu’il est nécessaire d’y consacrer plus de 80% du temps de réalisation d’un Data Warehouse. Cette étape nous a permis de concevoir et de réaliser, grâce à des outils open source, les routines d’extraction, transformation et chargement des données.

L’utilisation d’outils et de solutions open source est un volet très important dans ce projet. En effet, l’orientation Open Source du projet a été décidée dés l’initiation de ce dernier. Cette orientation, qui se fait ressentir durant les étapes sus citées, est plus présente dans la partie « réalisation de la zone de restitution » grâce à l’intégration d’une plateforme « BI », pour la diffusion et la gestion des documents, et d’outils de Reporting et de navigation dans les données complètement open source, offrant à l’utilisateur la possibilité d’exploiter les données de l’entrepôt via n’importe quel client léger. La partie restitution a aussi nécessité le

Page 152: Conception et Réalisation d'un Data Warehouse

144

développement des volets de gestion des utilisateurs, d’administration de l’entrepôt et de supervision de ce dernier.

Pour la mise en route de la solution, nous avons entamé le travail de déploiement en choisissant des sites pilotes. Ce déploiement obéit à une démarche clairement illustrée grâce à des digrammes de déploiement présentés dans le dernier chapitre du rapport.

Pour finir, et avant de citer les perspectives du projet, nous pouvons dire que ce stage au niveau de SONELGAZ nous a permis d’acquérir une très bonne expérience professionnelle et d’évoluer dans un domaine qui nous était totalement inconnu à savoir le domaine des systèmes décisionnels, et au sein d’un environnement regroupant des équipes de professionnels du métier représentant la filiale « ELIT ».

Comme un projet Data Warehouse n’est jamais complètement terminé, nous pouvons citer les perspectives et les développements suivants :

• Suivre le déploiement actuel et recueillir les correctifs et remarques des utilisateurs.

• Etendre le déploiement de manière à couvrir, à terme, la totalité du territoire national.

• Etendre le système vers d’autres systèmes opérationnels notamment les systèmes de

la HP/HT et de la ressource humaine.

• Utilisation des méthodes et algorithmes de Data Mining pour une meilleure

exploitation des données.

• Continuer le développement du portail de restitution.

Page 153: Conception et Réalisation d'un Data Warehouse

145

Bibliographie

Ouvrages

[Bouquin, 2003] : Bouquin Henry ; « Le contrôle de gestion » ; P.U.F ; 2003.

[Dresner, 2001] : H. Dresner ; « BI : Making the Data Make Sens » ; Gartner Group 2001.

[Franco, 1997] : Jean-Michel Franco; « Le Data Warehouse, le Data Mining » ; Eyrolles

1997.

[Goglin, 1998] : J.F. Goglin; « La Construction du Datawarehouse : du Datamart au

Dataweb »; Hermes 1998.

[Inmon, 2002]: W. H. Inmon ; « Building the Data Warehouse Third Edition» ; Wiley

Computer Publishing 2002.

[Kimball, 2004] : R. Kimball et J. Caserta ; « The Data warehouse ETL Toolkit» ;Wiley

Publisshing, INC 2004

[Kimball, 2002] : R. Kimball et M. Ross ; « Entrepôts de Données : Guide Pratique de

Modélisation Dimensionnelle 2ème édition » ; Vuibert 2002.

[Kimball,1996] : R. Kimball ; « Entrepôts de données : Guide pratique du concepteur de

Data Warehouse » ;Wiley Computer Publishing 1996.

[Le Moigne, 1977] : Le Moigne J.L., « La théorie du système général, théorie de la

modélisation », P.U.F., 1977.

[Nakache, 1998] : Didier Nakache; « Data Warehouse et Data Mining »; Conservatoire

National des Arts et Métiers de Lille; Version 1.1; 15 juin 1998.

Page 154: Conception et Réalisation d'un Data Warehouse

146

Articles et Thèses

[Bouzghoub, 2008] : Abdenour Bouzghoub ; « Modélisation des Entrepôts de données XML : Application au domaine de la sécurité sociale » ; Thèse de Magistère Option : SISCSD ; Institut National de Formation en Informatique (I.N.I) 2008.

[Chouder, 2007] : Lamri Chouder ; « Entrepôt Distribué de Données » ; Thèse de Magistère Option : SI; Institut National de Formation en Informatique (I.N.I) 2007.

[Chuck, 1998] : Chuck Ballard, Dirk Herreman, Don Schau, Rhonda Bell, Eunsaeng Kim, Ann Valencic; Data Modeling Techniques for Data Warehousing; International Technical Support Organization; http://www.redbooks.ibm.com; février 1998.

[Codd, 93] : E. F. Codd ; « Providing OLAP (On-Line Analytical Processing) to User- Analysts : an IT mandate. » ; Technical report ; E.F. Codd & Associates; 1993.

[Daan, 2007] : Daan Van Beck, Norman Manley, The ETL product survey 2007, A passionned International research paper, 2007.

[Favre, 2008] : Cécile Favre; «Évolution de schémas dans les entrepôts de données»; Thèse de doctorat ; Université Lumière Lyon 2 «École Doctorale Informatique et Information pour la Société» ; Décembre 2007.

[Haciane, 2006] : Ahmed Haciane ; « Conception d’un datawarehouse Orienté CRM »; Thèse de magistère Option : SI ; Institut National de Formation en Informatique (I.N.I); 2006.

[Hugh, 2009] : Hugh Watson, Dorothea L. Abraham, Daniel Chen, David Preston; Dominic Thomas,Data Warehousing ROI: Justifying and Assessing a Data Warehouse; http://www.bi-bestpractices.com/view-articles/4780; 2009.

[Inmon, 2000]: B. Inmon; What is a Data Warehouse; Article; http://www.billinmon.com; 2000.

[Inmon, 1998]: B. Inmon ;Data Mart Does Not Equal Data Warehouse; http://www.information- management.com/infodirect/19991120/1675-1.html ;1998.

[Soler, 2001] : Y.Soler; PLANIFICATION ET SUIVI D'UN PROJET ; Centre national de la recherche scientifique Direction des systèmes d'information ; http://www.dsi.cnrs.fr/conduite-

Page 155: Conception et Réalisation d'un Data Warehouse

147

projet/phasedefinition/gestion-de-projet/planification-suivi-projet/guide-planif-suivi-projet.pdf ;2001.