1) 논리 데이터 모델의 물리 데이터 모델로 변환 : 엔터티는 테이블, 속성은 칼럼 등으로 변환
이론적으로 위와같이 구분하나 개별로 암기할 필요는 없음
기출문제
새롭게 구축된 정보시스템의 데이터베이스 부문의 논리 데이터 모델링의 품질점검을 하게 되었다. 개념적 데이터베이스 모델링 결과를 관게형 데이터베이스 이론에 근거하여 데이터베이스 스키마로 변환하는 과정을 (mapping rule)이라고 하는데 단순 엔터티는 테이블로, 속성은 칼럼으로, 주식별자는 기본키로, 관계는 (외래키)로 변환한다. 즉, 개념적 데이터베이스 모델링에서 도출된 엔터티를 논리적 데이터베이스 모델링에서 (mapping rule)을 이용해 관계 스키마로 변환한다.
mapping rule(사상) 1) ERD에서 관게형 데이터베이스 이론에 입각해 릴레이션 스키마로 변환하는 과정 2) IE표기법에서 필수, 선택적, 다중 표기법이 출제된 적이 있음
2) 슈퍼 타입 기준 엔터티 통합
1] 슈퍼 타입 엔터티를 중심으로 서브 타입 엔터티와 단일 테이블로 통합
2] 주로 서브타입에 적은 양의 속성이나 관계를 가진 경우에 적용
3] 단일 테이블 통합으로 유리한 경우
- 데이터의 엑세스가 상대적으로 용이
- 뷰를 이용하여 각각의 서브 타입만을 액세스하거나 수정
- 수행 속도가 좋아지는 경우가 많음
- 서브 타입 구분이 없는 임의 집합에 대한 가공이 용이
4] 단일 테이블 통합으로 불리한 경우
- 특정 서브 타입에 대한 not null 제한이 어려움
- 테이블의 칼럼 및 블록 수가 증가
- 처리마다 서브 타입에 대한
3) 서브 타입 기준 엔터티 통합
1] 슈퍼 타입 속성들을 각각의 서브 타입에 추가하여 서브 타입마다 하나의 테이블로 변환
2] 주로 서브타입에 많은 양의 속서이나 관계를 가진 경우 용이
3] 복수의 테이블로 분할이 유리한 경우
- 각 서브 타입 속성들의 선택 사양이 명확한 경우에 유리
- 서브 타입 유형에 대한 구분을 처리마다 할 필요가 없음
- 전체 테이블을 스캔하는 경우 유리
4] 복수의 테이블로 분할이 불리한 경우
- 서브 타입 구분 없이 데이터를 처리하는 경우 유니온이 발생
- 처리 속도 감소가 발생할 가능성이 높음
- 트랜잭션을 처리하는 경우 다수 테이블을 처리하는 경우가 자주 발생
4.) 개별 타입 기준 변환
1] 슈퍼 타입과 서브 타입을 각각의 테이블로 변환
- 슈퍼 타입과 서브 타입 각각의 테이블 사이에는 1:1 관계가 형성
2] 개별 타입 기준 테이블 변환을 사용하는 경우
- 전체 데이터에 대한 처리가 자주 발생하는 경우 사용
- 서브 타입 처리가 대부분 독립적으로 발생하는 경우 사용
- 통합하는 테이블의 칼럼 수가 지나치게 많은 경우 사용
- 서브 타입 칼럼 수가 다수인 경우 사용
5) 속성 및 칼럼 변환
1] 일반 속성 변환
2] PRIMARY UID 기본 키 변환
- 논리 모델링에서의 PRIMARY KEY UID는 물리 모델링에서 기본 키로 생성
- DDL에서는 오브젝트가 생성되어 기본 키 제약 조건의 속성을 가짐
3] PRIMARY KEY UID(관계의 UID BAR) 기본 키 변환
- PRIMARY UID의 속성 중 해당 엔터티에서 생성된 속성도 있지만 다른 엔터티와의 관계로인해 생성되는 속성도 존재
- 이러한 관계 속성 UID의 변화는 일반적인 속성UID 변환과는 차이가 존재
4] SECONDARY/ALTERNATIVE UID 유니크 키 변환
- 논리 모델링에서 정의된 SECONDATY UID 및 ALTERNATE KEY들은 해당 엔터티와 상대 엔터티의 선택적 관계를 갖는데 중요한 역할을 함
- 이러한 secondaty uid들은 물리 모델에서는 기본키로 생성
6) 관계 변환
1] 1:M 변환
- 논리 데이터 모델의 관계에서 가장 보편적 형태의 관계이며 M 측의 관계 칼럼에 선택 사항이 결정되게 됨
2] 변환
- 논리 데이터 모델에서 1:1 관게는 일반적이지 않은 형태로 1:1 관게를 물리 모델링에 변환하는 과정은 관계의 선택성(기수성X)으로 인해 다른 방법이 적용
3] 1:M 순환 관계 변환
- 일반적으로 데이터 계층 구조의 표현에 주로 사용하는 관계의 형태로 특성상 최상위 관계속성은 항상 OPTIONAL의 형태
-경우에 따라서 최상위 관계에 특정 값을 설정하는 경우도 존재
4] 베타적 관계 변환
- 실제 데이터 환경에서는 빈번하게 등장하는 논리 데이터 모델의 배타적 관계 모델은 물리 모델링에서 생성하는 방법이 일반적인 관계 변환 방법과는 차이가 존재
- 외래 키 분리 : 관계별로 관계 칼럼을 생성하는 방법으로 실제 외래 키의 제약 조건이 생성 가능하다는 장점이 있으나 키 칼럼들이 각각 OPTIONAL의 형태여야 하며 체크 제약 조건의 추가적 생성이 필요
- 외래 키 결합 : 관계들을 하나의 관계 칼럼으로 통합 생성하는 방법으로 실제 외래 키 제약 조건의 생성은 불가능하고 다수의 관계를 선별하여 구분하기 위한 별도의 칼럼이 필요
7) 관리 목적의 칼럼 추가
1] 논리 모델링에서는 필요가 없으나 관리 또는 데이터베이스를 이용하는 프로그래밍의 수행 속도 향상을 위해 추가되는 테이블이나 칼럼으로 관리상 필요한 데이터를 등록한 일자, 시스템 번호 등을 추가
8) 데이터 타입 선택
1] 데이터 형식을 설정하는 것은 논리 데이터 모델링에서 정의된 논리적인 데이터 타입을 물리적인 DBMS 특성과 성능의 고려를 통해 최적 데이터 타입을 선택하는 작업
2] 주요 타입은 문자, 숫자, 날짜타입으로 구분
9) 데이터 표준화
1] 명명 규칙 및 표준 용어 사전을 활용하여 각 객체의 데이터 표준화를 수행
2] 표준화 적용 대상은 데이터베이스, 스토리지 그룹, 테이블 스페이스 테이블, 칼럼, 인덱스, 뷰
스토리지 그룹 : 물리적인 디스크를 묶어서 하나의 그룹으로 정의
테이블 스페이스 : 테이블이 생성되는 물리적인 영역으로 하나의 테이블 스페이스에 하나 또는 그 이상의 테이블 저장 가능
4. 칼럼 속성
1) 정보를 나타내는 최소의 단위
2) 엔터티의 성질, 분류, 수량, 상태, 특성 등을 나타내는 세부 항목
3) 기본 속성 : 엔터티가 원래 가지고 있는 속성
4) 설계 속성 : 원래 업무에 존재하지 않지만 시스템 효율을 위해 앞으로 추가되는 속성
5) 파생(추출)속성 : 다른 속성으로부터 계산, 변형되어 생성되는 것으로 데이터 중복성과 무결성 확보를 위해 가급적 적게 정의해야하며 트리거를 이용하거나 계산된 칼럼 선언으로 사용
