verification du MCD

Bonjour,

ma mission est de réaliser une application de gestion de stock (pièces de rechange) et des interventions , le problème c'est que je refait la conception plusieurs fois parce que le cahier de charge offert par la société et toujours incomplet ce qui m'a complique le travail bref...

je travaille avec sql/server et vb.net
et vous trouvez là dessus l'MCD que je propose , plz je veux savoir si ce qu'il y'a des améliorations , des propositions .... à faire et surtout la partie mouvement de stock

j'ai un souci c que la quantité sortis doit être calculer à partir de la table intervention ( des articles utilises pour les interventions ) et aussi il y'a des articles utilises en d'autre action , est ce que la modélisation que j'ai fait va me servir

j'attends vos remarques avec impatient pour aboutir le développement :?
Pièce jointe 176525

Bonjour;

Il est difficile de critiquer un modèle conceptuel sans avoir le cahier des charges, quelques remarques toutefois :

Fournisseur :
il est peu probable qu'un fournisseur ait un et un seul téléphone, un et un seul mail etc...
il faut donc modéliser une entité "média" par exemple avec un identifiant, un type (tél, mail) et créer une relation 0,n ou 1,n entre fournisseur et média
(ou une entité téléphone, une entité mail....)
La cardinalité mini 1 avec article, impose de connaitre un article pour pouvoir créer un fournisseur, à vérifier, très probablement mini zéro

Entrée_Stock et Sortie_Stock :
je suis surpris qu'il s'agisse d'entités, je pense que ce sont plutôt les relations entre article et dépôt qui portent les attributs date et quantité où alors un truc m'échappe
Par ailleurs, une seule relation "mouvement" par exemple pour les entrées et sortie devrait suffire. a priori les attributs d'une entrée ou d'une sortie sont les mêmes, seul le signe de la quantité change (débit/crédit)

Magazin :weird::
Avec un Z c'est surprenant :mrgreen:
Ca peut paraitre un détail, mais le DDL généré va embarquer la faute et la propager dans le modèle physique, c'est donc dommage de ne pas corriger à la source
Même remarque concernant SORTI sans E

Article :
Le prix est variable, en fonction du fournisseur, de la date ... ce devrait donc être un attribut d'une relation article/fournisseur/date etc...
CAT_ART s'il s'agit d'une catégorie, alors il faut remplacer le char(30) par un identifiant, et modéliser l'entité catégorie et la relation entre Article et catégorie d'article
Le prix défini en entier est-ce volontaire, si oui pourquoi ne pas avoir un attribut supplémentaire pour identifier le nombre de décimales ?
Un prix sans devise c'est dangereux
Il faut donc une entité devise et une relation entre article et devise (si toutefois le prix reste dans l'entité article ce dont je doute)
La quantité s'accompagne en général d'une unité de mesure de cette quantité (à la pièce, au mêtre, au rouleau, au kit, etc...)
encore une fois, une entité unité de mesure quantité s'impose, et la relation qui va avec
La cardinalité mini 1 avec stock imposerait qu'on ne puisse pas décrire un article avant de l'avoir entré en stock, je doute que ce soit la règle souhaitée !

Intervention :
Les attributs état_int, type_int ... ne devraient ils pas être en relation avec des entités état et type ?

PS : si REF_FR est la référence fournisseur, cette modélisation implique qu'on ne souhaite connaitre que la dernière ref fournisseur pour une référence interne
Or si on a plusieurs fournisseurs pour un même article, ou que la référence d'un fournisseur évolue sans que la référence interne évolue, il faut prévoir une entité "article fournisseur" en lien à date avec l'article interne et le fournisseur