Discussion :

[fulachan2]

Avant toutes choses, bonjour à tous.

Je suis débutant dans la méthode Merise et j'ai un projet pour une entreprise de nettoyage donc voici la demande:

Nous désirons un site pour gérer le nettoyage de nos clients. Nos clients possèdent des résidences de vacances contenant des appartements. Ses appartements sont nettoyé par des équipes de 2 personnes et contrôler par une personne prévu à cette tache. L'appartemment sale est "a faire" par l'équipe qui valide son travail une fois fini.L'appartement est "a vérifier" par un contrôleur qui décide si l'appartement est à refaire (un commentaire est donc renvoyé aux membres de l'équipe) ou OK (après 48h en état "OK", l'appartement repasse en etat "à faire").
L'entrepreneur peut, via une interface d'administration voir ce qui est à faire, à valider, OK, PAS OK.

Les types de personnes sont au nombre de 4:

• Aucun (afin de désactiver un compte en cas de perte de password).
• Nettoyeur (permet de valider son travail).
• Contrôleur (permet de faire la validation finale et envoyer un commentaire le cas échéant).
• Directeur (il possède les droits des nettoyeurs et des contrôleurs. Il peut créer: Client, Bâtiment, Appartement, Nettoyeur, Contrôleur, équipe et Assigner les nettoyeurs et un contrôleur à une équipe

Après avoir imaginé un table Rôle lié à la table Personne ("utilisateur" dans mon cas) contenant des booléens pour (je suis nettoyeur, je suis contrôleur,....), je me suis vite rendu compte que le MCD était trop vague pour faire la distinction entre un Directeur qui créer, nettoie, contrôle....et un contrôleur qui contrôle juste.

J'ai vu que dans mon cas, les héritages pouvait avoir un intérêt j'ai essayé pour la première fois ceci. J'ai opté pour une contrainte de totalité qui me permet d'avoir plusieurs rôles (Directeur, par exemple)...Je ne suis pas bien sur de moi à ce sujet.

Je vous remercie par avance pour votre aide.

[CinePhil]

Bonjour,

C'est pas mal pour un débutant de faire déjà des héritages !

1) Dans votre cas, l'héritage est une bonne idée puisqu'il y aura des associations différentes entre les nettoyeurs et les contrôleurs, notamment.

2) Lors d'un héritage, les tables filles héritent de l'identifiant de la table mère.
Il est donc inutile, dans le MCD, de mettre des id_control, id_dir, id_net et id_no_role.
Je ne pas bien l'utilité non plus des propriétés role_control, role_dir, role_net et no_role !

3) J'ai cru comprendre que les équipes sont composées de nettoyeurs.
L'association "composer" devrait alors être entre Equipe et Nettoyeur ; tous les utilisateurs ne pouvant pas entrer dans la composition d'équipes.

4) Selon votre MCD, un contrôleur ne peut rédiger qu'un seul commentaire et un commentaire peut être rédigé par plusieurs contrôleurs !
Inversez vos cardinalités.

5) Selon votre MCD, un appartement n'est nettoyé qu'une seule fois !
Vous devriez avoir des cardinalités 0,n - 0,n sur l'association Nettoyer.

6) Selon votre MCD, quand le directeur crée quelque chose, c'est en même temps un appartement, un bâtiment et un propriétaire.
Et s'il y a plusieurs appartements dans le même bâtiment, on fait comment ?

Je ne suis pas sûr que l'association Créer soit nécessaire. Les droits sur les fonctionnalités de l'application peuvent être gérés au niveau de l'application lorsqu'ils restent simples.

Si vous avez plusieurs agences avec plusieurs directeurs, ou si vous avez un turnover au poste de directeur, OK, ça peut être pertinent d'enregistrer qui a créé un bâtiment, un appartement ou un propriétaire.

7) Je reviens sur un point de votre description :

Les types de personnes sont au nombre de 4:

Aucun (afin de désactiver un compte en cas de perte de password).

Vous avez mis une contrainte d'exclusion dans l'héritage. Cela signifie, par exemple, qu'un contrôleur ayant perdu son mot de passe deviendra un "Aucun". Le lien vers tous les messages qu'il aura postés sera alors perdu.

Plutôt qu'un rôle "Aucun", ajoutez simplement une propriétaire booléenne "valid_user" dans Utilisateur et tenez compte de cette colonne dans votre application.

8) Ne faudrait-il pas enregistrer d'autres choses ?
Par exemple :
- les dates de nettoyage et d'éventuels re-nettoyages ;
- les dates de contrôle et d'éventuels re-contrôles.

[fulachan2]

Bonjour Cinephil pour votre réponse complète et rapide.

2) Lors d'un héritage, les tables filles héritent de l'identifiant de la table mère.
Il est donc inutile, dans le MCD, de mettre des id_control, id_dir, id_net et id_no_role.
Je ne pas bien l'utilité non plus des propriétés role_control, role_dir, role_net et no_role !

Entendu pour les ID, concernant les propriétés role_control, role_dir, role_net et no_role, ce sont des booléen.
L'idée est de faire des fonctions exemple: is_director(); qui modifie les booléen en fonction du role voulu. Au départ, je les avait mis directement dans l'entité utilisateur mais cela ne permettait pas de définir clairement le type d'utilisateur pour concevoir mes tables relationnelles.

3) J'ai cru comprendre que les équipes sont composées de nettoyeurs.
L'association "composer" devrait alors être entre Équipe et Nettoyeur ; tous les utilisateurs ne pouvant pas entrer dans la composition d'équipes.

J'ai relié utilisateur à équipe car les directeurs ont les droits des nettoyeurs quand aux contrôleurs, c'est une question que je n'ai pas posé et que je me pose aussi (en attente) car il est fort probable qu'il soit amené à faire du nettoyage. Le contrôleur étant un nettoyeur formé pour contrôler. Dans ce cas, seul l'entité fille "sans rôle" pourrait faire défaut mais est ce vraiment un problème?

NOTE: A ce sujet, un collège à moi qui utilise UML et ne connais pas Merise et moi c'est l'inverse, dur dur....m'a fait un MLD sans héritage dans lequel il a créé une entité role contenant une propriété pouvoir (je suppose qu'il s'agit de booléen) et relié à l'utilisateur.Dans ce cas, c'est mon code qui déterminera qui fait quoi.

4) Selon votre MCD, un contrôleur ne peut rédiger qu'un seul commentaire et un commentaire peut être rédigé par plusieurs contrôleurs !
Inversez vos cardinalités.

Désolé, la fatigue surement

5) Selon votre MCD, un appartement n'est nettoyé qu'une seule fois !
Vous devriez avoir des cardinalités 0,n - 0,n sur l'association Nettoyer.

La j'ai une question (basé sur mon résonnement...qui n'est peut être pas le bon d'ailleurs) car avec du 0,n - 0,n, cela va créer une table associative qui va me permettre d'attribué:
aucune ou plusieurs équipes pour aucun ou plusieurs appartements.
Hors, autant 1 équipe peut nettoyer plusieurs appartements.
Mais 1 appartement ne peut pas être nettoyer par plusieurs équipe car le commentaire en cas de travail mal fait est destiné qu'à une seule équipe.

Les appartements étant unique (du moins si on considère qu'ils sont dans un bâtiment donnée et appartenant à un propriétaire précis), si l'"id_equipe" devient une clé étrangère de Appartement, je pourrais dire:

App.1202, equipe1, App.15, equipe 1,App.27, equipe 1, etc...
MAIS
App.45, equipe2
et ce avec du 0,n - 1,1 ....ou plutôt car un appartement n'est pas forcement nettoyé, du 0,n - 0,1 ? ou je dis une connerie?

6) Selon votre MCD, quand le directeur crée quelque chose, c'est en même temps un appartement, un bâtiment et un propriétaire.
Et s'il y a plusieurs appartements dans le même bâtiment, on fait comment ?

Oui effectivement, je comprends votre raisonnement très intéressant. Malgré le fait que j'ai mis du 0,n....cela n'obligera pas le client à créer les 3 en même temps. Par contre en regardant le MCD, je pense vaguement à un CIF (un truc comme ça) qui oblige la base de donnée à avoir un propriétaire et un batiment pour avoir des apparts car des apparts sans bâtiments c'est dur cela dit cela peut se faire dans mon code.

Si vous avez plusieurs agences avec plusieurs directeurs, ou si vous avez un turnover au poste de directeur, OK, ça peut être pertinent d'enregistrer qui a créé un bâtiment, un appartement ou un propriétaire.

C'est très clair je retire.

Vous avez mis une contrainte d'exclusion dans l'héritage. Cela signifie, par exemple, qu'un contrôleur ayant perdu son mot de passe deviendra un "Aucun". Le lien vers tous les messages qu'il aura postés sera alors perdu.
Plutôt qu'un rôle "Aucun", ajoutez simplement une propriétaire booléenne "valid_user" dans Utilisateur et tenez compte de cette colonne dans votre application.

Oui bonne idée, j'ai pris ceci car dans un projet précédent, j'avais créer une table associative entre les roles et un compte de connexion, plus d'entrée dans cette table et le compte était inactif...donc j'étais partie sur la même idée mais n'avait pas pensé à la suppression des commentaires. Et au travers ce que vous dites, finalement, les booléens dans mon entité "Utilisateurs" ne serait pas une si mauvaise idée alors?


8) Ne faudrait-il pas enregistrer d'autres choses ?

Par exemple :
- les dates de nettoyage et d'éventuels re-nettoyages ;
- les dates de contrôle et d'éventuels re-contrôles.

Sur ceci, l'utilisateur final veut un archivage de 48h. c'est son choix.
J'ai donc juste intégré l'heure de fin de nettoyage de l'appartement (h_fin_net_app) dans l'entité Appartement, histoire de pouvoir faire mon calcul....48 heures après.
Concernant le scénario, c'est:

• appartement sale (PAS FAIT - Numéro 1)
• appartement nettoyé pas validé par le contrôleur (EN ATTENTE DE VALIDATION - Numéro 2)

Ensuite, 2 possibilités:

• appartement validé (OK - Numéro 3)
• appartement non validé (PAS OK - Numéro 4)

Cela a été intégré dans l'entité "Utilisateurs".


Par contre, je me pose une question est ce qu'une table "Contrôler" entre équipe et contrôleur ne serait pas la bienvenue?
Et une table créer entre directeur et équipe ou est ce superflu?



Sur vos conseils et histoire d'avoir un aperçu j'ai recréé mon MCD. J'ai juste gardé:
ma table "composer" car entre temps, l'utilisateur final m'a dit "1 controleur pour plusieurs équipes et 1 directeur peut (en cas de force majeur) nettoyer ou contrôler...donc reste plus que le aucun qui dégage et ca donne ...déja un autre grand merci et...

[CinePhil]

concernant les propriétés role_control, role_dir, role_net et no_role, ce sont des booléen.
L'idée est de faire des fonctions exemple: is_director(); qui modifie les booléen en fonction du role voulu. Au départ, je les avait mis directement dans l'entité utilisateur mais cela ne permettait pas de définir clairement le type d'utilisateur pour concevoir mes tables relationnelles.

Je ne vois toujours pas l'utilité de la propriété dans la base de données !
Un idUtilisateur qui sera aussi, par héritage, dans la table des directeurs signifiera naturellement que isDirector = TRUE.
Autrement dit, tous les utilisateurs qui, par héritage, se retrouveront dans la table des directeurs, par définition, seront des directeurs. Il est inutile d'enregistrer en plus une propriété spécifiant s'ils sont directeurs ou non.

J'ai relié utilisateur à équipe car les directeurs ont les droits des nettoyeurs quand aux contrôleurs

Ne pas confondre la modélisation des données propres aux utilisateurs, aux nettoyeurs, aux contrôleurs... et leurs rôles dans l'application.

Votre schéma autorise l'enregistrement d'un utilisateur de type directeur dans une équipe. Si c'est impossible alors votre schéma est faux.

c'est une question que je n'ai pas posé et que je me pose aussi (en attente) car il est fort probable qu'il soit amené à faire du nettoyage. Le contrôleur étant un nettoyeur formé pour contrôler.

Alors il ne faut pas d'exclusion dans votre héritage. Un utilisateur peut être à la fois un nettoyeur et un contrôleur.
Je constate d'ailleurs que vous avez remplacé l'exclusion par la totalité.

Dans ce cas, seul l'entité fille "sans rôle" pourrait faire défaut mais est ce vraiment un problème?

Je ne comprends pas vraiment votre phrase mais, encore une fois, je ne vois pas trop l'utilité de cette entité type.

NOTE: A ce sujet, un collège à moi qui utilise UML et ne connais pas Merise et moi c'est l'inverse, dur dur....m'a fait un MLD sans héritage dans lequel il a créé une entité role contenant une propriété pouvoir (je suppose qu'il s'agit de booléen) et relié à l'utilisateur.Dans ce cas, c'est mon code qui déterminera qui fait quoi.

Je suppose qu'il a fait un truc de ce genre :
utilisateur -*---------1..1- role

Mais du coup, rien n'interdit d'enregistrer dans la base de données un contrôle effectué par un utilisateur n'ayant pas le rôle de contrôleur ou bien, encore une fois, d'enregistrer un directeur comme faisant partie d'une équipe.
C'est aussi pour ça que je préfère Merise à UML pour concevoir les bases de données parce que ça laisse moins de place aux erreurs involontaires.

La j'ai une question (basé sur mon résonnement...qui n'est peut être pas le bon d'ailleurs) car avec du 0,n - 0,n, cela va créer une table associative qui va me permettre d'attribué:
aucune ou plusieurs équipes pour aucun ou plusieurs appartements.
Hors, autant 1 équipe peut nettoyer plusieurs appartements.
Mais 1 appartement ne peut pas être nettoyer par plusieurs équipe car le commentaire en cas de travail mal fait est destiné qu'à une seule équipe.

C'est là que mes dernières remarques prennent tout leur sens au sujet des dates de nettoyage et de contrôle.
À une date donnée, un appartement ne peut être nettoyé que par une équipe. La table associative contiendra donc la propriété date de nettoyage, laquelle fera aussi partie de la clé primaire.
On peut aussi considérer une entité type nettoyage :
Equipe -0,n----effectuer----1,1- Nettoyage -1,1----concerner----0,n- Appartement

Table Nettoyage (idNettoyage, idEquipe, idAppartement, dateHeureNettoyage)

On peut faire la même chose pour les contrôles. Un appartement qui aura été contrôlé négativement devra être recontrôlé après un nouveau nettoyage.
Controleur -0,n----effectuer----1,1- Controle -1,1----concerner----0,n- Nettoyage

Table Controle (idControle, idNettoyage, idControleur, resultat)

Oui effectivement, je comprends votre raisonnement très intéressant. Malgré le fait que j'ai mis du 0,n....cela n'obligera pas le client à créer les 3 en même temps. Par contre en regardant le MCD, je pense vaguement à un CIF (un truc comme ça) qui oblige la base de donnée à avoir un propriétaire et un batiment pour avoir des apparts car des apparts sans bâtiments c'est dur cela dit cela peut se faire dans mon code.

Un appartement ne peut pas exister sans bâtiment puisque :
Appartement -1,1----Contenir----1,n- Bâtiment

Pour la même raison, un bâtiment ne peut pas exister sans propriétaire.
Ce qui m'étonne un peu, c'est que tous les appartement d'un bâtiment appartiennent au même propriétaire car il existe des co-propriétés mais peut-être que dans votre contexte, c'est réellement comme ça.

l'utilisateur final m'a dit "1 controleur pour plusieurs équipes et 1 directeur peut (en cas de force majeur) nettoyer ou contrôler...donc reste plus que le aucun qui dégage

OK, je répondais en lisant donc ça répond à ce j'ai écrit un peu plus haut.

Par contre, sur votre MCD, un commentaire est rédigé par un contrôleur et un directeur. Dans une association ternaire, les pattes ne sont pas optionnelles.

En fait, un contrôleur peut-être accidentellement un nettoyeur. Un directeur peut être accidentellement nettoyeur ou contrôleur.

Je pense qu'il faut en rester à la sémantique :
- Une équipe est composée de 2 nettoyeurs, même si cette équipe peut comprendre un directeur ou un contrôleur.
- Un commentaire est rédigé par un contrôleur, même si ce contrôleur peut être le directeur.

Du coup, tout utilisateur peut composer une équipe et seuls ceux qui ont au moins le grade de contrôleur peuvent contrôler et rédiger les commentaires.
Utilisateur -0,1----Composer----2,2- Equipe
Controleur -0,n----Rediger----1,1- Commentaire

=> Le directeur devra faire partie de l'entité fille Controleur.
=> Du coup, l'entité fille nettoyeur n'est reliée à rien donc ne sert à rien et peut être éliminée.
=> Idem pour l'entité Directeur.

En effet, ce qui importe dans votre système est de savoir qui nettoie et qui contrôle or tout le monde peut nettoyer mais seuls ceux habilités à contrôler peuvent contrôler.
=> Seul l'héritage de Utilisateur vers Contrôleur est nécessaire dans votre schéma.

Nota : Si vous adoptez le schéma que j'ai fait plus haut au sujet des contrôles, cela remet un peu en cause la partie commentaire de votre schéma car le commentaire s'attache à un contrôle. Je vous invite à réfléchir à ça.