태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.

드디어 마지막 열 번째 방법입니다.

 

- 마스터에 해당 속성이 존재해 현재 데이터를 관리하고, 속성 그룹의 이력 데이터는 별도의 엔터티에서 관리

- 마스터에 해당 속성이 존재하지 않고, 속성 그룹을 별도 하나의 엔터티를 사용해 현재+과거 데이터를 통합해서 관리

- 마스터에 해당 속성이 존재하지 않고, 속성 그룹을 두 개의 엔터티를 사용해 현재와 과거 데이터를 개별로 관리

 

유사한 속성을 묶어서 별도의 엔터티로 설계하며, 현재 데이터와 변경된 과거 데이터를 따로 관리합니다.

 

앞서 밝혔듯이 구분하는 게 도움이 되기 때문에 구별했지만 다섯 번째 방법과 유사합니다.

 

이력 엔터티를 설계하는 다섯 번째 방법



[그림1]

 

주식종목가격 엔터티의 속성 값이 하나라도 바뀌면 주식종목가격이력 엔터티에 데이터가 생성합니다.

 

기준가가 바뀌면(16000에서 17000으로) 주식종목가격 엔터티에는 기준가 속성만 17000으로 업데이트되고, 주식종목가격이력 엔터티에는 변경 전 스냅샷 인스턴스로 인서트됩니다.

 

물론 [그림2] 상단 릴레이션처럼 스냅샷으로 등록하지 않고, 하단 릴레이션처럼 변경된 데이터만 생성하는 방법도 있습니다.

 

[주식종목가격이력]

#주식종목번호

#변경일자

액면가

기준가

1000

2026-01-15

5000

16000

 

[주식종목가격이력]

#주식종목번호

#변경일자

액면가

기준가

1000

2026-01-15

{null}

16000

 

[그림2]

 

하지만 유사한 여러 속성을 묶어서 하나의 엔터티에서 관리하는 주요 이유는 속성이 같이 사용되기 때문인데 하단 릴레이션은 이 점에서 문제가 있어 보입니다.

 

변경 값만 알려면 [그림2] 하단 릴레이션처럼이 아니라 여섯 번째 방법처럼 종테이블(Vertical Table)로 관리하는 것이 바람직합니다.

 

이력 엔터티를 설계하는 여섯 번째 방법


변경된 속성과 변경되지 않은 속성이 같이 조회될 가능성이 조금이라도 있다면 스냅샷 방식으로 관리하는 것이 좋습니다
.

 

이 마지막 방법은 이전 방법에 비해 엔터티의 개수가 늘었지만 자주 사용하는 현재 데이터만 별도 엔터티에 존재하므로 현재 데이터를 조회하기 수월합니다.

 

속성 그룹이라는 거 빼고는 다섯 번째 방법과 특징이 동일합니다.

 

이상으로 이력 데이터를 설계하는 10가지 방법에 대해 설명드렸습니다. 예상보다 오래 걸렸네요.

 

이 중에서 2가지(네 번째, 아홉 번째 방법)는 발생 내역 데이터이지만, 이력 엔터티를 설계할 때 도움이 되므로 포함시켰습니다.

 

이력 데이터는 본질 데이터로부터 영향을 받습니다.

본질 엔터티를 분명히 한 후에 이력 데이터를 설계해야 합니다.

 

또한 이력 엔터티는 엔터티 정의와 밀접하게 연관돼 있습니다.

엔터티 정의를 어떻게 하느냐에 따라 이력 엔터티도 영향을 받습니다.

 

이력 엔터티를 올바르게 정의하려면 원천 엔터티가 올바르게 정의돼야 하므로, 즉 원천과 이력 엔터티를 올바르게 정의해야 하므로 이력 엔터티를 제대로 설계하긴 쉽지 않습니다.

 

1~2가지 방법으로는 다양한 요건을 만족할 수 없습니다. 모든 이력 엔터티를 스냅샷 방식의 선분이력으로 설계한다는 식의 생각은 지양해야 하고요.

 

이번 시리즈에서 설명한 10가지의 다양한 설계 방법으로 다양한 요건을 대응할 수 있길 바랍니다.

 


블로그 이미지

블루퍼필

댓글을 달아 주세요

  • 정유성 2012.01.02 15:16  댓글주소  수정/삭제  댓글쓰기

    이력 엔터티를 설계하는 방법을 유형별로 아주 자세히 설명해 주신 것 같습니다. 감사드립니다.

    • 블루퍼필 2012.01.03 11:24 신고  댓글주소  수정/삭제

      감사합니다.

      아직도 이력 관리는 만족 못하고 있지만 최대한 체계적으로 정리하려 노력했습니다.
      많은 사람들이 읽어봤으면 하는 내용이기도 하고요. ㅎ

      복된 한 해 되세요.

아홉 번째 방법은 유사한 속성을 묶어서 별도의 엔터티로 설계하고, 이력 데이터도 같이 관리하는 겁니다.

 

- 마스터에 해당 속성이 존재해 현재 데이터를 관리하고, 속성 그룹의 이력 데이터는 별도의 엔터티에서 관리 

- 마스터에 해당 속성이 존재하지 않고, 별도의 엔터티에서 속성 그룹의 현재+과거 데이터를 통합해서 관리 

- 마스터에 해당 속성이 존재하지 않고, 속성 그룹을 두 개의 엔터티를 사용해 현재와 과거 데이터를 개별로 관리

 

이 방법은 네 번째 방법과 유사한데요.

 

제 기준으로는 내역 엔터티인데, 비교해서 보는 게 이해를 돕기 때문에 10가지의 이력 엔터티 설계에 포함시켰습니다. 여덟 번째 방법, 마지막 열 번째 방법과 비교해 보세요.

 

유사한 속성을 묶어서 별도의 엔터티에서 현재+과거 데이터를 통합 관리하는 모델이 [그림1]입니다.



[그림1]

 

발행가는 변하지 않기 때문에 주식종목 엔터티에서 관리하고요. 변할 가능성이 있는 속성만을 묶어서 별도의 엔터티에서 관리합니다.

 

별도의 엔터티에서 현재+과거 데이터를 통합해 관리하므로 엔터티명에 ‘~이력’을 붙이지 않습니다.

 

이전 방법과 마찬가지로 일대일(1:1) 관계로 도출해야 하는 요건과 잘 연계하면 더욱 효율적인 모델을 설계할 수 있습니다.


블로그 이미지

블루퍼필

댓글을 달아 주세요

이력 데이터를 설계하는 방법이 이제 곧 마무리될 거 같습니다.

시리즈 글 10개 올리는 게 쉽지 않네요. ㅎㅎ

 

이력 데이터를 설계하는 유형을 정리하면 크게 아래 세 가지입니다.

 

- 전체 속성을 관리(인스턴스 단위)

- 속성 하나 하나를 관리(속성 단위)

- 유사한 속성을 묶어서 관리(속성 그룹 단위)

 

위의 두 가지는 이미 설명드렸고 마지막 유형만 남았습니다.

 

마지막 유형인 유사한 속성을 묶어서 설계하는 방법은 다시 세 가지로 구분할 수 있습니다.

 

- 마스터에 해당 속성이 존재해 현재 데이터 관리, 속성 그룹의 이력 데이터는 별도의 엔터티에서 관리

- 마스터에 해당 속성이 존재하지 않고, 속성 그룹을 별도 하나의 엔터티를 사용해 현재+과거 데이터를 통합해서 관리

- 마스터에 해당 속성이 존재하지 않고, 속성 그룹을 두 개의 엔터티를 사용해 현재와 과거 데이터를 개별로 관리

 

위 방법은 유사한 속성을 묶어서 설계한다는 것을 제외하고 속성을 개별 엔터티에서 관리하는 방법(세 번째, 네 번째, 다섯 번째)과 동일합니다.

 

이 방법은 성격이 유사한 속성을 같이 관리하는 것인데요.

 

주로 도메인 유형이 같은 속성을 같이 설계합니다.

또는 같이 조회되는 요건이 명확하다면 해당 속성을 같이 설계하고요.

동시에 입력되는 속성도 같이 설계할 수 있고요.

일대일 관계로 관리할 수 있는 요건이면 이 유형으로 설계할 수 있습니다.

 

[그림1]은 모든 종목 속성을 마스터인 종목 엔터티에서 관리하며 가격과 관련된 속성은 별도의 가격 이력 엔터티에서, 이름과 관련된 속성은 별도의 이름 이력 엔터티에서 관리하는 모델입니다.



[그림1]

 

주식종목 엔터티의 가격 속성(주식종목가격이력 엔터티에 속한 속성) 중에서 하나라도 바뀌면 이력 데이터를 생성합니다.

 

예를 들어 장이 끝나고 다음날 기준가가 바뀌면 주식종목 엔터티의 기준가 속성은 업데이트되고, 변경되기 전의 기준가는 주식종목가격이력 엔터티에 인서트됩니다.

 

이때 다른 가격 속성(발행가·액면가)은 변경되지 않는다고 가정하면 주식종목 엔터티의 값과 일치합니다. 변경되지 않은 속성은 널(Null)로 인서트할 수도 있지만(이렇게 하면 변경된 속성을 알 수 있음) 같이 조회될 수 있다는 요건을 만족하기 위해 변경되지 않은 속성도 데이터를 그대로 인서트합니다.

 

물론 주식종목이름이력 엔터티에는 데이터를 인서트하지 않습니다.

 

[그림2] 인스턴스는 사례 데이터입니다. 2026115일에 기준가가 16000에서 17000으로 변했을 때의 인스턴스입니다.


[주식종목]

#주식종목번호

주식종목

한글단축명

주식종목

영문단축명

발행주식수

발행일자

발행가

액면가

기준가

1000

홍길동사

HONG

100

2025-12-31

6000

5000

17000


[주식종목가격이력]

#주식종목번호

#변경일자

발행가

액면가

기준가

1000

2026-01-15

6000

5000

16000

 

[그림2]

 

[그림1]과 같은 예제 모델은 일반적인 방법이고 좀 더 전략적으로 설계할 수 있습니다.

 

예를 들어 변경되지 않는 속성은 이력 엔터티에서 관리하지 않는다든지…

매우 빈번히 변경되는 속성과 변경될 가능성이 적은 속성으로 분리할 수도 있고요.

외부에서 데이터를 받는다면, 동시에 받는 속성만을 별도 이력 엔터티에서 관리할 수도 있고요.

 

[그림1] 모델에서 발행가는 변경되지 않으니 주식종목 엔터티에서 관리하고, 변할 수 있는 가격(액면가·기준가)만 이력에서 관리할 수 있습니다.

 

이 경우 더욱 정밀한 분석이 필요하고 물론 더 판단할 게 있습니다.

 

조회가 같이 되느냐와 정정인데요.

 

변경되느냐와는 무관하게 조회가 같이 되는 속성이라면 같은 엔터티에 위치하는 게 좋을 수 있고요.

 

원래는 변하지 않는 게 맞지만 잘못 입력한 정정 데이터를 고려해야 할 때가 많습니다. 정정에 대해서는 별도로 설명하겠습니다.

 

어쨌든 조회 요건과 정정 요건은 고려해야 할 요소입니다.

 

속성별로 하나의 엔터티에서 관리하는 방법(세 번째, 네 번째, 다섯 번째)은 엔터티가 늘어나는 단점이 있었지만 이 방법은 엔터티의 정체성도 비교적 좋고 엔터티도 많이 늘어나지 않습니다.

 

일대일(1:1) 관계의 엔터티와 연계해서 이력 데이터를 설계하기도 좋고요.

모델로 업무 파악하기에도 비교적 좋아 적절하게 사용하면 효율적인 모델이 됩니다.

 


 

블로그 이미지

블루퍼필

댓글을 달아 주세요

일곱 번째 방법은 여섯 번째 방법의 확장입니다.

 

엔터티 한 개만 관리하는 여섯 번째 방법에서 두 개의 엔터티로 확장한 모델이 [그림1] 입니다.


[그림1]

 

고객계좌통합번호 속성은 배타 관계(계좌와 고객 엔터티)를 관리하는 속성입니다. 엔터티번호 속성과 함께 사용해야 어떤 엔터티의 식별번호인지를 알 수 있습니다(파란 속성은 같이 사용하는 쌍을 의미).

 

계좌 엔터티만이 아니라 다른 엔터티의 이력 데이터도 관리하므로 포괄적으로 속성통합이력 엔터티라고 붙이고요([그림1]처럼 단 두 개의 엔터티라면 고객/계좌속성이력도 좋음).

 

이력엔터티라는 엔터티에서는 이력 데이터를 관리하는 대상 엔터티를 관리합니다.

 

이 방법은 여섯 번째 방법의 단점은 모두 가지고 있으며 더 유연하기 때문에 업무를 파악하기 더욱 어려워진다는 단점이 추가되지만, 엔터티별로 속성 이력 엔터티(계좌이력·고객이력 엔터티)가 추가되는 것보다 효과적이라고 생각합니다. 간혹 작정하고 다소 어려운 모델을 사용해야 할 때가 있습니다.

 

최대한 유연하게 설계할 수 있다는 것이 최대의 장점입니다.

 

이력 데이터를 종테이블(Vertical Table)로 관리하는 대상 엔터티를 알 수 있다는 점도 장점이고요. 엔터티 개수가 줄어든다는 점도 장점입니다.

 

너무 많은 엔터티의 이력 데이터를 통합하는 것보다는 성격이 유사하거나, 같은 영역에 있는 몇 개의 엔터티를 통합하면 좋습니다.

 

이 방법은 이력 데이터를 관리하는 대상 엔터티의 주 식별자를 주의해야 합니다. 배타 관계를 관리하는 방법과 같습니다.

 

[그림1]은 주 식별자가 다른 대표적인 엔터티를 관리하는 예제로 고객계좌통합번호 속성 사용에 주의해야 하고요.

 

슈퍼타입, 서브타입을 이력 관리할 때는 주 식별자가 같아 [그림2]와 같이 배타 속성(고객번호)이 단순해집니다.


[그림2]

 

[그림1] [그림2]는 비교적 수월한데요.

 

대상 엔터티의 주 식별자가 다양(성격과 개수)할 때가 문제입니다.

 

[그림3]은 이 문제를 해결할 수 있는 매우 유연한 모델입니다.


[그림3]

 

이력 데이터를 관리하는 대상이 계좌·고객·고객주소 엔터티이고요. 각각 주 식별자(빨간 속성) 개수가 다릅니다.

 

통합 이력을 관리하는 엔터티(속성통합이력)는 배타 관계가 발생하고, 세 개의 속성(통합이력식별속성·통합이력식별속성2·통합이력식별속성3)에서 대상 엔터티의 주 식별자 값을 관리합니다.

 

주 식별자가 하나인 고객 엔터티의 속성이 변경되면 통합이력식별속성2·통합이력식별속성3 속성에 해당되는 값은 없으므로 널(Null) 허용입니다(속성 왼쪽 동그라미 표시).

 

[그림3]과 같이 하나의 엔터티에서 다양한 엔터티의 이력 데이터를 관리하는 요건을 경험한 적은 없습니다.

 

배타 관계 때문에 이와 유사한 모델이 발생한 적은 있는데요. 이에 대해서는 나중에 별도로 소개하겠습니다.

 

이상으로 이력 데이터를 종테이블(Vertical Table)로 관리하는 방법을 설명드렸는데요.

 

여섯 번째와 일곱 번째 모델이 유용할 때가 분명 있습니다. 이력 데이터를 조인해서 조회하는 게 아니고 필요 시 단지 추적 용도로 사용하면 효과적입니다.

 

하지만 분석하기 싫어서, 귀찮아서 이 모델을 선택한다면 안 될 것입니다. 특별히 모델러는 주의해야 합니다.


블로그 이미지

블루퍼필

댓글을 달아 주세요