在许多数据库设计教程/文章中,他们总是提出这样一个事实,即如果两个表共享多对多关系,那么应该创建第三个表作为关联表来链接这两个。/ p>
然而 ,他们从未提供为什么我们应该这样做的原因。我很想知道 为什么 以及 可能出现的问题 的例子,如果您只保留两个表格它没有关联表。
答案 0 :(得分:2)
使用关系数据库不能以任何其他方式建立多对多的关系。即,如果你有一个名为“person”的表,你就不能创建一个“朋友”列,并期望在那里放置许多朋友的用户ID。你必须创建一个单独的表来保存关系本身。
答案 1 :(得分:2)
在关系数据库中,所有关系仅以一种方式表示:作为关系(关系对应于SQL中的表)。具有两个属性的关系,例如R {A,B},表示A和B之间的二元关系。例如,该关系可以是一对多或多对多。
如果R {A,B}表示的关系是多对多,则意味着A或B都不是候选键(因为如果其中任何一个都是唯一的,那么显然只允许该属性的每个值有一个元组) )。这意味着第三范式的原则要求依赖于A或B的任何属性进入其他表。原因是非密钥依赖(属于依赖于A或B的属性)是一种冗余形式,可能导致异常和不正确的结果。
所以并非“多对多关系”与其他关系的表现方式不同。只是标准化通常会导致一个常见的模式,其中包含复合键的表,而没有其他非键属性。有些人喜欢将该模式称为关联表 - 尽管我个人并不认为该术语非常有用。
答案 2 :(得分:0)
如果你没有创建第三个表,那么就没有地方可以存储这些关系了。
使用一对一或一对多关系,您可以将关系存储在其中一个表中。通过多对多关系,您必须分别存储关系。 (好吧,理论上你可以将它作为逗号分隔的两个表中的身份列表存储,但这将是一个使用和维护的噩梦。)
答案 3 :(得分:0)
维基百科也对此进行了描述。看看:http://en.wikipedia.org/wiki/Many-to-many_(data_model)
如果您仍然不相信多对多确实需要第三个表格,那么只需要使用两个规范化表格来检查作者/书籍(如维基百科文章中所述)。
答案 4 :(得分:0)
如果DB-Server可以为您创建第3个表,那就不灵活了。如果有这样的解决方案,你就不会对
产生太大的影响改变关系行为
在assoc中存储其他关联信息。表
性能增强
存储增强功能
答案 5 :(得分:0)
让我们通过一个例子来理解它。如果您有两个桌子,一个桌子用于苹果,另一个桌子用于人,并且它们之间存在多对多关系;意味着一个人可以有多个苹果,一个人可以通过共享来吃一个苹果。
因此,如果我们在人员表的apple表中添加外键,则可以得出这样的关系:一个苹果可以被多个人食用,但是我们没有为另一种方法指定该关系。参见此表
类似地,如果我们在apple表中的person表中添加外键,则可以得出一个人可以吃多个苹果的关系,而另一个人不能同时吃它。请参阅此表
因此,这里是关联表。关联表用于两个对象之间的多对多关系。它们由至少2个外键组成,每个外键都引用两个对象之一,并且关联表中的主键至少由2个外键组成。见此表