데이터베이스 정규화 - 어디까지 해야 할까?

 

정규화는, 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까지만, 상황에 따라 유연하게 정규화는 도구일 뿐, 목적이 아니다.

때에 따라, 상황에 따라 비즈니스 요구사항과 성능을 균형있게 고려하는 게 진짜 실력인 것 같다.