Powerful PowerDesigner

속성 후보 도출

속성을 결정할 때에도 다양한 후보를 준비하고 이들 중에서 속성의 검증 규칙에 부합하는 것을 속 성으로 최종 결정하게 된다. 특히 이러한 후보 도출 작업은 기존의 현장조사에 국한하지 않고 좀더 적극적이고 개선적인 사고를 가지고 사용자에게 많은 질문을 하고 확인해 속성 후보를 도출한다.

속성 후보 수집처

속성은 결국 속성 후보 중에서 선택되기 때문에 우리는 일단 다양한 경로를 통해서 좋은 후보를 가 능하다면 최대한 많이 확보해야 한다.

1) 구 시스템의 문서자료

가동 중인 기존 시스템의 데이터 구조 및 프로세스 명세들이 나타나 있는 설계 자료에서부터 사용 자를 위한 지침서에 이르기까지 다양한 도큐먼트가 있을 것이다. 이 자료는 엔터티 후보 및 속성 후 보를 도출하는데 가장 유용하게 사용할 수 있다.

2) 현업 장표/보고서

현업에서 사용하고 있는 각종 장표나 보고 자료들을 수집해서 조사해 보는 것이다. 현업 업무 중에 는 업무를 효과적으로 처리하기 위하여 많은 장표와 각종 보고 자료를 만들고 있다. 물론 이들을 그대로 속성 후보로 선정할 수 있는 것은 결코 아니다. 그 중의 상당 부분은 다른 속성에 의해 만들어질 수 있는 가공된 결과(추출 속성, Derived Value)인 경우가 많기 때문이다. 더구나 이것들은 대부분 정규화가 되어 있지 않기 때문에 정확히 파악해야만 진정한 의미의 속성 후보를 찾아낼 수 있다.

3) 사용자와 협의

데이터 모델링 과정에서부터 시종일관 현업 담당자들과 같이 진행하는 것이 데이터를 모델링하는 최상의 방법이다.

4) DFD의 DD(Data Dictionary)

업무 파악 및 시스템 분석을 위한 기능 설계로 자료 흐름도가 존재한다면 여기에 있는 데이터 저장 소(Data Store)와 데이터 사전(Data Dictionary)에 있는 정보를 이용하여 속성의 후보를 도출할 수 있다. 자료 흐름도를 작성할 때 생성되는 자료 저장소는 비록 테이블처럼 표현되지만 사실은 이러 한 내용의 데이터가 저장되어야 한다는 데이터의 추상화된 집합이라 할 수 있으며, 그 속에 들어가야 할 구체적인 속성이 데이터 사전에 기술된다.

5) 전문 서적 및 자료

동일한 업무에 대한 전문 서적 또는 자료를 통해서도 속성의 후보를 도출할 수 있다.

6) 다른 시스템 자료

우리가 개발할 시스템의 주변을 살펴보면 사내외에 이와 관련된 시스템이나 유사한 시스템을 찾을 수 있을 것이다. 만약 여러분이 그들이 가지고 있던 속성 또한 후보로서 참조하는 것도 속성 후보를 찾는데 좋은 방법이다.

속성 후보 선정 원칙

속성의 후보를 선택할 때는 최대한 충분히 수집해야 한다. 그것은 검토한 결과 자신의 속성이 아닌 것으로 판명될지라도 검토할 기회를 제공해 주는 단서라는 중요한 역할을 하기 때문이다.

1) 원시(Source) 속성으로 보이는 후보는 버리지 않는다

다른 속성에 의해 다시 재현할 수 있는 가공(추출, Derived) 속성이 아닌, 다시 말해서 만약 이 속 성이 없다면 다시는 재현할 수가 없을 때 이 속성을 원시 속성이라고 부른다. 재현이 불가능하다면 이것을 버리는 순간, 이미 정보는 소실되어 버리므로 절대 버려서는 안 된다.

2) 소그룹별로 후보군(Pool)을 만들고 가장 근접한 엔터티에 할당한다

모든 엔터티가 정의되어 있는 상태가 아니라 단지 핵심 엔터티들을 대상으로 모델링을 실시해왔을 뿐이므로 아직은 모든 엔터티가 드러나 있지는 않다. 그렇기 때문에 각 속성 후보들을 적절한 데이터 그룹으로 생성하여 두는 것이 필요하다.

속성의 기본 구성요소

1) 속성명

속성의 내용이나 목적이 무엇인지 알려주는 명사 또는 명사구이다. 기업에서 널리 사용하는 용어 를 쓴다.

·         속성의 의미를 명확히 표현하는 함축성 있는 명사 혹은 명사구를 사용한다.

·         해당 업무에서 일반적으로 사용하는 용어를 사용한다.

·         실체명은 속성명으로 사용하지 말아야 한다.

·         필요시 표준 약어를 제정하여 속성명을 생성하고 그 속성명을 단 하나의 실체에만 속하도록 하는 것이 바람직하다.

2) 도메인

속성이 지닐 수 있는 값에 대한 업무적인 제약 조건으로 파악된 일련의 특성이다. 모든 영역에서 같은 도메인을 사용하는 것이 좋다. 속성이 기존 도메인 집합에 속해 있지 않는 경우에는 새로운 도 메인을 추가한다. 도메인은 다음과 같은 속성들을 가진다.

·         데이터 타입

·         길이

·         허용 값(Permitted Value): 속성에 지정할 수 있는 모든 값들의 집합

·         디폴트 값 및 디폴트 알고리즘

3) 선택성

모든 건의 해당 속성이 반드시 값을 가져야 하는지 여부를 나타낸다.

·         선택성 조건 =} 선택성이 다른 속성 값에 의해 영향을 받는 경우

·         필요조건 / 금지조건 / 무관계조건

속성 개념

속성 정의

속성은 엔터티에서 관리되는 구체적인 정보 항목으로 더 이상 분리될 수 없는 최소의 데이터 보관 단위이다. 예를 들어, 엔터티 사원에 속하는 모든 엔터티는 이름을 갖고 있다. 또한 모든 사원에는 입사일자, 사원번호, 생년월일 등의 특성을 가지고 있다. 엔터티 사원에 속하는 모든 인스턴스들이 공통으로 가지는 이러한 특성을 속성(Attribute)이라고 한다. 각 엔터티들은 일련의 속성들에 의해 상세화될 수 있다.

속성 특징

1) 속성의 어원적 의미

속성이라는 의미에는 가공되지 않은 것이라는 의미도 포함되어 있다. 이 말은 곧 원천적인 것을 의 미한다. 또한 고유한 성질이란 의미도 가지고 있는데 이 말은 남의 도움을 받지 않더라도 자기만이 가지고 있는 독자적인 성질이 반드시 있어야 함을 뜻한다. 혼자서도 독자적인 성질을 가지고 있느냐 에 대한 문제는 절대적이 아니라 상대적이라는 것 때문에 판단이 쉽지 않다. 즉 어떤 시스템의, 어떤 엔터티에서, 어떤 목적으로 사용하려고 하느냐에 따라서 달라지기 때문에 사람의 종합적인 판단이 필요하다는 것이다. 이러한 속성의 어원적인 특징들은 속성 검증의 원칙으로도 사용된다.

2) 속성도 일종의 집합이다.

물리 데이터 모델링 단계에서 엔터티는 테이블이 되고, 속성은 칼럼이 된다. 결국 속성에는 데이터 값이 들어가게 되며, 그 값들은 여러 종류를 가지게 된다. 가령, 사원 정보 엔터티의 직책 속성에는 사원, 대리, 과장, 부장 … 등 여러 종류의 값들이 존재한다. 만약 이 값들의 종류 하나 하나를 개체 라고 한다면, 직책이란 속성은 결국 이들을 구성요소로 하는 집합이란 뜻이 된다.

3) 릴레이션십도 속성이다.

물리 데이터 모델링 단계에 가서 보면 릴레이션십 또한 결국은 일종의 속성이 될 수 밖에 없다.

[그림 1]에서 매출 부서는 엄격히 말해서 매출 엔터티의 속성이 아니라 부서 엔터티와의 릴 레이션십이라고 하는 것이 정확한 표현이다. 사실 이론적으로 따진다면 속성은 전체 엔터티를 통 틀어 반드시 유일하게 존재해야만 한다. 나 자신(속성)은 우리집(엔터티)에 속하고, 거기서 유일하지만 다른 모든 것(엔터티)들에 대해서도 반드시 유일한 존재이다.

매출 엔터티에 있는 매출 부서 속성에는 나중에 분명히 부서 코드가 들어온다. 부서 코드 속성이 오직 한 곳에만 위치해야 한다면 반드시 부서 엔터티에 있어야만 한다. 이 말은 다른 엔터티에 있 는 모든 부서 코드는 사실 모두가 릴레이션십이라는 것을 의미한다. 이 릴레이션십은 나중에 데이 터베이스 설계 단계에서 관계형 데이터베이스로 설계하고자 한다면 매출 테이블에 매출 부서라는 외래키 칼럼으로 존재하게 된다.

나) 매출 상품 릴레이션십

[그림 1]의 좌측에 있는 매출 상품 릴레이션십은 속성이 아닌 릴레이션십으로 제대로 표현 되어 있다. 설계 단계에서 결과적으로 동일해지는데 굳이 이것을 릴레이션십으로 표현하여 그림을 복잡하게 할 필요가 있겠는가?

물론, 원론적으로 본다면 이를 무조건 릴레이션십으로 표현하는 것이 옳다는 것에는 이견이 있 을 수 없다. 왜냐 하면 우리가 작성하는 논리적 데이터 모델이란 업무를 체계적으로 형상화하는 것 이지 데이터베이스의 구조를 정의하는 것이 아니기 때문이다. 엄격히 말한다면 논리적 데이터 모 델에는 데이터베이스나 컴퓨터와 같은 물리적 요소들은 전혀 감안하지 않은 상태에서 정의되어야 한다.

4) 속성들 간은 서로 독립적이다

속성들은 반드시 식별자에 직접 종속되어야 한다. 이 말은 정규화의 제2정규형에 해당하는 말이 다. 만약 속성들 간에 종속성이 존재한다면 이들은 별도의 엔터티로 분리되어야 한다. 이것이 바로 제3정규형이다.

출처 : DB 포탈 사이트 DBguide.net

논리 데이터 모델링 정의

논리적 데이터 모델링이란 데이터베이스 설계 프로세스의 Input으로써 비즈니스 정보의 구조와 규칙을 명확하게 표현하는 기법이다. 논리적 모델은 데이터 모델링이 최종적으로 완료된 상태를 말한다. 즉, 물리적인 스키마 설계를 하기 전단계의 데이터 모델 상태를 일컫는 말이다.

논리적 데이터 모델링의 핵심은 어떻게 데이터에 액세스하며, 누가 데이터에 액세스하며, 그러한 액세스의 전산화와는 독립적으로 비즈니스 데이터에 존재하는 사실을 인식·기록하는 기법일 뿐만 아니라 철학이다.

특히 데이터 모델링 과정에서 가장 핵심이 되는 부분이 논리 데이터 모델링이라고 할 수 있다. 데이터 모델링이란 모델링 과정이 아닌 별도의 과정을 통해서 조사하고 결정한 사실을 단지 개체-관계 다이어그램(ERD, Entity Relationship Diagram)이라는 그림으로 그려내는 과정을 말하는 것이 아니다. 시스템 구축을 위해서 가장 먼저 시작할 기초적인 업무조사를 하는 초기 단계부터 인간이 결정해야 할 대부분의 사항을 모두 정의하는 시스템 설계의 전 과정을 지원하는 과정의 도구라고 해야 할 것이다.

논리 데이터 목적 및 효과

해당 비즈니스에 대한 데이터 관점에서의 명확한 이해

데이터 모델링을 한마디로 하면 업무의 데이터 관점에서의 표현 또는 설계라고 할 수 있다.

전사적인 통합 데이터 체계 확립

논리 데이터 모델링을 통하여 전사의 데이터에 대한 구조를 체계화하고 이를 통한 통합 데이터 체계를 확립한다.

데이터의 일관성 및 정확성 유지를 위한 규칙 도출

기업이 관리하는 데이터의 일관성, 정확성을 유지하기 위해서는 데이터에 대한 정확한 업무 규칙과 데이터 처리 규칙들을 생성 관리해야 한다. 이것을 표현하고 관리하는 것은 논리 데이터 모델을 통해서 하게 된다.

안정적인 데이터베이스 설계의 토대 마련

논리 데이터 모델을 통하여 물리 데이터 모델이 생성된다. 특히 데이터 모델의 구체적인 실체(객체)인 데이터베이스를 안정적이고 체계적으로 생성하는 기초가 된다.

사용자와의 명확한 의사소통을 위한 수단으로 활용

시스템 설계자와 업무 담당자 간의 의사소통의 수단으로 논리 데이터 모델이 사용된다. 반면 설계자와 개발자 간의 의사 소통의 수단은 물리 데이터 모델이라고 볼 수 있다. 하지만 이 과정에서 개발자라고 하더라도 논리 데이터 모델에 표현되어 있는 비즈니스 규칙에 대한 이해가 선행되어야 한다.

논리 데이터 모델링 필수 성공요소

업무에 능통한 현업 사용자와 함께 데이터 모델링을 진행하라

데이터 모델링 작업은 결국 업무를 데이터 관점에서 체계화하는 작업이다. 즉, 비즈니스에서 사용되는 데이터를 집합(엔터티)으로 생성하고 이들 간의 관계(Relationship)를 지정하는 작업이다. 이러한 작업을 하는 과정에서 업무를 알고 있는 현업 사용자의 참여는 필수적이다.

절차(Procedure)보다는 데이터에 초점을 두고 모델링을 진행하라

데이터 모델에는 순서와 시간, 흐름의 개념이 들어가지 않는다. 이러한 개념을 넣어서 마치 데이터 흐름도(DFD, Data Flow Diagram)처럼 업무의 흐름에 따라 엔터티가 발생하는 경우를 실전에서는 많이 보게 된다. 이런 식의 데이터 모델에서는 많은 데이터의 중복과 데이터 정합성을 훼손할 개연성을 내포한 모델이 만들어지게 마련이다. 그렇기 때문에 가능한 절차를 배제한 채로 데이터 모델을 생성해야 한다.

·         데이터의 구조(Structure)와 무결성(Integrity)을 함께 고려하라

·         개념화(Conceptualization)와 정규화(Normalization) 기법을 적용하라

·         가능하면 다이어그램(Diagram)을 이용하여 업무를 표현하라

·         데이터 모델링을 지원하는 데이터 사전을 구축하라

출처 : DB 포탈 사이트 DBguide.net

개념

엔터티란?

• 엔터티란 업무 활동상 지속적인 관심을 가지고 있어야 하는 대상으로서 그 대상에 대한 데이터를 저장할 수 있고 대상들 간의 동질성을 지닌 개체 또는 행위의 집합
• 엔터티를 정의할 때는 어떤 대상이 그 엔터티에 속하는지 혹은 속하지 않는지를 명확하게 정의할 수 있어야 한다.
• 예를 들어 영화배우라는 엔터티를 영화에서 극중 배역으로 분하여 연기하는 사람(?)으로 정의한 경우에 파트라슈는 주연이지만 배우인지 아닌지를 명확히 정의할 수 있어야 한다.

엔터티 정의의 요건

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

의미상 주어 정의

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

본질 식별자 정의의 의의

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

본질 식별자 정의 예

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

출처 : DB 포탈 사이트 DBguide.net

주제 영역 개념

주제 영역(Subject Area)은 기업이 사용하는 데이터의 최상위 집합이다. 예를 들어, 제조 업체의 경우 인사, 생산, 자재, 판매 등의 주제 영역이 있을 수 있다. 하나의 주제 영역으로 정의되는 데이터간의 관계는 밀접하고, 다른 주제 영역에 포함되는 데이터간의 상호작용은 최소화할 수 있도록 정의한다. 데이터는 기본적으로 관계 구조로 표현된다. 관계 구조는 데이터간의 관계가 복수개로 표현되면서 서로 연결되어 있기 때문에 하향식(Top-down) 분석이 용이하지 않다. 계획 수립 단계는 하향식 분석을 원칙으로 하고, 검증을 위해서 부분적으로 상향식 분석을 사용한다. 데이터를 하향식으로 분석하기 위한 개념으로 유용한 것이 주제 영역이다. 주제 영역은 계층적으로 표현될 수 있다. 주제 영역을 분해하면 하위 수준의 주제 영역이나 엔터티가 나타난다.

주제 영역 명명

 1. 보편적 업무 용어 사용

  실제 업무에서 보편적으로 사용하는 업무 용어를 부여하는 것이 바람직하다 예) 인사, 생산, 판매, 구매, 재무 등

 2. 단수형 명사 사용

  유일한 단수형 명사를 사용한다

 3. 데이터 그룹을 의미하는 용어 사용

데이터의 그룹을 의미하는 이름을 부여한다 업무 활동(Activity)을 의미하는 이름을 배제하고 데이터 그룹을 의미하는 이름을 사용하도록 한다.

주제 영역 활용

 1. 목적

• 데이터의 계층적 구조 파악하는데 도움이 된다.
• 업무 기능(Function)과 병행하여 분석하는 경우에 분석의 최상위 단위 역할을 하여 품질 확보에기여한다.
• 주제 영역 계층과 업무 기능 계층 간의 대응 관계를 확인한다.

 2. 장점

• 데이터 및 업무 활동 모델의 품질보증(Quality Assurance)
• 프로젝트 관리(Project Management) 용이
• 모델 개발 조정(Development Coordination) 용이
• 리포지터리(Repository) 관리 용이
• 상세 사항의 전개 혹은 축약 가능

주제 영역 도출

 1. 업무에서 사용하는 데이터의 명사형 도출

      정보 수집 소스로부터 명사형 찾기

 2. 업무 기능의 이름으로부터 도출

     데이터와 업무 활동의 상호 보완 관계

 3. 하향식(Top-down) 접근 방법

    주제 영역에서 출발하여 엔터티 타입으로 전개

 4. 상향식(Bottom-up) 접근 방법

    엔터티 타입을 그룹핑하여 주제 영역 도출

 5. 분석 단계에서의 도출

   아키텍처 모델(Architecture Model)을 정련하는 과정에서 도출

   데이터 모델을 상세화하는 과정에서 도출

주제 영역 정의 내용

 주제 영역 목록

 레벨 : 주제 영역의 계층 수준 (1차, 2차, ... 단위)

 주제 영역명

 설명 (단위 주제 영역의 경우)

 대표 엔터티 : 해당 주제 영역 내에서 대표적인 엔터티를 기술한다.

출처 : DB 포탈 사이트 DBguide.net

관계(Relationship)란 ?


 관계도 집합이다

 릴레이션십(Relationship)이란 엔터티와 엔터티 사이의 관계를 말한다. 즉, 우리가 관리하고자 하는 업무 영역 내의 특정한 두 개의 엔터티 사이에 존재하는 많은 관계 중 특별히 우리가 관리하고자 하는 직접적인 관계를 의미한다.
 관계는 두 엔터티 사이에 그 목적과 내용이 다른 여러 개의 관계가 동시에 존재할 수 있다. 마치 교통량이 너무 많거나 좀더 나은 이동을 위해 특수 목적을 가진 더 세분화된 교량을 추가할 수도 있고, 작은 교량을 없애고 커다란 교량으로 통합할 수도 있듯이 관계 또한 크게 묶을 수도 있고, 구체적으로 분할시킬 수도 있다.

 직접 관계를 관계라고 한다

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

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

두 개의 엔터티 사이에는 서로 다른 업무 규칙을 가진 별개의 관계가 존재 할 수 있다.
보험계약과 고객과의 관계는  계약자 관계는 1:M이지만 피보험자 관계는 M:M이 될 수 있다. 물론 명의변경을 할 수도 있고 그 이력까지 관리하겠다고 한다면, 계약자 관계도 다시 M:M이 된다. 보험 종류에 따라 하나의 보험계약에 여러 명의 고객이 피보험자가 될 수 있으며, 고객 또한 하나 이상의 보험계약에 피보험자가 될 수 있으므로 이 관계는 당연히 M:M 릴레이션십을 가진다

 외래키로 정의

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

참조무결성 : 제3장-제3절-4항 참조무결성 규칙 정의 참조

 관계의 관점

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

 출처 : DB 포탈 사이트 DBguide.net

개념 데이터 모델 정의

개념적 데이터 모델이란 건물로 말하면 철제빔으로 건물의 골격을 세워 놓은 형태와 유사하다. 건 물의 골격이 주요 골조 자재로 구성되어 있듯이 개념 데이터 모델도 주요 핵심 엔터티들로 구성된다. 핵심 엔터티란 행위의 주체나 목적물이 되는 개체 집합에 해당하는 엔터티를 의미한다. 이들은 부모가 존재하지 않는 창조된 집합이어서 다른 집합의 존재 유무에 상관없이 독립적으로 탄생할 수 있다. 핵심 엔터티는 대체적으로 여러 가지 하위의 행위 엔터티를 탄생시킨다.

개념 데이터 모델 의의

개념 데이터 모델은 단지 대상을 주요 핵심 엔터티로 한정한다는 것일 뿐이지 모델링 기법은 논리적 모델링과 특별히 다를 것이 없다. 만약 우리가 하향식으로 데이터아키텍처를 수립해 간다면 개념적 모델은 개괄적 모델을 좀더 상세화된 형태로 진화시키거나 중요 엔터티만 선정하여 모델링을 함으로써 탄생된다. 물론 이후에도 모델링의 상세화는 계속되어 갈 것이며, 필연적으로 개념적 모델도 따라서 약간씩 변화가 일어날 수 밖에 없다. 하지만, 개념 데이터 모델은 앞으로 아무리 상세한 모델링이 진행되더라도 전체적인 골격은 개념적 모델을 벗어나지 않는다는 것이다.

데이터아키텍처 프레임워크 상에서 개념 데이터 모델

엔터프라이즈아키텍처에서 개념 레이어는 최상위의 개괄 레이어와 하위의 논리 레이어 중간에 존재하는 레이어이다. 데이터아키텍처에서는 개괄 데이터 모델과 논리 데이터 모델 사이에 존재하는 모델이라고 할 수 있다. 여기에서 개괄 데이터 모델는 흔히 사용되어지는 주제영역 관계도와도 대응되는 부분이라고 할 수 있다. 개념 데이터 모델은 상위의 주제영역별로 핵심 엔터티와 핵심 속성, 또한 핵심 엔터티들 사이의 관계들로 이루어진 데이터 모델이라고 할 수 있다. 아키텍처의 개념을 종종 건축물에 비유하곤 한다. 개념 데이터 모델을 건축물에 비유해 보면 건물의 기둥들과 중요 벽체들로만 만들어진 건물 설계 도면에 비유할 수 있다. 이 단계에서 정의된 핵심 엔터티들과 관계들을 기반으로 논리 데이터 모델에서는 업무 요구사항에 기반한 세부 데이터 모델이 생성되게 된다.

출처 : DB 포탈 사이트 DBguide.net

서브타입

확장된 개체-관계 다이어그램은 서브타입의 개념을 도입했다. 서브타입은 정확한 의미로는 서브 타입 엔터티이며 그것의 전체집합인 슈퍼타입(Supertype)의 부분집합이다. 예를 들어 학생들은 학 부학생이나 대학원생으로 분류될 수 있다. 이 경우 학생이 슈퍼타입이고 학부학생과 대학원생은 서브타입이다.

[그림 3]은 바커 표기법에 따른 서브타입 표현으로, 슈퍼타입인 사원은 서브타입인 내근사 원, 설계사, 대리점을 가지고 있다. 슈퍼타입은 세 서브타입에 공통적인 모든 속성을 포함하고 있고 서브타입은 각 서브타입에 적절한 속성만을 포함하고 있다.

                                                                           [그림 4]

[그림 3]에서 속성‘사원구분’은 내근사원, 설계사, 대리점인지를 가리킨다. 어떤 서브타입 이 적합한지를 결정해 주는 속성을 구분자(Discriminator)라고 부른다. IE 표기법을 사용하는 툴을 사용하면 [그림 5]와 같이 구분자는 서브타입 부호 바로 옆에 나타난다. 모든 슈퍼타입이 구분 자를 가지고 있는 것은 아니다. 만일 구분자가 없다면 적합한 서브타입을 생성하기 위해 응용 코드가 작성되어야 한다. 서브타입은 배타적(Exclusive) 또는 포괄적(Inclusive)일 수 있다. 만약 배타적이 라면 슈퍼타입은 많아야 1개의 서브타입과 관련될 수 있다. 만약 포괄적이라면 슈퍼타입은 1개 또는 그 이상의 서브타입과 관련될 수 있다. [그림 5]는 서브타입 MANAGER와 DB_ADMIN을 가진EMPLOYEE 슈퍼타입을 보여주고 있다. 돔 안의 X는 서브타입이 배타적인 것을 의미한다. 따라서 사원은 MANAGER나 DB_ADMIN 중 하나가 될 수 는 있으나 둘 다 될 수는 없다. [그림 6] 은 이러한 동일한 서브타입을 포괄적으로 보여주고 있다. 여기서 사원은 MANAGER, DB_ADMIN, 또는 양쪽 모두 될 수도 있다. 슈퍼타입은 두 개 이상의 서브타입과 관련되므로, 포괄적 서브타입은 구분자를 가지고 있지 않다.

                                                             [그림 6]

출처 : DB 포탈 사이트 DBguide.net

카디날리티(Cardinality)

개체-관계 다이어그램은 데이터베이스가 지켜야 할 제약 조건들을 명시할 수 있다. 중요한 제약 조건 중의 하나로 연결(Connectivity)이라는 것이 있는데, 이는 한 개체가 관계를 통하여 다른 개체 와 관련된 개체들의 수를 나타낸다. 관계의 연결은 1:1, 1:M, M:M으로 분류된다. 개체-관계 다이어 그램에서는 관계의 연결을 1, M 을 사용하여 표현하며 [그림1]의 예와 같다. 표기법에 따라서 는 M:M을 M:N으로 표현하기도 하나 여기서는 M:M으로 나타내기로 한다.

                                                                      [그림 1]

• 일대일(One To One, 1:1) : X에 속하는 한 개체는 Y에 속하는 한 개체에만 연결되며, Y에 속하는 한 개체도 X 에 속하는 한 개체에만 연결된다.
• 일대다(One To Many, 1:M) : X에 속하는 한 개체는 Y에 속하는 한 개체에만 연결되며, Y에 속 하는 한 개체는 X에 속하는 여러 개체들과 연결된다.
• 다대다(Many To Many, M:M) : X에 속하는 한 개체는 Y에 속하는 여러 개체들과 연결될 수 있 으며, Y에 속하는 한 개체도 X에 속하는 여러 개체들과 연결될 수 있다.

또한 카디날리티(Cardinality)란 관계에 참여하는 하나의 개체에 대해 다른 엔터티에서 몇 개의 개체가 참여하는지를 나타낸다. 예를 들면 한 명의 학생이 1개 이상 6개 이하의 과목에 등록할 수 있 다면 카디날리티는 (1, 6)이다. 한 명의 교수는 최대 3개의 과목을 가르칠 수 있다면 카디날리티는(0, 3)이다. 카디날리티는 (Min, Max)의 한 쌍의 값으로 표현하는데 여기서 Min은 관계에 참여하는 개체의 최소 개수, Max는 관계에 참여하는 최대 개수를 각각 의미한다. 여기서 Max의 값이 M으로 표시되면 최대 개수에 제한이 없음을 의미한다. [그림 2]에서 PROFESSOR-COURSE의 관 계를 살펴보면 다음과 같이 해석할 수 있다.

                                                                       [그림 2]

1) PROFESSOR-COURSE는 1:M 관계이다.

2) PROFESSOR의 카디날리티는 (0, 3) 이다. 즉 각 교수는 3개 이하의 과목을 가르칠 수 있다.

3) COURSE의 카디날리티는 (1, 1)이다. 즉 각 과목을 가르치는 교수는 반드시 1명이어야 한다.

출처 : DB 포탈 사이트 DBguide.net

식별자

엔터티의 각 개체들은 인스턴스라고 하는데, 인스턴스는 그들을 지칭하거나 식별해 주는 속성인 식별자(Unique Identifier)를 가지고 있다. 예를 들어 직원 인스턴스는 직원번호, 주민번호, 직원명 으로 식별될 수 있다. 이들 중 직원명은 실세계에서는 직원 각각을 식별하는데 이용될 수 있으나 데 이터 측면에서는 동명이인의 문제 때문에 식별성이 미약한 편이다. 봉급이나 입사일 같은 속성으로 는 각각의 인스턴스를 유일하게 식별할 수 없다. 이와 마찬가지로 고객은 고객번호나 고객이름으로 식별될 수 있고, SALES-ORDER은 OrderNumber(주문번호)에 의해서 구별될 수 있다.

식별자는 하나 또는 그 이상의 속성으로 구성된다. 특별히 두 개나 그 이상의 속성으로 이루어진 식별자를 복합 식별자(Composite Identifier)라고 부른다. 그 예로는 (Area Code, Local Number), (Project Name, Task Name), (First Name, Last Name, Date Of Hire) 등이 있다.

식별자와 키는 구별하여 사용되어야 하며, 이 둘은 서로 일치할 수도 있고 그렇지 않을 수도 있다. 즉 식별자는 논리적인 관점에서 사용되고 키(Key)는 물리적인 관점에서 사용된 키를 가진다고 할 수 있다. 이러한 이유로서 식별자가 엔터티에 대해 하는 역할은 키가 테이블에 대해 하는 역할과 동일하다.

데이터 모델링의 초기 단계에서부터 모델을 지나치게 상세히 표현하면 개체-관계 다이어그램을 이해하고 다루기가 힘들어질 수도 있기 때문에  간단하게 식별자만 보이거나  직사각형 안에 개체 이름만 간결하게 보임으로써 많은 모델들 중에서 사용자가 필요한 것들을 손쉽게 사용되어질 수 있다.

관계(Relationship)

관계는 엔터티와 엔터티간 연관성을 표현하는 것으로, 엔터티의 정의에 따라 영향을 받기도 하고, 속성 정의 및 관계 정의에 따라서도 다양하게 변할 수 있다. 엔터티간에 논리적으로 존재할 수 있는 수 많은 관계들 중에서 정말로 의미가 있고 관리할 가치가 있는 관계를 식별해 낸다는 것이 쉬운일은 아니다. 최초의 개체-관계 다이어그램에서 관계는 속성을 가질 수 있었으나 현재에는 그렇지 않다.

관계의 표현에는 이항 관계(Binary Relationship), 삼항 관계(Ternary Relationship), n항 관계 가 존재할 수 있는데 실제에 있어서 삼항 관계 이상은 잘 사용되지 않는다. [그림 1] 참조 매핑 카디날리티(Mapping Cadinality)는 개체-관계 다이어그램에서 개체와 연결될 때 나타나는 대응(Mapping)되는 수로 대응수라고도 한다. 대응수는 최대 대응수(Maximum Cadinality)와 최 소 대응수(Minimum Cadinality)로 구분된다. 매핑 카디날리티가 포함된 개체-관계 다이어그램에 대하여 예제를 통해서 설명하고자 한다. [그림 1] 참조 다음과 같은 조건 하에서 교수 개체와 학생 개체 간에 성립하는 지도 관계의 매핑 카디날리티를 결 정하고, 개체-관계 다이어그램을 작성하면 [그림 5-1-13]과 같은 이항 관계 구조의 다이어그램을 완성할 수 있다.

• 조건 1 : 교수는 꼭 학생에 대한 지도를 해야 한다.
  
  Min-Card(교수, 지도) = 1
• 조건 2 : 교수는 여러 명의 학생을 지도할 수 있다.
  
  Max-Card(교수, 지도) = n
• 조건 3 : 학생은 꼭 교수에게 지도를 받아야 한다.
  
  Min-Card(교수, 지도) = 1
• 조건 4 : 학생은 여러 명의 교수에게 지도를 받을 수 없다.
  
  Max-Card(교수, 지도) = 1

                                                              [그림 1]

출처 : DB 포탈 사이트 DBguide.net