CS-Notes/notes/数据库系统原理.md

306 lines
13 KiB
Markdown
Raw Normal View History

2018-03-12 12:22:14 +08:00
[TOC]
# 事务四大特性
## 1. 原子性
2018-03-08 15:26:36 +08:00
2018-03-11 17:09:04 +08:00
事务被视为不可分割的最小单元,要么全部提交成功,要么全部失败回滚。
2018-03-08 15:26:36 +08:00
2018-03-12 12:22:14 +08:00
## 2. 一致性
2018-03-08 15:26:36 +08:00
事务执行前后都保持一致性状态。在一致性状态下,所有事务对一个数据的读取结果都是相同的。
2018-03-12 12:22:14 +08:00
## 3. 隔离性
2018-03-08 15:26:36 +08:00
2018-03-11 17:09:04 +08:00
一个事务所做的修改在最终提交以前,对其它事务是不可见的。也可以理解为多个事务单独执行,互不影响。
2018-03-08 15:26:36 +08:00
2018-03-12 12:22:14 +08:00
## 4. 持久性
2018-03-08 15:26:36 +08:00
2018-03-12 08:53:39 +08:00
一旦事务提交,则其所做的修改将会永远保存到数据库中。即使系统发生崩溃,事务执行的结果也不能丢失。持久性通过数据库备份和恢复来保证。
2018-03-08 15:26:36 +08:00
2018-03-12 12:22:14 +08:00
# 数据不一致
2018-03-08 15:26:36 +08:00
2018-03-12 12:22:14 +08:00
## 1. 丢失修改
2018-03-08 15:26:36 +08:00
2018-03-12 12:22:14 +08:00
T<sub>1</sub>  T<sub>2</sub> 两个事务同时对一个数据进行修改T<sub>1</sub> 先修改T<sub>2</sub> 随后修改T<sub>2</sub> 的修改覆盖了 T<sub>1</sub> 的修改。
2018-03-08 15:26:36 +08:00
2018-03-12 12:22:14 +08:00
## 2. 读脏数据
2018-03-08 15:26:36 +08:00
2018-03-12 12:22:14 +08:00
T<sub>1</sub> 做修改后写入数据库T<sub>2</sub> 读取这个修改后的数据但是如果 T<sub>1</sub> 撤销了这次修改使得 T<sub>2</sub> 读取的数据是脏数据。
2018-03-08 15:26:36 +08:00
2018-03-12 12:22:14 +08:00
## 3. 不可重复读
2018-03-08 15:26:36 +08:00
2018-03-12 12:22:14 +08:00
T<sub>1</sub> 读入某个数据T<sub>2</sub> 对该数据做了修改如果 T<sub>1</sub> 再读这个数据,该数据已经改变,和最开始读入的是不一样的。
2018-03-08 15:26:36 +08:00
2018-03-12 12:22:14 +08:00
# 隔离级别
2018-03-08 15:26:36 +08:00
2018-03-11 17:09:04 +08:00
数据库管理系统需要防止出现数据不一致问题,并且有多种级别可以实现,这些级别称为隔离级别。
2018-03-08 15:26:36 +08:00
2018-03-12 12:22:14 +08:00
## 1. 未提交读READ UNCOMMITTED
2018-03-08 15:26:36 +08:00
2018-03-11 17:09:04 +08:00
事务中的修改,即使没有提交,对其它事务也都是可见的。事务可以读取未提交的数据,这也被称为脏读。
2018-03-08 15:26:36 +08:00
2018-03-12 12:22:14 +08:00
## 2. 提交读READ COMMITTED
2018-03-08 15:26:36 +08:00
2018-03-11 17:09:04 +08:00
一个事务只能读取已经提交的事务所做的修改。换句话说,一个事务所在的修改在提交之前对其它事务使不可见的。这个级别有时候也叫做不可重复读,因为两次执行同样的查询,可能会得到不一样的结果。
2018-03-08 15:26:36 +08:00
2018-03-12 12:22:14 +08:00
## 3. 可重复读REPEATABLE READ
2018-03-08 15:26:36 +08:00
2018-03-11 17:09:04 +08:00
解决了脏读的问题,保证在同一个事务中多次读取同样的记录结果是一致的。
2018-03-08 15:26:36 +08:00
2018-03-11 17:09:04 +08:00
但是会出现幻读的问题,所谓幻读,指的是某个事务在读取某个范围内的记录时,另一个事务会在范围内插入数据,当之前的事务再次读取该范围的记录时,会产生幻行。
2018-03-12 12:22:14 +08:00
## 4. 可串行化SERIALIXABLE
2018-03-08 15:26:36 +08:00
2018-03-09 14:22:11 +08:00
强制事务串行执行,避免幻读。
2018-03-08 15:26:36 +08:00
2018-03-12 12:22:14 +08:00
# 可串行化调度
2018-03-08 15:26:36 +08:00
如果并行的事务的执行结果和某一个串行的方式执行的结果一样,那么可以认为结果是正确的。
2018-03-12 12:22:14 +08:00
# 封锁类型
2018-03-08 15:26:36 +08:00
2018-03-12 12:22:14 +08:00
排它锁 (X 和共享锁 (S 又称写锁和读锁。
2018-03-11 17:09:04 +08:00
2018-03-12 12:22:14 +08:00
- 一个事务对数据对象 A 加了 X 就可以对 A 进行读取和更新。加锁期间其它事务不能对 A 加任何其它锁
2018-03-08 15:26:36 +08:00
2018-03-12 12:22:14 +08:00
- 一个事务对数据对象 A 加了 S 可以对 A 进行读取操作但是不能进行更新操作。加锁期间其它事务能对 A  S 但是不能加 X 锁。
2018-03-08 15:26:36 +08:00
2018-03-12 12:22:14 +08:00
# 封锁粒度
2018-03-08 15:26:36 +08:00
2018-03-11 17:09:04 +08:00
应该尽量只锁定需要修改的部分数据,而不是所有的资源。锁定的数据量越少,发生锁争用的可能就更小,则系统的并发程度越高。
但是加锁需要消耗资源,锁的各种操作,包括获取锁,检查所是否已经解除、释放锁,都会增加系统开销。因此需要在锁开销以及数据安全性之间做一个权衡。
2018-03-08 15:26:36 +08:00
2018-03-12 12:22:14 +08:00
MySQL 中主要提供了两种锁粒度行解锁以及表级锁。
2018-03-08 15:26:36 +08:00
2018-03-12 12:22:14 +08:00
# 封锁协议
2018-03-08 15:26:36 +08:00
2018-03-12 12:22:14 +08:00
## 三级封锁协议
2018-03-08 15:26:36 +08:00
2018-03-12 12:22:14 +08:00
![](index_files/785806ed-c46b-4dca-b756-cebe7bf8ac3a.jpg)
2018-03-09 14:22:11 +08:00
2018-03-12 12:22:14 +08:00
**1 级封锁协议**
2018-03-08 15:26:36 +08:00
2018-03-12 12:22:14 +08:00
事务 T 要修改数据 A 时必须加 X 直到事务结束才释放锁。
2018-03-08 15:26:36 +08:00
可以解决丢失修改问题;
2018-03-12 12:22:14 +08:00
**2 级封锁协议**
2018-03-08 15:26:36 +08:00
2018-03-12 12:22:14 +08:00
 1 级的基础上要求读取数据 A 时必须加 S 读取完马上释放 S 锁。
2018-03-08 15:26:36 +08:00
2018-03-12 12:22:14 +08:00
可以解决读脏数据问题因为如果一个事务在对数据 A 进行修改根据 1 级封锁协议会加 X 那么就不能再加 S 锁了也就是不会读入数据。
2018-03-08 15:26:36 +08:00
2018-03-12 12:22:14 +08:00
**3 级封锁协议**
2018-03-08 15:26:36 +08:00
2018-03-12 12:22:14 +08:00
 2 级的基础上要求读取数据 A 时必须加 S 直到事务结束了才能释放 S 锁。
2018-03-08 15:26:36 +08:00
2018-03-12 12:22:14 +08:00
可以解决不可重复读的问题因为读 A 其它事务不能对 A  X 从而避免了在读的期间数据发生改变。
2018-03-08 15:26:36 +08:00
2018-03-12 12:22:14 +08:00
## 两段锁协议
2018-03-08 15:26:36 +08:00
加锁和解锁分为两个阶段进行。两段锁是并行事务可串行化的充分条件,但不是必要条件。
```html
lock-x(A)...lock-s(B)...lock-s(c)...unlock(A)...unlock(C)...unlock(B)
```
2018-03-12 12:22:14 +08:00
# 乐观锁和悲观锁
2018-03-08 15:26:36 +08:00
2018-03-12 12:22:14 +08:00
## 悲观锁
2018-03-08 15:26:36 +08:00
假定会发生并发冲突,屏蔽一切可能违反数据完整性的操作。
2018-03-12 12:22:14 +08:00
Java synchronized 就属于悲观锁的一种实现每次线程要修改数据时都先获得锁保证同一时刻只有一个线程能操作数据其他线程则会被阻塞。
2018-03-08 15:26:36 +08:00
2018-03-12 12:22:14 +08:00
## 乐观锁
2018-03-08 15:26:36 +08:00
假设不会发生并发冲突,只在提交操作时检查是否违反数据完整性。
2018-03-12 12:22:14 +08:00
Java JUC 中的 Atomic 包就是乐观锁的一种实现AtomicInteger 通过 CASCompare And Set操作实现线程安全的自增操作。
2018-03-08 15:26:36 +08:00
2018-03-12 12:22:14 +08:00
乐观锁有两种实现方式数据版本和时间戳。它们都需要在数据库表中增加一个字段使用这个字段来判断数据是否过期。例如数据版本实现方式中需要在数据库表中增加一个数字类型的 version 字段当读取数据时 version 字段的值一同读出。随后数据每更新一次对此 version 值加 1。当提交更新的时候判断读出的 version 和数据库表中的 version 是否一致如果一致则予以更新否则认为是过期数据。
2018-03-08 15:26:36 +08:00
2018-03-12 12:22:14 +08:00
## MySQL 隐式和显示锁定
2018-03-08 15:26:36 +08:00
2018-03-12 12:22:14 +08:00
MySQL InnoDB 采用的是两阶段锁协议。在事务执行过程中随时都可以执行锁定锁只有在执行 COMMIT 或者 ROLLBACK 的时候才会释放并且所有的锁是在同一时刻被释放。前面描述的锁定都是隐式锁定InnoDB 会根据事务隔离级别在需要的时候自动加锁。
2018-03-08 15:26:36 +08:00
2018-03-12 12:22:14 +08:00
另外InnoDB 也支持通过特定的语句进行显示锁定这些语句不属于 SQL 规范
2018-03-08 15:26:36 +08:00
2018-03-12 12:22:14 +08:00
- SELECT ... LOCK IN SHARE MODE
- SELECT ... FOR UPDATE
2018-03-08 15:26:36 +08:00
2018-03-12 12:22:14 +08:00
# 范式
2018-03-08 15:26:36 +08:00
2018-03-12 12:22:14 +08:00
 A->B 表示 A 函数决定 B也可以说 B 函数依赖于 A。
2018-03-08 15:26:36 +08:00
2018-03-12 12:22:14 +08:00
如果 {A1A2... An} 是关系的一个或多个属性的集合,该集合决定了关系的其它所有属性并且是最小的,那么该集合就称为键码。
2018-03-08 15:26:36 +08:00
2018-03-12 12:22:14 +08:00
对于函数依赖 W->A如果能找到 W 的真子集使得 A 依赖于这个真子集那么就是部分依赖否则就是完全依赖
2018-03-08 15:26:36 +08:00
2018-03-12 12:22:14 +08:00
以下关系中Sno 表示学号Sname 表示学生姓名Sdept 表示学院Cname 表示课程名Mname 表示院长姓名。函数依赖为 (Sno, Cname) -> (Sname, Sdept, Mname)。注实际开发过程中不会出现这种表而是每个实体都放在单独一张表中然后实体之间的联系表用实体 id 来表示。
2018-03-08 15:26:36 +08:00
2018-03-12 12:22:14 +08:00
![](index_files/b6a678c0-c875-4038-afba-301846620786.jpg)
2018-03-08 15:26:36 +08:00
不符合范式的关系,会产生很多异常。主要有以下四种异常:
2018-03-12 12:22:14 +08:00
1. 冗余数据
2. 修改异常
3. 删除异常
4. 插入异常,比如如果新插入一个学生的信息,而这个学生还没选课,那么就无法插入该学生。
2018-03-08 15:26:36 +08:00
关系数据库的范式理论就是是为了解决这四种异常。
高级别范式的依赖基于低级别的范式。
2018-03-12 12:22:14 +08:00
## 第一范式 (1NF)
2018-03-08 15:26:36 +08:00
属性不可分。
2018-03-12 12:22:14 +08:00
## 第二范式 (2NF)
2018-03-08 15:26:36 +08:00
每个非主属性完全函数依赖于键码。
可以通过分解来满足。
2018-03-12 12:22:14 +08:00
**分解前**
2018-03-08 15:26:36 +08:00
2018-03-12 12:22:14 +08:00
$$ S(Sno, Cname, Sname, Sdept, Mname) $$
2018-03-08 15:26:36 +08:00
2018-03-12 12:22:14 +08:00
$$ (Sno, Cname) -> (Sname, Sdept, Mname) $$
2018-03-08 15:26:36 +08:00
2018-03-12 12:22:14 +08:00
**分解后**
2018-03-08 15:26:36 +08:00
2018-03-12 12:22:14 +08:00
$$ S1(Sno, Sname, Sdept, Mname)$$
2018-03-08 15:26:36 +08:00
2018-03-12 12:22:14 +08:00
$$ (Sno) -> (Sname, Sdept, Mname$$
2018-03-08 15:26:36 +08:00
2018-03-12 12:22:14 +08:00
$$ (Sdept) ->  (Mname) $$
2018-03-08 15:26:36 +08:00
2018-03-12 12:22:14 +08:00
<center> ![](index_files/8ef22836-8800-4765-b4b8-ade80096b323.jpg) </center>
2018-03-08 15:26:36 +08:00
2018-03-12 12:22:14 +08:00
$$ S2(Sno, Cname, Grade) $$
2018-03-08 15:26:36 +08:00
2018-03-12 12:22:14 +08:00
$$ (Sno, Cname) ->  (Grade) $$
2018-03-08 15:26:36 +08:00
2018-03-12 12:22:14 +08:00
<center> ![](index_files/b0748916-1acd-4138-b24c-69326cb452fe.jpg) </center>
2018-03-08 15:26:36 +08:00
2018-03-12 12:22:14 +08:00
## 第三范式 (3NF)
2018-03-08 15:26:36 +08:00
非主属性不传递依赖于键码。
2018-03-12 12:22:14 +08:00
上述 S1 存在传递依赖Mname 依赖于 Sdept Sdept 又依赖于 Sno可以继续分解。
2018-03-08 15:26:36 +08:00
2018-03-12 12:22:14 +08:00
<center> ![](index_files/923896c1-937e-4a38-b8a6-cec3040b4e2a.jpg) </center>
2018-03-08 15:26:36 +08:00
2018-03-12 12:22:14 +08:00
## BC 范式BCNF
2018-03-08 15:26:36 +08:00
所有属性不传递依赖于键码。
2018-03-12 12:22:14 +08:00
关系模式 STC(Sname, Tname, Cname, Grade),其中四个属性分别为学生姓名、教师姓名、课程名和成绩。有以下函数依赖:
2018-03-08 15:26:36 +08:00
2018-03-12 12:22:14 +08:00
$$ (Sname, Cname) -> (Tname) $$
2018-03-08 15:26:36 +08:00
2018-03-12 12:22:14 +08:00
$$ (Sname, Cname) -> (Grade) $$
2018-03-08 15:26:36 +08:00
2018-03-12 12:22:14 +08:00
$$ (Sname, Tname) -> (Cname) $$
2018-03-08 15:26:36 +08:00
2018-03-12 12:22:14 +08:00
$$ (Sname, Tname) -> (Grade) $$
2018-03-08 15:26:36 +08:00
2018-03-12 12:22:14 +08:00
$$ (Tname) -> (Cname) $$
2018-03-08 15:26:36 +08:00
2018-03-12 12:22:14 +08:00
分解成 SC(Sname, Cname, Grade)  ST(Sname, Tname)对于 ST属性之间是多对多关系无函数依赖。
2018-03-08 15:26:36 +08:00
2018-03-12 12:22:14 +08:00
# 约束
2018-03-08 15:26:36 +08:00
2018-03-12 12:22:14 +08:00
## 键码
2018-03-08 15:26:36 +08:00
用于唯一表示一个实体。键码可以由多个属性构成,每个构成键码的属性成为码。
2018-03-12 12:22:14 +08:00
## 单值约束
2018-03-08 15:26:36 +08:00
某个属性的值是唯一的。
2018-03-12 12:22:14 +08:00
## 引用完整性约束
2018-03-08 15:26:36 +08:00
一个实体的属性引用的值在另一个实体的某个属性中存在。
2018-03-12 12:22:14 +08:00
## 域约束
2018-03-08 15:26:36 +08:00
某个属性的值在特定范围之内。
2018-03-12 12:22:14 +08:00
## 一般约束
2018-03-08 15:26:36 +08:00
一般性约束,比如大小约束,数量约束。
2018-03-12 12:22:14 +08:00
# 数据库的三层模式和两层映像
2018-03-08 15:26:36 +08:00
外模式:局部逻辑结构;模式:全局逻辑结构;内模式:物理结构。
2018-03-12 12:22:14 +08:00
## 外模式
2018-03-08 15:26:36 +08:00
又称用户模式,是用户和数据库系统的接口,特定的用户只能访问数据库系统提供给他的外模式中的数据。例如不同的用户创建了不同数据库,那么一个用户只能访问他有权限访问的数据库。一个数据库可以有多个外模式,一个用户只能有一个外模式,但是一个外模式可以给多个用户使用。
2018-03-12 12:22:14 +08:00
## 模式
2018-03-08 15:26:36 +08:00
2018-03-12 12:22:14 +08:00
可以分为概念模式和逻辑模式,概念模式可以用概念 - 关系来描述;逻辑模式使用特定的数据模式(比如关系模型)来描述数据的逻辑结构,这种逻辑结构包括数据的组成、数据项的名称、类型、取值范围。不仅如此,逻辑模式还要描述数据之间的关系,数据的完整性与安全性要求。
2018-03-08 15:26:36 +08:00
2018-03-12 12:22:14 +08:00
## 内模式
2018-03-08 15:26:36 +08:00
又称为存储模式,描述记录的存储方式,例如索引的组织方式、数据是否压缩以及是否加密等等。
2018-03-12 12:22:14 +08:00
## 外模式/模式映像
2018-03-08 15:26:36 +08:00
把外模式的局部逻辑结构和模式的全局逻辑结构联系起来。该映像可以保证数据和应用程序的逻辑独立性。
2018-03-12 12:22:14 +08:00
## 模式/内模式映像
2018-03-08 15:26:36 +08:00
把模式的全局逻辑结构和内模式的物理结构联系起来,该映像可以保证数据和应用程序的物理独立性。
2018-03-12 12:22:14 +08:00
# ER 
2018-03-08 15:26:36 +08:00
Entity-Relationship包含三个部分实体、属性、联系。
2018-03-12 12:22:14 +08:00
## 实体的三种联系
2018-03-08 15:26:36 +08:00
2018-03-12 12:22:14 +08:00
联系包含 1  11 对多多对多三种。
2018-03-08 15:26:36 +08:00
2018-03-12 12:22:14 +08:00
如果 A  B  1 对多关系那么画个带箭头的线段指向 B如果是 1  1画两个带箭头的线段如果是多对多画两个不带箭头的线段。
2018-03-08 15:26:36 +08:00
2018-03-12 12:22:14 +08:00
![](index_files/292b4a35-4507-4256-84ff-c218f108ee31.jpg)
2018-03-08 15:26:36 +08:00
2018-03-12 12:22:14 +08:00
## 表示出现多次的关系
2018-03-08 15:26:36 +08:00
2018-03-12 12:22:14 +08:00
一个实体在联系出现几次就要用几条线连接。如下表示一个课程的先修关系先修关系中应当出现两个 Course 实体第一个是先修课程后一个是后修课程因此需要用两条线来表示这种关系。
2018-03-08 15:26:36 +08:00
2018-03-12 12:22:14 +08:00
![](index_files/8b798007-e0fb-420c-b981-ead215692417.jpg)
2018-03-08 15:26:36 +08:00
2018-03-12 12:22:14 +08:00
## 联系的多向性
2018-03-08 15:26:36 +08:00
下图中一个联系表示三个实体的关系。虽然老师可以开设多门课,并且可以教授多名学生,但是对于特定的学生和课程,只有一个老师教授,这就构成了一个三元联系。
2018-03-12 12:22:14 +08:00
![](index_files/423f2a40-bee1-488e-b460-8e76c48ee560.png)
2018-03-08 15:26:36 +08:00
一般只使用二元联系,可以把多元关系转换为二元关系。
2018-03-12 12:22:14 +08:00
![](index_files/de9b9ea0-1327-4865-93e5-6f805c48bc9e.png)
2018-03-08 15:26:36 +08:00
2018-03-12 12:22:14 +08:00
## 表示子类
2018-03-08 15:26:36 +08:00
2018-03-12 12:22:14 +08:00
 is-a 联系来表示子类具体做法是用一个三角形和两条线来连接类和子类。与子类有关的属性和联系都连到子类上而与父类和子类都有关的连到父类上。
2018-03-08 15:26:36 +08:00
2018-03-12 12:22:14 +08:00
![](index_files/7ec9d619-fa60-4a2b-95aa-bf1a62aad408.jpg)
2018-03-08 15:26:36 +08:00
2018-03-12 12:22:14 +08:00
# 一些概念
2018-03-08 15:26:36 +08:00
2018-03-12 12:22:14 +08:00
**数据模型** 由数据结构、数据操作和完整性三个要素组成。
2018-03-08 15:26:36 +08:00
2018-03-12 12:22:14 +08:00
**数据库系统** 包括了数据库,数据库管理系统,应用程序以及数据库管理员和用户,还包括相关的硬件和软件。也就是说数据库系统包含所有与数据库相关的内容。
2018-03-08 15:26:36 +08:00
2018-03-12 12:22:14 +08:00
# 参考资料
2018-03-08 15:26:36 +08:00
2018-03-12 12:22:14 +08:00
- 史嘉权. 数据库系统概论[M]. 清华大学出版社有限公司, 2006.
- 施瓦茨. 高性能MYSQL(第3版)[M]. 电子工业出版社, 2013.
- [MySQL 乐观锁与悲观锁 ](https://www.jianshu.com/p/f5ff017db62a)