Rapport PFE Balkis Abidi

Ministère de l’enseignement supérieur et de la recherche scientifique
Université de Jendouba
Faculté des Sciences Juridiques, Economiques et de Gestion de Jendouba
RAPPORT DE STAGE DE FIN D’ETUDES
Pour l’obtention du Diplôme de

Licence Fondamentale en Informatique de Gestion
Spécialité : Business Intelligence
Conception et développement d’une solution

BI pour le Groupe Délice "Pôle Lait"
Entreprise d’accueil : Centrale Laitière Du Nord
Élaboré par :
Balkis Abidi
Encadrant pédagogique : Encadrant professionnel :

Mme. Héla Gouider M. Aymen Mastouri
Année Universitaire 2022-2023

Remerciements
C’est avec un grand plaisir que je réserve cette page, en signe de gratitude et
profonde reconnaissance à tous ceux qui m’ont aidé à faire aboutir ce projet de fin
d’étude.
Je tiens à remercier au début les membres du jury d’avoir accepté de juger et

d’évaluer mon travail et de me faire part de leurs conseils.
J’adresse mes plus vifs remerciements à Mme. Héla GOUIDER pour son
encouragement continu et aussi d’être toujours là pour m’écouter, m’aider et me
guider à trouver le bon chemin par sa sagesse et ses précieux conseils, ce qui m’a
donné la force et le courage d’accomplir ce projet.
J’exprime ma profonde gratitude à M. Aymen MASTOURI, mon encadrant

professionnel au service informatique de la Société laitière du Nord pour le temps
qu’il m’a consacré au cours des différents échanges et pour sa disponibilité et son
profond dévouement.
Enfin, mes remerciements vont à tous mes enseignants aux Facultés des
Sciences juridiques économiques et de gestion de Jendouba qui n’ont pas cessé de
m’encourager, me soutenir et d’enrichir mes connaissances durant mon cursus
académique.
Balkis Abidi ...
i
Dédicaces
À mes chers parents Mousadek et Fatma qui m’ont donné un magnifique

modèle de labeur et de persévérance. En témoignage de ma reconnaissance envers
le soutien, les sacrifices et tous les efforts qu’ils ont faits pour mon éducation.
À ma chère sœur Arij qui m’a toujours entourée par leur affection. Je t’exprime à
travers ce travail mes sentiments d’amour.
À tous les membres de ma famille sans exception pour leur soutien moral et
matériel, qui ont tant souhaité assister à cette réussite pour m’exprimer leur joie
pressentie.
À tous ceux qui ont une relation de près ou de loin avec la réalisation du présent
projet.
ii
Table des matières
Introduction générale 1
1 Contexte de projet 3
1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Présentation du Groupe Délice . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.1 Organigramme du Groupe Délice . . . . . . . . . . . . . . . . . . . . . . 3
1.2.2 Les secteurs d’activité Du Groupe Délice . . . . . . . . . . . . . . . . . . 4
1.3 Présentation des sociétés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3.1 Présentation CLN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3.2 Présentation CLC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3.3 Présentation CLSB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3.4 Les activités des sociétés . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3.5 Organigramme des trois sociétés . . . . . . . . . . . . . . . . . . . . . . 5
1.4 Présentation du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4.1 Contexte du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4.2 Étude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4.3 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4.4 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.5 Méthodologie de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.5.1 Méthodologie d’Inmon . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.5.2 Méthodologie Kimball . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.5.3 Inmon Vs Kimball . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.5.4 Méthodologie adoptée . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2 Planification du projet et Spécification des besoins 12

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2 Planification du Projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3 Spécification des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3.1 Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3.2 Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4 Etude fonctionnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4.1 Identification des acteurs du système . . . . . . . . . . . . . . . . . . . . 15
2.4.2 Diagramme de cas d’utilisation Global . . . . . . . . . . . . . . . . . . . 15
2.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3 Environnement technique 17
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2 Architecture technique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2.1 Source de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2.1.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
iii
Table des matières
3.2.2 Types de sources de données . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.2.3 Tiers Back-end . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2.4 Tiers entrepôt de données . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2.4.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2.4.2 Les caractéristiques de l’entrepôt des données . . . . . . . . . . 20
3.2.4.3 Les avantages de l’entrepôt des données . . . . . . . . . . . . . 20
3.2.4.4 Le magasin de données . . . . . . . . . . . . . . . . . . . . . . . 20
3.2.4.5 Les avantages du magasin de données . . . . . . . . . . . . . . . 21
3.2.4.6 Comparaison entre un Data Warehouse et un Data Mart . . . . 21
3.2.5 Tiers OLAP ou cube de base de données multidimensionnelle . . . . . . . 21
3.2.5.1 Définition d’un systéme OLAP . . . . . . . . . . . . . . . . . . 21
3.2.5.2 Différence entre OLAP et OLTP . . . . . . . . . . . . . . . . . 22
3.2.5.3 Les types des systèmes OLAP . . . . . . . . . . . . . . . . . . . 22
3.2.6 Tiers Front-end . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.3 Environnement technique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.3.1 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.3.2 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.3.2.1 Comparatif des outils ETL . . . . . . . . . . . . . . . . . . . . 23
3.3.2.2 Comparatif des outils de visualisation . . . . . . . . . . . . . . 24
3.3.2.3 SQL Server 2019 . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.3.2.4 SQL Server Management Studio . . . . . . . . . . . . . . . . . . 26
3.3.2.5 Visual Studio 2019 . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.3.2.6 SQL Server Integration Services . . . . . . . . . . . . . . . . . . 27
3.3.2.7 SQL Server Analysis Services . . . . . . . . . . . . . . . . . . . 27
3.3.2.8 Microsoft Power BI . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4 Préparation des données et Modélisation 29

4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.2 Préparation des données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.2.1 Source de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.2.1.1 Etude descriptive de données sources . . . . . . . . . . . . . . . 30
4.2.1.2 Conception de la base de données source . . . . . . . . . . . . . 30
4.3 Modélisation multidimensionnelle . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.3.1 La modélisation multidimensionnelle et ses Concepts . . . . . . . . . . 32
4.3.1.1 Concept de fait . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.3.1.2 Concept de dimension . . . . . . . . . . . . . . . . . . . . . . . 32
4.3.1.3 Comparatif entre les tables de faits et les tables de dimensions . 33
4.3.2 Les modèles multidimensionnelles . . . . . . . . . . . . . . . . . . . . . . 34
4.3.2.1 Modèle en étoile . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.3.2.2 Modèle en flocon . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.3.2.3 Modèle en constellation . . . . . . . . . . . . . . . . . . . . . . 35
4.3.2.4 Avantages des modèles en étoile et en flocon . . . . . . . . . . . 35
4.4 Conception du modèle physique . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.4.1 Conception détaillée du data mart « Analyse Fournisseur » . . . . . . . . 35
4.4.1.1 Dimension Temps . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.4.1.2 Dimension Fournisseur . . . . . . . . . . . . . . . . . . . . . . . 36
4.4.1.3 Dimension Société . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.4.1.4 Choix de mesures . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.4.1.5 Table des faits . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
iv
Table des matières
4.4.2 Modèle physique du data mart « Analyse Fournisseur » . . . . . . . . . 38

4.4.3 Conception détaillée du data mart « Analyse Process » . . . . . . . . . . 39
4.4.3.1 Dimension Tank . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.4.3.3 Dimension Temps . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.4.3.4 Choix de mesures . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.4.3.5 Table des faits . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.4.4 Modèle physique du data mart « Analyse Process » . . . . . . . . . . . 42
4.4.5 Conception détaillée du data mart « Analyse Physico Chimie» . . . . . . 43
4.4.5.1 Dimension Produit . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.4.5.3 Dimension Temps . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.4.5.4 Choix de mesures . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.4.5.5 Table des faits . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.4.6 Modèle physique du data mart « Analyse Physico Chimie » . . . . . . . 46
4.4.7 Conception détaillée du data mart « Analyse Réclamation» . . . . . . . . 46
4.4.7.1 Dimension Client . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.4.7.2 Dimension Produit . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.4.7.3 Dimension Région . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.4.7.5 Dimension Temps . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.4.7.6 Choix de mesures . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.4.7.7 Table des faits . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.4.8 Modèle physique du data mart « Analyse Réclamation » . . . . . . . . . 50
4.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5 Intégration et Analyse des données 52

5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.2 Développement ETL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.2.1 Connexion aux bases de données . . . . . . . . . . . . . . . . . . . . . . 54
5.2.2 Intégration des données du Datamart «Analyse Fournisseur» . . . . . . . 54
5.2.2.1 Extraction des données . . . . . . . . . . . . . . . . . . . . . . . 54
5.2.2.2 Transformation des données . . . . . . . . . . . . . . . . . . . 58
5.2.2.3 Chargement des données . . . . . . . . . . . . . . . . . . . . . 62
5.2.3 Intégration des données du Datamart «Analyse Process» . . . . . . . . . 68
5.2.4 Intégration des données du Datamart « Analyse Physico Chimie » . . . . 71
5.2.5 Intégration des données du Datamart «Analyse Réclamation» . . . . . . 74
5.2.6 Mise à jour de l’entrepôt de données . . . . . . . . . . . . . . . . . . . . 78
5.3 Analyse multidimensionnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
5.3.1 Cube OLAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
5.3.2 Réalisation de cubes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
5.4 Déploiement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
5.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
6 Restitution des données 90

6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
6.2 Phase de restitution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
6.2.1 Choix des graphiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
6.2.2 Création du tableau de bord version desktop . . . . . . . . . . . . . . . . 92
6.2.3 Publication des rapports dans le portail de Power BI . . . . . . . . . . . 99
v
Table des matières
6.2.4 Création du tableau de bord version mobile . . . . . . . . . . . . . . . . 100

6.2.5 Prévision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
6.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Conclusion générale 104
vi
Table des figures
1.1 Logo du Groupe «Délice Holding» . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2 Organigramme du Groupe Délice «Pôle Lait» . . . . . . . . . . . . . . . . . . . 4
1.3 Organigramme des sociétés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4 Cycle de vie de Bill Inmon[1] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.5 Cycle de vie de Ralph Kimball[2] . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1 Les phases de planification du projet et de définition des besoins . . . . . . . . 12

2.2 Diagramme de Gantt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3 Tâches réalisées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4 Cas d’utilisation général de la solution . . . . . . . . . . . . . . . . . . . . . . . 16
3.1 Environnement technique à travers le cycle de vie Ralph Kimbal . . . . . . . . . 17

3.2 Architecture technique de la solution . . . . . . . . . . . . . . . . . . . . . . . . 18
3.3 Processus ETL[3] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.4 Exemple de Data mart[4] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.5 Logo du SQL Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.6 Logo du SQL Server Management Studio . . . . . . . . . . . . . . . . . . . . . . 26
3.7 Logo du Visual Studio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.8 Logo du SSIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.9 Logo du SSAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.10 Logo du Power BI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.1 Phase de modélisation et de conception du modéle physique . . . . . . . . . . . 29

4.2 Modélisation de la base de données sources . . . . . . . . . . . . . . . . . . . . . 31
4.3 Exemple de table de fait vente . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.4 Exemple de table de dimension . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.5 Schéma en étoile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.6 Schéma en flocon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.7 Schéma en constellation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.8 Dimension Temps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.9 Dimension Fournisseur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.10 Dimension Société . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.11 Table des faits « Fact_Analyse_Fournisseur » . . . . . . . . . . . . . . . . . . . 38
4.12 Modèle physique du data mart « Analyse Fournisseur » . . . . . . . . . . . . . . 39
4.13 Dimension Tank . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.15 Dimension Temps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.16 Table des faits « Fact_Analyse_Process » . . . . . . . . . . . . . . . . . . . . . 41
4.17 Modèle physique du data mart « Analyse Process » . . . . . . . . . . . . . . . . 42
4.18 Dimension Produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.20 Dimension Temps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.21 Table des faits « Fact_Analyse_PhysicoChimie » . . . . . . . . . . . . . . . . . 45
vii
Table des figures
4.22 Modèle physique du data mart « Analyse Physico Chimie » . . . . . . . . . . . 46

4.23 Dimension Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.24 Dimension Produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.25 Dimension Région . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.27 Dimension Temps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.28 Table des faits « Fact_Analyse_Réclamation » . . . . . . . . . . . . . . . . . . 50
4.29 Modèle physique du data mart « Analyse Réclamation » . . . . . . . . . . . . . 51
5.1 Phase de développement ETL et déploiement . . . . . . . . . . . . . . . . . . . . 52

5.2 Création d’un nouveau projet SSIS . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.3 Composition d’un Package SSIS simple[5] . . . . . . . . . . . . . . . . . . . . . . 54
5.4 Connection Managers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.5 Connexion à SQL Serveur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.6 Les bases de données et l’entrepôt de données . . . . . . . . . . . . . . . . . . . 55
5.7 Table Fournisseur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.8 Table Societe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.9 Table Réception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.10 Attribut date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.11 Union ALL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.12 Union ALL table Societe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.13 Union ALL table Fournisseur . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.14 Union ALL table Réception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.15 Colonne dérivée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.16 Transformation attribut date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.17 Union ALL table date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.18 Transformation table réception . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.19 Mapping entre table Societe et dimension Societe . . . . . . . . . . . . . . . . . 62
5.20 Mapping entre table Fournisseur et dimension Fournisseur . . . . . . . . . . . . 63
5.21 Mapping entre table date et dimension date . . . . . . . . . . . . . . . . . . . . 63
5.22 Execute SQL TASK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5.23 Rafraichissement "Dim_Societe" . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5.24 Rafraichissement "Dim_Fournisseur" . . . . . . . . . . . . . . . . . . . . . . . . 65
5.25 Rafraichissement "Dim_Time" . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.26 Chargement du dimension Societe . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.27 Chargement du dimension Fournisseur . . . . . . . . . . . . . . . . . . . . . . . 67
5.28 Chargement du dimension Temps . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.29 Chargement de la table des faits . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.30 La phase ETL de la dimension « Tank » . . . . . . . . . . . . . . . . . . . . . . 69
5.31 La phase ETL de la dimension « Societe » . . . . . . . . . . . . . . . . . . . . . 69
5.32 La phase ETL de la dimension « Temps » . . . . . . . . . . . . . . . . . . . . . 70
5.33 La phase ETL de la table des faits . . . . . . . . . . . . . . . . . . . . . . . . . 71
5.34 La phase ETL de la dimension « Produit » . . . . . . . . . . . . . . . . . . . . . 72
5.38 La phase ETL de la dimension « Client » . . . . . . . . . . . . . . . . . . . . . . 75
5.40 La phase ETL de la dimension « Région » . . . . . . . . . . . . . . . . . . . . . 76
viii
Table des figures

5.43 Chargement des données de la table de fait . . . . . . . . . . . . . . . . . . . . . 77
5.44 Exemple d’activation du CDC pour chaque base de données . . . . . . . . . . . 78
5.45 Exemple d’activation du CDC pour la table Societe . . . . . . . . . . . . . . . . 78
5.46 CDC Control Task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
5.47 CDC Control Task Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
5.48 Exemple d’un cube OLAP [6] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
5.49 Création d’un nouveau projet SSAS . . . . . . . . . . . . . . . . . . . . . . . . . 81
5.50 Créer une connexion avec la data warehouse . . . . . . . . . . . . . . . . . . . . 81
5.51 Créer une vue de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
5.52 L’ajout de la table de faits et dimensions . . . . . . . . . . . . . . . . . . . . . . 82
5.53 La structure du cube . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
5.54 Conception « Cube_Analyse_Fournisseur » . . . . . . . . . . . . . . . . . . . . 84
5.55 Conception « Cube_Analyse_Process » . . . . . . . . . . . . . . . . . . . . . . 85
5.56 Conception « Cube_Analyse_Physico_Chimie » . . . . . . . . . . . . . . . . . 86
5.57 Conception « Cube_Analyse_Réclamation » . . . . . . . . . . . . . . . . . . . 87
5.58 La dimension Societe avant l’ajout des champs . . . . . . . . . . . . . . . . . . 87
5.59 La dimension Societe après l’ajout des champ . . . . . . . . . . . . . . . . . . . 88
5.60 Hiérarchie de la dimension Temps . . . . . . . . . . . . . . . . . . . . . . . . . . 88
5.61 Déploiement des cubes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
5.62 Exploration du cube . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
6.1 Phase de réalisation suivant le cycle de vie dimensionnel de Ralph Kimball . . . 90

6.2 Choix du type des données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
6.3 Choix du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
6.4 Navigateur de cube . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
6.5 Page d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
6.6 Top 5 Fournisseur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
6.7 Explication détaillée du "Dashboard Qualité" . . . . . . . . . . . . . . . . . . . . 94
6.8 Colonne conditionnelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
6.9 Filtre de Top 5 Fournisseur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
6.10 Last 5 Fournisseur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
6.11 Nombre et cause du refus du fournisseur . . . . . . . . . . . . . . . . . . . . . . 96
6.12 Dashbooard analyse process 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
6.13 Dashbooard analyse process 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
6.14 Dashbooard analyse produit finis 1 . . . . . . . . . . . . . . . . . . . . . . . . . 97
6.15 Dashbooard analyse produit finis 2 . . . . . . . . . . . . . . . . . . . . . . . . . 98
6.16 Top 5 Réclamation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
6.17 Top 5 cause de Réclamation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
6.18 Publication du dashboard souhaité dans Power BI . . . . . . . . . . . . . . . . . 99
6.19 Affichage d’un dashboard dans Power BI Web . . . . . . . . . . . . . . . . . . . 100
6.20 Page d’acceuil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
6.21 Top 5 Fournisseur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
6.22 Analyse process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
6.23 Top 5 Réclamation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
6.24 Prévision des quantités pour la période 2024-2025 . . . . . . . . . . . . . . . . . 103
ix
Liste des tableaux
1.1 Bill inmon Vs Ralph Kimball . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1 Besoins en termes de restitutions . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.2 Description des cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.1 Data Warehouse Vs Data Mart[4] . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.2 Comparaison entre OLAP et OLTP[7] . . . . . . . . . . . . . . . . . . . . . . . . 22
3.3 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.4 Comparatif des outils ETL[8] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.5 Comparatif des outils de visualisation[9] . . . . . . . . . . . . . . . . . . . . . . 25
3.6 Les outils majeurs de Power BI . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.1 Description des tables de base données . . . . . . . . . . . . . . . . . . . . . . . 30

4.2 Tableau comparatif entre les tables de faits et les tables des dimensions . . . . . 33
4.3 Tableau descriptif de la dimension temps . . . . . . . . . . . . . . . . . . . . . . 36
4.4 Tableau descriptif de la dimension fournisseur . . . . . . . . . . . . . . . . . . . 37
4.5 Tableau descriptif de la dimension société . . . . . . . . . . . . . . . . . . . . . . 37
4.6 Les mesures de la table des faits . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.7 Table des faits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.8 Tableau descriptif de la dimension tank . . . . . . . . . . . . . . . . . . . . . . . 39
4.12 Table des faits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.13 Tableau descriptif de la dimension produit . . . . . . . . . . . . . . . . . . . . . 43
4.17 Table des faits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.18 Tableau descriptif de la dimension client . . . . . . . . . . . . . . . . . . . . . . 47
4.19 Tableau descriptif de la dimension produit . . . . . . . . . . . . . . . . . . . . . 47
4.20 Tableau descriptif de la dimension région . . . . . . . . . . . . . . . . . . . . . . 48
4.23 La mesure de la table des faits . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.24 Table des faits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
x
Introduction générale
Aujourd’hui, la possession de l’information est devenue la priorité des entreprises pour qu’elles
puissent survivre et défendre leurs positionnements afin de ne pas être dépassées par la foule. Mais
avec l’évolution des nouvelles technologies de l’information et de la communication et l’importance
du volume de données qui en résulte, le suivi des activités de l’entreprise est devenu vital pour toute
personne responsable qui y travaille. Il est donc nécessaire de vérifier en permanence la corrélation
entre le prévisionnel et la réalité du terrain pour maîtriser la situation afin de pouvoir agir plus
rapidement et identifier les points à traiter pour améliorer les résultats.
Pour ce faire, ces personnes doivent disposer de la bonne information au bon moment pour pou-
voir prendre la bonne décision. De ce fait, l’utilisation d’un Système d’Information Décisionnel (SID)
en tant qu’une solution technique paraît essentielle. Cette solution garantit une meilleure visibilité
sur l’activité de l’entreprise et permet d’anticiper les nouveaux enjeux du marché.
Dans ce contexte, nous a été proposé un projet de fin d’étude de licence par la centrale laitière
du nord, intitulé "Conception et développement d’une solution BI pour le Groupe Délice "Pôle Lait".
L’objectif de ce projet est de tirer pleinement parti du volume considérable de données disponibles
dans le secteur "Pôle Lait" des trois sociétés CLN, CLC et CLSB, ainsi que des directions qualité et
production. L’objectif ultime est d’aider les décideurs à prendre des décisions appropriées. Pour at-
teindre cet objectif, nous allons mettre en place un data warehouse, qui jouera un rôle essentiel dans
notre solution de business intelligence. Le data warehouse aura pour utilité de collecter, stocker et
organiser de manière structurée toutes les données pertinentes du secteur "Pôle Lait". Ces données
seront stockées de manière à faciliter leur accès et leur utilisation ultérieure lors des analyses et des
prises de décision.
La synthèse des travaux réalisés tout au long du projet de fin d’études feront l’objet de ce rapport
qui s’articule autour de six chapitres :
• Le premier chapitre, intitulé "Contexte de projet", consiste à présenter les Groupes Délice
et les trois sociétés du secteur Pôle Lait ainsi qu’une présentation du projet en termes de
problématique et solution envisagée et une élaboration du choix de la démarche à suivre tout
au long du projet.
• Le second chapitre, intitulé "Planification du projet et Spécification des besoins", porte sur la
planification et la spécification des besoins de notre projet.
• Le troisième chapitre, intitulé "Environnement technique", est réservé pour l’architecture tech-
nique de notre système ainsi que les outils avec lesquels nous avons élaboré le projet.
1
Introduction générale
• Le quatrième chapitre, intitulé "Préparation des données et Modélisation", aborde la présen-

tation de notre bases de données source, la modélisation de notre entrepôt de données et la
conception des data marts.
• Le cinquième chapitre, intitulé "Intégration et Analyse des données", présente la réalisation

du processus ETL en utilisant l’outil SSIS, la création des cubes OLAP à travers l’outil SSAS,
ainsi que la phase de déploiement.
• Le dernier chapitre, intitulé "Restitution des données",représente le résultat de notre projet à

travers la réalisation des dashboards dynamiques afin de permettre au décideur la bonne prise
de décision.
2
CHAPITRE 1
Contexte de projet
1.1 Introduction
Dans ce premier chapitre, Nous allons présenter l’environnement du groupe délice (Pôle Lait), ses
sociétés, ses activités, ses produits ainsi que ses secteurs d’activités. Ensuite, Nous allons présenter
le sujet du travail et clarifié les problèmes rencontrés au sein des entreprises CLN, CLC, CLSB du
Groupe Délice. Enfin, nous adopterons la solution et la méthodologie choisie.
1.2 Présentation du Groupe Délice

Le Groupe Délice est un groupe tunisien qui opère essentiellement dans l’industrie laitiére et
composé de huit sociétés : “CLN”,“CLC”, ‘’CLSB”, ‘’SBC”, ‘’CF”, ‘’Delta Plastic”, ‘’STIAL” et
‘’SOCOGES” exerçant dans le secteur de l’industrie agroalimentaire.
Figure 1.1 – Logo du Groupe «Délice Holding»
1.2.1 Organigramme du Groupe Délice

Notre projet concerne le secteur du Groupe Délice "Pôle Lait", composé de trois sociétés,
"CLN", "CLC", "CLSB" jouent un rôle crucial pour nous donner accès aux données et nous
fournir les informations nécessaires.
3
Chapitre 1. Contexte de projet
Figure 1.2 – Organigramme du Groupe Délice «Pôle Lait»
1.2.2 Les secteurs d’activité Du Groupe Délice

Le Groupe Délice est désormais présent sur cinq secteurs d’activité :
• Le lait,
• Les produits laitiers frais,
• Les boissons,
• Le fromage,
• L’eau minérale,
Le seceteur "pôle lait" a la contribution la plus importante aux revenus consolidés du Groupe. A
côté de son leadership sur ses métiers de base.
1.3 Présentation des sociétés

Puisque nous avons déjà exprimé le secteur "Pôle Lait" dans la figure 1.2, nous présentons
maintenant les trois sociétés
1.3.1 Présentation CLN

La société Centrale Laitière Du Nord “CLN” est une société anonyme spécialisée dans la trans-
formation du lait et la production de ses dérivés ainsi que la commercialisation des produits laitiers
et ses dérivés ainsi que tous produits agroalimentaires.
1.3.2 Présentation CLC

La société Centrale Laitière du Cap-Bon “CLC” est une société anonyme créée en 1993, spécia-
lisée dans la fabrication, le conditionnement et la commercialisation du lait et dérivés sauf le yaourt
et les boissons de toutes natures.
4
1.3.3 Présentation CLSB

La Centrale Laitière de Sidi-Bouzid ‘’CLSB” est une société anonyme de droit tunisien. Elle est
créée le 13 Juin 2011 et a pour objet la fabrication, le conditionnement et la commercialisation du
lait et dérivés, et la production et vente de tout produit agroalimentaire.
1.3.4 Les activités des sociétés

• Achat de lait cru,
• Transformation de lait cru,
• Productions,
• Vente du lait,
1.3.5 Organigramme des trois sociétés

Nous présentons l’organigramme des trois sociétés à travers la Figure 1.3.
Figure 1.3 – Organigramme des sociétés
Notre solution est particulièrement orientée aux directions de production et de qualité de CLN,
CLC, CLSB.
5
1.4 Présentation du projet

1.4.1 Contexte du projet
Le projet sera lié à la préparation du projet de fin d’étude pour obtenir un diplôme de licence en
informatique de gestion à la Faculté des Sciences Juridiques Économiques et de Gestion de Jendouba.
Notre projet est exécuté par la société "CLN" du 01/02/2023 au 30/05/2023. Son objectif principal
est de mettre en place une solution BI pour la production et la qualité de CLN, CLC, CLSB facilitant
la prise de décision.
1.4.2 Étude de l’existant

Le Groupe Délice a adopté pour son système d’information l’ERP JD Edwards qui couvre les
modules de gestion suivant : Achat, finance et comptabilité, stock, vente, production, maintenance.
Etant donné que le groupe est spécialisé à l’industrie agro-alimentaire et précisément l’industrie
laitière, le module qualité devient de plus en plus important à fin d’assurer un produit de bonne qualité
et compétitif sur le marché, de ce fait Delice a mis en place un système appelé « Easycontrol »
pour assurer la saisie et le suivi des différents analyse et flux durant le procès de production des trois
sociétés (CLN, CLC, CLSB).
Easycontrol est un système conçu et développé en interne du groupe par l’équipe SI, il contient
trois grands modules qui sont :
• Réception lait : Permet la saisie des réceptions du lait cru ainsi que les différentes informations
sur les opérations de dépotage et des nettoyages.
• Laboratoire : Ce module permet l’enregistrement des analyses durant toutes les phases de
production.
• Process (ou Salle de contrôle) : Permet l’enregistrement des informations des tous les flux
durant le cycle de production.
1.4.3 Problématique
Suite à l’étude de l’existant effectuée au cours du stage, nous avons constaté les points suivants :
• Absence d’une solution BI des données qualité,
• Absence des Dashboard des analyses par société,
• Accès lent aux informations,
• Difficulté d’anticipation des tendances relatives à la qualité des produits,
• L’utilisation d’outils classiques tels que (Microsoft Excel, etc.) pour la restitution des données
et la présentation des chiffres au comité de suivi, ainsi que pour le calcul des KPIs ,
• Absence des Dashboard contenant des KPIs qui facilite la prise des décisions d’une façon plus
rapide et qui permet d’agir à temps réelle en cas de besoin,
• Absence d’une version portable pour pouvoir accéder depuis n’importe quel périphérique.
6
1.4.4 Solution proposée

Afin de remédier à ces problématiques, notre solution est de mettre en place un outil d’aide à la
décision et Créer des tableaux de bord qualité qui englobe les trois sociétés du secteur Pôle Lait du
Groupe Délice.
Pour atteindre notre objectif, nous allons :
• Collecter les données nécessaires depuis les systèmes sources,
• Intégrer ces données dans un entrepôt de données Data Warehouse (DWH) en effectuant les
opérations d’extraction, de transformation et de chargement,
• Analyser les données et fournir des dashboards dynamiques,
• Fournir une visualisation claire qui comprend les informations nécessaires qui peuvent les servir
à prendre de bonnes décisions.
1.5 Méthodologie de travail

Un projet décisionnel comme tout autre projet doit suivre un ensemble d’étapes bien définies
pour arriver à un système décisionnel fonctionnel répondant aux besoins des utilisateurs finaux. Une
démarche claire et bien structurée est nécessaire non seulement pour organiser le travail mais aussi
pour identifier clairement les différentes phases et les différents objectifs afin de mener à bien le
projet tout en étant conforme aux bonnes pratiques.
1.5.1 Méthodologie d’Inmon

Bill Inmon est un informaticien américain considéré comme le pére des entrepôts et écrivain d’un
livre expliquant une approche pour les créer. Dans son approche, il faut d’abord créer l’entrepôt
qui comprend l’ensemble des données de l’entreprise, pour ensuite alimenter de mini-entrepôts de
données départementales. Chaque mini-entrepôts vise un secteur particulier de l’entreprise et sera
la source des requêtes et rapports utilisés par les décideurs de l’entreprise.
Figure 1.4 – Cycle de vie de Bill Inmon[1]
7
1.5.2 Méthodologie Kimball

Ralph kimball prend une approche tout à fait différente d’Inmon pour la création d’entrepôts.
Premiérement, il a développé une technique pour modéliser un entrepôt qui, à l’époque, était révo-
lutionnaire : le modéle dimentionnel. Au lieu d’être basé sur le modéle entités–association, le modéle
dimentionnel repose sur des tables représentant des faits et des dimensions. William Inmon nous
propose cette analogie : « Vous pouvez attraper tous les fretins de l’océan et les empiler les uns
sur les autres, vous n’arriverez pas à créer une baleine. » Ce que William Inmon veut dire c’est que
les magasins de données du type silo auront forcément des vides entre eux, et n’arriveront jamais à
refléter de façon réelle une vue d’ensemble des données de l’entreprise.
Figure 1.5 – Cycle de vie de Ralph Kimball[2]
1.5.3 Inmon Vs Kimball

Dans ce Tableau 1.1, nous allons mieux expliquer la comparaison entre Bill inmon et Ralph
Kimball.
Critère Inmon Kimball

Orientation Top-down Bottom-up
Modèle entité-association Modèle en étoile ou en flo-
Modèle de données
(EA) con
Conception centrée sur l’en- Conception centrée sur les
Approche de conception
treprise besoins de l’utilisateur final
Focus principal L’entrepôt de données Les data marts
Architecture Centralisée Décentralisée
Stockées dans l’entrepôt de Stockées dans les data
Données de base
données marts
Avant la création des data Intégration après la création
Intégration de données
marts des data marts
Granularité des données Fine Granularité variable
8
Conception comme un pro- Approche itérative pour

Évolution
cessus continu chaque data mart
Table 1.1 – Bill inmon Vs Ralph Kimball
Le Tableau 1.1 montre que la méthode de Bill Inmon est centrée sur l’entrepôt de données et
adopte une approche top-down et centralisée, tandis que celle de Ralph Kimball est centrée sur les
besoins de l’utilisateur final et adopte une approche bottom-up et décentralisée, en se concentrant
sur les data marts. Les deux approches ont leurs avantages et leurs inconvénients, et le choix de la
méthode dépendra des besoins spécifiques de l’entreprise ou de l’utilisateur final.
1.5.4 Méthodologie adoptée

Dans ce projet, nous allons adopter la méthodologie de "Ralph Kimball". Nous allons en premier
lieu présenter cette démarche d’une manière générale et détailler ses différentes phases, et nous
allons après procéder à la justification de ce choix.
En effet, Ralph Kimball est un expert reconnu dans le domaine des entrepôts de données qui a
mis en place le principe de la conception décisionnelle ascendante. Cette démarche est un processus
de conception décisionnelle d’entrepôt de données allant du bas vers le haut, appelé aussi Bottom-
Up. Ce processus est le résultat d’une étude des axes de l’entreprise et une analyse des besoins
d’affaires pertinents à modéliser.
La méthodologie de Kimball se base essentiellement sur la modélisation et l’implémentation des
Datamarts qui présentent des magasins de données spécialisés par secteur d’activités. Selon cette
modélisation, les structures de données dimensionnelles sont la destination ultime des processus ETL
(Extract, Transform, Load). En général, les tables dimensionnelles sont l’étape finale de stockage
physique de données avant leur transfert vers l’environnement des utilisateurs finaux.
Les différentes phases de cette méthodologie comme le montre la figure 1.5 sont :
✦ Planification du projet
La planification aborde la définition et l’étendue du projet de l’entrepôt, y compris l’appréciation
du niveau de maturité de l’organisation face à ce type d’approche. Elle se concentre essentiellement
sur les besoins en termes de ressources et de niveau de qualification, couplés aux affectations des
tâches, ainsi qu’à leurs durées et à leur séquencement.
✦ Définition des besoins de l’entreprise

Il est essentiel de bien comprendre les utilisateurs et leurs besoins, sinon l’entrepôt deviendra
rapidement un exercice vain de la part de l’équipe des concepteurs.
✦ Définition de l’architecture technique

Cette étape définit la vision globale de l’architecture technique à mettre en œuvre. Elle nécessite
la prise en compte de trois facteurs, à savoir : les besoins, l’environnement existant et les orientations
techniques stratégiques planifiées.
✦ Installation et sélection des produits

En se basant sur l’architecture technique, et en répondant aux besoins de notre projet nous avons
choisi de définir l’outil sur lequel se base notre projet. Une fois les produits évalués et sélectionnés,
9
ceux-ci doivent être installés et testés.
✦ Modélisation dimensionnelle
C’est la définition des besoins qui détermine quelles sont les données requises pour répondre aux
besoins d’analyse des utilisateurs. Le résultat de cette analyse n’est autre que le modèle dimension-
nel. Celui-ci identifie la granularité de la table de faits, les dimensions associées avec leurs attributs
ainsi que leurs hiérarchisations.
✦ Conception du modèle physique

La conception physique d’une base de données définit les structures nécessaires pour l’implé-
mentation du modèle dimensionnel. Par ailleurs, la mise en place de l’environnement de la base de
données, l’indexation primaire, les stratégies de partitionnement et les agrégations primaires sont
également définies.
✦ Conception et Développement des éléments de la zone de préparation des

données
Cette partie concerne l’implémentation du processus ETL après avoir identifié les dimensions et
les faits.
✦ Spécification de l’application utilisateur

Cette phase consiste à la préparation des maquettes qui vont être élaborées par la suite.
✦ Développement de l’application utilisateur

Cette phase a pour objectif la réalisation des différents rapports et tableaux de bord qui vont
répondre au besoin du client en termes d’analyse.
✦ Déploiement
Le déploiement est le point de convergence de la technologie, des données et des applications
utilisateurs. Une planification est indispensable pour gérer le déploiement qui comprend également la
formation des utilisateurs, les processus de communication, le support utilisateur, la prise en compte
des demandes d’évolution et de correction.
✦ Maintenance et croissance
Après le déploiement initial de l’entrepôt, c’est sa vie qui commence. Il faut s’assurer que les
processus mis en place pour la gestion de la zone de construction vont faire fonctionner l’entrepôt
efficacement en continu. Il est également important de mesurer périodiquement les performances
de l’entrepôt et de son acceptation dans l’entreprise. L’entrepôt en question va, en conséquence,
évoluer et croître.
✦ Gestion du projet
La gestion du projet garantit que les activités du cycle de vie restent sur la bonne voie et qu’elles
soient bien synchronisées. Cela consiste à contrôler l’état d’avancement du projet, ladétection et la
résolution des problèmes, ainsi que le contrôle des changements afin de garantir l’accès aux objectifs
du projet.
➢ Notre choix s’est porté sur le cycle de vie dimensionnel proposé par Ralph Kimball vu que :
10
✦ Kimball s’adapte à la stratégie de l’entreprise qui consiste à élaborer dans un premier

lieule Datamart de son activité commerciale et par la suite de construire son entrepôt de données
d’une manière progressive.
✦ Kimball permet d’avoir des résultats assez rapides puisque le client ne dispose pas d’un
système décisionnel donc il est nécessaire de mettre en place une solution rapidement.
1.6 Conclusion
L’entreprise d’accueil CLN et les deux autres Sociétés CLC, CLSB ont été amplement présentées
dans ce chapitre au sein duquel le contexte général et l’objectif du projet ont été introduits, pour
ensuite définir sa conduite explicitant la méthodologie de développement adoptée suivie, ainsi que
la planification des tâches tout au long de la période de notre stage.
11
CHAPITRE 2
Planification du projet et Spécification

des besoins
2.1 Introduction
Dans ce chapitre, nous allons nous concentrer sur les deux phases de la démarche de Kimball :
la planification du projet et la définition des besoins de l’entreprise. Nous entamons dans un premier
lieu la planification de notre projet. Ensuite, nous allons présenter les différents besoins fonctionnels
et non fonctionnels ainsi que les acteurs clés de notre solution avec les différents cas d’utilisation
pour garantir le bon acheminement du projet.
Comme le montre la Figure 2.1, nous allons entamer les phases de début du cycle de vie dimen-
sionnel.
Figure 2.1 – Les phases de planification du projet et de définition des besoins
12
Chapitre 2. Planification du projet et Spécification des besoins
2.2 Planification du Projet

Afin de mieux organiser notre projet, nous avons présenté à travers le diagramme de Gantt
l’ensemble des tâches ainsi que leurs durées, tout en respectant la démarche de Ralph Kimball
adoptée pour la réalisation du projet.
La Figure 2.2 schématise le diagramme de Gantt de notre projet.
Ce dernier permet de représenter visuellement l’état d’avancement des différentes activités qui
constituent un projet, il répertorie toutes les tâches à accomplir pour mener le projet à bien.
Figure 2.2 – Diagramme de Gantt
La Figure 2.3 représente les taches effectuées tout le long de notre stage avec les dates de début
et de fin de chacune.
Figure 2.3 – Tâches réalisées
13
2.3 Spécification des besoins

La phase de définition des besoins permettent de décrire les fonctionnalités de la solution et les
contraintes sous lesquelles celle-ci doit être réalisée.
Ces besoins sont divisés en deux catégories, la première concerne la partie fonctionnelle, la
deuxième concerne la partie non fonctionnelle.
Ainsi et au cours de ce chapitre, nous aborderons la phase "Définition des besoins" et nous
présenterons les besoins fonctionnels et non fonctionnels de notre solution.
2.3.1 Besoins fonctionnels

Les besoins fonctionnels ou besoins métiers représentent les actions que le système doit exécuter.
Le système ne devient opérationnel que s’il satisfait les besoins fonctionnels.
Le Groupe Délice " Pôle Lait " a besoin de développer l’approche de l’informatique décisionnelle
pour ses différentes directions que ce soient production ou de qualité vu que les systèmes existants
ne lui permettent pas d’effectuer un Reporting centralisé.
La solution BI à instaurer devrait améliorer la prise de décision pour tous les décideurs de Groupe
Délice " Pôle Lait " .
Le Tableau 2.1 explique mieux les besoins des sociétés en termes de restitutions.
Besoins Fonctionnalités
• évolution annuelle du nombre de fou-

nisseurs ;
• établir le nombre de quantités de lait

par fournisseur par société et par
temps ;
Analyse des fournisseurs • déterminer les tops et les last five four-
nisseur par société ;
• déterminer La moyenne de densité par

fournisseur ;
• dégager le taux de refus par société et

fournisseur.
• déterminer la moyenne de (MG, aci-

Analyse process dité, PH, protéine, densité) par tank
par société et par temps .
• déterminer la moyenne de (Nivstab,

Analyse physico chimique densité,PH, protéine,MG) par produit
par société et par temps .
14
• évolution annuelle du nombre de récla-

mations,
Analyse des réclamations • déterminer le nombre des réclamations
par région et par produit et par client
et par temps.
Table 2.1 – Besoins en termes de restitutions
2.3.2 Besoins non fonctionnels

Les besoins non fonctionnels décrivent toutes les contraintes auxquelles est soumis le système
pour sa réalisation et son bon fonctionnement. Elles décrivent des qualités que lesystème doit avoir,
telles que :
• L’ergonomie : Les tableaux de bords développés doivent présenter des interfaces pratiques
qui offrent une visualisation simple et rapide des informations. Les interfaces doivent être
conviviales avec une densité d’éléments sur les écrans convenablement étudiée ainsi qu’un bon
choix de couleurs.
• Temps de réponse et optimisation : Le grand volume de stockage des données implique

un temps de réponse important. Nous avons opté pour l’élimination des données inutiles, ainsi
que les composants qui alourdissent le chargement des données.
• Fiabilité : Il faut garantir la qualité du contenu et la pertinence des informations.
2.4 Etude fonctionnelle

2.4.1 Identification des acteurs du système
Notre système met en jeu de deux acteurs principaux ; Le client qui est le décideur etl’adminis-
trateur :
• Le décideur : C’est celui qui exige des fonctionnalités et énonce des besoins. Il va consulter
le TB avec une authentification implicite ;
• L’administrateur : C’est celui qui, après authentification, s’occupe du système. Il est chargé
de la gestion du tableau de bord, de l’ETL et du cube OLAP .
2.4.2 Diagramme de cas d’utilisation Global

Le cas d’utilisation sert à clarifier les relations entre le système et ses acteurs. Egalement il
permet d’abstraite les exigences fonctionnelles. A cet égard nous avons réalisé :
• Un cas d’utilisation général du système (Voir Figure 2.4)
15
Figure 2.4 – Cas d’utilisation général de la solution
Nous allons présenter dans le Tableau 2.2 la description détaillée des différents cas d’utilisation.
Cas d’utilisation Acteur(s) Description

Permet à l’Administrateur de gérer les
Gérer ETL Administrateur données (extraction,transformation et
chargement des données) .
Permet à l’Administrateur de gérer les
Gérer cube OLAP Administrateur
cubes OLAP.
Gérer les tableaux de Permet à l’Administrateur de créer,
bord Administrateur modifier ou supprimer les tableaux de
bord.
Consulter tableau de
Permet au Décideur de consulter les ta-
bord Décideur
bleaux de bord déjà déployés.
Table 2.2 – Description des cas d’utilisation
2.5 Conclusion
À l’issue de ce chapitre, nous avons déterminé les besoins fonctionnels et non fonctionnels du
projet. Nous avons cité également les acteurs clés du système. Ce chapitre a présenté la conception
détaillée qui a pour objectif de documenter précisément les tables de faits et les tables des dimensions
de la solution finale.
16
CHAPITRE 3
Environnement technique
3.1 Introduction
Après avoir spécifié les besoins de notre application, nous allons entamer maintenant la phase
qui concerne l’environnement technique qui constitue l’une des étapes les plus importantes du cycle
de vie du projet décisionnel. En se basant sur le cycle de vie dimensionnel de Ralph Kimball, nous
nous concentrons durant ce chapitre sur la définition de l’architecture technique et sur la sélection
et l’installation des produits.
Comme illustré dans la Figure 3.1, nous présentons l’environnement technique de notre solution
suivant le cycle de vie dimensionnel.
Figure 3.1 – Environnement technique à travers le cycle de vie Ralph Kimbal
17
Chapitre 3. Environnement technique
3.2 Architecture technique

Cette étape est une définition globale de la solution. Sa spécification doit être basée sur l’environ-
nement technologique adopté par l’entreprise. Nous allons, dans ce cadre définir un plan architectural
qui comporte 5 parties (voir Figure 3.2)
Figure 3.2 – Architecture technique de la solution
3.2.1 Source de données

3.2.1.1 Définition
Une source de données est un endroit où l’information est obtenue. La source peut être une base
de données, un fichier plat, un fichier XML ou tout autre format lisible par un système. L’entrée est
enregistrée sous la forme d’un ensemble d’enregistrements contenant des informations utilisées dans
le processus métier. Ces informations peuvent inclure les détails des clients, les chiffres comptables,
les ventes, la logistique, etc.
3.2.2 Types de sources de données

L’intégration des systèmes permet aux entreprises de fusionner les entrées de plusieurs systèmes.
Les dirigeants peuvent ensuite utiliser ces connaissances pour éclairer leur stratégie commerciale.
Ces informations peuvent provenir de différentes sources et jouer un rôle précieux en fournissant des
insights significatifs sur l’entreprise. Les sources les plus courantes sont :
• Base de données
Une base de données est un ensemble d’informations organisées en tableaux constitués de
lignes et de colonnes. Il existe plusieurs types de bases de données :
Entrepôt - Les informations collectées à partir de plusieurs sources et utilisées pour l’interro-
gation sont stockées dans un entrepôt.
Transactionnel - Avec une base de données transactionnelle, l’entrée est organisée par date ou
horodatage. Par conséquent, ces bases de données peuvent annuler ou annuler une opération
si une transaction échoue.
18
• Fichiers plats
L’entrée stockée dans des fichiers plats n’est pas relationnelle de la même manière qu’une base
de données. Il est généralement stocké sous forme de texte ou binaire qui peut être extrait par
des algorithmes d’analyse.
3.2.3 Tiers Back-end

La zone de préparation ou Back-room, dans laquelle l’ETL aura lieu. Cela résulte des données
standardisées, nettoyées et chargées dans l’entrepôt.
Figure 3.3 – Processus ETL[3]
Le processus ETL comporte trois étapes distinctes :
• Extraction de données : Les données sont extraites de sources de données multiples, souvent
hétérogènes, telles que des fichiers, des bases de données, des services web. Comme notre
étape, nous allons extraire les données à partir d’une base de données.
• Transformation de données : Les données sont transformées et nettoyées pour garantir leur
qualité, cohérence et normalisation. Cette étape peut inclure le filtrage, le tri, le regroupement,
la conversion de formats, la fusion, la suppression des doublons, la normalisation.
• Chargement de données : Les données transformées sont chargées dans une base de données
de destination, souvent un entrepôt de données.
3.2.4 Tiers entrepôt de données

3.2.4.1 Définition
L’entrepôt de données ou Data Warehouse en anglais est une base de données relationnelle
qui regroupe une grande quantité de données dans une entreprise à partir de différentes sources de
données. Il est plus utilisé pour la réalisation des requêtes, l’analyse des données et la prise de décision
que le traitement des transactions ou d’autres utilisations traditionnelles de bases de données, notre
data warehouse s’appelle "Délice".
19
3.2.4.2 Les caractéristiques de l’entrepôt des données

L’entrepôt des donnes doit être :
• Orientées sujet : Ce qui signifie que les données doivent être classées par sujets par exemple
vente, production, etc.
• Intégrées : Le Data Warehouse doit être en mesure d’assembler des données provenant de
différentes sources dans un format cohérent.
• Non volatiles (statiques) : Cela signifie que les données qui entrent dans le Data Warehouse
ne doivent pas être modifiées. L’utilisateur est ainsi en mesure d’analyser les données telles
qu’elles ont été stockées dans le Data Warehouse.
• Historiés : Cela signifie que les données sont liées à une période définie.
3.2.4.3 Les avantages de l’entrepôt des données

L’entrepôt des données présentent de nombreux avantages :
• Pour les responsables informatiques : permettre de séparer le processus d’analyse du processus

opérationnel pour améliorer les performances.
• Pour les entreprises : peuvent améliorer leurs opérations et leur efficience, et ainsi augmenter
leurs revenus et leurs bénéfices.[10]
3.2.4.4 Le magasin de données

Le magasin de données ou appelée en anglais Data Mart est un sous-élément d’un entrepôt de
données qui se compose par un ensemble de données qui sont structurées dans le but de répondre
aux besoins d’un seul département.
Figure 3.4 – Exemple de Data mart[4]
Le data mart utilisé en informatique décisionnelle, il est extrait de systèmes sources puis nettoyé
et mis à disposition des utilisateurs d’un domaine spécifique de l’entreprise, ou d’un groupe restreint
d’utilisateurs.
20
3.2.4.5 Les avantages du magasin de données

Le magasin de données présente de nombreux avantages, notamment :
• Une source unique d’informations fiables,
• Accès plus rapide aux données,
• Meilleure visibilité permettant une prise de décision plus rapide,
• Implémentation plus simple et plus rapide,
• Alternative peu coûteuse au data Warehouse,
• Le suivi des indicateurs KPI est très facile.[11]
3.2.4.6 Comparaison entre un Data Warehouse et un Data Mart

Le Tableau 3.1 représente la comparaison ente un Data Warehouse et un Data Mart :
Data Warehouse Data Mart

Taille 100 GO + < 100 GO .
Objet Plusieurs objets Un seul objet.
Portée Entreprise globale Un seul département.
Composé de plusieurs Composé de nombre
Sources de données
sources limiter de sources.
Temps d’implémenta- Mise en œuvre de plu- Mise en œuvre de
tion sieurs mois à plusieurs minutes, semaines ou
années mois.
Table 3.1 – Data Warehouse Vs Data Mart[4]
3.2.5 Tiers OLAP ou cube de base de données multidimensionnelle

Cela incarne la liaison entre le système ETL et la couche de présentation. Lors de l’envoi d’une
requête, c’est le serveur OLAP qui la prend en charge. Le résultat sera envoyé au cube OLAP.
3.2.5.1 Définition d’un systéme OLAP

Le système OLAP (Online Analytical Processing) ou aussi appelé système décisionnel est une
technologie permettant d’effectuer des analyses de données multidimensionnelles représentée par un
ou plusieurs cubes. Il permet de prendre des décisions rapides et crédibles sur des actions futures,
permet aussi l’analyse de tendances, les calculs complexes, et le data modeling.[12]
21
3.2.5.2 Différence entre OLAP et OLTP

Le Tableau 3.2 représente une comparaison entre les systèmes OLAP et OLTP :
OLTP OLAP
C’est un système transactionnel
C’est un système de récupération
en ligne qui sert à effectuer des
Définition de données et d’analyse de don-
modifications dans une base de
nées en ligne.
données.
Objectif Le traitement des donnée. L’analyse des donnée.
OLTP et ses transactions consti- Différentes bases de données
Les données tuent la source originale de don- OLTP deviennent la source de
nées. données pour OLAP.
La base de données OLAP n’est
La base de données OLTP doit
pas fréquemment modifiée. Par
Intégrité maintenir la contrainte d’intégrité
conséquent, l’intégrité des don-
des données.
nées n’est pas affectée.
Grand nombre de transactions
Caractéristique Grand nombre de données.
courtes.
Opération Lecture/écriture. Lecture.
Requêtes Des requêtes plus simples. Des Requêtes plus complexes.
Utilisateurs L’agent opérationnel. Les analystes et les décideurs .
Table 3.2 – Comparaison entre OLAP et OLTP[7]
3.2.5.3 Les types des systèmes OLAP

Le système OLAP comporte trois types :
ROLAP : Relational Online Analytical Processing.

Le modèle ROLAP est un OLAP relationnel. Il permet d’accéder directement aux données qui
sont stockées dans un format relationnel. Cette approche est utilisée pour les gros volumes de
données et effectue les requêtes avec un produit ROLAP en utilisant le langage SQL.
MOLAP : Multidimensional OnLine Analytical Processing.
Le modèle MOLAP permet de stocke les données dans un ou plusieurs cube OLAP multidi-
mensionnel,les données existent dans un format propriétaire et non pas dans la base de données
relationnelle.
HOLAP : Hybrid Online Analytical Processing .
Le modèle HOLAP est une combinaison de MOLAP et ROLAP. Dans ce modèle, les données
détaillées sont stockées dans une base de données relationnelle (HOLAP) tandis que les données
résumées sont stockées dans un cube OLAP multidimensionnel (MOLAP).
22
3.2.6 Tiers Front-end

La Front-room illustre la solution analytique élaborée. En d’autres termes c’est la zone de pré-
sentation qui sera livré au client sous forme d’interface abstraite facile à gérer.
3.3 Environnement technique

3.3.1 Environnement matériel
Nous avons utilisé l’environnement ci-dessous, tel que mentionné au Tableau 3.3.
Processeur 11th Gen Intel(R) Core(TM) i3-1115G4 @ 3.00GHz 3.00 GHz

RAM 8,00 Go
Système d’exploitation Windows 10 professionnel(x64)
Table 3.3 – Environnement matériel
3.3.2 Environnement logiciel

3.3.2.1 Comparatif des outils ETL
L’objectif de cette est distinguer les points faibles des outils SSIS et Talend, les deux outils les
plus utilisés.
Le Tableau 3.4 montre les principales bases de comparaison de chaque outil :
Base de comparaison SSIS Talend

Développeur Microsoft Talend
ETL permet d’extraire des don-
Extraction, transformation et
nées à partir de plusieurs sources,
chargement des données à partir
Objectif de les transformer puis les charger
de plusieurs et différents source
en une seule destination centrali-
de données.
sée.
SSIS permet d’éxécuter un grand
nombre de processus en paral-
Interfaces rapides et simple à uti-
léle. IL fournit de nombreux ou-
Avantages liser. La conception des jobs est
tils pour transformer les données
trés simple.
au cours du processus de migra-
tion.
Il est impossible de dupliquer un
flux existant, donc on a plusieurs La synchronisation avec Git de-
Inconvénients
similaires, on doit toutes les saisir vrait être facilitée.
de zéro.
23
Une fois développés, les packages

Talend data integration a rationa-
Retour sur investisse- sont trés stables et nécessitent
lisé la gestion de son entrepôt de
ment peu de maintenance, ce qui per-
données, ce qui permet de reduire
met d’économiser le temps de tra-
les coûts et les délais.
vail.
SSIS peut améliorer la gestion
de différents types de données. La version open source devrait in-
La connectivité avec différentes clure des fonctionnalités telles que
Marge d’amélioration
sources de données telles que la la gestion des versions du code
connectivité Salesforce, la connec- source et l’exécution parallèle.
tivité d’Oracle Cloud, etc.
Cela nécessite un peu de ré-
Problèmes d’évolutivité Aucun. glage avant d’atteindre les perfor-
mances optimales.
Table 3.4 – Comparatif des outils ETL[8]
Il est clairement visible que SSIS foncitonne mieux que Talend sur certaines transformations
simples. Mais cela ne signifie que SSIS surclassera Talend dans tous les domaines. Nous pouvons
affirmer que ces deux outils ont leurs propres avantages et inconvénients et qu’en fonction de nos
besoins, nous avons choisi de travailler avec SSIS.
3.3.2.2 Comparatif des outils de visualisation

Le Tableau 3.5 sert à réprésenter une étude comparatif sur les caractéristiques des trois concurents
Power BI, Tableau et Qlick.
Base de comparaison Power BI Tableau Qlik

Développeur Microsoft Tableau Qlik
Il peut gérer un vo-
Il peut gérer un
lume limité de don- Qlik a besoin d’un
énorme volume de
nées, facile à utili- développeur pour tra-
données avec de
ser et il permet aux vailler avec des rap-
Performance meilleurs perfor-
utilisateurs de générer ports et des tableaux
mances, offre un
des analyses avancées de bords et ils ont des
mécanisme facile à
ainsi que des visualisa- bonnes visualisations
utiliser .
tions.
Les tableaux de bord
sont la fonctionnalité
clé de PowerBI lors- L’interface utilisateur
L’interface utilisateur
Interface utilisateur qu’il dispose d’une est assez en baisse par
est meilleure .
bonne interface utili- rapport à Tableau.
sateur pour publier le
rapport.
24
Ils ne nécessitent au- Facile à apprendre

Convivial,La connais- cune compétence tech- avec une formation en
sance d’Excel est suffi- nique ou de program- science des données
Facilité d’apprentissage sante et lèinterface Po- mation pour travailler et difficile à utiliser
wer BI est trés facile à avec et il offre une in- sans connaissance des
apprendre. terface glisser-déposer scripts et des modéles
simple à utiliser. de données.
Ils convient le mieux
C’est le meilleur ou-
aux utilisateurs pro- QlikView est éxcellent
til pour le développe-
Pertinence fessionnels, aux cher- pour les équipes
ment des tableaux de
cheurs et aux univer- d’analyse internes.
bords.
sitaires.
Trés cher car il charge
Rentabilité Moins cher. un entrepôt de don- Cher.
nées.
Ils ont une meilleure
La vitesse dépend de vitesse car ils stockent
Ils ont une récupéra-
Vitesse la RAM et des en- les données dans la
tion intelligente.
sembles de données. RAM du serveur (sto-
ckage en mémoire).
Les solutions Power
Bi sont économiques
et évolutives pour les Ils sont les mieux clas- Ils fournissent une
Avantage grands projets et il sés dans les visualisa- large gamme d’ana-
permet la manipula- tions d’intelligence. lyses approfondies.
tion des données avant
d’importer.
Table 3.5 – Comparatif des outils de visualisation[9]
Tableau, Power BI et QlikView sont des outils de Business Intelligence tout puissants. Chacun
d’eux excelle dans certains paramétres. Les capacités de glisser-déposer ainsi que les connexions de
données sécurisées font de tableau un précurseur sur le marché.
Les points forts de Qlik incluent les capacités du moteur en mémoire de visualisation des modéles.
La création des tableaux de bord via Power BI peut être partagée entre les équipes et accessible sur
n’importe quel appareil. Globalement, Power BI apparaît comme l’outil concurrent parmi les trois
outils.
25
3.3.2.3 SQL Server 2019
Figure 3.5 – Logo du SQL Server
SQL Server est un outil qui posséde toutes les caractéristiques pour pouvoir accompagner l’uti-
lisateur dans la manipulation, le contrôle, le tri, la mise à jour et bien d’autres actions de bases de
données grâce au langage SQL.
Les avantages de SQL Server sont les suivants :
• Gestion avancée de la sécurité en offrant deux modes d’authentification (Authentification

Windows et Authentification SQLServer).
• SQL Server intégre par défaut des outils de gestion, d’administraion et de développement de
bases de données.
• Déploiement par un setup, mise en oeuvre et administration par des interfaces graphiques
intuitives.
3.3.2.4 SQL Server Management Studio
Figure 3.6 – Logo du SQL Server Management Studio
SSMS est un moteur de base de données relationnelles, crée par Microsoft, qui permet de créer,
d’administrer des bases de données de n’importe quelle taille, de stocker et de manipuler des données
structurées sur un serveur et d’y accéder avec n’importe quel langage de programmation.
Il offre à la fois une interface conviviale et un panel d’outil pour mettre en oeuvre et administrer
les bases de données et les serveurs.
26
3.3.2.5 Visual Studio 2019
Figure 3.7 – Logo du Visual Studio
C’est un environnement de développement intégré qui facilite les tâche de création, débogage et
déploiement d’applications faisant appel à plusieurs langages.
3.3.2.6 SQL Server Integration Services
Figure 3.8 – Logo du SSIS
Comme son nom l’indique, SSIS est un outil d’intégration des différentes données nécessaires
à l’outil décisionnel. Son principal objectif est de faire ETL(Extract-Transform-Load) tout en ayant
une gestion des différentes erreurs.
3.3.2.7 SQL Server Analysis Services
Figure 3.9 – Logo du SSAS
Comme son nom l’indique, SSAS est un outil de traitement analytique en ligne (OLAP) et
d’exploration de données dans Microsoft SQL Server et permettant de créer des cubes OLAP pouvant
être exploités par différents outils de forage, d’exploration de données et de tableaux de bord.
SSAS fournit deux types de modèles analytiques : multidimensionnel et tabulaire. Les cubes
multidimensionnels se déploient en local (on premise), contrairement aux modèles tabulaires qui se
traitent localement et aussi dans les services en ligne (SaaS - Software as a Service) Azure et Power
BI.
27
3.3.2.8 Microsoft Power BI
Figure 3.10 – Logo du Power BI
Power BI est un outil qui créé et commercialisé par Microsoft et qui est définit comme étant un
outil décisionnel de visualisation interactive des données.
Il se traduit en un ensemble de 3 outils majeurs :
Power BI Desktop Power BI service Power BI Application
Logiciel Site web Mobile
Où on construit nos visuels et nos Où on peut consulter, annoter et

rapports. partager nos solutions.
Table 3.6 – Les outils majeurs de Power BI
3.4 Conclusion
Durant ce chapitre, nous avons présenté les outils de développement qui ont contribué à la
réalisation de notre projet, nous avons aussi présenté l’architecture en spécifiant les tâches effectuées
là-dessus. Cette architecture est la base sur laquelle nous allons réaliser la conception du système.
28
CHAPITRE 4
Préparation des données et

Modélisation
4.1 Introduction
Dans le chapitre précédent, nous avons défini l’architecture technique ainsi que les outils utilisés
pour effectuer ce travail. Prenant en considération ces éléments comme point de départ, nous allons
nous concentrer durant ce chapitre sur la source de données et la modélisation dimensionnelle et
la conception du modèle physique en se basant sur le cycle de vie dimensionnel de Ralph Kimball
comme le montre la Figure 4.1.
Figure 4.1 – Phase de modélisation et de conception du modéle physique
29
Chapitre 4. Préparation des données et Modélisation
4.2 Préparation des données

4.2.1 Source de données
4.2.1.1 Etude descriptive de données sources
Durant cette partie, nous allons commencer par collecter les informations depuis trois bases de
données Microsoft SQL Server. la premiére base de données s’appelle "CLC" et la deuxiéme s’appelle
"CLN" et la troisiéme s’appelle "CLSB" contenant les tables suivantes dans le Tableau 4.1 :
Table Description
Décrit les différentes analyses fournisseurs à
Table Réception
la réception.
Table Fournisseur Décrit la liste des fournisseurs.
Décrit les différentes analyses de lait dans les
Table Analyseprocess
Tanks.
Table Tank Décrit la liste des tanks.
Décrit les différentes analyses de lait dans les
Table Analysepf
produits finis.
Table Produitpf Décrit la liste des produits.
Table Societe Décrit la liste des sociétiés.
Table Client Décrit la liste des clients.
Table Réclamation Décrit la liste des réclamations.
Table Région Décrit la liste des régions.
Table Produitrcl Décrit la liste des produits .
Table 4.1 – Description des tables de base données
4.2.1.2 Conception de la base de données source

Dans cette partie nous allons nous intéresser à la modélisation physique de la base, au niveau
relationnel. La base illustrée dans la Figure 4.2 représente 11 tables inter-reliées entre eux.
• Societe, Réception, Analysepf, Analyseprocess, Produitrclet Client

Une société peut avoir une ou plusieurs réceptions, une ou plusieurs analyse process, une ou
plusieurs analyse réclamation, une ou plusieurs clients et une ou plusieurs analyse produit fini.
• Tank, Réception et Analyseprocess

Un tank peut inclure une ou plusieurs réceptions et une ou plusieurs analyse process.
• Fournisseur et Réception
Un fournisseur peut avoir une ou plusieurs réceptions.
• Produitpf et Analysepf
Un produit fini peut avoir une ou plusieurs analyses produit fini.
30
• Societe ,Produitrcl
Une société peut être associée à plusieurs produits , mais un produit ne peut être associé qu’à
une seule société.
• Région et Client
Une région peut inclure une ou plusieurs clients.
• Client et Réclamation
Un client peut avoir plusieurs réclamations, mais une réclamation ne peut être liée qu’à un
seul client.
• Réclamation et Produitrcl
Un Produitrcl peut avoir plusieurs réclamations, mais une réclamation ne peut être liée qu’à
un seul produit.
Figure 4.2 – Modélisation de la base de données sources
4.3 Modélisation multidimensionnelle

L’un des principes de la BI c’est qu’elle nécessite deux éléments importants, ce sont une architec-
ture technique adéquate et une modélisation multidimensionnelle appropriée. La raison pour laquelle
31
ces deux composants doivent être élaborés c’est que l’utilisation directe des sources de données pose
des problèmes liés au fonctionnement et à la qualité du service exigé, ainsi qu’au temps de réponse
des requêtes, causé par des modèles normalisés qui ne répondent pas au besoin évolutif. Dans ce
cadre Ralph Kimball a travaillé sur la modélisation avancée qui assure le pilotage d’une entreprise.
Dans notre cas nous intéressons à l’approche "Buttom-Up" de Mr. Ralph.
La modélisation dimensionnelle est une méthode de conception logique qui vise à présenter les
données sous une forme standardisée intuitive et qui permet des accès hautement performants.
La modélisation multidimensionnelle consiste à considérer un sujet analysé comme un point dans

un espace à plusieurs dimensions. Les données sont organisées de manière à mettre en évidence le
sujet analysé et les différentes perspectives de l’analyse.
4.3.1 La modélisation multidimensionnelle et ses Concepts

« La modélisation multidimensionnelle a donné naissance aux concepts de fait et de dimension
».(kimball 1996)
La modélisation multidimensionnelle se traduit par deux concepts : le concept de fait et le concept
de dimension.
4.3.1.1 Concept de fait

Le sujet analysé est représenté par le concept de fait. Une table de faits est la table centrale d’un
modèle dimensionnel, elle assure les liens entre les dimensions. Elles comportent des clés étrangères,
qui ne sont autres que les clés primaires des tables dedimension.
Exemple :
Prenons l’exemple d’un fait de vente constitué des mesures d’activité suivantes :
Quantité des produits vendus et montant total des ventes :
Figure 4.3 – Exemple de table de fait vente
4.3.1.2 Concept de dimension

Les tables de dimension sont les tables qui raccompagnent une table de faits, elles contiennent les
descriptions textuelles de l’activité. Une table de dimension est constituée de nombreuses colonnes
qui décrivent une ligne. Une dimension modélise une perspective de l’analyse. C’est grâce à cette
table que l’entrepôt de données est compréhensible et utilisable elle permet des analyses en tranches
et en dés. Une dimension est généralement constituée : d’une clé artificielle, une clé naturelle et des
attributs.
32
Exemple :
Le fait à la Figure 4.4 peut être analysé suivant différentes perspectives correspondant à trois
dimensions : temps, produit et magasin.
Figure 4.4 – Exemple de table de dimension
✦Concept hiérarchie :
Une hiérarchie organise les paramètres d’une dimension selon une relation "est-plus-fin" confor-
mément à leur niveau de détail.
Par exemple, pour la dimension “ Géographie ”, ces paramètres sont organisés suivant l’hiérarchie
suivante : (Ville , Région , pays). La hiérarchie sert lors des analyses pour restreindre ou accroître
les niveaux de détail de l’analyse.
4.3.1.3 Comparatif entre les tables de faits et les tables de dimensions

Le Tableau 4.2 suivant récapitule les différences au niveau des données de ces tables :
Tables de faits Tables de dimensions

Peu de colonnes beaucoup de Peu de ligne beaucoup de co-
Structure
lignes lonnes
Mésurables, généralement numé- Descriptives généralement tex-
Données
rique tuelles
Référentiel Plusieurs clés étrangéres Une clés primaire
Valeur Prends de nombreuses valeurs Plus ou moins constantes
Manipulation Participe à des calculs Participe à des contraines
Signification Valeurs de mesure Descriptive
Assure les relations entre les di- Assure l’interface homme / entre-
rôle
mension pôt de données
Table 4.2 – Tableau comparatif entre les tables de faits et les tables des dimensions
33
4.3.2 Les modèles multidimensionnelles

4.3.2.1 Modèle en étoile
Dans le modèle en étoile on trouve au centre la table de faits. L’identifiant de cette table est une
clé multiple composée de la concaténation des clés de chacune des dimensions d’analyse. Autour de
la table de faits on trouve tous les paramètres qui caractérisent les dimensions d’analyse.
Ces caractéristiques sont regroupées dans des tables de dimension.
La force de ce type de modélisation est sa lisibilité et sa performance.
• La lisibilité : La finalité de ce modèle est très évidente et définit clairement les indicateurs
d’analyse.
• La performance : Les chemins d’accès à la base de données sont prévisibles.
Figure 4.5 – Schéma en étoile
4.3.2.2 Modèle en flocon

Il correspond à un schéma en étoile dans lequel les dimensions ont été normalisées, réduisant
chacune d’elles et faisant ainsi apparaitre des hiérarchies de dimension de façon explicite.
Figure 4.6 – Schéma en flocon
34
4.3.2.3 Modèle en constellation

Le principe de la modélisation en constellation est de joindre plusieurs modèles en étoile qui
utilisent des dimensions communes. Un modèle en constellation comprend donc plusieurs faits et
dimensions communes ou non.
Figure 4.7 – Schéma en constellation
4.3.2.4 Avantages des modèles en étoile et en flocon

• Le modèle en flocon offre une vue plus claire de la structure de l’information permettant
notamment de déceler une hiérarchie.
• La normalisation de ce modèle permet de plus de diminuer la redondance, en réduisant la taille

des tables de dimension.
• Kimball préfère le modèle en étoile sur la base de deux arguments :
1. La dénormalisation permet d’améliorer les performances du système lors de l’exécution

des requêtes
2. Le modèle est plus facile à apprendre par l’utilisateur non informaticien.
4.4 Conception du modèle physique

4.4.1 Conception détaillée du data mart « Analyse Fournisseur »
La conception détaillée représente la conception de chaque data mart selon les sujets traités.
Cette section sera dédiée selon Kimball à la spécification ou conception physique du modèle adopté.
Chaque demande à un traitement et une analyse indépendante de l’autre dont nous sommes utilisés
un modèle en étoile.
35
4.4.1.1 Dimension Temps

La dimension temps est « la seule dimension qui figure systématiquement dans tout entrepôt de
données, car en pratique tout entrepôt de données est une série temporelle. Le temps est le plus
souvent la premiére dimension dans le classement sous jacent de la base de données » (Kimball
2001).
La dimension temps se présente comme suit :
Figure 4.8 – Dimension Temps
Le Tableau 4.3 donne plus de détails sur cette dimension :
Désignation Détails
iddate La clé primaire de dimension temps.
jours Les jours où l’analyse a été effectuée.
mois Les mois pendant lesquels l’analyse a été réalisée.
année Les années de réalisation de l’analyse.
Table 4.3 – Tableau descriptif de la dimension temps
4.4.1.2 Dimension Fournisseur

Le fournisseur s’impose comme un élément important dans l’analyse, et intéresse les analystes
et les décideurs de l’entreprise.
Figure 4.9 – Dimension Fournisseur
36
idfournisseur La clé primaire de dimension fournisseur.
nomfournisseur Les noms du fournisseur.
Table 4.4 – Tableau descriptif de la dimension fournisseur
4.4.1.3 Dimension Société

La dimension societe comporte les noms des sociétés pour chaque analyse afin de permettre la
comparaison des analyses entre les sociétés.
Figure 4.10 – Dimension Société
idsociete La clé primaire de dimension société.
nomsociete Les noms du société.
adresse Les adresses du société.
telephone Les téléphones du société.
Table 4.5 – Tableau descriptif de la dimension société
4.4.1.4 Choix de mesures

Pour préparer la table des faits, il est nécessaire de faire un bon usage des éléments collectés
lors de l’étude des données sources. Ensuite, il faut déterminer l’élément que l’on souhaite mesurer.
Dans la table des faits nous avons retenu les mesures suivantes :
Mesure Détails
Quantite La quantité de lait pour chacun des fournisseurs.
densite La moyenne de la densité du lait provenant du fournisseur.
37
etat La situation du refus et l’acceptation du fournisseur.

Les causes de refus ( Acidité faible, Alcool 72 +, Acidité élevé,
causerefus
Mouillage élevé, Formol élévé, PH élevé) du fournisseur.
Table 4.6 – Les mesures de la table des faits
4.4.1.5 Table des faits

La table des faits « Fact_Analyse_Fournisseur » est composée de trois clés étrangères et de
quatre mesures, elle nous permet de faire des analyses sur les fournisseurs. Elle est représentée
comme suit :
Figure 4.11 – Table des faits « Fact_Analyse_Fournisseur »
idanalysefrs La clé primaire de table des faits.
idsociete La clé étrangére de la dimension société .
idfournisseur La clé étrangére de la dimension fournisseur .
iddate La clé étrangére de la dimension date .
Quantité Mesure.
densite Mesure.
etat Mesure.
causerefus Mesure.
Table 4.7 – Table des faits
4.4.2 Modèle physique du data mart « Analyse Fournisseur »

Pour modéliser le data mart, nous sommes utilisés le modèle en étoile. Le modéle est constitué
de trois tables de dimensions et une table des faits. La Figure 4.12 représente le Modèle physique
du data mart « Analyse Fournisseur » .
38
Figure 4.12 – Modèle physique du data mart « Analyse Fournisseur »
4.4.3 Conception détaillée du data mart « Analyse Process »

4.4.3.1 Dimension Tank

Le tank est un réservoir de stockage spécialement conçu pour stocker le lait qui vient d’être
collecté chez les fournisseurs.
La dimension tank se présente comme suit :
Figure 4.13 – Dimension Tank
idtank La clé primaire de dimension tank .
nomtank Les noms du tank.
Table 4.8 – Tableau descriptif de la dimension tank
39


La dimension temps est une dimension pas comme les autres. Autrement dit elle existe généra-
lement dans tout entrepôt de données. C’est grâce à elle que nous pouvons faire les analyses par
rapport au temps et ce qui affirme l’indispensabilité de cette dimension dans n’importe quel entrepôt.
40

Dans la table des faits, nous avons retenu les mesures suivantes :
Mesure Détails
acidite La moyenne de l’acidité du lait dans les tanks.
densite La moyenne de la densité du lait dans les tanks.
mg La moyenne de la matière grasse du lait dans les tanks.
PH La moyenne de PH du lait dans les tanks .
proteine La moyenne des protéines du lait dans les tanks.
nivstabilite La moyenne du niveau de stabilité du lait dans les tanks.

La table des faits « Fact_Analyse_Process » est composée de trois clés étrangères et de cinq
mesures, elle nous permet de faire des analyses sur le lait dans les tanks. Elle est représentée comme
suit :
Figure 4.16 – Table des faits « Fact_Analyse_Process »
41
idanalyseprocess La clé primaire de table des faits.
idtank La clé étrangére de la dimension tank .
acidite Mesure.
densite Mesure.
mg Mesure.
proteine Mesure.
nivstabilite Mesure.
4.4.4 Modèle physique du data mart « Analyse Process »

du data mart « Analyse Process » .
Figure 4.17 – Modèle physique du data mart « Analyse Process »
42
4.4.5 Conception détaillée du data mart « Analyse Physico Chimie»

4.4.5.1 Dimension Produit

La dimension produit représente tous les produits finis disponibles au sein de l’entreprise.
La dimension produit se présente comme suit :
Figure 4.18 – Dimension Produit
idproduit La clé primaire de dimension produit.
nomproduit Les noms du produit fini.
Table 4.13 – Tableau descriptif de la dimension produit

43

La dimension temps est « la seule dimension qui figure systématiquement dans tout entrepôt de
données, car en pratique tout entrepôt de données est une série temporelle. Le temps est le plus
souvent la premiére dimension dans le classement sous jacent de la base de données » (Kimball
2001).
44

Dans la table des faits nous avons retenu les mesures suivantes :
Mesure Détails
acidite La moyenne de l’acidité du lait dans les produits finis.
densite La moyenne de la densité du lait dans produits finis.
mg La moyenne de la matière grasse du lait dans produits finis.
PH La moyenne de PH du lait dans les produits finis .
visa Les conformités du lait dans les produits finis.
La Moyenne du niveau de stabilité du lait dans les produits
nivstabilite
finis.

La table des faits « Fact_Analyse_PhysicoChimie » est composée de trois clés étrangères et de
six mesures, elle nous permet de faire des analyses sur le lait dans les tanks. Elle est représentée
comme suit :
Figure 4.21 – Table des faits « Fact_Analyse_PhysicoChimie »
idanalyseprocess La clé primaire de table des faits.
idtank La clé étrangére de la dimension tank .
acidite Mesure.
45
densite Mesure.
mg Mesure.
visa Mesure.
nivstabilite Mesure.
4.4.6 Modèle physique du data mart « Analyse Physico Chimie »

du data mart « Analyse Physico Chimie » .
Figure 4.22 – Modèle physique du data mart « Analyse Physico Chimie »
4.4.7 Conception détaillée du data mart « Analyse Réclamation»

4.4.7.1 Dimension Client

La dimension client s’impose comme un élément important dans l’analyse, et intéresse les ana-
lystes et les décideurs de l’entreprise.
46
La dimension client se présente comme suit :
Figure 4.23 – Dimension Client
idclient La clé primaire de dimension client.
nomclient Les noms du client.
Table 4.18 – Tableau descriptif de la dimension client
4.4.7.2 Dimension Produit

La dimension produit représente tous les produits de réclamation disponibles au sein de l’entre-
prise.
La dimension produit se présente comme suit :
Figure 4.24 – Dimension Produit
idproduit La clé primaire de dimension produit.
nomproduit Les noms du produit fini.
Table 4.19 – Tableau descriptif de la dimension produit
47
4.4.7.3 Dimension Région

La dimension région représente les zones de rappel de chacun des clients.
La dimension région se présente comme suit :
Figure 4.25 – Dimension Région
idrégion La clé primaire de dimension région.
nomrégion Les noms du région.
Table 4.20 – Tableau descriptif de la dimension région

48

La dimension temps est une dimension pas comme les autres. Autrement dit elle existe généra-
lement dans tout entrepôt de données. C’est grâce à elle que nous pouvons faire les analyses par
rapport au temps et ce qui affirme l’indispensabilité de cette dimension dans n’importe quel entrepôt.

Dans la table des faits, nous avons retenu les mesures suivantes :
Mesure Détails
nbr récalamation Le nombre de réclamations.
Les causes de réclamations(Microbio, Embalage,
cause réclamation
Texture, Santé, Proposition, Appréciation).
Table 4.23 – La mesure de la table des faits
49

La table des faits « Fact_Analyse_Réclamation » est composée de cinq clés étrangères et deux
mesures, elle nous permet de faire des analyses sur le lait dans les tanks. Elle est représentée comme
suit :
Figure 4.28 – Table des faits « Fact_Analyse_Réclamation »
idréclamation La clé primaire de table des faits.
idproduit La clé étrangére de la dimension produit .
idrégion La clé étrangére de la dimension région .
idclient La clé étrangére de la dimension client .
nbr réclamation Mesure.
Cause réclamation Mesure.
4.4.8 Modèle physique du data mart « Analyse Réclamation »

du data mart « Analyse Réclamation » .
50
Figure 4.29 – Modèle physique du data mart « Analyse Réclamation »
4.5 Conclusion
Dans ce chapitre, nous avons présentée notre source de données et la conception de la base
de données, par la suite nous avons entamé la partie modélisation multidimensionnelle afin de bien
identifier les grandes lignes de notre solution. Enfin, nous avons présentée la phase de conception
du modèle physique. Dans le prochain chapitre, nous allons voir le développement ETL ainsi que sa
réalisation pour que nous puissions créer les cubes OLAP et faire les analyses.
51
CHAPITRE 5
Intégration et Analyse des données
5.1 Introduction
Dans ce chapitre nous allons présenter la phase de conception et de développement de la zone
de préparation des données et la création des cubes OLAP ainsi que la phase de déploiement et de
planification de cette zone en se basant sur le cycle de vie dimensionnel de Ralph Kimball comme
le montre la Figure 5.1.
Figure 5.1 – Phase de développement ETL et déploiement
52
Chapitre 5. Intégration et Analyse des données
5.2 Développement ETL

Le processus ETL représente la première étape de réalisation d’un système décisionnel. C’est
l’étape la plus délicate dans le processus BI, pour laquelle elle nécessite beaucoup de temps et
demande un grand effort. Donc l’étape d’ETL se déroule sur 3 phases : Extraction, Transformation
et le Chargement de données dans un entrepôt de données. Pour ce faire, nous avons créé d’abord
un nouveau projet dans l’environnement Visual Studio 2019 et nous avons sélectonné « Integration
Services Project » comme indiqué dans la Figure 5.2.
Figure 5.2 – Création d’un nouveau projet SSIS
Le projet Integration Services est composé de plusieurs Packages, qui à leurs tours sont composés
des Flux de contrôle et des Flux de données : Dans SSIS, l’onglet Flux de contrôle permet de gérer
les tâches nécessaires aux transformations et les éléments de contrôle que le package va exécuter. Au
niveau de l’onglet Flux de données, s’effectue la sélection des données sources, les transformations
qu’elles vont subir, et la précision de leurs destinations. Le schéma dans la Figure 5.3 clarifie la
composition d’un package simple.
53
Figure 5.3 – Composition d’un Package SSIS simple[5]
5.2.1 Connexion aux bases de données

La Figure 5.4 présente l’interface de connexion aux bases de données sources CLC, CLN, CLSB
qu’elles sont considérées comme un input et à la base destination Délice considérée comme étant
un output.
Figure 5.4 – Connection Managers
5.2.2 Intégration des données du Datamart «Analyse Fournisseur»

5.2.2.1 Extraction des données
Au cours de cette étape, nous nous sommes connectés à SQL Server, puis nous avons extrait
les données d’une base de données à trois bases « CLC » « CLN », « CLSB ». Afin de charger mon
datamart par des données spécifiques au sujet traité.
Comme illustré dans la Figure 5.5, nous présentons la connexion au Serveur SQL.
54
Figure 5.5 – Connexion à SQL Serveur
La Figure 5.6 présente les trois bases de données ainsi que l’entrepôt de données.
Figure 5.6 – Les bases de données et l’entrepôt de données
55
Les Figures 5.7, 5.8 et 5.9 illustrent les tables des sources de données utilisées pour la phase
d’extraction .
Figure 5.7 – Table Fournisseur
Figure 5.8 – Table Societe
56
Figure 5.9 – Table Réception
Dans cette Figure 5.10, nous avons extrait l’attribut date de la table Réception.
Figure 5.10 – Attribut date
57
5.2.2.2 Transformation des données

La phase transformation est cruciale dans la réalisation du processus ETL. Les données doivent
être nettoyées et reformatées pour ne pas compromettre les résultats de nos analyses futurs.
La première transformation que nous avons réalisée consiste à combiner plusieurs entrées dans
un seul output avec l’éditeur de transformation "Union ALL" .
Figure 5.11 – Union ALL
Les Figures 5.12, 5.13 et 5.14 illustrent la première transformation appliquée aux tables Societe,
Fournisseur et Réception, ainsi qu’aux attributs de dates de trois bases de données différentes, qui
sont combinées en une seule destination.
Figure 5.12 – Union ALL table Societe
58
Figure 5.13 – Union ALL table Fournisseur
Figure 5.14 – Union ALL table Réception
59
La deuxiéme transformation que nous avons réalisée consiste à créer de nouvelles valeurs de
colonne en appliquant des expressions aux colonnes d’entrée de transformation ou en remplaçant les
données d’une colonne existante avec l’éditeur de transformation "Colonne dérivée".
Figure 5.15 – Colonne dérivée
La Figure 5.16 montre la deuxiéme transformation appliquée sur l’attribut date, on a ajou-
tée des nouvelles colonnes "jour", mois", "annee" et les transformée avec des fonctions "DAY",
"MONTH", "YEAR".
Figure 5.16 – Transformation attribut date
60
La Figure 5.17 illustre la première transformation effectuée sur les attributs de date de trois bases
de données différentes, qui sont fusionnées en une seule table avec l’ajout de nouvelles colonnes.
Figure 5.17 – Union ALL table date
La Figure 5.18 présente la deuxième transformation effectuée sur la table Réception, qui consiste
à remplacer les valeurs "Accepté" et "Réfusé" de la colonne "état" respectivement par "1" et "0",
à l’aide de l’outil de script intégré nommé "Expression Builder".
Figure 5.18 – Transformation table réception
61
5.2.2.3 Chargement des données

Une fois que la phase de transformation ETL est terminée, nous procédons au chargement des
données dans les datamarts du data warehouse "Délice".
Les Figures 5.19, 5.20 et 5.21 illustrent le processus de mapping entre les colonnes des sources
de données et les colonnes de la table de destination.
Figure 5.19 – Mapping entre table Societe et dimension Societe
62
Figure 5.20 – Mapping entre table Fournisseur et dimension Fournisseur
Figure 5.21 – Mapping entre table date et dimension date
63
Nous allons maintenant vider les dimensions. À chaque rafraîchissement, nous éliminons les
anciennes valeurs et les remplaçons par des valeurs à jour afin de les intégrer à l’entrepôt de données.
Cette approche permet d’éviter les doublons et les incohérences dans les données de la table de
dimension.
Nous avons utilisé l’éditeur de tâches "Execute SQL TASK" pour créer des requêtes SQL.
Figure 5.22 – Execute SQL TASK
Les Figures 5.23, 5.24 et 5.25 présentent les requêtes SQL que nous avons utilisées pour chaque
table de dimension.
Figure 5.23 – Rafraichissement "Dim_Societe"
64
Figure 5.24 – Rafraichissement "Dim_Fournisseur"
Figure 5.25 – Rafraichissement "Dim_Time"
65
Les prochaines étapes consistent à effectuer le chargement des dimensions, comme présenté dans
les Figures 5.26, 5.27, 5.28 :
• Source : Les tables Societe de trois bases de données .
• Destination : dimension Societe.
Figure 5.26 – Chargement du dimension Societe
66
• Source : Les tables Fournisseur de trois bases de données.
• Destination : Dimension Fournisseur.
Figure 5.27 – Chargement du dimension Fournisseur
• Source : les attributs date de les tables Réceptions.
• Destination : Dimension Temps.
Figure 5.28 – Chargement du dimension Temps
67
Une fois toutes les dimensions chargées dans l’entrepôt de données, il est nécessaire d’ajouter
des clés de substitution à chaque dimension afin d’assurer l’unicité de chaque ligne de ces dernières.
Le chargement de la table des faits s’est fait à partir de la table Réception. Ensuite, nous avons
procédé au mappage entre les dimensions et la table de faits pour les lier, comme indiqué dans la
Figure 5.29.
• Source : les tables Réception de trois bases de données.
• Destination : Table des faits «Fact_Analyse_Fournisseur».
Figure 5.29 – Chargement de la table des faits
5.2.3 Intégration des données du Datamart «Analyse Process»

Comme mentionné précédemment, j’ai besoin de me connecter au serveur Microsoft SQL Server
pour accéder à la source de données, afin de charger des données spécifiques au sujet traité, les
transformer avec l’éditeur correspondant, effectuer le mapping entre les sources et les destinations,
et enfin les charger dans les datamarts de l’entrepôt de données.
Les Figures 5.30, 5.31 et 5.32 montrent l’interface de la phase ETL de chaque dimension.
• Source : les tables Tank de trois bases de données.
• Destination : Dimension Tank.
68
Figure 5.30 – La phase ETL de la dimension « Tank »
• Source : les tables Societe de trois bases de données.
• Destination : Dimension Societe.
Figure 5.31 – La phase ETL de la dimension « Societe »
69
• Source : les attributs date de les tables Analyseprocess.
Figure 5.32 – La phase ETL de la dimension « Temps »
Le chargement de la table des faits s’est fait à partir de la table Analyseprocess. Ensuite, nous
avons procédé au mappage entre les dimensions et la table de faits pour les lier, comme indiqué
dans la Figure 5.33.
70
• Source : les tables Analyseprocess de trois bases de données.
• Destination : Table des faits « Fact_Analyse_Process ».
Figure 5.33 – La phase ETL de la table des faits
5.2.4 Intégration des données du Datamart « Analyse Physico Chi-

mie »
Les Figures 5.34, 5.35 et 5.36 montrent l’interface de la phase ETL de chaque dimension.
• Source : les tables produitpf de trois bases de données.
• Destination : Dimension Produit.
71
Figure 5.34 – La phase ETL de la dimension « Produit »
72
• Source : les attributs date de les tables Analysepf.
Le chargement de la table des faits s’est fait à partir de la table Analysepf. Ensuite, nous avons
Figure 5.37.
73
• Source : les tables Analyseprocess de trois bases de données.
• Destination : Table des faits « Fact_Analyse_Physico_Chimie ».
5.2.5 Intégration des données du Datamart «Analyse Réclamation»

Les Figures 5.38, 5.39, 5.40 et 5.41 montrent l’interface de la phase ETL de chaque dimension.
• Source : les tables Client de trois bases de données.
• Destination : Dimension Client.
74
Figure 5.38 – La phase ETL de la dimension « Client »
75
• Source : les tables Région de trois bases de données.
• Destination : Dimension Région.
Figure 5.40 – La phase ETL de la dimension « Région »
• Source : les attributs date de les tables Réclamation.
76
Le chargement de la table des faits s’est fait à partir de la table Réclamtion. Ensuite, nous avons
Figure 5.42.
• Source : les tables Réclamtion de trois bases de données.
• Destination : Table des faits « Fact_Analyse_Réclamation ».
La Figure 5.43 résume les résultats du chargement des données, en particulier les données de table
de fait. Pour réaliser cet affichage, une requête SQL a été utilisée.
Figure 5.43 – Chargement des données de la table de fait
77
5.2.6 Mise à jour de l’entrepôt de données

Au cours de cette étape, nous avons mis en place une fonctionnalité appelée "Change Data
Capture (CDC)" qui est utilisée pour suivre et enregistrer les changements opérés sur les données
d’une base de données. Elle permet de détecter les insertions, les mises à jour et les suppressions
effectuées sur les enregistrements d’une table ou d’une base de données.
Dans la première étape, nous avons exécuté une requête SQL pour activer la fonctionnalité de
Change Data Capture (CDC) sur les trois bases de données sources dans SQL Server, comme le
montre la Figure 5.44.
Figure 5.44 – Exemple d’activation du CDC pour chaque base de données
Dans la deuxième étape, nous avons exécuté une requête SQL pour activer la fonctionnalité
de Change Data Capture (CDC) sur les tables de la base de données dans SQL Server, comme le
montre la Figure 5.45.
Figure 5.45 – Exemple d’activation du CDC pour la table Societe
Après avoir activé le CDC dans SQL Server, nous avons procédé à la création de la "tâche de
contrôle CDC" dans SSIS. Cette tâche particulière permet de gérer les opérations associées au CDC
au sein d’un package SSIS. Elle offre des fonctionnalités pour contrôler le processus de CDC, no-
tamment l’initialisation, l’activation, la désactivation et la vérification des instances de capture CDC.
Dans la Figure 5.46, montre l’éditeur de tâche de contrôle CDC (Change Data Capture).
Figure 5.46 – CDC Control Task
78
Dans la Figure 5.47, nous avons présenté les fonctionnalités intégrées disponibles dans l’éditeur
de tâche de contrôle CDC, comme suit :
• SQL Server CDC database ADO.NET connection managers : nous avons utilisé un
gestionnaire de connexion ADO.NET pour la base de données source du SQL Server CDC
"CLC". Cela nous a permis d’établir une connexion à la base de données "CLC" et d’accéder
aux données de CDC pour effectuer les opérations requises dans notre flux de travail SSIS.
• CDC Control operation : sont des actions spécifiques effectuées sur les tables ou les bases
de données activées pour le Change Data Capture (CDC) dans SQL Server. Elles ont pour
but de gérer et de contrôler le processus de CDC. Nous avons opté pour l’opération "Get
Processing Range" afin d’obtenir la plage de modifications à traiter de chaque table de base
de données.
• Variable containing the CDC state : Nous avons créé une variable appelée "CDC_State"
pour stocker et gérer l’état actuel du Change Data Capture (CDC) d’une table ou d’une base
de données. Elle nous permet de garder une trace de l’état du CDC tout au long du processus.
• Table to use for storing state : Nous avons créé une table appelée "cdc_states" pour
stocker l’état du CDC (Change Data Capture), telles que les dernières modifications traitées,
les dates de début et de fin.
• State_name : représente la variable "CDC_State" qui stocke l’état actuel du processus CDC,
tel que l’étape de traitement en cours, le dernier point de contrôle atteint.
Figure 5.47 – CDC Control Task Editor
79
5.3 Analyse multidimensionnelle

Maintenant que le data warehouse est prêt, on va créer un cube afin d’organiser les données en
vue de faciliter leurs analyses ainsi que la navigation entre les dimensions.
La réalisation du cube doit se faire dans un autre projet sous Visual Studio par le biais d’un
projet Analysis Services (SSAS).
5.3.1 Cube OLAP

Un cube OLAP est une base de données avancée conçue pour les Data Warehouses et les
applications OLAP, qui stocke les données sous forme multidimensionnelle pour faciliter l’analyse et
le reporting. Ces cubes sont généralement pré-agrégés pour accélérer les temps de requête, surpassant
ainsi les performances des bases de données relationnelles classiques.
Pour effectuer des requêtes au sein des cubes OLAP, on utilise le langage MDX (multimensional
expressions). Ce langage fut développé par Microsoft à la fin des années 1990 avant d’être adopté
par les autres vendeurs de bases de données multidimensionnelles.
L’exemple d’un cube OLAP est présenté dans la Figure 5.48. Il se compose de trois dimensions :
Année, Vendeur et Produit, tandis que la mesure utilisée est le prix de vente.
Figure 5.48 – Exemple d’un cube OLAP [6]
5.3.2 Réalisation de cubes

Avant le passage à la phase de restitution nous avons choisi de créer un cube OLAP assurant
la rapidité des traitements. nous avons créé d’abord un nouveau projet dans l’environnement Visual
Studio 2019 et nous avons sélectonné « Integration Services Project » comme indiqué dans la Figure
5.49.
80
Figure 5.49 – Création d’un nouveau projet SSAS
La première étape consiste à créer une connexion vers le data warehouse créé précédemment.
Figure 5.50 – Créer une connexion avec la data warehouse
La seconde étape se résume par la création d’une vue de sources de données afin de créer des
objets multidimensionnels dans le but d’exploiter ces même sources.
81
Figure 5.51 – Créer une vue de données
Dans cette étape, nous allons sélectionner les tables pour créer la vue de data source.
Figure 5.52 – L’ajout de la table de faits et dimensions
82
Finalement, on passe à la création du cube qui va être constitué d’une base de fait appelée
’Cube_Analyse_Process’ et quatre dimensions qui reflètent les axes sur lesquels on désire effectuer
une analyse.
Figure 5.53 – La structure du cube
83
La Figure 5.54 représente le cube nommé « Cube_Analyse_Fournisseur ». qui est composé de

trois dimensions (Societe, Temps, Fournisseur) et inclut quatre mesures (Quantite, densite, etat,
causerefus).
Figure 5.54 – Conception « Cube_Analyse_Fournisseur »
84
La Figure 5.55 représente le cube nommé « Cube_Analyse_Process », qui est composé de trois
dimensions (Societe, Temps, Fournisseur) et inclut cinq mesures (acidite, mg, densite, pH, protéine,
et nivstabilite).
Figure 5.55 – Conception « Cube_Analyse_Process »
85
La Figure 5.56 représente le cube nommé « Cube_Analyse_Physico_Chimie », qui est composé

de trois dimensions (Societe, Temps, Fournisseur) et inclut six mesures (acidite, densité, pH, mg,
nivstabilite, visa).
Figure 5.56 – Conception « Cube_Analyse_Physico_Chimie »
86
La Figure 5.57 représente le cube nommé « Cube_Analyse_Réclamation », qui est composé de

trois dimensions (Societe, Temps, Fournisseur) et inclut deux mesures (nombre de réclamations).
Figure 5.57 – Conception « Cube_Analyse_Réclamation »
Une fois que le cube a été créé, il est temps de passer à l’étape suivante qui consiste à sélectionner
les champs des dimensions nécessaires pour réaliser notre analyse et créer les hiérarchies requises.
La Figure 5.58 montre la dimension société avant la sélection des champs nécessaires.
Figure 5.58 – La dimension Societe avant l’ajout des champs
87
La Figure 5.59 montre la dimension société aprés la sélection des champs nécessaires.
Figure 5.59 – La dimension Societe après l’ajout des champ
La Figure 5.60 illustrée La création d’une hiérarchie de la dimension Temps.
Figure 5.60 – Hiérarchie de la dimension Temps
88
5.4 Déploiement
Et finalement, déployer le projet pour pouvoir le connecter avec Power BI afin de réaliser les
analyses.
Figure 5.61 – Déploiement des cubes
La Figure 5.62 résume les résultats du chargement du cube, et cet affichage a été réalisé à l’aide
d’une requête MDX(Multidimensional Expressions).
Figure 5.62 – Exploration du cube
5.5 Conclusion
Au cours de ce chapitre, nous avons réalisé le processus ETL et créé des cubes multidimensionnels.
Ensuite, nous avons présenté la phase de déploiement de nos cubes. Dans le prochain chapitre, nous
allons aborder la partie de restitution, notamment le reporting et les tableaux de bord.
89
CHAPITRE 6
Restitution des données
6.1 Introduction
L’étape de réalisation est celle qui résume le travail effectué lors du chargement de notre entrepôt
de données. Ce chapitre se base sur le modèle déjà généré suivant le cycle de vie dimensionnel de
Ralph Kimball illustré dans la Figure 6.1. Nous entamerons donc dans ce qui suit la spécification et
le développement de l’application utilisateur.
Dans ce chapitre, nous allons voir la phase de restitution de notre projet. Nous allons présenter
tout ce que nous avons fait sous forme des tableaux de bord et des rapports dynamiques.
Figure 6.1 – Phase de réalisation suivant le cycle de vie dimensionnel de Ralph

Kimball
90
Chapitre 6. Restitution des données
6.2 Phase de restitution

La phase de restitution présente la dernière étape du processus Bi. Elle consiste de créer des
tableaux de bord pour fixer des objectifs chiffrés et réalistes, ainsi qu’ils fournissent au décideur tous
les informations nécessaires pour prendre les décisions adéquates.
La mise en place du tableau de bord va se réaliser à l’aide du l’outil Power BI. Pour que cela
soit possible, il faut importer le cube créé auparavant à Power BI comme le montre les Figure 6.2,
6.3 et 6.4.
Figure 6.2 – Choix du type des données
Figure 6.3 – Choix du projet
91
Figure 6.4 – Navigateur de cube
6.2.1 Choix des graphiques

Power BI offre une variété de graphiques pour visualiser les données, il est donc crucial de choisir
ceux qui répondent le mieux à nos besoins. Dans notre analyse, nous avons utilisé les types de
visualisations suivantes pour construire nos tableaux de bord :
• carte : Les cartes à un seul numéro montrent un seul fait, un seul point de données.
• Segments : Les segments sont fournis dans différents formats (catégorie, plage, date) et
peuvent être mis en forme pour permettre la sélection d’une, de plusieurs ou de toutes les
valeurs disponibles.
• ChicletSlicer : Affiche des boutons représentant une image ou du texte qui font office de
filtres dans la zone de dessin sur d’autres visuels.
• Graphiques en secteurs : Ils montrent la relation des parties par rapport à un tout.
• Graphiques en anneau : Les graphiques en anneau sont similaires aux graphiques en secteurs.
Ils affichent la relation de parties par rapport à un tout. La seule différence est que le centre
est vide et qu’il y a de la place pour une étiquette ou une icône.
• Histogramme empilé : L’histogramme empilé 100% est un visuel qui présente la valeur de
la mesure antérieure et postérieure, en fonction de la colonne sélectionnée, sous la forme d’un
histogramme empilé 100%.
6.2.2 Création du tableau de bord version desktop

Une fois que l’intégration du cube dans Power BI et la sélection des types de graphiques ont été
réalisées avec succès, on peut maintenant avancer vers la création des tableaux de bord.
92
La Figure 6.5 présente la page d’accueil qui expose les diverses fonctionnalités offertes par notre
solution. À travers cette étape, nous pouvons observer la navigation entre les pages du tableau de
bord à l’aide de boutons ("Analyse Fournisseur", "Analyse Process", "Analyse Produit fini", "Analyse
Réclamation".
Figure 6.5 – Page d’accueil
Nous allons d’abord cliquer sur le bouton "Analyse Fournisseur" qui nous dirigera vers notre
premier tableau de bord, comme illustré dans les figures suivantes.
La Figure 6.6 présente le "Dashboard Qualité", qui permet de comparer la quantité totale et la
densité (PQ) (doit être supérieure ou égale à 1.028) des cinq premiers fournisseurs en fonction des
années, mois et jours, pour trois sociétés (CLC, CLN, CLSB).
Figure 6.6 – Top 5 Fournisseur
93
La Figure 6.7 fournit une explication des éléments interactifs présents dans le "Dashboard Qua-
lité", qui permettent à l’utilisateur de participer activement à l’exploration et à l’analyse des données.
Ces éléments comprennent des fonctionnalités telles que des boutons, des listes déroulantes et des
graphes, qui sont présentés comme suit :
1. Un bouton qui ramène à la page d’accueil.
2. Un graphe appelé "Chicklet Slicer" permet de filtrer les analyses de chaque société de manière
individuelle. Il est possible de sélectionner les sociétés à travers une série de boutons cliquables
pour afficher les analyses correspondantes.
3. Deux bouton, l’un pour revenir à la page précédente et l’autre pour accéder à la page suivante.
4. On peut sélectionner les périodes correspondant à l’analyse en utilisant trois listes déroulantes
(segments) qui permettent de choisir les jours, les mois et les années.
5. Une légende permet d’identifier les deux conditions représentées par les barres du graphique
dans un histogramme. Voir la Figure 6.8
6. On a ajouté un filtre à ce graphique qui permet de sélectionner les cinq principaux fournisseurs
en fonction de la quantité ainsi que les fournisseurs acceptés. Voir la Figure 6.9
Figure 6.7 – Explication détaillée du "Dashboard Qualité"
La Figure 6.8 présente la syntaxe de la colonne conditionnelle en langage M dans Power BI.
Figure 6.8 – Colonne conditionnelle
94
Le graphique présenté dans la Figure 6.9 est filtré pour afficher les cinq principaux fournisseurs.
Figure 6.9 – Filtre de Top 5 Fournisseur
La Figure 6.10 présente le "Dashboard Qualité", qui permet de comparer la quantité totale et la
densité du lait (doit être supérieure ou égale à 1.028) des cinq derniers fournisseurs en fonction des
années, mois et jours, pour trois sociétés (CLC, CLN, CLSB).
Figure 6.10 – Last 5 Fournisseur
95
La Figure 6.11 montre le "Dashboard Qualité", qui permet de visualiser le nombre et les causes
de refus pour les fournisseurs ayant été rejetés chaque année, mois et jour pour trois sociétés(CLC,
CLN, CLSB). Les raisons de refus sont classées en pourcentages et incluent une faible densité, une
teneur en alcool élevée, un mouillage excessif, une teneur élevée en formol, une teneur élevée en
amidon, une faible acidité, un faible pH, un pH élevé et une acidité élevée.
Figure 6.11 – Nombre et cause du refus du fournisseur
Le "Dashboard Qualité" représenté dans la Figure 6.12 offre une vue sur l’analyse de la teneur en
matière grasse (30 ou plus), de l’acidité (15 ou plus) et de la densité (1,028 ou plus) du lait contenu
dans les tanks, pour des périodes allant de jours à des années. Il permet également de comparer
cette analyse entre les trois sociétés (CLC, CLN, CLSB).
Figure 6.12 – Dashbooard analyse process 1
96
La Figure 6.13 présente le "Dashboard Qualité", qui permet d’analyser le pH (inférieur ou égal
à 6,8) et le niveau de stabilité (1,5 ou plus) du lait stocké dans les tanks, sur des périodes allant de
jours à des années. Ce tableau de bord permet également de comparer ces analyses entre les trois
sociétés (CLC, CLN, CLSB).
Figure 6.13 – Dashbooard analyse process 2
Le "Dashboard Qualité" présenté dans la Figure 6.14 offre une visualisation de l’analyse de la PH
(inférieure ou égale à 6,8), de la conformité (conforme ou non conforme) et de la densité (supérieure
ou égale à 1,028) du lait dans les tanks, pour les jours, les mois et les années. Ce dashboard permet
également une comparaison de ces analyses entre les trois sociétés (CLC, CLN, CLSB).
Figure 6.14 – Dashbooard analyse produit finis 1
97
La Figure 6.15 présente le "Dashboard Qualité", qui permet de visualiser l’analyse de plusieurs
paramètres tels que la matière grasse (6,8 ou inférieur), la conformité (conforme ou non conforme),
l’acidité (15 ou plus) et le niveau de stabilité (1,5 ou plus) du lait dans les tanks, pour les jours, les
mois et les années. Ce dashboard permet également de comparer ces analyses entre les trois sociétés
(CLC, CLN, CLSB).
Figure 6.15 – Dashbooard analyse produit finis 2
La Figure 6.16 présente le "Dashboard Qualité" permettant de visualiser le nombre de réclama-

tions ainsi que les cinq principales réclamations en fonction du produit, de client, de région et de la
période (jour, mois et année). Ce dashboard permet également de comparer ces analyses entre les
trois sociétés (CLC, CLN, CLSB).
Figure 6.16 – Top 5 Réclamation
98
Le "Dashboard Qualité" illustré dans la Figure 6.17 permet de visualiser le nombre de réclamations
ainsi que les cinq principales causes de réclamations (Microbio, Emballage, Aspect Goût, Santé,
Texture) en fonction du produit, de la région et de la période (jour, mois et année). Ce dashboard
permet également de comparer ces analyses entre les trois sociétés (CLC, CLN, CLSB).
Figure 6.17 – Top 5 cause de Réclamation
6.2.3 Publication des rapports dans le portail de Power BI

Power BI est une solution décisionnelle complète qui permet non seulement la création de rap-
ports interactifs, mais aussi de partager facilement des informations visuelles et interactives avec les
utilisateurs de l’organisation. Ainsi, la prise de décision est facilitée et les rapports sont accessibles
en tout lieu.
Nous nous proposons de publier les dashbords dans Power BI afin d’assurer le partage et l’acces-
sibilité de celui-ci. Il suffit de se connecter au compte Microsoft 365 et de cliquer sur l’icône ’publier’
situant au coin droit en haut de l’interface de Power BI Desktop.
Une fois la connexion s’est établie et le dashboard s’est publié, un message de succès s’affiche
comme-suit :
Figure 6.18 – Publication du dashboard souhaité dans Power BI
99
Une fois publié, le dashboard sera accessible à partir du site Power BI en ligne (https://app.powerbi.com/).
Sous la section ’Mon espace de travail’, nous trouvons tous les dashboads publiés et que nous puis-
sions partagés avec les personnes concernées.
La figure 6.19 montre un exemple d’affichage d’un dashboard sur Power BI web.
Figure 6.19 – Affichage d’un dashboard dans Power BI Web
6.2.4 Création du tableau de bord version mobile

Power BI propose une version mobile pour les smartphones et tablettes, disponible gratuitement
sur l’App Store et Google Play. Cette version permet d’accéder à vos tableaux de bord, rapports et
visualisations à tout moment, où que vous soyez. Elle offre également la possibilité d’interagir avec
les données et les visualisations, ainsi que de partager les rapports avec d’autres utilisateurs.
Pour commencer, nous allons télécharger l’application Power BI sur notre téléphone portable.
100
Les Figures 6.20, 6.2, 6.22 et 6.23 présentent des captures d’écran montrant les dashboads que
nous avons créés pour les interfaces mobiles.
Figure 6.20 – Page d’acceuil
Figure 6.21 – Top 5 Fournisseur
101
Figure 6.22 – Analyse process
Figure 6.23 – Top 5 Réclamation
102
6.2.5 Prévision
La prévision est une méthode qui consiste à utiliser des données historiques pour projeter les
valeurs futures d’une série de données. Pour cela, nous avons utilisé la fonction de prévision de
Power BI, qui nous a permis de générer des modèles prédictifs pour estimer les quantités de lait
prévues pour les années 2024 et 2025, en se basant sur les données historiques de quantités de lait
disponibles.
La Figure 6.24 présente les prévisions de quantités de lait pour la période 2024 et 2025. Ces
prévisions permettent d’estimer les quantités de lait attendues pour chaque année, en se basant sur
des données historiques de quantités de lait disponibles et en utilisant la fonction prévision.
Figure 6.24 – Prévision des quantités pour la période 2024-2025
6.3 Conclusion
Dans ce chapitre, nous avons exposé notre travail sur la création des dashboards dynamique
pour l’analyse de données. Nous avons commencé par présenter les dashboards en version desktop,
qui sont destinés à une utilisation sur ordinateur, et que nous avons ensuite publiés sur Power BI
web. Par la suite, nous avons également présenté les dashboards en version mobile, accompagnés de
captures d’écran pour illustrer le résultat final. Enfin, nous avons effectué une prévision à l’aide de
Power BI.
103
Conclusion générale
De nos jours, la détention de bonnes informations est une nécessité pour toutes les entreprises,
quel que soit leurs secteurs d’activité, en raison du volume massif de données disponible. La dispo-
nibilité d’un système fiable fournissant des données correctement restituées devient essentielle pour
tout décideur souhaitant garantir la croissance de son entreprise.
Au cours de ce stage d’une durée de trois mois, nous avons développé une solution de business
intelligence visant à faciliter le processus de prise de décision dans le secteur Pôle Lait du Groupe
Délice.
En premier lieu, nous avons commencé par étudier et analyser l’existant. Ensuite, en se basant
sur cette étude, nous avons dégagé les besoins de notre projet, nous avons implémenté notre modèle
de données et nous avons réalisé notre rapport en suivant la démarche de Ralph Kimball. Pour notre
conception, nous avons choisis le modèle en étoile pour notre entrepôt de données.
Après avoir clarifié le modèle conceptuel de notre entrepôt de données, nous avons procédé au
processus ETL afin de fournir des données aux différents data marts (Analyse Fournisseur, Analyse
Process, Analyse Physico Chimie, Analyse Réclamation). Une fois ce processus terminé, nous avons
utilisé les cubes OLAP pour réaliser des analyses multidimensionnelles. Dans la partie qui suit, nous
avons créé des dashboards interactifs en version Desktop et mobile qui nous ont permis de suivre la
qualité du lait de manière dynamique et en temps réel entre les trois sociétés.
Cette expérience a été d’une grande valeur ajoutée. Elle nous a permis de consolider nos connais-
sances académiques et de les mettre en pratique dans un environnement professionnel tout en col-
laborant avec d’autres consultants et experts du domaine décisionnel.
En guise de perspectives, notre solution a l’avantage d’être évolutive et extensible. En effet, nous
envisageons d’élargir notre projet en incluant les autres secteurs tels que le Pôle Boisson et le Pôle
Fromage du Groupe Délice dans notre solution de business intelligence, ce qui permettrait une vision
globale et une meilleure prise de décision à l’échelle de l’entreprise. De plus, nous pouvons profiter
des données restituées au niveau du data warehouse pour la prédiction et l’application de techniques
de machine learning. Cela nous permettrait d’obtenir des insights plus approfondis et de développer
des modèles prédictifs pour anticiper les tendances de qualité du lait et optimiser les processus.
104
Bibliographie
[1] “Cycle de vie de bill inmon, (consulté le 05/02/2023).” [Online]. Available :

https://fr.slideshare.net/SaidSadik/etat-de-lart-approche-et-outils-bi
[2] “Le cycle de vie de ralph kimball, (consulté le 06/02/2023).” [Online]. Available :
https://www.calameo.com/read/005322362eb7af096a86c
[3] “Processus etl, (consulté le 10/02/2023).” [Online]. Available : https://www.datachannel.

co/blogs/what-is-etl-and-how-the-etl-process-works
[4] “Présentation de data mart et comparaison entre datawarehouse et data mart,

(consulté le 14/02/2023).” [Online]. Available : https://www.appvizer.fr/magazine/
services-informatiques/stockage/data-mart
[5] “Composition d’un package SSIS simple, (consulté le 10/03/2023).”

[Online]. Available : https://learn.microsoft.com/en-us/sql/integration-services/
integration-services-ssis-packages
[6] “Exemple d’un cube olap, (consulté le 01/04/2023).” [Online]. Available : https:
//www.data-transitionnumerique.com/cube-olap-decisionnel-big-data/
[7] “Différence entre OLAP et OLTP, (consulté le 19/02/2023).” [Online]. Available :

https://fr.spot-the-difference.info/difference-between-olap
[8] “Comparatif des outils ETL, (consulté le 21/02/2023).” [Online]. Available :

https://www.educba.com/talend-vs-ssis/
[9] “Comparatif des outils de visualisation, (consulté le 22/02/2023).” [Online]. Available :

https://www.educba.com/power-bi-vs-tableau-vs-qlik/
[10] “Présentation d’un data warehouse, (consulté le 15/02/2023).” [Online]. Avai-

lable : https://www.lebigdata.fr/data-warehouse-entrepot-donnees-definition?msclkid=
fd484e6bb78111ecb22676c385d27264
[11] “Les avantage d’un data mart, (consulté le 16/02/2023).” [Online]. Available :
https://www.oracle.com/dz/autonomous-database/what-is-data-mart/
[12] “Définition d’un systéme OLAP, (consulté le 17/02/2023).” [On-

line]. Available : https://www.lebigdata.fr/olap-online-analytical-processing?msclkid=
922ad0edb78911ecbd5a53fda8998085
105

Rapport PFE Balkis Abidi

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

Rapport PFE Balkis Abidi

Transféré par

Droits d'auteur :

Formats disponibles

Ministère de l’enseignement supérieur et de la recherche scientifique

RAPPORT DE STAGE DE FIN D’ETUDES

Pour l’obtention du Diplôme de

Conception et développement d’une solution

Entreprise d’accueil : Centrale Laitière Du Nord

Encadrant pédagogique : Encadrant professionnel :

Année Universitaire 2022-2023

Je tiens à remercier au début les membres du jury d’avoir accepté de juger et

J’exprime ma profonde gratitude à M. Aymen MASTOURI, mon encadrant

Balkis Abidi ...

À mes chers parents Mousadek et Fatma qui m’ont donné un magnifique

2 Planification du projet et Spécification des besoins 12

3.2.2 Types de sources de données . . . . . . . . . . . . . . . . . . . . . . . . . 18

4 Préparation des données et Modélisation 29

4.4.2 Modèle physique du data mart « Analyse Fournisseur » . . . . . . . . . 38

5 Intégration et Analyse des données 52

6 Restitution des données 90

6.2.4 Création du tableau de bord version mobile . . . . . . . . . . . . . . . . 100

Conclusion générale 104

1.1 Logo du Groupe «Délice Holding» . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1 Les phases de planification du projet et de définition des besoins . . . . . . . . 12

3.1 Environnement technique à travers le cycle de vie Ralph Kimbal . . . . . . . . . 17

4.1 Phase de modélisation et de conception du modéle physique . . . . . . . . . . . 29

4.22 Modèle physique du data mart « Analyse Physico Chimie » . . . . . . . . . . . 46

5.1 Phase de développement ETL et déploiement . . . . . . . . . . . . . . . . . . . . 52

5.42 La phase ETL de la table des faits . . . . . . . . . . . . . . . . . . . . . . . . . 77

6.1 Phase de réalisation suivant le cycle de vie dimensionnel de Ralph Kimball . . . 90

1.1 Bill inmon Vs Ralph Kimball . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1 Besoins en termes de restitutions . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.1 Data Warehouse Vs Data Mart[4] . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.1 Description des tables de base données . . . . . . . . . . . . . . . . . . . . . . . 30

• Le quatrième chapitre, intitulé "Préparation des données et Modélisation", aborde la présen-

• Le cinquième chapitre, intitulé "Intégration et Analyse des données", présente la réalisation

• Le dernier chapitre, intitulé "Restitution des données",représente le résultat de notre projet à

1.2 Présentation du Groupe Délice

Figure 1.1 – Logo du Groupe «Délice Holding»

1.2.1 Organigramme du Groupe Délice

Figure 1.2 – Organigramme du Groupe Délice «Pôle Lait»

1.2.2 Les secteurs d’activité Du Groupe Délice

1.3 Présentation des sociétés

1.3.1 Présentation CLN

1.3.2 Présentation CLC

1.3.3 Présentation CLSB

1.3.4 Les activités des sociétés

• Transformation de lait cru,

1.3.5 Organigramme des trois sociétés

Figure 1.3 – Organigramme des sociétés

1.4 Présentation du projet

1.4.2 Étude de l’existant

• Absence d’une solution BI des données qualité,

• Absence des Dashboard des analyses par société,

• Accès lent aux informations,

• Difficulté d’anticipation des tendances relatives à la qualité des produits,

1.4.4 Solution proposée

• Collecter les données nécessaires depuis les systèmes sources,

• Analyser les données et fournir des dashboards dynamiques,

1.5 Méthodologie de travail

1.5.1 Méthodologie d’Inmon

Figure 1.4 – Cycle de vie de Bill Inmon[1]

1.5.2 Méthodologie Kimball

Figure 1.5 – Cycle de vie de Ralph Kimball[2]

1.5.3 Inmon Vs Kimball

Critère Inmon Kimball

Conception comme un pro- Approche itérative pour