[과목 I 1장 2절] 엔터티

1. 엔터티의 개념

• 데이터 모델을 이해할 때 가장 명확하게 이해해야 하는 개념 중에 하나가 바로 엔터티 (Entity)
• 엔터티에 대해서 데이터 모델과 데이터베이스에 권위자가 정의한 사항은 다음과 같음
  • 변별할 수 있는 사물 - Peter Chen
  • 데이터베이스 내에서 변별 가능한 객체 - C.J Date
  • 정보를 저장할 수 있는 어떤 것 - James Martin
  • 정보가 저장될 수 있는 사람, 장소, 물건, 사건, 개념 등 - Thomas Bruce

 

• 위 정의들의 공통점은 다음과 같음
  • 엔터티는 사람, 장소, 물건, 사건, 개념 등의 명사에 해당
  • 엔터티는 업무상 관리가 필요한 관심사에 해당
  • 엔터티는 저장이 되기 위한 어떤 것 (Thing)

 

• 종합하면 엔터티란 `업무에 필요하고 유용한 정보를 저장하고 관리하기 위한 집합적인 것 (Thing)`으로 설명 가능
  • 엔터티는 업무 활동상 지속적인 관심을 가지고 있어야 하는 대상으로서 그 대상들 간에 동질성을 지닌 인스턴스들이나 그들이 행하는 행위의 집합으로 정의 가능
  • 엔터티는 그 집합에 속하는 개체들의 특성을 설명할 수 있는 속성 (Attribute)을 ㄱ자음
  • ex) `학생`이라는 엔터티는 학번, 이름, 이수학점, 등록일자, 생일, 주소, 전화번호, 그리고 전공 등의 속성으로 특징지어질 수 있음

 

• 엔터티는 인스턴스의 집합이라고 부를 수 있고, 반대로 인스턴스라는 것은 엔터티의 하나의 값에 해당한다고 정의 가능
  • ex) 과목은 수학, 영어, 국어 등이 존재할 수 있는데 수학, 영어, 국어는 각각이 과목이라는 엔티티의 인스턴스

 

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

• 엔티티를 표현하는 방법은 각각의 표기법에 따라 조금씩 차이는 있지만 대부분 사각형으로 표현됨

 

https://snnchallenge.tistory.com/179

 

부연 설명

• 과목, 강사, 사건은 엔터티에 해당하고 수학, 영어는 과목이라는 엔터티의 인스턴스
• 이춘식, 조시형은 강사라는 엔터티의 인스턴스
• 사건번호인 2010-001, 2010-002는 사건 엔터티에 대한 인스턴스

 

https://snnchallenge.tistory.com/179

 

3. 엔터티의 특징

• 엔터티는 다음과 같은 특징을 가지고 있으며, 만약 도출한 엔터티가 다음의 성질을 만족하지 못하면 적절하지 않은 엔터티일 확률이 높음
  • 반드시 해당 업무에서 필요하고 관리하고자 하는 정보
  • 유일한 식별자에 의해 식별이 가능해야 함
  • 영속적으로 존재하는 인스턴스의 집합이어야 함
  • 엔터티는 업무 프로세스에 의해 이용되어야 함
  • 엔터티는 반드시 속성이 있어야 함
  • 엔터티는 다른 엔터티와 최소 한 개 이상의 관계가 있어야 함

 

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

• 엔터티는 반드시 시스템 구축하고자 하는 업무에서 필요로 하고 관리하고자 하는 정보
• 시스템 구축 대상인 해당 업무에서 해당 엔터티를 필요로 하는가를 판단하는 것이 중요 
  • ex) 환자라는 엔터티는 의료 시스템을 개발하는 병원에서 반드시 필요한 엔터티
  • ex) 일반 회사에서 직원들이 병에 걸려 업무에 지장을 주더라도 해당 정보를 그 회사의 정보로서 활용하지는 않을 것

 

나. 식별 가능해야

• 엔터니는 식별자 (Unique Identifier)에 의해 식별
  • 유일한 식별자는 해당 엔터티의 인스턴스만의 고유한 이름
  • 두 개 이상의 엔터티를 대변할 경우 그 식별자는 잘 못 설계된 것

 

• 어떤 엔터티이던지 임의의 식별자 (일련번호)를 부여하여 유일하게 만들 수는 있지만, 엔터티를 도출하는 경우에 각각의 업무적으로 의미를 갖는 인스턴스가 식별자에 의해 한 개씩만 존재하는지 검증 필요

 

다. 인스턴스의 집합

• 엔터티는 영속적으로 존재하는 인스턴스의 집합
• 엔터티의 특징 중 `한 개`가 아니라 `두 개 이상`이라는 집합 개념은 매우 중요
  • 두 개 이상이라는 개념은 엔터티뿐만 아니라 엔터티 간의 관계, 프로세스와의 관계 등 업무를 분석하고 설계하는 동안 설계자가 모든 업무에 대입해 보고 검증해 보아야 할 중요한 개념
  • 하나의 엔터티는 여러 개의 인스턴스를 포함
  • ex) 통신사라는 엔터티는 `SKT`, `KT`, `LG U+`와 같은 인스턴스의 집합

 

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

• 업무 프로세스 (Business Process)가 해당 엔터티를 반드시 이용

 

https://snnchallenge.tistory.com/179

 

마. 속성 포함

• 엔터티는 반드시 속성 (Attributes)을 포함
• 예외적으로 관계 엔터티 (Associative Entity)는 주식별자 속성만 가지고 있어도 엔터티로 인정

 

https://snnchallenge.tistory.com/179

 

바. 관계의 존재

• 엔터티는 다른 엔터티와 최소 한 개 이상의 관계를 가짐
  • 엔터티가 도출되었다는 것은 기본적으로 해당 업무 내에서 업무적인 연관성 (존재적 연관성, 행위적 연관성)을 가지고, 다른 엔터티와의 연관의 의미를 갖고 있음
  • 관계가 설정되지 않은 엔터의 도출은 부적절한 엔터티가 도출되었거나 아니면 다른 엔터티와의 적절한 관계를 찾지 못했을 가능성이 높음

 

• 단, 통계성 엔터티 도출, 코드성 엔터티 도출, 시스템 처리시 내부 필요에 의한 엔터티 도출과 같은 경우 데이터 모델링을 하면서 관계를 생략해 표현해야 하는 경우가 있음
  • 통계를 위한 엔터티는 업무 진행 엔터티로부터 Read Only인 통계 업무만을 위해 별도로 엔터티를 다시 정의하게 되므로 엔터티 가간 관계가 생략되는 경우에 해당
  • 코드를 위한 엔터티는 너무 많은 엔터티와 엔터티 간의 관계 설정으로 인해 데이터 모델의 읽기 효율성이 저하되어 도저히 모델링 작업을 진행할 수 없음
  • 시스템 내부적인 필요에 따라 생성된 엔터티의 경우 관계를 생략

 

4. 엔터티의 분류

 

가. 유무형에 따른 분류

• 일반적으로 엔터티는 유무형에 따라 유형 엔터티, 개념 엔터티, 그리고 사건 엔터티로 구분됨
  • 유형 엔터티 (Tangible Entity): 물리적인 형태가 있고 안정적이며 지속적으로 활용되는 엔터티로 업무로부터 엔터티를 구분하기 가장 용이함
  • 개념 엔터티 (Conceptual Entity): 물리적인 형태는 존재하지 않고 관리해야 할 개념적 정보로 구분되는 엔터티
  • 사건 엔터티 (Event Entity): 업무를 수행함에 따라 발생하는 엔터티로서 비교적 발생량이 많으며 각종 통계 자료에 이용될 수 있음

 

나. 발생 시점에 따른 분류

• 엔터티의 발생 시점에 따라 기본 엔터티, 중심 엔터티, 그리고 행위 엔터티로 구분할 수 있음
  • 기본 엔터티 (Fundamental Entity): 업무에 원래 존재하는 정보로서 다른 엔터티와 관계에 의해 생성되지 않고 독립적으로 생성이 가능하고 자신은 타 엔터티의 부모 역할을 하게 됨 
  • 중심 엔터티 (Main Entity): 기본 엔터티로부터 발생되고 해당 업무에서 중심적인 역할을 수행, 데이터의 양이 많이 발생하고 다른 엔터티와의 관계를 통해 많은 행위 엔터티를 생성
  • 행위 엔터티 (Active Entity): 두 갱 이상의 부모 엔터티로부터 발생하고, 자주 내용이 바뀌거나 데이터 양이 증가함, 상세 설계 단계나 프로세스와 상관 모델링을 진행하면서 도출됨

 

다. 엔터티 분류 방법 예

 

https://snnchallenge.tistory.com/181

 

5. 엔터티의 명명

• 엔터티를 명명하는 일반적인 기준은 다음과 같음
  • 현업 업무에서 사용하는 용어를 사용
  • 약어를 사용하지 않음
  • 단수 명사를 사용
  • 모든 엔터티에 유일하게 이름 부여
  • 엔터티 생성 의미대로 이름 부여

 

• `현업 업무에서 사용하는 용어`와 `모든 엔터티에 유이할게 이름 부여`는 대체적으로 잘 지켜지지만 적절하지 못한 엔터티명이 부여되면서 `엔터티 생성 의미대로 이름 부여` 원칙이 깨지는 케이스가 비번하게 발생
  • 중심 엔터티에서 간혹 적절하지 못한 엔터티명을 사용하는 경우 발생
  • 행위 엔터티에서는 꽤 많은 경우에 적절하지 못한 엔터티명을 사용하는 경우 발생
  • 엔터티의 이름을 업무 목적에 따라 생성되는 자연스러운 이름을 부여해야 하는데 이와 상관없이 임의로 부여하면, 프로젝트에서 커뮤니케이션 오류 문제를 야기할 수 있음
  • ex) 고객이 어떤 제품들을 주문함으로써 발생한느 행위 엔터티에 대해 주문 목록이라고도 할 수 있고 고객 제품이라고 할 수 있는데 만약 `고객 제품`이라고 명명하면 `고객이 주문한 제품`인지 아니면 `고객의 제품`인지 의미가 애매모호해질 수 있음

 

참고

SQL 전문가 가이드 2020 개정판 - 한국데이터산업진흥원