1
저는 Teisony, Simison 등이 저술 한 "Database Design"을 읽었습니다. 특정 시점에서 다중 값 속성이있는 엔티티를 관계형 테이블에 매핑하는 방법을 설명합니다. 다음 예는 다중 값 속성이 취미 인 경우입니다. 두 테이블다중 값 속성 표시
Employee(Employee_ID(PK),name,surname)
Hobby(Employee_ID(PK),hobby(PK))
책 엔티티 E 기본 키 p로 지정해, ER 다이어그램에 부착 된 다중 값 속성 E가 단에 매핑되는 "것을 다소 말한다 리드
Employee(Employee_ID(PK),name,surname,hobby)
p와 속성 값 (들) a "로 구성된 기본 키를 가진 자체 테이블. 이것은 일반적인 규칙입니까? 다음과 같은 다중 값 속성 책을 사용합니다.
Author(Author_ID(PK),name,book)
는이 책의 PK가 책의 PK의 일부가되어 가고 않고 단순히 Book_ID 및 author_id 값은 FK이다 인 follwing을 두 개의 테이블을 생성하기에 충분하지 않을까요?
Author(Author_ID(PK),name)
Book(Book_ID,book,Author_id(FK))
그러나 다른 직원이 같은 취미를 갖고 있다면 어떻게 될까요? 취미 이름 만이 PK로 사용되면 키가 중복 될 수 있습니다. 나는이 취미 예를 여기 다른 곳에서도 보았습니다. http://www.tomjewett.com/dbdesign/dbdesign.php?page=hobbies.php – tagomago
Teorey가이 문제를 다루는 방법에 대해서는 잘 모르겠지만 생각합니다. "다중 값 속성"과 "다 대다 관계"를 구별하는데 유용합니다. 또한 ER 모델링과 관계형 모델링을 구별하는 것이 유용하다고 생각합니다. 관계형 모델링에서 FK는 관계를 구현하는 수단입니다. ER 모델링에서 관계는 표시되지만 구현되지는 않습니다. –
@AlfioCastorina : 당신이 질문에 제기 한 2 테이블 구조에서 취미 이름을 기본 키로 사용할 수 없다는 것은 맞습니다. 다른 직원을 위해 반복 될 수 있기 때문입니다. 그러나 Book/Author 예제와 마찬가지로 Hobby_ID와 같은 기본 키 역할을하는 다른 필드를 도입 할 수 있습니다. 이것을 [대리 키] (http : //en.wikipedia.org/wiki/Surrogate_key), 유일한 목적은 취미를 유일하게 식별하는 것이다. 그것은 취미 자체에 관해 당신에게 아무것도 말하지 않습니다. –