© Éditions Eyrolles
219
chapitre n° 3
Le niveau physique : de SQL2 à SQL3
Contrainte de simultanéité
Dans notre exemple, un pilote peut être affecté à la fois à une mission sanitaire et à un exercice
d’entraînement. En outre, il peut n’être affecté à aucune mission.
La simultanéité se programme par une contrainte SQL de validation (CHECK).
CREATE TABLE pilote
(numpil NUMBER, nom VARCHAR(10), grade VARCHAR(10),
sani VARCHAR(10), entraine VARCHAR(10),
CONSTRAINT fk_pilote_sanitaire FOREIGN KEY(sani)
REFERENCES sanitaire(codesan),
CONSTRAINT fk_pilote_entrainement FOREIGN KEY(entraine)
REFERENCES entrainement(codent),
CONSTRAINT pk_pilote PRIMARY KEY(numpil))
Contrainte d’inclusion
Selon la contrainte d’inclusion, toutes les occurrences d’une association doivent être incluses
dans les occurrences d’une autre association.
Entre deux associations binaires
Considérons l’exemple 1-43 (1-47 pour la notation UML) dans lequel chaque étudiant formule
des vœux concernant des stages. Pour modéliser le fait qu’un étudiant accède à un stage à condition qu’il le demande explicitement, il faut utiliser une contrainte d’inclusion. Les règles R1 et
R3 s’appliquent pour traduire l’association Voeux. Les règles R1 et R4 s’appliquent pour
traduire l’association Effectuer.
L’inclusion entre deux associations se programme par une contrainte SQL de clé étrangère
(FOREIGN KEY).
Puisqu’il n’est pas possible de déclarer la contrainte lors de la création de la table Etudiant
(car la table Voeux référence la table Etudiant), il faut utiliser l’instruction ALTER TABLE.
Entre trois associations binaires
Considérons l’exemple 1-45 dans lequel des départements achètent des logiciels. La
contrainte d’inclusion exprime qu’un logiciel l acheté par le département d est installé sur un
serveur s, destiné, entre autres, à ce département.
CONSTRAINT ck_simultaneite CHECK
➥((sani IS NULL AND entraine IS NULL) OR
➥(sani IS NOT NULL AND entraine IS NOT NULL)),
219
chapitre n° 3
Le niveau physique : de SQL2 à SQL3
Contrainte de simultanéité
Dans notre exemple, un pilote peut être affecté à la fois à une mission sanitaire et à un exercice
d’entraînement. En outre, il peut n’être affecté à aucune mission.
La simultanéité se programme par une contrainte SQL de validation (CHECK).
CREATE TABLE pilote
(numpil NUMBER, nom VARCHAR(10), grade VARCHAR(10),
sani VARCHAR(10), entraine VARCHAR(10),
CONSTRAINT fk_pilote_sanitaire FOREIGN KEY(sani)
REFERENCES sanitaire(codesan),
CONSTRAINT fk_pilote_entrainement FOREIGN KEY(entraine)
REFERENCES entrainement(codent),
CONSTRAINT pk_pilote PRIMARY KEY(numpil))
Contrainte d’inclusion
Selon la contrainte d’inclusion, toutes les occurrences d’une association doivent être incluses
dans les occurrences d’une autre association.
Entre deux associations binaires
Considérons l’exemple 1-43 (1-47 pour la notation UML) dans lequel chaque étudiant formule
des vœux concernant des stages. Pour modéliser le fait qu’un étudiant accède à un stage à condition qu’il le demande explicitement, il faut utiliser une contrainte d’inclusion. Les règles R1 et
R3 s’appliquent pour traduire l’association Voeux. Les règles R1 et R4 s’appliquent pour
traduire l’association Effectuer.
L’inclusion entre deux associations se programme par une contrainte SQL de clé étrangère
(FOREIGN KEY).
Puisqu’il n’est pas possible de déclarer la contrainte lors de la création de la table Etudiant
(car la table Voeux référence la table Etudiant), il faut utiliser l’instruction ALTER TABLE.
Entre trois associations binaires
Considérons l’exemple 1-45 dans lequel des départements achètent des logiciels. La
contrainte d’inclusion exprime qu’un logiciel l acheté par le département d est installé sur un
serveur s, destiné, entre autres, à ce département.
CONSTRAINT ck_simultaneite CHECK
➥((sani IS NULL AND entraine IS NULL) OR
➥(sani IS NOT NULL AND entraine IS NOT NULL)),