Embed Size (px)
Citation preview
1
No························
UNIVERSITE FELIX HOUPHOUET BOIGNY UFR de Mathématiques et Informatique
Laboratoire de Mathématiques Appliquées et Informatique
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
Année académique
2013-2014
TITRE DU MEMOIRE:
ETUDE D'UNE PLATEFORME DECISIONNELLE POUR LA GESTION DES INFORMATIONS MEDICALES:
Cas des consultations médicales
Soutenu publiquement le jeudi 18 Décembre 2014
Le jury
~ Président : I
, Directeur : '
Pr. ADOU KABLAN JEROME
Dr. SEKA LOUIS PAUL
Professeur Titulaire UFRMI, UFHB Abidjan
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
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:,,é
TIF
ProducHon
~I
Figure 1. Le décisionnel au sein du système décisionnel 14]
1 La 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
BD E,;terne
Cube OLAP Analyse Multidimens,onnette
En.. Data Wareho.ise
Data M1mng
Fichiers rxr, csv ...
Data Mart f-,-
Source de Donnée
Extraction Stockage
Tableaux de bord
Restitution
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 ,, .
\ .. ., Il /}
\ 1 •
/
O"IC: O"I '1 ;,n '"' '•'
~,t,tttUtl• V>'-'!'·•' I ., nrt . Il, 1 /' ~) ; ··__!J . ,_,,., ln,i, •1•• 1111,t.ll •) • .,,,
,,
IJ 'tt. •.,.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\ / Données agrégées CJ ô d)
;::l .2 - '0 ..c
~ Cl)
Cl)
~ Données détaillées I î \ 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 i ,.,,_,,.,. •• a ~-v•. c..o
,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
~Joh A.1u,~
ale
~I Rc-i:.lon
:\I_Dc-partc-mc-nt
Dép:1rtrmc-n1 Rf;glou
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
1/: Pnxnl • ~
t lVR CSCPM ,tJgasl =ya,, ~ ·' "" fi hm il Temps
~~c:=:=:r=:;,--. • .,.,
1.,.,,,.. ,. "' "' ,.. .. î
•• Te~ 01ml/21m l--4~--tl--11.-~--- m0IS
<W- •• î Jeu
P:t;s
î Regon
î 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:
« Donnez-moi ce que je vous demande, et je vous direz ce dont j'ai vraiment besoin ». 5[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
nature de leurs fonctions »6 [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 fonctionnalités
Budget elevé (investissement disproportionné si le périmétre du projet est trop restreint)
Solution pré-packagée
Foc1hte de mise en ceuvr
Peut repondre aux besoins reglementasres ( comptabrht analyttque. T2A ) de manier utomotique
Budget limité (sous réserve de l'intégration)
01fficulle a creer des rapports d1fferents de ceux predefims (nouveaux développements - coüt+déh)o
Risque de statu quo (voie sans issue du SID)
t,lodeles de donnees plus ou moins ouverts
Flexibilité souvent très réduite
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é
Prelytis
• LiveDashBoard
• SPIH (Système de Pllotage
Hospitalier) basé sur le produit
généraliste LiveDashboard en
partenariat avec lBM et Stream
Consulting
QlikTech
• Qlikview:
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
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:
84.dinHs lntdlfg~nCJt Project'i Autlü ~'ll~ M prCJd:s:
Modcld: tJlc.dd6 V,su•I St:uct.o ,nsu!lu
Anoiys,<5e,v,cos Pr"Ojttt
4 lntegrat,on S.Cr..n.c~ (c,uo,tdtOJ"K. PrcJ• ,..J R.rport s«rva ProJttt 'llf,:Md
Repo.rt Se~r ProJ«ct
••. ..,Jlmpcrt A.nt~-' ~tees Oeta.tu~ ,:;\lntc-gubcn S..V..c.,ç P,c,ect 7JR.~port Modrl ProJe<t
Solutton:
Nom de wlubcn:
C:\Use,sV.SSŒ\Oec<kloP'l.1:uTER\Bd
§ une nouvdfc. S,.Olùl.t0n -- - •} .J Cree, I• ,.,p...,cu·e pou, I• l-Clut,on
An•lyus s~M«S: ProJectl
• \ PMC,DW'ÏI-
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•mc-ns,o~ on.,., ~-,st•ns, t•bhr or 51._..,..••••• • ne- t•blir es the ~ourc:c-
HDYY would you h.k.c lo cr~•tir the d,mtrut.onl
Ge_ner.et111 • ttme t•bf• on the :[email protected]
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
Defln• Tlm• Periods Sele<t. the: time pfflod.s to use ~he-n gtnarating the h1•r•rchies..
F,rst d.y of the- wee_lc:
jeudi 31 dé-ce.tnbte 2015
Timc pfflod.s.:
ILJ
l,J
v •• , H•H Ve•r Qu•rter T r1mest a Month Ten Oays
J \."Veck J Oat·e
Lengu•gc. for timc. mvnbe:r n..ames: 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
L •• Tnmcste-rOfYur
k:: H,crarc.h, es • ::~ Yur • T rrmestcr • Date • • ... :,. 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' .ol•:t t:a,: !I.U - ~
. )( _j
"'
Yu
Tltnè>/. J.inJ.yl Œ Ziil 1 .Jrur,-C-2!:ll
Sm.da)· JoN.,yCl2011 Su-.:.,y Jaow-,CS1G11
y..,,_,,.,,,, r ••••....•• Cdcrda, XII û1end,, 2011 Cai,ndy 2CII c.ien;,xn Colw,c!r1'11 c...r.dY~l ùi<nia-2CII c.:.,,.;,..z;11 Cè-dY2ll11
Tlll!>eler_llr.>t Wt:t!< 11 2011~1<1 !X oooc OC')
2011~1-CHlCOOOOOOO W·
::..i.2 2:111 ::..,;,.2.1.ill
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
iJ tJ Mu,i,,s )0.IIW•lhut
C,,•,f.urtaiSU.UT!OI
. ti ,f
'~ J o.r.a l~•dll1&t • l[ 0-,',ll~ffl.mATial • ll !Y,',llW.JUOJ: ' l[ Ol'l!ru , l[Tnl • ÜDM'lt0"5S l0!1
.J
, . ~ _.•......-..
- •. ,,,,.flllWI'_~ ·- ..• ,... ~,_r:;_, ••. ~O'_fw_t.r. •
:.00-6 .• u:·,·:.o·, C-i.A'1.U 1~
1 :.sof 1
..l; ~ SSASTtmps - ..J D,u Scurc,s
•: .• O~WardkMt..ik ,:, Dat,W,11thcas<l.ds Diu Scum v~.1 •)Dot1W11thc-.ci,,, (uh,s
Dot, l'l•ch-..n.et ..JD,m..,,,cns
O't.OU.tlUSITA TIOtl~ _ T-Ldim (l [M'DlMMAlAllŒ,d,m le: 00,Wf'.Ofill!C)tl d:m Il OU.IDE.dom
~ "1'"'"9 Sauc!urcs Pd,s
D•ta Wartho<M Cubt • A • I
H,nw Q,u ~·1.m~, Pro1a,. tC,ct,a (n<,, PrcetssmgMod ~ Prccffll!J9Pnc1 0 Scnpl(Jd!tl'n1F.~ ScnptfmltHlnc ~-.Nuit
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 •1alad1es 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
1gncstJqueiM.iladie ·tkllCom 1•
CodeUfl.l• llbreûs
Dffli.ind!!&amenlkdic ~ IUll(ons 'l Codef.tf,l!d
&Jmenl,Wol CodeW.ltd llbtU!Exl,lt(I
Mtdt<tn Y IAilnclAtf,led
llolll.lt<I Sptcaltt 8uluu
ttabhoonentHosp ,-.,,----,, Y CodtftHos
R.arsonSo<illt ltllrtllt
Cansulution H1111Con1 DàtCons Motteons •• stonlr.r (~
CoOtllill ~WnCIMMtd Codtflltos
PresairtMfdicamtnt YlllllCons
Codef.l!d Hbrtlo11PrtSl,ltd
l
'= Mtdioment l Codel.ltd t;i,d.11<1
• A·,t"Anle<tdtnt
llul!Cons (odt,\ntl.ltd
-l •
l Ptbtnts ,. Profes~on 1, 1 CodtPi
"'1- y COOtlil'olt11to11 n floll
~dt!t,b PloftSIIGn , I Plenoms i~ O.dlaru 'l Ditll Sm
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 ~
i '(JJ
-~ 1 IlOOlliser 'Modelrans u:= TMaladie - V C~Trw V~m ~ÎIW t~
~.
Schéma de la base de données BD Maladie sous SOL Server
74
SAHABITATION V COOEHA8JTATION
COMMl..f'E vtU..E
TablePallent5 9 CodeP•l>ff'lt
Sexe Codel>rofus>on
TableConsultationMedlcale V NumCons
O.teCons Co<S&at>er>t Sexe ProfHsaon H.t>otabOn
Malade A9CAnnee
TableProfession 9 CodeProfession
Professaon
Il
\CX>
TableMALADIE 9 COOEMALAOŒ
NOt+IAI.AOlE
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~
DWOIMHABITATION 9 100','IHABITATTON
Cc:ir+!U'E
YU.Lf
DWFAITCONSULTATION 1DOY,1'R~Ofl IDO\ 'n,IALADIE
IOOWT8"'5 IDOWSElΠIOOWHA8lTATION
AGE.Ali&
AGEMOlS
DIMPROFESSION 9 CodePl'or,,sSIOn
Pro~ 1 l
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
