서브타입 모델의 물리모델 변환-슈퍼타입서브타입 개별생성

세번째 방법 슈퍼타입·서브타입을 각각 개별 엔터티로 만드는 것

슈퍼타입 엔터티와 서브타입 엔터티가 일대일 관계로 실무에서 주로 사용하는 일반적인 모델

슈퍼타입 서브타입을 각각 개별 엔터티로 설계한 물리 모델

슈퍼타입 ·서브타입 논리 모델을 물리 엔터티로 설계하는 것이다.

서브타입인 정규직사원 ·계약직사원 엔터티의 주식별자는 슈퍼타입인 사원 엔터티의 주식별자인 사원번호를 상속

받으며, 관계는 일대일이 된다.

서브타입을 구분하는 사원유형코드 속성은 받드시 존재해야한다.

슈퍼타입 ·서브타입 모델 선택기준

-업무 연관성이 있을때

서브타입이 업무적으로 강결합관계일때

서브타입을 동시에 조회는 요건이 많을때

-주요 엔터티일때 

 슈퍼타입과 서브타입을 도출했다는 것은  해당 엔터티가 중요하게 사용된다는 것을 의미

주요엔터티에 사용되는 다양한 조회를 만족하기 위해서는 공토속성과 고유속성이 구분된 모델이 효과적이다.

주요엔터티는 변경이 빈번하여 확장하기 좋은 모델이어야 한다.

-공통속성을 주로 사용할 때

서브타입별 공통속서을 대상으로 하는 업무가 많을때 

서브타입별 고유속성은 특별할 때 사용하고, 대부분 공통속성으로 업무가 이뤄질때 

업무에서 빈번하게 사용된다는 것/ 자주 조회된다는 것/ 범위조건으로 조회될 가능성이 크다는 것 : 한블록에 많은 인스턴스를 저장해야 조회성능이 향상될수 있음

성능문제를 일으키는 속성은 공통속성이 아니더라도 슈퍼타입 엔터티에서 관리할 수도 있음(널값이 발생하고, 속성의미가 희석되는 단점이 있지만..)

-고유속성이 많을때

서브타입별 고유속성이 많다는 것은 서브타입간의 데이터 성격이 다소 다르다는 것

슈퍼타입의 공통속성을 사용하는 공통업무와 서브타입의 고유속성을 사용하는 고유업무가 다양하게 존재할때 이 모델이  좋다.

-속성이 빈번하게 추가될때

업무변화가 심해서 속성이 자주 추가될때

슈퍼타입 엔터티에 추가하면 실익도 없으며 애플리케이션에 더 큰영향을 미칠 수 있음

-트랜잭션을 분리할 때

데이터의 트랜잭션 처리를 원활하게 하려고 엔터티를 분리하는 경우도 있다.

사원 엔터티를 사용할때 정규직사원 엔터티도 별도 트랜잭션으로 사용해야 할 때가 있음. 서루에게 영향을 끼치지 않고 빨리 처리될수 있도록 엔터티를 분리하는 것이 좋다.

-통합하면 속성 개수가 많아질때

서브타입 엔터티를 통합 했을때 속성개수가 너무 많아지면 모델의 사용을 고려할 수 있다.

 

장점

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

논리모델과 유사한 구조이기 때문에 모델에 업무규칙이 표현되므로 모델의 가독성이 높아진다.

추가 업무로 생기는 애플리케이션의 변경  영향을 줄수 있다. 변경요건이 사원 계약직사원 정규직사원 엔터티로 분산되며, 슈퍼타입인 사원 엔터티에 속성이 추가되지 않도록 관리할 수 있다.

집계나  DW 요건을 만족할 가능성이 커진다

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

 

단점

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

여러엔터티로 나뉘어 엔터티 개수가 늘어나며 관리가 어려워진다.

배타 중복 완전 불완전 서브타입의 종류에 따라 인스턴스를 발생시킬 때 혼선이 발생할 수 있다.

 

슈퍼타입과 서브타입의 설계의도를 가장 잘 반영한 모델이여서, 물리모델도 그와 유사하게 생성하면 업무규칙이 잘 반영돼 커뮤니케이션을 원활하게 하는데 도움을 준다.