DATOR


엔터티 분류 방법 MECE


MECE의 측면에서 엔터티의 명명규칙을 돌아보기 위해 모 회사의 데이터 모델링 가이드에서 제시하는 엔터티의 유형을 나열해 보았다.

1. 원장 : 현재나 최종의 상태를 표시하는 기본적인 엔터티

2. 내역 : 작업 또는 거래시점에 생성되고, 동일 형식의 정보가 낱개 형태로 변경/추가되는 엔터티

3. 이력 : 기본 엔터티가 존재하고 별도로 과거 정보를 시점별로 관리하는 엔터티

4. 상세 : 기본 상위 엔터티가 존재하고 원장엔터티에 대해 1:M으로 세분화된 정보를 관리하는 엔터티

5. 정보 : 원장, 상세, 내역 이외의 엔터티

6. 관계 : 엔터티 간의 관계를 정의하기 위해 사용하는 엔터티

7. 집계 : 이미 존재하는 엔터티로부터 값을 집계하여 생성한 엔터티

8. 코드 : 코드 정보를 관리하는 엔터티

9. 채번 : 일련번호의 생성을 위해 사용하는 엔터티

 

 위 엔터티 명명규칙이 제대로 분류되었는지를 파악하는 방법이 바로 MECE임을 확인하는 것이다. , 9개의 유형이 서로 중복이 없고, 모두 합치면 전체 엔터티를 표현할 수 있어야 하는데 막상 위와 같은 명명규칙을 가지고 실제 엔터티의 명칭을 지정하려고 하다보면 애매한 부분이 많아 쉽게 결정을 내지 못하곤 한다.

 1) '정보' 유형의 정의를 보면 원장, 상세, 내역 이외의 엔터티를 모두 '정보'로 보아야 하는데, 이 4개 분류어 외에도 관계, 집계, 코드 등 더 많은 분류어가 존재하므로 앞뒤가 맞지 않는다.

 2) '원장' 유형의 엔터티와 1:M이긴 하지만 거래시점에 데이터가 생성되는 엔터티를 '내역'으로 보아야 할지, '상세'로 보아야 할지도 결정하기 어렵다.

 3) 잠시 사용하기 위해 생성한 '임시'성 엔터티를 '정보'라는 유형에 포함시키는 것도 적절해 보이지 않으므로 위의 9개의 엔터티 유형이 모든 엔터티에 대해 적용가능한 것인지도 의심스럽다.

 

 실제 엔터티의 명칭을 결정하다보면 위 3가지 이외에도 상당히 많은 엔터티의 분류어를 결정하기 어렵다. 따라서 위 분류 체계에 무엇인가 수정이 가해져야 하는데 그 기준이 되는 것이 MECE 어프로치이다. '중복없이, 빠짐없이'의 MECE의 기준으로 위 분류를 체크해 보면, 정상적으로 발생하는 엔터티 분류, 타 엔터티를 기준으로 상대적으로 설정되는 엔터티 분류, 기타 쓰임에 따른 분류 그리고 불명확한 엔터티 분류 정도로 구분할 수 있다.

 

  정상적으로 발생하는 정보성 엔터티 분류 - 원장, 내역

  타 엔터티를 기준으로 상대적으로 설정되는 엔터티 분류 - 이력, 상세, 관계, 집계

  기타 쓰임에 따른 엔터티 분류 - 코드, 채번

  불명확한 엔터티 분류 - 정보 -> 분류에서 삭제

  또, 위에 나열한 분류가 전체 엔터티를 커버할 수 있는지를 체크하여 '임시'와 '기준' 엔터티 분류를 추가하였다.

 

 이렇게 분류하고 보니 이력, 상세, 관계, 집계를 제외한 나머지 엔터티 분류어는 동일레벨에서 정의가 가능함을 알게 되었다.

 엔터티 분류 ---- 기본유형 ---- 정상적으로 발생하는 정보성 엔터티 분류 - 원장, 내역

                                            ㄴ 쓰임에 따른 엔터티 분류 - 코드, 채번, 임시, 기준

                    ㄴ 타 엔터티 기준 유형 - 이력, 상세, 관계, 집계

 

 위 구분에 일부의 엔터티 분류 간의 관계를 추가하여 다음과 같은 구조가 만들어졌다. MECE 구조를 서브타입으로 나타내니 보다 이해하기 쉬운 구조가 됨을 알 수 있다.(노란색으로 표현된 서브타입이 실제 사용할 명명규칙의 분류어이다.)

 

   엔터티분류어_초기분류5.JPG

 

위의 분류 체계를 좀 살펴보면 다음과 같은 점들이 확정되지 않아 아직은 사용하기에 불완전한 느낌이다.

1. '원장' 분류 중 상위 엔터티가 존재하는 엔터티가 존재한다.(예. 계좌원장은 고객원장의 하위 엔터티)

2. 타엔터티관련유형의 분류는 기본유형의 분류와 헷갈리는 경우가 있다.

   2-1. 내역 Vs 상세 (예. 주소내역인지 주소상세인지)

   2-2. 내역, 상세 Vs 이력 (예. 주문내역과 주문이력의 차이, 주소상세와 주소이력의 차이)

   2-3. 관계 Vs 이력 Vs 내역 (사원_부서관계인지 근무이력인지 근무내역인지)

 

다음은 위 각각에 대한 검토 결과로 글의 중간에 선택 기준이 될 만한 사항은 강조하여 적어 보았다.

1. '원장' 분류를 최상위 엔터티와 하위 엔터티로 나누어 내역 엔터티의 상위가 행위 엔터티가 될 수도 있도록 한다.

 2-1. 내역과 상세의 차이는 특정 엔터티의 보다 상세한 정보를 입력한 것이 '상세'이고, 특정 시점에 발생한 정보를 입력한 것이 '내역'이다. 특정 시점에 발생한 정보를 입력한 것이므로 본질식별자에 '시간'에 대한 속성이 포함되어 있으면 '내역'으로 보면 될 것 같지만, 사원의 경력사항의 본질식별자가 '사원번호', '경력회사', '경력기간'인데, '경력기간'이 있다고 해서 경력 엔터티를 '내역'으로 보기에는 무리가 있다. 사원의 경력, 학력, 가족, 급여 사항 중 회사에 입사한 이후에 발생하는 급여내역 엔터티는 급여 지급 시에 생성하는 '행위' 정보로 보아 내역'으로 볼 수 있지만, '경력', '학력', '가족'은 입사한 사원 개체에 대한 '정보' 차원에서 관리하는 엔터티이므로 '상세'로 보는 것이 타당하다.

 2-2. '내역, '상세'와 '이력'의 차이도 추의해야 한다. 이력의 구분은 '입력/수정 후의 최종 정보만 관리하느냐' 아니면, 변경 전의 정보도 관리하느냐(이력)의 차이에 따라 '이력'여부를 판단한다. 고객의 주문내역과 주문이력을 비교해 보자. 주문내역은 고객이 과거부터 지금까지 일으킨 모든 주문 행위의 최종 정보가 담겨있다. 최종 정보란 제일 마지막의 주문 행위의 정보를 가리키는 것이 아니라 모든 주문내역의 입력/수정 후의 최종 정보를 의미한다. 만약 어떤 고객이 배송지 A를 지정한 주문을 냈다가 발송 이전에 배송지를 B로 변경하면 주문내역에는 배송지 B에 대한 정보만 들어가 있을 것이다. 이 경우 주문이력에는 배송지 A에 대한 정보가 담길 것이다. 간단한 것 같지만, 자칫 주문이력이라 써 놓고 배송지 A의 정보는 없는 경우를 종종 보게 된다. 유사하게 '주소상세'와 '주소이력'에는 차이가 있다. '주소상세' 엔터티에는 고객이 등록한 여러 주소(집주소, 회사주소 등)에 대한 현재 유효한 정보가 담겨있고, '주소이력'에는 '주소상세' 엔터티에서 주소 관련 속성의 수정 전 데이터가 입력될 것이다(수정 후의 데이터 즉 최신 데이터의 이력 엔터티에의 입력 여부는 다른 인자를 검토하여 판단해야 한다). 만약 주소상세 엔터티가 없는 상태에서 '주소이력'엔터티가 존재한다면 이는 '고객원장'엔터티의 주소 속성에 대한 변경이력으로 해석해야 할 것이다. 이런 혼동을 막기 위해 타엔터티관련유형에 속한 엔터티의 명명은 원래 엔터티의 전체 명칭에 '상세','이력' 등의 분류어를 붙이는 것이 좋다. (예. 주소상세이력, 근무내역이력 등) 

 2-3. 사원이 부서를 옮겨다닌 이력이 사원_부서관계인가, 사원의 근무내역일까, 근무이력일까? 사실, 주문상세내역(고객-상품), 근무이력(사원-부서), 계좌원장(고객-상품) 등 사실은 많은 엔터티가 '관계' 엔터티이다. 그러나 이들을 관계 엔터티로 명명하지 않는 것은 기존의 명칭들이 보다 더 의미가 명확히 전달되기 때문일 것이다. 따라서, 관계 엔터티임을 표현하는 것 보다 일반적으로 사용하는 명칭이 더 직관적이고 널리 사용된다면 ~원장, ~내역 등 기본 유형에 포함되어 있는 분류어를 사용하도록 한다.

 한편, 근무이력일까? 근무내역일까? 사원 엔터티의 부서코드 속성이 수정(update)될 때 수정 전의 값을 보관하고 있는 이력이라 해석한다면 근무이력이 되겠지만, 그 엔터티를 사원과 부서의 관계 엔터티로 해석한다면 근무내역이 더 정확할 것이다. 그 판단은 '동일한 사원이 동일한 시기에 둘 이상의 부서에 소속될 수 있는지'에 따라서 달라진다. 동시에 둘 이상의 부서에 소속된다면 현재 시점에서도 사원과 부서의 관계가 M:M이 되어 관계 엔터티가 만들어져야 한다. '관계' 분류어는 상황에 따라 더 직관적인 다른 분류어를 적용할 수 있으며, 생성된 엔터티는 원본 데이터가 되므로 '이력'을 사용할 수 없으므로, '사원-부서 관계' 또는 '근무내역'이라는 명칭이 적합해 보인다. 반면에, 한 명의 사원이 특정 시점에는 하나의 부서에만 소속된다면 사원 엔터티의 부서코드 속성에 대한 수정 전 값을 관리하는 이력 엔터티 즉, '근무이력'이라는 명칭이 올바를 것이다. 이렇게 관계로 해석하지 않더라도 부서코드 외에 같이 변경될 만한 직급이나 직책 속성의 변경이력도 근무이력 엔터티에서 관리될 수 있을 것이다.

 

다음은 위의 명명규칙을 보다 명확하게 변경하고, 각 유형 간의 관계도 함께 표현한 결과로 노란색으로 표현된 서브타입이 실제 사용할 명명규칙의 분류어이다.

 

   엔터티분류어10.JPG     

 

노란색으로 표현된 서브타입의 명칭이 대부분 일반적으로 사용하는 것으로 채워져 있지만 '기본'과 '원장'의 개념을 분리하였다. 기본 엔터티는 최상위 개체 만을 가리키며, 개체의 행위 중 다시 행위의 주체가 될 수 있는 것을 '원장'이라 명명하였다. 또, 엔터티 간의 관계를 보다 정확하게 나타내기 위해 기본유형 서브타입셋트 이외에 아래 쪽에 4개의 ~여부 서브타입셋트를 표현했다.

 얼핏보면 관계까지 표현해서 조금 더 복잡한 것 같지만, 실제 엔터티 간의 관계를 시각적으로 표현하고 있으므로 데이터 모델을 볼 줄 아는 사람이라면 위 모델과 각 엔터티의 정의를 확인해 봄으로써 훨씬 용이하게 엔터티의 명칭을 지정할 수 있을 것이다.

 지금까지 MECE 하도록, 즉 중복이 없도록 하기위해 혼동을 일으킬 만한 부분에 대해서는 어떻게 결정해야 하는지에 대한 몇 가지 기준을 제시하였고, 빠지지 않도록 하기 위해 분류를 추가하기도 하였다. 많은 엔터티를 대상으로 분류 체계를 적용한 결과 만족할 만한 체계임을 확인했지만, 완벽하게 중복이나 누락이 없는지를 보장하기는 어려운 것도 사실이므로 앞으로 미진한 부분이 보이면 수정하도록 하겠다.

 

TAG

Leave Comments