엔터티 상세화와 서브타입

핵심 요약

슈퍼타입은 여러 유형에 공통인 식별자·속성·관계를 보유하고, 서브타입은 특정 유형에만 적용되는 속성·관계·규칙을 상속 구조로 표현한다. 올바른 서브타입 설계에는 분류 기준 하나, 완전성, 배타성, 판별 규칙, 유형 변경 가능성이 명시되어야 한다. 유형 코드가 있다는 이유만으로 서브타입을 만드는 것도, 구현 편의를 위해 논리적 차이를 없애는 것도 적절하지 않다.

학습 목표

• 슈퍼타입과 서브타입의 식별자·속성·관계 상속을 설명한다.
• 완전/불완전과 배타/포괄(중복) 제약을 사례로 판정한다.
• 판별자와 서브타입별 고유 업무 규칙을 정의한다.
• 단순 분류 코드와 실제 서브타입 구조를 구분한다.

1. 개념 설명

1.1 슈퍼타입과 서브타입

서브타입의 각 인스턴스는 동시에 슈퍼타입의 인스턴스다. 따라서 서브타입은 슈퍼타입의 주식별자를 그대로 상속하며, 공통 속성과 공통 관계도 상속한다.

고객(고객번호, 고객명, 연락처)
  ├─ 개인고객(고객번호, 생년월일)
  └─ 법인고객(고객번호, 법인등록번호, 대표자명)

개인고객과 법인고객의 고객번호는 별도의 무관한 식별자가 아니라 고객 인스턴스와 동일성을 유지하는 상속 식별자다.

1.2 서브타입이 필요한 조건

다음 중 하나 이상이 지속적으로 성립하면 서브타입을 검토한다.

• 유형별로 필수 속성이나 도메인이 다르다.
• 유형별로 참여하는 관계가 다르다.
• 유형별 생성·변경·종료 규칙이 다르다.
• 유형별 무결성 규칙을 명확히 표현해야 한다.
• 공통 부분과 고유 부분을 분리하면 업무 의미가 더 정확해진다.

반대로 유형마다 고유 속성·관계·행위가 없고 단순 조회·집계 분류만 필요하다면 분류 코드 속성으로 충분할 수 있다.

1.3 완전성과 배타성

두 축은 독립적이다. 따라서 완전·배타, 완전·포괄, 불완전·배타, 불완전·포괄의 네 조합이 가능하다.

1.4 판별자와 분류 기준

배타 서브타입은 보통 슈퍼타입의 판별자 값으로 어느 서브타입에 속하는지 결정할 수 있다. 판별자는 다음 조건을 만족해야 한다.

• 한 서브타입 집합에서 하나의 분류 기준을 사용한다.
• 코드값과 서브타입의 대응이 명확하다.
• 완전성·배타성 규칙과 모순되지 않는다.
• 값 변경 시 서브타입 전환 절차가 정의되어 있다.

고객을 한 축에서는 개인/법인, 다른 축에서는 국내/해외로 동시에 분해하려면 서로 다른 두 서브타입 집합으로 모델링해야 한다. 하나의 집합에 서로 다른 분류 기준을 섞으면 완전성과 배타성을 해석할 수 없다.

1.5 상속되는 관계와 고유 관계

슈퍼타입에 연결한 관계는 모든 서브타입에 공통으로 적용된다. 특정 유형에만 존재하는 관계는 해당 서브타입에 연결한다.

고객 ── 주문            (모든 고객 공통)
법인고객 ── 법인담당자   (법인에만 적용)
개인고객 ── 본인인증     (개인에만 적용)

공통 관계를 각 서브타입에 반복 연결하면 동일 의미의 관계가 중복되고 누락 가능성이 커진다. 반대로 법인에만 적용되는 관계를 슈퍼타입에 두면 개인고객에도 허용되는 것처럼 보인다.

1.6 유형 전환과 생명주기

서브타입은 정적 분류만이 아니다. 인스턴스가 유형을 바꿀 수 있는지 확인해야 한다.

• 개인사업자가 법인으로 전환할 때 동일 고객으로 볼 것인가?
• 직원이 일반직원에서 관리자로 승진할 때 과거 관리자 속성을 보존할 것인가?
• 중복 서브타입에서 하나의 역할이 종료되어도 슈퍼타입은 유지되는가?

유형 전환 시 고유 속성의 필수성, 관계 이전, 이력 보존, 판별자 갱신을 함께 정의한다.

2. 구성요소와 관계

3. 서브타입 판단 흐름

유형 후보 발견
  ↓
유형별 고유 속성·관계·업무 규칙이 있는가?
  ├─ 아니오 → 분류 코드 속성으로 충분한지 검토
  └─ 예
      ↓
분류 기준을 한 문장으로 정의
      ↓
완전/불완전 + 배타/포괄 결정
      ↓
판별자, 상속 관계, 유형 전환·이력 규칙 정의
      ↓
정상·미분류·중복소속·유형변경 사례로 검증

4. 사례

사례 1: 결제수단

결제수단에는 카드·계좌이체·가상계좌가 있고, 공통으로 결제수단번호·등록일시·상태를 가진다. 카드에는 카드사·마스킹번호·유효기간, 계좌이체에는 은행코드·계좌식별값이 필요하다.

결제수단
  ├─ 카드결제수단
  ├─ 계좌결제수단
  └─ 가상계좌결제수단

• 유형별 고유 속성과 검증 규칙이 있으므로 서브타입 근거가 있다.
• 한 결제수단 인스턴스는 한 유형에만 해당하므로 배타적이다.
• 허용 유형이 세 가지뿐이고 미분류를 허용하지 않으면 완전하다.
• 판별자 결제수단유형코드와 실제 서브타입 존재가 일치해야 한다.

사례 2: 직원 역할

직원은 동시에 프로젝트관리자와 기술검토자 역할을 수행할 수 있고 역할이 없는 기간도 허용된다. 이는 불완전·포괄 구조다. 역할의 시작·종료일이 중요하다면 단순 서브타입보다 직원역할 관계 엔터티로 역할 이력을 관리하는 편이 더 적합할 수 있다. 즉 다중 소속과 기간 속성이 결합되면 서브타입 오용 여부를 검토한다.

5. 비교와 구분

시험 판단 포인트

• 서브타입 인스턴스는 반드시 슈퍼타입 인스턴스이며 상위 식별자를 상속한다.
• 완전성과 배타성은 서로 다른 축이다. “완전하면 배타적”이라는 결론은 성립하지 않는다.
• 고유 속성·관계·규칙이 없는 단순 분류는 코드 속성으로 충분할 수 있다.
• 서로 다른 분류 기준을 하나의 서브타입 집합에 혼합하지 않는다.
• 논리적 서브타입과 물리 테이블 구현 방식은 동일한 문제가 아니다. 물리 변환은 82600042에서 별도로 다룬다.

자주 틀리는 부분

• 서브타입을 만들면 반드시 테이블도 유형별로 분리된다고 본다.
• 슈퍼타입과 서브타입에 서로 다른 식별자를 부여해 동일 인스턴스의 상속 관계를 끊는다.
• 유형 코드만 있고 고유 규칙이 없는데도 모든 코드값을 서브타입으로 만든다.
• 포괄 서브타입에서 단일 판별자 하나만으로 다중 소속을 표현하려 한다.
• 역할의 기간·상대 대상이 중요한데 정적 서브타입으로만 표현한다.