데이터베이스 정규화와 무결성을 지키는 스키마 설계
데이터베이스 정규화의 이상 현상, 1NF부터 5NF까지의 종속성 원칙, 비정규화와 성능 최적화의 균형을 정리한다.
2026-08-14 · 최초 발행 2025-08-10
중복 데이터가 만드는 설계 문제
정규화(Normalization)는 관계형 데이터베이스를 설계할 때 데이터 중복을 줄이고 무결성을 유지하기 위한 체계다. 저장 공간을 효율적으로 쓰는 것만이 목적은 아니다. 데이터가 바뀌었을 때 구조를 다루기 쉽게 만들고, 일관성 있는 상태를 유지하며, 쿼리 처리를 뒷받침하는 데도 쓰인다.
중복된 구조를 그대로 두면 다음과 같은 이상 현상이 생긴다.
- 삽입 이상(Insertion Anomaly): 원하는 데이터를 넣기 위해 관계없는 데이터까지 함께 넣어야 한다.
- 삭제 이상(Deletion Anomaly): 삭제 대상이 아닌 필요한 정보까지 함께 사라진다.
- 갱신 이상(Update Anomaly): 같은 정보가 여러 곳에 있어 일부만 바뀌고 불일치가 발생한다.
원자값에서 조인 종속성까지
제1정규형(1NF): 한 칸에는 하나의 값만 둔다
제1정규형은 모든 속성이 원자값(Atomic Value)만 갖는 상태다. 즉, 테이블의 각 셀에는 단일 값만 들어가야 한다.
[비정규화 상태]
| 학번 | 이름 | 수강과목 |
|---|---|---|
| 101 | 김철수 | 수학, 영어, 과학 |
[1NF 적용 후]
| 학번 | 이름 | 수강과목 |
|---|---|---|
| 101 | 김철수 | 수학 |
| 101 | 김철수 | 영어 |
| 101 | 김철수 | 과학 |
제2정규형(2NF): 복합 키의 일부에만 매달린 값을 분리한다
제2정규형은 1NF를 만족하면서 부분 함수적 종속성을 없앤 상태다. 기본키가 아닌 모든 속성이 기본키 전체에 완전 함수적 종속을 가져야 하며, 복합 기본키를 가진 테이블이 적용 대상이다.
[1NF 상태]
| 학번 | 과목코드 | 학생이름 | 과목명 | 성적 |
|---|---|---|---|---|
| 101 | M001 | 김철수 | 수학 | A |
| 101 | E001 | 김철수 | 영어 | B |
| 102 | M001 | 이영희 | 수학 | B+ |
[2NF 적용 후]
테이블1: 수강
| 학번 | 과목코드 | 성적 |
|---|---|---|
| 101 | M001 | A |
| 101 | E001 | B |
| 102 | M001 | B+ |
테이블2: 학생
| 학번 | 학생이름 |
|---|---|
| 101 | 김철수 |
| 102 | 이영희 |
테이블3: 과목
| 과목코드 | 과목명 |
|---|---|
| M001 | 수학 |
| E001 | 영어 |
제3정규형(3NF): 키가 아닌 속성 사이의 의존을 없앤다
제3정규형은 2NF를 충족하고 이행적 함수 종속성을 제거한 구조다. 기본키가 아닌 속성은 기본키에 직접 종속해야 하며, 다른 비키 속성을 거쳐 종속되면 안 된다.
[2NF 상태]
| 학번 | 학과코드 | 학과명 | 학생이름 |
|---|---|---|---|
| 101 | CS01 | 컴퓨터공학 | 김철수 |
| 102 | EE01 | 전자공학 | 이영희 |
| 103 | CS01 | 컴퓨터공학 | 박지민 |
[3NF 적용 후]
테이블1: 학생
| 학번 | 학과코드 | 학생이름 |
|---|---|---|
| 101 | CS01 | 김철수 |
| 102 | EE01 | 이영희 |
| 103 | CS01 | 박지민 |
테이블2: 학과
| 학과코드 | 학과명 |
|---|---|
| CS01 | 컴퓨터공학 |
| EE01 | 전자공학 |
BCNF: 모든 결정자를 후보키로 제한한다
BCNF(Boyce-Codd 정규형)는 3NF를 더 엄격하게 적용한 형태다. 함수적 종속성 X→Y가 있을 때 X는 반드시 슈퍼키여야 한다. 다시 말해 모든 결정자가 후보키인 상태를 요구한다.
[3NF 상태]
| 학번 | 과목 | 교수 |
|---|---|---|
| 101 | 수학 | 김교수 |
| 102 | 수학 | 김교수 |
| 103 | 영어 | 이교수 |
| 101 | 영어 | 이교수 |
// 여기서는 (학번, 과목)이 기본키이지만 (과목)→(교수)의 함수적 종속관계도 존재
[BCNF 적용 후]
테이블1: 수강
| 학번 | 과목 |
|---|---|
| 101 | 수학 |
| 102 | 수학 |
| 103 | 영어 |
| 101 | 영어 |
테이블2: 담당교수
| 과목 | 교수 |
|---|---|
| 수학 | 김교수 |
| 영어 | 이교수 |
제4정규형(4NF): 독립적인 다중 값을 분리한다
제4정규형은 BCNF를 만족하면서 다치 종속성을 제거한다. 비자명 다치 종속성 X→→Y가 있을 경우 X는 슈퍼키여야 한다.
[BCNF 상태]
| 학생 | 동아리 | 취미 |
|---|---|---|
| 김철수 | 축구부 | 게임 |
| 김철수 | 축구부 | 독서 |
| 김철수 | 밴드부 | 게임 |
| 김철수 | 밴드부 | 독서 |
[4NF 적용 후]
테이블1: 학생동아리
| 학생 | 동아리 |
|---|---|
| 김철수 | 축구부 |
| 김철수 | 밴드부 |
테이블2: 학생취미
| 학생 | 취미 |
|---|---|
| 김철수 | 게임 |
| 김철수 | 독서 |
제5정규형(5NF): 조인으로 생기는 종속성을 다룬다
제5정규형은 4NF를 만족하면서 조인 종속성을 제거한 상태다. 모든 조인 종속성은 후보키를 통해서만 성립해야 한다. 실무에서 5NF까지 정규화하는 경우는 드물다.
정규화와 비정규화 사이의 선택
정규화는 데이터 중복을 최소화하고 저장 공간을 절약하며, 일관성과 무결성을 지키고 스키마 변경을 쉽게 만든다. 반면 테이블이 늘어나면 조인 연산도 증가하고, 쿼리가 복잡해지거나 성능이 떨어질 수 있다.
읽기 중심의 작업이 많거나 특정 쿼리의 실행 속도가 중요하고 데이터 변경이 적다면 비정규화(De-normalization)를 검토할 수 있다. 성능 최적화가 필요한 상황에서도 같은 판단이 필요하다.
관계를 분리해 표현하는 데이터 모델
전자상거래 데이터베이스에서는 고객, 주문, 주문 항목, 상품, 카테고리를 분리해 관계를 표현할 수 있다.
금융 시스템에서는 계좌와 거래, 고객과 계좌의 관계를 분리해 관리할 수 있다.
요구사항에서 성능 검토까지
정규화는 테이블을 기계적으로 쪼개는 작업이 아니다. 현업 요구사항에서 데이터 항목과 업무 규칙을 파악한 뒤, 엔티티와 속성을 식별하고 엔티티 간 관계 및 종속성을 분석해야 한다. 이후 1NF부터 순서대로 적용하고, 정규화된 모델의 쿼리 성능을 검토한다. 성능 문제가 있으면 선택적으로 비정규화를 적용한 뒤 테스트 데이터로 스키마를 검증한다.
정규화 수준은 데이터 변경 빈도, 조회 패턴, 데이터 볼륨, 시스템 특성, 유지보수 복잡성에 따라 달라진다. 변경이 잦을수록 높은 정규화가 필요하다. 조인이 많은 복잡한 쿼리가 빈번하거나 대용량 데이터를 다뤄 성능을 검토해야 한다면 비정규화를 고려할 수 있다. OLTP와 OLAP도 서로 다른 접근이 필요하며, 변경 가능성이 높은 부분에는 높은 정규화가 권장된다.
모델링 도구와 성능 보완책
ERD(Entity-Relationship Diagram)는 엔티티와 관계를 시각화해 정규화 작업을 지원한다. PowerDesigner는 물리·논리 데이터 모델링과 정규화 기능을 제공하며, ERwin은 자동 정규화 및 역정규화 기능을 제공한다. MySQL Workbench는 무료 도구로 ER 다이어그램 작성과 정규화를 지원하고, Lucidchart와 draw.io에서는 온라인으로 ER 다이어그램을 작성할 수 있다.
정규화된 테이블에는 적절한 인덱스 전략이 필요하다. 자주 쓰는 조인 쿼리는 뷰(View)로 만들어 사용성을 높일 수 있으며, 대용량 테이블은 파티셔닝으로 관리할 수 있다. 자주 사용하는 데이터는 캐싱으로 보완하고, 실행 계획을 분석해 쿼리를 최적화한다.
실무에서는 3NF 또는 BCNF까지 정규화하는 경우가 일반적이다. 데이터 무결성과 성능은 상충할 수 있으므로, 비즈니스 요구사항과 시스템 특성에 맞춰 비정규화를 함께 판단해야 한다.