Académique Documents
Professionnel Documents
Culture Documents
Thème
Conception et réalisation d’un Data Warehouse pour
la mise en place d’un système décisionnel
Document de base
Promotion : 2009/2010
Remerciements
Nos remerciements vont tout spécialement à nos familles, qui ont sus nous supporter et
encourager tout au long de notre vie, ainsi que pour leur aide inestimable, leur patience et
leur soutien indéfectible.
Nous tenons aussi, à remercier tout les enseignants qui ont contribué de près ou de loin
à notre formation.
Nous remercions Mme Souad Merbet et M. Nadji Medjaoui pour avoir assuré
l’encadrement de ce projet, qui n’a pas toujours été de tout repos. On remercie monsieur
Medjaoui pour nos séances de travail agréables et fructueuses, ses remarques pertinentes,
mais aussi pour son écoute et son discours bienveillants.
Nous remercions Mme Merabet pour la confiance quelle nous a accordé et de nous
avoir donné l’opportunité de travailler sur un projet d’une tel envergure.
Nous remercions Mme Ait Ali Yahia pour ces critiques constructives qui nous ont
permis d’améliorer ce mémoire.
Nous nous devons de mentionner la précieuse et totale collaboration que nous avons
reçu au sein de ELIT, de part les moyens mis à notre disposition et l’aide et le support apporté
par l’ensemble des employés et des cadres.
Pour finir, et afin de n’oublier personne (amis, membre de la famille et tous ceux qui
nous sont chers) nous utiliserons la formule : « Merci à… ».
^xw}ÇtÇx 9 Y|ÄtÄ|
Dédicaces
TuwxÜÜt{ÅtÇx
Dédicaces
A:
M es parents, pour leur soutient indéniable et leur aide précieuse
Je dédie ce travail.
fÉy|tÇx
Sommaire
Résumé :………………………………………………………………………………………..I
Abréviations :………………………………………………………………………………….II
Liste des tableaux …………………………………………………………………………….IV
Liste des figures ……………………………………………………………………………...VI
Introduction générale ................................................................................................................. 9
1. Problématique .............................................................................................................. 10
2. Objectifs du projet ........................................................................................................ 11
I
Abréviations :
BI : Business Intelligence.
BT : Basse Tension.
BP : Basse Pression.
CTI : Centre de Traitement Informatique.
DAP : Direction Analyses et Prévision.
DAR : Direction Affaires De Régulation.
DBA : Data Base Administrator.
DCF : Direction Comptabilité et Finance.
DCM: Direction Commercial Et Marketing.
DD : Direction de Distribution.
DED : Département Etudes et Développement.
DGDS : Direction Générale du Développement et de la Stratégie.
DIM : Dimension.
DR : direction régionale(DD).
DRD : Direction de Distribution Régionale.
DW : Data Warehouse (Entrepôt de données).
ED : Etude et développent.
EDW : Entreprise Data Warehouse.
EGA : Electricité et Gaz d’Algérie.
ELIT : EL-djazaïr Information Technology.
EPIC : Etablissement Publique à caractère Industriel et Commercial.
ETL : Extract, Transform and Load (ETC).
FK: Foreign Key.
FTP : File Transfer Protocol.
HOLAP: Hybrid On Line Analytical Process.
HP : Haute Pression.
HT : Haute Tension.
MOLAP: Multidimensional On Line Analytical Process.
MP: Moyenne Pression.
MT : Moyenne Tension.
OLAP : On Line Analytical Process.
OLTP: On Line Transactional Process.
II
PDG: Président Directeur General.
PK : Primary Key.
ROLAP : Relational On Line Analytical Process.
SD : Socièté de Distribution.
SGC : Système de Gestion de la Clientèle.
SI : Systèmes d’Information.
SID: Systèmes d’Information Décisionnels.
SID : Systèmes d’information de la distribution.
SIAD : Systèmes d’Information d’Aide à la Décision
SGBD : Système de Gestion de Base de Données.
SMTP : Server Mail Transfer Protocol.
SONELGAZ : Société Nationale de l’Electricité et du GAZ.
SPA : Société Par Action.
SQL : Structured Query Language.
III
Liste des tableaux
IV
Tableau II.26 : Tableau descriptif des agrégats potentiels du modèle « Suivi abonnés » ....... 89
Tableau II.27 : Tableau descriptif des agrégats utiles du modèle « Suivi abonnés ».............. 89
Tableau II.28 : Tableau donnant les nivaux hiérarchiques de chaque dimension ................... 10
Tableau II.29 : Listes des cubes dimensionnels .................................................................... 107
V
Liste des figures
Figure I.1 : Le décisionnel au sein du système d’information ............................................ 9
Figure I.2 : Les différentes composantes du décisionnel .................................................... 5
Figure I.3 : Historique des bases de données décisionnelles ............................................... 8
Figure I.4 : Structure des données d’un Data Warehouse ................................................... 9
Figure I.5 : Les Data Mart dans un entrepôt de données selon l’architecture proposée par
B. Inmon dite Entreprise Data Warehouse ........................................................................... 11
Figure I.6 : Les Data Mart dans un entrepôt de données selon l’architecture proposée par
R. kimball dite approche bus ................................................................................................ 13
Figure I.7 : Architecture globale d’un Data Warehouse.................................................... 13
Figure I.8 : Considération d’un sujet d’analyse comme un cube à plusieurs dimensions . 14
Figure I.9 : Un modèle dimensionnel typique ................................................................... 15
Figure I.10 : Principe de l’architecture MOLAP ................................................................. 18
Figure I.11 : Principe de l’architecture ROLAP .................................................................. 18
Figure I.12 : Exemple de Slicing ......................................................................................... 20
Figure I.13 : Exemple de Dicing ......................................................................................... 20
Figure I.14 : Exemple de Roll up ........................................................................................ 21
Figure I.15 : Exemple de Drill Down .................................................................................. 21
Figure I.16 : Illustration de l’approche « Besoin d’analyse » grâce au cycle de vie
dimensionnel de kimball ....................................................................................................... 22
Figure I.17 : Illustration de l’approche « source de données » grâce au cycle de
développement du Data Warehouse de Inmon ..................................................................... 23
Figure I.18 : Illustration de l’approche mixte ...................................................................... 24
Figure I.19 : Objectif de qualité de données dans un processus E.T.L ............................... 27
Figure II.1 : Planification de la conduite du projet ............................................................. 34
Figure II.2 : Organigramme représentant l’organisation du Groupe SONELGAZ ............ 37
Figure II.3 : Evolution du chiffre d’affaire du groupe publiée dans le rapport d’activité de
l’année 2008 ………………………………………………………………………………38
Figure II.4 : Répartition du chiffre d’affaire publiée dans le rapport d’activité de l’année
2008………… ...................................................................................................................... 39
Figure II.5 : Organisation des sociétés de distribution ....................................................... 40
Figure II.6 : Organisation des directions de distribution .................................................... 41
Figure II.7 : Organisation de la filiale ELIT ....................................................................... 44
Figure II.8 : Organisation de la direction d’étude et de développement............................. 44
Figure II.9 : Diagramme d’activité modélisant l’édition de rapport pour le niveau groupe48
VI
Figure II.10 : La place de l’étape de définition des besoins dans un projet Data
Warehouse………………………………………………………………………………….52
Figure II.11 : Analyse des priorités du cas de la distribution « SONELGAZ »................ 60
Figure II.12 : La dimension du Temps de l’activité « Vente » ......................................... 64
Figure II.13 : La dimension client de l’activité « Vente » ................................................ 65
Figure II.14 : La dimension facture de l’activité « Vente » .............................................. 68
Figure II.15 : La dimension zone de l’activité « Vente ».................................................. 70
Figure II.16 : La dimension activité de l’activité « Vente » ............................................. 70
Figure II.17 : La dimension Tarif de l’activité « Vente » ................................................. 70
Figure II.18 : La dimension énergie de l’activité « Vente » ............................................. 71
Figure II.19 : Modèle en étoile de l’activité « Vente » ..................................................... 74
Figure II.20 : La dimension Nature de l’activité « Recouvrement »................................. 78
Figure II.21 : Modèle en étoile de l’activité « Recouvrement » ....................................... 79
Figure II.22 : La dimension affaire de l’activité «Suivi des affaires ».............................. 83
Figure II.23 : La dimension type affaire de l’activité « Suivi des affaires »..................... 82
Figure II.24 : La dimension phase de l’activité « suivie des affaires » ............................. 83
Figure II.25 : Modèle en étoile de l’activité « Suivie des affaires » ................................. 84
Figure II.26 : La dimension type abonné de l’activité « Suivi des abonné » .................... 87
Figure II.27 : Modèle en étoile de l’activité « Suivi des abonné » ................................... 88
Figure II.28 : Architecture global du processus E.T.L ...................................................... 95
Figure II.29 : Diagramme d’activité du processus d’alimentation .................................... 94
Figure II.30 : Diagramme d’activité du processus de chargement de dimension ............. 98
Figure II.31 : Diagramme d’activité du processus de chargement de fait......................... 99
Figure II.32 : Cube dimensionnel « Suivi des ventes ». .................................................. 109
Figure II.33 : Cube dimensionnel « Suivi des ventes et des consommations ». ............. 110
Figure II.34 : Cube dimensionnel « Suivi des abonnés ». ............................................... 111
Figure II.35 : Cube dimensionnel « Suivi des recouvrements ». .................................... 111
Figure II.36 : Cube dimensionnel « Suivi des affaires ». ................................................ 112
Figure II.37 : Diagramme de classe des métadonnées .................................................... 115
Figure II.38 : DCU navigation dans les métadonnées et administration des MAJ
utilisateurs………… ........................................................................................................... 116
Figure II.39 : DCU de supervision. ................................................................................. 117
Figure II.40 : Architecture technique de la solution. ...................................................... 121
Figure II.41 : Digramme de déploiement de la zone d’alimentation. ............................. 125
Figure II.42 : Diagramme de déploiement de la zone de restitution. .............................. 126
VII
Introduction générale
8
Contexte général
C’est dans un environnement fortement complexe et hautement concurrentiel
qu’évolue la majeure partie, si ce n’est la totalité, des entreprises. Ce climat de forte
concurrence exige de ces entreprises une surveillance très étroite du marché afin de ne pas se
laisser distancer par les concurrents et cela en répondant, le plus rapidement possible, aux
attentes du marché, de leur clientèle et de leurs partenaires.
C’est dans ce contexte que les « systèmes décisionnels » ont vu le jour. Ils offrent
aux décideurs des informations de qualité sur lesquelles ils pourront s’appuyer pour arrêter
leurs choix décisionnels. Pour se faire, ces systèmes utilisent un large éventail de technologies
et de méthodes, dont les « entrepôts de données » (Data Warehouse) représentent l’élément
principal et incontournable pour la mise en place d’un bon système décisionnel.
Le présent projet tend à la mise en place d’un système en mesure de consolider les
données issues des systèmes transactionnels, et d’offrir des informations de qualité pour les
décideurs. Il s’agit en fait de mettre à la disposition des décideurs des données à même de
les éclairer et leur faciliter une prise de décision prompte en connaissance de cause. Un tel
système requiert la mise en place d’un entrepôt de données fiables contenant les informations
nécessaires à l’accomplissement des processus décisionnels.
9
1. Problématique
Le groupe SONELGAZ est l’opérateur historique et leader du domaine énergétique en
Algérie, notamment dans le domaine de la distribution de l’électricité et du gaz pour les
professionnels et les particuliers.
Appelé à interagir avec ses clients sur différentes phases de la distribution (demande
de branchement, facturation, résiliation,…etc.), le groupe s’est doté, dans un souci de suivi de
la clientèle et de gestion de la distribution, d’un « Système de Gestion de la Clientèle –S.G.C.-
» constitué de 35 applications, développées en interne et exploité par plus de 2900
utilisateurs. Ce système est déployé dans chacune des 58 directions de distributions « D.D. »
exploitant une base de donnée décentralisée au niveau de chaque « D.D. ».
Dans un pareil contexte, la plus simple des opérations d’analyse devient une tâche
ardue. En effet, les sociétés de distributions « SD » se trouvent dans l’incapacité de faire des
analyses fiables, efficaces et à des moments opportuns sans engager des moyens considérables
sur des périodes plus ou moins longues. Ainsi, les principales difficultés rencontrées peuvent
être résumées en :
1
Voir annexe A
10
problèmes dû au fait qu’il interroge directement la base de données en production. En
effet le lancement de la production de n’importe quel rapport du module pénalise le
système. Pour éviter cela le module n’est accessible qu’au chef du CTI de la DD.
2. Objectifs du projet
Afin de palier aux problèmes précédemment cités, le groupe a initié, à travers sa filiale
Elit, le présent projet.
11
Planification et conduite du projet
L’initiation de tout
out projet nécessite une phase de planification. Celle Celle-ci permet
de définir les tâches à réaliser, maîtriser les risques et rendre compte de l’état d’avancement
du projet.
Pour garantir le bon déroulement du projet, tout en respectant les délais, nous avons
élaboré une planification globale de conduite du projet. Le diagramme suivant décrit cette
planification ainsi que l’ordonnancement prévu des phases du projet.
Conception E.T.L
Afin de présenter notre travail, le présent mémoire est organisé en trois parties et se
présente comme suit :
Après une introduction générale dans laquelle nous présentons le contexte général du
projet, ainsi que la problématique et les objectifs visés. La première partie présente les aspects
théoriques du domaine des systèmes d’information d’aide à la décision, en évoquant leurs
définitions et les concepts de bases relatifs aux « entrepôts de données » et à la modélisation
dimensionnelle.
12
Dans la deuxième partie, nous présentons le travail réalisé au sein du Groupe
SONELGAZ à travers les six suivants chapitres:
Le chapitre trois présente une synthèse de la collecte des besoins des utilisateurs, ainsi
que son déroulement.
Le chapitre six, quant à lui, donne la conception des cubes dimensionnels en détaillant
les différentes caractéristiques de chaque cube (dimensions, mesurables et hiérarchies).
Une conclusion générale est proposée afin de synthétiser le travail réalisé et de citer
les perspectives du projet.
13
Partie I : Synthèse
bibliographique
14
I. Introduction
Toutes les entreprises du monde disposent d’une masse de données plus ou moins
considérable. Ces informations proviennent soit de sources internes (générées par leurs
systèmes opérationnels au fil des activités journalières), ou bien de sources externes (web,
partenaire, .. etc.).
Le concept de Data Warehouse, tel que connu aujourd’hui, est apparu pour la première
fois en 1980 ; l’idée consistait alors à réaliser une base de données destinée exclusivement au
processus décisionnel. Les nouveaux besoins de l’entreprise, les quantités importantes de
données produites par les systèmes opérationnels et l’apparition des technologies aptes à sa
mise en œuvre ont contribué à l’apparition du concept « Data Warehouse » comme support
aux systèmes décisionnels.
Afin de mieux comprendre la finalité des systèmes décisionnels, nous nous devons de les
placer dans leurs contextes et rappeler ce qu’est un système d’information.
«Le système d’information est l’ensemble des méthodes et moyens de recueil de contrôle
et de distribution des informations nécessaires à l’exercice de l’activité en tout point de
l’organisation. Il a pour fonction de produire et de mémoriser les informations, de l’activité
du système opérant (système opérationnel), puis de les mettre à disposition du système de
décision (système de pilotage)»[Le Moigne, 1977].
15
Les origines des SID remontent au début de l’informatique et des systèmes d’information
qui ont, tous deux, connu une grande et complexe évolution liée notamment à la technologie.
Cette évolution se poursuit à ce jour2.
Parmi les différentes définitions du décisionnel « business intelligence B.I. » qui ont été
données on trouve :
• "Le Décisionnel est le processus visant à transformer les données en informations et,
par l'intermédiaire d'interrogations successives, transformer ces informations en
connaissances." [Dresner, 2001].
La figure ci-dessus
dessus illustre parfaitement la place qui
qu revient au décisi
décisionnel au sein
d’une entreprise. Cette place,, comprend plusieurs fonctions clés de l’entreprise. Les finalités
décisionnelles, étant différentes selon le poste et la fonction occupée,
occupée on ont pour but
d’engendrer plusieurs composantes.
2
Synthétisation à partir de la thèse de Bouzghoub A. « Modélisation des entrepôts de données XML:
application au domaine de la sécurité sociale » [Bouzghoub, 2008].
16
I.1.2. Les différentess composantes du décisionnel
17
I.3. Décisionnel vs transactionnel
Le tableau suivant résume de façon non exhaustive les différences qu’il peut y avoir
entre les systèmes transactionnels et les systèmes décisionnels selon les données et l’usage fait
des systèmes.
transparentes
Temps de réponse immédiats Temps de réponse moins critiques
Faibles volumes à chaque transaction Large volume manipulé
Conçu pour la mise à jour Conçue pour l’extraction
Usage maîtrisé Usage aléatoire
Tableau I.1 : Tableau comparatif entre les systèmes transactionnels et les systèmes
décisionnels.
Ces différences font ressortir la nécessité de mettre en place un système répondant aux
besoins décisionnels. Ce système n’est rien d’autre que le « Data Warehouse ».
18
II. Le Data Warehouse
II.1 Qu’est ce qu’un Data Warehouse
Bill Inmon définit le Data Warehouse, dans son livre considéré comme étant la référence
dans le domaine “Building the Data Warehouse” [Inmon, 2002] comme suit:
« Le Data Warehouse est une collection de données orientées sujet, intégrées, non
volatiles et évolutives dans le temps, organisées pour le support d’un processus d’aide à
la décision. »
Les paragraphes suivants illustrent les caractéristiques citées dans la définition d’Inmon.
Orienté sujet : le Data Warehouse est organisé autour des sujets majeurs de l’entreprise,
contrairement à l’approche transactionnelle utilisée dans les systèmes opérationnels, qui sont
conçus autour d’applications et de fonctions telles que : cartes bancaires, solvabilité client…,
les Data Warehouse sont organisés autour de sujets majeurs de l’entreprise tels que : clientèle,
ventes, produits…. Cette organisation affecte forcément la conception et l’implémentation des
données contenues dans le Data Warehouse. Le contenu en données et en relations entre elles
diffère aussi. Dans un système opérationnel, les données sont essentiellement destinées à
satisfaire un processus fonctionnel et obéit à des règles de gestion, alors que celles d’un Data
Warehouse sont destinées à un processus analytique.
Evolutives dans le temps : Dans un système décisionnel il est important de conserver les
différentes valeurs d’une donnée, cela permet les comparaisons et le suivi de l’évolution des
valeurs dans le temps, alors que dans un système opérationnel la valeur d’une donnée est
simplement mise à jour. Dans un Data Warehouse chaque valeur est associée à un moment
« Every key structure in the data warehouse contains - implicitly or explicitly -an element of
time » [Inmon, 2000].
Non volatiles : c’est ce qui est, en quelque sorte la conséquence de l’historisation décrite
précédemment. Une donnée dans un environnement opérationnel peut être mise à jour ou
supprimée, de telles opérations n’existent pas dans un environnement Data Warehouse.
Organisées pour le support d’un processus d’aide à la décision : Les données du Data
Warehouse sont organisées de manière à permettre l’exécution des processus d’aide à la
décision (Reporting, Data Mining…).
19
II.2 Historique des Data Warehouse
L’origine du concept « Data Warehouse » D.W (entrepôt de données en français) remonte
aux années 80, durant lesquelles un intérêt croissant au système décisionnel a vu le jour, dû
essentiellement à l’émergence des SGBD relationnel et la simplicité du modèle relationnel et
la puissance offerte par le langage SQL,
Au début, le Data Warehouse n’était rien d’autre qu’une copie des données du système
opérationnel prise de façon périodique, dédiée à un environnement de support à la prise de
décision. Ainsi, les données étaient extraites du système opérationnel, stockées dans une
nouvelle base de données «concept d’infocentre », le motif principal étant de répondre aux
requêtes des décideurs sans pour autant altérer les performances des systèmes opérationnels.
Le Data Warehouse, tel qu’on le connaît actuellement, n’est plus vu comme une copie
-ou un cumul de copies prises de façon périodique- des données du système opérationnel. Il
est devenu une nouvelle source d’information, alimenté avec des données recueillies et
consolidées des différentes sources internes et externes.
Entrepôt de
données
Infocentre
bases de
données
opérationnelles
20
II.3 Structure des données d’un Data Warehouse
Le Data Warehouse a une structure bien définie, selon différents niveaux d’agrégation
et de détail des données. Cette structure est définie par Inmon [Inmon, 2000] comme suit :
M Données agrégées
E
T
A
D
O
N
N Données détaillées
É
E
S
Données détaillées : ce sont les données qui reflètent les événements les plus récents,
fréquemment consultées, généralement volumineuses car elles sont d’un niveau détaillé.
Données fortement agrégées : données agrégées à partir des données détaillées, à un niveau
d’agrégation plus élevé que les données agrégées.
21
Meta données : ce sont les informations relatives à la structure des données, les méthodes
d’agrégation et le lien entre les données opérationnelles et celles du Data Warehouse. Les
métadonnées doivent renseigner sur :
• Le modèle de données,
• La structure des données telle qu’elle est vue par les développeurs,
• La structure des données telle qu’elle est vue par les utilisateurs,
• Les sources des données,
• Les transformations nécessaires,
• Suivi des alimentations,
Préparation des données : la préparation englobe tout ce qu’il y a entre les applications
opérationnelles et la présentation des données. Elle est constituée d’un ensemble de processus
appelé ETL, « Extract, transform and Load », les données sont extraites et stockées pour subir
les transformations nécessaires avant leur chargement.
Présentation des données : c’est l’entrepôt où les données sont organisées et stockées. Si les
données de la zone de préparation sont interdites aux utilisateurs, la zone de présentation est
tout ce que l’utilisateur voit et touche par le biais des outils d’accès.
L’entrepôt de données est constitué d’un ensemble de Data Mart. Ce dernier est défini
comme étant une miniaturisation d’un Data Warehouse, construit autour d’un sujet précis
d’analyse ou consacré à un niveau départemental3.
3
Synthétisation [Chuck, 1998] page 86.
22
1. Data Mart indépendant
Les Data Mart sont des versions miniaturisées du Data Warehouse au niveau
départemental, alimentéess par le Data Warehouse et baséess sur les besoins départementaux en
informations [Inmon, 2002].
Figure I.5 : les Data Mart dans un entrepôt de données selon l’architecture Entreprise Data
Warehouse (E.D.W) [Inmon, 2002].
23
2. Data Mart interconnectés
Les
es Data Mart sont construits
construi autour de sujets, interconnectés grâce aux tables des
faits contenues dans le Data Warehouse, ce dernier se compose alors des Data Mart et ces
tables des faits, appelées bus4.
Figure I.6 : les Data Mart dans un entrepôt de données selon l’architecture bus de données
[Kimball, 2002].
Zone d’outils d’accès : c’est l’ensemble des moyens fournis aux utilisateurs du Data
Warehouse pour exploiter la zone de présentation des données en vue de la prise de décision.
Ces outils varient des simples requêtes ad hoc aux outils permettant l’application de forage de
données plus complexes.. Environ 80 à 90% des utilisateurs sont desservis par des applications
d’analyses préfabriquées, consistaant essentiellement en des requêtes préétablies.
s.
4
Appellation proposée par R. Kimball dans son ouvrage [Kimball, 2002].
24
II.5 Architecture d’un Data Warehouse
Après avoir exposé et défini chacun des éléments constituant l’environnement d’un Data
Warehouse, il serait intéressant de connaitre le positionnement de ces éléments dans une
architecture globale d’un Data Warehouse :
5
http://www.formations-sas.fr/data-warehouse
25
III. Modélisation des données de l’entrepôt
III.1 La modélisation dimensionnelle et ses concepts
Les Data Warehouse sont destinés à la mise en place de systèmes décisionnels. Ces
systèmes, devant répondre à des objectifs différents des systèmes transactionnels, ont fait
ressortir très vite la nécessité de recourir à un modèle de données simplifié et aisément
compréhensible. La modélisation dimensionnelle permet cela. Elle consiste à considérer un
sujet d’analyse comme un cube à plusieurs dimensions, offrant des vues en tranches ou des
analyses selon différents axes.
Figure I.8 : Considération d’un sujet d’analyse comme un cube à plusieurs dimensions.
La nomination « schéma des jointures en étoile » a longtemps été adoptée pour décrire
un modèle dimensionnel. Cette nomination est due au fait que le diagramme qui représente un
modèle dimensionnel ressemble à une étoile, avec une grande table centrale et un jeu de
petites tables auxiliaires disposées en étoile autour de la table centrale. Celle-ci est appelée
table de faits et les autres tables sont appelées tables de dimensions. La figure suivante
illustre untel modèle :
26
Figure I.9 : Un modèle dimensionnel typique [Kimball, 1996].
Une table de faits est la table centrale d’un modèle dimensionnel, où les mesures de
performances sont stockées. Une ligne d’une table de faits correspond à une mesure. Ces
mesures sont généralement des valeurs numériques, additives ; cependant des mesures
textuelles peuvent exister mais sont rares. Le concepteur doit faire son possible pour faire des
mesures textuelles des dimensions, car elles peuvent êtres corrélées efficacement avec les
autres attributs textuels de dimensions.
Une table de faits assure les liens plusieurs à plusieurs entre les dimensions. Elles
comportent des clés étrangères, qui ne sont autres que les clés primaires des tables de
dimension.
Les tables de dimension sont les tables qui raccompagnent une table de faits, elles
contiennent les descriptions textuelles de l’activité. Une table de dimension est constituée de
nombreuses colonnes qui décrivent une ligne. C’est grâce à cette table que l’entrepôt de
données est compréhensible et utilisable; elles permettent des analyses en tranches et en dés.
Une dimension est généralement constituée : d’une clé artificielle, une clé naturelle et
des attributs.
« Une table de dimension établit l’interface homme / entrepôt, elle comporte une clé
primaire » [Kimball, 2002].
27
III.1.3 Comparatif entre les tables de faits et les tables de dimensions
Le tableau suivant récapitule les différences au niveau des données de ces tables :
Tableau I.2 : Tableau comparatif entre les tables de faits et les tables de dimensions.
Modèle en flocon : identique au modèle en étoile, sauf que ses branches sont éclatées
en hiérarchies. Cette modélisation est généralement justifiée par l’économie d’espace de
stockage, cependant elle peut s’avérer moins compréhensible pour l’utilisateur final, et très
couteuse en terme de performances.
Modèle en constellation : Ce n’est rien d’autre que plusieurs modèles en étoile liés
entre eux par des dimensions communes.
28
III.3 Le concept OLAP
III.3.1 Généralités
C’est en continuant sur sa lancée, qui lui a permis de définir le model OLTP pour les
bases de données relationnelles, que le concept OLAP fut introduit et défini6 en 1993 par E.F
Codd, le père des bases de données relationnelles, dans un document technique portant le titre
de « Providing OLAP (On-Line Analytical Processing) to User-Analysts : An IT Man-date »
[Codd, 1993].
6
Cette définition passe par l’introduction de 12 règles. Six autres règles furent par la suite, en 1995, ajoutées
aux 12 précédentes et le terme « règles » remplacé par dispositif «features » par le même auteur à savoir
Codd (Voir annexe B).
29
Data Warehouse Moteur MOLAP Aide à la décision
30
III.2.2.3 Les systèmes à architecture HOLAP
Les systèmes HOLAP « Hybride On-line Analytical Processing » sont une sorte de
compromis entre les différents systèmes précités. Cette combinaison donne à ce type de
système les avantages du ROLAP et du MOLAP en utilisant tour à tour l’un ou l’autre selon
le type de données.
31
Figure I.12
I : Exemple de Slicing.
Le Dicing, quant à lui, peut être vu comme étant une extraction d’un sous cube.
Figure I.13
I : Exemple de Dicing.
32
Ces opérations ne sont pas aussi faciles à implémenter car basées sur la notion d’une
bonne hiérarchisation des attributs d’une dimension et la différenciation entre tous les niveaux
de hiérarchie disponibles dans les différentes dimensions.
33
IV. Démarche de Construction d’un Data Warehouse
Plusieurs chercheurs ou équipes de recherche ont essayé de proposer des démarches
pour la réalisation d’un projet Data Warehouse, ces démarches se croisent essentiellement
dans les étapes suivantes :
Aucune des deux approches citées n’est ni parfaite, ni applicable à tous les cas. Toutes
deux doivent être étudiées pour choisir celle qui s’adapte le mieux à notre cas.
Le contenu du Data Warehouse sera déterminé selon les besoins de l’utilisateur final.
Cette approche est aussi appelée « approche descendante » (Top-Down Approach) et est
illustrée par R. Kimball grâce à son cycle de vie dimensionnel comme suit :
34
Avantages Inconvénients
Aucun risque de concevoir une solution Pas de prise en compte de l’évolution des
obsolète avant d’être opérationnelle besoins de l’utilisateur. Nécessite une
modification de la structure du Data
Warehouse en cas de nouveau besoin
Le contenu du Data Warehouse est déterminé selon les sources de données. Cette
approche est appelée : Approche ascendante (Bottom-up Approach).
35
Inmon considère que l’utilisateur ne peut jamais déterminer ses besoins dès le départ,
« Donnez moi ce que je vous demande, et je vous direz ce dont j’ai vraiment besoin »7, il
considère que les besoins sont en constante évolution.
Avantages Inconvénients
Meilleure prise en charge de l’évolution des Risque de concevoir une solution obsolète
besoins avant qu’elle soit opérationnelle
Une combinaison des deux approches appelée hybride ou mixte peut s’avérer efficace.
Elle prend en considération les sources de données et les besoins des utilisateurs.
Cette approche consiste à construire des schémas dimensionnels à partir des structures
des données du système opérationnel, et les valider par rapport aux besoins analytiques. Cette
approche cumule les avantages et quelques inconvénients des deux approches déjà citées,
telles que la complexité des sources de données et la difficulté quant à la détermination des
besoins analytiques.
“Give me what I tell you I want, then I can tell you what I really want.”[Inmon, 2002]
7
36
Cette étape aboutit à l’établissement du modèle dimensionnel validé du Data
Warehouse. Ce modèle dimensionnel sera transformé en modèle physique, qui différera du
modèle dimensionnel.
• Extraction des données primaires (issues par exemple des systèmes de production),
• Transformation des données,
• Le chargement des données traitées dans l’entrepôt de données,
Ces trois étapes décrivent une mécanique cyclique qui a pour but de garantir
l’alimentation du Data Warehouse en données homogènes, propres et fiables.
Lors du chargement des données, il faut extraire les nouvelles données ainsi que les
changements intervenus sur ces données. Pour cela, il existe trois stratégies de capture de
changement :
• Colonnes d’audit : la colonne d’audit, est une colonne qui enregistre la date
d’insertion ou du dernier changement d’un enregistrement. Cette colonne est mise à jour soit
par des triggers ou par les applications opérationnelles, d’où la nécessité de vérifier leur
fiabilité.
• Capture des logs : certains outils ETL utilisent les fichiers logs des systèmes sources
afin de détecter les changements (généralement logs du SGBD). En plus de l’absence de cette
fonctionnalité sur certains outils ETL du marché, l’effacement des fichiers logs engendre la
perte de toute information relative aux transactions.
37
• Comparaison avec le dernier chargement : le processus d’extraction sauvegarde des
copies des chargements antérieurs, de manière à procéder à une comparaison lors de chaque
nouvelle extraction. Il est impossible de rater un nouvel enregistrement avec cette méthode.
La transformation est la seconde phase du processus. Cette étape, qui du reste est très
importante, assure en réalité plusieurs tâches qui garantissent la fiabilité des données et leurs
qualités. Ces tâches sont :
Cette opération se solde par la production d’informations dignes d’intérêt pour l’entreprise
et de et sont donc prêtes à être entreposées.
C’est la dernière phase de l’alimentation d’un entrepôt de données, le chargement est une
étape indispensable. Elle reste toute fois très délicate et exige une certaine connaissance des
structures du système de gestion de la base de données (tables et index) afin d’optimiser au
mieux le processus.
• Pull : contrairement de la méthode précédente, le Pull " tire " les données de la source
vers la zone de préparation. L'inconvénient de cette méthode est qu'elle peut
surcharger le système s'il est en cours d'utilisation.
• Push-pull : c'est la combinaison des deux méthodes. La source prépare les données à
envoyer et indique à la zone de préparation qu'elle est prête. La zone de préparation
va alors récupérer les données.
8
http://grim.developpez.com/articles/concepts/etl/
38
Aussi, le processus d’alimentation doit répondre à certaines exigences illustrées par la
figure suivante :
Être correctif
Être rapide Être sûr
Processus
ETL
Être transparent
Figure I.19 : Objectif de qualité de données dans un processus ETL [Kimball, 2004].
39
IV.2.3 Les outils E.T.L.
a. Requêtage ad-hoc :
Le requêtage ad-hoc reste très fréquent dans ce type de projet. En effet, les utilisateurs
de l’entrepôt de données, et spécialement les analystes, seront amenés à interagir avec le DW
via des requêtes ad-hoc dans le but de faire les analyses requises par leurs métiers et,
d’élaborer aussi, des rapports et des tableaux de bords spécifiques.
b. Reporting :
Ces outils de Reporting ne sont pas, à proprement parler, des instruments d'aide à la
décision, mais, lorsqu’ils sont utilisés de manière appropriée, ils peuvent fournir une précieuse
vue d’ensemble.
Les rapports sont alors crées par le biais d’outils de Reporting qui permettent de leur
donner un format prédéterminé. Les requêtes sont constituées lors de l’élaboration des
rapports qui seront ensuite diffusés périodiquement en automatique ou ponctuellement à la
demande.
9
http://fr.wikipedia.org/wiki/Reporting
40
c. Analyse dimensionnelle des données:
L’analyse dimensionnelle est sans doute celle qui exploite et fait ressortir au mieux les
capacités de l’entrepôt de données. Le but par l’analyse dimensionnelle est d’offrir aux
utilisateurs la possibilité d’analyser les données selon différents critères afin de confirmer une
tendance ou suivre les performances de l’entreprise.
Cette analyse se fait selon le principe OLAP, offrant de ce fait aux utilisateurs les
possibilités de recourir à différentes opérations facilitant la navigation dans les données. La
mise en place de ces outils est une option très intéressante dans la mesure où les données
seront accessibles en analyses instantanées. Plusieurs fournisseurs de solution OLAP existent
sur le marché et offrent des solutions construites sur des méthodes et technologies différentes.
C’est d’ailleurs pour cela que le choix de la solution doit se faire au préalable, selon les
besoins en utilisation, la taille de l’entrepôt et les moyens techniques disponibles.
d. Tableaux de bord :
Les tableaux de bord sont un outil de pilotage qui donne une vision sur l’évolution
d’un processus, afin de permettre aux responsables de mettre en place des actions correctives.
e. Data Mining :
Le recours à ce genre de méthode est de plus en plus utilisé dans les entreprises
modernes. Les applications et outils implémentant ces solutions sont rarement développés en
interne. En effet, les entreprises préfèrent se reposer sur des valeurs sûres du marché afin
d’exploiter au plus vite les données en leur possession.
41
IV.4 Maintenance et expansion
La mise en service du Data Warehouse ne signifie pas la fin du projet, car un projet
Data Warehouse nécessite un suivi constant compte tenu des besoins d’optimisation de
performance et ou d’expansion. Il est donc nécessaire d’investir dans les domaines suivants
[Kimball, 2002] :
Support : assurer un support aux utilisateurs pour leur faire apprécier l’utilisation de
l’entrepôt de données. En outre, la relation directe avec les utilisateurs permet de détecter les
correctifs nécessaires à apporter.
42
V. Conclusion
Le concept « Data Warehouse » est apparu comme une réponse à des besoins
grandissants dans le domaine décisionnel. Son adaptabilité et sa capacité de fournir les
données nécessaires à une bonne analyse, ont fait de lui un atout majeur et incontournable
pour toute entreprise soucieuse du suivi de ces performances.
Au cours de la seconde partie de cette étude, nous allons essayer d’utiliser les
concepts présentés dans la synthèse bibliographique, et cela afin de mettre en œuvre notre
système.
43
Partie II : Cas pratique « filiales de
distribution SONELGAZ »
44
Chapitre I : Présentation de l’organisme
d’accueil.
45
I. Présentation de SONELGAZ
I.1 Historique
SONELGAZ est l’opérateur historique dans le domaine de la fourniture des énergies
électrique et gazière en Algérie. Ses missions principales sont la production, le transport et la
distribution de l’électricité ainsi que le transport et la distribution du gaz par canalisations.
Son nouveau statut lui confère la possibilité d’intervenir dans d’autres segments d’activités
présentant un intérêt pour l’entreprise et notamment dans le domaine de la commercialisation
de l’électricité et du gaz à l’étranger. Durant son existence le groupe a connu des évolutions
majeures qui peuvent être résumées comme suit :
1947, Création d’EGA : C’est le décret du 5 juin 1947 qui a crée l’Etablissement Public
National « Electricité et Gaz d’Algérie » (EGA par abréviation). Par décret du 16 août 1947,
seize sociétés qui se partageaient les concessions électriques ont été transférées à EGA. Ces
sociétés détenaient alors 90% des propriétés industrielles électriques et gazières du pays.
1962, Le défi de la relève : Cette année représente la prise en main de l’Algérie indépendante
de la SONELGAZ –alors Electricité et Gaz d’Algérie – et cela en faisant face au départ
massif de cadres et techniciens français.
Période allant de 1962 à 1969 : Cette période a été caractérisée par la baisse de la
consommation (une baisse de prés de 33% en deux ans) dû au départ massive des étrangers
qui représentaient plus de 87% de la clientèle. Par ailleurs, les tâches les plus urgentes ont été
de reprendre le fichier des abonnés, reconstituer les plans des ouvrages et des réseaux,
procéder au recrutement et à la formation dans tous les domaines et de ramener le niveau de
consommation de l’énergie à celui de 1961.
1977, le plan national d’électrification : Dès le milieu des années 70, l’Algérie s’est
engagée dans un ambitieux plan national d’électrification qui avait objectif l’amélioration des
conditions de vie des populations des campagnes tout en assurant un développement
harmonieux de l’espace rural.
1983, naissance des entreprises travaux : six entreprises autonomes voient le jour :
KAHRIF pour l’électrification; KAHRAKIB - Infrastructures et installations électriques;
KANAGAZ - Réalisation des réseaux gaz; INERGA - Génie civil; ETTERKIB – Montage
industriel et l’entreprise AMC - Fabrication des compteurs et appareils de mesure et de
contrôle.
46
1991, SONELGAZ EPIC : SONELGAZ change de nature juridique et devient Etablissement
Public à caractère Industriel et Commercial (EPIC) en vertu du décret exécutif n° 91-475 du
14 décembre 1991, portant transformation de la nature juridique de la Société Nationale de
l’Electricité et du Gaz. Le décret exécutif n° 95-280 du 17 septembre 1995 confirme la nature
de SONELGAZ en tant qu’Etablissement Public à caractère Industriel et Commercial.
1998, création de filiales périphériques : Le 1er janvier 1998, neuf filiales périphériques ont
vu le jour.
Juin 2002, SONELGAZ SPA : En vertu du décret présidentiel n° 02-195 du 1er juin 2002
portant statuts de la Société algérienne de l’électricité et du gaz dénommée "SONELGAZ.
Spa", SONELGAZ est passé d’Etablissement Public à caractère Industriel et Commercial à
une Société Par Actions dont le capital est détenu par l’Etat.
Sur le plan de son fonctionnement, SONELGAZ Spa est dotée d’une Assemblée Générale et
d’un Conseil d’Administration. Elle est dirigée par un Président directeur général.
Filiales Métiers de base : Durant ces cinq dernières années, les métiers de base de
SONELGAZ ont été érigés en filiales. Au nombre de huit, ces dernières activent dans les
domaines de la production, la gestion du réseau de transport, la gestion du système
production / transport, la distribution de l’électricité et du gaz (quatre sociétés).
47
Sociétés en Participation : SONELGAZ s’est investie dans des domaines clés à haute
valeur technologique tels que les télécommunications ou la maintenance de turbines à gaz.
48
I.1.2 Le groupe en chiffres
Le tableau suivant donne les chiffres relatifs à l’activité du groupe pour l’année 2008:
Critères Chiffres
Chiffre d’affaire groupe 137 529 millions de DA
Investissements groupe 190 828 millions de DA
Electricité 32 584 millions de kWh
Ventes
Gaz 7.44 Milliards de m3
Electricité 6 298 682
Nombre de clients
Gaz 2 638 963
Production Production SPE 28 970 millions de kWh
d’électricité groupe Production IPP 11 017 millions de kWh
Personnel en activité Permanents 35 633 agents
du groupe Temporaires 24 761 agents
La figure suivante illustre l’évolution du chiffre d’affaire du groupe depuis l’année 2001 :
Figure II.2 : Evolution du chiffre d’affaire du groupe « rapport d’activité de l’année 2008 ».
49
La répartition du chiffre d’affaire du groupe pour l’année 2008 est de la manière suivante :
Figure II.3 : Répartition du chiffre d’affaire publiée dans le rapport d’activité de l’année
2008.
50
Les Sociétés de Distribution d’Electricité et du Gaz ont pour principales mission
missions d’assurer :
• L’exploitation
’exploitation et la maintenance du réseau de distribution
distribution de l’électricité et du gaz.
• Lee développement des réseaux électricité et gaz permettant le raccordement raccordement des
nouveaux clients.
• La commercialisationtion de l’électricité et du gaz.
Le tableau suivant donne une vue d’ensemble des chiffres d’affaires des sociétés de
distribution :
Chaque société de distribution compte cinq directions centrales, situées au niveau de son
siège, et gère un certain nombre de « Directions de distribution ». Chacune de ces Directions
de Distributions gère des « Services Commerciaux ». L’organigramme suivant illustre :
51
L’organisation des directions de distribution se présente comme suit :
a. en électricité :
b. En gaz :
• Client « Basse Pression-BP BP » : tout client alimenté sous une pression de 21 bars à
travers un détendeur.
• Client « Moyenne Pression
ression-MP » : tout client alimenté sous une pression de 4 bars
avec un poste de détente gaz.
gaz
• Client « Haute Pression-HP HP » : tout client alimenté sous une pression sup
supérieure à 4
bars avec un poste de détente gaz.
52
En BT/BP, on distingue plusieurs types de clients :
• Clients non ménages : il s’agit des clients non domestiques (Activités commerciales).
• Jusqu’à la fin des années 80, l’informatique était essentiellement présente au niveau
central sur gros systèmes. Cette période a vu le développement de systèmes de gestion
de l’entreprise et l’acquisition de modèles scientifiques de calcul pour la planification
des réseaux Electricité et Gaz (CARAT et APHYRE).
• En 2009, la DGSI s’est érigée au rang de filiale spécialisée dans le domaine des
systèmes d’information et technologies nouvelles sous le nom de « ELIT ».
53
L’organigramme suivant illustre la manière dont est organisée la filiale « ELIT » et la
distribution de son effectif:
54
L’organigramme et l’effectif de la direction « études et développement » se présente
comme suit :
55
II. Conclusion
Avec ses décennies d’activité dans le domaine de l’énergie et une réputation qui
dépasse les frontières du pays, le groupe SONELGAZ représente un acteur majeur et
incontournable de l’économie nationale. Cette brève présentation nous a permis de connaître
un peu plus le groupe SONELGAZ, notamment dans sa nouvelle configuration de holding
industriel.
Dans le chapitre suivant, une étude détaillée de l’existant décisionnel du groupe, dans
sa fonction de distribution, sera présentée.
56
Chapitre II : étude de l’existant
57
I. Introduction
Le groupe SONELGAZ veut, par le biais de ce projet, palier à un manque important en
matière de décisionnel. Ce manque se caractérise par la quasi inexistence de support d’aide à
la décision, et l’indisponibilité de moyens de Reporting efficaces, en mesure de fournir des
informations adéquates en temps voulu.
Partant de ce constat, nous allons essayer, à travers ce chapitre, de présenter une analyse
aussi complète que possible de l’existant décisionnel du groupe dans le cadre de sa fonction
de distribution. Ce chapitre a aussi pour but de faire connaître les procédures et les méthodes
de Reporting et de prise de décision, ainsi que les éventuelles lacunes qui peuvent exister.
Lors de notre étude de l’existant, nous avons pu recenser deux procédés pour l’élaboration
des rapports. Les deux procédés se distinguent par leurs utilisateurs finaux, la structure
chargée de leur élaboration et le niveau de consolidation.
Dans le meilleur des cas, le rapport demandé concerne des données déjà consolidées et
prêtes à l’utilisation. L’élaboration du rapport se fait donc sans grandes difficultés. Sinon, le
procédé d’extraction et de consolidation est relancé. Le diagramme suivant donne une vision
claire de la manière dont sont consolidées les données et les rapports élaborés en partant de la
demande d’un état donné jusqu'à sa production :
58
Figure II.8 : Diagramme d’activité modélisant l’édition de rapport pour le niveau groupe.
À partir de ce diagramme on peut d’ores et déjà avoir une idée sur le nombre
d’intervenants dans cette procédure qui reste une tâche très fastidieuse, surtout dans sa partie
consolidation des données. Cette procédure se déroule comme suit:
59
Remarque : les fichiers, étant d’une taille assez volumineuse, peuvent atteindre une
centaine de mégas voire plus. Ces dits fichiers subissent parfois des altérations durant le
transfert ou deviennent carrément inutilisables. Dans ce cas les « D.D. » concernées sont
recontactées pour une nouvelle extraction ou un nouvel envoi selon la nature du problème. Il
arrive parfois, suite à des problèmes réseaux, de recourir au transfert des données sur
support physique transportable (CD, clé USB).
Phase 4 : Une fois les données reçues en totalité, la consolidation se fait au niveau du
département « SID » manuellement. Cette consolidation permet d’élaborer les rapports
voulus.
Phase 5 : Le rapport est validé par le chef de département est et envoyé aux
utilisateurs finaux.
Emission de la demande : La demande est formulée par les analystes et décideurs des
deux directions Commerciale Marketing « DCM » et Comptabilité et Finance « DCF ».
Extraction des données: l’extraction se fait toujours aux niveaux des DD affiliées à la
SD. Dans la plupart du temps les données sont transférées directement sous forme de
rapports10.
10
Ces rapports obéissent à des canevas prédéfinis.
60
II.3 Niveau Directions de Distribution
Les consommateurs de rapports au niveau des DD utilisent des rapports livrés
directement par leurs CTI. Ces rapports, basés exclusivement sur les données des systèmes
transactionnels, sont élaborés et transmis à la demande des managers. Le schéma suivant
montre la manière dont sont traitées les demandes de rapport au niveau DD.
11
Ce module a été développé pour fournir un certain nombre de rapports statistiques au niveau DD. Il interagit
directement avec la base de données en production et pénalise souvent le système transactionnel.
61
III. Conclusion
Cette étude nous permet d’avoir une vision générale des procédures d’élaboration de
rapports et de consolidation des données. Elle constitue aussi le point de départ pour définir le
périmètre du projet en général et de l’étude des besoins en particulier. Elle fait ressortir les
insuffisances du système actuel en soulignant les points faibles ou les goulots d’étranglements
de ce dernier.
Le chapitre suivant consacré à l’étude des besoins, aidera à détecter ceux des
utilisateurs de manière à pouvoir y répondre.
62
Chapitre III : Définition des besoins.
63
I. Introduction
Tout Data Warehouse doit être en mesure de répondre aux attentes des utilisateurs.
Cela ne peut, évidemment, se fairee sans une étude approfondie de leurs besoins.
Ainsi, il existe deux démarches qui ont été décrites lors de notre synthèse
bibliographique, et qui sont: l'approche « Buttom Up » et l'approche « Top Down ».
Figure II.9 : La place de l’étape d’étude des besoins dans un projet Data Warehouse.
64
Ce chapitre a pour principale vocation d’exposer et de décrire la démarche adoptée
pour la détection des besoins ainsi que la présentation de la synthèse qui en sera faite.
• Étude préliminaire des systèmes sources et interviews sommaires avec les DBA,
a. Étude préliminaire des systèmes sources et interviews sommaires avec les DBA
Cette étude représente une étape de compréhension des systèmes opérationnels et de leur
environnement. Elle a pour mérite de consolider les connaissances acquises durant l’étude de
l’existant, ainsi que le jargon et le fonctionnement de l’entreprise. En outre, cette étape permet
de détecter, de manière succincte, les postes susceptibles d’interagir avec le Data Warehouse.
Elle est de ce fait indispensable pour un bon recensement des besoins.
Outre les DBA, qui sont pour la plupart des chefs de CTI, les gestionnaires qui se trouvent
au sein de l’Elit, et dont la fonction principale est de définir les règles de gestion des
applications et de s’assurer du respect des procédures propres à la distribution, ont été une
source d’information assez bénéfique, eu égard à leur connaissance des applications du SGC
et de leur maîtrise du métier du groupe.
Cette étape nous a permis, donc, d’identifier, en premier lieu, les services qui peuvent
être porteurs d’informations tangibles et qui représentent la population potentiellement
utilisatrice du projet. Ces dits services sont classés selon leur appartenance aux différentes
structures, indiqué dans le tableau suivant:
65
Structure Intitulé du poste Nombre total de postes
Direction de distribution Directeur régional de distribution 58 (1 chef par DD)
Commercial 58 (1 chef par DD)
Division finance et comptabilité 58 (1 comptable par DD)
Administrateur 58 (1 administrateur par DD)
Société de distribution P.D.G de la SD 4
D.C.M 4
Directeur finance et comptabilité 4
Groupe P.D.G 1
DGDS 3
- DAP
- DAR
- ED
Total 248
Avant de détailler cette étape, il est nécessaire de justifier notre choix de l’entretien «
interviews » comme méthode de collecte des besoins.
Bien qu’il existe d’autres méthodes d’identification des besoins, les entretiens s’imposent
comme étant la valeur sûre dans un tel projet. En effet, cette méthode a l’avantage d’être, plus
ou moins, facilement planifiable et d’ouvrir le dialogue avec les interviewés, qui sont pour la
plus part des décideurs et des analystes.
Dans le souci de conduire à bien cette étape, qui du reste est très critique et délicate, il est
nécessaire de passer par différentes phases, à savoir :
1 La phase de planification
Cette phase, qui est un préalable indispensable, s’est avérée être une tâche très ardue. En
effet, la nature organisationnelle et la dispersion des structures liées à la distribution ont posé
des problèmes que nous évoquerons plus loin. Cependant ces mêmes facteurs nous ont
66
poussés à entreprendre ce genre de démarches dans un souci de bonne conduite du projet et
afin de ne pas perdre de temps dans des allers et retours improductifs.
Aussi, nous avons essayé de planifier nos entretiens de manière à avoir une certaine
alternance entre les interviews des potentiels utilisateurs et les entretiens avec les DBA et les
gestionnaires de manière à combiner entre les besoins d’analyse et les potentialités des
systèmes sources et de leurs données.
2 La phase de préparation
Une fois la planification de l’entretien terminée, sa préparation doit se faire de telle sorte à
ce qu’il se déroule dans les meilleures conditions possibles.
Les questions à poser sont classées en deux catégories, selon le poste de la personne
interviewée. Ainsi certaines questions sont destinées aux décideurs alors que d’autres sont
destinées aux analystes.
Dernière phase de l’étape, la conduite des interviews représente la réalisation sur le terrain
des phases précédentes. Le but escompté étant d’amener les interviewés, au travers de leurs
réponse à nos questions, de présenter leur travail et la manière dont ils procèdent pour le faire.
L’identification des besoins se fera alors en détectant les métriques qu’ils utilisent et les
informations sur lesquelles ils s’appuient pour la prise de décision.
Bien que les entretiens représentent une source importante d’informations et aident
grandement à l’identification des besoins des utilisateurs, leur utilisation exclusive n’est pas
conseillée dans la construction d’un entrepôt de données. Cela tient principalement au fait que
les utilisateurs ne peuvent, même avec la meilleure volonté du monde, exprimer tous leurs
besoins.
De ce fait, il est fait appel à l’étude des rapports déjà demandés et des données
disponibles a même de fournir des informations exploitables.
L’étude des rapports offre un certain apport à notre démarche d’études des besoins, dans la
mesure où les utilisateurs peuvent ne pas mentionner des besoins qui leur paraissent évidents
ou qui ne leur viennent pas à l’esprit durant nos interviews, ces derniers peuvent être, en effet,
influencés par nos questions.
L’étude des données, quant à elle, sert à détecter des besoins non déclarés et qui
peuvent se faire sentir ultérieurement, le but de cette démarche étant de construire un entrepôt
de données capable de répondre à ces éventuels nouveaux besoins.
67
e. Rédaction et validation du recueil récapitulatif des besoins
L’étude des besoins nous a permis de recenser les besoins que nous avons classés par
volets spécifiques. Ils peuvent être présentés de la manière suivante :
68
I.2 Problèmes et obstacles rencontrés
Bien que notre étude des besoins ait donné lieu aux résultats escomptés, à savoir leur
identification et leur prise en charge, il n’empêche que le travail ne s’est pas effectué sans
obstacles, dont les plus importants sont :
69
II. Conclusion
L’étude des besoins est une étape plus que nécessaire dans un projet Data Warehouse.
C’est, en effet, à partir de cette étude que se décidera la manière de construction de l’entrepôt
de données et de son architecture.
Cette étude des besoins s’est déroulée sur vingt trois entretiens et a concerné quinze
personnes occupant différents postes à des niveaux hiérarchiques différents. L’ensemble des
entretiens a duré plus de 33 heures et nous ont permis tout d’abord d’appliquer les méthodes
d’analyse et de collecte d’information. Il nous a permis de connaître d’avantage de détails sur
les rouages de l’entreprise et d’identifier les besoins analytiques de l’entreprise.
Les besoins étant recensés, la construction du Data Warehouse peut alors commencer.
Cette construction fera l’objet du chapitre suivant.
70
Chapitre IV : Conception de la solution
71
Conception de la zone d’entreposage
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 modélisation
dimensionnelle qui est souvent associée aux entrepôts de données compte tenu de ses
avantages.
• Choix de l’activité à modéliser : ce choix se fait après classement des activités dans
une matrice dite d’analyse
’analyse des priorités [Kimball, 2004]. Cette matrice permet de
connaître quelle activité choisir en premier. Le classement des sujets recensés, qui
s’est fait en collaboration avec les décideurs et les techniciens de l’entreprise, est
illustré dans la figure suivante :
73
II.1 Volet « Vente »
a) Présentation de l’activité « Vente »
« Une vente est la cession d’un bien ou d'un service en échange d'une somme d’argent
convenue entre le vendeur, celui qui cède le bien ou le service, et l'acheteur, celui qui paie »
[Larousse, 2008].
SONELGAZ, par le biais de ses quatre filiales, propose la vente d’énergie, (électricité ou
gaz), livré par canalisation jusqu’au lieu de consommation, dans le cadre d’un contrat de
fourniture.
La vente d’énergie, électrique ou gazière, demeure comme l’activité principale des filiales
de distribution du groupe SONELGAZ, réalisant la plus grande partie du chiffre d’affaire du
groupe. Les chiffres liés aux ventes se présentent comme des indicateurs d’une grande
signification par rapport à la performance du groupe. Ainsi la disponibilité de ces
informations s’avère indispensable pour les décideurs de l’entreprise.
b) Grain de l’activité
Le choix du grain le plus fin donne un maximum de flexibilité. Dans le cas des ventes
le grain le plus fin, ou le niveau de détail le plus bas, correspond à une opération de
facturation12, d’où une ligne de table de fait correspondant à :
12
Ce n’est qu’après facturation que la quantité et le montant consommé sont arrêtés, d’où la vente.
74
c) Les dimensions
sions participantes du modèle
Les dimensions ont pour objectif de décrire le fait, donc on essaye de recenser
recens toutes les
informations
formations qui décrivent une vente et qui peuvent intéresser les décideurs.
1. Dimension Temps
La dimension temps est « la seule dimension qui figure systématiquement dans tout
entrepôt de données, car en pratique tout entrepôt de données est une série temporelle. Le
temps est le plus souvent la première dimension dans le classement sous jacent de la base de
données » [Kimball, 2001].
Figure II.11
11 : La Dimension Temps de l’activité « Vente ».
Le niveau de détail le plus bas de cette dimension est la journée. En effet, les utilisateurs
ont fait ressortir le besoin de suivre les chiffres au jour le jour et d’en
d garder l’historique 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
détails sur cette dimension :
75
Désignation Détails
Code_temps Clé artificielle de la dimension temps.
76
2. Dimension client
Le client s’impose comme un élément important dans l’analyse,
l’analyse et intéresse les
analystes et les décideurs de l’entreprise. Outre ce qu’il représente dans une opération de
vente, l’analyse
analyse du comportement du client peut aider l’entreprise à mieux le satisfaire.
Figure II.12
12 : La Dimension
imension Client de l’activité « Vente ».
La dimension client décrit un client, l’acheteur. Un client est référencié par son lieu de
consommation, c'est-à-diredire quatre clients qui ont habité le même lieu, sont considérés comme
un seul client. Pour permettre la traçabilité et le suivi d’un client on a introduit une clé
artificielle. Celle-ci aide à pallier à l’insuffisance de la codification en vigueur, notamment
pour une finalité décisionnelle le.. Les caractéristiques qui décrivent un client sont:
77
Désignation Détails
Code_client Clé artificielle
13
FSM : Facturation sur mémoire.
78
3. Dimension facture
Une facture est un document relatif au fait de vente. Cette dernière contient un certain
nombre d’informations intéressantes pour une analyse. Elle décrit les différentes
caractéristiques d’une facture, et qui caractérisent aussi une vente.
La facture est identifiée par un numéro facture. Ce même numéro est affecté,
affecté dans le cas
présent, à la facture en cas d’annulation. La
L différence
ifférence entre les deux se fait alors grâce au
champ type facture. On pourrait dans ce cas penser à l’adoption d’une clé primaire composée.
Cependant une telle clé nuirait fortement aux performances du système.. Pour cela, et dans un
souci de performance, on a introduit une clé artificielle
artificielle à cette table. Ce choix est d’autant
plus justifiable que la dimension est une dimension à évolution rapide. La facture est
caractérisée par :
79
Désignation Détails
Numero_facture Clé artificielle
80
4. Dimension zone géographique
La dimension zone géographique décrit la zone où le fait a eu lieu. Après l’étude des
besoins au sein du groupe, il parait intéressant de faire des comparaisons par rapport à des
zones géographiques. Le grain le plus bas de cette dimension correspond aux communes. Ces
dernières sont susceptibles d’évolution dans le temps (appartenance a une filiale ou une
wilaya). On jugé donc nécessaire d’introduire une clé artificielle pour permettre le suivi de
l’évolution de la dimension et d’assurer la cohérence des données.
81
Désignation Détails
Code_zone Clé artificielle.
82
5. Dimension activité
Cette dimension décrit les différents secteurs d’activitéss économiques. Celle-ci est
chargée à partir d’un tableau transmit par le ministère des finances, et très importante, dès lors
que beaucoup d’analyses observées
observée pendant l’étude des besoins, se base sur cette dimension.
Désignation Détails
Code_activité Le code de l’activité.
6. Dimension tarif
Figure II.16
16 : La Dimension Tarif de l’activité « Vente ».
Désignation Détails
Code_tarif Le code tarif qui est appliqué actuellement.
Tableau II.10
10 : Tableau descriptif de la dimension « Tarif ».
83
7. Dimension énergie
Figure II.17
17 : La Dimension énergie de l’activité « Vente ».
Désignation Détails
Code_energie Code énergie débit/type
Debit Débit
Tableau II.11
11 : Tableau descriptif de la dimension « Energie».
8. Dimension dégénérée
dégénéré « Puissance maximale »
Les clés étrangères de la table de fait référencent les dimensions qui représentent le
contexte du fait. Cependant il existe des clés ne référençant aucune dimension, ces dernières
sont dites dimensions dégénérées.
84
d) Les mesurables
Les mesurables qui correspondent à l’activité des ventes et qui permettent de mesurer les
performances de cette activité, sont la « quantité vendue » et le« montant de la vente en hors
taxe » et les « primes fixes ».
85
e) Le modèle en étoile de l’activité « Vente »
86
f) Les agrégats
Les tables d’agrégats améliorent les performances du Data Warehouse, en réduisant le
nombre de lignes que le SGBD manipule afin de répondre à une requête. Cela se fait grâce à
l’agrégation des données contenues dans les tables de faits détaillées et qui sont stockées dans
de nouvelles tables de faits.
La construction des agrégats se base sur le modèle en étoile détaillée, et elle
peut nécessiter:
On peut aussi :
Les résultats issus d’une table agrégée ou du modèle de base doivent être identique.
Pour cette phase, on s’inspire de la démarche décrite par C. Adamson dans son livre
« Mastering the Data Warehouse Aggregates, Solution for Star Schema Performance ». La
démarche consiste à :
1- Enumérer les agrégats potentiels à partir d’une étoile détaillée : pour détecter les
agrégats potentiels et choisir ceux à implémenter dans le Data Warehouse. Il est
nécessaire de bien décrire chaque agrégat.
2- Détecter les agrégats utiles : choisir des agrégats utiles à partir des agrégats
potentiels.
3- Construire le modèle agrégé : enfin on construit le modèle agrégé tout en prenant en
considération les dimensions dérivées commune entre les différents modèles.
87
1) Les agrégats potentiels
Le tableau suivant décrit, d’une manière simple et efficace, les agrégats potentiels du
modèle dimensionnel de base de l’activité des ventes:
Nombre
Dimension Agrégats potentiels d’agrégats
possibles
Temps Mois, trimestre, année, saison 4
Energie Type, débit 3
Activité Code activité 1
Tarif Tarif 1
Zone Tournée, agence, commune, DR, wilaya, filiale 6
Facture Date, cycle, type, relève 4
Numéro, commune, agence, DR, wilaya, filiale, activité,
Client 10
débit gaz, débit électricité, type
Les agrégats potentiels ne sont pas en effet tous utiles, soit par le nombre de lignes
agrégées ou par les informations fournies. Pour cela on réduit la liste des agrégats à ce qui
suit :
A partir du tableau précédent nous choisissons les agrégats qui nous semblent les plus
pertinents et susceptibles de faire l’objet d’accès fréquents. nous arrêtons la liste des modèles
agrégats suivants :
88
II.2 Volet « Recouvrement »
« Action de recouvrer, de retrouver ce qui était perdu, des sommes dues ». [Larousse,
2008]
Une suite logique au fait de vente, c’est le recouvrement des sommes dues aux clients.
Une somme peut passer par plusieurs phases ou états : facturée, impayée, payée, prés-
contentieux, contentieux et apurée. Cette terminologie obéit à un jargon au sein de
l’organisation pour définir une créance ou un avoir.
b) Grain de l’activité :
Suivi du montant et de l’état d’une facture d’un client appartenant à une zone
géographique et activant dans un certain domaine à une date donnée
Tableau II.14 : Détection des dimensions communes entre les volets « Vente » et
« Recouvrement ».
A cette étape il existe quatre dimensions communes. Ces dimensions étant très
détaillées dans la première étoile, il n’y a pas eu nécessité de recourir à une mise en
conformité. Cette remarque reste valable pour l’ensemble du document, ainsi il n’y a pas lieu
de détailler les dimensions communes à la présentation de chaque étoile.
89
1. Dimension nature
Désignation Détails
Code_nature Clé artificielle
Tableau II.15
15 : Tableau descriptif de la dimension « Nature ».
d) Les mesurables
90
e) Le modèle en étoile de l’activité « Recouvrement »
91
f) Les agrégats
1) Les agrégats potentiels
Nombre
Dimension Agrégats potentiels d’agrégats
possibles
Temps Mois, trimestre, année, saison 4
Nature Opération, nature 2
Activité Code activité 1
Zone Tournée, agence, commune, DR, wilaya, filiale 6
Facture Date, cycle, type, relève 4
Numéro, commune, agence, DR, wilaya, filiale, activité,
Client 10
débit gaz, débit électricité, type
92
II.3 Volet « Suivi des affaires »
a) Présentation de l’activité « Suivi des affaires »
Une affaire est une demande initiée soit par la clientèle ou par l’agence et qui nécessite une
mise à jour de la base de données. Cet événement se traduit par l’enregistrement d’une affaire
qui sera suivie jusqu’à son aboutissement.
Parmi les modules du « SGC », le module « Gestion des Affaires » gère les affaires liées a
la « Basse Moyenne Pression, Basse Moyenne Tension » depuis leurs enregistrements jusqu'à
leurs réalisations. Ce module génère chaque jour, et au niveau de chaque direction de
distribution, une masse de données considérable. Ces données représentent une source
d’information plus qu’indispensables pour le groupe et ses filiales de distribution. D’où la
nécessité de suivre cette activité.
b) Grain de l’activité
Le grain le plus fin de l’activité suivi des affaires représente, en réalité, la possibilité de
suivre une affaire selon des critères différents. Le grain peut alors être donné comme suit :
Suivi dans le temps, et selon leur type, les affaires qui concerne un client selon son
activité et qui sont initiées au niveau de chaque commune.
D’après le grain de l’activité on peut déjà savoir les dimensions qui seront présentes dans
notre étoile et qui sont listées dans le tableau. Ces dimensions sont indispensables pour
répondre au grain de l’activité. Aussi, et afin d’offrir un suivi plus complet et plus aisé, on a
jugé nécessaire d’introduire la «Dimension phase affaire ».
Tableau II.18 : Détection 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
d’information la concernant. Cette dimension décrit donc une affaire qui est identifiée par son
numéro « le numéro de l’affaire est unique au niveau national » et qui est caractérisée par son
degré d’urgence et son initiateur
itiateur.
Désignation Détails
Numero_affaire Un numéro d’ordre donné par le système et qui évolue à
chaque enregistrement.
Tableau II.19
19 : Tableau descriptif de la dimension « Affaire ».
94
2. Dimension type affaire
La dimension est une dimension à évolution lente. En effet, l’ajout d’une catégorie est
peu fréquent. Le détail de cette dimension est le suivant :
Désignation Détails
Code_affaire Code de l’affaire tel qu’il est connu au sein du groupe.
95
3. Dimension phase
Chaque affaire transite, durant son cycle de vie, par un certain nombre de phases. Celles-ci
Ce
ont été normalisées et codifiéees de manière à ce qu’elles puissent
ssent être utilisées conjointement
par toutes les affaires. La dimension phase reprend donc la codification utilisée par le
« SGC » pour identifier ces phases. L’utilisation d’une telle dimension facilite grandement la
compréhension du modèle dimensionnel et conférera une certaine aisance d’implémentation
et de gestion de l’alimentation de l’étoile.
Désignation Détails
Code_phase Code des phases par lesquelles transitent
nt les affaires.
Tableau II.21
21 : Tableau descriptif de la dimension « Phase».
96
e) Modèle en étoile de l’activité « suivi des affaires »
97
f) Les agrégats
1) Les agrégats potentiels
Nombre
Dimension Agrégats potentiels d’agrégats
possibles
Temps Mois, trimestre, année, saison 4
Activité Code activité 1
Zone Tournée, agence, commune, DR, wilaya, filiale 6
Numéro, commune, agence, DR, wilaya, filiale, activité,
Client 10
débit gaz, débit électricité, type
Type affaire Code catégorie, code sous catégorie 2
Tableau II.22 : Tableau descriptif des agrégats potentiels du modèle « Suivi des
affaires ».
Tableau II.23 : Tableau descriptif des agrégats utiles du modèle « Suivi des affaires ».
98
II.4 Volet « Suivi des abonnés »
a) Présentation de l’activité « Suivi des abonné »
Un abonnement électrique (ou gazier) est une contrepartie aux services qui sont rendus
par le gestionnaire du réseau public de distribution. Principalement l’acheminement de
l’électricité, et du gaz de la centrale au lieu de consommation de l’abonné.
Lors de notre étude des besoins, un des sujets auquel s’intéressent les décideurs est le
suivi des abonnés : abonnement, mise en service, résiliation…. En effet, le nombre d’abonnés
se présente comme un des indicateurs de performances de l’entreprise, d’où l’intérêt de
suivre la réalisation des objectifs tracés.
b) Grain de l’activité :
L’historique complet d’un abonné par type, zone géographique et par activité.
Le tableau suivant nous donne la liste des dimensions communes entre toutes les
étoiles :
Tableau II.24 : Détection des dimensions communes entre les volets « Vente »,
« Recouvrement », « Suivi des affaires » et « Suivi des abonnés ».
99
2. Dimension type abonné
La dimension type abonné contient une description d’un abonné par le type de
paiement (domicilié ou non domicilié)
domicilié) et par rapport au type du lieu de consommation.
Désignation Détails
Code_type_abonne Clé artificielle du 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 l’historique d’un abonné du jour de son abonnement à son éventuelle
éventuelle résiliation.
100
e) Le modèle en étoile de l’activité « Suivi des abonnés »
101
f) Les agrégats
1. Les agrégats potentiels
Nombre
Dimension Agrégats potentiels d’agrégats
possibles
Temps Mois, trimestre, année, saison 4
Type abonné Lieu, paiement 2
Activité Code activité 1
Zone Tournée, agence, commune, DR, wilaya, filiale 6
Numéro, commune, agence, DR, wilaya, filiale, activité,
Client 10
débit gaz, débit électricité, type
Tableau II.26 : Tableau descriptif des agrégats potentiels du modèle « suivi abonnés ».
Tableau II.27 : Tableau descriptif des agrégats utiles du modèle « suivi abonnés ».
102
III. Conclusion
La zone d’entreposage constitue la zone exploitable par les utilisateurs. La modélisation
de cette zone se fait grâce à la modélisation dimensionnelle. Cette manière de représenter les
données offre aux utilisateurs des modèles intuitifs et compréhensibles permettant de
naviguer et de manipuler les données, détaillées ou agrégées, sans difficulté afin de satisfaire
leurs besoins en analyse.
103
Conception de la zone « alimentation »
104
I. Introduction
L’ETL, ou l’alimentation du Data Warehouse, est une étape des plus importantes dans
un projet Data Warehouse, elle représente 80% de la charge de travail. Cette étape a pour
objectif d’assurer l’acheminement des données des systèmes sources jusqu’à l’entrepôt de
données, en passant par les différentes phases de nettoyage et de transformations nécessaires.
105
II.2 Détection des emplacements des données sources :
Afin de définir l’emplacement des informations dans les différents systèmes source et
d’en choisir les emplacements les plus fiables, nous avons travaillé de manière étroite avec les
DBA et les gestionnaires.
Cette étape s’achève par l’élaboration d’une carte logique entre données sources et
données cibles15.
L’étoile qui engendrera les chargements les plus importants, en termes de volume,
n’est autre que l’étoile des ventes. En effet, le système de facturation, établit annuellement
plus de six millions de factures, ce qui représente plus de dix millions de lignes de faits
« ventes ». Ce processus s’exécute de façon journalière (soixante-dix mille lieux de
consommation par jour). Aussi, le module de gestion des affaires (Système source) présente
une forte volatilité de ses données. Cette volatilité est due au fait que le passage, d’une affaire
donnée, d’une phase à une autre, ne laisse aucune trace sur la base de données opérationnelle.
14
Ce tableau est décrit dans le livre [Kimball 2004].
15
Voire Annexe D
106
De ce fait, l’idéal est de procéder à des chargements journaliers, pendant les heures de
non activité des systèmes sources, c'est-à-dire, durant la période qui s’étend entre dix-huit
heures et huit heures du matin.
Même si pendant les week-ends le nombre d’heures de non activité des systèmes est
plus important, la quantité de données à charger sera, elle, plus conséquente, et affectera les
performances du processus de chargement. Par ailleurs, la volatilité de certaines données
nous contraint à appliquer une telle politique de chargement
• L’impossibilité d’accès distant aux systèmes source : l’entreprise n’autorise pas des
accès distants aux systèmes sources. L’accès se fera par le biais d’une base de
données intermédiaire. Cette restriction est due à la structure organisationnelle de
l’entreprise16.
• Les problèmes du réseau actuel17 : le réseau actuel subi des perturbations au niveau
de quelques directions de distribution. Ces dernières ne sont pas encore équipées de
connexion ADSL18.
• Le nombre important des sources de données et la quantité des données : Cette
politique (push-pull) permettra le lancement de chargements parallèles.
• L’existence de serveurs au niveau sources : les cinquante-huit directions de
distribution disposent de matériel informatique important, permettant de lancer des
processus de préparation de données au niveau des « DD ».
• Maintenance facile: même si les sites sont éparpillés, la tâche d’une éventuelle
maintenance sera facilitée par le biais des équipes informatiques en place.
16
Le découpage juridique de l’entreprise ne permet pas aux filiales de partager des informations d’une façon
directe.
17
Voire annexe F.
18
Plus de quarante D.D sont équipées de connexion ADSL.
107
Pourquoi adopter cette architecture ?
Dans la zone de préparation« Staging area » les données sont extraites à partir des
sources de données, transformées et préparées pour le chargement final. Au niveau du
serveur « ELIT » il est procédé à l’affectation de clés artificielles et à quelques
transformations nécessaires avant le chargement final dans la zone d’entreposage. Après
chaque chargement, une mise à jour des Meta Data doit être faite.
108
IV. Processus de chargement
Le diagramme d’activités suivant décrit le processus général de l’alimentation de
l’entrepôt de données dés sa mise en service :
109
Deux types de tables dans l’entrepôt de données « faits, dimensions » doivent être
distingués. Chaque type de table diffère dans les d’informations qu’il contient, et d’où donc
l’adoption de deux processus de chargement.
110
Le digramme suivant illustre la politique que nous avons retenue :
111
La stratégie adoptée pour la détection des changements se fait grâce à la comparaison
entre le dernier chargement et le chargement actuel. Cette méthode, comme décrite lors de la
synthèse bibliographique, est la plus fiable pour la capture des changements.
Les mises à jour de type 3 sont traitées comme de nouvelles insertions, avec la mise à jour
de la table références.
Le processus de chargement des tables des faits doit garantir l’intégrité référentielle vis-
à-vis des tables de dimensions.
Le diagramme d’activité suivant illustre le processus de chargement adopté pour une table
de faits :
112
Figure II.31 : diagramme d’activité du processus de chargement de faits.
Le chargement de la table de fait peut être une insertion, ou une mise à jour des tables de
faits.
113
IV.3 Processus de chargement particulier
Dans un entrepôt de données il y a des tables particulières, soit : la table de la dimension
temps et les tables d’agrégats, nécessites un traitement à part.
Contrairement aux autres dimensions, la dimension temps contient uniquement des dates
qui ne sont pas forcément extraites à partir des systèmes sources. Cette dimension doit
contenir, en effet, toutes les dates qui coïncident, ou coïncideront, avec un fait donné. Elle
participe à toutes les étoiles et assure l’historisation. Dès lors, il est préférable de construire un
calendrier :
« La dimension date est plus souvent construite comme étant un calendrier avec une
granularité journalière ». [Kimball, 2004].
Après le chargement d’une étoile, les tables d’agrégats doivent être chargées par le biais
de l’ETL et à partir des données détaillées. En plus du calcul des agrégats et de leur insertion,
des mises à jour fréquentes de ces tables sont indispensables.
114
V. Conclusion
Un processus E.T.L a pour mission d’assurer la livraison de données conformes,
cohérentes et correctes tout en assurant des performances acceptables. Lors de la conception
du processus de l’ETL il a été envisagé d’atteindre les objectifs suivants:
• Utiliser des sources, autres que les sources opérationnelles pour donner une valeur
ajoutée aux informations,
• Offrir une performance optimale grâce aux chargements parallèles et séparation des
données selon l’opération de chargement (mise à jour ou nouvelle insertion),
• Mettre en œuvre des solutions secours pour faire face aux problèmes réseau,
• Mise à jour des Meta data, pour la maintenance et l’assurance de la qualité de données,
115
Conception des cubes dimensionnels
116
I. Introduction
Afin de faciliter l’analyse et la navigation dans les données, il est important que les
cubes dimensionnels soient bien conçues et définis de manière claire pour une utilisation
intuitive.
La conception des cubes dimensionnels passe par la définition des mesurables, des
dimensions et des hiérarchies présentes au sein des dimensions, ainsi que les différents
niveaux de détails de chaque hiérarchie. Le but de la mise en place de ces cubes est d’offrir
une représentation abstraite d'informations multidimensionnelles à des fins d’analyse.
Le choix des cubes à construire, des mesurables qu’ils contiendront, des dimensions
participantes dans chacun d’entre eux et des hiérarchies qui constituera chaque dimension
dépend essentiellement des besoins recensés et de l’utilisation finale.
code_activite Hierarchy_1 :
dim_activite Niveau_1 : N1
libele_activite N1 ALL
numero_affaire
observation
degre_urgence Hierarchy_1 :
dim_affaire Niveau_1 : N1
N1 ALL
initier_par
commune
wilaya
117
code_client
reference_lc Niveau_1 : N1 Hierarchy_1 :
type N1 N2 N3 ALL
dim_client
numero_client Niveau_2 : N2 Hirarchy_2 :
N1 N3 ALL
Groupe Niveau_3 : N3
numero_facture
numero_facture_s
gc
date_facture
taux_tva Niveau_1 : N1 Hierarchy_1 :
soutient_etat N1 N2 N3 N4 ALL
conso_moy_enrgi
dim_facture e_jour Hierarchy_2 :
N1 N2 N4 N3 ALL
reference_lc
type_facture Niveau_2 : N2
type_releve Niveau_3 : N3
type_cycle Niveau_4 : N4
code_energie Hierarchy_1 :
type_energie Niveau_1 : N1 N2 N1 ALL
dim_energie unite_mesure
Hierarchy_2 :
Debit Niveau_2: N2 N2 N1
code_nature
Niveau_1 : N1 Hierarchy_1 :
lib_nature
dim_nature N2 N1 ALL
operation Niveau_2 : N2
code_phase
intitule_phase
Hierarchy_1 :
desc_phase Niveau_1 : N1
dim_phase N1 ALL
durree_estimee_p
hase
code_tarif
description_tarif Niveau_1 : N1
Hierarchy_1 :
dim_tarif abreviation_tarif N1 N2 ALL
Energie Niveau_2 : N2
118
code_temps
date
jour_du_mois Niveau_1 : N1
jours
evenement
semaine_dans_ann Niveau_2 : N2
ee
mois_annee Hierarchy_1 :
Niveau_3 : N3 N1 N2 N3 N4
annee_mois
dim_temps N5 N6 ALL
mois
annee_trimestre
Niveau_4 : N4
trimestre
Saison Niveau_5 : N5
Annee Niveau_6 : N6
code_type_abonne Niveau_1 : N1
e Hierarchy_1 :
N1 N2 N3 All
type_client_domic Niveau_2 : N2
dim_type_abonn iliation Hierarchy_2 :
e N1 N3 N2 All
type_client_paiem Niveau_3 : N3
ent
code_affaire
intitule_affaire
energie_affaire Niveau_1 : N1
durree_approxima
tive
Hierarchy_1 :
dim_type_affair N1 N2 N3 All
code_ss_categorie
e Niveau_2 : N2
intitule_ss_categor
ie
code_categorie
Niveau_3 : N3
intitule_categorie
119
code_zone
code_commune Niveau_1 : N1
commune
code_agence
Niveau_2 : N2
agence
code_dr Hierarchy_1 :
dr Niveau_3 : N3 N1 N2 N3 N4
dim_zone N5 ALL
code_wilaya
Niveau_4 : N4
wilaya
code_filiale
filiale
Niveau_5 : N5
adresse_filiale
tel_filiale
Tableau II.28 : Tableau donnant les niveaux et les hiérarchies de chaque dimension.
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 présents dans ces
cubes. Il est à signaler aussi que la dimension « dim_nature » n’apparaitra nul part dans la
description des cubes. En effet, cette dimension a été remplacée par l’utilisation de
mesurables dans les cubes concernés. Le tableau suivant donne le détail de la conception de
ces cubes :
Les Hiérarchies
Nom du cube Les mesurables Les dimensions
de la dimension
Dim_client Hierarchy_1
Hierarchy_1
Dim_facture
Hierarchy_2
Hierarchy_1
Dim_energie
1. Chiffre d’affaires Hierarchy_2
Suivi des ventes
2. Nombre de factures
Dim_zone Hierarchy_1
Dim_temps Hierarchy_1
Dim_tarif Hierarchy_1
Dim_client Hierarchy_1
Dim_facture Hierarchy_1
Dim_temps Hierarchy_1
Dim_tarif Hierarchy_1
Hierarchy_1
Dim_type_abonné
Hierarchy_2
Dim_zone Hierarchy_1
Suivi de l’apport 1. Nombre de raccordements
abonné
Dim_client Hierarchy_1
Dim_temps Hierarchy_1
121
Hierarchy_1
Dim_type_abonné
Hierarchy_2
Dim_zone Hierarchy_1
Suivi des
1. Nombre de résiliations
résiliations
Dim_client Hierarchy_1
Dim_temps Hierarchy_1
Hierarchy_1
Dim_type_abonné
Hierarchy_2
Dim_zone Hierarchy_1
Suivi des mises en 1. Nombre de mises en service.
service
Dim_client Hierarchy_1
Dim_temps Hierarchy_1
Dim_client Hierarchy_1
Dim_energie Hierarchy_1
Dim_zone Hierarchy_1
1. Nombre d’affaires
Suivi des affaires Dim_temps Hierarchy_1
2. Durée
dim_type_affaire Hierarchy_1
dim_phase Hierarchy_1
dim_affaire Hierarchy_1
Dim_temps Hierarchy_1
1. Montant créances
2. Montant avoir. Dim_client Hierarchy_1
Suivi des
3. Montant factures fraîches.
recouvrements Hierarchy_1
4. Montant factures impayées. Dim_facture
5. Montant précontentieux. Hierarchy_2
Dim_zone Hierarchy_1
122
IV. Présentation des cubes dimensionnels
Dim_zone
code_zone <N1>
code_commune
commune
code_agence <N2>
agence
code_dd <N3>
dd
code_wilaya <N4>
wilaya
Dim_client
Dim_enrgie code_filiale <N5>
filiale code_client <N1>
code_energie <N1>
reference_lc
type_energie Hierarchie_1 <Default> <h>
type
unite_mesure
numero_client <N2>
debit <N2>
Hierarchie_1 <Default> <h>
Hierarchie_1 <Default> <h1>
Hierarchie_2 <h2>
Cube_suivi_vente - Dim_zone
Cube_suivi_vente
chiffre_affaire
nombre_facture
Fait_vente
Cube_suivi_vente - Dim_temps
Dim_facture
numero_facture <N1> Dim_tarif
numero_facture_sgc code_tarif <N1>
Dim_temps
date_facture description_tarif
soutient_etat code_temps <N1>
abreviation_tarif
conso_moy_enrgie_jour date
energie <N2>
type_facture <N2> jour_du_mois
jours Hierarchie_1 <Default> <h>
type_releve <N3>
type_cycle <N4> evenement
semaine_dans_annee <N2>
Hierarchie_1 <Default> <h1>
mois_annee <N3>
Hierarchie_2 <h2>
mois
annee_trimestre <N4>
trimestre
saison <N5>
annee <N6>
Hierarchie_1 <Default> <h>
123
Dim_zone
code_zone <N1>
code_commune
commune
code_agence <N2>
agence
code_dd <N3>
dd
code_wilaya <N4>
wilaya
code_filiale <N5> Dim_client
filiale
code_client <N1>
Dim_enrgie Hierarchie_1 <Default> <h> reference_lc
code_energie <N1> type
type_energie numero_client <N2>
unite_mesure Hierarchie_1 <Default> <h>
debit <N2>
Hierarchie_2 <Default> <h>
Cube_suivi_vente_conso - Dim_zone
Cube_suivi_vente_conso
chiffre_affaire
nombre_facture
nombre_conso_nul
Fait_vente
Cube_suivi_vente_conso - Dim_temps
Dim_facture Dim_tarif
numero_facture <N1> code_tarif <N1>
numero_facture_sgc description_tarif
date_facture abreviation_tarif
Dim_temps energie <N2>
soutient_etat
conso_moy_enrgie_jour code_temps <N1> Hierarchie_1 <Default> <h>
type_facture <N2> date
type_releve <N3> jour_du_mois
type_cycle <N4> jours
evenement
Hierarchie_1 <Default> <h1>
semaine_dans_annee <N2>
Hierarchie_2 <h2>
mois_annee <N3>
mois
annee_trimestre <N4>
trimestre
saison <N5>
annee <N6>
Hierarchie_1 <Default> <h>
124
Dim_zone Dim_temps
code_temps <N1>
code_zone <N1>
date
code_commune
jour_du_mois
commune
code_agence <N2> Cube_suivi_des_abonnes - Dim_zone Cube_suivi_des_abonnes - Dim_temps jours
agence evenement
semaine_dans_annee <N2>
code_dd <N3>
mois_annee <N3>
dd
mois
code_wilaya <N4>
wilaya annee_trimestre <N4>
code_filiale <N5> trimestre
saison <N5>
filiale
annee <N6>
Hierarchie_1 <Default> <h>
Hierarchie_1 <Default> <h>
Cube_suivi_des_abonnes
Nombre_raccordements
Nombre_resiliations
Nombre_mise_service
Fait_suivi_abonnes
...
Dim_client
Dim_type_abonne code_client <N1>
code_type_abonnee <N1> reference_lc
type_client_domiciliation <N2> type
Cube_suivi_des_abonnes - Dim_client numero_client <N2>
type_client_paiement <N3> Cube_suivi_des_abonnes - Dim_type_abonne
Hierarchie_1 <Default> <h> Hierarchie_1 <Default> <h>
Dim_zone Dim_temps
Cube_suivi_recouvrement
Montant_creances
Montant_avoir
Montant_factures_fraiches
Montant_facture_impayee
Montant_precontentieux
Fait_suivi_abonnes
Dim_facture
numero_facture <N1>
numero_facture_sgc Dim_client
date_facture
code_client <N1>
soutient_etat
reference_lc
conso_moy_enrgie_jour
type
type_facture <N2>
type_releve <N3> Cube_suivi_recouvrement - Dim_facture Cube_suivi_recouvrement - Dim_client numero_client <N2>
type_cycle <N4> Hierarchie_1 <Default> <h>
Hierarchie_1 <Default> <h1>
Hierarchie_2 <h2>
125
Dim_zone
code_zone <N1>
code_commune
commune
code_agence <N2>
agence
code_dd <N3>
dd
Dim_temps
code_wilaya <N4>
wilaya code_temps <N1>
code_filiale <N5> date
filiale jour_du_mois
Dim_type_affaire
jours
code_affaire <N1> Hierarchie_1 <Default> <h>
evenement
intitule_affaire semaine_dans_annee <N2>
durree_approximative mois_annee <N3>
code_ss_categorie <N2> mois
intitule_ss_categorie annee_trimestre <N4>
code_categorie <N3> trimestre
intitule_categorie saison <N5>
Hierarchie_1 <Default> <h> annee <N6>
Hierarchie_1 <Default> <h>
Cube_suivi_affaire - Dim_zone
Cube_suivi_affaire - Dim_type_affaire
Cube_suivi_affaire - Dim_temps
Dim_client
Cube_suivi_affaire
code_client <N1>
nombre_affaire Cube_suivi_affaire - Dim_client
reference_lc
durre_moyen type
Fait_suivi_affaire numero_client <N2>
Hierarchie_1 <Default> <h>
Cube_suivi_affaire - Dim_energie
Dim_phase
Dim_affaire
code_phase <N1>
numero_affaire <N1>
intitule_phase
degre_urgence
Dim_energie durree_estimee_phase
initier_par
code_energie <N1> desc_phase
observation
type_energie Hierarchie_1 <Default> <h>
Hierarchie_1 <Default> <h>
unite_mesure
debit <N2>
Hierarchie_1 <Default> <h1>
Hierarchie_2 <h2>
126
V. Conclusion
Les cubes dimensionnels est une étape très importante dans tout projet Data Warehouse.
C’est grâce à cette dernière que l’utilisateur pourra utiliser et exploiter au mieux les données
contenues dans l’entrepôt de données de manière correcte et intuitive.
Dans ce chapitre nous avons essayé donc de définir les cubes dimensionnels en
explicitant les dimensions participantes dans chacun d’entre eux. Ensuite nous avons défini,
pour chacune des dimensions, les différentes hiérarchies présentes ainsi que les niveaux qui
composent ces dernières.
127
Meta Data
128
I. Les « Méta Data » ou « métas données » de l’entrepôt
Un entrepôt de données, étant en production constante, doit être suivi de prés.
L'administration d'un Data Warehouse revient à mettre en place des processus et des
mécanismes de gestion. Ces mécanismes sont là pour assurer un meilleur fonctionnement de
l’entrepôt. Aussi ils doivent garantir l’alimentation en données quelques soient les
circonstances.
Afin d’assurer la mise à jour de l’entrepôt de données, il est nécessaire de suivre son
alimentation au jour le jour, surtout dans le cas présent où les sources de données sont
géographiquement dispersées. Un tel suivi peut être garantie grâce au recours au méta data de
l’entrepôt.
129
Figure II.37 : Diagramme de classe des métas données.
130
III. Exploitation des métas données
III.1 Présentation de la partie navigation
La fonction première des métadonnées est d’offrir un catalogue complet et détaillé sur
le contenu de l’entrepôt. Ce catalogue est bien sûr appelé à évoluer. De ce fait l’utilisateur
doit être en mesure de consulter ce catalogue et d’y proposer des mises à jour, si cela est
nécessaire. Le diagramme des cas d’utilisation suivant illustre ces différents volets :
131
III.2.1 Supervision : l’administrateur aura la possibilité de suivre l’état des chargements
journaliers de l’entrepôt de données. Ainsi, il aura une situation précise des
chargements par direction de distribution, lui offrant de ce fait la possibilité de
détecter les chargements échoués et la date de l’échec de manière à recouvrir les
données non chargées.
Le diagramme des cas d’utilisation suivant illustre les cas cités précédemment :
132
IV. Conclusion
La couche méta données est très importante dans un projet Data Warehouse, dans la
mesure où elle en permet la maintenance de ce dernier, garantit son intégrité et facilite son
expansion.
Ainsi il est plus que nécessaire de concevoir les métas données et de développer une
couche applicative permettant de les maintenir. Dans ce chapitre nous avons essayé de
concevoir un sous système d’administration de l’entrepôt de données qui répond aux
exigences d’un tel projet.
133
Partie III : Réalisation et déploiement
134
I. Introduction
Pour la réalisation et la mise en place de la solution, il a été nécessaire de recourir à un
certain nombre d’outils et mettre en place des environnements d’exécution.
II. Implémentation
II.1 Périmètre technique et fonctionnel
Cette partie décrit les infrastructures déjà en place. En effet, cette dernière est une
étape à ne pas négliger, car la diversité des sources et leurs plateformes techniques pourront
engendrer des problèmes de compatibilité.
II.1.1 Matériel
• Machine IBM,
• Machine INTEL : HP ou DELL,
135
II.2 Architecture technique de la solution
La figure suivante illustre la structure et l’architecture technique de la solution proposée :
Figure III.1
III : Architecture technique de la solution.
19
Voir annexe F.
136
2) Base de données Meta Data :
La base de données, Meta data, a été implémentée sous le SGBD MySQL, qui est
un SGBD open source simple d’utilisation et performant pour les petites bases de
données.
Après une étude comparative, le choix a été porté sur « Talend Open Studio » dans sa
version « 3.1.4r2 », connu comme l’outil le plus performant de sa catégorie open source
[Daan, 2007]. Ce dernier basé sur l’IDE « Eclipse » intègre un ensemble de composants
implémentés en JAVA et permet de rajouter son propre code JAVA.
137
• Un serveur de reporting « JasperReports », pour l’édition des rapports préétablis.
Ces derniers sont conçus séparément et intégrés dans la plateforme « SpagoBI ».
• Un serveur SMTP, pour la diffusion des rapports.
• Implémentation des tableaux de bord conçus avec l’outil « Open Slazio » pour une
représentation graphiques efficace et compréhensible.
Même si ces outils se présentent comme des solutions clé en main, ils nécessitent un
travail d’intégration et de conception afin de donner une valeur ajoutée aux états
implémentés.
Ces deux modules ont été développés en JavaServer Pages (JSP), qui est l’extension
web du langage Java. Le développement s’est fait avec la version 6.5 de l’IDE NetBeans. Le
choix de ce langage est en rapport avec les points suivants :
138
III. Déploiement
Pour mieux décrire le déploiement de la solution, on utilise le modèle de déploiement
U.M.L qui permet de présenter l’architecture de déploiement d’une manière simple et
compréhensible.
Comme on peut le voir, notre solution comporte trois zones : zone d’alimentation,
zone de stockage et zone de restitution. Afin d’illustrer cela, on propose deux diagrammes de
déploiements : Un diagramme pour la zone d’alimentation et un autre diagramme pour la
zone de restitution. La zone de stockage étant liée directement aux deux autres zones sera
décrite dans les deux modèles.
139
III.2 Déploiement de la zone de restitution
140
IV. Conclusion
La partie de restitution est la partie sur laquelle l’utilisateur final aura à interagir. Cette
dernière a été mise en place en intégrant des solutions « Open Source », et en développant
certains volets de manière à assurer une bonne utilisation du système.
Le déploiement se fait pour le moment sur trois sites pilotes, et sera étendu à
l’ensemble du territoire des que les résultats des tests fonctionnels auront été approuvés.
141
Conclusion générale et perspectives
142
Conclusion générale et Perspectives
Exploiter les données à disposition de l’entreprise afin de leur donner de la valeur
ajoutée, tel est le défi des entreprises modernes.
Dans ce cadre, et afin de palier à des problèmes récurrents dans le processus de prise
de décision, SONELGAZ a initié le projet de réalisation d’un Data Warehouse pour permettre
la mise en place d’un système décisionnel fiable et efficace.
Bien que la méthode des entretiens soit l’outil principal pour la collecte des besoins
dans ce travail (en effet, le milieu et l’organisation du groupe ont rendu toute autre approche
pratiquement impossible), l’étude des besoins déjà exprimés sous forme de rapports et de
processus de prise de décision nous ont été d’une grande utilité pour définir de manière claire
le périmètre et les besoins réels des utilisateurs. Cette étude a fait ressortir quatre sujets
d’analyse dignes d’intérêt pour l’entreprise qui sont : Les ventes, les affaires, les nouveaux
abonnés, le recouvrement.
L’utilisation d’outils et de solutions open source est un volet très important dans ce
projet. En effet, l’orientation Open Source du projet a été décidée dés l’initiation de ce
dernier. Cette orientation, qui se fait ressentir durant les étapes sus citées, est plus présente
dans la partie « réalisation de la zone de restitution » grâce à l’intégration d’une plateforme
« BI », pour la diffusion et la gestion des documents, et d’outils de Reporting et de navigation
dans les données complètement open source, offrant à l’utilisateur la possibilité d’exploiter les
données de l’entrepôt via n’importe quel client léger. La partie restitution a aussi nécessité le
143
développement des volets de gestion des utilisateurs, d’administration de l’entrepôt et de
supervision de ce dernier.
Pour finir, et avant de citer les perspectives du projet, nous pouvons dire que ce stage
au niveau de SONELGAZ nous a permis d’acquérir une très bonne expérience professionnelle
et d’évoluer dans un domaine qui nous était totalement inconnu à savoir le domaine des
systèmes décisionnels, et au sein d’un environnement regroupant des équipes de
professionnels du métier représentant la filiale « ELIT ».
Comme un projet Data Warehouse n’est jamais complètement terminé, nous pouvons
citer les perspectives et les développements suivants :
144
Bibliographie
Ouvrages
[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
145
Articles et Thèses
[Bouzghoub, 2008] : Abdenour Bouzghoub ; « Modélisation des Entrepôts de données
XML : Application au domaine de la sécurité sociale » ; Thèse de
Magistère Option : SISCSD ; Institut National de Formation en
Informatique (I.N.I) 2008.
[Chuck, 1998] : Chuck Ballard, Dirk Herreman, Don Schau, Rhonda Bell, Eunsaeng
Kim, Ann Valencic; Data Modeling Techniques for Data
Warehousing; International Technical Support Organization;
http://www.redbooks.ibm.com; février 1998.
[Daan, 2007] : Daan Van Beck, Norman Manley, The ETL product survey 2007, A
passionned International research paper, 2007.
[Favre, 2008] : Cécile Favre; «Évolution de schémas dans les entrepôts de données»;
Thèse de doctorat ; Université Lumière Lyon 2 «École
Doctorale Informatique et Information pour la Société» ; Décembre
2007.
[Hugh, 2009] : Hugh Watson, Dorothea L. Abraham, Daniel Chen, David Preston;
Dominic Thomas,Data Warehousing ROI: Justifying and Assessing a
Data Warehouse; http://www.bi-bestpractices.com/view-
articles/4780; 2009.
[Inmon, 1998]: B. Inmon ;Data Mart Does Not Equal Data Warehouse;
http://www.information- management.com/infodirect/19991120/1675-
1.html ;1998.
146
projet/phasedefinition/gestion-de-projet/planification-suivi-
projet/guide-planif-suivi-projet.pdf ;2001.
147