본문 바로가기

데이터 Story/모델링 이론

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

여섯 번째 방법은 모델링하기 가장 쉬운 방법입니다. 적어도 표면적으로는요.

 

변경된 모든 속성의 데이터를 하나의 엔터티에서 관리하는 방법입니다. 흔히 종테이블(Vertical Table)이라고 하는데요. 속성 단위로 관리하기 때문에 이력 관리 대상 속성을 코드화해서 관리하는 것이 특징입니다.

 

[그림1] 계좌 엔터티 속성 중에서 역할을 의미하는 계좌관리사원번호 속성은 별도의 엔터티에서 이력 데이터를 관리하기로 하고요(역할에 대해서는 이전 글을 참조 하세요. http://dataprofessional.tistory.com/62).

 


[그림1]

 

그리고 나머지 속성은 이번에 설명하는 방법인 [그림2]와 같이 관리합니다.


 

[계좌이력속성]

#속성코드

속성명

100

계좌명

110

계좌비밀번호

 

[계좌이력]

#계좌번호

#속성코드

#변경일자

속성값

12345678

110

2021-05-05

홍길동

12345678

110

2021-07-07

김길동

 

[그림2]

 

계좌이력속성 엔터티는 계좌 속성 중에서 이력 데이터를 관리할 속성을 코드로 관리하는 엔터티입니다.

 

계좌의 이력 데이터를 관리하기 위해서는 먼저 계좌이력속성 엔터티에 데이터(속성코드와 속성명)를 생성해야 합니다. 속성명은 계좌 엔터티의 속성을 의미하므로 계좌 엔터티의 속성 이름과 일치해야 합니다. 일치하지 않으면 치명적이지는 않더라도 사용에 혼란이 생깁니다.

 

따라서 지금까지 설명한 다른 방법과는 다르게 계좌이력속성 엔터티에 대한 관리 부담이 부가적으로 생깁니다. 기준 데이터를 먼저 등록해야 하므로 번거로울 수 있죠.

 

이런 사전 작업 때문에 다른 방법보다 이력 데이터를 발생하기 어렵습니다.

 

가장 큰 문제점은 보통 계좌이력 엔터티에서 관리할 속성이 명확하지 않다는 것입니다.

 

계좌관리사원번호 속성의 이력 데이터는 별도의 엔터티로 설계했으니 결국 [그림3] 모델과 같은데 어떤 속성을 계좌이력 엔터티에서 관리하는지 모델로는 명확하지 않습니다(실제로 계좌 엔터티에는 속성이 많기 때문에 혼란스러워집니다).



[그림3]

 

계좌이력 엔터티와 같은 종테이블은 전부가 되지 않고 예외가 생기면 분별하기 어려워집니다. 계좌관리사원번호 속성까지 잘못 관리하는 것을 실무에서 종종 목격합니다.

 

이런 중복은 속성 하나를 중복시키는 것보다 문제가 더 심각해질 수 있습니다. 결국은 계좌이력 엔터티만 사용하기 때문에 계좌관리사원이력 엔터티가 소용이 없어지게 되죠.

 

또 다른 문제는 속성별로 상세한 업무 파악이 필요하지 않아 엔터티의 성격(정확하게는 속성의 성격)이 모호해진다는 것입니다.

 

그리고 인스턴스 전체를 쌓는 게 아니니 특정 시점의 모든 속성 데이터를 조회하기는 어렵습니다.

 

이 방법의 최대 장점(거의 유일한 장점)은 모델을 형상 관리할 필요가 없다는 점입니다. 그만큼 유연한 구조의 모델입니다.

 

그리고 변경된 개별 속성을 조회하기는 쉬운 편이고요. 물론 계좌이력속성 엔터티와의 관계 때문에 속성 단위로 이력 데이터를 설계하는 방법보다는 쉽지 않고요.

 

사용하기 편하다는 장점(업무를 심도 있게 분석하지 않는다는 단점이기도 함)이 있어 실무에서 자주 사용합니다.

 

하지만 업무를 하려 직접 사용하기보다는 문제가 발생했을 때를 대비해 과거의 데이터를 추적하는 용도로 사용하면 좋습니다.

 

그밖에 장점은 데이터 저장 공간이 효율적이고요.

 

데이터 중복이 없습니다. 어떤 값에서 어떤 값으로 바뀌었는지를 알려고 계좌이력 엔터티에 이전속성값 속성을 사용하는데 중복값이라 바람직하지 않습니다.

 

이보다 더한 중복도 있는데요. 계좌이력 엔터티에 변경 안 된 속성을 같이 관리하기도 합니다. 또는 [그림2] 모델로도 관리하고 스냅샷 모델로도 이중 관리하기도 합니다. 이는 두 가지 종류의 화면(요건)이 있다는 것을 의미합니다. [그림2] 모델만으로도 충분합니다.

 

어떤 방식이든 중복 데이터는 바람직하지 않습니다. 반드시 심각한 성능 문제를 해결하고자 할 때만 중복 데이터를 사용해야 합니다.

 

만약 이력 데이터에 대한 기본적인 요건이 확정되지 않았다면 이력 관리 모델을 반영하지 않고 유보해 놓는 것이 바람직합니다. 일단 [그림2]와 같이 설계하는 경향이 있는데 확정되지 않아서 가장 일반적이고 유연한 모델을 선택하는 것은 바람직하지 않습니다.

 

유연하므로 아무 때나 적용할 수 있다는 것은 그만큼 주의해서 적절한 때를 찾아야 한다는 것을 의미합니다.