Преобразование отношений n в m со специализацией в реляционную модель

Я нахожу лучший способ преобразовать диаграмму eer в соответствующую реляционную диаграмму. У меня есть объект обобщения с некоторыми специализациями, которые имеют отдельные отношения с другими объектами. Сущность обобщения, в свою очередь, имеет отношения n-to-m с сущностью. Следующий рисунок поясняет ситуацию: Eer-диаграмма со специализацией и отношением n-to-m.

Поскольку у двух специализированных объектов разные отношения, я должен преобразовать их в две отдельные таблицы. Тем временем я должен создать таблицу, моделирующую отношения n-to-m, которая связывает объект «Пользователь» с объектом «Информационный бюллетень» (или, лучше, его специализации). Как справиться с этой проблемой? Я не нашел никакой полезной информации.

Единственное возможное решение, о котором я подумал, состояло в том, чтобы создать две отдельные таблицы, моделирующие отношение n-to-m, одну из которых можно связать с таблицами «Пользователь» и «Информационный бюллетень по программированию», а другую — с таблицами «Пользователь» и «Информационный бюллетень о путешествиях». Но я ищу мнения для этого.


relational-database entity-relationship relational-model entity-relationship-model
person Andrea Camisa    schedule 14.02.2016    source источник

Ответы (2)


arrow_upward
2
arrow_downward

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

User (nickname PK, name, address)
Newsletter (name PK, supervisor, type)
Subscription (user_nickname PK/FK, newsletter_name PK/FK)
Programming_Newsletter (newsletter_name PK/FK, type FK, language)
Travel_Newsletter (newsletter_name PK/FK, type FK, means_of_transport)

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

person reaanb    schedule 15.02.2016

arrow_upward
1
arrow_downward

Я думаю, что есть несколько способов сделать это.

Самым простым было бы разрушить предположение: «Поскольку два специализированных объекта имеют отдельные отношения, я должен преобразовать их в две отдельные таблицы». Если вы храните свои специализации вместе в одной таблице, вы можете использовать STI (наследование одной таблицы) для вашего обобщения. Однако у этого подхода есть недостаток, заключающийся в том, что в вашей таблице будет много значений NULL для тех отношений, которые не относятся к конкретной специализации.

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

Я не совсем вижу проблему в отношениях n-to-m между пользователем и информационным бюллетенем. У вас должна быть обычная промежуточная таблица, которая создает связь между ними, поскольку нет дополнительных атрибутов, дополняющих эту связь.

person hasumedic    schedule 14.02.2016
comment
Почему вы должны присоединяться к таблице супертипов почти для каждого запроса, включающего подтипы? Если вам не нужен супервайзер, нет необходимости присоединяться к этому столу. - person reaanb; 15.02.2016
comment
Если у супертипа есть общие атрибуты для его подтипов (что вполне нормально), вам нужно присоединиться к этой таблице, чтобы вы могли получить к ним доступ для формирования полноценного объекта. - person hasumedic; 15.02.2016
comment
Спасибо за разъяснения. Поскольку я разбиваю свои системы на SQL-ориентированные сервисные объекты, а не на объекты предметной области, получение полноценных объектов из БД никогда не вызывает беспокойства. - person reaanb; 15.02.2016
comment
Спасибо за ответы. Я высоко оценил как хасумедический, так и рациональный подходы. Мне было интересно, можно ли реализовать эту диаграмму eer с архитектурой таблицы для специализированного класса без таблицы для суперкласса. Можете ли вы рассказать мне что-нибудь об этом? - person Andrea Camisa; 15.02.2016
comment
Это предложение @reaanb. Единственным предостережением будет то, что общие поля в каждом информационном бюллетене создадут некоторую избыточность. Если вас это не беспокоит, и ваша модель довольно стабильна (вы не будете часто добавлять/удалять типы информационных бюллетеней), этот подход должен работать. Если это неопределенно и может часто меняться, я бы использовал STI. - person hasumedic; 15.02.2016
comment
@hasumedic Нет, это не мое предложение. Проверьте мой ответ, я включил таблицу супертипов, которая требуется как минимум для ограничений внешнего ключа. - person reaanb; 15.02.2016
comment
Я решил свою проблему (на самом деле я сделал, как предложил reaanb), но на самом деле не было предоставлено ответа на исходный вопрос, то есть как преобразовать эту диаграмму eer в соответствующую реляционную модель с отдельными таблицами для подклассов и без таблицы для основного объекта . - person Andrea Camisa; 20.02.2016