DATOR


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


개체 그룹핑 모델링에 대한 다른 방안들을 "개체 그룹핑 모델링 #1"에 이어서 진행해 보도록 한다.

각각의 개념이나 방안들에 대한 답안은 없다. 각 사이트마다 상황에 따라 최적의 모델을 선택하면 된다어떤 사이트에서는 동일한 성격의 데이터 모델은 표준 1개만을 선택하여 다른 것을 사용하지 말라고 권하기도 하는데, 저는 테이블마다 업무성격에 따라 다른 구조를 적용해 보고,  좋고 나쁨은 운영하면서 판단해 보는 것이 좋을 것이라고 생각 한다.

 

먼저 한 통에 개체를 통합하는 개념을 살펴 봅니다.

 

개념 1)

개념2-1.jpg

 

제품은 물리적으로 관리하는 레벨이고제품그룹은 관리를 위해서 만든 가상의 묶음집합 레벨이다논리집합과 물리집합의 구성과 역할이 유사할 경우 통합을 진행 할 수 있다업무를 좀 더 깊숙히 분석하다 보면 "판매규칙"을 세팅하는 로직이 그룹별로 진행하거나 특정한 제품별로 진행 할 수도 있을 것이다마스터가 통합되니 자연적으로 자식 엔티티들도 통합을 고려하게 될 것이다한통에 있으면 복잡하지 않을까? 성능에 지장을 주지 않을까?를 걱정하게 되는데 적절한 서브타입과 인덱스, SQL을 사용하면 큰 걱정을 하지 않아도 된다.

 

모델 1)

개념2-1_방안2.jpg

방안 1-1) 모델은 위 개념1)을 그대로 모델로 표현한 구조이다논리집합과 물리집합은 1:M으로 구성된다제품유형이 서브타입으로 정의되어 있음을 유의하자. 상위-하위의 구조처럼 순환관계로 표현되어 있지만 LEVEL 1만 존재한다순환관계가 속성으로 되어 있기 때문에 제품유형 서브타입이 하나 추가되면 FK속성으로서 00제품그룹ID가 추가되어야 할 것이다.  "제품판매규칙"은 그룹으로 설정하든 제품으로 설정하든 비즈니스에 따라 정의 할 수 있다물론 프로그램을 작성하기 전에 명확한 업무정의가 선행되어야만 하겠다어떨때 부모에 세팅하고 어떨때 자식레벨에 세팅할 것인지가 불명확하게 정의되어 있으면 많은 혼선을 가져오는 모델이기도 하다. ( 이런류의 데이터 세팅하는 것은 나중에 다시 한번 논의해 보자 )

 

방안 2-2) 모델은 제품그룹 : 제품을 M:M으로 분리한 경우이다.  1:M의 업무규칙을 M:M 모델로 변환한 것으로 볼 수 있을까아니다제품그룹별로는 1:M 구조이다. 즉 기능제품그룹 : 제품 = 1:M, 메인제품그룹 : 제품 = 1: M이기 때문이다관계 혹은 매핑 데이터를 속성으로 관리할지 M:M 테이블로 분리할지도 모델링 작업시 고민되는 문제일 것이다. 비즈니스가 유동적이고 제품유형 그룹이 사용자의 성향에 따라 쉽게 변경되는 비즈니스 구조라면 당연히 M:M 분리테이블을 사용하는 것이 유리하다비즈니스가 고정적이여서 5 10년간 그룹이 발생하지 않는 곳에서는 일반 속성으로 관리하는 것이 개발과 성능면에서 유리할 것이다.

 

실제 현장에서 운영중인 시스템들에는 동일한 데이터를 관리함에 있어서 ● 어떤 그룹ID 제품속성으로 존재하고, ●어떤 그룹ID M:M 테이블에서 관리하고 있기도 하다성능상의 이유로 제품마스터에 관계속성을 중복하기도 하며,  M:M 관계테이블이 이력구조로 되어 있을때 제품마스터에는 현재제품그룹ID 로서 중복되어 있을 수 있을 것이다.

 

다음은 그룹개념과 유사한 "대표"라는 개념으로 관리되어지는 상황을 살펴 봅니다. 대표 개념도 사이트에서 간혹 발견된다.

 

개념 2)

개념2-2 대표.jpg

 

하나의 제품 테이블에 제품 데이터들이 있다제품은 특성이 조금씩 변경될 때 서브제품으로 파생/분할/스플릿 되어 지는데 서브제품도 제품과 동일한 개체로 관리된다. ( K10, K10-1, K10-2 ).  제품중에서는 아직 서브제품으로 파생되지 못한 것들도 존재한다. (H20, F20).  서브제품의 대분분 특성들은 대표제품과 동일하게 구성되어 있으며, 제품에 대한 규칙(셋업)정보를 설정시 대표제품에만 해당 룰을 세팅하여 관리되어 진다마스터 데이터 관리시 논리적인 그룹을 지정하는 것이 아니라 개체가 상징적인 대표성을 지니는가에 촛점을 맞추고 있다.

 

대표라는 것도 현장에서는 발생하는 데이터을 분류 방법이고 이를 위한 데이터 모델도 존재한다다만 데이터의 이해도와 사용되는 로직에 따라 대표지정보다는 논리적인 그룹집합을 생성하는 것이 좀 더 유리 할 수 있다개인적으로 대표제품 개념은 좀 혼란스럽고 어지럽다.

 

모델 2)

개념2-2 대표_모델방안.jpg

방안 2-1) 모델은 제품이 순환구조를 지니게 표현되어 있다대표제품ID Value가 있는 제품은 서브제품이라고 볼 수 있다대표제품ID NULL 인 것은 자식을 지니는 대표제품이라고 볼 수 있다데이터 입력 방법에 따라 대표제품ID Not Null로 지정한 경우에는 제품ID = 대표제품ID일때 대표제품이라고 판단하는 경우도 있다또한 본 모델에 "대표여부" 속성을 추가하면 어떤 제품이 대표로 지정된 제품인지를 알 수 있을 것이다대표제품-서브제품-서브제픔-서브제픔 처럼 계속 분할될 수 있는 데이터라면 순환구조 테이블 설계하듯이 root를 상징하는 "최상위 대표제품ID"를 중복 속성으로 관리 하는 것이 좋겠다.

 

방안 2-2) 모델은 대표제품으로 사용되는 데이터를 1:1로 분리한 형태이다. 대표제품인 경우만 독립적으로 관리하고자 할때 분리할 수 있다. 이는 대표여부 속성이 분리한 Case라고 보면 되겠다.

 

여기까지 개체집합에 대한 모델 구조를 살펴 보았다다른 모델 형태가 나타나면 지속으로 변경관리를 해 두어야 겠다.

 

< 정리 >

1) 여러개의 그룹 테이블을 분리하여 사용하는 모델

2) 그룹유형 서브타입을 통합하는 모델

   - 관계 속성을 마스터에서 관리

   - 관계 테이블로 분리하여 관리

3) 그룹유형의 서브타입을 통합할때 PK를 지정하는 모델

4) 그룹과 개체을 한 통으로 통합하는 모델

5) 개체중에서 대표를 지정하여 관리하는 모델

 

참조 > http://www.dator.co.kr/skdh/textyle/231877  

         (데이터 부스러기 > 특정 개체들의 묶음을 정의하고자 할때 데이터 모델 및 데이터 정의 방법)

 

"매일 매일 조금씩 강해지자" . . .

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

Leave Comments