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

Question

Obecnie próbuję po raz pierwszy poradzić sobie z SQL, więc pracuję nad kilkoma problemami. Oto przykładowa specyfikacja bazy danych:

Studenci (imię, płeć, kurs) robią projekty (tytuł). Każdy projekt ma dwóch przełożonych (imię, płeć, dział). Wszyscy studenci wykonują projekt , ale nie wszystkie projekty zostają wykonane. Więcej niż jeden uczeń może wykonać ten sam projekt . Uczniowie spotykają się regularnie ze swoim przełożonym, a spotkania są rejestrowane (data, godzina, student, kierownik, notatki).

Dotychczas Mam diagram ER sporządzać co moim zdaniem jest poprawne:

mogę podstaw (np tworzenia tabeli Student itp) ale mam kłopot z myśleniem o tym, jak reprezentować relacje, a konkretnie o relacjach spotkań i jak go reprezentować oraz o jego atrybutach w SQL. Czy zamiast tego powinienem utworzyć encję "spotkania"?

Answer 1

Tak, powinieneś utworzyć jednostkę Meeting, aby reprezentować wiele do wielu relacji między Student i Supervisor. Można w nim odnosić się do tych tabel za pomocą kluczy obcych, które odpowiadają tym tabelom. W SQL może 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) 
} 

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

Również dla twojego diagramu (domyślam się, że to jest dla klasy) możesz chcieć zajrzeć do oprogramowania takiego jak visio lub wizualny paradygmat, aby stworzyć swój diagram ER. Podczas gdy większość ludzi będzie w stanie zrozumieć twój obecny diagram, to nie jest poprawne modelowanie.

Dla zabawy zrobiłem schemat na podstawie tabel:

co chcesz podmiot między Supervisor i Project jeśli są one wiele do wielu relacji. Nazywa się to associative entity. Oznaczałem moją kopalnię SupervisorProject tylko dlatego, że są trochę bardziej przejrzyste.

EdytujPrzeoczyłem fakt, że Uczeń i projekt to wielu, naprawili, przepraszam.

Answer 2

W odpowiedzi na Cohagena this stackoverflow post sugeruje, że wiele do wielu relacji, takich jak Supervise, można przedstawić, zachowując tabelę relacji, nawet jeśli nie ma ona atrybutów. W przeciwieństwie do tabeli Do leży ona między relacjami wiele do jednego i nie ma atrybutów, więc możemy się go pozbyć i po prostu dodać odniesienie do klucza obcego do tabeli projektu w uczniach.