엔터티(entity)는 업무에서 관리할 대상의 집합이고, 그 안의 하나하나를 인스턴스(instance)라 합니다. 엔터티는 여섯 가지 조건을 갖추어야 하며, 형태와 발생 시점에 따라 나눕니다.
모델링은 무엇을 관리할지 정하는 데서 시작합니다. 관리할 대상을 엔터티로 뽑아야 그 엔터티의 속성과 엔터티끼리의 관계를 정할 수 있습니다. 엔터티를 잘못 뽑으면 쓸모없는 테이블이 생기거나 꼭 필요한 정보가 빠집니다. 아래 그림은 사원·부서로 엔터티와 조건을 보고, 영업 업무의 고객·상품·주문·주문상품(주문 한 건에 담긴 상품 한 줄)을 더해 분류를 봅니다.
1엔터티와 인스턴스의 관계
사원 엔터티는 사원 6명의 집합이고, 김민준 한 사람이 인스턴스 하나입니다. 물리 모델에서 엔터티는 테이블이 되고, 인스턴스는 행이 됩니다.
엔터티 이름은 현업 용어로, 약어 없이, 단수 명사로, 모델 안에서 하나뿐이게, 생긴 뜻대로 짓습니다. 그래서 엔터티 이름은 '사원'이고, EMP는 물리 모델에서 따로 정한 테이블 이름입니다.
2엔터티의 6가지 성립 조건
후보는 여섯 조건을 모두 갖춰야 엔터티가 됩니다. 사원으로 하나씩 확인해 봅니다.
| 조건 | 뜻 | 사원은 |
|---|---|---|
| ① 업무에 필요 | 그 업무가 관리할 정보다 | 인사 업무가 관리한다 |
| ② 식별자로 구분 | 하나씩 가려낼 수 있다 | 사번이 모두 다르다 |
| ③ 영속적 인스턴스 둘 이상 | 사라지지 않고 계속 관리되는 것이 둘 이상이다 | 6명이다 |
| ④ 업무 프로세스 | 업무를 처리할 때 쓴다 | 급여 계산에 쓰인다 |
| ⑤ 속성 | 설명하는 항목이 있다 | EMPNO · ENAME 등 |
| ⑥ 관계 | 다른 엔터티와 하나 이상 이어진다 | 부서에 소속된다 |
'회사' 후보는 인스턴스가 '우리 회사' 하나뿐이라 조건 ③에서 빠집니다. 조건 ⑥에는 예외가 있어, 통계용·코드용 엔터티와 시스템 내부용 엔터티(접속 기록 같은 로그)는 관계를 생략하기도 합니다.
3형태와 발생 시점에 따른 분류
엔터티는 두 기준으로 따로 나누므로, 한 엔터티가 두 분류에 모두 이름을 가집니다. 주문은 형태로는 사건 엔터티, 발생 시점으로는 중심 엔터티입니다.
형태(유무형)로는 유형(Tangible Entity)·개념(Conceptual Entity)·사건(Event Entity) 엔터티로 나눕니다.
| 갈래 | 가르는 질문 | 예 |
|---|---|---|
| 유형 | 물리적 형태가 있나 | 사원 · 상품 · 강사 |
| 개념 | 형태 없이 개념으로 관리하나 | 부서 · 보험상품 |
| 사건 | 업무를 하면서 생기나 | 주문 · 청구 |
발생 시점으로는 기본(Fundamental Entity)·중심(Main Entity)·행위(Active Entity) 엔터티로 나눕니다. 부모 엔터티는 다른 엔터티가 거기서 생겨나는 쪽입니다(주문상품의 부모는 주문과 상품).
| 갈래 | 가르는 질문 | 예 |
|---|---|---|
| 기본 | 다른 엔터티 없이 스스로 생기나 | 사원 · 부서 · 자재 |
| 중심 | 기본 엔터티에서 생긴 업무의 중심인가 | 주문 · 계약 |
| 행위 | 부모 엔터티 둘 이상에서 생기고 자주 바뀌거나 늘어나나 | 주문상품 · 사원변경이력 |
기본 엔터티는 다른 엔터티의 주식별자(인스턴스를 가려내는 대표 속성)를 물려받아 자기 주식별자로 삼지 않습니다. 사원이 부서번호를 속성으로 갖는 것은 괜찮습니다(→ 식별자 레슨).
행위 엔터티는 이렇게 가립니다.
- 고르는 기준: '두 개 이상의 부모 엔터티에서 생긴다', '자주 바뀌거나 양이 늘어난다'가 행위 엔터티의 설명입니다. 분석 초기보다 상세 설계 단계에서 많이 도출됩니다.
- 주의: 부모 수만으로 가르지는 않습니다. 업무의 중심이 되는 일(주문·계약·청구)은 부모가 둘인 모델에서도 중심이고, 그 일에 딸린 목록이나 바뀔 때마다 쌓는 이력(주문상품·사원변경이력)이 행위입니다.
예제
영업 업무를 설명한 글에서 엔터티를 뽑습니다.
고객은 상품을 주문합니다. 주문 한 건에는 상품이 여러 개 담기고, 상품마다 수량을 적습니다. 이 업무는 영업부가 맡습니다. 회사 이름과 대표 전화번호는 화면 맨 아래에 보입니다.
이름이 나오는 것과, '한 건에 여러 개'처럼 짝마다 따로 적어야 하는 것을 후보로 놓고 조건과 분류를 맞춥니다.
| 후보 | 엔터티 | 형태 | 발생 시점 |
|---|---|---|---|
| 고객 | 예 | 유형 | 기본 |
| 상품 | 예 | 유형 | 기본 |
| 주문 | 예 | 사건 | 중심 |
| 주문상품 | 예 | 사건 | 행위 |
| 영업부 | 아니요 | — | — |
| 회사 | 아니요 | — | — |
| 수량 | 아니요 | — | — |
주문상품은 주문과 상품, 두 부모에서 생깁니다. 영업부는 부서 엔터티에 든 인스턴스 하나이고, 회사는 인스턴스가 하나뿐입니다. 수량은 주문상품을 설명하는 속성입니다.
시험 포인트
- 한 엔터티는 형태와 발생 시점에 따라 이름이 둘입니다(주문 = 사건 · 중심). 두 기준을 섞은 보기를 조심합니다.
- 자료에 따라 엔터티를 엔티티, 인스턴스를 어커런스(occurrence), 기본 엔터티를 키 엔터티(Key Entity)라고도 부릅니다. 어느 이름으로 나와도 같은 것입니다.
- 인스턴스는 두 개 이상이어야 합니다. '한 개 이상'으로 바꾼 보기를 조심합니다.
- 통계용·코드용·시스템 내부용(로그) 엔터티는 관계가 없어도 됩니다. 시험에서 '관계가 없으니 엔터티가 아니다'를 고르게 하는 함정으로 나옵니다.
- '두 개 이상의 부모에서 생긴다'는 중심이 아니라 행위 엔터티의 설명입니다.
확인 문제
1. 예제의 회사가 계열사 다섯 곳을 함께 관리하게 되어, 주문마다 어느 계열사의 주문인지 적어야 합니다. 이제 '회사'는 엔터티가 될 수 있을까요? 까닭을 조건과 함께 말해 보세요.
정답
될 수 있습니다. 회사가 다섯 곳이 되어 앞에서 걸렸던 조건 ③을 채웁니다. 주문을 적을 때 회사를 쓰고(조건 ④), 주문과 관계도 맺습니다(조건 ⑥).
2. 다음 업무 글에서 엔터티를 고르고, 형태와 발생 시점으로 나눠 보세요.
투숙객은 객실을 예약합니다. 예약 한 건에 객실을 여러 개 잡을 수 있고, 객실마다 묵을 인원을 적습니다. 예약은 프런트 데스크가 받습니다.
정답
| 후보 | 엔터티 | 형태 | 발생 시점 |
|---|---|---|---|
| 투숙객 | 예 | 유형 | 기본 |
| 객실 | 예 | 유형 | 기본 |
| 예약 | 예 | 사건 | 중심 |
| 예약객실 | 예 | 사건 | 행위 |
| 프런트 데스크 | 아니요 | — | — |
| 인원 | 아니요 | — | — |
예약객실은 예약 한 건에 잡은 객실 한 줄이라, 예약과 객실 두 부모에서 생깁니다. 프런트 데스크는 부서의 인스턴스이고, 인원은 예약객실의 속성입니다.
3. 쇼핑몰 모델의 '지역코드' 엔터티(서울 02 · 부산 051 같은 지역번호 목록)에 관계선이 하나도 없습니다. 이 엔터티를 모델에서 빼야 할까요?
정답
빼지 않아도 됩니다. 지역코드는 코드용 엔터티라서 관계를 그리지 않아도 되는 예외에 듭니다.