by-nc-sa     개발자, DBA가 함께 만들어가는 구루비 지식창고!

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




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

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

슈퍼/서브타입에 대한 변환을 잘못하면 성능이 저하되는 이유는 트랜잭션 특성을 고려하지 않고 테이블이 설계되었기 때문이다.

1) 트랜잭션은 항상 일괄로 처리하는데 테이블은 개별로 유지되어 Union연산에 의해 성능저하
2) 트랜잭션은 항상 서브타입 개별로 처리하는데 테이블은 하나로 통합되어 있어 불필요하게 많은 양의 데이터가 집약되어 성능저하
3) 트랜잭션은 항상 슈퍼+서브 타입을 공통으로 처리하는데 개별로 유지되어 있거나 하나의 테이블로 집약되어 있어 성능이 저하

데이터의 양이 소량일 경우 처리의 유연성을 고려해 1:1관계를 유지하는것이 바람직. 대용량일 경우는 트랜잭션의 발생형태에 따라 3가지 변환방법을 참조하여 상황에 맞게 변환하도록 해야 한다.

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

1) 개별로 발생되는 트랜잭션에 대해서는 개별 테이블로 구성
2) 슈퍼타입+서브타입에 대해 발생되는 트랜잭션에 대해서는 슈퍼타입+서브타입 테이블로 구성
3) 전체를 하나로 묶어 트랜잭션이 발생할 때는 하나의 테이블로 구성

라. 슈퍼/서브타입 데이터 모델의 변환타입 비교
구분 OneToOne Type Plus Type Single 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인덱스 생성을 기본정책으로 하되 향후 트랜잭션에 의해 거의 활용되지 않았을 때만 지우는 것이 적절한 방법이 된다.

문서정보

Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. 3월 13, 2013

    기민용 says:

    제2절 정규화 가 아직 안올라와서...(아직 책은 못봐서 감이 완오네 ㅠ.ㅠ) 슈퍼타입/서브타입 설계시 3가지 유형으로 설계가 가능한데... ...

    제2절 정규화 가 아직 안올라와서...(아직 책은 못봐서 감이 완오네 ㅠ.ㅠ)

    슈퍼타입/서브타입 설계시 3가지 유형으로 설계가 가능한데...

    (질문 이자 예상문제 출제)
    슈퍼타입/서브타입 관계에서 정규화 입장에서 본다면 아래 3가지 유형중 어떤 유형이 정규화 유형인가?
    (1) 각각의 테이블
    (2) 수퍼타입 + 서브타입 각각
    (3) 하나의 테이블 통합
    (4) 모두 해당
    (5) 모두 아님

    1. 3월 15, 2013

      하봉래 says:

      저는 2번으로 생각됨...

      저는 2번으로 생각됨...

    2. 3월 18, 2013

      기민용 says:

      스터디때 우리끼리 낸 결론은. 정규화도 반정규화도 아닌 다른 시각(슈퍼타입/서브타입)에서의 접근이므로 정규화의 시각으로 봐서는 안된다. 따...

      스터디때 우리끼리 낸 결론은.

      • 정규화도 반정규화도 아닌 다른 시각(슈퍼타입/서브타입)에서의 접근이므로 정규화의 시각으로 봐서는 안된다.
      • 따라서 문제가 잘못된것이다.
        • 혹시 이견 있으신분은 댓글 환영...

      이와 유사하게 반정규화때 살펴보았던 컬럼을 기준으로 한 테이블 분할은 반정규화가 맞다.

      • 예) 사원정보 테이블의 컬험이 200개 정도 된다고 했을 때.
      • 업무 특성에 따라(트렌젝션 발생 경로에 따라) 테이블 분리..
        • 사원기본정보, 신체사항, 병역사항, 취미사항, 등등등 으로 1:1 로 분리하는 것은 반정규화
  2. 3월 13, 2013

    이재현 says:

    답은 4번인가요??

    답은 4번인가요??

  3. 3월 15, 2013

    이가혜 says:

    PK칼럼의 순서를 조정하지 않으면 성능이 저하 이유의 예제를 보면.. 주문번호+주문일자+주문번호코드되어 있는데. 꼭 이게 나쁘다고 볼수는 없어요...

    PK칼럼의 순서를 조정하지 않으면 성능이 저하 이유의 예제를 보면..
    주문번호+주문일자+주문번호코드되어 있는데. 꼭 이게 나쁘다고 볼수는 없어요.
    만약 주문일자가. 해당 일자만 검색 되거나. 검색되는 일자의 집합이 작다면은 우수할 수도 있으나.
    만약 between으로 매번 검색한다고 하면은 차라리. 이게 훨씬. 좋아 보일 듯 해요~!!!
    항상 인덱스는 답은 없고. 선택하는 거니깐요~!!!

    이상한 PK들이 많이 존재 해요....
    이유를 물어 보면. 그냥 그렇게 모델에 그려져서 라고 대답하는.. ㅎㅎㅎ;;;

  4. 3월 15, 2013

    이재현 says:

    대장?? 주문일자 + 주문번호 + 주문번호코드 말씀하시는거죠???

    대장??

    주문일자 + 주문번호 + 주문번호코드 말씀하시는거죠???

  5. 3월 15, 2013

    안종식 says:

    테이블 설계과 구현은 트렌잭션에 의해서 결정되는다는 말이 공감이 많이 되네요. 저희는 거의 반정규화 되어 있는데 증권업무의 특성상 이런 식으로 ...

    테이블 설계과 구현은 트렌잭션에 의해서 결정되는다는 말이 공감이 많이 되네요.
    저희는 거의 반정규화 되어 있는데 증권업무의 특성상 이런 식으로 구현하지 않았을까 생각이 드네요.

    물론 모델링과 서버와 프로그램과 업무에 대해서 알고 있으면 더 다양한 방안이 나올 것 같네요 ㅎㅎㅎ