Discussion :

[wear12]

Bonjour à tous,

est-ce quelqu'un pourrait me confirmer ou me corriger cet exerice svp, merci.


donc c'est un schéma de données relatives à une entreprise réalisant la fabrication de produit :





Table Fabrication : une fabrication d'un produit

id : id de la fabrication
date : date de la fabrication
produit : id du produit fabrique
responsable : id du personnel responsable(clé étrangère sur Personnel.id)

Table Personnel : un membre du personnel de l'entreprise

id : id du personnel

Table Participation : participation d'un membre du personnel à une fabrication

personnel : id du personnel participant à la fabrication ( clé étrangère sur personnel.id)
fabrication : id de la fabrication à laquelle il participe ( clé étrangère sur fabrication.id)
(personnel,fabrication) -> clé primaire




la question est : Pour être responsable d'une fabrication, un membre du personnel doit être un des fabricants de celle-ci.

Mon raisonnement rajouter trigger à la table fabrication qui va récuperer l'id de fabrication ainsi que le responsable de la fabrication, est vérifie qu'il existe un tuple dans la table participation:
donc en gros un truc du style :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
 
 
 
 
 
CREATE TRIGGER test BEFORE UPDATE,INSERT
ON Fabrication FOR EACH ROW
 
BEGIN
 
DECLARE var integer;
DECLARE prsnl integer;
DECLARE fab integer;
 
prsnl := NEW.personnel 
fab := NEW.fabrication
 
 
select id into  var
from participation
where personnel = persn and fabrication = fab
 
Si aucune exception se leve laisse passer la requette, sinon si aucun tuple renvoye refuser la requete.
 
END |

[escartefigue]

Bonsoir,

Il y a un souci de logique :
- la table participation utilise un contrainte de type référence vers la table fabrication, jusque là pas de souci, il faut juste que l'occurrence de fabrication soit créée avant l'occurrence de participation qui lui est rattachée.
- dans votre trigger, vous voulez vérifier que l'id fabrication soit présent dans la table préparation, c'est bien sur impossible en cas d'insert à cause de la contrainte de type référence qui précède

[wear12]

à oui bien vu, donc voici une autre solution

je rajoute d'abord une contrainte check à la table fabrication qui oblige que le responsable au depart est null
(responsable is null).

ensuite je garde le même trigger mais uniquement pour le update.

[aieeeuuuuu]

Bonjour,

Vous serez en effet de toutes façons contraint de procéder en plusieurs étapes :
1/ création de la ligne de fabrication (avec le responsable à NULL, car il ne pourra pas déjà exister dans PARTICIPATION comme expliqué par escartefigue)
2/ création des lignes dans la table PARTICIPATION (Au moins le responsable, et les autres le cas échéant)
3/ mise à jour de la ligne de fabrication afin de renseigner le responsable


Le problème du trigger, c'est qu'il faudra en créer plusieurs, sur les deux tables, afin de s'assurer que la règle de gestion est toujours respectée : il faudra par exemple un trigger pour interdire la suppression d'un ligne de participation si le personnel est renseigné comme responsable.

Il y a beaucoup plus simple : ajouter simplement une contrainte d'intégrité référentielle, qui veillera a ce que la règle de gestion soit vérifiée en toutes circonstances.


PS : une alternative :
Changer le modèle, en supprimant la colonne responsable de la table FABRICATION et en ajoutant une colonne EstResponsable dans la table PARTICIPATION, avec une contrainte d'unicité sur la couple (fabrication, EstResponsable). ça simplifiera les insertions (pas besoin de la mise à jour finale pour renseigner le responsable)

[wear12]

merci pour votre réponse, j'ai 2 petites "questions"

1)"Il y a beaucoup plus simple : ajouter simplement une contrainte d'intégrité référentielle, qui veillera a ce que la règle de gestion soit vérifiée en toutes circonstances." pouvez-vous m'expliquer parce que je ne vois pas comment.

2) la 2ème solution qui consiste à changer le modele, est a ajouter un attribut estResponsable à la table participation, dans le cas d'une participation où le membre n'est pas responsable l'attribut faudra null c'est ça?

Merci.

[escartefigue]

Bonjour,

Vu la présence de 2 FK (personnel et produit) dans la table Fabrication, cela signifie que votre modèle conceptuel était le suivant :
[PRODUIT] 0,n --- (Fabriquer) --- 1,1 [FABRICATION] 1,1 ---- (Participation) --- 0,n [PERSONNEL]

Or dans l'énoncé, il est mentionné :

la question est : Pour être responsable d'une fabrication, un membre du personnel doit être un des fabricants de celle-ci.

Il devrait donc y avoir plusieurs personnes possibles pour une même fabrication, ce qui change tout !
Le MCD devient donc
[PRODUIT] 0,n --- (Fabriquer) --- 1,1 [FABRICATION] 1,n ---- (Participation) --- 0,n [PERSONNEL]
La relation "Participation" pourra porter l'attribut rôle.
Et comme la relation Participation possède une cardinalité max "n" de chaque coté, elle devient une table, dont la PK est id_fabrication + id_personne et qui a pour attribut le rôle de la personne.
Du coup, plus besoin de trigger

Notez que par convention, on utilise des verbes à l'infinitif pour identifier les relations, ce qui donne :
[PRODUIT] 0,n --- (Fabriquer) --- 1,1 [FABRICATION] 1,n ---- (Participer) --- 0,n [PERSONNEL]

[aieeeuuuuu]

1)"Il y a beaucoup plus simple : ajouter simplement une contrainte d'intégrité référentielle, qui veillera a ce que la règle de gestion soit vérifiée en toutes circonstances." pouvez-vous m'expliquer parce que je ne vois pas comment.

Je veux dire créer une contrainte d'intégrité référentielle (clef étrangère) sur la table FABRICATION (responsable, id) référençant la table PARTICIPATION (personnel, fabrication)