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

1. 변환 규칙 복습

2. 일대다 relationship 변환

- relation을 table로 변환하는 예시

- relation을 table로 변환하지 않고 extra attribute를 추가하는 예시

3. 일대일 relationship 변환

- 일대일 관계를 변환한 예제이다.

- 만약 별도 테이블을 만들지 않는다고 하면 아래처럼 할 수 있다.

- 두가지 스키마가 가능하지만 도서가 더 많은 상황이라면 과목에 속성을 추가하는 것이 더 나을 수 있다. 왜냐하면 도서에 과목번호 속성이 추가되면 null이 들어가는 레코드가 많아질 수 있기 때문이다.

- 반대로 과목에 속성을 추가하는 경우는 total participation이기 때문에 null이 들어갈 일이 없다.

4. Unary relationship 변환

- 이번에는 unary relationship을 살펴보자.

- 만약 멘토링이라는 relation을 table을 만들지 않고 구성하면 어떻게 될까?

- "다"쪽에 attribute를 추가하면 된다고 했는데 이렇게 동일한 entity의 경우는 어떻게 해야할까?

- 스키마2의 경우는 한 학생에게 여러 멘티가 있을 수 있기 때문에 데이터 중복도 발생할 수 있고 이렇게 되면 학번이 고유 식별성이 사라져 버린다. 따라서 스키마1이 옳다.

 

- 이번에는 1대1 unary를 살펴보자.

- 마찬가지로 아래처럼 두가지 스키마가 가능할 것이다.

5. Ternary relationship 변환

- 위 모델을 변환하면 아래와 같다.

6.  다중값 속성 변환

- 학생이 취미를 복수개 가지는 경우

- 만약에 취미를 그냥 column으로 넣어버리면 행, 열 탐색으로 atomic한 값이 정해지지 않으므로 1NF규칙에 위배된다.

7.  ERD 통합

- 큰 실세계를 한번에 er model로 만드는 것은 어려우니 부분을 만들어서 합치는 과정을 겪게된다.

- 이 과정에서 발생하는 문제들을 알아보자.

- 첫번째 ERD와 두번째 ERD를 완성했다고 하자. 이제 둘을 합치는 단계에 왔다.

- 가만보니까 Book의 Topics과 Publication의 Keyword는 실세계에서 동일한 의미지만 다른 단어로 사용되고 있다.

- 따라서 이를 일치시킨다.

- 가만보니 문제가 하나 더 있다. 왼쪽 다이어그램에서는 entity로서 publisher가 필요하지만 우측 다이어그램에서는 publisher가 attribute면 충분하다.

- 따라서 이를 합치기 위해서는 publisher를 entity로 독립시키는게 좋아보인다.

- 명칭과 구조적 문제가 해결되었으니 아래처럼 결과를 합쳐보자.

- 그런데 좀 더 생각해보니까 Book도 Publication의 일종이다. 이를 상속관계로 만들어서 ERD를 더 간단하게 만들어보자.

8.  ERD 작성 변환 연습

- 만약 고객이 한 지점에서 대출을 또 받는다면? 불가능 왜냐면 고객ID, 지점명이 PK로 구성되었기 때문.

- 대출을 상환했다면? No

- 공동 명의 대출은 가능한가? No

- 위의 요구사항을 모두 반영하여 새롭게 만들었다.

- 아래 같은 다이어그램도 가능할 것이다.