1. 개체( Entity : 엔티티 )
1) 엔티티의 개념
데이터 모델을 이해할 때 가장 명확하게 이해해야 하는 개념 중에 하나가 바로 엔터티(Entity)이다. 이것은 우리말로 실체, 객체라고 번역하고 다음과 같이 정리할 수 있다.
가. 엔터티는 사람, 장소, 물건, 사건, 개념 등의 명사에 해당한다.
나. 엔터티는 업무상 관리가 필요한 관심사에 해당한다.
다. 엔터티는 저장이 되기 위한 어떤 것(Thing)이다.
엔터티는 그 집합에 속하는 개체들의 특성을 설명할 수 있는 속성(Attribute)을 갖는데, 예를 들어 ‘학생’이라는 엔터티는 학번, 이름, 이수학점, 등록일자, 생일, 주소, 전화번호, 전공 등의 속성으로 특징지어질 수 있다.
또한 엔터티는 인스턴스의 집합이라고 말할 수 있고, 반대로 인스턴스라는 것은 엔터티의 하나의 값에 해당한다고 정의할 수 있다.
예를 들어 과목은 수학, 영어, 국어가 존재할 수 있는데 수학, 영어, 국어는 각각이 과목이라는 엔터티의 인스턴스들이라고 할 수 있다. 또한 사건이라는 엔터티에는 사건번호2010-001, 2010-002 등의 사건이 인스턴스가 될 수 있다. 엔터티를 이해할 때 눈에 보이는(Tangible)한 것만 엔터티로 생각해서는 안되며 눈에 보이지 않는 개념 등에 대해서도 엔터티로서 인식을 할 수 있어야 한다. 실제 업무상에는 눈에 보이지 않는 것(Thing)이 엔터티로 도출되는 경우가 많기 때문에 더더욱 주의할 필요가 있다.
2) 엔터티와 인스턴스에 대한 내용과 표기법
엔터티를 표현하는 방법은 각각의 표기법에 따라 조금씩 차이는 있지만 대부분 사각형으로 표현된다.
다만 이 안에 표현되는 속성의 표현방법이 조금씩 다를 뿐이다.
엔터티와 엔터티간의 ERD를 그리면 다음과 같이 표현할 수 있다.
엔티티에 대한 표기법도 [IE 표기법]과 [Barker 표기법]으로 구분할 수 있다.
3) 엔티티의 특징
가. 반드시 해당 업무에서 필요하고 관리하고자 하는 정보이어야 한다.
나. 유일한 식별자에 의해 식별이 가능해야 한다.
다. 두개 이상의 인스턴스의 집합이어야 한다.
라. 업무프로세스에 의해 이용되어야 한다.
마. 속성을 포함해야 한다.
바. 한 개 이상의 관계가 존재해야 한다.
가. 반드시 해당 업무에서 필요하고 관리하고자 하는 정보이어야 한다.
사람이 살아가면서 환자는 발생할 수 밖에 없다. 그러나 일반회사의 인사시스템에서는 비록 직원들에 의해서 환자가 발생이 되지만 인사업무 영역에서 환자를 별도로 관리할 필요가 없다. 다른 예로 병원에서는 환자가 해당 업무의 가장 중요한 엔터티가 되어 꼭 관리해야 할 엔터티가 된다. 이와 같이 엔터티를 도출할 때는 업무영역 내에서 관리할 필요가 있는지를 먼저 판단하는 것이 중요하다.
나. 유일한 식별자에 의해 식별이 가능해야 한다.
유일한 식별자는 그 엔터티의 인스턴스만의 고유한 이름이다. 두 개 이상의 엔터티를 대변하면 그 식별자는 잘못 설계된 것이다. 예를 들어 직원을 구분할 수 있는 방법은 이름이나 사원번호가 될 수가 있다. 그러나 이름은 동명이인(同名異人)이 될 수 있으므로 유일하게 식별될 수 없다. 사원번호는 회사에 입사한 사람에게 고유하게 부여된 번호이므로 유일한 식별자가 될 수 있는 것이다.
다. 두개 이상의 인스턴스의 집합이어야 한다.
엔티티의 특징 중 “한 개”가 아니라 “두 개 이상”이라는 집합개념은 매우 중요한 개념이다.
인스턴스가 한 개 밖에 없으면 집합이 아니므로 엔티티 성립이 되지 않는다.
라. 업무프로세스에 의해 이용되어야 한다.
네 번째는 업무프로세스(Business Process)가 그 엔터티를 반드시 이용해야 한다는 점이다.
첫 번째 정의에서처럼 업무에서 반드시 필요하다고 생각하여 엔터티로 선정하였는데 업무프로세스에 의해 전혀 이용되지 않는다면 업무 분석이 정확하게 안되어 엔터티가 잘못 선정되거나 업무프로세스 도출이 적절하게 이루어지지 않았음을 의미한다.
마. 속성을 포함해야 한다.
다섯 번째는 엔터티에는 반드시 속성(Attributes)이 포함되어야 한다는 점이다.
속성을 포함하지 않고 엔터티의 이름만 가지고 있는 경우는 관계가 생략되어 있거나 업무 분석이 미진하여 속성정보가 누락되는 경우에 해당한다.
또한 주식별자만 존재하고 일반속성은 전혀 없는 경우도 마찬가지로 적절한 엔터티라고 할 수 없다.
단, 예외적으로 관계엔터티(Associative Entity)의 경우는 주식별자 속성만 가지고 있어도 엔터티로 인정한다.
바. 한 개 이상의 관계가 존재해야 한다.
여섯 번째는 엔터티는 다른 엔터티와 최소 한 개 이상의 관계가 존재해야 한다는 것이다.
기본적으로 엔터티가 도출되었다는 것은 해당 업무내에서 업무적인 연관성(존재적 연관성, 행위적 연관성)을 가지고 다른 엔터티와의 연관의 의미를 가지고 있음을 나타낸다.
그러나 관계가 설정되지 않은 엔터티의 도출은 부적절한 엔터티가 도출되었거나 아니면 다른 엔터티와 적절한 관계를 찾지 못했을 가능성이 크다.
4) 엔티티의 분류
가. 유무(有無)형에 따른 분류
일반적으로 엔터티는 유무형에 따라 유형엔터티, 개념엔터티, 사건엔터티로 구분된다.
유형엔터티(Tangible Entity)는 물리적인 형태가 있고 안정적이며 지속적으로 활용되는 엔터티로 업무로부터 엔터티를 구분하기가 가장 용이하다. 예를 들면, 사원, 물품, 강사 등이 이에 해당된다.
개념엔터티(Conceptual Entity)는 물리적인 형태는 존재하지 않고 관리해야 할 개념적 정보로 구분이 된다.
예를 들면, 조직, 보험상품 등이 이에 해당된다.
사건 엔터티(Event Entity)는 업무를 수행함에 따라 발생되는 엔터티로서 비교적 발생량이 많으며 각종 통계자료에 이용될 수 있다. 예를 들면, 주문, 청구, 미납 등이 이에 해당된다.
나. 발생시점(發生時點)에 따른 분류
엔터티의 발생시점에 따라 기본/키엔터티(Fundamental Entity, Key Entity), 중심엔터티(Main Entity), 행위엔터티(Active Entity)로 구분할 수 있다.
기본엔터티
기본엔터티란 그 업무에 원래 존재하는 정보로서 다른 엔터티와 관계에 의해 생성되지 않고 독립적으로 생성이 가능하고 자신은 타 엔터티의 부모의 역할을 하게 된다.
다른 엔터티로부터 주식별자를 상속받지 않고 자신의 고유한 주식별자를 가지게 된다.
예를 들어 사원, 부서, 고객, 상품, 자재 등이 기본엔터티가 될 수 있다.
중심엔터티
중심엔터티란 기본엔터티로부터 발생되고 그 업무에 있어서 중심적인 역할을 한다.
데이터의 양이 많이 발생되고 다른 엔터티와의 관계를 통해 많은 행위엔터티를 생성한다.
예를 들어 계약, 사고, 예금원장, 청구, 주문, 매출 등이 될 수 있다.
행위엔터티
행위엔터티는 두 개 이상의 부모엔터티로부터 발생되고 자주 내용이 바뀌거나 데이터량이 증가된다.
분석초기 단계에서는 잘 나타나지 않으며 상세 설계단계나 프로세스와 상관모델링을 진행하면서 도출될 수 있다.
예를 들어 주문목록, 사원변경이력 등이 포함된다.
5) 엔티티 명명규칙
가. 가능하면 현업업무에서 사용하는 용어를 사용한다.
나. 가능하면 약어를 사용하지 않는다.
다. 단수명사를 사용한다.
라. 모든 엔터티에서 유일하게 이름이 부여되어야 한다.
마. 엔터티 생성 의미대로 이름을 부여한다.
2. 속성( Attribute )
1) 속성의 개념
속성이란 사전적인 의미로는 사물(事物)의 성질, 특징 또는 본질적인 성질, 그것이 없다면 실체를 생각할 수 없는 것으로 정의할 수 있다.
데이터 모델링 관점에서 “업무에서 필요로 하는 인스턴스로 관리하고자 하는 의미상 더 이상 분리되지 않는 최소의 데이터 단위”로 정의할 수 있다.
2) 속성에 대한 정리와 표기법
가. 엔터티는 두 개 이상의 인스턴스가 존재한다.
나. 엔티티는 두 개 이상의 속성을 갖는다.
다. 한 개의 속성은 한 개의 속성값만 갖는다.
3) 속성의 특징
가. 엔터티와 마찬가지로 반드시 해당 업무에서 필요하고 관리하고자 하는 정보이어야 한다.
나. 정규화 이론에 근간하여 정해진 주식별자에 함수적 종속성을 가져야 한다.
다. 하나의 속성에는 한 개의 값만을 가진다. 하나의 속성에 여러 개의 값이 있는 다중값일 경우 별도의 엔터티를 이용하여 분리한다.
4) 속성의 분류
가. 속성의 특성에 따른 분류
나. 엔터티 구성방식에 따른 분류
속성은 이 두 방식으로 분류할 수 있다.
가. 속성의 특성에 따른 분류
속성은 업무분석을 통해 바로 정의한 기본속성(Basic Attribute),
원래 업무상 존재하지는 않지만 설계를 하면서 도출해내는 설계속성(Designed Attribute),
다른 속성으로부터 계산이나 변형이 되어 생성되는 파생속성(Derived Attribute)으로 분류할 수 있다.
기본속성
기본 속성은 업무로부터 추출한 모든 속성이 여기에 해당한다.
코드성 데이터, 엔터티를 식별하기 위해 부여된 일련번호, 그리고 다른 속성을 계산하거나 영향을 받아 생성된 속성을 제외한 모든 속성은 기본속성이다. 주의해야 할 것은 업무로부터 분석한 속성이라도 이미 업무상 코드로 정의한 속성이 많다는 것이다. 이러한 경우도 속성의 값이 원래 속성을 나타내지 못하므로 기본속성이 되지 않는다.
설계속성
설계속성은 업무상 필요한 데이터 이외에 데이터 모델링을 위해, 업무를 규칙화하기 위해 속성을 새로 만들거나 변형하여 정의하는 속성이다. 대개 코드성 속성은 원래 속성을 업무상 필요에 의해 변형하여 만든 설계속성이고 일련번호와 같은 속성은 단일(Unique)한 식별자를 부여하기 위해 모델 상에서 새로 정의하는 설계속성이다.
파생속성
파생속성은 다른 속성에 영향을 받아 발생하는 속성으로서 보통 계산된 값들이 이에 해당된다. 다른 속성에 영향을 받기 때문에 프로세스 설계 시 데이터 정합성을 유지하기 위해 유의해야 할 점이 많으며 가급적 파생속성을 적게 정의하는 것이 좋다.
나. 엔터티 구성방식에 따른 분류
엔터티를 식별할 수 있는 속성을 PK(Primary Key)속성,
다른 엔터티와의 관계에서 포함된 속성을 FK(Foreign Key)속성,
엔터티에 포함되어 있고 PK, FK에 포함되지 않은 속성을 일반속성이라 한다.
5) 도메인 ( Domain )
각 속성은 가질 수 있는 값의 범위가 있는데 이를 그 속성의 도메인(Domain)이라 한다.
예를 들면 학생이라는 엔터티가 있을 때 학점이라는 속성의 도메인은 0.0에서 4.0 사이의 실수 값이며,
주소라는 속성은 길이가 20자리 이내인 문자열로 정의할 수 있다.
각 속성은 도메인 이외의 값을 갖지 못한다.
이해하기 쉽게 정리하면, 엔터티 내에서 속성에 대한 데이터타입과 크기 그리고 제약사항을 지정하는 것이라 할 수 있다.
6) 속성의 명명규칙
가. 해당 업무에서 사용하는 이름을 부여한다.
나. 서술식 속성명은 사용하지 않는다.
다. 약어사용은 가급적 제한한다.
다. 전체 데이터모델에서 유일성을 확보하는 것이 좋다.
3. 관계 ( Relationship )
1) 관계의 정의
관계(Relationship)를 사전적으로 정의하면 상호 연관성이 있는 상태로 말할 수 있다.
데이터 모델에 대입하여 정의해 보면, “엔터티의 인스턴스 사이의 논리적인 연관성으로서 존재의 형태로서나 행위로서 서로에게 연관성이 부여된 상태”라고 할 수 있다.
2) 관계의 분류
관계는 두 가지로 나누어 분류할 수 있다.
가. 존재에 의한 관계
나. 행위에 의한 관계
최초의 ERD(Chen 모델)에서 관계는 속성을 가질 수 있었으나 요즘 ERD에서는 관계를 위해 속성을 도출하지는 않는다. 관계의 표현에는 이항 관계(Binary Relationship), 삼항 관계(Ternary Relationship), n항 관계가 존재할 수 있는데 실제에 있어서 삼항 관계 이상은 잘 나타나지 않는다.
3) 관계의 표기법
관계에서는 표기법이 상당히 복잡하고 여러 가지 의미를 가지고 있다.
다음 3가지 개념과 함께 표기법을 이해할 필요가 있다.
가. 관계명(Membership) : 관계의 이름
나. 관계차수(Cardinality) : 1:1, 1:M, M:N
다. 관계선택사양(Optionality) : 필수관계, 선택관계
가. 관계명
관계명은 엔터티가 관계에 참여하는 형태를 지칭한다.
각각의 관계는 두 개의 관계명을 가지고 있다.
또한 각각의 관계명에 의해 두 가지의 관점으로 표현될 수 있다.
나. 관계차수
두 개의 엔터티간 관계에서 참여자의 수를 표현하는 것을 관계차수(Cardinality)라고 한다.
가장 일반적인 관계차수 표현방법은 1:M, 1:1, M:N이다.
관계차수를 표시하는 방법은 여러 가지 방법이 있지만 Crow’s Foot 모델에서는 선을 이용하여 표현한다.
한 개가 참여하는 경우는 실선을 그대로 유지하고 다수가 참여한 경우는(Many) 까마귀발과 같은 모양으로 그려준다.
다. 관계선택사양
만약 지하철 문이 닫히지 않았는데 지하철이 떠난다면 무슨 일이 발생할까?
아마도 어떤 사람은 머리만 지하철 안에 들어오고 몸은 밖에 있는 채로 끌려갈 것이고,
또 어떤 사람은 가방만 지하철에 실어 보내는 사람도 있을 것이다.
물론 지하철운행과 지하철문의 관계는 이렇게 설계되지 않아 위와 같은 어처구니없는 일은 발생하지 않을 것이다.
“반드시 지하철의 문이 닫혀야만 지하철은 출발한다.”
지하철출발과 지하철문닫힘은 필수(Mandatory)적으로 연결 관계가 있는 것이다.
이와 같은 것이 데이터 모델의 관계에서는 필수참여관계(Mandatory)가 된다.
또 지하철 안내방송시스템의 예를 들어보자. 지하철의 출발을 알리는 안내방송은 지하철의 출발과 상관없이 방송해도 아무런 문제가 발생하지 않는다.
물론 정해진 시간에 방송을 하면 승객에게 정보로서 유익하겠지만 꼭 그렇게 할 필요는 없다.
이와 같이 지하철의 출발과 지하철방송과는 정보로서 관련은 있지만 서로가 필수적인(Mandatory) 관계는 아닌 선택적인 관계(Optional)가 되는 것이다.
필수참여는 참여하는 모든 참여자가 반드시 관계를 가지는, 타 엔터티의 참여자와 연결이 되어야 하는 관계이다.
선택참여된 항목은 물리속성에서 Foreign Key로 연결될 경우 Null을 허용할 수 있는 항목이 된다.
만약 선택참여로 지정해야 할 관계를 필수참여로 잘못 지정하면 애플리케이션에서 데이터가 발생할 때 반드시 한 개의 트랜잭션으로 제어해야 하는 제약사항이 발생한다.
그러므로 설계단계에서 필수참여와 선택참여는 개발시점에 업무 로직과 직접적으로 관련된 부분이므로 반드시 고려되어야 한다.
4) 관계를 읽는 방법
첫째. 기준(Source) 엔터티를 한 개(One) 또는 각(Each)으로 읽는다.
둘째. 대상(Target) 엔터티의 관계참여도 즉 개수(하나, 하나 이상)를 읽는다.
셋째. 관계선택사양과 관계명을 읽는다.
데이터 전문가 자격증 SQLD
1. 데이터모델링의 이해
1) 데이터 모델링의 이해
가. 엔티티
나. 속성
다. 관계
라. 식별자
마. 데이터 모델의 이해
중
가. 엔티티
나. 속성
다. 관계
를 데이터 전문가 지식포털 DBGuide.net 을 바탕으로 정리, 요약했습니다.
데이터 전문가 지식포털 DBGuide.net
엔터티 속성 관계 식별자 데이터 모델의 이해 1. 엔터티의 개념 데이터 모델을 이해할 때 가장 명확하게 이해해야 하는 개념 중에 하나가 바로 엔터티(Entity)이다. 이것은 우리말로 실체, 객체라��
www.dbguide.net
해당 사이트에서 더욱 전문적인 데이터 관련 지식을 다루고 있으니, 꼭 한 번 확인하시면 좋을 것 같습니다!
'DB > 기본 개념' 카테고리의 다른 글
| [SQL 기본 및 활용] SQL 기본 - 2 (0) | 2020.09.02 |
|---|---|
| [SQL 기본 및 활용] SQL 기본 - 1 (0) | 2020.09.01 |
| [데이터 모델링의 이해] 데이터 모델과 성능 - 2 (0) | 2020.09.01 |
| [데이터 모델링의 이해] 데이터 모델과 성능 - 1 (0) | 2020.08.31 |
| [데이터 모델링의 이해] 데이터 모델링의 이해 - 2 (0) | 2020.08.31 |