DB - 13. E-R Model 4

1. Design issues

case 1.

- er modeling을 할 때 생길 수 있는 애매한 상황들을 알아보자.

- stud_dept가 정의되어 있는데 굳이 student에 dept_name이 속성으로 들어가 중복을 야기한다.

 

case 2.

- 학생이 수업에서 낸 과제를 채점할 수 있는 구조를 나타내고 있다.

- 그런데 이 구조에서는 학생의 수업당 딱 한개의 과제만 채점이 가능하다.

- 현실세계를 더 잘 반영할 수 있도록 해보자.

- 이렇게 고치면 assignment는 section에 의존하는 weak entity이고 학생이 특정 section의 여러 과제들을 marks_in하도록 되어있다.

 

- 이 방법에서는 다중값 속성으로 특정학생이 특정 수업을 들을때 여러개의 assignment와 각각의 mark가 있을 수 있도록 했다.

 

case 3.

- 제일 많이 헷갈리는 경우이다. entity로 구성하는게 좋은지? attribute로 구성하는게 좋은지를 비교해보자.

- 만약 휴대폰 번호 하나로 충분하다면 왼쪽처럼 속성으로 만드는게 좋을수도 있고 연락처가 여러개 필요하다면 우측처럼 독립적인 entity가 나을 수도 있다.

 

case 4.

- 이번에는 entity와 relationship 두 경우 중 뭐가 나을지 고민되는 상황을 살펴보자.

- 일반적으로 action은 relationship으로 나타낸다.

- 아래 예시는 수강등록 entity를 가운데 두고 "section 개설" 을 section_reg로 그리고 학생의 "수강"을 student_reg의 relation으로 나타낸다.

- 물론 그냥 section과 student를 takes relation으로 단순하게 관계를 맺으면 되지만 필요에 따라 위 같은 구조도 가능하다.

 

case 5.

- relationship의 attribute를 다른 entity의 속성으로 넣어도 되지 않을까?

- 만약 1대1의 관계라면 사실 date가 instructor, student, advisor 셋중 어느 한 곳에 들어가도 상관은 없다.

 

case 6.

- binary relationship이 나은가 아니면 non- binary relationship이 나은가?

- 물론 ternary relationship을 binary relation들로 나눌수 있지만 설계자의 몫이다.

2. 기호 정리

 

- 아래는 er모델의 창시자인 chen의 표기법이다.