DB-7/1

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

 

Extended ER Model: 이 모델이 자주 쓰이는 이 유는 업무를 구성하는 데이터의 특징을 공통과 차이점의 특징을 고려하여 효과적으로 표현할 수 있기 때문이다. 즉, 공통의 부분을 슈퍼타입으로 모델링하고 공통으로부터 상속받아 다른 엔터티와 차이가 있는 속성에 대해서는 별도의 서브엔터티로 구분하여 업무의 모습을 정확하게 표현하면서 물리적인 데이터 모 델로 변환을 할 때 선택의 폭을 넓힐 수 있는 장점이 있다.

 

슈퍼/서브타입의 데이터모델은 논리적인 데이터모델링에서 사용하는 방식이므로, 진짜 SQL로 테이블 짜야하는 물리적 데이터모델링에서는 알맞게 이것을 변형해야한다. 

여러가지 변환방법

이러한 변환방법의 기준은 애플리케이션의 트랜잭션 특성을 분석해야한다.

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

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

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

 

변환기준:

데이터가 소량이면 그냥 1:1 타입으로 가고 데이터가 많아지면 트랜잭션 특성에 따라 3가지 중 하나 골라라.

(데이터의 양은 데이터량이 소량일 경우 성능에 영향을 미치지 않기 때문에 데이터처리의 유연성을 고려하여 가급적 1:1 관계를 유지하는 것이 바람직하다. 그 러나 데이터용량이 많아지는 경우 그리고 해당 업무적인 특징이 성능에 민감한 경우는 트랜잭션이 해당 테이블에 어떻게 발생되는지에 따라 3가지 변환방법 을 참조하여 상황에 맞게 변환하도록 해야 한다.)

 

1:1 타입 (1)

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

이때는 보면 각각의 당사자에 대해서 이름을 택하면 그 사람의 세부정보가 나온다. 이는 대리인-개인정보 테이블의 1:1 매핑으로 가능하다. 개인정보 테이블에 대리인 부모 테이블의 중복되는 공통속성을 전부 놓을 필요가 없어서 성능향상 기대 가능하다. 

 

(2)

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

위와는 다르게 테이블에 슈퍼타입의 칼럼과 서브타입의 칼럼들 매번 같이 트랜잭션에서 수행되면 1:1 타입으로 구성해버리면 조인연산으로 인해 추가적인 오버헤드가 발생한다. 따라서 그냥 슈퍼+서브타입으로 같이 묶어버려서 테이블 구성해버리면 한 테이블에서 전부 처리하니까 오버헤드 발생이 없다. 

 

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

여러 자식 테이블인 이해관계인, 대리인, 매수인이 전부 부모테이블과 함께 트랜잭션이 수행된다면 그냥 전부 하나로 묶어버린다. 

 

종합: 

 

인덱스 특성을 이용한 PK/FK DB 성능향상:

PK/FK 칼럼 순서도 성능에서 유효하다. 특히나 복합식별자로 구성될때 PK 순서에 별로 고려하지 않는 물리적 모델링은 성능저하를 일으킬 수 있다. 또한 위에서 본 슈퍼/서브타입처럼 다른 테이블에서 상속받아 만드는 테이블 경우에도 슈퍼타입에서 받아 생기는 PK순서 또한 고려해야한다. 

 

PK는 해당 해당테이블의 데이터를 접근할 가장 빈번하게 사용되는 유 일한 인덱스(Unique Index)를 모두 자동 생성한다

 

PK순서를 결정하는 기준은 인덱스 정렬구조를 이해한 상태에서 인덱스를 효율적으로 이용할 수 있도록 PK 순서를 지정해야 한다. 즉 인덱스의 특징은 여러 개의 속성이 하나의 인덱스로 구성되어 있을 때 앞쪽에 위치한 속성의 값이 비교자로 있어야 인덱스가 좋은 효율을 나타낼 수 있다. 앞쪽에 위치한 속성 값이 가급적 ‘=’ 아니면 최소한 범위 ‘BETWEEN’ ‘< >’가 들어와야 인덱스를 이용할 수 있는 것이다. (즉 복합 식별자로 인덱스 만들면 맨 앞의 속성은 가급적 비교자(=,BETWEEN)를 자주 쓰는 속성이 들어오도록 순서를 정해야된다.) 

 

또한 FK라고 하더라도 데이터를 조회할 때 조인의 경로를 제공하는 역할을 수행하므로 FK에 대해서는 반드시 인덱스를 생성하도록 하고 인덱스 칼럼의 순서도 조회의 조건을 고려하여 접근이 가장 효율적인 칼럼 순서대로 인덱스를 생성하도록 주의해야 한다.

 

+ FK 인덱스는 조인해서 조회할려고 애초에 참조테이블을 만든거니까 FK에 대한 인덱스는 만들어놓자.