2-5 데이터베이스 구조와 성능

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

Extended ER모델(슈퍼/서브타입 데이터 모델): 공통의 부분을 슈퍼타입으로 모델링하고 별도는 서브엔터티로 표현

- 최근에 자주 쓰이는 모델링 방법

- 업무를 구성하는 데이터의 특징을 공통과 차이점의 특징을 고려하여 효과적으로 표현 가능

- 물리적인 데이터 모델로 변환을 할 때 선택의 폭을 넓힐 수 있는 장점

- 논리적인 데이터 모델에 이용

- 분석 단계에서 많이 사용

 

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

- 1:1 타입

- 슈퍼+서브 타입

- All in One 타입

 

-> 데이터의 양과 트랜잭션의 유형에 따라 테이블을 설계하지 않으면 슈퍼/서브 타입 변환 잘못하면 성능 저하된다.

 

- 트랜잭션은 일괄 처리지만 테이블은 개별로 유지되어 Union 연산에 의해 성능 저하

- 트랜잭션은 항상 서브타입 개별로 처리하는데 테이블은 하나로 통합되어 있어 불필요하게 많은 양의 데이터가 집약되어 성능 저하

- 항상 슈퍼+서브 타입을 공통으로 처리하는데 개별로 유지되어 있거나 하나의 테이블로 집약되어 있어 성능 저하

 

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

 

1) 개별로 발생되는 트랜잭션에 대해서는 개별 테이블로 구성

- 슈퍼타입이 각 서브타입에 대해 기준역할을 하는 형식으로 사용할 때 이러한 유형의 트랜잭션이 발생

-> 분리하여 1:1 관계를 갖게 한다.

 

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

- 슈퍼타입과 서브타입을 묶어 트랜잭션이 발생하는 업무는 슈퍼타입+각서브타입을 하나로 묶어 별도의 테이블로 구성하는 것이 효과적

 

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

- 슈퍼타입과 서브타입의 테이블들을 하나로 묶었을 때 각각의 속성별로 제약사항(NULL/NOT NULL, 기본값, 체크값)을 정확하게 지정 못해도 대용량이고 성능향상이 필요하면 하나의 테이블로 묶어서 만들어 준다.

- 혼합된 트랜잭션 유형이 있는 경우는 많이 발생하는 트랜잭션 유형에 따라 구성하면 된다.

-> OneToOne Type(개별 테이블로 접근이 많은 경우), Plus Type(슈퍼+서브 형식으로 데이터를 처리하는 경우), Single Type(전체를 일괄적으로 처리하는 경우)

 

2. 인덱스 특성을 고려한 PK/FK 데이터베이스 성능향상

인덱스

- 데이터 조회 시 가장 효과적으로 처리될 수 있도록 접근 경로 제공하는 오브젝트

- B*Tree 구조 많이 사용

 

실전 프로젝트에서 아주 중요한 내용이 바로 PK 순서

PK는 해당 테이블의 데이터를 접근할 가장 빈번하게 사용되는 유일의 인덱스를 모두 자동 생성

또한 FK라고 해도 데이터 조회 시, 조인의 경로를 제공하는 역할을 수행하므로 FK에 대해서도 반드시 인덱스 생성하고

생성 순서도 조회의 조건을 고려하여 접근이 가장 효율적인 칼럼 순서대로 인덱스 생성

 

PK순서 잘못 지정하면 성능 저하(참조 - 1. PK 컬럼 순서, 대충하지 말자 (tistory.com))

 

3. 물리적인 테이블에 FK제약이 걸려있지 않을 경우 인덱스 미생성으로 성능저하

- FK 인덱스를 생성해야 성능이 좋은 경우가 빈번

 

ex) 학사기준과 수강신청에 대한 데이터 모델(두 테이블 사이에 FK 참조 무결성 관계 x)

학사기준(년도, 학기, 특이사항) 데이터 5만 건, 수강신청(학사기준번호(FK) ``` ) 데이터 500만 건 -> FK 인덱스 미생성으로 FULL TABLE SCAN 발생하여 성능저하

-> FK 인덱스 생성으로 INDEX SCAN 발생하여 성능 향상 가능