数据库系统
1 数据库模式
数据库系统的体系结构
在数据库系统中，三级模式结构 是指数据库系统的体系结构分为三层：外模式（External Schema）、概念模式（Conceptual Schema）、和内模式（Internal Schema）。为了实现这三层之间的映射和转换，引入了两级映射（Two-Level Mapping）机制。
1. 三级模式
• 外模式（External Schema）：外模式定义了不同用户或应用程序对数据库的特定视图。每个外模式对应于一个特定用户或应用程序的数据需求和访问权限，通常只展示数据的子集。
• 概念模式（Conceptual Schema）：概念模式是数据库系统的核心模式，定义了数据库中所有数据的逻辑结构和关系，而不涉及数据的物理存储细节。它描述了数据库的整体结构，如表、关系、约束等，是对全体用户共同可见的全局视图。
• 内模式（Internal Schema）：内模式描述了数据在数据库中的物理存储结构，包括文件组织、索引、存储路径等。它涉及如何高效地在物理介质上存储和检索数据。
2. 两级映射
为了在这三层之间进行数据访问和操作，系统定义了两个映射过程：
• 外模式到概念模式的映射（External/Conceptual Mapping）：这个映射定义了外模式与概念模式之间的对应关系。它确保用户或应用程序在访问外模式时，系统能够正确地将这些请求映射到概念模式中的相应部分。这种映射可以处理不同用户看到不同数据视图的情况，例如某个外模式只显示数据库的一个子集或以某种特定的格式显示数据。
• 概念模式到内模式的映射（Conceptual/Internal Mapping）：这个映射定义了概念模式与内模式之间的对应关系。它确保当系统执行概念模式中的操作时，能够将这些操作正确地映射到物理存储结构上，即在内模式中进行数据的存储和检索。这种映射允许数据库系统在不影响概念模式的情况下，优化数据的物理存储方式。
关系表的3种类型
- 基本关系（通常又称为基本表或基表）：实际存在的表，实际存储数据的逻辑表示。
- 查询表：查询结果对应的表。
- 视图表：由基表或其他视图表导出的表，本身不独立存储，数据库只存放它的定义，常称为虚表。
数据库视图： 它一个虚拟表（逻辑上的表），其内容由查询定义（仅保存SQL查询语句）。同真实的表一样，视图包含一系列带有名称的列和行数据。但是，视图并没有真正存储这些数据，而是通过查询原始表动态生成所需要的数据。
视图的优点：
1、视图能简化用户操作
2、视图使用户能以多种角度看待同一数据
3、视图对重构数据库提供了一定程度的逻辑独立性
4、视图可以对机密数据提供安全保护
物化视图：它不是传统意义上虚拟视图，是实体化视图，其本身会存储数据。同时当原始表中的数据更新时，物化视图也会更新。
2 分布式数据库
2.1 分布式数据库的主要特点
-
数据独立性：在分布式数据库系统中，除了逻辑独立性和物理独立性之外，还增加了数据分布的独立性（分布透明性）。用户不需要知道数据实际存储在哪个物理位置，可以像访问集中式数据库一样访问分布式数据库。
-
集中与自治共享结合的控制结构：分布式数据库系统中，各局部的DBMS可以独立管理局部数据库，具有自治的功能。同时，系统也没有集中式的控制机制，而是通过协调各局部DBMS的工作来执行全局应用。
-
适当增加数据冗余度：在不同的地点存储相同数据的多个副本，这样可以提高系统的可靠性和可用性，即使某个节点发生故障，其他节点的数据副本依然可用，确保数据的完整性和可恢复性。
-
全局的一致性、可串行性和可恢复性：尽管数据是分布式存储的，但系统必须确保全局数据的一致性和操作的可串行性，同时在发生故障时能够恢复数据。
2.2 分布式数据库体系结构
1. 全局DBMS
• 全局DBMS 是负责管理整个分布式数据库系统的组件，它协调和管理分布在不同位置的局部数据库。
2. 全局模式
• 全局外模式：这是用户或应用程序与分布式数据库交互的视图。每个全局外模式为不同的用户或应用程序提供了对数据库的一部分视图，屏蔽了底层数据的复杂性。
• 全局概念模式：它定义了整个分布式数据库的逻辑结构，统一描述了各局部数据库的内容和结构。它是全局外模式的基础，使得数据在全局上看起来是一个整体。
• 分片模式：分片模式定义了数据在不同数据库节点上的分布方式。它决定了哪些数据存储在系统的哪个部分。
• 分布模式：分布模式进一步描述了数据在多个节点之间如何分布和访问。
3. 局部DBMS
• 局部概念模式：这是局部数据库的逻辑结构，描述了各个局部数据库的内部数据结构。
• 局部内模式：它描述了局部数据库的物理存储结构，即数据在存储设备上的组织方式。
• 局部数据库：实际存储数据的物理数据库。分布式数据库系统通过这些局部数据库实现数据的存储和访问。
4. 映像（映射）关系
• 全局模式到局部模式的映像：全局概念模式通过分片模式和分布模式映射到各个局部概念模式。这些映像定义了全局数据库视图是如何在具体的局部数据库中实现的。
• 全局外模式到全局概念模式的映像：不同用户的全局外模式通过映像连接到全局概念模式，确保用户能够访问所需的数据视图。
全局DBMS负责管理全局的概念结构和分布策略，而局部DBMS则处理数据的物理存储和具体实现。用户通过全局外模式与系统交互，系统通过一系列映射将这些请求映射到各个局部数据库，从而完成分布式数据的管理和访问。
- 分片透明：是指用户不必关心数据是如何分片的，它们对数据的操作在全局关系上进行，即如何分片对用户是透明的。
- 复制透明：用户不用关心数据库在网络中各个节点的复制情况，被复制的数据的更新都由系统自动完成。
- 位置透明：是指用户不必知道所操作的数据放在何处，即数据分配到哪个或哪些站点存储对用户是透明的。
- 局部映像透明性（逻辑透明）：是最低层次的透明性，该透明性提供数据到局部数据库的映像，即用户不必关心局部DBMS支持哪种数据模型、使用哪种数据操纵语言，数据模型和操纵语言的转换是由系统完成的。因此，局部映像透明性对异构型和同构异质的分布式数据库系统是非常重要的。
两阶段提交协议 2PC
-
2PC 事务提交的两个阶段
表决阶段，目的是形成一个共同的决定
执行阶段，目的是实现这个协调者的决定
-
两条全局提交规则
只要有一个参与者撤销事务，协调者就必须做出全局撤销决定
只有所有参与者都同意提交事务，协调者才能做出全局提交决定
例题
D
D
C
3 数据仓库与数据挖掘
数据仓库特点
1. 面向主题：数据仓库中的数据是按主题进行组织的。主题通常代表了企业的关键业务领域，例如客户、销售、产品等。数据仓库通过整合不同来源的数据，为每个主题提供一个全面的视图。
2. 集成的：数据仓库中的数据是从多个异构数据源集成而来的。在集成过程中，消除了源数据中的不一致性，保证了整个企业数据的一致性和完整性。
3. 相对稳定的（非易失的）：数据仓库主要用于查询和分析操作，数据在进入数据仓库后很少被修改或删除，更多的是进行追加操作。数据仓库中的数据是历史数据的集合，保持相对稳定性。
4. **反映历史变化（随时间变化）**：数据仓库记录了企业在不同时间点上的信息，能够反映出企业的历史变化情况。这些历史数据可以用于分析和预测企业的未来趋势。
这些特点使得数据仓库成为企业进行历史数据分析、决策支持和趋势预测的重要工具。
数据处理与分析流程
阶段1：数据预处理（ETL）
- ETL过程：ETL代表“提取（Extract）、转换（Transform）和加载（Load）”。这一阶段的主要任务是从数据源中提取数据，对数据进行清理和转换处理，最后将处理后的数据加载到数据仓库中。图片中提到的操作包括“抽取、清理、装载、刷新”等，这些都是ETL的关键步骤。
阶段2：数据仓库存储
- 数据仓库：在ETL处理完成后，数据被存储在数据仓库中。数据仓库是一个专门设计来支持数据分析和报告的系统。它整合了来自多个来源的数据，确保数据的一致性和完整性。
阶段3：数据分析
-
OLAP服务器：图中展示了“OLAP服务器”用于进行联机分析处理（Online Analytical Processing）。OLAP服务器通过多维数据模型支持复杂的查询和分析操作，允许用户从不同的角度查看数据。
-
分析操作
：图片中特别提到了“上卷、下钻和旋转分析”，这些是OLAP分析中的常用操作：
- 上卷（Roll-up）：聚合数据，查看更高级别的摘要信息。
- 下钻（Drill-down）：分解数据，查看更细粒度的详细信息。
- 旋转分析（Pivot）：改变分析维度的顺序，以不同角度查看数据。
-
查询报表和数据分析：这些是基于OLAP的分析结果，可以生成详细的查询报表，或进行进一步的数据分析。
-
数据挖掘：图中还提到数据挖掘，这是利用统计学、机器学习等方法从数据中提取潜在的、有价值的模式或知识的过程。
阶段4：数据展现
- 数据展现：数据分析和挖掘的结果最终以可视化方式展现出来，如图中右下角所示。这个阶段旨在将分析结果转化为业务洞察，辅助决策和预测。
例题
在数据挖掘中，主要任务通常包括以下几个方面：
- 聚类分析：
- 聚类是将相似的数据对象归为一类，而不需要事先知道这些数据的类别标签。它用于发现数据中的自然分组或模式。
- 例如，将客户根据购买行为分为不同的群体。
- 分类分析：
- 分类是基于已知的类别标签，构建模型来预测新数据点所属的类别。这通常用于预测或识别数据的类别。
- 例如，根据病人的症状来预测病人可能患有的疾病。
- 关联规则挖掘：
- 关联规则挖掘用于发现数据项之间的有趣关联或模式，通常用于揭示哪些项经常一起出现。
- 例如，超市中的购物篮分析，可以发现“买了面包的人通常会买牛奶”这样的关联规则。
选项分析：
- A 选项：聚类分析、联机分析、信息检索等
- 联机分析（OLAP）和信息检索更多是数据分析或数据查询的任务，不属于典型的数据挖掘任务。
- B 选项：信息检索、聚类分析、分类分析等
- 信息检索虽然与数据相关，但更偏向于从数据库或文档库中查询信息，不是数据挖掘的核心任务。
- C 选项：聚类分析、分类分析、关联规则挖掘等
- 这是典型的数据挖掘任务，涵盖了数据挖掘中常用的三种分析方法，符合数据挖掘的定义和应用场景。
- D 选项：分类分析、联机分析、关联规则挖掘等
- 联机分析（OLAP）虽然涉及数据分析，但它的主要作用是多维数据的快速查询和汇总，而不是揭示隐藏的模式或关系，更多是数据分析而非数据挖掘。
4 数据库设计过程
数据库设计是一个系统化的过程，通常包括四个主要阶段：需求分析、概念结构设计、逻辑结构设计和物理设计。这些阶段相互关联，形成了从业务需求到实际数据库实现的全过程。下面是各个阶段的详细分析及其联系：
1. 需求分析
概念：
• 需求分析是数据库设计的起点。它的主要目标是理解和定义业务需求，确定系统需要存储的数据类型及其之间的关系。
• 在这个阶段，设计者与业务人员、用户沟通，收集业务需求，识别数据需求和处理流程。
内容：
• 确定数据的基本实体（如用户、订单、产品）及其属性（如用户的姓名、订单的日期）。
• 理解数据之间的关系（如用户和订单之间的关系）。
• 识别系统的业务规则和约束条件。
输出：
• 需求规格说明书：详细描述业务需求和数据需求的文档，包括数据实体、属性、关系、业务规则和约束条件等。
• 数据流图（DFD）：用于展示数据在系统中的流动和处理过程，帮助理解数据的输入、处理和输出过程。
• 数据字典：定义数据项的详细描述，包括数据类型、格式和约束条件等，以确保数据的一致性和准确性。
• 业务需求文档：记录业务功能和操作流程的文档，确保数据库设计能够满足实际业务需求。
2. 概念结构设计
概念：
• 概念结构设计是在需求分析的基础上，创建一个高层次的数据库模型，通常使用实体-关系（ER）模型或对象-关系模型（ORM）。
• 目标是将业务需求转化为概念模型，描述数据的实体、属性及它们之间的关系。
内容：
• 构建ER图或其他概念模型图，明确实体及其属性。
• 设计实体之间的关系（如一对多、多对多关系）。
• 定义实体的主键和外键。
输出：
• 概念数据模型（ER图等）。
3. 逻辑结构设计
概念：
• 逻辑结构设计是将概念模型转换为具体的数据库逻辑结构，通常是关系数据库模型。
• 目标是设计出一个规范化的逻辑模型，确保数据的完整性和一致性。
内容：
• 将概念模型转换为关系模型，定义表结构、字段类型、主键和外键。
• 进行数据库规范化，减少冗余，消除数据异常。
• 设计索引和视图以优化查询性能。
输出：
• 逻辑数据模型（包括表结构、关系、约束条件）。
4. 物理设计
概念：
• 物理设计是将逻辑数据模型转换为实际的数据库实施方案。它涉及数据库的存储、访问方式及性能优化。
• 目标是优化数据库的性能，考虑存储效率和数据访问速度。
内容：
• 确定数据的存储方式（如磁盘存储、内存存储）。
• 设计数据分区、分片以及索引结构。
• 设置数据库的缓存、备份和恢复策略。
输出：
• 物理数据模型（数据库的实际实现细节，如表的存储结构、索引、分区策略）。
各阶段之间的联系
1. 需求分析提供了概念结构设计的基础，通过明确的业务需求确定数据库要存储的数据类型和关系。
2. 概念结构设计生成的高层次模型（如ER图）为逻辑结构设计提供了参考，逻辑结构设计则在此基础上进一步规范化数据结构。
3. 逻辑结构设计转化为物理设计，在物理设计阶段需要将逻辑模型中的设计转化为实际的数据库实施方案，确保性能优化和存储效率。
例题1
C
-
A. E-R图：E-R图（实体-关系图）是在概念结构设计阶段创建的，用于将需求转化为概念模型。因此，E-R图不是需求分析阶段的直接产物。
-
B. 关系模式：关系模式是逻辑结构设计阶段的产物，用于描述表结构和关系。在需求分析阶段并不需要创建关系模式。
- C. 数据字典和数据流图：数据字典和数据流图是需求分析阶段的重要文档。数据字典记录数据项的详细定义和描述，数据流图展示数据在系统中的流动和处理。这些文档有助于理解业务需求和数据处理流程，是需求分析阶段的关键输出。
- D. 任务书和设计方案：任务书和设计方案虽然是项目初期的重要文档，但它们通常不专门用于数据库设计的需求分析阶段。任务书通常定义项目目标和范围，而设计方案是根据需求分析的结果制定的规划文档。
答案是C
5 概念结构设计
5.1 E-R图
在数据库概念结构设计中，ER图（实体-联系图，Entity-Relationship Diagram）是用于展示实体、实体属性以及实体之间关系的图形化工具。ER图是数据库设计的第一步，主要用于直观地描述业务需求中的数据结构。
ER图的基本元素
- 实体（Entity）：
• 实体是指现实世界中可以区分的事物、对象或概念，它们可以是物理对象（如学生、课程）或抽象概念（如订单、合同）。
• 在ER图中，实体通常用矩形表示。
- 属性（Attribute）：
• 属性是实体或联系的某一特性或描述，例如，学生实体可能有姓名、学号、年龄等属性。
• 属性在ER图中用椭圆形表示，并与其相关的实体或联系相连。
- 主键（Primary Key）：
• 主键是一种特殊的属性，用于唯一标识实体中的每个实例。例如，学号可以作为学生实体的主键。
• 在ER图中，主键属性通常用下划线标记。
- 联系（Relationship）：
• 联系是实体之间的关联，例如，学生选课就是学生实体和课程实体之间的联系。
• 在ER图中，联系用菱形表示，并通过线条连接相关的实体。
- 联系的类型：
• 联系有三种类型：
• 一对一（1:1）：一个实体的一个实例与另一个实体的一个实例相联系。
• 一对多（1:N）：一个实体的一个实例与另一个实体的多个实例相联系。
• 多对多（M:N）：一个实体的多个实例与另一个实体的多个实例相联系。
ER图的作用
• 数据建模：ER图帮助数据库设计人员和业务分析师通过图形化的方式直观地理解数据之间的关系。
• 需求分析：ER图可以帮助更好地捕捉并理解用户的业务需求，确保数据设计满足实际需求。
• 数据库设计：ER图是数据库设计的基础，通过ER图可以很容易地将概念设计转换为逻辑设计，然后进一步细化为物理设计。
5.2 概念结构设计
- 需求分析：
• 这是概念结构设计的起点，目的是深入理解用户的业务需求，明确系统中需要处理的数据和业务逻辑。
- 抽象数据：
• 从需求分析中抽象出数据，即识别出系统中的关键实体、属性以及它们之间的关系。
- 设计局部ER模型：
• 根据抽象出的数据，开始设计局部的实体-联系（ER）模型，具体描述每个实体及其属性，并初步定义实体之间的联系。
- 合并局部模型，消除冲突：
• 将局部ER模型进行合并，整合为一个完整的全局ER模型。同时，解决不同局部模型之间可能存在的冲突，确保模型的一致性。
- 重构优化，消除冗余：
• 对全局ER模型进行重构和优化，消除冗余数据和不必要的复杂性，以提高模型的简洁性和可维护性。
- 逻辑设计：
• 最后，基于优化后的概念结构，进入逻辑设计阶段。此阶段将概念结构转换为适合特定数据库管理系统的逻辑结构。
合并局部模型，集成的方法：
- 多个局部E-R图一次集成。
- 逐步集成，用累加的方式一次集成两个局部E-R。
集成产生的冲突及解决办法：
- 属性冲突：包括属性域冲突和属性取值冲突。
- 命名冲突：包括同名异义和异名同义。
- 结构冲突：包括同一对象在不同应用中具有不同的抽象，以及同一实体在不同局部E-R图中所包含的属性个数和属性排列次序不完全相同。
6 关系模型基本概念
数据库关系模型是一种用来表示和管理数据的结构化模型。它基于集合理论，通过“关系”的概念来组织数据。关系模型是最广泛使用的数据库模型之一，尤其在关系数据库管理系统（RDBMS）中得到了广泛应用。
6.1 数据模型
数据模型的组成部分
数据模型三要素：数据结构、数据操作、数据的约束条件。
- 数据结构：
• 数据结构定义了数据的组织方式和数据之间的关系，例如表、字段、记录、节点等。
- 数据操作：
• 数据操作定义了对数据进行增、删、改、查等操作的方法和规则。例如，SQL中的SELECT、INSERT、UPDATE、DELETE等操作。
- 数据完整性约束：
• 数据完整性约束用于确保数据的准确性、一致性和完整性。包括实体完整性（如主键约束）、参照完整性（如外键约束）和用户定义的约束（如CHECK约束）。
数据模型的分类
数据模型主要分为以下几种类型：
- 层次模型（Hierarchical Model）：
• 层次模型以树形结构组织数据，每个节点表示一个数据实体，父节点与子节点之间通过层次关系连接。
• 数据以严格的父子关系组织，一个父节点可以有多个子节点，但每个子节点只能有一个父节点。
• 例如：早期的IBM IMS数据库系统。
- 网状模型（Network Model）：
• 网状模型是层次模型的扩展，它允许数据之间存在多对多的关系，通过“结点”和“边”表示数据实体及其关系。
• 一个结点可以有多个父结点和子结点，使得数据结构更加灵活。
• 例如：CODASYL数据库模型。
关系模型（Relational Model）：
• 关系模型使用表格（二维表）来表示数据，表中的行对应数据记录，列对应属性。
• 关系模型中的每个表都表示一个关系，表之间通过外键建立关联。
• 关系模型的优点是结构化强、易于理解，并且基于数学理论（集合论和关系代数）。
• 例如：MySQL、PostgreSQL、Oracle等主流关系数据库。
- 面向对象模型（Object-Oriented Model）：
• 面向对象模型将数据表示为对象，每个对象包含数据（属性）和操作（方法）。
• 数据库中的对象通过继承、封装、多态等面向对象特性来组织和操作。
• 这种模型适合处理复杂的数据结构和业务逻辑。
• 例如：GemStone、ObjectDB等面向对象数据库。
6.2 关系模型相关概念
候选键（Candidate Key）是指在一个关系（表）中，能够唯一标识元组（记录）的最小属性集。候选键是主键的候选者，一个关系可以有多个候选键，但最终会选择一个作为主键。每个候选键都具有唯一性和最小性。
候选键的特性
- 唯一性：
• 候选键中的属性组合能够唯一标识关系中的每个元组。也就是说，候选键的每个值在表中是唯一的，不能有重复的值。
- 最小性：
• 候选键是最小的属性集，这意味着候选键中的任何一个属性都不能被移除，否则它就不再能够唯一标识关系中的元组。因此，候选键不能有多余的属性。
候选键与主键
• 主键（Primary Key）：
• 主键是从候选键中选出的一个键，用于唯一标识关系中的元组。主键值必须唯一且不能为空（NULL）。
• 每个关系只能有一个主键。
• 候选键（Candidate Key）：
• 候选键是可以作为主键的所有键的集合。一个关系可以有多个候选键，但最终只能选出一个作为主键。
• 其余的候选键可以作为备用的唯一标识符，称为备用键（Alternate Key）。
例子
假设有一个“学生”表，其中包含以下属性：
• 学号（student_id）
• 身份证号（id_number）
• 手机号（phone_number）
• 姓名（name）
在这个表中：
• student_id、id_number 和 phone_number 都可以唯一标识每个学生，因此它们都是候选键。
• 但最终只能选一个作为主键，假设选择 student_id 作为主键，id_number 和 phone_number 则成为备用键。
6.3 完整性约束
- 实体完整性（Entity Integrity）：
• 实体完整性约束保证了每个表中的行都可以通过一个唯一标识符（通常是主键）来唯一识别。
• 主键约束（Primary Key Constraint）：主键约束要求表中的某一列或一组列的值在表中是唯一的，并且这些列不能包含空值（NULL）。每个表必须有一个主键。
• 作用：防止表中出现重复的行，并确保每一行都能被唯一标识。
- 参照完整性（Referential Integrity）：
• 参照完整性约束用于确保表之间的关系有效和一致。
• 外键约束（Foreign Key Constraint）：外键是一个表中的列或列的组合，这些列的值必须来自另一表的主键或唯一键列。外键约束确保引用的记录在父表中确实存在。
• 作用：维护表之间的引用完整性，防止孤立或不匹配的引用。
- 用户自定义完整性约束
• 数据库用户根据具体业务需求，在数据库中创建的自定义规则，以确保数据的完整性和一致性。直接使用 CHECK 约束来实现自定义的完整性约束。
- 触发器（Trigger）
• 触发器是数据库中的一种特殊的存储过程，它会在特定的数据库操作（如 INSERT、UPDATE 或 DELETE）之前或之后自动执行。通过触发器，用户可以自定义复杂的业务逻辑来进行数据验证或自动更新相关数据。
例题
B
7 逻辑结构设计
- E-R图向关系模式的转换
- 实体转换为关系模式
- 联系转换为关系模式
- 关系模式的规范化
- 确定完整性约束（保证数据的正确性）
- 用户视图的确定（提高数据的安全性和独立性）
- 根据数据流图确定处理过程使用的视图
- 根据用户类别确定不同用户使用的视图
- 应用程序设计
7.1 E-R图向关系模式的转换
-
一个实体型必须转换为一个关系模式
-
联系转关系模式：
-
一对一联系的转换有两种方式。
独立的关系模式：并入两端主键及联系自身属性。（主键：任一端主键）
归并（任意一端）：并入另一端主键及联系自身属性。（主键：保持不变）
-
一对多联系的转换有两种方式。
独立的关系模式：并入两端主键及联系自身属性。（主键：多端主键）
归并（多端）：并入另一端主键及联系自身属性。（主键：保持不变）
-
多对多联系的转换只有一种方式。
独立的关系模式：并入两端主键及联系自身属性。（主键：两端主键的组合键）
例题1
最少可以转换为4个关系模式。
- 三个实体集：
• 假设有三个实体集 A、B 和 C。
• 每个实体集各自转换为一个关系模式（表）。因此，最少需要三个关系模式，分别表示实体 A、B 和 C。
2. 三者之间的多对多对多（m:n:p）联系：
• 在 E-R 模型中，三个实体集 A、B 和 C 之间存在一个多对多对多的联系。
• 这种联系不能简单地在一个实体表中添加外键来表示。为了处理这种复杂的联系，需要创建一个独立的联系表（关系模式），该表包含三个实体的主键作为外键，并且这些外键组合在一起形成联系表的主键。
例题2
第一问：D
第二问：C
第三问：A
8 关系代数
关系代数的基本运算可以分为两类：基本集合运算和关系运算。
1. 基本集合运算
• 并（Union, ∪）:
• 作用：返回两个关系的并集。
• 要求：两个关系必须是并兼容的，即它们具有相同的属性数目和对应属性的数据类型相同。
• 示例：R ∪ S，返回关系 R 和 S 的并集。
• 差（Difference, −）:
• 作用：返回在第一个关系中存在但在第二个关系中不存在的元组。
• 要求：两个关系必须是并兼容的。
• 示例：R − S，返回在关系 R 中但不在关系 S 中的元组。
• 交（Intersection, ∩）:
• 作用：返回两个关系的交集。
• 要求：两个关系必须是并兼容的。
• 示例：R ∩ S，返回关系 R 和 S 中共同存在的元组。
• 笛卡尔积（Cartesian Product, ×）:
• 作用：返回两个关系的笛卡尔积，生成所有可能的元组组合。
• 示例：R × S，返回关系 R 和 S 的所有可能组合的元组。
2. 关系运算
• 选择（Selection, σ）:
• 作用：从关系中选出满足指定条件的元组。
• 表示：σ®
• 示例：σage > 30(Employees)，选出 Employees 关系中 age 大于 30 的元组。
• 投影（Projection, π）:
• 作用：从关系中选出指定的属性列。
• 表示：π®
• 示例：πname, age(Employees)，返回 Employees 关系中的 name 和 age 属性列。
• 连接（Join, ⨝）:
• 自然连接（Natural Join, ⨝）:
• 作用：将两个关系中具有相同属性的元组连接在一起，只保留一个属性，并返回匹配的元组。
• 示例：R ⨝ S，返回关系 R 和 S 中匹配的元组。
• 等值连接（Equi-Join, ⨝）:
• 作用：类似自然连接，但保留所有匹配属性。
• 示例：R ⨝ R.a = S.a S，返回在属性 a 上相等的元组。
• 划分（Division, ÷）:
• 作用：用于处理”所有”的查询。例如，返回那些在一个关系中与另一个关系的所有元组相关联的元组。
• 示例：R ÷ S，返回在关系 R 中与 S 的每一个元组都相关联的元组。
上述公式第一个才是自然连接的等值公式。
例题1
第一问：D
第二问：C
例题2
在同等条件下自然连接性能是要优于笛卡尔积的。
但是题目中E2最终的自然连接条件是R.A2 = S.A2 ^ R.A3 = S.A3，而E4中 只有R.A3 = S.A3，E2的条件是要多余E4的，所以这里选择的是E4；
如果是同等条件下，E4的选择条件是R.A2 = S.A2 ^ R.A3 = S.A3，那么E2的性能是要优于E4的。
例题3
第一问：B
第二问：C
9 规范化理论
价值和用途
9.1 函数依赖
- 定义
在一个关系模式 R 中，如果属性集 Y 的值唯一地决定了属性集 Z 的值，则称 Y 到 Z 存在函数依赖关系，记作：Y -> Z
这意味着对于 R 中的每一对元组，如果它们在 Y 上的值相同，那么它们在 Z 上的值也必须相同。
• 完全函数依赖：
• 如果 Z 完全依赖于 Y，且 Y 是一个最小的决定 Z 的属性集，则称这种依赖为完全函数依赖。
• 举例：在一个包含学生信息的关系中，假设有属性集 {学生ID, 课程ID} 和 属性 成绩。成绩完全依赖于 {学生ID, 课程ID}，而不是单独依赖学生ID 或 课程ID。
• 部分函数依赖：
• 如果属性集 Y 的某一子集也能决定属性 Z 的值，则称 Z 对 Y 存在部分函数依赖。
• 举例：在同样的学生信息表中，假设课程名称部分依赖于 课程ID，因为课程名称不需要学生ID 就可以被确定。
• 传递函数依赖：
• 如果存在 Y → Z，且 Z → W，则 Y → W 是传递函数依赖。
• 举例：如果我们有一个学生的关系模式，其中学生ID 决定班级，班级决定班主任，那么学生ID 传递决定班主任。
9.2 求候选键
- 将关系模式的函数依赖关系用“有向图”的方式表示
- 找入度为0的属性，并以该属性集合为起点，尝试遍历有向图，若能正常遍历图中所有结点，则该属性集即为关系模式的候选键
- 若入度为0的属性集不能遍历图中所有结点，则需要尝试性的将一些中间结点
（既有入度，也有出度的结点）并入入度为0的属性集中，直至该集合能遍历所有结点，集合为候选键
例1：A
例2：ABCD
例3：B
9.3 Armstrong 公理
Armstrong 公理（Armstrong’s Axioms）是关系数据库中用于推导和验证函数依赖的一组推理规则。这些公理由 William W. Armstrong 在 1974 年提出，用来构造和推导数据库关系模式中的函数依赖集合。通过使用 Armstrong 公理，我们可以推导出关系模式中所有隐含的函数依赖。
例题
C
9.4 范式判断
1. 第一范式（1NF, First Normal Form）
• 判断标准：表中的每一列都必须是原子的，也就是说，每一个字段的值都不能再分为多个部分。
• 例子：表格中的每一个单元格都只包含一个值，不能包含多个值或重复的组。
2. 第二范式（2NF, Second Normal Form）
• 判断标准：表必须符合第一范式，并且所有非主键属性完全依赖于主键。换句话说，表中不应存在任何部分依赖。
• 例子：在一个表中，假设主键由多个字段组成（联合主键），所有非主键字段都必须依赖于整个主键，而不仅仅是其中的一部分。
拆分表（学号，课程号，成绩）、（课程号，学分）
3. 第三范式（3NF, Third Normal Form）
• 判断标准：表必须符合第二范式，并且不存在传递依赖。即非主键字段不应依赖于其他非主键字段。
• 例子：如果字段 A 依赖于字段 B，而字段 B 又依赖于主键，那么应将 A 和 B 分成不同的表。
拆分表（学号，姓名，系号）（系号，系名，系位置）
4. BC范式（BCNF, Boyce-Codd Normal Form）
• 判断标准：表必须符合第三范式，并且对于每一个函数依赖，左边的属性集必须是超键（即它唯一地标识表中的一行）。
• 例子：在一些复杂的情况下，即使符合第三范式，仍然可能存在一些异常，BCNF 就是在这种情况下应用的更强的范式。
例题
第一问：C
第二问：A
9.5 模式分解
9.5.1 是否保持函数依赖
保持函数依赖分解
设数据库模式p={R1，R2，⋯，Rk}是关系模式R的一个分解，F是R上的函数依赖集，p中每个模式Ri上的FD集是Fi。如果{F1，F2，⋯，FK}与F是等价的（即相互逻辑蕴涵），那么称分解p保持FD。
如何判断函数依赖是否保持？
对于一个关系模式 R，其具有函数依赖集 F。如果我们将 R 分解为多个子模式 R1, R2, …, Rn，要判断函数依赖是否保持，我们可以遵循以下步骤：
1. 检查每个子模式中的依赖关系：对于原始的函数依赖集 F 中的每一个依赖 X -> Y，如果存在某个子模式 Ri，其中包含 X 和 Y，则该依赖在 Ri 中是保持的。
2. 合成函数依赖集：对分解后的子模式计算它们的闭包，得到每个子模式的新函数依赖集 Fi。然后检查这些子模式依赖集 F1, F2, …, Fn 的并集是否能够覆盖原始依赖集 F。
3. 无损性检查：在保证依赖保持的前提下，还需要确保模式分解是无损连接的，即通过连接操作可以恢复原始的关系数据。
保持函数依赖的例子
假设我们有一个关系模式 R(A, B, C)，其函数依赖集为 { A -> B, B -> C }。我们尝试将 R 分解成 R1(A, B) 和 R2(B, C)。
• 在 R1(A, B) 中：依赖 A -> B 是可检查的，因为 A 和 B 都在 R1 中。
• 在 R2(B, C) 中：依赖 B -> C 是可检查的，因为 B 和 C 都在 R2 中。
因此，原始依赖集 { A -> B, B -> C } 可以在分解后的两个子模式 R1 和 R2 中分别检查，这意味着该分解保持了函数依赖。
不保持函数依赖的例子
现在假设我们有一个关系模式 R(A, B, C)，其函数依赖集为 { A -> B, A -> C }。我们尝试将 R 分解成 R1(A, B) 和 R2(B, C)。
• 在 R1(A, B) 中：依赖 A -> B 是可检查的。
• 在 R2(B, C) 中：依赖 A -> C 无法检查，因为 A 不在 R2 中。
此时，分解后的子模式无法直接检查 A -> C 这个依赖，必须通过连接 R1 和 R2 才能验证该依赖。这意味着该分解没有保持函数依赖。
9.5.2 无损分解
无损连接分解：指将一个关系模式分解成若干个关系模式后，通过自然联接和投影等运算仍能还原到原来的关系模式
无损分解的条件
无损分解的一个核心思想是确保数据在分解后不会被“割裂”，即通过对分解后的表做连接时，不会产生比原始表更多或更少的数据。为了实现这一点，通常需要满足一些条件。
假设我们将关系模式 R(A, B, C) 分解为 R1(A, B) 和 R2(B, C)，对于分解是无损的，必须满足函数依赖或者候选键的条件之一：
1. 交集属性是候选键：在分解前，原始模式 R 中交集的属性（如 B）必须是某一个子模式的候选键。这意味着在 R1 或 R2 中，交集属性能够唯一标识其中的记录。
2. 保持依赖性：如果在某个模式中存在函数依赖 X -> Y，那么这个函数依赖必须保持在分解后的子模式中。例如，如果 A -> B 在 R1 中保持成立，那么分解可以是无损的。
无损分解的例子
假设我们有一个关系模式 R(A, B, C)，其中存在如下函数依赖：
• A -> B
• B -> C
现在我们将 R 分解为 R1(A, B) 和 R2(B, C)。
无损连接步骤：
• 通过连接 R1 和 R2，使用共同属性 B 进行连接，我们可以恢复原始的模式 R(A, B, C)。
• 由于 B 是交集属性，而在 R1 中 A -> B 是成立的，因此 B 是 R1 的候选键，这保证了分解是无损的。
因此，这个分解是无损连接分解，因为我们可以通过连接 R1 和 R2 完整恢复原始的关系数据。
无损分解的例子（二）
假设有一个关系模式 R(A, B, C)，其中没有任何函数依赖。我们尝试将其分解为 R1(A, B) 和 R2(B, C)。
分解验证：
1. R1 和 R2 的交集属性为 B，但 B 既不是 R1 的候选键，也不是 R2 的候选键。
2. 由于无法确定交集属性 B 是候选键，且没有依赖关系可以保持，因此无法确定连接操作后会得到正确的原始数据。
因此，这种分解可能是有损的，因为通过连接操作无法无损地恢复原始数据。
表格法确定是否是无损分解
例题1
第一问：D
第二问：A
例题2
第一问：存在部分函数依赖，不满足第二范式，选A
第二问：D
10 并发控制
10.1 并发产生的问题
并发控制的引入是为了避免以下问题：
-
丢失更新（Lost Update）：两个事务同时读取同一数据项并进行修改，导致一个事务的更新被另一个事务覆盖。
-
脏读（Dirty Read）：一个事务读取了另一个未提交事务修改的数据。如果后者回滚，前者读到的就是无效数据。
-
不可重复读（Non-repeatable Read）：一个事务在多次读取同一数据项时，因其他事务修改该数据，导致前后读取的值不一致。
-
幻读（Phantom Read）：一个事务在读取数据的某个范围时，另一事务插入了该范围内的新数据，导致前后查询结果不一致。
10.2 事务的ACID特性
- 原子性（Atomicity）
原子性指事务是一个不可分割的最小操作单元，要么全部执行成功，要么全部失败回滚。即使事务中的某个操作失败，也不会对数据库产生任何影响，确保操作的完整性。
- 一致性（Consistency）
一致性指事务执行前后，数据库都必须处于一致的状态。事务的操作不会违反数据库的约束条件或规则，保证数据的正确性。比如，在一个账户转账的操作中，即使发生异常，账户的总金额仍然保持不变。
- 隔离性（Isolation）
隔离性指多个事务并发执行时，一个事务的执行不能被其他事务干扰，即事务之间是相互独立的。数据库系统通过隔离级别（如读未提交、读已提交、可重复读、序列化）来控制事务之间的相互影响。
- 持久性（Durability）
持久性指一旦事务提交，数据的变更将永久保存到数据库中，即使系统崩溃或出现故障，事务的结果也不会丢失。数据库通过日志、备份等机制确保数据的持久性。
10.3 封锁协议
- 一级封锁协议
一级封锁协议要求事务 T 在修改数据 R 之前，必须先对 R 加排他锁（X 锁）。并且直到事务结束，事务才会释放这个排他锁。通过这种方式，一级封锁协议可以防止丢失修改（Lost Update）问题，即一个事务的修改被另一个并发事务覆盖。
作用： 防止丢失修改。
- 二级封锁协议
二级封锁协议在一级封锁协议的基础上增加了以下要求：事务 T 在读取数据 R 之前，必须先对 R 加共享锁（S 锁）。读取完成后，事务可以立即释放共享锁。通过这个协议，可以防止丢失修改，并且防止读取到其他事务尚未提交的“脏数据”。
作用： 防止丢失修改和读“脏”数据。
- 三级封锁协议
三级封锁协议是在一级封锁协议的基础上进一步要求：事务 T 在读取数据 R 之前，必须先对 R 加共享锁（S 锁），并且该共享锁直到事务结束才能释放。这样可以防止丢失修改、读到“脏”数据，还可以防止事务在多次读取过程中读到不一致的数据（避免不可重复读问题）。
作用： 防止丢失修改、读“脏”数据，以及防止不可重复读。
- 两段锁协议（Two-Phase Locking, 2PL）
两段锁协议保证了事务的可串行化性，即事务可以并发执行，但执行结果等同于按某种顺序串行执行的结果。2PL 协议分为两个阶段：
• 加锁阶段（扩展阶段）： 事务可以获取锁（S 锁或 X 锁），但不能释放任何锁。
• 解锁阶段（收缩阶段）： 一旦事务开始释放锁，不能再获取任何锁。
这种协议虽然保证了事务的可串行化，但也可能引发死锁问题，即两个事务相互等待对方释放锁，导致事务无法继续执行。
作用： 保证可串行化，但可能引发死锁。
11 数据库的安全性
C. 存储过程。
存储过程是一组预编译的SQL语句，可以在数据库中执行复杂的操作。通过使用存储过程，数据库管理员可以提供给第三方开发人员一个固定的接口来进行数据更新，而不直接暴露数据库的表结构或关系模式。这可以有效地保护数据库的安全，防止第三方获取底层的关系模式。
视图（B 选项）也可以隐藏底层表结构，但主要用于数据查询，而不是执行更新操作。
12 数据库备份与恢复技术
12.1 数据备份
数据库备份方式
- 冷备份（Cold Backup，静态备份）
• 定义：冷备份是指在数据库正常关闭、停止运行的状态下，将所有数据库文件完整地备份下来。这种方式通常用于数据库在非工作时间的维护。
• 特点：
• 数据库处于关闭状态，确保数据一致性，无需担心数据读写操作冲突。
• 适合数据更新不频繁或允许系统停机的场景。
• 恢复简单，因为备份的数据处于静态状态，容易确保恢复后数据库的一致性。
• 缺点：
• 备份期间需要关闭数据库，无法进行读写操作，适用于停机维护。
• 对于高可用性要求的业务不适用。
- 热备份（Hot Backup，动态备份）
• 定义：热备份是在数据库运行的状态下进行的备份，通常是通过备份软件在数据库正常提供服务的过程中将数据文件备份出来。这种方式允许备份操作与数据库的正常读写操作同时进行。
• 特点：
• 备份时数据库仍然可以提供服务，业务不中断，适合需要高可用性的场景。
• 通常使用日志文件（如 MySQL 的 binlog、Oracle 的 redo log）来保证备份数据的一致性。
• 备份过程比较复杂，需要确保在数据读写过程中一致性得到维护。
• 缺点：
• 热备份需要更多的资源来保持数据库正常运行，并且对备份的一致性有更高的要求。
• 恢复过程中，可能需要恢复数据文件并回滚日志文件以确保数据的一致性。
备份类型
1. 完全备份（Full Backup）
• 定义：完全备份会将整个数据库中的所有数据（包括数据文件、日志文件等）一次性完整备份下来，无论数据是否发生变化。
• 优点：恢复简单，因为所有数据都在一个备份集中。
• 缺点：备份耗时长，占用大量存储空间。
2. 差量备份（Differential Backup）
• 定义：差量备份仅备份自上一次完全备份以来发生变化的数据。每次差量备份都会包含自上一次完全备份后所有更改的数据。
• 优点：比完全备份快，占用空间较少。
• 缺点：随着时间的推移，差量备份的体积会逐渐增加，因此可能会越来越大，恢复时需要先恢复完全备份，然后恢复最后一次差量备份。
3. 增量备份（Incremental Backup）
• 定义：增量备份仅备份自上一次任何类型的备份（无论是完全备份还是增量备份）以来发生变化的数据。每次增量备份只保存自上次备份后新增或修改的部分数据。
• 优点：速度快，节省存储空间。
• 缺点：恢复过程相对复杂，因为需要从完全备份开始，依次应用所有增量备份，才能恢复到最新状态。
日志文件
• 定义：日志文件是记录数据库中的每一个操作（如插入、更新、删除等）的文件。它们通常用于事务恢复或数据恢复。当数据库发生故障或意外关闭时，日志文件中的记录可以用来恢复未提交或损坏的事务。
• 作用：
• 事务管理：日志文件记录事务的开始、提交、回滚等信息，确保在故障发生时可以根据日志回滚未完成的事务，保持数据库的一致性。
• 数据恢复：日志文件可以帮助将数据库恢复到某个特定时间点（如使用 MySQL 的 binlog 进行时间点恢复）。
• 优点：通过日志文件，可以在数据库崩溃或出错时回滚错误操作，恢复未提交的事务，或重新应用提交的事务。
• 常见类型：
• 重做日志（Redo Log）：记录已提交的事务，用于恢复未持久化到磁盘的数据。
• 回滚日志（Undo Log）：记录未提交的事务，用于在事务回滚时撤销未提交的更改。
常见备用策略
先找最近的全备，再找最近的差备，没有差备就找增备
例子
B
12.2 数据库故障与恢复
撤销事务（UNDO）：故障发生时未完成的事务，放入Undo撤销。
重做事务（REDO）：故障发生前已提交的事务，放入Redo重做。
13 数据库的性能优化
一、集中式数据库优化
集中式数据库主要依赖单一服务器来处理所有数据库操作，因此优化的关键在于合理利用系统资源、精心设计数据库结构、优化 SQL 查询等方面。以下是进一步的优化策略：
1. 硬件系统优化
• CPU 优化：选择更高性能的多核 CPU，可以加速并发处理。
• 内存优化：增加内存容量，使得更多数据可以被缓存，减少磁盘 I/O 操作。特别是对于频繁查询的数据，内存中缓存的命中率越高，性能越好。
• I/O 优化：使用 SSD 代替传统硬盘，能够显著提升读写性能。对于大规模并发读写操作场景，可以使用 RAID 技术（如 RAID 10），提升数据存取的并发能力和可靠性。
• 网络优化：提升带宽、优化数据库和应用层之间的网络连接，减少查询和数据传输的延迟。
2. 系统软件优化
• 操作系统参数调优：调整操作系统的进程优先级、IO 调度策略，保证数据库进程获得更多 CPU 时间片和更低的 IO 延迟。
• 数据库管理系统（DBMS）参数调优：
• 调整数据库的内存缓冲区大小，例如 MySQL 的 InnoDB 缓冲池（Buffer Pool），以便数据库能缓存更多的热数据。
• 调整并发连接数、线程池大小等参数，确保系统能够高效处理并发请求。
3. 数据库设计
• 表与视图设计：数据库表设计时要尽量避免冗余，使用规范化的方式设计表结构。如果在查询时需要进行复杂的关联查询，可以通过视图预定义查询逻辑，减少客户端的复杂性和重复查询操作。
• 视图的优化：使用物化视图（Materialized View），将频繁查询的结果预先计算并存储，以减少实时计算的开销。
• 索引优化：
• 创建索引时应针对经常查询的列，特别是 WHERE、JOIN 和 ORDER BY 子句中的列。
• 避免在经常被修改的列上创建索引，因为每次插入或更新数据时，索引都需要重新维护，会增加开销。
• 对于复合索引，注意列的顺序，应该将选择性高的列放在最前面。
• 分区表：当单表数据量很大时，可以根据时间、区域等条件对表进行分区，分区表可以显著提高查询和更新性能。
4. SQL 查询优化
• 避免相干子查询：相干子查询（Correlated Subquery）会对每一行执行一次子查询，计算量大，效率低下。应使用 JOIN 或 EXISTS 代替相干子查询。
• 只查询必要的列：避免使用 SELECT *，只查询需要的字段，这样能减少网络传输和内存占用。
• 优化 IN 子句与 OR 条件：对于 IN 子句的优化，可以使用 JOIN 来替代。尽量避免使用多个 OR 条件，因为 OR 会降低索引的效率，推荐使用联合索引或 IN 来替代。
• 事务优化：尽可能缩短事务的执行时间，减少锁定资源的时间。频繁的 COMMIT 和 ROLLBACK 有助于释放锁资源，提升并发处理性能。
• 索引提示：在查询中可以使用索引提示（Index Hint），显式地指定使用哪个索引，避免数据库误用不合适的索引。
5. 应用软件层优化
• 数据库连接池：设置合理的数据库连接池大小（如 DBCP、HikariCP 等），连接池的配置能减少频繁创建和销毁连接的开销，并提升并发性能。
• 缓存机制：引入 Redis、Memcached 等分布式缓存，将常用查询结果缓存，减少数据库压力。
二、分布式数据库优化
分布式数据库将数据分散存储在多个节点上，通过分片、复制和一致性协议处理大规模数据。优化的关键在于减少节点之间的通信延迟、优化查询计划、以及处理分布式事务的一致性问题。
1. 通信代价优化
• 全局查询树的转换：在分布式查询中，尽量减少跨节点查询的次数，通过将查询树进行优化转换，最大程度减少节点间通信，提升查询效率。
• 查询副本策略：在分布式环境下，可以通过多副本策略，将读操作分散到多个节点处理，减轻单个节点的压力，提升读性能。
• 查询树分解：将复杂的查询拆分成多个小查询，分别在不同的节点上执行，最后将结果合并。这样的查询分解可以减少跨节点数据传输的开销。
• 半连接与直接连接：减少节点间的数据传输可以通过半连接优化。例如只在需要时将部分数据传输到其他节点，而非传输整个数据集。直接连接则可以减少中间节点的中转步骤，缩短传输路径。
2. 数据分片与分区
• 水平分片：根据主键、哈希或业务字段，将数据水平分片，分布到不同的节点上，能够有效提高并发写入的性能，避免单节点过载。
• 垂直分片：将不同业务模块的数据按功能拆分到不同节点上，例如订单数据存储在一个分片，用户数据存储在另一个分片，这样可以减轻单个节点的负载压力。
• 动态分片：当数据量逐渐增大时，可以动态调整分片策略，或者增加新的分片节点，避免单个节点性能瓶颈。
3. 复制与一致性
• 主从复制：主节点负责写入，从节点负责读取操作，读写分离可以提升系统的整体吞吐量。
• 异步复制：采用异步复制可以提升写操作的性能，但需要权衡一致性问题。对于高可用系统，可以选择半同步复制或最终一致性模型来保证性能和一致性的平衡。
• 多主复制：对于高并发写入场景，多主复制可以分担写压力，但需要额外处理冲突解决和数据一致性问题。
4. 分布式事务与容错
• 两阶段提交（2PC）与三阶段提交（3PC）：虽然 2PC 和 3PC 能保证事务的原子性，但会引入一定的延迟和开销。分布式系统通常通过弱一致性协议（如 Paxos、Raft）在性能和一致性之间取得平衡。
• 幂等操作：分布式系统中可以通过幂等设计减少重复执行操作的副作用。例如，通过唯一的事务 ID 或版本控制来确保操作只执行一次，提升系统的容错性和稳定性。
扫一扫
1923
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
