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

이번 엔코아 리포트에서는 지난 번에 이어 개체 집합의 모델링 활용에 대해서 알아보자. 개체를 그룹핑하는 또 다른 형태의 데이터 관리 방법 중 Unique 가상 그룹핑 방법과 마스터 데이터간의 데이터 연결법에 대해서 차례로 알아보고 그 활용법에 대해서도 알아보자.

 

 

 1. Unique 가상 그룹 집합이란?

개체를 관리하는 마스터 집합들은 다양한 분류 코드들이 존재한다. 특정한 비즈니스에서는 논리적인 관리용 그룹 집합을 구성할 때 속성들의 특성 값을 이용하여 Unique Group 집합을 만들어야 할 때가 있다.  개체 데이터들의 상위 집합을 생성할 때 사람의 직관에 의해 생성하는 것이 아니라 시스템적으로 Value를 조사하면서 카테고리화(그룹핑) 하는 방법이다.  이 그룹핑 된 집합은 공통적인 속성(특징)들을 가지고 있기 때문에 원가계산, 상품분류, 생산공정, 제품조립 등에서 많이 활용되고 있다. 비즈니스 측면에서는 대량의 마스터 데이터 별로 로직을 처리하는 것이 아니라 공통 속성을 지니는 소량의 그룹핑 집합별로 로직을 처리하고자 할 때 활용된다.

 

• 일반 쇼핑몰에는 다양한 상품들을 관리하고 있다.

• 쇼핑몰 상품은 매우 다양하기 때문에 상품들의 상위 집합을 상품의 특성을 이용하여 자동으로 관리하고자 한다.

• 상품들은 기존에 진열을 위한 카테고리가 정의되어 있다. 기존 분류 방법인 카테고리와는 다른 상품의 매출 관리를 위한 그룹 관리를 하고자 한다.

 

그림 1은 상품에 대한 카테고리와 해당 카테고리에 소속된 상품들이 지닐 수 있는 개별 속성들을 나타내고 있다. 매우 다양한 상품을 관리하기 때문에 카테고리마다 정의해야 하는 속성들이 다르게 나타난다.

 

그림1.jpg

 [그림 1] 상품의 기존 카테고리 분류 체계

 

상품을 분류하는 서브 타입들이 많이 있을 것인데 여기서는 다루지 않는다.  비즈니스가 세분화 됨에 따라 상품의 판매를 예측하거나, 매출 추이에 대한 또 다른 관점을 제공하고자 새로운 분류 체계를 만들고자 한다. 이 분류 체계에는 1개의 속성으로만 상품을 구분하지 않고 여러 개의 속성을 모아서 상품을 구분해야 한다.  1차원이 아닌 다차원으로 상품을 재 해석하려고 하는 것이다.  이를 위해 카테고리별로 다차원 분석에 사용 할 속성들을 지정하게 된다.

 

그림2.jpg

 

               [그림 2] 다차원적인 가상 그룹을 만들기 위한 속성 지정

 

그림 2에는 카테고리별로 분석에 필요한 속성들이 정리되어 있다. 점퍼/바지류는 브랜드/계절/ 나이별 분석이 필요하고, 도서류는 나이/분야별 분석이 필요하다. 이렇게 선택된 속성들로 구성할 새로운 그룹집합을 아이템이라고 정의 하자. 카테고리별 속성의 그룹핑 집합이라고 할 수 있겠다.  속성 Pool브랜드, 계절, 나이, 분야, CPU, 제조사, 메모리’ 7개가 정의되어 있다.

 

이 개념은 실제 비즈니스를 바탕으로 하는 것이 아니라, 임의 개체 집합들에 정의된 속성을 바탕으로 재그룹한 논리적인 집합을 만드는 것이 목적이기 때문에, 후보 속성이 적절한지는 논의 하지 않는다. 서로 다른 속성들로아이템을 정의하려는 의도를 알아채기 바란다.

 

 

그림3.jpg

 

              [그림 3] 속성의 Value를 유니크하게 구성한 가상 그룹집합 > 아이템

 

그림 3은 아이템이 어떻게 생성되는지를 보여 주고 있다. 점퍼와 바지류는 동일한 의류이기 때문에 아이템에 사용할 속성 Pool이 동일하다. 의류는 브랜드별, 계절별, 나이별로 매출에 대한 기여도를 확인하는 것이 중요하다고 판단되었다. 브랜드=’뱅뱅이면서 계절=’인 상품과 계절=’여름인 상품들의 매출 분석을 다르게 평가하고자 한다.

 

여기서 중요한 것은 해당 속성의 Value를 살펴보는 것이다. Value의 조합이 Unique한 것이 특징이다. 브랜드 10, 계절 4, 나이대 10건이라고 가정하면 의류의 아이템 최대 수는 10*4*10 = 400건이 된다. 마찬가지로 도서의 아이템 수는 나이 10 * 분야 20=200 건이 된다. 아이템 후보에 사용되는 속성 수가 많고 속성의 Value값이 많다면 아이템 수는 엄청 많이 늘어 날 수 있겠다.  기존 아이템에 2건짜리 속성(디멘전)이 하나 추가되면 아이템 수는2배가 되는 것이다.

속성 Value의 조합을 Unique하게 구성하여 아이템 번호를 채번하는 것을 기억해 두길 바란다. 간혹 사이트마다 이런 집합을 관리하는 테이블들이 있을 것이다.

 

그림 4는 상품과 아이템을 연결하고 있는 샘플 데이터를 보여 주고 있다. 먼저 데이터 건수를 보면점퍼 10건이고 이에 해당하는의류 아이템 6건이다. ‘도서 7건이며도서 아이템 4건이다. 아이템은 속성을 Group By한 것과 동일한 건수로 만들어 지기 때문에 상품보다는 적은 건수를 지닌다. 아이템을 생성하는 시점은 1) 모든 속성에 대한 경우의 수만큼 미리 생성해 두거나 2) 상품의 추가, 상품 속성값의 변화가 발생될 때 생성할 수 있을 것이다.

 

그림4.jpg

 

                                        [그림 4] 상품과 아이템의 샘플 데이터

 

 2. Unique 가상 그룹 집합의 활용

지금까지 정리한 설명을 바탕으로 Unique 가상 그룹인 아이템 데이터 모델을 작성해 보도록 하자

모델 1은 위에서 설명한 내용을 바탕으로 엔티티와 속성을 도출 하였다. '카테고리', '상품' 엔티티는 키 엔티티가 되겠다. '상품'에는 카테고리 별로 다양한 속성들이 구성되어 있다. 상품의 다양한 속성을 관리하는 방법은 여러 가지가 있는데, 여기서는 아이템의 구성을 이야기 하고 있기 때문에 속성 관리는 그냥 컬럼 형태로 나열되어 있다고 가정한다.

 

‘아이템’은 카테고리별로 구성 속성이 다르기 때문에 ‘의류/도서/컴퓨터’ 3개의 엔티티가 도출되었다. 아이템ID는 인조식별자이고, 개별 아이템마다 실질식별자가 다르게 구성되어 있다. 의류 아이템은 ‘아이템ID’가 PK이며, ‘카테고리ID + 브랜드 + 계절 + 나이’가 Unique Index로 정의 될 수 있을 것이다. 일반적으로 카테고리의 수는 많기 때문에 최종적인 ‘아이템’ 엔티티 모습은 통합이 필요할 것이라고 느낄 것이다. 사용되는 속성이 다르다고 분리하는 것은 적절치 못 할 수 있다.

 

            모델 1) 카테고리별로 아이템 구성

 

그림5.jpg

 

 

같은 성질의 데이터이고, 주어진 역할이 동일한 엔티티를 분리하여 설계하면 많은 애로 사항이 발생 할 것이다. 모델 1은 최종 모델을 완성하기 위한 준비 단계를 모델이라고 볼 수 있겠다.

 

                    모델 2) 컬럼 형태 아이템 모델

그림6.jpg

 

모델 2는 통합된 모습의 아이템 엔티티이다. 통합을 하고 보니아이템상품과의 배타 관계가 자연스럽게 사라져 버렸다. ‘아이템을 구성하는 실질 식별자는카테고리별로 상이한데도 불구하고 통합되어 있다. 이처럼 집합을 구성하는 식별자(PK)가 달라도 엔티티/테이블의 통합은 가능하다. 서브 타입에 있는 속성들은 실제로는아이템(가상)’처럼 속성이 나열된 형태와 동일한 모습이다. ‘아이템(가상)’처럼 속성을 그대로 나열하면 아이템을 구성하는 실질 식별자를 표현 할 수가 없기 때문에 서브 타입으로 표현해 두었다.

 

사실 카테고리가 굉장히 많다면 이런 속성 표현을 모든 서브 타입에 표현하기에는 무리가 있을 수 있다. 이때 이러한 규칙들을 엑셀로 정리해 두는 것도 좋은 방법이다. 

 

혹은 아래 그림의 모델처럼 서브 타입에 표현되어 있던 카테고리별 아이템 속성을 관리하기 위한카테고리별 아이템 속성엔티티와, 아이템을 구성하는 속성 Pool 집합을 관리하기 위한아이템속성을 추가적으로 관리하는 방법도 좋은 방법일 것이다.

 

그림7.jpg

 

이렇게 작성된아이템엔티티의 데이터는 다음과 같이 세팅된다.

 

 

그림8.jpg

아이템의 샘플 데이터에는 카테고리 별로 사용하는 속성에만 값이 채워 지는 것을 볼 수 있다.

여기서 우리는 논리적인 Unique 집합을 관리하기 위한 아이템 모델을 완성하였다고 종료 할 수가 있을 것이다.  그러나 뭔가 좀 찜질하다. 시스템을 운영하면서 카테고리별 아이템이 고정적이고 모든 속성들이 도출 완료 되었다면 현재 모델도 좋은 모델이 될 수 있다.

 

 

속성을 관리하는 방법에는 2가지가 있다. 첫째는 속성을 컬럼 형태로 관리하는 것이고, 둘째는 속성을 Value() 형태로 관리하는 것이다. Value 형태로 관리되는 것의 가장 큰 장점은 유연성이 매우 좋다는 것이고 단점은 SQL작성이 번거롭다는 것이다.

 

모델 3은 아이템을 구성하는 속성들이 Value로 정의되어 아이템구성속성으로 분리되었다.

 

아이템구성속성의 PK를 살펴보자. ‘아이템ID + 속성ID + 속성값으로 정의되어 있다. 속성값이 PK에 포함되어 있다는 것이 핵심 포인트이다.  Value PK로 지정된 모델이다. Value의 구성이 Unique한 논리 집합이기 때문이다.

 

모델 3) Value형태 아이템 모델

 

그림9.jpg

 

 아이템구성속성 Raw형태로 관리되기 때문에 메타 테이블인 아이템속성과 자연스럽게 관계를 갖게 된다. 이 모델의 명확한 쓰임새를 알아보기 위하여 샘플 데이터를 작성해 보자.

 

 

그림10.jpg

 

Value형태의 모델은 샘플 데이터를 보아야 아이템의 구성을 알 수 있다. 아이템을 구성하는 속성값이 변경되면 새로운 아이템ID를 발생시켜야 한다. 속성을 구성하는 값의 Unique를 체크하기 위하여 조금 복잡한 로직이 추가 되어야 할 것이다. 상품이 어떤 아이템에 소속되는지 데이터를 연결하기가 만만치 않다. 데이터 검색 시 WHERE 브랜드 = ‘뱅뱅’ AND 계절 = ‘과 같은 SQL도 직접적으로 사용 할 수가 없다. 컬럼과 컬럼 값이 모두 Row형태로 관리되기 때문에 Group By 형태로 테이블처럼 가공한 이후, 재 검색 해야 하는 SQL을 작성해야 한다. 좀 더 심도 깊게 모델을 이해하고자 하는 분들은 테이블을 직접 생성하고, 샘플 데이터를 입력하고, SQL을 작성해 보길 권한다. SQL로 데이터를 마음대로 조작할 수 있을 때 완벽한 모델을 이해 할 수 있을 것이다.

 

특정 마스터 집합의 속성을 이용하여 Unique한 논리적 그룹 집합을 재 생성하는 개념과 데이터 모델을 살펴 보았다.

 

 

3. 마스터 데이터 연결

 

마스터 데이터 연결은 데이터 모델의 핵심 데이터인 개체집합, 마스터 데이터들은 혼자만으로도 중요한 정보를 관리하고 있다. 그러나 혼자 일 때 모다 여럿이 뭉쳤을 때 강력한 파워를 발휘하듯이 마스터 데이터도 다른 데이터와 서로 연결을 하면서 의미가 강력해 진다. 위에서 설명하고 있는 개체집합의 그룹 개념을 데이터 연결 관점에서 재 해석한 것이라고 볼 수 있다.

 

개체와 개체를 연결하는 이유는? 바로 비즈니스 규칙을 정의하기 위함이다. 다른 말로는 프로그램에서 처리할 로직을 데이터로 세팅하기 위함이다.

 

  • 엔코 전자에서는 다양한 컴퓨터 부품/반제품/완제품을 생산한다.
  • 제품을 생산하기 위해서 많은 제조 장비가 갖추어져 있다. 제조 장비별로 생산 가능한 제품들이 정해져 있다.
  • 제품과 장비의 다양한 셋업 정보들이 존재하며, 셋업 정보를 어떻게 구성할 지가 고민이다.

 

 

 

그림11.jpg

 

                                       [그림 5] 장비와 컴퓨터의 M:M 연결

 

 

그림 5는 컴퓨터를 생산하기 위해서는 많은 장비들이 필요함을 나타내고 있다. 각 장비들은 컴퓨터의 부품, 제품을 생산하기 위하여 가동된다. 모든 장비들이 하나의 컴퓨터를 생산하기 위해 필요한 것은 아니다. 특정 장비는 특정 컴퓨터 제조 공정에만 사용되어 있다. 이러한 규칙들은 미리 세팅되어야 제조 공정 자동화가 구현 될 수 있다.

장비: 컴퓨터의 관계는 M:M으로 구성되어 있다.

 

 

모델 4) 장비컴퓨터 M:M 관계 엔티티

 

 

그림12.jpg

 

모델 4에서의 장비와 컴퓨터는 M:M 관계를 지닌다. 관계형 엔티티는 보통 여러 개의 매핑 규칙을 지니고 있다. 때문에 모델에는 서브타입인관계구분코드 PK로 정의되어 있다.

 

이것으로 데이터 연결 모형이 끝나는 걸까? 대부분의 사이트에서는 이 정도관계엔티티로 마무리되는 경우가 많을 것이다.

 

그러나 비즈니스가 복잡하고 대량의 마스터 데이터를 관리하는 곳에서는 연결 데이터를 만드는 것에 시간과 노력이 많이 소비되기 때문에 또 다른 대안을 찾고자 할 수 있다.

 

 

그림13.jpg

                              

 [그6] 대량의 마스터 데이터를 연결하려면 대량의 관계를 관리해야 한다.

 

마스터 데이터가 엄청 많다면 관계를 설정하는 것이 어지러운 일일 것이다. 과연 이 많은 데이터의 설정이 올바로 세팅 되었는지 담당자도 자신하지 못 할 수 있다. 좀 적은 데이터로 세팅할 수는 없을까? 있다.  바로 이전 글에서 계속 이야기 해오던 그룹핑이 하나의 대안이 될 수 있을 것이다.

 

 

 

그림14.jpg

                                       [그림 7] 그룹을 만들어 관계 개수를 줄여 보자

 

그림 7처럼 생산 장비들은 기계의 특성과 용도에 따라 논리적인 그룹이 가능 할 것이다. 유사한 기능을 수행하는 장비의 특성을 모아서 그룹 개체를 만들고 이 그룹 개체와 컴퓨터를 연결한다. 그림에서 보듯이 수 많은 관계선이 없어지고 단순화 되었다. 관계는 단순해 지겠지만장비그룹을 만들어 관리해야 하고, ‘장비그룹장비마스터의 연결 관리도 해야 한다. 추가적인 업무 관리가 발생하는 것은 어쩔 수 없을 것이다.  과연 이런 그룹 형태의 업무 관리가 효율적인지는 업무 전문가의 많은 경험, 노련함, 의지가 반드시 있어야 할 것이다.

 

모델 5에는장비그룹엔티티가 추가 되었다.  비즈니스 규칙이 장비에서 장비그룹으로 변경되었다. 모델은 평이한 구조이기 때문에 쉽게 이해 할 수 있을 것이다. 그룹 데이터를 누가 어떻게 관리하느냐가 관건이겠다.

 

 

모델 5) 장비그룹으로 컴퓨터와 연결 모델

 

 그림15.jpg

 

그림 8을 보자. 마치 복잡하게 얽힌 실타래가 풀린 것 같은 느낌이 들지 않는가?  그림에서는 일부러 과장하여 단순한 관계선으로 표현하였다. ‘그룹그룹으로 데이터를 연결하는 기법을 사용하였다. 현장에서는 품목코드, 마스터항목, 아이템코드들이 컴퓨터의 그룹집합이 될 수 있겠다.

 

 

 

그림16.jpg

[그림 8] 컴퓨터도이라는 형태의 그룹을 만들어 연결해 볼까?

모델 6에는 데이터 관리가 상세화 됨에 따라 추가적인 엔티티들이 도출되었다. 

 

장비그룹 : 컴퓨터군 = M:M 관계로 구성되었다. 그럴싸한 모델처럼 보인다. 이런 그룹 형태의 모델로 업무를 처리하다 보면 꼭 나타나는 이상한 요건들이 나타난다.  초기 사용시기에는 나타나지 않을 수 있지만, 유지보수 하면서 세월이 지남에 따라 최초 업무 규칙에서 어긋나는 데이터들이 발생한다.

 

모델 6) 그룹끼리의 관계연결 모델

 

그림17.jpg

 

 

OO제품은 장비그룹 관계를 따르지 못해요.  컴퓨터군이 아니라 컴퓨터에 직접 연결해 주세요. 이건 예외사항 이라구요”.  그냥 있는 그대로 쓰세요.  시스템 규칙에서 어긋나지 않게 올바로 사용하세요. 시스템 영향도가 크기 때문에 구현할 수 없어요.” 라는 시스템 관리자의 말은 통하지 않는다. 강성 고객의 입맛에 따라 단순한 로직들은 꼬이기 시작한다.

 

그림18.jpg

[그림 9] 예외 처리를 구현해 줄 수 밖에

 

 

모델 7에 결국 관계 엔티티가 하나 더 추가 되어 버렸다. OO장비에서 사용 가능한 컴퓨터를 찾으려면

 

1) ‘장비그룹컴퓨터군관계를 이용하여 해당 컴퓨터를 찾는다. 2) ‘장비컴퓨터예외관계에서 해당 컴퓨터를 찾는다. 2)번에 데이터가 있으면 이를 따르고 없으면 1)에서 찾은 데이터를 따르게 된다. 양쪽에 데이터가 존재하니 2개의 테이블을 각각 조회하여 매칭시켜 보아야 한다. 이때 2건의 데이터 중 어느 것을 선택할 것인가에 대한 우선순위가 결정되어야 한다.

 

모델 7 2개 관계 테이블을 보면 통합하고 싶은 욕망이 마구 일어나지 않는가?

 

그럼 한 번 통합한 모델을 보자.

 

모델 7) 장비와 컴퓨터의 예외 엔티티 추가 모델

 

 그림19.jpg

 

모델 8에는 관계 엔티티가 통합 되었다. PK장비식별ID’컴퓨터식별ID’로 되어 있다. PK가 서로 다른장비그룹장비를 대신하는 속성이다. 배타적인 PK를 통합한 형태이다.

 

관계의 분리테이블과 통합테이블은 어느 모델이 유리 할까? 너무 많은 통합을 해 놓으면 시간이 흘러 여러 사람의 손을 거치고 나서, 이상한 정체 불명의 통합 관계 엔티티가 될 가능성이 높다. 심지어 개발자도 이곳에 있는 데이터가 무엇인지 모른다. 프로그램을 봐야만 알 수 있는 지경이 올 수도 있다. 통합과 분리는 상황에 따라 다르기 때문에 현재 운영 중인 사이트에서 가장 잘 관리 할 수 있는 형태를 선정 해야겠다.

 

 

모델 8) 관계 테이블의 통합 모델

 

그림20.jpg

 

모델 9에는 장비와 컴퓨터가 직접적인 연결을 하고 있지 않다.  만약 마스터 데이터들간의 공통적인 성격이 있다면 공통속성으로 이루어진장비제품공통엔티티가 도출 될 수 있다. 이는장비컴퓨터간 직접적인 연결을 하지 않고 간접적인 M:M 관계로 로직을 구성 할 수 있다.

 

모델 9) 공통분모로 M:M 연결

 

그림21.jpg

 

결론 및 시사점

 

지금까지 개체 집합을 그룹핑하고 연결하는 여러 데이터 모델링의 활용 방법에 대해서 살펴 보았다. 

하나의 모델에서 출발하여 꼬리에 꼬리를 물고 여러 Case의 모델을 작성 할 수 있다.  이 중에서 업무 환경과 향후 변화의 방향에 최적인 데이터 모형을 잘 선택하여 구성해야 할 것이다. 데이터 모델링이라는 것이 눈으로 한번 읽어서 이해되는 분야가 아니다. 

 

엔티티 하나를 보더라도이건 뭐지?”  왜 이런 거야?”  그래서 어떻게 하라는 거야?” 스스로에게 질문을 던지고 심도 깊게 빠져 들지 않으면 모델링 지식은 책 속에 만 있을 뿐 내 것이 되지 않는다.

 

 

 

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

 

 

 

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

 

 

 

 


 

 

목록