Tłumaczenie atrybutów relacji z diagramu ER na SQL

Tak, powinieneś utworzyć Meeting podmiot reprezentujący relację wiele do wielu między Student i Supervisor . W nim możesz odnosić się do tych tabel za pomocą kluczy obcych, które odpowiadają tym odpowiednim tabelom. W SQL może to wyglądać mniej więcej tak:

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)
}

Zrobiłbyś to samo dla Supervise między Project i Supervisor . Możesz również użyć czegoś, co nazywa się kluczem złożonym na swoim stole Spotkanie, myślę, że sprowadza się to do osobistych preferencji, zwykle robię to w ten sposób, gdy reprezentuję wiele do wielu relacji. Nie mówię, że jest to składnia, której będziesz używać, która zależy od twojej bazy danych, to był tylko przykład wskazujący właściwy kierunek. Mam nadzieję, że to pomoże.

Również w przypadku diagramu (zgaduję, że dotyczy to klasy) możesz chcieć zajrzeć do oprogramowania, takiego jak visio lub wizualny paradygmat, aby utworzyć diagram ER. Chociaż większość ludzi będzie w stanie zrozumieć Twój obecny diagram, nie jest to poprawne modelowanie.

Dla zabawy wykonałem schemat na podstawie Waszych tabel:

Chciałbyś podmiot pomiędzy Supervisor i Project jeśli są w relacji wiele do wielu. To się nazywa associative entity . Mój projekt oznaczyłem jako SupervisorProject tylko po to, aby były trochę bardziej przejrzyste.

Edytuj Pominąłem fakt, że Student i projekt były jak wiele do jednego, naprawiłem to, przepraszam.