데이터 이력 관리

Dan.kimhaejun·2021년 3월 25일
0

Development

목록 보기
1/3

이력 관리

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

  • 현재의 순간은 점
  • 이력은 선분

이력 관리가 필요할 때

조사 및 검증 과정을 통해 이력 관리 여부를 결정한다.

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

이력 데이터의 종류

  • 발생 이력 데이터

    ⇒ 어떤 데이터가 발생할 때마다 이력 정보를 남겨야 할때

    예) 스포츠 데이터 (실시간 중계)

  • 변경 이력 데이터

    ⇒ 데이터가 변경될 때마다 변경 전과 후의 차이를 확인해야 할때

    예) 리뷰 수정 전 후를 비교하고 싶을 때

  • 진행 이력 데이터

    ⇒ 업무의 진행에 따라 데이터의 이력 정보를 남겨야 할 때

    예) 택배

이력 테이블 설계

테이블과 이력 함께 관리

해당 레코드에 수정 요소가 발생하면 새로운 레코드를 만들고 이전 레코드를 이력으로 취급

  • 하나의 엔티티에 원천 데이터와 변경 데이터를 함께 관리
  • 원천데이터와 변경 데이터를 함께 관리하기 때문에 테이블의 성격이 불명확
  • 데이터 모델을 관리하기 좋음
  • 원천 데이터와 변경 데이터를 같이 조회하는 경우가 많을 때 유리

테이블과 이력 분리

대상 테이블에서 이력을 남길 속성을 갖는 테이블을 새로 생성하고 수정 요소가 발생할 때마다 대상 테이블의 속성을 복사하여 이력 테이블의 레코드를 저장하고 대상 테이블을 업데이트 함

  • 이력 테이블을 별도 테이블로 설계하는 방법
  • 엔티티의 속성 중에서 하나라도 변경되면 변경 당시의 엔티티를 스냅샷 형태로 이력 엔티티에 생성
  • 변경된 속성은 원천 엔티티에 갱신
  • 원천 엔티티와 변경 엔티티가 같이 조회되는 경우가 드물 때 유리
  • 원천 엔티티의 하위 엔티티가 많이 존재할 경우 별도의 테이블에서 관리하는 것이 유리

이력 관리 형태

이력관리 없음

  • 하드 삭제
  • 일반적인 '삭제' (SQL DELETE)
  • 이력관리를 하지 않고 실제 레코드를 삭제하는 방식
  • 소프트 삭제의 반대 개념으로 '하드'를 붙인 것

장점

  • 현재 시점의 데이터를 쉽게 조회 할 수 있다.
  • 빠르다

단점

  • 이력을 알 수 없다.

이력관리 있음

  • 소프트 삭제
  • 일반적인 삭제 대신 컬럼을 갱신하는 방식 (SQL UPDATE)
  • 데이터를 실제로 삭제하지 않고 삭제여부를 나타내는 컬럼을 사용하는 방식
  • 복구하거나 예전 기록을 확인하고자 할 때 간편함
  • 항상 상태(removed)를 점검해야 하므로 불편함
  • 느리다

점이력

  • 변경 시점(시작시점) 만 관리
  • 데이터의 변경이 발생한 시각만을 관리
  • 데이터가 발생한 순간의 상태만 알 수 있음

장점

  • 데이터 관리에 용이

    ⇒ 새로운 데이터 생성시 문제 발생 가능성이 적음 (이전 데이터 고려 안해도 됨

단점

  • 특정 조건의 데이터 조회가 어려움

    ⇒ 현재 등급은 "C", 과거 2019-05-05 등급은?

    ⇒ 등록일자가 2019-05-05 이전의 일자중에서 가장 최근(큰) 날짜를 검색 → 비효율적임

선분이력

  • 시작 시점과 종료 시점을 모두 관리
  • 과거와 현재(미래) 데이터를 함께 관리할 때 적용
  • 특정 시점의 데이터를 조회하고 싶을 때
  • 레코드의 상태 변경 이력을 확인하고 싶을 때

장점

  • 넓은 범위 혹은 특정 키의 과거 시점 데이터를 조회하기 용이
  • 과거 특정 시점의 조회가 용이

단점

  • 속성 추가에 따른 추가 공간 사용

  • 데이터 정합성

    • 시작일자와 종료일자가 선분이 되어야 하므로 데이터가 잘못 관리된 가능성 있음

      ⇒ 변경일자 속성만 존재하는 점 이력 릴레이션은 정합성 문제 없음

  • 사용자가 선분이력에 익숙해야 함

특징

  • 어떤 점이나 반드시 하나의 선분을 통과한다.
  • 선분이 아무리 길어도 레코드는 하나이다.
  • 선분 이력을 관리하기 위한 종료일자 속성은 추출 속성이므로 생략 가능하다.

고려사항

  • 모든 변경 데이터에 대한 관리를 선분 이력으로 해야 할 필요 없음
  • 채택 조건
    • 넓은 범위의 과거 데이터 조회
    • 과거 특정 시점의 데이터를 자주 조회 (현재 데이터만 조회 한다면 선분 이력 불필요)
  • 채택 단계
    • 이력 요건을 검토하는 단계(개념 모델링 단계에서 선분 이력 적용 여부 결정)
profile
제가 겪은 이슈에 대해서 정리합니다. 기억보다는 기록이 더 낫다고 생각합니다.

0개의 댓글