#title 개체집합에 대하여..
[[TableOfContents]]

이제 데이터 모델링을 위해 알아보아야 할 것들을 모두 알아보았다. 다른 필요한 것들은 데이터베이스론 서적을 참고하여야 할 것이다. 이제 우리는 개체집합, 관계집합, 속성집합에 대해서 자세히 알아볼 것이다. 또한 여러 가지 모델링 기법에 대해서도 알아볼 것이다. 먼저 개체집합에 대해서 알아보도록 하자.

==== 개체와 개체집합 ==== 
개체(Entity) 또는 객체(Object)는 객체지향의 개념에서 빠져서는 안될 중요한 개념이다. 간단하게 그림을 보면 개체와 개체집합에 대해서 쉽게 설명할 수 있다. 

attachment:data_modeling01.jpg

사원번호가 ‘PMA42628M’인 사원은 하나의 개체이다. 또한 사원번호가 ‘VPA30890F’인 사원도 하나의 개체이다. 즉, 이러한 개체들의 모임이 바로 ‘개체집합’인 것이다. 여기서 알아야 할 것은 ‘집합’이다. 단순히 ‘~~의 모임’ 이 되어서는 안 된다. 우리는 수학시간에 집합에 대해서 다음과 같은 문제를 접하고는 했다. 

1. 키가 180Cm 이상인 사람들의 모임
2. 키 큰 사람들의 모임
 
''* 집합이란 특정 조건에 맞는 원소들의 모임. 임의의 한 원소가 그 모임에 속하는지를 알 수 있고, 그 모임에 속하는 임의의 두 원소가 다른가 같은가를 구별할 수 있는 명확한 표준이 있는 것을 이른다.''

이 두 문장을 가지고 개체집합의 개념을 알아보도록 하겠다. 수학시간에 배운 바로는 1은 집합이며, 2는 집합이 아니다라고 배웠다. 맞다. 그렇다면 우리가 앞서 살펴본 “사원”은 개체집합인가? “창문 밖에 지나가는 30대 가량으로 보이는 정장차림의 남자”는 사원인가? 섣불리 대답을 못할 것이다. 답을 못하는 이유는 집합의 정의처럼 “조건”을 제시하지 않았기 때문이다. 그렇다면 “OO 주식회사의 사원번호를 부여 받은 주민등록번호가 있는 국내거주자”라고 한다면 밖에 지나가는 남자가 사원인지 아닌지를 알 수 있을 것이다. 물론 필자가 이야기한 조건도 부족할 수도 있다. 이러한 조건들을 사용자들의 머리 속에서 끄집어 내어 정리하는 것이 바로 모델링이다. 
 
조건들은 “울타리”가 될 것이다. 그 울타리 안 쪽으로 들어오기 위한 조건들은 도메인이 될 것이다. 추상화 레벨이 높을수록 울타리는 낮을 것이며, 추상화 레벨이 낮을수록(구체화) 울타리는 높을 것이다. 우리는 적당한 추상화 레벨을 선택해야 한다. 추상화 레벨을 너무 낮추어 모델링한다면 상대적으로 복잡도는 증가할 것이나 정보의 정확성은 높아질 것이다. 모델러는 이러한 딜레마에서 유리한 쪽으로 판단하여야 할 것이다. 

==== 개념의 범위를 정하라 ====
데이터 모델링의 핵심기법은 “개념의 범위를 정의하는 것” 이다. 개체집합이건 관계집합이건 개념의 범위가 정해지면 그것으로 추상화는 끝이다. 이러한 개념의 범위에서 그래픽적인 요소를 가미하여 데이터 모델은 표현된다. 가장 큰 개념의 범위는 시스템을 구축하고자 하는 조직이다. 물론 내/외부 환경적인 요인이 개념의 범위에 필요할 수도 있다. 그러므로 시스템화 하고자 하는 범위가 개념의 가장 큰 범위가 된다. 모든 관점은 해당 조직에서의 개념이 된다. 
 
예를 들어보자. 다음의 그림은 우리가 생각하는 일반적인 담배의 그림이다.

attachment:data_modeling02.jpg

||특정 규격을 가진 종이 또는 다른 재질에 담겨진 제품 또는 상품이다. 규격은 이미 정해져 있을 수도 있으며, 계획된 상품에 따라서 현재 출시된 제품의 규격이 아닌 규격도 존재할 수 있다. 개념은 속의 내용물을 모두 포함하는 개념이다. ...||

물론 쓰여져 있는 담배의 개념보다 더 구체적으로 정의되었다고 가정하자. 이것은 담배를 제조/판매하는 조직에서 본 관점일 것이다. 그렇다면 다음과 같은 정의를 가지는 “담배”는 이 조직에서 담배일까?
 
 "쌍떡잎 식물 통화식물목 가지과의 여러해살이풀"
 
이 정의는 식물을 의미하는 것이다. 아마도 식물에 대한 연구를 하는 조직이라면 담배의 개념은 식물의 개념일 것이다. 그러므로 담배(그림)를 제조/판매하는 조직의 관점에서 본다면 “쌍떡잎 식물 통화식물목 가지과의 여러해살이풀”은 담배가 아니다. 상품을 만드는데 투입되는 원자재 정도는 될 것이다. 만약 식물의 개념도 담배의 개념에 넣는다면 추상화 레벨은 높아진다. 제품의 정의와 식물의 정의가 섞인다면 당연히 의미는 희미해지기 마련이므로 이미 언급하였듯이 모델러는 추상화 레벨을 잘 결정해야 한다. 
 
또 다른 예를 들어보자. “가게”을 국어 사전에서 찾아보자. 사전상의 의미는 “소규모의 상점”이라고 되어 있다. 데이터베이스의 관점에서 볼 때 이러한 정의는 맞지 않는다. 왜냐하면 집합이 아니기 때문이다. 애매모호한 것은 “소규모”이다. 만약 “10평이하의 소규모 상점”이라고 했다면 이러한 애매모호함은 없었을 것이다. 실무에서는 대부분의 정의를 “소규모의 상점”과 같이 하고 있다. 그러므로 관점에서 따라서 동네의 슈퍼마켓도 “가게”가 될 수 있고, 대규모 할인 매장도 “가게”가 될 수 있는 것이다. 
 
이러한 혼란은 개발 기간 중이나 유지보수 기간 동안에 시스템의 변경과 혼란을 유발 할 수 있다. 결국 이러한 요소는 사용자에게 좋은 정보를 제공하는데 방해요소라는 것을 알 수 있다. 데이터 모델링에서 이러한 개념을 집고 넘어갔다면 업무는 매우 명확해졌을 것이며, 이러한 업무는 시스템에 그대로 녹아 들어 갈 수 있었을 것이다. 성능 튜닝의 목적은 “속도”가 아니라 “정보의 질 향상”이라는 것을 다시 한번 인식하도록 하자. 

==== 개체집합의 개념 ====
이제 본격적으로 개체집합의 개념을 살펴보도록 하겠다. 개체집합의 선정 과정은 매우 중요한 과정이다. 물론 시스템을 구성하는 모든 요소가 중요하기는 하지만 개체집합에 1%의 중요성을 더 주고 싶다. 그 이유는 모든 데이터가 원천적으로 담겨질 곳을 설계하는 것이기 때문이다. 개체집합을 어떻게 정의하느냐에 따라서 모델의 모양이 틀려진다. 이에 대해서는 나중에 관계집합을 다루는 부분에서 살펴보도록 하겠다. 우선 다음의 그림을 보도록 하자. A라는 제조업체의 “사원” 개체집합이다. 

attachment:data_modeling03.jpg


위 그림은 “사원” 개체집합을 나타내는 그림이다. 아래의 사람 모양의 그림은 실제로 구현된(어커런스, 인스턴스) 것을 나타낸다. 소속부서의 경우는 개체집합의 한 요소가 아닌 관계의 표현이다. 이에 대해서도 역시 관계집합에서 다루도록 하겠다. 우선은 개체집합의 개념에 집중을 하도록 하자. 
 
실제로 “사원” 개체집합은 (111, ‘이재학’), (222, ‘나병우’), (333, ‘전호중’)과 같은 실제 데이터를 가진 개체들의 집합이다. 각각의 실제 데이터는 우리가 정의한 개체집합의 개념에 적합한 데이터만을 가지게 된다. 이러한 개체집합의 정의는 다음과 같다. 

||엔터티 집합이란? 한 조직(기업) 내에서 존재하는 다른 사물과 구별 지을 수 있는 어떤 특정한 관련성으로 묶일 수 있는 하나의 집합||

“한 조직(기업) 내에서 존재하는”의 뜻은 가장 큰 도메인을 나타낸다. 만약 ‘이재학’, ‘나병우’를 해당 기업의 관점이 아닌 자동차 영업 사원의 관점에서 본다면 “고객” 개체집합이 될 수 있다. 물론 고객의 정의를 “자동차를 살 수 있는 운전 면허가 있는 국내/외 성인 남/여” 쯤으로 정의했을 때이다. 이처럼 도메인에 따라서 개체집합의 정의가 틀려질 수 있기 때문에 개념의 범위를 한정 지은 것이다. 
 
“다른 사물과 구별 지을 수 있는” 의 뜻은 각각의 개체의 고유성과 대표성, 알 수 있는 값을 의미한다. “이재학” 이라는 사람을 두고서 도메인에 따라서 고유할 수 있는 식별자가 존재함을 뜻한다. “대한민국”의 범위에서 본다면 “이재학”이라는 사람의 식별자는 “주민등록번호”쯤이 될 것이고, 대학교의 범위에서 본다면 “주민등록번호” 보다는 “학생번호”가 더 대표성을 지니고 있으므로 “학생번호”가 식별자가 될 것이다. 
 
“특정한 관련성으로 묶일 수 있는” 의 뜻은 주제 중심적이라는 것과 객관적인 정의를 의미한다. 그 관련성이라는 것은 “우리 OO대학의 학생” 이라는 관련성이다. 학교에서 지나가는 학생을 붙잡고 “너 우리학교 학생이냐?”라고 물었을 때 그 학생이 “맞다” 라고 대답을 하면 실제로 확인해 볼 방법이 없다. 그 이유는 객관적인 명확한 정의가 이루지지 않았기 때문이다. 학번을 학교로부터 부여 받았으며, 등록금을 냈으며.. 등등을 따져보았을 때 옳은지 그른지 알 수 있다. 실제로 이렇게 따져보지 않아도 같은 학부(과) 학생이라면 우리는 머리 속에는 개념이 추상적으로 박혀있기 때문에 맞는지 틀리지는 알 수 있다. 그 학생은 그 학교의 “학생”의 개념의 범위 속하기 때문이다. 
 
많은 사람들이 데이터 모델링이 어렵다고 한다. 그 개념이 매우 모호하기 때문이다. 여기에 우리가 매우 어렵게 생각하는 “개체집합”을 어떻게 도출해야 하는지에 대한 열쇠가 있다. 이미 눈치챘을 것이다. 그 열쇠는 애매모호함을 없애는 것이다. 그 유명한 스티브 맥코넬은 다음과 같은 말을 했다. 
 
“뛰어난 디자이너들은 복잡성에 대한 두려움이 없다. 그들의 목표는 복잡한 것을 단순하게 만드는 것에 있다.”
 
모델을 만드는 것이 바로 복잡한 현실을 단순화시켜 애매모호함을 제거하는 것이다. 이것이 좋은 모델을 만드는 기본개념이 된다. 엔코아 정보 컨설팅의 이화식 대표는 개체집합을 다음과 같이 정의하였다. 

||엔터티 집합이란 인간이 생각하는 개념 또는 정보의 세계에서는 의미 있는 정보의 단위. 또는 우리가 관리하고자 하는 두 개 이상의 속성과 두 개 이상의 개체를 지닌 동질성의 의미를 가진 독립적인 집합(엔코아정보컨설팅, 이화식) 입니다.||

필자가 보기에는 매우 명확한 정의라 생각된다. 개체집합은 위에서 이야기한 개체집합의 정의에 따라 다음의 물음에 명확히 답할 수 있어야 한다. 

 * 업무상 관리되어야 할 의미 있는 단위인가? (개념의 범위, 현재 또는 미래 포함)
 * 집합 (키가 180Cm 이상인 사람들의 모임) 인가?
 * 영속성을 가지는가?
 * 독립성을 가지는가?
 * 본질적인 집합인가?
 * 관리되어야 할 구체적인 항목이 두 개 이상 존재하는가?
 * 관리되어야 할 개체들이 두 개 이상 존재하는가?
 * 각각의 개체들은 식별이 가능한가?
 * 명사적인 표현인가?

해당 개체집합은 업무상 관리되어야 한다. 여기서 “관리되어야 한다”는 의미는 우리가 시스템화 하고자 한다는 것이며, 특정한 개념의 범위가 있다는 의미로 “단위”라는 말이 들어갔다. 이러한 개념의 범위는 과거, 현재, 미래를 모두 포함해야 한다. 혹자는 데이터베이스는 특정 시점을 나타내는 것이므로 과거, 미래에 대한 언급은 틀린 것이라고 생각 할 수도 있다. 그러나 틀린 말이 아니다. 데이터웨어하우스에서는 “시간변이적인” 이라는 말이 나온다. 역시 이것도 데이터베이스이며, 이력관리를 통해서 과거, 현재, 미래의 업무에 필요한 정보를 제공해 줄 수 있다. 
 
영속성이라는 것은 해당 조직의 업무에 데이터가 계속 존재하여 쓰여짐을 의미한다. 독립성은 개체들이 독립적으로 존재할 수 있느냐에 대한 의미이다. 본질적이라는 것은 개체만의 개념이 포함되어야 한다는 뜻이다. 앞서 살펴본 “사원”에서 “소속부서”가 있었음을 알 수 있는데, 이는 관계의 표현일 뿐이다. 예를 들어 어떤 경매사이트에서 “입찰자”는 개체집합이 아니라 관계집합이다. 즉, 회원이 입찰이라는 행위를 통해 입찰자가 된 것이다. 즉, 우리가 알고 있는 입찰자는 회원의 또 다른 표현일 뿐이다. 해당 회원이 입찰이라는 행위를 하지 않으면 그 회원은 입찰자가 될 수 없음을 알아야 한다. 그러므로 입찰자는 “회원”이 “입찰”이라는 행위를 통해서 만들어진 데이터다. 그러므로 “입찰자”는 본질적인 집합이 아니다. 

다음의 예를 보자.
||라이터에는 제품명, 원산지, 제조일, 제조자명, 수입자명, 주소 등이 표기되어 있으며, 적색, 녹색, 황색 등 여러 가지 색깔을 가진다.||

라이터 가게에서 정보시스템을 도입하려 한다. 그러면 해당 조직에서만 필요한 데이터가 있다는 것이다. 라이터 가게의 관계자 이외의 사람들이 과연 제품명, 원산지 등에 관심이 있겠냐는 것이다. 철저히 개념의 범위를 좁혀야 한다. 만약 우리나라의 대부분의 국민들이 애국심이 너무나도 뛰어나 국산품을 매우 애용한다면 원산지에 대한 정보는 다른 사람들에게도 매우 중요한 데이터가 될 것이다. 

attachment:data_modeling04.jpg

위 그림은 두 개 이상의 개체와 항목에 대한 내용이다. 만약 “제조일”만 있다고 생각하여 보자. 제조일만 보면 도저히 어떤 것에 대한 제조일을 나타내는지 알 수가 없다. 즉, 항목이 한 개밖에 없다면 의미를 알 수 없다는 뜻이다. 제품이 “불티나”만 있다면 관리해야 할 필요성이 있을까? 당연히 관리해야 할 필요성은 없다. 그러므로 개체집합은 두 개 이상의 항목과 두 개 이상의 개체가 있어야 개체집합으로써의 자격이 될 수 있다는 것이다. 
 
아마도 여러분은 라이터에 대한 내용을 읽으면서 300원짜리 빨간 가스 라이터를 연상했을 것이다. 그렇다면 다음 그림을 보도록 하자. 

attachment:data_modeling05.jpg

모두 같은 라이터라고 볼 수 있는가? 그림만을 가지고 볼 때 이것을 모두 같은 라이터라고 묻는다면 비율을 어떻게 될지 몰라도 O, X로 분류될 수 있을 것이다. 역시 이렇게 나뉘는 이유는 도메인이 정확하지 않기 때문이다. “불만 켜지면 모두 라이터다” 라고 한다면 그림에는 없지만 가스레인지도 라이터다. 주로 담뱃불을 붙일 때 사용된다고 한다면 역시 가스레인지도 경우에 따라 라이터가 될 수 있다. 가스레인지로 담뱃불을 붙여본 사람은 알 것이다. (적어도 필자는 그렇게 했다) 애매모호하다면 개체집합의 정의가 부실한 것이다. 그러므로 무언가 석연치 않다면 개체집합의 정의를 더욱 명확히 내릴 필요가 있다는 뜻이 된다. 개체집합의 정의를 명확히 내릴수록 구체화되며, 개체집합의 정의가 덜 명확할수록 추상화 레벨은 높아진다. 

==== 개체집합을 선정하기 어려운 이유 ====
실제로 개체집합을 도출하는 과정은 매우 힘든 과정이다. 모델러는 모든 업무를 알 수 없기 때문에 사용자의 머리 속에서 또는 기존의 시스템과 문서들을 통해 모델을 완성하기 위한 개체집합을 도출해야 하기 때문이다. 그러나 이 또한 체계적인 방법을 가지고 접근한다면 그리 어려울 것도 없다. 단지 체계적인 단계를 거치면서 각 단계를 충실히 수행하는 것이 중요하다. 다음은 개체집합을 도출하는데 어려운 이유이다. 

 * 애매모호한 정의 
 * 엔터티집합과 관계, 속성의 개념 혼동
 * 처리 방법에 대한 사전 고려 
 * 정형화된 개발 방법론의 부재
 * 모델링과 설계의 중요성에 대한 인식 부족

개체집합을 도출하는데 어려움을 느끼는 가장 중요한 이유는 바로 “애매모호한 정의”이다. 다음의 정의를 보자. 

 1. "키가 큰 사람들의 집합" 
 2. "키가 180Cm 이상인 대한민국 국적을 가진 주민등록번호를 가지고 있는 현재 국내 거주자"

1번은 전혀 집합적이지 못하다. 그에 비해 2번은 매우 명확하다. 많은 경우에 1번과 같이 정의하기 때문에 개체집합을 도출하지 못하는 것이다. 관계(Relationship)을 다룰 때 이야기하겠지만 개체집합을 어떻게 정의하느냐에 따라서 모델이 많이 달라진다. 또한 많은 문제점과 모델러의 고민이 바로 이러한 애매모호함에서 나온다. 또 한 가지 중요한 것은 “기본”이 부족하고, “기본”에 대한 무시 때문이다. 개체, 관계, 속성들의 정확한 개념이 있어야만 제대로 된 모델이 만들어진다. 다음의 스키마를 보자. 

매입입력
(등록자, 등록일자, __매입번호__, 매입일자, 업체코드, 업체명, 품목, 구분, 매입금액, 지급금액, 지급예정일, 미지급잔액, 계산서여부, 최종수정자, 최종수정일자, 수정내용, 수정종류)
''* 밑줄은 기본키를 나타낸다. ''

릴레이션명(개념적 : 개체집합, 물리적 : 테이블)을 보아도 벌써 데이터 모델에 “처리”가 들어간 것을 볼 수 있다. 아마도 해당 조직에서 사용하는 문서에 나오는 항목들을 모조리 기술했다고 할 수 있을 것이다. 다른 릴레이션을 보아도 똑같을 것이다. 실제 구현된 테이블은 분명히 처리의 흐름에 따라서 그려져 있을 것이고, 엄청난 데이터의 중복이 있었을 것이다. 이러한 “처리”는 데이터 모델의 매우 큰 적이다. 데이터 모델은 정적이다. 그러므로 시간의 흐름에 따른 처리에 대한 내용은 포함되어서는 안 된다. 시간은 이력관리를 고려할 때나 나와야 한다. 
 
또한 정형화된 개발 방법론이 없이 프로젝트를 진행하는 것도 매우 큰 문제가 된다. 정형화되지 않았다는 것은 주먹구구식을 의미한다. 이렇게 주먹구구식으로 해서는 절대 좋은 모델이 나올 수 없다. 이는 모델링과 설계의 중요성에 대한 인식의 부족에서 오는 결과일 수도 있다. 이 문서는 계속적으로 모델링과 설계가 실제 물리적인 구현에 미치는 영향을 설명할 것이다. (계몽서 느낌이 들어도 어쩔 수 없다.)

==== 문제점이 있는 ERD의 예 ====
다음은 ERD의 한 예이다. 

attachment:data_modeling06.jpg?width=40%

그림을 보면 “소유자”, “노동자”, “조종사”는 “사람” 개체집합으로 일반화되었다. 일단 살펴보아야 할 것은 “사람” 개체집합의 개념이 너무 넓지 않은가를 살펴보아야 한다. 중요한 것은 “소유자”는 관계집합이지 개체집합이 아니라는 것이다. “소유자”의 개념은 “고객” 이 될 것이다. 그리고 “조종사”의 개념도 애매모호하기 짝이 없다. “비행기”를 소유하고 있는 사람도 비행기를 조종할 수 있고, 조종하지 않을 수도 있다. 그러므로 “조종사”의 개념의 범위와 “소유자”의 개념의 범위는 중첩된다. 만약 비행기를 가지고 있으나 조종을 하지 못하는 “고객”을 위해 해당 조직에서 “조종사”를 제공해 준다면 “노동자”, “조종사”는 아마도 “사원”쯤으로 봐도 될 것이다. “비행기”의 경우 세상의 모든 비행기가 관리대상인지 특정 지역의 비행기가 관리대상인지 등에 대한 개념의 범위가 확정되어야 할 것이다. 관리 대상의 범위가 너무 넓으면 의미가 희석되어 프로젝트 진행에 혼란을 가져온다. 위 ERD는 어느 책에서 발췌한 것이다. 애매모호하기 짝이 없는 데이터 모델이다. 이러한 상태로 개발이 이루어진다면 예상보다 긴 프로젝트가 될 가망성이 매우 높다.