ER 다이어그램의 관계 특성을 SQL

Question

으로 번역 중입니다. 현재 SQL로 그립을 처음 시도하고 있으므로 몇 가지 문제를 해결하려고합니다. 다음은 샘플 데이터베이스 사양입니다.

학생 (이름, 성별, 코스)은 프로젝트 (제목)를 수행합니다. 각 프로젝트에는 두 명의 수퍼바이저 (이름, 성별, 부서)가 입니다. 모든 학생들은 프로젝트를 수행합니다 ( ). 그러나 모든 프로젝트가 진행되는 것은 아닙니다. 한 명 이상의 학생이 동일한 프로젝트를 수행 할 수 있습니다. 학생들은 감독자 중 한 명과 정기적 인 회의를하며이 회의는 기록됩니다 (날짜, 시간, 학생, 감독자, 메모).

내가 (예 등 학생 테이블을 생성) 기초를 얻을 수 있습니다하지만 난 데 : 응급실 다이어그램 내가 생각하는 작성 지금까지 내가있어

가 정확한지 관계, 특히 미팅 관계를 표현하는 방법에 대해 고민하고 SQL에서 속성과 속성을 표현하는 방법에 대해 고민합니다. 대신 '회의'항목을 만들어야합니까?

Answer 1

예, Student과 Supervisor 사이의 many to many 관계를 나타내려면 Meeting 엔티티를 만들어야합니다. 이 테이블에 해당 외래 키를 사용하여 해당 테이블과 관련시킬 수 있습니다. SQL에서는이 같은 것을 보일 수 있습니다 : 또한 Project와 Supervisor 사이 Supervise에 대해 동일한 일을 할 것

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

. 또한 Meeting 테이블에서 복합 키라는 것을 사용할 수도 있습니다. 개인적인 선호도에 따라 달라질 수 있습니다. 일반적으로 다 대다 관계를 나타낼 때이 방법을 사용합니다. 이것이 데이터베이스에 의존하는 구문이라고 말하는 것은 아닙니다. 이것은 올바른 방향으로 당신을 가리키는 예일뿐입니다. 희망이 도움이됩니다.

또한 귀하의 다이어그램 (나는 이것이 클래스 용이라고 생각합니다)의 경우 Visio 또는 시각적 패러다임과 같은 소프트웨어를 조사하여 ER 다이어그램을 만들 수 있습니다. 대부분의 사람들은 현재 다이어그램을 이해할 수 있지만 올바른 모델링은 아닙니다.

재미를 위해 나는 당신의 테이블을 기반으로 다이어그램을 만든 : 그들은 많은 관계로 많은 경우

당신은 Supervisor 및 Project 사이의 엔티티를 원하는 것입니다. 이를 associative entity이라고합니다. 내 레이블을 SupervisorProject 그냥 그래서 좀 더 명확합니다.

편집 학생과 프로젝트가 다 대다는 사실을 간과 해 미안합니다.

Answer 2

Cohagen에 대한 응답으로 this stackoverflow post은 속성이없는 경우에도 관계 테이블을 유지함으로써 Supervise과 같은 다 대다 관계를 나타낼 수 있다고 제안합니다. 대조적으로 Do 테이블은 다 대일 관계 사이에 있고 특성을 갖지 않으므로이를 제거하고 학생들의 프로젝트 테이블에 외래 키 참조를 추가하기 만하면됩니다.