배타 서브타입 설계

서브타입을 설계할 때는 특정 시점을 기준으로 설계하기 때문에 변경이력 데이터를 포함시키지 않고 현재 시점의 데이터로 판단한다.

 

서브타입이 배타 서브타입인지 중복 서브타입인지는 특정 시점을 기준으로 판단한다. 특정 시점에 어느 하나의 서브타입에만 속하는지(배타 서브타입) 여러 서브타입에 속할 수 있는지(중복 서브타입)에 따라 서브타입의 유형이 정해진다.

 

따라서 과거 데이터인 변경이력 데이터는 제외하고 현재 시점을 기준으로 판단해서 서브타입 유형을 설계한다.

 

데이터 성격이나 업무 요건은 서브타입 간에 중복 데이터가 없어야 하는데 변경이력 데이터로 인해 중복된 것처럼 보이는 경우가 있기 때문에 주의해야 한다.

 

사원은 정규직이거나 임시직이어야 한다는 업무 요건이 있다면, 아래 모델처럼 배타 서브타입으로 설계해야 한다.

 

[그림 사원-배타서브타입]

 

하지만 [그림 사원릴레이션] 릴레이션과 같이 사원유형코드 속성 값이 변했을 때도 같은 릴레이션에서 관리하면, 즉 변경이력 데이터를 같이 관리하면 서브타입 모델에 왜곡이 생길 수 있다.

 

[사원]

#사원번호	사원명	주민등록번호	입사일자	사원유형코드
12345	홍길동	1234567890123	2021-07-07	정규직
67890	이길동	6789012345678	2023-01-02	정규직
23456	홍길동	1234567890123	2028-03-05	임시직

[그림 사원릴레이션]

 

사원 엔터티의 릴레이션이 위와 같을 때, 데이터만으로 판단하면 ‘홍길동’은 정규직과 임시직 인스턴스가 동시에 존재하기 때문에 배타 서브타입이 아니다.

 

하지만 첫 번째 인스턴스는 변경이력 성격의 데이터다. 과거에 정규직으로 근무했던 기록으로 현재 시점에서는 죽어 있는 데이터다. ‘홍길동’에 대해 현재 시점에 유효한 데이터는 세 번째 인스턴스뿐이다.

 

이력 데이터인 첫 번째 인스턴스가 없다면, 업무 요건을 그대로 반영한 배타 서브타입이 된다. 즉 데이터를 제대로 해석하면 배타 서브타입이 된다.

 

[그림 사원릴레이션] 릴레이션은 변경이력 데이터 때문에 어떤 서브타입인지 혼란스러울 수 있는 릴레이션이다. 업무 요건에 따라서 ‘홍길동’이 동시에 정규직이면서 임시직인 상태는 없기 때문에 배타 서브타입이 되도록 설계해야 한다. 그렇게 하려면 아래 릴레이션처럼 변경이력 데이터는 별도의 릴레이션에서 관리하는 것이 명확하다.

 

[사원]

#사원번호	사원명	주민등록번호	입사일자	사원유형코드
67890	이길동	6789012345678	2023-01-02	정규직
12345	홍길동	1234567890123	2028-03-05	임시직

[사원이력]

#사원번호	#변경일자	사원명	주민등록번호	입사일자	사원유형코드
12345	2028-03-05	홍길동	1234567890123	2021-07-07	정규직

[그림 사원릴레이션2]

 

사원 릴레이션의 서브타입은 배타 서브타입이다.

 

위와 같이 변경이력 데이터를 분리해서 설계하지 못하는 상황이라도, 서브타입이 배타 서브타입인지를 설계하는 기준은 특정 시점이기 때문에 현재 시점에서 업무적으로 중복된 데이터가 없어야 한다면 [그림 사원-배타서브타입] 모델과 같이 배타 서브타입으로 표현한다.

 

배타 서브타입인지 중복 서브타입인지를 판단하는 기준은 특정 시점이며, 변경이력 데이터 때문에 중복 서브타입처럼 보일 수 있다는 것을 주의해서 설계에 반영해야 한다.