Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Schéma Discussion :

MLD Gestion des stocks


Sujet :

Schéma

  1. #1
    Membre habitué
    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 ?



    Merci à vous

  2. #2
    Expert éminent sénior
    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.
    Faites simple, mais pas plus simple ! (A. Einstein)
    E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    Je ne réponds pas aux questions techniques par MP. Les forums sont là pout ça.
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench

  3. #3
    Membre habitué
    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

  4. #4
    Expert éminent sénior
    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.

  5. #5
    Expert éminent sénior
    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é.
    Faites simple, mais pas plus simple ! (A. Einstein)
    E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    Je ne réponds pas aux questions techniques par MP. Les forums sont là pout ça.
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench

  6. #6
    Expert éminent sénior
    ou, sous forme graphique, le schéma suivant :



    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)

  7. #7
    Membre éclairé
    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 !
    Patrick Bergougnoux - Professeur des Universités au Département Informatique de l'IUT de Toulouse III
    La simplicité est la sophistication suprême (Léonard de Vinci)
    LIVRE : Modélisation Conceptuelle de Données - Une Démarche Pragmatique
    Looping - Logiciel de modélisation gratuit et libre d'utilisation

  8. #8
    Membre habitué
    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

  9. #9
    Expert éminent sénior
    Bonjour Olivier,
    Citation Envoyé par olivier252 Voir le message
    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 Voir le message
    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

  10. #10
    Membre habitué
    Merci infiniment pour votre réponse,

    Finalement, je ne suis pas si littéraire que ça 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

  11. #11
    Expert éminent sénior
    Salve omnes,

    Citation Envoyé par Paprick Voir le message

    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 Voir le message
    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...
    Faites simple, mais pas plus simple ! (A. Einstein)
    E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    Je ne réponds pas aux questions techniques par MP. Les forums sont là pout ça.
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench

  12. #12
    Membre habitué
    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

  13. #13
    Membre éclairé
    Bonsoir,
    Citation Envoyé par olivier252 Voir le message
    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é !
    Patrick Bergougnoux - Professeur des Universités au Département Informatique de l'IUT de Toulouse III
    La simplicité est la sophistication suprême (Léonard de Vinci)
    LIVRE : Modélisation Conceptuelle de Données - Une Démarche Pragmatique
    Looping - Logiciel de modélisation gratuit et libre d'utilisation

###raw>template_hook.ano_emploi###