Bonjour.  
 
Je bosse sur un projet de site de commerce électronnique (php/sql).  
Comme je veux pas me planter j'aimerais savoir si quelqu'un pourrait jeter un oeil sur le modèle logique suivant et émettre des suggestions afin d'optimiser la base.
 
newsletter (date, sujet, contenu)
utilisateur (login, mot2passe; mail, nom, prenom, societe, adresse, CP, ville, tel, newsletter)
cartepro (id_carte, remiseperso, login)
commande (id_cmd, date_cmd, montant_cmd, montant_pmt, nom_fact, prenom_fact, adresse_fact, CP_fact, ville_fact, mode_liv, frais_liv, etat_liv, nom_liv, prenom_liv, adresse_liv, CP_liv, ville_liv, login)
produit (id_produit, type2produit, categorie, prix2base, refce_const, description, image, visibilite)
promotion (id_promo, type, date_deb, date_fin, prix, id_produit)
recevoir (login, date)
posseder (login, id_carte)
subir (id_produit, id_promo)
concerner (id_cmd id_produit, qte, prix)
 
 
Le modèle conceptuel :
 
 
Voilà, merci de prêter attention à mon problème.  

J'avais déjà demandé de l'aide pour la validation du modèle conceptuel, ensuite j'ai dû travailler sur un autre projet et là je revient à ce projet. Si vous pourriez me faire des suggestions, merci, parce que je suis pas douée.
 
Il s'agit de vendre des produits qui peuvent avoir une promotion soit de type professionnelle, soit de type personnelle.

Mise à part le "remise perso" dans ta table "carte pro", je ne vois pas de problème. En fait, c'est pas vraiment un problème, c'est juste que je vois pas ce que ça gère.
 
Idem pour le nommage : L'écriture SMS, franchement ça le fait pas, vire moi ces "2" qu'il y a partout. J'espère que tu fous pas ce genre de choses dans ton code après
 
Sinon, le modèle en lui-même n'est pas parfait, mais il n'est pas mauvais non plus.
Il n'y a pas de MCD "modèle" qui serait parfait et qui s'adapterait à tout. Le tien semble bon. Après, on ne peux pas valider sans document et en 5 minutes ce que tu es censé avoir fait après avoir récupéré un maximum d'information, et réfléchit plusieurs jours...

quoique je ne comprend pas ton binz avec la newsletter... normalement, c'est censé être un flag dans la table des utilisateurs, et pas de relation avec les newsletters elles-même (on s'en fout d'avoir un historique dans la base, et en  plus tel que t'as fait, on ne peux pas gérer d'historique...)
 
sinon, montant_pmt, ça veut dire quoi ? montant_promotion ? alors utilise "_promo" comme suffixe, que tu utilises déjà dans la table des produits.
 
idem, la promo est globale à toutes les commandes, ou seulement pour un client ? parceque là ça marche que pour tous les clients à la fois.
 
en fait, il m'a l'air assez foireux ton modèle

puis on peut faire mieux pour la categorie des produits.
Sans parler des villes, Code postal, etc .. qui apparaissent dans plusieurs tables

moi ce qui me chiffone c'est la cardinalité entre Utilisateurs et NewsLettre, donc si je comprends bien, un utilisateur ne peut avoir qu'une et une seul newsletter. Pas logique, la cardinalité est n à mon avis.

en effet. je n'avais pas mentionné ces points, car c'est très dépendant du nombre de lignes dans la base :
- s'il y a peu de produits, foutre la catégorie en bordel n'est pas dérangeant, et évite des dev superflus
- si un même client ne commande que rarement, alors stocker les adresses de façon "propre" n'est pas forcément utile, car ça ne le dérangera pas de la re-saisir à chaque fois

yep m'enfin ce qui me chiffone le plus, c'est le pourquoi du comment de cette liaison. on s'en fout de savoir à qui on a envoyé les newsletters. pour moi, y'a pas de liaison entre les deux tables

C'est peut être pour savoir à quelle News Letter s'est abonné un user

Ben ouais, mais vu les infos de l'entité Newsletter, c'est pas un "type de newsletter", mais bien la newsletter elle-même.
 
Alors à moins que ça permette ensuite à l'utilisateur de consulter "ses" newsletter en ligne, je ne vois pas du tout l'intérêt.

A mon avis, c'est bien un type de News Letter ... et là, c'est clair qu'il manque qqchose

bah... "date, sujet, contenu", moi ça me semble plus à la liste des newsletters envoyées

Il s'agit de vendre en ligne des produits informatiques.  
 
En premier lieu je pensais créer des entités spécialisées de produit mais mon tuteur n'était pas d'accord, il voulait quelque chose de simple, de facilement administrable.  
 
Ainsi la description des produits ne se fait que par un court texte illustré par une image. La référence constructeur doit être précisée. Les produits sont de différents types et appartiennent à une certaine catégorie. Par exemple le produit ASUS A7N8X est de type carte mère et appartient à la catégorie composants.  
 
L'utilisateur effectue des commandes. Pour les payer, deux possibilités s'offrent à lui :  
Soit il paie la totalité en ligne et dans ce cas la commande lui est envoyée.  
Soit il n'en paie que 30% en ligne et vient chercher sa commande et payer le restant en magasin.  
L'utilisateur peut avoir une adresse de livraison différente de la sienne . Il en est de même pour son adresse de facturation.  
 
Il y a deux types de clients, les clients "de base", et les professionnels. Pour ceux-ci un espace leur est spécialement dédié. Cependant ce n'est que purement commercial puisque les produits sont les même que ceux de l'espace "normal". La différence est que cet espace professionnel est réservé aux détenteurs d'une cartepro. Certains propriétaires de la cartepro peuvent bénéficier d'une remise personnelle après en avoir fait la demande.
 
Pour la newsletter je ne sais pas comment l'intégrer au modèle avec le fait qu'un utilisateur décide de recevoir ou non la newsletter.
 
J'ai modifié le MLD :
utilisateur (login, password, mail, nom, prenom, societe, adresse, CP, ville, tel, newsletter, cartepro)  
cartepro (id_carte, remiseperso, #login)  
commande (id_cmd, date_cmd, montant_cmd, montant_pmt, nom_fact, prenom_fact, adresse_fact, CP_fact, ville_fact, mode_liv, frais_liv, etat_liv, nom_liv, prenom_liv, adresse_liv, CP_liv, ville_liv, #login)
// montant_pmt désigne montant_paiement
produit (id_produit, type_produit, categorie, prix, refce_const, description, image, visibilite, visibilite-promo, prix_promo)  
concerner (#id_cmd #id_produit, qte, prix)

Mais si je comprends bien je ne suis pas obligé de mettre une table newsletter, seul l'attribut newsletter dans la table utilisateur indique que celui-ci recevra ou non la newsletter. Ainsi ce sera du style "select email from utilisateur where newletter=oui".