Conception et mise en place d’un DATA WAREHOUSE à · Avant d’entamer la partie conception...

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

Andriniaina Andriamanoelison 11

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, …

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.

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.

1.3 Le Data Warehouse


Différence Systèmes transactionnels Data Warehouse

Les données

Orienté applications Orienté thèmes et sujets

Données détaillées et codées non

redondantes

Informations agrégées cohérentes

souvent avec redondance

Données changeantes constamment Informations stables et

synchronisées dans le temps

Usage

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

complexes transparentes

Faibles volumes à chaque

transaction

Large volume manipulé

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.

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.

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 :

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.



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 :



Datamart dépendant Datamart indépendant

Identifier le bon sous-ensemble de données

correspondant au sujet du Datamart dans

l’entrepôt central déjà construit et faire une

copie

Gérer tous les aspects du processus ETL

comme pour faire un DW central mais

concentré sur un seul sujet

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.



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 :



Figure 4 Exemple modélisation Data Warehouse

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

DW

Commence par la conception du modèle

dimensionnel pour les Datamarts

Architecture composée d’un staging area

permanent, d’un DW et de Datamarts

dépendants

Architecture qui consiste en un staging area

et de Datamarts, le DW physique n’existe

pas

Le DW est orienté entreprise et les

Datamarts sont orientés processus

Les Datamarts contiennent les données

atomiques et agrégées

Le DW contient les données atomiques ; les

Datamarts et les données agrégées

Les Datamarts peuvent fournir une vue

entreprise ou processus

Le DW utilise un modèle normalisé de toute

l’entreprise ; les Datamarts utilisent des

données dimensionnelles orientés sujet

Les Datamarts sont implémentés de façon

incrémentale et intégrée en utilisant les

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 :



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.



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.

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 :

2.2 Le concept OLAP


ROLAP MOLAP HOLAP

Stockage des

données de base

BD relationnelle BD

multidimensionnelle

BD relationnelle

Stockage des

agrégations

BD relationnelle BD

multidimensionnelle

BD relationnelle

Structure de la

base de données

Modèle particulier (étoile

flocon, …)

Structure propriétaire

au logiciel utilisé

Croisement des

architectures

ROLAP et

MOLAP

Fonctionnement Le serveur extrait les

données par des requêtes

SQL et interprète les

données selon une vue

multidimensionnelle

avant de les présenter au

module client

Le serveur MOLAP

extrait les données de

l’hyper cube et les

présente directement au

module client

Accède aux deux

BD et les présente

au module client

selon leur

méthode

respective

Performance des

requêtes

Le moins performant Le plus performant Performance

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.

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

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.

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.

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.

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.

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.

2.3 Alimentation du Data Warehouse


Différence SQL MDX

Dimensions Deux dimensions Plusieurs dimensions

Clause SELECT Pour définir la disposition des

colonnes pour une requête

Pour définir les axes

Clause WHERE Pour filtrer les données

renvoyées par une requête

Pour fournir une tranche des

données renvoyées par une requête

Visualisation des

résultats

Intuitive Non intuitive

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.



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.



Figure 15 Processus ETL

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

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.

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.

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

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



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.



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.



Figure 22 Notification demande terminée

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

Conception et mise en place d’un DATA WAREHOUSE à · Avant d’entamer la partie conception...

Documents

Transcript of Conception et mise en place d’un DATA WAREHOUSE à · Avant d’entamer la partie conception...