了解关系数据库

介绍

数据库管理系统 (DBMS) 是允许用户与数据库交互的计算机程序。 DBMS 允许用户控制对数据库的访问、写入数据、运行查询以及执行与数据库管理相关的任何其他任务。

但是，为了执行任何这些任务，DBMS 必须有某种底层模型来定义数据的组织方式。 关系模型 是一种组织数据的方法，自 1960 年代后期首次设计以来，它已在数据库软件中得到广泛使用，以至于在撰写本文时，四个顶级五个最流行的 DBMS 是关系型的。

这篇概念性文章概述了关系模型的历史、关系数据库如何组织数据以及它们今天的使用方式。

关系模型的历史

Databases 是逻辑建模的信息集群，或 data。任何数据集合都是数据库，无论其存储方式或存储位置如何。即使是包含工资单信息的文件柜也是数据库，医院患者表格的堆栈或公司分布在多个位置的客户信息集合也是数据库。在使用计算机存储和管理数据成为常见做法之前，像这样的物理数据库是政府和企业组织需要存储信息的唯一可用数据库。

大约在 20 世纪中叶，计算机科学的发展导致机器具有更强的处理能力，以及更大的本地和外部存储容量。这些进步使计算机科学家开始认识到这些机器在存储和管理大量数据方面的潜力。

然而，对于计算机如何以有意义的、合乎逻辑的方式组织数据，并没有任何理论。在机器上存储未排序的数据是一回事，但设计允许您以一致、实用的方式添加、检索、排序和以其他方式管理数据的系统要复杂得多。对存储和组织数据的逻辑框架的需求导致了许多关于如何利用计算机进行数据管理的建议。

一种早期的数据库模型是分层模型，其中数据以树状结构组织，类似于现代文件系统。以下示例显示了用于对动物进行分类的分层数据库的部分布局可能看起来如何：

层次模型在早期的数据库管理系统中得到了广泛的应用，但也被证明有些不灵活。在此模型中，即使单个记录可以有多个“子”，但每个记录在层次结构中只能有一个“父”。因此，这些早期的分层数据库仅限于表示“一对一”和“一对多”关系。当您处理希望与多个父级关联的数据点时，这种“多对多”关系的缺乏可能会导致问题。

在 1960 年代后期，埃德加 F. Codd 是一名在 IBM 工作的计算机科学家，他设计了数据库管理的关系模型。 Codd 的关系模型允许单个记录与多个表相关联，从而除了“一对多”关系之外，还支持数据点之间的“多对多”关系。在设计数据库结构时，这提供了比其他现有模型更大的灵活性，并且意味着关系数据库管理系统 (RDBMS) 可以满足更广泛的业务需求。

Codd 提出了一种用于管理关系数据的语言，称为 Alpha，它影响了后来数据库语言的发展。 Codd 在 IBM 的两位同事 Donald Chamberlin 和 Raymond Boyce 在 Alpha 的启发下创造了一种这样的语言。他们称他们的语言为 SEQUEL，简称 Structured English Query Language，但因为一个现有的商标，他们将语言名称缩短为 SQL（更正式地称为 Structured Query Language）。

由于硬件的限制，早期的关系数据库仍然非常缓慢，并且需要一些时间才能使该技术普及。但是到 1980 年代中期，Codd 的关系模型已经在 IBM 及其竞争对手的许多商业数据库管理产品中实施。这些供应商还效仿 IBM 开发并实施了自己的 SQL 方言。到 1987 年，美国国家标准协会和国际标准化组织都批准并发布了 SQL 标准，巩固了其作为管理 RDBMS 的公认语言的地位。

关系模型在多个行业中的广泛使用使其成为公认的数据管理标准模型。即使近年来各种NoSQL数据库的兴起，关系数据库仍然是存储和组织数据的主要工具。

关系数据库如何组织数据

现在您对关系模型的历史有了大致的了解，让我们仔细看看模型是如何组织数据的。

关系模型中最基本的元素是 relations，用户和现代 RDBMS 将其识别为表。关系是一组元组或表中的行，每个元组共享一组属性或列：

列是关系数据库的最小组织结构，表示定义表中记录的各个方面。因此，他们更正式的名称，属性。您可以将每个元组视为该表包含的任何类型的人、对象、事件或关联的唯一实例。这些实例可能是公司的员工、在线业务的销售或实验室测试结果。例如，在保存学校教师员工记录的表中，元组可能具有 name、subjects、start_date 等属性。

创建列时，您指定一个 数据类型 来指示该列中允许的条目类型。 RDBMS 通常实现自己独特的数据类型，这些数据类型可能无法与其他系统中的类似数据类型直接互换。一些常见的数据类型包括日期、字符串、整数和布尔值。

在关系模型中，每个表至少包含一列，可以用来唯一标识每一行，称为主键。这很重要，因为这意味着用户不需要知道他们的数据在机器上的物理存储位置；相反，他们的 DBMS 可以跟踪每条记录并临时返回它们。反过来，这意味着记录没有定义的逻辑顺序，并且用户能够以任何顺序或通过他们希望的任何过滤器返回他们的数据。

如果您有两个想要相互关联的表，一种方法是使用外键。外键本质上是一个表（“父”表）主键的副本，插入到另一个表（“子”）的列中。以下示例突出显示了两个表之间的关系，一个用于记录公司员工的信息，另一个用于跟踪公司的销售情况。在这个例子中，EMPLOYEES表的主键被用作SALES表的外键：

如果尝试向子表添加记录，而外键列输入的值在父表的主键中不存在，则插入语句无效。这有助于维护关系级别的完整性，因为两个表中的行将始终正确关联。

关系模型的结构元素有助于以有组织的方式存储数据，但存储数据只有在您可以检索数据时才有用。要从 RDBMS 检索信息，您可以发出查询或对一组信息的结构化请求。如前所述，大多数关系数据库使用 SQL 来管理和查询数据。 SQL 允许您使用各种子句、谓词和表达式过滤和操作查询结果，从而使您可以很好地控制将出现在结果集中的数据。

关系数据库的优点和局限性

考虑到关系数据库的底层组织结构，让我们考虑一下它们的一些优点和缺点。

今天，SQL 和实现它的数据库在几个方面都偏离了 Codd 的关系模型。例如，Codd 的模型规定表中的每一行都应该是唯一的，而出于实用性的原因，大多数现代关系数据库确实允许重复行。如果 SQL 数据库未能遵守 Codd 对关系模型的每个规范，则有些人不认为它们是真正的关系数据库。然而，实际上，任何使用 SQL 并至少在一定程度上遵循关系模型的 DBMS 都可能被称为关系数据库管理系统。

尽管关系数据库迅速普及，但随着数据变得更有价值并且企业开始存储更多数据，关系模型的一些缺点开始变得明显。一方面，水平扩展关系数据库可能很困难。 水平扩展或向外扩展，是向现有堆栈添加更多机器以分散负载并允许更多流量和更快处理的做法。这通常与 垂直缩放 形成对比，后者涉及升级现有服务器的硬件，通常通过添加更多 RAM 或 CPU。

难以水平扩展关系数据库的原因与关系模型旨在确保 一致性 的事实有关，这意味着查询相同数据库的客户端将始终检索相同的数据。如果您要在多台机器上水平扩展关系数据库，则很难确保一致性，因为客户端可能会将数据写入一个节点而不是其他节点。初始写入与更新其他节点以反映更改的时间之间可能会有延迟，从而导致它们之间的不一致。

RDBMS 提出的另一个限制是关系模型旨在管理 结构化数据 ，或与预定义数据类型对齐或至少以某种预定方式组织的数据，使其易于排序和搜索。然而，随着 1990 年代初期个人计算的普及和互联网的兴起， 非结构化数据 — 例如电子邮件、照片、视频等。 ——变得越来越普遍。

这并不是说关系数据库没有用处。恰恰相反，关系模型在 40 多年后仍然是数据管理的主导框架。它们的流行和长寿意味着关系数据库是一种成熟的技术，这本身就是它们的主要优势之一。有许多应用程序旨在与关系模型一起使用，以及许多职业数据库管理员在关系数据库方面是专家。对于那些希望开始使用关系数据库的人来说，还有大量的印刷版和在线资源可供使用。

关系数据库的另一个优点是几乎每个 RDBMS 都支持事务。事务由作为单个工作单元按顺序执行的一个或多个单独的 SQL 语句组成。事务呈现全有或全无的方法，这意味着事务中的每个 SQL 语句都必须有效；否则，整个事务将失败。这对于在对多个行或表进行更改时确保数据完整性非常有帮助。

最后，关系数据库非常灵活。它们已被用于构建各种不同的应用程序，并且即使处理大量数据也能继续高效工作。 SQL 也非常强大，允许您动态添加和更改数据，以及更改数据库模式和表的结构，而不会影响现有数据。

结论

由于其灵活性和数据完整性设计，关系数据库在最初构思 50 多年后仍然是管理和存储数据的主要方式。即使近年来各种 NoSQL 数据库兴起，了解关系模型以及如何使用 RDBMS 对任何想要构建利用数据力量的应用程序的人来说都是关键。

要了解有关一些流行的开源 RDBMS 的更多信息，我们鼓励您查看我们对各种开源关系 SQL 数据库的比较。如果您有兴趣了解有关数据库的更多信息，我们鼓励您查看我们完整的数据库相关内容库。