데이터모델링 (Key Entity, Main Entity, Action Entity)

# 엔터티를 찾기 위한 사고의 전개

- 엔터티의 개수들은 점점 많아지지만 우리가 해야 할 것이 그렇게 많아지는 것은 아니다. 키가 되는 엔터티들을 찾고 키가 되지 않는 엔터티들은 키가 되는 엔터티들을 기준으로 파생시켜 나가면 되는 것이다.
- 이러한 개념을 기준으로 엔터티의 종류를 세 가지로 나눌 수 있다.
키 엔터티(Key Entity), 메인 엔터티(Main Entity), 액션 엔터티(Action Entity)가 바로 그것이다.
물론 이 외에도 M:M관계를 해소시켜주는 릴레이션 엔터티(Relation Entity)도 있으며 어떤 사람들은 메이저 엔터티(Major Entity)의 존재를 이야기하기도 하지만, 여기서 엔터티의 종류를 나누는 것은 우리가 어떻게 키 엔터티에서 나머지 엔터티들을 파생시켜 나갈 것인가 하는 것을 알기 위해서 이다.

* 키 엔터티, Key Entity
부모를 가지지 않는 독립적인 엔터티라 할 수 있다.
키 엔터티는 전체 개체-관계도에서 가장 주어가 되는 엔터티들이다. 예를 들어 고객은 키 엔터티이다. 고객이라는 데이터를 발생시키기 위한 엔터티들이 있는가? 사원 또한 키 엔터티이다.
사원과 일대다 관계를 맺는 부서라는 엔터티가 있을 수 있지만 이것은 릴레이션쉽의 문제로 실제 사원 데이터가 발생하는 것과는 아무런 연관이 없다. 그리고 부서가 없는 사원도 있을수 있으니 말이다(일반적으로 신입사원으로 연수를 받는 도중에는 부서가 없다).
되도록이면 엔터티 후보들을 찾을 때, 가장 우선해서 키 엔터티들을 찾아내야 한다. 그래야만 다른 엔터티들을 파생시킬 수 있다(물론 찾아내지 못한 키 엔터티들은 나중에 다른 엔터티들에서 도출될 수도 있다).
예) 사원, 고객, 강좌, 학생, 교수, 상품, 계정

* 메인 엔터티, Main Entity부모를 가지지만 스스로 업무의 핵심이 되어서 많은 자손 엔터티들을 가지는 것이 바로 메인 엔터티이다. 업무에는 이러한 데이터들이 많이 존재한다.
주문과 같은 엔터티의 경우, 상품이나 고객과 같은 주문이라는 데이터를 낳게 한 부모들을 가지고 있다.
주문 엔터티는 다른 엔터티들에서 파생된 엔터티이기는 하지만 업무의 중심으로, 또한 다른 엔터티들을 많이 파생시키기도 한다.
예) 주문, 가입계약, 납입계약, 보험계약, 예금원장

* 액션 엔터티, Action Entity
키 엔터티나 메인 엔터티가 아니라면 나머지는 액션 엔터티 밖에는 없을 것이다. 앤ㄱ션 엔터티는 메인 엔터터에서 파생되어 나온 엔터티들이다.
예를 들어 주무이라는 엔터티에서 파생되어 나온 주문 상세 엔터티 또는, 키 엔터티인 고객의 접속 기록을 관리하는 접속 기록 엔터티와 같은 경우도 앤ㄱ션 엔터티들이다. 액션 엔터티들도 나중에 업무가 변화하고 확장되면 메인 엔터티로 지위가 향상될 수 있다.
예) 주문 상세, 접속 기록

- 엔터티들을 키 엔터티, 메인 엔터티, 액션 엔터티로 나누는 것에 크게 주의를 기울일 필요는 없다. 중요한 것은 가장 먼저 찾아야 하는 것이 키 엔터티라는 것이다.

참고자료 : 소설처럼 읽는 DB 모델링 이야기(영진닷컴)