DATOR


개체 그룹핑 모델링 #1 데이터모델


데이터 모델링시 반드시 도출되어야 하는 것이 개체 집합이다. 개체 집합은 마스터, 키, 메인 테이블로 구현되어진다.  마스터 데이터들은 다양한 비즈니스 규칙들을 가지고 있는데, 데이터 하나 하나에 규칙을 세팅하기도 하지만, 공통된 특성을 지니는 분류/카데고리/그룹의 가상집합을 만들고 가상집합에 비즈니스 규칙을 적용하는 경우가 많이 있다.  이러한 경우에 개체집합을 그룹핑하게 되는데 이에 대한 개념과 데이터모델의 구조에 대하여 살펴보도록 한다.

 

< 목적 >

  • 개체집합의 구성에 대한 개념을 알아본다.
  • 개체집합의 그룹핑 데이터 모델의 다양한 구조를 살펴 본다.

< 시나리오 >

  • 우리가 관리하는 제품들은 수천건 이상을 관리하고 있다.
  • 제품에 대한 비즈니스 규칙들이 많은데 그중에서 "판매규칙"에 대한 설정을 하고자 한다.
  • 제품이 대량으로 관리되고 있기 때문에 관리/사용 목적에 따라 분류하여 관리하고자 한다.

개념 1)

그림1.jpg

 

개념 1)에는 여러 개의 제품들이 존재한다. 제품들이 판매될때 여러개의 판매규칙이 존재 할 수 있다.  제품 건수가 100여개 라면 100개에 대한 세팅만 해 주면 되지만,  1000개가 있다면 1000개의 제품별로 판매규칙을 해야 한다. 마스터 데이터가 너무 많기 때문에 도대체 무슨 기준으로 판매규칙을 세팅하고 있는것인지 업무담당자도 혼란스러워 하고, 새로운 제품이 생길때마다 매번 규칙을 설정하는 것도 만만치 않다.

업무담당자는 규칙을 설정하면서 지치게 되고 "좀더 쉬운 방법은 없을까?"를 고민하게 된다. 게으름은 어떤 상황에서는 혁신의 매개체가 될 수 있다.   열성적인 업무담당자는 제품별로 판매규칙 데이터를 분석하게 되고 패턴을 찾아내고자 노력을 한다.  공통적인 규칙을 설정하는 무언가가 있을 것이다.

 

개념 2)

그림2.jpg

 

개념 2)에는 업무담당자가 찾아낸 공통 패턴을 보여 주고 있다.  제품의 생산년도, 제조사, 주요기능, 생산공정에 따라 판매규칙이 동일하다는 것을 알아 냈다. 이러한 공통 특성별로 판매 규칙을 적용한다면 소수의 데이터에만 판매규칙을 설정해 주면 될 것이다.   공통 특성을 지니는 집합을 제품그룹이라고 정의하였다. .  이제 이를 바탕으로 데이터모델의 구조를 어떻게 가져갈 것인가를 고민해 보자.

 

개념 3)

그림3.jpg

 

제품에 대한 공통 집합인 제품그룹을 적용하기 위해 시스템을 재분석 하는 과정에서 IT담당자/개발자는 제품그룹의 개념이 1개가 아니라 여러개 라는 것을 알게 되었다.  개념 3) 에서는 "사용목적", "동일기능", "메인제품"별 그룹집합이 존재한다. 각각 업무에서 사용하는 목적이 다르다고 가정해 본다.  데이터 모델링 진행시 1가지 사실을 있는 그대로 설계에 반영하기 보다는 좀 더 확장된 사고로 이런 저런 case가 있지 않을까를 고려하게 되는데 확장성과 유연성은 시스템 설계자가 지녀야 할 기본적인 자세라고 생각된다.

 

이제 이렇게 정의된 개념을 충실히 반영할 수 있는 데이터 모델을 설계해 본다.  아래 제시하는 모델의 정답은 없다.  현재 상황을 해결 할 수 있는 최적의 모델을 선택하기 위하여 업무담당자/모델러/개발자/운영담당자 등이 모여 지속적인 협의를 해 나가야 할 것이다.

 

모델 1)

모델방안1.jpg

 

모델 1) 은 개념 3)의 이미지를 바탕으로 충실하게 설계되었다. 목적제품/기능제품/메인제품 그룹을 관리하는 엔티티가 있다.  제품은 이들 제품그룹에 소속되어 있다. 현재 모델에는 fk 속성이 not null로 지정되어 반드시 어느 제품그룹에 소속되어야만 한다.  제품판매규칙은 제품 레벨이 아니라 "목적제품그룹"에만 세팅하도록 설계되어 있다.  아마도 현장에서는 이런 형태로 모델링된 곳이 많을 있을 것이다.

 

모델 2)

모델방안2.jpg

모델 2)는 분리된 제품그룹이 하나로 통합되어 있다. 개체집합을 통합하느냐 분리하는냐는 항상 고민거리인데 데이터의 구성과 하는 역할이 유사하다면 일단 통합을 검토해 보는 것을 권장한다.

모델 2-1)은 제품이 소속된 그룹에 대한 fk속성을 가지고 있다.  제품의 그룹이 3개뿐이라는 확신 때문에 그랬을까? 성능때문에? SQL간편하게 작성하기 위해서? 아뭏든 설계자의 의도가 있다면 이런식의 모델 구조를 작성 할 수 있다.

모델 2-2)는 좀 더 유연성이 강조된 모델이다. 제품그룹과 제품ID와의 관계를 fk속성이 아니라 M:M매핑테이블 형태로 풀고 있다.  고정된 컬럼형태에서 동적인 raw 데이터 형태로 관리를 한다. 제품그룹이 아무리 늘어나더라고 테이블에 대한 변경은 발생하지 않는다. SQL 작성시에는 join을 한번더 해야 하기 때문에 불편함은 감수해야 겠다. 또한 엑셀 형태의 grid 형태로 제품특성을 조회하기 위해서는 group by 형태의 SQL을 작성해야 한다. 

유연성을 강조하느냐? 성능을 강조하느냐? 편리성을 강조하느냐? 에 따라 모델의 구조는 달라 질 수 있다.

 

방안 3)

모델방안3.jpg

방안 3)은 방안 2)와 유사한 모델이다.  차이점을 금방 발견 할 수 있는가 ?

제품그룹의 PK 구성이 다르게 되어 있다.  왜 그럴까 ?...

..

asis를 바탕으로 tobe를 재 설계해야 하는 case를 생각해 보자.

asis에는 목적/기능/메인제품그룹이라는 3개의 테이블이 존재 하였다.  tobe 설계시 1개의 테이블로 통합하기로 결정되었다. 그런데 문제는 기존 3개 테이블들의 그룹ID key값이 중복되었다.  기존 data가 이곳 저곳에서 사용되고 있어 영향도가 크기 때문에 data를 변경 할 수 없는 상황이다. 그래서 pk가 제품그룹유형 + 제품그룹ID로 되어 있다.

방안 3-1) 은 "제품그룹유형" 속성이 비상속 처리되어 있다. 즉 PK로 된 속성이 "제품"이나 "제품판매규칙"에는 전달되지 않았다. 제품마스터에 속성으로 구체화되어 있기 때문에 굳이 제품그룹유형속성이 없더라고 어느 제품그룹에 소속되는지 알 수 있기 때문이다.  제품판매규칙에는 목적제품그룹만이 해당하기 때문에 비상속 처리 되어 있다.

방안 3-2) 는 "제품그룹유형" 속성이 상속 처리되어 있다. "제품그룹별제품관계" 테이블에 존재하는 데이터가 무슨 제품그룹인지 알아야 하기 때문이며, 데이터 중복을 방지해야 하기 때문이다.  제품판매규칙에는 향후을 위해 제품그룹유형을 PK로 상속 처리하여 두었다.

 

동일한 개념을 바탕으로 시작된 데이터 모델인데도 업무상황에 따라, 모델러에 따라, asis 구조에 따라 다른 모습의 구조를 지닐 수 있다.

 

여기 까지가 기본적인 개체의 그룹핑 모델이라고 볼 수 있다.

 

다음 회에서는 그룹핑하는 다른 형태의 모델을 살펴 보도록 한다.

 

 

 

 

 

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

Leave Comments