关系模型:表还是主键和外键？

Question

在谈到关系数据库时，似乎大多数人都将主键和外键“关系”称为“关系数据库”术语的原因。

这给我造成了相当大的混乱，因为下面的教科书明确指出“一个常见的误解是，名称”关系“与表之间的关系(即外键)有关。实际上，模型名的真正来源是数学概念关系。关系模型中的关系就是SQL所称的表。”

campaign=Froogle&date=11/12/15

此外，下一个源显式地将表引用为关系，而不是主/外键。https://docs.oracle.com/javase/tutorial/jdbc/overview/database.html

然而，这似乎是常识，几乎在任何其他地方，我看或读到，主键和外键是关系。

有谁有不一致的原因吗？

Answer 1

外键约束是一种关系--子集关系--但这些关系并不是模型名称的来源。相反，关系模型的关系指的是有限关系。Ted Codd在他1970年的论文“A Relational Model of Data for Large Shared Data Banks”中写道：“在这里，关系这个词在它被接受的数学意义上使用。给定集合S1，S2，……Sn (不一定不同)，R是这些n集上的一个关系，如果它是一个n元组，其中每个元组都有来自S1的第一个元素，它的第二个元素来自S2，等等。”因此，他描述了一个可以由表表示的结构，如果我们遵循一些规则，比如忽略重复的行和行的顺序(毕竟，这是一个集合)。

另一个常见的误解是外键约束代表实体之间的关系。关系被表示为关联值行的集合/表。无论是在“实体表”还是“关系表”中，两个或多个实体的键都将被记录在一起。外键约束只执行完整性，它们不链接实体或表。表可以在任何谓词函数上连接，外键约束在这里不起作用。

大多数人从博客、教程和答案中学习数据库概念，按受欢迎程度排列。大多数人从来没有读过一本像样的数据库书，更不用说数据关系模型的发明者和学生的论文了。大多数程序员和公司都希望产品能够发布，并且对逻辑、理论和哲学几乎没有时间或欣赏。这是一个本质上复杂的领域--请参阅Bill Kent的书“Data and Reality”(关于这种复杂性的探索)。因此，在人们试图理解一个棘手的话题时，你在互联网上发现的大部分内容充其量不过是半真半假。

人们对记录和指针很熟悉，因为它们在主流编程语言中很流行，它们看上去和听起来都很像实体和关系。如果实体由表/记录表示，属性按字段/列表示，那么实体之间的1到-1/1到多个关系必须是记录/表之间的关联，对吗？这是一个简单的想法，这使得它很难纠正。对象/关系映射和面向对象的领域模型的流行源自于这个简单的想法(和一些关系支持者的粗暴态度不同，来自于言行一致、善于交际的作者)，但也进一步巩固了这种观念。

Peter Chen ( The Entity-Relationship Model - Toward a Unified View of Data的作者)努力做到严谨，区分“实体关系”和“关系关系”。在他看来，实体是真实世界的概念，在数据库中表示为值，并通过行中的值关联来描述。实体之间的关系类似地由行中的值关联来表示。E模型在关系和属性之间的区别有些多余(属性只是二进制关系)，区分实体元组和关系元组没有什么好处。事实上，我相信这会加深混乱。它与旧的网络模型表面上相似，这有助于它的采用，但也有助于维护后者，因为开发人员在维护旧实践的同时采用了新的术语。

对象-角色建模(又名NIAM，Sjir Nijssen和Terry Halpin)消除了属性，侧重于域、角色和关系。它比for更优雅，更接近真正的关系模型，但它的优点(逻辑、全面、远离网络模型)也是它的弱点(学习曲线、更复杂的图表，不太适合作为熟悉技术的工具)。

Ted Codd在上面提到的文章中指出，“另一方面，网络模型产生了许多困惑，其中并非最不重要的是将连接的推导误认为是关系的推导。”今天的情况和当时一样。他描述的关系模型后来被许多其他人建立在此基础上，包括Chris Date，他的书“An Introduction to Database Systems”是这个主题最全面的来源之一。

我命名所有这些作者是因为任何一方的多一个观点并不能澄清你的困惑。相反，去找资料来源，为自己研究它们。是的，这是一项艰苦的工作，但是你的努力会在你获得理解的质量上得到回报。