数据库实体关系表的名称，这是一个好主意吗？

Question

我不是数据库设计专家，我怀疑是一个新手问题。如果在其他论坛（或简单参考）中更好地回答，请告诉我。

给出表“录音”和表格“艺术家”。两个表都具有适当定义的主键。我们希望在这些表之间表达关系。也就是说，艺术家可以有很多录音，或者没有录音。录音只能有1或0位艺术家。 （我们可能会有一些不知名艺术家的模糊录音）。

我认为这个问题的解决方案是在录音表中有一个指向艺术家的外键。此字段可以为空（录制没有艺术家）。另外，我们应该定义级联删除，这样如果删除了一个艺术家，所有具有外国引用该艺术家的录音现在都具有null的外键。 [当你删除艺术家时，我真的想留下实际的录音。我们真正的桌子不是“艺术家”和“录音”，录音可以在没有艺术家的情况下存在]。

然而，这不是我的同事们如何设置的。 'Recordings'中没有外键列，而是带有两列的额外表'RecordingArtist_Mapping'，

RecordingKey ArtistKey

如果删除了Artist（或Recording），则删除此映射表中的相应条目。我并不是说这是错的，只是与我的预期不同。当一个人有很多关系时，我确实看到过这样的表，但不是我上面描述的关系。

所以，我的问题是：

1. 您是否听说过这种描述这种关系的方式？
2. 这种类型的桌子有名称吗？
3. 这是建立关系的好方法，还是我解释的外键概念会更好？每个人的利弊是什么？

我的同事指出，根据外键的想法，你可能在录音表中有很多空值，这违反了（可能只是在精神上？）关系数据库理论中的五种正态形式之一。我已经离开了我的联盟了:)这是否违反了其中一种形式？哪一个？怎么样？ （奖励积分简单参考“五种正常形式”:)）。

感谢您的帮助和指导。

戴夫

Answer 1

从表面上看，它只是一个允许两个其他表之间存在多对多关系的交集表。

如果您发现需要其中一种，通常最好考虑“这个表的意思是什么”，以及“我是否包含了所有相关属性”。

在这种情况下，表格会告诉您艺术家以某种方式为录音做出了贡献，然后您可能会考虑“贡献的本质是什么”。

可能他们演奏了一种特定的乐器或乐器。可能他们是指挥。

您可能会考虑艺术家以外的其他人是否为录音工作做出了贡献 - 音响工程师？因此，您可以考虑“艺术家”是否是一个很好的表格，因为您可能需要一个代表一般人的表格，然后您可以将它们中的任何一个与录音相关联。也许你甚至想记录一个非人的贡献 - 例如伦敦交响乐团。

你甚至可以拥有多种方式贡献的实体 - 吉他手，歌手和制作人？您还可以考虑是否应该对贡献进行排名，以便以正确的顺序列出（可能是合同问题）。

这正是对书面作品的贡献通常建模的方式 - 这里是书籍的ONIX元数据模式中使用的贡献者代码列表，作为一个说明性的行业示例：https://www.medra.org/stdoc/onix-codelist-17.htm

Answer 2

是的，这是一个可行的设置，这称为垂直分区。

基本上，您将artist字段从recording移到另一个表格，主键引用recording上的字段。

好处是你不一定要通过对录音进行查找来检索艺术家，缺点是如果你仍然需要，如果因为额外的连接会慢一点。

Answer 3

你在录音中使用外键的解决方案绝对正确，从规范化理论的角度来看，它不违反任何重要的正常形式（最重要的是第三范式，博伊斯 - 科德范式，并且都没有他们被侵犯了。）

此外，一个概念上更简单和安全的部分，从实际的角度来看它更有效，因为它通常会减少必须完成的连接数。在意见中，专业人士的利益大于利弊。

Answer 4

  

您是否听说过这种描述这种关系的方式？

是的，这是一对多关系。录音可以有多个艺术家。艺术家可以有多个录音。

  

这种类型的表有名称吗？

我称之为junction tables。

  

这是建立关系的好方法，还是我解释过的外键概念会更好？每个人的利弊是什么？

多对多关系中需要联结表。当你有一对多的关系时，你会在许多表中使用外键。

就第4级和第5级数据库规范化而言，1982年的这篇A Simple Guide to Five Normal Forms in Relational Database Theory文章解释了不同的层次。

  

在第四范式下，记录类型不应包含两个或多个关于实体的独立多值事实。

     

第五种正常形式处理的情况是，信息可以从较小的信息中重建，而这些信息可以通过较少的冗余来维护。

我记得这句话的前三个标准化水平。

  

我庄严地发誓，这些专栏依赖于钥匙，整个钥匙，只有钥匙，所以请帮助我Codd。