1. 서브타입과 코드

서브타입은 인스턴스를 나눈 집합
코드는 특정 속성을 대상
가독성을 위해 특정 툴에서 코드를 서브타입처럼 표현하는 경우가 있음

erd 에 표시 할 경우 어떤식으로든 코드와 서브타입 구분을 해 주어야 함

h1.2.Is a / Part of 서브타입

서브타입은 Is a 관계가 되어야 함

이 경우 "개인고객은 고객이다" 라는 서브-슈퍼 타입 간 관계가 성립 됨
이 경우 "프로그램은 소프트웨어의 일부이다" 라는 서브-슈퍼타입 간 관계가 성립 됨
인스턴스의 부분집합이 아닌 속성의 부분집합으로 엄밀하게 말하면 서브타입이 아님
가독성을 위해 최상위 수준 개념 모델에서는 가끔 사용하는 경우도 있음
우선 1:1 과계의 엔티티를 서브타입으로 잘못 파악한 것이 아닌지 확인 해야 함

h1.3.배타/중복 Subtype

모든 서브타입의 인스턴스 합은 슈퍼타입 인스턴스와 동일
업무적으로 배타/중복을 명확하게 도출하는 것이 필요
배타/중복 표기법 예시

배타 관계 표기

중복 관계 표기

h3.3-1 배타 서브타입 및 이력 데이타

배타 서브타입의 판단은 특정 시점에 동시에 중복이 발생하지 않는다는 의미
이력 데이터를 하나의 엔티티에 같이 표현하여 중복 서브타입으로 착각하는 경우가 있음

위와 같이 설계 후

실제 물리 모델로 분리 해 보았을 때 중복 관계인 것 처럼 보이나, 실제로는 이력 데이터를 포함하는 것

서브타입 엔티티는 하위 엔티티가 많이 있는 경우가 많으므로 이력 데이터는 별도의 엔티티로 분리하도록 권장

h3.3-2 중복 서브타입의 설계

h5.a. 1:1 관계의 슈퍼-서브타입

서브타입 인스턴스를 다 합치면 슈퍼타입 인스턴스와 동일함
배타 서브타입과 유사한 방법임

h5.b. 1:M 관계의 슈퍼-서브타입

하나의 슈퍼타입 인스턴스가 복수의 서브타입과 대응 함
이 방법은 여러모로 난해한 구분이며 권장하지 않음

h3.3-3 중복 서브타입 설계 시 주의점

*고객과 사원 엔티티를 통합 해야 하는 요건
*홍길동 처럼 고객이면서 사원인 경우 있음
*이를 중복 서브타입으로 모델링 하면 아래와 같이 표현 되나...

h5.a.엔티티의 실체를 잘못 파악 한 문제

이 엔티티는 사람을 표현하는 것이 아닌 역할을 담는 엔티티이므로
홍길동도 고객 역할, 사원 역할로 별도의 인스턴스가 각각 존재 해야 함
실체(사람) 을 구분하는 별도의 엔티티가 하나 더 필요

h5.b.중복 서브타입에서 구분 속성별 조회 문제

전체 개인 고객 조회 시 개인고객 or 개인고객+사원고객을 함께 조회 해야 함
서브타입이 늘어날 수록 변화에 취약하게 됨
부득이한 경우 소수의 서브타입이 존재하고 향후 서브타입 추가가 없다는 가정 하에 사용 고려 가능

h5.c.구분여부 속성 통한 변칙적인 관리 방법

이 모델은 변화에 취약하며 모델로만 보아서는 서브타입 개념이 명확하게 보이지 않는다고 함

h1.4 완전/불완전 서브타입

완전 서브타입은 슈퍼타입의 모든 인스턴스가 서브타입에 존재
불완전 서브타입은 슈퍼타입 인스턴스가 서브타입 어느 곳에도 없을 수 있는 상태
불완전 서브타입은 드물지만 엔티티를 과감하게 통합하는 과정에서 발생할 수 있음

아래와 같이 고객의 서브타입은 개인/사원/가망 고객이나,
가망고객은 이름과 주민번호만 관리한다는 요건에 의해 서브타입 고유 속성이 없음

이를 물리모델로 아래와 같이 변환하면 가망고객 서브타입 엔티티는 사라짐

h1.5 슈퍼타입-서브타입 관계 요약

모든 종류의 서브타입에서 슈퍼타입 인스턴스를 삭제하면 관련 서브타입 인스턴스도 삭제 필요

슈퍼타입-서브타입 관계 오해

슈퍼-서브 타입은 부모 자식 관계가 아니다 - 필요에 의해 분리 된 1:1 관계와 유사하다
슈퍼-서브 타입은 종속 관계이긴 하다 - 고객 엔티티 없이 개인고객 엔티티도 없다

h1.6 슈퍼타입-서브타입의 물리 모델 변환

엔티티 통합/개별생성/슈퍼-서브타입 별 생성으로 크게 분류할 수 있음

엔티티 분할 방법

위 모델의 경우 정규직/계약직 서브타입을 각각의 엔티티로 생성 하였을 경우 물리모델은 아래와 같음

서브타입 엔티티 명은 슈퍼타입 엔티티 명을 차용하는 것이 바람직
슈퍼타입의 속성은 모두 개별 서브타입 엔티티에 포합되어야 함
서브타입 구분 속성은 삭제

h5.사원번호 속성 채번 시 주의 필요 한 경우
정규/계약직 사원 모두에서 사원번호가 중복되지 말아야 할 업무적 요건이 있을 경우
별도의 테이블에서 중복 관리를 해야 하며, Table unique constraint 로는 관리할 수 없다
Application에서 관리하는 것 보다 DB 레벨에서 Trigger 로 관리하는 것을 권장한다
Trigger 보다 더 좋은 방법은 사원번호만 따로 관리하는 내역 엔티티를 추가하는 것이나
이는 또다른 슈퍼타입 엔티티가 되므로 엔티티를 분리하는 목적에 어긋날 수 도 있다
기본적으로 주 식별자는 하나의 엔티티 안에서만 관리되는게 정상이므로 이럴 경우는 엔티티 분리가 바람직하지 않을 수 있다

사용 가능한 경우

서브타입별 업무가 독립적이어서 서브타입 별 상호 관계가 없을 때
서브타입 별 조회 요건이 대부분일 때
서브타입들의 주 식별자가 상호 배타적이어야 한다는 요건이 없을 때

장점/단점

엔티티의 속성이 근본적으로 구분되므로 관리가 명확
개별 서브타입 조회가 많을 때 효과적
각 엔티티 해당 업무에 대해 상호 영향을 끼치지 않고 처리 가능하다(서브 엔티티 속성 추가 등)
각 엔티티의 크기 감소한다
슈퍼타입과 조인이 필요 없어 성능에서 유리하다
널 값을 가지는 속성이 줄어든다
모든 서브타입 동시 조회 요건 시에는 Union 이 발생하며 성능도 불리하다
서브타입 구분 속성을 사용하면 처리 불편하다
주 식별자 값을 생성하기 복잡하다
업무는 개별적으로 처리되지만 데이터는 통합되지 않앗으므로 DW 요건등에 의한 통합 데이터 조회 처리 시 어렵다
공통 속성이 개별 엔티티에 반복되므로 넓은 의미로 제 1 정규형 위배이다
종합적으로 판단했을 때 이 방법은 회의적이며 애초에 독립 설계한 모델이 아니라 슈퍼-서브타입으로 설계 했을 경우 이 방법으로 분할 하는일은 드물다

h3.엔티티 통합 방법

위 모델의 경우 정규직/계약직 서브타입을 각각의 엔티티로 생성 하였을 경우 물리모델은 아래와 같음

엔티티명, 주 식별자는 슈퍼타입과 동일
서브타입에 속하는 고유 속성은 모두 슈퍼타입에 추가 함
서브타입 구분하는 사원유형코드 속성이 반드시 존재해야 함
아래와 같이 다른 서브타입에 속하는 속성에는 null 값이 늘어나게 됨

이 경우는 모델로만 보아서는 서브타입의 조건에 따른 업무 규칙이 명확하지 않으며 값 관리가 되지 않으므로
Check constraint 로 서브타입 별 필수 속성 및 null 속성을 관리하는 방법을 권장함


CONSTRAINT_ CK_사원구분
CHECK (
(사원유형코드 = '정규직' AND
월급여 IS NOT NULL AND
연차휴가 IS NOT NULL AND
과정코드 IS NOT NULL AND
시급여 IS NULL AND
추가수당 IS NULL AND
계약기간 IS NULL)
OR
(사원유형코드 = '계약직' AND
월급여 IS NULL AND
연차휴가 IS NULL AND
과정코드 IS NULL AND
시급여 IS NOT NULL AND
추기수당 IS NOT NULL AND
계약기간 IS NOT NULL)
);

사용 가능한 경우

서브타입 전체를 대상으로 하는 업무가 빈번할 때
서브타입 간 업무적으로 강한 결합을 가질 때
대부분의 업무가 하나의 서브타입에서만 처리될 때 - 메인 서브타입 기준으로 다른 서브타입 통합
서브타입에서 관리하는 데이터(속성)가 중요하지 않거나 소수일 때

장점/단점

슈퍼-서브타입 간 조인이 발생하지 않아 쿼리가 단순해 지며 성능이 높아질 경우가 많다
엔티티 수가 감소 해 관리가 용이하다
전체 서브타입을 검색 할 경우 효과적?
엔티티 속성이 많아져 단일 엔티티 크기가 증가한다
널 값을 가지는 속성이 많아진다
하나의 서브타입 별 업무가 추가되거나 변경되면 다른 서브타입의 어플리케이션에 미치는 영향이 커진다
업무 규칙을 모델만으로 표현하기 어렵다
슈퍼타입 속성많을 조회하는 요건이 많을 경우나 조회 범위가 넓을 시 IO 가 많아져 성능에 악형향을 준다
엔티티의 정체성이 희석될 수 있다

데이터는 기본적으로 통합 관리하는게 바람직하므로 핵심 엔티티가 아닐 경우 이 방법을 사용하는것도 좋으나, 핵심 엔티티일 경우 슈퍼-서브타입 별 생성하는 방법과 고민 해 보아야 함

슈퍼-서브타입 별 생성

위 모델의 경우 아래와 같이 물리모델로 생성 됨

서브타입 주 식별자는 슈퍼타입의 식별자를 상속받으며
서브타입 구분하는 코드 속성은 반드시 필요

사용 가능한 경우

서브타입 간 연관성이 있을 때 - 동시 조회 요건이 많을 때
주요 엔티티일 때 - 주요 에티티에 사용되는 다양한 조건을 만족시키며 확장성이 좋음
슈퍼타입 별 공통 속성을 대상으로 하는 업무가 많을 때
서브타입 고유 속성이 많을 때
업무 변경이 잦아 속성이 빈번하게 추가될 때 - 중요하지 않은 속성은 서브타입에 추가 가능
트렌젝션 분리할 때 - 사원 엔티티를 사용(Update) 하면서 정규직 사원 엔티티에도 별도 트렌젝션을 발생시킬 때
통합하면 속성 갯수가 많아질 때

장점/단점

슈퍼타입 엔티티는 한 블록에 많은 인스턴스(row) 가 저장되므로 조회 성능 향상 가능
논리 모델과 유사하여 업무 규칙이 표현 됨
확장성이 좋음 - 변경 요건이 각 엔티티별로 분산됨
집계나 DW 요건을 만족할 가능성이 커짐
데이터 저장 공간을 효율적으로 사용

조회 요건에 따라 조인/유니온 등이 발생 할 가능성도 있음
엔티티 갯수 증가로 관리가 어려워진다
인스턴스 발생 시 혼선이 발생할 수 있다

이 모델은 결론적으로 슈퍼-서브타입 의도를 가장 잘 표현 한 모델이다.

슈퍼-서브타입 별 생성(배타 관계 일 경우)

이 모델은 일반적인 모델이지만 중복이나 불완전 서브타입등을 모두 관리할 수 있으나,
배타/완전 관계의 서브타입을 강제로 제약 할 수 있는 모델은 아래와 같다

서브타입 엔티티의 주 식별자를 슈퍼타입 엔티티로 상속한 점이 기본 모델과 다르다.
배타 제약은 배타 관계가 제어
서브타입 전체 인스턴스 합이 슈퍼타입이 된다는 제약은 식별자 상속으로 제어
이 경우 서브타입이 상위 엔티티의 성격을 지닌다 - 개별 엔티티의 공통 속성을 모아 슈퍼타입 엔티티 생성
고객고유번호는 unique 해야 무결성을 지킬 수 있다
서브타입 엔티티에 데이터가 먼저 발생한다

h5 일반 슈퍼-서브타입 물리모델과 비료
장점은 배타/완전 서브타입을 가장 장 표현 한 모델이다 - 모델 구조가 일종의 제약 역할을 한다
단점은 물리적으로 FK 제약을 생성할 수 없다는 것
주 식별자 값을 채번하기 어렵다 - 데이터 생성이 서브타입부터 발생하므로

h1.7. 중첩 서브타입

서브타입 안에 서브타입이 존재하는 것
다수의 엔티티를 통합하는 과정에서 발생 가능하다
개념, 초기 모델링 단계에서는 간혹 보이지만 물리적으로 구현되는 일은 드물다

하나 이상의 서브타입 구분자가 필요하다 - 고객유형코드, 자연인구분코드, 법인구분코드
구분자 사이에 계층이 존재한다 - 고객유형 > 자연인구분
하위 계층의 구분코드 값은 상위 계층의 값에 종속된다

물리모델 그대로 변환하면 아래와 같으나

관계가 복잡해 질 뿐 실익이 별로 없어 주로 첫 번 째나 마지막 서브타입 기준으로 물리모델을 생성한다