数据库系统

2025-02-23  本文已影响0人  bowen_wu

基本概念

三级模式（Three-Level Schema）

数据库三级模式（Three-Level Schema）是指数据库中数据的抽象层次结构，定义了不同的模式（Schema）层次以及它们之间的映射关系。其关键目的是通过层次化设计实现数据的独立性，简化数据库的管理与应用开发。在此架构中，两层映射关系指的是不同层次之间如何互相转换、传递数据，并保证数据的一致性和透明性。

三层模式体系结构

内部模式（Internal Schema）

概念模式（Conceptual Schema）

外部模式（External Schema）

两层映射关系

在三级模式结构中，映射关系是：

外部模式与概念模式之间的映射

概念模式与内部模式之间的映射

三层模式特点

关系表类型

数据库视图（View）

数据库视图是一个虚拟的表，它是通过一个或多个数据库表的查询结果定义的。视图本身并不存储数据，而是通过查询语句动态地从基础表中获取数据。视图用于简化复杂查询、增强数据安全性以及支持逻辑抽象。

视图的特点

  1. 虚拟表：视图是一个虚拟的表，数据并不存储在视图本身中，而是基于查询时从基础表中动态生成的。
  2. 简化查询：视图可以将复杂的查询封装成简单的查询接口，使用户和应用程序能够更加方便地访问数据。
  3. 提高数据安全性：视图可以限制用户访问表中的敏感数据，通过只展示必要的数据列和行来保护底层数据。
  4. 支持逻辑抽象：通过视图，用户可以将多个表的数据结合在一起，进行更高层次的数据抽象，从而提高应用的灵活性。
  5. 更新限制：某些情况下，视图的内容是不可更新的，尤其是当视图涉及多个表的连接、聚合函数或分组时。并不是所有视图都支持更新操作。

视图的优缺点

优点：

  1. 简化查询：视图能够封装复杂的查询逻辑，使得用户可以以更简洁的方式获取结果。
  2. 数据安全性：通过视图可以限制对敏感数据的访问，仅提供必要的列和行。
  3. 一致性：视图能够提供一致的查询接口，特别是在底层表结构发生变化时，只要视图定义不变，应用程序的查询代码也无需修改（逻辑独立性）。
  4. 抽象性：通过视图，可以将底层数据模型抽象出来，简化对数据库的操作。

缺点：

  1. 性能开销：每次访问视图时，底层的查询会重新执行，可能会影响性能。尤其对于复杂视图，性能可能较差。
  2. 更新限制：对于涉及多个表的视图，通常不支持直接更新操作，限制了其灵活性。
  3. 维护复杂性：如果视图的定义非常复杂或涉及多个表，在表结构变化时需要小心维护视图的有效性。

物化视图（Materialized View）

集中式数据库

分布式数据库

分布式数据库是将数据存储在多个物理位置的数据库管理系统（DBMS），这些数据可以分布在不同的计算机或地理位置。它通常由多个节点组成，每个节点可以是一个物理服务器或者一个虚拟实例，彼此通过网络连接。

特点

  1. 数据独立性：除了数据的逻辑独立性和物理独立性之外，还有数据分布独立性（分布透明性）
  2. 集中与自治共享结合的控制结构：各局部的 DBMS 可以独立地管理局部数据库，具有自治功能，同时系统又设有集中控制机制，协调各局部 DBMS 的工作，执行全局应用
  3. 适当增加数据冗余度：在不同的场地存储同一数据的多个副本，可以提高系统的可靠性和可用性，同时也能提高系统性能。（提高系统的可用性，即当系统中某个节点发生故障时，因为数据有其他副本在非故障场地上，对其他所有场所来说，数据仍然是可用的，从而保证数据的完备性）
  4. 全局的一致性、可串行性和可恢复性

结构

分布式数据库结构

全局概念模式（Global Conceptual Schema）

全局概念模式是一个逻辑层，它定义了整个分布式数据库系统中所有数据的整体结构和关系。它描述了数据库中所有的数据元素及其相互关系，是所有局部模式（local schemas）的集成，并不关心数据的物理存储方式或分布位置。全局概念模式提供的是数据的统一逻辑视图。

全局外模式（Global External Schema）

全局外模式是用户视图层，它为不同的用户或应用程序提供了定制化的数据视图。全局外模式定义了特定用户或应用程序如何访问和操作全局概念模式中定义的数据，但不会影响全局概念模式本身。

管理系统组成

管理系统结构

数据分片（Data Sharding）

将数据划分成多个独立的部分，每个部分称为“分片” (Shard)，并将这些分片分布在多个数据库节点上进行存储。通过这种方式，可以提高数据库系统的可扩展性、性能和可用性，减少单个节点的负载，从而支持更高的并发和大规模的数据处理。

类型

分片类型 说明 优势 挑战 适用场景
水平分片 按行划分数据 高可扩展性，分布均匀 复杂查询，数据倾斜 数据量大，增长快速的应用
垂直分片 按列划分数据 提高查询效率，数据访问优化 需要精确控制每列的访问频率 各列数据访问频率差异较大的表
哈希分片 按哈希值划分数据 数据分布均匀，负载均衡 查询复杂性较高，跨分片查询 高并发，数据量大，查询负载均匀
范围分片 按数据范围划分 简单直观，适用于范围查询 数据倾斜，查询可能不均匀 范围查询为主，数据分布较均匀
水平分片（Horizontal Sharding）

将数据表中的行（记录）划分成多个部分，每一部分存储在不同的服务器上。每个分片存储表中的一部分数据，通常基于某个字段（例如，ID、地区等）来决定哪些数据存储在哪个分片上。

垂直分片（Vertical Sharding）

将数据表中的列划分成多个部分，存储在不同的分片中。每个分片存储表的不同列。

哈希分片（Hash Sharding）

根据哈希函数将数据分布到不同的分片上。哈希函数根据某个字段的值（通常是主键）计算一个哈希值，然后将数据根据该哈希值存储到不同的分片中。

范围分片（Range Sharding）

将数据根据某个字段的值的范围划分为多个分片。例如，将用户数据按用户ID、创建时间等字段的范围划分成不同的分片。

混合分片（Hybrid Sharding）

混合分片策略是指在一个系统中同时采用多种分片策略，将其优点结合使用，以应对不同的数据分布和访问模式。

分片类型 组合方式 优势 挑战 适用场景
水平分片 + 范围分片 先按某字段进行水平分片，再在每个分片中进行范围分片 支持高效的范围查询，数据均匀分布 跨范围查询的复杂性，可能出现数据倾斜问题 时间序列数据、按日期分布的数据
水平分片 + 哈希分片 先按某字段进行水平分片，再在每个分片内进行哈希分片 负载均衡，数据均匀分布 跨分片查询复杂性，增加了哈希计算开销 大规模并发查询，负载均衡要求较高的场景
垂直分片 + 水平分片 先按列进行垂直分片，再按行进行水平分片 列访问优化，行数据扩展性高 列和行的分配需要精细控制 列访问频率差异较大的应用，如电商商品表
范围分片 + 哈希分片 先按范围进行分片，再在每个范围内进行哈希分片 高效范围查询和负载均衡 需要解决跨分片查询的性能瓶颈 大数据量的范围查询，数据分布不均匀的情况

分布透明性

两阶段提交协议（2PC，Two-Phase Commit Protocol）

一种常用于分布式数据库中的协议，确保在分布式系统中，事务的原子性得到保证。它的主要目的是确保所有参与者（节点）在分布式事务中要么全部提交，要么全部回滚，避免部分成功、部分失败的情况。

第一阶段：表决阶段（Voting Phase）

  1. 事务协调者（通常是发起事务的节点）向所有参与者（即涉及的数据库节点）发送一个请求，询问它们是否可以准备提交事务。
  2. 每个参与者节点会根据自己的状态做出响应：
    • 如果可以提交事务，参与者节点会准备好提交，发送一个“准备提交”信号（Vote: Yes）。
    • 如果参与者节点遇到任何问题，无法提交事务，它会发送一个“拒绝”信号（Vote: No）。

第二阶段：执行阶段（Execution Phase）

  1. 协调者收到所有参与者的响应后：
    • 如果所有参与者都返回“准备提交”，协调者会发出“提交”信号，指示所有节点提交事务。
    • 如果有任何参与者返回“拒绝”，协调者会发出“回滚”信号，指示所有节点回滚事务。

关键点

数据模型

数据模型定义了数据库中数据的结构、关系、约束以及操作方式。数据模型的选择直接影响数据库的设计、性能、可维护性和扩展性。

数据模型的三要素

任何类型的数据模型都包含以下三要素：

  1. 数据结构（Data Structure）：定义数据如何组织和存储。关系模型中的数据结构是表，层次模型中的数据结构是树，而面向对象模型中的数据结构是对象。

  2. 数据操作（Data Operations）：定义对数据的操作方式，包括查询、插入、删除、更新等操作。关系模型中通过SQL语言进行操作，文档模型和键值模型通常使用API进行操作。

  3. 数据约束（Data Constraints）：定义数据的合法性和完整性规则，确保数据在存储和操作时满足一定的规范。例如，关系模型中有主键约束、外键约束和非空约束等。

数据模型的主要类型

数据模型类型 描述 特点 应用
关系模型 关系模型通过表（关系）来组织数据，数据之间通过主键和外键的关系来实现关联。每个表由行（元组）和列（属性）组成。关系模型是目前最常用的数据模型，广泛应用于关系型数据库管理系统（RDBMS）中。 - 数据存储在表中，行表示记录，列表示属性。
- 使用关系操作（如选择、投影、连接等）来查询和操作数据
- 强调数据的结构化和规范化，以减少冗余数据，确保数据一致性。		 SQL（Structured Query Language）是关系模型的查询语言，广泛应用于MySQL、Oracle、PostgreSQL等数据库系统。
层次模型（Hierarchical Model） 层次模型采用树状结构来表示数据，数据以层次化的方式组织成父子关系。每个父节点可以有多个子节点，但每个子节点只能有一个父节点。它适用于表示具有自然层次结构的数据，如组织结构图、文件系统等。 - 数据呈现为父子节点的结构，类似于树形图。
- 支持快速的导航和查询，尤其在读取操作上效率较高。
- 在层次模型中，父节点和子节点之间的关系是固定的，不能灵活处理多对多关系。		 层次模型主要用于早期的数据库管理系统，如IBM的IMS。
网状模型（Network Model） 网状模型是层次模型的扩展，允许数据元素之间存在多对多的关系。数据元素通过指针（或链接）互相连接，形成一个复杂的网状结构。 - 支持多对多的关系，通过指针连接不同的记录。
- 灵活性较高，但比层次模型复杂，查询的复杂度较高。
- 数据的插入和删除操作较为复杂。		 网状模型的代表是CODASYL DBMS，如早期的IDMS（Integrated Database Management System）。
面向对象模型（Object-Oriented Model） 面向对象模型采用面向对象的思想来组织数据，将数据表示为对象（Object），对象由属性和方法组成。对象之间可以通过继承、封装和多态等面向对象的概念来建立关系。 - 数据和操作（方法）被封装在一起，支持更复杂的数据类型，如图像、音频等。
- 支持继承、多态、封装等面向对象的特性，可以更好地模拟现实世界的复杂关系。
- 适合处理复杂的数据和应用场景，但对于传统的关系数据处理支持较弱。		 面向对象数据库（如ObjectDB、db4o）和一些面向对象的关系数据库（如PostgreSQL的对象关系扩展）。

关系模型（Relational Model）

基本概念

1. 关系（Relation）

关系是数据库中用于表示数据的一种结构，它由一组行和列组成。每个关系可以看作是一张表，表中的每一行表示一个实体或记录，而每一列表示该实体的一个属性。

2. 元组（Tuple）

元组是关系中的一行，也就是表中的一条记录。每个元组包含一组属性值，这些属性值对应于关系的不同列。

3. 属性（Attribute）

属性是关系中的列，表示某一类信息的特征或属性。每个属性都有一个名称和一个数据类型，定义了该列存储的数据的格式。

4. 域（Domain）

域是属性可能取的所有值的集合。每个属性都有一个对应的域，它定义了该属性值的取值范围、数据类型及可能的约束。

5. 候选键（Candidate Key，候选码）

候选键是关系中能够唯一标识每一行的属性或属性组合。每个关系可以有多个候选键，但必须选择一个作为主键。

6. 主键（Primary Key）

主键是一个或多个属性的组合，用于唯一标识关系中的每一行（元组）。主键的值必须唯一且不能为NULL。

7. 外键（Foreign Key）

外键是一个或多个属性，用于在一个关系中引用另一个关系的主键。外键用于建立表之间的关联，保证数据的参照完整性。

8. 度（Degree）

关系的度是关系中属性的数量，即表中的列数。

9. 目（Cardinality）

关系的目是关系中元组的数量，即表中的行数。

10. 关系的基数（Cardinality）

基数表示一个关系中某一属性可能的取值个数。它通常用来描述关系中的元组数目。

关系操作（Relational Operations）

关系模型通过一系列的操作来对数据进行查询和更新，这些操作通常基于集合理论，主要包括以下几种：

完整性约束（Integrity Constraints）

完整性约束确保数据的正确性和一致性。主要包括以下几类：

关系代数（Relational Algebra）

关系数据库理论中用于操作关系（即表）的理论基础，它提供了一组数学运算符，用于在数据库中查询和操作数据。关系代数的主要作用是定义数据库查询的操作模型，它是关系数据库管理系统（RDBMS）执行查询和优化的基础。关系代数的主要操作是基于
集合论的操作，如选择、投影等。所有的操作结果都会返回一个新的关系（表），关系代数的操作具有封闭性
。它的主要优点是能够以一种清晰、形式化的方式定义查询和更新数据的方式。

基本操作

关系代数包括一些常见的基本操作符，每个操作符都可以应用于一个或多个关系，生成新的关系。下面是主要的关系代数操作：

1. 选择（Selection, σ）

选择操作从关系中选出满足特定条件的元组（行）。它相当于 SQL 中的 WHERE 子句。

2. 投影（Projection, π）

投影操作从关系中选出特定的列（属性），去除其他不需要的列，相当于 SQL 中的 SELECT 子句。

3. 并（Union, ∪）

并操作将两个关系中的元组合并，去除重复项，要求两个关系具有相同的属性（同名且类型相同）。

4. 差（Difference, -）

差操作返回在第一个关系中但不在第二个关系中的元组，相当于 SQL 中的 EXCEPT 子句。

5. 笛卡尔积（Cartesian Product, ×）

笛卡尔积操作返回两个关系的所有元组的组合，生成一个包含所有属性的关系。结果是两个关系的所有元组的组合。

复合操作

1. 交（Intersection, ∩）

交操作用于返回两个关系中共同存在的元组，类似于集合论中的交集操作。即，交操作返回的是同时出现在两个关系中的元组。要求两个关系有相同的属性（列）。

2. 连接（Join, ⨝）

连接操作将两个关系根据某些条件连接起来，常用于关联查询。最常见的连接是等值连接（Equi Join）和自然连接（Natural Join）。

3. 除法（Division, ÷）

除法操作用于查询那些与另一个关系的所有元组都相关联的元组。它常常用于“满足所有条件”的查询。

规范化理论（Normalization Theory）

一个用于设计关系型数据库结构的理论，它通过一系列的规则和步骤将数据从冗余、不一致、难以维护的设计转化为简洁、高效且一致的数据结构。规范化的核心目标是消除数据冗余、避免更新异常和插入异常，并确保数据的完整性。

规范化的目的

规范化的主要目的是通过将数据表的结构优化，达到以下目标：

函数依赖（Functional Dependency, FD）

描述一个数据表中某些属性如何依赖于其他属性的规则。具体来说，在一个关系（即数据表）中，如果某个属性集（或属性组合）决定了另一个属性的值，那么我们称这个关系存在
函数依赖。如果在一个关系中，属性集X 决定了属性 Y 的值，记作：

X → Y

函数依赖的类型：

  1. 完全函数依赖（Full Functional Dependency）：如果属性 Y 完全依赖于属性集 X，即没有任何冗余属性集能决定 Y，则称 Y 完全依赖于 X。
  2. 部分函数依赖（Partial Functional Dependency）：如果属性 Y 依赖于属性集 X 的某一部分，而不是整个 X，则称 Y 部分依赖于 X。
  3. 传递函数依赖（Transitive Dependency）：如果属性 X 决定了属性 Y，而属性 Y 又决定了属性 Z，则称 Z 通过 Y 间接依赖于 X，这是传递依赖。
  4. 自反函数依赖（Trivial Functional Dependency）：对于任何属性集 X，都有 X → X，即任何属性集总是自我决定的，这被称为自反依赖。
  5. 多值依赖（Multivalued Dependency）：这是一个更复杂的依赖类型，表示一个属性集决定了多个属性集的值。

图示法求取候选键

  1. 将关系模式的函数依赖关系用有向图的方式表示
  2. 找入度为0的属性，并以该属性集合为起点，尝试遍历有向图，若能正常遍历图中所有节点，则该属性集记为关系模式的候选键
  3. 若入度为0的属性集不能遍历图中所有节点，则需要尝试性的将一些中间节点（既有入度，也有出度的节点）并入入度为0的属性集中，直至该集合能遍历所有节点，集合为候选键

公式法

Armstrong 公理（Armstrong's Axioms）

一组用于推导函数依赖（Functional Dependency, FD）关系的基本规则。在数据库设计中，函数依赖是描述一个属性集如何决定其他属性集的关系，而 Armstrong 公理为推导和验证这些函数依赖提供了一组完备的推导规则。

Armstrong 公理的三条基本公理

  1. 自反性（Reflexivity）：大决定小
    • 如果 Y 是 X 的子集，那么 X → Y 是一个有效的函数依赖。
    • 形式化：如果 Y ⊆ X，则 X → Y。
    • 例子：如果 A, B → A，因为 A 是 A, B 的子集。
  2. 增广性（Augmentation）：
    • 如果 X → Y 是一个有效的函数依赖，并且 Z 是任意的属性集，那么 X, Z → Y, Z 也是一个有效的函数依赖。
    • 形式化：如果 X → Y，那么 X, Z → Y, Z。
    • 例子：如果 A → B，那么 A, C → B, C 也是有效的函数依赖。
  3. 传递性（Transitivity）：
    • 如果 X → Y 和 Y → Z 是有效的函数依赖，那么 X → Z 也是有效的。
    • 形式化：如果 X → Y 和 Y → Z，则 X → Z。
    • 例子：如果 A → B 和 B → C，那么 A → C。

根据 Armstrong 公理推导其他规则

除了上述三条基本公理外，Armstrong 公理还可以用来推导其他有用的规则，这些规则可以帮助我们推导出更多的函数依赖关系。常见的推导规则包括

  1. 合并性（Union）：
    • 如果 X → Y 和 X → Z 都是有效的函数依赖，那么 X → Y, Z 也是有效的。
    • 形式化：如果 X → Y 和 X → Z，则 X → Y, Z。
    • 例子：如果 A → B 和 A → C，那么 A → B, C。
  2. 分解性（Decomposition）：
    • 若 X \rightarrow Y 成立，且 Z \subseteq Y，则 X \rightarrow Z也成立
    • 如果 X → Y, Z 是有效的函数依赖，那么 X → Y 和 X → Z 也都是有效的。X \rightarrow YZ & Z \subseteq YZ => X \rightarrow Z
    • 形式化：如果 X → Y, Z，则 X → Y 和 X → Z。
    • 例子：如果 A → B, C，那么 A → B 和 A → C。
  3. 合成性（Pseudotransitivity）：
    • 如果 X → Y 和 Y, Z → W 都是有效的函数依赖，那么 X, Z → W 也是有效的。
    • 形式化：如果 X → Y 和 Y, Z → W，则 X, Z → W。
    • 例子：如果 A → B 和 B, C → D，那么 A, C → D。

范式（Normal Forms, NFs）

在数据库设计中，规范化理论用于减少数据冗余和避免插入、更新和删除异常。规范化的过程是将数据库分解成多个表，并通过范式来衡量数据库设计的质量。范式判断是评估数据库设计是否符合一定规范的过程，主要通过函数依赖来判断一个表是否满足特定的范式。

常见范式和范式判断的标准

  1. 第一范式（1NF）
    • 要求：每个字段（列）都应该是不可再分的原子值（即单一值），不能有重复的列或表。
    • 判断标准：如果表中的每一列都是原子值，没有重复组或数组类型的数据，就满足 1NF。
  2. 第二范式（2NF）
    • 要求：表必须满足 1NF，并且所有非主属性完全依赖于主键（即不存在部分依赖）。只有主键是集合属性是才有可能违反第二范式
    • 判断标准：首先确保表满足 1NF，然后检查是否存在非主属性依赖于主键的部分属性（即主键的一部分），如果存在，则需要进一步分解表格。
  3. 第三范式（3NF）
    • 要求：表必须满足 2NF，并且所有非主属性直接依赖于主键，不能通过其他非主属性间接依赖主键（即不存在传递依赖）。
    • 判断标准：首先检查表是否满足 2NF，然后检查是否有非主属性依赖于其他非主属性，如果存在，表不满足 3NF。
  4. 博茨-科得范式（BCNF）：BCNF是3NF的一个特殊形式。BCNF要求数据库表中的每个决定因素都必须是候选键。换句话说，如果某个非主键字段决定了其他字段的值，那么该字段必须是候选键。
    • 要求：表必须满足 3NF，并且每一个非平凡的函数依赖 X → Y 中，X 必须是主键（即左侧属性集必须是主键）。
    • 判断标准：检查所有的函数依赖，确保每个决定属性集的左侧属性集是主键。
  5. 第四范式（4NF）：消除多值依赖（MVD, Multivalued Dependency）。如果一个关系模式 ( R(A, B, C) ) 中的某个属性集 ( A ) 能够决定多个 ( B ) 值，同时也能决定多个 ( C ) 值，而 ( B ) 和 ( C ) 之间相互独立（彼此无关），那么就存在 多值依赖（MVD）。
    • 关系模式要满足 4NF，必须先满足 BCNF，并且不能存在非平凡的多值依赖。

第四范式

示例（未满足 4NF，存在多值依赖）

学号 证书 课程
1001 英语四级 数据库
1001 英语四级 计算机网络
1001 计算机二级 数据库
1001 计算机二级 计算机网络

分析：

解决方案（拆分表）

将表拆分为两个独立的表：

拆分后，数据冗余被消除，满足 4NF。

规范化的过程

  1. 从1NF开始：确保每个字段只有单一的值（没有重复的列和多值属性）。
  2. 应用2NF：消除部分依赖，确保非主键字段完全依赖于主键。
  3. 应用3NF：消除传递依赖，确保非主键字段不依赖于其他非主键字段。
  4. 进一步优化：根据需要应用BCNF、4NF和5NF，消除多值依赖和连接依赖。

模式分解

  1. 是否保持函数依赖
  2. 是否无损：可以还原
  3. 无损连接分解：指将一个关系模式分解成若干个关系模式后，通过自然连接和投影等运算仍能还原到原来的关系模式

是否保持函数依赖

无损分解

给定关系模式 ( R ) 和它的子关系模式 ( R_1, R_2, \dots, R_n )，如果通过自然连接操作可以恢复到原始关系 ( R )，并且没有丢失任何信息，那么这个分解是无损的。

无损分解表法（分解矩阵法）

如果关系 R 被分解成子关系 R1, R2, ..., Rn，可以构造一个分解矩阵来检查是否无损。

步骤
  1. 创建矩阵，每一列代表一个属性，每一行代表一个子关系：
    • 初始状态：如果属性属于某个子关系 Ri，标记为 Ri，否则标记为 NULL。
  2. 根据函数依赖更新矩阵：
    • 若某一行的某些属性可以通过函数依赖推导出某个属性 X，则用同一行的标记替换 X 的值。
  3. 检查是否存在一行所有元素仍然唯一：
    • 如果某一行的所有列的值都相同（即全为 R1、R2 之一），则无损。
    • 否则，有损。
示例

给定关系 R(A, B, C)，函数依赖：
F = \{ A \rightarrow B, B \rightarrow C \}

分解：
R1(A, B), R2(B, C)

属性 A B C
R1 R1 R1 NULL
R2 NULL R2 R2
属性 A B C
R1 R1 R1 R1
R2 NULL R2 R2
基于函数依赖的无损判定（属性闭包法）

定理： 关系模式 R 在 R1(A1, A2, ...), R2(B1, B2, ...) 上的分解是无损的，当且仅当：
(R_1 \cap R_2) \rightarrow R_1 \quad 或者 \quad (R_1 \cap R_2) \rightarrow R_2

即：

示例

给定关系 R(A, B, C)，函数依赖集：
F = \{ A \rightarrow B, B \rightarrow C \}

分解：
R1(A, B), R2(B, C)

验证无损：

总结
方法 步骤 适用场景
属性闭包法 计算 ( (R_1 \cap R_2) \rightarrow R_1 ) 或 ( (R_1 \cap R_2) \rightarrow R_2 ) 是否成立 适用于 两个子关系的无损判定
无损分解表法 构造矩阵，利用函数依赖推导，检查是否能合并行 适用于多个子关系的无损判定

事务（Transaction）

由一组数据库操作组成的逻辑单位，这些操作要么全部执行成功，要么全部撤销（即回滚）。事务的主要目的是为了保证数据库的一致性、完整性以及隔离性。事务处理使得数据库能够在多用户并发访问和系统故障时保持正确的状态。

特性（ACID）

生命周期

事务的生命周期可以分为几个阶段，通常如下所示：

  1. 开始（Start）：事务开始时，数据库管理系统为该事务分配资源，标记事务的开始。
  2. 执行（Execute）：事务中包含的数据库操作（如插入、删除、更新）被执行。如果在执行过程中没有错误，事务继续。
  3. 提交（Commit）：当所有操作都成功执行时，事务会通过提交（COMMIT）命令使得对数据库的修改永久生效。
  4. 回滚（Rollback）：如果事务中的某个操作失败，或者在执行过程中发生了错误，事务会通过回滚（ROLLBACK）命令撤销所有已执行的操作，恢复到事务开始之前的状态。

并发控制

确保在多个事务并发执行时，数据库的正确性、完整性和一致性得以维持的技术手段。在数据库中，多个事务可能会同时操作相同的数据，这就可能导致数据冲突或不一致的情况，因此需要采用并发控制技术来协调这些事务的执行顺序。

并发控制的基本问题

并发执行的事务可能会导致以下几种问题：

并发控制方法

并发控制方法 核心思想 优点 缺点
封锁协议 通过加锁控制事务访问数据 实现简单，隔离性强 可能导致死锁，锁开销大
时间戳排序 根据时间戳决定事务执行顺序 避免死锁，适合高并发 事务可能频繁重启
多版本并发控制（MVCC） 维护数据多个版本，事务读取旧版本数据 读写不冲突，适合读多写少 需要额外存储空间，版本链可能过长
乐观并发控制 假设冲突少，提交时检查冲突 避免锁开销，适合低冲突场景 高冲突场景下性能差
基于有效性检查 提交时检查事务读写集是否冲突 实现简单，适合低冲突场景 高冲突场景下性能差

封锁协议

通过对数据加锁，限制其他事务对同一数据的访问，确保事务隔离性。

1. 锁的种类
2. 常见的封锁协议

在数据库并发控制中，封锁协议（Locking Protocol）用于确保事务的隔离性和一致性。常见的封锁协议包括一级封锁协议、二级封锁协议和三级封锁协议

封锁协议 修改数据加锁 读取数据加锁 解决的问题 未解决的问题
一级封锁协议 排他锁（X锁） 不加锁 脏写 脏读、不可重复读、幻读
二级封锁协议 排他锁（X锁） 共享锁（S锁） 脏写、脏读 不可重复读、幻读
三级封锁协议 排他锁（X锁） 共享锁（S锁） 脏写、脏读、不可重复读 幻读
1. 一级封锁协议（First Locking Protocol）
2. 二级封锁协议（Second Locking Protocol）
3. 三级封锁协议（Third Locking Protocol）
4. 与两阶段加锁（2PL）的关系

时间戳排序（Timestamp Ordering）

时间戳排序通过为每个事务分配唯一的时间戳，并根据时间戳决定事务的执行顺序。

核心规则
优点
缺点

3. 多版本并发控制（MVCC, Multi-Version Concurrency Control）

MVCC通过维护数据的多个版本来实现并发控制，允许多个事务同时读取和修改数据。

核心思想
优点
缺点
实现

死锁处理（Deadlock Handling）

死锁是指多个事务相互等待对方释放锁，导致所有事务无法继续执行。

死锁预防
死锁检测与恢复

数据库设计过程

数据库设计过程

1. 需求分析阶段

目标

任务

输出

2. 概念结构设计阶段

概念结构设计

目标

任务

输出

ER图（实体-关系图，Entity-Relationship Diagram）

ER图是一种用于表示实体及其之间关系的图形化工具，广泛应用于数据库的概念设计阶段。

ER图的基本构成要素：

  1. 实体（Entity）

    • 实体通常表示一个对象或事物，可以是物理的或抽象的。例如，"学生"、"课程"、"订单"等都是实体。
    • 实体在ER图中通常用矩形表示。

  2. 属性（Attribute）

    • 属性是描述实体特征的细节，例如，学生实体可能有属性 "学号"、"姓名"、"年龄"等。
    • 属性用椭圆形表示，并通过线条与相应的实体连接。

  3. 关系（Relationship）

    • 关系描述不同实体之间的相互联系。例如，“学生选课”表示学生和课程之间的关系。
    • 关系用菱形表示，并通过线条连接相关的实体。

  4. 主键（Primary Key）

    • 主键是唯一标识实体的属性。它用来确保每个实体在表中的唯一性。通常在ER图中，用下划线表示主键。

  5. 联系的基数（Cardinality）

    • 基数描述了两个实体之间关系的数量限制，通常有：
      • 1对1：一个实体实例只能与另一个实体实例相关。
      • 1对多：一个实体实例可以与多个实体实例相关，但每个多方实例只能与一个实体实例相关。
      • 多对多：多个实体实例之间可以有多重关系。

  6. 弱实体（Weak Entity）

    • 弱实体是依赖于另一个实体（通常是强实体）存在的实体。例如，"订单项"可能是一个弱实体，它依赖于"订单"实体来唯一标识。
    • 弱实体用双矩形表示，并与强实体通过双线连接。

  7. 多值属性（Multivalued Attribute）

    • 多值属性是指一个实体可以具有多个值
联系类型（Cardinality）

在ER图中，联系类型（Cardinality）描述了两个实体之间的关系数量，即它们如何互相关联。判断联系类型通常依赖于实体间关系的基数，即每个实体实例如何与另一个实体实例关联。

1. 一对一（1:1）关系

在一对一关系中，一个实体实例只与另一个实体实例相关联。

2. 一对多（1:N）关系

在一对多关系中，一个实体实例可以与多个另一个实体实例相关联，但另一个实体实例只能与一个实体实例相关联。

3. 多对多（M:N）关系

在多对多关系中，多个实体实例可以与多个另一个实体实例相关联。

集成

方法
  1. 多个局部ER图一次集成
  2. 逐步集成，用累加的方式一次集成两个局部ER图
集成冲突
  1. 属性冲突：包括属性域冲突和属性取值冲突
  2. 命名冲突：包括同名异义和异名同义（同一实体）
  3. 结构冲突：包括同一对象在不同应用中具有不同地抽象，以及同一实体在不同局部ER图中所包含的属性个数和属性排列次序不完全相同

3. 逻辑结构设计阶段

逻辑结构设计

目标

任务

  1. 选择数据模型

    • 根据业务需求选择合适的数据模型（如关系模型、文档模型、键值模型等）。在关系型数据库中，选择的是关系模型，在非关系型数据库中，可能选择文档模型、图数据库模型等。

  2. 定义关系（表）和属性（列）

    • 通过ER图（实体-关系图）等工具，明确实体（表）、属性（列）及其之间的关系。
    • 确定每个表中所包含的字段，确定每个字段的数据类型（如整数、字符串、日期等）。

  3. 确定主键与外键

    • 为每个表选择主键（Primary Key），以确保记录的唯一性。
    • 确定外键（Foreign Key）以建立表与表之间的联系，确保数据的参照完整性。

  4. 定义完整性约束

    • 定义实体完整性、参照完整性、域完整性等约束，以确保数据的一致性和完整性。
    • 可以包括主键约束、外键约束、唯一约束、检查约束等。

  5. 规范化

    • 对数据模型进行规范化（Normalization），通过分解关系（表）来消除冗余数据，减少数据异常，确保数据的存储效率和一致性。
    • 规范化的过程一般包括从第一范式（1NF）到第三范式（3NF）的规范化步骤，也可能包括更高的范式。

  6. 确定数据表的关系

    • 确定不同数据表之间的关系，如一对多关系、多对多关系等。

输出

ER图转换关系模式

1. 将每个实体转换为关系

每个实体集（Entity Set）对应于一个关系模式（即数据库中的表）。实体集中的每个属性将转化为关系中的列。

2. 将每个关系转换为关系模式

每个关系（Relationship）对应于关系模型中的表。关系集转换为关系模式时，需要根据关系的基数（Cardinality）选择合适的方式来表示。

3. 处理属性
4. 处理弱实体

弱实体（Weak Entity）依赖于强实体（Strong Entity）的主键，并且通常没有自己的主键。在转换为关系模式时，弱实体表会包含其自身的属性和强实体的主键作为外键。

4. 物理设计阶段

目标

任务

输出

5. 数据库实施阶段

根据逻辑设计和物理设计阶段的结果建立数据库，编制与调试应用程序，组织数据入库，并进行试运行

6. 数据库运行和维护阶段

数据库应用系统经过试运行即可投入运行，但该阶段需要不断地对系统进行评价、调整与修改

数据库安全

数据库安全

备份与恢复技术

数据库备份的重要性

物理备份类型

特性 冷备份（Cold Backup） 热备份（Hot Backup）
数据库状态 关闭 运行
数据一致性 高 需要额外机制（如日志）保证一致性
业务影响 数据库不可用 数据库可用
复杂性 简单 复杂
适用场景 小型数据库、允许停机的系统 大型数据库、高可用性系统

冷备份（Cold Backup）

冷备份是在数据库关闭或停止运行的状态下进行的备份。备份内容包括数据库的数据文件、日志文件、控制文件等。

热备份（Hot Backup）

热备份是在数据库运行状态下进行的备份。备份过程中数据库可以继续提供服务。

数据备份类型

备份类型 特点 优点 缺点 适用场景
完全备份（Full Backup） 备份整个数据库，包括所有数据和对象。 - 恢复简单，只需一个备份文件。
- 适合首次备份和灾难恢复。		 - 备份时间长。
- 占用存储空间大。		 首次备份、定期全量备份（如每周一次）。
增量备份（Incremental Backup） 仅备份自上次备份以来发生变化的数据。 - 备份速度快。
- 占用存储空间小。		 - 恢复时需要依次应用完全备份和所有增量备份。
- 恢复时间较长。		 频繁备份（如每天一次）。
差异备份（Differential Backup） 备份自上次完全备份以来发生变化的数据。 - 恢复时只需应用完全备份和最新的差异备份。
- 恢复时间较短。		 - 备份文件比增量备份大。
- 占用存储空间较多。		 中等频率备份（如每两天一次）。
事务日志备份（Transaction Log Backup） 备份事务日志，记录所有数据库操作（如插入、更新、删除）。 - 支持点-in-time恢复（恢复到特定时间点）。
- 适合高可用性数据库。		 - 需要定期清理日志文件，否则可能占用大量空间。
- 管理复杂。		 高可用性数据库（如SQL Server、Oracle）。

备份策略

完全备份 + 增量备份

完全备份 + 差异备份

完全备份 + 事务日志备份

恢复方法

  1. 找最近的全部备份
  2. 找最近的差量备份
  3. 找差量备份后面的增量备份
  4. 全部备份 + 差量备份 + 增量备份

数据库故障

数据库故障是指由于硬件、软件、网络或人为原因导致数据库无法正常运行或数据丢失的情况

数据库故障的类型

故障类型 恢复方法 关键工具或技术
事务故障 回滚未完成的事务 事务日志
系统故障 重做已提交的事务，回滚未完成的事务 检查点、事务日志
介质故障 从备份恢复数据，应用日志 完全备份、增量备份、事务日志
灾难性故障 从异地备份恢复数据，启用备用数据中心 异地备份、灾难恢复计划（DRP）

事务故障

单个事务在执行过程中发生错误（如违反约束、死锁、用户中断）。

系统故障

由于硬件故障、操作系统崩溃或数据库软件错误导致数据库系统停止运行。

介质故障

磁盘损坏或数据文件丢失导致数据库无法访问。

灾难性故障

由于火灾、洪水、地震等自然灾害导致数据库系统完全损坏。

性能优化

性能优化

数据仓库

特点

  1. 面向对象：数据按主题组织
  2. 集成的：消除了源数据中的不一致性，提供整个企业的一致性全局信息
  3. 相对稳定的（非易失的）：主要进行查询操作，只有少量的修改和删除操作（或是不删除）
  4. 反映历史变化（随着时间变化）：记录了企业从过去某一时刻到当前各个阶段的信息，可对发展历程和未来做定量分析和预测

嵌入式数据库管理系统

数据挖掘

步骤

  1. 数据准备：从相关的数据源中选取所需的数据并整合成用于数据挖掘的数据集
  2. 规律寻找：用某种方法将数据集所含的规律找出来
  3. 规律表示：尽可能以用户可理解的方式将找出的规律表示出来

任务

  1. 关联分析
  2. 聚类分析
  3. 分类分析
  4. 异常分析
  5. 特异群组分析
  6. 演变分析
  7. 关联规则挖掘

知识点

  1. 两阶段提交协议（保证分布式事务的原子性（Atomicity），确保所有节点要么全部提交，要么全部回滚）：表决阶段 & 执行阶段
  2. 两阶段加锁协议（保证事务的隔离性（Isolation），防止并发冲突）：扩展阶段 & 收缩阶段
上一篇 下一篇

猜你喜欢

热点阅读