Sous La Direction de Chef Du Service DRP

THÈME
Etude et mise en place d'un outil d'aide à

la décision pour le service Monitoring de la
Qualité de service de la Sonatel.
Sous la direction de
Présenté et soutenu par
M. Jean-Marie PREIRA
M. Daouda TRAORE
Enseignant chercheur à l'ESMT
et
INGC - Architecture des Réseaux
M. Al Housseynou SAKHO
Informatiques et Télécoms
Chef du service DRPS/SMC-N/MQS
de la Sonatel
Promotion 2016 - 2019

Décembre 2019
Etude et mise en place d'un outil d'aide à la décision pour le service Monitoring de la Qualité de service de la Sonatel.
DEDICACE
Je dédie ce travail à tous ceux qui me sont chers,
A mes chers Parents, mes frères et sœurs
Aucun hommage ne pourrait être à la hauteur de l’amour et de

l’affection que vous me donnez,
Que ce travail soit l’expression de ma reconnaissance pour vos

sacrifices, votre soutien moral et matériel.
Vous étiez toujours présents pour m’encourager.
Je vous souhaite la réussite et le bonheur et surtout la

bénédiction de Dieu.
A mes amis mes professeurs
Qui ont été présents et sans qui cela n’aurait pu être

Possible !
Daouda TRAORE i
REMERCIEMENTS
Je rends grâce à Dieu, le Tout Puissant pour toutes ses grâces et bénédictions qu’il m’a donné
d’être entouré de personnes attentionnées et présentes pour ma modeste personne.
Je tiens à remercier particulièrement mon maitre de stage M. Al Housseynou SAKHO du service
DRPS/DEX/SMC-N/MQS de la Sonatel pour m’avoir accompagné durant ces mois de stage et
pour tout ce qu’il m’a apporté.
J’adresse également mes remerciements à mon directeur de mémoire M. Jean-Marie PREIRA
enseignant chercheur à l’ESMT pour les commentaires utiles, les remarques et le temps qu’il m’a
accordé. Egalement à mon Responsable Pédagogique M Boudal NIANG qui a été présent durant
ces trois années non regrettables et tout le corps administratif qui a été de près ou de loin acteur de
ma formation,
Je voudrais également remercier et témoigner toute ma reconnaissance à tous les cadres de la
MQS qui m’ont considérablement soutenu durant cette période et qui m’ont fait vivre une
expérience enrichissante et pleine d’intérêts. Ainsi qu’à toute personne de l'entreprise avec qui j’ai
pu échanger. Je dis Merci pour votre sens de l’écoute, votre disponibilité et surtout votre humanité.
J’exprime ma profonde gratitude à toute ma famille et je décerne particulièrement une mention
spéciale à mes chers parents sans qui cet accomplissement n’aurait pu se faire. Eux qui m’ont
apporté un soutien indéfectible et des encouragements continus tout au long de mes années
d'études et durant la rédaction de ce mémoire. Merci infiniment.
Daouda TRAORE ii
Abréviations et Acronymes
CEM: Customer Experience Management
CRUD: Create Read Update Delete
DG: Direction Générale
DGA: Direction Général Adjoint
DSD: Direction de la Stratégie et du développement
DMGP: Direction du Marketing Grand Public
DDE: Direction des entreprises
DSC: Direction du Service Client
DOI: Direction des Opérations internationales et Opérateurs
DCIRE: Direction de la Communication Interne et des relations extérieures
DAL: Direction des achats et de la logistique
DRH: Direction des ressources Humaines
DRPS: Direction des Réseaux et Plateformes de Services
DARQ: Direction de l'Audit, des Risques et de la Qualité
DFC: Direction Financier et Comptable
DRJ: Direction de la Réglementation et des Affaires Juridiques
DV: Direction des Ventes
DSI: Direction des Systèmes d’Informations
FCFA : franc de la Communauté financière africaine
GUI: Graphical User Interface
IMSI: International Mobile Subscriber Identity
KPI: Key Performance Indicator
Mo : Mégaoctet
NodeB: Station de base 3G
IDC : International Data Corporation
QoE: Quality of Experience
QoS: Quality of Service
SGBD: Système de Gestion de Base de Données
SQL: Structured Query Language
TCP: Transport Control Protocol
UDP: User Datagram Protocol
Daouda TRAORE iii

Liste des figures

Figure 1:Les directions de la Sonatel [2019] ............................................................................. 4
Figure 2: La Direction de Réseaux Plateforme et Service ......................................................... 5
Figure 3: Fonctionnement du Système décisionnel .................................................................... 9
Figure 4: Architecture d’un Système d’information décisionnel [B4] ..................................... 10
Figure 5: Perspectives des systèmes décisionnels [W3] .......................................................... 13
Figure 6: Diagramme de cas d’utilisation ................................................................................ 14
Figure 7:Diagramme de séquence ............................................................................................ 16
Figure 8: Schéma des caractéristiques des bases de données relationnelles ............................ 21
Figure 9: Application des bases de données relationnelles ...................................................... 22
Figure 10: Caractéristiques des bases de données NoSQL orientées clé/valeur ...................... 23
Figure 11: Application des bases de données NoSQL orientées clé/valeur ............................. 24
Figure 12: Caractéristiques des bases de données NoSQL orientées document ...................... 25
Figure 13: Application des bases de données NoSQL orientées document ............................. 26
Figure 14: Caractéristiques des bases de données NoSQL orientées colonne ......................... 27
Figure 15: Application des bases de données NoSQL orientées colonne ................................ 28
Figure 16: Caractéristiques des bases de données NoSQL orientées graphe ........................... 29
Figure 17: Application des bases de données NoSQL orientées graphe .................................. 30
Figure 18: Exemple de traduction plate en orienté document .................................................. 35
Figure 19: Exemple de traduction par imbrication orientée document .................................... 37
Figure 20: Exemple de traduction hybride en orientée document ........................................... 39
Figure 21: Exemple de traduction éclaté en orientée document .............................................. 42
Figure 22: Modèle Multidimensionnel ..................................................................................... 60
Figure 23 : Modèle Multidimensionnel avec les clés associées ............................................... 60
Figure 24 : interface d'accueil de talend ................................................................................... 61
Daouda TRAORE iv
Liste des tableaux
Tableau 1 Calendrier des activités.............................................................................................. 8

Tableau 2 Description des cas d’utilisation.............................................................................. 15
Daouda TRAORE v
Liste des captures

Capture 1: connexion au serveur MongoDB ............................................................................ 44
Capture 2: connexion du client observation côté serveur ........................................................ 44
Capture 3: connexion du client................................................................................................. 45
Capture 4: initialisation du replicaSet ...................................................................................... 47
Capture 5: ajout des serveurs de réplication ............................................................................. 47
Capture 6 : Observation du statut des serveurs ........................................................................ 48
Capture 7 : Observation de la priorité des serveurs ................................................................. 49
Capture 8: Statuts après simulation de panne du serveur primaire .......................................... 50
Capture 9 : interface Robo 3T .................................................................................................. 51
Capture 10 : interface Studio 3T .............................................................................................. 51
Capture 11 fichiers archivés ..................................................................................................... 55
Capture 12 extraction et connexion à Mongo .......................................................................... 57
Capture 13 insertion dans Mongo ............................................................................................ 58
Capture 14 Capture job ............................................................................................................ 62
Capture 15: job d’une table de dimension date ........................................................................ 63
Capture 16: tmap fonctionnement ............................................................................................ 63
Capture 17 Job de la dimension marque .................................................................................. 64
Capture 18: job de la dimension zone ...................................................................................... 64
Capture 19 : job de fait des appareils les plus utilisés .............................................................. 64
Capture 20 pentaho workbench interface ................................................................................. 65
Capture 21 : page d'authentification et d’accueil pentaho........................................................ 66
Capture 22 : Chargement des données ..................................................................................... 67
Capture 23 : Saiku analytics page d’accueil ............................................................................. 67
Capture 24 : camembert des appareils les plus utilisés suivant la date jour année mois.......... 68
Capture 25 : diagramme des appareils les plus utilisés suivant les jours ................................. 68
Capture 26 : Tableau du minimum, maximum la moyenne la déviation des appareils les plus
utilisés suivant la date .............................................................................................................. 69
Daouda TRAORE vi
Sommaire
Introduction générale................................................................................................................................................. 1
Chapitre I : Présentation du sujet et l'entreprise d'accueil ................................................................. 3
I.1 Contexte: ................................................................................................................................................................ 3
I.2 L’entreprise d’accueil ........................................................................................................................................ 3
I.3 Présentation du sujet ............................................................................................................................................ 7
Conclusion ............................................................................................................................................................................ 8
Chapitre II : Analyse et conception du système décisionnel ............................................................... 9
Introduction ........................................................................................................................................................................ 9
II.1 L’Enjeu des Systèmes D'information décisionnels .................................................................................... 9
II.2 Les principales fonctions de la chaine décisionnelle ............................................................................. 11
II.3 Les perspectives ................................................................................................................................................. 12
II.4 Modélisation du système ............................................................................................................................... 13
A. Diagramme de cas d’utilisation .............................................................................................................................. 14
B. Diagrammes de séquence.......................................................................................................................................... 16
II.5 Conclusion ........................................................................................................................................................... 17
Chapitre III : Généralité sur les SGBD ............................................................................................................ 18
Introduction ...................................................................................................................................................................... 18
III.1 Concepts de base............................................................................................................................................... 18
III.2 Les caractéristiques des SGBD .................................................................................................................... 19
III.3 Comparatif des deux grands groupes....................................................................................................... 20
Conclusion .......................................................................................................................................................................... 31
Chapitre IV : Les Bases de Données NoSQL orientées document: Cas de MongoDB............. 32
Introduction ...................................................................................................................................................................... 32
IV.1 Fonctionnement des SGBD NoSQL orientées document ...................................................................... 32
IV.2 La base de données MongoDB..................................................................................................................... 43
Conclusion .......................................................................................................................................................................... 52
Chapitre V : Réalisation du système décisionnel ...................................................................................... 53
Introduction ...................................................................................................................................................................... 53
V.1 Le Langage de programmation PERL ...................................................................................................... 53
V.2 Réalisation ......................................................................................................................................................... 55
Conclusion générale.................................................................................................................................................... 70
Daouda TRAORE vii

Introduction générale
Ensemble de connaissances consacrées à la création d’outils, la technologie a

aujourd’hui complétement bouleversé notre vie en société. Son évolution rapide nous permet
d’assister davantage à la naissance de nouveaux outils technologiques destinés à améliorer et
à faciliter le quotidien des individus. La création des ordinateurs vers la fin des années trente a
été l’une des étapes marquantes de la révolution technologique. En effet ces dispositifs qui
acceptent les informations et les manipulent, ont permis d’accentuer la productivité et
d’automatiser certaines tâches. L’un des apports majeurs des ordinateurs a été le stockage des
informations qui étaient autrefois détenues dans des registres en papier.
L’avènement de l’internet, réseau informatique à l’échelle mondiale dont l’ambition
est de relier entre eux tous les ordinateurs du monde en fournissant des services à travers un
tiers, fut une autre étape marquante de cette révolution qui est devenue de nos jours un
élément incontournable. Celui-ci combiné avec la capacité de traitement des ordinateurs
produit des données considérables et créent ainsi un océan de données pour la plupart sous
exploitées. Tout cet amas de données donne naissance au Big Data. Dans ce contexte de
données volumineuses, celle-ci renferme des informations qui pourraient permettent des
études curatives, et aussi prévisionnelles. Cet dans ce contexte que ce développe la Business
Intelligence qui nous permettra de traiter de façon efficace ces données afin de ne pas les
stocker juste et les laisser pour ainsi dire sans intérêt.
La collecte de données a toujours existé car même aux temps préhistorique les
Hommes prenaient la mesure de l’environnement ou du gibier à chasser avant d’attaquer.
Aussi avant de s’installer dans une zone observaient autour d’eux afin de se mettre si possible
à l’endroit le mieux agréable. Mais le numérique a rendu possible l’avènement d’une quantité
invraisemblable de données, « nouvel or noir du XXIe siècle ».
Des flots d’octets, un océan de données, un déluge de connaissances. A mesure qu’Internet
tisse sa toile, le volume d’informations numérisées n’en finit plus d’exploser. D’après le
cabinet d’études IDC en 2020, la masse vertigineuse de données serait 50 fois supérieure à ce
qu’elle était en 2012. Et il faudra dix fois plus de serveurs informatiques pour espérer gérer
cette déferlante. Pas uniquement par crainte d’être submergés, mais aussi pour être en mesure
de retrouver, d’extraire et d’exploiter cette nouvelle manne.
C’est aussi dans cette lancée que Fabien Le brusq, Chef de produit Web déclare : « Il faut
toujours tout tagguer ! Même si l’on pense que certaines informations ne seront pas
exploitables, il faut anticiper le tracking. » Cependant tout en faisant attention aux enjeux
autour de l’utilisation de ces données.
La digitalisation des entreprises nous amène à prendre en considération la gestion de ses
données qui ne seront plus perdues comme au temps du papier suite à des catastrophes, des
incendies j’en passe.
Il y a vingt ans, nous stockions encore nos fichiers sur des disques durs de quelques
mégaoctets (Mo). Aujourd’hui, la capacité des outils de stockage a passé le téraoctet (To), et
il n’est plus rare pour les entreprises et les organismes de recherche de manipuler des volumes
supérieurs au pétaoctet (Po).
Daouda TRAORE 1
A la Sonatel au service Monitoring de la qualité de service de la Direction des

Réseaux plateformes et services nous sommes chargés d’assurer une qualité de service des
abonnées sur la voix et la données principalement. Cela passe par la prise en compte et le
traitement des données teste disponible enregistrées sous forme de tableaux. Cependant
malgré la bonne santé de la société il s’avère que les ressources déployé ne sont pas
convenablement exploitées. Souvent sous-utilisés. C’est dans ce contexte que la grande partie
de données sous exploité pouvant répondre si bien exploité au problème dont fait face la
société prend son sens. Un outil d’aide à la décision serait le bienvenu.
Ainsi, ce mémoire présente une étude de gestion de données en prenant comme
exemple la mise en place d’un outil d’aide à la décision pour le service Monitoring de la
qualité de Service. Nous verrons après présentation de notre environnement de travail dans
une première partie, un chapitre consacrée à l’analyse et la conception du système
décisionnel puis des notions de traitement de données en abordant Systèmes de gestion de
base de données, et aussi les Systèmes de gestion de Base de données NoSQL, cas de
MongoDB qui nous permettra de mettre en place notre solution. Avant de terminer, on
présentera les systèmes d’information décisionnels, toujours dans le but d’apporter plus de
compréhension à la partie théorique. Et pour finir, nous verrons la modélisation et la
réalisation de notre système décisionnel.
Daouda TRAORE 2
Chapitre I : Présentation du sujet et l'entreprise d'accueil
I.1 Contexte:
Le secteur des télécommunications est un marché concurrentiel dans la plupart des pays en
général et au Sénégal en particulier. Les opérateurs afin de ne pas être distancer et ainsi
fidéliser leur clientèle se doivent de bien connaître les besoins de ceux-ci et de le leur rendre
accessible. C’est ainsi que la naissance d’outils nouveaux surtout ceux axés sur l’expérience
clients prend son sens. Ces outils deviennent incontournables. L’enjeu étant immense surtout
avec la relance de certains acteurs concurrents. Afin de conserver sa notoriété, et de
consolider ses acquis tout en conquérant de nouvelles parts de marchés. C’est ainsi que le Big
Data prend tout son sens car permettra grâce à ses outils d’offrir aux abonnés et surtout leur
offrir des services présents sous exploités. Les stratégies doivent être établies aussi bien au
niveau technique que commercial.
En effet la 4G étant présente depuis 2016 se voit sous exploités.
C’est dans ce sens que le thème «Mise en place d’un système décisionnel avec application
des données de la SONATEL» afin de trouver une solution valable à la sous-utilisation du
service 4G. Et aussi par cela trouver des moyens de palier au problème ci rencontré afin
d’assurer une bonne gestion des ressources et avoir un retour sur investissement tout en
maintenant bien sûr les services à un niveau de disponibilité et d’efficacité convenable surtout
face à une clientèle de plus en plus exigeante.
I.2 L’entreprise d’accueil
I.2.1 Présentation
La Société Nationale des Télécommunications du Sénégal (SONATEL) est le premier
opérateur de télécommunications au Sénégal et a été créée le 23 juillet 1985 par la loi 85-86
consacrée à la fusion de l’Office des Postes et Télécommunications (OPT) et de Télé Sénégal.
Signataire avec l’État du Sénégal d’une convention de concession d’une durée de vingt ans.
La nécessité de s’adapter au nouvel environnement du monde des télécommunications pousse
la société en 1995 a modifié ses statuts en procédant à une ouverture de son capital.
En septembre 1996, SONATEL innove en mettant à la disposition de ses clients un système
de téléphonie mobile. Puis s’alliant avec France Telecom qui possède actuellement 42% du
capital elle devient privée.
Daouda TRAORE 3
Lors de cette privatisation, France Telecom a d’abord acquis 33.3%, en concluant en même
temps avec l’Etat une option d’achat de 9% du capital à exercer par la suite. France Telecom a
exercé son option en Juillet 1999.
Nous pouvons donc dire que la privatisation de la SONATEL a été conclue sur la base d’une
participation de France Telecom à hauteur de 42.33%. Ce niveau de participation ne devrait
lui assurer en aucun cas le contrôle du destin de l’entreprise pour autant que les autres
actionnaires en particulier l’Etat du Sénégal qui détient 27.67%.
Aujourd’hui Le Groupe SONATEL est titulaire d’une licence d’opérateur global des
télécommunications, encadrée par un cahier des charges qui lui fixe ses obligations en matière
de couverture et de fourniture des services sur l’ensemble du territoire national et lui donne la
possibilité d’aller à la conquête de nouveaux marchés dans l’espace sous régional. Il est
l’opérateur de référence en Afrique de l’Ouest qui offre des solutions globales de
télécommunications dans les domaines du fixe, du mobile, de l’Internet, de la télévision, du
mobile money et des données au service des particuliers et des entreprises. Leader dans tous
ses pays de présence, le Groupe Sonatel a démarré sa croissance externe au Mali en 2002,
puis s’est successivement installé en Guinée et en Guinée Bissau en 2007 et tout dernièrement
en Sierra Léone et au Burkina (2016).
Aujourd’hui le Groupe SONATEL compte plus de 29,7 millions de clients pour plus de 4500
employés répartis sur 6 pays avec un chiffre d’affaire de plus de 1022 milliards de FCFA
I.2.2 Organisation
La SONATEL est composée d’une Direction Générale, d’une Direction Générale
adjointe, des Directeurs des filiales et de plusieurs Directions opérationnelles composées
chacune de plusieurs Départements, Services et Centres techniques.
Figure 1:Les directions de la Sonatel [2019]
Daouda TRAORE 4
I.2.2.a La Direction des réseaux plateforme et Services
La direction des réseaux et plateformes de services (DRPS) comprend cinq pôles :

• Le pôle d’Etude et Planification (DEP) ;
• Le pôle d’Ingénierie (DI) ;
• Le pôle Exploitation (DEX) ;
• Le pôle d’intervention (DINT) ;
• Le pôle de Transformation et de Pilotage de la Performance (TPP).
Notre stage a été effectué au pôle d’exploitation (DEX) plus précisément dans le Services
Monitoring de la Qualité de Service du le Département Services Manager Center- Network
(SMC-N) dont nous vous décrirons l’organisation.
I.2.2.b Organisation du pôle Exploitation (DRPS/DEX)

La direction de l’Exploitation (DEX), est composée de départements qui détiennent
eux aussi des services.
DRPS/DEX/SMC-N
SMS ASC MQS QSM SMO
Figure 2: La Direction de Réseaux Plateforme et Service
DRPS : Direction Réseaux et Plateformes de Service

DEX : Pôle Exploitation
SMC-N : Département Services Manager Center- Network
SMS : Supervision et Maintenance de services
ASC : Accueil Support clients
QSM : Qualité de Service Management
SMO : Service Management Orange Money
MQS : Monitoring de la qualité de service End to End
Daouda TRAORE 5
I.2.2.c Le service MQS

Principales attributions du service monitoring de la qualité de service End to End
(DEX/SMC-N/MQS)
1. Assurer la gestion de la qualité de service bout en bout
 Piloter la qualité de service End to End (E2E) pour l'ensemble des portefeuilles
de services (Voix, SMS, Roaming, DATA) ;
 Détecter et analyser les défauts qui affectent le trafic et les services ;
 Mettre en place et suivre les indicateurs qualité de service sur les services ;
 Participer aux chantiers qualité de service préparatoires des événements
exceptionnels ;
 Mettre en place le dispositif de suivi des événements exceptionnels et piloter le
suivi Qualité de service.
2. Coordonnées l’exploitation de CEM (Customer Experience Management)
 Réaliser les reporting sur les cas d’usage du CEM ;
 Piloter la mise en œuvre des plans d'action issus des détections CEM ;
 Accompagner l'identification et l'implémentation de nouveaux cas d’utilisation.
3. Suivi du roaming
La gestion de la QoS Roaming est prise en charge par le Service Monitoring de la
Qualité de Service End to End au niveau du SMC-N :
 Reporting (journaliers/hebdomadaire) dans la cadre du suivi de la Qualité de
Service basée sur l’analyse des valeurs des indicateurs collectés à partir de
l’outil IRIS (Netscout) et des tests ;
 Ces indicateurs concernent tous les opérateurs qui sont en catégorie de Top 10
Roaming In et Out ;
 Reporting hebdomadaire BRG Border Roaming Gateway concernant la Qualité
de Service aux frontières afin d’empêcher le roaming involontaire.
Lorsque MQS est notifié par mail sur une plainte il chargé d’analyser tout en se basant
sur les informations présentes sur le document et si besoin faire recourt à des précisions
Elle utilise l’expérience client définit par la QoE qui est un indicateur beaucoup plus précis
côté client que la QoS qui se base sur des résultats de l’équipement.
Dans ce service, on veut se mettre à la place du client en utilisant des robots qui effectuent des
tests sur le réseau et les outils informatiques permettant de visualiser la QoE.
Daouda TRAORE 6
Grâce aux résultats des analyses des robots, nous pouvons savoir exactement ce que ressent le
client.
La QoE est plus représentative dans le sens où un équipement peut présenter de bons taux
alors que de nombreux clients n’arrivent pas à utiliser le service.
Ces outils présents aident à l’accomplissement de la tâche afin d’avoir de bons résultats.
I.3 Présentation du sujet

I.3.1 La problématique
L’information est l’arme fatale du XXIème siècle. Celui qui détient l’information, a le
pouvoir. C’est ce que nous rabâchent tous les experts géopolitiques et tous les économistes.
Cependant nous avons un océan de données sous exploité et qui s’agrandit tous les
jours. Les entreprises de nos jours stockent de nombreuses informations dont la plupart non
utilisées, ou encore sous utilisées. Seulement le pouvoir de la donnée dans le pilotage
stratégique des entreprises est aujourd’hui reconnu. Une donnée bien exploitée permet la
production de meilleures prévisions et analyses, tout en respectant une gouvernance éthiques
des données afin d’assurer la sécurité et ainsi respecter les informations personnelles des
utilisateurs. Elle permettra par la suite une meilleure stratégie d’investissement, une stratégie
maintenance avec les informations collectées, une stratégie marketing tout ceci dans le but de
satisfaire la clientèle afin de booster le chiffre d’affaire des entreprises sinon un mixte de
plusieurs afin de s’adapter à l’objectif recherché par l’entreprise concernée.
C’est ainsi qu’au niveau de la SONATEL nous nous sommes rendus compte que
depuis la mise en vente de la technologie LTE sur le marché en 2016 près de trois ans
maintenant celle-ci reste très peu utilisée. Ces raisons pouvant être diverses.
Nous identifions trois cas essentiellement les raisons d’ordre financières, marketing
commerciales et techniques. C’est cette dernière qui fera l’objet de notre étude.
C’est ainsi qu’afin de connaître la sous-utilisation de la technologie LTE déployé on a
décidé de mettre en place un système Décisionnel.
Le service dans notre cas sera utilisé par le service MQS et seulement par les agents
habilités.
I.3.2 Objectifs
Ainsi, l’objectif de ce mémoire est de fournir d’abord une vue d’ensemble sur la
technologie NoSQL en général et celle NoSQL orientée document en particulier. Par la suite
concevoir ce système décisionnel qui nous permettra de décider des actions à entreprendre
afin de résoudre le problème de sous-utilisation de la technologie LTE déployée. Ce mémoire
Daouda TRAORE 7
fera également mention d’autres domaines où la Sonatel pourrait appliquer cette technologie
très prometteuse
I.3.3 Démarche et Méthodologie
Afin d’atteindre les objectifs de ce mémoire il est tout d’abord nécessaire de mener une
recherche documentaire dans l’optique d’avoir une maitrise suffisante de cette technologie
avant de pouvoir en venir au fait. S’en suivra un apprentissage de certains langages de
programmation jugés nécessaires pour la mise en œuvre de notre système. Puis il sera
question de définir le fonctionnement du système mis en place mais également de choisir en
justifiant les différents outils avant de passer à la partie simulation ayant pour but d’offrir une
vue finale de la solution.
I.3.4 Planning effectif du stage

Le tableau 1 ci-dessous nous donne le planning effectif du stage.
Tableau 1 Calendrier des activités
Conclusion
A travers ce premier chapitre, nous avons pu nous placer dans le contexte général de
notre projet en introduisant le domaine de l’application ainsi que le cadre du travail.
La détermination des besoins fonctionnels et non fonctionnels va nous permettre de
mieux clarifier notre application, de bien mettre au point nos objectifs au cours de la phase
suivante, qui est la phase d’incubation.
Daouda TRAORE 8
Chapitre II : Analyse et conception du système décisionnel
Introduction
Le système d'information décisionnel est un ensemble de données organisées de façon

spécifiques, facilement accessibles et appropriées à la prise de décision.
La finalité d'un système décisionnel est le pilotage d'entreprise. Alors que les systèmes de
gestion sont dédiés aux métiers de l'entreprise, les systèmes décisionnels eux sont dédiés au
management de l'entreprise.
Il s’agira après présentation générale des systèmes décisionnels, modéliser notre outil
décisionnel à travers le langage de modélisation Unified Modeling Language (UML) qui fait
partie des notations les plus utilisées aujourd’hui. Parmi les différents diagrammes proposés
par ce langage, nous allons nous servir du diagramme de cas d’utilisation pour décrire les
différentes manières dont un utilisateur peut interagir avec le système et du diagramme de
séquence pour matérialiser les différentes étapes d’une interaction entre les composants du
système.
Figure 3: Fonctionnement du Système décisionnel
Daouda TRAORE 9
II.1 L’Enjeu des Systèmes D'information décisionnels
Dans une organisation, la prise de décisions stratégiques nécessite le recours et le

croisement de multiples informations qui peut concerner plusieurs départements.
Pourtant ces données sont généralement :
 dispersées au sein des départements et non connectées entre elles ;
 Elles peuvent aussi être hétérogènes dans leurs formats techniques et leurs
organisations structurelles ;
 Ou implémentées pour l'action (par construction) et non à des fins d'analyse
 Ou encore volatiles, au sens où leur mise à jour peut conduire à oublier des
informations en somme elles peuvent être obsolètes.
Ce qui en découle c’est que leur exploitation devient difficile en demandant de mobiliser de
nombreuses ressources tant financière que temporelle et cela pour des résultats de faibles
qualités.
C’est à cela qu’un système décisionnel est important car permet non seulement d’avoir un
suivi mais de se projeter afin d’anticiper sur des évènements à venir.
Figure 4: Architecture d’un Système d’information décisionnel [B4]
Daouda TRAORE 10
II.2 Les principales fonctions de la chaine décisionnelle
Les éléments et outils composant la chaîne décisionnelle sont généralement en quatre

catégories correspondant chacune à une fonction spécifique, à une phase du processus
II.2.1 Collecter : Les outils d'ETL (Extract Transform and Load)

Collecter, Nettoyer et Consolider les données de l'entreprise étendue.
La collecte des données est une fonction remplie par une famille d'outils dénommée ETL pour
Extract Transform load. Le système d'information de l'entreprise ne s'est pas bâti en un temps
unique. La majorité des systèmes d'information d'entreprise sont de nature hétérogène pour la
plupart. Bien que la standardisation des échanges entre les divers outils informatiques avance
à grands pas, la disparité des formats des données en circulation est toujours une réalité. C'est
le principal obstacle technologique aux échanges étendus d'informations.
Avant d'être utilisables, les données seront formatées, nettoyées et consolidées. Les outils
d'ETL (Extract Transform load) permettent d'automatiser ces traitements et de gérer les flux
de données alimentant les bases de stockage : un Data warehouse ou un Datamart.
Le Master Data Management, la gestion des données de référence, assure la standardisation et
la traçabilité des données de référence de l'entreprise [W7].
II.2.2 Stocker : Le Data warehouse et le datamart

Les bases de données de production ne sont pas utilisables pour une exploitation
décisionnelle. Les données brutes ne sont pas prêtes à cet usage et par ailleurs les requêtes
décisionnelles sont particulièrement gourmandes en ressources machines.
Les données, au préalable nettoyées et consolidées, seront stockées dans une base
spécialisée: le data warehouse ou le datamart.
Le datamart est une version plus réduite du data warehouse. Le datamart est orienté sujet ou
thème et peut être par exemple utilisé pour des applications de CRM ou de Data Mining.
Le data warehouse ou le datamart sont alimentés par l'outil d'ETL (Extract Transform load). À
noter que le projet Data Warehouse est assez particulier. Il est préférable de le considérer
comme un processus. Le Data Warehouse est en effet en perpétuelle évolution.
Daouda TRAORE 11
II.2.3 Distribuer les informations

Distribuer pour faciliter l’accessibilité des informations selon les fonctions et les types
d’utilisation.
L'information sera perçue en termes de flux et non d'unité de stockage. Afin de dynamiser la
réactivité globale, l'information sera largement distribuée auprès de l'ensemble des
partenaires.
II.2.4. Exploiter : Tableau de bord

Une fois les données stockées, nettoyées, consolidées et accessibles, elles sont utilisables.
Selon les besoins, différents types d’outils d’extraction et d’exploitation seront envisagés.
II.3 Les perspectives
Au sortir de tout, l’entrepôt de données ou datawarehouse nous fournira donc une collection
de données thématiques, intégrées, non volatiles et historisées, organisées pour la prise de
décision.”
- Thématiques pour dire que les données seront organisées par thèmes par activités
majeures ;
- Intégrées avec donc avec divers sources de données ;
- Non volatiles : ne pas supprimer les données de l’entrepôt de données, et
- Historisées : trace des données, suivre l'évolution des indicateurs.
Daouda TRAORE 12
Figure 5: Perspectives des systèmes décisionnels [W3]

Les Systèmes d’information décisionnels devraient être utilisés par toute entreprise qui se
veut une meilleure productivité, une meilleure gestion de ses ressources tant économiques
matérielles qu’humaine
II.4 Modélisation du système

II.4.1 Description générale
Le système décisionnel doit pouvoir fournir d’une part une interface permettant aux
utilisateurs d’effectuer en une observation des informations suivant les axes qu’ils voudront
aussi bien sous forme de tableau que de représentation graphique. Chaque personne habilitée
à l’utilisation aura un login et un mot de passe. Lui permettant d’accéder à la plateforme.
Ainsi les utilisateurs seront invités à s’inscrire pour pouvoir effectuer accéder et visualiser
afin de prendre des décisions.
Le système valide ou pas la connexion selon que l’utilisateur est éligible ou pas ou à entrer ou
pas les bonnes informations de connexion.
D’autre part, il s’agira de mettre en place l’entrepôt de données ou datawarehouse sur
lequel va reposer le système. Pour cette partie, il est possible de déployer un entrepôt local
comme dans le Cloud en s’appuyant sur les plateformes fournissant de tel service. Nous
utiliserons l’option locale. Pour la mise en place de l’entrepôt nous utiliserons Talend
Opération system for Big Data et non le Data Integration de base car ce dernier n’intègre pas
les bases NoSQL. Dans ce qui suit, nous allons présenter la modélisation du système avec le
diagramme de cas d’utilisation et le diagramme de séquence.
Daouda TRAORE 13
II.4.2 Diagramme UML
A. Diagramme de cas d’utilisation
Le diagramme comprend le système et les différents acteurs que sont l’utilisateur,

l’administrateur et le serveur FTP
• Schéma
Figure 6: Diagramme de cas d’utilisation
• Description des cas d’utilisation

Le tableau ci-dessous donne une description des cas d’utilisation :
 Gérer les fichiers sources ;
 visualiser ;
 S’authentifier ;
 Ajouter un module.
Daouda TRAORE 14
Tableau 2 : Description des cas d’utilisation
Gérer les S’authentifier Visualiser Ajouter un

fichiers sources module
Objectifs Déposer les Permettre la Observer les Ajout de module
fichiers connexion pour variations de traitement ou
nécessaires au utiliser le d’informations de visualisation
bon système afin d’analyser
fonctionnement
du système
Acteurs Serveur FTP Utilisateur Utilisateur Administrateur
concernés Administrateur Administrateur Envoi la requête
Envoi la requête Envoi la requête Le serveur
Le serveur Le serveur pentaho lui
Pentaho lui Pentaho lui répond
répond répond
Préconditions Obtenir le Login S’authentifier S’authentifier
et le mot de passe
Post conditions Néant Néant Néant Néant
Scénario Dépôt des Entrer les Accès aux Nouveau
nominal fichiers dans le informations graphes et module de
répertoire d’authentification tableaux visualisation
et l’utilisateur est
authentifier
Scénario Néant L’utilisateur Néant Néant
alternatif n’est pas
autoriser à
s’authentifier
Daouda TRAORE 15
B. Diagrammes de séquence
Dans cette partie nous allons présenter le diagramme de séquences pour les cas d’utilisation :
« Gérer les fichiers sources », « visualiser », «s’authentifier», «Ajouter un module »
Figure 7:Diagramme de séquence
Daouda TRAORE 16
II.5 Conclusion
A ce jour les systèmes décisionnels avec l’avènement de l’outil informatique qui s’épand en
exponentielle devient incontournable. Le BigData le met plus en valeur du fait de ses données
volumineuses. Celles-ci si elles ne sont pas contrôlées seront juste des données « déchets » et
rempliront juste les systèmes de stockage alors que leur exploitation apporte une valeur
ajoutées plus que considérable.
Daouda TRAORE 17
Chapitre III : Généralité sur les SGBD
Introduction
L’approche classique de mise en place d’une application informatique dans une

entreprise, consistait le plus souvent à l’écriture d’un certain nombre de programmes destinés
à l’exploitation d’un ensemble de fichiers qu’il fallait aussi créer. Les principaux problèmes
posés par cette démarche sont : la redondance des informations et la dépendance entre les
données et les programmes qui les manipulent.
Une base de données est un ensemble d’informations structurées permettant la mise en
place d’une série d’applications informatiques destinées à une grande variété d’utilisateurs.
Depuis les années 70, les bases de données relationnelles étaient l'incontournable référence
pour gérer les données d'un système d'information.
En effet dans un contexte bases de données, il est préférable d'avoir un langage de haut
niveau pour interroger les données.
Toutefois, avoir un langage de trop haut niveau comme le SQL ne facilite pas la
manipulation face à certains facteurs comme les 3V (Volume, Vélocité, Variété). Le
relationnel peut difficilement lutter contre cette vague de données. Le NoSQL s'est alors
naturellement imposé dans ce contexte en proposant une nouvelle façon de gérer les données,
sans reposer sur le paradigme relationnel, d'où le "Not Only SQL".
Ceux sont ces deux grands groupes qui feront l’objet d’étude de notre chapitre.
III.1 Concepts de base

Un Système de Gestion de Base de Données (SGBD) est un logiciel (ou un ensemble
de logiciels) permettant de manipuler les données d'une base de données. Manipuler, c'est-à-
dire sélectionner et afficher des informations tirées de cette base, modifier des données, en
ajouter ou en supprimer regroupé en quatre opérations étant souvent appelé "CRUD", pour
Create, Read, Update, Delete).
Le SGBD nous permet donc d’administrer une base de données.
Une base de données, est une collection d’informations organisées de façon à être
facilement accessibles, administrées et mises à jour. Cela pourrait tout simplement être
résumé en une collection d’informations organisées de façon à être administré par un SGBD.
Généralement basés sur un modèle client-serveur. C'est-à-dire que la base de
données se trouve sur un serveur qui permet l’hébergement de la base de données, et pour
interagir avec cette base de données, il faut utiliser un logiciel "client" qui va interroger le
Daouda TRAORE 18
serveur et transmettre la réponse que le serveur lui aura donnée. Le serveur peut être installé
sur une machine différente du client ; c'est souvent le cas lorsque les bases de données sont
importantes. Ce n'est cependant pas obligatoire.
Par conséquent, lorsque vous installez un SGBD basé sur ce modèle, vous installez en réalité
deux choses au moins : le serveur et le client.
Chaque requête (insertion/modification/lecture de données) est faite par
l'intermédiaire du client. Nous avons donc besoin d'un langage pour discuter avec le client,
pour lui donner les requêtes que nous souhaitons effectuer. Dans le général ce langage est le
SQL.
III.2 Les caractéristiques des SGBD
Elle comprend habituellement un ensemble de tables (comme les feuille de calculs

sous Excel). Ces tables ont des relations entre-elles, comme la liste des clients et la liste des
commandes. A chaque client, une ou plusieurs commandes. A chaque commande un client.
C’est ce qu’on appelle une relation, d’où le terme SGBDR, “R” pour relationnel.
Les bases de données peuvent donc être classées par le type de contenu qu’elles renferment :
bibliographique, plein texte, images ou des nombres. Les propriétés ACID et BASE
propriétés Chimiques dans la détermination du pH d’une solution sont utilisés également ici
pour définir une base de données relationnelle SQL et NoSQL.
III.2.1 Les Base de données Relationnelles SGBDR
Les propriétés dites ACID sont celles mettant en rapport les problématiques d’une base de
données relationnelle pour les transactions (séquences d'opérations/requêtes) :
 Atomicité : une transaction s’effectue entièrement ou pas du tout ;
 Cohérence : le contenu d’une base doit être cohérent au début et à la fin d’une
transaction ;
 Isolation : Les modifications d’une transaction ne sont visibles/modifiables que quand
celle-ci a été validée ;
 Durabilité : Une fois la transaction validée, l’état de la base est permanent (non affecté
par les pannes ou autre).
Toutefois, ces propriétés ne sont pas applicables dans un contexte distribué tel que le NoSQL.
En effet, prenons l'exemple d'une transaction de cinq opérations (lecture/écriture) : cela
Daouda TRAORE 19
implique une synchronisation entre cinq serveurs pour garantir l'atomicité, la cohérence et
l'isolation. Au final, cela se traduit par des latences dans les transactions (en cours et en
concurrence). Ce qui n'est pas tolérable lorsque justement on veut éviter ces latences en
distribuant les calculs.
Le problème s'aggrave encore lorsque l'on distribue les données car il va falloir répliquer
chaque donnée. Pourquoi ? Tout simplement parce que si un serveur tombe en panne, il faut
pouvoir garantir de retrouver toutes les données présentes sur ce serveur, donc on fait de la
réplication. Mais cela veut dire également qu'il va falloir synchroniser toutes mises à jour
avec tous les réplicas de la donnée !
III.2.2 les Bases de données NoSQL
Du coup, les propriétés BASE ont été proposées pour caractériser les bases NoSQL :
 Basically Available : quelle que soit la charge de la base de données
(données/requêtes), le système garantie un taux de disponibilité de la donnée ;
 Soft-state : La base peut changer lors des mises à jour ou lors d'ajout/suppression de
serveurs. La base NoSQL n'a pas à être cohérente à tout instant ;
 Eventually consistent : À terme, la base atteindra un état cohérent
Ainsi, une base de données NoSQL relâche certaines contraintes, telles que la
synchronisation des réplicas, pour favoriser l'efficacité.
Le parallèle ACID / BASE repris du domaine de la chimie permet d'appuyer là où ça
fait mal: la concurrence. En effet la difficulté des transactions gérées par les bases de données
relationnelles est donc rendu plus évidente pour le temps de réponse en relâchant cette
contrainte impossible à maintenir.
III.3 Comparatif des deux grands groupes
Ce schéma comparatif confronte les principales caractéristiques des bases SQL et NoSQL, en
établissant la distinction entre les 4 grandes catégories de bases NoSQL (NoSQL clé/valeur,
NoSQL orienté document, NoSQL colonne et NoSQL graphe).
Pour chaque type de SGBD, nous aurons une synthèse comparative détaillant les choix
effectués et l’accent sera mis sur les cas d’usage.
Daouda TRAORE 20
III.3.1 LES BASES DE DONNEES RELATIONNELLES

 Caractéristiques
Conçus pour répondre à une multiplicité d’usages, les SGBDR (systèmes de bases de
données relationnels) sont adaptés aux projets qui nécessitent un bon équilibre entre la
complexité des données à traiter et le volume. La plupart de ces bases utilisent le SQL comme
langage standard d’accès aux données. Contrairement aux bases NoSQL, leur organisation en
table réduit leur usage au traitement des données structurées. Les bases SQL sont donc peu
adaptées aux médias sociaux, aux flux vidéo et audio, à l’internet des objets et de façon
générale au traitement des données fortement hétérogènes. Nous pouvons prendre l’exemple
d’une entreprise qui souhaite stocker des données météorologiques, par nature très hétérogènes
(car les sources, mesures, schémas et unités utilisés seront très différents). Dans un tel contexte
métier, le schéma statique fortement structuré de la base relationnelle ne conviendra pas. Nous
préfèrerons un modèle plus souple et évolutif offert par les bases NoSQL.
Le schéma ci-dessous l’illustre bien avec les différents niveaux :
3 : pour très adapté
2 : pour moyennement adapté
1 : pour peu adapté
Figure 8: Schéma des caractéristiques des bases de données relationnelles
Daouda TRAORE 21
 Type d’application
En revanche, la richesse fonctionnelle des bases relationnelles et la robustesse de leur

implémentation ACID (atomicité, cohérence, isolation, durabilité) les rend particulièrement
adaptées à la gestion des données stratégiques (transaction financières, applications gérant des
données financières pour ne citer que ceux-là).
Au final, les systèmes relationnels privilégient la cohérence et l’intégrité des données plutôt
que leur haute disponibilité comme nous l’avons déjà mentionné dans le grand point
précédent (II.3). Ce modèle convient bien aux données de gestion qui sont souvent très
structurées, avec des besoins de manipulation à partir de plusieurs briques logicielles clientes
et des besoins de recherches multicritères ainsi que des manipulations complexes. Les
volumes de données étant généralement assez modestes dans les applications de gestion, il est
rarement nécessaire de distribuer le traitement, ce qui confirme l’intérêt de recourir aux Base
de données relationnelles dans ce type de projets.
Figure 9: Application des bases de données relationnelles
Daouda TRAORE 22
III.3.2 LES BASES DE DONNÉES NoSQL ORIENTÉES CLÉ/VALEUR

Les bases de données NoSQL orientées clé/valeur constituent la forme la plus simple
de base NoSQL. Elles sont souvent utilisées pour des projets applicatifs qui nécessitent des
performances élevées mais qui reposent sur des jeux de données relativement simples.
La richesse fonctionnelle des bases NoSQL orientées clé/valeur est bien inférieure à celle
offerte par les bases relationnelles. A titre d’exemple, une base comme Redis permettra de
gérer des transactions, enchaîner des commandes (pipeline) ou gérer des listes, mais en aucun
cas d’effectuer des recherches plein texte ou du géo-spatial. La représentation des données ne
facilitera donc pas le travail du gestionnaire de la base. Par contre, une base de données
NoSQL clé/valeur conviendra parfaitement si vous avez besoin d’effectuer des recherches très
rapides. Nous pouvons prendre l’exemple d’une application mobile de commande sur
smartphone.
Figure 10: Caractéristiques des bases de données NoSQL orientées clé/valeur
Daouda TRAORE 23
Pour ce type d’usage, le temps de réponse sera primordial. Les bases NoSQL
clé/valeur conviennent bien à cette configuration car elles peuvent être facilement
dimensionnées pour répondre aux besoins en termes de traitement et de trafic. De même, elles
seront efficaces dans le cadre de la gestion de profils utilisateur ou produit.
Au final, ce type de base est un choix intéressant dans l’hypothèse où les données sont
codées de multiples façons sans schéma rigoureux, si nous avons besoins de performances et
si nous n’avons pas à réaliser de recherches poussées.
Figure 11: Application des bases de données NoSQL orientées clé/valeur
Daouda TRAORE 24
III.3.3 LES BASES DE DONNÉES NoSQL ORIENTÉES DOCUMENT
Contrairement aux bases NoSQL de données de type clé/valeur, les bases orientées document
imposent une structure aux données. Au lieu de conserver les données non structurées dans ce
qui constitue la « valeur », elles les décrivent dans une véritable structure de documents (très
souvent au format JSON, ou XML). Ainsi, les bases NoSQL orientées document peuvent être
utilisées pour des systèmes de gestion de contenus. Par contre, elles seront peu indiquées pour
le traitement de transactions très complexes. Au niveau de leur richesse fonctionnelle, ces
bases sont supérieures aux modèles NoSQL clé/valeur (sans pour autant égaler les bases
relationnelles). Une base comme MongoDB ou Lucene permettra de réaliser des recherches
relativement poussées : plein texte, par synonymes, géo-spatiale.
Pour revenir sur les usages, on peut souligner que les bases NoSQL orientées documents
Figure 12: Caractéristiques des bases de données NoSQL orientées document
Daouda TRAORE 25
Elles sont particulièrement indiquées pour les blogs, ces derniers étant essentiellement
constitués de textes (articles, commentaires) et de listes (mots-clés, catégories).
Dans son ouvrage « les bases NoSQL et le Big data », Rudi Bruchez souligne l’intérêt de faire
appel à ce type de base dans un tel contexte : « Un moteur NoSQL orienté documents, comme
MongoDB ou CouchDB, est particulièrement indiqué pour ce genre d’application, auquel on
peut ajouter les applications de messagerie, les bases de connaissance, les magazines. Il n’y a
aucun avantage à utiliser un moteur relationnel dans ce type d’application.
Pour les fonctionnalités de recherche, les index des moteurs relationnels ne seraient d’aucune
utilité sur du texte long. L’indexation en plein texte des documents JSON avec un outil
comme ElasticSearch est donc la meilleure solution.
NB : Classiquement, le traitement des données spatiales n’est pas l’apanage des bases NoSQL,
ce qui explique le classement effectué dans le tableau comparatif. Cela dit, plusieurs moteurs
NoSQL ont commencé à implémenter des fonctionnalités de calcul spatial, comme les calculs
de distance entre les points de MongoDB.
Figure 13: Application des bases de données NoSQL orientées document
Daouda TRAORE 26
III.3.4 LES BASES DE DONNÉES NoSQL ORIENTÉES COLONNE
Au même titre que le modèle orienté graphe, les bases de données NoSQL orientées
colonne peuvent être une bonne solution pour des usages de type reporting et applications BI.
Les besoins de reporting impliquent de faire des recherches à travers de grandes quantités de
données bien structurées, afin d’effectuer des calculs d’agrégation sur plusieurs axes
d’analyse. Pour ce type de tâches, on se tournera naturellement vers une base relationnelle
capable de manipuler directement des structures multidimensionnelles.
Figure 14: Caractéristiques des bases de données NoSQL orientées colonne
Daouda TRAORE 27
Lorsque les volumes à traiter sont importants, la nécessité de distribuer le traitement
conduira à se tourner vers le NoSQL. Dans une telle hypothèse, l’option moteur orienté
colonnes est recommandée, comme HBase ou Cassandra quitte à stocker des données pré-
calculées et dupliquées selon plusieurs clés correspondant aux axes d’analyse, et à profiter de
traitements en MapReduce (patron d'architecture de développement informatique, inventé par
Google, dans lequel sont effectués des calculs parallèles, et souvent distribués, de données
potentiellement très volumineuses, typiquement supérieures en taille à 1 téraoctet.). Dans les
cas d’usage les plus courants, on peut évoquer la recherche sur Internet, les applications Web
à grande échelle ainsi que les applications analytiques capables de traiter des péta-octets de
données.
Figure 15: Application des bases de données NoSQL orientées colonne
Daouda TRAORE 28
III.3.5 LES BASES DE DONNÉES NoSQL ORIENTÉES

GRAPHE
Les bases NoSQL orientées graphe sont un peu plus généralistes et peuvent convenir à
des projets impliquant la gestion de données stratégiques car elles sont davantage orientées
complexité que volume. Elles répondront mieux aux besoins des applications BI et
analytiques qu’aux problématiques de gestion opérationnelle, dès lors que de gros volumes de
données entrent en jeu. Par contre, si les volumes sont peu importants, une base relationnelle
pourra être privilégiée. Cela s’explique par les besoins de reporting, qui impliquent de faire
des recherches à travers de grandes quantités de données bien structurées afin d'effectuer des
calculs d'agrégation sur plusieurs axes d'analyse.
Figure 16: Caractéristiques des bases de données NoSQL orientées graphe
Daouda TRAORE 29
C’est donc uniquement lorsque le volume de données devient important que la base
NoSQL sera préférée au modèle relationnel dans le domaine de l’analytique. Pour rester sur
les usages, les bases de données orientées graphe conviendront bien aux réseaux sociaux ou
aux moteurs de recommandations pour leur faculté à créer des associations entre des éléments
de données.
Autre exemple, elles trouveront leur place dans le cadre du développement d’une plateforme
permettant d’associer un grand nombre de requêtes et de mots clés à des informations
techniques, juridiques, médicales.
Figure 17: Application des bases de données NoSQL orientées graphe
Daouda TRAORE 30
Conclusion
Les bases de données sont donc multiples et diverses selon le domaine d'étude ou le
projet que nous voulons mettre en place. Cependant afin de ne pas faire le mauvais choix nous
devons avant de choisir connaître les force s et les faiblesses de ses bases afin d’en tirer le
maximum de celle, choisis. Cependant il faut tenir compte des perspectives du projet afin de
ne pas mettre les utilisateurs futures dans des difficultés.
Notre choix portés sur le choix des Base de données orientées document c’est ce qui
fera l’objet d’étude du prochain chapitre.
Daouda TRAORE 31
Chapitre IV : Les Bases de Données NoSQL orientées

document: Cas de MongoDB
Introduction
Depuis quelques années, le volume de données à traiter sur le Web a mis à rude
épreuve les SGBD relationnels, qui ont été jugés non adaptés à de nombreuses montées en
charge. Les grands acteurs du web comme Google, Amazon, LinkedIn ou Facebook, ont été
amenés à créer leurs propres systèmes de stockage et de traitement de l’information (BigTable,
Dynamo, Cassandra). Des implémentations d’architectures open source comme Hadoop et des
SGBD comme HBase, Redis, Riak, MongoDB ou encore CouchDB ont permis de démocra-
tiser ce nouveau domaine de l’informatique répartie. On distingue plusieurs modèles de
données parmi les SGBD NoSQL du moment : clé-valeurs, orienté colonnes, documents et
graphes. Plus le modèle est complexe, moins le système est apte à évoluer rapidement en
raison de la montée en charge.
Notre étude portera sur les SGBD NoSQL orientées document.
IV.1 Fonctionnement des SGBD NoSQL orientées document

Ces systèmes reposent également sur le paradigme [clé, valeur], et la valeur dans ce cas est un
document.
Ce document a une structure arborescente : il contient une liste de champs, un champ est
associé à une valeur qui peut-elle même être une liste. Ces documents sont principalement de
type JSON ou XML.
Dans le modèle orienté documents, les données sont organisées en collections de

documents. Nous utiliserons deux constructeurs :
− [] pour représenter une structure formée d’un ou plusieurs attributs, et
− {} pour représenter un ensemble.
Définition : Une collection C est définie par (NC, EC) où
− NC est le nom de la collection,
− EC = {d1, . . ., dt} est un ensemble de documents de 1 à t.
La structure des documents est définie par l’intermédiaire d’attributs (pouvant s’apparenter à
des couples clé/valeur où le nom de l’attribut est la clé).
Daouda TRAORE 32
Nous distinguons les attributs simples dont les valeurs sont atomiques, des attributs
composés dont les valeurs sont elles-mêmes des documents appelés documents imbriqués.
Définition : Un document di est défini par (Si, Vi) où
− Si = [a1,..., anai] est le schéma du document formé par un ensemble d’attributs,
− Vi = [a1 : v1,..., anai : vnai] est la valeur du document.
Il est important de noter que le schéma est inhérent à chaque document. Dans les systèmes
NoSQL orientés documents, chaque document à son propre schéma, pouvant varier d’un
document à l’autre, même au sein d’une même collection.
Un attribut simple ak peut correspondre à une seule valeur atomique vk ou un ensemble de
valeurs atomiques [𝑣𝑘1, 𝑣𝑘2,…].
Un attribut composé ak peut être composé, c’est-à-dire constitué par une structure imbriquée
Sk. Celle-ci peut être mono-valuée (structure plate) ak[Sk], soit multi-valuée ak{[Sk]}.
Exemple : Ci-dessous nous présentons un document di décrivant une personne.
di = (
[id,nom,prenom,daten[jour,mois,annee],telephone{[numero]}],
[id:12345,
nom:”TRAORE”,
prenom:”Daouda”,
daten: [jour:”11”,mois:”12”,annee:”1991”],
telephone : {[numero:”77”],[numero:”578”]}]
)
L’attribut composé telephone pourrait être un attribut simple dont la valeur est constituée d’un
ensemble de valeurs, c’est-à-dire telephone : {”77”, ”578”}.
Les sous-sections suivantes présentent 4 processus de traduction, en NoSQL orienté
documents, d’un entrepôt de données multidimensionnelles en constellation.
 Processus de traduction plate en orienté documents

Ce premier processus repose sur une dé-normalisation des données du schéma en
constellation.
A chaque fait F ∈ FS et ses dimensions associées SS(F) correspond une collection de même
nom (NF, EF). Chaque instance du fait est traduite par un document di. Les attributs
représentant les mesures du fait et les attributs de dimensions sont contenus dans un même
document plat sans imbrication.
Un document di est défini par un schéma Si constitué de la manière suivante :
− id est l’identifiant du document,
Daouda TRAORE 33
− chaque mesure de MF forme un attribut (𝑘,𝐹) simple,

− chaque attribut de ⋃𝐷𝑗 ∈ 𝑆(𝐹) 𝐴𝐷𝑗 forme un attribut ak simple.
Exemple : L’expression ci-dessous présente une collection obtenue et détaille un document :
{
...,
di = (
[id,
idUser, nom, langage, time_c, time_z,
city, country, population, zone,
jour, mois, nom_mois, annee,
sujet, categorie],
[id:12345,
idUser:”C02265”,nom:”ingc”,langage:”français”, temps_c:”Dakar”, temps_z:”Senegal
ville:”Dakar”, pays:”Senegal”, population: 15000000, zone:”Afrique-Ouest”,
jour:”18-12-2019”, mois:”12-2019”, nom_mois:”Decembre”, annee:2015,
sujet:”Basket”,categorie:”sport”],
),
...
}
La Figure suivante présente sous une forme graphique le document di constitué par un
ensemble d’attributs simples issus des mesures et des attributs des dimensions liées.
Cette implantation évite l’utilisation des jointures entre le fait et les dimensions, mais génère
un important niveau de redondance par duplication des données des dimensions.
Daouda TRAORE 34
di-1
id 12345
idUser C02265
nom ingc
langage français
temps_c Dakar
temps_z Senegal
ville Dakar
di pays Senegal
population 15000000
zone Afrique-Ouest
jour 18-12-2019
mois 12-2019
nom_mois Decembre
annee 2019
sujet Basket
categorie sport
di+1
Figure 18: Exemple de traduction plate en orienté document
 Processus de traduction par imbrication en orienté documents
Ce modèle ci tire profit des possibilités d’imbrication offertes par le modèle orienté
documents. Il combine l’utilisation d’attributs simples et d’attributs composés. Comme
précédemment, à chaque fait F∈FS et ses dimensions associées SS(F) correspond une
collection de même nom (NF, EF). Chaque instance du fait est traduite par un document di.
L’imbrication est utilisée pour rassembler les attributs représentant les mesures du fait. De
même, les attributs de chaque dimension associée SS(F) sont rassemblés dans un même
attribut composé.
Un document di est défini par un schéma Si constitué de la manière suivante :
− un attribut composé est défini pour le fait, et chaque mesure de MF forme un attribut (𝑘,𝐹)
simple imbriqué,
Daouda TRAORE 35
− un attribut composé est défini pour chaque dimension, chaque attribut (𝑘,𝐷𝑗) de la
dimension Dj forme un attribut simple imbriqué.
Exemple : Considérons l’instance utilisée dans l’exemple précédent, que nous restructurons
ci-dessous en fonction de l’approche par imbrication :
{
...,
di = (
[id,
User[idUser,nom,langage,temps_c,temps_z],
Location[ville,pays,population,zone],
Temps[jour,mois,nom_mois,annee],
Thème[sujet,categorie],
],
[Id:12345,
User: [idUser:”C02265”, nom:”ingc”, langage:”french”,
temps_c:”Dakar”, temps_z:”Senegal”],
Location: [ville:”Dakar”, pays:”Senegal”, population: 15000000, zone:”Afrique-Ouest”],
Temps:[jour:”18-12-2019”, mois:”12-2019”, nom_mois:”Decembre”, année:2019],
Thème:[topic:”Basket”,categorie:”sport”],
],
),
...
}
La Figure qui suit présente sous une forme graphique le document di constitué par un
ensemble d’attributs composés issus du fait (imbrication des mesures) et de chaque dimension
associée (imbrication des attributs de la dimension).
Daouda TRAORE 36
di-1
id 12345
idUser C02265
User nom ingc
langage francais
temps_c Dakar
temps_z Senegal
ville Dakar
Location pays Senegal
di population 15000000
zone Afrique-Ouest
jour 18-12-2019
Time mois 12-2019
nom_mois Decembre
Thème année 2019
sujet Basket
categorie sport
di+1
Figure 19: Exemple de traduction par imbrication orientée document
 Processus de traduction hybride en orienté documents
Comme les approches précédentes, une traduction hybride rassemble au sein d’une
même collection les données issues d’un fait FFS et des dimensions associées SS(F).
Les attributs des dimensions sont convertis en attributs simples, à plat sans imbrication, et
stockés dans un document de la collection, à raison d’un document par dimension. Les
mesures du fait sont converties en attributs simples, à plat sans imbrication, et stockés dans un
document de la même collection. Les documents des faits contiennent également les
références aux documents représentant les dimensions associées.
Pour chaque instance de dimension, un document di est défini par un schéma Si constitué de
la manière suivante :
− id est l’identifiant du document, correspondant à la racine 𝑖𝑑𝐷𝑗 de la dimension,
− chaque attribut (𝑘,𝐷𝑗) de la dimension Dj forme un attribut simple.
Daouda TRAORE 37
Pour chaque instance du fait, un document di est défini par un schéma Si constitué de la
manière suivante :
− chaque mesure de MF forme un attribut 𝑚𝑘𝐹 simple,
− pour chaque dimension DjSS(F) associée, un attribut simple 𝑖d𝐷𝑗 est ajouté référençant un
document lié.
Exemple : Dans l’approche hybride, un document est constitué pour chaque instance des
dimensions ainsi qu’un autre document pour l’instance du fait. Nous obtenons les documents
définis ci-dessous :
{
...,
𝑑Tweet= (
[id,
idUser,ville,jour, sujet,
Repost_NB],
[id:12345,
idUser:”C02265”, city:”Paris”, day:”03-31-2015”, topic:”foot”,
Retweet_NB:200],
), 𝑑User(
[idUser,nom,langage,temps_c,temps_z],
[idUser:”C02265”,nom:”ingc”,langage:”francais”,temps_c:”Dakar”,
temps_z:”Senegal”],
),
𝑑Location = (
[ville,pays,population,zone],
[ville:”Dakar”, Pays:”Senegal”, population:15000000,
zone:”Afrique-Ouest”],
),
𝑑Temps = (
[jour,mois,nom_mois,annee],
[jour:”18-12-2019”,mois:”12-2019”,nom_mois:”Decembre”,
annee: 2019],
),
𝑑Theme= ([sujet,categorie],
[sujet:”Basket”,categorie:”sport”],
),
...
}
Daouda TRAORE 38
La Figure suivante présente sous une forme graphique les documents, dTweet 𝑑User,
𝑑Location, 𝑑Temps, 𝑑Theme constitués par un ensemble d’attributs simples issus respectivement du fait
et de chaque dimension.
Elle évite la redondance des données des dimensions des deux modèles précédents, mais
introduit une hétérogénéité dans les structures des documents placés dans la même collection.
Contrairement aux approches précédentes, l’approche hybride nécessite l’utilisation d’auto-
jointures pour retrouver les documents de dimensions liés aux documents des faits au sein de
la collection.
di-1
id 12345
idUser C02265
ville ingc
diTweet jour 18-12-2019
sujet Basket
Retweet_NB 200
idUser C02265
nom ingc
diUser langage français
temps_c Dakar
temps_z Senegal
ville Dakar
pays Senegal
diLocation continent Afrique
population 15000000
zone Afrique-Ouest
jour 18-12-2019
diTemps mois 12-2019
nom_mois Decembre
annee 2019
sujet Basket
diThème categorie sport
Figure 20: Exemple de traduction hybride en orientée document
Daouda TRAORE 39
 Processus de traduction éclatée en orienté documents

Une traduction éclatée distribue les données au sein de plusieurs collections : les
données issues d’un fait FFS sont placées dans une première collection, et les données de
chaque dimension associée SS(F) sont placées dans des collections distinctes (une
collection par dimension).
Les attributs des dimensions sont convertis en attributs simples, à plat sans imbrication,
et stockés dans un document de la collection dédiée, 𝐶𝐷𝑗. Les mesures du fait sont
transformées en attributs simples, à plat sans imbrication, et enregistrées dans un document
d’une autre collection CF. Les documents des faits contiennent également les références
aux documents représentant les dimensions associées, stockées dans les collections des
dimensions.
Pour chaque instance de dimension, un document di𝐶𝐷𝑗 est défini par un schéma Si
constitué de la manière suivante :
− id est l’identifiant du document, correspondant à la racine 𝑖d𝐷𝑗 de la dimension,
− chaque attribut 𝑎 (𝑘, 𝐷𝑗) de la dimension Dj forme un attribut simple.
Pour chaque instance du fait, un document di𝐶𝐹 est défini par un schéma Si constitué de la
manière suivante :
− chaque mesure de MF forme un attribut (𝑘,𝐹) simple,
− pour chaque dimension DjSS(F) associée, un attribut simple 𝑖d𝐷𝑗 est ajouté référençant un
document lié.
Exemple : dans l’approche éclatée, un document est constitué pour chaque instance des
dimensions ainsi qu’un autre document pour l’instance du fait. Ces documents sont mis dans
des collections distinctes. Nous obtenons les documents définis ci-dessous :
{
...,
𝑑𝑖 = (
[id,
idUser,ville, jour, topic,
Repost_NB],
[id:12345,
idUser:”C02265”, ville:”Dakar”, jour:”03-31-2015”, sujet:”Basket”,
Retweet_NB:200],
),
...
}
Daouda TRAORE 40
{
...,
𝑑𝑈ser = (
[idUser,name,language,time_c,time_z],
[idUser:”C02265”,name:”ingc”,language:”français”,time_c:”Dakar”,
time_z:”Senegal”],
),
...
}
{
...,
𝑑Location = (
[ville,pays,population,zone],
[ville:”Dakar”,pays:”Senegal”,population:15000000,
zone:”Afrique-Ouest”],
),
...
}
{
...,
𝑑𝑇emps = (
[jour,mois,nom_mois,annee],
[jour:”18-12-2019”,mois:”12-2019”,nom_mois:”Decembre”,
annee:2019],
),
di+1,
...
}
{
...,
di-1,
𝑑Theme= (
[sujet,categorie],
[sujet:”Basket”,categorie:”sport”],
),
...
}
Daouda TRAORE 41
La Figure ci-dessous présente sous une forme graphique les documents, dTweet 𝑑User,
𝑑Location, 𝑑Temps, 𝑑Theme appartenant respectivement aux collections, CTweet CUser, CLocation, CTemps,
CTheme. Les documents sont formés d’un ensemble d’attributs simples issus respectivement du fait
et de chaque dimension.
id 12345
idUser C02265
ville ingc
diTweet jour 18-12-2019
sujet Basket
Retweet_NB 200
idUser C02265
nom ingc
diUser langage français
temps_c Dakar
temps_z Senegal
ville Dakar
pays Senegal
diLocation continent Afrique
population 15000000
zone Afrique-Ouest
jour 18-12-2019
mois 12-2019
diTemps nom_mois Decembre
annee 2019
Di+1
sujet Basket
diThème categorie sport
Figure 21: Exemple de traduction éclaté en orientée document
Comme la précédente, elle évite la redondance des données des dimensions des deux modèles
précédents et place les documents dans différentes collections structurellement homogènes.
Daouda TRAORE 42
Contrairement aux deux premières approches, l’approche éclatée nécessite également

l’utilisation de jointures pour retrouver les documents.
Il existe plusieurs bases de données orientées document notamment CouchDB, Amazon
DynamoDB, OrientDB, Mark Logic, RethinkDB, MongoDB c’est cette dernière que nous
utiliserons.
IV.2 La base de données MongoDB
La solution MongoDB a été créée en 2009 par la société 10gen afin de répondre aux
besoins de la société en termes de traitement et de stockage de volumes de données
importants.
C’est un Système de gestion de base de données NoSQL qui utilise le modèle de
stockage par document. Une base de données contient des collections de documents.
Les documents sont écrits au format BSON qui est le format binaire de JSON.
Un document représente ici une entité du système. Il contient les caractéristiques de cette
entité.
Chaque collection de la base de données est composée de zéros ou plusieurs documents il
représente ce qu’est la table dans un SGBD relationnel.
Les documents d’une même collection n’ont pas à être du même format un document nous
sommes libre d’avoir des documents de format différents dans une même collection peut
contenir des sous documents.
La représentation textuelle des champs est automatiquement sauvegardée en format binaire
(BSON).
IV.2.1 Implémentation de notre base dans MongoDB
L’installation de MongoDB est relativement simple aussi bien sur Linux sur Windows
comme sur Mac. Nous prendrons soin de la présenter en annexe.
Nous aurons à configurer la réplication des données qui est un facteur important
surtout en entreprise afin d’avoir toujours une sauvegarde en cas de pannes et ne pas perdre ni
perturber le système en place.
Après l’installation de MongoDB vous devez lancer le server. Vous obtiendrez si tout
a été bien configuré en tapant : mongod --port 27017 ou tout simplement mongod,
Daouda TRAORE 43
Un résultat similaire à ceci :
Capture 1: connexion au serveur MongoDB
Assurez-vous de la dernière ligne signifiant que le serveur est bien en attente de connexion
sur le port 27017 étant le port par défaut mais vous pouvez choisir un autre port par exemple
27018.
Maintenant faudrait lancer le client pour pouvoir administrer la base.
Pour cela il faut ouvrir et taper dans un nouveau terminal mongo --port 27017 ou tout
simplement mongo et on devrait voir apparaître les 2 lignes côté serveur
Capture 2: connexion du client observation côté serveur
Daouda TRAORE 44
Et côté client :
Vous constaterez que la main vous a été donnée.
Capture 3: connexion du client
Puis affichons les bases de données présentes et choisissons celle qui nous intéresse en
faisant use le nom de la base de donnée vous pouvez créer un utilisateur admin en utilisant la
base admin afin d’y stocker ses informations.
 Mise en place du ReplicaSet

MongoDB utilise pour cela une architecture basée sur le principe « maître/esclave ».
Le serveur primaire "Primaire", à qui toutes les requêtes sont envoyées (lecture/écriture), va
s’occuper de gérer la cohérence des données. Ainsi, lors d’une mise à jour, une réplication est
effectuée sur les serveurs secondaires "Secondaire".
Cependant, si nous restons sur une architecture de la sorte, nous ne sommes pas tolérants aux
pannes puisque le serveur primaire reste un point critique. Nous allons donc rajouter un
Daouda TRAORE 45
arbitre, dont la tâche est de vérifier l’état du réseau. Ainsi, dès que le primaire tombe, un
système de vote va permettre d’élire le secondaire qui remplacera le serveur tombé en panne.
Nous sommes donc tranquilles : cette architecture tient tant qu’au moins un serveur tourne.
C’est ce que l’on appelle un ReplicaSet.
Un ReplicaSet doit contenir au minimum 3 serveurs (1 Primaire et 2 Secondaire) pour garantir

un minimum de tolérance aux pannes. Un ReplicaSet peut contenir jusqu’à 50 serveurs ;
toutefois lorsqu’un vote a lieu pour élire le nouveau Primaire, au maximum 7 peuvent
participer à cette élection (les premiers ayant répondu à l’Arbitre).
Pour cela, les paramètres de chaque serveur doivent être définis :
1. Un nom de ReplicaSet : rs0

2. Un port d’écoute pour chaque serveur : 27018 (à incrémenter)
3. Créer un répertoire dédié : /data/R0S1 (ReplicaSet 0/Serveur 1), /data/R0S2
(ReplicaSet 0/Serveur 2), /data/R0S3 (ReplicaSet 0/Serveur 3)
4. Ouvrir une console et aller dans le répertoire de mongodb (dénommé ici
$MONGO/bin)
5. Lancer le serveur :mongod --replSet rs0 --port 27018 --dbpath /data/R0S1
Cette opération devra être répétée pour chaque serveur du ReplicaSet.
En entrant dans un nouveau terminal :mongod --replSet rs0 --port 27019 --dbpath
/data/R0S2
Et dans un autre: mongod --replSet rs0 --port 27020 --dbpath /data/R0S3
Il faut maintenant initier celui-ci. En mode console connexion sur le port 27018 en tapant
mongo --port 27018 ce sera notre serveur primaire.
Daouda TRAORE 46
Capture 4: initialisation du replicaSet
Nous observons après le rs.initiate() ; que le Replicaset a bien été initié.

Nous ajoutons ensuite les autres serveurs en tapant :
rs.add("localhost:27019");
rs.add("localhost:27020");
Capture 5: ajout des serveurs de réplication
Nous pouvons maintenant voir le statut le membre à l’id 0 est le primaire et les autre sont
secondaires
Daouda TRAORE 47
Capture 6 : Observation du statut des serveurs
Le système de vote pouvant prendre un certain temps. Nous pouvons accélérer ce vote en
donnant une priorité entre les réplicas. Les réplicas qui ont la priorité la plus haute vont donc
passer avant tous ceux qui ont une priorité inférieure.
Constatons qu’à la base ils ont une priorité de 1 chacun
Daouda TRAORE 48
Capture 7 : Observation de la priorité des serveurs
Puis nous avons simulé une panne du serveur primaire en coupant juste la connexion du
serveur au port 27018.
Nous voyons bien à la flèche rouge que le serveur 27018 est non atteignable et que le
serveur à l’id 2 ayant la plus forte priorité ici 3 est le nouveau serveur primaire.
Daouda TRAORE 49
Capture 8: Statuts après simulation de panne du serveur primaire
IV.2.2 Outils interface graphique d’administration de MongoDB
MongoDB est administrable en ligne de commande cependant pour une meilleure

visualisation et utilisation des outils graphique sont présents :
Ce sont entre autre mongo compass qui est intégré au fichier zip téléchargeable, et la
suite Studio et Robo 3T.
Daouda TRAORE 50
Capture 9 : interface Robo 3T
Nous utiliserons Robo 3T et Studio 3T. Studio 3T est un outil très puissant permettant la
transcription de tables d’une base SQL en table dans une base NoSQL et vice versa.
Capture 10 : interface Studio 3T
Daouda TRAORE 51
Conclusion
Le fonctionnement des bases NoSQL orienté document a été abordé dans les grandes lignes.
L’installation et la configuration de notre base de données est indispensable pour mener à bien
la réalisation de notre système. La mise en place de la réplication est également un facteur
nécessaire en entreprise surtout afin de gérer au mieux la tolérance aux pannes et ne pas ainsi
bloquer toute une chaine car au temps d’aujourd’hui gagner du temps s’avère l’un des
principaux atouts de toute grande entreprise. Cependant le choix de ce type de base sera
justifié dans les prochains chapitres
Daouda TRAORE 52
Chapitre V : Réalisation du système décisionnel
Introduction
Dans ce dernier chapitre, il s’agira de modéliser notre solution.

Nous verrons également les éléments nécessaires et les différentes étapes pour la réalisation
en mode simulation du système décisionnel.
V.1 Le Langage de programmation PERL
Perl est un langage de programmation créé en 1987 par Larry Wall. À l'origine, il
était surtout utilisé pour le développement de scripts d'administration système sous UNIX,
mais, avec les années, et après plusieurs révisions importantes du langage, Perl est rapidement
devenu un outil polyvalent, puissant et extrêmement pratique.
Le PERL est un langage de script.
V.1.1 Les Caractéristiques du langage PERL

PERL étant un langage de script il évite au développeur de gérer manuellement des
aspects rébarbatifs de la programmation, tels que la gestion de la mémoire.
Il s'agit véritablement d'un langage généraliste. Il est aussi bien présent sur Linux (en
effet comme nous l’avons dit plus haut conçu pour UNIX) présent aussi sous Windows et sur
MacOs, et qui est employé sur des projets de toutes tailles, soit comme langage principal, soit,
pour faire communiquer des programmes entre eux afin de former de gros systèmes.
Là où il est le plus fort et le plus intéressant, cela reste le traitement de fichiers et de
données, mais grâce à ses nombreux modules.
Le langage Perl permet de produire très rapidement des programmes capables de se
connecter à Internet, des sites et des applications web ou des logiciels avec des interfaces
graphiques ! À titre d'exemples d'applications et de sites web connus qui utilisent Perl
aujourd'hui, on pourra citer BugZilla, Amazon.com ou encore IMDb.
Actuellement, il existe deux versions indépendantes de Perl, appelées Perl 5 et Perl 6.
La version que l'on appelle « Perl 5 » est la cinquième version du Perl d'origine, dont
le développement est dirigé par Larry Wall en personne. Cette version de Perl existe et évolue
depuis 1994 c’est celui installée par défaut sur tous les systèmes d'exploitation dérivés
d'UNIX, et qui est de très loin la plus utilisée dans le monde.
Daouda TRAORE 53
Parallèlement, depuis quelques années, un « nouveau » Perl est en cours de

développement, baptisé Perl 6. Il s'agit d'un langage différent qui partage seulement la
philosophie de base et la syntaxe de Perl 5.
Perl 6, est encore en cours de développement, à un stade expérimental. Cela signifie
qu'il faudra encore attendre un moment avant d'obtenir une version stable du langage, qui
puisse être utilisée en production.
On a donc l’interprétateur déjà présent sur les systèmes linux alors que sur les
systèmes Windows il nous faut un interprétateur afin de traduire et permettre l’exécution du
code.
V.1.2 Application du PERL
 Les interpréteurs PERL pour Windows et Mac les plus populaires
Nous avons d’abord ActiveState Perl : Proposé par ActiveState, Active Perl, bien qu’étant
Open Source, est disponible en 4 éditions Community Edition, Business Edition, Enterprise
Edition, Original Equipment Manufacturer Licensing).
Seule l’édition Community est gratuite, les 3 autres versions se distinguant par des niveaux de
supports avancés destinés aux entreprises.
Ensuite il y a Strawberry Perl : Solution Open Source développée pour Windows et Mac.
Et aussi DWIM Perl for Windows : Solution Open Source dérivée de Strawberry Perl et
incluant quelques packages complémentaires.
Tous ces interprétateurs sont disponibles sur le site des constructeurs.
Le langage PERL nous facilite donc le traitement de fichiers notamment dans le nettoyage la
conversion et mieux encore, est capable de d’intégré d’autre programme. Il faut aussi noter
que tout ce qui est du langage système linux peut y être intégré c’est ce qui sera fait dans le
traitement de nos fichier. De plus il est utilisable sur tout type de projet tant qu’il y a
traitement de fichier et d’environnement comme nous l’avons vu plus haut s’adapte au
différent système d’exploitation.
Cependant pour certains traitements il faut lui charger les dépendances nécessaires au
fonctionnement du programme.
L’utilisation du langage perl permet de traiter des fichiers et des données de tailles
faible ou grande tout en gardant une aussi très bonne véracité que vélocité. Les 3V volume
Daouda TRAORE 54
Véracité Vélocité étant les caractéristiques des bases NoSQL que nous verrons dans les
chapitres à venir.
V.2 Réalisation
Etant donné que nous sommes dans un environnement d’entreprises et que certaines
données sont à caractères confidentielles je ne montrerai que ce qui m’a été accordé de
présenter. Dans le contexte de notre solution nous sommes face à une sous-utilisation d’une
technologie à investissement élevé et à capacité large qui est la 4G.
Cependant comment faire pour comprendre cette sous-utilisation de la dite technologie avec
les données présentes.
- Inventaires du présent :
Nous avons un serveur FTP qui reçoit toute les trois heures les informations de robots situés à
trois emplacement le Siège de la Sonatel sis à la VDN, à Technopole et à Médina.
Les informations sont déposer sous forme de fichier compresser .txt.gz. Comme vous pouvez
le voir sur la capture ci-dessous
Capture 11 : fichiers archivés
Nous devons décompresser ces fichiers volumineux et les nettoyer notamment supprimer des
lignes et colonne avant de les introduire dans une base de données adéquate.
Aux fichiers sont associés une documentation me permettant de déchiffrer certains élément et
par rapport aux codes IMEI retrouver le modèle du téléphone correspondant me permettant
aussi de savoir si je suis face à un terminal utilisant la 4G ou pas
Daouda TRAORE 55
Les outils
V.2.1 LE LANGAGE PERL
Le langage PERL est celui que nous avons utilisé afin de nettoyer nos fichiers en l’associant
aux commandes systèmes linux. Nous avons pour cela utilisé une technique de
reconnaissance des entêtes afin de gérer la tolérance aux pannes puis nous avons chargé les
dépendances nécessaires au bon fonctionnement du programme.
Le programme ouvre le répertoire source src où il lit et décompresse les fichiers définit
notamment ceux ayant la terminaison NewCust.txt.gz
Pour éviter de perturbé l’opération, nous avons ajouté ces deux lignes afin de données une
priorité élevé aux processus du programme il faut noter que PERL ici crée des processus qui
travaille indépendamment pour une meilleure efficacité.
Puis nous nous connectons à la base MongoDB afin de lire les fichiers et de les faire
correspondre aux entêtes avant insertion dans la base de données
Daouda TRAORE 56
Capture 12 extraction et connexion à Mongo
Daouda TRAORE 57
Capture 13 insertion dans Mongo
Nous avons testé des modes d’insertion notamment lecture complète des lignes après insertion
ou lecture d’une ligne suivie d’insertion au fur et à mesure. Il s’est avéré que la première
méthode était la plus rapide.
V.2.2 La Base MongoDB
MongoDB a été choisi pour sa souplesse sa tolérance aux pannes grâce à une facile mise en
place de la réplication. Sa documentation étant aussi assez avancée, associée au fait qu’il
s’adapte bien à tous les environnements. Il intègre aussi des outils d’administration qui facilite
son utilisation. Aussi étant orienté document il répond efficacement aux attentes que sont les
nôtres. Avec une utilisation des agrégations relativement simple.
Daouda TRAORE 58
V.2.3 Talend Opération Système pour l’intégration de données
Cet outil nous a été important dans la mise en place de notre entrepôt de données. Nous
utilisons Talend pour BigData. Nous avons eu à définir des indicateurs dit Faits que nous
avons jugé utile en échangeant bien attendu avec le personnel chargé de l’exploitation dudit
système.
Ce sont entre autre :
- Les appareils les plus utilisées (les_appa_plus_utilises) Modèle du terminal
- Les applications les plus utilisées (les_appli_plus_utilises) Les application utilisant la
data ou pas,
- Les systèmes le plus utilise (system_plus_utilises) système plus bande GSM900, GSM
1800, UMTS,
- Les services les plus utilisés (services_plus_prises) type de services,
- Les tops MSISDN les plus recurrents (tops_MSISDN) Les abonnées les plus touchés,
- Les zones plus couvertes (zones_daffluence) pour savoir si elles sont couvertes en 4G,
La technologie la plus utilisées (techn_plus_utilisées) pour savoir le type de protocole par
exemple UDP, TCP.
DIMENSIONS
- Date (Date)
- Espace (Locinfo)
- Marque (Device correspondant à l’IMEI)
- Access (AccessType)
Nous avons fait le Modèle multidimensionnel en utilisant la représentation étoilé pour les faits.
Daouda TRAORE 59
Figure 22: Modèle Multidimensionnel
Figure 23 : Modèle Multidimensionnel avec les clés associées
Daouda TRAORE 60
Talend se présente comme suit :

A son ouverture il est demandé de créer un projet, en importé ou ouvrir un déjà présent.
C’est un outil très puissant qui est virtualisé il s’utilise sans besoin d’installation il faut
cependant avoir java jdk présent dans son système.
Figure 24 : interface d'accueil de talend
Daouda TRAORE 61
On peut voir 5 sections. Celle au centre pour la conception en haut à gauche la gestion des
fichiers et des jobs à droite les outils de jointure des objets. Comme dans la figure ci-dessous
on constate que les éléments 2G, 3G, 4G ressortent alors que ce sont des 0, 1, 2, 3 qui sont
présents dans le fichier principale.
Capture 14 Capture job
Au moins un job a été défini pour chaque table de fait et chaque dimension. Les jobs
correspondent à des mini projets du projet qui peut être stocké dans des dossiers pour une
meilleure organisation comme suit :
Daouda TRAORE 62
Exemple de table de dimension date ;

* L’objet Dakar_up correspond au fichier source dans lequel est chargé les données pris de la
base MongoDB.
Capture 15: job d’une table de dimension date
*Ses données sont ensuite mappées dans le tmap pour en ressortir l’élément date en entier qui
sera mis dans tUniqRow
*tUniqRow est chargé de découper afin de récupérer les éléments qui nous conviennent tels
que le jour, le mois, ou l’année.
Ces valeurs sont ensuite récupérées sur un autre tmap et introduites dans la base de sortie date.
Capture 16: tmap fonctionnement
Daouda TRAORE 63
Capture 17 Job de la dimension marque
Capture 18: job de la dimension zone

Exemple job d’une table de fait
Capture 19 : job de fait des appareils les plus utilisés
Daouda TRAORE 64
Nous voyons bien que nous utilisons les trois dimensions zone, date, et access ;
temp_zone étant une base temporaire de zone utilisée pour récupérer un élément commun à
zone qui pourra nous permettre de faire une jointure avec pole _up regroupant tous les infos
en data up des fichiers. De même que temp_access avec access. Afin de pouvoir récupérer les
trois id des dimensions qui correspondront à la clé de notre table de fait.
Le taggregateRow nous permet de faire des opérations de compte « count », « min »,
«max » par exemple. Pour enfin sortir dans la base les_appa_les_plus_utilisés
V.2.4 Pentaho Workbench et Pentaho server

Pentaho workbench nous a été utile dans la mise en place des cubes nécessaire à la
visualisation en graphe et table
Capture 20 pentaho workbench interface
Pentaho serveur nous permettra la mise en visuel car nous avons greffé dessus le module
Saiku analytics qui nous permettra des représentations affinées par rapport au module intégré
jpivot. Nous avons utilisé le modèle ROLAP qui est peu couteux et dont l’accessibilité à la
ressource est très satisfaisante [B3].
Daouda TRAORE 65
Capture 21 : page d'authentification et d’accueil pentaho
Daouda TRAORE 66
Capture 22 : Chargement des données
Le module Saiku analytics pour la visualisation
Capture 23 : Saiku analytics page d’accueil
Daouda TRAORE 67
Capture 24 : camembert des appareils les plus utilisés suivant la date jour année mois
Capture 25 : diagramme des appareils les plus utilisés suivant les jours
Daouda TRAORE 68
Capture 26 : Tableau du minimum, maximum la moyenne la déviation des appareils les plus utilisés
suivant la date
Daouda TRAORE 69
Conclusion générale
En définitif les systèmes décisionnels ont beaucoup évolué depuis le temps d’avant
l’avènement du numérique. Ils se sont informatisés et par la suite la naissance des bases NoSQL
ont permis un traitement pour des données volumineuses et ayant une structure différente. Se
rendre compte qu’une exploitation rapide et efficace est rentable tant à cours termes, que de faire
des prévisions pour le future. Et le Big Data et tout système permettant un stockage massif de
données le met à la lumière du monde de l’entreprise. Car aujourd’hui les outils de Business
Intelligence se multiplient. Aussi bien que les formations de sorte de répondre au mieux aux
besoins des entreprises.
L’étude de la solution associée au thème que nous venons de dérouler a été l’occasion pour nous
de compléter notre formation, de nous confronter aux réalités de la gestion d’un projet
informatique et de d’élargir nos connaissances.
A travers ce dernier semestre d’une formation riche consacré au projet de mémoire nous avons à
par la solution développée, abordé des thématiques qui ont permis d’approfondir nos
connaissances et renforcer nos acquis. Les notions revues ou approfondies ont concerné entre
autres les bases de données relationnelles, le datawarehouse l’algorithmique, la programmation, la
notion d’indicateurs de performance dans un réseau mobile. Quant aux notions nouvelles elles ont
couvert principalement le calcul distribué sur des données massives ainsi que les techniques et
solutions qui l’accompagnent notamment la programmation PERL et ses avantages dans le
traitement de fichiers les bases de données émergeantes NoSQL dont MongoDB.
Les échanges avec les futurs utilisateurs de la solution sur les fonctionnalités attendues nous ont
convaincu de l’importance capitale de la communication dans un projet de développement. Ces
échanges nous ont conduits à un certain nombre d’itérations sur la conception et la modélisation
de l’application. Notons que l’expression des besoins n’est pas chose évidente à premier abord.
En ce qui concerne les difficultés rencontrées lors de l’élaboration de ce document nous pouvons
mentionner le choix du cas d’utilisation et la connexion MongoDB et les autres outils. L’usage de
la documentation a été d’une importance capital. Signalons que le serveur de déploiement n’étant
pas défini nous avons fait une mise en place avec des outils qui s’adapteront convenablement à
l’un ou l’autre des systèmes dérivé d’UNIX ou Windows.
Ce projet nous a permis de découvrir un domaine d’activité en plein essor, celui de l’analyse des
données massives, ses défis techniques, l’intérêt et les opportunités qu’il suscite, les nouveaux
métiers qu’il créé comme les métiers de data architectes, data analystes et data scientistes.
Les difficultés rencontrées étaient pour nous des défis à relever et cela a contribué grandement à
améliorer nos connaissances.
Daouda TRAORE 70
Références
Bibliographie
[B1] Christian Soutou : Modélisation des bases de données 3ième édition Eyrolles 2015.
[B2] Jean Marie PREIRA Initialisation au SGBD ingc2 2017-2018.
[B3] Fanta HEMERYCK: Cours de Datawarehouse ingc3 2018-2019.
[B4] Omar Boussaid : Introduction aux Systèmes d'Information Décisionnels.
[B5] J.F BOUCHAUDY (2011), Linux Administration Tome 2 : Administration système
avancée.
[B6] Dr. Brahim BELATTAR les bases de données.
Webographie:
[W1] Apprenez à programmer en Perl !, consulté en Août 2019
https://openclassrooms.com/en/courses/1601801-apprenez-a-programmer-en-perl
[W2] Perl doc, consulté en Octobre 2019
https://www.perl.org/
[W3] Digital 2019: Global Digital Overview, consulté en Octobre 2019
https://datareportal.com/reports/digital-2019-global-digital-overview
[W4] Mongo DB la base..., consulté en Octobre 2019
https://www.system-linux.eu/index.php?post/2018/10/02/MongoDB-la-base...
[W5] Révolution Big data
https://www.ludosln.net/revolution-big-data-les-enjeux-et-les-risques-du-big-data/
[W6] meta::cpan Mongo DB, consulté en Septembre 2019
https://metacpan.org/pod/MongoDB
[W7] Business Intelligence, Architecture du SID, consulté en Décembre 2019
https://www.piloter.org/business-intelligence/business-intelligence.htm
[W8] Domaine du décisionnel et data warehouses, consulté en Décembre 2019
https://stph.scenari-community.org/dwh/int/co/intUC021dw.html
Daouda TRAORE a
Tables des matières
Introduction générale................................................................................................................................................. 1
Chapitre I : Présentation du sujet et l'entreprise d'accueil ................................................................. 3
I.1 Contexte: ................................................................................................................................................................ 3
I.2 L’entreprise d’accueil ........................................................................................................................................ 3
I.2.1 Présentation.......................................................................................................................................................... 3
I.2.2 Organisation ........................................................................................................................................................... 4
I.3 Présentation du sujet ............................................................................................................................................ 7
I.3.1 La problématique ............................................................................................................................................. 7
I.3.2 Objectifs .................................................................................................................................................................. 7
I.3.3 Démarche et Méthodologie ............................................................................................................................ 8
I.3.4 Planning effectif du stage ............................................................................................................................... 8
Conclusion ....................................................................................................................................................................... 8
Chapitre II : Analyse et conception du système décisionnel ............................................................... 9
Introduction ........................................................................................................................................................................ 9
II.1 L’Enjeu des Systèmes D'information décisionnels .................................................................................... 9
II.2 Les principales fonctions de la chaine décisionnelle ............................................................................. 11
II.2.1 Collecter : Les outils d'ETL (Extract Transform and Load) ....................................................... 11
II.2.2 Stocker : Le Data warehouse et le datamart .................................................................................... 11
II.2.3 Distribuer les informations .................................................................................................................... 12
II.2.4. Exploiter : Tableau de bord ..................................................................................................................... 12
II.3 Les perspectives ................................................................................................................................................. 12
II.4 Modélisation du système ............................................................................................................................... 13
II.4.1 Description générale ............................................................................................................................................. 13
II.4.2 Diagramme UML .................................................................................................................................................. 14
A. Diagramme de cas d’utilisation .............................................................................................................................. 14
B. Diagrammes de séquence.......................................................................................................................................... 16
II.5 Conclusion ........................................................................................................................................................... 17
Chapitre III : Généralité sur les SGBD .................................................................................................................. 18
Introduction ...................................................................................................................................................................... 18
III.1 Concepts de base............................................................................................................................................... 18
III.2 Les caractéristiques des SGBD .................................................................................................................... 19
III.2.1 Les Base de données Relationnelles SGBDR ..................................................................................... 19
III.2.2 les Bases de données NoSQL ................................................................................................................... 20
Daouda TRAORE b
III.3 Comparatif des deux grands groupes....................................................................................................... 20

III.3.1 LES BASES DE DONNEES RELATIONNELLES......................................................................... 21
III.3.2 LES BASES DE DONNÉES NoSQL ORIENTÉES CLÉ/VALEUR ......................................... 23
III.3.3 LES BASES DE DONNÉES NoSQL ORIENTÉES DOCUMENT............................................ 25
III.3.4 LES BASES DE DONNÉES NoSQL ORIENTÉES COLONNE ................................................ 27
III.3.5 LES BASES DE DONNÉES NoSQL ORIENTÉES GRAPHE.................................................... 29
Conclusion .......................................................................................................................................................................... 31
Chapitre IV : Les Bases de Données NoSQL orientées document: Cas de MongoDB............. 32
Introduction ...................................................................................................................................................................... 32
IV.1 Fonctionnement des SGBD NoSQL orientées document ...................................................................... 32
IV.2 La base de données MongoDB..................................................................................................................... 43
IV.2.1 Implémentation de notre base dans MongoDB ............................................................................... 43
IV.2.2 Outils interface graphique d’administration de MongoDB......................................................... 50
Conclusion .......................................................................................................................................................................... 52
Chapitre V : Réalisation du système décisionnel ...................................................................................... 53
Introduction ...................................................................................................................................................................... 53
V.1 Le Langage de programmation PERL ...................................................................................................... 53
V.1.1 Les Caractéristiques du langage PERL ................................................................................................ 53
V.1.2 Application du PERL ................................................................................................................................... 54
V.2 Réalisation ......................................................................................................................................................... 55
V.2.1 LE LANGAGE PERL ...................................................................................................................................... 56
V.2.2 La Base MongoDB ........................................................................................................................................ 58
V.2.3 Talend Opération Système pour l’intégration de données ......................................................... 59
V.2.4 Pentaho Workbench et Pentaho server .................................................................................................. 65
Conclusion générale.................................................................................................................................................... 70
Références ........................................................................................................................................................................... a
Bibliographie ..................................................................................................................................................................... a
Webographie: ...................................................................................................................................................................... a
Annexes................................................................................................................................................................................ d
Daouda TRAORE c
Annexes
Annexe 1: Installation et configuration de MongoDB

Etape1 :
 Téléchargement de MongoDB
La version communautaire peut être obtenue sur le site https://www.mongodb.com/download-

center/community en y précisant le système d’exploitation et la version recherchée ensuite :
-Sous Windows lancer l’exécutable puis appuyer sur Suivant.
-Sous Mac, décompressez l’archive et déplacez le répertoire dans vos applications
“/Applications"
-Sous Debian/Ubuntu, on peut utilisez simplement la commande “sudo apt install mongodb”
sinon télécharger le fichier (.tgz) selon la version de votre système linux.
Capture : décompression du fichier d’installation
Le serveur sera alors installé très probablement dans l’un des répertoires suivants selon votre
système d’exploitation :
Nommé généralement $MONGO il se présente:

-Sous Windows: C:\Program Files\MongoDB\Server\3.4\
-Sous Linux: /opt/local/bin/ ou /usr/bin (dans mon cas)
-Sous Mac: /Applications
Etape2 :
Daouda TRAORE d
 création d’un répertoire de stockage des données
 Sous Windows allez à la racine “C:\”, puis créer le répertoire “data”. Ensuite, aller
dans ce répertoire et créez le sous-répertoire “db”.
 -Sous Linux ou Mac, il faut créer le répertoire data à la racine avec “sudo mkdir
/data”, donner les droits de propriété (exemple avec l’utilisateur ‘traore’ : “sudo
chown traore /data”. Et enfin, créer le sous-répertoire db : “mkdir /data/db”.
 -Sous Mac, décompressez l’archive et déplacez le répertoire dans vos applications
“/Applications”
Il est possible de créer un autre répertoire dédié “$REP” pour les données de
MongoDB. Dans ce cas, le lancement du serveur ci-dessous devra utiliser le paramètre
--dbpath $REP.
Etape3 :
L’exécutable mongod est disponible sur $MONGO/bin. Si tout se passe bien, le
serveur devrait tourner comme dans la capture ci-dessous :
Capture : interface serveur
Nous pouvons remarquer que le serveur est en attente de connexion.

Lorsque le serveur mongoDB est démarré la commande mongo --port 27017 ou mongo
permet de se connecter au shell. C’est le client. A partir de ce moment on peut procéder aux
configurations de base pour passer enfin à l’utilisation.
Daouda TRAORE e
Capture : interface client
Sur Windows l’exécutable est ajouté à la liste des programmes à démarrage automatique
Sur linux on doit créer un fichier mongo.service au répertoire /etc/systemd/system comme suit
touch /etc/systemd/system/mongo.service
Puis copiez et collez la configuration ci-dessous
#Unit contains the dependencies to be satisfied before the service is started.

[Unit]
Description=MongoDB Database
After=network.target
Documentation=https://docs.mongodb.org/manual
# Service tells systemd, how the service should be started.
# Key `User` specifies that the server will run under the mongodb user and
# `ExecStart` defines the startup command for MongoDB server.
[Service]
User=mongodb
Group=mongodb
ExecStart=/usr/bin/mongod --quiet --config /etc/mongod.conf
# Install tells systemd when the service should be automatically started.
# `multi-user.target` means the server will be automatically started during boot.
[Install]
WantedBy=multi-user.target
Assurez-vous que la ligne ci
Daouda TRAORE f
ExecStart=/usr/bin/mongod --quiet --config /etc/mongod.conf

Contient bien le chemin de votre mongo.conf
Et redémarrer avec la commande
> systemctl daemon-reload
Puis lancer le service avec

> sudo systemctl start mongodb ou > sudo service mongodb start
On vérifie bien que Mongodb a été lance sur le port 27017 avec la commande:
> netstat -plntu
On vérifie que le service fonctionne correctement en tapant :

> sudo systemctl status mongodb ou sudo service mongodb status
 Création de l’utilisateur root

Le super utilisateur root est l’administrateur du système de gestion de base de données
MongoDB. Il a tous les droits d’accès sur toutes les bases de données du système. Une fois
connecté au shell MongoDB les commandes suivantes permettent de le créer :
$ use admin
Capture : création du root

Des outils comme studio 3T facilite l’administration de la base
Daouda TRAORE g
Il y a mongo compass et robo 3T
Capture : interface Robot 3T
Daouda TRAORE h
Capture : interface Mongo compass
Fonctions de lecture et d’insertion PERL utilisées
Capture : Fonction d’extraction PERL
Daouda TRAORE i
Capture : Fonction lecture PERL
Daouda TRAORE j
Ecole Supérieure Multinationale des Télécommunications

Mémoire de fin de formation pour l’obtention du diplôme d’Ingénieur de
conception des télécommunications
M. Daouda TRAORE
Les Systèmes décisionnels : Mise en place d’un système décisionnel avec application des
données de la SONATEL
Directeur de mémoire : M. Jean-Marie PREIRA
Aujourd’hui le monde a compris que toute donnée quelle qu’elle soit peut devenir une
information importante. Mais comment en tirer profit afin d’augmenter notre productivité tout
en limitant les ressources. C’est ce que nous avons fait en utilisant les données de la Sonatel
afin de pouvoir réglementer et gérer les capacités ressources et aussi projeter vers les futures
utilisations en utilisant des outils répondant au cas de données plus ou moins structuré.
Les outils du BI ont été utilisés notamment Pentaho workbench pour la conception des cubes
et pentaho serveur auquel nous avons greffé un module Saiku analytics pour la visualisation
de nos données. Les bases de données NoSQL sont une excellente alternative aux bases de
données relationnelles pour le stockage et l’analyse de données volumineuses. Les principaux
outils et techniques de ces solutions sont le calcul distribué basé sur MapReduce, les
nouvelles techniques d’indexation, l’élasticité et le sharding. En effet ces bases de données
apparaissent comme une solution aux données massives s’inscrivant aussi bien dans le
contexte actuelle qu’est le Big Data néanmoins il n’est pas sans remarquer que de nouvelles
solutions sont développées notamment le NewSQL qui se veut en plus d’intégrer le traitement
de données les volumineuses voudrait garder le contexte relationnel.
Daouda TRAORE

Sous La Direction de Chef Du Service DRP

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Sous La Direction de Chef Du Service DRP

Transféré par

Droits d'auteur :

Formats disponibles

THÈME

Etude et mise en place d'un outil d'aide à

Promotion 2016 - 2019

Je dédie ce travail à tous ceux qui me sont chers,

A mes chers Parents, mes frères et sœurs

Aucun hommage ne pourrait être à la hauteur de l’amour et de

Que ce travail soit l’expression de ma reconnaissance pour vos

Vous étiez toujours présents pour m’encourager.

Je vous souhaite la réussite et le bonheur et surtout la

A mes amis mes professeurs

Qui ont été présents et sans qui cela n’aurait pu être

Daouda TRAORE iii

Liste des figures

Liste des tableaux

Tableau 1 Calendrier des activités.............................................................................................. 8

Liste des captures

Daouda TRAORE vii

Ensemble de connaissances consacrées à la création d’outils, la technologie a

A la Sonatel au service Monitoring de la qualité de service de la Direction des

Chapitre I : Présentation du sujet et l'entreprise d'accueil

I.2 L’entreprise d’accueil

Figure 1:Les directions de la Sonatel [2019]

I.2.2.a La Direction des réseaux plateforme et Services

La direction des réseaux et plateformes de services (DRPS) comprend cinq pôles :

I.2.2.b Organisation du pôle Exploitation (DRPS/DEX)

SMS ASC MQS QSM SMO

Figure 2: La Direction de Réseaux Plateforme et Service

DRPS : Direction Réseaux et Plateformes de Service

I.2.2.c Le service MQS

I.3 Présentation du sujet

I.3.3 Démarche et Méthodologie

I.3.4 Planning effectif du stage

Tableau 1 Calendrier des activités

Chapitre II : Analyse et conception du système décisionnel

Le système d'information décisionnel est un ensemble de données organisées de façon

Figure 3: Fonctionnement du Système décisionnel

II.1 L’Enjeu des Systèmes D'information décisionnels

Dans une organisation, la prise de décisions stratégiques nécessite le recours et le

Figure 4: Architecture d’un Système d’information décisionnel [B4]

II.2 Les principales fonctions de la chaine décisionnelle

Les éléments et outils composant la chaîne décisionnelle sont généralement en quatre

II.2.1 Collecter : Les outils d'ETL (Extract Transform and Load)

II.2.2 Stocker : Le Data warehouse et le datamart

II.2.3 Distribuer les informations

II.2.4. Exploiter : Tableau de bord

II.3 Les perspectives

Figure 5: Perspectives des systèmes décisionnels [W3]

II.4 Modélisation du système

II.4.2 Diagramme UML

A. Diagramme de cas d’utilisation

Le diagramme comprend le système et les différents acteurs que sont l’utilisateur,

Figure 6: Diagramme de cas d’utilisation

• Description des cas d’utilisation

Tableau 2 : Description des cas d’utilisation

Gérer les S’authentifier Visualiser Ajouter un

Figure 7:Diagramme de séquence

Chapitre III : Généralité sur les SGBD

L’approche classique de mise en place d’une application informatique dans une

III.1 Concepts de base

III.2 Les caractéristiques des SGBD

Elle comprend habituellement un ensemble de tables (comme les feuille de calculs

III.2.1 Les Base de données Relationnelles SGBDR

III.2.2 les Bases de données NoSQL

III.3 Comparatif des deux grands groupes