需要关联表的多对多关系

Question

在许多数据库设计教程/文章中，他们总是提出这样一个事实，即如果两个表共享多对多关系，那么应该创建第三个表作为关联表来链接这两个。

然而 ，他们从未提供为什么我们应该这样做的原因。我很想知道 为什么 以及 可能出现的问题 的例子，如果您只保留两个表格它没有关联表。

Answer 1

使用关系数据库不能以任何其他方式建立多对多的关系。即，如果你有一个名为“person”的表，你就不能创建一个“朋友”列，并期望在那里放置许多朋友的用户ID。你必须创建一个单独的表来保存关系本身。

Answer 2

在关系数据库中，所有关系仅以一种方式表示：作为关系（关系对应于SQL中的表）。具有两个属性的关系，例如R {A，B}，表示A和B之间的二元关系。例如，该关系可以是一对多或多对多。

如果R {A，B}表示的关系是多对多，则意味着A或B都不是候选键（因为如果其中任何一个都是唯一的，那么显然只允许该属性的每个值有一个元组） ）。这意味着第三范式的原则要求依赖于A或B的任何属性进入其他表。原因是非密钥依赖（属于依赖于A或B的属性）是一种冗余形式，可能导致异常和不正确的结果。

所以并非“多对多关系”与其他关系的表现方式不同。只是标准化通常会导致一个常见的模式，其中包含复合键的表，而没有其他非键属性。有些人喜欢将该模式称为关联表 - 尽管我个人并不认为该术语非常有用。

Answer 3

如果你没有创建第三个表，那么就没有地方可以存储这些关系了。

使用一对一或一对多关系，您可以将关系存储在其中一个表中。通过多对多关系，您必须分别存储关系。 （好吧，理论上你可以将它作为逗号分隔的两个表中的身份列表存储，但这将是一个使用和维护的噩梦。）

Answer 4

维基百科也对此进行了描述。看看：http://en.wikipedia.org/wiki/Many-to-many_(data_model)

如果您仍然不相信多对多确实需要第三个表格，那么只需要使用两个规范化表格来检查作者/书籍（如维基百科文章中所述）。

Answer 5

如果DB-Server可以为您创建第3个表，那就不灵活了。如果有这样的解决方案，你就不会对

产生太大的影响

• 改变关系行为

• 在assoc中存储其他关联信息。表

• 性能增强

• 存储增强功能

Answer 6

让我们通过一个例子来理解它。如果您有两个桌子，一个桌子用于苹果，另一个桌子用于人，并且它们之间存在多对多关系；意味着一个人可以有多个苹果，一个人可以通过共享来吃一个苹果。

因此，如果我们在人员表的apple表中添加外键，则可以得出这样的关系：一个苹果可以被多个人食用，但是我们没有为另一种方法指定该关系。参见此表

类似地，如果我们在apple表中的person表中添加外键，则可以得出一个人可以吃多个苹果的关系，而另一个人不能同时吃它。请参阅此表

因此，这里是关联表。关联表用于两个对象之间的多对多关系。它们由至少2个外键组成，每个外键都引用两个对象之一，并且关联表中的主键至少由2个外键组成。见此表

参考： https://openclassrooms.com/en/courses/2071486-retrieve-data-using-sql/5758019-create-an-association-table