Bonjour à tous,
 
Je voudrais vous présenter un MCD et que vous n'hésitiez pas à donner votre avis, quelques conseils ou critiques, ce qui vous parait aller de travers et quelles modifications vous y apporteriez (si besoin est ).
 
C'est le MCD de la base de données d'un site web de restaurant.
 
Voici ce que je peux vous en dire:
 
 - l'entité PRODUCT regroupe les informations générales des produits proposés par l'entreprise comme le nom du produit (PRODUCT_LABEL), le fait qu'il soit ou non en vente (ON_SALE), etc... Les champs PRICE_x et UNIT_PRICE_x font référence au prix de vente lié à l'unité x.  
 
exemple:  
 PRICE_1 | UNIT_PRICE_1 | PRICE_2 | UNIT_PRICE_2 | PRICE_3 | UNIT_PRICE_3 |
 2.80 | 'verre' | 12.00 | '1/2 bouteille' | 22.00 | 'bouteille' |
 
 - l'entité CHARAC_WINE créée une identité spécifique pour le vin. ID_CHARAC_WINE doit permettre de réunir les informations spécifiques telles que la région de production (entité REGION), le pays de production (entité COUNTRY), l'appellation du vin (entité MARK) et le type de l'appellation (entité MARK_TYPE).
 
exemple:  
 COUNTRY | REGION | MARK | MARK_TYPE |
 France | Loire | Saumur | AOC
 
 - l'entité MENU regroupe les différents menus proposé à la carte du restaurant.
 
 - l'entité PRODUCT_CATEGORY indique la catégorie de produit c'est à dire par exemple : 'Entrée' ou 'Boisson chaude'. L'association IS_AFFILIATED qui lui est attribuée est réflexive puisque une catégorie de produit peut elle-même être une sous-catégorie.
 
exemple:
 
ID_CATEGORY | CATEGORY_LABEL |
 1 | 'Entrée' |
 2 | 'Entrée chaude' | ('Entrée chaude' est une sous-catégorie de 'Entrée')
 3 | 'Entrée végétarienne' |('Entrée végétarienne' est une sous-catégorie de 'Entrée')
 
 - l'entité GENDER est la civilité des clients (GENDER_SMALL = Mr, Mme, Mlle) (GENDER_LONG = Monsieur, Madame, Mademoiselle)
 
 - l'entité UNIT est la liste des unités de vente des produits (exemple : verre, bouteille, assiette, flute, etc...)
 
 - l'entité RESERVATION regroupe toutes les informations nécessaires pour effectuer une réservation en ligne. (nom du client, numéro de mobile ou mail pour la confirmation, Nombre de place réservées, Date et heure de réservation, etc...).
 
Voici un schéma du MCD:
 
 
Que pensez vous de ce modèle conceptuel de données?
 
Remarques:
  - Je n'ai pas relié les entités GENDER, UNIT et RESERVATION parce que je n'en voyais pas l'utilité. Aucun lien particulier n'aurait de fonction pour ces 3 entités ci. Puisque les réservations se limitent à la table et non aux produits il me parait inutile de relier les réservations à quoi que se soit. (mais peut-être que je me trompe?)
 
 - J'ai conscience qu'il y a de petites redondances d'informations (exemple dans l'entité PRODUCT les champs UNIT_PRICE_x reprennent le contenu de l'entité UNIT. C'est vrai que cela risque de poser un problème si je dois effectuer une modification sur les noms des unités dans l'entité UNIT, il me sera alors plus complexe de modifier les UNIT_PRICE_x de l'entité PRODUCT
 
Merci du temps que vous m'avez consacré.  

Une dernière question : Quand je génère le modèle physique de données (en attendant vos réponses pour mon premier message ) j'obtiens ce schéma:  
 

 
Jusqu'à maintenant j'écrivais mes fichiers sql de la manière suivante :  
 
create table TOTO
(
   ID_TOTO       int(10) not null auto_increment,
   DEF_TOTO      varchar(20) not null,
   primary key (ID_TOTO)
)ENGINE=MYISAM;
 
Mais je viens de lire sur un site que le point faible de MyISAM est qu'il "ne supporte pas les clés étrangères" (voir la source ici : ICI)
 
Je me demande donc si je dois changer mon moteur de stockage MyISAM en InnoDB? Mais est-ce que InnoDB est accepté chez tous les hébergeurs? Et que se passe t-il si je ne renseigne pas le moteur de stockage?
 
Bref le doute m'habite.  

A part quelques petites erreures de normalisation la structure a l'air correcte.
Tout d'abord, comme tu l'as remarqué, il faut remplacer les UNIT_PRICE_x pas une clé etrangère vers la table UNIT, si tout les produits n'ont pas 3 prix (ce qui est probablement le cas pour tout ce qui ne se boit pas) il serai bien aussi d'en faire une table séparée avec un lien vers PRODUIT, UNIT et le prix.
Dans la table RESERVATION, remplacer GUEST_GENDER_SMALL et _LONG pas une clé etrangere vers la table GENDER.
Si la table COUNTRY n'est utilisée que pour decrire du vin, MADE_IN n'est pas necessaire.
 
Pour le reste je pense que InnoDB est accepté chez quasi tous les hebergeurs, le meilleur moyen d'en etre sur c'est encore d'essayer

Merci pour ta réponse Oliiii !
 
En effet je vais devoir rajouter des entité et revoir certaines associations. Je vais faire des test et vous tenir au courant.
 
Pour ce qui est du Moteur de stockage, tu confirmes que MyISAM ne gère pas les clés étrangères? Dans ce cas je vais devoir changer ça, mais cela me semble tout de même bizarre, si le MyISAM ne supporte pas les FK comment ça se fait qu'il est largement utiliser avec MySQL? Les FK sont quand même super présent dans les modèles relationnels.
 
Je suis un peu perdu mais je vous tiens au courant de l'évolution de la DB.

Le coup de myisam qui ne supporte pas les clés étrangères, ça veut simplement dire que c'est ton soft qui va devoir faire les vérifs d'intégrités, mais rien ne t'empêche de mettre un champ dans une table qui correspond à un enregistrement dans une autre table.
 
Sinon, +1 pour le coup de des différents prix d'un produit à mettre dans une autre table.

Message reçu!  J'ai modifié mon mcd pour ajouter une entité PROD_PRICE et j'en ai profité pour faire quelques petites podifications.
 
Voici la nouvelle version :

 
Je pense que c'est mieux comme ça.

Up !  
 
Que pensez vous des modifications apportées? Est-ce que cette nouvelle version du MCd vous parait valide?

Je ne vois plus les images de photobucket au boulot et j'ai plus internet a la maison...
Donc je peu pas vraiment t'aider pour le moment

Erf... c'est ballot.  
 
Peut qu'en changeant l'hébergeur de mes images ça serait mieux?