normalization-patterns - SKILL.md Agent Skill

name: normalization-patterns description: "데이터베이스 정규화/비정규화 패턴 라이브러리. 1NF~BCNF 판별 기준, 함수 종속성 분석, 정규화 단계별 변환 절차, 전략적 비정규화 패턴, 공통 도메인 ERD 템플릿을 제공하는 data-modeler 확장 스킬. '정규화', '비정규화', 'ERD 패턴', '함수 종속성', '테이블 분리', '관계 설계' 등 데이터 모델링 시 사용한다. 단, DDL 생성이나 쿼리 최적화는 이 스킬의 범위가 아니다."

Normalization Patterns — 정규화/비정규화 패턴 라이브러리

data-modeler 에이전트가 데이터 모델링 시 활용하는 정규화 규칙, 비정규화 전략, 도메인별 ERD 패턴.

대상 에이전트

data-modeler — 이 스킬의 정규화 규칙과 ERD 패턴을 데이터 모델 설계에 직접 적용한다.

정규화 단계 판별 & 변환

1NF (제1정규형)

규칙: 모든 컬럼은 원자값(atomic value)이어야 한다.

위반 패턴	문제	해결
다중값 컬럼	`tags = "java,python,go"`	별도 테이블 분리 (M:N)
반복 그룹	`phone1, phone2, phone3`	별도 테이블 분리 (1:N)
복합값	`address = "서울시 강남구 역삼동"`	시/구/동 컬럼 분리

2NF (제2정규형)

전제: 1NF 만족 규칙: 부분 함수 종속성 제거 — 복합 기본키의 일부에만 종속되는 컬럼 분리.

위반 예	종속 관계	해결
`주문상세(주문ID, 상품ID, 상품명, 수량)`	상품명 → 상품ID에만 종속	상품 테이블 분리

3NF (제3정규형)

전제: 2NF 만족 규칙: 이행적 함수 종속성 제거 — 기본키가 아닌 컬럼이 다른 비키 컬럼을 결정하면 안 됨.

위반 예	종속 관계	해결
`직원(ID, 부서ID, 부서명, 부서장)`	부서명, 부서장 → 부서ID 종속 (이행적)	부서 테이블 분리

BCNF (보이스-코드 정규형)

규칙: 모든 결정자(determinant)가 후보키여야 한다.

위반 예	문제	해결
`수강(학생, 과목, 교수)` 여기서 교수→과목	교수가 결정자이지만 후보키 아님	교수-과목 테이블 분리

정규화 결정 흐름도

데이터 분석
  ├─ 원자값 위반? → 1NF 변환
  ├─ 복합키 & 부분 종속? → 2NF 변환
  ├─ 이행적 종속? → 3NF 변환
  ├─ 비후보키 결정자? → BCNF 변환
  └─ 성능 요구사항 → 전략적 비정규화 검토

전략적 비정규화 패턴

언제 비정규화하는가?

읽기 >> 쓰기 비율이 높을 때
JOIN이 5개 이상 필요한 빈번한 쿼리
실시간 집계/통계가 필요할 때
대시보드/리포트 전용 데이터

비정규화 패턴 카탈로그

패턴	설명	적합 상황	트레이드오프
파생 컬럼	계산값 저장 (`total_price`)	빈번한 합계 조회	갱신 시 동기화 필요
중복 컬럼	FK 대상의 자주 쓰는 컬럼 복사	JOIN 회피	데이터 불일치 위험
사전 조인 테이블	조인 결과를 물리 테이블로	리포트/대시보드	저장 공간, 갱신 복잡
히스토리 스냅샷	시점 데이터 보존 (`order_address`)	주문 시점 주소 보관	저장 공간
카운터 컬럼	`likes_count`, `comments_count`	실시간 카운트 표시	동시성 처리
JSON/JSONB	구조화되지 않은 확장 데이터	설정, 메타데이터	인덱싱 제한

공통 도메인 ERD 패턴

이커머스

users ──1:N──> orders ──1:N──> order_items
  │                                 │
  └──1:N──> addresses          products
  └──1:N──> reviews ──N:1──────┘
                               │
products ──N:M──> categories (via product_categories)
products ──1:N──> product_images
products ──1:N──> product_variants

핵심 테이블:

users (id, email, name, password_hash, created_at)
products (id, name, description, base_price, status)
orders (id, user_id, status, total, shipping_address_snapshot)
order_items (id, order_id, product_id, variant_id, quantity, unit_price)

SaaS 멀티테넌트

tenants ──1:N──> users ──N:M──> roles (via user_roles)
   │                              │
   └──1:N──> subscriptions    permissions ──N:M──> roles
   └──1:N──> [도메인 테이블] (tenant_id FK)

핵심: 모든 비즈니스 테이블에 tenant_id 포함, RLS(Row Level Security) 적용

소셜 네트워크

users ──N:M──> users (via follows: follower_id, following_id)
  │
  └──1:N──> posts ──1:N──> comments
  │              └──N:M──> tags (via post_tags)
  │              └──1:N──> likes (user_id + post_id UNIQUE)
  └──1:N──> messages (sender_id, receiver_id)

CMS/블로그

users ──1:N──> posts ──N:M──> tags (via post_tags)
                 │
                 └──1:N──> comments (self-referencing: parent_id)
                 └──1:N──> media
                 └──1:1──> post_meta (SEO, OG 등)

관계 패턴

1:1 관계

큰 테이블 분할 (자주 쓰는 컬럼 vs 가끔 쓰는 컬럼)
선택적 확장 (user + user_profile)
구현: FK + UNIQUE 제약

1:N 관계

가장 흔한 관계
자기참조: 카테고리 트리, 댓글 스레드 (parent_id)
구현: 자식 테이블에 FK

M:N 관계

중간 테이블(junction table) 필수
중간 테이블에 추가 속성 가능 (created_at, role, quantity)
네이밍: {table1}_{table2} 또는 의미 있는 이름 (enrollments)

공통 컬럼 패턴

기본 타임스탬프

모든 테이블에 포함:

id — UUID 또는 BIGINT AUTO_INCREMENT
created_at — TIMESTAMPTZ DEFAULT NOW()
updated_at — TIMESTAMPTZ, 트리거로 자동 갱신

Soft Delete

deleted_at — TIMESTAMPTZ NULL (NULL이면 미삭제)
모든 쿼리에 WHERE deleted_at IS NULL 조건
복원 가능, 감사 로그 역할

상태 관리

status — ENUM 또는 VARCHAR
상태 전이 규칙 문서화 필수 (어떤 상태에서 어떤 상태로?)
이력이 필요하면 별도 status_history 테이블

다국어

전략 1: 컬럼 확장 (name_ko, name_en, name_ja)
전략 2: 번역 테이블 (product_translations: product_id, locale, name, description)
전략 2 권장 (언어 추가 시 스키마 변경 불필요)