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

Question

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

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

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

Answer 1

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

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)

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

Answer 2

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

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

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

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