데이터 모델링(개념 데이터 모델링)

개념 데이터 모델링

---

 

1. 개념 데이터 모델링 이해

개념 데이터 모델이란?

 건물로 비유하자면, 건물의 골격을 세워 놓는 형태로서 모델링 단계 중, 정말 중요한 단계이다. 주제별로 분류 가능한 업무를 분석해서, 핵심 엔터티를 추출하고 그들 간의 관계를 정의하여 데이터의 골격을 생성하는 것이 개념 데이터 모델의 정의라고 할 수 있다. 나중에 논리 모델링, 물리 모델링 단계로 진행된다 하더라도 개념데이터 모델의 골격에서 크게 벗어나지 않기 때문에 개념 데이터 모델의 중요성은 더욱더 크다.

 

주제 영역 정의

 주제 영역은 기업이 사용하는 데이터의 최상위 집합이다. 하나의 주제 영역 내의 데이터 간 관계는 밀접해야 하고, 다른 주제 영역에 포함되는 데이터 간의 상호작용은 최소화할 수 있도록 정의해야 한다. 계획 수립 단계는 하향식 분석을 원칙으로 하고, 검증을 위해서 부분적으로 상향식 분석을 사용한다. 데이터를 하향식으로 분석하기 위한 개념으로 유용한 것이 주제 영역이다. 주제 영역은 계층적으로 표현될 수 있으며, 주제영역을 분해하면 하위 수준의 주제영역이나 엔터티가 나타난다.

 

2. 주제 영역 분류 원칙 및 기준

주제 영역 분류 원칙

 동일 기능을 하는 자원이 중복 정의되지 않도록 데이터 중복이 최소화되어야 한다. 그리고 가까운 미래에 추가될지 모르는 기능을 고려할 때, 데이터 확장성이 보장되어야 한다. 또한 데이터 관련성 및 편의성이 확보되어야 한다.

주제 영역 명명

• 실 업무에서 보편적으로 사용하는 업무 용어를 부여한다.
• 유일한 단수형 명사를 사용한다.
• 데이터 그룹을 의미하는 이름을 부여한다.

주제 영역 분류 방법

• 1차 분류 : 주요 데이터 집합의 유형을 정의한다. 기존 시스템별 데이터의 성격 및 특성을 고려해서 영역을 분류한다. 또한 업무의 변화에 민감하지 않도록 정의한다. ex) 데이터를 발생시키는 주체, 데이터 발생 주체 간의 상호작용으로 발생하는 대상, 공통/관리 성격의 상위 개념으로서의 분류
• 2차 분류 : Biz 활동에 필요한 분석 주제와 현황 등의 영역으로 분류한다. 1차 분류를 세분화한다. ex) 관계자 기본, 관계자 상세 등
• 3차 분류 : 2차 영역의 분류를 좀 더 세분화해서 분류한다. ex) 관계자 : 고객, 법인, 조직, 직원 등. 계약 : 수신계약, 예금계약, 신탁계약 등
• 업무 활동(Activity)을 의미하는 이름을 배제하고 데이터 그룹을 의미하는 이름을 사용하도록 한다.

 

주제 영역 활용

 주제 영역은 데이터의 계층 구조를 파악하는데 도움을 주며, 품질 확보에도 기여한다. 또한 효율적 데이터 관리를 위한 기준을 제공하며, 데이터 구성 및 통합에 대한 방향도 제시한다. 뿐만 아니라, 주제영역은 기업의 전사 업무를 위한 전체 데이터 구성에 대한 청사진을 제공한다.

 

주제 영역 정의 내용도출

• 레벨과 주제 영역명을 명시한다. 그리고 설명을 명시하며, 해당 주제 영역 내에서 대표적인 엔터티를 기술한다.

 

3. 후보 엔터티 선정

 엔터티를 선정할 때, 먼저 후보가 될만한 엔터티를 수집한다. 후보 엔터티의 수집 방법은 기존 시스템 도큐먼트와 현업에서 사용하는 각종 장표, 또는 현업 사용자와의 인터뷰를 통해서 찾을수도 있고, 관련 서적을 통해서도 가능하다. 이외에 데이터 흐름도라든지, 타 시스템 자료, 현장 조사를 통해서도 후보 엔터티를 수집할 수 있다.

엔터티 후보 식별

• 먼저 엔터티 후보의 개념을 명확히 정립한다. 관리하고자 하는 집합을 명확히 정의해야 다음 단계를 진행할 수 있다. 
• 그 다음, 우리가 관리하고자 하는 것인지를 현재 뿐만 아니라 미래 시점을 고려해서 따져봐야 한다. 분명한 개체집합이라 하더라도 관리 필요성이 없다면 과감히 버려야 한다. 
• 마지막으로 가로 세로를 가진 집합인지를 확인해야 한다.

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

• 엔터티 가능성이 있다고 예상되면 일단 검토 대상에 올려라.
• 너무 깊게 들어가지 말자. 후보 자격의 여부만 따지면 된다. 
• 동의어처럼 보이더라도 함부로 버리지 말자. 모델링 뒷부분에서 동의어로 보이는 후보를 집합의 정의에 따라 통합하면 된다.
• 개념이 모호한 대상은 일차로 그 개념을 상식화하여 이해하자.
• 프로세스에 너무 연연해 하지 말자.
• 예외 경우에 너무 집착하지 말자.
• 단어 하나하나에 집중해서 판단하자.

엔터티 분류

• 키 엔터티 : 간단 명료한 정의는 자신의 부모를 가지지 않는 엔터티라고 할 수 있다. 모델 내에서 주어 역할을 하며, 하위 엔터티들의 탄생을 유도한다. 주로 사원, 부서, 고객, 상품, 자재 등이 키 엔터티로 분류될수 있다.
• 메인 엔터티 : 키 엔터티를 제외한 나머지 엔터티 중에서 업무의 중심에 해당하는 엔터티를 메인엔터티라 정의한다. 주로 보험계약, 사고, 구매의뢰, 주문, 매출 등이 메인 엔터티로 분류될 수 있다.
• 액션 엔터티 : 키, 메인 엔터티를 제외한 나머지를 통상 액션 엔터티로 부른다. 액션 엔터티는 당연히 부모 없이 절대 존재할 수 없다. 즉, 존재종속으로 태어난 아이들이라고 보면 된다. 모델링이 좀 더 구체적으로 진행되더라도 키 엔터티와 메인 엔터티는 집합의 본질이 크게 달라지지 않는데 반해, 액션 엔터티는 상위 엔터티들이 어떻게 결정되느냐에 따라서 크게 영향을 받기 때문에 모델링 후반에 사라질수도 또는 크게 변경될 수도 있다. 주로 상태 이력, 차량 수리 내역 등이 액션 엔터티로 분류된다.

 

4. 핵심 엔터티 정의

엔터티 정의의 요건

• 관리하고자 하는 것인지를 확인한다.
• 가로와 세로를 가진 면적인지를 확인한다.
• 대상 개체 간의 동질성이 있는지를 확인한다.
• 다른 개체와 확연히 구분되는 독립성을 가지는지를 확인한다.
• 순수한 개체이거나 행위를 하는 행위 집합인지를 확인한다.

의미상 주어 정의(본질 식별자)

 인조식별자가 가주어라고 한다면, 진주어는 해당 엔터티의 의미상의 주어를 말한다. 이를 우리는 본질 식별자라고 칭한다. 본질 식별자는 집합의 인스턴스가 생성되는 정확한 단위라고 할 수 있다. 즉, 집합의 의미가 명확하게 정의되지 않은 모호한 집합에 인조적인 유일한 이름만 가져다 붙인다고 해서 갑자기 집합의 정의가 명확해지지는 않는다.

코드성 키 엔터티 모델링

코드성 엔터티를 개념 모델링 단계에서 모두 도출하게 되면, 추후 모델의 복잡성의 함정에 빠질 수 있다. 따라서, 다음과 같은 기준에 따라 도출하는 것이 좋다.

• 자식 엔터티를 가지는가? 해당 엔터티가 다른 엔터티의 본질 식별자가 되고 있는지를 판단한다. 해당 엔터티로 인해 다른 엔터티의 존재종속의 문제가 발생한다면, 정말 볼품 없는 엔터티라 하더라도 도출해야 한다.
• 해당 엔터티에 단순한 코드명이나 코드의 의미에 대한 설명 외에 또 다른 속성을 가지는지 확인해야 한다. 엔터티가 이러한 속성을 가지고 있다는 것은 자기만의 확실한 사유재산이 있다는 것을 의미하므로 독립적인 개체 집합으로서 의의가 있다.
• 관계 존재 여부를 확인해야 한다. 엔터티가 다양한 관계를 맺고 있다는 것은 활동성이 왕성하다는 것을 의미한다. 이러한 엔터티를 누락시킨다면 앞으로 정의해야할 많은 관계들도 같이 누락될 것이다.

 

집합 순수성

 집합 순수성이란 개체의 본질이 명확히 정의해야 된다는 말과 의미를 같이 한다. 사물을 정의한 개체 집합이든, 행위의 집합이든, 반드시 둘 중의 하나가 되어야 한다는 것이다.  예를 들어, '납입자'를 풀어보면, 납입(행위) + 자(사람) 의 합성어라 할 수 있다. 즉, 이는 엔터티가 될 수 없으며, 관계가 되어야 한다. 하지만, 집합 순수성 적용의 예외 사항도 고려해야 한다. 피보험자의 경우엔 '피보험'이라는 행위집합과 '자'라는 개체 집합의 결합이다. 즉, 피보험자는 고객과 보험계약 엔터티간에 관계가 된다. 하지만, M:M 관계로 도출되다보니, 이를 해소하기 위해, 별도의 엔터티로 도출해야 한다. 그리고 금융기관은 엔터티가 될 수 있으나 수납기간은 엔터티가 될 수 없다. 왜 그런지는 생각해보자. 그리고, 배타 관계가 가지는 복잡도를 해소하기 위해, 배타관계에 있는 엔터티를 모아서 별도의 엔터티를 구성하는 경우도 행위와 개체 집합의 합성이지만, 관계가 아닌 엔터티로 분류할 수 있다.

 

엔터티 통합과 분할

새롭게 정의하고자 하는 엔터티가 앞서 정의해 둔 어떤 엔터티에도 포함되지 않는 독립적인 집합인지를 확인해야 한다. 즉, 엔터티의 독립성을 확인해야 한다. 

보험회사의 대리점 사례

 보험회사에서 대리점은 조직과 유사한 집합으로 볼 수도 있고, 사원과 유사한 집합으로 볼 수 있다. 보험회사라면 보험모집, 고객관리 등의 주체가 되는 개체는 사람인 사원이나 설계사뿐만 아니라 대리점이 될 수도 있으므로 이러한 집합은 많은 행위를 공통적으로 한다는 입장에서 보면 매우 유사성이 강한 집합이다. 또한 개인도 자격 조건에 따라서 대리점이 될 수 있어 조직의 의미보다는 설계사나 사원의 역할을 하는 경우가 많기 때문에 사원 집합을 확장하여 여기에 포함시키고 있다. 

통신회사의 대리점 사례

 통신회사의 대리점은 회사의 조직처럼 실적 관리의 단위가 되거나 일반 부서와 유사한 업무 처리를 하기 때문에 조직으로 보는 것이 일반적이라 할 수 있다.

대리점 사원

 대리점 사원을 사원이라는 의미에서 동질성을 찾았다면 사원 엔터티에 포함시켜야 옳다. 그러나 행위의 주체로서 사원과 동격의 의미를 가지는 것은 대리점이고, 대리점 사원은 단지 참조 정보로서 관리하고자 한다면 대리점은 사원 집합에 포함시키고 대리점 사원은 별도의 엔터티로 분리하여 불필요하게 사원의 의미를 희석시키지 않는 것이 좋은 방법이다.

5. 관계 정의

• 관계도 집합이다. 두 엔터티 간 여러 개의 관계가 동시에 존재할 수 있기 때문이다.
• 직접 관계를 관계라고 한다. 
• 두 엔터티 간에는 하나 이상의 관계가 존재할 수 있다.
• 관계는 외래키(FK)로 구현되어, 참조 무결성(RI)으로 데이터 정합성 유지의 역할을 하게 된다.

관계 형태

• 1:1 관계 : 현실에서 매우 드물게 나타나며, 엔터티 수직 분할시에 많이 볼 수 있다. 또한 업무의 흐름에 따라 데이터가 설계된 형태에서도 많이 볼 수 있다. 필수-선택 형태는 한쪽은 실선, 다른 쪽은 점선으로 표현된다. 실선이 있는 엔터티는 점선이 있는 엔터티와 반드시 대응되어야 존재할 수 있다. 필수-필수 형태는 양쪽 모두 실선인 모습이다. 이 경우는 두 엔터티가 동치라고 봐야 한다. 
• M:1 관계 : 가장 흔한 관계다. 

 

병렬식 관계 특징

• 테이블이 될 때 여러 개의 칼럼으로 나열된다.
• 하나의 로우에서 관리되므로 새로운 테이블을 추가할 필요는 없다.
• 인덱스 수가 증가되고 SQL이 복잡해진다.
• 새로운 관계의 추가, 관계 형태의 변경 등에 매우 취약한 형태이다.

직렬식 관계 특징

• 관계들을 관리하는 새로운 엔터티가 추가되어야 한다.
• 관계들이 로우(Rows) 형태로 나타난다.
• 인덱스 수가 감소하고 SQL이 단순해진다.
• 새로운 관계의 추가, 관계 형태의 변경 등에 매우 유연한 형태이다.
• 관계 내용별로 상세 정보를 관리할 수 있다.

Arc 관계 특징

• 아크 내에 있는 관계는 보통 동일하다.
• 아크 내에 있는 관계는 항상 필수이거나 선택 사양이어야 한다.
• 아크는 반드시 하나의 엔터티에만 속해야 한다.
• 어떤 엔터티는 다수의 아크를 가질 수 있다. 그러나 지정된 관계는 단 하나의 아크에만 사용되어야 한다.