SQLD - 과목1. (2) 엔터티

1. 엔터티의 개념

▷ Entity ( 엔터티 ) 

    : 업무에 필요하고 유용한 정보를 저장, 관리를 위한 집합적인 어떤 것 ( Thing )

      사람, 장소, 물건, 사건, 개념 등의 명사이다.

      업무상 관리가 필요한 관심사에 해당한다.

      동질성을 지닌 인스턴스들의 행위의 집합이다.

 

" 엔터티 " , 우리말로 "실체, 객체" 이다.

실무에서 '객체' 보다는 '엔터티' 라고 사용한다.

 

 

엔터티는 그 집합에 속하는 개체들의 특성을 설명할 수 있는 속성 (Attribute) 를 갖는다.

속성은 <공통 속성> 과 <개별 속성> 이 있다.

     ㄴ<공통 속성> : 엔터티 인스턴스 전체가 공유 가능

     ㄴ<개별 속성> : 엔터티 인스턴스 일부만 해당

 

 

엔터티	인스턴스의 집합	과목
인스턴스	엔터티의 하나의 값	국어, 수학, 영어 ...

눈에 보이는 (Tangible) 한 것과, 눈에 보이지 않는 것 모두 엔터티가 될 수 있다. 

 

 

엔터티 종류

 

 

 

 

 

 

---

2. 엔터티와 인스턴스에 대한 내용과 표기법

엔터티와 인스턴스

엔터티는 대부분 ' 사각형 ' 으로 표현된다. 속성의 표현 방법만 조금씩 다르다.

 

엔터티에 대한 표기법

 

 

※ 오브젝트 모델링   

클래스 (Class)	여러 개의 오브젝트를 포함하는 집합
오브젝트 (Object)	클래스를 이루는 각 오브젝트 값

 

 

 

 

 

---

3. 엔터티의 특징

▷ 엔터티의 특징

     1) 반드시 해당 업무에서 필요, 관리하려는 정보

     2) 유일한 식별자에 의해 식별 가능

     3) 영속적으로 존재하는 인스턴스의 집합 ( 2개 이상 )

     4) 업무 프로세스에 의해 이용되야 함

     5) 반드시 속성이 있어야 함

     6) 다른 엔터티와 최소 한개의 관계가 있어야 함

 

 

 

 

① 업무에서 필요로 하는 정보

 

시스템을 구축하고자 하는 업무에서 필요, 관리하고자 하는 정보여야 한다. 

시스템 구축 대상인 해당 업무에서 그 엔터티를 필요로 하는가 판단하는 것이 중요하다.

∴ 엔터티를 도출할 때는 업무 영역 내에서 관리할 필요가 있는지 판단해야 한다.

 

ex. ' 환자 ' 엔터티는 병원시스템에서는 중요하지만, 일반 회사의 인사시스템에서는 필요하지 않다.

엔터티 특성 - 필요성

 

---

② 식별이 가능해야 함

 

식별자 (Unique Identifier) 에 의해 식별이 가능해야 한다.

인스턴스 구분을 위한 유일한 식별자는 엔터티의 인스턴스만의 '고유' 한 것이다. 

2개 이상의 엔터티를 대변하면 잘못 설계 된 식별자이다.

∴ 엔터티를 도출할 때 의미를 가지는 인스턴스가 식별자에 의해 한 개씩만 존재하는지 판단해야 한다.

 

ex. '직원' 엔터티를 구분하는 '이름' 과 '사원번호' 에서, '이름' 은 동명이인이 생길 수 있으므로 유일한 식별자가 아니다.

엔터티 특성 - 유일성

 

---

③ 인스턴스의 집합

 

영속적으로 존재하는 인스턴스 집합이 되야한다.

엔터티는 2개 이상인 <집합개념> 인 것이 중요한 특징이다. 

2개 이상의 개념은 엔터티간의 관계, 프로세스와의 관계 등 업무 분석, 설계를 위한 개념이다.

∴ 하나의 엔터티는 여러 개의 인스턴스를 포함한다.

 

ex. '병원' 엔터티에 하나의 인스턴스만 존재한다면, 집합이 아니므로 엔터티가 아니다.

엔터티 특성 - 인스턴스 수

 

---

④ 업무프로세스에 의해 이용

 

업무프로세스 (Bussiness Process) 가 그 엔터티를 반드시 이용해야 한다.

업무프로세스에 의해 이용되지 않는다면, 업무 분석이 정확하게 되지 않아 엔터티가 잘못 선정되었거나 업무프로세스 도출이 정확하지 않다는 것을 의미한다.

데이터 모델링, 상관 모델링을 할 때 문제점이 도출된다.

 

엔터티 특성 - 프로세스 존재

해결 방법 :  1) 고립된 엔터티를 제거한다.   2) 누락된 프로세스가 존재한지 확인 후 프로세스 추가

 

 

---

⑤ 속성을 포함

 

엔터티는 반드시 속성 (Attributes) 이 포함되야 한다.

속성 없이 엔터티의 이름만 있는 경우, 관계가 생략 또는 속성 정보가 누락되는 경우이다.

주별식자만 존재하고 일반 속성이 전혀 없는 경우도 적절하지 않은 경우이다.

( 예외 : 관계엔터티 (Associative Entity) 의 경우는 주별식자 속성만 존재해도 엔터티로 인정함 )

 

ex. '날씨' 엔터티에는 아무런 속성이 없기 때문에 엔터티가 될 수 없다.

엔터티 특성 - 속성의 문제

 

---

⑥ 관계의 존재

 

엔터티는 다른 엔터티와 최소 한 개 이상의 관계가 존재해야 한다.

도출된 엔터티는 업무적인 연관성을 가지고 다른 엔터티와의 연관의 의미를 가진다.

관계가 없는 엔터티는 부적절한 도출과 관계 누락을 의미한다.

 

엔터티 특성 - 관계의 존재

 

 

※ 데이터 모델링에서 관계 생략 표현이 가능한 경우

 

   1) 통계성 엔터티 도출

       : 업무 진행 엔터티로부터 통계업무 (Read Only) 만을 위해, 엔터티를 다시 정의해야 하므로 엔터티간의 관계 생략

 

   2) 코드성 엔터티 도출

       : 코드를 위한 엔터티 이므로 너무 많은 관계 설정으로 인해 읽기효율성 (Readability) 저하로 관계 생략

 

   3) 시스템 처리시 내부 필요에 의한 엔터티 도출

       : ' 트랜잭션 로그 테이블 ' 과 같은 시스템 처리시 내부 필요에 의한 엔터티는 업무적인 필요가 아닌,

         시스템 내부적인 필요이므로 관계 생략

 

 

 

 

 

 

 

 

---

4. 엔터티의 분류

 

엔터티는 실체유형에 따라 구분, 업무를 구성하는 모습에 따라 구분이 되는 발생시점에 의해 분류된다.

 

 

① 유무(有無)형에 따른 분류

 

유무형 분류	특징	예시
유형엔터티 (Tangible)	물리적인 형태, 안정적, 지속적 활용  업무로부터 엔터티 구분에 가장 용이	사원, 물품, 강사
개념엔터티 (Conceptual)	물리적인 형태 X  관리해야 할 개념적 정보로 구분 가능	조직, 보험상품
사건엔터티 (Event Entity)	업무를 수행함에 따라 발생됨  비교적 발생량이 많음, 통계자료에 이용	주문, 청구, 미납

 

 

② 발생시점에 따른 분류

 

엔터티의 발생시점에 따라 구분된다.

발생시점 분류	특징	예시
기본엔터티, 키엔터티 (Fundamental, Key)	업무에 원래 존재  다른 엔터티와 관계 생성 X , 독립적 생성 가능  다른 엔터티의 부모 역할 함  주식별자를 상속 X , 자신의 고유 주식별자	사원, 부서, 고객 ,상품, 자재
중심엔터티 (Main)	기본엔터티로부터 발생  업무의 중심적인 역할  많은 양의 데이터 발생  다른 엔터티와의 관계 → 행위엔터티 생성	계약, 사고, 예금원장 ,청구,주문,매출
행위엔터티 (Active)	두 개 이상의 부모엔터티로부터 발생  자주 내용이 바뀜, 데이터량 증가  분석초기 단계에서 도출 X  상세 설계단계, 상관모델링에서 도출 O	주문목록 ,사원변경이력

 

 

③ 엔터티 분류 방법의 예

 

엔터티 분류

유무형에 따라, 발생시점에 따라, 그리고 스스로 생성할 수 있는지 여부에 따라  < 독립엔터티 / 의존엔터티 > 를 구분할 수 있다.

 

 

 

 

 

 

 

---

5. 엔터티의 명명

▷ 엔터티 명명 (표기법)

     1) 가능한 업계 (현업업무) 용어 사용

     2) 가능한 약어 사용 X

     3) 단수명사 사용

     4) 모든 엔터티에서 유일하게 이름 부여

     5) 엔터티 생성 의미대로 이름 부여

 

 

" 엔터티 생성 의미대로 이름 부여 " 에서 적절하지 못한 엔터티명이 부여되는 경우가 빈번하다.

업무 목적에 상관없이 임의로 이름을 부여하면, 프로젝트에서 커뮤니케이션 오류로 인한 문제가 발생한다.

 

ex. 고객이 주문하여 발생한 행위엔터티에 대해 ' 주문목록 ' 과 ' 고객제품 ' 이라고 엔터티명을 정할 수 있다.

    ' 고객제품 ' 이라면 ' 고객이 주문한 제품 ' 또는 ' 고객의 제품 ' 두 가지로 의미가 애매모호하다.

 

 

 

 

 

 

 

---