제 5절 데이터 베이스 구조와 성능

 

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

 

가. 슈퍼/서브타입 데이터 모델의 개요

 

EER 모델이라고 부르는 슈퍼/서브 타입 데이터 모델 ->

최근 데이터 모델링을 할 때 자주 쓰이는 모델링 방법

 

데이터의 특징을 공통과 차이점의 특징을 고려하여 효과 적으로 표현

 

공통의 부분을 슈퍼타입으로 모델링하고 공통으로 부터 상속받아 다른 엔터티와 차이가 있는 속성에 대해서는 별도의 서브엔터티로 구분

 

분석단계에서 많이 쓰이는 모델로, 물리적인 데이터모델을 설계하는 다녜에서는 슈퍼/서브 타입 데이터 모델을 일정한 기준에 의해 변화 해야 한다.

 

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

 

성능을 고려한 슈퍼타입과 서브 타입의 모델 변환의 방법

1) 1:1 타입

2) 슈퍼 + 서브 타입

3) All in One 타입

 

슈퍼/서브 타입에 대한 변환을 잘 못하면 성능이 저하 되는 이유 ->

트랜잭션 특성을 고려 하지 않고 설계 되었기 때문

3가지의 경우의수

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

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

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

 즉 데이터 의 양 과 트랜잭션의 유형에 따라 변환해야 한다.

 

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

논리적인 데이터 모델에서 설계한 슈퍼/서브 타입 모델을 물리적인 데이터 모델로 전환할때 어떤 유현의 트랜잭션이 발생하는지 검증 해야 한다. 

시스템을 운영중에 데이터량이 증가하지 않는 다면 전체를 하나의 테이블로 묶어도 좋지만 그렇지 않다면 세심하게 변환 방법을 적용해야 한다.

 

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

  트랜잭션이 슈퍼타입과 서브타입 각각에 대해 발생하는 것

-슈퍼타입에도 꼭 필요한 속성만을 가지게 하고 서브타입 에도 꼭 필요한 속성 및 자신이 타입에 맞는 데이터만 가지게 하기 위해서 분리하여 1:1 관계를 가지도록 한다.

 

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

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

 

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

데이터들을 처리할때 할상 통합하여 처리한다고 하면 테이블을 개별로 분리해야 불필요한 조인을 유발하거나 불필요한 Union All 과 같은  sql 구문이 작성되어 성능이 저하된다. 

구분	1:1 type	plus type	single type
특징	개별테이블 유지	슈퍼+서브타입 테이블	하나의 테이블
확장성	우수함	보통	나쁨
조인성능	나쁨	나쁨	우수함
I/O량 성능	좋음	좋음	좋음
관리용이성	좋지않음	좋지않음	좋음
트랜잭션 유형에 따른 선택방법	개별 테이블로 접근이 많은 경우 선택	슈퍼 + 서브 형식으로 데이터를 처리하는 경우 선택	전체를 일괄적으로 처리하는 경우 선택

 

 

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

 

가. 데이터를 조회할 때 가장 효과적으로 처리 될 수 있도록 접근 경로를 제공하는 오브젝트-> 인덱스

데이터 베이스 테이블 ->> 일반적으로 균형 잡힌 트리구조의 B*Tree 구조

 

PK/FK 칼럼의 순서의 중요성 -> 데이터베이스 데이터 처리 성능에 문제를 유발

---성능저하 현상이 많은 부분이 PK가 여러 개의 속성으로 구성된 복합 식별자인 경우 PK순서에 대해 고려하지 않고 데이터 모델링을 한다.

물리적인 모델링 단계에서는 스스로 생성된 PK순서 이외에 다른 엔터티로부터 상속받아 발생되는 PK순서까지 항상 주의 하여 표시

 

여러개의 속성이 하나의 인덱스로 구성이 되어 있을때 인덱스의 앞쪽에 위치한 속성값이 비교자로 있어야 한다.

FK 또한 데이터를 조회할때 경로를 제공하는 역활을 수행하므로 반드시 인덱스를 생성하도록 하고 조회의 조건을 고려하여 효율적인 칼럼 순서대로 인덱스를 생성하도록 해야 한다.

 

 

나. PK칼럼의 순서를 조정하지 않으면 성능이 저하되는 이유

 

인덱스의 정렬된 첫 칼럼에 비교가 되면 순차적으로 데이터를 찾아 비교 범위가 작아지지만. 첫칼럼을 제외 하면 비교 범위가 매우 넓어 지기 때문에 성능저하를 유발하게 된다.

 

다. PK순서를 잘 못 지정하여 성능이 저하된 경우 = 간단한 오류

 

라. - 복잡한 오류

 

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

 

물리적인 테이블에 FK를 사용하지 않아도 데이터 모델 관계에 의해 상속받은 FK속성들은 SQL WHERE절에서 조인으로 이용되는 경우가 많으므로 FK인덱스를 생성해야 성능이 좋은 경우가 빈번하다.