[Database] Normalization
Seongje kim, 04 October 2020
데이터베이스 정규화에 대한 내용입니다.
데이터베이스 정규화(Normalization)
데이터베이스 정규화란 데이터베이스의 설계를 재구성하는 방법으로써 정규화를 통해 데이터에 대한 중복성(Redundancy)를 제거하고, 데이터가 관심사별로 처리되도록 성능을 향상 시킬 수 있는 방법이다.
정규화를 수행한다는 것은 데이터를 결정하는 ‘결정자’에 의해 함수적 종속을 가지고 있는 일반 속성(Attribute)을 ‘의존자’로 하여 데이터의 입력/수정/삭제 시 발생할 수 있는 각종 이상 현상을 방지하는 것이다. 데이터의 중복된 속성을 제거하고, 결정자에 의해 동일한 의미의 일반 속성이 하나의 테이블(엔티티)로 집약되기 때문에 한 테이블의 데이터 용량이 최소화되는 효과를 가져온다.
물론 정규화를 통해 추가적인 테이블이 발생하고, 테이블 간의 관계가 증가함에 따라 데이터 조회시 테이블 조인으로 인한 성능 저하가 발생하는 경우가 있기 때문에 이런 부분들을 사례별로 유의하여 반정규화를 적용하는 전략이 필요하다.
정규화 규칙
1차 정규화
반복되는 속성이나 그룹의 속성을 제거하고, 새로운 테이블을 추가한 후에 기존 테이블과 일대다 관계를 형성한다.
| OrderId(PK) | Name | Day | Item | Price | Info |
|---|---|---|---|---|---|
| 1 | Kim | 2020-10-05 | Book1 | 10000 | Computer |
| 2 | Lee | 2020-10-05 | Book1 | 10000 | Computer |
| 3 | Kim | 2020-10-07 | Book2 | 15000 | Fiction |
| 4 | Park | 2020-10-08 | Book1 | 10000 | Computer |
위와 같이 주문 테이블 있을 때, 상품에 대한 정보가 중복해서 저장되는 문제가 발생한다. 또한 상품에 대한 추가적인 속성이 필요하다면 모든 로우에 데이터를 추가해야 상황이 된다. 그러므로 1차 정규화를 통해 상품에 대한 테이블을 추가하여 일대다 관계로 만듦으로써 중복 데이터를 제거할 수 있게 된다.
| OrderId(PK) | Name | Day | ItemId(FK) |
|---|---|---|---|
| 1 | Kim | 2020-10-05 | 1 |
| 2 | Lee | 2020-10-05 | 1 |
| 3 | Kim | 2020-10-07 | 2 |
| 4 | Park | 2020-10-08 | 1 |
| ItemId(PK) | ItemName | Price | Info |
|---|---|---|---|
| 1 | Book1 | 10000 | Computer |
| 2 | Book2 | 15000 | Fiction |
2차 정규화
기본키가 복합키로 구성된 경우, 나머지 속성들이 완전 함수적 종속을 만족해야 한다. 다시 말해, 복합키 전체에 의존하지 않고 복합키의 일부에만 종속(부분적 함수 종속 관계)되는 속성들을 분리하는 방법이다.
| OrderId(PK,FK) | ItemId(PK,FK) | Quantity | Payment | Stock |
|---|---|---|---|---|
| 1 | 1 | 3 | Card | 5000 |
| 1 | 2 | 5 | Card | 3000 |
| 2 | 1 | 10 | Deposit | 5000 |
만일 위와 같은 주문 상세 테이블이 주문 테이블과 상품 테이블 사이에 추가되어 일대다-다대일 관계를 형성할 경우, 재고(Stock) 속성은 상품 테이블에 대해서만 종속되어 있기 때문에 중복 데이터에 대한 저장소의 낭비뿐만 아니라 데이터 입력/수정/삭제로 인한 데이터 불일치 문제가 발생할 수 있다. 따라서 재고 속성을 상품 테이블에 추가하여 주문 상세 테이블을 관리함으로써 이러한 문제들을 방지한다.
3차 정규화
기본키에 의존하지 않는 일반 속성들을 제거한다. 기본키에 의존하지 않고 다른 일반 속성에 의해 결정(이행적 함수 종속 관계)되는 속성들을 분리하는 방법이다.
| UserId | Name | City | Street | ZipCode |
|---|---|---|---|---|
| 1 | Kim | Seoul | Gangnam-daero | 06038 |
| 2 | Lee | Seoul | Gangnam-daero | 06038 |
| 3 | Park | Deajeon | Taepyeongro | 34888 |
위 테이블에서 볼 수 있듯이, City, Street는 다른 일반 속성인 ZipCode에 의해 결정되는 속성들이기 때문에 이들을 분리하여 새로운 테이블로 관리하여 불필요한 데이터 중복을 방지한다.
BCNF(Boyce and Codd Normal Form)
BCNF란 3차 정규형을 만족하면서 모든 결정자가 후보키 집합에 속한 정규형을 말한다. 즉, 특정 일반 속성에 의하여 후보키가 결정된다면 이는 BCNF 조건을 만족하지 못하는 경우이다. (단, 3차 정규형을 만족하는 테이블의 후보키가 1개뿐이고, 이 후보키가 기본키가 된다면 항상 BCNF를 만족한다.)
| StudentId | Subject | Professor | Score |
|---|---|---|---|
| 1 | CS001 | Kim | A |
| 2 | CS002 | Lee | B |
| 3 | CS002 | Lee | A |
우선 교수는 한 과목만 강의할 수 있으며, 교수가 결정되어야 과목을 수강할 수 있다고 가정한다. 위 테이블의 후보키 집합은 (StudentId, Subject), (StudentId, Professor) 2가지가 될 수 있다.
하지만 현실적으로 해당 테이블을 학번과 과목으로 관리한다고 했을 때, (StudentId, Subject) 집합이 기본키가 될 것이고, Professor는 일반 속성으로써 남겠지만 이는 BCNF 조건을 위반하는 경우가 된다. 교수가 과목을 결정하기 때문에 일반 속성에 의해 후보키가 결정되는 상황인 것이다. 결과적으로 Professor 속성을 분리하여 따로 교수 테이블을 관리함으로써 BCNF 조건을 만족시킬 수 있다.
| StudentId(PK) | Subject(PK) | Score |
|---|---|---|
| 1 | CS001 | A |
| 2 | CS002 | B |
| 3 | CS002 | A |
| Professor(PK) | Subject |
|---|---|
| Kim | CS001 |
| Lee | CS002 |