Associations réflexives, ternaires et identifiants relatifs

Une association réflexive relie une entité à elle-même : un adhérent est le responsable légal d'autres adhérents. Une association ternaire relie trois entités à la fois : un professeur enseigne une matière dans une classe. Une entité faible, enfin, n'a pas d'identifiant à elle seule : une salle n'est identifiée que par son numéro dans un bâtiment, ce qu'on appelle un identifiant relatif. Ces trois constructions reviennent souvent dans les sujets ; ce chapitre explique quand les utiliser et comment poser leurs cardinalités.

L'association réflexive

Une association réflexive relie deux occurrences d'une même entité. Elle a deux pattes, toutes deux reliées à la même entité, et chaque patte correspond à un rôle qu'il faut nommer, sinon le schéma est illisible.

À Rivelire, la RG8 relie un adhérent mineur à son responsable légal, lui-même adhérent :

ADHERENT (représenté) 0,1 ──── REPRESENTER ──── 0,n ADHERENT (responsable)

• Rôle « représenté » : un adhérent est représenté par zéro ou un responsable (0,1).
• Rôle « responsable » : un adhérent représente zéro, un ou plusieurs mineurs (0,n).

Les associations réflexives traduisent les hiérarchies et les liens entre semblables :

La base parc du cours SQL contient une association réflexive du premier type : la colonne id_responsable de la table employe (schéma de la base parc).

Plusieurs associations entre les mêmes entités

Deux entités peuvent être reliées par plusieurs associations, chacune avec son sens. Dans un cabinet médical, un patient a un médecin traitant ; il reçoit aussi des ordonnances rédigées par des médecins qui ne sont pas forcément son médecin traitant.

PATIENT 0,1 ──── AVOIR_POUR_TRAITANT ──── 0,n MEDECIN
ORDONNANCE 1,1 ──── REDIGER ──── 1,n MEDECIN
ORDONNANCE 1,1 ──── CONCERNER ──── 0,n PATIENT

Ne fusionne pas ces liens en une seule association « SOIGNER » : ils n'ont ni la même signification ni les mêmes cardinalités. Dans les tables, ils deviendront des clés étrangères de noms différents (num_medecin_traitant dans patient, num_medecin dans ordonnance).

L'association ternaire

Une association ternaire relie trois entités : chacune de ses occurrences est un triplet. Dans un lycée, « M. Martin enseigne les mathématiques en SIO1 A, 3 heures par semaine » est une occurrence de l'association ENSEIGNER entre PROFESSEUR, MATIERE et CLASSE, qui porte la propriété nb_heures.

Les cardinalités d'une ternaire se lisent comme d'habitude, mais en comptant des triplets : « Un professeur participe à combien de triplets (professeur, matière, classe) ? » Au moins un s'il enseigne, et plusieurs : 1,n. De même pour la matière et la classe.

Quand une ternaire est-elle justifiée ? Quand l'information ne peut pas se découper en associations binaires sans perte. Prenons trois triplets :

Si on les remplace par trois associations binaires (qui enseigne quelle matière, qui enseigne dans quelle classe, quelle matière est enseignée dans quelle classe), on garde : Martin enseigne les mathématiques, Martin enseigne en SIO2 B, les mathématiques sont enseignées en SIO2 B. Les trois binaires suggèrent donc que Martin enseigne les mathématiques en SIO2 B, ce qui est faux : c'est Durand. Les associations binaires ont perdu l'information de qui fait quoi où. Ici, la ternaire est nécessaire.

Une ternaire avec une CIF. Ajoutons la règle : « dans une classe, chaque matière est enseignée par un seul professeur ». Connaissant la classe et la matière, on connaît alors le professeur : (code_classe, code_matiere) → num_professeur. La ternaire reste juste, mais elle porte une contrainte d'intégrité fonctionnelle, que certains logiciels dessinent par une flèche « CIF » vers PROFESSEUR. Conséquence au MLD : la clé primaire de la table enseigner se réduit au couple (code_classe, code_matiere), et num_professeur devient une simple clé étrangère (chapitre 8).

Les ternaires dans les sujets. Elles y sont rares, et plus rares encore les quaternaires (quatre entités). Si tu en vois une dans ta copie, vérifie que tu n'as pas oublié une entité, comme EMPRUNT ou STAGE, qui aurait rendu les choses plus simples : une entité avec son propre identifiant est souvent préférable à une ternaire dont l'une des « entités » n'est qu'une date.

L'entité faible et l'identifiant relatif

Certaines entités n'ont pas d'identifiant à elles seules. Dans un campus, les salles sont numérotées dans chaque bâtiment : il y a une salle 12 dans le bâtiment A et une autre dans le bâtiment B. Le numéro seul ne suffit pas ; c'est le couple (bâtiment, numéro) qui identifie une salle. On dit que SALLE est une entité faible, et que son identifiant est relatif à celui de BATIMENT.

En Merise, on l'indique sur la patte de l'entité faible : la cardinalité 1,1 est écrite entre parenthèses, (1,1), ou suivie de la lettre R selon les logiciels. L'identifiant propre de l'entité faible (num_salle) reste souligné, mais il ne suffit qu'avec celui du bâtiment.

SALLE (1,1) ──── SITUER ──── 1,n BATIMENT

Une entité faible a trois caractéristiques :

1. elle est reliée à son entité « forte » par une association 1,1 de son côté : une salle est dans un seul bâtiment, pour toujours ;
2. elle n'existe pas sans elle : si on démolit le bâtiment, ses salles disparaissent ;
3. son identifiant complète celui de l'entité forte : le numéro de salle n'a de sens que dans le bâtiment.

Exemples fréquents : la ligne n° 3 d'une facture, le chapitre 2 d'un cours, la chambre 105 d'un hôtel, l'exemplaire n° 4 d'un document quand une bibliothèque numérote ses exemplaires au lieu de leur coller un code-barres.

Identifiant relatif ou identifiant artificiel ? On pourrait aussi donner à chaque salle un numéro unique dans tout le campus, id_salle, et relier SALLE à BATIMENT par une association 1,1 ordinaire. Les deux solutions sont justes. Préfère l'identifiant relatif quand l'organisation désigne vraiment ses objets ainsi (« la salle A-12 ») et que l'entité faible ne peut pas changer de parent ; préfère l'identifiant artificiel quand l'objet peut être déplacé, ou quand il sera référencé par beaucoup d'autres tables (la clé composée serait recopiée partout).

Au passage au MLD, la clé primaire de la table de l'entité faible est composée de la clé étrangère vers l'entité forte et de son identifiant propre : salle (#code_batiment, num_salle, capacite). On le reverra au chapitre 8.

Exercices