데이터 모델링을 수행하는 과정에서 실제로 작업은 ERD로 표현된다. ERD를 통해 Entity를 배치하고 Entity 사이에 Relationship을 설정하는 것이다.

이와 같은 순서를 통해 ERD를 작성하고 프로젝트 중에 계속 협의 수단으로 사용하게 된다.

• [그림1]
• 

ERD 표기 방식

ERD를 표기하는 방법으로 Subject Area를 이용하는 방법이 있다. Subject Area를 이용하는 방법은 전체 업무를 몇 개의 범주로 구분해 각각 ERD를 작성하는 것이다.

Entity가 많은 시스템의 경우 하나로 ERD를 작성한다면 매우 복잡해질 수 있다. 이와 같은 경우 업무별 또는 시간별로 구분하고 Subject Area를 분리해 ERD를 작성할 수 있다.

실제 프로젝트에 Entity의 개수가 많은 경우에는 Subject Area를 다수 활용하게 된다. [그림 2]의 예에서 카드 업무에 대해 데이터 모델링을 수행하는 과정에서 해당 데이터 모델링의 Entity가 많을 경우 카드 승인 업무와 카드 정산 업무를 분리해 Subject Area를 이용함으로써 각각 데이터 모델링을 수행할 수 있다.

Subject Area를 구분하는 경우 서로 다른 Subject Area 사이에 많은 Relationship이 존재한다면 매우 불리할 수 있다.

• - 업무별 또는 시간별로 Subject Area를 분리하기 때문에 각각의 Subject Area는 적은 Entity를 가지게 된다. 따라서 ERD의 읽기 편의성이 높아진다.
• - 업무를 분리해 데이터 모델링을 수행하게 되므로 하나의 Subject Area에서 관리해야 하는 Entity의 개수 감소로 명시적인 데이터 모델링이 가능해진다.
• - 서로 Relationship이 적은 경우를 Subject Area로 구성해야 한다.
• - 업무에서 가장 많이 사용하는 명사 또는 업무에서 가장 중심에 있는 Entity의 이름으로 Subject Area의 이름을 선정한다.

• [그림2]
• 

Entity의 개념

Entity가 되기 위해서는 어떤 조건을 만족해야 할까?

[그림 3]의 일곱 가지 조건을 만족해야만 Entity 자격이 되며, 데이터 모델링에서 Entity로 구현될 수 있다. Entity로 선정된 후 Entity는 Physical Modeling에서 테이블로 변경된다.

• [그림3]
• 

- 업무에 필요한 정보 : 통신회사일 경우는 통신에 대한 통화내역 데이터는 필요하지만 HR 시스템에서는 통화내역 데이터가 필요 없다. 결국 시스템에서 반드시 필요한 데이터를 저장하는 경우에만 Entity로 정의할 수 있다.

- 영속적으로 존재 : 영구히 존속하는 데이터를 가진 경우에만 Entity가 될 수 있다. 임시 Entity는 ERD에 구현하지 않는다. 또한 성능을 고려해 가상으로 만든 Entity는 ERD에서는 구현하지 않는다. 결국 데이터 정합성과 관련이 없는 Entity는 ERD에 구현하지 않는다.

- 객관적인 집합 : 누가 봐도 정확히 구분되는 집합이어야 한다. 예를 들어 부서 테이블에 국내 부서만 포함되는지 해외 부서도 포함되는지 또는 부서이력을 포함하는지 등 객관적인 집합에 대한 정의가 필요하다.

Entity 개념은 이와 같이 이해할 수 있다. Entity 개념에 대한 추가적인 사항은 다음 시간에 살펴본다.