엔터티의 개념 및 정의
데이터 모델을 이해할 때 가장 명확하게 이해해야 하는 개념 중에 하나가 바로 엔터티
이다.
- 업무 활동상 지속적인 관심을 가지고 있어야 하는 대상
- 그 대상들 간에
동질성을 지닌 인스턴스
들이나 그들이 행하는 행위의 집합
으로 정의할 수 있다.
- 인스턴스의 집합 (집합적인 개념에 있어)
인스턴스
란? 엔터티의 하나의 값에 해당할 수 있다.
Entity: [학생]
Attribute: 학번, 이름, 이수학점, 등록일자, 생일, 주소, 전화번호, 전공 등
이러한 속성은 공통 속성도 있고, 엔터티 인스턴스 중 일부에만 해당하는 개별 속성도 존재한다.
엔터티 (Entity)
업무에 필요하고 유용한 정보를 저장하고 관리하기 위한 집합적인 것
- 실체, 객체
- 데이터 베이스 내에서 변별할 수 있는 사물
- 정보를 저장할 수 있는 어떤 것
엔터티에 포함되는 개념
- 사람, 장소, 물건, 사건, 개념 (명사)
- 업무상 관리가 필요한 관심사
- 저장이 되기 위한 어떤 것(Things)
엔터티와 인스턴스에 대한 내용과 표기법
- 대부분 엔터티는 사각형으로 ERD 에서 표기한다.
[과목] 이라는 엔터티가 존재하고
국어, 수학, 영어 라는 인스턴스가 존재한다.
- 참고로, 오브젝트 모델링에는 Class와 Object라는 개념이 있다.
엔터티의 특징
- 반드시 해당 업무에서
필요하고 관리하고자 하는 정보
여야 한다.
유일한 식별자
에 의해 식별이 가능해야 한다.
영속적
으로 존재하는 인스턴스의 집합이어야 한다. (두 개 이상의 인스턴스)
- 엔터티는
업무 프로세스
에 의해 이용되어야 한다.
- 엔터티는 반드시
속성
이 있어야 한다. (두 개 이상의 속성)
- 하나 이상의
관계
를 가지고 있어야 한다. (한 개 이상의 관계)
업무에서 필요로 하는 정보
- 반드시 시스템을 구축하고자 하는
업무에서 필요로 하고
관리하고자 하는 정보여야 한다.
식별이 가능해야 함
- Unique Identifier 에 의해
식별이 가능
해야 한다.
- 어떤 엔터티이건 임의의 식별자(일련 번호)를 부여하여 유일하게 만들 수 있지만, 도출 시 각각의 업무적으로 의미를 가지는 인스턴스가 식별자에 의해 한 개씩만 존재하는지 검증해 보아야 한다.
- 식별자는 고유한 것이어야 하며 중복이 발생해서는 안된다.
인스턴스의 집합
- 영속적으로 존재하는 인스턴스의 집합이어야 한다.
- 엔터티에서 한 개가 아니라
두개 이상의 집합
개념은 매우 중요한 개념이다.
- 엔터티간의 관계, 프로세스와의 관계 등 업무를 분석하고 설계하는 동안 설계자가 모든 업무에 대입해보고 검증해 보아야 할 중요한 개념이다.
하나의 인스턴스는 여러 개의 인스턴스를 포함한다.
업무 프로세스에 의해 이용
업무 프로세스
가 반드시 해당 엔터티를 이용해야 한다.
- 만약, 엔터티를 선정했는데 업무 프로세스에 의해 전혀 이용되지 않는다면 업무 분석이 정확하게 안되어 엔터티가 잘못 선정되거나 업무 프로세스 도출이 적절하게 이루어지지 않았음을 의미한다.
- 데이터 모델과 검증을 하거나,
- 상관 모델링을 할 때 엔터티와 단위 프로세스를 교차 점검하면서 문제점이 도출된다.
속성을 포함
- 반드시
속성을 포함
하고 있어야 한다.
- 단, 예외적으로 관계 엔터티 (Associative Entity) 의 경우는 주식별자 속성만 가지고 있어도 엔터티로 인정한다.
관계의 존재
- 엔터티는 다른 엔터티와
최소 한 개 이상의 관계
가 존재해야 한다.
- 엔터티가 도출되었다는 것은 해당 업무내에서 업무적인 연관성을 가지고 다른 엔터티와의 연관 의미를 가지고 있음을 나타낸다.
- 단, 예외로 관계를 생략하여 표현해야 하는 경우
통계성 엔터티
도출
- 업무 진행 엔터티로부터 통계업무(read only)만을 위해 별도로 엔터티를 다시 정의하게 되므로 엔터티간의 관계가 생략되는 경우에 해당한다.
코드성 엔터티
도출
- 너무 많은 엔터티와 엔터티간의 관계 설정으로 인해 읽기 효율성(Readability)이 저하되어 모델링 작업을 할 수 없게 되기 때문에
- 대부분의 코드성 엔터티는 외부키에 의한 참조무결성을 체크하기 위한 규칙을 db 기능에 맡기지 않은 경우가 많기 떄문에 논리적/물리적 관계를 설정할 필요가 없다.
- 시스템 처리시
내부 필요에 의한 엔터티
도출
- 예) 트랜잭션 로그 테이블
- 트랜잭션이 업무적으로 연관된 테이블과 관계 설정이 필요하지만, 시스템 내부적인 필요에 의해 생성된 엔터티 이므로 관계를 생략하게 된다.
엔터티의 분류
엔터티는 엔터티 자신의 성격
에 의해 따라 구분하거나, 업무를 구성하는 모습에 따른 발생시점
으로 구분할 수 있다.
유무형에 따른 분류
유형 엔터티
- Tangible Entity
물리적인 형태가 있으며
, 안정적 및 지속적으로 활용되는 엔터티이다.
- 업무로부터 엔터티를 구분하기가 가장 용이한다.
- 예) 사원, 물품, 강사
개념 엔터티
- Conceptual Entity
- 물리적인
형태는 존재하지 않고
관리해야 할 개념적 정보
로 구분이 되는 엔터티
- 예) 조직, 보험상품
사건 엔터티
업무를 수행함
에 따라 발생되는 엔터티
- 비교적 발생량이 많으며 각종 통계자료에 이용될 수 있다.
- 예) 주문, 청구, 미납
발생시점에 따른 분류
기본/키 엔터티
- Fundamental Entity (Key Entity)
- 해당 업무에
원래 존재하는 정보
- 다른 엔터티와 관계에 의해 생성되지 않고 독립적으로 생성이 가능하다.
- 자신은 타 엔터티의
부모의 역할
을 하게 된다.
- 다른 엔터티로부터 주식별자를
상속받지 않고
자신의 고유한 주식별자를 가지게 된다.
- 예) 사원, 부서, 고객, 상품, 자재
중심 엔터티
- Main Entity
기본 엔터티로부터
발생된다.
- 해당 업무에 있어
중심적인 역할
을 한다.
- 데이터의 양이 많이 발생되고, 다른 엔터티와의 관계를 통해 많은 행위 엔터티를 생성한다.
- 예) 계약, 사고, 예금원장, 청구, 주문, 매출
행위 엔터티
- Active Entity
두 개 이상의 부모 엔터티
로부터 발생된다.
- 자주 내용이 바뀌거나 데이터량이 증가한다.
분석 초기 단계에서는 잘 나타나지 않으며
상세 설계단계나 프로세스와 상관 모델링을 진행하면서 도출된다.
- 예) 주문목록, 사원변경이력
엔터티 분류 방법의 예
- 이 밖에도 스스로 생성될 수 있는지 여부에 따라 독립/의존 엔터티를 분류할 수 있다.
엔터티의 명명
- 가능하면 현업 업무에서 사용하는 용어를 사용한다.
- 가능하면 약어를 사용하지 않는다.
- 단수 명사를 사용한다.
- 모든 엔터티에서 유일하게 부여되는 이름이어야 한다.
- 엔터티 생성 의미대로 이름을 부여한다.
- 대체적으로 다섯번째는 제대로 잘 지켜지지 않는 경우가 있다.
- 예) 고객 제품이라는 엔터티가 존재하면
- 이는 고객의 제품인지, 고객이 주문한 제품인지
- 이때 임의로 이름을 부여하게 된다면 의사소통에서 오류를 발생할 수 도 있다.