REPUBLIQUE DU SENEGAL

ECOLE SUPERIEURE DE TECHNOLOGIE ET DE MANAGEMENT DE DAKAR

DEPARTEMENT INFORMATIQUE
MEMOIRE DE FIN DE CYCLE

Pour l’obtention du diplôme d’ingénieur Téléinformatique et Réseaux

THEME:

Sujet : Mise en place d’un entrepôt de

données pour l’aide à la décision au
service médical des étudiants

Réalisé par : Abdrahmane Aw Encadrant : Dr. Fodé Camara

Promotion 2016 :2017

 Remercîment

La réalisation de ce mémoire a été possible grâce au concours de plusieurs personnes à

qui je voudrais témoigner toute ma reconnaissance.

Je tiens à exprimer ma sincère reconnaissance et ma profonde gratitude à ma famille

de Matam à Dakar en passant Rosso et Saint-Louis sans oublier Ndioume

et Podor.

A Dr Fodé Camara de par sa disponibilité, sa clairvoyance, son soutien et surtout ses

judicieux conseils, tout au long de ce mémoire.
Je voudrais aussi remercier les professeurs , le personnel de L’ESTM et à la cellule
informatique du C.O.U.D
.

1
 Avant- Propos

Créée en 2001, l’Ecole Supérieure de Technologie et de Management de Dakar (ESTM) fait

parti de la ligne des écoles supérieures de formation professionnelle qui ont pour ambition

de former de jeunes cadres africains pour l’excellence dans le domaine des technologies et

la gestion à travers l’informatique et le management.

Avec un corps professoral des experts de la place dans le domaine de l’informatique et du

Management, l’ESTM est dans une posture de se démarquer de ses concurrents pour

relever les défits du nouveau millénaire.

La fin d’une formation est toujours validée par la soutenance d’un mémoire de fin de cycle.

Ainsi, chaque étudiant devient apte à recevoir un diplôme reconnu par le ministère

de l’enseignement supérieur et par le conseil africain et malgache pour

l’enseignement supérieur(CAMES).

2
 Résumé

Un entrepôt de données est une collection de données intégrées et historiées qui sont utilisées
pour la prise de décisions stratégiques au moyen de techniques de traitement analytiques.

La mise en place de Systèmes d’Information Décisionnels (SID) dédiés au pilotage de la

performance facilite la prise de décision et l’alignement stratégique des organisations en
recherche d’efficacité et d’efficience. Ces systèmes assurent la restitution d’informations
fiables, précises et pertinentes au moyen d’indicateurs structurés en tableaux de bord. Ils
s’appuient sur les méthodes du contrôle de gestion et du pilotage de la performance.

Dans ce mémoire, 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,
le service médical des étudiants du Centre des Œuvres universitaires de Dakar (C.O.U.D) a la
mission d’accompagner tous les étudiants orientés durant leur cursus scolaire.

L’objectif de la construction d’un entrepôt revient à faire d’abord, la mise en place d’une
application web va permettre d’alimenter l’Entrepôt (Base de données), ensuite la création du
datamart, et en fin, on va proposer la conception d’un schéma multidimensionnel qui permet de
répondre aux besoins des utilisateurs.

3
 Summary

A data warehouse is a collection of integrated and historiated data which are used for the
strategic decision-making by means of analytical processing techniques.

The implementation of Decision-making Information Systems (DIS), dedicated to the piloting

of performance, facilitates decision-making and strategic alignment of organizations in search
for efficacy and for efficiency. These systems insure the restoration of reliable, precise and
relevant information by means of indicators structured in dashboards. They lean on the methods
of management control and on the performance piloting.

In this dissertation, we lay emphasis on our know-how to the problem medical management
data which constitute a particularly interesting application frame. Indeed, the medical service
of the students of Centre des Oeuvres Universitaires de Dakar ( C.O.U.D) aims to support all
the students during their school curriculum.

The objective of the construction of a data warehouse means making at first, the implementation
of a Web application which is going to allow to feed the Database, then the creation of the
DataMart, and at the end, we are going to propose the conception of a multidimensional plan
which allows to meet the needs of users.

4
Contents
Introduction .............................................................................................................................. 7
Chapitre 1 Analyse et Conception .......................................................................................... 8
1.1. Le cycle de développement....................................................................................... 8
1.1. Méthodes d’analyses .................................................................................................. 9
1.1.1. MERISE .............................................................................................................. 9
1.1.2. l'UML ................................................................................................................ 10
1.3. Diagrammes de cas d'utilisation ............................................................................. 11
1.3.1. Diagrammes de Séquence Système ..................................................................... 12
1.3.2. Diagrammes de classe ........................................................................................... 18
1.4. Architecture Logicielle ............................................................................................... 19
Chapitre II Les outils et environnements de développements .......................................... 22
2.1. Les systèmes de gestion de base de données ............................................................. 22
2.1.1. Oracle ..................................................................................................................... 22
2.1.2. PostgreSQL ........................................................................................................... 23
2.1.3. SQLite ................................................................................................................... 24
2.1.4. Mysql ..................................................................................................................... 25
2.2. Les FrameWorks MVC: ............................................................................................ 26
2.2.1. Struts ..................................................................................................................... 26
2.2.2. Hibernate .............................................................................................................. 26
2.2.3. JSF .......................................................................................................................... 27
2.3. Les Bibliothèques ........................................................................................................ 27
2.3.1. Richfaces ............................................................................................................... 27
2.3.2. Icefaces ................................................................................................................... 28
2.3.3. Primefaces .............................................................................................................. 29
2.4. Les Serveurs d’applications ....................................................................................... 30
2.4.1. Le serveur Jboss .................................................................................................... 30
2.4.2. Le serveur Glassfish .............................................................................................. 31
2.4.3. Le serveur Jrun ..................................................................................................... 31
2.4.4. Le serveur Tomcat ................................................................................................ 32
Chapitre III Implémentation de l’application ..................................................................... 34
Chapitre IV l’Analyse de données ........................................................................................ 38
4.1. Etat de l’art sur les systèmes décisionnels ................................................................ 39
4.1.1. Processus ETL ...................................................................................................... 39
4.1.2. Définition d'un outil ETL ..................................................................................... 39

5
 4.1.3. La phase d’alimentation ....................................................................................... 39
4.2. Différence entre Entrepôts et les bases de données .................................................. 40
4.3. Modélisation multidimensionnelle ............................................................................. 41
4.3.1. Niveaux Conceptuels ............................................................................................. 41
4.3.1.1. Table de faits ...................................................................................................... 42
4.3.1.2. Table de Dimensions .......................................................................................... 42
4.3.1.3. Hiérarchie ........................................................................................................... 43
4.1.3.4. Granularité ......................................................................................................... 43
4.2.1. Niveaux Logiques .................................................................................................. 44
4.2.2. Schéma en étoile ................................................................................................... 44
4.2.3. Le schéma en flocon de neige (Snowflake) .......................................................... 45
4.2.4. Le schéma en constellation ................................................................................... 46
4.3. ServeursOLAP (On-Line Analytical Processing) ..................................................... 47
4.3.1. ROLAP (Relational OLAP) ................................................................................. 48
4.3.2. MOLAP (Multidimensional OLAP) .................................................................... 48
4.3.3. HOLAP (Hybrid OLAP) ...................................................................................... 49
Chapitre V Conception et mise en place de notre entrepôt de données ........................... 51
5.1 Conception ..................................................................................................................... 51
5.2 Etude de quelques solutions décisionnelles ................................................................ 52
5.2.1. Spago BI ................................................................................................................. 52
5.2.2. Pentaho ................................................................................................................... 53
5.2.3. Birt .......................................................................................................................... 53
5.2.4. Talend Master Management (TMDM) .............................................................. 54
5.2.5. Le serveur Mondrian ........................................................................................... 54
5.3 Intégration des données avec Pentaho Data Integration .......................................... 54
5.4. Alimentation du Datamart .......................................................................................... 62
5.5. Protection des données à caractère personnel .......................................................... 69
5.6. Analyse des données .................................................................................................... 70
Conclusion ............................................................................................................................... 76
ANNEXE ................................................................................................................................. 77
Table des Figures et Tableaux ........................................................................................... 77
BIOBLIOGRAPHIE .............................................................................................................. 79

6
Introduction

L'utilisation des systèmes de gestion de base de données (SGBD) relationnel est très
majoritairement répandue pour la gestion des données. Si son usage avait été initialement conçu
pour organiser, stocker et exploiter de manière optimale des données. Il n'avait pas été pensé
pour les grandes quantités de donnée accumulées actuellement.
L'exemple de YouTube en est très révélateur, chaque minute l'équivalent de vingt-quatre heures
de vidéo est ajouté, c'est dans le contexte d'une incapacité à gérer leurs données qu'ils se sont
fait racheté par Google en 2006.
Par ailleurs, l’informatique décisionnelle (en anglais : DSS pour Decision Support System ou
encore BI pour Business Intelligence) désigne les moyens, les outils et les méthodes qui
permettent de collecter, consolider, modéliser et restituer les données, matérielles ou
immatérielles, d'une entreprise en vue d'offrir une aide à la décision et de permettre aux
responsables de la stratégie d’entreprise d’avoir une vue d’ensemble de l’activité traitée.

D'où l’importance de mettre en place un entrepôt de données pour l’aide à la décision au

service médical des étudiants du Centre des Œuvres universitaires de Dakar (C.O.U.D).

Ainsi la réalisation de ce mémoire consiste à répondre à un ensemble de questions que soulève

la problématique :

 Comment gérer la conformité, l’homogénéité et la disponibilité des données au sein du

service médical ?
 Quelle aide l’informatique décisionnelle peut-elle apporter aux analystes (médecins) ?
 Comment concevoir le système décisionnel ?
 Comment faire des analyses multidimensionnelles ?

L’objectif ainsi que le contenu de ce mémoire vise à résoudre les problèmes liés à
l’implémentation du Data Warehouse pour le service radiologie qui servira à alimenter
l’entrepôt de données, expliquer et montrer les apports fonctionnels et techniques de
l’informatique décisionnelle, plus communément connue sous le nom de business intelligence,
aux analystes pour une meilleure visibilité des informations et une qualité de service accrue.
La construction d’un entrepôt revient à faire d’abord, la mise en place d’une application web
va permettre d’alimenter l’Entrepôt (Base de données), ensuite la création du datamart, et enfin,
on va proposer la conception d’un schéma multidimensionnel qui permet de répondre aux
besoins des utilisateurs.

7
 Chapitre 1 Analyse et Conception

La conception de l’entrepôt de données est une tâche complexe et délicate. En effet, Le

problème d’évolution d’un schéma a des conséquences sur l’application chargée de l’extraction
et l’intégration de données des sources, car elle peut devenir incomplète ou incohérente vis-à-
vis du nouveau schéma de l’entrepôt. Par exemple si dans la théorie humaine les valeurs « f »
ou « m » désignent respectivement la même chose que ceux de féminin ou masculin ou encore
« RX » ou « Radio » qui sont des équivalents de radiographie, la réalité est tout autre dans les
entrepôts de données.

En effet, la difficulté liée aux données (qualité, homogénéité, disponibilité, etc.) et le lien entre
systèmes d’aide à la décision et systèmes opérationnels constituent une problématique majeure
pour la mise en place de l’entrepôt de données.
De plus, l’enregistrement manuel des informations sur des supports en papier engendrait
beaucoup de problèmes tels que la perte de temps ou la dégradation de ces dernières justifie la
création de l’application web au sein du service.

1.1. Le cycle de développement

La conduite d’un projet informatique, tel que le développement d’un système d’informations,
fait appel à des méthodes formalisées dont les principales sont : Les méthodes séquentielles
dites en cascade et les méthodes itératives (évolutive, objet).

Depuis des décennies, les projets sont gérés avec une approche classique, le plus fréquemment
« en cascade » ou son adaptation « en V », basée sur des activités séquentielles : on recueille
les besoins, on définit le produit, puis on le développe, ensuite on le test avant de le livrer au
client.

Vu que les besoins évoluent en permanence pour répondre aux changements du marché, ces
approches prédictives se sont révélées trop « rigides »parfois, sont alors apparues, dans les
années 1990, des méthodes moins prédictives ; ce sont les méthodes dites « agiles».

Après une étude exploratoire des méthodes de conduite de projet et pour répondre aux objectifs
fixés en début, le cycle de développement en « V » s’est révélé le plus approprié pour ce travail.

Le model en « V » a été imaginé suite au problème de réactivité du model en cascade.

Il permet en cas d’anomalie de limiter le retour aux étapes précédentes.

8
Les phases de la partie montantes doivent renvoyer de l’information sur les phases en vis –à-
vis lorsque des défauts apparaissent afin d’améliorer le logiciel.

Figure 1: Processus de développement du projet tiré du modèle en « V »

1.1. Méthodes d’analyses

Les applications de modélisation de processus structurent la conception du système

d'information selon plusieurs niveaux, chacun ciblant un profil d'acteurs de l'entreprise :
technique ou métier.

1.1.1. MERISE

MERISE le plus connu d'entre eux étant Merise (créé en 1978, sous l'impulsion du ministère de
l'industrie, par un groupement de 6 sociétés de services et un centre de recherche informatique)
qui propose une méthode de conception et de développement de Systèmes d'Information
complète, détaillée, en grande partie formalisée, qui garantit (en principe) une informatisation
réussie.

La méthode Merise d'analyse et de conception propose une démarche articulée simultanément

selon 3 axes pour hiérarchiser les préoccupations et les questions lors de la conduite d'un projet :

9
 Cycle de vie : phases de conception, de réalisation, de maintenance puis nouveau cycle
de projet.
Cycle de décision : des grands choix (GO-NO GO : Étude préalable), la définition du
projet (étude détaillée) jusqu'aux petites décisions des détails de la réalisation et de la
mise en œuvre du système d'information. Chaque étape est documentée et marquée par
une prise de décision.
Cycle d'abstraction : niveaux conceptuels, d’organisation, logique et
physique/opérationnel (du plus abstrait au plus concret) L'objectif du cycle
d'abstraction est de prendre d'abord les grandes décisions métier, pour les principales
activités (Conceptuel) sans rentrer dans le détail de questions d'ordre, d’organisation ou
technique.

1.1.2. l'UML

UML(Unified Modeling Language) est un langage de modélisation graphique à base de

pictogrammes. Il est apparu dans le monde du génie logiciel, dans le cadre de la "conception
orientée objet"

Voici en quelques mots une présentation du contenu de chaque type de diagramme :

cas d’utilisation : interactions entre le système et les utilisateurs (et autres systèmes
externes). Il aide dans la visualisation des exigences / besoins.
activité: séquence et parallélisme dans les activités du système ; autrement dit,
modélisation des processus métier avec les échanges de données
classes : classes, types, interfaces et relations entre eux.
objets : instances de classes définissant une configuration importante du système ;
machine à états: états des classes à travers leur cycle de vie (de la création / instanciation
des objets à leur destruction) et les événements qui provoquent les transitions /
changements d’états.
interaction, qui se décline en deux types de diagrammes :
séquence: interactions entre des objets pour lesquelles l’ordre des interactions est
important.
communications: interactions entre objets pour lesquels les connexions entre objets sont
importantes.

10
 composants : rassemblements de classes ou de composants tels que vus par l’équipe de
développement pour décomposer le système en parties de logiciel gérables (du point de
vue développement en gestion de projet) ;
paquetages : rassemblement d’éléments de modélisation par exemple pour les distribuer
entre membres de l’équipe de développement.
déploiement : unités d’installation, de configuration et de déploiement du produit fini
sur un parc de machines.

1.3. Diagrammes de cas d'utilisation

Un diagramme de cas d'utilisation est un diagramme UML qui fournit une représentation
graphique des exigences de votre système, et aide à identifier la façon dont les utilisateurs
interagissent avec ce dernier.

Un diagramme de cas d'utilisation est particulièrement approprié pour décrire toutes les tâches
pouvant être réalisées à l'aide d'un système de base de données par toutes les personnes
susceptibles de l'utiliser.

11
 GSMC
Enrigistrer un
resultat Supprimer un resultat

Gérer les resultats

Afficher liste des Modifier un resultat
resultats

<<include>>

Authentification
<<include>>

gérer etudiant

Secrétaire

supprimer etudiant
ajouter
etudiant Modifier
etudiant afficher liste etudiant

Figure 2 : Diagramme de cas d’utilisation

Un cas d'utilisation est une interaction entre un utilisateur et un système (ou une partie
d'un système). Il définit un but particulier que l'utilisateur souhaite atteindre dans le
système, sans révéler la structure interne du système.
Un acteur personnifie un utilisateur ou un groupe d'utilisateurs extérieur qui interagit
avec le système. Les acteurs peuvent être des humains ou d'autres systèmes externes.
Par exemple, les acteurs d'un réseau informatique peuvent inclure l'administrateur
système, un administrateur de base de données et des utilisateurs. Les acteurs sont les
entités dont le comportement ne peut pas être contrôlé ou modifié car ils ne font pas
partie du système que vous décrivez.
Une association est une relation unidirectionnelle qui décrit un lien entre des objets.

1.3.1. Diagrammes de Séquence Système

12
Les diagrammes de séquences sont la représentation graphique des interactions entre les acteurs
et le système selon un ordre chronologique dans la formulation Unified Modeling Language.
Le diagramme de séquences permet de cacher les interactions d'objets dans le cadre d'un
scénario d'un Diagramme des cas d'utilisation. Dans un souci de simplification, on représente
l'acteur principal à gauche du diagramme, et les acteurs secondaires éventuels à droite du
système. Le but étant de décrire comment se déroulent les actions entre les acteurs ou objets.

DiagrammeSequence Authentification

<<Actor>>: Secretaire <<System>>:GSMC

Demande d'authentification()

donner Loguin et Mot de passe ()

verififer login et mot depasse()

alt [OK] Présenter page accueil()

[echec]
Demande d'autentification()

Figure 3: Diagramme de séquence système d’authentification

13
DiagrammeSequence_1

<<Actor>>: Secretaire <<System>>:GSMC

ref

DiagrammeSequence Authentification()

Demander formulaire d'enrigistrement()

présentation du formulaire()

Saisir donner de l'etudiant()

valider ()

verifier la validiter()

alt [OK] afficher liste des etudiants()

[echec]
afficher formulaire d'enrigistrement()

Figure 4: Diagramme de séquence système d’enregistrement étudiant

14
Di agrammeSequence Li ste etudi ant

<< Actor >> :Secretai re << System >> : GSMC

ref

Di agrammeSequence Authenti fi cati on()

Demander Liste des etudiants()

Affiche liste des etudiants()

Figure 5: Diagramme de séquence système d’affichage liste étudiant

DiagrammeSequence suppression etudiant

<< Actor >> :Secretaire << System >> : GSMC

ref
DiagrammeSequence Authentification()

Demander Liste des etudiants()

Affiche liste des etudiants()

Saisir identifiant de l' etudiant()

verification identification()

alt [OK]
Réafichage de la liste des etudiants()

[echec] afficher echec de suppression()

Figure 6: Diagramme de séquence système de suppression étudiant

15
DiagrammeSequence Modifier etudiant

<< Actor >> :

<< System >> : GSMC
Secretaire

ref
DiagrammeSequence Authentification()

Demander Liste des etudiants()

Affiche liste des etudiants()

Saisir identifiant de l' etudiant()

verification identification()

alt [OK]
Affichage formulaire de modification()

[echec] affiche etudiant non trouve()

Faire la mise à jour()

vérifier la validite des données()

alt [OK] Mise à jour réussie()

[echec]
Réafiicher formulaire de modification()

Figure 7: Diagramme de séquence système de modification étudiant

16
Di agrammeSequence aj outer resul tat

<< Actor >> :Secretai re << System >> : GSMC

ref

Di agrammeSequence Authenti fi cati on()

Demander formulair d'enrigistrement

Affiche formulaire d'enrigistrement()

saisir les données()

verifer validite des données ()

al t [OK]
affiche enrigstrement reussi()

[echec]
affiche eche de l'enrigistrement()

Figure 8: Diagramme de séquence système d’enregistrement des résultats

Di agrammeSequence l i ste des resul tatas

<< Actor >> :Secretai re << System >> : GSMC

ref

Di agrammeSequence Authenti fi cati on()

Demander Liste des resultats ()

Affiche liste des resultats ()

Figure 9: Diagramme de séquence système d’affichage des résultats

17
Di agrammeSequence modi fi er resul tat

<< Actor >> :

Secretai re << System >> : GSMC

ref
Di agrammeSequence Authenti fi cati on()

Saisir identifiant de l' etudiant()

verification identification()

al t [OK]
Affichage formulaire de modification()

[echec] affiche etudiant non trouve()

Faire la mise à jour()

vérifier la validite des données()

al t [OK] Mise à jour réussie()

[echec]
Réafiicher formulaire de modification()

Figure 10: Diagramme de séquence système de modification des résultats

1.3.2. Diagrammes de classe

Un diagramme de classe est un diagramme UML qui fournit une représentation graphique des
classes, interfaces, et packages qui composent un système, ainsi que des relations entre eux.

18
 etudi ant
- i d_etudi ant : Stri ng
- nom : Stri ng
- prenom : Stri ng
1..*
- date_nai sse : Date
Uti l i sateur - sexe : Stri ng
- i d_user : i nt - facul te : Stri ng
- nom : Stri ng 1..1 Enri gi strer
- prenom : Stri ng
- l ogi n : Stri ng
1..1
- password : Stri ng

fai re obj et

1..*

resul tat
- i d_consul tati on : i nt
- date_consul tati on : Date
- type_de radi o : Stri ng

Figure 11: Diagramme de classe

1.4. Architecture Logicielle

Il existe différentes manières de structurer le code des applications interactives (celles qui
comportent une interface utilisateur).
Une des architectures, communément utilisée, et qui comporte de nombreuses variantes, est
connue sous l'acronyme MVC qui signifie Model - View - Controller.
Le principe de base de l'architecture MVC est relativement simple, on divise le code du système
interactif en trois parties distinctes :
Le ou les modèles (Models) qui se chargent de la gestion des données (accès,
transformations, calculs, etc.). Le modèle enregistre (directement ou indirectement)
l'état du système et le tient à jour.
Les vues (Views) qui comprennent tout ce qui touche à l'interface utilisateur
(composants, fenêtres, boîtes de dialogue) et qui a pour tâche de présenter les
informations (visualisation). Les vues participent aussi à la détection de certaines
actions de l'utilisateur (clic sur un bouton, déplacement d'un curseur, geste swipe, saisie
d'un texte, …).

19
 Les contrôleurs (Controllers) qui sont chargés de réagir aux actions de l'utilisateur
(clavier, souris, gestes) et à d'autres événements internes (activités en tâches de fond,
timer) ou externes (réseau, serveur).

Figure 12: Architecture Logicielle

La couche Vue est la couche en contact avec l'utilisateur de l'application web. Celui-ci interagit
avec l'application web a travers de pages web visualisées par un navigateur. C'est dans cette
couche que se situe JSF et uniquement dans cette couche.

JDBC : cette couche gère la connexion avec la (ou les) base(s) de données. Ici on utilisera la
notion de pool de connexion. Un pool de connexion est un ensemble de connexions avec la base
de données déjà instanciées. Cela permet aux requêtes de s’exécuter plus rapidement. On peut
venir connecter plusieurs couches JPA sur la couche JDBC si nécessaire.

JPA : la couche JPA (Java Persistence Annotation) est une couche d’abstraction de la couche

JDBC. Elle permet notamment de faire du Mapping Relationnel-Objet (ORM, Object-

Relationnal Mapping en anglais) qui consiste à modéliser la base de données sous forme
d’objets pour une manipulation plus simple à travers le code Java (requêtes pré-écrites, gestion

20
des liens entre les tables,…). Généralement la couche JPA contient une classe (entité) par table,
des contrôleurs (fonctions de base implémentées) et des gestionnaires d’exceptions.

DAO : Cette couche représente l’intelligence de l’application. Elle est composée d’un ensemble
d’interfaces locales (local) et distantes (remote). Les DAO (Data Access Object) permettent
d’accéder aux objets et proposent des méthodes de CRUD (Create, Read, Update, Delete).

21
 Chapitre II Les outils et environnements de développements

2.1. Les systèmes de gestion de base de données

Dans le monde aujourd'hui il existe plusieurs logiciels de gestion de base de données (Oracle,
PostgreSQL, MySQL,) utilisés autant par le grand public (applications web principalement)
que par des professionnels.

2.1.1. Oracle

Oracle est un système de gestion de base de données relationnel (SGBDR) qui depuis
l'introduction du support du modèle objet dans sa version 8 peut être aussi qualifié de système
de gestion de base de données relationnel-objet (SGBDRO). Oracle est écrit en langage C.

La base de données Oracle 11g Standard Edition One propose un outil simple et puissant de
développement d’applications Web permettant de consolider les données provenant de bases
de données Access et de feuilles de calcul Excel en offrant aux utilisateurs la possibilité de
consulter et de mettre à jour les données partagées à partir d'un navigateur Web.
Au fil des versions successives d'Oracle Database, Oracle continue à aider ses clients à
normaliser, consolider et automatiser les services de base de données sur le cloud.

Oracle Database 12c Enterprise Edition propose des fonctionnalités complètes pour la gestion
des traitements de transactions les plus exigeants, des Big Data et des charges de travail
d’entreposage de données tout en supportant :

L’intégration de Lightweight Directory Access Protocol (LDAP), la réplication intégrée

Les procédures stockés en PL-Sql (langage propriétaire Oracle, orienté ADA) ou ... en
JAVA (depuis la 8.1.7) ce qui peut s'avérer utile pour les équipes de développement.
L’assistant performant via Oracle Manager Server, possibilité de gérer en interne des
tâches et des alarmes
La gestion centralisée de plusieurs instances
Cependant, la base de donnée oracle présente quelques inconvénients tels que

22
 Prix élevé, tant au point de vue des licences que des composants matériels (RAM, CPU)
à fournir pour de bonnes performances
Administration complexe... liée à la richesse fonctionnelle
Fort demandeur de ressources, ce qui n'arrange à rien au point précité, Oracle est bien
plus gourmand en ressource mémoire que ses concurrents, ce qui implique un
investissement matériel non négligeable.

2.1.2. PostgreSQL

PostgreSQL est un système de gestion de base de données relationnelle et objet (SGBDRO)

implémenté par l'université de Berkeley. Ce système est concurrent d'autres systèmes de gestion
de base de données, qu'ils soient libres (comme MySQL et Firebird), ou propriétaires (comme
Oracle, Sybase, DB2 et Microsoft
SQL Server).
PostgreSQL offre :
La possibilité d’imposer des contraintes à l’insertion des données.
Les contraintes d’intégrités (garantie d’intégrité des données). En effet, PostgreSQL
gère automatiquement les contraintes d’intégrités liées aux clefs étrangères.
La possibilité de créer des vues. Les vues permettent de créer une abstraction sur des
requêtes fréquentes. Ces requêtes ne prennent pas de paramètres.
Supporte la majorité du standard SQL-92 et possède en plus un certain nombre
d'extensions (Java, Ruby, PL-SQL).
Cependant, PostgreSQL présente lui aussi quelques inconvénients :
Elle nécessite cependant une couche d'émulation Unix (Cygwin) pour s’installer avec
Windows. Une opération encore difficile car il faut compiler les sources.
PostgreSQL ne propose pas de solution de réplication par défaut.
La modification du fichier de sécurité pg_hba.conf nécessite un reboot pour être prise
en compte
pas possible de requêter sur plusieurs bases à la fois : chaque base nécessite sa
connexion
Sauvegardes peu évoluées
Supporte les bases de moyenne importance

23
 Il n’existe pas de services Web
Il n’existe pas d'ordonnanceur intégré
Il n’existe pas de fonctions d'agrégat OLAP
Il n’existe pas de requêtes récursives

2.1.3. SQLite

Avec sa dernière Version actuelle : 3.18, SQLite est un moteur de base de données SQL
autonome, à haute fiabilité.
Avantages

OpenSource et gratuit
Le plus petit moteur SGBDR du marché (en faite, une simple librairie C)
Porté sur C# (sous le nom de SQLite-C#)
Simple d'utilisation et d'administration
Aisément installable
Recommandé pour micro-base couplée à un programme C
Inconvénients

Fonctionnalités mimimales
Pas d'intégrité référentielle
DDL très limité (à part ajouter une colonne, mutations quasi impossibles)
Ne supporte pas les jointures externes
Pas d'ordonnanceur intégré
Volumétrie (une base = un fichier)
Pas de vue matérialisée
Pas de partitionnement
Pas de notion de rôles, pas de hiérarchisation de groupes, gestion de la sécurité
minimalist

24
 2.1.4. Mysql

MySQL est désigné comme le candidat pour remplir le rôle de gestionnaire de base de données
parce que son architecture logicielle le rend extrêmement rapide et facile à personnaliser.
Les principaux avantages de MySQL sont sa rapidité, sa robustesse et sa facilité d'utilisation et
d'administration. Un autre avantage majeur de MySQL est sa documentation très complète et
bien construite. Et pour terminer, c’est un logiciel gratuit.
Avec quatre millions de bases déployées, MySQL est le premier SGBD open source dans le
monde. Son succès tient en deux mots : simplicité et performances.
MySQL exploite aussi une cache de requêtes SQL qui améliore les performances pour les
lectures récurrentes. La montée en charge est assurée par un mécanisme de réplication maître
esclave.
Simplicité et rapidité : MySQL est connu dans le monde des logiciels open source comme
étant le plus rapide de sa catégorie. A l'origine MySQL était destiné aux applications web et
conçu pour tourner sur des serveurs web. Les critères essentiels de ces applications sont la
rapidité et la performance du serveur de bases de données.
Le serveur de bases de données MySQL : le serveur de bases de données MySQL est très
rapide, fiable et facile à utiliser. Il dispose aussi de fonctionnalités pratiques, développées en
coopération avec les utilisateurs.
Fonctionnalités générales : MySQL fonctionne sur de nombreuses plate-formes.
Dispose d'API pour C, C++, Eiffel, Java, Perl, PHP, Python et Ruby
Complètement multi-threadé, grâce aux threads du noyau. Cela signifie qu'on peut
l'utiliser facilement sur un serveur avec plusieurs processeurs.
Système l'allocation mémoire très rapide, exploitant les threads
Tables en mémoire, pour réaliser des tables temporaires
Les fonctions SQL sont implémentées grâce à une librairie de classes optimisées, qui
sont aussi rapides que possible.

25
 2.2. Les FrameWorks MVC:
Un Framework est un espace de travail modulaire. C'est un ensemble de bibliothèques et de
conventions permettant le développement rapide d'applications. Il fournit suffisamment de
briques logicielles et impose suffisamment de rigueur pour pouvoir produire une application
aboutie et facile à maintenir.

2.2.1. Struts

Créer par C. Mc Clanahan puis devenu le projet Jakartad'Apache en 2000 Basé sur le modèle
MVC2 qui contient un contrôleur principal redirigeant les requêtes vers des contrôleurs
secondaires.
Le cœur du framework Struts est une couche contrôleur basée sur les technologies les
plus acceptées Servlet/JSP, JavaBeans, ResourceBundles, XML. Struts fournit son
propre composant contrôleur
Struts intègre d'autres technologies pour offrir le Modèle et la Vue.
 Pour le Modèle, Struts peut interagir avec toutes les techniques d'accès aux données
comme JDBC, EJB (Entreprise JavaBeans), Hibernate…
 Pour la Vue, Struts n'est pas limité aux JSP, il peut fonctionner aussi avec les
Velocity Templates, le XSLT et d'autres systèmes de présentation.

2.2.2. Hibernate

C’est un logiciel, écrit en java, qui permet de faire le mapping entre Objets Java et Objets
stockés en base relationnelle en assurant la persistance. Il S’occupe du transfert des classes Java
dans les tables de la base de données et des types de données dans les types de données SQL
tout en réduisant le temps de développement de l'application en éliminant une grande partie du
code SQL à écrire pour interagir avec la base de données et en encapsulant le code SQL résiduel.

Les développeurs manipulent les classes dont les données doivent être persistantes comme des
classes Java normales.

Seule une initialisation correcte d‘Hibernate doit être effectuée, et quelques règles respectées
lors de l'écriture et de la manipulation des classes persistantes.

26
 2.2.3. JSF

Framework MVC qui reprend le modèle des interfaces utilisateurs locales (comme Swing)
 Le modèle est représenté par des classes Java, les Java beans, sur le serveur
 Les vues sont représentées par des composants Java sur le serveur, transformées en
pages HTML sur le client
 Le contrôleur est un servlet qui intercepte les requêtes HTTP liées aux applications JSF
et qui organise les traitements JSF (implicite)
Les services rendus par JSF sont :
Architecture MVC pour séparer l’interface utilisateur, la couche de persistance et les
processus métier, utilisant la notion d’événement
Conversion des données (tout est texte dans l’interface utilisateur)
Validation des données (par exemple, des champs de formulaires requis)
Automatisation de l’affichage des messages d’erreur en cas de problèmes de conversion
ou de validation
Internationalisation
Support d’Ajax sans programmation (communication en arrière-plan et mise à jour
partielle de l’interface utilisateur)
Fournit des composants standards simples pour l’interface utilisateur
Possible d’ajouter ses propres composants
Adaptable à d’autres langages de balise que HTML (WML par exemple pour les
téléphones portables).
A la lumière de ces Frameworks JSF sera privilégié dans ce mémoire

2.3. Les Bibliothèques

2.3.1. Richfaces

Richfaces disponible à cette adresse http://www.jboss.org/richfaces , selon la vitrine contient

39 composants. Ce nombre n’a pas augmenté ces dernières années mais Richfaces est livré avec
un kit de développement de composants (CDK).

Sur les compléments les plus intéressants fournis par Richfaces est Ajax Push,
nommé RichFaces Push. Cela vous permet d'effectuer des mises à jour côté client en temps réel

27
déclenchées via des événements du côté serveur. Sur le serveur, les événements sont gérés en
intégrant Java Messaging Service (JMS). Cela fournit une intégration de messagerie à niveau
d'entreprise jusqu'au navigateur! Un autre excellent ajout fourni par RF est un mécanisme de
mise en file d'attente avancé JSF 2 fournit un mécanisme de mise en file d'attente hors de la
boîte afin de séquencer les événements côté client avec l'implémentation Ajax intégrée

Malgré ces avantages de RichFaces et IceFaces utilisent tous JIRA pour suivre leurs problèmes
afin qu'ils soient sensiblement comparables. Bien que la quantité d'enjeux ouverts soit un peu
plus grande dans Richfaces, si nous les pondons par priorité, environ 93% des problèmes
Icefaces sont qualifiés de «majeur», tandis que Richfaces affiche «juste» 64% des problèmes
majeurs.

2.3.2. Icefaces

Icefaces http://www.icesoft.org qui contient 70 composants de base et un guide de démarrage.

En ce qui concerne les bibliothèques, la mise en route requiert un ensemble de bibliothèques
principales et certaines dépendances (la plupart des bibliothèques Apache commons).

Dans les coulisses, ICEfaces emploie une technique appelée « Direct-2-DOM » rendu, ou D2D
pour faire court, pour obtenir des mises à jour incrémentielles douces de page au
navigateur. ICEfaces stocke une copie du DOM, qui représente l'état de présentation du
navigateur dans une arborescence, sur le serveur. Lorsque l'utilisateur interagit avec la page, un
appel Ajax peut être effectué sur le serveur, ce qui entraîne une modification de l'état de
l'application, ce qui entraînera à son tour la restitution de la page sur le serveur. Une fois que la
page est retournée sur le serveur, et avant que la réponse ne soit renvoyée au navigateur,
Icefaces diffère les anciens et nouveaux arbres DOM pour créer une mise à jour DOM, qui
comprend les modifications essentielles à la page qui doivent être renvoyées Au navigateur.

Enfin, Icefaces dispose également d'une fonction Ajax Push intégrée (appelée ICEpush ) qui
ajoute la possibilité d'envoyer des mises à jour ajax à des groupes de clients en fonction
d'un événement serveur, sans que les clients n'aient à demander la mise à jour.

28
 2.3.3. Primefaces

Primefaces dispose d'un riche ensemble de 117 composants (composants de base plus
variantes http://www.primefaces.org/showcase/ui/home.jsf qui incluent, en plus de l'ensemble
standard de composants aussi de nombreux goodies comme HtmlEditors, Charts, Date et un
exportateur de données Excel à côté des autres.

Cette suite utilise en coulisse, jQuery avec ses widgets étonnants, plugins, thèmes et
interactions Ajax. Il est évité à propos d'autres frameworks JS / UI afin d'avoir une compatibilité
élevée entre les composants. Primefaces est plus facile à peau car il est basé sur themeroller. Il
a également plus de thèmes intégrés (environ 25) que celui qui est disponible dans Richfaces et
IceFaces.

Primefaces contient une page de démarrage. Tout ce que vous avez à faire est de naviguer sur
le téléchargement de PrimeFaces, d'ajouter le primefaces- {version} .jar à votre classpath et
d'importer l'espace de noms pour commencer. (Certaines dépendances sont nécessaires pour
traiter Excel / pdf et Fileupload).

Bien que l’atout majeur de PrimeFaces soit le jeu de composants, il comporte également divers
modules complémentaires simplifiant le développement Web et en particulier JSF. Depuis
Primefaces a dans son jQuery ADN, la plupart de ces ajouts sont basés comme des méthodes
de rappel JavaScript.

Les problèmes de primefaces sont suivis avec le code google et ils ont sensiblement moins
d’impacts que les deux autres concurrents (environ 128 questions ouvertes), bien que, ayant un
lifecyle différent et le nombre de communiqués, il est difficile de les comparer d'une manière
efficace.

29
Figure 13: Evolution des frameworks en vogue

2.4. Les Serveurs d’applications

Un serveur http, c’est un serveur qui gère exclusivement des requêtes HTTP. Il a pour rôle
d’intercepter les requêtes Http, sur un port qui est par défaut 80, pour les traiter et générer
ensuite des réponses Http. Tous les serveurs web embarquent un daemon Http (httpd) ou
équivalent qui s’occupe de cette fonctionnalité. Ainsi l’extension d’un serveur web va
permettre d’avoir la possibilité d’exécuter des programmes écrits avec des langages de
programmation (java, php, C# ou autres).

2.4.1. Le serveur Jboss

Jboss est un serveur d'application J2EE développé à partir de 1999 par un français Marc
FLEURY. Ce serveur est écrit en Java et distirbué sous licence LGPL. IL fournit un certains
nombres de modules :

JBossServer qui comporte une infrastructure constituée des conteneurs EJB, ainsi que
du Java Management Extension (JMX).
JBossMQ pour la gestion des messages JMS (Java Messaging service).

30
 JBossTX pour la gestion des transactions avec les API JTA(Java Transaction API ) et
JTS(Java Transaction Service).
JBossCMP pour la persistance CMP.

JBossSX pour la sécurité basée sur JAAS (Java Authentication and Authorization
Service).
JBossCX pour la gestion des connecteurs avec JCA (J2EE Connector Architecture).
Tomcat ou Jetty pour le support des servlets et des pages JSP.
Jboss permet grâce au JMX de chargé les différents modules, conteneurs ou plugin en
fonction des besoins. Bien entendu, Jboss permet d'implémenter ses propres services.

2.4.2. Le serveur Glassfish

GlassFish est un serveur d’applications Java EE dont le développement a été initié et est
aujourd’hui encore dirigé par SUN. Il faut tout d’abord noter que GlassFish est bel et bien un
serveur d’application Java EE complet. Il surpasse donc les capacités de Tomcat par exemple
qui ne propose qu’un conteneur de JSP /servlet sans le support des EJB entre autres. GlassFish
joue donc directement dans la cour des Websphere et autres mais surtout dans celle
de JBoss avec lequel il partage son ouverture de code. Une des plus spectaculaire est sans doute
son temps de démarrage qui est de l’ordre des 3 secondes alors qu’il avoisine les 30 secondes
pour JBoss voir beaucoup plus pour certains de ses concurrents.

2.4.3. Le serveur Jrun

JRun est un serveur d’application de Macromedia, basé sur Microsystem Java 2 Platform,
Entreprise Edition (J2EE). Macromedia a été récemment racheté par Adobe.

JRun consiste en Java Server Page (JSP), Servlets Java, Enterprise JavaBeans (EJB), de Java
Transaction Service (JST), et de Java Message Service (JMS).

JRun fonctionne avec la plupart des serveurs Web, comme Apache, IIS, et de manière générale,
tout webserver supportant Internet Server Application Program Interface (ISAPI) ou les
Common Gateway Interface (CGI).

31
Il existe 4 versions de JRUN : Développeur, Professionnelle, Avancée et Entreprise.Donnant
chacune des prestations différentes.

Développeur : Toute option, mais uniquement pour le développement, et limitée à 3

connexions simultanées
Avancée : Prévue pour le déploiement de JSP et de Servlets, en environnement en
cluster.
Professionnelle : pour les entreprises hébergeant des Servlets et des applications à base
de JSP, sur un seul serveur.
Entreprise : pour les entreprises créant et déployant des applications Java de e-
commerce.

2.4.4. Le serveur Tomcat

Apache Tomcat est un conteneur libre de Servlet JavaEE. Issu du projet Jakarta,Tomcat est
désormais un projet principal de la fondation Apache. Tomcat implémente les spécifications
des Servlets et des JSP de Sun Microsystems. Il inclut des outils pour la configuration et la
gestion, mais peut également être configuré en éditant des fichiers de configuration XML.
Comme Tomcat inclut un serveur HTTP interne, il est aussi considéré comme un serveur
HTTP (web).

Tomcat peut être utilisé en autonomie avec son propre serveur web, ou en collaboration avec
d’autres comme.

Il est constitué de composants

Catalina est le container Servlets, et implémente les spécifications de Sun pour les
Servlets et les JSP;
Coyote est le connecteur HTTP: il écoute le trafic entrant, dirige les requêtes au
moteur de Tomcat, processe la requête et renvoie la réponse au client
Jasper est le moteur JSP. Il parse les fichiers JSP pour les compiler en tant que
Servlets (gérable par Catalina).

Il est capable de détecter les modifications des fichiers et de les recompiler à la volée.

Avantages de Tomcat :

32
 Tomcat est simple, beaucoup plus que les serveurs d’application Open Source «
complets »
Il est donc plus simple d’administrer une instance Tomcat qu’un serveur
d’applications complet.
Il n’occupe que 2 ports sur la machine (8080 et 8009), alors que les autres en prennent
une dizaine.

Le choix du serveur d’application sera apache tomcat du fait de sa simple utilisation et des
nombres d’utilisateurs.

33
 Chapitre III Implémentation de l’application

Figure 14: Page d’Authentification

Figure 15: Page d’Accueil

34
Figure 16: Page d’ajout d’un nouvel étudiant

Figure 17: Liste des étudiants

35
Figure 18: Page de modification d’informations

36
Figure 19: Page de suppression d’informations

Figure 20: page d’enregistrement d’un examen

37
 Chapitre IV l’Analyse de données

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 ce mémoire, 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 une source qu’il faudra, 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 car elle doit non seulement identifier la source, mais aussi déterminer comment
extraire de celle-ci les données désirées. En plus, nous devons établir un mécanisme pour la
gestion de l’évolution. Dans ce cas, il faudra déterminer l’adaptation au niveau : de l’application
d’extraction, des agrégats.

Figure 21: Architecture générale d’un système décisionnel

38
 4.1. Etat de l’art sur les systèmes décisionnels

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.

4.1.1. Processus ETL

L’intégration des données est une étape clé dans la mise en œuvre de ce projet. En effet,
l’objectif de cette partie est de mener une réflexion sur des solutions et outils afin d’alimenter
les tables de la base de données. Parmi ces outils, on notera les ETL (Extract, Transform, Load).

4.1.2. Définition d'un outil ETL

Un ETL est une boite à outil (pro-logiciel) qui permet ainsi l’Extraction, la Transformation et
le chargement (Load) de données depuis des sources diverses(bases de données, fichiers ,…)
vers des cibles préalablement définies. Les ETL sont communément utilisés dans l'informatique
décisionnelle afin de permettre l'alimentation des datawarehouses (entrepôts de données).

De nombreux systèmes de gestion de bases de données sont supportés nativement en

lecture/écriture (Oracle, MSQL Server, DB2, MYSQL,...).De nombreux types de fichiers
peuvent également être lus ou écrits: Csv, Excel, Txt, XML, ...

Notons que la plupart des ETL disposent d'une interface graphique permettant l'élaboration des
différents scénarios d'intégration.

Le travail des développeurs en est ainsi grandement facilité, tant au niveau de la conception
que de la maintenance des traitements de données.

4.1.3. La phase d’alimentation

Elle se compose des zones de sources de données et d’extraction, de transformation et de

chargement des données.

 La zone des sources de données :

L’entrepôt de données est composé de différentes tables qu’il va falloir remplir avec des
données provenant souvent de sources diverses et hétérogènes.

 La zone d’extraction, de transformation et de chargement des données (ETL ou Extract

Transform and Load)

39
Pour alimenter l’entrepôt de données, on utilise un ETL. Cet outil peut être conçu
manuellement. Il peut aussi s’agir de logiciels propriétaires ou open source (code source ouvert
et sans licence) conçus spécialement à cet effet.

Il extrait les données à partir de leur source, procède aux transformations nécessaires et effectue
le chargement de celles-ci dans l’entrepôt de données. Ainsi il permet de manière cohérente
d’agréger, de classifier, de normaliser, de qualifier, de nettoyer et de consolider les données
extraites.

4.2. Différence entre Entrepôts et les bases de données

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 requetés 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.

Les SGBD ont été créés pour les applications de gestion de systèmes transactionnels.

Par contre, les entrepôts de données ont été conçus pour l’aide à la prise de décision. Ils intègrent
les informations qui ont pour objectif de fournir une vue globale de l’information aux analystes
et aux décideurs.

40
Tableau 1: différences entre entrepôts et les bases de données

4.3. Modélisation multidimensionnelle

La modélisation multidimensionnelle consiste à considérer un sujet d’analyse comme un point
dans un espace à plusieurs dimensions. 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).

4.3.1. Niveaux Conceptuels

Un Data Warehouse (DW) est basé sur une modélisation multidimensionnelle qui représente
les données dans un cube.

Un cube permet de voir les données suivant plusieurs dimensions.

41
 4.3.1.1. Table de faits

Une table de faits représente l’objet de l’analyse. Elle contient principalement des mesures
sous forme d’attributs représentant les éléments d’analyse. Les faits les plus utilisables sont les
numériques, les valeurs continues et additives. Une mesure est un élément de donnée sur lequel
porte les analyses, en fonction des différentes dimensions. Ces valeurs sont le résultat
d’opérations d’agrégation sur les données.

Exemple : Coût des travaux, Nombre d’accidents…

Les mesures peuvent être par exemple, nombres de personnes atteintes, nombres de villes
touchées qui sont résumées ou représentées par une moyenne. Ces mesures sont reliées
chacune à une table de dimension avec des clés étrangères.

La granularité des tables de faits est une caractéristique importante expliquée par le niveau de
détail des mesures représentées.

NB : La table de fait contient les valeurs des mesures et les clés vers les tables de dimensions.

4.3.1.2. Table de Dimensions

Une table de dimension est un objet qui inclut un ensemble d’attributs permettant à l’utilisateur
d’avoir des mesures suivant différentes perspectives d’analyse. Les attributs sont des
indicateurs pour les différentes vues d’analyses possibles. Par exemple, les ventes de produits
médicaux peuvent être analysées suivant différentes régions d’un pays, suivant des catégories
de produits ou suivant la combinaison de plusieurs de ces dimensions. Ces dimensions sont
connectées à la table de faits par des clés étrangères. Les attributs (tels que ville, pays) d’une
table de dimension sont appelés des attributs de dimensions. Les attributs d’une dimension
peuvent former entre eux une hiérarchie (ville/région/pays) permettant à l’utilisateur de voir les
données détaillées ou résumées suivant l’attribut en question. Une dimension peut avoir aussi
des attributs descriptifs qui ne sont pas utilisés pour l’analyse tels que le numéro de téléphone,
le nom d’un client, l’adresse d’un client. Les attributs descriptifs sont orthogonaux aux attributs
dimensions et ils les complètent.

42
 4.3.1.3. Hiérarchie

Il est important d’avoir des hiérarchies bien définies dans un SID. L’importance provient du
fait que la prise de décision commence par des vues générales puis les informations se détaillent
de plus en plus. En plus, si des outils OLAP sont utilisés pour l’analyse des données, il est ainsi
possible de réaliser des agrégations automatiques des données en s’appuyant sur les hiérarchies
définies.

Exemple

Dimension temporelle : jour, mois, semestre, année

Dimension géographique : agence, ville, département, région, pays

Figure 22: Représentation des hiérarchies dans une dimension

4.1.3.4. Granularité

La granularité est le niveau de détail des données dans un entrepôt de données. La granularité
détermine le volume des données ainsi que le type des requêtes que l’utilisateur peut poser.

Pour arriver à construire un modèle approprie pour un entrepôt de données, nous pouvons
choisir, soit un schéma multidimensionnel (cube), soit un schéma relationnel (le schéma en
étoile, en flocon de neige ou en constellation).

43
Figure 23: Représentation de la granularité de temps de lieu et produit

4.2.1. Niveaux Logiques

Dans les schémas relationnels ou Niveaux Logiques nous trouvons deux types de schémas. 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 deuxièmes, 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 déférents types des schémas relationnels pour le décisionnel.

4.2.2. Schéma en étoile

Il se compose du fait central et de leurs dimensions. Dans ce schéma il existe une relation pour
les faits et plusieurs pour les déférentes dimensions autour de la relation centrale. La relation
de faits contient les déférentes mesures et une clé étrangère pour faire référence à chacune de
leurs dimensions.

Avantage:

 Facilité de navigation
 Nombre de jointures limité

Inconvénients :

 Redondance dans les dimensions

 Toutes les dimensions ne concernent pas les mesures

44
Figure 24: Modélisation en étoile

4.2.3. Le schéma en flocon de neige (Snowflake)

Il dérive du schéma précédent avec une relation centrale et autour d’elle les déférentes
dimensions, qui 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 peut faciliter
l’analyse. Un autre avantage est représenté par la normalisation des dimensions, car nous
réduisons leur taille. Cependant, ce type de schéma augmente le nombre de jointures à réaliser
dans l’exécution d’une requête réduisant ainsi la navigation.

45
Figure 25: Modélisation en flocon

4.2.4. Le schéma en constellation

Le schéma en constellation représente plusieurs relations de faits qui partagent des dimensions
communes. Ces différentes relations de faits composent une famille qui partage les dimensions
mais où chaque relation de faits a ses propres dimensions.

46
Figure 26: Modélisation en constellation

4.3. ServeursOLAP (On-Line Analytical Processing)

Les données opérationnelles constituent la source principale d’un système d’information

décisionnel. Les systèmes décisionnels complets reposent sur la technologie OLAP, conçue
pour répondre aux besoins d’analyse des applications de gestion.

L’acronyme FASMI (Fast Analysis of Shared Multidimensional Information) permet de

résumer la définition des produits OLAP. Cette définition fut utilisée pour la première fois en
1995 et depuis aucune autre définition n’est plus proche pour résumer le terme OLAP.

Fast : Le temps de réponse aux demandes des utilisateurs oscille entre 1 et 20 secondes. Les
constructeurs utilisent des pré-calculs pour réduire les durées des requêtes.

47
Analysis : Le système doit pouvoir faire face à toutes les logiques d’affaires et de statistiques,
ainsi que fournir la possibilité aux utilisateurs de construire leurs calculs et leurs analyses sans
avoir à programmer. Pour cela, il y a des outils qui seront fournis par le constructeur.

Shared : Le système doit créer un contexte où la confidentialité est préservée et doit gérer les
cas où plusieurs utilisateurs ont des droits en écritures. Ce point constitue la plus grosse
faiblesse des produits actuels.

Multidimensional : C’est la caractéristique clé. Le système doit fournir des vues conceptuelles
multidimensionnelles des données. Il doit supporter aussi les hiérarchies.

Informations : L’ensemble des données et les informations nécessaires pour un produit OLAP.

Nous exposons dans la suite les divers types de stockage des informations dans les systèmes
décisionnels.

4.3.1. ROLAP (Relational OLAP)

Dans les systèmes relationnels OLAP, l’entrepôt de données utilise une base de données
relationnelle. Le moteur ROLAP traduit dynamiquement le modèle logique de données
multidimensionnel M en modèle de stockage relationnel R (la plupart des outils requièrent que
la donnée soit structurée en utilisant un schéma en étoile ou un schéma en flocon de neige).

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.

Le désavantage est que le langage de requêtes tel qu’il existe, n’est pas assez puisant ou n’est
pas assez flexible pour supporter de vraies capacités d’OLAP.

4.3.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 gestions données. Les données des sources sont

48
conformes au modèle multidimensionnel dans toutes les dimensions, les différentes
agrégations sont pré-calculées pour des raisons de performance.

Les avantages des systèmes MOLAP sont basés sur les désavantages des systèmes ROLAP et
elles représentent la raison de leur création. D’un côté, les requêtes MOLAP sont très puissantes
et flexible en termes du processus OLAP, tandis que, d’un autre côté, 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, à notre
avis, c’est qu’il n’existe pas de standard du modèle physique.

4.3.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.

Ci-dessous, nous traitons une liste des caractéristiques principales qu’un systèmeHOLAP doit
fournir :

La transparence du système : Pour la localisation et l’accès aux données, sans connaître si elles
sont stockées dans un SGBD relationnel ou dimensionnel. Pour la transparence de la
fragmentation,...

 Un modèle de données général et un schéma multidimensionnel global :

Pour aboutir à la transparence du premier point, tant le modèle de données général que le
langage de requête uniforme doivent être fournis. Etant donné qu’il n’existe pas un modèle
standard, cette condition est difficile à réaliser.

 Une 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,...

 Une réallocation automatique :

49
Toutes les caractéristiques traitées ci-dessus changent dans le temps. Ces changements peuvent
provoquer la réorganisation de la distribution des données dans le système de stockage
multidimensionnel et relationnel, pour assurer des performances optimales.

Actuellement, la plupart des systèmes commerciaux utilisent une approche hybride.

Cette approche permet de manipuler des informations de l’entrepôt de données avec un moteur
ROLAP, tandis que pour la gestion des datamarts, ils utilisent l’approche multidimensionnelle.

50
Chapitre V Conception et mise en place de notre entrepôt de données

5.1 Conception

En ce qui concerne la conception de l’entrepôt de données, le modèle en étoile simple à utiliser

permet une bonne lisibilité et une bonne performance des requêtes. Il sera constitué de tables
de dimensions, et d’une table de fait. La table de fait contiendra des données normalement
numériques, puisque d’ordre quantitatif.

Il s’agira des clés primaires de chaque table de dimension et des mesures (nombre de
consultation qui sera analysé en fonction de chaque dimension).

Figure 27: Modélisation de l’entrepôt de données

51
 5.2 Etude de quelques solutions décisionnelles

Avant de s’orienter vers la création de solutions décisionnelles complètes, les projets open
source se concentraient chacun sur un point bien précis du décisionnel.

Ainsi, les projets BIRT ou Jasper Reports permettent de composer et générer des rapports, et
les projets Mondrian et JPivot permettent de présenter des données sous forme
multidimensionnelle. Ces projets étaient et sont encore destinés à être intégrés en tant que «
composants » dans des développements spécifiques. Certaines plateformes décisionnelles open
source se basent sur ces composants déjà bien rodés et les intègrent de façon à constituer une
solution homogène, dans laquelle toutes les fonctionnalités sont disponibles dans un cadre
unique et rendues interopérables.

Dans cette partie, nous allons présenter les principaux composants décisionnels disponibles en
open source, que l’on peut regrouper dans les catégories suivantes :

 ETL : Pentaho Data Integration (ex Kettle), Talend Open Studio.

 Designer de rapport : BIRT, Jasper Report (i Report) et Pentaho Report Designer,
Spago.
 Analyse : Mondrian, JPivot, Palo/JedoxBffgvfI.
 Data mining: Weka.
 MDM : Talend MDM.

5.2.1. Spago BI

Spago est une plateforme collaborative dédiée à l’informatique décisionnelle complètement

réalisée en open source. C’est une suite d’outils intégrés facilitant le développement et la mise
en œuvre de solutions de business intelligence quel que soit le métier ou le secteur d’activité.
Cette plateforme fédère plus de vingt logiciels open source existant. Leur intégration s’est faite
en s’appuyant sur le middleware J2EE Spago Object Web, un serveur de séparation
vues/traitement/données de type MVC, qui comporte des composants de messagerie et de
dialogue XML. Spago couvre un large périmètre fonctionnel : les analyses OLAP (Mondrian),
le datamining (Weka), les requêtes, la restitution (Open Report). Spago comporte également le
logiciel d’ETL Enhydra Octopus. SpagoBI permet un développement très flexible permettant
de « mixer » l’open source avec des solutions propriétaires. Son grand avantage est donc sa

52
capacité d’intégration, ce qui permet de travailler indépendamment par briques séparées et une
meilleure répartition du travail. Son inconvénient principal est que c’est une solution jeune dans
un secteur en pleine évolution, il faut donc se tenir régulièrement au courant quant à l’ajout de
nouveaux composants et de fonctionnalités.

5.2.2. Pentaho

Pentaho est un projet ambitieux visant à créer une plateforme décisionnelle complète. Son but
n’est pas de proposer une alternative open source en matière de décisionnel, mais bien
concurrencer les leaders du marché BI. Pentaho se fonde sur des briques logiciels open sources
confirmées pour monter une plateforme robuste. Le projet Pentaho est dirigé par André
Boisvert, un des meilleurs visionnaires du monde décisionnel, qui a dirigé les principales
entreprises de ce secteur depuis 25 ans. A ses côtés, James Dixon, ancien pilier de Hyperion, et
plusieurs autres « pointures » du décisionnel. Elle seule, cette équipe crédibilise le projet
Pentaho.

5.2.3. Birt

BIRT (Business Intelligence Reporting Tools) est un outil de Reporting indépendant. Ce

logiciel a été créé en 2005 et fait partie de la communauté Eclipse. BIRT peut être intégré la
suite Pentaho dans son serveur au travers d’actions spécialement créées pour le démarrage et le
paramétrage de rapports. BIRT est considéré comme un outil simple d’utilisation tout en
fournissant une série de fonctionnalités facilitant la création de rapports de type Business
Intelligence. Il en va du tableau croisé jusqu’à la possibilité de représenter un set de données
du rapport sous forme de cube, simplifiant la création d’agrégations et de regroupements.
L’environnement de développement est doté d’un composant permettant la prévisualisation des
rapports dans Eclipse. Parmi les inconvénients majeurs de Birt nous pouvons cités la manque
de certaines fonctionnalités ce qui contraint l’utilisateur à l’associer à d’autres outils pour bien
réaliser un projet de business intelligence.

53
 5.2.4. Talend Master Management (TMDM)

Talend Master Data Management est une composante de la suite d'intégration de données open
source Talend. Elle fournit une plateforme permettant d'intégrer, nettoyer, surveiller et publier
les données référentielles d'une entreprise.

En s'intégrant dans la suite ETL de Talend, Talend MDM permet de faire de l'échange en temps
réel entre un référentiel de données et des bases d'application hétérogène.

D'un point de vue technique, les données référentielles sont stockées dans une base de données
XML eXist-db.

Le serveur MDM Talend est une application JEE déployée dans un serveur JBoss donnant accès
à de nombreux services Web. Du point de vue utilisateur, on dispose d'une application Web
permettant d'interagir avec la base de données référentielle.

5.2.5. Le serveur Mondrian

Le serveur Mondrian fait partie de la catégorie des serveurs « R-OLAP », c'est à dire qu'il
accède à des données contenues dans une base relationnelle .Mondrian exécute des requêtes
utilisant le langage MDX, également utilisé par d’autres moteurs OLAP, tel que celui de
Microsoft SQL Server. Ce langage permet de créer des requêtes dont l’équivalent en langue
SQL nécessiterait un grand nombre de requêtes et des temps d’exécution beaucoup plus longs.

Mondrian est particulièrement puissant et permet d’optimiser les temps de réponse en utilisant
des tables d'agrégats, créées au préalable, mais permet également de réaliser des calculs
complexes, en comparant des éléments sur la dimension temps ou en gérant des hiérarchies
récursives dissymétriques.

5.3 Intégration des données avec Pentaho Data Integration

L’intégration des données constitue une étape très importante car étant le point de départ de
tout système décisionnel. Cette phase commence par le choix des sources de données. Dans
notre cas la source de données provient d’un fichier Excel.

54
Nous allons lancer Wamp Server afin de pouvoir créer nos bases de données MySQL qui
servira de L’ODS. L’ODS, c'est une structure intermédiaire de gestion de données. Elle permet
de stocker des données issues d'un système de production opérationnelle de manière temporaire,
permettant un traitement ultérieur par des outils spécifiques.

Des données sont récupérées et intégrées en étant filtrées pour obtenir une autre base de
données. Cette base peut alors subir un traitement supplémentaire, permettant d'avoir d'autres
informations. Nous avons alors un accès plus rapide, car les données redondantes sont
éradiquées.

Lançons à présent l’outil Pentaho Data Integration et au niveau de la page d’accueil qui
s’affiche,

Cliquer sur le menu Fichier, pointer sur nouveau, une nouvelle transformation pour créer une
transformation.

Cliquer sur l’onglet Navigateur puis pointer sur Connexion et cliquer sur nouveau voici la
fenêtre Database Connexion qui s’affiche. Dans cette fenêtre on définit le nom de la connexion
(connexion2), le type de base de données (MYSQL), le type de serveur (localhost) et le type
d’utilisateur (root).

55
Figure 28: lancement Pentaho Data Integration (PDI)

56
Figure 29: Création de la connexion à la base de données source

A côté de navigateur se trouve l’onglet palette de création. Nous allons nous placer sur
Extraction qui contient les étapes pour récupérer différents formats de données source.

On ouvre l’étape « Extraction des donnés de puis excel » pour récupérer notre source de
données en cliquant sur parcourir puis sur ajoute.

57
Figure 30: Extraction des donnés de puis Excel

Le menu Feuilles permet d’ajouter une référence à chaque source ainsi, on clique sur
« Récupérer le nom des feuilles »

58
 Figure 31: Récupération de la feuille

Dans le menu Champs pour récupérer les champs et leurs types grâce à « Récupérer les champs
depuis la ligne d’en tète

Figure 32: Récupération des champs depuis la ligne d’en tète

59
Figure 33: Transformation des données

Nous ferons de même dans le sous menu Transformation en choisissant «Altération structure
flux» après avoir établis la liaison entre les deux étapes.
Maintenant nous allons cliquer sur Altération structure flux, sélectionner pour récupérer les
champs. Mais aussi métadonnées toujours pour récupérer les champs et valider pour finir.

La même chose sera pour l’étape Insertion et mise à jour où on définit le nom de la table cible
dans Mysql, puis la clé de recherche

60
Figure 34: Insertion et mise à jour des données

Nous allons maintenant exécuter la transformation afin que les données soient chargées dans
l’Opérational Data Store (l’ODS).

61
Figure 35: Processus ETL

5.4. Alimentation du Datamart

L’alimentation du datamart consiste à importer des données à partir d’une table (table
consultation) de l’ODS, à manipuler l’information s’y trouvant et à créer une nouvelle structure
en bout de ligne qui n’est rien d’autre qu’un magasin de données (Datamart )

62
Figure 36: Représentation du Model Multidimensionnel

On clique sur Extraction depuis table pour renseigner le champ « Connexion » en y mettant le
nom de la connexion à la base de données source et la requête SQL qui permettra de récupérer
les champs qui seront extraient depuis la table concernée.

63
Figure 37: Récupération des champs pour les analyses

De la même façon que précédemment pour l’étape « Altération structure flux », il est important
de récupérer les champs. Mais aussi métadonnées toujours pour récupérer les champs et valider
pour finir.

Pour chaque dimension on définit la connexion, le nom de la table de dimension et on récupère

les champs composants la clé de dimension sans oublier l’identifiant de chaque table.

64
Figure 38: Dimension date

65
Figure 39: Dimension sexe

66
Figure 40: Dimension faculté

67
Figure 41: Table de fait

68
Figure 42: Représentation du Model Multidimensionnel

5.5. Protection des données à caractère personnel

Selon l’Article 4-6, une donnée à caractère personnel c’est: « toute information relative à une
personne physique identifiée ou identifiable directement ou indirectement, par référence à un
numéro d'identification ou à un ou plusieurs éléments, propres à son identité physique,
physiologique, génétique, psychique, culturelle, sociale ou économique ».

Tout traitement de données à caractère personnel suppose le respect de principes de base,

notamment :

Principe d’exactitude (Art. 36) : les données à caractère personnel collectées doivent
être exactes et, si nécessaire, mises à jour.
Principe de légitimité (art. 33) : Les données à caractère personnel doivent être :

1) traitées loyalement et licitement ;

2) traitées lorsque la personne concernée a donné son consentement ;

69
 Principe de finalité (article 35) : les données doivent être collectées pour des finalités
déterminées et ne peuvent pas être traitées ultérieurement de manière incompatible avec
ces finalités.

5.6. Analyse des données

La conception d’un rapport se fait graphiquement en utilisant l’éditeur proposé par BIRT.
BIRT propose plusieurs types de composants graphiques à insérer dans un rapport, la vue
‘Palette’ affiche la liste des types de composants.

Figure 43: Connexion au Datamart

70
Figure 44: Le Nombre de consultation suivant la Dimension faculté

Figure 45: Le Nombre de consultation suivant la Dimension année

71
Figure 46: Le Nombre de consultation suivant la Dimension sexe

Les tableaux croisés affichent les données dans une matrice semblable à une feuille de calcul et
Bi-Lite-il Zero est un constructeur OLAP Cube disponible dans un certain nombre d’édition,
qui permet créer des cubes à la portée de quiconque qui est familier avec MS Access ou SQL
Serveur.

En tant qu’utilisateur Bi-Lite Cube offre une méthode rapide et efficace de produire des
prototypes entièrement fonctionnels

Cependant, Bi-Lite-il Zero n’interagit qu’avec une base Access ; ce qui entraine la
transformation du datamanig mysql.

Figure 47: Connexion à notre base de données Access

72
Figure 48: Concevoir la requête de rapport à l'aide du concepteur visuel de requêtes

73
Figure 49: Définir le contenu du cube

74
Figure 50: Analyse multidimensionnelle (faculte, sexe, annee)

Figure 51: Analyse multidimensionnelle (faculte, annee, trimestre sexe)

75
 Conclusion

La Business Intelligence (BI) se définit comme l'ensemble des technologies permettant de

traiter, valoriser et présenter les données à des fins de compréhension et de décision; elle
s’appuie sur un système d’information spécifique appelé Système d’Information Décisionnel
(SID).

La prise de décision exige la manipulation et l’analyse de grandes quantités de données d’où

l’intérêt du sujet : Mise en place d’un entrepôt de données pour l’aide à la décision au
service médical des étudiants.

Pour la réalisation et l’atteinte des objectifs, une application web basée sur le framework
primefaces et le serveur d’application apache tomcat est créée pour assurer la conformité et la
collecte des données.

Quant à l'intégration, la diffusion et la présentation des données, notre choix s’est porté sur la
plate forme Pentaho et eclipse birt qui sont des outils Open source de Business Intelligence.

En fin BI-Lite CUBE a permis La réalisation de cube pour une analyse multidimensionnelle.

76
 ANNEXE

Table des Figures et Tableaux

Figure 1: Processus de développement du projet tiré du modèle en « V » ....................................... 9
Figure 2 : Diagramme de cas d’utilisation ........................................................................................ 12
Figure 3: Diagramme de séquence système d’authentification ....................................................... 13
Figure 4: Diagramme de séquence système d’enregistrement étudiant ......................................... 14
Figure 5: Diagramme de séquence système d’affichage liste étudiant .............................................. 15
Figure 6: Diagramme de séquence système de suppression étudiant ............................................... 15
Figure 7: Diagramme de séquence système de modification étudiant ............................................ 16
Figure 8: Diagramme de séquence système d’enregistrement des résultats .................................. 17
Figure 9: Diagramme de séquence système d’affichage des résultats ............................................ 17
Figure 10: Diagramme de séquence système de modification des résultats ................................... 18
Figure 11: Diagramme de classe ........................................................................................................... 19
Figure 12: Architecture Logicielle ..................................................................................................... 20
Figure 13: Evolution des frameworks en vogue................................................................................ 30
Figure 14: Page d’Authentification....................................................................................................... 34
Figure 15: Page d’Accueil ...................................................................................................................... 34
Figure 16: Page d’ajout d’un nouvel étudiant .................................................................................. 35
Figure 17: Liste des étudiants............................................................................................................. 35
Figure 18: Page de modification d’informations ............................................................................. 36
Figure 19: Page de suppression d’informations .................................................................................. 37
Figure 20: page d’enregistrement d’un examen.................................................................................. 37
Figure 21: Architecture générale d’un système décisionnel ............................................................... 38
Figure 22: Représentation des hiérarchies dans une dimension ........................................................ 43
Figure 23: Représentation de la granularité de temps de lieu et produit .......................................... 44
Figure 24: Modélisation en étoile ........................................................................................................ 45
Figure 25: Modélisation en flocon ...................................................................................................... 46
Figure 26: Modélisation en constellation ............................................................................................ 47
Figure 27: Modélisation de l’entrepôt de données ............................................................................. 51
Figure 28: lancement Pentaho Data Integration (PDI) .................................................................... 56
Figure 29: Création de la connexion à la base de données source .................................................. 57
Figure 30: Extraction des donnés de puis Excel ............................................................................... 58

77
Figure 31: Récupération de la feuille ................................................................................................. 59
Figure 32: Récupération des champs depuis la ligne d’en tète........................................................ 59
Figure 33: Transformation des données .............................................................................................. 60
Figure 34: Insertion et mise à jour des données ............................................................................... 61
Figure 35: Processus ETL ....................................................................................................................... 62
Figure 36: Représentation du Model Multidimensionnel ................................................................ 63
Figure 37: Récupération des champs pour les analyses ................................................................... 64
Figure 38: Dimension date .................................................................................................................. 65
Figure 39: Dimension sexe .................................................................................................................. 66
Figure 40: Dimension faculté.............................................................................................................. 67
Figure 41: Table de fait ....................................................................................................................... 68
Figure 42: Représentation du Model Multidimensionnel ................................................................ 69
Figure 43: Connexion au Datamart ...................................................................................................... 70
Figure 44: Le Nombre de consultation suivant la Dimension faculté ............................................. 71
Figure 45: Le Nombre de consultation suivant la Dimension année .............................................. 71
Figure 46: Le Nombre de consultation suivant la Dimension sexe ..................................................... 72
Figure 47: Connexion à notre base de données Access ....................................................................... 72
Figure 48: Concevoir la requête de rapport à l'aide du concepteur visuel de requêtes .................... 73
Figure 49: Définir le contenu du cube ............................................................................................... 74
Figure 50: Analyse multidimensionnelle (faculte, sexe, annee) ....................................................... 75
Figure 51: Analyse multidimensionnelle (faculte, annee, trimestre sexe) ...................................... 75

78
 BIOBLIOGRAPHIE

 Pentaho Data Integration 4Cookbook, Adrián Sergio Pulvirenti et María Carina

Roldán

Sites internet
http://www.jboss.org/richfaces
http://www.icesoft.org
http://www.primefaces.org/showcase/ui/home.jsf

http://www.smiler.fr/
http://support.pentaho.com
http://www.pentaho.com/

79