본문으로 바로가기

DB정규화, 왜 하는가?

category 스타트업/만들기 2020. 1. 13. 22:42

RDBMS, Document DB 의 차이점

“1차 정규화, 2차 정규화를 하라고 배웠어요.
그런데 현장에 가보니까 그런 걸 안해요.
제가 잘못 배운건가요?”

강의 현장에서 들었던 이야기다.

아, 요즘은 이런 걸 들려줄 사람이 없구나.
막막하네. 

어디서부터 설명을 해야할지.

 

1. DB 정규화 왜 하는가?

 

1차정규화, 2차정규화….

적어도 이게 뭔지는 검색해보고 오자.

왜냐하면 이걸 설명하려면 길기 때문이다.

그래서 이걸 알고 있다고 가정한다.

 

정규화.

이걸 하는 이유는 두가지 때문이다.

 

2차원 데이터 구조

가장 많이 쓰는 데이터 기록형태가 “표”였다.

2차원 데이터구조. X, Y.

 

그래서 데이터베이스라는걸 처음 만들 땐,

세상 모든 데이터를 2차원으로 분해해서 바라봤다.

박보검 / 010-8888-9999 / 명지대학교 / 뮤지컬공연전공
배수지 / 010-2222-3333 / 서울예고 / 실용음악과
….


이렇게 말이다.

기록형태는 이렇게 진화되었다.

 

"표 - 2차원 Array - Linked List File (ISAM) - Oracle (RDBMS)"

더 다양한 방법도 있겠지만,
당시에는 이정도만 해도 충분했다.

그런데, 현실데이터는 다차원이다.
스마트폰 청약서, 통장가입청약서, 주민등록초본 발급신청서 등등.
문서를 잘 쳐다봐라.
문서구조가 다차원 구조, 중첩형 구조다.
표 안에 표가 있고,
표들끼리 연관관계도 있다.

이런 복잡 구조를 2차원구조로 뜯어서 매핑하는 과정을 “정규화”라고 한다.

그런데 왜 그랬을까?

왜 최초의 DB개발자는 그러한 선택을 했을까?

 

메모리, 디스크가 비쌌던 시절이 있다.

오라클이 한창 성장하던 1980년대에는
10메가 하드디스크가가 3,300 달러 정도 했었다.
1990년대 들어와서야 비로소 20메가가 된다.
국내 가격은 약 20만원.
서버용이라면 더 비쌌다.

데이터크기를 줄이는게 굉장히 중요했다.
조금만 커져도 비용이 확 늘어났기 때문이다.
CHAR, VARCHAR 를 구분할 필요가 있었고,
NUMBER, FLOAT 를 구분할 필요가 있었다.
그것도 부족해서 NCHAR, BINARY_FLOAT 같은 데이터타입을 만들어냈다.

 

처음엔 Oracle 개발자들이 이상해서 그런 줄 알았는데,

나중에 보니 이유가 있었다.

 

N01, 국어

N02, 수학

...


“코드화”를 시키기도 했다.
매번 긴 문자열을 쓰는 것보다,

숫자로 정의된 코드를 쓰는게 유리한 점이 많았다.

요즘도 코드는 쓴다.

코드는 다른 장점도 많아서 잘 살아남을 것 같다.

 

그래서 개발자들은

데이터를 2차원으로 매핑하면서,

중복 필드를 줄여나갔다.

그게 "정규화"의 정체다.

 

2. Document DB

Document DB

문서 DB?
mongodb?

이런게 등장했다.


“블로그”를 생각해보자.
데이터 구조가 대충 이렇다.
제목, 글쓴이, 태그, 글내용 (소제목, 설명글)

그런데 이걸 오랫동안 바라보면 
문서전체를 읽고 쓰는 경우가 많지
특정 필드만 찢어서 다루는 경우는 많지 않다.


그래서 통째로 넣고 빼는 게 편리하다.
중복항목이 있어도,

그냥 통째로 넣고 빼는게 유리하다.

 

특히 요즘은 하드디스크가 싸서,

굳이 중복제거의 압박이 없다.

하지만, 중복항목이 있다면 설명을 잘 달아놓자.
“저쪽 날짜는 이제 안써요.
날짜가 궁금하면 이쪽에 있는 날짜를 쓰세요.”

이렇게 말이다.

 

어디다 적어 놓을까?
“데이터 구조정의” 부분에 써두는 게 가장 좋고,
적어 둘 곳이 없다면, 

“데이터 ”를 호출하는 곳에 적어두는 게 좋다.

문서 전체를 넣고 빼다보니까,
데이터 타입을 한통으로 관리하는게 좋다.
그냥 String 으로 입출력을 받아서 
사용할 때 int 나 string 으로 나누어서 처리하는거다.
Java 같은 언어들은 자료형변환을 해줘야 하는데 이거 은근 귀찮다.
그래서 자료형변환을 컴파일시에 알아서 해주는 언어가 등장한다.

 

블로그형 데이터구조

블로그에만 쓸까?
아니다.
게시판에도 쓴다.
페이스북 타임라인에도 쓴다.

은행통장.
거기에도 쓸까?
아니다.
은행통장은
통장설명만 문서고,
나머지는 아주 기~~인~ 숫자들의 집합이다.
이런 건 2차원데이터,

RDBMS로 사용하는게 유리하다.

통계DB는 어떨까?
통계데이터도 숫자의 이합집산이 편리해야 한다.

Document DB는
문서전체를 저장하기 때문에,
문서 안에 박혀 있는 항목 하나에 접근하기 위해서는
전체 문서를 메모리에 풀어놓고,
그 항목(필드) 하나만 꺼내와야 한다.

처음에는 이게 불편했는데,
요즘 우회방법들이 생기기 시작했다.


음 길어진다.
여기서 STOP.

3. 결론

정규화는 RDBMS에 해당하는 거다.
RDBMS를 쓸지, Document DB를 쓸지는 데이터구조를 보고 판단한다.
그리고, 데이터구조는 어떤 “서비스"를 만들지에 의해 결정된다.
“서비스"는 그 회사의 “사업방향"과 일치한다.
즉, 그 회사의 사업을 보면 데이터형태를 짐작할 수 있다.

 

"정규화"는 그런 걸 다 판단한 후에 사용하는

작은 설계기법 중의 하나인거다.


끝.


댓글을 달아 주세요