Bonsoir !
j'aimerai créer une BDD pour un petit gestionnaire commercial standard, donc j'ai commencé par ce MCD,  
je voudrai savoir ce que vous en pensez,  
y aura plein de critiques j'en suis sur
 

C'est pour une mise en production ton outil ou par curiosité ? Dans le premier cas, t'as des outils GPL qui font ça très bien.
 
Je t'encourage vivement à prendre connaissance de la forme 3NF de Codd :
http://fr.wikipedia.org/wiki/Forme [...] me_normale
 
Un indice : tout ce qui peut être calculé n'est pas stocké en base. Autrement dit, le montant total d'une commande ou d'autre chose ne doit pas apparaître.
 
Par ailleurs, je pense que tu n'as jamais dû faire de gestion commercial : t'as oublié 3 trucs élémentaires :  
1) les taux de TVA à appliquer à chaque produit. Au passage, la réglementation impose, si je me souviens bien de stocker 4 chiffres après la virgule pour calculer l'arrondi du montant total d'une commande.
2) la facture associée à la commande.
3) les remises applicables (rabais). Pour un commercial, pas pouvoir faire une remise, c'est lui ôter toute latitude  
 
Faudra penser à faire une table "villes" avec les codes postaux pour gérer les adresses.

ça sent l'exo...  
Youce90 : Un forum c'est pas fait pour que les membres du forum te fasse ton exo... Je sais que nous n'avons pas tous le même niveau en "BD" et/ou SQL...
C'est pas le bon moyen de comprendre comment ça marche...
 
Au passage tu n'as pas de notion de status dans tes tables principales, pas de notions de langues, de monnaies , de taux de changes.
Tu livres tes clients aux même endroits ? qu'ils commandent?  => table d'adresse de livraison
Tes clients sont tous du niveau? Pas de clients payeurs? Pas groupes, pas de filliales?  
 
Tes produits sont vendus au même prix pour tout tes clients? Est ce que tous tes clients ne voudront pas une dénomination spécifique?
Il y a pas de tarifs?
Pas de factures...
 
SVP : Faites vos exo, vous même, en fonction des info que vous donnent vos prof.

Oui et non : ça, c'est quand on fait un ERP...
 
Pour une petite GESCOM, on n'a pas forcément envie de :
- stocker l'historique des tarifs
- stocker l'historique des remises clients et autres promotions
- stocker l'historique des remises manuelles
- stocker les changements de TVA
- stocker les changements d'éventuelles autres taxes (SACEM, SODA, EE, etc.)
 
Pour cette raison, que la commande contienne les montants calculés ne me choque pas en soit (après, tout dépends ce qu'on veut faire). Ceci dit, c'est plutôt au niveau de la facture qu'on va conserver ces informations calculées, puisque tant que la commande n'est pas transformée en bon de préparation, les prix peuvent fluctuer librement, et qu'il n'y a d'engagement de prix que sur la marchandise livrée (et donc facturée) - sauf mention contraire dans les CGU -.
Et attention : pouvoir fournir des duplicata de facture est une obligation légale pendant 10 ans il me semble, et un outil de GESCOM doit être en mesure, pendant toute cette durée, "d'expliquer" le montant de chaque ligne d'une facture : les remises doivent être indiquées clairement, les taxes aussi).
Donc on aura plutôt :
- un prix unitaire brut
- un montant total des remises pour chaque niveau (si remises en cascades, avec bases différentes, etc.)
- un montant total pour chaque taxe

Au passage, il manque la partie "devis", bien utile pour une gestion commerciale...

La forme 3NF est une règle mais qui peut être transgressée (comme souvent pour les règles, il y a des exceptions) : par ex, pour des questions de perfs, parfois.

merci pour vos réponses rufo, gpl73
je m'attendais à un tel nombres de remarques...
 
gpl73: vous avez fait de moi un etudiant paresseux en se basant sur un pressentiment ???
donc  
SVP: agissez en fonction de ce que vous savez, et non en fonction de ce que vous pensez
 
c'est un projet personnel que j'aimerai accomplir, apparemment ce ne sera pas facile  
 
j'ai pris vos remarques en considération, j'essaierai d'améliorer mon MCD
je vous tiendrai au courant ...  
Merci à vous

Ne prends pas mal les remarques de gpl73 : tu sais, on a très souvent des personnes qui viennent sur ce forum pour qu'on leur fasse leur exo, TP ou projet. Et certaines d'entre elles nient qu'il s'agit d'un exo (alors que rien qu'en regardant l'énoncé, ça se voit)
 
Dans ton cas, tu dis que c'est un projet perso : ok. Mon conseil si tu veux aboutir à un soft utile/utilisable : regardes comment sont conçu d'autres softs de gestion commerciale et renseignes toi sur le commerce en général, tant point de vue métier que juridique/dispositions légales/réglementations. Tous ces aspects ne s'inventent pas. L'idéale serait d'interviewer des personnes travaillant au quotidien avec ce genre de soft : ce qu'elles aiment bien, et ce qui est moins pratique, comment l'améliorer... Quand on développe un logiciel, toujours partir du besoin des utilisateurs (suffisamment représentatifs et ayant un retour d'expérience suffisamment pertinent), sinon, t'es sûr d'aller dans le mur
 
Forcément, tu vas aboutir à un MCD beaucoup plus complexe : donc plus de développement derrière. Donc, après, à toi de voir si c'est juste un soft pour le fun, auquel cas, t'as pas besoin d'aller trop dans le détail mais ton soft ne sera pas utilisable, soit tu veux produire un soft utilisable et là, il faudra être patient.

ok je comprends  
mais ça reste quand même un bon conseil:
parce que -dans d'autres situations- si on agit en suivant ce qu'on pense, il y aura de graves conséquences
 
je m'excuse pour le retard, j'étais dépassé toute la semaine,  
j'avançais petit à petit, et voilà le résultat:
 
 
 
pour les deux entités CLIENT et FOURNISSEUR je voulais appliquer la notion de l'héritage,  
mais je les trouve tellement identiques, j'ai pas su comment le faire
Merci !

Aussi pour l'identifiant de l'entité LIGNE, je crois qu'il vaut mieux qu'il soit relatif à chacun des identifiants des entités: PROF_FACT, COMMANDE, FACTURE et FOURNITURE.

bonsoir
Youce90 ne prend pas mal mes remarques... comme le dit Rufo, il y a plein de faux projets.
Le but de celles-ci sont surtout de faire réfléchir "le posteur" et pas le forum... lol
par contre pour filer un coup de main, pas de soucis...
Quelle est pour toi la notion de fourniture / produit ?
Tes fournisseurs ne te fournissent pas tes produits? Est ce qu'une fourniture est un composant de ton produit ?
 
Concernant tes tables clients / fournisseurs et la notion d'héritage:
Il est vrai que tu as beaucoup de champs communs et des propriétés, des méthodes aussi communes...  
C'est tentant de penser à l'héritage, mais l'héritage ne va jouer que sur quelques basiques méthodes (insert, delete, update)...c'est pas le plus long à écrire et ou à maintenir...
il faut regarder dup oint de vue BD, ou applicatif, si c'est ce bien utile?  
Que vas tu gagner? pas grand chose je pense...
 
Pour moi : Un fournisseur, ce n'est pas un client donc 2 tables avec leurs champs spécifiques et uniquement ceux-ci, avec en plus si tu veux des contraintes, et/ou triggers spécifiques...
Comme ça je sais où écrire, où chercher, et pour après si tu fais des stat, c'est plus facile ...  
et surtout dans le temps tu vas avoir 36000 règles qui vont venir s'ajouter dans ta gestion client,  alors que la gestion des fournisseurs bouge moins ...
 
Guillaume

Autrement Youce90: comment gères tu les champs Tarif1 -2 dans ta table produit?
tu ne nous parles par de la livraison de tes commandes?
et de tout ce qui est relatif à celle-ci?
la date de livraison, les règles de livraisons (acceptation de reliquats?)
est ce que tu factures que les produits livrés...