이력 관리
데이터는 현재의 프로세스만 처리하고 버리는 것이 아니라 오랜 기간의 데이터를 유지시켜 더 가치있는 정보를 제공할 수 있는 밑거름이 되어야 함
이력 관리가 필요할 때
조사 및 검증 과정을 통해 이력 관리 여부를 결정한다.
- 변경 내역을 감시할 필요가 있는가?
- 시간의 경과에 따라 데이터가 변할 수 있는가?
- 시간의 경과에 따라 관계가 변할 수 있는가?
- 과거의 데이터를 조회할 수 있는가?
- 과거 버전을 보관할 필요가 있는가?
이력 데이터의 종류
-
발생 이력 데이터
⇒ 어떤 데이터가 발생할 때마다 이력 정보를 남겨야 할때
예) 스포츠 데이터 (실시간 중계)
-
변경 이력 데이터
⇒ 데이터가 변경될 때마다 변경 전과 후의 차이를 확인해야 할때
예) 리뷰 수정 전 후를 비교하고 싶을 때
-
진행 이력 데이터
⇒ 업무의 진행에 따라 데이터의 이력 정보를 남겨야 할 때
예) 택배
이력 테이블 설계
테이블과 이력 함께 관리
해당 레코드에 수정 요소가 발생하면 새로운 레코드를 만들고 이전 레코드를 이력으로 취급
- 하나의 엔티티에 원천 데이터와 변경 데이터를 함께 관리
- 원천데이터와 변경 데이터를 함께 관리하기 때문에 테이블의 성격이 불명확
- 데이터 모델을 관리하기 좋음
- 원천 데이터와 변경 데이터를 같이 조회하는 경우가 많을 때 유리
테이블과 이력 분리
대상 테이블에서 이력을 남길 속성을 갖는 테이블을 새로 생성하고 수정 요소가 발생할 때마다 대상 테이블의 속성을 복사하여 이력 테이블의 레코드를 저장하고 대상 테이블을 업데이트 함
- 이력 테이블을 별도 테이블로 설계하는 방법
- 엔티티의 속성 중에서 하나라도 변경되면 변경 당시의 엔티티를 스냅샷 형태로 이력 엔티티에 생성
- 변경된 속성은 원천 엔티티에 갱신
- 원천 엔티티와 변경 엔티티가 같이 조회되는 경우가 드물 때 유리
- 원천 엔티티의 하위 엔티티가 많이 존재할 경우 별도의 테이블에서 관리하는 것이 유리
이력 관리 형태
이력관리 없음
- 하드 삭제
- 일반적인 '삭제' (SQL DELETE)
- 이력관리를 하지 않고 실제 레코드를 삭제하는 방식
- 소프트 삭제의 반대 개념으로 '하드'를 붙인 것
장점
- 현재 시점의 데이터를 쉽게 조회 할 수 있다.
- 빠르다
단점
이력관리 있음
- 소프트 삭제
- 일반적인 삭제 대신 컬럼을 갱신하는 방식 (SQL UPDATE)
- 데이터를 실제로 삭제하지 않고 삭제여부를 나타내는 컬럼을 사용하는 방식
- 복구하거나 예전 기록을 확인하고자 할 때 간편함
- 항상 상태(removed)를 점검해야 하므로 불편함
- 느리다
점이력
- 변경 시점(시작시점) 만 관리
- 데이터의 변경이 발생한 시각만을 관리
- 데이터가 발생한 순간의 상태만 알 수 있음
장점
단점
선분이력
- 시작 시점과 종료 시점을 모두 관리
- 과거와 현재(미래) 데이터를 함께 관리할 때 적용
- 특정 시점의 데이터를 조회하고 싶을 때
- 레코드의 상태 변경 이력을 확인하고 싶을 때
장점
- 넓은 범위 혹은 특정 키의 과거 시점 데이터를 조회하기 용이
- 과거 특정 시점의 조회가 용이
단점
-
속성 추가에 따른 추가 공간 사용
-
데이터 정합성
-
사용자가 선분이력에 익숙해야 함
특징
- 어떤 점이나 반드시 하나의 선분을 통과한다.
- 선분이 아무리 길어도 레코드는 하나이다.
- 선분 이력을 관리하기 위한 종료일자 속성은 추출 속성이므로 생략 가능하다.
고려사항
- 모든 변경 데이터에 대한 관리를 선분 이력으로 해야 할 필요 없음
- 채택 조건
- 넓은 범위의 과거 데이터 조회
- 과거 특정 시점의 데이터를 자주 조회 (현재 데이터만 조회 한다면 선분 이력 불필요)
- 채택 단계
- 이력 요건을 검토하는 단계(개념 모델링 단계에서 선분 이력 적용 여부 결정)