Normalization (Relational Model)

#draft 아직 미완성된 작물입니다.

• 구체적인 예시 추가

Normalization, 정규화 §

• 일단 정규화의 가장 큰 목표는 중복된 데이터를 최소화하는 것이다.
• 이렇게 함으로써 무결성 (Integrity) 도 줄일 수 있고, DB 의 용량도 줄일 수 있으며 연산의 양도 줄일 수 있게 된다.
• 하지만 너무 많이 쪼개면 JOIN 의 비용이 늘어나기 때문에 성능과 중복 간에 적당히 타협을 해서 정규화하는 것이 중요하다.

종류 §

제 1 정규화 §

• 얘의 핵심은 칼럼 하나당 하나의 값 (원자값, Atomic Value) 를 갖도록 해야된다는 것이 전부이다.

제 2 정규화 §

• 제 2 정규화는 “완전 함수 종속” 을 만족하게끔 해야된다는 것이다.
• 말이 좀 어려운데, 풀어서 말해보면 PK 의 부분집합이 “결정자” 가 되어서는 안된다는 개념이다.
  • 여기서 “결정자” 라는 것은 어떤 attribute 의 값을 결정하는 attibute 를 의미한다.
• 예를 들어보자.
  • A, B, C, D 네개의 칼럼으로 이루어진 테이블에서 PK 가 A, B 이라면
  • 결정자 관계를 -> 로 나타냈을 때 {A, B} -> {C, D} 라고 표현할 수 있을 것이다.
  • 근데 만약 B -> D 의 관계가 만족한다면 이건 B 가 Attribute 의 일부를 결정하는 결정자가 되기 때문에
  • A -> {C, D} 하고 B -> D 로 테이블을 나누는게 바람직하다는 것이다.

제 3 정규화 §

• 제 3 정규화는 “이행적 종속” 이 없어야 된다는 것이다.
  • A, B, C 세개의 칼럼으로 이루어진 테이블에서 PK 가 A 이고 (즉, A -> {B, C})
  • B -> C 의 결정관계가 있을때 A -> C 면 이행적 종속이 있다고 한다.
• 쨋든 그래서 이때도 테이블을 나눠야겠지
  • 위의 예제에서는 A -> B 하고 B -> C 로 나누는 게 적절하다.
• 이 정규화를 해줘야 되는 이유는 다음과 같다:
  • 만약에 위의 예시에서처럼 쟤네들이 모두 한 테이블에 있다면, B 가 변경되었을 때 C 까지 같이 변경해줘야 하기 때문이다.
  • 하지만 테이블을 나누게 되면 A -> B 의 테이블에서 B 의 값만 바꿔주면 된다.

BNCF 정규화 §

• 얘는 모든 결정자는 후보키가 되어야 한다는 것이다.
• 즉, 결정자는 후보키가 되어 PK 로 사용될 수 있어야 하거나 PK 가 되게끔 테이블을 분리하라는거다.
• 뭔말이냐면
  • {A, B} -> C 인 테이블에서 만약 C -> B 라면?
  • C 는 결정자인데 후보키가 아니므로 얘를 PK 로 하는 테이블을 만들어 주면 BNCF 정규화가 된다.
  • 즉, A -> C 랑 C -> B 로 쪼개는 방식으로 정규화를 한다.