В качестве упражнения для изучения некоторых методов проектирования баз данных я создаю базу данных для вымышленного небольшого компьютерного магазина. Идея состоит в том, что магазин получает некоторые компоненты от нескольких поставщиков, собирает их в компьютерные системы и продает их покупателям.
Вот изображение модели, которую я придумала до сих пор:
Изображение
Некоторые объяснения:
Центральным объектом этой модели является Предмет. Он представляет собой единицу товара, которой владеет или продал магазин, например, один точный процессор i7 920. Этот пункт принадлежит продукту (в данном случае «Intel i7 920»), который относится к категории («процессоры»).
Эти Товары поступают в магазин через Заказ. Когда компоненты заказываются у Поставщика, создается новая запись в таблице «Заказы». Для каждого упорядоченного элемента создается новая запись в таблице элементов с соответствующей записью в OrderItem (я не смог придумать лучшего названия для этой таблицы ...).
Запись OrderItem в основном содержит то, что магазин получил по счету от поставщика: цена, стоимость товара, то же описание и т. Д. Поле заказа определяет, в каком порядке появляются товары, если Заказ должен быть отображен или напечатан.
С другой стороны, когда покупатель что-то покупает, создается счет-фактура. Каждый предмет, который они покупают, создается InvoiceItem. В основном это работает так же, как OrderItem. Поле цены - это цена, которую заплатит покупатель (предположим, что цены не для каждого продукта, а для каждого счета-фактуры. Я не смог найти элегантный способ получить цену за продукт и отслеживать изменения цены) , Если описание имеет значение ПУСТО (NULL), описание соответствующего Продукта появляется в счете-фактуре, в противном случае можно ввести пользовательское описание для этого счета-фактуры.
Теперь самая сложная часть - это таблица Сборок. Если магазин продает систему ПК под названием «ПК 1», в продуктах появится запись «ПК 1», например, принадлежащая к категории «ПК». Каждый раз, когда собирается система «ПК 1», создается новый элемент (с productID «ПК 1»), и для каждого компонента этой системы добавляется запись в сборки: идентификатор сборки будет itemID нового элемента. , componentID - это itemID компонента.
Я просто подумал о другом способе управления этим без таблицы сборок: магазин мог бы «продать» компоненты за 0 $ (ну, фактически, 0 CHF) вымышленному клиенту и «купить» собранный компьютер у вымышленного поставщика ( опять же бесплатно). Это кажется более легким делом, так как компоненты исчезнут со склада, но будет ли простой способ связать «проданные» компоненты с «купленным» компьютером?
Теперь я очень доволен тем, что я узнал из этого. Но, безусловно, есть некоторые ошибки или лучшие способы изобразить вещи, о которых я не мог думать. Я рад получить любые предложения и критику. Заранее спасибо!
PS: Извините, если текст немного длинный ... Кроме того, извините за некоторые случаи плохого английского (это не мой основной язык), что также объясняет некоторые неудачные варианты выбора полей / таблиц (для которых я был бы более с удовольствием получаю предложения)))