서브타입 분할

• 서브타입 구조를 실제 물리 구조로 변환하는 경우 모델 구조를 빠르게 확정하는 것이 좋음.
• 서브타입으로 도출된 엔터티는 핵심적인 엔터티일 가능성이 크며 관계를 갖는 하위 엔터티가 많이 존재,
• 상위 구조가 바뀌면 관계도 바뀌게 됨(커뮤니케이션 혼선, 시간 낭비 발생)
• 자주 사용하고 중요한 서브타입은 성능을 고려해서 가능한 이른 단계에 모델 구조를 결정

서브타입 분할 방법

서브타입 분할 모델을 선택하는 기준

• 조회 조건에 따른 모델분리

서브타입 모델

서브타입별 엔터티로 분할(타입1)

• 슈퍼타입 속성은 모두 개발 엔터티에 포함되어야 한다.
• 서브타입을 구분하기 위한(\!그림 6.34_슈퍼타입 만터티가 상위 엔터티인 모댈.png\!사원구분코드) 속성은 삭제
• 서브타입의 고유 속성들은 개별 엔터티 속성으로 그대로 유지

하나의 엔터티로 통합(타입2)

• 서브타입을 구분하는 구분코드(사원구분코드) 속성이 반드시 존재해야 한다.
• Null 값이 많이 발생해 서브타입별 고유 속성이 많거나 향후 고유 속성이 늘어날 경우 적합하지 않음
• 핵심적인 엔터티가 아닌 경우 하나의 엔터티로 가져가는 것이 편함.
• 빈번히 사용되지 않는 경우 엔터티의 엔터티의 수를 줄이기 위해 하나의 엔터티 동합 필요

통합 엔터티와 개별 엔터티 혼합(타입3)

• 업무규칙을 가장 잘 표현한 모델. 물리모델도 유사하게 생성하는 것이 좋다.
• 시스템 전반적으로 중요하게 사용되는 엔터티에 적용
• 엔터티를 통합했을 때 속성 개수가 너무 많아지는 경우 고려 (업무에서 핵심적으로 사용되는 경우 속성개수가 많은 것은 지양)
• 속성개수가 많아지면 한 블록(Block)에 저장되는 인스턴스의 개수가 감소하게 되어 조회 성능에 악영향
• 공통 속성 위주로 수행되는 업무가 많은 경우 사용
• 서브타입별로 고유 속성이 많을 때 사용(타입2와 같이 많은 속성에서 Null발생 제어)
• 서브타입을 구분하는 구분코드(사원구분코드) 속성이 반드시 존재

• 그림6.34: 모든 서브타입 관리 가능, 그림6.35: Exclusive & Complete 서브타입(주로 사용)

배타 서브타입을 물리 구조로 구현한 모델의 단점

• 참조 무결성 제약 생성 할 수 없다. (서브타입 인스턴스의 키가 각각 다르다)