Mémoire de de fin d’études

En vue de l’obtention du diplôme

Master 2 en Système d’Information et Infrastructure

Thème
Intégration d'une solution BI d'entreprise
Avec

Organisme d’accueil
Celia Algérie

Réalisé par : Maitre de stage :

Djaoui Sid Ahmed Said AKHROUF

Promo Master 10 Année 2016- 2018

 REMERCIMENT

Avant de commencer à rédiger mon mémoire, je tiens à adresser mes

sincères remerciements aux personnes qui m'ont permis de mener à bien
mon travail par leurs sincères collaborations.
Je saisie cette occasion pour remercie Mr Said AKHROUF notre
professeur, qui par ses conseils judicieux et son suivi du travail, a su
m'éclairer sur l'itinéraire à suivre pour arriver à bout de ce travail.
J'adresse mes sincère remerciement à Mr BIQUILLON Antoine et Mr
BRINS Ahmed pour l’encadrement de ce travail, pour leurs conseils, leurs
critiques, leurs encouragements, leurs disponibilités ainsi que pour m’avoir
accueilli et donné les moyens pour accomplir ce stage dans les meilleurs
conditions.
Je tiens mes chaleureux remerciements, aux soldats de fond, et à tous ceux
qui ont contribué de près ou de loin à l'achèvement de ce travail, à leur tête
mes parents, ma femme, mes sœurs, mes frères, mes professeurs et mes
amis.

2
 SOMMAIRE
REMERCIMENT ................................................................................................................................ 2
Introduction générale............................................................................................................................... 5
1. Contexte générale ........................................................................................................................... 6
2. Problématique.............................................................................................................................. 6
3. Objectifs du projet ....................................................................................................................... 7
Partie I : Synthèse bibliographique.......................................................................................................... 8
I. Introduction .......................................................................................................................................... 9
I.1. Les systèmes décisionnels ............................................................................................................. 9
I.1.1. La place du décisionnel dans l’entreprise: ........................................................................... 10
I.1.2. Les différentes composantes du décisionnel ........................................................................ 11
I.2. Décisionnel vs transactionnel...................................................................................................... 11
II. Le Data Warehouse........................................................................................................................... 12
II.1 Qu’est-ce qu’un Data Warehouse ............................................................................................... 12
II.2 Historique des Data Warehouse .................................................................................................. 12
II.3 Structure des données d’un Data Warehouse.............................................................................. 13
II.4 Les éléments d’un Data Warehouse............................................................................................ 15
II.5 Architecture d’un Data Warehouse............................................................................................. 17
III. Modélisation des données de l’entrepôt .......................................................................................... 18
III.1 La modélisation dimensionnelle et ses concepts ....................................................................... 18
III.1.1 Concept de fait.................................................................................................................... 19
III.1.2 Concept de dimension ........................................................................................................ 20
III.2 Différents modèles de la modélisation dimensionnelle ............................................................. 20
III.3 Le concept OLAP ...................................................................................................................... 21
III.3.1 Généralités .......................................................................................................................... 21
III.3.2 Architectures des serveurs OLAP ...................................................................................... 21
III.3.2.1 Les systèmes à architecture MOLAP .............................................................................. 21
III.3.2.2 Les systèmes à architecture ROLAP ............................................................................... 22
III.2.2.3 Les systèmes à architecture HOLAP ............................................................................... 22
III.2.2.4 Autres architecture OLAP ............................................................................................... 22
III.4 La navigation dans les données ................................................................................................. 23
III.4.1 Slice & Dice ....................................................................................................................... 23
III.4.2 Drill-down & Roll-up ............................................................................................................. 24
IV. Démarche de Construction d’un Data Warehouse .......................................................................... 25
IV.1 Modélisation et conception du Data Warehouse ....................................................................... 26
3
 IV.1.1 Approche « Besoins d’analyse » ........................................................................................ 26
IV.1.2 Approche « Source de données » ........................................................................................... 27
IV.1.3 Approche mixte ...................................................................................................................... 28
IV.2 Alimentation du Data Warehouse ............................................................................................. 29
IV.2.1 Les phases de l’alimentation « E.T.L» ............................................................................... 29
IV.2.2 Politiques de l’alimentation ................................................................................................ 30
IV.2.3 Les outils E.T.L. ..................................................................................................................... 31
IV.3 Mise en oeuvre du Data Warehouse .............................................................................................. 32
IV.4 Maintenance et expansion ............................................................................................................. 34
V. Conclusion ........................................................................................................................................ 34
PARTIEII: Conception de la solution. .................................................................................................. 36
CHAPITRE I: l'existant décisionnel...................................................................................................... 37
I. Introduction ................................................................................................................................... 37
II. Etat du décisionnel au sein de CELIA ............................................................................................. 37
III. Conclusion ........................................................................................................................................ 37
CHAPITRE II: étude des besoins .......................................................................................................... 38
I. Introduction ............................................................................................................................... 38
I.1 Description de la démarche d'étude des besoins .......................................................................... 39
Rédaction et validation du recueil récapitulatif des besoins.............................................................. 40
I.2 Problèmes et obstacles rencontrés ................................................................................................ 41
II. Conclusion ........................................................................................................................................ 41
Chapitre IV : Conception de la solution ................................................................................................ 42
I. Introduction ............................................................................................................................... 42
II. Processus de la modélisation dimensionnelle............................................................................ 42
Chapitre IV: Conception des cubes dimensionnels. .............................................................................. 43
Introduction ........................................................................................................................................... 43
I. Définition des niveaux et des hiérarchies .................................................................................. 43
II. La liste des cubes ....................................................................................................................... 43
III. Présentation des cubes dimensionnels ....................................................................................... 44
IV. Conclusion ................................................................................................................................. 44
Partie III: Evolution de la business Intelligence. ................................................................................... 47
I. Introduction ............................................................................................................................... 48
II. La self service BI ....................................................................................................................... 48
Conclusion générale et perspectives ...................................................................................................... 49

4
Introduction générale
Avec l'apparition et le développement de nouveaux phénomènes économiques comme
la mondialisation, les entreprises évoluent dans un environnement difficile à appréhender.
Le marché évolue très rapidement, la concurrence est de plus en plus forte et les clients de
plus en plus exigeants.

Pour les entreprises, la prise de décision stratégique, politique ou parfois opérationnelle devient
cruciale. Aujourd’hui la qualité des décisions prises au sein d’une organisation dépend énormément
de la performance de son système d’information.
Pour faire face à ces exigences, l’entreprise doit s’appuyer sur un ensemble d’informations
pertinentes. Celles-ci sont à la portée de toute entreprise qui dispose d’un capital de données gérées
par ses applications de production.
Mais dans leur état naturel, ces données sont surabondantes, éparpillées dans plusieurs
systèmes hétérogènes et non organisées dans une perspective décisionnelle. Il devient donc
capital de les rassembler et de les homogénéiser afin de les rendre pertinentes pour la prise
de décisions.
Les nouvelles technologies de l'information et de la communication permettent de concevoir des
systèmes d'information particulièrement novateurs avec un niveau de performance acceptable.

Pour répondre aux besoins de ses clients et ses partenaires, CELIA ALGERIE s’est donnée comme
priorité la maîtrise du nouvel outil qu’est le Business Intelligence. Ainsi la réalisation et
l’exploitation d’un tel système décisionnel constitue le travail qui nous a été demandé et qui s’inscrit
dans le cadre de notre projet de fin d’étude intitulé :
« Intégration d'une solution Business Intelligence d'entreprise avec Jet Reports ».
Notre travail s’articulera autour de trois axes. Le premier concerne la synthèse bibliographique, Le
deuxième porte sur l’étude conceptuelle d’un système décisionnel, Le troisième et dernier axe
concerne la mise en oeuvre de la solution Business Intelligence.

5
1. Contexte générale

Le présent projet consiste à déployer une solution Business Intelligence (Jet Entreprise) à partir de
l’ERP Dynamics Nav, tout en définissant un modèle unique des dimensions et métriques en
conformité avec l’objectif de centraliser et d’uniformiser les analyses dans l’entreprise, et d’offrir des
informations de qualité pour les décideurs. Il s’agit en fait de mettre à la disposition des décideurs des
données à même de les éclairer et leur faciliter une prise de décision prompte en connaissance de
cause. Une telle solution est nécessaire à l’accomplissement des processus décisionnels de Celia
Algérie.

2. Problématique

Dans l'entreprise, le volume de données traitées croît rapidement avec le temps :

L’obtention des données depuis l’ERP Microsoft NAV n'est pas simple, comme la plupart des ERP,
NAV est un environnement relativement statique, conçu pour imposer des processus commerciaux et
pour les enregistrer d'une manière systématique. Il n'est pas prévu pour permettre de souplesse dans
la manière dont les rapports et les données sont configurés et exploités.

 Des rapports quotidien sous format Excel , émis différemment par chaque service avec des
métriques et des dimensions non unifiées  différentes interprétation des analyses

 Rapports sous format Excel envoyés par e-mail, y compris les données sous-jacentes  gros
fichiers saturant les boîtes aux lettres avec peu de consultation.

 Aucun outil d'analyse Web permettant aux utilisateurs de formuler leurs propres requêtes
d'analyse

 Rapports demandant l'extraction de données et le chargement dans des feuilles Excel, en

utilisant la puissance de traitement des stations de travail  prenant du temps, risque d'erreurs
et d'actes répréhensibles

 L’utilisation de plusieurs filtres pour avoir un rapport sur Navision (perte de temps , nécessiter
d’avoir une session sur Nav)
Déployer une solution de BI apporte de nombreux avantages :

 Présenter de manière structurée et cohérente les informations

 Analyser les données de l’entreprise (avoir une seule source de données)
 Faciliter la prise de décision grâce à des indicateurs pertinents
 Consolider l’ensemble des données, achats, ventes, comptabilité, clients, etc.
 Automatiser le processus de décision en se basant sur les mêmes indicateurs pour toute
l’entreprise
 Améliorer la visibilité sur les chiffres, les écarts, les anomalies
 Anticiper et prévoir les tendances

6
3. Objectifs du projet
Les objectifs du projet étaient divisés en deux types d’objectifs :

a) Les objectifs de l’entreprise:

Ce projet a pour but d’introduire, en premier lieu, une informatique décisionnelle au sein de
l’entreprise, tout en conférant aux décideurs un support fiable pour une meilleure prise de décision.
Ainsi, les principaux objectifs assignés au projet sont :

 Automatiser le processus de décision en se basant sur les mêmes indicateurs pour toute
l’entreprise
 Rendre les rapports sur l’ERP Nav accessibles partout depuis Jet Web Portal et Excel (pas
besoin d’accès à l’ERP Nav)
 Explorer les données et créer ou de modifier les rapports sans compétence technique
particulière.
 Planifiez les rapports pour qu'ils soient générés et transmis automatiquement avec la
périodicité souhaitée, tous les jours, toutes les semaines ou tous les mois.
 déclencher des rapports à envoyer sur la base d'alertes prédéfinies (Le budget a-t-il été
dépassé ?).
 Concevez le rapport qui vous convient, enregistrez vos tâches programmées.
 Déployer et publier dans Jet Reports les rapports de base : que ce soit des rapports déjà
existants dans Nav ou autres dont les utilisateurs ont besoin
 La réduction de la durée globale de l’élaboration des rapports
 Offrir des informations fiables, cohérentes et pertinentes, contenant la logique business
souhaitée .

b) Mes objectifs
 Enrichir ma formation
 Réaliser un travail de chef de projet
 Assumer la responsabilité d'une mission managériale confiée par l'entreprise
 Capitaliser de nouvelles technologies
 Renforcer mes capacités d’analyse fonctionnelle
 Avoir un premier vrai contact projet, avec le formalisme et la rigueur que cela demande
 Comprendre le fonctionnement d’une solution BI
 Mettre en pratique les connaissances théoriques et pratiques acquises dans l'établissement
des techniques modernes ETM IBN ROCHD
 Avoir une expérience enrichissante dans mon domaine
 Valider mon diplôme.

7
Partie I : Synthèse bibliographique

8
I. Introduction

Toutes les entreprises du monde disposent d’une masse de données plus ou moins considérable.
Ces informations proviennent soit de sources internes (générées par leurs systèmes opérationnels au
fil des activités journalières), ou bien de sources externes (web,partenaire, .. etc.).

Cette surabondance de données, et l’impossibilité des systèmes opérationnels de les exploiter à des
fins d’analyse conduit inévitablement l’entreprise à se tourner vers une nouvelle informatique dite
décisionnelle qui met l’accent sur la compréhension de l’environnement de l’entreprise et
l’exploitation de ces données à bon escient.

En effet, les décideurs de l’entreprise ont besoin d’avoir une meilleure vision de leur environnement
et de son évolution, ainsi, que des informations auxquelles ils peuvent se fier.
Cela ne peut se faire qu’en mettant en place des indicateurs « business » clairs et pertinents
permettant la sauvegarde, l’utilisation de la mémoire de l’entreprise et offrant à ses décideurs
la possibilité de se reporter à ces indicateurs pour une bonne prise de décision.
Le « Data Warehouse », « Entrepôt de données » en français, constitue, dans ces conditions, une
structure informatique et une fondation des plus incontournables pour la mise en place d’applications
décisionnelles.

Le concept de Data Warehouse, tel que connu aujourd’hui, est apparu pour la première fois en 1980 ;
l’idée consistait alors à réaliser une base de données destinée exclusivement au processus
décisionnel. Les nouveaux besoins de l’entreprise, les quantités importantes de données produites par
les systèmes opérationnels et l’apparition des technologies aptes à sa mise en oeuvre ont contribué à
l’apparition du concept « Data Warehouse » comme support
aux systèmes décisionnels.

I.1. Les systèmes décisionnels

La raison d’être d’un entrepôt de données, comme évoqué précédemment, est la mise en
place d’une informatique décisionnelle au sein de l’entreprise. Pour cela il serait assez
intéressant de définir quelques concepts clés autour du décisionnel.
Afin de mieux comprendre la finalité des systèmes décisionnels, nous nous devons de les
placer dans leurs contextes et rappeler ce qu’est un système d’information.
«Le système d’information est l’ensemble des méthodes et moyens de recueil de contrôle
et de distribution des informations nécessaires à l’exercice de l’activité en tout point de
l’organisation. Il a pour fonction de produire et de mémoriser les informations, de l’activité
9
du système opérant (système opérationnel), puis de les mettre à disposition du système de
décision (système de pilotage)»[Le Moigne, 1977].

Les différences qui existent entre le système de pilotage et le système opérationnel, du

point de vue fonctionnel ou des tâches à effectuer, conduit à l’apparition des « systèmes
d’information décisionnels » (S.I.D.). Ces différences seront clairement illustrées un peu plus
loin dans notre document.

Les origines des SID remontent au début de l’informatique et des systèmes d’information
qui ont, tous deux, connu une grande et complexe évolution liée notamment à la technologie. cette
évolution se poursuit à ce jour.

Pami les différentes définitions du décisionnel « Business intelligence BI » qui ont été données on
trouve :

 "Le Décisionnel est le processus visant à transformer les données en informations et,
par l'intermédiaire d'interrogations successives, transformer ces informations en
connaissances." [Dresner, 2001].

I.1.1. La place du décisionnel dans l’entreprise:

Figure 1 : Le décisionnel au sein du Système d’information [Goglin, 1998].

La figure ci-dessus illustre parfaitement la place qui revient au décisionnel au sein d’une entreprise.
Cette place, comprend plusieurs fonctions clés de l’entreprise. Les finalités décisionnelles, étant
différentes selon le poste et la fonction occupée d’engendrer plusieurs composantes.

10
I.1.2. Les différentes composantes du décisionnel

En relation étroite avec les nouvelles technologies de l’information et des télécommunications, le

système décisionnel se manifeste à différents niveaux selon leurs
utilités et leurs missions principales, comme illustré dans la figure suivante :

Figure 2 : Les différentes composantes du décisionnel

I.2. Décisionnel vs transactionnel

Le tableau suivant résume de façon non exhaustive les différences qu’il peut y avoir
entre les systèmes transactionnels et les systèmes décisionnels selon les données et l’usage fait
des systèmes.

11
 Tableau 1 : Tableau comparatif entre les systèmes transactionnels et les systèmes décisionnels.

Ces différences font ressortir la nécessité de mettre en place un système répondant aux
besoins décisionnels. Ce système n’est rien d’autre que le « Data Warehouse ».

II. Le Data Warehouse

II.1 Qu’est-ce qu’un Data Warehouse

Le Data Warehouse, ou entrepôt de données, est une base de données dédiée au stockage de
l'ensemble des données utilisées dans le cadre de la prise de décision et de l'analyse décisionnelle.
Le Data Warehouse est exclusivement réservé à cet usage.

II.2 Historique des Data Warehouse

L’origine du concept « Data Warehouse » D.W (entrepôt de données en français) remonte

aux années 80, durant lesquelles un intérêt croissant au système décisionnel a vu le jour, dû
essentiellement à l’émergence des SGBD relationnel et la simplicité du modèle relationnel et
la puissance offerte par le langage SQL,
Au début, le Data Warehouse n’était rien d’autre qu’une copie des données du système
12
opérationnel prise de façon périodique, dédiée à un environnement de support à la prise de
décision. Ainsi, les données étaient extraites du système opérationnel, stockées dans une
nouvelle base de données «concept d’infocentre », le motif principal étant de répondre aux
requêtes des décideurs sans pour autant altérer les performances des systèmes opérationnels.
Le Data Warehouse, tel qu’on le connaît actuellement, n’est plus vu comme une copie
-ou un cumul de copies prises de façon périodique- des données du système opérationnel. Il
est devenu une nouvelle source d’information, alimenté avec des données recueillies et
consolidées des différentes sources internes et externes.

Figure 3 : évolution des bases de données décisionnelles.

II.3 Structure des données d’un Data Warehouse

Le Data Warehouse a une structure bien définie, selon différents niveaux d’agrégation et de détail des
données. Cette structure est définie par Inmon [Inmon, 2000] comme suit :

13
 Figure 4 : Structure des données d’un Data Warehouse.

Données détaillées : ce sont les données qui reflètent les événements les plus récents,
fréquemment consultées, généralement volumineuses car elles sont d’un niveau détaillé.
Données détaillées archivées : anciennes données rarement sollicitées, généralement
stockées dans un disque de stockage de masse, peu coûteux, à un même niveau de détail que
les données détaillées.
Données agrégées : données agrégées à partir des données détaillées.
Données fortement agrégées : données agrégées à partir des données détaillées, à un niveau
d’agrégation plus élevé que les données agrégées.

Meta données : ce sont les informations relatives à la structure des données, les méthodes
d’agrégation et le lien entre les données opérationnelles et celles du Data Warehouse. Les
métadonnées doivent renseigner sur :
 Le modèle de données,
 La structure des données telle qu’elle est vue par les développeurs,
 La structure des données telle qu’elle est vue par les utilisateurs,
 Les sources des données,
 Les transformations nécessaires,
 Suivi des alimentations,

14
II.4 Les éléments d’un Data Warehouse

L’environnement du Data Warehouse est constitué essentiellement de quatre

composantes : les applications opérationnelles, la zone de préparation des données, la
présentation des données et les outils d’accès aux données.

Les applications opérationnelles : ce sont les applications du système opérationnel de

l’entreprise et dont la priorité est d’assurer le fonctionnement de ce dernier et sa performance.
Ces applications sont extérieures au Data Warehouse.

Préparation des données : la préparation englobe tout ce qu’il y a entre les applications
opérationnelles et la présentation des données. Elle est constituée d’un ensemble de processus
appelé ETL, « Extract, transform and Load », les données sont extraites et stockées pour subir
les transformations nécessaires avant leur chargement.
Présentation des données : c’est l’entrepôt où les données sont organisées et stockées. Si les
données de la zone de préparation sont interdites aux utilisateurs, la zone de présentation est
tout ce que l’utilisateur voit et touche par le biais des outils d’accès.
L’entrepôt de données est constitué d’un ensemble de Data Mart. Ce dernier est défini
comme étant une miniaturisation d’un Data Warehouse, construit autour d’un sujet précis
d’analyse ou consacré à un niveau départemental3.
Cette différence de construction, autour d’un sujet ou au niveau départemental, définit
la façon d’implémentation du Data Mart au niveau de l’entrepôt. On distingue, en effet, deux
architectures internes du Data Warehouse :

1. Data Mart indépendant

Les Data Mart sont des versions miniaturisées du Data Warehouse au niveau départemental,
alimentées par le Data Warehouse et basées sur les besoins départementaux en informations [Inmon,
2002].

15
 Figure 5 : les Data Mart dans un entrepôt de données selon Warehouse (E.D.W)

2. Data Mart interconnectés

Les Data Mart sont construits autour de sujets, interconnectés grâce aux tables des faits contenues
dans le Data Warehouse, ce dernier se compose alors des Data Mart et ces
tables des faits, appelées bus.

Figure 6 : les Data Mart dans un entrepôt de données selon l’architecture bus de données [Kimball, 2002].

16
II.5 Architecture d’un Data Warehouse

Après avoir exposé et défini chacun des éléments constituant l’environnement d’un Data
Warehouse, il serait intéressant de connaitre le positionnement de ces éléments dans une
architecture globale d’un Data Warehouse :

Figure 7 : Architecture globale d’un Data Warehouse.

17
III. Modélisation des données de l’entrepôt

III.1 La modélisation dimensionnelle et ses concepts

Les Data Warehouse sont destinés à la mise en place de systèmes décisionnels. Ces systèmes, devant
répondre à des objectifs différents des systèmes transactionnels, ont fait ressortir très vite la nécessité
de recourir à un modèle de données simplifié et aisément compréhensible. La modélisation
dimensionnelle permet cela. Elle consiste à considérer un sujet d’analyse comme un cube à plusieurs
dimensions, offrant des vues en tranches ou des analyses selon différents axes.

Figure 8 : Considération d’un sujet d’analyse comme un cube à plusieurs dimensions.

En plus de la perception intuitive qu’offre la modélisation dimensionnelle, celle-ci est

réputée pour ses performances élevées.
La nomination « schéma des jointures en étoile » a longtemps été adoptée pour décrire
un modèle dimensionnel. Cette nomination est due au fait que le diagramme qui représente un
modèle dimensionnel ressemble à une étoile, avec une grande table centrale et un jeu de
petites tables auxiliaires disposées en étoile autour de la table centrale. Celle-ci est appelée
table de faits et les autres tables sont appelées tables de dimensions. La figure suivante
illustre untel modèle :

18
 Figure9 : un model dimensionnelle typique [ kimball, 1996]

III.1.1 Concept de fait

Une table de faits est la table centrale d’un modèle dimensionnel, où les mesures de
performances sont stockées. Une ligne d’une table de faits correspond à une mesure. Ces
mesures sont généralement des valeurs numériques, additives ; cependant des mesures
textuelles peuvent exister mais sont rares. Le concepteur doit faire son possible pour faire des
mesures textuelles des dimensions, car elles peuvent êtres corrélées efficacement avec les
autres attributs textuels de dimensions.
Une table de faits assure les liens plusieurs à plusieurs entre les dimensions. Elles
comportent des clés étrangères, qui ne sont autres que les clés primaires des tables de
dimension.

19
III.1.2 Concept de dimension

Les tables de dimension sont les tables qui raccompagnent une table de faits, elles
contiennent les descriptions textuelles de l’activité. Une table de dimension est constituée de
nombreuses colonnes qui décrivent une ligne. C’est grâce à cette table que l’entrepôt de
données est compréhensible et utilisable; elles permettent des analyses en tranches et en dés.
Une dimension est généralement constituée : d’une clé artificielle, une clé naturelle et
des attributs.
« Une table de dimension établit l’interface homme / entrepôt, elle comporte une clé
primaire » [Kimball, 2002].

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

Le tableau suivant récapitule les différences au niveau des données de ces tables :

Tableau I.2 : Tableau comparatif entre les tables de faits et les tables de dimensions.

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

III.2 Différents modèles de la modélisation dimensionnelle

Modèle en étoile : comme indiqué précédemment, ce modèle se présente comme une

étoile dont le centre n’est autre que la table des faits et les branches sont les tables de
dimension. La force de ce type de modélisation est sa lisibilité et sa performance.

Modèle en flocon : identique au modèle en étoile, sauf que ses branches sont éclatées
en hiérarchies. Cette modélisation est généralement justifiée par l’économie d’espace de
stockage, cependant elle peut s’avérer moins compréhensible pour l’utilisateur final, et très
couteuse en terme de performances.

Modèle en constellation : Ce n’est rien d’autre que plusieurs modèles en étoile liés
entre eux par des dimensions communes.

20
III.3 Le concept OLAP

III.3.1 Généralités

Le terme OLAP (On-Line Analytical Processing) désigne une classe de technologies

conçue pour l’accès aux données et pour une analyse instantanée de ces dernières, dans le but
de répondre aux besoins de Reporting et d’analyse.
R. Kimball définit le concept « OLAP » comme «Activité globale de requêtage et de
présentation de données textuelles et numériques contenues dans l’entrepôt de données; Style
d’interrogation spécifiquement dimensionnel » [Kimball, 2005].
C’est en continuant sur sa lancée, qui lui a permis de définir le model OLTP pour les
bases de données relationnelles, que le concept OLAP fut introduit et défini6 en 1993 par E.F
Codd, le père des bases de données relationnelles, dans un document technique portant le titre
de « Providing OLAP (On-Line Analytical Processing) to User-Analysts : An IT Man-date »
[Codd, 1993].

III.3.2 Architectures des serveurs OLAP

Le noyau d’un système OLAP est son serveur. Ces serveurs sont classés selon la politique
régissant l’architecture du serveur. Ainsi, ces architectures peuvent être distinguées comme
suit:

III.3.2.1 Les systèmes à architecture MOLAP

Ces systèmes MOLAP « Multidimentional On-line Analytical Processing » sont

conçus exceptionnellement pour l’analyse multidimensionnelle.
R. Kimball définit ces systèmes comme étant un « Ensemble d’interfaces utilisateur,
d’applications et de technologies de bases de données propriétaire dont l’aspect dimensionnel
est prépondérant » [Kimball, 2005].
Ainsi donc cette base adopte réellement la structure multidimensionnelle, exploitant de
ce fait ces capacités au maximum. En effet MOLAP offre des temps d’accès optimisés et cela
en prédéfinissant les opérations de manipulation et de chemin d’accès prédéfinis.
Autre caractéristique du MOLAP c’est qu’il agrège tout par défaut, pénalisant du coup
le système lorsque la quantité de données à traiter augmente. On parle généralement de
volume de l’ordre du giga-octet pas plus.

21
 Figure 10 : Principe de l’architecture MOLAP [Nakache, 1998].

III.3.2.2 Les systèmes à architecture ROLAP

« Ensemble d’interfaces utilisateurs et d’applications qui donnent une vision

dimensionnelle à des bases de données relationnelles » [Kimball, 2005].
Les systèmes ROLAP « Relationnel On-line Analytical Processing » sont en mesure
de simuler le comportement d’une SGBD multidimensionnel en exploitant un SGBD
relationnel. L’utilisateur aura ainsi l’impression d’interroger un cube multidimensionnel alors
qu’en réalité il ne fait qu’adresser des requêtes sur une base de données relationnelles.
ROLAP n’agrège rien. Les règles d’agrégations sont crées au préalable et représentées
dans une table relationnelle ce qui cause une lourdeur d’administration mais confère une
certaine performance et un gage de cohérence lors de l’utilisation.
Cette structure est généralement adoptée dans le but de se dispenser de l’acquisition
d’un SGBD relationne

III.2.2.3 Les systèmes à architecture HOLAP

Les systèmes HOLAP « Hybride On-line Analytical Processing » sont une sorte de
compromis entre les différents systèmes précités. Cette combinaison donne à ce type de
système les avantages du ROLAP et du MOLAP en utilisant tour à tour l’un ou l’autre selon
le type de données.

III.2.2.4 Autres architecture OLAP

Bien que les architectures évoquées ci-dessus soient les plus répandues et les plus
adoptées par les fournisseurs de solutions OLAP, d’autres systèmes se basent sur des
architectures différentes telles que l’architecture OOLAP « Object On-line Analytical
Processing », ou alors DOLAP « Desktop On-line Analytical Processing » qui décrit une
catégorie de produits qui ne sont pas nécessairement connectés à un serveur et qui s’appuient

22
sur une source de données (un cube) construites, stockées et exploitées en local sur la machine
de l’utilisateur.

III.4 La navigation dans les données

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

cube selon l’architecture du serveur », plusieurs opérations sont possibles sur ce dernier
offrant ainsi la possibilité de naviguer dans les données qui le constituent. Ces opérations de
navigation « Data Surfing » doivent être, d’une part, assez complexes pour adresser
l’ensemble des données et, d’autre part, assez simples afin de permettre à l’utilisateur de
circuler de manière libre et intuitive dans le modèle dimensionnel.
Afin de répondre à ces attentes, un ensemble de mécanismes est exploité, permettant
une navigation par rapport à la dimension et par rapport à la granularité d’une dimension.

III.4.1 Slice & Dice

Le « Slicing » et le « Dicing » sont des techniques qui offrent la possibilité de faire

des tranches « trancher » dans les données par rapport à des filtres de dimension bien précis,
se classant de fait comme des opérations liées à la structure « se font sur les dimensions ». La
différence entre eux se manifestent dans le fait que :
Le Slicing consiste à faire une sélection de tranches du cube selon des prédicats et selon une
dimension « filtrer une dimension selon une valeur » [Chouder, 2008].

Figure 11 : Exemple de Slicing.

Le Dicing, quant à lui, peut être vu comme étant une extraction d’un sous cube.

23
 Figure 12 : Exemple de Dicing.

III.4.2 Drill-down & Roll-up

Ces méthodes, appelées aussi « forage vers le bas/vers le haut », sont les méthodes lesplus répandues
pour une navigation dans un entrepôt de données. Elle consiste à représenter les données du cube à
un niveau de granularité inférieur, dans le cas du « Drill –down », ou un niveau supérieur, c’est le
« Roll-up ». En somme, ces deux opérations permettent de contrôler le niveau de détail des données
du cube.

Ces opérations ne sont pas aussi faciles à implémenter car basées sur la notion d’unebonne
hiérarchisation des attributs d’une dimension et la différenciation entre tous les niveaux de hiérarchie
disponibles dans les différentes dimensions.

24
 Figure 13 : Exemple de Drill-Down « plus de détails sur les régions ».

IV. Démarche de Construction d’un Data Warehouse

Plusieurs chercheurs ou équipes de recherche ont essayé de proposer des démarches

pour la réalisation d’un projet Data Warehouse, ces démarches se croisent essentiellement
dans les étapes suivantes :
• Modélisation et conception du Data Warehouse,
• Alimentation du Data Warehouse,
• Mise en oeuvre du Data Warehouse,
• Administration et maintenance du Data Warehouse,

25
IV.1 Modélisation et conception du Data Warehouse

Les deux approches les plus connues dans la conception des Data Warehouse sont :
• L’approche basée sur les besoins d’analyse,
• L’approche basée sur les sources de données,
Aucune des deux approches citées n’est ni parfaite, ni applicable à tous les cas. Toutes
deux doivent être étudiées pour choisir celle qui s’adapte le mieux à notre cas.
Quelque soit l’approche adoptée pour la conception d’un Data Warehouse, la
définition de celui-là reste la même. En étant un support d’aide à la décision, le Data
Warehouse se base sur une architecture dimensionnelle.

IV.1.1 Approche « Besoins d’analyse »

Le contenu du Data Warehouse sera déterminé selon les besoins de l’utilisateur final.
Cette approche est aussi appelée « approche descendante » (Top-Down Approach) et est
illustrée par R. Kimball grâce à son cycle de vie dimensionnel comme suit :

Figure 14 : illustration de l’approche « Besoins d’analyse » grâce au cycle de vie

dimensionnel de Kimball [Kimball, 2004].

26
 Tableau 3 : Avantages et inconvénients de l’approche « Besoins d’analyse ».
IV.1.2 Approche « Source de données »
Le contenu du Data Warehouse est déterminé selon les sources de données. Cette
approche est appelée : Approche ascendante (Bottom-up Approach).

Figure 15 : Illustration de l’approche « Source de données » grâce au cycle de développement du DW de

Inmon [Inmon, 2002].

Inmon considère que l’utilisateur ne peut jamais déterminer ses besoins dès le départ,
« Donnez moi ce que je vous demande, et je vous direz ce dont j’ai vraiment besoin », il
27
considère que les besoins sont en constante évolution.

Tableau 4 : Avantages et inconvénients de l’approche « Sources de données».

IV.1.3 Approche mixte

Une combinaison des deux approches appelée hybride ou mixte peut s’avérer efficace.
Elle prend en considération les sources de données et les besoins des utilisateurs.
Cette approche consiste à construire des schémas dimensionnels à partir des structures
des données du système opérationnel, et les valider par rapport aux besoins analytiques. Cette
approche cumule les avantages et quelques inconvénients des deux approches déjà citées,
telles que la complexité des sources de données et la difficulté quant à la détermination des
besoins analytiques.

Figure 16 : Illustration de l’approche mixte.

Cette étape aboutit à l’établissement du modèle dimensionnel validé du Data

28
Warehouse. Ce modèle dimensionnel sera transformé en modèle physique, qui différera du
modèle dimensionnel.

IV.2 Alimentation du Data Warehouse

Une fois le Data Warehouse conçu, il faut l’alimenter et le charger en données. Cette
alimentation (le plus souvent appelée processus ETL « Extract-Transform-Load ») se déroule
en 3 phases qui sont :
• Extraction des données primaires (issues par exemple des systèmes de production),
• Transformation des données,
• Le chargement des données traitées dans l’entrepôt de données, Ces trois étapes décrivent une
mécanique cyclique qui a pour but de garantir l’alimentation du Data Warehouse en données
homogènes, propres et fiables.

IV.2.1 Les phases de l’alimentation « E.T.L»

Les phases du processus E.T.L. représentent la mécanique d’alimentation du Data

Warehouse. Ainsi elles se déroulent comme suit :

a) L’extraction des données

« L’extraction est la première étape du processus d’apport de données à l’entrepôt de
données. Extraire, cela veut dire lire et interpréter les données sources et les copier dans la
zone de préparation en vue de manipulations ultérieures. » [Kimball, 2005].
Elle consiste en :
• Cibler les données,
• Appliquer les filtres nécessaires,
• Définir la fréquence de chargement,
Lors du chargement des données, il faut extraire les nouvelles données ainsi que les
changements intervenus sur ces données. Pour cela, il existe trois stratégies de capture de
changement :
• Colonnes d’audit : la colonne d’audit, est une colonne qui enregistre la date
d’insertion ou du dernier changement d’un enregistrement. Cette colonne est mise à jour soit
par des triggers ou par les applications opérationnelles, d’où la nécessité de vérifier leur
fiabilité.
• Capture des logs : certains outils ETL utilisent les fichiers logs des systèmes sources
afin de détecter les changements (généralement logs du SGBD). En plus de l’absence de cette
fonctionnalité sur certains outils ETL du marché, l’effacement des fichiers logs engendre la

29
perte de toute information relative aux transactions.

• Comparaison avec le dernier chargement : le processus d’extraction sauvegarde des

copies des chargements antérieurs, de manière à procéder à une comparaison lors de chaque
nouvelle extraction. Il est impossible de rater un nouvel enregistrement avec cette méthode.

b) La transformation des données

La transformation est la seconde phase du processus. Cette étape, qui du reste est très
importante, assure en réalité plusieurs tâches qui garantissent la fiabilité des données et leurs
qualités. Ces tâches sont :
• Consolidation des données.
• Correction des données et élimination de toute ambiguïté.
• Elimination des données redondantes.
• Compléter et renseigner les valeurs manquantes.
Cette opération se solde par la production d’informations dignes d’intérêt pour l’entreprise
et de et sont donc prêtes à être entreposées.

c) Le chargement des données

C’est la dernière phase de l’alimentation d’un entrepôt de données, le chargement est une
étape indispensable. Elle reste toutefois très délicate et exige une certaine connaissance des
structures du système de gestion de la base de données (tables et index) afin d’optimiser au
mieux le processus.

IV.2.2 Politiques de l’alimentation

Le processus de l’alimentation peut se faire de différentes manières. Le choix de la

politique de chargement dépend des sources : disponibilité et accessibilité. Ces politiques
sont8 :
• Push : dans cette méthode, la logique de chargement est dans le système de
production. Il " pousse " les données vers la zone de préparation quand il en a
l'occasion. L'inconvénient est que si le système est occupé, il ne poussera jamais les
données.

• Pull : contrairement de la méthode précédente, le Pull " tire " les données de la source
vers la zone de préparation. L'inconvénient de cette méthode est qu'elle peut
surcharger le système s'il est en cours d'utilisation.

• Push-pull : c'est la combinaison des deux méthodes. La source prépare les données à

30
envoyer et indique à la zone de préparation qu'elle est prête. La zone de préparation
va alors récupérer les données.

Aussi, le processus d’alimentation doit répondre à certaines exigences illustrées par la

figure suivante :

Figure 17 : Objectif de qualité de données dans un processus ETL [Kimball, 2004].

• Sûr : assure l’acheminement des données et leur livraison.
• Rapide : la quantité de données manipulées peut causer des lenteurs. Le processus
d’alimentation doit palier à ce problème et assurer le chargement du Data Warehouse dans des
délais acceptables.
• Correctif : le processus d’alimentation doit apporter les correctifs nécessaires pour
améliorer la qualité des données.
• Transparent : le processus de l’ETL doit être transparent afin d’améliorer la qualité des données.

IV.2.3 Les outils E.T.L.

Les outils E.T.L, en français E.T.C « Extraction-Transformation-Chargement » [Kimball,

2005], sont des outils qui garantissent la faisabilité et facilitent le déroulement des trois phases citées
précédemment. D’où leur importance dans un projet Data Warehouse.

31
IV.3 Mise en oeuvre du Data Warehouse

C’est la dernière étape d’un projet Data Warehouse, soit son exploitation. L’exploitation
du Data Warehouse se fait par le biais d’un ensemble d’outils analytiques développés autour
du Data Warehouse. Donc cette étape nécessite l’achèvement du développement, ou de la
mise en place, de ces outils qui peuvent accomplir les fonctions suivantes:
a. Requêtage ad-hoc :
Le requêtage ad-hoc reste très fréquent dans ce type de projet. En effet, les utilisateurs
de l’entrepôt de données, et spécialement les analystes, seront amenés à interagir avec le DW
via des requêtes ad-hoc dans le but de faire les analyses requises par leurs métiers et,
d’élaborer aussi, des rapports et des tableaux de bords spécifiques.
L’accès à ce genre de service peut se faire via différentes méthodes et outils.
Cependant, les spécialistes en la matière préconisent de laisser la possibilité à l’utilisateur de
choisir les outils qui lui paraissent les plus adéquats.
b. Reporting :
Destiné essentiellement à la production de rapports et de tableaux de bord, « il est la
présentation périodique de rapports sur les activités et résultats d'une organisation, d'une
unité de travail ou du responsable d'une fonction, destinée à en informer ceux chargés de les
superviser en interne ou en externe, ou tout simplement concernés par ces activités ou
résultants ».
Ces outils de Reporting ne sont pas, à proprement parler, des instruments d'aide à la
décision, mais, lorsqu’ils sont utilisés de manière appropriée, ils peuvent fournir une précieuse
vue d’ensemble.
Les rapports sont alors crées par le biais d’outils de Reporting qui permettent de leur
donner un format prédéterminé. Les requêtes sont constituées lors de l’élaboration des
rapports qui seront ensuite diffusés périodiquement en automatique ou ponctuellement à la demande.

c. Analyse dimensionnelle des données:

L’analyse dimensionnelle est sans doute celle qui exploite et fait ressortir au mieux les
capacités de l’entrepôt de données. Le but par l’analyse dimensionnelle est d’offrir aux
utilisateurs la possibilité d’analyser les données selon différents critères afin de confirmer une
tendance ou suivre les performances de l’entreprise.
Cette analyse se fait selon le principe OLAP, offrant de ce fait aux utilisateurs les
possibilités de recourir à différentes opérations facilitant la navigation dans les données. La
mise en place de ces outils est une option très intéressante dans la mesure où les données
32
seront accessibles en analyses instantanées. Plusieurs fournisseurs de solution OLAP existent
sur le marché et offrent des solutions construites sur des méthodes et technologies différentes.
C’est d’ailleurs pour cela que le choix de la solution doit se faire au préalable, selon les
besoins en utilisation, la taille de l’entrepôt et les moyens techniques disponibles.

d. Tableaux de bord :
Les tableaux de bord sont un outil de pilotage qui donne une vision sur l’évolution
d’un processus, afin de permettre aux responsables de mettre en place des actions correctives.
« Le tableau de bord est un ensemble d’indicateurs peu nombreux conçus pour
permettre aux gestionnaires de prendre connaissance de l’état et de l’évolution des systèmes
qu’ils pilotent et d’identifier les tendances qui les influenceront sur un horizon cohérent avec
la nature de leurs fonctions » [Bouquin, 2003].
Cette forme de restitution a la particularité de se limiter à l’essentiel, c'est-à-dire la
mise en évidence de l’état d’un indicateur par rapport à un objectif, tout en adoptant une
représentation graphique de l’information.

e. Data Mining :
Au sens littéral du terme, le Data Mining signifie le forage de données. Le but de ce
forage est d’extraire de la matière brute qui, dans notre cas, représente de nouvelles
connaissances. L’idée de départ veut qu’il existe dans toute entreprise des connaissances
utiles, cachées sous des gisements de données. Le Data Mining permet donc, grâce à un
certain nombre de techniques, de découvrir ces connaissances en faisant apparaître des
corrélations entre ces données.
Le Data Warehouse constituera alors la première source de données sur laquelle
s’exécutera le processus de découverte de connaissances. Dans la majeure partie du temps,
l’entrepôt de données représente un pré requis indispensable à toute fouille de données.
Le recours à ce genre de méthode est de plus en plus utilisé dans les entreprises
modernes. Les applications et outils implémentant ces solutions sont rarement développés en
interne. En effet, les entreprises préfèrent se reposer sur des valeurs sûres du marché afin
d’exploiter au plus vite les données en leur possession.

33
IV.4 Maintenance et expansion

La mise en service du Data Warehouse ne signifie pas la fin du projet, car un projet
Data Warehouse nécessite un suivi constant compte tenu des besoins d’optimisation de
performance et ou d’expansion. Il est donc nécessaire d’investir dans les domaines suivants
[Kimball, 2002] :

Support : assurer un support aux utilisateurs pour leur faire apprécier l’utilisation de
l’entrepôt de données. En outre, la relation directe avec les utilisateurs permet de détecter les
correctifs nécessaires à apporter.
Formation : il est indispensable d’offrir un programme de formation permanant aux
utilisateurs de l’entrepôt de données.
Support technique : un entrepôt de données est considéré comme un environnement
de production. Naturellement le support technique doit surveiller avec la plus grande vigilance
les performances et les tendances en ce qui concerne la charge du système.
Management de l’évolution : il faut toujours s’assurer que l’implémentation répond
aux besoins de l’entreprise. Les revues systématiques à certain point de contrôle sont un outil
clé pour détecter et définir les possibilités d’amélioration. En plus du suivi et de la maintenance du
Data Warehouse, des demandes d’expansion sont envisageables pour de
nouveaux besoins, de nouvelles données ou pour des améliorations.
Ces travaux d’expansion sont à prévoir de façon à faciliter l’évolution du schéma du
Data Warehouse.

V. Conclusion

Le concept « Data Warehouse » est apparu comme une réponse à des besoins grandissants dans le
domaine décisionnel. Son adaptabilité et sa capacité de fournir les données nécessaires à une bonne
analyse, ont fait de lui un atout majeur et incontournable pour toute entreprise soucieuse du suivi de
ces performances.
Afin de mettre en place ce genre de système, il est nécessaire de choisir et d’adopter une démarche
précise qui doit tenir compte des réalités de l’entreprise et des contraintes du projet. La modélisation
de l’entrepôt se fait dans tous les cas grâce à la modélisation dimensionnelle. L’alimentation en
données constitue l’étape à laquelle il faut accorder le plus d’attention et de temps. En effet, elle est
le garant de contenance de l’entrepôt en données fiables et correctes. Une fois l’alimentation
terminée, l’exploitation des données peut alors se faire par différentes méthodes. L’utilisation d’outil

34
OLAP reste, cependant, l’aspect le plus intéressant dans cette exploitation permettant la navigation
dans les données de l’entrepôt à la demande.
Au cours de la seconde partie de cette étude, nous allons essayer d’utiliser les concepts présentés
dans la synthèse bibliographique, et cela afin de mettre en oeuvre notresystème.

35
PARTIEII: Conception de la solution.

36
CHAPITRE I: l'existant décisionnel

I. Introduction

L’entreprise CELIA ALGERIE veut, par le biais de ce projet, palier à un manque important en
matière de décisionnel. Ce manque se caractérise par la quasi inexistence de support d’aide à la
décision, et l’indisponibilité de moyens de Reporting efficaces, en mesure de fournir des
informations adéquates en temps voulu.
Partant de ce constat, nous allons essayer, à travers ce chapitre, de présenter une analyse
aussi complète que possible de l’existant décisionnel de l’entreprise.
Ce chapitre a aussi pour but de faire connaître les procédures et les méthodes de Reporting et de prise
de décision, ainsi que les éventuelles lacunes qui peuvent exister.

II. Etat du décisionnel au sein de CELIA

Il est intéressant de signaler que l’entreprise, ne dispose d’aucun système d’aide à la décision
automatique ou semi-automatique. Aussi, tout processus d’analyse et de prise de décision à tous les
niveaux se base essentiellement sur des rapports dont les données sont extraites et consolidées à partir
des systèmes transactionnels d’une manière manuelle. Des rapports quotidiens sous format Excel ,
émis différemment par chaque service avec des métriques et des dimensions non unifiées.

III. Conclusion

Cette étude nous permet d’avoir une vision générale des procédures d’élaboration des rapports et de
consolidation des données. Elle constitue aussi le point de départ pour définir le périmètre du projet
en général et de l’étude des besoins en particulier. Elle fait ressortir les insuffisances du système
actuel en soulignant les points faibles ou les goulots d’étranglements de ce dernier.
Le chapitre suivant consacré à l’étude des besoins, aidera à détecter ceux des utilisateurs de manière à
pouvoir y répondre.

37
 CHAPITRE II: étude des besoins

I. Introduction
Tout Data Warehouse doit être en mesure de répondre aux attentes des utilisateurs.
Cela ne peut, évidemment, se faire sans une étude approfondie de leurs besoins.

L'application exclusive de l’une de ces deux approches ne produit nullement des résultats
satisfaisants. La démarche généralement adoptée est une démarche mixte, qui allie
entre les deux précédentes dans un souci de prise en considération des besoins des décideurs
sans perdre de vue toute possibilité et opportunité offerte par les données sources. Cette
approche permet donc de recueillir, corriger et de modérer les attentes des utilisateurs dès le
départ, tout en détectant d'éventuels besoins non exprimés.

Durant l’étude des besoins on ne peut se limiter aux interviews avec les utilisateurs, néanmoins, il
faudrait absolument prendre en compte l’avis de l’administrateur de base de donnes des systèmes
sources « Les DBA sont les principaux experts sur les applications existantes susceptibles
d'alimenter l’entrepôt de données, Leurs interviews servent à confronter aux réalités certains des
thèmes qui surgissent lors des rencontres avec les utilisateurs finaux. » [Kimball, 96]

Figure 18 : La place de l’étape d’étude des besoins dans un projet Data Warehouse.

Ce chapitre a pour principale vocation d’exposer et de décrire la démarche adoptée

pour la détection des besoins ainsi que la présentation de la synthèse qui en sera faite.

38
I.1 Description de la démarche d'étude des besoins

Afin de faire une étude aussi complète que possible, nous avons choisi d'adopter une
démarche qui nous a permis de combiner, d’une manière assez satisfaisante, entre l'approche
« Buttom Up » et l'approche « Top Down ».
Ainsi, notre démarche peut se résumer au travers des étapes suivantes:
• Étude préliminaire des systèmes sources et interviews sommaires avec les DBA,
• Détection des postes susceptibles d'être porteurs d'informations utiles,
• Planification, préparation et conduite des interviews:
• Utilisation d’autres moyens pour la détection des besoins,
• Rédaction et validation du recueil récapitulatif des besoins,

a. Étude préliminaire des systèmes sources et interviews sommaires avec les DBA
b. Détection des postes susceptibles d'être porteurs d'informations utiles
c. Planification, préparation et conduite des interviews

39
Rédaction et validation du recueil récapitulatif des besoins

L’étude des besoins nous a permis de recenser les besoins que nous avons classés par
volets spécifiques. Ils peuvent être présentés de la manière suivante :

Ref Volet Détecté Besoins enregistrés (Les critères d’analyse)

Utilisateurs : ce volet a été évoqué et sollicité à tous
les niveaux et pardifférents postes. Cependant les
utilisateurs des services Commerciaux et marketing,
de l'ADV et CDG ont exprimé un vif intérêt pour ce
volet. Besoins : Les utilisateurs ont besoin de
1 Analyser le volume de vente connaître l’évolution des ventes (en tonne et en
chiffre d’affaires brute ) dans le temps YTD, semaine ,
mois, trimestre, semestre,ans Versus : YTD des
années précédentes , MTD des années …ect

Utilisateurs : tous les niveaux et par différents postes

Besoins : ce volet contient les informations CA Brut ,
NN , Remises, Ristournes pour chaque client,
2 Analyse du chiffre d’affaires
Réalisation YTD, semaine , mois, trimestre,
semestre,ans. Versus : YTD des années précédentes ,
MTD des années …ect

Utilisateurs : tous les niveaux et par différents postes

3 L'analyse des Produits Besoins : L'analyse par Famille, sous famille et SKU
Volume en KG , Prix moyen/kg

Utilisateurs : ADV,CDG
Besoins : ce volet contient Retour / Avoir (par
4 Analyse : Retour / Avoir
volumes , en CA ) par Client et produit et par région
par wilaya.
Utilisateurs : tous les niveaux et par différents postes
5 Analye des clients Besoins: Objectf par client versus réalisation par
période
Utilisateurs : CDG , ADV, CODIR
Suivre périodiquement les écarts entre Besoins: Comparatif réalisations en cours Versus
6
réalisation et prévision forecast (par région et par produit & CA)

Utilisateurs : ADV, supply, CDG

Besoins : générés et transmis automatiquement les
Assurer le reporting et l’analyse rapports avec la périodicité souhaitée, tous les jours,
7
hebdomadaire toutes les semaines ou tous les mois.

Tableau 5 : Synthétisation des besoins recensés.

40
I.2 Problèmes et obstacles rencontrés

Bien que notre étude des besoins ait donné lieu aux résultats escomptés, à savoir leur
identification et leur prise en charge, il n’empêche que le travail ne s’est pas effectué sans
obstacles, dont les plus importants sont :
Difficulté de planifier les entretiens à cause de :
- La charge de travail qui nous incombe,
- L’emploi du temps chargé des interviewés,
• L’indisponibilité de personnes concernées par les entretiens et les annulations de
dernière minute,
• Les résistances au changement,( Obliger les utilisateurs à saisir certains champs dans l'ERP) • La
rétention d’informations sous couvert de confidentialité,
• L’appréhension, par les utilisateurs, du projet et de sa faisabilité,

II. Conclusion

L’étude des besoins est une étape plus que nécessaire dans un projet Data Warehouse.
C’est, en effet, à partir de cette étude que se décidera la manière de construction de l’entrepôt
de données et de son architecture.
Cette étude des besoins s’est déroulée sur quinze entretiens et a concerné quinze personnes occupant
différents postes à des niveaux hiérarchiques différents. Les entretiens ont duré plus de 9 heures et
nous ont permis tout d’abord d’appliquer les méthodes d’analyse et de collecte d’information. et aussi
de connaître plus de détails sur les rouages de l’entreprise et d’identifier les besoins analytiques de
l’entreprise.
Les besoins étant recensés, la construction du Data Warehouse peut alors commencer.
Cette construction fera l’objet du chapitre suivant.

41
 Chapitre IV : Conception de la solution

I. Introduction

Une fois les besoins des utilisateurs connus, nous pouvons commencer à concevoir les volets de notre
Data Warehouse. Pour cela, nous avons eu recours à la modélisation dimensionnelle qui est souvent
associée aux entrepôts de données compte tenu de ses avantages.

Cependant, avant de se lancer dans la modélisation, il est intéressant de classer les sujets recensés
selon l’intérêt qu’ils représentent pour l’entreprise et les facilités de réalisation. Ce classement nous
aidera à choisir l’activité à modéliser en premier lieu de manière à garantir des résultats satisfaisants
pour l’entreprise.

II. Processus de la modélisation dimensionnelle

Figure 19 : Processus de la modélisation dimensionnelle

42
 Chapitre IV: Conception des cubes dimensionnels.

Introduction

Afin de faciliter l’analyse et la navigation dans les données, il est important que les
cubes dimensionnels soient bien conçues et définis de manière claire pour une utilisation
intuitive.
La conception des cubes dimensionnels passe par la définition des mesurables, des
dimensions et des hiérarchies présentes au sein des dimensions, ainsi que les différents
niveaux de détails de chaque hiérarchie. Le but de la mise en place de ces cubes est d’offrir
une représentation abstraite d'informations multidimensionnelles à des fins d’analyse.
Le choix des cubes à construire, des mesurables qu’ils contiendront, des dimensions
participantes dans chacun d’entre eux et des hiérarchies qui constituera chaque dimension
dépend essentiellement des besoins recensés et de l’utilisation finale.

I. Définition des niveaux et des hiérarchies

La définition des différentes hiérarchies présente dans une dimension est une étape cruciale et
indispensable pour la conception des cubes. En effet, c’est grâce à ces hiérarchies que l’utilisateur
pourra naviguer et explorer à bon escient les informations offertes par un cube donné.
Cette étape se déroule en deux phases:
 Identification des attributs d’un même niveau pour chaque dimension.
 Construction des hiérarchies (Une dimension peut avoir plusieurs hiérarchies).

43
II. Présentation des cubes dimensionnels « cube vente »

Figure 20 : Présentation des cubes dimensionnels « cube vente »

III. Conclusion

Les cubes dimensionnels est une étape très importante dans tout projet Data Warehouse.
C’est grâce à cette dernière que l’utilisateur pourra utiliser et exploiter au mieux les données
contenues dans l’entrepôt de données de manière correcte et intuitive.
Dans ce chapitre nous avons essayé donc de définir les cubes dimensionnels en
explicitant les dimensions participantes dans chacun d’entre eux. Ensuite nous avons défini,
pour chacune des dimensions, les différentes hiérarchies présentes ainsi que les niveaux qui
composent ces dernières.

44
Evolution de la Business Intelligence

45
 I. Evolution de la Business Intelligence

Figure 21 : Evolution de la Business Intelligence

Evolution de la Business Intelligence en 4 étapes

Le marché de la Business Intelligence ne cesse d’évoluer. Voici les 4 étapes majeures dans
l’évolution de la Business Intelligence :

1) DW et ETL
De l’extraction des données de l’Entreprise pour la construction des fameux « Data Warehouse »
ou « Entrepôts de données » grâce aux outils ETL (Extraction, Transformation, Loading)

Exemple outils : Talend, Oracle Data Integrator, IBM DataStage, Informatica, SAP Data Services,
Microsoft SSIS, OpenText, Pentaho

2) La BI Entreprise
A partir des années 90 :

 Apparition de logiciels graphiques

 Développement du concept des couches sémantiques (Vue métier ou Univers)

 Apparition des fonctionnalités de type « glisser-déposer » (ou « drag-and-drop »)

46
 Le reporting opérationnel et l’analyse multi dimensionnelle OLAP peuvent alors se développer pour
couvrir les besoins standards ‘BI’ dans les Entreprise

Exemple outils : SAP WebIntelligence et Crystal Reports , JetReports

3) La BI Agile
La BI Agile répond à des nouveaux besoins :

 Plus d’autonomie pour les utilisateurs

 Outil Intuitif avec des temps de formation très court

 Des nouveaux concepts de visualisations des données (data visualisation)

 Gestion de gros volumes de données

L’’utilisateur doit pouvoir expérimenter, changer de point de vue, manipuler les données, pour mettre
en lumière les tendances ou les écarts constatés.

Exemple outils : SAP Lumira

4) L’analyse prédictive
A partir de données historiques réelles et d’algorithmes statistiques complexes, l’analyse prédictive
est capable de proposer une représentation future des données.

Exemple outils : SAP Predictive Analytics

II. La Self-service BI

Généralement, la Business Intelligence traditionnelle est un projet stratégique ayant pour but de
consolider les informations disponibles au sein des bases de données d’une entreprise.

Cette notion regroupe, entre autres, des solutions informatiques permettant de créer des rapports et
des tableaux de bord analytiques.

La Self-service BI est avant tout une orientation de marché dont l’idée est de donner du pouvoir aux
utilisateurs pour qu’ils puissent construire eux-mêmes leur modèle d’analyse (et par extension, leurs
solutions décisionnelles). Traditionnellement, faire un projet de BI nécessite de solliciter le service
informatique (ou de faire un appel d’offre), de rédiger un cahier des charges et de confier cela à des
développeurs, avec des délais de mise en place parfois longs. L’objectif de la Self-service BI est de
donner de l’autonomie aux utilisateurs dans la réalisation de solutions décisionnelles. Par exemple,
un analyste financier qui disposerait des données sur l’ERP et qui souhaiterait en connaitre l’impact

47
sur l’évolution des crédits à la consommation, n’aura plus besoin de passer par le service
informatique.

Les utilisateurs finaux ont besoin d’obtenir des réponses rapidement, notamment en période de crise.
De ce fait, ils doivent pouvoir manipuler facilement les données et prendre des décisions rapidement,
d’autant plus que certaines de ces analyses ne sont souvent faites qu’à titre informatif.

Une opportunité pour les entreprises qui doit être bien appréhendée

Malgré les nombreux avantages que représente la Self-service BI, le plus grand risque réside en sa
mauvaise utilisation. Effectivement, il est par exemple, possible d’imaginer une situation où des
milliers d’utilisateurs ont chacun leur propre analyse des ventes de la société. Pour éviter ce type de
scénario, où les utilisateurs se retrouvent avec une multitude de données non exploitables, il est
important d’uniformiser les outils et les process.

Pour ce faire, il est nécessaire :

• de mettre en place une bonne gouvernance sur la gestion de la Self-service BI au sein de

l’entreprise, à l’image de l’utilisation d’un outil comme Jet Entreprise.
• d’équilibrer la répartition entre Self-service BI et Corporate-BI (la Business Intelligence
traditionnelle, gérée par l’IT).

Un modèle juste et pertinent, développé par un utilisateur, peut être étendu par l’IT et mis à
disposition de tous, respectant ainsi la sécurité et la capacité de montée en charge.

L’autre point de vigilance autour de la Self-service BI est la qualité des données. En effet, cette
discipline est essentielle pour pouvoir mixer des sources « certifiées » de l’entreprise avec des
sources plus ou moins « exotiques ». Il faut s’assurer de la pertinence et de l’exactitude des données
car le résultat des analyses en découleront.

Ne pas négliger la formation

Il est également très important de ne pas négliger la formation des utilisateurs, car même si l’usage
est simple, il est crucial d’appréhender les codes de la Business Intelligence mais aussi des choses
plus techniques comme le langage DAX (différent des formules Excel) ou encore Data Explorer. Par
exemple, un outil comme PowerPivot se découvre en moins d’une journée, toutefois, il faut quelques
jours de pratique pour maîtriser des formules de calculs plus complexes.
48
En conclusion, il est indéniable que la Self-service BI est une tendance forte du marché ces dernières
années, certes occultée depuis environ un an par le Big Data qui est assez connexe finalement.
Néanmoins, cet usage est bien présent dans les préoccupations des directions métiers (et donc des
Directeurs des Systèmes Informatiques). Aujourd’hui, les technologies sont matures et font donc
l’objet d’un large déploiement auprès des entreprises

Conclusion générale et perspectives

Exploiter les données à disposition de l’entreprise afin de leur donner de la valeur

ajoutée, tel est le défi des entreprises modernes.
Dans ce cadre, et afin de palier à des problèmes récurrents dans le processus de prise
de décision, CELIA a initié le projet de réalisation d’un Data Warehouse pour permettre

la mise en place d’un système décisionnel fiable et efficace.

Tout au long de notre travail de conception et de réalisation, nous avons essayé de
suivre une démarche mixte, alliant de ce fait entre Deux approches connues dans le domaine
du Data Warehousing, à savoir l’approche « Besoins d’analyse » et l’approche « Sources de
données ». Cette démarche a permis de répondre aux attentes et besoins des utilisateurs tout
en exploitant au mieux les données générées par les systèmes opérationnels de manière à
anticiper sur des besoins non exprimés.

49
Liste des Figures

Figure 1 : Le décisionnel au sein du Système d’information……………….………………..10

Figure 2 : Les différentes composantes du décisionnel………………………………………11
Figure 3 : évolution des bases de données décisionnelles……………………………………13
Figure 4 : Structure des données d’un Data Warehouse……………………………………...14
Figure 5 : les Data Mart dans un entrepôt de données selon Warehouse………………….....16
Figure 6 : les Data Mart dans un entrepôt de données selon l’architecture bus de données 16
Figure 7 : Architecture globale d’un Data Warehouse…………………………………….....17
Figure 8 : Considération d’un sujet d’analyse comme un cube à plusieurs dimensions……..18
Figure 9 : un model dimensionnelle typique………………………………………………….19
Figure 10 : Principe de l’architecture MOLAP……………………………………………….22
Figure 11 : Exemple de Slicing……………………………………………………………….23
Figure 12 : Exemple de Dicing……………...…………………………………….……… ..24
Figure 13 : Exemple de Drill-Down…………… ……………………………..………….…..25
Figure 14 : illustration de l’approche Besoins d’analyse……………………………………..26
Figure 15 : Illustration de l’approche « Source de données » Inmon ………….……..……..27
Figure 16 : Illustration de l’approche mixte…………………………………………………..28
Figure 17 : Objectif de qualité de données dans un processus ETL………………….………31
Figure 18 : La place de l’étape d’étude des besoins dans un projet Data Warehouse………...37
Figure 19 : Processus de la modélisation dimensionnelle……………………………………..41
Figure 20 : Présentation des cubes dimensionnels « cube vente » ……………………...……43
Figure 21 : Evolution de la Business Intelligence………………………………………………………....45

Liste des Tableaux :

Tableau 1 : comparatif entre les systèmes transactionnels et les systèmes décisionnels…… ….12
Tableau 2 : comparatif entre les tables de faits et les tables de dimension…………….…….….20
Tableau 3 : Avantages et inconvénients de l’approche « Besoins d’analyse »……………….....26
Tableau 4 : Avantages et inconvénients de l’approche « Sources de données»…………….…..27
Tableau 5 : Synthétisation des besoins recensés……………………………………………..….39

50
Bibliographie
Ouvrages
[Kimball, 2004] : R. Kimball et J. Caserta ; « The Data warehouse ETL Toolkit» ;Wiley
Publisshing, INC 2004

[Data warehouse 2016] : Stéphane Crozat ; « ntroduction à lamodélisation dimensionnelle »

Articles et Thèses
Site officel JetReports : https://jetsupport.jetreports.com/hc/en-us/articles/219401567-Server-Environment-
Configurations

https://stoneridgesoftware.com/what-is-a-data-warehouse/

https://reussirsonprojetbi.wordpress.com/2016/03/16/les-grands-principes-dun-projet-par-cycles-iteratifs/

https://jetsupport.jetreports.com/hc/en-us/articles/221031088-Jet-Web-Portal-Overview-Installation-setup-
and-use

https://www.usherbrooke.ca/cefti/fileadmin/sites/cefti/documents/Essais/Essai_Etienne_Rivard_-_Final_-
_Revision_CeFTI.pdf

Abréviations :
BI : Business Intelligence.
DAP : Direction Analyses et Prévision.
DBA : Data Base Administrator.
DCF : Direction Comptabilité et Finance.
DCM: Direction Commercial Et Marketing.
DIM : Dimension.
DW : Data Warehouse (Entrepôt de données).
EDW : Entreprise Data Warehouse.
ETL : Extract, Transform and Load (ETC).
FK: Foreign Key.
FTP : File Transfer Protocol.
HOLAP: Hybrid On Line Analytical Process.
MOLAP: Multidimensional On Line Analytical Process.
OLAP : On Line Analytical Process.
OLTP: On Line Transactional Process.
PK : Primary Key.
ROLAP : Relational On Line Analytical Process.
SI : Systèmes d’Information.
SID: Systèmes d’Information Décisionnels.
SIAD : Systèmes d’Information d’Aide à la Décision
SGBD : Système de Gestion de Base de Données.
SQL : Structured Query Language

51