Université d’Antananarivo

Domaine Sciences et Technologies

Mention Mathématiques et Informatique

Mémoire en vue de l’obtention du diplôme de Master 2 en

Mathématiques Informatique et Statistique Appliquées

Conception et mise en place d’un DATA WAREHOUSE à

partir des bases de données d’un guichet unique électronique

Présenté le 14 Juin 2019 par :

M. Andriniaina ANDRIAMANOELISON

Devant le jury composé de :

Président du jury : M. Joelson Solofoniaina Université d’Antananarivo

Examinateur : M. Tahiry Andriamarozakaniaina Université d’Antananarivo

Encadreur : M. Joseph Rakotondralambo Université d’Antananarivo

Co-Encadreur : M. Solonantenaina Rakotorahalahy Gasynet

Remerciements

Je voudrais témoigner toute ma reconnaissance à plusieurs personnes qui m’ont

aidé et soutenu durant la réalisation de ce mémoire.

Tout d’abord, je remercie Dieu de m’avoir toujours guidé jusqu’à présent et ma

famille et mes amis qui m’ont encouragé et aidé.

Je remercie aussi Monsieur Stéphane MANOUVRIER, Directeur des projets et

opération informatique au sein de la société GasyNet, pour m’avoir confié un tel projet
me permettant d’acquérir beaucoup d’expériences et d’approfondir mes connaissances.

Je tiens aussi à remercier Solonantenaina Rakotorahalahy, mon encadreur

professionnel, et mes collègues dans le département informatique de la société pour
m’avoir guidé et aidé à résoudre tous les problèmes que j’ai rencontré durant le stage.

Mes remerciements s’adressent aussi aux membres de jury qui ont accepté de
juger mon travail et à tout le corps enseignant de la MISA pour avoir partagé ses
compétences qui m’ont été d’une grande utilité durant tous ces temps passés en
entreprise.

A tous ces intervenants, je présente mes remerciements, mon respect et ma

gratitude.
Table des matières

Généralités ..................................................................................................................................................... 10

1.1. Contexte de stage ................................................................................................................................... 10

1.1.1. La société Gasynet .................................................................................................................................. 10

1.1.2. La MISA ................................................................................................................................................. 10

1.2. Les systèmes décisionnels ....................................................................................................................... 10

1.2.1. La place du décisionnel dans l’entreprise ................................................................................................... 11

1.2.2. Systèmes décisionnels vs systèmes transactionnels ................................................................................... 12

1.3. Le Data Warehouse ................................................................................................................................. 14

1.3.1. Introduction ............................................................................................................................................. 15

1.3.2. Architecture d’un Data Warehouse ............................................................................................................ 16

1.3.3. Les différentes notions liées à l’entreposage de données ............................................................................ 17

Démarche de construction d’un Data Warehouse .......................................................................................... 22

2.1. Conception et modélisation ...................................................................................................................... 22

2.2. Le concept OLAP .................................................................................................................................... 26

2.3. Alimentation du Data Warehouse .............................................................................................................. 34

Implémentation ............................................................................................................................................. 37

3.1. Outils et technologies............................................................................................................................... 37

3.2. Implémentation ....................................................................................................................................... 38

3.3. Le suivi des rapports ................................................................................................................................ 42

Liste des tableaux

Décisionnel vs Transactionnel ..................................................................................................... 14

Différence DW et Datamart ........................................................................................................ 18
Datamart dépendant et Datamart indépendant ........................................................................ 19
Inmon vs Kimball : les caractéristiques majeures ....................................................................... 23
Architecture serveur OLAP .......................................................................................................... 27
Différence entre SQL et MDX ...................................................................................................... 34
Synthétisation des besoins recensés .......................................................................................... 39
Table des figures

Processus Business Intelligence .................................................................................................. 12

Data Warehouse ......................................................................................................................... 16

Architecture générale Data Warehouse ..................................................................................... 17

Exemple modélisation Data Warehouse ..................................................................................... 21

Modèle en étoile ......................................................................................................................... 24

Modèle en constellation ............................................................................................................. 25

Modèle en flocons....................................................................................................................... 25

Cube OLAP ................................................................................................................................... 28

Slicing .......................................................................................................................................... 29

Dicing........................................................................................................................................... 30

Roll-up ......................................................................................................................................... 30

Drill-down.................................................................................................................................... 31

Pivot ............................................................................................................................................ 32

Exemple requête MDX ................................................................................................................ 33

Processus ETL .............................................................................................................................. 36

Intégration avec Talend .............................................................................................................. 40

Définition d’un cube avec Jaspersoft schéma workbench .......................................................... 41

Exemple de rapport..................................................................................................................... 42

Interface demande de rapport.................................................................................................... 43

Notification nouveau demande .................................................................................................. 44

Notification demande annulée ................................................................................................... 44

Notification demande terminée ................................................................................................. 45
Liste des abréviations

BD Base de Données.

BI Business Intelligence.

BSC Bureau de Suivi des Cargaisons.

DAU Document Administratif Unique.

DW Data Warehouse (Entrepôt de données).

ETL Extract, Transform, Load.

HOLAP Hybrid On-Line Analytical Processing.

IDE Integrated Development Environment.

MDX MultiDimensional eXpressions.

MIDAC Ministères, Départements et Agences de Contrôle.

MOLAP Multidimensional On-Line Analytical Processing.

MVC Modèle Vue Contrôleur.

OLAP On-Line Analytical Processing.

OLTP On-Line Transaction Processing.

OV Ordre de Validation.

PG Prestation GasyNet.

PDI Pentaho Data Integration.

ROLAP Relational On-Line Analytical Processing.

SGBD Système de Gestion de Base de Données.

TOS Talend Open Studio.

Préambule

Que ce soit pour une importation ou une exportation, toute personne physique ou
morale doit déclarer sa marchandise à la douane malagasy avant de pouvoir exécuter son
opération dans tout le pays. Auparavant, les déclarations en détails de ces marchandises
étaient faites par écrit impliquant la lenteur de la procédure de dédouanement. Mais en 2007,
le Gouvernement malagasy et la SGS-Société Générale de Surveillance S.A. ont signé un
partenariat public-privé et ont créé la société Malagasy Community Network Services S.A. ou
GasyNet afin de faciliter le commerce extérieur et d’accélérer le processus de dédouanement.

Parmi les activités de la société, il y a le déploiement et la gestion du système

informatique TradeNet, un système électronique qui regroupe sur une plateforme commune
toutes les entités prenantes au commerce international et permet l’acheminement, la
distribution et l’intégration électronique des données dans un environnement sécurisé. Le but
est de mettre en place un dédouanement informatisé éliminant un certain nombre d’étapes et
de documents.

Pour ce faire, la société a besoin d’outils qui offrent une vue d’ensemble des différentes
transactions qui ont eu lieu au fil du temps de manière à diminuer le délai de dédouanement.
Les données traitées jusqu’à présent sont énormes, du coup les outils traditionnels utilisés par
les salariés actuels nécessitent beaucoup de temps surtout au niveau des créations et émissions
des rapports.

D’où le besoin de concevoir et mettre en place un Data Warehouse qui sera le principal
objectif de ce projet. Bref, ce travail va contribuer à l’accélération du mécanisme de
traitement des déclarations des marchandises à la douane malagasy au sein de la société
GasyNet.

Ce mémoire s’articule en quatre parties principales : la première expliquant la place du

décisionnel dans l’entreprise et la différence entre un système transactionnel et un système
décisionnel. La deuxième parlera de l’entrepôt de données et de tout ce qu’il y a autour. La
troisième décrira la démarche de construction du Data Warehouse de la conception à la
navigation dans les données et son alimentation. Enfin, le dernier chapitre sera dédié à
l’implémentation de la solution.
Chapitre 1

Généralités

1.1. Contexte de stage

Avant d’aborder le sujet, présentons d’abord la société d’accueil et mon centre de

formation

1.1.1. La société Gasynet

GasyNet - Malagasy Community Network Services S.A. - est une société de droit
malgache née d'un partenariat public privé entre le gouvernement malagasy et la société SGS
- Société Générale de Surveillance dont les activités sont axées sur une utilisation poussée des
technologies de l'information. Avec le déploiement de la plateforme TradeNet, GasyNet
apporte non seulement une simple solution technologique mais une solution complète de
facilitation du commerce international.

1.1.2. La MISA

La MISA est une formation à vocation professionnalisant créée en 1996 au sein du

Département Mathématiques et Informatique de la Faculté des Sciences de l’Université
d’Antananarivo.
Le but de cette formation est de rehausser les compétences des étudiant en mathématiques et
administration d’entreprises en utilisant à bon escient les nouvelles technologies issues du
progrès, à savoir, l’informatique et l’internet. Elle forme des cadres d’entreprise maîtrisant les
outils statistiques et informatiques.

1.2. Les systèmes décisionnels

Avant d’entamer la partie conception d’un Data Warehouse, il serait judicieux de définir
quelques concepts clés autour du décisionnel puisque la construction d’un Data Warehouse
conduit à la mise en place d’un système décisionnel dans une entreprise. Dans cette partie, on
fait appel au Business Intelligence.
1.2.1 La place du décisionnel dans l’entreprise

1.2.1. La place du décisionnel dans l’entreprise

L’informatique décisionnelle (en anglais business intelligence (BI)) est l’informatique à

l’usage des décideurs et des dirigeants d’entreprises [1]. Elle s’adresse à la direction générale
tout comme aux métiers, c’est un outil d’aide à la décision.

Elle est mise en place pour aider à analyser les données, pour obtenir des informations
sur les différents canaux d’affaires et de les utiliser pour identifier les opportunités et à
améliorer l’efficacité.

En bref, l’informatique décisionnelle n’a d’autre objectif que d’assister le processus de

décision en vigueur dans l’organisation. Le business intelligence peut être envisagé comme
une transition transparente des données en information puis en action [2].

Chaque entreprise peut déployer sa stratégie de différentes manières selon sa culture

d’entrepreneuriat et les problèmes qu’elle rencontre.

Les différentes phases du processus

Les points les plus importants du processus restent les mêmes quelque soient les entreprises :

 L’extraction de l’information des différents systèmes d’informations de l’organisation

comme les données venant des bases transactionnelles (Oracle, PostgreSQL, Access,
…), des fichiers Excel, des mails, …
 La transformation des données avant leur stockage dans l’entrepôt car beaucoup de ces
informations sont de mauvaise qualité.
 Les différentes analyses, la création des rapports, data mining, …

Andriniaina Andriamanoelison 11
1.2.2 Systèmes décisionnels vs systèmes transactionnels

Figure 1 Processus Business Intelligence

L’entrepôt rassemble les données issues de plusieurs sources, ces données sont
fusionnées. Après que l’entrepôt soit fini d’être confectionné, les données qui ont été
transformés sont extraites dans des serveurs d’analyse ou serveurs OLAP sous forme de cubes
de données pour être analysées. Finalement, des générateurs d’états sont exploités pour
montrer l’étude aux utilisateurs finaux ou décideurs.

1.2.2. Systèmes décisionnels vs systèmes transactionnels

Un entrepôt de données est une collection de données où toutes les informations

transactionnelles d’une organisation sont stockées, mais il n’est pas le même que la base de
données transactionnelle. La principale différence est que ce dernier est conçue et optimisée
pour stocker des données, alors que les entrepôts de données sont conçus et optimisés pour
répondre aux questions d’analyse qui sont essentielles pour les entreprises.

Les systèmes OLTP aussi nommés systèmes opérationnels sont dédiés aux travaux de
l’entreprise pour les aider dans leurs tâches de gestion journalières et donc directement
opérationnels. Dans un système OLTP, les données ne sont conservées que sur une courte
période ; elles sont détaillées, personnelles, identifiées et représentent généralement en termes
de quantité quelques centaines de mégaoctets, voir certains giga-octets.

Andriniaina Andriamanoelison 12
1.2.2 Systèmes décisionnels vs systèmes transactionnels

Les systèmes décisionnels autant connus par systèmes OLAP sont consacrés au
management de l’entreprise pour le soutenir au pilotage de l’activité, et dès lors par quelques
chemins détournés opérationnels, proposant au décideur une vision transversale de
l’entreprise. Les données sont historisées et peuvent être agrégées, anonymes. Les
informations entreposées dans un DW sont dites statiques et ne sont pas faites pour être
changées. Ceci est fondamental pour la simple et bonne raison que ces informations sont
utilisées pour analyser l’organisation, ce qui reste dur à faire si l’information stockée continue
de changer. La base peut atteindre des volumes immenses.

Une autre différence entre système décisionnel et transactionnel est que les utilisateurs
des DW sont des utilisateurs tels que des analystes et des gestionnaires [1] contrairement à
ceux des BD transactionnels qui peuvent être des simples employés au sein d’un département.

Le tableau ci-dessous récapitule les différences entre un système transactionnels et un

Data Warehouse.

Andriniaina Andriamanoelison 13
1.3 Le Data Warehouse

Différence Systèmes transactionnels Data Warehouse

Orienté applications Orienté thèmes et sujets

Données détaillées et codées non Informations agrégées cohérentes

redondantes souvent avec redondance
Les données

Données changeantes constamment Informations stables et

synchronisées dans le temps

Mises à jour et requêtes simples Lecture unique et requêtes

complexes transparentes

Faibles volumes à chaque Large volume manipulé

Usage
transaction

Pour l’activité quotidienne Analyse et prise de décision

Conçue pour la mise à jour Conçue pour l’extraction

Utilisateurs Un département (employé) Analystes, gestionnaires

Tableau 1 Décisionnel vs Transactionnel

1.3. Le Data Warehouse

L’entrepôt de données est au cœur de l’analyse décisionnelle. C’est un facteur important

pour l’intelligence des affaires. Dans cette partie, nous allons définir ce que c’est un Data
Warehouse, la structure et architecture de ses données.

Andriniaina Andriamanoelison 14
1.3.1 Introduction

1.3.1. Introduction

Définition : Bill Inmon, l’un des pionniers du domaine définit le DW dans son livre
« Building the Data Warehouse » comme suit : « Un entrepôt de données est une collection de
données orientées sujet, intégrées, non volatiles et historisées, organisées pour le support d’un
processus d’aide à la décision. »

 Orienté sujet : le DW est organisé autour des sujets majeurs de l’entreprise. Les
données dans un système opérationnel sont essentiellement destinées à satisfaire un
processus fonctionnel et obéissent à des règles de gestion, tandis que celles d’un DW
sont destinées à un processus analytique.
 Intégrées : les données proviennent de différentes sources, de la plupart ou la totalité
des applications de l’organisation.
 Evolutif dans le temps : les différentes modifications apportées aux données dans la
base sont suivies et enregistrées, cela permet les comparaisons et le suivi de
l’évolution des valeurs dans le temps.
 Non volatile : une donnée dans un environnement DW ne peut être mise à jour ou
supprimée contrairement à celle d’un environnement opérationnel.

C’est une vision regroupée et universelle de toutes les informations de l'entreprise, une
structure qui a pour objectif, à l’inverse des bases de données, de regrouper les données de
l'entreprise pour des fins analytiques et pour permettre d’avoir des bonnes décisions
stratégiques. Pour résumé, c'est une grande quantité d'informations épurées, organisées,
historisées et provenant d’une multitude de sources de données, servant aux analyses et
support à la décision.

C’est une étape clé pour la construction d’une architecture technologique informatisée
au service du processus de prise de décision dans l’entreprise.

Andriniaina Andriamanoelison 15
1.3.2 Architecture d’un Data Warehouse

Figure 2 Data Warehouse

Les élements d’un Data Warehouse

L’environnement du DW est constitué essentiellement de quatre composantes :

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

l’entreprise et dont l’objectif est de garantir le fonctionnement et la performance de
celui-ci. Ces applications restent extérieures au DW.
 Organisation des données : la préparation englobe les étapes entre l’extraction des
données des applications actives jusqu’à sa présentation aux usagers. Elle est
constituée d’un ensemble de processus appelé ETL.
 Présentation des données : c’est la zone où les données sont organisées et conservées.
Les utilisateurs peuvent accéder aux données via cette zone.
 Les outils d’accès aux données : ce sont les outils permettant aux utilisateurs d’accéder
aux données de l’entrepôt.

1.3.2. Architecture d’un Data Warehouse

Le schéma ci-dessous représente l’architecture générale du Data Warehouse :

Andriniaina Andriamanoelison 16
1.3.3 Les différentes notions liées à l’entreposage de données

Figure 3 Architecture générale Data Warehouse

Généralement, un entrepôt de données adopte une architecture à trois niveaux :

 Niveau inférieur ou Bottom Tier : composé généralement du système de base

de données relationnel de l’entrepôt. Les programmes d’applications et les
utilitaires ETL sont utilisés pour fournir les données au niveau inférieur.
 Niveau intermédiaire ou Middle Tier : le niveau où se trouve le serveur OLAP
implémenté par deux modèles OLAP relationnel (ROLAP) et OLAP
multidimensionnel (MOLAP).
 Niveau supérieur ou Top Tier : c’est la couche client. Elle contient les outils
de requête et les outils de génération de rapports, les outils d’analyse et les outils
d’exploration des données.

1.3.3. Les différentes notions liées à l’entreposage de données

Voici quelques définitions sur les termes qui entourent un Data Warehouse.

1.2.3.1. Datamart

Définition : Un Datamart est un sous-ensemble d’un DW destiné à fournir des données

aux utilisateurs, et souvent spécialisé vers un groupe ou un type d’affaire [5]. Il s’agit d’un
extrait de l’ensemble des données d’une entreprise, ne contenant que le nécessaire.

Andriniaina Andriamanoelison 17
1.3.3 Les différentes notions liées à l’entreposage de données

Quelques exemples de Datamart :

 Datamart commercial
 Datamart RH
 Datamart financier

Les Datamarts sont généralement plus petits et moins complexes que les entrepôts de
données ; par conséquent, ils sont généralement plus faciles à construire et à entretenir. Le
tableau suivant récapitule les différences de base entre un DW et un Datamart :

Différence Data Warehouse Datamart

Portée Entreprise Département

Sujet Plusieurs Sujet unique

Les sources de données Beaucoup Peu

Tableau 2 Différence DW et Datamart

Les trois types de Datamart sont : Datamart dépendant, Datamart indépendant et

Datamart hybride. La catégorisation est principalement basée sur la source de données qui
alimente le Datamart.

Un Datamart dépendant permet de réunir les données de l’organisation dans un entrepôt

de données. Sa création améliore les performances et la disponibilité, améliore le contrôle et
réduit les coûts de télécommunication grâce à l’accès local aux données pertinentes pour un
service spécifique. Cela donne les avantages habituels de la centralisation.

Un Datamart indépendant est créé sans l’utilisation d’un entrepôt de données centralisé.
Sa création est souvent motivée par la nécessité de trouver une solution dans un délai plus
court. C’est pour les petits groupes au sein d’une organisation.

La principale différence entre Datamart dépendant et indépendant est la manière de

remplissage du magasin de données (comment extraire les données des sources et les stocker
dans le Datamart) comme le montre le tableau ci-dessous :

Andriniaina Andriamanoelison 18
1.3.3 Les différentes notions liées à l’entreposage de données

Datamart dépendant Datamart indépendant

Identifier le bon sous-ensemble de données Gérer tous les aspects du processus ETL
correspondant au sujet du Datamart dans comme pour faire un DW central mais
l’entrepôt central déjà construit et faire une concentré sur un seul sujet
copie

Tableau 3 Datamart dépendant et Datamart indépendant

Un Datamart hybride permet de combiner les entrées provenant de sources autres qu’un
entrepôt de données. Il combine simplement les problèmes des deux autres types de
Datamarts évoqués ci-dessus.

1.2.3.2. Dimension et hiérarchie

Définition : Une dimension est une structure qui classe les faits et les mesures afin de
permettre aux utilisateurs de répondre à des questions professionnelles [6]. Dans l’entrepôt de
données, elle est une collection d’information de référence sur un évènement mesurable.

Une table de dimension est une table qui contient les axes d’analyse selon lesquels on
veut étudier des données observables qui, soumises à une analyse multidimensionnelle,
donnent aux utilisateurs des renseignements nécessaires à la prise de décision. Elle contient
les détails sur les faits, les informations descriptives des valeurs numériques de la table de
faits.

Quelques exemples de Dimension :

 Dimension Temps
 Dimension Client
 Dimension Produit

Définition : Une hiérarchie est une organisation logique des membres d’une dimension
de manière hiérarchique.

Par exemple, une hiérarchie pour la dimension Temps : le plus haut niveau serait
l’année, contiendrait le mois, puis la semaine, puis le jour et ainsi de suite.

Andriniaina Andriamanoelison 19
1.3.3 Les différentes notions liées à l’entreposage de données

1.2.3.3. Fait et mesure

Définition : Les faits sont le sujet de l’analyse. Ils représentent des tables qui
contiennent des informations opérationnelles et qui retracent la vie de l’entreprise.

Les faits dans un entrepôt de données doivent être quantitatifs. Il peut s’agir du montant
des ventes, du nombre d’unités vendues d’un produit.

Une table de faits contient les valeurs numériques de ce qu’on désire mesurer, les clés
associées aux dimensions.

Définition : Une mesure est un indicateur numérique représentant une grandeur. C’est
un calcul analytique exécuté sur des données stockées afin de produire des résultats pouvant
être lus sous la forme d’états ou analysés pour faciliter la prise de décision.

Exemple le chiffre d’affaire ou le prix d’un produit.

Les dimensions, hiérarchies, faits et mesures sont utilisés dans la modélisation d’un DW
ou un Datamart comme la montre la figure ci-dessous :

Andriniaina Andriamanoelison 20
1.3.3 Les différentes notions liées à l’entreposage de données

Figure 4 Exemple modélisation Data Warehouse

Andriniaina Andriamanoelison 21
Chapitre 2

Démarche de construction d’un Data Warehouse

La conception des modèles de données dans un DW est une étape importante qui
nécessite une approche différente de celle utilisée lors de la conception de systèmes
opérationnels. Il est aussi important de savoir comment naviguer dans l’entrepôt et comment
l’alimenter.

2.1. Conception et modélisation

2.1.1. Conception

Les deux méthodes les plus connues dans la conception d’un entrepôt de données sont
les approches introduites par Bill Inmon « top-down » et Ralph Kimball « bottom-up ».

Inmon est reconnu par beaucoup comme étant le père du Data Warehouse, il a contribué
à la définition de ses fondements. Selon son point de vue, le DW sera déterminé en fonction
des besoins de l’utilisateur final. Concevoir un modèle de données normalisé en premier et
ensuite créer à partir de cet entrepôt les données dimensionnelles qui contiennent les données
requises pour les processus métiers spécifiques aux départements.

Ralph Kimball est un informaticien et chef d’entreprise américain qui a écrit plusieurs
ouvrages informatiques, notamment concernant les sujets liés au décisionnel. Son approche
pour la conception d’un DW s’oppose à celle d’Inmon, un DW doit être rapide et
compréhensible. Le contenu du DW est déterminé selon les sources de données [3].

Le tableau ci-dessous illustre la différence entre ces deux approches.

2.1 Conception et modélisation

Inmon Kimball

Commence par la conception du modèle de Commence par la conception du modèle

DW dimensionnel pour les Datamarts

Architecture composée d’un staging area Architecture qui consiste en un staging area
permanent, d’un DW et de Datamarts et de Datamarts, le DW physique n’existe
dépendants pas

Le DW est orienté entreprise et les Les Datamarts contiennent les données

Datamarts sont orientés processus atomiques et agrégées

Le DW contient les données atomiques ; les Les Datamarts peuvent fournir une vue
Datamarts et les données agrégées entreprise ou processus

Le DW utilise un modèle normalisé de toute Les Datamarts sont implémentés de façon

l’entreprise ; les Datamarts utilisent des incrémentale et intégrée en utilisant les
données dimensionnelles orientés sujet dimensions conformes

Les utilisateurs peuvent effectuer des

requêtes sur le DW et les Datamarts

Tableau 4 Inmon vs Kimball : les caractéristiques majeures

Il existe aussi une approche hybride qui combine ces deux approches. Elle consiste à
concevoir un modèle de données de l’entreprise en même temps que les modèles spécifiques.

Les approches citées ne sont ni parfaites, ni applicable à tous les cas. La meilleure
approche dépend des activités de l’entreprise et de ses objectifs.

2.1.2. Modélisation dimensionnelle

Un modèle dimensionnel est le résultat d’une analyse des besoins et d’une analyse des
données disponibles. Il définisse le grain, les dimensions et les faits correspondants aux
processus d’affaires de la société.

Un DW peut être modélisé en 2 types de modèle dimensionnel :

Andriniaina Andriamanoelison 23
2.1 Conception et modélisation

 Le modèle en étoile
 Le modèle en flocon de neige

Le modèle en étoile doit son nom à sa forme comme une étoile dont le centre est la table des
faits et les branches sont les tables de dimension. Les dimensions sont directement reliées à un
fait. Les dimensions sont dé-normalisées afin de concentrer toutes les informations en une
seule table. Cela implique que certaines colonnes aient plusieurs fois les mêmes valeurs.

Figure 5 Modèle en étoile

S’il y a plusieurs modèles en étoile liés entre eux par des dimensions communes, le nouveau
modèle constitué sera appelé modèle en constellation.

Andriniaina Andriamanoelison 24
2.1 Conception et modélisation

Figure 6 Modèle en constellation

Le modèle en flocon est une variante du modèle en étoile, plus adapté pour des usages bien
spécifiques. Il existe des hiérarchies de dimensions et elles sont reliées à un fait. Dans le
modèle en flocon, les dimensions sont normalisées. Au lieu de tout concentrer en une seule
table, on a plusieurs tables liées en une arborescence, chaque niveau de la hiérarchie donnant
lieu à une table.

Figure 7 Modèle en flocons

Le modèle en étoile est plus souvent choisi comme le plus performant en raison du fait
qu’il y a moins de jointures à faire que sur un modèle en flocons. Cependant, si la dimension a
de nombreux attributs, la table prendra plus d’espace pour le modèle en étoile.

Andriniaina Andriamanoelison 25
2.2 Le concept OLAP

2.2. Le concept OLAP

Définition : le traitement analytique en ligne (en anglais On-Line Analytical

Processing, OLAP) est un type d’application informatique orienté vers l’analyse sur le champ
d’informations selon plusieurs axes, dans le but d’obtenir des rapports de synthèse tels que
ceux utilisés en analyse financière [4].

Architecture OLAP

L’architecture d’un OLAP est constituée de trois parties :

 La base de données : un support de données agrégées ou résumées possédant une

structure multidimensionnelle c’est-à-dire basée sur un SGBD multidimensionnel ou
relationnel.
 Le serveur OLAP : permet la gestion de la structure multidimensionnelle dans le SGBD
et la gestion d’accès aux données de la part des utilisateurs.
 Le module client : permet à l’utilisateur de manipuler et d’exploiter les données, permet
aussi l’affichage des données sous formes de graphiques ou de tableau.

L’architecture du serveur OLAP qui est le noyau de son système peut être distinguée de
plusieurs manières :

 MOLAP : le Multidimensionnel OLAP stocke aussi bien les données que les agrégats
dans une structure multidimensionnelle entraînant la performance des requêtes et la
réduction des temps de réponse. L’inconvénient est que le traitement de la partition est
consommateur de ressources.
 ROLAP : le Relationnel OLAP stocke aussi bien les données que les agrégats dans la
base de données relationnelle source. Il est lent pour répondre aux requêtes. Le
traitement est cependant léger car moins de consommation de ressources.
 HOLAP : l’Hybride OLAP stocke les données dans la base relationnelle source et les
agrégats dans une structure multidimensionnelle. Il présente un compromis entre
MOLAP et ROLAP combinant les avantages des deux architectures. Les temps de
réponse dépendent des requêtes et des données à récupérer.

Le tableau ci-dessous désigne la spécificité technique des trois serveurs OLAP :

Andriniaina Andriamanoelison 26
2.2 Le concept OLAP

ROLAP MOLAP HOLAP

Stockage des BD relationnelle BD BD relationnelle

données de base multidimensionnelle

Stockage des BD relationnelle BD BD relationnelle

agrégations multidimensionnelle

Structure de la Modèle particulier (étoile Structure propriétaire Croisement des

base de données flocon, …) au logiciel utilisé architectures
ROLAP et
MOLAP

Fonctionnement Le serveur extrait les Le serveur MOLAP Accède aux deux

données par des requêtes extrait les données de BD et les présente
SQL et interprète les l’hyper cube et les au module client
données selon une vue présente directement au selon leur
multidimensionnelle module client méthode
avant de les présenter au respective
module client

Performance des Le moins performant Le plus performant Performance

requêtes moyenne

Tableau 5 Architecture serveur OLAP

D’autres systèmes se basent sur d’autres architectures différentes mais ce sont les
architectures évoquées ci-dessus qui sont les plus répandues et les plus adoptées par les
fournisseurs de solutions OLAP.

Andriniaina Andriamanoelison 27
2.2 Le concept OLAP

La navigation dans le cube OLAP

Le DW a une structure multidimensionnelle qui traite un sujet d’analyse comme un

cube à plusieurs dimensions, offrant des vues en tranches ou des analyses selon différents
axes. Son exploitation se fait par la technologie OLAP souvent appelée « cube OLAP ».

Définition : un cube OLAP est une structure de données supérieure aux bases de
données relationnelles grâce à une analyse rapide des données.

Pour naviguer dans les données de l’entrepôt, un serveur OLAP va construire un cube
multidimensionnel ou simuler ce cube selon l’architecture du serveur.

Figure 8 Cube OLAP

Le cube permettra de stocker les informations et de les lier à plusieurs dimensions de

manière à pouvoir effectuer des analyses en fonction de celles-ci. La navigation dans le cube
consiste principalement à passer d’un niveau d’agrégation à un autre.

Mécanisme d’exploitation

Les outils OLAP utilisent des opérations particulières pour la navigation dans les hyper
cubes :

 Slice
 Dice
 Drill-up
 Drill-down
 Pivot

Andriniaina Andriamanoelison 28
2.2 Le concept OLAP

2.2.1. Slice

L’opération slice sélectionne des données en appliquant un critère de sélection à une

dimension pour passer à un sous-cube. Elle aide l’utilisateur à visualiser et à rassembler les
informations spécifiques à une dimension.

Figure 9 Slicing

2.2.2. Dice

L’opération dice sélectionne des données en appliquant une sélection sur plusieurs
dimensions. Elle est semblable à slice mais fonctionne un peu différemment. En slice, le
filtrage est fait pour se concentrer sur un attribut particulier tandis qu’en dice, il est davantage
une fonction de zoom qui sélectionne un sous-ensemble pour toutes les dimensions mais pour
des valeurs spécifiques de la dimension.

Andriniaina Andriamanoelison 29
2.2 Le concept OLAP

Figure 10 Dicing

2.2.3. Drill-up (Roll up)

L’opération drill-up permette de passer d’une mesure détaillée à un résumé en

remontant dans la hiérarchie de la dimension, c’est-à-dire, naviguer vers une granularité plus
grossière.

Figure 11 Roll-up

2.2.4. Drill-down (roll down)

Le drill-down est l’inverse du drill-up, qui permette de descendre dans la hiérarchie de

la dimension, i.e. naviguer vers une granularité plus fine.

Andriniaina Andriamanoelison 30
2.2 Le concept OLAP

Figure 12 Drill-down

2.2.5. Pivot

L’opération pivot fait pivoter les axes de données pour afficher les données de
différentes perspectives.

Andriniaina Andriamanoelison 31
2.2 Le concept OLAP

Figure 13 Pivot

Toutes ces méthodes sont utilisées pour présenter les informations dans le DW de
diverses manières utiles et différentes.

Langage de requêtes

Les BD relationnels utilisent le SQL comme langage de requêtes mais les cubes OLAP
ont ses propres langages. C’est un langage de calcul avec une syntaxe similaire à celle des
tableurs.

Il n’y a pas de langage universel mais le plus utilisé est le MDX qui a été inventé par
Mosha Pasumansky au sein de Microsoft et fut présenté pour la première fois en 1997.

Andriniaina Andriamanoelison 32
2.2 Le concept OLAP

Figure 14 Exemple requête MDX

La syntaxe de MDX est remarquablement similaire à la syntaxe de SQL, et la

fonctionnalité fournie par MDX est également similaire à celle de SQL.

Cependant, il existe des différences majeures entre les deux langages. La principale
différence est la capacité de MDX à référencer plusieurs dimensions. MDX fournit des
commandes conçues spécifiquement pour extraire des données en tant que structures de
données multidimensionnelles avec un nombre quelconque de dimensions.

Andriniaina Andriamanoelison 33
2.3 Alimentation du Data Warehouse

Différence SQL MDX

Dimensions Deux dimensions Plusieurs dimensions

Clause SELECT Pour définir la disposition des Pour définir les axes
colonnes pour une requête

Clause WHERE Pour filtrer les données Pour fournir une tranche des
renvoyées par une requête données renvoyées par une requête

Visualisation des Intuitive Non intuitive

résultats

Tableau 6 Différence entre SQL et MDX

2.3. Alimentation du Data Warehouse

L’intégration des données d’un DW est capitale pour une entreprise en raison que si les
données entreposées dans le DW ne sont pas correctes ou non mises à jour, les décisions
prises par la société seront fausses. L’intégration des données définit le processus
d’alimentation du DW.

Ce processus est appelé ETL « Extract-Transform-Load » et se déroule en 3 phases :

 Extraction des données,

 Transformation des données,
 Chargement des données traitées

2.3.1. L’extraction des données

L’extraction consiste à extraire des données des systèmes sources de l’organisation pour
les utiliser ultérieurement dans l’entrepôt. C’est la première étape du processus ETL.

Andriniaina Andriamanoelison 34
2.3 Alimentation du Data Warehouse

La conception et la création du processus d’extraction est souvent l’une des tâches les
plus fastidieuses du processus ETL et, en fait, de tout le processus d’entreposage de données.

Les systèmes sources peuvent être très complexes et peu documentés, ce qui rend
difficile la détermination des données à extraire.

Les données doivent être extraites normalement non seulement une fois, mais plusieurs
fois de manière périodique pour fournir toutes les données modifiées à l’entrepôt et le
maintenir à jour. De plus, les systèmes sources ne peuvent généralement pas être modifiés et
ses performances ou ses disponibilités ne peuvent pas être ajustées pour répondre aux besoins
du processus d’extraction du DW.

L’extraction des données dépend fortement des systèmes sources et aussi des besoins de
l’entreprise.

2.3.2. La transformation des données

Après l’extraction, les données sont transformées avant d’être stockées dans le DW.
Elle consiste à convertir des données d’un format ou d’une structure dans un autre format ou
une autre structure.

Les transformations peuvent être complexes et, en termes de temps de traitement, la

partie la plus couteuse du processus ETL. Ils peuvent aller de simples conversions de données
à des techniques extrêmement complexes de nettoyage de données.

2.3.3. Le chargement des données

C’est la dernière phase du processus ETL qui consiste à charger les données nettoyées
durant la phase précédente dans le DW. Elle dépend en grande partie de l’utilisation finale des
données une fois chargées dans l’entrepôt.

Le processus ETL met à jour le magasin de données avec les nouveaux enregistrements
dans les bases de données sources.

Andriniaina Andriamanoelison 35
2.3 Alimentation du Data Warehouse

Figure 15 Processus ETL

Andriniaina Andriamanoelison 36
Chapitre 3

Implémentation

Pour la réalisation et la mise en place de la solution, il a été nécessaire de recouvrir à un

certain nombre d’outils. Une présentation de ces logiciels et applications serait donc
judicieuse avant de développer toutes les étapes de la création du DW.

3.1. Outils et technologies

3.1.1. Talend open studio TOS

Les outils d’ETL automatisent totalement la création, la maintenance et l’extension des

entrepôts de données. Chaque outil fonctionne différemment et a ses points forts et points
faibles.

Après une étude comparative, le choix a été porté sur « Talend open studio » un outil
ETL 100% Open Source et gratuit. C’est un outil facile à prendre en main. L’inter-
connectivité entre toute source de données existante (des SGBD ou des fichiers plats, …)
représente un avantage non négligeable. De plus Talend offre une grande souplesse
d’utilisation fonctionnant sur du Java et on peut ajouter nos propres codes.

3.1.2. TIBCO Jaspersoft Studio et JasperReports Server

L’interface entre l’utilisateur et le DW est constituée d’un ensemble d’outils permettant

aux utilisateurs d’exploiter le système mis en place dans les meilleures conditions possibles.
Cet ensemble est composé de deux logiciels open source et gratuit.

TIBCO Jaspersoft Studio est un logiciel qui aide à concevoir et à exécuter des modèles
de rapport ; écrire des expressions complexes ; mettre en page des composants visuels tels que
des graphiques, cartes, tableaux, tableaux croisés [7].

TIBCO JasperReports Server est un serveur de reporting qui fournit des rapports et des
analyses pouvant être intégrés à une application Web ou mobile. JasperReports Server est
optimisé pour partager, sécuriser et gérer de manière centralisée les rapports Jaspersoft et les
vues analytiques [8]. Elle contient un moteur ROLAP « Mondrian » pour implémenter les
cubes conçus pour l’analyse multidimensionnelle.
3.2 Implémentation

Talend et Jasper possèdent tous les deux une plateforme communautaire pour les
développeurs améliorant leur capacité à collaborer, obtenir une assistance technique, partager
leur expertise.

3.1.3. NetBeans IDE

NetBeans est un environnement de développement intégré (ou IDE en anglais), open source
permettant de développer des applications avec plusieurs langage de programmation. L’IDE
est orientée pour supporter plusieurs projets simultanément.

3.2. Implémentation

L’analyse des besoins

Le DW est construit pour répondre aux attentes des utilisateurs. Cela ne peut,
évidemment, se faire sans une étude approfondie de leurs besoins.

La société possède sept (7) départements qui utilisent les données venantes du guichet
unique électronique, l’analyse des besoins s’est donc faite sur ces différents départements de
la société.

Andriniaina Andriamanoelison 38
3.2 Implémentation

Département Activité principale

Audit Analyse et réconciliation des DAU

BSC Suivi des cargaisons à destination de Madagascar

Civio Contrôle des véhicules d’occasions importés à Madagascar

MIDAC Conciliation de la facilitation du commerce légitime et de la mission

régalienne de contrôle

Réconcilliation Recouvrement de paiement PG

Profiler Evaluation des risques sur les données anticipées des marchandises et
suggestion d’un canal de dédouanement adéquat de manière à atténuer les
risques tout en facilitant le commerce légitime

Statistique Fourniture des rapports statistiques

Tableau 7 Synthétisation des besoins recensés

Chaque entretien a grandement aidé à l’identification des exigences des utilisateurs mais
les usagers ne peuvent pas savoir tous leurs besoins. Néanmoins l’étude des rapports déjà
existants a contribué à la détection des besoins.

Après avoir synthétisé les besoins recueillis, on a modélisé un Datamart indépendant

pour chaque département.

L’étape ETL

La base de données du DW a été implémenté sous le SGBD Oracle. Cette SGBD est
connue pour ses performances par rapports aux bases de données volumineuses.

Andriniaina Andriamanoelison 39
3.2 Implémentation

Figure 16 Intégration avec Talend

Pour garder l’entrepôt à jour, le processus ETL est planifié à intervalles réguliers. Le
transfert des données des bases de données de production vers le DW a lieu toutes les nuits où
il n’y a pas de transaction.

Conception des cubes dimensionnels

Chaque département aura son propre cube pour effectuer ses analyses. Le tableau
suivant donne le détail de la conception des cubes :

Afin de pouvoir spécifier au serveur quels sont les dimensions et les faits (parce que les
cubes utilisés ont une architecture ROLAP), on a utilisé jaspersoft schéma workbench pour la
création des schémas des cubes.

Le Jaspersoft Schéma Workbench est un logiciel intégré dans JasperReports Server,

utilisé pour créer et tester visuellement les schémas des cubes Mondrian OLAP et a pour
résultat un fichier XML.

Andriniaina Andriamanoelison 40
3.2 Implémentation

Figure 17 Définition d’un cube avec Jaspersoft schéma workbench

Une fois les cubes conçus, l’interface utilisateur Jaspersoft OLAP intégrée dans
JasperReports Server associe les schémas, la source de données et les requêtes MDX dans des
vues d’analyse interactives, offrant aux utilisateurs finaux les rapports et les analyses dont ils
ont besoin pour prendre de meilleures décisions [10].

L’élaboration du rapport est facile et intuitive, tout comme la navigation dans le cube de
données. Grâce à Jaspersoft OLAP on peut accéder rapidement et facilement aux données via
une interface Web. Explorer les données en pivotant, en filtrant, en visualisant et en
définissant des alertes en fonction des valeurs des données. Prendre des décisions
commerciales éclairées en identifiant les tendances, les anomalies et les corrélations dans les
données.

Voici un exemple de rapport rendu au département Audit

Andriniaina Andriamanoelison 41
3.3 Le suivi des rapports

Figure 18 Exemple de rapport

Il s’agit de la répartition des déclarations liquidées par liquidateur, déclarant,

importateur et bureau de dédouanement.

3.3. Le suivi des rapports

Les chefs des départements utilisent les reporting pour superviser les actions et résultats
de l’organisation que ce soit en interne ou en externe. Ces rapports sont définis selon un
format prédéterminé et sont publiés et diffusés périodiquement suivant la demande des
utilisateurs.

Toutefois, il est possible pour un département ou une personne du département de

demander un rapport à l’équipe responsable des données.

Pour cela, on a développé une application web pour gérer ces demandes et aussi avoir
une traçabilité.

Andriniaina Andriamanoelison 42
3.3 Le suivi des rapports

Figure 19 Interface demande de rapport

L’application

L’application a été développée avec le Framework1 du langage de programmation PHP,

CodeIgniter sous sa version 3.1.9. CodeIgniter suit le motif de conception MVC. C’est très
pratique de développer des applications de gestion avec ce Framework.

L’utilisateur de cette application peut créer, modifier, envoyer et annuler une demande.

Pour créer une demande, l’utilisateur remplisse les informations sur le rapport (titre,
description, champs demandé) grâce à un formulaire. Les colonnes demandeur et date de la
demande sont remplis automatiquement par le login de l'utilisateur et la date d’enregistrement
de cette demande.

Après avoir créé une demande, cette dernière sera stockée dans une base de données
avec un statut vide. Les actions Envoyer et Annuler sont en fonction de ce statut :

 Envoyer : si le statut de la demande est « vide » ou « annulé ». Quand l’utilisateur

décide d’envoyer sa demande (en cliquant sur , l’équipe responsable des données
reçoivent un mail automatique à propos de la demande.

1
Un Framework désigne un ensemble cohérent de composants logiciels structurels, qui sert à créer les
fondations ainsi que les grandes lignes de tout ou d’une partie d’un logiciel.

Andriniaina Andriamanoelison 43
3.3 Le suivi des rapports

Figure 20 Notification nouveau demande

 Annuler : si le statut de la demande est « en attente ». Si l’utilisateur choisit d’annuler

sa demande (en cliquant sur , l’équipe responsable des données reçoivent un mail
automatique indiquant que l’utilisateur a annulé sa demande.

Figure 21 Notification demande annulée

Dès qu’une personne de l’équipe a fini de traité la demande, elle va alerter les autres membres

avec l’application (en cliquant sur ). Le statut de la demande sera alors « terminé » et
aucune action ne pourra plus lui être faite.

Andriniaina Andriamanoelison 44
3.3 Le suivi des rapports

Figure 22 Notification demande terminée

Andriniaina Andriamanoelison 45
Conclusion

La société GasyNet utilise beaucoup de données qui sont dispersées sur plusieurs bases
de données. L’intégration de ces données dans un Data Warehouse a permis de les regrouper
et de les rendre homogènes après quelques transformations. Ces données sont intégrées dans
l’entrepôt à l’aide du logiciel Talend. Les informations sont présentées de manière intuitive
grâce à l’interface web de JasperReports Server.

A travers ce travail de conception et de réalisation, nous avons pu constater qu’utiliser

une approche mixte est plus avantageux pour répondre aux attentes des utilisateurs tout en
exploitant au mieux les données générées par les systèmes opérationnels afin de pouvoir
anticiper des besoins non exprimés. La modélisation en étoile reste une façon très efficace
d’organiser les données pour des fins d’analyse. Les technologies OLAP facilite le reporting
et le traitement des données.

L’objectif qui a été d’instaurer un Data Warehouse pour contribuer à l’accélération du

mécanisme de traitement des déclarations des marchandises à la douane malagasy au sein de
la société GasyNet a donc été atteints. Toutefois, une des principales raisons de l'échec d'un
projet d'entrepôt de données est le manque d’entretien. Sans entretien adéquat, les résultats
souhaités sont presque impossibles à atteindre depuis l’entrepôt.
Références

BIBLIOGRAPHIE

[1] B. Azvine, Z. Cui, D; D. Nauck, Towards real-time business intelligence, BT Technology Journal,
23(3), 2005.

[3] W. H. Inmon, Building the Data Warehouse, 1992.

WEBOGRAPHIE

[4] «2 approches pour construire un Data Warehouse,» [En ligne]. Available:

https://www.aerow.group/a16u1509/. [Accès le 1 Mai 2018].
[12] «CodeIgniter User Guide,» [En ligne]. Available: https://www.codeigniter.com/user_guide/.
[Accès le 21 Juillet 2018].
[10] «Creating an Analysis View,» [En ligne]. Available:
https://community.jaspersoft.com/wiki/jaspersoft-olap-creating-analysis-view. [Accès le 2 Juin
2018].
[6] «Datamrt,» [En ligne]. Available: https://fr.wikipedia.org/wiki/Datamart. [Accès le 1 Mai 2018].
[11] «Datawarehouse: Cubes OLAP,» [En ligne]. Available: https://docplayer.fr/1312053-
Datawarehouse-cubes-olap-marlyse-dieungang-khaoula-ghilani.html. [Accès le 12 Juin 2018].
[7] «Dimension,» [En ligne]. Available: https://en.wikipedia.org/wiki/Dimension_(data_warehouse).
[Accès le 1 Mai 2018].
[2] «Informatique décisionnelle,» [En ligne]. Available:
https://fr.wikipedia.org/wiki/Informatique_décisionnelle. [Accès le 20 Avril 2018].
[13] «Référence MDX,» [En ligne]. Available: https://docs.microsoft.com/fr-
fr/sql/mdx/multidimensional-expressions-mdx-reference?view=sql-server-2017. [Accès le 01
Août 2018].
[9] «TIBCO JasperReports Server,» [En ligne]. Available:
https://community.jaspersoft.com/project/jasperreports-server. [Accès le 12 Juin 2018].
[8] «TIBCO Jaspersoft Studio,» [En ligne]. Available:
https://community.jaspersoft.com/project/jaspersoft-studio. [Accès le 12 Juin 2018].
[5] «Traitement analytique en ligne,» [En ligne]. Available:
https://fr.wikipedia.org/wiki/Traitement_analytique_en_ligne. [Accès le 12 Juin 2018].
Annexes

Comparaison Talend Open Studio (TOS) et Pentaho Data Integration (PDI) :

Lecture / Ecriture SGBD TOS PDI

Lecture de table OUI OUI

Prévisualisation complète des tables OUI OUI

Lecture de vue OUI OUI

Lecture de procédure stockée OUI OUI

Ajout clause WHERE OUI OUI

Ajout clause ORBER DY OUI OUI

Lecture d’une requête OUI NON

Création d’une requête OUI OUI

Designer graphique de requêtes OUI NON

Résumé
Pour la société GasyNet, les données exploitées durant le processus de dédouanement à
Madagascar nécessitent d’être centralisées et uniformisées afin d’accélérer ce processus. Ce
besoin conduit à la mise en place d’un Data Warehouse. Ce nouveau système va répondre au
besoin des utilisateurs qui est d’avoir les bonnes informations au bon moment.

Ce travail a donc pour vocation la réalisation de cet entrepôt à travers des analyses et études
approfondies.

Mots clés : Data Warehouse ou Entrepôt de données, Décisionnel, Business Intelligence

Abstract
For GasyNet, the data used during the clearance process in Madagascar needs to be
centralized and standardized to speed up this process. This need leads to the setting up of a
Data Warehouse. This new system will meet the needs of users to have the right information
at the right time.

This work is therefore aimed at the realization of this warehouse through in-depth analyzes
and studies.

Keywords: Data Warehouse, Business Intelligence