98. 이행적 함수적 종속 (Transitive Functional Dependency) - X->Y, Y->Z 일 때 X->Z 종속 발생

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

본질: 이행적 함수적 종속 (Transitive Functional Dependency)은 A가 B를 결정하고, B가 C를 결정하여 간접적으로 A가 C를 결정하게 되는 꼬리물기형 종속 관계다.

가치: 이 종속성을 제거하여 테이블을 분리하는 과정이 제3정규형 (3NF, Third Normal Form)이며, 이를 통해 삽입, 갱신, 삭제 시 발생하는 이상 현상 (Anomaly)을 방지한다.

판단 포인트: 기본 키 (PK, Primary Key)가 아닌 일반 속성이 다른 일반 속성을 결정하고 있다면, 이는 반드시 별도의 부모 테이블로 분리하여 외래 키 (FK, Foreign Key)로 참조하도록 설계해야 한다.

Ⅰ. 개요 및 필요성

이행적 함수적 종속 (Transitive Functional Dependency)은 관계형 데이터베이스에서 기본 키가 아닌 일반 컬럼이 또 다른 일반 컬럼의 값을 고유하게 결정하는 현상을 말한다. 제2정규형 (2NF)을 만족하여 부분 함수적 종속이 제거된 테이블이라도, 일반 컬럼 간의 꼬리물기식 종속성이 남아있으면 데이터 중복과 모순이 발생한다.

데이터베이스 설계 시 "기본 키 (PK)를 알면 모든 속성을 알 수 있다"는 원칙은 지켜져야 하지만, 그 과정에 중간 다리가 존재하면 문제가 된다. 예를 들어, 사번으로 부서코드를 알고 부서코드로 부서명을 알 수 있는 구조에서는 새로운 부서가 생겨도 소속 사원이 없으면 부서 자체를 등록하지 못하는 치명적인 삽입 이상 (Insertion Anomaly)이 발생하기 때문에 이러한 종속 고리를 끊어낼 필요가 있다.

📢 섹션 요약 비유: 이행적 종속은 회사에서 사장이 직접 지시하지 않고, 중간 관리자를 통해 말단 직원에게 지시가 전달되는 다단계 하청 구조와 같다. 중간 관리자가 퇴사하면 말단 직원의 소속도 공중분해 된다.

Ⅱ. 아키텍처 및 핵심 원리

이행적 종속은 $X \rightarrow Y$ 이고 $Y \rightarrow Z$ 일 때 (단, $Y$는 $X$에 종속되지만 $X$는 $Y$에 종속되지 않음), 논리적으로 $X \rightarrow Z$ 가 성립하는 구조다. 이 구조를 타파하기 위해 3NF (Third Normal Form) 분해가 일어난다.

┌──────────────────────────────────────────────────────────────┐
│           이행적 함수적 종속의 구조와 3NF 분해 원리          │
├──────────────────────────────────────────────────────────────┤
│ [분해 전: 이상 현상 발생]                                      │
│                                                              │
│       ┌─────────결정─────────┐                               │
│       ▼                      │                               │
│ [사번(X, PK)] ──▶ [부서코드(Y)] ──▶ [부서명(Z)]               │
│       └──────────이행적 종속─────────▲                       │
│                                                              │
│ ──────────────────────────────────────────────────────────── │
│ [분해 후: 3NF 적용 (테이블 분리)]                              │
│                                                              │
│  사원 테이블 (Emp)                 부서 테이블 (Dept)        │
│ ┌───────────┬────────────┐      ┌────────────┬───────────┐ │
│ │ 사번(PK)  │ 부서코드(FK)│  조인 │ 부서코드(PK) │ 부서명    │ │
│ │ 1001      │ HR         ├──────┤ HR         │ 인사팀    │ │
│ │ 1002      │ IT         │      │ IT         │ 전산팀    │ │
│ └───────────┴────────────┘      └────────────┴───────────┘ │
└──────────────────────────────────────────────────────────────┘

다이어그램에서 보듯, 부서명(Z)은 오직 부서코드(Y)에만 종속되지만, 분해 전에는 하나의 테이블에 묶여 있어 중복 저장된다. 3NF 분해는 중간 결정자(Y)를 새로운 테이블의 기본 키(PK)로 삼고 종속자(Z)를 데려가 독립시키는 과정이다. 원래 테이블에는 중간 결정자(Y)만 외래 키(FK)로 남겨 데이터의 일관성을 확보한다.

📢 섹션 요약 비유: 두꺼운 백과사전 한 권에 단어와 그 단어의 어원, 어원의 기원 국가 역사까지 다 적어놓는 대신, 단어장과 역사책 두 권으로 분리하고 단어장에는 '역사책 15페이지 참조'라는 포스트잇(FK)만 붙이는 원리다.

Ⅲ. 비교 및 연결

정규화의 각 단계는 제거하는 종속성의 종류가 다르다. 이행적 종속은 2NF와 BCNF (Boyce-Codd Normal Form) 사이에 위치하며, 일반 속성 간의 관계를 다룬다는 점에서 차이가 있다.

비교 항목	제1정규형 (1NF)	제2정규형 (2NF)	제3정규형 (3NF)
제거 대상	반복되는 그룹, 복수 값	부분 함수적 종속	이행적 함수적 종속
원인 요소	원자값 미준수	복합 키 (Composite Key)의 일부에만 종속	일반 속성(Non-prime)이 다른 일반 속성 결정
주요 결과	모든 속성이 단일 값	복합 키 분리 (주문-상품 테이블 분해 등)	부모-자식 코드 테이블 분리 (사원-부서 등)

이행적 종속을 해결하지 않으면, 하나의 릴레이션 내에 이질적인 두 가지 주제(예: 사원 정보와 부서 정보)가 혼재되어 응집도(Cohesion)가 떨어지고 결합도(Coupling)가 높아지는 소프트웨어 공학적 문제와도 궤를 같이한다.

📢 섹션 요약 비유: 1NF는 밥그릇에 반찬 안 섞기, 2NF는 밥과 국을 따로 담기라면, 3NF는 간장 종지를 별도로 분리해서 어느 튀김을 찍어 먹든 하나의 간장만 관리하게 만드는 것이다.

Ⅳ. 실무 적용 및 기술사 판단

실무 데이터베이스 설계에서 이행적 종속은 매우 흔하게 발생하며, 코드화(Coding) 설계 시 반드시 마주치는 문제다.

판단 포인트

언제 분리 (3NF) 해야 하는가?: 부서, 직급, 우편번호, 상품 카테고리 등 '공통 코드' 성격을 띠는 데이터가 메인 트랜잭션 테이블에 중복 저장되고 있다면 반드시 별도 테이블로 분리해야 한다.
언제 역정규화 (De-normalization)를 고려하는가?: 데이터를 읽을 때마다 빈번하게 조인(Join)이 발생하여 I/O 병목이 심각하다면, 조회 성능 향상을 위해 3NF를 포기하고 다시 이행적 종속을 허용(부서명을 사원 테이블에 중복 저장)할 수 있다.

안티패턴

로그 성격의 히스토리 테이블에 3NF를 억지로 적용하는 경우. 과거 시점의 스냅샷 데이터(그 당시의 부서명 등)는 원본 코드가 바뀌어도 유지되어야 하므로 이행적 종속을 허용해야 한다.
📢 섹션 요약 비유: 3NF 분리는 사무실에서 100명이 각자 프린터를 놔두지 않고, 중앙 복합기 1대를 공유(조인)하는 것이다. 관리(업데이트)는 편하지만, 100명이 동시에 인쇄 버튼을 누르면 병목(조인 부하)이 생길 수 있으므로 상황에 맞게 배치해야 한다.

Ⅴ. 기대효과 및 결론

이행적 함수적 종속을 제거하여 3NF를 달성하면, 데이터베이스의 논리적 구조가 명확해지고 중복 데이터가 제거되어 저장 공간이 절약된다. 무엇보다 갱신 이상 (Update Anomaly)을 원천 차단하여 데이터 무결성을 강력하게 유지할 수 있다.

하지만 고도로 정규화된 스키마는 쿼리 작성 시 수많은 조인을 유발하므로, 성능과 무결성 사이의 트레이드오프를 신중하게 판단해야 한다. 결론적으로 이행적 종속의 파악은 관계형 데이터 모델링의 기본기이자, 엔터티 간의 명확한 독립성을 보장하는 핵심 기준이다.

📢 섹션 요약 비유: 이행적 종속 제거는 짐싸기에서 '파우치 속의 파우치'를 밖으로 꺼내 독립적인 가방으로 만드는 것과 같다. 물건 찾기(조인)는 한 번 더 거쳐야 하지만, 내용물이 섞여 오염되는 일(이상 현상)은 절대 일어나지 않는다.

📌 관련 개념 맵

개념	연결 포인트
이상 현상 (Anomaly)	이행적 종속으로 인해 발생하는 삽입, 갱신, 삭제 시의 오류 현상
제3정규형 (3NF)	이행적 종속을 제거한 상태의 데이터베이스 정규형
BCNF (Boyce-Codd Normal Form)	3NF를 만족하면서도 결정자가 후보키가 아닌 경우를 해결하는 더 엄격한 정규형
역정규화 (De-normalization)	조회 성능(Join 회피)을 위해 의도적으로 이행적 종속을 허용하는 실무적 기법

📈 관련 키워드 및 발전 흐름도

제1정규형 (1NF)
    │
    ▼
제2정규형 (2NF) : 부분 함수적 종속 제거
    │
    ▼
이행적 함수적 종속 (Transitive Dependency) 진단
    │
    ▼
제3정규형 (3NF) : 이행적 함수적 종속 제거 (테이블 분리)
    │
    ▼
BCNF (결정자 중 후보키가 아닌 속성 제거) 및 역정규화 판단

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

학교에서 '철수(사번)'의 반을 물어보면 '3반(부서코드)'이라고 대답하고, '3반' 담임이 누구냐고 물으면 '김선생님(부서명)'이라고 대답해요.
그럼 철수 반의 담임은 자연스럽게 '김선생님'이 되죠? 이게 바로 꼬리에 꼬리를 무는 '이행적 종속'이에요.
데이터베이스에서는 이걸 하나로 합쳐 쓰면 복잡해지니까, '학생-반' 명부와 '반-담임' 명부를 따로 나누어(3NF) 깔끔하게 관리한답니다.