4

エンティティ関係図を SQL ステートメントに変換する前に、このモデルに、SQL データベース スキーマを作成したときに現れる不条理や異常が含まれていないかどうかを誰かに確認してもらえるかどうか尋ねてみようと思いました。

顧客と VIP の間の関係のカーディナリティについて特に確信が持てません。また、サプライヤーと CD の関係。VIP エンティティのstart_date - 弱いキーにする必要がありますか? Songエンティティのname属性以外に潜在的な弱いキーはありますか?

E/R モデル

伝説

  • 実在物ここに画像の説明を入力
  • 属性ここに画像の説明を入力
  • 弱い実体ここに画像の説明を入力
  • 関係ここに画像の説明を入力
  • 関係の特定ここに画像の説明を入力
  • カーディナリティ比ここに画像の説明を入力

図を作成するための参考として、次の Web サイトを使用しました。

  1. http://en.wikipedia.org/wiki/File:ERD_Representation.svg
  2. http://en.wikipedia.org/wiki/Entity-relationship_model
  3. http://www.cse.ohio-state.edu/~gurari/course/cse670/cse670Ch2.xht

図の作成に使用したソフトウェア: Dia (Linux)

4

1 に答える 1

1

申し訳ありませんが、これは遅い回答ですが、役立つ場合は、2 つの改善点があります。

1) 「VIP」と「CUSTOMER」の間の「is-a」関係は、スーパークラス (顧客) とサブクラス (vip) の存在を示します。VIP をサブクラスとしてモデル化したい場合があります。

2) 関係「家賃」の日付を追跡しているため、カーディナリティは「時間をかけて」取得する必要があります。したがって、両側のカーディナリティは「N」です (つまり、顧客側の「1」ではありません)。

マイナーな改善: "Song" (弱いエンティティ クラス) で、部分識別子を "name" ではなく "track" として設定します。これにより、同じ曲を 1 つの CD に複数録音することができます (たとえば、2 つのバージョン)。トラック番号は、CD 内で常に一意になります。

于 2012-08-26T02:32:28.870 に答える