※ IT: RDBMS Normalization.
안녕하세요. 듀스트림입니다.
오늘의 내용은 정규화입니다. 너무 오래되서 한번 정리해봤습니다.
정규화(Normalization)?
데이터베이스 설계에서 데이터 중복을 줄이고 무결성을 높이기 위해 데이터를 구조화하는 과정입니다.
즉, 테이블(릴레이션) 내에 중복된 데이터를 허용하지 않도록 여러 단계에 걸쳐 테이블을 분해하고 각 테이블이 논리적으로 잘 조직되도록 만드는 것이 목적입니다.
Edgar F. Codd가 처음 제안했고, 이후 Boyce-Codd·Fagin 등이 고급 정규형을 확장했습니다.
정규화의 목표
- 데이터 중복 제거: 동일한 정보가 여러 곳에 저장되는 것을 방지합니다.
- 데이터 무결성 유지: 데이터의 일관성과 정확성을 보장합니다.
- 저장 공간 절약: 불필요한 중복 데이터를 줄여 저장 용량을 효율적으로 사용합니다.
- 이상 현상(Anomaly) 방지: 삽입, 삭제, 갱신 시 발생할 수 있는 데이터 불일치 문제를 줄입니다.
전제 조건
- 관계형 데이터베이스 모델: 정규화는 관계형 데이터베이스 설계에서 적용하는 개념입니다. 테이블(릴레이션) 구조를 기반으로 합니다.
- 기본키(Primary Key) 존재: 각 테이블은 유일하게 각 행을 식별할 수 있는 기본키가 필요합니다. 이는 정규화 단계의 출발점입니다.
- 속성의 원자성(Atomicity): 제1정규형(1NF)에서는 모든 컬럼이 원자값(더 이상 분해할 수 없는 값)을 가져야 합니다.
- 함수적 종속성 파악: 속성 간의 함수적 종속성(어떤 속성이 다른 속성에 의해 결정되는 관계)을 이해하고 있어야 정규화 단계를 적용할 수 있습니다.
- 업데이트 이상(Anomaly) 문제 인식: 데이터 삽입, 수정, 삭제 시 발생할 수 있는 이상 현상을 해결하려는 목적이 있어야 합니다.
핵심 개념 요약표
| 개념 | 설명 |
| Functional Dependency (함수적 종속) |
X → Y: 속성 X의 값이 같으면 Y의 값도 반드시 같다. 즉, X가 Y를 결정한다는 의미로 정규형(정규화 단계)은 이 함수적 종속성을 기준으로 정의됩니다. |
| Candidate Key / Super Key (후보키 / 슈퍼키) |
모든 레코드를 유일하게 식별하는 최소/최대 속성 집합입니다. 슈퍼키는 유일성을 보장하는 속성 집합 전체를 의미하고 후보키는 그중에서 최소인 것을 의미합니다. 테이블의 각 행을 구분할 때 사용합니다. |
| Anomalies (이상 현상) |
Insert, Update, Delete 시 원치 않는 부작용(데이터 불일치, 손실 등)이 발생하는 현상입니다. (삽입 이상, 삭제 이상, 갱신 이상 등이 대표적입니다.) 정규화의 목적은 이런 이상 현상을 방지하는 데 있습니다. |
- 함수적 종속은 테이블 내 속성 간의 관계를 정의하고
- 후보키/슈퍼키는 테이블의 유일성을 보장하며
- 이상 현상은 정규화가 반드시 해결해야 할 데이터베이스의 문제를 의미합니다.
정규형과 규칙
| 단계 | 규칙 |
| 1NF | 모든 셀은 원자값(atomic), 반복/집합 금지 |
| 2NF | 1NF + 부분적 종속 제거(복합키의 부분집합에 종속 금지) |
| 3NF | 2NF + 이행 종속 제거(Non-Key → Non-Key 금지) |
| BCNF | 3NF + 모든 함수적 종속의 LHS가 Candidate Key |
| 4NF | BCNF + 다치 종속(MVD) 제거 |
| 5NF (PJ/NF) | 4NF + 조인 종속(Join Dependency) 제거 (모든 조인 종속이 후보키로 함축) |
| 6NF | 5NF + 모든 비자명 조인 종속 제거 → 테이블이 더 이상 분해 불가 |
정규화 절차
- 요구사항 분석 → 속성·관계 정의
- 1NF 체크(중첩/반복 필드 제거)
- 후보키 설정 후 2NF, 3NF 위반 검출·분해
- 복수 후보키 / 다치·조인 종속 존재 여부 확인 → BCNF·4NF·5NF 적용
- 성능·쿼리 패턴 고려해 정규형 완화(denormalization) 여부 결정
정규화의 장점
| 장점 | 설명 |
| 무결성 강화 | FK 및 UNIQUE 제약이 간결, 중복 방지로 데이터 품질 향상 |
| 쓰기 성능 | 동일 정보 다중 업데이트 필요 없으므로 Update Anomaly 제거 |
| 스토리지 | 중복 컬럼 제거로 저장공간 절약 |
| 유지보수 | 스키마 변경 영향 범위 최소화 |
정규화의 한계
| 한계 / Trade-off | 대응책 |
| JOIN 증가로 읽기 속도↓ | 자주 조회되는 조합은 Materialized View·파티셔닝, 또는 부분 Denormalization (Reporting DB) |
| 복잡한 스키마 | ORM Mapping 복잡-> View / API 계층 추상화 |
| 분산 캐시 중복 | Redis 등 캐시 계층에 Aggregate Data 저장 |
정규화 vs 비정규화 선택 시나리오
| 시나리오 | 권장 |
| OLTP(트랜잭션) | 3NF 또는 BCNF 유지, 데이터 무결성·동시성 우선 |
| DW/OLAP | Star Schema(비정규화) + ETL로 주기적 적재 |
| Logging / Time-series | 6NF 수준까지 열 단위 분해 → 파샤(Parquet) · TimescaleDB 등 고려 |
| Edge-Cache | 비정규화된 Regional Replica Table 생성(읽기 전용) |
PostgreSQL 적용 팁
- 외래키 지연(DEFERRABLE INITIALLY DEFERRED)
- 트랜잭션 종료 시점 검증으로 배치 적재 성능 확보.
- 배열·JSONB vs 정규화
- 자유도 높은 semi-structured 데이터는 JSONB, 핵심 엔티티는 정규형 유지 → 조인 대비 인덱스 선택성 평가.
- EXPLAIN으로 조인 비용 확인
- 너무 잦은 조인은 읽기 최적화를 위해 Star Schema 또는 denormalized summary table 검토.
- VACUUM / HOT Update
- 정규화된 테이블은 업데이트 범위가 좁아 HOT(Heap-Only Tuple) 적용률↑ → 페이지 단편화 감소, I/O 절약.
- 파티셔닝
- PK·FK 설계 후 파티션 키 후보를 식별, 파티션 간 조인 최소화 설계(예: Range by date + FK 포함).
요약
- 정규화는 데이터 중복 제거와 이상 방지를 위한 체계적 분해 절차.
- 1NF→6NF로 갈수록 제약 조건이 엄격해지며 무결성은 높아지지만 읽기 성능과 복잡성이 증가.
- PostgreSQL 환경에서는 FK, 인덱스, 파티셔닝, Materialized View를 적절히 활용해 무결성과 성능 균형을 맞추는 것이 핵심.
- 실제 설계는 Workload 패턴·쿼리 빈도·서비스 SLA를 기준으로 3NF 정도에서 마무리.
- 보고·검색 용도에는 선택적 비정규화를 적용하는 혼합 전략이 일반적.
오늘은 여기까지~
'IT 여러가지' 카테고리의 다른 글
| IT: RDBMS 스타스키마 (1) | 2025.07.09 |
|---|---|
| IT: RDBMS 반정규화 (2) | 2025.07.08 |
| IT: 데이터 이행 (1) | 2025.05.25 |
| IT: 데이터 클렌징 (0) | 2025.05.25 |
| IT: YAML(YML) (1) | 2025.03.04 |