前言
总结整理不易，希望大家点赞收藏。
给大家整理了一下数据库系统概论中的重点概念，以供大家期末复习和考研复习的时候使用。
参考资料是王珊老师和萨师煊老师的数据库系统概论(第五版)。
数据库系统概论系列文章传送门：
第一章 绪论
第二/三章 关系数据库和标准语言SQL
第四/五章 数据库安全性和完整性
第六/七章 关系数据理论和数据库设计
第八/九章 数据库编程和优化
第十章 数据库恢复技术
第十一章 并发控制
文章目录
第六章 关系数据理论
6.1 规范化
函数依赖：
关系r中不可能存在两个元组在X属性上相等，在Y属性上不相等。成为X->Y。Y函数依赖于X。X决定Y。一个学生的学号能决定学生的姓名，也可称姓名属性依赖于学号。学号->学生姓名
函数依赖从性质上分为完全函数依赖、部分函数依赖和传递函数依赖。
完全函数依赖和部分函数依赖：
例，(sno,con)->grade是完全函数依赖 (sno,cno)->sdept是部分函数依赖因为sno->sdept。
传递函数依赖 A->B B->C 所以A->C
候选码：U是R上的属性。U完全函数依赖于K，K为R的候选码
超码: U部份依赖于K，K为U的超码。候选码是最小的超码
候选码多于一个选定一个为主码
6.2 范式
1NF第一范式:
关系中的每一个分量必须是不可分的数据项。规范化：一个低级的范式的关系模型通过模式分解可以转换成若干高一级的范式。
2NF第二范式：
每一个非主属性完全函数依赖于任何一个候选码，也就是说第二范式是消除了非主属性对码的部份依赖。例如：SLC(sno，sdept，sloc，cno，grade）满足第一范式，不满足第二范式。（sno，cno）->sdept是部分函数以来。要把表拆开。SLC1(sno，sloc，sdept) SLC2(sno，cno，grade)
3NF第三范式：
每一个非主属性既不传递依赖于码，也不部分依赖于码，第三范式消除了非主属性对码的传递依赖。例如：SLC1(sno，sloc，sdept) 满足第二范式，不满足第三范式。再拆SD(sno，sdept) SL(sno，sloc)
BCNF BC范式：
每一个决定因素都有码。不允许主键的一部分被另一部分或者其他部分决定。BC范式一定满足第三范式，但是第三范式不一定满足BC范式。例如：（S,J)->T,(S,T)->J T->J 所有属性都是主属性，满足第三范式，（但T不是码，不满足BCNF）
多值依赖 设R(U)是一个属性集合U上的一个关系模式，X, Y, 和Z是U的子集，并且Z=U-X-Y，多值依赖X->->Y成立当且仅当对R的任一个关系r，r在(X,Z)上的每个值对应一组Y的值，这组值仅仅决定于X值而与Z值无关。Z为空时，X->->Y平凡的多值依赖，多值依赖具有对称性，多值依赖具有传递性，X->->Y, Y->->Z则X->->Z-Y
4NF限制不允许有非平凡非函数依赖的多值依赖
6.3 规范化小结
规范化的基本思想：逐步消除数据依赖中不合适的部分，达到某种程度上的分离，即“一事一地”的设计原则。规范化的目的就是为了解决插入异常，删除异常，数据冗余等问题。规范化实质上是概念的单一化。
第七章 数据库设计
7.1 数据库设计
数据库设计是指对于一个给定的应用环境，设计构造数据库和应用系统使之能够有效地存储和管理数据。满足各种用户地应用需求。
“三分技术，七分管理，十二分基础数据”。重要环节是数据的收集，整理，组织和不断更新。
7.2 数据库设计六个阶段
1、需求分析
2、概念结构设计
3、逻辑结构设计
4、物理结构设计
5、数据库实施
6、数据库运行和维护
7.3 需求分析主要任务
通过详细调查现实世界要处理的对象，明确用户的各种需求，以此确定系统要实现的功能。
用户的要求：
（1） 信息要求
（2）处理要求
（3）安全性和完整性要求
7.4 数据字典
是关于所有数据库数据的描述，即元数据。在需求分析阶段建立，在设计过程中不断修改、完善。在数据库设计过程中有很重要的地位。通常包括数据项、数据结构、数据流、数据存储等。
7.5 概念结构设计
将需求分析得到的用户需求抽象为概念模型的过程就是概念结构设计。是整个数据库设计的关键。
概念模型能真实、充分的反映现实世界。易于理解，易于更改，易于向各种数据模型转换。是数据模型地基础。
7.6 E-R模型：实体、属性、实体之间的联系。
（1）实体型的联系：一对一 （1：1）；一对多（1：n）;多对多（m:n）
（2）实体用矩形，属性用椭圆形，联系用菱形表示
7.7 概念结构设计过程
（1）确定属性和实体，属性必须不能具有描述的性质，不包含其他属性。
（2） 找到属性之间的联系，（一对一之类）
（3） 画E-R图
（4） 大型系统可能会需要集成（先设计子系统的E-R图，然后集成）
7.8 E-R图的集成
（就是将子系统得E-R图集成在一起）一般分两步：合并，修改重构
合并需要消除冲突：属性冲突、命名冲突、结构冲突。
1、属性冲突：属性值的类型、取值范围，单位不一致。
2、命名冲突：同名异义，异名同义。
3、结构冲突：同一对象在不同应用中具有不同的抽象。实体联系在不同的关系中为不同的类型。
7.9 E-R图向关系模型的转换（就是概念模型转逻辑模型）
一个实体型转换为一个关系模型，关系的属性就是实体的属性，关系的码就是实体的码。
根据实体间的联系转换成不同的关系模型（1：1，1：n, m:n）
7.10 数据模型的优化
（1） 确定数据依赖
（2） 对于各关系模型之间的数据依赖进行极小化处理，消除冗余的联系
（3） 按照数据依赖理论对关系模型逐一进行分析
（4） 找到合适的范式来进行分解和合并
7.11 数据库的物理设计通常分两步：
（1） 确定数据库的物理结构：存取方法和存储结构
（2） 对物理结构进行评价，重点是时间和空间效率。之后再进行进一步操作，修改或者数据库实施
7.12 存取方法：快速存取数据库中的数据技术
1、B+树索引，hash索引，聚簇方法。
2、前两者都是建立索引，具体概念参照数据结构
聚簇方法：为了提高某个属性的查询速度，把这个属性上具有相同值的元素集中存放在连续的物理块中称为聚簇，该属性称为聚簇码。一个数据库可以建立多个聚簇，一个关系只能加入一个聚簇。聚簇的开销是相当大的，会导致物理位置发生变化.
B+Tree与 B-Tree 的区别：
1、所有的数据都会出现在叶子节点。
2、叶子节点形成一个单向链表。
MySQL 索引数据结构对经典的B+Tree 进行了优化。在原B+Tree 的基础上，增加一个指向相邻叶子节点的链表指针，就形成了带有顺序指针的 B+Tree，提高区间访问的性能。变成了双向循环链表。
为什么 InnoDB 存储引擎选择使用 B+Tree 索引结构？
答：相对于二叉树，层级更少，搜索效率高。对于 B-Tree，无论是叶子节点还是非叶子节点，都会保存数据，这样导致一页中存储的键值减少，指针也跟着减少，要同样保存大量数据，只能增加树的高度，导致性能降低。相对于 Hash 索引，B+Tree 支持范围匹配及排序操作。
7.13确定数据库的存储结构
考虑三方面：存取时间、存储空间利用率、维护代价三方面。
7.14 数据库的实施
设计人员根据上面的概念模型、逻辑模型、物理设计对数据库进行程序设计、编码。调试，最后运行。
数据要分批分期地组织数据入库，待运行稳定后再大批入库。也要做好转储和恢复的工作防止出现故障。
7.15数据库的运行和维护
（1） 数据库的转储和恢复
（2） 数据库的安全性和完整性控制
（3） 性能的监督、分析和改造
（4） 数据库的重组织与重构造。
数据库重组织不修改原设计的逻辑结构和物理结构，而数据库的重构造会部分修改模式和内模式。
练手题
8.1
这里答案仅作参考，我自己随便写的，照着书好好好好做做，这个题很重要的
8.2
8.3
8.4
8.5
8.6
8.7 语法树
我不知道会不会考，期末考过反正是
弄两个做做吧
8.8
