Vos avis sur analyse

[Banjalex]

Bonjour,

Je me suis lancé dans le développement d'un logiciel de gestion de stock pr essayer de faciliter le travail de ma femme (tout est actuellement sur excel ce qui n'est pas très pratique...).
Je voulais avoir votre avis sur l'analyse que j'ai faite avant de me lancer dans le développement sur 4D (d'ailleurs, si vous pensez qu'il y a plus performant/plus convivial que 4D, vos propositions sont aussi les bienvenues).
Voici le le lien pr le MCD (cliquer sur l'image si elle s'affiche en trop petit):
http://www.upload2.com/?cmd=_viewer&...&s=file-upload
N'hésiter à envoyer vos remarques ou vos critiques, elles seront toutes constructives.
J'aurais aussi 2 grandes questions:
2) Pour l'association "livre", j'aurais voulu retrouver le numéro de commande qui doit etre rattaché à toute livraison. Comment puis-je m'y prendre ?
3) Pour l'entité "Facture", j'aurais voulu la rattacher aussi à l'entité "Fournisseur", mais j'ai lu qu'il fallait éviter les associations n-aires. Comment donc faire pour récupérer les infos du fournisseur et les infos d'une commande dans une facture, faut il absolument relier "Facture" à "Commande" et "Fournisseur" ou y a-t-il une autre solution ?

Je vous remercie tous par avance de l'attention que vous voudrez bien préter à ce Topic. J'espère ne pas avoir été trop "cafouilleux" dans mes explications...

[SQLpro]

1) le type TEXT pour toutes tes colonnes est une abération
2) il faut prévoir un seuil d'alerte de stock.

A +

[Banjalex]

Ok merci des conseils.
J'ai donc rajouté le seuil alerte dans l'entité Article. Pr ce qui est des type TEXT, je ne vais laisser cela dans la future analyse (j'avais fait une première ébauche sur Power AMC).

[yizashi]

Moi il me semble qu'il y a un problème entre les classes Prix_unitaire, Article, Fournisseur et Commande.

Je suppose que le prix correspond au prix d'achat, puisque les produits semblent être "utilisés" par les services et non "vendus".
Dans ce cas, on peut imaginer qu'un produit soit commandé le même jour à 2 fournisseurs différents car selon ton modèle, 2 fournisseurs peuvent offrir le même produit. Si le prix est différent d'un fournisseur à l'autre, ce qui serait probablement le cas, alors je ne crois pas qu'il soit possible de connaître le prix de l'article. Les 2 commandes seraient associées au même article et par conséquent au même prix. Si par contre ta classe prix contient les prix de vente, c'est déjà plus logique.

Enfin bref, moi je déplacerais le prix dans la classe association entre Commande et Article, tu aurais donc pour chaque commande le prix et la quantité des articles commandés.

---------------

Je ne sais pas comment tu as l'intention de mettre ça en place, mais il me semble qu'on ne peut pas savoir quel fournisseur offre quel article. Peut-être qu'il serait pratique de relier Article à Fournisseur.
Lorsque tu passes une commande, l'utilisateur choisirait ce dont il a besoin sans se préoccuper des fournisseurs et c'est après que toi tu divises la commandes en sous-commandes qui seront envoyées au fournisseur adéquat.

Dans ton modèle, il me semble que la personne qui crée une commande doit savoir ce qu'offre chaque fournisseur...

--------------------------

Pour le point 3) je crois qu'il n'y a pas de problème. Lors du passage au modèle logique, tu auras l'identifiant du fournisseur qui va migrer dans la commande puis l'identifiant de la commande migrera dans la facture. Tu sauras donc à quel commande est rattachée la facture et donc quel est son fournisseur.

---------------------------

Pour le point 2) il y a surement un problème, je sais pas vraiment comment je ferais ça, mais peut-être que tu pourrais faire une 2ème association (livré) entre Commande et Article au lieu de celle que tu as fait.
Tu saurais donc que pour la commande X, t'as 10 produits Y qui ont été livrés. Comme cette commande ne concerne qu'un seul fournisseur, on sait donc qui a fait la livraison.

---------------------------

Voilà, j'espère ne pas avoir dit trop de bêtises, c'est pas facile de se mettre dedans comme ça. Surtout que j'en ai pas fait des milliers *encore étudiant*.