엔터티 (Entity)

엔터티 (Entity)

---

  정의 

  업무에 필요하고 유용한 정보를 저장하고 관리하기 위한 집합적인 것 이다. 업무 활동상 지속적인 관심을 가지고 있어야 할 대상들 간에 동질성을 지닌 인스턴스들이나 그들이 행하는 행위의 집합으로 정의할 수 있다.

---

  설명 

  엔터티는 그 집합에 속하는 개체들의 특성을 설명할 수 있는 속성(Attribute)를 갖는다. 어떠한 엔터티에 대해서 그에 해당되는 인스턴스들을 표현한 것을 속성이라고 한다.

 

  엔터티는 Generic 한 특성을 가지고 Instance는 Specific한 특성을 가진다. 마치 OOP에서 class / object 의 관계를 나타내는 것 과 비슷하다.

 

  엔터티의 특징 

1. 반드시 해당 업무에서 필요하고 관리하고자 하는 정보여야 한다.
2. 유일한 식별자에 의해 식별이 가능해야 한다.
3. 영속적으로 존재하는 두 개 이상의 인스턴스 집합이어야 한다.
4. 업무 프로세스에 의해 이용되어야 한다.
5. 반드시 속성이 있어야 한다.
6. 다른 엔터티와 최소 한 개 이상의 관계(Relation)이 있어야 한다.

1. 반드시 해당 업무에서 필요하고 관리하고자 하는 정보여야 한다.

  A 라는 회사가 있다고 하자. 그리고 이 회사의 부속 병원인 B 병원이 있다. A 회사 회사원들은 아플때 B 병원을 많이 찾는다. 이 때 병원에서는 '환자'라는 엔터티를 활용 할 것 이다. 의료업계에 해당되는 병원의 입장에선 '환자' 엔터티는 반드시 필요 할 것 이다. 하지만 회사에선 '환자' 엔터티는 사실상 업무적으로 그렇게 많이 필요하지는 않을 것 이다. 어느 부분을 생각하면 필요할 수도 있겠지만, 반드시 모든 회사에 있어서 필요한 엔터티는 아니다. 이와 같이 엔터티를 도출할 때는 업무 영역 내에서 관리를 할 필요가 있는지를 먼저 판단해야한다.

 

2. 유일한 식별자에 의해 식별이 가능해야 한다.

  유일한 식별자는 그 엔터티에 해당되는 인스턴스만의 고유한 이름이다. 어떠한 엔터티에서 원하는 인스턴스에 대한 정보를 식별해야할 때 사용될 수 있다. 따라서, 유일한 식별자는 두 개 이상의 인스턴스를 대변한다면 그 식별자는 잘못된 것 이다. 예를 들어, 회사에서 사원들의 정보에 대한 엔터티가 존재한다고 하자. 이 엔터티에 해당되는 사원들을 구분할 수 있는 방법은 무엇이 있을까 생각해보면 된다. 이름? 이름은 동명이인이 존재할 수 있기 때문에 유일한 식별자가 될 수 없다. 소속 부서, 입사 날짜등 전부 겹칠 수 있는 가능성이 있어서 유일한 식별자가 될 수 없다. 따라서 사원번호가 존재한다. 사원번호는 입사한 사원들에 대해서 모두 그 사원에 유일하게 부여된 번호이므로 유일한 식별자가 될 수 있다.

 

3. 영속적으로 존재하는 두 개 이상의 인스턴스 집합이어야 한다.

   한 개의 인스턴스를 가지는 엔터티는 다른 엔터티간의 관계, 프로세스와의 관계 등 업무를 분석 및 설계하는 것에 대해서 의미가 없게 된다. 따라서 한 개의 인스턴스만을 가지는 엔터티는 결국 집합이라고 표현되지 않으며 이에 따라 엔터티에 성립이 되지 않는다.

 

4. 업무 프로세스에 의해 이용되어야 한다.

  업무에 있어서 반드시 필요하다고 여겨져서 엔터티로 선정을 하였지만 업무프로세스 상에서 전혀 이용이 되지 않는다면, 이는 업무 분석에 있어서 문제가 발생 할 것 이고, 이는 엔터티가 잘못 선정이 되었거나 업무 프로세스의 도출이 제대로 이루어지지 않았다는 것을 의미한다.

  데이터 모델링 과정에선 발견이 되지 못했지만 프로세스 모델링 과정에서 데이터 모델과의 검증, 상관 모델링을 할 때 엔터티와 단위프로세스의 교차를 점검하면서 문제점이 도출된다고 한다.

 

5. 반드시 속성이 있어야 한다.

  속성이 포함되지 않은 엔터티는 관계(Relation)가 생략되어 있거나, 업무 분석이 부족하여 속성정보가 누락되는 경우에 해당이 된다. 또한, 주식별자만 존재하고 일반속성은 전혀 없는 경우도 적절한 엔터티라고 할 수 없다. (예외적으로 관계엔터티(Associative Entity)의 경우는 주식별자 속성만 가지고 있어도 엔터티로 인정이 된다.)

 

6. 다른 엔터티와 최소 한 개 이상의 관계(Relation)이 있어야 한다.

  엔터티가 도출이 되었다는 것은 해당 업무 내에서 업무와 연관성이 있고, 이러한 연관성(존재적 연관성, 행위적 연관성)을 통해 다른 엔터티와 연관의 의미를 갖고있다는 것을 의미한다. 하지만 관계가 설정되지 않은 엔터티의 도출은 부적절한 엔터티가 도출이 된 경우이거나 다른 엔터티와 적절한 관계를 찾지 못한 경우에 해당이 된다.

  (통계성 엔터티 도출, 코드성 엔터티 도추르 시스템 처리시 내부 필요에 의한 엔터티 도출은 관계를 생략하여 표현해야 한다.)

 

  엔터티의 분류 

1. 유/무 형에 따른 분류
2. 발생시점에 따른 분류

1. 유/무형에 따른 분류

  * 유형 엔터티 (Tangible Entity)

      : 물리적인 형태가 있으며, 안정적이고 지속적으로 활용이 되는 엔터티이다. 업무로부터 엔터티를 구분하기 가장 용이하다.

      ex) 해당인원, 물품

 

 * 개념 엔터티 (Conceptual Entity)

      : 물리적인 형태는 존재하지 않으며, 관리해야 할 개념적인 정보로 구분이 되는 엔터티이다.

      ex) 조직, 보험상품

 

 * 사건 엔터티 (Event Entity)

      : 업무를 수행함에 따라 발생이 되는 엔터티 이다. 비교적으로 발생량이 많다.

      ex) 주문내역, 청구내역

 

2. 발생시점에 따른 분류

  * 기본 엔터티 (Fundamental Entity / Key Entity)

      : 업무에 원래 존재하는 정보이다. 다른 엔터티와의 관계에 의해서 생성이 되는 엔터티가 아니라, 독립적으로 생성이 가능하며 다른 엔터티들의 부모 엔터티 역할을 하게 된다. 다른 엔터티로부터 주식별자를 상속받지 않고 자신의 고유한 주식별자를 가지게 된다.

      ex) 사원, 부서, 고객, 상품 등

 

 * 중심 엔터티 (Main Entity)

      : 기본 엔터티로부터 발생되고, 그 업무에 있어서 중심적인 역할을 한다. 데이터의 양이 많이 발생되며 다른 엔터티와의 관계를 통해 행위 엔터티를 생성한다.

      ex) 계약, 사고, 주문, 매출 등

 

 * 행위 엔터티 (Active Entity)

      : 두 개 이상의 부모 엔터티로부터 발생. 자주 내용이 바뀌거나 데이터 양이 증가가 된다.

        분석 초기 단계보단 상세 설계단계 / 프로세스와 상관 모델링 중 도출될 수 있다.

      ex) 주문목록, 사원변경이력

 

  엔터티의 명명 

1. 현업업무 사용 용어 사용
2. 약어 사용 X
3. 단수명사 사용
4. 모든 엔터티에서 유일한 이름이 부여가 되야 함
5. 엔터티 생성 의미대로 이름을 부여 (잦은 문제가 발생하는 부분)

---

오늘의 한 마디 : 아직 3주 뒤에 있는 SQLD 시험에 대해서 큰 방향은 잡히지가 않았다. 그날 그날의 목표를 명확하게 세우고 달성 해야겠다.