La notation pied de corbeau

Le pied-de-corbeau - proprement, la notation Information Engineering - place deux marques à chaque extrémité de chaque trait de relation. Celle qui est la plus éloignée de l'entité est le maximum, celle qui est la plus proche est le minimum.

Combinez-les et il y a exactement quatre possibilités, ce qui est toute la notation :

C'est la seule chose vraiment contre-intuitive du pied-de-corbeau, et elle explique la plupart des diagrammes mal lus. Les symboles d'une extrémité décrivent l'entité de cette extrémité, et on les lit en se déplaçant vers elle.

Sur le quatrième trait du diagramme ci-dessus, le pied-de-corbeau est du côté Order. Il ne veut pas dire « plusieurs clients ». Il veut dire : pour un client, il y a zéro ou plusieurs commandes. Dites-le comme un trajet - « je pars d'un client, je suis le trait, et j'arrive à zéro ou plusieurs commandes » - et la direction cesse d'être ambiguë.

Une habitude qui supprime entièrement le problème : écrivez la locution verbale sur le trait dans le sens de lecture, et relisez la lecture inverse à voix haute avant de passer à la suite. Trente secondes par relation, et cela attrape des erreurs qui survivent des mois dans un document.

Le style du trait porte une seconde information, et elle concerne les clés, pas les comptes.

Le test tient en une question : cette ligne pourrait-elle être identifiée sans connaître son parent ? Une ligne de commande numéro 3 n'a pas de sens sans savoir de quelle commande - c'est identifiant. Une commande appartenant au client 41 reste la commande 8817 quoi qu'il arrive - c'est non identifiant.

Un pied-de-corbeau aux deux bouts dit « plusieurs à plusieurs », et aucune base relationnelle ne sait stocker cela en deux tables. La relation devient une entité à part entière - une entité de jonction, associative ou de liaison - portant une clé étrangère vers chaque côté.

Deux choses en découlent, et la seconde est la raison de le faire tôt plutôt qu'au moment de l'implémentation :

1. La jonction a généralement ses propres attributs. Une inscription a une date, une note, un statut. Ces attributs n'avaient nulle part où vivre tant que la relation était un trait, et leur absence cachait un trou dans le modèle.
2. La jonction mérite un vrai nom. Enrolment, Booking, Assignment - pas StudentCourse. Un expert métier reconnaît le premier et ne peut pas relire le second, et ce nom est généralement un mot que le métier emploie déjà.

Notez les clés de la jonction ci-dessus : les deux clés étrangères forment ensemble la clé primaire, ce qui empêche le même étudiant de s'inscrire deux fois au même cours. Cette contrainte est venue gratuitement d'une modélisation correcte, et aurait sinon été une validation dont quelqu'un s'est souvenu.

Rien de tout cela n'est exclusif. Beaucoup de projets réels tracent du pied-de-corbeau pour la base et un diagramme de classes pour le modèle du domaine, et gardent les deux, parce qu'ils répondent à des questions différentes sur les mêmes noms.

1. Symboles à la mauvaise extrémité. L'erreur la plus fréquente de la notation. Lisez les deux phrases à voix haute.
2. Tout optionnel. Un cercle à chaque position intérieure signifie que le modèle n'affirme aucune règle, et chacune d'elles devient du code applicatif.
3. Plusieurs-à-plusieurs laissé dans un modèle logique. Acceptable conceptuellement, impossible physiquement. Résolvez-le et nommez la jonction.
4. Des entités de jonction nommées par concaténation. OrderProduct ne dit rien à un relecteur ; OrderLine lui dit tout.
5. Se fier au seul style de trait pour les relations identifiantes. Les outils divergent. Montrez aussi la clé composite dans la boîte.
6. Relations non étiquetées. Le verbe est ce qui rend le trait lisible à voix haute, et lire à voix haute est la relecture.

Une fois la cardinalité réglée, la question suivante est celle des tables elles-mêmes - c'est-à-dire la conception de schéma : clés, normalisation, et le trajet du modèle au DDL.