이력 모델

1. 이력모델 개념

데이터 모델링에서 '이력', '이력데이터' 는 많이 사용되는 용어 인데 그 개념이 모호하거나 
이력이 아닌것을 이력이라고 부르는 등 이치에 맞지 않게 사용되는 경우가 종종 보인다. 

어느 글에서 이력은 '시간에 따라 발생하는 데이터 형식' 이라고 정의한 것을 보았는데, 
이것은 일반적인 트랜잭션과도 차이점이 없다. 

주문과 같은 일반적인 트랜잭션을 '발생내역' 이라고 한다면 변경된 속성값을 일자에 따라 관리하는 "이력" 을 '변경이력' 이라고 구별 할 수 있다. 
변경이력을 다시 정의하면 현재 유효하지 않은 과거 데이터 라고 할수 있다. 
이력모델 이라고 부를수 있는것은 '변경이력' 이고, 원천모델이 나오고 나서야 이력모델이 도출되는 것이다. 
즉, 원천모델이 없는데 이력엔터티라고 부르고 있다면 엔터티의 정의를 다시 한번 살펴볼 필요가 있다. 


2. 발생내역 vs 변경이력 

- 발생내역(트랜잭션)
  insert 의 형태 (ex. 주문, 접속ip로그..)
  pk변경, 데이터변경 

- 변경내역 (찐 이력)
  update & insert 형태 (ex. 비밀번호변경 이력)
  pk동일, 데이터변경 
 
ex) 개인경력 엔터티가 있다면..
사번
일자
소속
경력상세 
=> 시간에 따른 경력쌓인 것(발생내역)

    과거의 경력데이터가 변경된 경우(변경내역 발생) -> 변경전 데이터를 관리할거면 이력엔터티 도출, 아니면 업데이트하고 완료


3. 이력엔터티와 원천엔터티 분리 or 통합

- 분리가 원칙 
엔터티 순수성이 유지 되어야 확장이 가능 -> 원천모델이 자식엔터티가 있다면 분리가 원칙 
잘못된 데이터 하나가 전체 엔터티의 데이터 신뢰도를 떨어트림 

이력+원천 통합 모델의 자식은 일자속성은 상속되지 않는 이상한 케이스 발생 => '$'

- 통합하는 경우 
업무적으로 이력/원천데이터가 빈번히 같이 사용된다면 한곳에 사용할수도 있다 
=> 원천에 일시 속성이 추가되어 사용하는것. 성능적 관점. 반정규화 일종 

이력+원천을 통합해서 쓴다면 해당 엔터티의 이름은 '~이력' 이라고 쓰지 않는다. 
오직 이력데이터만 있는 엔터티에게만 ~이력 이라고 명명한다. 


4. 이력관리 모델 형태/유형

- 이력관리 유형(레벨)
 1) 엔터티 레벨 (스냅샷)
   *장: 변경 시점의 다른 속성 값 파악 쉽다, 설계가 쉽다. 
   *단: 공간낭비, 어떤속성이 변경되었는지 1row 만 가지고 알수없다
   원천 형상 바뀌면 이력도 변경 해줘야 함
   자식이 있다면 스냅샷 

 2) 속성 레벨
   *장: 공간 절약, 무엇이 변경된 속성인지 파악 쉽다, 원천형상에 독립적 => 컬럼추가 필요 X
   *단: 변경시점의 다른속성값 알기 어려워. 원천테이블의 이력요건 속성이 추가되면 비효율 증가 

* 추가적 방식(vertical) 
 - 종(vertical)테이블 방식
    
 - 통합이력 
   *장: 업무변경에 유연하다
   *단: 구조가 데이터가 되어 파악 쉽지않다 

 3) 속성그룹 레벨
   같이사용되는 속성들 묶어서 관리 
   *장: 비교적 공간 절약, 
  
* 원천이 종속이면 이력도 종속 
 
 
- 이력관리 형태 
  1) 점이력 
변경시점만 관리 
특정시점의 값 찾기 어려움 

ex)   
SELECT A.기관코드, A.기관거래등급
  FROM 기관정보 A, 
     ( SELECT 기관코드, MAX(적용일자)
 FROM 기관정보 
WHERE 적용일자 <='20080701'
GROUP BY 기관코드 
  )B
 WHERE A.기관코드 = B.기관코드 
   AND A.적용일자 = B.적용일자 
;   

  2) 선분이력
시작시점/종료시점 관리 
특정시점의 값 찾는 것에 유리 

SELECT 기관코드, A.기관거래등급
 FROM 기관정보 A
WHERE '20081201' BETWEEN 시작일자 AND 종료일자 
;

선분이라는 것은 시작점,끝점이 이어진 2차원 형태인데 현재의 RDB 에서는 이를 구현할수 없다
(xmltype 도 있는데 선분타입이라는 것을 못만들 이유는 없을것 같다)
편의상 시작점, 끝점을 속성으로 만들어 선분을 구현했으나(흉내냈으나) unique 제약조건 등을 걸수가 없다.
이력에서 사용하는 선분은 겹치는 지점없이 이어져야(unique 해야) 하지만 이를 DB에선 표현 못함.
겹치거나 누락되는 지점이 발생되는것을 제약조건 등으로 막을수 없다. 
 
 * 선분이력의 자식 => 상속되지 않는 시작/종료일자 속성
 pk에 컬럼추가를 할때 시작 vs 종료  무엇을 추가를 할까 => 종료 : only 성능관점 
 
  - pk결정
  부모pk + 1) 종료일자
                 2) 시작일자 
                 3) 순번

논리적으로는 부모pk속성 + 시작,종료속성 모두를 상속해야 함  
 * 중복 row 는 존재하지 않는다. => 부모에 존재한 row 는 자식에 나오지 말아야함