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

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

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

• Extended ER모델(슈퍼/서브타입)이라 부르는 슈퍼/서브타입 데이터 모델은 최근에 데이터 모델링을 할 때 자주 쓰이는 모델링 방법
  • 업무를 구성하는 데이터의 특징을 공통과 차이점의 특징을 고려하여 효과적으로 표현할 수 있기 때문
  • 즉, 공통의 부분은 슈퍼타입으로 모델링하고 공통으로부터 상속받아 다른 엔티티와 차이가 있는 속성에 대해서는 별도의 서브엔티티로 구분하여 업무의 모습을 정확하게 표현하면서 물리적인 데이터 모델로 변환을 할 때 선택의 폭을 넓힐 수 있는 장점이 있다.

 

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

• 슈퍼/서브타입에 대한 변환을 잘못하여 성능이 저하되는 이유
  • 트랜잭션 특성을 고려하지 않고 테이블이 설계되었기 때문
  • 경우의 수로 정리
    1. 트랜잭션은 항상 일괄로 처리하는데 테이블은 개별로 유지되어 Union연산에 의해 성능이 저하될 수 있다.
    2. 트랜잭션은 항상 서브타입 개별로 처리하는데 테이블은 하나로 통합되어 있어 불필요하게 많은 양의 데이터가 집약되어 있어 성능이 저하되는 경우가 있다.
    3. 트랜잭션은 항상 슈퍼+서브 타입을 공통으로 처리하는데, 개별로 유지되어 있거나 하나의 테이블로 집약되어 있어 성능이 저하되는 경우가 있다.

 

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

1. 개별로 발생되는 트랜잭션에 대해서는 개별 테이블로 구성
   • 당사자유형(이해관계인, 매수인, 대리인) 화면에서 사용자 명 조회 시 개별정보 조회 
     • 이 개별정보(서브타입)가 당사자 정보(슈퍼타입)에 영향을 미치지 않기 때문에 당사자유형 마다 테이블 생성
2. 슈퍼타입+서브타입에 대해 발생되는 트랜잭션에 대해서는 슈퍼타입+서브타입 테이블로 구성
   • 당사자란 공통적인 필드를 관리하는 테이블을 생성하고, 당사자유형(이해관계인, 대리인, 매수인) 테이블을 별도 생성
3. 전체를 하나로 묶어 트랜잭션이 발생할 때는 하나의 테이블로 구성
   • 하나의 테이블에 당사자유형을 컬럼으로두어 관리하는 방법

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

 

 

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

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

• 복합식별자 일 때 PK순서의 중요성
  
  • PK 순서를 잘못 지정하여 생성될 때 Join 시 성능 저하 발생
  • 일반 where 조건절 도 동일

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

• 주문번호순번 + 주문번호 PK
  • 조인 걸때 주문번호로 조인 조건을 내걸 경우 PK Index 사용 못함

 

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

• "나" 주제와 유사함

 

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

• 거래일자 Between에 사무소코드를 비교로 사용되는 쿼리에서
  • PK : 거래일자+사무소코드+출급기번호+명세표번호 (AS-IS)
  • PK : 사무소코드+거래일자+출급기번호+명세표번호 (TO-BE)
• 선행 조건이 Between이긴 하지만 Between에 걸리는 범위가 넓으면 넓을수록 성능이 느려..
  • 실제 DBA 업무를하면서 출고영역 테이블에 일자들이 선두로 걸려있어 유사한 경우라고 생각함

 

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

• 조인조건이 FK에 해당할 경우 조인 시 성능을 위해 인덱스 생성
  • 일반 Btree인덱스와 동일한 생성구문과 종류가 같다.