Сопоставление троичной связи с реляционной моделью (сотрудники, заказчик, проект)

ER-диаграмма

Я хотел бы преобразовать этот сегмент ER-диаграммы в реляционную модель. У нас есть тройное отношение, и оно говорит следующее:

  • 1 клиент дает 1 проект -> нескольким разработчикам
  • 1 Заказчик назначает 1 разработчика с -> несколькими проектами
  • 1 разработчик назначает 1 проект -> ОДИН клиент

Предлагаемое решение будет таким:

Назначение(EmployeeID, CustomerID, ProjectID)

где первичный ключ состоит из EmployeeID, CustomerID и ProjectID. И все эти атрибуты являются внешними ключами, каждый из которых относится к соответствующему объекту.

Но это решение совершенно неверно, поскольку оно не выражает то же самое, что и ER-диаграмма. У нас есть составленный первичный ключ, а это означает, что КОМБИНАЦИЯ этих трех вещей УНИКАЛЬНА. Это означает, что у меня может быть тот же ProjectID с тем же EmployeeID, но с другим CustomerID (чего я не хочу).

Как решить эту проблему?

РЕДАКТИРОВАТЬ: Поскольку многие пользователи считают, что пункты списка ничего не прояснили, я дам краткое текстовое описание концепции отношения:

  • Один клиент может отдать один или несколько проектов
  • Один проект может быть предоставлен ОДНИМ КЛИЕНТОМ
  • Каждый проект может быть завершен одним или несколькими разработчиками
  • Каждый разработчик может работать над несколькими проектами (независимо от заказчика, которым был передан проект)

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


database relational-database database-design cardinality entity-relationship
person Infecto    schedule 09.11.2017    source источник
comment
Я не уверен, что ваш комментарий говорит то же самое, что и диаграмма, с точки зрения мощностей. Каждый Проект контролируется/принадлежит одному Заказчику? Возможно ли, что один и тот же разработчик может работать над несколькими проектами для нескольких клиентов?   -  person AntC    schedule 10.11.2017
comment
Пожалуйста, всегда используйте текст, когда можете, и изображения/диаграммы только дополнительно. Здесь вы должны указать DDL, и диаграмма избыточна.   -  person philipxy    schedule 10.11.2017
comment
До сих пор неясно, какое отношение/предикат имеет каждое ограничение кардинальности здесь или в вашем ответе; вы не даете определяющих предикатов для них или назначений, и хотя новые маркеры лучше, вы не полностью используете ясный язык из моего ответа относительно количества данного атрибута / подкортежа: количество подкортежей всех остальных. Вы все еще путаете предикаты отношений и ограничения — вы даете ограничения, но не предикаты — какие отношения имеют эти ограничения. Задайте отношения/предикаты, а затем задайте любые ограничения количества элементов для каждого из них.   -  person philipxy    schedule 20.04.2020

Ответы (3)


arrow_upward
2
arrow_downward

КОМБИНАЦИЯ этих трех вещей УНИКАЛЬНА. Это означает, что у меня может быть тот же ProjectID с тем же EmployeeID, но с другим CustomerID (чего я не хочу).

Уникальность триплетов не означает, что триплеты могут быть уникальными в то же время, когда отсутствуют определенные комбинации строк. С другой стороны, это не навязывает их отсутствие. Но существуют ограничения кардинальности. Они говорят то же, что и пули (пытаются) сказать: могут возникнуть только определенные ситуации/состояния. Маркеры не являются не тем, "что говорит взаимосвязь" — либо в смысле того, какие строки фактически формируют взаимосвязь/таблицу в данной ситуации/состоянии, либо в смысле того, что строка говорит о ситуации. когда он находится в отношениях/таблице.

На диаграмме такого типа ромб обозначает n-арное деловое или прикладное отношение (корабль) или ассоциацию и соответствующую ему таблицу. Линия на такой диаграмме представляет собой участие типа объекта и его соответствующего FK (внешнего ключа) (к сожалению, в методах псевдо-ER это называется «отношением»). Ограничение — это ограничение на то, какие экземпляры/строки могут появляться в отношения / таблица. Каждый экземпляр/строка в отношении/таблице «говорит», что эта строка значений удовлетворяет отношению. Ограничения «говорят», что существуют ограничения на то, какие значения могут быть связаны во всех ситуациях/состояниях. Кардиналы — это ограничения, которые что-то говорят о том, сколько раз значения и/или комбинации значений могут встречаться в отношении.

Существует два основных правила кардинальности: просмотр и просмотр здесь. При просмотре число/диапазон говорит, сколько сущностей того типа, к которому оно относится, может участвовать в одной подстроке сущностей других типов, т. е. сколько раз одна подстрока других может участвовать/быть в отношении/ Таблица. (Первоначальное значение ER Чена.) Здесь число/диапазон говорит о том, сколько подстрок других типов объектов может появиться с объектом того типа, к которому он относится, т. е. сколько раз ближайший объект может участвовать/быть в отношениях. /Таблица. (Посмотрите-здесь не очень полезно для отношений с арностью> 2.)

У нас есть тройное отношение, и оно говорит следующее:

Ромб отношения говорит о том, что вы записываете строки (EmployeeID, CustomerID, ProjectID), где (что-то вроде) разработчик EmployeeID назначается заказчиком CustomerID проекту ProjectID. О чем говорит количество элементов, так это о том, что только определенные наборы экземпляров/строк могут удовлетворить этим отношениям в любой данной ситуации/состоянии.

  • 1 клиент дает 1 проект -> нескольким разработчикам
  • 1 Заказчик назначает 1 разработчика с -> несколькими проектами
  • 1 разработчик назначает 1 проект -> ОДИН клиент

Ваши отмеченные ограничения не ясны. Числа были застряли перед типами сущностей — почти так же, как можно было бы вставить значения идентификатора, чтобы получить то, что говорит эта строка значений идентификатора, когда находится в отношении/таблице, — но произведенные почти предложения, которые также имеют необъяснимые стрелки, < em>ничего не значит. Может быть, вы пытаетесь сказать, что для данного значения подстроки клиент-проект может быть несколько значений разработчика и т. д.? Это дало бы сквозную мощность на диаграмме. Но вы этого не сказали.

person philipxy    schedule 10.11.2017

arrow_upward
1
arrow_downward

Когда троичные отношения выражаются в реляционной модели, каждый из наборов сущностей с индикатором кардинальности «многие» становится частью первичного ключа. Другими словами, я понимаю, что ваши отношения выражают функциональную зависимость (EmployeeID, ProjectID) -> CustomerID, которая физически будет представлена ​​как Assignment (EmployeeID PK/FK, ProjectID PK/FK, CustomerID FK).

person reaanb    schedule 09.11.2017
comment
Хм, я не уверен, что вопрос хорошо сформулирован. Я согласен с тем, что, поскольку CustomerID не имеет множества элементов, он не должен быть (частью) какого-либо ключа. Я думаю, что каждый проект принадлежит только одному заказчику (? Нигде не сказано, что несколько заказчиков назначают данный проект.) Над данным проектом могут работать несколько разработчиков. Или разработчик может работать над несколькими проектами (и, следовательно, над несколькими клиентами). У меня было бы два отношения: Assignment (ProjectID, CustomerID) с ключом ProjectID; Ключ WorksOn(DeveloperID, ProjectID) - это все атрибуты. - person AntC; 10.11.2017

arrow_upward
0
arrow_downward

Как я уже упоминал в вопросе, в первую очередь, описание отношения следующее:

  • Один клиент может отдать один или несколько проектов
  • Один проект может быть предоставлен ОДНИМ ОДНИМ ЗАКАЗЧИКОМ
  • Каждый проект может быть завершен одним или несколькими разработчиками
  • Каждый разработчик может работать над несколькими проектами (независимо от заказчика, которым был передан проект)

Проблема в самой ER-диаграмме: она не совсем соответствует приведенному выше описанию. Проблема заключается в том ограничении, что один проект может быть предоставлен одним заказчиком. Вот почему было бы разумнее смоделировать это с двумя отдельными бинарными отношениями, а не с использованием троичного.

При этом отношение между Заказчиком и Проектом должно быть отношением 1:n, а отношение между Проектом и Разработчиком< /em> должно быть отношение am:n. Отображение этих отношений дает нам следующее:

  • Customer(CustomerID) с первичным ключом=CustomerID
  • Проект (ProjectID, CustomerID) с первичным ключом=CustomerID и внешним ключом=CustomerID, ссылающимся на клиента
  • Разработчик (ID разработчика) с PK = ID разработчика
  • ProjectDevelopment (ProjectID, DeveloperID) с PK={ProjectID, DeveloperID)
person Infecto    schedule 10.11.2017