[SQLD 정리] 데이터 모델링 기초(2) - 엔터티(Entity)

[SQLD 정리] 데이터 모델링 기초(2) - 엔터티(Entity)

안녕하세요. 갓대희 입니다. 이번 포스팅은 [ 데이터 모델링 기초(2) - 엔터티 ] 입니다. : ) 

과목 Ⅰ - 데이터 모델링의 이해

[ 제 2절 엔터티 (Entity) ]

1. 엔터티의 개념

▶ 정의

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

 - 업무 활동상 지속적인 관심을 가지고 있어야 하는 대상으로서 그 대상들 간에 동질성을 지닌 인스턴스들이나 그들이 행하는 행위의 집합

1) 엔터티는 사람, 장소, 물건, 사건, 개념 등의 명사에 해당한다.

2) 엔터티는 업무상 관리가 필요한 관심사에 해당한다.

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

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

위의 예에서 

1) 엔티티 : 과목, 강사, 사건

2) 각 엔터티의 인스턴스 

 - 과목 엔터티의 인스턴스 : 수학, 영어

 - 강사 엔터티의 인스턴스 : 이춘식, 조시형

이를 IE 표기법, Barker 표기법으로 표현 하면 다음과 같다.

3. 엔터티의 특징

1) 반드시 해당 업무에서 필요하고 관리하고자 하는 정보이어야 한다.(ex, 환자, 토익 응시 횟수)

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

3) 영속적으로 존재하는 인스턴스의 집합이어야 한다. ('한 개' 가 아니라 '두 개 이상')

4) 업무 프로세스에 의해 이용 되어야 한다.

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

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

1) 업무에서 필요하고 관리하고자 하는 정보

ex) 환자라는 엔터티

 - 병원 => 의료 시스템을 개발시 반드시 필요한 엔터티

 - 회사 => 회사의 정보로 활용할 필요가 없음.

2) 식별 가능

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

 - 유일 식별자 : 해당 엔터티 인스턴스만의 고유한 이름

 - 두 개 이상의 엔터티를 대변하면 잘못된 설계이다.

ex) 환자 엔터티

 - 식별자 : 이름 => 동명이인이 발생할 수 있으므로 유일 식별자가 아니다.

 - 식별자 : 중복되지 않는 고유 사번 => 올바른 식별자.

3) 인스턴스 집합

 - "두 개 이상"

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

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

 - 반드시 필요한 엔터티로 선정 하였는데 업무프로세스에 의해 이용되지 않는다면 잘못 선정된 케이스

5) 속성(Attribute)을 포함

 - 속성을 포함하지 않고 엔터티의 이름만 가지고 있는 경우 관계가 생략되어 있거나 업무 분석이 미진하여 속성정보가 누락된 경우

 - 주식별자만 존재하고 일반 속성은 전혀 없는 경우도 올바르지 않은 케이스.

   (But, 예외적으로 관계엔터티(Associative Entity)의 경우 주식별자 속성만 갖고 있어도 엔터티로 인정)

환자

환자 번호

=> 위와 같이 속성이 존재하지 않는 경우 엔터티가 아니다. (관계엔터티 예외)

6) 관계의 존재

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

 - 엔터티가 도출되었다는 것은 해당업무내 연관성을 갖고 다른 엔터티와 관계를 맺고 있음을 나타냄

단, 통계성 엔터티 도출, 코드성 엔터티 도출, 시스템 처리시 내부 필요에 의한 엔터티 도출과 같은 경우 관계 표현 생략 한다.

6.1 통계

 - 업무진행 엔터티로부터 통계업무만(Read Only)을 위해 별도로 엔터티를 다시 정의하게 됨.

6.2 코드

 - 너무 많은 엔터티와 엔터티간의 관계 설정으로 인해 데이터 모델의 읽기효율성(Readability)이 저하되어 모델링 작업 진행이 어려울 수 있게 될 수 있다.

 - 또한 물리적으로 테이블과 프로그램 구현 이후에도 외부키에 의한 참조무결성을 체크하기 위한 규칙을 데이터베이스 기능에 맡기지 않는 경우가 대부분, 논리적으로나 물리적으로 관계설정할 필요 없다.

6.3 시스템 처리시 내부 필요에 의한 엔터티

 - ex) 트랜잭션 로그 테이블 등

 - 시스템 내부적인 필요에 의해 생성된 엔터티이므로 관계 생략

4. 엔터티의 분류

▶ 유무형에 따른 분류

1) 유형엔터티(Tangible Entity)

 - 물리적인 형태가 있다.

 - 안정적이며 지속적으로 활용된다.

 - 업무로부터 엔터티를 구분하기 가장 용이

 - ex) 사원, 물품, 강사 등

2) 개념엔터티(Conceptual Entity)

 - 물리적인 형태가 없음

 - 관리해야 할 개념적 정보로 구분됨

 - ex) 조직, 보험상품 등

3) 사건 엔터티(Event Entity)

 - 업무 수행함에 따라 발생되는 엔터티

 - 발생량이 많아 각종 통계자료에 이용되기도 함

 - ex) 주문, 청구, 미납 등

▶ 발생시점에 따른 분류

1) 기본/키 엔터티(Fundamental Entity, Key Entity)

 - 그 업무에 원래 존재하는 정보.

 - 다른 엔터티와 관계에 의해 생성되지 않고 독립적으로 생성 가능, 자신은 타 엔터티의 부모역할을 한다.

 - 다른 엔터티로부터 주식별자를 상속받지 않고 자신의 고유한 주식별자를 갖게 된다.

 - ex) 사원, 부서, 고객, 상품, 자재 등

2) 중심 엔터티(Main Entity)

 - 기본 엔터티로부터 발생되고 업무에 있어 중심적인 역할을 한다.

 - 데이터의 양이 많이 발생 되고, 다른 엔터티와의 관계를 통해 많은 행위 엔터티를 생성한다.

 - ex) 제약, 사고, 예금원장, 청구, 주문, 매출 등

3) 행위 엔터티(Active Entity)

 - 두 개 이상의 부모엔터티로부터 발생되고, 자주 내용이 바뀌거나 데이터량이 증가된다.

 - 분석초기 단계에서는 잘 나타나지 않으며 상세 설계단계나 프로세스와 상관모델링을 진행하면서 도출 될 수 있다.

 - ex) 주문목록, 사원 변경이력 등

▶ 엔터티 분류 방법의 예

1) 유무형에 따라

 - 유형 (사원, 물품)

 - 사건 (주문, 창구)

 - 개념 (조직, 장소)

2) 발생시점에 따라

 - 중심 (접수, 계약)

 - 기본/키 (사원, 부서)

 - 행위 (주문내역, 계약진행)

3) 기타

 - 스스로 생성될수 있는지에 따라 (독립엔터티, 의존엔터티)

5. 엔터티의 명명

1) 현업업무에서 사용하는 용어 사용

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

3) 단수명사를 사용한다.

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

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

[ 관련 문제 풀어보기] 

1. 엔터티의 특징으로 가장 부적절한 것은?

1) 속성이 없는 엔터티는 있을 수 없다. 엔터티는 반드시 속성을 가져야 한다.

2) 엔터티는 다른 엔터티와 관계가 있을 수 밖에 없다. 단, 통계성 엔터티나, 코드성 엔터티의 경우 관계를 생략할 수 있다.

3) 객체지향 디자인패턴에는 싱글턴패턴이 있어 하나의 인스턴스를 가지는 클래스가 존재한다. 이와 유사하게 엔터티는 한 개의 인스턴스를 가지는 것만으로도 충분한 의미를 부여할 수 있다.

4) 데이터로서 존재하지만 업무에서 필요하지 않으면 해당 업무의 엔터티로 성립될 수 없다.

1번 정답 : 3번

2. 다음 중 다른 엔터티로부터 주식별자를 상속받지 않고 자신의 고유한 주식별자를 가지며 사원, 부서, 고객, 상품, 자재 등이 예가 될 수 있는 엔터티는?

1) 기본 엔터티(키엔터티)

2) 중심 엔터티(메인엔터티)

3) 행위 엔터티

4) 개념 엔터티

2번 정답 : 1번

관련글

ㆍ SQLD 자격증 준비 및 합격 후기