Conception de bases de données pour des produits avec des lots de produits


13

Je construis un système de base de données pour mon commerce de détail. J'ai mis quelques tables qui sont:

  • Produit
  • achat
  • Ventes
  • Équilibre

Tous sont connectés les uns aux autres et peuvent afficher mon niveau d'inventaire.

Le problème que j'ai, c'est que je vends également des lots de produits - qui ont des prix différents de leurs prix individuels.
Exemple: je vends une orange pour 1 $, une pomme pour 1,2 $; Je vends le paquet de fruits 1 (2 oranges et 2 pommes) pour 3,8 $, le paquet 2 (4 oranges et 4 pommes) pour 7 $.

Existe-t-il un bon moyen de créer une relation pour ces offres de produits?

PS: J'utilise FileMaker Pro pour créer ceci.

Réponses:


16

Le modèle que vous décrivez est souvent appelé une « explosion de pièces » ou « nomenclature ». Il fait partie de la partie graphiques et arbres de l'étude des structures de données. L'essence de la solution est de réaliser que tout «produit» donné peut être composé d'autres «produits». La conception est alors une structure de réseau où il y a une Producttable qui a une ligne pour chaque produit - qu'elle soit composée d'autres produits ou non, puis une Product Componenttable qui a une ligne pour chaque produit qui est composée d'autres produits et chaque produit correspondant qui est un composant de ce produit. Dans votre cas, chaque produit a un prix. Vous auriez donc quelque chose comme ça

Product
-----------------------------------
|Name             |Price          |
-----------------------------------
|Orange           |1             |
|Apple            |1.20          |
|Fruit Package    |3.80          |
-----------------------------------

Product Component
----------------------------------------------------------
|Product               |Contains                |Quantity|
----------------------------------------------------------
|Fruit Package         |Orange                  |2       |
|Fruit Package         |Apple                   |2       |
----------------------------------------------------------

Cette conception est préférable à une table unique avec une association récursive car elle sépare proprement ce qui sont en réalité deux types d'entités - nœuds et liens. Dans notre cas, les produits sont les nœuds et les composants du produit sont les liens.

Bien que la conception du réseau soit une structure commune, l'interrogation est problématique car lorsqu'elle est complètement remplie, il s'agit d'une structure récursive de profondeur variable. Les SGBD de puissance industrielle tels qu'Oracle et SQL Server ont des éléments de langage spéciaux (CONNECT BY d'Oracle et CTE récursif de SQL Server) pour aider à rendre la requête déclarative. Étant donné que vous utilisez File Maker Pro, que je connais peu, vous n'aurez peut-être pas de telles constructions de langage pour vous aider et devrez peut-être écrire du code de procédure pour traverser le réseau. Ce problème peut cependant être résolu si le réseau s'avère d'une profondeur fixe - par exemple, chaque produit ne possède aucun composant ou un seul niveau de composants. Voici quelques références concernant les structures de réseau dans la conception de bases de données:

  1. Problèmes pratiques de gestion de base de données - Fabian Pascal . Le chapitre 7 fournit l'explication la meilleure et la plus compréhensible que j'ai trouvée.
  2. Arbres et hiérarchies de Joe Celko dans SQL pour Smarties, deuxième édition . Il s'agit d'un livre entier sur le sujet spécifique à la norme SQL.
  3. Modèles de modèle d'entreprise - David Hay . Un livre sur les modèles communs à toutes les organisations (malheureusement, les diagrammes ER sont présentés en UML mais qui peuvent être surmontés), il existe plusieurs exemples de structures de réseau.
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.