엔터티: 무엇을 관리할 것인가

핵심 요약

업무에서 지속적으로 관리할 대상인 엔터티의 성립 조건과 분류·명명 원칙을 익힌다.

핵심 질문

1. 엔터티: 무엇을 관리할 것인가를 실제 업무 사례에서 어떤 기준으로 판별하는가?
2. 한 행이 나타내는 업무 사실과 유일성·필수성·변경 가능성은 무엇인가?
3. 잘못 모델링하면 어떤 중복·이상 현상·변경 영향이 발생하는가?
4. 여러 설계안 중 업무 의미와 변경 용이성을 가장 잘 보존하는 안을 어떻게 고르는가?

학습 목표

• 엔터티가 성립하기 위한 조건을 판별한다.
• 유형·개념·사건 엔터티와 기본·중심·행위 엔터티를 구분한다.

개념 지도

업무 사실 → 엔터티와 행 단위 → 속성·도메인 → 관계·카디널리티 → 제약

핵심 내용

엔터티는 업무상 관리할 필요가 있고 서로 구별되는 인스턴스의 집합이다. 보통 다음 조건을 확인한다.

1. 업무에서 반드시 필요한 정보인가?
2. 유일하게 식별할 수 있는가?
3. 둘 이상의 인스턴스가 존재할 수 있는가?
4. 업무 프로세스에서 이용되는가?
5. 속성과 다른 엔터티와의 관계를 가지는가?

발생 형태로 보면 사원 같은 유형, 조직·보험상품 같은 개념, 주문·계약 같은 사건 엔터티로 나눌 수 있다. 업무 영향에 따라 독립적으로 생기는 기본 엔터티, 핵심 업무의 중심 엔터티, 처리 결과로 생기는 행위 엔터티로도 분류한다.

명칭은 현업 용어를 사용하고, 단수 명사로 짧고 명확하게 정한다. 같은 의미를 여러 이름으로 부르거나 한 이름을 여러 의미로 쓰지 않는다.

흔한 오해와 주의점

• 화면의 입력란이나 보고서 항목이 곧바로 엔터티가 되는 것은 아니다.
• 인스턴스 하나만을 가리키는 명칭과 인스턴스 집합인 엔터티를 혼동하지 않는다.
• 엔터티는 속성 없이 이름만 존재하지 않으며, 일반적으로 다른 엔터티와 업무 관계를 가진다.

문항 풀이 보강: 엔터티 판별과 분류

엔터티 후보를 찾았다고 바로 채택하지 않는다. 다음 질문을 모두 통과하는지 확인한다.

1. 업무에서 반드시 관리할 필요가 있는가?
2. 같은 종류의 인스턴스가 보통 두 개 이상 존재할 수 있는가?
3. 각 인스턴스를 식별할 수 있는가?
4. 업무 프로세스에서 실제 생성·조회·변경되는가?
5. 속성을 두 개 이상 가지며 다른 엔터티와 관계를 맺는가?

환자는 여러 환자 인스턴스와 이름·주소 속성이 있으므로 엔터티다. 홍길동은 환자 엔터티의 한 인스턴스이며, 화면의 “환자 이름 입력란”은 속성 표현이지 별도 엔터티가 아니다.

발생 시점에 따른 분류

• 기본/키 엔터티: 다른 엔터티에 의존하지 않고 먼저 존재한다. 사원, 부서, 고객, 상품이 대표적이다.
• 중심 엔터티: 기본 엔터티에서 발생해 핵심 업무의 중심이 된다. 계약, 사고, 주문 등이 대표적이다.
• 행위 엔터티: 둘 이상의 부모 사이의 업무 처리 결과로 생긴다. 주문목록, 사원변경이력 등이 대표적이다.

이름을 정하는 규칙

현업의 단수 명사를 사용하고, 약어나 구현 용어 대신 업무 의미가 드러나게 한다. 같은 대상을 화면마다 다른 이름으로 부르지 않으며, 한 이름을 서로 다른 뜻으로 재사용하지 않는다.

문제에 적용하는 순서

지문의 명사가 “사람 한 명”인지 “같은 종류의 정보 집합”인지 먼저 구분한다. 그다음 독립적으로 먼저 생기는지, 핵심 거래인지, 거래의 상세·이력인지 순서로 분류한다.

엔터티·속성·값을 구분하는 사례

온라인 쇼핑 업무에서 다음 후보를 본다.

“명사다”라는 이유만으로 엔터티가 되지 않는다. 독립적으로 관리할 인스턴스 집합, 식별자, 속성, 관계와 생명주기가 있어야 한다.

행 단위(Grain) 질문

엔터티를 정할 때 “한 행은 무엇을 의미하는가?”를 한 문장으로 쓴다.

주문 한 행 = 고객이 특정 시점에 생성한 하나의 주문 Header
주문상품 한 행 = 주문 안의 특정 상품 Line 한 건

두 사실을 한 테이블에 섞으면 주문 정보가 상품 수만큼 반복되고 갱신 이상이 생긴다. 기본·중심·행위 엔터티 분류보다 먼저 Grain과 식별자를 확정한다.

경계 사례 검증

• 속성이 여러 값을 가지거나 자체 이력을 가지면 별도 엔터티 후보다.
• 코드 값이 설명·유효기간·계층을 가지면 코드 엔터티로 관리할 수 있다.
• 현재 화면에서 한 번만 보인다는 이유로 엔터티를 제거하지 않는다.
• 다른 엔터티 없이 존재할 수 있는지와 삭제 시 생명주기를 함께 묻는다.

사례를 판별하는 순서

1. 모델이 표현해야 하는 업무 사실과 행 단위(Grain)를 한 문장으로 정의합니다.
2. 각 인스턴스를 유일하게 식별할 수 있는 후보와 변경 가능성을 확인합니다.
3. 속성이 어느 사실에 종속되는지와 관계의 필수성·카디널리티를 확인합니다.
4. 중복 저장으로 삽입·갱신·삭제 이상이 생기는지 검토합니다.
5. 물리 성능을 이유로 구조를 바꿀 때 원천 데이터와 동기화·복구 규칙을 함께 설계합니다.

모델 품질 확인표

• 같은 업무 사실이 여러 곳에 중복 저장되지 않는가?
• 이름과 도메인이 한 가지 의미로 사용되는가?
• PK·FK가 실제 업무 관계와 선택성을 정확히 표현하는가?
• 현재 화면이나 프로세스에 과도하게 종속되지 않는가?
• 정규화와 성능 설계의 이유를 측정 가능한 근거로 설명할 수 있는가?

마지막 점검

• 화면의 입력 항목이나 현재 프로세스를 그대로 엔터티·관계로 옮기지 않습니다.
• 한 행의 업무 사실, 후보 식별자와 함수 종속성을 먼저 확정합니다.
• 중복과 비일관성을 만들면서 조회 편의만 얻는 설계를 정답으로 선택하지 않습니다.
• 반정규화와 물리 설계는 측정된 성능 문제와 동기화·복구 대책이 있을 때 적용합니다.

복습 문제

1. 주문과 주문상세는 각각 어떤 업무 역할의 엔터티인가?
2. 사원 홍길동은 엔터티인가, 인스턴스인가?
3. 이 개념을 실제 업무 사례에서 판별할 수 있는가?
4. 한 행의 업무 의미와 식별자를 설명할 수 있는가?