介绍
数据库管理系统(DBMS) 是允许用户与数据库交互的计算机程序。DBMS 允许用户控制对数据库的访问、写入数据、运行查询以及执行与数据库管理相关的任何其他任务。
但是，为了执行这些任务中的任何一项，DBMS 必须具有某种定义数据组织方式的底层模型。在关系模型是组织已经发现，在数据库软件广泛使用，因为它是在20世纪60年代末首先设计数据的一种方法，以至于，截至记者发稿，前五名最流行的DBMS四是关系。
这篇概念性文章概述了关系模型的历史、关系数据库如何组织数据以及它们在今天的使用方式。
关系模型的历史
数据库是逻辑建模的信息或数据集群。任何数据集合都是一个数据库，无论其存储方式和存储位置如何。甚至包含工资单信息的文件柜也是一个数据库，就像一堆医院病人表格一样，或者一个公司收集的分布在多个位置的客户信息。在使用计算机存储和管理数据成为普遍做法之前，需要存储信息的政府和商业组织只能使用此类物理数据库。
大约在 20 世纪中叶，计算机科学的发展导致机器具有更强的处理能力，以及更大的本地和外部存储容量。这些进步促使计算机科学家开始认识到这些机器在存储和管理越来越多的数据方面的潜力。
然而，没有任何关于计算机如何以有意义的、合乎逻辑的方式组织数据的理论。在机器上存储未排序的数据是一回事，但设计允许您以一致、实用的方式添加、检索、排序和以其他方式管理数据的系统要复杂得多。对存储和组织数据的逻辑框架的需求导致了许多关于如何利用计算机进行数据管理的建议。
一种早期的数据库模型是分层模型，其中数据以树状结构组织，类似于现代文件系统。以下示例显示了用于对动物进行分类的分层数据库的一部分的布局可能看起来如何：
层次模型在早期的数据库管理系统中得到了广泛的应用，但它也被证明有些不灵活。在此模型中，即使单个记录可以有多个“子项”，但每个记录在层次结构中只能有一个“父项”。因此，这些早期的分层数据库仅限于表示“一对一”和“一对多”关系。这种“多对多”关系的缺乏可能会在您处理要与多个父级关联的数据点时导致问题。
1960 年代后期，在 IBM 工作的计算机科学家 Edgar F. Codd 设计了数据库管理的关系模型。Codd 的关系模型允许单个记录与多个表相关联，从而除了“一对多”关系之外，还支持数据点之间的“多对多”关系。在设计数据库结构时，这比其他现有模型提供了更大的灵活性，这意味着关系数据库管理系统 (RDBMS) 可以满足更广泛的业务需求。
Codd 提出了一种管理关系数据的语言，称为Alpha，它影响了后来数据库语言的发展。Codd 在 IBM 的两位同事 Donald Chamberlin 和 Raymond Boyce 在 Alpha 的启发下创造了一种这样的语言。他们称他们的语言SEQUEL，简称小号tructured é简体中文阙RY大号anguage，但因为现有的商标，他们缩短了语言的名称SQL（简称更正式的结构化查询语言）。
由于硬件限制，早期的关系数据库仍然非常缓慢，并且该技术需要一段时间才能普及。但到 1980 年代中期，Codd 的关系模型已在 IBM 及其竞争对手的许多商业数据库管理产品中实施。这些供应商还通过开发和实现他们自己的 SQL 方言来效仿 IBM。到 1987 年，美国国家标准协会和国际标准化组织都批准并发布了 SQL 标准，巩固了其作为管理 RDBMS 的公认语言的地位。
关系模型在多个行业的广泛使用使其成为公认的数据管理标准模型。即使近年来各种NoSQL 数据库兴起，关系数据库仍然是存储和组织数据的主要工具。
关系数据库如何组织数据
现在您对关系模型的历史有了大致的了解，让我们仔细看看模型是如何组织数据的。
关系模型中最基本的元素是关系，用户和现代 RDBMS 将其识别为表。关系是一组元组或表中的行，每个元组共享一组属性或列：
列是关系数据库的最小组织结构，代表定义表中记录的各个方面。因此他们更正式的名称，属性。您可以将每个元组视为表中保存的任何类型的人、对象、事件或关联的唯一实例。这些实例可能是公司员工、在线业务的销售或实验室测试结果等。例如，在保存学校教师员工记录的表中，元组可能具有诸如name、subjects、等属性start_date。
创建列时，您指定一种数据类型，该数据类型指示该列中允许的条目类型。RDBMS 通常实现自己独特的数据类型，这些数据类型可能无法与其他系统中的类似数据类型直接互换。一些常见的数据类型包括日期、字符串、整数和布尔值。
在关系模型中，每个表至少包含一列可用于唯一标识每一行，称为主键。这很重要，因为这意味着用户不需要知道他们的数据在机器上的物理存储位置；相反，他们的 DBMS 可以跟踪每条记录并临时返回它们。反过来，这意味着记录没有定义的逻辑顺序，用户可以按任何顺序或通过他们希望的任何过滤器返回他们的数据。
如果您有两个要相互关联的表，一种方法是使用外键。外键本质上是一个表（“父”表）主键的副本，插入到另一个表（“子”）的列中。以下示例突出显示了两个表之间的关系，一个用于记录有关公司员工的信息，另一个用于跟踪公司的销售情况。在本例中，EMPLOYEES表的主键用作表的外键SALES：
如果尝试向子表添加一条记录，而输入到外键列的值在父表的主键中不存在，则插入语句将无效。这有助于维护关系级别的完整性，因为两个表中的行将始终正确关联。
关系模型的结构元素有助于以有组织的方式存储数据，但存储数据只有在您可以检索数据时才有用。要从 RDBMS 检索信息，您可以发出查询或对一组信息的结构化请求。如前所述，大多数关系数据库使用 SQL 来管理和查询数据。SQL 允许您使用各种子句、谓词和表达式来过滤和操作查询结果，从而使您可以很好地控制将出现在结果集中的数据。
关系数据库的优点和局限性
考虑到关系数据库的底层组织结构，让我们考虑一下它们的一些优点和缺点。
今天，SQL 和实现它的数据库在几个方面都偏离了 Codd 的关系模型。例如，Codd 的模型规定表中的每一行都应该是唯一的，而出于实用性的原因，大多数现代关系数据库确实允许重复行。如果 SQL 数据库未能遵守 Codd 的每个关系模型规范，那么有些人不认为 SQL 数据库是真正的关系数据库。但实际上，任何使用 SQL 并且至少在某种程度上遵循关系模型的 DBMS 都可能被称为关系数据库管理系统。
尽管关系数据库迅速流行起来，但随着数据变得更有价值并且企业开始存储更多数据，关系模型的一些缺点开始变得明显。一方面，水平扩展关系数据库可能很困难。水平扩展或向外扩展是向现有堆栈添加更多机器以分散负载并允许更多流量和更快处理的做法。这通常与垂直扩展形成对比，垂直扩展涉及升级现有服务器的硬件，通常是通过添加更多 RAM 或 CPU。
难以横向扩展关系数据库的原因与以下事实有关：关系模型旨在确保一致性，这意味着查询同一数据库的客户端将始终检索相同的数据。如果您要跨多台机器水平扩展关系数据库，则很难确保一致性，因为客户端可能会将数据写入一个节点而不是其他节点。初始写入与更新其他节点以反映更改的时间之间可能存在延迟，从而导致它们之间的不一致。
RDBMS 提出的另一个限制是，关系模型旨在管理结构化数据，或与预定义数据类型一致或至少以某种预定方式组织的数据，使其易于排序和搜索。然而，随着 1990 年代初期个人计算的普及和互联网的兴起，非结构化数据（例如电子邮件、照片、视频等）变得更加普遍。
这并不是说关系数据库没有用。恰恰相反，关系模型在 40 多年后仍然是数据管理的主导框架。它们的流行和长寿意味着关系数据库是一项成熟的技术，这本身就是它们的主要优势之一。有许多应用程序设计用于关系模型，以及许多职业数据库管理员，他们是关系数据库方面的专家。对于那些希望开始使用关系数据库的人，还有大量可用的印刷和在线资源。
关系数据库的另一个优点是几乎每个 RDBMS 都支持事务。事务由作为单个工作单元按顺序执行的一个或多个单独的 SQL 语句组成。事务呈现一种全有或全无的方法，这意味着事务中的每个 SQL 语句都必须有效；否则，整个交易将失败。这对于在更改多行或表时确保数据完整性非常有帮助。
最后，关系数据库非常灵活。它们已被用于构建各种不同的应用程序，并且即使处理大量数据也能继续高效工作。SQL 也非常强大，允许您动态添加和更改数据，以及在不影响现有数据的情况下更改数据库模式和表的结构。
结论
由于其灵活性和数据完整性设计，关系数据库在最初构想五十多年后仍然是管理和存储数据的主要方式。即使近年来各种 NoSQL 数据库兴起，对于任何想要构建利用数据力量的应用程序的人来说，理解关系模型以及如何使用 RDBMS 都是关键。
要了解有关一些流行的开源 RDBMS 的更多信息，我们鼓励您查看我们对各种开源关系 SQL 数据库的比较。如果您有兴趣了解有关数据库的更多信息，我们鼓励您查看我们完整的数据库相关内容库。
