반응형
정규화는 중복 데이터를 제거하고, 데이터의 일관성과 무결성을 유지하기 위해 테이블을 체계적으로 나누는 설계 방법
즉,
"이상한 데이터가 저장되는 걸 방지하고, 데이터 변경 때 문제가 안 생기게 테이블을 구조화 하는 과정"
정규화가 잘되면
- 중복 감소
- 저장 공간 감소
- UPDATE/DELETE 오류 감소
- 시스템 안정성 및 유지보수성 향상
정규화를 왜 해야 할까?
정규화는 세 가지 이상현상 방지
1) 삽입 이상(Insertion anomaly)
- 새로운 데이터를 넣으려는데 불필요한 값까지 넣어야 하는 문제
예: 학생을 등록하려는데, 아직 강의가 없어도 강의명을 강제로 넣어야함
2) 갱신 이상(Update anomaly)
- 데이터 중복 때문에 하나 수정하면 여러 군데 수정해야 하고
- 하나라도 빠지면 데이터 불일치 발생
3) 삭제 이상(Delete anomaly)
- 어떤 데이터를 삭제했더니
- 삭제하면 안 되는 다른 중요 정보까지 같이 사라짐
정규화는 이 세 문제를 해결하는 방향으로 이뤄짐
정규화의 단계
보통 실무에서는 3 정규형(3NF)까지 사용
1정규형(1NF): 원자성(Atomicity)
컬럼에는 쪼갤 수 없는 값(Atomic value)만 들어가야 한다.
| user_id | phones |
| 1 | 010-1111-2222, 02-3333 |
phones가 여러 값을 가지므로 X
| user_id | phones |
| 1 | 010-1111-2222 |
| 1 | 02-3333 |
2정규형(2NF): 부분 종속 제거
기본키가 두 개 이상(복합키)일 때만 해당
기본키의 일부에는 종속된 컬럼을 분리해야 한다.
예:
| Table A | |||
| order_id | product_id | order_date | product_name |
여기서 PK = (order_id, product_id)
- order_date → order_id에만 종속
- product_name → product_id에만 종속
→ 2NF 위반
✔ 정규화하면:
| orders | |
| order_id | order_date |
| products | |
| product_id | product_name |
| order_items | |
| order_id | product_id |
3정규형(3NF): 이행적 종속 제거
기본키가 아닌 컬럼이 또 다른 비키(non-key)를 결정하면 안 된다.
예:
| user_id | dept_id | dept_name |
| pk | 비키 | dept_id에 의해 결정 |
정규화:
| Users | |
| user_id | dept_id |
| Departments | |
| dept_id | dept_name |
정규화를 너무 많이하면 성능이 느려질 수 있으니 필요시 비정규화를 적절히 활용하는 것이 좋음
반응형