Au format de erdiag :

[Parties]
+id
Résultat

[Tournois]
+id
nom
édition
lieu

[Joueurs]
+num_FIDE
prénom
nom

[Cadences]
+id
description

[Classements]
+elo

[Coups]
+id
code
numéro

{Jouée_dans}
Parties 1
Tournois +

{Être_classé}
Joueurs +
Classements *
--
Date

{Inscrits}
Tournois +
Joueurs *

{Jouée_à}
Cadences *
Parties 1

{Jouer}
Joueurs *
Parties +
--
Couleur

{Comporter}
Parties +
Coups *

Remarques :

• "Classements" est plutôt artificiel, contenant seulement un champ "elo" = clé. En pratique (automatique) on efface l'entité - sauf si certains classements sont impossibles, mais ce n'est pas le cas aux échecs.
• une partie est jouée par exactement deux joueurs, mais comme on ne peut pas traiter la cardinalité 2 il faut indiquer 1,n.
• Les attributs d'associations "Date" et "Couleur" dépendent bien de toutes les entités en association (condition nécessaire).

1. Oui (créneau → cours : 0,n)
2. Non (cours → nageurs : 1,n)
3. Non, puis non. Il semble y avoir une anomalie, car un MN doit bien faire l'une ou l'autre de ces tâches, sinon il s'ennuie. C'est en fait représentable sur le schéma E/A en suivant les conventions résumées à cet endroit. On peut aussi contourner le problème en supposant raisonnablement qu'ils surveillent tous au moins une fois dans la semaine, et changer la cardinalité 0,n en 1,n.
4. En fait il n'y a pas vraiment d'indices sur le schéma, qui est plutôt général : "on ne peut pas savoir" est donc la réponse attendue. Cela peut être justifié en indiquant qu'aucune cardinalité 0,n ou 1,n ne part d'une entité en association binaire avec Bassin.

Clarification sur l'association ternaire : "un bassin (fixé) est en relation au moins une fois avec un créneau et un MN donné". Si par exemple on change 0,n en 0,1 de MN vers l'association ternaire, alors un MN donné surveille au plus un (unique) créneau dans un (seul) bassin.

Schéma au format erdiag :

[Nageurs]
+id
prénom
nom
catégorie_pro

[Tarifs]
+id
abonnement
réduit

[Maîtres-nageurs]
+id
prénom
nom

[Cours]
+id
thème
tarif

[Créneaux]
+id
jour
heure_début
durée

[Bassins]
+id
longueur
largeur
profondeur

{payer}
Nageurs 1
Tarifs *

{participer}
Nageurs *
Cours +
--
record

{assurer}
Maîtres-nageurs *
Cours 1

{avoir_lieu_pendant}
Cours 1
Créneaux *

{avoir_lieu_dans}
Cours 1
Bassins *

{surveiller}
Créneaux *
Bassins +
Maîtres-nageurs *

Brouillon d'une possible modélisation : celle-ci sera améliorée au fil des séances.

Avec la syntaxe erdiag :

[Users]
+id
name
email
location
birthdate
gender

[Groups]
+id
name
description

[Events]
+id
name
description

[Messages]
+id
date
content

{send}
Messages ?
Users *

{send_group}
Messages ?
Users *
Groups *

{like}
Users *
Users *

{follow}
Users *
Users *

{is_friend_with}
Users *
Users *

{participate}
Events *
Users *
--
degree

Remarques :

• Is_friend_with est symétrique, mais ça ne peut pas se voir sur le schéma E/A (ni d'ailleurs sur le schéma logique). Il faudra s'assurer de cela au moment de l'implémentation.
• L'attribut d'association "degree" résume les deux options a priori possibles dans FB : "je suis sûr d'y aller" / "je suis intéressé". Le terme est peut-être mal choisi.
• Les associations "follow", "like" et "is_friend_with" seront tranformées en tables, ainsi pour aller chercher les amis de X il faudra trouver toutes les lignes lui correspondant. La recherche est sous-linéaire grâce à l'indexation (on verra ça dans un cours ultérieur), mais on sent quand-même que ce n'est pas l'implémentation la plus efficace. On y reviendra.
• L'anomalie observée sur le schéma de la piscine se retrouve ici au niveau de l'entité "Messages" : un message est envoyé vers un utilisateur, ou (exclusif !) vers un groupe. Ici aussi il faudrait adopter la notation décrite sur la FAQ en lien plus haut. Ceci dit l'outil que j'utilise ne permet pas encore cette représentation, et on ne pourrait pas l'exprimer sur le schéma MLD.