정규화란?
정규화(Normalization)는 데이터의 중복을 줄이고, 데이터 무결성을 보장하기 위해 데이터베이스를 쪼개는 과정이다. 쉽게 말해서 비효율적인 테이블을 더 효율적이고 유지보수 가능한 형태로 바꾸는 일이라는 것이다.
왜 중복되면 안될까
위의 테이블을 보면 교수 정보가 중복된다
만약 교수 연락처가 바뀐다면 → 모든 학생 행을 수정해야 한다!
데이터를 잘게 나누고 관계로 연결하면, 이러한 문제를 해결할 수 있다.
정규화의 단계
📌 제1정규형 (1NF)
원자값만 허용한다.
| O | X |
|---|---|
| 이름: 김철수 | 이름: 김철수, 이영희 |
| 전화: 01012345678 | 전화: 01012345678 / 01098765432 |
→ 테이블의 각 칸에는 하나의 값만 있어야 한다.
📌 제2정규형 (2NF)
부분적 종속 제거
- 복합키를 사용하는 테이블에서
- 기본키의 "일부에만" 종속되는 컬럼이 있다면 → 분리해야 한다.
기본키가 여러 개일 때, 컬럼이 그 중 일부에만 의존하면 안 된다!
아래는 아직 정규화되지 않은 테이블이다.
- 기본키는 (학번, 과목코드) 복합키이다.
- 그런데 "과목명", "교수명"은 오직 과목코드에만 의존한다
이게 바로 부분 종속이다.
→ 기본키 전체가 아니라 일부(과목코드)에만 종속된 정보
이렇게 계속 저장하게 된다면 "자료구조", "김교수"와 같은 값들이 계속 반복 저장된다.
만약 과목명 오타나 교수 변경이 발생하면? → 데이터 불일치 발생 위험
제2 정규화를 하게 되면 이렇게 나눌 수 있다.
→ 과목코드만 알면 관련 정보 추적 가능
→ 과목명, 교수명이 더 이상 반복되지 않음
📌 제3정규형 (3NF)
이행적 종속 제거
- 기본키 외의 컬럼이, 또 다른 컬럼에 의존하면 → 분리해야 한다
학번 → 학과코드
학과코드 → 학과명→ 그러면 학번으로 학과코드를 거쳐 학과명을 알 수 있다.
학번 → 학과코드 → 학과명
이처럼 중간 단계가 있는 종속이 이행적 종속(transitive dependency)이다.
- 기본키는
학번인데학과명은학과코드로부터만 결정된다.
이런 상황에서 제3 정규화를 하게 되면, 다음처럼 나눌 수 있다.
- 학과명을 바꾼다고 했을 때, 3NF 이전 테이블에서는 중복된 모든 행을 찾아 바꿔야 하지만, 3NF 이후에는 학과 테이블 한 군데만 수정하면 된다.
📌 보이스-코드 정규형 (BCNF)
모든 결정자(determinant)가 후보키
결정자(determinant)란?
어떤 값을 보면 다른 값을 정할 수 있는 속성
- (학번 → 이름): 학번이 결정자
- (과목명, 교수명 → 강의실): 과목명과 교수명이 결정자
- 하나의 교수는 여러 과목을 강의할 수 있다. (교수명 → 강의실)
여기서 교수명은 결정자인데, 후보키가 아님!
BCNF를 하게 되면 이렇게 나눌 수 있다.
→ 이렇게 하면 결정자는 후보키가 되고, BCNF를 만족한다.
BCNF vs 3NF
| 구분 | 제3정규형(3NF) | BCNF |
|---|---|---|
| 제거하는 종속 | 이행적 종속 | 후보키가 아닌 결정자 |
| 후보키 기준 | 후보키가 아닌 속성이 종속되면 안됨 | 모든 결정자가 후보키 |
+BCNF가 더 엄격하다
정규화의 흐름 순서도
원자값인가? ──> 1NF
부분적 종속 있는가? ──> 2NF
이행적 종속 있는가? ──> 3NF
모든 결정자가 후보키가 아닌가? -> BCNF
정규형은 단계적으로 진행되며,
이전 정규형을 만족한 상태에서 다음 단계로 넘어간다.
무조건 정규화만이 답은 아니다.
- 너무 쪼개면 JOIN이 많아져 성능이 나빠질 수 있음
- 읽기 성능이 중요한 시스템은 일부 비정규화하기도 한다 (ex: 로그, 대시보드용 DB)
