태터데스크 관리자

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

태터데스크 메시지

저장하였습니다.

원천 엔터티가 실체 엔터티일 때는 변경이력 데이터를 별도의 엔터티에서 관리하도록 설계한다.

 

[그림1고객실체 엔터티는 실체인 고객 데이터를 관리하는 실체 엔터티다.

 

[그림1]

 

만약 고객명 속성이나 전화번호 속성의 변경이력 데이터를 관리할 때, 고객은 실체이기 때문에 아래 모델처럼 별도의 엔터티에서 변경이력 데이터를 관리하도록 설계한다.

 

[그림2]

 

고객실체 엔터티의 속성 중에서 하나라도 변경되면, 그 시점의 고객실체 엔터티 인스턴스는 고객실체이력 엔터티로 이동한다.

 

고객실체이력 엔터티는 변경된 과거 데이터이므로 주로 사용되지 않으며, 필요 시에만 참고 용도로 사용하기 위해 보관하는 역할을 한다.

 

실체 엔터티는 실체에 대한 개별 인스턴스를 관리하는 엔터티다. 실체 엔터티에서 실체의 변경된 데이터까지 관리한다면, 이미 실체 자체를 의미하는 것이 아니라서 엔터티의 정의가 달라진다.

 

실체 엔터티에서는 실체의 존재 자체를 관리해야 하므로 실체 엔터티의 인스턴스 개수와 실제 실체의 개수가 같아지도록 관리하는 게 바람직하다.

 

없어진 실체에 대해서는 해당 인스턴스를 삭제하지 않기 때문에 인스턴스 개수와 현재 존재하는 실체의 개수가 달라질 수 있지만, 이를 감안해서 존재했던 실체의 개수와 엔터티의 인스턴스 개수는 일치해야 한다.

 

대부분의 데이터가 그렇지만 특히 실체를 관리하는 데이터는 현재의 최종 데이터를 주로 사용하기 때문에 변경된 과거 데이터를 함께 관리하지 않는다. 자주 사용하지 않는 데이터를 실체 엔터티에 포함시키는 것은 효율적이지 않다.

 

더구나 실체 엔터티는 하위 엔터티가 많기 때문에 실체 엔터티에 변경이력 엔터티를 포함시키면 하위 엔터티와의 관계 때문에 데이터를 관리하기 복잡해진다.

 

만약 실체 엔터티임에도 불구하고 변경이력 데이터를 최종 데이터와 함께 자주 사용하거나, 변경된 인스턴스에 대해서도 하위 인스턴스와 관계가 필요하다면 실체 엔터티에 변경이력 데이터를 포함시킬 수 있다.



블로그 이미지

블루퍼필

댓글을 달아 주세요

서브타입을 설계할 때는 특정 시점을 기준으로 설계하기 때문에 변경이력 데이터를 포함시키지 않고 현재 시점의 데이터로 판단한다.

 

서브타입이 배타 서브타입인지 중복 서브타입인지는 특정 시점을 기준으로 판단한다. 특정 시점에 어느 하나의 서브타입에만 속하는지(배타 서브타입) 여러 서브타입에 속할 수 있는지(중복 서브타입)에 따라 서브타입의 유형이 정해진다.

 

따라서 과거 데이터인 변경이력 데이터는 제외하고 현재 시점을 기준으로 판단해서 서브타입 유형을 설계한다.

 

데이터 성격이나 업무 요건은 서브타입 간에 중복 데이터가 없어야 하는데 변경이력 데이터로 인해 중복된 것처럼 보이는 경우가 있기 때문에 주의해야 한다.

 

사원은 정규직이거나 임시직이어야 한다는 업무 요건이 있다면, 아래 모델처럼 배타 서브타입으로 설계해야 한다.

 

[그림 사원-배타서브타입]

 

하지만 [그림 사원릴레이션] 릴레이션과 같이 사원유형코드 속성 값이 변했을 때도 같은 릴레이션에서 관리하면, 즉 변경이력 데이터를 같이 관리하면 서브타입 모델에 왜곡이 생길 수 있다.

 

[사원]

#사원번호

사원명

주민등록번호

입사일자

사원유형코드

12345

홍길동

1234567890123

2021-07-07

정규직

67890

이길동

6789012345678

2023-01-02

정규직

23456

홍길동

1234567890123

2028-03-05

임시직

[그림 사원릴레이션]

 

사원 엔터티의 릴레이션이 위와 같을 때, 데이터만으로 판단하면 홍길동은 정규직과 임시직 인스턴스가 동시에 존재하기 때문에 배타 서브타입이 아니다.

 

하지만 첫 번째 인스턴스는 변경이력 성격의 데이터다. 과거에 정규직으로 근무했던 기록으로 현재 시점에서는 죽어 있는 데이터다. ‘홍길동에 대해 현재 시점에 유효한 데이터는 세 번째 인스턴스뿐이다.

 

이력 데이터인 첫 번째 인스턴스가 없다면, 업무 요건을 그대로 반영한 배타 서브타입이 된다. 즉 데이터를 제대로 해석하면 배타 서브타입이 된다.

 

[그림 사원릴레이션] 릴레이션은 변경이력 데이터 때문에 어떤 서브타입인지 혼란스러울 수 있는 릴레이션이다. 업무 요건에 따라서 홍길동이 동시에 정규직이면서 임시직인 상태는 없기 때문에 배타 서브타입이 되도록 설계해야 한다. 그렇게 하려면 아래 릴레이션처럼 변경이력 데이터는 별도의 릴레이션에서 관리하는 것이 명확하다.

 

[사원]

#사원번호

사원명

주민등록번호

입사일자

사원유형코드

67890

이길동

6789012345678

2023-01-02

정규직

12345

홍길동

1234567890123

2028-03-05

임시직

[사원이력]

#사원번호

#변경일자

사원명

주민등록번호

입사일자

사원유형코드

12345

2028-03-05

홍길동

1234567890123

2021-07-07

정규직

[그림 사원릴레이션2]

 

사원 릴레이션의 서브타입은 배타 서브타입이다.

 

위와 같이 변경이력 데이터를 분리해서 설계하지 못하는 상황이라도, 서브타입이 배타 서브타입인지를 설계하는 기준은 특정 시점이기 때문에 현재 시점에서 업무적으로 중복된 데이터가 없어야 한다면 [그림 사원-배타서브타입] 모델과 같이 배타 서브타입으로 표현한다.

 

배타 서브타입인지 중복 서브타입인지를 판단하는 기준은 특정 시점이며, 변경이력 데이터 때문에 중복 서브타입처럼 보일 수 있다는 것을 주의해서 설계에 반영해야 한다.



 

'데이터 Story > 모델링 매뉴얼' 카테고리의 다른 글

실체 엔터티의 변경이력 엔터티 설계  (0) 2017.03.22
관계 엔터티 설계  (2) 2017.03.09
배타 서브타입 설계  (0) 2017.02.16
실체 엔터티 설계  (0) 2016.12.29
종속 엔터티의 엔터티 명  (0) 2016.12.08
기준 엔터티의 엔터티 명  (0) 2016.12.01
블로그 이미지

블루퍼필

댓글을 달아 주세요

그럼 [그림5] 환율 엔터티는 내역 엔터티일까요? 이력 데이터일까요? 환율은 기준 통화에 대한 상대 통화의 교환 비율인데요. 기본적으로 매일 관리하기 때문에 기준일자를 관리합니다. 원화에 대한 달러의 2 15일 환율 데이터가 생성되고, 16일 환율도 생성되는 등 주 식별자에 따라 데이터가 생성되니 내역 데이터입니다.

 

환율을 관리하는 원천 엔터티이니 발생 내역 엔터티입니다. 환율 같은 엔터티를 이력 엔터티로 생각하는 경우가 많습니다.


 

[그림5]

 

이미 존재하는 15일 환율이 바뀌고, 바뀌기 전 데이터를 관리해야 한다면 [그림6]과 같이 이력 엔터티가 있어야 됩니다.


 

[그림6]

 

그리고 또 많이 혼돈하는 엔터티가 학력이나 회사경력 같은 엔터티입니다. [그림7]과 같은 고객의 학력을 관리하는 엔터티는 주 식별자가 고객번호+졸업년도정도입니다.


 

[그림7]

 

고객을 기준으로 본다면 학력이 계속 바뀐 것이므로 이력 데이터가 될테지만, 학력 엔터티의 주 식별자는 고객번호+졸업년도입니다. 고객번호와 졸업년도에 따라 생성되므로 내역 데이터입니다.

 

내역 데이터는 현재 살아 있는 데이터입니다. 주 식별자 데이터를 기준으로 유효한 인스턴스가 살아 있는 데이터입니다. ‘123’ 고객의 1995년을 기준으로 본다면 살아 있는 상태며, 현재도 유효한 상태이므로 내역 데이터입니다.

 

학력 엔터티를 이력 데이터라고 생각하는 경우도 많은데요. 적어도 제가 설명하는 기준으로 학력 엔터티는 원천 데이터를 관리하는 내역 데이터입니다. 아마 학력 엔터티를 이력 엔터티라고 생각하면 이력 데이터를 분간하기 어려울 것입니다.

 

이렇게 과거 히스토리를 관리하는 데이터는 일반적으로 이력 데이터가 발생하지 않습니다. 결과를 관리하기 때문에 변경되는 요건이 발생하지 않습니다. 다만 정정이 발생할 수는 있습니다. 정정에 대해서는 다음에 다시 설명하겠습니다.

 

간혹 원천 데이터와 이력 데이터를 혼합해서 한 엔터티에서 관리하는 예가 있는데요. 나중에 설명하겠지만 이런 방법이 효율적일 때가 있지만 대부분 혼란스럽기 때문에 주의해야 합니다. 데이터 모델은 명료한 게 가장 좋은 거 같습니다. 오해의 소지가 있으면 한 없이 오용할 수 있기 때문에요.

 

[그림8] 모델과 같이 주문 엔터티에서 내역과 이력을 동시에 관리하면 혼란스러워서 바람직하지 않습니다. 위의 [그림1]과 같이 원천 데이터를 먼저 도출한 후에 이력 데이터를 따져야 합니다.


 

[주문]

#고객번호

#상품번호

#변경일시

주문수량

123

A001

2025-02-21 13:25:20

1

123

A001

2025-02-21 17:17:17

2

 

[그림8]

 

주문 엔터티는 보통 위와 같이 내역+이력 데이터를 혼합해서 사용하지 않습니다. 주문 엔터티의 주 식별자는 주문번호가 일반적인데요. 예를 들어 주문 수량이나 배송지를 수정한다고 해서 주문번호를 새로 생성시키지 않습니다. 그렇게 되면 하위의 모든 데이터도 생성해야 되고, 고객에게 전달됐을 고객번호를 다시 전달해야 하고요. 혼란스럽죠. 택배 쪽하고도 커뮤니케이션이 혼란스러울 것입니다.

 

주문번호는 변하지 않고 내용(속성)만 변경하는 것이 명료하다고 생각합니다. 따라서 [그림9]와 같이 이력 데이터를 관리하게 됩니다.

 

 

[주문]

#주문번호

고객번호

상품번호

주문일자

주문수량

100001

123

A001

2025-02-21

2

 

[주문이력]

#주문번호

#변경일시

주문수량

100001

2025-02-21 17:17:17

1

 

[그림9]

 

또한 변경일시를 사용하면 어떤 인스턴스가 원천 데이터, 즉 내역 데이터인지 어떤 인스턴스가 변경 이력 데이터인지 구분해야 합니다. 별도의 속성으로 구별할 수 있지만 직관적이지 않고 대부분 내역으로 생각할 것이므로 오용의 소지가 있습니다. 원천 데이터가 흔들릴 수 있으므로 신중하게 사용해야 합니다.

 

변경된 데이터인지에 대한 판단 기준은 해당 엔터티입니다. 해당 엔터티가 원천 데이터인지를 먼저 판단해야 하고요. 그리고 주 식별자에 종속된 속성이 변경돼야 변경 이력이 됩니다. 새로운 주 식별자 데이터를 발생시키면서 데이터를 쌓는 것은 발생 내역입니다.


블로그 이미지

블루퍼필

댓글을 달아 주세요

지난 글에서 이력 데이터의 성격에 대해 간략하게 설명드렸습니다. 다시 정리하면 변경되는 데이터가 이력 데이터이고요. 쌓이는 데이터는 내역 데이터입니다.

 

그리고 원천(본질) 데이터인지를 구별하는 것이 중요합니다. 원천 엔터티를 도출하고 이력엔터티를 분석해야 하고요. 발생 내역인 원천 데이터가 변경되면, 변경 전의 데이터를 관리해야 이력 데이터 관리라고 합니다.

 

저는 변경이력발생내역이라는 용어로 구분합니다. 지난 번에 언급했듯이 이력이라는 용어는 상당히 애매합니다. 과거 데이터라는 포괄적인 의미를 지니고 있습니다. 영어로 표현하면 Time-Dependent Data, Historical Data 정도가 되는데요

 

하지만 데이터 모델에서 말하는 이력은 단순히 쌓여있는 과거의 데이터가 아니라 변경된 과거 데이터입니다. 과거 데이터라도 본질(원천) 데이터일 수 있습니다. 죽어 있는 데이터가 우리가 말하는 이력 데이터입니다.

 

제가 두어 명에게 이 내용을 설명했는데 이해시키는 데 실패했습니다. 그래서 책에서도, 블로그에서도 반복적으로 쓰고 있습니다. ㅎㅎ

 

다양한 예제로 설명하겠습니다.

 

[그림1]은 단골로 출연하는 주문 엔터티입니다. 같은 상품은 하루에 한 번만 주문할 수 있다고 가정하겠습니다. 이 엔터티의 주 식별자는 고객번호+상품번호+주문일자입니다. 주 식별자는 인스턴스를 생성하는 기준이 됩니다. 따라서 이 주 식별자대로 데이터가 생성되는 내역 데이터입니다. 그다지 따지지 않아도 원천 엔터티라는 것을 알 수 있습니다.


 

[그림1]

 

간혹 해당 주 식별자(고객번호+상품번호+주문일자)가 아닌 고객번호 속성 하나에 대한 종속성을 기준으로 상품번호와 주문일자가 바뀌므로 이력이라고 확대 해석하는 경우가 있습니다. 임의의 속성이 종속성을 판단하는 기준이 아니라 해당 주 식별자가 기준이 됩니다. 해당 엔터티가 분석 대상입니다.

 

따라서 주문 엔터티에 인스턴스가 발생되는 것은 내역 데이터입니다. 만약 이 주 식별자에 종속된 속성 값이 바뀌면 이력 데이터가 됩니다. 즉 주문수량이 변경되면 이력 데이터에 대한 고민을 하게 됩니다.

 

업무가 변경돼서 하루에 같은 상품을 여러 개 주문할 수 있다고 가정하면요. ‘123’ 고객이 2025 2 21일 주문한 ‘A001’ 상품을 몇 시간 후에 하나 더 추가하는 것으로 주문을 변경했다면 주문 엔터티의 주문수량 데이터를 ‘2’로 변경해야 됩니다.

 

이때 기존에 ‘1’이었던 데이터를 관리해야 하면 이력 데이터를 관리하는 것입니다. 그냥 ‘2’로 업데이트하고 끝이라면 이력 데이터는 관리하지 않는 것입니다. 아래의 주문이력 엔터티는 불필요합니다.

 

이력 데이터를 관리할 때는 [그림2]와 같습니다.


 

[주문]

#고객번호

#상품번호

#주문일자

주문수량

123

A001

2025-02-21

2

 

[주문이력]

#고객번호

#상품번호

#주문일자

#변경일시

주문수량

123

A001

2025-02-21

2025-02-21 13:25:20

1

 

[그림2]

 

[그림3] 왼쪽 모델에서 상품 가격은 기본적으로 상품 엔터티와 일대일 관계입니다. 더 정확하게 얘기하면 상품번호를 알면 유일하게 하나의 가격이 정해지는, 상품번호에 종속된 속성입니다.

 

주 식별자인 상품번호 속성에 종속된 상품가격 속성 값이 변경되면 이력 데이터가 생깁니다. 오른쪽 모델과 같습니다.

 

    

[그림3]

 

만약 매일 변할 수 있는 상품 가격을 관리하겠다라는 요건이 있다면 [그림4]와 같은 상품가격 엔터티가 필요합니다. 이 엔터티의 주 식별자는 상품번호+기준일자정도가 됩니다. 상품 엔터티에는 상품가격 속성이 없고, 주 식별자에 유니크하게 상품가격 엔터티에 데이터가 생성되므로 내역 데이터가 됩니다. 상품 가격을 관리하는 원천 엔터티가 됩니다.


 

[그림4]

 


블로그 이미지

블루퍼필

댓글을 달아 주세요