제 5 절 데이터베이스 구조와 성능
1. 슈퍼/서브타입 모델의 성능고려 방법
 가. 슈퍼/서브타입 데이터 모델(Extended ER Model)의 개요
  - 최근 가장 많이 쓰임
  이유) 업무를 구성하는 데이터를 공통과 차이점을 특징을 고려하여 효과적으로 표현할 수 있기 때문
  - 공통의 부분 -> 슈퍼타입
     공통으로부터 상속받아 다른 엔티티와 차이가 있는 속성 -> 서브타입
  - 논리적 데이터 모델에서 이용되는 형태이며,  분석단계에서 많이 쓰이는 모델
  - 물리적 데이터 모델로 설계시의 문제점이 나타남
   이유) 적당한 노하우가 없음
   결과) 1:1 타입이 되거나  All in one 타입이 되어버림 -> 성능저하

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


   - 성능저하의 원인 3가지
   1) 트랜젝션은 항상 일괄로 처리하는데 테이블은 개별로 유지되어 Union 연산에 의해 성능이 저하될 수 있다.
   예) 이해관계인/매수인/대리인
   2) 트랜젝션은 항상 서브타입 개별로 처리하는데 테이블은 하나로 통합되어 있어 불필요하게 많은 양의 데이터가 집약되어 있어 성능이 저하되는 경우 
   예) 도서정보 -> 일반도서 테이블의 전자책정보
   3) 트랜젝션은 항상 슈퍼+서브 타입을 공통으로 처리하는데 개별로 유지되어 있거나 하나의 테이블로 집약되어 있어 성능이 저하되는 경우
   예) 이해관계인/매수인/대리인

  - 슈퍼/서브 타입의 변환 기준?
  : 데이터의 양과 해당 테이블에 발생되는 트랜젝션의 유형
   1) 데이터가 소량 : 데이터 처리의 유연성을 고려하여 가급적 1:1 관계를 유지하는 것이 좋음
   2) 데이터가 대량 : 3가지의 변화방법이 있음 -> 다음 설명

 다. 슈퍼/서브 타입의 데이터 모델의 변환 기술
   1) 개별로 발생되는 트랜젝션에 대해서는 개별 테이블로 구성 (One To One)
    : 업무적으로 발생되는 트랜젝션이 슈퍼타입과 서브타입 각각에 대해 발생하는 것

   -> '조회' 버튼을 기준으로 각각의 트랜젝션이 분리되어 실행됨

   2) 슈퍼타입+버스타입에 대해 발생되는 트랜젝션에 대해서는 슈퍼+서브타입 테이블로 구성 ( Plus Type)
    예) 1천 10만건 vs 10만건 ?
    대리인(10만건), {매수인(500만건), 이해관계인(500만건)}

3) 전체를 하나로 묶어 트랜젝션이 발생할 때는 하나의 테이블로 구성
    예) 대리인, 매수인, 이해관계인 -> 항상 통합하여 처리한다면? (한 페이지에 나타난다면? )
    -> Union ALL과 같은 SQL구문이 성능을 저하시킬 수 있다.
 
 라. 슈퍼/서브타입 데이터 모델의 변환타입 비교
 


2. 인덱스 특성을 고려한 PK/FK 데이터베이스 성능향상
  가. PK/FK 컬럼 순서와 성능개요
   - 인덱스의 중요성
     : 데이터를 조작할 때 가장 효과적으로 처리죌 수 있도록 접근경로를 제공하는 오브젝트
   - PK/FK 설계의 중요성
     : 데이터에 접근할 때 접근 경로를 제공한다는 측면에서 중요함. 프로젝트시 설계단계 말에 컬럼의 순서를 조정하는 것이 필요하다
 

   - PK 순서의 중요성
    : 물리적인 데이터 모델링 단계에서는 스스로 생성된 PK 순서 이외에 다른 엔티티로부터 상속받아 발생되는 PK 순서까지 항상 주의하여 표시되도록 해야 한다.
    참고) PK 순서를 결정하는 기준
            : 인덱스를 효율적으로 이용할 수 있도록 PK를 지정 즉, 여러개의 속성이 하나의 인덱스로 구성되어 있는데 앞쪽에 위치한 속성의 값이 비교자로 있어야 인덱스가 좋은 효율을 나타낼 수 있다. ('=','BETWEEN', '<>' 등등)
 
   - FK의 중요성
     : FK도 데이터를 조회할 때 조인의 경로를 제공하는 역할을 수행하므로 이에 대해 반드시 인덱스를 생성하도록 한다. 조회의 조건도 고려하여!
 
  나. PK컬럼의 순서를 조정하지 않을 때 성능이 저하되는 이유
  

   -> 조회조건에 따라 인덱스를 처리하는 범위가 달라지게 된다
  
  

   만약) 맨 앞에 있는 컬럼이 제외된 상태에서 데이터를 조회할 경우 데이터를 비교하는 범위가 넓어진다 -> 성능저하

  

   - PK의 순서를 인덱스 특징에 맞게 생성하지 않고 자동으로 생성하게 되면 테이블에 접근하는 트랜젝션의 특징이 효율적이지 않은 인데스가 생성되어 있으므로 인덱스의 범위를 넓히거나 풀 스캔(Full Scan)을 유발해서 성능이 저하된다.

  다. PK 순서를 잘못 지정하여 성능이 저하된 경우 - 간단한 오류
   예) 입시마스터 테이블 (200만건, 4학기, 5년보관 / 한학기 평균 2만건)
        수험번호 + 년도 + 학기

       전형과목 실적 테이블
       (상속받은) 수헙번호 + 년도 + 학기 // 전형과목 코드 (PK)
 


  라. PK 순서를 잘못 지정하여 성능이 저하된 경우 - 복잡한 오류
   예) 현금출급기실적 테이블
         거래일자 + 사무코드 + 출급기번호 + 명세표번호
   
   

3. 물리적 테이블에 FK 제약이 걸려있지 않을 경우 인덱스 미생성으로 성능저하
   예) 학사기준(5만건) / 수강신청(500만건) 테이블
       -> 물리적으로는 두 테이블 사이의 FK 참조 무결성 관계가 걸려있지 않다.


  
-> 비록 물리적으로 학사기준과 수강신청이 연결되어 있지 않다고 하더라도 학사기준으로부터 상속받은 FK에 대해 FK 인덱스를 생성함으로써 SQL문장이 조인이 발생할 때 성능저하를 예방할 수 있다.
     


 




 

• SQL 개발자 자격증 (bysql.net 2011년 2차 스터디)
• 작성자: 김수은
  
• 최초작성일: 2011년 09월 08일
• 본문서는 bysql.net 스터디 결과입니다 .본 문서를 인용하실때는 출처를 밝혀주세요. http://www.bysql.net
• 문서의 잘못된 점이나 질문사항은 본 문서에 댓글로 남겨주세요. ^^