선분이력

• 시작 시점과 종료 시점을 관리
• 과거 특정 시점의 데이터를 조회하는 요건이 많을 때 조회 성능을 고려한 방법

점 이력

점 이력 릴레이션

점 이력 참조

• 현재(2020-02-10) 고객등급은 'C', 과거(2019-05-01) 등급은?
  • 등록일자가 2019-05-01 이전인 일자 중에서 가장 최근(큰) 날짜를 탐색 (서브쿼리 + MAX 함수) → 비효율

• 모든 일자에 해당하는 데이터를 생성하는 방법
  • 복잡한 쿼리 해소, 하지만 많은 양의 데이터 발생 과 부가적인 업무 발생
  • 초까지 포함된 과거의 특정 시각을 기준으로 조회 불가

• OLTP 에서 점 이력 릴레이션도 대개 문제가 없음
  • 광범위한 범위를 조회 하면 성능 문제 발생 (요건의 존재여부, 정당성, 사용빈도, 중요도 검토)

선분 이력

선분 이력 릴레이션

선분 이력 참조

• 위 처럼 하나의 인스턴스가 세 번 수정되었을 때 세 개의 시작 시점과 종료 시점을 연결하면 하나의 선분이 됨
• 현재 데이터는 종료 시점이 없어서(몰라서) 9999-12-31 과 같은 약속된 데이터를 사용(NULL 이 맞지만 성능을 고려)
• 유효종료일자를 별도로 관리하는 이유는 조회시 BETWEEN 구문을 사용해 조회 쿼리 효율성을 높이기 위함
• 하나의 엔터티에서 과거와 현재(미래) 데이터를 같이 관리할 때 적용 된다
• 유효종료일자는 로직으로 관리 한다 (추출 속성)
  • 새로운 인스턴스의 유효시작일자를 참조해 이전 인스턴스의 유효종료일자를 계산해 업데이트

2019.07.06 당시 릴레이션

2019.07.07 당시 릴레이션 (고객번호 100 인 고객의 등급이 'C' 로 변경)

유효종료일자 댓가

• 속성 추가에 따른 추가 공간 사용
• 로직에 의해 계산된 데이터를 저장/변경
• 데이터 정합성
  • 시작일자와 종료일자가 선분이 되어야 하므로, 데이터가 잘못 관리될 가능성 (변경일자 속성만 존재하는 점 이력 릴레이션은 정합성 문제 없음)

정합성이 깨진 릴레이션 (어느 값이 맞는지 판단할 수 없음)

선분 이력 채택은 신중

• 모든 변경 데이터에 대한 관리를 선분 이력으로 해야 할 필요 없음
• 채택 조건
  • 넓은 범위의 과거 데이터를 조회
  • 특정 고객의 과거 특정 시점의 데이터를 자주 조회 (현재 데이터만 조회 한다면 선분 이력 불필요)
• 채택 단계 - 이력 요건을 검토하는 단계(이력 대상을 결정하는 개념 모델링 단계에서 선분 이력 적용 여부 결정)

선분 개념으로 데이터를 관리하는 예제

• 극장 좌석 예약 상태 관리 (예약이 안된 연속된 좌석을 알아야 하는 요건)

• 극장 좌석 예약 상태 관리 (10-13번 좌석 예약 후)