[ DB ] 데이터베이스...2(ER Diagram)

본 포스팅은 인하대학교 최원익교수님의 "데이터베이스설계" 수업에서 진행한 프론트, 백엔드 실습 관련 정리하는 포스팅입니다. 백엔드, 프론트엔드는 전문 분야가 아니기에 공부용으로 올리는 포스팅이며 오류사항이 있을 수 있습니다.

 

https://jinwoo-jung.tistory.com/100

[ DB ] 데이터베이스...1

 

---

 

이번에는 주어진 요구사항 및 제약 조건에서 Entity, Attribute, Relationship을 판단하고 ER Diagram을 그리는 방법을 알아보자. 

 

• ER Diagram

ER Diagram은 Entity-Relationship Model을 표한하는 것으로, 데이터베이스 구조를 시각적으로 표현한 다이어그램이다. 이는 현실세계의 요구사항들을 기반으로 데이터베이스를 설계하는 과정에서 사용되며, 개체(Entity), 속성(Attribute), 관계(Relationship)로 구성된다.

 

 

다음과 같은 요구사항이 있다고 생각 해 보자.

 

• Entity
  • 실세계에서 독립적으로 존재하는 실체, 객체
  • Entity는 Attributes(속성)로 표현되며, 다른 Entity와 Relationship(관계)를 이룬다.

위 요구사항에서, Entity는 부서, 사원이 된다.

 

• Attribute
  • Entity를 설명하는 요소
  • Entity를 기술하는 속성

부서 Entity는 고유한 이름, 고유한 번호, 위치라는 Attribute를 가진다. 

 

이때, Key 개념이 등장한다. 추후 자세히 다룰 것이지만, 여기서는 Primary Key의 의미를 알아보자.

•  Primary Key
  • 테이블(릴레이션)에서 특정 튜플(행)을 유일하게 구별할 수 있는 Attribute

요구사항에서 이름, 번호 Attribute는 고유하다고 하였으므로 Primary Key가 되는 것이다.

 

Attribute는 하나의 Attribute는 하나의 값을 가지는 Single Value Attribute, 하나의 Attribute가 여러 값을 가지는 Multi-Valued Attribute로 나뉜다. 한 부서는 여러 위치에 있을 수 있으므로, 부서 Entity의 위치 Attribute는 Multi-Valued Attribute가 된다. 

 

• Relationship
  • Entity간의 관계를 표현

"각 부서마다 부서를 관리하는 특정 사원이 있다."라고 하였으므로 부서 Entity와 사원 Entity는 "관리"라는 Relationship이 존재한다. 

 

1번 요구사항을 만족하는 ER Diagram은 다음과 같다. Entity는 사각형, Relationship은 마름모, Attribute는 타원으로 표현되며, Multi-Valued Attribute는 이중 타원으로 표현된다. 이때, Primary Key의 경우 밑줄로 표현된다. Relationship의 세부사항은 추후 요구사항을 더 살펴보고 결정 해 보자.

 

 

두번째 요구사항에서는 프로젝트 Entity가 새롭게 등장한다. 프로젝트 Entity는 이름, 번호, 위치 Attribute를 가지며, 이름과 번호는 Primary Key 이다. 

 

---

부서 Entity와 프로젝트 Entity는 관리하는 Relationship을 가진다. 여기서 Relationship에 대해서 조금 더 알아보자.

 

Relationship은 2가지 제약조건이 명시된다.

 

1. Cardinality Ratio Constraint

• 관계를 가지는 두 Entity에 대하여 하나의 Entity가 얼마나 많은 다른 개체와 관련될 수 있는지

Cardinality Ratio Constraint는 1:1, 1:N, N:M 총 3가지 관계가 있다.

 

1:1

1:1 Relationship은 하나씩 관계를 가지는 것이다. 예를 들면, 남자와 여자의 결혼관계는 1:1이다. 

 

1:N

1:N Relationship은 관계를 가지는 두 Entity 중 한 쪽 엔티티가 다른 쪽 엔티티의 여러 객체를 가질 수 있음을 의미한다. 예를들어 부모와 자식의 Entity는 1:N이다. 부모는 자식을 1명만 낳을 수 있지만, 여러명 낳을 수 있다. 반대로, 하나의 자식이 여러명의 부모를 가진다는 것은 말이 안된다(Common Sense).

 

M:N 

M:N Relationship은 관계를 가진 양쪾 모두에서 1:N 관계가 존재함을 의미한다. 예를들어 손님과 상품의 관계는 M:N이다. 여러명의 손님이 하나의 상품을 가질 수 있으며, 하나의 손님이 여러개의 상품을 가질 수 있다. 

 

Cardinality Ratio Relationship은 Relationship과 Entity를 연결하는 선 위에 표현된다.

 

2. Participation Constraint

• 관계를 가지는 두 Entity에 대해 한 개체의 존재에 의존하는지 여부

Participation Constraint는 Total Participation, Partial Participation 2가지 관계가 있다.

 

학생 Entity와 수업 Entity를 생각 해 보자. 학생이 없다면 수업은 없다. 따라서 모든 수업은 학생과 관계를 맺어야 한다. 하지만, 학생이 모든 수업과 관계를 맺을 필요는 없다. 따라서 학생은 Partial Participation이지만, 수업은 Total Participation이다. Total Participation은 두 개의 실선으로, Partial Participation은 한 개의 실선으로 표현된다. 

---

 

요구사항에서 한 부서는 여러 프로젝트를 관리한다고 하였으므로, 1:N 관계이다. 또한, 프로젝트는 관리하는 부서가 없으면 안되므로 Total Participation 이지만, 모든 부서가 프로젝트를 관리할 필요는 없기에 부서는 Partial Participation이다. 

 

앞서 사원과 부서의 관리하는 관계를 정의 해 보면, 부서는 관리하는 사원이 없으면 안되므로 Total Participation이며, 모든 사원이 부서를 관리하지는 않기에 Partail Participation이다. 그리고 각 부서마다 부서를 관리하는 특정 사원이 있으므로 1:1 관계임을 유추할 수 있다. 

 

2번 요구사항을 만족하는 ER Diagram은 다음과 같다.

 

세번째 요구사항에서는 사원 Entity에 대한 Attributes가 등장한다. 이름, 사회보장번호, 조수, 급여, 성별, 생년월일을 Attribute로 가진다. 

 

또한, 사원과 부서에 대한 새로운 관계인 "속하다(WORKS_FOR)"가 등장한다. 한 사원은 한 부서에 속하므로 N:1의 관계를 가진다. 여러 사원이 한 부서에 들어갈 순 있으므로 1:1이 아닌 N:1이다. 또한, 사원이 없는 부서는 없으며 모든 사원은 부서에 속해 있으므로 둘 다 Total Participation이다.

 

한 사원은 여러 프로젝트 등레 관여할 수 있고, 한 사원이 관여하는 프로젝트들은 그 사원이 소속된 부서가 관리하는 프로젝트가 아니여도 무방하므로, 사원 Entity와 프로젝트 Entity는 또다른 관계를 가진다. 이는 M:N의 관계를 가지며, 둘 다 Total Participation임을 유추할 수 있다. 이때, 각 사원이 각 프로젝트를 위해 일하는 주당 근무 시간을 기록하므로, 사원과 프로젝트의 "WORKS_ON" 관계에서 해당 Attribute가 추가된다.

 

각 사원의 직속 상사 역시 사원이므로 재귀적 관계(Recursive Relationship)을 가진다. 이때, 각 사원에 대하여 여러명의 직속 상사가 존재할 수 있으므로, 1:N의 관계이다. 

 

3번 요구사항을 만족하는 ER Diagram은 다음과 같다. Recursive Relationship에 대한 ER Diagram을 잘 확인하고 넘어가자.

 

 

마지막으로 각 사원의 부양가족 Entity이다. 부양가족 Entity는 이름, 성별, 생년월일, 사원과의 관계를 Attribute로 한다. 하지만, 부양가족 Entity의 경우 사원이 없다면 존재하지 않기에 사원에 의존적이다. 이처럼 독자적으로 존재하지 못하고, 관계를 맺는 Entity에 의존적인 Entity를 Weak Entity라 한다. Weak Entity는 Primary Key를 가지지 않으며, 항상 Total Participation Constraint를 가진다. 이러한 Weak Entity와 Entity 관계를 나타내는 것을 Identifying Relationship이라 한다. 

 

 

4번 요구사항을 만족하는 ER Diagram은 다음과 같다. Identifying Relationship, Weak Entity는 2중으로 표현된다. 이때, Weak Entity는 Partial Key가 존재하는데, 이는 관계를 가지는 Entity와 결합해서 쓰일 때 자신의 Entity를 고유하게 식별 해 주는 Weak Entity의 Key를 의미한다. 부양 가족의 경우 동일한 이름을 가진다. 이때, 사원의 Primary Key인 Ssn과 결합해서 구분 가능하다.

 

Ex) 12345678의 부양 가족 김철수, 12631523의 부양 가족 김철수 

 

 

이게 ER Diagram의 정답인데, 하나 확인해야 할 점은 Department Entity의 Number_of_employees이다. 해당 Attribute의 경우 WORKS_FOR의 관계를 가지는 Employee의 수에 따라 결정된다. 이처럼, 실제 저장되어 있지 않으나, 다른 Attribute나 사실에 의해 그 값이 유도되는 Attribute를 Derived Attribute라 표현하며, 이는 점선으로 표현된다.