notes-dbms

chap1 绪论

SQL数据库与NoSQL数据库

其实就是NoSQL主要是面向单一的大量数据（比如一个人每天的定位数据这种，显然那比较适合NoSQL

但是那种需要经常读写的，就需要关系型数据库来维持ACID的性质

SQL 结构化查询语言

三级模式结构-例子

GPT:

让我们以一个简单的学生信息管理系统为例来说明外模式-模式-内模式的概念。

假设我们有一个学生信息管理系统，其中包含以下数据：

• **内模式（Internal Schema）：**在底层，数据库的内模式定义了数据在物理存储介质上的实际存储方式和结构。假设我们使用关系型数据库，并使用MySQL的InnoDB存储引擎，数据以表格的形式存储在磁盘上，包括学生表（Student table）、课程表（Course table）和成绩表（Grade table）等。内模式定义了表的存储方式、索引结构、数据分区等底层实现细节。
• **模式（Conceptual Schema）：**在中间层，数据库的模式定义了整个数据库的逻辑结构和关系。假设我们的模式包括学生表（Student table）、课程表（Course table）和成绩表（Grade table）之间的关系。它描述了表之间的主键-外键关系、表的属性和约束等信息。模式是对整个数据库的全局视图，独立于具体的应用程序。
• **外模式（External Schema）：**在最高层，数据库的外模式定义了特定用户或应用程序对数据库的部分可见视图。假设我们有两个外模式：
  1. 学生用户外模式（Student User External Schema）：学生用户只对学生表（Student table）感兴趣，他们可以访问学生的基本信息，如学号、姓名、年龄等。其他表（如课程表和成绩表）对他们不可见。
  2. 教师用户外模式（Teacher User External Schema）：教师用户对课程表（Course table）和成绩表（Grade table）感兴趣，他们可以访问课程的信息和学生的成绩。其他表（如学生表）对他们不可见。

通过这个案例，可以看到：

• 内模式定义了数据在底层存储介质上的物理结构和存储方式。
• 模式定义了整个数据库的逻辑结构和表之间的关系。
• 外模式定义了特定用户或应用程序对数据库的部分可见视图，根据用户的需求定义了他们可以访问的数据集合。

这种外模式-模式-内模式的层次结构帮助实现数据的抽象和分离，使得不同用户或应用程序可以根据自己的需求访问数据库中的数据，而不需要了解底层的物理存储细节或其他用户不可见的数据。

chap2 关系数据库

规范条件

最基本的一条，不允许“表中有表”

关系模式

D就是域的集合

DOM是指明属性的域是哪个

外码

参照关系和被参照关系不一定是不同的关系

主键和主属性

个人感觉任一候选码的属性都是主属性

主键就是人为选定的一个候选码，应该等同于主码的概念

五种基本关系代数运算

并 差 笛卡尔积 选 投

连接操作

分类众多

连接：

• 等值连接
  • 自然连接
    • 内连接
    • 外连接
      • 外连接
      • 左外连接
      • 右外连接
  • 普通等值连接
• 非等值连接

chap3 SQL

1	<center><embed src="https://box.nju.edu.cn/f/e58b4ec1bf54441eb433/" width="100%" height="700"></center>

MySQL中没有模式Schema的概念吗？

比如PostgreSQL中一个数据库下还是有Schema的概念的

Show search_path; 语句

索引

以及数据字典

涉及空串的查询 P96

必须用IS NULL 或者IS NOT NULL

用=NULL永远返回False

派生表

AS关键字可以省略，但是必须起一个别名

空值

行列子集视图

视图消解

意思就是转换成对基本表的操作

视图的作用-更清晰的表达

感觉也可以用嵌套查询

比如使用派生表，感觉差不太多

join关键字

ppt貌似只有这里出现过

视图的作用

SQL语言的两种使用方式

交互式和嵌入式

GROUP BY 多个字段

group by 多个字段 - lin_zone - 博客园 (cnblogs.com)

chap4 数据库安全性

不安全因素

用户身份鉴别

存取控制

• 用户权限定义，并将用户权限登记到数据字典中

​ – 用户对某一数据对象的操作权力称为权限

​ – DBMS 提供适当的语言来定义用户权限，存放在数据字典中，称做安全规则或授权规则

• 合法权限检查

• 用户权限定义和合法权检查机制一起组成了数据库管理系统的存取控制子系统

两种存取控制方法

C2 级的数据库管理系统支持自主存取控制（Discretionary Access Control，DAC），B1 级的数据库管理系统支持强制存取控制（Mandatory Access Control，MAC）

– 在自主存取控制方法中，用户对不同的数据对象有不同的存取权限，不同的用户对同一对象也

有不同的权限，而且用户还可将其拥有的存取权限转授给其他用户

– 在强制存取控制方法中，每一个数据对象被标以一定的密级，每一个用户也被授予某一个级别

的许可证，对于任意一个对象，只有具有合法许可证的用户才可以存取

DAC 自主存取控制

PUBLIC

WITH GRANT OPTION

REVOKE

创建数据库模式的权限

数据库角色

先给角色grant权限再把角色grant给用户，能稍微简便点

自主存取控制的缺点

优点就是灵活吧，并且达到了C级别的安全级别（C2？）

缺点如下

MAC？强取存取控制

解释

视图机制

这个间接有点迷，背背吧

审计

审计语句AUDIT

数据加密

存储加密，传输加密等

chap5 数据库完整性

完整性机制

三类

实体完整性

PRIMARY KEY

列级和表级说明

实体完整性检查

唯一 + 主码各属性非空

全表扫描 或 索引（如B+树）

参照完整性

处理

例：SET-NULL

显示说明参照完整性的违约处理

用户定义的完整性

属性上

非空 唯一等

或者使用CHECK关键字

元组上

还可以使用完整性命名子句CONSTRAINT

这样约束就能有名字了，同时也便于删去

主码约束也可以成为Constraint的一部分

删除（修改）CONSTARINT

似乎没有修改语句

只能先DROP掉，再ADD

注意要配合alter table使用

断言

可以定义更具一般性的约束，比如涉及聚合操作等比较复杂的完整性约束

例子

触发器

定义

触发器类型

行级，语句级

例子

这是一个行级触发器，有FOR EACH ROW

这例子有点绕，OLDROW（或者OLD）和NEWROW（或者NEW）是保留字，不随题目变化而变化，Oldgrade和Newgrade只是该题恰好要的两个属性

触发器激活顺序

删除触发器

chap6 关系数据理论

1NF

First Normal Form

通俗理解

虽然chatgpt说理解为“表中有表”并不完全正确

数据依赖

有很多类型

主要是函数依赖和多值依赖

函数依赖 FD Function Dependency

很字面的意思，就是像y=fx一样，y由x决定

1NF：F的表示

范式

模式分解

规范化

函数依赖的标准定义

简单说就是X一样，Y一定一样，所以X->Y

X 函数确定 Y

Y 函数依赖于 X

平凡函数依赖与非平凡函数依赖

关键在于Y是否被包含于X

显然平凡函数依赖没什么意义

完全函数依赖和部分函数依赖

看例子就懂意思了，定义削微有点晦涩

传递函数依赖

Y非平凡依赖于X，Z非平凡依赖于Y，同时X不依赖与Y（否则Z就直接函数依赖于X了）

码

书P181：

在后面的章节中主码或候选码都简称为码

书上这段文字很清晰

外码

1NF

关系数据库的最基本要求

2NF

1NF + 没有非主属性对码的部分依赖

分解成2NF

3NF

为什么不分解成S(Student)-D(Department)和S-L？这样会使得函数依赖关系丢失？不太好

消除了非主属性对码的传递函数依赖

辨析

1NF 2NF 3NF 依赖关系图对比

看图更容易判断

存在非主属性对码的部分函数依赖，所以不是2NF

也有非主属性对码的传递函数依赖，所以不是3NF

存在非主属性对码的传递函数依赖，所以不是3NF

BCNF Boyce Codd NF

修正的第三范式，扩充的第三范式

决定属性集就是指X

1NF + 所有决定属性集都包含候选码/没有主属性对码的部分和传递依赖

BCNF：消除了插入异常和删除异常

BCNF与3NF

多值依赖

简单看了下

例子：

chap7 数据库设计

数据库设计6个阶段

各级模式

需求分析

需求分析过程

数据字典

注意区分之前的“数据字典”

需求分析小结

概念模型

真实反映现实世界，易于理解，可以用于和不熟悉计算机的用户交换意见

1.2.2节 概念模型

实体：学生

属性：学号、姓名

码：学号

实体型：实体名+属性名集合，如学生（学号，姓名）

实体集：全体学生

联系：

概念模型的一种表示方法：实体E-联系R方法 E-R方法 使用 E-R图

联系 Relation

两个实体性之间

两个以上实体型之间

单个实体型内部

员工之间存在领导和被领导的关系

联系的度

几个实体型就是几元联系

E-R图

联系也可以有属性

ISA联系

三角形，代表继承父类所有属性，并且子类可以有自己的属性

分类属性

比如学生类别

可用于进行实体分派

不相交/可重叠约束

既是，又是

能否属于子类中的过多个实体集

完备性约束：是否必须是其中之一？

要么是，要么是

基数约束

左到右 学生 可以选修 20-30门 课程

右到左 课程 可以被0-*个学生选修

Part Of 联系

非独占(的Part Of)联系：整体实体如果被破坏，另一部分实体仍然可以独立存在

独占(的Part Of)联系：整体实体如果被破坏，部分实体不能存在**（整体没了，部分就没了）**

概念结构设计的方法

这部分书上没有？

自顶向下：先全局概念结构

自底向上：先子需求

逐步扩张

混合策略

自底向上的概念结构设计的步骤

实体与属性的划分原则

• 属性不可再有属性

• 属性不能再与其他实体有联系

例子：职工和职称

ppt有好多例子

E-R图的集成

合并 + 重构去除冗余

三类冲突

1属性冲突：整数类型和字符串类型，单位冲突

2命名冲突：同名异义，异名同义（一义多名）

讨论协商解决

3结构冲突

合并

E-R图集成之二：修改和重构

第三步：逻辑结构设计

任务

转换

对于实体型

很直接的转换

对于联系

• 一个 1 ∶ 1 联系可以转换为一个独立的关系模式，也可以与任意一端对应的关系模式合并

• 一个 1 ∶ 𝑛 联系可以转换为一个独立的关系模式，也可以与 𝑛 端对应的关系模式合并

• 一个 𝑚 ∶ 𝑛 联系转换为一个关系模式，与该联系相连的各实体部分的码以及联系本身的属性均转换为关系的属性，各实体的码组成关系的码或关系码的一部分

• 三个或三个以上实体间的一个多元联系转换为一个关系模式

• 具有相同码的关系模式可合并

数据模型的优化

关系数据模型的优化通常以规范化理论为指导，方法为：

• 确定数据依赖

• 对于各个关系模式之间的数据依赖进行极小化处理，消除冗余的联系

• 按照数据依赖的理论对关系模式进行分析，考察是否存在部分函数依赖、传递函数依赖、多值依赖等，确定各关系模式分别属于第几范式

• 按照需求分析阶段得到的各种应用对数据处理的要求，分析对于这样的应用环境这些模式是否合适，确定是否要对它们进行合并或分解

• 对关系模式进行必要分解，提高数据操作效率和存储空间的利用率

并不是规范化程度越高的关系就越优

关系模式的分解

水平分解

元组分解，例如分解出经常用的

80/20原则

垂直分解

对常用属性分解

风险是可能有时必须进行连接操作了

设计用户子模式

应该还是自底向上设计过程中的一部分

现在已经有全局逻辑模型了

现在是根据局部需求，设计用户的外模式

但应该还是处于逻辑结构设计的部分

别名、视图、简化使用

第四步：物理结构设计

存取方法的选择

B+树索引存取

Hash索引存取

聚簇存取

Cluster

例如：

聚簇存取方法的选择

数据库的重组织

数据库的重构造

chap8 数据库编程

JDBC驱动

可以看某次实验的代码

过程化SQL

SQL的扩展

游标

类似于指针吧

SQL块的概念

主要就是两种

命名块有名字，能存储在数据库中供调用

过程和函数的区别在于函数必须制定返回的类型

没太懂存储过程和过程的区别在哪

chap10 数据库恢复技术

事务Transaction

ACID特性

事物的ACID特性：

原子性Atomicity：事务是数据库的逻辑工作单位，事务中包括的诸操作要么都做，要么都不做

一致性Consistency：

隔离性Isolation：

隔离性是指多个并发事务同时运行时，每个事务都被隔离并互不干扰的特性。

隔离性确保了并发事务之间的独立性，以防止出现干扰、数据损坏或不一致的情况。当多个事务同时访问和修改数据库时，隔离性保证每个事务都感觉不到其他事务的存在，就好像它们是按顺序执行的一样。这意味着每个事务将以一种隔离的方式运行，不会受到其他事务的干扰。

持续性Durability：

也称永久性

恢复子系统

故障的种类

故障1-事务内部的故障

非预期的

恢复操作是进行事务撤销（UNDO），即强行回滚事务

故障2-系统故障

又称为“软故障”

恢复

既要UNDO，又要REDO

故障3-介质故障

故障4-计算机病毒

恢复的基本原理

数据转储

简单说就是定期保存下

转储方法1-静态转储

转储方法2-动态转储

转储分类2-海量与增量

所以排列组合后一共可以有4种转储方式

日志文件

协助动态转储的后备副本进行数据库恢复至某一正确状态

以记录为单位的日志文件

以数据块为单位的日志文件

均要记录事务标识

日志文件的作用

最后一点的意思是不需要运行程序，直接根据日志文件记录的一步步操作即可

先日志，后改数据库

原因

恢复策略

事务故障的恢复

事务故障是指未正常运行到commit或者rollback

事务故障的恢复步骤

细读这段可以明白究竟日志文件里面记了些什么

反正开始结束标志肯定记了，然后每个事物都有ID（事务标识），然后有增删改查的操作就记一条（所谓的更新操作，这种记录就会包括上面讲的五个部分）

反向扫描

系统故障的恢复

系统故障的恢复步骤

介质故障的恢复

介质故障的恢复步骤

检查点技术

日志文件加入检查点记录

采取的策略

为什么T1不用重做？有没有可能他的数据还在缓冲区？

没有可能，这正是检查点的作用

因为在“动态维护日志文件”中，有一个步骤是“将当前数据缓冲区的所有数据记录写入磁盘的数据库中”

数据库镜像

有故障时可救火，没故障时还可并发

并不对整个数据库进行镜像

chap11 并发控制

串行、交叉并行、同时并行

事务是并发控制的基本单位

并发操作带来的数据不一致性

1.丢失修改

2.不可重复读

有好几种

还有幻影现象Phantom Row

3.读"脏"数据

原本的修改事务被撤销了，读到了脏数据

并发控制的主要技术

封锁

排它锁：写锁，只能上锁者读写

共享锁：读锁，自己只能读，保证别人不能改

封锁协议

一级封锁协议

因为一定在T改完后

别人才能读或者写，所以不会丢失修改

二级封锁协议

三级封锁协议

小结

不可重复读的理解：

活锁

意思就是有个怨种一直没轮到，一直在等

如何避免

FCFS

死锁

死锁的预防

死锁的诊断

超时法：可能误判

等待图法

等待图法

解除死锁

选择处理代价最小的事务，将其撤销

可串行调度

冲突可串行化：给出一个判断课串行化的充分条件

充分条件

例子

两段锁协议2PL

就是对事务来说，所有获取锁的操作都在释放锁之前

扩展阶段和收缩阶段

遵循2PL协议：又一个可串行化的充分条件

一次封锁法 vs 2PL协议

例如

封锁粒度

选择封锁粒度原则

多粒度树

多粒度协议

显示封锁与隐式封锁

引进意向锁的目的Intention Lock

注意，上层所有节点都要加上意向锁

意向共享锁IS

意向排它锁IX

共享意向排它锁SIX

表达的是，要读这个节点，并且可能修改子节点

意向锁提高了加锁时的检查效率

因为不用往下检查了

例子：

意向锁的作用，相当于就是在低层次资源是否使用，加了一个tag来标识而已。对于步骤2的执行可以大大加速，仅此而已。

(1条消息) 意向锁的作用_werflychen的博客-CSDN博客

意向锁的相容矩阵

意向锁之间，只有互相带X的不兼容

NoSQL

阻抗失谐

集群问题

关系型数据库不适合集群，大规模的数据

涉及分片和复制，但关系型数据库本身其实没有这些概念

所以NoSQL要更加适合集群，有的NoSQL就是分布式的

特点

无模式，上课举了不同宠物有不同的描述属性的例子

有点类似于面向对象的感觉

比如A有属性A1 A2

B可以有B1 B2 B3 B4

不需要每个都有相同的属性列

聚合：名词而非动词

NoSQL特点：无模式

格式不一致的数据

直接看看这两篇文章

《NoSQL精粹》了解NoSQL这一篇就够了_Foools的博客-CSDN博客 这篇全一点，但错别字有点多

NoSQL精粹笔记-概念_面向聚合数据库_平平无奇的小颜的博客-CSDN博客

CAP定理

BASE属性

做题记录

如何判断码

R型没什么写的必要，写出L和LR型就够了

先求所有L型的闭包，不够再LR型一个个加进去

对于判断迷茫了可以看看P203第6题