不确定我的关系模型的 ER 图是否正确
Unsure if my ER Diagram to relational model is correct
好的，我是 SQL 等方面的新手，如果这完全错误，我深表歉意..
我设计了一个 ER 模型，我认为它是正确的，我正在尝试将其转换为关系模型，并希望得到任何关于我在转换它时出错的地方或任何提示的建议。绞尽脑汁。
我相信..
1-1 关系
实体要么合并，要么将一个实体类型的主键作为外键放置在另一个关系中。
1 米关系
来自“一侧”的主键作为外键放置在多侧。
m-n 关系
使用每个实体的主键创建一个新关系，形成一个复合键。
多值属性
创建了一个新的 table，从第一个 table 使用主键，在第二个 table alognside 主键中使用属性。
这是我的关系模型，PK 粗体，FK 斜体
用户：
USERID FNAME LNAME USERNAME PASSWORD USERTYPE EMAIL
客户：
USERID、CUST_ID、BIO
管理员：
用户 IDADMIN_ID
艺术家
USERID, ARTIST_ID, BIO REC_ID
制作人：
PROD_ID，姓名，电子邮件
唱片公司：
RECORD_ID , 名称, 描述
专辑：
专辑名称 名称、成本、标题、NOOFSONGS
跟踪：
轨道 ID、名称、成本、标题、描述
TRACK REVIEW：取决于 TRACK 所以 TRACK ID 进入此 table =
REVIEW_ID(PK), TRK_ID(PK) 姓名
TRACK PURCHASE TABLE（用户 ID 作为外键进入此 table）
TrackPuchaseID user_id, 日期
购买专辑 TABLE
AlbumPuchaseID user_id, 日期, 数量
类型 TABLE?:
不确定？？
BPM：是多值属性，所以变得独立 table 所以 it.s
流派 ID BPM
我知道这一切都可能是错误的。但任何帮助都会很棒.. 解释应该是 FK 或复合 PK 等或者我缺少什么 tables..
- 在
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 table 才能说 "customer xyz bought the items 1,2,3,4..."，它应该像：
Table Invoice
- invoice_id
- user_id
- 日期
- 状态
Table Invoice_Purchase
- invoice_id // 发票编号
- purchase_type // 购买类型（例如，0 表示曲目，1 表示专辑）
也许你还应该在你的相册和曲目中添加一个status，这样你就可以设置是否可以购买某个项目。是的，你不应该删除它们，因为你会在上面中继旧发票...
无论如何，你应该考虑以后使用像Navicat这样的软件来绘制关系部分并部署你的数据库。
这是我的一些初步印象，排名不分先后。
- 1-1关系：不仅是实体的PK在相关table中定义为FK，也是相关table的PK。这保持了关系的统一性。
- 多值属性：换句话说，1-m 关系。
- 没有理由为客户、管理员或艺术家设置单独的 ID 值。事实上，称它们为 ID。我会说这是一个 m-1 关系，因为用户可以既是客户又是艺术家。但是用户 table 和其他人的关系是 1-1.
- 曲目与专辑无关吗？那么AlbumID不就是一个Track属性吗？
- 采购 tables 应该有 CustID 而不是 UserID 并且 FK 给客户 table。这强制要求将购买者定义为客户。
- 流派可以是曲目或专辑或两者的属性。一张专辑通常可以 "Country" 但有 "Blues" 曲目、"Pop" 曲目等
- 制作人也一样。会有专辑制作人，但可能会有其他人制作的一首或多首曲目。
- 艺术家也一样。整张专辑可能只有一位艺术家，但 "The Greatest Top 40 Hits of the 1980s" 呢？
- 您可能需要艺术家和标签之间的交集 table。一个厂牌可以签约很多艺人，一个艺人可以为很多厂牌工作（虽然通常不会同时工作）。
- 我不知道 BPM 是什么。
那应该让你忙一阵子了。
好的，我是 SQL 等方面的新手，如果这完全错误，我深表歉意..
我设计了一个 ER 模型，我认为它是正确的，我正在尝试将其转换为关系模型，并希望得到任何关于我在转换它时出错的地方或任何提示的建议。绞尽脑汁。
我相信..
1-1 关系 实体要么合并，要么将一个实体类型的主键作为外键放置在另一个关系中。
1 米关系 来自“一侧”的主键作为外键放置在多侧。
m-n 关系 使用每个实体的主键创建一个新关系，形成一个复合键。
多值属性 创建了一个新的 table，从第一个 table 使用主键，在第二个 table alognside 主键中使用属性。
这是我的关系模型，PK 粗体，FK 斜体
用户： USERID FNAME LNAME USERNAME PASSWORD USERTYPE EMAIL
客户： USERID、CUST_ID、BIO
管理员： 用户 IDADMIN_ID
艺术家 USERID, ARTIST_ID, BIO REC_ID
制作人： PROD_ID，姓名，电子邮件
唱片公司： RECORD_ID , 名称, 描述
专辑： 专辑名称 名称、成本、标题、NOOFSONGS
跟踪： 轨道 ID、名称、成本、标题、描述
TRACK REVIEW：取决于 TRACK 所以 TRACK ID 进入此 table = REVIEW_ID(PK), TRK_ID(PK) 姓名
TRACK PURCHASE TABLE（用户 ID 作为外键进入此 table） TrackPuchaseID user_id, 日期
购买专辑 TABLE AlbumPuchaseID user_id, 日期, 数量
类型 TABLE?: 不确定？？
BPM：是多值属性，所以变得独立 table 所以 it.s 流派 ID BPM
我知道这一切都可能是错误的。但任何帮助都会很棒.. 解释应该是 FK 或复合 PK 等或者我缺少什么 tables..
- 在
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 table 才能说 "customer xyz bought the items 1,2,3,4..."，它应该像：
Table Invoice
- invoice_id
- user_id
- 日期
- 状态
Table Invoice_Purchase
- invoice_id // 发票编号
- purchase_type // 购买类型（例如，0 表示曲目，1 表示专辑）
也许你还应该在你的相册和曲目中添加一个status，这样你就可以设置是否可以购买某个项目。是的，你不应该删除它们，因为你会在上面中继旧发票...
无论如何，你应该考虑以后使用像Navicat这样的软件来绘制关系部分并部署你的数据库。
这是我的一些初步印象，排名不分先后。
- 1-1关系：不仅是实体的PK在相关table中定义为FK，也是相关table的PK。这保持了关系的统一性。
- 多值属性：换句话说，1-m 关系。
- 没有理由为客户、管理员或艺术家设置单独的 ID 值。事实上，称它们为 ID。我会说这是一个 m-1 关系，因为用户可以既是客户又是艺术家。但是用户 table 和其他人的关系是 1-1.
- 曲目与专辑无关吗？那么AlbumID不就是一个Track属性吗？
- 采购 tables 应该有 CustID 而不是 UserID 并且 FK 给客户 table。这强制要求将购买者定义为客户。
- 流派可以是曲目或专辑或两者的属性。一张专辑通常可以 "Country" 但有 "Blues" 曲目、"Pop" 曲目等
- 制作人也一样。会有专辑制作人，但可能会有其他人制作的一首或多首曲目。
- 艺术家也一样。整张专辑可能只有一位艺术家，但 "The Greatest Top 40 Hits of the 1980s" 呢？
- 您可能需要艺术家和标签之间的交集 table。一个厂牌可以签约很多艺人，一个艺人可以为很多厂牌工作（虽然通常不会同时工作）。
- 我不知道 BPM 是什么。
那应该让你忙一阵子了。