슈퍼타입&서브타입 물리모델 변환

슈퍼타입 ·서브타입 논리 모델을 물리모델로 변환하는 방법

첫번째 서브타입별로 엔터티 분할

두번째 슈퍼타입 엔터티 하나로 통합

세번째 엔터티와 개별 서브타입 엔터티로 분할

 

첫번째 서브타입별로 엔터티 분할 : 서브타입마다 별도의 엔터티로 만드는 것

서브타입별로 엔터티를 각자 생성한 후에 슈퍼타입의 주 식별자를 포함한 속성 전부를 양쪽 엔터티에 추가

 

두번째 슈퍼타입  엔터티 하나로 통합 : 각 서브타입에 속하는 속성을 슈퍼타입에 포함시키고 서브타입을 삭제해 슈퍼타입만 남긴다.

세번째 슈퍼타입 엔터티와 개별 서브타입 엔터티로 분할 : 슈퍼타입과 개별 서브타입 별로의 엔터티로 분할 하는 방법

슈퍼타입 서브타입 논리모델 구조가 그대로 물리모델로 변환된다, 즉 서브타입 개념을 가장 잘 반영한 물리 모델이다.

 

슈퍼타입 서브타입 논리모델 --> 물리모델 변환 시 고려사항

조회에 대한 사용 결합도 즉 조회성능을 의미

- 서브타입을 독립적으로 조회하는지 공통 속성에 대해서만 조회하는지 , 슈퍼타입과 서브타입 전체는 조회하는지. 중요 조회에 대한 횟수는 어떤지 등 고려해야 함

- 조회 시 서브타입 전체를 대상으로 이루어 지는데  같이 서브타입별로 엔터티를 분리 했을 때  union 등 발생하므로 성능저하 될 것

-서브타입별로만 조회하는데 서브타입을 하나의 엔터티로 통합했다면 많은 양의 데이터로 인해 성능저하 발생가능

-슈퍼타입과 서브타입에 속한 속성을 대부분 한번에 조회하는데 슈퍼타입과 서브타입을 분할 하는 것은 조인 부담이 생길것

 

관리측면도 고려

-서브타입이 지속적으로 늘어날때 엔터티별로 분리하면 모델을  확장하기 좋지 않음.관리 효율성이 떨어짐

-슈퍼타입 엔터티 하나로 통합 시 속성이 많이 추가 되기 때문에 관리 효율성이 떨어짐

-슈퍼타입과 개별서브타입 모델은 관리 효율성은 좋다. 서브타입 늘어나도  슈퍼타입 엔터티에 거의 변화가 없기때문에

 

사용결합도에 따른 조회 성능과 관리측면을 고려하여 설계하야 하고, 통합 관점에서도 고려해야 함.

타입	선택기준
서브입별로 분할	-       서브타입별 업무가 서로 독립적일 때 -       서브타입별 속성이 많이 다를 때 -       서브타입별 관계가 많이 다를 때 -       모든 서브타입을 동시에 조회하는 경우가 드물 때 -       서브타입별 주 식별자가 상호 배타적이 아닐 때 -       서브타입이 업무적으로 서로 약 결합관계일 때
슈퍼타입 하나로 통합	-       서브타입별 고유 속성이 적을 때 -       속성이 지속적으로 늘어날 가능성이 작을 때 -       하나의 서브타입은 속성도 많고 업무도 중요하며, 나머지 서브타입은 속성이 적고 덜 중요할 때 -       서브타입 전체를 대상으로 하는 업무가 빈번할 때 -       데이터 건수가 많지 않을 때 -       업무가 중요하지 않을 때 -       서브타입이 중복 서브타입일 때 -       서브타입이 업무적으로 서로 강 결합 관계일 때
슈퍼타입-서브타입으로 구분	-       서브타입별 공통 속성을 대상으로 하는 업무가 빈번할 때 -       통합 하면 속성 개수가 너무 많아질 때 -       업무의 변화가 빈번해 속성이 자주 추가 될 때 -       서브타입별 고유 속성이 많을 때 -       트랜잭션의 락을 방지하기 위해 엔터티를 분리해야 할 때 -       공통업무와 고유업무가 다양하게 존재할 때 -       중요속성과 참고속성으로 분리될 수 있을 떄 -       슈퍼타입의 조회가 빈번하고 조회범위가 넣을 때 -       서브타입이 업무적으로 서로 강 결합 관계일 때