DAsP - 물리 데이터 모델링 [논리-물리 모델 변환]

논리-물리 모델 변환

 

1.   논리 데이터 모델 – 물리 데이터 모델 변환 용어

 

2.   엔티티 – 테이블 변환

가.  테이블 설명

테이블은 데이터를 저장하기 위해서 생성된 데이터베이스에서의 가장 기본적인 객체이다.

1)     테이블(Table)

테이블은 기본적으로 칼럼(Column)과 로우(Row)를 가진다. 각각의 칼럼은 지정된 유형의 데이터 값을 저장하는 데 사용된다.

2)     로우(Rows)

테이블의 한 로우에 대응. 튜플, 인스턴스, 어커런스라고도 한다.

3)     칼럼(Columns)

각 사원 개개인의 관리 항목에 대한 Value를 저장한다.

4)     기본키(Primary Key)

하나의 칼럼 혹은 몇 개의 칼럼 조합으로, 어떤 경우라도 테이블 내에 동일한 값을 갖는 튜플이 존재하지 않도록 한다.

5)     외래키(Foreign Key)

외부 데이터 집합과의 관게를 구현한 구조이다.

 

나.  서브타입 변환(Transformation)

논리 데이터 모델에서는 비즈니스 또는 업무를 데이터 모델로 표현하기 위해서는 최대한 상세한 표현이 필수적이다. 그러한 목적을 달성하기 위해 가능하면 집합(엔티티)의 구성은 서브타입을 사용하여 구체적으로 표현하는 것이 통상적이다. 또한 각각의 서브타입들이 독립적인 속성(Attribute), 관계(Relationship)를 가지고 있는 경우에는 이러한 서브타입(Sub Type)을 사용한 집합의 표현은 필수적이다. 이렇게 논리 모델링에서 표현된 서브타입은 물리 데이터 모델에서는 테이블의 형태로 설계되어야 한다. 하지만 이러한 서브타입 모델은 단순 엔티티-테이블 변환과는 다른 몇 가지 방법을 통해 테이블로 변환 작업을 하게 된다.

1)     슈퍼타입 기준 테이블 변환

n  서브타입을 슈퍼타입에 통합하여 하나의 테이블로 만든다.

n  이 통합된 테이블에는 모든 서브타입의 데이터를 포함해야 한다.

n  주로 서브타입에 적은 양의 속성이나 관계를 가진 경우에 적용된다.

가)   절차

n  슈퍼타입으로 테이블 명칭 부여

n  서브타입을 구분할 수 있도록 칼럼 추가

n  슈퍼타입의 속성을 칼럼명으로

n  서브타입의 속성을 칼럼명으로

n  슈퍼타입의 관계를 FK로

n  서브타입의 관계를 FK로

나)   테이블 사례

n  TYPE
서브타입을 구분할 수 있는 칼럼이다.

n  DEPT
위의 구분이 정규직일 경우에 부서로부터의 관계로 인행 생성된 칼럼이다.

n  UNION
위의 구분이 임시직일 경우에 협력 업체로부터의 관계로 인해 생성된 칼럼이다.

다)   하나의 테이블로의 통합이 유리한 경우

n  데이터 액세스가 좀 더 간편

n  뷰를 활용하여 각 서브타입만을 액세스하거나 수정 가능

n  수행 속도가 좋아지는 경우가 많다.

n  서브타입 구분 없는 임의 집합의 가공 용이

n  다수의 서브타입을 통합한 경우 조인(JOIN) 감소 효과가 크다

n  복잡한 처리를 하나의 SQL로 통합하기가 용이

라)   하나의 테이블로의 통합이 불리한 경우

n  특정 서브타입의 NOT NULL 제한 불가

n  테이블의 칼럼 수가증가

n  테이블의 블럭 수가 증가

n  처리 시마다 서브타입의 구분(TYPE)이 필요해지는 경우가 많다.

n  인덱스(INDEX) 크기가 증가

 

2)     서브타입 기준 테이블 변환

n  슈퍼타입 속성들을 각 서브타입에 추가하여 각각의 서브타입마다 하나의 테이블로 만든다.

n  분할된 테이블에는 해당 서브타입의 데이터만 포함되어야 한다.

n  주로 서브타입에 많은 양의 속성이나 관계를 가진 경우에 적용된다.

가)   절차

n  서브타입마다 테이블 명칭 부여

n  서브타입의 속성을 칼럼명으로

n  테이블마다 슈퍼타입의 속성을 칼럼으로

n  서브타입마다 해당되는 관계들을 FK로

n  테이블마다 슈퍼타입의 관계를 FK로

나)   테이블 사례

다)   서브타입 기준으로 여러 개의 테이블로 분할한 경우가 유리한 경우

n  각 서브타입 속성들의 선택 사양이 명확한 경우에 유리하다.

n  처리 시마다 서브타입 유형 구분이 불필요하다.

n  전체 테이블 스캔 시 유리하다.

n  단위 테이블의 크기가 감소한다.

라)   서브타입 기준으로 여러 개의 테이블로 분할한 경우가 불리한 경우

n  서브타입 구분 없이 데이터 처리하는 경우 UNION이 발생한다.

n  처리 속도가 감소하는 경우가 많다.

n  트랜잭션 처리 시 여러 테이블을 처리하는 경우가 증가한다.

n  복잡한 처리의 SQL 통합이 어려워진다.

n  부분 범위 처리가 불가능해질 수 있다.

n  여러 테이블을 합친 뷰는 조회만 가능하다.

n  UID 유지 관리가 어렵다.

 

3)     개별타입 기준 테이블 변환

n  슈퍼타입과 서브타입을 각각 테이블로 변환한 경우이다.

n  슈퍼타입과 서브타입 테이블 간에는 1:1 관계가 생성된다.(한 쪽을 모두 합치면 전체와 같게 된다는 면에서 개념적으로 아크 관계와 유사)

가)   다음의 여러 가지 경우를 만족할 때 사용

n  전체 데이터 처리가 빈번하게 발생할 경우에 적용한다.

n  서브타입의 처리는 주로 독립적으로 발생할 경우에 적용한다.

n  테이블을 통합했을 때 칼럼의 수가 너무 많아지는 경우에 적용한다.

n  서브타입의 칼럼 수가 많은 경우에 적용한다.

n  트랜잭션이 주로 공통 부분(슈퍼타입)에서 발생한다.

n  슈퍼타입의 처리 범위가 넓고 빈번하여 단일 테이블 클러스터링을 해야 할 때 적용한다.

 

다.  서브타입 변환 예

데이터 모델을 물리적으로 전환하는 방법은 다양하다.

 

1)     Case 1: 서브타입을 테이블로 분리

2)     Case 2: 서브타입을 통합 테이블로 생성

 

라.  테이블 목록 정의서

 

3.   속성 – 칼럼 변환

가.  일반 속성 변환

n  엔티티에 있는 각 속성들에 대한 칼럼명을 사례 데이터 표의 칼럼명 란에 기록한다.

n  칼럼의 명칭은 속성의 명칭과 반드시 일치할 필요는 없으나 개발자와 사용자의 혼동을 피하기 위해 가급적 표준화된 약어를 사용한다.

n  표준화된 약어의 사용은 SQL 해독 시간을 감소시킨다.

n  SQL의 예약어(reserved word)의 사용을 피한다.

n  가급적 칼럼 명칭은 짧은 것이 좋으며, 짧은 명칭은 개발자의 생산성에 긍정적인 영향을 준다.

n  필수 입력 속성은 Nulls/Unique 란에 NN을 표시한다.

n  실제 테이블에 대한 설계를 검증하기 위한 목적으로 가능하다면 표본 데이터를 입력시킨다.

 

나.  Primary UID -> 기본키 (Primary Key) 변환

논리 데이터 모델에서의 Primary UID는 물리데이터 모델에서는 기본키로 생성된다. 실제 DDL에서는 기본키 제약 조건의 형태로 객체가 생성된다.

1)     변환 절차

n  사례 데이터 표의 키 형태 란에 엔티티의 Primary UID에 속하는 모든 속성에 PK를 표시

n  PK로 표시된 모든 칼럼은 Nulls/Unique란에 반드시 NN,U로 표시되어야 함

n  여러 개의 칼럼으로 UID가 구성되어 있는 경우는 각각의 칼럼에 NN,U1을 표시

n  또 다른 Unique Key(Secondary UID)가 있다면 U2로 표시

2)     변환 예

 

다.  Primary UID(관계의 UID Bard) -> 기본키 (Primary Key) 변환

논리 데이터 모델에서 Primary UID에 속하는 속성 중에는 해당 엔티티 자체에서 생성된 것도 존재하지만 다른 집합(엔티티)으로부터의 관계에 의해 생성되는 UID 속성(관계 속성)도 존재한다. 이러한 관계 속성 UID의 변환은 기본적인 속성 UID 변환과는 약간 다르다.

1)     변환 절차

n  테이블에 외래키 칼럼을 포함시킨다.

n  PK의 일부분으로 표시

l  Nulls/Unique 란에 각각 NN,U1을 표시

l  키 형태 란에 PK, FK를 표시

l  여러 UID BAR가 있는 경우는 (PK, FK1), (PK, FK2) …

l  여러 칼럼으로 구성된 경우 PK, FK1을 각각 표시

n  추가된 FK 칼럼에 표본 데이터를 추가

2)     변환 예

 

라.  Secondary(Alternate) UID -> Unique Key 변환

논리 데이터 모델에서 정의한 Secondary UID 또는 Alternate Key 들을 해당 집합과 상태 집합과의 선택적인 관계를 가질 수 있도록 하는 데 중요한 역할을 수행한다. 이러한 Secondary UID들은 물리 데이터 모델에서는 Unique Key로 생성된다. 변환 절차는 기본적으로 Primary UID 변환 절차와 동일하다.

 

마.  테이블 정의서

 

4.   관계 변환

가.  1:M 관계 변환

논리 데이터 모델에서 존재하는 관계 중에서 가장 많은 형태의 관계이다. M쪽 관계의 형태에 따라서 관계 칼럼의 선택 사양이 결정된다.

1)     변환 절차

n  1(One) 쪽에 있는 PK를 M(Many)의 FK로 변환

l  FK의 명칭 결정

l  키 형태 란에 FK 표시

l  Nulls/Unique란에 NN표시(Must Be 관계 시)

l  필수 관계가 아닌 경우에는 NN을 체크하지 않는다.

n  표본 데이터 추가

n  UID BAR 가 있는 경우는 전단계에서 실시

2)     변환 예

3)     1:M 관계에서 1쪽이 Mandatory 관계일 때의 변환 시 주의사항

n  자식 쪽의 레코드(Row)가 반드시 하나 이상은 되어야만 부모 쪽의 레코드(Row)를 생성할 수 있다.

n  자식 쪽의 레코드(Row)를 삭제할 경우에는 전체를 다 삭제할 수는 없고 반드시 하나 이상의 자식 레코드(Row)를 남겨두어야 한다. 또는 자식, 부모 레코드(Row)를 동시에 삭제해야 한다.

 

나.  1:1 관계 변환

1:1 관계는 논리 모델에서는 자주 발생하지는 않는 관계이다. 이러한 1:1 관계를 물리 모델로 변환하는 과정은 관계의 Optionality(기수성)에 따라서 다른 방법으로 적용된다. 양쪽 다 Optional인 경우에는 보다 빈번하게 사용되는 테이블이 외래키를 가지는 것이 유리하다.

1)     변환 절차

n  Mandatory 반대쪽에 있는 테이블의 기본키를 Mandatory 쪽 테이블의 외래키로 변환한다.

n  NN 표시를 한다.

2)     변환 예

3)     변환 시 주의 사항

n  1:1 관계에 의해서 생긴 모든 외래키 부분은 Unique Key가 필수적이다.

n  한쪽이 Optional이고 다른 한쪽이 Mandatory라면 Mandatory 쪽의 테이블에 외래키가 생성된다.

n  양쪽 다 Mandatory라면 변환 시에 어떤 테이블에 외래키를 생성할 것인지를 선택해야 한다.

 

다.  1:M 순환 관계 변환

대부분의 경우는 데이터의 계층 구조를 표현하기 위해서 이러한 관계를 사용한다. 특성상 최상위 관계 속성은 항상 Optional인 형태의 관계이어야 한다. 하지만 경우에 따라서는 최상위의 관계 속성에 특정 값을 지정하는 경우도 존재한다.

1)     변환 절차

n  해당 테이블 내에 외래키 칼럼을 추가한다. 외래키는 같은 테이블 내의 다른 로우의 기본키 칼럼을 참조하게 된다.

n  외래키 칼럼 명칭은 가능한 한 관계 명칭을 반영한다. 외래키는 결코 NN(Not Null)이 될 수 없다.

2)     변환 예

 

라.  배타적 관계 변환

논리 모델에서의 배타적 관계의 모델은 실제 데이터 환경에서는 자주 등장하게 된다. 이러한 관계를 물리 데이터 모델로 생성하는 방법은 일반적인 관계를 물리 데이터 모델로 변환하는 것과는 다르다.

1)     외래키(Foreign Key) 분리 방법

각각의 관계를 관계 칼럼으로 생성하는 방법이다. 이 방법을 사용하면 실제 외래키 제약조건(Foreign Key Contraints)을 생성할 수 있다는 장점이 있다. 하지만 각각의 키 칼럼들이 Optional이어야 한다. 또한 다음과 같은 체크 제약조건(Check Constraints)을 추가적으로 생성하여야 한다.

 

n  추가적인 체크 제약조건
CHECK(    JUMIN_NO IS NOT NULL
     AND PART_NO IS NULL
     AND BUSINESS_ID IS NULL )
OR   (    JUMIN_NO IS NOT NULL
     AND PART_NO IS NOT NULL
     AND BUSINESS_ID IS NULL )   
OR   (    JUMIN_NO IS NULL
     AND PART_NO IS NULL
     AND BUSINESS_ID IS NOT NULL )

2)     외래키 결합 방법

각각의 관계를 하나의 관계 칼럼으로 생성하는 방법이다. 이 방법을 사용하면 실제 외래키 제약조건을 생성할 수 없다는 단점이 있다. 또한 각각의 관계를 선택적으로 구분할 수 있는 추가적인 칼럼이 필요하게 된다.

n  구분 칼럼 추가
구분 칼럼 TYPE이 추가되어 배타적 관계의 각 테이블들이 구분된다.

l  J: 개인

l  P: 단체

l  B: 법인

 

5.   관리상 필요한 칼럼 추가

가.  개념

논리 데이터 모델에는 존재하지 않지만 관리상의 이유로 혹은 데이터베이스를 이용하는 프로그래밍이 좀 더 빠르게 수행되도록 하기 위해 테이블이나 칼럼을 추가할 수 있다.

 

나.  시스템 칼럼 추가 예

생성일시, 생성 프로세스 ID라는 논리 데이터 모델에서는 존재하지 않는 속성인데도 불구하고 물리 데이터 모델에서 추가하여 생성하고 있는 예를 보여주고 있다.

 

6.   데이터 타입 선택

가.   개념

물리 데이터 모델링 단계에서 일어나는 많은 문제 중의 하나가 칼럼의 데이터 형식을 잘못 설정하는 데에서 발생한다. 특정 칼럼의 데이터 형식을 선택하는 것은 논리 데이터 모델에서 정의된 논리적인 데이터 타입(정보타입: Information Type)을 물리적인 DBMS의 특성과 성능 등을 고려하여 최적의 데이터 타입을 선택하는 작업이다.

 

나.   문자 타입(Character Data Types)

1)     세부 문자 타입 선택을 위한 기준

가)   영문만 사용되었는가?

나)   4000자 혹은 8000자 이상의 문자열이 포함되는가?

다)   입력되는 값의 길이가 일정한가?

2)     문자 형식 데이터 타입 설정 예

 

다.   숫자 타입(Numeric Types)

1)     세부 숫자 타입 선택을 위한 기준

가)   정말 숫자 데이터인지 판단한다.

나)   세부 숫자 타입 결정

2)     숫자 형식 데이터 타입 지정 예

 

라.   날짜 타입(DateTime Types)

1)     세부 날짜 타입 선택을 위한 기준

대부분의 DBMS에서는 날짜 타입에 일자뿐만 아니라 시분초의 정보도 같이 저장한다.

2)     세부 날짜 타입 지정 예

 

7.   데이터 표준 적용

가.  개념

논리 데이터 모델링 과정에서 정의된 엔티티, 속성, 관계들을 여러 가지 기준으로 물리 데이터 모델로 변환한다. 이 과정에서 필수적으로 엔티티명에 해당하는 테이블명을 생성하고, 속성 또는 관계에 해당하는 칼럼명을 생성한다. 이러한 이름을 변환하는 과정에서 전사적으로 미리 생성된 데이터 표준을 따르게 된다.

 

나.  데이터 표준 적용 대상

1)     데이터베이스(Database)

테이블의 집합으로 통합 모델링 단계의 주제 영역이나 애플리케이션 모델링 단계의 업무 영역에 대응되는 객체이다.

2)     스토리지 그룹(Storage Group)

DASD(Direct Access Storage Device), 즉, 물리적인 디스크(Disk)를 묶어서 하나의 그룹으로 정의해 놓은 것이며, 테이블스페이스, 인덱스 스페이스 생성 시 스토리지 그룹명을 지정하여 물리적인 영역을 할당하도록 한다.

3)     테이블 스페이스(Tablespace)

테이블이 생성되는 물리적인 영역이며, 하나의 테이블 스페이스에 하나 또는 그 이상의 테이블을 저장할 수 있다.

4)     테이블(Table)

논리 설계 단계의 엔티티에 대응하는 객체이다.

5)     칼럼(Column)

논리 설계 단계의 속성에 대응하는 객체이다.

6)     인덱스(Index)

테이블에서 특정 조건의 데이터를 효율적으로 검색하기 위한 색인 데이터로, 대표적인 인덱스 대상으로는 기본키(Primary Key), 외래키(Foreign Key) 등이 있다.

7)     뷰(View)

테이블에 대한 재정의로서 물리적으로 테이블의 특정 칼럼, 특정 로우를 뷰로 정의하여 특정 사용자만 접근이 가능하도록 할 수 있다.

 

다.  데이터 표준 적용 방법

1)     명명 규칙에 의한 표준화 적용

2)     표준 용어집에 의한 표준화 적용