시작일자 속성을 주 식별자에 포함

• 원래 주 식별자에 시작일자 속성을 포함 (또는 종료일자 속성까지 포함) 하는 방법

시작일자 속성이 주 식별자에 포함된 선분 이력 모델
!

• 위의 모델에서 '123' 대리점의 현재 소속 지점 조회 쿼리

SELECT *
  FROM 대리점소속 A, 대리점 B
 WHERE A.대리점코드 = B.대리점코드
   AND A.대리점코드 = '123'
   AND 유효종료일자 = '9991231';

• PK 인덱스 (대리점코드 + 유효시작일자) 사용 불가
• 별도 인덱스 (대리점코드 + 유효종료일자) 필요 (부담)
• PK 인덱스 변경 (대리점코드 + 유효시작일자 + 유효종료일자) 가능 (부담)

• 위의 모델에서 '123' 대리점의 2020.01.23 소속 지점 조회 쿼리

SELECT *
  FROM 대리점소속 A, 대리점 B
 WHERE A.대리점코드 = B.대리점코드
   AND A.대리점코드 = '123'
   AND '20200123' BETWEEN A.유효시작일자 AND A.유효종료일자;
 

• PK 인덱스 (대리점코드 + 유효시작일자) 사용시 유효종료일자를 체크 조건으로 사용 하므로, 약간의 비효율 발생
• 최적 인덱스는 (대리점코드 + 유효시작일자 + 유효종료일자)

• 과거/현재 시점의 데이터를 조회 해기 위해 필요한 인덱스 (3개)

종료일자를 주 식별자에 포함

• 원래 주 식별자에 종료일자 속성을 포함
  • 실무에서는 상대적으로 덜 사용됨
    • 주 식별자인 종료일자 값에 업데이트가 발생 하기 때문 (주 식별자 값을 변경되지 않아야 한다는 기본 원칙)
    • 종료일자가 시작일자 앞서 있어서 이상하게 여기는 경향
  • 성능을 최우선으로 고려하는 선분 이력의 목적 고려
    • 종료일자 값이 업데이트 된다고 별다른 문제를 일으키지는 않는다
    • 하지만 자식 엔터티 존재하는 경우는 적용 불가 (이력 엔터티에 자식 엔터티가 존재 하는 것 자체가 바람직 하지 않지만)

• 모델

종료일자 속성이 주 식별자에 포함된 선분 이력 모델

• 위의 모델에서 '123' 대리점의 현재 소속 지점 조회 쿼리

SELECT *
  FROM 대리점소속 A, 대리점 B
 WHERE A.대리점코드 = B.대리점코드
   AND A.대리점코드 = '123'
   AND 유효종료일자 = '9991231';
 

• 가장 자주 사용되는 현재 소속 부서 조회시 PK 인덱스 (대리점코드 + 유효종료일자) 사용
• 별도 인덱스 불필요

• 위의 모델에서 '123' 대리점의 2020.01.03 소속 지점 조회 쿼리

SELECT *
  FROM 대리점소속 A, 대리점 B
 WHERE A.대리점코드 = B.대리점코드
   AND A.대리점코드 = '123'
   AND '20200103' BETWEEN A.유효시작일자 AND A.유효종료일자;
 

• 최적 인덱스 (대리점코드 + 유효시작일자 + 유효종료일자) 필요

• 과거/현재 시점의 데이터를 조회 해기 위해 필요한 인덱스 (2개)

변경순번 속성을 주 식별자에 포함

• 원래 주 식별자에 변경순번 속성을 포함

변경순번 속성이 주 식별자에 포함된 선분 이력 모델

• 변경순번(일련번호)이 업무적으로 의미가 있을 때 고려
  • 변경순번을 관리해야 하는 특별한 요건이 없는 경우 가장 비효율적인 모델 (요건: 몇 번째 변경인가?)
• 대리점소속 엔터티에 자식 엔터티가 생기면서 하위 엔터티는 대리점소속 엔터티의 현재 데이터와만 관계를 가질 때
  • 예) 2023-12-30 에 '123' 대리점의 소속 지점이 '10'으로 변경

• 대리점소속(변경전)

• 대리점소속(변경후)

• 기존의 변경순번 값을 +1 업데이트, 새로 추가된 인스턴스의 변경순번 값은 1 설정
  • 변경순번 값이 1인 인스턴스는 현재 데이터를 의미
  • 현재 데이터와 관계를 갖는 하위 엔터티에 영향이 없다. (하지만 이력 데이터를 관리하는 엔터티에 하위 엔터티가 생기는 것은 지양 해야 함)
  • 종료일자 속성을 주 식별자에 포함한 모델에서도 현재 인스턴스에만 하위 엔터티가 존재하는 경우 수용 가능 (주 식별자 값 '9999-12-31' 이 변하지 않음)

• 과거/현재 시점의 데이터를 조회 해기 위해 필요한 인덱스 (3개)

• 선분 이력으로 관리할 필요가 없을 때 (특정 시점 조회 성능 이슈 없을 때)

선분 이력이 아닌 일반 이력 모델

• 대리점별 변경순번이 업무적으로 필요 없는 경우 지양
• 하루에 여러번 변경되는 요건 이라면, 변경순번 보다는 변경일시에 시,분,초 까지 관리 하는것이 바람직

• 선분 이력으로 관리할 필요가 없을 때 (최신 여부 추출속성 사용)

최신 여부 추출속성이 사용된 모델

• 현재 시점 데이터 조회시 성능 문제 극복을 위해 추출 속성인 최신여부 속성을 사용