24. DB 정규화(normalization) - Part 2

3Normal Form(3NF)

EMPLOYEE_ACCOUNT Table의 FD를 시각화한 것이다.

그런데 테이블의 {empl_id,empl_name}을 보면 중복된 데이터가 너무 많은 것을 알 수가 있다.

왜 저 부분에서 중복된 데이터가 발생할 수밖에 없는지, 원인을 살펴보자. 

우선, empl_id -> empl_name이라는 FD 관계에 있다. 

그리고 account_id(key) -> empl_id이다. 

위 2가지 FD를 좀 더 그림으로 이해해 보자. 

Key가 {bank_name.account_num}일 때에도 위와 같은 이유로 중복이 발생을 한다. 

모든 non prime attribute는 여기서는 {class,ratio, empl_id, empl_name}에 해당

key는 {bank_name,account_num}, {account_id}이다. 

위 그림의 정의와 같이, 모든 non prime attribute가 어떠한 key에 transitively dependency 관계에 있을 때에는 중복이 발생

할 수가 있다(중복이 발생하지 않을 수도 있다.)

solution : 문제가 되는 non prime attribute를 다른 테이블로 따로 분할을 시켜준다.(아래 참조)

위 테이블들은 3NF을 만족한다. 

 

BCNF

class -> bank_name이라는 FD가 위 테이블 상에 존재를 한다. 

non-trivial FD : Y가 X의 subset이 아닌 경우.

bank_name={국민은행,우리은행}은 x에 해당하는 class={Bronze, silber, ...loyal}의 부분 집합이 될 수가 없으므로

class->bank_name은 non-trivial FD이다. 

그러나 X에 해당하는 CLASS는 위 테이블 상에서는 super key가 될 수가 없다. 

고로, BCNF의 조건을 만족하도록 아래와 같이 테이블을 수정해야 한다. 

EMPLOYEE_ACCOUNT TABLE은 애초에 non trivial FD가 없고,

ACCOUNT_CLASS의 non trivial FD인 class -> bank_name에서 x에 해당하는 class는 해당 테이블에서 super key 이므로

위 테이블들은 모두 BCNF를 충족시킨다. 

 

composite key : 2개 이상의 attribute로 구성된 key!

위 테이블에서는 {team,back_number}라는 composite key가 존재!

교과서 등에 2NF에 대하여 key가 composite key가 아니라면, 즉 key가 1개의 attribute로 구성이 되어 있다면 자동적으로

2NF의 조건을 만족한다고 나와 있다.

일반적으로는 맞는 말이지만, 특수한 상황에서는 틀린 경우가 존재한다. 

위와 같은 EMPLOYEE Table의 company attribute의 값이 항~~상 eg.인 경우를 생각해보자. 

key {empl_id}에서 empl_id를 제거한 {}도 공집합이자 {empl_id}의 부분 집합이다.

고로, company라는 non prime attribute는 partially dependent라고 볼 수가 있다. 

즉, EMPLOYEE 테이블의 KEY가 Composite key가 아닌데도 2NF를 만족하고 있지 않고 있다. 

2NF의 조건을 만족시키기 위해, company를 다른 테이블로 빼 주어서 2NF 조건을 만족시켰다. 

근데, "굳이 COMPANY를 다른 테이블로 빼야 할까?"라는 생각이 들 수가 있다.

테이블이 많아지면 JOIN시 연산량이 많아 지는 등의 단점도 존재를 한다. 

그래서 굳이 테이블을 나누지 않고(정규화 하지 않고) 테이블을 전략적으로 분할하지 않는 것을 역정규화(Denomalization)

이라고 한다. 

ACCOUNT_CLASS을 역정규화(denormalization)하면 아래와 같이 되면서 BCNF에서 3NF로 바뀐다.