• 미디어 >
  • 엔코아 리포트
Weekly Brief
[조회수 : 13251]  다운로드
효과적인 데이터 분석의 출발, 데이터 모델링의 이해 Ⅱ(활용편) - #1. 개체 그룹핑 모델링

정보 시스템을 구축하는 과정에서 데이터 모델링 과정은 종종 건축물을 만드는 과정에 비유되곤 한다. 건물을 세울 때 사용되는 자재는 그 종류와 수량이 매우 다양하고 많다. 만약 이 자재들을 한 번에 전부를 가져다 놓고서 건물을 세우기 시작하면 작업의 효율성이 매우 떨어지는 것은 자명하다. 아주 큰 건물을 짓는다고 하면 이런 방식으로는 불가능할 수 도 있다. 그렇다면 건물을 세울 때 바람직한 방법은 무엇일까? 먼저 건물의 조감도를 그리고 그에 따른 설계 도면을 만들어야 한다. 또한 전체 건물을 세우기 위해서 가장 먼저 진행해야 할 일부터 차례로 일의 순서를 정하는 것을 해야 할 것이다. 아마도 가장 먼저 진행해야 할 일은 건물의 골조를 세우는 일이 될 것이다.

 

정보 시스템을 구축하는 과정도 이와 유사한다. 정보 시스템에서의 골격에 해당하는 데이터 구조를 설계한다. 특히 데이터 구조를 설계할 때에도 먼저 확정하여 기초의 역할을 하는 데이터 구조가 존재한다. 여기에서 기초의 역할을 하는 데이터 구조를 개체 집합이라고 할 수 있다.

 

이번 엔코아 리포트 데이터 모델링의 활용 영역에서는 데이터 구조에서의 개체 집합의 모델링 활용에 대해서 2회로 나누어 자세히 알아보고자 한다.

 

1. 개체 집합이란?

먼저 개체 그룹핑 모델링이라는 용어에서 ‘개체’라는 단어의 사전적 의미를 살펴보면 전체집단상대하여 하나하나낱개이르는 로서, 데이터 모델링 시 반드시 도출되어야 하는 것을 가리켜 개체 집합이라 한다. 개체 집합은 마스터, , 핵심, 기본 테이블로 불리기도 한다개체 집합들은 다양한 비즈니스 규칙들을 가지고 있는데, 데이터 하나 하나에 규칙을 세팅하기도 하지만, 공통된 특성을 지니는 분류, 카데고리, 그룹의 가상 집합을 만들고 가상 집합에 비즈니스 규칙을 적용하는 경우가 많다이러한 경우에 개체 집합을 그룹핑하여 관리하게 되는데 이에 대한 개념과 데이터 모델의 구조에 대하여 살펴보자.

 

본 글에서는 개체 집합, 핵심, , 기본, 마스터 데이터 등 여러 용어들을 사용하는데 모두 같은 의미라고 보면 된다. 개체 집합인 마스터 데이터의 여러 모델링 활용 방법 중에서 첫째는 마스터 데이터의 일반적인 그룹핑 방법과 둘째는 Unique 가상 그룹핑 방법, 그리고 세번째는 마스터 데이터간의 데이터 연결법이 있다. 차례로 각 방법과 그 활용법에 대해서 알아보자.

 

2, 개체 집합 그룹핑

우리가 관리하는 제품들은 수 천건 이상을 관리하고 있다(제품은 마스터 데이터로서 개체 집합이다).

 

제품에 대한 비즈니스 규칙들이 많은데 그 중에서 판매 규칙에 대한 설정을 하고자 한다. 제품이 대량으로 관리되고 있기 때문에 관리 및 사용 목적에 따라 분류가 필요하다.

 

그림1.JPG

                              [그림 1] 제품 한 건씩 판매 규칙을 설정

 

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

 

업무 담당자는 규칙을 설정하면서 지치게 되고 "좀더 쉬운 방법은 없을까?"를 고민하게 된다.

열성적인 업무 담당자는 제품별로 판매 규칙 데이터를 분석하게 되고 패턴을 찾아내고자 노력한다

 

  

                          그림2.JPG

                      [그림 2] 공통 특성을 지닌 소량의 그룹으로 판매 규칙을 설정

 

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

 

              그림3.jpg  

 

                                           [그림 3] 여러 개의 제품 그룹을 관리

 

그림 31개의 제품이 여러 개의 다른 그룹에 소속 관리 될 수 있다는 것을 보여 주고 있다.

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

 

이제 이렇게 정의된 개념을 충실히 반영할 수 있는 데이터 모델을 설계해 보자

아래 제시하는  모델의 정답은 없다현재 상황을 해결 할 수 있는 최적의 모델을 선택하기 위하여 업무 담당자, 모델러, 개발자, 운영 담당자 등이 모여 지속적인 협의를 해 나가야 할 것이다.

 

                         모델 1) 독립적인 그룹 개체

                               그림4.jpg  

                              

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

 

모델 2) 그룹 개체의 통합

모델 2-1)                                                모델 2-2)

 

      그림 5.jpg

                  

 

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

 

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

 

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

 

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

 

모델 3) 통합 그룹의 PK 정의

모델 3-1)                                             모델 3-2)

 그림 6.jpg

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

 

제품 그룹의 PK 구성이 다르게 되어 있다왜 그럴까? 현재 운영 중인 As is 리버스 모델을 바탕으로 To be를 재 설계해야 하는 Case를 생각해 보자.

 

As is에는 목적, 기능, 메인 제품 그룹이라는 3개의 테이블이 존재하였다. To be 설계 시 1개의 테이블로 통합하기로 결정되었다. 그런데 문제는 기존 3개 테이블들의 그룹 ID Key값이 중복되었다.기존 데이터가 이곳 저곳에서 사용되고 있어 영향도가 크기 때문에 데이터를 변경 할 수 없는 상황이다. 그래서 PK제품 그룹 유형 + 제품 그룹 ID’로 구성되어야 한다.

 

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

 

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

 

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

 

지금까지 살펴본 모델 1, 2, 3은 기본적인 개체의 그룹핑 모델이라고 볼 수 있다. 이번에는 개체와 개체 그룹에 대한 좀 더 차원 높은 또 다른 방법에 대하여 살펴보자. 각각의 개념이나 방안들에 대한 답안은 없다. 각 사이트마다 상황에 따라 최적의 모델을 선택하면 된다어떤 사이트에서는 동일한 성격의 데이터 모델은 표준 한 개만을 선택하여 다른 것을 사용하지 말라고 권하기도 하는데, 테이블마다 업무 성격에 따라 다른 구조를 적용해 보고좋고 나쁨은 운영하면서 판단해 보는 것이 효과적이다. 먼저 한 통에 개체와 개체 그룹을 통합하는 개념을 살펴 보자.

 

 

                         그림 7.jpg  

                                                 [그림 4] 개체와 개체 그룹의 통합

 

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

 

모델 4) 개체와 개체 그룹의 통합 모델

모델 4-1)                                                                 모델 4-2)

그림 8.jpg

 

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

 

모델 4-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 로서 중복되어 있을 수 있을 것이다.

 

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

 

                      그림 9.jpg

                                    [그림 5] 개체의 메인을 나타내는 대표 지정

 

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

 

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

 

 

모델 5) 개체의 대표를 지정하는 모델

모델 5-1)                                   모델 5-2)

그림 10.jpg

 

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

 

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

 

 

 

 

 

지금까지 개체 집합에 대한 모델 구조를 살펴 보았다. 다음 엔코아 리포트에서는 개체를 그룹핑하는 또 다른 형태의 데이터 관리 방법에 대해 연구한 자료를 공유하고자 한다.

 

 

다운로드>>EN-CORE_Report_2013.09.01.pdf

 

 

 

 

 

목록