Diseño de bases de datos para productos con paquetes de productos.

13

Estoy construyendo un sistema de base de datos para mi negocio minorista. He establecido algunas tablas que son:

  • Producto
  • Compra
  • Ventas
  • Equilibrar

Todos están conectados entre sí y pueden mostrar mi nivel de inventario.

El problema que tengo es que también vendo paquetes de productos que tienen precios diferentes a sus precios individuales.
Ejemplo: vendo una naranja por $ 1, una manzana por $ 1.2; Vendo paquete de frutas 1 (2 naranjas y 2 manzanas) por $ 3.8, paquete 2 (4 naranjas y 4 manzanas) por $ 7.

¿Hay una manera correcta de cómo crear una relación para estos paquetes de productos?

PD: Estoy usando FileMaker Pro creando esto.

database-design relations filemaker sombreado
fuente

Respuestas:

16

El patrón que está describiendo a menudo se denomina " explosión de piezas " o " lista de materiales ". Forma parte de la parte de gráficos y árboles en el estudio de estructuras de datos. La esencia de la solución es darse cuenta de que cualquier "producto" puede estar formado por otros "productos". El diseño es entonces una estructura de red donde hay una Producttabla que tiene una fila para cada producto, ya sea que esté compuesta de otros productos o no, y luego una Product Componenttabla que tiene una fila para cada producto que está compuesta de otros productos y cada producto correspondiente que es un componente de ese producto. En su caso, cada producto tiene un precio. Entonces tendrías algo como esto

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       |
----------------------------------------------------------

Este diseño es preferible a una sola tabla con una asociación recursiva, ya que separa limpiamente lo que realmente son dos tipos de entidades: nodos y enlaces. En nuestro caso, los productos son los nodos y los componentes del producto son los enlaces.

Si bien el diseño de la red es una estructura común, la consulta es problemática ya que cuando está completamente lleno es una estructura recursiva de profundidad variable. Los DBMS 'de fuerza industrial como Oracle y SQL Server tienen elementos de lenguaje especiales (CONNECT BY de Oracle y CTE recursivo de SQL Server) para ayudar a hacer que la consulta sea declarativa. Dado que está utilizando File Maker Pro, de lo que sé poco, es posible que no tenga tales construcciones de lenguaje para ayudar y que deba escribir un código de procedimiento para atravesar la red. Sin embargo, este problema puede aliviarse si la red resulta ser de profundidad fija, por ejemplo, cada producto no tiene componentes o tiene un nivel de componentes. Aquí hay algunas referencias con respecto a las estructuras de red en el diseño de bases de datos:

  1. Cuestiones prácticas en la gestión de bases de datos - Fabian Pascal . El Capítulo 7 proporciona la mejor y más comprensible explicación que he encontrado.
  2. Árboles y jerarquías de Joe Celko en SQL para Smarties, segunda edición . Este es un libro completo sobre el tema específico del estándar SQL.
  3. Patrones de modelo de empresa - David Hay . Un libro sobre patrones comunes a todas las organizaciones (desafortunadamente los Diagramas ER se presentan en UML pero que pueden superarse) hay varios ejemplos de estructuras de red.
Todd Everett
fuente