데이터 모델링2010. 12. 31. 05:06

Inheritance 는 좀 더 포괄적인 Entity 로부터 특별한 경우의 Entity 를 정의하는 경우 사용합니다. Inheritance 에 포함되는 Entity 들은 상호간에 매우 유사한 특성을 지니 고 있으며 일부 다른 특성을 가지고 있습니다.
 

포괄적인 Entity 는 통상적으로 모든 공통적인 특성을 가지는 Super-type (혹은 Parent) Entity 라고도 합니다. 각 Notation 의 Inheritance 상태를 표시하는 심볼은 다음과 같습니다.

 

IDEF1X

ER/Merise

설명

 



사용자 삽입 이미지

 

사용자 삽입 이미지

표준 상속

 

 

사용자 삽입 이미지

상호 배타적 상속 ( Entity

의 한 버는 자식 Entity 나에 만 할 수 있음 : 의 사은 일반직이 보조직 일 없음)

 

사용자 삽입 이미지

 

사용자 삽입 이미지
 

 

완전 ( Entity 들의

주화가 우로 이상 가 적인 자식 Entity 포함되지 않을 것을 의미)

 

 

사용자 삽입 이미지

 

상호 배타이며 완전

 

Posted by choi1779
데이터 모델링2010. 11. 19. 04:46

개념 데이터 모델링 작업 시 자주 사용되는 용어 입니다. Data Item, Package 등은 PowerDesigner 에서만 제공하는 특별한 기능입니다.



 

용어

해당

범위

 

내용

CDM

(Conceptual Data Model)

System

  논리적인 정의를 Model , Entity등을 정의

PDM

(Physical Data Model)

System

  Table, View, Index, Trigger등을 물리DB 항목들 을 정의하고, 그리는 Model

Package

모든

Model

  모델에서 부적으로 누는 단위 모델링 주제 영 역의 개념 Depth 제한은 없음(모델 속의 )

 

사용 ) DBMS User 으로 주제영역 분이 가 능한 경우의

 

1 수준 : DB User

2 수준 : 업무구분

3 수준 : 세부 업무 구분

 

  패키 구성 증가 함으 고려하 사용

Documents

모델

파일

PowerDesigner 모델 총칭

Data Item

CDM

  CDM에서 사용되는 정보의 기본 단위로써 Entity 에 속하게 되면 Attribute가 되며 CDM에서 PDM을 생성하는 경우 테이블의 Column이 됨.

 

  Entity에 속하지 않는 Data Item 정의가 가능하며 이런 Data  Item 은 모델에 정의된 상태로 있다가 Entity에서 필요한 경우 어느 때라도 사용이 가능함.

Domain

CDM PDM

  Model에서 사용하는 정보의 종류를 확인하는데 도움을 주며 도메인을 Data Item에 적용하여 서로 다른 Entity Attribute 들의 데이터 표준화를 쉽게 하도록 도와줌.

Entity

CDM

 사용자가 저장하고자 하는 정보를 정보시스템에 정의한 객체

Attribute

CDM

  Entity,  Association,  inheritance에 속한 Data  Item으로 PDM을 생성하게 되면 EntityAttributeTableColumn이 됨.

Identifier

CDM

  Entity  내용을  유일하게  구별할   있도록  하는 값을 가지는 Entity Attribute 혹은 Entity Attribute들의 조합.

 

  IdentifierPDMPrimary  Key  혹은 Alternate  Key와 동일함.

 

  Entity는 적어도 하나의 Identifier를 가져야 하며 만 약 Entity가 오직 하나의 Identifier를 가지고 있다면 기 본으로 EntityPrimary Identifier로 지정됨.

Relationship

CDM

—  Entity 간에 존재하는 상호관계를 의미하며 Entity 간의

Link     표시됨.(:  직원과 팀 Entity 사이의

Relationship, 직원은 팀에 속하고 팀은 직원들로 구성)

Inheritance

CDM

  좀 더 일반적인 Entity 의 특정한 경우의 Entity를 정의 하는데 이용되며 Inheritance 에 속한 Entity 들은 다른 점들이 있긴 하지만 많은 공통적인 특성을 가지고 있 음.

 

  특정한  경우의  Entity들을  SubType(child)이라고  하며 PDM 으로 전환 시 부모 Entity 와 자식 Entity 를 어떤 형 식으로 생성할지를 CDM 단계에서 지정이 가능함.

Posted by choi1779
데이터 모델링2010. 7. 2. 04:49

개념

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

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

의미상 주어 정의

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

본질 식별자 정의의 의의

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

본질 식별자 정의 예

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


출처 : DB 포탈 사이트 DBguide.net
Posted by choi1779
데이터 모델링2010. 7. 1. 04:32

주제 영역 개념


주제 영역(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
Posted by choi1779
데이터 모델링2010. 6. 29. 04:13

관계(Relationship)란 ?


 관계도 집합이다

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


 직접 관계를 관계라고 한다

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

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



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



 외래키로 정의



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

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

 관계의 관점

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


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

Posted by choi1779
데이터 모델링2010. 6. 28. 04:08

개념 데이터 모델 정의

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

개념 데이터 모델 의의

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

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

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


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