Progettazione di database per prodotti con pacchetti di prodotti

Sto costruendo un sistema di database per la mia attività di vendita al dettaglio. Ho impostato alcune tabelle che sono:

• Prodotto
• Acquista
• I saldi
• Equilibrio

Tutti sono collegati tra loro e sono in grado di mostrare il mio livello di inventario.

Il problema che sto riscontrando è che vendo anche pacchetti di prodotti, che hanno prezzi diversi rispetto ai loro prezzi individuali.
Esempio: vendo un'arancia per $ 1, una mela per $ 1,2; Vendo pacchetto di frutta 1 (2 arance e 2 mele) per $ 3,8, pacchetto 2 (4 arance e 4 mele) per $ 7.

Esiste un modo giusto come creare relazioni per questi pacchetti di prodotti?

PS: sto usando FileMaker Pro per creare questo.

Il modello che stai descrivendo viene spesso chiamato " esplosione di parti " o " distinta materiali ". Fa parte della parte dei grafici e degli alberi nello studio delle strutture di dati. L'essenza della soluzione è rendersi conto che ogni dato "prodotto" può essere costituito da altri "prodotti". Il design è quindi una struttura di rete in cui è presente una Producttabella con una riga per ciascun prodotto, indipendentemente dal fatto che sia composta da altri prodotti o meno, e quindi una Product Componenttabella con una riga per ciascun prodotto composto da altri prodotti e ogni prodotto corrispondente che è un componente di quel prodotto. Nel tuo caso, ogni prodotto ha un prezzo. Quindi avresti qualcosa del genere

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

Questo design è preferibile a una singola tabella con un'associazione ricorsiva in quanto separa in modo chiaro quali sono in realtà due tipi di entità: nodi e collegamenti. Nel nostro caso, i prodotti sono i nodi e i componenti del prodotto sono i collegamenti.

Mentre la progettazione della rete è una struttura comune, l'interrogazione è problematica in quanto una volta riempita completamente è una struttura ricorsiva di varia profondità. Forza industriale DBMS come Oracle e SQL Server hanno elementi linguistici speciali (CONNECT BY di Oracle e CTE ricorsivo di SQL Server) per aiutare a rendere la query dichiarativa. Dato che stai usando File Maker Pro, di cui so poco, potresti non avere tali costrutti linguistici per aiutarti e potresti dover scrivere il codice di procedura per attraversare la rete. Questo problema può essere risolto tuttavia se la rete risulta essere di profondità fissa, ad esempio ogni prodotto non ha componenti o un livello di componenti. Ecco alcuni riferimenti relativi alle strutture di rete nella progettazione di database:

1. Problemi pratici nella gestione dei database - Fabian Pascal . Il capitolo 7 fornisce la spiegazione migliore e più comprensibile che abbia trovato.
2. Alberi e gerarchie di Joe Celko in SQL per Smarties, seconda edizione . Questo è un intero libro sull'argomento specifico dello standard SQL.
3. Enterprise Model Patterns - David Hay . Un libro sugli schemi comuni a tutte le organizzazioni (purtroppo i diagrammi ER sono presentati in UML ma che possono essere superati) ci sono diversi esempi di strutture di rete.