Должен ли студент быть слабым сущностью в СУБД?

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

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

источник

2017-02-23 Ahmed Jamil

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

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

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

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

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

Edit:

Вот пример того, как представить Grades как отношения между Student и Courses. Я использовал оригинальную запись ER, так как у меня нет инструмента, который реализует ваши обозначения.

источник

2017-02-23 05:53:44 reaanb

Да, я знаю, что я использовал несогласованную нотацию ради меня только извините за это, и я также знаю, что N: M требует другую таблицу, которую я нарисую после того, как я очистил свои недоумения. Я хотел бы знать, что, как вы сказали, я согласен с тем, что УЧАСТНИКИ И ГРАДЫ должны быть вместе с СТУДЕНТОМ И КУРСОМ, но я не могу представить его и как должна быть диаграмма, как я могу их повторить. Куда и к чему я должен подключиться, с какой реализацией. –

Я добавил пример, надеюсь, что это поможет. – reaanb

Спасибо, это очень помогло! Был надеяться увидеть этот ответ. –

Участники таблицы должны быть связаны с курса и студент не отдела, как показано на рисунке.

источник

2017-02-23 07:25:31 Ezani

Можете ли вы подробно рассказать о том, как я могу разместить посещаемость между курсом и учениками, когда они уже связаны. Я не вижу визуальных троичных или n-арных отношений. –

Если вы думаете об этом, студенты посещают курсы. На самом деле было бы лучше иметь другую таблицу, класс, в которой курс и класс имеют отношения «один ко многим». Например, для прохождения курса студенту приходилось посещать минимальное количество классов. Конечно, у курса было бы много отношений с Департаментом. Итак, в двух словах, «Посещение -> Класс -> курс -> Отдел – Ezani

Должен ли студент быть слабым сущностью в СУБД?

ответ

Смежные вопросы