不確定我的ER圖與關系模型是否正確

Question

好吧，我是SQL的新手，所以如果這是完全錯誤的話，我深表歉意。

我設計了一個我認為正確的ER模型，並且試圖將其轉換為關系模型，並希望獲得有關我在轉換該模型時出錯的任何建議或任何提示。 絞盡腦汁。

我相信

1-1關系實體可以合並，也可以將一個實體類型的主鍵作為外鍵放置在另一個關系中。

1-m關系將“一側”中的主鍵作為多端中的外鍵放置。

mn關系創建一個新關系，每個實體的主鍵構成一個復合鍵。

多值屬性將創建一個新表，第一個表中使用的主鍵，第二個表中使用的屬性則是主表的主鍵。

所以這是我的關系模型，黑體字為PK，斜體字為FK

USER： USERID FNAME LNAME USERNAME密碼USERTYPE電子郵件

客戶： USERID ， CUST_ID ，BIO

ADMIN： USERID ADMIN_ID

ARTIST USERID ， ARTIST_ID ，BIO REC_ID

生產者 ： PROD_ID ，名稱，電子郵件

記錄標簽： RECORD_ID ，名稱，說明

專輯： 專輯名稱，費用，標題，NOOFSONGS

軌跡： 軌跡ID ，名稱，費用，標題，說明

軌跡審核 ：與軌跡有關，因此軌跡ID進入此表= REVIEW_ID（PK） ， TRK_ID（PK）名稱

跟蹤購買表（用戶ID作為外鍵進入此表） TrackPuchaseID user_id ，日期

專輯購買表AlbumPuchaseID user_id ，日期，數量

類型表：不確定嗎？

BPM：是多值屬性，所以因為它是單獨的表，所以它是GenreID BPM

我知道這一切可能都是錯誤的。 但是任何幫助都會很棒..解釋應該是FK還是復合PK等，或者我缺少什么表。

Answer 1

• album purchase您應該具有： user_id ， date ， album_id 。
• 在track purchase我看不到您為什么在乎quantity ，卻錯過了track_id 。
• review ， track ， album ， user都應包括一個date 。 向artist和customer添加last_update_date可能也很有趣。
• review應包含一個user_id 。

我想還有其他事情了。 您將需要一個Invoice / Invoice_Purchase表，以便能夠說“客戶xyz購買了1,2,3,4 ...”項目，它應該像這樣：

表格Invoice

• INVOICE_ID
• 用戶身份
• 日期
• 狀態

表Invoice_Purchase

• invoice_id //發票編號
• Purchase_type //購買類型（例如0表示曲目，1表示專輯）

也許您還應該將status添加到相冊和曲目，這樣您就可以設置是否可以購買商品。 是的，您不應該刪除它們，因為您會使用舊的發票...

無論如何，您應該稍后考慮使用類似Navicat的軟件來繪制關系部分並部署數據庫。

Answer 2

從初步看，這是我的一些印象，沒有特別的順序。

• 1-1關系：不僅在關聯表中將實體的PK定義為FK，而且還是關聯表的PK。 這保留了關系的統一性。
• 多值屬性：換句話說，是1-m關系。
• 沒有理由為客戶，管理員或藝術家使用單獨的ID值。 實際上，將它們全部稱為ID。 我想說這是一種m-1的關系，因為用戶既可以是客戶又可以是藝術家。 但是用戶表和其他用戶表之間的關系分別是1-1。
• 曲目與專輯無關嗎？ 那么AlbumID不會是Track屬性嗎？
• 購買表應具有CustID而不是UserID，並且對客戶表應為FK。 這就需要將購買者定義為客戶。
• 流派可以是曲目或專輯或兩者的屬性。 專輯通常可以是“國家/地區”，但具有“藍調”曲目，“流行”曲目等。
• 生產者也一樣。 會有唱片制作人，但也可能是其他人制作的一個或多個曲目。
• 藝術家也一樣。 整張專輯可能只有一位歌手，但是“ 1980年代最偉大的前40首流行歌曲”呢？
• 您可能需要Artist和Label之間的交集表。 一個標簽可以簽約許多藝術家，而一個藝術家可以為許多標簽工作（盡管通常不是同時）。
• 我不知道什么是BPM。

那應該讓你忙一陣子。