数据库

欢迎来到我的 ChatGPT 中转站，极具性价比，为付费不方便的朋友提供便利，有需求的可以添加左侧 QQ 二维码，另外，邀请新用户能获取余额哦！最后说一句，那啥：请自觉遵守《生成式人工智能服务管理暂行办法》。

# 一、数据模型

数据模型是用于描述现实世界中的数据之间关系的一种概念模型。它定义了用于组织、存储和操作数据的结构、规则和约束。数据模型是数据库设计和开发的基础，它提供了一种抽象的视图，帮助我们理解和操纵数据。

数据模型可以分为以下几种常见类型：

层次模型（Hierarchical Model）：数据以树状结构组织，父节点与子节点之间存在一对多的关系。层次模型适合描述具有明确层次结构的数据，如组织结构、目录结构等。
网状模型（Network Model）：数据以网状结构组织，允许节点之间存在多对多的关系。网状模型适合描述复杂的数据关系，但较难理解和操作。
关系模型（Relational Model）：数据以表格形式组织，使用行和列来表示实体和属性，通过关系（键）将表格相互关联。关系模型是最常用的数据模型，广泛应用于现代数据库系统。
对象模型（Object Model）：数据以对象的形式进行描述，包括属性和方法。对象模型适合处理面向对象的复杂数据关系，如面向对象编程语言中的类和对象。
半结构化模型（Semi-structured Model）：数据可以组织成不同的结构，具有一定的灵活性。半结构化模型适合描述文档、XML、JSON 等非严格结构化的数据。

不同的数据模型适用于不同类型的数据和应用场景。在数据库设计过程中，需要根据实际需求选择合适的数据模型，并基于该模型创建实体、定义属性和建立关系，以满足数据存储和操作的要求。

# 二、三级模式结构

在数据库管理系统中，外模式、模式和内模式是用于描述和组织数据库结构的概念。

外模式（External Schema）：外模式指的是用户或应用程序能够直接访问的数据库的部分。它定义了用户所能看到的数据和访问方式，提供了一个用户与数据库交互的界面。外模式以用户的角度出发，根据用户的需求和特定的应用程序需求来定义不同的视图。一个数据库系统可以有多个外模式，每个用户或应用程序可以有自己的外模式，且可能只能看到数据库中的部分数据。
模式（Schema）：模式是数据库的全局逻辑结构的描述，定义了字段、表、关系以及数据的存储方式等。它包括了数据库中所有与结构相关的信息，如表、视图、索引等的定义。模式不依赖于特定的应用程序，而是为数据库中所有的用户提供一致的视图。一个数据库可以有一个或多个模式，每个模式定义了数据库的整体结构。
内模式（Internal Schema）：内模式是数据库的最低级别的物理表现，描述了数据在磁盘上的存储方式和访问方法。它定义了如何将数据存储成文件和记录的形式，并且提供了物理层面的操作和存储细节。内模式通常由数据库管理系统自动管理，用户无法直接访问。

总的来说，外模式关注的是用户和应用程序的需求，定义了他们能够直接访问和操作的数据库部分；模式定义了数据库的逻辑结构，为所有用户提供统一的视图；内模式描述了数据库在磁盘上的物理存储方式。这三个级别之间存在层次关系，数据库管理系统负责管理和实现它们之间的映射关系，使得用户能够方便地访问和操作数据库。

一个数据库可以有多个外模式，只能有一个内模式

视图对应外模式、基本表对应模式、存储文件对应内模式

# 三、两级映像

数据库系统在三级模式之间提供了两级映像：模式 / 内模式映像、外模式 / 模式映像。正因为这两级映像保证了数据库中的数据具有较高的逻辑独立性和物理独立性。

模式 / 内模式映像。存在于概念级和内部级之间，实现了概念模式和内模式之间的相互转换。
外模式 / 模式映像。存在于外部级和概念级之间，实现了外模式和概念模式之间的相互转换。

数据的物理独立性，需要修改概念模式和内模式之间的映像。

数据的逻辑独立性，需要修改外模式和概念模式之间的映像。

# 四、关系代数

运算符	含义	类别
×	笛卡尔积	集合运算符
σ	选择	专门的关系运算符
π	投影	专门的关系运算符
⨝	连接	专门的关系运算符
=	等于	比较运算符
>	大于	比较运算符
≥	大于等于	比较运算符
<	小于	比较运算符
≤	小于等于	比较运算符
≠	不等于	比较运算符
∧	与	逻辑运算符
∨	或	逻辑运算符
∪（不考）	并	集合运算符
-（不考）	差	集合运算符
∩（不考）	交	集合运算符
÷（不考）	除	专门的关系运算符
¬（不考）	非	逻辑运算符

例题

关系 R、S 如下图所示，关系代数表达式 π_{3,4,5}(σ_{1<6}(R × S)) = ，对关系 R、S 进行自然连接后的属性列数和元组个数分别为。

然后找出来第一列小于第六列的

考的多较多的是笛卡尔积和连接

当两个不含共同属性时，自然连接就退化为笛卡尔积

完全外连接的元组个数取决于左表和右表的记录数以及它们之间的匹配情况。如果左表有 m 条记录，右表有 n 条记录，并且有 k 条记录在连接条件下匹配，那么完全外连接的元组个数为 $m+n-k$ 。

# 五、关系代数转 SQL 语言

看第四即可

# 六、SQL 语言

就是一些 SQL 题

# 七、授权语句

SQL 授权语句是用来授予或撤销用户对数据库对象（如表、视图、存储过程等）的访问权限的。以下是 SQL 授权语句的格式，包括授权类型、关键字和语法：

GRANT 语句（授权权限给用户）的格式：
```
GRANT <权限列表> ON <对象类型> <对象名称> TO <用户或用户组> [WITH GRANT OPTION];
```
1
- <权限列表> : 指定用户被授予的权限，可以是一个或多个权限，用逗号分隔。例如：SELECT, INSERT, UPDATE, DELETE。
- <对象类型> : 指定被授予权限的对象类型，如 TABLE、VIEW、PROCEDURE 等。
- <对象名称> : 指定被授予权限的对象名称，如表名、视图名、存储过程名等。
- <用户或用户组> : 指定被授予权限的用户或用户组名称。
- [WITH GRANT OPTION] : 可选项，表示被授权用户可以将其拥有的权限授权给其他用户。
REVOKE 语句（撤销用户的权限）的格式：
```
REVOKE <权限列表> ON <对象类型> <对象名称> FROM <用户或用户组>;
```
1
- <权限列表> : 指定需要撤销的权限，可以是一个或多个权限，用逗号分隔。
- <对象类型> : 指定被撤销权限的对象类型，如 TABLE、VIEW、PROCEDURE 等。
- <对象名称> : 指定被撤销权限的对象名称，如表名、视图名、存储过程名等。
- <用户或用户组> : 指定被撤销权限的用户或用户组名称。

在 SQL 中，"PUBLIC" 和 "WITH GRANT OPTION" 都是用于授权语句的关键字，但它们的用途和含义有所不同。

"PUBLIC" 关键字：
- "GRANT <权限列表> ON < 对象类型 > < 对象名称 > TO PUBLIC"：将权限授予所有用户，包括匿名用户和已经存在的用户。
- "REVOKE <权限列表> ON < 对象类型 > < 对象名称 > FROM PUBLIC"：从所有用户中撤销权限。
"WITH GRANT OPTION" 关键字：
- "GRANT <权限列表> ON < 对象类型 > < 对象名称 > TO < 用户或用户组 > WITH GRANT OPTION"：授予用户权限，并允许该用户将权限授予其他用户。
- "REVOKE <权限列表> ON < 对象类型 > < 对象名称 > FROM < 用户或用户组 > WITH GRANT OPTION"：撤销用户的授权同时也会删除他们授予给其他用户的相应权限。

# 八、视图

在 SQL 中，视图（View）是虚拟的表，它是基于一个或多个表的查询结果集，可以像表一样进行查询操作。视图提供了一种从逻辑上组织数据的方式，并且可以隐藏底层表的细节，简化复杂的查询操作。

创建视图：
```
CREATE VIEW <视图名称> AS
SELECT <列1>, <列2>, ...
FROM <表1>
JOIN <表2> ON <条件>
WHERE <条件>;
```
1
2
3
4
5
- <视图名称> ：指定要创建的视图名称。
- <列1>, <列2>, ... ：选择要包含在视图中的列。
- <表1> ， <表2> ：指定需要在查询中引用的表。
- <条件> ：设置连接和筛选条件。
删除视图：
```
DROP VIEW <视图名称>;
```
1
- <视图名称> ：要删除的视图名称。
修改视图：
一般来说，SQL 不直接提供修改视图定义的功能。如果要修改视图的查询逻辑，你需要执行以下操作：
- 删除现有的视图： DROP VIEW <视图名称>;
- 重新创建视图：使用新的查询逻辑使用 CREATE VIEW 语句创建视图。
WITH CHECK OPTION：
WITH CHECK OPTION 是用于创建或修改视图时的一个可选子句，它可以约束视图上的数据更新。当视图的 WITH CHECK OPTION 被指定时，插入或修改数据行的过程中，必须满足视图定义中的条件，否则会被拒绝。
```
CREATE VIEW <视图名称> AS
SELECT <列1>, <列2>, ...
FROM <表1>
WHERE <条件>
WITH CHECK OPTION;
```
1
2
3
4
5

注意事项：

视图只存储查询逻辑，不存储实际的数据。每次查询视图时，都会根据定义的查询逻辑重新计算结果。
视图可以被用于查询和更新操作，但具体支持的操作会依赖于基础表的约束和引用规则。
在创建视图时，可以指定列名，也可以使用别名来自定义视图中的列名。这样可以提供更清晰的数据接口。
删除视图不会影响实际的数据表。

# 九、索引

索引存在于数据库的底层例如 B + 树（面试问的较多），也就是内模式。

# 十、函数依赖和属性闭包

候选码（或候选键）：属性或属性组合，其值能够唯一地标识一个元组
主码（或主键）：在一个关系中可能有多个候选码，从中选择一个作为主码
主属性：包含在任何候选码中诸属性称为主属性，不包含在任何候选码中诸属性称为非码属性
外码（或外键）：如果一个关系中的属性或属性组并非该关系的码，但它们是另外一个关系的码，则称其为该关系的外码。
全码：关系模式的所有属性组是这个关系模式的候选码，称为全码
超码：一个包含码的属性集称为超码，例如学号是码，则（学号，姓名）就是一个超码

# 十一、范式

定义：

第一范式（1NF）
- 第一范式要求数据库中的每个列都是原子的，即每个列不能包含多个值或重复的值。如果存在非原子的列，就需要将其拆分成多个原子列。
- 例如，考虑一个包含学生信息和课程信息的表格。如果我们有一个 "成绩" 列，其中包含多个学生的成绩（如 "90, 95, 80"），那么该列就不符合第一范式。为了满足第一范式，我们可以将成绩列拆分成多个原子列，如 "成绩 1"、"成绩 2"、"成绩 3"。
第二范式（2NF）
- 第二范式要求数据库中的每个非主键列完全依赖于主键。换句话说，每个非主键列必须直接依赖于整个主键，而不是主键的一部分。
- 例如，考虑一个包含订单信息的表格，其中包含订单号、产品名称和产品价格。这里订单号是主键，产品名称和产品价格是非主键列。如果一个产品名称对应多个产品价格，则产品价格不完全依赖于订单号，违反了第二范式。为了满足第二范式，我们可以创建另一个表格，将产品名称和产品价格分离出来，使每个产品名称只对应一个产品价格。
第三范式（3NF）
- 第三范式要求数据库中的每个非主键列不能传递依赖于主键。换句话说，非主键列之间不应该存在传递依赖关系。
- 例如，考虑一个包含雇员信息的表格，其中包含雇员 ID、雇员姓名和雇员部门。这里雇员 ID 是主键，雇员部门依赖于雇员 ID，而雇员姓名依赖于雇员部门。这种情况违反了第三范式，因为非主键列（雇员姓名）传递依赖于另一个非主键列（雇员部门）。为了符合第三范式，我们可以创建另一个表格，将雇员姓名和雇员部门分离开来。

BC 范式 (BCNF)
- 设 R 是一个关系模式，F 是它的依赖集，R 属于 BCNF，当且仅当其 F 中每个依赖的决定因素必定包含 R 的某个候选码。
- 一个满足 BCNF 的关系模式有
  - 所有非主属性对每一个码都是完全函数依赖
  - 所有的主属性对每一个不包含它的码，也是完全函数依赖
  - 没有任何属性完全函数依赖于非码的任何一组属性
- 一个满足 BCNF 的关系模式 R 已消除了插入和删除异常
- 例如，考虑一个关系模式 R（学生，课程，教师）和函数依赖集 F 如下：F = {学生→课程，学生→教师，学生，课程→教师}，这里学生可以作为关系模式 R 的候选码，因为它可以唯一地标识每个学生，并决定相关的课程和教师。现在，让我们检查每个函数依赖的决定因素，看是否每个函数依赖的决定因素都包含候选码。
  - 学生→课程：学生（候选码）包含了决定课程的属性。
  - 学生→教师：学生（候选码）包含了决定教师的属性。
  - 学生，课程→教师：学生和课程的组合并不能唯一地决定教师，因此这个函数依赖不满足 BCNF。
  根据 BCNF 的要求，每个函数依赖的决定因素必须包含候选码。在这个例子中，函数依赖 “学生，课程→教师” 违反了 BCNF，因为它的决定因素（学生和课程组合）不包含候选码。
  
  要将关系模式 R 调整为满足 BCNF，可以将非满足 BCNF 的依赖分解为单独的关系模式。在这种情况下，我们可以将 “学生，课程，教师” 作为一个新的关系模式，并通过外键引用学生和课程关系。这样就可以消除违反 BCNF 的依赖，同时避免插入和删除异常。
  
  注意
  
  BCNF 是一种高级的范式化标准，它可以帮助消除函数依赖和数据冗余。然而，满足 BCNF 并不一定意味着设计的关系模式是最优的。在实际数据库设计中，需要根据具体情况和需求做出权衡，并结合其他设计原则来确定最佳的范式化水平。

问题：

第一范式（1NF）对数据的要求是将数据原子化，确保每个属性都包含一个单一的值。但即使在满足 1NF 的情况下，仍然可能存在数据冗余和更新异常。这是因为可能存在部分函数依赖，即非主键属性依赖于主键的一部分而不是全部。部分函数依赖会导致更新数据时的重复工作或不一致性。

第二范式（2NF）要求满足 1NF 的基础上，非主键属性必须完全依赖于候选键。然而，即使在满足 2NF 的情况下，仍然可能存在数据冗余和更新异常。这是因为仍然可能存在传递函数依赖，即非主键属性依赖于非候选键的某些属性。传递函数依赖会导致在更新数据时的冗余和不一致性。

第三范式（3NF）要求满足 2NF 的基础上，消除非主键属性对主属性的传递依赖。但即使在满足 3NF 的情况下，仍然可能存在插入异常、删除异常和更新复杂的问题。这是因为仍然可能存在主属性对候选键的部分依赖和传递依赖。

# 十二、关系分解

看道题

第一题，主键为员工号和家庭成员，因为成员关系必须由员工号和家庭成员推出来。但是姓名、部门、部门电话都依赖于员工号，所以是部份依赖，未达到 2NF 要求，所以是 1NF。而 EMP1 中不能有部门电话，因为会存在传递依赖（员工号→部门→部门电话）。所以按照 B 选项拆分能达到所有的非主属性对主属性完全依赖，并不存在传递依赖。

# 十三、无损连接和保持函数依赖

正例

假设我们有一个关系模式 R（学生，课程，教师）和以下函数依赖集 F：

F = {学生→课程，学生→教师}

现在，我们将关系模式 R 进行分解为两个关系模式 R1（学生，课程）和 R2（学生，教师）。我们将使用学生作为共有属性（外键）进行连接操作，以验证是否存在无损连接和保持函数依赖。

无损连接：
我们通过使用学生作为连接属性来连接 R1 和 R2，来验证是否能够恢复原始关系模式 R。

R1（学生，课程）JOIN R2（学生，教师）

通过连接操作，我们可以获得以下结果：

R（学生，课程，教师）

可以看到，通过连接操作，我们能够恢复原始关系模式 R，没有丢失任何数据记录。因此，这个分解是无损连接的。

保持函数依赖：
我们需要验证分解后的关系模式 R1 和 R2 是否仍然保持原始关系模式中的函数依赖关系。在这个例子中，我们需要验证学生→课程和学生→教师这两个函数依赖是否在分解后的模式中保持。

在关系模式 R1（学生，课程）中，我们可以看到学生→课程的函数依赖仍然存在。

在关系模式 R2（学生，教师）中，我们可以看到学生→教师的函数依赖也仍然存在。

因此，在这个分解中，函数依赖关系得到了保持。

反例

当与无损连接和保持函数依赖的概念相冲突时，以下是几个反例的示例：

无损连接的反例：
考虑一个初始的关系模式 R（学生，课程，教师）和函数依赖集 F 如下：

F = {学生→课程，学生→教师，课程→教师}

现在，我们将关系模式 R 分解为两个关系模式 R1（学生，课程）和 R2（课程，教师）。如果我们使用课程作为连接属性进行连接操作，我们无法恢复原始关系模式 R，因为学生和教师之间的关系被分解为不同的关系模式中。在这种情况下，这个分解不满足无损连接的要求。

保持函数依赖的反例：
考虑一个初始的关系模式 R（学生，课程，教师）和函数依赖集 F 如下：

F = {学生→课程，学生→教师}

现在，我们将关系模式 R 分解为两个关系模式 R1（学生，课程）和 R2（学生，教师）。如果我们以学生作为连接属性进行连接操作，虽然我们能恢复原始关系模式 R，但是我们发现学生→课程的函数依赖在分解后的模式中丢失了。在这种情况下，这个分解不满足保持函数依赖的要求。

# 十四、属性

在关系数据库设计中，有几个常见的属性类型，包括简单属性、复合属性、单值属性、多值属性、NULL 属性和派生属性。下面对每个属性类型进行详细说明：

简单属性（Simple Attribute）：
简单属性是一个单独的、不可再分的属性，它代表关系模式中的一个字段。简单属性存储的是一个单一的值。例如，在一个学生关系模式中，"姓名" 和 "年龄" 可以是简单属性，因为它们是单个值。
复合属性（Composite Attribute）：
复合属性是由多个简单属性组合而成的属性，它表示关系模式中的一个组合字段。复合属性可以被分解为更小的简单属性。例如，在一个地址关系模式中，"街道"、"城市" 和 "邮编" 可以组合成一个复合属性 "地址"。
单值属性（Single-Valued Attribute）：
单值属性是指一个属性只能有一个值。每个实例或记录在该属性上只能具有一个值。例如，在一个员工关系模式中，"工号" 可以是一个单值属性，因为每个员工只有一个工号。
多值属性（Multi-Valued Attribute）：
多值属性是指一个属性可以有多个值，每个实例或记录在该属性上可以具有多个值。例如，在一个学生关系模式中，"兴趣爱好" 可以是一个多值属性，因为每个学生可能有多个兴趣爱好，例如篮球、音乐等。
NULL 属性：
NULL 属性表示一个属性没有被赋予任何值，即它是空的或缺失的。NULL 在关系数据库中用于表示缺失数据或未知值。一个属性可以被赋予 NULL 值，表示该属性的值是未知的或不适用的。
派生属性（Derived Attribute）：
派生属性是通过对一个或多个已有属性进行计算或推导得出的属性。它的值不是直接存储在关系模式中，而是通过其他属性的计算或逻辑关系得到。例如，在一个学生关系模式中，"年级" 可以是一个派生属性，它通过计算学生的入学年份和当前年份得到。

# 十五、E-R 合并冲突

属性冲突
- 属性冲突指的是在不同的 E-R 图中，相同的属性存在不一致的定义。例如，在一个 E-R 图中，属性 "年龄" 可能被定义为整数类型，而在另一个 E-R 图中，"年龄" 可能被定义为字符串类型。这样的冲突需要解决，以确保在系统中对属性的使用是统一的。
- 解决方法：解决属性冲突的方法是在合并 E-R 图时，对相同的属性进行统一的定义。在上述示例中，可以通过确定一个通用的数据类型（例如整数）来统一 "年龄" 属性的定义。
命名冲突
- 命名冲突发生在不同的 E-R 图中，相同的属性被赋予了不同的名称，或是在不同的 E-R 图中使用相同的名称来表示不同的属性。这样的冲突会导致混淆和歧义。
- 解决方法：解决命名冲突的方法是为相同的属性选择一个统一的命名约定。在合并 E-R 图时，可以讨论和协商来确定一个一致的命名，以避免混淆。例如，可以选择一个描述性的属性名称，如 "学生姓名" 和 "课程学生姓名"，以区分不同的属性。
结构冲突
- 结构冲突发生在不同的 E-R 图中，对于相同的实体或属性，在其结构的定义上存在不一致。例如，一个 E-R 图中的实体 "学生" 可能有属性 "年龄" 和 "性别"，而另一个 E-R 图中的实体 "学生" 可能只有属性 "年龄"。
- 解决方法：解决结构冲突的方法是通过讨论和协商来统一实体的属性结构。在合并 E-R 图时，可以确定一致的属性定义，以确保在整个系统中对实体结构的使用一致。

# 十六、逻辑结构设计

# 十七、数据库设计

确定系统边界和关系规范化分别在数据库设计的需求分析和逻辑设计阶段进行。
在数据库逻辑结构设计阶段，需要需求分析阶段形成的需求说明文档、数据字典和数据流图作为设计依据。
关系规范化在数据库设计的逻辑设计阶段进行。

# 十八、事务管理

原子性（Atomicity）：
原子性要求一个事务中的所有操作要么全部执行成功，要么全部回滚，不允许部分执行成功而部分失败的情况发生。当事务执行失败或中断时，系统将撤销或回滚已经执行的操作，使数据库恢复到执行事务前的状态。
一致性（Consistency）：
一致性要求事务执行的结果必须使数据库从一个一致性状态转变到另一个一致性状态。这意味着事务的执行应符合数据库的完整性约束和业务规则，以确保数据的正确性和完整性。
隔离性（Isolation）：
隔离性确保并发执行的事务彼此相互隔离，互不干扰。并发执行的多个事务在执行过程中彼此不可见，即一个事务的中间结果对其他事务是不可知的，直到事务提交时才可见。这样可以防止并发事务之间的数据冲突、干扰和不一致。
持久性（Durability）：
持久性要求一旦事务被提交，它对数据库的更改应该是永久的，即使在系统故障（如崩溃）之后也不能丢失。数据库管理系统会将已提交的事务的更改记录到稳定的存储介质（如磁盘）中，以确保数据的持久性。

# 十九、数据库的备份与恢复

系统在进行事务处理时，对数据的插入、删除或修改的全部有关内容先写入日志文件；当系统正常运行时，按一定的时间间隔，把数据库缓冲区内容写入数据文件。

# 二十、锁

并发控制技术：并发控制的主要技术是封锁。基本封锁的类型有排它锁 (简称 X 锁或写锁) 和共享锁 (简称 S 锁或读锁)。

排它锁。若事务 T 对数据对象 A 加上 X 锁，则只允许 T 读取和修改 A，其他事务都不能再对 A 加任何类型的锁，直到工释放 A 上的锁。
共享锁。若事务 T 对数据对象 A 加上 S 锁，则只允许 T 读取 A，但不能修改 A，其他事务只能再对 A 加 S 锁，直到 T 释放 A 上的 S 锁。这就保证了其他事务可以读 A，但在 T 释放 A 上的 S 锁之前不能对 A 进行任何修改。

# 二十一、分布式数据库

分片透明：指用户或应用程序不需要知道逻辑上访问的表具体是怎么分块存储的
复制透明：指采用复制技术的分布方法，用户不需要知道数据是复制到哪些节点，如何复制的
位置透明：指用户无须知道数据存放的物理位置
逻辑透明：指用户或应用程序无需知道局部场地使用的是哪种数据模型

共享性：指数据存储在不同的结点数据共享
自治性：指每结点对本地数据都能独立管理
可用性：指当某一场地故障时，系统可以使用其他场地上的副本而不至于使整个系统瘫痪
分布性：指数据在不同场地上的存储

#软考

上次更新: 2025/04/12, 05:37:39

← 知识产权面向对象→