정의 및 관리 목적

개념 데이터 모델이란 업무 요건을 충족하는 데이터의 주제 영역과 핵심 데이터 집합을 정의하고 관계를 정의한 모델을 의미한다. 기관이나 기업의 업무 특성에 적합한 주제 영역과 핵심 데이터 집합 과의 관계를 정의하여 향후에 정의하게 될 상세 논리 데이터 모델과 물리 데이터 모델과의 데이터 구 조적 정렬(Alignment)을 지원한다. 또한 주제 영역을 통해 전체 업무 범위와 업무 구성 요소를 확인 할 수 있다.

데이터 구조를 위한 데이터 모델은 건축물을 짓는 공법과 유사하다. 큰 건축물에서 방 하나의 인테 리어부터 시작하지 않고 건물의 용도, 건물의 전체적 구조, 쓰이는 자재의 분류부터 시작하듯이 데이 터 구조에 대한 정의 역시 같은 방법으로 접근해야 한다.

개념 데이터 모델은 건축물의 조감도와 같이 구축하고자 하는 업무 모델의 핵심 데이터 구조를 그 림으로써 전체 업무에 대한 큰 윤곽을 잡고 세부적인 단계로 나아갈 수 있게 한다. 개념 데이터 모델 의 정의로부터 접근하는 것은 골조가 튼튼한 건물을 짓는 것과 같이 데이터 구조에 대한 기본 구조를 확실히 정의하고 업무 요건 변경에 취약하지 않는 데이터 구조를 세우는 것과 같다. 경우에 따라서는 개념 데이터 모델의 상위 모델인 개괄 데이터 모델을 둘 수 있다.

개괄 데이터 모델은 상위 수준의 전사 데이터 영역을 분류하여 표현한 것으로, 흔히 사용되는 주제 영역 관계도와 대응되는 부분이라고 할 수 있다. 반면에 개념 데이터 모델은 전사 수준에서 사용하는 데이터를 전체적으로 표현할 수 있는 틀로서, 단위 주제 영역별로 핵심 엔터티와 핵심 엔터티들 사이 의 관계를 정의한 모델이라고 할 수 있다.

개괄 데이터 모델은 데이터 영역과 데이터 집합을 업무 영역에 국한하지 않고 전사적 관점에서 정 의하는 것으로, 각 데이터 영역은 다른 데이터 영역과 관계를 가질 수 있다. 또한 기업의 이익 관점이 아닌 공익적인 관점에서 공통으로 사용되는 속성을 좀 더 원시화된 형태의 수준으로 정의할 수 있다. 데이터 구조에서의 세부 관리 대상은 개별적인 항목으로 관리하는 것이 아닌 개체-관계 다이어그램 (ERD, Entity Relationship Diagram)으로 표현해 관리한다.

[그림 6-2-1], [그림 6-2-2]는 개괄 데이터 모델과 바커표기법을 기준으로 작성한 개념 데이터 모델의 예다. [그림 6-2-3]은 [그림 6-2-2]의 개념 데이터 모델을 IE표기법 기준으로 작성한 예다. 작성에 사용된 도구의 특성상 동일하게 표현할 수는 없으나 바커표기법을 기준으로 작성한 예에 대 해 최대한 유사한 개념을 표현하도록 구성하였다.

세부 관리 대상

주제 영역(Subject Area)

주제 영역은 업무상 친밀도가 높은 데이터 집합을 하나의 주제 영역으로 정의한다. 일반적으로 업무를 명확히 구분하는 범위를 하나의 주제 영역으로 정의하기도 하나 주의할 점은 서로 다른 주제 영역간 공유하는 엔터티의 수가 가급적 적게 해야 한다. 다음과 같은 기준에 따라 관리되어야 한다.

원자성

하나의 단위 주제 영역은 가급적 다른 주제 영역의 엔터티나 관계의 영향을 받지 않는 엔터티의 모임이어야 한다.

집중성

단위 주제 영역 내의 엔터티와 관계는 단위 주제 영역 내에 집중되어야 한다.

업무 지향성

주제 영역을 명명하는데 있어 업무적 명확성을 나타내는 단수 단위로 명명할 수 있어야 한다.

업무상 동일한 영역에서 다루는 것이 보다 효과적인 엔터티 집합들을 하나의 주제 영역으로 선언하며, 주제 영역은 업무의 다양성에 따라 여러 개로 나뉠 수 있다.

핵심 엔터티(Kernal Entity)

핵심 엔터티는 업무 영역 내에서 관리하고자 하는 데이터 집합으로 두 개 이상의 속성과 두 개 이상의 데이터 인스턴스를 가져야 하며 각각의 인스턴스는 개별적, 동질적, 독립적인 데이터 집합이며 영속적으로 존재하는 데이터 단위이다. 키(Key) 엔터티, 메인(Main) 엔터티인 핵심 엔터티는 업무의 근간이 되고 수많은 자식(업무, 트랜잭션) 엔터티를 만들 수 있는 상위 개념의 엔터티이다. 다음과 같은 기준에 따라 관리되어야 한다.

집합성

엔터티는 두 개 이상의 속성과 두 개 이상의 데이터 인스턴스를 갖는 데이터의 집합이어야 한다.

식별성

엔터티는 하나 이상의 속성으로 엔터티의 각 데이터 인스턴스를 유일하게 구분할 수 있어야 한다.

영속성

엔터티는 업무의 활동 주기에 따라 영속적으로 존재해야 하는 데이터 집합이다. 즉, 업무의 내용이달라질 때 사라지거나 생성되어야 하는 데이터 집합은 엔터티로 선언하고 관리하기에 부적절하다.

사용성

엔터티는 업무 범위 내에서 반드시 사용되어야 하는 데이터 집합이다.선언은 되었으나 사용되지 않는다면 엔터티로서의 존재 가치가 없다.

관계성

엔터티는 반드시 다른 엔터티와의 관계가 존재해야 한다. 관계가 없는 엔터티는 사용되지 않는 엔터티일 수 있으므로 사용성에 위배된다.

엔터티는 업무의 문서, 장표, 인터뷰, 관련 전문서적, 데이터 흐름도(Data Flow Diagram), 타시스템, 보고서, 현장 조사로부터 수집될 수 있다. 엔터티는 논리적인 단위로 정확히 분할하여 선언하되 하나의 엔터티가 의미상으로 다르게 보인다고 해서 중복되게 선언해서는 안된다.

이는 매우 중요 한 사항이다. 즉, 하나의 엔터티가 상태에 따라 다르게 보인다면 데이터의 동질성을 파악하여 서브타입으로 하나의 엔터티로 선언할 수 있는지 확인해야 한다.

핵심 관계

핵심 관계는 핵심 엔터티 간의 논리적인 관계를 나타낸 것으로 엔터티의 존재 형태나 상호 영향을 주는 비즈니스 규칙과 현재나 가까운 장래에 유용한 관계를 한정적으로 표현하며, 관계 명칭과 선택 사양과 관계 형태(Degree)를 갖는다. 관계형 데이터 모델에서 엔터티 간에는 반드시 관계가 존재해 야 한다. 핵심 관계는 개념 데이터 모델 단계에서 M:M 관계를 그대로 유지할 수도 있고, M:M 관계 가 해소된 엔터티를 포함할 수도 있다. 핵심 관계는 부모와 자식 간의 관계명을 반드시 정의하여야 하며, 다음과 같은 기준에 따라 관리되어야 한다.

선택성

관계는 ‘필수’와 ‘선택’을 구별하여 표현할 수 있어야 한다.

형태성

관계에는 1:1, 1:M, M:M의 형태가 정의되고 관리되어야 한다.

업무 지향성

관계는 두 엔터티 간의 존재가 상호 어떤 영향을 미치는가를 명확히 표현할 수 있어야 한다. 즉, 자 식 엔터티의 인스턴스 존재는 반드시 부모 인스턴스의 존재를 필요로 하지만 부모 인스턴스의 존 재는 자식 인스턴스의 존재에 영향을 받지 않는다면 관계는 이와 같은 부모와 자식 엔터티 간의 존 재 영향에 대하여 명확히 표현할 수 있어야 한다.

관계명은 구체적이어야 하며 엔터티 간의 주는 쪽(부모)과 받는 쪽(자식)의 관계가 명확해야 한다. 또한 반드시 관계를 갖는 데이터가 있어야 하는 경우와 관계를 갖는 대상 데이터가 없어도 되는 경우 에 대한 선택성이 있어야 한다. 하나의 데이터와 하나 이상의 데이터에 대한 관계의 형태도 명확히 표현할 수 있어야 한다.