Design de banco de dados para produtos com pacotes de produtos

Estou construindo um sistema de banco de dados para o meu negócio de varejo. Eu configurei algumas tabelas que são:

• produtos
• Compra
• Vendas
• Saldo

Todos estão conectados um ao outro e podem mostrar meu nível de inventário.

O problema que tenho é que também vendo pacotes de produtos - com preços diferentes dos preços individuais.
Exemplo: vendo uma laranja por US $ 1, uma maçã por US $ 1,2; Eu vendo pacote de frutas 1 (2 laranjas e 2 maçãs) por US $ 3,8, pacote 2 (4 laranjas e 4 maçãs) por US $ 7.

Existe uma maneira correta de criar relacionamento para esses pacotes de produtos?

PS: Estou usando o FileMaker Pro para criar isso.

O padrão que você está descrevendo costuma ser chamado de " explosão de peças " ou " lista de materiais ". Faz parte da parte de gráficos e árvores no estudo de estruturas de dados. A essência da solução é perceber que qualquer "produto" pode ser composto de outros "produtos". O design é então uma estrutura de rede em que há uma Producttabela que possui uma linha para cada produto - seja ele composto por outros produtos ou não e, em seguida, uma Product Componenttabela que possui uma linha para cada produto que é composto por outros produtos e cada produto correspondente que é um componente desse produto. No seu caso, cada produto tem um preço. Então você teria algo parecido com isto

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

Esse design é preferível a uma única tabela com uma associação recursiva, pois separa claramente o que realmente são dois tipos de entidade - nós e links. No nosso caso, os produtos são os nós e os componentes do produto são os links.

Embora o design da rede seja uma estrutura comum, a consulta é problemática, pois quando completamente preenchida, é uma estrutura recursiva de profundidade variável. Os DBMS de força industrial, como Oracle e SQL Server, têm elementos especiais de linguagem (CONNECT BY da Oracle e CTE recursiva do SQL Server) para ajudar a tornar a consulta declarativa. Como você está usando o File Maker Pro, sobre o qual sei pouco, talvez você não tenha essas construções de linguagem para ajudar e precise escrever código de procedimento para atravessar a rede. No entanto, esse problema pode ser resolvido se a rede tiver profundidade fixa - digamos que todos os produtos não possuam componentes ou um nível de componentes. Aqui estão algumas referências com relação às estruturas de rede no design do banco de dados:

1. Questões práticas em gerenciamento de banco de dados - Fabian Pascal . O capítulo 7 fornece a melhor e mais compreensível explicação que encontrei.
2. Árvores e hierarquias de Joe Celko no SQL for Smarties, segunda edição . Este é um livro inteiro sobre o tópico específico para o padrão SQL.
3. Padrões de modelo corporativo - David Hay . Um livro sobre padrões comuns a todas as organizações (infelizmente os diagramas de ER são apresentados na UML, mas que podem ser superados), existem vários exemplos de estruturas de rede.