-
슈퍼타입/서브타입
모델의
성능고려
방법
가. 슈퍼/서브타입
데이터
모델의
개요
- Extended ER모델이라고
부르는
슈퍼/서브타입
데이터
모델은
최근에
데이터
모델링을
할
때
자주
쓰이는
모델링
방법 - 자주
쓰이는
이유는
업무를
구성하는
데이터의
특징을
공통과
차이점의
특징을
고려하여
효과적으로
표현할
수
있기
때문 - 공통의
부분을
슈퍼타입으로
모델링하고
공통으로부터
상속받아
다른
엔티티와
차이가
있는
속성에
대해서는
별도의
서브엔티티로
구분하여
업무의
모습을
정확하게
표현하면서
물리적인
데이터
모델로
변환을
할
때
선택의
폭을
넓힐
수
있는
장점이
있음. - 슈퍼/서브타입의
경우
논리적인
데이터
모델에서
이용되는
형태이고, 분석단계에서
많이
쓰이는
모델이다. 따라서
물리적인
데이터
모델을
설계하는
단계에서는
슈퍼/서브타입
데이터
모델을
일정한
기준에
의해
변환해야
한다. -
변환하는
과정에서
막연하게 1:1로
변환하거나
아니면
하나의
테이블로
구성해
버리는
경우
성능이
저하되는
경우가
생길
수
있다.
나. 슈퍼/서브타입
데이터
모델의
변환
- 트랜잭션은
항상
일괄로
처리하는데
테이블은
개별로
유지되어 Union연산에
의해
성능이
저하될
수
있다.
- 트랜잭션은
항상
서브타입
개별로
처리하는데
테이블은
하나로
통합되어
있어
불필요하게
많은
양의
데이터가
집약되어
있어
성능이
저하되는
경우가
있다.
- 트랜잭션은
항상
슈퍼+서브
타입을
공통으로
처리하는데
개별로
유지되어
있거나
하나의
테이블로
집약되어
있어
성능이
저하되는
경우가
있다.
-
해당
테이블에
발생되는
성능이
중요한
트랜잭션이
빈번하게
처리되는
기준에
따라
테이블을
설계해야
이러한
성능저하
현상을
예방할
수
있음을
기억해야
한다.
다. 슈퍼/서브
타입
데이터
모델의
변환기술
- 개별로
발생되는
트랜잭션에
대해서는
개별
테이블로
구성
- 슈퍼타입+서브타입에
대해
발생되는
트랜잭션에
대해서는
슈퍼타입+서브타입
테이블로
구성
- 전체를
하나로
묶어
트랜잭션이
발생할
때는
하나의
테이블로
구성
라. 슈퍼/서브타입
데이터
모델의
변환타입
비교
-
인덱스
특성을
고려한 PK/FK 데이터베이스
성능향상
가. PK/FK 컬럼
순서와
성능개요
- 데이터를
조회할
때
가장
효과적으로
처리될
수
있도록
접근경로를
제공하는
오브젝트가
바로
인덱스이다 -
일반적으로
데이터베이스
테이블에서는 B*Tree구조를
많이
사용한다.
- 성능저하
현상이
많은
부분이 PK가
여러
개의
속성으로
구성된
복합식별자
일
때 PK순서에
대해
별로
고려하지
않고
데이터
모델링을
한
경우에
해당된다. - 스스로
생성된 PK순서
이외에
다른
엔티티로부터
상속받아
발생되는 PK순서까지
항상
주의하여
표시하도록
해야함 - PK는
해당
테이블의
데이터를
접근할
가장
빈번하게
사용되는
유일한
인덱스(Unique Index)를
모두
자동
생성한다. - 여러
개의
속성이
하나의
인덱스로
구성되어
있을
때
앞쪽에
위치한
속성의
값이
비교자로
있어야
인덱스가
좋은
효율을
나타낼
수
있다. - 앞쪽에
위치한
속성값이
가급적 ‘=’ 아니면
최소한
범위 ‘BETWEEN’ ‘<>’가
들어와야
인덱스를
이용할
수
있다. -
FK는
데이터를
조회할
때
조인의
경로를
제공하는
역할을
수행하므로 FK에
대해서는
반드시
인덱스를
생성하도록
하고
인덱스
컬럼의
순서도
조회의
조건을
고려하여
접근이
가장
효율적인
컬럼
순서대로
인덱스를
생성하도록
한다.
나. PK컬럼의
순서를
조정하지
않으면
성능이
저하되는
이유
-
PK의
순서를
인덱스
특징에
맞게
고려하지
않고
바로
그대로
생성하게
되면, 테이블에
접근하는
트랜잭션의
특징에
효율적이지
않은
인덱스가
생성되어
있으므로
인덱스의
범위를
넓게
이용하거나 Full Scan을
유발하게
되어
성능이
저하된다.
다. PK순서를
잘못
지정하여
성능이
저하된
경우 – 간단한
오류
-
위
내용과
같이
빈번하게 where절에
들어오는
컬럼
순서로 PK 순서를
정해주는
것이
좋다.
라. PK순서를
잘못
지정하여
성능이
저하된
경우 – 복잡한
오류
-
Where 조건절의
경우
사무소코드는 ‘=’로
들어오고
거래일자에
대해서는 ‘BETWWEN’ 조회를
하고
있다. 이때 SQL은
정상적으로
인덱스를
이용할
수
있지만
인덱스
효율이
떨어져
성능이
저하되는
경우에
해당된다.
- 범위조회에
따른
성능저하
및
성능향상이
발생될
수
있기
때문에 PK의
순서는
중요하다. - 인덱스순서를
고려하여 PK순서를
거래일자+사무소코드+출급기번호+명세표번호
에서 - 사무소코드+거래일자+출급기번호+명세표번호로
수정하여
성능을
개선할
수
있다.
- 물리적인
테이블에 FK제약이
걸려있지
않을
경우
인덱스
미생성으로
성능저하
-
물리적인
테이블에 FK를
사용하지
않아도
데이터
모델
관계에
의해
상속받은 FK속성들은 SQL WHERE 절에서
조인으로
이용되는
경우가
많이
있으므로 FK 인덱스를
생성해야
성능이
좋은
경우가
빈번하다.
- 학사기준번호가 WHERE 절에
오진
않았지만, 학사기준과
수강신청의
조인으로
인하여 Full Table Scan이
발생 -
아래와
같이 FK에
인덱스를
생성해줌으로서
성능향상을
기대할
수
있음
