Правильно ли построена ER диаграмма?

Question

[enot_13]

Возник вопрос, правильно ли построена ER диаграмма (нужна для диплома)? Суть в том что мой куратор сказал что она цикличная (круговая) и что это неправильно. При этом я не считаю что она циклична (по логике.)
Сама структура бд:
Таблица пользователей, содержащая информацию о пользователе.
Таблица организаторов, содержащая информацию об организаторе. При этом данная таблица ссылается на таблицу пользователей, так как пользователь если захочет может стать организатором (Organizator_id = user_ID (они равны, то есть когда пользователь хочет стать организатором, в таблицу организаторов добавляется запись об этом, но organizator_id не типа serial, а равный user_id). Объединять не хочу, потому что на мой взгляд эти таблицы могут быть с большим объемом информации и тогда можно запутаться, поэтому я их разделила.
Таблица мероприятия, содержащая всю информацию о мероприятии.
Таблица участия пользователей, содержащие user_ID и event_ID (То есть на какие мероприятия пользователь записался или уже посетил).
Таблица созданных мероприятий организаторами, содержащая organizator_id и event_id (То есть какие мероприятия какой пользователь создал).
P.s к названиям таблиц и столбцов, пожалуйста, не придирайтесь, я и так знаю что не всё корректно (первый большой опыт).
Помогите понять как правильно.

Comments

[Akina]

Возник вопрос, правильно ли построена ER диаграмма

ER-диаграмма - это следствие из анализа предметной области. Сам анализ - отсутствует... ну и как мы должны определять, правильно выполнено отображение или нет, на основании каких данных?

[enot_13]

Akina, добрый день! Простите, не совсем понимаю вопрос. У меня в postgresql создана бд и там есть возможность автоматического построения ER диаграммы.
А если вы про суть самой системы для чего бд, то сайт для организации мероприятий (лекции, вебинары, мастер-классы разного направления). Есть пользователи, это просто участники, они записываются на мероприятия и все. Они по желанию могут стать организатором, для этого надо заполнить форму и отправить админу сайта, который одобряет или отклоняет. Только организаторы могут создавать мероприятия. После создания мероприятие попадает на проверку админу и он также одобряет или отклоняет.

[Akina]

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

Вы же сделали всё в обратном порядке. Посему ожидать правильного результата бессмысленно. И попытки исправить ситуацию заплатками, скорее всего, ничего не исправят.

[enot_13]

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

Answer 1

[Rsa97]

Никакой цикличности здесь нет - users и events не ссылаются на другие таблицы.
Есть только пара вопросов.
1. Зачем в таблице organizators поле is_organizer? В ней может быть кто-то кроме организаторов?
2. Зачем нужно поле organizer в таблице events? У вас есть таблица связи, которая позволяет получить всех организаторов мероприятия.
3. Предполагается ли, что у события может быть несколько организаторов? Если нет, то таблица связи не нужна, нужно поле в таблице событий.

Comments

[Akina]

В дополнение.

Что есть organizators.name? Оно что, не связано с users.(firstname + lastname)?
Зачем organizators.email? Оно что, отличается от users.email?
Почему phone_number - не в users?
Я вижу events.is_repeated. Соответственно допускаю, что у очередного event может измениться organizer. То есть вы упираетесь в pattern/entiy.

[enot_13]

Akina, добрый день, спасибо за дополнение!
1) organizatir.name это название организации, его надо переименовать может в title, я не знаю, и оно не связано с фамилией или именем пользователя.
2) email организатора и пользователя может отличаться, и номер есть только у организатора.
3) is_repeated данное поле служит для мероприятий, которые были отменены по какой-то причине, но затем внесли изменения и отправили на повторное подтверждение, то есть повторно (на сайте модерация мероприятий)

[enot_13]

Rsa97, добрый день! Спасибо за ответ!
1) в таблице organizations поле is_organizer имеет некорректное название, оно должно быть is_approved, то есть организатору надо получить одобрение на становление организатором, а поле is_active отвечает за активность организатора, то есть с него могут снять права и он не сможет создавать мероприятия, но есть возможность просматривать свои предыдущие мероприятия.
2) поле organizer косяк, оно осталось еще от того варианта когда не было таблице организаторов, его удалю.
3) у мероприятия может быть только один организатор.

[Rsa97]

enot_13,
3) Тогда таблица связи не нужна, достаточно поля organizator_id в таблице events.

[enot_13]

Rsa97, спасибо за комментарий. Есть ли еще что нужно исправить?

[Rsa97]

enot_13, В остальном надо знать предметную область и задачу, чтобы что-то советовать.
Разве что можно найти другой редактор диаграмм, который показывает связи не просто между таблицами, а между конкретными полями.