Bonjour,
Envoyé par
alicc
Maintenant, partant du code proposé par fsmrel, que penser de la version ci-dessous ? (incluant la clause CASCADE)
D’abord deux questions : est-elle techniquement valable, est-ce qu’elle signifie bien que si un AVION ou un PILOTE ou un CLIENT était ‘rayé de la carte’, les RESERVATIONs concernées le seraient aussi ?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
| CREATE TABLE RESERVATION
(
ResId INT NOT NULL
, AvionId INT NOT NULL
, PiloteId INT NOT NULL
, ClientId INT NOT NULL
, DateActivite DATE NOT NULL
, Activite ... NOT NULL
, PRIMARY KEY (ResId)
, UNIQUE (AvionId, PiloteId, ClientId, DateActivite)
, FOREIGN KEY (AvionId) REFERENCES AVION (AvionId)ON DELETE CASCADE
, FOREIGN KEY (PiloteId) REFERENCES PILOTE (PiloteId)ON DELETE CASCADE
, FOREIGN KEY (ClientId) REFERENCES CLIENT (ClientId)ON DELETE CASCADE
) ; |
D’un point de vue purement technique, la clause « ON DELETE CASCADE » est on ne peut plus valide et signifie que si l’on exécute une instruction du genre :
DELETE FROM AVION WHERE AvionId = 50 ;
Alors il y a déclenchement automatique de la part du système d’une instruction :
DELETE FROM RESERVATION WHERE AvionId = 50 ;
Même principe en ce qui concerne les clients et les pilotes. Autant dire que, comme dirait Raoul Volfoni, c’est du brutal et certaines précautions élémentaires sont à prendre, on ne code pas CASCADE impunément, c’est de la dynamite ! C’est comme si la suppression d’un client entraînait la suppression automatique de ses factures, même si certaines n’étaient pas réglées : le comptable de la maison ne serait pas content du tout...
Face à l’alternative CASCADE/ NO CASCADE, le choix que l’on fait suit d’une réflexion de niveau sémantique : si par exemple je souhaite supprimer une facture, les lignes de facture correspondantes peuvent-elles être supprimées automatiquement elles aussi ? La réponse est affirmative, car ces lignes constituent une propriété multivaluée de la facture et si on en a fait une entité-type, c’est seulement pour respecter la première forme normale (1NF). Mais, me direz-vous, que se passera-t-il si les lignes de facture sont elles mêmes référencées par des livraisons et qu’il est hors de question que ces dernières disparaissent ? Il suffit en l’espèce d’utiliser la clause NO CASCADE (RESTRICT, NO ACTION en SQL, qui valent par défaut) :
CREATE TABLE FACTURE ... ;
CREATE TABLE LIGNE_FACTURE ... REFERENCES FACTURE ON DELETE CASCADE ;
CREATE TABLE LIVRAISON ... REFERENCES LIGNE_FACTURE ON DELETE NO CASCADE ;
La suppression d’une facture déclenche un stimulus à destination des lignes de la facture, qui ne voient pas d’objection à disparaître et propagent donc le stimulus vers les livraisons, mais celles-ci émettent un veto formel : l’opération de suppression est annulée, en vertu de quoi la facture, les lignes et les livraisons demeurent.
N.B. Pour que les noms des attributs faisant partie de l’en-tête de la table soient les mêmes que ceux qui représentent les éléments des clés, dans votre code SQL j’ai remplacé « Reservation » par « ResId ».
Associations non binaires - clés
Répondre avec citation
En cas de résolution, et afin de faciliter la tâche des bénévoles, merci de cliquer sur 
.
et 
permettent aux forumeurs de cibler leur recherche dans une discussion : n'hésitez pas à voter !
Partager