나의 포트폴리오를 검토하면서 데이터 정규화 개념을 한번 정리하고 넘어가려한다
데이터 정규화란 뭐냐.
데이터베이스를 처음 설계할 때 가장 많이 듣는 말 중 하나가 "정규화해서 테이블 나눠라"이다
데이터베이스 쪽은 내 메인 분야가 아니라 데이터베이스 설계 시에 데이터 정규화가 무엇인지만 알고 있었지
그 필요성과 어디까지 해야하는지는 명확하지 못했던 것 같다.
이번 글에서는 데이터 정규화에 대한 추상적인 정의보다는 실제 예시를 통해 내 머릿속을 정리하려고 한다
데이터 정규화(Normalization)란
데이터베이스 설계 과정에서 중복 데이터를 줄이고, 데이터 무결성을 유지하기 위해 테이블 구조를 단계적으로 분리하는 과정이다.
제 1정규형 (1NF) - 모든 속성은 원자값(Atomic Value)을 가져야 한다
| user_id (PK) | user_name | user_email |
| 1 | 홍길동 | hong@test.com, jylee@test.com |
-> 컬럼은 하나의 값만 가져야 한다. 위처럼 user_email에 값 두개 넣으면 제 1정규형 위반
(수정)
| user_id (PK) | user_name | user_email |
| 1 | 홍길동 | hong@test.com |
제 2정규형 (2NF) - 제1정규형을 만족하고, 모든 비기본키 속성이 기본키에 '완전 함수 종속'이어야 한다.
2NF는 복합 기본키를 사용하는 테이블에서만 의미가 있다. PK컬럼이 1개면 2NF를 만족하고 있다고 봐도 된다.
하지만 PK가 컬럼 2개 이상이면 2NF 검사가 필요하다
주문상품 테이블을 만들어보자
| order_id (FK) | product_id (FK) | quantity | product_name | product_price |
| 1 | 25 | 3 | 키보드 | 50000 |
주문상품 테이블을 보면 order_id + product_id 조합은 유니크해야 한다. 이 조합이 PK가 된다
수량(quantify)은 order_id와 product_id에 의존하고 있다
하지만 product_name과 product_price는 PK 전체에 의존하는 것이 아니라 product_id에만 의존하고 있다.
이러면 product_name과 product_price는 완전 함수 종속되지 않고 부분 함수 종속이다.
2NF 위반이 된거다
product_name과 product_price는 product 테이블의 속성으로 분리해야한다.
(수정)
-> 주문상품 테이블
| order_id (FK) | product_id (FK) | quantity |
| 1 | 25 | 3 |
-> 상품 테이블
| product_id (PK) | product_name | product_price |
| 25 | 키보드 | 50000 |
제 3정규형 (3NF) - 제2정규형을 만족하고, 기본키가 아닌 속성 간의 '이행적 함수 종속'을 없애야 한다.
"기본키가 아닌 속성 간의 이행적 함수 종속을 없애야 한다" 는
기본키가 아닌 일반 컬럼들끼리 서로 종속 관계가 있어서는 안된다는 말이다
사용자 테이블을 만들었다
| user_id(PK) | user_name | department_id | department_name |
| 1 | 홍길동 | 3 | 개발 |
테이블 구조를 보자
user_id -> department_id
departmemt_id -> department_name
기본키가 아닌 컬럼(department_name)이 다른 기본키가 아닌 컬럼(department_id)에 의존하고 있다.
그 결과 department_name이 user_id에 간접적으로 의존하고 있다고 본다.
이때 department_name이 user_id에 이행적으로 종속되어 있다고 한다
3NF 위반이다.
만일 department_id = 3에 속한 사용자가 100명인데 department_name이 바뀐다고 하면
100개의 row를 다 수정해줘야한다 ㄱ-
(수정)
-> 사용자 테이블
| user_id(PK) | user_name | department_id |
| 1 | 홍길동 | 3 |
-> 조직 테이블
| department_id (PK) | department_name |
| 3 | 개발 |
마지막으로 반정규화까지 간단히 정리하고 넘어가겠다
반정규화 (Denormalization)
시스템의 성능 향상과 개발 및 운영의 편의성을 위해, 정규화된 데이터 모델을 통합, 중복, 분리하는 데이터 모델링 기법
열심히 정규화를 하고나니 성능 최적화 목적으로 반정규화(비정규화)가 필요하다고 할 수 있다
왜 정규화만으로는 안될까?
정규화의 장점은 명확하다 -> 데이터 중복 최소화, 무결성 유지, 수정/삭제 이상 방지 등
하지만 단점도 있다 테이블 분리가 증가할테고 JOIN도 증가할 것이다
그럼 조회가 압도적으로 많은 서비스에서는 정규화 구조가 오히려 성능을 떨어트릴 수도 있다.
이때 필요한게 반정규화다
반정규화가 언제 필요할까 아래 두가지 경우엔 필요하다
-> 조회가 쓰기보다 훨씬 많은 경우
-> 특정 JOIN이 거의 모든 쿼리에 반복되는 경우
정규화 후 성능 측정했을 때 필요하면 반정규화를 하자
처음부터 반정규화하지는 않는다
'개발노트' 카테고리의 다른 글
| [공부] FK(Foreign Key)란 (0) | 2026.01.15 |
|---|---|
| [공부] DDL & DML & DCL (0) | 2026.01.14 |
| Yarn Berry (0) | 2025.05.30 |
| 모바일 애플리케이션 프로세스 메모리 덤프에 대해.. (0) | 2023.07.18 |
| [MAC] terminal 사용해서 특정 포트 죽이기 (0) | 2023.06.22 |
댓글