데이터베이스 구조와 성능

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

1) 슈퍼/서브타임 모델 개요

• Extended ER 이라고도 부름
• 공통점과 차이점의 특징을 고려하여 엔터티를 분할
• 논리적 데이터 모델에서 고려됨
• 분석단계에서 사용됨
• 성능이 저하될 수도 있음

2) 슈퍼/서브 타임 모델 변환

• 트랙잭션은 일괄로 처리되는데 유니온 연산에 의해 성능이 저하될 수 있음
• 트랜잭션은 서브타입을 개별로 처리하는데 테이블은 하나로 통합되어 있는 경우 성능 저하 가능
• 트랜잭션은 슈퍼 + 서브 타입으로 처리하는데 개별로 유지되는 경우 성능이 저하될 수 있음
• 따라서 트랜잭션 패턴 분석은 필수임
• 가급적 1 : 1 관계가 좋은 것은 사실이나, 용량이 많거나 업무적 특징이 성능에 민감한 경우에는 상황에 맞게 변환

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

• 개별로 발생하는 트랜잭션에 대해 개별 테이블로 구성 (one to one)
  |-- 확장성 우수//조인성능나쁨//I/O 성능 좋음//관리 용이성 나쁨//개별 테이블 접근이 많은 경우 선택
• 슈퍼 + 서브 타입에 대해 발생되는 트랜잭션은 슈퍼 + 서브로 구성한다 (plus type)
  |-- 확장성 보통//조인성능나쁨//I/P 성능 좋음//관리 용이성 나쁨
• 전체를 하나로 묶어 발생할떄는 하나로 묶는다
  |-- 확장성 나쁨//조인성능우수//I/O 성능 나쁨//관리 용이성 좋음// 전체를 일괄로 처리할떄 굳굳

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

1) pk/fk 컬럼 순서와 성능개요

• B* Tree 구조를 사용하는 만큼 이해가 필요 => 컬럼 성능이 중요한 자료구조
• 복합 식별자의 경우 pk 순서에 대해 고려하지 않고 데이터 모델링이 되서 성능저하가 종종 유발
• pk 순서는 인덱스를 가장 효율적으로 쓸 수 있어야함 => 먼저오는 녀석에 비교연산자를 사용할 수 있도록해야함

2) pk/fk에 따라 성능이 저하되는 이유

• 인덱스의 정렬 구조로 인해 데이터에 접근하는 트랜잭션의 특징에 효율적이지 않은 인덱스가 생성되어 인덱스의 범위를 넓게 이용하고 Full Scan 이 발생하기 때문

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

• fk 인덱스를 사용하면 Join 에서 아주 성능이 우수하게 된다
• 하지만 위의 경우 참조 무결성 관계가 결려 있지 않은 경우 Full Scan이 발생할 수 있어서 성능 저하 유발
• 무조건 FK 인덱스를 생성하고, 트랜잭션에 의해 거의 활용되지 않았을 때에만 FK 인덱스를 지우는 방법으로 하는 것이 적절한 방법임