数据库管理系统 - 快速指南

数据库管理系统 - 概述

数据库是相关数据的集合，数据是可以处理以产生信息的事实和数字的集合。

大多数数据代表可记录的事实。数据有助于产生基于事实的信息。例如，如果我们有关于所有学生获得的分数的数据，那么我们就可以得出关于最高分和平均分的结论。

数据库管理系统存储数据的方式使得检索、操作和生成信息变得更加容易。

特征

传统上，数据以文件格式组织。DBMS 在当时是一个新概念，所有的研究都是为了使其克服传统数据管理方式的不足。现代 DBMS 具有以下特征 -

• 现实世界的实体- 现代 DBMS 更加现实，并使用现实世界的实体来设计其架构。它也使用行为和属性。例如，学校数据库可以使用学生作为实体，并将他们的年龄作为属性。

• 基于关系的表- DBMS 允许实体和它们之间的关系形成表。用户可以通过查看表名来了解数据库的体系结构。

• 数据和应用程序的隔离- 数据库系统与其数据完全不同。数据库是一个主动的实体，而数据被认为是被动的，数据库在其上工作和组织。DBMS 还存储元数据，即关于数据的数据，以简化其自身的过程。

• Less redundancy - DBMS 遵循规范化规则，当它的任何属性在值上具有冗余时，它会拆分关系。归一化是一个数学上丰富且科学的过程，可以减少数据冗余。

• Consistency - 一致性是数据库中每个关系保持一致的状态。存在可以检测使数据库处于不一致状态的尝试的方法和技术。与文件处理系统等早期形式的数据存储应用程序相比，DBMS 可以提供更高的一致性。

• 查询语言- DBMS 配备了查询语言，可以更有效地检索和操作数据。用户可以根据需要应用尽可能多和不同的过滤选项来检索一组数据。传统上不可能使用文件处理系统。

• ACID 属性- DBMS 遵循原子性、一致性、隔离性和耐久性（通常简称为 ACID）的概念。这些概念适用于处理数据库中数据的事务。ACID 属性帮助数据库在多事务环境中和出现故障时保持健康。

• 多用户和并发访问- DBMS 支持多用户环境并允许他们并行访问和操作数据。虽然当用户试图处理同一个数据项时对事务有限制，但用户总是意识不到它们。

• 多个视图- DBMS 为不同的用户提供多个视图。销售部门的用户与生产部门的用户对数据库的看法不同。此功能使用户能够根据他们的要求集中查看数据库。

• 安全性- 多个视图等功能在某种程度上提供了安全性，用户无法访问其他用户和部门的数据。DBMS 提供了在将数据输入数据库并在稍后阶段检索数据时施加约束的方法。DBMS 提供了许多不同级别的安全功能，使多个用户可以拥有具有不同功能的不同视图。例如，销售部门的用户无法看到属于采购部门的数据。此外，还可以管理应该向用户显示多少销售部门的数据。由于 DBMS 不像传统的文件系统那样保存在磁盘上，因此不法分子很难破解代码。

用户

典型的 DBMS 具有不同的权限和权限的用户，他们将其用于不同的目的。一些用户检索数据，一些用户备份数据。DBMS 的用户可以大致分为以下几类 -

• 管理员- 管理员维护 DBMS 并负责管理数据库。他们负责管理它的使用以及应该由谁使用。他们为用户创建访问配置文件并应用限制以保持隔离和强制安全。管理员还负责管理 DBMS 资源，如系统许可证、所需工具以及其他与软件和硬件相关的维护。

• 设计师- 设计师是实际从事数据库设计部分工作的一群人。他们密切关注应该保存哪些数据以及以何种格式保存。他们识别和设计整套实体、关系、约束和视图。

• 最终用户- 最终用户是那些真正从拥有 DBMS 中获益的人。最终用户的范围可以从关注日志或市场价格的简单查看者到业务分析师等复杂用户。

数据库管理系统 - 架构

DBMS 的设计取决于其体系结构。它可以是集中的、分散的或分层的。DBMS 的体系结构可以被视为单层或多层。n 层体系结构将整个系统划分为相关但独立的n 个模块，这些模块可以独立修改、更改、更改或替换。

在一层架构中，DBMS 是用户直接坐在 DBMS 上并使用它的唯一实体。此处所做的任何更改都将直接在 DBMS 本身上完成。它不为最终用户提供方便的工具。数据库设计人员和程序员通常更喜欢使用单层架构。

如果 DBMS 的体系结构是 2 层的，那么它必须有一个可以访问 DBMS 的应用程序。程序员使用 2 层架构，他们通过应用程序访问 DBMS。在这里，应用层在操作、设计和编程方面完全独立于数据库。

三层架构

3 层架构根据用户的复杂程度以及他们如何使用数据库中存在的数据将其层级彼此分开。它是设计 DBMS 时使用最广泛的架构。

• 数据库（数据）层- 在此层，数据库与其查询处理语言一起驻留。我们还具有定义数据的关系及其在此级别的约束。

• 应用程序（中间）层- 在这一层驻留应用程序服务器和访问数据库的程序。对于用户，此应用程序层呈现数据库的抽象视图。最终用户不知道应用程序之外的任何数据库存在。在另一端，数据库层不知道应用层之外的任何其他用户。因此，应用层位于中间，充当最终用户和数据库之间的中介。

• User (Presentation) Tier - 最终用户在这一层操作，他们对这一层之外的数据库的存在一无所知。在这一层，应用程序可以提供数据库的多个视图。所有视图均由驻留在应用程序层中的应用程序生成。

多层数据库体系结构是高度可修改的，因为它的几乎所有组件都是独立的并且可以独立更改。

DBMS - 数据模型

数据模型定义了数据库的逻辑结构是如何建模的。数据模型是在 DBMS 中引入抽象的基本实体。数据模型定义数据如何相互连接以及如何在系统内处理和存储数据。

第一个数据模型可以是平面数据模型，其中使用的所有数据都将保存在同一平面中。早期的数据模型不是很科学，因此很容易引入大量重复和更新异常。

实体关系模型

实体关系 (ER) 模型基于现实世界实体及其之间关系的概念。ER 模型在将现实世界的场景制定到数据库模型中时，创建了实体集、关系集、一般属性和约束。

ER 模型最适合用于数据库的概念设计。

ER 模型基于 -

• 实体及其属性。

• 实体之间的关系。

这些概念解释如下。

• 实体- ER 模型中的实体是具有称为属性的属性的真实世界实体。每个属性都由其称为域的值集定义。例如，在学校数据库中，学生被视为一个实体。学生有各种属性，如姓名、年龄、班级等。

• 关系- 实体之间的逻辑关联称为关系。关系以各种方式映射到实体。映射基数定义两个实体之间的关联数。

  映射基数 -

  • 一对一
  • 一对多
  • 多对一
  • 多对多

关系模型

DBMS 中最流行的数据模型是关系模型。它是比其他模型更科学的模型。该模型基于一阶谓词逻辑并将表定义为n 元关系。

该模型的主要亮点是 -

• 数据存储在称为关系的表中。
• 关系可以正常化。
• 在规范化关系中，保存的值是原子值。
• 关系中的每一行都包含一个唯一值。
• 关系中的每一列都包含来自同一域的值。

DBMS - 数据模式

数据库架构

数据库模式是表示整个数据库的逻辑视图的骨架结构。它定义了数据的组织方式以及它们之间的关系如何关联。它制定了要应用于数据的所有约束。

数据库模式定义了它的实体和它们之间的关系。它包含数据库的描述性细节，可以通过模式图来描述。是数据库设计者设计模式来帮助程序员理解数据库并使之有用。

数据库模式可以大致分为两类 -

• Physical Database Schema - 该模式与数据的实际存储及其存储形式（如文件、索引等）有关​​。它定义了数据将如何存储在辅助存储中。

• 逻辑数据库模式- 该模式定义了需要应用于存储数据的所有逻辑约束。它定义表、视图和完整性约束。

数据库实例

重要的是我们要分别区分这两个术语。数据库模式是数据库的骨架。它是在数据库根本不存在时设计的。一旦数据库可以运行，就很难对其进行任何更改。数据库模式不包含任何数据或信息。

数据库实例是在任何给定时间具有数据的操作数据库的状态。它包含数据库的快照。数据库实例往往会随时间变化。DBMS 通过认真遵循数据库设计者强加的所有验证、约束和条件，确保其每个实例（状态）都处于有效状态。

DBMS - 数据独立性

如果数据库系统不是多层的，那么就很难对数据库系统进行任何更改。正如我们之前了解到的，数据库系统是多层设计的。

数据独立

数据库系统除了用户数据外，通常还包含大量数据。例如，它存储有关数据的数据（称为元数据），以便轻松定位和检索数据。一旦元数据存储在数据库中，就很难对其进行修改或更新。但是随着 DBMS 的扩展，它需要随着时间的推移而改变以满足用户的需求。如果整个数据都是依赖的，这将成为一项繁琐且高度复杂的工作。

元数据本身遵循分层架构，因此当我们更改某一层的数据时，不会影响另一层的数据。这些数据是独立的，但相互映射。

逻辑数据独立性

逻辑数据是关于数据库的数据，即存储了数据内部如何管理的信息。例如，存储在数据库中的表（关系）及其所有约束都应用于该关系。

逻辑数据独立性是一种机制，它从存储在磁盘上的实际数据中解放出来。如果我们对表格式进行一些更改，它不应该更改驻留在磁盘上的数据。

物理数据独立性

所有的模式都是逻辑的，实际数据以位格式存储在磁盘上。物理数据独立性是在不影响模式或逻辑数据的情况下更改物理数据的能力。

例如，如果我们想要更改或升级存储系统本身——假设我们想用 SSD 替换硬盘——它不应该对逻辑数据或模式有任何影响。

ER 模型 - 基本概念

ER 模型定义了数据库的概念视图。它围绕现实世界的实体和它们之间的关联工作。在视图级别，ER 模型被认为是设计数据库的不错选择。

实体

实体可以是现实世界的对象，可以是有生命的也可以是无生命的，可以很容易地识别。例如，在学校数据库中，学生、教师、班级和所提供的课程都可以被视为实体。所有这些实体都有一些赋予它们身份的属性或特性。

实体集是相似类型实体的集合。实体集可能包含具有共享相似值的属性的实体。例如，一个 Students 集合可能包含一所学校的所有学生；同样，教师集可能包含一所学校所有院系的所有教师。实体集不需要不相交。

属性

实体通过它们的属性来表示，称为属性。所有属性都有值。例如，学生实体可能具有姓名、班级和年龄作为属性。

存在可以分配给属性的值域或值范围。例如，学生的姓名不能是数值。它必须是字母顺序的。学生的年龄不能为负数等。

属性类型

• 简单属性- 简单属性是原子值，不能进一步划分。例如，学生的电话号码是10位数字的原子值。

• Composite attribute - 复合属性由多个简单属性组成。例如，学生的全名可能有 first_name 和 last_name。

• 派生属性- 派生属性是物理数据库中不存在的属性，但它们的值是从数据库中存在的其他属性派生的。比如一个部门的average_salary不应该直接保存在数据库中，而是可以推导出来。再例如，年龄可以从 data_of_birth 中导出。

• 单值属性- 单值属性包含单个值。例如 - Social_Security_Number。

• 多值属性- 多值属性可能包含多个值。例如，一个人可以有多个电话号码、电子邮件地址等。

这些属性类型可以像这样的方式组合在一起 -

• 简单的单值属性
• 简单的多值属性
• 复合单值属性
• 复合多值属性

实体集和键

键是在实体集中唯一标识一个实体的一个属性或属性集合。

例如，学生的 roll_number 使他/她在学生中可以被识别。

• Super Key - 一组属性（一个或多个）共同标识实体集中的实体。

• Candidate Key - 最小的超级密钥称为候选密钥。一个实体集可能有多个候选键。

• Primary Key - 主键是数据库设计者选择的候选键之一，用于唯一标识实体集。

关系

实体之间的关联称为关系。例如，一名员工在一个部门工作，一名学生注册了一门课程。在这里，Works_at 和 Enrolls 被称为关系。

关系集

一组相似类型的关系称为关系集。与实体一样，关系也可以具有属性。这些属性称为描述性属性。

关系度

关系中参与实体的数量定义了关系的程度。

• 二进制 = 度数 2
• 三元 = 3 度
• n元=度

映射基数

基数定义了一个实体集中的实体数量，它可以通过关系集与另一组实体的数量相关联。

• 一对一- 实体集 A 中的一个实体最多可以与实体集 B 中的一个实体相关联，反之亦然。

• 一对多- 实体集 A 中的一个实体可以与实体集 B 中的多个实体相关联，但是实体集 B 中的实体最多可以与一个实体相关联。

• 多对一- 实体集 A 中的多个实体最多可以与实体集 B 中的一个实体相关联，但是实体集 B 中的实体可以与实体集 A 中的多个实体相关联。

• 多对多- 来自 A 的一个实体可以与来自 B 的多个实体相关联，反之亦然。

ER图表示

现在让我们了解如何通过 ER 图表示 ER 模型。任何对象，例如实体、实体的属性、关系集和关系集的属性，都可以借助 ER 图来表示。

实体

实体用矩形表示。矩形以它们代表的实体集命名。

属性

属性是实体的特性。属性用省略号表示。每个椭圆代表一个属性并直接连接到它的实体（矩形）。

如果属性是复合的，它们将进一步划分为树状结构。然后每个节点都连接到它的属性。也就是说，复合属性由与椭圆相连的椭圆表示。

多值属性用双椭圆表示。

派生属性由虚线椭圆表示。

关系

关系由菱形框表示。关系的名称写在菱形框内。参与关系的所有实体（矩形）都通过一条线连接到它。

二元关系和基数

两个实体参与的关系称为二元关系。基数是关系中可以与该关系相关联的实体实例的数量。

• 一对一- 当只有一个实体的实例与关系相关联时，它被标记为“1:1”。下图反映了每个实体只有一个实例应该与该关系相关联。它描述了一对一的关系。

• 一对多- 当一个实体的多个实例与一种关系相关联时，它被标记为“1:N”。下图反映了只有左侧实体的一个实例和右侧实体的多个实例可以与关系相关联。它描述了一对多的关系。

• 多对一- 当多个实体实例与关系关联时，它被标记为“N:1”。下图反映了左侧实体的多个实例和右侧实体的唯一实例可以与关系关联。它描述了多对一的关系。

• 多对多- 下图反映了左侧实体的多个实例和右侧实体的多个实例可以与关系相关联。它描述了多对多的关系。

参与限制

• Total Participation - 每个实体都参与关系。总参与度用双线表示。

• 部分参与- 并非所有实体都参与关系。部分参与由单线表示。

泛化聚合

现在让我们了解如何通过 ER 图表示 ER 模型。任何对象，例如实体、实体的属性、关系集和关系集的属性，都可以借助 ER 图来表示。

实体

实体用矩形表示。矩形以它们代表的实体集命名。

属性

属性是实体的特性。属性用省略号表示。每个椭圆代表一个属性并直接连接到它的实体（矩形）。

如果属性是复合的，它们将进一步划分为树状结构。然后每个节点都连接到它的属性。也就是说，复合属性由与椭圆相连的椭圆表示。

多值属性用双椭圆表示。

派生属性由虚线椭圆表示。

关系

关系由菱形框表示。关系的名称写在菱形框内。参与关系的所有实体（矩形）都通过一条线连接到它。

二元关系和基数

两个实体参与的关系称为二元关系。基数是关系中可以与该关系相关联的实体实例的数量。

• 一对一- 当只有一个实体的实例与关系相关联时，它被标记为“1:1”。下图反映了每个实体只有一个实例应该与该关系相关联。它描述了一对一的关系。

• 一对多- 当一个实体的多个实例与一种关系相关联时，它被标记为“1:N”。下图反映了只有左侧实体的一个实例和右侧实体的多个实例可以与关系相关联。它描述了一对多的关系。

• 多对一- 当多个实体实例与关系关联时，它被标记为“N:1”。下图反映了左侧实体的多个实例和右侧实体的唯一实例可以与关系关联。它描述了多对一的关系。

• 多对多- 下图反映了左侧实体的多个实例和右侧实体的多个实例可以与关系相关联。它描述了多对多的关系。

参与限制

• Total Participation - 每个实体都参与关系。总参与度用双线表示。

• 部分参与- 并非所有实体都参与关系。部分参与由单线表示。

泛化聚合

ER 模型具有以概念层次方式表达数据库实体的能力。随着层次结构的上升，它概括了实体的视图，当我们深入层次结构时，它为我们提供了包含的每个实体的细节。

在这种结构中向上发展称为泛化，其中实体组合在一起以表示更泛化的视图。例如，可以将名为 Mira 的特定学生与所有学生一起概括。该实体为学生，进一步地，该学生为人。反过来称为专业化，其中一个人是学生，那个学生是米拉。

概括

如上所述，泛化实体的过程，其中泛化实体包含所有泛化实体的属性，称为泛化。在泛化中，许多实体根据它们的相似特征被归为一个泛化实体。例如，鸽子、麻雀、乌鸦、鸽子都可以归纳为鸟类。

专业化

专业化与泛化相反。在专业化中，一组实体根据其特征分为子组。以一组“人”为例。一个人有姓名、出生日期、性别等。这些属性是所有人、人类共有的。但在公司中，可以根据人员在公司中扮演的角色将其识别为雇员、雇主、客户或供应商。

类似地，在学校数据库中，可以根据人员在学校中作为实体所扮演的角色，将人员专门化为教师、学生或职员。

遗产

我们使用 ER-Model 的所有上述功能，以便在面向对象编程中创建对象类。实体的细节通常对用户隐藏；这个过程称为抽象。

继承是泛化和特化的一个重要特征。它允许较低级别的实体继承较高级别实体的属性。

例如，Person 类的属性（如姓名、年龄和性别）可以由较低级别的实体（如 Student 或 Teacher）继承。

科德的 12 条规则

Edgar F. Codd 博士在对数据库系统的关系模型进行了广泛的研究之后，提出了自己的十二条规则，根据他的说法，数据库必须遵守这些规则才能被视为真正的关系数据库。

这些规则可以应用于任何仅使用其关系功能来管理存储数据的数据库系统。这是一个基础规则，它是所有其他规则的基础。

规则 1：信息规则

存储在数据库中的数据，可能是用户数据或元数据，必须是某个表格单元格的值。数据库中的所有内容都必须以表格格式存储。

规则 2：保证访问规则

通过表名、主键（行值）和属性名（列值）的组合，保证每个数据元素（值）在逻辑上是可访问的。不能使用其他方式（例如指针）来访问数据。

规则 3：NULL 值的系统处理

必须对数据库中的 NULL 值进行系统和统一的处理。这是一个非常重要的规则，因为 NULL 可以解释为以下之一 - 数据丢失、数据未知或数据不适用。

规则 4：活跃的在线目录

整个数据库的结构描述必须存储在一个在线目录中，称为数据字典，授权用户可以访问该目录。用户可以使用相同的查询语言来访问他们用来访问数据库本身的目录。

规则五：综合数据分语言规则

只能使用具有支持数据定义、数据操作和事务管理操作的线性语法的语言来访问数据库。这种语言可以直接使用，也可以通过某些应用程序使用。如果数据库允许在没有这种语言的任何帮助的情况下访问数据，那么它被认为是违规的。

规则 6：查看更新规则

理论上可以更新的数据库的所有视图也必须可以被系统更新。

规则 7：高级插入、更新和删除规则

数据库必须支持高级插入、更新和删除。这不能仅限于单行，也就是说，它还必须支持联合、交集和减法运算以产生数据记录集。

规则 8：物理数据独立性

存储在数据库中的数据必须独立于访问数据库的应用程序。数据库物理结构的任何变化都不得对外部应用程序访问数据的方式产生任何影响。

规则 9：逻辑数据独立性

数据库中的逻辑数据必须独立于其用户视图（应用程序）。逻辑数据的任何更改都不得影响使用它的应用程序。例如，如果合并两个表或将一个表拆分为两个不同的表，则对用户应用程序应该没有影响或更改。这是最难应用的规则之一。

规则 10：诚信独立

数据库必须独立于使用它的应用程序。它的所有完整性约束都可以独立修改，而不需要对应用程序进行任何更改。此规则使数据库独立于前端应用程序及其界面。

规则 11：分发独立性

最终用户不能看到数据分布在不同的位置。用户应该始终得到数据仅位于一个站点的印象。这条规则被认为是分布式数据库系统的基础。

规则 12：非颠覆规则

如果系统具有提供对低级别记录的访问的接口，则该接口不能破坏系统并绕过安全性和完整性约束。

关系数据模型

关系数据模型是主要的数据模型，在世界范围内被广泛用于数据存储和处理。该模型很简单，并且具有以存储效率处理数据所需的所有属性和功能。

概念

表- 在关系数据模型中，关系以表的格式保存。这种格式存储实体之间的关系。表有行和列，其中行代表记录，列代表属性。

元组- 表的单行，其中包含该关系的单个记录称为元组。

关系实例- 关系数据库系统中的一组有限元组表示关系实例。关系实例没有重复的元组。

关系模式- 关系模式描述关系名称（表名）、属性及其名称。

关系键- 每行都有一个或多个属性，称为关系键，可以唯一标识关系（表）中的行。

属性域- 每个属性都有一些预定义的值范围，称为属性域。

约束条件

每个关系都有一些必须满足的条件才能成为有效关系。这些条件称为关系完整性约束。存在三个主要的完整性约束 -

• 关键约束
• 域约束
• 参照完整性约束

关键约束

关系中必须至少有一个属性的最小子集，它可以唯一标识一个元组。这个最小的属性子集称为该关系的键。如果存在多个这样的最小子集，则这些子集称为候选键。

关键约束迫使 -

• 在与键属性的关系中，没有两个元组可以具有相同的键属性值。

• 键属性不能有 NULL 值。

键约束也称为实体约束。

域约束

属性在现实场景中具有特定的值。例如，年龄只能是正整数。已经尝试在关系的属性上使用相同的约束。每个属性都必然具有特定范围的值。例如，年龄不能小于零，电话号码不能包含 0-9 以外的数字。

参照完整性约束

参照完整性约束适用于外键的概念。外键是关系的关键属性，可以在其他关系中引用。

引用完整性约束指出，如果一个关系引用不同或相同关系的关键属性，则该关键元素必须存在。

关系代数

关系数据库系统有望配备一种查询语言，可以帮助其用户查询数据库实例。有两种查询语言——关系代数和关系演算。

关系代数

关系代数是一种过程查询语言，它将关系实例作为输入并产生关系实例作为输出。它使用运算符来执行查询。运算符可以是一元的或二元的。他们接受关系作为输入，并接受关系作为输出。关系代数是在关系上递归执行的，中间结果也被认为是关系。

关系代数的基本运算如下 -

• 选择
• 项目
• 联盟
• 设置不同
• 笛卡尔积
• 改名

我们将在以下部分讨论所有这些操作。

选择操作 (σ)

它从关系中选择满足给定谓词的元组。

符号- σ p (r)

其中σ代表选择谓词，r代表关系。p是介词逻辑公式，可以使用and、or、not等连接符。这些术语可能使用关系运算符，如 − =、≠、≥、<、>、≤。

例如-

σsubject="database"(Books)

Output - 从主题为“数据库”的书籍中选择元组。

σsubject="database" and price="450"(Books)

输出- 从主题为“数据库”且“价格”为 450 的书籍中选择元组。

σsubject="database" and price < "450" or year > "2010"(Books)

输出- 从主题为“数据库”且“价格”为 450 或 2010 年以后出版的书籍中选择元组。

项目运营（∠）

它投影满足给定谓词的列。

记法 − ‖ A 1 , A 2 , A n (r)

其中 A 1、 A 2、 A n是关系r的属性名称。

重复的行会被自动消除，因为关系是一个集合。

例如-

∏subject, author (Books)

从关系 Books 中选择并投影名为主题和作者的列。

联合运算(∪)

它在两个给定关系之间执行二元联合并定义为 -

r ∪ s = { t | t ∈ r or t ∈ s}

符号- r U s

其中r和s是数据库关系或关系结果集（临时关系）。

为了使联合操作有效，必须满足以下条件 -

• r和s必须具有相同数量的属性。
• 属性域必须兼容。
• 自动消除重复的元组。

∏ author (Books) ∪ ∏ author (Articles)

Output - 投射出写了一本书或一篇文章或两者的作者的姓名。

设置差异 (−)

集差运算的结果是元组，它存在于一个关系中，但不存在于第二个关系中。

符号- r - s

查找存在于r但不存在于s中的所有元组。

∏ author (Books) − ∏ author (Articles)

Output - 提供写过书但没有文章的作者姓名。

笛卡尔积 (X)

将两种不同关系的信息合并为一个。

记法− r X s

其中r和s是关系，它们的输出将定义为 -

r X s = { qt | q ∈ r 和 t ∈ s}

∏ author = 'tutorialspoint'(Books Χ Articles)

Output - 产生一个关系，显示由 tutorialspoint 撰写的所有书籍和文章。

重命名操作 (ρ)

关系代数的结果也是关系，但没有任何名称。重命名操作允许我们重命名输出关系。“重命名”操作用小写希腊字母rho ρ表示。

符号- ρ x (E)

其中表达式E的结果以x的名称保存。

额外的操作是 -

• 设置路口
• 任务
• 自然连接

关系演算

与关系代数相反，关系演算是一种非过程查询语言，也就是说，它告诉你做什么，但从不解释如何去做。

关系演算以两种形式存在 -

元组关系演算 (TRC)

过滤元组的变量范围

符号- {T | 健康）状况}

返回满足条件的所有元组 T。

例如-

<span style="color:#000000">{ T.name |  Author(T) AND T.article = 'database' }
</span>

输出- 从写过关于“数据库”的文章的作者那里返回带有“名称”的元组。

TRC 可以量化。我们可以使用存在量词 (∃) 和全称量词 (∀)。

例如-

<span style="color:#000000">{ R| ∃T   ∈ Authors(T.article='database' AND R.name=T.name)}
</span>

Output - 上述查询将产生与前一个相同的结果。

域关系演算 (DRC)

在 DRC 中，过滤变量使用属性域而不是整个元组值（正如在 TRC 中所做的，如上所述）。

符号-

{ 一个1 , 一个2 , 一个3 , ..., 一个n | P (a 1 , a 2 , a 3 , ... ,a n )}

其中a1、a2为属性，P代表由内部属性构建的公式。

例如-

{< article, page, subject > | ∈ TutorialsPoint ∧ subject = 'database'}

输出- 从关系 TutorialsPoint 中产生文章、页面和主题，其中主题是数据库。

就像 TRC 一样，DRC 也可以使用存在量词和全称量词来编写。DRC 还涉及关系运算符。

元组关系演算和域关系演算的表达能力相当于关系代数。

ER 模型到关系模型

ER 模型，当概念化为图表时，可以很好地概述实体关系，这更容易理解。ER图可以映射到关系模式，也就是说，可以使用ER图创建关系模式。我们不能将所有的 ER 约束导入关系模型，但可以生成一个近似的模式。

有多种过程和算法可用于将 ER 图转换为关系模式。其中一些是自动的，其中一些是手动的。我们可能会在这里关注映射图内容到关系基础知识。

ER图主要包括 -

• 实体及其属性
• 关系，即实体之间的关联。

映射实体

实体是具有某些属性的现实世界对象。

映射过程（算法）

• 为每个实体创建表。
• 实体的属性应该成为具有各自数据类型的表的字段。
• 声明主键。

映射关系

关系是实体之间的关联。

映射过程

• 为关系创建表。
• 将所有参与实体的主键添加为具有各自数据类型的表的字段。
• 如果关系有任何属性，将每个属性添加为表的字段。
• 声明一个主键，组成参与实体的所有主键。
• 声明所有外键约束。

映射弱实体集

弱实体集是指没有任何主键与之关联的实体集。

映射过程

• 为弱实体集创建表。
• 将其所有属性作为字段添加到表中。
• 添加标识实体集的主键。
• 声明所有外键约束。

映射分层实体

ER 专业化或泛化以分层实体集的形式出现。

映射过程

• 为所有更高级别的实体创建表。

• 为较低级别的实体创建表。

• 在下级实体表中添加上级实体的主键。

• 在较低级别的表中，添加较低级别实体的所有其他属性。

• 声明上级表的主键和下级表的主键。

• 声明外键约束。

概览

SQL 是一种用于关系数据库的编程语言。它是在关系代数和元组关系演算之上设计的。SQL 作为一个包出现在所有主要的 RDBMS 发行版中。

SQL 包括数据定义和数据操作语言。使用 SQL 的数据定义属性，可以设计和修改数据库模式，而数据操作属性允许 SQL 从数据库中存储和检索数据。

数据定义语言

SQL 使用以下命令集来定义数据库模式 -

创造

从 RDBMS 创建新的数据库、表和视图。

例如-

<span style="color:#000000">Create database tutorialspoint;
Create table article;
Create view for_students;
</span>

降低

从 RDBMS 中删除命令、视图、表和数据库。

例如-

<span style="color:#000000">Drop object_type object_name;
Drop database tutorialspoint;
Drop table article;
Drop view for_students;
</span>

改变

修改数据库模式。

<span style="color:#000000">Alter object_type object_name parameters;
</span>

例如-

<span style="color:#000000">Alter table article add subject varchar;
</span>

此命令在关系文章中添加一个属性，名称为字符串类型的主题。

数据操作语言

SQL配备了数据操作语言（DML）。DML 通过插入、更新和删除其数据来修改数据库实例。DML 负责数据库中所有表单数据的修改。SQL 在其 DML 部分包含以下命令集 -

• 选择/从/哪里
• 插入/值
• 更新/设置/哪里
• 从/哪里删除

这些基本构造允许数据库程序员和用户将数据和信息输入数据库，并使用许多过滤器选项进行有效检索。

选择/从/哪里

• SELECT - 这是 SQL 的基本查询命令之一。它类似于关系代数的投影操作。它根据 WHERE 子句描述的条件选择属性。

• FROM - 此子句将关系名称作为参数，从中选择/投影属性。如果给出了多个关系名称，则此子句对应于笛卡尔积。

• WHERE - 此子句定义谓词或条件，它们必须匹配才能限定要投影的属性。

例如-

<span style="color:#000000">Select author_name
From book_author
Where age > 50;
</span>

此命令将从年龄大于 50 岁的关系book_author中生成作者姓名。

插入/值

此命令用于将值插入表（关系）的行中。

语法-

<span style="color:#000000">INSERT INTO table (column1 [, column2, column3 ... ]) VALUES (value1 [, value2, value3 ... ])
</span>

或者

<span style="color:#000000">INSERT INTO table VALUES (value1, [value2, ... ])
</span>

例如-

<span style="color:#000000">INSERT INTO tutorialspoint (Author, Subject) VALUES ("anonymous", "computers");
</span>

更新/设置/哪里

此命令用于更新或修改表（关系）中列的值。

语法-

<span style="color:#000000">UPDATE table_name SET column_name = value [, column_name = value ...] [WHERE condition]
</span>

例如-

<span style="color:#000000">UPDATE tutorialspoint SET Author="webmaster" WHERE Author="anonymous";
</span>

删除/从/哪里

此命令用于从表（关系）中删除一行或多行。

语法-

<span style="color:#000000">DELETE FROM table_name [WHERE condition];
</span>

例如-

<span style="color:#000000">DELETE FROM tutorialspoints
   WHERE Author="unknown";
</span>

DBMS - 规范化

函数依赖

功能依赖性 (FD) 是关系中两个属性之间的一组约束。函数依赖表示如果两个元组的属性 A1、A2、...、An 具有相同的值，那么这两个元组的属性 B1、B2、...、Bn 必须具有相同的值。

功能依赖性由箭头符号 (→) 表示，即 X→Y，其中 X 在功能上确定 Y。左侧属性确定右侧属性的值。

阿姆斯特朗公理

如果 F 是一组函数依赖，则 F 的闭包（表示为 F +）是 F 逻辑上隐含的所有函数依赖的集合。阿姆斯特朗公理是一组规则，当重复应用时，会生成函数依赖的闭包.

• 自反规则- 如果 alpha 是一组属性而 beta is_subset_of alpha，则 alpha 持有 beta。

• 增广规则- 如果 a → b 成立且 y 是属性集，则 ay → by 也成立。即在依赖项中添加属性，不改变基本依赖项。

• 传递规则- 与代数中的传递规则相同，如果 a → b 成立且 b → c 成立，则 a → c 也成立。a → b 被称为决定 b 的函数。

琐碎的函数依赖

• Trivial - 如果函数依赖性 (FD) X → Y 成立，其中 Y 是 X 的子集，则它被称为平凡 FD。琐碎的 FD 始终成立。

• Non-trivial - 如果 FD X → Y 成立，其中 Y 不是 X 的子集，则称为非平凡 FD。

• Completely non-trivial − 如果 FD X → Y 成立，其中 x 与 Y = Φ 相交，则称其为完全非平凡的 FD。

正常化

如果数据库设计不完美，它可能包含异常，这对任何数据库管理员来说都是一场噩梦。管理异常的数据库几乎是不可能的。

• 更新异常- 如果数据项是分散的并且没有正确地相互链接，那么它可能会导致奇怪的情况。例如，当我们尝试更新一个副本分散在多个地方的数据项时，一些实例得到正确更新，而其他一些实例保留旧值。此类实例使数据库处于不一致状态。

• 删除异常- 我们试图删除一条记录，但由于不知情，部分记录未被删除，数据也保存在其他地方。

• 插入异常- 我们试图在根本不存在的记录中插入数据。

规范化是一种消除所有这些异常并使数据库处于一致状态的方法。

第一范式

第一范式是在关系（表）本身的定义中定义的。此规则定义关系中的所有属性都必须具有原子域。原子域中的值是不可分割的单元。

我们重新安排关系（表）如下，将其转换为第一范式。

每个属性必须仅包含来自其预定义域的单个值。

第二范式

在我们了解第二范式之前，我们需要了解以下内容 -

• 素数属性- 作为候选键的一部分的属性称为素数属性。

• Non-prime attribute - 不是主键一部分的属性被称为非主属性。

如果我们遵循第二范式，那么每个非素数属性都应该在功能上完全依赖于素数键属性。也就是说，如果 X → A 成立，则不应该存在 X 的任何真子集 Y，对此 Y → A 也成立。

我们在 Student_Project 关系中看到主键属性是 Stu_ID 和 Proj_ID。根据规则，非键属性，即 Stu_Name 和 Proj_Name 必须依赖于两者，而不是单独依赖于主键属性中的任何一个。但是我们发现Stu_Name可以通过Stu_ID来识别，Proj_Name可以通过Proj_ID来独立识别。这称为部分依赖，这在第二范式中是不允许的。

如上图所示，我们将关系一分为二。所以不存在部分依赖。

第三范式

对于第三范式的关系，它必须是第二范式并且必须满足以下条件 -

• 没有非主属性可传递地依赖于主键属性。
• 对于任何非平凡的函数依赖，X → A，然后 -
  • X 是一个超级键，或者，
  • A是主要属性。

我们发现在上面的 Student_detail 关系中，Stu_ID 是键，也是唯一的主键属性。我们发现 City 可以通过 Stu_ID 以及 Zip 本身来识别。Zip 既不是超级键，City 也不是主要属性。另外，Stu_ID → Zip → City，所以存在传递依赖。

为了将这种关系带入第三范式，我们将关系分成两个关系如下 -

Boyce-Codd范式

Boyce-Codd 范式 (BCNF) 是严格意义上的第三范式的扩展。BCNF 指出 -

• 对于任何非平凡的函数依赖，X → A，X 必须是超键。

在上图中，Stu_ID 是关系 Student_Detail 中的超键，Zip 是关系 ZipCodes 中的超键。所以，

Stu_ID → Stu_Name, Zip

和

邮编 → 城市

这证实了这两个关系都在 BCNF 中。

DBMS - 连接

我们了解采用两个关系的笛卡尔积的好处，它为我们提供了所有可能配对在一起的元组。但在某些情况下，我们可能无法采用笛卡尔积，因为我们会遇到具有大量属性的数千个元组的巨大关系。

Join是笛卡尔乘积和选择过程的组合。当且仅当满足给定的连接条件时，连接操作将来自不同关系的两个元组配对。

我们将在以下部分简要介绍各种连接类型。

Theta (θ) 加入

Theta join 组合来自不同关系的元组，前提是它们满足 theta 条件。连接条件用符号θ表示。

符号

<span style="color:#000000">R1 ⋈θ R2
</span>

R1 和 R2 是具有属性 (A1, A2, .., An) 和 (B1, B2,.. ,Bn) 的关系，这些属性没有任何共同点，即 R1 ∩ R2 = Φ。

Theta join 可以使用各种比较运算符。

学生
标识符	姓名	标准
101	亚历克斯	10
102	玛丽亚	11

科目
班级	主题
10	数学
10	英语
11	音乐
11	运动的

Student_Detail =

<span style="color:#000000">STUDENT ⋈Student.Std = Subject.Class SUBJECT</span>

学生详情
标识符	姓名	标准	班级	主题
101	亚历克斯	10	10	数学
101	亚历克斯	10	10	英语
102	玛丽亚	11	11	音乐
102	玛丽亚	11	11	运动的

等值连接

当 Theta join 仅使用相等比较运算符时，称为 equijoin。上面的例子对应的是equijoin。

自然连接 ( ⋈ )

自然连接不使用任何比较运算符。它不像笛卡尔积那样连接。仅当两个关系之间存在至少一个共同属性时，我们才能执行自然连接。此外，属性必须具有相同的名称和域。

自然连接作用于那些匹配的属性，其中两个关系中的属性值相同。

培训班
客户识别码	课程	部门
CS01	数据库	CS
ME01	力学	我
EE01	电子产品	电子工程

总督
部门	头
CS	亚历克斯
我	玛雅人
电子工程	米拉

课程 ⋈ HoD
部门	客户识别码	课程	头
CS	CS01	数据库	亚历克斯
我	ME01	力学	玛雅人
电子工程	EE01	电子产品	米拉

外连接

Theta Join、Equijoin 和 Natural Join 称为内部联接。内部连接只包括那些具有匹配属性的元组，其余的在结果关系中被丢弃。因此，我们需要使用外部连接将参与关系中的所有元组包含在结果关系中。外连接分为三种——左外连接、右外连接和全外连接。

左外连接(R 

S)

来自左关系 R 的所有元组都包含在结果关系中。如果 R 中的元组在右关系 S 中没有任何匹配的元组，则结果关系的 S 属性为 NULL。

左边
A	乙
100	数据库
101	力学
102	电子产品

正确的
A	乙
100	亚历克斯
102	玛雅人
104	米拉

课程 主任
A	乙	C	丁
100	数据库	100	亚历克斯
101	力学	---	---
102	电子产品	102	玛雅人

右外连接：( R 

S )

右关系 S 中的所有元组都包含在结果关系中。如果 S 中有元组而 R 中没有任何匹配的元组，则结果关系的 R 属性为 NULL。

课程 主任
A	乙	C	丁
100	数据库	100	亚历克斯
102	电子产品	102	玛雅人
---	---	104	米拉

全外连接：( R 

S)

来自两个参与关系的所有元组都包含在结果关系中。如果两个关系都没有匹配的元组，则将它们各自的不匹配属性设为 NULL。

课程 主任
A	乙	C	丁
100	数据库	100	亚历克斯
101	力学	---	---
102	电子产品	102	玛雅人
---	---	104	米拉

数据库管理系统 - 存储系统

数据库以包含记录的文件格式存储。在物理层面，实际数据以电磁格式存储在某些设备上。这些存储设备可大致分为三种类型 -

• 主存储- CPU 可直接访问的内存存储属于此类。CPU 的内部存储器（寄存器）、快速存储器（高速缓存）和主存储器（RAM）都可以直接被 CPU 访问，因为它们都放置在主板或 CPU 芯片组上。这种存储通常非常小、超快且易变。主存储需要持续供电以维持其状态。如果发生电源故障，其所有数据都会丢失。

• 辅助存储- 辅助存储设备用于存储数据以供将来使用或作为备份。二级存储包括不属于 CPU 芯片组或主板的存储设备，例如磁盘、光盘（DVD、CD 等）、硬盘、闪存驱动器和磁带。

• 三级存储- 三级存储用于存储大量数据。由于此类存储设备位于计算机系统之外，因此速度最慢。这些存储设备主要用于备份整个系统。光盘和磁带被广泛用作三级存储。

内存层次结构

计算机系统具有明确定义的内存层次结构。CPU 可以直接访问其主内存及其内置寄存器。主存的访问时间明显小于CPU速度。为了最大限度地减少这种速度不匹配，引入了缓存内存。高速缓存提供最快的访问时间，它包含 CPU 最常访问的数据。

访问速度最快的内存是成本最高的内存。较大的存储设备速度较慢且价格较低，但与 CPU 寄存器或高速缓存相比，它们可以存储大量数据。

磁盘

硬盘驱动器是目前计算机系统中最常见的辅助存储设备。这些被称为磁盘，因为它们使用磁化的概念来存储信息。硬盘由涂有可磁化材料的金属盘组成。这些磁盘垂直放置在主轴上。读/写磁头在磁盘之间移动，用于对其下方的点进行磁化或消磁。磁化点可以识别为 0（零）或 1（一）。

硬盘以明确定义的顺序格式化以有效地存储数据。硬盘盘片上有许多同心圆，称为磁道。每个磁道进一步分为扇区。硬盘上的一个扇区通常存储 512 字节的数据。

袭击

RAID全称R edundant A rray of Independent Disks，是一种连接多个二级存储设备并将它们作为单一存储介质使用的技术。

RAID 由一个磁盘阵列组成，其中多个磁盘连接在一起以实现不同的目标。RAID 级别定义磁盘阵列的使用。

• RAID 0 - 在此级别中，实施了条带化磁盘阵列。数据被分解成块，块分布在磁盘之间。每个磁盘接收一个数据块以并行写入/读取。它提高了存储设备的速度和性能。Level 0 没有奇偶校验和备份。

• RAID 1 - RAID 1 使用镜像技术。当数据被发送到 RAID 控制器时，它会向阵列中的所有磁盘发送一份数据副本。RAID 级别 1 也称为镜像，并在发生故障时提供 100% 的冗余。

• RAID 2 - RAID 2 使用汉明距离为其数据记录纠错码，在不同的磁盘上条带化。与0级一样，一个字中的每个数据位都记录在一个单独的磁盘上，数据字的ECC码存储在不同的一组磁盘上。RAID 2由于结构复杂、成本高，目前还没有商用。

• RAID 3 - RAID 3 将数据条带化到多个磁盘上。为数据字生成的奇偶校验位存储在不同的磁盘上。该技术使其能够克服单个磁盘故障。

• RAID 4 - 在此级别中，将整个数据块写入数据磁盘，然后生成奇偶校验并将其存储在不同的磁盘上。请注意，第 3 级使用字节级条带化，而第 4 级使用块级条带化。level 3 和 level 4 都需要至少三个磁盘来实现 RAID。

• RAID 5 - RAID 5 将整个数据块写入不同的磁盘，但为数据块条带化生成的奇偶校验位分布在所有数据磁盘中，而不是将它们存储在不同的专用磁盘上。

• RAID 6 - RAID 6 是级别 5 的扩展。在此级别中，生成两个独立的奇偶校验位并以分布式方式存储在多个磁盘中。两个奇偶校验提供额外的容错能力。此级别至少需要四个磁盘驱动器才能实现 RAID。

数据库管理系统 - 文件结构

相关数据和信息以文件格式集中存储。文件是以二进制格式存储的一系列记录。磁盘驱动器被格式化成几个可以存储记录的块。文件记录被映射到那些磁盘块上。

文件组织

文件组织定义文件记录如何映射到磁盘块。我们有四种类型的文件组织来组织文件记录 -

堆文件组织

当使用堆文件组织创建文件时，操作系统会为该文件分配内存区域，而无需任何进一步的统计细节。文件记录可以放在该内存区域的任何位置。管理记录是软件的责任。堆文件本身不支持任何排序、排序或索引。

顺序文件组织

每个文件记录都包含一个数据字段（属性）来唯一标识该记录。在顺序文件组织中，记录根据唯一键字段或搜索键以某种顺序排列在文件中。实际上，不可能以物理形式顺序存储所有记录。

哈希文件组织

哈希文件组织对记录的某些字段使用哈希函数计算。散列函数的输出决定了要放置记录的磁盘块的位置。

集群文件组织

集群文件组织不适合大型数据库。在这种机制中，来自一个或多个关系的相关记录保存在同一个磁盘块中，即记录的排序不基于主键或搜索键。

文件操作

对数据库文件的操作大致可分为两类 -

• 更新操作

• 检索操作

更新操作通过插入、删除或更新来更改数据值。另一方面，检索操作不会更改数据，而是在可选的条件过滤后检索它们。在这两种类型的操作中，选择都起着重要作用。除了创建和删除文件外，还可以对文件执行多种操作。

• Open - 可以在两种模式之一打开文件，read mode或write mode。在读取模式下，操作系统不允许任何人更改数据。换句话说，数据是只读的。以读取模式打开的文件可以在多个实体之间共享。写模式允许数据修改。以写入模式打开的文件可以读取但不能共享。

• Locate - 每个文件都有一个文件指针，它告诉当前要读取或写入数据的位置。可以相应地调整该指针。使用查找（查找）操作，它可以向前或向后移动。

• 读取- 默认情况下，当文件以读取模式打开时，文件指针指向文件的开头。有一些选项，用户可以在打开文件时告诉操作系统将文件指针定位到哪里。读取文件指针的下一个数据。

• Write - 用户可以选择以写入模式打开文件，这使他们能够编辑其内容。它可以是删除、插入或修改。文件指针可以在打开时定位，也可以在操作系统允许的情况下动态更改。

• 关闭- 从操作系统的角度来看，这是最重要的操作。当产生关闭文件的请求时，操作系统

  • 删除所有锁（如果处于共享模式），
  • 将数据（如果更改）保存到辅助存储介质，并且
  • 释放与该文件关联的所有缓冲区和文件处理程序。

文件中数据的组织在这里起着重要作用。将文件指针定位到文件内所需记录的过程根据记录是按顺序排列还是成簇排列而有所不同。

数据库管理系统 - 索引

我们知道数据是以记录的形式存储的。每条记录都有一个关键字段，这有助于它被唯一识别。

索引是一种数据结构技术，可以根据已完成索引的某些属性从数据库文件中有效地检索记录。数据库系统中的索引与我们在书中看到的类似。

索引是根据其索引属性定义的。索引可以是以下类型 -

• Primary Index - 主索引在有序数据文件上定义。数据文件在关键字段上排序。键字段通常是关系的主键。

• 二级索引- 二级索引可以从一个字段生成，该字段是候选键并且在每个记录中具有唯一值，或者是具有重复值的非键。

• 聚类索引- 聚类索引是在有序数据文件上定义的。数据文件在非关键字段上排序。

有序索引有两种类型 -

• 密集索引
• 稀疏索引

密集索引

在密集索引中，数据库中的每个搜索键值都有一个索引记录。这使得搜索速度更快，但需要更多空间来存储索引记录本身。索引记录包含搜索键值和指向磁盘上实际记录的指针。

稀疏索引

在稀疏索引中，不会为每个搜索关键字创建索引记录。这里的索引记录包含一个搜索关键字和一个指向磁盘上数据的实际指针。要搜索记录，我们首先通过索引记录进行并到达数据的实际位置。如果我们要查找的数据不是按照索引直接到达的地方，那么系统就会开始顺序查找，直到找到需要的数据。

多级索引

索引记录包括搜索关键字值和数据指针。多级索引与实际的数据库文件一起存储在磁盘上。随着数据库规模的增长，索引的规模也随之增长。非常需要将索引记录保存在主存储器中以加快搜索操作。如果使用单级索引，则无法在内存中保留大尺寸索引，从而导致多次磁盘访问。

多级索引有助于将索引分解为几个较小的索引，以便使最外层的索引非常小，以至于可以将其保存在单个磁盘块中，这可以很容易地容纳在主内存中的任何位置。

B +树

AB +树是一种遵循多级索引格式的平衡二叉搜索树。B +树的叶节点表示实际的数据指针。B +树保证所有的叶子节点都保持在同一高度，从而达到平衡。此外，叶节点使用链接列表链接；因此，B +树既可以支持随机访问，也可以支持顺序访问。

B +树的结构

每个叶节点与根节点的距离相等。AB +树的阶数为n，其中n对于每棵B +树都是固定的。

内部节点-

• 内部（非叶）节点包含至少 ⌈n/2⌉ 个指针，根节点除外。
• 一个内部节点最多可以包含n 个指针。

叶节点-

• 叶节点至少包含 ⌈n/2⌉ 记录指针和 ⌈n/2⌉ 键值。
• 一个叶节点最多可以包含n个记录指针和n个键值。
• 每个叶节点包含一个块指针P指向下一个叶节点，形成一个链表。

B +树插入

• B +树从底部开始填充，每个条目都在叶节点完成。

• 如果叶节点溢出 -

  • 将节点分成两部分。

  • 在i = ⌊(m+1) /2 ⌋ 处划分。

  • 第i个条目存储在一个节点中。

  • 其余条目（从 i+1 开始）被移动到新节点。

  • 第 i个键在叶节点的父节点中被复制。

• 如果非叶节点溢出 -

  • 将节点分成两部分。

  • 在i = ⌈(m+1) /2 ⌉处对节点进行分区。

  • 直到i 的条目都保存在一个节点中。

  • 其余条目将移动到新节点。

B +树删除

• B +树条目在叶节点处被删除。

• 搜索并删除目标条目。

  • 如果是内部节点，则删除并替换为从左侧位置开始的条目。

• 删除后，测试下溢，

  • 如果发生下溢，从它留下的节点分发条目。

• 如果不能从左分配，则

  • 从节点分配到它。

• 如果无法从左或右分配，则

  • 将节点与 left 和 right 合并到它。

数据库管理系统 - 哈希

对于庞大的数据库结构，几乎不可能遍历其所有级别搜索所有索引值，然后到达目标数据块以检索所需数据。哈希是一种无需使用索引结构即可计算数据记录在磁盘上的直接位置的有效技术。

散列使​​用以搜索关键字作为参数的散列函数来生成数据记录的地址。

哈希组织

• Bucket - 哈希文件以桶格式存储数据。桶被认为是一个存储单元。一个桶通常存储一个完整的磁盘块，而该磁盘块又可以存储一个或多个记录。

• 哈希函数- 哈希函数h是一种映射函数，它将所有搜索键集K映射到放置实际记录的地址。它是一个从搜索键到桶地址的函数。

静态散列

在静态散列中，当提供搜索键值时，散列函数总是计算相同的地址。例如，如果使用 mod-4 哈希函数，则它应该只生成 5 个值。该功能的输出地址应始终相同。提供的桶数始终保持不变。

手术

• 插入- 当需要使用静态哈希输入记录时，哈希函数h计算搜索键K的存储桶地址，记录将存储在该地址中。

  桶地址 = h(K)

• 搜索- 当需要检索记录时，可以使用相同的哈希函数来检索存储数据的存储桶的地址。

• Delete - 这只是一个搜索，然后是删除操作。

桶溢出

桶溢出的情况称为碰撞。这是任何静态散列函数的致命状态。在这种情况下，可以使用溢出链接。

• 溢出链接- 当桶已满时，为相同的散列结果分配一个新桶，并在前一个桶之后链接。这种机制称为Closed Hashing。

• Linear Probing - 当哈希函数生成已存储数据的地址时，将为其分配下一个空闲桶。这种机制称为Open Hashing。

动态散列

静态散列的问题在于它不会随着数据库大小的增长或收缩而动态扩展或收缩。动态哈希提供了一种机制，在该机制中，可以动态地按需添加和删除数据桶。动态哈希也称为扩展哈希。

哈希函数，在动态哈希中，被用来产生大量的值，最初只使用几个。

组织

将整个哈希值的前缀作为哈希索引。只有一部分哈希值用于计算桶地址。每个散列索引都有一个深度值来表示有多少位用于计算散列函数。这些位可以寻址 2n 个桶。当所有这些位都被消耗时——也就是说，当所有的桶都满了——然后深度值线性增加并且分配两倍的桶。

手术

• 查询- 查看哈希索引的深度值并使用这些位来计算桶地址。

• 更新- 执行上述查询并更新数据。

• Deletion - 执行查询以找到所需的数据并将其删除。

• 插入- 计算桶的地址

  • 如果桶已经满了。
    • 添加更多桶。
    • 向散列值添加额外的位。
    • 重新计算哈希函数。
  • 别的
    • 将数据添加到桶中，
  • 如果所有桶都已满，则执行静态散列的补救措施。

当数据按某种顺序组织并且查询需要一定范围的数据时，散列是不利的。当数据是离散和随机的时，hash 表现最好。

散列算法比索引具有更高的复杂性。所有哈希操作都在恒定时间内完成。

数据库管理系统 - 交易

事务可以定义为一组任务。单个任务是最小的处理单元，不能进一步划分。

让我们以一个简单的交易为例。假设银行职员从 A 的账户转账 500 卢比到 B 的账户。这个非常简单和小的交易涉及几个低级任务。

A的账户

<span style="color:#000000">Open_Account(A)
Old_Balance = A.balance
New_Balance = Old_Balance - 500
A.balance = New_Balance
Close_Account(A)
</span>

B的账户

<span style="color:#000000">Open_Account(B)
Old_Balance = B.balance
New_Balance = Old_Balance + 500
B.balance = New_Balance
Close_Account(B)
</span>

酸性物质

事务是程序的一个非常小的单元，它可能包含多个低级任务。数据库系统中的事务必须保持原子性、一致性、隔离性和持久性——通常称为 ACID 属性——以确保准确性、完整性和数据完整性。

• 原子性- 此属性声明事务必须被视为原子单元，也就是说，要么执行其所有操作，要么不执行。数据库中不能有事务部分完成的状态。状态应该在事务执行之前或事务执行/中止/失败之后定义。

• 一致性- 数据库必须在任何事务后保持一致状态。任何事务都不应对驻留在数据库中的数据产生任何不利影响。如果数据库在事务执行前处于一致状态，则在事务执行后它也必须保持一致。

• 持久性- 数据库应该足够持久以保存所有最新更新，即使系统出现故障或重新启动也是如此。如果事务更新数据库中的数据块并提交，则数据库将保存修改后的数据。如果事务提交但系统在将数据写入磁盘之前发生故障，那么一旦系统恢复运行，该数据将被更新。

• 隔离- 在同时并行执行多个事务的数据库系统中，隔离的属性表明所有事务都将被执行和执行，就好像它是系统中唯一的事务一样。任何交易都不会影响任何其他交易的存在。

可串行化

当操作系统在多道程序设计环境中执行多个事务时，一个事务的指令可能会与其他一些事务交错。

• Schedule - 事务的时间顺序执行序列称为时间表。一个调度表中可以包含许多事务，每个事务都包含许多指令/任务。

• Serial Schedule - 这是一种时间表，其中事务以首先执行一个事务的方式对齐。当第一个事务完成其循环时，将执行下一个事务。交易顺序依次进行。这种类型的调度称为串行调度，因为事务以串行方式执行。

在多事务环境中，串行调度被视为基准。事务中一条指令的执行顺序不能改变，但是两个事务可以让它们的指令以随机方式执行。如果两个事务相互独立并且处理不同的数据段，则这种执行不会造成损害；但是如果这两个事务处理相同的数据，那么结果可能会有所不同。这种不断变化的结果可能会使数据库处于不一致的状态。

为了解决这个问题，我们允许并行执行一个事务调度，如果它的事务是可序列化的或者它们之间有某种等价关系。

等价表

等效时间表可以是以下类型 -

结果等价

如果两个调度在执行后产生相同的结果，则称它们是结果等价的。它们可能对某些值产生相同的结果，而对另一组值产生不同的结果。这就是为什么这种等效性通常不被认为是重要的。

查看等效项

如果两个计划中的事务以类似的方式执行类似的操作，则这两个计划将被视为等效。

例如 -

• 如果 T 读取了 S1 中的初始数据，那么它也读取了 S2 中的初始数据。

• 如果 T 读取了 J 在 S1 中写入的值，那么它也读取了 J 在 S2 中写入的值。

• 如果 T 对 S1 中的数据值执行最终写入，那么它也会对 S2 中的数据值执行最终写入。

冲突对等

如果两个时间表具有以下属性，它们将发生冲突 -

• 两者属于单独的交易。
• 两者都访问相同的数据项。
• 至少其中之一是“写”操作。

当且仅当 -

• 两个计划都包含同一组事务。
• 冲突的操作对的顺序在两个调度表中都保持不变。

注意- 视图等效计划是视图可序列化的，冲突等效计划是冲突可序列化的。所有冲突的可序列化计划也都是可序列化的。

交易状态

数据库中的事务可以处于以下状态之一 -

• Active - 在此状态下，交易正在执行。这是每笔交易的初始状态。

• 部分提交- 当事务执行其最终操作时，据说它处于部分提交状态。

• Failed - 如果数据库恢复系统所做的任何检查失败，则称事务处于失败状态。失败的交易不能再继续进行。

• 已中止- 如果任何检查失败并且事务已达到失败状态，则恢复管理器将回滚其对数据库的所有写操作，以使数据库恢复到事务执行之前的原始状态。处于这种状态的事务称为中止。事务中止后，数据库恢复模块可以选择两个操作之一 -

  • 重新开始交易
  • 杀死交易

• Committed - 如果事务成功执行了所有操作，则称它已提交。它的所有效果现在都永久地建立在数据库系统上。

DBMS - 并发控制

在可以同时执行多个事务的多道程序环境中，控制事务的并发性非常重要。我们有并发控制协议来确保并发事务的原子性、隔离性和可串行性。并发控制协议可以大致分为两类 -

• 基于锁的协议
• 基于时间戳的协议

基于锁的协议

配备基于锁的协议的数据库系统使用一种机制，任何事务在获得适当的锁之前都无法读取或写入数据。锁有两种 -

• Binary Locks - 数据项上的锁可以处于两种状态；它要么被锁定，要么被解锁。

• Shared/exclusive - 这种类型的锁定机制根据其用途区分锁。如果在数据项上获取锁以执行写操作，则它是排他锁。允许多个事务写入同一数据项会导致数据库进入不一致状态。读取锁是共享的，因为没有数据值被更改。

有四种类型的锁定协议可用 -

简单的锁定协议

简单的基于锁的协议允许事务在执行“写”操作之前获得每个对象的锁。事务可以在完成“写入”操作后解锁数据项。

预声明锁定协议

预声明协议评估它们的操作并创建它们需要锁定的数据项列表。在开始执行之前，事务请求系统预先获得它需要的所有锁。如果所有的锁都被授予，事务执行并在它的所有操作结束时释放所有的锁。如果所有的锁都没有被授予，事务回滚并等待所有的锁都被授予。

两相锁定 2PL

该锁定协议将事务的执行阶段分为三个部分。在第一部分中，当事务开始执行时，它会为其所需的锁寻求许可。第二部分是事务获取所有锁的地方。一旦事务释放了它的第一个锁，第三阶段就开始了。在这个阶段，事务不能要求任何新的锁；它只释放获得的锁。

两阶段锁定有两个阶段，一个是growing，所有的锁都在被事务获取；第二阶段是收缩，此时事务持有的锁正在被释放。

要申请独占（写）锁，事务必须首先获取共享（读）锁，然后将其升级为独占锁。

严格的两阶段锁定

Strict-2PL 的第一阶段与 2PL 相同。第一阶段获取到所有锁后，事务继续正常执行。但与2PL不同的是，Strict-2PL在使用后并不会释放锁。Strict-2PL 持有所有锁直到提交点并一次释放所有锁。

Strict-2PL 没有像 2PL 那样的级联中止。

基于时间戳的协议

最常用的并发协议是基于时间戳的协议。该协议使用系统时间或逻辑计数器作为时间戳。

基于锁的协议在执行时管理事务之间冲突对之间的顺序，而基于时间戳的协议在事务创建后立即开始工作。

每笔交易都有一个与之关联的时间戳，排序由交易的年龄决定。在 0002 时钟时间创建的事务将比它之后的所有其他事务更早。例如，任何在 0004 进入系统的事务“y”都晚两秒，并且优先权将给予较早的事务。

此外，每个数据项都被赋予最新的读写时间戳。这让系统知道最后一次对数据项执行“读写”操作的时间。

时间戳排序协议

时间戳排序协议确保事务在其冲突的读写操作中的可串行化。这是协议系统的责任，即应根据事务的时间戳值执行冲突的任务对。

• 事务 T i的时间戳记为 TS(T i )。
• 数据项 X 的读取时间戳记为 R-timestamp(X)。
• 数据项 X 的写入时间戳记为 W-timestamp(X)。

时间戳排序协议的工作原理如下 -

• 如果事务 Ti 发出读取（X）操作 -

  • 如果 TS(Ti) < W-时间戳(X)
    • 操作被拒绝。
  • 如果 TS(Ti) >= W-时间戳(X)
    • 操作已执行。
  • 所有数据项时间戳已更新。

• 如果事务 Ti 发出写（X）操作 -

  • 如果 TS(Ti) < R-timestamp(X)
    • 操作被拒绝。
  • 如果 TS(Ti) < W-时间戳(X)
    • 操作被拒绝，Ti 回滚。
  • 否则，执行操作。

托马斯的写规则

该规则规定如果 TS(Ti) < W-timestamp(X)，则操作被拒绝并且 Ti被回滚。

可以修改时间戳排序规则以使计划视图可序列化。

不是让 T i回滚，而是忽略“写”操作本身。

数据库管理系统——死锁

在多进程系统中，死锁是在共享资源环境中出现的一种不需要的情况，其中一个进程无限期地等待另一个进程持有的资源。

例如，假设一组事务 {T 0 , T 1 , T 2 , ...,T n }。T 0需要资源 X 来完成它的任务。资源 X 由 T 1持有，T 1正在等待由 T 2 持有的资源Y。T 2正在等待T 0持有的资源Z。因此，所有进程都在等待对方释放资源。在这种情况下，没有一个进程可以完成它们的任务。这种情况称为死锁。

死锁对系统来说是不健康的。如果系统陷入死锁，则死锁中涉及的事务将回滚或重新启动。

死锁预防

为了防止系统中出现任何死锁情况，DBMS 会积极检查所有即将执行事务的操作。DBMS 检查操作并分析它们是否会造成死锁情况。如果发现可能发生死锁情况，则永远不允许执行该事务。

存在使用事务的时间戳排序机制来预先确定死锁情况的死锁预防方案。

等死计划

在此方案中，如果事务请求锁定资源（数据项），而该资源（数据项）已被另一个事务持有冲突锁，则可能会出现以下两种可能性之一 -

• 如果 TS(T i ) < TS(T j ) - 即请求冲突锁的 T i早于 T j - 然后允许 T i等待直到数据项可用。

• 如果 TS(T i ) > TS(t j ) - 即 T i比 T j年轻- 然后 T i死亡。T i稍后以随机延迟重新启动，但具有相同的时间戳。

该方案允许较旧的事务等待但杀死较新的事务。

伤口等待计划

在这个方案中，如果一个事务请求锁定一个资源（数据项），而该资源（数据项）已经被另一个事务持有冲突锁，则可能会出现以下两种可能性之一 -

• 如果 TS(T i ) < TS(T j )，则 T i迫使 T j回滚 - 即 T i伤害 T j。T j稍后以随机延迟重新启动，但具有相同的时间戳。

• 如果 TS(T i ) > TS(T j )，则 T i被迫等待直到资源可用。

该方案，允许小事务等待；但是当较旧的交易请求较年轻的交易持有的物品时，较旧的交易会迫使较年轻的交易中止并释放该物品。

在这两种情况下，稍后进入系统的交易都会被中止。

避免死锁

中止交易并不总是一种实用的方法。相反，可以使用死锁避免机制来提前检测任何死锁情况。像“等待图”这样的方法是可用的，但它们只适用于事务轻量级且资源实例较少的系统。在庞大的系统中，死锁预防技术可能效果很好。

等待图

这是一种可用于跟踪是否可能出现死锁情况的简单方法。对于进入系统的每个交易，都会创建一个节点。当一个事务 Ti请求锁定一个项目，比如 X，它被其他事务 T j持有，从 T i到 T j的有向边被创建。如果 T j释放项目 X，则它们之间的边被删除并且 T i锁定数据项。

系统为等待其他人持有的某些数据项的每个事务维护此等待图。系统会不断检查图中是否存在循环。

在这里，我们可以使用以下两种方法中的任何一种 -

• 首先，不允许对已被另一个事务锁定的项目进行任何请求。这并不总是可行的，并且可能会导致饥饿，事务会无限期地等待数据项并且永远无法获取它。

• 第二种选择是回滚其中一个事务。回滚较新的事务并不总是可行的，因为它可能比较旧的事务重要。在一些相关算法的帮助下，选择要中止的事务。这个交易被称为受害者，这个过程被称为受害者选择。

数据库管理系统 - 数据备份

易失性存储丢失

像 RAM 这样的易失性存储器存储所有活动日志、磁盘缓冲区和相关数据。此外，它还存储当前正在执行的所有交易。如果这种易失性存储突然崩溃会怎样？它显然会带走数据库的所有日志和活动副本。这使得恢复几乎不可能，因为恢复数据所需的一切都丢失了。

如果易失性存储丢失，可以采用以下技术 -

• 我们可以在多个阶段设置检查点，以便定期保存数据库的内容。

• 易失性内存中的活动数据库状态可以定期转储到稳定存储中，其中还可能包含日志和活动事务和缓冲块。

• <dump> 可以在日志文件上标记，每当数据库内容从非易失性内存转储到稳定内存时。

恢复

• 当系统从故障中恢复时，它可以恢复最新的转储。

• 它可以维护重做列表和撤消列表作为检查点。

• 它可以通过查阅撤销-重做列表来恢复系统，以将所有事务的状态恢复到最后一个检查点。

从灾难性故障中备份和恢复数据库

灾难性故障是稳定的辅助存储设备损坏的故障。使用存储设备，存储在其中的所有有价值的数据都会丢失。我们有两种不同的策略来从这种灾难性故障中恢复数据 -

• 远程备份 &minu; 这里数据库的备份副本存储在远程位置，在发生灾难时可以从那里恢复。

• 或者，可以将数据库备份在磁带上并存储在更安全的地方。稍后可以将此备份传输到新安装的数据库上，以将其带到备份点。

成熟的数据库体积太大，无法经常备份。在这种情况下，我们可以通过查看日志来恢复数据库。因此，我们在这里需要做的就是定期备份所有日志。数据库可以每周备份一次，日志非常小可以每天或尽可能频繁地备份。

远程备份

远程备份提供了一种安全感，以防数据库所在的主要位置遭到破坏。远程备份可以是离线的，也可以是实时的，也可以是在线的。如果它离线，则手动维护。

在线备份系统对数据库管理员和投资者来说更加实时和救命稻草。在线备份系统是一种将实时数据的每一位都同时备份到两个相距遥远的地方的机制。其中一个直接连接到系统，另一个作为备份保存在远程位置。

一旦主数据库存储发生故障，备份系统就会感知到故障并将用户系统切换到远程存储。有时，这种情况是如此之快，以至于用户甚至都没有意识到失败。

DBMS - 数据恢复

崩溃恢复

DBMS 是一个高度复杂的系统，每秒执行数百个事务。DBMS 的持久性和健壮性取决于其复杂的体系结构及其底层硬件和系统软件。如果它在交易过程中失败或崩溃，预计系统将遵循某种算法或技术来恢复丢失的数据。

故障分类

要查看问题发生的位置，我们将故障归纳为各种类别，如下所示 -

交易失败

当事务无法执行或到达无法继续执行的点时，事务必须中止。这称为事务失败，其中只有少数事务或进程受到损害。

交易失败的原因可能是 -

• 逻辑错误- 交易无法完成的地方，因为它有一些代码错误或任何内部错误条件。

• 系统错误- 数据库系统本身终止活动事务，因为 DBMS 无法执行它，或者由于某些系统条件而必须停止。例如，在死锁或资源不可用的情况下，系统会中止活动事务。

系统崩溃

系统外部存在问题，可能会导致系统突然停止并导致系统崩溃。例如，电源中断可能导致底层硬件故障或软件故障。

示例可能包括操作系统错误。

磁盘故障

在技​​术发展的早期，硬盘驱动器或存储驱动器经常发生故障是一个常见问题。

磁盘故障包括坏扇区的形成、磁盘无法访问、磁头崩溃或任何其他破坏全部或部分磁盘存储的故障。

存储结构

我们已经描述了存储系统。简而言之，存储结构可以分为两类 -

• 易失性存储- 顾名思义，易失性存储无法在系统崩溃后幸存下来。易失性存储设备放置在非常靠近 CPU 的位置；通常它们被嵌入到芯片组本身。例如，主存储器和高速缓冲存储器是易失性存储器的例子。它们速度很快，但只能存储少量信息。

• 非易失性存储− 这些存储器用于在系统崩溃时幸存下来。它们的数据存储容量巨大，但访问速度较慢。示例可能包括硬盘、磁带、闪存和非易失性（电池备份）RAM。

恢复和原子性

当系统崩溃时，可能有多个事务正在执行，并打开各种文件供它们修改数据项。事务由各种操作组成，这些操作本质上是原子的。但根据DBMS的ACID特性，必须保持事务整体的原子性，即要么全部执行，要么不执行。

当 DBMS 从崩溃中恢复时，它应该维护以下内容 -

• 它应该检查正在执行的所有交易的状态。

• 一个事务可能正处于某个操作的中间；在这种情况下，DBMS 必须确保事务的原子性。

• 它应该检查事务现在是否可以完成或者是否需要回滚。

• 不允许任何事务使 DBMS 处于不一致状态。

有两种技术可以帮助 DBMS 恢复和维护事务的原子性：

• 维护每个事务的日志，并在实际修改数据库之前将它们写入一些稳定的存储。

• 维护影子分页，其中更改在易失性内存上完成，稍后更新实际数据库。

基于日志的恢复

日志是一个记录序列，它维护着一个事务执行的动作的记录。重要的是日志在实际修改之前写入并存储在稳定的存储介质上，这是故障安全的。

基于日志的恢复工作如下 -

• 日志文件保存在稳定的存储介质上。

• 当一个事务进入系统并开始执行时，它会写一个关于它的日志。

<span style="color:#000000"><Tn, Start>
</span>

• 当事务修改项目 X 时，它写入日志如下 -

<span style="color:#000000"><Tn, X, V1, V2>
</span>

它读取 T n已将 X 的值从 V 1更改为 V 2。

• 事务完成后，它会记录 -

<span style="color:#000000"><Tn, commit>
</span>

可以使用两种方法修改数据库 -

• 延迟数据库修改- 所有日志都写入稳定存储，并在事务提交时更新数据库。

• Immediate database modification - 每个日志都遵循实际的数据库修改。也就是说，每次操作后都会立即修改数据库。

并发事务恢复

当并行执行多个事务时，日志会交错。在恢复时，恢复系统很难回溯所有日志，然后开始恢复。为了缓解这种情况，大多数现代 DBMS 使用“检查点”的概念。

检查点

在真实环境中实时保存和维护日志可能会填满系统中所有可用的内存空间。随着时间的推移，日志文件可能会变得太大而根本无法处理。Checkpoint 是一种机制，将所有以前的日志从系统中删除并永久存储在存储磁盘中。检查点声明了一个点，在此之前 DBMS 处于一致状态，并且所有事务都已提交。

恢复

当具有并发事务的系统崩溃并恢复时，它的行为如下 -

• 恢复系统从末尾向后读取日志到最后一个检查点。

• 它维护两个列表，一个撤销列表和一个重做列表。

• 如果恢复系统看到带有 <T n , Start> 和 <T n , Commit> 或只是 <T n , Commit>的日志，它会将事务放入重做列表。

• 如果恢复系统看到带有 <T n , Start>的日志但没有找到提交或中止日志，它会将事务放入撤消列表。

然后撤销列表中的所有事务并删除它们的日志。重做列表中的所有事务及其以前的日志都将被删除，然后在保存日志之前重做。