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>

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