398. 제3정규형 (3NF)과 이행 함수 종속

⚠️ 이 문서는 데이터베이스 테이블 안에서 기본 키(PK)가 아닌 일반 컬럼들끼리 몰래 서로를 결정짓고 의존하는 '다단계 하청 관계'를 찾아내어 끊어버림으로써 데이터 중복을 막는 **'제3정규형(3NF)'**을 다룹니다.

핵심 인사이트 (3줄 요약)

본질: 제3정규형은 제2정규형을 만족하면서, 테이블 내에 **이행적 함수 종속(Transitive Functional Dependency)**이 없어야 한다는 규칙이다.

문제점: A가 B를 결정하고, B가 C를 결정할 때 결국 A가 C를 결정하게 되는 꼬리 물기 구조(A -> B -> C)가 테이블 안에 있으면 갱신 이상(Anomaly)이 발생한다.

해결책: 일반 컬럼들끼리 종속된 꼬리(B -> C)를 잘라내어 **새로운 테이블로 독립(분리)**시키면 완벽한 제3정규형이 달성된다.

Ⅰ. 개요: 꼬리에 꼬리를 무는 관계 (Context & Necessity)

어떤 회사의 직원 테이블을 만들었다고 치자. 기본 키는 사원번호 하나뿐이라서 2NF는 무조건 통과다.

사원번호 (PK)	이름	부서코드	부서위치
101	김철수	D01	서울
102	이영희	D01	서울

이 테이블은 언뜻 보면 문제가 없어 보이지만, 내부적으로 이상한 권력 구조가 숨어있다.

사원번호를 알면 $\rightarrow$ 부서코드를 알 수 있다. (정상적인 종속)
부서코드를 알면 $\rightarrow$ 부서위치를 알 수 있다. (일반 컬럼끼리의 종속)
결과적으로 사원번호 $\rightarrow$ 부서코드 $\rightarrow$ 부서위치라는 A $\rightarrow$ B $\rightarrow$ C 꼬리 물기 구조가 성립한다. 이를 이행적 함수 종속이라고 부른다.

이대로 두면 D01 부서가 서울에서 부산으로 이사 갈 때, D01 소속 직원 1,000명의 '부서위치' 데이터를 1,000번 수정해야 한다. (갱신 이상 발생)

📢 섹션 요약 비유: 이행 종속은 **'하청의 재하청'**과 같습니다. 사장님(PK)이 부장님(부서코드)에게 일을 시키고, 부장님이 다시 대리(부서위치)에게 일을 시키는 구조죠. 이렇게 얽혀있으면 부장님이 바뀔 때 대리까지 다 영향을 받으므로, 아예 부장님과 대리들을 묶어서 '별도의 자회사(새 테이블)'로 독립시키는 것이 3NF입니다.

Ⅱ. 정규화의 전제 조건: 제2정규형 (2NF)

제3정규형을 논하기 전에, 테이블은 반드시 제2정규형을 만족해야 한다.

2NF의 규칙: 복합 기본 키를 쓸 때 일부 키에만 종속되는 얌체 컬럼(부분 함수 종속)이 없어야 한다. (397번 문서 참고)
기본 키가 1개인 테이블은 이미 1NF, 2NF를 모두 통과한 상태이므로 바로 3NF 검사로 넘어가면 된다.

Ⅲ. 제3정규형 달성 방법: 꼬리 자르기 ★

해결책은 2NF와 똑같다. **문제를 일으키는 녀석들을 데리고 나가서 새 테이블을 차리게 하는 것(테이블 분할)**이다.

기존 테이블 (2NF 상태, 3NF 위반)

직원_테이블 [사원번호, 이름, 부서코드, 부서위치]
이행 종속: 사원번호 $\rightarrow$ 부서코드 $\rightarrow$ 부서위치

테이블 분리 후 (3NF 달성)

가운데 낀 녀석(부서코드)을 새로운 테이블의 기본 키(PK)로 만들고, 꼬리(부서위치)를 데리고 나간다.

직원_테이블 [사원번호, 이름, 부서코드(FK)]
부서_테이블 [부서코드, 부서위치] (새로 독립한 테이블)

이제 D01 부서가 부산으로 이사 가도, 부서_테이블에서 딱 1줄만 '부산'으로 업데이트하면 된다. 직원 테이블은 건드릴 필요가 전혀 없다!

┌──────────────────────────────────────────────────────────────┐
│           이행 함수 종속과 3NF(제3정규형) 분리 과정 시각화              │
├──────────────────────────────────────────────────────────────┤
│                                                              │
│ [ ❌ 3NF 위반 (이행 함수 종속 존재) ]                              │
│                                                              │
│  [사원번호(PK)] ───▶ [부서코드] ───▶ [부서위치]                   │
│         │                             ▲                      │
│         └─────────────────────────────┘                      │
│          (결국 사원번호가 부서위치를 결정하는 꼴이 됨)                 │
│                                                              │
│ [ 🟢 3NF 달성 (테이블 분리) ]                                    │
│                                                              │
│ 테이블 1: [사원번호(PK)] ───▶ [부서코드(FK)]                     │
│                                                              │
│ 테이블 2:                     [부서코드(PK)] ───▶ [부서위치]       │
│                                                              │
│ ★ 특징: PK가 아닌 일반 컬럼들끼리 쑥덕거리는 연결 고리를 완벽하게 끊어냄! │
└──────────────────────────────────────────────────────────────┘

Ⅳ. 결론

"일반 컬럼은 오직 기본 키만 바라보아야 한다." 실무에서 데이터베이스 설계를 할 때, 개발자들은 대개 의식하지 않아도 이 3NF까지는 본능적으로 맞추어 테이블을 짠다. "직원 테이블에 부서 주소를 왜 넣어? 부서 테이블 따로 빼야지"라는 직관이 바로 3NF의 수학적 본질과 일치하기 때문이다. 1NF, 2NF, 3NF로 이어지는 이 3단계 정규화는 중복 데이터를 없애고 무결성을 지키는 관계형 데이터베이스 설계의 가장 기초적이고 위대한 공식이다.

📌 관련 개념 맵

선행 조건: 제2정규형 (2NF - 부분 함수 종속 제거, 397번 문서)
후행 과정: BCNF (강한 제3정규형 - 결정자이면서 후보 키가 아닌 것 제거, 399번 문서)
핵심 키워드: 이행 함수 종속 (Transitive Functional Dependency), A $\rightarrow$ B $\rightarrow$ C
발생하는 문제점: 이상 현상 (Anomaly - 삽입/갱신/삭제 이상)

👶 어린이를 위한 3줄 비유 설명

3NF 위반은 학생 카드에 '내 반 번호'뿐만 아니라 '우리 반 담임선생님 이름'까지 다 적어두는 거예요.
담임선생님이 바뀌면 학생 30명의 카드를 다 지우고 새로 적어야 하니까 너무 힘들죠! (갱신 이상)
3NF는 학생 카드에는 '내 반 번호'만 적어두고, '3반 담임은 이순신'이라는 정보는 교무실 게시판(새 테이블)에 딱 하나만 적어두는 똑똑한 정리법이랍니다!