2장 5절 데이터베이스 구조와 성능

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

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

   - Extended ER 모델이라고 부르는 이른바 슈퍼/서브타입 데이터 모델

   - 최근 데이터 모델링을 할 때 자주 쓰이는 모델링 방법

   - 업무를 구성하는 데이터의 특징을 공통과 차이점의 특징을 고려하여 효과적으로 표현할 수 있기 때문에 자주 쓰임

   - 공통의 부분을 슈퍼타입으로 모델링 하고 공통으로부터 상속받아 다른 엔터티와 차이가 있는 속성에 대해서는 별도의

     서브엔터티로 구분하여 업무의 모습을 정확하게 표현하면서 물리적인 데이터 모델로 변환을 할 때 선택의 폭을 넓힐 수

     있는 장점이 있다.

   - 논리적인 데이터 모델에서 이용되는 형태이고 분석단게에서 많이 쓰이는 모델

   - 물리적인 데이터 모델을 설계시에는 일정한 기준에 의해 변환을 해야함.

   - 아무런 기준없이 변환하는 것 자체가 성능이 저하될 수 있는 위험이 있음.

 

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

   - 성능이 저하되는 이뉴는 트랜잭션 특성을 고려하지 않고 테이블이 설계되었기 때문.

   1) 트랜잭션은 항상 일괄로 처리하는데 테이블은 개별로 유지되어 Union연산에 의해 성능이 저하될 수 있다.

   2) 트랜잭션은 항상 서브타입 개별로 처리하는데 테이블은 하나로 통합되어 있어 불필요하게 많은 양의 데이터가 집약되

      어 있어 성능이 저하되는 경우

   3) 트랜잭션은 항상 슈퍼+서브 타입을 공통으로 처리하는데 개별로 유지되어 있거나 하나의 테이블로 집약되어 있어

      성능이 저하되는 경우가 있다.

 

   - 트랜잭션이 빈번하게 처리되는 기준에 따라 테이블을 설계해야 성능저하 현상을 예방할 수 있다.

   - 물리적인 데이터모델로 변환하는 기준은 데이터 양과 해당 테이블에 발생되는 트랜잭션의 유형에 따라 결정된다.

   - 데이터양이 소량일 경우 1:1관계가 바람직하다

   - 데이터양이 대량일 경우 트랜잭션이 해당 테이블에 어떻게 발생되는지에 다라 3개지 변환방법을 참조하야한다.

 

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

   1) 개별로 발생되는 트랜잭션에 대해서는 개별 테이블로 구성

    - 공통으로 처리하는 슈퍼타입테이블인 당사자 정보를 미리 조회하고 원하는 내용을 클릭하면 거기에 따라서 서브타입

      인 세부적인 정보 즉 이해관계인, 매수인, 대리인에 대한 내용을 조회하는 형식

 

   2) 슈퍼타입+서브타입에 대해 발생되는 트랜잭션에 대해서는 슈퍼타입+서브타입 테이블로 구성

    - 대리인이 10만건, 매수인이 500만건, 이해관계인이 500만건일때, 그 중 대리인에 대한 처리가 개별적으로 많이 발생하

      는대 매수인과 이해관계인의 데이터까지 포함되어 있으므로 최대 10만건을 읽어 처리할 수 있는 업무가 최대 1천10만

      건을 읽어 처리하는 경우가 발생된다.

      이럴경우에는 슈퍼타입+각서브타입을 하나로 묶어 별도의 테이블로 구성하는 것이 효육적이다.

 

   3) 전체를 하나로 묶어 트랜잭션이 발생할 때는 하나의 테이블로 구성

   - 대리인 10만건, 매수은이 500만건, 이해관계인이 500만 건일때, 이를 항상 통합하여 처리한다고 하면 테이블을 하나로

     묶었을 때 각각의 속성별로 제약사항(NULL/NOT NULL, 기본값, 체크값)을 정확하게 지정하지 못할지라도 대용량이고

     성능향상이 필요하다면 하나의 테이블로 묶어서 만들어준다.

 

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

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

 

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

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

   - 간단한것 같지만 실전 프로젝트에서는 아주 중요한 내용이 바로 PK순서이다.

   - 물리적인 데이터 모델링 단계에서는 스스로 생성된 PK순서 이외에 다른 엔터티로부터 상속받아 발생되는 PK순서까지

     항상 주의하여 표시하도록 해야한다.

   - PK순서를 결정하는 기준은 인덱스 정렬구조를 이해한 상태에서 인덱스를 효율적으로 이용할 수 있도록 PK순서를

     지정해야한다.

   - 앞쪽에 위치한 속성값이 가급적 '=' 아니면 최소한 범위 'BETWEEN''<>'가 들어와야 인덱스를 이용할수 있다.

   - FK에 대해서 반드시 인덱스를 생성하도록 하고 인덱스 칼럼의 순서도 조회의 조건을 고려하여 접근이 가장 효율적인

     칼럼 순서대로 인덱스를 생성하도록 주의해야 한다.

 

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

  - 테이블의 주문번호가 가장먼저 정렬되고 그에 따라 주문일자가 정렬이 되고 마지막으로 주문목록코드가 정렬된다.

  - 이러한 정렬구조로 인해 데이터를 접근하는 트랜잭션의 조건에 따라 다른 인덱스 접근방식을 보여준다.

 

  - 인덱스의 정렬된 첫번째 컬럼에 비교가 되면 순차적으로 데이터를 찾아가지만 맨 앞에 컬럼이 제외된 상태에서 데이터

     를 죄회 할 경우 데이터를 비교하는 범위가 매우 넓어지게 되어 성능 저하를 유발하게 된다.

 

  - PK의 순서를 인덱스 특징에 맞게 고려하지 않고 바로 그대로 생성하게 되면, 테이블에 접근하는 트랜잭션의 특징에

    효율적이지 않은 인덱스가 생성되어 있으므로 익덱스의 범위를 넓게 이용하거나 Full Scan을 유발하게 되어 성능이

    저하된다고 정리할 수 있다.

 

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

  - 입시마스터_I01 인덱스가 수험번호 + 년도 + 학기 중 수험번호에 대한 값이 where절에 들어오지 않으므로 full table

    scan이 발생. 성능저하

 

  - 년도와 학기에 대한 내용이 빈번하게 들어오므로 pk순서를 위와같이 변경함으로서 인덱스를 이용 가능하도록 한다.

 

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

  - 거래일자+사무소코드+출급기번호+명세표번호 순서.. 사무소코드가 '='으로 들어오고, 거래일자는 'BETWEEB'조회이므

    로 인덱스를 정상적으로 타나 효율은 떨어지는 CASE.

   - 즉, 넓은 범위를 스캔함으로서 인덱스는 타지만 성능은 저하되는 케이스

 

   - 사무소코드+거래일자로 구성된 인덱스의 경우 '='비교를 한 사무소코드가 인덱스 앞에 위치하여 범위가 좁아짐

   - 인덱스의 순서를 고려하여 모델의 PK순서를 거래일자+사무소코드+출급기번호+명세표번호 에서

    사무소코드 + 거래일자 + 출급기번호 + 명세표번호로 수정하여 성능을 개선한다.

 

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

   - 물리적인 테이블에 FK를 사용하지 않아도 데이터 모델 관계에 의해 상속받은 FK속성들은 SQL WHERE절에서 조인으로

     이용되는 경우가 많이 있으므로 FK인덱스를 생성해야 성능이 좋은 경우가 빈번하다.

 

   - 비록 수강신청 테이블에 있는 학사기준번호가 SQL WHERE절에 비교자로 들어오지는 않았지만 수강신청 테이블에서 상속받은 학사기준번호에 대해 인덱스를 생성하지 않으므로 인해 학사기준과 수강신청 테이블이 조인이 되면서 500만 건의 수강신청 테이블이 FULL TABLE SCAN이 발생되어 성능이 저하 됨.

 

 

 

 

 

    - 이때는 수강신청 테이블에 FK인덱스를 생성하여 성능을 개선할수 있음.

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

   - 물리적인 테이블에 FK제약 걸었을 때는 반드시 FK인덱스를 생성하도록 하고 FK제약이 걸리지 않았을 경우 FK인덱스를 생성하는 것을 기본정책으로 하되 발생되는 트랜잭션에 의해 거의 활용되지 않았을 때에만 FK인덱스를 지우는 방법으로 하는 것이 적절한 방법이 된다.