엔티티 도출과 엔티티명 정의 참고 원칙

 

엔티티 도출 원식은 데이터의 성격, 본질, 주제에 대한 정체성이 분명해야 합니다.

 

데이터 정체성

데이터 성격에 맞는 엔티티를 도출하는 것

명확하게 정의하는 것이 데이터 모델링에서 가장 중요

 

선수 데이터 관리 목적으로 설계된 릴레이션

선수 - 선수번호 PK / 선수이름 / 출신고교명 / 소속팀번호 / 소속팀명 / 주장선수번호 / 리그번호 / 리그명

 

주 식별자를 봐야지만 선수 데이터를 관리하는 릴레이션인지 추측할 수 있을 정도록 주제가 섞여있다.

팀에 대한 데이터, 리그에 대한 데이터 이런 경우 정규형도 아니며 주제가 섞여 있어 엔티티가 잘못 도출된 것이다.

 

여러 데이터가 혼합된 형태는 뷰로 사용되 수 있습니다.

원천 데이터는 개별적인 엔티티에 존재하고 위 릴레이션 같은 형태는 뷰를 만들어 데이터를 제공하는 것이 좋습니다.

 

데이터 종속성에 의해 하나의 주제만 관리하는 성격이 명확한 엔티티는 다른 성격의 데이터를 관리해야 할 때 확장이 좋습니다.

 

엔티티 무결성

데이터 본질에 합당하도록 엔티티를 도출하는 것이 중요합니다.

주 식별자가 존재하도록 엔티티를 도출하는게 기본 원칙. 무결성을 지키기 위한 근본 원칙입니다.

 

주 식별자는 데이터 모델링의 기반으로 물리적인 키(Primary Key)가 존재해야 하며 엔티티의 인스턴스를 식별할 수 있는 식별자(Identifier)가 존재해야 합니다.

 

엔티티 유일성

동일한 성격의 데이터는 전체에서 유일해야 합니다. 데이터 통합과도 관련.

유사 성격의 엔티티가 많으면 데이터 무결성을 저하시킬 수 있으며 관리에도 좋지 않습니다.

 

데이터 혼용 배제

유사 데이터를 통합하는 것이 엔티티 도출의 중요 원칙인 것처럼 한 엔티티에 서로 다른 성격의 데이터를 혼용해서는 안됩니다.

이는 데이터 정체성에 맞게 도출해야 한다는 원칙과 비슷합니다.

여러 종류 데이터가 관리되는 원인은 정체성에 맞는 엔티티를 도출하지 않은 것이 가장 큰 원인입니다.

 

타 엔티티와 관계 존재

엔티티는 다른 엔티티와 관계가 존재하는 것이 일반적입니다.

종속 엔티티는 부모 엔티티와 관계가 자립 엔티티도 여러 참조 관계가 존재합니다.

 

프로세스 도출 지양

엔티티 도출 시 자주 발생하는 것이 프로세스에 따라 엔티티가 만들어지는 것입니다.

같은 주제를 표현한 데이터지만 프로세스에 따라 변하는 상태를 엔티티로 도출하거나 특정 프로세스를 처리하기 위한 화면에 따라 엔티티를 도출하면 안됩니다.

 

데이터 모델에는 순서인 프로세스가 없습니다. 어떤 것이 먼저 발생하고 어떤 것이 나중에 발생하는 순서가 없습니다.

데이터는 프로세스나 시간 흐름과 무관하게 결과로만 데이터가 존재합니다.

 

프로세스에 따라 엔티티가 도출되면 프로세스 변화에 따라 엔티티 관계가 바뀔 수 밖에 없어 유연하지 않은 모델이 됩니다.

 

아래와 같은 프로세스가 있고 엔티티를 도출했다면

계약요청 -> 계약승인 -> 계약

 

아래와 같이 프로세스 변화가 발생할 때 새로운 엔티티를 추가해야 하며 관계가 조정돼야 합니다.

더 이상 사용하지 않는다면 엔티티 삭제와 관계 조정이 불가피해집니다.

만약 계약요청 -> 계약 외부검토 -> 계약승인 -> 계약

 

프로세스 상태에 따라 엔티티가 생성, 삭제되는 모델은 확장성 없는 유연하지 않은 모델로 통합 엔티티로 관리하는 것이 좋습니다.

계약 - 계약상태 (요청 / 승인 / 계약)

 

화면 도출 지양

프로세스에 따라 엔티티 도출하는 것과 유사하게 화면에 따른 엔티티 도출도 자주 발생된다.

물품 구매 요청 화면, 승인 화면, 최종 계약 화면이 개별로 존재해서 엔티티도 개별로 존재하는 경우가 있다.

 

유사한 데이터를 보여주는 화면이 통합되지 않고 여러 개로 화면에 따라 엔티티 도출은 지양해야 합니다.

특히 집계 데이터는 집계 화면에 따라 도출되는 경우가 많습니다.

 

가능한 원천 데이터를 사용해 결과를 보여주는 것이 좋으며 성능상 문제가 되면 계산용 요약 엔티티를 사용해야 하는데 이것도 최소한의 요약 엔티티를 통해 많은 화면을 처리할 수 있도록 설계해야 합니다.

 

데이터 관리 요건

데이터로 관리할 필요가 있어야 엔티티로 도출하는 것이 기본 원칙입니다.

관리할 필요가 없는 데이터를 엔티티로 관리할 때가 존재합니다.

 

예를들어 입고, 출고가 있는 업무에서 언제 입고한 것인지 언제 출고했는지 알 필요가 없다면 입고별출고 엔티티를 별도로 관리할 필요가 없습니다.

 

엔티티 명

데이터 모델링에서 가장 중요한 것 중 하나가 엔티티를 정의하는 것입니다.

엔티티 정의는 엔티티에 대한 설명을 의미하는 것이 아니라 엔티티가 어떤 집합으로 이루어져 있는지를 선언하는 거입니다.

 

엔티티 명이 잘못 선언되면 이미 엔티티의 정의가 잘못된 것이나 같습니다.

 

엔티티 정의는 어떤 데이터 집합과 데이터 속으로 구성되는지가 핵심입니다.

집합의 속성이 어떻게 구성되는지 그 집합 결정자에 따라 결정합니다.

집합을 식별할 수 있는 식별자가 무엇인지 자연스레 엔티티를 정의하면서 결정됩니다.

 

엔티티를 정의하고 모든 속성을 도출한 후 속성 중에 대표 성격의 속성(식별자)를 정하는 방법도 있습니다.

하지만 필자(관계형 데이터 모델링)는 엔엔티티 정의와 주 식별자 정의가 하나라고 생각합니다.

 

엔티티 명을 정하는 것도 엔티티의 정의나 결정자 식별과 동시에 이루어집니다.

엔티티명은 자신의 데이터 집합에 대한 이름이기도 하고 다른 엔티티가 바라보는 이름이기도 합니다.

 

엔티티명을 정하는 가장 중요한 원칙은 관리하고자 하는 데이터의 성격(주제)를 가장 잘 표현하는 이름으로 정해야 합니다.

 

교차 엔티티의 이름은 양쪽 부모 엔티티의 연관성을 표현할 수 있게 정해야 합니다.

주문 엔티티와 상품 엔티티의 교차 엔티티는 주문상품이 적합합니다.

 

엔티티 명을 정할 때도 확장성을 고려해서 정하는 것이 좋으며 이것은 데이터 통합을 고려해야 한다는 의미와 같습니다.

예를들어 개인고객으로 정하는 것보단 고객으로 정해 법인 고객과 개인 사업자 고객을 모두 관리할 수 있는 것도 대비하는 것이 좋습니다.