1. 데이터베이스 정규화(Normalization): 1NF부터 BCNF까지 완벽 정리
데이터베이스 설계 시 가장 중요한 원칙 중 하나는 데이터 중복을 줄이고, 이상(Anomaly)을 방지하는 것입니다. 이를 위한 대표적인 기법이 바로 **정규화(Normalization)**입니다. 정규화는 테이블의 구조를 체계적으로 개선하여 데이터의 무결성과 효율성을 보장하는 핵심 과정입니다.
이번 글에서는 데이터베이스 정규화의 개념부터 1정규형(1NF), 2정규형(2NF), 3정규형(3NF), **BCNF(Boyce-Codd Normal Form)**까지 각 단계별 개념과 예시를 자세히 설명합니다. 정보처리기사 공부는 물론 실무에서도 유용하게 활용할 수 있는 내용을 담았으니 끝까지 집중해주세요.
1-1. 정규화란 무엇인가?
정규화(Normalization)는 데이터베이스 내의 테이블을 구조적으로 정제하여 중복을 최소화하고, 삽입·삭제·갱신 이상(Anomalies)을 방지하는 과정입니다.
정규화의 주요 목적:
- 데이터 중복 방지
- 데이터 무결성 유지
- 효율적인 테이블 구조 설계
- 관계형 데이터베이스 이론 기반의 논리적 모델링 수행
정규화는 1NF → 2NF → 3NF → BCNF → 4NF → 5NF 등으로 발전되며, 각 단계마다 더 강력한 제약 조건을 갖습니다. 이번 글에서는 정보처리기사에서 주로 다루는 1NF ~ BCNF까지에 집중하겠습니다.
1-2. 1정규형(1NF: First Normal Form)
정의:
모든 속성(컬럼)은 원자값(Atomic Value)만을 가져야 하며, 반복되는 그룹이 없어야 한다.
설명:
한 셀(속성)에 여러 개의 값이 들어 있는 중복 속성이나 반복 속성을 제거하고, 하나의 값만 존재하도록 구성합니다.
예시 (정규화 전):
학번 | 이름 | 전화번호 |
1001 | 홍길동 | 010-1111-2222, 010-3333-4444 |
→ 전화번호 필드에 두 개의 값이 들어 있음 → 원자성 위반
정규화 후:
학번 | 이름 | 전화번호 |
1001 | 홍길동 | 010-1111-2222 |
1001 | 홍길동 | 010-3333-4444 |
→ 각 레코드마다 원자값만 존재하도록 재구성
1-3. 2정규형(2NF: Second Normal Form)
정의:
1NF를 만족하며, 기본키의 부분집합이 결정자가 되는 종속성(부분 함수 종속성)을 제거해야 한다.
설명:
테이블의 기본키가 복합키인 경우, 일부 키에만 종속된 속성을 제거하여 별도의 테이블로 분리해야 합니다.
예시 (정규화 전):
학번 | 과목코드 | 교수명 |
1001 | CS101 | 김교수 |
1002 | CS101 | 김교수 |
→ (학번, 과목코드)가 복합키인데, 교수명은 과목코드에만 종속됨 → 부분 함수 종속
정규화 후:
수강 테이블
학번 | 과목코드 |
1001 | CS101 |
1002 | CS101 |
과목 테이블
과목코드 | 교수명 |
CS101 | 김교수 |
→ 교수명을 과목 정보로 분리하여 부분 함수 종속 제거
1-4. 3정규형(3NF: Third Normal Form)
정의:
2NF를 만족하고, 기본키가 아닌 속성 간에 이행적 종속(Transitive Dependency)이 없어야 한다.
설명:
어떤 속성이 기본키가 아닌 다른 일반 속성에 종속되어 있다면, 이를 제거해 독립 테이블로 분리합니다.
예시 (정규화 전):
학번 | 이름 | 학과코드 | 학과명 |
1001 | 홍길동 | C01 | 컴퓨터공학과 |
→ 학과명은 학과코드에 종속되고, 학과코드는 학번에 종속 → 이행적 종속 발생
정규화 후:
학생 테이블
학번 | 이름 | 학과코드 |
1001 | 홍길동 | C01 |
학과 테이블
학과코드 | 학과명 |
C01 | 컴퓨터공학과 |
→ 이행 종속 제거, 각 속성은 오직 기본키에만 종속됨
1-5. BCNF(Boyce-Codd Normal Form)
정의:
3NF를 만족하면서, 모든 결정자가 후보키여야 한다.
설명:
3NF에서 여전히 결정자가 후보키가 아닌 속성이 있다면 BCNF로 정규화해야 합니다.
예시 (정규화 전):
교수명 | 과목 | 강의실 |
김교수 | DB | 101호 |
김교수 | OS | 101호 |
→ 교수명 → 강의실, 교수명 + 과목 → 강의실
→ 교수명은 후보키가 아님에도 결정자 역할을 함 → BCNF 위반
정규화 후:
교수 테이블
교수명 | 강의실 |
김교수 | 101호 |
강의 테이블
교수명 | 과목 |
김교수 | DB |
김교수 | OS |
→ 모든 결정자가 후보키가 되도록 분해
1-7. 정규화와 반정규화, 언제까지 해야 할까?
정규화는 무조건 많이 한다고 좋은 것이 아닙니다.
읽기 성능이나 실시간 조회가 중요한 시스템에서는 너무 많은 테이블 분할이 오히려 성능을 저하시킬 수 있습니다.
이럴 땐 일부러 중복을 허용하는 반정규화(Denormalization) 전략을 선택하기도 합니다.
요약하자면:
- 1NF: 원자성 확보
- 2NF: 부분 종속 제거
- 3NF: 이행 종속 제거
- BCNF: 모든 결정자를 후보키로 제한
정규화를 통해 데이터의 무결성과 논리적 설계를 확보한 후, 운영 환경에 따라 반정규화도 유연하게 고려하는 것이 좋습니다.
1-8. 마무리
정규화는 데이터베이스 설계의 기초이자 핵심입니다.
복잡한 시스템일수록 데이터 무결성과 성능의 균형을 맞추는 것이 중요하며, 정규화는 이를 위한 첫걸음이라 할 수 있습니다.
정보처리기사 시험뿐만 아니라 실무에서도 1NF부터 BCNF까지의 원리를 이해하고 적용할 수 있어야, 논리적이고 오류 없는 데이터베이스 설계가 가능합니다.
이 글을 바탕으로 본인의 프로젝트 DB 스키마에 정규화를 적용해보는 것도 좋은 연습이 될 것입니다.
2. 고급 정규화 이론: 4NF, 5NF와 반정규화 전략까지 완벽 정리
앞선 글에서 우리는 1NF부터 BCNF까지의 정규화 단계를 상세히 살펴보았습니다.
하지만 복잡한 관계를 가지는 테이블 구조에서는 BCNF 이후에도 중복 문제나 이상 현상이 발생할 수 있습니다.
이를 해결하기 위해 존재하는 정규화가 바로 **4NF(제4정규형)**와 **5NF(제5정규형)**입니다.
이번 글에서는 고급 정규형의 개념과 예시, 그리고 실무에서 자주 사용하는 반정규화 전략까지 함께 정리하여, 데이터베이스 설계의 균형점을 잡는 데 도움이 될 수 있도록 구성했습니다.
2-1. 4정규형(4NF: Fourth Normal Form)
정의
BCNF를 만족하면서 다치 종속(Multi-valued Dependency, MVD)을 제거해야 한다.
다치 종속(MVD)이란?
어떤 속성 A가 B와 C를 각각 독립적으로 결정할 때, A →→ B, A →→ C와 같이 다중 값 간 독립적인 종속성이 존재하는 경우를 말합니다.
즉, 한 개의 기본키가 여러 개의 속성에 대해 서로 무관하게 여러 값을 가지는 경우가 다치 종속입니다.
예시 (정규화 전):
학번 | 외국어 | 자격증 |
1001 | 영어 | 정보처리 |
1001 | 일본어 | 정보처리 |
1001 | 영어 | 토익 |
1001 | 일본어 | 토익 |
→ 외국어와 자격증이 서로 독립적이지만, 학번에 대해 다치 종속된 관계
→ 중복 데이터 다량 발생
정규화 후:
학생-외국어 테이블
학번 | 외국어 |
1001 | 영어 |
1001 | 일본어 |
학생-자격증 테이블
학번 | 자격증 |
1001 | 정보처리 |
1001 | 토익 |
→ 다치 종속 제거 → 중복 방지 및 무결성 향상
2-2. 5정규형(5NF: Fifth Normal Form)
정의
4NF를 만족하면서 조인 종속성(Join Dependency)을 제거해야 한다.
조인 종속(Join Dependency)이란?
테이블을 여러 개로 나누었을 때, 원래 테이블을 정확히 복원하기 위해 반드시 세 개 이상을 조인해야 하는 경우를 말합니다.
즉, 불완전 분해 문제를 막기 위해 등장한 정규형입니다.
예시 (정규화 전):
공급자 | 제품 | 고객 |
A상사 | TV | 철수 |
A상사 | 냉장고 | 철수 |
A상사 | TV | 영희 |
A상사 | 냉장고 | 영희 |
→ 공급자와 제품, 고객이 각각 독립적인 관계이나, 이를 하나의 테이블에 저장하면 중복 발생
정규화 후:
공급자-제품 테이블
공급자 | 제품 |
A상사 | TV |
A상사 | 냉장고 |
공급자-고객 테이블
공급자 | 고객 |
A상사 | 철수 |
A상사 | 영희 |
제품-고객 테이블
제품 | 고객 |
TV | 철수 |
TV | 영희 |
냉장고 | 철수 |
냉장고 | 영희 |
→ 세 개의 테이블을 조인해야만 원래 데이터를 복원할 수 있음 → 조인 종속 제거
2-3. 반정규화(Denormalization)란?
정규화는 데이터 무결성과 중복 방지에 효과적이지만, 지나치게 분해하면 성능이 떨어질 수 있습니다.
특히 조회가 많은 OLAP 시스템에서는 조인 연산 비용이 커지고, 응답 속도가 느려질 수 있습니다.
이런 상황에서 사용하는 전략이 **반정규화(Denormalization)**입니다.
즉, 성능 향상이나 데이터 조회 편의성을 위해 일부 중복을 의도적으로 허용하는 것입니다.
2-4. 반정규화 전략 5가지
(1) 조인 대상 테이블 병합
- 자주 함께 조회되는 테이블을 하나로 통합
- 예: 학생 테이블 + 학과명 포함
(2) 컬럼 중복 저장
- 외래키 대신 상세 정보를 직접 저장
- 예: 고객ID 대신 고객이름도 함께 저장
(3) 집계 컬럼 추가
- 합계, 평균 등의 값을 실시간으로 계산하지 않고 컬럼으로 유지
- 예: 주문 수량 합계 total_qty 저장
(4) 테이블 분할
- 자주 조회되는 데이터를 메인 테이블에, 나머지를 보조 테이블에 저장
- 예: 게시판 본문과 댓글 분리
(5) 캐시 테이블 구성
- 자주 쓰는 데이터를 별도 테이블로 유지하여 조회 속도 향상
2-5. 정규화 vs 반정규화: 어떤 기준으로 결정할까?
항목 | 정규화 | 반정규화 |
목적 | 데이터 무결성, 중복 제거 | 성능 향상, 조회 최적화 |
테이블 수 | 많아짐 | 줄어듦 |
조인 | 많아짐 | 줄어듦 |
성능 | 느릴 수 있음 | 빠름 (조건부) |
유지보수 | 논리적으로 용이 | 물리적으로 복잡할 수 있음 |
정규화는 기본, 반정규화는 선택입니다.
처음에는 정규화된 설계로 시작하고, 이후 시스템 성능 테스트를 거쳐 부분적으로 반정규화하는 방식이 일반적입니다.
2-6. 마무리: 정규화는 데이터베이스의 뼈대다
정규화는 단순한 이론이 아니라, 데이터를 구조적으로 이해하고 설계하는 능력입니다.
1NF부터 5NF까지 각 단계는 점점 더 복잡한 데이터 관계를 다루며, 설계자의 수준도 함께 요구됩니다.
하지만 현업에서는 반드시 정규화와 반정규화의 균형이 중요합니다.
무조건 정규화하거나, 성능 때문에 무분별하게 반정규화하는 것은 모두 바람직하지 않습니다.
정규화로 문제를 예방하고, 반정규화로 현실적인 운영을 보완하는 것 — 그것이 바로 실전 데이터베이스 설계의 핵심입니다.
3. 정규화의 핵심, 이상현상과 ER 다이어그램에서 정규형 도출 방법
정규화는 단순히 테이블을 분해하는 과정이 아닙니다.
진짜 목적은 데이터베이스에서 발생할 수 있는 **이상현상(Anomaly)**을 제거하고, 효율적이고 안정적인 시스템을 구축하는 데 있습니다.
이번 글에서는 삽입 이상, 삭제 이상, 갱신 이상의 의미와 실제 예시를 통해 이상현상의 위험성을 짚어보고,
실제 ER 다이어그램(개체-관계 모델)에서 어떻게 정규형으로 테이블을 도출하는지도 단계별로 정리해 보겠습니다.
3-1. 이상현상(Anomalies)란?
이상현상이란 데이터베이스의 설계 미비로 인해 발생하는 부작용을 말합니다.
정규화되지 않은 테이블에서는 다음과 같은 문제가 자주 발생합니다.
(1) 삽입 이상 (Insertion Anomaly)
데이터를 일부만 입력하려 해도 전체 필드가 채워져야 하는 상황
예시: 교수 테이블
교수ID | 교수이름 | 과목 |
001 | 김교수 | 데이터베이스 |
→ 과목 배정 전인 교수는 입력 불가
→ **“과목이 없는 교수는 테이블에 입력할 수 없다”**는 모순 발생
(2) 삭제 이상 (Deletion Anomaly)
하나의 정보만 삭제하고 싶었는데, 다른 중요한 정보까지 함께 사라지는 현상
예시: 다음 행을 삭제하면 해당 교수 정보 자체가 사라짐
교수ID | 교수이름 | 과목 |
002 | 이교수 | 운영체제 |
→ 이교수가 더 이상 과목을 담당하지 않게 되었을 때, 해당 행 삭제 시 교수 정보 자체도 사라짐
(3) 갱신 이상 (Update Anomaly)
중복된 데이터가 많아 한 곳만 수정하면 불일치가 생기는 현상
예시:
교수ID | 교수이름 | 과목 |
001 | 김교수 | DB |
001 | 김교수 | 운영체제 |
→ 김교수가 “박교수”로 변경되었을 때, 한 행만 수정하면 데이터 불일치 발생
이상현상 정리 표
이상현상 유형 | 발생 상황 | 해결 방법 |
삽입 이상 | 일부만 입력 불가 | 테이블 분해 |
삭제 이상 | 하나 삭제로 전체 소실 | 종속성 제거 |
갱신 이상 | 데이터 불일치 발생 | 중복 제거 |
→ 이 모든 이상은 정규화를 통해 제거할 수 있습니다.
3-2. ER 다이어그램에서 정규형 도출 절차
정규화를 실무에 적용하기 위해서는 **ERD(Entity Relationship Diagram)**에서 관계를 분석하고, 테이블로 변환하는 절차가 필수입니다.
Step 1: 개체(Entity) 추출
- 사람, 상품, 부서, 고객 등 ‘명사’ 중심으로 핵심 개체를 식별
- 각 개체는 **고유 식별자(기본키)**를 가져야 함
예:
- 고객(Customer), 주문(Order), 제품(Product)
Step 2: 관계(Relationship) 도출
- 개체 간의 상호작용을 파악 (주문한다, 포함된다, 담당한다 등)
- 관계형 데이터베이스에서는 관계도 별도 테이블로 변환됨 (especially 다:다)
예:
- 고객은 여러 개의 주문을 한다 → 1:N 관계 → 외래키(FK) 활용
- 주문과 제품은 다:다 관계 → 중간 테이블 필요 (OrderDetail)
Step 3: 속성(Attribute) 분류
- 개체별로 필요한 속성 정의
- 원자성 위반되는 복합 속성은 분해 (정규화 1NF)
예:
- 고객: 고객ID, 이름, 전화번호
- → 전화번호가 여러 개인 경우 전화번호 테이블로 분리
Step 4: 관계형 스키마로 변환
- 각 개체 → 테이블
- 관계 → 외래키로 연결 또는 별도 테이블
- 다치/이행/부분 종속 존재 여부에 따라 2NF ~ BCNF 적용
Step 5: 정규형 검토 및 이상현상 제거
- 종속성 파악 (A → B)
- 부분/이행/다치 종속 여부 확인
- 중복 발생 시 테이블 분할
3-3. ERD 예시와 정규화 흐름
초기 ERD 예시 (학생-과목 관계)
- 개체: 학생(Student), 과목(Subject)
- 관계: 수강(Takes)
초기 테이블
학번 | 이름 | 과목코드 | 과목명 |
1001 | 홍길동 | CS101 | 자료구조 |
→ 문제점: 과목코드 → 과목명 이행 종속 존재
정규화된 테이블 구성
- 학생(Student): 학번(PK), 이름
- 과목(Subject): 과목코드(PK), 과목명
- 수강(Takes): 학번(FK), 과목코드(FK)
→ 이행 종속 제거 → 3NF 만족 → 이상현상 제거
3-4. 실무에서의 응용 팁
- 정규화는 논리적 모델링 단계에서 적용
- 설계 초기에 정규화해두면 향후 구조 변경을 최소화할 수 있음
- 정규화 → 성능 이슈 발생 시 반정규화
- 데이터량이 많고 조인 비용이 높을 때만 선택적으로 반정규화
- ERD 도구 활용 추천
- MySQL Workbench, ERDCloud, dbdiagram.io 등으로 관계 시각화
- 종속성 분석은 항상 기본키 중심
- 속성이 기본키 전체에 종속되는지, 일부에만 종속되는지 확인
3-5. 마무리
정규화는 단순한 암기 과목이 아니라, 이상현상을 사전에 방지하고 데이터 일관성을 유지하는 전략적인 사고방식입니다.
특히 실무에서는 **ER 다이어그램을 기반으로 논리적 정규형 구조를 만들고, 이후 물리적 구현 단계에서 성능 중심의 조정(반정규화)**을 진행해야 합니다.
정규화는 단순히 “문제를 피하기 위한 수단”이 아니라, 신뢰할 수 있는 데이터 시스템을 만드는 기본 골격입니다.
지금 설계하고 있는 데이터베이스가 이상현상 없이 잘 정규화되어 있는지, 오늘 이 글을 바탕으로 점검해보세요.
'IT개발' 카테고리의 다른 글
ER 모델에서 관계형 스키마로 변환하는 절차 (0) | 2025.05.05 |
---|---|
SQL DDL, DML, DCL 명령어 정리 및 활용 예시 (0) | 2025.05.05 |
On-Device AI(Edge AI) 모델 경량화와 TensorFlow Lite 최적화 (0) | 2025.05.05 |
AI 윤리·편향(Bias) 모니터링·완화 전략 (0) | 2025.05.05 |
하이퍼파라미터 최적화 자동화: Optuna vs Ray Tune 비교 (0) | 2025.05.05 |