정규화(Normalization)는 데이터의 중복을 줄이고 데이터의 무결성을 확보하며 더 효율적으로 관리하기 위한 방법
실무에서는 주로 제3 정규화(3NF)만 고려하는 경우가 많다. ( 이유는 글 하단에 설명되어있음 )
정규화가 진행될수록 테이블이 세분화되면서 조인이 많아져 조회 속도가 저하될 수 있다.
이러한 경우, 정규화를 부분적으로 완화(위배)하여 조인을 줄이고 조회 성능을 향상시키는
반정규화(Denormalization) 기법을 활용할 수 있다.
(자주 조인(Join)되는 테이블을 하나로 합쳐서 조인 비용을 줄이는 방법 등을 실시)
4NF 와 5NF 는 잘 사용되지 않기에, 다른 글에 새로 작성하겠다.
🚀 정리
| 정규화 | 내용 | 중복 발생 이유 | 예시 |
|---|---|---|---|
| 제1 정규화 (1NF) |
한 칸(셀)에 하나의 원자적 값만 저장 (Atomic Value) |
한 칸(셀)에 여러 개 값 존재 🔴 → 검색·수정 어려움 |
과목 셀 → 수학, 영어 ❌ 과목 셀 → 수학 ⭕ |
| 제2 정규화 (2NF) |
부분 종속 제거 (Partial Dependency) (기본키 일부만으로 결정되는 속성을 분리하여, 모든 속성이 기본키 전체에 종속되도록 한다.) |
부분 종속 발생 🔴 → 기본키 일부에만 종속된 속성 존재 (데이터 중복 증가) |
복합 기본키(학생ID, 과목ID) 학생ID → 이름·전화번호 ❌ 과목ID → 과목명·교수 ❌ ✅ 해결: 학생·과목 정보 테이블 분리 |
| 제3 정규화 (3NF) |
이행적 종속 제거 (Transitive Dependency) (기본키와 직접 연결되지 않고 다른 속성을 거쳐 간접적으로 연결된 종속 관계를 제거한다.) |
이행적 종속 발생 🔴 → 기본키에 간접적으로 종속된 속성 존재 |
과목ID → 교수명 ❌ 과목ID → 교수ID → 교수명 ⭕ ✅ 해결: 교수 테이블 분리 |
| BCNF (Boyce-Codd NF) |
모든 결정자가 후보키여야 함 (다른 속성을 결정하는 속성이 기본키나 후보키가 아니라면 새로 후보키로 설정 혹은 테이블 분리) |
결정자가 후보키가 아닐 경우 🔴 → 여전히 중복·수정 문제 발생 가능 (3NF 이후에도 남을 수 있음) |
예: 강의실(Room)이 교수ID를 결정할 때, 강의실이 기본키나 후보키가 아니라면 BCNF 위반 ✅ 해결: 복합키 설정 혹은 "강의실-교수" 관계 테이블로 분리 |
🏆 정규화 과정
✅ 제1 정규화 (1NF: First Normal Form) - 원자적 값(Atomic Value) 유지
아래처럼 수강 과목 데이터를 저장하면 어떤 문제가 생길까요?
| 학생ID | 이름 | 전화번호 | 과목 | 담당 교수 |
|---|---|---|---|---|
| 1 | 철수 | 010-1111-1111 | 수학,영어 | 김교수,박교수 |
| 2 | 영희 | 010-3333-3333 | 수학 | 김교수 |
📌 문제점: 원자적 값(Atomic Value) 위반
- 한 칸에 여러 개의 값이 들어있음. 원자적 값(Atomic Value) 위반.
- 데이터 형식이 일관적이지 않아 검색 및 수정 시 어려움.
📌 이 문제를 해결하려면?
학생이 수강한 과목과 담당 교수를 각각의 행으로 분리합니다.
| 학생ID | 이름 | 전화번호 | 과목ID | 과목 | 담당 교수 |
|---|---|---|---|---|---|
| 1 | 철수 | 010-1111-1111 | 101 | 수학 | 김교수 |
| 1 | 철수 | 010-1111-1111 | 102 | 영어 | 박교수 |
| 2 | 영희 | 010-3333-3333 | 101 | 수학 | 김교수 |
✅ 제2 정규화 (2NF: Second Normal Form) - 부분 종속(Partial Dependency) 제거
제1 정규화를 통해 각 줄을 원자적 값(Atomic Value)으로 분리하여 한 셀에 하나의 값만 들어가도록 정리했습니다.
하지만 제1 정규화를 마친 테이블을 다시 보면, 문제점이 있습니다.
📌 문제점 : 부분 종속(Partial Dependency)
- 기본키(학생ID + 과목ID) 중 일부(학생ID 또는 과목ID)에만 종속된 컬럼 존재
- 학생ID만으로 이름, 전화번호를, 과목ID만으로 과목명, 교수명을 결정하여 정보가 중복 저장됨
📌 이 문제를 해결하려면?
👉 학생 정보(이름, 전화번호)와 과목 정보(과목명, 담당 교수)를 각각 다른 테이블에 저장해야 합니다.
📚 학생 테이블
| 학생ID | 이름 |
|---|---|
| 1 | 철수 |
📚 과목 테이블
| 과목ID | 과목명 | 담당 교수 |
|---|---|---|
| 101 | 수학 | 김교수 |
📚 수강 테이블
| 학생ID | 과목ID |
|---|---|
| 1 | 101 |
참고 사항
테이블의 모든 컬럼에 동일한 값이 들어 있다면
이는 공집합의 종속적인것 처럼 되고, 이 공집합은 기본 키 값과 복합키처럼 사용될 수 있습니다.
✅ 제3 정규화 (3NF: Third Normal Form) - 이행적 종속(Transitive Dependency) 제거
제2 정규화를 통해 학생 정보와 과목 정보를 분리하여 부분 종속 문제를 해결했으나, 여전히 이행적 종속 문제가 존재합니다.
예를 들어, 과목 테이블에 교수 정보가 직접 저장되어 있어 교수명이 변경될 경우 모든 행을 수정해야 하는 문제가 발생합니다.
📌 문제점: 이행적 종속(Transitive Dependency)
- 교수 정보가 과목ID와 무관함에도 과목ID에 종속됨
- 과목ID가 교수명을 직접 결정하면, 교수명이 변경될 때 모든 행 수정 필요
📌 이 문제를 해결하려면?
👉 과목ID → 교수ID → 교수명 관계로 변경하고, 교수 정보를 별도 테이블로 분리
📚 과목 테이블
| 과목ID | 과목명 |
|---|---|
| 101 | 수학 |
📚 교수 테이블
| 교수ID | 교수명 |
|---|---|
| 201 | 김교수 |
📚 과목-교수 테이블
| 과목ID | 교수ID |
|---|---|
| 101 | 201 |
✅ BCNF (Boyce-Codd Normal Form) - 모든 결정자(Determinant)가 후보키가 되도록 정규화
제3 정규화(3NF)보다 더 엄격한 정규화 단계로, “모든 결정자(Determinant)가 후보키여야 한다.”라는 추가 조건을 만족해야 합니다.
만약 후보키가 아닌 속성이 다른 속성을 결정한다면 BCNF 위반이므로, 테이블을 분리하거나 후보키(복합 키)를 재설정해야 합니다.
📚 강의 테이블 - 강의ID 만 PK
| 강의ID (PK) | 강의실(Room) | 교수ID |
|---|---|---|
| 1 | 101 | 1 |
| 2 | 101 | 2 |
| 3 | 102 | 3 |
📌 문제점: 후보키가 아닌 결정자 (BCNF 위반)
- 강의실(Room)이 교수ID를 직접 결정 (결정자). 그러나 강의실이 후보키가 아님 → BCNF 위반
- 같은 강의실에서 여러 교수가 강의할 수 있거나, 강의실 중복 시 수정 문제 발생
📌 이 문제를 해결하려면?
👉 강의실이 후보키가 되도록 테이블을 분리하거나, 복합 키(합성키)로 “결정자 = 후보키” 구조를 만든다.
해결 방법1 - 강의ID 와 강의실ID 복합 PK 설정
📚 강의 테이블
| 강의ID (PK) | 강의실(Room) (PK) | 교수ID |
|---|---|---|
| 1 | 101 | 1 |
| 2 | 101 | 2 |
| 3 | 102 | 3 |
해결 방법2 - 강의, 강의실- 교수 테이블 분리
📚 강의 테이블
| 강의ID (PK) | 강의실(Room) |
|---|---|
| 1 | 101 |
| 2 | 101 |
| 3 | 102 |
📚 강의실-교수 테이블
| 강의실 (Room) (PK) | 교수ID (PK) |
|---|---|
| 101 | 1 |
| 101 | 2 |
| 102 | 3 |
🏆 정규화 적용 방법 및 순서
✅ 제1 정규화 (1NF) 적용 순서
📌 목표: 한 칸(셀)에 여러 값이 들어있는 경우 해결 (원자적 값 유지)
🔎 확인해야 할 것
- 한 셀(속성)에 여러 값이 들어있는지 확인
- 예: “수학, 영어”처럼 한 셀에 여러 값이 저장된 경우
- 해당 데이터를 개별 행으로 나누어 ‘원자적 값(Atomic Value)’ 유지
- 한 셀에는 단 하나의 값만
- 예: “수학” 행, “영어” 행으로 분할
- 정상화가 완료되었는지 최종 확인
- 검색·수정 시, 한 셀에 여러 값이 없는지 점검
- 모든 셀이 “한 칸 = 한 값” 구조이면 1NF 충족
✅ 제2 정규화 (2NF) 적용 순서
📌 목표: 기본키 일부에만 종속되는 속성(부분 종속) 제거
🔎 확인해야 할 것
- 1NF가 적용되었는지 확인
- 한 셀에 여러 값이 없는지 점검
- 기본키가 합성키(Composite Key)인지 확인
- 예: (학생ID + 과목ID) 같이 여러 컬럼이 합쳐진 경우
- 합성키 전체가 아니라 일부(학생ID·과목ID)만으로 결정되는 ‘부분 종속’ 찾기
- 예: 학생ID만으로 학생 이름·전화번호 결정
- 예: 과목ID만으로 과목명·담당 교수 결정
- ‘부분 종속’ 속성을 별도 테이블로 분리
- 학생 정보(이름·전화번호)와 과목 정보(과목명·담당 교수)를 각각 분리 보관
- 중복 데이터 제거 및 테이블 간 관계(수강 테이블)로 연결
✅ 제3 정규화 (3NF) 적용 순서
📌 목표: 기본키가 아닌 속성들 간의 종속(이행적 종속) 제거
🔎 확인해야 할 것
- 2NF 적용 여부 확인
- 부분 종속이 제거되었는지 점검
- 중복 데이터 확인
- 과목 테이블에서 교수명이 여러 번 반복되는지 검사
- 동일한 교수명이 여러 과목에서 중복 저장되면 수정 시 모든 행 변경 필요
- 해당 중복 데이터가 기본키(과목ID)에 직접 종속되는지 확인
- 예: “과목ID → 교수명”이면 이행적 종속 발생
- 즉, 과목ID가 교수명을 직접 결정하는 구조는 잘못됨
- 이행적 종속 여부 최종 판단
- 교수명은 과목ID가 아니라 교수ID에 의해 결정되어야 함
- 즉, “과목ID → 교수ID → 교수명”으로 변경하여 별도 테이블에서 관리
✅ BCNF (Boyce-Codd Normal Form) 적용 순서
📌 목표: 모든 결정자(Determinant)가 후보키가 되도록 정규화
🔎 확인해야 할 것
- 3NF가 적용되었는지 점검
- 부분 종속, 이행적 종속이 이미 제거되었는지 확인
- 결정자(Determinant)가 후보키인지 확인
- 테이블 내에서 어떤 속성이 다른 속성을 ‘결정’(A → B)한다면, 그 결정자 A가 후보키인지 검사
- 중복 데이터 확인
- 후보키가 아닌 속성이 다른 속성을 결정할 경우, 중복·수정 문제가 발생
- 예: 강의실(Room)이 교수ID를 결정한다면, 강의실이 후보키가 아니면 BCNF 위반
- 후보키가 아닌 결정자가 존재한다면 최종 판단
- 만약 A가 후보키가 아니면서도 B를 결정한다면, BCNF 위반
- 해결: 테이블을 분리하거나 복합 키(합성키)를 재설정해, 모든 결정자를 후보키로 만든다
🏆 1NF, 2NF, BCNF 가 실무에서 잘 안 보이는 이유
- 1NF(원자성 유지)
- 엑셀처럼 한 셀에 여러 값이 들어간 비정상적인 구조는 DB 설계 시 거의 사용하지 않음
- 대부분의 관계형 DB 사용 시 1NF가 자동으로 적용됨
- 2NF(부분 종속 제거)
- 실무에서는 합성키(복합키)보다 단일 PK를 주로 사용하여 부분 종속이 잘 발생하지 않음
- 예: 학생ID+과목ID 대신 “수강ID”라는 Auto Increment PK 사용
- 따라서 2NF에서 부분 종속 고민이 줄어듦
- 3NF(이행적 종속 제거)는 실무에서 가장 중요
- 3NF는 데이터 중복 방지와 수정 시 오류 방지를 위해 많이 신경 씀
- 운영 중에도 중복 데이터 문제는 자주 발생하여 실무에서 중요함
- BCNF (Boyce-Codd NF)
- 3NF로도 해결이 안 되는 데이터 중복 “후보키가 아닌 결정자가 존재”하는 경우 추가로 고려
- 실무에서는 드물게 등장하지만, 복합키가 많은 환경에서는 적용 필요할 수 있음