You are on page 1of 71

PROJET DE FIN DETUDES

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

Filire Ingnierie Informatique et Rseaux


Option MIAGE (Mthodes Informatiques Appliques la Gestion des Entreprises)

Anne universitaire : 2015/2016


Mise en place
Dun datamart
Ressources Humaines

Ralis par :
Bouhouch Youssef
Kouraimiten Abdelaziz

Encadr par : M. A.Riad Elidrissi

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

Partie II: Architecture matrielle et logiciel38


Chapitre 4: Architecture matrielle..39
Chapitre 5: Architecture logiciel.41

Partie III: Conception du datamart.48


Chapitre 6: Matrice dimensionnelle.49
Chapitre 7: Schmas toile, snowflack, constellation.52

Partie VI: Ralisation.....66


Conclusion Gnrale...70

6
LISTE DES FIGURES
.

Figure 1. 1: Illustration de la solution BI ...................................................................................... 10


Figure 1. 2: Illustration de la lapproche Source de donnes .................................................... 14
Figure 1. 3: Conception dun ED par un processus dintgration (selon Inmon) .............................. 15
Figure 1. 4: Illustration de lapproche Besoins danalyse .......................................................... 17
Figure 1. 5: Illustration de lapproche Mixte ............................................................................ 19
Figure 1. 6: Illustration de la Flux de communication .................................................................... 28
Figure 1. 7: Illustration de la Capitalisation des risques au sein de lorganisme .............................. 34
Figure 1. 8: Architecture physique ............................................................................................... 39
Figure 1. 9: Architecture applicative ........................................................................................... 41
Figure 1. 10: Composants de SQL Server ...................................................................................... 42
Figure 1. 11: Objectif de qualit de donnes dans un processus ETL [Kimball, 2004]. .................. 44

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

Tableau 2. 1: Membres de lquipe du projet ................................................................................. 27


Tableau 2. 2: Gestion du dlai ..................................................................................................... 29
Tableau 2. 3: Analyse des carts .................................................................................................. 33
Tableau 2. 4: Matrice des Risques ............................................................................................... 35
Tableau 2. 5: Description de larchitecture physique..................................................................... 40
Tableau 2. 6: Comparatif entre les tables de faits et les tables de dimensions. ................................ 50

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

Cette surabondance de donnes, et limpossibilit des systmes oprationnels de les exploiter


des fins danalyse conduit, invitablement, lentreprise se tourner vers une nouvelle
informatique dite dcisionnelle qui met laccent sur la comprhension de lenvironnement de
lentreprise et lexploitation de ces donnes bon escient.

En effet, les dcideurs de lentreprise ont besoin davoir une meilleure vision de leur
environnement et de son volution, ainsi, que des informations auxquelles ils peuvent se fier.
Cela ne peut se faire quen mettant en place des indicateurs business clairs et pertinents
permettant la sauvegarde, lutilisation de la mmoire de lentreprise et offrant ses dcideurs
la possibilit de se reporter ces indicateurs pour une bonne prise de dcision.

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

Ce rapport est organis comme suit :

Partie I: Management du projet


Partie II: Architecture matrielle et logiciel
Partie III: Conception du datamart
Partie VI: Intgration des donnes
Parier v : Couche logique Et Reporting

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 :

Lapproche dite classique (en cascade).


Lapproche en spirale.
Lapproche en V.

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 :

Lapproche Top-Down Source de donnes de Bill Inmon.


Lapproche Bottom-Up Besoins danalyse de Ralph Kimball.
Lapproche Middle-Out (Hybride).

Si vous recherchez la meilleure approche, il n'existe pas de meilleure approche, mais plutt
recherchez l'approche la plus adapte votre contexte.

Lapproche Top-Down de Bill Inmon


Bill Inmon est un informaticien amricain considr comme le pre des entrepts et crivain
dun livre [1] expliquant une approche pour les crer. Dans son approche, il faut dabord crer
lentrept qui comprend lensemble des donnes de lentreprise, pour ensuite alimenter de
mini-entrepts de donnes dpartementales. Chaque mini-entrept vise un secteur particulier
de lentreprise et sera la source des requtes et rapports utiliss par les dcideurs de
lentreprise.

Inmon divise lenvironnement de bases de donnes de lentreprise en quatre niveaux :

Oprationnel.

Entrept de donnes atomique.

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.

Dvelopper suivant la mthodologie dInmon demande une connaissance approfondie de


lentreprise. Inmon recommande lutilisation de modles de donnes dj existants sur le
march pour le domaine daffaires de lentreprise. [2] La modlisation de la base de donnes
repose sur les techniques traditionnelles dentits-association et de normalisation. Le modle
dentits-association est un modle de donnes conceptuel de haut niveau contenant des
entits et les associations entre elles, traditionnellement utilis pour concevoir des bases
de donnes en informatique.

La mthodologie dInmon est destine un public compos de professionnels des


technologies de linformation. Les utilisateurs jouent un rle passif dans le dveloppement de
lentrept; [2] ils sont cependant plus impliqus au moment dillustrer leurs besoins.

Inmon dcrit sa mthodologie en la comparant au Software Development Life Cycle (SDLC). Le


SDLC est aliment par les besoins des utilisateurs.

Inmon prtend que sa mthodologie est exactement le contraire et lappelle CLDS(en


inversant les lettres SDLC). La figure 1.1 illustre le CLDS. Le CLDS dbute avec les
donnes. Elles sont intgres et testes puis une analyse est faite pour dcouvrir des
tendances. Ensuite, des programmes sont crs pour alimenter le systme de support
la dcision. Ultimement, une analyse des rsultats des programmes est faite pour enfin
comprendre les besoins. [1] Le cycle se rpte pour chaque ensemble de donnes disponible.

Figure 1. 2:
Illustration de
Lapproche
Source de
Donnes

DSS (decision support systems)

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.

Tableau 1. 1: Avantages et inconvnients de lapproche guide par les donnes sources


(Approche Top-Down)

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

Minimise la redondance des Complexit de source de donnes


donnes.
Pas efficace long terme.
efficace court terme.
Ncessite de crer d'autres
Meilleur quilibre en termes de structures pour permettre
la flexibilit. lexploration de donnes data
mining .

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 applications analytiques.

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.

Ces trois chemins sont intgrs en fin de projet au moment du dploiement. Le


processus complet est rpt pour chaque nouveau magasin de donnes demand par les
utilisateurs.

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.

Rutilisation des donnes. Ngligence du systme

Supporter les autres oprationnel


structures.
Difficult de dterminer les besoins
Data Mining. des Utilisateurs

limine les extraits Plus cher.


redondants.
Plus de temps

Lapproche Middle-Out (Hybride)


Lapproche Hybride combine les deux dmarches prcdentes. Aussi appele approche mixte,
En effet, cette approche construit dune part des schmas candidats partir des sources de
donnes (dmarche ascendante) et dautre part des schmas multidimensionnels partir des
besoins danalyse (dmarche descendante). Linformaticien doit confronter ces deux types de
schmas pour obtenir un schma multidimensionnel cohrent et rpondant aux besoins des
dcideurs.

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.

La conception dun schma multidimensionnel selon la dmarche mixte prend en compte


simultanment le schma des sources et les besoins des dcideurs. En raison de son caractre
progressif, cette dmarche nous a parus mieux adapte notre processus qui est destin des
utilisateurs non informaticiens.

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.

Tableau 1. 3: Avantages et inconvnients de lapproche mixte (Approche hybride ou


Approche Middle-Out)

Avantages Inconvnients

Prendre le meilleur des deux Les utilisateurs peuvent tre


approches. confus quand ils ne savent pas
qui ils doivent adresser leurs
Dveloppe un modle de requtes.
donnes d'entreprise de faon
itrative. Le remblayage du data
Warehouse peut tre un
Dveloppe une infrastructure processus trs perturbateur.
lourde quune fois qu'il est
vraiment ncessaire.

Mthodologie adopte pour le projet


Lapproche adopte pour notre projet est lapproche Bottom-Up de Ralph Kimball, cette
approche nous permet de construire le schma de lentrept partir dune analyse dtaille des
besoins des dcideurs, les problmes de correspondances entre ces besoins et les sources
existantes sont traits postriori lors du chargement des donnes dans lentrept.

20
Les phases du cycle de vie du projet sont les suivantes :

1. Planification du projet : La planification aborde la dfinition et ltendue du projet de


lentrept, y compris lapprciation du niveau de maturit de lorganisation face ce type
dapproche. Elle se concentre sur les besoins en termes de ressources et de niveau de
qualification, coupls aux affectations des tches, leurs dures et leur squencement.
La planification dpend bien videmment des besoins, comme lindique la flche en
double sens du schma.

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.

5. Conception du modle physique : La conception physique dune base de donnes dfinit


les structures ncessaires pour limplmentation du modle dimensionnel. Les lments
fondamentaux sont la dtermination des rgles de nommage des objets, la mise en place
de lenvironnement de la base de donnes. Lindexation primaire, les stratgies de
partitionnement et les agrgations primaires sont galement dfinies. La conception du
modle physique est fortement dpendante de la machine utilise pour lentrept.

6. Dfinition de larchitecture technique : Cette tape dfinit la vision globale de


larchitecture technique mettre en uvre. Elle ncessite la prise en compte de trois
facteurs : Les besoins; Lenvironnement existant et les orientations techniques
stratgiques planifies. En plus de larchitecture supportant lentrept, il est ncessaire de
mener des rflexions sur les outils de conception de la zone de prparation des donnes
et des outils de restitutions.

7. Conception et dveloppement de la zone de prparation des donnes : La conception de la


zone de prparation des donnes (staging area) constitue gnralement la tche la plus
sous-estime du projet entrept de donnes. Le processus de prparation se droule en
trois phases majeures : Extraction, Transformation et le Chargement (Loading).

8. Choix technologiques et mis en uvre : A partir de ltude de larchitecture technique il


faut slectionner les composants spcifiques, telle plate-forme(s) matrielle(s) et
logiciel(s), SGBD outils dextraction et restitution mettre en uvre. Une fois les produits
valus et slectionns, ceux-ci doivent tre installs et tests mticuleusement afin de
garantir une intgration adquate dun bout lautre de lenvironnement de lentrept.

9. Dveloppement de lapplication utilisateur : Il est recommand de dfinir une srie


dapplication standard destine aux utilisateurs finaux, car tous nont pas besoin dun

21
accs ad hoc lentrept. Les spcifications de lapplication dcrivent les maquettes
dtats, les critres de slection laisss lutilisateur et les calculs ncessaires.

10. Dploiement : Le dploiement est le point de convergence de la technologie, des donnes


et des applications utilisateurs. Une planification est indispensable pour grer le
dploiement qui comprend galement la formation des utilisateurs, les processus de
communication, le support utilisateur, la prise en compte des demandes dvolution et de
correction.

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.

Description des phases de projet


Phase de Planification du projet:

Tableau 1. 4: Description de la phase Planification du projet

Objectifs
Comprendre dune manire globale le projet

Planifier le projet

Prrequis
Etape de la phase Planning

Livrables en sortie Cahier de charge


Plan dassurance qualit.
Dpendance N/A

Critres de fin de phase :


Le cahier de charge rdig et valid, le travail planifi, la phase danalyse peut
commencer.

22
Phase de Dfinition des besoins

Tableau 1. 5: Description de la phase de Dfinition des besoins

Objectifs Validation des besoins du client dgags


Avoir les inputs ncessaires pour la phase de
conception.

Prrequis
Etape de la phase Analyse

Livrables en sortie Dossier danalyse et spcification.

Dpendance N/A

Critres de fin de phase :


Validation des besoins exprims par le client.

Phase de Modlisation dimensionnelle

Tableau 1. 6: Description de la phase de Modlisation dimensionnelle

concevoir la base de donnes multidimensionnelle


Objectifs
Prrequis
Conception
Etape de la phase
Dossier darchitecture Fonctionnelle.
Livrables en sortie
Phase de Planification et analyse des besoins
Dpendance
Critres de fin de phase :
Comprhension fonctionnelle de lapplication par lquipe de dveloppement.

23
Phase de Conception du modle physique

Tableau 1. 7: Description de la phase de Conception du modle physique

Mettre en place la plateforme dcisionnelle


Objectifs
sur le plan technique

Disposer des pr-requis logiciels et matriels.


Prrequis
Dfinir larchitecture physique.
Etape de la phase
Dossier darchitecture technique.
Livrables en sortie
Phase de Planification et analyse des besoins
Dpendance
Critres de fin de phase :
Avoir un environnement de dveloppement stable permettant lintgration des
donnes et la ralisation du reporting demand.

Phase de Dfinition de larchitecture technique

Tableau 1. 8: Description de la phase Dfinition de larchitecture technique

Concevoir larchitecture cible globale


Objectifs

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

Tableau 1. 9: Description de la phase Conception et dveloppement de la zone de


prparation des donnes

Objectifs Cration dune base donne destination

Concept faits.
Prrequis
Concept dimensions.

Cration dun DataMart


Etape de la phase
Dossier darchitecture Applicative
Livrables en sortie
Phase de Modlisation dimensionnelle
Dpendance
Critres de fin de phase :
Existence dune base de donnes destination

Phase de Choix technologiques et mis en uvre

Tableau 1. 10: Description de la phase de Choix technologiques et mis en uvre

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

Tableau 1. 11: Description de la phase de Dploiement

Objectifs
Assistance linstallation de lenvironnement de production
Prrequis
Etape de la phase dploiement

Livrables en sortie

Dpendance Recette

Critres de fin de phase :


Mise en place de la solution dveloppe en environnement de production.

Phase de Maintenance et croissance

Tableau 1. 12: Description de la phase de Maintenance et croissance

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.

Tableau 2. 1: Membres de lquipe du projet

Nom Cordonne Rle Tches

Abdessamad riadelidrissi@gmail.com Encadrant Contrle et


RIAD ELIDRISSI suivi du projet.

Youssef bouhouch89@gmail.com Ingnieur Analyse &


BOUHOUCH conception.
Ralisation.

Abdelaziz kraimten@gmail.com Ingnieur Analyse &


KOURAIMTEN conception.
Ralisation.

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

Tableau 2. 2: Gestion du dlai

Tches Dlais Date Dbut Date Fin

Mise en place d'un datamart RH


Jeu 28/01/16 Ven 29/04/16
67 jours

Phase de Planification du projet


Jeu 28/01/16 Lun 01/02/16
3 jours

Runion de cadrage 1 jour Jeu 28/01/16 Jeu 28/01/16

Gestion des risques 2 jours Ven 29/01/16 Lun 01/02/16

Validation 0 jour Lun 01/02/16 Lun 01/02/16

Gestion du projet
Mar 02/02/16 Mer 03/02/16
2 jours

Gestion du projet 2 jours


Mar 02/02/16 Mer 03/02/16

Dfinition des besoins


Jeu 04/02/16 Mar 09/02/16
4 jours

identification des besoins 2 jours Jeu 04/02/16 Ven 05/02/16

Choix des outils 2 jours Lun 08/02/16 Mar 09/02/16

Validation 0 jour Mar 09/02/16 Mar 09/02/16

Modlisation dimensionnelle
Mer 10/02/16 Ven 19/02/16
8 jours

Conception de la BD 4 jours Mer 10/02/16 Lun 15/02/16

Conception dtaille 4 jours Mar 16/02/16 Ven 19/02/16

Validation 0 jour Ven 19/02/16 Ven 19/02/16

Conception du modle physique


Lun 22/02/16 Ven 26/02/16
5 jours

Etude de l'architecture et de l'infrastructure 5 jours Lun 22/02/16 Ven 26/02/16


technique
Validation 0 jour Ven 26/02/16 Ven 26/02/16

Dfinition de larchitecture technique


Lun 29/02/16 Mer 09/03/16
8 jours

Etude des sources de donnes Lun 29/02/16 Jeu 03/03/16


4 jours
Etude de la volumtrie de donnes sources Ven 04/03/16 Mer 09/03/16
4 jours
Validation 0 jour Mer 09/03/16 Mer 09/03/16

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

Cration de la base(Datamart) 5 jours Jeu 17/03/16 Mer 23/03/16

Validation 0 jour Mer 23/03/16 Mer 23/03/16

Choix technologiques et mis en uvre


Jeu 24/03/16 Lun 04/04/16
8 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

Dveloppement de lapplication utilisateur


Mar 05/04/16 Ven 15/04/16
9 jours

Cration de la couche smantique Mar 05/04/16 Lun 11/04/16


5 jours
Cration des rapports Mar 12/04/16 Ven 15/04/16
4 jours
Validation Ven 15/04/16 Ven 15/04/16
0 jour

Dploiement
Lun 18/04/16 Ven 22/04/16
5 jours

Dploiement Lun 18/04/16 Ven 22/04/16


5 jours

Maintenance et croissance
Lun 25/04/16 Ven 29/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

Tableau 2. 3: Analyse des carts

Nom Dure : Prv Dure : Rel Dure : Diff


4 5 1
Dfinition des besoins

8 10 2
Modlisation dimensionnelle

8 10 2
Dfinition de larchitecture technique

67 73 5
Total

33
Chapitre 3

Gestion des risques


.

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.

Matrice des Risques:


Niveau Actions
Rf. Description Impact Type Probabilit
dimpact
Poids
prventives
-Planning
Mauvaise
Risque prvisionnel
estimation du Retard sur le
R01 planning planning rel
gestion de 3/4 2/4 dtermin avec
projet une marge de
prvisionnel
manuvre
-Recensement des
Ca bloquera bugs connus
Instabilit de Risque
R02 l'environnement
lavancement du
Technique
2/4 4/4 -
projet. Recommandation
s de configuration
-La ralisation
dune tude
technique
Les outils exigs
Impossibilit -La ralisation
ne peuvent pas Risque
R03 rpondre au
dachever le
Technique
1/4 2/4 dune
projet. dmonstration
besoin.
avec des
chantillons des
fichiers sources
Les donnes -Dterminer des
dans le moyens de reprise
Lintgration des Risque
R04 donnes choue
Datamart ne
Fonctionnel
2/4 3/4 en cas derreurs
sont pas
intgres.
-Le
Le produit ne
dveloppement
La conception est couvre pas tous Risque
R05 insuffisante les volets du Fonctionnel
3/4 4/4 incrmental et
limplication du
besoin
client.
-Un planning
Risque dtaill
Le suivi est Le dpassement
R06 insuffisant des dlais
Organisatio 2/4 2/4 -Des runions de
nnel suivi
hebdomadaires
Tableau 2. 4: Matrice des Risques

35
Impact *Probabilit Classement

1/16 3/16 Faible Echelle Impact Probabilit


Moyen 1/4 Risque acceptable Rare
4/16 7/16
2/4 Performance Possible
8/16 11/16 Svre 3/ 4 retard de livraison Souvent
12/16 16/16 Dangereux non disponibilit dune Trs
4/4
fonction vitale possible
Impact des Risques
Calcul des Risques

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 :

les environnements techniques


les systmes dexploitation
les rseaux de tlcommunications

Schma physique

Serveur BD Serveur de Reporting


SQL Server 2012

Figure 1. 8: Data Mart


Architecture Ressources Humaines
physique
Serveur des fichiers

39
Descriptif de larchitecture
Tableau 2. 5: Description de larchitecture physique

Equipement Description

Serveur BD -contient la base de donnes globale sous SQL server 2012

Serveur du rapport -Traite les demandes de rapports et tient


disposition les rapports pour l'accs la demande
ou la distribution planifie.
Data Mart -Chargement des donnes.
-Insrer et mettre jour les tables de faits et les
dimensions.
Serveur de fichiers -Permet de partager des donnes travers un rseau.
-possde gnralement une grande quantit d'espace
disque o sont dposs des fichiers.
Firewall -Applique un niveau de scurit en fonction du type de
rseau.
-Bloque les tentatives d'intrusion lances sur les rseaux
Switch -Utilis pour interconnecter plusieurs cbles
Ethernet.
-Son principe est de diriger les donnes mises
vers le PC qui les donnes sont destines.

40
Chapitre 5

Architecture logiciel
.

Prsentation globale

Figure 1. 9:
Architecture
applicative

Description des Outils


Source de donnes
Microsoft SQL Server 2012 : SQL Server 2012 est un systme de gestion de bases
de donnes relationnelles. Le stockage, la manipulation et lanalyse de ces
donnes se font au sein de son moteur de bases de donnes. Ce service permet
la ralisation de nombreuses applications, requtes SQL/ T-SQL.

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.

Microsoft Excel : Est un logiciel de tableur de la suite bureautique Microsoft,


dveloppe et distribue par l'diteur Microsoft ; il est destin fonctionner sur
les plates-formes Microsoft Windows ou Mac OS X. Le logiciel Excel intgre des
fonctions de calcul numrique, de reprsentation graphique, d'analyse de
donnes (notamment de tableau crois dynamique) et de programmation.

Figure 1. 10: Moteur


SSIS SSAS SSRS
Composants BDD
de SQL Server D
SQL server 2012

Sous systme dalimentation


Une fois le Data Mart conu, il faut lalimenter et le charger en donnes. Cette
Alimentation (le plus souvent appele processus ETL Extract-Transform-Load ) se
droule en 3 phases qui sont :
Extraction des donnes primaires
Transformation des donnes,
Le chargement des donnes traites dans data mart.
Ces trois tapes dcrivent une mcanique cyclique qui a pour but de garantir
Lalimentation du Data Warehouse en donnes homognes, propres et fiables.

Les phases de lalimentation E.T.L.


Les phases du processus E.T.L. reprsentent la mcanique dalimentation du Data
Mart. Ainsi elles se droulent comme suit :

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

Sr : assure lacheminement des donnes et leur livraison.


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

Les outils E.T.L.


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

Systme de cration de la couche smantique

Analyse dimensionnelle des donnes:


Lanalyse dimensionnelle est sans doute celle qui exploite et fait ressortir au mieux les
capacits de lentrept de donnes. Le but par lanalyse dimensionnelle est doffrir
aux utilisateurs la possibilit danalyser les donnes selon diffrents critres afin de
confirmer une tendance ou suivre les performances de lentreprise.
Cette analyse se fait selon le principe OLAP, offrant de ce fait aux utilisateurs les
possibilits de recourir diffrentes oprations facilitant la navigation dans les
donnes. La mise en place de ces outils est une option trs intressante dans la
mesure o les donnes seront accessibles en analyses instantanes. Plusieurs
fournisseurs de solution OLAP existent sur le march et offrent des solutions
construites sur des mthodes et technologies diffrentes.
Cest dailleurs pour cela que le choix de la solution doit se faire au pralable, selon
les besoins en utilisation, la taille de lentrept et les moyens techniques disponibles.

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
.

Conception du modle dcisionnel


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

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


rpute pour ses performances leves.

La nomination schma des jointures en toile a longtemps t adopte pour


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

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

Comparatif entre les tables de faits et les tables de


dimensions
Le tableau suivant rcapitule les diffrences au niveau des donnes de ces tables :
Tables de faits Tables de dimensions
Tableau 2. 6: Comparatif entre les tables de faits et les tables de dimensions.

Tables de faits Tables de dimensions


Structure Peu de colonnes beaucoup de lignes Peu de lignes beaucoup de
colonnes
Donnes Mesurable, gnralement Descriptives gnralement
numrique textuelles
Rfrentiel Plusieurs cls trangres Une cl primaire
Valeur Prend de nombreuses valeurs Plus ou moins constantes
Manipulation Participe des calculs Participe des contraintes
Signification Valeurs de mesure Descriptive
Rle Assure les relations entre les Assure linterface homme /
dimensions entrept de donnes

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 $

Figure 9 : Matrice des indicateurs et axes danalyses

51
Chapitre 7

Schmas toile, flocon,


constellation
.

Diffrents modles de la modlisation


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

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.

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_EMPLOYEE
DIM_MONTH
DIM_PAY_TYPE

Schmas des Tables de Dimension/Faits


Ci-dessous le schma de la table de fait FACT_SALARY li avec ses diffrentes tables de dimension :

Description des tables de Dimension


DIM_EMPLOYEE

53
Le dtail de cette dimension est le suivant :

Table DIM_EMPLOYEE

Name Type / (taille) Source

KEY_EMPLOYEE INT Non applicable (Surrogate Key)


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_PAY_TYPE

Le dtail de cette dimension est le suivant :

Table DIM_PAY_TYPE

Name Type / (taille)

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.

PAY_CATEGORY_1 PAY_CATEGORY_2 COMPONENT_OF_GROSS_PAY


Net Pay Wages Yes
Federal Withholding Federal Withholding Yes
Employer Paid Benefit Employer Paid FICA OASDI No
Employer Paid Benefit Employer Paid FICA MED No
Employer Paid Benefit Employer Paid Health Insurance No
Employee Paid Benefit Employee Paid Health Insurance Yes
Employer Paid Benefit Employer Paid Dental Insurance No
Employee Paid Benefit Employee Paid Dental Insurance Yes
Employee Paid Benefit Employee Paid 401K Contribution Yes
Employer Paid Benefit Employer Paid 401K Contribution No

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.

Le dtail de cette dimension est le suivant :

Table DIM_MONTH

Name Type / (taille)

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

Prsentation de table de fait


Lanalyse technique a permis didentifier la table de fait suivante :

FACT_SALARY

Description de table de fait

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.

Le dtail de cette table de fait est le suivant :

Table FACT_SALARY

55
Name Type / (taille)

KEY_EMPLOYEE INT
KEY_MONTH INT
KEY_PAY_TYPE INT
AMOUNT INT

Le modle en toile de lactivit Evaluation


Description Technique
Parce que le nom de l'valuateur est stock sous forme de texte (dans diffrents formats) dans la colonne
EVALUATOR de la table EVALUATION_HEADER, il est impossible de lier cela un individu en utilisant le numro
d'employ. Par consquent, l'valuateur sera une dimension dgnre dans la table de FACT_EVALUATION.

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.

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
DIM_EVALUATION_JUNK

Schmas des Tables de Dimension/Faits


Ci-dessous le schma de la table de fait FACT_EVALUATION li avec ses diffrentes tables de dimension :

56
Description des tables de Dimension
DIM_DAY
Ceci est une table date de dimension standard au niveau de la journe.

Le dtail de cette dimension est le suivant :

Table DIM_MONTH

Name Type / (taille)

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

Le dtail de cette dimension est le suivant :

Table DIM_EMPLOYEE

Name Type / (taille) Source

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

Le dtail de cette dimension est le suivant :

Name Type / (taille) Source

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

Name Type / (taille)

ID INT
ORIGINAL_EVAL_STATUS NVARCHAR(255)
WAREHOUSE_EVAL_STATUS NVARCHAR(255)

Prsentation de table de fait


Lanalyse technique a permis didentifier la table de fait suivante :

FACT_ EVALUATION

Description de table de fait


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.

Le dtail de cette table de fait est le suivant :

Table FACT_ EVALUATION

Name Type / (taille)

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

Schmas des Tables de Dimension/Faits


Ci-dessous le schma de la table de fait FACT_LEAVE li avec ses diffrentes tables de dimension :

Description des tables de Dimension


DIM_DAY
Ceci est une table date de dimension standard au niveau de la journe.

Le dtail de cette dimension est le suivant :

Table DIM_MONTH

Name Type / (taille)

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

Le dtail de cette dimension est le suivant :

Table DIM_EMPLOYEE

Name Type / (taille) Source

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

Prsentation de table de fait


Lanalyse technique a permis didentifier la table de fait suivante :

FACT_ LEAVE

Description de table de fait


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.

Le dtail de cette table de fait est le suivant :

Table FACT_ EVALUATION

Name Type / (taille)

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

Schmas des Tables de Dimension/Faits


Ci-dessous le schma de la table de fait FACT_EVAL_PAY_COMPARAISON li avec ses diffrentes tables de
dimension :

Description des tables de Dimension


DIM_CALENDAR_YEAR

Ceci est une table date de dimension standard au niveau de l'anne.

Le dtail de cette table de fait est le suivant :

62
Table FACT_ EVALUATION

Name Type / (taille)

KEY_CALENDAR_YEAR INT
CALENDAR_YEAR INT
FIRST_DAY DATE
LAST_DAY DATE

DIM_EMPLOYEE

Le dtail de cette dimension est le suivant :

Table DIM_EMPLOYEE

Name Type / (taille) Source

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

Prsentation de table de fait


Lanalyse technique a permis didentifier la table de fait suivante :

FACT_EVAL_PAY_COMPARAISON

Description de table de fait


Ceci est une table de fait additif de base qui permet l'utilisateur d'analyser le delta entre le salaire et le score
d'valuation entre l'anne dernire et cette anne par l'employ. Il contient deux cls trangres diffrentes la
table de DIM_CALENDAR_YEAR depuis est utilis de donnes de l'anne la fois avant l'anne et le courant.

Le dtail de cette table de fait est le suivant :

63
Table FACT_ EVAL_PAY_COMPARAISON

Name Type / (taille)

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.

Cration des tables de dimension


Dans un entrept de donnes, une dimension est un lment de donnes qui permet de
catgoriser chaque lment d'un ensemble de donnes dans les rgions non-cumul. Une
dimension entrept de donnes fournit les moyens de tranche et ds" de donnes dans un
entrept de donnes. Dimensions fournir des informations structures l'tiquetage autrement
non ordonnes des mesures numriques.

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.

Nos tables de fait ont t dj dtermin pendant la phase de la conception, et la ralisation


de ces tables ncessite la cration et le remplissage de ses dimensions.

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.

On prsente ici quelques rapports raliss sous format de graphe :

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.

La modlisation multidimensionnelle ma permis de concevoir le Datawarehouse selon la


matrice des tables Faits / Dimensions, afin davoir un regroupement structur des informations.

Durant cette phase, nous allons rparti galement les tches du projet, en suivant un planning
prvisionnel, respectant les deadlines.

Ce projet nous a t trs enrichissant au point de vue connaissances et pilotage.

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

You might also like