데이터 모델링 결과 슈퍼타입(SUPERTYPE) 서브타입(SUBTYPE) 모델에 대한 기본 DB Design기법.
SCOPE & APPLICATION
SUPER/SUB TYPE DB Design 방안
KEY IDEA
(KEY WORD : 슈퍼타입, 서브타입, SUPER TYPE, SUB TYPE)
SUPPOSITION
DESCRIPTION
슈퍼타입과 서브타입의 정의
데이터 모델링에서 보다 응축화되고 통합된 데이터 모델링 기법을 많이 활용하게 되면 여러가지 형태의 슈퍼타입내의 서브타입이 나타나게 된다.
이러한 슈퍼/서브 타입 모델링에 대한 최종 물리 데이터 모델링 및 DB Design 방법은 여러가지 해법을 적용할 수 있으며, 이러한 해법은 단순한 공식과 같은 해법이 아니라 주어진 환경 및 모델에 표현된 상황 그리고 성능을 고려한 섬세한 설계자의 테크닉이 필요하기 때문에 많은 설계자들이 슈퍼/서브 타입 모델에 대한 최종 DB Design방안에 대한 고민에 빠지게 된다.
다음의 대표적인 슈퍼/서브 타입 사례 ERD를 살펴 보자.
(그림1)에서 고객이라는 슈터 타입(Super Type) 엔터티는 개인과 법인이라는 두개의 서브타입으로 구성되어 있으며, 재무결산이라는 엔터티는 개인고객과는 상관없이 고객 중에서 법인일 경우에만 존재할 수 있는 직접 종속 하위 엔터티이다.
과금구성이라는 엔터티는 개인/법인 모두 갖을 수 있는 정보로서 고객이라는 슈퍼타입 엔터티와 납입자라는 관계를 가지고 있다. 즉, 과금구성의 주체인 납입자는 개인납입자일 수도 있으며 법인납입자일 수도 있다는 의미이다.
과금구성이라는 엔터티에는 대금 납부방법에 따라 자동이체, 신용카드, 지로 와 같이 세가지의 서브타입이 있으며, 지로일 경우에는 슈퍼타입의 공통 속성외에 별도의 관리 속성이 필요 없지만 자동이체일 경우와 신용카드일 경우에는 별도의 필요 관리 속성이 정의되어 있다.
슈퍼타입은 각 서브타입의 전체 합집합이어야 하며 각각의 서브타입간의 교집합은 없어야 한다. 즉, 다음과 같은 집합정의가 만족되어야 한다.
슈퍼타입(고객) = 서브타입1(개인) ∪ 서브타입2(법인)
서브타입1(개인) ∩ 서브타입2(법인) = Ø
이는 고객이라는 집합은 개인과 법인의 합집합이라는 의미이며 하나의 주문원장의 주문 주체는 개인 고객일 수 도 있으며 법인 고객일 수 도 있다는 정의이다. 그리고 슈퍼타입에 속하는 서브타입 역시 자신 집합내에서 다시 여러 개의 서브타입을 가질 수 있다. 즉, 하나의 슈퍼타입 A 에 속하는 임의의 서브타입AA은 자신의 집합 내에서 또다시 여러 서브타입(AAA,AAB)을 가질 경우 상위 서브타입(AA)은 스스로 슈퍼타입의 역할을 하게 된다.
데이터 모델링에서 슈퍼/서브타입 엔터티 정의를 할 때에 주의를 기울여야 할 사안이 바로 어느 서브타입 집합에도 속할 수 없이 별도의 집합이 나타날 가능성이 있어서는 안된다는 점이다. 만일 자신이 없다면 구체적으로 정의할 수 없지만 예상되는 별도의 부분집합을 “기타”라는 서브타입을 활용하여 정의하고 지속적인 모델링 과정에서 검증토록 하는 방법도 자주 사용되는 기법이다.
슈퍼타입과 서브타입의 DB Design기법
슈퍼타입과 서브타입 엔터티에 대한 물리적 데이터모델링 및 DB Design기법에는 대표적으로 다음과 같은 세가지의 활용 해법이 있다.
하나의 테이블로 통합하여 설계하는 방안
여러 개의 테이블로 분할하여 설계하는 방안
슈퍼타입 테이블과 서브타입별 테이블로 각각 정의하여 ARC관계로 설계하는 방안
먼저, 하나의 테이블로 통합하는 방안에 대하여 살펴보자.
이 방안은 슈파타입내에 존재하는 여러 가지의 서브타입을 구분할 수 있는 속성(컬럼)의 추가로 해당 개체(Instance)가 어느 서브타입의 개체인지를 식별하게 하여 단일 테이블로 구성하는 방안이다.
이 경우 해당 테이블에 포함되는 컬럼(속성)은 슈퍼타입과 서브타입에 존재하는 각각의 속성들에 대한 최대공약수 속성을 갖게 하여 통분될 수 있는 각 서브타입의 속성들은 하나의 공용의미의 컬럼(속성)으로 사용하고 해당 의미를 앞서 설명한 서브타입 구분 컬럼(속성)으로 명확히 구분하게 한다.
그러므로 최대공약수 도출을 잘 하지 못하게 되면 한 테이블에 무척 많은 컬럼들이 각각의 독립적인 의미로 나열되게 된다. 그렇다고 통분을 무리하게 하여 하나의 컬럼으로 만국 공통 다용도 컬럼으로 설계할 경우에는 속성의 무결성 보장에 상당한 무리가 따르게 되므로 다양한 경험을 통하여 최적의 통분과 속성 무결성 보장을 적절하게 이루게 해주는 선에서 설계의 정점을 찍어야 할 것이다.
상기 (그림1)에서 좋은 예를 찾아볼 수 있으니 과금구성 엔터티를 활용하여 DB Design 해법을 제시해보자.
상기 Table Instance Chart양식에서 표현된 DB Design기법에는 통분이 필요한 2가지의 유사형태의 독립적인 서브타입의 속성을 약분하여 설계하였으며 (이체은행,신용카드사→ 금융기관 으로 계좌번호,신용카드번호→ 계좌카드번호로 통분시킴) 예금주와 유효만료일 컬럼은 별도의 독립적인 컬럼으로 설계하였다.
이러한 설계 방안은 주로 서브타입 간 속성 통분이 가능하면서 서브타입간 자료의 분포 차이가 대등한 경우 그리고 일부 서브타입간 독립적인 속성 차이가 많지 않은 경우에 주로 적용하는 방안이며 만일 테이블 분리를 할 경우 주변 엔터티와 잦은 ARC Relation 발생이 예상되는 경우에 이를 예방하기 위하여 키(Key)엔터티를 응축하여 통합하고자 할 경우에 적합하다.
이 방안은 주로 모든 데이터 발생의 시조가 되는 키(Key)엔터티에서 효과적이며 단점으로는 하나의 테이블의 자료량이 대량화가 발생될 가능성이 있어 정확한 엑세스 유형을 파악하여 최적의 인덱스 또는 클러스터링 및 테이블 파티션(Partition) 전략이 같이 고려되어야 한다는 점이다.
또한 주요한 단점은 컬럼의 무결성 보장(예:Not Null)이 어렵다는 것이다. 또한 로직에서 서브타입 구분자에 대한 조건이 자주 나타나고 테이블 뿐만이 아니라 인덱스 구성 컬럼도 증가되는 단점이 있다.
다음으로, 여러 개의 테이블로 분할하여 설계하는 방안에 대하여 살펴보자.
이 방안은 슈퍼타입에 정의된 공통 속성과 각 서브타입의 속성을 더하여 서브타입별로 테이블을 설계하는 방안으로서 반드시 필요한 자기만의 고유 컬럼만으로 설계하므로 속성의 무결성 보장에 있어서는 가장 확실한 방안이다.
이는 서브타입별 Relation 정의가 테이블 참조제약성을 명확히 부여하고 쉽게 일치성을 보장받을 수 있으며 각 컬럼의 무결성을 완벽하게 보장할 수 있는 것이 장점이다.
앞에서 열거한 첫번째 방안에서 사례로 든 과금정보라는 테이블을 다음과 같이 3개의 테이블로 설계하는 방안이다.
자동이체과금구성
납입자번호, 과금구성SEQ , 유효시작일,유효종료일,이체은행,계좌번호,예금주 …
신용카드과금구성
납입자번호, 과금구성SEQ , 유효시작일,유효종료일,신용카드사,카드번호,유효만료일 …
지로과금구성
납입자번호, 과금구성SEQ , 유효시작일,유효종료일 …
첫번째 방안에 비하여 서브타입별로 관리되는 속성(형태와 개수)의 차이가 심하거나 업무적으로 별도의 독립적인 업무활용(데이터 연결) 패턴을 보이는 환경 그리고 서브타입간의 자료량 분포의 차이가 심한 경우(예: 고객정보 중 개인 95% , 법인 5%) 에서 주로 채택되는 방안이 바로 이 방안이다.
이러한 방안은 잘못 적용할 경우에는 빈번한 ARC Relation 연결을 위하여 비효율적인 조인이 자주 나타날 수 있으며 빈번한 UNION 처리가 발생하게 되므로 개발시 기술상 다소 어려움과 성능상 위험을 초래할 수 있다. 또한 테이블 오브젝트의 증가로 인하여 다소 관리의 어려움과 서브타입간 교집합 예방을 위한 자료 일관성에 어려움이 있다.
개발 성능 측면에서는 고급 SUPER SQL로서 성능개선을 하고자 할 경우 한 SQL로 통합이 어려워 지는 경우와 합집합의 개념의 처리를 하고자 할 경우 부분범위 처리가 곤란해지는 경우도 발생하는 단점이 있다.
끝으로, 슈퍼타입 테이블과 서브타입별 테이블로 각각 정의하여 ARC관계로 설계하는 방안에 대하여 살펴보자.
전체 집합(슈퍼타입) 처리가 빈번하면서 업무적으로는 서브타입별로 독립적으로 활용되어지는 업무상 자료의 독립성이 강한 상황이면서 업무적으로 대부분의 처리가 공통부분(슈퍼타입 공통속성)에서 주로 발생하는 경우에 선택할 수 있는 설계 기법이다.
하나의 테이블로 통합할 경우 최대공약수 컬럼으로 나열하다 보니 너무도 많은 컬럼 정의가 필요하게 되는 상황에서도 선택할 수 있는 방안 중의 하나이다.
앞에서 사례로 사용한 예제 (그림1)에서 고객이라는 슈퍼타입 엔터티를 가지고 다음과 같은 DB Design을 할 수 있을 것이다.
고객
고객번호, 한글명칭, 등록일자, 연락처, …
개인고객정보
고객번호, 성별, 주민번호, …
지로과금구성
고객번호, 자본금, 법인번호 …
이러한 설계기법은 궁극적으로는 마치 배타적독점관계(ARC Relation)로 해석하기가 오히려 편할 것이다. 즉, 이 상황에 대한 고객 Entity를 ARC관계로 표현한 ERD로 다음 (그림2)와 같이 표현할 수 있다.
이러한 설계기법은 하나의 테이블로 통합할 경우 대용량의 데이터량 부담과 I/O엑세스 효율을 위한 물리적인 블록당 정보의 량을 증가시켜서 물리적인 디스크 I/O를 감소하기 위한 방안으로 많이 활용된다. 즉, 주로 대부분의 업무가 고객의 이름과 연락처만을 원하는 경우에는 고객이라는 슈퍼타입 테이블의 가로길이(속성의개수)를 줄여서 가능한 많은 고객의 자주 참조되는 핵심 주요 정보를 적은 DB Block에 저장하여 I/O효율을 극대화할 수 있다. 이러한 경우에는 특히 업무의 특성을 고려한 속성 배치에 심도있는 고려가 필요하다.
ARC관계에 대한 물리적인 설계 기법은 “ARC Model의 DB Design” 자료를 참고하기 바란다
출처 :http://www.en-core.com/
댓글 없음:
댓글 쓰기