Design Issues in E-R model: 두 판 사이의 차이

youngwiki
새 문서: 상위 문서: Entity Relationship Model ==개요== ==각주== 분류:데이터베이스 시스템
 
편집 요약 없음
2번째 줄: 2번째 줄:


==개요==
==개요==
엔터티 집합과 관계 집합의 개념은 명확하지 않으며, 엔터티들의 집합과 그들 사이의 관계를 여러 가지 다른 방식으로 정의하는 것이 가능하다. 따라서 해당 문서에서는 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가 독립된 엔티티가 아니므로 마감 기한과 같은 세부 정보는 추가적으로 저장하기 어렵다는 단점이 있다.


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

2025년 3월 29일 (토) 15:58 판

상위 문서: Entity Relationship Model

개요

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

Common mistakes in E-R diagram

먼저 위 이미지는 관계(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가 자동으로 포함되기 때문이다.

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

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

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

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

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


각주