在我继续将实体关系图转换为SQL语句之前,我想我会问是否有人可以验证这个模型是否包含任何荒谬和异常,一旦我有SQL数据库模式就会出现。< / p>
我特别不确定客户与VIP之间关系的基数。此外,供应商和CD的关系。 VIP实体的 start_date - 它应该是弱密钥吗?除了歌曲实体的 name 属性之外还有其他潜在的弱键吗?
我使用以下网站作为参考来构建我的图表:
答案 0 :(得分:1)
对不起,这是一个迟到的答案,但如果它有用,你可以做两个改进。
1)“VIP”和“CUSTOMER”之间的“is-a”关系表示存在超类(客户)和子类(vip)。您可能希望将VIP建模为子类。
2)由于您要跟踪关系“租金”的日期,因此必须“随着时间的推移”采用基数。因此,双方的基数为“N”(即,客户方面不是“1”)
轻微改进:在“Song”(弱实体类)中将部分标识符设置为“track”而不是“name”;这将允许在CD上对同一首歌曲进行多次录制(例如,2个版本)。 CD中的曲目编号始终是唯一的