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

이력 엔터티를 설계하는 세 번째 방법입니다.

 

첫 번째, 두 번째 방법은 인스턴스를 대상으로 이력 데이터를 관리했지만 세 번째 방법부터는 개별 속성을 대상으로 이력 데이터를 관리합니다.

 

개별 속성의 이력 데이터를 관리하는 방법은 다시 아래와 같이 세 가지로 나눕니다.

 
- 마스터에 해당 속성이 존재해 현재 데이터를 관리하고, 이력 데이터는 별도의 엔터티에서 관리
- 마스터에 해당 속성이 존재하지 않고, 별도의 한 엔터티에서 현재+과거 데이터를 통합해서 관리
- 마스터에 해당 속성이 존재하지 않고, 별도의 두 엔터티에서 현재와 과거 데이터를 개별로 관리

 

[그림1]은 계좌 비밀번호의 이력 데이터를 관리하는 모델입니다. 계좌비밀번호 속성이 마스터 엔터티인 계좌 엔터티에 존재해서 현재 비밀번호를 관리하며, 계좌비밀번호이력 엔터티에서는 과거의 비밀번호만을 관리합니다.

[그림1] 

계좌비밀번호 하나의 속성만 보면 현재 데이터는 계좌 엔터티에서, 과거 데이터는 계좌비밀번호이력 엔터티에서 관리합니다.

 

여기서 계좌 엔터티는 실체 엔터티입니다. 그리고 비밀번호는 계좌의 성격을 나타내므로 계좌의 속성입니다. 계좌를 개설하면 생성되는 기초 속성(Basic Attributes)이므로 계좌 엔터티에 속하게 됩니다.

 

이렇게 이력 데이터를 생각하기 전에 원천 데이터만으로 엔터티를 설계하면 [그림1]의 계좌 엔터티는 당연히 그렇게 되겠죠. 계좌비밀번호 속성이 계좌 엔터티에 속하는 기초 속성이라는 것이 의미가 있습니다.

 

이 상태에서 원천 데이터인 계좌의 비밀번호가 변경됐을 때 이력 데이터를 어떻게 관리하느냐하는 문제입니다. 변경된 비밀번호는 별도의 이력 엔터티에서 관리하는 모델이 [그림1]입니다.

 

비밀번호가 변경되면 변경되기 전 시점의 비밀번호는 계좌비밀번호이력 엔터티에 쌓고, 변경 후의 현재 비밀번호는 계좌 엔터티에 업데이트해서 보관합니다.

 

결과적으로 현재의 비밀번호는 계좌 엔터티에 존재하고(비밀번호는 계좌의 속성이니까요) 과거의 비밀번호는 계좌비밀번호이력 엔터티에 존재합니다(비밀번호 속성 하나만 개별 엔터티에서 이력 관리하기로 했으니까요).

 

계좌비밀번호 속성만 보면 계좌 엔터티는 내역 엔터티고 계좌비밀번호이력 엔터티는 이력 엔터티가 됩니다. 이 설명이 이해가 안 되면 아래 이력과 내역에 대해 설명한 글을 다시 보세요.

 

이력 데이터와 내역 데이터1
이력 데이터와 내역 데이터2

 

계좌비밀번호이력 엔터티에는 과거의 비밀번호만 존재하니 ‘~이력’이라고 엔터티명을 사용합니다. 보통 현재 데이터도 같이 존재하면 엔터티명에서 ‘~이력’을 뺍니다.

 

만약 어떤 이유에서든 비밀번호를 계좌 엔터티에서 관리하지 않고 별도의 엔터티에서 관리하고자 한다면 이어서 설명할 네 번째 방법을 사용하게 됩니다.

 

어떤 이유란 여러 가지가 있을 듯 한데요. 보안을 위해서나, 성능을 향상시키려 별도의 엔터티에서 관리할 수도 있고요. 여러 종류의 비밀번호가 있어 1정규화를 해야 될 수도 있습니다. 네 번째 방법에서 예제로 사용할 것입니다.

 

[그림1]과 같이 속성 하나에 대해 이력 데이터를 관리하고, 현재와 과거 데이터를 별도로 관리하는 방법의 가장 커다란 특징은 엔터티 성격이 명확해진다는 것입니다. 속성 하나에 대해 과거와 현재 데이터를 어떻게 관리할지를 결정하니 엔터티가 명확해집니다.

 

이는 커다란 장점이지만 모델링을 정밀하게 해야 돼서 모델링하기 힘듭니다. 요건 분석부터 정밀하게 하니 시간이 오래 걸립니다. 이것도 장점이긴 하지만 속성 하나 하나 이렇게 한다면 단점이 될 것입니다. 별도로 요건이 존재할만한 주요 속성을 대상으로 하는 것이 좋습니다.

 

이렇게 속성 단위로 관리하는 방법의 단점은 특정 시점의 전체 데이터, 즉 인스턴스로 조회하기 힘들다는 것입니다.

 

장점은 이미 설명드렸듯이 엔터티 성격이 명확해집니다. 이건 모델의 확장성이 좋다는 것을 의미하기도 합니다.

 

중복 데이터가 없고요. 데이터 저장 공간이 절약됩니다. 이력 모델 형상 관리도 그리 어렵지 않습니다(모델링하기 어려울 수는 있지만요). 과거의 비밀번호가 뭐였는지를 조회하기도 좋습니다.

 

이력 엔터티가 별도로 존재해서 이력 데이터를 발생시키는 건 다소 어려울 수 있습니다. 계좌 엔터티에만 비밀번호를 업데이트하고 끝낸다면 문제가 됩니다. 하지만 엔터티를 명확하게 설계했는데 이렇게 한다면 일을 안 한 게 되는 거죠.

현재 비밀번호가 거의 일방적으로 사용되면 바람직한 모델입니다.
 

실무에서는 이렇게 세 번째 방법으로 관리할 요건(속성)을 도출하기가 어려운데요. 결정해서 선택하는 것이 어려운데 이번 이력 엔터티 시리즈가 조금의 도움이라도 됐으면 좋겠습니다.

 

10가지를 명확히 알고, 장단점을 알고, 상황이 발생했을 때 많이 고민하고, 실무에서 다양하게 경험한다면 선택하기 수월해질 것입니다.