IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Schéma Discussion :

Gestion des clients


Sujet :

Schéma

  1. #1
    Nouveau Candidat au Club
    Homme Profil pro
    Étudiant
    Inscrit en
    Janvier 2018
    Messages
    6
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 28
    Localisation : Pologne

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Janvier 2018
    Messages : 6
    Points : 1
    Points
    1
    Par défaut 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:
    Nom : question.jpg
Affichages : 3476
Taille : 51,3 Ko

    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.

  2. #2
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    Mars 2010
    Messages
    10 087
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : Mars 2010
    Messages : 10 087
    Points : 38 380
    Points
    38 380
    Billets dans le blog
    9
    Par défaut
    Bonjour,

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

    Citation Envoyé par wojciech Voir le message
    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 Voir le message
    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
    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é

  3. #3
    Nouveau Candidat au Club
    Homme Profil pro
    Étudiant
    Inscrit en
    Janvier 2018
    Messages
    6
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 28
    Localisation : Pologne

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Janvier 2018
    Messages : 6
    Points : 1
    Points
    1
    Par défaut
    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:
    Nom : question2.jpg
Affichages : 2508
Taille : 83,8 Ko

  4. #4
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    Mars 2010
    Messages
    10 087
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : Mars 2010
    Messages : 10 087
    Points : 38 380
    Points
    38 380
    Billets dans le blog
    9
    Par défaut
    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

  5. #5
    Nouveau Candidat au Club
    Homme Profil pro
    Étudiant
    Inscrit en
    Janvier 2018
    Messages
    6
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 28
    Localisation : Pologne

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Janvier 2018
    Messages : 6
    Points : 1
    Points
    1
    Par défaut
    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:
    Nom : Capture3.PNG
Affichages : 4004
Taille : 76,2 Ko

    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?

  6. #6
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    Mars 2010
    Messages
    10 087
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : Mars 2010
    Messages : 10 087
    Points : 38 380
    Points
    38 380
    Billets dans le blog
    9
    Par défaut
    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
    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

  7. #7
    Nouveau Candidat au Club
    Homme Profil pro
    Étudiant
    Inscrit en
    Janvier 2018
    Messages
    6
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 28
    Localisation : Pologne

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Janvier 2018
    Messages : 6
    Points : 1
    Points
    1
    Par défaut
    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?

  8. #8
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    Mars 2010
    Messages
    10 087
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : Mars 2010
    Messages : 10 087
    Points : 38 380
    Points
    38 380
    Billets dans le blog
    9
    Par défaut
    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 )

  9. #9
    Nouveau Candidat au Club
    Homme Profil pro
    Étudiant
    Inscrit en
    Janvier 2018
    Messages
    6
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 28
    Localisation : Pologne

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Janvier 2018
    Messages : 6
    Points : 1
    Points
    1
    Par défaut
    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):
    Nom : question4.jpg
Affichages : 2455
Taille : 91,3 Ko

    Merci pour votre patience.

  10. #10
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    Mars 2010
    Messages
    10 087
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : Mars 2010
    Messages : 10 087
    Points : 38 380
    Points
    38 380
    Billets dans le blog
    9
    Par défaut
    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

  11. #11
    Nouveau Candidat au Club
    Homme Profil pro
    Étudiant
    Inscrit en
    Janvier 2018
    Messages
    6
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 28
    Localisation : Pologne

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Janvier 2018
    Messages : 6
    Points : 1
    Points
    1
    Par défaut
    Bonsoir,

    Citation Envoyé par escartefigue Voir le message
    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.

Discussions similaires

  1. Gestion des clients d'une entreprise
    Par losing it dans le forum Débuter
    Réponses: 2
    Dernier message: 15/12/2015, 14h04
  2. [Entité-Association] Gestion des clients d'un magasin
    Par simon59000 dans le forum Schéma
    Réponses: 1
    Dernier message: 07/11/2012, 15h48
  3. Problème pour la gestion des clients
    Par AddicTion dans le forum Réseau
    Réponses: 7
    Dernier message: 28/06/2011, 19h05
  4. Réponses: 4
    Dernier message: 11/01/2008, 10h16
  5. [MCD] gestion des clients taxiphone
    Par poula dans le forum Schéma
    Réponses: 5
    Dernier message: 21/01/2007, 20h38

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo