用英语，我们可能会谈论鲍勃和蒂姆之间的关系。也许他们是表亲。在这种情况下，术语“关系”对我来说很有意义。
在关系数据库的上下文中，我理解该术语所指的含义，但我不理解为什么使用该术语。我认为了解为什么使用它可以帮助我更好地理解该领域，因此我想了解为什么使用它。
（也许这应该是多个问题。我认为答案是高度相关的-也许只有一个答案-所以我认为这是一个问题是有意义的。如果我错了，请告诉我而是创建单独的问题。）
编辑：此图对于可视化关系将不同的域相互关联起来可能很有用：
Answers:
首先，我强烈推荐Edgar Frank Codd博士在1970年向公众发布关系框架的科学论文，即大型共享数据库的数据关系模型。在那里，科德博士在第1.1节“简介”中指出：
本文涉及基本关系理论在系统上的应用，该系统提供对大型格式化数据库的共享访问。
©计算机协会。ACM通讯，1970年6月，第13卷，第6期（第377-387页）。
因此，是的，关系和（因此）关系这两个术语来自数学背景。Codd博士（除了他的学术和研究资历，在计算和信息处理方面拥有大约20年的第一手经验）还设想了在数据管理领域中应用该关系（自然是抽象构造）的巨大优势。 。
我不是数学家，但从根本上讲，关系是集合之间的关联，集合是元素的集合（此外部资源提供了数学关系的定义，可能有助于从不同的角度理解它）。当借助SQL数据库管理系统（为简便起见，使用DBMS）进行工作时，众所周知的关系近似表是表，在这种情况下，关联发生在其列的类型之间。显然，在确实提供DOMAIN支持的SQL平台（例如Firebird和PostgreSQL）中，关联发生在为相关表格的列固定的域；有关重要的详细信息，请参见以下各节。
在这方面，我将再次引用Codd博士的观点，他在第1.3节“数据的关系视图”中断言：
术语“ 关系”在这里以其公认的数学意义使用。给定集合S 1，S 2，，S n，（不一定是不同的），如果R是一组n元组（每个元组都具有第一个元素S 1，第二个元素），则R是这n个集合的关系。从S 2开始，依此类推。1我们将把小号Ĵ作为Ĵ个域的ř。如上述所定义，- [R据说有度n。1级的关系通常称为一元，2级二元，3级三元和n n元。
1简而言之，R是笛卡尔积S 1 × S 2 × S 3 ⋯× S n的子集。
©计算机协会。ACM通讯，1970年6月，第13卷，第6期（第377-387页）。
我也同意其他答案，因为指出Codd博士对数学关系进行了一些调整以最大程度地利用它来处理数据管理，这一点非常相关，在之前和之前所提到的论文中对此进行了解释。在他广泛的书目中。
关系和关系
一种情形值得造就的是，随着这些问题打交道时，有可能会出现混乱，由于存在对条款的日常（非数学，非技术）定义的相似性关系和关系哪位，作为非我以英语为母语的人，尤其可以理解。
在实体关系图和关系模型
我认为还可能引起混淆的其他因素（与上面提到的两个术语的技术含义紧密相关）是，在学习设计数据库时，通常首先向学生或从业人员介绍博士提出的方法。Peter Pin-Shan Chen在数据的实体关系视图中（于1976年发布），提出了两种不同的实现方式（即，实体和关系）来描述概念图式，然后仅在定义了该图式之后如果是稳定的，则在声明学生或从业人员时，会向他们介绍关系术语和工具（例如，关系）相关数据库的逻辑布局。在概念的参照系中，关系所包含的含义与词的日常意义更加接近。
然后，也许，这种情况也增加了关系和关系的问题，但是首先定义概念图式，然后声明相应的逻辑设计的顺序当然是很合适的，我将在以下各节中详细介绍。
我认为，包括这三个子问题确实是相关的，因为它们为职位提供了更广阔的背景，因此不应忽视它们。这样一来，除了专门解决为什么术语关系和关系被使用（这当然是非常显著，是标题的帖子，但它是不是在整个后），说子问题可以理解更多的范围内协助当一个人参与整个信息管理项目时，该关系和关系模型（非常相关，因为这是一个有关数据库管理的站点），因此在不同的抽象层次上工作。通过这种方式，我将在下面分享我对这些细节的看法。
例如，为什么一个人被认为是“关系”？用英语来说，关系是描述两个实体如何关联的名词。它不涉及实体本身。在关系数据库的上下文中，“关系”是指实体本身。为什么？
概念层面
在给定的业务环境中，根据在此工作的人员（业务专家和数据库设计人员）如何将其概念化，可以将Person视为实体类型。并且，是的，在该业务环境中，关于Person实体类型，例如，Name，BirthDate，Gender等，可能会有不同的关注属性。
此外，人实体类型可保持一定的关系（或关联或连接）类型与其自身或其他实体类型; 例如，Person可能与名为UserProfile的实体类型相关联，而该实体类型又可能具有其自己感兴趣的属性，比如说Username和Password。
但是，（a）实体类型，（b）它们的相应属性，（c）实体类型之间的关系类型和（d）属性本身之间的关系是“属于”它们所处的特定业务环境的概念被认为是重要的。它们是数据库设计人员使用的设备，它们与业务专家紧密合作，以便在设计阶段定义特定于上下文的概念架构。
因此，在概念层面上，我们基本上是处理现实世界中感兴趣的部分中出现的思想的结构，即（1）事物的原型和（2）事物的原型之间的关系的原型，我们不使用（3）关系-在数据的关系框架的意义上采用最后一个术语-。
逻辑层次
在概念级别将Person精确地描述为一种实体类型之后，如果想要实现一个传达Person的含义以及与之相关的所有概念的关系数据库，则可以借助该类型的实体来管理事实在逻辑层次上具有数学关系，并利用可以在该抽象构造上执行的基于科学的操作（即定义，约束和操纵它）。
是的，在定义数据库的逻辑排列时，可以命名某个关系“ 人”，但这并不能将“现实世界”中的“ 人 ”概念转化为一种关系，由于管理信息时会获得好处，因此可以这样处理关于它的信息，例如，在其上应用关系代数运算以得出新的关系（因此人们正在推导“新”信息）。考虑到某种类型的实体组成一个集合，并且某种属性的值也组成一个集合，上述好处变得更加明显。
而且，是的，正如前面的段落和其他答案中提到的那样，关系的最重要方面之一是其域之间存在的连接 -通常用于表示实体或关联类型的属性，这些实体或关联类型是概念模式。例如，假设我们声明了以下（三元）关系：
Salary (PersonNumber, EffectiveDate, Amount)…并让我们假设，在有问题的商业环境中，元组 -（i）代表特定实体，即适用概念模式中实体类型的实例，以及（ii）SQL对应项是行 -
Salary (x, y, z)……将具有意义
x在EffectiveDate上支付给PersonNumber所标识的人员的工资y与的金额相对应z”。因此，以一种近似的方式描述事物，这三个域之间的联系至关重要，它们都是相关的（是的，一元关系仅涉及一个域）。某个域的所有值之间的联系也非常重要，因为它们构成了一组精确的类型。同样，该Salary关系的每个元组的内容必须适合上述声明的结构。
概念层次关系和逻辑层次关系
如所示，我现在在两个不同的抽象层次上处理数据库管理，即概念层次和逻辑层次-还有一个称为物理层次的较低层次，在SQL DBMS中通常涉及例如索引，页面，范围，等等。-。
因此，根据前面解释的概念，在逻辑级别上，一个专门用于（a）数学关系，其中（b）概念关系或关联由（c）这种数学关系的元组中包含的值表示，这些值通常通过FOREIGN KEY约束定界，以便它们可以准确表示适用的关系。
而且，是的，关联实体，即具有多对多（M：N）基数比的关系类型的实例，可以通过单个数学关系的元组来传递-具有适当声明的对应约束，课程-。
我知道关系模型是继分层模型和网络模型之后出现的。但是在这些模型中，实体之间也有关系。那么为什么将此模型称为关系模型呢？是否有更具体的短语/术语？也许我们应该说这三个模型都是关系模型，但是层次模型和网络模型是特定类型的关系模型？
网络和分层DBMS在获得正式理论支持之前
应当指出，围绕分层方法和网络方法的理论支持实际上是根据先前存在的 DBMS 创建的，其目的之一是测试和确定（1）种类型的合理性。软件和（2）关联的数据管理实践（从我的角度来看，这是一种倒置现象）。
与关系框架相比不完整
话虽这么说，尽管存在关系模型之前的分层DBMS和网络DBMS，即使Codd博士将这些方法中的每一种称为“模型”，也都没有以与关系框架相同的方式对其进行定义。关系范式为（i）定义，（ii）限制和（iii）数据操纵提供了科学的构造，而层次结构和网络方法缺乏完全的理论支持来覆盖前面提到的所有三种构造。
网络和分层功能
同样，如前所述，实体和关系类型是概念级别的设备，它们不属于层次结构或网络方法，每种方法都提供了表示所述方面的特定机制：
网络范例需要两个用于数据表示的设备，即节点和弧（并且该特性当然意味着两种不同的数据操作操作），与关系模型（根据信息原理）相比，它们仅需要一种构造（该关系）表明以网络方式工作所涉及的不必要的复杂性。例如，假定使用两种表示工具，则网络方法会施加不切实际的查询偏见，从而阻碍数据操作。
就其本身而言，层次视图建议通过（物理！）文件来表示数据，这些文件由以三类形式组织的记录（这些记录又由字段组成）组成；也就是说，一个父记录通过指针与可能的许多子对应对象链接在一起，这会产生关于数据操作的物理访问路径。该方法也是不利的，因为它在概念和物理方面之间存在纠缠，因此物理存储安排中的更改要求对数据结构进行重组，这又要求在有关的数据操作操作中进行更改。
如图所示，层次结构视图和网络视图将其构造强加于要管理的数据上，而关系模型建议通过关联事实集（从中自然选出n个后续类型的集，在这些自然事实中优雅地管理数据）设计阶段，可以派生出来，依此类推！）。
关系模型没有子模型
而且，非常重要的是，层次结构视图和网络视图都不是关系模型的特定类型，它们只是人们可以遵循的其他范式（a）构建DBMS和（b）创建数据库，但是请记住，层次结构和网络方法被认为已经过时了数十年。
如果我们拥有彼此不相关的独立实体该怎么办。说，人，门和树。术语“关系”是否仍然适用？
是的，如果（1）通过适应的数学关系来管理关于那些实体类型的信息，并且（2）在特定数据库中以给定关系DBMS的支持在逻辑级别上执行适用的关系操作，这将是完全适用的。
在概念级别上，所述实体类型是否与其他实体类型不具有任何关系类型无关紧要（并且值得注意的是，一个实体类型可以具有一对零或一对多基数关系）与自身有关），因此，在考虑中的关系的元组的值之间没有传达或加强任何关系。
“关系”一词来自数学，与实体之间的关系无关。我不是数学家（而Codd拥有数学博士学位），因此不会详细说明，但是会向您指出有关二元关系的 Wikipedia文章。有关关系（数据库）的维基百科条目提供了有关Codd如何适应数学概念以应用于数据管理的更多详细信息。关于为什么将这种数学结构称为关系，我认为这与构成关系的域之间存在“关系”的想法有关。为了更好地理解Codd的原始思想，我所知道的最好的资料是Fabian Pascal'。。克里斯·伊达特（Chris Date）还在RDM上写过很多书，他的《第三宣言》网站上有一节列出了论文和书籍。他的书《计算专业人员的关系理论》是一本不错的书。我希望这有帮助。
当您使用自然键想到它们时，这是一个直观的名称。您可以将单元格值视为代表实体。
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 |
|--------+------------+--------|
您已经接受了一个很长的答案，其中必须包含很多有关数据库的内容，但是让我回答您实际提出的问题：
为什么使用“关系”一词。
因为表是数学对象“关系”的具体实例。
让我们看看维基百科对“关系”一词有何评论（在数学中，而不是在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.
它继续与集合论。请记住，这是数学，比数据库的东西抽象得多。因此，最后一句话是
两组之间的关系是其笛卡尔积的子集。
这将转换为包含两列的一个表：
A是所有（人类）名称的集合。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+1也可以表示为一组元组(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为负”是一元关系，因此由一组单例定义。
我们上面定义的部门元组是二元关系，雇员关系是六元关系。