Bonsoir à tous,
Plutôt que tenter de recourir à des subterfuges, à savoir concaténer des noms d’objets de nature différente, appelons un chat un chat !
Je remets les compteurs à zéro et laisse de côté ce que j’ai écrit au sujet de « Rôle » et « Contrainte » : à la réflexion, ces deux concepts sont indépendants l’un de l’autre. En effet :
— Le rôle porté par une patte d’association est seulement là pour mieux faire parler le MCD (et n’influence en rien le code SQL), en conséquence de quoi il doit forcément être affiché dans le diagramme si dans la fenêtre « Cardinalité » le cartouche « Rôle » est renseigné. Dans ces conditions la case à cocher « Afficher dans le modèle » est rendue de facto inutile, elle passe donc au rasoir d’Ockham (y-compris dans le cas des réflexives). A noter que le rôle devrait logiquement se propager jusqu’au MLD graphique, là encore seulement pour faire parler le diagramme (avec la possibilité qu’on puisse l’effacer si par exemple le diagramme devient trop chargé...)
— Le nom de la contrainte portée par cette patte n’est pas là pour faire parler le MCD, mais permet d’anticiper sur le nom à donner aux contraintes de clés étrangères (notamment dans le cas des réflexives), et se propage donc jusqu’au code SQL (CREATE/ALTER TABLE). Inutile d’en demander l’affichage dans le MCD puisqu’en aval c’est fondamentalement le code SQL qui est concerné. En l’absence de clé étrangère à générer (c’est-à-dire du côté x,N de la patte), en toute logique pas de cartouche ad-hoc.
1er exemple :
Soit la partie suivante du MCD (laquelle reprend le diagramme figurant dans le post #86, aux rôles près qui changent de nom) :
[E1{e1Id}]------1,1------(R)------0,N------[E2{e2Id}]
Côté 1,1 :
Côté 0,N :
En notant que dans le cas d’une x,1/y,N le nom de contrainte côté N est sans objet (donc que le cartouche « Nom de contrainte » n’a alors pas d’utilité, comme déjà signalé...)
=>
MCD
[E1{e1Id}]------1,1------(R)------0,N------[E2{e2Id}]
Enfant Parent
CREATE TABLE E1
(
e1Id INT NOT NULL,
e2Id INT NOT NULL,
PRIMARY KEY(e1Id),
CONSTRAINT E1_E2_FK FOREIGN KEY(e2Id) REFERENCES E2(e2Id)
);
2e exemple
Soit la représentation suivante :
[E1{e1Id}]------0,N------(R)------0,N------[E2{e2Id}]
Côté E1 :
Côté E2 :
Passage à SQL :
CREATE TABLE R
(
e1Id INT NOT NULL,
e2Id INT NOT NULL,
PRIMARY KEY(e1Id, e2Id),
CONSTRAINT R_E1_FK FOREIGN KEY(e1Id) REFERENCES E1(e1Id),
CONSTRAINT R_E2_FK FOREIGN KEY(e2Id) REFERENCES E2(e2Id)
);
Cas des noms des attributs :
Comme je l’ai déjà écrit, les noms des attributs (ou plutôt des colonnes) SQL ne devraient pas être transformés au stade MCD. Le code SQL précédent se substitue normalement à celui qui est actuellement généré (voir quand même ci-dessous la remarque de CinePhil) :
CREATE TABLE R
(
e1Id_Désignation INT,
e2Id INT,
PRIMARY KEY(e1Id_Désignation, e2Id),
FOREIGN KEY(e1Id_Désignation) REFERENCES E1(e1Id),
FOREIGN KEY(e2Id) REFERENCES E2(e2Id)
);
Cas des noms des contraintes de clé primaire :
Dans la série « appelons un chat un chat », puisqu’une table SQL a une seule clé primaire, pour mon exemple précédent, une évolution de la fenêtre « Association » du genre de ce qui suit me conviendrait bien :
Cas des noms des contraintes des clés alternatives :
En suspens… 
Cas de la génération évoquée par CinePhil (cf. son post #75) :
Envoyé par
CinePhil
Pour ma part, je nomme mes clés étrangères selon le nom de la colonne qui en fait l'objet...
Exemple :
te_personne_prs (
prs_id,
prs_id_civilite, prs_nom, prs_prenom...)
CONSTRAINT fk_prs_id_civilite FOREIGN KEY...
Et comme par son nom on sait que la colonne
prs_id_civilite fait partie de la table te_personne_
prs, on sait que la contrainte concerne aussi cette table.
Philippe, pour les noms des contraintes, le système ci-dessus devrait te convenir :
Cela donne lieu a :
CONSTRAINT fk_prs_id_civilite FOREIGN KEY...
En effet, on est dans le genre de situation où quand la génération du code SQL est faite à partir du MLD, renommer les colonnes, notamment pour les tables issues d’associations, peut se faire the fingers in the nose, ici ça devient plus qu’acrobatique et là, Paprick va tousser grave et peut-être bien vouloir taper !!!
En attendant, je mets mon casque lourd et me tapis au fond de la tranchée, car il pourrait pleuvoir pleins de trucs, comme à Gravelotte... Comme dit Paprick, 
Irrésistiblement, le principe de la non démontrabilité me fait penser à Kurt Gödel et « comme toujours » à Jacques Brel, un des héros de mes 20 ans...
Répondre avec citation
... 
, je suis en train d'intégrer la case à cocher "Suffixer les clés étrangères" en cas de rôle (que tu pourras donc décocher !) 
Partager