① 업무를 구성하는 데이터의 특징을 분석하여 공통점/차이점을 고려하여 효과적으로 표현할 수 있음
② 공통의 부분을 슈퍼타입 엔터티으로 모델링하고 공통으로 부터 상속받아 다른 엔터티와 차이가 있는 속성
에 대해서는 별도의 서브 타입 엔터티로 구분
③ 업무의 모습을 정확하게 표현하면서 물리적인 데이터 모델로 변환을 할 때 선택의 폭을 넓힐 수 있는 장점
이 있음
•
슈퍼/서브 타입 모델의 물리 데이터 모델 변환 유형 3가지
슈퍼/서브타입 모델 변환 방법
•
슈퍼타입 (Single 타입, All in One 타입) 기준 :
슈퍼/서브타입을 모델을 하나의 테이블로 변환한 것이다. (예:고객 테이블 하나로만 구성한다.)
Single 타입 기준 혹은 All in One 타입 기준이라고도 한다.
•
서브타입 (Plus 타입, Super+Sub 타입) 기준 :
슈퍼/서브타입을 서브타입 테이블들로 변환한 것이다. (예:개인고객, 법인고객 테이블로 구성한다.)
도출된 각각의 서브타입에는 변환 전 슈퍼 엔터티에 있던 컬럼들을 공통적으로 가지고 있다.
Plus 타입 기준 혹은 Super+Sub 타입 기준이라고도 한다.
•
개별타입 (OneToOne 타입, 1:1 타입) 기준 :
슈퍼/서브타입을 슈퍼, 서브타입 각각 개별 테이블로 변환한 것이다. (예:고객, 개인고객, 법인고객 테이
블로 구성한다.)
슈퍼 테이블, 서브 테이블 모두 생성한 것이다.
OneToOne 타입 기준 혹은 1:1 타입 기준이라고도 한다.
슈퍼 타입/서브타입 모델
•
슈퍼/서브타입 데이터 모델의 변환의 중요성
◦
트랜잭션은 항상 슈퍼타입 기준으로 처리하는데 테이블은 개별타입으로 유지되어 UNION 연산에 의해 성능이 저하될 수 있다. (슈퍼타입 기준으로 테이블을 구성하는 것이 유리한 경우이다.)
◦
트랜잭션은 항상 서브타입을 기준으로 처리하는데 개별타입 혹은 슈퍼타입으로 되어 있는 경우 성능이 저하되는 경우가 있다. (서브타입 기준으로 테이블을 구성하는 것이 유리한 경우이다.)
◦
트랜잭션은 항상 개별타입 기준으로 처리하는데 테이블은 슈퍼타입으로 되어 있어 불필요하게 많은 양의 데이터가 집약되어 있어 성능이 저하되는 경우가 있다. (개별타입으로 테이블을 구성하는 것이 유리한 경우이다.)
슈퍼/서브 타입 데이터 모델의 변환 기술
•
슈퍼/서브타입(논리)를 슈퍼타입(물리)으로 변환
슈퍼/서브타입(논리)
◦
논리 데이터 모델의 슈퍼/서브타입을 물리 데이터 모델로 변환 시 슈퍼타입으로 변환하는 것은 슈퍼/서브타입 전체를 하나의 테이블로 구성하는것을 뜻한다.
◦
슈퍼/서브타입의 데이터를 처리 시 항상 통합하여 처리한다고 가정하면 하나의 테이블로 구성하는 것이 성능 상 유리할 수 있다.
◦
데이터를 처리할 때 항상 통합하여 처리하는데 개별로 분리하게 되면 조인 연산 혹은 UNION ALL 연산 등이 빈번해져서 오히려 성능에 부담을 줄수 있기 때문이다.
◦
이러한 경우 하나의 테이블로 통합하여 테이블을 구축한다. 슈퍼/서브타입(논리)을 슈퍼타입(물리)으로 변환하는 기법이다.
•
슈퍼/서브타입(논리)을 서브타입(물리)으로 변환
슈퍼/서브타입(논리)
서브타입(물리)
슈퍼/서브타입의 데이터 처리 시 10만건인 대리인에 대해서 개별로 처리하는 일이 빈번하다고 가정한다.
만약 슈퍼타입(물리)으로 변환하여 하나의 테이블로 구성하였다면 10만건인 대리인의 데이터를 처리하기 위해서 이해관계인(500만건) 및 매수인(500만건)의 데이터까지 모두 처리해야 한다.
10만건의 대리인에 대한 데이터를 처리하려고 할때 1010만건의 데이터를 모두 처리해야하는 비효율이 발생하
는 것이다.
이러한 비효율을 제거하기 위해서 서브타입 기준으로 테이블을 변환한다.
•
만약 대부분의 업무 처리가 각각의 개별로 발생한다고 가정한다.
•
당사자, 이해관계인, 대리인, 매수인 각각에 대해 독립적으로 트랜잭션이 발생하면 당사자에 꼭 필요한 컬럼들만 을 가지게 하고 이해관계인, 대리인, 매수인에도 꼭 필요한 컬럼들만을 가지게한다.
•
기존의 슈퍼/서브(논리) 타입을 모두 개별 테이블로 변환한 것이다.
•
전체를 하나로 묶어 트랜잭션이 발생할 때는 하나의 테이블로 구성
슈퍼/서브타입 데이터 모델 변환 타입 비교
I/O 기능 ⇒ 나쁨, 좋음 ⇒ 하나의 테이블 여부
PK/FK 칼럼 순서와 성능
PK/FK 칼럼 순서와 성능개요
•
테이블에 발생되는 트랜잭션 조회 패턴에 따라 PK/FK 칼럼의 순서를 조정해야 함
•
성능저하 현상이 많은 부분이 PK가 여러 개의 속성으로 구성된 복합식별자 일 때 PK순서에 대해 별로 고려하지 않고 데이터 모델링을 한 경우에 해당
•
물리적인 데이터 모델링 단계에서는 스스로 생성된 PK순서 이외에 다른 엔터티로부터 상속받아 발생되는 PK순서까지 항상 주의하여 표시
PK가 복합키일 경우 칼럼순서가 성능에 영향을 미치는 이유
•
인덱스 선두 칼럼에 대한 조건이 들어와야 한다. (가능한 한 '=' 조건으로)
•
인덱스 선두 칼럼에 대한 조건이 들어오지 않을 경우 인덱스 전체를 읽거나 테이블 전체를 읽게 됨
예) 테이블의 PK는 수험번호+년도+학기로 구성되어 있고 전형과목실적 테이블은 입시마스터 테이블에서 상속받
은 수험번호+년도+학기에 전형과목코드로 PK가 구성되어 있는 복합식별자 구조의 테이블
⇒ 수험번호+년도+학기 중 수험번호에 대한 값이 WHERE절에 들어오지 않으므로 FULL TABLE SCAN이 발생, 200만 건의 데이터를 모두 읽게 되어 성능이 저하
⇒ 성능 개선
⇒ 년도+학기+수험번호 순으로 되어 있으므로 해당 조건이 ‘=‘ 조건으로 들어오게 되어 성능이 향상됨
PK순서를 잘못 지정하여 성능이 저하된 경우 - 복잡한 오류
현금출금기실적의 PK는 거래일자+사무소코드+출금기번호+명세표번호로 되어 있는데
대부분의 SQL문장에서는 조회를 할 때 사무소코드가 ‘=’로 들어오고 거래일자에 대해서는 ‘BETWEEN’ 조회
SQL은 정상적으로 인덱스를 이용할 수 있지만 인덱스 효율이 떨어져 성능이 저하되는 경우에 해당
⇒ 인덱스 스캔은 가능하나 최적화된 인덱스 사용은 되지 않음
⇒ 사무소코드+거래일자 순으로 스캔하게 되므로 최적화된 인덱스 스캔이 가능하게 됨
물리적인 테이블에 FK제약이 걸려있지 않을 경우 인덱스 미생성으로 성능저하
⇒ 물리적인 테이블에 FK를 사용하지 않아도 데이터 모델 관계에 의해 상속받은 FK속성들은 SQL WHERE 절에서 조인으로 이용되는 경우가 많이 있으므로 FK 인덱스를 생성해야 성능이 좋은 경우가 빈번
•
수강신청 테이블의 학사기준번호에 인덱스가 존재하지 않는 경우 조인 시 성능이 매우 안좋을 수 있음
•
학사기준번호 테이블에 인덱스를 생성하여 성능을 향상 시킬 수 있음