理解关系型数据库(Relational Database)

卡拉先生
发布于 2020年08月22日 | 上次编辑:2020年08月24日

卡拉搜索:一行代码即可快速部署「站内搜索」功能:点这里了解更多

理解关系型数据库
理解关系型数据库

简介

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

为了执行以上这些操作,DBMS 必须具有某种定义数据组织方式的底层模型。关系模型是一种组织数据的方法,自 20 世纪 60 年代末首次被设计以来,在数据库软件得到了广泛的应用,以至于在撰写本文时,五个最流行的数据库管理系统有四个是关系型的。

本文概述了关系型数据库的的历史,以及关系型数据库如何组织数据、使用数据。

关系模型的历史

数据库是逻辑建模的信息或数据群集。任何数据的集合都是一个数据库,不管它是如何存储的,也不管它存储在哪里。即使是包含工资单信息的文件柜也是一个数据库,就像一叠医院患者的表格,或者公司跨多个位置收集的客户信息一样。在使用计算机存储和管理数据之前,这样的物理数据库是政府和商业组织唯一需要存储信息的数据库。

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

然而,对于计算机如何以有意义、合乎逻辑的方式组织数据,并没有任何理论。在计算机上存储未排序的数据是一回事,但设计一个允许用户以一致、实用的方式添加、检索、排序和以其他方式管理这些数据的系统则要复杂得多。由于需要一个用于存储和组织数据的逻辑框架,因此计算机科学家提出了许多的如何利用计算机进行数据管理的建议。

早期的数据库模型是分层模型,其中数据以树状结构组织,类似于现代的文件系统。下面的例子描述了用于动物分类的分层数据库的布局:

早期的数据库模型是分层模型
早期的数据库模型是分层模型

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

20世纪60年代末,在 IBM 工作的计算机科学家埃德加·科德 (Edgar F. Codd) 设计了数据库管理的关系模型。Codd 的关系模型允许单个记录与多个表关联,从而在数据点之间实现了"多对多"以及"一对多"关系。这在设计数据库结构方面提供了比其它的现有模型更大的灵活性,意味着关系数据库管理系统(RDBMS)可以满足更广泛的业务需求。

Codd 提出了一种用于管理关系数据的语言 Alpha,其影响了后来数据库语言的发展。科德在IBM的两位同事唐纳德·钱伯林 (Donald Chamberlin) 和雷蒙德·博伊斯 (Raymond Boyce) 受 Alpha 语言的启发创造了一种新的语言。他们称之为 "SEQUEL",是 Structured English Query Language 的简称。但由于要规避现有商标,于是称为 SQL(更正式地称为 Structured Query Language)。

由于硬件限制,早期的关系数据库令人难以忍受的缓慢,而且技术的广泛普及需要一定的时间。但到 20 世纪 80 年代中期,Codd 的关系模型已经在 IBM 及其竞争对手的商业数据库管理产品中实现。这些供应商也跟随 IBM 的脚步,开发并实现了他们自己的 SQL 语言。到 1987 年,美国国家标准协会和国际标准化组织都批准并发布了 SQL 标准,巩固了其作为管理 RDBMS 语言的公认地位。

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

关系数据库如何组织数据

现在,你已经对关系模型的历史有了大致的了解,接下来让我们看看模型是如何组织数据的。

关系模型中最基本的元素是关系,用户和现代关系数据库管理系统都将关系视为表。关系是一组元组或表中的行,每个元组共享一组属性或列:

关系模型中最基本的元素是关系
关系模型中最基本的元素是关系

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

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

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

如果你有两个要关联的表,一种方法是使用外键。外键本质上是一个表(“父”表)主键的副本,插入到另一个表(“子”表)的列中。下面的示例突出显示两个表之间的关系,一个用于记录公司员工的信息,另一个用于跟踪公司的销售额。在本例中,EMPLOYEES的主键用作 SALES 的外键:

父子表之间的关系
父子表之间的关系

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

关系模型的结构元素有助于以有组织的方式存储数据,但是只有当你能够检索数据时,存储数据才是有用的。若要从 RDBMS 检索信息,可以发出查询或一组信息的结构化请求。如前所述,大多数关系数据库使用 SQL 来管理和查询数据。SQL 允许你使用各种从句、谓语和表达式来筛选和操作查询结果,从而精细地控制哪些数据会出现在结果集中。

关系数据库的利弊

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

如今,无论是 SQL 还是实现它的数据库都在几个方面偏离了 Codd 的关系模型。例如,Codd 的模型规定表中的每一行都是唯一的,而出于实用性的原因,大多数现代关系数据库确实允许重复行。有些人认为 SQL 数据库不是真正的关系数据库,如果其不能遵守 Codd 关系模型的每个规范。然而,实际上任何使用 SQL 并且至少在某种程度上遵循关系模型的 DBMS 都可能被称为 RDBMS。

尽管关系数据库迅速普及,但随着数据变得越来越有价值,企业开始存储更多的数据。关系模型的一些缺点开始变得明显起来。首先,很难横向扩展关系数据库。水平扩展或横向扩展是将更多计算机添加到现有堆栈,以分散负载并允许更多流量和更快的处理操作。这通常与垂直扩展形成对比,垂直扩展涉及升级现有服务器的硬件,通常是增加更多的 RAM 或 CPU。

很难横向扩展关系数据库的原因在于,关系模型是为了确保一致性而设计的。这意味着查询同一个数据库的客户端总是会检索相同的数据。如果要在多台机器上横向扩展关系数据库,则很难确保一致性,因为客户端可能会将数据写入一个节点,而不会写入其他节点。在初始写入节点和更新其他节点以反映变动的这段时间可能会有延迟,从而导致它们之间的不一致。

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

这并不是说关系数据库没有用处。恰恰相反,关系模型在四十多年后仍然是数据管理的主要框架。其流行和寿命意味着关系数据库是一种成熟的技术,这本身就是它们的主要优势之一。有许多应用程序是为关系模型设计的,也有许多的职业数据库管理员是关系数据库方面的专家。对于那些想要开始使用关系数据库的人来说,还有大量的印刷和在线的资源。

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

最后,关系数据库非常灵活。它们已用于构建各种不同的应用程序,即使有大量的数据也能够继续高效工作。SQL 也非常强大,允许你在不影响现有数据的情况下添加和更改数据,以及更改数据库架构和表的结构。

结论

由于其灵活性和数据完整性设计,在首次构思五十多年后关系数据库仍然是数据管理和存储的主要方式。即使近年来各种 NoSQL 数据库的兴起,理解关系模型以及如何使用 RDBMS 对于任何想要构建利用数据功能的应用程序的人来说都是至关重要的。

要了解一些流行的开源 RDBMS 的信息,你可以查看我们对各种开源关系数据库的比较。如果想了解更多数据库相关信息,也可访问卡拉搜索技术社区

扩展阅读:

数据库 系列教程

友情链接更新日志© 2020, 卡拉搜索, Built with ❤️ in San Francisco + Beijing

京ICP备15049164号-3