엔터티 도출 원칙 2

 

-      데이터 정체성

-      엔터티 무결성

-      엔터티 유일성

-      데이터 혼용 배제

-      타 엔터티와 관계 존재

-      프로세스 도출 지양

-      화면 도출 지양

-      데이터 관리 요건

 

관계(Relationship)도 엔터티 도출의 중요한 요소인데요. 엔터티는 보통 타 엔터티와 관계가 존재하는 것이 일반적입니다. 그래서 표현상의 약속을 제외하고 다른 엔터티와 관계가 존재하지 않으면 그 엔터티의 성격에 대해서 다시 한 번 살펴야 합니다.

 

하지만 이 부분이 지나치게 강조돼 전체 엔터티가 관계선으로 연결돼 있지 않으면 잘못된 모델이라고 단정하는 때가 있습니다. 잘못된 생각입니다. 관계 장에서 자세하게 설명하겠지만 관계가 무조건 존재해야 하는 것은 아닙니다. 기준 엔터티 등은 관계가 존재하지 않을 수 있으며 참조 무결성을 엄격히 적용한다면 많은 엔터티가 관계 없이 고립될 수 있습니다.

 

그리고 프로세스에 따라 엔터티를 도출하는 경향이 많은데요. 간혹 판단이 어려울 때가 있지만 일반적으로는 프로세스와 엔터티는 별개입니다. 같은 주제를 표현한 데이터지만 프로세스에 따라 변하는 상태를 엔터티로 도출하거나, 특정 프로세스를 처리하기 위한 화면에 따라 엔터티를 도출하면 안 됩니다. 프로세스에 따라 엔터티가 별도로 도출되면 프로세스의 변화에 따라 엔터티 관계가 바뀔 수밖에 없어 유연하지 않은 모델이 됩니다.

 

[그림1]은 비품을 요청하고, 요청을 승인하고 계약해서 구매하는 프로세스를 보여줍니다. 속성은 품목·수량·사용부서 등으로 유사하고 상태가 명확히 존재합니다. 세 개의 프로세스에 따라 새 개의 엔터티를 도출했습니다.

 

[그림1]

 

그런데 만약 요청 후 승인하기 전에 어떤 프로세스가 추가되면 [그림2]와 같이 엔터티가 중간에 끼어들어가야 됩니다. 또는 반대로 승인 프로세스가 없어져도 마찬가지로 곤란해지고요. 이런 불상사가 없더라도 속성이 유사하고 일대일인 관계의 엔터티를 나누는 것이 바람직하지는 않은 거 같습니다.

 

[그림2]

 

이처럼 프로세스 상태에 따라 엔터티가 생성되고 삭제되는 모델은 확장성이 없는 유연하지 않은 모델입니다. [그림3]과 같은 개념으로 접근하는 게 효율적입니다.

 

[그림3]

 

하나의 프로세스가 하나의 엔터티가 될 수는 있지만 일반적이지 않으니 주의해야 합니다. 프로세스가 아닌 데이터 성격을 기준으로 엔터티를 생성하는 것이 원칙입니다. 프로세스는 속성으로 표현될 수 있습니다.

 

프로세스와 마찬가지로 화면별로 엔터티를 만드는 경우도 빈번합니다. 하나의 화면에 하나의 엔터티를 매핑해 도출되는 것은 지양해야 합니다. 화면은 뷰(View)일 뿐이고 대부분 엔터티와 일대일로 매핑되지 않습니다.

 

마지막으로 너무 기본적인 사항인데요. 데이터베이스에서 관리하려는 데이터를 엔터티로 도출해야 합니다. 관리할 필요가 없는 데이터를 엔터티로 관리할 때가 간혹 존재합니다. 필요가 없다는 것은 필수적이지 않다는 것입니다. 통합이 덜된 엔터티나 중복으로 존재하는 엔터티까지 범위를 넓히면 매우 많고, 그게 아니라도 간혹 사용하지 않는 데이터가 엔터티로 존재합니다. 물론 요건이 없더라도 데이터를 더욱 상세하게 관리해야 하는 경우가 존재할 수 있습니다. 하지만 요건이 데이터 관리의 기준이 되므로 필요 없는 데이터를 관리하지 않아야 합니다.

 

이상으로 몇 가지 엔터티 도출 원칙을 설명했습니다. 다시 강조하지만 가장 중요한 원칙은 성격·본질·주제에 따른 정체성이 분명한 엔터티로 도출하는 것입니다.