Слабая сущность в ERD

Question

У меня есть следующая проблема, что у меня есть несколько сценариев, которые могут быть правильными или неправильными, я искал это некоторое время, и я не нашел конкретного ответа на мою проблему:

Доктор Клиника Пример:

У нас есть врач, пациент, лечение, тип лечения

Доктор: идентификатор, имя....

Пациент: идентификатор, имя...

Лечение: дата, стоимость

Лечение-Тип: id, имя

Врач может проводить несколько процедур, а пациент также может проводить несколько процедур, поэтому они связаны с лечением отношениями (1-N).

Объект лечения является слабым объектом, так как его нельзя определить в отсутствие доктора или пациента, поэтому мой вопрос заключается в том, когда мы конвертируем эту ERD в фактические таблицы, что является правильным (или оптимальным) сценарием?

1 - идентификатор доктора, идентификатор пациента не может однозначно определить таблицу "Лечение", поэтому мы добавляем в таблицу " Лечение" поле идентификатора процедуры, а в поле "PK" (идентификатор доктора, идентификатор пациента, идентификатор процедуры).

2 - Мы добавляем поле идентификатора обработки, а PK - это (идентификатор обработки).

3 - ПК будет (идентификатор врача, идентификатор пациента, дата).

Я изо всех сил пытался найти, может ли 'date' быть частью PK, или нет, а также я пытался создать уникальный идентификатор для слабой сущности.

Заранее спасибо.

Answer 1

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

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

Следует также отметить, что для слабых наборов сущностей может быть установлен только один родительский объект в соответствии с моделью отношения сущностей, как это описал Чен. Будучи идентифицированным множеством родительских наборов сущностей, он станет связью, а не набором сущностей.

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

Давайте посмотрим на ваши примеры:

В примере 1 мы должны рассмотреть, treatment-id идентифицирует сам по себе (т.е. суррогатный ключ) или только в сочетании с doctor-id а также patient-id (т.е. порядковый номер). Если это суррогатный ключ, было бы ошибкой включать doctor-id а также patient-id в PK пример 2 был бы правильным способом справиться с этим. Если это порядковый номер, то он в основном такой же, как в примере 3 - два ключа внешней сущности и значение, установленное в первичном ключе. Об этом я расскажу в комментариях к примеру 3.

В примере 2 treatment-id это суррогатный ключ, который означает Treatment является регулярным набором сущностей, который полностью участвует в его отношениях с Patient а также Doctor, Это было бы моим рекомендуемым решением, так как это самое простое.

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

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

Вернемся к примеру 3, несмотря на недостатки модели ER, создание такой таблицы / отношения в реальной базе данных не является недействительным. Однако подумайте о том, что означает первичный ключ - может ли пациент получать только одно лечение в день от одного и того же врача? Я думаю, что несколько вариантов лечения могут быть возможны, и в этом случае вам может понадобиться добавить еще один порядковый номер, например (doctor-id, patient-id, date, treatment-id), В этом случае может быть проще сделать (doctor-id, patient-id, treatment-id),

Один из аргументов против таких составных / естественных ключей заключается в том, что они складываются - ассоциация "многие ко многим" между двумя отношениями, каждое из которых имеет 3 столбца в своих первичных ключах, может иметь до 6 столбцов в своем первичном ключе! Это быстро становится неудобным, но, с другой стороны, эти столбцы являются релевантной связанной информацией, которую в противном случае пришлось бы извлекать из соединенных таблиц, если связь была идентифицирована суррогатным ключом.

Извините за длинный ответ, но я надеюсь, что это охватывает все тонкости. Дайте знать, если у вас появятся вопросы.