View
142
Download
4
Category
Preview:
Citation preview
Page 1
Présenté par :
KIENDREBEOGO Pousga Martin
Etudiant en DESS/2ITIC
Tel : (00226) 70 72 87 34
Mail : martin.kiendrebeogo@gmail.com
Stage effectué à la Direction Générale des Services Informatiques du
Ministère de l’Economie et des Finances du 05/03/2014 au 21/07/2014
Maitre de stage : Directeur de mémoire :
M. Alain OUATTARA M. Yaya TRAORE
Directeur des Etudes et Applications
Enseignant Chercheur à l’IBAM
THÈME : « Mise en Place d’un entrepôt de données sur les financements extérieurs au
Burkina Faso »
Page 2
Table des matières
DEDICACES .............................................................................................................................. 5
REMERCIEMENTS ................................................................................................................... 6
SIGLES, ABREVIATIONS ET ACRONYMES ....................................................................... 7
LISTE DES FIGURES ............................................................................................................... 8
LISTE DES TABLEAUX .......................................................................................................... 9
PREAMBULE .......................................................................................................................... 10
RESUME .................................................................................................................................. 11
INTRODUCTION GENERALE .............................................................................................. 12
Contexte général ....................................................................................................................... 13
Problématique ........................................................................................................................... 14
Planification .............................................................................................................................. 15
PRESENTATION DE LA STRUCTURE D’ACCUEIL ......................................................... 17
PARTIE I: GENERALITES ..................................................................................................... 21
I Introduction ............................................................................................................................ 22
I. 1 Les systèmes décisionnels ..................................................................................... 22
I.1.1 La place du décisionnel dans l’entreprise ......................................................... 23
I.1.2 Les différentes composantes du décisionnel ....................................................... 23
I.2 Le data warehouse ............................................................................................................... 24
I.3 Historique des Data Warehouse .......................................................................................... 25
I.4 Structure des données d’un Data Warehouse ...................................................................... 25
I.5 Les composantes d’un Data Warehouse .............................................................................. 26
I.6 L’architecture d’un Data Warehouse .................................................................................. 27
II. Modélisation des données de l’entrepôt ............................................................................... 27
II.1 La modélisation dimensionnelle et ses concepts ................................................................ 27
II.2 Le concept modèle ............................................................................................................. 29
II.3 Le concept OLAP ............................................................................................................... 31
II.3.1 Généralités ................................................................................................................. 31
II.3.2 Les systèmes à architecture MOLAP ......................................................................... 31
II.3.3 Les systèmes à architecture ROLAP .......................................................................... 32
II.3.4 Les systèmes à architecture HOLAP .......................................................................... 32
II.4 La navigation dans les données .......................................................................................... 32
Page 3
II.4.1 Opérateurs de restriction (Slice et Dice) ................................................................... 33
III. Démarche de construction d’un entrepôt de données ......................................................... 35
III.1 Modélisation et conception du data warehouse ................................................................ 35
III.1.1 Approche « besoins d’analyse » ................................................................................. 35
III.1.2 Approche « Source de données » ............................................................................... 36
III.1.3 Approche mixte ......................................................................................................... 37
III.1.4 Choix de l’approche de mise en œuvre ...................................................................... 38
III.2 Alimentation du Data Warehouse ..................................................................................... 38
III.2.1 Les phases de l’alimentation (ETL) ........................................................................... 38
III.2.2 Politique de l’alimentation ......................................................................................... 39
III.2.3 Exploitation du data warehouse ................................................................................ 40
Conclusion ................................................................................................................................ 43
PARTIE II: MODELISATION ................................................................................................ 44
CHAPITRE I: ETUDE DE L’EXISTANT ............................................................................... 45
I Introduction ............................................................................................................................ 46
I.1 Etat de l’opérationnel .......................................................................................................... 46
I.2 Etat du décisionnel .............................................................................................................. 47
I.2.1 Niveau DGCOOP ................................................................................................. 47
I.2.2 Niveau DGB.......................................................................................................... 49
I.2.1 Niveau DGTCP ..................................................................................................... 49
I.3 Etude des besoins ................................................................................................................ 49
I.3.1 Description de la démarche d’étude des besoins ................................................. 50
Conclusion ................................................................................................................................ 52
CHAPITRE II: CONCEPTION DE LA SOLUTION .............................................................. 53
Introduction ............................................................................................................................... 54
I Processus de la modélisation dimensionnelle ........................................................................ 55
I.1 Inscription Projet ................................................................................................................. 55
I.1.1 Présentation du sujet ............................................................................................ 55
I.1.2 Grain du sujet ....................................................................................................... 55
I.1.3 Les dimensions participantes du modèle ............................................................. 56
I.1.4 Les mesurables ..................................................................................................... 58
I.1.5 Le modèle en étoile de l’activité «inscription projet» .......................................... 58
I.2 Elaboration .......................................................................................................................... 58
Page 4
I.2.1 Présentation du sujet ............................................................................................ 58
I.2.2 Grain du sujet ....................................................................................................... 58
I.2.3 Les dimensions participantes du modèle ............................................................. 58
I.2.4 Le modèle en étoile de l’activité « élaboration » ................................................. 59
I.3 Mobilisation ......................................................................................................................... 59
I.3.1 Présentation du sujet ............................................................................................ 59
I.3.2 Grain du sujet ....................................................................................................... 59
I.3.3 Les dimensions participantes du modèle ............................................................. 59
I.3.4 Le modèle en flocon de l’activité «mobilisation » ................................................ 60
I.4 Exécution ............................................................................................................................. 60
I.4.1 Présentation du sujet ............................................................................................ 60
I.4.2 Grain du sujet ....................................................................................................... 61
I.4.3 Les dimensions participantes du modèle ............................................................. 61
Conclusion ................................................................................................................................ 62
PARTIE III: MISE EN OEUVRE DE LA SOLUTION ............................................................. 63
I Introduction ............................................................................................................................ 64
I.1 Etude et Planification .......................................................................................................... 65
I.2 Architecture de chargement ................................................................................................. 65
I.3 Processus général de chargement ........................................................................................ 66
I.4.1 Processus de chargement initial .......................................................................... 67
I.3 Architecture technique de la solution .................................................................................. 67
I.4 Choix de l’ETL .................................................................................................................... 68
I.4.1 Implémentation de l’extraction, de la transformation et du chargement .......... 68
a. Mise en œuvre de l’extraction, de la transformation et du chargement initial . 69
I.4.2 Conception des cubes ........................................................................................... 70
I.4.3 Architecture technique de déploiement ............................................................... 71
I.4.4 Coût de mise en œuvre ......................................................................................... 72
Conclusion ................................................................................................................................ 73
CONCLUSION GENERALE .................................................................................................. 74
Bibliographie ............................................................................................................................ 75
Webographie ............................................................................................................................. 75
Page 5
DEDICACES
A :
Mes feux parents, qui de leur vivant, n’avaient
jamais cessé de m’encourager et me soutenir,
Ma femme Sylvie et ma fille Tinb-Noma
Marthe Anonn,
Mon feu frère Philippe et ma feue sœur Martine :
puisse Dieu les accueillir dans son vaste paradis.
Page 6
REMERCIEMENTS
Au début de ce rapport, nous tenons à remercier, Madame la
Directrice de l’IBAM, toute l’équipe pédagogique et les
intervenants professionnels pour avoir assuré notre formation.
Nous remercions également le Directeur Général des Services
informatiques du Ministère de l’Economie et des Finances pour
nous avoir accepté au sein de son service pour le stage pratique.
Nos vifs remerciements vont particulièrement aux personnes
suivantes :
M. Yaya TRAORE, Enseignant chercheur à l’IBAM, notre
Directeur de mémoire ;
M. Alain OUATTARA, Directeur des Etudes et Applications à la
Direction générale des Services Informatiques, notre maître
de stage.
Enfin, dans le souci de n’oublier personne, nous témoignons de
notre gratitude à tous ceux qui, d’une manière ou d’une autre, ont
apporté leur brique à notre formation ou à la réussite de ce
travail.
Page 7
SIGLES, ABREVIATIONS ET ACRONYMES
BI Business Intelligence
2IOPSIE Ingénierie informatique et organisation et protection des systèmes d’information dans
l’entreprise
2ITIC Ingénierie Informatique et Technologie de l’Information et de la Communication
DBA Data Base Administrator
DDP Direction de la Dette Publique
DESS Diplôme d’Etude Spécialisé Supérieur
DGB Direction Générale du Budget
DGCOOP Direction Générale de Coopération
DGTCP Direction générale du Trésor et de la Comptabilité Publique
DGSI Direction Générale des Services Informatiques
DIM Dimension
DW Data warehouse
ETL Extract, Transform and Load
FK Foreign Key
FTP File Transfer protocol
IBAM Institut Burkinabè des Arts et Métiers
IHM Interface Homme-Machine
KLSL Kilo Ligne Source du Logiciel
MEF Ministère de l’économie et des finances
MOLAP Multidimensional On Line Analytical process
OLAP Hybrid On Line Analytical process
OLTP On Line Transactional process
PDF Portable Document Format
PK Primary key
PTF Partenaires Techniques et Financiers
ROLAP Relational On LIne
SGBD (R) Système de Gestion de Base de Données (Relationnelles)
SQL Structured Query Language
WWW World Wide Web
XP eXtreme Programming
Page 8
LISTE DES FIGURES
Figure 1 : Le diagramme de GRANT ........................................................................................ 15 Figure 2 : Le diagramme d’allocation de ressources ................................................................. 16 Figure 3 : Légende du diagramme d’allocation de ressources .................................................. 16 Figure 4 : Le décisionnel au sein du Système d’information [Goglin, 1998] ............................. 23 Figure 5 : Les différentes composantes du décisionnel [Goglin, 1998] ...................................... 23 Figure 7 : Structure des données d’un data warehouse ............................................................... 25 Figure 8 : Architecture global d’un data warehouse ................................................................... 27 Figure 9 : Cube à plusieurs dimensions ...................................................................................... 28 Figure 10 : Un modèle dimensionnel typique [Kimball, 1996] .................................................. 28 Figure 11 : Modèle en étoile ....................................................................................................... 30 Figure 12 : Modèle en flocon ...................................................................................................... 30 Figure 13 : Modèle en constellation ............................................................................................ 30 Figure 14 : Principe de l’architecture MOLAP [Nakache, 1998] ............................................... 31 Figure 15 : Principe de l’architecture ROLAP [Nakache, 1998] ................................................ 32 Figure 16 : Exemple de cube dimensionnel ................................................................................ 33 Figure 17 : Exemple de slicing .................................................................................................... 33 Figure 18 : Exemple de dicing .................................................................................................... 34 Figure 19 : Exemple de drill up & drill down ............................................................................. 34 Figure 20 : Exemple de rotate ..................................................................................................... 35 Figure 21 : Illustration de l’approche « besoins d’analyse » [Kimball, 2004] ............................ 36 Figure 22 : Illustration de l’approche « source de données » [Inmon, 2002] ............................. 36 Figure 23 : Illustration de l’approche « mixte » .......................................................................... 37 Figure 24 : Objectif de qualité de données dans un processus ETL [Kimball, 2004] ................. 40 Figure 25 : Diagramme d’activité modélisant l’édition d’un rapport sur les projets et convention ..................................................................................................................................................... 48 Figure 27 : Analyse des priorités ................................................................................................. 55 Figure 28 : La dimension Temps de l’activité « inscription projet» ........................................... 56 Figure 28 : La dimension BAILLEUR de l’activité « inscription projet» .................................. 56 Figure 30 : La dimension SECTEUR_ACTIVITE de l’activité « inscription projet» ................ 57 Figure 31 : La dimension ZONE_GEOGRAPHIQUE de l’activité « inscription projet» .......... 57 Figure 32 : Modèle en étoile de l’activité « inscription projet» ................................................. 58 Figure 33 : Modèle en étoile de l’activité « élaboration» .......................................................... 59 Figure 34 : Modèle en étoile de l’activité « mobilisation» ........................................................ 60 Figure 35 : Modèle en constellation de l’activité « exécution» ................................................. 61 Figure 36 : diagramme de l’activité du processus d’alimentation .............................................. 66 Figure 35 : Architecture technique de la solution ....................................................................... 67 Figure 36 : Gestionnaire de connexions à oracle depuis SQL Server ......................................... 68 Figure 37 : Enchainement des taches du chargement initial ....................................................... 69 Figure 38 : Exemple de conversion de type de données. ............................................................ 69 Figure 39 : Figure illustratif du chargement de la dimension convention. ................................. 70 Figure 40 : Cube du fait mobilisation. ......................................................................................... 70 Figure 41 : Exemple d’analyse du cube de fait mobilisation. ..................................................... 71 Figure 42 : Architecture de deploiement. .................................................................................... 71
Page 9
LISTE DES TABLEAUX
Tableau 1 : Tableau comparatif entre le transactionnel et le décisionnel ................................... 24 Tableau 2 : Tableau comparatif entre tables de faits et tables de dimensions ............................ 29 Tableau 3 : Avantages et inconvénients de l’approche « besoins d’analyse » ............................ 36 Tableau 4 : Avantages et inconvénients de l’approche « source de données » ........................... 37 Tableau 5 : Tableau représentant les différents postes de travail ................................................ 50 Tableau 6 : Synthétisation des besoins recensés. ........................................................................ 51 Tableau 7 : Tableau descriptif de la dimension TEMPS ............................................................. 56 Tableau 7 : Tableau descriptif de la dimension BAILLEUR ...................................................... 57 Tableau 9 : Tableau descriptif de la dimension Secteur_activité ................................................ 57 Tableau 10 : Tableau descriptif de la dimension zone géographique ......................................... 57
Page 10
PREAMBULE
L’institut burkinabé des arts et métiers (IBAM) est un établissement de l’Université de Ouagadougou
(UO). Il a été créé en 2000 suite à la refondation de l’université de Ouagadougou et a pour objectif la
formation professionnelle.
De 2006 à 2010, l’IBAM disposait des filières de formation suivantes :
- DUT option Secrétariat de Direction/ Secrétariat de Direction Bilingue ;
- DUT option Finance Comptabilité ;
- DUT option Gestion Commerciale ;
- DUT option Banque ;
- Licence Professionnelle Finances et Audits Comptable(LPFAC) ;
- Licence Professionnelle en Marketing et Gestion;
- Licence Professionnelle en Banque ;
- Licence Professionnelle Secrétariat ;
- Méthodes Informatiques Appliquées à la Gestion (MIAGE) ;
- DESS en Ingénierie Informatique et Technologies de l’Information et de la communication (2ITIC).
- DESS en Ingénierie Informatique et Organisation et Protection des Systèmes d’Information dans
l’Entreprise (2IOPSIE).
La filière MIAGE a pour objectifs de répondre aux besoins croissants des entreprises en cadres de bon
niveau dans le domaine de la technologie et des techniques informatiques. La formation en MIAGE était
ouverte aux titulaires d’un BTS/DUT en Informatique, d’un DEUG en Mathématique et Physique, en
Physique Chimie ou d’un diplôme reconnu équivalent. La durée de la formation est de deux ans. Aussi,
suite à des relations de partenariat existant entre l’IBAM, l’université de Bobo-Dioulasso et l’IAI Niger,
l’opportunité est offerte aux étudiants de ces universités ayant un diplôme d’ingénieur de travaux
informatiques d’intégrer la deuxième année MIAGE après examen de dossier.
A compter de l’année universitaire 2011-2012, la formation à l’IBAM intègre le système LMD
(Licence, Master, Doctorat) et les filières ont été réorganisées de la manière suivante :
- Marketing, Gestion;
- Comptabilité, Contrôle, Audit ;
- Assurance, Banque, Finance;
- Assistant de direction bilingue;
- Méthode Informatiques Appliquées à la Gestion ;
Il y a aussi la formation en DESS (2ITIC, 2IOPSIE) et en MIAGE 2 soir.
Pour l’obtention du DESS, un stage suivi de la rédaction d’un mémoire est obligatoire. C’est pour
répondre à cette obligation que nous avons fait un stage à la Direction Générale des Services
Informatiques qui nous a permis de nous pencher sur la mise en œuvre d’un entrepôt de données des
financements extérieurs au Burkina Faso.
Page 11
RESUME
Dans le but de disposer d’outils performants et fiables à même d’améliorer la gestion budgétaire, le
Burkina Faso s’est lancé dans un vaste chantier d’informatisation. Dans ce processus figure pour une
grande part, la gestion des financements extérieurs, préoccupation qui est traduite dans le Plan d’Action
pour le Renforcement de la Gestion Budgétaire (PRGB), adopté le 31 Juillet 2002.
Malgré l’exploitation du logiciel dédié à la gestion de la dette, les structures chargées de la gestion des
financements extérieurs éprouvent de réelles difficultés de mise en place d’une base de données
exhaustive des éléments de la dette. Ainsi pour plus d’efficacité dans la gestion des financements
extérieurs afin de rendre compte avec célérité de leur utilisation, il s’est avéré nécessaire de mettre en
place un dispositif prenant en compte des aspects organisationnel et informatique. Ainsi est né le Circuit
Intégré des Financement Extérieurs (CIFE) dont les objectifs sont entre autres :
- la prise en compte les besoins des différents départements ministériels en terme d’inscription
annuelle de projets de développement ;
- la saisie des conventions de financements entre le Burkina Faso et ses différents partenaires
techniques ;
- la budgétisation annuelle des prévisions de financements par bailleurs au titre des
investissements ainsi que la mobilisation des ressources budgétisées;
- l’exécution du titre 5 ainsi que la prise en compte dans la comptabilité de l’Etat;
Malgré la mise en œuvre de cet arsenal de mesures devant conduire à une meilleure gestion des finances
publiques, force est de constater la persistance de réelles difficultés dans des secteurs tels celui des
financements extérieurs quant à la maîtrise des données et de leur suivi pour une meilleur prise de
décisions par les autorités.
Ce travail fournit un effort d’analyse et de développement d’un entrepôt de données qui devra donc
résoudre la problématique posée qui est de mettre à disposition des décideurs un outil décisionnel
performent. Il a pour objectifs d’être un outil qui va:
offrir des informations agrégées et détaillées en matière de prévision budgétaire sur
financements ;
permettre d’analyser les flux de décaissements effectuées par les partenaires techniques et
financiers ;
permettre une bonne lecture de l’exécution et surtout fournir en temps réel l’utilisation faite
des financements extérieurs ;
offrir une large possibilité de génération d’un certains nombre d’états d’aide à la décision.
Page 12
INTRODUCTION GENERALE
Page 13
Contexte général
La prise en compte des systèmes informatisés dans la gestion des finances publiques au Burkina Faso
est un élément indispensable pour un meilleur suivi et une meilleure prise de décision en vue
d’améliorer la croissance économique nationale. Dans le souci de satisfaire ce besoin, le gouvernement
dans sa politique nationale en matière des TIC s’est doté des logiciels pour accroitre la disponibilité du
service publique en matière des finances publiques mais aussi réduire les délais de traitement des
dossiers. Ces solutions pour la plupart apportent satisfaction à nos décideurs en matière d’information
financières. En effet le climat sur fond de crise dans lequel évolue le monde aujourd’hui et
particulièrement les Etats en voie de développement, fortement dépendant de l’aide extérieur, exige de
ces derniers une surveillance très étroite de la mobilisation et de l’exécution des finances publiques afin
d’accroitre la croissance, de maintenir une confiance vis-à-vis des partenaires techniques financiers, et
aussi de garantir la stabilité gaze de développement. Pour ce faire, nos autorités, quelque en soit
d’ailleurs le domaine d’activité, doivent être en mesure de mener à bien les missions qui leur incombent
en la matière. Ils devront prendre notamment les décisions les plus opportunes.
Cependant, ces logiciels existant s’ils permettent d’atteindre un niveau très acceptable en matière de
gestion des finances publiques, n’offrent pas à nos jours une possibilité de simulation et de prédiction à
nos décideurs sur une période définie.
Ces décisions, qui influeront grandement sur la stratégie nationale et donc sur le devenir de la nation, ne
doivent pas être prises ni à la légère, ni de manière trop hâtive, compte tenu de leurs conséquences sur le
développement et la stabilité nationale. Il s’agit de prendre des décisions fondées, basées sur des
informations claires, fiables et pertinentes.
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.
Dans le présent rapport qui s’articule autour de trois parties, il sera question dans un premier temps de
faire une synthèse bibliographique afin de définir les concepts d’entrepôt de données, ensuite, de
dépeindre succinctement la structure d’accueil et de la conception de la solution, enfin viendra
l’implémentation, la présentation pratique et le déploiement de la solution conçue.
Page 14
Problématique
Les financements extérieurs représentant en termes d’exécution, 76% du Programme d’investissement
Public contre 24 % pour les ressources internes au cours de l’année budgétaire 2002, il devient
indispensable d’améliorer leur suivi, en particulier celui des dépenses sur financements extérieurs, dans
le cadre de la transparence de la gestion et du suivi des dépenses dans la lutte contre la pauvreté. Dès
lors, il s’avère urgent de mettre en œuvre un dispositif (en termes d’organisation à mettre en place, de
renforcement des capacités et d’outil informatique à utiliser) fiable pour mieux gérer les financements
extérieurs.
Dans un pareil contexte, la plus simple des opérations d’analyse devient une tâche ardue. En effet, les
différentes directions en charge du CIFE se trouvent dans l’incapacité de faire des analyses fiables,
efficaces et à des moments opportuns dans des délais courts. Ainsi, les principales difficultés
rencontrées peuvent être résumées en :
Difficultés dans l’élaboration des rapports de suivi des financements extérieurs:
L’élaboration des rapports de suivi de la mobilisation et de l’exécution des financements extérieurs fait
intervenir, généralement, plusieurs acteurs en raison de la multiplicité des intervenants dans le circuit
(DGCOOP, DGTCP, DGB, DGEP…). En effet, à chaque fois qu’il est nécessaire d’élaborer un rapport,
il faudra procéder d’abord à l’extraction les données à partir de la base de productions à commencer par
la DGCOOP pour ce qui concerne les projets et les conventions, la DGB pour la mise à disposition du
budget et enfin la DGTCP pour les questions touchant les décaissements, l’exécution et la
comptabilisation du titre 5. Il s’agit là d’une procédure lourde outre les éventuelles incohérences et
erreurs. Les retards enregistrés, parfois, font que le rapport est élaboré sur la base d’une consolidation
antérieure, en sachant pertinemment que les données ne sont pas à jour.
L’inexistence d’une procédure de Reporting :
L’inexistence d’une politique de Reporting n’est pas pour arranger les décideurs. Ceux ci ont besoin
d’informations fiables et dans des délais raisonnables. À titre indicatif, l’édition d’un rapport national
qui devra être présenté devant l’assemblée nationale peut prendre, en moyenne, plus d’un mois ce qui
est plus que pénalisant pour une bonne prise de décision.
Insuffisance du module « suivi et évaluation » :
Afin de produire et offrir un moyen de suivi des activités sur la gestion faite des financements
extérieurs, un module « suivi et évaluation » a été développé et intégré dans le système Ce dernier
fournit des états statistiques permettant, aux décideurs au niveau des directions générales, l’analyse et la
prise de décision. Cependant, ce module connait quelques problèmes dû au fait qu’il interroge
directement la base de données en production.
Page 15
Objectifs
Afin de palier aux problèmes précédemment cités, la DGSI à travers la DEA, a initié le présent projet.
Ce projet a pour but d’introduire, en premier lieu, une informatique décisionnelle au sein du Ministère
de l’Economie et des Finances en général et en particulier sur les financements extérieurs, tout en
conférant aux décideurs un support fiable pour une meilleure prise de décision. Ainsi, les principaux
objectifs assignés au projet sont :
La réduction de la durée globale de l’élaboration des rapports ;
La mise en place d’une politique de Reporting ;
La réduction du nombre d’intervenants lors de la production de rapports ;
Offrir aux décideurs et aux analystes la possibilité de faire des analyses appropriées ;
Offrir des informations fiables, cohérentes et pertinentes, contenant la logique souhaitée.
Planification
« Planifier optimise ainsi les chances de réussite d’un projet en améliorant la productivité grâce à une
meilleur maitrise de la qualité » [Soler, 2001]
Pour garantir le bon déroulement du projet, tout en respectant les délais, nous avons élaboré une
planification globale de conduite du projet. Le Diagramme suivant décrit cette phase ainsi que leur
ordonnancement prévu.
Figure 1 : Le diagramme de GRANT
Page 16
Figure 2 : Le diagramme d’allocation de ressources
Figure 3 : Légende du diagramme d’allocation de ressources
Page 17
PRESENTATION DE LA
STRUCTURE D’ACCUEIL
Page 18
I. Attributions
Suivant les termes de l’article 69 du décret N°2012 -546 /PRES/PM/MEF du 2 juillet 2012 portant
organisation du MEF, la DGSI a pour mission d’assurer la coordination et la mise en œuvre de la
politique d’informatisation du MEF.
A ce titre, elle est chargée notamment :
- de réaliser, de déployer, d’administrer et de maintenir les applications informatiques ;
- d’élaborer, d’actualiser et de mettre en œuvre le schéma directeur informatique ;
- de coordonner le suivi de l’exportation et de la maintenance des applications informatiques au
sein du ministère ;
- de gérer le parc informatique et l’infrastructure de communication ;
- d’administrer les systèmes ;
- De former et d’assister les utilisateurs du système informatique ;
- d’assurer la cohérence, la sécurité et l’évolution du système informatique du ministère en
conformité avec le schéma national ;
- de promouvoir l’expertise du ministère en matière de technologies de l’information et de la
communication et de gestion informatisée des finances publiques ;
Pour mieux organiser les tâches qui lui sont confiées, la DGSI est organisée en structures de mission et
structures d’appui.
II. Organisation et fonctionnement de la DGSI
L’organisation et le fonctionnement de la DGSI est régie par l’arrêté N°2012 -473 /MEF/SG/DGSI du
31 décembre 2012 portant attribution, organisation et fonctionnement de Direction Générale des
Services Informatiques. Au terme de l’article 4 du dit arrêté, la DGSI est organisée comme suit :
- La Direction générale ;
- Les structures d’appui ;
- Les structures centrales.
1. La Direction générale
La Direction générale comprend le Directeur général, le secrétariat du Directeur général et la Cellule
d’appui technique.
2. Les structures d’appui
Il existe 5 structures d’appui au sein de la DGSI que :
- la Cellule du Contrôle Interne et de Suivi-évaluation (CCI-SE) ;
- le Service des Ressources Humaines(SRH) ;
- le Service Financier et Matériel (SFM) ;
- le Service de la Communication et Relation Publique (SCRP) ;
- le Service des Archives et de la Documentation (SAD).
3. Les directions de services
Il existe 4 directions de services à la DGSI.
Page 19
3.1. La Direction des études et des applications (DEA)
La direction des études et applications est chargée d’assurer la réalisation, le déploiement,
l’administration et la maintenance des applications informatiques ainsi que du suivi du Schéma
Directeur Informatique du MEF.
Elle comprend deux (02) services qui sont :
- Le Service Etudes et Développement (SED)
- Le Service Exploitation et Production (SEP)
3.2. La Direction de l’Equipement et du Support Technique (DEST)
La direction de l’équipement et du support technique est chargée d’assurer la gestion prévisionnelle et
opérationnelle du parc informatique, le support technique et la formation des utilisateurs.
Elle est composée de trois (03) services :
- Le Service Equipement Informatique (SEI) ;
- Le Service Support Technique (SST) ;
- Le Service Formation des Utilisateurs (SFU) ;
3.3. La Direction des Réseaux et Systèmes (DRS)
La direction des réseaux et systèmes s’occupe de la gestion prévisionnelle et opérationnelle de
l’infrastructure de communication, des systèmes et des outils de collaboration du MEF.
La DRS comprend trois (03) services qui sont :
- Le Service Infrastructures de communication (SIC) ;
- Le Service Gestion des Systèmes(SGS) ;
- Le Service Internet et Intranet (S2I).
3.4. La Direction des Prestations Externes (DPE)
La direction des prestations externes est chargée de la poursuite de l’exécution de certaines activités de
l’ex Centre National de Traitement de l’Information (CENATRIN). A ce titre, elle est chargée de
fournir des logiciels et des services internet et associés aux clients et de l’expertise du Ministère en
matière de technologie de l’information et de la communication et de gestion informatisée des finances
publiques.
La DPE comprend également deux (02) services notamment :
- Le Service Assistance et Traitement (SAT) ;
- Le Service Relation Clientèle (SRC).
Page 20
4. L’organigramme
DGSI
CCISE CAT
SFM SRH
SAD SCRP
Secrétariat
DEA DESTDRS DPE
Page 21
PARTIE I: GENERALITES
« Un entrepôt de données ne s'achète pas, il se construit. » Bill Inmon
Page 22
I Introduction
Toutes les entreprises du monde disposent d’une masse de données plus ou moins considérable. Ces
informations proviennent soit de sources internes (générées par leurs systèmes opérationnels au fil des
activités journalières), ou bien de sources externes (web, partenaire, .. etc.).
Cette surabondance de données, et l’impossibilité des systèmes opérationnels de les exploiter à des fins
d’analyse conduit, inévitablement, l’entreprise à se tourner vers une nouvelle informatique dite
décisionnelle qui met l’accent sur la compréhension de l’environnement de l’entreprise et l’exploitation
de ces données à bon escient. En effet, les décideurs de l’entreprise ont besoin d’avoir une meilleure
vision de leur environnement et de son évolution, ainsi, que des informations auxquelles ils peuvent se
fier. Cela ne peut se faire qu’en mettant en place des indicateurs « business » clairs et pertinents
permettant la sauvegarde, l’utilisation de la mémoire de l’entreprise et offrant à ses décideurs la
possibilité de se reporter à ces indicateurs pour une bonne prise de décision.
Le « Data Warehouse », « Entrepôt de données » en français, constitue, dans ces conditions, une
structure informatique et une fondation des plus incontournables pour la mise en place d’applications
décisionnelles.
Le concept de Data Warehouse, tel que connu aujourd’hui, est apparu pour la première fois en 1980 ;
l’idée consistait alors à réaliser une base de données destinée exclusivement au processus décisionnel.
Les nouveaux besoins de l’entreprise, les quantités importantes de données produites par les systèmes
opérationnels et l’apparition des technologies aptes à sa mise en oeuvre ont contribué à l’apparition du
concept « Data Warehouse » comme support aux systèmes décisionnels.
I. 1 Les systèmes décisionnels
La raison d’être d’un entrepôt de données, comme évoqué précédemment, est la mise en place d’une
informatique décisionnelle au sein de l’entreprise. Pour cela il serait assez intéressant de définir
quelques concepts clés autour du décisionnel.
Afin de mieux comprendre la finalité des systèmes décisionnels, nous nous devons de les placer dans
leurs contextes et rappeler ce qu’est un système d’information.
«Le système d’information est l’ensemble des méthodes et moyens de recueil de contrôle et de
distribution des informations nécessaires à l’exercice de l’activité en tout point de l’organisation. Il a
pour fonction de produire et de mémoriser les informations, de l’activité du système opérant (système
opérationnel), puis de les mettre à disposition du système de décision (système de pilotage)»[Le
Moigne, 1977].
Page 23
Les différences qui existent entre le système de pilotage et le système opérationnel, du point de vue
fonctionnel ou des tâches à effectuer, conduit à l’apparition des « systèmes d’information décisionnels »
(S.I.D.). Ces différences seront clairement illustrées un peu plus loin dans notre document.
Parmi les différentes définitions du décisionnel « business intelligence B.I. » qui ont été données on
trouve : « Le Décisionnel est le processus visant à transformer les données en informations et, par
l'intermédiaire d'interrogations successives, transformer ces informations en connaissances. » [Dresner,
2001].
I.1.1 La place du décisionnel dans l’entreprise
Figure 4 : Le décisionnel au sein du Système d’information [Goglin, 1998]
La figure ci-dessus illustre parfaitement la place qui revient au décisionnel au sein d’une entreprise.
Cette place, comprend plusieurs fonctions clés de l’entreprise.
I.1.2 Les différentes composantes du décisionnel
Figure 5 : Les différentes composantes du décisionnel [Goglin, 1998]
Page 24
I.1.3 Comparaison entre le transactionnel et le décisionnel
Différences Systèmes transactionnels SID
Par les données
Orienté applications Orienté thèmes et sujets Situation instantanée Situation historique
Donnée détaillées et codées non redondantes Informations agrégées cohérentes souvent avec redondance
Données changeantes constamment Informations stables et synchronisées dans le temps
Pas de référentiel commun Un référentiel unique
L’usage
Assure l’activité au quotidien Permet l’analyse et la prise de décision Pour les opérationnel Pour les décideurs Mises à jour et requêtes simples Lecture unique et requêtes complexes
transparentes Temps de réponse immédiats Temps de réponse moins critiques Faibles volumes à chaque transaction Large volume manipulé Conçu pour la mise à jour Conçue pour l’extraction Usage maîtrisé Usage aléatoire
Tableau 1 : Tableau comparatif entre le transactionnel et le décisionnel
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 ».
I.2 Le data warehouse
Définition
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. »
Ces principales caracteristiques sont les usivantes :
- 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…
- Intégrée : le Data Warehouse va intégrer des données en provenance de différentes sources. Cela
nécessite la gestion de toute incohérence.
- Evolutives dans le temps : Dans un système décisionnel il est important de conserver les
différentes valeurs d’une donnée, cela permet les comparaisons et le suivi de l’évolution des
Page 25
valeurs dans le temps, alors que dans un système opérationnel la valeur d’une donnée est
simplement mise à jour.
- 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…).
I.3 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.
I.4 Structure des données d’un Data Warehouse
Le Data Warehouse a une structure bien définie, selon différents niveaux d’agrégation et de détail des données. Cette structure est définie par Inmon [Inmon, 2000] comme suit :
Figure 6 : Structure des données d’un data warehouse
Page 26
Données détaillées : ce sont les données qui reflètent les événements les plus récents, fréquemment
consultées, généralement volumineuses car elles sont d’un niveau détaillé.
Données détaillées archivées : anciennes données rarement sollicitées, généralement stockées dans un
disque de stockage de masse, peu coûteux, à un même niveau de détail que les données détaillées.
Données agrégées : données agrégées à partir des données détaillées.
Données fortement agrégées : données agrégées à partir des données détaillées, à un niveau
d’agrégation plus élevé que les données agrégées.
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.
I.5 Les composantes d’un Data Warehouse
L’environnement du Data Warehouse est constitué essentiellement de quatre composantes : les
applications opérationnelles, la zone de préparation des données, la présentation des données et les
outils d’accès aux données.
Les applications opérationnelles : ce sont les applications du système opérationnel de l’entreprise et
dont la priorité est d’assurer le fonctionnement de ce dernier et sa performance.
Ces applications sont extérieures au Data Warehouse.
Préparation des données : la préparation englobe tout ce qu’il y a entre les applications opérationnelles
et la présentation des données. Elle est constituée d’un ensemble de processus appelé ETL, « Extract,
transform and Load », les données sont extraites et stockées pour subir les transformations nécessaires
avant leur chargement.
« Un point très important, dans l’aménagement d’un entrepôt de données, est d’interdire aux utilisateurs l’accès à la zone de préparation des données, qui ne fournit aucun service de requête ou de présentation » [Kimball, 2002].
Page 27
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.
Zone d’outils d’accès (olap et data mining) : 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.
I.6 L’architecture d’un Data Warehouse
ETL
ExtractTransform
Load
Data Warehouse
Systèmes Opérationnels
ERP
CRM
Resource_5
Agrégats
fichier plat
Données
metadata
Analyse OLAP
Reporting
Data mining
Data Mart
Data Mart .
Data Mart.
Figure 7 : Architecture global d’un data warehouse
II. Modélisation des données de l’entrepôt
La modélisation multidimensionnelle a été introduite par Ralph Kimball. C’est une technique de
conception logique permettant de structurer les données de manière à les rendre intuitives aux
utilisateurs d'affaires et offrir une bonne performance aux requêtes.
II.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
Page 28
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 8 : Cube à plusieurs dimensions
Chaque point du cube contient les mesures relatives à une combinaison particulière de produit, de
magasin et de temps.
En plus de la perception intuitive qu’offre la modélisation dimensionnelle, celle-ci est réputée pour ses
performances élevées.
La nomination « schéma des jointures en étoile » a longtemps été adoptée pour décrire un modèle
dimensionnel. Cette nomination est due au fait que le diagramme qui représente un modèle
dimensionnel ressemble à une étoile, avec une grande table centrale et un jeu de petites tables auxiliaires
disposées en étoile autour de la table centrale. Celle-ci est appelée table de faits et les autres tables sont
appelées tables de dimensions. La figure suivante illustre untel modèle :
Dimension temps
Clé_tempsjour_desemaineMoistrimestreannee
Dimension produit
Clé_produitDescription_produitCategorie_produit
Fait de venteClé_tempsClé_produitClé_magasinQte_vendueSomme_vendue
Dimension magasin
Clé_magasinnom_magasinadresse_magasintype_magasin
<<<<
Figure 9 : Un modèle dimensionnel typique [Kimball, 1996]
Page 29
II.1.1 Concept de faits 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
II.1.2 Concept de dimension
Les tables de dimension sont les tables qui raccompagnent une table de faits, elles contiennent les
descriptions textuelles de l’activité. Une table de dimension est constituée de nombreuses colonnes qui
décrivent une ligne. C’est grâce à cette table que l’entrepôt de données est compréhensible et utilisable;
elles permettent des analyses en tranches et en dés.
Une dimension est généralement constituée : d’une clé artificielle, une clé naturelle et des attributs.
« Une table de dimension établit l’interface homme / entrepôt, elle comporte une clé primaire »
[Kimball, 2002].
II.1.3 Comparaison entre table de faits et table de dimensions
Caractéristiques Tables de faits Tables de dimensions Structure Peu de colonnes beaucoup de lignes Peu de lignes beaucoup de colonnes Données Mesurable, généralement numérique Descriptives généralement textuelles Référentiel Plusieurs clés étrangères Une clé primaire Valeur Prend de nombreuses valeurs Plus ou moins constantes Manipulation Participe à des calculs Participe à des contraintes Signification Valeurs de mesure Descriptive Rôle Assure les relations entre les
Dimensions Assure l’interface homme / entrepôt de données
Tableau 2 : Tableau comparatif entre tables de faits et tables de dimensions
II.2 Le concept modèle
Modèle en étoile : comme indiqué précédemment, ce modèle se présente comme une étoile dont le
centre n’est autre que la table des faits et les branches sont les tables de dimension. La force de ce type
de modélisation est sa lisibilité et sa performance.
Page 30
Figure 10 : Modèle en étoile
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.
Figure 11 : Modèle en flocon
Modèle en constellation : Ce n’est rien d’autre que plusieurs modèles en étoile liés entre eux
par des dimensions communes.
Figure 12 : Modèle en constellation
Page 31
II.3 Le concept OLAP
II.3.1 Généralités
Le terme OLAP (On-Line Analytical Processing) désigne une classe de technologies conçue pour
l’accès aux données et pour une analyse instantanée de ces dernières, dans le but de répondre aux
besoins de Reporting et d’analyse.
R. Kimball définit le concept « OLAP » comme «Activité globale de requêtage et de présentation de
données textuelles et numériques contenues dans l’entrepôt de données; Style d’interrogation
spécifiquement dimensionnel » [Kimball, 2005].
C’est en continuant sur sa lancée, qui lui a permis de définir le model OLTP pour les bases de données
relationnelles, que le concept OLAP fut introduit et défini 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].
II.3.2 Les systèmes à architecture MOLAP
Ces systèmes MOLAP « Multidimentional On-line Analytical Processing » sont conçus
exceptionnellement pour l’analyse multidimensionnelle.
R. Kimball définit ces systèmes comme étant un « Ensemble d’interfaces utilisateur, d’applications et de
technologies de bases de données propriétaire dont l’aspect dimensionnel est prépondérant » [Kimball,
2005].
Ainsi donc cette base adopte réellement la structure multidimensionnelle, exploitant de ce fait ces
capacités au maximum. En effet MOLAP offre des temps d’accès optimisés et cela en prédéfinissant les
opérations de manipulation et de chemin d’accès prédéfinis.
Autre caractéristique du MOLAP c’est qu’il agrège tout par défaut, pénalisant du coup le système
lorsque la quantité de données à traiter augmente. On parle généralement de volume de l’ordre du giga-
octet pas plus.
Figure 13 : Principe de l’architecture MOLAP [Nakache, 1998]
Page 32
II.3.3 Les systèmes à architecture ROLAP
« Ensemble d’interfaces utilisateurs et d’applications qui donnent une vision dimensionnelle à des bases
de données relationnelles » [Kimball, 2005].
Les systèmes ROLAP « Relationnel On-line Analytical Processing » sont en mesure de simuler le
comportement d’un SGBD multidimensionnel en exploitant un SGBD relationnel. L’utilisateur aura
ainsi l’impression d’interroger un cube multidimensionnel alors qu’en réalité il ne fait qu’adresser des
requêtes sur une base de données relationnelles.
ROLAP n’agrège rien. Les règles d’agrégations sont crées au préalable et représentées dans une table
relationnelle ce qui cause une lourdeur d’administration mais confère une certaine performance et un
gage de cohérence lors de l’utilisation.
Figure 14 : Principe de l’architecture ROLAP [Nakache, 1998]
II.3.4 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.
II.4 La navigation dans les données
Les données dimensionnelles sont représentées au travers d’un cube regroupant à la fois la structure et
les valeurs des données (voir Figure 13). Chaque case dans le cube présente les valeurs des mesures
d’un fait (par exemple les montants des locations sont représentées à l’intersection des dimensions
Agence, Véhicule et Temps). Chaque arête du cube, représentant une dimension, est composée des
valeurs d’un paramètre de la dimension considérée.
Page 33
La Figure 16 présente le cube analysant les mesures du fait Location en fonction des paramètres Année
de la dimension Temps, Marque de la dimension Véhicule et Ville de la dimension Agence.
Figure 15 : Exemple de cube dimensionnel
Une nouvelle génération d’opérateurs algébriques basés sur le concept de cube a vu le jour (Codd et al,
1993). La représentation dimensionnelle fait appel à des opérateurs spécifiques qui faciliteront l’analyse
et la visualisation des cubes dimensionnels.
II.4.1 Opérateurs de restriction (Slice et Dice)
Le « Slicing » et le « Dicing » sont des techniques qui offrent la possibilité de faire des tranches «
trancher » dans les données par rapport à des filtres de dimension bien précis, se classant de fait
comme des opérations liées à la structure « se font sur les dimensions ». La différence entre eux se
manifestent dans le fait que :
Le Slicing consiste à faire une sélection de tranches du cube selon des prédicats et selon une dimension
« filtrer une dimension selon une valeur » [Chouder, 2008].
Figure 16 : Exemple de slicing
Page 34
Le Dicing, quant à lui, peut être vu comme étant une extraction d’un sous cube.
Figure 17 : Exemple de dicing
II.4.2 Opérateurs de forage («Roll_Up» et «Drill_Down»)
Ils permettent soit de généraliser l’analyse, soit de l’affiner en modifiant le paramètre utilisé pour définir
les valeurs d’une arête du cube. En effet, les dimensions sont associées à des hiérarchies; ces deux
opérateurs permettent, respectivement, de « monter » ou de « descendre » dans une hiérarchie.
Figure 18 : Exemple de drill up & drill down
II.4.3 Opérateurs de rotation («rotate»)
L’opérateur de rotation («Rotate») permet d’avoir accès aux différentes vues de données : c’est
le fait d’inverser les axes visualisés du cube. Un cube de n dimensions possède n * (n – 1) vues
possibles.
Page 35
Figure 19 : Exemple de rotate
III. Démarche de construction d’un entrepôt de données
Plusieurs chercheurs ou équipes de recherche ont essayé de proposer des démarches pour la réalisation
d’un projet Data Warehouse, ces démarches se croisent essentiellement dans les étapes suivantes :
• modélisation et conception du Data Warehouse ;
• alimentation du Data Warehouse ;
• mise en œuvre du Data Warehouse ;
• administration et maintenance du Data Warehouse.
III.1 Modélisation et conception du data warehouse
Les deux approches les plus connues dans la conception des Data Warehouse sont :
• l’approche basée sur les besoins d’analyse ;
• l’approche basée sur les sources de données.
Aucune des deux approches citées n’est ni parfaite, ni applicable à tous les cas. Toutes deux doivent être
étudiées pour choisir celle qui s’adapte le mieux à notre cas.
Quelque soit l’approche adoptée pour la conception d’un Data Warehouse, la définition de celui-là reste
la même. En étant un support d’aide à la décision, le Data Warehouse se base sur une architecture
dimensionnelle.
III.1.1 Approche « besoins d’analyse »
Le contenu du Data Warehouse sera déterminé selon les besoins de l’utilisateur final.
Cette approche est aussi appelée « approche descendante » (Top-Down Approach) et est illustrée par R.
Kimball grâce à son cycle de vie dimensionnel comme suit :
Page 36
Figure 20 : Illustration de l’approche « besoins d’analyse » [Kimball, 2004]
Avantages inconvénients Aucun risque de concevoir une solution obsolète avant d’être opérationnelle
Pas de prise en compte de l’évolution des besoins de l’utilisateur.
Nécessite une modification de la structure du Data Warehouse en
cas de nouveau besoin
Négligence du système opérationnel Difficulté de déterminer les besoins des utilisateurs
Tableau 3 : Avantages et inconvénients de l’approche « besoins d’analyse »
III.1.2 Approche « Source de données »
Le contenu du Data Warehouse est déterminé selon les sources de données. Cette approche est appelée :
Approche ascendante (Bottom-up Approach).
Figure 21 : Illustration de l’approche « source de données » [Inmon, 2002]
Page 37
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 dirai ce dont j’ai vraiment besoin»1, il considère que les besoins sont
en constante évolution.
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
Avantages inconvénientsMeilleure prise en charge de l’évolution des
besoins
Risque de concevoir une solution obsolète avant qu’elle soit
opérationnelle
Evolution du schéma des données source
Complexité de source de données
Tableau 4 : Avantages et inconvénients de l’approche « source de données »
III.1.3 Approche mixte
Une combinaison des deux approches appelée hybride ou mixte peut s’avérer efficace Elle prend en
considération les sources de données et les besoins des utilisateurs.
Cette approche consiste à construire des schémas dimensionnels à partir des structures des données du
système opérationnel, et les valider par rapport aux besoins analytiques. Cette approche cumule les
avantages et quelques inconvénients des deux approches déjà citées, telles que la complexité des sources
de données et la difficulté quant à la détermination des besoins analytiques.
Figure 22 : Illustration de l’approche « mixte »
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.
1 “Give me what I tell you I want, then I can tell you what I really want.”[Inmon, 2002]
Page 38
III.1.4 Choix de l’approche de mise en œuvre
Après l’étude comparative des approches, l’approche mixte a été retenue par le groupe de projet et
validée par le comité de pilotage, comme le choix le plus judicieux pour la mise en œuvre de la solution
finale. En effet, au vue de l’importance d’avoir une situation exhaustive et transparente de la gestion des
financements extérieurs, la solution future devra être appropriée par tous les acteurs, d’où la nécessité
d’implication et de prise en compte des besoins des utilisateurs. En outre, les solutions opérationnelles
existantes apportent satisfaction en matière de la gestion des finances publiques. Il est donc
indispensable de tenir comptes de ces systèmes dans la mise en œuvre de l’entrepôt.
III.2 Alimentation du Data Warehouse
Une fois le Data Warehouse conçu, il faut l’alimenter et le charger en données. Cette alimentation (le
plus souvent appelée processus ETL « Extract-Transform-Load ») se déroule en 3 phases qui sont :
• extraction des données primaires (issues par exemple des systèmes de production) ;
• transformation des données ;
• le chargement des données traitées dans l’entrepôt de données.
Ces trois étapes décrivent une mécanique cyclique qui a pour but de garantir l’alimentation du Data
Warehouse en données homogènes, propres et fiables.
III.2.1 Les phases de l’alimentation (ETL)
Les phases du processus E.T.L. représentent la mécanique d’alimentation du Data Warehouse. Ainsi
elles se déroulent comme suit :
a. L’extraction des données
« L’extraction est la première étape du processus d’apport de données à l’entrepôt de données.
Extraire, cela veut dire lire et interpréter les données sources et les copier dans la zone de préparation
en vue de manipulations ultérieures. » [Kimball, 2005].
Elle consiste en :
• Cibler les données ;
• Appliquer les filtres nécessaires ;
• Définir la fréquence de chargement.
Lors du chargement des données, il faut extraire les nouvelles données ainsi que les changements
intervenus sur ces données.
Page 39
b. La transformation des données
La transformation est la seconde phase du processus. Cette étape, qui du reste est très importante, assure
en réalité plusieurs tâches qui garantissent la fiabilité des données et leurs qualités. Ces tâches sont :
• Consolidation des données ;
• Correction des données et élimination de toute ambiguïté ;
• Elimination des données redondantes ;
• Compléter et renseigner les valeurs manquantes.
Cette opération se solde par la production d’informations dignes d’intérêt pour l’entreprise et de et sont
donc prêtes à être entreposées
c. Le chargement des données
C’est la dernière phase de l’alimentation d’un entrepôt de données, le chargement est une étape
indispensable. Elle reste toute fois très délicate et exige une certaine connaissance des structures du
système de gestion de la base de données (tables et index) afin d’optimiser au mieux le processus.
III.2.2 Politique de l’alimentation
Le processus de l’alimentation peut se faire de différentes manières. Le choix de la politique de
chargement dépend des sources : disponibilité et accessibilité. Ces politiques sont2 :
• Push : dans cette méthode, la logique de chargement est dans le système de production.
Il " pousse " les données vers la zone de préparation quand il en a l'occasion. L'inconvénient est que si
le système est occupé, il ne poussera jamais les données.
• Pull : contrairement à 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.
le processus d’alimentation doit répondre à certaines exigences illustrées par la figure suivante :
2 http://grim.developpez.com/articles/concepts/etl/
Page 40
Figure 23 : Objectif de qualité de données dans un processus ETL [Kimball, 2004]
• Sûr : assure l’acheminement des données et leur livraison.
• Rapide : la quantité de données manipulées peut causer des lenteurs. Le processus d’alimentation doit
palier à ce problème et assurer le chargement du Data Warehouse dans des délais acceptables.
• Correctif : le processus d’alimentation doit apporter les correctifs nécessaires pour améliorer la qualité
des données.
• Transparent : le processus de l’ETL doit être transparent afin d’améliorer la qualité des données.
III.2.3 Exploitation du data warehouse
L’exploitation du Data Warehouse se fait par le biais d’un ensemble d’outils analytiques développés
autour du Data Warehouse. Donc cette étape nécessite l’achèvement du développement, ou de la mise
en place, de ces outils qui peuvent accomplir les fonctions suivantes:
a. Requêtage ad-hoc
Le requêtage ad-hoc reste très fréquent dans ce type de projet. En effet, les utilisateurs de l’entrepôt de
données, et spécialement les analystes, seront amenés à interagir avec le DW via des requêtes ad-hoc
dans le but de faire les analyses requises par leurs métiers et, d’élaborer aussi, des rapports et des
tableaux de bords spécifiques.
Page 41
b. Le reporting
Destiné essentiellement à la production de rapports et de tableaux de bord, c’est un procédé visant à
fournir au sein de l'Entreprise une information agrégée ou détaillée, simple ou complexe sous forme de
représentation lisible et interprétable (liste de données, tableau croisé ou graphique) nommée rapport, à
partir d'une source de données normalisée issue des différents systèmes amont, apportant une réponse
aux principales questions analytiques dans la société : Que s'est il passé ?
c. L’analyse dimensionnelle
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.
d. L’analyse dimensionnelle
Les tableaux de bord sont un outil de pilotage qui donne une vision sur l’évolution d’un processus, afin
de permettre aux responsables de mettre en place des actions correctives.
« Le tableau de bord est un ensemble d’indicateurs peu nombreux conçus pour permettre aux
gestionnaires de prendre connaissance de l’état et de l’évolution des systèmes qu’ils pilotent et
d’identifier les tendances qui les influenceront sur un horizon cohérent avec la nature de leurs fonctions
» [Bouquin, 2003].
e. Le Data Mining
Au sens littéral du terme, le Data Mining signifie le forage de données. Le but de ce forage est d’extraire
de la matière brute qui, dans notre cas, représente de nouvelles connaissances. L’idée de départ veut
qu’il existe dans toute entreprise des connaissances utiles, cachées sous des gisements de données. Le
Data Mining permet donc, grâce à un certain nombre de techniques, de découvrir ces connaissances en
faisant apparaître des corrélations entre ces données.
f. Maintenance et croissance
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]
Page 42
Support : assurer un support aux utilisateurs pour leur faire apprécier l’utilisation de l’entrepôt de
données. Cela permet en outre de détecter les correctifs nécessaires à apporter.
Formation : il est indispensable de prévoir un plan de formations continues aux utilisateurs de
l’entrepôt de données.
Support technique : un entrepôt de données est considéré comme un environnement de production. Il
devient alors nécessaire que le support technique doit surveille avec la plus grande vigilance les
performances et les tendances en ce qui concerne la charge du système.
Management de l’évolution : il faut toujours s’assurer que l’implémentation répond aux besoins de
l’entreprise. En plus du suivi et de la maintenance du Data Warehouse, des demandes d’expansion sont
envisageables pour de nouveaux besoins, de nouvelles données ou pour des améliorations.
Page 43
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 ses
performances.
Afin de mettre en place ce genre de système, il est nécessaire de choisir et d’adopter une démarche
précise qui doit tenir compte des réalités de l’entreprise et des contraintes du projet. L’alimentation en
données constitue l’étape à laquelle il faut accorder le plus d’attention et de temps. En effet, elle est le
garant de contenance de l’entrepôt en données fiables et correctes. Une fois l’alimentation terminée,
l’exploitation des données peut alors se faire par différentes méthodes. L’utilisation d’outil OLAP reste,
cependant, l’aspect le plus intéressant dans cette exploitation permettant la navigation dans les données
de l’entrepôt à la demande.
Au cours de la seconde partie de cette étude, nous allons essayer d’utiliser les concepts présentés dans la
synthèse bibliographique, et cela afin de mettre en œuvre notre système.
Page 44
PARTIE II:
MODELISATION
Page 45
CHAPITRE I: ETUDE DE L’EXISTANT
Page 46
I Introduction
Le ministère de l’Economie et des Finances, à travers la Direction de la Dette Publique, qui est
le secrétariat technique du Circuit Intégré des Financements Extérieurs, veut par le canal de ce présent
projet palier le manque d’outil décisionnel en matière des financements extérieurs.
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, à travers ce chapitre, présenter une analyse de l’existant opérationnel
et décisionnel du ministère en matière de gestion des financements extérieurs. 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
forces et faiblesses qui peuvent exister.
I.1 Etat de l’opérationnel
Le ministère de l’Economie et des Finances dispose depuis avril 2011 d’un outil opérationnel de gestion
des financements extérieurs.
L’objectif global visé est le renforcement des capacités du Burkina Faso dans la gestion des
financements extérieurs à travers :
- la mise en place d’un nouveau schéma du circuit d’échange d’information dans le cadre du suivi de
la gestion des financements extérieurs par la mise en œuvre de nouvelles procédures de gestion et par
la redéfinition du rôle de chacun des intervenants dans le processus ;
- la mise au point d’un outil informatisé de la gestion des financements extérieurs qui prend en compte
toutes les phases de négociations, de mobilisation, d’exécution et de comptabilisation de l’ensemble
des financements extérieurs ;
- la mise en œuvre de l’intégration informatique des systèmes existants (SYGADE, CID, CIR, CIE,
SGDF, SIMP) à travers le développement d’interfaces permettant un échange aisé d’informations
entre les différentes applications actuellement en utilisation au sein du Ministère de l’Economie et
des Finances.
Ce nouveau système permet aux autorités de disposer d’un outil fiable de maîtrise et de suivi des
données pour la prise de décisions stratégiques et contribue à mesurer plus efficacement les efforts du
Burkina Faso dans la lutte pour le développement.
Conçu pour être utilisé par tous les départements ministériels et institutions au Burkina, et aussi par les
unités de coordinations des projets et programmes de développement sur le territoire national, le CIFE
Page 47
connait dans un premier temps une exploitation centralisée se résumant uniquement à l’utilisation de la
DGTCP, de la DGCOOP, de la DGB et de la DGEP.
En exploitation, depuis 2011, l’élaboration, l’exécution et la comptabilisation des financements
extérieurs se font dans le CIFE. Des difficultés sont certes rencontrées, mais une nette progression des
chiffres en termes de budgétisation et d’exécution est à mettre à l’actif de l’application.
I.2 Etat du décisionnel
Il est intéressant de signaler que le ministère des l’Economie et des Finances, dans sa fonction de
mobilisation et d’exécution des financements extérieurs, ne dispose d’aucun système d’aide à la
décision automatique ou semi-automatique. Aussi, tout processus d’analyse et de prise de décision à
tous les niveaux se base essentiellement sur des rapports dont les données sont extraites et consolidées à
partir des systèmes transactionnels d’une manière manuelle.
Lors de notre étude de l’existant, nous avons pu recenser trois types de rapport à produire par trois
structures différentes en fonction du champ’ d’intervention dans le CIFE. Les trois types de rapports se
distinguent par leurs utilisateurs finaux, la structure chargée de leur élaboration et le niveau de
consolidation. Ce sont les rapports sur les informations générales des projets et programmes et les
informations générales des conventions au niveau de la DGCOOP, le rapport d’élaboration du budget au
niveau de la DGB et enfin le rapport sur la mobilisation et l’exécution au niveau de la DGTCP.
I.2.1 Niveau DGCOOP
A ce niveau, les utilisateurs ont besoin juste des informations d’ordre général des projets et conventions.
Au titre de ces informations nous avons, les composantes, volets et activités des projets, les partenaires
techniques qui financent le projet, les zones d’interventions du projet, les secteurs d’activités….Pour ce
qui concerne les conventions, les besoins demandés sont essentiellement la liste des conventions par
étape, les prévisions de financement par projet et par convention. Cela suppose donc, la participation de
différents acteurs que sont les utilisateurs finaux et l’équipe technique du CIFE.
Dans le meilleur des cas, le rapport demandé concerne des données déjà consolidées et prêtes à
l’utilisation. L’élaboration du rapport se fait donc sans grandes difficultés. Sinon, le procédé
d’extraction et de consolidation est relancé. Le diagramme suivant donne une vision claire de la manière
dont sont consolidées les données et les rapports élaborés en partant de la demande d’un état donné
jusqu'à sa production :
Page 48
'
Les données ne sont pas consolidées
Pas de problèmes
Autorité demadeur DGCOOP EQUIPE CIFE
DemandeInstruction de DG
alternative Contacter équipe CIFE
Extraction des données
Transmission des donnéesReception des données
Alternative
Consolider les données
Problèmes dans les données
Elaboration du Rapport
Les données sont déjà consolidées
Reception du rapport
Transmission rapport
Figure 24 : Diagramme d’activité modélisant l’édition d’un rapport sur les projets et convention
À partir de ce diagramme on peut avoir une idée sur le nombre d’intervenants dans cette procédure
d’élaboration d’un rapport sur les projets et programme et les conventions. Cette procédure se déroule
comme suit:
Phase 1 : l’autorité formule la requête sous forme de courrier administratif à la DGCOOP.
Phase 2 : la DGCOOP, en recevant une demande de la part de l’autorité, impute à un agent qui lance la procédure de consolidation si toute fois les données sont disponibles. Sinon l’équipe du projet CIFE sera saisie.
Phase 3 : L’équipe du projet CIFE, en recevant la demande d’extraction, construit une requête à base de
scripts d’extraction. L’étape d’extraction aboutit à la transmission de fichier texte ou Excel vers les
utilisateurs de la DGCOOP.
Phase 4 : Une fois les données reçues en totalité, la consolidation se fait au niveau de l’agent DGCOOP
manuellement. Cette consolidation permet d’élaborer les rapports voulus.
Phase 5 : Le rapport est validé par le chef de service, le Directeur, puis le Directeur Général avant d’être
envoyé à l’autorité demandeur.
Page 49
Remarque : la procédure se répète généralement quatre fois par an, la consolidation des données se
faisant chaque trimestre. Mais cela n’empêche pas le lancement de cette procédure en cas de nécessité.
I.2.2 Niveau DGB
A ce niveau, les utilisateurs ont besoin d’informations plus approfondies. Au titre de ces informations
nous avons, les dépenses prévues par projet ou programme, par bailleur, les imputations budgétaires
ainsi que le budget prévisionnel annuel par bailleur. Cela suppose toujours, la participation de différents
acteurs que sont les utilisateurs finaux et l’équipe technique du CIFE.
Remarque : la procédure se répète généralement une fois par an.
I.2.1 Niveau DGTCP
A ce niveau, les utilisateurs ont besoin en général, d’informations financières. Au titre de ces
informations nous avons, les décaissements hebdomadaires par bailleurs et par projet, les dépenses
effectives par projets, les paiements effectifs par bailleurs, projets et dépenses. Cela suppose toujours, la
participation de différents acteurs que sont les utilisateurs finaux et l’équipe technique du CIFE.
La procédure se répète généralement chaque semaine. Sauf en cas de problèmes, toute échange d’information « demandes et fichiers joints » se fait par le biais de la messagerie interne du groupe.
I.3 Etude des besoins
L’objectif premier de tout entrepôt de données est d’être en mesure de répondre aux besoins des
utilisateurs. Une étude approfondie des besoins s’avère donc nécessaire. Cette étude se fait suivant les
deux démarches décrites lors de la synthèse bibliographique. Ce sont l’approche «Buttom-Up » et
l’approche « Top-Down ».
En règle générale, il est déconseillé l’application exclusive de l’une des démarches. Celle généralement
adoptée est la démarche mixte qui allie entre les deux précédentes dans un souci de prise en
considération des besoins des décideurs sans perdre de vue toute possibilité et opportunité offerte par les
données sources. Cette approche permet donc de recueillir, corriger et de modérer les attentes des
utilisateurs dès le départ, tout en détectant d'éventuels besoins non exprimés.
Durant l’étude des besoins on ne peut se limiter à ceux exprimés par les utilisateurs, il faudrait
absolument prendre en compte l’avis des administrateurs des bases de données des systèmes sources.
« Les DBA sont les principaux experts sur les applications existantes susceptibles d’alimenter l’entrepôt
de données. Leurs interviews servent à confronter aux réalités certains des thèmes qui surgissent lors
des rencontres avec les utilisateurs finaux. »[Kimball, 96]
Page 50
I.3.1 Description de la démarche d’étude des besoins
Dans le souci de réaliser une étude complète que possible, nous avons adopté la démarche mixte qui a
pour étapes :
- Étude préliminaire des systèmes sources et interviews sommaires avec les DBA ;
- Détection des postes susceptibles d'être porteurs d'informations utiles ;
- Planification, préparation et conduite des interviews ;
- Rédaction et validation du recueil récapitulatif des besoins.
a. Etude préliminaire des systèmes sources et interviews des DBA
Cette phase représente une étape de compréhension des systèmes opérationnels et de leur interaction.
Elle a pour but de consolider les connaissances acquises durant l’étude de l’existant. En outre, elle
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, les expert métiers de CIFE et des différentes applications interdépendantes, ont été une
source d’information assez bénéfique, eu égard à leur connaissance des applications et de leur maîtrise
du métier.
b. Description des postes susceptible d’être porteur d’informations.
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ées dans le tableau
suivant:
Structure Intitulé du poste
DGCOOP Direction de la Coopération Bilatérale (DCB) Direction de la Coopération Multilatérale (DCM)
DGB Direction de la Programmation Budgétaire (DPB) Direction de l’Exécution Budgétaire (DEB)
DGTCP Direction de la Dette Publique (DDP) DGEP Direction de la Coordination et l'Evaluation des Investissements publics (DCEI)
Tableau 5 : Tableau représentant les différents postes de travail
Page 51
c. Rédaction et validation du recueil 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 :
volets Besoins enregistrés
Suivi des projets et programmes
utilisateurs Ce volet a été sollicité surtout au niveau de la DCB et de la DCM et la DGEP
besoins
Les utilisateurs du module 1 ont besoin surtout de connaitre la répartition des projets par zone géographique, par secteur d’activité et dans le temps, leur décomposition en composante/volet, l’apport des bailleurs par projet en terme de requête conclues.
Suivi de l’élaboration budgétaire
utilisateurs Ce volet a été sollicité surtout au niveau de la DGB et de la DGTCP
besoins Les utilisateurs du module 3 ont besoin surtout de connaitre les prévisions annuelles par bailleurs, par convention et par projet
Suivi de la mobilisation
utilisateurs Ce volet a été sollicité surtout au niveau de la DGTCP
besoins Les utilisateurs des modules 3 et 4 ont besoin surtout de connaitre les décaissements hebdomadaires initiés par type de demandes et par bailleur, ainsi que les décaissements effectifs
Suivi de l’exécution
utilisateurs Ce volet a été sollicité surtout au niveau de la DGTCP
besoins
Les utilisateurs du module 5 ont besoin surtout de connaitre les dépenses effectuées au sein des projets par natures, par projet, et dans le temps Aussi, les paiements effectifs par dépense, par projet et dans le temps
Tableau 6 : Synthétisation des besoins recensés.
Page 52
Conclusion
L’étude de l’existant nous permet d’une part, d’avoir une vision générale des procédures d’élaboration
de rapports et de consolidation des données d’autre part de décider de la manière de construction de
l’entrepôt de données et de son architecture.
Page 53
CHAPITRE II: CONCEPTION DE LA SOLUTION
Page 54
Introduction
La conception de la solution est réalisée à partir de l’étude des besoins fonctionnels. Elle a pour objectif
de fournir aux utilisateurs, une définition détaillée et complète des aspects externes et internes du
fonctionnement du système futur. Pour mieux atteindre notre objectif, nous procéderons à une
modélisation dimensionnelle qui est le plus souvent associée aux entrepôts de données compte tenu de
ses avantages.
Il est souvent nécessaire de classifier les sujets recensés selon l’intérêt qu’ils représentent pour les
décideurs et les facilités de réalisation. En effet cette classification devra permettre d’aider au choix de
l’activité à modéliser en premier de manière à garantir des résultats satisfaisants.
Page 55
I Processus de la modélisation dimensionnelle
La conception d’un modèle dimensionnel passe par cinq étapes essentielles qui sont :
- le choix de l’activité à modéliser ;
- la définition de l’activité ;
- la définition des dimensions qui décrivent une ligne de la table de fait ;
- la définition des mesurables du fait ;
- la définition des agrégats.
Le choix de l’activité à modéliser se fait après classement des activités dans une matrice dite d’analyse
des priorités [Kimball, 2004]. Cette matrice à pour objectif la détermination de la première activité. La
figure suivante donne une illustration du classement des sujets recensés fait en collaboration avec les
décideurs et les techniciens.
Exécution
Mobilisation
Inscription Projets
Elaboration
Figure 25 : Analyse des priorités
I.1 Inscription Projet
I.1.1 Présentation du sujet
Ce volet constitue le point de départ des financements extérieurs. Les coûts de projets, les montants des
requêtes de financement par bailleurs ainsi que la répartition géographique et par secteur d’activités
constituent des indicateurs indispensables de sorte que leur disponibilité s’avère nécessaire pour les
décideurs.
I.1.2 Grain du sujet
Le choix du grain le plus fin donne un maximum de flexibilité. Dans le cas des projets et programme le
grain le plus fin, ou le niveau de détail le plus bas, correspond à une inscription du projet ou programme
dans la liste des projets en exécution, d’où une ligne de table de fait correspondant à :
Suivi du volume de financement et de la quantité des projets par zone géographique, secteur d’activité,
par bailleur à une date donnée.
Page 56
I.1.3 Les dimensions participantes du modèle
Les dimensions ont pour objectif de décrire le fait.
a) 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].
Elle se présente comme suite :
Dimension _Temps----
PK_CODE_TEMPSDATESEMESTREANNEE
Figure 26 : La dimension Temps de l’activité « inscription projet»
Le niveau de détail le plus bas de cette dimension est le semestre en raison de la fréquence lente
d’inscription de projet et programme de développement sur le plan national. Il sera utilisé une clé
artificielle dans cette dimension comme clé primaire pour faciliter la manipulation.
Nom colonne description PK_CODE_TEMPS Clé artificielle de la dimension temps DATE La date au format complet SEMESTRE Semestre de la date ANNEE Année de la date
Tableau 7 : Tableau descriptif de la dimension TEMPS
b) Dimension « Bailleur »
Le bailleur s’impose comme un élément important dans l’analyse et intéresse les analystes et les
décideurs de tous les départements étant donné que les financements proviennent d’eux. Outre ce qu’il
représente dans une opération d’inscription d’un projet ou programme, l’analyse du comportement du
bailleur peut aider à mieux gérer la collaboration et les relations de partenariat.
DIM BAILLEUR-----
PK_CODE_BAILLEURNOM_BAILLEURSIGLE_BAILLEURCODE_TYPE_BAILLEURADRESSE_BAILLEUR
Figure 27 : La dimension BAILLEUR de l’activité « inscription projet»
Page 57
Nom colonne description PK_CODE_BAILLEUR Clé de la dimension bailleur NOM_BAILLEUR Le nom complet du bailleur SIGLE_BAILLEUR Le sigle ou le nom court du bailleur ADRESSE_BAILLEUR Adresse du bailleur (sa localité, son téléphone, son mail…) CODE_TYPE_BAILLEUR Le type du bailleur (bilatéral ou multilatéral)
Tableau 8 : Tableau descriptif de la dimension BAILLEUR
c) Dimension « secteur activité »
Un secteur d’activité est un domaine défini d’activités interdépendantes qui concourent au
développement du dit domaine.
DIM SECTEUR ACTIVITE
--
PK_CODE_SECTEURNOM_SECTEUR
: :
Figure 28 : La dimension SECTEUR_ACTIVITE de l’activité « inscription projet»
Nom colonne description PK_CODE_SECTEUR Clé de la dimension secteur d‘activité NOM_SECTEUR Le nom complet du secteur d’activité
Tableau 9 : Tableau descriptif de la dimension Secteur_activité
d) Dimension « Zone géographique »
Elle définit la zone où le fait a eu lieu. Le grain le plus ici correspond au département. Une clé
artificielle a été introduite du fait de l’évolution possible de cette dimension.
DIM
ZONE_GEOGRAPHIQUE-----
PK_CODE_ZONENOM_ZONECODE_REGIONCODE_PROVINCECODE_DEPARTEMENT
Figure 29 : La dimension ZONE_GEOGRAPHIQUE de l’activité « inscription projet»
Nom colonne description PK_CODE_ZONE Clé de la dimension Zone géographique NOM_ZONE Le nom complet de la zone CODE_REGION Code de la région CODE_PROVINCE Code de la province CODE_DEPARTEMENT Code du département
Tableau 10 : Tableau descriptif de la dimension zone géographique
Page 58
I.1.4 Les mesurables
Les mesurables qui correspondent à l’activité « inscription projet» et qui permettent de mesurer les
performances de cette activité, sont la « quantité des projets inscrits» et le « volume de financement »
I.1.5 Le modèle en étoile de l’activité «inscription projet»
Dimension _Temps----
PK_CODE_TEMPSDATESEMESTREANNEE
DIM BAILLEUR-----
PK_CODE_BAILLEURNOM_BAILLEURSIGLE_BAILLEURCODE_TYPE_BAILLEURADRESSE_BAILLEUR
DIM SECTEUR ACTIVITE
--
PK_CODE_SECTEURNOM_SECTEUR
: :
DIM ZONE_GEOGRAPHIQUE-----
PK_CODE_ZONENOM_ZONECODE_REGIONCODE_PROVINCECODE_DEPARTEMENT
Fait inscription projet----
PK_CODE_BAILLEURPK_CODE_SECTEURPK_CODE_TEMPSPK_CODE_ZONE
::::
++
Quantite ()Volume ()
: int: Number
Figure 30 : Modèle en étoile de l’activité « inscription projet»
I.2 Elaboration
I.2.1 Présentation du sujet
L’élaboration du budget sur financements extérieurs est la phase de prévision pour chaque projet de
développement, les futurs possibles décaissements de l’année N+1. Les indicateurs les plus utilisés à ce
niveau sont le taux de l’apport extérieur dans le budget national, le taux de prévision par bailleur d’une
année N par rapport à une année N+1, le taux global des financements extérieurs d’une année N par
rapport à une année N+1.
I.2.2 Grain du sujet
Dans le cas de l’élaboration, le grain le plus fin, ou le niveau de détail le plus bas, correspond à une
prévision par bailleur et par projet à une date donnée, d’où une ligne de table de fait correspondant à :
Suivi des montants prévu par bailleur et par projet à une date donnée.
I.2.3 Les dimensions participantes du modèle
Les dimensions participantes à ce modèle sont essentiellement les dimensions « temps », la dimension
« projet », la dimension « convention » et la dimension « bailleur »
Page 59
I.2.4 Le modèle en étoile de l’activité « élaboration »
Dimension _Temps.,
-----
PK_CODE_TEMPSDATEMOISSEMESTREANNEE
DIM BAILLEUR..-----
PK_CODE_BAILLEURNOM_BAILLEURSIGLE_BAILLEURCODE_TYPE_BAILLEURADRESSE_BAILLEUR
DIM PROJET..---
PK_CODE_PROJETLIBELLE_PROJETMONTANT_PROJET
DIM CONVENTION..----
PK_CODE_CONVENTIONLIBELLE_CONVENTIONDATE_SIGNATUREMONTANT_CONVENTION
Fait prevision----
PK_CODE_BAILLEURPK_CODE_PROJETPK_CODE_TEMPSPK_CODE_CONVENTION
+ Montantprevu () : Number
Figure 31 : Modèle en étoile de l’activité « élaboration»
I.3 Mobilisation
I.3.1 Présentation du sujet
Le volet mobilisation des financements extérieurs est d’autant plus complexe qu’il met en relation l’Etat
et ses différents bailleurs pour ce qui est du décaissement des prévisions annuelles mais aussi parce que
les procédures de décaissement varient selon les bailleurs. Les indicateurs à ce niveau sont
essentiellement le taux de décaissement par bailleur. Il est intéressant de suivre cet indicateur qui est
fortement dépendant du taux de l’exécution des dépenses que nous verrons dans le volet suivant.
I.3.2 Grain du sujet
Dans le cas de la mobilisation, le grain le plus fin, ou le niveau de détail le plus bas, correspond à un
décaissement par bailleur à une date donnée, d’où une ligne de table de fait correspondant à :
Suivi des montants décaissements demandés et le montant réellement décaissé par bailleur et par
demande de décaissement à une date donnée.
I.3.3 Les dimensions participantes du modèle
Les dimensions participant au modèle de l’activité mobilisation sont : la dimension « temps », la
dimension « convention », la dimension « projet », la dimension « bailleur », la dimension
« type_decaissement » et la dimension « type_bailleur ».
Page 60
I.3.4 Le modèle en flocon de l’activité «mobilisation »
Dimension _Temps.
-------
PK_CODE_TEMPSDATESEMAINEMOISSEMESTRETRIMESTREANNEE
DIM BAILLEUR.-----
PK_CODE_BAILLEURNOM_BAILLEURSIGLE_BAILLEURCODE_TYPE_BAILLEURADRESSE_BAILLEUR
DIM PROJET---
PK_CODE_PROJETLIBELLE_PROJETMONTANT_PROJET
DIM CONVENTION-----
PK_CODE_CONVENTIONLIBELLE_CONVENTIONDATE_SIGNATUREMONTANT_CONVENTIONCODE_MODE_FIN
Fait mobilisation-----
PK_CODE_BAILLEURPK_CODE_PROJETPK_CODE_TEMPSPK_CODE_CONVENTIONPK_CCODE_TYPE_DEC
++
MontantInitial ()MontantFinal ()
: Number: Number
DIM TYPE_BAILLEUR--
PK_CODE_TYPE_BAILLEUNOM_TYPE_BAILLEUR
DIM TYPE DECAISSEMENT
--
PK_CODE_TYPE_DECLIB_TYPE_DEC
DIM MODE_FINANCEMENT
--
PK_CODE_MODE_FInLIB_MODE_FIN
: :
Figure 32 : Modèle en étoile de l’activité « mobilisation»
I.4 Exécution
I.4.1 Présentation du sujet
Le volet exécution des financements extérieurs comprend deux (2) sous volet qui sont intrinsèquement
liés. Il s’agit du sous volet dépenses effectués et du sous volet paiement dépenses effectuées. En effet le
paiement d’une dépense effectué sur financement extérieur doit subir d’abord une validation a posteriori
par le bailleur afin qu’il puisse être comptabilisé parmi les dépenses effectives. Des cas de rejet peuvent
intervenir en cas d’inéligibilité d’une dépense. Les indicateurs à ce niveau sont essentiellement le taux
d’exécution des dépenses par projet, le taux de rejet des paiements par projet, le taux global d’exécution
des dépenses sur financements extérieurs et le taux de comptabilisation des financements extérieurs. Il
est indispensable de suivre ces indicateurs pour maintenir la confiance des partenaires techniques et
pour mieux cerner les investissements en termes de développement.
Page 61
I.4.2 Grain du sujet
Au titre de l’exécution, le grain le plus fin, ou le niveau de détail le plus bas, correspond à une dépenses
par bailleur à une date donnée ainsi qu’à un paiement d’une dépense effective par type de paiement et à
un moment donné, d’où une ligne de ces deux tables de fait correspondant à :
Suivi des dépenses effectives et des paiements y afférents par bailleur et par type de paiement à une date
donnée.
I.4.3 Les dimensions participantes du modèle
Les dimensions participantes à ce modèle sont : la dimension « temps », la dimension « projet », la
dimension « bailleur », la dimension « type_paiement »
Dimension _Temps..-------
PK_CODE_TEMPSDATESEMAINEMOISSEMESTRETRIMESTREANNEE
: : : : : : :
DIM BAILLEUR...-----
PK_CODE_BAILLEURNOM_BAILLEURSIGLE_BAILLEURCODE_TYPE_BAILLEURADRESSE_BAILLEUR
DIM PROJET.---
PK_CODE_PROJETLIBELLE_PROJETMONTANT_PROJET
Fait depense--
PK_CODE_PROJETPK_CODE_TEMPS
+++
MontantPrevu ()MontantExecute ()TauxExecution ()
: Num: Num: Num
Fait paiement----
PK_CODE_PROJETPK_CODE_TEMPSPK_CODE_BAILLEURPK_CODE_TYPE_PMT
+++
Montantdepense ()Montantpaiement ()Tauxpaiement ()
: Num: Num: Num
DIM TYPE_PAIEMENT--
PK_CODE_TYPE_PMTLIB_TYPE_PMT
Figure 33 : Modèle en constellation de l’activité « exécution»
Page 62
Conclusion
La zone d’entreposage constitue la zone exploitable par les utilisateurs. La modélisation de cette zone se
fait grâce à la modélisation dimensionnelle. Cette manière de représenter les données offre aux
utilisateurs des modèles intuitifs et compréhensibles permettant de naviguer et de manipuler les
données, détaillées ou agrégées, sans difficulté afin de satisfaire leurs besoins en analyse.
La finalisation de la conception de l’entrepôt, nous permet de passer à la construction de la zone
d’alimentation qui constitue l’objet du prochain chapitre.
Page 63
PARTIE III: MISE EN
OEUVRE DE LA SOLUTION
Page 64
I Introduction
L’ETL, ou l’alimentation du Data Warehouse, est une étape des plus importantes dans un projet Data
Warehouse, elle représente 80% de la charge de travail. Cette étape a pour objectif d’assurer
l’acheminement des données des systèmes sources jusqu’à l’entrepôt de données, en passant par les différentes phases de nettoyage et de transformations nécessaires.
La conception du processus d’alimentation nécessite les étapes suivantes :
• Etude et planification ;
• Choix de l’architecture ;
• Conception des processus de chargement :
- Processus de chargement des tables de dimension ;
- Processus de chargement des tables de faits ;
- Processus de chargement de table temps.
Page 65
I.1 Etude et Planification
Cette phase représente une phase préliminaire à l’ensemble du processus. Elle consiste en :
• l’étude des sources de données :
- la source de données est constituée des six modules du CIFE
• la détection des emplacements des données source :
- cette tache est en partie réalisée par les DBA
• la définition de la périodicité du chargement.
- A ce niveau nous avons retenu la périodicité mensuelle pour ce qui concerne
l’inscription des projets et programmes et l’élaboration du budget compte tenu du fait
que ces deux activités ne sont pas fréquemment réalisées.
- Pour les autres activités la périodicité journalière a été retenue compte tenu de la
fréquence élevée de celle-ci.
I.2 Architecture de chargement
L’architecture globale de chargement du système futur se présente de la sorte :
BD Production
Collecte
Taging Area
Extraction.
DW
Collecte.
Extraction.
AlimentationSERVER ETL
La zone « Taging Area » permet de stocker les donner à transformer et collectées depuis les bases de
productions. Elle permet de résoudre les problèmes d’indisponibilité des systèmes opérationnels qui
sont permanemment en utilisation.
Page 66
I.3 Processus général de chargement
Le diagramme d’activités suivant décrit le processus général de l’alimentation de l’entrepôt de données
dés sa mise en service :
Figure 34 : diagramme de l’activité du processus d’alimentation
La stratégie d’extraction adoptée consiste à comparer des chargements successifs afin de détecter les
changements. Cette stratégie, étant la plus fiable, est incontournable pour la capture des changements
pour des raisons de non fiabilité des champs date, généralement non renseignés. Cette détection se fait
au niveau de la zone de préparation améliorant sensiblement les performances.
Page 67
I.4.1 Processus de chargement initial
Comme son nom l’indique, ce type de chargement permet de prendre en compte le premier chargement
de l’entrepôt. Toutes les dimensions sont préalablement vidées pour s’assurer qu’il n’y a pas des
données préexistantes. Excepté la dimension « temps », le chargement initial de tous les autres
dimensions est précédé d’une purge pour s’assuré qu’il n’y a pas de données en attente dans ces dits
dimensions.
Le chargement de la dimension temps (DIM_TEMPS) à l’aide du Data Flow Task consiste à
extraire la date de l’activité des travaux de la table par une requête SQL, ensuite des
transformations sont faites afin d’obtenir le jour, la semaine, le mois, le trimestre, l’année et la
date de l’activité, le code de la date du type de travail concerné. Ensuite les données sont
insérées dans la dimension DIM_TEMPS de l’entrepôt.
Le code de la dimension est obtenu par concaténation du jour, du mois et de l’année de la
l’activité.
I.3 Architecture technique de la solution
La figure suivante illustre la structure et l’architecture technique de la solution
Figure 35 : Architecture technique de la solution
Page 68
I.4 Choix de l’ETL
L’ETL est l’outil permettant l’extraction, la transformation et le chargement des données. Ils sont indépendants des systèmes de gestion de bases de données. Cependant certains systèmes de gestions de base de données intègrent déjà cet outil notamment OWB dans le cas d’oracle, SSIS dans le cas de SQL SERVER…
Pour la mise en œuvre de notre solution la solution ETL retenu est SSIS pour la simple raison que l’entrepôt sera construit à l’aide de SQL SERVER.
Les différents outils qui seront utilisés sont :
outil d’extraction : Integration Services 2008 de SQL Server Business Intelligence
Development Studio ;
outil d’analyse : Analysis Services 2008 de SQL Server Business Intelligence
Development Studio ;
outil de reporting : report Server 2008.
I.4.1 Implémentation de l’extraction, de la transformation et du chargement
L’extraction des données qui se fait depuis une base de données oracle 10g se fait à l’aide
d’une connexion SQL Server par le Gestionnaire de connexions et utilisant le fournisseur
« OracleClient Data Provider » comme l’indique la figure ci-dessous.
Figure 36 : Gestionnaire de connexions à oracle depuis SQL Server
Les deux types de chargement (initial et incrémentiel) se font de façon séparée à l’aide des
pacquages offerts par SQL Server
Page 69
a. Mise en œuvre de l’extraction, de la transformation et du chargement initial
Pour s’assurer de la cohérence des données chargées, le chargement initial est précédé d’une
purge des dimensions ainsi que des faits de l’entrepôt de données. Elle est effectuée à travers
les flux de données.
Figure 37 : Enchainement des taches du chargement initial
Il s’avère nécessaire d’effectuer les conversions convenables avant les éventuels chargements
étant données la différence technologique des deux systèmes de gestion de base de données
utilisé. Ainsi, pour le chargement de la dimension bailleur convention par exemple une
conversion de types suivants est effectuée :
CHAMPS TYPES DEPART TYPES D’ARRIVEES CODE_CONVENTION VARCHAR2 CHAINE [DT_SDR] LIBELLE_CONVENTION VARCHAR2 CHAINE [DT_SDR] MONTANT_CONVENTION NUMBER(18,0) NUMERIQUE [DT_NUMERIC] TYPE_FINANCEMENT NUMBER ENTIER_SIGNE (4 BITS)[DT_I4]
Figure 38 : Exemple de conversion de type de données.
Page 70
La figure ci-dessous illustre le lancement du chargement initial d’une convention.
Figure 39 : Figure illustratif du chargement de la dimension convention.
I.4.2 Conception des cubes
La conception des cubes se fait à l’aide de l’outil Analysis Services 2008 de SQL Server.
Après la création de sources de données liée à l’entrepôt de données, la génération du cube se
fait de façon automatique. Pour le fait « Mobilisation » , on obtient le cube suivant :
Figure 40 : Cube du fait mobilisation.
Connexion à la base oracle et extraction des conventions
Conversion des types d’oracle en type SQL Server
Connexion à la base SQL Server et Insertion
Page 71
Le cube « Fait_Mobilisation » peut être analysé dans l’outil Analysis Services 2008 de SQL
suivant des critères de choix. Le schéma ci-dessous montre une analyse des montants initiaux et
finaux des décaissements du fait « mobilisation » par projet et par bailleur.
Figure 41 : Exemple d’analyse du cube de fait mobilisation.
I.4.3 Architecture technique de déploiement
L’architecture de déploiement demeura la même que celle abritant les applications métiers des
finances publiques (Architecture Trois tier). Elle est constituée d’un serveur d’application sous
windows 2008 Server et un server de base de données oracle sous Linux Redhat et un server de
base de données SQL SERVER 2008.
Figure 42 : Architecture de deploiement.
Base Linux
Base Windows
Poste Client
Server d’application windows
Page 72
I.4.4 Coût de mise en œuvre
Le coût de mise en œuvre de la solution est fonction du scenario de réalisation. Pour une réalisation en
interne, ce sont les informaticiens de l’administration qui formeront le groupe de projet contrairement
à l’option « développement en externe » où le besoin de recruter des consultants se pose. Les tableaux
suivants présentent les différents coûts :
a) Développement en interne
Le développement en interne a un coût relativement nul car les informaticiens qui travailleront sur
l’application sont de l’administration.
Ressources Qté Coût unitaire Nbre Mois Coût total
Développeur 03 0 5 0
Total 0 Tableau 11 : Tableau récapitulatif du coût de mise en œuvre en interne
b) Développement en externe
Ressources Qté Coût unitaire Nbre Mois Coût total
Chef de projet 01 1 700 000 4 6 800 000
Développeur 03 650 000 4 2 600 000
Autres - 2 000 000 - 2 000 000
Total 11 400 000 Tableau 12 : Tableau récapitulatif du coût de mise en œuvre en externe
Page 73
Conclusion
Les cubes dimensionnels est une étape très importante dans tout projet Data Warehouse. C’est grâce à cette dernière que l’utilisateur pourra utiliser et exploiter au mieux les données contenues dans l’entrepôt de données de manière correcte et intuitive.
Dans ce chapitre nous avons essayé donc de définir les cubes dimensionnels en explicitant les dimensions participantes dans chacun d’entre eux. Ensuite nous avons défini, pour chacune des dimensions, les différentes hiérarchies présentes ainsi que les niveaux qui composent ces dernières.
Page 74
CONCLUSION GENERALE
Au terme de ce stage au cours duquel il nous a été demandé la mise en place d’un entrepôt de
données sur les financements extérieurs au Burkina Faso, les bénéfices qui s’en dégagent sont
manifestes. D’abord, sur le plan professionnel, des acquis considérables ont été engrangés. De
plus, outre l’approfondissement de nos connaissances sur la mise en place des systèmes
décisionnels, nous avons touché des doigts les réalités en termes de difficultés de maitrise par
les autorités des flux financiers extérieurs dans le processus du développement national.
En effet, par la modélisation dimensionnelle, l’analyse des besoins nous a mené à concevoir un
scénario présentant un système sous SQL SERVER 2008, en réseaux, ergonomique, simple
mais efficace et qui permettra aux décideurs d’avoir une idée plus claire des flux financiers
extérieurs et de leur utilisation.
En sommes, nous aimerions que le travail que nous avons entrepris au sein de la DGSI,
connaisse son achèvement pour permettre de voir nos efforts couronnés par la mise en place
complète du système informatique décisionnel sur les financements extérieurs.
Page 75
Bibliographie
Ouvrages
1. [Goglin, 1998] : J.F. Goglin; « La Construction du Datawarehouse : du Datamart
au Dataweb »; Hermes 1998.
2. [Inmon, 2002]: W. H. Inmon ; « Building the Data Warehouse Third Edition» ;
Wiley Computer Publishing 2002.
3. [Kimball, 2004] : R. Kimball et J. Caserta ; « The Data warehouse ETL Toolkit» ;
Wiley Publisshing, INC 2004
4. [Kimball, 2002] : R. Kimball et M. Ross ; « Entrepôts de Données : Guide Pratique
de Modélisation Dimensionnelle 2ème édition » ; Vuibert 2002.
5. [Nakache, 1998] : Didier Nakache; « Data Warehouse et Data Mining »;
Conservatoire National des Arts et Métiers de Lille; Version 1.1; 15 juin 1998.
Articles
6. [FILALI ABDERRAHMANE,KEDJNANE SOFIANE, 2009/2010] : Conception
et réalisation d’un Data Warehouse pour la mise en place d’un système
décisionnel, lu le 10/03/2014
7. [Florian FRANCHETEAU, 2007/2008] : Étude des ETL Open Source, lu le
20/04/2014
8. [O. Boussaid, 2013-2014] : Le processus d'ETL, lu le 14/05/2014
Webographie
9. https://denglishbi.wordpress.com/tag/ssis/, consulté le 03/03/2014
10. http://support.microsoft.com/kb/943655/fr, consulté le 05/04/2014
11. http://denglishbi.wordpress.com/2009/03/29/ssis-2008-ado-net-source-issue-with- ssas-data-source-error-code-0x80004002/, consulté le 10/06/2014
12. www.labo-microsoft.org.htm, consulté le 12/06/2014
Recommended