1

わかりました、私はSQLなどにまったく慣れていないので、これが完全に間違っている場合はお詫びします..

私は正しいと感じた ER モデルを設計しました。それをリレーショナル モデルに変換しようとしています。変換のどこが間違っているか、またはヒントについてアドバイスを求めています。私の頭を悩ませます。

私が信じているように..

1 対 1 の関係 エンティティが結合されるか、1 つのエンティティ タイプの主キーが他の関係の外部キーとして配置されます。

1-m 関係 「一側」の主キーは、多側に外部キーとして配置されます。

mn リレーションシップ 複合キーを形成する各エンティティのプライマリ キーを使用して、新しいリレーションが作成されます。

複数値属性 新しいテーブルが作成され、最初のテーブルから主キーが使用され、主キーに沿って 2 番目のテーブルで属性が使用されます。

では、リレーショナル モデルについて説明します。PK は太字、FK はイタリック体です。

ユーザー: ユーザー ID FNAME LNAMEユーザー名 パスワード ユーザータイプ Eメール

顧客: USERID、CUST_ID、BIO

管理者: ユーザー ID ADMIN_ID

アーティスト ユーザーID 、アーティスト_ID、バイオREC_ID

プロデューサー: PROD_ID、名前、電子メール

レコード ラベル: RECORD_ID、名前、説明

アルバム: ALBUMID NAME、COST、TITLE、NOOFSONGS

トラック: トラック ID、名前、コスト、タイトル、説明

TRACK REVIEW: TRACK に依存するので、TRACK ID はこのテーブルに入ります = REVIEW_ID(PK) , TRK_ID(PK) NAME

TRACK PURCHASE TABLE (USER id は外部キーとしてこのテーブルに入ります) TrackPuchaseID user_id , date

ALBUM PURCHASE TABLE AlbumPuchaseID user_id、日付、数量

ジャンル表?: わからない??

BPM: 複数の値の属性なので、別のテーブルになるので、それは GenreID BPMです。

私はこれがすべて間違っているかもしれないことを知っています。しかし、どんな助けも素晴らしいでしょう..FKまたは複合PKなどである必要がある説明、または欠落しているテーブル..

4

2 に答える 2

0
  • あなたalbum purchaseが持っている必要があります: user_id, date, album_id.
  • track purchaseなぜあなたが を気にかけているquantityのに を見逃しているtrack_idのかわかりません。
  • review、、、すべてtrackにalbumをuser含める必要がありますdate。 とに を追加するlast_update_dateのも興味深いかもしれません。artistcustomer
  • reviewを含める必要がありuser_idます。

他にも残っていると思います。「顧客 xyz がアイテム 1,2,3,4 を購入しました...」と言うことができるInvoice/テーブルが必要です。次のようになります。Invoice_Purchase

テーブルInvoice

  • 請求書ID
  • ユーザーID
  • 日にち
  • 状態

テーブルInvoice_Purchase

  • Invoice_id // 請求書の ID
  • purchase_type // 購入の種類 (たとえば、0 はトラック、1 はアルバムを意味します)

たぶん、statusあなたのalbunsとトラックにaを追加する必要があるかもしれません。これにより、アイテムを購入できるかどうかを設定できます. そして、はい、古い請求書が中継されているため、それらを削除しないでください...

とにかく、関係部分を描画してDBをデプロイするようなソフトウェアを後で使用することを検討する必要があります。Navicat

于 2015-01-23T08:36:36.253 に答える