Discussion :

[encours]

bonjour,
dans mon application
j'ai trois tables : utilisateur, admin, operateur
chacun de ces trois peut envoyer un message a l'autre
le message peut etre une reponse a un message envoyer par l'autre
ou bien il peut correspondre a une commande (car l'utilisateur passe des commandes a l'admin et l'admin peut envoyer un message sur cette commande (commande validé, rejeté, en cours de traitement))

tous ca concerne une application de gestion des requettes d'impression


mon probleme c'est que je ne suis pas arrivé a determiner est ce que je dois avoir une table message ou bien plusieurs et les attributs qui correspond au sujet et detinaire et comment garder l'historique des messages reponses et ...


voila a quoi je suis arrivé mais jusqu'a la j'ai des problemes sur cette table et comment gerer ces infos : l'historique des messages envoyés et recus....

voila l'image de mld :
http://postimage.org/image/fezebtifp/

pouvez vous m'aider ou me donner des exemples de cas proches


merci bien

[CinePhil]

Comme dit dans ton autre discussion, tu aurais intérêt à fusionner utilisateur, opérateur et administrateur puisque administrateur et opérateurs ne sont que des types d'utilisateurs.

Tu aurais aussi intérêt à externaliser grade et division dans des tables de référence, ainsi que l'état d'un message

Un message est-il envoyé par un utilisateur à un seul autre ou peut-il l'être à plusieurs ?
Les utilisateurs de même type peuvent-ils s'envoyer des messages entre eux ?

Je te recommande de reprendre la conception à zéro en commençant par écrire des règles de gestion claires car là j'ai du mal à les deviner au vu de ton schéma. D'ailleurs, il vaut mieux commencer par un MCD, même à la main, avant de passer au diagramme Entity/relationship de MySQL Workbench qui peut laisser faire des erreurs de modélisation quand on n'a pas trop l'habitude de cet exercice.

[encours]

voila les regles de gestion :
- il y a trois profils utilisateur, operateur et admin
- un utilisateur peut effectuer plusieurs commandes d'impression
- l'administrateur peut valider ou rejetter la commande, dans les deux cas un message de notification est envoyé au demandeur
- l'utilisateur peut repondre au message, et peut aussi envoyer un message sans commande et meme l'admin et peut avoir des reponses
- les demandes validés par l'administrateur (decision = true)seront affiché chez l'operateur qui va modifier l'etat de la commande (en attente, en cours de traitement, terminé, echoué), et un mesage de notification est envoyé a l'administrateur et peut etre envoyé aussi au demandeur (mais rarement)

- il peut y avoir des messages et des reponses entre l'administrateur et l'operateur mais pas entre l'operateur et le demandeur apart notification (en attente , ...)

[fsmrel]

Bonjour,

avant de passer au diagramme Entity/relationship de MySQL Workbench

Attention, le Modèle Entité-Relation a été concocté par Chen et se situe au niveau conceptuel, MCD, alors que MySQL Workbench est au niveau MLD (voire MPD si on veut pinailler, puisqu’on y parle des index). Du reste, les diagrammes produits avec Workbench ne sont pas du type entity-relationship, mais prétendument « enhanced entity-relationship » (EER), nuance ! tout en ayant omis de prendre en compte la généralisation/spécialisation. C’est encore comme si on prétendait intégrer dans les MCD de Merise le concept de table :



Et pire, les concepts de clé étrangère, de schéma de rattachement des tables, de trigger, etc. :

[CinePhil]

@encours : Tu n'as pas suivi le lien que j'ai donné dans mon précédent message !
Je parlais des règles de gestion des données telles que je les présente dans mon blog, pas du processus.

Attention, le Modèle Entité-Relation a été concocté par Chen et se situe au niveau conceptuel, MCD, alors que MySQL Workbench est au niveau MLD (voire MPD si on veut pinailler, puisqu’on y parle des index). Du reste, les diagrammes produits avec Workbench ne sont pas du type entity-relationship, mais prétendument « enhanced entity-relationship » (EER), nuance !

Ça fait un bout de temps que je n'ai plus fait de schémas de BDD alors je citais ce E/R de mémoire.

Pas de confusion dans ma tête. D'ailleurs, je faisais l'analogie du schéma EER de MySQL Workench avec le MLD Merisien ou l'on retrouve des tables contenant des clés étrangères, même si le EER de MySQL Workbench est plus complet puisqu'il inclut aussi les index.

[encours]

voila une proposition :



mais je pense que l'astuce d'une classe role est plus adapté que deux classes similaires operateur et admin
que pensez vous ?

et concernant les regles de gestions : je pense que ce que j'ai ecrit est une description du processus et regles de gestion en meme temps :
par exemple : un utilisateur peut effectuer plusieurs commandes : c'est une regle de gestion.....

[fsmrel]

le EER de MySQL Workbench est plus complet puisqu'il inclut aussi les index.

Dont acte, l'outil n'est même pas du niveau MLD mais MPD...

[encours]

voila la derniere version que j'ai realisé
NB : la relation entre message et personne c'est pour que le message est vers un ou plusieurs personnes
sauf que j'aimerai savoir votre idée sur la table admin et operateur (je craint d'avoir des reproches sur ces deux tables avec les memes attributs)
et si vous avez d'autres commentaires ou conseils :

[DaizDev]

Bonjour,

Ton modèle est correct mais as-tu envisagé les cas particuliers ou les évolutions possibles de ton applicatif ?

J'ai donc deux questions :

• Le grade d'un employé peut-il donner plus de droits ?
• Est-il possible que d'autres attributs puissent être ajoutés aux différents profils utilisateurs ?

Dans le cas des droits, créer une table Roles et une table Droits est possible telles que :

• Un utilisateur possède 1 ou plusieurs rôles
• un rôle définit différents droits

Ce qui ressemble à de l'ACL.

Dans le cas des attributs, créer une table Attributs et une table ValeurAttribut, telles que:

• Un attribut a une légende (comme champ)
• Une valeur d'attribut est rattachée à un attribut
• Une valeur est rattaché à un utilisateur

Tu pourras donc facilement ajouter à l'avenir un attribut quelconque à un utilisateur quelque soit ses droits.

Sinon tu peux rattaché l'attribut à un rôle si tu ne veux pas gérer l'affectation d'un attribut par programmation et donc reprendre la liste précédente, telle que :

• Un attribut a une légende (comme champ)
• Un attribut est affecté à un rôle
• Une valeur d'attribut est rattachée à un attribut
• Une valeur est rattachée à un utilisateur

Je parle en connaissance de cause, "notre" hiérarchie ne nous présente jamais les exceptions dans leurs projets mais "nous" reproche souvent de ne pas l'avoir fait Elle aurait tort de s'en priver