[Database] Entity

이번 포스팅은 데이터베이스의 용어와 엔터티의 개념 및 특징에 대해 포스팅하고 있습니다.

[Intro]

플라톤은 인간이 본질을 보지 못하고, 단순히 눈 앞의 것만 보면서 착각하는 것을

마치 동굴안의 사람이 바깥세상의 빛으로부터 생겨난 그림자를 보며,

두려워하는 모습과 같다고 동굴의 비유로 예를 들어 설명합니다.

인간은 항상 눈에 보이는 현상을 떠나서 참된 본질을 인식해야 한다고 강조했습니다.

데이터베이스에서 엔터티와 테이블의 관계는 마치 이러한 빛(실체)과 그림자(현상)의

관계와 매우 유사합니다.

엔터티에 대해 설명하기에 앞서 간략하게 용어들에 대해 한번 정리해보겠습니다.

[Terms]

데이터베이스를 처음 접하거나, 공부를 하다보면 모르는 용어들이 쏟아져 나옵니다...

튜플, 인스턴스, 엔터티, 릴레이션, 스키마, 도메인... 등등....

(레코드나 튜플이나 행이나 다 같은거 아냐?..개념은 하난데 별명이 왜 서너게인지...😱)

비슷한 용어들에 대해 상황에 따라 용어가 달라지므로, 해당 개념들을 정확한 상황에 맞게

사용할 필요가 있습니다.

릴레이션 = 테이블 = (스키마 + 인스턴스)

• 릴레이션이란 테이블을 말합니다.

• 릴레이션은 스키마, 인스턴스로 이루어져 있습니다.

스키마

• 스키마는 관계형 데이터베이스에서 기본 구조를 정의하는 것입니다.

• 스키마는 테이블의 첫 행인 헤더를 나타내며, 속성, 자료타입 등의 정보를 담고 있습니다.

인스턴스

• 인스턴스는 테이블에서 실제로 저장된 데이터를 말합니다 .

Tuple(튜플) = Row(행) = Cardinality(카디널리티)

• 튜플은 릴레이션에서 행(가로)의 개수를 의미합니다

• 위 그림에서 튜플의 개수는 3입니다

Attribute(속성) = Column(열) = Degree(차수)

• 속성은 릴레이션에서 열(세로)의 개수를 의미합니다

• 위그림 속성의 개수는 3입니다

도메인

• 도메인은 속성이 가질 수 있는 값의 집합입니다

• 무지개라는 속성에는 7가지 도메인이 존재합니다.

[개념]

엔터티에 대해서 데이터 모델과 데이터베이스에 권위자들은 다음과 같이 엔터티를 정의하고 있습니다.

변별할 수 있는 사물 - Peter Chen (1976) -

데이터베이스 내에서 변별 가능한 객체 - C.J Date (1986) -

정보를 저장할 수 있는 어떤 것 - James Martin (1989) -

정보가 저장될 수 있는 사람, 장소, 물건, 사건 그리고 개념 등 - Thomas Bruce (1992) -

데이터 모델을 이해할 때 가장 명확하게 이해해야 하는 개념 중에 하나가 바로 엔터티(Entity)입니다.

우리말로 실체, 객체라고 번역하기도 하는데 실무적으로 엔터티 엔터티라는 용어를 그대로 사용합니다.

한마디로 엔터티는 저장이 되기 위한 어떤 것(Thing) 이라고 할 수 있습니다.

또한 엔터티는 그 집합에 속하는 개체들의 특성을 설명할 수 있는 속성(Attribute)를 지닙니다.

가령 과목이라는 엔터티안에는 국어, 수학, 영어라는 인스턴스들이 존재할 수 있습니다.

[표기법]

엔터티를 표현하는 방법은 각각의 표기법에 따라 조금씩 차이는 있지만 대부분

사각형으로 표현됩니다. 다만 이 안에 표현되는 속성의 표현방법이 조금씩 다를 수 있습니다.

[특징]

엔터티의 특징들은 다음과 같습니다.

 1. 반드시 해당 업무에서 필요하고 관리하고자 하는 정보이어야 한다.
	(ex_ 환자, 토익의 응시횟수, …)
    
 2. 유일한 식별자(key)에 의해 식별이 가능해야 한다.

 3. 영속적으로 존재하는 인스턴스의 집합이어야 한다.
	(ex_‘한 개’가 아니라 ‘두 개 이상’)
    
 4. 엔터티는 업무 프로세스에 의해 이용되어야 한다.

 5. 엔터티는 반드시 속성이 있어야 한다.

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

🔽하나씩 예시를 들어가면서 이해해보겠습니다🔽

1. 반드시 해당 업무에서 필요하고 관리하고자 하는 정보이어야 한다.

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

위 그림에서 환자 정보는 쌩뚱맞게 회사에선 필요가 없겠죠?

2. 식별이 가능해야함

식별자는 우리가 흔히 사용하는 KEY라는 개념의 논리적 용어입니다.

만일 성별이 식별자가 되버린다면, 남자인 개소리꾼이라는 사람의 정보는 남자로 기록됩니다.

" 어이 거기 남자!!" 라고 불러서 찾으려고하면 개소리꾼이 아닌 사람도

응답하겠죠?

3. 인스턴스의 집합

친구와 여행을 갈때 가방에 여러가지 준비물들을 넣기는 하지만,

우리는 가방을 준비해야하기 때문에 가방을 담을 가방을 준비하지는 않습니다.

엔터티도 마찬가지입니다. 값이 하나인 주체가 되는 상위 값은 보통 값이 하나이므로

인스턴스의 집합이 될 수 없는 것이죠!

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

해당 엔터티는 반드시 필요에 의해 선정되었다면 이용이 되어야합니다.

보통 이러한 경우는 데이터 모델링을 할때 미처 발견하지 못했다가,

프로세스를 구성해나가는 과정에서 발견하게 됩니다.

제 생각입니다만,, 필요한 기능과 구성들을 고려하여 데이터 모델링을 할때 요구사항 위주의

기능 분석에 기반하여 모델링을 하는 것이 위와 같이 이용되지 않는 엔터티를 만드는 상황을

예방할 수 있다고 생각합니다.

5. 속성을 포함

반드시 속성이 포함되어야 합니다. 속성을 포함하지 않고 엔터티의 이름만 가지고 있는 경우는 관계가 생략되어 있거나 업무 분석이 미진하여 속성 정보가 누락되는 경우에 해당 됩니다.

저는 처음 봤을때 엥? 3번이랑 같은말 아니야? 생각이 들었습니다.

하지만 3번의 특성의 경우에는 해당 실제 값이 하나인 경우이고, 3번의 회사나 병원과 같이

해당 엔터티가 해당 병원 이름에 대한 속성 정보 하나만 딸랑 갖고 있는 경우를 의미합니다.

보통 이와같이 속성값이 누락되는 경우는 해당 엔터티가 하나의 속성 단위여야 하는데 억지로

빼내서 엔터티단위로 만들고자 할때 발생하기도 합니다.

6. 관계의 존재

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

관계형 데이터 베이스에서 혼자 노는 왕따 엔터티가 있어서는 안됩니다.

관계가 설정되지 않은 엔터티의 도출은 부적절한 엔터티가 도출되었거나 아니면 다른 엔터티와

적절한 관계를 찾지 못했을 가능성이 크다고 할 수 있습니다.

[분류]

엔터티는 실체유형(유무형)에 따라 구분하거나, 엔터티의 발생시점에 의해 분류 될 수 있습니다.

1. 실체유형(유무형)에 따른 분류

• 유형 엔터티(Tangible Entity)

물리적인 형태가 존재하는 엔터티이며 안정적이고 지속적으로 활용되는 엔터티이다.

• 개념 엔터티(Conceptual Entity)

물리적인 형태는 존재하지 않고 관리해야 할 개념적인 정보로 구분이 되는 엔터티이다.

• 사건 엔터티(Event Entity)

업무를 수행함에 따라 발생되는 엔터티이다.

2. 발생시점에 따른 분류

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

해당 업무에 원래 존재하는 정보로 다른 엔터티와의 관계에 의해 발생 또는 생성되지 않고 독립적으로 존재하는 엔터티이다. 이는 독립적으로 생성이 가능하며 다른 엔터티의 부모역할을 한다.

• 중심 엔터티(Main Entity)

기본 엔터티로 부터 발생되며 업무에 있어서 중심적인 역할을 한다. 일반적으로 데이터 양이 많으며 다른 엔터티와의 관계를 통해 행위 엔터티를 생성한다.

• 행위 엔터티(Active Entity)

두 개이상의 부모엔터티로 부터 주로 발생되고, 자주 엔터티의 내용이 바뀌거나 데이터양이 증감한다. 분석초기 단계보다는 상세 설계단계나 프로세스와 상관모델링을 진행하면서 도출될 수 있다.

[엔터티의 명명(Naming)]

엔터티의 이름을 정하는 데에 있어서는 다음과 같은 원칙을 지켜야 합니다.

- 가능하면 현업업무에서 사용하는 용어를 사용한다.

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

- 단수 명사를 사용한다.

- 모든 엔터티를 통틀어서 유일한 이름을 가져야 한다.

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