• 논리 모델과 물리 모델의 개념
  • LOGICAL DATA MODEL

    – 논리 모델은 업무를 지원하는데 필요한 정보와 업무규칙을 표현한 것으로서 물리적인 스키마 설계를 하기 위한 전 단계의 데이터 모델 상태를 의미하며 그것은 DBMS와는 독립적으로 표현이 가능하다.

  • PHYSICAL DATA MODEL

    – 물리 모델은 설계와 구축 사이에서 생성할 수 있는 데이터 구조, 즉 논리 모델을 특정 데이터베이스로 설계함으로써 생성된 데이터를 저장할 수 있는 물리적인 스키마를 의미하며 위의 논리적인 단계에서 잠시 배제해 두었던 물리적(현실적) 요건을 감안시키는 모델링 단계를 말한다.

  • ER-Win 구조
  • LIBRARY -> MODEL -> SUBJECT AREAS

– MAIN SUBJECT AREA

– 업무영역명_MAIN(SUBTYPE은 1 LEVEL까지만 표현함)

– 일반화관계(SUBTYPE이 M LEVEL인 것을 표현함)

– 그 외의 테이블

위와 같은 순서의 계층구조로 구성되어 있다.

2) WISE 시스템내의 HC, MAF, GR로 구성된 MPS업무로 예를 든다면 구조도는 아래와 같다

EX) LIBRARY(WISE) -> MODEL(MPS) -> SUBJECT AREAS

– MAIN SUBJECT AREA(MPS 전체 ERD)

– HC_MAIN

– MAFHC_MAIN

– GR_MAIN

– HC_SUBTYPE

– MAF_SUBTYPE

– GRHC_SUBTYPE

– 그 외의 테이블

  • TABLE(물리 모델)/ENTITY(논리 모델) 유형과 분류

(1) 논리 모델

1) NORMAL : 일반. Normal한 Entity를 의미



2) PSEUDO : 가상. 존재하지 않는 Entity를 필요에 의해서 가상으로 생성한 Entity


TABLE명 + [가상] – LOGICAL ONLY


3) Additional : 추가. 미래에 발생해야 할 Entity를 가상으로 생성한 Entity

TABLE명 + [추가] – LOGICAL ONLY


4) External : 외부. 타 시스템에 존재하는 Entity를 참조 시에 사용


TABLE명 + [외부]



5) 미사용 : 제거. 사용하지 않는 Entity.


TABLE명 + [미사용]



6) 현행화 안됨: Conversion 대상에는 존재하지 않지만 Relation Ship을 갖는 Entity

TABLE명 + [현행화안됨]



7) 복사 : 복사. 타업무영역이 Owner Ship을 가지고 있으나 끌어다 사용함.

TABLE명 + [업무영역 명 + 복사]


8) 복사 : 복제의 의미. ERD가 복잡하여 동일 업무영역내의 동일 Entity를 복제하여 사용

TABLE명 + [복사]


Entity의 분류 및 유형 설정하기

-> ER-Win 모델의 Entity를 지정하고 오른쪽 버튼을 클릭하며 Entity Properties를 선택하여 UDP 기능(LIST BOX)을 활용하여 Entity의 분류 및 유형을 아래의 그림과 같이 설정한다.


(2) 물리 모델

1) NORMAL : 일반. Normal한 TABLE을 의미



2) External : 외부. 타 시스템에 존재하는 Entity를 참조 시에 사용


TABLE명 + _외부_



3) 복사 : 복사. 타 업무영역이 OWNER SHIP을 가지고 있으나 끌어다 사용함.

TABLE명 + _업무영역 명 + 복사_


4) 복사 : 복제의 의미. ERD가 복잡하여 동일 업무영역내의 동일 TABLE을 복제하여 사용

TABLE명 + _복사_


※ TABLE의 유형

-> UDP를 활용하여 유형을 설정하지 않고 TABLE명에 위의 규칙으로만 표현한다.

※ I/F TYPE

-> 서로 다른 주제영역의 RELATION SHIP에서 TABLE을 가져다 사용할 경우에 해당 TABLE의

주제영역을 명시하기 위한 기능으로 UDP에 I/F TYPE이라는 항목명으로 MASTER인지

아닌지를 구분한다. (PHYSICAL ONLY)

  • COLUMN(물리 모델)/ATTRIBUTE(논리 모델) 유형

(1) 논리 모델

  • 일반 Primary Key
  • Primary Key 중 비상속 속성 : 논리 모델에서는 속성명 + ‘*$’으로 표현한다
  • Not Null 속성
  • 속성유형

    ① Normal : 일반

    ② Derived : 추출속성(source 테이블과 속성을 명기한다.)

    ③ Pseudo : 가상속성(실제로 속성이 존재하지는 않는다.)(LOGIAL ONLY)

    ④ Additional : 추가속성(미래에 예상되는 추가 속성이다.) (LOGIAL ONLY)

    ⑤ Drop : 미사용으로 DROP 예상속성이며 소문자 ‘x’로 표현한다.

    ⑥ System : WISE SYSTEM에서 사용하는 속성으로 모든 ENTITY에 존재한다.

논리 모델의 속성유형은 Attribute + * + 소문자 영문


속성의 유형 설정하기

-> ER-Win 모델의 속성을 지정하고 오른쪽 버튼을 클릭하며 ATTRIBUTES의 UDP 기능(LIST BOX)을 활용하여 속성의 유형을 아래의 그림과 같이 설정한다


(2) 물리 모델

COLUMN의 유형 및 비상속여부 설정하기

-> 각각의 유형별로 색상을 지정하여 구분하며 비상속의 경우와 COLUMN의 유형은 ER-Win

모델의 속성을 지정하고 오른쪽 버튼을 클릭하며 COLUMNS의 UDP 기능(LIST BOX)을 활용(비상속여부와 속성유형)하여 아래의 그림과 같이 설정한다.

1) 유형

① Normal : 일반적인 TABLE

② Derived : 추출속성(source TABLE과 COLUMN을 명기한다.)

③ Drop : 미사용으로 인하여 추후에 제거가 예상되는 COLUMN이다.

④ System : WISE SYSTEM에서 사용하는 COLUMN으로 모든 TABLE에 존재한다.


  • RELATION SHIP의 종류와 유형

종류

(1) 논리 모델

  • 1:1 관계 -> 부모의 PK가 자식의 PK로 상속되는 경우



  • 1:1 관계 -> 부모의 PK가 자식의 일반속성으로 상속되는 경우


  • 1:M 관계 -> 부모의 PK가 자식의 PK로 상속되는 경우



  • 1:M 관계 -> 부모의 PK가 자식의 일반속성으로 상속되는 경우



  • M:M 관계



  • Exclusive : arc 관계는 그림으로 표현




유형 : UDP 항목으로 관리하며 관계의 UDP 항목 중 관계 유형에 표기
관계선 위에 대문자 첫자리 표기, 색상은 파란색, FONT는 굵게 표현한다.

NORMAL : 일반적으로 사용하는 RELATION SHIP의 표현

EX)

BETWEEN : 한 개체와 그 개체를 포함하는 그룹간의 RELATION SHIP의 표현


LIKE : 속성이 원자적인 특성을 갖지 못하고 혼합된 형태라 할지라도 의미적으로 또는 가공을 통해서 연결이 가능한 RELATION SHIP의 표현

EX)

PSEUDO : UID가 아닌 일반속성과의 논의적인 연결 또는 가상 ENTITY와의 연결을 표현



DERIVED : 실제로는 1촌 이상 떨어져 있는 간접적인 관계를 마치 직접적인 관계인 것처럼 표현

EX)

(2) 물리 모델

물리 모델의 경우는 NORMAL을 제외한 모든 CASE는 표현하지 않는다.

※ COLUMN ORDER

-> ER-Win에 표현되어 있는 PK 구성컬럼의 순서와 실제의 DBMS상의 PK 구성컬럼의 순서가

다를 수 있으므로 DBMS를 기준으로 UDP를 활용하여 순서를 지정한다. (PHYSICAL ONLY)

  • SUBTYPE
  • 간단한 Subtype

MAIN에는 1LEVLE SUBTYPE만 표현하고, M LEVEL SUBTYPE은 SUBTYPE SUBJECT AREA에 표현

한다.



  • 복잡한 Subtype

2 LEVEL 이상 DEPTH의 SUBTYPE과 타 테이블과의 RELATION SHIP이 발생하는 경우는 1 LEVEL

부터 그 사이 LEVEL의 SUBTYPE은 생략을 한 채 MAIN SUBJECT AREA에 표현하며 전체에 대한 그림은 위에서 표현한 바와 같이 SUBTYPE SUBJECT AREA에 그린다.


  • SUBTYPE과 ENTITY간의 RELATION SHIP


  • 하나의 ENTITY내의 SUBTYPE간 RELATION SHIP


  • 동일한 속성을 상속하는 경우의 처리 방안



처리방안

Alternate Key(대체키)와 Role Name을 활용하여 처리함

위의 그림과 같이 테이블, SEGMENT_DEFINITION의 일반속성, SEGMENT_NO를 테이블, PERIOD가 기존

의 속성명칭이 아닌 일반속성으로 상속을 받고자 할 경우에는 테이블, SEGMENT_DEFINITION의

일반속성, SEGMENT_NO를 대체키(Alternate Key)로 선언한 후에 Relation Ship을 갖는다.

Alternate Key


Role Name


10. 부모의 키 중 일부 속성은 비상속으로 처리하는 경우의 처리방안

① PERIOD_SET의 PK 구성속성이면서 비상속 속성이 존재함

② 1:M 관계를 갖고, PERIOD_SET_CODE만 상속하며 EFFECTIVE_DATE는 상속하지 않는 경우

③ PERIOD_NAME의 PK는 PERIOD_SET_CODE + PERIOD_VALUE_CODE + EFFECTIVE_DATE로 구성



처리방안

Alternate Key(대체키)를 활용하여 처리함

위의 그림과 같이 테이블, PERIOD SET의 PK 구성속성 중에 유효일자는 비상속 속성이므로 본 속

성을 제외한 PK 구성속성으로 대체키(Alternate Key)를 선언한 후에 Relation Ship을 맺으며 이

때 Relation은 UID의 상속이 아닌 일반속성의 상속으로 연관을 맺는다.

위의 작업 후에 M쪽 테이블의 PK로 상속하는 속성은 인위적으로 해당 속성을 PK레벨로 올려준다.

  1. PK중 일부속성은 PK로, 일부속성은 일반속성으로 상속하는 경우의 처리방안

① PERIOD_NAME의 PK는 PERIOD_SET_CODE + EFFECTIVE_DATE

② 1:M 관계, 상속은 PERIOD_SET_CODE는 PK로 EFFECTIVE_DATE는 일반속성으로 표현

③ PERIOD의 PK는 PERIOD_SET_CODE + DAY_NUMBER + FROM_HOUR로 구성


처리방안

위의 그림과 같이 테이블, PERIOD NAME의 PK 구성속성 중에 PERIOD_SET_CODE는 PK로,

EFFECTIVE_DATE는 일반속성으로 상속되는 경우이며 이 때 Relation Ship은 UID의 상속이 아닌

일반속성의 상속으로 연관을 맺는다.

위의 작업 후에 M쪽 테이블의 PK로 상속하는 속성은 인위적으로 해당 속성을 PK레벨로 올려준다.


  1. PK가 아닌 일반속성이 상속되는 경우 처리방안

① 일반속성으로 상속을 받는 경우




처리방안


Alternate Key(대체키)를 활용하여 처리함

위의 그림과 같이 TABLE01의 일반속성, PERIOD_CODE를 대체키(Alternate Key)로 선언한 후에 Relation Ship을 맺으며 이때 Relation Ship은 UID의 상속이 아닌 일반속성의 상속

으로 연관을 맺는다.


② PK로 상속을 받는 경우




처리방안


Alternate Key(대체키)를 활용하여 처리함

위의 그림과 같이 TABLE01의 일반속성, PERIOD_CODE를 대체키(Alternate Key)로 선언한 후에 Relation Ship을 맺으며 이때 Relation Ship은 UID의 상속으로 연관을 맺는다.

By haisins

오라클 DBA 박용석 입니다. haisins@gmail.com 으로 문의 주세요.

답글 남기기

이메일 주소를 발행하지 않을 것입니다. 필수 항목은 *(으)로 표시합니다