Неисправность диаграммы E-R

Question

Я занимаюсь разработкой этой диаграммы E-R для магазина, в котором я показал часть ниже (остальное не актуально). См. Ссылку: E-R diagram

Вопрос, который у меня есть, заключается в том, что в магазине продаются только два предмета, носки и обувь. Я правильно описал это на диаграмме? Я не уверен, правильны ли мои мощности и/или мой дизайн. Клиент должен купить хотя бы один из этих предметов для заказа на существование (но имеет право купить любое количество).

башмак и Носок организация будет иметь свой соответствующий атрибут ID, и я планирую перевести в реляционную схему, как это:

(я забыл добавить к моей диаграмме отношений ORDER_CONTAINS иметь атрибут под название " Количество ".)

Table: Order_Contains 
    ORDER_ID | SHOEID   | SOCKID   | QTY 
    primary key | FK, could be null |FK, could be null | INT 

Это явно не сработает, поскольку Qty будет бессмысленным. Есть ли способ уменьшить количество продуктов до двух продуктов и сделать все это?

Answer 1

Наличие двух отношений один-ко-многим, объединенных в одно с полями с нулевым значением, является плохим дизайном. Как бы вы записывали заказ, содержащий как туфли, так и носки - ряд для обуви с SOCKID, установленный в NULL, и наоборот для носков, или вы бы объединили строки? В первом случае значение QTY ясно, хотя это зависит от содержимого полей SHOEID/SOCKID, но что бы означало QTY в последнем случае? Как бы вы имели дело со строками, где и SHOEID, и SOCKID являются NULL, а QTY положителен? Имейте в виду закон баз данных Мерфи - если его можно будет записать, он будет. Хуже того, ваш первичный ключ (ORDER_ID) помешает вам записать более одного ряда, чтобы клиент не мог купить более одного (пару) носков или обуви.

Лучше дизайн будет иметь два отдельных отношений:

Order_Socks (ORDER_ID PK/FK, SOCKID PK/FK, QTY) 
Order_Shoes (ORDER_ID PK/FK, SHOEID PK/FK, QTY) 

С этим, есть только один способ записать содержимое заказа, и это однозначно.

Answer 2

Вы не очень хорошо объяснили контекст здесь. Я попытаюсь объяснить, что я понимаю, и дать вам несколько советов.

Сделайте свой магазин только и всегда (навсегда) продаете 2 продукта? Должны ли сохраняться детали данных продуктов (цвет, модель, вес, ширина и т. Д.) В базе данных? Если да, то у нас есть две сущности в модели, SOCKS и SHOES. Каждый объект имеет свои собственные свойства. Покупка или заказ обычно рассматриваются как событие в ERD. Если ваши клиенты всегда покупает (или заказать) носки с ботинками, то всегда будет связь между тремя субъектами:

КЛИЕНТЫ --- ОБУВИ --- SOCKS

Это соединение/объединение/отношения событие , и это будет покупка (или заказ).

---

Если клиент может купить отдельные ботинки и носки, затем носки и обувь являются подтипами супер сущности, называемые продукты, а покупка является событием между клиентами и продуктами. Здесь в этом случае мы имеем отношение разбиения.

---

Однако, если ваши клиенты покупают отдельные продукты, и ваш магазин не будет продавать навсегда только 2 продуктов, и детали продуктов не всегда одинакова и не будут сохранены в виде столбцов в таблице, то случай - другой.

Обувь и носки считаются товарами, а также другими предметами, которые можно учитывать в будущем. Таким образом, у нас есть записи/строки в таблице ПРОДУКТОВ.

Когда клиент размещает заказ (или покупку), он (она) приобретает продукты. Существует сильная связь между клиентами и продуктами здесь, опять же обычно событие, которое будет покупка (или заказ).

---

Я не знаю, если вы это делаете, но прежде, чем начать думать о диаграммы, введите контекст проблемы в работе или документа. Показать все подробности в этой ситуации.

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

Если вы видите, что сущности связаны каким-то образом, то у вас есть отношения, и вы должны спросить себя, какие отношения эти сущности образуют. В вашем случае продуктов и клиентов у нас есть отношения между покупками. Установленные отношения - это покупка (или заказ, который вы называете). Один клиент может купить различные продукты, и один продукт (а не на той же полке, тип, модель) можно купить для нескольких клиентов, таким образом, у нас есть отношения «Много-ко-многим».

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

Будет существовать тесная связь между клиентами и объектами продуктов (действительно близко ... я думаю ...). В этом случае отношения представляют собой историю клиентов, лижущих продукты. Это создало бы СОБЫТИЕ. В этом случае вы можете поместить такие свойства, как дата, количество раз, когда клиент лизал надлежащий продукт, погоду, время, цвет светофора на улице и т. Д., Только то, что вам нужно, чтобы упорствовать в соответствии с вашим контекстом , твои нужды.

Помните, что для созданных отношений N-N нам нужно увидеть, появятся ли новые сущности (из отношения). Обычно это происходит, когда вы разлагаете концептуальную модель на логическую модель. Возможно, заказы на продукт будут генерировать не одно, а два объекта: ORDER и продукты заказов. В продукты заказов вы размещаете список продуктов, заказанных у каждого клиента, и количество.

---

Я хотел бы представить различные материалы для изучения ERD, но, к сожалению, они все на португальском языке. Надеюсь, я кое-что тебе помог. Если вы хотите более подробно рассказать о своей проблеме, я думаю, что могу помочь вам лучше всего. Что угодно, пожалуйста, спросите.