Entity 이름

Entity는 데이터 모델링을 수행한 사람만 보는 것이 아니다. 그러므로 Entity에는 표준화된 이름의 사용이 권장된다. 용어사전, Domain(Data Type 지정)을 이용해 누가 보더라도 이해할 수 있고 커뮤니케이션(Communication)이 가능하도록 Naming Rule을 정하도록 한다([그림1] 참조)

• [그림1] Entity Naming Rule
• 

Entity 검증

그럼 Entity 검증에 대해 살펴보자. Entity를 도출한 후에는 모든 Entity에 대해 검증을 수행해야 한다. 이와 같은 검증 단계를 수행한다면 시간이 소요되겠지만, 데이터 모델링에서 가장 중요한 Entity 도출을 좀더 정확하게 수행할 수 있다([그림 2] 참조).

• [그림2] Entity 검증
• 

Entity 분할

Entity 분할은 하나의 Entity를 여러 개의 작은 Entity로 분리하는 것을 의미한다. 이와 같이 Entity 분할을 수행하는 이유는 다음과 같다.

• - 중복된 데이터 제거 : 중복된 데이터 제거를 통해 데이터 정합성을 강화시키며 이는 정규화와 유사한 과정이 된다.
• - 자주 사용되지 않는 Attribute 분리 : 자주 사용하지 않는 Attribute를 다른 Entity로 분리해 성능을 향상시킨다.
• - 유사 데이터를 분리 : 유사 데이터를 별도의 Entity로 분리해 관리 및 성능을 고려한다.

• [그림3] Entity 분할 수행 이유
• 

우리는 이와 같은 이유에서 Entity 분할을 수행하게 된다. 그럼 그 중 하나인 Subset에 의한 분할을 확인해 보자. Subset에 의한 분할은 데이터만 분할하는 것을 말한다. 예를 들어 계좌 Entity에서 법인 계좌와 개인 계좌 데이터를 분리한다고 가정하자.

렇다면 [그림4]의 예제와 같이 법인 계좌 Entity와 개인 계좌 Entity를 도출할 수 있을 것이다. 이와 같이 하나의 Entity에 동일한 형태의 데이터가 하나의 Attribute로 몇 개로 분리될 수 있을 경우 subset에 의한 분할을 고려할 수 있게 된다.

• [그림4] 법인계좌 Entity와 개인계좌 Entity
• 

이와 같이 Subset에 의한 Entity 분할을 수행한다면 하나의 계좌번호 값에 대해 조회를 수행하는 SQL이 달라질 수 있다. 보통의 경우에는 Entity 분할을 하게 되면 해당 Entity를 액세스하는 SQL은 복잡해질 수 있게 된다.

물론 계좌번호 자체로 법인 계좌인지 아닌지를 확인할 수 있다면 굳이 UNION ALL을 이용할 필요 없이 애플리케이션에서 해당 Entity만 액세스하면 될 것이다. 이와 같다면 Entity 분할도 동일해진다.