관계형 스키마는이 ER 다이어그램에 대해 몇 개의 테이블을 보유합니까?

Question

ER 다이어그램에는 다음과 같은 내용이 있습니다. 나는 아직도 DBMS를 배우고 있으며이 ER 다이어그램을 관계형 스키마로 변환하려고합니다. ER 다이어그램의 각 엔티티에는 별도의 테이블이 있다는 것을 알고 있습니다. 그러나이 ER 다이어그램의 관계에 대해 무엇을해야할지 모르겠습니다. 우리는 엔티티 들간의 각각의 관계에도 테이블이 있다는 말을 들었습니다. 따라서이 ER 다이어그램에서도 관계를 구분해야합니까? 그러나 관계의 속성이 없습니다. 또한, 나는 정확히 어떤 종류의 관계에 혼란을 겪고 있습니까? 이것은 하나입니까?

ER 다이어그램 그림에 링크를 첨부하고 있습니다. 저를 올바른 방향으로 인도하십시오. 감사!

Answer 1

다이어그램은 그 용어의 원래 의미에서 ER 다이어그램이 아닙니다. 엔티티 관계 모델에서 관계는 엔티티 세트 간의 연관이며 테이블로 구현되어야합니다. 예를 들어, AUTHOR_BOOK, CAST 및 PURCHASE 테이블은 각각 ​​두 개의 엔티티 세트를 연결하는 관계 테이블입니다 (관계는 두 개의 엔티티 세트로만 제한되지 않음을 명심하십시오). 관계가 엔티티 집합의 키를 사용하여 어떻게 표현되는지 주목하십시오. (actorID, inventID). 동일한 패턴이 다른 표에서 찾을 수 있습니다 (예 : (inventID, publisher), (inventID, director), (inventoryID, genre), (inventoryID, supplier), (receiptID, inventID) 및 (receiptID, customerID)). 이것들은 당신의 관계입니다. 까마귀의 풋 라인은 외래 키 제약 사항이 아닙니다. Chen의 원래 표기법에서 두 관계 유형 사이의 다이아몬드 모양을 사용하여 관계를 표시합니다. 또한 Chen은 이러한 각각의 관계에 대해 별도의 관계 테이블 (일명 접합 테이블)을 만들었을 것입니다.

테이블 도표는 14 개의 테이블을 보여줍니다.

귀하의 제목은 관계형 스키마를 참조 : 첸의 방법에 따라, 19 개 테이블이있을 것입니다. 관계형 스키마는 엔티티 관계 모델에 제한되지 않고 모든 정규화 된 테이블 세트 (1NF 이상)를 나타낼 수 있습니다. 테이블의 수는 부분적으로 정규화 수준에 달려 있습니다.

그러나 관계의 속성은 없습니다.

올바르지 않습니다. Purchase 관계는 두 가지 속성 (quantity 및 amountPaid)을 보여줍니다. 속성은 엔티티 또는 관계 세트의 값을으로 매핑하는 것입니다. 따라서 엔티티 키를 관계의 속성으로 간주하지 않습니다. 또한 Book과 Publisher 사이의 관계 특성으로 Book의 pubYear을 모델링했습니다.

실제적으로 모든 관계 테이블을 개별적으로 구현하면 관계 카디널리티가 변경 될 때 스키마 변경을 완화하는 데 약간의 이점이 있지만 원래의 다이어그램과 비슷한 실제 스키마를 제공하는 동일한 결정자와 관계를 비정규 화합니다.