Выражение «многие ко многим», то есть «многие к одному» по отношению к данному атрибуту - PullRequest
0 голосов
/ 30 мая 2018

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

Я подумал об одном решении, но мне не нравится, что оно искусственное и не может выразить его в ERD.Решение состоит в том, чтобы включить специализацию доктора в ключ в таблице «Врачи».Затем ключ таблицы, выражающий отношения между пациентами и врачами, должен состоять только из идентификатора пациента и специализации врача (но не идентификатора врача, который используется только как часть внешнего ключа таблицы Doctors).Опять же, я ищу более естественное решение, которое можно выразить в ERD.

1 Ответ

0 голосов
/ 31 мая 2018

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

Если вы заинтересованы в нотации для выражения бизнес-правил, тогда посмотритев Object Role Modeling , что гораздо точнее и выразительнее, чем ERD.

SQL также не очень хорош в реализации ограничений взаимосвязи.В качестве примера того, насколько легко это может быть в RDBMS, приведена возможная реализация реляционной базы данных с использованием языка Tutorial D.Требуемое ограничение реализуется с помощью ключа {patno, spec} в виртуальном отношении (view) с именем Patient_doc_spec.

VAR doctor REAL RELATION {doc CHARACTER, spec CHARACTER} KEY {doc};
VAR patient REAL RELATION {patno CHARACTER} KEY {patno};
VAR patient_doc REAL RELATION {patno CHARACTER, doc CHARACTER} KEY {patno,doc};
VAR patient_doc_spec VIRTUAL (patient_doc{patno,doc} JOIN doctor {doc,spec}) KEY {patno, spec};
...