엔티티(Entity)에 대해 알아봤습니다.

1. 엔터티의 개념

엔터티에 대해서 데이터 모델과 데이터 베이스에서 정의한 사항은 다음과 같음.

변별할 수 있는 사물

데이터베이스 내에서 변별 가능한 객체

정보를 저장할 수 있는 어떤 것

정보가 저장될 수 있는 사람, 장소, 물건, 사건 그리고 개념

 

정의들의 공통점은

엔터티는 사람, 장소 , 물건, 사건, 개념등의 명사임.

엔티티는 업무상 관리가 필요한 관심사에 해당

엔티티는 저장이 되기 위한 어떤 것 (Thing)이다.

 

엔티티는 "업무에 필요하고 유용한 정보를 저장하고 관리하기 위한 집합적인 것(Thing)"으로 설명됨. 업무 활동 상 지속적인 관심을 가지고 있어야 하는 대상. 대상들 간 동질성을 지닌 인스턴스나 행위의 집합. 엔티티는 개체들의 특성을 설명할 수 있는 속성(Attribute)를 가짐. 이러한 속성 가운데에는 엔티티 인스턴스 전체가 공유할 수 있는 공통 속성도 있고 일부에만 해당하는 개별 속성도 있을 수 있음.

---

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

엔티티는 인스턴스의 집합. 반대로 인스턴스는 엔티티의 하나의 값.

눈에 보이는 것만 엔티티라고 생각해서는 안됨. 눈에 보이지 않는 개념들도 엔티티로 인식할 수 있어야 함.

 

엔티티는 대부분 사각형으로 표현됨. 안에 표현되는 속성의 표현방법이 조금씩 다름. 

오브젝트 모델링에서는 클래스와 오브젝트라는 개념이 있는데, 클래스는 여러개의 오브젝트를 포함하는 오브젝트 깡통임.

 

---

3. 엔티티의 특징

담의 성질을 만족하지 못하면 적절하지 않은 엔티티일 확률이 높음.

 - 반드시 해당 업무에서 필요하고 관리하고자 하는 정보

- 유일한 식별자에 의해 식별이 가능해야함

- 영속적으로 존재하는 인스턴의 집합( 두개 이상이어야함!!)

- 업무 프로세스에 의해 이용되어야 함

- 속성이 있어야함

- 다른 엔티티와 최소 한개 이상의 관계가 있어야 한다.

(마치 직원이라고 생각하면 이해하기 쉬울듯. 업무에 필요하고/직원이라고 식별가능해야하고/두명이상있어야하며/업무를 해야하고/직원의 성격이 있어야하며/다른 직원과 교류해야함)

 

가. 업무에서 필요로 하는 정보

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

해당 업무에서 그 엔티티를 필요로 하는가를 판단하는 것이 중요.

(예: [환자]라는 엔티티는 [병원]에 필요하고 관리되어야하지만 [회사]에서는 굳이 관리하지는 않음. 회사에서는 [직원]이라는 엔티티가 있다면 더 필요로하고 관리해야하는 엔티티일듯. 하지만 [직원]과 [환자]는 사람이라는 공통된 속성이 있음)

 

나. 식별이 가능해야 함

식별자(Unique identifier)에 의해 식별이 가능해야 한다는 점. 식별자(일련번호)를 부여하여 유일하게 만들 수는 있지만, 엔티티를 도출하는 경우에 인스턴스가 식별자에 의해 한 개씩만 존재하는지 검증해야함. 유일한 식별자는 그 엔티티의 인스턴스마늬 고유한 이름. 이름으로 식별하는 경우 동명이인이 될 수 있으므로 유일하게 식별될 수 없음, 사원번호는 고유하게 부여된 번호이므로 식별자가 될 수 있음. (주민등록증 처럼 이해하면 쉬울 듯. 유일하게 하나만 지칭하는 것이 있어야함.)

 

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

"두 개 이상"이라는 집합개념은 매우 중요함. 엔티티 간의 관계, 프로세스와의 관계 등 업무를 분석하고 설계하는 동안 설계자가 모든 업무에 대입해보고 검증해 보아야할 중요한 개념

(예:[병원] ->  [병원]-세브란스(X) [병원]-세브란스,삼성의료원(O))

 

라. 업무프로세스에 의해 이용

그 엔티티가 업무프로세스에 반드시 이용해야 함. 잘못 선정되면 문제점이 도출되기 때문에 Create, Read, Update, Delete등이 발생하지 않는 고립된 엔티티의 경우 제거하거나 누락된 프로세스가 있는지 살펴보고 프로세스를 추가해야함.

 

마. 속성을 포함

반드시 속성이 포함되어야 한다는 점.

이름만 가지고 있는 경우는 관계가 생략되어 있거나, 업무 분석이 미진하여 속성정보가 누락되는 경우에 해당. 단!!!! 예외적으로 관계엔티티의 경우는 주식별자 속성만 가지고 있어도 엔티티로 인정.

 

바. 관계의 존재

엔티티는 다른 엔티티와 최소 한 개 이상의 관계가 존재해야 함. 엔티티가 도출되었다 = 업무 내에서 업무적인 연관성이 있다. 이므로 관계가 설정되지 않은 엔티티의 도출은 부적절한 엔티티이거나 관계가 적절치 않은 것임.

단!! 모델링을 하면서 관계를 생략하여 표현해야하는 경우

1) 통계를 위한 엔티티는 통계업무(ReadOnly)를 위해 별도로 엔티티를 다시 정의함으로 생략되는 경우

2) 코드를 위한 엔티티의 경우 너무 많거나, 관계 설정으로 인해 읽기효율성(Readability)가 저하되어 진행할 수 없을 때. 또한 물리적으로 무결성체크 시 데이터베이스 기능에 하지 않아 설정할 이유가 없음.

3) 시스템 처리시 내부 필요에 의한 엔티티의 경우 시스템 내부에 의해 생성된 거 이므로 관계 생략 가능.

---

4. 엔티티의 분류

엔티티 자신의 성격에 의해 실체 유형에 따라 구분하거나, 업무를 구성하는 모습에 따라, 구분이 되는 발생시점에 따라 분류할 수 있음.

 

가. 유무형에 따른 분류

유형엔티티, 개념엔티티, 사건 엔티티로 구분.

유형엔티티(Tangible Entity)는 물리적인 형태가 있음, 안정적임, 지속적으로 활용되는 엔티티, 업무로부터 엔티티를 구분하기 가장 용이 (직원 사장 등 유형명사)

개념엔티티(Conceptual Entity)는 물리적인 형태 없음, 관리해야할 개념적 정보로 구분되는 엔티티 (조직, 보험상품 등 무형명사)

사건 엔티티(Event Entity)는 업무 수행에 따라 발생되는 엔티티, 비교적 발생량이 많음, 각종 통계 자료에 이용될 수 있음. (주문 청구 미납 등 동사)

 

나. 발생시점에 따른 분류

기본/키엔티티(Fundamental Entity, Key entity), 중심엔티티(Main Entity), 행위 엔티티(Active Entity)로 구분.

1) 기본엔티티 : 그 업무에 원래 존재하는 정보. 다른 엔티티와 관계에 의해 생성되지 않고 독립적으로 생성이 가능, 타 엔티티의 부모 역할, 다른 엔티티로부터 주식별자를 상속받지 않고 자신의 고유한 주 식별자. (사원 부서 고객 등 대빵)

2) 중심 엔티티 : 기본엔티티에 의해 발생되고, 업무에 중심적인 역할, 데이터가 많이 발생되고, 관계를 통한 행위엔티티 생성(기본엔티티의 의한 결과 같은 느낌)

3) 행위 엔티티: 두개 이상의 부모엔티티로부터 발생되고, 자주 내용이 바뀌거나 데이터량이 증가, 분석 초기에는 잘 안나타나지만, 상세 설계단계나 상관모델링 하면서 도출될 수 있음(부산물 같은 느낌. 주문목록, 사원변경이력)

 

다. 엔티티 분류 방법의 예

스스로 생성될 수 있는 지에 따라 독립/의존 엔티티로 구분할 수 있음.

---

5. 엔티티의 명명

엔티티를 명명하는 일반적인 기준은

1)가능하면 현업업무에서 사용하는 용어 사용.

2)가능하면 약어를 사용하지 않음.

3)단수명사를 사용.

4)모든 엔티티에서 유일하게 이름이 부여되어야함.

5)엔티티 생성의미대로 이름을 부여함.

 

1~4)의 원칙은 잘 지켜지지만 5)는 잘 안지켜짐. 적절하지 못한 엔티티 명이 부여 될 수 있고 이러면 의미가 애매모호해질 수 있음. 프로젝트에서는 커뮤니케이션 오류로 문제를 야기할 수 있음. (예: 고객제품 = '고객이 주문한 제품? 고객한테 받은 제품? 이러면 해석 오류 나서 커뮤니케이션 박살남)