Discussion :

[MaxenceL]

Bonjour,
je dois concevoir une BDD et procéder a des procédures stockées plus tard. Tout d'abord me voici a la parti du MCD.
Pour commencer voici mon sujet :

Le but est de gérer une base permettant de commander des « bundles » de composants électroniques (plusieurs exemplaires de plusieurs types).
Les bundles sont composés de minimum 2 types de composants dont 1 obligatoirement de type semi-conducteur. Il est possible d’ajouter des composants complémentaires sans limite de quantité.
Le prix du bundle dépendra du prix de chaque composant et du nombre total de composants commandés (prix fixe à ajouter dépendant du nombre total de composants).
Les commandes peuvent également contenir des sachets ayant pour caractéristiques une matière, une taille et une couleur.
Il n’y a également pas de limite au nombre de bundles commandés.

J'ai réaliser mon premier MCD et j'aimerai que vous me corrigiez. Je ne pense pas qu'il soit complet mais je ne vois pas trop quoi faire d'autre.

Merci d'avance.

[escartefigue]

Bonjour,

Puisque vous indiquez "Les bundles sont composés de minimum 2 types de composants", alors la cardinalité mini de Bundle vers composer est 2

Une base de donnée ne doit pas contenir de donnée calculée (à l'exception notable et réglementaire du total facture).
Puisque vous mentionnez "Le prix du bundle dépendra du prix de chaque composant et du nombre total de composants commandés (prix fixe à ajouter dépendant du nombre total de composants)", alors l'entité-type "bundle" ne doit pas avoir d'attribut prix. Pareil pour la commande.

Autre chose, le prix d'un composant dépend de la date, et du fournisseur.
Les fournisseurs révisent leur prix, tous ne proposent pas les mêmes prix pour un même article, et les couts de fabrication des composants que vous produisez vous mêmes, varient.
Le prix est donc l'attribut d'une relation entre un composant, une date et un fournisseur

Dans l'ET commande, vous avez commande_ID, mais aussi d'autres ID, or,
- au niveau conceptuel (MCD), les clef étrangères ne doivent pas apparaitre
- comme les 2 relations en lien avec commande ont des cardinalités maxi n de part et d'autres, ces relations deviendront des tables lors de la génération du MLD. Ce sont donc ces tables qui contiendront les clefs étrangères issues des entités-types
- si toutefois au niveau logique (MLD) les identifiants bundle d'une part et sachet d'autre part, étaient présents dans la table commande, alors une commande ne pourrait concerner qu'un seul bundle et un seul sachet

Le type de composant devrait faire référence (via une relation) avec une entité-type qui permet de décrire le type (libellé du type, date de début de validité du type, date de fin de validité...)

Toute expression de poids et mesure, doit être accompagnée de l'unité correspondante. Il manque l'unité de mesure de la quantité dans l'association "composer" (pièce, m3, sachet, lot, boite, litre etc...), il faudra penser a mettre une unité de mesure du prix dans votre nouvelle association en lien avec la date, le fournisseur, et le composant (voir plus haut)
Les unités de mesure pourront être décrites dans une entité-type (libellé correspondant au code, dates de validité etc...)


Peut etre n'Est-ce qu'une ébauche de MCD mais
- il manque la partie client, votre commande n'est rattachée à aucun client
- il n'y pas non plus de notion de livraison
- quid de la facturation

[MaxenceL]

Voila, j'ai apporter pas mal de correction depuis quand pensez vous ?

[escartefigue]

Bonjour,

Vous avez supprimé les identifiants parasites de l'entité-type commande et externalisé le type de composant, fort bien

Par contre vous avez maintenu le prix au niveau composant, sans lien avec la date, ni le fournisseur (cf. mon post précédent).
Ce choix est risqué, il compromet la tenue d'un historique des prix, contraint à un prix unique à un instant "t" quelque soit le fournisseur, etc...

De plus vous avez corrigé la cardinalité de "bundle" vers "composer" de 0,n en 1,n, mais c'est bien 2,n dans votre cas qu'il faut indiquer

N'oubliez pas aussi ma remarque sur les unités de mesure

L'association "composition" (vous devriez utiliser des verbes pour les associations) me semble plus que suspecte, d'une part à cause des 4 liens d'association, c'est beaucoup, et aussi à cause des ET "taille", "matière" et "couleur" qui semblent devoir être de simples attributs de l'ET "paquet".

Question : que sont les sachets par rapport aux composants ? sont-ce des conditionnements de composants ?

Aussi, complétez vos entités types, il manque des attributs, par exemple une commande a une date de commande

[MaxenceL]

Bonjour,

Au sujet du prix, c'est un simple projet, donc aucun changement aura lieu pour modifier le prix.
Pour les cardinalités, 2N , mon logiciel UML ne me permet juste pas des les faire.

Pour les unités de mesures, je devrais changer quantité qui est un terme trop vague pour juste pièce ? ( je veux être bien sur).

Pour l'association composition, je dois créer 3 association pour "taille " matière" " couleur", relié a sachet ? Je trouve qu'avec mon composition actuel, la création d'un nouveau sachet est bien plus simple et rapide. Qu'elle est le problème que cela peut engendrer?

Les sachets peuvent être rajouter a la commande, ils n'ont aucune connexion direct.

[escartefigue]

Au sujet du prix, c'est un simple projet, donc aucun changement aura lieu pour modifier le prix.

OK, de toutes façons le prix des composants est rarement directement corrélé au prix de vente, dans la vraie vie il faudrait d'une part le prix d'acquisition coté composants et d'autre part le prix de vente et les éventuelles promotions, remises etc...

Pour les unités de mesures, je devrais changer quantité qui est un terme trop vague pour juste pièce ? ( je veux être bien sur).

Non, il faut les deux, sauf si vous comptez TOUJOURS à la pièce
Dans un contexte général, il est fréquent que certains articles soient comptés et facturés à la pièce, d'autres au kit, d'autres au litre etc..., dans ce cas il faut savoir le nombre ou quantité ET l'unité de mesure

Pour l'association composition, je dois créer 3 association pour "taille " matière" " couleur", relié a sachet ? Je trouve qu'avec mon composition actuel, la création d'un nouveau sachet est bien plus simple et rapide. Qu'elle est le problème que cela peut engendrer?

La rapidité n'est pas le sujet du modèle conceptuel qui s'attache à décrire les acteurs ou les objets manipulés (les entités-types), leurs interactions ou relations (les associations) et les règles de gestion (cardinalités et CIF). Et la simplicité est une qualité, sauf si elle dénature la réalité des règles de gestion
Votre modèle actuel implique qu'il y a une relation entre les 4 entités types "sachet", "taille", "matière" et "couleur", or ce n'est pas ce que vous voulez matérialiser.
Si vous voulez référencer les différentes matières, tailles et couleurs, alors il faut effectivement matérialiser 3 relations entre chacune de ces entités-types et l'entié-type "sachet"

[MaxenceL]

Dans mon contexte actuel, les unités de mesure ne me sont pas utile.

J'ai donc modifier la "monstruosité" a 4 pattes ( petit problème pour le nom des associations)

[escartefigue]

J'ai donc modifier la "monstruosité" a 4 pattes ( petit problème pour le nom des associations)

C'est mieux comme ça, par contre, s'il est concevable qu'un sachet ait plusieurs couleurs et/ou plusieurs matières, il est peu probable qu'il ait plusieurs tailles

S'il s'agit de dimensions (longueur, largeur, profondeur) alors pas besoin d'entité type taille, mais il faut 3 attributs dans l'ET sachet
S'il s'agit de taille (ex : petit, moyen, grand) alors il y en a une et une seule pour un sachet

Pour les couleurs et matières, s'il y en a plusieurs, la relation correspondante peut être porteuse d'un attribut pour connaitre la proportion (par exemple 50% polyester, 50% nylon)

[MaxenceL]

Tu parle des cardinalités n'est ce pas ?
Et non ,je pars du principe qu'il ne peut y avoir une seule couleur, ou matière et bien évidement taille.

[MaxenceL]

Je viens de modifier donc :

couleur 0,n ---- couleur_sachet --- 1,1 sachet
taille0,n ---- taille_sachet --- 1,1 sachet
matiere 0,n ---- matiere_sachet --- 1,1 sachet

[escartefigue]

Je viens de modifier donc :

couleur 0,n ---- couleur_sachet --- 1,1 sachet
taille0,n ---- taille_sachet --- 1,1 sachet
matiere 0,n ---- matiere_sachet --- 1,1 sachet

[MaxenceL]

Me reste un dilemme.
Pour les frais, j'ai donc deux frais a prendre en compte.
Le premier, un frais de port classique qui sera fix pour tous je pense.
le deuxieme, est un frais par composants, donc un frais supplémentaires par nombre de composants ( quantité).
Je ne sais ou les placer, actuellement, je l'ai placer dans bundle, mais je suis presque sûr qu'elle n'est pas au bonne endroit.
J'hésite également à faire une nouvelle entité, qui ne correspondrait qu'au frais par composant

[escartefigue]

Le plus souvent, les transporteurs facturent au volume ou au poids selon le type de marchandise : les marchandises légeres sont facturées au volume et les lourdes au poids
Du coup, si certains composants sont très volumineux mais plutôt légers et d'autres au contraire sont très lourds pour peu de volume, facturer le transport à la pièce n'est pas une bonne solution
il vous faudra en ce cas ajouter des attributs masse et volume dans l'entité-type composant, pour pouvoir estimer le cout du transport

Si au contraire, cas le plus simple, vous avez des composants à peu près homogènes en masse volumique, alors inutile de modifier le modèle, comptez le nombre de compos et appliquez un barème au moment de facturer

Ensuite, selon le type d'activité, il arrive que le client final ne paye les frais de port que en deçà d'une certaine quantité commandée