2016-05-31 9 views
0

ERダイアグラムには次のものがあります。私はまだDBMSを学んでおり、このER図をリレーショナルスキーマに変換しようとしています。私は、ER図の各エンティティに別々のテーブルがあることを知っています。しかし、私はこの特定のERダイアグラムの関係について何をすべきかはわかりません。エンティティ間のそれぞれの関係にもテーブルがあると言われました。したがって、このER図でも関係を別々にする必要がありますか?しかし、関係の属性はありません。また、これはまさにどのような関係にあるのか混乱していますか?これは1対1ですか?このER図のリレーショナルスキーマにはいくつのテーブルがありますか?

ERダイアグラムの画像にリンクを貼り付けています。私を正しい方向に導いてください。ありがとう! enter image description here

答えて

0

あなたの図は、その用語の元の意味での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のテーブルを示しています。

Inventory ER diagram

あなたのタイトルは、リレーショナルスキーマを参照:Chenの方法に従い、19個のテーブルが存在することになります。リレーショナル・スキーマは、エンティティー・リレーションシップ・モデルに限定されず、正規化された表(1NF以上)のセットを表すことができます。テーブルの数は、部分的に正規化のレベルに依存します。

しかし、関係の属性はありません。

これは正しくありません。 Purchaseの関係には、quantityamountPaidの2つの属性が表示されます。 属性は、エンティティまたはリレーションシップから値のセットにマッピングされることに注意してください。したがって、私は関係の属性としてエンティティキーを数えていません。私はBookPublisherの間の関係の属性としてBookpubYearをモデル化しました。

実際には、すべての関係テーブルを個別に実装すると、リレーションシップカーディナリティが変更されたときにスキーマの変更が緩和されるという利点がありますが、元のダイアグラムに似た物理スキーマを与える同じ行列式を使用して非正規化することになります。

+0

更新された完全な投稿からすべてのエンティティリレーションシップとリレーションシップリレーションシップを特定できますか?ありがとう! :) –

+0

receipt_customerとinventory_genreのような関係のテーブルには、2つの接続エンティティの主キーが含まれます。 –

+0

これは正しいです。 – reaanb

関連する問題