Перевод атрибутов отношения из диаграммы ER в SQL

Question

В настоящее время вы пытаетесь впервые получить доступ к SQL, поэтому я работаю с несколькими проблемами. Вот пример базы данных:

Студенты (имя, пол, курс) выполняют проекты (название). Каждый проект имеет двух надзирателей (имя, пол, отдел). Все учащиеся выполняют проект , но не все проекты принимаются. Более одного студента могут выполнить тот же проект . Студенты регулярно встречаются с одним из своих надзирателей, и эти записи записываются (дата, время, студент, руководитель, заметки).

До сих пор у меня есть схема ER разработан, который я считаю правильным:

я могу получить основы (например, создание таблицы для студентов и т.д.), но у меня проблемы с тем, как представлять отношения, в частности отношения с собраниями, и как представлять его и его атрибуты в SQL. Должен ли я вместо этого создать «собрание»?

Answer 1

Да, вы должны создать объект Meeting, чтобы представить отношение многих ко многим между Student и Supervisor. В нем вы можете ссылаться на эти таблицы, используя внешние ключи, соответствующие этим соответствующим таблицам. В SQL может выглядеть следующим образом:

Create table Meeting { 
id INT NOT NULL PRIMARY KEY AUTO_INCREMENT, 
student_id INT NOT NULL, 
supervisor_id INT NOT NULL, 
//rest of the fields... 
FOREIGN KEY (student_id) REFERENCES Student(id) 
FOREIGN KEY (supervisor_id) REFERENCES Supervisor(id) 
} 

Вы также сделать то же самое для Supervise между Project и Supervisor. Кроме того, вы можете использовать что-то, называемое составным ключом на вашей таблице собраний, я предполагаю, что это сводится к личным предпочтениям, я обычно делаю это таким образом, когда представляю много-много отношений. Я не говорю, что это синтаксис, который вы будете использовать, что зависит от вашей базы данных, это был всего лишь пример, указывающий на то, что вы в правильном направлении. Надеюсь, поможет.

Также для вашей диаграммы (я просто догадываюсь, что это для класса) вы можете захотеть заглянуть в программное обеспечение, такое как визуальная или визуальная парадигма, чтобы создать свою диаграмму ER. Хотя большинство людей смогут понять вашу текущую диаграмму, это неправильное моделирование.

Для удовольствия я сделал схему на основе таблиц:

Вы хотели бы объект между Supervisor и Project, если они являются отношения многие ко многим. Это называется associative entity. Я назвал мой SupervisorProject, так что они немного понятнее.

Редактировать С видом на то, что Студент и проект были от многих до одного, исправили это, извините.

Answer 2

В ответ на Cohagen this stackoverflow post показано, что многие из многих отношений, например Supervise, могут быть представлены путем хранения таблицы отношений, даже если у нее нет атрибутов. Напротив, таблица Do лежит между отношением «много к одному» и не имеет атрибутов, поэтому мы можем избавиться от нее и просто добавить ссылку на внешний ключ в таблицу проекта у студентов.