Mmoire de fin dtudes

Pour lobtention du diplme dIngnieur dEtat en Informatique

Option : Systmes dinformation

Thme
Conception et ralisation dun Data Warehouse pour
la mise en place dun systme dcisionnel
Document de base

Ralis par

Encadr par

FILALI ABDERRAHMANE

MERABET SOUAD

KEDJNANE SOFIANE

MEDJAOUI NADJI

Promotion : 2009/2010

Remerciements

Nos remerciements vont tout spcialement 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 indfectible.
Nous tenons aussi, remercier tout les enseignants qui ont contribu de prs ou de loin
notre formation.
Nous remercions Mme Souad Merbet et M. Nadji Medjaoui pour avoir assur
lencadrement de ce projet, qui na pas toujours t de tout repos. On remercie monsieur
Medjaoui pour nos sances de travail agrables 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 lopportunit de travailler sur un projet dune tel envergure.
Nous remercions Mme Ait Ali Yahia pour ces critiques constructives qui nous ont
permis damliorer ce mmoire.
Nous nous devons de mentionner la prcieuse et totale collaboration que nous avons
reu au sein de ELIT, de part les moyens mis notre disposition et laide et le support apport
par lensemble des employs et des cadres.
On remercie vivement Mesdames et Messieurs les membres du jury davoir accepter
dvaluer ce travail.
Pour finir, et afin de noublier personne (amis, membre de la famille et tous ceux qui
nous sont chers) nous utiliserons la formule : Merci .

^xw}tx 9 Y|t|

Ddicaces
Je ddie ce modeste travail :
M es parents, qui nont jamais cess de mencourager et me soutenir,
M on frre : M oham med, et m es surs :A mina et Soum ia
M on binm e et ami Sofiane et sa famille,
M es amis : Amine, M ouhata, M oham med, Lotfi
Tous les m embres de ma famille,
Ceux qui me sont chers,
M on cousin : Samir, puisse dieu laccueillir dans son vaste paradis.

Tuwxt{tx

Ddicaces

A:
M es parents, pour leur soutient indniable et leur aide prcieuse
Pourrais-je jamais vous dire tous mon am our,
M a grand-mre, pour sa patience et pour avoir su me supporter,
M a sur Linda, et mes frres Tareq et Yacine, pour leurs
encouragements et leur amour,
Tous les m embres de la famille, pour lintrt quils mont montr,
M on binme (et ami) Abderrahmane H amza et toute sa famille,
pour ce quils mont apport,
M es amis, pour tous ce quon a partag ensemble,
Toutes les personnes proches que je nai pas cites
Je ddie ce travail.

fy|tx

Sommaire
Rsum :..I
Abrviations :.II
Liste des tableaux .IV
Liste des figures ...VI
Introduction gnrale ................................................................................................................. 9
1. Problmatique .............................................................................................................. 10
2. Objectifs du projet ........................................................................................................ 11

Partie I: Synthse Bibliographique.

I.

Introduction ...................................................................................................................... 15
I.1.

Les systmes dcisionnels ........................................................................................ 15

I.1.1. La place du dcisionnel dans lentreprise .............................................................. 16

I.1.2. Les diffrents composantes du dcisionnel ............................................................ 17
I.2.

Dcisionnel vs transactionnel ................................................................................... 18

II. Le Data Warehouse .......................................................................................................... 19

II.1

Quest ce quun Data Warehouse ............................................................................. 19

II.2

Historique des Data Warehouse ............................................................................... 20

II.3

Structure des donnes dun Data Warehouse ........................................................... 21

II.4

Les lments dun Data Warehouse ......................................................................... 22

II.5

Architecture dun Data Warehouse .......................................................................... 25

III. Modlisation des donnes de lentrept ........................................................................... 26

III.1

La modlisation 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

Diffrents modles de la modlisation dimensionnelle ............................................. 28

III.3

Le concept OLAP ..................................................................................................... 29

III.3.1

Gnralits ......................................................................................................... 29

III.3.2

Architectures des serveurs OLAP ..................................................................... 29

III.4

La navigation dans les donnes ................................................................................ 31

III.4.1

Slice & Dice ...................................................................................................... 31

III.4.2

Drill-down & Roll-up ......................................................................................... 32

IV. Dmarche de Construction dun Data Warehouse ........................................................... 34

IV.1 Modlisation et conception du Data Warehouse ...................................................... 34
IV.1.1

Approche Besoins danalyse ....................................................................... 34

IV.1.2

Approche Source de donnes ...................................................................... 35

IV.1.3

Approche mixte ................................................................................................. 36

IV.2 Alimentation du Data Warehouse.............................................................................. 37

IV.2.1

Les phases de lalimentation E.T.L. ............................................................ 37

IV.2.2

Politiques de lalimentation ............................................................................... 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: Prsentation de l'organisme d'accueil.
I. Prsentation 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 mtier de la distribution .......................................................................................... 50
I.2.1 Organisation des socits de distribution ............................................................... 51
I.2.2 La clientle de la distribution ................................................................................ 52
I.3 Linformatique au sein du groupe SONELGAZ .......................................................... 53
I.3.1 Prsentation de la filiale ELIT ........................................................................ 53
II. Conclusion ....................................................................................................................... 56
Chapitre 2: L'xistant dcisionnel.
I. Introduction ...................................................................................................................... 58
II. Etat du dcisionnel au sein du groupe............................................................................... 58
II.1

Niveau Groupe .......................................................................................................... 58

II.2

Niveau Socit 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 dmarche d'tude des besoins ........................................................... 65
1.

tude prliminaire des systmes sources et interviews sommaires avec les DBA.... 65

2.

Dtection des postes susceptibles d'tre porteur d'informations utiles ...................... 65

3.

Planification, prparation et conduite des interviews ................................................ 66

4.

Autres moyens utiliss pour la dtection des besoins ............................................... 67

5.

Rdaction et validation du recueil rcapitulatif des besoins ..................................... 68

I.2 Problmes et obstacles rencontrs ................................................................................ 69

II. Conclusion ....................................................................................................................... 70
Chapitre 4: Conception de la zone entreposage des donnes .
I. Introduction ...................................................................................................................... 73
II. Processus de la modlisation dimensionnelle .................................................................. 73
II.1

Volet vente ......................................................................................................... 74

II.2

Volet recouvrement ............................................................................................ 89

II.3

Volet suivi des affaires ........................................................................................ 93

II.4

Volet Suivi des abonns ..................................................................................... 99

III. Conclusion ..................................................................................................................... 103

Chapitre 5: Conception de la zone Alimentation .
I. Introduction .................................................................................................................... 105
II. Etude et planification ..................................................................................................... 105
II.1

Les sources de donnes ........................................................................................... 105

II.2

Dtection des emplacements des donnes sources ................................................. 106

II.3

Dfinition de la priodicit de chargement .............................................................. 106

III. Architecture du processus dalimentation ...................................................................... 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 dagrgats .............................................................. 114

V. Conclusion ..................................................................................................................... 115

Chapitre 6: Conception des cubes dimensionnels.
I. Dfinition des niveaux et des hirarchies ...................................................................... 117
II. La liste des cubes ........................................................................................................... 121
III. Prsentation des cubes dimensionnels ........................................................................... 123
IV. Conclusion ..................................................................................................................... 123
Chapitre 7: Conception des Meta Data.
I. Les Meta Data ou mta donnes de lentrept ................................................... 129
II. Rle des mta donnes ................................................................................................... 129
III. Exploitation des mtas donnes ..................................................................................... 133
III.1 Prsentation de la partie navigation ....................................................................... 133

III.2 Prsentation de la partie supervision ...................................................................... 133

IV. Conclusion ..................................................................................................................... 133
Partie III: Implmentation et dploiement.
Introduction .................................................................................................................... 135

I.

II. Implmentation .............................................................................................................. 135

II.1

Primtre technique et fonctionnel ......................................................................... 135

II.1.1 Matriel ............................................................................................................... 135

II.1.2 Systmes dexploitation ...................................................................................... 135
II.2

Architecture technique de la solution ..................................................................... 136

II.3

Zone de stockage .................................................................................................... 136

II.4

Zone dalimentation de lentrept ........................................................................... 137

II.5

Zone de restitution .................................................................................................. 137

III. Dploiement ................................................................................................................... 139

III.1

Dploiement de la zone dalimentation .................................................................. 139

III.2

Dploiement de la zone de restitution .................................................................... 140

IV.

Conclusion ...141

Conclusion gnrale et perspectives ...142

Bibliographie ........................................................................................................................ 145

Rsum :
Le groupe SONELGAZ, premier oprateur nergtique en Algrie, assure plusieurs missions
dans le domaine de lnergie. Ces dernires, allant de la gestion du rseau lectrique et gazier
la distribution et commercialisation de llectricit et du gaz au profit tant des professionnels
que des particuliers, font de SONELGAZ un acteur incontournable de lconomie nationale.
Le groupe SONELGAZ rencontre, dans le cadre de son activit de distribution, quelques
problmes dans sa politique de Reporting clientle. Ces difficults sont lies notamment la
lenteur et au cot de la procdure, du fait du nombre important dintermdiaires et/ou
intervenants. Ces difficults ont rendu tout effort danalyse vain ; et cest pourquoi les
dirigeants du groupe aspirent la mise en place dun systme qui procure aux dcideurs les
informations ncessaires et fiables, les aidant ainsi pendre dans les meilleurs dlais les
dcisions les plus appropries. Dans ce contexte, et afin de rpondre ces attentes
grandissantes le groupe a sollicit sa filiale spcialise dans les systmes dinformation et les
nouvelles technologies Elit .
Le But recherch tant daller vers la mise en place dun systme sinscrivant dans le cadre
du Systme de Gestion de la Clientle S.G.C . Ce systme sera construit autour dune
base de donnes ddie totalement aux dcisionnel un Data Warehouse et rpondant
tout les besoins danalyse du groupe dans sa fonction de distribution. Ce prsent projet a donc
pour vocation premire de raliser une telle base de donnes.
Mots cls : Data Warehouse Entrept de donnes , Dcisionnel, Business Intelligence
B.I , intgration de donnes, solutions BI Open Source.

Abrviations :
BI : Business Intelligence.
BT : Basse Tension.
BP : Basse Pression.
CTI : Centre de Traitement Informatique.
DAP : Direction Analyses et Prvision.
DAR : Direction Affaires De Rgulation.
DBA : Data Base Administrator.
DCF : Direction Comptabilit et Finance.
DCM: Direction Commercial Et Marketing.
DD : Direction de Distribution.
DED : Dpartement Etudes et Dveloppement.
DGDS : Direction Gnrale du Dveloppement et de la Stratgie.
DIM : Dimension.
DR : direction rgionale(DD).
DRD : Direction de Distribution Rgionale.
DW : Data Warehouse (Entrept de donnes).
ED : Etude et dveloppent.
EDW : Entreprise Data Warehouse.
EGA : Electricit et Gaz dAlgrie.
ELIT : EL-djazar Information Technology.
EPIC : Etablissement Publique caractre Industriel et Commercial.
ETL : Extract, Transform and Load (ETC).
FK: Foreign Key.
FTP : File Transfer Protocol.
HOLAP: Hybrid On Line Analytical Process.
HP : Haute Pression.
HT : Haute Tension.
MOLAP: Multidimensional On Line Analytical Process.
MP: Moyenne Pression.
MT : Moyenne Tension.
OLAP : On Line Analytical Process.
OLTP: On Line Transactional Process.
II

PDG: Prsident Directeur General.

PK : Primary Key.
ROLAP : Relational On Line Analytical Process.
SD : Socit de Distribution.
SGC : Systme de Gestion de la Clientle.
SI : Systmes dInformation.
SID: Systmes dInformation Dcisionnels.
SID : Systmes dinformation de la distribution.
SIAD : Systmes dInformation dAide la Dcision
SGBD : Systme de Gestion de Base de Donnes.
SMTP : Server Mail Transfer Protocol.
SONELGAZ : Socit Nationale de lElectricit et du GAZ.
SPA : Socit Par Action.
SQL : Structured Query Language.

III

Liste des tableaux

Partie I : Synthse Bibliographique.

Tableau I.1 : Tableau comparatif entre les systmes transactionnels et les systmes
dcisionnels... ............................................................................................................................. 6
Tableau I.2 : Tableau comparatif entre les tables de faits et les tables de dimensions............ 16
Tableau I.3 : Avantages et inconvnients de lapproche Besoins danalyse ..................... 23
Tableau I.4 : Avantages et inconvnients de lapproche Sources de donnes ................... 24

Partie II: Conception de la solution.

Tableau II.1 :

Le groupe SONELGAZ en chiffres ................................................................ 38

Tableau II.2 :

Prsentation des socits de distribution ........................................................ 40

Tableau II.3 :

Tableau prsentant la population a interview ............................................... 54

Tableau II.4 :

Synthtisation des besoins dtects ................................................................ 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 gographique ........................... 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 agrgats potentiels de lactivit Vente ...................................... 75
Tableau II.13 : Liste des agrgats utiles de lactivit Vente ............................................ 75
Tableau II.14 : Dtection 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 agrgats potentiel du modle Recouvrement ....... 79
Tableau II.17 : Tableau descriptif des agrgats utiles du modle Recouvrement ............. 79
Tableau II.18 : Dtection 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 agrgats potentiel du modle suivi des affaires .... 85
Tableau II.23 : Tableau descriptif de des agrgats utiles du modle Suivi des affaires .... 85
Tableau II.24 : Dtection des dimensions communes entre les volets Vente ,
Recouvrement , Suivi des affaires et suivi des abonns . ......................................... 86
Tableau II.25 : Tableau descriptif de la dimension Type abonn ..................................... 87
IV

Tableau II.26 : Tableau descriptif des agrgats potentiels du modle Suivi abonns ....... 89
Tableau II.27 : Tableau descriptif des agrgats utiles du modle Suivi abonns .............. 89
Tableau II.28 : Tableau donnant les nivaux hirarchiques de chaque dimension ................... 10
Tableau II.29 : Listes des cubes dimensionnels .................................................................... 107

Liste des figures

Figure I.1 :

Le dcisionnel au sein du systme dinformation ............................................ 9

Figure I.2 :

Les diffrentes composantes du dcisionnel .................................................... 5

Figure I.3 :

Historique des bases de donnes dcisionnelles ............................................... 8

Figure I.4 :

Structure des donnes dun Data Warehouse ................................................... 9

Figure I.5 : Les Data Mart dans un entrept de donnes selon larchitecture propose par
B. Inmon dite Entreprise Data Warehouse ........................................................................... 11
Figure I.6 : Les Data Mart dans un entrept de donnes selon larchitecture propose par
R. kimball dite approche bus ................................................................................................ 13
Figure I.7 :

Architecture globale dun Data Warehouse.................................................... 13

Figure I.8 :

Considration dun sujet danalyse comme un cube plusieurs dimensions . 14

Figure I.9 :

Un modle dimensionnel typique ................................................................... 15

Figure I.10 : Principe de larchitecture MOLAP ................................................................. 18

Figure I.11 : Principe de larchitecture 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 lapproche Besoin danalyse grce au cycle de vie
dimensionnel de kimball ....................................................................................................... 22
Figure I.17 : Illustration de lapproche source de donnes grce au cycle de
dveloppement du Data Warehouse de Inmon ..................................................................... 23
Figure I.18 : Illustration de lapproche mixte ...................................................................... 24
Figure I.19 : Objectif de qualit de donnes dans un processus E.T.L ............................... 27
Figure II.1 : Planification de la conduite du projet ............................................................. 34
Figure II.2 : Organigramme reprsentant lorganisation du Groupe SONELGAZ ............ 37
Figure II.3 : Evolution du chiffre daffaire du groupe publie dans le rapport dactivit de
lanne 2008 38
Figure II.4 : Rpartition du chiffre daffaire publie dans le rapport dactivit de lanne
2008 ...................................................................................................................... 39
Figure II.5 : Organisation des socits 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 dtude et de dveloppement............................. 44
Figure II.9 : Diagramme dactivit modlisant ldition de rapport pour le niveau groupe48

VI

Figure II.10 : La place de ltape de dfinition des besoins dans un projet Data
Warehouse.52
Figure II.11 :

Analyse des priorits du cas de la distribution SONELGAZ ................ 60

Figure II.12 :

La dimension du Temps de lactivit Vente ......................................... 64

Figure II.13 :

La dimension client de lactivit Vente ................................................ 65

Figure II.14 :

La dimension facture de lactivit Vente .............................................. 68

Figure II.15 :

La dimension zone de lactivit Vente .................................................. 70

Figure II.16 :

La dimension activit de lactivit Vente ............................................. 70

Figure II.17 :

La dimension Tarif de lactivit Vente ................................................. 70

Figure II.18 :

La dimension nergie de lactivit Vente ............................................. 71

Figure II.19 :

Modle en toile de lactivit Vente ..................................................... 74

Figure II.20 :

La dimension Nature de lactivit Recouvrement ................................. 78

Figure II.21 :

Modle en toile de lactivit Recouvrement ....................................... 79

Figure II.22 :

La dimension affaire de lactivit Suivi des affaires .............................. 83

Figure II.23 :

La dimension type affaire de lactivit Suivi des affaires ..................... 82

Figure II.24 :

La dimension phase de lactivit suivie des affaires ............................. 83

Figure II.25 :

Modle en toile de lactivit Suivie des affaires ................................. 84

Figure II.26 :

La dimension type abonn de lactivit Suivi des abonn .................... 87

Figure II.27 :

Modle en toile de lactivit Suivi des abonn ................................... 88

Figure II.28 :

Architecture global du processus E.T.L ...................................................... 95

Figure II.29 :

Diagramme dactivit du processus dalimentation .................................... 94

Figure II.30 :

Diagramme dactivit du processus de chargement de dimension ............. 98

Figure II.31 :

Diagramme dactivit 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 abonns . ............................................... 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 mtadonnes .................................................... 115

Figure II.38 : DCU navigation dans les mtadonnes 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 dploiement de la zone dalimentation. ............................. 125

Figure II.42 :

Diagramme de dploiement de la zone de restitution. .............................. 126

VII

Introduction gnrale

Contexte gnral
Cest dans un environnement fortement complexe et hautement concurrentiel
quvolue la majeure partie, si ce nest la totalit, des entreprises. Ce climat de forte
concurrence exige de ces entreprises une surveillance trs troite du march afin de ne pas se
laisser distancer par les concurrents et cela en rpondant, le plus rapidement possible, aux
attentes du march, de leur clientle et de leurs partenaires.
Pour se faire, les dirigeants de lentreprise, quelque en soit dailleurs le domaine
dactivit, doivent tre en mesure de mener bien les missions qui leur incombent en la
matire. Ils devront prendre notamment les dcisions les plus opportunes. Ces dcisions, qui
influeront grandement sur la stratgie de lentreprise et donc sur son devenir, ne doivent pas
tre prises ni la lgre, ni de manire trop htive, compte tenu de leurs consquences sur la
survie de lentreprise. Il sagit de prendre des dcisions fondes, bases sur des informations
claires, fiables et pertinentes. Le problme est de savoir donc comment identifier et prsenter
ces informations qui de droit, sachant par ailleurs que les entreprises croulent dune part
sous une masse considrable de donnes et que dautre part les systmes oprationnels
transactionnels savrent limits, voire inaptes fournir de telles informations et
constituer par la mme un support apprciable la prise de dcision.
Cest dans ce contexte que les systmes dcisionnels ont vu le jour. Ils offrent
aux dcideurs des informations de qualit sur lesquelles ils pourront sappuyer pour arrter
leurs choix dcisionnels. Pour se faire, ces systmes utilisent un large ventail de technologies
et de mthodes, dont les entrepts de donnes (Data Warehouse) reprsentent llment
principal et incontournable pour la mise en place dun bon systme dcisionnel.
De part sa dimension conomique et sa position sur le march nergtique algrien,
lactivit journalire de la SONELGAZ gnre des donnes complexes et volumineuses. Ces
donnes reprsentent une source prcieuse dinformations, qui serait mme damliorer de
faon significative le processus de prise de dcision. Cependant, ces donnes ne sont pas
exploites de manire satisfaisante, hypothquant ainsi le processus de prise de dcision
tous les niveaux du groupe.
Le prsent projet tend la mise en place dun systme en mesure de consolider les
donnes issues des systmes transactionnels, et doffrir des informations de qualit pour les
dcideurs. Il sagit en fait de mettre la disposition des dcideurs des donnes mme de
les clairer et leur faciliter une prise de dcision prompte en connaissance de cause. Un tel
systme requiert la mise en place dun entrept de donnes fiables contenant les informations
ncessaires laccomplissement des processus dcisionnels.

1. Problmatique
Le groupe SONELGAZ est loprateur historique et leader du domaine nergtique en
Algrie, notamment dans le domaine de la distribution de llectricit et du gaz pour les
professionnels et les particuliers.
Appel interagir avec ses clients sur diffrentes phases de la distribution (demande
de branchement, facturation, rsiliation,etc.), le groupe sest dot, dans un souci de suivi de
la clientle et de gestion de la distribution, dun Systme de Gestion de la Clientle S.G.C. constitu de 35 applications, dveloppes en interne et exploit par plus de 2900
utilisateurs. Ce systme est dploy dans chacune des 58 directions de distributions D.D.
exploitant une base de donne dcentralise au niveau de chaque D.D. .
Dans un pareil contexte, la plus simple des oprations danalyse devient une tche
ardue. En effet, les socits de distributions SD se trouvent dans lincapacit de faire des
analyses fiables, efficaces et des moments opportuns sans engager des moyens considrables
sur des priodes plus ou moins longues. Ainsi, les principales difficults rencontres peuvent
tre rsumes en :

Difficults dans llaboration des rapports dactivit :

Llaboration des rapports
dactivit fait intervenir, gnralement, plusieurs
intermdiaires. En effet, chaque fois quil est ncessaire dlaborer un rapport
dactivit , il faudra procder dabord l extraction les donnes partir des 58 bases de
donnes installes au niveau des directions de distribution, pour les acheminer ensuite
manuellement vers une structure centralise, qui en fera enfin la consolidation. Il sagit l
dune procdure lourde outre les ventuelles incohrences et erreurs. Les retards
enregistrs, parfois, font que le rapport dactivit est labor sur la base dune
consolidation antrieure, en sachant pertinemment que les donnes ne sont pas jour.

Lenteur de la procdure de Reporting : La politique de Reporting actuelle, qui du reste

est quasi manuelle, connait des lenteurs qui narrangent pas les dcideurs. Ceux ci ont
besoin dinformations fiables et dans des dlais raisonnables. titre indicatif, ldition
dun rapport national peut prendre, en moyenne, plus dun mois ce qui est plus que
pnalisant pour une bonne prise de dcision.

Cot de la procdure de Reporting1 : la procdure de Reporting est jug trs couteuse

pour lentreprise, et cela est principalement du au nombre dintervenant et des moyens mis
en place pour cette dernire.
Insuffisance du module Statistique : Afin de produire et offrir un moyen de suivi des
activits de la distribution, un module Statistique a t dvelopp et intgr dans le
systme SGC . Ce dernier fournit des tats statistiques permettant, aux dcideurs de
niveau D.D., lanalyse et la prise de dcision. Cependant, ce module connait quelques

Voir annexe A
10

problmes d au fait quil interroge directement la base de donnes en production. En

effet le lancement de la production de nimporte quel rapport du module pnalise le
systme. Pour viter cela le module nest accessible quau chef du CTI de la DD.

2. Objectifs du projet
Afin de palier aux problmes prcdemment cits, le groupe a initi, travers sa filiale
Elit, le prsent projet.
Ce projet a pour but dintroduire, en premier lieu, une informatique dcisionnelle au
sein du groupe, tout en confrant aux dcideurs un support fiable pour une meilleure prise de
dcision. Ainsi, les principaux objectifs assigns au projet sont :

La rduction de la dure globale de llaboration des rapports, en essayant de ramener

cette dure, au moins, en dessous de la barre des 48 heures.

La Rduction des cots de la procdure de Reporting actuelle.

La rduction du nombre dintervenants lors de la production de rapports.

Offrir aux dcideurs et aux analystes la possibilit de faire des analyses appropries.

Offrir des informations fiables, cohrentes et pertinentes, contenant la logique

business souhaite.

11

Planification et conduite du projet

Linitiation de tout
out projet ncessite une phase de planification. Celle
Celle-ci permet
de dfinir les tches raliser, matriser les risques et rendre compte de ltat davancement
du projet.
Planifier optimise ainsi les chances de russite d'un projet en amliorant la
productivit grce une meilleure matrise de la qualit. [Soler, 2001].
Pour garantir le bon droulement du projet, tout en respectant les dlais, nous avons
labor une planification globale de conduite du projet. Le diagramme suivant dcrit cette
planification ainsi que lordonnancement prvu des phases du projet.

Conception E.T.L

Figure : Planification et conduite du projet.

Afin de prsenter notre travail, le prsent mmoire est organis en trois parties et se
prsente comme suit :
Aprs une introduction gnrale dans laquelle nous prsentons le contexte gnral du
projet, ainsi que la problmatique et les objectifs viss. La premire partie prsente les aspects
thoriques du domaine des systmes dinformation daide la dcision, en voquant leurs
dfinitions et les concepts de bases relatifs aux entrepts de donnes et la modlisation
dimensionnelle.

12

Dans la deuxime partie, nous prsentons le travail ralis au sein du Groupe

SONELGAZ travers les six suivants chapitres:
Le chapitre un, prsente lorganisme daccueil, sa structure organisationnelle, son
activit et la culture de lentreprise en matire dutilisation des technologies de linformation.
Le chapitre deux a pour vocation de prsenter lexistant dcisionnel au sein de
lentreprise et selon diffrents niveaux de prise de dcision.
Le chapitre trois prsente une synthse de la collecte des besoins des utilisateurs, ainsi
que son droulement.
Le chapitre quatre contient la conception de la partie dentreposage de notre solution.
Il prsente entre autre les modles dimensionnels des activits recenses.
Le chapitre cinq pour but de prsenter la conception de la zone dalimentation, ainsi
que les stratgies adoptes.
Le chapitre six, quant lui, donne la conception des cubes dimensionnels en dtaillant
les diffrentes caractristiques de chaque cube (dimensions, mesurables et hirarchies).
La troisime partie dcrie larchitecture globale de la solution, et cela en prsentant les
diffrents outils intgrs et les volets de la solution dvelopps. Elle dcrit aussi la manire
dont se passe le dploiement de la solution.
Une conclusion gnrale est propose afin de synthtiser le travail ralis et de citer
les perspectives du projet.

13

Partie I :
Synthse
bibliographique
Un entrept de donnes ne s'achte pas, il se construit.
Bill Inmon

14

I.

Introduction

Toutes les entreprises du monde disposent dune masse de donnes plus ou moins
considrable. Ces informations proviennent soit de sources internes (gnres par leurs
systmes oprationnels au fil des activits journalires), ou bien de sources externes (web,
partenaire, .. etc.).
Cette surabondance de donnes, et limpossibilit des systmes oprationnels de les
exploiter des fins danalyse conduit, invitablement, lentreprise se tourner vers une
nouvelle informatique dite dcisionnelle qui met laccent sur la comprhension de
lenvironnement de lentreprise et lexploitation de ces donnes bon escient.
En effet, les dcideurs de lentreprise ont besoin davoir une meilleure vision de leur
environnement et de son volution, ainsi, que des informations auxquelles ils peuvent se fier.
Cela ne peut se faire quen mettant en place des indicateurs business clairs et pertinents
permettant la sauvegarde, lutilisation de la mmoire de lentreprise et offrant ses dcideurs
la possibilit de se reporter ces indicateurs pour une bonne prise de dcision.
Le Data Warehouse , Entrept de donnes en franais, constitue, dans ces
conditions, une structure informatique et une fondation des plus incontournables pour la mise
en place dapplications dcisionnelles.
Le concept de Data Warehouse, tel que connu aujourdhui, est apparu pour la premire
fois en 1980 ; lide consistait alors raliser une base de donnes destine exclusivement au
processus dcisionnel. Les nouveaux besoins de lentreprise, les quantits importantes de
donnes produites par les systmes oprationnels et lapparition des technologies aptes sa
mise en uvre ont contribu lapparition du concept Data Warehouse comme support
aux systmes dcisionnels.

I.1. Les systmes dcisionnels

La raison dtre dun entrept de donnes, comme voqu prcdemment, est la mise en
place dune informatique dcisionnelle au sein de lentreprise. Pour cela il serait assez
intressant de dfinir quelques concepts cls autour du dcisionnel.
Afin de mieux comprendre la finalit des systmes dcisionnels, nous nous devons de les
placer dans leurs contextes et rappeler ce quest un systme dinformation.
Le systme dinformation est lensemble des mthodes et moyens de recueil de contrle
et de distribution des informations ncessaires lexercice de lactivit en tout point de
lorganisation. Il a pour fonction de produire et de mmoriser les informations, de lactivit
du systme oprant (systme oprationnel), puis de les mettre disposition du systme de
dcision (systme de pilotage)[Le Moigne, 1977].
Les diffrences qui existent entre le systme de pilotage et le systme oprationnel, du
point de vue fonctionnel ou des tches effectuer, conduit lapparition des systmes
dinformation dcisionnels (S.I.D.). Ces diffrences seront clairement illustres un peu plus
loin dans notre document.
15

Les origines des SID remontent au dbut de linformatique et des systmes dinformation
qui ont, tous deux, connu une grande et complexe volution lie notamment la technologie.
Cette volution se poursuit ce jour2.
Parmi les diffrentes dfinitions du dcisionnel business intelligence B.I. qui ont t
donnes on trouve :

"Le Dcisionnel est le processus visant transformer les donnes en informations et,
par l'intermdiaire d'interrogations successives, transformer ces informations en
connaissances." [Dresner, 2001].

I.1.1. La place du dcisionnel dans lentreprise:

Figure I.1 : Le dcisionnel

nnel au sein du Systme dinformation [Goglin, 1998]
1998].
La figure ci-dessus
dessus illustre parfaitement la place qui
qu revient au dcisi
dcisionnel au sein
dune entreprise. Cette place,, comprend plusieurs fonctions cls de lentreprise. Les finalits
dcisionnelles, tant diffrentes selon le poste et la fonction occupe,
occupe on
ont pour but
dengendrer plusieurs composantes.

Synthtisation partir de la thse de Bouzghoub A. Modlisation des entrepts de donnes XML:

application au domaine de la scurit sociale [Bouzghoub, 2008].
16

I.1.2. Les diffrentess composantes du dcisionnel

En relation troite avec les nouvelles technologies de linformation et des
tlcommunications, le systmee dcisionnel se manifeste diffrents niveaux selon leurs
utilits et leurs missions principales,
principales comme illustr dans la figure suivante :

Figure I.2 :

Les diffrentes composantes du dcisionnel [Goglin, 1998]

1998].

17

I.3. Dcisionnel vs transactionnel

Le tableau suivant rsume de faon non exhaustive les diffrences quil peut y avoir
entre les systmes transactionnels et les systmes dcisionnels selon les donnes et lusage fait
des systmes.

par les donnes

Diffrence

Systmes transactionnels

SID

Orient applications

Orient thmes et sujets

Situation instantane

Situation historique

Donne dtailles et codes non Informations

agrges

cohrentes

redondantes

souvent avec redondance

Donnes changeantes constamment

Informations stables et synchronises

dans le temps

Pas de rfrentiel commun

Un rfrentiel unique

Assure lactivit au quotidien

Permet lanalyse et la prise de

Lusage

dcision
Pour les oprationnels

Pour les dcideurs

Mises jour et requtes simples

Lecture unique et requtes complexes

transparentes

Temps de rponse immdiats

Temps de rponse moins critiques

Faibles volumes chaque transaction

Large volume manipul

Conu pour la mise jour

Conue pour lextraction

Usage matris

Usage alatoire

Tableau I.1 : Tableau comparatif entre les systmes transactionnels et les systmes
dcisionnels.
Ces diffrences font ressortir la ncessit de mettre en place un systme rpondant aux
besoins dcisionnels. Ce systme nest rien dautre que le Data Warehouse .

18

II.

Le Data Warehouse

II.1

Quest ce quun Data Warehouse

Bill Inmon dfinit le Data Warehouse, dans son livre considr comme tant la rfrence
dans le domaine Building the Data Warehouse [Inmon, 2002] comme suit:
Le Data Warehouse est une collection de donnes orientes sujet, intgres, non
volatiles et volutives dans le temps, organises pour le support dun processus daide
la dcision.
Les paragraphes suivants illustrent les caractristiques cites dans la dfinition dInmon.
Orient sujet : le Data Warehouse est organis autour des sujets majeurs de lentreprise,
contrairement lapproche transactionnelle utilise dans les systmes oprationnels, qui sont
conus autour dapplications et de fonctions telles que : cartes bancaires, solvabilit client,
les Data Warehouse sont organiss autour de sujets majeurs de lentreprise tels que : clientle,
ventes, produits. Cette organisation affecte forcment la conception et limplmentation des
donnes contenues dans le Data Warehouse. Le contenu en donnes et en relations entre elles
diffre aussi. Dans un systme oprationnel, les donnes sont essentiellement destines
satisfaire un processus fonctionnel et obit des rgles de gestion, alors que celles dun Data
Warehouse sont destines un processus analytique.
Intgre : le Data Warehouse va intgrer des donnes en provenance de diffrentes sources.
Cela ncessite la gestion de toute incohrence.
Evolutives dans le temps : Dans un systme dcisionnel il est important de conserver les
diffrentes valeurs dune donne, cela permet les comparaisons et le suivi de lvolution des
valeurs dans le temps, alors que dans un systme oprationnel la valeur dune donne est
simplement mise jour. Dans un Data Warehouse chaque valeur est associe un moment
Every key structure in the data warehouse contains - implicitly or explicitly -an element of
time [Inmon, 2000].
Non volatiles : cest ce qui est, en quelque sorte la consquence de lhistorisation dcrite
prcdemment. Une donne dans un environnement oprationnel peut tre mise jour ou
supprime, de telles oprations nexistent pas dans un environnement Data Warehouse.
Organises pour le support dun processus daide la dcision : Les donnes du Data
Warehouse sont organises de manire permettre lexcution des processus daide la
dcision (Reporting, Data Mining).

19

II.2

Historique des Data Warehouse

Lorigine du concept Data Warehouse D.W (entrept de donnes en franais) remonte

aux annes 80, durant lesquelles un intrt croissant au systme dcisionnel a vu le jour, d
essentiellement lmergence des SGBD relationnel et la simplicit du modle relationnel et
la puissance offerte par le langage SQL,
Au dbut, le Data Warehouse ntait rien dautre quune copie des donnes du systme
oprationnel prise de faon priodique, ddie un environnement de support la prise de
dcision. Ainsi, les donnes taient extraites du systme oprationnel, stockes dans une
nouvelle base de donnes concept dinfocentre , le motif principal tant de rpondre aux
requtes des dcideurs sans pour autant altrer les performances des systmes oprationnels.
Le Data Warehouse, tel quon le connat actuellement, nest plus vu comme une copie
-ou un cumul de copies prises de faon priodique- des donnes du systme oprationnel. Il
est devenu une nouvelle source dinformation, aliment avec des donnes recueillies et
consolides des diffrentes sources internes et externes.

Entrept de
donnes
Infocentre

bases de
donnes
oprationnelles

1970

Figure I.3 :

1980

1990

volution des bases de donnes dcisionnelles.

20

II.3

Structure des donnes dun Data Warehouse

Le Data Warehouse a une structure bien dfinie, selon diffrents niveaux dagrgation
et de dtail des donnes. Cette structure est dfinie par Inmon [Inmon, 2000] comme suit :

Donnes fortement agrges

M
E
T
A
D
O
N
N

E
S

Donnes agrges

Donnes dtailles

Donnes dtailles archives

Figure I.4 :

Structure des donnes dun Data Warehouse.

Donnes dtailles : ce sont les donnes qui refltent les vnements les plus rcents,
frquemment consultes, gnralement volumineuses car elles sont dun niveau dtaill.
Donnes dtailles archives : anciennes donnes rarement sollicites, gnralement
stockes dans un disque de stockage de masse, peu coteux, un mme niveau de dtail que
les donnes dtailles.
Donnes agrges : donnes agrges partir des donnes dtailles.
Donnes fortement agrges : donnes agrges partir des donnes dtailles, un niveau
dagrgation plus lev que les donnes agrges.
21

Meta donnes : ce sont les informations relatives la structure des donnes, les mthodes
dagrgation et le lien entre les donnes oprationnelles et celles du Data Warehouse. Les
mtadonnes doivent renseigner sur :

Le modle de donnes,

La structure des donnes telle quelle est vue par les dveloppeurs,

La structure des donnes telle quelle est vue par les utilisateurs,

Les sources des donnes,

Les transformations ncessaires,

Suivi des alimentations,

II.4

Les lments dun Data Warehouse

Lenvironnement du Data Warehouse est constitu essentiellement de quatre

composantes : les applications oprationnelles, la zone de prparation des donnes, la
prsentation des donnes et les outils daccs aux donnes.
Les applications oprationnelles : ce sont les applications du systme oprationnel de
lentreprise et dont la priorit est dassurer le fonctionnement de ce dernier et sa performance.
Ces applications sont extrieures au Data Warehouse.
Prparation des donnes : la prparation englobe tout ce quil y a entre les applications
oprationnelles et la prsentation des donnes. Elle est constitue dun ensemble de processus
appel ETL, Extract, transform and Load , les donnes sont extraites et stockes pour subir
les transformations ncessaires avant leur chargement.
Un point trs important, dans lamnagement dun entrept de donnes, est
dinterdire aux utilisateurs laccs la zone de prparation des donnes, qui ne fournit aucun
service de requte ou de prsentation [Kimball, 2002].
Prsentation des donnes : cest lentrept o les donnes sont organises et stockes. Si les
donnes de la zone de prparation sont interdites aux utilisateurs, la zone de prsentation est
tout ce que lutilisateur voit et touche par le biais des outils daccs.
Lentrept de donnes est constitu dun ensemble de Data Mart. Ce dernier est dfini
comme tant une miniaturisation dun Data Warehouse, construit autour dun sujet prcis
danalyse ou consacr un niveau dpartemental3.
Cette diffrence de construction, autour dun sujet ou au niveau dpartemental, dfinit
la faon dimplmentation du Data Mart au niveau de lentrept. On distingue, en effet, deux
architectures internes du Data Warehouse :

Synthtisation [Chuck, 1998] page 86.

22

1. Data Mart indpendant

Les Data Mart sont des versions miniaturises du Data Warehouse au niveau
dpartemental, alimentess par le Data Warehouse et basess sur les besoins dpartementaux en
informations [Inmon, 2002].

Figure I.5 :

les Data Mart dans un entrept de donnes selon larchitecture Entreprise Data
Warehouse (E.D.W) [Inmon, 2002].

23

2. Data Mart interconnects

Les
es Data Mart sont construits
construi autour de sujets, interconnects grce aux tables des
faits contenues dans le Data Warehouse, ce dernier se compose alors des Data Mart et ces
tables des faits, appeles bus4.

Figure I.6 :

les Data Mart dans un entrept de donnes selon larchitecture bus de donnes
[Kimball, 2002].

Zone doutils daccs : cest lensemble des moyens fournis aux utilisateurs du Data
Warehouse pour exploiter la zone de prsentation des donnes en vue de la prise de dcision.
Ces outils varient des simples requtes ad hoc aux outils permettant lapplication de forage de
donnes plus complexes.. Environ 80 90% des utilisateurs sont desservis par des applications
danalyses prfabriques, consistaant essentiellement en des requtes prtablies.
s.

Appellation propose par R. Kimball dans son ouvrage [Kimball, 2002].

24

II.5

Architecture dun Data Warehouse

Aprs avoir expos et dfini chacun des lments constituant lenvironnement dun Data
Warehouse, il serait intressant de connaitre le positionnement de ces lments dans une
architecture globale dun Data Warehouse :

Figure I.7 : Architecture globale dun Data Warehouse5.

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

III.

Modlisation des donnes de lentrept

III.1

La modlisation dimensionnelle et ses concepts

Les Data Warehouse sont destins la mise en place de systmes dcisionnels. Ces
systmes, devant rpondre des objectifs diffrents des systmes transactionnels, ont fait
ressortir trs vite la ncessit de recourir un modle de donnes simplifi et aisment
comprhensible. La modlisation dimensionnelle permet cela. Elle consiste considrer un
sujet danalyse comme un cube plusieurs dimensions, offrant des vues en tranches ou des
analyses selon diffrents axes.

Figure I.8 :

Considration dun sujet danalyse comme un cube plusieurs dimensions.

En plus de la perception intuitive quoffre la modlisation dimensionnelle, celle-ci est

rpute pour ses performances leves.
La nomination schma des jointures en toile a longtemps t adopte pour dcrire
un modle dimensionnel. Cette nomination est due au fait que le diagramme qui reprsente un
modle dimensionnel ressemble une toile, avec une grande table centrale et un jeu de
petites tables auxiliaires disposes en toile autour de la table centrale. Celle-ci est appele
table de faits et les autres tables sont appeles tables de dimensions. La figure suivante
illustre untel modle :

26

Figure I.9 :

Un modle dimensionnel typique [Kimball, 1996].

III.1.1 Concept de fait

Une table de faits est la table centrale dun modle dimensionnel, o les mesures de
performances sont stockes. Une ligne dune table de faits correspond une mesure. Ces
mesures sont gnralement des valeurs numriques, 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 corrles efficacement avec les
autres attributs textuels de dimensions.
Une table de faits assure les liens plusieurs plusieurs entre les dimensions. Elles
comportent des cls trangres, qui ne sont autres que les cls 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 lactivit. Une table de dimension est constitue de
nombreuses colonnes qui dcrivent une ligne. Cest grce cette table que lentrept de
donnes est comprhensible et utilisable; elles permettent des analyses en tranches et en ds.
Une dimension est gnralement constitue : dune cl artificielle, une cl naturelle et
des attributs.
Une table de dimension tablit linterface homme / entrept, elle comporte une cl
primaire [Kimball, 2002].

27

III.1.3 Comparatif entre les tables de faits et les tables de dimensions

Le tableau suivant rcapitule les diffrences au niveau des donnes de ces tables :
Structure
Donnes
Rfrentiel
Valeur
Manipulation
Signification
Rle

Tables de faits
Peu de colonnes beaucoup de lignes
Mesurable, gnralement numrique
Plusieurs cls trangres
Prend de nombreuses valeurs
Participe des calculs
Valeurs de mesure
Assure les relations entre les
dimensions

Tableau I.2 :

III.2

Tables de dimensions
Peu de lignes beaucoup de colonnes
Descriptives gnralement textuelles
Une cl primaire
Plus ou moins constantes
Participe des contraintes
Descriptive
Assure linterface homme / entrept
de donnes

Tableau comparatif entre les tables de faits et les tables de dimensions.

Diffrents modles de la modlisation dimensionnelle

Modle en toile : comme indiqu prcdemment, ce modle se prsente comme une

toile dont le centre nest autre que la table des faits et les branches sont les tables de
dimension. La force de ce type de modlisation est sa lisibilit et sa performance.
Modle en flocon : identique au modle en toile, sauf que ses branches sont clates
en hirarchies. Cette modlisation est gnralement justifie par lconomie despace de
stockage, cependant elle peut savrer moins comprhensible pour lutilisateur final, et trs
couteuse en terme de performances.
Modle en constellation : Ce nest rien dautre que plusieurs modles en toile lis
entre eux par des dimensions communes.

28

III.3

Le concept OLAP

III.3.1 Gnralits
Le terme OLAP (On-Line Analytical Processing) dsigne une classe de technologies
conue pour laccs aux donnes et pour une analyse instantane de ces dernires, dans le but
de rpondre aux besoins de Reporting et danalyse.
R. Kimball dfinit le concept OLAP comme Activit globale de requtage et de
prsentation de donnes textuelles et numriques contenues dans lentrept de donnes; Style
dinterrogation spcifiquement dimensionnel [Kimball, 2005].
Cest en continuant sur sa lance, qui lui a permis de dfinir le model OLTP pour les
bases de donnes relationnelles, que le concept OLAP fut introduit et dfini6 en 1993 par E.F
Codd, le pre des bases de donnes 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 dun systme OLAP est son serveur. Ces serveurs sont classs selon la politique
rgissant larchitecture du serveur. Ainsi, ces architectures peuvent tre distingues comme
suit:
III.3.2.1

Les systmes architecture MOLAP

Ces systmes MOLAP Multidimentional On-line Analytical Processing sont

conus exceptionnellement pour lanalyse multidimensionnelle.
R. Kimball dfinit ces systmes comme tant un Ensemble dinterfaces utilisateur,
dapplications et de technologies de bases de donnes propritaire dont laspect dimensionnel
est prpondrant [Kimball, 2005].
Ainsi donc cette base adopte rellement la structure multidimensionnelle, exploitant de
ce fait ces capacits au maximum. En effet MOLAP offre des temps daccs optimiss et cela
en prdfinissant les oprations de manipulation et de chemin daccs prdfinis.
Autre caractristique du MOLAP cest quil agrge tout par dfaut, pnalisant du coup
le systme lorsque la quantit de donnes traiter augmente. On parle gnralement de
volume de lordre du giga-octet pas plus.

Cette dfinition passe par lintroduction de 12 rgles. Six autres rgles furent par la suite, en 1995, ajoutes
aux 12 prcdentes et le terme rgles remplac par dispositif features par le mme auteur savoir
Codd (Voir annexe B).
29

Data Warehouse

Donnes

Moteur MOLAP

Traitements

Stockage des
donnes dtailles (et
agrges)

Aide la dcision

Prsentation
Rapports
Multi-Dimensionnel

Figure I.10 :Principe de larchitecture MOLAP [Nakache, 1998].

III.3.2.2

Les systmes architecture ROLAP

Ensemble dinterfaces utilisateurs et dapplications qui donnent une vision

dimensionnelle des bases de donnes relationnelles [Kimball, 2005].
Les systmes ROLAP Relationnel On-line Analytical Processing sont en mesure
de simuler le comportement dune SGBD multidimensionnel en exploitant un SGBD
relationnel. Lutilisateur aura ainsi limpression dinterroger un cube multidimensionnel alors
quen ralit il ne fait quadresser des requtes sur une base de donnes relationnelles.
ROLAP nagrge rien. Les rgles dagrgations sont cres au pralable et reprsentes
dans une table relationnelle ce qui cause une lourdeur dadministration mais confre une
certaine performance et un gage de cohrence lors de lutilisation.
Cette structure est gnralement adopte dans le but de se dispenser de lacquisition
dun SGBD relationnel.

Data Warehouse

Donnes
Stockage des
donnes dtailles (et
agrges) et
des mta-donnes

Figure I.11 :

Moteur ROLAP

Traitements
Gnration de plans
d'excution SQL
afin d'obtenir des
fonctionnalits OLAP.

Aide la dcision

Prsentation
Rapports
Multi-Dimensionnel

Principe de larchitecture ROLAP [Nakache, 1998].

30

III.2.2.3 Les systmes architecture HOLAP

Les systmes HOLAP Hybride On-line Analytical Processing sont une sorte de
compromis entre les diffrents systmes prcits. Cette combinaison donne ce type de
systme les avantages du ROLAP et du MOLAP en utilisant tour tour lun ou lautre selon
le type de donnes.
III.2.2.4 Autres architecture OLAP
Bien que les architectures voques ci-dessus soient les plus rpandues et les plus
adoptes par les fournisseurs de solutions OLAP, dautres systmes se basent sur des
architectures diffrentes telles que larchitecture OOLAP Object On-line Analytical
Processing , ou alors DOLAP Desktop On-line Analytical Processing qui dcrit une
catgorie de produits qui ne sont pas ncessairement connects un serveur et qui sappuient
sur une source de donnes (un cube) construites, stockes et exploites en local sur la machine
de lutilisateur.

III.4

La navigation dans les donnes

Une fois que le serveur OLAP a construit le cube multidimensionnel ou simul ce

cube selon larchitecture du serveur , plusieurs oprations sont possibles sur ce dernier
offrant ainsi la possibilit de naviguer dans les donnes qui le constituent. Ces oprations de
navigation Data Surfing doivent tre, dune part, assez complexes pour adresser
lensemble des donnes et, dautre part, assez simples afin de permettre lutilisateur de
circuler de manire libre et intuitive dans le modle dimensionnel.
Afin de rpondre ces attentes, un ensemble de mcanismes est exploit, permettant
une navigation par rapport la dimension et par rapport la granularit dune 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 donnes par rapport des filtres de dimension bien prcis,
se classant de fait comme des oprations lies la structure se font sur les dimensions . La
diffrence entre eux se manifestent dans le fait que :
Le Slicing consiste faire une slection de tranches du cube selon des prdicats et
selon une dimension filtrer une dimension selon une valeur [Chouder, 2008].

31

Figure I.12
I
:

Exemple de Slicing.

Le Dicing, quant lui, peut tre vu comme tant une extraction dun sous cube.

Figure I.13
I
:

Exemple de Dicing.

III.4.2 Drill-down & Roll-up

up
Ces mthodes, appeles aussi forage vers le bas/vers le haut , sont les mthodes les
plus rpandues pour une navigation dans un entrept de donnes. Elles consistent
reprsenter les donnes du cube un niveau de granularit infrieur,
inf rieur, dans le cas du Drill down , ou un niveau suprieur, cest le Roll-up . En somme, ces deux oprations
permettent de contrler le niveau de dtail des donnes du cube.

32

Ces oprations ne sont pas aussi faciles implmenter car bases sur la notion dune
bonne hirarchisation des attributs dune dimension et la diffrenciation entre tous les niveaux
de hirarchie disponibles dans les diffrentes dimensions.

Figure I.14 :

Figure I.15 :

Exemple de Roll up moins de dtails sur les annes.

Exemple de Drill-Down plus de dtails sur les rgions .

33

IV.

Dmarche de Construction dun Data Warehouse

Plusieurs chercheurs ou quipes de recherche ont essay de proposer des dmarches

pour la ralisation dun projet Data Warehouse, ces dmarches se croisent essentiellement
dans les tapes suivantes :

Modlisation et conception du Data Warehouse,

Alimentation du Data Warehouse,

Mise en uvre du Data Warehouse,

Administration et maintenance du Data Warehouse,

IV.1

Modlisation et conception du Data Warehouse

Les deux approches les plus connues dans la conception des Data Warehouse sont :

Lapproche base sur les besoins danalyse,

Lapproche base sur les sources de donnes,

Aucune des deux approches cites nest ni parfaite, ni applicable tous les cas. Toutes
deux doivent tre tudies pour choisir celle qui sadapte le mieux notre cas.
Quelque soit lapproche adopte pour la conception dun Data Warehouse, la
dfinition de celui-l reste la mme. En tant un support daide la dcision, le Data
Warehouse se base sur une architecture dimensionnelle.
IV.1.1 Approche Besoins danalyse
Le contenu du Data Warehouse sera dtermin selon les besoins de lutilisateur final.
Cette approche est aussi appele approche descendante (Top-Down Approach) et est
illustre par R. Kimball grce son cycle de vie dimensionnel comme suit :

Figure I.16 : illustration de lapproche Besoins danalyse grce au cycle de vie

dimensionnel de Kimball [Kimball, 2004].
34

Avantages

Inconvnients

Aucun risque de concevoir une solution Pas de prise en compte de lvolution des
obsolte avant dtre oprationnelle
besoins de lutilisateur. Ncessite une
modification de la structure du Data
Warehouse en cas de nouveau besoin
Ngligence du systme oprationnel
Difficult de dterminer les besoins des
utilisateurs
Tableau I.3 : Avantages et inconvnients de lapproche Besoins danalyse .
IV.1.2 Approche Source de donnes
Le contenu du Data Warehouse est dtermin selon les sources de donnes. Cette
approche est appele : Approche ascendante (Bottom-up Approach).

Figure I.17 : Illustration de lapproche Source de donnes grce au cycle de

dveloppement du DW de Inmon [Inmon, 2002].
35

Inmon considre que lutilisateur ne peut jamais dterminer ses besoins ds le dpart,
Donnez moi ce que je vous demande, et je vous direz ce dont jai vraiment besoin 7, il
considre que les besoins sont en constante volution.
Avantages

Inconvnients

Meilleure prise en charge de lvolution des Risque de concevoir une solution obsolte
besoins
avant quelle soit oprationnelle
Evolution du schma des donnes source
Complexit de source de donnes
Tableau I.4 :

Avantages et inconvnients de lapproche Sources de donnes.

IV.1.3 Approche mixte

Une combinaison des deux approches appele hybride ou mixte peut savrer efficace.
Elle prend en considration les sources de donnes et les besoins des utilisateurs.
Cette approche consiste construire des schmas dimensionnels partir des structures
des donnes du systme oprationnel, et les valider par rapport aux besoins analytiques. Cette
approche cumule les avantages et quelques inconvnients des deux approches dj cites,
telles que la complexit des sources de donnes et la difficult quant la dtermination des
besoins analytiques.

Figure I.18 :

Give me what

Illustration de lapproche mixte.

I tell you I want, then I can tell you what I really want.[Inmon, 2002]
36

Cette tape aboutit ltablissement du modle dimensionnel valid du Data

Warehouse. Ce modle dimensionnel sera transform en modle physique, qui diffrera du
modle dimensionnel.

IV.2 Alimentation du Data Warehouse

Une fois le Data Warehouse conu, il faut lalimenter et le charger en donnes. Cette
alimentation (le plus souvent appele processus ETL Extract-Transform-Load ) se droule
en 3 phases qui sont :

Extraction des donnes primaires (issues par exemple des systmes de production),

Transformation des donnes,

Le chargement des donnes traites dans lentrept de donnes,

Ces trois tapes dcrivent une mcanique cyclique qui a pour but de garantir
lalimentation du Data Warehouse en donnes homognes, propres et fiables.
IV.2.1 Les phases de lalimentation E.T.L.
Les phases du processus E.T.L. reprsentent la mcanique dalimentation du Data
Warehouse. Ainsi elles se droulent comme suit :
a) Lextraction des donnes
Lextraction est la premire tape du processus dapport de donnes lentrept de
donnes. Extraire, cela veut dire lire et interprter les donnes sources et les copier dans la
zone de prparation en vue de manipulations ultrieures. [Kimball, 2005].
Elle consiste en :
Cibler les donnes,
Appliquer les filtres ncessaires,
Dfinir la frquence de chargement,
Lors du chargement des donnes, il faut extraire les nouvelles donnes ainsi que les
changements intervenus sur ces donnes. Pour cela, il existe trois stratgies de capture de
changement :
Colonnes daudit : la colonne daudit, est une colonne qui enregistre la date
dinsertion ou du dernier changement dun enregistrement. Cette colonne est mise jour soit
par des triggers ou par les applications oprationnelles, do la ncessit de vrifier leur
fiabilit.
Capture des logs : certains outils ETL utilisent les fichiers logs des systmes sources
afin de dtecter les changements (gnralement logs du SGBD). En plus de labsence de cette
fonctionnalit sur certains outils ETL du march, leffacement des fichiers logs engendre la
perte de toute information relative aux transactions.
37

 Comparaison avec le dernier chargement : le processus dextraction sauvegarde des

copies des chargements antrieurs, de manire procder une comparaison lors de chaque
nouvelle extraction. Il est impossible de rater un nouvel enregistrement avec cette mthode.
b) La transformation des donnes
La transformation est la seconde phase du processus. Cette tape, qui du reste est trs
importante, assure en ralit plusieurs tches qui garantissent la fiabilit des donnes et leurs
qualits. Ces tches sont :

Consolidation des donnes.

Correction des donnes et limination de toute ambigut.
Elimination des donnes redondantes.
Complter et renseigner les valeurs manquantes.

Cette opration se solde par la production dinformations dignes dintrt pour lentreprise
et de et sont donc prtes tre entreposes.
c) Le chargement des donnes
Cest la dernire phase de lalimentation dun entrept de donnes, le chargement est une
tape indispensable. Elle reste toute fois trs dlicate et exige une certaine connaissance des
structures du systme de gestion de la base de donnes (tables et index) afin doptimiser au
mieux le processus.
IV.2.2 Politiques de lalimentation
Le processus de lalimentation peut se faire de diffrentes manires. Le choix de la
politique de chargement dpend des sources : disponibilit et accessibilit. Ces politiques
sont8 :

Push : dans cette mthode, la logique de chargement est dans le systme de

production. Il " pousse " les donnes vers la zone de prparation quand il en a
l'occasion. L'inconvnient est que si le systme est occup, il ne poussera jamais les
donnes.
Pull : contrairement de la mthode prcdente, le Pull " tire " les donnes de la source
vers la zone de prparation. L'inconvnient de cette mthode est qu'elle peut
surcharger le systme s'il est en cours d'utilisation.
Push-pull : c'est la combinaison des deux mthodes. La source prpare les donnes
envoyer et indique la zone de prparation qu'elle est prte. La zone de prparation
va alors rcuprer les donnes.

http://grim.developpez.com/articles/concepts/etl/
38

Aussi, le processus dalimentation doit rpondre certaines exigences illustres par la

figure suivante :

tre correctif
Processus
ETL

tre sr

tre transparent

tre rapide

Figure I.19 :

Objectif de qualit de donnes dans un processus ETL [Kimball, 2004].

Sr : assure lacheminement des donnes et leur livraison.

Rapide : la quantit de donnes manipules peut causer des lenteurs. Le processus
dalimentation doit palier ce problme et assurer le chargement du Data Warehouse dans des
dlais acceptables.
Correctif : le processus dalimentation doit apporter les correctifs ncessaires pour
amliorer la qualit des donnes.
Transparent : le processus de lETL doit tre transparent afin damliorer la qualit
des donnes.
39

IV.2.3 Les outils E.T.L.

Les outils E.T.L, en franais E.T.C Extraction-Transformation-Chargement [Kimball,
2005], sont des outils qui garantissent la faisabilit et facilitent le droulement des trois phases
cites prcdemment. Do leur importance dans un projet Data Warehouse.

IV.3

Mise en uvre du Data Warehouse

Cest la dernire tape dun projet Data Warehouse, soit son exploitation. Lexploitation
du Data Warehouse se fait par le biais dun ensemble doutils analytiques dvelopps autour
du Data Warehouse. Donc cette tape ncessite lachvement du dveloppement, ou de la
mise en place, de ces outils qui peuvent accomplir les fonctions suivantes:
a. Requtage ad-hoc :
Le requtage ad-hoc reste trs frquent dans ce type de projet. En effet, les utilisateurs
de lentrept de donnes, et spcialement les analystes, seront amens interagir avec le DW
via des requtes ad-hoc dans le but de faire les analyses requises par leurs mtiers et,
dlaborer aussi, des rapports et des tableaux de bords spcifiques.
Laccs ce genre de service peut se faire via diffrentes mthodes et outils.
Cependant, les spcialistes en la matire prconisent de laisser la possibilit lutilisateur de
choisir les outils qui lui paraissent les plus adquats.
b. Reporting :
Destin essentiellement la production de rapports et de tableaux de bord, il est la
prsentation priodique de rapports sur les activits et rsultats d'une organisation, d'une
unit de travail ou du responsable d'une fonction, destine en informer ceux chargs de les
superviser en interne ou en externe, ou tout simplement concerns par ces activits ou
rsultants 9.
Ces outils de Reporting ne sont pas, proprement parler, des instruments d'aide la
dcision, mais, lorsquils sont utiliss de manire approprie, ils peuvent fournir une prcieuse
vue densemble.
Les rapports sont alors cres par le biais doutils de Reporting qui permettent de leur
donner un format prdtermin. Les requtes sont constitues lors de llaboration des
rapports qui seront ensuite diffuss priodiquement en automatique ou ponctuellement la
demande.

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

c. Analyse dimensionnelle des donnes:

Lanalyse dimensionnelle est sans doute celle qui exploite et fait ressortir au mieux les
capacits de lentrept de donnes. Le but par lanalyse dimensionnelle est doffrir aux
utilisateurs la possibilit danalyser les donnes selon diffrents critres afin de confirmer une
tendance ou suivre les performances de lentreprise.
Cette analyse se fait selon le principe OLAP, offrant de ce fait aux utilisateurs les
possibilits de recourir diffrentes oprations facilitant la navigation dans les donnes. La
mise en place de ces outils est une option trs intressante dans la mesure o les donnes
seront accessibles en analyses instantanes. Plusieurs fournisseurs de solution OLAP existent
sur le march et offrent des solutions construites sur des mthodes et technologies diffrentes.
Cest dailleurs pour cela que le choix de la solution doit se faire au pralable, selon les
besoins en utilisation, la taille de lentrept et les moyens techniques disponibles.
d. Tableaux de bord :
Les tableaux de bord sont un outil de pilotage qui donne une vision sur lvolution
dun processus, afin de permettre aux responsables de mettre en place des actions correctives.
Le tableau de bord est un ensemble dindicateurs peu nombreux conus pour
permettre aux gestionnaires de prendre connaissance de ltat et de lvolution des systmes
quils pilotent et didentifier les tendances qui les influenceront sur un horizon cohrent avec
la nature de leurs fonctions [Bouquin, 2003].
Cette forme de restitution a la particularit de se limiter lessentiel, c'est--dire la
mise en vidence de ltat dun indicateur par rapport un objectif, tout en adoptant une
reprsentation graphique de linformation.
e. Data Mining :
Au sens littral du terme, le Data Mining signifie le forage de donnes. Le but de ce
forage est dextraire de la matire brute qui, dans notre cas, reprsente de nouvelles
connaissances. Lide de dpart veut quil existe dans toute entreprise des connaissances
utiles, caches sous des gisements de donnes. Le Data Mining permet donc, grce un
certain nombre de techniques, de dcouvrir ces connaissances en faisant apparatre des
corrlations entre ces donnes.
Le Data Warehouse constituera alors la premire source de donnes sur laquelle
sexcutera le processus de dcouverte de connaissances. Dans la majeure partie du temps,
lentrept de donnes reprsente un pr requis indispensable toute fouille de donnes.
Le recours ce genre de mthode est de plus en plus utilis dans les entreprises
modernes. Les applications et outils implmentant ces solutions sont rarement dvelopps en
interne. En effet, les entreprises prfrent se reposer sur des valeurs sres du march afin
dexploiter au plus vite les donnes en leur possession.

41

IV.4

Maintenance et expansion

La mise en service du Data Warehouse ne signifie pas la fin du projet, car un projet
Data Warehouse ncessite un suivi constant compte tenu des besoins doptimisation de
performance et ou dexpansion. Il est donc ncessaire dinvestir dans les domaines suivants
[Kimball, 2002] :
Support : assurer un support aux utilisateurs pour leur faire apprcier lutilisation de
lentrept de donnes. En outre, la relation directe avec les utilisateurs permet de dtecter les
correctifs ncessaires apporter.
Formation : il est indispensable doffrir un programme de formation permanant aux
utilisateurs de lentrept de donnes.
Support technique : un entrept de donnes est considr 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 systme.
Management de lvolution : il faut toujours sassurer que limplmentation rpond
aux besoins de lentreprise. Les revues systmatiques certain point de contrle sont un outil
cl pour dtecter et dfinir les possibilits damlioration. En plus du suivi et de la
maintenance du Data Warehouse, des demandes dexpansion sont envisageables pour de
nouveaux besoins, de nouvelles donnes ou pour des amliorations.
Ces travaux dexpansion sont prvoir de faon faciliter lvolution du schma du
Data Warehouse.

42

V.

Conclusion

Le concept Data Warehouse est apparu comme une rponse des besoins
grandissants dans le domaine dcisionnel. Son adaptabilit et sa capacit de fournir les
donnes ncessaires 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 systme, il est ncessaire de choisir et dadopter
une dmarche prcise qui doit tenir compte des ralits de lentreprise et des contraintes du
projet. La modlisation de lentrept se fait dans tous les cas grce la modlisation
dimensionnelle. Lalimentation en donnes constitue ltape laquelle il faut accorder le plus
dattention et de temps. En effet, elle est le garant de contenance de lentrept en donnes
fiables et correctes. Une fois lalimentation termine, lexploitation des donnes peut alors se
faire par diffrentes mthodes. Lutilisation doutil OLAP reste, cependant, laspect le plus
intressant dans cette exploitation permettant la navigation dans les donnes de lentrept la
demande.
Au cours de la seconde partie de cette tude, nous allons essayer dutiliser les
concepts prsents dans la synthse bibliographique, et cela afin de mettre en uvre notre
systme.

43

Partie II :

Cas pratique filiales de

distribution SONELGAZ

44

Chapitre I :

Prsentation
daccueil.

de

lorganisme

45

I.

Prsentation de SONELGAZ

I.1 Historique
SONELGAZ est loprateur historique dans le domaine de la fourniture des nergies
lectrique et gazire en Algrie. Ses missions principales sont la production, le transport et la
distribution de llectricit ainsi que le transport et la distribution du gaz par canalisations.
Son nouveau statut lui confre la possibilit dintervenir dans dautres segments dactivits
prsentant un intrt pour lentreprise et notamment dans le domaine de la commercialisation
de llectricit et du gaz ltranger. Durant son existence le groupe a connu des volutions
majeures qui peuvent tre rsumes comme suit :
1947, Cration dEGA : Cest le dcret du 5 juin 1947 qui a cre lEtablissement Public
National Electricit et Gaz dAlgrie (EGA par abrviation). Par dcret du 16 aot 1947,
seize socits qui se partageaient les concessions lectriques ont t transfres EGA. Ces
socits dtenaient alors 90% des proprits industrielles lectriques et gazires du pays.
1962, Le dfi de la relve : Cette anne reprsente la prise en main de lAlgrie indpendante
de la SONELGAZ alors Electricit et Gaz dAlgrie et cela en faisant face au dpart
massif de cadres et techniciens franais.
Priode allant de 1962 1969 : Cette priode a t caractrise par la baisse de la
consommation (une baisse de prs de 33% en deux ans) d au dpart massive des trangers
qui reprsentaient plus de 87% de la clientle. Par ailleurs, les tches les plus urgentes ont t
de reprendre le fichier des abonns, reconstituer les plans des ouvrages et des rseaux,
procder au recrutement et la formation dans tous les domaines et de ramener le niveau de
consommation de lnergie celui de 1961.
1969, cration de SONELGAZ: Cest lordonnance n 69-59 du 28 juillet 1969) portant
dissolution de lEGA et cration de la nouvelle Socit Nationale de lElectricit et du GAZ SONELGAZ-. Ce texte sinscrit dans le cadre des mesures de nationalisation des secteurs cls
de lconomie nationale. Lordonnance prcite a attribu lentreprise le monopole de la
production, du transport, de la distribution, de limportation et de lexportation de llectricit
et du gaz manufactur (art. 4 et 7). Lensemble des biens de lex-EGA lui a t lgu.
1977, le plan national dlectrification : Ds le milieu des annes 70, lAlgrie sest
engage dans un ambitieux plan national dlectrification qui avait objectif lamlioration des
conditions de vie des populations des campagnes tout en assurant un dveloppement
harmonieux de lespace rural.
1983, naissance des entreprises travaux : six entreprises autonomes voient le jour :
KAHRIF pour llectrification; KAHRAKIB - Infrastructures et installations lectriques;
KANAGAZ - Ralisation des rseaux gaz; INERGA - Gnie civil; ETTERKIB Montage
industriel et lentreprise AMC - Fabrication des compteurs et appareils de mesure et de
contrle.

46

1991, SONELGAZ EPIC : SONELGAZ change de nature juridique et devient Etablissement

Public caractre Industriel et Commercial (EPIC) en vertu du dcret excutif n 91-475 du
14 dcembre 1991, portant transformation de la nature juridique de la Socit Nationale de
lElectricit et du Gaz. Le dcret excutif n 95-280 du 17 septembre 1995 confirme la nature
de SONELGAZ en tant quEtablissement Public caractre Industriel et Commercial.
1998, cration de filiales priphriques : Le 1er janvier 1998, neuf filiales priphriques ont
vu le jour.
2002, promulgation de la loi 02 / 01 du 5 fvrier 2002 : Promulgue en fvrier 2002, la
nouvelle loi relative llectricit et la distribution du gaz par canalisations est venue
supprimer le monopole exerc jusque l par SONELGAZ, en ouvrant le secteur de
llectricit et du gaz la concurrence, sauf pour les activits de Transport qui ont un
caractre de monopole naturel.
Juin 2002, SONELGAZ SPA : En vertu du dcret prsidentiel n 02-195 du 1er juin 2002
portant statuts de la Socit algrienne de llectricit et du gaz dnomme "SONELGAZ.
Spa", SONELGAZ est pass dEtablissement Public caractre Industriel et Commercial
une Socit Par Actions dont le capital est dtenu par lEtat.
Sur le plan de son fonctionnement, SONELGAZ Spa est dote dune Assemble Gnrale et
dun Conseil dAdministration. Elle est dirige par un Prsident directeur gnral.
I.1.1

Organisation du groupe

SONELGAZ, et afin de se mettre en conformit avec les dispositions de la loi de

fvrier 2002, qui lui confre le statut de Socit Par Actions, sest rige en un Groupe
Industriel constitu de socits oprationnelles et dune Socit Mre. Chacune des socits
ayant des missions et objectifs diffrents, il en ressort les principes dorganisation suivants :
Maison Mre : elle est charge essentiellement de llaboration de la stratgie et de
pilotage du Groupe, le contrle des filiales, llaboration et la mise en uvre de la politique
financire et la dfinition de la politique de dveloppement de la Ressource Humaine.
Filiales Mtiers de base : Durant ces cinq dernires annes, les mtiers de base de
SONELGAZ ont t rigs en filiales. Au nombre de huit, ces dernires activent dans les
domaines de la production, la gestion du rseau de transport, la gestion du systme
production / transport, la distribution de llectricit et du gaz (quatre socits).
Filiales Travaux : Les entreprises de ralisation riges en entreprises autonomes la
faveur de la restructuration de 1984 ont t rintgres, depuis janvier 2006, au sein du
Groupe SONELGAZ.
Filiales Priphriques : SONELGAZ a externalis ses activits priphriques et les a
confies des filiales dont elle dtient entirement le capital. Ces filiales sont au nombre de
quatorze et oprent dans des activits diverses.

47

Socits en Participation : SONELGAZ sest investie dans des domaines cls haute
valeur technologique tels que les tlcommunications ou la maintenance de turbines gaz.
Lorganigramme suivant donne une vision claire et prcise de la structure de
lentreprise et de son administration :

Figure II.1 : Organigramme reprsentant lorganisation du Groupe SONELGAZ.

48

I.1.2

Le groupe en chiffres

Le tableau suivant donne les chiffres relatifs lactivit du groupe pour lanne 2008:
Critres

Chiffres

Chiffre daffaire groupe

137 529 millions de DA

Investissements groupe
Electricit
Ventes
Gaz
Electricit
Nombre de clients
Gaz
Production SPE
Production
dlectricit groupe
Production IPP
Personnel en activit Permanents
du groupe
Temporaires

190 828 millions de DA

32 584 millions de kWh
7.44 Milliards de m3
6 298 682
2 638 963
28 970 millions de kWh
11 017 millions de kWh
35 633 agents
24 761 agents

Tableau II.1 :

Le groupe SONELGAZ en chiffres anne 2008 .

La figure suivante illustre lvolution du chiffre daffaire du groupe depuis lanne 2001 :

Figure II.2 : Evolution du chiffre daffaire du groupe rapport dactivit de lanne 2008 .

49

La rpartition du chiffre daffaire du groupe pour lanne 2008 est de la manire suivante :

Figure II.3 : Rpartition du chiffre daffaire publie dans le rapport dactivit de lanne
2008.

I.2 Le mtier de la distribution

Lun des mtiers les plus importants du groupe, et dans lequel sinscrit notre projet, est la
fourniture et la distribution de lnergie lectrique et gazire. Ce mtier, vu lorganisation du
groupe, est assur par quatre filiales qui sont les Socits de Distribution . Les socits
sont :

Socits de Distribution dElectricit et du Gaz de lOuest (SDO).

Socits de Distribution dElectricit et du Gaz du Centre (SDC).

Socits de Distribution dElectricit et du Gaz dAlger (SDA).

Socits de Distribution dElectricit et du Gaz de lEst (SDE).

50

Les Socits de Distribution dElectricit et du Gaz ont pour principales mission

missions dassurer :

Lexploitation
exploitation et la maintenance du rseau de distribution
distribution de llectricit et du gaz.
Lee dveloppement des rseaux lectricit et gaz permettant le raccordement
raccordement des
nouveaux clients.
La commercialisation
tion de llectricit et du gaz.

Le tableau suivant donne une vue densemble des chiffres daffaires des socits de
distribution :
SDO

SDC

SDA

SDE

Cration

Jan. 2006

Jan. 2006

Jan. 2006

Jan. 2006

Chiffre daffaire (MDA)

26.366,14

16.242

17.713

39,752

ELEC

1.668.668

1.290.058

810.636

2.069.266

GAZ

549.904

389.410

383.583

893.750

4406

3211

2412

4887

Nombre de clients
Nombre demploys
Tableau II.2 :
I.2.1

Prsentation des socits de distribution en chiffres anne 2008 .

Organisation des socits de distribution

Chaque socit de distribution compte cinq directions centrales, situes au niveau de son
sige, et gre un certain nombre de Directions de distribution . Chacune de ces Directions
de Distributions gre des Services Commerciaux . Lorganigramme suivant illustre :

Figure II.4 : Organisation des socits de distribution.

51

Lorganisation des directions de distribution se prsente comme suit :

Figure II.5 : Organisation des Directions de Distribution.

I.2.2

La clientle de la distribution

La segmentation des clients se fait selon la puissance de lnergie laquelle

quelle est abonn le
client. Ainsi, on distingue :
a. en lectricit :

Client Basse Tension-BT

BT : jusqu une puissance de 40 KVA,, labonn est
considr comme un client BT. La tension dlivre est 220 V ou 380 V.
Client Moyenne Tension-MT
Tension
: dune puissance de 50 KVA jusqu 630 KVA,
labonn est considr comme un client MT La tension dalimentation est de 10 KV
ou 30 KV.
Client Haute Tension-HT
HT : est considr comme client Haute Tension
Tension-HT
tout client dont la tension dalimentation est suprieure 60 KV.

b. En gaz :

Client Basse Pression-BP

BP : tout client aliment sous une pression de 21 bars
travers un dtendeur.
Client Moyenne Pression
ression-MP : tout client aliment sous une pression de 4 bars
avec un poste de dtente gaz.
gaz
Client Haute Pression-HP
HP : tout client aliment sous une pression sup
suprieure 4
bars avec un poste de dtente gaz.

52

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

Clients mnages : il sagit des clients domestiques.

Clients non mnages : il sagit des clients non domestiques (Activits commerciales).

Clients FSM (Facturation sur mmoire).

I.3 Linformatique au sein du groupe SONELGAZ

Linformatique occupe une place trs importante au sein du groupe SONELGAZ. En
effet, la taille du groupe et son activit loblige se doter des moyens technologiques de
pointe afin dassurer ses activits mtiers et de gestion.
Linformatique au sein du groupe a volu au fil des annes comme suit :

Jusqu la fin des annes 80, linformatique tait essentiellement prsente au niveau
central sur gros systmes. Cette priode a vu le dveloppement de systmes de gestion
de lentreprise et lacquisition de modles scientifiques de calcul pour la planification
des rseaux Electricit et Gaz (CARAT et APHYRE).

La rorganisation de SONELGAZ en 1991 et lavnement des mini et microordinateurs ont prcipit la dcentralisation de linformatique.

En 1996, le schma directeur informatique de lentreprise a dfini la stratgie de

dcentralisation de linformatique vers une informatique distribue, se basant sur
linterconnexion des rseaux locaux travers un rseau de tlcommunication propre.

En 2006, le Groupe centralise lactivit informatique par la cration de la Direction

Gnrale des Systmes dInformation (DGSI), charge de la matrise duvre dans le
domaine de linformatique.
En 2009, la DGSI sest rige au rang de filiale spcialise dans le domaine des
systmes dinformation et technologies nouvelles sous le nom de ELIT .
I.3.1

Prsentation de ELIT

Elit El-Djazar Information Technology labore et met en uvre les systmes

dinformation destins au pilotage et la gestion des diffrentes activits du groupe
SONELGAZ, assure laccs linformation et aux applications, en garantit la scurit,
lintgrit et la fiabilit et met la disposition de ses clients lexpertise technique
indispensable la satisfaction de leurs besoins.

53

Lorganigramme suivant illustre la manire dont est organise la filiale ELIT et la

distribution de son effectif:

Figure II.6 :

Organisation de la filiale ELIT.

La direction tudes et dveloppement

Notre stage se droule au sein de la direction dtude et de dveloppement. Ce
dpartement a pour mission de faire : ltude, la conception, le dveloppement et le
dploiement de solutions nouvelles et la mise en place des systmes dinformation du groupe.
Aussi, il offre lassistance ncessaire et le suivi des solutions dployes.

54

Lorganigramme et leffectif de la direction tudes et dveloppement se prsente

comme suit :

Figure II.7 :

Organisation de la direction dtude et de dveloppement.

Remarque : au niveau de chaque DD il existe une Division Gestion des Systmes

Informatique . Cette dernire soccupe essentiellement du suivie et de la maintenance des
systmes dj dploys, ainsi que de la gestion du matriel informatique au niveau de la DD
et des agences affilies.

55

II.

Conclusion

Avec ses dcennies dactivit dans le domaine de lnergie et une rputation qui
dpasse les frontires du pays, le groupe SONELGAZ reprsente un acteur majeur et
incontournable de lconomie nationale. Cette brve prsentation nous a permis de connatre
un peu plus le groupe SONELGAZ, notamment dans sa nouvelle configuration de holding
industriel.
Par ailleurs, cette prsentation nous a fait comprendre la structuration et lorganisation
du mtier de la distribution, qui est le premier vis par ce projet, et de nous pencher sur
linformatique du groupe dsormais gre, au niveau national, par la filiale ELIT .
Dans le chapitre suivant, une tude dtaille de lexistant dcisionnel du groupe, dans
sa fonction de distribution, sera prsente.

56

Chapitre II : tude de lexistant

57

I.

Introduction

Le groupe SONELGAZ veut, par le biais de ce projet, palier un manque important en

matire de dcisionnel. Ce manque se caractrise par la quasi inexistence de support daide
la dcision, et lindisponibilit de moyens de Reporting efficaces, en mesure de fournir des
informations adquates en temps voulu.
Partant de ce constat, nous allons essayer, travers ce chapitre, de prsenter une analyse
aussi complte que possible de lexistant dcisionnel du groupe dans le cadre de sa fonction
de distribution. Ce chapitre a aussi pour but de faire connatre les procdures et les mthodes
de Reporting et de prise de dcision, ainsi que les ventuelles lacunes qui peuvent exister.

II.

Etat du dcisionnel au sein du groupe

Il est intressant de signaler que le groupe, dans sa fonction de distribution, ne dispose

daucun systme daide la dcision automatique ou semi-automatique. Aussi, tout processus
danalyse et de prise de dcision tous les niveaux se base essentiellement sur des rapports
dont les donnes sont extraites et consolides partir des systmes transactionnels dune
manire manuelle.
Lors de notre tude de lexistant, nous avons pu recenser deux procds pour llaboration
des rapports. Les deux procds se distinguent par leurs utilisateurs finaux, la structure
charge de leur laboration et le niveau de consolidation.

II.1

Niveau Groupe

A ce niveau de hirarchie, les utilisateurs ont besoin de chiffres qui concernent lensemble
du groupe, dans sa fonction de distribution. Ces rapports sont essentiellement livrs par la
filiale ELIT . Les donnes tant consolides partir des bases de production des DD
des quatre filiales de distribution. Cela suppose donc, la participation de diffrents acteurs
disperss sur lensemble du territoire national ainsi que sur lensemble des filiales
distributions.
Dans le meilleur des cas, le rapport demand concerne des donnes dj consolides et
prtes lutilisation. Llaboration du rapport se fait donc sans grandes difficults. Sinon, le
procd dextraction et de consolidation est relanc. Le diagramme suivant donne une vision
claire de la manire dont sont consolides les donnes et les rapports labors en partant de la
demande dun tat donn jusqu' sa production :

58

Figure II.8 : Diagramme dactivit modlisant ldition de rapport pour le niveau groupe.
partir de ce diagramme on peut dores et dj avoir une ide sur le nombre
dintervenants dans cette procdure qui reste une tche trs fastidieuse, surtout dans sa partie
consolidation des donnes. Cette procdure se droule comme suit:
Phase 1 : les utilisateurs de niveau groupe, principalement des analystes et des
dcideurs de la DGDS et de la maison mre, formulent leurs requtes qui sont transmises au
dpartement Systmes dinformation de la distribution (SID) de la filiale ELIT .
Phase 2 : le dpartement SID, en recevant une demande de la part des utilisateurs de
niveau groupe, lance la procdure de consolidation des donnes partir des diffrentes DD du
groupe. Cette procdure doit faire lobjet dune validation de la part du directeur tudes et
dveloppement. La demande est ensuite transmise au chef de CTI de chaque DD.
Phase 3 : Les chefs de CTI, en recevant la demande dextraction, programment une
tranche horaire et prparent les scripts dextraction. Ltape dextraction aboutit la
transmission de fichier texte vers le dpartement SID.

59

Remarque : les fichiers, tant dune taille assez volumineuse, peuvent atteindre une
centaine de mgas voire plus. Ces dits fichiers subissent parfois des altrations durant le
transfert ou deviennent carrment inutilisables. Dans ce cas les D.D. concernes sont
recontactes pour une nouvelle extraction ou un nouvel envoi selon la nature du problme. Il
arrive parfois, suite des problmes rseaux, de recourir au transfert des donnes sur
support physique transportable (CD, cl USB).
Phase 4 : Une fois les donnes reues en totalit, la consolidation se fait au niveau du
dpartement SID manuellement. Cette consolidation permet dlaborer les rapports
voulus.
Phase 5 : Le rapport est valid par le chef de dpartement est et envoy aux
utilisateurs finaux.
Remarque : la procdure se rpte gnralement quatre fois par an, la consolidation
des chiffres se faisant chaque trimestre. Mais cela nempche pas le lancement de cette
procdure en cas de ncessit.
Sauf en cas de problmes, toute change dinformation demandes et fichiers joints
se fait par le biais de la messagerie interne du groupe.

II.2

Niveau Socits de Distribution

Pour le niveau SD , la procdure se droule exactement comme pour le niveau

groupe. A cela prs que ELIT nintervient pas ce niveau l. Cest alors aux ingnieurs de
la structure concerne de prendre en charge la consolidation et llaboration des rapports. Les
diffrences notes sont :
Emission de la demande : La demande est formule par les analystes et dcideurs des
deux directions Commerciale Marketing DCM et Comptabilit et Finance DCF .
Extraction des donnes: lextraction se fait toujours aux niveaux des DD affilies la
SD. Dans la plupart du temps les donnes sont transfres directement sous forme de
rapports10.
Consolidation des donnes : la consolidation se fait soit partir des fichiers de
donnes, soit en se basant sur les rapports transmis par les DD. Cette consolidation se fait
toujours de faon manuelle et monopolise les ingnieurs et techniciens de SD.
Remarque : la procdure dlaboration de rapports au niveau SD se fait
gnralement chaque fin de mois. Elle peut aussi tre lance en cas de ncessit.

10

Ces rapports obissent des canevas prdfinis.

60

II.3

Niveau Directions de Distribution

Les consommateurs de rapports au niveau des DD utilisent des rapports livrs

directement par leurs CTI. Ces rapports, bass exclusivement sur les donnes des systmes
transactionnels, sont labors et transmis la demande des managers. Le schma suivant
montre la manire dont sont traites 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 lentreprise . Le chef de CTI charge son quipe technique de
llaboration du rapport demand quil contrle avant sa transmission qui de droit.
Llaboration des rapports se fait ce niveau soit par le bais du module
Statistique11 du SGC, Soit par des requtes SQL. La prsentation 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 dcideurs des systmes qui fournissent des tats
statistiques la demande. Cependant, ces systmes, en interrogeant directement la base de
donnes transactionnelle en production, offrent des services limits avec des temps de
rponse non satisfaisants.
Cette mise en place de systmes, ne fait quencourager le groupe uniformiser les
procdures et mthodes de prise de dcision.

11

Ce module a t dvelopp pour fournir un certain nombre de rapports statistiques au niveau DD. Il interagit
directement avec la base de donnes en production et pnalise souvent le systme transactionnel.
61

III.

Conclusion

Cette tude nous permet davoir une vision gnrale des procdures dlaboration de
rapports et de consolidation des donnes. Elle constitue aussi le point de dpart pour dfinir le
primtre du projet en gnral et de ltude des besoins en particulier. Elle fait ressortir les
insuffisances du systme actuel en soulignant les points faibles ou les goulots dtranglements
de ce dernier.
Le chapitre suivant consacr ltude des besoins, aidera dtecter ceux des
utilisateurs de manire pouvoir y rpondre.

62

Chapitre III : Dfinition des besoins.

63

I.

Introduction

Tout Data Warehouse doit tre en mesure de rpondre aux attentes des utilisateurs.
Cela ne peut, videmment, se fairee sans une tude approfondie de leurs besoins.
Ainsi, il existe deux dmarches qui ont t dcrites lors de notre synthse
bibliographique, et qui sont: l'approche Buttom Up et l'approche Top Down .
L'application exclusive dee l'une
l
de ces deux approches ne produit nullement des
rsultats satisfaisants. La dmarche gnralement adopte est une dmarche mixte, qui allie
entre les deux prcdentes dans un souci de prise en considration des besoins des dcideurs
sans perdre de vue toute possibilit
possibilit et opportunit offerte par les donnes sources
sources. Cette
approche permet donc de recueillir, corriger et de modrer les attentes des utilisateurs ds le
dpart, tout en dtectant d'ventuels besoins non exprims.
Durant ltude des besoins on ne peut se limiter
limiter aux interviews avec les utilisateurs
utilisateurs,
nanmoins, il faudrait absolument prendre en compte lavis des Administrateurs des bases de
donnes des systmes sources Les DBA sont les principaux experts sur les applications
existantes susceptibles d'alimenter
d'aliment
l'entrept de donnes. Leurs interviews servent
confronter aux ralits certains des thmes qui surgissent lors des rencontres avec les
utilisateurs finaux. [Kimball, 96]

Figure II.9 : La place de ltape dtude des besoins dans un projet Data Warehouse.

64

Ce chapitre a pour principale vocation dexposer et de dcrire la dmarche adopte

pour la dtection des besoins ainsi que la prsentation de la synthse qui en sera faite.

I.1 Description de la dmarche d'tude des besoins

Afin de faire une tude aussi complte que possible, nous avons choisi d'adopter une
dmarche qui nous a permis de combiner, dune manire assez satisfaisante, entre l'approche
Buttom Up et l'approche Top Down .
Ainsi, notre dmarche peut se rsumer au travers des tapes suivantes:

tude prliminaire des systmes sources et interviews sommaires avec les DBA,

Dtection des postes susceptibles d'tre porteurs d'informations utiles,

Planification, prparation et conduite des interviews:

Utilisation dautres moyens pour la dtection des besoins,

Rdaction et validation du recueil rcapitulatif des besoins,

a. tude prliminaire des systmes sources et interviews sommaires avec les DBA
Cette tude reprsente une tape de comprhension des systmes oprationnels et de leur
environnement. Elle a pour mrite de consolider les connaissances acquises durant ltude de
lexistant, ainsi que le jargon et le fonctionnement de lentreprise. En outre, cette tape permet
de dtecter, de manire succincte, les postes susceptibles dinteragir 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 lElit, et dont la fonction principale est de dfinir les rgles de gestion des
applications et de sassurer du respect des procdures propres la distribution, ont t une
source dinformation assez bnfique, eu gard leur connaissance des applications du SGC
et de leur matrise du mtier du groupe.
b. Dtection des postes susceptibles d'tre porteurs d'informations utiles
Vu le grand nombre demploys activant au sein du groupe SONELGAZ, notamment
dans la fonction de distribution, ainsi que la dispersion gographique des filiales, il nous a t,
bien sr, impossible de voir et dinterviewer toute cette population. Ainsi, notre tude sest
axe sur les utilisateurs SDA, SDC.
Cette tape nous a permis, donc, didentifier, en premier lieu, les services qui peuvent
tre porteurs dinformations tangibles et qui reprsentent la population potentiellement
utilisatrice du projet. Ces dits services sont classs selon leur appartenance aux diffrentes
structures, indiqu dans le tableau suivant:

65

Structure

Intitul du poste

Nombre total de postes

Direction de distribution

Directeur rgional 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)

P.D.G de la SD

D.C.M

Directeur finance et comptabilit

P.D.G

DGDS

Socit de distribution

Groupe

DAP

DAR

ED

Total
Tableau II.3 :

248
Tableau prsentant la population interviewer.

c. Planification, prparation et conduite des interviews

Avant de dtailler cette tape, il est ncessaire de justifier notre choix de lentretien
interviews comme mthode de collecte des besoins.
Bien quil existe dautres mthodes didentification des besoins, les entretiens simposent
comme tant la valeur sre dans un tel projet. En effet, cette mthode a lavantage dtre, plus
ou moins, facilement planifiable et douvrir le dialogue avec les interviews, qui sont pour la
plus part des dcideurs et des analystes.
Dans le souci de conduire bien cette tape, qui du reste est trs critique et dlicate, il est
ncessaire de passer par diffrentes phases, savoir :
1

La phase de planification

La planification se fait gnralement plusieurs jours lavance. Elle nous permet de

prendre les rendez-vous ncessaires et de prvenir les futurs interviews de notre arrive et du
motif de cet entretien.
Cette phase, qui est un pralable indispensable, sest avre tre une tche trs ardue. En
effet, la nature organisationnelle et la dispersion des structures lies la distribution ont pos
des problmes que nous voquerons plus loin. Cependant ces mmes facteurs nous ont

66

pousss entreprendre ce genre de dmarches 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 manire avoir une certaine
alternance entre les interviews des potentiels utilisateurs et les entretiens avec les DBA et les
gestionnaires de manire combiner entre les besoins danalyse et les potentialits des
systmes sources et de leurs donnes.
2

La phase de prparation

Une fois la planification de lentretien termine, sa prparation doit se faire de telle sorte
ce quil se droule dans les meilleures conditions possibles.
La prparation se rsume essentiellement en lidentification des questions poser, des
points soulever et des thmes viter afin de ne pas trop sparpiller.
Les questions poser sont classes en deux catgories, selon le poste de la personne
interviewe. Ainsi certaines questions sont destines aux dcideurs alors que dautres sont
destines aux analystes.
3

La conduite des entretiens

Dernire phase de ltape, la conduite des interviews reprsente la ralisation sur le terrain
des phases prcdentes. Le but escompt tant damener les interviews, au travers de leurs
rponse nos questions, de prsenter leur travail et la manire dont ils procdent pour le faire.
Lidentification des besoins se fera alors en dtectant les mtriques quils utilisent et les
informations sur lesquelles ils sappuient pour la prise de dcision.
d. Autres moyens utiliss pour la dtection des besoins
Bien que les entretiens reprsentent une source importante dinformations et aident
grandement lidentification des besoins des utilisateurs, leur utilisation exclusive nest pas
conseille dans la construction dun entrept de donnes. Cela tient principalement au fait que
les utilisateurs ne peuvent, mme avec la meilleure volont du monde, exprimer tous leurs
besoins.
De ce fait, il est fait appel ltude des rapports dj demands et des donnes
disponibles a mme de fournir des informations exploitables.
Ltude des rapports offre un certain apport notre dmarche dtudes des besoins, dans la
mesure o les utilisateurs peuvent ne pas mentionner des besoins qui leur paraissent vidents
ou qui ne leur viennent pas lesprit durant nos interviews, ces derniers peuvent tre, en effet,
influencs par nos questions.
Ltude des donnes, quant elle, sert dtecter des besoins non dclars et qui
peuvent se faire sentir ultrieurement, le but de cette dmarche tant de construire un entrept
de donnes capable de rpondre ces ventuels nouveaux besoins.

67

e. Rdaction et validation du recueil rcapitulatif des besoins

Ltude des besoins nous a permis de recenser les besoins que nous avons classs par
volets spcifiques. Ils peuvent tre prsents de la manire suivante :

Volet Dtect

Besoins enregistrs (Les critres danalyse)

Suivi des
ventes

Utilisateurs : Ce volet a t voqu et solliciter tous les niveaux et par

diffrents postes. Cependant les utilisateurs des services Commerciaux
et marketing, de la DCM et de la DFC ont exprim un vif intrt pour ce
volet.
Besoins : Les utilisateurs ont besoin de connatre lvolution des ventes
et des consommations dans le temps et selon diffrents critres savoir :
(Zone gographique, type dabonnement, secteur dactivit)

Suivi des
abonns

Utilisateurs : Services commerciaux, DCM, utilisateurs de la DGDS.

Besoins : ce volet contient les informations relatives lapport abonn
(rsiliations, nouveaux clients,etc.), lutilisateur devrait tre en mesure
de suivre lvolution de ces chiffres selon diffrents critres danalyse:
(Zone gographique, temps, type abonnement, activits).

Suivi des
affaires

Utilisateurs : Services commerciaux, DCM.

Besoins : Avoir une vue densemble de lvolution des affaires et le
suivi des taux et les dlais de ralisations. Lutilisateur doit tre en
mesure de faire des analyses selon les critres : (Zone, Type de laffaire,
nergie, temps)

Suivi des
recouvrements

Utilisateurs : Services commerciaux, DCM, DFC.

Besoins :Disposer de la possibilit danalyse par rapport des axes bien
dtermins, qui sont :(Zone, Type dabonne, client, nergie, temps)

Tableau II.4 :

Synthtisation des besoins recenss.

68

I.2

Problmes et obstacles rencontrs

Bien que notre tude des besoins ait donn lieu aux rsultats escompts, savoir leur
identification et leur prise en charge, il nempche que le travail ne sest pas effectu sans
obstacles, dont les plus importants sont :
Difficult de planifier les entretiens cause de :
- La charge de travail qui nous incombe,
-

Lemploi du temps charg des interviews,

Lorganisation du groupe par filiale a limit notre libre circulation au sein du

groupe,

Dispersion gographique des structures dhbergement

dhbergent des

services et les personnes interviewer,

Lindisponibilit de personnes concernes par les entretiens et les annulations de

dernire minute,

Les rsistances au changement notamment au sein de quelques directions rgionales,

La rtention dinformations sous couvert de confidentialit,

Lapprhension, par les utilisateurs, du projet et de sa faisabilit,

69

II.

Conclusion

Ltude des besoins est une tape plus que ncessaire dans un projet Data Warehouse.
Cest, en effet, partir de cette tude que se dcidera la manire de construction de lentrept
de donnes et de son architecture.
Cette tude des besoins sest droule sur vingt trois entretiens et a concern quinze
personnes occupant diffrents postes des niveaux hirarchiques diffrents. Lensemble des
entretiens a dur plus de 33 heures et nous ont permis tout dabord dappliquer les mthodes
danalyse et de collecte dinformation. Il nous a permis de connatre davantage de dtails sur
les rouages de lentreprise et didentifier les besoins analytiques de lentreprise.
Les besoins tant recenss, la construction du Data Warehouse peut alors commencer.
Cette construction fera lobjet du chapitre suivant.

70

Chapitre IV :

Conception de la solution

71

Conception de la zone dentreposage

72

I.

Introduction

Une fois les besoins des utilisateurs connus, nous pouvons commencer concevoir les
volets de notre Data Warehouse. Pour cela, nous avons eu recours la modlisation
dimensionnelle qui est souvent associe aux entrepts de donnes compte tenu de ses
avantages.
Cependant, avant de se lancer dans la modlisation, il est intressant de classer les
sujets recenss selon lintrt quils reprsentent pour lentreprise et less facilits de
ralisation. Ce classement nous aidera choisir lactivit modliser en premier lieu de
manire garantir des rsultats satisfaisants
satisfaisant pour lentreprise.

II.

Processus de la modlisation dimensionnelle

La conception dun modle dimensionnel passe par cinq tapes essentielles :

Choix de lactivit modliser : ce choix se fait aprs classement des activits dans
une matrice dite danalyse
analyse des priorits [Kimball, 2004]. Cette matrice permet de
connatre quelle activit choisir en premier. Le classement des sujets recenss, qui
sest fait en collaboration avec les dcideurs et les techniciens de lentreprise, est
illustr dans la figure suivante :

Figure II.10 : Analyse des priorits du cas Distribution SONELGAZ

ONELGAZ .

Dfinition de lactivit et de son grain,

Dfinition des dimensions qui dcrivent une ligne de la table de fait,

Dfinir
finir les mesurables du fait,

Dfinir les agrgats.

73

II.1

Volet Vente

a) Prsentation de lactivit Vente

Une vente est la cession dun bien ou d'un service en change d'une somme dargent
convenue entre le vendeur, celui qui cde le bien ou le service, et l'acheteur, celui qui paie
[Larousse, 2008].

SONELGAZ, par le biais de ses quatre filiales, propose la vente dnergie, (lectricit ou
gaz), livr par canalisation jusquau lieu de consommation, dans le cadre dun contrat de
fourniture.
La vente dnergie, lectrique ou gazire, demeure comme lactivit principale des filiales
de distribution du groupe SONELGAZ, ralisant la plus grande partie du chiffre daffaire du
groupe. Les chiffres lis aux ventes se prsentent comme des indicateurs dune grande
signification par rapport la performance du groupe. Ainsi la disponibilit de ces
informations savre indispensable pour les dcideurs de lentreprise.
b) Grain de lactivit
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 dtail le plus bas, correspond une opration de
facturation12, do une ligne de table de fait correspondant :
Suivi de la quantit et du montant de la vente dune nergie par tarif un client
activant dans un certain domaine une date donne.

12

Ce nest quaprs facturation que la quantit et le montant consomm sont arrts, do la vente.
74

c) Les dimensions
sions participantes du modle
Les dimensions ont pour objectif de dcrire le fait, donc on essaye de recenser
recens toutes les
informations
formations qui dcrivent une vente et qui peuvent intresser les dcideurs.
1. Dimension Temps
La dimension temps est la seule dimension qui figure systmatiquement dans tout
entrept de donnes, car en pratique tout entrept de donnes est une srie temporelle. Le
temps est le plus souvent la premire dimension dans le classement sous jacent de la base de
donnes [Kimball, 2001].
La dimension temps se prsente comme
com suit :

Figure II.11
11 : La Dimension Temps de lactivit Vente .

Le niveau de dtail le plus bas de cette dimension est la journe. En effet, les utilisateurs
ont fait ressortir le besoin de suivre les chiffres au jour le jour et den
d
garder lhistorique de
ces derniers.
Dans cette dimension, il est utilis une cl artificielle comme cl primaire.
primair Cette cl
artificielle sert faciliter la manipulation de la dimension. Le tableau suivant donne plus de
dtails sur cette dimension :

75

Dsignation
Code_temps

Dtails
Cl artificielle de la dimension temps.

Date

La date au format complet.

Jour

Position du Jour dans le mois.

Jour_semaine

Nom des jours de la semaine.

Mois

Nom du mois.

Mois_annee

Numro du mois dans lanne.

Annee_mois

Anne et mois (concatnation).

Semaine_dans_annee

Numro de la semaine dans lanne.

Annee

Anne de la date.

Trimestre

Trimestre de la date.

Trimestre_annee

Trimestre et anne (concatnation).

Saison

Saison la quelle appartient une date.

Evnement

Evnement survenu lors de cette date.

Tableau II.5 :

Tableau descriptif de la dimension Temps .

76

2. Dimension client
Le client simpose comme un lment important dans lanalyse,
lanalyse et intresse les
analystes et les dcideurs de lentreprise. Outre ce quil reprsente dans une opration de
vente, lanalyse
analyse du comportement du client peut aider lentreprise mieux le satisfaire.

Figure II.12
12 :

La Dimension
imension Client de lactivit Vente .

La dimension client dcrit un client, lacheteur. Un client est rfrenci par son lieu de
consommation, c'est--dire
dire quatre clients qui ont habit le mme lieu, sont considrs comme
un seul client. Pour permettre la traabilit et le suivi dun client on a introduit une cl
artificielle. Celle-ci aide pallier linsuffisance de la codification en vigueur, notamment
pour une finalit dcisionnelle
le.. Les caractristiques qui dcrivent un client sont:

77

Dsignation
Code_client

Dtails
Cl artificielle

Reference

La rfrence du lieu de consommation

Numero_client

Le numro affect un client FSM 13(ce champ est utilis si le

client est un abonn FSM)

Nom_client

Le nom du client.

Adresse_client

Adresse du client.

Code_postal

Code postal du lieu de consommation.

Commune

Commune du lieu de consommation.

Agence

Agence laquelle le lieu de consommation est affili.

Direction_regionale

La direction rgionale o le lieu de consommation est affili.

Wilaya

La wilaya du lieu de consommation.

Filiale

La filiale laquelle le lieu de consommation est affili.

Secteur_activite

Secteur dactivit du client dans le lieu de consommation.

Debit_gaz

Dbit gaz install sur le lieu de consommation.

Debit_electricite

Dbit lectricit install sur le lieu de consommation.

Type

Type du client (ordinaire ou FSM).

Groupe

Le groupe de facturation du client (Chaque client appartient

un groupe de facturation. Il existe 60 groupes de facturation).

Tournee

La tourne de relve laquelle appartient le client.

Tableau II.6 :

13

Tableau descriptif de la dimension Client .

FSM : Facturation sur mmoire.

78

3. Dimension facture
Une facture est un document relatif au fait de vente. Cette dernire contient un certain
nombre dinformations intressantes pour une analyse. Elle dcrit les diffrentes
caractristiques dune facture, et qui caractrisent aussi une vente.

Figure II.13 :

La Dimension Facture de lactivit Vente .

affect dans le cas

La facture est identifie par un numro facture. Ce mme numro est affect,
prsent, la facture en cas dannulation. La
L diffrence
iffrence entre les deux se fait alors grce au
champ type facture. On pourrait dans ce cas penser ladoption dune cl primaire compose.
Cependant une telle cl nuirait fortement aux performances du systme.. Pour cela, et dans un
souci de performance, on a introduit une cl artificielle
artificielle cette table. Ce choix est dautant
plus justifiable que la dimension est une dimension volution rapide. La facture est
caractrise par :

79

Dsignation
Numero_facture

Dtails
Cl artificielle

Numero_facture_SGC

Le numro facture dans le systme source.

Date_facture

Date de la facturation.

Cycle

Cycle dmission de la facture.

Type

Type de la facture (Emission ou Annulation).

Type_releve

Type de la relve (les relves dindex se font de diffrentes

manires).

Montant_HT

Montant hors taxe.

Montant_TTC

Montant toutes taxes comprises.

Taxe_habitation

Taxe habitation.

Montant_timbre

Montant du timbre.

Montant_TVA

Montant TVA.

Droit_fixes

Montant droit fixes.

Soutient_etat

Montant du soutient de ltat (les wilayas du sud).

Tableau II.7 :

Tableau descriptif de la dimension Facture .

80

4. Dimension zone gographique

La dimension zone gographique dcrit la zone o le fait a eu lieu. Aprs ltude des
besoins au sein du groupe, il parait intressant de faire des comparaisons par rapport des
zones gographiques. Le grain le plus bas de cette dimension correspond aux communes. Ces
dernires sont susceptibles dvolution dans le temps (appartenance a une filiale ou une
wilaya). On jug donc ncessaire dintroduire une cl artificielle pour permettre le suivi de
lvolution de la dimension et dassurer la cohrence des donnes.

Figure II.14 : La Dimension

D
Zone gographique de lactivit Vente .

Les caractristiques de la dimension Zone gographique sont explicites dans le

tableau suivant :

81

Dsignation
Code_zone

Dtails
Cl artificielle.

Code_commune

Code de la commune.

Nom_commune

Nom de la commune.

Code_agence

Code de lagence (une agence regroupe plusieurs communes).

Nom_agence

Nom de lagence.

Adresse_agence

Adresse de lagence.

Tel_agence

Tlphone de lagence.

Code_dd

Code de la direction de distribution.

Nom_dd

Nom de la direction de distribution.

Adresse_dd

Adresse de la direction de distribution.

Tel_dd

Tlphone de la direction de distribution.

Code_wilaya

Code de la wilaya.

Nom_wilaya

Nom de la wilaya.

Code_filiale

Code de la filiale de distribution (il y a quatre filiales).

Adresse_filiale

Adresse de la filiale de distribution.

Tel_filiale

Tlphone de la filiale de distribution.

Tableau II.8 :

Tableau descriptif de la dimension Zone gographique .

82

5. Dimension activit

Figure II.15 : La Dimension Activit de lactivit Vente .

Cette dimension dcrit les diffrents secteurs dactivitss conomiques. Celle-ci est
charge partir dun tableau transmit par le ministre des finances, et trs importante, ds lors
que beaucoup danalyses observes
observe pendant ltude des besoins, se base sur cette dimension.

Dsignation
Code_activit

Dtails
Le code de lactivit.

Libell_activit

Libell de lactivit.

Tableau II.9 :

Tableau descriptif de la dimension Activit .

6. Dimension tarif

Figure II.16
16 : La Dimension Tarif de lactivit Vente .
Souvent, des analyses sont faite
faites par rapport aux tarifs affects au client. Cette
tarification est affecte de manire tudie selon le type du client. En plus du code_tarif ,
cette dimension contient :
Dsignation
Code_tarif

Dtails
Le code tarif qui est appliqu actuellement.

Abreviation_tarif

Abrviation du tarif telle quutilise dans lentreprise et

codifie sur les documents officiels.

Description_tarif

Une description sommaire du tarif.

Tableau II.10
10 : Tableau descriptif de la dimension Tarif .
83

7. Dimension nergie

Figure II.17
17 : La Dimension nergie de lactivit Vente .
Les filiales de distribution de SONELGAZ livrent plusieurs types dnergie qui
diffrent par un certain nombre de caractristiques.
caractristiques Avoir
voir une segmentation par rapport une
caractristique ou une autre est trs intressant lors dune analyse. Une
ne nergie est dcrite
par les caractristiques suivantes :
Dsignation
Code_energie

Dtails
Code nergie dbit/type

Type_energie

Type de lnergie

Debit

Dbit

Unite_mesure

Unit de mesure de lnergie

Tableau II.11
11 : Tableau descriptif de la dimension Energie.
8. Dimension dgnre
dgnr Puissance maximale
Les cls trangres de la table de fait rfrencent les dimensions qui reprsentent le
contexte du fait. Cependant il existe des cls ne rfrenant aucune dimension, ces dernires
sont dites dimensions dgnres.
La dimension puissance maximale
max
est
st dans ce cas un exemple de ce type de
dimension. En effet, celle-ci ne contient aucune description textuelle et elle ne peut tre
assimile aucune autre dimension. Elle est identifie par sa valeur dans la table
ta
des faits et
fournie grce ce dernier la possibilit danalyser les ventes
ventes selon la puissance maximale
demande par le client.

84

d) Les mesurables
Les mesurables qui correspondent lactivit 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 .

85

e) Le modle en toile de lactivit Vente

Figure II.18 : Modle en toile de lactivit Vente .

86

f) Les agrgats
Les tables dagrgats amliorent les performances du Data Warehouse, en rduisant le
nombre de lignes que le SGBD manipule afin de rpondre une requte. Cela se fait grce
lagrgation des donnes contenues dans les tables de faits dtailles et qui sont stockes dans
de nouvelles tables de faits.
La construction des agrgats se base sur le modle en toile dtaille, et elle
peut ncessiter:

La cration de nouvelles dimensions drives : la construction dun modle agrg

ncessitera la suppression de quelques attributs dune dimension qui dsigne le grain
le plus fin.
La suppression de quelques dimensions : le modle agrg peut engendrer
llimination de certaines dimensions qui napparaissent pas au niveau de dtail voulu.

On peut aussi :

Crer de nouveaux faits: lors de la cration de la table de faits agrge on peut

rajouter quelques faits qui nexistaient pas dans la modle de base. En effet, lusage et
la signification des tables agrges peuvent diffrer du modle de base.
Crer des tables pr-jointes : une table dagrgat peut tre construite partir dune
jointure entre la table de faits et une ou plusieurs dimensions. Le rsultat est stock
dans une seule table dite pr-jointure.

Une table dagrgat peut tre invisible ou visible lutilisateur final :

Elle est invisible lorsquelle reflte exactement le modle de base

Elle est visible lorsquelle contient des faits supplmentaires.

Les rsultats issus dune table agrge ou du modle de base doivent tre identique.

Pour cette phase, on sinspire de la dmarche dcrite par C. Adamson dans son livre
Mastering the Data Warehouse Aggregates, Solution for Star Schema Performance . La
dmarche consiste :
1- Enumrer les agrgats potentiels partir dune toile dtaille : pour dtecter les
agrgats potentiels et choisir ceux implmenter dans le Data Warehouse. Il est
ncessaire de bien dcrire chaque agrgat.
2- Dtecter les agrgats utiles : choisir des agrgats utiles partir des agrgats
potentiels.
3- Construire le modle agrg : enfin on construit le modle agrg tout en prenant en
considration les dimensions drives commune entre les diffrents modles.

Les agrgats sont conus, en gnral, comme des modles dimensionnels.

87

1) Les agrgats potentiels

Le tableau suivant dcrit, dune manire simple et efficace, les agrgats potentiels du
modle dimensionnel de base de lactivit des ventes:

Dimension

Agrgats potentiels
Mois, trimestre, anne, saison
Type, dbit
Code activit
Tarif
Tourne, agence, commune, DR, wilaya, filiale
Date, cycle, type, relve
Numro, commune, agence, DR, wilaya, filiale, activit,
dbit gaz, dbit lectricit, type

Temps
Energie
Activit
Tarif
Zone
Facture
Client

Nombre
dagrgats
possibles
4
3
1
1
6
4
10

Tableau II.12 : Liste des agrgats potentiels pour lactivit Vente .

2) Les agrgats utiles :
Les agrgats potentiels ne sont pas en effet tous utiles, soit par le nombre de lignes
agrges ou par les informations fournies. Pour cela on rduit la liste des agrgats ce qui
suit :
Dimension
Temps
Energie
Activit
Tarif
Zone
Facture

Agrgats utiles
Mois, trimestre, anne, saison
Type, dbit
Code activit
Tarif
Commune, agence, DR, wilaya, filiale
Cycle, type, relve

Nombre dagrgats retenus

4
3
1
1
5
4

Tableau II.13 : Liste des agrgats utiles de lactivit Vente .

A partir du tableau prcdent nous choisissons les agrgats qui nous semblent les plus
pertinents et susceptibles de faire lobjet daccs frquents. nous arrtons la liste des modles
agrgats suivants :

Ventes journalires par type dnergie par activit par commune.

Ventes mensuelles par DR (agrgation de plus de dix mille lignes).

Ventes mensuelles par cycle par type de relve (agrgation de plus de trois
millions lignes).

La modlisation des agrgats se fait grce aux principes de la modlisation

dimensionnelle.
88

II.2

Volet Recouvrement

a) Prsentation de lactivit Recouvrement

Action de recouvrer, de retrouver ce qui tait perdu, des sommes dues . [Larousse,
2008]
Une suite logique au fait de vente, cest le recouvrement des sommes dues aux clients.
Une somme peut passer par plusieurs phases ou tats : facture, impaye, paye, prscontentieux, contentieux et apure. Cette terminologie obit un jargon au sein de
lorganisation pour dfinir une crance ou un avoir.
Ces tats correspondent aux diffrents comptes de recouvrement. Le mouvement dun
compte lautre se fait par rapport aux dlais de recouvrement. Lentreprise sintresse au
suivi de ltat journalier de ces comptes afin de suivre de prs cette activit trs importante.
b) Grain de lactivit :
Le grain le plus fin de lactivit correspond :
Suivi du montant et de ltat dune facture dun client appartenant une zone
gographique et activant dans un certain domaine une date donne
c) Les dimensions participantes du modle
Les dimensions communes
Aprs la dtection des dimensions de la nouvelle toile, on procde une mise en
conformit des dimensions communes. Pour ce faire, on construit un tableau qui croise les
toiles conues avec leurs dimensions. Le but tant de dtecter les dimensions communes
pour leurs mises en conformit. Le tableau suivant illustre cela :
Etoile

Vente

Recouvrement

Dimensions
Client
Zone gographique
Temps
Facture
Activit
Nature
Tableau II.14 :

Dtection des dimensions communes entre les volets Vente et

Recouvrement .

A cette tape il existe quatre dimensions communes. Ces dimensions tant trs
dtailles dans la premire toile, il ny a pas eu ncessit de recourir une mise en
conformit. Cette remarque reste valable pour lensemble du document, ainsi il ny a pas lieu
de dtailler les dimensions communes la prsentation de chaque toile.
89

1. Dimension nature

Figure II.19 : La Dimension nature de lactivit Recouvrement .

La dimension nature dcrit la nature du montant contenu dans le fait, ou plus
prcisment le compte dont il est comptabilis un moment donn. La dimension contient les
informations listes dans le tableau suivant :
Dsignation
Code_nature

Dtails
Cl artificielle

Libelle

Libell de la nature du montant

Operation

Libell de lopration relative au montant

Tableau II.15
15 : Tableau descriptif de la dimension Nature .

d) Les mesurables
Le mesurable qui correspond lactivit recouvrement et qui permet de mesurer
les performances de cette activit, est le montant de lopration en toutes
tout taxes
comprises .

90

e) Le modle en toile de lactivit Recouvrement

Figure II.20 : Modle en toile de lactivit Recouvrement .

91

f) Les agrgats
1) Les agrgats potentiels

Dimension

Agrgats potentiels

Temps
Nature
Activit
Zone
Facture

Mois, trimestre, anne, saison

Opration, nature
Code activit
Tourne, agence, commune, DR, wilaya, filiale
Date, cycle, type, relve
Numro, commune, agence, DR, wilaya, filiale, activit,
dbit gaz, dbit lectricit, type

Client

Tableau II.16 :

Nombre
dagrgats
possibles
4
2
1
6
4
10

Tableau descriptif des agrgats potentiels du modle

Recouvrement .

2) Les agrgats utiles

Dimension
Temps
Activit
Zone
Facture

Agrgats utiles
Mois, trimestre, anne, saison
Code activit
Commune, agence, DR, wilaya, filiale
Cycle, type, relve

Tableau II.17 :

Nombre dagrgats possibles

4
1
5
4

Tableau descriptif des agrgats utiles du modle Recouvrement .

Nous arrtons la liste des agrgats suivants :

Montant et nombre des factures des comptes de recouvrement journalier.

par nature par activit par commune.

Montant et nombre de facture mensuel par opration par commune.

Montant et nombre de facture par nature par type client.

92

II.3

Volet Suivi des affaires

a) Prsentation de lactivit Suivi des affaires

Une affaire est une demande initie soit par la clientle ou par lagence et qui ncessite une
mise jour de la base de donnes. Cet vnement se traduit par lenregistrement dune affaire
qui sera suivie jusqu son aboutissement.
Parmi les modules du SGC , le module Gestion des Affaires gre les affaires lies a
la Basse Moyenne Pression, Basse Moyenne Tension depuis leurs enregistrements jusqu'
leurs ralisations. Ce module gnre chaque jour, et au niveau de chaque direction de
distribution, une masse de donnes considrable. Ces donnes reprsentent une source
dinformation plus quindispensables pour le groupe et ses filiales de distribution. Do la
ncessit de suivre cette activit.
b) Grain de lactivit
Le grain le plus fin de lactivit suivi des affaires reprsente, en ralit, la possibilit de
suivre une affaire selon des critres diffrents. 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 inities au niveau de chaque commune.

c) Les dimensions participantes

Les dimensions communes
Daprs le grain de lactivit on peut dj savoir les dimensions qui seront prsentes dans
notre toile et qui sont listes dans le tableau. Ces dimensions sont indispensables pour
rpondre au grain de lactivit. Aussi, et afin doffrir un suivi plus complet et plus ais, on a
jug ncessaire dintroduire la Dimension phase affaire .
Etoile

Vente

Recouvrement

Suivi des affaires

Dimension
Client
Zone gographique
Temps
Facture
Activit
Affaire
Type affaire
Phase
Tableau II.18 :

Dtection des dimensions communes entre les volets Vente ,

Recouvrement et Suivi des affaires .

93

1. Dimension affaire
La dimension affaire estt une dimension indispensable pour faire une bonne analyse dans
cette toile. En effet, afin de bien suivre une affaire nous avons besoin du maximum
dinformation la concernant. Cette dimension dcrit donc une affaire qui est identifie par son
numro le numro de laffaire est unique au niveau national et qui est caractrise par son
degr durgence et son initiateur
itiateur.

Figure II.21 : La Dimension

D
affaire de lactivit Suivi
uivi des affaires .
Cette dimension est une dimension
dimension volution rapide. Cela se vrifie par le nombre
daffaires inities quotidiennement par agence.
agence Cette dimension fournie les informations
suivantes :

Dsignation
Numero_affaire

Dtails
Un numro dordre donn par le systme et qui volue
chaque enregistrement.

Degre_urgence

Reprsente le degr durgence de laffaire. Certaines

Certaine affaires
sont plus urgentes que dautres.

Observation

Observation relative laffaire.

Initier_par

Permet de connaitre linitiateur de laffaire (agence, client,

DD).
Tableau II.19
19 : Tableau descriptif de la dimension Affaire .

94

2. Dimension type affaire

Cette dimension nous renseigne
igne sur le type de laffaire. Les
Les types sont classs en catgories
daprs la nature de laffaire, ensuite en sous catgories daprs lnergie concerne. En plus
de lappartenance dune affaire une catgorie, cette dimension nous renseigne sur dautres
caractristiques savoir lnergie
nergie de laffaire et saa dure approximative.

Figure II.22 : La Dimension

imension type affaire de lactivit Suivi
uivi des affaires .
La dimension est une dimension volution lente. En effet, lajout dune catgorie est
peu frquent. Le dtail de cette dimension est le suivant :
Dsignation
Code_affaire

Dtails
Code de laffaire tel quil est connu au sein du groupe.

Intitule_affaire

Intitul du type de laffaire.

Code_categorie

Le code de la catgorie laquelle

quelle appartient un type
daffaires.

Intitule_categorie

Lintitul de la catgorie laquelle

quelle appartient un type
daffaires.

Code_ss_categorie

Code de la sous catgorie. Chaque catgorie est divise

divis en
sous catgories.

Intitule_ss_categorie

Intitul de la sous catgorie.

Duree_aproximative

Une approximation en jours de la dure de laffaire.

Tableau II.20 : Tableau descriptif de la dimension Type affaire.

95

3. Dimension phase
Chaque affaire transite, durant son cycle de vie, par un certain nombre de phases. Celles-ci
Ce
ont t normalises et codifiees de manire ce quelles puissent
ssent tre utilises conjointement
par toutes les affaires. La dimension phase reprend donc la codification utilise par le
SGC pour identifier ces phases. Lutilisation dune telle dimension facilite grandement la
comprhension du modle dimensionnel et confrera une certaine aisance dimplmentation
et de gestion de lalimentation de ltoile.

uivi des affaires .

Figure II.23 : La Dimension phase de lactivit Suivi
Le tableau suivant donne le dtail de cette dimension :
Dsignation
Code_phase

Dtails
Code des phases par lesquelles transitent
nt les affaires.

Intitule_phase

Intitul de chaque phase.

Description_phase

Description textuelle de chaque phase.

Tableau II.21
21 : Tableau descriptif de la dimension Phase.
d) Les faits mesurs
Cette toile na pas de mesurables a proprement parl. La table de faits
fait dans ce cas est
appele une Table de faits sans faits . Ce genre de table permet de renseigner sur le nombre
et lvolution des affaires dans le temps.

96

e) Modle en toile de lactivit suivi des affaires

Figure II.24 : Modle en toile de lactivit Suivi des affaires .

97

f) Les agrgats
1) Les agrgats potentiels

Dimension

Agrgats potentiels

Temps
Activit
Zone

Mois, trimestre, anne, saison

Code activit
Tourne, agence, commune, DR, wilaya, filiale
Numro, commune, agence, DR, wilaya, filiale, activit,
dbit gaz, dbit lectricit, type
Code catgorie, code sous catgorie

Client
Type affaire

Tableau II.22 :

Nombre
dagrgats
possibles
4
1
6
10
2

Tableau descriptif des agrgats potentiels du modle Suivi des

affaires .

2) Les agrgats utiles

Dimension
Temps
Activit
Zone
Type affaire

Agrgats utiles
Mois, trimestre, anne, saison
Code activit
Commune, agence, DR, wilaya, filiale
Code catgorie, code sous catgorie

Tableau II.23 :

Nombre dagrgats possible

4
1
6
2

Tableau descriptif des agrgats utiles du modle Suivi des affaires .

On va arrter la liste des agrgats suivants :

Nombre et dure des affaires par commune.

Nombre et dure des affaires par secteur dactivit.

98

II.4

Volet Suivi des abonns

a) Prsentation de lactivit Suivi des abonn

Un abonnement lectrique (ou gazier) est une contrepartie aux services qui sont rendus
par le gestionnaire du rseau public de distribution. Principalement lacheminement de
llectricit, et du gaz de la centrale au lieu de consommation de labonn.
Labonn est la partie bnficiaire du service, en contrepartie il doit honorer ses
engagements relatifs au contrat dabonnement.
Lors de notre tude des besoins, un des sujets auquel sintressent les dcideurs est le
suivi des abonns : abonnement, mise en service, rsiliation. En effet, le nombre dabonns
se prsente comme un des indicateurs de performances de lentreprise, do lintrt de
suivre la ralisation des objectifs tracs.
b) Grain de lactivit :
Le grain le plus fin de lactivit correspond :
Lhistorique complet dun abonn par type, zone gographique et par activit.

c) Les dimensions participantes du modle :

1. Les dimensions communes
Le tableau suivant nous donne la liste des dimensions communes entre toutes les
toiles :
Etoile

Vente

Recouvrement

Suivi des
abonns

Dimension
Client
Zone
gographique
Temps
Activit
Type abonn

Suivi des
abonns

Tableau II.24 : Dtection des dimensions communes entre les volets Vente ,
Recouvrement , Suivi des affaires et Suivi des abonns .

99

2. Dimension type abonn

La dimension type abonn contient une description dun abonn par le type de
paiement (domicili ou non domicili)
domicili) et par rapport au type du lieu de consommation.

Figure II.25 : la Dimension Type

T
abonn de lactivit Suivi des abonns
abonn .
Dsignation
Code_type_abonne

Dtails
Cl artificielle du type abonn

Type_paiement

Type abonn selon ses paiements

Type_ lieu

Type abonn selon le lieu de consommation

Tableau II.25 : Tableau descriptif de la dimension Type abonn .

d) Les mesurables
Dans ce cas on se retrouve avec une table de faits sans faits. Cette table a pour objectifs de
tracer lhistorique dun abonn du jour de son abonnement son ventuelle
ventuelle rsiliation.

100

e) Le modle en toile de lactivit Suivi des abonns

Figure II.26 : Modle en toile de lactivit Suivi des abonns .

101

f) Les agrgats
1. Les agrgats potentiels

Dimension

Agrgats potentiels

Temps
Type abonn
Activit
Zone

Mois, trimestre, anne, saison

Lieu, paiement
Code activit
Tourne, agence, commune, DR, wilaya, filiale
Numro, commune, agence, DR, wilaya, filiale, activit,
dbit gaz, dbit lectricit, type

Client

Tableau II.26 :

Nombre
dagrgats
possibles
4
2
1
6
10

Tableau descriptif des agrgats potentiels du modle suivi abonns .

2. Les agrgats utiles

Dimension
Temps
Activit
Zone
Type abonn

Agrgats utiles
Mois, trimestre, anne, saison
Code activit
Commune, agence, DR, wilaya, filiale
Lieu, paiement

Nombre dagrgats possibles

4
1
6
2

Tableau II.27 : Tableau descriptif des agrgats utiles du modle suivi abonns .
On va arrter la liste des agrgats suivants :

Nombre dabonnements par commune par jour.

Nombre de rsiliations par commune par jour.

Nombre de mises en service par commune par jour.

102

III.

Conclusion

La zone dentreposage constitue la zone exploitable par les utilisateurs. La modlisation

de cette zone se fait grce la modlisation dimensionnelle. Cette manire de reprsenter les
donnes offre aux utilisateurs des modles intuitifs et comprhensibles permettant de
naviguer et de manipuler les donnes, dtailles ou agrges, sans difficult afin de satisfaire
leurs besoins en analyse.
La finalisation de la conception dune toile de lentrept, nous permet de passer la
construction de la zone dalimentation. Cette zone dalimentation constitue lobjet du
prochain chapitre.

103

Conception de la zone alimentation

104

I.

Introduction

LETL, ou lalimentation du Data Warehouse, est une tape des plus importantes dans
un projet Data Warehouse, elle reprsente 80% de la charge de travail. Cette tape a pour
objectif dassurer lacheminement des donnes des systmes sources jusqu lentrept de
donnes, en passant par les diffrentes phases de nettoyage et de transformations ncessaires.
La conception du processus dalimentation ncessite les tapes suivantes :
Etude et planification,

Choix de larchitecture,

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 reprsente une phase prliminaire lensemble du processus. Elle consiste

en :

Ltude des sources de donnes,

La dtection des emplacements des donnes source,

La Dfinition de la priodicit du chargement,

II.1

Les sources de donnes :

Les sources de donnes de notre entrept sont :

Le systme SGC, avec ses 35 modules (voire annexe C),

Le systme de gestion de la distribution HT/HP,

Les fichiers plats, en provenance dautres structures (pour les achats), ou

dorganismes externes (le ministre des finances),

Les sources de donnes en chiffres:

58 sources de donnes, parpilles sur lensemble du territoire national,

Plus de 6 millions de clients,

Plus de cent trente intgrations dabonns jour,

Soixante-dix mille factures jour,

105

II.2 Dtection des emplacements des donnes sources :

Afin de dfinir lemplacement des informations dans les diffrents systmes source et
den choisir les emplacements les plus fiables, nous avons travaill de manire troite avec les
DBA et les gestionnaires.
Le nombre important de tables, la redondance des donnes et lintervention de
diffrents systmes, rendent cette tche trs ardue. Afin de mener bien cette dtection, nous
devons :

Lister les donnes ncessaires partir des toiles conues,

Lister les emplacements de chaque donne,

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

Dresser un tableau14 qui tabli le lien entre donnes sources et donne cibles avec
les transformations ncessaires,

Cette tape sachve par llaboration dune carte logique entre donnes sources et
donnes cibles15.
Il est important de valider les sources de donnes (donc le tableau cit
prcdemment), afin de vrifier leurs intgrits et leurs fiabilits.

II.3 Dfinition de la priodicit de chargement

La priodicit de chargement est tudie pour chaque toile sparment. , ce qui
nempche pas une synchronisation dans les chargements des dimensions communes.
Avant de dcider de la priodicit du chargement, les contraintes suivantes doivent
tre prises considration :

La quantit de donnes charger,

Le temps de non activit des systmes sources,

Ltoile qui engendrera les chargements les plus importants, en termes de volume,
nest autre que ltoile des ventes. En effet, le systme de facturation, tablit annuellement
plus de six millions de factures, ce qui reprsente plus de dix millions de lignes de faits
ventes . Ce processus sexcute de faon journalire (soixante-dix mille lieux de
consommation par jour). Aussi, le module de gestion des affaires (Systme source) prsente
une forte volatilit de ses donnes. Cette volatilit est due au fait que le passage, dune affaire
donne, dune phase une autre, ne laisse aucune trace sur la base de donnes oprationnelle.

14
15

Ce tableau est dcrit dans le livre [Kimball 2004].

Voire Annexe D
106

De ce fait, lidal est de procder des chargements journaliers, pendant les heures de
non activit des systmes sources, c'est--dire, durant la priode qui stend entre dix-huit
heures et huit heures du matin.
Pourquoi pas des chargements hebdomadaires
Mme si pendant les week-ends le nombre dheures de non activit des systmes est
plus important, la quantit de donnes charger sera, elle, plus consquente, et affectera les
performances du processus de chargement. Par ailleurs, la volatilit de certaines donnes
nous contraint appliquer une telle politique de chargement

III.

Architecture du processus dalimentation

Llaboration dune architecture du processus de lalimentation ETL ds le dbut

du projet est trs importante. En effet, le choix dune architecture affecte pratiquement toutes
les composantes du projet. Tout changement de celle-ci engendrera ncessairement
dimportants changements dans lensemble du projet.

Partant de ce constat, il est ncessaire de mettre en place une architecture consistante

mme de prendre en charge toutes les contraintes auxquelles on doit faire face.
Le processus de lETL peut se faire de diffrentes manires. Dans le cas despce
nous avons choisi la mthode Push-Pull . En plus des avantages quelle prsente, cette
mthode pallie aux contraintes rencontres au sein de lentreprise et permet dexploiter toutes
les opportunits offertes. Parmi les contraintes et opportunits il peut tre cit :

Limpossibilit daccs distant aux systmes source : lentreprise nautorise pas des
accs distants aux systmes sources. Laccs se fera par le biais dune base de
donnes intermdiaire. Cette restriction est due la structure organisationnelle de
lentreprise16.
Les problmes du rseau actuel17 : le rseau actuel subi des perturbations au niveau
de quelques directions de distribution. Ces dernires ne sont pas encore quipes de
connexion ADSL18.
Le nombre important des sources de donnes et la quantit des donnes : Cette
politique (push-pull) permettra le lancement de chargements parallles.
Lexistence de serveurs au niveau sources : les cinquante-huit directions de
distribution disposent de matriel informatique important, permettant de lancer des
processus de prparation de donnes au niveau des DD .
Maintenance facile: mme si les sites sont parpills, la tche dune ventuelle
maintenance sera facilite par le biais des quipes informatiques en place.

16

Le dcoupage juridique de lentreprise ne permet pas aux filiales de partager des informations dune faon
directe.
17
Voire annexe F.
18
Plus de quarante D.D sont quipes de connexion ADSL.
107

Pourquoi adopter cette architecture ?

Outre un chargement sr, Cette architecture permet de:

Rduire les temps de chargement : grce au chargement parallle, le temps de

traitements sera rduit.
Limpact rduit dun chargement chou : lchec dun chargement aura un impact
rduit sur les donnes du Data Warehouse.
La possibilit de mise en place dune nouvelle faon daccs : dans une architecture
Push-Pull il est prfrable de faire un transfert de fichiers, par exemple via FTP.
cette mthode trs performante teste est difficile dployer, elle sera donc mise
en perspective. La figure suivante illustre larchitecture du processus dalimentation
adopte :

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

Dans la zone de prparation Staging area les donnes sont extraites partir des
sources de donnes, transformes et prpares pour le chargement final. Au niveau du
serveur ELIT il est procd laffectation de cls artificielles et quelques
transformations ncessaires avant le chargement final dans la zone dentreposage. Aprs
chaque chargement, une mise jour des Meta Data doit tre faite.

108

IV.

Processus de chargement

Le diagramme dactivits suivant dcrit le processus gnral de lalimentation de

lentrept de donnes ds sa mise en service :

Figure II.29 : Diagramme dactivit du processus dalimentation.

109

Deux types de tables dans lentrept de donnes faits, dimensions doivent tre
distingus. Chaque type de table diffre dans les dinformations quil contient, et do donc
ladoption de deux processus de chargement.
La stratgie dextraction adopte consiste comparer des chargements successifs afin de
dtecter les changements. Cette stratgie, tant la plus fiable, est incontournable pour la
capture des changements pour des raisons de non fiabilit des champs date, gnralement non
renseigns. Cette dtection se fait au niveau de la zone de prparation amliorant
sensiblement les performances.

IV.1

Processus de chargement de dimension

Les tables de dimension constituent le contexte de la table de faits. Elles reprsentent le

point dentre au Data Warehouse. Une dimension est gnralement constitue : dune cl
artificielle, dune cl naturelle et des attributs.
Le processus de chargement de dimension doit, outre le chargement des donnes, assurer :
La gestion des cls artificielles: affectation des cls et mise en correspondance avec
les cls naturelles.
La gestion de lvolution de dimension : grer les changements que subissent les
dimensions. Il existe trois types de traitement par rapport lvolution dune
dimension :
o Type 1 crasement : consiste mettre jour lattribut subissant un
changement.
o Type 2 cration dun nouvel enregistrement : consiste crer un
nouvel enregistrement afin de sauvegarder tout le cycle dvolution de la
dimension.
o Type 3 dplacement de la valeur a chang dans un attribut ancien :
consiste prvoir des attributs pour enregistrer les changements ventuels.
Il permet de sauvegarder un nombre dfini de changements.

110

Le digramme suivant illustre la politique que nous avons retenue :

Figure II.30 : diagramme dactivit du processus de chargement de dimension.

111

La stratgie adopte pour la dtection des changements se fait grce la comparaison

entre le dernier chargement et le chargement actuel. Cette mthode, comme dcrite lors de la
synthse bibliographique, est la plus fiable pour la capture des changements.
Les mises jour de type 3 sont traites comme de nouvelles insertions, avec la mise jour
de la table rfrences.

IV.2

Processus de chargement des tables de faits

Lextraction des faits se fait avec les cls naturelles utilises dans les systmes sources.
Ltape qui prcde le chargement de la table des faits consiste remplacer les cls naturelles
par les cls artificielles. La substitution peut se faire directement par le biais des tables de
dimension, ce qui est correct mais trs lent. Pour cela on utilise des tables de rfrencement.
Le processus de chargement des tables des faits doit garantir lintgrit rfrentielle vis-vis des tables de dimensions.
Le diagramme dactivit suivant illustre le processus de chargement adopt pour une table
de faits :

112

Figure II.31 : diagramme dactivit 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.

113

IV.3

Processus de chargement particulier

Dans un entrept de donnes il y a des tables particulires, soit : la table de la dimension

temps et les tables dagrgats, ncessites 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 forcment extraites partir des systmes sources. Cette dimension doit
contenir, en effet, toutes les dates qui concident, ou concideront, avec un fait donn. Elle
participe toutes les toiles et assure lhistorisation. Ds lors, il est prfrable de construire un
calendrier :
La dimension date est plus souvent construite comme tant un calendrier avec une
granularit journalire . [Kimball, 2004].
IV.3.2 Processus de construction dagrgats
Aprs le chargement dune toile, les tables dagrgats doivent tre charges par le biais
de lETL et partir des donnes dtailles. En plus du calcul des agrgats et de leur insertion,
des mises jour frquentes de ces tables sont indispensables.

114

V.

Conclusion

Un processus E.T.L a pour mission dassurer la livraison de donnes conformes,

cohrentes et correctes tout en assurant des performances acceptables. Lors de la conception
du processus de lETL il a t envisag datteindre les objectifs suivants:

Assurer le chargement des donnes et leur qualit,

Assurer la transparence des processus de chargement et de consolidation qui assure la

qualit des donnes,

Ne pas nuire aux performances des systmes sources,

Utiliser des sources, autres que les sources oprationnelles pour donner une valeur
ajoute aux informations,

Permettre un suivi de lavancement des chargements, et corrections en cas derreur,

Offrir une documentation complte du processus, afin de faciliter la maintenance ainsi

que lamlioration,

Offrir une performance optimale grce aux chargements parallles et sparation des
donnes selon lopration de chargement (mise jour ou nouvelle insertion),

Mettre en uvre des solutions secours pour faire face aux problmes rseau,

Mise jour des Meta data, pour la maintenance et lassurance de la qualit de donnes,

115

Conception des cubes dimensionnels

116

I.

Introduction

Afin de faciliter lanalyse et la navigation dans les donnes, il est important que les
cubes dimensionnels soient bien conues et dfinis de manire claire pour une utilisation
intuitive.
La conception des cubes dimensionnels passe par la dfinition des mesurables, des
dimensions et des hirarchies prsentes au sein des dimensions, ainsi que les diffrents
niveaux de dtails de chaque hirarchie. Le but de la mise en place de ces cubes est doffrir
une reprsentation abstraite d'informations multidimensionnelles des fins danalyse.
Le choix des cubes construire, des mesurables quils contiendront, des dimensions
participantes dans chacun dentre eux et des hirarchies qui constituera chaque dimension
dpend essentiellement des besoins recenss et de lutilisation finale.

II.

Dfinition des niveaux et des hirarchies

La dfinition des diffrentes hirarchies prsente dans une dimension est une tape
cruciale et indispensable pour la conception des cubes. En effet, cest grce ces hirarchies
que lutilisateur pourra naviguer et explorer bon escient les informations offertes par un
cube donn.
Cette tape se droule en deux phases:

Identification des attributs dun mme niveau pour chaque dimension.

Construction des hirarchies (Une dimension peut avoir plusieurs hirarchies).

Au final nous obtiendrons le tableau rcapitulatif suivant :

Dimension

Colonne

Niveaux

Hirarchies

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

117

dim_client

dim_facture

dim_energie

dim_nature

dim_phase

dim_tarif

code_client
reference_lc
type

Niveau_1 : N1

Hierarchy_1 :
N1 N2 N3 ALL

numero_client

Niveau_2 : N2

Hirarchy_2 :
N1 N3 ALL

Groupe

Niveau_3 : N3

numero_facture
numero_facture_s
gc
date_facture
taux_tva
soutient_etat
conso_moy_enrgi
e_jour
reference_lc

Niveau_1 : N1

type_facture

Niveau_2 : N2

type_releve

Niveau_3 : N3

type_cycle

Niveau_4 : N4

code_energie
type_energie
unite_mesure

Niveau_1 : N1

Hierarchy_1 :
N2 N1 ALL

Debit

Niveau_2: N2

Hierarchy_2 :
N2 N1

code_nature
lib_nature

Niveau_1 : N1

operation

Niveau_2 : N2

code_phase
intitule_phase
desc_phase
durree_estimee_p
hase

Niveau_1 : N1

code_tarif
description_tarif
abreviation_tarif

Niveau_1 : N1

Energie

Niveau_2 : N2

N1

Hierarchy_1 :
N2 N3 N4

ALL

N1

Hierarchy_2 :
N2 N4 N3

ALL

Hierarchy_1 :
N2 N1 ALL

Hierarchy_1 :
N1 ALL

Hierarchy_1 :
N1 N2 ALL

118

dim_temps

dim_type_abonn
e

dim_type_affair
e

code_temps
date
jour_du_mois
jours
evenement

Niveau_1 : N1

semaine_dans_ann
ee

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

code_type_abonne
e

Niveau_1 : N1

type_client_domic
iliation

Niveau_2 : N2

type_client_paiem
ent

Niveau_3 : N3

code_affaire
intitule_affaire
energie_affaire
durree_approxima
tive

Niveau_1 : N1

code_ss_categorie
intitule_ss_categor
ie

Niveau_2 : N2

code_categorie
intitule_categorie

Niveau_3 : N3

N1

Hierarchy_1 :
N2 N3 N4
N5 N6 ALL

N1

Hierarchy_1 :
N2 N3 All

N1

Hierarchy_2 :
N3 N2 All

N1

Hierarchy_1 :
N2 N3 All

119

code_zone
code_commune
commune

Niveau_1 : N1

code_agence
agence

Niveau_2 : N2

code_dr
dr

Niveau_3 : N3

dim_zone
code_wilaya
wilaya

Niveau_4 : N4

code_filiale
filiale
adresse_filiale
tel_filiale

Niveau_5 : N5

N1

Hierarchy_1 :
N2 N3 N4
N5 ALL

Tableau II.28 : Tableau donnant les niveaux et les hirarchies de chaque dimension.

Le niveau All : Ce niveau reprsente le niveau le plus haut dune hirarchie. De ce

fait, il est le niveau le plus agrg. Le niveau ALL napparat pas systmatiquement dans
toutes les hirarchies.

120

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 prsents dans ces
cubes. Il est signaler aussi que la dimension dim_nature napparaitra nul part dans la
description des cubes. En effet, cette dimension a t remplace par lutilisation de
mesurables dans les cubes concerns. Le tableau suivant donne le dtail de la conception de
ces cubes :
Nom du cube

Les mesurables

Les dimensions
Dim_client
Dim_facture

Suivi des ventes

Suivi des ventes et

des consommations

Suivi de lapport
abonn

1. Chiffre daffaires
2. Nombre de factures

1. Chiffre daffaires
2. Consommation
3. Nombre de consommations
nulles

1. Nombre de raccordements

Dim_energie

Les Hirarchies
de la dimension
Hierarchy_1
Hierarchy_1
Hierarchy_2
Hierarchy_1
Hierarchy_2

Dim_zone

Hierarchy_1

Dim_temps

Hierarchy_1

Dim_tarif

Hierarchy_1

Dim_client

Hierarchy_1

Dim_facture

Hierarchy_1

Dim_energie

Hierarchy_2

Dim_zone

Hierarchy_1

Dim_temps

Hierarchy_1

Dim_tarif

Hierarchy_1

Dim_type_abonn

Hierarchy_1
Hierarchy_2

Dim_zone

Hierarchy_1

Dim_client

Hierarchy_1

Dim_temps

Hierarchy_1

121

Suivi des
rsiliations

Suivi des mises en

service

Suivi des affaires

Suivi des
recouvrements

Dim_type_abonn

Hierarchy_1
Hierarchy_2

Dim_zone

Hierarchy_1

Dim_client

Hierarchy_1

Dim_temps

Hierarchy_1

Dim_type_abonn

Hierarchy_1
Hierarchy_2

Dim_zone

Hierarchy_1

Dim_client

Hierarchy_1

Dim_temps

Hierarchy_1

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

Dim_temps

Hierarchy_1

Dim_client

Hierarchy_1

Dim_facture

Hierarchy_1
Hierarchy_2

Dim_zone

Hierarchy_1

1. Nombre de rsiliations

1. Nombre de mises en service.

1. Nombre daffaires
2. Dure

1.
2.
3.
4.
5.

Montant crances
Montant avoir.
Montant factures fraches.
Montant factures impayes.
Montant prcontentieux.

Tableau II.29 : Liste des cubes dimensionnels.

122

IV.

Prsentation des cubes dimensionnels

Dim_zone

Dim_enrgie
code_energie
type_energie
unite_mesure
debit

<N1>

code_zone
code_commune
commune
code_agence
agence
code_dd
dd
code_wilaya
wilaya
code_filiale
filiale

<N1>

<N2>
<N3>
<N4>
Dim_client

<N5>

Hierarchie_1 <Default> <h>

<N2>

code_client
reference_lc
type
numero_client

<N1>

<N2>

Hierarchie_1 <Default> <h>

Hierarchie_1 <Default> <h1>

Hierarchie_2
<h2>
Cube_suivi_vente - Dim_zone

Cube_suivi_vente - Dim_client

Cube_suivi_vente - Dim_enrgie

Cube_suivi_vente
chiffre_affaire
nombre_facture
Fait_vente

Cube_suivi_vente - Dim_tarif

Cube_suivi_vente - Dim_facture

Cube_suivi_vente - Dim_temps

Dim_facture
numero_facture
numero_facture_sgc
date_facture
soutient_etat
conso_moy_enrgie_jour
type_facture
type_releve
type_cycle
Hierarchie_1
Hierarchie_2

<N1>

Dim_tarif
Dim_temps

<N2>
<N3>
<N4>

<Default> <h1>
<h2>

code_temps
date
jour_du_mois
jours
evenement
semaine_dans_annee
mois_annee
mois
annee_trimestre
trimestre
saison
annee

<N1>

code_tarif
description_tarif
abreviation_tarif
energie

<N1>

<N2>

Hierarchie_1 <Default> <h>

<N2>
<N3>
<N4>
<N5>
<N6>

Hierarchie_1 <Default> <h>

Figure II.32 : Cube dimensionnel Suivi des ventes .

123

Dim_zone
code_zone
code_commune
commune
code_agence
agence
code_dd
dd
code_wilaya
wilaya
code_filiale
filiale

<N2>
<N3>
<N4>
<N5>

Dim_client
code_client
reference_lc
type
numero_client

Hierarchie_1 <Default> <h>

Dim_enrgie
code_energie
type_energie
unite_mesure
debit

<N1>

<N1>

<N1>

<N2>

Hierarchie_1 <Default> <h>

<N2>

Hierarchie_2 <Default> <h>

Cube_suivi_vente_conso - Dim_zone

Cube_suivi_vente_conso - Dim_client

Cube_suivi_vente_conso - Dim_enrgie

Cube_suivi_vente_conso
chiffre_affaire
nombre_facture
nombre_conso_nul
Fait_vente
Cube_suivi_vente_conso - Dim_tarif

Cube_suivi_vente_conso - Dim_facture

Cube_suivi_vente_conso - Dim_temps

Dim_tarif

Dim_facture
numero_facture
numero_facture_sgc
date_facture
soutient_etat
conso_moy_enrgie_jour
type_facture
type_releve
type_cycle
Hierarchie_1
Hierarchie_2

code_tarif
description_tarif
abreviation_tarif
energie

<N1>
Dim_temps
<N2>
<N3>
<N4>

<Default> <h1>
<h2>

code_temps
date
jour_du_mois
jours
evenement
semaine_dans_annee
mois_annee
mois
annee_trimestre
trimestre
saison
annee

<N1>

<N1>

<N2>

Hierarchie_1 <Default> <h>

<N2>
<N3>
<N4>
<N5>
<N6>

Hierarchie_1 <Default> <h>

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

124

Dim_temps

Dim_zone
code_zone
code_commune
commune
code_agence
agence
code_dd
dd
code_wilaya
wilaya
code_filiale
filiale

<N1>

<N2>

Cube_suivi_des_abonnes - Dim_zone

Cube_suivi_des_abonnes - Dim_temps

<N3>
<N4>
<N5>

Hierarchie_1 <Default> <h>

code_temps
date
jour_du_mois
jours
evenement
semaine_dans_annee
mois_annee
mois
annee_trimestre
trimestre
saison
annee

<N1>

<N2>
<N3>
<N4>
<N5>
<N6>

Hierarchie_1 <Default> <h>

Cube_suivi_des_abonnes
Nombre_raccordements
Nombre_resiliations
Nombre_mise_service
Fait_suivi_abonnes
...

Dim_client
Dim_type_abonne
code_type_abonnee
<N1>
type_client_domiciliation <N2>
type_client_paiement
<N3>
Hierarchie_1

Cube_suivi_des_abonnes - Dim_client

Cube_suivi_des_abonnes - Dim_type_abonne

code_client
reference_lc
type
numero_client

<N1>

<N2>

Hierarchie_1 <Default> <h>

<Default> <h>

Figure II.34 : Cube dimensionnel Suivi des abonns .

Dim_temps

Dim_zone
code_zone
code_commune
commune
code_agence
agence
code_dd
dd
code_wilaya
wilaya
code_filiale
filiale

<N1>

<N2>

Cube_suivi_recouvrement - Dim_zone

Cube_suivi_recouvrement - Dim_temps

<N3>
<N4>
<N5>

Hierarchie_1 <Default> <h>

code_temps
date
jour_du_mois
jours
evenement
semaine_dans_annee
mois_annee
mois
annee_trimestre
trimestre
saison
annee

<N1>

<N2>
<N3>
<N4>
<N5>
<N6>

Hierarchie_1 <Default> <h>

Cube_suivi_recouvrement
Montant_creances
Montant_avoir
Montant_factures_fraiches
Montant_facture_impayee
Montant_precontentieux
Fait_suivi_abonnes

Dim_facture
numero_facture
numero_facture_sgc
date_facture
soutient_etat
conso_moy_enrgie_jour
type_facture
type_releve
type_cycle
Hierarchie_1
Hierarchie_2

<N1>
Dim_client

<N2>
<N3>
<N4>

Cube_suivi_recouvrement - Dim_facture

code_client
<N1>
reference_lc
type
<N2>
Cube_suivi_recouvrement - Dim_client numero_client
Hierarchie_1 <Default> <h>

<Default> <h1>
<h2>

Figure II.35 : Cube dimensionnel Suivi des recouvrements .

125

Dim_zone
code_zone
code_commune
commune
code_agence
agence
code_dd
dd
code_wilaya
wilaya
code_filiale
filiale

Dim_type_affaire
code_affaire
intitule_affaire
durree_approximative
code_ss_categorie
intitule_ss_categorie
code_categorie
intitule_categorie

<N1>

<N1>

<N2>
<N3>
<N4>
<N5>

Hierarchie_1 <Default> <h>

<N2>
<N3>

Hierarchie_1 <Default> <h>

Dim_temps
code_temps
date
jour_du_mois
jours
evenement
semaine_dans_annee
mois_annee
mois
annee_trimestre
trimestre
saison
annee

<N1>

<N2>
<N3>
<N4>
<N5>
<N6>

Hierarchie_1 <Default> <h>

Cube_suivi_affaire - Dim_zone

Cube_suivi_affaire - Dim_type_affaire

Cube_suivi_affaire - Dim_temps

Dim_client

Cube_suivi_affaire
nombre_affaire
durre_moyen
Fait_suivi_affaire

code_client
Cube_suivi_affaire - Dim_client
reference_lc
type
numero_client

<N1>

<N2>

Hierarchie_1 <Default> <h>

Cube_suivi_affaire - Dim_energie
Cube_suivi_affaire - Dim_affaire

Cube_suivi_affaire - Dim_phase

Dim_phase

Dim_affaire
numero_affaire
degre_urgence
initier_par
observation

<N1>
Dim_energie

Hierarchie_1 <Default> <h>

code_energie
type_energie
unite_mesure
debit

<N1>

code_phase
<N1>
intitule_phase
durree_estimee_phase
desc_phase
Hierarchie_1 <Default> <h>

<N2>

Hierarchie_1 <Default> <h1>

Hierarchie_2
<h2>

Figure II.36 : Cube dimensionnel Suivi des affaires .

126

V.

Conclusion

Les cubes dimensionnels est une tape trs importante dans tout projet Data Warehouse.
Cest grce cette dernire que lutilisateur pourra utiliser et exploiter au mieux les donnes
contenues dans lentrept de donnes de manire correcte et intuitive.
Dans ce chapitre nous avons essay donc de dfinir les cubes dimensionnels en
explicitant les dimensions participantes dans chacun dentre eux. Ensuite nous avons dfini,
pour chacune des dimensions, les diffrentes hirarchies prsentes ainsi que les niveaux qui
composent ces dernires.

127

Meta Data

128

I.

Les Mta Data ou mtas donnes de lentrept

Un entrept de donnes, tant en production constante, doit tre suivi de prs.

L'administration d'un Data Warehouse revient mettre en place des processus et des
mcanismes de gestion. Ces mcanismes sont l pour assurer un meilleur fonctionnement de
lentrept. Aussi ils doivent garantir lalimentation en donnes quelques soient les
circonstances.
Afin dassurer la mise jour de lentrept de donnes, il est ncessaire de suivre son
alimentation au jour le jour, surtout dans le cas prsent o les sources de donnes sont
gographiquement disperses. Un tel suivi peut tre garantie grce au recours au mta data de
lentrept.

II.

Rle des mtas donnes

Les mtas donnes ont un rle trs important dans le cycle de vie dun entrept de
donnes. En effet, elles donnent une description ainsi quun sens aux donnes contenues dans
lentrept, afin que lutilisateur comprenne et puisse utiliser au mieux ces donnes.
Cependant, leur rle peut dpasser le cadre de cette description en se prsentant comme un
moyen de supervision et de suivi de lvolution de lentrept. Le diagramme illustr sur la
figure II.37 montre la conception des mtas donnes.
Ce diagramme reprsente, de manire claire, la structure de lentrept de donnes,
renseignant de ce fait sur sa contenance en donnes. En plus de cela, il offre la possibilit de
superviser les chargements en donnant une vue gnrale sur lalimentation de lentrept de
donnes.

129

Figure II.37 : Diagramme de classe des mtas donnes.

130

III.

Exploitation des mtas donnes

III.1

Prsentation de la partie navigation

La fonction premire des mtadonnes est doffrir un catalogue complet et dtaill sur
le contenu de lentrept. Ce catalogue est bien sr appel voluer. De ce fait lutilisateur
doit tre en mesure de consulter ce catalogue et dy proposer des mises jour, si cela est
ncessaire. Le diagramme des cas dutilisation suivant illustre ces diffrents volets :

Figure II.38 : DCU navigation dans les mtas donnes.

III.2

Prsentation de la partie supervision

Vu le nombre de sources de donnes et leurs dispersions gographiques, il se peut que

lalimentation en donnes dune des directions de distribution ne se droule pas comme prvu.
Dans ce cas, ladministrateur doit tre en mesure de dtecter les erreurs survenues lors de
lalimentation et avoir la possibilit de recourir des solutions secours. Ces solutions de
supervision et de chargement secours sont :

131

III.2.1 Supervision : ladministrateur aura la possibilit de suivre ltat des chargements

journaliers de lentrept de donnes. Ainsi, il aura une situation prcise des
chargements par direction de distribution, lui offrant de ce fait la possibilit de
dtecter les chargements chous et la date de lchec de manire recouvrir les
donnes non charges.
III.2.2 Solutions secours : lors dun chargement chou ladministrateur de lentrept de
donnes pourra utiliser lune des mthodes suivantes pour mettre jour les
donnes de lentrept :
a. Le chargement paramtr : le chargement peut se faire distance en spcifiant
les directions concernes par ce chargement et le jour du chargement concern.
Cependant, cette solution nest utilisable que pour le jour suivant lchec du
chargement et cela, soit cause de la volatilit des donnes, soit cause de la
quantit trop importante des donnes. Le paramtre de ce chargement nest autre
que les Directions de distribution concernes par le chargement.
b. Le chargement partir des fichiers de sauvegarde : durant la prsentation de la
partie alimentation de lentrept nous avons voqu les fichiers de sauvegarde.
Ces fichiers sont utiliss afin de charger les donnes manquantes en cas de
problmes. Ces fichiers, qui sont gnrs aprs chaque extraction de donnes au
niveau des directions de distribution, sont transfrs et utiliss. Une dure de
sauvegarde de ces fichiers est ncessaire, cette dure a t arrte une semaine.
Le diagramme des cas dutilisation suivant illustre les cas cits prcdemment :

Figure II.39 : DCU supervision.

132

IV.

Conclusion

La couche mta donnes est trs importante dans un projet Data Warehouse, dans la
mesure o elle en permet la maintenance de ce dernier, garantit son intgrit et facilite son
expansion.
Ainsi il est plus que ncessaire de concevoir les mtas donnes et de dvelopper une
couche applicative permettant de les maintenir. Dans ce chapitre nous avons essay de
concevoir un sous systme dadministration de lentrept de donnes qui rpond aux
exigences dun tel projet.

133

Partie III :

Ralisation et dploiement

134

I.

Introduction

Pour la ralisation et la mise en place de la solution, il a t ncessaire de recourir un

certain nombre doutils et mettre en place des environnements dexcution.
Ce chapitre a pour objectif, de dcrire lenvironnement mis en place et les outils
utiliss, ainsi que de dcrire lenvironnement existant (matriels et logiciels), et dans lequel
voluera notre systme.

II.

Implmentation

II.1

Primtre technique et fonctionnel

Cette partie dcrit les infrastructures dj en place. En effet, cette dernire est une
tape ne pas ngliger, car la diversit des sources et leurs plateformes techniques pourront
engendrer des problmes de compatibilit.
II.1.1 Matriel
Les systmes sources sont installs sur diffrentes plateformes :

Machine IBM,

Machine INTEL : HP ou DELL,

II.1.2 Systmes dexploitation

Lors de notre tude il a t recens les systmes suivants :

AIX 5.1, 5.2 pour les machines IBM,

LINUX : RedHat 4.5,

Windows Server 2003,

Solaris Sparc,

Ltude du matriel existant nous a permis de prvoir des solutions certains

problmes, tels que la non compatibilit des machines AIX 5.2 avec la version du JRE
ncessaire pour lexcution des programmes dextractions.

135

II.2 Architecture technique de la solution

La figure suivante illustre la structure et larchitecture technique de la solution propose :

Figure III.1
III : Architecture technique de la solution.

II.3

Zone de stockage

Lors de la conception, il a t question de concevoir et mettre en place deux bases de

donnes : la base de donnes de la zone dentreposage et celle des Meta data.
Le choix du systme de gestion de base de donnes sest fait en fonction de la finalit
de chaque base de donnes, de son utilisation et des
des donnes quelle contiendra.
1) Base de donnes Data Warehouse :
La base de donnes, Data Warehouse, a t implmente sous le
l SGBD open
source PostgresPlus. Cette
C
distribution de PostgreSQL, en plus du noyau PostgreSQL
connu pour ses performances par rapport aux bases de donnes volumineuses19,
intgre un ensemble doutils
doutil dadministration et de configuration. Aussi ce SGBD est
pr configur pour la mise en place dun Data Warehouse.

19

Voir annexe F.
136

2) Base de donnes Meta Data :

La base de donnes, Meta data, a t implmente sous le SGBD MySQL, qui est
un SGBD open source simple dutilisation et performant pour les petites bases de
donnes.

II.4

Zone dalimentation de lentrept

Limplmentation du processus de chargement peut se faire par le biais doutils

disponibles sur le march. Une multitude de choix soffre nous. Cependant, et vu
lorientation de lentreprise vers lopen source notre tude sest limit cette classe de
produit.
Aprs une tude comparative, le choix a t port sur Talend Open Studio dans sa
version 3.1.4r2 , connu comme loutil le plus performant de sa catgorie open source
[Daan, 2007]. Ce dernier bas sur lIDE Eclipse intgre un ensemble de composants
implments en JAVA et permet de rajouter son propre code JAVA.
Les points forts de cet outil sont :

Assurer une indpendance totale vis--vis du SGBD source, ou celui

implmentant lentrept de donnes.

Sa richesse en nombre de composants, permet lextraction de toute source de

donnes connue et standard.

Gnre des programmes en java sexcutant sur diffrentes plateformes.

Dvelopp par une communaut importante qui ne cesse daugmenter.

Permet dajouter du code java afin dimplmenter notre solution telle quelle a t
conue.

II.5

Zone de restitution

Cette zone reprsente linterface entre lutilisateur et le Data Warehouse. Elle est
constitue dun ensemble doutils qui doivent permettre aux utilisateurs dexploiter le
systme mis en place dans les meilleures conditions possibles. . Ainsi plusieurs outils et
serveurs ont t mis en place:

Un serveur web Apache permettant un accs distant.

Une plateforme BI SpagoBI pour la gestion et la diffusion des documents, ainsi

que pour son module de cration de requtes la demande Querry by exemple .

Un moteur ROLAP Mondrian , pour limplmentation des cubes conus pour

lanalyse multidimensionnelle. Ce dernier est connu comme leader des moteurs
ROLAP open source.
137

Un serveur de reporting JasperReports , pour ldition des rapports prtablis.

Ces derniers sont conus sparment et intgrs dans la plateforme SpagoBI .

Un serveur SMTP, pour la diffusion des rapports.

Implmentation des tableaux de bord conus avec loutil Open Slazio pour une
reprsentation graphiques efficace et comprhensible.

Mme si ces outils se prsentent comme des solutions cl en main, ils ncessitent un
travail dintgration et de conception afin de donner une valeur ajoute aux tats
implments.
En plus de la mise en place de ces outils, il tait ncessaire de dvelopper certains
volets:

Gestion des utilisateurs : ce module permettra la gestion des utilisateurs et des

droits daccs.

Administration et supervision de lentrept de donnes :

Navigation dans les Meta data : cela offrira un support aux utilisateurs finaux.

Ces deux modules ont t dvelopps en JavaServer Pages (JSP), qui est lextension
web du langage Java. Le dveloppement sest fait avec la version 6.5 de lIDE NetBeans. Le
choix de ce langage est en rapport avec les points suivants :

Les possibilits offertes par ce langage.

La portabilit des modules dvelopps.

Lintgration au sein du mme serveur web.

Lintgration dans la plateforme SpagoBI. Cette dernire tant dveloppe en JSP.

Lexcution au niveau serveur, offrant un niveau de scurit optimum.

138

III.

Dploiement

Pour mieux dcrire le dploiement de la solution, on utilise le modle de dploiement

U.M.L qui permet de prsenter larchitecture de dploiement dune manire simple et
comprhensible.
Comme on peut le voir, notre solution comporte trois zones : zone dalimentation,
zone de stockage et zone de restitution. Afin dillustrer cela, on propose deux diagrammes de
dploiements : Un diagramme pour la zone dalimentation et un autre diagramme pour la
zone de restitution. La zone de stockage tant lie directement aux deux autres zones sera
dcrite dans les deux modles.

III.1

Dploiement de la zone dalimentation

Figure III.2 : Digramme de dploiement de la zone dalimentation.

139

III.2

Dploiement de la zone de restitution

Figure III.3 : Diagramme de dploiement de la zone de restitution.

140

IV.

Conclusion

La partie de restitution est la partie sur laquelle lutilisateur final aura interagir. Cette
dernire a t mise en place en intgrant des solutions Open Source , et en dveloppant
certains volets de manire assurer une bonne utilisation du systme.
Des programmes ont t dvelopps, au pralable, en JAVA, afin dassurer
lalimentation de la zone de stockage en donnes. Cette dernire a t implmente sous le
SGBD PostgreSQL, dans sa distribution PostgreSQLPLUS .
Le dploiement de la solution se fait suivant les diagrammes de dploiement illustrs
dans la figure III.2 et la figure III.3, et se divise en deux parties :

Dploiement de la zone dalimentation.

Dploiement de la zone de restitution.

Le dploiement se fait pour le moment sur trois sites pilotes, et sera tendu
lensemble du territoire des que les rsultats des tests fonctionnels auront t approuvs.

141

Conclusion gnrale et perspectives

142

Conclusion gnrale et Perspectives

Exploiter les donnes disposition de lentreprise afin de leur donner de la valeur
ajoute, tel est le dfi des entreprises modernes.
Dans ce cadre, et afin de palier des problmes rcurrents dans le processus de prise
de dcision, SONELGAZ a initi le projet de ralisation dun Data Warehouse pour permettre
la mise en place dun systme dcisionnel fiable et efficace.
Tout au long de notre travail de conception et de ralisation, nous avons essay de
suivre une dmarche mixte, alliant de ce fait entre Deux approches connues dans le domaine
du Data Warehousing, savoir lapproche Besoins danalyse et lapproche Sources de
donnes . Cette dmarche a permis de rpondre aux attentes et besoins des utilisateurs tout
en exploitant au mieux les donnes gnres par les systmes oprationnels de manire
anticiper sur des besoins non exprims.
Bien que la mthode des entretiens soit loutil principal pour la collecte des besoins
dans ce travail (en effet, le milieu et lorganisation du groupe ont rendu toute autre approche
pratiquement impossible), ltude des besoins dj exprims sous forme de rapports et de
processus de prise de dcision nous ont t dune grande utilit pour dfinir de manire claire
le primtre et les besoins rels des utilisateurs. Cette tude a fait ressortir quatre sujets
danalyse dignes dintrt pour lentreprise qui sont : Les ventes, les affaires, les nouveaux
abonns, le recouvrement.
Dans un deuxime temps, la modlisation de la zone de stockage des donnes sest
faite grce aux principes de la modlisation dimensionnelle. Cette modlisation offre une
vision claire et une comprhension intuitive des modles proposs. Nous avons de ce fait
propos des modles en toiles des quartes activits recenss. Partant de chaque modle
dimensionnel, nous avons donn les modles agrgs afin damliorer les performances du
futur systme.
La partie dalimentation de la zone de stockage implmentation physique des
modles dimensionnels sur un SGBD relationnel a t sans nul doute la partie du projet la
plus fastidieuse et consommatrice en temps ; nous permettant de vrifier le postula disant
quil est ncessaire dy consacrer plus de 80% du temps de ralisation dun Data Warehouse.
Cette tape nous a permis de concevoir et de raliser, grce des outils open source, les
routines dextraction, transformation et chargement des donnes.
Lutilisation doutils et de solutions open source est un volet trs important dans ce
projet. En effet, lorientation Open Source du projet a t dcide ds linitiation de ce
dernier. Cette orientation, qui se fait ressentir durant les tapes sus cites, est plus prsente
dans la partie ralisation de la zone de restitution grce lintgration dune plateforme
BI , pour la diffusion et la gestion des documents, et doutils de Reporting et de navigation
dans les donnes compltement open source, offrant lutilisateur la possibilit dexploiter les
donnes de lentrept via nimporte quel client lger. La partie restitution a aussi ncessit le
143

dveloppement des volets de gestion des utilisateurs, dadministration de lentrept et de

supervision de ce dernier.
Pour la mise en route de la solution, nous avons entam le travail de dploiement en
choisissant des sites pilotes. Ce dploiement obit une dmarche clairement illustre grce
des digrammes de dploiement prsents 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 dacqurir une trs bonne exprience professionnelle
et dvoluer dans un domaine qui nous tait totalement inconnu savoir le domaine des
systmes dcisionnels, et au sein dun environnement regroupant des quipes de
professionnels du mtier reprsentant la filiale ELIT .
Comme un projet Data Warehouse nest jamais compltement termin, nous pouvons
citer les perspectives et les dveloppements suivants :

Suivre le dploiement actuel et recueillir les correctifs et remarques des utilisateurs.

Etendre le dploiement de manire couvrir, terme, la totalit du territoire national.

Etendre le systme vers dautres systmes oprationnels notamment les systmes de

la HP/HT et de la ressource humaine.

Utilisation des mthodes et algorithmes de Data Mining pour une meilleure

exploitation des donnes.

Continuer le dveloppement du portail de restitution.

144

Bibliographie

Ouvrages
[Bouquin, 2003] : Bouquin Henry ; Le contrle 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 ; Entrepts de Donnes : Guide Pratique de

Modlisation Dimensionnelle 2me dition ; Vuibert 2002.

[Kimball,1996] :

R. Kimball ; Entrepts de donnes : Guide pratique du concepteur de

Data Warehouse ;Wiley Computer Publishing 1996.

[Le Moigne, 1977] : Le Moigne J.L., La thorie du systme gnral, thorie de la

modlisation , P.U.F., 1977.
[Nakache, 1998] :

Didier Nakache; Data Warehouse et Data Mining ; Conservatoire

National des Arts et Mtiers de Lille; Version 1.1; 15 juin 1998.

145

Articles et Thses
[Bouzghoub, 2008] :

Abdenour Bouzghoub ; Modlisation des Entrepts de donnes

XML : Application au domaine de la scurit sociale ; Thse de
Magistre Option : SISCSD ; Institut National de Formation en
Informatique (I.N.I) 2008.

[Chouder, 2007] :

Lamri Chouder ; Entrept Distribu de Donnes ; Thse de

Magistre 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; fvrier 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] :

Ccile Favre; volution de schmas dans les entrepts de donnes;

Thse de doctorat ; Universit Lumire Lyon 2 cole
Doctorale Informatique et Information pour la Socit ; Dcembre
2007.

[Haciane, 2006] :

Ahmed Haciane ; Conception dun datawarehouse Orient CRM ;

Thse de magistre 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/viewarticles/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/16751.html ;1998.

[Soler, 2001] :

Y.Soler; PLANIFICATION ET SUIVI D'UN PROJET ; Centre

national de la recherche scientifique Direction des systmes
d'information ; http://www.dsi.cnrs.fr/conduite146

projet/phasedefinition/gestion-de-projet/planification-suiviprojet/guide-planif-suivi-projet.pdf ;2001.

147