Discussion :

[Alixe80]

Bonjour,
j'aimerais un petit coup de pousse pour la réalisation du MCD d'une boutique de vente de bijoux.
En pièce jointe, le MCD que j'ai déjà fait. Juste une chose, j'ai crée l'entité langue mais je n'ai pas encore créé les relations (je manque d'imagination pour les noms de ces relations) donc pour le moment, un attribut langue est placé dans les entitées concernées...



Sinon, mon problème est au niveau de mon entité description...
Beaucoup de relations mènent vers cette entité et je ne sais pas trop comment gerer ça...
Pour le moment, j'ai mis un attribut référence ou je pensais indiquer de quelle description il s'agit suivi de l'id
ex:

• s'il s'agit d'une description du produit à l'id 1: prd_1
• s'il s'agit d'une description d'une categorie à l'id 3: cat_3

cet attribut ne sera pas unique vu que je peux avoir une description en français pour pdr_1 ou dans une autre langue...

Enfin, je ne sais pas trop si c'est correcte... j'aurais aimé avoir des avis extérieurs sur mon MCD

D'avance merci à ceux qui pendront le temps de le regarder et de me répondre...

[MacFly58]

Voici quelques pistes de réflexions :

- Tous les prix ttc risquent d'être redondants avec les prix ht. Les prix ttc sont des données calculées et n'apparaissent généralement pas dans le MCD.
La table TVA permettra de faire le calcul.

- Je te conseille également d'ajouter des dates d'entrées en application des taux de TVA (date d'entrée et date de fin même). Ces taux varient très rarement, mais quand c'est le cas ont est bien content d'y avoir pensé dès la conception

- Je mettrai l'adresse des clients dans l'entité client (sauf si les fournisseurs sont aussi des clients car dans ce cas on évitera des redondances d'adresses dans la BDD).
Au passage, cela supprimerait la relation "envoyer".

- Il faudrait s'assurer des dépendances fonctionnelles. Par exemple, le prix d'un produit commandé dépend de quel(s) attribut(s) ? Autrement dit, le prix peut-il varié en fonction du client ?

- J'ai du mal à répondre à la question qui te préoccupe en priorité. L'entité "description" est floue. Le but est-il d'imprimer des catalogues par exemple ? Il me manque des règles de gestion pour émettre un avis.

- Il me semble que tu as des redondances avec les photos.

- Je suis surpris de ne pas voir d'entité "facture". Une facture peut être différente d'une commande. Il peut être utile d'en garder une trace. Par exemple, la quantité de produit livrée est parfois différente de la quantité de produit commandée en fonction des stocks.

- De même une gestion de stock est souvent utile. Par exemple, un attribut "stock d'alerte" pourrait permettre de déclencher une commande automatiquement auprès d'un fournisseur.



Cordialement,

[Alixe80]

Tout d'abord, un grand merci pour ta réponse.
Je réponds à tes remarques dans l'ordre.

• Pour les prix ttc, j'ai mis ça dans la db pcque, je me suis dis que c'était mieux pour un question de rapidité, plutôt que de devoir passer par un calcul à chaque fois.

• En ce qui concerne la TVA, ok, je v rajouter ces 2 attributs, c'est vrai que ça peut-être intéressant.

• L'adresse du client, en fait j'ai mis ça dans une entité à part pcque un client a son adresse mais il peut décider d'envoyer une commande à une autre adresse, qui peut appartenir déjà un autre client.
  Et puis, un fournisseur peut avoir plusieurs adresses, d'où ma cardinalité 0,n de fournisseur vers adresses. Je ne peux donc pas mettre adresse dans fournisseur... autant créé une entité séparée pour les adresses.
  Par contre, je viens de me rendre compte que mes cardinalités "adresses --1,n--> envoyer" ne sont pas juste mais doivent être à 0,n...

• Pour mon "problème" concernant mon entité description, je vais m'expliquer plus bas.

• Concernant photos, je suppose que tu fais référence au fait que j'ai une entité photo pour les produits et que pour les entités pierre et catalogue, j'ai mis les attributs concernant la photo dans leur entité.
  J'ai fait ça parce que pour les produits, je peux avoir plusieurs photos, donc d'office, je devais avoir une entité à part.
  Mais pour pierre et catalogue, je n'ai qu'une seule photo. J'allais donc avoir une relation:
  pierre - 1,1 - representer - 1,1 - photos
  Hors, une relation 1,1 n'a pas lieu d'exister, je crois...

• Pour le prix, non, il ne dépend pas de la tête du client lol En fait, le prix ne dépend de rien, si ce n'est éventuellement de la taille de l'objet (ex: je pourrais définir qu'une bague taille 49 à un prix inférieur à celui d'une bague taille 60). C'est pourquoi j'ai mis le prix de vente du produit dans ma table réserve qui est liée à taille.

• Concernant l'entité facture, je sais pas trop. Je pensais simplement adapter la commande en cas de rupture de stock sur un produit commandé...

• Pour ta remarque sur le stock, j'en fais bien une gestion... c'est ma relation stock. Et dedans, j'ai un attribut quantité_min, qui correspond plus ou moins à ce que tu décris à savoir que, si je définis une valeur dans quantité_min, quand mon stock arrive à cette valeur, un avertissement est donné pour indiquer qu'il faut repasser une commande auprès du fournisseur.

Bon, maintenant je v tenter d'expliquer cette histoire de description lol
Mon but n'est pas d'imprimer des catalogues, en fait il s'agit d'une boutique en ligne donc l'utilisateur choisit sa langue et en fonction de ça, les catégories, les produits et les pierres auront un nom, une description et des mots_clée différents.
Vu que ces 3 éléments avaient des attributs dépendants de la langues identiques (donc nom, description et mots_clée), j'ai créé une table description.
Mes 3 entités ont une relation vers l'entité description.
Je ne sais pas si c'est la meilleure façon de faire. Moi, ce qui me gêne maintenant c'est que dans description, je devrai spécifier de quoi il s'agit (si c'est une description de produit, de catalogue ou pierre).
Donc je pensais l'indiquer par un attribut "référence" qui serait suivi de l'id de l'élément concerné.

Ex: s'il s'agit d'une description du produit qui a l'id 21, j'aurais prd_21

Mais je ne sais pas si ma façon de faire est correcte ou si ce serait mieux de ne pas grouper les descriptions de ces 3 entités ensembles...

J'espère que tu auras eu le courage de lire ma tartine et de te pencher sur mon problème

[MacFly58]

Je te réponds en fonction du temps limité dont je dispose^^

* Pour les prix ttc, j'ai mis ça dans la db pcque, je me suis dis que c'était mieux pour un question de rapidité, plutôt que de devoir passer par un calcul à chaque fois.

non là il faut bien passer par un calcul à chaque fois.

* L'adresse du client, en fait j'ai mis ça dans une entité à part pcque un client a son adresse mais il peut décider d'envoyer une commande à une autre adresse, qui peut appartenir déjà un autre client.
Et puis, un fournisseur peut avoir plusieurs adresses, d'où ma cardinalité 0,n de fournisseur vers adresses. Je ne peux donc pas mettre adresse dans fournisseur... autant créé une entité séparée pour les adresses.

- Les règles de gestion peuvent justifier ta modélisation.
- Vérifie la cardinalité Client -1,1---( habite )---Adresse
- La relation "habite" pourrait être remplacée par "est livré", cela faciliterait la compréhension.

* Pour le prix, non, il ne dépend pas de la tête du client lol En fait, le prix ne dépend de rien, si ce n'est éventuellement de la taille de l'objet (ex: je pourrais définir qu'une bague taille 49 à un prix inférieur à celui d'une bague taille 60). C'est pourquoi j'ai mis le prix de vente du produit dans ma table réserve qui est liée à taille.

- Les montants dans la table "Commande" devraient disparaitre je pense. Il peuvent être calculé aisément (prix_produit x quantité_commandée).
- Il restera des redondances sur les prix. Il faut revoir ton système.
- L'entité-type Réserve (et non la table) ne me semble pas claire.
- Une entité Produit peut correspondre à plusieurs entités Réserve, et donc à plusieurs prix de vente

* Concernant l'entité facture, je sais pas trop. Je pensais simplement adapter la commande en cas de rupture de stock sur un produit commandé...

Si le responsable de l'entreprise ou bien un client te demande de réimprimer un Bon de commande et la Facture associée, tu risques d'être ennuyé.

Bon, maintenant je v tenter d'expliquer cette histoire de description lol
Mon but n'est pas d'imprimer des catalogues, en fait il s'agit d'une boutique en ligne donc l'utilisateur choisit sa langue et en fonction de ça, les catégories, les produits et les pierres auront un nom, une description et des mots_clée différents.
Vu que ces 3 éléments avaient des attributs dépendants de la langues identiques (donc nom, description et mots_clée), j'ai créé une table description.
Mes 3 entités ont une relation vers l'entité description.
Je ne sais pas si c'est la meilleure façon de faire. Moi, ce qui me gêne maintenant c'est que dans description, je devrai spécifier de quoi il s'agit (si c'est une description de produit, de catalogue ou pierre).
Donc je pensais l'indiquer par un attribut "référence" qui serait suivi de l'id de l'élément concerné.

Ex: s'il s'agit d'une description du produit qui a l'id 21, j'aurais prd_21

Mais je ne sais pas si ma façon de faire est correcte ou si ce serait mieux de ne pas grouper les descriptions de ces 3 entités ensembles...

Cela mérite réflexion effectivement...

Par contre il me semble opportun que l'identifiant de l'entité-type Description comprenne la "langue". Des données en dépendent. Une relation entre Description et Pays me semble également judicieuse.

Si tu n'as pas fait la phase d'étude des dépendances fonctionnelles, il n'est pas trop tard. Mieux vaut tard que jamais^^


Cordialement,

[Alixe80]

ok, pour le prix ttc je vais le retirer..

Pour l'adresse, je ne comprends pourquoi je dois vérifier ma cardinalité...
Je pense qu'elle est juste... Une personne habite min 1 adresse et maximum 1 adresse.
Pourquoi remplacer ma relation habiter par est livré? Pcque il s'agit bien de le liaison entre client et son adresse de domicile. C'est la relation "envoyer" qui représente l'envoie.

Mis à part le fait que j'indique le montant total dans ma commande, je ne vois pas de redondance de prix. Peux-tu me dire où?

Pour mon entité réserve, oui, une entité produit peut correspondre à plusieurs réserve et donc plusieurs prix. Je peux avoir différente taille pour une même produit. Ma réserve doit m'indiquer mon stock pour un produit et une taille précise. Et pour le prix, oui il dépend de la taille. Comme expliqué auparavant, je pourrais décider qu'une bague taille 49 coute moins chers qu'une bague taille 60...

Pour l'entité facture, je ne crois vraiment pas que ce soit utile. Commande représente la facture. Je ne comprends pas bien l'utilité de faire une entité facture. C'est un achat en ligne. Le client voit directement le stock disponible.

Pour la description, je comprends pas trop pourquoi la liéer à la table pays(?)
ni d'ailleurs pourquoi faire en sorte que l'identifiant de l'entité-type Description comprenne la "langue" vu que la langue vient d'une entité langue externe... (comme dis dans mon premier post, je n'ai pas encore mis la relation vers langue, pr le moment, j'ai juste mis un attribut dans l'entité description mais il va disparaitre après)

[MacFly58]

Pour l'adresse, je ne comprends pourquoi je dois vérifier ma cardinalité...
Je pense qu'elle est juste... Une personne habite min 1 adresse et maximum 1 adresse.
Pourquoi remplacer ma relation habiter par est livré? Pcque il s'agit bien de le liaison entre client et son adresse de domicile. C'est la relation "envoyer" qui représente l'envoie.

L'adresse me semble être l'adresse de livraison qui peut être différente de l'adresse du domicile du client.
Mais vu le contexte de ton projet tout cela n'a finalement guère d'importance car le MCD est relativement simple. On peut considérer que c'est l'adresse personnel du client et qu'il n'a qu'une seule adresse.

Mis à part le fait que j'indique le montant total dans ma commande, je ne vois pas de redondance de prix. Peux-tu me dire où?

Relation "se composer" et entité "réserve"
Mais bon ce qui concerne une commande me semble bizarre. J'en reparlerai à la fin de ce post.

Pour mon entité réserve, oui, une entité produit peut correspondre à plusieurs réserve et donc plusieurs prix. Je peux avoir différente taille pour une même produit. Ma réserve doit m'indiquer mon stock pour un produit et une taille précise. Et pour le prix, oui il dépend de la taille. Comme expliqué auparavant, je pourrais décider qu'une bague taille 49 coute moins chers qu'une bague taille 60...

- Je ne comprends toujours pas ce qu'est la "réserve".
- La quantité en stock d'un produit dépend de prd-id et devrait se trouver dans l'entité "produit" je pense (comme d'autres attributs de l'entité Réserve).
- A mon sens, une bague taille 49 et une bague taille 60 correspondent aux même produit (id-prd) mais l'attribut "taille" n'a simplement pas la même valeur.
- L'entité "taille" pourrait être supprimée je pense. Sinon, cela signifie qu'on pourrait rajouter des entités comme "Civilité du client" (mme, melle, m.), et bien d'autres. Ceci dit lors de la programmation, ce genre de table est utile.

Pour l'entité facture, je ne crois vraiment pas que ce soit utile. Commande représente la facture. Je ne comprends pas bien l'utilité de faire une entité facture. C'est un achat en ligne. Le client voit directement le stock disponible.

Pour la description, je comprends pas trop pourquoi la liéer à la table pays(?)
ni d'ailleurs pourquoi faire en sorte que l'identifiant de l'entité-type Description comprenne la "langue" vu que la langue vient d'une entité langue externe... (comme dis dans mon premier post, je n'ai pas encore mis la relation vers langue, pr le moment, j'ai juste mis un attribut dans l'entité description mais il va disparaitre après) [/QUOTE]

Ok. Tout cela dépend de tes règles de gestion.



Pour finir, je t'invite à soumettre tes problèmes de modélisation en nombres limités dans chacun de tes post. Il est difficile d'analyser une ébauche de MCD sans connaitre le contexte, les règles de gestion, le cahier des charges...
Cela te permettra en outre d'avoir des réponses d'autres internautes

Un petit post avec un problème précis sera plus facilement décortiqué par la communauté. Et nous aurons les règles de gestion car elles seront peu nombreuses.


Cordialement,

[Anne May]

J'avais le même problème avec ma bijouterie de fantaisie et je n'arrive pas à croire qu'un poste aussi ancien puisse m'aider. Je vous remercie.