ER диаграмма моделирования аукционной сделки

Question

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

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

Проблема, которую я пытаюсь смоделировать, - это система онлайн-аукционов, участники которой могут быть покупателями и продавцами (у них есть общие атрибуты, такие как почтовый адрес, имя и пароль). У продавца также есть атрибут банковского счета, а у покупателя - адрес доставки атрибута. Поэтому я нарисовал это как непересекающееся обобщение.

Продавец может продать предмет, а покупатель может предложить цену за товар.

элемент имеет категорию, которая может иметь подкатегорию.

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

Мои два подхода к транзакции следующие:

Решение 1

Выполнение транзакции как трехсторонней связи между покупателем, продавцом и товаром и добавление атрибута обратной связи к взаимосвязи

Решение 2

Вставьте непосредственно отзыв и идентификатор победителя в элемент. (Невозможно продать больше товаров с одним списком)

Заранее спасибо за помощь

Answer 1

Вы не говорите точно, как заполнить наборы / таблицы сущностей и отношений.Вы на самом деле не дали дизайн, пока не сделаете это.Делая разумные предположения об этом и ограничениях, кажется, что оба эти проекта могут записывать ваши ситуации.Для работы 2 требуется (что-то вроде), что домен Winner_ID является доменом идентификаторов покупателя плюс некоторое значение, которое не может быть идентификатором покупателя.SQL обычно использует NULL для такого рода часового значения.

-- "I ids an item"
Item_1(I)
-- "buyer B makes a transaction with seller S for item I with feedback F"
MakesATransaction_1(B, S, I, F)

-- "item I has either winner B & feedback F or no winner & B is null & F is null"
Item_2(I, B, F)

Вы можете видеть, что они могут записывать одинаковые ситуации, потому что для всех B, I & F, [для некоторого S, покупатель B совершает транзакцию спродавец S за элемент I с обратной связью F "] в 1, если и только если [" элемент I имеет либо победителя B & отзыв F, либо нет победителя и B равен нулю, а F равен нулю "& B равен нулю, а F равен нулю] в 2Это также означает, что каждая таблица сущностей / отношений в одном дизайне может быть выражена как запрос в другом.Ключом к этой эквивалентности являются кардинальности, такие как транзакции 1: 1 с предметами с победителями.

PS В 2 вместо сохранения идентификатора победителя вы можете просто сохранить, есть ли победитель / транзакция.Вы понимаете почему?(A: Вы можете запросить победителя.)

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

PS «Имеет» ничего не значит.Выберите имена отношений, описывающие, как участвующие субъекты связаны .Лучше всего - сокращение для четкого шаблона выписки, который делает выписку, если дано значение / значения для сущностей / атрибутов.«Элемент I является членом категории C.»

PS Почему стрелки?Они избыточны.