.png)
데이터베이스 정규화란?
데이터베이스의 설계를 재구성하는 테크닉이다.
정규화를 통해 불필요한 데이터(redundancy)를 제거할 수 있고,
삽입/갱신/삭제 시 발생할 수 있는 이상현상(anamolies) 등을 방지할 수 있다.
위의 표는 정규화 방식에 대한 특징을 나타낸다.
처음의 UNF는 Unnormalized form의 약자로 정규화 되지 않은 데이터를 의미한다.
이후의 1NF, 2NF, 3NF, ...는 각 정규화 방식을 의미하며,
각 방식은 이전 방식들의 원칙을 적용하며 자신의 특징을 갖는다.
예를들어, 3NF(제 3 정규화)는 1NF(제 1 정규화)와 2NF(제 2 정규화)의 규칙을 만족해야한다.
해당 포스트에서는 빨간색으로 표시해둔 1,2,3 정규화 방식에 대해 알아보겠다.
아래에 정규화 되지않은 UNF(Unnormalized form) 데이터가 준비돼있다.
각 정규화를 통해 해당 테이블이 어떻게 변화하는지 살펴보자.
UNF
[Game]
| title(PK) | type(PK) | description | created | designer_id | designer_name | designer_email | price | tag |
|---|---|---|---|---|---|---|---|---|
| 루미큐브 | board | 루미큐브는 ... | 2010 | 1 | jihan | little@punch.com | 15000 | tile, party |
| 루미큐브 | mobile | 루미큐브는 ... | 2010 | 1 | jihan | little@punch.com | 20000 | tile, party |
| 할리갈리 | board | 할리갈리는 ... | 2020 | 1 | jihan | little@punch.com | 30000 | card, party |
1NF (제 1 정규화)
Atomic colums
모든 속성은 반드시 하나의 값만 가져야 한다.
[Game]
| title(PK) | type(PK) | description | created | designer_id | designer_name | designer_email | price | tag |
|---|---|---|---|---|---|---|---|---|
| 루미큐브 | board | 루미큐브는 ... | 2010 | 1 | jihan | little@punch.com | 15000 | tile, party |
| 루미큐브 | mobile | 루미큐브는 ... | 2010 | 1 | jihan | little@punch.com | 20000 | tile, party |
| 할리갈리 | board | 할리갈리는 ... | 2020 | 1 | jihan | little@punch.com | 30000 | card, party |
위의 UNF 데이터의 tag 컬럼에 주목하자. 한 컬럼에 여러개의 데이터가 ',' 를 구분자로 등록되어있다.
이런 경우 제 1 정규화의 원칙인 '원자성' 에 어긋난다.
해당 문제점을 제 1 정규화를 통해 아래와 같이 변경할 수 있다.
제 1 정규화 결과
[Game]
| title(PK) | type(PK) | description | created | designer_id | designer_name | designer_email | price |
|---|---|---|---|---|---|---|---|
| 루미큐브 | board | 루미큐브는 ... | 2010 | 1 | jihan | little@punch.com | 15000 |
| 루미큐브 | mobile | 루미큐브는 ... | 2010 | 1 | jihan | little@punch.com | 20000 |
| 할리갈리 | board | 할리갈리는 ... | 2020 | 1 | jihan | little@punch.com | 30000 |
[Tag]
| id | name |
|---|---|
| 1 | tile |
| 2 | card |
| 3 | party |
[Game_Tag_Map]
| game_title | tag_id |
|---|---|
| 루미큐브 | 1 |
| 루미큐브 | 3 |
| 할리갈리 | 2 |
| 할리갈리 | 3 |
- [Game] 테이블의 tag 컬럼을 [Tag] 테이블로 분리
- [Game_Tag_Map] 테이블은 Game과 Tag가 M:N 관계여서 매핑 역할을 하는 별도의 테이블 생성
2NF (제 2 정규화)
No partial dependencies
- 부분 종속성이 없어야 한다.
- 모든 속성은 반드시 모든 기본키에 종속되어야 한다.
제 1 정규화 작업을 마친 Game 테이블을 이어서 살펴보자.
[Game]
title(PK) | type(PK) | description | created | designer_id | designer_name | designer_email | price |
|---|---|---|---|---|---|---|---|
| 루미큐브 | board | 루미큐브는 ... | 2010 | 1 | jihan | little@punch.com | 15000 |
| 루미큐브 | mobile | 루미큐브는 ... | 2010 | 1 | jihan | little@punch.com | 20000 |
| 할리갈리 | board | 할리갈리는 ... | 2020 | 1 | jihan | little@punch.com | 30000 |
description ~ designer_email 사이의 컬럼 데이터 중 상단 두 줄 데이터들을 보자.
해당 데이터들은 title(PK) 컬럼이 "루미큐브" 일 때 종속된 데이터들이다.
type(PK)이 board 이건 mobile이건 상관이 오직 title(PK) 컬럼에만 종속되어있다.
따라서, 모든 속성은 반드시 모든 기본키에 종속되어야 하는 제 2 정규화 원칙에 어긋난다.
또한 데이터 불필요한 데이터 중복이 발생한 걸 볼 수 있다.
제 2 정규화를 통해 테이블을 변경해보자.
제 2 정규화 결과
[Game]
| title(PK) | description | created | designer_id | designer_name | designer_email |
|---|---|---|---|---|---|
| 루미큐브 | 루미큐브는 ... | 2010 | 1 | jihan | little@punch.com |
| 할리갈리 | 할리갈리는 ... | 2020 | 1 | jihan | little@punch.com |
[Game_Type]
| title | type | price |
|---|---|---|
| 루미큐브 | board | 15000 |
| 루미큐브 | mobile | 20000 |
| 할리갈리 | board | 30000 |
- [Game] 테이블 부분 종속성을 없애기 위해 title(PK)와 종속적인 데이터만 남긴다.
- title(PK)컬럼과 type(PK)컬럼에 모두 종속된 price컬럼을 [Game_Type] 테이블로 분리한다.
- 결과적으로 두 테이블은 제 2 정규화 원칙인 부분 종속성 없음을 만족한다.
3NF (제 3 정규화)
No transitive dependencies
- 이행적 종속성이 없어야 한다.
- 기본키가 아닌 모든 속성간에는 서로 종속될 수 없다.
앞에서와 마찬가지로 제 2 정규화 작업을 마친 Game 테이블을 이어서 살펴보자.
[Game]
| title(PK) | description | created | designer_id | designer_name | designer_email |
|---|---|---|---|---|---|
| 루미큐브 | 루미큐브는 ... | 2010 | 1 | jihan | little@punch.com |
| 할리갈리 | 할리갈리는 ... | 2020 | 1 | jihan | little@punch.com |
designer_id 컬럼은 title(PK) 컬럼에 종속적이다.
루미큐브의 디자이너가 1번이고 할리갈리를 디자인한 디자이너도 1번이므로
PK인 title 컬럼에 종속적인 데이터이다.
그런데 designer_name 컬럼과 designer_email 컬럼은 title(PK) 컬럼에 종속된게 아니라
designer_id에 종속된 데이터들이다.
따라서, 제 3 정규화 원칙인 기본키가 아닌 모든 속성간에 서로 종속될 수 없다 라는 원칙에 어긋난다.
마지막으로 제 3 정규화를 통해 테이블을 변경해보자.
제 3 정규화 결과
[Game]
| title(PK) | description | created | designer_id(FK) |
|---|---|---|---|
| 루미큐브 | 루미큐브는 ... | 2010 | 1 |
| 할리갈리 | 할리갈리는 ... | 2020 | 1 |
[Designer]
| designer_id | designer_name | designer_email |
|---|---|---|
| 1 | jihan | little@punch.com |
- [Game] 테이블에 designer와 관련된 속성들을 [Designer] 테이블로 분리
- [Game] 테이블에 FK로 designer_id 값만 연결
- 참고: FK의 값은 중복으로 보지않음
- 각 테이블의 속성들 사이에 종속성이 사라져서 '이행적 종속성 없음'을 만족
References
