Bases de données

1/44
TER
Bases de données
2006-2007
2/44
Ministère de l'Éducation Nationale
Université Montpellier II
Rapport de TER
Master informatique
Décembre 2006
Bases de données
2006-2007
Naïtan GROLLEMUND
Jean-Marie CODOL
3/44
4/44
Remerciements
Ce rapport présente nos travaux d'analyse et le début de l'élaboration d'un site
Web pour la gestion d'une banque virtuelle et de ses agences. L'analyse représente environ
les deux tiers de notre réalisation, et pour cette partie, nous tenons tout particulièrement à
remercier Mme Thérèse Libourel (notre professeur de bases de donnée) pour les
nombreuses heures qu'elle nous a consacrées en plus des cours et des Travaux Pratiques du
semestre ainsi que Mme Isabelle Mougenot pour les Travaux Dirigés de Bases de Donnée
qui nous ont aussi beaucoup aidés.
Enfin nous remercions l'Université Montpellier 2 de nous proposer de présenter
un projet de TER, ce qui nous permet de nous spécialiser dans un domaine et de l'explorer
plus en détail.
5/44
Table des matières
1) Introduction.............................................................................................................................6
1.1) - Généralités..............................................................................................................................6
1.2) - Le sujet................................................................................................................................... 6
1.3) - Cahier des charges..................................................................................................................6
2) Stratégie de développement.................................................................................................... 8
2.1) - Outils de développement........................................................................................................8
2.2) - Collaboration permanente.......................................................................................... 11
3) Analyse du projet.................................................................................................................. 12
3.1) - Diagramme des cas d'utilisation...........................................................................................12
3.2) - Diagramme des états............................................................................................................ 14
3.3) - Diagramme des séquences................................................................................................... 15
3.4) - Diagramme des classes........................................................................................................ 18
4) Base de données....................................................................................................................22
4.1) - Création des tables............................................................................................................... 22
4.2) - Trigger..................................................................................................................................22
4.3) - Fonction................................................................................................................................23
4.4) - Procédure..............................................................................................................................23
5) Implémentation.................................................................................................................... 25
5.1) - Base de données................................................................................................................... 25
5.2) - Interface web........................................................................................................................ 26
5.3) - Client Lourd, interface administrateur................................................................................. 33
6) Discussion.............................................................................................................................41
6/44
1-Introduction
1.1- Généralités:
Ce Travail d'Etudes et de Recherche (TER) prend place dans notre formation
d'informaticien au sein de l'Université Montpellier 2 et plus précisément dans l'unité
d'enseignement ''Bases de Données'' (UMINM 132) du premier semestre de Master.
Dans cette unité d'enseignement, nous abordons les notions de :
− ' modèles relationnels et objets ',
− ' normalisations des schémas ',
− ' contraintes et triggers ',
− ' modélisation par UML et E/A ',
− ' utilisation de Power AMC ',
− 'ODL et OCL’.
L’ensemble des leçons nous a apporté un bagage que nous avons utilisé pour mener à
bien ce projet. Cependant nous avons du approfondir certaines notions, notamment au niveau
de l’analyse UML.
Enfin le deuxième point important est notre organisation, nous avons utilisé la
technologie CVS et ainsi nous avons pu travailler à distance et apprendre à utiliser cette
nouvelle méthode de travail.
1.2- Le Sujet:
Une banque possédant plusieurs agences en France, désire mettre en ligne la gestion
de divers produits financiers qu'elle propose aux clients. Nous souhaitons réaliser un site
internet proposant ces produits en ligne. Le site présentera une liste d'agences (on pourra
envisager une interface cartographique pour désigner celles-ci).
[-- Suivi d'une série de contraintes sur les produits, les clients, et les employés. --]
7/44
1.3- Cahier des charges:
Le travail demandé aborde les aspects de conception de base de données ainsi que sa
mise en oeuvre avec Oracle.
Pour cela, il nous est demandé:
1. de modéliser à l'aide d'un diagramme de classe UML L'application proposée (Ne
pas oublier les règles de gestion et les contraintes diverses).
2. de proposer deux mises en oeuvre avec Oracle, l'une avec un schéma relationnel
plat, l'autre avec un schéma relationnel-objet.
3. de réaliser l'implantation de ces 2 types de solutions.
4. de faire un bilan critique des différentes solutions.
5. de réaliser l'interface avec un langage hôte de notre choix.
8/44
2-Stratégie de développement
2.1- Outils de développement:
2.1.1- Subversion (SVN):
On utilise souvent un gestionnaire de version pour les projets de grande ampleur, ou les
projets où le nombre de développeurs est élevé. Au cours d'un TP de bases de données, on nous
a proposé (à tout le groupe de TP) d'utiliser un gestionnaire de version: Subversion.
Subversion est apparu après CVS et s’est avéré être plus performant, les clients sont déjà
présents dans la majorité des distributions linux, et sous Windows, il existe un client simple et
performant : tortoise SVN, qui s'intègre a l’explorer.
N'ayant pas reçu de mail de confirmation pour le service universitaire de Subversion, nous
nous sommes mis à la recherche de serveurs gratuits sur Internet et avons trouvé deux sites :
sourceforge.net (mais sous condition
d'avoir un logiciel anglophone et nous
sommes toujours en attente de la réponse
du jury pour le recevoir).
➢ code.google.com
(contre une simple
inscription au service mail Gmail -immédiat).
➢
Nous avons donc choisi l'offre de
code.google.com et donc à 100 Mo d'espace
de stockage par projet pour un nombre
illimité de projets (avec un wiki et un
gestionnaire de bugs [issue repository]) et le
client TortoiseSVN (pour Windows) afin de
gérer facilement les commandes d’accès au
serveur (commit, update…
toutes les
fonctionnalités de Svn sont accessibles par un
clic droit dans un dossier).
Nous travaillions donc sur 2 parties différentes à un instant t pour éviter les conflits et
restions en contact permanent via MSN Messenger pour se poser des questions et discuter des
différents choix de développement.
9/44
2.1.2- Power AMC:
Power AMC est la version française du logiciel Power Designer. Commercialisé
mondialement par Sybase, ce logiciel permet, entre autre, de modéliser des bases de
données, de générer du code SQL, de générer des données de test, et de calculer des
estimations de taille.
Il gère divers formats de sortie SQL, tel que Oracle 9i que nous utiliserons.
La modélisation intuitive (héritage, clés) et la version française claire nous facilitent
le travail.
10/44
2.1.3- Oracle Express:
En Novembre 2005, la Société 'Oracle corporation', qui commercialise 'Oracle' (le premier
Système de gestion de bases de données [SGBDR] relationnel au monde), propose ''Oracle
Database 10g Express Edition'' (version gratuite d’Oracle), à ne pas confondre avec la
technologie Express, commercialisée avec 'Oracle' en 1995.
Cette version est restreinte à des fichiers de donnée limités à 4 Giga-octets, à un seul
processeur pour son exécution, et à 1 Giga-octet de mémoire RAM au maximum.
Cette version est entièrement compatible (si différente) avec celle de l'université où nous
feront la démonstration de notre interface.
L'installation contient une interface Web (ouverte dans un navigateur) très pratique pour
visualiser et créer les tables ainsi que le logiciel SQLPLUS, le même logiciel qu'en salle de TP
donc pratique et simple d'utilisation.
2.1.4- Autres applications:
−
−
−
−
−
−
Pour ce qui est des logiciels utilisés, nous citerons:
Open Office (sous Licence GPL),
The Gimp (Licence GPL),
Notepad++ (Licence GPL).
MSN Messenger (pour communiquer hors des heures de cours)
EasyPHP (contient le serveur apache pour la création du site Web)
Eclipse (programmation de l'interface administrateur)
−
−
Systèmes d'exploitation:
Windows XP (à nos domiciles)
Linux Fedora (à l'Université)
11/44
2.2- Collaboration permanente:
Comme nous étions deux étudiants à s’occuper du projet nous avons dû nous occuper
de la répartition du travail.
Pour la phase d'analyse, cela s'est fait facilement vu que cette phase s'est faite à
l'Université en salle de TP et en amphithéâtre et donc nous étions ensemble pour discuter.
Mais pour le développement comme nous ne pouvions pas développer séparément
l'interface de la structure logique des requêtes nous avons dû être en contact permanant.
2.2.1- Phase d'analyse:
Durant la phase d'analyse, nous utilisions la méthode d' ''extreme programming'': pendant
que le premier travaillait sur powerAMC, le deuxième supervisait, proposait des solutions et
posait des questions sur ce qu'il voyait Nous échangions nos rôles régulièrement afin d’être
présent sur les deux plans.
La phase d'analyse a aussi été l'occasion de nombreuses réunions (salles de TD et
amphithéâtres) avec ou sans nos professeurs ce qui nous a permis d'avancer rapidement tout en
sachant que nous allions dans la bonne direction.
2.2.2- Phase de développement:
Grâce a SVN et MSN Messenger, nous restions en contact et à chaque fois qu’un
problème se présentait (script PL/SQL difficile, ...) il était résolu rapidement grâce a cette mise
en commun permanente des idées. De plus comme nous avions eu beaucoup de réunions
d'analyse, nous n'avons pas eu beaucoup de points sur lesquels nous avons eu des désaccords et
nous n'avons pas eu à prendre de décisions importantes séparément.
12/44
3-Analyse du projet
3.1- Diagramme des cas d'utilisation:
3.1.1- Annotations:
Nous prévoyons quatre types d'utilisateurs:
Le simple Visiteur, qui n'a pas de compte, qui a donc simplement le droit de
consulter les produits disponibles, une liste d'agence ainsi que des informations
générales sur la banque.
➢ Le Client, qui s'identifie et peut consulter ses produits ou faire des virements entre
ses propres comptes.
➢ L'Employé, qui peut consulter les produits de son agence, éditer les produits des
clients de son agence, inscrire un nouveau client ou éditer les informations d'un client
de son agence.
➢ L'administrateur, qui va gérer les employés et les agences grâce au Client lourd en
java. Il aura accès à toutes les données de la base et pourra faire une sauvegarde de la
base de données.
➢
Certains aspects n'apparaissent pas sur les schémas:
➢ Les clients et les employés ne peuvent pas avoir le même login.
➢ Un employé peut être aussi client, il aura seulement 2 login différents
➢ Un employé ne peut gérer que les clients de son agence
➢ Un administrateur n'est pas lié à une agence, il a accès à toutes les données
13/44
3.1.2- Diagramme :
14/44
3.2.1- Diagramme des états :
3.2.1- Annotations:
Les Quatre Groupes d'utilisateurs sont distingués lors du contrôle de à la connexion.
Chaque type d'utilisateur a ses fonctions disponibles.
Il peut revenir à l'accueil en se déconnectant.
On ne rentre pas le détail sur ce diagramme, mais le contrôle de connexion effectue un
test sur le fait qu'on est ou non en intranet (sécurité pour les employés).
3.2.2- Diagramme :
15/44
3.3- Diagramme des séquences:
3.3.1- Visiteurs et Clients:
16/44
3.3.2- Les Employés:
17/44
3.3.3- L'Administrateur:
18/44
3.4- Diagramme des classes:
3.4.1 – Annotations
Les 3 types d'utilisateur sont des personnes (héritage).
Tous les comptes et produits ont une racine commune (héritage).
La table opération va suivre les virements entre les comptes des clients.
3.4.1- Vue globale:
19/44
3.4.2- Coupe 1/4:
3.4.3- Coupe 2/4:
20/44
3.4.4- Coupe 3/4:
21/44
3.4.5- Coupe 4/4:
22/44
4-Base de données
Nous allons ici décrire le code SQL qui sera exécuté dans la base de données. Nous
utilisons les outils d'Oracle : code SQL classique, Trigger et programmation PL/SQL.
4.1- Création des tables :
Génération du code :
Le logiciel PowerAMC permet de générer automatiquement du code SQL à partir d'un
diagramme de classe, donc une fois notre diagramme complet nous avons utilisé cette option.
Le code de création de table est très clair et bien écris, le seul problème a été que tout les
noms de variables (nom des tables et des attributs) ont été crée avec des guillemets ce qui n'est
pas pratique après dans la programmation mais le remplacement des guillemets s'est fait
rapidement avec un simple logiciel de traitement de texte.
Contrainte :
Il a fallu rajouter des contraintes manuellement dans le code car nous n'avions pas
réussi à les intégrer dans notre diagramme des classes dans powerAMC.
La connexion à l'interface devait se faire par un login et un mot de passe. Il fallait
donc un login unique pour différencier les clients ou employés, alors nous avons ajouté une
contrainte d'unicité du login sur les tables Client, Employé et administrateur.
Notre banque était prévue pour être installée en France donc il fallait gérer les
départements français allant de 1 à 95, nous avons donc ajouté une contrainte de type CHECK
sur le numéro de département.
Séquence :
On voulait que lorsque qu'on ajoute une ‘personne’, un ‘produit’, une ‘opération’,
une ‘agence’, ou un ‘département’ leurs numéros s'incrémentent automatiquement, nous avons
pour cela utilisé des séquences pour chacune des tables cités. Les séquences commencent à 1 et
à chaque ajout sont automatiquement incrémenté de 1.
23/44
4.2- Trigger:
Unicité des logins :
Nous avions prévu qu'un employé pouvait aussi être client, donc il fallait
différencier les comptes par leur login. De plus la fonction de connexion (voir plus bas)
parcours les tables ‘client’ puis ‘employé’ or si les deux logins étaient les mêmes, la fonction
renverrai automatiquement vers l'interface client et donc la personne ne pourrait jamais accéder
à son compte employé.
Nous avons donc créer des trigger, qui lors de l'ajout d'une personne (client,
employé ou administrateur) parcourront les 3 tables, afin de vérifier que le login n'existe pas
déjà.
Ville et département :
En France les deux premiers chiffre d'un code postal correspondent au numéro de
département, il fallait ajouter cette contrainte dans notre système afin qu'il soit impossible
d'ajouter un code postal dans le mauvais département.
Nous avons donc d'abord créé une fonction (CP_to_Dept) qui à partir d'un code
postal renvoie le numéro de département, puis un trigger sur la table Ville qui à chaque ajout
vérifie que le code postal et le département correspondent bien.
4.3- Fonction :
Connexion :
Lorsqu'une personne tente d'accéder à son interface elle doit entrer son login et son
mot de passe et la fonction va vérifier que les informations sont correctes.
Une telle fonction pouvait être écrite dans le code PHP du site Web ou dans le code
java du client lourd mais nous avons préféré l'intégrer directement à la base de données pour
raison de sécurité et de simplicité d’utilisation.
La fonction va parcourir la table client, puis la table employé, puis la table
administrateur et chercher si le login/mot de passe correspond. Elle va renvoyer respectivement
1, 2 ou 3 si elle trouve, et 0 si aucune ligne ne correspond. Dans le site Web, ce numéro sera
conservé comme « droit d'accès ».
24/44
4.4- Procédure :
Insertion :
Dans notre base de donnée, il y avait plusieurs relations d'héritage ainsi lorsqu'on
ajoutait un client par exemple il fallait obligatoirement d'abord créer une personne. Nous avons
donc décidé de créer des procédures d'insertion, qui fera toutes les insertions nécessaires avant
de terminer par la table fille. Elles prennent en argument toutes les valeurs nécessaires aux
tables parentes ainsi qu’aux tables concernées.
Ainsi lorsqu'on insère un Plan epargne-logement dans la table, grâce à sa procédure
d'insertion, on insère automatiquement un produit, un compte, un livret épargne correspondant
avec le même numéro de produit (grâce au sequence.currval).
A noter qu'un employé ne pourra ajouter des clients que dans sa propre agence
donc la procédure d'ajout de client demande un numéro d'employé. Et lorsqu'on ajoute un client
dans une ville non présente dans la base de données elle est automatiquement ajoutée.
Update :
Certaine information devront pouvoir être modifier (adresse client par exemple)
donc nous avons créer des procédures d'update dans le même esprit que les procédures que les
procédures d'insertion : on rentre toutes les informations que l'on souhaite changer et toutes les
tables sont modifier automatiquement.
Suppression :
Lorsqu'on veut supprimer une personne il faut supprimer tous ces comptes en
même temps, et pour chaque produit il faut supprimé ces uplet « parents » ainsi que les
opérations. Donc lorsqu'on va supprimer un objet dans la table on va faire appel à ces
procédures qui feront toutes les suppressions au fur et à mesure.
La suppression d'un client implique la suppression de tout ces produit, il faut donc
utilisé un curseur (pl/sql) qui va parcourir chaque produit lui appartenant et faire les
suppressions.
La suppression d'un produit implique celle de toutes ces occurrences dans la base
de données (numproduit étant clé étranger presque partout), donc tous les produits qui en
héritent mais aussi toutes les opérations où le produit a été concerné, cela va poser problème car
un client ne verra plus son virement vers un produit qui a été par la suite supprimé.
Virement :
Ces procédure vont être appeler pour un virement entre deux comptes, elle va
automatiquement faire les entrés dans la table opérations et modifier les soldes des comptes
concernés. Cette procédure existe en deux versions : virement_client et virement_employe.
Virement_client ne permet que les virements entre deux comptes d'un même client (intra
client) et donc sera accessible directement par celui ci dans son interface.
Virement_employe est plus générale et permet les virements entre deux clients (inter client)
et donc sera accessible seulement par un employé. Si un client désire faire un virement vers un
autre client il devra en faire la demande à un employé dans son agence.
25/44
5-Implémentation
5.1- Base de données :
On va exécuter (grâce a la commande START ou @) chaque fichier .sql du dossier
dans la base de données dans un ordre précis :
1- drop_banque.sql : qui va supprimer tout les éléments de la banque de la base (si
jamais les tables ont déjà été créés)
2- creation_table_banque.sql : qui contient la création des tables, les contraintes, et
la création des séquences.
3- creation_fonction_trigger_banque.sql : qui contient les trigger d'unicité des
logins, la vérification des départements, et la fonction de connexion.
4- creation_procedure_insert-update-supp.sql : qui contient toutes les procédures
d'insertion, d'update et de suppressions.
5- creation_procedure_virement.sql : qui contient les deux procédures de virements
(inter client et intra client).
6- insertion_dept_banque.sql : qui va insérer tous les départements de France, ce
sont des données de base que l'on ne modifie généralement pas et reste fixe.
7- insertion_divers_banque.sql : qui va insérer un échantillon de données afin de
découvrir et tester l'interface.
26/44
5.2- Interface Web :
5.2.1- PHP et Oracle :
Nous avons décidé de créer notre interface Web grâce au langage PHP, ce langage
permet de manipuler facilement des bases de données, de gérer les résultats et de les faire
afficher en HTML.
La librairie PHP possède deux types de fonctions pour manipuler une base de
données Oracle, les fonctions de type ORA et OCI. OCI est une série de fonctions utiles pour
des versions d'Oracle supérieures ou égales à 8, pour les versions inférieures on utilisera ORA.
Afin que notre interface soit compatible avec n'importe quelle version nous avons
créer 2 classes « oracle_oci.php » et « oracle_ora.php », ainsi on les inclura au choix suivant la
version d'oracle utilisée.
Le fichier « configuration.php » contiendra les informations propres à la base de données
(accès, nom) et une inclusion d'une des classes.
Le fichier index crée ensuite un objet « sql » de la classe choisie et on pourra utiliser les
fonctions oracle.
27/44
5.2.2- Structure :
Le site est découpé en plusieurs parties qui sont inclues et gérées par la page index.
Ainsi si on veut modifier un menu ou une description il n'y qu'une seule page à éditer.
Header.php
Description.php
Menuconnexion.php
Menu.php
contenu (xxxxx.inc.php)
footer.php
Quand on clique sur un lien, seul le contenu va changer, ou rediriger vers
« index.php?p=xxxx » si la page « xxxx.inc.php » existe elle sera incluse dans le contenu, sinon
ça sera la page d'accueil qui sera affiché.
5.2.3- Visiteur :
Le visiteur est une personne lambda qui va se connecter au site. Il pourra accéder :
-aux informations générales sur la banque (page d'accueil, page d'aide).
-à une liste des agences de la banque triées par code postal (page contact) :
-au formulaire de connexion pour accéder aux interfaces client, employé ou administrateur.
Le formulaire renvoie vers la page login.php qui va gérer le contenu du formulaire et faire appel
a la fonction connexion de notre base de données, en fonction des résultats renvoyés, le visiteur
sera redirigé vers la page approprié (respectivement accueil_client, accueil_employe,
accueil_admin).
Une fois connecté on a accès aux autres interfaces.
28/44
5.2.4- Client :
Une fois connecté en tant que client on accède à l'accueil client qui va décrire ce que peut
faire le client, à savoir : consulter ses comptes, consulter l'historique des actions sur ses comptes
(virements) et faire un virement entre ses propres comptes (intra client). On remarque qu'un
bouton déconnexion est apparu dans le menu en haut (dans le header) et que le menu a changé
avec les options clients.
Liste des produits :
Dans cette page tous les produits du client sont référencés et consultables. Chaque
produit est affiché dans un tableau avec son numéro et quelques renseignements. Si on veut plus
d'information sur un produit, le lien « plus d'info » renvoie vers une page où le produit sera
détaillé.
Les requêtes utilisées pour faire afficher le tableau sont des SELECT, à noter que quand on
veut sélectionner des uplets d'une table d'où héritent d'autres tables (parents) il faut faire
attention à ne pas sélectionner aussi les uplets parents (par exemple on va sélectionner tous les
livrets épargne moins ceux où les « numproduit » sont aussi des plans épargne logement)
Détail du produit :
Le lien « plus d'info » dans la liste des produits renvoie vers cette page, chaque
attribut du produit y est décrit et tous les virements faits à partir ou vers ce compte sont affichés
(voir plus loin la page historique). La requête SQL est un simple SELECT * sur le numéro du
produit pour chaque table.
29/44
Historique :
Cette page va contenir un tableau décrivant toutes les opérations effectuées sur les
comptes du client, à chaque virement une entrée du compte crédité et du produit débité est écrite
dans la table opérations, on va donc faire afficher son contenu en fonction.
Si le virement appartient au client, le numéro de compte sera affiché, sinon ce sera
le nom du propriétaire du compte concerné. De même lorsqu'il s'agit d'un virement inter client le
responsable sera le numéro de l'employé ayant effectué le virement (si jamais il y a un
problème) sinon ce sera le client (« vous mêmes »). Les virements sont triés par date
descendante (on affiche d'abord le plus récent).
Virement intra client :
Un client sera autorisé à faire un virement entre ses propres comptes directement à
partir de son interface.
On va donc faire appel ici à la procédure « virement_client » enregistré dans la
base de données lors de l'implémentation SQL.
30/44
Le client remplit un formulaire en sélectionnant un compte à débiter et un autre à
créditer, un motif, un montant à envoyer. Le formulaire va d'abord vérifier que les données
envoyées sont correctes puis faire appel à la procédure.
En cas de problème (comme un dépassement du découvert autorisé), une erreur est affichée
et le client doit recommencer.
5.2.5- Employé :
Similairement à l'interface client, une fois connecté on accède a la page d'accueil employé
qui va décrire les possibilités. Le menu de droite va détailler chacune des fonctionnalités
(gestion des clients, gestion des comptes) et le menu sous la description va servir de menu
rapide où on pourra accéder rapidement à des pages pratiques.
31/44
Liste des clients :
Cette page permet de voir la liste des clients triés dans un tableau, on peut voir leur nombre
de produits et des « boutons » permettant d'accéder aux fonctions d'employés rapidement :
−
−
−
le bouton de la colonne « voir » envoie vers la liste des comptes d'un client
le bouton de la colonne « edit » permet de modifier les informations d'un client ainsi que
d'avoir des informations plus précises sur la personne.
Le bouton de a colonne « supp » permet de supprimer le client avec tous ses comptes.
La page se termine par un lien vers le formulaire d'ajout de client.
À noter qu'un employé ne pourra voir que les clients inscrits dans son agence, il n'a donc
pas accès à toutes les données de la table, seul l'administrateur pourra voir la liste complète des
clients.
Ajouter un client :
On va faire appel à la procédure « insert_cli » de notre base de donnée. L'employé remplit
le formulaire avec les informations sur le client et en l'envoyant va exécuter la procédure. On
peut accéder à cette page directement à partir du menu ou alors à partir de la liste des clients.
Une personne est client lorsqu'il possède au moins un compte, donc lorsqu'il s'inscrit on va
automatiquement lui ajouter un compte ordinaire, son solde sera nul et le découvert autorisé
aussi, à la demande du client on pourra le modifier ou le supprimer s'il prend un autre produit.
Modifier un client :
Cette page permet de modifier certaines informations sur le client, elle va faire appel à la
procédure « update_client ». On peut accéder à cette page a partir du menu ou alors à partir de la
liste des clients.
32/44
Supprimer un client :
Lorsqu'on veut supprimer un client, on va d'abord vérifier s'il lui reste des comptes et
toujours demander une confirmation à la suppression. Si l'employé est sûr de vouloir supprimer
la personne il va faire appel a la procédure « supp_client ».
Lorsque cette page est appelée à partir du menu, l'employé va devoir rentrer le numéro du
client, on vérifie s'il existe puis on compte son nombre de produit et on fait un « afficher un
message de confirmation ». Si on choisit de supprimer un client à partir de la liste des clients on
arrivera directement sur le message de confirmation.
Liste des comptes :
Le menu rapide employé (sous la description) contient un formulaire qui permet d'accéder
directement à la liste des produits d'un client a partir de son numpersonne.
La liste des produits d'un client est exactement la même que la version de l'interface client
(on incluse le fichier) sauf que l'on rajoute les options employé a savoir : l'ajout, l'édition ou la
suppression d'un produit. On peut de la même façon suivre le lien « plus d'info » qui décrit
précisément le produit sélectionné ainsi que son historique, toujours pareil à l'interface client.
33/44
Ajouter un produit pour un client :
Pour ajouter un produit, on entre d'abord le numéro de client dans le formulaire puis on
valide, on va ainsi accéder à une page où il sera possible d’ajouter tous les produits gràce à de
simples formulaires Chaque formulaire d'ajout de produit est un fichier à part qui est inclus,
ainsi les traitements sont faits dans des pages différentes, c'est plus pratique s'il faut modifier
un formulaire (ajout un attribut par exemple).
Chaque page d'ajout utilise la procédure insert du produit que l'on a entré dans la base
de données.
Modifier un produit :
Cette page permet de modifier certaines informations sur le produit, elle va faire appel à la
procédure enregistrée dans la base de données. On peut accéder à cette page a partir du menu ou
alors à partir de la liste des produits grâce au lien.
Supprimer un produit :
On entre le numéro de client et le numéro du compte et on valide le formulaire qui va
utiliser la procédure « supp_produit » de la base de données.
34/44
5.2.6- Administrateur :
L'interface administrateur a d'abord été prévu pour le site Web donc la page d'accueil a été
écrite et lorsqu'on entre un login/mot de passe administrateur on accède à la page d'accueil qui
va décrire les fonctionnalités du compte.
Mais nous avons par la suite décidé de créer plutôt un client lourd en java avec l'interface
administrateur donc la section administrateur du site a été laissé de coté mais elle pourrait être
facilement implémenté à la manière des interfaces clients et employés.
5.3- Client lourd, interface administrateur :
D'une part pour garantir une sécurité évidente (attaques http, failles PHP bien connues,
...), et d'autre part pour explorer les possibilités offertes par objc (librairie java pour les
connexions aux bases de données Oracle), nous avons développé une interface Java/Swing que
peuvent utiliser les administrateurs de la banque pour consulter et gérer certains éléments de
leur banque.
L'avantage moins évident d'un tel développement est l'analyse des possibilités offertes par
le déploiement d'une plateforme RPC (Plateforme Client Riche [Rich Client Platform]), en
effet, bien que nous n'ayons pas exploité ce mode de développement (car ce n'était pas une
priorité), il faut bien avouer qu'une telle technologie est utile surtout pour un administrateur qui
veut (à priori), une interface réactive avec des accès possibles aux ressources locales
( périphériques de stockage, look-and-feel, ... ).
Le langage java offre l'opportunité de développer rapidement (à l'aide de plugins) des
interfaces conviviales et fluides .Cependant la gestion des 'processus légers' (Threads) doit être
gérée contrairement aux interfaces Web .Ojdbc est présent dans le répertoire d'installation
d'Oracle pour Windows. Avec le développement sous Eclipse, il faudra préciser les astuces
d'intégration de la librairie Oracle dans l'exécutable jar pour avoir une application réellement
portable.
35/44
5.3.1 - L'accès a la base :
Pour le développement de l'interface, nous avons reliés le projet Eclipse à la librairie ojdbc
avec les propriétés du projet.
Puis nous avons installé un plugin (payant mais en version d'évaluation) nommé
''SWT&Swing designer''. Ce plugin permet de construire une interface très rapidement et produit
un code source propre et performant.
L'accès à la base de la banque se fait par des saisies dans des champs texte et password.
Attention, les informations sont relatives à la base de donnée, le contrôle du login de
l'administrateur vient après.
36/44
Il se peut que les informations données soient erronées, ou bien que le serveur soit hors
service, alors un message d'erreur peut apparaître :
5.3.2 - L'accès administrateur :
Sinon on arrive à un deuxième panneau.
Celui de l'authentification de l’administrateur.
Indication: en Swing, le rafraîchissement de panneau se fait en supprimant tout le contenu
d'un panneau (removeAll()), puis en reconstruisant le Layout (setLayout(LayoutManager)), en
ajoutant le nouveau contenu (add(Component)), et en appelant la reconstruction (validate()) .
37/44
Et éventuellement au message d'erreur classique :
5.3.3 - Manipulation des Employés :
L'administrateur peut, à travers cette interface, consulter et éditer les informations sur les
employés, en cliquant sur le tableau de gauche, il peut afficher les informations détaillées sur
un employé. Par un simple click (avec confirmation), supprimer un employé.
38/44
Indication: Certains éléments sont présents sur touts les panneaux :
➢ Un lien pour se déconnecter.
➢ Un lien pour rafraîchir les données (synchronisation avec la base).
➢ Un filtre sur les données (sauf pour les interfaces de création).
➢ Un menu déroulant présentant toutes les possibilités de l'interface :
➢ déconnexion.
➢ liste et ajouter des employés.
➢ liste des clients.
➢ liste et ajouter des agences.
➢ éditer les villes.
➢ quitter le programme (avec popup de confirmation).
L'administrateur peut aussi ajouter des employés :
39/44
5.3.4 - Manipulation des Clients :
L'administrateur peut voir la liste de tous les clients (pas seulement ceux d'une agence),
mais ne peut pas influencer sur les soldes (ni même les consulter).
40/44
5.3.5 - Manipulation des Agences :
L'interface permet de visualiser les agences, voir pour chaque agence le nombre d'employés,
de clients, et de produits .D'ajouter, de supprimer une agence (sélectionner la ligne dans le
tableau et cliquer sur le bouton ''supprimer l'agence'').
Le filtre est disponible et permet de diminuer le nombre de lignes du tableau.
41/44
5.3.6 - Manipulation des Villes :
Au cours de la création d'un client, un employé a la possibilité de créer une ville avec
un code postal, s'il s'est trompé, l'administrateur peut rectifier le code postal pour le nom de
ville, et ainsi modifier le nom de la ville pour tous les clients, tous les employés, et toutes les
agences qui ont pour code postal ce code postal.
5.3.7 - Améliorations possibles de l'interface :
La principale amélioration serait de mettre un curseur d'attente pendant les
connexions et exécutions des requêtes (en manipulant des threads).
La seconde serait de redimensionner les tableaux en fonction de la taille de la fenêtre
(utiliser un LayoutManager plus ergonomique, mais plus complexe à manipuler).
Mettre en place une plateforme complète de mise a jour de version (RPC), ce qui
rendrait le client beaucoup plus complet, serait un autre objectif.
Enfin au niveau des fonctionnalités, il faudrait ajouter une coloration des clients ayant
un compte dans le rouge, faire une sauvegarde de l'état de l'agence, ou encore avoir une vue
spatiale des agences.
42/44
5.3.7 - Un mot sur Eclipse et ojdbc :
Pour intégrer obdbc.jar dans le projet eclipse, une simple configuration suffit,
cependant au moment de compiler et générer l'exécutable jar, on perd le classpath du projet
Eclipse.2 solutions :
➢ Décompresser l'archive ojdbc (avec 7zip par exemple) intégrer les .class dans le
projet, générer le .jar et cela fonctionne (c'est la solution que nous avons choisie).
➢ Intégrer ojdbc.jar dans le projet, faire un ''loader de .jar'', charger dynamiquement au
lancement du programme le contenu de ojbdc.jar et lancer l'interface.
Malheureusement il n'existe pas de chargeur de .jar dans l'API java SE, et sur internet,
nous n'avons trouvé que des chargeurs défaillants ou en développement.
Pour le reste du développement, nous avons réutilisé les techniques vues en TP.
Indication: pour faire appel a une procédure en java avec ojdbc, il faut:
➢ créer un Objet Connexion,
➢ créer un objet Statement (C.createStatement()) ,
➢ executer la requête (req.executeQuery('' begin
nom_procedure('arg1','arg2',...) ; end ; '')) ,
L’exception pouvant être levée est du type SQLException .
Indication: utiliser la fonction Oracle to_date comme ceci :
 update Personne
set datenaissance=to_date('84-01-23','YY-MM-DD')
WHERE numPersonne='3' ;
43/44
6-Discussion
Au final, on s'aperçoit que même s'il est fonctionnel notre système est loin d'être complet.
En effet il manque certaines choses qui en feraient une vraie interface bancaire, professionnelle
et sérieuse.
D'abord, un manque évident du contenu, les pages du site Web accessibles par le simple
visiteur sont vides d'informations. on pourrait aussi opter pour une meilleure mise en page.
D'autre part il manque des fonctionnalités, il n'y a quasiment aucun système de communication
entre la banque et le client. A l'avenir on pourrait mettre un système de messagerie entre un
client et un employé, lorsqu'un client aurait besoin de faire une action nécessaire, il pourrait
remplir un formulaire que l'employé recevrait et validerait, cela faciliterait la rapidité et la
qualité des services. Il faudrait aussi améliorer la sécurité: actuellement les mots de passe sont
stockés en clair dans la base de données et un employé peut voir les mots de passe des clients
de son agence ce qui est impossible pour une banque professionnelle. Ajouter une
authentification ssl serait indispensable.
Mais le site Web et le client lourd sont actuellement seulement l'implémentation des
fonctions de notre base de données dans 2 interfaces simples et aussi claires que possible pour
le temps imparti. De plus la structure du site et de la base de données est très évolutive, il est
très simple de rajouter des requêtes SQL et des procédures PL/SQL dans la base de données et
de rajouter des pages pour implémenter ces fonctions sans tout changer.
Malgré certains manques, le système est fonctionnel et prêt à évoluer.
44/44
Conclusion
Ce travail d'étude et de recherche (TER) nous a permis de développer les étapes d'un
projet. Nous somme passés de la théorie à la pratique, de l'analyse à l'implémentation dans
une optique professionnelle.
La phase d'analyse nous a permis d'étudier correctement le sujet et de savoir clairement
ce que nous devions faire et quels étaient les besoins du projet. Puis nous avons pu améliorer
nos connaissances en base de données et dans le logiciel oracle lors de la création des tables
et des fonctions. Enfin nous avons découvert et amélioré nos connaissances pour créer une
interaction entre une interface PHP ou java et une base de données oracle.
Ce projet nous a aussi obligé de développer une communication quasi permanente dans
le groupe, notamment grâce au protocole SVN qui nous a permis de travailler à distance sans
problème, et obtenir un travail clair et correctement organisé.
Grâce à ce travail, nous avons donc amélioré nos connaissances en base de données et
notre organisation et ainsi développer un projet de façon professionnelle.