후보 엔터티 도출과 검증

핵심 요약

엔터티 후보는 명사 목록을 기계적으로 옮겨 만드는 것이 아니다. 업무가 관리해야 하는 동일 유형의 인스턴스 집합인지, 각 인스턴스를 구별할 수 있는지, 독립된 속성과 생명주기·관계가 있는지를 검증한다. 후보를 넓게 수집한 뒤 근거를 기록하며 통합·제외·보류한다.

학습 목표

• 다양한 업무 자료에서 후보 엔터티를 도출한다.
• 엔터티의 성립 조건으로 후보를 검증한다.
• 엔터티와 속성·코드값·역할·프로세스·산출물을 구분한다.
• DAP 실기형 엔터티 정의를 명확하게 작성한다.

1. 후보 엔터티의 발견

1.1 후보 원천

• 업무 기능·프로세스와 사건: 계약 체결, 주문, 입금, 배송, 해지
• 업무 문서·화면·보고서의 핵심 명사
• 요구사항과 업무 규칙의 주어·목적어
• 현행 테이블·파일·인터페이스와 CRUD 사용 현황
• 표준 용어·코드와 조직의 기준정보
• 법규·정책상 보존해야 하는 대상과 이력

한 자료에만 의존하면 편향이 생긴다. 화면은 표시 편의상 여러 엔터티를 합쳐 보여주고, 현행 테이블은 성능이나 과거 제약으로 비정규화되어 있을 수 있다. 업무 사건과 규칙을 함께 확인한다.

2. 엔터티 성립 조건

모든 조건을 체크리스트처럼 기계 적용하지 않는다. 초기 개념 모델에서는 속성이 아직 상세화되지 않았더라도 업무상 독립 대상과 생명주기가 명확하면 후보로 유지할 수 있다. 반대로 속성이 많아 보여도 단지 보고서의 열 집합이면 엔터티가 아닐 수 있다.

2.1 흔한 후보와 제거 기준

3. 도출과 검증 절차

1. 여러 자료에서 후보 명사를 넓게 수집한다.
2. 동의어를 묶고 동음이의어를 분리한다.
3. 각 후보의 정의, 발생 사건, 식별 기준과 주요 속성을 기록한다.
4. 엔터티 성립 조건으로 채택·통합·제외·보류를 판정한다.
5. 주제영역에 배치하고 다른 엔터티와 관계를 검증한다.
6. 핵심 업무 시나리오와 CRUD를 따라 누락·중복을 확인한다.
7. 현업과 정의·범위·명칭을 합의한다.

3.1 명명 원칙

• 업무에서 사용하는 명확한 단수형 명사를 사용한다.
• 화면·보고서·프로세스 이름보다 관리 대상의 본질을 나타낸다.
• 정보, 내역, 현황, 관리 같은 포괄어는 실제 의미를 숨기지 않는지 검토한다.
• 동일한 이름이 서로 다른 범위를 뜻하면 수식어와 정의로 구분한다.
• 구현 테이블 약어보다 업무 용어를 우선한다.

4. 엔터티 유형과 사례

4.1 유형 분류

교재와 방법론마다 명칭은 다를 수 있으나 개념 모델 검토에 흔히 다음 관점을 사용한다.

• 기본·키 엔터티: 다른 사건에 선행하며 독립적으로 존재하는 기준 대상. 예: 고객, 상품.
• 중심·메인 엔터티: 핵심 업무 행위의 중심이 되는 대상. 예: 계약, 주문.
• 행위·사건 엔터티: 업무 사건이 발생할 때 생성되는 기록. 예: 결제, 배송, 상담.

유형 명칭을 암기하기보다 발생 시점, 독립성, 다른 엔터티와의 관계를 판정한다.

4.2 사례: 주문승인

“주문을 승인한다”는 문장에서 주문승인을 후보로 얻었다.

• 승인 여부와 최종 승인자만 주문 속성으로 관리하고 과거 이력이 필요 없다면 별도 엔터티가 아닐 수 있다.
• 여러 차례 승인 요청·반려·재승인을 식별하여 시각, 승인자, 결과, 사유를 보존한다면 주문승인이력 사건 엔터티가 타당하다.

같은 명사라도 업무가 무엇을 독립적으로 관리하는지에 따라 판정이 달라진다.

4.3 DAP 실기형 엔터티 정의

요구사항: “회원이 강좌별로 수강을 신청하며 신청일시, 상태, 취소일시를 관리한다.”

• 엔터티명: 수강신청
• 정의: 회원이 특정 강좌의 수강을 요청하여 생성되며 신청부터 취소·완료까지 상태를 관리하는 업무 사건
• 발생 기준: 회원이 강좌에 대해 수강 신청을 확정할 때 1건 생성
• 식별 후보: 수강신청번호 또는 회원번호+강좌번호+신청차수
• 주요 관계: 회원, 강좌

정의는 엔터티명을 반복하지 않고 무엇이 한 인스턴스이며 언제 발생하는지 나타낸다.

5. 비교와 구분

시험 판단 포인트

• 명사라는 이유만으로 엔터티가 되지 않는다.
• 집합성·식별 가능성·속성·생명주기와 업무 중요성을 함께 본다.
• 역할·분류가 별도 속성과 생명주기를 가지는지 확인한 뒤 엔터티 또는 서브타입 후보를 판정한다.
• 현행 테이블 1개가 논리 엔터티 1개와 반드시 대응하지 않는다.
• 엔터티 정의에는 인스턴스 의미와 발생 기준이 드러나야 한다.

자주 틀리는 부분

• 보고서 제목과 화면 탭을 그대로 엔터티로 만든다.
• 코드값 하나마다 별도 엔터티를 만든다.
• 후보를 제거하면서 제외 근거를 남기지 않아 나중에 다시 중복 검토한다.
• 고객정보, 주문내역처럼 포괄적인 이름만 사용하고 범위를 정의하지 않는다.