ER Modeling

목차

• Conceptual Design과 ER Modeling
• Entity와 Attribute
• Entity Type과 key
• Relation이란
• Relation의 Constraint
• Recursive Relation
• Weak Entity Type
• Attributes on Relation
• Tenary Relation
• GuideLine for ER Modeling

---

Conceptual Design의 중요성

• 어떤 DBMS를 사용할지는 추후에 결정해도 된다. 하지만 어떤 DBMS를 선택하던 Conceptual Design은 바뀌지 않는다.
• 이러한 Conceptual Design을 위해서 ER modeling을 많이 사용한다.

---

Entity 와 Attribute

• Entity : 실제 세상에 존재하는 것을 의미한다.
  • ex) student, course
• Attribute : Entity를 표현하기 위한 성질들이다.
  • Simple Attribute : 엔티티가 가지는 하나의 atomic한 value. 즉, 해당 값 혼자서 엔티티의 특정 Attribute를 표현할 수 있다.
  • Composite Attribute : 여러 Attribute들이 모여서 나타나는 복합 Attribute를 의미한다.
  • Multi-valued Attribute : 엔티티가 해당 Attribute들에 대해 여러 값을 가질 수 있는 Attribute를 의미한다.
  • Complex Attribute : Composite + Multi-valued Attribute
  • Derived Attribute : 다른 특성들과의 연산에 의해 정의 되는 Attribute
  • Null Attribute : Attribute의 값들이 아직 정해지지 않았거나 존재하지 않는 특성을 의미한다.
• Attribute의 종류

---

Entity Type과 key

• Entity Type : 비슷한 엔티티들을 모아놓은 것이다.
• Key : Entity들을 Entity Type중에서 고유하게 식별하기 위한 Attribute의 집합이다. 따라서 이들은 서로가 구별되어야한다.

 

 

---

Relation이란?

Relation은 엔티티 타입들 간의 관계를 의미한다.

이러한 Relation을 비슷한 부류끼리 모아 놓은 것을 Relation Type이라고 한다.

이러한 관계에 속한 엔티티의 갯수에 따라 Degree가 결정이 되는데

• 1개 : Unary(Recursive) Relation
• 2개 : Binary
• 3개 : Tenary

라고 한다.

---

Relation의 Constraints

Relation Constraints란 엔티티들이 관계를 맺을 때의 제약사항을 의미하는데 이는 DBMS가 관리를 해준다.

👉 Mapping Contraints

• Relation에서 각각의 entity끼리 관계를 맺을 수 있는 갯수를 의미하는 Data constraints이다.

👉 Participation Constraints

해당 관계에서 엔티티들의 참여 여부를 정해주는 제약사항이다.

• Total : 모든 엔티티들이 관계에 참여해야한다는 것으로 해당 관계에 참여하지 않는 엔티티들은 존재하지 않는다.
• Partial : 관계에 엔티티들이 반드시 참여할 필요는 없는 관계를 의미한다.

Work-For : 사원들은 반드시 한개의 부서에 속해있다

Manage : 부서에는 관리자가 반드시 한명 존재하지만 모든 사원이 관리자는 아니다.

👉 (Min, Max) Constraints

관계에 참여하는 최소 및 최대 인원을 정해주는 제약사항이다.

즉, 특정 Relation이 M : N의 관계 에서 M이 최소 몇개 부터 최대 몇개까지 가능한지를 의미한다.

---

Recursive Relation

Relation에서 Degree가 1개인 Relation을 의미한다. 즉, Relation에서 사용하고 있는 Entity Type이 동일한 것을 의미한다.

ex)사람과 사람의 관계, 부품과 부품간의 관계 등..

---

Weak Entity Type

Entity 자체에서 Key를 가지고 있지 않는 엔티티를 의미한다.

이러한 엔티티들은 그들과 관계를 맺고 있는 owner entity type을 찾아야한다. 이때 Owner Entity Type은 항상 key를 가지고 있는 엔티티를 의미한다.

• Player은 선수번호랑 이름이라는 특성을 가지고 있지만 이름과 선수 번호가 모두 같은 선수들이 존재할 수 있다.
• 이들은 그들이 속한 Team으로 Key가 정의 될 수 있는 데 팀 내에서 팀 번호는 고유하기 때문이다.
• 따라서 Players는 Weak Entity Type으로 불리고 Play-On은 Weak Relation이라고 부른다.

이들은 다음과 같은 특징을 가지게 된다.

1. 관계는 항상 M : 1이다.
   • 왜 1 : 1은 되지 못할까?
     • 1 대 1인데 한 쪽이 Weak Entity Type이면 이들을 합치면 되지 굳이 나눠놓을 필요는 없기 때문이다.
   • 왜 M : N은 되지 못할 까?
     • Weak Entity의 Key는 Owner의 Key + Weak Entity의 Partial Key가 되는데 Owner의 Key가 고유하지 못하면 Key가 되지 못하기 때문이다.
2. Weak entity type은 항상 Total Participation이다.
   • 안 그러면 Key가 없는 상황이 생기기 때문이다.
3. Existence Dependency
   •  owner가 DB에서 삭제되면 이것과 관계를 맺고 있는 Weak Entity는 삭제되어야한다.

---

Attributes on Relation

Relation자체가 Attribute를 가질 수 있다.

→ 도서관 책과 학생은 대출이라는 관계를 가지는데 이들의 대출이라는 관계는 대출일과 반납일이라는 특성을 가질 수 있다.

• 주로 m : n의 관계를 가진다.
  • 위의 예시에서 쉽게 생각 할 수 있다.
• 1 : 1인 경우 해당 Attribute가 어느 Entity의 Attribute로 들어가든 상관 없다.
  • 연인이라는 관계에서 연애 시작 날짜는 어느 사람에게 속해든 상관이 없다.
• 1 : m 인 경우 m-side의 entity로만 이동해야한다.

해당 상황에서 관계의 특성은(Description)은 AcademicAdvisor입장에서도 RegStudent의 입장에서도 RegStudent의 Attibute로 변할 수는 있지만 AdademicAdvisor의 Attribute라고 이야기했을 때는 이를 구분하기 위한 RegStudentId가 추가되어야한다.

---

Ternary Relationships

관계를 형성 할때 2개 이상의 Entity가 필요할 수 있다.

ex)

Entities : employees, beers, cafes

Relation : Employees only drink certain beers at certain cafes

Q) Binary Relation을 여러개로 관계를 표현하면 안될까?

이를 표현하면 다음과 같은 3가지 의미로 표현이 된다.

• 직원들은 특정 맥주를 좋아한다
• 직원들은 특정 카페에 방문한다.
• 카페는 맥주를 판다.

이 3가지로 위의 관계를 모두 표현이 가능할까?

“직원은 특정 맥주를 좋아한다.” 라는 말은 직원들이 어디서나 맥주를 마신다는 것으로 해석 될 여지가 존재한다.

“직원은 특정 카페에 방문한다.” 라는 말은 직원들이 카페에 방문했다는 것 밖에 표현 못하고 그 안에서의 행동에 대해서는 해석의 여지가 존재하게 된다.

“카페는 맥주를 판다" 라는 말은 해당 맥주를 손님들이라는 더 큰 집단에 판다는 뜻으로 직원이라는 그룹보다는 크게 해석될 여지가 존재한다.

즉, Ternary Relation은 여러 조건이 서로 종속적이기 때문에 이를 제대로 표현하기 위해 존재하는 관계라고 생각하면 된다.

다음과 같이 표현했을 때는 이러한 정보들이 서로 종속적인것을 표현할 수 있기 때문에 관계에 들어가는 것을 확인 할 수 있다.

Ternary Relation을 만드는 것까지는 좋다. 그럼 DBMS가 이를 지원해야할 것이다. 하지만 잠깐 생각해보자. Binary까지는 당연히 지원하겠지만 그 이상은 어느정도까지 허용해야할까? 이들에 대한 처리 방식도 다양할텐데 말이다.

따라서 n-ary Relation은 여러개의 Binary Relation과 Weak Entity를 통해 표현하게 되는 것이 일반적이다.

다음 예시를 보자

Entity : Supplies, Project, Part

Relation : 어떤 공급자가 특정 프로젝를 위해 특정 부품을 공급한다.

이를 어떻게 종속적인 관계에서의 binary 관계로 표현이 가능할까?

답은 각각이 직접적인 관계를 맺는 것이 아니라 특정 Supply라는 Entity와 관계를 맺데 Supply라는 Weak Entity 로 만들고 이들이 각각의 Entity와 관계를 맺게하면된다.

이렇게 하면 Supply의 키는 특정 공급자, 특정 프로젝트, 특정 부품이라는 3가지 entity가 모여 정의가 되게 된다.

이렇게 되면 각각이 종속적이게 표현이 되게 되고 이에 따라 binary Relation으로 Ternary Relation이 표현이 가능하게 되는 것이다.

---

A Few ER Diagram Guidelines

1. 데이터의 중복을 피하라

ex)

위의 경우에 만약 학과 관련 정보를 수정하고 싶다면 관련 학과 학생들을 모두 찾아서 수정을 가해야한다. 따라서 데이터의 중복은 공간을 낭비시키고 수정을 어렵게 한다.

따라서 위의 구조는 다음과 같은 방법으로 표현하는게 더 적절할 것이다.

2. Entity의 attirbute가 key만 존재한다면 해당 entity와 관계를 맺는 다른 Entit로 귀속시켜라

다음과 같은 상황에서는 Dept를 우리가 따로 Entity로 나눌 필요는 없다. 그냥 아래와 같이 학생의 Attribute로 표현하는 것이 검색에 있어서 더 큰 이점을 가지게 될 것이다.

물론 Key가 바뀌는 경우는 드물 것이다. 하지만 만약 저렇게 따로 독립되어 존재하는 Entity의 key가 자주 바뀐다면? 난 개인적을 저렇게 두는 것이 좀 더 효율적이라는 생각이 들긴한다.

---

해당 내용은 성균관대학교 김응모 교수님 데이터 베이스 개론 수업을 듣고 정리한 것입니다.

---

긴 글 읽어주셔서 감사합니다.

 

틀린 부분이 있으면 댓글을 달아주시면 감사하겠습니다.

 

📧 : may3210@g.skku.edu

🔗 : https://github.com/RicardoKim