Bonjour,
Je souhaiterais avoir des avis sur le mcd que j'ai crée.
Je décris un peu le fonctionnement :

Il y-a plusieurs personnes : prof,enfant,chef de famille,admin
Tous ces personnes peuvent s'inscrire a la newsletter d'un stage auquel un admin (qui peut aussi etre prof ou une famille) envoie des emails.
Un stagiaire s'inscrit à 1 ou plusieurs stages et pour un stage il possède une famille et est placé dans un groupe de classe
Ce groupe est sous la responsabilité d'un seul professeur.
On doit savoir avant de recevoir les fiches des stagiaires quelles sont les familles qui pourront accueillir des stagiaires cette année, à quelle stage il participeraient et combien de stagiaires ils prendraient.

Voici le mcd :



Et le mpd correspondant :



Maintenant, en regardant le mpd je me demande que viennent faire les lignes GRO_N°Stage et FAM_N°Personne dans la table INSCRIPTION STAGE ou FAM_N°Personne dans CHEF DE FAMILLE ou encore FAM_N°Personne dans FAMILLE

Pourquoi la traduction du MCD donne cela qui est inutile ?
Est-ce au niveau des liens identifiants ?

Avant de s'occuper du MPD il y a déjà quelque erreurs au niveau conceptuel:
-Enfant est aussi une spécialisation de l'entité personne;
-Il vaudrait mieux mettre l'e-mail comme propriété dans personne;
-L'entité inscription stage n'a pas lieu d'être;
-Et que représente l'entité évènement par rapport à stage ?

Bonjour, merci de ta réponse.
J'ai oublié de préciser quelques petites choses
En faites j'aurais plutôt du appeler l'entité personne UTILISATEUR. Les profs, les admins, les stagiaires et les chefs de famille sont des utilisateurs. L'entité ENFANT sert juste à savoir combien d'enfants possède une famille car elles en possèdent en nombre variable et les enfants ne sont donc pas utilisateur (ils n’accèdent pas au site).

Effectivement j'ai oublié de mettre un attribut e-mail dans l'entité UTILISATEUR (enfin PERSONNE) mais par contre l'entité EMAIL associé à STAGIAIRE permet de lier des adresses e-mails en plus de celle que possède le stagiaire et qui correspond au adresses e-mails des ces proches qui veulent s'inscrire à la newsletter.

L'entité événement correspond à tous les activités qui se dérouleront pendant le stage (Activité, Cours, Fêtes) Elle permet de constituer le programme du stage.

Pourquoi tu penses que l'entité INSCRIPTION STAGE n'a pas lieu d'être ?

L'entité inscription stage est en fait une association qui relie toutes les entités auxquelles elle est lié. En fait les associations enregistrer, posseder, posseder et concerner disparaissent et toutes les entités seront liées par une seul association inscription.

Oui je comprends bien mais à la fin cela donnera une association INSCRIPTION de type 4-aire
Et ma prof nous à déconseillé de faire des association n-aires>2-aires car elles sont sources de confusions et de mauvaises traductions.Elle nous oblige à la place de créer une entité esclave avec des liens identifiants et dfs.

En faites je crois que j'ai compris pourquoi il y'a les lignes GRO_N°Stage et FAM_N°Personne dans la table INSCRIPTION STAGE ou FAM_N°Personne dans CHEF DE FAMILLE ou encore FAM_N°Personne dans FAMILLE
Je pense que avec les liens identifiants ça reprend les identifiants composés des autres tables qui pointent sur l'entité esclave et que donc il est obligé de reprendre ces identifiants composés.
Mais ça fait bizarre de devoir reprendre l'attribut GRO_N°Stage par ce qu'il existe déjà N°STage et qu'il seront les mêmes mais comme c'est la clé primaire on peut pas en supprimer une partie .

Ta prof a tout à fait raison ce type d'associations est plutôt déconseillé, cependant la solution qu'elle te donnes (créer une entité esclave) ne fait que masquer le problème (intégrité des données) mais il est toujours là. La solution consisterais donc, dans ton cas, à associer stage et stagiaire et faire des agrégations avec les autre entités.

En revanche je ne comprend pas comment tu expliques les champs GRO_N°Stage, FAM_N°Personne,... il n'y a aucun identifiant composé (sauf dans inscrire). Je pense que certains champs sont inutiles, une relation [1,1]-[1,1 ](pour famille - chef de famille) va se traduire en mettant la clé primaire de chaque entités associés en clé étrangère dans l'autre donc dans ton MPD tu as au moins une ligne en trop dans chaque table où tu as ces GRO_N°Stage, etc ...
Cependant ton explication semble être juste pour expliquer le MPD dans la mesure où dans ton MPD il s'agit de la même FK, mais ce n'est pas pour autant qu'il est correct.
Essayes de le faire toi même à partir du MLD.

Je n'ai pas compris cela : cependant la solution qu'elle te donnes (créer une entité esclave) ne fait que masquer le problème (intégrité des données) mais il est toujours là. La solution consisterais donc, dans ton cas, à associer stage et stagiaire et faire des agrégations avec les autre entités.

La présence de GRO_N°Stage s'explique par le fait qu'une INSCRIPTION_STAGE concerne un stage mais qu'elle concerne aussi un groupe (N°Stage,N°Stage) Cependant les N°Stage seront les même il faut donc que je supprimer l'association CONCERNER d'INSCRIPTION_STAGE à STAGE car INSCRIPTION_STAGE concerne dejà un stage par le fait quelle concerne un groupe ( qui concerne un stage)
Bref et j'aurais du supprimer chef_de_famille et appliquer directement l'héritage de famille à personne ( l'identifiant de la famille sera donc celui de la personne en PK,FK).