不确定我的关系模型的ER图是否正确

Question

好的，我是SQL等新手，所以如果这是完全错误的话，请道歉。

我设计了一个ER模型，我觉得这是正确的，我正在尝试将其转换为关系模型，并希望有任何关于我在转换它或任何提示时出错的建议。绞尽脑汁。

我相信..

1-1关系 实体可以组合使用，也可以将一个实体类型的主键作为外键放在另一个关系中。

1-m关系     来自“一边”的主要关键词被放在许多方面作为外键。

m-n关系     创建一个新关系，每个实体的主键形成一个复合键。

多值属性      创建一个新表，从第一个表使用的主键和在第二个表中使用的属性alognside主键。

所以，我的关系模型，粗体PK，斜体字FK

USER： USERID FNAME LNAME USERNAME密码USERTYPE电子邮件

CUSTOMER： USERID ， CUST_ID ，BIO

ADMIN： USERID ADMIN_ID

ARTIST USERID ， ARTIST_ID ，BIO REC_ID

PRODUCER： PROD_ID ，姓名，电子邮件

记录标签： RECORD_ID ，NAME，DESCRIPTION

ALBUM： ALBUMID NAME，COST，TITLE，NOOFSONGS

TRACK： 跟踪ID ，NAME，COST，TITLE，DESCRIPTION

TRACK REVIEW：TREND SO TRACK ID依赖于此表= REVIEW_ID（PK）， TRK_ID（PK） NAME

TRACK PURCHASE TABLE（USER id作为外键进入此表） TrackPuchaseID user_id ，日期

ALBUM PURCHASE TABLE AlbumPuchaseID user_id ，日期，数量

GENRE TABLE？： 不确定??

BPM：是多值的属性所以becoems分隔表所以它 GenreID BPM

我知道这一切都可能是错的。但任何帮助都会很棒..解释应该是FK或复合PK等，或者我缺少哪些表格。

Answer 1

• 在album purchase，您应该：user_id，date，album_id。
• track purchase我不明白为什么你关心quantity和track_id 您错过了review。
• track，album，user，date都应包含last_update_date。威力 将artist添加到customer也很有意思 和review。
• user_id应包含Invoice。

我猜还剩下其他的事了。您需要一个Invoice_Purchase / Invoice表来表示＆＃34;客户xyz购买了商品1,2,3,4 ......＆＃34;，它应该是这样的：

表Invoice_Purchase

• INVOICE_ID
• USER_ID
• 日期
• 状态

表status

• invoice_id //发票的ID
• purchase_type //购买的类型（例如，0表示曲目，1表示专辑）

也许您还应该在您的albuns和曲目中添加Navicat，这样您就可以设置是否可以购买商品。是的，你不应该删除它们，因为你将旧的发票转发给它......

无论如何，你应该考虑以后使用像{{1}}之类的软件来绘制关系部分并部署你的数据库。

Answer 2

从最初看，这是我的一些印象，没有特别的顺序。

• 1-1关系：不仅是相关表中定义为FK的实体的PK，它也是相关表的PK。这保持了关系的统一。
• 多值属性：换句话说，1米关系。
• 没有理由为Customer，Admin或Artist分别设置ID值。事实上，称他们为所有ID。我会说这是一种m-1关系，因为用户既可以是顾客，也可以是艺术家。但是User表和其他表之间的关系是1-1。
• Isn跟踪相册有关吗？那么AlbumID不是Track属性吗？
• 购买表应该具有CustID而不是UserID，并且FK为Customer表。这强制要求购买者被定义为客户。
• 流派可能是曲目或专辑或两者的属性。专辑通常可以是＃34; Country＆＃34;但是有一个＆＃34;蓝调＆＃34;跟踪，一个＆＃34; Pop＆＃34;跟踪等。
• 同样适合制片人。将有一个专辑制作人，但可能是由其他人制作的一首或多首曲目。
• 同样的艺术家。整张专辑可能只有一位艺术家，但是＃80; 1980年代最伟大的40首歌曲＆＃34;
• 您可能需要艺术家和标签之间的交叉表。标签可以注册许多艺术家，艺术家可以为许多标签工作（虽然通常不是同时）。
• 我不知道什么是BPM。

这应该会让你忙碌一段时间。