데이터베이스 구조와 성능

1. 슈퍼 타입 / 서브 타입 모델

 

1) 업무를 구성 하는 데이터 특징을 분석.

공통점 / 차이점 을 고려 하여 효과적으로 표현함.

 

2) 공통의 부분을 슈퍼 타입 엔터티 으로 모델링 함.

공통의 것으로 부터 상속 받아, 다른 엔터티와 차이가 있는 속성은 별도의 서브 타입 엔터티로 구분 함.

 

3) 업무의 모습을 정확 하게 표현 하고, 물리적인 데이터 모델로 변환 하면,

선택의 폭을 넓힐 수 있는 장점이 있음.

 

 

만약에, 고객 이라는 테이블이 있다고 할 때,

 

이 고객은 개인 / 법인 고객이 있다.

 

이럴 때, 고객 테이블은 한개지만, 개인 고객과 법인 고객 두개로 나누어 테이블을 구성 하는 것을 서브 타입 이라고 한다.

 

 

 

2. 슈퍼 타입 / 서브 타입 모델 변환 방법

 

1) 슈퍼 타입 (Single Type / All in One Type) 기준

 

- 슈퍼 / 서브 타입 모델을 하나의 테이블로 변환.

예) 고객 테이블 하나로만 구성.

 

2) 서브 타입 (Plus Type / Super + Sub Type) 기준

 

- 슈퍼 / 서브 타입을 서브 타입 테이블로 변환.

예) 개인 고객 / 법인 고객 테이블 두개로 구성.

 

- 만들어진 각각의 서브 타입 (테이블 == 엔터티) 에는 변환 이전에 슈퍼 타입 (테이블 == 엔터티) 에 있었던,

칼럼들을 공통적으로 지니고 있다.

 

3) 개별 타입 (OneToOne Type / 1 : 1 Type) 기준

 

- 슈퍼 / 서브 타입을 슈퍼 / 서브 타입 각각의 개별 테이블로 변환.

예) 고객 / 개인 고객 / 법인 고객 테이블 세개로 구성.

 

즉, 슈퍼 타입 테이블과 서브 타입 테이블 모두를 생성.

 

칼럼들을 서브 타입 기준으로 나눌 때와 다르게, 정말 딱 그 나눈 테이블에 필요한 칼럼들만 갖게 된다.

(공통 칼럼 X)

 

 

 

3. 슈퍼 / 서브 타입 데이터 모델을 변환 하는 것의 중요성

 

1) 트랜잭션은 항상 슈퍼 타입을 기준으로 처리 함.

 

항상 고객 전체의 전체 데이터를 처리 한다.

 

굳이 개인 / 법인 고객 테이블 두개를 조회 해서 UNION 처리 (합집합) 하는것은 너무 번거 롭다.

>> 성능상 저하 될 수 있다.

 

따라서, 슈퍼 타입에 모두 몰아 !

 

 

 

2) 반대로 트랜잭션은 항상 서브 타입을 기준으로 처리 함.

 

개인 고객 또는 법인 고객으로만 트랜잭션이 처리 된다고 하면,

 

즉, 서브 타입을 기준으로 처리 하는 상황 인데,

 

슈퍼 타입 또는 개별 타입으로 되어 있으면 성능이 저하 되므로, 이럴 때는 서브 타입으로 테이블을 분리 한다.

 

 

 

3) 또는, 트랜잭션은 항상 개별 타입을 기준으로 처리 함.

 

 고객 / 개인 고객 / 법인 고객 이렇게 완전 다 개별적으로 트랜잭션이 처리 된다고 할 때,

 

슈퍼 타입으로 트랜잭션이 된다고 하면, 굳이 읽지 않아도 되는 것을 다 읽게 되므로 비효율.

 

이럴 때는 모두 읽으면 성능이 저하 되므로, 개별 타입을 기준으로 트랜잭션 처리를 진행 한다.

 

 

 

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

 

1)

슈퍼 / 서브 타입 (논리) 을 슈퍼 타입 (물리) 으로 변환 !

 

 

그냥 모든걸 하나의 테이블에 몰아 넣어 버린다.

 

그러니까, 슈퍼 / 서브 타입의 데이터를 처리 할 때, 나누는 경우가 없이, 무조건 항상 같이 데이터를 통합적으로 처리 ?

>> 하나의 테이블로 구성 하는게 효율 !

 

개별로 분리 하면 JOIN 또는 UNION ALL 을 해야 하기 때문에 이런 연산 자체가 성능에 부담을 줄 수 있기 때문 이다.

 

따라서 이런 경우는 하나의 테이블로 통합 하여 테이블을 구축 한다.

 

 

 

2)

슈퍼 / 서브 타입 (논리) 을 서브 타입 (물리) 으로 변환 !

 

 

당사자 구분은 이해 관계인 / 대리인 / 매수인 으로 나눠져 있기 때문에,

 

저 각각의 경우를 서브 타입으로 테이블을 나누는 경우.

 

그러니까, 만약에 10만건 에 해당 하는 대리인에 대해 개별로 처리 하는 일이 잦다면 ?

 

굳이 처리가 필요 없는 이해 관계인 (500 만건) / 매수인 (500 만건) 도 같이 처리 해야 한다.

>> 비효율 !

 

그래서, 비효율을 제거 하기 위해, 서브 타입 기준으로 테이블을 나눈다 !

 

 

 

3)

슈퍼 / 서브 타입 (논리) 을 개별 타입 (물리) 으로 변환 !

 

 

특정 업무만 잦거나 하는게 아니라,

 

모든 업무가 다 각각 개별로 발생 하면,

 

당사자 / 이해관계인 / 대리인 / 매수인 모두를 트랜잭션을 독립적으로 발생 하게 하고,

 

얘네를 모두 각 테이블로 나눌 때, 꼭 필요한 칼럼만 갖게 한다.

 

 

 

[ 슈퍼 / 서브 / 개별 타입 데이터 모델 비교 ]

 

 

 

슈퍼 타입이 조인 성능이 우수한 이유 ?

>>  애초에 조인할 필요 자체가 없기 때문 이다.

 

슈퍼 타입이 관리 용이한 이유 ?

>>  하나의 테이블 이기 때문에 !

 

서브 / 개별 타입이 조인 성능이 나쁜 이유 ?

>>  테이블이 나눠졌으니, 조인을 해야 하므로.

 

서브 / 개별 타입이 관리가 용이 하지 않은 이유 ?

>> 테이블이 여러개 이기 때문에 !

 

 

 

5. PK / FK 칼럼 순서와 성능

 

1) 테이블에 발생 되는 트랜잭션 조회 패턴에 따라 PK / FK 칼럼의 순서를 조정 해야 한다.

 

2) 성능 저하 현상은 보통 PK 가 여러 개의 속성으로 구성된 복합 식별자 일 때 발생 된다.

이는, PK 순서에 대해 고려 하지 않고 데이터를 모델링 했을 때 해당 된다.

 

3) 물리적인 데이터 모델링 단계일 때,

디폴트로 생성된 PK 순서 이외에, 다른 엔터티로부터 상속 받아 발생 되는 PK 순서까지 항상 주의 해서 표시 해야 한다.

 

4) PK 가 복합키 인 경우, 칼럼 순서가 성능에 영향을 미치는 이유 ?

 

- 인덱스 선두 칼럼에 대한 조건이 들어와야 한다. 가능한 ' = ' 조건으로 들어와야 한다.

 

- 인덱스 선두 칼럼에 대한 조건이 없으면, 인덱스 전체를 읽거나 테이블 전체를 읽게 되서, 성능 저하 현상이 발생 된다.

 

예시 01)

 

 

입시 마스터 테이블에 수험번호 PK를 맨 앞에 놓았을 때,

쿼리문의 WHERE 절 조건에 수험 번호가 없으므로,

일단.. 모든 데이터를 다 읽고, WHERE 조건을 보게 된다.

 

근데 아래의 테이블을 보면, PK가 년도, 학기 수험번호 순으로 되어 있고,

WHERE 절 조건에 년도, 학기 조건이 있으므로,

해당 조건을 우선적으로 보면서 들어 오기 때문에, 모든 데이터를 조회 하지 않고,

조건에 맞는 데이터만 읽으면서 조회 하게 되므로, 성능이 향상 된다.

 

예시 02) 

 

가급적 ' = ' 조건이 테이블의 PK 자리에 선행 되는게 좋다.

 

딱 그 조건에 맞는 데이터만 먼저 뽑아 내서 조회 하기 때문에 성능이 향상 될 수 밖에 없다.

 

막, BETWEEN 조건이나 이런걸 맨 앞에 놓으면, A AND B 이므로, 인덱스 스캔은 되지만, 최적화 되진 않는다.

 

 

 

 

[ 정리 ]

 

정리하자면, 복합 PK 인 상황에 PK 의 순서가 최적화 및 성능에 영향을 미칠 수 있다는 것이다.