DF à double sens : contrainte UNIQUE

[laowantong]

Originally posted by @fduchatea in https://github.com/laowantong/mocodo/issues/79#issuecomment-1582463224

Suite à une discussion avec les collègues, le cas d'une entité avec clé étrangère comme clé candidate est peu fréquent. A-priori, c'est uniquement quand les cardinalités d'une asso sont 1,1 de chaque côté.

PERSONNES: id, nom
PE, 11 PERSONNES, 11 EMAILS
EMAILS : email, x, y

Dans ce cas, Mocodo devrait détecter que email (ou id selon la traduction) est une clé candidate (et donc lui assigner la représentation appropriée), et déclarer l'attribut en UNIQUE (+ NOT NULL) dans le code SQL.

S'il y a une cardinalité 0,1 alors ça ne fonctionne pas (on peut mettre la contrainte UNIQUE mais ce n'est pas forcément une clé puisque les NULL sont possibles). S'il y a une cardinalité 0,n d'un côté, alors ça ne peut pas être une clé.

[laowantong]

C'est un genre d'association que j'interdis explicitement à mes étudiants. Mocodo le tolère, j'ai retrouvé ça dans la doc :

Autre point litigieux: dans les dépendances fonctionnelles à double sens ((1,1) des deux côtés), la priorité est donnée à la première des entités énumérées dans l'association. Même chose quand deux (0,1) sont en concurrence.

Donc, ça donne de façon déterministe :

EMAILS (email, x, y) PERSONNES (id, nom, #email)

Oui, Mocodo pourrait (devrait) alors ajouter les contraintes UNIQUE + NOT NULL sur l'attribut email.

[laowantong]

Je viens de traiter le sous-cas qui me paraît le plus intéressant, 01 --DF-- 11, par exemple :

Ou, de façon plus complexe, avec des entités faibles et des contraintes d'unicité déjà données explicitement :

Cela fait suite à cette discussion.

Je n'injecte toujours pas de contraintes NOT NULL pour le moment.

[laowantong]

Aperçu de la version 4, est-ce le résultat que vous attendiez ?

[fduchatea]

C'est bien le résultat attendu.

Une remarque : en SQL, les attributs formant la clé primaire (id ou email, dans l'exemple précédent) sont désormais définis avec une contrainte NOT NULL (qui est évidemment inutile puisque la contrainte de clé primaire l'implique déjà). Ca semble nouveau (j'utilise encore mocodo 3.2.0 et la contrainte NOT NULL n'apparait pas dans mes datasets). Ce n'est pas vraiment gênant, mais j'imagine que ce serait mieux sans.

[laowantong]

Cool.

Concernant votre remarque, c'est un choix que j'ai fait après avoir lu quelques discussions sur ce sujet précis. Spécifier NOT NULL pour une clé primaire, quoique redondant, semble être généralement considéré comme une bonne pratique.