MLD Gestion des stocks

Version imprimable

16/07/2020, 09h43
olivier252

1 pièce(s) jointe(s)

MLD Gestion des stocks

Bonjour,
Voici un petit extrait d'un MLD de gestion des stocks : j'ai créé une relation entre une classe de pièce détachée et une classe qui permet de lancer un ordre d'achat sur une quantité d'une piece détachée.
Je suis parti du principe d'une relation n:n. A savoir, une pièce détachée peut être demandée dans plusieurs demande d'achats et une demande d'achat peut référencer plusieurs pièces détachées.

Je me demandais où mettre la quantité de pièces détachées à commander, quel serait le meilleur scénario à privilégier ?

Pièce jointe 575099

Merci à vous
16/07/2020, 13h23
fsmrel

Bonjour olivier252,

Avec votre 1er scénario, on ne peut pas savoir pas de quel type de pièce il s’agit, avec le 2e scénario on le sait.
16/07/2020, 19h14
olivier252

Bonsoir et merci de m'avoir répondu.

Je suis désolé mais je n'ai pas copris car je pensais que l'on pouvait trouver une pièce grâce à la clé étrangère de la table de jointure. Il n'est pas possible de faire un select avec un where 'pieceDetachee'=id_pieceDetachee ?

Merci encore
16/07/2020, 19h47
escartefigue

Si la quantité est dans la table demande_achat, alors il sera impossible de savoir laquelle des pièces détachée est concernée par la quantité
Sauf si, cas très peu probable, toutes les pièces détachées sont obligatoirement commandées pour une même quantité.

Par ailleurs, la table Join_piece_demande issue de l'association n,n n'a pas besoin d'identifiant propre. Son identifiant unique doit être le couple d'identifiants issus de piece_detachée et de demande_achat ;)

Enfin, si les quantités peuvent être exprimées selon des unités de mesures différentes (à l'unité, au kg, au mètre linéaire, au sachet...) alors il faut une table des unités de mesure en lien avec la pièce détachée.

Bonsoir Olivier,

Vous avez défini une association n:n, donc une pièce donnée peut faire l’objet de plusieurs demandes et une demande donnée peut concerner des pièces différentes.

Exemple selon le 1er scénario :
PIECE_DETACHEE
pieceId   pieceRef   piecePrix
p1        ref001     100,20
p2        ref002     200,40
p3        ref003     300,30

DEMANDE_ACHAT
demandeId   qtePiece   demandeDate
d1          90         2020-07-10
d2          40         2020-07-13
d3          25         2020-07-15 

PIECE_DEMANDE
pieceId   demandeId   
p1        d1
p2        d1
p1        d2
p1        d3
La demande d1 détermine une quantité 90, mais on ne sait manifestement pas ventiler cette quantité selon les pièces référencées.

Exemple selon le 2e scénario :
PIECE_DETACHEE
pieceId   pieceRef   piecePrix
p1        ref001     100,20
p2        ref002     200,40
p3        ref003     300,30

DEMANDE_ACHAT
demandeId   demandeDate
d1          2020-07-10
d2          2020-07-13
d3          2020-07-15 

PIECE_DEMANDE
pieceId   demandeId   qtePiece 
p1        d1          80
p2        d1          10
p1        d2          40
p1        d3          25
Cette fois-ci, la demande d1 détermine une quantité 80 pour la pièce p1 et une quantité 10 pour la pièce p2. Il n'ya pas d'ambiguïté.

16/07/2020, 20h32
escartefigue

ou, sous forme graphique, le schéma suivant :

Pièce jointe 575148

En vert : comment savoir si, pour la demande n° 27 la quantité de 200 est la somme de la quantité des pièces n°121 et n°8 (auquel cas, impossible de savoir combien il y en a de chaque référence et combien il faudra facturer) ou bien une quantité identique pour les deux références ?

En jaune : on connait la quantité commandée pour chaque pièce, le montant à facturer est (50 x 15,50) + (2 x 133,82)
17/07/2020, 07h29
Paprick

Bonjour Olivier,
Comme à mon habitude, je pense qu'il serait préférable de régler cette problématique au niveau conceptuel avec un bon MCD.
Le fait de raisonner directement au niveau du MLD peut conduire à des dérives et surtout peut mettre à mal une bonne interprétation du système d'information.
Réglez donc tout d'abord le problème au niveau conceptuel, le MLD et les requêtes deviendront alors naturellement plus simples et évidentes.
Bon courage !
17/07/2020, 10h22
olivier252

Merci beaucoup pour votre aide,
je vais travailler sur les réponses qui m'ont été apportées par vous tous, je classe le sujet en résolu. Je débute dans le domaine et j'ai beaucoup de mal entre autres à faire le lien entre diagramme de classe et model relationnel. Cela me demande beaucoup d'effort pour matérialiser les associations mentalement...Epérons que ça vienne avec la pratique.

De plus, je constate que je distingue mal la différence entre relation 1:n et n:1 et n:n. Par exemple quelle différence entre dire que :
- un musicien joue de plusieurs instruments et un instrument peut être joué par plusieurs musiciens
- des musiciens peuvent jouer de plusieurs instruments et plusieurs instruments peuvent être joués par plusieurs musiciens
J'ai du mal a distinguer la différence sans doute parce que je suis plus littéraire que logique...

Ensuite, je réalise que la relation n:n n'est pas tout à fait vraie dans ce contexte : en effet, c'est seulement au fil du temps que la relation "une pièce détachée concerne plusieurs demande d'achat" prend sens, il faut en effet au moins 2 demande d'achat
échelonnées dans le temps vérifier l'association. Contrairement à l'autre association qui est vraie dès son existence : une demande d'achat concerne d'emblée potentiellement plusieurs pièces.
Comme quoi, d'un sujet en apparence simple...

Merci encore

Olivier
17/07/2020, 13h59
escartefigue

Bonjour Olivier,

Citation:

Envoyé par olivier252

De plus, je constate que je distingue mal la différence entre relation 1:n et n:1 et n:n. Par exemple quelle différence entre dire que :
- un musicien joue de plusieurs instruments et un instrument peut être joué par plusieurs musiciens
- des musiciens peuvent jouer de plusieurs instruments et plusieurs instruments peuvent être joués par plusieurs musiciens
J'ai du mal a distinguer la différence sans doute parce que je suis plus littéraire que logique...

être littéraire peut s'avérer avantageux : des règles de gestion clairement formulées sont plus aisées à traduire sous forme de cardinalités ou de contraintes ;)
Les cardinalités mini et maxi expriment combien de fois, une même occurrence d'un type d'entité, peut intervenir dans une association

C'est pourquoi la deuxième version de la règle de gestion devrait être libellée ainsi :
R001 : un (et non pas des) musicien peut jouer de plusieurs instruments et un instrument peut être joué par plusieurs musiciens

Dans la première version, avoir mentionné "un musicien joue de plusieurs instruments" signifie que tout musicien joue d'au moins 2 instruments, ce qui ne correspond sans doute pas à la réalité
à reformuler
R001 : un musicien joue d'au moins un instrument et un instrument peut être joué par plusieurs musiciens

Citation:

Envoyé par olivier252

Ensuite, je réalise que la relation n:n n'est pas tout à fait vraie dans ce contexte : en effet, c'est seulement au fil du temps que la relation "une pièce détachée concerne plusieurs demande d'achat" prend sens, il faut en effet au moins 2 demande d'achat échelonnées dans le temps vérifier l'association. Contrairement à l'autre association qui est vraie dès son existence : une demande d'achat concerne d'emblée potentiellement plusieurs pièces.

Comme je l'ai écrit plus haut, ce qui compte c'est de représenter combien de fois, une même occurrence d'un type d'entité, peut intervenir dans une association.
Même si dans certains cas, même provisoirement, une pièce détachée ne concerne qu'une seule demande d'achat, potentiellement, elle en concernera plusieurs, on est donc bien sur une cardinalité maximale n
Pour la même raison, une pièce détachée peut provisoirement ne concerner aucune demande d'achat (cas d'espèce : la nouvelle pièce qui n'a encore jamais été commandée), c'est pourquoi la cardinalité minimale doit être zéro.

Enfin, tout comme Paprick, je recommande de commencer par le MCD et d'en dériver ensuite le MLD. Et ce plus particulièrement si le modèle est complexe et/ou que vous maîtrisez mal la modélisation ;)
17/07/2020, 17h16
olivier252

Merci infiniment pour votre réponse,

Finalement, je ne suis pas si littéraire que ça:D puisque je formulais mal 2 fois la même chose !

Effectivement, l'idéal est de partir du MCD pour suivre les excellents conseils de Paprick. Le problème, pour définir le contexte, c'est que je viens de prendre mon premier
poste en développement et je suis en mission dans une PME pour ajouter un module à une solution existante.

Du coup je me retrouve à morceler au maximum ce schéma d'architecture tout en me référant aux classes de persistance...En plus je suis étranger au métier de la société, donc je peine beaucoup à me représenter des cas concrêts. Bref, j'ai beaucoup à apprendre. Merci pour votre aide une fois de plus
17/07/2020, 17h27
fsmrel

Salve omnes,

Citation:

Envoyé par Paprick

Comme à mon habitude, je pense qu'il serait préférable de régler cette problématique au niveau conceptuel avec un bon MCD.

Olivier parut en être convaincu il y a quelques mois, lors de la discussion qu’il avait ouverte « Réflexion autour d'un MCD » :

Citation:

Envoyé par olivier252

Les réponses sur ce fil ont dépassé mes espérances c'est pourquoi je remercie chaleureusement les contributeurs et à nouveau Paprick : il y a largement matière à avancer sur le sujet que je considère comme largement résolu !

Mais au départ, Olivier vise manifestement le diagramme de classes (« Réflexion d'un débutant autour du MCD »)

Cela dit, les explications du Capitaine sont très claires. La mayonnaise finira bien par prendre un jour...
17/07/2020, 17h37
olivier252

En fait, j'ai du mal à me repérer : à l'école effectivement, il y a quelques mois on a abordé la modélisation (date des sujets) pendant 2 jours, je n'en n'ai pas refait depuis. Du coup, j'ai l'impression qu'en entreprise on tombe tantôt sur de l'UML, tantôt sur des MLD
Cordialement
17/07/2020, 21h51
Paprick

Bonsoir,

Citation:

Envoyé par olivier252

En fait, j'ai du mal à me repérer : à l'école effectivement, il y a quelques mois on a abordé la modélisation (date des sujets) pendant 2 jours, je n'en n'ai pas refait depuis. Du coup, j'ai l'impression qu'en entreprise on tombe tantôt sur de l'UML, tantôt sur des MLD

Ce constat se vérifie malheureusement souvent... La modélisation préalable des systèmes d'information aui niveau conceptuel est souvent négligée par les entreprises qui se jètent immédiatement sur les schémas relationnels des bases de données... :(
Et quand on trouve des modèles UML, ils sont rarement compatibles avec une approche systémique conduisant à la bonne structure des données...
Mais bon, les choses commencent à changer, et les vertus d'une bonne modélisation conceptuelle avant implémentation commencent enfin à être reconnues... mais c'est pas gagné ! :traine: