Entity 개념

지난 시간에 이어 Entity를 구성하는 개념을 확인해 보자. Entity를 구성하는 항목은 다음과 같다.

• [그림1] Entity의 개념
• 

Unique ldentifier에 의해 식별 가능

Unique Identifier는 Physical Modeling 과정에서 Primary Key로 구현된다. Primary Key란 Entity에서 유일하게 존재하 는 값을 말한다.

예를 들어, 카드 마스터 테이블에서는 카드번 호 값은 유일한 값이다. 하지만 카드 마스터 테이블에 카드 이 력 Data를 저장하게 되었을 경우 카드번호는 유일한 값이 될 수 없으므로 Unique Identifier가 될 수 없다.

하나의 카드번호 Data에 여러 건의 이력 Data가 저장되므로 이와 같은 경우에 카드번호 값을 Unique Identifier로 정의한다면 카드 마스터 테이블은 Entity의 자격을 잃게 된다.

카드번호 Data에 대해 이력 정보를 별도로 분리해 다른 Entity로 생성하거나 카드 마 스터 테이블에 변경일자 Data를 저장해 카드번호 값과 변경일자 값의 합으로 Unique Identifier를 구성한다면 해당 값들에 의해 유일한 값이 되므로 Entity의 조건을 만족하게 된다.

업무에서 반드시 사용

프로젝트를 수행하다 보면 수천 개의 Entity가 존재하는 경 우도 많다. 경우에 따라서는 Relationship도 없고 사용하지 않 는 Entity가 존재하는 경우도 발생하게 된다.

이와 같다면 해당 Entity는 잘못 선정되었을 가능성이 커지게 된다. Entity는 업 무에 필요해야 하며 그렇기 때문에 업무에서 반드시 사용돼야 한다. 이는 상관 모델링을 통해 확인할 수 있게 된다.

1개 이상의 Attribute 존재

Entity에 Attribute가 존재하지 않는다면 의미가 없게 된다. Entity를 구성하는 Attribute가 존재할 경우에만 Entity로 의미가 있게 된다.

1개 이상의 Relationship 존재

Entity 간에는 Relationship 이 존재해야 한다. 중요 Entity가 관계가 없게 되면 애플리케이션 구현이 불가능하거나 정확한 데이터 추출이 어렵게 된다.

하지만 일반적으로 Code Entity, 통계(요약) Entity는 Relationship을 표현하지 않는다. 이는 Code Entity의 경우 대디수의 Entity와 Relationship을 가지게 되므로 모든 Relationship을 표현하는 순간 ERD가 너무 복잡해질 수 있기 때문이다.

지난 시간과 이번 시간에 확인한 내용을 종합해보면 Entity로서 자격을 가지기 위해서는 다음과 같은 요소를 가져야 한다.

• - 업무에 필요한 정보
• - 영속적으로 존재
• - 객관적인 집합
• - Unique Identifer(UID) 에 의해 식별 가능
• - 업무에서 반드시 사용
• - 1 개 이상의 Attribute 존재
• - 1 개 이상의 Relationship 존재

Entity는 위와 같은 요소를 만족해야 Entity로서 자격을 가지게 된다.

Entity 정보 수집

데이터 모델링은 업무 프로세스를 고려하되 업무에 절대적으로 의존적 이어서는 안 된다. 업무는 언제든 변경될 수 있으므로 업무에 의존적이면 애플리케이션 변경이 어려워진다.

데이터 모델링의 중심이 되는 Entity는 결국 업무에서 추출해야 한다. 그렇기 때문에 기존 문서, 업무 프로세스, DFD, 업무 설명 , Interview 및 경험/성능 등을 고려해 도출하게 된다.

• [그림2] Entity의 정보수집
• 

Entity 도출

Entity 도출은 [그림 3]과 같은 순서에 의해 진행하게 된다. 업무에 필요한 데이터는 당연히 요구사항 명세서 등을 이용하 게 되므로 업무에 필요한 데이터가 될 것이다.

또한 업무에서 반드시 사용하는 것은 상관 모델링에서 확인하게 된다. Relationship의 관계는 Entity 도출 시에 확인하지 않으면 Relationship을 표현하는 시점에 확인하게 된다.

• [그림3] Entity의 도출순서
•