왜 정규화가 필요한가 — 이상현상 먼저 겪어보기

정규화(normalization)를 정의부터 외우면 왜 필요한지 감이 오지 않습니다. 먼저 정규화되지 않은 테이블이 실제로 어떤 사고를 일으키는지 겪어봅니다. 다음은 “수강신청” 정보를 테이블 하나에 몰아넣은 예시입니다.

이 테이블에 데이터를 넣고 빼고 고치다 보면 세 가지 사고가 반복적으로 발생합니다. 이를 이상현상(anomaly, 애노멀리)이라고 부릅니다.

쉽게 말하면: 이상현상은 “같은 정보를 여러 곳에 중복 저장해서 생기는 뒤틀림”입니다. 정보 하나가 바뀌어야 하는데 사본이 여러 개라 일부만 바뀌는 사고입니다.

정규화는 바로 이 세 가지 이상현상을 없애기 위해, 하나의 사실은 데이터베이스 안에 오직 한 곳에만 저장되도록 테이블을 쪼개는 절차입니다.

1. 함수적 종속성 — 정규화 판별의 유일한 도구

정규형을 판별하려면 먼저 함수적 종속성(functional dependency, FD)을 이해해야 합니다.

쉽게 말하면: “A값을 알면 B값이 자동으로 하나로 정해진다”면 “A가 B를 함수적으로 결정한다”고 말합니다.

기호로는 A → B(A가 B를 함수적으로 결정한다, A determines B)로 씁니다. 이때 A를 결정자(determinant, 디터미넌트)라 하고 B를 종속자(dependent)라고 부릅니다. 위 표에서 과목번호를 알면 과목명이 저절로 정해지므로 다음이 성립합니다.

같은 방식으로 과목번호를 알면 담당교수도, 담당교수를 알면 교수연구실도 정해집니다.

이렇게 A → B이고 B → C이면 A → C도 성립합니다(과목번호를 알면 결국 교수연구실도 알 수 있습니다). 이 연쇄를 이행적 함수 종속(transitive functional dependency)이라고 부르며, 3NF를 판별하는 핵심 개념입니다(4절에서 다시 다룹니다).

복합키가 있는 테이블에서는 종속의 범위를 더 세밀하게 나눠야 합니다.

• 완전 함수 종속(full functional dependency): 종속자가 기본키를 구성하는 속성 전체에 의존해야만 값이 정해지는 경우.
• 부분 함수 종속(partial functional dependency): 종속자가 기본키 일부 속성만으로도 이미 값이 정해지는 경우. 나머지 기본키 속성은 사실 필요 없었다는 뜻입니다.

2. 제1정규형(1NF) — 원자값 조건

제1정규형의 조건은 하나뿐입니다.

모든 속성이 원자값(atomic value)을 가져야 한다 — 하나의 셀에 값이 하나만 들어가야 하며, 반복되는 값 그룹이나 다중값이 들어가서는 안 된다.

다음은 1NF를 위반한 “고객” 테이블입니다. 한 셀에 값이 여러 개 들어 있습니다.

연락처 셀에 값이 두 개 들어있는 C01 행은 “이 안에서 값을 하나씩 골라 조회하거나 수정한다”는 관계형 모델의 기본 동작을 깨뜨립니다. 특정 번호 하나만 삭제하려 해도 문자열을 파싱해야 하는 처지가 됩니다.

분해 결과: 다중값 속성인 연락처를 별도 엔터티로 분리합니다.

이제 각 셀은 값을 하나만 담고, 전화번호 하나를 추가·삭제·수정하는 작업이 다른 전화번호에 전혀 영향을 주지 않습니다.

3. 제2정규형(2NF) — 부분 함수 종속 제거

제2정규형의 조건은 다음과 같습니다.

1NF를 만족하면서, 기본키가 아닌 모든 속성이 기본키 전체에 완전 함수 종속되어야 한다 — 즉 부분 함수 종속이 없어야 한다.

이 조건은 기본키가 복합키일 때만 실질적인 의미를 가집니다. 기본키가 속성 하나뿐이라면 “일부”라는 개념 자체가 성립하지 않으므로 부분 함수 종속도 있을 수 없고, 자동으로 2NF를 만족합니다.

다음은 2NF를 위반한 “수강” 테이블입니다. 기본키는 (학번, 과목번호) 복합키입니다.

왜 위반인가: 이 테이블의 함수적 종속을 모두 나열하면 다음과 같습니다.

성적은 학번과 과목번호 둘 다 있어야 정해지므로 완전 함수 종속입니다(수강 기록마다 성적이 다를 수 있으니 당연합니다). 하지만 교수번호와 교수명은 과목번호 하나만으로 이미 정해집니다. 학번은 전혀 필요하지 않습니다. 이것이 부분 함수 종속이며, 43회 모의고사에서 정확히 이 구조가 “제2정규형을 위반하는 이유”를 묻는 문제로 출제되었습니다.

분해 결과: 과목번호에만 종속되는 속성들을 별도 테이블로 뽑아냅니다.

이제 교수 배정이 바뀌어도 과목 테이블 단 한 행만 고치면 되고, 수강생이 몇 명이든 갱신 이상이 발생하지 않습니다.

4. 제3정규형(3NF) — 이행적 함수 종속 제거

제3정규형의 조건은 다음과 같습니다.

2NF를 만족하면서, 기본키가 아닌 속성 사이에 이행적 함수 종속이 없어야 한다 — 즉 기본키가 아닌 속성이 다른 기본키 아닌 속성을 결정해서는 안 된다.

다음은 3NF를 위반한 “주문” 테이블입니다. 기본키는 주문번호 하나뿐이라 2NF는 이미 만족합니다(속성 하나짜리 키는 부분 종속이 성립할 수 없습니다).

왜 위반인가: 이 테이블의 함수적 종속 연쇄는 다음과 같습니다.

주문번호가 사원번호를 결정하고, 사원번호가 다시 사원명·사원부서를 결정하므로

가 성립하지만, 이는 주문번호가 직접 결정한 것이 아니라 사원번호를 거쳐서 간접적으로 결정된 것입니다. 기본키가 아닌 속성인 사원번호가 또 다른 기본키 아닌 속성(사원명, 사원부서)을 결정하고 있으므로 이행적 함수 종속입니다.

분해 결과: 사원 관련 정보를 별도 테이블로 분리하고, 주문에는 사원번호만 외래키로 남깁니다.

이제 홍길동 사원이 부서를 옮기면 사원 테이블의 딱 한 행만 고치면 되고, 그 사원의 모든 과거 주문 기록에 자동으로 최신 부서 정보가 반영됩니다(조인으로 연결되어 있으므로).

5. 2NF 위반과 3NF 위반, 정면으로 대조하기

두 정규형 위반은 겉보기에 비슷해 보이지만 종속의 출발점이 다릅니다. 이 차이를 정확히 구분하는 것이 정규화 판별 문제의 핵심입니다.

6. 정규화 전체 흐름과 성능 트레이드오프

세 정규형을 단계별로 쌓아가는 흐름을 정리하면 다음과 같습니다.

정규화를 진행할수록 중복은 줄지만 테이블 개수는 늘어나고, 원래 하나로 조회되던 정보를 얻으려면 조인(join, 08·16편에서 다룹니다)이 더 많이 필요해집니다. 이 때문에 “정규화는 항상 데이터베이스 성능을 향상시킨다”는 진술은 틀린 설명입니다 — 정규화의 목적은 무결성과 저장 공간 효율화이며, 조회 성능은 오히려 저하될 수 있습니다. 이 트레이드오프를 되돌리는 기법이 07편의 반정규화(denormalization)입니다.

핵심 정리

• 정규화되지 않은 테이블은 삽입·갱신·삭제 이상현상을 일으킨다. 세 이상현상 모두 “같은 사실이 여러 곳에 중복 저장되어 생기는 뒤틀림”이라는 공통 원인을 가진다.
• 함수적 종속(A → B)은 정규형 판별의 유일한 도구다. 복합키 상황에서는 완전 함수 종속과 부분 함수 종속을 구분해야 한다.
• 1NF는 모든 속성이 원자값이어야 한다는 조건이다. 다중값 속성을 별도 엔터티로 분리해 해결한다.
• 2NF는 부분 함수 종속(복합키의 일부에만 종속) 제거이며, 기본키가 단일 속성이면 자동으로 성립한다.
• 3NF는 이행적 함수 종속(기본키 아닌 속성이 다른 기본키 아닌 속성을 결정) 제거다.
• 부분 함수 종속과 이행적 함수 종속은 종속의 출발점(기본키 일부 vs 일반 속성)이 다르며, 실제 테이블은 두 위반을 동시에 가질 수 있다.
• 정규화는 무결성·저장 효율을 높이지만 조인 증가로 조회 성능이 저하될 수 있어, “항상 성능이 향상된다”는 진술은 틀렸다.

마무리 복습

참고 자료

• 데이터자격시험 - SQLD 출제기준 
• MDN - SQL 개요 (관계형 DB 기초)