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

Question

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

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

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

Answer 1

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

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

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

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

Answer 2

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

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) 

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