ARC Model의 DB 디자인

PURPOSE

데이터 모델링 결과 상호 배타적 독점관계(ARC-Relationship) 모델에 대한 기본 DB Design기법.

SCOPE & APPLICATION

ARC Model DB Design 방안

KEY IDEA

(KEY WORD : ARC, 배타적독점관계, 아크관계, ARC Relationship, ARC관계)

SUPPOSITION

DESCRIPTION

데이터 모델링 결과 흔하게 나타나는 관계 중의 하나는 상호 배타적 독점관계 (ARC Relation)이다. ARC Relation은 부모가 하나의 엔터티가 아니라 두개 이상의 엔터티 중에서 상황(Instance)에 따라 어느 한 엔터티가 부모 또는 주어가 되는 엔터티가 될 경우에 이를 ARC Relation이라고 한다.
다음의 대표적인 사례 ERD를 살펴 보자.



(그림1)에서 하나의 주문원장의 주문 주체는 개인 고객일 수 도 있으며 법인 고객일 수 도 있다.
그러므로 상기 ARC관계 엔터티(주문원장)의 모든 Instance(개체)는 반드시 개인 또는 법인 둘 중하나의 부모를 갖게 된다.
이러한 상황의 모델링을 DB Design화 시킬 경우에는 ARC-Relation을 명확히 지정할 수 있는 속성을 하위 엔터티에 포함을 하는 방법을 많이 활용하게 된다.
ARC관계 구분을 위해 마치 하위 엔터티를 몇 개의 서브타입(SUBTYPE)으로 설계하는 것과 유사하게 표현한다는 원리이다.
즉, 역으로 표현하여 (그림1)의 주문원장에는 개인고객주문원장 과 법인고객주문원장의 두개의 서브타입(SUBTYPE)이 존재한다고 할 때, 이 두 가지의 서브타입을 하나의 슈퍼타입 (SUPERTYPE)으로 표현한 것이 바로 주문원장이라고 할 수 있다. 이러한 경우 서브타입(SUBTYPE) 모델에 대한 DB Design 시 적용하는 방안은 서브타입 구분 속성을 추가하는 방법이며 이러한 서브타입 구분 속성을 (그림1)에서는 “개인법인고객구분” 이라는 속성을 주문원장 DB Design시에 추가한다는 의미이다.
이러한 DB Design기법은 하위 테이블에서 선 처리(Driving Table)될 경우에 자기 자신의 ARC관계 구분 정보로 판단하여 필요한 하나의 부모 테이블과 연결을 할 수 있기 때문에 데이터연결(JOIN)의 비효율을 예방할 수 있으며, 전사 통합 데이터베이스 구축을 위해서라도 올바른 DB Design 해법이라고 할 수 있다.
물론 이러한 DB Design시의 관계 명확화를 위한 속성의 추가로 인하여 추가 부담이 되는 1 Byte의 부담은 100만건일 경우 1 MB 가량의 저장공간의 증가가 따르게 된다. 하지만 이 정도의 투자는 실보다 득이 많다. 조인 엑세스 연결시 항시 2배의 부담을 가중시키는 것 보다는 이롭기 때문이다.
이렇게 ARC관계에서 하위 엔터티에 ARC관계 구분속성을 추가하지 않고 DB Design을 하는 경우도 있다. 이는 하위 테이블이 업무적으로 주 선 처리(Driving Table) 대상이 되지 않고 반드시 상위 부모 테이블로부터 선 처리(Driving)되는 경우만 존재한다면 ARC관계 구분속성을 하위 테이블에서 추가할 필요가 없게 된다. 그러나, 다양한 업무의 특성상 대부분의 경우 그렇지 않은 경우가 다반사이므로 이러한 DB Design이 많이 활용되지 않는다.
이러한 배경에 따른 DB Design 결과 DDL Script를 제시하면 다음과 같다.

CREATE TABLE ORDER_MASTER
(ORDER_NO number(8) not null, /* Primary Key */
cust_id varchar2(14) not null, /* 개인고객번호 또는 법인번호 */
cust_flag char(1) not null, /* ARC관계구분자 1:개인고객 , 2:법인고객 */
order_date char(8) not null,
. . . . . .