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