개념 데이터 모델링 - 개념 데이터 모델 작성

개념 데이터 모델의 구성 요소

개념 데이터 모델은 핵심 엔터티(키엔터티, 메인엔터티)와 핵심 엔터티 사이의 관계 도출을 통해 핵심 구조라 할 수 있는 데이터 모델의 골격을 정의한 것이다. 이것은 데이터 아키텍처 상에서 개괄 데이터 모델로부터 업무 요건을 충족하기 위해서 데이터 주제영역별로 상세화하여 핵심 엔터티들을 도출하고 관계를 정의함으로써 생성되기도 하고, 수집된 엔터티 후보들을 검토하고 분류하여 핵심 엔터티들을 도출하고 이들 간의 관계를 정의함으로써 생성되기도 한다. 주제영역별로 작성된 개념 데이터 모델을 전사 영역으로 확장하여 하나의 개념 데이터 모델로 작성한 것을 전사 개념 데이터 모델(Enterprise Conceptual Data Model) 또는 확장 개념 데이터 모델(Extended Conceptual Data Model)로 부르기도 한다. 전사 개념 데이터 모델에서는 전사 관점의 핵심 엔터티와 관계를 통해 전사적인 핵심 데이터 구조를 정의한다.



개념 데이터 모델은 시스템에 대한 사용자의 요구사항을 정형화된 모델로 표현함으로써 사용자가 요구하는 데이터의 범위 및 구조를 용이하게 확인할 수 있고, 사용자의 요구 사항을 사용자와 함께 검토하여 신규 시스템에 해당 요구사항을 반영할지 여부를 결정하여 개발범위를 정하는데도 도움을 준다. 또한 개괄 데이터 모델 및 전사 개념 데이터 모델과의 불일치가 발생하지 않도록 데이터의 골격을 유지하고 향후의 논리 및 물리 데이터 모델과의 구조적 정렬(얼라인먼트)을 지원한다.

개념 데이터 모델은 주요 핵심 엔터티와 이들 간의 관계 정의 위주로 구성하여 데이터의 전체적인 골격을 파악하는 것이 목적이기 때문에, 작성된 개념 데이터 모델 상에서는 속성 표현이 불필요할 수있다. 그러나 개념 데이터 모델을 구성하는 핵심 엔터티들이 데이터의 발생 기원 측면에서 상위 수준에 해당하기 때문에, 전체 데이터 구성에 대한 이해를 돕기 위해 향후에 이들이 세분화되거나 자식으로 탄생될 수 있는 하위 엔터티나 부가적인 엔터티들을 속성이나 서브타입 형태로 표현하는 경우도 있다. 드물지만 때로는 엔터티를 이해하는데 도움을 주거나 해당 엔터티의 속성으로 명백한 일부 핵심 속성이 함께 도출되기도 한다. [그림 4-2-41]과 [그림 4-2-42]는 각각 바커 표기법과 IE 표기법에 따라 작성한 개념 데이터 모델의 사례이다.

개념 데이터 모델 미작성시 영향

- 개괄 데이터 모델 및 전사 개념 데이터 모델과의 불일치 사항이 발생할 수 있다.
- 논리 및 물리 데이터 모델 작성 시 사용자 요구사항 반영이 누락되거나 잘 못 반영될 수 있다.
- 주제영역 간 혹은 업무 간 데이터 연관에 있어 범위가 불명확해져 오류가 발생할 수 있다.

개념 데이터 모델의 작성이 불필요한 경우

- 개념 데이터 모델은 반드시 작성하는 것을 원칙으로 하는 것이 바람직하지만, 시스템의 특성이 대체적으로 연산- 처리 중심이거나 업무에 연관된 데이터를 저장하지 않는 경우는 생략할 수 있다.

개념 데이터 모델의 작성 방법

개괄 데이터 모델로부터 상세화하는 경우

- 개괄 데이터 모델 또는 전사 개념 데이터 모델로부터 개념 데이터 모델을 작성할 단위 주제영역을 결정한다.
- 도출된 핵심 엔터티를 주제영역과 매핑한다.
- 주제영역별로 해당 엔터티들 간의 관계를 정의하여 개념 데이터 모델을 작성한다.
- 개념 데이터 모델을 상위 수준의 어플리케이션 모델이나 프로세스 모델과 비교하여 검증한다.

수집된 엔터티 후보로부터 작성하는 경우

- 수집된 엔터티 후보들을 검토하고 분류하여 핵심 엔터티를 도출한다.
- 수집된 엔터티 후보들과 핵심 엔터티들을 분류하여 데이터 주제영역을 정의한다.
- 데이터 주제영역별로 해당하는 핵심 엔티티들을 배치하고 이들 간의 관계를 정의하여 개념 데 이터 모델을 작성한다.
- 개념 데이터 모델을 상위 수준의 어플리케이션 모델이나 프로세스 모델과 비교하여 검증한다.

현행 데이터 리버스를 통해 작성하는 경우

- 현행 물리 데이터 모델을 생성하고 상세화 및 논리화를 거쳐 현행 논리 데이터 모델을 작성한 다.
- 현행 논리 데이터 모델의 엔터티들을 분류하여 핵심 엔터티를 도출하고 현행 데이터 주제영역 에 매핑한다.
- 현행 논리 데이터 모델로부터 현행 핵심 엔터티 간의 관계를 정의하여 현행 개념 데이터 모델을 작성한다.
- 사용자 요구사항이나 현행 시스템 분석 결과 또는 선진 사례 등을 검토하여 개선 사항을 반영함 으로써 현행 개념 데이터 모델로부터 목표 개념 데이터 모델을 생성한다.
- 목표 개념 데이터 모델을 상위 수준의 어플리케이션 모델이나 프로세스 모델과 비교하여 검증 한다.

발췌 - DB GUIDE.NET

[DAP, DAsP] 개념 데이터 모델링 - 관계(Relationship) 정의

[DAP, DAsP] 개념 데이터 모델링 - 관계(Relationship) 

관계(Relationship)란 ?

관계(Relationship)란 엔터티와 엔터티 사이의 관계(關係)를 말한다. 즉, 관리하고자 하는 업무 영역 내의 특정한 두 개의 엔터티 사이에 존재하는 많은 관계 중 특별히 관리하고자 하는 직접적인 관계(업무적 연관성)를 의미한다.


관계 이해

관계도 집합이다

관계는 두 엔터티 사이에 그 목적과 내용이 다른 여러 개의 관계가 동시에 존재할 수 있다. 마치 교통량이 너무 많거나 좀더 나은 이동을 위해 특수 목적을 가진 더 세분화된 교량을 추가할 수도 있고, 작은 교량을 없애고 커다란 교량으로 통합할 수도 있듯이 관계 또한 크게 묶을 수도 있고, 구체적으로 분할시킬 수도 있다.


직접 관계를 관계라고 한다

데이터 모델링에서의 데이터 집합(엔터티) 간에는 무수한 관계가 존재한다. 하지만 이러한 모든 관계를 표현(설계)하는 것은 아니다. 많은 관계 중에서 직접 종속인 것만을 관계로 보고 모델링하는 것이다.

두 엔터티 간에는 하나 이상의 관계가 존재할 수 있다

두 개의 엔터티 사이에는 서로 다른 업무 규칙을 가진 별개의 관계가 존재 할 수 있다.


보험계약과 고객과의 관계는 [그림 4-2-20]에서 볼 수 있듯이 계약자 관계는 1:M이지만 피보험자 관계는 M:M이 될 수 있다. 물론 명의 변경을 할 수도 있고 그 이력까지 관리하겠다고 한다면, 계약자 관계도 다시 M:M이 된다. 보험 종류에 따라 하나의 보험계약에 여러 명의 고객이 피보험자가 될 수 있으며, 고객 또한 하나 이상의 보험계약에 피보험자가 될 수 있으므로 이 관계는 당연히 M:M 관계를 가진다.

외래키로 정의

관계는 외래키(FK, Foreign Key)로 구현되어 참조 무결성(RI, Referential Integrity)으로 데이터 정합성 유지의 역할을 하게 된다.

관계의 관점

- 항상 두 엔터티 간에 존재한다.
- 항상 두개의 관점을 가지고 있다.
- 데이터의 양방향 업무 규칙(Business Rule)을 표현
- 관계를 통하여 정보로서의 활용가치 상승
- 외래키로 구현되어 참조무결성으로 데이터의 정합성 유지
- 참조무결성

관계표현

관계 형태(Degree/Cardinality)

1) 하나 이상(Many)

[그림 4-2-21]에 있는 까마귀 발가락처럼 표시된 모양은 하나 이상(Many)을 나타낸다. 하나 이상이란 반드시 하나 이상이 되어야 한다는 것이 아니라 하나 이상인 것이 적어도 한가지는 존재하고 있다는 것을 의미한다. 이 말은 1:M의 관계에는 1:1의 관계가 포함되어 있다는 것을 의미하고 있다. 나중에 우리가 관계 형태를 규명할 때도 하나 이상인 경우가 한가지라도 있는지에 대해 집중적으로 검토함으로써 이 관계를 밝혀내게 된다.

2)단 하나(Only One)

[그림 4-2-21] 우측에 있는 수평선은 단 하나임을 의미한다. 여기서 수평선이란 직선이 될 수도 있고 점선으로 표현될 수도 있으며 이것은 다음에 설명할 선택 사양에 따라 결정된다. 단 하나뿐임을 규명하는 것 또한 하나 이상인 경우가 하나라도 존재하는지를 검토함으로써 밝혀 낼 수 있다.


선택 사양(Optionality)

직선은 반드시 존재해야 함을 의미하고, 점선은 존재하지 않을 수도 있음을 의미한다.

1) 일반적인 형태

주로 참조하는 엔터티(M쪽)는 참조되는 엔터티(1쪽)가 반드시 존재해야 하는 경우가 많이 나타난다. 반대로 1쪽 엔터티는 M쪽 엔터티와 반드시 관계를 맺지 않아도 되는 경우가 가장 일반적인 형태라고 할 수 있다. 일반적이란 말은 이러한 경우가 가장 많이 나타난다는 것이지 항상 그러해야 한다는 것을 말하는 것은 아니다.

2)바람직한 형태

우리는 모델링에서 가능한 직선 관계를 가지도록 - 특히 자식 쪽에서 - 노력해야 한다. 즉, M쪽 관계의 선택사양을 직선관계로 만들려고 노력해야 한다. 부모 엔터티에 개체가 존재하지 않는 자식 엔터티의 개체가 많이 발생한다면 정보의 정합성에 많은 문제점이 나타나게 된다.

관계명

1) 두 개의 관계 멤버십에 각각 부여

- 각자 상대방 입장에서의 관계명을 기술한다.

2) 현업에서 사용하는 간결한 동사형으로 표현

두 엔티티 타입 간의 업무적 연관성을 나타내는 이름 부여
현재 시제를 사용
다른 관계명과의 유일성은 확보되지 못함
능동/수동형의 사용은 가급적 배제



3)업무적 의미가 없거나 애매모호한 용어는 배제

예: ∼(관계가)있다, ∼(관련이)있다, ∼이다, ∼한다 등

관계 정의 방법

먼저 한쪽 엔터티를 기준으로 상대 엔터티와의 관계를 규명하고 다시 반대 방향으로 관계를 규명 한다. 관계를 규명할 때 가장 먼저 해야 할 일이다.

관계 구문 이해

관계를 규명할 때 사용하는 관계 구문(Relationship Syntax)은 다음과 같은 전형적인 형태를 가진다.



위의 관계 부분을 설명하면 다음과 같다.

엔터티1

관계를 규명할 두 엔터티 중에서 어느 한쪽이 주어가 되어 상대방과의 관계를 규명하고자 할 때 주어가 되는 엔터티

임의의

영어적 표현이라면‘ANY’와 같다고 이해하면 된다. 따라서 ‘임의의’란 결국 ‘모든’과 같은 뜻이라 하겠다. 즉, 집합 내의 개체 중에서 아무것이나 하나(임의의 개체)를 선택하여 만족하는지 증명하는 것이다.

하나는

주어 집합에 있는 ‘임의의’ 나 ‘하나’의 개체를 말한다. 이 하나가 어떤 형태로 상대방과의 관계를 가지는지를 검증한다.

관계 형태

하나가 몇 개의 상대방을 가질 수 있는지를 집중적으로 밝히는 것이다. 여기에서 단 하나인 것을 증명하기 위해서 하나만 가지는 경우를 수없이 내세우는 것보다 하나 이상인 경우를 한 가지만 제시하는 것이 보편적인 방법이다.

엔터티2

주어가 되는 엔터티가 바라 본 상대방 엔터티이다.

관계명

관계 규명을 통해서 정의된 관계 명칭이다.

선택 사양

필수(실선), 선택(점선)의 모습을 결정하는 과정이다. 여기서‘반드시 관계명이어야 한다’와‘관계명일 수도 있다’를 결정하기 위해서는 관계명을 만족하는 경우를 아무리 많이 제시하더라도 없을 수도 있다는 한 가지 경우만 예를 들면 결정할 수 있다.

관계 정의 절차

[그림 4-2-24]는 어디에서나 접할 수 있는 사원과 부서 엔터티 간의 관계를 정의한 모습이다.



[그림 4-2-24]와 같이 두 집합 간의 관계는 두 집합 각각의 관점에서 바라 본 관계가 궁극적으로는 합성된 형태가 완성된 관계가 된다. 이 관계에 대해서 각각의 관점에서 생각하고 판단해야 할 사항은 예를 들면 다음과 같다.

1) 사원을 주어로 부서를 보는 관계에서 판단해야 할 사항 예제

사원 엔터티의 임의의 한 개체(사원 한 사람)가 상대인 부서 엔터티에 단 하나의 개체(부서 하나)에만 소속되는지, 아니면 하나 이상에 소속될 수 있는지 판단한다.
지금까지 소속되었던 모든 부서를 찾고자 하는 것인지, 아니면 현재 소속되어 있는 부서만 찾고자 하는지를 판단한다.
겸임(兼任)을 하는 사원(주로 관리자)에 대한 처리 방안을 판단한다.
현재 소속을 가지지 않는 사원이 단 한 명이라도 있는지를 판단한다.
사원 엔터티가 우리 회사에 적을 두고 있는 사람만이 아니라 관계사나 협력사에서 파견되어 근무하는 사람들까지 포함된 집합인지를 판단한다.


2) 부서를 주어로 사원을 보는 관계에서 판단해야 할 사항 예제

하나 이상의 사원을 가지는 부서가 있을 수 있는지를 판단한다.
부서가 사원을 반드시 가져야 하는지, 그렇게 하지 않을 수도 있는지에 대해 판단한다.
최종적인 관계는 임의의 부서는 하나 이상의 사원을 현 주소속 부서로서 배치 받을 수도 있다로 결정한다.
[그림 4-2-26] 바커 표기법(위)과 IE 표기법(아래)에 따른 부서 주어 관계 예


관계 형태

관계의 형태는 크게 1:1, M:1, M:M의 세 가지로 나눌 수 있다. 물론 선택 사양까지 결합하면 훨씬 많은 형태가 나타나지만 형태로만 나눈다면 이렇게 세 가지로 분류할 수 있다. 각각의 형태들은 고유한 특징을 가지고 있으며, 각자 가장 흔하게 발생하는 기본 형태(Default Style)를 가지고 있다.

1:1 관계(Relationship)

1:1 관계란 어느 쪽 당사자의 입장에서 상대를 보더라도 반드시 단 하나씩과 관계를 가지는 것을 말한다.

1) 특징

현실에서 매우 드물게 나타나는 형태
업무의 흐름에 따라 데이터가 설계된 형태에서 많이 나타남.
엔터티 수직 분할시에 많이 나타남.

2)필수-선택 형태

한쪽은 실선이고 다른 쪽은 점선이 되는 모습이다. 좌측에 있는 엔터티의 개체는 대응되는 우측 엔터티의 개체가 반드시 존재해야 하지만 우측 엔터티의 개체와 대응되는 좌측 엔터티의 개체는 없을 수도 있다는 것이다.


좌측의 Personal Computer가 조립되기 위해서는 반드시 단 하나씩의 Mother Board를 가져야 한다. 그러나 Mother Board는 아직 조립에 사용되지 않은 것이 존재할 수 있으므로 위와 같은 관계가 나타난다.

3) 필수-필수 형태

양쪽 모두 실선인 모습이다. 이 관계를 수학적으로 풀어보면 두 엔터티는 같은 엔터티라는 것이 증명된다. 수학에서 사용하는 필요충분조건은 P ⇒ Q이고, Q ⇒ P이면, P ⇔ Q 라는 법칙이다. 이것은 서로 필요충분조건을 만족하면 두 개는 서로 동치(同値)라는 것을 의미한다.
대부분의 경우가 데이터 양을 감안하여 수직분할을 한 경우가 대부분이다. 하지만 이러한 데이터들은 논리적 관점에서 보면 하나의 데이터 집합이라고 볼 수 있다.

4)선택-선택 형태

바커표기법에서는 양쪽 모두가 점선인 모습으로, IE표기법에서는 양쪽 끝에 모두 타원(oval)이 나타나는 모습의 관계로서 자주 발생되지 않는 형태이다.
[그림 4-2-28]에서 좌측 3개의 엔터티는 서로 1:1 관계를 가지고 있지만 서로 존재할 수도, 존재하지 않을 수도 있는 형태이다. 이것을 만약 나중에 그대로 테이블로 설계한다면 전체 집합(1,2,3,4)을 찾기 위해서는 항상 합집합을 만들어야 한다.


M:1 관계(Relationship)

M:1 관계는 가장 흔하게 나타나는 매우 일반적인 형태라 할 수 있다. 이는 마치 부모와 자식과의 관계처럼 계층적인 구조로 이해해도 좋다.

1)특징

가장 흔하게 나타나는 관계의 형태이다.
내가 참조할(부모쪽) 정보는 나에 대해서 반드시 하나만 존재해야만 참조(join)할 때 내 집합에 변화가 생기지 않으므로 내가 참조하는 엔터티는 반드시 1쪽이 될 수 밖에 없다.
M:1 관계는 한쪽은 M(many)이고 다른 한쪽은 1(one)인 것을 말한다. 이 관계의 가장 일반적인 선택 사양의 모습은 [그림 4-2-29]와 같이 참조하는 쪽(M)은 실선(바커표기법)이거나 타원(oval)을 갖는 형태(IE표기법)이고 참조되는 쪽(I)은 점선(바커표기법)이거나 타원(oval)이 없는 형태로 나타낸다.
[그림 4-2-29]와 같이 참조하는 쪽(M)은 실선이 되도록(바커표기법)하거나 타원이 포함되도록 (IE표기법) 하는 것이 바람직하며, 반대로 참조되는 쪽(I)은 점선이 되도록(바커표기법) 하거나 타원이 없는 형태가 되도록(IE표기법) 하는 것이 좋은 모양이다.

2)One to many relationship (Both Side Mandatory)

현실 세계에서 그리 많은 경우는 아니지만 가끔 발생하는 형태이다.
주문과 주문 아이템의 관계에서 하나의 주문이 여러 개의 아이템을 포함하고 있는 경우, 주문 아이템이 없는 주문은 업무적으로 의미가 없고 마찬가지로 주문이 없는 주문 아이템도 의미가 없다.

3)One to many relationship (One Optional)

현실 세계에서 가장 흔한 형태이다.
부서와 사원 간의 관계에서 모든 사원은 반드시 하나의 부서에 소속되어야 한다. 하지만 사원이 하나도 없는(신생) 부서도 존재할 수 있다.


4) One to many relationship (Many Optional)

one to many 관계에서 현실적으로 드문 형태.
[그림 4-2-30]의 예는 여러 번의 납품 건에 대해서 한번에 모아 대금 청구를 하는 경우이다. 즉 선 납품 후 대금 청구하는 계약 조건에서 아직 대금이 청구되지 않는 납품 건은 청구번호가 정해지지 않은 경우이다.



5) One to many relationship (Both Side Optional)

이 또한 현실 세계에서 흔한 형태 중의 하나.
관계의 선택성(Optional)이 증가할수록 모델의 모호성도 증가하므로 될 수 있으면 선택성을 해소해야 한다.

M:M 관계(Relationship)

1) 특징

M:M 관계는 관계를 가진 양쪽 당사자 모두에서 1:M 관계가 존재할 때 나타나는 모습이다.
M:M관계의 선택 사양은 양쪽 모두가 선택적(바커표기법에서는 점선으로, IE표기법에서는 실선의 M:M형태)인 것이 기본형이다.

M:M 관계는 의외로 아주 빈번하게 발생되는 관계이다. 그러나 데이터 모델링이 완료된 후에 M:M은 존재하지 않는다. 이 말은 M:M 관계가 아직 덜 풀려진 형태라는 것을 의미한다.
M:M 관계는 관계가 해소되면서 새로운 엔터티(Relation Entity/Intersection Entity)를 생성시킨다. [그림 4-2-32]와 같이 새로 생성된 릴레이션 엔터티와 기존 엔터티 사이에는 1:M 관계로 분해된 새로운 관계가 나타난다. M:M 관계를 분해했을 때 항상 1:M 관계로 분해되는 것은 아니다. [그림 4-2-33]의 상품과 주문 사이의 M:M 관계와 같이 때때로 덜 분해된 M:M 관계가 사이에 나타날 수도 있다. 이 경우 앞의 작업과 동일하게 분해 작업을 수행하여 M:M 관계가 완전히 해소될 때까지 관계를 분해해야 한다.

다중 관계 처리

1) 특징

다중 관계란 어떤 두 엔터티의 사이에 하나 이상의 관계를 가지고 있는 상태를 말한다. 서로 다른 엔터티 사이에도 경우에 따라 얼마든지 하나 이상의 다양한 관계가 존재할 수 있다. 관계도 집합이기 때문에 내용을 엄격하게 구분하여 여러 개의 관계로 정의할 수도 있고, 크게 묶어서 한두 개로 정의할 수도 있다. 묶거나 분리한다는 입장에서 보면 앞에서 설명한 관계의 통합, 분할과 비슷하게 보일 수도 있지만 엄연히 다른 개념이다.



[그림 4-2-34]에 있는 공사(工事) 엔터티는 말 그대로 회사 내에서 일어나는 각종 토목이나 건축물을 구축하거나 보수하는 작업을 말한다. 이러한 작업에는 실제 공사의 수행을 담당하는 부서(예를들면, 공무1과)와 투입된 비용에 대한 손익 처리(원가배정 부서)의 대상이 되어야 할 부서가 있을 것이다. 또 그 공사의 진행을 감독하는 부서도 관리할 수 있을 것이다. 가령, 생산1과가 관장하는 공정의 설비 개선 공사를 공무1과가 담당하고, 공무관리과에서 공사를 감독한다면 손익 부서는 생산1과, 공사담당부서는 공무1과, 감독 부서는 공무관리과가 될 것이다. 우리가 관리해야 할 이런 관계를 [그림 4-2-34]의 상단에 있는 것처럼 여러 개의 관계로 나누어 관리하는 것을 병렬식이라고 하고, 하단에서처럼 하나로 묶어서 관리하는 것을 직렬식 관계라고 부른다.

2) 병렬식 관계

병렬식이란 말 그대로 두 엔터티 사이에 존재하는 관계들을 별도의 관계로 간주함으로써 여러개의 관계 선분이 나란히 병렬로 관계가 맺어지게 되는 경우이다.



병렬식으로 결정한다는 것은 [그림 4-2-35]와 같이 계약자, 피보험자, 수익자 등을 별도의 관 계로 정의하겠다는 의미다. [그림 4-2-35]의 하단은 이렇게 정의했을 때 나중에 테이블의 구조 (관계형 데이터베이스로 설계 시)가 나타나는 모습을 보여주고 있다.

3) 병렬식 관계 특징

가) 테이블이 될 때 여러 개의 칼럼으로 나열된다.

물리 데이터 모델에서 테이블로 변환할 때 이러한 관계는 여러 개의 칼럼으로 생성되어진다.

나) 하나의 로우(row)에서 관리되므로 새로운 테이블을 추가할 필요가 없다.

나열된 모든 관계가 결국에는 모두 외래키 칼럼이 되어서 같은 로우에 펼쳐지게 되므로 이들을 위하여 새로운 테이블이 추가될 필요가 없다는 것이다. 이 말은 다시 말하면 이렇게 관리하는 방법은 기존 집합에 변화가 발생하지 않는다는 것이다. 이 특징이 바로 다음에 설명할 직렬식과 가장 큰 차이라고 할 수도 있겠다. 직렬식은 관계를 관리하기 위한 전용 엔터티(즉, 릴레이션 엔터티)를 가짐으로써 변화에 대한 유연성은 크게 증가하지만 새로운 엔터티를 추가해야 하고, 관계의 형태가 나빠진다 - M:M이 발생한다 - 는 단점이 있다.

다) 인덱스 수가 증가되고 SQL이 복잡해진다.

각각의 관계가 여러 개의 독립적인 칼럼으로 나타나기 때문에 이들이 검색 조건에 사용된다면 이들 모두에게 별도의 인덱스가 존재해야만 한다. 만약 [그림 4-2-33]에 있는 피보험자 관계처럼 동질성이 강함에도 불구하고 병렬식으로 정의했다면 피보험자의 고객 정보들을 참조하고자 할 때마다 나열된 각각에 대해 동일한 액세스를 해야 한다. 뿐만 아니라 만약 단 한 곳에라도 인덱스가 없다면 모두 없는 것이나 다름없는 매우 심각한 일이 발생한다. 이들이 혼자로서는 분포도가 너무 나빠 다른 칼럼과 결합 인덱스를 만들어야 한다면 각각에 대해서도 모두 동일하게 결합해 주어야 하기 때문에 상황에 따라서는 매우 심각한 일이 발생할 수도 있다.

라) 새로운 관계의 추가, 관계 형태의 변경 등에 매우 취약한 형태이다.
업무의 변화가 테이블이나 칼럼에 영향을 주지 않고, 데이터의 변화로 나타난다면 유연성은 크게 향상된다. 
특히 관계형 데이터베이스에서 사용하는 SQL에서는 테이블이나 칼럼을 변수로 하는 것이 불가능하다. 물론 다이나믹 SQL을 사용하면 마치 변수로 처리할 수 있는 것처럼 보이지만 사실은 그렇지 않다. 비록 겉모양은 그렇게 하였더라도 DBMS로 날라오기 전에 바인딩(Binding)을 하여 최종적으로는 이들 변수를 없애기 때문에 결국 DBMS는 변수로 이들을 처리하지 않는다.
좀 더 정확하게 말한다면 DBMS는 이들을 변수로 해서는 처리가 불가능하다는 것이 옳은 표현이다. DBMS는 데이터 사전을 이용하여 사용자 SQL을 해석하고 실행 계획을 수립해야 한다. 그러나 근거가 될 테이블과 칼럼이 변수로 지정되어 그 값을 알지 못한다면 아무것도 참조할 수 없게 된다. 이런 이유로 인해 테이블이 추가된다거나 새로운 칼럼이 추가되어 기존의 처리에 영향을 미친다면 반드시 SQL은 수정되어야만 한다. 즉, 업무의 변화로 인해 데이터 모델에 변화가 발생했을 때 많은 애플리케이션을 수정해야 하므로 유연성이 크게 나빠질 수밖에 없는 것이다.
이런 의미에서 병렬식은 직렬식에 비해 유연성이 훨씬 부족하다. 병렬식은 새로운 관계가 추가되면 결국 새로운 칼럼(외래키)이 추가되어야 하고, 관련된 애플리케이션이 수정되어야 하지만 직렬식에서는 거의 변화가 일어나지 않는다.

마) 관계 내용별로 상세 정보를 관리할 수 없다.

병렬식으로 나열된 관계는 기존의 집합을 유지하도록 하는 장점이 있지만, 이들이 칼럼으로 나 열됨으로써 나중에라도 각자에 대한 상세한 정보를 관리할 자식 엔터티를 가질 수 있는 길이 원천적으로 봉쇄된다는 매우 중요한 제한 요소를 가지고 있음을 잊어서는 안된다.
[그림 4-2-36] 상단의 A, B, C는 병렬식 관리로 인해 옆으로 나열된 속성이다. 이 속성에 대해 좀 더 상세한 정보를 관리해야 할 일이 생겨서 그림 하단에 있는 새로운 엔터티를 추가하게 되었다.




4) 직렬식 관계

두 엔터티 사이에 존재하는 몇 개의 관계를 모아 상위 개념으로 통합함으로써 하나의 관계로 관리하는 방법이다. 이 방법은 여러 가지의 관계를 하나로 통합했기 때문에 관계의 명칭 또한 당연히 상향으로 조정되어야 한다.

[그림 4-2-37]은 앞서 병렬로 정의된 여러 관계를 모두 묶어‘보험계약관련자’라는 명칭의 관계로 통합한 모양이다. 여러 개의 M:1 관계를 통합하면 당연히 M:M 관계가 된다. 이 관계를 해소하면 보험계약관련자란 관계 엔터티가 탄생한다. 이때 각각의 관계들이 서로 섞이지 않도록 하기위하여 서브타입을 사용하였다.




5)직렬식 관계의 특징

가) 관계들을 관리하는 새로운 엔터티가 추가되어야 한다.

M:M 관계를 해소시켜 관계 엔터티를 생성하는 것을 말하는 것이다. 이 방법은 앞으로 설명할 양호한 유연성을 얻는 대가로 새로운 엔터티가 추가되는 비용이 발생한다. 물론 특별하게 관리할 가치가 있다면 얼마간의 비용이 발생하더라도 그렇게 관리해야 한다는 것에는 이론의 여지가 없다.

나) 관계들이 로우(Rows) 형태로 나타난다.

칼럼의 나열로 나타나는 병렬식과 크게 대비되는 모습이다. 앞서 유연성을 얻고 싶다면 업무의 변화를 엔터티나 속성의 변화로 만들지 말고, 데이터를 증가하게 만들어야 한다고 했었다. 직렬식은 계약자, 피보험자 등등 아무리 많아지고, 변경이 발생하더라도 새로운 로우들이 만들어지거나 수정됨으로써 쉽게 해결되기 때문에 유연성이 높아지는 것은 당연하다.

다) 인덱스 수가 감소하고 SQL이 단순해진다.

향후 물리 데이터 모델링, 데이터베이스 디자인 과정에서 생성할 인덱스 전략에 영향을 미친다. 즉, 병렬식인 경우와 반대로 생각하면 쉽게 이해할 수 있다. 만약, 병렬식으로 설계되었다면 많은 관계들이 다수의 칼럼(계약고객번호, 주피보험자고객번호 …)이 되었으므로 칼럼마다 인덱스가 필요해진다. 하지만 직렬식으로 되어 있는 보험계약관련자 엔터티에는 고객번호 칼럼이 하나밖에 존재하지 않으므로 당연히 고객번호에 대한 인덱스는 하나만 있어도 충분하다.

라) 새로운 관계의 추가, 관계 형태의 변경 등에 매우 유연한 형태이다.

직렬식 관계는 엔터티의 형태를 특별한 목적으로 보강하는 것 즉, 구조 변화에 대해서도 유연성을 가지고 있으므로 병렬식에 비해 유연성의 차이는 매우 크다는 것을 인정하지 않을 수 없다. 그렇기 때문에 대부분은 직렬식으로 하는 것이 바람직하다고 할 수 있다. 그렇다고 해서 앞서 소개한 공사와 부서간의 관계처럼 관리할 관계가 분명하고 내용이 독립적인 경우까지 무조건 그렇게 해야 한다는 뜻은 아니므로 오해하지 말기 바란다.

마) 관계 내용별로 상세 정보를 관리할 수 있다(자식 엔터티를 거느릴 수 있다).

모든 관계들이 관계 엔터티에서 별개의 개체로 관리되고 있으므로 이들이 자식 엔터티를 거느릴 수 있다

특수한 형태 관계

1) 순환 관계 ( Recursive Relationship )

하나의 엔터티가 다른 엔터티가 아닌 자기 자신과 관계를 맺는 관계를 순환 관계(Recursive Relationship)라고 한다. 이와 같은 순환 관계를 표현한 모델을 순환 구조 모델 또는 순환 모델이라고 하며, [그림 4-2-38]의 좌측에 표현된 조직 구조와 같은 계층 구조를 표현하는 데 유용하다.


순환 관계는 다음과 같은 특징을 가지고 있다.

- 하나의 순환 엔터티는 각 엔터티의 모든 속성을 포함해야 한다.
- 각 계층에 있는 속성은 동일하게 하는 것이 가장 좋다.
- 순환 모델은 필수(직선) 관계로 취급될 수 없고(무한 LOOP 발생), 반드시 선택사양 관계이다.
- 순환 모델의 특징은 조직의 변경(추가/삭제)에 쉽게 대응할 수 있다는 것이다.

2) BOM(Bill of Materials) 관계

BOM 관계의 모델을 네트워크 구조(전철 노선이나 하이퍼링크를 갖는 웹 도큐먼트 같은)라 한다. 이러한 네트워크 구조를 제조업에서 [그림 4-2-39]와 같이 부품의 소요량 파악 등의 모델에 유용하게 이용하게 되면서 M:M 순환 구조는 BOM(Bill of Material) 모델이라 알려지게 되었다.



BOM 모델은 M:M 순환 관계라 하며, 상세 모델링 과정에서 새로운 관계 엔터티(Relation Entity, Intersection Entity)를 추가하여 두 개의 일대다(1:M) 관계로 구성된 모델로 구체화된다.

3) Arc (Mutually Exclusive) 관계

어떤 엔터티가 두 개 이상의 다른 엔터티의 합집합과 관계를 가지는 것을 배타적(Exclusive) 관계 혹은 아크(Arc) 관계라 한다. 이러한 아크 관계는 동일한 의미의 관계가 서로 다른 하나 이상의 엔터티와 배타적으로 관계를 갖고 있을 때 이를 하나로 통합함으로써 발생하게 된다.

이러한 관계의 특징은 다음과 같다.

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

발췌 - DB GUIDE . NET

[DAP, DAsP] 개념 데이터 모델링 - 핵심 엔티티 정의

[DAP, DAsP] 개념 데이터 모델링 - 핵심 엔티티 정의

엔터티란?

엔터티란 업무 활동상 지속적인 관심을 가지고 있어야 하는 대상으로서 그 대상에 대한 데이터를 저장할 수 있고 대상들 간의 동질성을 지닌 개체 또는 행위의 집합
엔터티를 정의할 때는 어떤 대상이 그 엔터티에 속하는지 혹은 속하지 않는지를 명확하게 정의할 수 있어야 한다.

엔터티 정의의 요건

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

의미상 주어 정의
엔터티에는 인조 식별자(Artificial Unique Identifier)가 있을 수 있고, 이를 가주어(假主語)라 한다면 진주어(眞主語)에 해당하는 관계나 속성이 어딘가에 있을 수 있다. 예를 들어 신용카드의 가주어는 임의의 번호를 부여해서 만든 카드번호를 말하며, 진주어는 카드를 발급 받은 사람(고객 번호)과 발급 받은 상품(상품 코드), 그리고 발급일자가 될 것이다. 이 진주어를 의미상의 주어라고 할 수 있으며, 의미상의 주어를 모델링 입장에서 본다면 원래의 본질적인 식별자에 해당한다. 여기에서는 이것을 본질 식별자라고 칭한다.

본질 식별자 정의의 의의

모델링 진행 과정에서 본질 식별자를 특별히 중시하는 이유는 집합의 의미가 모호한 상태에서는 더 이상 객관적인 판단을 진행해 가는 것이 불가능하기 때문이다. 집합의 인스턴스가 생성되는 정확 한 단위를 모르고서는 집합이 명확해질 수 없다. 다시 말해서 집합의 의미가 명확하게 정의되지 않은 모호한 집합에 인조적인 유일한 이름만 가져다 붙인다고 해서 갑자기 집합의 정의가 명확해지지는 않는다.

본질 식별자 정의 예

신용카드 엔터티의 본질 식별자인 고객 번호와 상품 코드는 부모에게서 상속받은 관계 속성이며, 이 부모들은 바로 키 엔터티이다. 다시 말해 본질 식별자로 상속 관계를 규명해 올라갔을 때 최상위에 존재하는 것이 바로 키 엔터티라는 것이다. 여기서 주의할 것은 임의의 엔터티가 다른 엔터티와 1:M이나 1:1 관계일 때 1 쪽의 엔터티가 항상 본질 식별자가 되는 것은 아니다. 예를 들어, 사원 엔터티와 부서 엔터티는 M:1의 관계를 가지지만 사원 엔터티의 부모가 부서 엔터티는 아니다. 다시 말해 1쪽의 엔터티라고 해서 항상 본질 식별자가 되는 것은 아니다. 본질 식별자란 만약 그가 없다면 자신이 절대로 태어날 수 없을 때만 해당된다.

코드성 키 엔터티 모델링
소위 코드성 엔터티라고 부르는 엔터티를 개념적 모델링 단계에서 도출할 것인지 아니면 나중에 상세 모델링 단계의 정규화 단계에서 처리할 것인지에 대한 판단은 모델링의 효율적인 진행에 커다란 영향을 미친다. 이런 유형의 엔터티를 현 단계에서 너무 많이 도출시킨다면 모델링은 복잡성의 함정에 빠져 버릴 것이다. 반면, 꼭 필요한 것을 누락시켰다면 태어나야 할 중요한 자식 엔터티가 나타나지 않을 수도 있다. 이러한 고민을 해결하는 방법은 다음의 네 가지 기준에 따라 판단하는 것이다.

- 이 엔터티가 자식 엔터티를 가지는가?
- 이 엔터티가 자신만의 다양한 속성을 가질 것인가?
- 이 엔터티가 여러 엔터티에 관계를 가질 것인가?
- 이 엔터티가 다양한 종류의 관계를 가질 것인가?
- 자식 엔터티 유무 확인

이것은 해당 엔터티가 다른 엔터티의 본질 식별자가 되고 있는지를 찾아내는 것이다. 다시 말해서, 비록 겉모양은 볼품없이 초라하지만 만약 이 엔터티가 도출되지 않았을 때 중요한 자식 엔터티도 같이 태어날 수 없다면 반드시 미리 도출해야 한다는 것이다.

[그림 4-2-5]에 있는 엔터티를 검토해 보자. 이 그림은 어떤 생산 공장에 있는 생산에 관련된 설비를 정의한 엔터티이다. 여기에 들어 있는 개체를 크게 나누어 펌프, 탱크, 배관, 발전기, 압축기 등으로 분류했다고 하자. 이러한 분류를 모델링에서는 서브타입(Sub-type)이라고 한다. 이 분류가 그 림에서처럼 단지 설비를 분류하는 데에만 사용한다면-그것이 비록 나중에 코드화를 함으로써 별도의 엔터티로 생성된다고 하더라도-지금 단계에서 굳이 엔터티로 도출할 필요가 없다. 그 이유는 지금 엔터티로 도출한 것이나 나중에 정규화 단계에서 도출한 것이나 별차이도 없으면서 초기 단계의 복잡성만 가중시키기 때문이다.

[그림 4-2-5] 자식 엔터티 유무 확인 예

그러나 만약 설비 타입과 생산 라인별로 우리가 관리하고자 하는 공정 제어값이 있다면 이 설비타입은 분명히 부모의 역할을 하게 되므로 지금 도출해 두지 않으면 자식 엔터티도 같이 누락된다.

①속성 존재 여부 확인

해당 엔터티가 현재 혹은 미래에 단순한 코드명이나 코드의 의미에 대한 설명 외에 또 다른 속성을 가질 수 있는가를 확인해 보는 것이다. 엔터티가 이러한 속성을 가지고 있다는 것은 자기만의 확실한 사유재산이 있다는 것을 의미하므로 마땅히 독립적인 개체 집합으로서의 자격이 있다고 하겠다. 이러한 엔터티는 필연적으로 다른 엔터티와 다양한 관계를 가지게 될 것이며, 앞으로 자신을 참조하는-향후에 조인(join)이 발생하는-행위 엔터티가 분명히 발생하게 될 것이므로 미리 엔터티로 도출해 두는 것이 바람직하다.

②관계 존재 여부 확인

엔터티가 향후 다른 엔터티와 많은 관계를 가질 가능성이 있는지를 검토해 보는 것이다. 엔터티가 다양한 관계를 맺고 있다는 것은 활동성이 왕성하다는 것을 의미한다. 여기서 말하는 관계는 반드시 부모(의미상의 주어)로써의 관계만 의미하는 것이 아니라 일반적인 관계까지 모두 포함한 포괄적인 관계를 말한다. 만약 이러한 엔터티를 누락시킨다면 앞으로 우리가 정의해야 할 많은 릴레이션십들 도 같이 누락될 것이다.

집합 순수성 예

집합 순수성 의미

엔터티는 반드시 순수한 본질(本質) 집합이 되어야 한다는 것은 정의하고자 하는 집합이 사람, 상품 등과 같이 단위 사물을 정의한 개체(個體) 집합이 되든지, 아니면 이들이 어떤 활동을 함으로써 만들어진 입금, 계약 등과 같은 행위(行爲) 집합이 되든지 간에 반드시 둘 중의 어느 하나가 되어야 한다는 것이다. 그렇지 못하고 이들이 서로 결합된 형태라면 그것은 관계이다.

집합 순수성 예

납입자와 같은 단어 개체 집합이 합성되어 있음을 알 수 있다. 물론 여기서 ‘자’란 사람이나 단체와 같은 개체 집합을 의미하며, 이러한 개체가 포함될 수 있는 본질 집합은 고객과 같은 집합들이 이에 해당할 수 있다. 그렇다면 납입자란 순수 본질 집합인 고객과 납입이 결합되어 만들어진 것, 다시 말해 이것은 엔터티가 아니라 관계라는 것이다.

집합 순수성 적용 예외 사항

1) 관계의 엔터티화

관계가 엔터티로 변하는 경우이다. 관계가 M:M이 되면 더 이상 관계로만 존재할 수 없기 때문에 엔터티로 바뀌게 되며, 이를 릴레이션 엔터티라고 한다. 예를 들어 피보험자란 단어를 분석해 보면, [그림 4-2-6]에 있는 것처럼 보험 수혜자로 위촉되었다는 행위와 그 수혜자가 된 사람의 개체가 결합되어 있어 순수한 본질 집합이 아니기 때문에 관계가 분명하다.

[그림 4-2-7] 바커 표기법(좌측)과 IE 표기법(우측)으로 표현한 피보험자 모델 예

하지만, M:M 관계는 최종적으로는 관계로써 존재할 수 없기 때문에 1:M으로 연결된 교량 역할을 해주는 엔터티로 바뀌어야 한다. 이 엔터티는 관계가 변해서 생성되었기 때문에 릴레이션 엔터티(Relation Entity)라고 부른다. 방법론에 따라서 제휴 엔터티(Association Entity)나 교차 엔터티(Intersection Entity)라고 부르기도 한다.

2)일부 집합 정의

단순하게 생각하면 금융이란 말이나 수납이란 말은 모두 동일한 역할을 하는 것처럼 보인다. 그러 나 조금만 더 깊이 생각해보면 이들 간에는 아주 뚜렷한 차이가 있음을 알 수 있다. 금융은 기관이라 는 큰 집합의 특정 부분 집합을 나타내기 위해 사용된 말이다. 마치 전체 집합인 고객의 일부를 법인 고객으로 표현한 것과 같은 의미로 사용되었다. 반면, 수납기관에 사용된 수납이란 뜻은 기관의 개체 가 행하는 여러 행위 중의 하나이다. 가령 은행에서는 수납만 하는 것이 아니라 출납 행위도 한다.

[그림 4-2-8] 금융기관 모델 예

3)배타적 관계 대체

엔터티가 여러 엔터티와 동일한 내용의 관계를 갖는 배타적 관계를 가질 때 만약 배타적 관계의 변화 가능성이 높다면 이를 피하기 위해 배타적 관계에 있는 것들만 모아서 별도의 엔터티를 구성하는 경우이다. 예를 들어보자. 물건을 배달하기 위해서는 목적지가 있을 것이다.

[그림 4-2-9] 바커 표기법(위)과 IE 표기법(아래)에 따른 배송모델 예

일반적으로 이것을 배송처라고 부르는데, 이 단어를 풀어보면‘배송’이라는 행위와‘처’라는 개체 집합이 결합되어 만들어졌음을 발견할 수 있다. 이론적으로 보면 이것은 관계가 틀림없다. 여기서 먼저 ‘처’에 해당하는 원래의 집합을 찾아보면 [그림 4-2-9]와 같이 다양한 개체 집합들이 이에 해당할 것이다. 그런데 만약 업무의 변화가 심해서 배송처가 될 대상 집합이 앞으로 계속 늘어날 가능성이 높다면 필연적으로 배타적 관계 선분이 증가할 것이고, 이에 따라 애플리케이션의 처리 방법에는 빈번한 수정이 발생하게 된다. 이러한 경우라면 약간의 집합적 중복이 발생하더라도 별도의 엔터티를 생성할 필요가 있다.

집합 동질성

집합 동질성 의미

엔터티에서 동질성(同質性)을 정의한다는 것은 말 그대로 집합에 들어갈 개체들의 동일한 성질을 어디까지로 한정할 것인가를 결정하는 것을 말한다. 가령, 사원이라는 집합을 우리 회사에 공식적인 적(籍)을 두고 있는 사람들로만 정의했다면 협력회사 사원이나 관계사 직원들은 이들과 동질성을 갖지 못한다. 그러나 개념을 확장하여 우리 회사에 공식적인 적을 두고 있거나 사내 업무에 관련된 준 사원에 해당하는 사람들이라고 정의했다면 협력회사나 관계사 직원은 정규 사원과 동질성을 갖게 된다.

집합 동질성 부여의 예

고객이라는 집합의 동질성을 부여하는 두 가지 경우를 가정해 보자. 첫 번째는 고객집합에 대해 우리 회사의 상품을 구매했거나, 구매할 사람들의 집합이라고 규정했다고 가정하자. 두번째 경우는 우리 회사의 상품을 구매했거나, 구매할 가능성이 있는 모든 사람 혹은 법인·단체들의 개체집합이라고 규정했다고 가정하자.

1) 사람의 집합이라고 규정한 경우

이 경우에는 사람만의 집합이고, 우리 상품과 구체적인 관계를 맺은 사람들만 존재하는 집합으로 정의했다는 특수성이 분명히 나타나야만 한다. 이러한 구체적인 정의는 잠정 고객은 이 집합에 포함 되지 않는다는 집합적 비교를 확실하게 해 주고 법인, 금융기관 등도 전혀 동질성을 갖고 있지 않다 는 것을 분명하게 나타내고 있다

2)사람 또는 법인이라고 규정한 경우

위의 이러한 집합들을 분명하게 포함시켰다는 것을 내포하고 있다.

엔터티 명칭

엔터티에 적절한 명칭을 붙여주는 작업은 생각보다 매우 중요한 일이다. 도출한 집합의 의미에 가장 어울리는 명칭을 부여해야만 앞으로의 커뮤니케이션에서 오류를 줄일 수 있고, 제3자에게 설명할 때도 의미의 전달이 명확해질 수 있다. 사실 지금까지 명확화를 했다고 생각하는 것은 겨우 엔터티 단위일 뿐이다.

적절한 엔터티 명칭

엔터티 명칭은 그 엔터티를 함축시킨 의미를 담고 있어 남에게 일일이 설명하지 않아도 오해를 최소화시킬 수 있어야 한다.

엔터티 명칭 부여하기 예제

엔터티의 의미를 명확하게 정의하는 작업은 매우 중요한 일이며, 그에 못지 않게 적절한 명칭을 부여하는 일에도 심혈을 기울여야 한다. 적절한 엔터티 명칭을 부여하기 위한 예를 들어보자.

[그림 4-2-10] 바커 표기법(위)과 IE 표기법(아래)에 따른 적절한 엔터티명 부여 예

[그림 4-2-10]에서 좌측에 있는 교육과정이란 엔터티는 의미상으로 본다면 교육과목에 가까운 엔터티이다. 다시 말해서 이 과정이 몇 차례 강의가 개설되더라도, 혹은 아직 언제 강의를 개설할지 결정이 나지 않았더라도 과정마다 단 하나씩의 개체를 가지게 되는 키 엔터티라고 하자. 이 엔터티는 그 진행 일정과 강사가 정해지면서 여러 번에 걸쳐 강의가 진행될 것이다. 이 엔터티는 교육과정을 부모로 해서 태어난 자식에 해당하는 행위 집합이며, 그 이름을 교육일정으로 하여 생성됐다. 이 엔터티의 의미는 명확해 보이며, 그 명칭에도 큰 문제가 없어 보인다. 그러나 분명히 엔터티의 명칭에 문제가 있다. 교육일정이라고 되어 있는 엔터티의 속성을 보면 일정만 있는 것이 아니다. 교육장소· 강사 등의 일정과는 전혀 다른 속성도 있다. 그렇다면 이 집합의 개체는 교육일정이 아니라 개설된 강좌로 보는 것이 더 어울린다.

서브타입

서브타입 지정 의의

엔터티를 명확화하는 단계에서 해야 할 또 하나의 중요한 작업은 엔터티 내에 들어가는 구체적인 부분 집합(서브타입)의 종류를 명시하는 것이다. 개체-관계 도표(ERD, Entity Relationship Diagram)를 입체적이고 구체적으로 작성하기 위해서는 집합의 부분 집합을 표현해 주어야 한다. 예를 들어 어떤 보험회사의 사원정보 엔터티를 사원의 유형별로 바라보면 내근사원, 설계사, 대리점으로 구성되어 있지만, 직무별로 바라본다면 경영자, 관리자, 영업사원, 사무직 등으로 구분할 수 있다. 만약 성별로 바라본다면 남자, 여자로 구분할 수 있다.

서브타입 지정시 고려사항

1) 교집합 허용 불가

서브타입 간에 교집합(交集合)을 허용하지 않는다. 다시 말해 남자와 여자 집합의 교집합, 즉 남자도 되고 여자도 되는 개체가 존재한다면 이는 서브타입이 될 수 없다.

2)서브타입의 합이 전체집합

서브타입을 모두 결합하면 반드시 전체 집합이 되도록 해야 한다. 만약 전체 집합이 될 자신이 없다면 나머지 부분(여집합, 餘集合)을 기타로 정의해서라도 반드시 이 규칙을 준수해야 한다.

[그림 4-2-11] 바커 표기법(위)과 IE 표기법(아래)에 따른 서브타입의 지정 예

3)서브타입 표현의 기준

서브 타입의 표현은 추후 궁극적으로는 물리 모델에서 테이블 분할의 기준 역할을 하게 된다. 이러한 목적 이외에 서브타입 표현을 위해서는 기본적으로 다음과 같은 기준을 가지는 것이 바람직하다.

- 개별 속성을 가지는 경우
- 개별 관계를 가지는 경우
- 가독성을 증진시키고자 하는 경우

서브타입 도출

1) 분류 속성

분류 속성에 따라 엔티티의 정보가 차별화되는 경우에 서브타입을 도출할 수 있다.

2)다수의 선택적 속성

다수의 선택적 속성이 존재하는 경우에 서브타입을 도출할 수 있다.

3)선택적 관계가 존재하는 경우

서브타입으로 분할함으로써 관계가 필수적으로 변하는지를 확인한다.

4)도출 절차

- 분류 속성을 확인(엔티티의 발생이 차별화되는 경우)한다.
- 분류 속성값에 의해 분류되는 서브타입을 파악한다.
- 분류 속성에 따라 필수적/선택적 분할을 정의한다.
- 서브타입별 속성을 할당한다.
- 슈퍼타입의 관계를 해당 서브타입에 정의한다.

서브타입의 활용

1)데이터 모델에 업무 규칙을 명확히 표현하여 업무를 정확히 이해할 수 있다.

- 엔티티의 정의를 좀더 구체화하여 데이터 모델에 대한 가독성을 향상시킬 수 있다.-
- 속성의 선택성 제거
- 관계의 선택성 제거

2)서브타입의 표현은 업무 규칙의 명확성과 표현의 복잡성이라는 트레이드 오프(Trade Off) 관계가 적절히 조화를 이루어야 한다.

엔터티 통합과 분할

엔터티를 크게 하나로 할 것인지 아니면 여러 개의 개별 엔터티로 할 것인지의 결정은 향후에 일어날 데이터 모델링의 많은 과정에 커다란 영향을 미치게 된다. 예를 들면, 개발 단계의 생산성, 난이도, 수행 속도, 업무 변경에 대한 유연성, 유지·보수의 비용 등 많은 부분에 영향을 미친다. 좋은 형태의 통합은 변화에 대한 유연성을 증가시키고, 마치 분모의 개수가 감소하듯이 복잡한 업무를 단순화시킬 수 있지만 나쁜 통합 형태는 본질의 희석을 가져와 모호한 집합을 만들게 된다. 엔터티 통합/분할의 결정 사례를 알아보자.

엔터티 독립성

엔터티를 결정하기 위해서 우리가 따져 보아야 할 독립성이란 우리가 새롭게 정의하고자 하는 엔터티가 앞서 정의해 둔 어떤 엔터티에도 포함되지 않는 독립적인 집합인지를 확인하는 것이다.

[그림 4-2-12] 집합 독립성 예

고객이라는 엔터티의 동질성을 우리 회사 제품의 구매 주체가 되었거나 될 가능성을 가진 사람이나 법인, 단체로 규정했다고 하자. 이때 새롭게 법인이라는 엔터티 후보를 검토한다면 이 집합에 속할 개체들은 이미 고객 엔터티에 속할 수 있기 때문에 독립적인 집합이 아니다.
고객 엔터티를 사람의 집합만으로 국한해서 동질성을 부여했다면 법인은 독립적인 집합이 된다.
우리가 독립성을 따질 때는 먼저 검토할 엔터티 후보의 의미를 명확히 해야 한다. 그것은 자신의 집합에 어떠한 개체들이 속해 있는지를 구체적으로 알아야만 다른 엔터티와의 독립성을 확인할 수 있다.

엔터티 분할/통합

집합 간에는 상품과 고객처럼 전혀 포함 관계를 가지지 않거나,
고객과 사원처럼 일부가 포함되거나,
사원과 임원처럼 전체가 포함되는 세 가지 경우가 존재
그런 집합 간에 서로 포함되지 않는 경우라도 동질성을 크게 확장하면 포함될 수도 있고, 반대로 동질성을 구분하면 별도로 분리될 수도 있는 것이기 때문에 상황에 따라 종합적인 판단이 필요해지는 것이며, 그 판단의 합리성에 따라 모델의 품질은 크게 영향을 받게 된다.

이러한 결정에 따라 집합은 이합집산이 일어날 수 있으며 최종적으로 엔터티의 모습이 결정되는 것이다. 이와 같이 집합의 일부가 서로 겹쳐져 있을 때 이들 간의 모양을 결정하는 방법

첫째, 어느 한 집합을 확장된 부분을 어느 한쪽 집합에서만 가지도록 해 둘 사이를 완전 분리하는 방법
둘째, 비록 교차되는 부분이 있더라도 두 집합을 별개의 집합으로 간주하고 필요시 이들 간에 관계를 맺어 주는 방법

어떤 상황에서 이것들을 선택해야 할 것인지는 매우 중요하고 어려운 판단이다. 엔터티를 결정하는 것은 결국 집합의 형태를 결정하는 것이므로 이러한 결정의 적절성이 바로 모델링의 품질을 좌우하는 가장 기본적인 요소이다.

[그림 4-2-13] 집합 이합집산 예

집합 동질성 확대를 통한 집합 통합 사례

1) 보험회사의 대리점 사례

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

2)통신회사의 대리점 사례

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

3)대리점 사원

대리점 사원을 사원이라는 의미에서 동질성을 찾았다면 사원 엔터티에 포함시켜야 옳을 것이다. 가령 대리점에 소속된 사원이지만 어떤 행위의 주체로서의 의미는 일반 사원과 동일하다고 한다면, 사원 엔터티에 포함시키고 일반 사원과 희석되지 않도록 서브타입으로 구분하는 것이 좋다. 그러나 우리가 관리할 행위의 주체(모집자, 고객관리자 등)로서 일반 사원과 동격의 의미를 가지는 것은 대 리점이고, 대리점 사원은 단지 참조 정보로서 관리하고자 한다면 대리점은 사원 집합에 포함시키고 대리점 사원은 별도의 엔터티로 분리하여 불필요하게 사원의 의미를 희석시키지 않는 것이 좀더 좋은 방법이다.

[그림 4-2-14] 집합 동질성 확대 예

유연성 향상을 위한 통합

집합의 동질성을 확장시켜 중첩된 집합을 포함시키면 이들 간의 집합적 관계는 명확해진다. 이러 한 집합의 확장은 비록 유연성과 단순성을 증가시키기는 하지만 지나친 확장은 집합의 의미를 희석 시키므로 주의해야 한다.


[그림 4-2-15]에서와 같이 부모 집합인 사원 엔터티에는 아직 경력 정보를 입수하지 못했거나 신입사원이기 때문에 경력이 없는 사원도 있다는 것은 이상할 것이 없다. 어떤 사원의 경력 정보라고 하더라도 그 정보의 주인이 되는 사원이 없다면 정보로서 아무런 가치가 없다. 부모는 상황에 따라 자식을 가질 수도, 갖지 않을 수도 있지만 자식은 설사 부모가 누군지 모를지언정 결코 없을 수는 없다. 이것이 바로 보편 타당한 규칙이다. 이 말을 다른 의미로 해석을 해보면 그림 좌측과 같이 사원 엔터티에만 새로운 개체가 추가되더라도 경력 정보에는 영향을 미치지 않는다는 것을 뜻한다. 어차피 부모인 사원은 경력 정보를 가지지 않을 수 있도록 허용되었기 때문에 경력 정보를 가지지 않은 새로운 사원이 추가되었다고 해서 이 규칙에 영향을 줄 수 없는 것은 당연하다. 결과적으로 키 엔터티(사원 엔터티)는 최대한 통합되어 집합이 늘어나더라도 하위 엔터티에는 거의 영향을 미치지 않으므로 과감한 통합을 시도하는 것이 바람직하다.

엔터티 정의 기술과 엔터티 정의서 작성

엔터티 후보를 도출하고 충분한 검토와 검증을 거쳐 엔터티의 구성 단위와 형태 등을 결정하고 나면, 다시 서브타입 정의, 동질성 파악을 통한 엔터티 통합 및 분할 등의 과정을 거쳐서 최종적인 엔터티 형태가 확정된다. 엔터티 도출 및 정의 과정에서 엔터티의 개념을 정립하고 적절한 이름을 부여한 후 엔터티 분할·통합 과정을 거쳐 가장 적절한 명칭을 확정해야 한다. 이와 같은 과정을 거쳐 확정한 엔터티의 이름은 이미 이름만으로도 해당 엔터티가 어떤 집합인지 최대한 표현될 수 있어야 하며, 나머지 미진한 부분은 엔터티 정의 또는 엔터티 설명에서 구체적으로 기술하여 이해관계자 간의 명확한 의사소통과 개념 공유가 가능하도록 해야 한다. 이를 위해 엔터티 정의 기술 시 다음과 같은 내용으로 서술함으로써 해당 엔터티에 대한 상세하고 구체적인 내용이 온전하게 전달될 수 있도록 해야 한다.

- 데이터 집합의 개념 및 성격
- 집합 구성상의 특징
- 데이터 생성, 변경, 삭제 시의 특이사항 또는 데이터 오너쉽 등 기타 특이사항 등

[그림 4-2-16]은 이와 같은 기준에 따라 작성한 엔터티 정의 기술 사례이다.




엔터티 정의 기술이 완료되면 엔터티 정의에 관련된 추가적인 상세 정보 항목들을 작성하여 문서화 및 의사소통 수단으로 활용한다. 엔터티 정의서는 이러한 목적으로 작성하는 대표적인 산출물이다. [표 4-2-17]은 엔터티 정의서에 대한 작성 사례이다. 엔터티 정의서에 대한 항목 구성과 서식은 각 조직이나 프로젝트 여건에 맞춰 변형하여 사용할 수 있으며, 가능하면 최대한 상세한 내용으로 작성되어야 산출물의 작성 목적을 달성할 수 있다.


발췌 - DB GUIDE.NET

[블로그 파일 공유]블로그 파일 공유 방법

[블로그 파일 공유]블로그 파일 공유 방법

google 드라이브로 이동!!

공유클릭 ! 

링크 복사 ! ! ! - 블로그의 링크를 클릭 ! ! !

 URL 입력 ! 그럼 끝 ! 

[블로그 보안] 블로그 불펌 방지 코드 삽입

[블로그 보안] 블로그 불펌 방지 코드 삽입
<!-- 불펌 방지 코드 삽입 head -->
<script type="text/javascript">
var omitformtags=["input", "textarea", "select"]
omitformtags=omitformtags.join("|")
function disableselect(e){
if (omitformtags.indexOf(e.target.tagName.toLowerCase())==-1)
return false
}
function reEnable(){
return true
}
if (typeof document.onselectstart!="undefined")
document.onselectstart=new Function ("return false")
else{
document.onmousedown=disableselect
document.onmouseup=reEnable
}
</script>
<!-- 불펌 방지 코드 끝 head -->

파일 다운로드

[SQL]표준조인 JOIN

1. STANDARD SQL 개요
1970년: Dr. E.F.Codd 관계형 DBMS(Relational DB) 논문 발표 1974년: IBM SQL 개발 1979년: Oracle 상용 DBMS 발표 1980년: Sybase SQL Server 발표 (이후 Sybase ASE로 개명) 1983년: IBM DB2 발표 1986년: ANSI/ISO SQL 표준 최초 제정 (SQL-86, SQL1) 1992년: ANSI/ISO SQL 표준 개정 (SQL-92, SQL2) 1993년: MS SQL Server 발표 (Windows OS, Sybase Code 활용) 1999년: ANSI/ISO SQL 표준 개정 (SQL-99, SQL3) 2003년: ANSI/ISO SQL 표준 개정 (SQL-2003) 2008년: ANSI/ISO SQL 표준 개정 (SQL-2008)

 국내뿐만 아니라 전 세계적으로 많이 사용되고 있는 관계형 데이터베이스의 경우 오브젝트 개념을 포함한 여러 새로운 기능들이 꾸준히 개발되고 있으며, 현재 기업형 DBMS는 순수 관계형 데이터베이스가 아닌 객체 지원 기능이 포함된 객체관계형(Object Relational) 데이터베이스를 대부분 사용하고 있다. 현재 우리가 사용하는 많은 시스템의 두뇌 역할을 하는 관계형 데이터베이스를 유일하게 접속할 수 있는 언어가 바로 SQL이다. 사용자와 개발자 입장에서는 SQL의 진화 및 변화가 가장 큰 관심 내용인데, 초창기 SQL의 기본 기능을 정리했던 최초의 SQL-86 표준과 관계형 DBMS의 폭발적인 전성기를 주도했던 ANSI/ISO SQL2 세대를 지나면서 많은 기술적인 발전이 있었다. 그러나, ANSI/ISO SQL2의 경우 표준 SQL에 대한 명세가 부족한 부분이 있었고, DBMS 벤더 별로 문법이나 사용되는 용어의 차이가 너무 커져서 상호 호환성이나 SQL 학습 효율이 많이 부족한 문제가 발생하였다. 이에 향후 SQL에서 필요한 기능을 정리하고 호환 가능한 여러 기준을 제정한 것이 1999년에 정해진 ANSI/ISO SQL3이다. 이후 가장 먼저 ANSI/ISO SQL3의 기능을 시현한 것이 Oracle의 8i/9i 버전이라고 할 수 있다. 참고로 2003년에 ANSI/ISO SQL 기준이 소폭 추가 개정되었고 현재 사용되는 데이터베이스는 대부분 SQL-2003 표준을 기준으로 하고 있다. 다른 벤더의 DBMS도 2006년 이후 발표된 버전에서 ANSI/ISO SQL-99와 SQL-2003의 핵심적인 기능은 만족스러운 수준으로 구현된 것으로 평가 받고 있다. 마지막으로 2008년에 진행된 추가 개정 내용은 아직 사용자 레벨에 큰 영향을 미치지 않고 있다. 아직도 벤더별로 일부 기능의 개발이 진행 중인 경우도 있고 벤더별 특이한 기술 용어는 여전히 호환이 안 되고 있지만, ANSI/ISO SQL 표준을 통해 STANDARD JOIN을 포함한 많은 기능이 상호 벤치마킹하고 발전하면서 DBMS 간에 평준화를 이루어 가고 있다고 볼 수 있다. 예를 들면, IBM DB2나 SYBASE ASE DBMS는 과거 버전부터 CASE 기능이나 FULL OUTER JOIN 기능을 지원하였지만, Oracle DBMS는 양쪽(FULL) OUTER JOIN의 경우 (+) 표시를 이용한 두 개의 SQL 문장을 UNION 오퍼레이션으로 처리하거나, CASE 기능을 구현하기 위해 DECODE 함수를 복잡하게 구현해야 하는 불편함이 있었다. 이런 불편 사항은 Oracle에서 표준 SQL에 포함된 CASE 기능과 FULL OUTER JOIN 기능을 추가함으로써 문제가 해결되었다.(참고로, Oracle DECODE 함수가 CASE 기능보다 장점도 있으므로 Oracle 사용자는 요구사항에 따라 DECODE나 CASE 함수를 선택할 수 있다.) 결과적으로 사용자 입장에서는 ANSI/ISO SQL의 새로운 기능들을 사용함으로써 보다 쉽게 데이터를 추출하거나 SQL 튜닝의 효과를 함께 얻을 수 있게 되었다. 대표적인 ANSI/ISO 표준 SQL의 기능은 다음 내용을 포함한다.

- STANDARD JOIN 기능 추가 (CROSS, OUTER JOIN 등 새로운 FROM 절 JOIN 기능들) - SCALAR SUBQUERY, TOP-N QUERY 등의 새로운 SUBQUERY 기능들 - ROLLUP, CUBE, GROUPING SETS 등의 새로운 리포팅 기능 - WINDOW FUNCTION 같은 새로운 개념의 분석 기능들

가. 일반 집합 연산자


 현재 사용하는 SQL의 많은 기능이 관계형 데이터베이스의 이론을 수립한 E.F.Codd 박사의 논문에 언급이 되어 있다. 논문에 언급된 8가지 관계형 대수는 다시 각각 4개의 일반 집합 연산자와 순수 관계 연산자로 나눌 수 있으며, 관계형 데이터베이스 엔진 및 SQL의 기반 이론이 되었다. 일반 집합 연산자를 현재의 SQL과 비교하면,

1. UNION 연산은 UNION 기능으로, 2. INTERSECTION 연산은 INTERSECT 기능으로, 3. DIFFERENCE 연산은 EXCEPT(Oracle은 MINUS) 기능으로, 4. PRODUCT 연산은 CROSS JOIN 기능으로 구현되었다.

 첫 번째, UNION 연산은 수학적 합집합을 제공하기 위해, 공통 교집합의 중복을 없애기 위한 사전 작업으로 시스템에 부하를 주는 정렬 작업이 발생한다. 이후 UNION ALL 기능이 추가되었는데, 특별한 요구 사항이 없다면 공통집합을 중복해서 그대로 보여 주기 때문에 정렬 작업이 일어나지 않는 장점을 가진다. 만일 UNION과 UNION ALL의 출력 결과가 같다면, 응답 속도 향상이나 자원 효율화 측면에서 데이터 정렬 작업이 발생하지 않는 UNION ALL을 사용하는 것을 권고한다.
 두 번째, INTERSECTION은 수학의 교집합으로써 두 집합의 공통집합을 추출한다.
 세 번째, DIFFERENCE는 수학의 차집합으로써 첫 번째 집합에서 두 번째 집합과의 공통집합을 제외한 부분이다. 대다수 벤더는 EXCEPT를, Oracle은 MINUS 용어를 사용한다. (SQL 표준에는 EXCEPT로 표시되어 있으며, 벤더에서 SQL 표준 기능을 구현할 때 다른 용어를 사용하는 것은 현실적으로 허용되고 있다.)
 네 번째, PRODUCT의 경우는 CROSS(ANIS/ISO 표준) PRODUCT라고 불리는 곱집합으로, JOIN 조건이 없는 경우 생길 수 있는 모든 데이터의 조합을 말한다. 양쪽 집합의 M*N 건의 데이터 조합이 발생하며, CARTESIAN(수학자 이름) PRODUCT라고도 표현한다.

나. 순수 관계 연산자



순수 관계 연산자는 관계형 데이터베이스를 구현하기 위해 새롭게 만들어진 연산자이다. 순수 관계 연산자를 현재의 SQL 문장과 비교하면 다음과 같다.

5. SELECT 연산은 WHERE 절로 구현되었다. 6. PROJECT 연산은 SELECT 절로 구현되었다. 7. (NATURAL) JOIN 연산은 다양한 JOIN 기능으로 구현되었다. 8. DIVIDE 연산은 현재 사용되지 않는다.

 다섯 번째, SELECT 연산은 SQL 문장에서는 WHERE 절의 조건절 기능으로 구현이 되었다. (SELECT 연산과 SELECT 절의 의미가 다름을 유의하자.)
 여섯 번째, PROJECT 연산은 SQL 문장에서는 SELECT 절의 칼럼 선택 기능으로 구현이 되었다.
 일곱 번째, JOIN 연산은 WHERE 절의 INNER JOIN 조건과 함께 FROM 절의 NATURAL JOIN, INNER JOIN, OUTER JOIN, USING 조건절, ON 조건절 등으로 가장 다양하게 발전하였다.
 여덟 번째, DIVIDE 연산은 나눗셈과 비슷한 개념으로 왼쪽의 집합을 ‘XZ’로 나누었을 때, 즉 ‘XZ’를 모두 가지고 있는 ‘A’가 답이 되는 기능으로 현재 사용되지 않는다. 관계형 데이터베이스의 경우 요구사항 분석, 개념적 데이터 모델링, 논리적 데이터 모델링, 물리적 데이터 모델링 단계를 거치게 되는데, 이 단계에서 엔터티 확정 및 정규화 과정, 그리고 M:M (다대다) 관계를 분해하는 절차를 거치게 된다. 특히 정규화 과정의 경우 데이터 정합성과 데이터 저장 공간의 절약을 위해 엔터티를 최대한 분리하는 작업으로, 일반적으로 3차 정규형이나 보이스코드 정규형까지 진행하게 된다. 이런 정규화를 거치면 하나의 주제에 관련 있는 엔터티가 여러 개로 나누어지게 되고, 이 엔터티들이 주로 테이블이 되는데 이렇게 흩어진 데이터를 연결해서 원하는 데이터를 가져오는 작업이 바로 JOIN이라고 할 수 있다. 관계형 데이터베이스에 있어서 JOIN은 SQL의 가장 중요한 기능이므로 충분히 이해할 필요가 있다.

2. FROM 절 JOIN 형태

ANSI/ISO SQL에서 표시하는 FROM 절의 JOIN 형태는 다음과 같다.

- INNER JOIN - NATURAL JOIN - USING 조건절 - ON 조건절 - CROSS JOIN - OUTER JOIN

ANSI/ISO SQL에서 규정한 JOIN 문법은 WHERE 절을 사용하던 기존 JOIN 방식과 차이가 있다. 사용자는 기존 WHERE 절의 검색 조건과 테이블 간의 JOIN 조건을 구분 없이 사용하던 방식을 그대로 사용할 수 있으면서, 추가된 선택 기능으로 테이블 간의 JOIN 조건을 FROM 절에서 명시적으로 정의할 수 있게 되었다.
 INNER JOIN은 WHERE 절에서부터 사용하던 JOIN의 DEFAULT 옵션으로 JOIN 조건에서 동일한 값이 있는 행만 반환한다. DEFAULT 옵션이므로 생략이 가능하지만, CROSS JOIN, OUTER JOIN과는 같이 사용할 수 없다. NATURAL JOIN은 INNER JOIN의 하위 개념으로  NATURAL JOIN은 두 테이블 간의 동일한 이름을 갖는 모든 칼럼들에 대해 EQUI(=) JOIN을 수행한다. NATURAL INNER JOIN이라고도 표시할 수 있으며, 결과는 NATURAL JOIN과 같다. 새로운 SQL JOIN 문장 중에서 가장 중요하게 기억해야 하는 문장은
 ON 조건절을 사용하는 경우이다. 과거 WHERE 절에서 JOIN 조건과 데이터 검증 조건이 같이 사용되어 용도가 불분명한 경우가 발생할 수 있었는데, WHERE 절의 JOIN 조건을 FROM 절의 ON 조건절로 분리하여 표시함으로써 사용자가 이해하기 쉽도록 한다. ON 조건절의 경우 NATURAL JOIN처럼 JOIN 조건이 숨어 있지 않고, 명시적으로 JOIN 조건을 구분할 수 있고, NATURAL JOIN이나 USING 조건절처럼 칼럼명이 똑같아야 된다는 제약 없이 칼럼명이 상호 다르더라도 JOIN 조건으로 사용할 수 있으므로 앞으로 가장 많이 사용될 것으로 예상된다. 다만, FROM 절에 테이블이 많이 사용될 경우 다소 복잡하게 보여 가독성이 떨어지는 단점이 있다. 그런 측면에서 SQL Server의 경우 ON 조건절만 지원하고 NATURAL JOIN과 USING 조건절을 지원하지 않고 있는 것으로 보인다. 본 가이드는 ANSI/ISO SQL 기준에 NATURAL JOIN과 USING 조건절이 표시되어 있으므로 이 부분도 설명을 하도록 한다.

3. INNER JOIN

 INNER JOIN은 OUTER(외부) JOIN과 대비하여 내부 JOIN이라고 하며 JOIN 조건에서 동일한 값이 있는 행만 반환한다. INNER JOIN 표시는 그 동안 WHERE 절에서 사용하던 JOIN 조건을 FROM 절에서 정의하겠다는 표시이므로 USING 조건절이나 ON 조건절을 필수적으로 사용해야 한다.

4. NATURAL JOIN
NATURAL JOIN은 두 테이블 간의 동일한 이름을 갖는 모든 칼럼들에 대해 EQUI(=) JOIN을 수행한다. NATURAL JOIN이 명시되면, 추가로 USING 조건절, ON 조건절, WHERE 절에서 JOIN 조건을 정의할 수 없다. 그리고, SQL Server에서는 지원하지 않는 기능이다.

5. USING 조건절
NATURAL JOIN에서는 모든 일치되는 칼럼들에 대해 JOIN이 이루어지지만, FROM 절의 USING 조건절을 이용하면 같은 이름을 가진 칼럼들 중에서 원하는 칼럼에 대해서만 선택적으로 EQUI JOIN을 할 수가 있다. 다만, 이 기능은 SQL Server에서는 지원하지 않는다.

6. ON 조건절
JOIN 서술부(ON 조건절)와 비 JOIN 서술부(WHERE 조건절)를 분리하여 이해가 쉬우며, 칼럼명이 다르더라도 JOIN 조건을 사용할 수 있는 장점이 있다.

가. WHERE 절과의 혼용

[예제] ON 조건절과 WHERE 검색 조건은 충돌 없이 사용할 수 있다. 부서코드 30인 부서의 소속 사원 이름 및 소속 부서 코드, 부서 코드, 부서 이름을 찾아본다.

[예제]
SELECT E.ENAME, E.DEPTNO, D.DEPTNO, D.DNAME
  FROM EMP E
  JOIN DEPT D ON (E.DEPTNO = D.DEPTNO) WHERE E.DEPTNO = 30;

나. ON 조건절 + 데이터 검증 조건 추가

ON 조건절에 JOIN 조건 외에도 데이터 검색 조건을 추가할 수는 있으나, 검색 조건 목적인 경우는 WHERE 절을 사용할 것을 권고한다. (다만, 아우터 조인에서 조인의 대상을 제한하기 위한 목적으로 사용되는 추가 조건의 경우는 ON 절에 표기되어야 한다.)

[예제] 매니저 사원번호가 7698번인 사원들의 이름 및 소속 부서 코드, 부서 이름을 찾아본다.

[예제]
SELECT E.ENAME, E.MGR, D.DEPTNO, D.DNAME
  FROM EMP E
  JOIN DEPT D ON (E.DEPTNO = D.DEPTNO AND E.MGR = 7698);
  위 SQL과 아래 SQL은 같은 결과를 얻을 수 있다.
SELECT E.ENAME, E.MGR, D.DEPTNO, D.DNAME
  FROM EMP E
  JOIN DEPT D ON (E.DEPTNO = D.DEPTNO) WHERE E.MGR = 7698;

다. ON 조건절 예제

[예제] 팀과 스타디움 테이블을 스타디움ID로 JOIN하여 팀이름, 스타디움ID, 스타디움 이름을 찾아본다.

[예제]
SELECT TEAM_NAME, TEAM.STADIUM_ID, STADIUM_NAME
  FROM TEAM
  JOIN STADIUM ON TEAM.STADIUM_ID = STADIUM.STADIUM_ID
 ORDER BY STADIUM_ID;;
 위 SQL은 STADIUM_ID라는 공통된 칼럼이 있기 때문에 아래처럼 USING 조건절로 구현할 수도 있다.
SELECT TEAM_NAME, STADIUM_ID, STADIUM_NAME
  FROM TEAM
  JOIN STADIUM USING (STADIUM_ID)
 ORDER BY STADIUM_ID;
 위 SQL은 고전적인 방식인 WHERE 절의 INNER JOIN으로 구현할 수도 있다.
SELECT TEAM_NAME, TEAM.STADIUM_ID, STADIUM_NAME
  FROM TEAM, STADIUM
 WHERE TEAM.STADIUM_ID = STADIUM.STADIUM_ID
 ORDER BY STADIUM_ID

[예제]
SELECT TEAM_NAME, TEAM_ID, STADIUM_NAME
  FROM TEAM
  JOIN STADIUM ON TEAM.TEAM_ID = STADIUM.HOMETEAM_ID
 ORDER BY TEAM_ID;
 위 SQL은 고전적인 방식인 WHERE 절의 INNER JOIN으로 구현할 수도 있다.
SELECT TEAM_NAME, TEAM_ID, STADIUM_NAME
  FROM TEAM, STADIUM
 WHERE TEAM.TEAM_ID = STADIUM.HOMETEAM_ID
 ORDER BY TEAM_ID; 위 SQL은 TEAM_ID와 HOMETEAM_ID라는 다른 이름의 칼럼을 사용하기 때문에 USING 조건절을 사용할 수는 없다.

라. 다중 테이블 JOIN

[예제] 사원과 DEPT 테이블의 소속 부서명, DEPT_TEMP 테이블의 바뀐 부서명 정보를 출력한다.

[예제]
SELECT E.EMPNO, D.DEPTNO, D.DNAME, T.DNAME New_DNAME
  FROM EMP E
  JOIN DEPT D ON (E.DEPTNO = D.DEPTNO)
  JOIN DEPT_TEMP T ON (E.DEPTNO = T.DEPTNO);
위 SQL은 고전적인 방식인 WHERE 절의 INNER JOIN으로 구현할 수도 있다.
SELECT E.EMPNO, D.DEPTNO, D.DNAME, T.DNAME New_DNAME
  FROM EMP E, DEPT D, DEPT_TEMP T
 WHERE E.DEPTNO = D.DEPTNO
   AND E.DEPTNO = T.DEPTNO;

[예제]
SELECT P.PLAYER_NAME 선수명, P.POSITION 포지션, T.REGION_NAME 연고지명, T.TEAM_NAME 팀명, S.STADIUM_NAME 구장명
  FROM PLAYER P
  JOIN TEAM T ON P.TEAM_ID = T.TEAM_ID
  JOIN STADIUM S ON T.STADIUM_ID = S.STADIUM_ID
 WHERE P.POSITION = 'GK'
 ORDER BY 선수명;
위 SQL은 고전적인 방식인 WHERE 절의 INNER JOIN으로 구현할 수도 있다.
SELECT P.PLAYER_NAME 선수명, P.POSITION 포지션, T.REGION_NAME 연고지명, T.TEAM_NAME 팀명, S.STADIUM_NAME 구장명
  FROM PLAYER P, TEAM T, STADIUM S
 WHERE P.TEAM_ID = T.TEAM_ID
   AND T.STADIUM_ID = S.STADIUM_ID
   AND P.POSITION = 'GK' ORDER BY 선수명;

[예제]
SELECT ST.STADIUM_NAME, SC.STADIUM_ID, SCHE_DATE, HT.TEAM_NAME, AT.TEAM_NAME, HOME_SCORE, AWAY_SCORE
  FROM SCHEDULE SC
  JOIN STADIUM ST ON SC.STADIUM_ID = ST.STADIUM_ID
  JOIN TEAM HT ON SC.HOMETEAM_ID = HT.TEAM_ID
  JOIN TEAM AT ON SC.AWAYTEAM_ID = AT.TEAM_ID
 WHERE HOME_SCORE > = AWAY_SCORE +3;
위 SQL은 고전적인 방식인 WHERE 절의 INNER JOIN으로 구현할 수도 있다.
SELECT ST.STADIUM_NAME, SC.STADIUM_ID, SCHE_DATE, HT.TEAM_NAME, AT.TEAM_NAME, HOME_SCORE, AWAY_SCORE
  FROM SCHEDULE SC, STADIUM ST, TEAM HT, TEAM AT
 WHERE HOME_SCORE> = AWAY_SCORE +3
   AND SC.STADIUM_ID = ST.STADIUM_ID
   AND SC.HOMETEAM_ID = HT.TEAM_ID
   AND SC.AWAYTEAM_ID = AT.TEAM_ID;
 FROM 절에 4개의 테이블이 JOIN에 참여하였으며, HOME TEAM과 AWAY TEAM의 팀 이름을 구하기 위해 TEAM 테이블을 HT와 AT 두 개의 ALIAS로 구분하였다.

7. CROSS JOIN

CROSS JOIN은 E.F.CODD 박사가 언급한 일반 집합 연산자의 PRODUCT의 개념으로 테이블 간 JOIN 조건이 없는 경우 생길 수 있는 모든 데이터의 조합을 말한다. 두 개의 테이블에 대한 CARTESIAN PRODUCT 또는 CROSS PRODUCT와 같은 표현으로, 결과는 양쪽 집합의 M*N 건의 데이터 조합이 발생한다. (아래 56건의 데이터는 EMP 14건 * DEPT 4건의 데이터 조합 건수이다.)

[예제] NATURAL JOIN의 경우 WHERE 절에서 JOIN 조건을 추가할 수 없지만, CROSS JOIN의 경우 WHERE 절에 JOIN 조건을 추가할 수 있다. 그러나, 이 경우는 CROSS JOIN이 아니라 INNER JOIN과 같은 결과를 얻기 때문에 CROSS JOIN을 사용하는 의미가 없어지므로 권고하지 않는다.

[예제]
SELECT ENAME, DNAME
  FROM EMP CROSS
  JOIN DEPT
 WHERE EMP.DEPTNO = DEPT.DEPTNO;
위 SQL과 아래 SQL은 같은 결과를 얻을 수 있다.
SELECT ENAME, DNAME
  FROM EMP INNER
  JOIN DEPT
 WHERE EMP.DEPTNO = DEPT.DEPTNO;

정상적인 데이터 모델이라면 CROSS PRODUCT가 필요한 경우는 많지 않지만, 간혹 튜닝이나 리포트를 작성하기 위해 고의적으로 사용하는 경우가 있을 수 있다. 그리고 데이터웨어하우스의 개별 DIMENSION(차원)을 FACT(사실) 칼럼과 JOIN하기 전에 모든 DIMENSION의 CROSS PRODUCT를 먼저 구할 때 유용하게 사용할 수 있다.

8. OUTER JOIN

INNER(내부) JOIN과 대비하여 OUTER(외부) JOIN이라고 불리며, JOIN 조건에서 동일한 값이 없는 행도 반환할 때 사용할 수 있다.


 [그림 Ⅱ-2-3]은 TAB1 테이블이 TAB2 테이블을 JOIN 하되, TAB2의 JOIN 데이터가 있는 경우는 TAB2의 데이터를 함께 출력하고, TAB2의 JOIN 데이터가 없는 경우에도 TAB1의 모든 데이터를 표시하고 싶은 경우이다. TAB1의 모든 값에 대해 TAB2의 데이터가 반드시 존재한다는 보장이 없는 경우 OUTER JOIN을 사용하여 해결이 가능하다. 과거 OUTER JOIN을 위해 Oracle은 JOIN 칼럼 뒤에 ‘(+)’를 표시하였고, Sybase는 비교 연산자의 앞이나 뒤에 ‘(+)’를 표시했었는데, JOIN 조건과 WHERE 절 검색 조건이 불명확한 단점, IN이나 OR 연산자 사용시 에러 발생, ‘(+)’ 표시가 누락된 칼럼 존재시 OUTER JOIN 오류 발생, FULL OUTER JOIN 미지원 등 불편함이 많았다.
 STANDARD JOIN을 사용함으로써 OUTER JOIN의 많은 문제점을 해결할 수 있고, 대부분의 관계형 DBMS 간에 호환성을 확보할 수 있으므로 명시적인 OUTER JOIN을 사용할 것을 적극적으로 권장한다. 추가로 OUTER JOIN 역시 JOIN 조건을 FROM 절에서 정의하겠다는 표시이므로 USING 조건절이나 ON 조건절을 필수적으로 사용해야 한다. 그리고, LEFT/RIGHT OUTER JOIN의 경우에는 기준이 되는 테이블이 조인 수행시 무조건 드라이빙 테이블이 된다. 옵티마이저는 이 원칙에 위배되는 다른 실행계획을 고려하지 않는다.

가. LEFT OUTER JOIN

조인 수행시 먼저 표기된 좌측 테이블에 해당하는 데이터를 먼저 읽은 후, 나중 표기된 우측 테이블에서 JOIN 대상 데이터를 읽어 온다. 즉, Table A와 B가 있을 때(Table 'A'가 기준이 됨), A와 B를 비교해서 B의 JOIN 칼럼에서 같은 값이 있을 때 그 해당 데이터를 가져오고, B의 JOIN 칼럼에서 같은 값이 없는 경우에는 B 테이블에서 가져오는 칼럼들은 NULL 값으로 채운다. 그리고 LEFT JOIN으로 OUTER 키워드를 생략해서 사용할 수 있다.

[예제] STADIUM에 등록된 운동장 중에는 홈팀이 없는 경기장도 있다. STADIUM과 TEAM을 JOIN 하되 홈팀이 없는 경기장의 정보도 같이 출력하도록 한다.

[예제]
SELECT STADIUM_NAME, STADIUM.STADIUM_ID, SEAT_COUNT, HOMETEAM_ID, TEAM_NAME
  FROM STADIUM
  LEFT OUTER JOIN TEAM ON STADIUM.HOMETEAM_ID = TEAM.TEAM_ID
 ORDER BY HOMETEAM_ID;
OUTER는 생략 가능한 키워드이므로 아래 SQL은 같은 결과를 얻을 수 있다.
SELECT STADIUM_NAME, STADIUM.STADIUM_ID, SEAT_COUNT, HOMETEAM_ID, TEAM_NAME
  FROM STADIUM
  LEFT JOIN TEAM ON STADIUM.HOMETEAM_ID = TEAM.TEAM_ID
 ORDER BY HOMETEAM_ID;

나. RIGHT OUTER JOIN

조인 수행시 LEFT JOIN과 반대로 우측 테이블이 기준이 되어 결과를 생성한다. 즉, TABLE A와 B가 있을 때(TABLE 'B'가 기준이 됨), A와 B를 비교해서 A의 JOIN 칼럼에서 같은 값이 있을 때 그 해당 데이터를 가져오고, A의 JOIN 칼럼에서 같은 값이 없는 경우에는 A 테이블에서 가져오는 칼럼들은 NULL 값으로 채운다. 그리고 RIGHT JOIN으로 OUTER 키워드를 생략해서 사용할 수 있다.

[예제] DEPT에 등록된 부서 중에는 사원이 없는 부서도 있다. DEPT와 EMP를 조인하되 사원이 없는 부서 정보도 같이 출력하도록 한다.

[예제]
SELECT E.ENAME, D.DEPTNO, D.DNAME
  FROM EMP E
 RIGHT OUTER JOIN DEPT D ON E.DEPTNO = D.DEPTNO;
OUTER는 생략 가능한 키워드이므로 아래 SQL은 같은 결과를 얻을 수 있다.
SELECT E.ENAME, D.DEPTNO, D.DNAME, D.LOC
  FROM EMP E
 RIGHT JOIN DEPT D ON E.DEPTNO = D.DEPTNO;

다. FULL OUTER JOIN

조인 수행시 좌측, 우측 테이블의 모든 데이터를 읽어 JOIN하여 결과를 생성한다. 즉, TABLE A와 B가 있을 때(TABLE 'A', 'B' 모두 기준이 됨), RIGHT OUTER JOIN과 LEFT OUTER JOIN의 결과를 합집합으로 처리한 결과와 동일하다. 단, UNION ALL이 아닌 UNION 기능과 같으므로 중복되는 데이터는 삭제한다. (UNION ALL과 UNION에 대해서는 다음 절에서 설명하도록 한다.) 그리고 FULL JOIN으로 OUTER 키워드를 생략해서 사용할 수 있다.

[예제] DEPT 테이블과 DEPT_TEMP 테이블의 FULL OUTER JOIN 사례를 만들기 위해 DEPT_TEMP의 DEPTNO를 수정한다. 결과적으로 DEPT_TEMP 테이블의 새로운 DEPTNO 데이터는 DETP 테이블의 DEPTNO와 2건은 동일하고 2건은 새로운 DEPTNO가 생성된다.

[예제]
UPDATE DEPT_TEMP
   SET DEPTNO = DEPTNO + 20;
SELECT * FROM DEPT_TEMP;

[예제] DEPTNO 기준으로 DEPT와 DEPT_TEMP 데이터를 FULL OUTER JOIN으로 출력한다. 예제에 사용된 UNION(중복 데이터는 제거됨)은 다음 절에서 설명하도록 한다.

[예제]
SELECT *
  FROM DEPT
  FULL OUTER JOIN DEPT_TEMP ON DEPT.DEPTNO = DEPT_TEMP.DEPTNO;
OUTER는 생략 가능한 키워드이므로 아래 SQL은 같은 결과를 얻을 수 있다.
SELECT *
  FROM DEPT
  FULL JOIN DEPT_TEMP ON DEPT.DEPTNO = DEPT_TEMP.DEPTNO;
위 SQL과 아래 SQL은 같은 결과를 얻을 수 있다.
SELECT L.DEPTNO, L.DNAME, L.LOC, R.DEPTNO, R.DNAME, R.LOC
  FROM DEPT L
  LEFT OUTER JOIN DEPT_TEMP R ON L.DEPTNO = R.DEPTNO
 UNION SELECT L.DEPTNO, L.DNAME, L.LOC, R.DEPTNO, R.DNAME, R.LOC
         FROM DEPT L
        RIGHT OUTER JOIN DEPT_TEMP R ON L.DEPTNO = R.DEPTNO;

9. INNER vs OUTER vs CROSS JOIN 비교


첫 번째, INNER JOIN의 결과는 다음과 같다. 양쪽 테이블에 모두 존재하는 키 값이 B-B, C-C 인 2건이 출력된다.
두 번째, LEFT OUTER JOIN의 결과는 다음과 같다. TAB1을 기준으로 키 값 조합이 B-B, C-C, D-NULL, E-NULL 인 4건이 출력된다.
세 번째, RIGHT OUTER JOIN의 결과는 다음과 같다. TAB2를 기준으로 키 값 조합이 NULL-A, B-B, C-C 인 3건이 출력된다.
네 번째, FULL OUTER JOIN의 결과는 다음과 같다. 양쪽 테이블을 기준으로 키 값 조합이 NULL-A, B-B, C-C, D-NULL, E-NULL 인 5건이 출력된다.
다섯 번째, CROSS JOIN의 결과는 다음과 같다. JOIN 가능한 모든 경우의 수를 표시하지만 단, OUTER JOIN은 제외한다.
양쪽 테이블 TAB1과 TAB2의 데이터를 곱한 개수인 4 * 3 = 12건이 추출됨 키 값 조합이 B-A, B-B, B-C, C-A, C-B, C-C, D-A, D-B, D-C, E-A, E-B, E-C 인 12건이 출력된다.

발췌 DB GUIDE

[데이터 모델링]데이터 모델의 이해

[데이터 모델링]데이터 모델의 이해
1. 모델링의 이해

가. 모델링의 정의

인류의 가장 보편적인 특징이면서 욕구 중의 하나는 의사소통을 하면서 항상 그에 대한 기록을 남기는 것이다. 어떤 현상에 대해 기록하고 남겨 자신 스스로 또는 다른 사람에게 적절한 의미를 주기 위해 고대부터 기록의 문화는 발전해 왔다고 할 수 있다. 모델이라고 하는 것은 모형(模型), 축소형(縮小型)의 의미로서 사람이 살아가면서 나타날 수 있는 다양한 현상에 대해서 일정한 표기법에 의해 표현해 놓은 모형이라고 할 수 있다. 이 역시 사람이 어떤 목적을 달성하기 위해 커뮤니케이션의 효율성을 극대화한 고급화된 표현방법으로 설명될 수 있다.

사람이 살아가면서 나타날 수 있는 다양한 현상은 사람, 사물, 개념 등에 의해 발생된다고 할 수 있으며 모델링은 이것을 표기법에 의해 규칙을 가지고 표기하는 것 자체를 의미한다. 즉 모델을 만들어가는 일 자체를 모델링으로 정의할 수 있다.



다음은 모델링에 대한 다양한 정의를 보여준다.

1) Webster 사전
- 가설적 또는 일정 양식에 맞춘 표현(a hypothetical or stylized representation)
- 어떤 것에 대한 예비표현으로 그로부터 최종대상이 구축되도록 하는 계획
2) 복잡한 ‘현실세계’를 단순화시켜 표현하는 것이다.
3) 모델이란 사물 또는 사건에 관한 양상(Aspect)이나 관점(Perspective)을 연관된 사람이나 그룹을 위하여 명확하게 하는 것이다.
4) 모델이란 현실 세계의 추상화된 반영이다.

나. 모델링의 특징

위의 정의를 요약하여 모델링의 특징을 요약하면 추상화, 단순화, 명확화의 3대 특징으로 요약할 수 있다.

1) 추상화(모형화, 가설적)는 현실세계를 일정한 형식에 맞추어 표현을 한다는 의미로 정리할 수 있다. 즉, 다양한 현상을 일정한 양식인 표기법에 의해 표현한다는 것이다.
2) 단순화는 복잡한 현실세계를 약속된 규약에 의해 제한된 표기법이나 언어로 표현하여 쉽게 이해할 수 있도록 하는 개념을 의미한다.
3) 명확화는 누구나 이해하기 쉽게 하기 위해 대상에 대한 애매모호함을 제거하고 정확(正確)하게 현상을 기술하는 것을 의미한다.

따라서 모델링을 다시 정의하면 ‘현실세계를 추상화, 단순화, 명확화하기 위해 일정한 표기법에 의해 표현하는 기법’으로 정리할 수 있다. 정보시스템 구축에서는 모델링을 계획/분석/설계 할 때 업무를 분석하고 설계하는데 이용하고 이후 구축/운영 단계에서는 변경과 관리의 목적으로 이용하게 된다.

다. 모델링의 세 가지 관점

시스템의 대상이 되는 업무를 분석하여 정보시스템으로 구성하는 과정에서 업무의 내용과 정보시스템의 모습을 적절한 표기법(Notation)으로 표현하는 것을 모델링이라고 한다면, 모델링은 크게 세 가지 관점인
데이터관점,
프로세스관점,
데이터와 프로세스의 상관관점으로 구분


1) 데이터관점 : 업무가 어떤 데이터와 관련이 있는지 또는 데이터간의 관계는 무엇인지에 대해서 모델링하는 방법(What, Data)
2) 프로세스관점 : 업무가 실제하고 있는 일은 무엇인지 또는 무엇을 해야 하는지를 모델링하는 방법(How, Process)
3) 데이터와 프로세스의 상관관점 : 업무가 처리하는 일의 방법에 따라 데이터는 어떻게 영향을 받고 있는지 모델링하는 방법(Interaction)으로 설명될 수 있다.

이 장에서는 데이터 모델링에 대한 기본 개념이 중요하므로 프로세스와 상관모델링에 대한 내용은 생략하고 데이터베이스를 구축하기 위한 데이터 모델링을 중심으로 설명한다.

2. 데이터 모델의 기본 개념의 이해

가. 모델링의 정의

데이터 모델은 데이터베이스의 골격을 이해하고 그 이해를 바탕으로 SQL문장을 기능과 성능적인 측면에서 효율적으로 작성하기 위해 꼭 알아야 하는 핵심요소이다. SQL 전문가를 위한 지식에서도 데이터베이스의 논리적인 구조를 이해하는 데이터 모델을 이해하는 것은 그 다음 SQL문장을 어떻게 구성할지에 대한 지식과 효율적인 구성에 대한 밑바탕의 지식을 쌓기 위한 핵심 이론이라 할 수 있다. 일반적으로 데이터 모델링은 다음과 같이 다양하게 정의될 수 있다.

- 정보시스템을 구축하기 위해, 해당 업무에 어떤 데이터가 존재하는지 또는 업무가 필요로 하는 정보는 무엇인지를 분석하는 방법
- 기업 업무에 대한 종합적인 이해를 바탕으로 데이터에 존재하는 업무 규칙(Business Rule)에 대하여 참(True) 또는 거짓(False)을 판별할 수 있는 사실(사실명제)을 데이터에 접근하는 방법(How), 사람(Who), 전산화와는 별개의(독립적인) 관점에서 이를 명확하게 표현하는 추상화 기법

이것을 좀 더 실무적으로 해석해 보면 업무에서 필요로 하는 데이터를 시스템 구축 방법론에 의해 분석하고 설계하여 정보시스템을 구축하는 과정으로 정의할 수 있다. 데이터 모델링을 하는 주요한 이유는 업무정보를 구성하는 기초가 되는 정보들을 일정한 표기법에 의해 표현함으로써
첫 번째 목적 : 정보시스템 구축의 대상이 되는 업무 내용을 정확하게 분석하는 것이
두 번째 : 분석된 모델을 가지고 실제 데이터베이스를 생성하여 개발 및 데이터관리에 사용
즉, 데이터 모델링이라는 것은 단지 데이터베이스만을 구축하기 위한 용도로만 쓰이는 것이 아니라 데이터 모델링 자체로서 업무를 설명하고 분석하는 부분에도 매우 중요한 의미를 가지고 있다고 할 수 있다.


나. 데이터 모델이 제공하는 기능

업무를 분석하는 관점에서 데이터 모델이 제공하는 기능은 다음과 같다.

- 시스템을 현재 또는 원하는 모습으로 가시화하도록 도와준다.
- 시스템의 구조와 행동을 명세화 할 수 있게 한다.
- 시스템을 구축하는 구조화된 틀을 제공한다.
- 시스템을 구축하는 과정에서 결정한 것을 문서화한다.
- 다양한 영역에 집중하기 위해 다른 영역의 세부 사항은 숨기는 다양한 관점을 제공한다.
- 특정 목표에 따라 구체화된 상세 수준의 표현방법을 제공한다.

3. 데이터 모델링의 중요성 및 유의점

데이터 모델링이 중요한 이유는
- 파급효과(Leverage)
- 복잡한 정보 요구사항의 간결한 표현(Conciseness)
- 데이터 품질(Data Quality)

가. 파급효과(Leverage)

시스템 구축이 완성되어 가는?행하고 대규모의 데이터 이행을 성공적으로 수행하기 위한 많은 단위 테스트들이 수행되고 이러한 과정들이 반복된다. 각 단위 테스트들이 성공적으로 수행되고 완료되면 이를 전체를 묶어서 병행테스트, 통합테스트를 수행하게 된다. 만약, 이러한 시점에 데이터 모델의 변경이 불가피한 상황이 발생한다고 가정해 보자. 이를 위해서 데이터 구조의 변경에 따른 표준 영향 분석, 응용 변경 영향 분석 등 많은 영향 분석이 일어난다. 그 이후에 해당 분야의 실제적인 변경 작업이 발생하게 된다. 변경을 해야 하는 데이터 모델의 형태에 따라서 그 영향 정도는 차이가 있겠지만 이 시기의 데이터 구조의 변경으로 인한 일련의 변경작업은 전체 시스템 구축 프로젝트에서 큰 위험요소가 아닐 수 없다. 이러한 이유로 인해 시스템 구축 작업 중에서 다른 어떤 설계 과정보다 데이터 설계가 더 중요하다고 볼 수 있다.

복잡한 정보 요구사항의 간결한 표현(Conciseness)

데이터 모델은 구축할 시스템의 정보 요구사항과 한계를 가장 명확하고 간결하게 표현할 수 있는 도구이다. 정보 요구사항을 파악하는 가장 좋은 방법은 수많은 페이지의 기능적인 요구사항을 파악하는 것보다 간결하게 그려져 있는 데이터 모델을 리뷰하면서 파악하는 것이 훨씬 빠른 방법이다. 데이터 모델은 건축물로 비유하자면 설계 도면에 해당한다. 이것은 건축물의 설계 도면이 건축물을 짓는 많은 사람들이 공유하면서 설계자의 생각대로 일사불란하게 움직여서 아름다운 건축물을 만들어 내는 것에 비유할 수 있다. 데이터 모델은 시스템을 구축하는 많은 관련자들이 설계자의 생각대로 정보요구사항을 이해하고 이를 운용할 수 있는 애플리케이션을 개발하고 데이터 정합성을 유지할 수 있도록 하는 것이다. 이렇게 이상적으로 역할을 할 수 있는 모델이 갖추어야 할 가장 중요한 점은 정보 요구사항이 정확하고 간결하게 표현되어야 한다는 것이다. 우리가 활용하고 있는 데이터 모델이 이와 같은 요소들이 충족된 모델인지를 확인해 볼 필요가 있다.

다. 데이터 품질(Data Quality)

데이터베이스에 담겨 있는 데이터는 기업의 중요한 자산이다. 이 데이터는 기간이 오래되면 될수록 활용가치는 훨씬 높아진다. 그런데 이러한 오래도록 저장되어진 데이터가 그저 그런 데이터, 정확성이 떨어지는 데이터라고 한다면 어떨까? 이것은 일부 시스템의 기능이 잘못되어 수정하는 성격의 일이 아니다. 이것은 해당 데이터로 얻을 수 있었던 소중한 비즈니스의 기회를 상실할 수도 있는 문제이다. 데이터 품질의 문제가 중요한 이유가 여기에 있다.
데이터 품질의 문제는 데이터 구조가 설계되고 초기에 데이터가 조금 쌓일 때에는 인지하지 못하는 경우가 대부분이다. 이러한 데이터의 문제는 오랜 기간 숙성된 데이터를 전략적으로 활용하려고 하는 시점에 문제가 대두되기 때문이다.
데이터 품질의 문제가 야기되는 중대한 이유 중 하나가 바로 데이터 구조의 문제이다.
중복 데이터의 미정의, 데이터 구조의 비즈니스 정의의 불충분, 동일한 성격의 데이터를 통합하지 않고 분리함으로써의 나타나는 데이터 불일치 등의 데이터 구조의 문제로 인한 데이터 품질의 문제는 치유하기에 불가능한 경우가 대부분이다. 데이터 모델링을 할 때 유의점은 다음과 같다.

1) 중복(Duplication) 데이터 모델은 같은 데이터를 사용하는 사람, 시간, 그리고 장소를 파악하는데 도움을 준다. 이러한 지식 응용은 데이터베이스가 여러 장소에 같은 정보를 저장하는 잘못을 하지 않도록 한다.

2) 비유연성(Inflexibility) 데이터 모델을 어떻게 설계했느냐에 따라 사소한 업무변화에도 데이터 모델이 수시로 변경됨으로써 유지보수의 어려움을 가중시킬 수 있다. 데이터의 정의를 데이터의 사용 프로세스와 분리함으로써 데이터 모델링은 데이터 혹은 프로세스의 작은 변화가 애플리케이션과 데이터베이스에 중대한 변화를 일으킬 수 있는 가능성을 줄인다.

3) 비일관성(Inconsistency) 데이터의 중복이 없더라도 비일관성은 발생한다. 예를 들어 신용 상태에 대한 갱신 없이 고객의 납부 이력 정보를 갱신하는 것이다. 개발자가 다른 데이터와 모순된다는 고려 없이 일련의 데이터를 수정할 수 있기 때문이다. 데이터 모델링을 할 때 데이터와 데이터간 상호 연관 관계에 대한 명확한 정의는 이러한 위험을 사전에 예방할 수 있도록 해준다.

4. 데이터 모델링의 3단계 진행
특별히 데이터 모델은 데이터베이스를 만들어내는 설계서로서 분명한 목표를 가지고 있다. 현실세계에서 데이터베이스까지 만들어지는 과정은 [그림 Ⅰ-1-3]과 같이 시간에 따라 진행되는 과정으로서 추상화 수준에 따라 개념적 데이터 모델, 논리적 데이터 모델, 물리적 데이터 모델로 정리할 수 있다.



처음 현실세계에서 추상화 수준이 높은 상위 수준을 형상화하기 위해 개념적 데이터 모델링을 전개한다. 개념적 데이터 모델은 추상화 수준이 높고 업무중심적이고 포괄적인 수준의 모델링을 진행한다. 참고로 EA기반의 전사적인 데이터 모델링을 전개할 때는 더 상위수준인 개괄적인 데이터 모델링을 먼저 수행하고 이후에 업무영역에 따른 개념적 데이터 모델링을 전개한다.
엔터티(Entity)중심의 상위 수준의 데이터 모델이 완성되면 업무의 구체적인 모습과 흐름에 따른 구체화된 업무중심의 데이터 모델을 만들어 내는데 이것을 논리적인 데이터 모델링이라고 한다. 논리적인 데이터 모델링 이후 데이터베이스의 저장구조에 따른 테이블스페이스 등을 고려한 방식을 물리적인 데이터 모델링이라고 한다. 이것을 요약하여 정리하면 [표 Ⅰ-1-1]과 같다.


가. 개념적 데이터 모델링(Conceptual Data Modeling)

개념적 데이터베이스 설계(개념 데이터 모델링)는 조직, 사용자의 데이터 요구사항을 찾고 분석하는데서 시작한다. 이 과정은 어떠한 자료가 중요하며 또 어떠한 자료가 유지되어야 하는지를 결정하는 것도 포함한다.
이 단계에 있어서의 주요한 활동은 핵심 엔터티와 그들 간의 관계를 발견하고, 그것을 표현하기 위해서 엔터티-관계 다이어그램을 생성하는 것이다. 엔터티-관계 다이어그램은 조직과 다양한 데이터베이스 사용자에게 어떠한 데이터가 중요한지 나타내기 위해서 사용된다. 데이터 모델링 과정이 전 조직에 걸쳐 이루어진다면, 그것은 전사적 데이터 모델(Enterprise Data Model)이라고 불린다.
개념 데이터 모델을 통해 조직의 데이터 요구를 공식화하는 것은 두 가지의 중요한 기능을 지원한다.

첫째, 개념 데이터 모델은 사용자와 시스템 개발자가 데이터 요구 사항을 발견하는 것을 지원한다. 개념 데이터 모델은 추상적이다. 그렇기 때문에 그 모델은 상위의 문제에 대한 구조화를 쉽게 하며, 사용자와 개발자가 시스템 기능에 대해서 논의할 수 있는 기반을 형성한다.

둘째, 개념 데이터 모델은 현 시스템이 어떻게 변형되어야 하는가를 이해하는데 유용하다. 일반적으로 매우 간단하게 고립된(Stand Alone) 시스템도 추상적 모델링을 통해서 보다 쉽게 표현되고 설명된다.

나. 논리적 데이터 모델링(Logical Data Modeling)

논리 데이터 모델링은 데이터베이스 설계 프로세스의 Input으로써 비즈니스 정보의 논리적인 구조와 규칙을 명확하게 표현하는 기법 또는 과정이라 할 수 있다. 논리 데이터 모델링의 결과로 얻어지는 논리 데이터 모델은 데이터 모델링이 최??리적인 스키마 설계를 하기 전에 액세스하고, 누가 데이터에 액세스하며, 그러한 액세스의 전산화와는 독립적으로 다시 말해서 누가(Who), 어떻게(How: Process) 그리고 전산화와는 별개로 비즈니스 데이터에 존재하는 사실들을 인식하여 기록하는 것이다.
데이터 모델링 과정에서 가장 핵심이 되는 부분이 논리 데이터 모델링이라고 할 수 있다. 데이터 모델링이란 모델링 과정이 아닌 별도의 과정을 통해서 조사하고 결정한 사실을 단지 ERD라는 그림으로 그려내는 과정을 말하는 것이 아니다. 시스템 구축을 위해서 가장 먼저 시작할 기초적인 업무조사를 하는 초기단계에서부터 인간이 결정해야 할 대부분의 사항을 모두 정의하는 시스템 설계의 전 과정을 지원하는 ‘과정의 도구’라고 해야 할 것이다. 이 단계에서 수행하는 또 한가지 중요한 활동은 정규화이다. 정규화는 논리 데이터 모델 상세화 과정의 대표적인 활동으로, 논리 데이터 모델의 일관성을 확보하고 중복을 제거하여 속성들이 가장 적절한 엔터티에 배치되도록 함으로써 보다 신뢰성있는 데이터구조를 얻는데 목적이 있다. 논리 데이터 모델의 상세화는 식별자 확정, 정규화, M:M 관계 해소, 참조 무결성 규칙 정의 등을 들 수 있으며, 추가적으로 이력 관리에 대한 전략을 정의하여 이를 논리 데이터 모델에 반영함으로써 데이터 모델링을 완료하게 된다.

다. 물리적 데이터 모델링(Physical Data Modeling)

데이터베이스 설계 과정의 세 번째 단계인 물리 데이터 모델링은 논리 데이터 모델이 데이터 저장소로서 어떻게 컴퓨터 하드웨어에 표현될 것인가를 다룬다. 데이터가 물리적으로 컴퓨터에 어떻게 저장될 것인가에 대한 정의를 물리적 스키마라고 한다. 이 단계에서 결정되는 것은 테이블, 칼럼 등으로 표현되는 물리적인 저장구조와 사용될 저장 장치, 자료를 추출하기 위해 사용될 접근 방법 등이 있다. 계층적 데이터베이스 관리 시스템 환경에서는 데이터베이스 관리자가 물리적 스키마를 설계하고 구현하기 위해서 보다 많은 시간을 투자하여야 한다.

실질적인 현실 프로젝트에서는 개념적 데이터 모델링 논리적 데이터 모델링 물리적 데이터 모델링으로 수행하는 경우는 드물며 개념적 데이터 모델링과 논리적 데이터 모델을 한꺼번에 수행하여 논리적인 데이터 모델링으로 수행하는 경우가 대부분이다. 프로젝트 생명주기에 따른 일반적인 데이터 모델은 다음과 같이 수행된다.

5. 프로젝트 생명주기(Life Cycle)에서 데이터 모델링

Waterfall 기반에서는 데이터 모델링의 위치가 분석과 설계단계로 구분되어 명확하게 정의할 수 있다. 정보공학이나 구조적 방법론에서는 보통 분석단계에서 업무중심의 논리적인 데이터 모델링을 수행하고 설계단계에서 하드웨어와 성능을 고려한 물리적인 데이터 모델링을 수행하게 된다. 나선형 모델, 예를 들어 RUP(Rational Unified Process나 마르미)에서는 업무크기에 따라 논리적 데이터 모델과 물리적 데이터 모델이 분석, 설계단계 양쪽에서 수행이 되며 비중은 분석단계에서 논리적인 데이터 모델이 더 많이 수행되는 형태가 된다.


데이터축과 애플리케이션축으로 구분되어 프로젝트가 진행되면서 각각에 도출된 사항은 상호 검증을 지속적으로 수행하면서 단계별 완성도를 높이게 된다. 단, 객체지향 개념은 데이터와 프로세스를 한꺼번에 바라보면서 모델링을 전개하므로 데이터 모델링과 프로세스 모델링을 구분하지 않고 일체형으로 진행(대표적인 예가 데이터(속성)와 프로세스(Method)가 같이 있는 클래스(Class))하게 된다.

6. 데이터 모델링에서 데이터독립성의 이해

가. 데이터독립성의 필요성

 일체적 구성에서 기능화된 구성의 가장 큰 목적은 상호간 영향에서 벗어나 개별 형식이 가지는 고유의 기능을 유지시키며 그 기능을 극대화하는 것이다. 컴포넌트 기반의 모듈 구성도 각각이 고유한 기능을 가지면서 다른 기능을 가지고 있는 컴포넌트와 인터페이스를 가지게 하는 모습으로 정의할 수 있다.
 SOA의 ‘서비스’라고 하는 단위도 독립적인 비즈니스로 처리 가능한 단위를 서비스로 정의하고 그것이 다른 서비스에 비해 독립성을 구성하여 개별로도 의미가 있고 다른 서비스와 결합하여 프로세스로 제공해도 의미가 있는 단위(예, BPM)로 제공하게 된다.
 이와 같이 어떤 단위에 대해 독립적인 의미를 부여하고 그것을 효과적으로 구현하게 되면 자신이 가지는 고유한 특징을 명확하게 할 뿐만 아니라 다른 기능의 변경으로부터 쉽게 변경되지 않고 자신의 고유한 기능을 가지고 기능을 제공하는 장점을 가지게 된다. 데이터독립성을 이해하기 위해서는, 데이터독립성이라고 하는 개념이 출현하게 된 배경을 이해할 필요가 있다. 데이터독립성의 반대말은 데이터종속성이다.
 여기에서 종속의 주체는 보통 응용(Application)을 지칭하는 경우이다. 응용(Application)은 사용자 요구사항을 처리하는 사용자 접점의 인터페이스 오브젝트이다. 과거에 파일방식으로 데이터를 구성할 때는 데이터가 있는 파일과 데이터에 접근하기 위한 인덱스를 별도로 구현하여 접근하게 하였는데 사용자가 접근하는 방법(트랜잭션의 유형)에 따라 파일의 정렬순서, 인덱스의 정렬순서, 파일 구성 등을 제공하기 쉽게 별도로 구성하였다.
 즉, 사용자 접근하는 유형에 따라 데이터를 구성하는 방법이 영향을 받게 된다. 메인프레임 환경에서 파일방식을 사용하여 데이터처리를 했던 메인프레임 세대는 개별로 처리했던 접근방법을 이해할 수 있으나 1990년대 이후의 Client/Sever 이후 세대는 파일처리 방식 이해가 난해할 수도 있다. 데이터독립성은 지속적으로 증가하는 유지보수 비용을 절감하고 데이터 복잡도를 낮추며 중복된 데이터를 줄이기 위한 목적이 있다. 또한 끊임없이 요구되는 사용자 요구사항에 대해 화면과 데이터베이스 간에 서로 독립성을 유지하기 위한 목적으로 데이터 독립성 개념이 출현했다고 할 수 있다.


데이터독립성은 미국 표준 협회(ANSI) 산하의 X3 위원회(컴퓨터 및 정보 처리)의 특별연구분과위원회에서 1978년에 DBMS와 그 인터페이스를 위해 제안한 ‘three-schema architecture’로 정의할 수 있다.

데이터독립성을 확보하게 되면 다음과 같은 효과를 얻을 수 있다.

- 각 View의 독립성을 유지하고 계층별 View에 영향을 주지 않고 변경이 가능하다.
- 단계별 Schema에 따라 데이터 정의어(DDL)와 데이터 조작어(DML)가 다름을 제공한다.
- 데이터독립성을 이해하기 위해서는 3단계로 표현된 ANSI 표준 모델을 살펴보면 되는데 특히 3단계인 구조, 독립성, 사상(Mapping) 3가지를 이해하면 된다.

나. 데이터베이스 3단계 구조

ANSI/SPARC의 3단계 구성의 데이터독립성 모델은 외부단계와 개념적 단계, 내부적 단계로 구성된 서로 간섭되지 않는 모델을 제시하고 있다.



데이터독립성의 3단계에서 외부단계는 사용자와 가까운 단계로 사용자 개개인이 보는 자료에 대한 관점과 관련이 있스키마 구조데이터 유형의 공통적인 사항을 처리하는 통합된 뷰를 스키마 구조로 디자인한 형태이다. 우리가 쉽게 이해??를 설계하는 도구?? 데이터가 물리적으로 저장된 방법에 대한 스키마 구조를 말한다. 다음에서 [그림 Ⅰ-1-6]의 3단계 구조의 상세 사항에 대해 각 구성별로 예를 들어 설명한다.

다. 데이터독립성 요소


데이터베이스 스키마 구조는 3단계로 구분되고 각각은 상호 독립적인 의미를 가지고 고유한 기능을 가진다. 데이터 모델링은 통합관점의 뷰를 가지고 있는 개념 스키마를 만들어가는 과정으로 이해할 수 있다.

라. 두 영역의 데이터독립성

이렇게 3단계로 개념이 분리되면서 각각의 영역에 대한 독립성을 지정하는 용어가 바로 논리적인 독립성과 물리적인 독립성이다.


즉, 논리적인 데이터독립성은 외부의 변경에도 개념스키마가 변하지 않는 특징을 가진다.
물론, 새로운 요건이 추가되거나 삭제될 경우 칼럼이 변형될 수 있지만 그러한 변화가 개별 화면이나 프로세스에 의해 변화된다기 보다는 전체 업무적인 요건을 고려하여 종합적으로 영향을 받음을 의미한다.

마. 사상(Mapping)

영어로 ‘Mapping’은 우리말로 ‘사상’이라고 번역되는데 이것은 상호 독립적인 개념을 연결시켜주는 다리를 뜻한다. 데이터독립성에서는 크게 2가지의 사상이 도출된다.


 즉, 외부 화면이나 사용자에게 인터페이스하기 위한 스키마 구조는 전체가 통합된 개념적 스키마와 연결된다는 것이 논리적 사상이다. 또한 통합된 개념적 스키마 구조와 물리적으로 저장된 구조의 물리적인 테이블스페이스와 연결되는 구조가 물리적 사상이다.
 데이터독립성을 보장하기 위해서는 사상을 하는 스크립트(DDL)를 DBA가 필요할 때마다 변경해 주어야 한다. 즉, 각 단계(외부, 개념적, 내부적)의 독립성을 보장하기 위해서 변경사항이 발생했을 때 DBA가 적절하게 작업을 해주기 때문에 독립성이 보장된다고도 할 수 있다.

7. 데이터 모델링의 중요한 세 가지 개념

가. 데이터 모델링의 세 가지 요소

데이터 모델링을 구성하는 중요한 개념 세 가지가 있는데 이것은 데이터 모델에 대한 이해의 근간이 되므로 반드시 기억할 필요가 있다.

1) 업무가 관여하는 어떤 것(Things)
2) 어떤 것이 가지는 성격(Attributes)
3) 업무가 관여하는 어떤 것 간의 관계(Relationships)

이 세 가지는 데이터 모델링을 완성해 가는 핵심 개념으로서 결국 엔터티, 속성, 관계로 인식되는 것이다. 사물이나 사건 등을 바라 볼 때 전체를 지칭하는 용어를 어떤 것(Things)이라 하고, 그 어떤 것이 가지는 세부적인 사항을 성격(Attributes)이라고 할 수 있다. 또한 각각의 어떤 것은 다른 어떤 것과 연관성을 가질 수 있는데 이것을 관계(Relationship)라고 표현한다. 예를 들어 ‘이주일과 심순애가 존재하고 둘 사이는 서로 사랑하는 연인사이이다. 이주일은 키가 180cm에 성격은 친절하고 심순애는 키가 165cm에 세심하며 활달한 성격을 가지고 있다’는 시나리오를 살펴보자. 여기에서 ‘이주일, 심순애’는 어떤 것(Things)에 해당하고 ‘사랑하는 연인사이’가 어떤 것 간의 관계(Relationships)에 해당하며 ‘180cm에 성격은 친절, 세심하며 활달함’이 어떤 것이 가지는 성격(Attributes)에 해당한다. 위의 예와 같이 이 세상의 모든 사람, 사물, 개념 등은 어떤 것, 어떤 것 간의 관계, 성격의 구분을 통해서 분류할 수 있다. 바로 이러한 원리, 즉 자연계에 존재하는 모든 유형의 정보들을 세 가지 관점의 접근 방법을 통해 모델링을 진행하는 것이다.

나. 단수와 집합(복수)의 명명

데이터 모델링에서는 이 세 가지 개념에 대해서 단수와 복수의 개념을 분명하게 구분하고 있고 실제로 데이터 모델링을 할 때 많이 활용되는 용어이다.



 어떤 것의 전체를 지칭하는 것을 영문으로 Entity Set, Entity Type의 복수의 의미를 가지는 Set이나 Type을 포함하여 표현하기도 한다. 그래서 엔터티 타입으로 표현하기도 하는데 실제 실무 현장에서는 엔터티로 짧게 명명한다.
 즉 엔터티를 어떤 것에 대한 집합을 명명하여 지칭한다. 어떤 것에 대한 개별 지칭으로 엔터티가 단수명사로서 단어의 의미가 있지만, 엔터티를 집합개념으로 사용하는 경우에는 개별요소에 대해서는 인스턴스/어커런스를 단수의 개념으로 사용하여 부른다.
 관계(Relationship)도 이를 복수로 통칭하여 관계로 표현하고 관계에 포함된 개별 연관성을 패어링이라고 부르기도 한다. 그러나 패어링이라는 용어는 실제 데이터 모델링을 할 때는 잘 사용하지 않으며 그냥 일반적으로 단수든 복수든 관계라고 표현하는 경우가 많다.
 어떤 것이 가지는 성격(Attribute)에 대한 집합개념이 속성이고 그 안에 개별 값들을 속성값으로 구분하여 복수와 단수의 개념으로 구분할 수 있다. 본 가이드에서는 현장 통용성을 반영하여 국내외적으로 가장 범용적으로 명명되고 있는 용어인 엔터티를 집합의 개념으로 지칭하고 인스턴스를 단수의 개념으로 명명하도록 한다.
 데이터 모델의 핵심 요소인 이 세 가지를 이용하여 일정한 표기법에 의해 데이터 모델을 만들어 낼 수 있다. 다음은 다양한 표기법에 의해 생성되는 데이터 모델의 표기법을 설명한다.

8. 데이터 모델링의 이해관계자

가. 이해관계자의 데이터 모델링 중요성 인식

 실제 업무시스템을 구축하는 실전 프로젝트에서는 데이터베이스를 전문적으로 하는 이른바 DBA(DataBase Administrator)가 데이터 모델링을 전적으로 하는 예는 거의 없다. 오히려 업무시스템을 개발하는 응용시스템 개발자가 데이터 모델링도 같이 하게 된다.
 그 이유는 데이터 모델링이라는 과정이 단지 데이터베이스를 설계한다는 측면보다 업무를 이해하고 분석하여 표현하는 것이 중요하고, 표현된 내용을 바탕으로 프로젝트 관련자와 의사소통하고 프로그램이나 다른 표기법과 비교 검증하는 일을 수행하는 등 많은 시간을 업무를 분석하고 설계하는데 할애하기 때문에 업무영역별 개발팀에서 보통 데이터 모델링을 진행하게 되는 것이다.
 물론 시스템이 대형화되면 모델링만을 전문적으로 담당하는 모델러를 투입하여 진행하는 경우도 있지만 이와 같은 경우도 실제 모델링 작업은 응용개발을 하는 사람이나 업무분석가(역할분담이 잘되어 있을 경우)가 담당하고 모델러나 DBA는 정확하게 모델링이 진행될 수 있도록 교육하고 제시하며 현안별로 직접 모델링을 진행하는 역할을 수행한다.
 이와 같이 응용시스템을 개발하는 모든 시스템 엔지니어가 데이터 모델을 하거나 할 기회가 있음에도 불구하고 대부분의 사람들은 데이터 모델에 많은 관심을 갖지 않고 단지 프로그램을 개발하기 위한 프로그래밍 언어(Programming Language)에만 많은 관심을 두고 애플리케이션을 개발하는 데에 훨씬 많은 시간을 투자하는 경우가 많다. 그러나 분명한 사실은 정보시스템을 개발한다고 할 때 데이터 모델링, 데이터베이스 구축, 구축된 데??하다는 점이다.


 우리가 구축하려는 시스템 대부분을 데이터에 기반한, 데이터가 중심에 있는 정보시스템을 구축하기 때문에 정보시스템의 핵심에 있는 데이터베이스 설계를 잘못했을 때 미치는 영향력은 모든 프로그램, 시간에 따라 입력되는 모든 데이터, 그리고 그 데이터베이스에 발생되는 모든 트랜잭션에 영향을 미칠 수 밖에 없게 된다.
 Bachmann은 ‘프로그래머는 데이터집합의 탐색자이다’라고 하였다. 그만큼 데이터에 대한 중요성을 높게 평가하는 것이다.

나. 데이터 모델링의 이해관계자

 그러면 누가 데이터 모델링에 대해 연구하고 학습해야 하겠는가?
첫 번째는 정보시스템을 구축하는 모든 사람(전문적으로 코딩만하는 사람 포함)은 데이터 모델링도 전문적으로 할 수 있거나 적어도 완성된 모델을 정확하게 해석할 수 있어야 한다.
 즉 프로젝트에 참여한 모든 IT기술자들은 데이터 모델링에 대해 정확하게 알고 있어야 한다는 것을 의미한다.
두 번째는 IT기술에 종사하거나 전공하지 않았더라도 해당 업무에서 정보화를 추진하는 위치에 있는 사람도 데이터 모델링에 대한 개념 및 세부사항에 대해 어느 정도 지식을 가지고 있어야 한다. 실제 프로젝트에서 보면 업무분석을 하는 도중에 현업의 업무담당자가 어느 사이에 데이터 모델링에 대해 상당한 이해를 하고 있음을 알게 된다.
 그래야만 서로가 프로젝트 수행 중에 의사소통을 잘 할 수 있고 업무를 잘못 해석하여 잘못된 시스템을 구축하는 위험(Risk)을 줄일 수 있게 된다. 업무를 가장 잘 알고 있는 사람이 가장 훌륭한 모델러가 될 수 있다는 사실을 나타내는 예이다.


9. 데이터 모델의 표기법인 ERD의 이해

가. 데이터 모델 표기법

데이터 모델에 대한 표기법으로 1976년 피터첸(Peter Chen)이 Entity-relationship model(E-R Model)이라는 표기법을 만들었다. 엔터티를 사각형으로 표현하고 관계를 마름모 속성을 타원형으로 표현하는 이 표기법은 데이터 모델링에 대한 이론을 배울 때 많이 활용되고 있다. 데이터베이스 설계에 대해 우리나라 대학에서는 주로 이 Chen의 모델 표기법을 통해 배우고 있다. [표 Ⅰ-1-6]은 엔터티와 속성 그리고 관계에 대한 다양한 표기법을 설명한 것이다


데이터아키텍처 전문가(DAP) 관련 자격에서는 바커(Barker) 표기법을 적용하여 설명했다면, 본 가이드에서는 범용적인 Information Engineering(이하 IE) 표기법과 바커 표기법을 모두 적용하여 설명을 진행하도록 한다. 표기법은 바커 표기법이든 IE 표기법이든 상호간에 기술적으로 전환이 가능하기 때문에 한 가지만 정확하게 알고 있어도 다른 표기법을 이해하는데 큰 어려움이 없을 것이다.

나. ERD(Entity Relationship Diagram) 표기법을 이용하여 모델링하는 방법

 ERD는 각 업무분석에서 도출된 엔터티와 엔터티간의 관계를 이해하기 쉽게 도식화된 다이어그램으로 표시하는 방법으로서 실제 프로젝트에서는 도식화된 그림 정도로만 생각하지 않고 해당 업무에서 데이터의 흐름과 프로세스와의 연관성을 이야기하는 데 가장 중요한 표기법이자 산출물이다. UML 표준 표기법을 사용하는 오브젝트 모델링에서는 궁극적으로 해당 업무에 가장 적절한 클래스다이어그램을 그려내는 것이 가장 중요하다고 하면, 정보공학을 기반으로 하는 모델링에서는 해당 업무에 가장 적절한 ERD를 그려내는 것이 프로젝트의 지상과제이다. 오브젝트 모델링을 하더라도 관계형 데이터베이스를 대부분 사용하기 때문에 데이터베이스를 생성할 수 있는 데이터 모델 생성이 프로젝트에서 아주 중요한 타스크에 포함된다.  데이터분석이 어느 정도 완료되면 즉 엔터티, 관계, 속성 등이 데이터사전이나 각종 산출물에 의해 분석된 상태에서 ERD를 그리는 것이 원래 이론적인 작업 방법이지만, 실제 프로젝트에서는 분석된 엔터티와 관계, 속성 정보가 바로 ERD에 표현되며 내부 프로젝트 인원이나 해당 업무고객과 대화할 때 핵심 업무산출물로 항상 이용된다.
 ERD를 그리는 것은 물론 어떻게 그리든 업무에는 전혀 지장을 주지 않지만 일정한 규칙을 지정하여 그림으로써 데이터 모델을 누구나 공통된 시각으로 파악할 수 있고 의사소통을 원활하게 하는 장점이 있다.
 여기에서 제시하는 방법은 가이드일 뿐이며 프로젝트 상황과 엔터티의 관련 순서에 따라 얼마든지 다르게 배치될 수 있음을 숙지하고 배치방법에 대한 원칙을 다음과 같이 설명한다. 최근에는 전문 데이터 모델링 툴을 활용하여 ERD를 그리게 되므로 다음과 같이 엔터티, 속성, 관계 순으로 진행하기 보다는 엔터티와 관계를 바로 표현하는 방식으로 진행하기도 한다. 다만 업무를 분석하여 무엇을 도출할 지에 대한 관점을 제시하고, 전문 데이터 모델링 툴이 없을 때 어떤 순서로 표현해야 하는지 알 수 있도록 방법을 설명한다.

1) ERD 작업순서 ERD를 작성하는 작업순서는 다음과 같다.
① 엔터티를 그린다.
② 엔터티를 적절하게 배치한다.
③ 엔터티간 관계를 설정한다.
④ 관계명을 기술한다.
⑤ 관계의 참여도를 기술한다.
⑥ 관계의 필수여부를 기술한다.


 ERD는 엔터티와 엔터티 사이의 관계가 있는 정보를 나타내므로 두 개를 이용하여 작성하고, 이에 따라 Primary Key와 Foreign Key를 ERD 규칙에 따라 기술하도록 한다. 엔터티는 사각형으로 표기하여 기술한다.

2) 엔터티 배치 엔터티를 처음에 어디에 배치하는지는 데이터 모델링 툴을 사용하든 사용하지 않던 중요한 문제이다. 일반적으로 사람의 눈은 왼쪽에서 오른쪽, 위 쪽에서 아래쪽으로 이동하는 경향이 있다. 따라서 데이터 모델링에서도 가장 중요한 엔터티를 왼쪽상단에 배치하고 이것을 중심으로 다른 엔터티를 나열하면서 전개하면 사람의 눈이 따라가기에 편리한 데이터 모델링을 전개할 수 있다. 해당 업무에서 가장 중요한 엔터티는 왼쪽 상단에서 조금 아래쪽 중앙에 배치하여 전체 엔터티와 어울릴 수 있도록 하면 향후 관계를 연결할 때 선이 꼬이지 않고 효과적으로 배치할 수 있게 된다.


[그림 Ⅰ-1-10]의 데이터 모델에서도 가장 중요한 엔터티인 고객과 주문을 왼쪽 상단에 배치하여 다른 엔터티를 연결하는 방식으로 엔터티를 배치하였다. 주문에 따라 출고가 이루어졌으므로 주문이 위에 출고가 아래에 위치해 있다.
 두 번째 업무흐름에 중심이 되는 엔터티, 보통 업무 흐름에 있어서 중심이 되는 엔터티는 타 엔터티와 많은 관계를 가지고 있으므로 중앙에 배치하도록 한다. [그림 Ⅰ-1-10]에서는 주문, 출고, 주문목록, 출고목록이 업무의 중심엔터티에 해당한다.
 세 번째는 업무를 진행하는 중심엔터티와 관계를 갖는 엔터티들은 중심에 배치된 엔터티를 주위에 배치하도록 한다. [그림 Ⅰ-1-10]에서는 창고, 고객, 사원, 재고가 이에 해당한다.

3) ERD 관계석서를 보고 서로 관련있는 엔터티간에 관계를 설정하도록 한다. 초기에는 모두 Primary Key로 속성이 상속되는 식별자 관계를 설정하도록 한다. 중복되는 관계가 발생되지 않도록 하고 Circle 관계도 발생하지 않도록 유의하여 작성하도록 한다.


4) ERD 관계명의 표시 관계설정이 완료되면 연결된 관계에 관계이름을 부여하도록 한다. 관계이름은 현재형을 사용하고 지나치게 포괄적인 용어(예, 이다, 가진다 등)는 사용하지 않도록 한다.


실제 프로젝트에서는 관계의 명칭을 크게 고려하지 않아도 무방하다. 왜냐하면 관계의 명칭이 나타나지 않아도 ERD의 흐름이 명확하게 드러나기 때문이다. 대부분의 관계는 엔터티의 성질과 주식별자를 보고 유추가 가능하다.

5) ERD 관계 관계차수와 선택성 표시 관계에 대한 이름을 모두 지정하였으면 관계가 참여하는 성격 중 엔터티내에 인스턴스들이 얼마나 관계에 참여하는 지를 나타내는 관계차수(Cardinality)를 표현한다. [그림 Ⅰ-1-13]은 관계의 관계차수를 지정한 ERD의 모습을 보여준다. 관계설명에서도 언급하겠지만 IE표기법으로는 하나(1, One)의 관계는 실선으로 표기하고 Barker표기법으로는 점선과 실선을 혼합하여 표기한다. 다수참여(Many)의 관계는 까마귀발과 같은 모양으로 그려준다. 또한 관계의 필수/선택표시는 관계선에 원을 표현하여 ERD를 그리도록 한다.


10. 좋은 데이터 모델의 요소

일반적으로 시스템 구축 과정에서 생성되는 데이터 모델은 그 품질을 평가하는 것이 매우 어렵다. 사실 특정 데이터 모델이 업무 환경에서 요구하는 사항을 얼마나 잘 시스템적으로 구현할 수 있는가를 객관적으로 평가할 수 있다면 가장 좋은 평가의 방법일 것이다. 하지만 어디에도 이것을 객관적으로 평가할 수 있는 기준이 존재하지는 않는 것이 현실이다. 본 가이드에서는 이러한 상황에서 대체적으로 좋은 데이터 모델이라고 말할 수 있는 몇 가지의 요소들을 설명한다.

가. 완전성(Completeness)

업무에서 필요로 하는 모든 데이터가 데이터 모델에 정의되어 있어야 한다. 데이터 모델을 검증하기 위해서 가장 먼저 확인해야 할 부분이다. 이 기준이 충족되지 못하면 다른 어떤 평가 기준도 의미가 없어진다. 만약, 보험사의 데이터 모델에 고객의 직업을 관리하기 위한 속성이 존재하지 않는다면 어떨까? 이것은 심각한 데이터 모델의 문제점이다.

나. 중복배제(Non-Redundancy)

하나의 데이터베이스 내에 동일한 사실은 반드시 한 번만 기록하여야 한다. 예를 들면, 하나의 테이블에서 ‘나이’ 칼럼과 ‘생년월일’ 칼럼이 동시에 존재한다면 이것은 데이터 중복이라 볼 수 있다. 이러한 형태의 데이터 중복 관리로 인해서 여러 가지 바람직하지 않은 형태의 데이터 관리 비용을 지불할 수 있다. 예를 들면, 저장공간의 낭비, 중복 관리되고 있는 데이터의 일관성을 유지하기 위한 추가적인 데이터 조작 등이 대표적으로 낭비되는 비용이라고 볼 수 있다.

다. 업무규칙(Business Rules)

데이터 모델에서 매우 중요한 요소 중 하나가 데이터 모델링 과정에서 도출되고 규명되는 수많은 업무규칙(Business Rules)을 데이터 모델에 표현하고 이를 해당 데이터 모델을 활용하는 모든 사용자가 공유할 수 있도록 제공하는 것이다. 특히, 데이터 아키텍처에서 언급되는 논리 데이터 모델(Logical Data Model)에서 이러한 요소들이 포함되어야 함은 매우 중요하다. 예를 들면, 보험사의 사원들은 매월 여러 가지 항목에 대해서 급여를 지급받고 있고 이를 데이터로 관리하고 있다. 각 사원들은 월별로 하나 이상의 급여 항목(기본급, 상여금, 수당, 수수료, 등등)에 대해서 급여를 지급받는다. 여기에 더 나아가 각 사원은 사원 구분별(내근, 설계사, 계약직, 대리점 등)로 위의 급여 항목을 차등적으로 지급받는 다는 업무규칙이 있다. 이러한 내용을 데이터 모델에 나타내야 한다. 이렇게 함으로써 해당 데이터 모델을 사용하는 모든 사용자(개발자, 관리자 등)가 해당 규칙에 대해서 동일한 판단을 하고 데이터를 조작할 수 있게 된다.

라. 데이터 재사용(Data Reusability)

 데이터의 재사용성을 향상시키고자 한다면 데이터의 통합성과 독립성에 대해서 충분히 고려해야 한다. 과거에 정보시스템이 생성·운영된 형태를 되짚어 보면 철저하게 부서 단위의 정보시스템으로 설계되고 운용되어 왔다. 현재 대부분의 회사에서 진행하고 있는 신규 정보시스템의 구축 작업은 회사 전체 관점에서 공통 데이터를 도출하고 이를 전 영역에서 사용하기에 적절한 형태로 설계하여 시스템을 구축하게 된다.
 이러한 형태의 데이터 설계에서 가장 중요하게 대두되는 것이 통합 모델이다. 통합 모델이어야만 데이터 재사용성을 향상시킬 수 있다. 또 한 측면에서 보면 과거 정보시스템의 데이터 구조의 가장 큰 특징은 데이터 모델이 별도로 존재하지 않고 애플리케이션의 부속품 정도로 인식되어져 왔던 것이 사실이다. 이러한 환경에서의 데이터는 프로세스의 흐름에 따라서 관리되게 마련이다. 이렇게 되면 데이터 중복이 많이 발생하고 데이터의 일관성 문제가 심각하게 초래된다.
 데이터가 애플리케이션에 대해 독립적으로 설계되어야만 데이터 재사용성을 향상시킬 수 있다. 정보시스템은 비즈니스의 변화에 대해서 최적으로 적응하도록 끊임없이 요구된다. 하지만 일부 정보시스템의 데이터 모델은 이러한 변화에 대해서 현재의 데이터 구조를 거의 변화하지 않고도 변화에 대응할 수 있는 데이터 구조도 있을 것이고, 아주 적은 확장을 통해서 이러한 변화에 대응하는 것도 있을 것이다.
 하지만, 이러한 변화에 대응하기 위해서 데이터 구조적으로 아주 많은 변화를 주어야만 한다면 변화의 대상이 되는 부분뿐만 아니라 정보시스템의 나머지 부분들도 많은 영향을 받게 될 것이다. 그래서 많은 기업들이 정보시스템을 구축하는 과정에서 데이터 구조의 확장성, 유연성에 많은 노력을 기울이고 있다.
 결국 현대의 기업들이 동종의 타 기업으로부터 경쟁 우위에 자리매김하려고 하다면 구축하는 데이터 모델은 이러한 외부의 업무 환경 변화에 대해서 유연하게 대응할 수 있어야 한다. 특히 근래의 많은 패키지 시스템들이 가지고 있는 데이터 모델들은 확장성을 강조하기 위해서 많은 부분을 통합한 데이터 모델의 형태를 가지고 있다. 여기에서도 잘 나타나듯이 확장성을 담보하기 위해서는 데이터 관점의 통합이 불가피하다. 특히 정보시스템에서의 ‘행위의 주체’가 되는 집합의 통합, ‘행위의 대상’이 되는 집합의 통합, ‘행위 자체’에 대한 통합 등은 전체 정보시스템의 안정성, 확장성을 좌우하는 가장 중요한 요소이다. 데이터 모델이 갖추어야 하는 중요한 요소 중에 하나는 기업이 관리하고자 하는 데이터를 합리적으로 균형이 있으면서도 단순하게 분류하는 것이다.
 아무리 효율적으로 데이터를 잘 관리할 수 있다고 하더라도 그것의 사용, 관리 측면이 복잡하다면 잘 만들어진 데이터 모델이라고 할 수 없다. 동종의 비즈니스를 영위하는 기업이라 하더라도 각 회사의 데이터 모델을 비교해 보면 그 복잡도에는 많은 차이를 나타낸다. A보험사는 계약 업무를 수행하기 위해서 10개의 테이블을 정의하여 업무를 수행하는 반면에 B회사는 100개의 테이블을 정의하여 동일한 업무를 수행하고 있다. 두 회사의 데이터 모델의 차이점은 다음과 같다. 10개의 테이블을 가지고 업무를 수행하고 있는 A회사의 데이터 모델은 간결하지만 새로는 업무 환경의 변화에 대해서 확장성을 가지고 있다. B회사는 겉으로는 새로운 업무 환경의 변화터 모델의 한계로 인해 테이블의 수가 지속적으로 증가해 왔다.
 이렇게 됨으로써 데이터 모델은 간결하지 못하고 동일한 형태로 관리되어야 하는 데이터가 복잡한 형태로 관리되고 그들과의 관계를 가지고 있는 다른 여러 가지의 데이터들 또한 복잡한 형태의 관계들이 불가피 기본적인 전제는 통합이다. 합리적으로 잘 정돈된 방법으로 데이터를 통합하여 데이터의 집합을 정의하고 이를 데이터 모델로 잘 표현하여 활용한다면 웬만한 업무 변화에도 데이터 모델이 영향을 받지 않고 운용할 수 있게 된다.

마. 의사소통(Communication)

 데이터 모델의 역할은 많다. 그 중에서도 중요한 것이 데이터 모델의 의사소통의 역할이다. 데이터 모델은 대상으로 하는 업무를 데이터 관점에서 분석하고 이를 설계하여 나오는 최종 산출물이다. 데이터를 분석 과정에서는 자연스럽게 많은 업무 규칙들이 도출된다. 이 과정에서 도출되는 많은 업무 규칙들은 데이터 모델에 엔터티, 서브타입, 속성, 관계 등의 형태로 최대한 자세하게 표현되어야 한다. 예를 들면, ‘사원’ 테이블에는 어떠한 ‘사원구분’을 가지는 사원들이 존재하는지, ‘정규직’, ‘임시직’ 사원들이 같이 존재하는지, 아니면 또 다른 형태의 사원들이 존재하는지를 표현해야 한다. 더 나아가서 ‘호봉’이라는 속성은 ‘정규직’일 때에만 존재하는 속성인데 이러한 업무 규칙이 데이터 모델에 표현되어야 한다. 또한, 우리가 관리하는 사원들 중에서 ‘정규직’ 사원들만이 ‘급여’ 테이블과 관계를 가진다. 이러한 부분은 개별 관계로 데이터 모델에 표현되어야 한다. 이렇게 표현된 많은 업무 규칙들을 해당 정보시스템을 운용, 관리하는 많은 관련자들이 설계자가 정의한 업무 규칙들을 동일한 의미로 받아들이고 정보시스템을 활용할 수 있게 하는 역할을 하게 된다. 즉, 데이터 모델이 진정한 의사소통(Communication)의 도구로서의 역할을 하게 된다.

바. 통합성(Integration)

 기업들이 과거부터 정보시스템을 구축해 왔던 방법은 개별 업무별로의 단위 정보시스템을 구축하여 현재까지 유지보수를 해오고 있는 것이 보통이다. 점진적인 확장과 보완의 방법으로 정보시스템을 구축해 왔기 때문에 동일한 성격의 데이터임에도 불구하고 전체 조직관점에서 보면 여러 곳에서 동일한 데이터가 존재하기 마련이다.
 특히 이러한 데이터 중에서도 고객, 상품 등과 같이 마스터 성격의 데이터들이 분할되어 관리됨으로 인해 전체 조직 관점에서 데이터 품질, 관리, 활용 관점에서 많은 문제점들이 나타나고 있는 것이 현실이다.
 가장 바람직한 데이터 구조의 형태는 동일한 데이터는 조직의 전체에서 한번 만 정의되고 이를 여러 다른 영역에서 참조, 활용하는 것이다. 물론 이 때에 성능 등의 부가적인 목적으로 의도적으로 데이터를 중복시키는 경우는 존재할 수 있다.
 동일한 성격의 데이터를 한 번만 정의하기 위해서는 공유 데이터에 대한 구조를 여러 업무 영역에서 공동으로 사용하기 용이하게 정의할 수 있어야 한다. 이러한 이유로 데이터 아키텍처의 중요성이 한층 더 부각되고 있다.

발훼 DB GUIDE