为什么使用术语“关系（al）”？
Ada*_*ner 26 terminology relational-theory
用英语，我们可能会谈论鲍勃和蒂姆之间的关系。也许他们是堂兄弟。在这种情况下，“关系”一词对我来说很有意义。
在关系数据库的上下文中，我理解该术语指的是什么，但我不明白为什么要使用它。我认为理解为什么使用它会帮助我更好地理解这个领域，所以我想了解为什么使用它。
- 例如，为什么一个人被认为是一个“关系”？在英语中，关系是描述两个实体如何关联的名词。它不是指实体本身。在关系数据库的上下文中，“关系”是指实体本身。为什么？
- 我知道关系模型是在层次模型和网络模型（例如父、邻居）之后出现的。但在这些模型中，实体之间也有关系。那么为什么称这个模型为关系模型呢？有更具体的短语/术语吗？或者也许我们应该说所有三个模型都是关系模型，但是层次模型和网络模型是特定类型的关系模型？
- 如果我们有彼此不相关的独立实体怎么办。说，人，门和树。术语“关系（al）”仍然适用吗？
（也许这应该是多个问题。我认为答案是高度相关的——也许只有一个答案——所以我认为这是一个单一的问题是有意义的。如果我错了，请告诉我，我将创建单独的问题。）
编辑：此图可能有助于可视化一种关系正在将不同的域相互关联：
MDC*_*CCL 33
首先，我强烈推荐Edgar Frank Codd 博士在 1970 年向公众发布了关系框架的科学论文，即A Relational Model of Data for Large Shared Data Banks。在第 1.1 节“介绍”中，Codd 博士本人指出：
本文关注基本关系理论在系统中的应用，这些系统提供对大量格式化数据的共享访问。
© 计算机协会。ACM 通讯，第 13 卷，第 6 期（第 377-387 页），1970 年 6 月。
所以，是的，术语关系和（因此）关系来自数学背景。Codd 博士——除了他的学术和研究资历外，在计算和信息处理方面拥有大约 20 年的第一手经验——预见了在数据管理领域应用关系（一个抽象的构造，自然）的巨大优势.
我不是数学家，但基本上来说，关系是集合之间的关联，集合是元素的集合（这个外部资源给出了数学关系的定义，可能有助于从不同的角度理解它）。在 SQL 数据库管理系统（简称 DBMS）的帮助下工作时，众所周知的关系近似是表，在这种情况下，关联发生在其列的类型之间。显然，在提供 DOMAIN 支持的 SQL 平台中（例如，Firebird和PostgreSQL）中，关联发生在域已针对相关表格的列进行修复；有关重要详细信息，请参阅以下部分。
在这方面，我将再次引用 Codd 博士，他在第 1.3 节“数据的关系视图”中断言：
术语关系在这里以其公认的数学意义使用。给定集合S 1 , S 2 , ? , S n , (不一定是不同的), 如果R是一组n元组，其中每个元组的第一个元素来自S 1，第二个元素来自S 2，依此类推，则R是这n 个集合上的关系。1我们将把小号Ĵ作为Ĵ个域的ř。如上所定义，R被称为度数 n. 度数 1 的关系通常称为一元、度 2二元、度 3三元和度n n-ary。
1更简洁地说，R是笛卡尔积S 1 × S 2 × S 3的子集？× S n。
© 计算机协会。ACM 通讯，第 13 卷，第 6 期（第 377-387 页），1970 年 6 月。
我同意其他答案，指出 Codd 博士对数学关系进行了一些调整，以便在数据管理方面发挥最大作用，这点非常重要，并且在之前提到的论文中对此进行了解释和在他广泛的参考书目中。
关系和关系
一个值得提出的情况是，在处理这些主题时，可能会由于在术语关系和关系的日常（非数学、非技术）定义方面存在相似性而引起混淆——作为非-以英语为母语的人，我觉得特别容易理解——。
在实体关系图和关系模型
我认为也可能引起混淆的另一个因素（并且与上述两个术语的技术内涵密切相关）是，在学习设计数据库时，通常首先向学生或从业者介绍博士提出的方法。. Peter Pin-Shan Chen在entity-relationship view of data（1976 年发表）中提出了两种不同的实现方式（即实体和关系）来描绘一个概念模式，然后，只有在定义了该模式之后是稳定的，学生或从业者被引入关系术语和工具（例如，关系声明时）相关数据库的逻辑布局。在概念参考框架内，关系的内涵更接近于这个词的日常意义。
那么，也许这种情况也增加了关系和关系的问题——但首先定义概念模式然后声明相应的逻辑设计的顺序当然是非常合适的，我将在以下部分详细说明——。
对每个子问题的回答
我认为将这三个子问题包括在内是非常相关的，因为它们为帖子建立了更广泛的背景，因此不应忽视它们。这样一来，除了专门解决为什么术语关系和关系被使用（这当然是非常显著，是标题的帖子，但它是不是在整个后），说子问题可以理解更多的范围内协助当一个人参与整个信息管理项目时的关系和关系模型（非常相关，因为这是一个关于数据库管理的站点），因此在不同的地方工作的抽象层次上. 通过这种方式，我将在下面分享我对这些细节的看法。
子问题编号 1
例如，为什么一个人被认为是一个“关系”？在英语中，关系是描述两个实体如何关联的名词。它不是指实体本身。在关系数据库的上下文中，“关系”是指实体本身。为什么？
概念层面
在给定的业务环境中，Person可以被视为一种实体类型，具体取决于在那里工作的人员（业务专家和数据库设计人员）如何对其进行概念化。而且，是的，在该业务环境中，可能存在与Person实体类型相关的不同属性，例如Name、BirthDate、Gender等。
此外，人实体类型可保持一定的关系（或关联或连接）类型与其自身或其他实体类型; 例如，Person可能与名为UserProfile的实体类型相关联，而后者又可能有自己感兴趣的属性，比如Username和Password。
但是，(a) 实体类型，(b) 它们的相应属性，(c) 实体类型之间的关系类型和 (d) 属性本身之间的关系是“属于”它们所在的特定业务环境的概念。认为具有重要意义。它们是数据库设计人员使用的设备，与业务专家密切合作，以便在设计阶段定义特定于上下文的概念模式。
因此，在概念层面上，我们基本上使用在现实世界感兴趣的部分中出现的想法的结构，即（1）事物的原型和（2）事物原型之间关系的原型，我们不使用(3)关系——在数据的关系框架的意义上使用最后一个术语——。
逻辑层
在概念层面将Person精确描绘为实体类型之后，如果想要实现一个关系型数据库来传达Person的含义以及与之相关的所有概念，那么该类型实体的事实就可以通过美德来管理逻辑层面的数学关系，并利用可以在该抽象构造上执行的基于科学的操作（即定义它、约束它和操纵它）。
是的，在定义数据库的逻辑排列时，可以将某个关系命名为Person，但这并没有将Person的“现实世界”概念转换为关系，因为管理信息时获得的好处可以这样处理它关于它，例如，对其应用关系代数运算以推导出新的关系（因此一个是推导出“新”信息）。考虑到某种类型的实体构成一个集合，并且某个属性的值也构成一个集合，上述好处变得更加明显。
而且，是的，正如在前面的段落和其他答案中提到的，关系的最重要方面之一是其域之间存在的连接——通常用于表示实体或关联类型的属性，这些属性属于一个概念图式——。例如，假设我们已经声明了以下（三元）关系：
Salary (PersonNumber, EffectiveDate, Amount)
……让我们假设，在所讨论的业务环境中，元组— (i) 代表特定实体，即适用概念模式中的实体类型的实例，以及 (ii) 其 SQL 对应项是行—
Salary (x, y, z)
……意思是
- “
x在 EffectiveDate支付给由 PersonNumber 标识的 Person 的工资y对应于“的金额z”。
因此——以近似的方式描述事物——三个域之间的连接是最重要的，它们都是相关的（是的，一元关系只涉及一个域）。某个域的所有值之间的联系也非常重要，因为它们构成了一组精确的类型。此外，Salary关系的每个元组的内容必须适合上述断言的结构。
概念级关系和逻辑级关系
正如所展示的，我现在已经在两个不同的抽象层次上处理数据库管理，即概念和逻辑——还有一个更低的层次被称为物理层次，在 SQL DBMS 中通常涉及，例如，索引、页面、范围、等等。-。
因此，根据之前解释的概念，在逻辑层次上，一个专门处理 (a) 数学关系，其中 (b)概念关系或关联由 (c)包含在此类数学关系的元组中的值表示，并且所述值通常通过 FOREIGN KEY 约束分隔，以便它们可以准确地表示适用的关系。
并且，是的，关联实体，即具有多对多 (M:N) 基数比的关系类型的实例，可以通过单个数学关系的元组来传达 - 并适当声明相应的约束，课程-。
子问题编号 2
我知道关系模型是在层次模型和网络模型之后出现的。但在这些模型中，实体之间也有关系。那么为什么称这个模型为关系模型呢？有更具体的短语/术语吗？或者也许我们应该说所有三个模型都是关系模型，但是层次模型和网络模型是特定类型的关系模型？
网络和分层 DBMS 先于其正式的理论支持
值得指出的是，围绕分层和网络方法的理论支持实际上是根据先前存在的DBMS创建的，其目的之一是测试和建立 (1) 所述种类的健全性软件和 (2) 关联的数据管理实践——从我的角度来看，这是一种颠倒的现象——。
与关系框架相比不完整
话虽如此，尽管存在早于关系模型的分层和网络 DBMS，甚至当 Codd 博士将这些方法中的每一种称为“模型”时，也没有任何一种以与关系框架相同的方式定义。关系范式为数据的 (i) 定义、(ii) 限制和 (iii) 操作提供了科学构造，而层次和网络方法缺乏完整的理论支持来涵盖前面提到的所有三种构造。
网络和分层特征
此外，如前所述，实体和关系类型是概念级设备，它们不属于分层或网络方法，每种方法都提供特定的机制来表示所述方面：
网络范式需要两个用于数据表示的设备，即节点和弧（该特性当然意味着两种不同类型的数据操作操作），当与关系模型（根据信息原理）仅需要一个构造相比时（关系），表明以网络方式工作所涉及的不必要的复杂性。例如，鉴于它采用两种表示工具，网络方法强加了阻碍数据操作的不切实际的查询偏差。
就其本身而言，分层视图建议通过（物理！）文件来表示数据，这些文件由以三类排列组织的记录（依次由字段组成）组成；即，一个父记录通过指针与可能的许多子记录链接，这产生了关于数据操作的物理访问路径。这种方法也是不利的，因为它呈现了概念和物理方面的纠缠，因此物理存储安排的变化需要数据结构的重组，这反过来又要求相关数据操作操作的变化。
如图所示，分层视图和网络视图将它们的结构强加于要管理的数据，而关系模型则建议通过关联事实集（从这些集合中生成n 个后续类型的集合，在其自然结构中优雅地管理数据）设计阶段，可以派生等等！）。
关系模型没有子模型
而且，非常重要的是，层次视图和网络视图都不是特定类型的关系模型，它们只是其他人可能遵循的范式，以 (a) 构建 DBMS 和 (b) 创建数据库，但请记住，层次结构数十年来，网络方法被认为已经过时。
子问题编号 3
如果我们有彼此不相关的独立实体怎么办。说，人，门和树。术语“关系（al）”仍然适用吗？
是的，如果 (1) 通过适应的数学关系管理有关这些实体类型的信息，以及 (2) 在给定关系 DBMS 的支持下管理的某个数据库中的逻辑级别执行适用的关系操作，则它是完全适用的.
在概念层面上，所述实体类型是否与其他实体类型不存在关系类型并不重要（值得注意的是，一个实体类型可以具有一比零一或多基数比的关系）与自身），因此不会在所考虑的关系的元组的值之间传达或强制执行任何关系。
eck*_*kes 16
“关系数据库”背后的有趣之处在于，它并不（主要）指代表之间的关系，如您所料，但它指代元组中多个属性（列）的关系。关系数据库将这些元组存储为表中的一行。
它基于阿尔弗雷德·塔斯基( Alfred Tarski)在他 1941 年（！）的论文On the calculus of Relations 中定义的关系代数。他总结了符号逻辑中术语和用法的历史，但定义了最终成为 SQL 基础的操作。
Codd在他的12 条诫命中将其转化为可以理解为关系数据库的定义。
Tod*_*ett 10
“关系”一词来自数学，与实体之间的关系无关。我不是数学家（而 Codd 拥有数学博士学位），因此不会详细说明，但会向您指出这篇关于二元关系的维基百科文章。关于关系（数据库）的维基百科条目提供了关于 Codd 如何将数学概念应用于数据管理的更多细节。至于为什么将这种数学结构称为关系，我认为这与构成关系的域之间存在“关系”的想法有关。我所知道的最好的来源是Fabian Pascal'. Chris Date 还撰写了大量关于 RDM 的文章，他的第三个宣言网站有一个部分列出了论文和书籍。他的著作Relational Theory for Computing Professionals是一个很好的介绍。我希望这有帮助。
当您使用自然键想到它们时，这是一个直观的名称。您可以将单元格值视为表示实体。
Relation: Employee
|--------+------------+--------|
| name | job | boss |
|--------+------------+--------|
| Mark | owner | NULL |
| Bob | manager | Mark |
| Jane | supervisor | Bob |
| Claire | supervisor | Bob |
| John | cashier | Jane |
| Jesse | cashier | Jane |
| Jason | cashier | Claire |
|--------+------------+--------|
- 员工姓名“Jane”与工作“主管”相关。
- 员工姓名“John”与老板“Jane”有关。
- 工作“收银员”与员工姓名“John”、“Jesse”和“Jason”相关。
- 工作“收银员”与老板“简”和“克莱尔”有关。
小智 6
您已经接受了一个很长的答案，该答案必须对数据库说了很多，但让我回答您实际提出的问题：
为什么使用“关系”一词。
因为表是数学对象“关系”的具体实例。
让我们看看维基百科对术语“关系”（在数学中，而不是 RDBMS 中）是怎么说的，然后将其翻译为数据库：
形式上，关系是一组等度的 n 元组。因此，二元关系是一组对，三元关系是一组三元组，等等。在集合论的语言中，两个集合之间的关系是它们笛卡尔积的一个子集。
Mathematics | RDBMS
========================|===============
A relation is | A table is
a set of | a bunch of
n-tuples | rows
of equal degree. | with the same cell (a.k.a. column) types and sizes.
它继续集合论。请记住，这是数学，比数据库的东西抽象得多。因此最后一句话是
两个集合之间的关系是它们的笛卡尔积的子集。
这意味着到一个与表2列：
- 我们称 A 列为“名称”。它的数学集合
A是所有（人类）名字的集合。 - 列 BI 调用“城市”。它的数学集合
B是所有城市的集合。 - 笛卡尔积
A x B（在数学中）是一个新的集合，它包含所有对（又名，tupels）(a, b)，其中a是 的成员A，并且b是 的成员B。即，a是一个名字，b是一个城市。示例将是(Alice, New York)或(Bob, Hollywood)。但是笛卡尔积不仅是其中的几个，而是全部。说到点子上，关系是笛卡尔积的一个子集。换句话说，关系是（定义为）任意数量的对(a, b)，其中a是一个名字和b一个城市，甚至根本没有。
现在我希望一切都开始有意义了。在 RDBMS 中，表的行只是挑选出这些列中所有可能组合的笛卡尔积的子集。也就是说，在使用RDBMS 时，完全无关紧要。
但是由于计算机科学（包括关系数据库）确实起源于数学，因此我们很幸运在这里使用“关系”一词。它是完全抽象的，与人与人之间的关系或你有什么无关。
顺便说一句，术语“关系”有时也用于“关联”，它是完全相同的（这里，关系的基础集合是它们本身如上所述的关系（又名，表格））。
注意：在数学中，关系与数据库无关，而是类似于函数，只是更一般（请所有数学家，现在不要开始吹毛求疵，我们在 dba.SE，而不是 math.SE；我知道这是错误的方法:)）。类似f(x)=x+1also的函数可以表示为一组元组(1, 2), (2, 3), ...，但它只能在元组的左侧出现每个数字一次。即，这不会是一个有效的功能：(1, 2), (1, 3), ...。但后者将是一个有效的关系；也就是说，你可以在纽约鲍勃和在好莱坞鲍勃。
关系数据库基于EFCodd的关系模型。在关系代数介绍了如何查询数据的方法。关系只是一些集合（域）的叉积的子集。
例子
我们有以下套装：
DepIds = {1, 2, 3, ...}
EmpIds = {1, 2, 3, ...}
DepNames = {'Engineering', 'Finance', 'Sales', ...}
FirstNames = {'John', 'Walter', 'Mary', 'Roxane', ...}
LastNames = {'Smith', 'Bondy', 'Taylor', ...}
BirthDates = {..., 1950-01-01, 1950-01-02, ...}
Jobs = {'Accountant', 'Programmer', 'Database Administrator', ...}
此外，我们有元组集
departements = {
(1, 'Engineering'),
(2, 'Finance')}
employees = {
(1, 1, 'John', 'Taylor', 1985-03-22, 'Programmer'),
(2, 1, 'Walter', 'Bondy', 1997-09-11, 'Database Administrator'),
(3, 2, 'Roxane', 'Myers', 1987-12-19, 'Accountant')}
departements 是一个子集
DepIds x DepNames
所以这是一个关系。
employees 是一个子集
EmpIds x DepIds x FirstNames x LastNames x BirthDates x Jobs
所以它也是一种关系。
很明显，关系可以通过表来实现。
为什么数学家称一组元组为关系？
通常，诸如“2 小于 3”、“4 等于 4”、“2 介于 1 和 3.4”、“-1 为负”之类的属性称为关系。
集合 A={1, 2, 3} 上的关系“小于”由子集定义
{(1, 2), (1, 3), (2, 3) }
的
A x A = {1, 2, 3} x {1, 2, 3}=
{ (1, 1), (1, 2), (1, 3),
(2, 1), (2, 2), (2, 3),
(3, 1), (3, 2), (3, 3) }
以类似的方式，可以将其他关系视为叉积的子集。'x 小于 y'，'x 等于 y' 是二元关系，因此由一组对定义。“y 和 z 之间的 x”是三元关系，因此由一组三元组定义。“x 为负”是一元关系，因此由一组单例定义。
我们上面定义的部门元组集是一个二元关系，员工关系是一个六元关系。