Gestion de stock via SGBD MySQL

Bonjour à tous et à toutes

Je suis débutant en gestion de base de données.
Et dans la cadre d'un projet, je dois créer une base de données permettant la gestion du stock d'un entrepôt.

J'ai donc commencé par créer la base de donnée, ainsi que 3 tables qui correspondent aux Stocks, Achat, Vente

Pièce jointe 497816

L'objectif est de permettre de connaitre le stock au jour J. Pourvoir ajouter les achats passé au fournisseurs dans le stock et de pouvoir retirer du stock les ventes réalisés auprès des clients.

Ainsi je me pose plusieurs question :

-Si les colonnes de mes tables sont suffisantes pour faire ce que je veux ? (Je commence avec le minimum nécessaire)
-Si les relations que j'ai mis entres mes tables sont adéquate ?
-Enfin l'action d'ajouter / retirer des produits du stock seront réalisées via des snippets (requêtes préenregistrés, si j'ai bien compris) est ce possible ?

Sur quelle thématique me conseillez vous de me renseignez sachant que mes connaissances en SQL sont basique. Afin de pouvoir mener à bien ce projet.
L'objectif étant réellement de faire d'abord quelques chose de simple mais qui répond à mon attente.

Si je pouvais avoir un peu d'éclairage de la part de personne expérimenté à propos de ma problématique, j'en serait grandement reconnaissant.
Merci d'avance

Cordialement

Bonjour,
quelques remarques en vrac:
- le stock est par nature variable et résulte de la différence entre achats et ventes d'un produit identifié: il n'y a pas de table produit... (mais la table stock serait un bon candidat)
- quantité est parfois en INT et parfois en VARCHAR : ça va pas être simple pour les calculs
- 1 achat concerne 1 produit et 1 seul, 1 achat est fait à une certaine date et on achète une quantité définie: le reste est superflu a priori (compte tenu de ton cahier des charges très light)
- même chose pour 1 vente
- pour le prix: si tu dois (cahier des charges) pouvoir différencier le prix d'achat du prix de vente (par ex calcul de bénéf. ou évolution des tarifs), alors le prix d'achat sera dans la table achat et le prix de vente dans celle des ventes ET pas besoin de prix dans la table produit (stock). A contrario, pourquoi s'encombrer du prix?
- catégorie ? pas facile de se prononcer... mais si plusieurs produits peuvent avoir la même catégorie, il faudra 1 table dédiée [id_categorie, libelle_categorie]
- même remarque pour la marque
- pour l'emplacement: ne sachant pas de quoi il s'agit, pas de remarque, mais attention si le système de repérage est matriciel genre numéro dans 1 allée comme chez Ikea !

Voilà, bon courage, et n"hésite pas à proposer la V2 de ton modèle :lol:

Dernière recommandation : plein de tutos concernant la modélisation sur Developpez te seront très profitables pour avoir de bon réflex 8-)

Bonjour qi130, Tout d'abord je tenais à te remercier pour ton aide.

J'ai donc fait quelques petites modifications concernant,la table stock qui devient produit. Et les colonnes ont été modifiés dans les différentes tables comme tu peux le voir :

Pièce jointe 497970

Je vais faire quelques retour concernant tes judicieuse remarques:

Citation:

---

- 1 achat concerne 1 produit et 1 seul, 1 achat est fait à une certaine date et on achète une quantité définie: le reste est superflu a priori (compte tenu de ton cahier des charges très light)

---

Je me demandais s'il était possible de faire les choses autrement. A la place de faire une requête achat/vente pour chaque produit, est-il possible d'avoir une requête qui me présente l'ensemble des produits. Il me suffira donc de rentrer les quantités pour les différents produits que ce soit pour l'achat et la vente ?

L'idée serait donc d'avoir une seul requête pour les achats et une autre pour les ventes. J'aurais seulement à modifier la quantité des produits que ça soit pour la requête achat et la requête vente.

Pour reprendre tes termes il faudrait qu'un achat concerne plusieurs produits. J'imagine qu'il faut créer un table intermédiaire Bon d'achat qui regroupe les produits achetés et une table intermédiaire bon de vente qui regroupe les différents produits vendus.

Je sais pas si j'ai été bien clair :?

Pour ce qui est l'emplacement, je crois que ça correspond à ce qu'on appelle un repérage matriciel. Nos emplacement varient de A-001-001-001 à D-001-001-001.
chaque bloque correspond à une allée, étage, position.

Encore merci pour ton aide, ça m'aide énormément à y voir plus clair.

PS: je suis entrain de voir les tuto par rapport à le modélisation :D

indépendamment du cahier des charges (i.e que doit permettre de faire ou calculer l'application), il existent de multiples possibilités pour le modèle cible physique (= les tables) :lol:

Mais on n'est pas encore à ce niveau... il faut en 1er lieu obtenir le modèle conceptuel basé sur les entités et leurs associations. Il sera toujours temps de dénormaliser au niveau physique (si besoin).

D'après ce que tu montres, je détecte plusieurs entités:

1. produit
2. catégorie
3. marque
4. achat
5. vente
6. emplacement (c'est subtil)

Ensuite, il y a des associations entre ces entités, puis les cardinalités:

• produit-catégorie: 1 produit n'appartient qu'à 1 catégorie, mais 1 catégorie peut comporter plusieurs produits - par exemple pour la catégorie "pile" on aura pile de 1,5 volt, de 9 volts, etc.. la cardinalité résultante est donc : [produit]-(1,1)-(1,n)-[catégorie]
• produit-achat: même approche, 1 produit est acheté (1,n) fois et 1 achat concerne (1,1) produit
• produit-vente: comme les achats
• produit-emplacement: 1 produit est situé à 1 et 1 seul emplacement, et 1 emplacement ne contient qu'1 et 1 seul produit (sauf si le magasinier fait mal son boulot). La cardinalité résultante est donc [produit]-(1,1)-(1,1)-[emplacement]
• etc.

Ce n'est que lorsque tout ça est posé qu'on peut envisager de passer aux tables et relations.
Les entités et leurs attributs deviennent les tables et leurs colonnes.
Les associations deviennent des relations avec en général l'approche suivante:

• 1 association (1,1)-(1,1) permet d'intégrer les attributs d'une entité dans l'autre
• 1 association (1,1)-(1,n) permettra d'avoir dans la table de gauche une FK sur celle de droite
• 1 association (1,n)-(1,n) devient une table de relation dont la PK est composée des colonnes clés des tables gauche et droite

NB: si tu n'es pas familier avec la notation (n,m): le 1er terme se détermine par la question "combien au minimum", et le 2nd par "combien au maximum".
ainsi: combien de catégorie concerne un produit donné? A minima 1 et au maxi 1 => (1,1)

Garde à l'esprit que les explications qui précèdent sont simplistes et vont au plus rapide (je ne veux pas m'attirer les foudres des Maitres du Relationnel présents sur Developpez :roll:)

Essaie de mettre ton modèle d'aplomb par rapport à tout ça.

Citation:

---

il faudrait qu'un achat concerne plusieurs produits

---

Là, je te suggère de parler de commande afin de regrouper plusieurs achats ou ventes.
C'est peut-être 1 entité supplémentaire, mais encore une fois, sans cahier des charges, pas facile de se prononcer.

Bon courage.

Bonjour à toutes et à tous

Cette discussion ne concerne pas MySQL.
Il s'agit d'interrogations sur la conception de la base de données.

Il faudrait mieux se pencher sur le forum Merise pour avoir plus de réponses.

Bonne journée.

Pierre

La modélisation mérise à été faite c'est le passage du modèle conceptuel des données à l'interface de workbench qui me fait douter.

mes règles de gestions sont les suivantes:

-un produit peut ne pas être vendu ou vendu plusieurs fois
-une vente concerne un ou plusieurs produits

-une réception concerne un ou plusieurs produits.
-un produit peut ne pas être reçu une ou plusieurs fois reçu.

-un catégorie peut avoir un ou plusieurs produits
-un produit n'a qu'une seul catégorie

-un fournisseur peut fournir plusieurs produits
-un produit n'est fournis que par un fournisseur

de cela en découle mon modèle conceptuel des données avec les cardinalités:

Pièce jointe 515015


une fois ce travail fait c'est la transposition à mysql qui me pose soucis.
J'ai un peu de mal avec les relations n,n . je crois pas qu'il y a tout les attributs qu'il faut .
ma modélisation est pleinement perfectible et j'aimerais bien connaitre votre avis sur la possibilité de l'améliorer.

le modèle mysql est espagnol et la traduction n'est pas mot à mots mais le modèle est le même


Pièce jointe 515011



Merci pour vos commentaires

Bonjour,

Pour les questions concernant la modélisation, ça se passe normalement ici : https://www.developpez.net/forums/f6...sation/schema/

Cela étant, vos règles de gestion sont incomplètes et du coup le MCD ne va pas.

Par exemple, une vente est liée à une commande elle même liée à un client.
Classiquement, la modélisation consacrée est la suivante
CLIENT 0,n --- commander --- 1,1(R) COMMANDE 1,n --- contenir --- 1,1(R) LIGNE_COMMANDE 1,1 --- concerner --- 0,n PRODUIT

De la même façon, un achat est lié aussi à une commande, celle-ci étant liée à un fournisseur

Positionner les prix d'achat et de vente dans l'entité-type PRODUIT, signifie que le prix est indépendant du client, de la quantité achetée ou vendue, de la date, du conditionnement... très peu probable
De même, la quantité, n'a de sens qu'à un instant "t" et qui dit quantité, dit unité de mesure de cette quantité, sauf si cette unité est la même pour tous vos produits

Pas mieux avec l'emplacement : s'il s'agit de l'emplacement de stockage, alors il est lié au couple produit et entrepôt ou magasin et il peut être multiple (un même produit peut être stocké dans zéro à plusieurs emplacements situés dans différents magasins de différents entrepôts)
Ce qui donne pour ce qui concerne le stockage
PRODUIT 0,n --- stocker --- 0,1 EMPLACEMENT 1,1(R) --- appartenir --- 1,n MAGASIN 1,1(R) --- situer --- 1,n ENTREPOT

Notez le (R) sur certaines cardinalités pour matérialiser l'identification relative dans le cas d'entité type dite "faible" (exemple, l'emplacement n'existe que si la magasin existe : l'emplacement est identifié relativement au magasin, idem pour le magasin et l'entrepôt)