Discussion :

[escartefigue]

bonjour François

En effet, mais c'est moins lisible que le MCD originel (moins naturel en tout cas à mes yeux) et au stade SQL, on récupère une table supplémentaire qui n'a pas vraiment de raison d'être.
Mais bon, je retiens l'argument de Paprick : dans la mesure où les contraintes ne sont pas directement gérées par Looping du MCD vers le DDL, on ne saurait lui reprocher de ne pas les gérer dans l'autre sens.
J'y ajoute que comme les autres logiciels de modélisation font moins bien (et le plus souvent ne proposent rien du tout au sujet du DDL des contraintes), ça me va bien.
Sans compter que le fait que les DBA aient toujours un peu de travail me va bien aussi

[fsmrel]

Ave Capitaine,

au stade SQL, on récupère une table supplémentaire qui n'a pas vraiment de raison d'être.

 
Une table en plus (table Annulation) ça n’est pas un problème dans la mesure où :

(1) Elle est saine (non polluée par NULL),

(2) Elle permet d’éviter ainsi le piège des clés étrangères nullables (cf. les posts #16 et #40, ta table E3 contient une telle clé étrangère : "FOREIGN KEY(E1ident) REFERENCES E1(E1ident)", sans oublier bien entendu la clé étrangère nullable, conséquence de l’auto-référence,

(3) La table supplémentaire Annulation permet d’éviter la double référence à E1 (cf. ta table E3, "FOREIGN KEY(E1ident_1) REFERENCES E1(E1ident)", "FOREIGN KEY(E1ident) REFERENCES E1(E1ident)".

Bref, la table supplémentaire pallie de façon simple les impedimenta évoqués.

Quant à la lisibilité des MCD, je pense que le MCD rétroconçu ci-dessous n’est quand même pas d’une limpidité exemplaire dans sa partie droite...

Et pourtant c’est le MCD sur lequel les développeurs devront s’appuyer, avec le souci constant de l’auto-référence (horresco referens, sic !), jamais simple à manipuler...  

[escartefigue]

Non obstante his omnibus argumentis, persevero

Pour moi, conceptuellement parlant, le schéma le plus lisible est celui portant la contrainte, l'originel donc, mais à l'impossible nul n'est tenu