슈퍼타입/서브타입 모델링과 물리 테이블 변환 기준

슈퍼타입과 서브타입으로 공통·고유 속성을 분리하고, OneToOne·PlusType·SingleType 변환 방식을 선택하는 기준을 정리한다.

2026-08-14 · 최초 발행 2025-08-10

공통 속성과 유형별 속성을 분리하는 모델

슈퍼타입/서브타입은 유사한 엔터티의 상속 관계를 데이터 모델에 표현하는 방법이다. 여러 유형이 공유하는 속성은 슈퍼타입에 두고, 각 유형에만 필요한 속성은 서브타입으로 분리한다. 객체지향 프로그래밍의 상속 개념과 닮았지만, 데이터 중복과 일관성 문제를 다루는 모델링 기법이라는 점에 초점이 있다.

공통 속성을 한곳에서 관리하면 변경 범위가 줄고, 복잡한 관계도 계층적으로 읽을 수 있다. 서브타입별 업무 규칙과 속성 차이를 모델에 드러낼 수 있어 유지보수에도 유리하다.

다만 하나의 서브타입은 하나의 슈퍼타입만 가질 수 있으며, 어떤 서브타입인지 식별할 구분자가 필요하다.

접수 유형을 계층으로 표현한 예

접수번호, 접수자명, 접수구분코드는 모든 접수에 공통이므로 접수에 둔다. 인터넷·방문·전화 접수에만 필요한 정보는 각각의 서브타입이 맡는다. 이때 접수구분코드가 접수 유형을 나누는 구분자 역할을 한다.

접수+접수자명+접수구분코드+접수번호(PK)인터넷접수+인터넷ID+접수번호(FK)방문접수+방문장소+접수번호(FK)전화접수+전화일시+접수번호(FK)

논리 모델을 테이블로 옮기는 방식

OneToOne(Identity): 공통 정보와 유형 정보를 분리한다

슈퍼타입과 서브타입을 각각 독립 테이블로 두고 일대일 관계로 연결하는 구조다.

1:0,11:0,11:0,1접수인터넷접수방문접수전화접수

정규화 수준이 높고 각 엔터티의 독립성을 유지할 수 있으며, 불필요한 NULL 값도 피할 수 있다. 반면 조회할 때 테이블 조인이 필요하고 Union 연산에 따른 오버헤드가 생길 수 있다.

서브타입별 속성이 많거나 유형 간 속성 차이가 클 때 적합하다.

PlusType(RollDown): 공통 속성을 서브타입에 함께 둔다

이 방식에서는 슈퍼타입 속성을 모든 서브타입 테이블에 중복 저장한다.

1:0,11:0,11:0,1ReceptionintReceptionNumberPKstringReceptionistNamestringReceptionTypeCodeInternetreceptionintReceptionNumberPK,FKstringInternetIDstringReceptionistNamestringReceptionTypeCodeVisitreceptionintReceptionNumberPK,FKstringVisitLocationstringReceptionistNamestringReceptionTypeCodeCallreceptionintReceptionNumberdatetimeCallDateTimestringReceptionistNamestringReceptionTypeCode

조인 연산을 줄여 조회 성능을 높일 수 있고, 서브타입별 처리를 분리하기 쉽다. 대신 같은 정보가 여러 테이블에 반복되므로 저장 공간을 더 쓰며, 데이터 일관성을 유지하기 위한 관리가 필요하다.

조회 성능이 중요하거나 서브타입별 독립 처리가 많은 환경에서 고려할 수 있다.

SingleType(RollUp): 하나의 테이블에 통합한다

슈퍼타입과 모든 서브타입 속성을 단일 테이블에 모으는 방식이다.

ReceptionintReceptionNumberPKstringReceptionistNamestringReceptionTypeCodestringInternetIDstringVisitLocationdatetimeCallDateTime

조인이 필요 없어 조회 성능이 좋고, 구현과 관리도 단순하다. 그러나 유형에 따라 사용하지 않는 컬럼이 많아 NULL 값이 늘 수 있으며, 저장 공간 낭비와 서브타입별 제약조건 적용의 어려움이 뒤따른다.

서브타입 간 속성 차이가 작고 단순한 구조가 필요한 경우에 맞는다.

각 방식에서 달라지는 운영 특성

항목 OneToOne (Identity) PlusType (RollDown) SingleType (RollUp)
특징 개별 테이블 생성, 1:1 관계 공통 속성이 서브타입에 중복 하나의 통합 테이블
확장성 높음 중간 낮음
조인 성능 낮음 (다중 조인 필요) 중간 높음 (조인 불필요)
I/O량 낮음 (필요 데이터만 접근) 중간 높음 (전체 테이블 접근)
데이터 중복 없음 높음 없음 (NULL 값 다수)
관리 복잡도 높음 중간 낮음

트랜잭션과 업무 규칙으로 선택하기

서브타입별 속성 수와 볼륨 차이가 작고, NULL 허용 비율이 낮으며, 대부분의 트랜잭션이 전체 서브타입을 함께 조회한다면 SingleType이 맞을 수 있다. 서브타입 간 데이터 이동이 빈번한 경우도 통합화 판단에 포함된다.

반대로 서브타입마다 속성이 많거나 볼륨 차이가 크고, 특정 서브타입만 접근하는 트랜잭션이 많다면 OneToOne 또는 PlusType을 검토한다. 유형마다 업무 규칙과 제약사항이 다르거나 보안 요구사항이 다를 때도 세분화된 모델이 유리하다.

고객과 결제 모델에 적용한 형태

금융기관의 고객 정보에서는 개인고객과 법인고객이 공통 고객 정보를 공유하면서도 서로 다른 속성을 갖는다.

고객+고객명+고객구분코드+연락처+주소+고객번호(PK)개인고객+주민등록번호+직업코드+결혼여부+고객번호(FK)법인고객+사업자등록번호+업종코드+설립일자+자본금+고객번호(FK)

이 구조에 OneToOne 방식을 적용하면 개인정보 보호를 위한 접근 제어가 쉬워지고, 개인고객과 법인고객의 속성 차이도 명확히 나눌 수 있다.

전자상거래 주문 시스템에서는 결제 유형을 서브타입으로 모델링할 수 있다.

결제+주문번호+결제금액+결제일시+결제구분코드+결제번호(PK)신용카드결제+카드사코드+카드번호+승인번호+결제번호(FK)계좌이체결제+은행코드+계좌번호+이체일시+결제번호(FK)포인트결제+포인트유형+사용포인트+결제번호(FK)

결제 유형별 조회 성능과 특화 처리가 중요하다면 PlusType 방식으로 설계할 수 있다. 모델을 물리 구조로 바꿀 때는 업무 특성, 트랜잭션 패턴, 성능 요구사항을 함께 봐야 한다.

데이터 모델링슈퍼타입서브타입엔터티 모델링물리 모델