DB - 12. E-R Model, RDB로 변환하기

1. 최종 점검

- 이제 필요한건 다 배웠으니 전체 ER Diagram을 살펴보자.
- entitiy set는 모두 7개, relationship diamond는 총 10개가 있다.
- weak entity 1개와 identifying relationship도 1개가 보인다.
- course entity는 unary로 선수, 후수 과목 관계가 잘 나타나있다.
- 겹선으로 나타낸 total participation을 보면 학생은 반드시 과가 정해져있어야하는 등의 제약들이 잘 반영되었다.

2. Redcution to Relation Schemas

- 위의 ER Model로 RDB를 만들면 아래처럼 된다.

- 일반적으로 entity set, relation이 하나의 table이 된다. 그 안의 속성들이 column으로 변환된다.

weak entity 변환

- 아래 변환 예시를 살펴보자.

- couse(cid, title, credits), section(course_id, sec_id, sem, year)가 되고 section의 course_id가 course의 cid를 참조하는 외래키가 된다.
- weak entity에서는 section을 테이블로 만든것과 sec_course를 table로 만든것과 중복되기 때문에 relationship은 테이블로 만들지 않는다.
- 겹선다이아몬드는 무시한다.

여러 종류의 속성들 변환

- 이번엔 instructor를 변환한 결과를 살펴보자.

- composite attributes에서 leaf node만 flatten되어 나온다.
- 도출속성은 column으로 추가하지 않는다.

- 다중값인 phone_number는 column으로 추가하면 atomic한 value로 구성될 수 없기 때문에 따로 테이블을 만든다.
- intructor의 pk인 id와 phone_number로 구성된 테이블을 하나 만든다.
- 이 새로운 테이블을 두 속성의 합성으로 pk가 된다.

Relationship set

- 이번에는 relationship set를 변환하는 예를 살펴보자.
- 다대다 관계이기 때문에 두 pk를 합성해서 advisor의 합성키로 사용한다.
- 자연스럽게 각 속성이 foreign key로 두 entity를 참조한다.

- 하지만 모든 relation이 table로 변환되는 것은 아니다.
- 아래처럼 테이블을 안 만들고 redundancy를 줄일 수 있다.

- 원래 같으면
dept(dept_name, building, budget)
instructor(id, name, salary)
inst_dept(id, dept_name) 로 자연스럽게 변환이 된다.

- 하지만 이러면 중복이 생기니까 아래처럼 "many, 다" side쪽에 속성을 하나 추가(extra attribute)해서 아래처럼 변환이 가능하다.
dept(dept_name, building, budget)
instructor(id, name, salary, dept_name)
- instructor에 dept_name을 추가해서 외래키로 설정하면 inst_dept가 없어도 무방하다.

*물론 일대일 관계도 위처럼 속성을 추가해서 테이블을 만들지 않아도 된다. 일대일 관계의 경우는 아무 entity에 속성을 추가하면 된다.
*한가지 주의할 점이 있는데 위의 예시는 total participation으로 교수가 반드시 과가 정해지기 때문에 dept_name을 속성으로 추가했을 때 null이 들어갈 염려가 없지만 partial participation의 경우는 dept_name column에 null이 많이 생길 수 있다.
*null이 많은 데이터베이스가 좋은 형태는 아니기 때문에 꼭 table을 줄이는게 최선은 아니다.

3. Extended E-R Features : Generalization(Specialization)

- bottom-top 관점으로는 entity들을 generalize하는 모습이고 top-down관점에서는 개체들을 specialize하고 있다.
- low level entity는 상위 entity의 attribute를 상속받는다.
- 속성 뿐만아니라 상위 entity의 relation도 하위 entity가 상속을 받는다.
- isA relationship이라고도 부른다.
- overlapping : 만약 대학원생이라면 student이면서 employee가 된다. 이런 entity들을 overlapping이라고 한다.
- disjoint : 반면에 instructor(교수), secretary(직원)는 서로 겹칠 수 없기 때문에 disjoint라고 한다.
- total : 상위 entity의 속성이 하위 entity에 반드시 나타난다면 total이라고 한다. 예를들면 student, employee는 person의 속성을 다 물려받는다.
- partial : 상위 entity의 속성이 하위 entity에 반드시 나타나지는 않는 경우이다. 예를들면 student는 employee일수는 있지만 instructor나 secretary가 student의 tot_credits속성을 상속받지는 않는다. 이런경우를 partial이라고 한다.

- 그럼 이런 e-r model은 어떻게 테이블 스키마로 변환할까?

- 그대로 구현하되 PK만 상속받고 PK인 ID로 외래키 참조가 가능하게 만든다.
- 후에 DB에 접근하기 위해 Join연산을 하게 되는데 이는 cost가 비싸다.

- 두번째 방법은 이렇게 상속하는 모든 속성을 받아서 적는다.
- 접근 시간은 빠르겠지만 중복이 발생한다.

4. Extended E-R Features : Aggregation

- is_part_of_relationship이라고 부른다.
- subpart들이 모여서 하나의 합성속성을 이루는 것을 말한다.

- 지금 위의 예시는 학생, 교수, 졸업논문(프로젝트)이 proj_guide로 연결 되어있다.
- 그런데 여기에 교수가 학생의 논문을 평가하는 관계를 또 추가했다고 해보자.
- 딱봐도 복잡한 관계로 얽혀있고 이미 3자간 관계로 묶인 proj_guide가 있는데 evaluation이 추가되어 eval_for로 사자간 관계로 묶여있다.
- 이를 aggregation으로 깔끔하게 정리해보자.

- 이미 삼자간 묶여있는 관계를 하나의 큰 box로 묶어서 하나의 entitiy인것처럼 나타낸다.
- 그럼 eval_for는 evaluation과 하나의 큰 box, 두 entity와의 binary relationship이 된다.
- 이제 이 모델을 테이블 스키마로 변환하면 다음과 같다.
proj_guide(iID, pID, sID)
eval_for(eID, iID, pID, sID)