1.11. 실체 엔터티란?
- 실체의 정의를 사전에서 찾아보면 '실체의 물체 또는 외형에 대한 실상'이라고 나온다.
- 실체 엔터티는 간단히 만질 수 있는 것(tangible)을 관리하는 엔터티다.
- 1.5에서 설명한 보이는 것을 관리하는 엔터티가 실체 엔터티다.
- 엔터티를 분석하거나 설계할 때 해당 엔터티가 실체 엔터티인지를 가장 먼저 살펴본다.
- 주의할 점은 만질 수 있는 것에 대한 모든 데이터를 관리하는 것이 아니라 본질적인 데이터를 관리한다는 것이다.
- 실체의 존재와 연관된 데이터를 의미한다.
- 이름이나 주민등록번호, 나이 등 실체의 존재와 연관된 데이터를 관리하는 엔터티이지, 그 실체가 발생시킨 데이터를 관리하는 엔터티는 아니다.
- 예를 들면, 그 실체가 어떤 계약을 했는지, 어떤 불만을 얘기했는지, 얼마나 출금했는지 등을 관리하면 실체 엔터티가 아니다.
- 실체 자체의 존재와 연관된다는 점은 유념해야 한다.
- 간혹 실체 자체와 실체의 역할을 혼동할 때도 있다.
- 한 사원이 정규직이나 계약직이 될 수 있더라도 사원 실체는 하나다.
- 따라서, 실체 인스턴스는 하나이지 두 개가 아니다.
- 실체로 파악하면 인스턴스는 하나며, 역할로 파악하면 인스턴스는 두 개다.
- 만약, 역할로 파악해서 설계했다면, 실체 엔터티를 잘못 설계한 것이다.
- 실체 엔터티는 도출이 쉽지만 잘못 설계하면 업무 전체적으로 심각한 영향을 끼친다.
- 행위 엔터티는 실체가 발생시킨 엔터티고, 가공 엔터티는 실체나 행위 엔터티의 데이터를 가공한 엔터티이기 때문에 실체 엔터티가 가장 상단에 위치한다.
- 기준 엔터티도 실체와 연관된 기준일 때가 많다.
- 따라서, 대부분의 실체 엔터티는 행위 엔터티의 주체가 되며, 부모 엔터티가 존재하지 않는다.
- 실체 엔터티는 몇 가지 특징이 있다.
- 우선 실체 엔터티의 주 식별자는 단순해야 좋다.
- 고객번호와 같은 인조 식별자가 오히려 성격을 더 직관적이고 명확하게 해준다.
- 하나의 실체에 대해서 약속한 번호를 지정해 실체를 의미하도록 설계하면 효과적이다.
- 반면에, 행위 엔터티나 가공 엔터티에 인조 식별자를 사용하면 이해하기 어렵고 오용되는 경향이 있다.
- 그리고, 실체 엔터티는 다른 엔터티에 비해 더욱 과감한 통합이 필요하다.
- 본질을 관리하기 때문에 다른 엔터티에 비해 통합될 가능성이 높고 통합이 더욱 용이하다.
- 상단에서 실체 엔터티가 통합되면 전체 모델 구조가 단순해진다.
- 단순한 모델이 좋은 모델이 될 가능성이 높다.
- 실체 엔터티는 이력 데이터를 설계할 때도 주의해야 한다.
- 실체 엔터티는 물리적으로 존재하는 실체를 한나의 인스턴스로 관리하기 때문에 실체가 소멸되지 않는 한 지속해서 하나의 인스턴스로 관리해야 한다.
- 따라서, 실체 엔터티의 이력 데이터를 실체 데이터에 포함시키지 않도록 주의해야 한다.
- 다만 실체의 특정 속성이나 상태가 바뀔 수 있다.
- 이때는 실체를 의미하는 인스턴스 전체가 변하는 것이 아니라, 일부 특성이 변하는 것이다.
- 일부 속서에 대한 이력 데이터일 뿐 실체 자체에 대한 이력 데이터는 아니다.
- [그림 1.11]은 보이는 종류 중 하나인 사람을 관리하는 고객 엔터티다.
- [그림 1.11] 모델에서 주민등록번호가 변경될 때, [그림 1.12] 릴레이션과 같이 물리적으로 두 개의 인스턴스로 관리하는 것은 바람직하지 않다.
#고객번호 | 고객명 | 주민등록번호 | 고객상태코드 |
00001 | 홍길동 | 123456-7890123 | 변경 |
00002 | 홍길동 | 123456-7890123 | 정상 |
[그림 1.12] 실체 엔터티를 내역 엔터티인 것처럼 잘못 설계한 릴레이션
- 이처럼 관리하면 실제 고객의 개수와 고객 엔터티의 인스턴수 개수가 같지 않게 된다.
- [그림 1.13]과 같이 보이는 실체를 의미하는 원천 엔터티(고객)와 변경 데이터를 관리하는 이력 엔터티(고객주민등록번호이력)는 별도로 관리하는 것이 바람직하다.
- 고객 엔터티의 인스턴스는 실제 고객의 숫자와 같다.
- 고객의 이력 데이터가 고객의 숫자에 영향을 미치면 안된다.
- 실체 데이터는 주로 행위에 의해서 생긴다.
- 예를 들어, 펀드 계약 후에 펀드 계좌가 생긴다.
- 이때 펀드계약 엔터티는 있는데 펀드계좌 엔터티가 없는 경우가 있다.
- 계약과 계좌를 하나의 데이터로 보더라도 계약 엔터티보다는 계좌 엔터티로 설계하는 것이 바람직하다.
- 원인(계약)과 결과(계좌)를 별도로 관리하기도 하지만,
- 만약 하나만 관리한다면 결과를 관리하는 것이 좋다.
- 특히 보이는 것이라면 엔터티로 설계하는 것이 바람직하다.
- 대부분 최상위 엔터티인 실체 엔터티를 제대로 설계해야 전체 모델이 안정된다.
- 단순하게 설계할 수 있고, 그렇게 설계해야 하는 엔터티가 실체 엔터티다.
'데이터 모델링 > 모델링 노트 - 관계형 데이터 모델링' 카테고리의 다른 글
1. 엔터티 이야기(7) (1) | 2024.11.24 |
---|---|
1. 엔터티 이야기(5) (0) | 2024.11.22 |
1. 엔터티 이야기 (4) (1) | 2024.11.21 |
1. 엔터티 이야기(3) (1) | 2024.11.21 |
1. 엔터티 이야기(2) (0) | 2024.11.19 |