DA 가이드

DA, SQL, DB보안 등 실무자를 위한 위한 DB기술 바이블!

후보 엔터티 설정

데이터 모델링
개념 데이터 모델링
후보 엔터티 선정
작성자
admin
작성일
2021-02-10 14:36
조회
2914

개념

엔터티를 선정하기 위해서 우리가 가장 먼저 해야 할 일은 엔터티 후보를 수집하는 것이다. 이 단계는 말 그대로 후보를 찾아내는 것이지 엔터티를 확정하는 것이 아니므로 후보의 자격 여부만 가려내는 선에서 수사를 멈출 수 있어야 한다. 엔터티 후보를 수집할 때는 다양한 경로를 통해 수집하는 것이 바람직하며, 후보인지를 검증하는 객관적인 기준을 적용하여 후보라는 것을 판명하는 엔터티 후보 판정 단계를 거치게 된다. 이들은 엔터티 후보 분류 단계에서 3가지 형태로 분류된다.


엔터티 후보 수집

엔터티 후보를 수집할 수 있는 방법은, 기존 시스템이 있었다면 시스템 도큐먼트(Document)가 있고, 현업에서 사용하는 각종 장표들도 있다. 또한 현업 사용자와의 인터뷰를 통해 후보를 찾을 수도 있고, 관련 서적을 통해서도 가능하다. 만약 프로세스 모델링을 먼저 수행하여 자료 흐름도가 나와 있다면 그 속에 있는 데이터 스토어 또한 훌륭한 엔터티 후보가 될 수 있다. 뿐만 아니라 타사 혹은 유사 시스템의 자료를 확보하고 있다면 거기에서도 많은 후보가 나타날 것이다. 현업 담당자들이 기안한 각종 보고 자료, 또는 현장에 가서 직접 업무를 조사해 보는 방법도 있다.


기존 시스템 도큐먼트

시스템 도큐먼트에는 데이터 구조 및 프로세스 명세들이 나타나 있는 설계 자료에서부터 사용자를 위한 지침서에 이르기까지 다양한 도큐먼트가 있다. 이 자료를 가지고 있다면 엔터티 후보를 도출하는데 가장 유용하게 사용할 수 있다.


현업 장표/보고서

실제 업무를 하는 조직에서는 대체적으로 정보시스템과 관련되지 않았더라도 오래 전부터 그들이 수행하는 업무의 효과적인 처리를 위하여 많은 장표를 가지고 있다. 또한 처리된 업무의 집계·분석·관리를 위해서 많은 종류의 보고서를 가지고 있다. 이러한 장표나 보고서에서 진짜 엔터티를 찾으려면 이 자료를 만들기 위해서 어떤 본질적인 집합이 필요한지를 분석해 보아야 한다. 좀 더 자세히 말하면 자료에 기술된 항목들을 속성이라 가정하고 이 속성들의 주인이 될 본질적인 집합이 무엇이 될지를 검토해 보라는 것이다. 여기서 말하는 본질 집합은 가공된 결과가 아닌 원재료(Source)가 되는 정보를 말한다.


현업 인터뷰(Interview)

엔터티 후보를 도출할 때부터 현업 담당자들과 같이 시작하는 것이 최상의 모델링 방법이다. 사전에 충분한 분석을 통해 짧은 시간에 많은 것을 확인할 수 있도록 질문을 준비해야 한다.


관련 전문 서적

현재의 업무를 있는 그대로의 모습으로 형상화하는 것이 아니라 좀 더 개선되고 발전된 모습으로 재창조하는 것이다. 이를 위해서 얻을 수 있는 정보는 현업만으로는 분명히 한계가 있다. 관련 전문 서적을 통하여 현실에 적용하기 위해 고민하고 있는 문제를 해결하는 데 필요한 아이디어나 힌트를 얻을 수만 있어도 충분히 목적을 달성한 것이다. 이러한 시각에서 전문 서적을 참고하면 생각보다 얻을 것이 많다.


데이터 흐름도 (DFD, Data Flow Diagram)

업무 파악 및 시스템 분석을 위해 기능 설계를 데이터 흐름도로 작성했다면, 여기에 있는 데이터 저장소(Data Store)와 데이터 사전(Data Dictionary)에 있는 정보를 이용하여 엔터티 후보를 도출할 수 있다. 데이터 흐름도를 작성할 때 생성되는 데이터 저장소는 비록 테이블처럼 표현되지만 사실은 특정 데이터를 저장해야 한다는 데이터의 추상화된 집합이지 엔터티가 되는 것은 아니다. 예를 들어, 자재 구매 기능에서 자재 정보 자료 저장소로 정보가 저장되고 여기에는 자재 코드+자재명+규격+구매 수량+... 등의 자료 사전이 생성되지만 실제 모델링을 해보면 자재, 자재 유형, 단가정보 등의 많은 엔터티가 나타나게 된다.


타 시스템 자료

타 시스템이 가지고 있는 엔터티를 면밀히 조사하고 이것들이 우리가 가져가야 할 집합과 어떻게 다른지를 밝히고 앞으로는 어떻게 정의해야 할 것인지를 조사한다. 엔터티 후보를 손쉽게 찾을 수 있는 또 하나의 방법은 관계사나 유사 업종의 시스템 도큐먼트를 입수해서 참조하는 것이다.


현장 조사

본격적인 모델링을 하기 전에 현장을 답사하는 것이 좋다. 그렇게 해야 모델러와 개발 종사자들 간에 공통적인 의사소통 수단(Communication Protocol)이 좀 더 쉽게 만들어진다. 그렇지 못하면 설계 시에는 서로를 충분히 이해한 것 같은데, 나중에 가서 보면 무엇인가 앞뒤가 맞지 않는 일이 자주 발생한다. 이것은 결국 동일한 사실에 대해서 서로가 동상이몽을 하고 있었다는 것을 의미한다.


엔터티 후보 식별

다양한 경로를 통해 엔터티 후보를 수집하는 과정에서 가장 중요한 것은 엔터티 후보를 어떻게 식별할 것인가에 대한 문제이다. 이러한 판단을 위해서는 무엇보다도 누구나 인정할 수 있는 구체적이고 객관적인 잣대가 있어야 한다. 엔터티 후보의 식별은 다음의 세 가지 단계에 대한 검증을 통해 객관화할 수 있다.


  • 후보 엔터티의 개념 정립을 명확히 한다.
  • 우리가 관리하고자 하는 것인지를 따져 본다.
  • 가로와 세로를 가진 면적(집합)인지를 확인한다.
엔터티 후보의 개념 정립

엔터티 후보로 검토해 볼 대상의 최초 상태는 한낱 단어에 불과하다. 단어란 단지 사전적 의미에 지나지 않으므로 우리는 이 단어가 의미하는 진정한 집합이 무엇인지를 정의해야 한다. 예를 들어 사원이란 단어의 사전적 의미는 회사에 근무하는 사람 혹은 사단법인을 구성하는 사람이라고 되어 있다. 그러나 우리가 검토할 사원은 우리 회사에 근무하거나 촉탁(임시) 사원, 관계사, 협력사 등에서 지원받은 사원들을 포함한 집합이 될 수도 있다. 우리는 반드시 이와 같은 구체적 집합을 정의한 다음에야 비로소 다음 단계에 대한 검토를 진행할 수 있다. 그것은 애매모호한 대상을 놓고 구체적인판단을 하고자 노력하는 것은 도로(徒勞)에 지나지 않기 때문이다.


관리 대상 판정

엔터티 후보로 선정하기 위해 개념을 정립해 둔 단어에 대해 우리가 검토해야 할 첫 번째 작업은 과연 이것이 우리가 관리하고자 하는 대상이 맞는지를 확인하는 일이다. 이 말은 앞으로 우리가 모델링을 하면서 던지는 모든 질문에 반드시 기본적으로 포함되어야 하는 주어부(主語部)에 해당하는 구문이다. 이 문장이 있음으로 인해서 모델링을 할 대상 업무에 따라 모델링의 결과가 달라지는 원인이된다.


  • 사람이라는 논리적인 집합은 구멍가게 업무를 모델링을 하느냐 혹은 행정 전산망에 대한 모델링을 하느냐에 따라 관리하고자 하는 집합이 달라지므로 데이터 모델의 모습도 달라질 수 있다.
  • 현재 관리하고 있느냐 뿐만 아니라 앞으로는 관리해야 하지 않느냐를 모두 포함하고 있다. 사실 현재 관리되고 있다는 것을 확인하는 것도 쉽지 않겠지만, 앞으로 관리할 것인지를 결정하는 것은 매우 전략적인 판단이 필요하다.
집합 여부 확인

엔터티는 집합이어야 하지만 모든 집합이 모두 엔터티가 되는 것은 아니다. 여기서는 엔터티를 결정하는 것이 아니라 엔터티 후보를 선정하려는 것이므로 검토하고자 하는 대상이 집합이 되는지 여부만 확인한다.

[그림 4-2-3] 집합 여부 확인 예

집합이란 다른 측면에서는 면적이라고 할 수도 있다. 면적이 되려면 가로 선분과 세로 선분이 있어야 한다. 선분이란 서로 다른 독립적인 두개 이상의 점(點)이 있어야 한다. 여기서 점이란 속성을 의미한다. 만약 우리가 검토할 대상이 하나의 점만 있다면 선분이 되지 못하므로 비록 세로가 선분이되더라도 수직선 밖에 될 수 없다. 마찬가지로 세로가 하나의 점이라면 최대 수평선 밖에 될 수 없기 때문에 이런 경우는 면적(집합)이 되지 못하므로 엔터티가 될 수 없다.


엔터티 후보 선정시 유의사항

엔터티 후보의 선택은 데이터 모델링의 시작 부분이다. 엔터티 후보를 선정하는 동안에 아래와 같은 몇 가지의 유의사항을 염두에 두어야 한다.


엔터티 가능성이 있다고 예상되면 일단 검토 대상에 올려라

엔터티 후보라고 해서 모두가 최종적으로 엔터티가 되는 것은 당연히 아니다. 그 대신 후보란 다른 후보들과 비교됨으로써 결정되는 것이므로 이런 후보들을 충분히 수집한 후 언젠가는 후보들을 하나씩 비교하면서 검토하게 된다. 버리게 되더라도 이 때 버리면 되므로 일단 모든 가능성 있는 대상을 최대한 수집한다는 생각을 가지고 접근하는 것이 좋다.


너무 깊게 들어가지 마라

후보의 자격이 있다/없다 정도만 판단한다. 물론 필요에 따라 좀더 깊은 곳에 있는 내용을 통해 현재 결정하고자 하는 것에 대한 확신이 필요하다면 얼마간은 더 깊이 들어가 볼 수는 있다. 그러나 엔터티 후보를 선정하는 단계에서 절대로 너무 깊이 들어가서는 안 된다


동의어처럼 보이더라도 함부로 버리지마라

특정 단어의 경우에는 의미를 일반적인 의미와는 다르게 사용하는 경우가 많다. 마치 새로운 언어가 생겨나는 것과 유사하게 누가 사용하기 시작했는지는 모르지만 언젠가부터 그렇게 알고 사용하기 시작하면서 의미가 그대로 굳어 버린다. 예를 들어 어떤 회사에는 상품과 제품이 있는데 일반적으로는 동일한 의미로 사용하지만 이 회사는 다른 의미로 사용하고 있었다. 이와 같이 동일한 의미로 여겨지지만 실제 정의된 집합은 같지 않을 수가 있고, 비슷하기는 하지만 정확하게 일치하지 않는 경우도 종종 발견된다. 그러므로 동의어처럼 보인다고 함부로 버릴 게 아니라 일단 후보로 도출하는 것이 중요하다. 데이터 모델링의 뒷부분에서 이러한 부분들을 가지고 다른 어떤 집합과 중복된 것인지, 완전히 포함되는 부분집합을 말하는 것인지, 아니면 일부가 서로 겹쳐져 있는 형태인지를 정확하게 규명하게 된다.


개념이 모호한 대상은 일차로 그 개념을 상식화하여 이해하라

어려운 전문 용어나 특화된 업무에 대해서는 일반적이고 상식적인 예를 들어서 엔터티의 개념만을 파악한다. 이 단계에서 해당 업무 또는 데이터에 대해 정확한 개념을 파악하는 것은 무리가 따르기 마련이다.


프로세스에 너무 연연해 하지마라

지금까지 우리는 모든 업무를 프로세스 중심으로 이해했기 때문에 프로세스 중심으로 설명을 듣지 않으면 이해하기가 매우 어렵다. 그러나 데이터 모델에는 프로세스가 없다. 흐름도 없고, 시간도 없다. 이것이 우리를 참으로 어렵게 만든다. 모델링을 하면서 자꾸 업무의 흐름에 집착하면 데이터흐름도처럼 데이터 모델이 업무를 따라 흘러가는 이상한 현상이 발생한다. 물론 데이터 모델링에서도 업무의 흐름을 완전히 배제하지는 않는다. 다만 그것은 현재 목적한 데이터 모델링의 어떤 결정을 좀더 완벽하게 하기 위해서 프로세스를 파악해 보는 것일 뿐이다.


예외 경우에 너무 집착하지마라

예외 처리에 집착하지 말라는 뜻은 예외 처리가 중요하지 않다는 의미가 아니다. 지금 엔터티 후보를 수집하고 선정하는 단계에서는 가볍게 넘어가라는 것이다. 나중에 엔터티의 내부 구성 집합(Subtype)이나 릴레이션십을 정의하는 단계에서 이러한 예외 경우를 분석하여 설계에 반영하게된다.


단어 하나하나에 집중해서 판단해라

누구나 알고 있는 것처럼 보이는 단어에 대해서도 좀더 깊이 구체적인 집합을 생각해야 한다. 예를들어 누구나 사원이 어떤 집합인지는 확실히 알고 있다고 생각한다. 그러나 좀더 깊이 들어가서 외부 용역사원이나 협력사 직원도 우리 사원 집합에 들어오는지를 물어보면 대답을 못한다. 왜냐하면 이렇게 구체적으로 사원이라는 집합에 대해서 정의한 적이 없기 때문이다. 매우 상식적이고 일반적인 용어로 정의된 엔터티 후보라도 사실은 매우 개략적이고 모호하게 정의되어 있는 경우가많다.


수집된 엔터티 분류

개념 데이터 모델링에서는 일단 데이터 모델의 골격을 잡는 일부터 철저하게 수행해야 한다. 이렇게 하기 위해서는 엔터티 후보를 분류하는 작업부터 수행해야 한다. 분류 작업의 궁극적인 목적은 골격에 해당하는 엔터티만을 따로 분류해서 거기에 노력을 집중함으로써 나무만 보고 숲을 보지 못하는 오류를 범하지 않도록 하기 위한 것이다. 엔터티 후보를 분류하는 작업은 다음 두 단계에 걸쳐 진행된다. 첫 번째 단계는 우선적용 대상을 분류하는 것이고, 두 번째 단계는 첫 번째 단계에서 선별한 핵심 엔터티를 데이터 영역별로 분류하는 것이다.


우선적용 대상 분류

엔터티 후보를 우선적용 대상별로 분류하는 목적은 모델링의 골격에 해당하는 주요 엔터티를 먼저 도출하여 이를 명확히 정의함으로써 모델링의 기초를 단단하게 하는 것이다. 이를 바탕으로 흔들림없이 상세한 모델링을 진행해 갈 수 있게 된다. 모델링을 순차적으로 접근해 가야 할 형태별로 분류한다면 크게 세 가지로 나눌 수 있다.

첫 번째는 사람, 상품, 자재 등과 같이 행위를 발생시키는 주체나 목적어가 되는 엔터티(여기서는 키 엔터티라 부르기로 한다)이다. 두 번째는 키 엔터티가 행위를 함으로써 발생되는 행위의 집합 중에서 좀더 하위의 행위를 발생시키는 주체나 목적어가 될 수 있는 엔터티(여기서는 메인 엔터티라 부르기로 한다)이다. 그리고 나머지 엔터티(여기서는 액션 엔터티라 부르기로 한다)를 세 번째로 분류한다.


1) 키 엔터티(Key Entity)

자신의 부모를 가지지 않는 엔터티를 말한다. 여기서 부모 엔터티란 자신을 태어나게 한 - 만약 이 엔터티가 없다면 논리적으로 자신이 태어날 수 없는 - 엔터티를 말한다. 태초부터 창조된 집합이란 다른 엔터티의 도움을 받지 않더라도 얼마든지 어떤 개체를 새롭게 정의할 수 있는 집합을 말한다. 예를 들어, 사원 엔터티에 있는 홍길동이란 개체는 아직 부서가 정해지지 않았더라도 사원으로서 정의하는 데 문제가 없다. 물론 부서 엔터티와 관계를 정의할 때 반드시 부서를 갖도록 하는 규칙을 부여할 수도 있겠지만 그렇다고 해서 부서가 직접적으로 사원을 태어나게 한 부모인 것은 결코 아니다. 다시 말해 사원은 부서 없이도 태어날 수 있지만 부서가 결정되지 않으면 결코 탄생시키지 않겠다는 규칙을 부여할 수는 있다. 키 엔터티를 구별할 때 이러한 규칙과 부모의 차이를 혼동하는 경우가 자주 나타나고 있으므로 여기서 정확히 개념을 정립해야 한다. 키 엔터티의 예로는 다음과 같은 엔터티가 있을 수 있다.


  • 사원
  • 부서
  • 고객
  • 상품
  • 자재
2)메인 엔터티(Main Entity)

키 엔터티를 제외한 다른 모든 엔터티는 부모 엔터티를 가지고 있어야만 태어날 수 있다. 이러한 엔터티는 업무의 크기에 따라 엔터티 간 계층의 깊이가 달라진다. 여기서 키 엔터티를 제외한 엔터티 중에서 업무의 중심에 해당하는 엔터티를 메인 엔터티라 정의하고, 나머지를 액션 엔터티로 정의한다. 이렇게 정의하는 것은 전체를 단계적으로 파악하고자 하는 의도가 있다. 메인 엔터티의 예로는 다음과 같은 엔터티가 있다.


  • 보험계약, 사고, 예금원장, 청구 …
  • 구매의뢰, 출하지시, 공사 …
  • 주문, 예산편성, 매출 …
3)액션 엔터티(Action Entity)

매출, 출고, 입금과 같은 엔터티는 눈에 잘 보이지만 이들을 태어나게 한 고객, 공정, 창고 등은 엔터티로서는 눈에 잘 보이지 않는다. 키 엔터티에 해당하는 것들은 다만 우리 눈에는 코드 정도로 보일 뿐이고 실제 모델링에서도 이러한 부모들이 나중에 나타나는 경우가 많다. 액션 엔터티는 수행된 업무를 담고 있으므로 중요도를 가지고 따진다면 물론 가장 중요하다고 할 수 있다. 그러나 이들은 스스로는 결코 태어날 수 없는 - 반드시 부모를 가져야만 하는 - 자손들이다. 이들을 제대로 정의하기 위해서는 낳을 부모들부터 먼저 정확하게 정의하는 것이 일의 당연한 순서일 것이다.

액션 엔터티를 구별하는 방법은 매우 쉽다. 키 엔터티와 메인 엔터티가 아닌 것은 모두 액션 엔터티이기 때문이다. 앞으로 모델링이 좀더 구체적으로 진행되더라도 키 엔터티와 메인 엔터티는 집합의 본질이 크게 달라지지 않는다. 그러나 액션 엔터티는 상위 엔터티들이 어떻게 결정되느냐에 따라서 크게 영향을 받기 때문에 업무의 본질은 살아 있지만 최초에 예상했거나 과거에 정의했던 의미상의 주어가 크게 달라질 수도 있다. 액션 엔터티의 예로는 다음과 같은 엔터티가 있다


  • 상태 이력, 차량 수리 내역, 상세 주문 내역,···
우선적용 대상 분류 사례

[그림 5-2-3]에서 예시된 엔터티 후보를 접근 형태별로 분류해 보기로 하자. 검토 대상은 가능한 무순으로 하고 간단한 설명만 하도록 하겠다.

[그림 4-2-4] 우선 적용 대상 분류 예

위의 후보 대상 중에서 키 엔터티에 해당하는 몇 가지만 분류해 보면 다음과 같다.


고객

고객은 상식선에서 생각하더라도 당연히 개체 집합이므로 키 엔터티로 분류해야 한다. 문제는 어떤 구체적인 집합을 고객으로 할 것이냐를 결정하는 것이 중요하다. 가령 개인과 법인을 모두 고객이라고 할 것인지, 현재 우리와 직접 관계를 가진 것만이 고객인지, 아니면 잠재고객까지 포함한 것을 고객이라 할 것인지에 대한 결정을 하는 것이 중요하다.


법인

법인 또한 당연히 개체 집합이라는 것은 굳이 설명할 필요도 없다. 강의를 하다보면 가끔 법인을 메인 엔터티라고 생각하는 사람도 있다. 그 이유를 물어보면 고객의 자식이 아니냐고 반문한다. 이것은 착각이다. 법인은 고객의 부분집합이지 자식은 아니다. 부분집합과 자식은 절대로 같은 개념이 아니다. 만약 사원 엔터티를 남자, 여자로 구분했다면, ‘남자는 사원의 아들인가’ 그렇다면 ‘여 자가 사원의 자식인가’ 나중에 엔터티 확정 단계에 가면 집합의 독립성과 동질성에 대한 평가를 하게 되는데 여러 가지 결론이 나올 수 있다. 즉, 고객 집합에 법인 집합이 포함된다면 이는 독립성에 저촉을 받는 것이므로 법인은 엔터티가 아니라 고객의 서브타입에 불과하다. 만약 개체의 일부만 고객에 포함된다면 고객 집합의 동질성을 확장하여 법인 집합 모두를 포함시킬 것인지, 아니면 어떤 특별한 목적이 있다면 중복이 있더라도 별도의 개체 집합으로 할 것인지 등의 결정에 따라 판단은 달라진다.


금융기관

이것은 법인의 한 부분 집합일 수 있으므로 당연히 키 엔터티로 보아야 한다. 이 또한 고객과 법인과의 관계에서 고려했던 문제처럼 법인과 금융기관 관계에서도 동일한 고민이 발생한다. 즉, 금융기관을 법인의 서브타입으로 보아야 할 것인지, 독립적인 집합으로 보아야 할 것인지를 검토하면서 유사해 보이는 두 집합의 개념을 좀 더 정확하게 정의를 해야 한다는 것이다. 얼핏 생각하면 금 융기관은 당연히 법인의 일부분처럼 보인다. 그러나 집합을 좀 더 명확히 해보면 미묘한 차이가 있을 수도 있다. 가령, 법인 엔터티는 국가가 인정한 공식 법인이 있다면 그것이 하나의 단위 개체가 되는 집합이라고 정의했다고 가정하자. 그렇지만 금융기관 엔터티는 금융기관의 본·지점이 하나의 개체가 되는 집합이라고 했다면 이들은 성격이 다른 집합이 될 것이다.


수납기관

단어의 구성을 보면 금융기관과 유사해 보이지만 결론은 정반대이다. 수납기관은 엔터티가 아니다. 물론 다른 엔터티와 개체의 중복이 발생하더라도 수납을 받을 수 있는 모든 개체들을 모아두고이를 수납기관이라고 정의한다면 안 될 것도 없지만 개체 본연의 본질이 많이 희석되는 일이 발생한다. 예를 들어 행정기관인 세무서에서 세금을 수납 받는다면 이것을 수납기관의 개체로 두어야 하겠는가? 만약 법이 바뀌어 수납을 받지 않는다면 이 집합에서 다시 빼내어야 하는가? 또 수납의 반대 개념인 지급도 발생할 것이므로 그렇다면 지급기관 엔터티도 만들어야 하고 여기에도 이 개체가 존재해야 하지 않겠는가? 수납기관이란 말에는 기관이란 개체 본질과 수납이라는 행위 본질이 같이 들어 있는-다시 말해서 두 개의 집합을 연결한-모습이므로 이것은 엔터티가 아니라 릴레이션십이 되는 것이다.


거래자

거래자는 엔터티가 아니다. 엔터티는 순수한 개체 본질이 되거나 행위 본질이 되어야 하는데 거래자는 거래라는 행위 본질과 자라는 개체 본질이 혼합되어 있으므로 엔터티가 아니라 관계이다. 다시 말해서 개체 집합인 자(고객)와 거래내역이라는 행위 집합의 관계 명칭이 바로 거래자인 것이다. 이러한 집합에 대해 얼핏 생각하면 엔터티 정의에서 검토했던 우리가 관리하고자 하는 집합이며, 2개 이상의 속성과 2개 이상의 개체를 가져야 한다는 조건을 모두 만족하고 있으므로 엔터티로 오해하는 경우가 많은데 절대 그렇지 않다.


데이터 영역별 분류

이 골격에 해당하는 엔터티들을 명확하게 정의해야 한다. 상위 엔터티가 단단하게 고정되지 않고서는 사상누각이 될 수밖에 없기 때문에 앞으로 좀 더 상세한 모델링이 진행되더라도 굳건하게 견딜 수 있도록 견고하게 정의를 해야 한다. 앞서 도출했던 골격 엔터티들의 의미를 정밀하게 비교하여 구체화시키기 위해서는 유사한 의미를 가진 엔터티를 서로 모아 함께 비교하는 것이 필요하다. 뚜렷한 차이를 가지는 것들 간이라면 대충만 비교해도 그 차이가 분명하게 나타나지만 미묘한 차이를 가지고 있는 것들은 곁에 놓고 같이 비교해 보지 않으면 쉽게 그 차이를 알아낼 수 없다. 데이터 영역을 정의하는 방법은 접근 방법별로 볼 때 크게 하향식(Top-Down)과 상향식(Bottom-Up) 접근 방법으로 나누어 볼 수 있다. 또한 그 구성에 따라 세상의 모든 집합을 크게 나누어 행위의 주체나 목적물이 되는 개체들이 모인 집합과 그들의 활동으로 얻어지는 행위??, 지역, 시설, 재료 등은 행위의 주체로서 개체 집합의 예가 될 수 있고, 계약, 주문, 청구, 매출, 수납 등은 기업의 업무를 크게 분류한 것으로서 행위 형태의 데이터 영역으로 분류될 수 있다. 실제 업무에서 자주 발생하는 엔터티의 일부를 몇 가지 데이터 영역별로 분류해보면 [표 4-2-1]과 같다.

[표 4-2-1] 엔터티 영역별 분류 정의서 예


모델 대 상 엔 터 티 후 보
사람 사원, 가입자, 회원, 고객, 학생, 교사, 환자, 협력사 직원 …
물건 부품, 원재료, 연료, 저장품, 상품, 건물, 운송센터 …
사건
관리자
계약, 수주, 주문, 발주, 재해, 고장, 사건, 신고, 입고, 출고 …
장소 창고, 생산라인, 행정구역, 하천, 선거구, 공항, 항만, 공정 …
개념 판매목표, 생산계획, 평가기준, 할인기준, 배부기준, 공법 …
금전 입급, 청구, 차입금, 예적금, 연간예산, 융자, 사내대출 …
조직 부서, 판매망, 채널, 거래처, 법인조직, 교대조, 대리점 …