DATOR


1:1 테이블의 진실 데이터모델


제 사연 좀 들어 보세요. 

왜 저만 보면 못 잡아먹어서 안달 이예요?

저도 제가 존재하는 이유가 있단 말이예요.

필요할때는 불러 놓고 왜 이제와서 내 탓만을 하는 건가요?

저도 억울합니다.

억울해요!

 

무슨 이야기 이길래 이렇게 절절 할 까요?

 

이건 바로 우리가 탄생 시킨 1:1 형태의 테이블 이야기이다.

모델 검토시 항상 지적당하고 있는 것이 1:1 분리 테이블일 것이다.  데이터 통합의 기치 아래 여러 개로 쪼개진 테이블들은 하나로 통합을 적극 검토하는 것이 데이터 모델의 방향성이다.  동일한 데이터는 1개의 테이블에서 관리해야 하는데 분리되어 있으니 당연히 통합 대상 중에서 1순위로 선정되곤 한다.

테이블이 1개면 어떻고 2개, 3개로 나뉘어져 있으면 어떤가?  이번에는 1:1 분리형태의 테이블을 알아보고 개인적인 의견을 적어 본다.

 

일단 1:1 테이블이 생성되는 이유를 찾아보자.

 

이유 1) 운영중

운영중인 시스템에서는 테이블에 컬럼을 추가하는 것이 쉽지 않다.  컬럼 추가에 대한 영향도를 파악하기에도 버겁다.  괜히 컬럼하나 추가 하였다가 어디선가 오류가 발생하면 그 책임을 어떻게 감당 할 것인가?  옛날처럼 본인이 테이블 설계하고 관련 프로그램을 코딩하며 화면을 작성하는 슈퍼 멀티 개발자가 요즘에는 많지 않다.  시스템 개발이 분업화 되어서 맡은 영역은 훤하게 알겠지만 다른 영역과 어떤 연결을 하고 있는지 확신할 수 없다. 이때 당연히 컬럼을 추가하지 않고 별개의 테이블을 생성하게 된다.  이런 테이블이 마스터 테이블과 PK구조가 동일한 1:1 분리 테이블이 된다.

 

이유 2) 오너쉽 

테이블에는 오너쉽이라는 것이 있다.  테이블 데이터에 대한 책임을 갖는다.  업무담당자별, 시스템 부서별로 각기 다르다. 내가 관리하는 테이블에 다른 팀/영역에서 필요한 컬럼을 추가해 달라는 요청이 들어온다. 이 컬럼의 데이터는 내가 직접 입력/수정을 하지 않는다.  다른 영역의 화면에서 데이터를 발생시키고 있다. 이런 경우 나는 내가 관리하는 테이블에 내가 알지도 못하는 컬럼을 쉽게 추가 해 주지 않는다.  네 업무니까 네가 알아서 해라는 식으로 나올 수 있다. 이때 메인 테이블에 추가 되어야할 컬럼은 1:1 테이블로 분리되어 생성 될 것이다.

 

이유 3) 성능, 관리

컬럼수가 100개인 메인 테이블이 있다. 데이터 1건이 발생 될때마다 컬럼 100개는 물리적인 공간에 저장된다.  1건을 저장하기 위해 100byte가 최소 필요하다. 그런데 일부 컬럼들은 대부분 null 값을 지닌다.  모델러는 조금이라고 데이터 사이즈를 줄여서 하드용량을 절약하고 싶어 한다.  그래서 대부분 null인 컬럼들은 메인 테이블에서 분리하여 설계 하였다.  100만건인 고객 테이블에서 "일시정지여부" "일시정지일시"라는 컬럼에는 2000건 정도의 고객만 데이터가 입력되어 있다고 가정하자.  데이터 건수가 2000건 소량이기 때문에 분리하여 관리하면 성능상 유리 할 것이다.  또한 이 컬럼들은 다른 100여개의 컬럼들과 함께 조회 하지도 않는다. 성능과 관리의 이유 때문에 1:1 테이블로 분리하였다.

 

이유 4) 특수성 

특정 고객에 대하여 서비스 일시정지 리스트를 관리하는 테이블인 "일시정지고객" 테이블을 설계 하였다. "고객번호"가 PK이고, "일시정지여부", "일시정지일시", "일시정지해제일시"가 일반 속성이다. 최초 설계시에는 통합을 고려하였으나, 일시정지고객은 블랙리스트로 관리되어야 하는 특수성 때문에 메인 테이블에서 관리하지 않기로 했다.  메인 테이블과 한몸에 있어 봐야 도움될 것이 없는 테이블이다.  현재는 고객 테이블과 1:1 형태이지만, 혹시나 나중에 이력관리를 하게 되면 PK구조가 "고객번호 + 정지일시 + 해제일시"로 변경 될지도 모르기 때문에 분리를 결정하였다.  테이블 설계시 분리에 대한 이유와 사연을 기록해 놓지 않았기 때문에, 시간이 흐른 후 모델 점검자는 1:1 테이블이라고 지적을 하며 통합을 검토하라고 할 수 있다.

 

이유 5) 패키지

자체 개발하는 시스템이 아닌 솔루션이나 패키지 시스템에서는 정말이지 컬럼을 추가 할 수가 없다.  업체의 특수한 비즈니스를 수행하는 ASIS 컬럼들과 매핑되는 패키지 컬럼이 없을 수 있다.  이런 컬럼들을 위하여 패키지의 메인 테이블에 컬럼을 추가하는 것은 무리가 발생할 수 있다.  추가 되는 컬럼의 명명규칙을 제대로 정해 놓지 않으면 원래부터 존재하던 컬럼인지,  인하우스 개발시 추가된 컬럼인지 식별을 못 할 수 있다. 패키지 패치시에도 추가된 컬럼이 있으면 장애를 유발할 위험도 있다.  무엇보다 안전성이 우선이기 때문에 1:1 테이블로 컬럼을 분리 해야만 한다.

 

이유 6) 수직분할

이유3과 유사한 경우로서 메인 테이블에 컬럼수가 너무 많아서 1:1로 분리하였다. 그냥 분리한 것이 아니라 "서브타입"별 고유 컬럼들은 해당 업무에서만 사용하기 때문에 분할 하였다. 수직분할이라는 전문용어가 들어가니 분리의 타당성과 정당성이 있어 보인다.  역시 말빨이 먹힐 것 같다.

 

이유 7) Insert 배치 프로그램

우리의 배치 프로그램은 무엇보다 빠른 시간에 끝나야 한다. 성능을 최우선으로 해야 한다.  고객 테이블에 "우수고객등급코드" 컬럼은 매일 밤 고객의 서비스/주문/거래 정보를 바탕으로 산출되는 컬럼이다.  고객은 1000만건이 넘는데 이 컬럼을 매일밤 Update 하기에는 시스템 부하가 너무 심하고 속도도 매우 느리다.  어쩔 수 없이 "우수고객등급" 테이블을 1:1로 분리 한 이후,  배치 처리시 테이블 Truncate를 실행 한 후, 새로운 등급 데이터를 Insert 하고 있다. 빠른 배치 성능 때문에 1:1로 분리하였다.  뭐 고객 정보 조회시에는 1:1 조인 하면 되니까 검색 성능에는 아무 지장이 없다.

 

이유 8) Varchar2(4000), CLOB, BLOB컬럼 

게시판 형태의 의견을 주고 받는 테이블이 있다. 이 테이블에는 신청사유, 질문내용, 답변내용 등 text 혹은 HTML 형태의 데이터가 입력된다. CLOB 컬럼들이 메인 테이블에 떡하니 자리 잡고 있으면 관리상, 성느상 불편하기 때문에 대용량의 정보를 담고 있는 컬럼들은 1:1 로 분리 할 수 있다.

 

이외에 무슨 이유가 있을까요? 

이 글을 보신 분들 중 다른 이유가 있으면 답글 부탁합니다. 사소한 이유라도 괜찮답니다.

 

1:1 테이블은 존재 할 수 밖에 없다. 무조건 사용하지 마라.  통합하라는 것은 존재에 대한 부정과도 같다. 

그러면 이런 1:1 테이블에게 존재의 이유를 부여하고 떳떳하게 세상에 알리는 것은 어떨까? 언제까지 모델링의 어둠속에 갇혀 있을 것인가?

 

방법은 간단하다.

 

유지무죄 무지유죄

( 알면 죄가 없음이요. 모르면 죄가 있음이다 )

 

무죄 1) 엔티티 정의에 1:1 테이블로 분리한 사연을 적는다.  옳던 그르던 간에 설계자가 판단한 이유를 기록한다. 남모르게 은근 슬쩍 테이블을 추가해 놓는 행동은 하지 말자.  통합을 권장하였는데 테이블을 분리하였다고 기죽지 말자.  당당하게 사연을 적어 놓으면  미 통합에 대한 면죄를 받을 수 있다.

 

무죄 2) ERD에 메인 테이블과 1:1 테이블에 관계선을 맺는다.  ERD에 혼자 떨렁 떨어져 있으면 안 된다. 본인 아닌 다른 사람들은 이 테이블이 메인 테이블인지 헷갈려 할 수도 있다.  확실히 분리 테이블이라고 ERD에 표기하면 100점이다.  왠만하면 1:1 테이블들은 메인 테이블 근처에 위치하여 도식화 하자.

 

위 2가지가 지켜진다면 1:1 테이블의 억울함을 해소 시켜 줄 수 있다고 생각한다.

 

PS. 집합의 통합,  테이블의 통합은 개체의 유사성, 동일 역할과 동일 구성시 고려 된다.  이유가 있는 속성들을 1개 테이블로 몰아 넣는 것이 아니다.

그래도 웬만하면 소수의 집중된 테이블에서 관련 된 속성들을 관리하는 것이 여러 모로 유리한 점이 많을 것이다. 너무 1:1 분할을 남발하지는 말자.

 

 

1:1 테이블 그대를 메인 데이터 모델의 정식 구성원으로 명합니다.

 

억울해 하지 마세요. ~~

 

 

* 따뜻한 데이터 세상 만들기 - FROM 핫신 *
Tag :

Leave Comments