정규화
Functional Dependency(FD)를 사용해서 DB를 정규화한다.
X가 Y의 값을 결정하거나, Y가 X에 의존적인것을 FD라 한다.
의미
데이터 중복과 insertion, update, deletion anomaly를 최소화 하기 위해 일련의 normal forms(NF)에 따라 relational DB를 구성하는 과정
normal form
정규화 되기 위해 준수해야할 몇가지 규칙
앞 단계를 만족해야 다음 단계로 진행할 수 있다.
3NF를 만족할 경우 1NF, 2NF를 만족한 상태이다.
실무에서는 주로 3NF 혹은 BCNF까지 진행(많이 해도 4NF 정도 까지만 진행)
BCNF까지만 FD와 key만으로 정의되는 normal forms이다.
예제 Table Schema
candidate key : 존재하지 않으면 tuple들을 unique하게 식별할 수 없는 key, PK의 후보
primary key : candidate key중 tuple을 unique하게 식별하기 위해 선택된 key
prime attribute : 임의의 key에 속하는 attribute, candidate key에 속하는 attribute
non-prime attribute : 그어디에도 속하지 않는 attribute
예제 FD
account_id
bank_name, account_num
class
예제 data
1NF
attribute의 value는 반드시 나눠질 수 없는 단일한 값이어야한다.
1NF 후 발생된 문제 해결
card_id를 나누고, Primary Key가 더이상 tuple을 unique하게 식별할 수 없기 때문에, (account_id, card_id)로 PK를 설정한다.
2NF
card_id가 존재하지 않아도 non-prime attribute가 unique하게 결정될 수 있다.
non-prime attribute들이 부분적으로 의존하는 상태이다.
Messi의 card_id가 분리되었기 때문에 중복된 데이터가 생성되었다.
2NF : 모든 non-prime attribute는 모든 key에 fully functionally dependent 해야 한다.
class, ratio, empl_id, empl_name은 (candidate) key에 대해 전체적으로 의존적이어야한다.
non-prime attribute들이 key에의해 unique하게 결정된다.
3NF
account_id -> empl_name은 transitive FD관계이다.
bank_name, account_id -> empl_name
3NF : 모든 non-prime attribute는 어떤 key에도 transitively dependent 하면 안된다.
즉, transitive funtional dependency가 존재해서는 안된다.
non-prime attribute 들 사이에 FD가 존재해서는 안된다.
empl_id에 의해 empl_name이 결정되는 상황.
BCNF
class가 같으면 bank_name이 같고, class의 value를 파악하면 bank_name이 어떤것인지 파악가능하다.
BCNF : 모든 유효한 non-trivial FD X -> Y는 X가 super key여야 한다.
bank_name은 class에 의존적이지만, class는 super key가 아니다!
class만으로 tuple을 unique하게 식별할 수 없다.
2NF 참고사항
2NF는 key가 composite key가 아니라면 2NF는 자동적으로 만족하는가?
composite key : Primary Key가 2개이상의 attribute로 구성되는 key
대부분 composite key가 아닌경우 2NF를 만족하지만 항상 만족하는것은 아니다.
Denormalization
반 정규화, 정규화 과정에서 너무 많은 table로 나뉘게 되면 관리가 어려워지고, table join에서 성능저하이슈가 발생될 가능성이 존재한다.
항상 정규화를 지켜주는것이 최선이 아니다.
