关系数据库模型：元素，操作方法，示例 - 技术 - 2025

在关系数据库模型是使用关系，使用格状结构，由行和列的结构化数据的方法。这是关系数据库的概念原理。它是由Edgar F. Codd在1969年提出的。

与其他数据库模型（例如层次结构，网络和对象）相比，它已成为业务应用程序的主要数据库模型。

资料来源：foto.com

Codd不知道他作为关系数据库平台的工作将有多么重要和影响力。大多数人都非常熟悉数据库中关系的物理表达：表格。

关系模型被定义为数据库，该数据库允许将其数据元素分组在一个或多个独立的表中，这些表可以通过使用每个相关表的公用字段相互关联。

数据库管理

数据库表类似于电子表格。但是，可以在表之间创建的关系允许关系数据库有效地存储大量数据，可以有效地检索这些数据。

关系模型的目的是提供一种用于指定数据和查询的声明性方法：用户直接声明数据库包含哪些信息以及他们想要从中获得什么信息。

另一方面，他们将其留给数据库管理系统软件来描述用于存储的数据结构以及用于回答查询的检索过程。

大多数关系数据库使用SQL语言查询和定义数据。当前，有许多关系数据库管理系统或RDBMS（关系数据库管理系统），例如Oracle，IBM DB2和Microsoft SQL Server。

特征和要素

-所有数据在概念上均表示为行和列中数据的有序排列，称为关系或表。

-每个表必须具有标题和正文。标头只是列的列表。主体是填充表的数据集，按行组织。

-所有值都是标量。也就是说，在表中任何给定的行/列位置，都只有一个值。

-元素

下图显示了一个表格，其中包含其基本元素的名称，这些元素构成了完整的结构。

元组

数据的每一行都是一个元组，也称为记录。每行是一个n元组，但是通常会丢弃“ n-”。

柱

元组中的每一列称为属性或字段。该列表示特定属性可以具有的一组值。

键

每一行都有一个或多个列，称为表键。该组合值对于表中的所有行都是唯一的。通过该键，每个元组将被唯一标识。即，密钥不能重复。它称为主键。

另一方面，外键或辅助键是表中的字段，它引用某个其他表的主键。它用于引用主表。

-诚信原则

在设计关系模型时，您定义了数据库中必须满足的一些条件，称为完整性规则。

密钥完整性

对于所有元组，主键必须唯一，并且不能为null（NULL）。否则，您将无法唯一标识该行。

对于多列键，这些列均不能包含NULL。

参照完整性

外键的每个值都必须与引用表或主表的主键的值匹配。

具有主键的行只能在主表中存在该值的情况下插入到辅助表中。

如果由于更新或删除了行而导致主表中键的值发生更改，则应相应地更新或删除具有该外键的辅助表中的所有行。

如何建立关系模型？

-收集数据

必须收集必要的数据才能存储在数据库中。这些数据分为不同的表。

必须为每一列选择适当的数据类型。例如：整数，浮点数，文本，日期等。

-定义主键

对于每个表，必须选择一列（或几列）作为主键，它将唯一地标识表中的每一行。主键还用于引用其他表。

-在表之间创建关系

由独立的，不相关的表组成的数据库几乎没有用。

设计关系数据库中最关键的方面是识别表之间的关系。关系类型为：

一对多

在“班级列表”数据库中，一位老师可以教零个或多个班级，而一个班级则由一位老师教。这种关系称为一对多。

此关系不能在单个表中表示。在“班级列表”数据库中，可以有一个名为“教师”的表，该表存储有关教师的信息。

要存储每个老师讲授的课程，您可以创建其他列，但是会遇到一个问题：要创建多少列。

另一方面，如果您有一个名为Classes的表，用于存储有关班级的信息，则可以创建其他列来存储有关教师的信息。

但是，由于老师可以教很多班，因此他的数据将在“班级”表的许多行中重复。

设计两张桌子

因此，您需要设计两个表：一个Classes表，用于存储有关班级的信息（以Class_Id作为主键），以及Teachers表，以存储有关教师的信息，以Teacher_Id作为主键。

然后，可以通过将主表（Master_Id）中的主键存储在“类”表中来创建一对多关系，如下所示。

Classes表中的Master_Id列称为外键或辅助键。

对于主表中的每个Master_Id值，“类”表中可以有零行或更多行。对于“班级”表中的每个Class_Id值，“教师”表中只有一行。

多对多

在“产品销售”数据库中，客户订单可以包含多个产品，并且一个产品可以出现在多个订单中。这种关系是众所周知的。

您可以使用两个表启动“产品销售”数据库：产品和订单。产品表包含有关产品的信息，其中productID为主键。

另一方面，Orders表包含客户的订单，其中orderID为主键。

您无法将订购的产品存储在Orders表中，因为您不知道要为产品保留多少列。出于相同的原因，订单也不能存储在Products表中。

为了支持多对多关系，您需要创建第三个表，称为联接表（OrderDetails），其中每一行代表特定顺序的项目。

对于OrderDetails表，主键由两列组成：orderID和productID，它们唯一地标识每一行。

OrderDetails表中的orderID和productID列用于引用Orders和Products表。因此，它们也是OrderDetails表中的外键。

逐个

在“产品销售”数据库中，产品可以具有可选信息，例如附加说明及其图像。将其保留在Products表中会产生很多空白。

因此，可以创建另一个表（ProductExtras）来存储可选数据。对于带有可选数据的产品，只会创建一个记录。

两个表Products和ProductExtras具有一对一的关系。对于“产品”表中的每一行，在“ ProductExtras”表中最多有一行。必须将相同的productID用作两个表的主键。

优点

结构独立

在关系数据库模型中，对数据库结构的更改不会影响对数据的访问。

当可以在不影响DBMS访问数据的能力的情况下更改数据库的结构时，可以说已经实现了结构独立性。

概念简单

关系数据库模型在概念上比分层或网络数据库模型更简单。

由于关系数据库模型使设计人员摆脱了数据物理存储的细节，因此设计人员可以专注于数据库的逻辑视图。

易于设计，实施，维护和使用

关系数据库模型实现了数据独立性和结构独立性，这使得数据库的设计，维护，管理和使用比其他模型容易得多。

临时查询容量

非常强大，灵活和易于使用的查询功能的存在是关系数据库模型广受欢迎的主要原因之一。

关系数据库模型的查询语言称为结构化查询语言或SQL，使临时查询成为现实。SQL是第四代语言（4GL）。

4GL允许用户指定应执行的操作，而无需指定应如何执行。因此，使用SQL，用户可以指定他们想要的信息，并将如何获取信息的细节留给数据库。

缺点

硬件支出

关系数据库模型隐藏了其实现的复杂性以及用户数据的物理存储细节。

为此，关系数据库系统需要具有更强大硬件和数据存储设备的计算机。

因此，RDBMS需要功能强大的机器才能平稳运行。但是，随着现代计算机的处理能力呈指数级增长，在当今的情况下，对更多处理能力的需求不再是一个大问题。

易于设计会导致设计不佳

关系数据库易于设计和使用。用户无需了解数据物理存储的复杂细节。他们不需要知道如何实际存储数据来访问它。

设计和使用的这种简便性可能导致开发和实施设计不良的数据库管理系统。因为数据库是有效的，所以在设计数据库时以及只有少量数据时，这些设计的低效率将不会暴露出来。

随着数据库的增长，设计不良的数据库将降低系统速度，并导致性能下降和数据损坏。

“信息岛”现象

如前所述，关系数据库系统易于实现和使用。这将造成一种情况，即太多的人或部门将创建自己的数据库和应用程序。

这些信息孤岛将阻止信息集成，这对于组织的平稳高效运行至关重要。

这些单独的数据库还会产生诸如数据不一致，数据重复，数据冗余等问题。

例

假设一个数据库由“供应商”，“零件”和“发货”表组成。表的结构和一些示例记录如下：

供应商表中的每一行都由唯一的供应商编号（SNo）标识，从而唯一地标识表中的每一行。同样，每个零件都有唯一的零件号（PNo）。

此外，“货件”表中给定的“供应商/零件”组合最多只能有一个货件，因为这种组合是“货件”的主键，它是一个联合表，因为它是多对多关系。

零件和出货表之间的关系是通过共用字段PNo（零件编号）来给出的，而供应商和出货之间的关系是通过共用SNo字段（供应商编号）来产生的。

通过分析“发货”表，可以了解到，Suneet和Ankit供应商总共发送了500个螺母，每个250个。

同样，从三个不同的供应商那里总共装运了1,100个螺栓。Suneet供应商提供了500颗蓝色螺钉。没有红色螺钉的发货。

参考文献

1. 维基百科，免费百科全书（2019）。关系模型。摘自：en.wikipedia.org。
2. Techopedia（2019）。关系模型。摘自：ceilingpedia.com。
3. 迪内什·塔库（Dinesh Thakur）（2019）。关系模型。电子计算机说明。摘自：ecomputernotes.com。
4. Geeks for Geeks（2019）。关系模型。摘自：geeksforgeeks.org。
5. 南洋理工大学（2019）。关系数据库设计快速入门教程。摘自：ntu.edu.sg。
6. 艾德丽安·瓦特（Adrienne Watt）（2019）。第7章关系数据模型。卑诗省公开课本。取自：opentextbc.ca。
7. Toppr（2019）。关系数据库和架构。摘自：toppr.com。