정규화

Contents

1. Normal forms

2. 예시 테이블

3. 정규화

4. 반정규화

---

데이터 중복과 (insert, update, deletion) anomaly를 최소화 하기 위해 일련의 normal forms(NF) 에 따라 relation DB를 구성하는 과정

1. Normal forms

정규화 되기 위해 준수해야 하는 규칙

처음부터 순차적으로 진행하며 normal forms을 만족하지 못하면 만족하도록 테이블 구조를 조정한다.

• 앞 단계를 만족해야 다음 단계로 진행할 수 있다.

• FD와 Key 만으로 정의되는 normal forms
• 3NF까지 도달하면 졍규화 됐다고 말하기도 함
• 보통 실무에서는 3NF 혹은 BCNF까지 진행

2. 예시 테이블

• 임직원의 월급 계좌를 관리하는 테이블
• 월급 계좌는 국민은행 or 우리은행
• 한 임직원이 하나 이상의 월급 계좌를 등록하고 월급 비율(ratio)를 조정할 수 있다.
• 계좌마다 등급(class)이 있음
  • 국민
    • STAR / PRESTIGE / LOYAL
  • 우리
    • BRONZE / SILVER / GOLD
• 한 계좌는 하나 이상의 현금 카드와 연동될 수 있다.

2.1 Key

1. super key
   • table에서 tuple들을 unique하게 식별할 수 있는 attributes set
2. (candidate) key
   • 어느 한 attribute라도 제거하면 unique하게 tuples를 식별할 수 없는 super key
     • {account_id}, {bank_name, account_num}
3. primary key
   • table에서 tuple들을 unique하게 식별하려고 선택된 (candidate) key
     • {account_id} or {bank_name, account_num}
4. prime attribute
   • 임의의 key에 속하는 attribute
     • account_id, bank_name, account_num
5. non-prime attribute
   • 어떠한 key에도 속하지 않는 attribute
     • class, ratio, empl_id, empl_name, card_id

2.2 Functional Dependency

2.3 tuple

---

3. 정규화

3.1 1NF

attribute의 value는 반드시 나눠질 수 없는 단일한 값이어야 한다.

하지만 중복 데이터가 생기고 primary key도 변경해야 한다.(ratio)

• 기존
  • account_id
• 수정 후
  • {account_id, card_id}

후보 키:

• {account_id, card_id}, {bank_name, account_num, card_id}

non-prime attribute

• class, ratio, empl_id, empl_name

non-prime attribute는 card_id에 종속되지 않는다. → {account_id, card_id}, {bank_name, account_num, card_id}에 partially dependent 하다. → 2정규화

3.2 2NF

모든 non-prime attribtue는 모든 key에 fully functionally dependent 해야 한다.

non-prime attribute는 {account_id}, {bank_name, account_num}에 종속된다.

즉, 복합 키의 일부에만 의존하는 속성이 존재하면 2NF를 위반한다.

key가 composite key가 아니라면 2NF는 자동적으로 만족한다? → X company tuple이 항상 ez.라면 2NF을 위반한다.

3.3 3NF

모든 non-prime attribute는 key에 **직접적으로만 의존해야 하며,

다른 non-prime attribute를 통해 간접적으로 의존하면 안 된다.**

{account_id} → {empl_id}, {empl_id} → {empl_name} 따라서 {account_id} → {empl_name}

{bank_name, account_num} → {empl_id}, {empl_id} → {empl_name} 따라서 {bank_name, account_num} → {empl_name}

transitive FD

• if X → Y && Y → Z holds then X → Z is transitive FD
• unless either Y or Z is NOT subset of any key

국민은행 계좌 등급

• START / PRESTIGE / LOYAL 우리은행 계좌 등급
• BRONZE / SILVER / GOLD

따라서 class → bank_name FD 존재. → bank_name을 들고있을 필요가 있을까?

3.4 BCNF

모든 유효한 non-trivial FD X → Y 는 X가 super key여야 한다.

4. 반정규화

정규화를 통해 분리된 테이블들을, 성능 향상을 위해 의도적으로 다시 합치거나 일부 중복을 허용하는 설계 방식

정규화를 지나치게 적용하면 여러 테이블을 조인해야 하는 상황이 많아지고, 그로 인해 조회 성능이 저하되거나 쿼리가 복잡해질 수 있다.

이러한 문제를 완화하기 위해 반정규화를 적용한다.

반정규화를 고려하는 상황:

1. 조인 비용이 큰 경우
2. 조회 빈도가 매우 높은 경우
3. 집계·통계 데이터를 자주 조회하는 경우

결국 반정규화는 데이터 중복을 최소화하는 정규화 원칙과, 조회 성능을 높이기 위한 요구 사이에서 적절한 균형을 맞춰야 한다.