Discussion :

[Milleras]

Bonjour à tous.
Voilà une (toute) petite partie de mon MCD et j'ai une question.

J'ai deux propriétés "note" et "remarque" à rajouter et ceux ci sont ajoutées par une session.
Je dois également créer une entité "Motif" avec un "idMotif" et "libelleMotif" également ajoutée par une session pour un étudiant.

Est ce que je dois créer une entité Evaluation et y relier la entité Motif ou alors je met "note et "remarque" dans ma entité "Candidat" et y relie ma entité "motif"?

Merci par avance de vos réponses.

[CinePhil]

J'ai deux propriétés "note" et "remarque" à rajouter et ceux ci sont ajoutées par une session.

"Par" une session ?
Si tu veux dire que la note et la remarque constituent le résultat de l'évaluation du candidat lors d'une session, alors il suffit d'ajouter les propriétés "note" et "remarque" à l'entité "Candidat" puisqu'un candidat n'est évalué qu'une seule fois.

Je dois également créer une table "Motif" avec un "idMotif" et "libelleMotif" également ajoutée par une session pour un étudiant.

Que signifie cette notion de "motif" ?
C'est une autre propriété de l'évaluation et elle est à choisir dans une liste définie de libellés ?
Alors l'association devient ternaire :
Session -0,n----Evaluer----(1,1)- Candidat
Motif -0,n------------|

Est ce que je dois créer une table Evaluation et y relier la table Motif ou alors je met "note et "remarque" dans ma table "Candidat" et y relie ma table "motif"?

Voir schéma ci-dessus.
Je suis par contre un peu étonné de la cardinlaité 1,1 du côté du candidat dans ton morceau de MCD.
Un candidat n'est-il pas d'abord inscrit avant d'avoir été évalué ?
Ta base de données n'enregistre t-elle que des résultats et ne gère t-elle pas des inscriptions aux sessions ?
Un candidat recalé ne peut-il repasser l'examen dans une autre session ?

[Milleras]

L'application (projet de fin d'année) consiste à gérer les candidatures dans les différentes filières de l'université où j'étudie.

Une fois le dossier reçu, l'université évalue le dossier lors d'une session en lui donnant un avis(favorable, défavorable,...), un motif (niveau insuffisant,...), et une remarque donc le dossier ne passe qu'une fois devant la commission.

Le motif et l'avis étant une liste déroulante dans l'application, je voulais en faire deux entités.

Doit-je donc relier les entités "motif" et "avis" à l'entité candidat?

Session -0,n----Evaluer----(1,1)- Candidat
Motif -0,n------------|

J'ignorais que c'était autorisé.

Quel est la différence entre faire une entité "evaluation" et mettre "remarque" dans candidat?

[CinePhil]

L'application (projet de fin d'année) consiste à gérer les candidatures dans les différentes filières de l'université où j'étudie.

Une fois le dossier reçu, l'université évalue le dossier lors d'une session en lui donnant un avis(favorable, défavorable,...), un motif (niveau insuffisant,...), et une remarque donc le dossier ne passe qu'une fois devant la commission.

Je suppose donc que ces dossiers de candidature sont enregistrés puis évalués lors d'une session et le résultat de l'évaluation enregistré pendant ou après la session ?
Donc selon moi, la cardinalité devrait être 0,1 et non pas 1,1.

Sauf si le traitement des dossiers est fait manuellement et que c'est seulement le résultat de l'évaluation qui est enregistré.

Le motif et l'avis étant une liste déroulante dans l'application, je voulais en faire deux entités.

Effectivement, c'est plus propre.

Selon ce que j'ai écrit plus haut le schéma pourrait être le suivant :
Session -0,n----Evaluer----(0,1)- Candidat
Motif -0,n-----------| |----------0,n- Avis

Ainsi on a bien :
- Un candidat peut être évalué une fois lors d'une session
- Un motif peut être utilisé plusieurs fois lors des sessions d'évluation
- Un avis peut être utilisé plusieurs fois lors des sessions d'évluation
- Une session peut évaluer plusieurs candidats.

L'identification relative du candidat (cardinalité 0,1 entre parenthèses) fera que l'identifiant de la table issue de l'association Evaluer sera l'identifiant du candidat et non pas le quadruplet d'identifiants de la session, du candidat, du motif et de l'avis.

J'ignorais que c'était autorisé.

Je ne vois pas pourquoi ça ne le serait pas !

Quel est la différence entre faire une entité "evaluation" et mettre "remarque" dans candidat?

La remarque figure parmi les résultats de l'évaluation non ?

L'entité "Evaluation" est équivalente à l'association évaluer.
On aurait alors le schéma, plus complexe, suivant :
Session -0,n----Réaliser----1,1- Evaluation
Candidat -(0,1)-----Evaluer----1,1----|
Motif -0,n----Motiver-----------1,1------|
Avis -0,n-----Résulter---------1,1------|

En mettant l'identification relative du candidat vers l'évaluation, c'est l'identifiant du candidat qui devient l'identifiant de l'évaluation. L'entité Evaluation n'a donc pas d'identifiant propre.

Au fait, à propos d'identifiant... Sur ton schéma, idSession et numDossierCandidat sont de type INTEGER(255). INTEGER est suffisant, le 255 ne signifie rien.

Et tant qu'on y est :
- Tu connais des noms de famille et des prénoms qui peuvent faire 255 caractères ?
- La dateSession devrait être de type DATE
- Le numéro de dossier peut être un code alphanumérique plutôt qu'un entier auto-incrémenté. Par contre je maintiendrais, en plus de ce numéro de dossier alphanumérique, un identifiant anonyme de type entier qui constitue une meilleur clé qu'une chaîne variable.
- moyBacCandidat est de type REAL, pas REAL(255).

[Milleras]

Sauf si le traitement des dossiers est fait manuellement et que c'est seulement le résultat de l'évaluation qui est enregistré.

On enregistre les candidats avant les différentes sessions et une fois qu'elle a eu lieu on y ajoute les résultats (de la sessions).

Donc selon moi, la cardinalité devrait être 0,1 et non pas 1,1.

Je vais changer ça.

Session -0,n----Evaluer----(0,1)- Candidat
Motif -0,n-----------| |----------0,n- Avis

Que donnerait le MLD dans ce cas?
Quand je disais que je pensais ne pas etre autorisé, j'ai toujours pensé qu'on ne pouvais faire d'association ternaire ou plus que si on a des cardinalités maximal à "n".

Session -0,n----Réaliser----1,1- Evaluation
Candidat -(0,1)-----Evaluer----1,1----|
Motif -0,n----Motiver-----------1,1------|
Avis -0,n-----Résulter---------1,1------|

N'y a t il pas une erreur au niveau de l'entité faible?

Je dirais que la parenthèse devrait être du coté de Evaluation.

Session -0,n----Réaliser----1,1- Evaluation
Candidat -0,1-----Evaluer----(1,1)----|
Motif -0,n----Motiver-----------1,1------|
Avis -0,n-----Résulter---------1,1------|

[CinePhil]

Que donnerait le MLD dans ce cas?

Le MLD Merise :
Session <-----Evaluation-----> Candidat
Motif <-------------| |-----------> Avis

Ou le schéma entity/relation (comme dans MySQL Workbench par exemple) qui est plus parlant :
Session -|-----< Evaluation-----|- Candidat
Motif -|------------------v v-----------|- Avis

L'extrémité -|- signifie 1.
L'extrémité < (qui est en fait une patte d'oie à trois doigts) signifie plusieurs.
Donc, par exemple, 1 "Session" distribue son identifiant à plusieurs "Evaluation".

Pas sûr de l'exactitude du formalisme mais dans les deux cas ça donnerait les tables :
Session (S_Id, S_Nom, S_Date)
Motif (M_Id, M_Libelle)
Avis (A_Id, A_Libelle)
Candidat (C_Id, C_NumDossier, C_Nom, C_Prenom, ...)
Evaluation (E_IdCandidat, E_IdSession, E_IdMotif, E_IdAvis, E_Remarque)

Quand je disais que je pensais ne pas etre autorisé, j'ai toujours pensé qu'on ne pouvais faire d'association ternaire ou plus que si on a des cardinalités maximal à "n".

Ben non je ne pense pas.

N'y a t il pas une erreur au niveau de l'entité faible?

Je dirais que la parenthèse devrait être du coté de Evaluation.

Session -0,n----Réaliser----1,1- Evaluation
Candidat -0,1-----Evaluer----(1,1)----|
Motif -0,n----Motiver-----------1,1------|
Avis -0,n-----Résulter---------1,1------|

Euh... peut-être... je n'étais pas sûr de mon coup là dessus.

[Milleras]

Session -0,n----Evaluer----(0,1)- Candidat
Motif -0,n-----------| |----------0,n- Avis

Pour moi ça aurait donné

Session (S_Id, S_Nom, S_Date)
Motif (M_Id, M_Libelle)
Avis (A_Id, A_Libelle)
Candidat (C_Id, E_IdCandidat, E_IdSession, E_IdMotif, E_IdAvis, C_NumDossier, C_Nom, C_Prenom, ...)
Evaluation (E_IdCandidat, E_IdSession, E_IdMotif, E_IdAvis, E_Remarque)

C'est pour ça que je doute de l'utilisation de cardinalités max à 1 dans une association supérieur à 2 entités.

Car cela

Session (S_Id, S_Nom, S_Date)
Motif (M_Id, M_Libelle)
Avis (A_Id, A_Libelle)
Candidat (C_Id, C_NumDossier, C_Nom, C_Prenom, ...)
Evaluation (E_IdCandidat, E_IdSession, E_IdMotif, E_IdAvis, E_Remarque)

serait plutot

Session (S_Id, S_Nom, S_Date)
Motif (M_Id, M_Libelle)
Avis (A_Id, A_Libelle)
Candidat (C_Id, C_NumDossier, C_Nom, C_Prenom, ...)
Evaluation (E_IdCandidat, E_IdSession, E_IdMotif, E_IdAvis, E_Remarque)

ne traduit pas la notion d'entité faible du coté de candidat.

[CinePhil]

Quel que soit le formalisme du schéma, ce qui est sûr c'est qu'il faut que la table Evaluation soit identifiée relativement par le candidat.
Ma liste des tables reste valable.

[Milleras]

Ok donc je vais faire une table Evaluation avec comme identifiant celui de candiat.

En tout cas merci de l'aide qui m'a été précieuse.
Bonne journée et encore merci.