RAPPORT SUR LE PROJET DE BDA : AGENCE DE VOYAGES

DESENNE Nicolas
LEGUAY Gaël
ZHU Min
RAPPORT SUR LE PROJET
DE BDA : AGENCE DE VOYAGES
Sujet présenté par : M. Prudence
Page :1/18
Table des matières
Cahier des charges................................................................................................................................3
Besoins fonctionnels........................................................................................................................3
Ensemble de besoins fonctionnels..............................................................................................3
Ensemble de besoins particuliers................................................................................................3
Besoins non fonctionnels.................................................................................................................4
Description des tables...........................................................................................................................5
Diagramme de la base de données principale..................................................................................5
Explication des tables de la base de données principale..................................................................5
Diagramme de la base de données Facturation................................................................................7
Explication des tables de la base de données Facturation...............................................................8
Description des fonctions, procédures et triggers.................................................................................9
Description des fonctions.................................................................................................................9
Description des procédures..............................................................................................................9
Description des triggers.................................................................................................................10
Description des modules développés..................................................................................................12
Client..................................................................................................................................................12
Vendeurs.............................................................................................................................................13
Facture................................................................................................................................................14
Description du générateur de données................................................................................................15
Pourquoi faire un générateur de données?.....................................................................................15
Comment marche-t-il?...................................................................................................................15
En quoi cela va-t-il nous aider?.....................................................................................................15
Justification des choix effectués.........................................................................................................17
Choix des tablespaces....................................................................................................................17
Choix des tables.............................................................................................................................17
Page :2/18
1 Cahier des charges
Décrivons ici l'ensemble des besoins que nous avons identifiés pour notre application. Nous
devons séparer nos différents besoins : besoins fonctionnels et besoins non fonctionnels.
1.1 Besoins fonctionnels
1.1.1 Ensemble de besoins fonctionnels
Nous retrouvons l'ensemble l'ensemble des besoins suivent :
Chercher un circuit. Un client pourra chercher un circuit selon les critères suivants:
le nom, la destination, une fourchette de prix et/ou une durée.
Chercher un hôtel. Un client pourra chercher un hôtel selon les critères suivants: la
ville où se situe l'hôtel, la catégorie, une fourchette de prix et/ou le type de chambre.
La ville où se situe l'hôtel est un critère obligatoire pour la recherche.
Chercher un vol. Un client pourra chercher un vol selon les critères suivants: la ville
de départ et la ville d'arrivée, la date et/ou une fourchette de prix.
Afficher un circuit. Pour chaque circuit, on affiche le nom, le pays, le prix de base,
l'itinéraire, la description.
Afficher un hôtel. Pour chaque hôtel, on affiche une image de cet hôtel, le nom,
l'adresse, la description, les types de chambre proposés, le prix par type de chambre.
Créer un compte client. Un client doit s'inscrire afin de réserver un produit (vol,
hôtel, circuit). Pour l'inscription, on saisit le nom, prénom, l'adresse, le code postal,
la ville, la date de naissance, le titre.
Ajouter un produit. Un client peut ajouter un produit (vol, hôtel, circuit) dans son
panier. Il ne lui est pas obligé de le réserver.
Réserver un produit. Un client peut réserver un produit (vol, hôtel, circuit) qui est
dans son panier.
Édition de la facture. L'employé de l'agence peut éditer les factures des clients. Une
ligne de facturation est liée à un client avec une adresse et un montant par prestation.
1.1.2 Ensemble de besoins particuliers
Nous avons également des besoins particuliers. Voyons ensemble quels sont ces
besoins :
Automatisation :
● Des effacements des données vieilles de plus de 10ans.
● De la génération de facture après paiement d'une réservation.
Page :3/18
1.2 Besoins non fonctionnels
Voyons maintenant l'ensemble de nos besoins non fonctionnels :
Interface: L'interface doit être ergonomique et simple à utiliser.
Pré-requis: Le site web est basé sur une base de données Oracle 10g.
Facturation: La facturation est un modèle à part entière.
Page :4/18
2 Description des tables
Nous allons voir maintenant l'ensemble des tables de nos base de données. Nous allons
expliquer le diagramme entité-relation de chacune de ces bases et ensuite nous allons décrire
les tables qui les composent.
2.1 Diagramme de la base de données principale
Afin de mieux analyser et structurer la base, nous avons d'abord défini ce diagramme
entité- relation. Il représente la base du côté client et répond à la plupart des demandes
fonctionnelles.
2.2 Explication des tables de la base de données principale
Après avoir étudié les besoins fonctionnels, nous avons créé les tables suivantes:
•
CITY
Cette table contient les villes des pays. Chaque ville contient un numéro, un nom et
le nom du pays auquel il appartient. Étant donné qu'il existe peut-être deux villes
ayant le même nom, on décide d'attribuer le numéro comme la clé primaire de cette
table. Il n'existe pas de table représentant un pays dans notre base, car l'attribut pays
n'apparaît que dans la table CITY. C'est la raison pour laquelle nous décidons
d'ignorer la table pays.
Page :5/18
•
HOTEL
Chaque hôtel de la base est identifié par un numéro. Un hôtel appartient à une et une
seule ville.
•
TYPEROOM
Nous avons décidé que chaque hôtel a au moins un type de chambre (chambre d'une
personne, chambre double etc). Et à tout moment, on pourra ajouter un type de
chambre à un hôtel quelconque. C'est la raison pour laquelle on a décidé de créer
cette table.
•
FIGHT
On gère également les vols. Étant donné que le client peut n'acheter dans notre
agence de voyage que les billets d'avion, nous proposons une liste de vols
disponibles selon les critères recherche du client. Tous les jours nous avons des vols
différents et cette table sera modifiée fréquemment. C'est la raison pour laquelle,
malgré que cette table sera consultée assez souvent, nous n'avons pas mis de Index
dans cette table.
•
TYPEFIGHT
Même raisonnement que la table TYPEROOM, pour chaque vol, on propose
plusieurs tarifs différents (tarif adulte, tarif enfant etc). On pourra ajouter pour
chaque vole un nouveau tarif.
•
CIRCUIT
Notre application propose aux clients des circuits. Ces circuits sont composés par
une liste de villes à visiter. Le tarif, le nombre de journées, le nombre de places
disponibles sont des informations propres à un circuit.
•
CITY_HAS_CIRCUIT
Afin de mieux gérer un circuit, on ne stock pas tous les villes du circuit dans cette
table. C'est la raison pour laquelle nous avons créé cette table. Cette table relie un
circuit avec les villes du circuit. Étant donné qu'il y aura beaucoup de recherche sur
cette table, et cette table ne sera pas modifié très fréquemment (juste un ajout d'un
circuit de temps en temps), nous avons décidé de mettre les deux clef primaires en
Index, afin de faciliter et accélérer la vitesse de recherche.
•
RESERVATION
Notre application propose également aux client une réservation. Le client peut
réserver un circuit, un vol, un hôtel (plus précisément une chambre). On veut savoir
également si le client a payé ou non un produit et le vendeur qui lui as vendu ce
produit. Afin de connaître le type de produit que le client a réservé, nous avons créé
trois tables associées: typefight_has_reservation, circuit_has_reservation,
reservation_has_typeroom.
Page :6/18
•
TYPEFIGHT_HAS_RESERVATION
•
Cette table nous permet de connaître les détails d'une réservation concernant à un
vol. Si le client possède une réduction sur cette réservation, le montant de cette
réduction sera indiqué dan l'attribut « offer ». Malgré cettte table sera souvent
consultée, elle n'a pas d'Index, car elle sera modifiée très fréquemment.
CIRCUIT_HAS_RESERVATION
Même raisonnement que la table typefight_has_reservation, cette table nous permet
de savoir tel client a réservé tel circuit et si ce client l'a réglé. Elle contient également
l'attribut « offer » pour la réduction.
•
RESERVATION_HAS_TYPEROOM
Cette table nous permet de connaître tel client a réservé tel hôtel et tel chambre.
•
SELLER
Nous avons besoins d'enregistrer les information d'un vendeur. C'est la raison pour
laquelle nous avons créé cette table qui intervient dans tous les réservations. Cela
nous permet de connaître le travail fait par un vendeur et conclure l'efficacité d'un
vendeur.
•
CUSTOMER
Bien évidemment on a besoin d'une table client qui enregistrer les informations d'un
client. Cette table sera mise à jour une fois tous les six mois. Les clients qui n'ont pas
d'achat ni de réservation depuis six mois seront supprimés de la table. Cela nous
permet de faciliter la gestion de table et de garder une table efficace.
2.3 Diagramme de la base de données Facturation
Nous pouvons voir sur ce diagramme que cette base est très simple puisqu'elle ne
regroupe que l'ensemble des factures qui ont été éditées. Nous avons conçu nos factures
en deux parties (deux tables). La première regroupe les informations sur les clients, le
vendeur, la date d'achat. La seconde table regroupe les lignes de factures qui contiennent
les information sur les produits achetés.
Page :7/18
2.4 Explication des tables de la base de données Facturation
Voici un description de nos deux tables de la base de données Facturation.
•
FACTURE. Cette table contient les informations concernant le client qui a payé la
facture : son nom, son prénom, son ville de résidence, son adresse, son code postal et
son pays. Cette table contient aussi le numéro du vendeur qui a émis la facture.
•
LIGNES. La table lignes contient toutes les lignes de facture existantes. Bien
évidemment, nous pouvons avoir plusieurs lignes pour la même facture. Une ligne
de facture contient la référence du produit qui a été acheté, sa désignation, son prix
unitaire et la quantité achetée. Nous avons également ajouté un champ pour la remise
faite sur le produit.
Page :8/18
3 Description des fonctions, procédures et triggers
Nous allons expliqué dans cette sections les différentes procédures et fonctions que nous
avons créées.
3.1 Description des fonctions
Commençons pour jeter un coup d'oeil à nos fonctions.
●
Fonction createFacture :
Function createFacture (datef in date, lastName in varchar,
firstName in varchar, city in varchar,
address in varchar, postcode in varchar,
country in varchar, seller in integer)
return integer
Pour assurer le bon fonctionnement de notre application et notre base, nous préférons
que l'application utilise une fonction stockée plutôt qu'une requête SQL pour
l'insertion d'un enregistrement dans la table FACTURE. La création d'une facture
concerne uniquement celle des entêtes de la facture, la date, les informations du
client, le numéro du vendeur etc. Elle nous retourne le numéro de la facture créée.
●
Fonction calculFacture :
Function calculFacture (idFacture in INTEGER) return float
Au lieu que ça soit l'application qui calcule le total d'une facture, on préfère stocker
une fonction une fois pour toute. Cette fonction permettant de calculer le montant
total d'une facture, prend un numéro de facture en paramètre et retourne le montant
calculé. Au sein de la fonction, on utilise un curseur LFACTURE représentant les
colonnes unitPrice, quantity et offer de la table LIGNES correspondant à idFacture.
A l'aide d'une boucle WHILE, ce curseur parcourt toutes les lignes de la facture afin
que l'on puisse calculer la somme totale.
3.2 Description des procédures
Voyons maintenant quelles procédures nous avons décidé d'implémenter.
●
Procédure addLine :
Procedure addLine(idFacture in INTEGER,
reff in VARCHAR, designation in varchar,
unitPrice in float, quantity in float,
offer in float)
Cette procédure nous permet d'ajouter une ligne à la facture. Une ligne correspond
généralement à un produit, une ou plusieurs chambres par exemple. Une facture a au
Page :9/18
moins une ligne. Pour appeler cette procédure, on a besoins du numéro de la facture.
C'est la raison pour laquelle la fonction createFacture doit être appelée en première.
Au sein de la procédure, on utilise une variable « maxi » pour calculer la clé « num »
de la table LIGNES. On ne pourra pas utiliser SEQUENCE, car « num » incrémente
de façon indépendante du nombre d'enregistrement de la table. Il dépend au
idFacture.
●
Procédure removFacture :
Procedure removFacture
Comme on peut le voir, cette procédure ne demande aucun paramètre. La
suppression de factures est déclenché par un responsable de service facturation. On
ne supprime que des factures ayant plus que dix ans dans la base. Cette procédures
cherche toutes ces factures et les supprime de façon automatique. S'il n'y a aucune
facture correspond à cette condition, un message sera affiché.
3.3 Description des triggers
Un trigger permet d'automatiser certains traitements assurant la cohérence et l'intégrité
de la base de données. Une séquence permet de générer une série de nombres.
Généralement une séquence est utilisée pour générer les clés primaires d'une table. Nous
avons combiné ces deux objets de Oracle afin d'obtenir une meilleure gestion des clés
primaires.
Nous avons créé plusieurs triggers et séquences dans les deux parties: vendeur et facture.
La plupart des triggers et séquences ont le même objectif, nous n'allons pas tous citer
mais sélectionner ceux ayant des fonctionnalités différentes.
1. TRIGGER trg_idFacture BEFORE INSERT ON Facture
Avant d'insérer une ligne dans la table FACTURE, ce trigger ajoute une clé primaire à
cet enregistrement à l'aide de la séquence stockée seq_facture.
SELECT seq_facture.nextval
INTO :NEW.idFacture
Grâce à ce trigger, nous n'avons plus besoins de spécifier la clé primaire « idfacture ».
2. TRIGGER trg_removFacture AFTER DELETE on Facture
Lorsque l'on supprime une facture, on doit supprimer toutes les lignes de cette facture.
C'est la raison pour laquelle nous avons créé ce trigger. Voici l'instruction pour
supprimer les lignes correspondant à cette facture:
DELETE FROM Lignes where Facture_idFacture = :old.idFacture;
Page :10/18
3. CREATE SEQUENCE seq_facture
START WITH 1
MINVALUE 1
NOCYCLE
NOCACHE
ORDER;
Cette séquence est utilisée dans le trigger trg_idFacture permettant de commencer à
numéroter par un et incrémenter un chaque fois.
Page :11/18
4 Description des modules développés
Nous allons décrire dans cette partie, les différents modules que nous avons développés pour
nos clients, vendeurs, et facture.
4.1 Client
Ce module Client permet de rechercher un client, afficher ses informations, insérer et
sauvegarder un client et de supprimer un client.
Page :12/18
Le client doit pouvoir visualiser des circuits de la base. Cette interface répond justement au
besoin. Avec les flèches, le client pourra parcourir les circuits.
4.2 Vendeurs
Page :13/18
Nous avons implémenté un formulaire qui permet de voir toutes, les réservations, et de les
valider.
L'insertion ne fonctionne pas pour l'instant et donc l'ajout dans les factures non plus.
4.3 Facture
Une facture est éditée de façon automatique. Lorsque le client valide (paye) ses réservations,
une facture sera livrée. Cette interface montre l'édition d'une facture. Côté gauche de
l'interface contient les information du client et du vendeur. Celui à droite montre les produits
que le clients a achetés avec le numéro qui correspond l'attribut « num » de la table Lignes.
Page :14/18
5 Description du générateur de données
Nous allons aborder dans cette partie toutes les questions importantes quant à notre
générateur de données.
5.1 Pourquoi faire un générateur de données?
L'élaboration d'un générateur de données est essentielle dans le cadre du test d'une base
de données. En effet, cela nous permet de pouvoir tester nos procédures, nos fonctions et
les tailles de nos tables. Nous avons fait des prévisions sur la taille de nos tablespaces et
tables. Le fait de peupler notre base de données en adoptant le pire des cas permet de
vérifier que la taille que nous avons choisie est adéquate.
5.2 Comment marche-t-il?
Par soucis de simplicité, ce générateur de données renvoie des données fictives.
Cependant ces données respectent l'intégrité de la base de données. En effet, prenons
l'exemple de nos tables facture et lignes : notre générateur va nous générer un certain
nombre de factures puis un certains nombre de lignes. Ces lignes sont toutes
« rattachées » à une facture existante (la clé étrangère correspondant à une facture est
bien un clé d'une facture existante).
Notre générateur de données (DataGen.java) renvoie des fichiers .sql pour chaque table à
peupler. L'utilisation de ce dernier est assez simple. Il suffit de spécifier au début du
programme le nombre de ligne de chaque table que l'on souhaite créer et ensuite
d'exécuter le programme. Tous les scripts sql sont générés et il nous reste plus qu'à les
exécuter pour peupler notre base. Bien entendu, il y a deux écoles pour peupler un base
de données :
- On désactive toutes les contraintes sur les tables et on exécute les scripts.
- On exécute les scripts en respectant un certain ordre pour ne pas violer les contraintes
5.3 En quoi cela va-t-il nous aider?
Tout d'abord, nous allons voir comment les données générées vont nous aider à
déterminer la taille des tables. Prenons l'exemple de notre table facture :
Nous avons 100 personnes par départ de circuit et 4 départs par mois, ce qui nous donne
400 factures par mois. Nous devons garder un historique des factures sur 10 ans alors
nous devrons stocker 10*12*400 = 48000 factures pour nos circuits.
Supposons maintenant que les clients choisissent aussi des hôtels et des vols seul. Nous
considérons que les clients effectuent moins souvent des vols et réservations de
chambres que des circuits. Nous supposons cela mais ce n'est pas précisé dans le sujet du
projet. Notons alors que que nous stockons 30 000 factures pour la réservation de
chambres et autant pour la réservation de billet d'avion. Ce qui nous fait au total : 48 000
+ 30 000 + 30 000 = 108 000 factures à stocker en dix ans. Avec notre générateur nous
allons donc générer 108 000 lignes dans la table facture en les remplissant au maximum
( ex : un varchar(20) contiendra toujours les 20 caractères). Nous pouvons donc vérifier
la taille que cela occupe sur la base de données grâce à la commande suivante :
Page :15/18
SELECT segment_name "Table", bytes/1024 "Taille en Ko", blocks "Nb Blocks"
FROM user_segments
WHERE segment_name = 'FACTURE';
Le résultat renvoyé pour une table Facture avec 108 000 lignes est :
36864 Ko et 4608 Blocks.
Précisons ici que cette taille n'est pas la taille réelle utilisée par la table mais la taille
allouée par oracle. En effet, tous les blocks réservés par Oracle pour notre table ne sont
pas plein.
Page :16/18
6 Justification des choix effectués
Nous allons maintenant expliquer les différents choix que nous avons fait sur nos
tablespaces et sur nos tables. Nous allons abordé le sujet du dimensionnement et de
paramètres de stockage.
6.1 Choix des tablespaces
Ayant déjà une petite expérience sur les bases de données nous avons commencé par
créer des tablespaces de taille moyenne afin d'y créer nos tables. Nous avons d'abord
choisi une taille de 512Mo afin de voir large.
Pour affiner ce choix, nous avons utilisé notre générateur de données pour se faire une
idée réelle de la place occupée par l'ensemble de nos tables dans chaque tablespace.
Pour cela nous avons appliqué la méthode expliquée dans la section 5.3 En quoi cela vat-il nous aider?
Après avoir appliqué cette méthode sur toutes les tables, nous avons donc fixé la taille de
nos tablespaces à environ 45 Mo pour le tablespace TableSeller et environ 70 Mo pour le
tablespace TableFacture.
Pour les calculs nous avons supposé les données suivantes : 30 vendeurs, 15000 clients,
108 000 factures, 324 000 lignes de facture, 120 000 réservations, 50 circuits, 100 vols,
300 villes, 300 hôtels 3 types de billet par vol, 3 types de chambre par hôtel.
Pour ce qui est des paramètres de stockage de ces tablespaces, nous avons sélectionner
l'option management automatique.
6.2 Choix des tables
Nous avons garder les options par défaut pour la création des tables. Nous avons juste
préciser de créer les tables dans les tablespaces qui ont été créés à cet effet. Nous aurions
tout à fait pu fixer la taille initiale à la taille que nous calculé avec nos données réelles
mais nous avons gardé la gestion automatique. Ainsi, au début la taille de la table est
minime et augmente au fur et à mesure que l'on entre des données dans celle-ci. Oracle
augmente la taille réservée à une table 8 blocks par 8 blocks. La taille des blocks étant de
8Ko la taille augmente donc de 64Ko à chaque fois.
Page :17/18
CONCLUSION
Ce projet sur Oracle nous a permis de mettre en pratique nos connaissances concernant le structure
et les caractéristiques de la base Oracle, notamment PLSQL qui est un langage procédural créé par
Oracle.
Nous avons pu utiliser les différents objets d'Oracle au sein de notre projet. Par exemple, Procédure,
Fonction, trigger; séquence et Index.
Nous avons choisi de sécuriser et de bien gérer notre base Oracle. C'est la raison pour laquelle nous
n'avons pas eu assez de temps pour raffiner les interfaces de l'application.
Page :18/18