DATOR


여부컬럼 #2 : 모델적용 데이터모델


여부 컬럼이 실제 데이터 모델에서 어떻게 표현되는지 살펴보자.

 

데이터 모델링은 건축(집 짓는 것)과 많이 비교되곤 한다. 컬럼의 위치를 설정하는 것도 유사하다. 내 집의 잡동사니들을 어느 곳에 위치해 두는가?

 

방 하나에 모든 잡동사니를 모아 놓는다 ( 귀찮은 사람, 혹은 방1개만 있는 집 )

사용빈도에 따라 다르다 (자주 쓰는 것은 거실에, 가끔 쓰는 것은 베란다 )

값어치에 따라 배치한다 (비싼 것 거실에 장식용으로, 싸구려는 창고에)

라벨을 붙여서 목록화한다.(꼼꼼한 사람은 그룹별로 라벨 주어서 쉽게 찾을수 있도록 꾸민다)

 

내 방의 잡동사니는 어떤가 ? 

나는 처음엔 꼼꼼하게 계획하여 정리하는 편일까? 

시간이 흘러 가면 처음 의도와는 다르게 이곳 저곳에 자리잡고 살아가는 잡동사니들을 볼 수 있다. 마치 테이블의 컬럼들이 처음 의도와는 다르게 이곳 저곳에 배치되는 것과 유사한 것 같다.

 

그럼 여부 컬럼들은 테이블의 어떤 위치에서 살아 갈 수 있을까?

여부 컬럼들이 존재하는 방들을 살펴 본다.

 

적절하게 방안을 꾸미는 것은 모델러의 몫이리라.

 

1) 기본 마스터 테이블의 컬럼으로 존재

 

슬라이드1.JPG  

내가 경험한 OO은행사이트의 계좌테이블은 무려 200여개의 여부 컬럼이 있었다.

 

아래 모델은 상품에 존재 할 수 있는 여부 컬럼의 사례이다.

 

 

여부 컬럼은 키/메인/핵심 테이블에 위치 시켜 질 수 있다.

보통 오랜된 사이트의 메인 테이블을 리버스 해보면 마스터 테이블에 덕지 덕지 달라 붙어 있는 여부 컬럼들을 흔히 볼 수가 있다.

 

[ 장점 ]

- 마스터 테이블 조회시 바로 검색 할 수 있다. SELECT COL 구문만 작성하면 된다.

- 조인이 필요 없기 때문에 조인을 회피함으로써 성능에 유리 할 수 있다 (항상 그런 것은 아니다 )

 

[ 단점 ]

- 모델이 유연하지 못하다.  여부 컬럼이 추가 될 때 마다 테이블의 변경이 발생하고, 마스터 테이블 변경은 주요 어플리케이션의 변경도 함께 동반 할 수 있다.

- 여부 컬럼이 특정한 상황 일 때만 사용되는 경우라면 값이 대부분 없음에도 불구하고 1BYTE를 차지 하게 된다. 예를 들어 정품여부는 특정 브랜드 일때만 체크하는 속성이다.  Y: 1000  N:2999000. 즉 대부분은 정품여부 컬럼을 사용하지 않는다.

 

[ 의견 ]

- 개체의 구성과 역할을 이해하는데 필요한 여부 컬럼은 마스터에 둔다

- SELECT 절에서 자주 사용되며, 사용자 화면에서 매번 검색되는 컬럼은 마스터에 둔다.

- 성능에 필요하다고 판단되는 컬럼은 마스터에 둔다

- 대부분의 여부 값이 세팅되는 컬럼은 마스터에 둔다. (사용여부, 판매여부 : 대부분 Y)

 

 

2) 1:1 테이블 분리

 

슬라이드2.JPG   

부속품은 부속품대로 따로 보관하는 전략을 사용 한다.

여부 컬럼은 1:1 확장 테이블에 위치 시킨다.

 

[ 장점 ]

- 기본 테이블이 가벼워 졌다. 많은 컬럼들을 가지고 다니지 않으니 부담감이 없다. 그만큼 들고 다닐 때 빠른 속도를 낼 수 있겠지.

- 추가되는 속성은 확장에만 있는 컬럼 ADD시 기본 테이블의 변경에 대한 부담이 없다.

 

[ 단점 ]

- 확장 컬럼을 참조하려면 조인을 해야 한다.

- 1:1 필수 입력이기 때문에 INSERT 2개 테이블에 동시에 데이터를 발생시킨다.

 

[ 의견 ]

- LIST 목록에 조회가 자주되는 컬럼은 확장에 만들지 않는다.

- 가끔 참조되는 컬럼은 확장에 둔다.

- PK로 조회되는 팝업 창, 상세내역 화면에서만 보면 되는 컬럼은 확장에 둔다.

- 컬럼의 값이 많지 않는 경우는 확장에 위치한다.( 정품여부는 1% 만이 값이 있으므로 확장에 위치 시키면 되겠다 )

 

 

 

3) 1:M 테이블 분리

 

슬라이드3.JPG   

여부 컬럼은 1:M 확장 테이블에 위치 시킨다.

컬럼은 물리적 위치에서 논리적인 값으로 변화를 일으킨다.

 

모델이 쪼개 지는 순간 머리도 함께 쪼개 지려 하지 않는가? 머릿속이 하얘지는 이유는 형상화 되지 않기 때문이다. 이럴 땐 엑셀을 꺼내 들고 데이터를 만들어 보자.  데이터를 그리는 방법이 모델을 이해 가장 좋은 방법이다.

 

[ 여부코드 ]

 

10

재판매제한여부

RE_SALE_RES_YN

Y

11

무료판매여부

NO_FEE_YN

Y

12

적립금제한여부

ACCU_LIMIT_YN

Y

13

프로모션제한여부

PRO_LIMIT_YN

N

- 컬럼 정의를 하기 위한 코드 테이블을 정의한다.

- 값으로 정의하기 때문에 관리를 위한 정보를 추가 할 수 있다

  ( 사용여부, 한글명, 영문명, 사용여부)

 

[ 상품_M분리 ]

 

상품번호

여부속성코드

속성값

등록일시

9001

10

Y

2011-01-25

9002

10

Y

2011-01-25

9003

10

N

2011-01-25

9001

20

Y

2011-01-25

9002

20

Y

2011-01-25

 

- 상품과 여부코드가 만나서 생기는 매핑 테이블 형식을 취한다.

  ( 매핑 테이블 = 교차 테이블 = 관계 테이블 : 모두 동의어 )

- 속성값 레벨이기 때문에 추가적인 관리속성을 만들 수 있다.

 

[ 장점 ]

- 최고 장점은 유연성이다. 속성이 추가 되더라도 테이블 변경 없이 데이터 값만 추가하여 관리하면 된다.  유연하다고 하여 프로그램을 수정하지 않아도 된다는 것은 아니다.  당연히 해당 로직에 들어갈 코드는 하드 코딩 되어야 한다.

- 여부 마다 인덱스를 만들지 않아도 된다. 여부속성코드에만 인덱스를 만들면 된다.

  1:1 모델에서는 재판매제한여부 인덱스, 무료판매여부 인덱스, 적립금제한여부 인덱스를 모두 만들어야 하지만, 1:M모델에서는 여부속성코드에만 인덱스를 만들면 된다.

- 이력관리를 하고자 한다면 시작일시 ~ 종료일시를 부여하여 변경이력 까지도 쉽게 관리 가능하다.

 

[ 단점 ]

- SQL이 복잡하다.  어려운 것은 아니지만 컬럼으로 조회하는 것보다는 접근이 어렵다

- 성능이 나빠 질 수도 있다. 특히 리스트 조회 하는 곳에서는 M건을 1개로 치환하기 위하여 GROUP BY 혹은 스칼라 서브쿼리가 사용될 수 있다.

 

[ 의견 ]

- 여부 컬럼을 목록화 하여 값으로 가져갈 때는 성능상 이슈가 발생할 수 있다. 여기서는 성능까지 심도 깊게 다루지는 않는다. ( 다음 기회에 )

- PK로 상품별, 혹은 고객별로 상세 정보 뷰 하는 곳에서는 사용해 봄 직 하다.

- 한시적인 관리 속성일 때 사용 가능 하다. ( 1월 잠시 STOP 상품여부를 설정 할 때 )

- 속성이 M 테이블로 분리되는 사유 및 상황은 아주 다양하다. 그 변화를 느끼고 알면서 모델에 적용하는 것이 좋겠다.

- 테이블을 설계하고 CREATE 하는 것은 쉬울 수 있겠으나, 활용성과 편이성을 고려하여 여부 컬럼을 적절하게 분산 배치해야 한다. 데이터 이행시에도 주의해야 겠다.

 

 

4) 1:1 테이블 분리 : 테이블 메타 기법

 

 슬라이드4.JPG

1:M 의 성능 문제를 다소 해결한 모델 기법이다.

한마디로 표현한다면 정의 내리고 사용한다

교과서에 나오는 컬럼 정의 방법에는 위배 되지만 패키지 모델에서 많이 사용되고, 알게 모르게 현장에서 많이 사용되고 있는 방법이다.

( : 공통코드에 보면 기타1, 기타2, 기타3 등의 컬럼을 볼 수 있다.  )

 

다음 기회에 자세한 사례를 다루도록 하고 여기서는 특성만 살펴본다.

테이블에 컬럼을 메타형태로 표현하였다 해서 테이블 메타 기법 이라 부르기도 한다.

 

[ 테이블메타 ]

 

상품번호

여부구분코드

속성값1

속성값1

속성값1

속성값4

9001

제한속성

Y

Y

Y

Y

9001

배송속성

Y

Y

Y

Y

9001

기타속성

N

N

N

N

9002

제한속성

Y

Y

Y

Y

9002

배송속성

Y

Y

Y

Y

 

- 시스템 마다 이런 형태의 테이블이 한 두개는 존재 할 것이다.

- 속성값1, 속성값2, 속성값3, 속성값4의 의미는 여부구분코드에 따라 다르다

제한속성 일때는 컬럼 순서대로  재판매제한여부 / 무료판매여부 / 적립금제한여부 /일시불할인제한여부로 사용된다.

배송속성 일때는 컬럼 순서대로 유료배송여부 / 당일배송여부 / 반품제한여부 / 배송제한여부 로 사용된다.

 

[ 장점 ]

- 컬럼으로 정의 되기 때문에 SQL 작성이 쉽고, 1:M 형보다는 성능에 유리하다

- 여부 속성을 공통으로 묶어 주는 단위인 여부구분코드설정에 따라 많은 속성을 정의하여 사용 할 수 있다.

- 물론 속성이 추가 되더라도 테이블 변경 없이 값 변경으로 적용 가능하다 (유연성이 좋다고 말 할 수도 있겠다)

 

[ 단점 ]

- 테이블과 컬럼,데이터만 보면 정의를 알 수 없다. 따라서 별도의 속성을 정의하는 메타관리 코드 테이블이 필요 할 수 있다.

- 1개의 컬럼이 다중적인 의미를 갖고 있기 때문에 주의 해야 한다.

 

[ 의견 ]

- 컬럼이 무수히 많이 발생할 소지가 많은 테이블일 경우 적용 검토 할 수 있다.

- 서브타입 역할을 하는 구분코드를 유형별로 잘 묶어 주어야 한다.

- 성능이나 SQL 작성은 1:M 형 보다 단순하고 간단하다.

 

 

지금 까지 여부 컬럼이 일반적으로 테이블에 적용되는 사례를 살펴 보았다.

 

다음에는 특수한 여부컬럼 방식에 대해서 살펴본다.

 

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

Leave Comments