1. 정규화란?
관계형 데이터베이스(RDBMS)에서 정규화는 데이터의 중복을 제거하고,
데이터 무결성을 유지하기 위해 테이블 구조를 체계적으로 설계하는 기법
2. 정규화의 목적
- 중복 제거: 같은 정보가 여러 곳에 반복 저장되지 않도록
- 이상 현상 방지: 삽입/삭제/수정 시 데이터 불일치 방지
- 무결성 유지: 일관성 있는 데이터 저장
- 재사용성 향상: 여러 테이블을 효율적으로 연결 가능
3. 이상현상이란?
이상현상은 테이블 설계가 잘못됐을 때 발생하는 비정상적인 현상
| 종류 | 설명 | 예시 |
|---|---|---|
| 삽입 이상 | 일부 정보만으로는 삽입 불가 | 고객이 주문해야 등록 가능 |
| 삭제 이상 | 하나의 삭제가 다른 정보도 삭제 | 마지막 주문 삭제 시 고객 정보도 삭제 |
| 갱신 이상 | 중복 데이터 중 일부만 수정되어 불일치 발생 | 고객 주소가 여러 행에 있을 때 일부만 변경 |
4. 정규화 단계
4-1. 제1정규형 (1NF) – 원자값(Atomic Value)
- 컬럼에 반복되거나 집합적인 값이 존재하면 안 됨
- 각 필드는 더 이상 나눌 수 없는 단일값만 저장
비정규화 테이블 예시
| 학번(StudentID) | 과목명(Subject) |
|---|---|
| 101 | DB, C# |
| 102 | DB |
1NF 적용
| 학번(StudentID) | 과목명(Subject) |
|---|---|
| 101 | DB |
| 101 | C# |
| 102 | DB |
4-2. 제2정규형 (2NF) - 부분 함수 종속 제거
- 제1정규화(1NF)를 만족해야 하며,
- 기본키의 일부분에만 종속되는 속성(부분 함수 종속)이 없어야 한다.
즉, 모든 비프라이머리 속성(기본키가 아닌 속성)은 기본키 전체에 대해 완전 함수 종속이어야 함.
비정규화 예시
- 제1정규형까지만 적용된 테이블
| 학번(StudentID) | 과목명(Subject) | 교수명(Professor) |
|---|---|---|
| 101 | DB | 홍길동 |
| 101 | C# | 김철수 |
| 102 | DB | 홍길동 |
- 기본키:
(학번, 과목명)→ 복합키 교수명은과목명에만 종속됨 → 부분 함수 종속 발생
문제점
- 과목과 교수의 관계는 중복됨 (수학=김교수)
- 과목명이 바뀌거나 교수가 변경되면 다수의 행을 수정해야 함 → 이상 발생 가능
→ 교수명은 과목에만 종속되어 있으므로 과목 테이블로 분리
2NF 적용
- 학생-수강 테이블 (Student_Subject)
| 학번(StudentID) | 과목명(Subject) |
|---|---|
| 101 | DB |
| 101 | C# |
| 102 | DB |
- 과목-교수 테이블 (Subject_Professor)
| 과목명(Subject) | 교수명(Professor) |
|---|---|
| DB | 홍길동 |
| C# | 김철수 |
| DB | 홍길동 |
→ 교수명이 과목명에만 종속된 부분 종속 제거 완료
→ 각 테이블은 단일 기본키에만 의존하도록 분해됨
4-3. 제3정규형 (3NF) - 이행 함수 종속 제거
- 제2정규화(2NF)를 만족해야 하며
- 이행적 함수 종속(Transitive Dependency)을 제거해야 한다
이행적 함수 종속(Transitive Dependency):
- A → B, B → C가 존재할 때, A → C도 성립하는 관계
- 여기서 C는 A에 직접적으로 종속된 게 아니라, B를 거쳐 종속됨
즉, 기본키가 아닌 다른 컬럼에 종속된 속성이 존재하는 경우!
비정규화 예시
- 제2정규화까지만 적용된 테이블
| 학번 | 학과코드(DeptCode) | 학과명(DeptName) |
|---|---|---|
| 101 | CS | 컴퓨터공학과 |
| 102 | EE | 전자공학과 |
| 103 | CS | 컴퓨터공학과 |
- 기본키:
학번(StudentID) 학과명(DeptName)은학과코드(DeptCode)에 종속학과코드는학번에 종속
→ 따라서학과명은 학번에 이행적 종속됨
문제점
- 학과명이 바뀌면 여러 행을 수정해야 함
- 데이터 중복으로 인해 갱신 이상(Anomaly) 발생 가능
3NF 적용
- 학생 테이블 (Student)
| 학번(StudentID) | 학과코드(DeptCode) |
|---|---|
| 101 | CS |
| 102 | EE |
| 103 | CS |
- 학과 테이블 (Department)
| 학과코드(DeptCode) | 학과명(DeptName) |
|---|---|
| CS | 컴퓨터공학과 |
| EE | 전자공학과 |
→ 이행적 종속 제거 완료
→ DeptName은 더 이상 Student 테이블에 존재하지 않음
5. 정규화 vs 비정규화
| 항목 | 정규화 | 비정규화 |
|---|---|---|
| 정의 | 중복 제거 및 이상현상 방지를 위해 테이블을 분해 | 성능 향상을 위해 테이블을 병합하거나 중복 허용 |
| 목적 | 무결성과 일관성 유지 | 조회 속도 향상 및 쿼리 단순화 |
| 데이터 중복 | 최소화 | 일부 허용 (조회 속도 우선) |
| 무결성 | 유지하기 용이 | 유지하기 어려움 |
| 설계 복잡도 | 구조가 정교하고 복잡 | 구조가 단순화됨 |
| 속도 최적화 | 쓰기(INSERT/UPDATE) 최적화 | 읽기(SELECT) 최적화 |
| 사용 시점 | 설계 초기, 정합성이 중요한 시스템 | 성능이 중요한 상황, 조회가 많은 시스템 |
언제 정규화를 사용할까?
- 데이터 무결성이 중요할 때
- 데이터 중복 최소화가 필요할 때
- 업데이트, 삭제 이상을 방지하고 싶을 때
언제 비정규화를 사용할까?
- 조회 속도가 중요한 시스템 (예: 분석, 검색 위주)
- 복잡한 조인이 시스템 성능에 영향을 줄 때
- 캐싱이나 요약 데이터가 필요한 경우
정규화는 데이터의 일관성을 보장하고 유지 관리가 용이하다는 장점이 있지만,
때로는 성능상 이유로 비정규화가 필요할 수도 있다."설계 초기엔 정규화, 성능 최적화 시 비정규화"가 일반적인 접근
Clarinetist.dev