1 접근 방법

2 추상화(Abstraction) 기법

3 개체집합의 선정 방법

4 개체집합의 후보 수집

5 관점에 따른 추상화 레벨의 차이

6 개체집합 후보 선정 연습1

7 개체집합 후보 선정 연습2

8 개체집합의 분류

9 Key Entity Set

10 Main Entity Set

11 Action Entity Set

12 모델관점에서의 분류

13 개체집합의 명칭 부여

14 개체집합의 자격 검증

15 Key Entity Set의 통합

16 Bottom-Up 방식으로 개체집합 선정

개체집합을 도출하는 접근 방법은 여러 가지가 있을 수 있다. 여기에서는 전통적인 방법을 살펴보고, 그에 따른 절충안을 내놓을 것이다. 다음 그림을 보자.

• Top-Down은 미래/목표 지향적
  
• Top-Down은 점진적 세부화
  
• Top-Down은 구체적인 내용을 이끌어내기 힘들다.
  
• Bottom-Up은 점진적/세부적
  
• Bottom-Up은 반드시 구 시스템이 존재 해야 가능 (대부분 조직은 구 시스템이 존재하므로 사용 가능)
  
  

상향식(Bottom-up)방식과 하향식(Top-Down) 방식 중 어떤 방법을 사용해서 접근할 것인가를 따져보아야 한다. Top-Down 방식은 만족할 만한 개념적 설계가 완성될 때까지 그 모델에 세부사항을 추가하는 방식이고, Bottom-Up 방식은 세부적인 요구사항을 분석하고 각 사용자 뷰를 개별적으로 모델링하는 방식이다.
쉽게 접근할 수 있는 방법은 업무의 중심이 되는 개체집합과 해당 조직에서 없어서는 안 되는 개체집합을 도출하는 것이다. 이러한 개체집합은 실제 사용자들에게는 잘 보이지 않는다. 사용자들이 보는 주된 뷰는 이러한 개체집합들(키 개체집합, 중심 개체집합)에서 파생된 것이기 때문이다. 그러므로 모델러는 조직에서 사용되는 데이터의 틀을 잡아야 한다. 그리고는 그 틀에 살들을 붙이는 것이 수월하다. 그러므로 추천하는 접근방법은 상향식과 하향식의 복합적인 형태이다. 즉, 지도를 그린 후 세부적인 것은 우리가 모델링한 지도를 가지고 다니면서 세부적인 것을 추가하자는 것이다.
중요한 딜레마는 어떤 시점에서 하향식 설계를 마치고, 상향식 설계로 넘어가느냐의 문제이다. 이것은 전적으로 모델러의 판단에 달려있다. 그러나 그 판단에 대한 두려움을 가질 필요가 없다. 분명히 상향식 설계를 할 때 누락된 개체집합을 도출 될 것이기 때문이다. 상향식 설계는 아래에서 설명할 추상화 기법과 정규화를 이용하면 된다.

이론적으로는 추상화(Abstraction)이라는 것이 있다. 사실 개체집합의 정의만으로도 그 의미를 알고 있다면 충분하지만 또한 “관점”이라는 변수가 있기 때문에 추상화 기법을 데이터 모델링의 원칙으로 하고 있다. 추상화란 객체들의 집합 중에서 필요한 특성들은 선택하고, 불필요한 특성들은 버리는 과정으로 여기서는 핵심적인 것만 판단한다.
우리가 사람을 판단할 때 “직립보행을 하고, 얼굴과 팔, 다리, 몸통이 달리고, 얼굴에는 눈, 코, 귀, 입이 달리고 손에는 손가락이 5개 붙어 있고..”와 같은 식으로 판단하지 않는다. 다음 그림에서 보는 바와 같이 불필요한 객체들간의 차이점(사람과 사람을 구분하는 것, 주민번호, 이름, 피부색 등..)을 무시한 하나의 관점에서 개념이다. 추상화의 기법도 분류화(Classification), 집단화(Aggregation), 일반화(Generalization) 이렇게 3가지가 있다. 각각을 살펴보도록 하자. 참고로 여기서 ‘클래스’라는 용어는 앞에서 살펴본 개체집합과 동일한 의미를 가지고 있다.

분류화(Classification)
분류화는 공통의 성질에 의해서 특징지어진 집합을 의미한다. 이것은 나중에 배울 속성의 개념과 같을 수 있다. 즉, 정보통신공학과, 국어국문학과... 이러한 것들은 ‘학과명’이 될 수 있는 것이다. 그러나 이러한 학과명을 갖는 여러 개의 개체들이 모이면 그림에서와 같이 ‘학과’라는 하나의 개체집합이 탄생하는 것이다.

집단화(Aggregation)
집단화는 부분집합이 모여서 하나의 개념의 집합이 되는 것을 말한다. 즉, 하나의 부분집합은 하나의 요소가 된다. 다음 그림에서와 같이 여러 개의 요소(자동차 부품들)가 모여서 하나의 자동차라는 개념이 탄생하는 것이다.

일반화(Generalization)
앞에서 살펴본 그림의 “자동차” 와 “학과” 는 하나의 클래스로 볼 수 있다. 클래스란 객체들의 공통의 성질로 모여있는 것을 의미한다. 일반화는 두 개 이상의 클래스들의 원소들의 사이의 부분 집합 관계를 정의하는 것이다.

전통적으로 구조적 설계나 OOP 방법론이나 “분할 후 정복”의 중요성을 강조하지 않는 방법론은 없다. 즉, 해당 문제를 놓고 단계적으로 나누어 해당 문제의 답을 도출하기 위해서 접근한다. 결과를 도출하기 위해서 문제를 쪼개는 것은 복잡성에 빠지지 않고, 단순하게 접근하기 위함이다. 중요한 것은 해당 단계를 충실히 수행하는 것이다. 아래의 그림처럼 하나의 단계라도 삼각형을 만들지 못하면 전체의 큰 삼각형이 만들어질 수 없듯이 각 단계를 충실히 수행해야 하는 것이다.

만약 구 시스템이 있다면 Key Entity는 Top-Down 방식으로 Action Entity는 Bottom-Up 방식 사용한다. 필요하다면 해당 전문 서적을 참고한다. (참고만 한다.) 아무리 일반적인 개념이라도 해당 조직에서는 개념이 틀려질 수 있으므로 간과하면 안 된다. 많은 경우 내가 수집한 개체집합의 후보가 의심이 된다면 Instance Diagram을 그려 보는 것은 아주 좋은 방법이다. 모델러 자신과 사용자들은 실제 데이터를 표 형태로 보면 거의 맞음과 틀림을 알 수 있다.

후보 수집에서 많은 경우 “명사”를 찾으라고 언급되어 있다. 왜 꼭 “명사”일까? 그 해답은 “명사”의 정의에서 찾아볼 수 있다.

“명사(名辭)” 에 대하여… ( 출처 : 두산세계대백과 )

아리스토텔레스는 《형이상학》에서 ‘horos(사물의 끝 •경계)’를 삼단논법과 비례식의 유추(類推)로부터 사물의 본질을 깊이 규정하고 그 능력 •성질을 한정하는 울타리라는 뜻으로 사용하였다. 이것이 보에티우스에 의해서 ‘terminus’로 번역되어 전통논리학에서는 범주적 명제(範疇的命題)의 주어 •술어를 가리키게 되었다. 그러나 주어나 술어는 필연적으로 언어표현을 하기 때문에 차차 이름(name)이나 단어(word), 특히 명사(名詞: noun)와 구별이 없어져 마침내는 결합사적(結合詞的)인 단어(and, if 등)까지를 가리키게 되었다. 그 한 가지 예가 삼단논법의 대개념 •중개념 •소개념이 대명사(大名辭) •중명사 •소명사라고 불리게 된 것이다. 새벽의 명성(明星)과 초저녁의 명성이 같은 금성을 가리키는 것으로도 알 수 있듯이 개념의 뜻은 외연(外延)과 내포(內包)를 가지고 있고, 더욱이 이것들이 언어적 기호로 표시되므로 개념과 기호는 구별해야 한다.

개체집합의 분류작업은 모델 관점의 분류 방법과 탄생 시점에 의한 분류 방법이 있다. 대부분 모델 관점의 분류 방법보다는 탄생 시점에 의한 분류 방법을 많이 사용한다. 그러나 이 두 가지 분류 방법을 모두 사용하여 상호 보완을 하는 것도 매우 좋다. 모델 관점의 분류 방법은 매우 쉽지만 탄생 시점에 의한 분류 방법은 만만치 않다. 역시 분류가 어려운 이유는 “애매모호한 정의” 때문이다. 정의만 잘 한다면 탄생 시점에 의한 분류도 매우 쉬워진다.
분류된 개체집합의 후보를 놓고 자격검증을 한다. 모든 단계가 중요하지만 이 단계에서 거의 최종적인 개체집합이 가려지므로 하나하나에 집중하여 자격을 검증해야 한다. 검증이 끝난 뒤에는 모델의 통합작업이 이루어져야 한다. 앞서 설명한 접근 방법처럼 이 단계에서는 조직의 업무에 실제 사용되는 데이터의 소스격인 개체집합들이므로 매우 중요하다. 그러므로 최대한 통합하여 단순화하여야 한다. 모델은 사용자와 모든 프로젝트 관계자들의 의사소통의 도구라는 이유도 단순성은 확보되어야 한다. 가장 중요한 이유는 상향식 접근으로 도출할 실제 업무에 쓰이는 데이터 집합이 복잡해지지 않게 하기 위함이다. 물론 성능과 무결성과 단순성을 모두 보장해야 한다.

개체집합의 후보를 선정하기 위해서는 자료를 수집해야 한다. 업무에 쓰이는 각종 문서들을 모두 포함하여, 기존의 시스템과 조직의 목표, 사용자와의 인터뷰 등의 노력이 필요하다. 개체집합을 도출하는데 기존의 시스템의 역할이 매우 크다. 그렇다고 기존의 시스템을 그대로 베껴오라는 것이 아니다. 설계를 하다 보면 기존의 시스템의 스키마를 그대로 가져다가 쓰는 경우가 많이 있는데, 이러한 것은 철저한 검증이 이루어져야 한다. 대부분의 시스템은 설계가 그리 좋지 못하다. 그러므로 개체집합의 후보를 수집하는 소스로만 사용해야 한다.
모든 업무는 문서로 남는다. 기존의 시스템에서 쓰이는 화면이 하나의 문서가 될 수 있고, 엑셀이나 워드 등의 오피스도구에 의해 만들어진 전자문서로 남는다. 물론 이 문서도 역시 개체집합을 표현하고 있는 것은 아니며, 실제 개체집합은 잘 보이지 않는다. 이것을 찾아내는 작업이 이 단계의 목적이다.
먼저 후보 수집의 대상(장표, 보고서, 인터뷰 등)을 통해서 개체집합 후보를 수집(명사를 구분)한다. 많은 서적에서 명사를 구분하라고 되어 있지만 필자가 보기에는 이러한 방법은 초보적인 방법이다. 꼭 명사를 모두 정리할 필요는 없으며, 개체집합의 느낌이 있는 것을 골라 사용자에게 개념을 확인한다. 명심해야 할 것은 이 단계는 “후보수집”이라는 것이다. 후보다라고 판단되거나 후보인지 아닌지 구분이 어렵다면 일단 개체집합의 후보로 놓는다. 확실히 개체집합이라고 판단하는 단계가 있으므로 걱정하지 않아도 된다.
두 번째로 개념이 애매모호한 것, 구축할 시스템 범위와 비슷한 의미의 명사를 제외시킨다. 예를 들어 “그것”이라든지 “사람” 과 같은 경우이다. “사람”의 경우 논란의 소지가 있는데, 이것은 조직의 업무를 보고 판단해야 한다. 대부분의 조직은 “사람” 개체집합은 너무 추상화 레벨이 높기 때문에 의미가 없을 수도 있다.
세 번째로 개체집합의 특성을 나타내는 명사를 제외시킨다. 예를 들어 제조일, 고객ID, 패스워드와 같은 경우는 각 개체의 특성이므로 제외시킨다. 중요한 것은 속성인지 개체인지 판단하는 것이다. 또한 프로세스에 대한 명사나 동음어와 같은 경우를 제외시킨다. 물론 명사를 모두 끄집어 내어 제외시키라는 것은 아니고, 모델러의 머리 속에서 제외시키라는 것이다. 마지막으로 업무에 필요한 개체집합이 누락된 것이 없는 살펴본다.
중요한 것은 개체집합의 정의를 잘 이용해야 한다는 것이다. 명사를 언급한 이유도 명사의 뜻이 개체집합의 개념에 포함되기 때문이다. 그러므로 개체집합의 정의에서 각각의 판단하여 Ture인지 False인지만 표시하면 된다. 다음의 표를 사용하면 편리하다.

후보기준	업무상 관리의 대상	가로 * 세로	영속성	식별자
고객	∨	∨	∨	∨
사원	∨	∨	∨	∨

위의 표를 이용하여 다음과 사항을 주의하면서 개체집합을 도출하면 된다.

• 현 단계의 목표를 사용자들에게 확실히 인식시키고 복잡성을 배제한다. (후보수집단계)
  
• 위의 표를 이용하여 개체집합의 후보인지만 판단
  
• 동의어는 더욱 신중하게 판단해야 한다. (같은 개념이 아닌 경우도 많음)
  
• 핵심적인 개념을 파악하여 기록해둔다.
  
• 후보인지 아닌지 판단이 서지 않는다면 후보로 선정하여 자격 유무를 판단할 때 걸러낸다.
  
• 데이터베이스의 현재 시점을 나타내지만 미래까지 고려하여 변경에 대한 대처를 한다.
  
• 프로세스에 현혹되어 데이터 모델에 프로세스를 포함시키지 않도록 한다.
  
• 순수한 개체집합인지를 파악해야 한다. (개념, 행위, 물건, 장소.. 복합적인 개념은 안 된다.)
  
• 개념이 흐려지지 않도록 적당한 추상화 레벨의 관점이 필요
  
  

후보를 수집할 때 주의해야 할 것은 해당 개체집합이 개체집합의 개념의 범위에만 속하는지 알아야 한다. 많은 경우 장표나 기존 시스템의 폼을 보면 관계의 표현이 섞여져 있는 경우가 많이 있다. 그런 경우를 잘 구분한다면 개체집합의 후보를 선정하는 것은 매우 쉬울 것이다.
위에서 핵심개념을 파악하라고 하였다. 필자는 사전을 매우 잘 이용한다. 사전을 통하여 일반적인 대략의 개념을 파악한 후 사용자에게서 해당 조직에 해당되는 개념을 끌어낸다. 핵심개념을 파악하는 일은 매우 중요한 일이다.

추상화 레벨에 대한 이야기는 몇 번을 언급했었다. 추상화 레벨을 계속 이야기 하는 것은 모델러와 각 사용자가 같은 관점에서 데이터를 바라보아야 하기 때문이다. 각각의 사용자는 일반 사원이 될 수도 있고, 임원이 될 수도 있다. 사원이 보는 관점과 사장이 보는 관점은 많이 틀릴 것이다. 데이터베이스는 모든 사용자의 관점을 나타낼 수 있어야 하므로 사용자의 요구사항을 모델에 반영하기 위해서 적절한 추상화 레벨에서 멈춰야 한다.

다음은 추상화 레벨의 결정에서 주의해야 할 사항이다.

• 어떤 관점에서 바라볼 것인가?
  
• 어느 레벨까지가 최적인가?
  
• 추상화 레벨이 높아질수록 유연성을 좋아짐
  
• 추상화 레벨이 낮아질수록 구체화됨
  
• 후보가 선정되었다면 상식적으로 비슷한 것끼리 분류한다.(사람, 장소..)
  
  

다음의 글을 보고 개체집합의 후보를 선정하라.

우리 회사에서 프로젝트 배정 현황에 관한 데이터베이스를 구축하고자 한다. 각 사원은 하나 또는 그 이상의 프로젝트에 배정될 수 있으며, 프로젝트가 없는 사원도 있을 수 있다. 그러나 각 프로젝트에는 반드시 한 명 이상의 사원이 배정되어야 한다. 어떤 프로젝트는 우리 회사에서 근로하는 근로자와 계약을 한 근로자가 배정될 수 있으며, 거래처로 외주를 줄 수도 있다. 사원은 이름, 호봉, 특기, 생년월일을 속성으로 가지며, 프로젝트는 프로젝트 번호, 프로젝트 내역, 시작일, 예상 완료일을 속성으로 갖는다. 단, 직원은 하나 이상의 특기를 보유할 수 있다.

다음의 장표를 보고 개체집합의 후보를 선정하라.

이 장표의 경우는 초보자에게는 매우 어려울 수도 있다. 이제까지 개체집합만을 언급하였었는데 관계 및 개체, 속성이 아닌 값들이 표현되어 있기 때문이다. 또한 모델을 만든 사람마다 매우 상이한 결과를 가져올 수도 있다. 왜냐하면 정의가 되지 않았기 때문이다. 필자는 이에 대한 답을 제시하지는 않을 것이다.

개체집합의 후보를 선정하였으면 개체집합을 분류를 한다. 시스템의 크기나 모델러에 따라서 개체집합을 분류하지 않을 수도 있다. 물론 이 방법은 쓰는 사람만 쓰지만 데이터의 탄생의 비밀과 중요도를 알 수 있으므로 개체집합을 분류하는 작업은 매우 바람직하다고 볼 수 있다. 개체집합을 분류하면 다음과 같은 이점이 있다.

• 업무의 우선 순위를 판단 할 수 있다.
  
• 데이터가 어떤 업무에 의해서 만들어져야 하는지에 대한 정의가 이루어진다.
  
• Key Entity Set과 Main Entity Set을 분류하여 시스템의 뼈대와 살을 분리
  
• 우리가 구축해야 할 시스템의 틀을 마련할 수 있다.
  
• 주제영역(Subject Area)를 파악할 수 있다.
  
  

어찌 보면 위에 나열된 내용은 모두 같은 내용으로 볼 수 있다. 키 개체집합은 프로젝트를 진행할 때 우선순위 판단의 기준이 될 수 있다. 왜냐하면 해당 조직에서 없어서는 안될 가장 중요한 기초 데이터이기 때문이다. 데이터의 분류에 의한 우선순위 선정이 되지 않으면, 거의 대부분의 프로젝트에서 관계(Relationship)를 끊고 작업하는 일이 발생한다. 이는 지극히 현실을 무시하고 개발하는 것이므로 당장은 편하겠지만 프로젝트 후반에 고생할 것은 충분히 짐작할 수 있다. 시스템의 틀이 되는 것은 키 개체집합(Key Entity Set)과 중심 개체집합(Main Entity Set)이다. 그 중 키 개체집합은 업무의 주제영역이 될 가능성이 매우 높다. 그럼 어떤 기준으로 개체집합을 분류할 것인가? 다음의 두 가지 방법을 사용한다.

• 탄생 시점에 의한 분류
  
• 모델 관점에 의한 분류
  
  

탄생 시점에 의한 분류는 최종 사용자가 행위를 하기 위해서 어떤 기초 데이터가 사용되었는지 판단하는 과정이다. 예를 들어 주문과 같은 경우 고객과 상품이 있어야만 주문이 가능하므로 고객과 상품은 주문보다 탄생 시점이 더 빠르다. 모델 관점에 의한 분류는 개체집합을 정의한 단계 이후에 관계집합을 정의하는 단계에 매우 큰 도움이 된다. 또는 관계집합을 정의하면서 진행하여도 무방하다.
탄생 시점에 의한 분류는 키 개체집합, 중심 개체집합, 행위 개체집합으로 분류된다. 용어는 틀릴 수도 있지만 개념은 같으니 이곳에서는 키, 중심, 행위로 나누도록 하겠다. 키, 중심 개체집합은 전체 개체집합의 차지하는 비율이 많지 않다. 사용자가 접근하는 개체집합은 대부분 행위 개체집합이다. 각각의 개체집합의 특성에 대해서 살펴보도록 하겠다.

키 개체집합은 해당 조직이 존재하기 위해서 꼭 필요한 개체집합이다. 예를 들어 부서, 사원이 이에 해당한다. 즉, 탄생 순서에 의한 분류에서 부서와 사원은 그 어떤 것도 먼저 태어났고(데이터가 생성되었고) 그 어떤 것이 태어나는데 영향을 끼치지 않았다는 것이다. 그러나 다음과 같은 경우를 보고 이에 대한 반박을 하는 경우도 있다.

즉, “각각의 사원은 반드시 하나의 부서에 소속되어야 한다.” 라는 관계를 가지고 있을 때이다. 만약 이러한 규칙을 어겼을 경우는 DBMS는 다음과 같은 오류 메시지를 리턴할 것이다.

이렇게 볼 때 “부서”는 “사원”의 탄생에 영향을 미쳤다고 할 수 있다. 그러나 여기서 중요한 것을 빠뜨렸다. 바로 “사원”이 실제로 물리적으로 구현되었을 때 포함되어 있는 “외부키”의 존재이다. 즉, “외부키”는 외부로부터 해당 개체집합에 들어온 키이다. 그러므로 “부서번호”는 사원의 속성이 아니라 “관계”라는 것이다. 즉, “부서번호”는 “사원” 개체집합에 포함되는 내용이 아니라는 것이다. 그러므로 관계가 없이 각각의 개체집합을 보았을 때는 탄생에 대한 영향이 없다는 것을 알 수 있다. 즉, 키 개체집합은 최 상위 개체집합(개체집합이 탄생되는데 영향을 준 다른 개체집합이 없는 것)이다.
또 한가지 특징은 키 개체집합은 개체가 새로 생기거나 변경, 삭제되는 일이 적은 집합이라는 것이다. 일반적인 업무에 비해서 사원, 부서와 같은 경우 Create, Update, Delete와 같은 연산은 많이 발생되지 않는다. 왜냐하면 해당 조직의 틀이기 때문이다. 만약 사원 개체집합에서 Create, Update, Delete의 대상이 50%에 해당 된다면 그 조직은 분명히 엄청난 사건이 일어난 것이다.
키 개체집합은 거의 대부분은 Subject Area 명과 유사하다. 또한 독립적인 개체집합(다른 개체가 없이도 개체 탄생 가능)이다. 그러므로 항상 서브타입을 항상 고려해야 한다.
예) 고객, 부서, 사원, 거래처, 상품 …

중심 개체집합은 업무의 중심이 되는 개체집합이다. 중심 개체집합의 탄생에 영향을 주는 것은 키 개체집합이 될 수도 있고, 또한 다른 중심 개체집합이 될 수 있다. 그러므로 어떤 레벨까지 중심 개체집합으로 놓느냐는 전적으로 사용자의 의견을 수렴하여 모델러가 판단해야 한다. 예를 들면 주문과 같은 경우가 중심 개체집합으로 볼 수 있다. 왜냐하면 주문은 고객과 상품이 있어야만 탄생이 가능하기 때문이다. 즉, 주문하는 고객이 있어야 하고, 주문하는 상품이 있어야 하는 것이다. 모델러마다 약간씩 틀리지만 “주문”과 같은 경우는 관계로 놓는 경우도 있다. 틀렸다고는 할 수 없다. 또한 중심 개체집합은 행위를 위한 소스를 제공하는 개체집합(데이터 발생 주체)이다. 즉, 행위 개체집합의 소스가 된다. 중심 개체집합은 업무의 도메인에 따라서 Main Entity Set의 분류는 틀려진다.
중심 개체집합인지 아닌지를 판단하는 것은 해당 개체가 만들어지기 위해서 어떤 다른 개체가 영향을 주었는지 만 파악하면 된다. “계약”과 같은 경우는 예를 들어 “고객”과 “상품”과 같은 개체가 먼저 탄생되어 있어야만 존재 가능하므로 분명히 키 개체집합은 아니다. “고객”과 “상품”은 키 개체집합이므로 “계약”은 중심 개체집합이다.
예)카드, 계약, 수강 …

행위 개체집합은 업무 행위를 나타내는 개체집합이다. 키 개체집합과 중심 개체집합을 찾고 나면 나머지는 모두 행위 개체집합이라고 볼 수 있다. 처음 개체집합의 후보를 도출 할 경우는 행위 개체집합은 자주 눈에 보일 것이다. 왜냐하면 대부분의 업무는 Action Entity Set에 접근하기 때문이다. Action Entity Set은 Main Entity Set이 탄생에 직접적인 영향을 주거나 다른 Action Entity Set에 의해서도 탄생된다. 즉, 부모를 가지지 않는 Action Entity Set은 없다. 또 다른 특성으로는 개체의 생성, 변경, 삭제가 매우 많이 일어난다는 것이다.
예) 구매내역, 사고유형?

개체집합의 분류 시 주의 사항

개체집합의 분류는 Entity Set의 탄생에 영향을 주는지 평가하는 것이다. 탄생 시점으로 분류를 한다는 것은 물의 진원지를 파악하는 것과 비슷하다. 주의 할 점은 개념을 어떻게 파악했느냐에 따라서 분류가 틀려질 수 있다는 것이다. 이에 대한 내용은 관계를 다룰 때 다시 다루도록 하겠다. 좀 더 확실하게 개체집합을 분류해보고 싶다면 Instance Diagram을 그려 볼 것을 권장한다. 애매모호함을 줄여줄 것이다.

모델관점에 의한 분류는 아래의 그림과 같이 전체적인 개념이 모두 잡혀야 가능하다. 모델관점에서 보면 다음과 같이 분류될 수 있다.

• 독립 개체집합: 독립적으로 존재가능
  
• 중심 개체집합: 업무의 중심이 됨, 많은 관계를 가짐
  
• 의존 개체집합: 독립적으로 존재하지 못하고, 다른 개체집합이 탄생되어 있어야 하는 집합
  
• 연관 개체집합: 두 개의 개체집합에 연관되어 있는 집합(대부분 다:다 관계의 해소로 생김)
  
• 특성 개체집합: 다중값 속성을 해소하거나 또는 코드성 집합임
  
  

개체집합의 후보가 선정되고, 분류가 이루어졌다면 개체집합에 대한 적절한 명칭을 부여해야 한다. 모델은 프로젝트 관계자들의 의사소통의 도구이자 가시화, 문서화하기 위한 도구이다. 그러므로 개체집합의 이름은 해당 조직에서 통용될 수 있는 최대한 관련된 개념을 반영할 수 있는 명칭을 부여해야 한다.
명칭을 부여하면서 가능하다면 개체집합의 개념을 더욱 구체화시킨다. 개체집합의 개념이 구체화되면 될수록 프로젝트의 성공은 가까워진다. 중요한 것은 해당 조직에서의 용어나 개념이라는 것이지, 일반적으로 사용되는 용어나 개념이 아니라는 것이다. 짐작하지 말고 꼭 확인을 해야 한다. 매우 일반적인 용어라도 간과하지 말아야 한다. 개체집합의 명칭은 반드시 해당 도메인에서 통용되는 명칭으로 부여하되 프로젝트 관계자들이 혼란스럽지 않도록 명칭 선정한다.

수집된 후보를 다음의 질문에서 모두 Yes라는 답을 얻어야 한다. 만약 애매모호함이 발견된다면 이 자리에서 모두 해결하거나 적절한 단계로 피드백이 이루어져야 한다.

1. 시스템화 하고자 하는 Domain안에 있는가?
   
2. 미래까지 고려해야 함
   
   1. 유연성 확보
      
   2. 의미가 흐려지지 않는 범위에서…
      
3. 집합(가로 * 세로) 인가?
   
4. 가로가 2개 이상인가?
   
5. 세로가 2개 이상인가?
   
6. 본질적인 집합인가?(다른 두 집합의 중첩?)
   
7. 각각의 개체를 구분할 수 있는 속성(들)이 있는가? (식별자)
   
8. 명사적 표현인가?
   
   

Key Entity Set은 업무의 기초가 되는 것이기 때문에 최대한 단순화시키는 것이 중요하다. Key Entity Set이 복잡해지면 데이터 모델은 매우 복잡해진다. 키 개체집합은 개체가 탄생되기 위해서 어떤 개체집합에도 영향을 받지 않는다. 그러나 키 개체집합은 다른 개체가 탄생되는데 직/간접적인 영향을 미친다. 예를 들어 “주문”은 “고객”과 “상품”에 영향을 받는다. 그러므로 “고객”이나 “상품”이 복잡하면 당연히 “주문” 개체집합과 “주문”과 관계된 다른 개체집합들도 복잡해진다. “주문”에서 더 상세화되면 더욱 복잡해진다. 또한 Key Entity Set이 변화하면 데이터베이스 전체에 많은 영향을 끼친다. 그러므로 통합을 통하여 최대한 단순화 시키는 것이 중요하다. (데이터 모델은 프로젝트 관계자와의 의사소통 도구이므로 단순성을 확보해야 한다.)
주의해야 할 것은 추상화레벨을 너무 높이거나 너무 많은 통합이 이루어지면 의미가 희석된다는 것이다. 키 개체집합이 다른 개체집합들의 탄생에 직접적인 영향을 미치므로 당연히 영향을 받는 하위 개체집합들의 의미도 희석된다. 매우 주의해야 한다. 이러한 이유로 모든 프로젝트는 Key Entity Set으로부터 시작되어야 한다. (자동 우선순위 선정) Code Entity Set은 Key Entity Set이지만 초기에 도출하면 모델이 복잡해지므로 가능하면 나중에 도출한다. (모델은 단순하면서 명료하게..)
데이터베이스 시스템의 주요 목적은 사용자에게 데이터에 관련된 추상적인 관점을 제공하는 것이다. 대부분의 사용자들은 정보시스템의 깊은 곳까지 알 수 없고, 또한 알 필요도 없으므로 여러 단계의 추상화를 통해 이런 복잡한 구조를 가능한 감추는 것이 중요하다. 다음의 그림을 보자.

Componet의 서브타입으로 Chair_Leg, Seat_Support, Cushion, Seat, Back이 있다. 일반화 시킨다고 시킨 것인데, 이 하나의 개체집합으로 매우 복잡해짐을 느낄 수 있다. 아래와 같이 ComponentType을 하나의 속성으로 본다면 이는 다중값 속성이 된다. 그러므로 다중값 속성을 해결하여 또 하나의 개체집합을 만들었다. 각 Type이 결정되어야 하므로 다중값 속성에 대한 해소는 진행되었다. 또한 서브타입이 더 생겨도 Type만 추가하여 주면 되니 문제가 될 것은 없다.

이제까지 키개체집합과 중심개체집합을 선정하는 방법을 알아보았다. 그러면 행위 개체집합은 어떻게 분류하고 찾아낼까? 답은 단순하다. 키, 중심이 아닌 것은 모두 행위 개체집합인 것이다. 이제까지는 하향식 방법을 사용하였다. 상향식 방법은 구 시스템이나 장표 등의 보고서 형태의 문서를 보면서 개체집합을 도출할 때 매우 편리하다. 우선 살펴보아야 할 것은 다음과 같다.

• 필수속성 구분(not null)
  
• 필수속성의 의미파악
  
• 탄생에 직접적인 영향을 주었는지 파악
  
• 발생한 대상 파악
  
• 발생한 시기 파악
  
  

일단 NULL 허용 컬럼은 무조건 제외시킨다. 이는 있어도 되고 없어도 되는 옵션이다. 그러므로 필수적으로 필요한 속성의 의미를 먼저 파악한다. 의미가 파악되었으면 탄생에 직접적인 영향을 준 것이 어떤 것인지 파악한다. 아래의 그림을 보자.

이 그림에서 보면 “계약자원장”의 한 개체가 만들어지기 위해서는 “고객” 개체집합과 “주택” 개체집합이 참여해야 한다는 것을 알 수 있다. 더 살펴보아야 할 것은 “주택”이 부분집합인지를 살펴보아야 한다. 실제로 추상화 레벨을 더 높인다면 “주택”은 “건물”의 부분집합이 될 수 있다. 그러므로 탄생에 직접적인 영향을 끼치는 것은 “건물”이 된다. 물론 이렇게 가정했을 때의 이야기다. 발생한 대상을 파악하라는 이야기는 개체집합의 개념에 이미 포함되어 있기 때문에 그렇게 하라는 이야기다. 물론 의미가 정의되지 않았더라도 어딘가에는 그 의미가 숨어 있을 것이다. 그것을 찾아내는 것도 모델러의 임무 중에 하나이다. 또한 발생시기를 찾아야 한다. 그림에서 본다면 개체 하나가 만들어지기 위해서는 “계약일”이라는 것이 필요하다. 즉, 개체 하나가 만들어지기 위해서는 “고객”, “주택”, “계약일”이 필요하다는 것이다. 실제로 이 방법을 사용하기 위해서는 실제 식별자를 찾는 것이 매우 중요하다. “계약번호”와 같은 것은 설계속성이다. 설계속성이 아닌 진짜 식별자를 찾음으로써 실제로 하나의 개체가 탄생되는데 영향을 끼친 개체집합이 어떤 것인지를 판단해 낼 수 있는 것이다. 실제로 위에서 나타난 “계약자원장”은 매우 많은 문제를 가졌다. 이 단원의 목적은 상향식으로 어떻게 개체를 도출하는가에 대한 내용이므로 나머지는 언급될 때마다 차차 살펴보기로 하겠다.