메뉴 여닫기
개인 메뉴 토글
로그인하지 않음
만약 지금 편집한다면 당신의 IP 주소가 공개될 수 있습니다.
Dbstudy (토론 | 기여)님의 2026년 11월 4일 (수) 12:35 판 (새 문서: <div style="background:linear-gradient(135deg,#7a3e0c 0%,#c0620f 55%,#e67e22 100%);color:#ffffff;padding:30px 36px;border-radius:14px;margin-bottom:24px;box-shadow:0 4px 14px rgba(122,62,12,0.25);"> <div style="font-size:12px;letter-spacing:3px;opacity:0.8;margin-bottom:6px;">DATA MODELING · STEP 3 DEEP DIVE</div> <div style="font-size:28px;font-weight:700;line-height:1.3;">정규화 심화</div> <div style="font-size:15px;opacity:0.92;margin-top:10px;line-height:1.7;">함수...)
(차이) ← 이전 판 | 최신판 (차이) | 다음 판 → (차이)
DATA MODELING · STEP 3 DEEP DIVE
정규화 심화
함수 종속성 이론부터 BCNF · 4NF · 5NF, 그리고 실무에서의 판단 기준까지

선수 학습 · 데이터 모델링 입문 5장 커리큘럼 · 7~8주차 난이도 · 중급

1. 정규화를 다시 보다

정규화는 "테이블을 쪼개는 기술"이 아니라 하나의 사실(Fact)을 한 곳에만 저장하도록 만드는 원칙이다. 쪼개는 것은 결과일 뿐이며, 기준은 언제나 함수 종속성이다.

핵심 문장 — "모든 비키 속성은 키에, 키 전체에, 그리고 키 외에는 아무것에도 종속되지 않아야 한다."
(The key, the whole key, and nothing but the key) — 각각 1NF · 2NF · 3NF에 대응

2. 함수 종속성 이론

2.1 기본 용어

용어 표기 설명
함수 종속 X → Y X 값이 같으면 Y 값도 반드시 같다
완전 함수 종속 X ⇒ Y Y가 X 전체에 종속, X의 진부분집합에는 종속되지 않음
부분 함수 종속 (A,B) → C, A → C 복합키의 일부만으로 C가 결정됨
이행 함수 종속 A → B, B → C ⟹ A → C 키가 아닌 속성을 거쳐 간접 결정
다치 종속 (MVD) X ↠ Y X 값 하나에 Y 값의 집합이 독립적으로 대응
조인 종속 (JD) *(R1, R2, …, Rn) 분해한 릴레이션들을 조인하면 원래 릴레이션이 복원됨

2.2 암스트롱 공리 (Armstrong's Axioms)

함수 종속으로부터 새로운 종속을 추론하는 규칙. 후보키 도출과 정규형 판정의 근거가 된다.

구분 규칙 내용
기본 규칙 반사 (Reflexivity) Y ⊆ X 이면 X → Y
첨가 (Augmentation) X → Y 이면 XZ → YZ
이행 (Transitivity) X → Y, Y → Z 이면 X → Z
유도 규칙 합집합 (Union) X → Y, X → Z 이면 X → YZ
분해 (Decomposition) X → YZ 이면 X → Y, X → Z
의사이행 (Pseudo-transitivity) X → Y, WY → Z 이면 WX → Z

2.3 속성 폐포(Closure)로 후보키 찾기

릴레이션 R(A, B, C, D, E)
FD = { A → B,  B → C,  CD → E }

{A}+   = {A, B, C}            → 후보키 아님
{A,D}+ = {A, D, B, C, E}      → 모든 속성 포함 ⇒ 후보키
{B,D}+ = {B, D, C, E}         → A 미포함

∴ 후보키 = {A, D}
   - 2NF 위반: A → B (키의 일부에 종속)
   - 3NF 위반: B → C (비키 → 비키)

💡 요령 — FD의 오른쪽에 한 번도 나오지 않는 속성은 반드시 후보키에 포함된다. 위 예에서 A와 D가 그렇다.

3. 정규형 상세

1NF
원자값
2NF
부분 종속 ✕
3NF
이행 종속 ✕
BCNF
결정자 = 후보키
4NF
다치 종속 ✕
5NF
조인 종속 ✕

3.1 제1정규형 (1NF) — 흔한 위반 패턴

위반 패턴 예 해결
다중값 컬럼 전화번호 = '010-1111, 02-2222' 고객연락처 엔터티로 분리
반복 컬럼 전화1, 전화2, 전화3 행으로 전환 (연락처유형코드 + 번호)
복합 의미 컬럼 주소 = '서울시 강남구 …'를 시·구 단위로 조회 업무상 조회 단위라면 분리
JSON/CSV 저장 태그 = 'DB,ORACLE,RAC' 태그 매핑 엔터티 (M:N 해소)

3.2 제2정규형 (2NF)

조건 1NF이며 모든 비키 속성이 기본키에 완전 함수 종속.
단일 컬럼 PK인 테이블은 1NF만 만족하면 자동으로 2NF이다. 2NF 문제는 복합키에서만 발생한다.

수강 (위반)
학번 과목코드 성적 과목명 학점수
S01 DB101 A 데이터베이스 3

→ 과목코드 → 과목명, 학점수 (부분 종속) ⟹ 수강(학번, 과목코드, 성적) + 과목(과목코드, 과목명, 학점수)

3.3 제3정규형 (3NF)

조건 2NF이며 비키 속성 간 이행 종속이 없음.
형식적 정의: 모든 비자명 FD X → A 에 대해 X가 슈퍼키이거나 A가 주요 속성(후보키의 일부)이다.

사원 (위반)
사원번호 사원명 부서코드 부서명 부서위치
E01 홍길동 D10 개발팀 판교

→ 사원번호 → 부서코드 → 부서명, 부서위치 ⟹ 사원 + 부서 분리

3.4 BCNF (Boyce-Codd Normal Form)

조건 모든 결정자가 후보키이다. 3NF에서 "A가 주요 속성이면 허용"하던 예외를 없앤 강화된 형태.

대표 예제 — 특강 신청

  • 업무 규칙: 학생은 과목별로 한 교수에게만 수강한다. 교수는 한 과목만 담당한다.
특강신청 — PK(학번, 과목)
학번 과목 교수
S01 데이터베이스 김교수
S02 데이터베이스 이교수
S01 운영체제 박교수
  • FD: (학번, 과목) → 교수, 교수 → 과목
  • 교수는 결정자인데 후보키가 아님 → BCNF 위반 (3NF는 만족: 과목이 주요 속성이므로)
  • 이상현상: 김교수가 담당 과목을 바꾸면 여러 행 수정 필요, 신청자가 없는 교수의 담당 과목 기록 불가

분해 결과

수강교수
학번 교수
S01 김교수
S02 이교수
S01 박교수
교수과목
교수 과목
김교수 데이터베이스
이교수 데이터베이스
박교수 운영체제

⚠ BCNF 분해의 대가 — 위 분해에서는 "학생은 과목별로 한 교수에게만 수강"이라는 FD (학번, 과목) → 교수가 어느 한 테이블에서도 키로 보장되지 않는다. 즉 BCNF 분해는 종속성 보존을 잃을 수 있다. 실무에서는 3NF에서 멈추고 제약조건(트리거·애플리케이션)으로 보완하는 선택도 흔하다.

3.5 제4정규형 (4NF) — 다치 종속

조건 BCNF이며 자명하지 않은 다치 종속 X ↠ Y가 있다면 X는 슈퍼키이다.
서로 독립적인 다중값 사실 두 개를 한 테이블에 넣으면 발생한다.

사원역량 (위반) — 보유기술과 사용언어는 서로 무관
사원 기술 언어
홍길동 Oracle 한국어
홍길동 Oracle 영어
홍길동 Python 한국어
홍길동 Python 영어

→ 사원 ↠ 기술, 사원 ↠ 언어. 기술 하나 추가 시 언어 수만큼 행 추가 ⟹ 사원기술(사원, 기술) + 사원언어(사원, 언어)

3.6 제5정규형 (5NF / PJNF) — 조인 종속

조건 모든 조인 종속이 후보키에 의해서만 함축된다.
3개 이상의 엔터티가 순환적 업무 규칙으로 묶일 때 문제가 된다.

  • 예: "공급업체 S가 부품 P를 공급하고, 프로젝트 J가 부품 P를 사용하며, S가 J에 납품한다면 → S는 J에 P를 공급한다" 라는 규칙이 성립하는 경우
  • 이 경우 (S, P, J) 3원 테이블은 (S,P), (P,J), (S,J) 세 개로 분해 후 조인해도 정확히 복원된다 → 분해 대상
  • 규칙이 성립하지 않으면 3원 관계 자체가 의미 있는 사실이므로 분해하면 거짓 튜플(Spurious Tuple)이 생긴다

💡 실무 감각 — 현업 모델에서 4NF·5NF 위반은 대부분 "M:N 관계 두 개를 하나의 교차 엔터티에 몰아넣은 경우"다. 교차 엔터티를 만들 때 "이 세 속성은 동시에 하나의 사실인가?"를 질문하면 대부분 예방된다.

4. 분해의 두 가지 원칙

원칙 의미 위반 시
무손실 조인 (Lossless Join) 분해된 테이블을 조인하면 원래 데이터가 정확히 복원된다. 공통 속성이 한쪽의 키여야 한다 거짓 튜플 발생 — 절대 위반 불가
종속성 보존 (Dependency Preservation) 원래의 모든 FD가 분해된 어느 테이블 안에서 검사 가능하다 업무 규칙을 조인·트리거로 검증해야 함
  • 3NF까지는 두 원칙을 항상 동시에 만족하는 분해가 존재한다.
  • BCNF는 무손실은 보장되지만 종속성 보존은 보장되지 않는다.

5. 실무에서 정규화 판단하기

5.1 정규화가 성능을 높이는 경우

  • 갱신 대상 행 수 감소 → Redo/Undo 감소, 락 범위 축소
  • 테이블 폭이 줄어 블록당 행 수 증가 → Buffer Cache 효율 향상, Full Scan 비용 감소
  • 중복 컬럼 동기화 트리거·배치 제거

5.2 정규화가 성능을 떨어뜨리는 경우

  • 조회 시 다단계 조인이 필수인 대량 범위 조회 (통계·리포트)
  • 조인 키 분포가 나빠 NL 조인 랜덤 I/O가 폭증하는 경우

5.3 판단 순서

  1. 먼저 3NF까지 정규화한 논리 모델을 만든다. (반정규화는 정규화된 모델에서만 의미가 있다)
  2. 핵심 SQL과 처리량(TPS, 일 건수, 조회 범위)을 정의한다.
  3. 인덱스·파티션·Materialized View·클러스터로 해결 가능한지 검토한다.
  4. 그래도 부족하면 반정규화하고 정합성 유지 방안을 문서화한다.

6. 연습 문제

문제 1. R(학번, 이름, 학과코드, 학과명, 과목코드, 성적), FD = {학번 → 이름, 학과코드 / 학과코드 → 학과명 / (학번, 과목코드) → 성적}. 3NF로 분해하라.

해설 후보키 (학번, 과목코드).

  • 부분 종속 제거 → 학생(학번, 이름, 학과코드), 성적(학번, 과목코드, 성적)
  • 이행 종속 제거 → 학생(학번, 이름, 학과코드), 학과(학과코드, 학과명)
  • 최종: 학생, 학과, 성적 3개

문제 2. R(A, B, C), FD = {AB → C, C → B}. 이 릴레이션은 3NF인가? BCNF인가?

해설 후보키 {A,B}, {A,C}. B, C 모두 주요 속성.

  • C → B: C는 슈퍼키가 아니지만 B가 주요 속성 → 3NF 만족
  • 결정자 C가 후보키가 아님 → BCNF 위반

문제 3. 상품(상품코드, 색상, 사이즈)에서 색상과 사이즈는 상품별로 독립적으로 제공된다. 어떤 정규형 위반이며 어떻게 분해하는가?

해설 상품 ↠ 색상, 상품 ↠ 사이즈 → 4NF 위반. 상품색상(상품코드, 색상), 상품사이즈(상품코드, 사이즈)로 분해. 단, 실제 재고가 색상×사이즈 조합(SKU) 단위로 관리된다면 3원 관계 자체가 사실이므로 분해하지 않는다.