> ## Documentation Index > Fetch the complete documentation index at: https://base.bangwu.me/llms.txt > Use this file to discover all available pages before exploring further. # 数据库原理 > 数据库原理与应用课程的系统复习笔记与知识点整理，涵盖关系代数传统集合与专门运算、SQL 数据定义查询操纵控制四大功能语句、第一到第三范式及 BCNF 规范化分解理论、事务 ACID 四大特性与隔离级别、B+ 树索引存取结构以及数据库故障恢复技术与安全性存取控制机制。 # 数据库原理与应用考试相关-2023 \---------------------------------------- **考试题型** **一. 选择题（10分，5题，每题2分）** **二. 填空题（15分，5题，每题3分）** **三. 简答题（15分，3题，每题5分，要求尽量详细，逻辑清晰，层次分明）** **四. 设计题（60分。第一题10分；第二题50分，共10道编程题，每题5分）** *** **\* 出题思路：从以下重点中出相应的题目，然后再随机选择上述题型和数目，再做微调。** \---------------------------------------- 考试重点： # 一. 绪论 1. `数据库的4个基本概念 P10` * 数据，数据库，数据库管理系统，数据库系统 2. `数据库的定义 P14` * 数据库是长期存储在计算机内有组织、大量、共享的数据集合 3. `数据库（系统）的基本特征 P14 / P37 - P41` * 可供用户共享，冗余度低且易扩充，较高的数据独立性 4. `数据库管理系统的主要功能 P17 - P19` * 数据定义功能（DDL），数据组织、存储和管理，数据操纵功能（DML），数据库的事务管理和远行管理，数据库的建立和维护功能，数据库和网络中其他软件系统的通信功能 5. `数据库系统的构成 P20 - P21` * 数据库，数据库管理系统（及其开发工具），应用程序和数据库管理员 6. `数据库系统的特点 P37-P41` * 数据结构化，数据的共享性高、冗余度低、易扩充，数据独立性高，数据由DBMS统一管理和控制 7. `数据独立性高如何理解 P40` * 指一个应用程序的数据库模式和数据存储方式不依赖于其他应用程序或操作系统平台的特定实现 8. `数据库管理系统如何控制数据共享 P41` * 数据库访问权限控制，数据库元数据控制，数据加密，数据库复制，数据库分区， 9. `概念模型、逻辑模型和物理模型的概念 P47` * 概念模型是对现实世界的抽象和简化，它用于描述数据库中的数据和数据之间的关系，是数据库设计的核心，是数据库建模的基础； * 逻辑模型是概念模型的逻辑表示，它用于存储数据库中的数据和数据之间的关系； * 物理模型是逻辑模型在物理存储设备上的表示，它用于存储和管理数据库中的数据； 10. `数据模型的组成要素 P57` * 实体，属性，关系，实体间的约束，数据类型和精度 11. `数据模型中的数据结构 P58` * 数据模型中的数据结构是指数据在数据库中的存储方式和表示方式； * 表，视图，索引，主键和外键， 12. `数据模型中的数据操作 P59` * 增加、删除和修改，插入操作，查询操作，数据备份和恢复操作，事务操作 13. `数据模型中的完整性约束条件 P60` * 是指用于保证数据库中数据完整性的一组规则； * 实体完整性，属性完整性，参照完整性，用户定义完整性 14. `关系模型谁提出的？ P84` * 美国IBM公司San Jose研究室的研究员E.F.Codd 15. `类型和值的概念 P95 - P96` * 类型：类型是用来描述数据结构和数据类型的标识符，它们通常以关键字的形式出现； * 常见类型：整数型，字符型和日期型; * 值：值是指数据的具体内容和值，通常是用户输入或程序产生的数据； 16. `数据库系统的三级模式结构 P99 - P105` * 物理层：物理层是指数据存储数据的实际物理设备，确保数据的可靠性和安全性； * 概念层：概念层是指数据库中的数据模型和数据结构，是数据库设计和实现的核心； * 逻辑层：逻辑层是指数据库管理系统中的应用程序，是数据库管理和维护的直接对象 17. `数据库系统的两级映射功能 P107 - P114` 是指数据库管理系统将数据存储在物理设备上，并将数据提供给用户进行查询和操作； 数据库：是数据库管理系统中存储数据的地方，是数据库管理系统的物理实现； 数据库管理系统应用程序：是数据库管理系统中的应用程序。数据库管理和维护的直接对象 # 二. 关系数据库 1. `关系数据库的提出者和时间 P4` * E.F.Codd 2. `何为关系 P7` * 是数据库的一种基本概念，用于描述数据库中数据之间的关系，是实体之间的关系，描述了实体之间的联系和交互，可以是一对一，一对多，多对多 3. `域 P9` * 域是一组具有相同数据类型的值的集合 4. `笛卡尔积 P10 - P14` * 笛卡尔积是域上的一种集合运算 5. `关系和笛卡尔积的关系 P17，P19` * 关系是笛卡尔积的有限子集 6. `码 P18` * 码是指一种编码方式，用于表示特定的数据或者实体，通常有一组数字、字母或者其他符号组成 7. `三类关系 P20` * 一对一：两个表之间一对一的关系； * 一对多：两个表之间的一对多的关系； * 多对多：指三个表及以上表之间的多对多的关系； 8. `基本关系的性质 P22` * 1.列是同质的，即每一列中的分量是同一类型的数据，来自同一个域 * 2.不同的列可出自同一个域，称其中的每一列为一个属性，不同的属性要给予不同的属性名 * 3.列的顺序无所谓，即列的次序可以任意交换 * 4.任意两个元组的候选码不能取相同的值 * 5.行的顺序无所谓，即列的次序可以任意交换 * 6.分量必须取原子值，即每一个分量都必须是不可分的数据项 9. `关系模式的定义 P26` * 关系的描述称为关系描述 10. `基本的关系操作 P36` * 查询操作，插入、删除、修改操作两大部分 * 查询操作又可以分为选择，投影，连接，除，并，差，交，笛卡尔积 11. `SQL的4大功能 P39` * 数据定义，数据查询，数据操纵，数据控制 12. `三类完整性约束 P41` * 实体完整性，参照完整性，用户定义完整性 13. `实体完整性规则 P43 - P44` * 若属性（指一个或一组属性）A是基本关系R的主属性，则A不能取空值 14. `外码 P50` * 设F是基本关系R的一个或一组属性，但不是关系R的码，KS是S的主码。如果F与KS相对应，则称F是R的外码，并称基本关系R为参照关系，基本关系S为被参照关系或目标关系 14. `参照完整性 P55 - P56` * 又称引用完整性，是相关联的两个表之间的约束 15. `用户定义的完整性 P60` * 用户定义的完整性就是针对某一具体关系数据库的约束条件，它反映某一具体应用所涉及的数据必须满足的语义要求 16. `关系代数运算符 P64` * 并，差，交，笛卡尔积和选择，投影，连接，除运算 17. `传统的集合运算 P66 - P74` * 并，差，交，笛卡尔积 18. `专门的关系运算（除运算除外） P85 - P103` * 选择，投影，连接，除运算 19. `关系运算符的运用 P110` * 自己学 # 三. SQL 1. `SQL的中文和英文 1P51` * 结构化查询语言，Structured Query Language SQL 2. `SQL的功能和特点 1P55 - 1P61` * 综合统一，高度非过程化，面向集合的操作方式，以同一种语法结构提供多种使用方式， * 语言简洁，易学易用 * 数据查询，数据操纵，数据定义，数据控制 3. `内模式/模式/外模式 与 存储文件/基本表/视图 之间概念关联 1P64 - 1P67` * 外模式：又称子模式或用户模式，是用户可以看见和使用的局部数据的逻辑结构和特征的描述； * 模式：又称逻辑模式，是数据库中全体数据的逻辑结构和特征的描述，是所有数据的公共数据视图 * 内模式：又称为存储模式，是数据库物理结构和存储方式的描述，是数据在数据库内部的表示方式 * 数据按外模式的描述提供给用户，按内模式的描述存储在硬盘上，而模式介于外，内模式之间，既不涉及外部的访问，也不涉及内部的存储，从而起到隔离作用，有利于数据的独立性，内模式依赖于全局逻辑结构，但可以独立于具体的存储设备。 * 基本表：独立存在的表； * 视图：一个虚拟的表，是从一个或几个基本表导出的表； * 数据库中只存放视图的定义而不存放视图对应的数据，这些数据仍存放在导出视图的基本表中，当基本表的数据发生变化时，从视图中查询出来的数据也随之改变 4. `数据定义的所有代码 1P74 - 1P99` * 创建：create schema; create table; create view; create index; * 删除：drop schema; drop table; drop view; drop index; * 修改：alter table; alter index 5. `数据字典是什么 1P101` * 数据字典是关系数据库管理系统内部的一组系统表，它记录了数据库中所有的定义信息，包括关系模式定义，视图定义，索引定义，完整性约束定义，各类用户对数据库的操作权限，统计信息等。 6. `单表查询 1P106 - 1P137` * 单表查询是指仅涉及一个表的查询 7. `连接查询 2P8 - 2P24` * 若一个查询同时涉及到两个以上的表，则称之为连接查询。 8. `嵌套查询（EXISTS除外） 2P26 - 2P48` * 一个SELECT-FROM-WHERE语句称为一个查询块，将一个查询块嵌套在另一个查询块的WHERE子句或HAVING短语的条件中的查询称为嵌套查询。 * 如果子查询的查询条件依赖父查询，则称为相关子查询，整个查询语句称为相关嵌套查询， * 反之则称为不相关子查询， 9. `集合查询 2P58 - 2P63` * 并操作：UNION，交操作：INTERSECT，差操作：EXCEPT 10. `基于派生表的查询 2P65 - 2P66` * 子查询不仅可以出现在WHERE子句中，还可以出现在FROM子句中，这时子查询生成的临时派生表成为主查询的查询对象。 11. `插入数据 3P6 - 3P13` * INSERT INTO（表名）VALUES（值） * INSERT INTO（表名）子查询 12. `修改数据 3P15 - 3P20` * UPDATE（表名）SET（列名）WHERE（条件） 13. `删除数据 3P22 - 3P27` * DELETE FROM（表名）WHERE（条件） 14. `Drop和DELETE的区别` * Drop一般用于删除整体性数据，如表，模式，索引，视图和完整性限制， * DELETE用于删除局部性数据，如表中的某一元组 15. `空值相关 3P29 - 3P37` * 空值是一个很特殊的值，含有不确定性， * 属性定义（域定义）中有NOT NULL约束条件的不能取空值，加了UNIQUE限制的属性不能取空值，码属性不能取空值 16. `视图的特点 3P39` * 视图：一个虚拟的表，是从一个或几个基本表导出的表； * 数据库中只存放视图的定义而不存放视图对应的数据，这些数据仍存放在导出视图的基本表中，当基本表的数据发生变化时，从视图中查询出来的数据也随之改变 * 17. `建立视图 3P42 - 3P52` * CREATE VIEW（视图名）AS（子查询）\[WITH CHECK OPTION] 18. `删除视图 3P53` * DROP VIEW（视图名）\[CASCADE] * CASCADE可以将该视图导出的其他视图一并删除 19. `视图更新的限制 3P66 - 3P68` * 1.若视图是由两个以上基本表导出的，则此视图不允许更新； * 2.若视图的字段来自字段表达式或常数，则不允许对此视图执行INSERT和UPDATE操作，但允许使用DELETE操作； * 3.若视图的字段来自聚集函数，则此视图不允许更新； * 4,若视图定义中含有GROUP BY语句，则此视图不允许更新； * 5.若视图定义中含有DISTINCT短语，则此视图不允许更新； * 6.若视图定义中有嵌套查询，并且内层查询的FROM子句中涉及的表也是导出该视图的基本表，则此视图不允许更新； * 7.一个不允许更新的视图上定义的视图也不允许更新。 20. `视图的作用 P72` * 1.简化用户的操作； * 2.使用户能以多种角度看待同一数据； * 3.对重构数据库提供了一定程度的逻辑独立性； * 4.能够对机密数据提供安全保护； * 5.适当利用视图可以更清晰地表达查询。 # 四. 数据库安全性 1. `数据库安全性问题的提出 P4` * 数据库的安全性是指保护数据库以防止不合法使用所造成的数据泄露、更改或破坏 2. `数据库的不安全因素 P8 - P11` * 1.非授权用户对数据库的恶意存取和破坏； * 2.数据库中重要或敏感的数据被泄露； * 3.安全环境的脆弱性； 3. `数据库安全性控制的流程 P35` * 1.用户标识和鉴定（静态口令鉴别，动态口令鉴别，生物特征鉴别，智能卡鉴别）； * 2.存取控制（自主存取控制，强制存取控制）； * 3.授权：授予和回收（grant，revoke，创建数据库模式的权限）； * 4.数据库角色（角色的创建，给角色授权，将一个角色授予其他的角色或用户，角色权限的收回）； 4. `用户身份鉴定的概念和方法 P38 - P43` * 静态口令鉴别： * 动态口令鉴别： * 生物特征鉴别： * 智能卡鉴别： 5. `存取控制 P46` * 存取控制机制主要包括定义用户权限和合法权限检查两部分； 6. `常用的两种存取控制方法 P47 - P48` * 自主存取控制：用户对于不同的数据库对象有不同的存取权限，不同的用户也对同一对象也有不同的权限，而且用户还可将其拥有的存取权限转授给其他用户，因此自主存取控制十分灵活； * 强制存取控制：每一个数据库对象被标以一定的密级，每一个以后也被授予某一个级别的许可证。对于任意一个对象，只有具有合法许可证的用户才可以存取，因此强制存取控制相比比较严格。 * 7. `权限授予的SQL代码 P54 - P68` ```sql theme={"theme":{"light":"github-light","dark":"github-dark"}} GRANT（权限）ON（对象类型）（对象名）TO（用户）[WITH GRANT OPTION] ``` 8. `权限回收的SQL代码 P69 - P73` ```SQL theme={"theme":{"light":"github-light","dark":"github-dark"}} REVOKE（权限）ON（对象类型）（对象名）FROM（用户）[CASCADE|RESTRICT] ``` 9. `数据库角色的概念 P76` * 数据库角色是被命名的一组与数据库操作相关的权限，角色是权限的集合。 10. `数据库角色的SQL代码 P77 - P83` ```sql theme={"theme":{"light":"github-light","dark":"github-dark"}} CREATE ROLE（角色名）； GRANT（权限）ON（对象类型）（对象名）TO（用户）[WITH GRANT OPTION]； REVOKE（权限）ON（对象类型）（对象名）FROM（用户）[CASCADE|RESTRICT] ``` `视图机制在安全性控制中的作用` * 视图机制间接地实现支持存取谓词的用户权限定义，通过视图机制把要保密的数据对无权存取的用户隐藏起来，从而自动对数据提供一定程度的安全保护 # 五. 数据库完整性 1. `数据库完整性的概念 P4` * 数据库的完整性是指数据的正确性和相容性； * 数据的正确性是指数据是符合现实世界语义、反映当前实际状况的； * 数据的相容性是指数据库同一对象在不同关系表中的数据是符合逻辑的 2. `数据库完整性和安全性的异同 P5` * 数据的完整性是为了防止数据库中存在不符合语义的数据，也就是防止数据库中存在不正确的数据； * 数据的安全性是保护数据库防止恶意破坏和非法存取。 3. `数据库管理系统如何维护数据库的完整性 P6 - P10` * 1.提供定义完整性约束条件的机制； * 2.提供完整性检查的方法； * 3.进行违约处理； 4. `实体完整性定义的代码 P13 - P16` ```SQL theme={"theme":{"light":"github-light","dark":"github-dark"}} （列名）PRIMARY KEY； PRIMARY KEY（列名）（必须设置列名不为空值） ``` 6. `实体完整性的检查和违约处理 P18` 自动检查： 1.检查主码值是否唯一，如果不唯一则拒绝插入或修改； 2.检查主码的各个属性是否为空，只要有一个为空就拒绝插入或修改 检查记录中主码是否唯一的一种方法就是进行全表扫描，依次判断表中每一条记录的主码值与将插入记录的主码值（或者修改的新主码值）是否相同 7. `参照完整性定义的代码 P24 - P25` * 参照完整性在CREATE TABLE中用FOREIGN KEY短语定义哪些列为外码，用REFERENCES短语指明这些外码参照哪些表的主码 ```SQL theme={"theme":{"light":"github-light","dark":"github-dark"}} FOREIGN KEY（列名）REFERENCES （表名）（列名） ``` 8. `参照完整性的检查和违约处理 P27 - P35` * 拒绝（NO ACTION）执行：不允许改操作执行。该策略一般设置为默认策略； * 级联（CASCADE）操作：当删除或修改被参照表的一个元组导致与参照表的不一致时，删除或修改参照表中所有导致不一致的元组 * 设置为空值：当删除或修改被参照表的一个元组时造成了不一致，则将参照表中的所有造成不一致的元组的对应属性设置为空值 9. `用户定义完整性 P40 - P50` * 用户定义的完整性就是针对某一具体应用的数据必须满足的语义要求。 一. **属性上的约束条件p163** 1. 属性上约束条件的定义 2. 属性上约束条件的检查和违约处理 二. **元组上的约束条件p163** 1. 元组上约束条件的定义 2. 元组上约束条件的检查和违约处理 3. 完整性约束命名的SQL P53 - P57 ```SQL theme={"theme":{"light":"github-light","dark":"github-dark"}} CONSTRAINT（完整性约束条件名）（完整性约束条件） 完整性约束条件包括 NOT NULL，UNIQUE，PRIMARY KEY，FOREIGN KEY，CHECK短语 可以使用ALTER TABLE语句修改表中的完整性限制 ALTER TABLE Student DROP CONSTRAINT C4; ALTER TABLE Student ADD CONSTRAINT C1 CHECK(Sno BETWEEN 900000 AND 999999); ``` 10. `触发器的定义、激活与删除 P68 - P78` **触发器**是一种特殊类型的[存储过程](https://so.csdn.net/so/search?q=存储过程\&spm=1001.2101.3001.7020)，它不同于存储过程，主要是通过事件触发而被执行的，即不是主动调用而执行的；而存储过程则需要主动调用其名字执行 [触发器](https://so.csdn.net/so/search?q=触发器\&spm=1001.2101.3001.7020)：trigger，是指事先为某张表绑定一段代码，当表中的某些内容发生改变（增、删、改）的时候，系统会自动触发代码并执行。 ```sql theme={"theme":{"light":"github-light","dark":"github-dark"}} delimiter 自定义结束符号 create trigger 触发器名字 触发时间 触发事件 on 表 for each row begin -- 触发器内容主体，每行用分号结尾 end 自定义的结束符合 delimiter ; ``` * 触发器是用户定义在关系表上的一类由事件驱动的特殊过程。 * 触发器的定义P168 * 触发器的执行是由触发事件激活，并由数据库服务器自动执行的。 * 1. 执行该表上的BEFORE触发器 2. 激活触发器的SQL语句 3. 执行该表上的AFTER触发器 ```sql theme={"theme":{"light":"github-light","dark":"github-dark"}} 删除触发器的SQL语法：DROP TRIGGER（触发器名）ON（表名） ``` # 六. 关系数据理论 * 数据依赖是一个关系内部属性与属性之间的一种约束关系。这种约束关系是通过属性间值的相等与否体现出来的数据间相关联系。它是现实世界属性间相互联系的抽象，是数据内在的性质，是语义的体现。 1. `现实世界已知语义得到的函数依赖 P13 - P14` * 函数依赖是普遍存在的一种数据依赖 * 不合适的函数依赖关系会导致很多问题： * 1.数据冗余 * 2.更新异常 * 3.插入异常 * 4.删除异常 2. `函数依赖 P22 - P26` * 函数依赖和别的数据依赖一样是语义范畴的概念，只能根据语义来确定一个函数依赖。 3. `平凡函数依赖与非平凡函数依赖 P27 - P28` 4. `完全函数依赖与部分函数依赖 P29 - P30` 5. `传递函数依赖 P31` ![image-20230618223115913](https://bangwu.oss-cn-shanghai.aliyuncs.com/img/202306182243473.png) 6. `1NF、2NF、3NF、BCNF的定义以及判断 P41 - P56，P81` **第一范式（1NF）** 定义 > (1NF, Normal Form) 如果一个关系模式R中的每个属性A的域值都是原子的，即属性值是不可再分的，则关系模式R属于第一范式，简记为R ∈ 1NF。若数据库模式R中的每个关系模式都是1NF，数据库模式 R∈1NF。 这个非常好理解，基本上，只要题目给了，他就是一个满足第一范式的关系模式 **第二范式（2NF）** 定义 ![第二范式](https://img-blog.csdnimg.cn/20181125213408784.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0NhbmRsZV9saWdodA==,size_16,color_FFFFFF,t_70) 2NF指的就是，我们的关系模式中的所有非主属性完全依赖于每个键。什么意思呢，这里呢最重要的是理解什么是`非主属性`，什么是`主属性`，什么是`键` 推荐看另外一个博客的总结，理解一下键的含义： [https://blog.csdn.net/fjxcsdn/article/details/76549751](https://blog.csdn.net/fjxcsdn/article/details/76549751) 看我之前写的博客理解完全依赖和部分依赖的含义： [数据库基础（3）函数依赖-平凡依赖，完全依赖，部分依赖，传递依赖](https://blog.csdn.net/Candle_light/article/details/84424505) 那非主属性和主属性怎么理解呢，举个例子：关系模式R=｛A,B,C,D｝ ,已知R的候选键是AD ， 那么AD中的A和D就是主属性，而B和C就是非主属性。**`包含在候选键里的属性就是主属性！`** 现在理解键和依赖关系的含义之后，我们就可以好好看看2NF是个什么了 **`举例子1：`** > #### 已知，R=｛A，B，C｝，函数依赖集为 F = ｛B → C, AC → B｝，判断关系模式是不是 2NF 那么我们**首先**看这个R关系模式里面的键是谁 利用`数据库基础（4）中我们学习的属性闭包算法`求出R的候选键为：AC 所以**第二步** 就是看是否有非主属性部分依赖于主属性AC （我们这里的非主属性就是B） 很明显并没有B部分依赖于A或者C ，所以R是2NF **`举例子2`** > #### 已知，R=｛A，B，C，D｝，函数依赖集为 F = ｛A → C, AD → B｝，判断关系模式是不是 2NF 和第一个例子一样，我们首先看这个R中的键是谁 用属性闭包算法，求出R的候选键为：AD （AD+ = ABCD） ，所以C和B都是非主属性，A和D是主属性 所以，很明显，我们发现 AD中的A竟然可以单独决定C（A->C），所以C部分依赖于AC ，存在非主属性部分依赖于主属性，R不是2NF **第三范式（3NF）** 定义 ![3NF](https://img-blog.csdnimg.cn/20181125213645372.png) 第三范式的意思就是，**R中`没有非主属性传递依赖`于R的键**,R才是3NF 这里也隐含了一个条件，那就是，如果是R中的`主属性传递依赖`于R的键，那么R也是满足3NF的 **注意区分主属性传递依赖和非主属性传递依赖喔** `举例子1` > #### 已知 R(A, B, C)，其函数依赖集为 F = ｛B → C, AC → B｝；该关系模式是否第 3 范式 我们来判断判断，首先第一步，找键！我们发现AC是候选键（AC+=ABC，通过属性闭包算法求的候选键） 同时由于AC->B , B->C ，所以C传递依赖于AC ，那么R是不是3NF呢？ R 当然是3NF啦，因为R的候选键是AC，所以C是主属性，因此 这里是`主属性C`传递依赖于键AC，R是3NF 注意！`只有当非主属性传递依赖于R的时候,R才不是3NF` `举例子2` > #### R(A, B, C, D)，其函数依赖集为 F = ｛AB → C, C → D｝；该关系模式是否第 3 范式 首先第一步，还是找键！ 发现AB是候选键， 但是由于AB -> C , C -> D ，所以D传递依赖于AB 那么R是3NF吗？ R当然不是3NF啦，因为D是非主属性，所以这里是非主属性D传递依赖于主属性AB，因此就不满足3NF的定义啦 **`Boyce-Codd范式（BCNF）`** 定义 ![BCNF](https://img-blog.csdnimg.cn/20181125213719359.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0NhbmRsZV9saWdodA==,size_16,color_FFFFFF,t_70) BCNF最高级了，它指的是R中`没有任何属性传递依赖于R中的任何一个键`。所以联想到上面我们3NF中的举例1，它虽然满足3NF，但是由于有主属性传递依赖于键，它就不是BCNF。 看例题，判断是几范式 ![例题](https://img-blog.csdnimg.cn/20181125213738319.png) 很明显，两个都是BCNF，因为都没有任何属性存在传递依赖 最后说一下，满足BCNF的关系模式，肯定也满足3NF；同理，满足3NF的关系模式，肯定也满足2NF # 七. 数据库设计 1. `数据库设计的概念 1P6` 数据库设计是指对于一个给定的应用环境，构造（设计）优化的数据库逻辑模式和物理结构，并据此建立数据库及其应用系统，使之能够有效地存储和管理数据，满足各种用户的应用需求，包括信息管理系统要求和数据操作要求。 3. `数据库高效率的运行环境 1P7` 数据库数据的存取效率，数据库存储空间的利用率，数据库系统运行管理的效率 4. `数据库设计的特点 1P10 - 1P12` 试探性，反复性，多步性，面向数据 5. `数据库设计的基本步骤 1P18` * 需求设计 * 概念结构设计 * 逻辑结构设计 * 物理结构设计 * 数据库实施 * 数据库运行和维护 6. `数据库设计各个阶段的数据设计描述 1P25` * P 209 7. `需求分析的任务 1P36 - 1P38` 需求分析的任务是通过详细调查现实世界要处理的对象（组织、部门、企业等），充分了解原系统（手工系统或计算机系统）的工作概况，明确用户的各种需求，然后在此基础上确实新系统的功能。调查的重点是“数据”和“处理”，通过调查、收集与分析，获得用户对数据库的如下要求： * 信息要求 * 处理要求 * 安全性与完整性要求 8. `需求分析的方法 1P40` * 调查组织机构的情况 * 调查各部门的业务活动情况 * 在熟悉业务活动的基础上，协助用户明确对新系统的各种要求，包括信息要求，处理要求，安全性与完整性要求 * 确定新系统的边界 常见的调查方法： * 跟班作业 * 开调查会 * 请专人介绍 * 询问 * 设计调查表请用户填写 * 查阅记录 9. `E-R模型的提出者 1P58` * P.P.S.Chen 10. `实体之间联系的类型 1P59 - 1P67` * 两个实体型之间的联系：一对一，一对多，多对多 * 两个以上的实体型之间的联系 * 单个实体型内的联系 11. `E-R图 1P68 - 1P74` 实体用矩形，属性用椭圆形，联系用菱形 12. `实体与属性的划分原则 1P77` 能作为属性对待的尽量作为属性对待 13. `E-R图的集成 1P87 - 1P94` * 合并，解决各分E-R图之间的冲突 * 修改和重构，消除不必要的冗余 * 冲突类型：1.属性冲突，2.命名冲突，3.结构冲突 14. `E-R图向关系模型的转换 2P7 - 2P13` * 一个实体型转换为一个关系模式，关系的属性就是实体的属性，关系的码就是实体的码 15. `优化数据模型的方法 2P19` * 确定数据依赖 * 对于各个关系模式之间的数据依赖进行极小化处理 * 按照数据依赖的理论对关系模式逐一进行分析 * 根据需求分析阶段得到的处理要求分析对于这样的应用环境这些模式是否合适，确定是否要对某些模式进行合并或分解 * 对关系模型进行必要分解，提高数据操作效率和存储空间利用率。常用的两种分解方法是水平分解和垂直分解 16. `数据库物理设计的步骤 2P32` * 为一个给定的逻辑数据模型选取一个最适合应用要求的物理结构的过程，就是数据库的物理设计。 * 1. 确定数据库的物理结构，在关系数据库中主要指存取方法和存储结构 2. 对物理结构进行评价，评价的重点是时间和空间效率 3. 数据库管理系统的常用存取方法 2P39 * 索引方法和聚簇(clustering)方法，B+树索引和hash索引 P236 17. `影响数据存放位置和存储结构的因素 2P53` * 存取时间，存储空间利用率，维护代价，硬件环境，应用需求 # 八. 数据库编程 1. `python关联MySQL的包（Package）是什么 P9` * PyMySQL 2. `游标的好处 P22` * 游标是系统为用户开设的一个数据缓冲区，存放SQL语句的执行结果，每个游标区都有一个名字。 * 用户可以通过游标逐一获取记录并赋给主变量，交由主语言进一步处理。 * 使用游标功能后，我们可以将得到的结果先保存起来，然后可以随意进行自己的编程，得到我们最终想要的结果集。 ```python theme={"theme":{"light":"github-light","dark":"github-dark"}} Cursor = (数据库名).db.cursor ``` 3. `tornado web服务器的四大组件 P62-P63` * ioloop实例，app实例，handler类，路由表 4. `GET和POST的区别 P65` * 传参方式不同：Get把参数包含在URL中，Post通过request body传递参数； * URL可见性不同：get请求的参数可以直接看到，而post请求的参数URL不可见； * 传递数据大小不同：get请求对传递的数据长度受到URL大小的限制，而post请求没有长度限制 * 后退页面影响不同：get后退不会有影响，而post后退会重新进行提交； * 编码方式不同：get请求只支持URL编码，而post请求支持多种编码方式； 5. `SQL 变量的定义 P73 - P76` 在SQL中，变量是一种用于存储数据的容器 6. `流程控制 P80 - P97` * 在存储过程和自定义函数中可以使用流程控制语句来控制程序的流程。 ```sql theme={"theme":{"light":"github-light","dark":"github-dark"}} 流程控制语句： IF 语句； CASE语句； LOOP语句； LEAVE语句； ITERATE语句； REPEAT语句； WHILE语句； ``` 7. `匿名块与命名块 P100` * 匿名块：每次执行时都要进行编译，它不能被存储在数据库中，也不能在其他过程化SQL块中调用； * 命名块：编译后保存在数据库中，称为持久性存储模块，可以被反复调用，运行速度较快，过程和函数时命名块。 8. `存储过程的定义 P102` * 存储过程是一种在数据库中存储复杂程序，以便外部程序调用的一种数据库对象 9. `存储过程的优点 P103` * 远行效率高 * 降低了客户机和服务器之间的通信量 * 方便实施企规则 10. `存储过程的缺点 P104` * 存储过程，往往定制化与特定的数据库上，因为支持的编程语言不同。当切换到其他厂商的数据库系统时，需要重写原有的存储过程 * 存储过程的性能调校与撰写，受限于各种数据库系统 11. `存储过程的SQL代码 P107 - P117` ```sql theme={"theme":{"light":"github-light","dark":"github-dark"}} 创建存储过程：CREATE PROCEDURE （过程名）（参数）（过程化SQL块） 声明语句结束符，可以自定义：DELIMITER $$或DELIMITER// DELIMITER $$ CREATE PROCEDURE delete_sno ( IN p_sno CHAR(9)) BEGIN DELETE FROM Student WHERE sno = p_sno ; END$$ DELIMITER ; 执行存储过程：CALL（过程名）（参数） CALL delete__sno(‘201215122’); 删除存储过程：DROP PROCEDURE（过程名） ``` 12. `函数与存储过程的异同 P119` * 同：都是持久存储模块 * 异：函数必须指定返回的类型 13. `函数的SQL代码 P120 - P122` ```sql theme={"theme":{"light":"github-light","dark":"github-dark"}} 1.定义语句格式：CREATE FUNCTION （函数名）（参数）RETURN（类型）（过程化SQL块） DELIMITER // CREATE FUNCTION func_student ( f_Sno CHAR(9)) RETURNS CHAR(20) DETERMINISTIC COMMENT ’ 查 询 某 个 学 生 的 姓 名 ’ BEGIN RETURN (SELECT Sname FROM Student WHERE Sno = f_Sno ) ; END // DELIMITER ; 2.函数的执行语句格式：SELECT（函数名）（参数） SELECT func_student(‘201215123’); SELECT func_student(sno) FROM Stduent; 3.删除函数：DROP FUNCTION（函数名） ``` # 九. MySQL优化原理 1. `MySQL各组件之间协同工作的逻辑架构 P6 - P9` * 9-MySQL优化原理.pdf 2. `MySQL的查询过程 P12，P38` * 1.客户端/服务端通信协议 * 2.查询缓存 * 3.语法解析和预处理 * 4.查询优化 * 5.查询执行引擎 * 6.返回结果给客户端 # 十. 数据库恢复技术 1. `事务的概念 P7` * 事务是用户定义的一个数据库操作系统序列，这些操作要么全做，要么全不做，是一个不可分割的工作单位； * 事务是数据库恢复和并发控制的基本单位 2. `事务的显示控制 P8 - P9` * 10-数据库恢复技术.pdf 3. `事务的ACID特性 P13 - P19` * 原子性：事务是数据库的逻辑工作单位，要么都做，要么都不做； * 一致性：事务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态； * 隔离性：一个事务的执行不能被其他事务干扰； * 持续性：持续性也称永久性，一个事务一旦提交，它对数据库中数据的改变就应该是永久性的，接下来的其他操作或故障不应该对其执行结果有任何影响 4. `数据库恢复的背景和原因 P21` * 故障是不可避免的： * 1. 计算机硬件故障； 2. 软件的错误； 3. 操作员的失误 4. 恶意的破坏 * 故障的影响： * 1. 运行事务的非正常中断，影响数据库中数据的正确性 2. 破坏数据库，全部或部分丢失数据 5. `数据库恢复的概念 P22` * 数据库恢复：数据库管理必须具有把数据库从错误状态恢复到某一已知的正确状态（亦称为一致状态或完整状态）的功能，这就是数据库的恢复管理系统对故障的对策；恢复子系统是数据库管理系统的一个重要组成部分；恢复技术是衡量系统优劣的重要指标。 6. `故障的种类 P24 - P38` * 事故内部的故障 * 系统故障 * 介质故障 * 计算机病毒 7. `恢复机制的两个关键问题 P40` * 如何建立冗余数据（1.数据转储2.登记日志文件3.两者常常一起使用） * 如何利用这些冗余数据实施数据库恢复 8. `数据转储的概念 P43 - P44` * 数据转储是数据库恢复中采用的基本技术 * 转储是指数据库管理员定期地将整个数据库复制到磁带、磁盘或其他存储介质上保存起来的过程 * 这些备用的数据文本称为后备副本或后援副本 9. `数据转储的方法 P47 - P52` * 静态转储与动态转储 * 海量转储与增量转储 * 转储方法小结（动态海量转储，静态海量转储，动态增量转储，静态增量转储） 10. `日志文件的概念 P55` * 日志文件是用来记录事务与数据库的更新操作的文件 11. `以记录为单位的日志文件内容 P56 - P57` * 各个事务的开始标记 * 各个事务的结束标记 * 各个事务的所有更新操作 * 这里每个事务的开始标记、每个事务的结束标记和每个更新操作均作为日志文件中的一个日志记录 日志记录的内容： 1. 事务标识 2. 操作类型 3. 操作对象 4. 更新前数据的旧值 5. 更新后数据的新值 6. `以数据块为单位的日志文件内容 P58` * 事务标记 * 被更新的数据块 13. `日志文件的作用 P59 - P61` * 进行事务故障恢复 * 进行系统故障恢复 * 协助后备副本进行介质故障恢复 14. `登记日志文件的原则 P63` 15. 登记的次序严格按并发事务执行的时间次序 16. 必须先写日志文件，后写数据库 * (写日志文件操作：把表示这个修改的日志记录写到日志文件中； * 写数据库操作：把对数据的修改写到数据库中； ​ 这就“先写日志文件”的原则) 15. `先写日志文件的原因 P64` * 写数据库和写日志是两个不同的操作 * 在这两个操作之间可能发生故障 * 如果先写了数据库修改，而在日志文件中没有登记下这个修改，则以后就无法恢复这个修改了 * 如果先写日志，但没有修改数据库，按日志文件恢复时只不过是多执行一次不必要的UNDO操作，并不会影响数据库的正确性 * 所以为了安全，一定要先写日志文件，即首先把日志记录写到日志文件中，然后写数据库的修改。 16. `事务故障的恢复方法 P67` * 由恢复子系统利用日志文件撤销（UNDO）此事务已对数据库进行的修改 17. `事务故障恢复的步骤 P68 - P69` * 反向扫描文件日志（即从最后向前扫描日志文件），查找该事务的更新操作 * 对该事务的更新操作执行逆操作。即将日志记录中“更新前的值”写入数据库 * （插入操作：“更新前的值”为空，则相当于做删除操作； * 删除操作：“更新后的值”为空，则相当于做插入操作； * 若是修改操作，则相当于用修改前值代替修改后值） 18. `系统故障的恢复方法 P71` 1. Undo（撤销）故障发生时未完成的事务； 2. Redo（重做）已完成的事务 19. `系统故障的恢复步骤 P72 - P73` 1. 正向扫描日志文件（即从头扫描日志文件），找出在故障发生前已经提交的事务 2. 对撤销（UNDO）队列事务进行撤销（UNDO）处理 3. 对重做（REDO）队列事务进行重做（REDO）处理 20.`介质故障的恢复方法 P75` 1. 重装数据库 2. 重做已完成的事务 3. `介质故障的恢复步骤 P76 - P77` 4. 装入最新的后备数据库副本（离故障发生时刻最近的转储副本），使数据库恢复到最近一次转储时的一致性状态 5. 装入有关的日志文件副本（转储结束时刻的日志文件副本），重做已完成的事务 6. `为什么要具有检查点的恢复技术 P81` 7. 搜索整个日志将耗费大量的时间 8. 很多需要重做处理的事务实际上已经将它们的更新操作结果写到了数据库中，然而恢复子系统又重新执行了这些操作，浪费了大量时间 This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.