forked from SSHeRun/CS-Xmind-Note
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
30 changed files
with
818 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,56 @@ | ||
# 关系代数 | ||
## 概述 | ||
### 关系代数是一种抽象的查询语言,用对关系的运算来表达查询,作为研究关系数据语言的数学工具。 | ||
### 关系代数的运算对象是关系,运算结果亦为关系。 | ||
## 关系代数的运算 | ||
### 普通的集合运算 | ||
* 并、交、差 | ||
### 删除部分关系的运算 | ||
* 选择、投影 | ||
### 合并两个关系元组的运算 | ||
* 连接、积 | ||
### 改名运算 | ||
## 关系代数 | ||
### 并Union (∪) | ||
* R和S的并,R∪S,是在R或S或两者中的元素的集合 | ||
* 一个元素在并集中只出现一次 | ||
* R和S必须同类型(属性集相同、次序相同,但属性名可以不同) | ||
### 交Intersect (∩) | ||
* R和S的交,R∩S,是在R和S中都存在的元素的集合 | ||
* 一个元素在交集中只出现一次 | ||
* R和S必须同类型(属性集相同、次序相同,但属性名可以不同) | ||
### 差Minus (-) | ||
* R和S的差,R-S,是在R中而不在S中的元素的集合 | ||
* R和S必须同类型(属性集相同、次序相同,但属性名可以不同) | ||
### 投影Projection(π) | ||
* 从关系R中选择若干属性组成新的关系 | ||
* πA1,A2,…,An(R),表示从R中选择属性集A1,A2,…,An组成新的关系 | ||
* 列的运算 | ||
* 投影运算的结果中,也要去除可能的重复元组 | ||
### 广义笛卡儿积(×) | ||
* 关系R、S的广义笛卡儿积是两个关系的元组对的集合所组成的新关系 | ||
* R×S: | ||
* 属性是R和S的组合(有重复) | ||
* 元组是R和S所有元组的可能组合 | ||
* 是R、S的无条件连接,使任意两个关系的信息能组合在一起 | ||
### 选择Selection(σ) | ||
* 从关系R中选择符合条件的元组构成新的关系 | ||
* σC(R),表示从R中选择满足条件(使逻辑表达式C为真)的元组 | ||
* 行的运算 | ||
### 条件连接(θ) | ||
* 从R×S的结果集中,选取在指定的属性集上满足AθB条件的元组,组成新的关系 | ||
* θ是一个关于属性集的比较运算符 | ||
* θ为“=”的连接运算称为等值连接。 | ||
### 自然连接 | ||
* 从R×S的结果集中,选取在某些公共属性上具有相同值的元组,组成新的关系 | ||
* R、S的公共属性 | ||
* 属性集的交集(名称及类型相同) | ||
* 公共属性在结果中只出现一次 | ||
* 等值连接 | ||
### 关系代数—除( ÷ ) | ||
* 给定关系R(X,Y)和S(Y,Z),其中X, Y, Z为属性组。R中的Y与S中的Y可以有不同的属性名,但必须出自相同的域集。R与S的除运算得到一个新的关系P(X),P是R中满足下列条件的元组在X属性列上的投影:元组在X上分量值x的象集Yx包含S在Y上投影的集合。 | ||
* R÷S = {tr[X]| tr∈R∧πy (S)Yx} | ||
* 其中Yx为x在R中的象集,x=tr[X]。 | ||
* 例子 | ||
## 总图 | ||
*XMind: ZEN - Trial Version* |
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file not shown.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,86 @@ | ||
# 关系数据库设计理论 | ||
## 设计一个好的关系数据库系统,关键是要设计一个好的数据库模式(数据库逻辑设计问题) | ||
## 数据库逻辑设计主要解决的问题 | ||
### 关系数据库应该组织成几个关系模式 | ||
### 关系模式中包括哪些属性 | ||
## “不好”的数据库设计 | ||
### 举例:为学校设计一个关系数据库 | ||
### 关系模式: UN(Sno,Cno,G,Sdept,MN) | ||
* Sno:描述学生 | ||
* Sdept:描述系名 | ||
* MN:描述系主任 | ||
* Cno:描述课程 | ||
* G:描述学习成绩 | ||
* 根据对现实世界的分析,可得出:Sno,Cno是码 | ||
* 按照关系模式UN装入部分数据 | ||
### | ||
### 对数据库操作时,会出现以下问题 | ||
* 1. 数据冗余(系主任名的存储次数) | ||
* 数据重复存储:浪费存储空间,数据库维护困难(更新异常) | ||
* 2. 插入异常(一个系刚成立) | ||
* 主码为空的记录不能存在与数据库,导致不能进行插入操作 | ||
* 3. 删除异常(一个系的学生全部毕业) | ||
* 删除操作后,一些相关信息无法保存在数据库中 | ||
### 要消除以上的“弊病”,把上面的关系数据库模式分解为三个关系模式 | ||
* S(Sno,Sdept) | ||
* SG(Sno,Cno,G) | ||
* Dept(Sdept,MN) | ||
## 函数依赖 | ||
### 类似于变量之间的单值函数关系 | ||
### Y=F(X),其中自变量X的值,决定一个唯一的函数值Y | ||
### 在一个关系模式里的属性,由于它在不同元组里属性值可能不同,由此可以把关系中的属性看作变量 | ||
### 一个属性与另一个属性在取值上可能存在制约关系 | ||
### 函数依赖就是属性间的逻辑依赖关系 | ||
### 定义1 设R(U)是一个关系模式,U是R的属性集合,X和Y是U的子集.对于R(U)的任何一个可能的关系r,如果r中不存在两个元组,它们在X上的属性值相同,而在Y上的属性值不同,则称X函数决定Y,或Y函数依赖于X,记作:X Y. | ||
### X通常称为“决定因素” | ||
### 几点说明 | ||
* 1. 函数依赖是语义范畴的概念.它反映了一种语义完整性约束,只能根据语义来确定一个函数依赖. | ||
* 2. 函数依赖是指关系R模式的所有关系元组均应满足的约束条件,而不是关系模式中的某个或某些元组满足的约束条件 | ||
* 3. 函数依赖与属性间的联系类型有关 | ||
* (1)若属性X和Y之间有“一对一”的联系, | ||
* (2)若属性X和Y之间有“多对一”的联系, | ||
* (3)若属性X和Y之间有“多对多”的联系, | ||
* 4. 如果X Y,并且Y不是X的子集,则称X Y是非平凡的函数依赖;如果Y是X的子集,则称X Y是平凡的函数依赖; | ||
## 完全函数依赖与部分函数依赖 | ||
### 完全函数依赖 | ||
### 部分函数依赖 | ||
## 码的形式定义 | ||
### 候选码的两个性质 | ||
* 1. 标识的唯一性: 对于R(U)中的每一元组,K的值确定后,该元组就相应确定了. | ||
* 2. 无冗余性: K是属性组的情况下,K的任何一部分都不能唯一标识该元组(定义中的完全函数依赖的意义) | ||
## 规范化 | ||
### 简介 | ||
* 用几个简单的关系去取代原来结构复杂的关系的过程叫做关系规范化. | ||
* 规范化理论是研究如何把一个不好的关系模式转化为好的关系模式的理论 | ||
* 规范化理论是E.E.Codd在1971年首先提出的 | ||
* 规范化理论是数据库设计过程中的一个非常有用的辅助工具 | ||
### 范式 | ||
* 简介 | ||
* 规范化理论是围绕着范式建立的. | ||
* 满足不同程度要求的约束集则称为不同的范式. | ||
* 如果一个关系满足某个指定的约束集,则称它属于某个特定的范式. | ||
* 较高层次的范式比较低层次的范式具有“更合乎要求的性质” | ||
* 一个低一级范式的关系模式,通过投影运算可以转化为若干个高一级范式的关系模式的集合,这个过程叫做规范化. | ||
* 如果一个关系满足某个范式要求,则它也会满足较其级别低的所有范式的要求 | ||
* 范式层次 | ||
* 第一范式(1NF) | ||
* 定义5: 在关系模式R中的每一个具体关系r中,如果每个属性值都是不可再分的最小数据单位,则称R是第一范式的关系,记作R∈1NF. | ||
* 数据库理论研究的是规范化关系. | ||
* 1NF规范化: 把非规范化关系规范提高到1NF关系模式的集合. | ||
* 第二范式(2NF) | ||
* 定义6: 若关系模式R∈1NF,且每个非主属性都完全依赖于R的任意候选码,则关系模式R属于第二范式,记作R ∈2NF. | ||
* 2NF规范化是把1NF关系模式规范提高到变成2NF关系模式的集合. | ||
* 从1NF中消除非主属性对候选码的部分函数依赖,则获得2NF关系. | ||
* 举例:UN(Sno,Cno,G,SDN,MN) | ||
* 第三范式(3NF) | ||
* 定义7: 若关系模式R∈2NF,且每个非主属性都不传递依赖于R的任意候选码,则R∈3NF. | ||
* 从2NF关系中,消除非主属性对码的传递依赖函数而获得3NF关系 | ||
* R∈3NF,则每个非主属性既不部分依赖,也不传递依赖于R的任何候选码. | ||
* 3NF的规范化 | ||
* BCNF范式 | ||
* 3NF的不完善性 | ||
* 定义8: 若R∈1NF,且R中每个决定因素都是候选码,则R ∈BCNF. | ||
* 满足BCNF的关系将消除任何属性对候选码的部分依赖与传递依赖 | ||
* 应用BCNF定义时,可直接判断1NF是否属于BCNF | ||
* BCNF规范化 | ||
*XMind: ZEN - Trial Version* |
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file not shown.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,38 @@ | ||
# 关系模型 | ||
## 关系模型组成的三要素 | ||
### 关系数据结构 | ||
* 基本概念 | ||
* 关系 | ||
* 关系模式 | ||
* 什么是关系模式 | ||
* 关系模式(Relation Schema)是型 | ||
* 关系是值 | ||
* 关系模式是对关系的描述 | ||
* 关系数据库 | ||
### 关系操作集合 | ||
### 关系完整性约束 | ||
* 关系模型的完整性规则是对关系的某种约束条件 | ||
* 实体完整性和参照完整性是关系模型必须满足的完整性约束条件,被称作是关系的两个不变性,应该由关系系统自动支持。 | ||
## 基本关系的六大性质 | ||
### ① 列是同质的(Homogeneous) | ||
* 每一列中的分量是同一类型的数据,来自同一个域 | ||
### ② 不同的列可出自同一个域 | ||
* 其中的每一列称为一个属性 | ||
* 不同的属性要给予不同的属性名 | ||
### ③ 列的顺序无所谓 | ||
* 列的次序可以任意交换 | ||
* 遵循这一性质的数据库产品(如ORACLE),增加新属性时,永远是插至最后一列。但也有许多关系数据库产品没有遵循这一性质,例如FoxPro仍然区分了属性顺序 | ||
### ④ 任意两个元组的候选码不能完全相同 | ||
* 候选码是可以惟一标识一个元组的属性或属性组。若一个关系中的候选码有多个,则选择一个作为主码 | ||
### ⑤ 行的顺序无所谓 | ||
* 行的次序可以任意交换 | ||
* 遵循这一性质的数据库产品(如ORACLE),插入一个元组时永远插至最后一行。但也有许多关系数据库产品没有遵循这一性质,例如FoxPro仍然区分了元组的顺序 | ||
|
||
### ⑥ 分量必须取原子值 | ||
* 每一个分量都必须是不可分的数据项。 | ||
## 关系模型中的三类完整性约束 | ||
### 实体完整性 | ||
### 参照完整性 | ||
* 外码(Foreign Key) | ||
### 用户定义的完整性 | ||
*XMind: ZEN - Trial Version* |
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file not shown.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,19 @@ | ||
# 完整性约束 | ||
## 静态列级约束 | ||
### 1. 对数据类型的约束,包括数据的类型、长度单位、精度等 | ||
### 2. 对数据格式的约束 | ||
### 3. 对取值范围或取值集合的约束 | ||
### 4. 对空值的约束 | ||
### 5. 其他约束 | ||
## 静态元组约束 | ||
### 一个元组是由若干个列值组成的,静态元组约束就是规定元组的各个列之间的约束关系 | ||
## 静态关系约束 | ||
### 在一个关系的各个元组之间或者若干关系之间常常存在各种联系或约束。 (参照完整性-外码约束) | ||
## 动态列级约束 | ||
### 1. 修改列定义时的约束 | ||
### 2. 修改列值时的约束 | ||
## 动态元组约束 | ||
### 动态元组约束是指修改元组的值时元组中各个字段间需要满足某种约束条件 | ||
## 动态关系约束 | ||
### 动态关系约束是加在关系变化前后状态上的限制条件,例如事务一致性、原子性等约束条件 | ||
*XMind: ZEN - Trial Version* |
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file not shown.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,61 @@ | ||
# 并发控制 | ||
## 多事务执行方式 | ||
### (1)事务串行执行 | ||
* 每个时刻只有一个事务运行,其他事务必须等到这个事务结束以后方能运行 | ||
* 不能充分利用系统资源,发挥数据库共享资源的特点 | ||
### (2)交叉并发方式(interleaved concurrency) | ||
* 事务的并行执行是这些并行事务的并行操作轮流交叉运行 | ||
* 是单处理机系统中的并发方式,能够减少处理机的空闲时间,提高系统的效率 | ||
### (3)同时并发方式(simultaneous concurrency) | ||
* 多处理机系统中,每个处理机可以运行一个事务,多个处理机可以同时运行多个事务,实现多个事务真正的并行运行 | ||
* 最理想的并发方式,但受制于硬件环境 | ||
* 更复杂的并发方式机制 | ||
## 事务并发执行带来的问题 | ||
### 可能会存取和存储不正确的数据,破坏事务的隔离性和数据库的一致性 | ||
### DBMS必须提供并发控制机制 | ||
### 并发控制机制是衡量一个DBMS性能的重要标志之一 | ||
## 并发控制机制的任务 | ||
### 对并发操作进行正确调度 | ||
### 保证事务的隔离性 | ||
### 保证数据库的一致性 | ||
## 并发操作带来的数据不一致性 | ||
### 丢失修改(lost update) | ||
* 丢失修改是指事务1与事务2从数据库中读入同一数据并修改 | ||
* 事务2的提交结果破坏了事务1提交的结果,导致事务1的修改被丢失。 | ||
### 不可重复读(non-repeatable read) | ||
* 不可重复读是指事务1读取数据后,事务2执行更新操作,使事务1无法再现前一次读取结果。 | ||
### 读“脏”数据(dirty read) | ||
* 事务1修改某一数据,并将其写回磁盘 | ||
* 事务2读取同一数据后 | ||
* 事务1由于某种原因被撤消,这时事务1已修改过的数据恢复原值 | ||
* 事务2读到的数据就与数据库中的数据不一致, | ||
* 是不正确的数据,又称为“脏”数据。 | ||
## 封锁 | ||
### 什么是封锁 | ||
* 封锁就是事务T在对某个数据对象(例如表、记录等)操作之前,先向系统发出请求,对其加锁 | ||
* 加锁后事务T就对该数据对象有了一定的控制,在事务T释放它的锁之前,其它的事务不能更新此数据对象。 | ||
* 封锁是实现并发控制的一个非常重要的技术 | ||
### 基本封锁类型 | ||
* 排它锁(eXclusive lock,简记为X锁) | ||
* 排它锁又称为写锁 | ||
* 若事务T对数据对象A加上X锁,则只允许T读取和修改A,其它任何事务都不能再对A加任何类型的锁,直到T释放A上的锁 | ||
* 共享锁(Share lock,简记为S锁) | ||
* 共享锁又称为读锁 | ||
* 若事务T对数据对象A加上S锁,则其它事务只能再对A加S锁,而不能加X锁,直到T释放A上的S锁 | ||
### 基本锁的相容矩阵 | ||
### 封锁协议 | ||
* 1级封锁协议 | ||
* 事务T在修改数据R之前必须先对其加X锁,直到事务结束才释放 | ||
* 1级封锁协议可防止丢失修改 | ||
* 在1级封锁协议中,如果是读数据,不需要加锁的,所以它不能保证可重复读和不读“脏”数据。 | ||
* 读“脏”数据 | ||
* 不可重复读 | ||
* 2级封锁协议 | ||
* 1级封锁协议+事务T在读取数据R前必须先加S锁,读完后即可释放S锁 | ||
* 2级封锁协议可以防止丢失修改和读“脏”数据。 | ||
* 在2级封锁协议中,由于读完数据后即可释放S锁,所以它不能保证可重复读。 | ||
* 3级封锁协议 | ||
* 1级封锁协议 + 事务T在读取数据R之前必须先对其加S锁,直到事务结束才释放 | ||
* 3级封锁协议可防止丢失修改、读脏数据和不可重复读。 | ||
* 三级协议的主要区别 | ||
*XMind: ZEN - Trial Version* |
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file not shown.
Binary file not shown.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,57 @@ | ||
# 数据库恢复技术 | ||
## 什么是事务 | ||
### 事务(Transaction)是用户定义的一个数据库操作序列,这些操作要么全做,要么全不做,是一个不可分割的工作单位 | ||
### 事务和程序是两个概念 | ||
* 在关系数据库中,一个事务可以是一条SQL语句,一组SQL语句或整个程序 | ||
* 一个应用程序通常包含多个事务 | ||
### 事务是恢复和并发控制的基本单位 | ||
## 事务结束 | ||
### COMMIT | ||
* 事务正常结束 | ||
* 提交事务的所有操作(读+更新) | ||
* 事务中所有对数据库的更新永久生效 | ||
### ROLLBACK | ||
* 事务异常终止 | ||
* 事务运行的过程中发生了故障,不能继续执行 | ||
* 回滚事务的所有更新操作 | ||
* 事务滚回到开始时的状态 | ||
## 事务的特性(ACID特性) | ||
### 原子性(Atomicity) | ||
* 事务是数据库的逻辑工作单位 | ||
* 事务中包括的诸操作要么都做,要么都不做 | ||
### 一致性(Consistency) | ||
* 事务执行的结果必须是使数据库从一个 一致性状态变到另一个一致性状态 | ||
* 一致性状态: | ||
* 数据库中只包含成功事务提交的结果 | ||
* 不一致状态: | ||
* 数据库中包含失败事务的结果 | ||
### 隔离性(Isolation) | ||
* 对并发执行而言一个事务的执行不能被其他事务干扰 | ||
|
||
* 一个事务内部的操作及使用的数据对其他并发事务是隔离的 | ||
* 并发执行的各个事务之间不能互相干扰 | ||
### 持续性(Durability ) | ||
* 持续性也称永久性(Permanence) | ||
* 一个事务一旦提交,它对数据库中数据的改变就应该是永久性的。 | ||
* 接下来的其他操作或故障不应该对其执行结果有任何影响。 | ||
## 故障 | ||
### 故障原因 | ||
* 计算机硬件故障 | ||
* 系统软件和应用软件的错误 | ||
* 操作员的失误 | ||
* 恶意的破坏 | ||
### 故障的影响 | ||
* 运行事务非正常中断 | ||
* 破坏数据库 | ||
### 故障的种类 | ||
* 事务故障 | ||
* 系统故障 | ||
* 介质故障 | ||
* 计算机病毒 | ||
## 恢复操作的基本原理 | ||
### 恢复操作的基本原理:冗余 | ||
### 利用存储在系统其它地方的冗余数据来重建数据库中已被破坏或不正确的那部分数据 | ||
## 恢复的实现技术 | ||
### 数据转储(backup) | ||
### 登录日志文件(logging) | ||
*XMind: ZEN - Trial Version* |
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file not shown.
Oops, something went wrong.