Discussion :

[pr0methee]

Bonjour,

Débutant en merise, j'essaie de représenter la gestion de menu par des restaurants. Pour cela j'ai effectué un premier schéma via umLet

A dispo pour le restaurant :

- Base pré remplie de services (petit déj, repas de midi) avec possibilité d'en ajouter des propres à soi
- Base pré remplie de catégories ( entrée, plat, dessert...) avec possibilité d'en ajouter des propres à soi
- Base publique de plat avec possibilité d'en ajouter des propres à soi
- La possibilité de sauvegarder le menu créer pour être re utilisé

Processus :
- le restaurant pré définis des services (en spécifiant l'horaire de son service) et le structure avec les catégories de son choix.
- le restaurant compose son menu en associant des plats aux catégories correspondantes du service sélectionné

Suis je sur la bonne voie ?

Merci de vos retours

[pr0methee]

Il est vrai que ce mcd manque de lisibilité

je posterais ce soir une version plus lisible avec l'ensemble des règles associées

[Gannox]

Bonjour,

Avec seulement quelques courtes phrases sur le fonctionnement de ton SI, on va avoir du mal à te dire si ton MCD est juste/faux/complet/incomplet

Quelques points pour commencer :

1) Pas vraiment obligatoire selon moi mais tu pourrais externaliser en entités de référence toutes les propriétés "ville" de ton MCD avec à l'intérieur VILLE(id, libelle) car il se peut que la plupart des clients habitent la même ville donc cela peut revenir plusieurs fois.

2) Je ne comprends pas l'intérêt de l'association entre CATEGORIE et RESTAURANT. La catégorie s'applique au service et ce service appartient au restaurant donc y a-t-il un lien entre les deux d'après ton projet ?

3) Qu'est-ce qui différencie USER et CLIENT précisément ?

4) Si je ne me trompe pas, il est écrit d'après les cardinalités qu'un service peut ne pas contenir de menu (il sert à quoi alors le service ) et un menu peut ne pas contenir de plat (va pas venir deux fois le client alors )

5) Le prix d'un plat devrait se trouver directement dans l'entité PLAT. Mais si selon tes règles de gestion, il est écrit comme quoi par exemple qu'un même plat, selon le menu auquel il appartient, a une composition différente mais possède toujours le même nom de plat, dans ce cas je n'ai rien dis

Voilà voilà.

[CinePhil]

Il y a eu un sujet similaire il y a quelques semaines qui pourrait te donner des pistes.

[pr0methee]

1) Pas vraiment obligatoire selon moi mais tu pourrais externaliser en entités de référence toutes les propriétés "ville" de ton MCD avec à l'intérieur VILLE(id, libelle) car il se peut que la plupart des clients habitent la même ville donc cela peut revenir plusieurs fois.

Modification effectuée
Dans cette même logique on peut externaliser le code postal si on considère que beaucoup de clients feront parti du même ? En fait à partir de combien d'occurence y a t il un réel intérêts à externaliser en entité de références ?

2) Je ne comprends pas l'intérêt de l'association entre CATEGORIE et RESTAURANT. La catégorie s'applique au service et ce service appartient au restaurant donc y a-t-il un lien entre les deux d'après ton projet ?

Je tentais de représenter que catégorie était pré remplie de données par défaut (entrée plat, dessert) visible par tous les restaurants et qu'un restaurant pouvait en ajouter. Mais ces ajouts serait d'ordre privée et visible que par le dit restaurant. Ce n'est peut être pas la bonne représentation, mais dans ce cas comment dissocier dans ma table categorie, que l'une est publique, l'autre est privée. A moins qu'il soit obligatoire de créer deux tables, une entité référence de catégorie, une entité de catégorie prope au restaurant ?

En outre un service, le serivce de 12h00-- 13h00 peut être constitué de 0,n catégorie (quelle soit publique ou privée)

3) Qu'est-ce qui différencie USER et CLIENT précisément ?

Une chaine de restaurant défini un administrateur général, cet admin désigne des responsables par secteur en gros

4) Si je ne me trompe pas, il est écrit d'après les cardinalités qu'un service peut ne pas contenir de menu (il sert à quoi alors le service*) et un menu peut ne pas contenir de plat (va pas venir deux fois le client alors*)

C'était dans la logique que les services sont pré définies avant la création d'un menu, donc au niveau applicatif, on a l'étape définir des services qui seront dans la majorité des cas définis une seule fois car ils resteront identique sur de longues périodes, chaque jour le restaurant fera son service du midi de telle à telle heure jusqu'à nouvel ordre et dissocier, on a l'étape sélectionner un service pré défini contenant déjà 0,N catégories (prédéfini avant dans la même logique que service ), et y composer un menu. Donc un ensemble service/categorie peut exister avant même qu'un menu est été composé. Un menu étant l'association de ce couple service/categorie, avec des plats à un jour ou période donné.

Précision, je ne dis pas que ma logique est la bonne, je tente juste de l'expliciter

Pour menu et plat, effectivement un menu n'existe pas sans plat

5) Le prix d'un plat devrait se trouver directement dans l'entité PLAT. Mais si selon tes règles de gestion, il est écrit comme quoi par exemple qu'un même plat, selon le menu auquel il appartient, a une composition différente mais possède toujours le même nom de plat, dans ce cas je n'ai rien dis*

C'est le même principe de plat publique/ plat privée
plat doit contenir une liste de plat pré définies
Le restarant peut ajouter un nom de plat mais il ne sera visible que par lui

Pour la dissociation nom/caracteristiques, j'essayais de trouver une façon de ne pas dupliquer le nom d'un plat x fois
Un saumon restant un saumon, parcontre les caractéristiques d'un plat comme son prix ou tout autre informations sont propres au restaurant

[pr0methee]

Entité

- un utilisateur qui gèrera des restaurants
- un restaurant qui associera des plats à des structures de menus prédéfinis ( service + 0 à n catégories )
- un service est défini par l'association d'un nom et un créneau horaire (petit déjeuner, repas de midi...)
- une catégorie est définie par un nom ( entrée, plat, dessert...)
- un plat est défini par un nom. Il peut se voir attribuer un ensemble d'informations complémentaires, qui seront propre au restaurant comme son nombre de calorie, un label bio, etc...
- un menu est défini par l'association d'un service contenant de 0 à n catégorie, de 1 à n plat et d'une période.

Disponible pour l'utilisateur (accessible pour chaque restaurant) :
Liste de nom de services publiques {nom} afin d'éviter que chaque restaurant est à saisir un service commun comme petit déjeuner
Liste de nom de catégories publiques { nom } -> même principe
Liste de nom de plats publiques {nom } -> même

premier interrogation : peut on associer dans une même table ces listes publiques avec des ajouts effectués par le restaurant qui ne seront visible que par lui, ou doit on dissocier en 2 entités distinctes une entité référence pour le publique, une entité classique pour le privée ?

Description du processus utilisateur:

1. L'utilisateur déclare un restaurant

2. Il pré défini des services en associant un nom de service à un créneau horaire.
Cette association nom service + créneau horaire lui enregistre un service.
Si le nom de service n'est pas déjà référencé, il peut en créer un, qui ne sera accessible que par ce restaurant. Ce nom privée n'est pas unique contrairement au nom publique, car un autre restaurant de son côté peut lui aussi vouloir utilisé ce même non. Mais en même temps il ne souhaite pas être "pollué" par les noms de services ajoutés par les autres restaurants
Pour chaque service il peut associer de 0 à N catégorie.
Si le nom de catégorie n'est pas disponible même principe que pour service

3.Dans une étape distincte :
Le restaurant peut désormais composer son menu :
il séléctionne une date ou une période
il sélectionne le service sur lequel il veut travailler
Il associe des plats :
directement au service, si celui ci ne comprends aucune catégorie
à chacune des catégories

Si un plat n'existe pas en liste publique, même principe que service

Règles :

Un restaurant défini de 0 à n services
Un service appartient à ? restaurant, le mcd initial semblait fonctionnait avec un service en 1,1
mais le 1,1 ne réponds pas à la règle qu'un service petit déjeuner 8h à 9h soit utilisé par plusieurs restaurants sans duplication

deuxième interrogation :
restaurant A peut définir un "petit déjeuner" (nom de service publique) de 8h à 9h
restaurant B peut définir un "petit déjeuner" (nom de service publique) de 7h à 8h
restaurant C peut définir un "petit déjeuner" (nom de service publique) de 8h à 9h
restaurant D peut définir un "spécial dejeuner" (nom de service privée) de 8h à 9h

Actuellement le nom du service et le créneau horaire sont stockés dans la même entité.
Dans ma logique cela entraine des duplications autant du nom de service que des créneaux horaires.

Je pensais séparer avec une entité T_R_PERIODE_TIME_PRD et une entité T_R_NOM_SERVICE_NSV. En outre je pensais pouvoir ainsi re utiliser cette table période pour dans le futur gérer d'autres évènements relatif à des périodes et éviter de me retrouver à nouveau avec une duplication de créneaux horaires dans une table evenements ou tout autre table nécessitant une notion de période. exemple mcd_PRD

T_R_CRENEAUX_HORAIRES_CRH est associé à 1,n T_R_NOM_SERVICE_NSV
(un créneaux horaires n'existe pas tant qu'un restaurant ne la pas utiliser une première fois)
T_R_CRENEAUX_HORAIRES_CRH est utilisable par n'importe quel restaurant

T_R_NOM_SERVICE_NSV est associé à 0,n T_R_CRENEAUX_HORAIRES_CRH ( un nom de service pouvant ne pas avor encore été utilisé par un restaurant)
T_R_NOM_SERVICE_NSV est utilisable par n'importe quel restaurant

T_E_RESTAURANT_RST peut ajouter 0,n nom de service privée (visible que par lui)
T_E_RESTAURANT_RST peut définir un service : sélectionner un nom de service publique ou privée, et saisir une période

T_J_ASSOCIER_ASC représentant au final le service ?

Mais est ce judicieux, conseillé, déconseillé comme "principe" et je dois admettre pêcher pour trouver la bonne modélisation car je me retrouve avec une association à 4 branches qui est déconseillé non ?

La suite de ce mcd découlant de ce point, je m'arrête là

J'ajouterais que j'ai essayé de suivre la normalisation que vous proposez. Parcontre je trouve peu intuitif la notation des associations, en fait je suis étonné qu'elle ne comporte pas le nom des 2 tables qu'elle joint. N'est il pas possible pour les associations de les nommer comme l'association entre RST et NSV ?

Je ne sais pas si j'en demande trop, si j'explicite comme il se doit, si je suis suffisament clair. Je reste ouvert à toute critique