Ce qui suit est une traduction en français, une adaptation à la syntaxe de Mocodo et une discussion de quatre exemples d'association ternaire tirés de Toby J. Teorey, Sam S. Lightstone, Tom Nadeau, H.V. Jagadish, Database Modeling and Design - Logical Design, 5th Edition - February 10, 2011 (Elsevier), pp 29-30.
Les quatre combinaisons de cardinalités d'une association ternaire en notation LA
Triplet NNN (équivalent à la notation LH de Merise : ok)
Triplet 1NN (agrégat : ok)
Chaque ingénieur travaillant sur un projet particulier a exactement un responsable, mais chaque responsable d'un projet peut gérer plusieurs ingénieurs, et chaque responsable d'un ingénieur peut gérer cet ingénieur sur plusieurs projets.
Triplet 11N (erroné)
Chaque employé affecté à un projet travaille sur un seul site pour ce projet, mais peut se trouver sur différents sites pour différents projets. Sur un site donné, un salarié ne travaille que sur un seul projet. Sur un site donné, il peut y avoir plusieurs employés affectés à un projet donné.
Un technicien utilise exactement un carnet pour chaque projet. Chaque carnet appartient à un technicien pour chaque projet. Notez qu'un technicien peut toujours travailler sur plusieurs projets et gérer différents carnets pour différents projets.
Lorsque j'ai introduit la notation /1N, j'y voyais une façon d'indiquer que l'identifiant qui migrerait par-là se verrait au passage retirer son caractère identifiant. Ça marchait quand une seule des cardinalités 1N était marquée ainsi, mais à partir de deux, la clé primaire de la table associative réduisait comme une peau de chagrin, ce qui n'avait aucun sens.
En étudiant un peu la notation Look Across, de loin la plus répandue en dehors de la sphère francophone, j'ai réalisé que ma façon de voir était fausse, et qu'une autre s'imposait naturellement :
Supposons une association $n$-aire $A$ exclusivement entourée de 1N (ou 0N). Soient $E_1$, $E_2$, ..., $E_n$ les entités mises en jeu, et $k_1, k_2$, ..., $k_n$ leurs identifiants respectifs. Alors, noter /1N la cardinalité de la patte de $E_i$ dénote l'existence de la dépendance fonctionnelle suivante : $(k1, ..., k{i-1}, k_{i+1}, ..., k_n) \implies k_i$, autrement dit : que $(k1, ..., k{i-1}, k_{i+1}, ..., k_n)$ est une clé candidate de la table $A$.
La notation se généralise alors parfaitement à plusieurs cardinalités /1N : chacune créera une nouvelle dépendance fonctionnelle, autrement dit, une nouvelle clé candidate.
Le concepteur peut spécifier à coût zéro quelle clé candidate sera élue clé primaire. Il lui suffit pour cela de placer en tête de la liste des entités mises en jeu par $A$ celle dont l'identifiant ne doit pas entrer dans la clé primaire. Si c'est $E_1$, la clé primaire sera automatiquement $(k_2, ..., k_n)$.
Dans tous les cas, les clés alternatives se verraient traduites aux niveaux relationnel et physique par des contraintes d'unicité.
Aspect graphique
Chaque /1N doit donner lieu au tracé d'une enveloppe d'agrégat distincte (ce n'est pas le cas actuellement). Il faut alors veiller à élargir ou rétrécir chacune des enveloppes pour éviter les chevauchements. Jouer sur l'opacité et éventuellement les couleurs de fond peut aussi améliorer la lisibilité.
Si le MCD comporte au moins une contrainte CIF, cette visualisation est automatiquement désactivée (c'est le cas actuellement). Ainsi, l'exemple pour le triplet (11N) pourrait être rendu de façon plus orthodoxe comme :
À noter : l'ajout automatique des CIF à partir des /1N peut être programmé facilement. Inclure cette transformation dans les arguments de la nouvelle option --rewrite.
Ce qui suit est une traduction en français, une adaptation à la syntaxe de Mocodo et une discussion de quatre exemples d'association ternaire tirés de Toby J. Teorey, Sam S. Lightstone, Tom Nadeau, H.V. Jagadish, Database Modeling and Design - Logical Design, 5th Edition - February 10, 2011 (Elsevier), pp 29-30.
Les quatre combinaisons de cardinalités d'une association ternaire en notation LA
Triplet NNN (équivalent à la notation LH de Merise : ok)
Triplet 1NN (agrégat : ok)
Chaque ingénieur travaillant sur un projet particulier a exactement un responsable, mais chaque responsable d'un projet peut gérer plusieurs ingénieurs, et chaque responsable d'un ingénieur peut gérer cet ingénieur sur plusieurs projets.
Triplet 11N (erroné)
Chaque employé affecté à un projet travaille sur un seul site pour ce projet, mais peut se trouver sur différents sites pour différents projets. Sur un site donné, un salarié ne travaille que sur un seul projet. Sur un site donné, il peut y avoir plusieurs employés affectés à un projet donné.
Problèmes.
Triplet 111 (erroné)
Un technicien utilise exactement un carnet pour chaque projet. Chaque carnet appartient à un technicien pour chaque projet. Notez qu'un technicien peut toujours travailler sur plusieurs projets et gérer différents carnets pour différents projets.
Problèmes.
Discussion
Aspect sémantique
Lorsque j'ai introduit la notation
/1N, j'y voyais une façon d'indiquer que l'identifiant qui migrerait par-là se verrait au passage retirer son caractère identifiant. Ça marchait quand une seule des cardinalités1Nétait marquée ainsi, mais à partir de deux, la clé primaire de la table associative réduisait comme une peau de chagrin, ce qui n'avait aucun sens.En étudiant un peu la notation Look Across, de loin la plus répandue en dehors de la sphère francophone, j'ai réalisé que ma façon de voir était fausse, et qu'une autre s'imposait naturellement :
Supposons une association $n$-aire $A$ exclusivement entourée de 1N (ou 0N). Soient $E_1$, $E_2$, ..., $E_n$ les entités mises en jeu, et $k_1, k_2$, ..., $k_n$ leurs identifiants respectifs. Alors, noter
/1Nla cardinalité de la patte de $E_i$ dénote l'existence de la dépendance fonctionnelle suivante : $(k1, ..., k{i-1}, k_{i+1}, ..., k_n) \implies k_i$, autrement dit : que $(k1, ..., k{i-1}, k_{i+1}, ..., k_n)$ est une clé candidate de la table $A$.La notation se généralise alors parfaitement à plusieurs cardinalités
/1N: chacune créera une nouvelle dépendance fonctionnelle, autrement dit, une nouvelle clé candidate.Le concepteur peut spécifier à coût zéro quelle clé candidate sera élue clé primaire. Il lui suffit pour cela de placer en tête de la liste des entités mises en jeu par $A$ celle dont l'identifiant ne doit pas entrer dans la clé primaire. Si c'est $E_1$, la clé primaire sera automatiquement $(k_2, ..., k_n)$.
Dans tous les cas, les clés alternatives se verraient traduites aux niveaux relationnel et physique par des contraintes d'unicité.
Aspect graphique
Chaque
/1Ndoit donner lieu au tracé d'une enveloppe d'agrégat distincte (ce n'est pas le cas actuellement). Il faut alors veiller à élargir ou rétrécir chacune des enveloppes pour éviter les chevauchements. Jouer sur l'opacité et éventuellement les couleurs de fond peut aussi améliorer la lisibilité.Si le MCD comporte au moins une contrainte CIF, cette visualisation est automatiquement désactivée (c'est le cas actuellement). Ainsi, l'exemple pour le triplet (11N) pourrait être rendu de façon plus orthodoxe comme :
À noter : l'ajout automatique des CIF à partir des
/1Npeut être programmé facilement. Inclure cette transformation dans les arguments de la nouvelle option--rewrite.