junome

정규화

정규화

데이터 구조를 안정적으로 만들기 위한 관계형 데이터베이스의 핵심 설계 원칙

0. 정규화는 왜 등장했는가?

데이터베이스 초창기에는 데이터를 한 테이블에 많이 모아두는 경우가 많았다.

예:

주문번호 고객명 고객전화 상품 가격

처음에는 편하다.
하지만 시간이 지나면 문제가 터진다.

  • 고객 전화번호가 바뀌면?
  • 같은 고객이 여러 주문을 했다면?
  • 일부만 수정되면?

→ 데이터가 서로 달라진다.

즉,

하나의 사실이 여러 곳에 존재하면
언젠가는 서로 다른 값을 가지게 된다.

정규화는 이 문제를 해결하기 위해 등장했다.

1. 정규화의 목적

정규화는 다음을 제거하기 위한 이론이다.

✔ 데이터 중복
✔ 수정 불일치
✔ 삽입 불가능 상황
✔ 삭제로 인한 정보 손실

이것을 통틀어 이상(Anomaly) 이라고 부른다.

2. 이상(Anomaly)의 종류

2-1. 수정 이상 (Update Anomaly)

같은 정보가 여러 줄에 있어 전부 바꾸지 않으면 불일치 발생.

2-2. 삽입 이상 (Insert Anomaly)

필요 없는 정보가 없으면 추가가 안 되는 상황.

예: 주문이 없으면 고객을 등록 못함.

2-3. 삭제 이상 (Delete Anomaly)

하나를 지웠는데 원래 유지해야 할 정보까지 사라짐.

3. 정규화의 기본 철학

한 사실은 한 곳에서만 관리한다.

이를 위해 테이블을 나누고, 관계로 연결한다.

4. 함수 종속 (Functional Dependency)

정규화를 이해하려면 이것이 핵심이다.

A → B

A가 정해지면 B도 항상 정해진다.

예: 자재코드 → 자재명

자재코드를 알면 이름은 하나로 결정되어야 한다.

만약 여러 값이 나오면 구조가 잘못된 것이다.

5. 정규형 (Normal Forms)

정규화는 단계적으로 구조를 개선한다.

5-1. 제1정규형 (1NF)

원칙

컬럼에는 원자값만 들어가야 한다.

위반 예

자재 LOT 목록
A L1, L2, L3

→ 분리해야 한다.

5-2. 제2정규형 (2NF)

원칙

부분 함수 종속 제거.

복합 키의 일부에만 의존하는 컬럼을 분리.

(주문번호, 자재코드) → 자재명

자재명은 자재코드만 알면 된다.

→ 자재 테이블로 분리.

5-3. 제3정규형 (3NF)

원칙

이행 함수 종속 제거.

A → B → C 라면
C는 A에 두지 말고 B에 둔다.

자재코드 → 거래처코드 → 거래처명

거래처명은 거래처 테이블에서 관리해야 한다.

5-4. BCNF

모든 결정자는 후보키여야 한다.

실무에서는 보통 3NF까지 가면 충분한 경우가 많다.

6. 정규화를 통해 얻는 것

✔ 중복 감소
✔ 수정 시 한 곳만 변경
✔ 무결성 향상
✔ 데이터 의미 명확
✔ 확장 시 안정적

7. 그러나 현실은 JOIN의 세계

정규화를 많이 하면 테이블이 나뉜다.

→ 조회 시 JOIN 증가
→ 복잡도 증가
→ 성능 이슈 가능

그래서 실무에서는 다음을 고민한다.

무결성 vs 성능

8. 그래서 등장하는 반정규화 (Denormalization)

일부 중복을 허용해서

✔ 조회 빠르게
✔ 화면 단순하게
✔ 집계 쉽게

만든다.

하지만 이 경우:

→ 동기화 책임이 개발자에게 온다.

9. 정규화는 언제 가장 중요해지는가?

  • 시스템 규모가 커질 때
  • 여러 프로그램이 데이터를 공유할 때
  • 수정이 자주 일어날 때
  • 장기간 운영할 시스템일 때

10. 실무에서 정규화를 잘한 구조의 특징

  • 데이터의 주인이 명확하다
  • 어디를 수정해야 할지 헷갈리지 않는다
  • 로직이 단순해진다
  • 버그 발생률이 줄어든다

11. 트랜잭션 · 동시성 제어 · 정규화의 관계

정규화 → 데이터를 올바르게 배치
트랜잭션 → 작업을 안전하게 완료
동시성 제어 → 동시에 처리해도 보호

즉,

구조 + 시간 + 경쟁

을 모두 해결해야 시스템이 안정된다.

요약

정규화
- 데이터를 어떻게 나눠 저장해야 중복과 오류를 막을 수 있느냐? → 정규화
- 하나의 사실을 한 곳에서만 관리하도록 테이블 구조를 정리하는 방법

정규화 사용 이유
- 같은 정보가 여러 곳에 있으면 수정 시 일부만 바뀌는 문제가 발생
- 어디가 진짜 값인지 판단하기 어려워짐
- 예: 자재명이 여러 테이블에 흩어져 있으면 한 곳만 수정돼 불일치 발생

정규화를 하면 좋은 점
- 데이터 중복 감소
- 수정 시 한 곳만 변경하면 됨
- 이상 데이터(모순된 값) 발생 방지
- 예: 자재 정보는 자재 마스터, 재고는 재고 테이블로 역할 분리

정규화 주의점
- 너무 많이 나누면 JOIN 증가로 조회가 복잡해질 수 있음
- 조회 성능과 관리 편의성 사이의 균형이 필요
- 그래서 실무에서는 일부러 중복을 허용하는 반정규화도 사용

정규화의 효과
- 데이터 구조가 명확해짐
- 책임 위치가 분명해짐
- 프로그램 로직이 단순해짐
- 예: 자재 기본 정보는 항상 마스터를 보면 된다는 확신이 생김

정리
- 트랜잭션: 작업을 안전하게 끝내는 방법
- 동시성 제어: 동시에 작업해도 값이 맞게 유지되는 장치
- 정규화: 애초에 데이터가 틀어지지 않도록 구조를 정리하는 설계 원칙
- 즉, 수정·조회·확장 모든 상황에서 오류 가능성을 줄이기 위한 기반 작업

소감

정규화에 대해 배우기 전까지 테이블을 나눈다는 행위가 단쉬히 보기 좋게 정리하는 작업이라고 생각했습니다. 
하지만 정규화는 미관의 문제가 아니라 오류를 예방하기 위한 구조적 안정장치라는 것을 알았습니다.

함수 종속과 정규형을 배우면서 데이터를 어디에 두어야 하는지에 대한 기준이 생겼습니다. 과거에는 필요해서 그냥 컬럼을 추가했는데, 이제는 "이 값의 주인은 누구인가?"에 대해서 고민할 수 있었으며 정규화가 만능이 아니라는 점 역시 알 수 있었습니다. JOIN 증가와 성능 문제 떄문에 반정규화를 선택하는 순간, 편리함 대신 관리 책임이 개발자에게 넘여온다는 것을 알았습니다.