Conception d’un système de gestion d’entrepôt de données dans un supermarché

(1)

REPUBLIQUE DU BENIN

***********

MINISTÈRE DE L’ENSEIGNEMENT SUPÉRIEUR ET DE LA RECHERCHE SCIENTIFIQUE

**********

UNIVERSITÉ D’ABOMEY-CALAVI

**********

ECOLE POLYTECHNIQUE D’ABOMEY-CALAVI

**********

DEPARTEMENT DE GENIE INFORMATIQUE ET TELECOMMUNICATION

**********

Option : Réseaux Informatiques et Internet

MEMOIRE DE FIN DE FORMATION

POUR L’OBTENTION DU

DIPLOME D’INGENIEUR DE CONCEPTION

INTITULE DU THEME :

Présenté et soutenu par :

Vidjinnangni Alphonse Ignace AZONHOUMON Maître de mémoire :

Dr. Médésu SOGBOHOSSOU, Enseignant à l’EPAC Tuteur de stage :

Ing. Appolinaire KONNON, Directeur Général de TBC Sarl

Année Académique : 2013-2014

Conception d’un système de gestion d’entrepôt

de données dans un supermarché

(2)

SOMMAIRE

SOMMAIRE . . . . ii

DEDICACE . . . . iv

REMERCIEMENTS . . . . v

LISTE DES SIGLES ET ABREVIATIONS . . . . vi

RESUME . . . . ix

ABSTRACT . . . . x

LISTE DES TABLEAUX . . . . xi

LISTE DES FIGURES . . . . xiii

INTRODUCTION GENERALE . . . . 1

I SYNTHESE BIBLIOGRAPHIQUE 4 1 Concept de progiciel de gestion Intégrée . . . . 5

2 Les systèmes d’information décisionnels . . . . 9

II MATERIELS ET METHODES 16 3 Méthodologie d’étude . . . . 17

4 Système de communication avec les chariots électroniques . . . . 24

5 Modélisation du système décisionnel . . . . 31

6 Outils de réalisation et environnement de test . . . . 42

III RESULTATS ET DISCUSSION 48 7 Résultats obtenus . . . . 49

8 Discussion . . . . 61

CONCLUSION ET PERSPECTIVES . . . . 63

(3)

Conception d’un système de gestion d’entrepôt de données dans un supermarché

REFERENCES BIBLIOGRAPHIQUES . . . . 66

ANNEXES 67 A Tableaux comparatifs et récapitulatifs . . . . 68

B Extraits de code de programmation . . . . 72

C Extrait du manuel d’utilisation des interfaces logicielles . . . . 77

D Structure d’acceuil . . . . 81

ENGLISH VERSION 83 TABLES DES MATIERES . . . . 94

(4)

DEDICACE A

Mon père Gabriel AZONHOUMON Ma mère Monique KOHOUNKO Mes frères et ma soeur Ines AZONHOUMON

Merci pour votre amour

(5)

REMERCIEMENTS

Je tiens à remercier en premier lieu, l’Eternel tout puissant lui qui a mis en moi le vouloir et le pouvoir.

Mes remerciements vont aussi à l’endroit :

– du Directeur de l’EPAC, Pr. Félicien AVLESSI et à toute l’administration de l’EPAC ;

– de Pr. Marc ASSOGBA, Chef de Département du Génie Informatique et Télécommunication et Directeur du Laboratoire d’Electrotechnique de Télécommunication et d’Informatique Appliquée (LETIA) ;

– du Dr. Médésu SOGBOHOSSOU, maître de ce mémoire, qui a accepté d’encadrer mes travaux. Ses enseignements de qualité, son oreille atten- tive, sa patience, ses conseils judicieux m’ont été d’une aide précieuse.

Merci d’avoir toujours cru en moi ;

– de tous les professeurs et enseignants de l’EPAC pour la qualité de l’enseignement ;

– de Ing. Appolinaire KONNON, mon maître de stage et DG de TBC Sarl, qui n’a ménagé aucun effort dans le suivi de ce travail ;

– de toute l’équipe de TBC Sarl, pour leurs remarques constructives, et leurs conseils ;

– de tous mes camarades et amis du Département de Génie informatique et Télécommunication en partiulier DE SOUZA Florentio et COLI Ga- farou pour leurs aides ;

– de tous mes camarades et amis de la 5^ème année ;

– de tous mes frères et soeurs de la communauté catholique Feu Nouveau pour leurs prières et soutiens ;

– de mes frères : Calixte, Anasthase, Prudence et Géraud, qu’ils voient en ce travail un exemple à suivre et à dépasser ;

– de tous ceux qui m’ont soutenu, de près ou de loin.

(6)

LISTE DES SIGLES ET ABREVIATIONS

A

AJAX Asynchronous Javascript And XML API Application Programming Interface B

BDD Base de données BI Business Intelligence C

CRM Customer Relation Management CSS Cascading Style Sheet

CSV Comma-Separated Values D

DOLAP Desktop OnLine Analytical Processing E

ERP Enterprise Resource Planning ETL Extract Transform Loading

(7)

F

FTP File Transfert Protocol G

GCL Gestion de la Chaîne Logistique

GMAO Gestion de la Maintenance Assistée par ordinateur GRC Gestion de la Relation Client

H

HOLAP Hybrid OnLine Analytical Processing HTML HyperText Markup Language

J

JDK Java Development Kit M

MDX MultiDimensional eXpression

MOLAP Multidimensional OnLine Analytical Processing MRP Manufacturing Resource Planning

O

OLAP OnLine Analytical Processing P

PDI Pentaho Data Integration PGI Progiciel de Gestion Intégré POS Point Of Sale

PME Petites et Moyennes Entreprises PMI Petites et Moyennes Industries

(8)

R

RFID Radio Frequency IDentification

ROLAP Relational OnLine Analytical Processing S

SAD Système d’aide à la décision SCM Supply Chain Management

SID Système d’Information Décisionnel SGBD Système de Gestion de Base de Données SQL Structured Query Language

U

UML Unified Modeling Language V

VLAN Virtual Local Area Network W

WIFI Wireless Fidelity X

XML eXtensible Markup Language

XMLA eXtensible Markup Language for Analysis

(9)

RÉSUMÉ

Le présent travail vise à renforcer le système de gestion des supermarchés grâce à l’utilisation d’un entrepôt de données. Après les généralités sur les concepts de ERP (Enterprise Resource Planning) et d’entrepôt de données, nous avons modélisé le système avec le langage de modélisation UML (Unified Modeling Language) en présentant dans un premier temps une vue globale de ce dernier. De cette vue, nous avons abordé en détails les différents éléments constitutifs du système. Il s’agit du module de communication de l’ERP avec les chariots intelligents et de la chaîne décisionnelle basée sur un entrepôt de données qui contient les informations émanant de l’activité des chariots intelligents et des données collectées dans le système opérationnel.

Les chariots intelligents sont utilisés dans notre travail pour accélérer le processus de vente et d’achat des clients. Pour implémenter ce système, nous avons utilisé en majeur partie des outils de développement web, ce qui nous a permis d’avoir comme résultats deux interfaces : la première est destinée à la gestion des activités du supermarché et la gestion des chariots intelligents ; la seconde pour aider les gérants dans leur prise de décision. Aux différents tests effectués, a manqué l’évaluation du système en grandeur réelle.

Mots clés : ERP, chariot intelligent, entrepôt de données, aide à la décision.

(10)

ABSTRACT

This work aims at reinforcing the management system of the supermar- kets thanks to the use of a data warehouse. After the general information on concepts of ERP (Enterprise Resource Planning) and of data warehouse, we modelled the system with the language of modeling UML (Unified Modeling Language) by presenting a view initially total of this last. Of this sight, we approached in details the different ones components of the system. It is the module of communication the ERP with the intelligent carriages and of the decisional chain based on one data warehouse which contains information emanating of the activity of intelligent carriages and of the data collected in the operational system. The intelligent carriages are used in our work to accelerate it process of sale and purchase of the customers. To implement this system, we used into major part of the development tools Web, which has us licence to have like results two interfaces : first is intended for management of the activities of the supermarket and the management of the intelligent carriages and the second to help the managers in their decision making. With different tests carried out, missed the evaluation of the system in real size.

Keywords : ERP, electronic trolley, data warehouse, business intelligence.

(11)

LISTE DES TABLEAUX

1.1 Modules généralistes d’un ERP . . . 7

1.2 Modules non traditionnels d’un ERP . . . 7

1.3 Les produits ERP . . . 7

3.1 Extrait de la liste des indicateurs retenus . . . 20

4.1 Acteurs principaux du système de pilotage des chariots élec- troniques . . . 25

6.1 Tableau récapitulatif des outils utilisés . . . 45

6.2 Liste des équipements utilisés pour les tests . . . 47

7.1 Liste des accès aux ressources de notre système . . . 58

7.2 Coût global de notre projet . . . 60

A.1 Comparaison entre une base de données et un data warehouse 68 A.2 Comparaison des meilleurs ERP libres sur le marché . . . . 69

A.3 Liste des indicateurs retenus (Extrait 1) . . . 70

A.4 Liste des indicateurs retenus (Extrait 2) . . . 71

(12)

LISTE DES FIGURES

1.1 Architecture modulaire d’un ERP . . . 6

2.1 Représentation d’un système d’information décisionnel . . . 10

2.2 Modèle de données en étoile . . . 12

2.3 Modèle de données en flocon . . . 13

2.4 Cube OLAP . . . 13

3.1 Vue globale du système . . . 22

4.1 Diagramme de cas d’utilisation du système . . . 26

4.2 Diagramme d’interaction entre le chariot et le système . . . 27

4.3 Tables utilisées dans la communication entre le chariot et le système . . . 28

4.4 Communication entre le chariot et la caisse . . . 29

4.5 Lecteur RFID et son tag . . . 29

5.1 Schéma en constellation de l’entrepôt de données . . . 33

5.2 Exemple de niveaux de granularité pour la dimension "produit" 34 5.3 Architecture physique de stockage dans l’entrepôt de données 35 5.4 Processus ETL dans l’entrepôt de données . . . 35

5.5 Extrait des dernières dates du processus ETL . . . 37

5.6 Architecture type des outils ROLAP . . . 39

5.7 Diagramme de cas d’utilisation de l’outil de visualisation . . 40

5.8 Diagramme de séquence de l’outil de visualisation . . . 40

5.9 Principe de fonctionnement du serveur ROLAP . . . 41

6.1 Architecture réseau de test de notre système . . . 46

7.1 Interface visible au niveau de la caisse . . . 50

(13)

7.2 Historique des achats d’un client . . . 51

7.3 Processus ETL de chargement des produits . . . 52

7.4 Durée d’exécution du processus ETL de chargement des 85 produits . . . 52

7.5 Interface de visualisation OLAP . . . 53

7.6 Total remises effectuées par caissier par mois . . . 54

7.7 Total remises effectuées à un client par caissier par mois . . 54

7.8 Repartition du total des remises par client . . . 55

7.9 Chiffre d’affaire par catégorie de produits . . . 55

7.10 Proposition d’architecture de déploiement de notre système . 57 B.1 Fichier contenant les numéros de série des produits scannés . 72 B.2 Fichier contenant un descriptif du contenu du chariot . . . . 72

B.3 Trigger plsql de remplissage de la dimension temporelle . . 73

C.1 Utilisation de l’interface de visualisation du point de vente . 77 C.2 Utilisation de l’interface de visualisation OLAP . . . 79

C.3 Structure modulaire de OPENERP . . . 80

D.1 Logo de la structure d’accueil . . . 81

1 Overall view of the system . . . 86

2 ETL process . . . 87

3 ROLAP process . . . 88

4 Interface of the POS . . . 89

5 Interface display OLAP . . . 90

6 Distribution of discounts by customer . . . 90

7 Physical architecture of the network . . . 91

(14)

INTRODUCTION GÉNÉRALE

L’entreprise est un système économique et social de personnes, organisée pour produire des services ou des biens pour une autre communauté de personnes que l’on appelle clients. L’entreprise évolue dans un environnement de plus en plus complexe. À une ère où la concurrence s’exerce sur plusieurs facteurs et où les risques d’entreprise se multiplient, la réussite de l’entreprise ne se traduit plus strictement en termes d’augmentation du bénéfice ou du rendement sur capital investi : la performance de l’entreprise devient donc multicritères. Il aura fallu attendre les années 90 pour que le débat autour de l’utilisation d’indicateurs financiers et non-financiers s’anime. Des systèmes performants ont vu le jour. Ils ont pour objectif, d’intégrer les indicateurs financiers et non-ficanciers pour offrir aux décideurs des pistes de prise de décision : ce sont les systèmes décisionnels. Un système décisionnel est composé de plusieurs outils qui, peuvent être imbriqués les uns aux autres ou utilisés séparément [1]. Il se base sur les entrepôts de données, les outils d’analyse OLAP (Online Analytical Processing) et des outils de datamining.

L’innovation, la qualité des produits et la qualité du service au client sont des facteurs déterminants des PME¹ performantes [3], [8]. Les supermarchés (entreprises commerciales) n’échappent pas à ces besoins puisque la qualité du service au client, demande la résolution des problèmes récurrents tels que les files d’attente au niveau des points de vente. Pour ce dernier problème, une solution a été proposée : il s’agit d’équiper les chariots du supermarché d’une unité de traitement destinée à automatiser le processus de vente. C’est le concept de chariot intelligent.

La gestion d’un supermarché étant une activité complexe, sa survie et sa prospérité dépendent, en partie, de la qualité des outils de gestion dont il

1. Petites et Moyennes Entreprises

(15)

dispose et des stratégies managériales adoptées. Une étude statistique sur le terrain nous a révélé que les ERPs utilisés par les supermarchés (G-Caisse² 5.0 version, Super Facturation³, Gestion commerciale⁴...) n’intègrent aucun module lié à la gestion de la file d’attente au niveau de la caisse. Ces systèmes utilisent tous actuellement la technologie du code barre qui impose un scan des produits à la caisse. Cet enregistrement est à la base du long temps passé par les clients à la caisse.

Les systèmes actuels de gestion de supermarché ne proposent aucune solution à l’accélération du processus d’achat et de vente qui constitue pourtant un facteur crucial de satisfaction de la clientèle. Ces systèmes ne présentent pas une vue globale des facteurs influençant la performance de l’entreprise et ont de la difficulté à mettre en corrélation les facteurs financiers et non- financiers.

Face à tous ces problèmes, nous proposons une solution tout-en-un réglant à la fois les problèmes de file d’attente et de gestion efficiente des activités des supermarchés. Il s’agit dans un premier temps de doter les chariots des supermarchés d’une unité de traitement équipée de la technologie RFID⁵ (Système conçu par Descartes ACCALOGOUN), permettant ainsi d’identifier les produits déposés dans lesdits chariots et de comptabiliser automatiquement les achats des clients. Dans un second temps, nous allons mettre en place un progiciel de gestion intégrée muni d’un entrepôt de données et capable de communiquer avec le chariot intelligent.

L’objectif principal de ce projet est de concevoir un système de gestion d’entrepôt de données capable de communiquer avec les chariots intelligents du supermarché et de renforcer les capacités de planification et de gestion des dirigeants. Les objectifs spécifiques sont :

– concevoir et mettre en place un dispositif de communication avec les chariots intelligents du supermarché pour faciliter le processus de vente et recueillir des données pertinentes à des fins décisionnelles ;

– mettre en place les modules de gestion de vente, de gestion d’achats, de gestion de stock, de gestion de sites distants, de gestion de la compta- bilité, de gestion du personnel... pour permettre le bon déroulement des activités du supermarché ;

2. www.gcaisse.com

3. www.superlogiciels.fr/professionnel/12-super-facturation-et-devis-2.html 4. www.cogivea/Gestion-commerciale

5. Radio Frequency IDentification

(16)

– mettre en place des outils décisionnels d’analyse des ventes de produits et du comportement de la clientèle (produit le plus vendu, les produits à forte rentabilité, prévisions des approvisionnements, meilleurs clients et besoins des clients, définition des périodes de promotion etc.)

Le présent mémoire de fin de formation sera organisé autour de trois grandes parties. Dans la première partie, nous ferons une synthèse bibliographique sur les principaux concepts de progiciel de gestion intégrée et sur les systèmes décisionnels. Ensuite dans la seconde partie, nous présenterons la méthodologie de conception adoptée, la modélisation du système ainsi que les différents choix techniques opérés. Enfin la troisième partie sera consacrée à la présentation, l’anlyse des résultats issus de notre travail et la discussion.

(17)

Première partie SYNTHESE

BIBLIOGRAPHIQUE

(18)

CHAPITRE 1

CONCEPT DE PROGICIEL DE GESTION INTÉGRÉE

S

^OMMAIRE

1.1 COMPOSANTES D’UNERP . . . . 6 1.2 LES PRODUITSERP . . . . 6 1.3 ATOUTS D’UNERP . . . . 8

Le traitement de l’information dans l’entreprise a largement évolué. Les différentes fonctions de l’entreprise étaient gérées par une multitude d’ap- plications dédiées souvent hétérogènes. Aujourd’hui, toutes les entreprises, aussi bien nationales qu’internationales de type PME¹ ou PMI² se tournent vers les solutions de gestion informatisée, offrant une vue transversale de toutes les activités de l’entreprise. Ceci a amené plusieurs d’entre elles à im- planter un ERP (Entreprise Ressource Planning) encore appelé progiciel de gestion intégrée, au cœur de leur système global d’information [16]. La quasi- totalité des grandes entreprises mondiales sont déjà équipées d’un ERP et de plus en plus de PME cherchent à construire un système informatique unifié qui s’appuie sur ce progiciel [10].

1. Petites et Moyennes Entreprises 2. Petites et Moyennes Industries

(19)

1.1 CONCEPT D’ERP

Il est important de noter qu’il n’existe pas un consensus sur une définition unique d’un ERP. Par ailleurs, la définition proposée par [15], s’avère la plus complète : « L’ERP est un système intégré qui permet à l’entreprise de stan- dardiser son système d’information pour relier et automatiser ses processus de base. Il fournit aux employés les informations nécessaires pour diriger et contrôler les activités essentielles de l’entreprise le long de la chaîne logistique, de l’approvisionnement à la production/exploitation jusqu’à la vente et à la livraison au client final. Les employés n’entrent qu’une seule fois les informations, qui sont alors mises à la disposition de tous les systèmes de l’entreprise. »

La figure 1.1 présente l’architecture modulaire d’un ERP.

FIGURE1.1 –Architecture modulaire d’un ERP

Si les limites du périmètre fonctionnel peuvent varier, on considère en général qu’un ERP prend en charge les domaines énumérés dans le tableau 1.1 [13].

De façon moins systématique, on trouve encore dans certains ERP les fonctionnalités résumées dans le tableau 1.2 [13].

1.2 LES PRODUITS ERP

Cette section présente une liste non exhaustive des produits ERP. On dis- tingue deux catégories de produit ERP : les produits ERP sous license et les produits ERP Open Source présentés dans le tableau 1.3.

(20)

TABLEAU 1.1 –Modules généralistes d’un ERP

Modules généralistes Description

Comptabilité Gestion de la comptabilité analytique et générale dont le mode de représentation peut s’appuyer sur une infrastructure d’aide à la décision embarquée par l’ERP.

Achats Le module d’achat permet de gérer les transactions d’achat et écritures comptables associées, mais aussi les approvisionnements selon des politiques à paramétrer et/ou selon le calcul des besoins déterminés par la gestion de production.

Ventes Ecritures comptables des ventes, mais aussi : règles de pricing, devis, factures, paiements... Les ERP s’interfacent nativement avec des solutions de ventes en caisse POS (Point Of Sale) ou encore Point de Vente en français.

Stocks et inventaire Gestion des politiques d’approvisionnement de stocks en fonction des ventes et des mouvements internes. On parle ici de SCM (Supply Chain Management), ou en français GCL (Gestion de la Chaîne Logistique).

TABLEAU 1.2 –Modules non traditionnels d’un ERP

Modules non traditionnels Description

Gestion de projet Cette gestion prend en charge la simple imputation de prestation de service en comptabilité générale et analytique et permet de surveiller les écarts entre quantité ven- due et charge réelle. L’ERP met aussi en jeu l’affectation des tâches aux employés, plannings...

Ressources Humaines Le périmètre du module ressources humaines peut varier de la gestion des emplois du temps, au recrutement, en passant par la gestion de la paie.

GMAO Ce type de module sert de référentiel des opérations de maintenance et n’est pas très complexe. On pourra assez facilement l’ajouter s’il n’est pas offert nativement.

TABLEAU 1.3 –Les produits ERP (Source Livre Blanc Smile 2011)

Open Source Sous Licence

Aria SAP

Compiere Oracle

ERP5 GEAC

webERP SAGE X3

OFBiz SSA Global etc.

OpenBravo SAP Business One

PGI Suite Gamme Cegid

Tiny ERP/Open ERP/Odo Peoplesoft

Dolibarr Microsoft Dynamics/Navision

Value Entreprise. etc

(21)

Le marché des ERP a évolué et est associé à la technologie Cloud et aux réseaux sociaux. Avec l’arrivée du Cloud, qui permet d’accéder à des bases de données localisées sur un serveur à distance, de nouveaux ERP ont vu le jour : les ERP en mode SaaS³.

1.3 ATOUTS D’UN ERP

Les ERP représentent la réalisation du rêve managérial d’unification et de centralisation de tous les systèmes d’information de l’entreprise en un système unique. Elles fournissent aux acteurs organisationnels une base de données commune. Les ERP permettent d’obtenir des avantages tels que :

– intégrer les activités de l’entreprise en développant une grande majorité des transactions ;

– faciliter la communication et la collaboration inter-organisationnelle ; – accéder aux données en temps réel ;

– réduire l’asymétrie d’information [9].

3. Software as a Service

(22)

CHAPITRE 2

LES SYSTÈMES D’INFORMATION DÉCISIONNELS

S

^OMMAIRE

2.1 COMPOSITION DU SYSTÈME D’INFORMATION DÉCISIONNEL . . . . 9 2.2 CONCEPTION D’UN ENTREPÔT DE DONNÉES . . . . 14

Les Systèmes d’Aide à la Décision (SAD) sont des systèmes flexibles qui aident les décideurs dans l’extraction d’informations utiles pour identifier, résoudre des problèmes et pour prendre des décisions [11].

2.1 COMPOSITION DU SYSTÈME D’INFORMATION DÉCISIONNEL

Un système d’information décisionnel est composé de plusieurs outils qui interagissent entre eux. La représentation schématique 2.1 illustre d’une manière globale les différentes interactions entre chaque outil.

2.1.1 Le système de données

Les sources de données susceptibles d’alimenter un entrepôt de données sont multiples :

– base de données internes et externes ; – flux XML ;

– fichiers CSV ; – ERP...

(23)

FIGURE2.1 –Représentation d’un système d’information décisionnel (Source : Livre Blanc ADUL- LACT, 2008)

2.1.2 Le système d’alimentation

Le système d’alimentation ou l’ETL¹ recouvre à la fois des outils et le processus d’alimentation. Il est utilisé pour alimenter le datawarehouse² à partir des bases de données de production.

Comme son nom l’indique, un ETL :

– Extract : extrait les données à partir de différentes sources ;

– Transform : transforme ces dernières afin de les unifier sous un même format ;

– Load : charge les données dans l’entrepôt.

2.1.3 Entrepôt de données

Le Data Warehouse est une base de données recueillant et gérant toutes les données collectées au sein de l’organisme, dans le cadre d’une prise de décision. Selon Inmon [2], un entrepôt de données doit répondre à quatre (4) caractéristiques essentielles :

– orienté sujet : car l’entrepôt est structuré autour des principaux sujets de l’entreprise au lieu des principaux domaines d’application (comme la facturation client, la gestion des stocks et la vente des produits) ; – intégré: les données provenant de différentes sources hétérogènes, l’in-

tégration des données permet d’éliminer l’ensemble des conflits afin d’avoir une représentation uniforme et cohérente des données ;

– historisé : car chaque donnée est horodatée et ne sera jamais effacée ni

1. Extract Transform Loading

2. Traduction anglaise du terme « entrepôt de données »

(24)

modifiée. Ceci permet à l’utilisateur du système de constater une pro- gression, comprendre les tendances, etc ;

– non volatil : les données ne disparaissent pas et ne changent pas au fil des traitements, au fil du temps. Ceci permet de conserver la traçabilité des informations afin de pouvoir effectuer des analyses sur une longue période.

Les entrepôts de données étant, en général, très volumineux et très complexes à concevoir, il est possible de les diviser en bouchées plus faciles à créer et à entretenir. Ce sont les mini-entrepôts de données. Les divisions peuvent être faites par fonction (un mini-entrepôt de données pour les ventes, un autre pour les commandes).

2.1.4 Cubes OLAP

Le terme OLAP désigne une technologie qui fait appel à une vue mul- tidimensionnelle de données, agrégées pour offrir un accès rapide à des informations stratégiques, à des fins d’analyses évoluées. En 1993, E. F. Codd a formulé douze (12) règles qui jettent les bases de l’évaluation des outils OLAP :

– multidimensionalité : le modèle OLAP l’est par nature.

– transparence : l’emplacement physique du serveur OLAP est transpa- rent pour l’utilisateur.

– accessibilité : l’utilisateur OLAP dispose de l’accessibilité à toutes les données nécessaires à ses analyses.

– stabilité : la performance des reportings³ reste stable indépendamment du nombre de dimensions.

– client-Serveur : le serveur OLAP s’intègre dans une architecture de la sorte.

– dimensionnement: il est générique, afin de ne pas fausser les analyses.

– gestion complète : le serveur OLAP assure la gestion des données clairsemées.

– multi-utilisateurs: le serveur OLAP offre un support multi-utilisateurs (gestion des mises à jour, intégrité, sécurité...).

– inter-dimension : Le serveur OLAP permet la réalisation d’opérations inter-dimensions sans restriction.

3. Ce sont des rapports présentant de manière synthétique et lisible des données, sous forme de tableaux de chiffres, tout en gérant la mise en page (en-tête, pied de pages...)

(25)

– intuitif : Le serveur OLAP permet une manipulation intuitive des don- nées.

– flexibilité : La flexibilité (ou souplesse) de l’édition des rapports est intrinsèque au modèle.

– analyse sans limites : Le nombre de niveaux d’agrégation possibles et de dimensions est suffisant pour autoriser les analyses les plus poussées.

Les outils OLAP permettent de modéliser l’activité d’une entreprise suivant des axes ou paramètres. Les outils OLAP se distinguent en fonction de l’architecture employée pour stocker et traiter les données multidimension- nelles. Il existe quatre catégories principales d’outils OLAP [4] :

– l’OLAP multidimensionnel (MOLAP) ; – l’OLAP relationnel (ROLAP) ;

– l’OLAP hybride (HOLAP) ; – le Desktop OLAP (DOLAP).

L’OLAP relationnel (ROLAP) est le type de technologie OLAP qui con- naît actuellement le plus grand succès. Il existe quatre modèles de ROLAP [11] :

– le modèle en étoile (Figure 2.2) ;

FIGURE2.2 –Modèle de données en étoile (Source : Livre Blanc ADULLACT, 2008)

– le modèle en flocon (Figure 2.3) ;

– le modèle mixte : résultat de la combinaison des structures en étoile et en flocon ;

– le modèle en constellation : représente plusieurs tables de faits qui partagent des dimensions communes.

En nous basant sur le modèle en étoile, nous pouvons ainsi distinguer deux types de tables :

(26)

FIGURE2.3 –Modèle de données en flocon (Source : Livre Blanc ADULLACT, 2008)

– celles formant les branches des étoiles. Elles sont appelées dimensions ouaxes et sont utilisées comme critères d’analyse ;

– celle qui forme le centre de l’étoile : latable de fait.

Une table de fait contient les indicateurs, également appelés mesures qui fe- ront objet d’analyse. Ces indicateurs sont donc fonctions des différentes dimensions, c’est pour cela que l’on emploie le terme multidimensionnel. Si l’on représente cette conceptualisation sous forme schématique, on obtient un cube (Figure 2.4).

FIGURE2.4 –Cube OLAP (Inspirée de : Livre Blanc ADULLACT, 2008)

On appelle Cube OLAP une représentation des données selon des axes ou dimensions. Dès qu’on dépasse trois dimensions, on parle d’hypercube.

(27)

2.1.5 Les métadonnées

Ce sont des données employées par tous le processus de l’entrepôt. Les métadonnées servent à une grande variété de desseins, dont :

– les processus d’extraction et de chargement : Les métadonnées sont utilisées pour faire correspondre des sources de données à une vue commune des données au sein de l’entrepôt ;

– le processus d’administration de l’entrepôt : Les métadonnées servent à automatiser la production des tables de synthèse ;

– en tant qu’acteur dans le processus d’administration des requêtes : Les métadonnées sont utilisées pour diriger une requête vers la source de données la plus appropriée [4].

2.1.6 Système de diffusion et de présentation

La principale raison d’être de l’entreposage de données est de livrer des informations aux utilisateurs commerciaux et administratifs pour les aider à prendre des décisions stratégiques. Ces utilisateurs interagissent avec l’en- trepôt, grâce à des outils d’accès aux données spécifiques. Nous pouvons regrouper ces outils en cinq catégories :

1. les outils de rapport et de requête ;

2. les outils de développement d’application ;

3. les systèmes d’information pour dirigeants (SID) ; 4. les outils de traitement analytique en ligne (OLAP) ; 5. les outils d’exploration des données (data mining) [4].

2.2 CONCEPTION D’UN ENTREPÔT DE DONNÉES

2.2.1 Approche de conception d’un entrepôt de données

Les approches de conception d’un entrepôt de données peuvent être classées en trois catégories [7] :

– les approches descendantes ou top-down : elles permettent de construire le schéma de l’entrepôt à partir d’une analyse détaillée des besoins des décideurs ;

– les approchesascendantes ou bottom-up: elles débutent par une analyse détaillée des sources de données. Les besoins des décideurs ne sont pris en compte que vers la phase d’analyse en ligne des données [5] ;

(28)

– les approches mixtes : elles considèrent à la fois les besoins des dé- cideurs et la disponibilité des données sources [17].

2.2.2 Architecture physique d’un entrepôt de données

Il existe essentiellement cinq architectures pour le stockage de données dans un entrepôt de données [7] :

– l’architecture « magasin de données indépendantes » : cette architecture est très simple et moins coûteuse mais elle n’est pas extensible et présente des risques d’incohérences et de redondances entre les mini- entrepôts de données ;

– l’architecture « bus de magasin de données » : elle est caractérisée par des datamarts⁴ de l’entrepôt reliés entre eux par soit une dimension ou, soit une mesure (dimension/mesure commune) [2] ;

– l’architecture « Hub-and-Spoke » : est caractérisée par l’entrepôt de données (hub) qui contient des données atomiques, les mini-entrepôts (spoke) qui reçoivent les données de l’entrepôt. Cette architecture permet l’intégration et la consolidation complètes des données de l’entreprise [14]. Cependant, on peut avoir des redondances de données entre les mini-entrepôts ;

– l’architecture « entrepôt de données centralisées » : l’intégration et la maintenance des données sont faciles car les données sont à un seul endroit [2]. Cependant, cette architecture est longue et très coûteuse à développer ;

– l’architecture « fédérée » : elle est caractérisée par un entrepôt de données distribué sur plusieurs systèmes hétérogènes. Elle présente de faibles performances à cause des synchronisations et ne permet pas de contrôler les sources et la qualité des données.

4. Mini-entrepôts de données

(29)

Deuxième partie

MATERIELS

ET METHODES

(30)

CHAPITRE 3

MÉTHODOLOGIE D’ÉTUDE

S

^OMMAIRE

3.1 DÉMARCHE DU PROJET . . . . 17 3.2 ANALYSE DE L’EXISTANT ET CHOIX DES INDICATEURS . . . . 18 3.3 PRÉSENTATION DE NOTRE SOLUTION . . . . 20

Dans ce chapitre, nous présenterons la méthodologie adoptée au cours de la réalisation de notre projet.

3.1 DÉMARCHE DU PROJET

Ce projet s’est focalisé sur la conception d’un système embarquant un module de communication avec les chariots électroniques, et les outils néces- saires à la gestion interactive des différents services métiers d’un super- marché. L’approche méthodologique adoptée est la suivante :

– analyse des besoins : cette partie nous permettra de ressortir les indicateurs qui seront utilisés par notre système sur la base des difficultés rencontrées par les supermarchés ;

– proposition d’une solution : Cette partie nous permettra de dégager à partir des besoins, un premier prototype du système et son fonctionnement ;

– modélisation du système : cette partie s’occupera de la conception des différents modèles du système. Nous présenterons d’abord

(31)

une représentation schématique du système. Cette représentation fera ressortir les différents modules du système et les interactions entre ces derniers. Ensuite, nous présenterons de manière détaillée chaque module du système en utilisant des diagrammes, des modèles ;

– implémentation du système : nous présenterons les outils et technolo- gies utilisés dans la réalisation du système tout en justifiant nos dif- férents choix. Il s’agit du choix de l’ERP, des outils d’aide à la décision, des langages de programmation... Après cette étape, le système implé- menté pourra être évalué en vue d’analyser ses performances ;

– tests et évaluations : des tests globaux seront effectués sur le système pour vérifier le fonctionnement global et des tests unitaires pour les dif- férents blocs fonctionnels ;

– déploiement : A cette étape, il ne reste qu’à déployer le système implé- menté dans un environnement réel.

3.2 ANALYSE DE L’EXISTANT ET CHOIX DES INDICATEURS

Après l’étude des solutions informatiques utilisées par les supermarchés du Bénin, nous pouvons les regrouper en deux catégories :

1. les solutions partielles :

Ces solutions (Excel, Ciel Compta) n’offrent pas une vue globale des activités de l’entreprise ; logiciel de comptabilité séparé du logiciel de vente et de gestion de stock. Cette pluralité de logiciels dédiés utilisés par les supermarchés, ne permet pas une gestion efficace et une augmentation de la performance. Une gestion globale dans ces contextes, nécessite des ponts entre les solutions hétérogènes utilisées ;

2. les solutions ERP :

La conception d’une solution informatique spécifique à un besoin du marché quoiqu’elle fut générale, présente toujours un problème d’inté- gration des réalités socio-culturelle et socio-économique des utilisateurs quand ces derniers n’appartiennent pas à l’environnement social ayant donné naissance à ce besoin. Certains supermarchés utilisent SAGE 100 version commerciale. Bien que cet ERP couvre un large périmètre fonctionnel, les supermarchés béninois sont limités parfois par le fait que cet outil n’arrive pas à gérer certaines ambiguïtés du commerce béninois (gestion de stock avec la vente en gros et en détail pour un même produit,...).

Ces solutions ERP intègrent des outils d’aide à la décision (Tableaux

(32)

de bords, Reporting) disposant le plus souvent d’indicateurs financiers (évolution du chiffre d’affaire, du profit...) riches et d’indicateurs non- financiers (quantité de produits en stock,...) pauvres. Cependant, ces mesures ne permettent pas une vue globale des facteurs influençant la performance du supermarché puisque les paramètres tels que la satisfaction du client, l’analyse du service après-vente, le comportement du client,... pourtant capitaux, ne sont pas pris en compte.

A ces problèmes précités, s’ajoutent les difficultés de gestion de la clientèle et de gestion du stock. Ces difficultés sont liées :

– aux longues files d’attente qui décourage la clientèle lors de leurs achats ;

– aux limites du code barre qui n’identifie que la gamme de produit et non le produit de manière unique. Lors des retours de marchandises, il devient alors difficile aux dirigeants de certifier que ce sont bien les produits vendus ;

– au fait que les dirigeants de supermarché ne savent pas le plus souvent, comment et quand tenir des campagnes de réduction sur les achats pour les clients, parce qu’ils ne disposent pas des informations pertinentes de prise de décision. Ces campagnes permettent au supermarché de faire des bénéfices et par la même occasion, de mettre en confiance la clientèle

Nous pouvons regrouper toutes ces difficultés que rencontrent les super- marchés béninois en deux grandes catégories :

1. l’abscence d’un système souple, hautement paramétrable et évolutif s’alignant aux besoins des utilisateurs avec une facilité de maintenance et d’homogénéisation ;

2. le manque d’outils décisionnels adaptés pour accompagner les dirigeants dans la gestion de leurs supermarchés.

Pour répondre à ces différents besoins, une liste d’indicateurs a été retenue.

Un indicateur est une mesure objective (vérifiable et indicative) qui reflète l’état (le statut) d’une variable qu’on voudrait mesurer. Par exemple l’indicateur peut être un chiffre, un taux, un ratio, une moyenne. Le tableau 3.1 présente la liste des indicateurs choisis.

La conception de notre système utilisera les chariots disponibles dans le supermarché. Ces chariots seront équipés de la technologie RFID et col-

(33)

TABLEAU 3.1 –Extrait de la liste des indicateurs retenus (Source : Livre Blanc Martec, 2011)

Variables Indicateurs Détails/Formules

Clientèle Taux de satisfaction de la clientèle

Nombre de services apres vente r` eussi×100´ Nombre de services apres vente total` Ce taux est évalué pendant une période donnée Ventes Taux d’évolution des ventes (Vente periode n−vente p´ eriode n−1´ )×100

vente periode n−1´ Cet

indicateur permet de suivre l’évolution des ventes dans le temps

Personnel Gain moyen par caisse Gain total ×Nombre de vendeurs. Cet indicateur nous permettra d’étudier l’affluence des clients vers une caisse donnée

Taux d’absentéisme (Nombre de presences pendant une p´ eriode´ )×100 Nombre reglementaire de pr´ esences dans la p´ eriode´ permet d’évaluer de manière périodique la présence du personnel

Produits Demande en volume Quantite moyenne achet´ ee par personne´ × Nombre d⁰acheteurs. Cet indicateur nous permettra d’évaluer le volume de demande de ce produit et ainsi, anticiper sur les ruptures de stock pour ce produit

Demande en valeur Prix d⁰un produit×Demande en volume. Cet indicateur nous permet d’évaluer en moyenne, le chiffre pour un produit dans une période donnée

lecteront des données par rapport au comportement du client lors de son achat.

3.3 PRÉSENTATION DE NOTRE SOLUTION

A la connaissance des difficultés rencontrées par les supermarchés et dans le souci d’offrir une solution unique répondant à tous ces besoins, nous présentons dans cette section, une vue globale du système et son fonctionnement.

3.3.1 Architecture métier de notre proposition Deux architectures métiers sont possibles :

– « client-serveur » : Le client se connecte au serveur en utilisant une application embarquée. Le client est autonome et embarque tout le processus de connexion, de traitement et de communication avec le serveur ; – « n tiers » : cette architecture constitue un client léger qui se connecte à

(34)

une couche intermédiaire de type intergiciel.

Nous avons opté pour la seconde architecture qui ne nécessite aucune instal- lation du côté du client qui n’a besoin que d’un navigateur web pour accéder aux ressources en ligne.

3.3.2 Vue globale

La figure 3.1 présente une vue globale de notre proposition. Nous pouvons y remarquer les grands blocs du système et les différentes relations.

3.3.3 Fonctionnement global

Le fonctionnement global de notre système peut être scindé en trois grandes parties :

1. Chariot - Serveur ERP

Cette partie présente le comportement du chariot électronique lorsqu’il est en activité. Pour notre système, le serveur ERP et les chariots élec- troniques sont dans un réseau et communiquent par WIFI. L’adresse du serveur dans ce réseau est statique.

Le lecteur RFID¹ implantée au niveau du chariot scanne le contenu de ce dernier. Elle récupère ainsi tous les identifiants uniques des produits et questionne la base de données par rapport à ces identifiants. Le scan et le résultat de la requête (désignations, prix, images, ...) sont enregistrés dans deux fichiers différents qui sont envoyés au serveur par FTP.

1. Radio Frequency IDentification

(35)

FIGURE3.1–Vueglobaledusystème

(36)

2. Chariot - Point de vente

Cette partie présente le comportement d’un chariot électronique lorsqu’il est amené au niveau de la caisse. La caisse dispose d’un lecteur RFID. Lorsque le chariot vient au niveau de la caisse à une distance de 10cm du lecteur RFID, ce dernier lit l’identifiant du chariot.

Aussitôt, le point de vente² récupère cet identifiant et suivant les fichiers reçus par FTP des différents chariots, décide lequel lire. Après lecture, le point de vente affiche le contenu du chariot et la caissière peut lancer le processus de vente.

3. Analyse décisionnelle

Les utilisateurs habiletés à utiliser les outils décisionnels sont les gérants du supermarché. Ces utilisateurs accèdent au système via une application web hébergée sur un serveur d’application. A partir de cette application, ils définissent les différents paramètres de l’analyse. Le serveur d’application traduit la demande du client en requêtes multidimension- nelles qu’il envoie au serveur d’analyse. Le serveur d’analyse (OLAP) quant à lui traduit ces nouvelles requêtes en requêtes SQL compréhen- sibles par l’entrepôt de données.

L’entrepôt de données est constitué de données issues de la base de don- nées centrale de l’ERP. Ces données ont suivi un processus ETL avant d’être intégrées dans l’entrepôt de données.

L’entrepôt de données après avoir traité les requêtes, renvoie les ré- sultats au serveur d’analyse. Le seveur d’analyse à son tour, renvoie une réponse au serveur d’application qui utilise des graphiques, des tableaux, pour permettre à l’initiateur de la requête de visualiser la réponse de sa demande.

2. Interface visible par la caissière grâce au navigateur de son poste client et destinée à la vente de produits

(37)

CHAPITRE 4

SYSTÈME DE COMMUNICATION AVEC LES CHARIOTS ÉLECTRONIQUES

S

^OMMAIRE

4.1 IDENTIFICATION DES CAS D’UTILISATION DU SYSTÈME . . . . 24 4.2 COMMUNICATION ENTRE LE CHARIOT ET LE SYSTÈME . . . . 26 4.3 FONCTIONNEMENT DU MÉCANISME DE VENTE LA CAISSE . . . . 28

Ce chapitre présente les modèles mis en oeuvre pour concevoir le module de pilotage des chariots électroniques. Tout au long de ce chapitre nous désignerons parsystèmele serveur hébergeant l’ERP.

4.1 IDENTIFICATION DES CAS D’UTILISATION DU SYSTÈME

4.1.1 Acteurs du système

Un acteur représente un rôle joué par une entité externe (utilisateur hu- main, dispositif matériel ou autre) qui interagit directement avec le système étudié [12]. Le tableau 4.1 présente les principaux acteurs du système.

(38)

TABLEAU 4.1 –Acteurs principaux du système de pilotage des chariots électroniques

Acteurs Opérations

Client sans chariot

– opération d’achat au niveau de la caisse ; – réception de ticket d’achat

Client avec chariot

– demande des renseignements sur les produits entrés dans le chariot ;

– sauvegarde le contenu du chariot au niveau du système ; – opération d’achat au niveau de la caisse ;

– réception de ticket d’achat.

Caissière

– gestion du processus de vente des produits ; – impression du ticket de vente.

Responsable des ventes

– enregistre les chariots dans le système ;

– enregistre les identifiants des produits dans le système ; – gestion des ventes des produits ;

– enregistre les caissiers.

Administrateur

– maintenance du système ; – gestion des droits d’accès.

Décideur

– collecte les informations relatives à l’analyse décisionnelle pour la conception de l’entrepôt de données ;

4.1.2 Diagramme de cas d’utilisation

Le diagramme de cas d’utilisation permet de décrire ce que le futur sys- tème devra faire, sans spécifier comment il le fera [12].

Préconditions

– réseau Wifi en place et connexion stable ;

– mise en réseaux des chariots électroniques et du serveur hébergeant l’ERP ;

– paramétrage du réseau et adresse statique du serveur.

Postconditions

– enregistrement des informations pertinentes (journalisation des ventes opérées) ;

(39)

– suppression des numéros de série des produits vendus.

La représentation 4.1 est le diagramme de cas d’utilisation du système.

FIGURE4.1 –Diagramme de cas d’utilisation du système

4.2 COMMUNICATION ENTRE LE CHARIOT ET LE SYSTÈME

Nous avons modélisé cette interaction entre le chariot et le système à travers le diagramme de séquence 4.2.

Explication du fonctionnement

Lorsque l’utilisateur allume le chariot, ce dernier tente une connexion à la

(40)

FIGURE4.2 –Diagramme d’interaction entre le chariot et le système

base de données du serveur ERP. Si la connexion réussie (scénario 1.1), à intervalle de 3 secondes, le chariot à travers une requête, demande des renseignements sur les produits scannés à partir de leurs identifiants. Avant cette étape dans la base de données, le champ « actif » de la table « chariot » passe à ’TRUE’ pour signaler aux caissiers que le chariot est actif. Rappelons que la liste des identifiants des produits scannés est enregistrée dans un fichier. La réponse de la base de données (désignation, prix, photo pour chaque produit distinct) est aussi enregistrée dans un fichier. Ces deux fichiers sont envoyés au serveur grâce au protocole FTP. Le premier fichier servira à supprimer les identifiants des produits vendus, de la base de données. Le second fichier quant à lui, sera utilisé dans la reconnaissance des produits entrés et sortis du chariot au cours de l’achat du client. Il sera aussi utilisé après l’identification du chariot au comptoir de la caisse. Dans ce cas, son contenu sera affiché au niveau du point de vente.

Après un certain temps d’inactivité du chariot, ce dernier passe automatique-

(41)

ment en veille. Avant de passer dans cet état, il se connecte à la base de données et fait passer le champ « actif » de la table « chariot » à ’FALSE’. A la suite les fichiers enregistrés sur l’activité du chariot sont supprimés. La figure 4.3 présente le diagramme de classe modélisant la relation entre la table

« product_template » (Table de l’ERP contenant les détails sur les produits) et « numero_serie » contenant les numéros de série de tous les produits. Les requêtes du chariot sont effectuées sur la jointure de ces deux tables.

FIGURE4.3 –Table « chariot » à gauche et Relation d’aggrégation entre les tables « numero_serie » et « product_template » à droite

L’algorithme de traitement du comportement du client lors de son achat est présenté dans l’annexe B.6. Les fichiers échangés par le chariot et le serveur sont au format XML. Les annexes B.1 et B.2 présentent les contenus de ces deux fichiers.

4.3 FONCTIONNEMENT DU MÉCANISME DE VENTE LA CAISSE

Le mécanisme de vente à la caisse met en jeu plusieurs acteurs. Nous pouvons citer :

– un client et son chariot ;

– une caissière et son point de vente ; – un serveur hébergeant l’ERP ; – un lecteur RFID.

(42)

Les interactions entre ces différents acteurs s’illustrent à travers le diagramme de séquence 4.4.

FIGURE4.4 –Communication entre le chariot et la caisse

Explication du fonctionnement

Chaque chariot est équipé d’une étiquette l’identifiant de manière unique dans le système d’informations du supermarché et le comptoir de la caisse est équipé d’un lecteur RFID (Figure 4.5).

Lorsque le client arrive avec son chariot à la caisse, et que le chariot est à

FIGURE4.5 –Lecteur à « gauche » et le « tag » à droite

(43)

une distance de 10cm du lecteur RFID, ce dernier lit l’étiquette du chariot.

Automatiquement, l’identifiant du chariot est envoyé au niveau du point de vente de la caissière. Le point de vente récupère cet identifiant et demande au serveur l’autorisation d’avoir accès au fichier décrivant le contenu du chariot (figure B.2). Lorsque le point de vente entre en possession de cette information, il affiche à la caissière le contenu du chariot. La caissière peut alors effectuer la vente des produits. Ce processus de vente inclut l’accès au fichier contenant les identifiants des produits vendus (figure B.1). Ces identifiants après vente des produits sont supprimés de la base de données.

(44)

CHAPITRE 5

MODÉLISATION DU SYSTÈME DÉCISIONNEL

S

^OMMAIRE

5.1 MODÉLISATION DE L’ENTREPÔT DE DONNÉES . . . . 31 5.2 PROCESSUS ETL . . . . 35 5.3 L’ANALYSE EN LIGNE . . . . 38

L’ERP présente une base de données centrale contenant une multitude d’informations relatives aux ventes, aux clients, aux employés, aux produits...

Notre travail dans ce chapitre consistera à modéliser le système décisionnel qui sera utilisé pour mettre à la disposition des gérants de supermarché des outils d’analyse et de prise de décision. Nous utiliserons comme source de données de notre système décisionnel, la base de données de l’ERP. La conception de notre système décisionnel passe par la conception de l’entrepôt de données et le choix des outils de visualisation pour les utilisateurs finaux.

5.1 MODÉLISATION DE L’ENTREPÔT DE DONNÉES

Une phase préalable de collecte et d’analyse des besoins nous a permis d’identifier un ensemble prioritaire d’exigences auquel l’entrepôt de données de l’entreprise doit satisfaire. Nous avons aussi identifié la source de données qui alimentera notre entrepôt de données. Cette source de données est la base de données de l’ERP.

(45)

5.1.1 Approche conceptuelle

Des entretiens avec des gérants de supermarché, nous ont permis de col- lecter des informations ayant rapport à la vue descendante (les exigences des utilisateurs) et à la vue montante (les informations sources disponibles). L’approche de conception qui sera adoptée pour notre modélisation est l’approche mixte qui considère à la fois, les besoins des décideurs et les informations sources disponibles. Cette approche permet de tenir compte de la disponibi- lité des informations qui seront utilisées pour l’analyse et parallèlement, de ne charger dans l’entrepôt de données que les données pertinentes apportant une aide à la prise de décision.

5.1.2 Modélisation dimensionnelle

La description du composant de base de données d’un entrepôt de données s’effectue à l’aide d’une technique, dénommée modélisation dimensionnelle.

Cette modélisation dimensionnelle se base sur les concepts de dimensions, de mesures et de faits.

Les mesures de notre entrepôt sont par exemple : – le nombre total de produits vendus ;

– le nombre total d’employés ; – le nombre de démissions ; – le nombre d’absences ;

– le total des réductions sur vente...

Ces différentes mesures sont numériques et additives. Elles nous ont permis d’orienter nos analyses. Elles porteront sur les ventes des catégories de produits, dans une certaine période, à un client disposant d’un moyen de paiement (chèque, compte banquaire, cash, etc). Cette vente est opérée par un caissier dans une succursale du supermarché appartenant à un quartier d’une ville. Nos analyses porteront aussi sur le service après vente. Sur le personnel, nous orienterons nos analyses sur la paie et la promotion.

Nous dégageons de ces réflexions, trois tables de faits : « l’analyse des ventes », « l’analyse du service après vente » et la « gestion du personnel ».

A ces trois tables de faits sont conjointes des tables de dimensions qui fournissent le contexte (qui, quoi, quand, où, pourquoi et comment) des faits. La figure 5.1 donne la représentation en constellation de l’entrepôt de donnée.

(46)

FIGURE5.1–Schémaenconstellationdel’entrepôtdedonnées

(47)

Niveau de granularité

La granularité est le degré de précision dans l’analyse. Pour la dimension

« temps », la granularité de la mesure est arrêtée au niveau « année », pour la dimension « produit », à la « famille » du produit et pour la dimension

« quartier », au niveau de la « commune ». La figure 5.2 illustre le cas de la dimension produit avec les niveaux de granularité « Produit », « Categorie » et « Famille ». Le premier niveau de granularité est le « Produit ».

FIGURE5.2 –Exemple de niveaux de granularité pour la dimension "produit"

Dimensions partagées

Une dimension commune ou partagée est une dimension utilisée par au moins deux tables de fait. De notre architecture, nous relevons deux dimensions partagées : « Client » et « Temps ».

La dimension « Client » est commune aux tables de fait « Ser- viceApresVente » et « VenteProduit ». La dimension temporelle quant à elle, est une dimension commune à toutes les tables de fait.

5.1.3 Architecture physique de stockage des données

Les données de la source globale (base de données opérationnelles de l’ERP) sont intégrées dans l’entrepôt de données à travers un processus ETL (détaillé dans la section 5.2). Il faudra alors organiser ces données pour les rendre disponibles aux utilisateurs finaux. Le supermarché ne dispose que d’un nombre très limité de gérants tournant autour de un (01). L’accès à l’information est donc restreint à ce petit nombre. On ne saurait donc orienté l’en- trepôt de données vers « l’utilisateur ». Nous orienterons donc notre entrepôt de données vers les « fonctionnalités ». Cela nous permet de ne pas prévoir des mini-entrepôts de données qui pourraient lors de la conception induire des redondances d’information surtout avec les tables de dimensions comme

«Temps» partagée par les tables de fait. Nous opterons donc pour une architecture avec un entrepôt de données centralisé (Figure 5.3). Comme avantage, cette architecture permet aux utilisateurs d’avoir accès à toutes les données

(48)

de l’entreprise. L’intégration et la maintenance des données sont faciles car les données sont à un seul endroit.

FIGURE5.3 –Architecture physique de stockage dans l’entrepôt de données

5.2 PROCESSUS ETL

Le processus ETL est un processus complexe dans la phase de conception d’un entrepôt de données. La figure 5.4 schématise le processus complet d’intégration de données dans notre entrepôt.

FIGURE5.4 –Processus ETL dans l’entrepôt de données

(49)

5.2.1 Extraction des données

La base de données source est celle de l’ERP contenant toute l’activité du supermarché. Le processus d’extraction commence donc par le ciblage des tables impliquées dans l’analyse décisionnelle. Ces tables sont relatives au processus vente, au service après vente et gestion de la relation client. Le processus d’extraction est linéaire puisqu’il n’a pas plusieurs formats sources possibles à gérer.

5.2.2 Transformation des données Filtrage des données

Le filtrage des données consiste à éliminer les données abérrantes. Par exem-ple si la quantité de produits vendus est négative, il faudra filtrer cette valeur, en la remplaçant par une valeur prédéfinie positive. Il faudra aussi uniformiser le libellé des désignations de quartiers et de communes entrés dans le système par les utilisateurs. Exemple : transformer « Ab-calavi » ou

« Abomey-calavi » en « Abomey-Calavi » Déduplication des données extraites

Ce processus nous permet d’éviter le chargement dans une table de l’entrepôt de données, d’entrées identiques. Pour éviter des duplications d’entrée dans l’entrepôt, une table de «timestamp» est créée et indique la date de dernière chargement des données pour chaque table de l’entrepôt (Voir Figure 5.5).

Cette opération est effectuée à chaque fin de transformation des données.

Seules les données récentes par rapport à cette date sont extraites de la source.

Formatage des données extraites

Les données extraites doivent être formatées suivant le type des champs des tables de l’entrepôt. A ce niveau, les dates doivent être formatées.

5.2.3 Chargement des données

L’intégration des données dans l’entrepôt commence par le chargement des dimensions et se termine par le chargement des tables de faits. Les sous- dimensions d’une dimension doivent être chargées avant cette dernière. Par exemple, pour charger pour la dimension « Temps », les sous-dimensions

« annee », « trimestre » et « mois » doivent être chargées dans cet ordre au

(50)

FIGURE5.5 –Extrait des dernières dates du processus ETL

préalable. Cette démarche est importante pour ne pas créer des problèmes de référencement.

5.2.4 Démarche d’alimentation

– Le chargement des données dans l’entrepôt peut s’effectuer de deux manières (en temps réel ou en différé). Notre modélisation optera pour une alimentation différée, puisque la charge d’un processus est gour- mande en ressource et peut prendre plusieurs minutes. Charger les données au fur et à mesure des modifications sur la source de données peut altérer les performances de l’ERP ;

– Suivi des dimensions à modification lente

Nous pouvons distinguer trois types fondamentaux de dimensions à modification lente [12] : le Type 1, où un attribut de dimension modifié est écrasé ; le Type 2, où un attribut de dimension modifié provoque la création d’un nouvel enregistrement de dimension ; et le Type 3, où un attribut de dimension modifié provoque la création d’un attribut alternatif, pour que les deux valeurs, l’ancienne et la nouvelle, soient simultanément accessibles dans le même enre-gistrement de dimension.

Notre modélisation utilisera une stratégie d’historisation suivant le type 2. Cette stratégie permettra par exemple de dater la période d’aug-