정규화-1

정규화는 테이블을 쪼개는 기술이 아니다

정규화는 어렵게 느껴진다.

제1정규형, 제2정규형, 제3정규형이라는 말이 나오면 갑자기 수학 공식처럼 보인다.
함수 종속이라는 말까지 나오면 더 멀게 느껴진다.

하지만 실무에서 정규화의 출발점은 그렇게 복잡하지 않다.

데이터가 반복되기 때문이다.
같은 값이 여러 곳에 저장되기 때문이다.
서로 다른 의미의 데이터가 한 테이블에 섞이기 때문이다.
하나의 칸에 여러 값을 억지로 넣기 때문이다.

정규화는 테이블을 많이 만드는 기술이 아니다.
정규화는 데이터를 보기 좋게 나누는 기술도 아니다.

정규화는 업무에서 관리해야 할 데이터가 자기 자리를 갖도록 정리하는 일이다.

같은 고객 정보가 여러 곳에 반복해서 저장되면 문제가 생긴다.
같은 상품명이 주문마다 다르게 저장되면 통계를 낼 수 없다.
주문 하나에 여러 상품을 억지로 한 칸에 넣으면 검색도 어렵고 수정도 어렵다.
배송 정보와 반품 정보가 주문 테이블에 뒤섞이면 시간이 지날수록 모델이 흐려진다.

이 문제는 SQL을 잘못 짜서 생긴 문제가 아니다.
컬럼명이 나빠서 생긴 문제도 아니다.

테이블의 구조가 업무의 구조를 제대로 담지 못했기 때문에 생긴 문제다.

그래서 정규화는 엔터티 도출과 분리된 작업이 아니다.
엔터티를 도출한 다음, 그 엔터티 안에 속성이 제대로 놓였는지 확인하는 과정이다.

엔터티를 잘못 잡으면 정규화도 흔들린다.
반대로 정규화를 하다 보면 처음에 놓친 엔터티가 보이기도 한다.

이번 장에서는 온라인 쇼핑몰 주문 관리 시스템을 예제로 정규화를 살펴본다.

잘못된 시작

온라인 쇼핑몰 주문 관리 시스템을 만든다고 해보자.

고객이 상품을 주문한다.
주문이 접수되면 결제가 이루어진다.
배송이 시작되면 택배사와 송장번호가 등록된다.
고객은 배송 전 주문을 취소할 수 있다.
배송 후에는 반품을 요청할 수 있다.

처음에는 다음과 같은 테이블을 만들기 쉽다.

겉으로 보면 큰 문제가 없어 보인다.

주문 화면에 필요한 정보가 모두 있다.
고객 문의가 오면 주문 테이블만 조회하면 된다.
배송 상태도 볼 수 있다.
취소 여부와 반품 여부도 확인할 수 있다.

처음 만드는 사람 입장에서는 오히려 단순해 보인다.

하지만 이 모델은 곧바로 막힌다.

고객 한 명이 여러 번 주문하면 고객명과 연락처를 계속 반복해서 저장해야 한다.
하나의 주문에 상품이 여러 개 들어가면 상품명을 한 칸에 여러 개 넣어야 한다.
상품 가격이 바뀌면 과거 주문의 가격과 현재 상품의 가격을 구분하기 어렵다.
주문한 상품 중 일부만 반품하면 반품여부를 어떻게 표시해야 할지 애매해진다.
상품별 판매수량을 구하려면 상품명 문자열을 다시 분리해야 한다.

이 문제는 컬럼이 부족해서 생긴 것이 아니다.

서로 다른 성격의 데이터를 한 테이블에 넣었기 때문에 생긴 문제다.

고객은 주문의 속성이 아니다.
상품도 주문의 속성이 아니다.
배송은 주문 이후에 발생하는 업무 흐름이다.
취소와 반품도 주문 이후에 발생하는 업무 사건이다.

이것들을 주문 테이블 하나에 모두 넣으면 모델은 처음부터 불안정해진다.

정규화는 바로 이 문제를 다룬다.