Discussion :

[Lynn2563]

Bonjour,
J’ai réalisé un MCD pour mon projet, mais je rencontre un problème de fermeture circulaire entre certaines entités.



Dans ce modèle, chaque commande peut avoir plusieurs livraisons, et une seule facture est associée à la commande.
Pourriez-vous m’aider à corriger le MCD afin d’éviter la fermeture circulaire?
Merci !

[escartefigue]

Bonsoir Lynn2563

Je ne vois aucune référence circulaire dans votre MCD, par contre, il y a d'autres choses qui méritent votre attention :

Types d'entité [FACTURE] et [COMMANDE]
vu qu'il y a une et une seule facture par commande et une et une seule commande par facture, ces deux types d'entités sont redondantes, il ne faut en conserver qu'une seule : commande = facture


Type d'entité [ARTICLE]
La notion de quantité en stock n'a de sens que si l'article n'est stocké que dans un seul lieu (un seul entrepôt, un seul magasin...)
L'attribut date_exp, s'il s'agit de la date d'expiration, n'est pas un attribut de l'article, mais d'un lot d'articles.


Association (effectue)
Le terme "effectue" est inadéquat : une commande n'effectue pas de livraison, une livraison concerne une commande ou se rapporte à une commande.
Pour nommer les associations, il est recommandé d'utiliser un verbe à l'infinitif, comme nous avons vu que FACTURE et COMMANDE ne faisaient qu'un, l'association (concerne) qui les liaient n'a plus lieu dêtre, on peut donc nommer (concerner) l'association entre [COMMANDE] et [LIVRAISON]


Association (detail livraison)
Cette association permet de livrer des articles qui n'ont pas été commandés ! Je doute que ce soit le but
Si l'on ne peut livrer que des articles de la commande, alors il faut supprimer cette association et ajouter d'une part un type d'entité [LIGNE_COMMANDE] et d'autre part un type d'entité [LIGNE_LIVRAISON]


Type d'entité [SORTIE]
S'il s'agit de gérer les sorties de stock, alors cette notion concerne non pas l'article, mais l'article stocké dans tel emplacement de tel magasin de tel entrepôt.
Et on peut généraliser à la notion de mouvement de stock pour gérer aussi les entrées

[Lynn2563]

Merci beaucoup escartefigue

Description du projet :

Ce projet consiste à développer un système de gestion de stock pour un établissement scolaire disposant de pleusieur magasins distincts :
Magasin 1 : dédié au stockage des articles de bureautique (papier, stylos, matériel informatique, etc.)
Magasin 2 : destiné à tous les autres types de produits (produits d’entretien, matériels divers, etc.)
Magasin 3 : dédié au stockage alimentaires..
Chaque catégorie de produits est associée à un seul magasin..
la date d’expiration ne concerne que les produits de nettoyage et les produits alimentaires
Lorsqu’une commande est passée auprès d’un fournisseur, celle-ci peut être livrée de manière partielle.
Par exemple, une commande n°1 peut contenir quatre produits :
Lors de la première livraison, le fournisseur livre deux produits ;
Lors de la deuxième livraison, les deux produits restants sont livrés.

Chaque livraison est accompagnée d’un bon de livraison précisant les produits livrés ainsi que les quantités livrées.
Pour chaque produit inclus dans une livraison, le fournisseur livre la totalité de la quantité demandée dans la commande. Il n’y a pas de livraison partielle sur un même article.

À la fin de l’année, le fournisseur envoie une facture globale.

[escartefigue]

OK, du coup voici un MCD qui peut correspondre :



Pour la partie personnes
J'ai mutualisé ce qui est commun aux employés et fournisseurs en utilisant l'héritage.
Une personne est soit une personne physique (nom, prénom, date de naissance...), soit une personne morale (SIRET, raison sociale, code NAF...), soit, à la marge, les deux à la fois (cas des entrepreneurs individuels).
Les employés sont un sous type de personnes physiques.
La contrainte d'exclusion notée (X) matérialise le fait que la personne qui émet la commande vers un fournisseur, ne peut pas être la même que la personne qui reçoit cette commande
(pour éviter le cas d'un employé qui serait également auto entrepreneur et qui passerait des commandes pour lui-même )


Pour la partie commandes
La notion de lignes de commandes est ajoutée, elle est nécessaire pour faire le lien avec les lignes de livraison et les lignes de facture.
La cardinalité maximale n vers l'association (couvrir) matérialise le fait qu'une ligne de commande peut être livrée en plusieurs fois.


Concernant les livraisons
Chaque ligne de livraison concerne une seule ligne de commande (tout ou partie de cette ligne) et donc un et un seul article.
Facultativement, l'article livré est associé à un lot de fabrication


Au sujet des lots de fabrication
La date de fabrication et la date de péremption ne sont pas liés à l'article, mais au lot de fabrication de cet article, d'où la nécessité de gérer les lots pour certains articles.
Ainsi, pour un article A1 "mayonnaise en pot de 250 ml", on pourra avoir 5 pots du lot L1 fabriqué en 2024 et dot la date de péremption est en 2025 et 12 pots du lot L2 fabriqué en 2025 et dont la péremption sera en 2026.
La notion de péremption étant facultative, la patte de [ART] vers [LOT] possède une cardinalité minimale de zéro


Au sujet des factures
Comme la facturation est annuelle, elle correspond à au moins une livraison. Vous n'avez pas détaillé si chaque ligne de facture correspondait à chaque livraison ou à chaque ligne de livraison.
Dans le doute, j'ai privilégié la solution la plus détaillée.


Pour ce qui concerne le stockage
Comme expliqué précédemment, la quantité en stock ne doit pas dépendre seulement de l'article, mais aussi du lieu de stockage.
Par exemple, dans l'emplacement E1 du magasin M1 il y a 10 articles A1 et il y en a également 20 dans l'emplacement E2 du même magasin M1.
Si A1 est géré par lot (article périssable), dans l'emplacement E1 c'est un lot L1 alors que dans E2 c'est un lot L2.
Bien entendu, le positionnement d'un article ou d'un lot dans un emplacement dépend de la date, d'où la présence de l'entité-type [CAL_calendrier] dans les associations (ENT) et (STO)
Cette entité-type ne deviendra pas une table, ce serait inutile, c'est pourquoi son nom est entre parenthèses. Elle n'est là que pour faire participer la date à la PK des tables associatives "ENT_entreposer" et "STO_stocker".
La contrainte d'inclusion notée (I) de (ENT) vers (STO) est requise pour s'assurer que le lot entreposé dans un emplacement correspond bien à l'article stocké dans ce même emplacement.
La flèche de (ENT) vers [LOT] matérialise le fait que pour une date et un emplacement, on ne peut avoir qu'un seul lot.
La flèche de (STO) vers [ART] matérialise le fait que pour une date et un emplacement, on ne peut avoir qu'un seul article.


MCD à minima, à compléter

[Paprick]

Bonsoir,

Bonjour,
J’ai réalisé un MCD pour mon projet, mais je rencontre un problème de fermeture circulaire entre certaines entités.



Dans ce modèle, chaque commande peut avoir plusieurs livraisons, et une seule facture est associée à la commande.
Pourriez-vous m’aider à corriger le MCD afin d’éviter la fermeture circulaire?
Merci !

La fermeture circulaire vient de votre cardinalité 1,1 / 1,1 entre Commande et Facture.
En effet, si vous créez une commande, le numéro de facture sera exigé ; si vous créez une facture, le numéro de commande sera exigé : il y a donc un problème de référence circulaire.
La solution consiste, comme le signale escartefigue, à fusionner ces deux classes d'entités.
A la rigueur, une cardinalité 0,1 peut vous tirer d'affaire mais, conceptuellement, ce n'est pas terrible ...

Bonne continuation !

[escartefigue]

Bonsoir,

Pour ce cas de figure, je n'utilise pas le terme de "référence circulaire", pour moi la "référence circulaire", c'est une modélisation de ce type :



Quoi qu'il en soit avoir une cardinalité 1,1 de part et d'autre de l'association est une erreur