DB
데이터베이스 정규화 - 어디까지 해야 할까?
ZZJJing
2025. 5. 26. 20:37
반응형
정규화는, 3NF까지만 해도 90% 충분함
■ 정규화 단계별 정리 (정처기에서 배운 것들을 써본다..)
1NF (제1정규형)
- 핵심: 원자값만 저장
- 예시: 취미: 독서,영화,음악 → 별도 테이블로 분리
- 실무: 무조건 지켜야 함
2NF (제2정규형)
- 핵심: 부분 함수 종속 제거
- 쉽게: 복합키의 일부에만 의존하는 컬럼 분리
- 실무: 대부분 자연스럽게 지켜짐
3NF (제3정규형)
- 핵심: 이행적 함수 종속 제거
- 쉽게: A→B→C 관계를 A→B, B→C로 분리
- 실무: 여기까지가 황금 기준
BCNF (Boyce-Codd 정규형)
- 핵심: 모든 결정자가 후보키
- 실무: 복잡함. 특수한 경우에만 고려
4NF, 5NF
- 솔직히: 실무에서 거의 안 씀
- 이유: 복잡도 증가 > 얻는 이익
실무에서는?
3NF까지 하는 이유
- 데이터 중복 최소화
- 업데이트 이상 방지
- 저장공간 효율화
- 데이터 일관성 보장
과도한 정규화의 문제점
- JOIN 연산 증가 → 성능 저하
- 쿼리 복잡도 증가
- 개발 생산성 저하
- 유지보수 어려움
■ 실무 팁
JOIN 성능 최적화
-- 자주 조회되는 데이터는 비정규화 고려
CREATE TABLE order_summary (
order_id INT,
customer_name VARCHAR(100), -- 정규화라면 customer 테이블 참조
total_amount DECIMAL(10,2)
);
읽기 전용 뷰 활용
-- 정규화된 테이블 + 조회용 뷰
CREATE VIEW customer_order_view AS
SELECT c.name, o.order_date, o.total
FROM customers c JOIN orders o ON c.id = o.customer_id;
캐싱 테이블 전략
- 정규화된 원본 테이블 유지
- 성능을 위한 비정규화 캐시 테이블 별도 생성
- 배치로 동기화
정리하자면
- 무작정 5NF까지 정규화는 비추천
- 성능 고려 없는 설계하면 안된다
- 비즈니스 로직 무시한 정규화는 불필요
- 비즈니스 요구사항 우선시 하기
- 조회 패턴 분석
- 성능 테스트 필수
- 팀 역량 고려
3NF까지만, 상황에 따라 유연하게 정규화는 도구일 뿐, 목적이 아니다.
때에 따라, 상황에 따라 비즈니스 요구사항과 성능을 균형있게 고려하는 게 진짜 실력인 것 같다.
728x90
반응형