Bonsoir les lions,
Envoyé par
RZinaoui
Nous avons travaillé avec Merise tandis que vous travaillez avec ALM.
Je suppose que vous voulez dire UML (Unified Modeling Language, ALM signifiant pour sa part : Application Lifecycle Management et ULM : ultra léger modélisé 
). En fait, le diagramme de Krop est ce que les merisiens appellent un MLD, pour lequel la notation retenue ici pour les associations est celle d’UML. Comme déjà précisé, l’outil est MySQL Workbench (qui offre l’avantage d’être gratuit).
Envoyé par
RZinaoui
Pourquoi alors vous avez crée une nouvelle entité appelée type d'article ?
Krop a bien fait. Vous avez fourni une liste de noms de types d’articles :
organe hydraulique, pneumatique, plomberie, électricité, mécanique, droguerie, sécurité, …
L’usage en modélisation est d’attribuer à chaque type d’article une valeur d’identifiant : voyez ce que dit Tabourier à ce propos (et que je nommerai maintenant Principe de Tabourier).
L’entité-type ARTICLE sera donc dotée de 2 attributs supplémentaires : TypeArtId (identifiant du type d’article) et TypeArtLibelle (libellé du type d’article). Si {ArtId} est identifiant de l’entité-type ARTICLE, celle-ci vérifie désormais les dépendances fonctionnelles suivantes :
{ArtId} -> {TypeArtId} -> {TypeArtLibelle}
D’où un viol de la 3NF... Pour éviter un pareil drame, on débarrasse la table ARTICLE de l’attribut TypeArtLibelle en appliquant le théorème de Heath (que Krop doit commencer à bien connaître, tout comme la position de Tabourier... 
), conduisant à la mise en œuvre d’une table TYPE_ARTICLE :
TYPE_ARTICLE {TypeArtId, TypeArtLibelle}
Envoyé par
RZinaoui
Pour le prix unitaire, il s'agit de celui des fournisseurs.
Vous avez fait figurer ce prix dans l’en-tête de l’entité-type ARTICLE, mais par référence à votre 1er MCD, un article donné peut être fourni par plusieurs fournisseurs. Si ce prix peut être différent selon les fournisseurs, il faut représenter les choses ainsi :
Catalogue_MCD.png)
L’association FOURNIR représente simplement le catalogue des articles proposés par les fournisseurs.
Notez les identifiants alternatifs {ArticleCode} et {FournisseurCode} engendrés par l’application du principe de Tabourier, puisque les identifiants primaires {ArticleId} et {FournisseurId} ne sont pas du ressort de l’utilisateur mais du système (disons que leurs valeurs sont de banals auto-incréments ou hachages et Cie), alors que l’utilisateur fait ce qu’il veut de ses identifiants alternatifs lesquels sont soumis seulement à la règle d’unicité caractéristique des identifiants au sens Merise.
Envoyé par
RZinaoui
Le flux d’information représenté sur le schéma est le suivant : La personne gérant le stock (Le responsable ou son adjoint) effectue en un moment donné une demande d’achat d’articles en cas de besoin, cette demande contient les informations suivantes :
-Les codes des articles demandés.
-Proposition d’un fournisseur (connu par code_fournisseur)
-La quantité demandée.
-La date souhaitée (On souhaite recevoir ces articles au plus tard le jour/mois/année).
-La date de la demande d’achat (Le jour où elle a été écrite)
-Code de la demande.
Une demande fait donc mention d’un certain nombre d’articles, ainsi que d’une suggestion servant à déterminer le fournisseur à contacter. La modélisation correspondante est la suivante :
Vue DEMANDE
Demandes_MCD.png)
En assemblant les vues :
Demandes_Catalogue_MCD.png)
Je note que pour votre part vous avez défini une ternaire :
Demandes_ternaire_MCD.png)
C'est-à-dire que la règle n’est plus celle que vous aviez formulée, selon laquelle une demande concerne un seul fournisseur, mais deviendrait celle-ci :
Une demande peut concerner plusieurs fournisseurs.
Veuillez statuer sur la règle de gestion qui devra être appliquée.
A propos des livraisons.
Vous avez modélisé ainsi :
Livraisons_Viol_2NF_MCD.png)
Je fais observer que, suite à dérivation du MCD en MLD, l’association CONTENIR donnera lieu à une table ayant la structure suivante (clé soulignée) :
CONTENIR {code_livraison, code_article, forme_entrée, date_entrée, quantité_entrée}
Mais vous avez écrit :
Envoyé par
RZinaoui
On peut considérer que le temps entre la livraison des articles et leur mise en stock est nul.
Concernant l’entrée des articles, on doit tenir compte des informations suivantes :
-La date d’entrée (Elle correspond à la date de livraison).
La date d’entrée d’un article est donc égale à la date de livraison, en vertu de quoi il existe la dépendance fonctionnelle :
{code_livraison} -> {date_entrée}
Ce qui fait que la 2NF est violée.
Il faut donc rectifier le tir, faire travailler une fois de plus le théorème de Heath, pour obtenir :
Livraisons_Respect_2NF_MCD.png)
Relation entre les demandes et les livraisons
Selon votre MCD, on ne sait pas à quelle demande fait référence une livraison.
On peut ajouter le lien manquant, comme quoi une livraison honore tout où partie d’une demande :
Livraisons_Cdes_MCD.png)
Attention ce diagramme n’est qu’une vue partielle du diagramme général.
Remarque : Le fournisseur a pu livrer des articles qui ne correspondent pas à la demande : le service Achats s’en sera-t-il occupé ? Est-ce votre rôle ?
A propos des stocks :
Idéalement, le stock est évidemment fonction du stock initial, des entrées et des sorties mais concrètement peut-être aussi de choses non prises en compte ici (articles cassés, perdus, invendables, etc.) : par sécurité vous pourriez modéliser une entité-type STOCK, avec tenue des stocks à date :
On peut bien sûr vérifier par rapport à la différence entre les entrées et les sorties.
Envoyé par
RZinaoui
Pour la table JAD, c'est le résultat d'une relation ternaire existant entre les entités Demande d'achat, Fournisseur et Article. Est-ce bien ça ? Si oui, comment vous avez fait pour la lier à la table ARL ? car on s'est jamais présenté devant un tel cas avec Merise ou bien c'est réservé à ALM ?
Merise le permet par le biais d’une CIF (contrainte d’intégrité fonctionnelle) symbolisée par la flèche rouge et qui signifie que pour un article et une demande donnés il n’y a qu’un fournisseur. En l’absence de CIF il peut y en avoir plusieurs.
CIF.png)
N’oubliez pas qu’avec les diagrammes de MySQL Workbench on modélise des tables et que les contraintes merisiennes liées aux ovales n’existent pas (associations d’associations, etc.)
@Krop,
Selon la table JAD de votre diagramme, une demande peut être associée à plusieurs fournisseurs. Ci-dessus, j’ai fait des remarques à RZinaoui à ce sujet. Maintenant, toujours selon cette table, pour une demande et un article donnés il y a un seul fournisseur, par contre au vu de la composition de la clé de la table ARL pour une demande et un article donnés, on peut cette fois-ci avoir plusieurs fournisseurs : mais ça ne peut pas être le cas (ce que vous confirmez : « La table ARL nous renseigne sur ce qui a été livré Cette table nous informe sur la forme dans laquelle l'article est livré ainsi que le fournisseur qui l'a livré »), ainsi il y a viol de 2NF conduisant à appliquer le théorème de Heath.
@Lions,
Je regarderai la suite un peu plu tard, essayons déjà de nous mettre d’accord sur la partie demandes, livraisons, stock. Je note quand même en passant que la clé primaire de la table JAU de Krop est en contradiction avec les cardinalités portées par les pattes la branchant sur ART et UTI.
Gestion de stock
Répondre avec citation
. Puis, j'ai dit qu'il faut les mettre dans l'association puisqu'ils sont liés aussi à l'article mais comme l'association est un à plusieurs, je vais les perdre lors de la création des tables 
. Du coup j'ai pris l'autre chemin et on peut savoir à quel niveau se trouve un tel article grâce aux clés étrangères (les relations père-fils).
BoutonCiter.png)
BoutonCiterSuite.png)
BoutonCiterSuiteSuite.png)
Stock_V1_MCD.png)
Stock_V1_MLD.png)
Stock_V1_MWB.png)
), une autre commande de 500 pièces chez le fournisseur F'.
Les cardinalités devraient évidemment être 1, 1..* . Disons que c'était pour vérifier que vous suiviez bien tous les deux
Partager