0
Как я представляю, как диаграммы, в базе данных отношений (например, MySQL) случай, в котором:базы данных отношений, многие ко многим
1) один пользователь может быть организатором различных мероприятий
2) событие может иметь только один организатор
3) и событие может иметь большое количество участников (которые все между пользователями таблицы)
4) пользователь может участвовать многие события (только если событие не вступает в противоречие с другим событием от начала до конца)
вот эскиз БД, я должен это понять многие ко многим отношения. 
Думаю, у вас почти есть. Я бы предложил, чтобы таблица Events_has_Users была переименована в Users_Attending_Events. Также в этой таблице основным ключом будут как Users_UserId, так и Events_EventsId. Для этого не требуется Организатор событий, так как это определено в таблице событий как внешний ключ (Организатор). Таблица Events_has_Users размещена там, чтобы разрешить отношения «многие-ко-многим» между пользователями и событиями. Многие пользователи посещают множество событий. Я думаю, что он автоматически отображается в mysql-workbench (т. Е. Разрешает это отношение «многие ко многим» с таблицей между ними. – barudo
Хорошо, спасибо, но все же некоторые ошибки, таблица События не должны содержать Организатор в качестве первичного ключа и как это сделать рассмотрите тот факт, что Пользователь может посещать многие события, а события могут посещать многие пользователи, поскольку таблица событий не имеет уникального первичного ключа? – mattobob
Ах, возможно, я получил его как Events_eventID, так и Users_userID - первичный ключ таблицы Events_has_User, правильно? – mattobob