COVOITURAGE

Université de Bourgogne – Année Universitaire 2008– 2009
Licence IE troisième année
Projet BD
Enseignants : Marinette Savonnet, Éric Leclercq & Joël Savelli
Projet de Bases de Données
2008-2009
COVOITURAGE
Johan Jegard, Camille Teruel & Julien Virey
1/47
Base de Données
Sommaire
I. Introduction
3
II.
Modélisation
1. Diagrammes des cas d'utilisations
• explications
• le diagrammes
2. Diagramme de classe
• Description détaillée
4
4
4
5
6
7
III.
Modèle relationnel
1. Passage du diagramme de classe au modèle relationnel
• A propos de notre diagramme
• Traduction diagramme de classe / modèle relationnel
2. Diagramme relationnel
3. Forme normale
4. Création des tables
5. création des vues
6. requêtes
10
12
13
14
23
24
IV.
Fonctionnalités complexes
1. PL/SQL
2. Problèmes rencontrés (tables mutantes etc.)
30
30
43
V. Conclusion
44
Annexe 1 : Crédits et ftp
45
Annexe 2 : Scénario de démonstration
46
Johan Jegard, Camille Teruel & Julien Virey
2/47
Base de Données
Introduction
L'objectif de ce projet est de modéliser puis mettre en place une base de données
permettant d'alimenter un site de covoiturage. Le covoiturage désigne une association
de personnes qui accomplissent un trajet commun dans un même véhicule afin de
réduire les frais et la pollution.(1)
En France, il existe soixante-dix-huit sites de covoiturage, gratuits pour la plupart.
Toutefois, ils souffrent tous d'une faible fréquentation, probablement due au grand
nombre de sites grand publics existants. De plus, la plupart des sites de petites annonces
gratuites proposent aussi une rubrique de covoiturage. D'ailleurs, certains sites de
petites annonces locales disposent de plus d'offres de covoiturage qu'un site spécialisé,
pour un trajet identique. La multiplicité et la diversité des acteurs et des sites est un
frein au développement et à l'essor du covoiturage en France. Le regroupement
d'acteurs (Collectivité, entreprise, association, etc.) et la mise en commun des bases de
données des sites peut répondre à ce problème.(2)
Afin de mettre en place cette base de données, il est tout d'abord nécessaire de
comprendre le fonctionnement d'un système de covoiturage. Nous allons donc tout
d'abord présenter ce modèle de fonctionnement sous forme de diagrammes de cas
d'utilisation et de classes. Ce modèle est le fruit de nos concertations mutuelles, de nos
ébauches de diagrammes personnelles, puis de notre mise en accord commun. Une fois
cette modélisation terminée, il faut traduire le diagramme de classe obtenu dans le
modèle relationnel afin de l'introduire dans Oracle. Oracle est un système de gestion de
données relationnel (SGBDR), fourni par Oracle Corporation.
(1)
(2)
: D'après http://www.le-dictionnaire.com/definition.php?mot=covoiturage
: D'après http://fr.wikipedia.org/wiki/Covoiturage
Johan Jegard, Camille Teruel & Julien Virey
3/47
Base de Données
Modélisation UML
Afin de faire une modélisation de notre base de données, nous allons utiliser UML.
Nous détaillerons donc la réalisation de deux diagrammes : tout d'abord le diagramme
des cas d'utilisations puis le diagramme de classe.
1 ) Diagramme des cas d'utilisations :
Après une analyse du sujet et avoir visité plusieurs sites de covoiturage, nous avons
décidé de faire apparaître les six fonctionnalités principales suivantes :
•
Recherche :
Un internaute doit pouvoir rechercher si des trajets qui l'intéressent sont
proposés avant son inscription éventuelle.
•
Inscription :
L'internaute doit pouvoir s'inscrire sur le site. Il devient alors un covoitureur.
•
Demande de trajet :
Un covoitureur peut faire une demande de trajet.
•
Participation à un trajet :
Un covoitureur peut se proposer pour participer à un trajet.
•
Évaluation des covoitureur :
Un covoitureur peut en évaluer un autre s'il à déjà participé à un trajet avec
lui.
• Proposition de trajet :
Un covoitureur qui possède un véhicule est considéré comme un conducteur. Il
peut alors faire une proposition de trajet.
Johan Jegard, Camille Teruel & Julien Virey
4/47
Base de Données
Le diagramme tant attendu :
Figure 1 : Diagramme de cas
Johan Jegard, Camille Teruel & Julien Virey
5/47
Base de Données
2 ) Diagramme de classe :
Johan Jegard, Camille Teruel & Julien Virey
6/47
Base de Données
Le diagramme de classe à une part importante dans un projet tel que celui-ci, car il
permet de modéliser le fonctionnement de notre base. Cela nous a donné une vue plus
nette de ce que nous devions faire. Le diagramme a évolué au fur et à mesure de notre
avancement dans le projet. En effet, le passage au modèle relationnel ou même
l'utilisation d'Oracle ont fait ressortir des difficultés que nous avons du gérer.
Description détaillée
La classe Covoitureur décrit un internaute inscrit sur
le site de covoiturage. Certains attributs peuvent
être nuls, comme la présentation ou l'id paypal. Tous
les autres doivent obligatoirement être renseignés
par l'internaute. Les classes évaluation, véhicule et
message sont des composition de la classe
covoitureur. La classe covoitureur est également
associée aux classe DemandeTrajet, trajet et
évaluation. En effet un covoitureur peut faire une
demande de trajet, peut voyager sur un trajet ou
encore être l'auteur d'une évaluation.
La classe Évaluation
est une composition de la classe Covoitureur. Un
covoitureur est auteur d'une évaluation sur un autre
covoitureur. Une évaluation possède une note, qui peut
être positive, neutre ou négative, un commentaire et
éventuellement, une réponse du covoitureur concerné.
La classe véhicule est une composition de la classe
covoitureur. Un covoitureur qui possède une voiture est
un conducteur, il peut donc proposer des trajets. Un
véhicule possède une marque, un modèle et une couleur
(pour que les passagers puissent la repèrer de loin). Un
véhicule possède également un type de carburant ainsi
qu'une consommation. La classe véhicule est associé à la
classe trajet : un véhicule peut parcourir plusieurs
trajets
La classe carburant est une énumération. Elle contient les
différents types de carburant qu'un véhicule consomme. Elle
possède également une opération prix_carburant(), qui
pourra indiquer le prix courant du carburant.
Johan Jegard, Camille Teruel & Julien Virey
7/47
Base de Données
La classe message est une composition de la classe
covoitureur. Elle modélise une messagerie privée.
Un covoitureur est prévenu en cas d'annulation de
trajet ou lorsqu'un trajet correspondant à une de
ses demandes est déposée sur le site...
La classe demandeTrajet est associée à la classe
covoitureur. Un covoitureur (qu'il soit passager ou
conducteur) peut demander un trajet. Il doit préciser la
date de départ, la ville de départ ainsi que la ville
d'arrivée.
La classe trajet est associée à covoitureur,
véhicule,
ville
et
préférences.
Un
covoitureur voyage sur le trajet, dans le
véhicule d'un covoitureur conducteur. Un
trajet possède au moins deux étapes (un
départ et une arrivée) et des préférences. Il
possède les attributs date de départ,
fréquence, un commentaire, un nombre de
place, une distance, un type de cout et le
cout du trajet.
La classe fréquence est une énumération. Elle liste les
fréquences disponibles pour un trajet donné. Un trajet peut
donc être quotidien, hebdomadaire, mensuel, unique ou
seulement les jours ouvrés de la semaine.
La classe typeCout est une énumération. Elle liste les différents
types de cout qu'un conducteur peut choisir pour son trajet. Le cout
d'un trajet peut donc être gratuit, fixe, ou partagé. Dans ce dernier
cas, le cout est calculé en fonction du prix de l'essence et du
kilométrage.
Johan Jegard, Camille Teruel & Julien Virey
8/47
Base de Données
La classe préférences permet à un conducteur de
paramétrer les options de son trajet. Il peux donc donner
son avis sur le transport d'animaux, la consommation de
tabac, l'écoute de musique et l'utilisation de la palabre. Tous
ces attributs sont de type note, soit positif, neutre ou
négatif.
La classe Note est une énumération. Elle présente les valeurs que
peuvent prendre les notes, l'acceptation pour un trajet ou les
préférences.
La classe participe est une classe association qui permet au
conducteur d'accepter ou de refuser un passager pour son
trajet. Le covoitureur qui souscrit à un trajet arrive en
neutre. Si le conducteur l'accepte, il passe en positif, dans
le cas inverse, il passe en négatif
La classe ville permet de répertorier les villes
par leur nom et leur code postal.
La classe etape est une classe association entre les
classes trajet et ville. Elle présente une liste
ordonnée de ville dans le trajet. Un trajet possède
au moins deux étapes : le départ et l'arrivée. Mais
le conducteur peut décider de s'arrêter dans
plusieurs villes intermédiaires.
Johan Jegard, Camille Teruel & Julien Virey
9/47
Base de Données
Modèle relationnel
1 ) Passage du diagramme de classe au modèle relationnel :
a) A propos de notre diagramme :
Pour représenter notre modèle relationnel nous avons utilisé un diagramme dont nous
allons expliquer la sémantique :
figure 2 : Association simple
Ce type de diagramme est aussi intuitif qu'il semble l'être. Nous avons dans cet exemple
deux tables A et B. Les attributs de A sont ici identifiantA et attributB tandis que B ne
possède que l'attribut identifiantB. Les identifiants des tables sont soulignés. La flèche
reliant la table A à la table B signifie que la table A possède une clé étrangère attributB
(comme désigné au dessus de la flèche) qui désigne la table B.
b) Traduction diagramme de classes/modèle relationnel :
Traduire un diagramme de classe en un modèle relationnel n'est pas a priori une tache
compliquée mais ce processus nécessite tout de même quelques explications:
•
une classe devient évidemment une table
•
les associations entre classes de type ''un vers un'' ou ''plusieurs vers un'' sont
modélisées par une simple clé étrangère.
•
les associations de type ''un vers plusieurs'' sont également modélisées par une
clef étrangère, mais dans le sens inverse :
Johan Jegard, Camille Teruel & Julien Virey
10/47
Base de Données
✗
ainsi l'association :
figure 3 : Composition
✗
devient :
figure 4 : Traduction de la composition
•
les associations de type ''plusieurs vers plusieurs'' ainsi que les associations qui
possèdent une classe-association deviennent une table avec des clés
étrangères sur les tables associées :
✗
ainsi l'association :
figure 5 : Classe association
✗
devient :
figure 6 : Traduction de la classe association
Johan Jegard, Camille Teruel & Julien Virey
11/47
Base de Données
2 ) Diagramme relationnel
figure 7 : Diagramme relationnel
Johan Jegard, Camille Teruel & Julien Virey
12/47
Base de Données
3 ) Forme normale
Dans ce diagramme, toutes les relations sont en troisième forme normale grâce à
l'insertion d'un identifiant dans chacune d'elles. Nous obtenons donc un graphe minimum
similaire en forme d'étoile, tout les attributs dépendants de l'identifiant.
La seule exception à cette règle est la relation Véhicule. En effet, nous aurions pus la
diviser en deux relations, l'une contenant la marque, le modèle, la consommation et le
type de véhicule l'autre contenant une référence à la première, une couleur et un
propriétaire. Mais étant donné le nombre inconcevable de modèles de véhicules existant
comparé à la population de notre base (qui même dans la cas d'une utilisation sur un vrai
site internet ce serait révélée à notre avis plutôt faible), il nous a semblé que cette
division n'aurait fait que complexifier notre diagramme. Nous décidons donc de garder
cette relation en seconde forme normale.
Johan Jegard, Camille Teruel & Julien Virey
13/47
Base de Données
4 ) Créations des tables :
Création de la table carburant
La table carburant possède deux attributs. Le nom du carburant et son prix au litre. La
clef primaire de cette table est nomCarburant. Nous avons fait une contrainte, qui
vérifie que le nom du carburant est bien dans une liste fixée de carburant.
Création de la table cout
La table cout contient seulement l'attribut typeCout, qui liste les états que peut prendre
le type, soit gratuit, partagé ou fixe.
Création de la table note
La table note, comme la table cout, a un attribut typeNote contraint à lister les
différentes notes disponibles, soit positif, négatif ou neutre.
Johan Jegard, Camille Teruel & Julien Virey
14/47
Base de Données
Création de la table covoitureur
La table covoitureur contient les attributs login, mot de passe, prénom, nom, date de
naissance, telephone, email, id paypal, présentation et le nombre de trajet. La clef
primaire est le login. Les attributs email et idpaypal doivent contenir un @, car les deux
sont représentés par des adresses email.
Johan Jegard, Camille Teruel & Julien Virey
15/47
Base de Données
Création de la table fréquence
La table fréquence, comme les table note et cout, contient un attribut, qui est
également la clef primaire : typeFrequence. Celui-ci liste les états que peut prendre la
fréquence, soit journalier, hebdomadaire mensuel, unique ou jours ouvrés.
Création de la table demandeTrajet
Johan Jegard, Camille Teruel & Julien Virey
16/47
Base de Données
La table demande trajet possède un nombre à 10 chiffres, nommé idDemandeTrajet, qui
permet d'identifier la demande. C'est donc évidement la clef primaire de la table.
L'attribut demandeur possède une clef externe vers le login du covoitureur associé. Le
'On delete cascade' permet d'automatiser la suppression des trajets demandés par un
covoitureur si celui-ici est supprimé. Départ et arrivée possèdent tous les deux une clef
externe vers idVille (de la table ville) et préférence pointe vers l'idPreference de la
table préférence.
Création de la table étape
La clef primaire de la table étape est un numéro de 10 chiffres baptisé idEtape. Ville
pointe vers la clef primaire de la table ville (idVille), trajet vers la clef primaire de la
table trajet (idTrajet). Le 'On delete cascade' permet de supprimer toutes les étapes
d'un trajet si celui ci est anéanti.
Johan Jegard, Camille Teruel & Julien Virey
17/47
Base de Données
Création de la table évaluation
La clef primaire de la table évaluation est, pour changer, un identifiant à 10 chiffres
dénommé idEvaluation. L'auteur et l'objet de l'évaluation tendent vers la clef primaire
de la table covoitureur(login). Quant à note, il s'élance en direction de la table note,
vers la clef typeNote.
Création de la table message
Johan Jegard, Camille Teruel & Julien Virey
18/47
Base de Données
La table message comprend quatre attributs, dont idMessage, un nombre à dix chiffres
qui identifie le message et sert également de clef primaire. L'attribut covoitureur pointe
bien sur vers la table covoitureur et plus particulièrement vers sa clef primaire : login.
Le 'On delete cascade' implique la suppression des messages d'un covoitureur si celui ci
est détruit.
Création de la table participe
La table participe référence un covoitureur, un trajet et un attribut accepte. Les deux
premiers attributs constituent la clef primaire de la table. Covoitureur pointe vers la
table covoitureur, et plus particulièrement vers login, trajet est dirigé vers idTrajet de
la classe trajet. Quant à accepte, il est braqué vers typeNote de la table note, tout
simplement parce que pour participer à un trajet, il faut que ce paramètre passe en
positif. Il est neutre par défaut, et négatif pour un refus.
Johan Jegard, Camille Teruel & Julien Virey
19/47
Base de Données
Création de la table véhicule
La table véhicule possède une clef primaire, dont le rôle est tenue par idVéhicule, et
une clef externe propriétaire. Le propriétaire pointe bien sur vers l'attribut login de la
table covoitureur.
Création de la table ville
La table ville se compose d'un idVille, qui est également la clef primaire de la table,
d'un nom et d'un code postal.
Johan Jegard, Camille Teruel & Julien Virey
20/47
Base de Données
Création de la table trajet
La table trajet contient une clef primaire : idTrajet. Elle possède également quatre clefs
externes : véhicule, qui pointe vers l'idVéhicule de la table véhicule, fréquence, qui
pointe vers typeFréquence de la table fréquence, typeCout, qui pointe vers typeCout
dans la table cout et pour finir, préférence, qui pointe vers idPreference de la table
préférence.
Johan Jegard, Camille Teruel & Julien Virey
21/47
Base de Données
Création de la table préférence
La table préférence contient simplement un identifiant, qui fait office de clef primaire.
Les autres attributs pointent tous vers typeNote de la table note. En effet, cette table
illustre les choix du conducteur quant à l'ambiance qu'il tolérera au cours du voyage. Il
peut donc avoir un avis négatif sur les animaux, positif sur la cigarette et neutre sur la
musique et la discussion.. (par exemple).
Johan Jegard, Camille Teruel & Julien Virey
22/47
Base de Données
5 ) Création de vues
Nous avons décidé de créer deux types de vues afin de permettre un accès plus rapide à
certaines données. La première vue concerne les tables participe, étape et ville. Elle
permet de récupérer les covoitureurs, le lieu, et le nom de la ville à chaque trajet.
Cette vue pourra ainsi être utilisée dans une requête que nous détaillerons dans la
section requête.
La deuxième vue quant à elle établit une liaison entre les classes trajet, préférences et
véhicule. Elle va permettre de nous renseigner sur tous les détails de chaque trajet (les
préférences, le conducteur, etc.)
Ces deux vues combinées et correctement utilisées dans des requêtes vont donc
apporter une description complète de chaque trajet . Leur utilité est simple : elles
permettent l'accès rapide à des attributs importants qui ne sont pas abordables
simultanément dans une simple requête.
Johan Jegard, Camille Teruel & Julien Virey
23/47
Base de Données
6 ) requêtes
Voici notre jeu de requêtes SQL. Chaque requête a bien évidement été testé et
fonctionne sous Oracle.
• Requêtes de mise à jour
Cette requête permet de supprimer tous les trajets dont la date de départ est passée
depuis un mois (laissant un mois pour l'évaluation).
Suppression des messages qui ont plus d'un an.
Refus des covoitureurs qui n'ont été ni acceptés ni refusés (valeur 'NEUTRE' pour la
colonne accepte de la table participe) pour un trajet qui a déjà commencé.
Modification du lieu de départ d'un trajet donné.
ROLLBACK permet d'annuler toutes les mises à jour effectuée depuis le COMMIT.
Johan Jegard, Camille Teruel & Julien Virey
24/47
Base de Données
• Requêtes d'interrogation
Requête retournant tous les participants par trajet.
Récupération de toutes les évaluations du covoitureur 1234567890.
Retourne tous les véhicules que possède un covoitureur.
Nom, e-mail de tous les conducteurs qui ont proposé au moins un trajet.
Le nom et prénom des covoitureurs qui n'ont pas de véhicule et qui ont déposé une
demande de trajet ou qui ont participé à un trajet : en deux mots, les passagers actifs.
Johan Jegard, Camille Teruel & Julien Virey
25/47
Base de Données
Retourne le nom et prénom des covoitureurs qui n'ont pas participé ni demandé de
trajet : toujours en deux mots, les covoitureurs inactifs.
Quels sont les date et id de tous les trajets non fumeurs actuellement disponibles ?
Quels sont les date et id de tous les trajets qui acceptent les animaux?
Tous les trajets actuels dont les covoitureurs ont 80 ans ou plus (trajets du troisième
age... On n'est pas rendu).
Johan Jegard, Camille Teruel & Julien Virey
26/47
Base de Données
Les trajets dont le cout est supérieur à tous ceux qui ont un prix fixe.
Les véhicules dont la consommation est supérieure à un de ceux de marque Renault.
• Requêtes avec appels à une procédure, une fonction, ou une vue.
Quel est l'age moyen des covoitureurs.
Nom et email de tous les conducteurs qui ont proposé au moins un trajet.
Nombre de covoitureurs inscrits.
Le conducteur ayant proposé le trajet dont le coût est le plus bas.
Johan Jegard, Camille Teruel & Julien Virey
27/47
Base de Données
Les covoitureurs dont la date de naissance n'est pas le 15/07/84.
Afficher le nom des utilisateurs dont le prénom commence par 'j'.
Recherche de trajets entre Lyon et Paris.
Requête qui recherche un trajet grâce à une procédure stockée puis affiche les résultats
de la table ResultatRecherche.
Calcul de la note d'un covoitureur nommé alpha grâce à une fonction stockée.
Johan Jegard, Camille Teruel & Julien Virey
28/47
Base de Données
On utilise la vue détail_trajet pour récupérer les informations sur un trajet.
Johan Jegard, Camille Teruel & Julien Virey
29/47
Base de Données
Fonctionnalités complexes
1 ) PL/SQL
Voici une procédure stockée qui va rechercher les trajets disponibles puis stocker les
informations trouvées (si informations il y a) dans une table temporaire
ResultatRecherche. Cette table sera vidée préalablement lors de chaque appel à la
procédure grâce à un COMMIT.
Johan Jegard, Camille Teruel & Julien Virey
30/47
Base de Données
Johan Jegard, Camille Teruel & Julien Virey
31/47
Base de Données
Voici le code d'une fonction stockée qui prend en paramètre le login d'un utilisateur puis
calcule sa note et retourne sa valeur. La note est un pourcentage de ses évaluations
positives.
Johan Jegard, Camille Teruel & Julien Virey
32/47
Base de Données
La fonction calcul cout calcul le cout total d'un trajet. Elle prend en paramètres le
nombre de kilomètres, le cout de l'essence et la consommation du véhicule.
Johan Jegard, Camille Teruel & Julien Virey
33/47
Base de Données
La fonction get_cout, renvoie le coup d'un trajet par personne, si le trajet est d'un type
cout partagé.
Ce trigger permet d'ajouter automatiquement le conducteur dans la table participe
lorsqu'un nouveau trajet est ajouté . On gère ici une exception table mutante a cause de
l'accès à la table trajet.
Johan Jegard, Camille Teruel & Julien Virey
34/47
Base de Données
Quand un trajet est retiré, on doit retirer les participants de la table participe.
Si un trajet est annulé avant d'être effectué, on envoie un message aux participants de
ce trajet. Deux triggers sont crées à cause des tables mutantes.
Johan Jegard, Camille Teruel & Julien Virey
35/47
Base de Données
Johan Jegard, Camille Teruel & Julien Virey
36/47
Base de Données
Vérifier que l'auteur et l'objet de l'évaluation ont bien effectué un trajet ensemble avant
l'insertion d'une évaluation . On créé une table buffer (non temporaire) pour empêcher
les fameuses tables mutantes.
Johan Jegard, Camille Teruel & Julien Virey
37/47
Base de Données
Après insertion sur évaluation il faut recalculer la note du covoitureur qui fait l'objet de
l'évaluation.
Johan Jegard, Camille Teruel & Julien Virey
38/47
Base de Données
Rechercher les trajets qui correspondent à la demande.
Johan Jegard, Camille Teruel & Julien Virey
39/47
Base de Données
Si il y a un trajet correspondant, alors on envoie un message au covoitureur qui a
demandé le trajet.
Interdire la suppression de villes, gestion d'erreur si quelqu'un essaye d'effacer une ville
de la table ville.
Johan Jegard, Camille Teruel & Julien Virey
40/47
Base de Données
Si insertion d'un nouveau participant, on décrémente le nombre de places dans la table
trajet et on recalcule le coût du trajet avant de l'insérer dans trajet, si le type de coût
est partagé.
Johan Jegard, Camille Teruel & Julien Virey
41/47
Base de Données
Pour éviter le problème de table mutante, on ruse en utilisant un déclencheur sur une
insertion dans temp_participe (qui correspond à une suppression dans participe). Les
tuples de la table temp_participe sont insérés au moment d'une suppression sur
participe.
Johan Jegard, Camille Teruel & Julien Virey
42/47
Base de Données
Pour voir tous les triggers, il suffit de faire.
2 ) PROBLEMES RENCONTRÉS
Au cours de l'élaboration des fonctionnalités complexes de ce projet, nous nous sommes
confrontés à plusieurs problèmes qu'il nous a fallut résoudre.
Tout d'abord, la compilation des fonctions, procédures et triggers n'est pas aussi simple
qu'il y paraît : la syntaxe à respecter est stricte et le compilateur peut parfois se
montrer peu explicite. Merci à la documentation Oracle sur les erreurs qui nous a
permis, dans bien des cas, de corriger une erreur qui ne nous semblait pas forcément
évidente.
Outre ces problèmes triviaux, nous avons également rencontré une erreur courante et
inévitable pour un développeur PL/SQL qui utilise les déclencheurs: les tables mutantes
avec l'erreur '' ORA-04091 ''.
L'erreur '' ORA-04091 '' se produit dans chacun des cas suivants :
• Si un déclencheur de niveau ligne (qu'il soit BEFORE ou AFTER) tente d'accéder,
même par un SELECT, à une table mutante.
• Si un déclencheur de niveau instruction résultant d'une contrainte DELETE
CASCADE tente d'accéder, même par un SELECT, à une table mutante.(1)
Pour empêcher cette erreur, il nous a fallut ruser. Il est par exemple possible
d'intercepter l'exception Oracle des tables mutantes, et de la traiter dans la partie
EXCEPTION du programme. Mais cette méthode est risqué et ne fonctionne que dans
quelques cas de déclencheurs isolés. Après différents essais de méthodes de résolution
pour ce problème, il semble que la meilleur méthode (dans notre cas) consiste en la
création d'une table temporaire qui prend les mêmes valeurs que la table qui fait l'objet
de l'exception table mutante. On modifie ensuite le trigger correspondant afin qu'il
effectue ses opérations sur la table temporaire.
Prenons l'exemple de la table participe et du déclencheur annule trajet de notre projet.
Le déclencheur annule_trajet engendrait une exception table mutante sur participe.
Pour y remédier, nous avons un autre déclencheurs(annule_trajet0) qui va être exécuté
avant une suppression sur la table participe, puis va insérer les tuples de cette table
dans une table temporaire. Ainsi on modifie les opérations de notre déclencheur
annule_trajet afin qu'elles utilisent la table temporaire. L'erreur a donc été évitée. Dans
d'autres cas plus spécifiques, il serait plus judicieux d'utiliser un déclencheur de niveau
d'instruction( c'est à dire sans le '' FOR EACH ROW '').
Merci au tutoriel complet de Pomalaix.(1)
(1)
D'après http://sgbd.developpez.com/oracle/ora-04091/
Johan Jegard, Camille Teruel & Julien Virey
43/47
Base de Données
Conclusion
La conception d'une base de données est une étape cruciale dans le développement d'un
site web, et plus particulièrement pour un site de covoiturage, qui se doit de contenir
une grande quantité d'informations pertinentes et cohérentes, sur les territoires à
parcourir, sur les utilisateurs, mais également des fonctionnalités avancées permettant
l'utilisation aisée du site. Ainsi, même l'utilisateur lambda, sans aucune connaissance,
doit pouvoir utiliser facilement ce genre de site. Tout doit alors être fait pour lui
faciliter l'utilisation, en lui indiquant clairement si un trajet lui convient, si un trajet est
annulé et lui proposer des options permettant de distinguer clairement quel type de
trajet lui convient le mieux (fumeur, présence d'animaux, voiture confortable)...
C'est dans cette optique que nous avons développer notre projet.
La conception de la base en elle-même, créations des tables, peuplement, présente peu
de difficultés. Le premier gros travail se situe sur la modélisation de la base et les
relations entre les tables. Entre le début du projet et ce rapport, nous avons fait au
moins six diagrammes de classes différents. Notre modèle relationnel en sort beaucoup
plus simple et efficace. Le second effort s'est matérialisé par la création des
fonctionnalités complexes en PL/SQL et par la multitude d'erreurs qu'elle entraine (Ah
les tables mutantes...). La dernière besogne, et non la moindre, fut de créer un scénario
consistant pour la présentation de ce projet. Exposer le bon fonctionnement de notre
travail d'une manière cohérente, sans qu'aucun problème ne vienne troubler notre
l'intervention.
Ainsi, ces quelques mois de travail nous ont permis d'approfondir notre connaissance du
SQL, du PL/SQL, d'Oracle mais surtout d'apprendre à concevoir une base de donnée
conséquente sans répéter les erreurs faites dans le développement de celle-ci.
Johan Jegard, Camille Teruel & Julien Virey
44/47
Base de Données
Annexe 1 : Crédits et ftp
Rapport intermédiaire réalisé par :
•
•
•
Johan Jegard
Camille Teruel
Julien Virey
[email protected]
[email protected]
[email protected]
grâce à :
•
•
•
•
•
•
OpenOffice.org v.3 pour le blabla → http://fr.openoffice.org/
Dia pour les diagrammes → http://projects.gnome.org/dia/
Gedit pour l'edition de texte avec colorisation syntaxique
→ http://projects.gnome.org/gedit/
Imagemagick pour les captures d'écran → http://www.imagemagick.org/
Gimp pour les éditer → http://www.gimp.org/
Et tout cela sous Debian Lenny :) → http://www.debian.org/
Les sources du document, les diagrammes, ainsi que les codes sources de nos
tables/requêtes/vues/fonctions/procédures sont accessible sur le ftp :
http://betageek.free.fr/Projets/bdd/
Johan Jegard, Camille Teruel & Julien Virey
45/47
Base de Données
Annexe 2 : Scénario
Voici un petit scénario (complet cette fois-ci), qui montre le déclenchement des
principaux triggers :
Johan Jegard, Camille Teruel & Julien Virey
46/47
Base de Données
Johan Jegard, Camille Teruel & Julien Virey
47/47
Base de Données

Download Report