[Data Modeling] : 이력 관리 정의

이력 관리

현재는 단지 하나의 점에 불과하지만 과거란 엄청난 갯수의 점이 모여 있는 형상입니다. 이력은 선분이고 현재의 순간은 점이므로 선분을 관리해야 합니다.

 

이력 관리를 하려면 비용이 들어갑니다.

 

사용자 조사를 잘 하고 협의해서 합니다.

 

사용자 조사

데이터의 이력을 관리한다는 것은 많은 비용이 들어가므로 사용자의 검증 과정이 필요합니다.

- 변경 내역을 감시할 필요가 있는가?

- 시간의 경과에 따라 데이터가 변할 수 있는가?

- 시간의 경과에 따라 관계가 변할 수 있는가?

- 과거의 데이터를 조회할 필요가 있는가?

- 과거 버전을 보관할 필요가 있는가?

 

이력 데이터의 종류

발생 이력 데이터

- 어떤 데이터가 발생할 때마다 이력 정보를 남기는 것 입니다. 

- 예를 들면 고객의 접속 기록 같은 것이 발생 이력 데이터에 해당합니다.

 

변경 이력 데이터

- 데이터가 변경될 때마다 변경 전과 후의 차이를 확인하기 위해 남기는 이력입니다.

- 예를 들면 주문 정보 변경으 변경 이력 데이터에 해당합니다.

 

진행 이력 데이터

- 업무의 진행에 따라 이 데이터를 이력 정보로 남기는 이력입니다.

- 예를 들면 주문 정보 변경이 진행 이력 데이터에 해당합니다.

 

 

EVENT 발생 시 마다 생성

- Event가 발생할 때마다 사진을 찍어 두어야 이력을 관리할 수 있는가?

- 자주 사용합니다.

 

DAILY 마다 생성

- 아무 변화가 없는 경우도 데이터를 생성합니다. 그러나 완벽한 이력 관리는 불가능합니다.

 

이력 관리 형태

시점(Event) 이력

- 데이터의 변경이 발생한 시각만 관리합니다.

- 로그성 데이터로 이력을 쌓아두고자 할 경우(임의 시점에 대한 조회 요구사항이 없음)

- 이력 데이터를 저장하고 이해하기에는 용이하지만 활용할때 비효율이 많이 나타납니다.

- 과거 임의의 시점에서 이력을 재현하기에 비효율이 많이 발생합니다.

- 특정 통화의 환율이 변경되면 어느 시점에 얼마의 값으로 변경되었다라는 정보를 관리합니다.

- 이런 방식은 특정한 시점의 데이터를 추출하고자 할 경우에 불필요한 작업을 수행하게 됩니다.

 

선분 이력

- 데이터 변경의 시작 시점부터 그 상태의 종료 시점까지 관리합니다. 

- 이력관리 대상 속성들이 의미하는 정보가 일정 시점의 정보만을 나타내는 것이 아니라 일정 기간동안 해당 정보가 유효하다는 의미입니다.

- 임의의 시점의 데이터를 찾고자 하는 요구가 있는 경우에 유용합니다.

- 이력 데이터를 저장하고 이해하는데 있어서 점이력 방식보다 불리하지만, 과거 임의의 시점에서의 이력을 재현하고 활용하는데 매우 효율적입니다.

- 각 통화의 특정 기간 동안 유효한 환율을 관리합니다.

 

선분 이력에서 식별자 결정 시 고려사항

선분 이력을 관리하는 엔터티의 UID를 확정하는 것은 향후 테이블로 만들어지고 사용될 떄의 성능 측면도 고려되어야 합니다. 의미적으로 Unique를 점검할 수 있는 조치가 필요합니다.

 

선분 이력에서 종료점 처리 시 주의사항

종료점이 미정이므로 NULL

- 논리적으로는 타당하지만 비교가 불가능합니다.

- 인덱스를 사용하지 못하므로 수행 속도가 저하됩니다.

 

수렴하므로 최대치 부여

- 아직 종료되지 않았으므로 무한히 계속되는 것으로 간주합니다.

- 최대치를 부여합니다. ( 예를 들어 일자를 부여한다고 하면 9999/12/31 이렇게 최대치를 줍니다.)

- 가능한 TABLE creation 시 Default constraints를 부여합니다.

- 수행 속도에 유리합니다.

 

이력 관리 유형

인스턴스 레벨 이력 관리

하나의 인스턴스의 어떤 변경이라도 발생하면 전체 인스턴스를 새롭게 생성하는 방식의 이력 관리 유형입니다.

- 한 번의 액세스로 스냅샷을 참조하는 것이 가능합니다.

- 로그성 데이터를 저장할 목적인 경우 적당한 방법입니다.

- 다른 이력 관리 유형에 비해서 저장하기가 쉽습니다.

- 가장 큰 담점은 하나 이상의 컬럼에 변경이 발생했을 때 이벤트가 모호해진다는 점이 있습니다. 만약 이벤트가 자식 정보를 가지게 된다면 매우 치명적이게 됩니다.

- 이력 관리의 다른 유형들에 비해 저장 공간의 낭비를 초래할 수 있습니다.

- 실제 어떤 데이터가 변경된 것인지를 찾기 위해서는 과거의 데이터를 Merge해서 비교를 해야만 가능할 수 있습니다.

- 특정 순간의 스냅샷만 보는 게 아니라면 처리가 복잡해지는 경향이 있습니다.

- 변화가 빈번하게 발생하는 상황이라면 고려해 볼 수 있는 유형입니다.

 

속성 레벨 이력 관리

이력을 관리할 대상 속성에서 변화가 생길 때만 이력을 생성하는 방식입니다.

- 실제 어떤 데이터가 변경되었는지가 분명합니다.

- 하나의 이력 관리 엔터티에서 다른 엔터티와  통합 이력 관리가 가능합니다.

- 변경된 것만 처리하기 때문에 독립적 처리가 가능합니다.

- 변화 발생 가능성은 매우 낮으면서 대상 속성은 매우 많은 경우에 사용하는 것이 유리합니다.

- 특정 속성들에 변화가 집중되는 경우에 해당 속성에 대해서만 이력을 관리할 수 있기 때문에 유리합니다.

- 여러 속성들에 대한 이력이 필요할 때 많은 Merge 가 발생합니다.

- 이력 관리의 다른 유형들의 비해서 향후 사용도리 데이터 액세스 쿼리에서 조건 검색이 조금 어렵습니다.

- 변화가 너무 많은 경우에는 적용이 곤란합니다.

 

주제 레벨 이력 관리

내용이 유사하거나 연동될 확률이 높은 것 별로 인스턴스 레벨 이력을 관리하는 방법입니다.

- 인스턴스 레벨과 속성 레벨 장점을 모두 수용합니다.

- 목적이 분명한 엔터티를 생성함으로써 확장성을 확보할 수 있는 용도로 사용합니다.

- 변경 부분만 처리가 가능합니다. ( 독립적 처리가 가능합니다. )

- 다른 엔터티와 통합 이력 관리가 가능합니다.

- 속성 레벨의 단점을 해소합니다.

- 전체를 참조할 때 인스턴스 레벨에 비해 Merge가 발생하는 문제점이 존재합니다.

- 부문에 따라 변경 정도의 차이가 심한 경우 유리합니다.