정규화(Normalization)
정규화: 데이터의 중복과 삽입, 갱신, 삭제 시 발생할 수 있는 이상 현상(insert, update, deletion anomaly)을 최소화하기 위해 일련의 정규화(Normal Forms, NF)에 따라 관계형 데이터베이스를 구성하는 과정이다.
NF: 정규화되기 위해 준수해야 하는 몇 가지 rule
정규화 과정 : 1NF -> 2NF -> 3NF -> BCNF
보통 실무에서는 3NF 혹은 BCNF 까지 만족하면 정규화되었다고 말한다. (최소 정규화 단계)
왜 정규화를 해야 할까?
정규화를 하는 궁극적인 목표는 데이터의 중복을 줄이고 데이터의 무결성과 일관성을 유지하기 위해서이다.
비정규화된 데이터베이스 테이블 (고객 정보와 주문 정보를 하나의 테이블에 저장)
| ID | 이름 | 주소 | 주문 번호 | 주문 날짜 | 주문 상품 |
| 1 | 김철수 | 서울시 강남구 | 101 | 2023-06-01 | 컴퓨터 |
| 1 | 김철수 | 서울시 강남구 | 102 | 2023-06-03 | 마우스 |
| 2 | 김짱구 | 서울시 서초구 | 103 | 2023-06-05 | 키보드 |
이 테이블에서는 '김철수'라는 이름으로 주문이 발생할 때 마다, 불필요하게 ‘김철수’ 정보(고객 ID, 고객 이름, 주소)도 같이 중복되어 저장된다.
주문이 발생하면 주문에 대한 정보(주문 번호, 주문 날짜, 주문 상품)만 저장이 되면 된다.
만일 “김철수”의 주소가 “서울시 강남구”에서 “서울시 송파구”로 변경되었다고 생각해 보자.
그러면 우리는 주문번호 101, 102번에 대한 고객 정보를 수정해야 해서 2번의 수정을 해야 한다. (만일 정규화가 되어 있다면 사용자 테이블의 이름이 김철수에 대한 주소만 1번 수정해 주면 된다.)
이렇게 정규화를 하지 않으면 데이터의 중복이 발생하고 이는 데이터의 무결성을 해칠 수 있고, 고객 정보가 변경될 때 모든 데이터를 찾아 수정해야 한다는 단점이 존재한다.
이러한 문제점들 때문에 우리는 정규화를 진행해야 한다.
정규화 과정
제1 정규화 (1NF)
제1정규화를 만족하기 위해서는 테이블의 각 칼럼은 유일한 값(Atomic)을 가져야 한다.
즉, 하나의 칼럼에는 하나의 데이터인 단일 값으로 구성되어야 하며, 각 데이터는 고유한 식별자를 가져야 한다.
=> 하나의 칼럼에는 하나의 데이터!
제 1 정규화를 만족하지 않은 데이터를 보자.
| ID | 이름 | 주소 | 주문 번호 | 주문 날짜 | 주문 상품 |
| 1 | 김철수 | 서울시 강남구 | 101 | 2023-06-01 | 컴퓨터, 마우스 |
| 2 | 김짱구 | 서울시 서초구 | 103 | 2023-06-05 | 키보드 |
이 예시에서 사용자 이름이 “김철수”인 주문 정보 데이터에 여러 개의 주문 상품 값(컴퓨터, 마우스)을 갖고 있다.
즉, 하나의 칼럼(주문 상품)에 2개의 값이 저장되어 원자성을 보장하지 못한다.
제1 정규화를 만족하기 위해 각각의 주문을 독립적인 데이터로 분리하고, 하나의 칼럼이 고유한 값을 갖도록 해야 한다.
제 1 정규화를 만족하도록 테이블을 수정하면 아래와 같이 수정할 수 있다.
| ID | 이름 | 주소 | 주문 번호 | 주문 날짜 | 주문 상품 |
| 1 | 김철수 | 서울시 강남구 | 101 | 2023-06-01 | 컴퓨터 |
| 1 | 김철수 | 서울시 강남구 | 101 | 2023-06-01 | 마우스 |
| 2 | 김짱구 | 서울시 서초구 | 103 | 2023-06-05 | 키보드 |
컴퓨터와 마우스를 각각의 row로 분리하여 하나의 칼럼이 하나의 데이터만 갖도록 분리하였다.
테이블의 각 칼럼은 유일한 값을 갖도록 하였기 때문에 이 테이블은 1 정규화를 만족한다고 할 수 있다.
하지만 데이터가 중복(김철수 정보)되는 문제는 여전히 존재한다. 이는 제2 정규화를 통해 해결할 수 있다.
제 2 정규화 (2NF)
2 정규화에서는 함수적 종속성이라는 개념을 알아야 하는데 이는 이전에 포스팅했던 적이 있다.
https://seungjjun.tistory.com/326
함수적 종속성 (FD, Functional Dependency)
함수적 종속성(FD, Functional Dependency)함수적 종속성이란?함수적 종속성이란, 테이블 내에서 한 속성 X 값에 따라 다른 속성 Y의 값이 유일하게 결정이 될 때 “X가 Y를 함수적으로 결정한다.”라고
seungjjun.tistory.com
2차 정규화를 만족하기 위해서는 1차 정규형(1NF)을 만족하면서 모든 비주요 속성(non-prime attribute)이 기본 키에 완전 함수적 종속(fully functional dependency)을 만족해야 한다.
테이블의 기본 키가 아닌 모든 칼럼이 기본 키 전체에 대해 종속되어야 하며, 일부분에만 종속되어서는 안 된다.
=> key에 속하지 않는 칼럼의 데이터들은 모두 기본 key에 완전히 함수 종속하게 만들자.
제1 정규화를 만족하고 ID가 기본 키인 테이블 예시를 통해 2 정규화를 알아보자.
| ID | 이름 | 주소 | 주문 번호 | 주문 날짜 | 주문 상품 |
| 1 | 김철수 | 서울시 강남구 | 101 | 2023-06-01 | 컴퓨터 |
| 1 | 김철수 | 서울시 강남구 | 101 | 2023-06-01 | 마우스 |
| 2 | 김짱구 | 서울시 서초구 | 103 | 2023-06-05 | 키보드 |
현재 이 테이블이 2 차 정규화룰 만족하지 않는 이유가 ID라는 기본 키에 다른 모든 칼럼인 이름, 주소, 주문 번호, 주문 날짜, 주문 상품이 기본 키에 대하여 완전히 함수적 종속성을 만족하지 않기 때문이다.
즉, 이름과 주소는 기본키인 ID에 대하여 완전 함수적 종속성을 만족하지만 주문에 대한 정보는 함수적 종속성을 만족하지 않기 때문이다.
이름과 주소 칼럼은 ID에 완전 함수적으로 종속된다.
하지만 주문 정보인 주문 번호, 날짜, 상품 칼럼들은 기본 키인 ID에 의해서만 결정이 되지 않는다.
예를 들어, ID 값이 1인 사용자가 여러 상품을 주문하면, 같은 ID 값에 대하여 다른 주문 정보 데이터를 가질 수 있다. 그래서 주문 정보에 대한 데이터는 ID와 주문 번호의 조합에 의해 결정될 수 있다.
이는 기본 키인 ID만으로는 완전 함수적 종속성을 만족하지 않는다는 것을 의미한다.
즉, 2 정규화를 만족하지 못한다.
2차 정규화를 만족시키기 위해서, 기본 키에 대해 완전 함수적 종속성을 만족하지 않는 속성들을 분리하여 별도의 테이블로 구성해야 한다.
아래와 같이 사용자 테이블, 주문 테이블로 나눌 수 있다.
사용자 테이블
| ID | 이름 | 주소 |
| 1 | 김철수 | 서울시 강남구 |
| 2 | 김짱구 | 서울시 서초구 |
주문 테이블
| 주문 번호 | ID | 주문 날짜 | 주문 상품 |
| 101 | 1 | 2023-06-01 | 컴퓨터 |
| 101 | 1 | 2023-06-01 | 마우스 |
| 103 | 2 | 2023-06-05 | 키보드 |
각 테이블의 모든 비주요 속성이 해당 테이블의 기본 키에 완전 함수적으로 종속되며, 2차 정규화를 만족하게 된다.
제3 정규화 (3NF)
3차 정규화(3NF)는 테이블이 2차 정규화(2NF)를 만족하면서, 모든 비주요 속성(non-prime attribute)이 기본 키에 대해서만 종속되어야 하고, 어떠한 비주요 속성도 다른 비주요 속성에 종속되지 않아야 한다.(즉, 이행적 종속성(transitive dependency)을 제거해야 한다.)
더 간단히 표현하면 기본 키가 아닌 칼럼은 기본 키에 대해서만 종속이 되어야 하고, 다른 기본 키가 아닌 칼럼에 종속되어서는 안 된다.
3NF를 만족하지 않는 경우
| ID | 이름 | 가게 ID | 가게 주소 |
| 1 | 김철수 | Z1 | 서울시 강남구 |
| 2 | 김짱구 | Z2 | 서울시 서초구 |
이 경우의 종속성 관계
- ID -> 이름, 가게 ID
- 가게 ID -> 가게 주소
기본 키가 아닌 가게 주소는 가게 ID에 종속되고, 가게 ID는 ID에 종속되므로, 가게 주소는 ID에 이행적으로 종속된다.
이 예시는 3 정규화를 만족하지 않는 경우이다.
3NF를 만족하는 정규화된 테이블 예시
3NF를 만족하도록 정규화하기 위해, 이행적 종속성을 제거하고 독립적인 정보를 별도의 테이블로 분리할 수 있다.
사용자 테이블
| ID | 이름 | 가게 ID |
| 1 | 김철수 | Z1 |
| 2 | 이영희 | Z2 |
가게 테이블
| 가게 ID | 가게 주소 |
| Z1 | 서울시 강남구 |
| Z2 | 서울시 서초구 |
- 사용자 테이블에서 ID는 이름과 가게 ID를 결정한다.
- 가게 테이블에서 가게 ID는 가게 주소를 결정한다.
이렇게 테이블을 분리하면 각 테이블 내의 모든 칼럼이 그 테이블의 기본 키에 직접적으로 종속되며, 비주요 속성이 다른 비주요 속성에 종속되는 이행적 종속성이 없기 때문에 제3 정규화를 만족한다.
BCNF (Boyce-Codd Normal Form)
BCNF는 모든 함수적 종속성이 후보 키에 의해서만 결정되는 경우를 만족해야 한다. 즉, 모든 결정자가 후보 키여야 한다는 의미이다.
3NF를 만족하지만 BCNF를 만족하지 않는 테이블
강의 테이블 (기본 키: 강사 ID, 과목명)
| 강사 ID | 과목명 | 강의실 |
| 1 | 수학 | 301호 |
| 1 | 물리학 | 302호 |
| 2 | 수학 | 301호 |
테이블의 함수적 종속성
- (강사 ID, 과목명) → 강의실: 기본키인 { 강사 ID, 과목명 }는 강의실을 결정한다.
- 강의실 → 과목명: 만약 모든 강사가 동일한 과목을 동일한 강의실에서 가르친다면, 강의실만으로 과목명을 결정할 수 있다.
BCNF가 만족되지 않는 이유
강의 테이블이 BCNF를 만족하지 않는 이유는 강의실 칼럼이 과목명을 결정하지만, 강의실은 후보 키가 아니기 때문에 BCNF를 만족하지 못한다. BCNF는 모든 결정자가 후보 키여야 한다는 조건을 갖고 있기 때문이다.
BCNF를 만족하는 경우
BCNF를 만족시키기 위해, 이 테이블을 두 개의 테이블로 분리해야 한다.
강사 테이블
| 강사 ID | 과목명 |
| 1 | 수학 |
| 2 | 물리학 |
| 1 | 수학 |
강의 테이블
| 강의실 | 과목명 |
| 301호 | 수학 |
| 302호 | 물리학 |
이렇게 분리하면, 각 테이블은 모든 결정자가 후보 키이기 때문에 BCNF를 만족한다.
- 강사 테이블에서는 후보 키인 (강사 ID, 과목명)이 강의실을 결정한다.
- 강의실 테이블에서는 후보 키인 강의실이 과목명을 결정한다.
'Database' 카테고리의 다른 글
| MVCC(Multi-Version Concurrency Control) 개념 (1) | 2024.06.04 |
|---|---|
| Connection을 미리 생성하는 이유 (0) | 2024.05.21 |
| [E-commerce] 캐시를 통한 애플리케이션 성능 개선 (1) | 2024.05.10 |
| [E-commerce] 쿼리 분석 및 인덱스 설계를 통한 성능 개선 (0) | 2024.05.10 |
| [E-commerce] 동시성 문제 해결하기 (비관적 락, 네임드 락, 분산 락) (0) | 2024.05.01 |