Design Issues in E-R model

상위 문서: Entity Relationship Model

개요

엔터티 집합과 관계 집합의 개념은 명확하지 않으며, 엔터티들의 집합과 그들 사이의 관계를 여러 가지 다른 방식으로 정의하는 것이 가능하다. 따라서 해당 문서에서는 E-R database schema를 설계할 때 주의해야할 것들에 대해서 다룬다.

Common mistakes in E-R diagram

파일:Incorrect use of attribute.png

먼저 위 이미지는 관계(relationahip)를 통해서 표현해야 할 것을 속성(attribute)으로 표현한 대표적인 예시이다. 위에서는 어떤 엔티티의 primary key를 다른 entity의 속성으로 넣었는데 student와 department 사이에 stud_dept라는 명시적인 관계가 존재하기 때문에 문제가 된다. 만약 이를 해결하기 위해서 stud_dept 관계를 제거하면 redundancy 문제는 해결할 수 없으나, student와 department 사이의 관계가 implicit하게 되기 때문이다. 즉, student에 dept_name을 속성으로 사용하는 대신 student와 department 사이에 stud_dept라는 관계를 사용해야 한다.
비슷한 이유로, 관계 안에 엔티티의 primary key를 속성으로 넣는 것도 잘못이다. 그 이유는 관계에 참여(participating)하는 엔티티에는 primary key가 자동으로 포함되기 때문이다.

파일:Erroneous use of relationship attibutes.png

또한 위는 다중값 속성(multivalued attribute)이 필요한데 단일값(single-valued attribute)으로 모델링하는 오류를 보여준다. 위의 상황에서는 takes(student, section) 관계에서 학생이 과제별로 점수를 받으며, 이것이 assignment, marks라는 두 개의 단일 속성을 추가해서 표현되고 있다. 이는 각각의 section과 student 쌍의 관계당 단 하나의 과제 점수만 기록가능하므로, 과제가 여러 개인 경우에는 표현이 불가능하다는 단점이 있다. 이를 해결하는 두가지 방법이 존재한다.

파일:Correct alternative to erroneous E-R diagram.png

첫번째 방법은 위를 구현하기 위해 다음 두가지 항목을 추가한다.

• section에 의해 identified되는 weak entity set인 assignment
• student이 해결한 assignment entity에 대한 점수(mark)를 표시하는 decriptive attribute를 가지고 있는 marks_in 관계

이를 통해서 student가 어떤 department에 속하는 어떤 assignment를 해결하고, 어떤 점수를 받았는지를 redundancy없이 해결할 수 있다. 또한 이는 assignment에 대한 마감 기한과 같은 다른 정보를 속성으로 나타낼 수 있다는 점에서 더욱 좋은 해결 방법이다.

파일:Correct alternative to erroneous E-R diagram 2.png

두번째 방법은 위와 같이 stud_section이라는 복합 속성(composite attribute) 내에 다중값 속성을 추가하여 내부에 assignment와 marks 속성을 포함하는 것이다. 이를 통해서 student와 section 사이의 관계인 stud_section 내에 그 section에서 수행한 과제와 점수의 목록들을 하나의 복합 다중값 속성으로 저장할 수 있다. 이는 모델링이 간단하지만, assignment가 독립된 엔티티가 아니므로 마감 기한과 같은 세부 정보는 추가적으로 저장하기 어렵다는 단점이 있다.

Use of Entity Sets versus Attributes

위와 같이 instructor 엔터티 집합에 phone number라는 추가 속성이 있다고 가정해 보자. 여기서 phone은 그 자체로 entity라고 고려될 수 있다. 예를 들어, phone은 phone_number와 location이라는 속성을 가질 수 있다. 이러한 관점에서 보면, 우리는 instructor 엔터티에 phone number 속성을 추가하지 않고 위 이미지와 같이 표현하기 위해서 다음과 같은 구성을 만든다.

• phone_number와 location 속성을 가진 phone 엔터티 집합
• 강사와 그들이 가지고 있는 전화들 간의 연결을 나타내는 관계 집합 inst_phone

이때, 위 이미지의 (a)와 같이 전화번호를 속성 phone number로 처리한다는 것은 각 강사마다 정확히 하나의 전화번호를 가진다는 의미이다.
반면, 전화기를 엔터티 phone으로 처리하면 각 강사가 여러 개의 전화번호(또는 0개)를 가질 수 있게 된다. 따라서, 각각의 phone에 대해 mobile, IP phone, 유선 전화인지, 또는 여러 명이 함께 사용하는지 등의 정보를 담고자 한다면 phone을 엔터티로 표현하는 것이 더 일반적이고 유연하다. 하지만 name과 같은 속성은 그 자체로 독립적인 엔터티로 보기 어렵기 때문에 따라서 name은 instructor 엔터티 집합의 속성으로 표현하는 것이 적절하다.

Entities vs. Relationship sets

어떤 개체(object)가 엔터티 집합으로 표현되어야 할지, 관계 집합으로 표현되어야 할지는 명확하지 않다. student가 어떤 section에 대해 수강(take)를 하는 경우는, student와 section의 엔티티 집합 사이에 take라는 관계 집합을 설정할 수 있다.
하지만 다른 방법으로는 각 학생이 수강하는 각 과목에 대해 "수강 등록(course-registration) 기록" 이 존재한다고 상상할 수 있다. 이 경우, 우리는 각 수강 등록 기록을 하나의 엔터티로 보고, 이를 표현하는 엔터티 집합을 만든다. 이 엔터티 집합을 registration 이라고 부르자. 각 registration 엔터티는 정확히 하나의 학생 및 하나의 section과 연결되므로, 두 개의 관계 집합이 필요하다. 하나는 수강 등록 기록과 학생을 연결하는 관계, 다른 하나는 수강 등록 기록과 section을 연결하는 관계이다.

파일:Replacement of takes by registeration and two relationshipt sets.png

위 이미지는 section 및 student 엔터티 집합을 유지하면서, 기존의 takes 관계 집합을 엔터티 집합 하나와 관계 집합 두 개로 교체한 구조를 보여준다.

• registration: 수강 등록 기록을 나타내는 엔터티 집합
• section_reg: registration과 section을 연결하는 관계 집합
• student_regs: registration과 student를 연결하는 관계 집합

또한, 그림에서는 registration 엔터티가 두 관계 집합 모두에 전체 참여(total participation) 하는 것을 이중선(double lines) 으로 나타내고 있다.

Binary versus n-ary Relationship Sets

데이터베이스에서의 관계는 종종 이진(binary) 관계이다. 일부 관계는 비이진(nonbinary) 처럼 보이지만, 실제로는 여러 개의 이진 관계로 표현하는 것이 더 적절할 수 있다.
예를 들어, 자식(child)을 어머니(mother)와 아버지(father)에 연결하는 삼항(ternary) 관계 parent를 만들 수 있다. 하지만 이 관계는 자식과 어머니를 연결하는 mother 관계, 그리고 자식과 아버지를 연결하는 father 관계의 두 개의 이진 관계로도 표현될 수 있다. 그리고 이 경우, mother와 father라는 두 관계를 사용하는 경우, 아버지를 모르는 경우에도 어머니 정보를 기록할 수 있다.하지만 parent라는 삼항 관계를 사용할 경우, 아버지를 모르면 null 값이 필요하다. 따라서 이 경우에는 이진 관계를 사용하는 것이 더 바람직하다.

파일:Ternary relationship versus three binary relationships.png

사실, 모든 비이진(n > 2) 관계 집합은 여러 개의 이진 관계 집합으로 대체할 수 있다. 간단히, 추상적인 삼항(n = 3) 관계 집합 R 을 생각해 보자. 이 관계는 엔터티 집합 A, B, C를 연결한다. 이를 다음 과정을 통해 변환할 수 있다:

• R 관계 집합을 엔터티 집합 E 로 바꿉니다.
• 그리고 다음과 같은 3개의 이진 관계 집합을 만든다:
  • R_A: E → A (many-to-one)
  • R_B: E → B (many-to-one)
  • R_C: E → C (many-to-one)

이때, 엔터티 집합 E는 R_A, R_B, R_C 세 관계 모두에 전체 참여(total participation) 해야 한다. 만약 R 관계에 속성이 있다면, 그 속성들은 E 엔터티 집합의 속성으로 포함시킨다. 또한, E를 구성하는 개체들을 식별하기 위한 식별 속성(identifying attribute) 도 만든다.
그리고 R 안의 각 관계 ([math]\displaystyle{ a_i,\,b_i,\,c_i }[/math])에 대해, 새로운 엔터티 [math]\displaystyle{ e_i }[/math]를 E에 추가하고 다음과 같이 관계를 생성한다:

• [math]\displaystyle{ (e_i, a_i) \in R_A }[/math]
• [math]\displaystyle{ (e_i, b_i) \in R_B }[/math]
• [math]\displaystyle{ (e_i, c_i) \in R_C }[/math]

이러한 절차는 n진(n-ary) 관계 집합 전체에 대해 일반화할 수 있다. 즉, 개념적으로는 E-R 모델을 이진 관계만 포함하도록 제한할 수 있다는 뜻이다. 하지만, 이 제한이 항상 바람직한 것은 아니다. 그 이유는 다음과 같다.

• 관계 집합을 나타내기 위해 생성한 엔터티 집합에는 식별 속성이 필요하다. 이 속성과 추가적인 관계 집합들 때문에 설계가 복잡해지고, 저장 공간도 더 많이 필요하게 된다.
• n진 관계 집합은 여러 엔터티가 하나의 관계에 함께 참여함을 더 명확하게 보여준다.
• 어떤 제약 조건은 n진 관계에서는 표현 가능하지만, 변환된 이진 관계에서는 표현할 수 없는 경우도 있다.
  • 예: 관계 R이 A, B → C에 대해 다대일(many-to-one) 관계라고 가정하면,
    A와 B의 각각의 쌍이 최대 하나의 C 엔터티와만 관련될 수 있음
    하지만 이것은 R_A, R_B, R_C 각각의 이진 관계만으로는 표현할 수 없다.