P RO J E T 1 : BA S E D E

D O N N E S R E PA RT I E S
G ESTION

Elves :
David Brchet
Frdric Jacot
Charles Secrtan

D UNE BANQUE

DONNES DU PROJET

SSC - Bases de Donnes II Laboratoire de Bases de Donnes

BD rparties 1

Projet 1: Bases de donnes rparties

Un dossier est rendre le 11/01/00 lors de la soutenance.

Le but de ce premier projet est de dvelopper une application simulant le
fonctionnement dun systme de gestion de bases de donnes rparties (SGBDR).
Il sagit de reprendre lapplication vue en cours (systme bancaire) de ltoffer, et de
considrer la rpartition sur trois sites (SSCX1, SSCX2 et SSCX3).
Le travail fait intervenir les tapes suivantes:
1) Dfinir le modle conceptuel (EA) Dfinir deux vues externes: 1.
les clients et 2. les gestionnaires des comptes
2) Dfinir le modle logique relationnel. Attention ne pas oublier la
dfinition des vues.
3) Identifier et crire en SQL les requtes les plus frquentes et les
plus critiques (en terme de performance).
4) Dfinir le schma de fragmentation en fonction de ces requtes
5) Dfinir le schma de localisation (justifiez les rpliques en fonction
des problmes daccessibilit et de performance)
6) Rpartir les requtes identifies au 3) en deux sous-groupes :

Globales (faisant intervenir plusieurs sites)

Locales (faisant intervenir un site local)

Quelle est lincidence des vues sur les schmas de fragmentation et dallocation?
Il est noter que lapplication doit permettre la formulation des 4 commandes
SQL suivantes: SELECT, INSERT, UPDATE et DELETE (bien sr de faon
transparente lutilisateur) et doit mettre en uvre le protocole de validation de
transactions deux phases.

B A S E D E D O N N E S R E PA R T I E S
G ESTION D UNE BANQUE .
INTRODUCTION

Le but de ce projet est de dvelopper une application simulant le

fonctionnement dun systme de gestion bancaire. Il met en uvre un systme de
gestion de base de donnes rparties (SGBDR) et pour le rendre convivial, nous
utilisons la mthode embeded SQL qui consiste intgrer des commandes SQL
dans un environnement de programmation C.
La base de donne est rpartie sur 3 sites, qui sont la centrale et deux agences A
et B. Pour nous la centrale se trouve Genve et les agences sont Lausanne et
Neuchtel.
La centrale est un site, qui nest accessible que par le gestionnaire. Il peut
interroger un certain type de compte (courant, tudiant) sur un certain type
dopration (retrait ou versement). Il peut aussi grer un employ, cest dire quil
ajoute ou supprime un employ de la base de donne.
Dans les agences, les employs peuvent faire des versements ou des retraits sur
un compte, et linterroger, ils peuvent aussi changer un compte dagence.

MODLE CONCEPTUEL DE LA BASE DE DONNE

LE SCHEMA ENTITE ASSOCIATION

No_emp
Nom_em
Prnom

Employ

No_op
Type_op

Opration

travaille

Date_op

Type_compte
No_compte

No_agence
Compte

Est dans

Somme

Agence

Nom_agence
Addr_agence

possde

No_client
Nom

Client

Age
Adresse

Prnom

Ce schma entit association va nous permettre de dduire le schma relationnel

de la base de donne.

LE SCHMA RELATIONNEL

Grce a ce schma relationnel on va pouvoir visualiser les tables ncessaires la

base de donne. Ces tables serons ensuite fragmentes sur les diffrents sites.
Domaines
Dch20 : chanes de caractres de longueur infrieure 20.
Dch30 : chanes de caractres de longueur infrieure 30.
Dnum : entier.
Relation : Client
Attributs :NoClient : Dnum sans nul
Nom : Dch20 sans nul
Prenom : Dch20 sans nul
Adresse : Dch30 sans nul
Age : Dnum sans nul
Identifiant : (NoClient)
Dfinition : toute personne ayant un compte dans la banque
CLIENT
NoClient
213
456

Nom
Bouana
Legros

Prenom
Doudou
Herv

Age
23
55

Adresse
Ch. Soleil 13 1240 Bled
R. centrale 33 1512 Ville

Relation : Compte
Attributs : NoClient :Dnum sans nul
NoCompte :Dnum sans nul
TypeCompte : Dnum sans nul
Somme : Dnum sans nul
NoAgence : Dnum sans nul
Identifiant :

(NoCompte + NoAgence)

Identifiant externe: NoAgence rfrence une Agence

NoClient rfrence un Client
Dfinition : Compte du client dans la banque
COMPTE
NoClient
213
456

NoCompte
1234
5678

TypeCompte
courant
tudiant

Somme
12000
45000

NoAgence
1
2

Relation : Agence
Attributs :NoAgence : Dnum sans nul
Nom : Dch20 sans nul
Adresse : Dch30 sans nul
Identifiant :

(NoAgence)

Dfinition : Succursale de la banque

AGENCE
NoAgence
1
2

Nom
Lausanne
Neuchatel

Adresse
Av. de la gare 22 1230 Bled
Av. de Genve 33 1530 Ville

Relation : Employ
Attributs :NoEmp : Dnum sans nul
Nom_Emp : Dch20 sans nul
Prenom_Emp : Dch20 sans nul
NoAgence : Dnum sans nul
Identifiant :

(NoEmp + NoAgence)

Identifiant externe: NoAgence rfrence une agence

Dfinition : Employ travaillant dans une agence
EMPLOYE
NoEmp
567
786

Nom_Emp
Ducon
Lepetit

Prenom_Emp
Jules
Andr

NoAgence
1
2

Relation : Opration
Attributs :NoOp : Dnum sans nul
NoEmp : Dnum sans nul
NoCompte : Dnum sans nul
Montant : Dnum sans nul
TypeOp: Dch20 sans nul
dDate : Dch20 sans nul
Identifiant :

(NoOp)

Identifiant externe: NoCompte rfrence un compte

NoEmp rfrence un Employ
Dfinition : Opration effectue par un employ sur un compte

OPERATION
NoCompte
NoOp
1234
7890
5678
7891

Montant
1000
7000

TypeOp
retrait
versement

dDate
23/01/99 1034
25/01/99 1430

NoEmp
567
567

REQUETES FREQUENTES

Nous avons essay de sparer les diffrentes requtes utilises dans le cadre du
fonctionnement dune banque et nous navons considrer que les plus frquentes et
les plus critiques pour la base de donne. Voici donc les requtes :
VERSEMENT ET RETRAIT

Lors dun versement ou dun retrait, lemploy a besoin du numro de compte

du client et de lagence dans lequel le compte se trouve. Lors de lopration,
lattribut somme ainsi que la table opration sont mis jour.
Issu de la table Opration
NoOp

NoEmp

NoCompte

Montant

TypeOp

Issu de la table Compte

NoCompte

Somme

NoAgence

Les requtes en SQL pour un versement sont :

NoAgence
FROM Compte
WHERE NoCompte = xxx
if NOT FOUND {
maj_copie_compte();
maj_copie_operation(NoAgence);
}
else {
Update(Compte.somme);
Update(Operation.*);
}
SELECT

dDate

Pour un retrait cest la mme requte avec une opration diffrente retrait au
lieu de versement.
INTERROGATION

Lorsque le client dsire consulter les dernires oprations effectues sur son
compte, lemploy a besoin du numro de compte et de lagence dans lequel le
compte se trouve. Lattribut somme indique la solde du compte au moment de
la requte. Avec lattribut Montant , il peut dterminer la solde du compte au
moment de lopration. Les autres attributs de la table Opration nintressent
que le gestionnaire.
Table I1
NoCompte

Montant

TypeOp

dDate

Table V R-I2
NoCompte

Somme

NoAgence

Les requtes en SQL sont :

NoAgence
FROM Compte
WHERE NoCompte = input in no_cpte
if NOT FOUND {
SELECT NoCompte, Somme, NoAgence
FROM Compte_copie
WHERE NoCompte = no_cpte
SELECT Montant, TypeOp, dDate
FROM Operation_copie
WHERE NoCompte = no_cpte
}
else {
SELECT NoCompte, Somme, NoAgence
FROM Compte_copie
WHERE NoCompte = no_cpte
SELECT Montant, TypeOp, dDate
SELECT

Operation
WHERE NoCompte = no_cpte

FROM

INTERROGATION PAR LE GESTIONNAIRE

Le Gestionnaire analyse le type dopration effectue sur un type de compte. Ce

type de compte est de lagence Lausanne et Neuchtel. Pour ce faire, il a besoin des
informations suivantes issues des tables opration et compte .
Issu de la table opration
No_op

No_emp

No_compte

Montant Type_op

Date_op

Issu de la table compte

No_compte

Somme

Type_compte

No_agence

Voici la requte en SQL :

*
FROM TableOp
WHERE TypeOp=:type_op AND
NoCompte IN (SELECT NoCompte,
FROM Compte
WHERE TypeCompte = :type_cpte);
SELECT

GRER LES EMPLOYS PAR LE GESTIONNAIRE

Le gestionnaire gre les employ, il ajoute ou supprime un employ. Pour ce

faire, il a besoin des informations suivantes de la table employ .
Issu de la table employ
NoEmp

Nom_Emp

Prenom_Emp

NoAgence

Voici les requtes en SQL :

Supprimer un employ :
TableEmp
WHERE NoEmp =:noemp;
DELETE FROM

Ajouter un employ :
TableEmp,
VALUES (:noemp, :Nom_Emp, :Prenom_Emp, :NoAgeance);
INSERT INTO

SCHEMA DE FRAGMENTATION

Voici le schma de fragmentation des tables en fonction des requtes effectues

sur les attributs. Remarquons que la localisation des fragments a t faite par
rapport aux poids des requtes. Pour faire la rpartition sur les trois sites, nous
avons dcid davoir une centrale et deux agences et tout notre travail dcoule de
cette rpartition.
Table Client
NoClient
1
2
3

Nom
Jacot
Secretan
Brechet

Prenom
Frederic
Charles
David

Somme
1000
2000
3000

NoAgence
0
1
1

Age
23
56
24

Adresse
Rue a 1
Rue b 2
Rue c 3

Table Compte
NoCompte
10
11
12

TypeCompte
Etudiant
Epargne
Etudiant

NoClient
1
2
3

Table Opration
NoOp

NoEmp

20
21
22

31
30
32

NoCompte
10
11
12

Montant

TypeOp

dDate

100
200
300

Versement
Virement
Retrait

12/05/99-
13/06/99-
18/11/99-

10

Table Agence
NoAgence

Nom

Adresse

Genve

Rue du cucu 3

Lausanne

Rue des pins 1

Neuchtel

Rue de la gare 3

Table Employ
NoEmp
30
31
32

Nom_Emp
Dupond
Smith
Ducommun

Prenom_Emp
Jean
John
Georges

NoAgence
0
1
1

Localisation
Donnes relatives aux client / compte agence A
Donnes relatives aux client / compte agence B
Versement, retrait, interrogation et gestionnaire / compte agence A
Versement, retrait, interrogation et gestionnaire / compte agence B
Gestionnaire / compte agence A
Gestionnaire / compte agence B
Versement, retrait et gestionnaire / opration agence A
Versement, retrait et gestionnaire / opration agence B
Versement, retrait, interrogation et gestionnaire / opration agence A
Versement, retrait, interrogation et gestionnaire / opration agence B
Donnes relatives lemploy / agence A
Donnes relatives lemploy / agence B
Donnes gnrales

original
A
B
A
B
Centrale
Centrale
A
B
A
B
A
B
Centrale

copie
B
A
B
A
A
B
Centrale
Centrale
Centrale
Centrale
Centrale
Centrale

Cest avec ce schma de fragmentation que nous avons fait le schma

dallocation des fragments. Cela a t fait en regardant quelles taient les requtes
critiques et celles qui taient le plus frquemment utilise. Cest aussi par cette
mthode que nous avons plac les copies des fragments aux sites que nous jugions
adquat.
Dans lagence A, les fragments des tables Compte et Client sont copis dans
lAgence B. Dans lagence B ces fragments sont copi dans lagence A. Cela permet
davoir toutes les informations ncessaires disposition en local afin de minimiser
le temps ncessaire pour les requtes. Le fragment de la table opration est copi
dans la centrale car cest le gestionnaire qui en le plus besoin pour faire ses
requtes.
En plus la copie du fragment de la table Compte qui se trouve la centrale
11

SCHMA DALLOCATION

Voici la localisations sur les diffrents sites des diffrents fragments et de leur
copie tels quils ont t implment dans lapplication.
CENTRALE :
Frag_Centr_Compte
NoCompte TypeCompte
Ageances
NoAgeance Nom

Adresse

FragA_TableEmp_CP
Nom_Emp
NoEmp

Prenom_Emp NoAgeance

FragB_TableEmp_CP
Nom_Emp
NoEmp

Prenom_Emp NoAgeance

FragA_TableOp_CP
NoEmp
NoOp

NoCompte

Montant

TypeOp

Date

FragB_TableOp_CP
NoEmp
NoOp

NoCompte

Montant

TypeOp

Date

AGENCE A :
FragA_Compte
NoCompte NoClient

NoAgeance Somme

FragA_Client
Nom char
NoClient

Prenom

Adresse

Age

FragA_TableOp
NoEmp
NoOp

NoCompte

Montant

TypeOp

FragB_Client_CP
Nom
NoClient

Prenom

Adresse

Age

12

Date

FragB_Compte_CP
NoCompte NoClient

NoAgeance Somme

FragC_Compte_CP
NoCompte TypeCompte
FragA_TableEmp
Nom_Emp
NoEmp

Prenom_Emp NoAgeance

AGENCE B :
FragB_Compte
NoCompte NoClient

NoAgeance Somme

FragB_Client
NoClient
Nom char

Prenom

Adresse

Age

FragB_TableOp
NoEmp
NoOp

NoCompte

Montant

TypeOp

FragA_Client_CP
Nom
NoClient

Prenom

Adresse

Age

FragA_Compte_CP
NoCompte NoClient

NoAgeance Somme

FragC_Compte_CP
NoCompte TypeCompte
FragB_TableEmp
Nom_Emp
NoEmp

Prenom_Emp NoAgeance

13

Date

REALISATION DE LA BASE DE DONNE

STRATGIE UTILISEE

Nous avions trois sites pour faire notre banque. Nous avons donc fait deux
agences et une centrale. Cest sur ces sites que sont situs les diffrents fragments
de la base de donnes. Tous les fragments sont dupliqu et mis sur un autre site
afin de pouvoir travailler mme si un site est en panne. Chaque copie est utilisable
sur le site o elle se trouve. Cela permet de gagner du temps lorsque des requtes
utilisent les fragments originaux qui sont localiss sur dautres sites. Pour toute
requte qui fait une mise jour sur un autre site, il faut dabord vrifier que les
lments de la requtes sur le sites soient correctes avant de les envoyer sur le site
voulu, cela sappelle le commit deux phase .
Nous avons fait trois applications diffrentes pour faire cette base de donne
rpartie, linitialisation, la centrale et lagence. les applications sont implmentes en
C avec des commandes SQL dans le code. Nous utilisons Oracle comme interface
entre la base de donne et le langage C.
La premire application sert initialiser la base de donne et la peupler afin
davoir un minimum de donnes pour faire nos requtes.
La deuxime application est la centrale. Elle permet au gestionnaire de faire son
travail de vrification des comptes. Il interroge un type de compte donn et peut y
voir lopration de versement ou de retrait, effectue. Il peut grer les employs,
cest dire quil peut ajouter et enlever un employ de la base de donne en
vrifiant que cet employ existe.
La troisime application est lagence. Elle fait toutes les requtes ncessaire la
gestion des clients et des comptes de la banque. Lemploy peut ouvrir ou fermer
un compte, interroger, faire des versement et des retraits sur un compte. Il peut
aussi modifier des donnes relatives au client. Si le client change dadresse, il est
alors transfr sur lautre agence ainsi que son ou ses comptes.
Un journal se trouve sur chaque site et est mis jour chaque fois quune
requte SQL modifie un fragment de table.
Pour chaque requte impliquant une mise jour, nous vrifions chaque tape
quil ny a pas derreur gnre par la requte. Arriv la fin de celle ci, on essaie
dcrire dans le journal, si on y arrive, on fait le commit , sinon on annule tout.

14

DESCRIPTION DE LAPPLICATION
CENTRALE

Une fois le mot de passe du gestionnaire valid, les connexions avec les
diffrents sites sont tablies. Un menu propose au gestionnaire diffrents choix :
interroger un type de compte , grer un employ, soit quitter lapplication.
Pour grer un employ, le gestionnaire le choix dajouter ou de supprimer un
employ. Pour lajout dun employ dans lagence A, on prend les donnes
ncessaire, on teste si le numro demploy existe dans une des deux agences, si
non mise jour du fragment FragA_TableEmp sur le site A, ainsi que sa copie
FragA_TableEmp_CP sur le site Centrale. Ecriture sur les journaux de lagence A
et de la Centrale, si pas derreur, validation des mise jour par un commit.
Supprimer un employ, on demande le numro demploy, on recherche le
numro si le numro existe et on supprime lentre correspondante dans le
fragment FragA_TableEmp si lemploy travail lagence A, ainsi que lentre dans
la copie FragA_TableEmp_CP, aprs lcriture dans les journaux correspondants
on valide la suppression.
Pour interroger un compte qui se trouve dans lagence A, on demande le type
de compte et la transaction (versement ou retrait) et on interroge le fragment
FragA_TableOP_CP avec le type dopration et le type de transaction. Ce fragment
se trouve sur le site de la central ce qui permet de rester en local et de gagner du
temps. Pour interroger la base de donne, on utilise un tampon qui prend les
donnes requises et les transmet lapplication qui les affiches. On ne peut voir que
les transactions sur un type de compte et non sur un compte donn. Une fois
lopration faite, retour au choix initial.
AGENCE

Une fois le mot de passe de lemploy valid, les connexions avec les diffrents
sites sont tablies. Un menu propose lemploy diffrents choix : versement,
retrait, interrogation dun compte, soit changement dadresse dun client
Avant chaque opration, on vrifie lexistence et la localisation du compte.
Pour faire un versement-retrait, suivant sa localisation, par exemple lagence A,
on travail en local sur le fragment FragA_Compte ou sur FragB_Compte_CP.
Pour interroger un compte on fait une simple requte.
Pour changer dadresse on prend le compte concern, on le dplace. Les
lments de la table opration qui concerne le compte dplac et les donnes du
client sont aussi dplacs. Une fois les lments dplacs, on les efface des tables
15

dorigines. Tout cela ncessite de faire des mises jour dans les tables, donc on
ecrit dans les diffrents journaux
Une fois connect choix de lopration). Puis demande du numro de compte
ou lopration doit avoir lieu. Vrification de lendroit o se trouve le compte si le
compte est en local, on travail sur le fragment mme, sinon travail sur la copie du
fragment, ensuite lopration voulue est effectue.
Pour linterrogation, requte SQL par un tampon la base de donnes pour
ressortir les informations voulues.
Pour le versement ou le retrait, demande du montant et requte de mise a jour
des tables oprations et compte. Ces mises jour entranent une criture dans les
diffrents journaux. Une fois ces critures russies, il y a validation des mises jour
par un commit.
Pour le changement dadresse, on demande la nouvelle adresse et on met jour
les fragments concerns. Si le compte change dagence, les donnes du client, des
oprations et du compte, qui appartiennent au compte, sont aussi transfres. Les
mises jour implique dajouter des donnes dans certains fragment et de les enlever
dans dautres, toutes ces transactions sont reportes dans les journaux, si toutes les
critures sont effectues correctement, il y a alors validation des mises jour.

DESCRIPTION DES FONCTIONS

AGENCE :

void connexion(char *u)

{Introduction et vrification du login et du mot de passe ;
connexion au site u du SGBDR, avec permissions dcriture et de lecture ;}
void deconnexion()
{Dconnexion des diffrents sites ;
}
int input()
{Introduction du numro de compte ;
Vrification de la localisation du compte ( location_check(compte);
Si compteur =0,
Teste les valeurs de rvi, et suivant la valeur, aller dans interrogation(compte) ou
retrait_versement(compte) ou location_change(compte)
return 1;
}
int JournalC(char texte[])
{teste si ouverture du journal possible ;
si oui, criture de la date et du texte dans le journal ;

16

fermeture du journal ;
}
mme chose pour
int JournalA(char texte[]){
int JournalB(char texte[]){
int location_check(int compte)
{Interrogation des lments de la table FragA_Compte, o NoCompte = :compte
et mise des lments dans la structure inter_cp;
teste si erreur, cela veut dire que le compte nest pas dans FragA_Compte ;
alors Interrogation des lments de la table FragB_Compte_CP,
o NoCompte = :compte et mise des lments dans la structure inter_cp2 ;
si erreur, ce compte nexiste pas ;
location =1 ;
interrogation des lments de la table FragB_Client_CP,
o NoClient =:inter_cp2.no_client et mise dans la structure client;
affichage des lments de client.
Sinon si pas derreur, cela veut dire que le compte est dans FragA_Compte ;
location =0 ;
interrogation des lments de la table FragA_Client,
o NoClient =:inter_cp2.no_client et mise dans la structure client;
affichage des lments de client.
}
int interrogation(int compte)
{teste si location =0
alors affichage que le compte est sur A ;
excution sur ssc8a ;
dclaration dun tampon pour
interrogation de typeop et de dDate de la table FragA_TableOp,
o NoCompte = :compte et mise dans la structure inter _op ;
ouverture du tampon ;
tant quil ny a pas derreur
recherche des lments dans le tampon;
fermeture du tampon ;
affichage du nb dopration qui est le nb de tuple dans le tampon ;
si le nb de tuple =0
alors compte inxistant ;
input() ;
sortie de la fonction ;
ouverture du tampon
tant quil y a des tuples
recherche des lments dans le tampon et mise dans la structure inter_op ;
affichage des lments sortis du tampon , le montant, le type dop, la date de lOp;
fermeture du tampon
affichage de la somme ducompte ;
sinon affichage que le compte est sur B ;
excution sur ssc8b ;
dclaration dun tampon pour
interrogation de typeop et de dDate de la table FragB_TableOp,
17

o NoCompte = :compte et mise dans la structure inter _op ;

ouverture du tampon ;
tant quil ny a pas derreur
recherche des lments dans le tampon;
fermeture du tampon ;
affichage du nb dopration qui est le nb de tuple dans le tampon ;
si le nb de tuple =0
alors compte inexistant ;
input() ;
sortie de la fonction ;
ouverture du tampon
tant quil y a des tuples
recherche des lments dans le tampon et mise dans la structure inter_op ;
affichage des lments sortis du tampon , le montant, le type dop, la date de lOp;
fermeture du tampon
affichage de la somme du compte ;
compteur=1;
}

PROBLEMES RENCONTR

Difficult la compilation par le moteur doracle.

AMELIORATIONS POSSIBLE

CONCLUSION

Ce projet nous a permis de nous familiariser avec les bases de donnes rpartie,
ainsi que de plonger des requtes SQL dans un langage comme le C.
Ce projet nous a pris normment de temps pour implmenter les applications.
Le fait que le compilateur dOracle ne fonctionne pas correctement a engendrer
beaucoup de temps perdu.
ANNEXES

Listing des applications.

18