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