在谈论关系数据库时，似乎大多数人都提到了主要和外键的关系＆＃39;作为关系数据库的原因＆＃39;术语。
这引起了我相当大的困惑，因为下面链接的教科书明确规定了＃34;一个常见的误解是名称＆＃34;关系＆＃34;与表之间的关系（即外键）有关。实际上，模型名称的真正来源是数学概念关系。关系模型中的关系就是SQL调用表格。＆＃34;
此外，下一个源明确地将表称为关系而不是主键/外键。 https://docs.oracle.com/javase/tutorial/jdbc/overview/database.html
然而，在我看来或读到的其他任何地方，似乎是常识，主键和外键是关系。
有没有人有不一致的原因？
答案 0 :(得分：2)
外键约束是一种关系 - 子集关系 - 但这些关系不是模型从中得出其名称的关系。相反，关系模型的关系指的是有限的关系。 Ted Codd在他1970年的论文A Relational Model of Data for Large Shared Data Banks中写道，＆＃34;术语关系在这里被用于其公认的数学意义上。给定集合S1，S2，... Sn（不一定是不同的），如果它是一组n元组，则R是这些n个集合的关系，每个n元组的第一个元素来自S1，它的第二个元素来自S2，并且等等。＆＃34;因此，他正在描述一个可以用表格表示的结构，如果我们遵循一些规则，比如忽略重复的行和行的顺序（毕竟它是一组）。
另一个常见的误解是外键约束表示实体之间的关系。他们没有。关系表示为关联值行的集合/表。两个或多个实体的密钥将连续记录在一起，无论它是否在＆＃34;实体表中＆＃34;或者是一个关系表＆＃34;。外键约束仅强制完整性，它们不链接实体或表。表可以在任何谓词函数上连接，外键约束在这里不起作用。
大多数人从博客，教程和按受欢迎程度排名的答案中学习数据库概念。大多数人从来没有读过一本体面的数据库书，更不用说发明者和学生关于数据关系模型的论文了。大多数程序员和公司希望将产品发布，并且没有时间或对逻辑，理论和哲学的欣赏。这是一个内在复杂的领域 - 请参阅Bill Kent的书Data and Reality，了解这种复杂性。因此，你在互联网上发现的大部分内容都是半真半假的，因为人们试图理解一个困难的话题。
人们熟悉记录和指针，因为它们在主流编程语言中很流行，而且它们看起来和听起来很像实体和关系。如果实体由表/记录表示，按字段/列表示属性，那么实体之间的1对1/1对多关系必须是记录/表之间的关联，对吗？这是一个简单的想法，这使得很难纠正。对象/关系映射和面向对象领域模型的流行源于这个简单的想法（来自口头和社交作者，与一些关系支持者的态度不同），但也进一步巩固了它。
Peter Chen（The Entity-Relationship Model - Toward a Unified View of Data的作者做出了一些努力，要求严格，区分和实体关系以及关系关系＆＃34;在他看来，实体是真实世界的概念，它们在数据库中表示为值，并通过行中值的关联来描述。实体之间的关系类似地通过行中值的关联来表示.ER模型在关系和属性之间的区别有点多余（属性只是二元关系）并且在将实体元组与关系元组区分开来方面没什么好处。事实上，我认为它有助于加强混淆。它与旧网络模型的表面相似性有助于其采用但也有助于维护后者，因为开发人员在保持旧习惯的同时采用了新的术语。
对象角色建模（又名NIAM，Sjir Nijssen和Terry Halpin）消除了属性，并侧重于域，角色和关系。它比ER更优雅，更接近真正的关系模型，但它的优势（逻辑的，全面的，远离网络模型）也是它的弱点（学习曲线，更复杂的图表，更不适合作为车辆）熟悉的技术）。
Ted Codd在上面提到的论文中评论说＆＃34;另一方面，网络模型已经产生了许多混淆，其中最重要的是错误地推导出用于推导的连接。关系＆＃34。今天和今天一样真实。他描述的关系模型后来被许多其他人所建立，包括Chris Date，其书An Introduction to Database Systems是该主题最全面的来源之一。
我命名所有这些作者，因为任何一方的另一个意见都不能解决你的困惑。相反，去找消息来源并自己研究它们。是的，这是一项艰苦的工作，但你的努力将以你获得的理解质量来偿还。