이력 엔터티를 설계하는 10가지 방법 – 일곱 번째

일곱 번째 방법은 여섯 번째 방법의 확장입니다.

 

엔터티 한 개만 관리하는 여섯 번째 방법에서 두 개의 엔터티로 확장한 모델이 [그림1] 입니다.

[그림1]

 

고객계좌통합번호 속성은 배타 관계(계좌와 고객 엔터티)를 관리하는 속성입니다. 엔터티번호 속성과 함께 사용해야 어떤 엔터티의 식별번호인지를 알 수 있습니다(파란 속성은 같이 사용하는 쌍을 의미).

 

계좌 엔터티만이 아니라 다른 엔터티의 이력 데이터도 관리하므로 포괄적으로 속성통합이력 엔터티라고 붙이고요([그림1]처럼 단 두 개의 엔터티라면 ‘고객/계좌속성이력’도 좋음).

 

‘이력엔터티’라는 엔터티에서는 이력 데이터를 관리하는 대상 엔터티를 관리합니다.

 

이 방법은 여섯 번째 방법의 단점은 모두 가지고 있으며 더 유연하기 때문에 업무를 파악하기 더욱 어려워진다는 단점이 추가되지만, 엔터티별로 속성 이력 엔터티(계좌이력·고객이력 엔터티)가 추가되는 것보다 효과적이라고 생각합니다. 간혹 작정하고 다소 어려운 모델을 사용해야 할 때가 있습니다.

 

최대한 유연하게 설계할 수 있다는 것이 최대의 장점입니다.

 

이력 데이터를 종테이블(Vertical Table)로 관리하는 대상 엔터티를 알 수 있다는 점도 장점이고요. 엔터티 개수가 줄어든다는 점도 장점입니다.

 

너무 많은 엔터티의 이력 데이터를 통합하는 것보다는 성격이 유사하거나, 같은 영역에 있는 몇 개의 엔터티를 통합하면 좋습니다.

 

이 방법은 이력 데이터를 관리하는 대상 엔터티의 주 식별자를 주의해야 합니다. 배타 관계를 관리하는 방법과 같습니다.

 

[그림1]은 주 식별자가 다른 대표적인 엔터티를 관리하는 예제로 고객계좌통합번호 속성 사용에 주의해야 하고요.

 

슈퍼타입, 서브타입을 이력 관리할 때는 주 식별자가 같아 [그림2]와 같이 배타 속성(고객번호)이 단순해집니다.

[그림2]

 

[그림1]과 [그림2]는 비교적 수월한데요.

 

대상 엔터티의 주 식별자가 다양(성격과 개수)할 때가 문제입니다.

 

[그림3]은 이 문제를 해결할 수 있는 매우 유연한 모델입니다.

[그림3]

 

이력 데이터를 관리하는 대상이 계좌·고객·고객주소 엔터티이고요. 각각 주 식별자(빨간 속성) 개수가 다릅니다.

 

통합 이력을 관리하는 엔터티(속성통합이력)는 배타 관계가 발생하고, 세 개의 속성(통합이력식별속성·통합이력식별속성2·통합이력식별속성3)에서 대상 엔터티의 주 식별자 값을 관리합니다.

 

주 식별자가 하나인 고객 엔터티의 속성이 변경되면 통합이력식별속성2·통합이력식별속성3 속성에 해당되는 값은 없으므로 널(Null) 허용입니다(속성 왼쪽 동그라미 표시).

 

[그림3]과 같이 하나의 엔터티에서 다양한 엔터티의 이력 데이터를 관리하는 요건을 경험한 적은 없습니다.

 

배타 관계 때문에 이와 유사한 모델이 발생한 적은 있는데요. 이에 대해서는 나중에 별도로 소개하겠습니다.

 

이상으로 이력 데이터를 종테이블(Vertical Table)로 관리하는 방법을 설명드렸는데요.

 

여섯 번째와 일곱 번째 모델이 유용할 때가 분명 있습니다. 이력 데이터를 조인해서 조회하는 게 아니고 필요 시 단지 추적 용도로 사용하면 효과적입니다.

 

하지만 분석하기 싫어서, 귀찮아서 이 모델을 선택한다면 안 될 것입니다. 특별히 모델러는 주의해야 합니다.