Discussion :

[wild_child]

Bonjour,
Après 4 jours d’étude de cas, d'extraction des règles de gestion d'un stock, je suis enfin arriver a concevoir un MCD qui, de mon point de vue a l'air OK mais j'aimerai avoir un avis de pro vu que que j'ai eu du mal à gérer certaine notion de gestion de stock. Je tiens à souligné que ma conception est de loin probleme-free, je reste juste optimiste et surtout je voudrai corriger les erreurs et pouvoirs passer aux Codage sur une bonne " base " .

Un petit énoncé :
C'est un garage de réparation automobile et qui propose des articles divers lier à la mécanique à la vente.
Donc se système comprendra un gestionnaire de stock qui nous permettra ( comme tout gestionnaire de stock ) de sauvegarder chaque entrée d'un article, son fournisseur, de gérer la quantité requise, de s'approvisionner au bon moment et sauvegarder sa sortie soit pour une commande (achat directe), soit pour une réparation effectuée sur une voiture d'un client et qui lui sera facturé de suite.

Concernant la gestion du garage, un client et sa voiture sont saisis dans la base de données pour pouvoir effectué une réparation, demander un devis sur une quelconque main d’œuvres, un ou plusieurs articles du stock ou une réparation et s'il confirme son achat ou son ordre de réparation, le devis sera transféré en facture ( pour un produit ) ou en une réparation ( devis de réparation ).

Mes doutes sont principalement portés sur ces points :

• La gestion du stock : l'entrée - sortie dans le stock et l'approvisionnement chez les fournisseurs ainsi que les commandes et réparation qui s'en servent du stock sont-ils bien représentés ?
  Un bon de sortie est relatif à une Réparation pour une réparation mais à une commande s'il s'agit d'un achat d'un article ?

j’espère que j'ai mentionné assez d'informations et je précise que les règles de gestion sont basic.
Voici pour le moment, ce qui me complique un peu les choses pour espérer avoir une conception solide et correcte pour pouvoir passer à la suite.
J'attends vos remarques, avis et surtout des corrections
Merci.

[escartefigue]

Bonjour,

Difficile de valider un MCD sans avoir les règles de gestion, or vous n'en mentionnez aucune

Du coup on ne peut faire que quelques remarques d'ordre général

La première est que vous devriez scinder le modèle en sous-ensembles, il est plus facile de valider un petit MCD qu'un tel pachyderme , l'assemblage du tout pourra être fait plus tard, concentrez vous pour l'instant sur l'essentiel, le coeur du métier

Ensuite, quelle est la raison pour laquelle vous distinguez les bons d'entrée et de sortie, et les stocks entrée et stocks sortie, à part le signe du mouvement, tous les attributs sont identiques, il me semble que vous pourriez simplifier en ne modélisant que 2 entités-type au lieu de 4.

Il y a aussi des erreurs sur les types de données
- dans l'ET véhicule, vous avez choisi l'immatriculation comme id primaire. il ne faut JAMAIS choisir d'id fonctionnel comme id primaire : un id fonctionnel peut changer ce qui est lourd de conséquences sur la bases de données à cause de la propagation des id primaires via les contraintes. De plus un format char, et pire varchar, est à fuir comme la peste pour un identifiant primaire. A corriger d'urgence donc
- dans la plupart des autres entités, vous avez choisi du type numérique pour les id, il est préférable de choisir de l'integer attribué par le système (identity column, souvent appelé "auto-incrément", ce qui est réducteur)
- pour les prix, n'utilisez pas du réel, mais du décimal

Respectez les formes normales, il ne faut pas mettre dans une même entité-type, des infos qui ne dépendent pas de l'identifiant. Par exemple, dans client, vous ne devez avoir que ce qui dépend de l'identifiant client, donc ni adresse, ni téléphone qui doivent l'un et l'autre être dans 2 autres entité-type, en relation avec client

Je ne vois nulle part d'entité-type ligne facture, ni de lien entre facture et article, c'est surprenant et nécessite des explications. La encore, les règles de gestion sont requises.

[SQLpro]

Deux remarques :
1) employés et clients sont des personnes. Vous devez synthétiser ces informations dans une seule et même entité générique "personne physique"
2) fournisseur et assurance sont aussi des personnes... morales ! Vous devez synthétiser ces informations dans une seule et même entité générique "personne morale"

De manière générale, vous ne devez jamais avoir 2 attributs qui portent le même nom... En particulier sous Power AMC, si vous faites cela et que vous modifiez le type de l'un des attributs d'une entité, cela modifie aussi le type de l'autre entité, car PAMC considère à juste titre que c'est la même information !!!

Enfin, ne doivent figurer dans une entité que les attributs propres. Les attributs ralatifs ne doivent en aucun cas figurer directement dans l'entité !
Exemple : un patronyme est bien un attribut propre d'une personne physique, car tout le monde possède un patronyme. Cet attribut doit donc figurer dans l'entité des personnes physique. En revanche un n° de téléphone est un attribut relatif à une personne physique ou une personne morale (personne n'est obligé d'avoir un n° de téléphone). Vous devez donc externaliser les N° de téléphone dans une unique table qui sera rattaché à la personne générique dont les entités héritières seront les personnes physiques et morale.
Inspire vous du modèle de personnes que j'ai donné ici :
http://blog.developpez.com/exercices...n_de_personnes

A +

[wild_child]

Après avoir parcouru des dizaine de discussion sur ce forum, j’apprécie énormément l'effort que vous faites pour venir en aide des demandeurs, je vous remercie pour vos efforts.

La première est que vous devriez scinder le modèle en sous-ensembles, il est plus facile de valider un petit MCD qu'un tel pachyderme , l'assemblage du tout pourra être fait plus tard, concentrez vous pour l'instant sur l'essentiel, le coeur du métier

Oui, j'avoue ! et pourtant j'ai scinder tout ce qui en liaison avec les employer, leurs fiches de paie, les règlement et leurs type, etc ..
Pour ce post, j'ai choisis de colorier les entités-type dont je souhaite que vous accordiez votre attention.

quelle est la raison pour laquelle vous distinguez les bons d'entrée et de sortie, et les stocks entrée et stocks sortie, à part le signe du mouvement, tous les attributs sont identiques, il me semble que vous pourriez simplifier en ne modélisant que 2 entités-type au lieu de 4.

J'ai fais comme vous l'avez suggérer : Entrée_stock et Sortie_stock, mais j'ai bloquer .. et j'ai pas su les relier avec des factures, des commandes ou des réparation stock, qui garde les traces, quantité de chaque articles, ainsi que date d'entrée sortie pour l'entité respective.

Je ne vois nulle part d'entité-type ligne facture, ni de lien entre facture et article, c'est surprenant et nécessite des explications. La encore, les règles de gestion sont requises.

Vous aviez raison, c’était un point dont je douté et j'ai oublier de le mentionner mais je les directe corriger.

Enfin comme @escartefigue @SQLpro, vous m'aviez suggérer : Respectez les formes normales et ne doivent figurer dans une entité que les attributs propres.
je vais pencher de suite sur ces points pour les corriger.

AIDE :
Donc mon problème la, je bloque au niveau des entrées/sorties du stock.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
Voici les règles de gestion relatif au stock, réparation et " document ":
RG01-D: Un client peut commander un ou plusieurs articles.
RG02-D: Un client peut demander un devis sur un article du stock, une main d'oeuvres
RG03-D: Un client peut avoir une ou plusieurs facture a son compte, qui correspondent soit à une réparation, soit un achat d'article.
RG04-R: Un client peut faire une ou plusieurs réparations.
RG05-R: Une réparation peut concerner plusieurs main d'oeuvres.
RG06-R: Une réparation peut contenir des articles pris du stock et qui seront facturer au client correspondant lors de la facturation.
RG07-F: Un fournisseur est en charge du remplissage du stock par les articles qui lui sont associés. 
RG08-ES: Une entrée en stock d'un produit génère un bon d'entrée contenant la quantité entrée, le fournisseurs, la date d'entrée
RG09-SS: Une sortie du stock d'un produit génére un bon de sortie contenant la quantité sortie, le concernant ( si une réparation : on note pour la réparation X, si pour une commande, on note le numéro de commande correspondant ).

Au fait ce que j'assimile mal, c'est où stocké la quantité d'un produit, où es qu'on fait une entrer ( fournis par un fournisseur ) et par où on s'en sert ( sortie pour une commande, ou une réparation) , donc où es que ces entrées sorties sont sensé être stocké ou sauvegardé ..

je tiens a mentionner :
* le cahier de charge m'a était décrit oralement, les règles décrite ci dessus sont celle que j'ai moi même imposé.
* Je comprends un peu mal la notion de gestion de stock ( bon au début de se projet, là un peu mieux ).

Je suis un peu fatigué et je sens que la logique m’échappe pour trouver une solution donc je me retourne vers vous

Remarque concernant le MCD :
Une ligne, quelque soit son type (ligne commande, devis, facture) est sensé avoir une cardinalité (1,1) de son coté, mais puisqu'une ligne peut designer soit un article, soit une réparation, j'ai choisis la cardinalité (0,1) mais doit y'avoir obligatoirement une des deux. y'a surement un moyen de modéliser ça correctement donc.

[escartefigue]

Je me permets d'insister :

[...] vous devriez scinder le modèle en sous-ensembles, il est plus facile de valider un petit MCD qu'un tel pachyderme , l'assemblage du tout pourra être fait plus tard, concentrez vous pour l'instant sur l'essentiel, le coeur du métier[...]

J'ai une mauvaise vue, et je n'arrive même pas à déchiffrer ce qui est écrit dans votre MCD, et comme le zoom est inopérant sur les schémas...

Il me semble que le cœur du métier pour un garage automobile c'est les réparations. Ne livrez donc que cette partie la dans un premier temps. La facturation, l'achat de pièces détachées etc... pourront être vus plus tard et séparément

Note : vu la taille du modèle, le nombre de règles de gestion me semble très insuffisant, à vérifier

Au sujet de votre remarque :

Une ligne, quelque soit son type (ligne commande, devis, facture) est sensé avoir une cardinalité (1,1) de son coté, mais puisqu'une ligne peut designer soit un article, soit une réparation, j'ai choisis la cardinalité (0,1) mais doit y'avoir obligatoirement une des deux. y'a surement un moyen de modéliser ça correctement donc.

Il vous faut modéliser 2 relations (une vers article, une vers réparation) et ajouter une Contrainte d'Intégrité Fonctionnelle (CIF) de type "exclusion", matérialisée par un X cerclé, qui rejoint les 2 associations

[SQLpro]

Il vous faut modéliser 2 relations (une vers article, une vers réparation) et ajouter une Contrainte d'Intégrité Fonctionnelle (CIF) de type "exclusion", matérialisée par un X cerclé, qui rejoint les 2 associations

Ou bien passer par un héritage ! (avec exclusion mutuelle....

A +