슈퍼타입과 서브타입 모델별 사용 장단점

슈퍼타입과 서브타입 정의

유사 엔티티를 일반화하면 슈퍼타입 엔티티가 생깁니다. 공통 속성은 슈퍼타입에 속하게 되고 고유한 속성은 서브타입으로 남게 됩니다. 반면 상세화를 하면 슈퍼타입 엔티티에서 서브타입 엔티티를 도출하며 일반화와 반대 방향으로 수행됩니다.

 

슈퍼타입과 서브타입 정의

서브타입은 주로 데이터를 일반화하는 과정인 통합하는 과정에서 발생합니다. 데이터를 일반화하면 상위 집합은 슈퍼타입이 되며, 슈퍼타입 부분 집합인 서브타입이 생깁니다. 슈퍼타입은 좀 더 일반적인 개념이고 서브타입은 좀 더 특수화된 개념입니다. 

슈퍼타입의 정의는 서브타입 정의보다 일반적이며 포괄적입니다.

 

일반적으로 엔티티가 복잡하면 여러 서브타입으로 나눠 단순한 모델로 만들 수 있습니다. 여러 엔티티에 중복 속성이 존재하며 슈퍼타입 도출해 중복 속성이 없는 모델을 만들 수 있습니다.

 

공통 중복 속성은 슈퍼타입에서 관리하고 엔티티별 고유 개별 속성은 엔티티에 남아서 서브 타입이 됩니다.

슈퍼타입과 서브타입 집합 간에는 몇가지 특성이 있습니다. 관계 속성을 포함한 슈퍼타입의 모든 속성은 서브타입에 속하게 됩니다. 이것은 일반화 수행하는 과정에서 서브타입 공통 속성을 슈퍼타입 속성으로 도출했기에 당연히 만족하는 특성입니다.

 

슈퍼타입과 서브타입 사이에는 상속개념이 존재하여 슈퍼타입 속성은 서브타입에 상속됩니다. 슈퍼타입과 서브타입을 합쳐야 완전한 인스턴스가 된다는 점에서는 서브타입의 고유 속성이나 관계도 슈퍼타입에 속하게 됩니다.

 

서브타입 엔티티 간 관계는 일반적으로 상호 배타적이나 간혹 포함적인 경우도 있습니다. 서브타입 엔티티 간 관계가 상호 배타적일 때는 서브타입 집합을 모두 합하면 슈퍼타입 집합(인스턴스 개수)이 됩니다.

 

즉 서브타입 집합 간 중첩되는 부분이 존재하지 않습니다. 서브타입 인스턴스는 반드시 그에 해당하는 슈퍼타입 인스턴스가 존재햐아 합니다. 반면 슈퍼타입 인스턴스에 해당하는 서브타입 인스턴스는 존재하지 않을 수 있습니다.

 

슈퍼타입의 구조는

모든 서브타입에 해당되는 관계 - Supertype - Attribute(모든 서브타입으로 상속되는 공통 속성)

Supertype - A-Subtype - Attributes (A 서브타입의 고유속성)

Supertype - B-Subtype - Attributes (B 서브타입의 고유속성)

 

슈퍼타입과 서브타입 구조에서 흔히 잘못 알고 있는 것 중 하나가 서브타입이 슈퍼타입 하위 개념으로 생각하는 것입니다.

슈퍼타입과 서브타입은 부모 자식 관계가 아닙니다. 슈퍼타입은 전체 집합, 서브타입은 부분 집합이며, 슈퍼타입 속성과 서브타입 속성을 합쳐야 전체 속성이 됩니다.

 

 

[물리적으로 분리된 고객 엔티티]

취미 - 개인고객 - 연락처

주요제품 - 법인고객 - 연락처

 

일반적으로 같은 속성이 여러번 사용되는 것도 중복이며 한 엔티티가 두 개의 엔티티와 배타 관계를 갖는 것도 바람직한 관계는 아니다.

배타 관계를 발생시키는 엔티티는 통합(일반화)해  슈퍼타입을 도출해야 합니다.

 

고객이라는 슈퍼타입을 도출합니다. 그리고 개인과 법인은 서브타입이 됩니다.

 

 

[슈퍼타입 도출 엔티티]

고객 [개인 - 취미 / 법인 - 주요제품] - 연락처 

 

슈퍼타입에는 서브타입을 구분할 수 있는 고객구분코드 속성이 관리됩니다. 슈퍼타입에는 서브타입을 구분할 수 있는 구분자를 관리하는 것이 일반적입니다.

 

고객 - 고객번호 / 고객구분코드 / 고객명

 

 

[고객을 통합해서 관리하는 엔티티]

취미 / 주요제품 - 고객 - 연락처

 

취미 - 고객번호 (FK) / 취미코그

주요제품 - 고객번호 (FK) / 제품코드 / 총판매액

고객 - 고객번호 (PK) / 고객명 / 고객구분코드 / 주민등록번호 / 법인등록번호 / 대표자명 / 성별 / 결혼여부 / 생년월일 / 설립일자

연라처 - 고객번호 (FK) / 연락처유형코드 / 주소 / 전화번호

 

고객 엔티티는 고객 구분에 의해 개인 고객과 법인 고객으로 이루어져 있습니다.

하지만 어떤 속성이 개인 고객 고유의 속성인지, 법인 고객 고유의 속성인지는 알 수 없습니다.

 

개인 고객일 때는 법인등록번호, 대표자명, 설립일자 등의 속성 값은 Null 이어야 합니다.

법인 고객일 때는 주민등록번호, 성별, 결혼여부, 생년월이 등의 속성 값은 Null 이어야 합니다.

 

고객 엔티티와 관계에서도 연락처, 취미, 주요제품 엔티티 중 어떤 엔티티가 고객 전체 집합과 관계가 존재하는지 개인 고객과 관계가 존재하는지 알 수 없습니다. 주요 제품 엔티티가 법인 고객과 관계가 있는지 직관적으로 알 수 없습니다.

 

모델 구조가 올바른지 판단하기 전 이런 업무 규칙이 반영이 안돼 있어 바람직한 논리 모델은 아닙니다.

하나의 엔티티에 속성 관계가 복잡하게 얽혀 있는 모델은 상세화해 서브타입을 도출하게 됩니다.

우선 고객 구분이 개인과 법인이므로 서브타입을 개인과 법인으로 분리합니다.

그리고 개인 서브타입에 개인 고객일 때만 관리되는 주민번호, 생년월일, 성별, 결혼여부 속성을 둡니다.

 

서브타입 속성이 슈퍼타입에 있어서도 안되고

슈퍼타입 속성이 서브타입에 있어서도 안됩니다.

 

 

슈퍼타입과 서브타입 사용방법

서브타입은 데이터 모델 구조를 잘 이해할 수 있게 해줍니다.

모델 가독성이 높아 당사자 간 커뮤니케이션을 돕습니다. 좋은 모델러는 서브타입을 잘 도출합니다. 서브타입을 잘 도출하는 것은 데이터 성격을 명확히 정의한다는 것을 의미합니다.

그러므로 서브타입을 제대로 도출하는 것은 모델러가 가져야할 중요한 기술입니다.

 

정의한 집합이 어떤 종류로 이루어졌는지 한 눈에 알 수 있게 표현한 것이 서브타입을 사용하는 가장 큰 의미입니다. 모델러가 정의한 집합이 어떤 종류의 집합으로 이루어졌는지를 입체적으로 보여주는 것이 서브타입입니다.

 

[일반 엔티티 구조]

고객 - 고객번호 PK

개인고객 (고객번호 FK / 주민등록번호 / 생년월일 / 성별 / 결혼여부)

법인고객 (고객번호 FK / 법인등록번호 / 대표자명 / 설립일자 / 주요제품명)

 

[서브타입 엔티티 구조]

고객 - 개인 (주민등록번호 / 생년월일 / 성별 / 결혼여부)

고객 - 법인 (법인등록번호 / 대표자명 / 설립일자 / 주요제품명)

 

주변 엔티티와 관계가 달라도 서브타입을 표현하는 것은 좋은 방법입니다.

 

[관계 표현된 서브타입]

고객 - 개인 - 취미

고객 - 법인 - 주요제품

고객 - 연락처 

 

서브타입은 모델의 확장성을 고려해서 도출할 수도 있습니다.

쇼핑몰에서 특정 서적만을 취급하면 서적 엔티티로 정의할 수 있지만 DVD나 의률 등이 추가될 것을 대비해 기타 서브타입을 도출할 수 있습니다.

 

[확장성을 고려한 서브타입]

상품 - 서적

상품 - 기타

 

[일반화된 서브타입]

사원 - 관리자

사원 - 기술자

사원 - 비서

 

관리자나 기술자, 비서는 사원의 종류이면서 사원의 부분집합입니다. 사원에 존재하는 데이터는 관리자이거나 기술자이거난 비서여야 합니다. 이렇게 데이터를 일반화하면 부분 집합은 전체집합과 '이다'(Is-A)의 관계가 성립합니다. 즉 관리자는 사원이다는 관계가 성립합니다.

하지만, 일반화와 약간 다른 개념으로 서브타입을 사용할 때도 있습니다.

 

일부(Part-Of)의 관계가 성립해 프로그램과 사용자메뉴얼은 둘다 소프트웨어 일부가 됩니다.

 

[구성 요소로 서브타입]

소프트웨어 - 프로그램

소프트웨어 - 사용자메뉴얼

 

따라서 프로그램은 소프트웨어다. 같이 일반화에서 성립한 '이다'의 관계가 성립하지 않고 프로그램은 소프트웨어의 구성요소다. 사용자 메뉴얼은 소프트웨어의 구성 요소이다가 성립합니다.

 

위 모델에서는 프로그램과 사용자메뉴얼이 둘 다 모여야 완전한 소프트웨어가 된다는 것을 의미합니다.

이렇게 구성요소를 서브타입으로 표현하면 서브타입 간 공통된 속성이 존재하지 않고 각자 고유한 속성만 존재합니다.

 

[중복 서브타입 릴레이션]

고객 - 홍길동 / 개인고객 

고객 - 홍길동 / 사원

개인고객 - 홍길동 / 사업자등록번호

사원 - 홍길동 / 사원번호

 

고객 엔티티에 홍길동이 개인고객과 사원으로 두번 등장한다. 같은 인물에 대해 다른 고객번호로 두 인스턴스가 존재한다.

그리고 서브타입인 개인고객, 사원 엔티티에 각각 인스턴스가 존재한다.

 

만약 홍길동이 개인 고객에만 해당하면 슈퍼타입과 서브타입 하나씩 인스턴스가 존재할 것이다. 카디널리티 1:1

이 방법은 데이터 모델이나 데이터 관리 방법이 배타 서브타입과 비슷하다. 서브타입의 인스턴스 총 개수는 슈퍼타입의 인스턴스 갯수와 같다. 그래서 직관적이고 사용하기 편리하다.

 

하지만 고객 엔티티에 동일 인물이 두 번 존재하는 것은 단점이 될 수 있다.

단점은 아니지만 통합 고객 차원에서는 단점이 될 수 있다.

 

데이터가 이렇게 관리되면 고객 엔티티는 고객에 포함되는 사람을 역할(Role)에 따라 개별적으로 관리하는 엔티티가 됩니다. 만약 주민번호 하나에 고객번호 하나만 존재해야 한다는 요건이 있다면 고객 엔티티의 데이터를 한번 더 일반화한 통합고객 엔티티 정도가 필요할 것입니다. 중복 속성을 제거하기 위한 통합고객 같은 엔티티가 필수적입니다.

 

중복 서브타입의 데이터를 관리하는 다른 방법은 슈퍼타입인 고객 엔티티에 하나의 인스턴스만 존재하는 것입니다. 그 대신 구분자 속성의 코드값이 추가됩니다.

 

[서브타입 구분자로 관리하는 중복 서브타입 릴레이션]

고객 - 고객번호 / 고객명 / 주민등록번호 / 고객구분코드

개인고객 - 고객번호 / 사업자등록번호 / 업종구분코드

사원 - 고객번호 / 사원번호 / 입사일자

 

이 릴레이션은 슈퍼타입과 서브타입 사이 관계 카디널리티가 일대다 (1:M)이다. 물론 고객 엔티티와 개인고객, 사원 엔티티는 일대일 관계다. 

 

만약 개인 고객 상태인 홍길동이 입사해 사원이되면

고객구분코드 속성 값이 개인고객 + 사원으로 업데이트 되고 사원 엔티티에 인스턴스가 추가된다.

개인고객 릴레이션에 존재하는 홍길동에 대한 인스턴스는 그대로 존재한다. 이처럼 데이터를 관리하면 주민등록번호 하나에 고객번호 하나가 돼 통합 고객에 대한 혼선도 없고 데이터의 중복도 없다는게 장점이다.

 

반면 고객구분코드 속성 값에 단점이 하나 있다.

만약 개인고객과 사원 두 종류가 아니라 다섯 종류의 서브타입이 구성되면 코드값이 많이 늘어날 것이다.

추후 엄청난 코드값이 추가되고 관리가 힘들 것이다.

또한 개인 고객의 숫자를 알아야 하면 고객구분코드 속성값이 개인고객과 개인고객+사원을 함께 조회해야 한다.

요건에 따라 서브타입 엔티티별로 조회해야 하므로 바람직하지 않다.

그래서 사용한다면 제한적으로만 사용해야 한다. 

 

[여부 속성으로 서브타입을 관리하는 모델]

고객 - 고객번호 / 고객명 / 주민등록번호 / 개인고객 여부(Y/N) / 사원여부(Y/N)

개인고객 - 고객번호 / 사업자등록번호

사원 - 고객번호 / 사원번호

 

서브타입을 여부 속성으로 관리하는 모델 릴레이션이다. 홍길도이 사원과 개인고객 모두 포함되면 개인고객여부와 사원여부 속성이 Y 값으로 관리된다. 코드값보단 편리하지만 변화에 취약하며 모델 상 서브타입 개념이 명확히 보이지 않는다

 

 

슈퍼타입 엔티티와 서브타입 엔티티 간 관계는 아래와 같이 구분됩니다.

 

Exclusive 서브타입 & Complete 서브타입

슈퍼타입의 한 인스턴스는 하나의 서브타입 인스턴스와 관계가 존재할 수 있다.

슈퍼타입의 모든 인스턴스는 관계가 존재하는 서브타입의 인스턴스가 존재한다.

 

Exclusive 서브타입 & Incomplete 서브타입

슈퍼타입의 한 인스턴스는 하나의 서브타입 인스턴스와 관계가 존재할 수 있다.

슈퍼타입의 어떤 인스턴스는 서브타입의 인스턴스와 관계가 존재하지 않을 수 있다.

 

Inclusive 서브타입 & Complete 서브타입

슈퍼타입의 한 인스턴스가 두 개 이상의 서브타입 인스턴스와 관계가 존재할 수 있다

슈퍼타입의 모든 인스턴스는 관계가 존재하는 서브타입의 인스턴스가 존재한다.

 

Inclusive 서브타입 & Incomplete 서브타입

슈퍼타입의 한 인스턴스가 두 개 이상의 서브타입 인스턴스와 관계가 존재할 수 있다

슈퍼타입의 어떤 인스턴스는 서브타입의 인스턴스와 관계가 존재하지 않을 수 있다.

 

이 중에서 일반적인 종류의 서브타입은 Exclusive 서브타입과 Complete 서브타입으로 실무에서 많이 존재합니다.

데이터 통합 과정을 거쳐 서브타입이 도출됐다면 대부분 Complete 서브타입이다.

 

 

서브타입의 물리모델 변환

서브타입 구조를 실제 물리 구조로 변환하는 것은 물리 모델링 단계라 해도 모델 구조를 확정하는 것은 빠를수록 좋습니다.

성능 등의 물리적 요소를 고려해 물리 모델링 단계에서 진행해야 하는 것처럼 보이지만 서브타입으로 도출된 엔티티는 핵심적인 엔티티일 가능성 커서 관계를 갖는 하위 엔티티가 많이 존재하는데 상위 구조가 바뀌면 관계도 바뀌게 됩니다. 관계는 중요한 속성으로 물리 모델링 단계에서 바뀌면 혼선과 낭비를 줄일 수 있습니다. 

 

타입 1 - 분할

Sub1 : supertype -key / supertype - attr1 / subtype - attr1

Sub2 : supertype2 - key / supertype - attr1 / subtype - attr1

 

타입 2 - 통합

Sub : supertype - key / supertype - attr1 / subtype - attr1

 

타입 3 - 혼합

Sub : supertype - key / supertype - attr1 / subtype - discriminator

Sub1 : supertype - key / subtype1 - attr1 / supertype1 - attr2

Sub2 : supertype - key / subtype2 - attr1 / supertype2 - attr2

 

서브타입을 물리구조로 변환하는 첫 번째 방법은 서브타입마다 하나의 엔티티로 만드는 것

엔티티가 명확히 구분되는 장점이 있다. 서브타입을 서로 약 결합 관계에서 사용한다.

 

두 번째 방법은 하나의 엔티티로 통합한다. 이는 서브타입별 속성이 많이 다르지 않고 업무가 유사할 때 사용한다.

 

세 번째 방법은 통합 성격의 엔티티와 서브타입별 엔티티로 분리하는 방법입니다. 통합하면 속성이 너무 많아지거나 서브타입별 속성이 많이 다를 때 사용합니다.

 

 

 

[서브타입별 엔티티로 분리한 모델]

 

부서 : 부서코드, 부서명

정규직사원 : 사원 ID, 부서코드 

계약직사원 : 사원 ID, 부서코드

 

위 DDL에서 주의할 사항은 사원 ID를 체크하기 위한 트리거다. 사원 ID는 정규직 사원이나 계약직 사원 사이에 중복되면 안되므로 애플리케이션에서 구현도 가능하지만 원천적으로 데이터베이스에서 체크하는 것이 바람직하다.

 

이때 자주 사용되는 방법이 사원 ID를 관리하는 엔티티를 추가하는 것이다. 하지만 이렇게 추가된 엔티티는 슈퍼타입 개념이 약간 존재하는 엔티티로 조금만 더 확장하면 결국 슈퍼타입과 서브타입을 도출한 모델과 유사해진다. 슈퍼타입을 없애기 위한 구조인데 PK 중복을 방지하기 위해 결국 슈퍼타입 성격의 엔티티가 사용된다는 점은 애초 목적을 반하는 것일 수 있다.

 

또 한 가지 주의점은 계약직이면서 정규직일 수 있다. 이때 어떤 사원은 중복 서브타입이 발생할 수 있다. 이때 서브 타입별로 엔티티를 분리하는 것이 오히려 데이터를 관리하기 수월할 수 있다.

 

장점

엔티티 속성이 근본적으로 구분되어 명확하다

개별 서브타입을 사용하는 요건에서 효율적이다

각 엔티티에 해당하는 업무에 상호 영향 없이 처리할 수 있다

각 엔티티 크기가 줄어든다

정규직 사원과 계약직 사원 엔티티를 동시에 조회하는 요건이 없다면 UNION 구문이 필요없어 성능에서 유리하다. 

 

단점

정규직 사원과 계약직 사원을 동시에 조회하는 요건이 있을 때 UNION 등이 발생하며 SQL 복잡해지고 성능 면에서 불리하다.

사원구분코드 속성과 같이 서브타입을 구분하는 속성을 업무에서 사용하면 처리하기 불편하다

시퀀스나 채번 관리 엔티티를 사용해 주 식별자 값을 생성하기 복잡하다

업무는 개별적으로 처리돼도 데이터는 통합된 모습이 아니므로 DW등의 요건에 의해 조건이 복잡해질 수 있다

속성이 반복되어 넓은 의미로 1정규형이 아니다

 

 

[하나의 엔티티로 통합한 모델]

사원 : 사원 ID, 사원구분코드, 부서코드, 사원명

 

슈퍼타입에 통합되는 것으로 엔티티명은 사원으로 한다.

주의할 점은 서브타입을 구분하던 사원구분코드 속성이 반드시 존재해야 한다

이 방법은 사원이 정규직일 때는 계약직 속성이 Null 발생하고, 계약직 사원일 때는 정규직 속성이 Null 된다

향후 고유 속성이 늘어날 가능성이 있을 때는 적합하지 않을 수 있습니다.

 

장점 

슈퍼타입과 서브타입 조인이 발생하지 않아 조회 SQL 단순해지고 성능이 좋아질 때가 많습니다

엔티티 수 감소로 관리가 용이합니다

복잡한 관계가 없어 모델이 단순하고 ERD 관리가 편합니다

주 식별자를 관리하기 편합니다

전체 서브타입 검색할 때 UNION 등이 발생하지 않아 성능에서 효율적입니다.

 

단점

엔티티 속성 개수와 인덱스가 많아져 크기가 증가합니다

Null 값이 존재하는 속성이 많아집니다

정규직 사원이나 계약직 사원에 대한 업무가 추가되거나 변경되면 애플리케이션에 끼치는 영향이 커집니다

업무 규칙을 모델에 표현하기 어렵다

공통 속성만 조회하는 요건이 빈번하거나 조회 범위가 넓으면 IO 가 많아져 성능이 나빠진다

엔티티 정체성이 희석될 수 있다

 

 

[통합 엔티티와 개별 엔티티 혼합 모델]

 

부서 : 부서코드, 부서명 

사원 : 사원 ID(FK), 사원구분코드, 사원명

계약직 사원 : 사원 ID (PK), 시급여

정규직 사원 : 사원 ID (PK), 월급여

 

통합 엔티티와 개별 엔티티를 혼합하는 세번째 방법은 슈퍼타입과 서브타입 도출 의도를 가장 잘 반영한 모델입니다.

슈퍼타입과 서브타입은 업무 규칙을 가장 잘 표현한 모델입니다.

 

이 방법은 데이터가 주로 함께 사용돼 통합하는게 좋지만, 통합하면 속성 개수가 너무 많아질 때 유용하게 사용됩니다.

자주 사용되는 속성도 통합 엔티티에 두어 통합 엔티티만으로 많은 요건을 해결하도록 하는게 바람직합니다.

반면 서브타입인 개별 엔티티는 고유 속성으로 이루어집니다. 

 

통합 엔티티와 개별 엔티티를 혼합해 사용하는 방법은 시스템 전반에서 중요하게 사용되는 엔티티에서 발생됩니다.

그다지 중요하지 않은 엔티티는 사용빈도도 낮을 것이며 업무 규칙도 복잡하지 않아 통합에 대한 심도 있는 고려가 필요 없을 수 있습니다.

 

엔티티를 통합했을 때 속성 개수가 너무 많아지면 이 방법의 사용을 고려할 수 있습니다. 속성 개수가 200~300개인 엔티티는 흔히 볼 수 있습니다. 정규형이 아닌 경우도 존재하지만 서브타입이 도출되지 않아 분리해야할 속성을 모르는 경우도 존재합니다.

 

업무에서 핵심적으로 사용되는 엔티티 속성 개수는 많은 것은 바람직하지 않습니다. 인스턴스 크기가 커지면 한 블록에 저장되는 인스턴스 개수가 감소하게 돼 조회 서능에 나쁜 영향을 미칠 수 있습니다.

 

공통 속성 위주로 수행되는 업무가 많다면 이 방법을 사용해야 합니다. 서브 타입별 고유 속성은 특별할 때 사용하고 대부분 공통 속성으로 업무가 이뤄질 때 이 모델이 유용합니다.

 

데이터의 트랜잭션 처리를 원할하게 하려 엔티티를 분리할 때도 존재합니다. 사원 엔티티와 정규직 사원 엔티티는 보통 하나의 트랜잭션으로 처리될 것입니다. 하지만 사원 엔티티를 사용할 때 정규직 사원 엔티티는 별도 트랜잭션으로 사용해야 할 때도 있습니다. 물론 반대의 경우도 있지만 서로에게 영향(LOCK)을 끼치지 않고 빨리 처리될 수 있게 엔티티를 분리하는 것이 좋습니다.

 

장점

슈퍼타입인 통합 엔티티의 한 블록에 많은 인스턴스가 저장되므로 핵심 조회 요건의 성능이 좋아질 때가 많습니다

모델에 업무 규칙이 표현되므로 모델 가독성이 높아집니다

추가 업무로 어플리케이션 변경 영향이 감소합니다. 사원, 계약직, 정규직 사원 엔티티로 분산되며 슈퍼타입 사원 엔티티에 속성이 추가되지 않도록 관리할 수 있습니다

집계나 DW(DAta Warehouse) 요건을 만족할 경우가 커집니다. 반드시 필요한 것은 아니지만 전사 차원에서 고려하면 바람직하다.

데이터 저장 공간을 가장 효율적으로 사용합니다

 

단점

조회 요건에 따라 조인이나 조인 후 유니온 등이 발생해 성능 효율이 떨어질 수 있습니다

여러 엔티티로 나뉘어 관리가 어렵습니다

배타, 중복, Complete, Incomplete 서브타입의 종류에 따라 인스턴스 발생시키는데 혼선이 발생할 수 있습니다

계약직, 정규직 사원 엔티티의 주 식별자 값이 띄엄띄엄 생깁니다

서브타입을 배타 관계로 관리하면 보통 R(Referece Integrity)를 생성할 수 없습니다

서브타입을 배타 관계로 관리하던 주 식별자를 관리하기 복잡해진다