Gestion des clients

Bonsoir,
Je suis débutant en Merise. J'essaie de modéliser le problème suivant*:
Un restaurant est composé de trois salles.
Les clients du restaurant sont caractérisés par les attributs suivants*: le nom, prénom age, fumeur ou non. On peut classer tous les clients en trois catégories*: enfant, adulte fumeur et adulte
non fumeur.

Les contraintes sont*:

• Un fumeur ne se retrouve pas dans la même salle qu’un non fumeur et encore moins autour de la même table.
• Les adultes ne doivent pas se retrouver dans la même salle que les enfants.
• Deux personnes ne s’appréciant pas ne doivent pas également être autour de la même table.

Voici mon schéma pour commencer:
Pièce jointe 345334

Les entités enfants et adultes héritent du entité client (héritage avec partition). Le fumeur héritent du adulte.
J'ai crée des contraintes d’exclusivité entre les trois associations car une salle ne peut pas accueillir à la fois un enfant , un fumeur et non fumeur.
J'ai crée aussi une contraint d’inclusion entre association réflexive Apprécier est l'association S'asseoir pour exprimé que deux personnes
assis à une table s’apprécient.
Dites moi s'il vous plaît si je suis sur une bonne piste.

Bonjour,

N'avez vous pas besoin des informations du restaurant ? vous ne l'avez pas modélisé

Citation:

---

Envoyé par wojciech

Les clients du restaurant sont caractérisés par les attributs suivants*: le nom, prénom age, fumeur ou non. On peut classer tous les clients en trois catégories*: enfant, adulte fumeur et adulte
non fumeur.

---

D'une façon générale, il ne faut pas stocker de donnée calculée. L'âge est une donnée calculée à partir de la date de naissance, le stocker implique de le reconsidérer tous les jours pour vérifier s'il est toujours juste. Aucun intérêt donc.
De plus vous utilisez un héritage adulte/enfant qui risque d'être en désaccord avec cet âge...
Pourquoi cet héritage d'ailleurs, dans votre cas ça n'a pas d'intérêt : vous n'avez aucun attribut spécifique, la répartition est instable et c'est une redondance avec la date de naissance.
Si toutefois vous voulez utiliser des héritages, les sous-types ne doivent pas avoir d'identifiant : leur identifiant est celui hérité du sur-type

Citation:

---

Envoyé par wojciech

Les contraintes sont*:

• Un fumeur ne se retrouve pas dans la même salle qu’un non fumeur et encore moins autour de la même table.
• Les adultes ne doivent pas se retrouver dans la même salle que les enfants.
• Deux personnes ne s’appréciant pas ne doivent pas également être autour de la même table.

---

Pour le 1er point admettons, mais ce serait plus logique que les fumeurs et les non fumeurs soient surtout dans des salles différentes ;)
Pour le 2ème, ça va faire tous les parents qui préfèrent garder un œil sur leur progéniture
Pour le 3ème, c'est ingérable comment voulez vous connaitre et stocker cette notion !
A chaque fois qu'un client appelle pour réserver, vous devriez appeler tous les autres clients qui ont déjà réservé à la même table pour savoir s'ils acceptent de déjeuner avec lui :aie:
Ca n'a pas de sens et c'est probablement illégal (à voir avec l'équivalent de la CNIL en Pologne)

Il manque un attribut "nombre de places" dans l'entité-type table pour en connaitre la capacité

Bonsoir,
Merci pour votre réponse.
J’abandonne alors le héritage et les clients qui s'apprécient ou pas (cela ne passe pas, même en Pologne ;)).

En regardent de près les deux contraints je peut constaté que chaque type de client (enfant, adulte, adulte fumeur) doit être placer
dons une salle différant (ce ne que une exercices pas forcement proche de réalité).
Le problème c'est que je ne sais pas comment associer une type de client avec sa salle respective.
Je pense que il faut ajouter des attributs supplémentaires dans l’Entité Client_Type. Si oui je ne sais pas lesquels car la date de naissance et fumeur ou no
sont déjà utiliser dans l’Entité Client.

Voici mon modèle:
Pièce jointe 345705

Bonjour,

Si vous ne gérez qu'un et un seul restaurant, le sous-ensemble restaurant / salle peut convenir plus ou moins en l'état

Si vous avez plusieurs restaurants, il est préférable d'identifier la salle relativement au restaurant. C'est à dire que la PK de la salle sera constituée de la FK identifiant restaurant + de la PK identifiant salle.
Graphiquement, cela se matérialise par des parenthèses autour des cardinalités coté salle :
RESTAURANT 1,n --- contenir --- (1,1) SALLE

Qu'il y ait un ou plusieurs restaurants, il est préférable d'externaliser la ou les adresses, un restaurant peut avoir une adresse de livraison différente de celle de facturation par exemple
Chaque adresse peut donc avoir un type adresse, quitte à avoir un type général "tout usage" si besoin
Là aussi l'identification relative est judicieuse.
Ce qui donne
RESTAURANT 0,n --- adresser --- (1,1)ADRESSE 1,1 --- typer --- 0,n TYPE_ADRESSE

Le type de client ne semble pas présenter d'intérêt, puisque vous gérez la notion de fumeur via un booléen, et que la notion adulte/enfant se déduit de la date de naissance

La relation "accueillir" entre SALLE et CLIENT pose deux problèmes :
- en l'état, un client ne peut venir qu'une fois dans une même salle, il manque donc la notion de date, voire même d'heure si le client souhaite déjeuner et diner le même jour ;)
- le client réserve plus probablement une table (par exemple pour 4 personnes) qu'une salle, d'un point de vue traitement, il faudra bien sur vérifier que la table correspond à une salle de la qualité requise (fumeur ou non) mais au niveau MCD il me semble que c'est bien la table qui est en relation avec le client et non la salle

La relation "s'asseoir" entre table et client présente la même erreur que "acceuillir" : un client ne peut venir qu'une et une seule fois à une table :aie:

Bonsoir,
Je vous remercie infiniment pour votre aide. J'ai gaspillée inutilement mon temps en me concentrant
sur le type de client qui était en effet sans aucun intérêt.

Voici ma troisième version du schéma:
Pièce jointe 346060

J'ai appliqué votre consigne:

• J'ai ajouté des identifications relatives,
• j'ai externalisé les adresses du restaurant,
• j'ai ajoutée aussi l’entité Data et deux dépendances fonctionnelles. Maintenant un client peut être accueillir
  dans une seul salle et peut occuper une place à table à des dates différentes.

Est-ce que c'est bon?

C'est mieux, mais

Je ne suis pas certain du bien-fondé de la relation entre client et salle.
Si les clients ne réservent que des places ou des tables elle est sans intérêt, mais peut être certains clients réservent ils des salles (ex : pour une réunion d'entreprise ou un mariage)
A préciser

Attention, vous avez laissé un attribut adresse dans le restaurant, bien que vous ayez créé l'ET adresse
Attention aussi à l'identifiant PK fonctionnel du restaurant, c'est dangereux si vous avez beaucoup de restaurants les risques de doublons sont certains, sans parler des changements d'enseigne et les effets délétères sur les contraintes et les problèmes de perfs. Un id technique de type integer serait préférable.
Idem pour l'identifiant du type adresse ;)

Qu'avez vous voulu matérialiser avec vos CIF ? les CIF doivent concerner deux relations or là vous joignez des ET :weird:
De plus il faut indiquer le type de CIF dans le cercle (inclusion, partition, exclusion)

EDIT : un autre point dont j'ai oublié de parler : vous ne faites pas mention des "réservations". Sans doute un manque pour une gestion de restaurants ;)

Bonjour,

Sans CIF, si je bien compris un client peut être accueillir dans plusieurs salles à des dates différentes,
mais selon les règles de gestion un fumeur ne peut être accueillir que dans une seule salle – la salle des fumeur.
Il ne peut pas se retrouver avec des enfants ou des adultes non fumeur.
Comment est-il possible de modéliser cette contrainte?

Pour vérifier qu'un client fumeur réserve dans une salle fumeur, il faut tout d'abord ajouter un attribut fumeur O/N à l'entité salle, puis vérifier à mon avis par traitement et non par contrainte que la salle correspond au besoin du client "pour cette réservation". Ce que je veux dire, c'est qu'un même client fumeur, peut très bien venir le lundi, seul, et souhaiter pouvoir fumer pendant son repas, puis revenir le mardi, accompagné de non fumeurs qui ne souhaitent pas être gênés par la fumée.

Du coup ce client va réserver une table le lundi en salle fumeur puis une table le mardi en salle non fumeur.

Auquel cas la nécessité de modéliser une entité-type "réservation" dont j'ai parlé plus haut, devient indispensable : on ne s'intéresse plus à la qualité fumeur/non fumeur du client, mais bien à celle de la réservation (qui doit bien sur prévoir cet attribut)
Ça me semble plus conforme à la réalité (sous réserve bien sur que la salle fumeur soit légale, ce qui n'est plus le cas en France depuis déjà longtemps ;))

Disons que dons ce cas exceptionnel on a trois salles une pour enfant, une pour des adultes fumeur,
et troisième pour des adultes non fumeur.

Effectivement ll n'est pas bête que un client fumeur peut venir accompagné de non fumeurs qui ne souhaitent pas être gênés par la fumée
et du coup réserver une table le lundi en salle fumeur puis une table le mardi en salle non fumeur.
De même pour des parents que veulent gardé un œil sur leur enfants. Je vais garder ça en tête pour mon prochaine étape.

Je débute en modélisation donc je voudrais commencer par des choses simples.
Supposant donc que dans mon monde un client en faisant une réservation pour une seul place lundi puis vendredi par exemple,
est placer dans une de trois salle en fonction de «est-ce que il fume ou non ou» et «est-ce qui il est adulte ou enfant».

J'aurai sans doute besoin d'un entité «Réservation» et si je bien compris c'est la ou il faut géré des qualité comme «la date de naissance» et «fumeur ou non» et pas dans entité client? Puis je utilise les même attribut pour l'entité «Salle» ?

Comment vérifie par traitement et non par contrainte que la salle correspond au besoin du client "pour cette réservation"?

Voici la partie problématique du schéma(on oublie des tables pour l'instant):
Pièce jointe 346155

Merci pour votre patience.

Voici un exemple simplifié, qui ne prend pas en compte le calendrier d'ouverture des différents restaurants.

C'esti réalisé avec DB-Main, du coup l'identification relative n'appairait pas sous forme de parenthèse mais apparait en bas de chaque entité-type dans la partie identifiant
On voit par exemple que l'ET table est identifiée relativement à l'ET salle, la salle étant elle même identifiée relativement à l'ET restaurant
Du coup, le MLD résultant aura 3 identifiants pour la table "TB_table" : RT_id+SL_id+TB_id

L'entité-type média permet d'avoir des n° de téléphone et/ou de courriel pour contacter le client

Dans l'ET réservation, outre la date de réservation et la date du repas, on trouve également l'indicateur AM/PM pour repas du midi ou du soir (un horaire prévisionnel serait certainement plus utile mais bon ;)), le nombre d'adultes, d'enfants, la présence ou non de personne handicapée (afin d'éviter les étages par exemple), une zone de commentaires
J'ai oublié de mettre le booléen fumeur O/N. A ajouter bien sur ;)

La relation "affecter" en lien avec le calendrier, permet de s'assurer qu'une même table n'est pas réservée deux fois le même jour dans le même restaurant (puisque l'identifiant table, inclut l'identifiant restaurant via l'identification relative)
C'est une solution assez grossière dans la mesure où une table peut être servie plusieurs fois le même jour (le midi et le soir ou même deux fois le midi en début et en fin de service par exemple). A affiner donc.

Pièce jointe 346258

Bonsoir,

Citation:

---

Envoyé par escartefigue

Pour vérifier qu'un client fumeur réserve dans une salle fumeur, il faut tout d'abord ajouter un attribut fumeur O/N à l'entité salle, puis vérifier à mon avis par traitement et non par contrainte que la salle correspond au besoin du client "pour cette réservation".

---

Je crois comprendre mon problème. J'ai confondu le Modèle conceptuel de données avec un Modèle de traitement. J'ai tenté à tout prix de représenter sur mon schéma MCD des contraintes qui ne peuvent être vérifiés que pare traitement.

Encore un fois grand merci pour m'aide à comprendre mon erreur.
Bonne soirée.