ER Модель, представляющая объекты, не сохраненные в БД и выбор пользователя

Question

Я пытаюсь создать диаграмму ER простой модели базы данных типа торговой сети. У вас есть ваш клиент, различные магазины, инвентарь и т. Д.

Мой первый вопрос: как представлять клиента, размещающего заказ в магазине. Если клиент является владельцем дисконтной карты, у компании есть свое имя, адрес и т. Д., Поэтому я могу иметь объект cardHolder для подключения к товару и хранить его с помощью порядка. Но как я представляю заказ, размещаемый клиентом, который на самом деле не является сущностью в базе данных?

Во-вторых, как условно ... материал, представленный на диаграммах ER, например. в автосалоне клиент может выбрать один или несколько дополнительных дополнительных при покупке автомобиля. Я бы подумал, что есть объект Car с соответствующими атрибутами и параметрами в качестве многозначного атрибута, но как вы представляете пользователя, который выбирает эти параметры (таблица заказа будет отображаться в заказе машины, выбранных дополнительных вариантах и ​​добавленной стоимости дополнительных услуг) в порядке отношений?

Answer 1

Во-первых, вам действительно нужно моделировать клиентов как отдельные объекты, или вам просто нужны данные о порядке, оплате и доставке? Многие розничные системы не отслеживают отдельных клиентов. Если вам нужно, у вас может быть таблица клиентов с суррогатным ключом и уникальными ограничениями на идентификацию таких атрибутов, как SSN или номер дисконтной карты (даже если эти атрибуты являются необязательными). Как правило, трудно предотвратить дублирование в таблицах клиентов, поскольку для людей нет идеального естественного ключа, поэтому подумайте, действительно ли это требуется.

Как смоделировать дополнительные опции, зависит от того, от чего они зависят. Некоторые дополнительные функции могут быть специфическими или специфичными для модели, например. выбор определенных цветов или ручная/автоматическая коробка передач. Расширенные гарантии могут быть доступны по всем направлениям.

Вот пример автомобиля конкретных дополнительных опций:

car (car_id PK, make, model, color, vin, price, ...) 
car_extras (extra_id PK, car_id FK, option_name, price) 
order (order_id PK, date_time, car_id FK, customer_id FK, payment_id FK, discount) 
order_extras (order_id PK/FK, car_id FK, extra_id PK/FK) 

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

В моем примере, order_extras.car_id является излишним, но поддерживает лучшую целостность посредством использования композитных ограничений FK (т.е. (order_id, car_id) ссылки на соответствующие столбцы в order и (car_id, extra_id) ссылки на соответствующие столбцы в car_optional_extras, чтобы предотвратить недопустимые статистов от того связан с заказ).

Вот ER диаграмма для указанных таблиц:

Answer 2

Во-первых, в соответствии с вашей мысли вы определенно можете иметь два вида клиентов. Держатели дисконтных карт, чьи данные присутствуют у компании и новых клиентов, чьи данные недоступны в компании.

Есть три способа достичь того, что вы пытаетесь, 1) имеют две различные таблицы порядка в системе (что лично я не хотел бы предложить) 2) имеют одну таблицу заказа в системе и получить сведения о владельцах дисконтных карт. 3) Вставьте строку в таблицу держателей дисконтной карты для новых/незарегистрированных клиентов, имеющих только одну таблицу заказов в системе.

Наличие таблицы единого заказа сделает систему стандартизованной и будет более удобной при выполнении многих других операций.

Во-вторых, чтобы решить вашу проблему, вам необходимо следить за нормализацией. Это уменьшит текущую проблему, а также сделает систему избыточной бесплатной и сделает объекты взвешенными, что напрямую повлияет на производительность, когда вы будете расти.

Дополнительные выбранные элементы могут быть указаны в заказе от клиента, добавив его во время генерации счета с использованием внешнего ключа. Работа с ключами приведет к быстрым и надежным результатам вместо хранения избыточных/повторяющихся деталей в разных местах.

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

Предпочтительно, чтобы NF 4 был лучше. Посмотрите на следующую ссылку, чтобы начать работу с нормализацией.

http://www.w3schools.in/dbms/database-normalization/