1. 배타(Exclusive 또는 Disjoint) 서브타입

• 서브타입 부분집합간에 공통 부분을 갖지 않는 서브타입
• 전체 서브타입의 합 = 슈퍼타입
• 오른쪽 모델은 정보 공학 표기법(서브타입 기호에 X표시가 있으면 배타 서브타입)
• 실제로 발생하는 대부분 서브타입

2. 중복(Inclusive 또는 Overlapping) 서브타입

• 서브타입 부분집합간에 겹쳐지는 부분이 존재하는 서브타입
• 슈퍼타입의 하나의 인스턴스는 최소한 하나 이상의 서브타입과 관계가 존재
• 자주 발생하지 않는 서브타입이며 데이터를 관리하는 방법이 혼란스러울 수 있다.
  • 슈퍼타입 하나의 인스턴스가 하나의 서브타입과 관계가 존재하는지 아니면 여러 개의 서브타입과 관계가 존재하는지에 따라 두가지 데이터 관리방법이 존재한다.

예제

• 고객 엔티티에 사원 데이터를 통합한 모델
• 사원이면서 고객인 사람이 존재할 수 있으므로 중복 서브타입
• 오른쪽 물리 모델만으로 서브타입간의 관계가 배타 서브타입인지, 중복 서브타입인지 알 수 없다.
• 일차적으로 CASE 툴에서 엔티티를 설명하는 부분에 데이터 관리 방법을 상세하게 기술해야 하며 사례 데이터를 작성해 놓는 것이 좋다.

데이터 관리방법1

• 고객 엔티티에는 '홍길동'이라는 같은 인물에 대해 다른 고객번호로 두 인스턴스가 존재
• 데이터 모델이나 데이터 관리 방법이 배타 서브타입과 유사
  • 슈퍼타입 릴레이션과 서브타입 릴레이션 관계의 카디널리티는 1:1
  • 서브타입의 인스턴스 총개수 = 슈퍼타입의 인스턴스 개수
  • 직관적이고 사용하기 편리하지만 고객 엔티티에 같은 사람이 두번 존재하는 단점
• 데이터 중복을 제거하기 위해 주민등록번호 하나에 고객번호 하나만 존재하는 통합고객같은 엔티티 추가

데이터 관리방법2

• 슈퍼타입인 고객 엔티티에 하나의 인스턴스만 존재
• 대신 구분자 속성의 코드값이 추가된다.(개인고객+사원 형태 추가)
• 슈퍼타입과 서브타입 사이의 관계 카디널리티가 1:M
• 통합 고객에 대한 혼선도 없고 데이터의 중복도 없다는 장점
• 하지만 많은 서브타입이 존재할경우 고객구분코드값 관리가 힘들어진다.

데이터 관리방법3

• 서브타입을 여부 속성으로 관리하는 모델('Y' or 'N')
• 위의 데이터 관리방법2보다는 편리한 모델이지만 변화에 마찬가지로 취약하며 구분자는 서브타입의 종류를 명확하게 표현해야 하는데 이 모델상으로 서브타입 개념을 명확히 알 수 없다.

3. 완전한(Complete) 서브타입

• 슈퍼타입의 모든 인스턴스가 최소한 하나의 서브타입 인스턴스로 반드시 존재하는 서브타입

4. 완전하지 않은(Incomplete) 서브타입

• 슈퍼타입에만 인스턴스가 존재하고 서브타입에는 인스턴스가 존재하지 않는 서브타입(즉 고유 속성이 존재하지 않는 슈퍼타입 인스턴스가 존재할 수 있다.)
• 물론 서브타입 인스턴스에 해당하는 슈퍼타입 인스턴스는 반드시 존재해야 하며 오직 하나만 존재해야 한다.
• 예제

• 김길동이라는 가망고객은 슈퍼타입인 고객 엔티티에는 존재하지만 서브타입은 존재하지 않는다.
• 개념 모델링이나 초기 논리 모델링 단계에서는 가망고객처럼 명확하게 서브타입이 도출되지 않아 슈퍼타입에 속하는 전체 집합이 명확하지 않을 수 있는데 이때는 '기타'라는 서브 타입을 사용해 미정의 상태라는 것을 표현한다.