Bonne année à tous !
En passant, une observation concernant Looping et les contraintes d’inclusion.
Je rappelle d’abord la définition de la contrainte d’inclusion, telle qu’elle fut donnée en 1990 par le groupe 135 de l’Afcet dans son Glossaire :
A son tour, Looping est bien entendu conforme :
On sait toutefois que Looping (version 2.3) ne traduit pas cette contrainte dans le code SQL :
CREATE TABLE CLASSE(
classeId INTEGER,
PRIMARY KEY(classeId)
);
CREATE TABLE MATIERE(
matiereId INTEGER,
PRIMARY KEY(matiereId)
);
CREATE TABLE ENSEIGNANT(
enseignantId INTEGER,
PRIMARY KEY(enseignantId)
);
CREATE TABLE ENSEIGNE(
classeId INTEGER,
matiereId INTEGER,
enseignantId INTEGER,
PRIMARY KEY(classeId, matiereId, enseignantId),
FOREIGN KEY(classeId) REFERENCES CLASSE(classeId),
FOREIGN KEY(matiereId) REFERENCES MATIERE(matiereId),
FOREIGN KEY(enseignantId) REFERENCES ENSEIGNANT(enseignantId)
);
CREATE TABLE SAIT_ENSEIGNER(
matiereId INTEGER,
enseignantId INTEGER,
PRIMARY KEY(matiereId, enseignantId),
FOREIGN KEY(matiereId) REFERENCES MATIERE(matiereId),
FOREIGN KEY(enseignantId) REFERENCES ENSEIGNANT(enseignantId)
);
Dans la table ENSEIGNE les deux clés étrangères faisant référence aux tables MATIERE et ENSEIGNANT sont donc à remplacer par une clé étrangère unique (cf. contrainte ENSEIGNE_SAIT_ENSEIGNER_FK ci-dessous) faisant référence à la table SAIT_ENSEIGNER.
Si aux clés étrangères à supprimer était associé un nom de contrainte (reprenant par exemple le nom des rôles enseigne_matiere et enseigne_enseignant) alors on pourrait effectivement compléter le code SQL au moyen d’une règle Looping :
ALTER TABLE ENSEIGNE
DROP CONSTRAINT enseigne_matiere, enseigne_enseignant
;
ALTER TABLE ENSEIGNE
ADD CONSTRAINT ENSEIGNE_SAIT_ENSEIGNER_FK FOREIGN KEY(matiereId, enseignantId)
REFERENCES SAIT_ENSEIGNER(matiereId, enseignantId)
;
En attendant, on modifie le code SQL manuellement :
CREATE TABLE CLASSE
(
classeId INTEGER NOT NULL
, CONSTRAINT CLASSE_PK PRIMARY KEY(classeId)
) ;
CREATE TABLE MATIERE
(
matiereId INTEGER NOT NULL
, CONSTRAINT MATIERE_PK PRIMARY KEY(matiereId)
) ;
CREATE TABLE ENSEIGNANT
(
enseignantId INTEGER NOT NULL
, CONSTRAINT ENSEIGNANT_PK PRIMARY KEY(enseignantId)
) ;
CREATE TABLE SAIT_ENSEIGNER
(
matiereId INTEGER NOT NULL
, enseignantId INTEGER NOT NULL
, CONSTRAINT SAIT_ENSEIGNER_PK PRIMARY KEY(matiereId, enseignantId)
, CONSTRAINT SAIT_ENSEIGNER_MATIERE_FK FOREIGN KEY(matiereId)
REFERENCES MATIERE(matiereId)
, CONSTRAINT SAIT_ENSEIGNER_ENSEIGNANT_FK FOREIGN KEY(enseignantId)
REFERENCES ENSEIGNANT(enseignantId)
) ;
CREATE TABLE ENSEIGNE
(
matiereId INTEGER NOT NULL
, enseignantId INTEGER NOT NULL
, classeId INTEGER NOT NULL
, CONSTRAINT ENSEIGNE_PK PRIMARY KEY(matiereId, enseignantId, classeId)
, CONSTRAINT ENSEIGNE_SAIT_ENSEIGNER_FK FOREIGN KEY(matiereId, enseignantId)
REFERENCES SAIT_ENSEIGNER(matiereId, enseignantId)
, CONSTRAINT ENSEIGNE_CLASSE_PK FOREIGN KEY(classeId)
REFERENCES CLASSE(classeId)
) ;
@ Paprick
Peut-on espérer que Looping prenne un jour en compte ce type de contrainte au stade SQL ? (c’est l’époque des voeux et des étrennes... 
)
... même si je regrette que la splendide "Miss PK" affichée par François ait ainsi été rayée
!
Répondre avec citation
Merci François ! 
Envoyé par CinePhil
)... le plus utilisé.
) auront bien du mal ! 
.
mais dans lesquelles on retrouve le nom des schémas (bdd) et tables concernées par les contraintes.
Partager