Разработка базы данных для продуктов с пакетами продуктов


13

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

  • Продукт
  • покупка
  • Продажи
  • Баланс

Все связаны друг с другом и могут показать мой уровень инвентаря.

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

Есть ли правильный способ, как создать отношения для этих пакетов продуктов?

PS: я использую FileMaker Pro для создания этого.

Ответы:


16

Образец, который вы описываете, часто называют « взрывом деталей » или « ведомостью материалов ». Это часть графов и деревьев в исследовании структур данных. Суть решения заключается в том, чтобы понять, что любой данный «продукт» может состоять из других «продуктов». Проектирование - это структура сети, в которой есть 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 для умников, второе издание . Это целая книга по теме, специфичной для стандарта SQL.
  3. Модели корпоративной модели - Дэвид Хэй . В книге о шаблонах, общих для всех организаций (к сожалению, диаграммы ER представлены в UML, но это можно преодолеть), есть несколько примеров сетевых структур.
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.