[DAP 전문가 가이드] 4.3.4 이력 관리 정의

 

 

이력 관리란?

- 데이터는 현재의 프로세스만 처리하고 버리는 것이 아니라 오랜 기간의 데이터를 유지시켜 좀 더 가치 있는 정보를 제공할 수 있는 밑거름이 되도록 해야 한다.

 

이력 관리 대상 선정

사용자 조사

사용자 검증 과정

• 변경 내역을 감시할 필요가 있는가?
• 시간의 경과에 따라 데이터가 변할 수 있는가?
• 시간의 경과에 따라 관계가 변할 수 있는가?
• 과거의 데이터를 조회할 필요가 있는가?
• 과거 버전을 보관할 필요가 있는가?

이력 데이터의 종류

• 발생 이력 데이터
  • 어떤 데이터가 발생할 때마다 이력 정보를 남겨야만 한다면 이력은 발생 이력이라고 볼 수 있다.
  • 이벤트가 발생할 때에만 이력 데이터를 발생하는 방법이 있고, 이력이 발생하지 않더라도 날마다 데이터를 생성하는 경우도 있다.
• 변경 이력 데이터
  • 데이터가 변경될 때마다 변경 전과 후의 차이를 확인해야 한다면 변경 이력을 남길 수 있다.
  • 예를 들어, 고객이 주문을 하고서 주문 정보를 변경하였을 때 이전 주문과 변경된 새로운 주문 정보를 관리하기 위해 변경된 새로운 주문 정보를 이력 정보로 남겨야 한다.
• 진행 이력 데이터
  • 업무의 진행에 따라 이 데이터를 이력 정보로 남겨야만 하는 경우가 있다.
  • 대부분의 주문 업무 처리의 경우 각 단계가 언제 누구에 의해서 처리되고, 현재 단계는 무엇인지에 관한 정보가 필요한 경우가 많다. 이러한 경우의 업무를 처리하기 위해서는 진행 이력이 중요하다.

이력 관리 형태

• 시점 이력 : 데이터의 변경이 발생한 시각만을 관리
• 선분 이력 : 데이터 변경의 시작 시점부터 그 상태의 종료 시점까지 관리

선분 이력 관리 유형

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

인스턴스 이력 관리 예

 

인스턴스 레벨 이력 관리 특징

• 한 번의 액세스로 스냅샷을 참조하는 것이 가능하다. 즉, 한 번의 액세스로 해당 시점의 모든 데이터를 참조하는 것이 가능하다.
• 로그성 데이터를 저장할 목적인 경우 적당한 방법이다.
• 다른 이력 관리 유형에 비해 저장하기가 쉽다.
• 가장 큰 단점 중 하나는 하나 이상의 컬럼에 변경이 발생했을 때 이벤트가 모호해진다는 점이다.
• 만약 이벤트가 자식 정보를 가지게 된다면 매우 치명적이다.
• 이력 관리의 다른 유형들에 비해 저장 공간의 낭비를 초래할 수 있다.
• 특정 순간의 스냅샷만 보는 게 아니라면 처리가 복잡해지는 경향이 있다.
• 변화가 빈번하게 발생하는 상황이라면 고려해 볼 수 있는 유형이다.

 

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

속성 레벨 이력 관리 예

 

속성 레벨 이력 관리 특징

• 변경 이벤트가 매우 분명하게 관리된다. 즉, 실제 어떤 데이터가 변경되었는지가 분명하다.
• 하나의 이력 관리 엔티티에서 다른 엔티티와 통합 이력 관리가 가능하다.
• 변경된 것만 처리하기 때문에 독립적 처리가 가능하다.
• 변화가 발생할 가능성은 매우 낮으면서 이력 관리 대상 속성은 매우 많은 경우에 사용하는 것이 유리하다.
• 특정 속성들에 변화가 집중되는 경우에 해당 속성에 대해서만 이력을 관리할 수 있기 때문에 유리하다.
• 여러 속성에 대한 이력이 필요할 때 많은 Merge가 발생한다.
• 이력 관리의 다른 유형들에 비해서 향후 사용될 데이터 액세스 쿼리에서 조건 검색이 조금 어렵다.
• 변화가 너무 많은 경우에는 적용이 곤란하다.

 

 

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

주제 레벨 이력 관리 예

 

주제 레벨 이력 관리 특징

• 인스턴스 레벨과 속성 레벨의 장점을 모두 수용하는 형태의 이력 관리 형태이다.
• 목적이 분명한 엔티티를 생성함으로써 확장성을 확보할 수 있는 용도로 사용할 수 있다.
• 변경 부분만 처리가 가능하다.
• 다른 엔티티와 통합 이력 관리가 가능하다.
• 속성 레벨의 단점을 해소할 수 있다.
• 전체를 참조할 때 인스턴스 레벨에 비해 Merge가 발생하는 문제점이 존재한다.
• 부문에 따라 변경 정도의 차이가 심한 경우 유리하다.

 

선분 이력 관리용 식별자 확정

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

- 선분 이력을 관리하는 엔티티의 UID를 확정하는 것은 향후에 테이블로 만들어지고 사용될 때의 성능 측면도 고려되어야 한다.

 

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

• 종료점이 미정이므로 NULL
  • 논리적으로는 타당하지만 비교가 불가능
  • 인덱스를 사용하지 못하므로 수행 속도 저하
• 수렴하므로 최대치 부여
  • 아직 종료되지 않았으므로 무한히 계속되는 것으로 간주
  • 최대치 부여(예 : 일자라면 9999/12/31)
  • 가능한 테이블 생성 시 Defaulf Constraints 부여
  • 수행 속도에 유리