[ 슈퍼/서브 타입 모델 ]
슈퍼/서브 타입 모델은 업무를 구성하는
데이터의 특징을 분석하여 공통점과 차이점을
고려하여 효과적으로 표현할 수 있다.
공통의 부분을 슈퍼 타입 엔터티로 도출하고
공통으로부터 상속받아 다른 엔터티와 차이가 있는
속성에 대해서는 별도의 서브 타입 엔터티로 구분한다.
논리 데이터 모델링에서 슈퍼/서브 타입을 구성하면
물리 데이터 모델로 변환할 경우, 3가지 방식에 따르게 된다.
1) 슈퍼 타입 기준 - Single 타입
2) 서브 타입 기준 - Plus 타입
3) 개별 타입 기준 - OneToOne 타입
[ 모델 변환의 중요성 ]
논리 데이터 모델링 시 정의한 슈퍼/서브 타입을
물리 모델로 변환하는 것은 성능상 중요하다.
예시 사례)
- 1번
트랜잭션은 항상 슈퍼 타입 기준으로 처리하는데 테이블은
개별 타입으로 유지되어 UNION 연산에 의해 성능이 저하.
→ 슈퍼 타입 기준으로 테이블 구성하는 것이 유리
- 2번
트랜잭션은 항상 서브 타입을 기준으로 처리하는데 테이블은
슈퍼 타입으로 되어 있는 경우 성능이 저하되는 경우.
→ 서브 타입 기준으로 테이블 구성하는 것이 유리
- 3번
트랜잭션은 항상 개별 타입 기준으로 처리하는데, 테이블은
슈퍼 타입으로 되어 있어서 불필요하게 많은 양의 데이터가
집약되어 성능이 저하되는 경우.
→ 개별 타입 기준으로 테이블 구성하는 것이 유리
따라서 논리 데이터 모델링 시 정의한 슈퍼/서브 타입을
물리 데이터 모델로 변환 시 적절하게 선택을 해야한다.
슈퍼 타입(물리) 변환
슈퍼/서브 타입 전체를 하나의 테이블로 구성
데이터를 처리 시 항상 통합하여 처리한다.
서브 타입(물리) 변환
슈퍼/서브 타입 전체를 서브 타입 기준으로 테이블 변환
각각의 서브 타입으로만 테이블이 설계된다.
개별 타입(물리) 변환
슈퍼/서브 타입 전체를 모두 개별 테이블로 변환
꼭 필요한 칼럼들만을 가지도록 한다.
| 구분 | 슈퍼 타입 | 서브 타입 | 개별 타입 |
| 특징 | 하나의 테이블 | 각각의 서브 타입 테이블 | 슈퍼, 서브 각각의 테이블 |
| 확장성 | 나쁨 | 보통 | 좋음 |
| 조인 성능 | 좋음 | 나쁨 | 나쁨 |
| I/O 성능 | 나쁨 | 좋음 | 좋음 |
| 관리 용이성 | 좋음 | 나쁨 | 나쁨 |
| 트랜잭션 유형에 따른 선택 방법 |
전체를 일괄적으로 처리하는 경우 |
각각의 서브 타입을 기준으로 처리하는 경우 |
각각의 슈퍼, 서브 타입을 기준으로 처리하는 경우 |
[ PK 칼럼 순서와 성능 ]
테이블에는 기본키(PK)가 존재하고
단 1개의 칼럼으로 이루어져 있을 수 있고(단일PK)
2개 이상의 칼럼으로 이루어져 있을 수도 있다(복합PK).
복합 PK의 경우 PK 칼럼 순서에 따라
SQL문의 성능이 빨라질 수도 있고 느려질 수도 있다.
테이블 생성 시 PK는 DBMS에서
자동으로 인덱스도 같이 생성되기 때문에
PK가 복합 PK일 경우 복합 PK의 칼럼 순서가
성능에 영향을 미친다.
외래키(FK) 칼럼에 대한 인덱스 생성의 중요성
논리 데이터 모델상으로 관계에 의한
외래키(FK) 제약이 걸린 경우, 해당 FK 제약이
실제 물리 데이터베이스에 적용될지 안될지는
물리 데이터 모델 설계자의 몫이다.
관계가 있어도 FK 제약조건을 생성하지 않은 경우도 있고,
FK 제약조건을 생성했어도 칼럼에 인덱스를 안많드는 경우도 있다.
단 물리적인 왜래키(FK)의 생성 여부와는 상관없이
논리적이든 물리적이든 FK 제약조건이 있다면(관계O)
외래키 칼럼에 대해 인덱스를 생성하는 것이
성능상 유리한 경우가 많다.
'개주 훈련일지 > 📚 코살대 교본 학습' 카테고리의 다른 글
| SQL) 분산 데이터베이스와 성능 (0) | 2025.12.26 |
|---|---|
| 소프트웨어 요구분석과 요구 (0) | 2025.12.25 |
| SQL) 대량 데이터에 따른 성능 (0) | 2025.12.25 |
| SQL) 반정규화와 성능 (0) | 2025.12.24 |
| 프로젝트 리스크 관리 (0) | 2025.12.23 |