2017-02-23 75 views
0

У меня есть следующая база данных проекта студенческого портала, который я создаю. Я новичок в базах данных, но я знаю понятия довольно много. Я не хотел просить, чтобы на моей диаграмме ученик был слабым лицом, поскольку это зависит от отдела. Если нет отдела, в этом отделе не будет студента.Должен ли студент быть слабым сущностью в СУБД?

Помимо моего основного вопроса, я немного смущен о таблице УЧАСТНИКОВ И ГРАД. Я правильно их связал и насколько они достаточны и правильны? Я знаю, что много задаю, но вы можете просмотреть мою диаграмму и дать мне предложение улучшить ее, даже если это нужно, чтобы сделать ее с нуля. Спасибо.

Student Portal Database Design

ответ

2

Студент не должен быть слабым набор сущностей. В то время как слабые сущности-объекты подразумевают зависимость существования, зависимости существования не подразумевают слабые сущности. Общее участие возможно и для обычных сущностей.

Вместо того, чтобы смотреть на зависимости существования, посмотрите на идентификацию. Слабые сущностные наборы не могут быть идентифицированы только по их собственным атрибутам, они зависят от внешнего ключа (обычно в сочетании со слабым ключом) для идентификации. Когда набор объектов имеет независимый идентификатор, такой как Roll ID (суррогатные идентификаторы всегда независимы), они являются регулярными объектами.

Вы, кажется, путаете сущности с таблицами, возможно, из-за смешанной нотации, которую вы используете. Если я правильно прочитал вашу модель, Grades - это отношения между Student и Courses, так как в нем есть первичный ключ, состоящий из двух внешних ключей. Однако ваша диаграмма связывает ее только с Student через ненужные отношения has.

У вас также есть встроенные отношения в ваших таблицах, например. Courses имеет Department FK, но вы не связывали их на диаграмме. Enrolls требует свой собственный стол, но вы не показываете его в отличие от других отношений «многие ко многим» на вашей диаграмме.

Attendance, как Grades, представляет собой взаимосвязь между Student и Courses. Вы показываете связь с Department, но не указываете FK. Хотя в оригина