DAsP - 논리 데이터 모델링 [이력 관리 정의]

이력 관리 정의

 

1.   이력 관리란?

데이터는 현재의 프로세스만 처리하고 버리는 것이 아니라 마치 후손에게 물려주어야 할 귀중한 문화유산처럼 오랜 기간의 데이터를 유지시켜 좀 더 가치있는 정보를 제공할 수 있는 밑거름이 되도록 해야 한다.

이력은 선분이고 현재의 순간은 점이므로 선분 – 그것도 과거에 비해 현저하게 오랜 기간 – 을 관리해야 한다는 것은 결코 함부로 결정해서는 안된다.

n  어제의 환율은 얼마인가?

n  오늘 아침의 환율은 얼마인가?

n  환율의 변화에 대한 추이 분석을 하고자 한다.

 

2.   이력 관리 대상 선정

가.  사용자 조사

사용자의 검증 과정

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

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

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

n  과거의 데이터를 조회할 수 있는가?

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

 

나.  이력 데이터의 종류

1)     발생 이력(Occurrence History) 데이터

어떤 데이터가 발생할 때마다 이력 정보를 남겨야 한다면 이력은 발생 이력이라고 볼 수 있다.

                     

2)     변경 이력(Modification History) 데이터

데이터가 변경될 때마다 변경 전과 후의 차이를 확인해야 한다면 변경 이력을 남길 수 있다.

3)     진행 이력(Progress History) 데이터

업무의 진행에 따라 이 데이터를 이력 정보로 남겨야만 하는 경우가 있다.

 

다.  이력 관리 형태

n  시점 이력: 데이터의 변경이 발생한 시각만을 관리

n  선분 이력: 데이터 변경의 시작 시점부터 그 상태의 종료 시점까지 관리

 

1)     시점 이력

가)   시점 이력 활용 예

SELECT 환율

FROM 환율 변동 이력

WHERE 발생시각 = (SELECT MAX(발생시각)

                        FROM 환율 변동 이력

                        WHERE 발생 시각 <= ‘20020521’ AND 통화_ID= ‘USD’)

AND 통화_ID = ‘USD’

2)     선분 이력

가)   선분 이력 활용 예

SELECT 환율

FROM 환율 변동 이력

WHERE 발생 시각 BETWEEN 시작 시각 AND 종료 시각
AND 통화_ID = ‘USD’

나)   선분 이력 의미

n  17을 가진 선분으로 = 로 찾을 수는 없다.

n  그러나 17이 통과하는 선분을 찾아보자

n  어떤 점이나 반드시 하나의 선분을 통과한다.

n  선분이 아무리 길어도 레코드는 하나이다.

n  부등식 표현: 시작점 <= 17 <= 종료점

n  연산자 표현: 17 BETWEEN 시작점 AND 종료점

 

라.  선분 이력 관리 유형

1)     인스턴스 레벨 이력 관리

n  한 번의 액세스로 스냅샷을 참조하는 것이 가능하다. 즉, 한 번의 액세스로 해당 시점의 모든 데이터를 참조하는 것이 가능하다.

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

n  다른 이력 관리 유형에 비해 저장하기가 쉽다.

n  가장 큰 단점 중 하나는 하나 이상의 칼럼에 변경이 발생했을 때 이벤트가 모호해진다는 점이다.

n  만약 이벤트가 자식 정보를 가지게 된다면 매우 치명적이다. 즉, 각각의 변경 이벤트가 하위의 데이터(엔티티)를 가지게 된다면 해당 이벤트를 찾기가 매우 어려워진다.

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

n  실제 어떤 데이터가 변경된 것인지를 찾기 위해서는(즉, 이벤트를 찾기 위해서는) 과거의 데이터를 Merge해서 비교를 해야만 가능할 수 있다.

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

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

2)     속성 레벨 이력 관리

n  변경 이벤트가 매우 분명하게 관리된다. 즉, 실제 어떤 데이터가 변경되었는지가 분명하다.

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

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

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

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

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

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

n  변화가 너무 많은 경우에는 적용이 불가능하다.

3)     주제 레벨 이력 관리

n  인스턴스 레벨과 속성 레벨의 장점을 모두 수용하는 형태의 이력 관리 형태이다.

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

n  변경 부분만 처리가 가능하다(독립적 처리 가능).

n  다른 엔티티와 통합 이력 관리가 가능하다.

n  속성 레벨의 단점을 해소할 수 있다.

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

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

 

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

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

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

 

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

1)     종료점이 미정이므로 NULL

n  논리적으로는 타당하지만 비교가 불가능

n  인덱스를 사용하지 못하므로 수행 속도 저하

2)     수렴하므로 최대치 부여

n  아직 종료되지 않았으므로 무한히 계속되는 것으로 간주

n  최대치 부여 (예; 일자라면 9999/12/31)

n  가능한 TABLE creation 시 Default constraints 부여

n  수행 속도에 유리