Design Issues in E-R model 문서 원본 보기

상위 문서: [[Entity Relationship Model]]

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

==Common mistakes in E-R diagram==
[[파일:Incorrect use of attribute.png|테두리|프레임없음|400x400픽셀]]

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

[[파일:Erroneous use of relationship attibutes.png|프레임없음|400x400픽셀]]

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

[[파일:Correct alternative to erroneous E-R diagram.png|테두리|프레임없음|500x500픽셀]]

첫번째 방법은 위를 구현하기 위해 다음 두가지 항목을 추가한다.
* 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|테두리|프레임없음|500x500픽셀]]

두번째 방법은 위와 같이 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<ref>location은 전화기가 위치한 사무실 또는 집일 수 있고, 휴대폰의 경우에는 "mobile"이라는 값으로 표현될 수 있다.</ref>이라는 속성을 가질 수 있다. 이러한 관점에서 보면, 우리는 instructor 엔터티에 phone number 속성을 추가하지 않고 위 이미지와 같이 표현하기 위해서 다음과 같은 구성을 만든다. 
* phone_number와 location 속성을 가진 phone 엔터티 집합
* 강사와 그들이 가지고 있는 전화들 간의 연결을 나타내는 관계 집합 inst_phone
이때, 위 이미지의 (a)와 같이 전화번호를 속성 phone number로 처리한다는 것은 각 강사마다 정확히 하나의 전화번호를 가진다는 의미이다.<ref>
다만, phone number를 다중값 속성으로 정의한다면, 강사 1인당 여러 개의 전화번호를 가지는 것도 가능하다.</ref> <br>
반면, 전화기를 엔터티 phone으로 처리하면 각 강사가 여러 개의 전화번호(또는 0개)를 가질 수 있게 된다.
따라서, 각각의 phone에 대해 mobile, IP phone, 유선 전화인지, 또는 여러 명이 함께 사용하는지 등의 정보를 담고자 한다면 phone을 엔터티로 표현하는 것이 더 일반적이고 유연하다. 하지만 name과 같은 속성은 그 자체로 독립적인 엔터티로 보기 어렵기 때문에 따라서 name은 instructor 엔터티 집합의 속성으로 표현하는 것이 적절하다.<ref>"무엇이 속성(attribute)이고, 무엇이 엔터티 집합(entity set)인가?"인지에 대한 질문에는 간단한 정답은 없다. 이러한 구분은 주로 모델링하려는 현실 세계(기업 등)의 구조와 해당 속성이 갖는 의미(semantics)에 의존하게 된다.</ref>

==Entities vs. Relationship sets==
어떤 개체(object)가 엔터티 집합으로 표현되어야 할지, 관계 집합으로 표현되어야 할지는 명확하지 않다. student가 어떤 section에 대해 수강(take)를 하는 경우는, student와 section의 엔티티 집합 사이에 take라는 관계 집합을 설정할 수 있다.<br> 
하지만 다른 방법으로는 각 학생이 수강하는 각 과목에 대해 "수강 등록(course-registration) 기록" 이 존재한다고 상상할 수 있다. 이 경우, 우리는 각 수강 등록 기록을 하나의 엔터티로 보고, 이를 표현하는 엔터티 집합을 만든다. 이 엔터티 집합을 registration 이라고 부르자. 각 registration 엔터티는 정확히 하나의 학생 및 하나의 section과 연결되므로, 두 개의 관계 집합이 필요하다. 하나는 수강 등록 기록과 학생을 연결하는 관계, 다른 하나는 수강 등록 기록과 section을 연결하는 관계이다.
 
[[파일:Replacement of takes by registeration and two relationshipt sets.png|테두리|프레임없음|500x500픽셀]] 

위 이미지는 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) 처럼 보이지만, 실제로는 여러 개의 이진 관계로 표현하는 것이 더 적절할 수 있다.<br>
예를 들어, 자식(child)을 어머니(mother)와 아버지(father)에 연결하는 삼항(ternary) 관계 parent를 만들 수 있다. 하지만 이 관계는 자식과 어머니를 연결하는 mother 관계, 그리고 자식과 아버지를 연결하는 father 관계의 두 개의 이진 관계로도 표현될 수 있다. 그리고 이 경우, mother와 father라는 두 관계를 사용하는 경우, 아버지를 모르는 경우에도 어머니 정보를 기록할 수 있다.하지만 parent라는 삼항 관계를 사용할 경우, 아버지를 모르면 null 값이 필요하다. 따라서 이 경우에는 이진 관계를 사용하는 것이 더 바람직하다. 

[[파일:Ternary relationship versus three binary relationships.png|테두리|프레임없음|400x400픽셀]] 

사실, 모든 비이진(n > 2) 관계 집합은 여러 개의 이진 관계 집합으로 대체할 수 있다. 간단히, 추상적인 삼항(n = 3) 관계 집합 R 을 생각해 보자. 이 관계는 엔터티 집합 A, B, C를 연결한다. 이를 다음 과정을 통해 변환할 수 있다:
* R 관계 집합을 엔터티 집합 E 로 바꿉니다.
* 그리고 다음과 같은 3개의 이진 관계 집합을 만든다:
** R<sub>A</sub>: E → A (many-to-one)
** R<sub>B</sub>: E → B (many-to-one)
** R<sub>C</sub>: E → C (many-to-one)
이때, 엔터티 집합 E는 R<sub>A</sub>, R<sub>B</sub>, R<sub>C</sub> 세 관계 모두에 전체 참여(total participation) 해야 한다. 만약 R 관계에 속성이 있다면, 그 속성들은 E 엔터티 집합의 속성으로 포함시킨다. 또한, E를 구성하는 개체들을 식별하기 위한 식별 속성(identifying attribute) 도 만든다. <br>
그리고 R 안의 각 관계 (<math>a_i,\,b_i,\,c_i</math>)에 대해, 새로운 엔터티 <math>e_i</math>를 E에 추가하고 다음과 같이 관계를 생성한다:
* <math>(e_i, a_i) \in R_A</math>
* <math>(e_i, b_i) \in R_B</math>
* <math>(e_i, c_i) \in R_C</math>

이러한 절차는 n진(n-ary) 관계 집합 전체에 대해 일반화할 수 있다. 즉, 개념적으로는 E-R 모델을 이진 관계만 포함하도록 제한할 수 있다는 뜻이다. 하지만, 이 제한이 항상 바람직한 것은 아니다. 그 이유는 다음과 같다.
* 관계 집합을 나타내기 위해 생성한 엔터티 집합에는 식별 속성이 필요하다. 이 속성과 추가적인 관계 집합들 때문에 설계가 복잡해지고, 저장 공간도 더 많이 필요하게 된다.
* n진 관계 집합은 여러 엔터티가 하나의 관계에 함께 참여함을 더 명확하게 보여준다.
* 어떤 제약 조건은 n진 관계에서는 표현 가능하지만, 변환된 이진 관계에서는 표현할 수 없는 경우도 있습니다.
** 예: 관계 R이 A, B → C에 대해 다대일(many-to-one) 관계라고 가정하면, <br>A와 B의 각각의 쌍이 최대 하나의 C 엔터티와만 관련될 수 있음<br>하지만 이것은 R<sub>A</sub>, R<sub>B</sub>, R<sub>C</sub> 각각의 이진 관계만으로는 표현할 수 없다.

==각주==
[[분류:데이터베이스 시스템]]