num3 universite cocody 040418 161228 1
Post on 15-Jun-2022
7 Views
Preview:
TRANSCRIPT
;,'ll'l#lll,ll;llllll'l.#IIIIJ/r.llllllllllllllll·l#lll,lllllllll:lllllllll·.ll#ll.l,l##,#'llllllllllllll,lll#llll/l'Z-
~ ; ~ ' , ' ! ___..-c=---- UNIVERSITE FELIX HOUPHOUET BOIGNY ~ ; \)NIVERS/7'." UFR . ur1 •• A ~ ~ ~ de Mathématiques et Informatique ,=.:_.~~-) ~ i ; ~ : Laboratoire de Mathématiques Appliquées et Informatique A,1·11 , ,~ (>~ ' ~ ' ~ o"- r j OupHOU~"î-\!> ~ , ' , Année académique ~ , ; ~ N"........................ 2013-2014 ; ; ; ' ~
~ MEMOIRE DE MASTER ~ ; , i ; ; ~ ~ ~ : 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 ~ ; t
~ DECISIONNELLE POUR LA GESTION ~ , ' ~ DES INFORMATIONS MEDICALES: ~ ,. ' ; ;
~ Cas des consultations médicales Î ; ' ' ----------------------------------- ~ ~ ' ~ ~ ~ ~ , Soutenu publiquement le jeudi 18 Décembre 2014 ~ ; ' ~ , ; Lejury ; ' ~ ~ ; : Président : Pr. ADOU KABLAN JEROME Professeur Titulaire UFRMI, UFHB Abidjan ~ , ; ! Directeur : Dr. SEKA LOUIS PAUL Assistant UFRMI, UFHB Abidjan ~ ,. ~ ' Examinateurs : Dr. OUA TT ARA SOMA Chargé de Recherche IRMA, UFHB Abidjan ~
~ ' ~ Mr. BROU PATRICE Assistant UFRMI, UFHB Abidjan ~ ~ J - , ~ . Lri- i , , ' , , ' ; ' - , ' ~ ' 1 t:,l#lllllltr.,,,-.llll#l.l'l'llllllll#ll'lll'l.lll.l.lll'l~lll.ll-:lllll·ll,l'll''l'IIIIMll6'llllll,ll.llll,lllllllllllll#I~
• J
t
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.................................................................................... vil Listes des figures.................................................................................... ix
Introduction 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 I : 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
1- Historique.............................................................................. 9 2- ETL (Extract-Transform-Load}.................................................... 11 3- Entrepôts de données ou Data_Warehouse.... .. .. .. 12 4- Architecture d · un système décisionnel.. .. .. .. .. .. .. .. . . . .. .. .. .. .. .. . . . . .. .. . . .. . 12 5- Data lllin.ing......... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
B- Informatique décisionnel vs Informatique de production.......................... 15 1- Informatique 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 warehouse... . .. .. 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 OLAP..................................................................... 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
1- 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 ID: Modélisation- Réalisation - Exploration du système........................... 44
Chapitre 1 : Modélisation du Système........................................................... 45
1- Techniques de modélisation..................................................... 45 1.1. Méthode MERISE........................................................... 47 1.2. Langage UML.................... .. 47
2- Modèle Conceptuel des données du système................................. 48 2.1. Activité« Consultation médicale»........................................ 49 2.2. Dimensions participantes du modèle...................................... 50
2.2.1. Dirnension « Time_l »............................................ .. 50 2.2.2. Dimension «DWDIMPROFESSION»............................ 51 2.2.3. Dimension «DWDIMSEXE»........................................... 52 2.2.4. Dimension «DWDIMMALADIE»............................. 52 2.2.5. Dimension «DWDIMHABITATION»... 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 Informatique, 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 Ahou 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. « Pourrais-je jamais vous dire tout mon amour».
vi
Abréviations
BI: Business Intelligence
DW: Data Warehouse
DIPE: 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
SI: Système d'Information
SIAD: Système d'Information d' Aide à la Décision
SIH: Système d'Information 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 lntegration 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
Figure5. Structure de données d'un data warehouse
Figure6. Exemple de modélisation en étoile
Figure7. Exemple de modélisation en flocon
Figure8. Exemple de modélisation en constellation
Figure9. Exemple de schéma multidimensionnel
FigurelO. MCD du système
Figurell. Dimension « DWDIMPROFESSION »
Figure12. Dimension « DWDIMSEXE»
Figure13. Dimension « DWDIMMALADIE»
Figure14. Dimension« DWDIMHABITATION>>
Figure15. Schéma en étoile de la consultation médicale
Figure16. Architecture de chargement des données
Figurel 7. Diagramme d'activité du processus de chargement
Figure18. Exemple de package SSIS
Figure19. Package TableProfession dans SSIS
Figure20. Package SACONSULTATION dans SSIS
Figure21. Package DWDIMHABITATION dans SSIS
Figure22. Package DWDIMPROFESSION dans SSIS
Figure23. Package DWF AITCONSULTA TION dans SSIS
Figure24. Création du projet SSASTemps
ix
Figure25. Création d'une dimension Time_l à 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. Ils 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. Il 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.»
2
2- Problématique de l'étude
Les entrepôts de données ont été conçus pour l'aide à la décision. Ils 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 ?
)ii>- 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 del '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
~ Sources de données réelles
Il 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 r 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.
~ 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 (BI) 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 (SIAD), 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 1 '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
Chapitrel: 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 l'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 warehouse » 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. li a pour fonction de produire et de mémoriser les informations, de
l'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 BI 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écillque, 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 (BU, é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 ?
Pilotage
omptabllltéanat~·tlque
Analy'SC de g e-srto n
ommunicatlon
Production
:\.ŒTIER DE L'E.:-,.TREPRISE
Figure 1. Le décisionnel au sein du système décisionnel [4)
1 La construction du datawarehouse: Du datamart au dataweb. Hermes, tmc é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 (Extract-Transform-Loac/J
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 In 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 Mart Générateur d'état
80 Interne
BD Externe
1-l Fichiers TXT,
csv ...
ETL Data Warehouse
Data Mart Cube OLAP Analyse Multidimensionnelle
Data Mart
Source de Données
Extraction Stockage
Data Mining
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.
Il 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.
Jii>' 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.
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.
1. 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-Line
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 n'existe que
par ce dernier.
17
Chapitre 2: Data Warehouse
1. Approche définitionnelle
Considéré comme étant la référence dans le domaine "Building the Data Warehouse", Bill
Inmon 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 Je temps, organisées pour Je 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'Inrnon.
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 Tbird 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 key structure in the data warehouse contains - implicitly or explicitly -an element of time » 4[ 5] disait Inmon.
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 SQL.
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 Publishing 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 :
Données agrégées
Données détaillées
LI Données détaillées hlstorlsées
l 0
î \ 00
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. 11 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.
-~!112 Ccmml.M ftl-ri,*'!2~ v.. ~~
~ IIY~ <Ill>
IIL..-,-------~l&M\l.ltal!~ ~~) <lt2> 5d0Wîtmpl ~ <Al> IDOA'Stxe m;~J<tb ldOWHtbtt1ianiw~)<AS> •• Îl":I
~-----~ Y!!l!!!!I ~
Figure 6. Exemple de modélisation en étoile
Dans ce cas, nous avons une étoile centrale avec une table de faits appelée
DWFAITCONSULTATION et autour ses diverses dimensions DWTEMPS,
DWDIMSEXE, DWDIMMALADIE, DWDIMPROFESSION et DWDIMHABITATION.
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
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. Pr·oduit
Temps
Clé T Jour Mfili
Venre
T_Mots
l\Iois Année
eu Prod Clê T Clê l\lag
Quamirë
Clé Proct Désignation Type alégorie
:\•Iagasiu
Clê Mag Raison sociale Adresse OIIU1lll0e
~·I_Depa.-temeut
l\I_Reglou
Région Pays
Dép a 1·temeu t RNion
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.
Pl·oduit :."\•Iagastn
Clê Mng Raison_ sociale Actresse C=wie Dépanauent Région Pays
Année
Code_postal Conunune Pays
Quantité
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
Magasin
Produit • P.lys s u î TV R CS CP -/:l~ Temps
Greooble /vneq 1 3flNie Reg,oo SUM
î î r·- 3j) l!ll
Terll)S 02/01/2000 mois Dép:lr1ement
0:Wl/2000 î î Jour Ville
Hlérare!lies oes dimensions
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.
Il est important de noter que la construction d'un cube se fait par l'utilisation d'un serveur
OLAP (voir ci-dessous).
),l' 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 (nes~. l'enfoncement (pusb), 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 ro/1-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 (Relational 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
• la transparence du système. Ici, 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 warehouse
Les deux approches les plus connues dans la conception des data warehouse 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-Dawn 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.
Inmon.
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, etje vous direz ce dont} '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.
)i;>- 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 warehouse 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 I tell you I want, then I can tell you what I really want." [Inmon, 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 et d'identifier les tendances qui les influenceront sur un horizon cohérent avec la
nature de leurs fonctions » 6 [ 1].
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. Il 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 Warehouse » 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é. Il 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
1
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 Inconvénients
Solution blanche Forte évolutlvité Complexité de l'intégration 1
Richesse des Budget élevé
' fonctionnalités (Investissement
Réponse aux besoins métîers disproportionné si le
multi applications avec périmëtre du projet est trop ' l'analyse multidimensionnelle restreint)
Solution Facilité de mise en oeuvre Difficulté à créer des rapports
pré-packagée Mise en place plus rapide, différents de ceux prédéfinis
,c (nouveaux développements - faible effet tunnel coût+délai) Permet d'acquérir une bonne Risque de statu quo (voie culture de gestion ·sans issue' du SID)
J.' Peut répondre aux besoins " Modèles de données plus ou réglementaires (comptabilité moins ouverts analytique, T2A ... ) de manière
" automatique Flexibilité souvent très
Budget limité (sous réserve réduite
' . ,. 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'Intormetion Décisionnels dans les établissements de santé :
analyse de J'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, Cognas, 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 BI 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 Ali Share, 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, CTI
Santé, QlikView, SPIB.
• 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.
• CTI Santé
Société de services créée en 2004, CTI 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 QlikVtew.
• Qlikview
La plate-forme QlikView de QlikTech est une véritable expérience de BI 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, nurn 004 pl Z).
38
• SPIH
Le SPIH (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 service 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 1. (à la
page 35), 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 Insight
Tableaux de bord universels
• CognosTMl Planification, Elaboration de
budgétaire, Modélisation,
Simulation. Analyse en temps réel.
• CognosFSR 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 1
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 PerformancePoint Server
• SharePoint Setver
• Power BI for Office 365
• 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.
Keyrus
Le groupe Keyrus a développé deux
solutions pour répondre aux besoins des
établissements de santé :
• K@PRIM : 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 Pilotage
Hospitalier) basé sur le produit
généraliste LiveDashboard en
partenariat avec IBM 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
3. Choix et justification
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).
Il est important de souligner que les licences pour utiliser les logiciels concurrents d'IBM
et de SAP, c'est-à-dire Cognas 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 SIH 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 DHIS 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
1 1
Dans la méthodologie MERISE, le processus de développement du modèle de données
implique l'analyse des types de données qui auront un sens dans le SI ainsi que les
relations entre les différentes donné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 donné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. Il 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
1
• 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 MERISE et UML, nous avons retenu, pour la modélisation du data
warehouse, MERISE 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 ™ 15.1, nous avons réalisé le MCD qui nous a permis
d'aboutir au schéma en étoile 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éfmition 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 le 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
OWOIMPROFESSION
ldDWProfffliqn ~ ~tultibytt vpi1blf(255} ~ P!ofe,sion Multiby1ntri1bl<{255)
Ol'IDIMSEXE OWOIMHABITATION
Identifiant_ 1 <pi>
~ ~ Myl1ibyttvari1bltf25.5) !Q?: Sext Multibylt vari1blt(10)
ldentifilnl_ 1 <pi>
ldQWlltbit>tion ~ Muttibyt• œ•bttf255) ~ Commune Multibyle vlriablt{~ Ville Multibyte varitblt{255) ldtntifitn!_l
O,n
t,n
OWFAITCONSULTATIOH O. 1 ,Age Entior
1,1
OWOl~1MA1AD1E ~ ~ Multibyttvari1!>!t{255l ~ ~t,ladie Mulfibyle vtri1blt{255) Identifiant_ 1 <pi>
1,1 1,1
1 OWTEMPS
t.n ~~211!<0> ldtntifiant_1 <pi>
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
première dimension dans le classement sous-jecent de la base de données » 7 [8] .
7 « Entrepôts de Données : Guide Pratique de Modélisation Dimensionnelle 2ème édition »,
Vuibert 2002.
50
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 l' 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 «DWDIMPROFESSION»
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« DWDIMPROFESSION».
Désignation Détail
IdDWProfession La clé de la dimension «DWDIMPROFESSION»
Profession Le libellé de profession
Tableau 4. Tableau descriptif de la dimension «DWDIMPROFESSION»
51
2.2.3. Dimension «DWDIMSEXE»
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 « DWDIMSEXE»
Désignation Détail
ldDWSexe La clé de la dimension « DWDIMSEXE»
Sexe Le genre du patient
Tableau 5. Tableau descriptif de la dimension «DWDIMSEXE»
2.2.4. Dimension « DWDIMMALADIE»
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:
i>
Figure 13. Dimension « DWDIMMALADIE»
52
Désignation Détail
ldDWMaladie La clé de la dimension« DWDIMMALADIE»
Maladie Le nom de maladie
Tableau 6. Tableau descriptif de la dimension «DWDIMMALADIE»
2.2.5. Dimension « DWDIMHABITATION»
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
DWDIMHABIT A TION est présentée ainsi:
Figure14. Dimension« DWDIMHABITATION»
Désignation Détail
ldDWHabitation La clé de la dimension« DWDIMHABITATION»
Commune La commune où habite un patient
Ville La ville où se trouve la commune
Tableau 7. Tableau descriptif de la dimension «DWDIMHABIT ATION »
53
2.3. Les mesures
Les mesures qui correspondent à la table des faits «DW F AITCONSULTATION » 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.
OWOiMSEXE DWOIMHASITATION
~f!V!!Shp![2ffi~ ldOWIUbt!ation nvsrçha!1255) ~ Sext n•8l<Nl\10) Commune nvw,11{25~)
OWOJMPROFESS10N Villt ~551
t ldOWProlfflÏon nvttdwGC.551 ~ Pn>fenion ~551
OWFAJTCONSULTJ\TION
ldOWProfwion nvard>att2.55) <1!11> ldOVr'Maladlt n.ttch.11{255) <ft2>
i rctOl'/Tamps datatime <lt3> lOO'NSut ~)<11.4> ldl>\YHibfi.tion nvatdla,(255) <A5> ~ lnt
owt)IWJALADIE
1gpw1.111fdit nvf'Wf'(:2Ml ~ Maladit nvarcha,\255)
DWT9.lPS
ldOWTeme, !!!l!!l!:!!! ~
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:
BOPatients
BD_Maladie / stagingArea
•• Datawarehouse OLAP
Figure 16. Architecture de chargement des données
55
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é do 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
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:
.,,..._ •••• •
Succès
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 SSIS 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
E.dr"""'dttsme -:: N~<c.diiocwl
î- (l lmpcrù!icn dt-
Jomrt dt""""' t!MrJbJlfwon
ijNcriftdt~
1- l. ltmrd>tdtt,,m, ~l P""'1dl<fbut ~p!OO,lblt
~ luppinerk..-ao,slô1'111.- 1 '\ Tlbkdeuoolm !!: TM!lùuaooiclp'omiqut ~ ,,__ -.ooe lflrier 11UndUM
1 1 11~~--- -----=~
(.-,w,Wo Qi0S0dinm • l),t,ul(od<P~ ll5I ll<,a,pôoo (lf080dJNli
1) 35 { 1c.rntl1otwn!ti cOIT'~r,,er,t • hDt/Nlioule r.,. i looltil 1...,.. (Fanc,)( llomt --.i °"""-" ld>olJSl,HA!IITl'- fl,c~'imonO
Figure 18. Exemple de package SSIS
Il est à noter que chaque package à partir de la figure 18 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 l'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 (StagingArea)
• TableProfession
Figure 19. Package TableProfession dans SSIS
58
• TableConsultationMedicale
Exlractlon d dmê.es depuis Source Acœss
LC>Olcl4> Match
Figure 20. Package SA CONSULTATION dans SSIS
2.2. Chargement des tables de l'entrepôt de données (DataWarehouse)
• Tables de dimensions
• DWDIMHABITATION
Exnci>onde_<lc>rY,tts de_lo table SAHABfTA,Ia< depulslot-eS~
~tde_lo DWOMWIITATIOI<
Figure 21. Package DWDIMHABITATION dans SSIS • DIMPROFESSION
Chargement de la œnensiof1 OlllProf=ion dans la~ OataWarehouse
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 Tirne_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 « DWFAITCONSULTATION»:
Extraction de données depuis la base Stag,ngArea
ldDWHabHabon
ldOWTc,mps
Cha<9=icnt de la table des faits DWFAITCONSUL TATION clans la base Datz,Warehouse
Figure 23. Package DWF AITCONSUL TATION 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.
~ 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 multidimensionnel
• 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 projets: Modèles:
~ uslness lntelfigence Projcd.s jM~ê.les Vîsual Stud;o in~t.1116
Aut,es types de proJets ~~~~ces Pro~
· -l lntegration Services Conncction.J Proje... ,) Report Sefver Project Wuud 3 Report - ProJ«:t Mes modè.le.s
.3]Rechttcher des modèles en ligne.-
[.Nn ttomework 3.S
Import Analysis St:rvices üeteeese ~lntegr-ation Services Projttt 1J Report Modo! ProJect
Crute • new Analysis Servie~ pro-jcct
Nom:
Empl1cement :
Nom de: solution :
An1tysis Services ProJt-ctl --- -- C:\Users\ASSIE\Desktop\MASTER\Bd
1 Créer une nouvdJe soh.Jtion ~ 1 0 Crttr l,: ~OR pour la solution - - .
An•lysis Services Proj«tl
1 OK 1 [ Annuler
Figure 24. Création du projet SSASTemps
Sélectionner la méthode de création
How woufd you llke to creatc the dimension?
Use ~n exi.rting t . .;,blc
Il!'" Gene.~t• • bme t•ble in t:he d•t• source
Ge.ne.rate a timc table on the. serves
Gen~tc • non-time table i-n the data source Te:mpl,a;t,e-:
Select Creatlon Met:hod Vou c•n eese the dîm111C..nsion on an exist::ing t•ble or ge.ne.ratc o ncw table as the source.
(None)
OC$cript.ion: - - - - Cre.ate. a ncw time. dime.n.sion Uble. in the. und~ng dab ~ource. The dime-n~ion 'Will cont•in d•t:.a for the. d~te rangiP., attributes.~ .and calendars you specify. Vou must have permission to eeeeee objcct-o;; in the undertying dat., source.
< Prk~e.nt 11 Suivitnt > 1 Annuler-
Figure 25. Création d'une dimension Time_l à l'aide de l'assistant SSAS
Définir les périodes
63
D..tine Time Periods Select the- timc pe_riod-; to c se whcn gene,.ating the hicrarchi~.
First calendar day: samedi
La.st c.alendar day. j@udi
1 janvier 2011
31 dê-cembre 2015
o-
Firrt day of the: wee.lc: {Sunday
Tïme pcriods: Ga v ee« D Hait Year EJ Quarter r,;_: [':] Month n Ten Days 0w .• e1t GB Date
Tnmestel'
L _I Language for time mc-mbcr names: ! Franç.ais (France) ~
,----· < Précëdent J ( Suiv~nt > J Annuler
1 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 C..lend •• rs Sefec-t the cal~nda,-s for whic.h you \Nant to ee eet e hierarchies.
~ Regular cale-nd•r
Fisc..-1 c.alendar Janua,y
c~ter,,d.,.,) car namc • 1
0 Re.porting (or mar1ceting) calcnd.ar J.:>nuarv
Jonva,..,
.. J ISO 8601 calcndar
~~êden~ 11 Sunl•nt > 1 Œn_nulc-r
Figure 27. Sélection du type de calendrier
64
Générer les attributs
Completing the Wiard Type a name for the new dimension, verify the dimension structure, and then click Finish to save the dime.nsion.
Name:
Tïme,_l
Preview:
(3 k: Time_l S t2) Attributes
:l°l Date ::g Vcar :: Trimester :: Week :: DayOfYear :: Day Of Trimester :; DayOfWeek :; Y/eek Of Y car :: T rirnester Of Ye.ar
0 k: Hierarchies Œ) :Z. .• Vear - Trirnester • Date fi.) h. Ye,ar - Week - Date
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:
9 )( ----
:iiJ
PK,_Oate Dau N..,. Y~ y.., Name TllllOst!t Tm,esm Name Vltt:l< Wef/,, tme G} ! 2011-01-0100:00:00000 1 ~ . .lna)'Ol 2011 2011-01-01000000.000 Coloida-2011 201Hl1-010000-00000 Tm,e,t" 1.2011 2011-01-010000-00000 W..t 1.20110. 2011-01-0200.00:00000 s.rday.Jn<.r022011 2011-01-0lOOC0:00000 Cami,,r2011 2011-01-010000-00000 Trme,u,1.2011 2011-01--02C01Xl·OO.OC:O We,H2011 2011-01-03 0000 00.000 l,b,day. J«u«y 03 2011 2011-01-0100001l0 000 C*idar 2011 2011-01-01000000 000 T- 1. 2011 2011-01-02 000000.000 \'leek 2. 2011
: 4 2011-01-0400:001l0000 Tuesda'y.~~2011 2011-01-010000.00000 ûi,nSa-2011 2011-01-010000-00000 Trmes.,1.2011 2011-01-0200;00:00.000 Weel<2.2011 s 2011-01-05 oo·oooo ooo Vl«hesday. """'105 2011 2011-01-01 00-0000 ooo ûiencia' 2011 2011-01-01 0000-00000 r""""' 1. 2011 2011-01-020000 00.000 w..i,. 2. 2011
2011-01-0600-001l0000 'Tlu!&/.J,nsyœ2011 2011-01-0lOO'OOilO.OOO ~2011 2011-01-010000:00000 T-1 2011 2011-01-020000-00.000 Weel<2.2011 2011-01-07 000000.000 fndar. Jnay 07 2011 2011-01-01 00-0000.00ll Caienda' 2011 2011-01-01 00:IX)-{'() 000 r-.. 1. 2011 2011-01-02 00-00.00.000 Weelt 2. 2011 , 2011-01-<18 000000 000 ~- Ja-&wy 08 2011 2011-01-01 00;0000.IDI Ca'enila" 2011 2011-01-01 0000:00 000 Tm,e,1er 1. 2011 2011-01-02 000000.000 Wodt 2. 2011 (
Ü .~11-01:~~~.~tm ::,·~0920~1 _ _._._~~1.:~:::J_ ~~11. 2011-01-01~:00ooooo __ r-:1.2011 2011-01-09001»00000 1~~3--~;1~; . .
Figure 29. Visualisation des données de la table Time_l
65
• Présentation du cube multidimensionnel de la consultation médicale
D,t, Source, , 1· .jt Data Wmhouse.ds
11/:;iDalaw~ il r f,- .d!I - ,jt DruWarthousd.ds ~ ·' , 8· D DataSouruYiews
le ls 1
DalaWardwse i!l DV«>IMiASIT ATICli tg'. DYiU!MWJIDŒ trlDIMlm \Q'.Tme 1 lt D!M'R<F5SICN
T~_Ntmt ,..,.. 1'1111. __ o.,_ei_r •• D,y_Ci_Yw__ •
J Pt,'FAITCONSlL !DO\;J>ROFESS!ON toO\W.AlADJë tOOWT&..PS = tDOl\'HAi!TA TION AGEAIŒEE AGalO!S
·~ Data Wartnoose.dsv Cube, 1J Dlll Wuthause.cube Osr,,ruicns
- IL OVIOIMHABITATION.dim IL Tome l.dim IL Dl'IDIMMALADŒ.dim IL DIMPROFESS!ON.d'un
- IL DlMSEXE.dim Mining SlnKture, Rcl<s
1 !D0i\~
5""
Name Dm Wmhouse PrcutivtCachi, (none) P1ocessingMcd R,gul,r Proce,singPncr 0 ScriptCoch<Pro Rtgul,r Script[rrcrHanc lgncrtNcne Source Oit, W,rehcust 1 Stcr19tl.oca!K>t 5tcragtMoclt Molap V'~ibft True
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' outiJ 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
• F. Yamoussoukro-Yamoussoukro M. Abobo. Abidjan • M-Adjamé-Abidjan • M. Yamoussoukro. Yamoussoukro
Fièvre Jaune Paludisme Maladies identifiées
Figure 31. Rapprot de la consultation médicale
67
Nombre de Cas par maladie -2 5
Fièvre Jaune
aladie identifiée
Figure 32. Rapport Nombre de Cas par maladie de la consultation médicale
3. Coût du projet
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 CF A)
(en CFA)
Machine serveur ~ ,, 1- •. , • .;;.:,. . 1 . " 750 000 750000 -· ., \ •. ~ ,, ' ,',
Licence SQL Server 2008r2 1 1800 000 1800 000
Licence Windows Server .. 1 ' 244 300 244 300 ' ', ~ ,
' _, ,_ ,. . '· Licence Microsoft office 1 86000 86000
Connexion Internet ADSL 1 mois ' 30000 30000 . • ?·
" ·,.,;. ,j.l ' . ' .,
"
, " - ' ,· .•. ,.:) ........ < ,,
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 del' 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 1' 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 Inmon) selon lesquels
il faut nécessairement consacrer plus 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
AffectiooMaladie ~ ClldtAIIMa
NomA!fl.la Oiagnostiqutd&ladie V HumCons 9 CodtAlfMa
llbreCas
'CIi
ME<lecin 1 'y Matnculttd!d 1 llomM!d
1 5~.~~~.~, 1
1B~
Etablisl!fTienlHospit.. 9 CodtEtHos
Rai1onSooa1, Adrtm
Consultation ~III.IICons
OateCons Moti!Con1 HirtoiltMal (odtPat CodtHab MatricultMtd CodtEIHils
Pres<rireMedicam6'1t V NumCons V CodtMtd
tairtloisPmMed
Mtdicament 11 ! i CodtM!d
j
CIi A1'0i!Antecedent 1 V llumCons 1 9 ClldeAn!Mtd Ante<tdent
'f CodtAntMtd libtlleAn!Mtd
Patients
~ ~!Pat ~ Habiter
l
m <y coœHab Prtnoms V Codeht Dat1tjajn f DattO Sm Domtàlt lalitni'IMJ
Hab~ation 1 Codttiab
Quartitr Communt Vd1!
Schéma de la base de données BDPatients sous Access
73
TT raltement 1 Î ~Tratfflelt 1
Tyçelramt
1. lv ~S~t
1
t ~~}111)1
F~c-- 1
~ 1
TTraiter ! V ~Tramt 1
1
:'~ 1
TAvoir
~ li ~S~t 1
1
1
TSituatGeo Î C~tGeo
ZcœGeo
'Modelrans 'J (~Trais ~WTrais
J , ,--TTransmettre-~
l=~h~ 1
1
1
j
TPrevenir l" C~ev 1
LJ r-0a1 Tldel'rev ~ 9 cciœActePrev 1
~~ev j
Schéma de la base de données BD Maladie sous SOL Server
74
TablePat:ients 1 · ::-~· l SAHABITATION 1·==·- l CocleProfessiol'l
. l 1 TableProfesslon TableConsultationMed.icale 19 Code,Prof'Cssion
1 'il Nt.rneons ,..,, oaœcons
Prof'essoon
CodePatient Il
sexe =- Professlon Habiœlion Maladi<, L-, .r.-,.. TableMALADIE
~ ~Œ 1
- , r (TJ.,, ,~ ..•..• _. •....• ~.J - QMMALAOŒ
'
Base de données StagingArea
j- ASSlE-PC.~ta,W_DiagramSEXEMODt -=L~ --• - (I..JE·PC\ASSIE 1~1)" l 'ASSIE-PC àaina.M Da~mMt!dicele l"SQLQ~l~ - !I • .JE-P~
DWOIMMALADIE r 'l IOOWMALAOIE J DIMSEXE MALADIE
[:- J 1 l sexe
1
(• 1
DWFAITCONSULTATION IDOWPROFESSION
DWDIMHABITATION IOOWMALADŒ Il.
1· ==·- 1
IDOY/TcM'S DIMPROFESSION
IOOWSEXE ,·~-- 1
1 IDOWHABITATION
AGEJIH'E
Profession
AGEMOIS
Time 1 l 'l PK_Date
1 Daœ _ _,,., . 1
Base de données Data Warehouse
75
Olf 06 Conrnand
Hi. if Mergtlîi
aaœ Conmand
Exemples de package de mise à jour
76
•!• Définitions
./ Data mart: Un Data mari (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 Meke 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 Datamarc au Dataweb »;
Hermes 1998.
- (5] W. H. lnmon; « 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; 15juin 1998.
Articles et Thèses - (11] 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 : SISCSD ; 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 (I.N.I) 2007.
- [13) Chuck Ballard, Dirk Herreman, Don Schau, Rhonda 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-Line Analytical Processing) to User-Analysts:
an IT 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. Inmon; « What is a Data Warehouse»; Article; http://www.billinmon.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 MySih, num 004pl2.
- [20] Maria Trinidad Serna Encinas ; «Entrepôts de données pour 1 '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 GA Y AND, 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 mining, [SCIA]
EPITA 2009, ppl-20, 2009.
79
80
top related