태터데스크 관리자

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

태터데스크 메시지

저장하였습니다.

요건은 아래와 같습니다.

 

-부서명, 전화번호, 부서장 등의 부서에 대한 기본 정보를 관리한다.

-전화번호, 부서장 등의 데이터는 변경될 수 있어 이력 관리한다.

 

위의 요건을 설계한 모델이 아래와 같습니다.

잘못된 부분을 생각해 보세요.

 

 


[그림 1]

 

 

--

 

이력 데이터를 어떻게 설계할지에 대한 문제입니다.

 

이력 데이터를 원천 엔터티에 통합해서 관리하면 좋을 때가 있고 그렇지 않을 때가 있습니다. [그림 1]은 그렇지 않을 때에 해당돼서 아래와 같이 관리하는 게 바람직합니다.

 


[그림 2]

 

실체를 관리하는 엔터티나 기본 정보를 관리하는 엔터티, 기준 정보를 관리하는 엔터티는 이력 데이터를 원천 데이터와 같이 관리하지 않는 것이 좋습니다.

 

실체 데이터는 한 번 생기면 그대로 존재하는 것이어서, 특성(속성)이 바뀐다고 새로운 인스턴스로 생성하면 데이터 성격을 반영하지 못 한 것이라 하나의 인스턴스로 존재해야 하고요. 기본 정보나 기준 정보 또한 실체 성격을 포함하고 있기도 하고, 참조하기 좋아야 하기 때문에 그렇습니다.

 

행위 엔터티가 아닌데 일자 속성이 주 식별자에 존재하면 한번 더 고민하셔야 됩니다. 대개 이력 데이터를 포함시켜서 그렇게 되는데 바람직하지 않습니다.

 

쉽게 생각해서 참조되는 엔터티는 관계선을 표현할 수 있도록 설계해야 합니다. 조인해서 사용한다는 의미니까요. [그림 1]이라면 다른 엔터티와 조인해서 사용하기 매우 어려운 상태입니다. 약간씩 다르지만 [그림 3]도 역시 마찬가지로 모두 바람직하지 않습니다.

 

   

  

[그림 3]

 

일부 기본 정보를 관리하는 엔터티는 [그림 1]처럼 원천 데이터와 이력 데이터를 같이 관리할 수 있습니다. 굳이 나눠서 관리하면 엔터티 개수만 늘어나서 같이 관리할 수 있는데, 조인해서 사용하지 않을 때만 가능합니다.

 

[그림 4] 모델도 간혹 보는데, 많이 참조되는 주요 엔터티가 이렇게 설계되면 매우 난감해집니다. 어떻하든 사용은 가능하지만요.

 


[그림 4]



'데이터 Story > 데이터 상념(想念)' 카테고리의 다른 글

데이터에 대한 개인적인 비전  (0) 2018.06.23
데이터 아키텍트 프레임웍  (0) 2018.03.31
[worst practice 4]  (0) 2017.11.04
worst practice  (0) 2017.10.28
[worst practice 2]  (3) 2017.09.30
모델러의 상처  (0) 2017.09.25
블로그 이미지

블루퍼필

댓글을 달아 주세요

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

 

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

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

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

 

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

 

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

 

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



[그림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) 관계로 도출해야 하는 요건과 잘 연계하면 더욱 효율적인 모델을 설계할 수 있습니다.


블로그 이미지

블루퍼필

댓글을 달아 주세요