Professional Documents
Culture Documents
Mise en place
Dun datamart
Ressources Humaines
I N G E N I E RI E I N FO R MAT I Q UE E T RESEAUX
Ralis par :
Bouhouch Youssef
Kouraimiten Abdelaziz
2
Ddicaces
A nos parents, nos familles respectives, nos ami(e)s, a tous les professeurs et personnel de lemsi qui nous
ont accompagns tout au long de nos etudes, veuillez trouver ici, le temoignage de nos sentiments
respectueux et lexpression de notre sincere reconnaissance.
Que ce travail vous apporte lestime et le respect que nous portons a votre egard, et soit la preuve du desir
que nous avons pour vous honorer.
3
Remerciements
Avant dentamer ce rapport, nous tenons tmoigner notre profonde gratitude toutes les personnes qui
ont particip de loin ou de prs llaboration de ce travail.
Labsence dune rfrence explicite chacun dentre eux ne serait, en aucun cas, tre interprte comme
un manque de reconnaissance.
Monsieur A.RIAD ELIDRISSI pour son encadrement constant et ses nombreux conseils, et surtout
pour sa disponibilit durant les sances dencadrement lEMSI, je le remercie encore pour ses
remarques pertinentes, mais aussi pour son coute et son discours bienveillants.
Les membres du jury qui ont accept de juger notre travail ainsi que tout le corps professoral et
administratif de lEMSI.
4
Rsum
Dans le cadre du projet de fin dtude, nous avons ralis un projet dcisionnel.
Le besoin consiste collecter et extraire les donnes brutes du client, partir de la base de
donnes de production et des fichiers plats, les transformer en information et les diffuser sous
forme de tableaux de bord et Reporting aux utilisateurs dcideurs de lentreprise.
Dans la partie conception, nous avons labor un DataMart pour lactivit de gestion des
ressources humaines, en se basant sur la matrice axe danalyse/indicateurs.
Lobjectif est de mettre la disposition du client un outil simple de gnration des tats
selon diffrents critres, avec possibilit dexport vers diffrents formats, chose que nous
avons assur durant la phase de dveloppement du projet.
Ce projet nous a permis de mettre en pratique les diffrentes mthodes pour la bonne conduite
dun projet BI.
5
Table des matires
.
Introduction Gnrale...9
Partie I: Management du projet ..11
Chapitre 1: Cycle de vie...13
Chapitre 2: Gestion de projet.27
Chapitre 3: Gestion des risques34
6
LISTE DES FIGURES
.
7
LISTE DES TABLEAUX
.
Tableau 1. 1: Avantages et inconvnients de lapproche guide par les donnes sources (Approche
Top-Down) ................................................................................................................................. 15
Tableau 1. 2: Avantages et inconvnients de lapproche guide par les besoins danalyse (Approche
Bottom-Up) ............................................................................................................................... 18
Tableau 1. 3: Avantages et inconvnients de lapproche mixte (Approche hybride ou Approche
Middle-Out)............................................................................................................................... 20
Tableau 1. 4: Description de la phase Planification du projet ........................................................ 22
Tableau 1. 5: Description de la phase de Dfinition des besoins ..................................................... 23
Tableau 1. 6: Description de la phase de Modlisation dimensionnelle ........................................... 23
Tableau 1. 7: Description de la phase de Conception du modle physique ...................................... 24
Tableau 1. 8: Description de la phase Dfinition de larchitecture technique .................................. 24
Tableau 1. 9: Description de la phase Conception et dveloppement de la zone de prparation des
donnes ...................................................................................................................................... 25
Tableau 1. 10: Description de la phase de Choix technologiques et mis en uvre ............................ 25
Tableau 1. 11: Description de la phase de Dploiement................................................................. 26
Tableau 1. 12: Description de la phase de Maintenance et croissance............................................ 26
8
Introduction
.
T outes les entreprises du monde disposent dune masse de donnes plus ou moins
considrable. Ces informations proviennent soit de sources internes (gnres par leurs
systmes oprationnels au fil des activits journalires), ou bien de sources externes (web,
partenaire, .. etc.).
En effet, les dcideurs de lentreprise ont besoin davoir une meilleure vision de leur
environnement et de son volution, ainsi, que des informations auxquelles ils peuvent se fier.
Cela ne peut se faire quen mettant en place des indicateurs business clairs et pertinents
permettant la sauvegarde, lutilisation de la mmoire de lentreprise et offrant ses dcideurs
la possibilit de se reporter ces indicateurs pour une bonne prise de dcision.
Dfinition
Linformatique dcisionnelle (ou BI pour Business Intelligence) dsigne les moyens, les outils
et les mthodes qui permettent de collecter, consolider, modliser et restituer les donnes,
matrielles ou immatrielles, d'une entreprise en vue d'offrir une aide la dcision et de
permettre aux responsables de la stratgie d'entreprise davoir une vue densemble de
lactivit traite.
Voici la dfinition que lon retrouve gnralement lorsque lon parle dinformatique
dcisionnelle. Une entreprise est gnralement compose de plusieurs services tels que les
ressources humaines, les services comptabilit, marketing, commercial, technique Tous
conservent des informations propres leurs fonctions : listes des clients, des employs,
chiffres, emplois du temps
Laccumulation de ces donnes ncessite donc leur sauvegarde dans le but dune future
exploitation. On constate ainsi rgulirement que chaque service possde son tableau de
bord, ce qui lui permet de mesurer les indicateurs de performance de lentreprise (chiffre
daffaires, calculs de bnfices lanne). Cependant, chaque service a bien souvent sa faon
de stocker ses informations (par exemple dans un fichier Excel, une base de donnes
relationnelle), et sa manire de calculer les indicateurs, avec sa vrit et ses critres.
Ainsi, si lon veut considrer les donnes de lentreprise dans son ensemble, la tche savre
rude voire parfois impossible. Pourtant, cela constituerait une utilit vidente et un rel apport
la socit. En effet, une mise en relation et une analyse de toutes les donnes permettraient
de raliser des tudes et des prvisions sur le comportement et la sant de lentreprise.
9
Figure 1. 1:
Illustration de
la Solution BI
Le but de la BI est dapporter une vision globale des donnes de lentreprise, afin de rpondre
aux problmatiques de celle-ci ou, tout simplement, afin de lvaluer.
Pour y arriver, SQL Server 2012 met donc disposition trois plateformes qui illustrent ce
cheminement (cf. figure 1.1).
10
Partie I
Management du projet
11
Cette partie
Dcrit la dmarche suivie pour assurer la bonne conduite du
projet. Nous allons entamer dabord le cycle de vie de projet
ensuite la gestion du projet et la procdure adopte pour grer les
risques.
12
Chapitre 1
Cycle de vie
.
Dfinition
Il existe plusieurs approches dimplantation des systmes dinformation transactionnels
savoir :
Cependant les experts saccordent sur le fait que ces approches ne rpondent pas
parfaitement aux besoins dimplantation des systmes dcisionnel, ils ont alors dfinit dautres
approches telles que :
Si vous recherchez la meilleure approche, il n'existe pas de meilleure approche, mais plutt
recherchez l'approche la plus adapte votre contexte.
Oprationnel.
Dpartemental.
Individuel.
13
Les trois derniers niveaux constituent lentrept. Le premier niveau comprend les bases de
donnes de logiciels patrimoniaux et autres systmes de traitement transactionnel. Les
donnes sont transformes entre le premier et le deuxime niveau. Pour transformer les
donnes, un processus appel ETC (pour extraction, transformation et chargement) est utilis.
Il sagit dun ensemble de processus qui extraient les donnes des systmes sources, qui
transforment les donnes et les chargent dans lentrept cible. Avec cette approche, les
donnes des dpartements sont toujours cohrentes, car elles proviennent toutes du mme
entrept.
Figure 1. 2:
Illustration de
Lapproche
Source de
Donnes
14
Figure 1. 3:
Conception dun
ED par un
processus
dintgration
(selon Inmon)
Caractristiques majeures
L'emphase est mise sur le DW.
Commence par concevoir un modle de DW au niveau de l'entreprise.
Dploies une architecture multi tiers compose de staging area, le DW, et les data mart
dpendants.
Le staging area est permanent.
Le DW est orient entreprise; les data marts sont orients processus.
Le DW contient des donnes atomiques; Les data marts contiennent les donnes agrges.
Le DW utilise un modle de donnes normalis de toute l'entreprise; Les data marts utilise des
modles dimensionnels orients sujet.
Les utilisateurs peuvent effectuer des requtes sur le DW et les data marts.
Avantages Inconvnients
Meilleure prise en charge de Risque de concevoir une solution
lvolution des besoins. obsolte avant quelle soit
oprationnelle.
Facile mettre en uvre.
Evolution du schma des
Offre des rsultats rapidement. donnes source
15
Lapproche Bottom-Up de Ralph Kimball
Ralph Kimball prend une approche tout fait diffrente dInmon pour la cration dentrepts.
Premirement, il a dvelopp une technique pour modliser un entrept qui, lpoque, tait
rvolutionnaire: le modle dimensionnel. Au lieu dtre bas sur le modle entits-
association, le modle dimensionnel repose sur des tables reprsentant des faits et des
dimensions. Le modle dimensionnel peut tre reprsent dans la plupart des cas par
un modle entits-association, mais est plus simple comprendre dans sa forme
dimensionnelle.
Les faits sont typiquement des vnements mesurables qui se produisent dans lentreprise. Il
est simple de mesurer la quantit de produit commande, le montant dune facture ou le
nombre de jours de retard dun paiement. Les dimensions sont des descriptions textuelles
dlment de lentreprise. [3] Les dimensions permettent danalyser les faits sous diffrents
angles, par exemple des ventes par client, par produit et par mois.
Deuximement, au lieu de crer un entrept normalis global partir duquel est ensuite
produits des magasins de donnes (data marts), Kimball prfre la cration de magasins
de donnes comme base de larchitecture. Ces magasins, des sous-ensembles de donnes
regroupes gnralement pour rpondre aux besoins spcifiques dun dpartement ou
secteur de la compagnie, sont assembls pour crer un entrept. Cette approche est
possible lorsque les dimensions sont conformes, cest--dire quelles reprsentent
exactement la mme chose dun magasin lautre.
Troisimement, un autre lment de la mthodologie de Kimball qui diffre avec celle dInmon
est quelle est mene par les besoins des clients. Le cycle de vie dun projet utilisant la
mthodologie Kimball dbute comme celui dun projet traditionnel en cascade, soit par
llaboration des besoins du client. Ensuite, Kimball distingue les tches de cration
dentrepts entre trois spcialisations du monde de lintelligence daffaires [3] :
lenvironnement technique.
les donnes.
Les tches des chemins spcialiss peuvent tre excutes en parallle, car elles ne visent pas
les mmes lments de lenvironnement.
Le chemin technique est orient vers le choix et la configuration des outils utiliss pour les
entrepts. Cest aussi dans ce chemin quest dfinie larchitecture technique, donc lensemble
des lments matriels et logiciels formant lenvironnement dun entrept.
Le chemin des donnes est emprunt par les programmeurs qui modlisent les
magasins de donnes et acheminent les donnes des systmes sources vers ces magasins.
Le chemin pour le dveloppement dapplications analytiques est prvu pour les dveloppeurs
de rapports, danalyses et de tableaux de bord typiquement dans des logiciels prvus pour la
consommation de donnes analytiques.
16
Lapproche Bottom-Up de Ralph Kimball est traduite par le cycle de vie dimensionnel dont le
schma est prsent dans la figure suivante :
Figure 1. 4:
Illustration de
lapproche
Besoins
danalyse
Caractristiques majeures
L'emphase est mise sur les data marts.
Commence par concevoir un modle dimensionnel pour le data mart.
Utilise une architecture qui consiste en un staging area et les date marts.
Le staging area est en gnral non permanent, mais il peut devenir permanent pour implanter
l'architecture en BUS (Dimensions et faits conformes)
Les data marts contiennent les donnes atomiques et les donnes agrges.
Les data marts peuvent fournir une vue entreprise ou processus.
Un data mart consiste en une seule star schema physique.
Les data marts sont implants d'une faon incrmentale et intgre en utilisant les dimensions
CONFORMES.
Les utilisateurs ne peuvent effectuer des requtes sur le staging AREA.
17
Tableau 1. 2: Avantages et inconvnients de lapproche guide par les besoins danalyse
(Approche Bottom-Up)
Avantages Inconvnients
Aucun risque de concevoir Pas de prise en compte de
une solution obsolte avant lvolution des besoins de
dtre oprationnelle. lutilisateur. Ncessite une
modification de la structure du
Offrir une architecture Datawarehouse en cas de nouveau
intgre. besoin.
Dans (Romero et Abell, 2010), les auteurs proposent de partir dune part des besoins des
dcideurs exprims sous la forme de requtes SQL et dautre part du schma dune base de
donnes relationnelle. Linterrogation des sources est assure par des requtes SQL et une
connaissance de la smantique du schma relationnel de la source. Les auteurs font
lhypothse que les attributs figurant dans la clause SELECT de chaque requte SQL,
appartiennent une table dans la base de donnes source et quils correspondent au fait
analys. Lensemble des schmas produits peut tre affin par lutilisateur. Bien quil soit
important de pouvoir faire valider les schmas multidimensionnels par lutilisateur, cette
dmarche reste toujours dpendante dun expert (un informaticien) pour formuler les
requtes SQL en entre du systme.
Les auteurs de (Zepeda et al., 2008) proposent une dmarche MDA (Model Driven Approach)
en partant du modle conceptuel source et des besoins sources suivant trois tapes. La
premire tape consiste transformer le schma Entit/Association de la source en un
schma multidimensionnel grce des mtargles. La deuxime tape collecte les besoins des
dcideurs en les formalisant avec un modle de but. La troisime tape consiste confronter
les rsultats des deux tapes prcdentes pour fournir un schma multidimensionnel ;
18
lutilisateur peut alors affiner le schma rsultant. Ces travaux se limitent au niveau conceptuel
et ne proposent pas doutil logiciel pour valider la dmarche propose.
Plusieurs travaux utilisent lapproche MDA (Model Driven Approach) pour formaliser les
schmas multidimensionnels ainsi que les processus de transformation de schmas, ceci du
niveau conceptuel au niveau physique.
Dans (Mazn and Trujillo, 2008) et (Mazn and Trujillo, 2009), les auteurs proposent une
mthode base sur MDA (Model Driven Approach) en suivant une dmarche mixte. Les
besoins des dcideurs sont reprsents sous forme dun diagramme de buts au niveau CIM.
Ensuite, ce modle de buts est fusionn avec les modles sources pour obtenir un modle
conceptuel hybride (PIM hybride). Ce dernier est transform en un modle logique (PSM).
Enfin, le modle logique est traduit selon le formalisme spcifique dune plateforme physique.
Dans (Atigui et al., 2012), les auteurs proposent une approche MDA (Model Driven Approach)
pour formaliser les transformations de schmas de lentrept et de son chargement partir
des sources. Cette mthode permet de formaliser le schma multidimensionnel et les
oprations de chargement de manire conjointe. Elle fournit un ensemble de mta-modles et
de rgles de transformation pour gnrer les modles logique et physique dcrivant la fois
les donnes et les oprations.
Figure 1. 5:
Illustration de
lapproche
Mixte
19
Caractristiques majeures
L'emphase est sur le DW et les data marts.
Utilise les deux approches top-down et Bottom-up.
Commence par concevoir un modle de donnes de l'entreprise en mme temps que les
modles spcifiques.
Passe 23 semaines crer un modle normalis d'entreprise de haut niveau.
Gnre les modles des premiers data marts.
Charge les data marts avec les donnes atomiques en utilisant un staging area temporaire.
Les modles des data marts sont composs d'un ou plusieurs star schmas.
Utilise un outil ETL pour charger les data marts et pour changer le mtadata avec ces
derniers.
Charge le DW partir des data marts lorsqu'il y'a besoin de faire des requtes travers
plusieurs data marts en mme temps.
Avantages Inconvnients
20
Les phases du cycle de vie du projet sont les suivantes :
2. Gestion du projet : La gestion du projet garantit que les activits du cycle de vie restent sur
la bonne voie et sont bien synchronises. Cela consiste contrler ltat davancement du
projet, la dtection et la rsolution des problmes et le contrle des changements afin de
garantir laccs aux objectifs du projet.
3. Dfinition des besoins : Il est essentiel de bien comprendre les utilisateurs et leurs besoins,
sinon lentrept deviendra rapidement un exercice vain de la part de lquipe des
concepteurs Lapproche utilise pour identifier les besoins analytiques diffre de
manire significative de la traditionnelle analyse des besoins base sur les donnes. Les
besoins une fois dfinis constituent le point de dpart de trois trajectoires parallles que
sont la technologie, les donnes et les interfaces utilisateurs.
4. Modlisation dimensionnelle : Cest la dfinition des besoins qui dtermine quelles sont les
donnes requises pour rpondre aux besoins danalyse des utilisateurs. La conception du
modle logique de donnes commence par la construction dune matrice reprsentant les
processus mtier cl et leurs dimensionnalits. A partir de cette matrice, il faut effectuer
une analyse plus dtaille des donnes du (des) systme(s) source(s) oprationnels. Le
rsultat de cette analyse est le modle dimensionnel. Ce modle identifie la granularit de
la table de fait, les dimensions associes avec leurs attributs et leurs hirarchisations. Cet
ensemble dactivits sachvera sur le dveloppement dune mise en correspondance des
donnes sources et cibles dans des mta-donnes.
21
accs ad hoc lentrept. Les spcifications de lapplication dcrivent les maquettes
dtats, les critres de slection laisss lutilisateur et les calculs ncessaires.
11. Maintenance et croissance : Aprs le dploiement initial de lentrept, cest sa vie qui
commence. Il faut sassurer de fournir un service de support et de formation continue. Il
faut galement sassurer que les processus mis en place pour la gestion de la zone de
construction vont faire fonctionner lentrept en continu et efficacement. Il est galement
important de mesurer priodiquement les performances de lentrept et de son
acceptation dans lentreprise. Lentrept va donc voluer et crotre et le changement doit
tre peru comme un facteur de succs et non dchec. Des processus de hirarchisation
des priorits doivent bien sr tre mis en place afin de grer les demandes des utilisateurs
en termes dvolution et de croissance.
Objectifs
Comprendre dune manire globale le projet
Planifier le projet
Prrequis
Etape de la phase Planning
22
Phase de Dfinition des besoins
Prrequis
Etape de la phase Analyse
Dpendance N/A
23
Phase de Conception du modle physique
Prrequis
Architecture Applicative
Etape de la phase
Dossier darchitecture Applicative
Livrables en sortie
Phase de Planification et analyse des besoins
Dpendance
Critres de fin de phase :
Mettre en place un systme qui constitue la base de donnes dcisionnelle pour
son activit service et logiciel rpondant aux besoins de production dindicateurs
et tats statiques.
24
Phase de Conception et dveloppement de la zone de
prparation des donnes
Concept faits.
Prrequis
Concept dimensions.
Objectifs
Dgager les diffrents indicateurs
Prrequis
Etape de la phase
dossier de spcifications fonctionnelles
Livrables en sortie Liste des indicateurs et des dimensions (Axes
danalyse)
Dpendance
25
Phase de Dploiement
Objectifs
Assistance linstallation de lenvironnement de production
Prrequis
Etape de la phase dploiement
Livrables en sortie
Dpendance Recette
Objectifs
Prrequis
Maintenance et croissance
Etape de la phase
Livrables en sortie
Dploiement et Formation
Dpendance
Critres de fin de phase :
Systme bien appliqu
26
Chapitre 2
Gestion de projet
.
Planifier optimise ainsi les chances de russite d'un projet en amliorant la productivit
grce une meilleure matrise de la qualit.
[Soler, 2001].
L initiation de tout projet de dfinir les tches raliser, matriser les risques et rendre compte
de ltat davancement du projet.
Equipe du projet
La russite dun projet pass par une organisation rigoureuse et efficace de lquipe de projet.
27
Flux de communication
Le principal moyen de communication pour le projet se manifestait dans des runions
hebdomadaires et/ou vnementielles (jalons, livrables), mais, nous faisions aussi
recours des runions, suite aux vnements inattendus ; tous les membres de
lquipe taient tenus tre prsents.
Le diagramme suivant prsente les flux qui sont en relation avec ce projet et leurs
caractristiques.
Figure 1. 6:
Illustration de la
Flux de
communication
28
Gestion des dlais
Gestion du projet
Mar 02/02/16 Mer 03/02/16
2 jours
Modlisation dimensionnelle
Mer 10/02/16 Ven 19/02/16
8 jours
29
Conception et dveloppement de la zone de Jeu 10/03/16 Mer 23/03/16
prparation des donnes 10 jours
Etude des indicateurs et des dimensions (axes Jeu 10/03/16 Mer 16/03/16
d'analyse)
5 jours
Etude des flux ETL (Extraction, Transformation Jeu 24/03/16 Mer 30/03/16
et Chargement) 5 jours
Test unitaire ETL Jeu 31/03/16 Lun 04/04/16
3 jours
Validation Lun 04/04/16 Lun 04/04/16
0 jour
Dploiement
Lun 18/04/16 Ven 22/04/16
5 jours
Maintenance et croissance
Lun 25/04/16 Ven 29/04/16
5 jours
30
Planning prvisionnel
31
Planning rel
32
Analyse des carts
8 10 2
Modlisation dimensionnelle
8 10 2
Dfinition de larchitecture technique
67 73 5
Total
33
Chapitre 3
Dfinition
Matriser les risques est une proccupation majeure dans la conduite de projet informatique.
Les risques sont dfinis comme tant la possibilit qu'un projet ne s'excute pas conformment
aux prvisions de dates, de cot ou d'expression des besoins, ces drives tant considres
comme difficilement acceptables, voire mme inacceptables.
Pour remdier contre les risques, plusieurs activits sont mettre en uvre et ce, de manire
itrative pendant toute la dure du projet : l'analyse des risques du projet, la rduction des
risques et leur suivi. Les rsultats de ces activits doivent tre capitaliss au sein de l'organisme
afin de faire profiter les futurs projets de l'exprience acquise.
Figure 1. 7:
Illustration de la
Capitalisation des
risques au sein de
lorganisme
34
Exercer la matrise des risques dans un projet permet au chef de projet de mieux
communiquer sur les difficults potentielles du projet et de partager ses responsabilits avec les
autres dcideurs concerns.
En effet, les diffrents acteurs concerns par le projet (aux niveaux stratgique, fonctionnel ou
technique, matrise d'ouvrage ou matrise d'uvre) doivent tre impliqus dans le suivi des
risques. Cette participation, tout en les engageant davantage dans l'atteinte des objectifs du
projet, leur permet de mieux apprhender les risques du projet, de mieux les surveiller tout au
long des phases et d'en rduire les effets.
Le projet est globalement mieux matris car son pilotage est ajust au fur et mesure des
volutions de son environnement. La visibilit sous-jacente la matrise des risques permet une
prise de dcision efficace, tout en se focalisant sur les aspects les plus sensibles du projet.
35
Impact *Probabilit Classement
36
Conclusion
Cette tape garantie que toutes les activits restent sur la bonne voie et sont bien
synchronises. Les activits de gestion du projet dcisionnel sont tales tout au long du cycle
de vie prsent, elles concernent le contrle de ltat davancement du projet, la dtection et
la rsolution des problmes et le contrle des changements, afin de rester dans la limite des
objectifs et du primtre.
37
Partie II
Architecture matrielle
et logiciel
38
Chapitre 4
Architecture matrielle
.
Une architecture matrielle montre comment il est possible chaque entreprise de mettre en
uvre les rgles et les solutions proposes en fonction des moyens infrastructures dont elle
dispose, il rassemble tous les lments suivants :
Schma physique
39
Descriptif de larchitecture
Tableau 2. 5: Description de larchitecture physique
Equipement Description
40
Chapitre 5
Architecture logiciel
.
Prsentation globale
Figure 1. 9:
Architecture
applicative
41
Fichier XML : La norme XML (eXtensible Markup Language) dcrit simplement
comment construire un fichier texte permettant de stocker des informations en
respectant une structure donne. On parle alors de document XML.
Fichier plat : Une base de donnes oriente texte est un modle de base de
donnes sous la forme d'un simple fichier. Un fichier plat est un fichier texte ou
du texte combin avec un fichier binaire contenant gnralement un seul
enregistrement par ligne.
Fichier XLS : Les fichiers avec une extension de fichier XLS sont ceux qui sont
associs avec un logiciel de cration de tableur comme Microsoft Excel. Avec les
versions plus rcentes de Microsoft Excel, vous pouvez voir lextension de fichier
rpertorie comme .XLSX.
SQL Server Integration Services (SSIS), qui permet dintgrer des donnes
provenant de diffrentes sources pour les ranger dans un entrept central
(datawarehouse).
SQL Server Analysis Services (SSAS), qui permet danalyser les donnes, agrges
lors de SSIS, grce des fonctions danalyse multidimensionnelle.
SQL Server Reporting Services(SSRS), qui permet de crer, grer et publier des
rapports rsultant des analyses ralises lors de SSAS.
42
Lextraction des donnes
Lextraction est la premire tape du processus dapport de donnes magasin de
donnes. Extraire, cela veut dire lire et interprter les donnes sources et les copier
dans la zone de prparation en vue de manipulations ultrieures. [Kimball, 2005].
Elle consiste en :
Cibler les donnes,
Appliquer les filtres ncessaires,
Dfinir la frquence de chargement,
Lors du chargement des donnes, il faut extraire les nouvelles donnes ainsi que les
Changements intervenus sur ces donnes.
La transformation des donnes
La transformation est la seconde phase du processus. Cette tape, qui du reste est
trs importante, assure en ralit plusieurs tches qui garantissent la fiabilit des
donnes et leurs qualits. Ces tches sont :
Consolidation des donnes.
Correction des donnes et limination de toute ambigut.
Elimination des donnes redondantes.
Complter et renseigner les valeurs manquantes.
Cette opration se solde par la production dinformations dignes dintrt pour
lentreprise et de et sont donc prtes tre entreposes.
Le chargement des donnes
Cest la dernire phase de lalimentation dun magasin de donnes, le chargement est
une tape indispensable. Elle reste toute fois trs dlicate et exige une certaine
connaissance des structures du systme de gestion de la base de donnes (tables et
index) afin doptimiser au mieux le processus.
Politiques de lalimentation
Le processus de lalimentation peut se faire de diffrentes manires. Le choix de la
politique de chargement dpend des sources : disponibilit et accessibilit.
Ces politiques sont [4] :
Push : dans cette mthode, la logique de chargement est dans le systme
de production. Il " pousse " les donnes vers la zone de prparation quand il
en a l'occasion. L'inconvnient est que si le systme est occup, il ne
poussera jamais les donnes.
Pull : contrairement de la mthode prcdente, le Pull " tire " les donnes
de la source vers la zone de prparation. L'inconvnient de cette mthode
est qu'elle peut surcharger le systme s'il est en cours d'utilisation.
Push-pull : c'est la combinaison des deux mthodes. La source prpare les
donnes envoyer et indique la zone de prparation qu'elle est prte. La
zone de prparation va alors rcuprer les donnes.
43
Aussi, le processus dalimentation doit rpondre certaines exigences illustres par la
figure suivante :
tre correctif
Figure 1. 11: tre rapide ETL tre sr
Objectif de
qualit de
tre transparent
donnes dans
un processus
ETL [Kimball,
2004].
44
Data Mining :
Au sens littral du terme, le Data Mining signifie le forage de donnes. Le but de ce
forage est dextraire de la matire brute qui, dans notre cas, reprsente de nouvelles
connaissances. Lide de dpart veut quil existe dans toute entreprise des
connaissances utiles, caches sous des gisements de donnes. Le Data Mining permet
donc, grce un certain nombre de techniques, de dcouvrir ces connaissances en
faisant apparatre des corrlations entre ces donnes.
Le Data Mart constituera alors la premire source de donnes sur laquelle
sexcutera le processus de dcouverte de connaissances. Dans la majeure partie du
temps, Le magasin de donnes reprsente un pr requis indispensable toute fouille
de donnes.
Le recours ce genre de mthode est de plus en plus utilis dans les entreprises
modernes. Les applications et outils implmentant ces solutions sont rarement
dvelopps en interne. En effet, les entreprises prfrent se reposer sur des valeurs
sres du march afin dexploiter au plus vite les donnes en leur possession.
Systme de Reporting
Cest la dernire tape dun projet dcisionnel, soit son exploitation. Lexploitation du
Data Mart se fait par le biais dun ensemble doutils analytiques dvelopps autour du
Data Mart. Donc cette tape ncessite lachvement du dveloppement, ou de la
mise en place, de ces outils qui peuvent accomplir les fonctions suivantes:
Requtage ad-hoc :
Le requtage ad-hoc reste trs frquent dans ce type de projet. En effet, les
utilisateurs de lentrept de donnes, et spcialement les analystes, seront amens
interagir avec le DM via des requtes ad-hoc dans le but de faire les analyses requises
par leurs mtiers et, dlaborer aussi, des rapports et des tableaux de bords
spcifiques.
Laccs ce genre de service peut se faire via diffrentes mthodes et outils.
Cependant, les spcialistes en la matire prconisent de laisser la possibilit
lutilisateur de choisir les outils qui lui paraissent les plus adquats.
Reporting :
Destin essentiellement la production de rapports et de tableaux de bord, il est la
prsentation priodique de rapports sur les activits et rsultats d'une organisation,
d'une unit de travail ou du responsable d'une fonction, destine en informer ceux
chargs de les superviser en interne ou en externe, ou tout simplement concerns
par ces activits ou rsultants 9.
Ces outils de Reporting ne sont pas, proprement parler, des instruments d'aide la
dcision, mais, lorsquils sont utiliss de manire approprie, ils peuvent fournir une
prcieuse vue densemble.
Les rapports sont alors cres par le biais doutils de Reporting qui permettent de leur
donner un format prdtermin. Les requtes sont constitues lors de llaboration
des rapports qui seront ensuite diffuss priodiquement en automatique ou
ponctuellement la demande.
45
Tableaux de bord :
Les tableaux de bord sont un outil de pilotage qui donne une vision sur lvolution
dun processus, afin de permettre aux responsables de mettre en place des actions
correctives.
Le tableau de bord est un ensemble dindicateurs peu nombreux conus pour
permettre aux gestionnaires de prendre connaissance de ltat et de lvolution des
systmes quils pilotent et didentifier les tendances qui les influenceront sur un
horizon cohrent avec la nature de leurs fonctions [Bouquin, 2003].
Cette forme de restitution a la particularit de se limiter lessentiel, c'est--dire la
mise en vidence de ltat dun indicateur par rapport un objectif, tout en adoptant
une reprsentation graphique de linformation.
46
Conclusion
Larchitecture physique et applicative permet de dfinir linfrastructure de dploiement
qui va nous servir de connatre lemplacement de chaque outil ainsi la liaison entre eux.
47
Partie III
Conception du datamart
48
Chapitre 6
Matrice dimensionnelle
.
49
Concept de fait
Une table de faits est la table centrale dun modle dimensionnel, o les mesures de
performances sont stockes. Une ligne dune table de faits correspond une mesure.
Ces mesures sont gnralement des valeurs numriques, additives ; cependant des
mesures textuelles peuvent exister mais sont rares. Le concepteur doit faire son
possible pour faire des mesures textuelles des dimensions, car elles peuvent tres
corrles efficacement avec les autres attributs textuels de dimensions.
Une table de faits assure les liens plusieurs plusieurs entre les dimensions. Elles
comportent des cls trangres, qui ne sont autres que les cls primaires des tables de
dimension.
Concept de dimension
Les tables de dimension sont les tables qui raccompagnent une table de faits, elles
contiennent les descriptions textuelles de lactivit. Une table de dimension est
constitue de nombreuses colonnes qui dcrivent une ligne. Cest grce cette table
que lentrept de donnes est comprhensible et utilisable; elles permettent des
analyses en tranches et en ds.
Une dimension est gnralement constitue : dune cl artificielle, une cl naturelle
et des attributs.
Une table de dimension tablit linterface homme / entrept, elle comporte une cl
primaire [Kimball, 2002].
50
Matrice dindicateurs et axes danalyses
La matrice ci-dessous regroupe tous les besoins fonctionnel du client :
Axe danalyse
Rgle
Indicateur Unit PAY EVALUATION
dagrgation EMPLOYEE MONTH DAY CALENDAR_YEAR
TYPE UNK
Montant $
51
Chapitre 7
52
Le modle en toile de lactivit Salaire
Description Technique
Ce schma en toile contient quatre tables, une table de fait et trois tables de dimension. Une seule des tables de
dimension (DIM_EMPLOYEE) est peuple par ETL. Les deux autres, (DIM_MONTH) est une dimension de la date
et l'autre (DIM_PAY_TYPE) contient des groupements qui ne sont pas disponibles dans le systme source.
Ces dernires sont organises en dimensions reprsentant les axes de recherche suivants :
DIM_EMPLOYEE
DIM_MONTH
DIM_PAY_TYPE
53
Le dtail de cette dimension est le suivant :
Table DIM_EMPLOYEE
DIM_PAY_TYPE
Table DIM_PAY_TYPE
KEY_PAY_TYPE INT
PAY_CATEGORY_1 NVARCHAR(100)
PAY_CATEGORY_2 NVARCHAR(100)
COMPONENT_OF_GROSS_PAY NVARCHAR(100)
Cette table de dimension est en train de changer lentement dimension qui repose un peu en dehors de la table
de PAY_TYPE. Les utilisateurs ont dfini de catgories supplmentaires pour tre utiliss dans leur analyse des
donnes de salaire. Parce que ne devraient pas ces catgories de changer frquemment et depuis le systme
source ne contient pas les catgories dont ils ont besoin d'exister dans le datamart, un travail ETL n'a pas t
crit pour remplir ce tableau. Les donnes suivantes, il a t plac manuellement.
54
Employee Paid Benefit Employee Paid FICA OASDI Yes
Employee Paid Benefit Employee Paid FICA Med Yes
Unknown Unknown Unknown
DIM_MONTH
Ceci est une table date de dimension standard au niveau mensuel.
Table DIM_MONTH
KEY_MONTH INT
CALENDAR_MONTH_NUMBER INT
CALENDAR_MONTH_NAME NVARCHAR(20)
CALENDAR_QUARTER_NUMBER INT
CALENDAR_YEAR INT
FISCAL_MONTH_NUMBER INT
FISCAL_QUARTER_NUMBER INT
FISCAL_YEAR INT
FIRST_DAY DATETIME
LAST_DAY DATETIME
FACT_SALARY
FACT_SALARY
Ceci est une table de fait additif de base qui permet l'utilisateur d'analyser le salaire par mois, type de
rmunration, et l'employ. La valeur SALARY.AMOUNT FACT viendra de la colonne PAYCHECK DETAIL.AMOUNT.
Les trois valeurs cls se rfrent leurs tables de dimensions associes. Parce que les utilisateurs souhaitent voir
le salaire un niveau mensuel bas sur la date de paiement du KEY_MONTH est driv de la colonne PAY
PAYCHECK HEADER.DATE.
Table FACT_SALARY
55
Name Type / (taille)
KEY_EMPLOYEE INT
KEY_MONTH INT
KEY_PAY_TYPE INT
AMOUNT INT
Il y a trois descripteurs de chacun des faits qui ne se rapportent pas directement les uns aux autres. Ils sont
l'lment en cours d'valuation, la raison de l'valuation, et le statut. Pour viter de crer trois tables de
dimension avec une seule colonne (en dehors de la cl) ou de placer ces trois lments dans la table de fait que
les dimensions dgnres, une dimension d'ordure sera cr pour contenir ces lments divers.
La colonne EVALUATION_HEADER.EVAL_STATUS contient des textes qui ne sont pas toujours cohrentes. Par
exemple, l'analyse montre que la valeur complete, Completed, ou Successful signifie que l'valuation est
termine. Ceci devra tre rsolu.
La table de fait contiendra une colonne pour score possible et un autre pour le score rel, montrant chacune des
valeurs de 1-5. Ces colonnes peuvent ensuite tre ajoutes pour montrer les performances de l'valuation dans
le contexte des dimensions.
Ces dernires sont organises en dimensions reprsentant les axes de recherche suivants :
DIM_DAY
DIM_EMPLOYEE
DIM_EVALUATION_JUNK
56
Description des tables de Dimension
DIM_DAY
Ceci est une table date de dimension standard au niveau de la journe.
Table DIM_MONTH
KEY_DAY INT
CALENDAR_DAY DATE
CALENDAR_MONTH_NUMBER INT
MONTH_NAME NVARCHAR(50)
CALENDAR_QUARTER INT
CALENDAR_YEAR INT
FISCAL_MONTH_NUMBER INT
FISCAL_QUARTER INT
FISCAL_YEAR INT
57
DIM_EMPLOYEE
Table DIM_EMPLOYEE
KEY_EMPLOYEE INT
EMPLOYEE_ID INT EMPLOYEE.ID
APPOINTMENT_ID INT APPOINTMENT.ID
EMPLOYEE_NUMBER NVARCHAR(100) EMPLOYEE.EMPLOYEE_NUMBER
FIRST_NAME NVARCHAR(100) EMPLOYEE.FIRST_NAME
LAST_NAME NVARCHAR(100) EMPLOYEE.LAST_NAME
FULL_NAME NVARCHAR(100) Derived - Combinaison de
EMPLOYEE.FIRST_NAME et
EMPLOYEE.LAST_NAME
HIGHEST_DEGREE_EARNED NVARCHAR(100) EMPLOYEE.HIGHEST_DEGREE_EARNED
APPOINTMENT_BEGIN_DATE DATETIME APPOINTMENT.APPOINTMENT_BEGIN_DATE
APPOINTMENT_END_DATE DATETIME APPOINTMENT.APPOINTMENT_END_DATE
TITLE NVARCHAR(100) TITLE.TITLE_NAME
DEPARTMENT_NAME NVARCHAR(100) DEPARTMENT.DEPARTMENT_NAME
DEPARTMENT_NUMBER NVARCHAR(100) DEPARTMENT.DEPARTMENT_NUMBER
DIM_EVALUATION_JUNK
KEY_EVALUATION_JUNK INT
NVARCHAR(255) EVALUATION_HEADER.EVAL_STATUS
EVALUATION_STATUS (see the LOOKUP_EVAL_STATUS table
description below)
REASON_NAME NVARCHAR(255) EVAL_REASON.REASON_NAME
ITEM_NAME NVARCHAR(255) EVALUATION_ITEM.ITEM_NAME
LOOKUP_EVAL_STATUS
Ceci est une table LOOKUP qui est utilise pour mapper le diver.
Les valeurs de STATUS EVALUATION HEADER.EVAL des valeurs constantes utilises par le magasin de donnes.
Les utilisateurs ont examin les valeurs distinctes actuellement dans la colonne STATUS EVALUATION
HEADER.EVAL et condition que le mappage. L'ETL sera rfrence cette table en plaant le statut d'valuation
dans l'toile.
58
Ceci est la table LOOKUP_EVAL_STATUS qui contient ce qui suit ...
ID INT
ORIGINAL_EVAL_STATUS NVARCHAR(255)
WAREHOUSE_EVAL_STATUS NVARCHAR(255)
FACT_ EVALUATION
Ceci est une table de fait additif de base qui permet l'utilisateur d'analyser relle et possible note d'valuation
par date, le destinataire de l'valuation (personne), l'tat de l'valuation, la raison de l'valuation, et l'valuation
article. Le DD_EVALUATOR_NAME est une dimension dgnre qui vient de la colonne EVALUATION DE
HEADER.EVALUATOR. Parce que le systme source a des noms dans cette colonne en plusieurs formats avec
aucun autre identificateur, une cl trangre la table de DIM_EMPLOYEE n'a pas pu tre cre. Le
ACTUAL_SCORE et POSSIBLE_SCORE sont deux valeurs additives qui viennent de la SCORE EVALUATION
DETAIL.ACTUAL et les colonnes SCORE EVALUATION_DETAIL.POSSIBLE, respectivement. Les trois valeurs cls se
rfrent leurs tables de dimensions associes.
KEY_EVALUATION_DATE INT
KEY_EVALUATION_RECIPIENT INT
KEY_EVALUATION_JUNK INT
DD_EVALUATOR_NAME NVARCHAR(255)
ACTUAL_SCORE INT
POSSIBLE_SCORE INT
59
Le modle en toile de lactivit Employee
Leave
Les tables de Dimension
Le modle retenu une perspective globale et multidimensionnelle par rapport aux besoins de la direction RH, il
est reprsent par un schma en toile des tables de dimensions et des tables de faits rduite et particularise.
Ces dernires sont organises en dimensions reprsentant les axes de recherche suivants :
DIM_DAY
DIM_EMPLOYEE
Table DIM_MONTH
KEY_DAY INT
CALENDAR_DAY DATE
CALENDAR_MONTH_NUMBER INT
MONTH_NAME NVARCHAR(50)
CALENDAR_QUARTER INT
CALENDAR_YEAR INT
FISCAL_MONTH_NUMBER INT
FISCAL_QUARTER INT
FISCAL_YEAR INT
60
DIM_EMPLOYEE
Table DIM_EMPLOYEE
KEY_EMPLOYEE INT
EMPLOYEE_ID INT EMPLOYEE.ID
APPOINTMENT_ID INT APPOINTMENT.ID
EMPLOYEE_NUMBER NVARCHAR(100) EMPLOYEE.EMPLOYEE_NUMBER
FIRST_NAME NVARCHAR(100) EMPLOYEE.FIRST_NAME
LAST_NAME NVARCHAR(100) EMPLOYEE.LAST_NAME
FULL_NAME NVARCHAR(100) Derived - Combinaison de
EMPLOYEE.FIRST_NAME et
EMPLOYEE.LAST_NAME
HIGHEST_DEGREE_EARNED NVARCHAR(100) EMPLOYEE.HIGHEST_DEGREE_EARNED
APPOINTMENT_BEGIN_DATE DATETIME APPOINTMENT.APPOINTMENT_BEGIN_DATE
APPOINTMENT_END_DATE DATETIME APPOINTMENT.APPOINTMENT_END_DATE
TITLE NVARCHAR(100) TITLE.TITLE_NAME
DEPARTMENT_NAME NVARCHAR(100) DEPARTMENT.DEPARTMENT_NAME
DEPARTMENT_NUMBER NVARCHAR(100) DEPARTMENT.DEPARTMENT_NUMBER
FACT_ LEAVE
Ceci est une table de fait additif de base qui permet l'utilisateur d'analyser LEAVE utilis et les congs
accumuls par date, personne, et LEAVE type. La DD_LEAVE_TYPE est une dimension dgnre qui provient de
la colonne de LEAVE_TYPE.TYPE. Les deux valeurs de cl trangre se rfrer leurs tableaux de dimensions
associes.
KEY_EMPLOYEE INT
KEY_DAY INT
LEAVE_BANK INT
LEAVE_USED INT
DD_LEAVE_TYPE NVARCHAR(255)
61
Le modle en toile de lactivit Salaire vs
Evaluation
Les tables de Dimension
Le modle retenu une perspective globale et multidimensionnelle par rapport aux besoins de la direction RH, il
est reprsent par un schma en toile des tables de dimensions et des tables de faits rduite et particularise.
Ces dernires sont organises en dimensions reprsentant les axes de recherche suivants :
DIM_CALENDAR_YEAR
DIM_EMPLOYEE
62
Table FACT_ EVALUATION
KEY_CALENDAR_YEAR INT
CALENDAR_YEAR INT
FIRST_DAY DATE
LAST_DAY DATE
DIM_EMPLOYEE
Table DIM_EMPLOYEE
KEY_EMPLOYEE INT
EMPLOYEE_ID INT EMPLOYEE.ID
APPOINTMENT_ID INT APPOINTMENT.ID
EMPLOYEE_NUMBER NVARCHAR(100) EMPLOYEE.EMPLOYEE_NUMBER
FIRST_NAME NVARCHAR(100) EMPLOYEE.FIRST_NAME
LAST_NAME NVARCHAR(100) EMPLOYEE.LAST_NAME
FULL_NAME NVARCHAR(100) Derived - Combinaison de
EMPLOYEE.FIRST_NAME et
EMPLOYEE.LAST_NAME
HIGHEST_DEGREE_EARNED NVARCHAR(100) EMPLOYEE.HIGHEST_DEGREE_EARNED
APPOINTMENT_BEGIN_DATE DATETIME APPOINTMENT.APPOINTMENT_BEGIN_DATE
APPOINTMENT_END_DATE DATETIME APPOINTMENT.APPOINTMENT_END_DATE
TITLE NVARCHAR(100) TITLE.TITLE_NAME
DEPARTMENT_NAME NVARCHAR(100) DEPARTMENT.DEPARTMENT_NAME
DEPARTMENT_NUMBER NVARCHAR(100) DEPARTMENT.DEPARTMENT_NUMBER
FACT_EVAL_PAY_COMPARAISON
63
Table FACT_ EVAL_PAY_COMPARAISON
KEY_EMPLOYEE INT
KEY_CURRENT_CALENDAR_YEAR INT
KEY_PRIOR_CALENDAR_YEAR INT
PRIOR_YEAR_EVAL_SCORE INT
PRIOR_YEAR_SALARY INT
CURRENT_YEAR_EVAL_SCORE INT
CURRENT_YEAR_SALARY INT
EVAL_PERCENTAGE_CHANGE INT
SALARY_PERCENTAGE_CHANGE INT
64
Conclusion
Ce chapitre a rappel la dmarche suivie pour la ralisation et mise en place du Datamart. Il
dcrit aussi les diffrentes indicateurs et axes danalyse qui sert rpondre aux besoins de
client.
65
Partie VI
Ralisation
66
Extraction ETL
ETL est un systme de chargement de donnes depuis les diffrentes sources d'information de
l'entreprise, htrognes, jusqu' l'entrept de donnes. Ce systme ne se contente pas de
charger les donnes, il doit les faire passer par un tas de moulinettes pour les d-normaliser,
les nettoyer, les contextualiser, puis de les charger de la faon adquate.
Il est important de savoir que la ralisation de l'ETL constitue 70% d'un projet dcisionnel en
moyenne. Et ce n'est pas pour rien, ce systme est complexe et ne doit rien laisser s'chapper,
sous peine d'avoir une mauvaise information dans l'entrept, donc des donnes fausses, donc
un systme inutilisables.
Dans cette phase, et aprs avoir dtermin les axes danalyse dont on aura besoin, on va passer
la cration de ses axes via des tables de dimension en utilisant loutil SSIS.
La figure en dessous prsente quelques tables de dimension crent avant leurs remplissages.
67
Cration des tables de fait
Chaque entrept de donnes inclut une ou plusieurs tables de faits. Centrale par rapport un
schma en toile ou en flocons, une table de faits capture les donnes qui mesurent les
oprations de l'quipe. Les tables de faits contiennent habituellement de grands nombres de
lignes, en particulier lorsqu'elles contiennent une ou plusieurs annes d'historique pour un
grand projet d'quipe.
Une caractristique cl d'une table de faits est qu'elle contient des donnes numriques (faits)
qui peuvent tre rsumes pour fournir des informations sur l'historique des oprations de la
socit. Chaque table de faits inclut galement un index multipart qui contient, comme cls
trangres, les cls primaires de tables de dimension connexes qui contiennent elles-mmes
les attributs des enregistrements de faits. Les tables de faits ne doivent pas contenir
d'informations descriptives ni de donnes autres que les champs de mesures numriques et
les champs d'index qui relient les faits aux entres correspondantes dans les tables de
dimension.
La figure en bas prsente un exemple de la cration dune table de fait parmi les tables crer.
68
Cration des rapports
La cration des rapports qui reprsentent la phase finale dun systme dcisionnel et qui vont
permettre aux diffrents utilisateurs et responsables de prendre les bonnes dcisions pour un
bon pilotage de lentreprise.
Dans cette tape, on effectue un filtrage selon des critres quon veut afficher pour la fin avoir
un rapport
69
Conclusion Gnrale
Au cours de la ralisation de ce projet, nous allons pu dvelopper une double comptence,
technique et fonctionnelle sur le mtier des RH ainsi que la bonne conduite dun projet
informatique BI, ceci est grce la prdisposition de mon encadrant, aux recherches effectues,
et aux modules enseigns lors de ma formation.
La premire tape du travail, relative la phase thorique du projet, a t consacre sur ltude
de la plateforme matriel/logiciel, et de la dfinition de lobjectif et le contexte global du projet
qui devra satisfaire le modle des reporting demands.
Durant cette phase, nous allons rparti galement les tches du projet, en suivant un planning
prvisionnel, respectant les deadlines.
Certaines fonctionnalits avaient t envisages, afin de suivre la tendance actuelle vers le Cloud
Computing, ce qui permettra aux dcideurs de se focaliser sur les activits principales de
lentreprise, et davoir des indicateurs de performance, de Scoring et de diffrents reporting.
Sur le plan personnel, ce projet nous a permis dapprofondir nos connaissances et daccrotre
nous esprit dquipe.
70
Rfrences
[1] Inmon, W. H., Building the data warehouse, 4 d, Wiley, New York, 2005, 543p.
[2] Breslin, M., Data Warehousing Battle of the Giants :Comparing the Basics
of the Kimball and Inmon Models, Business Intelligence Journal, vol. 9, no1, 004,
pp.6-20.
[3] Kimball, R. ET Ross, M., The data warehouse toolkit, New York, 1998, 436p
[4] http://grim.developpez.com/articles/concepts/etl/
71