Modeliser le statut de vente

Bonjour à tous,

pour un projet de suivi de vente d'articles, je realise un MCD comme celui en piece jointe!
En fait le client pourra visualiser sur une page web, si ses articles sont vendus ou pas! ( date de vente,prix de vente)


Il ya un point sur lequel j'hésite:

L'entité VENTE a t elle lieu d'exister, ou devrais-je ajouter ses propriétés directement dans l'entité PRODUIT ?
Creer cette entité VENTE peut servir pour archiver toutes les ventes, mais pr la visualisation , tout regrouper dans PRODUIT peut aller, Non?


Et comment modeliser le statut d'un article (vendu ou pas), un booleen peut etre? Mais je ne sais pas si je dois le placer dans vente ou dans produit!

help, i m lost!

Bon et bien merci d'avance, si vous avez quelques instants à me consacrer.

La réponse est là :

Citation:

---

Envoyé par sativa808

( date de vente,prix de vente)

---

Si tu veux afficher les dates et prix de vente, il y en aura plusieurs à afficher donc tu dois externaliser la notion de vente du produit.

En plus c'est quand même mieux pour la gestion !

Merci de ta réponse,
j'avais oublié de preciser que chaque article est unique, donc un article n'est vendu qu une fois, pour ça que je voulais tout mettre ensemble.
Mais pour bien faire c'est sur que c'est plus conventionnel de separer ces deux entités!

Quant au status de 'vendu ou pas', tu vois je pensais afficher un message du style: "vous avez une nouvelle vente!"
Là je sèche pour modeliser ça!

Peut etre un test comme ceci:

SI "id_vente" existe pour "id_produit"
ALORS "message"

@+

Comme le dis si précisément CinePhil la solution est dans les attributs.

Juste un commentaire en ce qui concerne la tarification et les tiers/entité de gestion.


En recherchant les entités de l'offre à modéliser et à partir de la liste d'attribut l'entité l'entité Vente est intuitive (de par date de vente)en fait tu ne peux pas le mettre dans l'entite produit car conceptuellement chaque produit n'a pas une date de vente (en mld pourquoi pas ?)

La tarification (prix de vente)dépend bien du produit et de la vente, dans ce cas on le place dans l'association (association 18 dans ton exemple) mais cela ne serait pas justesans rajouter une patte vers client.

Du coup pas besoin de booleen pour modèliser une vente le simple fait que la relation existe dans l'association qui est donc ternaire ici indique une vente. En fait association 18 contient toutes les ventes de produit des clients.

Citation:

---

car conceptuellement chaque produit n'a pas une date de vente

---

Exactly!!

alors avant ton message, j'avais fais une autre esquisse de MCD que je joins au cas où.
Mais ta proposition serait un raccourcis à ce que j ai fait afin d'attribuer la vente d un produit donné à un client.
Qu en pense tu?
j'ai un peu de mal quand on place des attributs dans les associations pour la suite et l'intégration en base de données.

Merci en tous cas

la ternaire entre client/produit/vente constitue au final un historique de vente. dans la base de données on va avoir une table "HistoriqueVente" avec comme attributs des clefs étrangéres à savoir les clés primaires des entités en association (idclient,idproduit,idvente)



ton schéma est bien mais les associations 19 et 20 ne sont pas explicite du tout, en l'absence d'attribut dans l'association(et de nom explicite ;) ) si ton logiciel te le permet tu fais juste une fléche qui part de vente pour pointer directement vers les entités.

Tu remarqueras que "Vente" est un objet naturel toutes ses cardinalités max du côté de ses associations sont à 1.

ok donc je m'éxecute lol , voici deux versions

au passage trop sympa le petit cours, j'etais en licence pro cette année, j'ai mieux compris tes messages que mon prof LOL.

J'avais jamais entendu parlé d'objet naturel!

je vais pouvoir tagger en résolu bientot! aprés TEST!

merci merci!

merci bien du compliment ;)

tu as regardé un peu tout les articles, tutos et livres...peut-être que dans Parlez-vous Merise c'est abordé les objets naturels

... et dans tout ça tu penses que les deux MCD se valent?

@+

Depuis ton second schéma(avec une ternaire) je supprimerais l'association LaVenteDe. Au fianl l'attribut dateVente se retrouve dans Vente, l'attribut prixVente dans l'association deposepar et je ferais 2 binaires Client vers Vente et Produit vers Vente.

Donc ton premier schéma en déplaçant juste le prix de vente dans l'association plutot que dans Vente (en implémentant on pourrait se rendre compte qu'on veuille pouvoir fixer le prix au moment de la création du produit)

en regardant encore une fois le mcd je me dis que la patte vendeur ne sert à rien finalement car dans le modèle physique on va avoir ce schéma (simplifié)

Code:

---

1 2 3

Vendeur : {IDClient, IDVente} laVenteDe : {IDVente,IDProduit} DeposePar : {IDClient, IDProduit}

---

La table physique Vendeur contient 2 informations que nous connaissons déja à partir des 2 autres tables. laVenteDe contient déja IDVente, reste IDClient à trouver. Dans laVenteDe nous avons aussi IDProduit nous pouvons retrouver IDClient en passant par DeposePar (lien entre IDProduit de laVenteDe et IDProduit de DeposePar)


Je pencherais plus pour une table Vendeur au niveau du MLD si on veut faire de l'optimisation par exemple, mais niveau mcd je ne representerais peut etre pas cette relation