Discussion :

[sub-0]

Bonjour,

Je dois réaliser une application intranet dans le cadre de mon stage, le sujet de cette application est la gestion des courriers de mon établissement, alors j'ai fait la modélisation suivante, veuillez m'indiquez les fautes que j'ai commis.
Merci d'avance

[CinePhil]

A part les parenthèses autour des cardinalités qui sont inutiles, à part l'entité Session qui se balade toute seule alors qu'elle devrait peut-être être associée à l'entité User, à part le nom bizarre 'recever' donné à l'association (je dirais plutôt 'recevoir'), c'est tellement simple comme schéma que c'est juste.

Un dernier truc quand même : Login est une mauvaise clé primaire pour l'entité Session. Une clé primaire est de type entier non signé, non nul et auto-incrémenté pour des raisons de performance, de non redondance des données et d'éventuels problèmes évités lors des mises à jour.

[sub-0]

D'abord merci pour la reponse , pour les parentheses c'est une question d'habitude rien d'autre .
Une petite explication: l'application sera utilisé par 3 types d'utilisateur:
-Utilisateur simple (ici c'est User qui est en réalité le professeur)
-Gestionnaire (qui joue le rôle d'opérateur de saisie des nouveaux courriers reçus)
-Admin (qui doit gérer les comptes des gestionnaires et des users)
alors je ne vois aucune relation entre user et session si vous pouvez m'expliquer la relation que vous me proposez ça sera mieux.
Pour la clé de l'entité session si j'ai mis un entier non nul et auto-incrémenté alors on peut avoir deux login pareil ?
Merci toujours pour votre aide

[CinePhil]

pour les parentheses c'est une question d'habitude rien d'autre .

Sauf que dans un MCD, cela symbolise une identification relative et ce n'est pas justifié ici.

Une petite explication: l'application sera utilisé par 3 types d'utilisateur:
-Utilisateur simple (ici c'est User qui est en réalité le professeur)
-Gestionnaire (qui joue le rôle d'opérateur de saisie des nouveaux courriers reçus)
-Admin (qui doit gérer les comptes des gestionnaires et des users)
alors je ne vois aucune relation entre user et session si vous pouvez m'expliquer la relation que vous me proposez ça sera mieux.

Ce sont bien les utilisateurs qui vont avoir des sessions utilisateur non ?
Du coup le modèle est peut-être simplifiable.
Et quel est l'intérêt de cette entité Session ?

Pour la clé de l'entité session si j'ai mis un entier non nul et auto-incrémenté alors on peut avoir deux login pareil ?

Pour l'éviter, il faut mettre ensuite un index de type UNIQUE sur le login.
Login est une clé candidate mais pas une bonne clé primaire.

[sub-0]

Ce sont bien les utilisateurs qui vont avoir des sessions utilisateur non ?

les users vont avoir des sessions utilisateur, les autres vont avoir des droits de "haut niveau"

Et quel est l'intérêt de cette entité Session ?

effectivement je pense que je ne dois pas mentionner cette table au niveau du MCD mais j'hésite car les logins et les mots de passe doivent figurer dans un table.
Je pense également que je dois créer un table département pour éviter les redondances, que pensez vous ??

[sub-0]

Bon voila après des conseils d'ici et labas j'ai fais les modifications suivante, j'espère que vous me répondiez le plus vite possible car je dois passer à l'étape de programmation ce soir, et merci

[CinePhil]

A priori, et sans connaître les règles de gestion qui amènent à ce schéma, ça semble bon.

Un détail tout de même : éviter les cardinalités minimales à 1 des deux côtés d'une association car ça pose des problèmes lors de l'implantation.

[sub-0]

Merci beaucoup Mr.Philipe pour ton aide précieux , maintenant je passe à l phase programmation.