by-nc-sa     개발자, DBA가 함께 만들어가는 구루비 지식창고!

이력 엔터티의 주 식별자




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

  • 원래 주 식별자에 시작일자 속성을 포함 (또는 종료일자 속성까지 포함) 하는 방법
    시작일자 속성이 주 식별자에 포함된 선분 이력 모델
    !
  • 위의 모델에서 '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개)
    PRIMARY KEY 대리점코드 + 유효시작일자  
    INDEX 대리점코드 + 유효종료일자 현재 시점
    UNIQUE INDEX 대리점코드 + 유효시작일자 + 유효종료일자 과거 시점

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

  • 원래 주 식별자에 종료일자 속성을 포함
    • 실무에서는 상대적으로 덜 사용됨
      • 주 식별자인 종료일자 값에 업데이트가 발생 하기 때문 (주 식별자 값을 변경되지 않아야 한다는 기본 원칙)
      • 종료일자가 시작일자 앞서 있어서 이상하게 여기는 경향
    • 성능을 최우선으로 고려하는 선분 이력의 목적 고려
      • 종료일자 값이 업데이트 된다고 별다른 문제를 일으키지는 않는다
      • 하지만 자식 엔터티 존재하는 경우는 적용 불가 (이력 엔터티에 자식 엔터티가 존재 하는 것 자체가 바람직 하지 않지만)
  • 모델
    종료일자 속성이 주 식별자에 포함된 선분 이력 모델
  • 위의 모델에서 '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개)
    PRIMARY KEY 대리점코드 + 유효종료일자 현재 시점
    UNIQUE INDEX 대리점코드 + 유효시작일자 + 유효종료일자 과거 시점

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

  • 원래 주 식별자에 변경순번 속성을 포함
    변경순번 속성이 주 식별자에 포함된 선분 이력 모델
  • 변경순번(일련번호)이 업무적으로 의미가 있을 때 고려
    • 변경순번을 관리해야 하는 특별한 요건이 없는 경우 가장 비효율적인 모델 (요건: 몇 번째 변경인가?)
  • 대리점소속 엔터티에 자식 엔터티가 생기면서 하위 엔터티는 대리점소속 엔터티의 현재 데이터와만 관계를 가질 때
    • 예) 2023-12-30 에 '123' 대리점의 소속 지점이 '10'으로 변경
  • 대리점소속(변경전)
    #대리점코드 #변경순번 유효시작일자 유효종료일자 지점코드
    123 1 2022-10-10 9999-12-31 09
    123 2 2020-02-01 2022-10-09 05
  • 대리점소속(변경후)
    #대리점코드 #변경순번 유효시작일자 유효종료일자 지점코드
    123 1 2023-12-30 9999-12-31 10
    123 2 2022-10-10 2023-12-29 09
    123 3 2020-02-01 2022-10-09 05
    • 기존의 변경순번 값을 +1 업데이트, 새로 추가된 인스턴스의 변경순번 값은 1 설정
      • 변경순번 값이 1인 인스턴스는 현재 데이터를 의미
      • 현재 데이터와 관계를 갖는 하위 엔터티에 영향이 없다. (하지만 이력 데이터를 관리하는 엔터티에 하위 엔터티가 생기는 것은 지양 해야 함)
      • 종료일자 속성을 주 식별자에 포함한 모델에서도 현재 인스턴스에만 하위 엔터티가 존재하는 경우 수용 가능 (주 식별자 값 '9999-12-31' 이 변하지 않음)
  • 과거/현재 시점의 데이터를 조회 해기 위해 필요한 인덱스 (3개)
    PRIMARY KEY 대리점코드 + 변경순번  
    INDEX 대리점코드 + 유효종료일자 현재 시점
    UNIQUE INDEX 대리점코드 + 유효시작일자 + 유효종료일자 과거 시점
  • 선분 이력으로 관리할 필요가 없을 때 (특정 시점 조회 성능 이슈 없을 때)
    선분 이력이 아닌 일반 이력 모델
    • 대리점별 변경순번이 업무적으로 필요 없는 경우 지양
    • 하루에 여러번 변경되는 요건 이라면, 변경순번 보다는 변경일시에 시,분,초 까지 관리 하는것이 바람직
  • 선분 이력으로 관리할 필요가 없을 때 (최신 여부 추출속성 사용)
    최신 여부 추출속성이 사용된 모델
    • 현재 시점 데이터 조회시 성능 문제 극복을 위해 추출 속성인 최신여부 속성을 사용

문서정보

Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.