SQL 전문가 가이드 (2013년)
데이터베이스 구조와 성능 0 0 74,247

by 구루비스터디 슈퍼타입 서브타입 [2013.09.01]


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


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

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


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


  • 슈퍼/서브타입에 대한 변환을 잘못하면 성능이 저하되는 이유는 트랜잭션 특성을 고려하지 않고 테이블이 설계되었기 때문이다.
  • 1) 트랜잭션은 항상 일괄로 처리하는데 테이블은 개별로 유지되어 Union연산에 의해 성능저하
  • 2) 트랜잭션은 항상 서브타입 개별로 처리하는데 테이블은 하나로 통합되어 있어 불필요하게 많은 양의 데이터가 집약되어 성능저하
  • 3) 트랜잭션은 항상 슈퍼+서브 타입을 공통으로 처리하는데 개별로 유지되어 있거나 하나의 테이블로 집약되어 있어 성능이 저하
  • 데이터의 양이 소량일 경우 처리의 유연성을 고려해 1:1관계를 유지하는것이 바람직. 대용량일 경우는 트랜잭션의 발생형태에 따라 3가지 변환방법을 참조하여 상황에 맞게 변환하도록 해야 한다.


다. 슈퍼/서브 타입 데이터 모델의 변환기술
  • 1) 개별로 발생되는 트랜잭션에 대해서는 개별 테이블로 구성
  • 2) 슈퍼타입+서브타입에 대해 발생되는 트랜잭션에 대해서는 슈퍼타입+서브타입 테이블로 구성
  • 3) 전체를 하나로 묶어 트랜잭션이 발생할 때는 하나의 테이블로 구성


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


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인덱스 생성을 기본정책으로 하되 향후 트랜잭션에 의해 거의 활용되지 않았을 때만 지우는 것이 적절한 방법이 된다.
"구루비 데이터베이스 스터디모임" 에서 2013년에 "SQL 전문가 가이드" 도서를 스터디하면서 정리한 내용 입니다.

- 강좌 URL : http://www.gurubee.net/lecture/2363

- 구루비 강좌는 개인의 학습용으로만 사용 할 수 있으며, 다른 웹 페이지에 게재할 경우에는 출처를 꼭 밝혀 주시면 고맙겠습니다.~^^

- 구루비 강좌는 서비스 제공을 위한 목적이나, 학원 홍보, 수익을 얻기 위한 용도로 사용 할 수 없습니다.

댓글등록
SQL문을 포맷에 맞게(깔끔하게) 등록하려면 code() 버튼을 클릭하여 작성 하시면 됩니다.
로그인 사용자만 댓글을 작성 할 수 있습니다. 로그인, 회원가입