정규화(normalization)란?
데이터의 입출력을 위해 DB에서 가져오는 경우가 일반적이다.
그렇다면 DB를 효율적으로 관리하기 위해 어떤 식으로 구조화 하면 좋을까?
위의 고민을 많이 한 사람들이 normalization과 제 1, 2, 3 정규형을 해답으로 내놓았다.
개인적으로 정규화라는 단어보다 표준화가 더 와닿는다.
그렇다면 어떤 생각으로 normalization과 정규형을 고려 했는지 알아보자.
DB 구조
먼저 이해하기 쉽게 사전 지식이 있으면 좋다.
DB 구조를 간단하게 알아보자.
DB는 여러 table들로 이루어져 있다.
이 table들은 특정 목적을 중심으로 정리 되어 있다.
table은 schema라는 column의 상단에 어떤 자료인지 대표하는 이름도 갖고 있다.
DB
ㄴ TABLE1(사람)
ㄴ TABLE2
ㄴ TABLE3
TABLE1(사람)
ㄴ 키
ㄴ 몸무게
ㄴ 성별
ㄴ 나이
여기서 TABLE1의 이름이 사람이면 사람에 대한 데이터들을 column에 넣을 수 있다.
사람이 여러명인 경우 이런 식으로 정리 된다.
normalization을 적용한 이유
본인이 육류 쇼핑몰 DB를 관리하는 관리자라는 가정하고 생각해보자.
돼지고기 1키로당 10,000원 소고기 1키로당 15,000원이다.
그리고 이를 주문하기 위해 주문자 고유의 ID, 주소, 입금 처리 유무 등등 여러 주문자의 정보가 필요하다.
이를 한 테이블에 정리 했을 경우 다음과 같이 정리될 수 있다.
하지만 이렇게 한 테이블에 모든 정보를 넣을 경우 문제가 생긴다.
1. 이상현상
- 삽입 이상: 회원 가입만 한 경우, 다른 속성에 NULL 값이 생긴다.
- 삭제 이상: 회원 탈퇴를 하여, 삭제가 필요한 경우 다른 정보까지 삭제된다.
톰의 주문 내역까지 모두 삭제 됐다.
- 갱신 이상: 고기 값이 변경된 경우
일치해야 하는 종속된 데이터의 일부만 갱신되어 데이터가 불일치 한다.
돼지고기의 가격이 5000원으로 인하했음에도, 총 금액이 달라지지 않았다.
그리고 돼지고기, 소고기를 같이 시킨 경우 따로 처리를 해줘야 한다.
일부의 예시만 들었다. 하지만 대부분 종속된 feature들의 이상이 생긴다.
이를 해결하기 위해 정규형이라는 표준화를 통해 테이블들을 잘게 자르면 이상을 해결할 수 있다.
제1 정규형
핵심은 각 컬럼당 하나의 속성을 가져야 한다.
예를 들어 한 사람이 여러 제품을 한꺼번에 시킬 수 있다.
이런 경우 어떻게 관리하면 좋을까?
이렇게 나누자
제2 정규형
핵심은 table은 특정 목적을 중심으로 정리 되어야 하는데, 위 사진의 예시는 여러 목적이 섞여있어, 관리 DB 테이블에 부분적으로 종속된 값들이 많이 있다.
잘게 잘라주자.
고객, 제품, 주문 이렇게 세 개로 잘라줄 수 있어 보인다.
- 고객
- 제품
- 주문
잘 잘라진 걸 볼 수 있다.
각 테이블 별 고유의 ID 값이 있고, 이들의 primary key를 참조해서 추적할 수 있다.
제3 정규형
특정 컬럼에 종속 되어 있는 경우가 있다.
이럴 때 제3 정규형으로 나눠주면 된다.
아래 사진과 같이 제품 TABLE에 이름, 가격, 거래처, 원산지까지 포함되는 경우는 어떻게 해야할까?
이렇게 정리해도 괜찮지만, 거래처와 원산지가 한 제품에 종속 되어 있다.
이들을 두 개로 나눠주자.
이렇게 나눠서 특정 column에 종속되는 현상을 막을 수 있다.
정규화의 장단점
장점
DB의 이상 현상을 최소화 할 수 있다.
유지보수가 편하다.
단점
특정 결과를 알기 위해 DB 조회할 때 JOIN 참조의 참조를 계속 파고 들어가야하는 번거로움이 있다.
그래서 적당히 테이블을 나누는 방법이 있는데, 필요하다면 더 찾아보자.
