- 논리 모델과 물리 모델의 개념
- ER-Win 구조
- TABLE(물리 모델)/ENTITY(논리 모델) 유형과 분류
- COLUMN(물리 모델)/ATTRIBUTE(논리 모델) 유형과 분류
- RELATION SHIP의 종류와 유형
- SUBTYPE
- SUBTYPE + TABLE RELATION SHIP
- 하나의 TABLE 내의 SUBTYPE 간의 RELATION SHIP
- 동일한 속성을 상속 받은 경우의 처리방안
- 부모의 KEY중 일부 COLUMN을 비상속으로 처리하는 경우의 처리방안
- PRIMARY KEY중 일부 COLUMN은 PRIMARY KEY로 상속, 일부 COLUMN은 일반
-
LOGICAL DATA MODEL
– 논리 모델은 업무를 지원하는데 필요한 정보와 업무규칙을 표현한 것으로서 물리적인 스키마 설계를 하기 위한 전 단계의 데이터 모델 상태를 의미하며 그것은 DBMS와는 독립적으로 표현이 가능하다.
-
PHYSICAL DATA MODEL
– 물리 모델은 설계와 구축 사이에서 생성할 수 있는 데이터 구조, 즉 논리 모델을 특정 데이터베이스로 설계함으로써 생성된 데이터를 저장할 수 있는 물리적인 스키마를 의미하며 위의 논리적인 단계에서 잠시 배제해 두었던 물리적(현실적) 요건을 감안시키는 모델링 단계를 말한다.
-
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
– 그 외의 테이블
(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)
(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에 존재한다.
종류
(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
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에 그린다.
처리방안
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레벨로 올려준다.
① 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레벨로 올려준다.
① 일반속성으로 상속을 받는 경우
처리방안
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의 상속으로 연관을 맺는다.