태터데스크 관리자

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

태터데스크 메시지

저장하였습니다.

'실체엔터티'에 해당되는 글 5건

요건은 아래와 같습니다.

 

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

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

 

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

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

 

 


[그림 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고객실체 엔터티는 실체인 고객 데이터를 관리하는 실체 엔터티다.

 

[그림1]

 

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

 

[그림2]

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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



블로그 이미지

블루퍼필

댓글을 달아 주세요

보이거나 만질 수 있는 실제의 물체(物體)를 나타내는 데이터는 실체 엔터티로 설계한다.

 

엔터티를 정의할 때 엔터티에서 관리하는 데이터가 실제로 존재하는 물체인지, 만질 수 있는 물건인지를 가장 먼저 따져서 실체를 나타낸다면 실체 엔터티로 설계한다. 실체 엔터티는 엔터티 명에 실체접미어를 붙인다.

 

[그림1] 서적실체 엔터티는 만질 수 있는 실체인 책을 관리하는 엔터티다.


[그림1]

 

서적실체 엔터티는 실체 엔터티이기 때문에 엔터티 명에 실체접미어를 붙인다.

 

책을 한 권씩 개별적으로 다룬다면 서적실체 엔터티가 필요하다. 바코드 정보가 있어 해당 책을 관리할 수 있다.

 

하지만 서적실체 엔터티에는 책에 대한 이름이나 저자 등과 같은 기본 정보가 없다. 이런 정보는 책을 상징하는 정보로서 실체 정보는 아니다. [그림1] 서적실체 엔터티의 도서번호 속성이 책에 대한 개념 정보를 나타내는 관계 속성이다.

 

책에 대한 개념을 관리하는 도서 엔터티는 아래와 같다.

[그림2]

 

도서 엔터티는 책에 대한 개념을 의미하며, 낱권의 책을 의미하지 않는다. 따라서 실체 엔터티가 아니다. 따라서 엔터티 명에 실체접미어를 붙이면 안 된다.

 

책에 대한 개념과 실체를 관리하는 모델은 아래와 같다.


[그림3]


업무에 따라 도서에 대한 개념을 나타내는 도서 엔터티만 필요할 수 있으며, 낱권의 책인 실체를 관리하는 서적실체 엔터티까지 필요할 수 있다.

 

실체 엔터티는 보이고 만질 수 있는 것(Tangible)을 관리하는 엔터티다. 물체를 관리하는 엔터티가 실체 엔터티다. 노트북, 자동차, 창고, 카드 등이 만질 수 있는 물체다.

 

실체 엔터티는 엔터티의 성격이 명확한데다 중요하게 사용될 수 있기 때문에 설계를 명확하게 해야 한다. 행위의 주체와 대상이 될 수 있는 실체 엔터티가 불분명하면 하위 엔터티와의 관계도 명확하지 않게 된다.


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

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

블루퍼필

댓글을 달아 주세요

실체의 본질적인 성격이나 특성을 관리하는 엔터티가 아닌, 실체가 하는 역할을 관리하는 엔터티의 이름은 대상 실체 엔터티 명+역할 의미+담당 실체 엔터티 명형식으로 정한다.


즉 양쪽 실체 엔터티 명(실체라는 접미어를 제외한 명)과 실체가 하는 역할을 의미하는 단어를 사용해서 엔터티 명을 정한다. 이 엔터티는 실체 자체를 의미하지 않으므로 엔터티 명에 접미어 실체를 붙이지 않는다.

 

[그림1] 계좌관리사원 엔터티는 계좌를 관리하는 역할을 하는 사원을 관리하는 엔터티다.

[그림1]

 

계좌를 관리하는 사원이든, 사원에게 관리되는 계좌이든 실체 자체를 의미하지 않고, 실체의 역할을 의미한다. 역할을 담당한 실체는 사원이기 때문에 ‘~사원처럼 엔터티 명을 정하며 관리라는 역할의 대상은 계좌. 따라서 엔터티 명은 계좌관리사원이 된다. 계좌관리사원 엔터티는 실체 자체를 나타내지 않기 때문에 ‘~실체라는 접미어를 붙이지 않는다.

 

대상 실체 엔터티 명+역할 의미+담당 실체 엔터티 명형식으로 엔터티 명을 정할 때 역할을 의미하는 단어 앞에는 역할에 대한 대상 실체를 나타내는 엔터티 명을 사용하고, 뒤에는 역할을 담당한 실체를 나타내는 엔터티 명을 사용한다.

 

[그림2] 프로젝트수행사원 엔터티는 프로젝트를 수행한 사원을 관리하는 엔터티다.

[그림2]

 

대상 실체 엔터티 명+역할 의미+담당 실체 엔터티 명형식으로 엔터티 명을 정할 때, 역할을 의미하는 용어는 수행이며, 프로젝트를 수행한 것이기 때문에 수행에 대한 대상인 프로젝트수행앞에 사용하며, ‘수행이란 역할을 담당한 것은 사원이기 때문에 사원을 뒤에 사용해서 프로젝트수행사원으로 정한다.

 

엔터티에서 관리하는 데이터가 실체 자체가 아니라 실체가 하는 역할을 의미한다면 실체 엔터티로 정의하지 않는다. 실체 자체를 관리하는 엔터티와 실체를 의미하지만 실체 자체를 관리하는 것이 아닌 실체와 연관된 데이터를 관리하는 엔터티는 구별해야 한다. 후자를 실체 자체로 정의하지 않아야 한다. 자연히 후자일 때는 엔터티 명에 접미어인 ‘~실체를 붙이지 않는다.



 

블로그 이미지

블루퍼필

댓글을 달아 주세요

실체 엔터티는 실체 엔터티임을 명확하게 구분하기 위해서 엔터티 명에 실체라는 단어를 접미어(Suffix)로 붙인다. 그리고 접미어 앞에는 엔터티 성격을 나타내는 명사형의 단어를 사용한다.

 

[그림 실체엔터티명] 장비실체 엔터티는 장비를 관리하는 엔터티다.

  

[그림 실체엔터티명]

 

장비실체 엔터티는 장비라는 만질 수 있는(Tangible) 실제의 물체(物體)를 관리하는 엔터티로 실체 엔터티다. 명사형인 장비와 접미어인 실체를 붙여 장비실체로 엔터티 명을 정한다.

 

명사형과 동사형의 단어를 구분하는 방법은 ‘~했음을 붙여 자연스러우면 명사형이 아니라 동사형이다. ‘장비라는 단어는 명사형이기 때문에 ‘~했음을 붙이면 의미가 통하지 않는다. ‘~했음을 붙여 의미가 통하는 동사형의 단어는 행위 엔터티에 사용한다.

 

엔터티 명에는 엔터티의 종류를 나타내는 접미어를 사용하지 않는 것이 바람직하지만, 실체 엔터티는 대개 핵심 엔터티이기 때문에 지속적으로 관리하기 위해 엔터티 명을 분명하게 구분하는 것이 의미가 있다. 추후에 실체 엔터티만을 뽑아서 검증할 수도 있고, 모델링 중에도 지속적으로 인지할 수 있어 엔터티를 잘못 설계하는 오류를 최소화할 수 있다.

 

또한 엔터티 정의를 명확하게 하는 효과도 있다. 실체 엔터티 명에 ‘~실체라는 접미어를 붙이면, 엔터티 명에 엔터티의 성격이 포함돼 있어 엔터티 정의가 더욱 명확해진다.


블로그 이미지

블루퍼필

댓글을 달아 주세요