软件设计师笔记：数据库系统

一、考试内容

数据库系统（上午下午都考，很重要，上午的分值6—8分）与数据库设计（下午考ER图，拿到15分，容易）

二、数据库模式

三级模式两级映射：

三级模式：
外模式（视图级，用户级的数据库）：逻辑模式，与用户打交道，可以通过视图想获取什么信息就获取什么信息
概念模式（表级，概念级的数据库）：就是我们经常用的数据表
内模式（文件级，物理级数据库）：存储模式，物理结构，如何的存储数据

两层映射
外模式/概念模式（视图和表之间有一层映射关系）：逻辑独立性
概念模式/内模式（表和数据存储的一种映射关系）：数据独立性

只需要修改映射，就保证了两个独立型。

三、数据库设计

3.1 数据库设计过程

数据库设计过程，不同的过程产生不同的产物

数据库设计的过程：

1. 需求分析（产生数据流图，数据字典、需求说明书）
2. 概念结构设计（E-R 图，描述不同实体的属性行为，以及实体和实体之间的关系）
3. 逻辑结构设计（根据E-R模型，将实体之间的关系，通过范式理论，建表）
4. 物理设计（根据表的一些字段属性，进行物理存储）

3.2 ER模型

E-R 图研究的是实体与实体之间的关系
包含实体，联系、属性三部分




一对一：可以把关系单独转化为一个关系模式，也可以合并到两个实体中的任何一个。

一对多：可以把关系单独转化为一个关系模式，也可以合并到两个实体中的“多”的那一个实体（例如一个部门和多个员工，可以给员工这个实体发一个部门标志，而不是给部门发多个不同员工的不同铭牌）。

多对多：关系也必须单独转化为一个关系模式。

3.3 关系代数

一般以选择题形式出现，一般是给一个关系代数表达式，让我们找出等价的关系代数表达式，或者给一个场景并要求写出对应的关系代数表达式。

笛卡尔积：

其中S1的记录与S2中记录作两两拼接得到新的记录为笛卡尔积。属性数为S1和S2属性数之和，记录数为S1和S2记录数之积。

投影和选择操作的条件可以用列数代替属性名。

联接操作：

联接操作中一般要写联接的条件。连接操作后，将会把S1和S2都有的字段只保留1个。

在没有写联接条件的情况下，称为自然联接，默认将两个关系中相同字段作等值。

特别注意笛卡尔积含中两个关系的字段列，而联接只有一个整合的字段列。特别注意在投影操作上例中Sno，Sname，Age时，投影条件中的列数在联接中为1，2，4；在笛卡尔积中为1，2，5（第四列为S2的Sno）。

四、规范化理论

4.1 函数依赖

函数依赖是规范化理论的基础。

函数依赖的简单理解，比如y=x²，y依赖于x，即一个确定的x值可以确定一个y值，反过来不可以。又或者一个学号可以唯一确定一名学生，但是一个学生的姓名，不一定对应唯一一个确定的学号。

部分函数依赖：举一个简单的例子，一个学号和一个课程号可以唯一确定一个（学生的）姓名，很显然这是可以的，而且仅仅一个学号其实就已经可以确定一个姓名，这就是部份依赖。即主键是组合键，其中的一部分可以确定某一个属性，为部份依赖。

传递函数依赖：顾名思义，但是值得注意的是，B不能确定A，否则AB等价，就不存在传递的说法了。

4.2 规范化理论的价值与用途

为什么要用规范的关系模式？

关系模式R（之所以存在关系模式，目的就是消除数据冗余，只要存在数据冗余，就会有修改异常、插入异常、删除异常）

既然要规范，就要知道几种键

超键、候选键、主键都可以标识一个元组

超键（存在冗余属性）
候选键（不存在冗余属性）
主键（在众多候选键中选一个，这是自定义选择的）
外键：其他关系表中的主键

规范化理论也存在一些问题，所以也有逆规范化、反规范化理论。

4.3 求候选键

超键唯一标识元组，但是可能存在多余属性，消除了多余属性才能是候选键。

主键即在候选键中任选一个。

图示法求候选键：

例1中入度为零的为A1，即一个节点被箭头指向的数目为入度，同理A4是出度为零。若入度为零的节点出发，可以遍历所有的节点最后走出去，则该出发节点就是候选键。即A1为候选键。

例2中的情况，我们发现ABCD均入度为零，且其中任意一个节点出发均不能遍历所有节点，所以候选键必定为组合键，答案为ABCD组合键。

需要注意的是ABD->E代表ABD组合键确定E，画法应如图所示三条线汇成一条线，只有一个箭头，若ABD三个节点画一条线，即共三个箭头指向E代表的是ABD三个节点每个节点都可以单独确定E，与题意不符。

既然E只有ABD组合键才能遍历到，这说明如果要遍历所有节点，候选键至少应该是ABD组合键，又因为I和J只有C能遍历到，所以该题目的候选键为ABCD组合键。

例题3中我们发现没有入度为0的节点，那我们就要找中间节点（既有入度又有出度的节点），且要求该节点能够遍历所有的节点，那么该节点就是候选键。故该题目中候选键为A和B（不能写成AB，这代表AB组合键为候选键）

4.4 范式

第一范式：

第二范式：

非主属性，如图中的学分，和组合键中的学号实际上可以没有依赖关系，所以应该消除该部份依赖。具体操作为将表格拆分，把学分和课程号单独组成第二张表。

第三范式：

第三范式要求非主属性之间无依赖关系

BC范式：

要求每个依赖关系当中，决定因素一方（即依赖关系箭头起始端）必须包含候选键。

例题：

问题一考察部份依赖和传递依赖C
问题二考察一对多的联系（部门和职工）中联系放在数量多的一方（职工）D
问题三A

4.5 模式分解

保持函数依赖分解：

假设A->B,B->C,那么分解如图R1和R2均各自保持了函数依赖了A->B和B->C，总的来说，这样的分解保持了函数依赖。而分解成R1和R3没有保持函数依赖。

如果A->B,B->C,A->C，那么分解成R1和R2依然保持了函数依赖，原因是A->C是冗余的，无需被保持。

无损分解：

把R关系模式分成三个，如果不能还原回来，就是有损的；如果能够通过连接操作，形成原来的关系模式，就是无损的。

判断是否无损分解的习题：

一般判断是否无损分解有两种解法，上图所示的题目只能用第一种方法——表格法。

表格法：

每一行都是每个被拆分的子关系模式，a表示该关系模式拥有的属性，b表示未包含。

然后查找该表中每一行拥有的函数依赖，并将另外的只拥有该依赖的决定因素但没有被决定因素的那一行，把被决定因素的b改为a。所有操作结束后，如果存在一行使得该行所有元素均为a，则称该分解为无损分解。

如下所示：

第二种方法为公式法，但是有一个局限性，该方法要求原关系模式只能被分为两个子关系模式。

如下图：

该方法步骤为，将被分成的两个子关系模式作交操作，将得到的属性设为A，将第一个子关系模式与第二个子关系模式做差得到的属性设为B，将第二个子关系模式与第一个子关系模式做差得到的属性设为B。

令A->B，A->C，若其中任意一个函数依赖被原关系模式的函数依赖所满足，则称该分解为无损分解。

五、并发控制

5.1 基本概念

事务具有以上四个性质：

1. 原子性即事务一旦开始执行，则要执行完全部操作，不能只执行一部分，不可拆分，所以具有原子性。
2. 例如银行转账，从一个账户转到另一个账户，钱数总额应该是相等的，即一致性。
3. 两个事务之间相互独立，不被干扰。
4. 事务执行产生的结果具有持续有效的特点。

5.2 并发存在的问题

丢失更新：事务T2执行A=A-8后，T1的A得到的结果在使用前被覆盖掉，即丢失更新。

不可重复读：T1在执行前面操作后，对数据重新读取时，数据可能已被其他事务更改。

读“脏”数据：T1事务在执行过程中，某数据在被执行的过程中产生了中间值，但是此值实际是无效无意义的，但是有可能被其他事务错误的拿去使用。

5.3 封锁协议

X锁为排他锁，某事务对一个数据加X锁后，其他事务不能加任何锁。
S锁为共享锁，某事务对一个数据加S锁后，其他事务不能加排他锁，但是可以加共享锁。

封锁协议有三级。
　　一级：当某一事务在修改数据时加独占锁(exclusive locks, write locks)，直到事务结束(提交或者回滚)释放。因为不能同时对某一数据进行修改，所以一级封锁协议可防止丢失更新。但是读取数据时没有加任何锁，它还是可以读取加了独占锁的数据，所以不能防止脏读不可重复读。
　　二级：在一级封锁基础上事务读数据时加共享锁(shared locks , read locks)，读取之后释放(共享锁范围是每次读取)。二级封锁协议可防止丢失更新，脏读。不能防止不可重复读。
　　三级：在一级封锁基础上事务读数据时加共享锁，直到事务结束释放(共享锁范围是整个事务)。三级封锁协议可防止丢失更新，脏读，不可重复读。

数据库完整性约束（提高数据可靠性的一种机制）：

实体完整性约束：定义主键，主键不能为空，主键唯一标识（例如你在一个数据表中填写了主键，再次填写相同的主键会报错，如果不填写也会报错）

参照完整性约束：F是R中表的外键，与S表中的主键K相对应（K就是F，在S表中是主键，在R表中是外键），F要么在R中为空值，要么在S中等于K

用户自定义完整性约束：根据需求自己定义，例如年龄范围，不能是负一，也不能超过100

触发器：用脚本约束数据库中的数据

六、数据库安全

七、数据库备份与恢复

7.1 数据备份

冷备份与热备份：

备份的另一种分类方式：

增量备份只针对上一次备份数据的变化进行存储，存储速度快，但是如果连续使用增量备份，则恢复需要恢复上一个完全备份后一步一步恢复到需要恢复到的时间版本。使用差量备份是针对上一次完全备份后到目前为止所发生的变化进行存储，存储速度比增量备份慢，但是恢复时只需要恢复上一个完全备份版本后加上完全备份版本到所需版本之间的差量即可。

但是这并不能保证每次恢复数据的完整性，如图中例子所示，存储可能是一天进行一次，如果数据库的故障发生在下一次存储时间点之前，那么上一个存储点到发生故障这段时间的所有数据都将不被保存下来。所以使用日志来解决这一问题，在对数据库做任何改变前，都会将操作记录在日志中。

7.2 数据库的故障与恢复：

八、数据仓库与数据挖掘

九、反规范化

属于以空间换时间。

十、大数据