Сколько таблиц будет иметь реляционная схема для этой ER-диаграммы?

Question

У меня есть следующая диаграмма ER. Я все еще изучаю СУБД и пытаюсь перевести эту диаграмму ER в реляционную схему. Я знаю, что каждый объект на диаграмме ER будет иметь отдельную таблицу. Однако я не уверен, что делать с отношениями для этой конкретной диаграммы ER. Нам сказали, что каждая взаимосвязь между сущностями также будет иметь таблицу. Поэтому мне нужно сделать отдельный для отношений на этой диаграмме ER? Но нет никаких атрибутов отношений. Кроме того, у меня есть путаница в каких отношениях это именно так? Это один ко многим?

У меня есть ссылка на картинку диаграммы ER. Пожалуйста, направляйте меня в правильном направлении. Благодаря!

Answer 1

Ваша диаграмма не является диаграммой ER в исходном смысле этого термина. В модели сущности-отношения отношения являются ассоциациями между наборами объектов и предназначены для реализации в виде таблиц. Например, ваши таблицы AUTHOR_BOOK, CAST и PURCHASE представляют собой таблицы отношений, которые связывают два набора сущностей каждый (имейте в виду, что отношения не ограничиваются двумя наборами объектов). Обратите внимание, как отношения представлены с использованием ключей наборов сущностей, например. (actorID, inventID). Та же картина может быть найдена в некоторых ваших других таблицах, то есть (inventID, publisher), (inventID, director), (inventoryID, genre), (inventoryID, supplier), (receiptID, inventID) и (receiptID, customerID). Это ваши отношения, а не линии пещеры, которые являются лишь внешними ограничениями. В оригинальной нотации Чэна отношения будут указаны с использованием алмазных форм между ними и связаны с двумя типами сущностей. Кроме того, Чэнь сделал бы отдельную таблицу отношений (aka junction table) для каждого из этих отношений.

В вашей табличной таблице показано 14 таблиц. Следуя методу Чена, было бы 19 столов:

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

Но нет никаких атрибутов отношений.

Неправильное использование. Ваше отношение Purchase показывает два атрибута - quantity и amountPaid. Обратите внимание: атрибут - это сопоставление от объекта или отношения, установленного к значению. Таким образом, я не считаю ключи сущностей атрибутами отношения. Я также смоделировал BookpubYear как атрибут отношения между Book и Publisher.

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