Vous êtes sur la page 1sur 90

UNIVERSITE FELIX HOUPHOUET BOIGNY

UFR de Mathématiques et Informatique


Laboratoire de Mathématiques Appliquées et Informatique

Année académique

No························
2013-2014

MEMOIRE DE MASTER
Présenté à

l'UNIVERSITÉ FELIX HOUPHOUËT BOIGNY

Mention: Informatique

Spécialité: Base de Données et Génie Logiciel


par
ASSIE BROU IDA

TITRE DU MEMOIRE:

ETUDE D'UNE PLATEFORME


DECISIONNELLE POUR LA GESTION
DES INFORMATIONS MEDICALES:
1 Cas des consultations médicales

Soutenu publiquement le jeudi 18 Décembre 2014

Le jury

~ Président : Pr. ADOU KABLAN JEROME Professeur Titulaire UFRMI, UFHB Abidjan
I
, Directeur : Dr. SEKA LOUIS PAUL Assistant UFRMl, UFHB Abidjan

'
Thème: Etude d'une plateforme décisionnelle
pour la gestion des informations médicales :
Cas des consultations médicales
Sommaire
Remerciements........................................................................................ v

Dédicace. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vi

Abréviations.......................................................................................... vii

Liste des tableaux.................................................................................... v11


Listes des figures.................................................................................... ix

lntroduction générale. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1- Contexte de l'étude........................................................................ 2
2- Problématique.............................................................................. 3
3- Présentation du thème..................................................................... 3
4- Objectif du mémoire....................................................................... 5

Partie 1 : Aspects théoriques de la Business Intelligence................................... 7

Chapitre 1: Approche générale de la Business Intelligence.................................... 8


A- Présentation de la Business Intelligence.............................................. 9
l- Historique. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2- ETL (Extract-Transform-Load).................................................... 11
3- Entrepôts de données ou Data_Warebouse..... .. .. .. . 12
4- Architecture d'un système décisionnel............................................ 12
5- Data mining.. .. .. . .. .. . 14

8- Informatique décisionnel vs lnformatique de production.......................... 15


1- lnformatique de production........................................................ 15
2- informatique décisionnel........................................................... 16

Chapitre 2 : Data Warehouse...................................................................... 18

1- Approche définitionnelle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2- Historique des data warehouse.... .. .. .. .. .. . .. .. .. .. 19
3- Structure des données d'un data warehouse...... .. .. . 20
4- Modélisation d'un data warebouse. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.1. Schéma relationnel... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.1.1. Schéma en étoile....................................................... 22
4.1.2. Schéma en flocon de neige (Snowflake)............ .. 22
4.1.3. Schéma en constellation.............................................. 23
4.2. Schéma multidimensionnel (Cube)......................................... 24

5- Serveurs O LAP.............................. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.1. ROLAP (Relational OLAP)................................................. 26
5.2. MOLAP (Multidimensional OLAP)....................................... 27
5.3. HOLAP (Hybrid OLAP)........................... 27

6- Démarche de construction d'un data warehouse...... .. . .. .. 28


6.1. Modélisation et conception du data warehouse.... .. .. .. .. 28

ii
6.2. Alimentation du data warehouse. .. .. . . . . .. .. . . .. . 30
6.3. Mise en œuvre du data warehouse. 30
6.4. Maintenance et expansion............................................................ 32

Partie Il: Etat de l'art de Système Décisionnel existant dans le domaine médical... 34

l- Différences entre les deux approches.......................................... 35


2- Les éditeurs des différentes solutions.......................................... 36
2.1. Solutions blanches........................................................... 36
2.2. Solutions pré-packagées.................................................. .. 38

3- Choix et justification........ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Partie Ill: Modélisation- Réalisation - Exploration du système........................... 44

Chapitre 1 : Modélisation du Système........................................................... 45

1- Techniques de modélisation..................................................... 45
l.l. Méthode MERISE........................................................... 47
l.2. Langage UML............................................................... 47

2- Modèle Conceptuel des données du système................................. 48


2.l. Activité « Consultation médicale»........................................ 49
2.2. Dimensions participantes du modèle...................................... 50
2.2.1. Dimension« Time 1 ».. .. . . . . .. . . . . . .. . . .. .. . .. .. .. 50
2.2.2. Dimension «DWDIMPROFESSION». .. .. . .. .. .. .. 51
2.2.3. Dimension «DWDIMSEXE»............... 52
2.2.4. Dimension «DWDlMMALADIE»............................. 52
2.2.5. Dimension «DWDIMHABIT ATION»........................ 53

2.3. Mesures........................................................................ 54
2.4. Schéma en étoile de la consultation médicale............................. 54

Chapitre 2: Réalisation et alimentation de l'entrepôt de données.......................... 55

1- Etude et planification.............................................................. 56
1.1. Sources de données et emplacement.............................. 56
1.2. Périodicité du chargement.......................................... 56

2- Conception des processus de chargement...................................... 57


2.1. Chargement des tables de la zone de transit . .. . . . . . . . . . . . . ..... 58
2.2.Chargement des tables de l'entrepôt de données................. 58
2.3.Chargement de la table des faits.................................... 60

Chapitre 3 : Exploration des données du système............................................ 62

1- Conception du cube muldimensionnel......... . . . . . . . . . . . . . . . . . . . . . . . . . . . 62


2- Exploration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

iii
Conclusion générale............................................................................... 70
Annexes............................................................................................. 73
Bibliographie....................................................................................... 78

iv
Remerciements
Au moment où prend forme ce mémoire, nos remerciements et reconnaissances vont à :

DIEU, l'auteur de toute vie, inspirateur et réalisateur de tout projet.


Tous nos professeurs et encadreurs du département de Mathématiques et lnformatique,
pour l'enseignement que vous nous avez dispensé avec abnégation et pour les conseils
que vous ne cessez de nous prodiguer.
Docteur SEKA Louis Paul, notre encadreur, nous rendons un sincère hommage, car il
a veillé avec rigueur à la réalisation de ce travail, pour ses remarques pertinentes, mais
aussi pour son écoute et ses conseils bienveillants.
Nos familles, qui ont sus nous supporter et encourager tout au long de notre vie, ainsi
que pour leur aide inestimable, leur patience et leur soutien indéfectible. En
particulier, à Docteur ASSIE Abou Marthe, pour le modèle de travail qu'elle a été
pour nous.
Messieurs les membres du jury d'avoir accepté d'évaluer ce travail.
Tous ceux qui nous sont chers, qui de près ou de loin nous ont apporté leur soutien.
Merci.

V
Dédicace

A mes parents, pour leur soutien indéniable et leur aide précieuse.


« Powrais-jejamais vous dire tout mon amour».

vi
Abréviations

Bl: Business Intelligence

DW: Data Warehouse

DlPE: Direction de l'Information, de la Planification et de l'Evaluation

ED: Entrepôt de Données

ETL: Extract Transform Loading

ERP : Enterprise Ressources Planning

GMSIH : Groupement pour la Modernisation du Système d'lnformation Hospitalier

HOLAP : Hybrid OLAP

Sl: Système d'lnformation

SIAD: Système d'lnformation d'Aide à la Décision

SIH: Système d'lnformation Hospitalier

SGBD: Système de Gestion de Base de Données

OLTP: On-Line Transactional Processing

OLAP: On-Line Analytical Processing

ROLAP: Relational OLAP

MOLAP : Multidimensional OLAP

MCD: Modèle Conceptuel des Données

SSIS: SQL Server Integration Services

SSAS: SQL Server Analysis Services

SSRS: SQL Server Report Services

SSMS: SQL Server Management Studio

SSBIDS: SQL Server Business Intelligence Development Studio

SA: Staging Area

vii
Liste des tableaux

Tableaul. Tableau de comparaison des processus OLTP et OLAP

Tableau2. Tableau comparatif des avantages et inconvénients des solutions blanches et pré-
packagées.

Tableau3. Tableau de l'étude descriptive des solutions BI médicales

Tableau4. Tableau descriptif de la dimension «DWDIMPROFESSION»

Tableau5. Tableau descriptif de la dimension «DWDIMSEXE»

Tableau6. Tableau descriptif de la dimension «DWDIMMALADIE»

Tableau7. Tableau descriptif de la dimension «DWDIMHABITATION»

Tableau8. Tableau du coût du matériel et de logiciel de la mise en place de la solution

viii
Listes des figures

Figure 1. Le décisionnel au sein du système décisionnel

Figure2. Architecture d'un système décisionnel

Figure3. Structure d'un neurone artificiel

Figure4. Evolution des bases de données décisionnelles

Figures. Structure de données d'un data warehouse

Figure6. Exemple de modélisation en étoile

Figure7. Exemple de modélisation en flocon

Figures. Exemple de modélisation en constellation

Figure9. Exemple de schéma multidimensionnel

Figureto. MCD du système

Figurell. Dimension « DWDIMPROFESSION»

Figure12. Dimension « DWDIMSEXE»

Figure13. Dimension « DWDIMMALADIE»

Figure14. Dimension« DWDIMHABITATION»

FigurelS. Schéma en étoile de la consultation médicale

Figure16. Architecture de chargement des données

Figure17. Diagramme d'activité du processus de chargement

Figure18. Exemple de package SSIS

Figure19. Package TableProfession dans SSIS

Figure20. Package SACONSULTATION dans SSIS

Figure21. Package DWDIMHABlTA TION dans SSIS

Figure22. Package DWDIMPROFESSION dans SSIS

Figure23. Package DWFAlTCONSULTATION dans SSIS

Figure24. Création du projet SSASTemps

63~ix
Figure25. Création d'une dimension Time 1 à l'aide de l'assistant SSAS

Figure 26. Définition de la période

Figure 27. Sélection du type de calendrier

Figure 28. Génération des attributs

Figure 29. Visualisation des données de la table Time _ l

Figure 30. Cube multidimensionnel de la consultation médicale

Figure 31. Rapport de la consultation médicale

Figure 32. Rapport Nombre de Cas par maladie de la consultation médicale

X
Introduction générale

1
1- Contexte de l'étude

C'est dans un environnement fortement complexe et hautement concurrentiel qu'évolue la


majeure partie, si ce n'est la totalité, des entreprises. Ce climat de forte concurrence exige
de ces entreprises 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 ainsi que leurs partenaires. Pour ce faire, les dirigeants de
l'entreprise, quel que soit leur domaine d'activité, doivent être en mesure de mener à bien
les missions qui leur incombent en la matière. lis devront prendre, à cet effet, les décisions
les plus opportunes. Ces décisions, qui influeront grandement sur la stratégie de
l'entreprise et sur son devenir, ne doivent être prises ni à la légère, ni de manière trop
hâtive, compte tenu de leurs conséquences sur la survie de l'entreprise. li s'agit de prendre
des décisions fondées ou basées sur des informations claires, fiables et pertinentes.
Le problème est donc de savoir comment identifier et présenter ces informations à qui de
droit, sachant par ailleurs que les entreprises croulent d'une part sous une masse
considérable de données et d'autre part que les systèmes opérationnels ou « transactionnels
» s'avèrent limités voire inaptes à fournir de telles informations et constituer par la même
occasion un support appréciable à la prise de décision.

C'est dans ce contexte que les systèmes décisionnels ont vu le jour. Ces systèmes offrent
aux décideurs des informations de qualité sur lesquelles ils pourront s'appuyer pour arrêter
leur choix décisionnel. Pour ce faire, ces systèmes utilisent un large éventail de
technologies et de méthodes parmi lesquelles nous pouvons noter les entrepôts de données
(ou Data Warehouse (DW) en anglais) qui représentent l'élément principal et
incontournable pour la mise en place d'un bon système décisionnel.

De nos jours, il devient ainsi possible pour une structure de s'évaluer et d'anticiper grâce à
l'informatique décisionnelle (ou Business Intelligence (BI) en anglais). C'est d'ailleurs ce
qui justifie le thème de notre mémoire : « Etude d'une plateforme décisionnelle pour la

gestion des informations médicales»

1
2- Problématique de l'étude

Les entrepôts de données ont été conçus pour l'aide à la décision. Us intègrent les
informations en provenance des différents systèmes transactionnels de l'entreprise.
L'ensemble des données, y compris leur historique, est utilisé pour faire des calculs
prévisionnels, des statistiques ou pour établir des stratégies de développement et d'analyses

des tendances.
Dans le cadre de notre recherche, nous nous proposons d'adapter notre savoir-faire au
problème de la gestion de données médicales qui constituent un cadre applicatif
particulièrement intéressant. En effet, ces données se trouvent reparties dans plusieurs
sources qu'il faut, dans un premier temps, fédérer pour constituer un entrepôt de données
pertinentes pour l'application visée. Cette étape est importante dans la mesure où elle doit
non seulement identifier les sources, mais aussi déterminer comment extraire de ces
sources les données désirées. Nous devons alors déterminer si les données doivent être
extraites telles quelles ou bien s'il faut les traiter au préalable en leur appliquant des
fonctions spécifiques. Cela suppose qu'il faut déterminer l'adaptation de ces données soit
au niveau de l'application d'extraction, soit au niveau des agrégats soit au niveau de

l'application d'analyse.
Cette problématique est générale à la constitution de tout entrepôt, mais nous devons ici
tenir compte de la nature particulière des données sur lesquelles portent l'étude à savoir le
type, le format, la sémantique, les informations manquantes ou incomplètes etc.

En somme, il s'agit de constituer un entrepôt de données qui contient des données


pertinentes et de qualité sur lesquelles seront basés l'outil d'interrogation et le processus
d'aide à la décision médicale. Cette application aidera au mieux les professionnels de la
santé en charge des décisions à avoir une vue sur l'ensemble des activités menées dans
leurs établissements hospitaliers respectifs afin d'aboutir à des prises de décisions

optimales.

3- Présentation du thème

Le thème de notre mémoire est: « Etude d'une plateforme décisionnelle pour la gestion
des informations médicales ». A travers ce thème, nous voulons approfondir nos

3
connaissances sur le sujet du système d'information décisionnel afin de l'adapter au
domaine spécifique d'activités médicales où la gestion des données demande une attention
particulière. Mais, qu'entendons-nous par information médicale?

~ Information médicale

Selon le site Wikipédia, une information médicale est une spécialité d'origine récente
fondée sur l'analyse de données informatiques relatives aux patients et aux services de
santé pour disposer d'éléments chiffrés sur l'activité du centre de santé.
Par ailleurs en Côte d'Ivoire, l'information médicale se définit comme étant l'ensemble
des données recueillies sur un malade au cours d'une consultation et auprès des différents
services de l'hôpital. Ces données comprennent en général:

• une analyse des temps d'attente (par exemple par département).


• une analyse de la durée du séjour des patients (par département, par âge, par
traitement, etc.).
• une analyse du comportement de prescription des médecins.
• une gestion des stocks des matériaux et de la pharmacie.
• une réduction des coûts opérationnels en analysant l'utilisation des matériaux. la
gestion des ressources (achat basé sur la demande ou le besoin en ce moment) et les
fournisseurs (des livraisons à temps, de bon prix).
• un suivi mensuel, trimestriel ou annuel des différents départements, médecins,
patients ou traitements.
• un accès aux dossiers médicaux des patients.
• une combinaison des informations provenant du système de planification, du
système financier et du système des ressources humaines.

• un suivi des paiements.


• une analyse des coûts et des rendements par département, médecin ou patient etc.

Dans le cadre de notre recherche, nous avons focalisé notre travail sur le dossier médical
des patients et celui des maladies dont ceux-ci pourront éventuellement être atteints.

4
)il, Sources de données réelles

11 existe deux types de sources réelles qui sont la base de données « BDPatients » et la
base de données « BD _Maladie ». Ces sources de données ont été conçues à partir des
informations recueillies auprès des spécialistes de la santé que nous avons rencontrés au
cours de notre travail.

Ces sources seront fournies en annexe (à la page 73).

4- Obiectif du mémoire

Notre objectif consiste à la conception et à la réalisation d'un entrepôt de données pour


l'aide à la décision médicale. C'est pourquoi nous proposons:
la récupération des données en provenance de sources multiples des différents

services de l'hôpital;
la consolidation et le traitement de ces données en vue de les rendre exploitables;
le développement et le suivi des indicateurs pour mesurer la qualité des soins;
l'envoi périodique ou généralement par mail, des tableaux de bord au grand nombre
d'utilisateurs en vue de décisions prévisionnelles.

)il, Les utilisateurs

Ce sont:
le Ministère de la Santé et de Lutte contre le Sida
les Directeurs régionaux de la santé
les Directeurs des centres hospitaliers,
les Médecins.

De ce qui précède, nous pouvons retenir que les progrès techniques dans le domaine
médical sont une solution aux difficultés que connaissaient autrefois les gestionnaires et
analystes médicaux ainsi que les médecins dans leur pratique. Ces progrès, il faut le
souligner, relèvent de la Business Intelligence (Bl) dont le cœur repose sur l'entrepôt de

5
données (ED) qui est alimenté par les ETL (Extract-Transform-Load); les informations
contenues dans l'ED sont récupérées par de nombreux outils qui permettent de répondre
aux divers problèmes.

Dans le souci d'une meilleure présentation de notre travail, nous avons mis principalement
l'accent sur l'entrepôt de données (ED) dans le domaine médical. Toutefois, pour mieux
appréhender notre préoccupation nous avons articulé notre travail en quatre parties

essentielles qui sont :

• introduction générale
• Aspects théoriques de la Business intelligence
• Etat de l'art du système décisionnel existant dans le domaine médical
• Modélisation-Alimentation-Exploration du système

Après une introduction générale dans laquelle nous avons présenté le contexte général du
projet ainsi que la problématique et les objectifs visés, la première partie consistera à
présenter les aspects théoriques du domaine des systèmes d'information d'aide à la
décision (SlAD), en évoquant leurs définitions et les concepts de bases relatifs aux «
entrepôts de données » et à la BI.
Dans la deuxième partie, nous présenterons l'état de l'art du système décisionnel existant

dans le domaine médical.


La troisième partie, quant à elle, décrit l'architecture globale de La solution; cela en
présentant les différents outils intégrés et les volets de la solution développés. Elle décrit
aussi la manière dont se passe le déploiement de la solution.
Une conclusion générale est proposée afin de synthétiser le travail réalisé et de citer les

perspectives du projet.

6
Partie I:
Aspects théoriques de
la Business Intelligence

7
Chapitre!: Approche générale de la Business Intelligence

Par le passé, les décisions dans les structures telles que les établissements sanitaires et
même en entreprise étaient prises selon l'intuition du pôle exécutif sans l'aide de
l'informatique. Cela était dû au fait que les outils informatiques de l'époque ne le
permettaient pas. Autrement dit, il était difficile d'accéder à l'outil informatique compte
tenue de la non maitrise de la chose et du coût exorbitant. L'informatique, était l'apanage
de quelques riches (aussi bien les hommes que les entreprises ou les structures). Ainsi, les
informations étaient sauvegardées tant bien que mal. En effet, toutes les entreprises du
monde disposent d'une masse de données plus ou moins considérable. Ces informations
proviennent soit de sources internes (générées par leurs systèmes opérationnels au fil des
activités journalières) soit de sources externes (web, partenaire, etc.). Cette surabondance
de données et l'impossibilité des systèmes opérationnels de les exploiter à des fins
d'analyse conduit, inévitablement, l'entreprise à se tourner vers une nouvelle informatique
dite décisionnelle qui met l'accent sur la compréhension de 1 'environnement de l'entreprise
et l'exploitation de ces données à bon escient.
L'informatique décisionnelle (Business Intelligence (BI) en anglais) désigne l'ensemble
des moyens, des outils et des méthodes qui permettent de collecter, de consolider, de
modéliser et de restituer les données internes ou externes d'une entreprise en vue d'offrir
une aide à La décision. Elle est à l'usage des décideurs et des dirigeants. Ainsi, à l'aide de
cet outil, le décideur peut à tout moment avoir une vue sur l'activité traitée dans sa
structure. Toutefois, cela ne peut se faire qu'en mettant en place des indicateurs« business
» clairs et pertinents qui permettent la sauvegarde, l'utilisation de la mémoire de
l'entreprise et en offrant aux décideurs la possibilité de se reporter à ces indicateurs pour
une bonne prise de décision.
Le data warehouse (DW) ou entrepôt de données en français constitue dans ces
conditions une structure informatique et une fondation des plus incontournables pour la
mise en place des applications décisionnelles. Le concept de DW, tel que connu
aujourd'hui, est apparu pour la première fois en 1980; l'idée consistait à réaliser une base
de données destinée exclusivement au processus décisionnel. Les nouveaux. besoins de
l'entreprise, les quantités importantes de données produites par les systèmes opérationnels

8
et l'apparition des technologies aptes à sa mise en œuvre ont effectivement contribué à
l'apparition du concept« data warebouse » comme support aux systèmes décisionnels.

De nos jours, il devient ainsi possible pour une structure de s'évaluer et d'anticiper grâce à

la Business Intelligence.

A- Présentation de la Business intelligence

La raison d'être d'un entrepôt de données, comme évoqué précédemment, est la mise en
place d'une informatique décisionnelle au sein d'une structure. C'est pourquoi il serait
assez intéressant pour nous de définir quelques concepts clés relatifs au concept de
décisionnel. Par ailleurs, pour mieux comprendre la finalité des systèmes décisionnels
nous essaierons de les placer dans leurs contextes et rappellerons ce que c'est qu'un
système d'information.

Le système d'information (SI) est l'ensemble des méthodes et moyens de recueil, de


contrôle et de distribution des informations nécessaires à l'exercice de l'activité en tout
point de l'organisation. 11 a pour fonction de produire et de mémoriser les informations, de
1 'activité du système opérant (système opérationnel), puis de les mettre à la disposition du
SIAD (système de pilotage).

1- Historique

La notion de Business Intelligence est apparue à la fin des années 1970 avec les premiers
infocentres. Les infocentres sont des systèmes qui envoyaient des requêtes directement sur
les serveurs de production, mais cela se révélait plutôt dangereux pour ces derniers. Dans
les années 1980, l'arrivée des bases de données relationnelles et du mode client/serveur a
permis par contre d'isoler l'informatique de production des dispositifs décisionnels.
Toutefois, dans la foulée, des acteurs spécialisés se sont lancés dans la définition de
couches d'analyse "métier", dans le but de masquer la complexité des structures de
données. Dès lors, la 81 n'est plus l'affaire des équipes techniques, dans la mesure où. elle
est directement accessible aux responsables opérationnels que sont les décideurs et les

dirigeants des entreprises.

9
C'est d'ailleurs ce que soutenait Goglin J.-F quand il dit que « le système d'information
décisionnel est un ensemble de données organisées de façon spécifique, facilement
accessible et appropriées à la prise de décision. la finalité d'un système décisionnel est
donc le pilotage d'entreprise ».1 [4]

Dit autrement, la Business Intelligence (BI), également appelée "intelligence


d'affaires" ou "informatique décisionnelle" englobe les solutions informatiques qui
apportent une aide à la décision. Plus simplement, elle est la transformation de
données brutes en information puis la transformation de l'information en savoir;
elle permet aussi de mettre en œuvre des moyens pour collecter. consolider et
restituer des données afin :

de prédire et/ou gérer les ventes,


d'évaluer le risque-client (par exemple pour les banques et assurances)
de définir des comportements des populations afin d'aider les entreprises à
définir leur cible-client.
En somme, l'entrepôt de données est le cœur de La Business Intelligence. Il est alimenté
par les ETL (Extrat-Transform-Load) et ses données sont récupérées par de nombreux
outils permettant de répondre aux problèmes.

~ Quelle est donc la place du décisionnel en entreprise ?

PUotag

omprabUlcé anaJ;n:lque

Anal~ - de ~e-,tlon

:::SoYou noœ-.olf:,,é
ProducHon

TIF ~I

Figure 1. Le décisionnel au sein du système décisionnel 14]

1La construction du datawarehouse: Du datamart au dataweb. Hermes, 2ème édition 2001,


pp21-22.

10
La figure ci-dessus illustre parfaitement la place qui revient au décisionnel au sein d'une
entreprise. Cette place, comprend plusieurs fonctions clés de l'entreprise. Les finalités
décisionnelles, étant différentes selon le poste et La fonction occupée ont pour but
d'engendrer plusieurs composantes.

Pour analyser les données, il est indispensable de les rassembler en un seul endroit. Or, les
données d'une entreprise se trouvent dans de multiples endroits et ne sont pas souvent
cohérentes. Pour les rassembler et afin de les nettoyer, nous utilisons un logiciel de type
ETL.

2- ETL (Extraa-Transform-Loadï

L'ETL est le processus qui permet de charger un data warehouse (entrepôt de données) à
partir de données externes généralement issues de sources différentes. Son rôle est de
récupérer ces données et de les traiter pour qu'elles correspondent aux besoins du modèle
dimensionnel.

Selon Kimball R. et Caserta J, « 70% de l'effort consacré à un projet de Bi est dépensé


dans l'ETL ».2 [6]

En ce qui concerne la nécessité de nettoyer et transformer les données extraites, un ETL


vise:
• à les homogénéiser, c'est-à-dire définir un format commun pour les données.
Prenant l'exemple des dates, si certains utilisent le format français 12/01/2012 et
d'autres Le format us 01/12/2012, on risque une confusion de l'information.
• soit à nettoyer les données, soit à supprimer les données anciennes ou celles
incohérentes, ou encore agir doublement c'est à dire nettoyer et supprimer (les
données). C'est l'exemple des produits sans nom ni prix.

Pour résumer ce passage relatif aux ETLs, nous sommes partis de données brutes que nous
avons nettoyées et transformées. mais où et comment les stocker? Nous allons stocker ces

2
ln The Data Warehouse ETL Toolkit. Wiley Publishing. (2004).

11
données dans une base de données particulière, appelée data warehouse ou entrepôt de
données.

3- Entrepôts de données ou Data Warehouse

La raison d'être d'un entrepôt de données, comme évoqué précédemment. est la mise en
place d'une informatique décisionnelle au sein de l'entreprise. Les entrepôts de données
sont apparus vers les années 1990 en réponse à la nécessité de rassembler toutes les
informations de l'entreprise en une base de données unique destinée aux analystes et aux
gestionnaires. L'ensemble des données, y compris leur historique sont utilisés dans de
nombreux domaines, tels que l'analyse de données et l'aide à la décision (gestion et
analyse de marché, gestion et analyse du risque, gestion et détection des fraudes etc ... ),
ainsi que dans certaines autres applications (recherches dans des textes, dans les documents
web etc ... ).

De ce qui précède, nous pouvons dire que le data warehouse est fait pour stocker les
données selon les besoins actuels et futurs de l'entreprise et répondre à tous les utilisateurs.

Dans ce chapitre, où nous analysons aussi bien les caractéristiques des entrepôts que leurs
aspects temporels, nous présenterons d'abord l'architecture d'un système décisionnel qui
se constitue de trois composantes à savoir les sources, l'entrepôt de données et les outils
pour l'interrogation de l'ensemble de données. Nous décrirons aussi les caractéristiques
des entrepôts et les bases de données relationnelles.

4- Architecture d'un système décisionnel

L'architecture d'un système décisionnel repose sur un SGBD (data warehouseï séparé du
système de production de l'entreprise qui contient les données de l'entrepôt. Le processus
d'extraction des données (les outils ETL) permet d'alimenter périodiquement ce SGBD.
Néanmoins avant d'exécuter ce processus, une phase de transformation est appliquée aux
données opérationnelles. Celle-ci consiste à les préparer (mise en correspondance des

12
formats de données), les nettoyer, les filtrer, pour finalement aboutir à leur stockage dans
l'entrepôt ou data warehouse. La Figure suivante nous présente cette architecture:

Data Ma
Generate.ir
d'~ta
BD Interne

Cube OLAP Analyse


Multidimens,onnette

BD E,;terne
En.. Data Wareho.ise

Data M1mng

Data Mart f-,-


Fichiers rxr,
csv ...
Tableaux de
bord

Source de Extraction Stockage Restitution


Donnée

Figure 2. Architecture d'un système décisionnel

Source: ADULLACT (Association des Développeurs et des Utilisateurs de Logiciels


Libres pour les Administrations et les Collectivités Territoriales), Etat de l'art: Solutions
Open Source de Business Intelligence, pl 7. 2008.

ll existe trois grandes parties qui sont : les sources de données, l'entrepôt ou le data
warehouse et les outils d'interrogation existants sur le marché.

a / Les sources de données proviennent de différentes bases de données complexes. Il


existe deux types de sources de données: les données internes et externes à l'organisation.

b / L'entrepôt de données ou data warehouse. Il existe plusieurs types de données dans


un entrepôt qui correspondent à diverses utilisations. Chaque donnée se présente sur deux
axes l'un synthétique et l'autre historique.
• L'axe synthétique établit une hiérarchie d'agrégation comprenant:

13
les données détaillées qui représentent les événements les plus récents au bas
de la hiérarchie et
les données agrégées, qui, elles, synthétisent les données détaillées. les
données fortement agrégées synthétisant à un niveau supérieur les données
agrégées.
• L'axe historique comprend les données détaillées historisées représentant les
événements passés.

La description de toutes ces données (provenance, structure, méthode utilisées pour


l'agrégation) constitue les métadonnées de l'entrepôt.

c / Les outils. il existe sur le marché différents outils pour l'aide à la décision. comme les
outils de fouille de données ou data mining (pour découvrir des liens sémantiques), les
outils d'analyse en ligne OLAP "On-Line Analytical Processing" (pour la synthèse et
l'analyse des données multidimensionnelles), les outils d'interrogation (pour faciliter
l'accès aux données en fournissant une interface conviviale au langage de requêtes).

5. Data mining

Le data mining ou fouille de données est un ensemble de techniques tirées des


mathématiques permettant le forage de données, c'est-à-dire la recherche d'informations
dans de grands volumes de données. C'est l'art d'extraire des connaissances à partir des
données. Nous pouvons citer à ce sujet les réseaux de neurones, l'analyse en composant
principal, l'analyse du discrimant linéaire, les chaînes de Markov etc ...
L'un des principaux modèles utilisés est le réseau de neurones.

)- Le réseau de neurones

Un réseau de neurones est un modèle de calcul dont le fonctionnement schématique est


inspiré du fonctionnement des neurones biologiques. Chaque neurone fait une somme
pondérée de ses entrées et retourne une valeur en fonction de sa fonction d'activation.
Cette valeur peut être utilisée soit comme une des entrées d'une nouvelle couche de

14
neurones, soit comme un résultat dont il appartient à l'utilisateur d'interpréter (classe,
résultat d'un calcul, etc.).
La phase d'apprentissage d'un réseau de neurones permet de régler le poids associé à
chaque synapse d'entrée; on parle également de coefficient synaptique. C'est un processus
long qui doit être réitéré à chaque modification structurelle de la base de données traitées.

DoidS
valeurs
,, . O"IC: O"I
'1 ;,n '"' '•'
\ .. ., Il /}
.,
~,t,tttUtl• V>'-'!'·•' I
nrt . Il, 1 ,,
\1 •
/' ~) ; · __!. J
,_,,., ln,i, •1••

'tt.
/ 1111,t.ll •) • .,,,

IJ
•.,.1--,1

Figure 3. Structure d'un neurone artificiel

Source: Guillaume CALAS, Études des principaux algorithmes de data mining, [SCIA]
EPITA 2009, ppl-20, 2009.

B- informatique décisionnel vs Informatique de production

Dans l'environnement des entrepôts de données, les opérations, l'organisation des


données, les critères de performance, la gestion des métadonnées, la gestion des
transactions et le processus de requêtes sont très différents des systèmes de bases de
données opérationnels. Par conséquent, les SGBD relationnels orientés vers
l'environnement opérationnel ne peuvent pas être directement transplantés dans un
système d'entrepôt de données.

l. Informatique de production

Les bases de données ou SGBD relationnels sont utilisées dans les entreprises pour gérer
les volumes importants d'informations contenus dans leurs systèmes opérationnels. Ces

15
données sont gérées selon des processus transactionnels en ligne (OLTP "On-Une
Transactional Processing") qui se caractérisent de la manière suivante :
- ils sont nombreux au sein d'une entreprise
- ils concernent essentiellement la mise à jour des données,
- ils traitent un nombre d'enregistrements réduits,
- ils sont définis et exécutés par de nombreux utilisateurs.

L'exploitation de l'information contenue dans les systèmes opérationnels étant devenue


une préoccupation essentielle pour les dirigeants des entreprises, la prise de décisions
stratégiques qui leur incombe nécessite le recours et le croisement de multiples
informations. C'est pourquoi il faut penser à l'informatique décisionnelle.

2. Informatique décisionnelle

A l'inverse de l'informatique de production, le décisionnel fournit les informations pour


définir la stratégie, piloter les opérations et analyser les résultats. Ainsi, le data warehouse
qui est le cœur de cette informatique intègre ces informations qui ont pour objectif de
fournir une vue globale de l'information aux analystes et aux décideurs. Ces applications
utilisent des processus d'analyse en ligne de données (OLAP : "On-Line Analytical
Processing") qui se caractérisent de la manière suivante:
- ils sont peu nombreux mais leurs données et traitements sont complexes.
- il s'agit uniquement de traitements semi-automatiques visant à interroger. visualiser et

synthétiser les données.


- ils concernent un nombre d'enregistrements importants aux structures hétérogènes.
- ils sont définis et mis en œuvre par un nombre réduit d'utilisateurs qui sont les décideurs.

On résume tout ceci dans le tableau suivant :

16
Processus OLTP Processus OLAP

Données exhaustives, courantes, résumées, historisées,


dynamiques, orientées statiques, orientées sujets,
applications, mises à jour et interrogation
interrogation
Utilisateurs Nombreux, variés (employés Peu nombreux, uniquement
et directeurs), les directeurs et décideurs

Mode accès Concurrent, lecture/ écriture Lecture seule

Temps de réponse Réponse immédiate Réponse moins rapide

Requêtes prédéfinies Imprévisibles et complexes

Tableaul.Tableau de comparaison des processus OLTP et OLAP

Pour mieux appréhender le thème soumis à notre travail, il convient de revenir plus en
détail sur le concept du data warehouse en ce sens qu'un système décisionnel o' existe que
par ce dernier.

17
Chapitre 2: Data Warebouse

1. Approche définitionnelle

Considéré comme étant la référence dans le domaine "Building the Data Warebouse", Bill
ln.mon définit le data warehouse, dans son livre en ses propres termes :
« Le data warehouse est une collection de données orientées sujet, intégrées, non
volatiles et évolutives dans le temps, organisées pour le support d'un processus d'aide à
la décision». 3[5]

Les paragraphes suivants illustrent les caractéristiques citées dans la définition d'Inmon,

Orientées sujet: le DW est organisé autour des sujets majeurs de l'entreprise,


contrairement à l'approche transactionnelle utilisée dans les systèmes opérationnels, qui
sont conçus autour des applications et des fonctions comme les cartes bancaires. la
solvabilité client etc. Les DW sont organisés autour de sujets majeurs de l'entreprise tels
que la clientèle, les ventes, les produits etc. Cette organisation, il faut le dire, affecte
forcément la conception et l'implémentation des données contenues dans l'entrepôt de
données ; de même que le contenu en données et en relations. Dans un système
opérationnel, les données sont essentiellement destinées à satisfaire un processus
fonctionnel en obéissant à des règles de gestion, alors que celles d'un DW sont destinées à

un processus analytique.

Intégrées : le data warehouse va intégrer les données en provenance de différentes


sources. Mais cela nécessite la gestion de toute incohérence.

Evolutives dans le temps. Dans un système décisionnel, il est important de conserver les
différentes valeurs d'une donnée, cela permet les comparaisons et le suivi de l'évolution

3 « Building the Data Warehouse Third Edition»; Wiley Computer Publishing 2002

18
des valeurs dans le temps alors que dans un système opérationnel la valeur d'une donnée
est simplement mise à jour. Dans un DW, chaque valeur est associée à un moment.
« Every lœy structure in the data warehouse contains - implicitly or explicitly -an
element of lime »4[5] disait lnmon.

Non volatiles : c'est ce qui est, en quelque sorte la conséquence de l'historisation décrite
précédemment. Une donnée dans un environnement opérationnel peut être mise à jour ou
supprimée; cependant, une telle opération n'existe pas dans un environnement DW.

Organisées pour le support d'un processus d'aide à la décision. Les données du DW


sont organisées de manière à permettre l'exécution des processus d'aide à la décision
(Reporting, Data Mining).

2- Historique des data warehouses

L'origine du concept d'entrepôt de données remonte aux années 1980 durant lesquelles
un intérêt croissant au système décisionnel a vu le jour; cela se justifie essentiellement par
l'émergence des SGBD relationnels, la simplicité du modèle relationnel et la puissance
offerte par le langage SQ L.

Au début, en effet, le data warehouse n'était rien d'autre qu'une copie des données du
système opérationnel prise de façon périodique; cette dernière étant dédiée à un
environnement de support à la prise de décision. Ainsi, les données étaient extraites du
système opérationnel et stockées dans une nouvelle base de données «concept d'infocentre
» dont le motif principal est de répondre aux requêtes des décideurs sans toutefois altérer
les performances des systèmes opérationnels.

Le data warehouse, tel qu'on le connaît actuellement, n'est plus vu comme une copie ou
un cumul de copies prises de façon périodique des données du système opérationnel. Il est
devenu une nouvelle source d'informations. alimenté avec des données recueillies et
consolidées des différentes sources internes et externes.

4
« Building the Data Warehouse Third Edition»; Wiley Computer Publisbing 2002

19
Figure 4. Evolution des bases de données décisionnelles

3- Structure des données d'un data warehouse

Le data warehouse a une structure bien définie, selon différents niveaux d'agrégation et de
détails des données. Comme nous l'avons souligné plus haut, chaque donnée se présente
sur deux axes; l'un synthétique et l'autre historique. Ce que nous pouvons résumer dans le
diagramme suivant :

1 Données '""'-"-"'

\! B\ /
d)
;::l
Données agrégées
CJ ô
-
.2
'0
..c
~
Cl)
Cl)

I î \
Données détaillées

LI
Données détaillées historisées
0 0 0
Axe historique >
Figure 5. Structure de données d'un datawarehouse

La description de toutes ces données, c'est-à-dire la provenance, la structure et la méthode


utilisée pour l'agrégation, etc, constitue les métadonnées de l'entrepôt.

20
4- Modélisation d'un data warehouse

La construction d'un modèle approprié pour un entrepôt de données nécessite de choisir,


soit un schéma relationnel ou dimensionnel (le schéma en étoile, en flocon de neige ou en
constellation), soit un schéma multidimensionnel.
Les données sont organisées de manière à mettre en évidence le sujet (le fait) et les
différentes perspectives de l'analyse (les dimensions).

~ Le fait représente le sujet d'analyse. Il est composé d'un ensemble de mesures qui
représentent les différentes valeurs de l'activité analysée.
Une table de faits assure les liens plusieurs à plusieurs entre les dimensions. Elles
comportent des clés étrangères qui ne sont autres que les clés primaires des tables

de dimension.

~ Une dimension modélise une perspective de l'analyse. Elle se compose de


paramètres (ou attributs) qui servent à enregistrer les descriptions textuelles. C'est
d'ailleurs grâce à cette table que l'entrepôt de données est compréhensible et

utilisable.

~ Une hiérarchie représente les paramètres d'une dimension selon leur niveau de

granularité ou de détail.

4.1- Schéma relationnel

Il existe deux types de schémas relationnels. Les premiers sont des schémas qui répondent
fort bien aux processus de type OLTP qui ont été décrits précédemment, alors que les
secondes, que nous appelons des schémas pour le décisionnel, ont pour but de proposer des
schémas adaptés pour des applications de type OLAP. Nous décrivons les différents types

des schémas relationnels pour le décisionnel.

21
4.1.1- Schéma en étoile

C'est un schéma dans lequel il existe une table pour les faits et plusieurs tables pour les
différentes dimensions autour de celle-ci. La table de faits contient les différentes mesures
et des clés étrangères de chacune de leurs tables de dimensions.

La figure 6 (ci-dessous) montre le schéma en étoile en décrivant les consultations


réalisées par différents patients exerçant une profession particulière au cours d'un jour.

1 ~:,:rr.tSEXE
,.,,_,,.,. •• a ~-v•. c..o
i
,1u1'.1Fi'Of'ESSIOI,
tg!)!\'Pr; 1tu::P:" ~~
~ ;"' N•"tl"~.!5j

Figure 6. Exemple de modélisation en étoile

Dans ce cas, nous avons une étoile centrale avec une table de faits appelée
DWFAlTCONSULTATION et autour ses diverses dimensions DWTEMPS,
DWD1MSEXE, DWDIMMALADIE, DWD1MPR0FESS10N et DWDIMHAB1TAT10N.

4.1.2- Schéma en flocon de neige (Snowflake)

Ce schéma dérive du précédent avec une table centrale autour de laquelle les différentes
dimensions, sont éclatées ou décomposées en sous hiérarchies. L'avantage du schéma en
flocon de neige est de formaliser une hiérarchie au sein d'une dimension, ce qui pourrait
faciliter L'analyse. Un autre avantage est représenté par la normalisation des dimensions

22
1

lorsque nous réduisons leur taille. Cette normalisation rend plus complexe la lisibilité et la
gestion dans ce type de schéma. En ce sens, ce type de schéma augmente le nombre de
jointures à réaliser dans l'exécution d'une requête.
La figure 7, elle, montre le schéma en flocon de neige avec les dimensions Temps et
Magasin éclatées en sous hiérarchies des ventes réalisées dans les différents magasins
pendant un certain jour.
Pl'O(hlll
Tc-tnp~
Clf T
Jour
:\ IQi

T_~Joh
ale
~Joh
A.1u,~

:\I_Dc-partc-mc-nt
Dép:1rtrmc-n1
Rf;glou
~I Rc-i:.lon

Figure 7. Exemple de modélisation en flocon

Source : http ://business-intelligence.developpez.com/

Dans l'exemple ci-dessus, la dimension Temps a été éclatée en deux tables: la table
Temps et la table T_Mois. Quant à la deuxième à savoir la dimension Magasin, elle, a été
décomposée en trois tables: la table Magasin, la table M_Departement et la table

M_Région.

4.1.3- Schéma en constellation

Le schéma en constellation représente plusieurs tables de faits qui partagent des


dimensions communes. Ces différentes tables de faits composent une famille qui partage
des dimensions mais où chacune a ses propres dimensions.
La figure 8 montre le schéma en constellation qui est composé de deux relations de faits.
La première s'appelle Ventes et enregistre les quantités de produits vendus dans les

23
différents magasins pendant un certain jour tandis que la deuxième gère les différents
produits achetés aux fournisseurs pendant un certain temps.

ProduJ•

ÇJÉ' "\Ing
R.a, .• on ..ociole
Adre-c..,e
·onunw1e
I:>,:pn~en,enl
Reglon
P:1)."5

,oie

Figure 8. Exemple de modélisation en constellation

Source: http://business-intelligence.developpez.com/

La table de faits Ventes partage les dimensions Temps et Produits avec la table Achats.
Cependant, la dimension Magasin appartient seulement à Ventes et la dimension
Fournisseur est liée uniquement à la relation Achats.

4.2- Schéma multidimensionnel (Cube)

La modélisation multidimensionnelle se base sur un sujet analysé considéré comme un


point dans un espace à plusieurs dimensions.

Le cube représente le concept central du modèle multidimensionnel, lequel est constitué


des éléments appelés cellules qui peuvent contenir une ou plusieurs mesures. La
localisation de la cellule est faite à travers les axes qui correspondent chacun à une
dimension composée de membres représentant les différentes valeurs. La reprise d'une
partie du schéma en flocon de neige de la figure 7 permet de construire le schéma

multidimensionnel suivant :

24
l,13ga5ln

Pnxnl • ~ P:t;s

1/=y: a, ~ ·' ""


,tJgasl
lVR CSCPM
fi hm il
î
Temps

Regon

.,., ,.. ,. "' "' ,.. ..


~~c:=:=:r=:;,--. • .,.,

î î
••
1
Te~ 01ml/21m l--4~--tl--11.-~---

î
m0IS

<W- ••
Jeu v,

Figure 9. Exemple de schéma multidimensionnel

Source: http://business-intelligence.developpez.com/

La figure 9 présente un schéma multidimensionnel pour les ventes qui ont été réalisées
dans les magasins pour les différents produits pendant un temps donné (jour). Par exemple,
nous avons la quantité de 100 Téléviseurs vendus dans le magasin d'Annecy le 1er janvier

2000.

ll est important de noter que la construction d'un cube se fait par l'utilisation d'un serveur

OLAP (voir ci-dessous).

~ Manipulation des données multidimensionnelles

Pour visualiser les données multidimensionnelles, nous pouvons utiliser la représentation


sous forme d'une table de données lorsque le nombre de dimensions est inférieur ou égal à
deux. L'augmentation de ce nombre crée des problèmes à l'utilisateur.
Pour résoudre ce problème, nous devons disposer d'opérations afin de manipuler les
données et rendre possible la visualisation. Nous présentons ici, quelques opérations de la
manipulation des données multidimensionnelles :

25
• Opérations classiques
Ces opérations correspondent aux opérations relationnelles de manipulation des données
comme la sélection. la projection, la jointure et les opérations ensemblistes.
• Opérations agissant sur la structure
Les opérations agissant sur la structure visent à présenter une vue (face du cube)
différente en fonction de leur analyse c'est-à-dire la rotation, La permutation, la division,
L'emboîtement (nest), L'enfoncement (push), Le retrait (pull) et L'opération Cube.
• Opérations agissant sur la granularité
Les opérations agissant sur La granularité des données analysées permettent de hiérarchiser
la navigation entre les différents niveaux de détail d'une dimension c'est-à-dire le forage
vers Le haut (drill-up ou roll-up) et le forage vers le bas (drill-down ou roll-down ou scale-
down).

5- Serveurs OLAP

Les systèmes décisionnels reposent sur les processus OLAP conçus pour répondre aux
besoins d'analyse des applications de gestion. A ce sujet, nous exposerons sur les divers
types de stockage des informations dans Les systèmes décisionnels.

5.1- ROLAP (Relatiooal OLAP)

Dans Les systèmes relationnels OLAP, l'entrepôt de données utilise une base de données
relationnelle. Le stockage et La gestion de données sont relationnels. Ces systèmes sont en
mesure de simuler le comportement d'un SGBD multidimensionnel en exploitant un
SGBD relationnel. L'utilisateur aura ainsi L'impression d'interroger un cube
multidimensionnel alors qu'en réalité, il ne fait qu'adresser des requêtes sur une base de
données relationnelles. Par ailleurs, ROLAP n'agrège rien dans le mesure où les règles
d'agrégations sont créées au préalable et représentées dans une table relationnelle; cela
cause une lourdeur administrative tout en conférant une certaine performance et un gage de
cohérence lors de l'utilisation. Cette structure est généralement adoptée dans le but de se
dispenser de l'acquisition d'un SGBD relationnel. Toutefois, le modèle relationnel requiert
des extensions pour supporter les requêtes d'analyses multidimensionnelles du niveau

26
d'application. En outre, Les stratégies d'optimisation représentent le point principal qui
distingue les systèmes ROLAP.
La technologie ROLAP a deux avantages principaux :
elle permet la définition de données complexes et multidimensionnelles
en utilisant un modèle relativement simple,
elle réduit le nombre de jointures à réaliser dans l'exécution d'une

requête.
L'inconvénient est que le langage de requêtes tel qu'il existe, n'est pas assez puissant ou
flexible pour supporter de vraies capacités d 'OLAP.

5.2- MOLAP (Multidimensional OLAP)

Les systèmes multidimensionnels OLAP utilisent une base de données


multidimensionnelle pour stocker les données de l'entrepôt et les applications analytiques
sont construites directement sur elle. Dans cette architecture, le système de base de
données multidimensionnel sert tant au niveau de stockage qu'au niveau de la gestion des
données. Les données des sources sont conformes au modèle multidimensionnel; et dans
toutes Les dimensions, les différentes agrégations sont recalculées pour des raisons de
performance.
Les avantages des systèmes MOLAP sont basés sur les désavantages des systèmes
ROLAP et représentent la raison de leur création. D'un côté, Les requêtes MOLAP sont très
puissantes et flexibles en termes du processus OLAP, tandis que de L'autre, le modèle
physique correspond plus étroitement au modèle multidimensionnel.
Néanmoins, il existe des désavantages au modèle physique MOLAP. Le plus important
c'est qu'il n'existe pas de standard du modèle physique.

5.3-HOLAP (Hybrid OLAP)

Un système HOLAP est un système qui supporte et intègre un stockage des données
multidimensionnel et relationnel d'une manière équivalente pour profiter des
caractéristiques de correspondance et des techniques d'optimisation.
Les caractéristiques principales d'un système HOLAP sont:

27

1
• la transparence du système. lei, en ce qui concerne le processus de la localisation
et l'accès aux données, il n'est pas utile de connaître si celles-ci (données) sont
stockées dans un SGBD relationnel ou dimensionnel.

• le modèle de données générales et un schéma multidimensionnel global. Pour


aboutir à la transparence du premier point, il faut noter qu'aussi bien Le modèle de
données général que le Langage de requête uniforme doit être fournis. Etant donné
qu'il n'existe pas un modèle standard, cette condition est difficile à réaliser.

• l'allocation optimale dans le système de stockage. Le système HOLAP doit


bénéficier des stratégies d'allocation qui existent dans Les systèmes distribués tels
que le profil de requêtes, le temps d'accès, l'équilibrage de chargement, etc.
• La réallocation automatique. Toutes les caractéristiques traitées ci-dessus
changent dans le temps. Toutefois, ces changements peuvent provoquer la
réorganisation de la distribution des données dans le système de stockage
multidimensionnel et relationnel afin d'assurer des performances optimales.

De ce qui précède, nous pouvons remarquer qu'actuellement, la plupart des systèmes


commerciaux utilisent une approche hybride. Cette approche permet, en effet, de
manipuler des informations de l'entrepôt de données avec un moteur ROLAP. Pour la
gestion des datamarts, les systèmes commerciaux utilisent L'approche

multidimensionnelle.

6- Démarche de construction d'un data warehouse

Plusieurs chercheurs ou équipes de recherche ont essayé de proposer des démarches pour
la réalisation d'un projet data warehouse; celles-ci se croisent essentiellement dans les

étapes suivantes :
• la modélisation et la conception du data warehouse,
• l'alimentation du data warehouse,
• la mise en œuvre du data warehouse,
• l'administration et la maintenance du data warehouse.

28
6.1. Modélisation et conception du data warebouse

Les deux approches les plus connues clans la conception des data warebouse sont :
• l'approche basée sur les besoins d'analyse et

• l'approche basée sur les sources de données.

Aucune des deux approches citées n'est ni parfaite ni applicable à tous les cas. Mais toutes
deux doivent être étudiées pour choisir celle qui s'adapte le mieux à notre cas. Quel que
soit l'approche adoptée pour la conception d'un data warehouse, la définition de ce dernier

reste la même.

~ Approche« Besoins d'analyse»

Le contenu du data warehouse sera déterminé selon les besoins de l'utilisateur final.
Cette approche appelée aussi« approche descendante» (Top-Down Approach en anglais) a

été conçue par R. Kimball,


En ce qui concerne les avantages de cette approche, il n'y a pas de risque de concevoir
une solution obsolète avant d'être opérationnelle.
Par contre, nombreux sont ses inconvénients:
Aucune prise en compte de l'évolution des besoins de

l'utilisateur.
Nécessité d'une modification de la structure du data warehouse en
cas de nouveau besoin.
Négligence du système opérationnel.
Difficulté de déterminer les besoins des utilisateurs.

~ Approche « Source de données »

Le contenu du data warehouse est déterminé selon les sources de données. Cette approche
est appelée« approche ascendante» (Bottom-up Approach en anglais) et est illustrée par B.

lnmon.

29
Inmon considère que l'utilisateur ne peut jamais déterminer ses besoins dès le départ,
parce que ses besoins sont en constante évolution. Il traduit cela en ces termes:
5
« Donnez-moi ce que je vous demande, et je vous direz ce dont j'ai vraiment besoin ». [5]
L'un des avantages est la meilleure prise en charge de l'évolution des besoins. Quant aux
inconvénients, ce sont :
le risque de concevoir une solution obsolète avant qu'elle soit
opérationnelle
l'évolution du schéma des données sources,
la complexité de source de données.

).> Approche mixte

Une combinaison des deux approches appelée hybride ou mixte peut s'avérer efficace
dans La mesure où elle prend en considération les sources de données et les besoins des
utilisateurs. Cette approche consiste à construire des schémas dimensionnels à partir des
structures des données du système opérationnel en les validant par rapport aux besoins
analytiques. Par ailleurs, elle cumule les avantages et quelques inconvénients des deux
approches déjà citées telles que la complexité des sources de données et la difficulté
relative à la détermination des besoins analytiques.

6.2- Alimentation du data warehouse

L'alimentation du data warehouse se fait par l'utilisation d'outils ETL décrits dans le
chapitre précédent.

6.3- Mise en œuvre du data warehouse

C'est la dernière étape du projet data warebouse c'est-à-dire son exploitation.


L'exploitation de l'entrepôt de données se fait par le biais d'un ensemble d'outils
analytiques développés autour de ce dernier. Cette étape nécessite donc l'achèvement du

5 "Give me what l tell you 1 want, then l can tell you wbat l really want."(lomon, 2002]

30
développement ou de la mise en place de ces outils qui peuvent accomplir les fonctions

suivantes:

• le requêtage ad-hoc
Le requêtage ad-hoc reste très fréquent dans ce type de projet. En effet, les utilisateurs de
l'entrepôt de données et spécialement les analystes, seront amenés à interagir avec le DW
via des requêtes dans le but de faire les analyses requises par leurs métiers et d'élaborer
aussi des rapports ainsi que des tableaux de bords spécifiques. L'accès à ce genre de
service peut se faire à travers différentes méthodes et outils. Cependant, les spécialistes en
la matière préconisent de laisser la possibilité à l'utilisateur de choisir les outils qui lui

paraissent les plus adéquats.

• le reporting
Destiné essentiellement à la production de rapports et de tableaux de bord, il est la
présentation périodique de rapports sur les activités et résultats d'une organisation, d'une
unité de travail ou du responsable d'une fonction, destinée à en informer ceux chargés de
les superviser en interne ou en externe, ou tout simplement concernés par ces activités ou

résultats.
Ces outils de reporting ne sont pas, à proprement parler, des instruments d'aide à la
décision; mais, lorsqu'ils sont utilisés de manière appropriée, ils peuvent fournir une
précieuse vue d'ensemble. Les rapports sont alors crées par le biais d'outils de reporting
qui permettent de leur donner un format prédéterminé. Les requêtes, elles, sont constituées
lors de l'élaboration des rapports qui seront ensuite diffusés périodiquement en
automatique ou ponctuellement à la demande.

• les tableaux de bord


Les tableaux de bord sont un outil de pilotage qui donne une vision sur l'évolution d'un
processus, afin de permettre aux responsables de mettre en place des actions correctives.

C'est ce que soutient Bouquin en ses termes :


« Le tableau de bord est un ensemble d'indicateurs peu nombreux conçus pour permettre
aux gestionnaires de prendre connaissance de l'état et de l'évolution des systèmes qu'ils

31
pilotent el d'identifier les tendances qui les influenceront sur un horizon cohérent avec la
6
nature de leurs fonctions » [l].

6.4- Maintenance et expansion

La mise en service du DW ne signifie pas la fin du projet en ce sens qu'un projet DW


nécessite un suivi constant compte tenu des besoins d'optimisation de performance et /ou
d'expansion. li est donc nécessaire d'investir dans les domaines comme le support, la
formation et le management de l'évolution.
Ces travaux d'expansion sont à prévoir de façon à faciliter l'évolution du schéma du DW.

Conclusion partielle:

Le concept« Data Warebouse » est apparu comme une réponse à des besoins grandissants
dans le domaine décisionnel. Son adaptabilité et sa capacité de fournir les données
nécessaires à une bonne analyse ont fait de lui un atout majeur et incontournable pour toute
entreprise soucieuse du suivi de ces performances.
Toutefois, la mise en place de ce genre de système nécessite le choix et l'adoption d'une
démarche précise qui doit tenir compte des réalités de l'entreprise et des contraintes du
projet.
L'alimentation en données constitue l'étape à laquelle il faut accorder le plus d'attention et
de temps. En effet, elle est le garant de contenance de l'entrepôt en données fiables et
correctes. Une fois l'alimentation terminée, l'exploitation des données peut alors se faire
par différentes méthodes. L'utilisation d'outil OLAP reste, cependant, l'aspect le plus
intéressant dans cette exploitation qui favorise la navigation dans les données de l'entrepôt
à la demande.

6
« Le contrôle de gestion»; P.U.F; 2003.

32
Au cours de la troisième partie de cette étude, nous essayerons d'utiliser les concepts
présentés ici, afin de mettre en œuvre notre système.

33
Partie II:
Etat de l'art de Système
Décisionnel existant dans
le domaine médical

34
Dans le marché des établissements de santé, les besoins d'outils décisionnels commencent
à émerger. Malheureusement bon nombre en sont à leur premier projet ou pas du tout.
Néanmoins, au vu de l'intérêt de ce marché, les éditeurs et les intégrateurs de solutions
logiciels tendent à se développer.
Contrairement à certains qui sont très répandus et faciles à référencer d'autres se font
beaucoup plus discrets sur la toile. Les outils proposés par ces acteurs peuvent être classés
selon deux grandes catégories :
• les suites logicielles dites « blanches». il s'agit des outils du marché qui s'adresse
à n'importe quel domaine d'activité pour lesquels une modélisation spécifique des
données au niveau médical est nécessaire.
• les solutions dites «pré-packagées ». Il s'agit de solutions déjà modélisées selon
une logique choisie par l'éditeur spécialiste santé. li s'agira seulement de les
paramétrer et les « brancher » sur le SIH. Les solutions dites «pré-packagées »
comprennent en général un choix de tableaux de bord, un ensemble d'indicateurs
pré formatés et des fonctionnalités diverses qui sont très variables d'un éditeur à

l'autre.

NB: A côté de ces solutions citées, nous avons le monde Open Source avec des acteurs tel
que Pentaho qui propose des suites décisionnelles complètes. Les systèmes Open Sources
ont le même fonctionnement que les solutions dites blanches.

1. Différences entre les deux approches

Pendant que les éditeurs de solutions blanches souhaitent entrer sur ce nouveau marché où
des besoins existent, les éditeurs spécialistes santé, eux, tentent de développer un avantage
concurrentiel en proposant des solutions décisionnelles. On observe ainsi :
une orientation vers le développement de solutions pré packagées Santé ;
des tarifs qui commencent à s'adapter à la taille de l'établissement (nombre
d'utilisateurs, budget).
Le tableau ci-dessous synthétise les avantages et les inconvénients des deux catégories de

solutions:

35
Avantaaes
SolutJon blanche Forte évolutlvlté
Richesse des Budget elevé
fonctionnalités (investissement
disproportionné si le
périmétre du projet est trop
restreint)

Solution Foc1hte de mise en ceuvr 01fficulle a creer des rapports


d1fferents de ceux predefims
pré-packagée (nouveaux développements -
coüt+déh)o
Risque de statu quo (voie
sans issue du SID)
Peut repondre aux besoins t,lodeles de donnees plus ou
reglementasres ( comptabrht moins ouverts
analyttque. T2A ) de manier
utomotique Flexibilité souvent très
réduite
Budget limité (sous réserve
de l'intégration)

Tableau 2. Tableau comparatif des avantages et inconvénients des solutions blanches


et pré-packagées.

Source: GMSIH, Systèmes d'information Décisionnels dans les établissements de santé:


analyse de l'offre éditeur au 31/07/2007, pp9/163.

2. Les éditeurs des différentes solutions

Nous allons présenter brièvement Les plateformes de quelques éditeurs ou prestataires


d'outils décisionnels en milieu médical. Cette liste, il faut le dire, n'est pas exhaustive; elle
n'a pas, non plus, la prétention d'être critique. Elle permet tout juste de renseigner sur
l'existant du marché mondial.
Selon une étude effectuée par le GMSIH (Groupement pour la Modernisation du Système
d'information Hospitalier) en 2007, on peut identifier les plateformes de quelques éditeurs
des différentes solutions citées plus haut.

2.1- Solutions blanches

Elles comprennent entre autres Business Objects, Cognos, Microsoft et Oracle qui sont les
leaders du décisionnel.

36
• Business Objects
Leader des solutions de progiciel intégré (ERP, Enterprise Ressources Planning), SAP
AG était curieusement quasi absent du monde de La Business Intelligence. Mais, avec Le
rachat de Business Object en 2008, SAP AG a suivi Le mouvement de concentration mis en
action par les autres éditeurs majeurs comme Oracle ou IBM. Au titre des produits de
référence pour le domaine médical, il n'existe pas de modèle spécifique santé, mais ces
produits peuvent être utilisés pour La conception d'application en ce domaine.

• Cognos
Avec le rachat du canadien Cognos en 2008, IBM Corp. est devenu un acteur majeur du
secteur de La Business Intelligence car Cognos était un Leader des solutions de reporting.
Avec ce rachat, IBM peut enfin proposer une gamme complète de solutions performantes
orientées post-utilisateur (reporting, analyse, planning, budgétisation ... ).
Au titre des produits de référence pour le domaine médical, aussi, il n'existe pas de
modèle spécifique santé; par contre on peut utiliser ces produits pour concevoir des
applications 81 pour le domaine médical.

• Oracle
Hyperion Solution, éditeur historique de la Business Intelligence, spécialiste des
solutions de gestion financière et de planification a été racheté par Oracle Corp. en 2007.
D'ailleurs, les solutions technologiques d'Oracle Corp. couvrent aujourd'hui l'ensemble du
processus d'aide à la décision et de management de la performance.
Produits de référence pour le domaine médical, il en existe, mais ceux-ci sont
développés en partenariat avec Keyrus et All Sbare, qui sont des prestataires indépendants
supportant plusieurs socles décisionnels.

• Microsoft
Malgré l'arrivée tardive de Microsoft Corp. sur le marché de la Business Intelligence,
Microsoft Excel reste encore aujourd'hui l'outil le plus utilisé pour les applications

décisionnelles.

37
Produits de référence pour le domaine médical, il n'existe pas de modèle spécifique
santé, mais on peut utiliser ces produits pour concevoir des applications BI pour le

domaine médical.

2.2- Solutions pré-packagées

La vision produit considérée en 2.1 ne suffit plus à répondre au besoin de pilotage. Ce


changement explique l'arrivée sur le marché de nouveaux acteurs offrant des services
autour de l'informatique décisionnelle en santé. On peut citer entre autres KEYRUS, en
Santé, QlikView. SPlH.

• KEYRUS
Présent sur le marché depuis plus de 15 ans, Keyrus est identifié comme le partenaire le
plus reconnu parmi les plus grands éditeurs du marché de la BI tels SAP, Oracle,
Microsoft, IBM ainsi que les nouveaux acteurs comme QlikTech et Open source.
L'approche ici n'est plus autour d'une solution, mais elle s'inscrit dans le cadre d'une
mutualisation autour de diverses solutions.

• CTJ Santé

Société de services créée en 2004, en Santé s'est spécialisée dans la création de logiciels
de pilotage d'établissements de santé. Sa stratégie BI consiste à proposer un infocentre
basé sur les technologies Web standards et à forte valeur ajoutée« métier». Quoi qu'il en
soit, cette approche est à l'inverse de ce que propose la solution Qlik.View.

• Qlikview

La plate-forme Qlikview de QlikTech est une véritable expérience de 81 libre qui permet
de prendre des décisions innovantes. Elle est celle qui connaît aujourd'hui. le
développement le plus fort sur le marché du décisionnel de santé. En effet, sa popularité est
liée à son mode de diffusion via un partenaire tel que Maya Business Solutions qui ne
compte pas moins de deux cent cinquante (250) références en quatre (04) ans d'existence
(source: magasine MySih, num 004 pl2).

38
• SPIH

Le SPlH (Système de Pilotage Hospitalier) est la solution par laquelle Le produit


LiveDashBoard de Prelytis s'est fait connaître. C'est une solution pré-paramétrée conçue
par trois (03) partenaires apportant leur expertise «métier» au setvice des établissements
de santé; ce sont Stream Consulting, Prelytis et IBM.

•!• Etude descriptive

Aux vues des avantages et inconvénients des différentes solutions présentées en l. (à la


page 3 5), notre étude s'est basée sur la présentation des produits de références pour chaque
éditeur. Cela est consigné dans le tableau suivant:

Editeurs Produits de références

• SAP Crystal Reports Dashboard

Business Objects Design ( anciennement Xcelsius)


permet la création de rapports de
type dashboard.

• OLAP Analyse

• Webl permet aux utilisateurs, à


travers des environnements
prédéfinis, de créer leur rapport et
tableaux de bord de façon autonome.

• Cognos Business Intelligence

Cognos Fonctionnalités traditionnelles de la


BI+ fonctions de planification, de
modélisation, de scénario et
d'analyse prévisionnelle. C'est un
outil collaboratif.
Gamme complète de produits de
Reporting, Analyse, Scorecard et

39
tableaux de bord BI

• Cognos Express
Spécial PME : Solution complète et
modulaire de pilotage de la
performance

• Cognos lnsight
Tableaux de bord universels

• Cognos TMl
Planification, Elaboration de
budgétaire, Modélisation,
Simulation. Analyse en temps réel.

• Cognos FSR
Reporting rfinancier, ( officiel)

• Oracle Essbase

Oracle Serveur multi dimensionnel de


données, un produit historique en
matière d'analyse dimensionnelle
conçu à l'origine par Arbor Software
avant d'être racheté par hyperion
Solution.
• Oracle Business Intelligence Suite
Enterprise Edition
Connu sous l'acronyme OBI EE
Plus, ce nom générique ne couvre
l'ensemble des solutions de Business
Intelligence issues principalement
des gammes Siebel et Hyperion.

• Oracle Hyperion Financial


Management
Application Web de consolidation
financière, analyse et reporting.

40
• Oracle Enterprise Performance
Management (EPM)
Disponible aussi en mode "Cloud",
délivre les fonctions d'aide au
pilotage stratégique, budget,
planning, prévision, reporting,
gestion des coûts ...

• SQLServer
Microsoft I Le serveur de base de données
SGBD phare de la marque. Un
virage radical a été pris dès la
version SQL 7, avec l'intégration
d'outils d'analyse
multidimensionnelle de type OLAP
au sein même du produit de
référence.
• Office Performancel'oint Server
• SharePoint Server
• PowerBlforO.lfice365
• Excel
Au fil des versions, Excel devient un
véritable outil de Business
Intelligence, tout à fait à même de
gérer de grandes quantités de
données.

Le groupe Keyrus a développé deux


Keyrus I solutions pour répondre aux besoins des
établissements de santé :
• K@PRlM : composant standard
d'origine centré sur l'activité

41
PMSI
Les utilisateurs réalisent leurs propres
interrogations des données PMSI via
des univers d'indicateurs métiers et
des rapports préétablis : répartition
par GHM, valorisation des séjours par
Unité Médicale, par CCAM, par
GHS, Case mix, CIM 10 ...
• K@PRIM + : composant étendu
traitant la comptabilité analytique
et budgétaire
Cette offre comporte deux modules
compatibles et autonomes : l'un pour
la comptabilité analytique hospitalière
(CAH), l'autre pour l'élaboration et la
planification budgétaire.

• CTI-Santé
CTI Santé

• LiveDashBoard

• SPIH (Système de Pllotage


Prelytis Hospitalier) basé sur le produit
généraliste LiveDashboard en
partenariat avec lBM et Stream
Consulting
• Qlikview:
QlikTech une véritable expérience de BI en
libre-service qui permet de prendre
des décisions innovantes.

Tableau 3. Etude descriptive des solutions BI médicales

42
3. Choix et iustification

Après avoir référencé les éditeurs ci-dessus, notre choix d'outils s'est porté sur ceux des
solutions blanches, en particulier la suite décisionnelle de Microsoft pour diverses raisons.
En effet, ce qui amenait hier à choisir Oracle ou IBM plutôt que Microsoft, c'était avant
tout la fiabilité de leurs moteurs respectifs pour les applications critiques et la recherche de
la performance sous la contrainte de fortes volumétries. Compte tenu des solutions mises
en œuvre en termes de tolérance de pannes et du saut qualitatif des moteurs de base de
données, La valeur d'un moteur semble aujourd'hui se faire, à titre principal, sur certains
usages. A priori, le choix d'un moteur se fait aujourd'hui sur La qualité des outils en vue de
l'administrer au quotidien. De ce point de vue, Oracle n'aura pas réussi à fournir des
Logiciels de la simplicité et de La qualité de ceux proposés par Microsoft. Pour administrer
une base Oracle, il faut utiliser au moins quatre logiciels différents; ce qui n'est pas le cas
de Microsoft. Pour administrer Microsoft SQL Server 2008 par exemple, tout se fait à
partir d'un seul logiciel à savoir SQL Server Management Studio (SSMS). En outre, la
force de Microsoft SQL Server 2008 réside aussi et avant tout dans le coût, la simplicité et
la qualité de ses solutions de Business Intelligence. Avec une Licence SQL Server,
l'utilisateur peut accéder aux rapports générés par SQL Server Report Services (SSRS). A
partir d'Excel 2010, il peut aussi facilement se connecter aux cubes générés relatifs au

SQL Server Analysis Services (SSAS).


11 est important de souligner que les Licences pour utiliser les logiciels concurrents d'IBM
et de SAP, c'est-à-dire Cognos et Business Objects coûtent plus de 1000 euros par
utilisateur. Toutefois, si Microsoft continue de progresser fortement dans le segment des
moteurs de base de données, c'est parce qu'il propose une solution intégrée, simple et peu
onéreuse en matière d'informatique décisionnelle par rapport à ses concurrents directs.
C'est d'ailleurs ce qui justifie notre choix des outils.

Comme on peut le constater, à travers la présentation de toutes ces approches


diamétralement opposées, Le retard du secteur de la santé en matière de BI est dû à la

qualité des données initiales.

43
Partie III :
Modélisation- Réalisation-
Exploration du système

44
Chapitre 1 : Modélisation du Système

La conception d'un entrepôt de données est une tâche complexe et délicate. Elle se
compose de plusieurs étapes. La première étape consiste à analyser l'ensemble des sources
de données internes et externes. Cette analyse sert aussi bien à la sélection de l'ensemble
de données à stocker dans l'entrepôt qu'à la sélection des outils requis pour l'extraction et
la transformation de ces données avant leur stockage. A la deuxième étape, il s'agit
d'organiser ces données à l'intérieur de l'entrepôt. Pour ce faire, nous devons concevoir le
modèle dimensionnel à utiliser et définir l'ensemble optimal de vues à matérialiser. La
troisième étape consiste à déterminer les outils nécessaires pour la visualisation de
l'ensemble des données.
En ce qui concerne la conception du modèle dimensionnel à utiliser, il est important de
noter que c'est en général au cours de cette phase que s'appliquent les techniques de
modélisation. Il en découle la description de l'entrepôt de données à créer, les programmes
à écrire et la manière dont tout cela va être intégré.

1- Les techniques de modélisation

La modélisation est l'art de créer une surface qui imite la forme d'un objet du monde réel
ou correspond à notre vision d'un objet abstrait. Cette phase est primordiale dans tout
projet informatique; elle comporte trois grandes phases qui sont :

la phase d'analyse ou de conception


Durant cette phase, on effectue simultanément l'étude des données et l'étude
des traitements à effectuer. C'est ici que s'appliquent les techniques de
modélisation. il en découle la description des bases de données éventuelles
à créer, les programmes à écrire et la manière dont tout cela va être intégré.

la phase de réalisation
Elle consiste à écrire et à tester des programmes.

45
La phase de livraison
Elle s'appuie sur la validation. La phase de livraison est l'opération destinée
à démontrer, documents à l'appui, que notre application mise en œuvre
conduit effectivement aux résultats escomptés.

L'essentiel de notre travail a reposé sur la phase d'analyse, en ce sens qu'à l'instar de tout
projet, notre projet Business Intelligence est destiné à des utilisateurs. C'est pourquoi il est
impératif pour nous d'être à l'écoute de ces derniers afin de cerner avec précision leur
besoin; cela commence par l'étude de l'existant.

Par ailleurs, dans le cadre de notre recherche, nous avons été au Ministère de La Santé et
de la Lutte contre Le Sida afin de nous renseigner sur l'effectivité d'un existant de
plateforme décisionnelle dans le domaine sanitaire ivoirien. En effet, Lors de nos
différentes rencontres avec le service informatique dudit ministère (DIPE), nous avons
constaté l'existence de ces logiciels seulement, ils n'ont pas encore été déployés pour
diverses raisons. Ces logiciels sont:

la Slli Santé (technologie Huwei),


la Télémedécine,
l 'OpenElis pour la gestion des laboratoires
la SigDep pour gérer les données électroniques ; elle est en phase
expérimentale dans les cliniques et polycliniques au niveau national,
la DHlS 2 en phase expérimentale au sein de La DIPE.

Pour ces différentes raisons évoquées. L'étude de l'existant sera inexistante ou absente

dans notre travail.

En outre, il existe plusieurs méthodes d'analyse ou de conception en système


d'information. Mais, nous nous intéresserons à la méthode standard MERISE et au
langage UML parce qu'ils sont les plus utilisés aujourd'hui.

46
1.1. Méthode MERISE

Dans la méthodologie MERISE, le processus de développement du modèle de données


implique l'analyse des types de doooées qui auront un sens dans le SI ainsi que les
relations entre les différentes doooées de ce système. MERISE est, en effet, une méthode
d'analyse, de conception et de gestion de projet informatique. Son but est donc de
concevoir un système d'information.

Dans les premières phases du projet de développement du logiciel. il faut faire ressortir
l'étude d'un modèle conceptuel de données (MCD). Celui-ci peut être détaillé dans un
modèle logique de doooées (MLD) quelquefois appelé modèle organisationnel de données.
Dans des phases ultérieures, ce modèle peut être traduit en un modèle physique de données

(MPD).

En résumé, la méthode MERISE préconise d'analyser séparément les données et


traitements, à chaque niveau.

1.2. Langage UML

L'UML (en anglais Unified Modeling Language), ou Langage de modélisation unifié est
un langage de modélisation graphique. 11 est utilisé en développement de logiciels et en
conception orientée objet. L'UML est couramment utilisé dans les projets logiciels.

Cependant, parce qu'il n'est pas une méthode, son utilisation est laissée à l'appréciation de
chacun, bien que le diagramme de classes soit généralement considéré comme l'élément
central de l'UML. En outre, des méthodologies comme le processus unifié (PU) (en anglais
Unified Process) axent a priori l'analyse sur les diagrammes de cas d'utilisation (Use Case).
L'on peut même se contenter de modéliser uniquement ou partiellement un système.
L'UML se décompose en plusieurs sous-ensembles:

• Les vues sont les observables du système. Elles décrivent le système d'un point de
vue donné, qui peut être organisationnel, dynamique, temporel, architectural,
géographique, logique, etc. En combinant toutes ces vues, il est possible de définir
ou retrouver le système complet.

47
• Les diagrammes sont des éléments graphiques. Ils décrivent le contenu des vues
qui sont des notions abstraites. Les diagrammes peuvent faire partie de plusieurs
vues.
• Les modèles d'élément sont les briques des diagrammes UML; ces modèles sont
utilisés dans plusieurs types de diagrammes. Nous pouvons noter à titre d'exemple
d'élément le cas d'utilisation, la classe, l'association, etc.

Il est important de noter que le data warehouse est dé-normalisé, c'est-à-dire qu'il ne suit
aucune des formes normales. De ce fait les techniques standards Merise et UML ne
pourraient nous aider à concevoir notre entrepôt de données. C'est une base de données
destinée uniquement à la lecture; ainsi, il. ne fera pas l'objet d'une opération d'insertion
de modification ou même de suppression. Parmi les différentes techniques de
modélisation que sont MERLSE et UML, nous avons retenu, pour la modélisation du data
warehouse, MERlSE dans la mesure où, en utilisant le MCD, cette dernière favorise une
conception claire et précise de notre entrepôt de données.

2. Modèle Conceptuel des données du système

A l'aide du logiciel PowerAMC TM 15.1, nous avons réalisé le MCD qui nous a permis
d'aboutir au schéma en étoîle ci-dessous. PowerAMC est un logiciel de conception créé par
la société SDP, qui permet de modéliser les traitements informatiques et leurs bases de
données associées.

La conception d'un modèle dimensionnel passe par cinq étapes essentielles :

• le choix de l'activité à modéliser, s'il en existe plusieurs. Ce choix se fait


après un classement des activités dans une matrice dite d'analyse des
priorités. Cette matrice permet de connaître quelle activité choisir en

premier.
• la définition de l'activité et de son gain,
• La définition des dimensions qui décrivent une Ligne de la table des faits,
• la définition des mesurables du fait

48
• la définition des agrégats.

Dans notre cas où il existe une seule activité à savoir « la consultation médicale », le
choix est déjà fait.

2.1. Activité« Consultation médicale»

Une consultation médicale est un examen d'un patient réalisé dans un cabinet médical ou
un centre hospitalier par un médecin pouvant conduire à des actes techniques, des actes
d'investigation, des actes d'éducation, des actes de prévention. Lors d'une consultation, le
médecin émet un avis sur les symptômes ressentis par le patient, afin d'établir un
diagnostic, donner des conseils, prescrire une ordonnance, identifier un cas de maladie
établir un protocole de soin etc ...

C'est aujourd'hui que demain se prépare dit l'adage. Ceci est la devise de toute nation et
surtout la Côte d'Ivoire, qui se veut émergente à l'horizon 2020. Or cette émergence, il faut
le dire, ne peut se faire qu'avec une population en bonne santé. D'où, l'intérêt grandissant
pour l'Etat ivoirien à investir dans des programmes de santé publique sur la base des
informations recueillies auprès des directions départementales de santé sur tout Je territoire
ainsi que dans les différents centres hospitaliers respectifs. Ces informations recensées au
cours des différentes consultations sont relatives au nombre de personnes atteintes d'une
maladie et à la tranche d'âge concernée. Tout ceci désigne des indicateurs qui sont des
données très importantes pour les décideurs dans le domaine médical.

Toutefois, le niveau de détail le plus bas aux différentes consultations correspond à la


consultation elle-même qui permet d'identifier les patients d'une maladie afin d'apporter
une solution dans l'éradication du mal; c'est d'ailleurs ce qui est à l'origine d'une ligne de
la table des faits qui permet à son tour d'établir :

Un suivi du nombre de personnes atteintes d'une maladie au cours d'une consultation


vivant et/ou exerçant un métier donné dans une commune à une certaine date.

49
~,i.,rnuf1e v~,_.~,e<t,55) <O>
!~)

o.

Jltf

- eneautl'lt

1.

Figure 10. MCD du système

2.2. Les dimensions participantes du modèle

Les dimensions ont pour objectif de décrire le fait. C'est pourquoi il est nécessaire de
recenser toutes les informations qui décrivent une consultation; et en cela celles qui
peuvent intéresser les décideurs.

2.2.1. Dimension« Time 1 »

La dimension Temps est la seule dimension qui figure dans tout entrepôt de données.
Selon Kimball, l'un des pères fondateur du DW: « Le temps est le plus souvent la
7
première dimension dans le classement sous-jacent de la base de données » (8] .

7« Entrepôts de Données : Guide Pratique de Modélisation Dimensionnelle 2ème édition »,


Vuibert 2002.

50

1
Contrairement aux autres dimensions, la dimension Temps contient uniquement des dates
qui ne sont pas forcément extraites à partir des systèmes sources. Cette dimension doit
contenir, en effet, toutes les dates qui coïncident, ou coïncideront. avec un fait donné. Cela
pour assurer I'historisation. Et elle peut se charger automatiquement dans SSAS à partir de
la création d'une nouvelle dimension temps ou sous SSIS comme les autres dimensions.
Nous reviendrons sur cette dimension dans le chapitre suivant.

2.2.2. Dimension «DWD1MPROFESSION»

Souvent la maladie d'un patient peut être liée à la profession qu'il exerce. D'où la
nécessité d'utiliser celle-ci comme un axe d'analyse. Cet axe est présenté par:

Figurell. Dimension « DWDIMPROFESSION»

Pour évaluer les facteurs de risque professionnels dans le cadre de pathologies courantes
afin d'ajuster les pratiques thérapeutiques et préventives selon les conditions de travail du
patient, il est très important de connaître la profession du malade. Voici comment est
présentée la dimension « DWDIMPROFESS10N».

Désignation Détail

ldDWProfession La clé de la dimension «DWDIMPROFESSlON»

Profession Le libellé de profession

Tableau 4. Tableau descriptif de la dimension «DWDIMPROFESSION»

51

1
2.2.3. Dimension «DWDlMSEXE»

La dimension « DWDIMSEXE » décrit le genre du patient à une consultation. Le sexe


permet de savoir les maladies liées à un genre en particulier.

Figure 12. Dimension « DWDlMSEXE»

Désignation Détail

ldDWSexe La clé de la dimension « DWDIMSEXE»

Sexe Le genre du patient

Tableau S. Tableau descriptif de la dimension «DWDlMSEXE»

2.2.4. Dimension « DWDlMMALADlE»

La maladie demeure le point central de la consultation. En effet, la présence de tout


patient à une consultation médicale est justifiée par un mal qu'il traine depuis peu ou
qui lui est apparu brusquement; d'où l'importance pour ce dernier de voir un médecin.
La dimension DWDIMMALADIE se présente comme suit:

Figure 13. Dimension « DWDlMMALADlE»

52
Désignation Détail

ldDWMaladie La clé de la dimension« DWDIMMALADIE»

Maladie Le nom de maladie

Tableau 6. Tableau descriptif de la dimension «DWD1MMALADIE»

2.2.5. Dimension« DWDIMHAB1TAT10N»

Le lieu où l'on habite est souvent la source de plusieurs maladies. Par exemple, lorsque
nous nous référons aux habitants des quartiers précaires en Côte d'Ivoire, nous nous
rendons compte que le taux du paludisme est élevé. Cela est dû au manque d'hygiène
dans ces quartiers qui abritent de grands nids de moustiques. Tout ceci pour dire que
l'habitation est facteur important à prendre en compte. La dimension
DWD1MHAB1TAT10N est présentée ainsi:

Figure14. Dimension« DWD1MHAB1TATION»

Désignation Détail

ldDWHabitation La clé de la dimension« DWDIMHABlT A TION»

Commune La commune où habite un patient

Ville La ville où se trouve la commune

Tableau 7. Tableau descriptif de la dimension «DWDlMHABlTATION»

53
2.3. Les mesures

Les mesures qui correspondent à la table des faits «DW FAlTCONSULTATlON» et qui
permettent de mesurer les performances de celle-ci concernent l'âge en année «
AgeAnnee » et l'âge en mois« AgeMois ».

2.4. Schéma en étoile de la consultation médicale

Les clés étrangères de la table de fait se réfèrent aux dimensions qui représentent le

contexte du fait.

Figure 15. Schéma en étoile de la consultation médicale

La zone d'entreposage constitue la zone exploitable par les utilisateurs. La modélisation


de cette zone se fait grâce à la modélisation dimensionnelle. Cette manière de représenter
les données offre aux utilisateurs des modèles intuitifs et compréhensibles qui permettent
facilement de naviguer et de manipuler les données (détaillées ou agrégées) dans le but de
satisfaire leurs besoins en analyse.
La finalisation de la conception d'une étoile de l'entrepôt, nous permet de passer à la
construction de la zone d'alimentation. Cette zone d'alimentation constitue, d'ailleurs,

l'objet du prochain chapitre.

54
Chapitre 2: Réalisation et alimentation de l'entrepôt de données

L'alimentation de l'ED est une étape très importante dans un projet DW ; elle représente
70% de la charge de travail. Cette étape a pour objectif d'assurer l'acheminement des
données des systèmes sources jusqu'à l'entrepôt de données, en passant par les différentes
phases de nettoyage et de transformations nécessaires. La conception du processus
d'alimentation nécessite les étapes suivantes :
• l'étude et planification,
• la conception des processus de chargement qui contient à son tour :
le processus de chargement des tables de dimension
le processus de chargement des tables de faits
le processus de chargement de table temps.
Mais, il est important de souligner qu'en réalité les données ne transitent pas directement
des systèmes sources vers l'entrepôt de données. Elles passent par une zone de transit
appelée le sas des données ou Staging Area (SA) en anglais. Nous l'appellerons
StagingArea dans notre cas. Cette base de données sera fournie en annexe à la page ...
A ce titre, nous pouvons utiliser ce schéma pour illustrer nos propos relativement au

chargement:

BDPatients

Oatawarehouse OLAP
/ Stag,igArea
BD Maladie

Figure 16. Architecture de chargement des données

55

1
Les différents rôles du SA consistent, entre autres, à :
- rapatrier les informations émanant de sources multiples, en garantissant qu'il n'y ait pas
de pertes de données lors de ce processus.
- faire une zone mémoire tampon d'un état brut de la source pour faciliter la mise en œuvre
d'un processus de reprise de données. Autrement dit, avec cette zone tampon il n'est plus
nécessaire de revenir dans les systèmes sources pour faciliter le processus de reprise des
données.

La mise en place d'un SA est donc une étape indispensable à la bonne mise en œuvre des
flux ETL. Son usage est d'ordre pratique en ce sens qu'il permet l'étape suivante qui est

celle du DW.

1. Etude et planification

Cette phase représente une phase préliminaire à l'ensemble du processus. Elle consiste en:
l'étude des sources de données
la détection des emplacements des données source,
la définition de la périodicité du chargement.

1.1. Sources de données et emplacement


Les sources de données de notre entrepôt sont :
BDPatients sous Access,
BD _Maladie sous SQL Server.

1.2. Périodicité du chargement


Avant de décider de la périodicité du chargement, les contraintes suivantes doivent être

prises en considération à savoir :


• la quantité de données à charger et
• le temps de non activité ou l'inactivité des systèmes sources.

En termes de volumes, bien que La quantité de données de nos différentes sources ne soit
pas élevée, l'idéal pour nous serait de procéder à un chargement quotidien pendant les
heures auxquelles les systèmes sources sont inactifs.

56

1
2. Conception des processus de chargement

Le diagramme d'activités suivant décrit le processus général du chargement de l'entrepôt


de données:

CtwfQaffle"I non .-.1b

Figure 17. Diagramme d'activité du processus de chargement

Les chargements des différentes tables se feront à l'aide de l'outil ETL SSIS de
Microsoft.

~ ETL SS1S de Microsoft

SSIS (Sql Server lntegration Services) de Microsoft est l'outil qui nous permettra de faire
le chargement des différentes bases de données : le SA et le DW.

On appelle package l'environnement SSIS dans lequel l'on travaille. Il se présente comme
tel:

57
... x h'""-.:~cw•::c:Uatt • 1 ,c
• J ,•• ..,...... io,,ip,t !gdc -·
.J J
~DF"°"'"''' Ï """""" • ..; Qi<a""" 'j td_, •• 'mi),e-« _.,Sl&u;,,,Am

·:--.-n
;, E,tucot, "" ,,

f.,,..,,...,
.J{',aSc.ft.1
..Jt.•• lcnt
_;iW\~"'11"
()~ dl- .,~
-'~'*"'

,,r,.i..,_...,_
__. __
•11~:1t,..,,••••

-'-°''"""
f t•••• :~
.. ,. 8

°"'""'~ .
~ ''"'"'
0:>1€1~
/',O,,,U.,,,,Udol""""i

1
..b ~ -
''-°"'-*'•""'IN
J. D<lnnll>osdtlld9trlla

- -·
i
J °""'"""'•r-,-,.. j 1c,,roo,,- !,,nç,clhat
ie:\la1~
l ~ ••- i•,~'l.',&:1/

Figure 18. Exemple de package SSIS

li est à noter que chaque package à partir de la figure L 8 contient toutes les tâches
d'intégration. Toutefois l'enchaînement des tâches d'un package est orchestré par le flux
de contrôle. Lorsqu'une tâche a pour objectif d'assurer la transformation des données, elle
est nommée « tâche de flux de données ». A 1 'intérieur de cette tâche se trouve, en effet, un
flux de données qui contient au minimum une source, une transformation et une

destination.

2.1. Chargement des tables de la zone de transit (StagiogArea)

• TableProfession

Figure 19. Package TableProfession dans SSIS

58

1
• TableConsultationMedicale

Figure 20. Package SACONSUL TATION dans SSIS

2.2. Chargement des tables de l'entrepôt de données (DataWarehouse)

• Tables de dimensions

• DWDIMHABITATION

EJ<O'k110ndo domôn do la -
SN<A8!'t ATtO'l d<p.d la booc S,_,..,. •••

Figure 21. Package DWDIMHABITATION dans SSIS


• DIMPROFESSION

Qwoement œ 1a dmenSIOn OrrProfl!SSIOl'I œns 1a ~


04!.,'."larehause

Figure 22. Package DWDIMPROFESSION dans SSIS

• Time_l

59
Dans un entrepôt de données, il y a des tables particulières notamment la table de la
dimension temps et la table d'agrégats. Celles-ci nécessitent un traitement à part lors du

chargement.
Dans notre étude, nous utilisons l'outil SSAS de Microsoft pour générer automatiquement
la dimension Time_l. Le chargement de cette table sera décrit au chapitre suivant (chapitre
3). Il est tout de même important de préciser que c'est lorsque toutes les dimensions sont
chargées qu'on charge la table des faits.

2.3. Chargement de la table des faits

Un flux de chargement des tales de faits possède plusieurs caractéristiques:


il fait suite au chargement et à la mise à jour des tables de dimension
il doit s'assurer avant insertion, des contraintes d'intégrité entre les faits et les

dimensions,
il se charge uniquement en insertion rapide
il possède toutes les caractéristiques d'un flux ETL.

Décrivons le flux de chargement de la table des faits « DWFAITCONSULTATlON»:

Figure 23. Package DWFAlTCONSULTATION dans SSIS

60
Une fois l'alimentation des différentes tables terminée, nous pouvons faire des analyses et
naviguer dans les données.

61
Chapitre 3 : Exploration des données du système

Pour faciliter l'analyse et la navigation dans les données, il est important de concevoir des
cubes dimensionnels pour une utilisation intuitive.

La conception des cubes dimensionnels passe par la définition des mesures, des
dimensions et des hiérarchies présentes au sein des dimensions, ainsi que les différents
niveaux de détails de chaque hiérarchie. Le but de la mise en place de ces cubes est d'offrir
une représentation abstraite d'informations multidimensionnelles à des fins d'analyse.
L'outil de la suite Microsoft qui nous permettra de faire ce travail est l'outil d'analyse
SSAS.

)il> Outil d'analyse SSAS

SSAS (SQL Server Analysis Services) est l'outil qui permet de créer et gérer des
structures multidimensionnelles et des modèles d'exploration de données.

1. Conception du cube muJtidimensionnel

• Génération de la dimension Time_l dans SSAS

Nous utilisons l'assistant de dimension de SSAS en observant les étapes suivantes:

Créer le projet SSASTemps

62
Typos de ptoJ.U : Modcld:
84.dinH s lntd lfg~nCJt Project'i tJlc.d d6 V,su•I St:uct.o ,nsu!lu
Autlü ~'ll~ M prCJd:s: Anoiys,<5e,v,cos Pr"Ojttt ••. .,Jlmpcrt A.nt~-' ~tees Oeta.tu~
4 lntegrat,on S.Cr..n.c~ (c,uo,tdtOJ"K. PrcJ•- ,:;\lntc-gubcn S..V..c.,ç P,c,ect
,..J R.rport s«rva ProJttt 'llf,:Md 7JR.~port Modrl ProJe<t
Repo.rt Se~r ProJ«ct

• \ PMC,DW'ÏI-
C:\Use,sV.SSŒ\Oec<kloP'l.1:uTER\Bd

Solutton: § une nouvdfc. S,.Olùl.t0n -- - •} .J Cree, I• ,.,p...,cu·e pou, I• l-Clut,on

Nom de wlubcn: An•lyus s~M«S: ProJectl

Figure 24. Création du projet SSASTemps

Sélectionner la méthode de création


l

s.i.ct Creatlon Method


Vou c•n b-•-.c- thor d•m c-n s,o~ on.,., ~-,st•ns, t•bhr or 51._..,..••••• • ne- t•blir es the ~ourc:c-

H DYY w ou ld you h.k.c lo cr~•tir th e d,mtrut.onl

Ge_ner.et111 • ttme t•bf• on the :Serv@.r

T~mpl•te-:

[<None}

O.esc,.,pt:10.n:
C nit.•t.• • n-cw t.,m• d1mens:Îon t•ble ,n t.h:e: und«.rty,ng d.at.e s.ource.. "Th• d,men"1ion w,11 cont..ln det.• for t.he
d.ale r.ngt,. att:nbut~.• and cal•nd.•rs. you s-pe:c,fy, Vau must hav• per·rn,~s,on to ctt.•lr• obJect.s. ,,, 1:he
undcrlyu"Sf d.-t• $-out<e .•

~~ [ Suw·ent > ]
Annulet-

Figure 25. Création d'une dimension Time_l à l'aide de l'assistant SSAS

Définir les périodes

63
D e fln • Tlm • Periods
Sele<t. the: tim e pfflod.s to use ~he-n gtnarating the h1•r•rchies..

jeudi 31 dé-ce.tnbte 2015

F,rst d.y of the- wee_lc:

Timc pfflod.s.: LJ v •• ,
H•H Ve•r

I l,J
Qu•rter
T r1mest a
M onth
Ten Oays
J \."Veck
J Oat·e

Lengu•gc. for tim c. mvnbe:r n..a m es: 1 Français {fr-ence) •J

< Précédent ] ( Surv•nl > ~nule:r

Figure 26. Définition de la période

Sélectionner le calendrier

Il contient plusieurs types de calendrier en fonction de l'activité gérée. Dans notre cas,
notre choix est le calendrier régulier.

Select Calend•rs
Select the calend•rs for '°""hich yo..,. v.,ant to cre.•tc h1cr•rchies.

J Regul .•. r c.alenda.fo

Report1n9 (or m •rlcct,ng) c.•lend•r

..
.tSO 8601 c.•lc:nd•t

• P,,Ec:bt.,..1 ) ( s..iv- > 1 Annulet'


J
Figure 27. Sélection du type de calendrier

64

1
Générer les attributs

Completing the Wiurd


Type: a name. for the neow d,me.rn;,cn.. v~rtfy the. d,mens,on !ôtructute., and then chclc. f,n,sh to
savt the- dime..n,ion.

Name
Tom~..l

P-rev1evw.

-. k:: Time_l
- ...J Attributes
.,. D•t-e
•• Ve•r
Tnmuter

.... Wttk
Day Of Yeu
Day Of Tnmutcr
•• OayOfWcek
:: Weck Of Yur
•• Tnmcste-rOfYur
k:: H,crarc.h , es
• ::~ Yur • T rrmestcr • Date

L • •. .:,. Vear • We~k • D•te

Figure 28. Génération des attributs

A travers les différentes étapes ci-dessus citées, nous pouvons dire que la dimension
time_l est remplie automatiquement. Par ailleurs, une requête sur cette table générée dans
l'entrepôt de données« DataWarehouse » permet de voir les enregistrements suivants:

AS'ilE-PC.Ollll'll-1),q.wnSEXIMOO SQ!.~l.sql · (LE-~ Oll)' AS.SŒ·~~ SQIQ,,o,y~ · IU·l'OASSII CS4ll'


- . )(
_j
.ol•:t t:a,: !I.U-~

"'

Yu y..,,_,,.,,,, r••••..•. • Tlll!>eler_llr.>t Wt:t!<


Cdcrda, XII 11 2011~1<1 !X oooc OC')
û1end,, 2011 2011~1-CHlCOOOOOOO W·
Cai,ndy 2CII
c.ien;,xn
Colw,c!r1'11
Tltnè>/. J.inJ.yl Œ Ziil 1 c...r.dY~l
.Jrur,-C-2!:ll ùi<nia-2CII ::..i.2 2:111
Sm.da)· JoN., yCl2011 c.:.,,.;,..z;11 ::..,;,.2.1.ill
Su-.:.,y Jaow-,CS1G11 Cè-d Y2ll11 0 l'/oekl~\I -

Figure 29. Visualisation des données de la table Time_l

65
• Présentation du cube multidimensionnel de la consultation médicale

..l;
~ SSASTtmps
iJ tJ . ti ,f .J - ..J D,u Scurc,s
•:.• O~WardkMt..ik
Mu,i,,s
,:, Dat,W,11thcas<l.ds
)0.IIW•lhut Diu Scum v~.1
C,,•,f.urtaiSU.UT!OI
,
~
._.•......-.. •)Dot1W11thc-.ci,,,
(uh,s
Dot, l'l•ch-..n.et

·-
-•.,,,,.flllWI'_~
..JD,m..,,,cns
..• ,... O't.OU.tlUSITA TIOtl~
~,_r:;_, ••. _ T-Ldim
~O'_fw_t.r. • (l [M'DlMMAlAllŒ,d,m
le: 00,Wf'.Ofill!C)tl d:m
Il OU.IDE.dom
~ "1'"'"9 Sauc!urcs
Pd,s

'~
J o.r.a l~•dll1&t D•ta Wartho<M Cubt
• l[ 0-,',ll~ffl.mATial

1~
• A
:.00-6.• u:·,·:.o·,
• ll !Y,',llW.JUOJ: C-i.A'1.U
• I

' l[ Ol'l!ru H,nw Q,u ~·1.m~,


, l[Tnl Pro1a,. tC,ct,a (n<,,
• ÜDM'lt0"5S l0!1 PrcetssmgMod ~
Prccffll!J9Pnc1 0
Scnpl(Jd!tl'n1F.~
ScnptfmltHlnc ~-.Nuit

1 :.sof 1

Figure 30. Cube multidimensionnel de la consultation médicale

NB: Le cube dimensionnel est une étape très importante dans tout projet DW. C'est grâce
à cet élément que l'utilisateur final pourra utiliser et exploiter au mieux les données
contenues dans l'entrepôt de données de manière correcte et intuitive.

2. Exploration des données

Les données contenues dans le DW sont explorées pour produire les rapports à l'aide de
l'outil SSRS de la suite Microsoft.

)- SSRS (SQL Server Reporting Services)

Reporting Services est un outil permettant de concevoir des reports ou des modèles de
reports. Ce service est intégré à Visual Studio et SQL server. Un report est créé depuis

66
Visual Studio, ou par le générateur de report. Le report est publié sur un serveur Reporting
Services et les utilisateurs pourront visionner ces rapports selon 3 possibilités :
- Directement depuis le portail Reporting Services,
- Depuis des pages WEB appelant les WebServices.

N'ayant pas de licence Sql Server, les utilisateurs auront accès aux rapports directement
depuis le portail Reporting Services. C'est pourquoi nous presentons ces exemples de
rapports dont un qui affiche par Commune et Ville, le genre, le nombre de personnes
atteintes du paludisme et de la fièvre jaune et l'autre celui des nombres de cas par maladie:

Nombre de personnes atteintes par le lieu d'habitation

Fièvre Jaune Paludisme


•1 alad1es 1den1Jfiëes

Figure 31. Rapprot de la consultation médicale

67
Nombre de Cas pa,- maladie

-2 5

F,êv-e _s,un
ladre 1dent1fiée

Figure 32. Rapport Nombre de Cas par maladie de Ja consultation médicale

3. Coût du proiet

Lorsqu'une entreprise se lance dans le décisionnel, celui-ci enclenche un processus


interminable dans la mesure où les besoins évoluent tout le temps ce qui conduit à la
concurrence avec l'arrivée de tout ce qui constitue le cycle de vie d'une entreprise. Le
pilotage de l'entreprise gouvernée par les données devient alors une réalité et il n'y a pas
de retour possible. C'est-à-dire si on se lance dans le décisionnel et qu'on souhaite estimer
son coût, on ne regarde pas le coût sur une année mais sur plusieurs années.

Pour notre travail, les dépenses effectuées sont consignées dans le tableau suivant:

68
Désignation Quantité Pu Montant ( en CFA)

(en CFA)

Machine serveur 1 750000 750000


Licence SQL Server 2008r2 1 l 800 000 1800000
Licence Windows Server 1 244300 244300
Licence Microsoft office 1 86 000 86000

Connexion Internet ADSL 1 mois 30000 30000

MTN
Total 2 910 300

Tableau 8.Tableau du coût du matériel et de logiciel de la mise en place de la solution

69
Conclusion générale

70
Exploiter les données à la disposition des établissements sanitaires afin de leur donner de
la valeur ajoutée, tel est le défi que nous voulons relever à travers le thème de notre

mémoire.

Tout au long de notre travail de conception et de réalisation de l'entrepôt de données, nous


avons essayé de suivre une démarche mixte, alliant Les deux approches connues dans le
domaine du D W, à savoir l'approche « Besoins d'analyse » et l'approche « Sources 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 les systèmes opérationnels de
manière à anticiper sur des besoins non exprimés.

Bien que n'ayant pas des sources de données mises à notre disposition par les systèmes
hospitaliers, la méthode des entretiens avec les différents agents de la santé nous a permis
de constituer les sources de données avec lesquelles nous avons travaillé. Ces entretiens
ont favorisé l'identification de quelques indicateurs qui ont permis de répondre aux besoins

des utilisateurs finaux.

La modélisation de la zone de stockage des données s'est faite à partir des principes de la
modélisation dimensionnelle. Cette modélisation offre une vision claire et une
compréhension intuitive des modèles proposés. C'est pourquoi nous avons proposé un
modèle en étoiles de la consultation médicale.

Quant à la partie d'alimentation de la zone de stockage, il faut reconnaître qu'elle a été,


sans doute, la partie du projet la plus fastidieuse et consommatrice en temps. En effet nous
avons expérimenté les dires des pères fondateurs du DW (Kimball et lnmon) selon lesquels
il faut nécessairement consacrerpLus de 70% du temps de réalisation d'un DW. Cette étape
nous a permis de concevoir et de réaliser à partir de La suite décisionnelle de Microsoft les
étapes d'extraction, de La transformation et du chargement des données.

En absence de Licence Sql Server, le déploiement du cube multidimensionnel pour une


optimisation de données et l'envoi périodique par mail, des tableaux de bord au grand
nombre d'utilisateurs en vue de décisions prévisionnelles n'ont pas été possibles.

71
De tout ce qui précède, nous pouvons dire que ce travail nous a permis d'acquérir une
bonne connaissance de l'environnement médical et de mettre en pratique nos
connaissances théoriques du data warehouse ou des systèmes décisionnels.

Cependant, comme un projet DW n'est jamais complètement terminé, nous pouvons


proposer quelques perspectives et développements notamment :
Suivre le déploiement actuel, recueillir les correctifs et les remarques des
utilisateurs.
Etendre le déploiement de manière à couvrir, à terme, la totalité du territoire
national.

72
Annexes

&Jmenl,Wol
1gncstJqueiM.iladie Dffli.ind!!&amenlkdic
CodeW.ltd
·tkllCom 1• ~ IUll(ons llbtU!Exl,lt(I
CodeUfl.l• 'l Codef.tf,l!d
llbreûs

Mtdt<tn
Y IAilnclAtf,led
llolll.lt<I PresairtMfdicamtnt Mtdioment
l
Sptcaltt YlllllCons l Codel.ltd
8uluu Cansulution
H1111Con1
DàtCons
Codef.l!d
Hbrtlo11PrtSl,ltd '= t;i,d.11<1

Motteons
•• stonlr.r
,-ttabhoonentHosp
.,Y,----,,
CodtftHos
(~
A·,t"Anle<tdtnt
CoOtllill
R.arsonSo<illt
~WnCIMMtd
• llul!Cons
ltllrtllt
Codtflltos (odt,\ntl.ltd •
-l

,.
n
l Ptbtnts
Profes~on 1, 1 CodtPi
y COOtlil'olt11to11
I "'1-
floll
PloftSIIGn , Plenoms ~dt!t,b
O.dlaru i~
Sm 'l Ditll
Dolloolt
TollMII"'

Schéma de la base de données BDPatients sous Access

73
TI raltement
,~htere,t
~Tra!ar61'

TAvoir
vc~ TSituiGeo
Tiralter Î Crté1~ f C~hlatc,eo
V ~Tramt
,, 1 ZettCto
9C~
1 1
(' JJ~
-~ i 1 IlOOlliser
'Modelrans
V C~Trw
~ÎIW
- TMaladie
V~m
t~
u:=

~.

Schéma de la base de données BD Maladie sous SOL Server

74
TablePallent5
9 CodeP•l>ff'lt
SA H ABITATIO N Sexe
V COOEHA8JTATION Codel>rofus>on
COMMl..f'E
vtU..E

TableProfession
TableConsultationMedlcale 9 CodeProfession
V NumCons Professaon

O.teCons
Co<S&at>er>t \CX>
Sexe
ProfHsaon
H.t>otabOn
TableMALADIE
Malade
9 COOEMALAOŒ
A9CAnnee
NOt+IAI.AOlE
Il

Base de données StagingArea

ASSll-PC.OabW- DiagnmSEXlMOO SQL~249' - (L..IE-PC\ASSIE (!lW


DWDIMMAI.ADIE
9 100\'.'MAI.ADIE

DIMSEXE
9 IDO\'ISEXE
Sex~

DWFAITCONSULTATION
1DOY,1'R~Ofl
IDO\ 'n,IALADIE
DWOIMHABITATION DIMPROFESSION
9 100','IHABITATTON IOOWT8"'5
9 CodePl'or,,sSIOn
Cc:ir+!U'E IDOWSElŒ
Pro~
YU.Lf
IOOWHA8lTATION 1
AGE.Ali& l
AGEMOlS

Base de données Data Warehouse

75
O.H8
(crnr,nl

Exemples de package de mise à jour

76
•!• Définitions

./ Data mart: Un Data mart (littéralement en anglais magasin de données) est un


sous-ensemble d'un DW destiné à fournir des données aux utilisateurs, et souvent
spécialisé vers un groupe ou un type d'affaire. Techniquement, c'est une base de
données relationnelle utilisée en informatique décisionnelle et exploitée en
entreprise pour restituer des informations ciblées sur un métier spécifique,
constituant pour ce dernier un ensemble d'indicateurs utilisés pour le pilotage de
l'activité et l'aide à la décision.

./ Indicateur : Un indicateur est l'association de plusieurs paramètres clés


représentant l'évolution d'une activité. Il est toujours choisi en fonction des
objectifs futurs de l'entreprise.

77
Bibliographie

Ouvrages
- [1] Bouquin Henry; « Le contrôle de gestion»; P.U.F; 2003.
- [2] H. Dresner; « Bi, Making the Data Make Sens»; Gartner Group 2001.
- [3] Jean-Michel Franco;« Le Data Warehouse, le Data Mining »; Eyrolles 1997.
- [4] J.F. Goglin; «La Construction du Datawarehouse: du Datamart au Dataweb »;
Hermes 1998.
- [5] W. H. Inmon; « Building the Data Warehouse Third Edition»; Wiley Computer
Publishing 2002.
- [6] R. Kimball et J. Caserta; « The Data warehouse ETL Toolkit»; Wiley Publisshing,
INC 2004
- [7] R. Kimball et M. Ross; « Entrepôts de Données : Guide Pratique de Modélisation
Dimensionnelle 2ème édition » ; Vuibert 2002.
- [8] R. Kimball; « Entrepôts de données : Guide pratique du concepteur de Data
Warehouse » ;Wiley Computer Publishing 1996.
- [9] Le Moigne J.L., « La théorie du système général, théorie de la modélisation», P.U.F.,

1977.
-[10] Didier Nakache; « Data Warehouse et Data Mining »; Conservatoire National des
Arts et Métiers de Lille; Version 1.1; 15 juin 1998.

Articles et Thèses
- [ l l] Abdenour Bouzghoub; « Modélisation des Entrepôts de données XML : Application
au domaine de la sécurité sociale» ; Thèse de Magistère
Option : SlSCSD ; Institut National de Formation en
Informatique (I.N .1) 2008.
- [12] Lamri Chouder; « Entrepôt Distribué de Données»: Thèse de Magistère Option:
SI; institut National de Formation en Informatique (1.N.l) 2007.
- [ 13] Chuck Ballard, Dirk Herreman, Don Schau, Rbonda Bell, Eunsaeng Kim, Ann
Valencic; Data Modeling Techniques for Data Warehousing; International
Technical Support Organization; http://www.redbooks.ibm.com; février 1998.

78
- [14] E. F. Codd; « Providing OLAP (On-Une Analytical Processing) to User-Analysts:
an JT mandate.»; Technical report; E.F. Codd &Associates; 1993.
- (15] Cécile Favre; «Évolution de schémas dans les entrepôts de données»; Thèse de
doctorat; Université Lumière Lyon 2 «École Doctorale Informatique
et Information pour la Société» ; Décembre 2007.
- (16] B. ln.mon;« What is a Data Warehouse»; Article; http://www.billiomon.com; 2000.
- (17] Y .Soler; « Planification et Suivi d'un Projet»; Centre national de la recherche
scientifique Direction des systèmes d'information ;
- [ 18] http://sante-medecine.commentcamarche.net/faq/27828-consultation-medicale-
definition.
- [19] magasine MySib, num 004pl2.
- [20] Maria Trinidad Sema Encinas ; «Entrepôts de données pour/ 'aide à la décision
médicale : conception et expérimentation » ; Thèse de doctorat Spécialité :
Informatique; Université Joseph Fourier« École Doctorale Mathématiques,
Sciences et Technologies de l'Information»; 27 Juin 2005.
- [21] Sébastien FANTINI, FRANK GAVAND, Business Intelligence avec SQL Server
2012 - Maitrisez les concepts et réaliser un système décisionnel, Editions ENI, 600 pages,

2012.
- [22] Guillaume CALAS, Études des principaux algorithmes de data mioing, [SCIA]

EPITA 2009, ppl-20, 2009.

79