Discussion :

[marui]

Bonjour,

il manque donc plusieurs types d'entité dans votre modèle :

• "client" et "membre" qui sont des sous-types de l'entité-type "contact" ;
• peut être également "table", car vous mentionnez que les membres ne sont pas affectés à une table particulière, ce qui laisse supposer qu'il en va différemment des clients ? à préciser.

je dois effectivement compléter les règles de gestion :
il y a 4 catégories de "Contacts" possédant un compte:

- 1 compte "Club" : ce compte permet de gérer les consommations non facturés(offertes mais qui affecteront quand même les stocks). Il est défini par son identifiant et son libellé ou nom(Club).

- 1 compte "Gestion" : Ce compte permet de gérer les clients "non-membre" qui souhaitent consommer en dehors d'une table (les clients sont anonymes et payent immédiatement).identifiant et nom(Gestion).

- N comptes "Table" : Ces comptes permettent de gérer les clients "non-membre" qui s'installent à une table (les clients sont anonymes et payent lorsqu'ils quittent la table). identifiant et n°table.

-N comptes "Membres" : Ces comptes permettent de gérer les membres. Les membres consomment "à crédit" sur un ou plusieurs jours (limite à définir). ils sont définis par plusieurs attributs (ID, nom, prénom, adresse, date de naissance, téléphone, etc...).

enfin une 5eme catégorie de "Contact" qui ne possède pas de compte, les clients non-membre("Client").
ils sont simplement inscrits comme tel dans la base (ID, nom, prénom, code postal, date de naissance, date inscription). ils peuvent par la suite changer de catégorie (devenir membre) auquel cas leurs informations seront complétées.

Donc pour répondre à la question, seuls les produits sont affectés à une table, pas les clients.

Par contre "membre" et "Client" partagent les mêmes informations mais en fonction de la catégorie à laquelle ils appartiennent ils n'auront pas les même droits et prix des produits, idem pour "Club", "Gestion" et "Table".
Donc je pourrais ne faire que 2 entités "Compte" et "Contact" qui appartiendraient chacune à 1 seule des 5 "Catégorie", la PK idCatégorie sera de toute façon dupliquée dans les tables compte et contact non?

On est donc ici dans le schéma classique COMMANDE 1,n --- posséder --- (1,1) LIGNE_COMMANDE 1,1 --- concerner --- 0,n PRODUIT
La "commande" étant chez vous le "panier"
Notez les parenthèses autour des cardinalités de "posséder" coté "ligne_commande", pour mettre en évidence l'identification relative : la ligne de commande (ici ligne de panier) n'existe que si le panier existe.
C'est donc une entité-type faible. D'où utilisation de l'identification relative. La conséquence est que la PK de la ligne sera constituée de la PK du panier + l'identifiant de la ligne

c'est modifié.

A partir du moment où vous devez gérer des paiements, il n'est pas question de supprimer les paniers et leurs lignes, vous devez les conserver, archivés ou non !
Il manque d'ailleurs tout ce qui est lié à la facturation : facture, ligne de facture, codes et taux de TVA, moyens de paiement, devises de paiement...

j'ai ajouté des entités facture et TVA mais je ne sais pas si elles sont correctement relié...
la devise sera toujours la même.
les moyens de paiement étaient déjà présent sur le précédent MCD (entité mode_paiement).

voici les 2 versions de MCD auquel je suis arrivé en fonction de vos remarques :
version 1:


***********************************************

version 2


encore merci!