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
반응형