Дизайн бази даних для виробів із пачками продуктів

Я будую систему баз даних для свого роздрібного бізнесу. Я встановив кілька таблиць, які:

• Товар
• Купівля
• Продажі
• Баланс

Усі пов'язані один з одним і можуть показати рівень мого запасу.

Проблема, яку я маю, полягає в тому, що я також продаю пачки продуктів, які мають різні ціни, ніж їх окремі ціни.
Приклад: я продаю апельсин за 1 долар, яблуко за 1,2 долара; Продаю фруктовий пакет 1 (2 апельсини та 2 яблука) за 3,8 долара, пакет 2 (4 апельсини та 4 яблука) за 7 доларів.

Чи є правильний спосіб, як створити відносини для цих наборів продуктів?

PS: Я використовую FileMaker Pro, створюючи це.

Опис, який ви описуєте, часто називають " вибухом частин " або " викладкою матеріалів ". Вона є частиною графіків та частини дерев при вивченні структур даних. Суть рішення полягає в усвідомленні того, що будь-який даний продукт може складатися з інших «продуктів». Потім конструкція - це мережева структура, де є Productтаблиця з рядком для кожного продукту - чи складається вона з інших продуктів, чи ні, а потім - Product Componentтаблиця з рядком для кожного продукту, що складається з інших продуктів і кожен відповідний продукт, який є компонентом цього продукту. У вашому випадку кожен товар має ціну. Тож у вас було б щось подібне

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

Ця конструкція є кращою для однієї таблиці з рекурсивною асоціацією, оскільки вона чітко розділяє те, що є насправді двома типами сутності - вузлами та посиланнями. У нашому випадку продукти - це вузли, а компоненти продукту - посилання.

Хоча дизайн мережі є загальною структурою, запитувати її проблематично, оскільки при повному заповненні це рекурсивна структура різної глибини. Програмні СУБД промисловості, такі як Oracle і SQL Server, мають спеціальні мовні елементи (Oracle CONNECT BY і рекурсивний CTE SQL Server), щоб допомогти зробити декларативний запит. Зважаючи на те, що ви використовуєте File Maker Pro, про який я мало знаю, можливо, у вас немає таких мовних конструкцій, щоб допомогти, і, можливо, доведеться писати процедурний код для проходження мережі. Однак цю проблему можна полегшити, якщо мережа виявиться на фіксованій глибині - скажімо, у кожного продукту немає ні компонентів, ні одного рівня компонентів. Ось декілька посилань щодо мережевих структур у дизайні баз даних:

1. Практичні питання управління базами даних - Фабіан Паскаль . Розділ 7 дає найкраще і найрозумніше пояснення, які я знайшов.
2. Дерева та ієрархії Джо Селко в SQL для Smarties, друге видання . Це ціла книга на тему, характерну для стандарту SQL.
3. Моделі моделей підприємства - Девід Хей . У книзі про закономірності, загальні для всіх організацій (на жаль, діаграми ER представлені в UML, але їх можна подолати) є кілька прикладів мережевих структур.