1. 1. 슈퍼타입/서브타입 모델의 성능고려 방법
2. 2. 인덱스 특성을 고려한 PK/FK 데이터베이스 성능향상
3. 3. 물리적인 테이블에 FK제약이 걸려있지 않을 경우 인덱스 미생성으로 성능저하

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

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

• 슈퍼/서브타입 모델 업무를 구성하는 데이터의 특징을 공통과 차이점의 특징을 고려하여 효과적으로 표현할 수 있으므로, 자주 쓰이는 모델링의 방법이다.
• 이 모델은 논리데이터 모델에서 이용되는 형태이고, 물리적인 데이터 모델을 설계하는 단계에서는 일정한 기준에 의해 변환을 해야 한다.
• 아무런 기준없이 막연히 변환하는 것 자체가 성능 저하의 위험이 있다.

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

• 슈퍼/서브타입에 대한 변환을 잘못하면 성능이 저하되는 이유는 트랜잭션 특성을 고려하지 않고 테이블이 설계되었기 때문이다.

• 1) 트랜잭션은 항상 일괄로 처리하는데 테이블은 개별로 유지되어 Union연산에 의해 성능저하
• 2) 트랜잭션은 항상 서브타입 개별로 처리하는데 테이블은 하나로 통합되어 있어 불필요하게 많은 양의 데이터가 집약되어 성능저하
• 3) 트랜잭션은 항상 슈퍼+서브 타입을 공통으로 처리하는데 개별로 유지되어 있거나 하나의 테이블로 집약되어 있어 성능이 저하

• 데이터의 양이 소량일 경우 처리의 유연성을 고려해 1:1관계를 유지하는것이 바람직. 대용량일 경우는 트랜잭션의 발생형태에 따라 3가지 변환방법을 참조하여 상황에 맞게 변환하도록 해야 한다.

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

• 1) 개별로 발생되는 트랜잭션에 대해서는 개별 테이블로 구성
• 2) 슈퍼타입+서브타입에 대해 발생되는 트랜잭션에 대해서는 슈퍼타입+서브타입 테이블로 구성
• 3) 전체를 하나로 묶어 트랜잭션이 발생할 때는 하나의 테이블로 구성

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

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

가.PK/FK 칼럼 순서와 성능개요

• 인덱스는 데이터를 접근할 때 경로를 제공하는 성능 측면에도 중요한 의미를 가지고 있기 때문에 설계단계 말에 컬럼의 순서를 조정할 필요가 있다.
• PK가 복합식별자인 경우, 앞쪽에 위치한 속성이 가급적 '=' 이거나 최소범위 'BETWEEN' '<>'가 들어와야 인덱스를 이용할 수 있다.
• 또한 FK라 하더라도, 인댁스를 생성하도록하고, 인덱스 컬럼의 순서도 조회조건을 고려하여 접근이 가장 효율적인 순서대로 생성한다.

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

데이터모델링에서 설계된 테이블의 PK순서대로 인덱스가 만들어진 경우

• 테이블에 접근하는 트랜잭션의 특징에 효율적이지 않은 인덱스가 생성되었으므로, 인덱스 범위를 넓게 이용하거나 Full Scan을 유발하게 된다.

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

• 입시마스터 테이블의 PK : 수험번호+년도+학기
• 입시마스터 테이블을 조회할 때 조회조건에 수험번호가 들어오지 않아 FULL TABLE SCAN이 발생됨
• 년도와 학기에 대한 내용이 빈번하게 들어오므로 PK순서를 변경함으로써 인덱스를 정상적으로 이용할 수 있게 한다.

라.PK순서를 잘못 지정하여 성능이 저하된 경우 - 복잡한 오류

• 현금출급기실적의 PK는 거래일자+사무소코드+출급기번호+명세표번호로 구성
• 대부분의 SQL문장은 거래일자가 BETWEEN으로 들어오고 사무소코드가 '='로 들어와서 인덱스를 이용할 수 있으나 효율성이 떨어짐
• 인덱스 컬럼을 사무소코드+거래일자+출급기번호+명세표번호로 변경
• 테이블의 PK속성이 A+B와 B+A의 형태로도 빈번하게 조회되는 경우, 더 자주이용되는 형태로 PK순서를 구성하고, 순서를 바꾼 인덱스를 추가로 생성하는 것이 필요

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

• 두 테이블사이에 FK참조 무결성 관계가 걸려있지 않더라도, 데이터 모델관계에 의해 상속받은 FK속성들은 조인조건으로 이용하는 경우가 많으므로, FK인덱스를 생성하는 것을 기본정책으로 하는 것이 좋다.
• FK인덱스 생성을 기본정책으로 하되 향후 트랜잭션에 의해 거의 활용되지 않았을 때만 지우는 것이 적절한 방법이 된다.