Vous êtes sur la page 1sur 91

Dédicace

Du plus profond de mon cœur, je dédie ce travail

A tous ceux qui me sont chers

A mes chers parents


Que ce travail soit l’expression de ma reconnaissance pour vos sacrifices
Consentis, votre soutien moral et matériel que vous n’avez cessé de
prodiguer.

A mon frère Rami, A ma sœur Imen

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


A tous mes amis qui n’ont cessé de m’encourager et de me soutenir.
A tous mes professeurs et ceux qui ont contribué à la réussite de ce travail.

Je dédie ce travail

Mohamed
Dédicace
Du plus profond de mon cœur, je dédie ce travail

A tous ceux qui me sont chers

A mes chers parents


Que ce travail soit l’expression de ma reconnaissance pour vos sacrifices
Consentis, votre soutien moral et matériel que vous n’avez cessé de
prodiguer.

A mon frère Omar, A ma sœur Kenza

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


A tous mes amis qui n’ont cessé de m’encourager et de me soutenir.
A tous mes professeurs et ceux qui ont contribué à la réussite de ce travail.

Je dédie ce travail

Aymen
Remerciement
Au terme de ce travail, nous avons le plaisir d’exprimer nos sincères remerciements à
tous ceux qui ont bien voulu nous apporter leur aide précieuse pour la réalisation de
ce projet de fin d’études.

Nous exprimons tout particulièrement nos remerciements, nos admirations et tout le


respect à nos encadreurs

Mr Anis JEDDIDI et Mme Faiza GHOZZI

Faiza pour avoir acceptées d’encadrer notre projet, pour leurs conseils, toujours
donnés avec extrême amabilité et leurs recommandations pédagogiques et
méthodologiques.

Monsieur le Président, Mesdames et Messieurs les membres du jury, Nous tenons à


vous remercier pour l’intérêt que vous avez bien voulu porter à notre travail en
acceptant de faire partie de ce jury

Merci également à Mr Firas Zekri

Pour avoir participé à la prise de décision utile et pour avoir donné les conseils et les
orientations nécessaires et mis en place toutes les facilités pour rendre le travail Plus
facile.

Enfin, nous remercions tous les enseignants de l’ISIMS qui ont contribué à notre
formation universitaire.
Table des Matières
Introduction Générale ............................................................................................................................................ 1
Chapitre 1 : Cadre du projet................................................................................................................................... 3
I. Introduction .................................................................................................................................................... 4
1. L’organisme d’accueil.................................................................................................................................... 4
2. Présentation de l’entreprise d’accueil ............................................................................................................ 4
3. Objectif de la société ...................................................................................................................................... 5
4. Répartition Géographique .............................................................................................................................. 5
5. Les Services de Clinisys ................................................................................................................................ 6
6. Les nouvelles solutions de CliniSys ............................................................................................................... 6
7. Cadre du projet ............................................................................................................................................... 6
8. Etude de l’existant.......................................................................................................................................... 7
9. Problématique ................................................................................................................................................ 7
10. Solution proposée ......................................................................................................................................... 8
10.1 Objectifs ................................................................................................................................................. 8
11. Travail demandé........................................................................................................................................... 9
12. Plan de déroulement du projet ..................................................................................................................... 9
II. Conclusion ..................................................................................................................................................... 9
Chapitre 2 : Informatique décisionnelle ........................................................................................................... 10
1. Le décisionnel .............................................................................................................................................. 11
2. Revue historique de l’informatique décisionnelle........................................................................................ 11
3. Avantage du BI ............................................................................................................................................ 12
4. Limite du BI ................................................................................................................................................. 12
5. Les principes de l’informatique décisionnelle ............................................................................................. 13
6. L’architecture décisionnelle ......................................................................................................................... 13
7. Entrepôt de données ..................................................................................................................................... 14
7.1 Définition ............................................................................................................................................... 14
8. Magasin de données (Data Mart) ................................................................................................................. 15
9. Modélisation Entité/Relation ....................................................................................................................... 15
10. Modélisation multidimensionnelle ............................................................................................................. 16
11. Modélisation conceptuelle ......................................................................................................................... 16
11.1 Concepts de base ...................................................................................................................................... 16
11.1.1 Modèle en étoile ................................................................................................................................ 17
11.1.2 Modèle en flocon de neige ................................................................................................................ 17
11.1.3 Modèle en constellation .................................................................................................................... 18
12. Processus ETL (Extract, Transform, Load) ............................................................................................... 19
12.1 Extraction ............................................................................................................................................. 19
12.2 Transformation ..................................................................................................................................... 19
12.3 Chargement .......................................................................................................................................... 19
13. Serveur OLAP ........................................................................................................................................... 19
14. Cube OLAP ................................................................................................................................................ 20
15. ROLAP ...................................................................................................................................................... 20
16. MOLAP...................................................................................................................................................... 20
17. Différence entre ROLAP et MOLAP ......................................................................................................... 21
18. Besoin Fonctionnel .................................................................................................................................... 22
19. Les Besoins Non-fonctionnel ..................................................................................................................... 22
II. Conclusion .................................................................................................................................................... 22
Chapitre 3 : Modélisation Conceptuelle ............................................................................................................ 23
I. Introduction .................................................................................................................................................. 24
1. Méthodologie de travail ............................................................................................................................... 24
2. Processus de modélisation d’un ED ............................................................................................................. 24
3. Méthodes de conception d’un ED ................................................................................................................ 25
3.1. Méthode Ascendante (Botton-up) ......................................................................................................... 25
3.2. Méthode descendante (Top-down) ........................................................................................................ 25
3.4. Méthode mixte ...................................................................................................................................... 25
II. Schéma Source de la base de données ......................................................................................................... 26
4. Méthode Ascendante ................................................................................................................................... 27
4.1. Analyse schéma source ........................................................................................................................ 27
5. Méthode Descendante .................................................................................................................................. 32
5.1 Spécification des Besoins....................................................................................................................... 35
6. Méthode Mixte ............................................................................................................................................. 37
Chapitre 4 : Conception et développement de processus de L’ETL et l’enchainement d’un cube OLAP .......... 40
I. Introduction .................................................................................................................................................. 41
1. Conception de l’ETL.................................................................................................................................... 41
2. Diagrammes d’activités................................................................................................................................ 42
2.1 Diagramme d’activité de processus ETL ............................................................................................... 42
3. Développement de l’ETL ............................................................................................................................ 45
3.1. Microsoft SQL Server 2019 .................................................................................................................. 45
3.2. Microsoft SQL Server Intégration Services (SSIS) .............................................................................. 45
3.3. Microsoft SQL Server Mangement studio 18 (SSMS) ......................................................................... 45
3.4. Microsoft Analysis Services ................................................................................................................. 45
3.5. Microsoft Visual Studio 2019 ....................................................................................................................... 46
4. connexion au SQL SERVER ....................................................................................................................... 46
5. les composants de l’ETL ............................................................................................................................. 48
5.1 Flux de contrôle ..................................................................................................................................... 48
5.2 Paramétrage du projet SSIS ................................................................................................................... 50
5.3 Gestionnaire de connexion ..................................................................................................................... 51
6. Flux de données ........................................................................................................................................... 52
6.1 Extraction des données........................................................................................................................... 52
6.2 Transformation et chargement des données ........................................................................................... 54
7. Création du cube OLAP ............................................................................................................................... 58
7.1 Définition ............................................................................................................................................... 58
7.2 Vue de source de données ...................................................................................................................... 58
7.3 Création des dimensions ........................................................................................................................ 59
7.4 Création du Cube ................................................................................................................................... 60
7.5 Déploiement et traitement ..................................................................................................................... 60
I. Conclusion ................................................................................................................................................... 61
Chapitre 5 : Restitution ........................................................................................................................................ 62
I. Introduction .................................................................................................................................................. 63
1. Définition ..................................................................................................................................................... 63
1.1 Microsoft Power BI ................................................................................................................................ 63
1.2 Fonction DAX ........................................................................................................................................ 63
2. Connexion et Chargement Power BI............................................................................................................ 64
3. Modelé ........................................................................................................................................................ 65
4. Diagramme de cas d’utilisation.................................................................................................................... 66
5. Tableaux de bord.......................................................................................................................................... 70
5.1 Power BI ................................................................................................................................................ 70
6. Fonction DAX .............................................................................................................................................. 75
6.1 Création de la table Dates ...................................................................................................................... 75
6.2 Les fonctions .......................................................................................................................................... 76
Fonction ............................................................................................................................................................... 76
CALENDARAUTO ............................................................................................................................................. 76
7. Visualisation Excel ...................................................................................................................................... 77
7.1 Microsoft Excel .................................................................................................................................. 77
II. Conclusion ................................................................................................................................................... 79
CONCLUSION GENERALE .............................................................................................................................. 80
Liste des figures
Figure 1 : Logo de CliniSys ....................................................................................................................... 4
Figure 2 : Répartition géographique........................................................................................................ 5
Figure 3 : Processus du travail ................................................................................................................. 8
Figure 4 : Architecture décisionnelles ................................................................................................... 13
Figure 5 : Architecture décisionnelle ..................................................................................................... 15
Figure 6 : Modèle en étoile.................................................................................................................... 17
Figure 7 : Modèle en flocon de neige .................................................................................................... 18
Figure 8 : Modèle en constellation ........................................................................................................ 18
Figure 9 : Représentation d’un cube OLAP............................................................................................ 21
Figure 10 : Processus de modélisation d’un entrepôt de données ....................................................... 24
Figure 11 : Diagramme de classe du schéma source ............................................................................. 26
Figure 12 : Lien de dépendance entres les classes ................................................................................ 28
Figure 13 : Hiérarchisation des dimensions et définition de la granularité de l’analyse ...................... 29
Figure 14 : Démarche Ascendante ........................................................................................................ 31
Figure 15 : démarche descendante ....................................................................................................... 36
Figure 16 : démarche Mixte................................................................................................................... 38
Figure 17 : Processus ETL ....................................................................................................................... 41
Figure 18 : Diagramme d’activités globales pour le processus de l’ETL ................................................ 42
Figure 19 : Diagramme d'activité flux de contrôle ................................................................................ 43
Figure 20 : Diagramme d'activité flux de données "Client" .................................................................. 43
Figure 21 : diagramme d’activités d’un fait ........................................................................................... 44
Figure 22 : connexion au serveur SQL ................................................................................................... 46
Figure 23 : l’entrepôt de données Local ................................................................................................ 47
Figure 24 : Flux de contrôle ................................................................................................................... 48
Figure 25 : Boite de message ................................................................................................................. 49
Figure 26 : Editeur de boucle foreach ................................................................................................... 50
Figure 27 : Liste de la connexion ........................................................................................................... 51
Figure 28 : Liste des variables ................................................................................................................ 51
Figure 29 : Gestionnaire de connexion .................................................................................................. 52
Figure 30 : Flux de données ................................................................................................................... 52
Figure 31 : Flux de données du processus de chargement de fait règlement ...................................... 54
Figure 32 : Editeur de source OLE DB .................................................................................................... 55
Figure 33 : Editeur de transformation de fractionnement conditionnel fait règlement ...................... 56
Figure 34 : Editeur de transformation de Recherche ............................................................................ 57
Figure 35 : Création de la vue de source de données ........................................................................... 58
Figure 36 : Création de dimension Client .............................................................................................. 59
Figure 37 : Hiérarchies de la dimension Client ...................................................................................... 59
Figure 38 : Table de groupes de mesures.............................................................................................. 60
Figure 39 : Déploiement réussi .............................................................................................................. 60
Figure 40 : Structure du cube dans Microsoft Analysis Server.............................................................. 61
Figure 41 : Connexion au serveur .......................................................................................................... 64
Figure 42 : Tables a chargées ................................................................................................................ 64
Figure 43 : Modèle power BI ................................................................................................................ 65
Figure 44 : Diagramme de cas d'utilisation ........................................................................................... 66
Figure 45 : Menu.................................................................................................................................... 70
Figure 46 : Filtre sur société ................................................................................................................. 71
Figure 47 : Rapport de facture payant .................................................................................................. 71
Figure 48 : Rapport de Règlement par organisme et payant ................................................................ 72
Figure 49 : Rapport de Règlement contentieux et organisme .............................................................. 73
Figure 50 : Rapport de Règlement contentieux et passagers ............................................................... 74
Figure 51 : Rapport de Balance et organisme payant ........................................................................... 75
Figure 52 : COD DAX pour la table DATES ............................................................................................. 75
Figure 53 : facture Payant (Excel) .......................................................................................................... 77
Figure 54 : facture règlement par organisme et par payant (Excel) ..................................................... 78
Figure 55 : Flux Payant contentieux (Excel) ........................................................................................... 79
Liste des tableaux

Tableau 1 : Plan de déroulement du projet ............................................................................................................................ 9


Tableau 2 : Spécification des besoins .................................................................................................................................... 34
Tableau 3 : Description textuelle pour le chef service .......................................................................................................... 67
Tableau 4 : Description textuelle pour le PDG de la clinique ................................................................................................ 69
Tableau 5 : Fonction DAX ...................................................................................................................................................... 76
Liste des acronymes

Acronyme Définition
BI Business Intelligence
SQL Structured Query Language
ERP Enterprise Ressource Planning
ETL Extract-Transform-Load
OLAP Online Analytical Processing
SGBD Système de Gestion de Base de Données
SSMS SQL Server Management Studio
SSIS SQL Server Integration Services
SSAS SQL Server Analysis Services
BD Base de Données
DWH Data Warehouse
DAX Data Analysis Expressions
Introduction Générale
Les entreprises se situent actuellement dans un marché très concurrentiel qui ne cesse d’évoluer
rapidement. Pour garder leur stabilité et acquérir de nouvelles parts du marché, l’entreprise doit
mieux comprendre ses clients et être réactive pour identifier les nouveaux relais de croissance. Dans
ce sens, l’étude de l’évolution du marché devient un défi pour détecter les opportunités et les
menaces. Pour ce faire, l’entreprise a besoin d’outils qui lui permettent de déceler tous ces éléments.

C’est dans cette optique que l’informatique décisionnelle vient pour résoudre les problèmes qui font
face aux entreprises dans l’aide à la décision à travers des moyens, des outils et des méthodes qui
permettent de collecter, consolider, modifier et restituer les données d’une organisation en vue
d’offrir une aide à la décision.

L’analyse de l’évolution de l’activité commerciale devient une tâche fastidieuse pour les décideurs
de la Société Nationale d'édition des logiciels de santé en Tunisie (Clinisys) en absence des outils
appropriés. En outre, il a fallu mettre en place des requêtes complexes, coûteuses en temps de réponse
et en ressources informatiques. Dès lors, l’entreprise souhaite acquérir un système décisionnel qui
permet de répondre à ses besoins d’analyse. Les outils de Business Intelligence permettent de
collecter les informations nécessaires à la mise en place de tableaux de bord adaptés aux besoins des
décideurs. L’entreprise pourra par le biais des applications de Business Intelligence, avoir une image
parfaite de son activité et de faciliter la prise de décision.

C’est dans cette optique que « Clinisys » a exprimé son besoin de mise en place d’un système
décisionnel : une optique qui a pour but de prévoir les futurs objectifs et les moyens dont elle aura
besoin pour cerner également les défis du marché, les pressions de la concurrence et l’évolution des
technologies. Ainsi, ce présent mémoire qui est l’illusion du travail effectué dans ce stage, relate les
différentes phases ainsi que les moyens auxquels nous avons eu recours pour atteindre les objectifs
fixés, et ceci en cinq chapitres.

1
Ce rapport est articulé autour de cinq chapitres

 Chapitre 1 (Cadre du projet) : Dans lequel nous allons présenter le projet


et la société d’accueil.

 Chapitre 2 (Informatique Décisionnelle) : Dans ce chapitre nous allons


développer les notions de base de l’informatique décisionnelle.

 Chapitre 3 (Conception) : Dans ce chapitre nous allons présenter la


conception multidimensionnelle de l’entrepôt de données

 Chapitre 4 (Construction) : Ce quatrième chapitre nous présentons les


différentes phases de la construction de l’entrepôt de données en
commençant par la modélisation logique, physique, la conception et le
développement de l’ETL ainsi l’enchainement du cube OLAP

 Chapitre 5 (Restitution) : Ce chapitre est consacré à la modélisation des


applications BI et la présentation de leurs développements

2
Chapitre 1 : Cadre du projet

3
Chapitre 1 : Cadre du projet

I. Introduction
À travers ce chapitre nous allons présenter l’organisme d’accueil au sein duquel s’est déroulé notre
projet, situons le présent travail dans son contexte général et mettrons en relief le choix
méthodologique que nous avons adopté tout au long de son élaboration.

1. L’organisme d’accueil
Ce Projet de fin d’études a été réalisé au sein de l’entreprise Clinisys (Computer System) durant une
période de quatre mois qui s’étale du 1 février jusqu’au 31 Mai 2022.

2. Présentation de l’entreprise d’accueil


Clinisys ERP est une solution de gestion clinique installée dans 90% des cliniques en Tunisie et
couvre toute leurs activités : administrative et financière, médicale, bloc, stérilisation, ris, pacs et
lis, pharmacie, achat et stock, Rh, elle est actuellement le leader en Afrique du Nord dans le
développement de systèmes d'information hospitaliers intégrés.

Figure 1 : Logo de CliniSys

Depuis plus de 25 ans, CliniSys a réussi à moderniser la gestion des hôpitaux dans des
environnements difficiles et très hostiles et réussi à intégrer dans plus de 130 hôpitaux en Tunisie,
en Egypte, en Libye et au Maroc tous les aspects administratifs, financiers, organisationnels,
médicaux et décisionnels avec un seul produit : CLINISYS.
4
Chapitre 1 : Cadre du projet

3. Objectif de la société
Les réflexions, les orientations et les efforts sont orientés principalement sous ces quatre objectifs :

- Améliorer en continue la qualité de nos solutions pour satisfaire nos clients.

- Assurer la mobilisation et la valorisation de nos portefeuilles de compétences.

- Faciliter la transformation digitale des processus pour nos clients.

- Devenir une société responsable et citoyenne envers son environnement.

4. Répartition Géographique
- 100 hôpitaux/cliniques en Tunisie.

- 30 hôpitaux/cliniques à l'international.

- 30 000 utilisateurs.

- 12 000 lits.

- 3 millions nuitées d'hospitalisation.

Figure 2 : Répartition géographique

5
Chapitre 1 : Cadre du projet

5. Les Services de Clinisys


Clinisys présente à ses clients les services suivants :

- Etude et accompagnement de projets.

- Mise en place totale de l’infrastructure adaptée au système informatique hospitaliser CliniSys.

- Ingénierie Réseau Cliniques et Hôpitaux.

- Etude et conception d’un organigramme organisationnel.

- Etudes des intégrations des plateaux techniques avec le SIH.

- Sécurité & installation des matériels.

6. Les nouvelles solutions de CliniSys


- Gestion budgétaire.
- Traçabilité des instruments chirurgicaux avec RFID.
- Gestion des lignes avec RFID.
- CRM clinisys.
- Application mobile patient Satisfaction patient.
- RFD immobilisations.
- Gestion des files d’attente.
- Soins à domicile.
- SMS send.
- Satisfaction patient.

7. Cadre du projet
Dans le cadre de la préparation du projet de fin d’étude en vue de l’obtention du diplôme de licence
en science informatique spécialité Big Data et analyse des données ce travail consiste à réaliser un
tableau de bord pour analyser le recouvrement d’un groupe de polycliniques en Tunisie analysant
l’activité commerciale de ce groupe.

6
Chapitre 1 : Cadre du projet

8. Etude de l’existant
Actuellement les établissements hospitaliers connaissent une véritable révolution de leur capital
informationnel. Ils agrègent des volumes de données de plus en plus importants, issus de
canaux hétérogènes, qu’il s’agisse des applications de gestion, des applications métier, etc.
Ces établissements ont besoin de collecter, stocker, interpréter et analyser ces données en temps
réel afin de les utiliser pour la prise de décision.
Ainsi, au sein de ces établissements, les décideurs du métier ont besoin de suivre leurs états
budgétaires, leurs chiffres d’affaires, etc. Ces décideurs ont à leur disposition une diversité de
données provenant des différents systèmes transactionnels. Ainsi, ces données doivent être
regroupées pour pouvoir être analysées. Pour cela, l’informatique décisionnelle peut être une
solution pour la mise en place d’une méthodologie et d’outils exploitant ces données.
La solution Business Intelligence que nous proposons doit permettre de :
 Centraliser les données dans un entrepôt de données.
 Obtenir une vision synthétique d’un service ou de l’ensemble de la clinique.
 Aider à la prise de décision via une exploitation efficace des données.
Les partenaires de CliniSys possèdent plusieurs sources de données éparpillées sur des
différents systèmes d’information. Ces systèmes sont représentés essentiellement dans les outils
suivants :
 L’ERP CliniSys : C’est un ERP qui permet la gestion et le suivi au quotidien, l’ensemble
des informations et des services opérationnels des cliniques (développé en .Net).
 Les fichiers Excel : Contiennent toutes les traces financières et budgétaires des cliniques.
Les BDs transactionnelles de ces différents systèmes ne sont pas conçues pour répondre à des
besoins d’analyse et à réaliser des rapports directement à partir de ces bases.

9. Problématique
Les rapports actuels réalisés par CliniSys ne répondent pas aux besoins des décideurs et posent
un problème de lourdeur de cette base de données avec une diminution de la qualité des
données.
En effet, les principales limites du processus de travail actuel qui font face aux décideurs se
résument en ces différents points :

 Une complexité des requêtes de restitution : les informations utiles aux décideurs sont
stockées sur des sites de natures diverses (application web, application mobile, bases de
données relationnelles, fichiers, etc.) ce qui rend difficile l’extraction des données en
vue d’établir un document.
7
Chapitre 1 : Cadre du projet

 Le processus de prise de décision prend beaucoup plus de temps.


 Manque de traçabilité et d’historisation.
 Manque de données agrégées : on ne peut pas avoir une vision synthétique d’un service
ou de l’ensemble de l’entreprise.
 Une difficulté d’analyser les données vue leurs quantités.

10. Solution proposée


Suite à une étude détaillée de l’existant, nous allons fixer l’objectif de ce projet et analyser le
travail demandé.

10.1 Objectifs
Ce projet a pour but d’ajouter une couche BI au sein de l’ERP CliniSys tout en conférant aux
responsables des cliniques un support fiable pour une meilleure prise de décision concernant la
gestion et le pilotage de la clinique. Ce support permet de :

 Prendre en entrée toute base de données provenant du système utilisé par la clinique.
 Regroupe et stocke les données dans un entrepôt de données.
 Avoir des rapports et des tableaux de bords interactifs pour une analyse détaillée.
 Garantir une exploitation optimale des données par rapport aux BDs relationnelles.
 Rendre l’architecture existante conforme aux normes de l’informatique décisionnelle.

Figure 3 : Processus du travail

8
Chapitre 1 : Cadre du projet

11. Travail demandé

Après un certain nombre de discussions avec les décideurs pour analyser leurs besoins
et une analyse des données sources, les tâches que nous avons réalisées au cours de
ce projet sont :
 Conception d’un entrepôt de données (Data Warehouse).
 Création des tables de dimensions et des faits.
 Déploiement du projet pour l’exécuter et création des jobs.
 Conception et développement d’un cube pour l’analyse multidimensionnelle.
 Conception et développement des packages d’alimentation de l’entrepôt de
données à partir du système opérationnel de collecte de données.

 Conception et développement des rapports et des Dashboard de suivi des


indicateurs de performance et les publier.

12. Plan de déroulement du projet

Février Mars Avril Mai


Semaine 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3
Spécification des besoins X X X X
Modélisation conceptuelle X X X
Conception et X X X X X
développement de l’ETL
Modélisation, X X X
développement et de
l’application BI
Evaluation X X
Rédaction du rapport X X X X X X X

Tableau 1 : Plan de déroulement du projet

II. Conclusion
Au cours de ce premier chapitre nous avons présenté le cadre général de notre projet, dont
le premier objectif est la mise en place d’un système décisionnel pour l’ERP CliniSys.
Le deuxième chapitre nous définissons l’informatique décisionnelle, découvrons ses
fonctionnalités essentielles et ses concepts qui feront l’objet du chapitre suivant.

9
Chapitre 2 : Informatique décisionnelle

10
Chapitre 2 : Informatique décisionnelle

I. Introduction
Le Business Intelligence (BI) est un processus technologique d’analyse des données et de
présentation d’informations exploitables pour aider les dirigeants, managers et autres
utilisateurs finaux de l’entreprise à prendre des décisions commerciales éclairées .le BI
englobe une grande variété d’outils, d’applications et de méthodologies qui permettent aux
organisations de collecter des données à partir de systèmes internes et de sources externes,
de les préparer pour l’analyse, de développer et d’exécuter des requêtes par rapport à ces
données, et de créer des rapports, tableaux de bord et visualisations de données pour rendre
les résultats analytiques disponibles aux décideurs et au personnel opérationnel.

1. Le décisionnel
La Business Intelligence (BI), également "intelligence d'affaires" ou "informatique
décisionnelle", englobe les solutions informatiques apportant une aide à la décision avec, en
bout de chaîne, rapports et tableaux de bord de suivi à la fois analytiques et prospectifs. Le
but est de consolider les informations disponibles au sein des bases de données de
l'entreprise.

2. Revue historique de l’informatique décisionnelle


Le terme de business intelligence apparait pour la première fois en 1985 dans un article de
HANS PETER LUHN, chercheur à IBM, qui l’avait défini comme « la capacité
d’appréhender les interrelations des faits présentés de manière à orienter l’action vers un but
désiré ».

Les grandes firmes qui étaient déjà dotées d’un service informatique ont été les premières à
essayer d’exploiter leur BD transactionnelle comme un moyen d’aide à la décision. Elles se
sont appuyées dans les années 70 sue les infocentres : qui mettaient aux dispositions
d’utilisateurs finaux toute la puissance de calcul d’un ordinateur central (Mainframes) au
moyen de terminaux. Dans les années 80, les données de l’informatique transactionnelle,
notamment des ERP, ne se prêtaient pas à une exploitation dans un cadre d’analyse
décisionnelle.

11
Chapitre 2 : Informatique décisionnelle

3. Avantages du BI
 L’alignement d’une organisation autour d’un ensemble cohérant d’indicateurs clés de
performance et de mesures.
 L’accélération de la prise de décision fondée sur des faits.
 La simplification de la présentation graphique des indicateurs de performance clés et
des paramètres d’analyse décisionnelle.
 La présentation uniforme d’informations fiables.
 La combinaison de plusieurs sources de données (ERP, systèmes comptable, feuilles de
calcul, des budgets …).
 L’automatisation permet l’accélération de la collecte et de la diffusion de l’information
 La performance dans le calcul d’agrégat sur de gros volume de données.

4. Limites du BI
 Rationalisation excessive et processus complexes :
Les systèmes décisionnels produisent des indicateurs ou s'appuient sur des modèles dont
l'objectif est de simplifier la réalité pour aider à la prise de décision.
Mais la décision doit bien réintégrer des évaluations humaines qui la replacent dans sa
réalité, qui est restée complexe.

 Sélectivité des données et organisations humaines :


Les systèmes décisionnels s'appuient sur les données que l'on est en mesure de produire,
mais ces données ne peuvent pas intégrer toutes les dimensions d'une organisation et de son
environnement, en particulier les dimensions humaines.
Or ces dimensions cachées au système décisionnel déterminent de nombreux
fonctionnements de l'organisation, et doivent continuer d'être prises en compte.

 L’interprétation est humaine :


Un système décisionnel produit des indicateurs qui nécessitent des interprétations expertes
mais ne produit pas des directives qu'une organisation humaine doit suivre.

12
Chapitre 2 : Informatique décisionnelle

5. Les principes de l’informatique décisionnelle


L’informatique décisionnelle ou "Business Intelligence" se base sur une architecture multi-
tiers formée par les composants de la figure présentée ci-dessous, dont on l’explique :

 En amont un accès au système transactionnel en lecture seule.


 Un entrepôt de données fusionnant les données requises.
 Un ETL permettant d'alimenter l’entrepôt de données à partir des données existantes.
 Des magasins de données permettant de simplifier l’entrepôt de données.
 Des applications d'exploitation de données.

6. L’architecture décisionnelle
Une architecture BI, est un ensemble de concepts, de méthodes, de technologies et d’outils

(logiciels ou matériels) permettant de répondre aux besoins de l’entreprise

Figure 4 : Architecture décisionnelles

13
Chapitre 2 : Informatique décisionnelle

7. Entrepôt de données

7.1 Définition
Bill Immon définit le datawarehouse dans son livre considéré comme étant la référence
dans le domaine «Building the Data Warehouse » comme suit :

« Un entrepôt de données est une collection de données thématiques, intégrées, non


volatiles et historiées, organisées pour la prise de décision »

Le DWH peut être aussi défini comme étant une structure pour l’organisation des systèmes
d’information. Il s’agit d’un processus d’aide à la décision a la gestion de la connaissance
tant pour l’usage quotidien que pour l’élaboration de stratégies à long terme. Les
paragraphes suivants illustrent les caractéristiques citées dans la définition d’Immon :

Orienté sujet : Les donneés dans un datawarehouse sont organisées autour des sujets
majeurs de l’entreprise (Clients, services, achats…).
Intègres : la Datawarehouse permet l’intégration des données hétérogènes provenant de
différentes sources.
Evolutives dans le temps : Contrairement aux systèmes opérationnels qui permettent de
mettre à jour des données, dans un système décisionnel l’historisation des différentes
valeurs d’une donnée est très importante. Cela permet le suivi, la comparaison et l’évolution
de ces valeurs dans le temps.
Généralement, dans un DWH, chaque valeur et associée à un moment bien déterminé
Non volatiles : C’est ce qui est, en quelque sorte, la conséquence de l’historisation décrite
précédemment. Une donnée peut être mise à jour ou supprimée dans un système
opérationnel.
Mais dans un Datawarehouse les données ne disparaissent pas et ne changent pas.
Organisées pour le support d’un processus d’aide à la décision : Les données du
Datawarehouse sont organisées de maniéré a permettre l’exécution des processus d’aide à
la décision (Reporting, datamining…).

14
Chapitre 2 : Informatique décisionnelle

8. Magasin de données (Data Mart)


Un « data mart » est une base de données dont le contenu est en rapport avec une activité de
l'entreprise et qui est créé pour répondre aux besoins spécifiques d'un groupe d'utilisateurs. Il
s'agit souvent (mais pas toujours) d'un segment partitionné dans le data warehouse de
l'entreprise.

Les data marts accélèrent les processus en permettant de définir un accès aux données
stockées dans un data warehouse (Ou autre gisement de données opérationnelles) en
quelques jours au lieu de plusieurs mois ou plus .Il s'agit d'une solution peu coûteuse qui
permet de transformer les données en connaissance exploitable.

Figure 5 : Architecture décisionnelle

9. Modélisation Entité/Relation
C’est un modèle de conception qui permet d’éclairer les relations microscopiques entre les
données ; en éliminant les données redondantes ; ce qui apporte de nombreux avantages au
niveau du traitement des transactions, qui deviennent alors très simples et déterministes. Ce
type de modélisation est adapté au traitement de transaction mais non plus aux requêtes
d’analyse.

D’après Kimball :

"Les modèles entité-relation ne peuvent pas servir de base pour construire des entrepôts
de données de l’entreprise"

15
Chapitre 2 : Informatique décisionnelle

10. Modélisation multidimensionnelle


La modélisation multidimensionnelle 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. Chaque modèle dimensionnel se compose d’un fait, et d’un ensemble de
dimensions.

11. Modélisation conceptuelle


La modélisation multidimensionnelle implique l'utilisation de faits et de dimensions pour
conserver un enregistrement des données historiques dans les entrepôts de données,
différents types de techniques de modélisation de données sont optimisés pour différentes
applications.

11.1 Concepts de base

 Un fait : est un centre d’intérêt décisionnel. Il modélise le sujet de l'analyse. Il regroupe un


ensemble d’attributs numériques représentant les mesures correspondant aux informations
de l'activité analysée ainsi que les identifiants associés aux dimensions.
 Une mesure : est un indicateur d’analyse de type numérique et cumulable. Une mesure est
accompagnée d’un ensemble de fonctions d’agrégation qui permettent de l’agréger en
fonction des axes d’analyse.
Les mesures peuvent être additives, semi-additives et non additives.
 Une dimension : modélise une perspective de l'analyse. C’est un axe d’analyse selon lequel
sont visualisées les mesures d’activité d’un sujet d’analyse.
 Un paramètre : Une dimension se compose de paramètres correspondant aux informations
faisant varier les mesures de l'activité.
 Les paramètres d’une dimension peuvent être accompagnés de descripteurs appelés attributs
faibles qui ne sont pas utilisés dans les calculs de regroupement.
 Une hiérarchie : est une perspective d’analyse définie dans une dimension. Elle regroupe
un ensemble de paramètres organisés de la granularité la plus fine vers la granularité la plus
générale.

16
Chapitre 2 : Informatique décisionnelle

11.1.1 Modèle en étoile


Dans un schéma en étoile, une table centrale de faits contenant les faits à analyser, référence
les tables de dimensions par des clés étrangères. Chaque dimension est décrite par une seule
table dont les attributs représentent les diverses granularités possibles.

 Avantages
 Facilite la navigation.
 Il est facile compréhensible par les utilisateurs.
 Inconvénients
 Redondance au niveau des attributs de la dimension.
 Alimentation complexe.

Figure 6 : Modèle en étoile

11.1.2 Modèle en flocon de neige

Dans un schéma en flocon, cette même table de faits, référence les tables de dimensions de
premier niveau, au même titre que le schéma en étoile. La différence réside dans le fait que
les dimensions sont décrites par une succession de tables représentant la granularité de
l’information. Ce schéma évite les redondances d’information mais nécessite des jointures
lors de l’agrégation de ces dimensions.

 Avantage
 Réduction du volume dans les tables de dimension.
 Offre une structure plus facile à modifier lorsque les besoins évoluent.
 Inconvénients
 Navigation difficile.

17
Chapitre 2 : Informatique décisionnelle

Figure 7 : Modèle en flocon de neige

11.1.3 Modèle en constellation

Le Schéma en constellation est une généralisation du Schéma en étoile. Une constellation


regroupe plusieurs sujets d’analyse (faits) étudiés selon différents axes (dimensions)
éventuellement partagés.

 Avantage :
 Facilite les corrélations entre les différents sujets d’analyse.
 Simplifie la modélisation avec la possibilité de partager les dimensions.

Figure 8 : Modèle en constellation

18
Chapitre 2 : Informatique décisionnelle

12. Processus ETL (Extract, Transform, Load)

Les processus ETL prennent en charge la récupération des données depuis l’ensemble des
sources opérationnelles existantes et de les changer vers le système décisionnel.

12.1 Extraction
L'objectif de ces processus est de produire des données propres, faciles d'accès et qui
peuvent être exploitées efficacement par l'analytique, la Business Intelligence ou/et les
opérations commerciales. Les données brutes peuvent être extraites de différentes sources,
en particulier
- Bases de données existantes.
- Logs d'activité (trafic réseau, rapports d'erreurs, etc.)
- Comportement, performances et anomalies des applications.

12.2 Transformation
L’étape de transformation d’applique à une série de règles ou de fonction aux données
extraites de la source afin de dériver les données pour le chargement. Pour certaines source
de sonnées, il faudra une manipulation très légère voire aucune, des données. Dans d’autres
cas, un ou plusieurs des types de transformation suivant peuvent être nécessaire pour
répondre aux besoins technico-commerciaux de de la base de données cibles.

12.3 Chargement
La dernière étape du processus ETL standard consiste à charger les données extraites et
transformées dans leur nouvel emplacement. En général, les data Warehouse supportent
deux modes pour le chargement des données : chargement complet et chargement
incrémental.

13. Serveur OLAP


En informatique, et plus particulièrement dans le domaine des bases de données, le
traitement analytique en ligne (anglais online Analytical processing, OLAP) est un type
d'application informatique orienté vers l'analyse sur-le-champ d'informations selon plusieurs
axes, dans le but d'obtenir des rapports de synthèse tels que ceux utilisés en analyse
financière.

19
Chapitre 2 : Informatique décisionnelle

14. Cube OLAP


Un cube OLAP est un tableau multidimensionnel de données. Le traitement analytique en
ligne (OLAP) est une technique informatique d'analyse des données pour rechercher des
informations.

Le terme cube fait ici référence à un jeu de données multidimensionnel, qui est aussi parfois
appelé hypercube si le nombre de dimensions est supérieur à 3.

Les cubes OLAP ont les caractéristiques suivantes :

 Obtenir des informations déjà agrégées selon les besoins de l’utilisateur.


 Simplicité et rapidité d’accès.
 Capacité à manipuler les données agrégées selon différentes dimensions
 Un cube utilise les fonctions classiques d’agrégation : min, max, count, sum, avg,
mais peut utiliser des fonctions d’agrégations spécifiques.

15. ROLAP
ROLAP : est un modèle de traitement analytique en ligne relationnel, dans lequel les
données sont stockées comme dans une base de données relationnelle, c'est-à-dire
des lignes et des colonnes dans l'entrepôt de données. Dans le modèle ROLAP, les données
sont présentes devant l'utilisateur sous la forme multidimensionnelle. Pour afficher les
données, dans une vue multidimensionnelle, une couche sémantique de métadonnées est
créée, laquelle mappe la dimension aux tables relationnelles. Les métadonnées prennent
également en charge l’agrégation des données.

16. MOLAP
MOLAP : est un modèle de traitement analytique en ligne multidimensionnel. Les
données utilisées pour l'analyse sont stockées dans des bases de données
multidimensionnelles spécialisées (MDDB). Les systèmes de gestion de base de données
multidimensionnels sont des systèmes logiciels propriétaires.

20
Chapitre 2 : Informatique décisionnelle

Figure 9 : Représentation d’un cube OLAP

17. Différence entre ROLAP et MOLAP

 Le tableau ci-dessous montre la différence entre ROLAP et MOLAP

ROLAP MOLAP

Multidimensionnel Online Analytical


Définition Relationnel Online Analytical Processing Processing

Les données sont stockées sous forme de Les données sont stockées dans le grand tableau
tables relationnelles (Etoile, flocon de multidimensionnel composé de cubes de
Forme de données neige) données.

Accès Accès lent Accès plus rapide.

ROLAP crée une vue multidimensionnelle MOLAP stocke déjà la vue


Vue des données de manière dynamique. multidimensionnelle statique dans les MDDB.
Le moteur MOLAP crée des cubes de données
pré-calculés et préfabriqués pour les vues de
Utilise des requêtes SQL complexes pour données multidimensionnelles. La technologie
extraire des données de l’entrepôt de matrice fragmentée est utilisée pour gérer la
Technologies principal. dispersion des données.

Stockage & Les données sont stockées et extraites de Les données sont stockées et extraites à partir
Récupération l’entrepôt de données principal. des MDDBs de la base de données propriétaire.

21
Chapitre 2 : Informatique décisionnelle

18. Besoin Fonctionnel


Le besoin peut être exprimé de manière fonctionnelle mettant en évidence les fonctions de
services (A quoi ça sert ?) et les fonctions techniques (Comment cela peut marcher ?). Ces
fonctions doivent être ordonnées, hiérarchisées et quantifiées sous la forme de valeurs de
performance attendue.

 Pour un développeur BI :
 Création d’une base de données source et ses différentes tables.
 Création d’un entrepôt de données.
 Création d’un cube OLAP.

Pour un décideur :

 Génération des rapports de table de bord interactifs et dynamique permet aux clients
de mieux prendre des décisions afin de réduire le risque d’erreurs.

19. Les Besoins Non-fonctionnel

Il s'agit des besoins qui caractérisent le système. Ce sont des besoins en matière de
performance, de type de matériel ou le type de conception. Ces besoins peuvent concerner
les contraintes d'implémentation (langage de programmation, type SGBD, de système
d'Exploitation...).

 La fiabilité.
 La facilité d'utilisation (utilisabilité).
 Le rendement et l'efficacité.
 La maintenabilité.
 La portabilité.

II. Conclusion
Ce chapitre est une étape très importante dans laquelle nous avons cité les principales
méthodes de recueil d’information. Puis nous avons élaboré une justification métier de la
méthode adoptée dans notre processus de spécification de besoins.
Nous allons passer à l’étape de conception de l’entrepôt de données qui fera l’objet du
chapitre suivant.

22
Chapitre 3 : Modélisation Conceptuelle

23
Chapitre 3 : Modélisation Conceptuelle

I. Introduction
La modélisation des données est l’élaboration des structures de données pour les données
qui seront enregistrées dans une BD. L’Objectif de la modélisation est de représenter la
réalité telle qu'elle est perçue par les utilisateurs.
Le processus de modélisation et la définition de son résultat sous forme d'un schéma
conceptuel est appelé conception de la base de données La qualité de la conception de la BD
est un facteur critique de réussite.

1. Méthodologie de travail
La méthode de Kimball débute par les besoins du client. Par la suite, la création de l’entrepôt
de données, tels que trois chemins sont empruntés en parallèles.
 La conception de l’architecture technique : on choisit l’architecture technique et les outils
matériels et logiciels nécessaires pour la mise en place de l’entrepôt de données.
 La modélisation dimensionnelle : on définit la modélisation dimensionnelle de l’entrepôt
et des magasins de données, et on définit les outils ETL.
 Conception des applications BI : développement des applications décisionnelles tels que
les rapports, les tableaux de bord… Ces trois chemins convergent en fin du projet au
moment du déploiement. Le processus complet est répété pour chaque nouveau magasin de
données demandé par les utilisateurs finaux tout en assurant l’évolution et la maintenabilité
du système.

2. Processus de modélisation d’un ED


La modélisation d’un entrepôt de données est constituée de différentes phases
 La figure ci-dessous illustre le processus de la modélisation :

Figure 10 : Processus de modélisation d’un entrepôt de


données

24
Chapitre 3 : Modélisation Conceptuelle

3. Méthodes de conception d’un ED

On distingue trois approches de conception d’un schéma multidimensionnel [Kimball 2001]

3.1. Méthode Ascendante (Botton-up)

Cette méthode propose un ensemble d’étapes pour la définition des faits, des dimensions et
des hiérarchies à partir du schéma de la source. Le fait représente les événements fréquents
dans le monde de l’entreprise. Les dimensions sont formées à partir d’une portion du
schéma source qui dépend de la relation représentant le fait. Les attributs de cette portion
sont extraits puis réorganisés et épurés pour former les hiérarchies.

3.2. Méthode descendante (Top-down)

La méthode descendante débute par l’identification du besoin utilisateur. La première étape


consiste à collecter des données pour identifier les sujets d’intérêt. Par la suite, elle combine
ces besoins avec les différents axes d’analyse dans une matrice. L’inconvénient de cette
méthode est qu’elle n’est pas formelle d’où l’absence d’un outil de transformation des
besoins dans la matrice proposée.

3.4. Méthode mixte

La méthode mixte est la combinaison des deux méthodes : ascendante et descendante. Elle
intègre à la fois les données des sources et les besoins des décideurs dans la définition du
modèle dimensionnel. En effet, elle résout les problèmes rencontrés dans les méthodes
précédentes pour répondre aux différents besoins utilisateurs en respectant les données
sources.

25
Chapitre 3 : Modélisation Conceptuelle

II. Schéma Source de la base de données

Figure 11 : Diagramme de classe du schéma source

26
Chapitre 3 : Modélisation Conceptuelle

4. Méthode Ascendante

4.1. Analyse schéma source


Une source de données peut être l'endroit où les données ont été créés ou les informations
physiques ont été numérisées. Cependant, même les données les plus élaborées peuvent être
considérées comme des sources, tant qu'un autre processus y accède et les utilisent.
Concrètement, une source de données peut être une base de données ou même des fichiers
plats Au niveau de notre travail nous avons un diagramme de classe définissant le schéma
source de la société qui contient plusieurs tables qui ont des relations (1…*), on peut voir
tous les modules qu’on a besoin d’analyser comme le recouvrement qui représente le suivie
de règlement, le suivie de facture, le suivie flux payant.

Détermination des faits


 Analyse du schéma de la source globale

Détection des classes représentatives de l’analyse


Une classe représentative (CR) décrit un événement qui se produit à un instant donné ; elle
contient les mesures d’analyse.
 Choix des mesures d’activités à analyser :

CR1 (Suivie Facture)


MntPEC = {SUM}

MntPECCLI = {SUM}

MntPECHO = {SUM}

CR2 (Suivie Règlement)


Montant fac= {SUM, AVG}}

CR3 (Suivie flux Payant)


MntPay {SUM, AVG}}

27
Chapitre 3 : Modélisation Conceptuelle

Fait Dimensions Mesures

Suivie Facture DimClient, DimPEC,  Montant facture


DimEtat, DimSocieté, (MntPEC)
DimTemps, Dimcaisse,  Montant clinique
DimBordeau_Envoi, (MntPECCLI)
DimFacture  Montant honoraire
(MntPECHO)

Suivie Règlement DimClient, DimPEC, Montant règlement


DimSocieté, DimTemps, (Montant fac)
Dimcaisse, DimRégler,
DimBordeau_Envoi

Suivie flux Payant , DimClient,


 Flux payant (MntPay)
DimBordeau_Envoi,
DimSocieté, Dimcaisse,
DimObservation,
DimTemps, DimEtat

 Le graphe suivant représente les liens de dépendance fonctionnelle entre les classes
représentatives et les autres classes de la source de données

Figure 12 : Lien de dépendance entres les classes

28
Chapitre 3 : Modélisation Conceptuelle

Détermination des dimensions


Pour une meilleure gestion des données, une étude détaillée des sources de données s’est
avérée impérative et inévitable pour finalement décider les données appropriées qui seront
extraites pour construire les dimensions, les différentes dimensions choisis sont présentées
ci-dessous :

 D-PEC {id = PEC.CodPEC, désignation = PEC.DESPEC, Clinique}


 D-Client {id=Client.NumDoss, désignation = Client.NumCIN, clinique, Client.NumSoc}
 D-Facture {id=Facture.NumFaC, désignation = Facture.TypeFac, Clinique, Facture.NumDoss
 D-Société {id = Société.NumSoc, désignation = Société.DesSoc, Clinique, Société.cod_catég}
 D-Catégorie-Société{id=Catégorie-Société.cod_catég,désignation=Catégorie-
Société.DesCatég}
 D-Etat {id = Etat.CodEtat, désignation = Etat. Desetat, clinique}
 D-Régler {id = Régler.Numreg, désignation = Régler.NumDoss, clinique}
 D-Caisse {id = Caisse.Numcaisse, clinique}
 D-Bordeau_Envoi {id = Bordeau_Envoi.NumBordeau, clinique}
 D-Observation{id=Observation.Numdoss,désignation=Observation.Des_observation,
Observation.Nature, clinique}
 D-Responsable {id=Responsable.Codres, désignation=Responsable.Nomres, clinique}
 D-Temps {id = Id temps, date, jour, année mois, trimestre}

Figure 13 : Hiérarchisation des dimensions et définition de la granularité de l’analyse

29
Chapitre 3 : Modélisation Conceptuelle

 Le tableau ci-dessous représente les dimensions et leurs définissions

Nom de la dimension Description

DimClient Tous les personnes hospitalisées

DimPEC Les différents types de prise en charge

DimEtat Les différents types d’état

DimRegler Toutes les listes de règlement

DimCaisse Tous les listes de caisse

DimBordereau_Envoi Tous les listes de Bordereau envoyées

DimSocieteCategorieSoc Les différents organismes d'assurance ainsi, leurs catégories


(type de payeur)

DimObservation
Les différentes observations de chaque client

DimResponsable Toutes les listes des responsables

DimFacture
Toutes les listes de factures

DimTemps Contient toutes les dates

30
Chapitre 3 : Modélisation Conceptuelle

 La figure ci-dessous représente le schéma multidimensionnel en constellation


(démarche Ascendante)

Figure 14 : Démarche Ascendante

31
Chapitre 3 : Modélisation Conceptuelle

5. Méthode Descendante
Une conception descendante (Top/Down) est souvent assimilée à tort à de la conception en place.
Le principe de base de la conception descendante est de partir de la contrainte (environnement,
épure, lot de paramètres…) pour aller jusqu'à la définition des éléments les plus simples (les pièces).

5.1. Collecte des données :


R1 : Analyser ‘ Col N '
En fonction de Date, catégories sociétés, famille, par clinique, Années
R1 : Analyser ‘ Col N -1 ‘
En fonction de Date, catégories sociétés, famille, par clinique, Années
R3 : Analyser ‘ Evol ‘
En fonction de Date, catégories sociétés, famille, par clinique, Années
R3 : Analyser ‘ % Evol ‘
En fonction de Date, catégories sociétés, famille, par clinique, Années
R3 : Analyser ‘ Ecart ‘
En fonction de Date
R3 : Analyser ‘ % Ecart ‘
En fonction Date
R5 : Analyser ‘ Ratio ‘
En fonction de Date, clinique
R6 : Analyser ‘ Balance « Montant-règlement » ‘
En fonction de clinique
R7 : Analyser ‘ Recouvrement-Payant ‘
En fonction de clinique, famille
R8 : Analyser ‘ AVG ‘
En fonction de Date
R10 : Analyser ‘ performance ‘
En fonction de Date, clinique, Année
R11 : Analyser ‘ collection solde ‘
En fonction de clinique
R12: Analyser ‘ reste pay/ reste PEC ‘
En fonction de clinique.
R14 : Analyser ‘ Créance payant ’

32
Chapitre 3 : Modélisation Conceptuelle

En fonction de famille, observation client Année, clinique


R15 : Analyser ‘ Recouvrement ’
En fonction de catégories-société, Des Soc
R16 : Analyser ‘ Taux de recouvrement ‘
En fonction de catégories-société
R17 : Analyser ‘ PEC ‘
En fonction de catégories-société
R18 : Analyser ‘ Montant facturé clinique ‘
En fonction de famille, clinique, date, Année observation client
R19 : Analyser ‘ Solde clinique ‘
En fonction de famille, clinique, date, Année observation client
R20 : Analyser ‘ Montant facturé en honoraire ‘
En fonction de famille, clinique, date, Année, observation client
R21 : Analyser ‘ Solde en honoraire ‘
En Fonction de famille, clinique, date, Année, observation client

Légende

Col N : revenue par Année

Col N-1 : revenue de l’année précédente

Evol : différence entre l’année et l’année précédente

Ecart : Ecart Type

Ratio : quotient de deux valeurs

Balance : Facture - Règlement

PEC : prise en charge

AVG Y : moyenne de montant de cette année

33
Chapitre 3 : Modélisation Conceptuelle

Dim observati catégories Des Soc


Mesures famille clinique date on client -société

Col N

Col N -1

Evol / %Evol

Ecart/% Ecart
Ratio

Balance
Recouvrement
Payant

AVG

Recouvrement
Taux Recouvrement

performance
Collection solde

Reste Pay / PEC

PEC
Créance payant

Montant facturé clinique

Montant facturé
honoraire

Solde
honoraire/clinique

Tableau 2 : Spécification des besoins

34
Chapitre 3 : Modélisation Conceptuelle

5.1 Spécification des Besoins


Formulation des besoins

Définitions des faits

Fait Facture /

{MntPEC {SUM, AVG}}

{MntPECCLI {SUM, AVG}}

{MntPECHO {SUM, AVG}}

Fait Règlement /

{Montant fac {SUM, AVG}}

Fait flux payant /

{MntPay {SUM, AVG}}

Définition des dimensions


Regroupement

D-Observation {Observation.NumDoss [clé primaire]}

D-Société {Société.NumSoc [clé primaire]}

D-PEC {PEC.CodPEC [clé primaire]}

D-Etat {Etat.CodEtat [clé primaire]}

D-Régler {Régler.Numreg [clé primaire]}

D-Facture {Facture.NumFaC [clé primaire]}

D-Catégorie-société {Catégorie-Société.cod_catég [clé primaire]}

D-client {Client.NumDoss [clé primaire]}

35
Chapitre 3 : Modélisation Conceptuelle

 La figure ci-dessous représente le schéma multidimensionnel en constellation


(démarche descendante)

Figure 15 : démarche descendante

36
Chapitre 3 : Modélisation Conceptuelle

6. Méthode Mixte
La méthode mixte est « un modèle de recherche qui implique de combiner les éléments
d'une approche ascendante et descendante à des fins de compréhension et de corroboration,
ses atouts s'inscrivent d'abord, dans des différents designs, aussi dans des stratégies
poursuivies.

Après avoir définies chacune des deux démarches ascendantes et descendantes nous avons
décidé de supprimer les dimensions « Bordeau_Envoi », « caisse », « Responsable » et
« avance-organisme » parce qu'ils ne sont pas utilisés lors de l’analyse des sujets.

En se basant sur le schéma source de la base du clinique , nous avons dégagées trois types
de fait au bout de laquelle nous aurons défini les mesures nécessaires la première concerne
le suivie de facture dont le but et de calculer les montants suivants : {Montant PEC :
montant prise en charge (payant/organisme), MontantPECCLI : montant prise en charge
clinique, Montant PECHO : montant prise en charge honoraire} par les dimensions
suivants : Responsable, client, société, PEC, Etat, clinique la deuxième concerne le suivie
règlement ou le but et de calculer le montant du règlement par les dimensions suivants :
société ,régler, facture, clinique, temps concernant la troisième c’est le suivie payant que
nous intéressent ou on va analyser le montant payant contentieux par les dimensions
suivants : Responsable, client, facture, société, observation.

Finalement notre schéma contient 3 faits et 8 dimensions chacune a une relation (1…*) on
choisit donc le schéma en constellation.

37
Chapitre 3 : Modélisation Conceptuelle

 La figure ci-dessous représente le schéma multidimensionnel en constellation (démarche


mixte)

Figure 16 : démarche Mixte

38
Chapitre 3 : Modélisation Conceptuelle

Conclusion
Après avoir appliqué les différentes démarches de la modélisation conceptuelle de l’entrepôt il
ne reste qu’à le construire ; qui fera l’objet du chapitre suivant.

39
Chapitre 4 : Conception et développement
de processus de L’ETL et l’enchainement
d’un cube OLAP

40
Chapitre 4 : Construction

I. Introduction
Dans ce chapitre, nous définissons les différentes phases de la construction de l’entrepôt de
données en détaillant la phase d’intégration des données où nous présentons la conception
et le développement de l’ETL

1. Conception de l’ETL
Les processus ETL représentent le cœur du projet décisionnel. La conception de ce processus
permet d’avoir une vision claire de cette phase et d’éviter les erreurs d’implémentation.

Figure 17 : Processus ETL

 Avant de pouvoir commencer à organiser vos données, la première étape du processus


ETL de données consiste à extraire les données de toutes les sources pertinentes et à les
compiler. Cette exigence ETL et ce processus de collecte comprendront la préparation
nécessaire à la réalisation de l'intégration des données ensuite l’étape de transformation
des données elle implique l'exécution d'une série de fonctions et l'application
d'ensembles de règles aux données extraites pour les convertir dans un format standard
afin de répondre aux exigences de schéma de la base de données cible. Finalement la
troisième étape consiste à charger les ensembles de données qui ont été extraits et
transformés précédemment dans la base de données cible.

41
Chapitre 4 : Construction

2. Diagrammes d’activités
Le langage de modélisation unifié regroupe plusieurs sous-catégories de diagrammes,
notamment les diagrammes de structure, les diagrammes d'interaction et les diagrammes
comportementaux. Les diagrammes d’activités, ainsi que les diagrammes de cas d’utilisation et
d'états-transitions sont considérés comme des diagrammes comportementaux, car ils décrivent
ce qui doit arriver dans le système modélisé.

2.1 Diagramme d’activité de processus ETL


Nous avons opté pour le développement de cette partie à l’utilisation du diagramme
d’activités puisqu’il modélise un flux et décrit la logique d’une opération.

 La figure ci-dessous représente le diagramme d’activité globale pour l’ETL

Figure 18 : Diagramme d’activités globales pour le processus de l’ETL

Ce diagramme présente la phase d’intégration générale qui consiste à récupérer les données
à partir de la source et à les charger dans la base de la destination.

42
Chapitre 4 : Construction

Les figures ci-dessous nous montrent les diagrammes d’activités du flux de contrôle et d’un
exemple d’une dimension :

Description de la figure 19 : Ce diagramme d’activité


représente les différentes étapes au niveau du flux de
contrôle, nous commençons par la création des variables
pour la gestionnaire de connexion passant au boucle
foreach qui va générer les bases des données des cliniques
d’une manière successive.

Figure 19 : Diagramme d'activité flux de contrôle

Description de la figure 20 : Ce diagramme


d’activité représente l’extraction des données d’une
dimension en prenant l’exemple de la dimension
« client » qu’on va les extraire de la base source vers
l’ED cible, en effet la première étape consiste à
configurer la source ainsi les colonnes à extraire ensuite
on passe à ajouter la variable « clinique » au niveau de la
colonne dérivé puis au niveau la dimension a variation
lente nous définissons les clés d’entreprise et les types
des attributs «modification d’attribut ». Figure 20 : Diagramme d'activité flux de
données "Client"
 La figure ci-dessous nous montre le
Finalement les données seront chargées dans l’ED.
diagramme d’activités d’un fait

43
Chapitre 4 : Construction

Figure 21 : diagramme d’activités d’un fait

Description de la figure : Ce diagramme d’activité représente l’extraction des données d’une fait,
au niveau de la colonne dérivée nous avons utilisé la variable « clinique » puis la transformation
de recherche pour joignez les colonnes d’entrée aux colonnes de destinations, ensuite nous avons
fait des conditions pour nos mesures en utilisant le fractionnement conditionnel en effet s’il y a un
changement des données dans la source donc il y a une correspondance sinon le processus passe
directement au destination

44
Chapitre 4 : Construction

3. Développement de l’ETL
Les outils de développement exploités pour assurer la phase d’intégration des données sont
présentés ci-dessous :

3.1. Microsoft SQL Server 2019


Microsoft SQL Server, aussi appelé « SQL Server » ou parfois plus simplement
« MSSQL », est un système de gestion de base de données relationnelle développé par
Microsoft, c’est une plate-forme de données d’entreprise permettant de gérer et stocker dans
des bases de données tout type d’information :

 Données structurées : données relationnelles par exemple.

 Données non structurées : documents, images, …

 Données géospatiales.

3.2. Microsoft SQL Server Intégration Services (SSIS)

SQL Server Intégration Services est un composant du logiciel de base


de données Microsoft SQL Server qui peut être utilisé pour effectuer un
large éventail de tâches de migration de données.

3.3. Microsoft SQL Server Mangement studio 18 (SSMS)

Est l'un des outils de gestion de SQL Server, quel que soit votre emplacement, utilisé pour
concevoir des requêtes et gérer des bases de données et des entrepôts de
données via un ordinateur personnel ou le Cloud.

3.4. Microsoft Analysis Services


Offrant une analyse multidimensionnelle avec de puissantes capacités d'exploration de
données, SSAS implique la configuration efficace de schémas dans le développement de
Business Intelligence. Les fonctionnalités clés telles que le cube seront présentées dans la
section suivante, il fournit plusieurs approches, ou modes, pour créer des modèles
sémantiques d'informatique décisionnelle : tabulaires et multidimensionnels.

45
Chapitre 4 : Construction

3.5. Microsoft Visual Studio 2019


Visual Studio, également connu sous le nom de Microsoft Visual Studio et VS, est un
environnement de développement intégré pour Microsoft Windows. C'est un outil pour
écrire des programmes informatiques, des sites Web, des applications Web et des services
Web. Il comprend un éditeur de code, un débogueur, un outil de conception d’interface
graphique et un concepteur de schéma de base de données, et prend en charge
la plupart des principaux systèmes de contrôle de révision.

4. connexion au SQL SERVER


Une solution SQL Server Management Studio est un ensemble d'un ou plusieurs projets
associés, Un ou plusieurs projets connexes peuvent être combinés dans une solution. Les
solutions et les projets peuvent être gérés à l'aide du volet Explorateur de solutions dans
Management Studio.

C’est pour cela nous avons décidé de créer notre entrepôt au niveau SQL SERVER mais tout
d’abord nous devons connecter au serveur

 La figure ci-dessous montre la connexion au niveau SQL SERVER

Figure 22 : connexion au serveur SQL

Après la connexion nous avons créé un entrepôt de données sous le nom du « projet pfe » en
effet cette entrepôt contient plusieurs tables qui définissent les dimensions et les faits.

46
Chapitre 4 : Construction

 La figure ci-dessous montre notre serveur connecté et l’entrepôt de données qu’on a créé.

Figure 23 : l’entrepôt de données Local

47
Chapitre 4 : Construction

5. les composants de l’ETL

5.1 Flux de contrôle


Un flux de contrôle définit un workflow de tâches à exécuter, souvent un ordre particulier,
il en exécute certains qui eux-mêmes peuvent (ou non) agir sur les données quelque part, il
est constitué d’éléments de la boîte à outils, de tâches et de conteneurs, reliés par
des contraintes de précédence.

 La figure ci-dessous représente le package SSIS

Figure 24 : Flux de contrôle

 Le package SSIS Comportent un flux de contrôle qui définit un flux de taches à exécuter, il
effectue des opérations telle que le chargement des données, l’exécution des instructions
SQL, gérer la gestion d'erreur, vérifier une condition et appelle les différentes tâches (y
compris les flux de données), etc.

 À la suite de l’utilisation la commande SELECT dans l’outil du flux de contrôle « tache


d’exécution de requetés SQL », il génère une table contient des colonnes représentent les
bases de données des cliniques.

48
Chapitre 4 : Construction

La tâche d'exécution de requête SQL :


La tâche d'exécution de requête SQL exécute des instructions
SQL ou des procédures stockées à partir d'un package. La
tâche peut contenir une seule instruction SQL ou plusieurs
instructions SQL qui s'exécutent de manière séquentielle.

Notre source est une variable nommé « clinique », la propriété Valeur de la variable contient le
texte de la requête, nous définissons la propriété Valeur/Type de la variable en tant que type de
données String, puis nous tapons ou copions l’instruction SQL dans la propriété Value

 Lorsqu’ on exécute l’ETL une boite de message s’affiche en indiquant le début d’exécution
de la 1ère base de données de la clinique dans la table « Sourcelist ». Finalement Lorsqu'un
flux de contrôle est terminé, il a échoué ou réussi.
Ce message est affiché suite a la l’execution d’une commande SQL qui
permet d’acceder a la bes de données de la table « sourceList ».

Figure 25 : Boite de
message
Tache de script :
Le conteneur de boucles Foreach définit un flux de
contrôle répétitif dans un package, il répète le flux de
contrôle pour chaque membre d'un énumérateur spécifié.

 Au niveau de la boucle foreach, nous avons configuré l’enumérateur foreach, ainsi la


variable source « varSourceList » pour sélectionner toutes les lignes des tables

La boucle Foreach :
Le conteneur de boucles Foreach définit un flux de
contrôle répétitif dans un package, il répète le flux de
contrôle pour chaque membre d'un énumérateur spécifié.

49
Chapitre 4 : Construction

 La figure ci-dessous représente l’éditeur de boucle foreach

Figure 26 : Editeur de boucle foreach

 Au niveau de flux de données, nous avons configuré les étapes de l’ETL Pour les
dimensions et les faits

Tache de flux de données :


L'ajout d'une tâche de flux de données à un flux de
contrôle de package permet au package d'extraire, de
transformer et de charger des données.

5.2 Paramétrage du projet SSIS


Pour atteindre l’un des objectifs de notre projet qui est la standardisation de la solution, de
telle sorte qu’elle peut prendre en entrée toute base source opérationnelle de n’importe quel
établissement hospitalier tout en restant fermé, il faut utiliser des paramètres.

En effet, les paramètres permettent d’exposer à l’extérieur les parties variables de notre
solution.

Le paramétrage permet de donner des valeurs aux connexions lors de l’exécution du


package.

50
Chapitre 4 : Construction

Les connexions contiennent les informations nécessaires pour ce connecté à une source de
données. Dans le cadre de notre projet, nous avons utilisé principalement cinq paramètres
pour chaque connexion :

- Le serveur.

- Le nom de l’utilisateur de la base de données.

- Le mot de passe de l’utilisateur de la base de données.

- La base de données.

C’est pour ce but, on a opté de créer une base de connexions qui contient les différentes
connexions utilisées pour notre ETL

Figure 27 : Liste de la connexion

D’autre part, nous avons créé trois variables pour spécifier le nom de la base de données
source à parcourir ainsi que les chemins des bases de données à traiter et qui sont utilisées
par la suite comme paramètres pour la configuration de la boucle foreach.

Figure 28 : Liste des variables

5.3 Gestionnaire de connexion


Intégration Services utilise le gestionnaire de connexions comme représentation logique
d'une connexion. Au moment de la conception, vous définissez les propriétés d'un
gestionnaire de connexions pour décrire la connexion physique créée par Intégration
Services lors de l'exécution du package

51
Chapitre 4 : Construction

 La figure ci-dessous représente le gestionnaire de connexion au niveau SSIS

Figure 29 : Gestionnaire de connexion

Nous avons connecté au magasin de données source nommé « sql2019 » et de destination


« projet pfe » du SQL Server pour extraire et charger des données.

6. Flux de données
Le flux de données est le cœur de l’ETL SSIS. Il permet d’intégrer des données dans un
Data Warehouse, elle doit contenir au moins une source. Généralement elle contient aussi
une destination et plusieurs transformations reliées par des chemins d’accès au flux de
données qui véhiculent les lignes de données d’un composant à l’autre.

6.1 Extraction des données


Cette étape consiste à la collecte ou récupération de types disparates de données à partir de
différentes sources, dont certaines peuvent être non structurées ou mal structurées.
L'extraction des données permet de consolider, traiter et affiner les données, puis de les
stocker dans un emplacement centralisé avant de les transformer

 La figure ci-dessous représente le flux de donnes de la table client

Figure 30 : Flux de données

52
Chapitre 4 : Construction

 Un flux de données peut inclure une ou plusieurs sources, la source d'un flux de données
comporte généralement une sortie normale. La sortie normale contient des colonnes de
sortie, qui sont les colonnes ajoutées par la source au flux de données.
 La figure ci-dessus représente l’importation des données, en effet nous avons utilisé « la
source OLE DB » pour extraire les données de quelconque table et les chargées dans notre
entrepôt par l’outil « destination d’insertion ».

La Source OLE DB :
La source OLE DB extrait des données d'une série de bases
de données relationnelles compatibles OLE DB à l'aide
d'une table de BD d'une vue ou d'une commande SQL.

La destination OLE DB :
Charge des données dans différentes bases de données
compatibles OLE DB à l'aide d'une table ou d'une vue de
base de données ou d'une commande SQL.

 Au niveau ce chargement nous avons incluent d’autres outils « colonne dérivée » qui
contient la variable « clinique » et « la dimension à variation lente » qui définit le type des
données et détecte la variation des attributs dimensionnels dans le temps, tous les attributs
sont de type modifiable.

Dimension a variation lente :


Ce composant est utilisé si vous souhaitez insérer
ou mettre à jour des enregistrements de données
dans des tables de dimension, elle compare les
données source entrantes aux données de table de
dimension de destination.

La transformation Colonne dérivée :


Peut définir plusieurs colonnes dérivées, et toute
variable ou colonne d'entrée peut apparaître dans
plusieurs expressions.

53
Chapitre 4 : Construction

 Au niveau de cette tache une requête SQL est générée permet de mettre à jour les données si l’Ya
une modification dans les données

UPDATE [dbo].[Client] SET [CodSoc] = ?,[Nom] = ?,[Prénom] =


? WHERE [clinique] = ? AND [NumDoss] = ?

La commande OLE DB :
Vous permettez d’exécuter une instruction SQL qui insère,
met à jour ou supprime des lignes dans une table de base
de données.

6.2 Transformation et chargement des données


La transformation des données est le processus de conversion des données d'un format vers
un autre format plus utilisable par le système ou l'application cible. Il comprend de multiples
activités : vous pouvez « transformer » vos données en les filtrant en fonction de certaines
règles et en joignant différents champs pour obtenir une vue consolidée. Les outils de
transformation vous aident à atteindre facilement votre résultat final.

 La figure ci-dessous représente le fait règlement

Figure 31 : Flux de données du processus de chargement de fait règlement

54
Chapitre 4 : Construction

 La figure ci-dessous représente l’éditeur de source OLE BD

 Au niveau source des données nous


avons tapé une requête SQL
suivant nos besoins.
Nous avons utilisé la commande
SQL comme mode d’accès.

Figure 32 : Editeur de source OLE DB

 La requête ci-dessous représente le fait règlement

SELECT Régler.Numreg, régler. numdoss,Regler.numfac,Regler.datreg,


societe.numsoc,SUM(Regler.mntben) AS Mnt_reglement ,Regler.PEC
FROM Client
INNER JOIN societe ON Client.NumSoc = societe.NumSoc
INNER JOIN Regler ON Client.NumDoss = Regler.numdoss
GROUP BY regler.numreg, regler.numdoss,Regler.numfac, Regler.datreg, societe.numsoc,Regler.PEC
union all
SELECT Avance_organisme.Num_Avance as numreg, 'avance' as numdoss, 'avance' as numfac,
Avance_organisme.DatReg,Avance_organisme.NumSoc ,
ISNULL(SUM(Avance_organisme.mnt_Avance ),0)
AS Mnt_reglement,1 as Pec
FROM Avance_organisme
INNER JOIN Societe ON Avance_organisme.NumSoc = Societe.NumSoc
INNER JOIN Caisse ON Avance_organisme.Caisse = Caisse.NumCaisse
GROUP BY Avance_organisme.Num_Avance, Avance_organisme.DatReg,Avance_organisme.NumSoc

55
Chapitre 4 : Construction

 Au niveau du fractionnement conditionnel, nous avons traité un sorite de commandes SQL


qui définit les mesures sources et les mesures de la destination en effet si une des conditions
se modifie au niveau la source elle sera modifiée au niveau notre l’entrepôt de données.
 La figure ci-dessous représente l’éditeur de fractionnement Conditionnelle

Figure 33 : Editeur de transformation de fractionnement conditionnel fait règlement

La transformation de fractionnement conditionnel peut


acheminer des lignes de données vers différentes sorties
en fonction du contenu des données.

 La requête ci-dessous montre la mise à jour au niveau de fractionnement conditionnelle

update [Reglement Fact] set Montant_fac = ?

where NumFac = ? and NumDoss = ? and Datereg = ? and CodSoc =


? and PEC = ? and Numreg = ? and Cod_clinique = ?

56
Chapitre 4 : Construction

Nous avons utilisé la transformation Recherche au niveau des trois faits pour effectuer des
recherches en joignant les données des colonnes d’entrées aux colonnes de l’entrepôt de
données référée, en effet nous avons fait une recherche sur le montant facturé à partir des
colonnes d’entrée aux colonnes de sorties

 La figure ci ’dessous représente l’éditeur des transformations de recherche qui sert

Figure 34 : Editeur de transformation de Recherche

La transformation Recherche effectue des recherches


en joignant les données des colonnes d'entrée aux
colonnes d'un ensemble de données de référence.

57
Chapitre 4 : Construction

7. Création du cube OLAP


Le traitement analytique en ligne (OLAP, On-Line Analytical Processing) est une manière
d'organiser des données pour ajuster la façon de les analyser et de les gérer, afin que la
création de vos rapports nécessite moins de temps et d'effort. Lorsque vous créez un cube
OLAP à partir d'une requête, vous transformez le jeu d'enregistrements à deux dimensions
en hiérarchie structurée, ou cube, permettant à des rapports d'afficher le niveau de détails
souhaité. Vous définissez également les valeurs de synthèse pour les rapports, ce qui accélère
le calcul d'un rapport.

7.1 Définition
Un cube est une structure multidimensionnelle qui contient des informations à des fins
analytiques ; les constituants principaux d'un cube sont des dimensions et des mesures. Les
dimensions définissent la structure du cube que vous utilisez pour la découpe, et les mesures
fournissent des valeurs numériques agrégées qui intéressent l'utilisateur final.

7.2 Vue de source de données


Cette étape nous permet de créer une vue de source de données des tables dans notre entrepôt
de données comme nous montre la figure ci-dessous

Figure 35 : Création de la vue de source de données

58
Chapitre 4 : Construction

7.3 Création des dimensions


Toutes les dimensions Microsoft SQL Server SQL Server Analysis Services sont des
groupes d'attributs basés sur des colonnes de tables ou de vues dans une vue de source de
données. Les dimensions existent indépendamment d'un cube, peuvent être utilisées dans
plusieurs cubes, peuvent être utilisées plusieurs fois dans un même cube et peuvent être liées
entre des instances SQL Server Analysis Services. Une dimension qui existe
indépendamment d'un cube est appelée une dimension de base de données et une instance
d'une dimension de BD dans un cube est appelée une dimension de cube.

Figure 36 : Création de dimension Client

Chaque dimension nécessite une hiérarchie qui permet de naviguer et d’agréger à différents
niveaux.

Figure 37 : Hiérarchies de la dimension Client

59
Chapitre 4 : Construction

7.4 Création du Cube


Nous sommes maintenant prêts à définir notre cube d’analyse multidimensionnelle. Le
processus est simple, il suffit donc de sélectionner les tables de faits, les mesures et les
dimensions.

Figure 38 : Table de groupes de mesures

7.5 Déploiement et traitement


Après avoir terminé la création du cube, nous allons le déployer sur une instance d’Analysis
Services. Le déploiement du projet créé des objets d’Analysis services copie les données des
sources de données dans les objets de cube.

Figure 39 : Déploiement réussi

60
Chapitre 4 : Construction

 La figure ci-dessous montre l’instance de SSAS ainsi l’architecture du cube

Figure 40 : Structure du cube dans Microsoft Analysis Server

I. Conclusion
A travers ce chapitre nous avons définis la modélisation logique adoptée pour notre entrepôt,
celle d’après la modélisation physique pour aboutir à la construction réelle de l’entrepôt dont
nous avons définis la conception de l’ETL ensuit son développement. A ce stade-là, il ne reste
qu’à implémenter l’application d’interrogation de l’entrepôt de données.

61
Chapitre 5 : Restitution

62
Chapitre 5: Restitution

I. Introduction
La visualisation des données est la représentation des données à l'aide de graphiques
courants, tels que des graphiques, des tracés, des infographies et même des animations. Ces
affichages visuels d'informations communiquent des relations de données complexes et des
informations basées sur les données d'une manière facile à comprendre.

La visualisation des données peut être utilisée à diverses fins, et il est important de noter
qu'elle n'est pas uniquement réservée aux équipes de données. La direction s'en sert
également pour transmettre la structure et la hiérarchie organisationnelles, tandis que les
analystes de données et les spécialistes des données l'utilisent pour découvrir et expliquer
les modèles et les tendances.

Nous avons décidé de créer des rapports interactifs et des chartes graphiques à l’aide de
l’outil Microsoft Power BI avec des requêtes DAX qui prennent notre projet SSIS comme
source de données, et on utilisant le Microsoft EXCEL et qui prennent notre CUBE
multidimensionnelle comme source des données.

1. Définition

1.1 Microsoft Power BI


Power BI est le nom commun attribué à une variété d’applications et de services basés sur
le Cloud. Ces derniers sont conçus pour aider les entreprises à collecter, gérer et analyser
diverses sources de données via une interface facile à utiliser. Il permet de rassembler les
données et de les traiter. Mais surtout, il est utile pour transformer les données en
informations intelligibles souvent à l’aide de graphiques et de tableaux visuellement précis
et faciles à traiter. Cela permet aux utilisateurs de créer des rapports interactifs et de les
partager à toutes les parties prenantes d’une entreprise.

1.2 Fonction DAX


Qu'est que le langage DAX ? DAX est un ensemble de fonctions, d'opérateurs et de
constantes qui peuvent être utilisés dans une formule, ou expression, afin de calculer et
retourner une ou plusieurs valeurs

63
Chapitre 5: Restitution

2. Connexion et Chargement Power BI


Nous avons utilisé Power BI Desktop pour interroger et charger des données à partir de
sources de données externes et créer des rapports.

 La figure 5.2 ci-dessous montre la connexion au serveur SQL à travers Power BI

Figure 41 : Connexion au serveur

 La figure 5.3 ci-dessous montre les tables de faits et les dimensions a chargé

Figure 42 : Tables a chargées

64
Chapitre 5: Restitution

3. Modelé
La vue Modèle affiche toutes les tables, colonnes et relations de votre modèle. Cette vue
peut être particulièrement utile lorsque votre modèle comporte des relations complexes
entre de nombreuses tables.

 La figure 5.4 ci-dessous montre le modèle avec des relations (1….*).

Figure 43 : Modèle power BI

65
Chapitre 5: Restitution

4. Diagramme de cas d’utilisation

Figure 44 : Diagramme de cas d'utilisation

66
Chapitre 5: Restitution

Titre
Gestion des rapports

Acteur
Chef services

Objectif
Permettre au Chef services de consulter quelques données au niveau
de la visualisation (il n’a pas tout droit à accéder à tous les tableaux
de bord)
Précondition

Le chef service lance l’application et s’authentifie.

Post-condition
Le chef service voir les tableaux de bord qui sont destiné à lui.

Scenario nominal

1. Le chef service accède à l’application.


2. Le système affiche une interface permettant au chef d’ouvrir les
tableaux de bord
3. Le système affiche les tableaux.
4. Le chef service consulte les visualisations
5. Le système affiche les données correspondantes.
6. Le chef service applique les différentes opérations sur les données
afin de les détailler

Scenario alternatif
Le système affiche « Impossible d’ouvrir le visuel »

 Le tableau ci-dessous représente une description textuelle pour le chef service

67

Tableau 3 : Description textuelle pour le chef service


Chapitre 5: Restitution

68
Chapitre 5: Restitution

 Le tableau ci-dessous représente une description textuelle pour le PDG

Titre
Consultation des tableaux de bord.

Acteur
PDG de la clinique

Objectif
Permettre au PDG de la clinique de consulter le tableau de bord.

Précondition
Le PDG lance l’application et s’authentifie.

Post-condition
Le PDG explore les données.
Scenario nominal
- Le PDG accède à l’application.

- Le système affiche une interface permettant au PDG de choisir quel tableau de


bord à consulter.

- Le PDG choisit le tableau de bord.

- Le système affiche le tableau de bord préférer.

Scenario alternatif

1. Modification du format de la représentation graphique. :


1. Le PDG sélectionne le graphique.
2. Le système affiche la liste de l’autre présentation situable avec ce type de
données
3. Le PDG valide la génération de ce nouveau format d’affichage.
4. Le système traite la commande.

Tableau 4 : Description textuelle pour le PDG de la clinique

69
Chapitre 5: Restitution

5. Tableaux de bord

5.1 Power BI

5.1.1 Menu
Ce visuel donne une vision générale sur les mesures qu’on va analyser pour le groupe de
sante « AMEN SANTE » au niveau de ces six cliniques a Tunisie regroupé dans Cinq ville
« Beja, Bizerte, Marsa, Mutuelle-Ville, Nabeul »

L’utilisateur peut avoir une idée sure :

 Le Montant PEC (Prise en charge) du recouvrement organisme.

 Le Montant PEC du recouvrement Payant.

 Le Montant de la facture Payant.

 Le Balance organisme.

 Le Flux payant contentieux, par organisme et passagers .

 La figure 45 représente le Menu

Figure 45 : Menu

70
Chapitre 5: Restitution

Ce rapport présente le la facture payant par clinique, société, état et PEC


A travers ce rapport, le décideur peut avoir une vision globale sur :
 Le montant de chaque société pour l’année actuelle et l’année précédente, la
différence entre les deux années, l’écart type, la variance, la médiane et le Ratio sous
forme « d’une Matrice ».
 Le Montant PEC honoraire et le montant PEC en clinique pour chaque clinique
durant une période.
 La Collection annuelle trimestrielle et mensuel global des cliniques dans une période,
en utilisant le visuel « carte ».
 Le montant PEC par année dans les 10 dernières années, en
appliquant un filtre sur la date pour spécifier la période.
 Le montant PEC Par société des cinq tops premiers société en
appliquant un filtre, on a choisi d’utiliser le visuel « Graphique en
anneau ».

Figure 46 : Filtre sur société


 La figure 47 représente le rapport de facture payant

Figure 47 : Rapport de facture payant

71
Chapitre 5: Restitution

Ce rapport présente le montant du règlement par organisme, payant, par clinique,


société et PEC
A travers ce rapport, le décideur peut avoir une vision globale sur :
 La Collection annuelle trimestrielle et mensuel global des cliniques dans une période,
en utilisant le visuel « carte ».
 Le montant pour l’année actuelle et l’année précédente, la différence entre les deux
années, l’écart type, la variance, la médiane et le Ratio par clinique sous forme
« d’une Matrice ».
 Le montant du règlement pour les six tops société (CNAM CARDIO au meilleur
chiffre elle représente 39,81% des autres sociétés) en utilisant « Graphique en
anneau »
 Le montant PEC par année dans les 18 dernières années, en appliquant un filtre sur la
date pour spécifier la période. en utilisant « l’histogramme empilé »
 Le montant du règlement par PEC (prise en charge : payant & organisme)

 La figure 48 représente le rapport de recouvrement contentieux et organismes

Figure 48 : Rapport de Règlement par organisme et payant

72
Chapitre 5: Restitution

Ce rapport présente le montant du règlement contentieux et organisme par clinique,


état, client et PEC
A travers ce rapport, le décideur peut avoir une vision globale sur :
 Le flux payant par société durant six ans (de 2016 à 2021)
 Le flux payant par société, on a appliqué un filtre pour déterminer les six premières
sociétés qui ont le meilleur chiffre (CNAM KSAR HELAL a le montant le plus
élevé) en utilisant le visuel « Treemap »
 Le montant payant par Société et Etat (l’état peut être contentieux ou non
réceptionné.

 La figure 49 représente le rapport Règlement contentieux et organisme

Figure 49 : Rapport de Règlement contentieux et organisme

73
Chapitre 5: Restitution

 La figure 5.4 représente le rapport Règlement contentieux Passagers

Figure 50 : Rapport de Règlement contentieux et passagers

Ce rapport présente le montant Balance organisme et payant par clinique, état, client
et PEC
A travers ce rapport, le décideur peut avoir une vision globale sur :
 La balance par clinique (Marsa a le nombre de balance le plus élevé)
En utilisant le visuel « Treemap ».
 La balance par année durant 7 ans (de 2015 à 2021) en utilisant le visuel « Graphique
a barre empilé ».
 La balance de chaque société dans la période de 7 ans en utilisant le visuel «
Matrice».

Calcul du Balance avec DAX


Montant Facture – Montant Règlement

74
Chapitre 5: Restitution

 La figure 5.4 représente le rapport Balance et organisme payant

Figure 51 : Rapport de Balance et organisme payant

6. Fonction DAX

6.1 Création de la table Dates


Cet article vous cible en tant que modélisateur de données travaillant avec Power BI
Desktop. Il décrit les bonnes pratiques de conception pour la création de tables de dates dans
vos modèles de données, pour utiliser les fonctions d'intelligence temporelle DAX (Data
Analysis Expressions)

Figure 52 : COD DAX pour la table DATES

75
Chapitre 5: Restitution

6.2 Les fonctions

 Le Tableau montre les fonctions de DAX Suivantes

Fonction
Description

Renvoie une table avec une seule colonne nommée "Date" qui
contient un ensemble contigu de dates
CALENDARAUTO

Additionne tous les nombres d'une colonne.


SUM/SUMX

Évalue la valeur cumulée de l'année de l’expression dans le


contexte actuel.
TOTALYTD

Renvoie une table qui contient une colonne de dates, décalées en


avant ou en arrière dans le temps du nombre d'intervalles spécifié
DATEADD
à partir des dates dans le contexte actuel.

Calcule la moyenne (moyenne arithmétique) d'un ensemble


d'expressions évaluées sur une table.
AVERAGEX

Modifie la manière dont les filtres sont appliqués lors de


l'évaluation d'une fonction CALCULATE ou
KEEPFILTERS
CALCULATETABLE

Effectue une division et renvoie un résultat alternatif ou BLANK


() lors de la division par 0.
DIVIDE

Évalue une expression dans un contexte de filtre modifié.


CALCULATE

Renvoie la plus grande valeur dans une colonne ou entre deux


expressions scalaires.
MAX

Tableau 5 : Fonction DAX

76
Chapitre 5: Restitution

7. Visualisation Excel

7.1 Microsoft Excel


Microsoft Excel est un logiciel produit par Microsoft qui permet aux utilisateurs d'organiser,
de formater et de calculer des données à l'aide de formules à l'aide d'un tableur. Ce logiciel
fait partie de la suite Microsoft Office et est compatible avec d'autres applications de la suite
Office.

Ce rapport donne une vision globale sur le Montant de facture dans les cliniques, en effet à
travers ce tableau de bord le décideur peut faire ses analyses en connaissant :

 Le montant PEC (Prise en charge) facturé honoraire et par clinique en utilisant le graphe
« Histogramme Groupé ».

 Le montant facturé pour chaque société, on a montré seulement les tops six sociétés qui ont
le montant le plus élevé en utilisant le « secteur ».

 Le montant facturé pour chaque année durant les 11 dernières années (depuis 2010 à 2021)
en utilisant la « courbe ».

 Le Montant facturé par Années, Trimestre, mois et par clinique pendant les 4 dernières
années en utilisant le « Tableau croisé ».

 La figure ci-dessous représente la facture payant

Figure 53 : facture Payant (Excel)

77
Chapitre 5: Restitution

Ce rapport donne une vision globale sur Le montant par clinique, société et par PEC, en effet
à travers ce tableau de bord le décideur peut faire ses analyses en connaissant :

 Le montant règlement par année, trimestre, mois et clinique pendant les 3 derniers ans en
utilisant le « tableau croisé ».

 Le montant règlement pour chaque société en utilisant le « secteur ».

 Le montant règlement par clinique en utilisant « l’histogramme groupé ».

 Le montant règlement par année pendant les 12 dernières années depuis (2005 à 2021) en
utilisant « la courbe ».

 Le montant règlement par PEC (par organisme & par payant) en utilisant « l’histogramme
groupé ».
 La figure ci-dessous montre le règlement par organisme et payant

Figure 54 : facture règlement par organisme et par payant (Excel)

78
Chapitre 5: Restitution

Ce rapport donne une vision globale sur flux payant contentieux par clinique, société et par
PEC, en effet à travers ce tableau de bord le décideur peut faire ses analyses en connaissant :

 Le flux payant par clinique.

 Le flux payant pour chaque société.

 Le flux payant par années durant chaque 2 année depuis (1998 à 2020).

 Le flux payant organisme par années et clinique.

 Le flux payant passagers par années, clinique et par observation.

 La figure ci-dessous montre le flux payant contentieux

Figure 55 : Flux Payant contentieux (Excel)

II. Conclusion
Dans ce chapitre nous avons présenté la modélisation de l’application BI ainsi que son
développement à travers l’enchainement des différentes interfaces d’analyses décisionnelles.

79
CONCLUSION GENERALE

L’environnement concurrentiel dans lequel évolue notre société aujourd’hui, exige une
surveillance très étroite du marché afin de ne pas se laisser distancer par les concurrents et cela
en répondant, le plus rapidement possible, aux attentes du marché, de leur clientèle et de leurs
partenaires. Dans ce contexte, le suivi des mesures n’est pas une question de gain ou de perte,
c’est une question de survie. En réponse à ces besoins, les systèmes décisionnels sont définis
afin d’offrir aux décideurs une assistance dans leur processus d’aide à la décision.

Dans ce cadre, la société « CliniSys » aborde un projet consistant en la conception et la


réalisation d’un entrepôt de données comportant son application d’interrogation. Ce travail
s’inscrit dans le cadre de notre projet de fin d’étude en vue de l’obtention du diplôme de licence
en science informatique spécialité Big data et analyse des données

Tout au long de notre travail de conception et de réalisation, nous avons suivi une
démarche mixte, alliant de ce fait entre deux approches connues dans le domaine de
l’entreposage de données, à savoir l’approche descendante (guider par le besoin d’analyse) et
l’approche ascendante (guidé par la source de données). Cette démarche a permis de répondre
aux attentes et besoins des utilisateurs tout en exploitant au mieux les données générées par le
système opérationnel de manière à anticiper sur des besoins non exprimés. Dans un deuxième
temps, la modélisation de la zone de stockage des données s’est faite grâce aux principes de la
modélisation multidimensionnelle en adoptant un schéma en étoile.

La partie ETL, a été la partie du projet la plus fastidieuse et consommatrice en temps. Cette
étape nous a permis de concevoir et de réaliser les routines d’extraction, transformation et
chargement des données sous l’outil SSIS de SQL Server.

Tirant avantages du modèle multidimensionnel et du moteur OLAP, l’application ainsi obtenu


permet un Reporting flexible, rapide et intuitif. Elle vise une meilleur aide à la décision au sien
de l’entreprise.

Étant basé sur un entrepôt de données, notre système d’aide à la décision est ouvert aux futures
évolutions :

- Extension de l’entrepôt par la prise en compte des autres sources de données.

- Intégration d’un module de « Datamining » afin d’identifier des opportunités commerciales

80
Bibliographie

[En ligne]. Available: https://www.data-transitionnumerique.com/informatique-decisionnelle-


definition/.

[En ligne]. Available: http://clinisys-his.com/Pages/.

[En ligne]. Available: https://www.commentcamarche.net/contents/307-informatique-


decisionnelle-business-intelligence.

[En ligne]. Available: https://miashs-www.u-ga.fr/prevert/SpecialiteIHS/GP/coursED.pdf.

[En ligne]. Available: https://www.astera.com/fr/type/blog/data-warehouse-concepts/.

[En ligne]. Available: https://www.lebigdata.fr/datamart-definition.

[En ligne]. Available: https://eric.univ-lyon2.fr/publications/files/memoire-midouni-2005.pdf

[En ligne]. Available: https://www.talend.com/fr/resources/guide-etl/.

[En ligne]. Available: https://docs.microsoft.com/en-us/system-center/scsm/olap-cubes-


overview?view=sc-sm-2019.

[En ligne]. Available: https://www.usinenouvelle.com/expo/guides-d-achat/tableau-de-bord-et-


reporting-223.

[En ligne]. Available: https://waytolearnx.com/2018/09/difference-entre-oltp-et-olap.html.

[En ligne]. Available: https://agiliste.fr/introduction-methodes-agiles/.

[En ligne]. Available: https://agiliste.fr/introduction-methodes-


agiles/?nab=0&utm_referrer=https%3A%2F%2Fwww.google.com%2F.

[En ligne]. Available: https://www.microsoft.com/en-us/sql-server/sql-server-2019.

[En ligne]. Available: https://docs.microsoft.com/en-us/visualstudio/windows/?view=vs-


2019&preserve-view=true.

[En ligne]. Available: https://docs.microsoft.com/en-us/sql/ssdt/sql-server-data-


tools?view=sql-server-ver15.

81

Vous aimerez peut-être aussi