[SQLD : Ⅱ. 데이터 모델과 성능] 5-1. 데이터베이스 구조와 성능 - 슈퍼타입/서브타입 모델

* 슈퍼타입/서브타입 모델의 성능 고려 방법

 - 슈퍼/서브타입 데이터 모델 : Extended ER 이라고 부름, 논리 데이터 모델에서 이용되는 형태

    공통의 부분을 슈퍼타입으로 모델링하고

    공통으로부터 상속받아 다른 엔티티와 차이가 있는 속성에 대해 별도의 서브 엔티티로 구분하여 표현

    물리적 데이터 모델 변환 시 선택의 폭을 넓힐 수 있음

 - 물리 데이터 모델을 설계하는 단계에서는 슈퍼/서브타입 데이터 모델을 일정한 기준으로 변환해야 함

   막연하게 아무 기준 없이 변환하면 성능 저하 위험 있음

 

* 슈퍼/서브타입 데이터 모델 변환 

  변환을 잘못하면 트랜잭션 특성을 고려하지 않고 테이블이 설계되어 성능이 저하 됨

   1) 트랜잭션은 항상 일괄로 처리하는데 테이블은 별개로 유지되어 UNION연산에 의해 성능 저하

   2) 트랜잭션은 서브타입 개별로 처리하는데 테이블은 하나로 통합되어 불필요한 많은 데이터가 집약되어 성능 저하

   3) 트랜잭션은 슈퍼+서브 타입을 공통으로 처리하는데 개별로 유지되어 있거나 하나의 테이블로 집약되어 성능 저하

  슈퍼/서브타입을 성능을 고려한 물리적 데이터 모델로 변환하는 기줄은 데이터의 양과 트랜잭션의 유형

  데이터량이 소량일 경우 데이터처리 유연성을 고려하여 1:1관계 유지

 

* 슈퍼/서브 타입 데이터 모델의 변환 기술

 1) 개별로 발생되는 트랜잭션은 개별 테이블로 구성

   공통으로 처리하는 슈퍼타입테이블인 당사자 정보를 미리 조회하고 원하는 내용에 따라 서브타입 조회하는 형식 

   독립적으로 트랜잭션 발생 시 슈퍼타입과 서브타입에 꼭 필요한 속성만 갖게 하여 1:1 관계를 갖도록 함

   실제로 슈퍼타입 속성 수가 너무 많아 디스크IO가 많아지는 것을 방지하기 위해 1:1 관계로 가져가는 경우도 있음

 2) 슈퍼타입 + 서브타입에 대해 발생되는 트랜잭션에 대해 슈퍼타입+서브타입 테이블로 구성

   슈퍼타입과 서브타입을 묶어 트랜잭션이 발생하는 업무특징이 있을 때 

   슈퍼타입 + 각 서브타입을 하나로 묶어 별도의 테이블로 구성하는 것이 효율적

 3) 전체를 하나로 묶어 트랜잭션이 발생할 때는 하나의 테이블로 구성

   테이블을 개별로 분리하면 불필요한 조인 유발이나 불필요한 UNION ALL 작성으로 성능 저하

   테이블들을 하나로 묶었을 때 각 속성별로 제약사항을 정확하게 지정 못해도 성능향상이 필요하면 묶어서 만듦

 

* 슈퍼/서브타입 데이터 모델의 변환 타입 비교