저번 포스팅에 이어 이번엔, Modeling Data in the Organization에 대해 알아본다.
목차는 다음과 같다.
목차
1. Entity-Relationship Model
2. Entity Type, Relationship type, and attribute
3. Degree, Cardinality Constraint and Participation Constraint
4. Weak Entity Type
Modeling Data in the Organization
Entity-Relationship Model
Conceptual Data Modeling에서는 Entity-Relationship Model을 만드는 과정을 포함한다. 즉, Entity-Relationship Model은 Conceptual Data Modeling을 위한 지배적인 도구로 남아 있다. 사용자 요구사항에 따라 데이터베이스의 내용을 정의하는 것이다. 예를 들어 데이터, 데이터 속성 및 데이터 간 관계를 모델링한다.
ER Model은 비교적 사용하기 쉽고 이해하기 쉽다.
ER Model은 데이터베이스 애플리케이션을 모델링하는 데 효과적인 도구이며, 실제와 이론에서 증명되었다.
Entity Type, Relationship Type, Attribute
그렇다면, 이 ER Model은 누가 만든 것인가? Dr. Peter Chen에 의해 ER Model은 개발되었다.
ER Model은 총 3가지 구성요소를 포함한다. Entity Type, Relationship Type, Attributes이다.
ER Model에 대한 단일 표준 표기법은 없지만, Dr. Peter Chen이 개발한 고전적 표기법을 따른다.
ER Model에서는 Entity들을 모델링하는 것이 아니라, Entity Types들을 모델링한다.
이 두가지 차이점에 대해서 알아본다.
-> Entity란 무엇일까? Entity란 조직이 데이터를 유지하고자 하는 실세계의 사물을 의미한다. 예를 들어 김정우, 티스토리, 초콜릿 같은 것들이다.
-> Entity Type이란 무엇일까? 공통 속성 또는 특성을 공유하는 Entity의 모음이다. 예를 들어 학생, 블로그, 음식 같은 것들이다.
Entity Type을 이름짓는 규칙에는 다음과 같은 것들이 있다.
단수명사를 사용, 특정하게, 간결하게, 고유하게 표현한다.
ER Model에서는 위와 마찬가지로 Relationship을 모델링하는 것이 아니라, Relationship Type을 모델링한다.
이 두가지 차이점에 대해서 알아본다.
-> Relationship이란 무엇일까? Entity Type간의 상호작용을 나타내는 연관성을 의미한다. 예를 들어 김정우가 티스토리를 이용한다가 될 수 있다.
-> Relationship Type이란 무엇일까? 공통특성 또는 특성을 공유하는 관계의 모음이다. 예를 들어, 학생이 블로그를 이용한다가 될 수 있다.
ER Model에서 3번째 구성요소인 Attribute에 대해서 알아본다.
Attribute란 조직이 관심있어 하는 Entity Type 또는 Relationship Type의 속성 또는 특성을 의미한다.
Attribute는 Field 혹은 Column으로 불리기도 한다. 예를 들어 Student_Id, Student_Name과 같은 것들이 될 수 있다.
속성에도 이름을 짓는 규칙이 있다. 단수명사, 동일한 Entity Type의 두 속성이 동일한 이름을 갖지 않아야 하고, ER Model에서 동일한 이름을 가진 두 속성은 없는 것이 바람직하다는 규칙이다.
그렇다면, Entity Type, Relationship Type, Attribute는 그림으로 어떻게 표현할까?
위와 같이 표현할 수 있다. Entity Type 은 네모로, Relationship Type은 마름모, Attribute는 동그라미로 표현한다.
속성에는 여러가지로 표현할 수 있는데 먼저 Simple Attribute와 Composite Attribute이다.
Simple Attribute란 조직에 의미 있는 작은 구성요소로 나눌 수 없는 속성을 의미하고, Composite Attribute란 의미있는 구성요소를 갖는 속성, 즉 여러 개의 Simple Attribute를 갖는 것을 의미한다.
예를 들자면, 다음 그림과 같다.
위의 그림을 보면 알 수 있듯, Major는 Simple Attribute이고, Student_name은 Student_fname, Student_mname, Student_lname으로 이루어져 있으므로 Composite Attribute이다.
또한, 속성은 Single-valued Attribute, Multi-valued Attribute로 나뉜다. Single-valued Attribute란 객체에 대해 하나의 값을 갖는 속성이고, Multi-valued Attribute는 둘 이상의 값을 사용할 수 있는 속성을 의미한다. 그림을 통해 알아본다.
Major는 Multi-valued Attribute이고, Student_ID는 Single-valued Attribute이면서 Simple Attribute이다. Major는 전공이 융합소프트웨어학부, 경영학과를 갖는 복수전공학생일 경우에 사용될 수 있다.
Attribute는 또한 Identifier Attribute라는 개념을 가질 수 있다. 이는 각 Entity Type간의 값이 구별되는 Attribute를 의미하는데, 예를 들어 학생id, 주민등록번호와 같은 것들이 될 수 있다. 표기법은 다음과 같다.
ER Modeling을 진행하는 과정을 간략히 설명하자면 다음과 같다.
Entity Type들을 식별하고, Entity Type사이에 Relationship Type을 식별하며 Entity Type과 Relationship Type에 대한 Attribute를 식별한다. 마지막으로 각각의 Entity Type에 대한 Identifier Attribute를 식별한다.
Degree, Cardinality Constraint and Participation Constraint
다음으로 Relationship Type에 사용되는 Degree에 대해서 알아본다. Degree란 Relationship Type에 참여하는 Entity Type의 수를 의미한다. 예를 들어, Degree가 one이라면, Unary Relationship Type은 다음과 같은 경우가 될 수 있다.
하나의 Entity Type인 직원이, 감독한다라는 Relationship Type에 참여할 경우이다.
Degree가 Two라면, Binary Relationship Type은 다음과 같은 경우가 될 수 있다.
예를 들어, Customer, Book이라는 Entity Type이 Relationship Type에 참여할 경우이다.
Degree가 Three라면, Tenary Relationship Type은 다음과 같은 경우가 될 수 있다.
Entity Type인 Customer, Book, Cashier가 Relationship Type인 구매한다에 참여하는 경우이다.
다음으로, Cardinality Contraint에 대해 알아본다. Cardinality Constraint란 관계를 맺는 두 Entity Type에 대해 한 개체가 얼마나 많은 다른 개체와 관련될 수 있는지를 나타내는 제약조건이다.
예를 들어, One-to-One Relationship이라면,
하나의 faculty는 하나의 office를 가질 수 있다고 표현할 수 있다.
다음으로, One-to-Many Relationship에 대해 알아본다.
하나의 팀은 많은 선수들로 구성되어 있고, 선수는 한 팀에서만 뛰는 경우에 다음과 같이 표현한다.
M과 1이 어디쪽에 있는지 주의해야 한다.
다음으로, Many-to-Many Relationship에 대해 알아본다.
한명의 학생은 많은 프로젝트를 가질 수 있고, 하나의 프로젝트는 많은 학생들을 가질 수 있을 때 다음과 같이 표현한다.
다음으로, Participation Constraint에 대해 알아본다.
Participation Constraint은 참여제약 조건으로, Entity Type이 관계를 통해 다른 Entity Type에 의존하는 지 여부를 명시하는 것이다.
Participation Constraint는 Total Participation과 Partial Participation이 있다.
-> Total Participation은 A의 모든 객체는 관계를 통해 B의 객체와 연결되어야 하는 것이다.
-> Partial Participation은 반드시 B의 모든 객체는 관계를 통해 A와 연결되어야 하는 것은 아니다.
예를 통해 알아보자.
모든 직원이 반드시 부서에서 일해야만 하고, 만약 새로생긴 부서라면, 직원이 전혀 없을 수 있는데 이는 위의 그림과 같이 표현할 수 있다.
모든 직원이 부서를 관리하는 것은 아니지만, 모든 부서에는 관리자가 있어야 하는 경우 위의 그림과 같이 표현할 수 있다.
다음으로, Weak Entity Type에 대해 알아본다.
이는 Identifier Attribute가 없는 Entity Type이다.
그렇다면 Weak Entity Type은 어떻게 식별될까? -> Weak Entity Type은 다른 Entity Type, 즉 Identifier Owner라고 불리는 Entity Type을 통해 식별된다.
Identifying Relationship Type은 Weak Entity Type과 그것의 Owner들의 관계를 의미한다.
-> Weak Entity Type은 항상 Total Participation을 갖지만, 강한 Entity Type은 항상 Total Participation을 갖지 않을 수 있다.
-> Weak Entity Type은 일반적으로 Partial Key를 갖는데, 이는 Identifying Owner Entity와 관련된 Weak Entity를 고유하게 식별할 수 있는 속성 또는 속성들의 조합이다.
표기법을 예를 통해 알아본다.
Order -> Identifying Owner
OrderID -> Identifier Attribute
Contains -> Identifying Relationship Type
Order_line -> Weak Entity Type
LineID -> Partial Key
이번 포스팅에서는 ER Model에 대해 알아보았다. 다음 포스팅에는 ER Model의 향상된 버전인 Enhanced ER Model에 대해서 알아본다.
'Dev > Database' 카테고리의 다른 글
[Database] 5. Physical Database Design (0) | 2022.02.25 |
---|---|
[Database] 4-2. Logical Database Design (0) | 2022.01.30 |
[Database] 4-1. Logical Database Design (0) | 2022.01.26 |
[Database] 3. The Enhanced E-R Model (0) | 2022.01.25 |
[Database] 1. The Database Environment and Development Process (0) | 2022.01.23 |