[HUFS/Database] Relational Database Design

Fifth Normal Form

• {사내강사,교재} 일단 가능하나 다른 과목에서 같은 강사, 같은 과목이 가능해보이므로
  {OJT, 사내강사, 교재} 를 기본키로.
• 어떤 att도 다른 att의 값을 정하지 않는다 > 전체 멤버가 primary key 에 속하므로 함수종속이 없다고 이해할 수도 있다.(MVD도 없다.)
• {DB, A, 실습교재} 이면 OJT와 강사 , OJT와 교재간 MVD가 있다고 할 수 있다.
• MVD없으므로 4정규형
• insertion 있다 / 연쇄 삭제가 있다 / OBJ, 교재 사이 교재 종속 관계가 없으므로 Update anomaly 없음.

정규화

• 종속이 있었고, 이를 제거하는 것이 정규화였음
• 현재는 함수 종속 자체가 없음
• 어떻게 decompose? > 규칙 없이?
• 원칙: 한 테이블을 나누면 두 테이블엔 공통 att 가 생기고, 이 att 기준으로 natural join 하면 복원 되어야 함.

경우의 수

각 att 기준으로 나눈 경우 사내강사, 교재를 기준으로 한 경우 natural join 을 통해 복원이 가능.

2: 교재없이 강사입력은 가능하나, 강사없이 교재 입력은 불가능. (insertion 해결 안됨)
OJT와 교재로 이루어진 테이블이 있다면 살아남을텐데 없어서 deletion 해결 안됨

3. 교재 없이 새로운 강사 입력 불가, insertion 해결 안됨
   OJT 교재에 DB,DB실습이 남아있다. 해결 O

{OS, A, 실습교재} 가 추가되면 case1, 2, 3이 원상복구가 될까?
1은 X / 2도 OS, A, DB이론이라는 거짓 튜플 생성으로 X / 3도 OS, B, 실습교재라는 거짓튜플로 X

이럴 경우 편견을 깨고 테이블 3개로 쪼개자는 게 결론이다!

이 경우 더이상 anomaly 가 발생하지 않는다.

Normalization Example 1

기본키, 함수종속, 정규화

• telephone num 에 multivalue > 1정규화 필요. (정규형 중 어떤 것에도 해당하지 않음)
• 수평적 분할한다 (튜플만 추가하는 방식: 1정규화)
• 기본키는 customer_id, telephone_number 로 한다. (ID는 현재 456이 정규화 이후 두 개가 생겨서 안됨)
• {Customer_id, telephone_number} > first_name, Surname
• Customer_id > first_name, Surname (Partial Dependency)
• Customer_id, first_name, Surname 과 Customer_id, telephone_number 로 나누자.
  : anomaly 없음! 그냥 두면 된다. (5정규형)

Example 2

• 기본키: {종업원, 기술} 로 지정하면 같아질 이유가 없다.
• {종업원, 기술} > 근무지
• 종업원 > 근무지 (한 종업원은 하나의 근무지에만 근무한다는 가정, Partial Dependency)
• Binaary 이므로 더이상 정규화하지 않음

Example 3

• 주문 ID 가 기본키(나머지 다 결정)
• 주문 ID > 나머지 모든 att
• 회원ID > 회원 명, 전화번호, 회원등급 (주문 ID > 회원 ID > 이름, 전화번호, 등급: transitive dependency)
• {주문 ID, 회원ID, 상품ID, 수량, 단가} : 주문 테이블
• {회원 ID, 회원명, 전화번호, 회원등급} : 회원 테이블
• 주문 테이블의 회원 ID => 회원 테이블의 회원 ID 를 참조 설정
• 주문 테이블을 create 할 때 설정해주는 것! (delete Cascade이다. update Cascade 도 있다!)