06. 이력 데이터 이야기

이력 데이터에 대한 서설

1. 이력 데이터의 정의
   • 이력 데이터(Altered Data)는 단순한 과거 데이터가 아니라 원천 데이터가 변경되었을 때 생성되는 데이터를 의미한다.
   • 과거에 쌓인 내역 데이터(Historical Data)와는 다르며, 반드시 원천 데이터의 변경이 있어야 한다.
2. 원천 데이터와의 관계
   • 이력 데이터는 원천 데이터에 종속된다.
   • 원천 데이터가 명확히 정의되어야 이력 데이터도 올바르게 설계할 수 있다.
   • 이력 엔터티 정의는 원천 엔터티 정의와 밀접하게 연관된다.
3. 이력 데이터를 관리하는 이유
   • 데이터 변경 전 상태 추적을 위해 필요하다.
   • 필요성이 없다면 단순히 데이터 업데이트만 하면 되므로 이력 데이터 관리 자체가 불필요하다.
   • 그러나 정보화 사회가 발전할수록 이력 관리 요건은 점점 많아질 것이므로 주요 엔터티는 이력 관리 가능성을 대비해야 한다.
4. 설계 시 고려사항
   • 이력 데이터는 함수 종속, 파생 종속 등 데이터 종속성과 관련이 깊다.
   • 이력 관리는 중복 속성, 추출 속성과도 연관되어 복잡성이 높다.
   • 원천 데이터가 바뀌어야 이력 데이터가 생긴다는 원칙을 염두에 두어야 하며, 원천 엔터티와 이력 엔터티 모두 올바르게 정의해야 안정적인 설계가 가능하다.\

결론:

• 이력 데이터는 단순 과거 기록이 아니라 원천 데이터의 변경으로 발생하는 데이터이며, 원천 데이터 정의가 명확해야 제대로 설계할 수 있다.
• 이력 관리 여부는 업무 요건이 결정하지만, 미래 요구를 고려해 주요 엔터티는 대비하는 것이 바람직하다.

 

이력 데이터와 내역 데이터

이력 데이터란 변경된 데이터다. 예전에 쌓인 데이터여도 변경되지 않았다면 이력 데이터가 아니라 내역 데이터다.

(이력 데이터 = 죽은 데이터)

 

▶ 주문 데이터를 관리하는 모델

1. 같은 상품은 하루에 한 번만 주문할 수 있음

 

2. 주문 데이터를 관리하는 모델: 하루에 같은 상품을 여러 개 주문할 수 있게됨. 그에 따라 기존의(변경 전의) 수량을 관리하기 위해 이력 데이터 관리하기 시작함.

 

 

▶ 상품과 상품가격

1. 상품과 상품 가격은 일대일로 연관됨. 즉 상품번호를 알면 유일하게 하나의 가격이 정해지기 때문에 상품가격 속성은 상품번호에 종속된 속성임.

 

2. 주 식별자인 상품번호 속성에 종속된 상품가격 속성의 값이 변경되면 이력 데이터가 생기는데, 이를 관리하는 모델

• 상품 엔터티의 상품가격 속성은 현재 유효한 상품가격을 관리하고, 상품가격이력 엔터티의 상품가격은 현재 유효하지 않은 상품가격을 관리 → 이력 데이터

 

3. 만약 매일 변할 수 있는 상품 가격을 별도로 관리하겠다는 요건이 있다면 아래와 같은 모델이 필요

• 상품 엔터티에는 상품가격 속성이 없고, 상품가격 엔터티에 데이터가 생성됨 → 내역 데이터(원천 데이터)
• 기준일자에 해당하는 과거에 생성된 데이터라도 변경된 데이터가 아니기 떄문에 이력 데이터가 아니라 내역 데이터이다.

 

이력 엔터티 설계 시점

1. 설계 시점 두 가지
   • 동시 설계 방식: 원천 엔터티와 함께 이력 엔터티를 설계.
     • 장점: 초기 단계부터 구조 영향을 최소화, 개선 기회 제공.
     • 단점: 원천/이력 데이터가 뒤섞일 위험 → 반드시 원천 데이터 정의를 우선해야 함.
   • 후행 설계 방식: 논리/물리 모델링이 끝난 후 이력 엔터티 설계.
     • 장점: 본질 데이터에 집중 가능, 절차 단순 → 초보자에게 유리.
     • 단점: 모델 구조가 바뀔 위험이 크며, 때로는 처음부터 다시 설계해야 하는 상황 발생.
2. 설계 시 고려사항
   • 본질 데이터와 이력 데이터는 종합적으로 동시에 고민해야 함.
   • 이력 설계는 선분이력(시작일/종료일 관리 방식) 사용 여부까지 포함해 결정해야 한다.
   • 선분이력을 쓰는 경우, 종료일자 속성이 주 식별자에 포함되면 하위 엔터티가 없어야 하는 제약도 고려해야 함.
3. 모델링 원칙
   • 단계 절차에 집착하지 말고, 중요한 엔터티는 식별자, 핵심 속성, 이력 관리 방안, 성능 이슈를 함께 검토해야 함.
   • 본질 데이터 설계 시, 이후 이력 추가가 모델 구조를 흔들지 않는지 미리 검토해 두어야 한다.
   • 이렇게 하면 마무리 단계에서 구조 변경이 크게 줄어든다.

결론:

• 이력 엔터티 설계는 본질 데이터 정의와 동시에 종합적으로 고려하는 것이 바람직하며, 시점은 상황에 따라 달라질 수 있다.
  특히 선분이력 사용 여부를 초기에 결정하고, 구조 변경 가능성을 최소화하는 것이 중요하다.

 

이력 데이터를 설계하는 방법

이력 데이터를 설계하는 방법

1. 엔터티 단위 이력
   • 만약 원천 엔터티에서 속성 값이 하나라도 변경되면 변경 전의 전체 속성(인스턴스)을 별도의 이력 엔터티에서 관리하는 방법
   • 다른 방법에 비해 저장 공간의 낭비가 심하다.
   • 인스턴스의 스냅샷 데이터이기 때문에 저장하기 쉽고 해당 시점의 전체 데이티, 즉 변경된 속성값과 변경되지 않은 속성 값을 한 번의 액세스로 조회하기 쉽다는 장점이 있다.
   • 이 방법은 특정 시점의 전체 속성 값을 조회하는 요건이 많을 때 사용한다.
2. 속성 단위 이력
   • 변경된 속성의 데이터만을 별도로 관리하는 방법
   • 저장 공간이 가장 절약된다.
   • 변경된 속성만을 대상으로 관리하므로 변경된 속성이 무엇인지 명확하게 알 수 있다. 
   • 과거 특정한 시점에 대해 변경된 속성 값과 변경되지 않은 속성 값을 같이 조회하기는 쉽지 않다.
3. 속성 그룹 단위 이력
   • 속성 중 내용(도메인)이 유사하거나 같이 사용될 수 있는 속성을 묶어서 별도의 엔터티에서 이력 데이터를 관리하는 방법
   • 묶인 속성 중의 하나라도 변경되면 그 시점의 묶인 속성 전체를 이력 데이터로 그대로 쌓는 방법
   • 엔터티 단위로 관리하는 방법과 개별 속성 단위로 관리하는 방법의 장점을 수용한 방식

 

이력 데이터를 설계하는 첫 번째 방법

1. [엔터티 단위로 설계] 이력 엔터티를 별도 엔터티로 설계하는 방식
   • 이력 데이터를 생성하는 게 다른 방법에 비해 쉽다
   • 변경 데이터를 별도로 관리하기 때문에 원천 데이터를 관리하기 수월하다. 
   • 하위(자식) 엔터티에 미치는 영향도 차단했기 때문에 모델이 안정적이다.
   • 거의 유사한 스키마의 엔터티를 동일하게 유지해야 하는 점은 부담이다.
   • 이 방법은 다른 방법에 비해 데이터 중복이 심해 데이터 저장 공간이 많이 소비된다.
   • 만약 변경된 속성 값만 알아야 한다면 이 방법은 사용할 수 없다.
   • 실무에서 가장 많이 사용하는 방식이다.
2. [엔터티 단위로 설계] 하나의 엔터티에 원천 데이터와 변경 데이터를 함께 관리하는 방식
   • 하나의 엔터티에서 원천 데이터와 변경 데이터(이력)를 같이 관리하는 주요한 이유는 변경 데이터에 대한 사용 빈도가 높기 때문이다. 변경 데이터가 빈번하게 사용되고, 떄로는 원천 데이터와 동시에 사용된다면, 하나의 엔터티에서 관리하는 것이 효율적이다.
   • 하나의 엔터티에서 이력 데이터까지 관리하면 데이터 모델(ERD)을 관리하기 편하다.
   • 엔터티 개수를 줄이는 효과가 있다.
   • 이 방법을 사용할 때는 데이터가 하나의 엔터티에 집중돼 있기 때문에, 조회 또한 집중적으로 발생한다는 점도 고려해야 한다.
   • 원천 데이터와 변경 데이터를 한 엔터티에서 관리하면, 발생내역과 변경이력을 같이 관리하기 때문에 엔터티의 성격이 불명확해지는 경향이 있다.
   • 이 방법은 주요 실체/행위 엔터티에는 사용하지 않는다. 반면에 기준 엔터티는 하위 엔터티가 존재하지 않고 데이터양도 적어서 이 방법을 사용하기 적절하다.
3. [속성 단위로 설계] 변경 데이터를 별도의 엔터티에서 관리하는 방법
   • 속성 하나에 대해서만 이력 데이터를 관리하고, 현재 유효한 데이터와 무효한 데이터를 별도로 관리하는 방법의 가장 커다란 특징은 엔터티 성격이 명확해진다는 것이다. → 모델의 확장성이 좋아진다는 것을 의미
   • 반면에 모델링을 정밀하게 해야 해서 모델링하기 어려울 수 있다. 요건부터 정밀하게 분석해야 해서 시간이 오래 걸린다. → 별도로 요건이 존재할만한 주요 속성을 대상으로 하는 것이 좋다.
   • 이 방법은 중복 데이터가 없어 데이터 저장 공간이 절약된다.
   • 모델을 설계하긴 어려울 수 있어도 이력 모델을 형상 관리하긴 그리 어렵지 않다.
   • 실무에서 많이 사용되지 않는 방법이나, 자주 사용하는 중요한 속성에 대해서는 이 방법의 사용을 고려해야 한다.
4. [속성 단위로 설계] 특정 속성의 원천 데이터를 별도의 엔터티에서 관리하면서, 변경 데이터와 원천 데이터를 함께 관리하는 방식
   • 이 방법은 설계할 때 혼란스러울 수 있어 주의해야 한다. 변경이력 데이터로 설계한 것인지, 발생내역 데이터로 설계한 것인지 구분해야 혼란스럽지 않게 된다.
5. 원천 엔터티에서 변경된 속성을 종 테이블(Vertical Table) 형식의 별도 엔터티에서 통합 관리하는 방식
   • 모델 구조가 데이터 속으로 사라지기 때문에 제대로 사용하기 쉽지 않다.
   • 종 테이블을 사용할 때는 상세한 업무 파악이 필요하지 않아 엔터티의 성격(정확하게는 속성의 성격)이 모호해지는 경우가 많다.
   • 이 방법의 최대 장점은 모델을 형상 관리할 필요가 없다는 점이다. → 그만큼 유연한 구조의 모델
   • 변경된 개별 속성을 조회하기는 쉬운 편이다.
   • 데이터 저장 공간도 적게 사용하며, 설계하기 편하다는 장점도 있어 실무에서 자주 사용한다.

 

이력 데이터를 종 테이블로 설계하는 다양한 방법

1. 여러 엔터티의 이력 데이터를 관리하는 종 테이블

• 너무 유연한 모델이라 업무를 파악하기 더욱 어렵다.
• 엔터티별로 종 테이블 형식의 이력 엔터티(계좌이력/고객이력 등)가 추가되는 것보다 효과적이다.
• 엔터티 개수가 많이 줄어든다.
• 성격이 다른 많은 엔터티의 이력 데이터를 통합하는 것보다는 성격이 유 사하거나, 같은 영역에 있는 몇 개의 엔터티를 통합하는 게 바람직하다. 또한 이력 데이터를 조인해서 사용하기보다는 필요할 때 참고할 용도로 사용하면 효과적이다.
• 이력 데이터를 관리하는 대상 엔터티의 주 식별자가 배타 관계를 만들기 때문에 주의해야 한다.

 

2. 변경 행위를 기준으로 변경된 속성을 관리하는 모델

• 변경 행위를 기준으로 변경된 속성을 관리하기 때문에 같이 변경된 속성이 무엇인지를 자연스럽게 알 수 있다.
• 변경된 데이터 중에서 함께 변경된 속성을 알아야 하는 요건이 간혹 있으나 이런 요건은 흔치 않기 때문에 요건 정의부터 명확히 해야 한다.

 

선분이력

선분이력은 과거 특정 시점의 데이터를 조회하는 요건이 많을 때 사용하는 방법으로 조회 성능을 고려한 기법이다.

• 데이터가 유효한 시작 시점과 종료 시점을 관리하는 방법
• 특정 데이터가 변경된 시작일자와 변경 전의 종료일자가 이어지도록 인위적으로 데이터를 관리하는 것이 핵심이다.
• 반댓말: 점이력
• 선분이력 방법은 과거 특정 시점의 데이터를 빠르게 조회해야 할 때 사용하는 방법이다. 단지 성능 문제를 해결하기 위해 사용하는 방법으로 심각한 성능 문제가 없다면 굳이 이력 데이터를 선분이 되도록 생성시킬 이유는 없다.

 

▶ 고객의 변경된 등급을 관리하는 릴레이션

• 이 릴레이션에서 만약 2039년 5월 1일의 등급을 알아야 한다면 쿼리가 약간 복잡해진다. → 성능 측면에서 비효율 발생

• 만약 넓은 범위의 조회가 있고 성능 문제를 해결해야 한다면 위와 같이 선분이력 방법을 사용해야 한다.
• 마지막 인스턴스가 현재 상태를 의미하는 데이터다.(현재의 데이터는 종료 시점이 없어서(모르기 때문에) '9999년 12월 31일'과 같은 약속된 데이터를 사용해 현재 데이터라는 것을 알 수 있도록 한다.)
  • 입력 시점에는 종료일자를 모르기 때문에 의미상으로는 널 값을 입력하는 것이 맞지만, 종료 시점 데이터는 성능을 위해 사용하는 값이므로 널 값을 사용할 수 없어 기본 값을 사용한다.
  • 무한대의 날짜를 의미하는 종료일자에 대한 기본 값은 '9999년 12월 31일'이 적당하다.('3000년 12월 31일'이나 '9000년 12월 31일'처럼 사람마다 다르게 해석하도록 하는 것은 좋지 않다.'
  • '9999년 99월 99일'처럼 날짜가 아닌 값을 사용하는 것은 좋지 않다.
  • 종료일자에 대한 기본 값은 DEFAULT 제약을 설정해 사용하는 것이 좋다.

 

선분이력의 종료일자

선분이력을 사용할 때는 종료일자 속성을 주 식별자에 포함시키는 것이 효과적이다.

종료일자 속성을 사용하는 것에 대한 문제점: 종료일자 속성이 추출 속성이라는 점 → 데이터 무결성 ↓

 

결론:

• 추출 속성인 종료일자 속성은 보수적으로 사용할 것을 권하며, 무의식적으로 사용하는 것은 지양해야 한다.

 

기간을 의미하는 종료 일자

선분이력을 위한 종료일자 ≠ 기간을 의미하는 종료일자

• 기간을 의미하는 기초 속성은 선분이력 속성과의 차별을 위해 '유효'라는 단어를 사용하지 않고 보험기간종료일자나 보험종료일자 등과 같이 업무를 의미하는 용어를 사용하는 것이 좋다.(선분이력을 의미하는 속성에만 '유효'를 붙이는 게 구분하기 좋다.)

 

이력 엔터티의 주 식별자

▶ 왜 선분이력 방법에서 종료일자 속성이 주 식별자에 포함되어야 하는지?

 

 

• 계좌의 변경된 비밀번호를 별도로 관리하는 일반적인 이력 엔터티

• 위 모델을 선분이력이 되도록 설계한 모델 - 유효시작일자를 주 식별자에 포함시킨 모델

-- 계좌의 현재 비밀번호를 조회하는 쿼리
SELECT 계좌비밀번호
FROM 계좌비밀번호
WHERE 유효종료일자 = '99991231'

• 위 쿼리는 조건절에 유효시작일자가 포함되지 않아 PK 인덱스인 '계좌번호+유효시작일자' 인덱스를 사용하지 못한다. → 별도의 인덱스 필요

-- 과거 특정일의 비밀번호를 조회하는 쿼리
SELECT 계좌비밀번호
FROM 계좌비밀번호
WHERE '20300123' BETWEEN 유효시작일자 AND 유효종료일자

• 이때 PK 인덱스를 사용하면 특정 계좌에 해당하는 시작일자에 대해 처음부터 끝까지 PK 인덱스를 스캔하면서, 유효종료일자를 체크 조건으로 사용함으로써 약간의 비효율이 발생한다.
• 결국 현재와 과거 시점의 비밀번호를 조회하는 쿼리를 위해 필요한 인덱스는 다음과 같다.
  • Primary Key: 계좌번호 + 유효시작일자
  • Index 1: 계좌번호 + 유효종료일자
  • Index 2: 계좌번호 + 유효시작일자 + 유효종료일자\

• 위와 같이 유효종료일자 속성을 주 식별자에 포함시킬 경우 필요한 인덱스는 다음과 같다
  • Primary Key: 계좌번호 + 유효종료일자
  • Index 1: 계좌번호 + 유효시작일자 + 유효종료일자
• 현재 유효한 비밀번호를 조회할 때 PK 인덱스를 사용한다는 것이 가장 큰 장점이다.
• 이 모델을 사용할 때 주 식별자 값에 업데이트가 발생한다는 단점이 있으나 큰 문제를 일으키지 않는다.

 

▶ 인조 식별자인 변경 순번 속성을 사용해야 하는지?

• 선분이력 방법에서 변경 순번을 주 식별자에 사용하는 것은 가장 비효율적이다.
• 간혹 실무에서 하위(자식) 엔터티가 존재할 때, 하위 엔터티에 미치는 영향을 줄이기 위해 사용하기도 한다. 그렇지만 기본적으로 이력 엔터티의 주 식별자에 변경순번과 같은 인조 식별자를 사용하는 것은 바람직하지 않다.

 

이력 엔터티 설계 절차

 

서브타입의 이력 모델

일반적으로 서브타입은 전체 모델에서 핵심적인 엔터티에 해당하기 때문에 제대로 설계하지 않으면 부작용이 커진다. 

 

1. 슈퍼타입/서브타입 엔터티별로 이력 데이터를 관리하는 방식

• 이 모델을 사용하면 서브타입별로 이력 데이터를 관리할 수 있다. 즉 개인고객 데이터가 변경되면 개인고객이력 엔터티에만 데이터가 생성되고 고객이력 엔터티에는 데이터가 생성되지 않는다.
• 고개깅력 엔터티와 개인고객이력 엔터티 간에 참조 무결성 제약이 없기 때문에 데이터 무결성을 장담할 수 없다.

 

2. 슈퍼타입 엔터티와 서브타입 엔터티에 참조 무결성이 존재하는 방식

• 이 모델에서는 고객이력 엔터티와 개인고객이력 엔터티 간에 참조 무결성 제약이 존재해 데이터 정합성이 맞으며, 조회하기가 쉽다.

 

3. 속성 단위로 이력을 관리하는 방식

• 이 모델을 사용하면 특정 속성이 변경된 값만을 관리할 수 있다.

 

정정 데이터

정정 데이터: 이미 존재하는 데이터가 잘못돼 수정한 데이터(잘못을 정정한 데이터)

실무에서 가끔 이력과 정정 데이터를 함께 관리해야 하는 요ㅕ건이 발생한다.

 

정정 데이터를 관리하는 방법

1. 기존 데이터를 정정해야 하는 데이터로 업데이트하는 방법
   • 정정에 대한 이력 관리는 하지 않는 방법이다.
   • 누가, 언제 정정했는지, 정정되기 전의 데이터는 무엇인지 알 필요가 없을 때 사용한다.(데이터가 업무상 중요하지 않을 때 사용)
2. 하나의 엔터티에서 변경이력 데이터를 관리하면서 정정 데이터도 함께 관리하는 방법
   • 이 모델은 변경정정구분코드 속성이 추가돼 몇 바이트가 더 소요된다는 점과 쿼리에 변경정정구분코드를 항상 추가해야 한다는 단점이 있지만, 정정 데이터도 함께 조회해야 하는 요건이 빈번할 때 사용하기 효율적인 모델이다.

 

1. 설계 시점
   • 정정 데이터 요건은 대부분 모델링 후반부나 실제 사용 경험 이후에 드러난다.
   • 따라서 이력 엔터티 확정 이후에 반영하는 것이 현실적이다.
2. 정정 데이터의 특징
   • 정정은 언제나 발생할 수 있는 행위지만, 이를 별도로 관리하는 요건은 흔하지 않다.
   • 잘못된 데이터를 인지한 시점에 수정하는 데이터를 관리하는 것이 정정 데이터의 핵심이다.
3. 이력 데이터와의 구분 필요성
   • 정정 데이터 ≠ 이력 데이터.
   • 두 개념을 혼동하면 모델 구조가 복잡해지고 가독성이 떨어지며, 특히 이력 데이터 관리에 악영향을 줄 수 있다.
   • 업무적으로는 구분하지 않아도 되지만, 데이터 모델에서는 반드시 구분해서 관리하는 것이 바람직하다.

 

결론:

• 정정 데이터는 드물지만 필요한 경우가 있으며, 이력 데이터와는 구분해서 관리해야 한다.
• 이력 엔터티 이후에 설계하는 것이 현실적이고, 혼동 시 모델 품질이 저하될 수 있다.