あなたの図は、その用語の元の意味でのER図ではありません。エンティティ・リレーションシップ・モデルでは、リレーションシップはエンティティ・セット間の関連付けであり、表として実装されることを意図しています。たとえば、AUTHOR_BOOK
,CAST
およびPURCHASE
テーブルは、それぞれ2つのエンティティセットを関連付けるリレーションシップテーブルです(リレーションシップは2つのエンティティセットに限定されないことに注意してください)。エンティティセットのキーを使用して関係がどのように表されるかに注意してください。 (actorID, inventID)
。他の表の一部に同じパターンがあります((inventID, publisher)
、(inventID, director)
、(inventoryID, genre)
、(inventoryID, supplier)
、(receiptID, inventID)
、(receiptID, customerID)
)。これらはあなたの関係です - 外来のキー制約であるカラスの足の線ではありません。 Chenの元の表記法では、関係は2つのエンティティタイプ間でダイヤモンド形状を使用して示されます。また、Chenはこれらの関係ごとに別個の関係表(別名ジャンクション表)を作成していました。
テーブルの図は14のテーブルを示しています。
あなたのタイトルは、リレーショナルスキーマを参照:Chenの方法に従い、19個のテーブルが存在することになります。リレーショナル・スキーマは、エンティティー・リレーションシップ・モデルに限定されず、正規化された表(1NF以上)のセットを表すことができます。テーブルの数は、部分的に正規化のレベルに依存します。
しかし、関係の属性はありません。
これは正しくありません。 Purchase
の関係には、quantity
とamountPaid
の2つの属性が表示されます。 属性は、エンティティまたはリレーションシップから値のセットにマッピングされることに注意してください。したがって、私は関係の属性としてエンティティキーを数えていません。私はBook
とPublisher
の間の関係の属性としてBook
のpubYear
をモデル化しました。
実際には、すべての関係テーブルを個別に実装すると、リレーションシップカーディナリティが変更されたときにスキーマの変更が緩和されるという利点がありますが、元のダイアグラムに似た物理スキーマを与える同じ行列式を使用して非正規化することになります。
更新された完全な投稿からすべてのエンティティリレーションシップとリレーションシップリレーションシップを特定できますか?ありがとう! :) –
receipt_customerとinventory_genreのような関係のテーブルには、2つの接続エンティティの主キーが含まれます。 –
これは正しいです。 – reaanb