서브타입 분할

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


서브타입 분할 방법


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

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


서브타입 모델


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

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


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

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


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

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


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

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