Кардинальность рекурсивных отношений?
Я создал базу данных для вычислений в школах (CIS), и у меня есть некоторые дополнительные требования, чтобы добавить из приведенной ниже информации. Я создал ERD, но чувствую, что сделал несколько ошибок, таких как кардинальность рекурсивных отношений?
Любые другие отзывы будут оценены.
Новые требования CiS хотел бы использовать базу данных для обмена информацией о сессиях, участниках и т. Д. В режиме онлайн через веб-сайт. Любой участвующий участник - ученик-волонтер, школьный персонал, преподаватели SHU - сможет войти в систему с помощью имени пользователя (или, возможно, адреса электронной почты) и пароля. После входа в систему участники используют сайт по-разному (школьный персонал запрашивает сессии, лекторы SHU управляют ими, а учащиеся-волонтеры видят, в чем они могут принять участие, подтверждают свою доступность и после этого проверяют, что часы подходят). CiS хочет иметь возможность делиться ресурсами через сайт. Ресурсы - это файлы, которые полезны в сеансах или, как правило, для целей CiS. Пользователи, которые создают такие файлы, загружают их, и в базе данных хранятся такие сведения, как URL, заголовок файла, описание и отслеживание автора файла. Участники могут загружать файлы, участники могут отмечать их, давать им звездный рейтинг и комментировать их.
• Теги - это ключевые слова, которые пользователи назначают файлу. Файл может иметь несколько тегов; После того, как кто-то пометил файл ключевым словом, больше не нужно, чтобы кто-то помечал этот же файл тем же ключевым словом еще раз.
• Звездный рейтинг. Любой участник сайта может оценивать любой файл, но не может повторно оценивать файл, который он оценил.
• Комментарии не имеют таких ограничений, поскольку в конечном итоге они формируют обсуждение каждого файла, поэтому участники сайта могут написать множество комментариев о файлах. Будет полезно узнать дату, автора и тему каждого комментария к файлу.
1 ответ
Ваша диаграмма не является ERD. В частности, использование линий для представления отношений ограничивает вас бинарными отношениями и в значительной степени утрачивает выразительную силу модели Entity-Relationship.
Используя комбинацию Username
а также Password
в качестве первичных ключей в ваших таблицах пользователей, вы допускаете возможность того, что разные пользователи могут использовать один и тот же Username
с разными паролями. Это то, что вы хотите? Однако в Upload file
таблица, вы храните только Author_username
так что, возможно, вы хотите только Username
как ключ? Вы должны быть последовательны здесь.
Ваш Uploaded file
Стол нужно разбить на множество. На данный момент он поддерживает только один тег, один рейтинг и один комментарий на файл / имя пользователя. Не ясно, является ли Author_username
указывает на пользователя, который загрузил файл, или на пользователя, который отметил, оценил и прокомментировал файл. Кстати, эти вещи связаны между собой в вашей таблице, не позволяя пользователю публиковать больше тегов или комментариев, чем оценок. File title
а также File description
вероятно зависят только от File URL
и будет дублироваться, если будет сохранено несколько тегов, оценок или комментариев, что приведет к риску несогласованности.
Редактировать:
Поскольку вы попросили рекомендации в своем комментарии, я предлагаю:
- Используйте обозначение Чена ERD или, по крайней мере, вариант, который использует формы для представления отношений и поддерживает троичные и более высокие отношения. Еще лучшим подходом было бы объектно-ролевое моделирование.
- Использовать только
Username
в качестве первичного ключа для ваших 4 пользовательских таблиц. Трещина
Uploaded file
в следующие таблицы:Uploaded file (File_URL PK, File_title, File_description, Username FK)
File_tags (File_URL PK/FK, Tag PK)
File_ratings (File_URL PK/FK, Username PK/FK, Rating)
File_comments (Comment_ID PK, File_URL FK, Username FK, Comment, Created_at, Reply_to_comment_ID FK)
Обратите внимание, что это лишь минимальный набор изменений для решения поставленных мною вопросов, предназначенных для образовательных целей, а не обязательно для правильного решения ваших требований.