데이터베이스 정규화

Database Normalization

출제빈도: 상
빈출 태그: 종속성, 정규화 단계, 이상 현상

정규화는 규칙만 외우면 시험은 맞힐 수 있어도, 실제로 “왜 이렇게 쪼개는가”를 이해하려면 이상 현상이 실제로 발생하는 예시를 한 번은 손으로 짚어봐야 한다. 이 글은 Database basic에서 다룬 학생 테이블을 확장한 “수강신청” 예시로 1NF부터 BCNF까지 실제로 무엇이 나빠서 무엇이 좋아지는지를 따라간다.

1. 데이터 종속성 (Data Dependency)

데이터와 또 다른 데이터가 서로 의존관계를 가지는 것 — A가 변경/삭제될 때 B도 함께 변경/삭제되는 관계다. 종류는 함수 종속, 다가(다치) 종속, 조인 종속 세 가지로 나뉜다.

2. 함수적 종속 (Functional Dependency)

한 속성이 다른 속성을 유일하게 식별할 수 있는 상태를 A → B(A가 B를 결정)로 표기한다.

• 결정자(Determinant): 종속성 규명의 기준이 되는 속성, 유일함
• 종속자(Dependent): 결정자에 의해 값이 정해지는 속성

3. 다가(다치) 종속 / 4. 조인 종속

• 다가 종속: 하나의 결정자가 서로 관련없는 여러 속성을 결정 (G ->> H | J, 예: 학번 -> 이름

  대여횟수)

• 조인 종속: 셋 이상의 릴레이션으로 분해했다가 공통키로 다시 조인해 원래 릴레이션으로 복원 가능한 종속

5. 폐포 (Closure)와 추론 규칙

특정 속성에 종속되었다고 추론 가능한 모든 속성의 집합을 폐포(예: 회원번호⁺)라 하며, 다음 규칙으로 유도한다.

규칙	내용
반사(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, YZ→W이면 XZ→W

6. 정규화 — 수강신청 테이블로 직접 따라가기

다음과 같이 “정규화 안 된” 수강신청 테이블이 있다고 하자.

학번	학생이름	학과	과목	성적
20250001	김선영	컴퓨터공학과	자료구조	A
20250001	김선영	컴퓨터공학과	운영체제	B
20250002	이철수	전자공학과	자료구조	A

이 테이블은 이미 1NF(모든 칸이 원자값)는 만족한다. 하지만 문제가 있다.

• 삽입 이상: 아직 아무 과목도 신청하지 않은 신입생을 등록하려면 “과목/성적” 칸을 비워둬야 한다.
• 갱신 이상: 김선영 학생이 전과해서 학과가 바뀌면, 김선영이 등장하는 모든 행(2행)을 다 고쳐야 하고 하나라도 빠뜨리면 같은 학생인데 학과가 다르게 기록되는 모순이 생긴다.
• 삭제 이상: 이철수가 “자료구조” 수강을 취소하면 그 행이 삭제되는데, 그러면 이철수가 전자공학과 학생이라는 정보 자체가 테이블에서 사라져버린다.

왜 이런 문제가 생기는가 — 부분 함수 종속

이 테이블의 기본키는 {학번, 과목}이다. 그런데 “학생이름”과 “학과”는 사실 {학번, 과목} 전체가 아니라 학번 하나만으로 결정된다(부분 함수 종속). 성적만 {학번, 과목} 둘 다 있어야 결정되는 완전 함수 종속이다. 즉 한 테이블 안에 “학생에 대한 정보”와 “수강 사실에 대한 정보”가 뒤섞여 있는 게 근본 원인이다.

2NF로 분해 — 부분 함수 종속 제거

학생(학번, 학생이름, 학과)
수강(학번, 과목, 성적)

이렇게 나누면 학생 정보는 학번당 한 번만 저장되므로 위 세 이상 현상이 모두 사라진다. 신입생은 수강 테이블에 아무 행이 없어도 학생 테이블에는 등록할 수 있고, 학과 변경도 한 행만 고치면 되고, 수강 취소가 학생 정보를 지우지도 않는다.

3NF — 이행적 함수 종속 제거

만약 학생 테이블에 “학과”뿐 아니라 “학과사무실 위치”까지 들어 있다면 어떨까.

학생(학번, 학생이름, 학과, 학과사무실위치)

여기서 학번 → 학과 → 학과사무실위치라는 이행 관계가 생긴다. 학과사무실위치는 학번이 아니라 학과에 의해 결정되는데, 학과 정보가 같은 학과 학생 수만큼 중복 저장되고, 학과 사무실이 이전하면 그 학과 학생 수만큼 다시 다 고쳐야 하는 문제가 생긴다. 이를 막으려면 다시 분리한다.

학생(학번, 학생이름, 학과)
학과(학과, 학과사무실위치)

BCNF

3NF는 만족하지만 “결정자가 후보키가 아닌” 함수 종속이 남아있는 특수한 경우에 한 단계 더 분해하는 게 BCNF다. 실무에서는 3NF까지만 적용해도 대부분의 이상 현상이 해결되기 때문에 “정규화의 실질적 목표 단계”로 불린다.

4NF, 5NF

• 4NF: 다치종속성 제거 (예: 과목 -» 강사

  프로그램처럼 서로 무관한 다치 속성이 한 테이블에 있으면 분리)

• 5NF: 조인 종속 제거 — 후보키를 통해서만 성립하는 조인 종속만 남긴다

정규형 단계가 올라갈수록(1NF→5NF) 중복은 줄지만, 데이터를 다시 모아 보려면 여러 테이블을 조인해야 하므로 조회 성능은 대체로 낮아진다. 그래서 실무에서는 반정규화(성능을 위해 일부러 중복을 허용하는 기법)로 다시 절충을 하기도 한다.

7. 논리 데이터 모델 품질 검증

정규화가 잘 됐는지와 별개로, 데이터 모델 자체의 품질은 다음 기준으로 평가한다.

• 완전성: 요구사항이 빠짐없이 반영됐는가
• 중복 배제: 불필요한 중복이 없는가
• 업무 규칙: 이해관계자가 동일한 기준으로 데이터를 다룰 수 있는가
• 데이터 재사용: 통합 설계를 통한 재사용성
• 안정성 및 확장성 / 간결성 / 의사소통: 변경에 강하고, 이해하기 쉬우며, 관계자 간 소통 수단으로 기능하는가

핵심 정리

• 정규화는 “한 테이블에 서로 다른 주제의 정보를 억지로 합쳐놓지 말라”는 원칙을 단계별로 형식화한 것이다.
• 2NF는 부분 함수 종속(기본키 일부만으로 결정되는 속성) 제거, 3NF는 이행적 함수 종속(속성이 속성을 결정) 제거로 기억하면 실무 예시에 바로 대입할 수 있다.
• 정규화 단계가 높을수록 중복은 줄지만 조회 시 조인이 늘어난다 — 그래서 실무는 “정규화 후 필요한 곳만 반정규화”하는 절충을 택한다.