一、概述
1. 数据
数据:完整性(不包含任何冗余信息)、可共享
2. 数据库
数据库:相关数据的集合
2.1 模式
- 模式(逻辑模式):数据库中全体数据的逻辑结构和特征的描述
- 外模式(视图层):数据库用户使用的局部数据的逻辑结构和特征描述
- 内模式(物理层):数据物理结构和存储方式的描述
3. 数据库管理系统
数据库管理系统:为用户提供访问数据库的方法
功能:
- 数据定义:利用DDL方便的对数据对象定义
- 数据操作:利用DML实现对数据库的基本操作,如增删改查
- 数据库运行管理:利用DBMS统一管理,确保数据的安全性、完整性、并发问题以及故障修复
- 数据库建立和维护:初始数据的录入、转换功能、恢复功能、分析功能等
4. 数据库系统
数据库系统:由数据、数据库、数据库管理系统、硬件、软件和用户组成
(
硬件:主存和辅存
软件:操作系统、数据库管理系统(mysql等)、其他软件
用户:终端用户(使用者)、应用程序员、数据库管理员
)
二、关系模型
1. 概念
关系:数据结构
关系表:存储关系的表,逻辑结构,是一个二维表
元组:关系表中的一行
属性:关系表中的列(标题)
属性值:属性对应列中的值
域:属性值的取值范围
超码:部分属性的集合,根据这些属性,可以区分任意两个元组
候选码:最小的超码(包含的属性个数最少)
主码:从候选码中选出的一个码
外码:当一个表的某一个属性,引用到另外一个表的主码
关系模式(Relation Schema)是对关系的描述,它可以形式化地表示为:R(U,D,dom,F)。
其中R为关系名,U为组成该关系的属性名集合,D为属性组U中属性所来自的域,dom为属性向域的映象集合,F为属性间数据的依赖关系集合。
通常简记为:R(U)或R(A1,A2,…,An)其中R为关系名,U为属性名集合,A1,A2,…,An为各属性名。
关系完整性:
- 实体完整性:每个关系应该有一个主码(可唯一标识表中的一条记录),每个元组的主码值惟一确定该元组
主码的任何属性都不能取空值 - 参照完整性:实现这种引用规则(一对一,多对多),要求外码的取值只是被参照表主码的值或者取空值
- 用户定义完整性:对某一具体应用的数据必须满足的语义要求。如列值非空,列值唯一,列值必须大于10
2. 关系代数基本操作
2.1 选择
σ expression(table)
expression 是命题演算,可以包含与或非、大于小于等于…
作用是筛选出table中满足expression的元组
2.2 投影
π attribute(table)
attribute是一些属性的集合
作用是筛选出table中属性属于attribute的列组成一个新的表(并删除重复元组)
2.3 并
r∪s
将r中元组和s中元组组成一个新的表(并删除重复元组),要求r和s列数相同,且域兼容
2.4 集合差
r-s
将r中元组中存在s中的部分删除,要求r和s列数相同,且域兼容
2.5 笛卡尔积
r×s
将r中的每一个元组和s中的每一个元组进行拼接,将所得的所有元组组成新的表
2.6 重命名
ρ name(n1,n2,…)(E)
将表E的名称重命名为name,并将其属性重命名为n1,n2…
(n1,n2,…)可以不写,即不重命名属性
2.7 交
r∩s
将r中元组和s中元组中共有的元组组成一个新的表,要求r和s列数相同,且域兼容
2.8 自然连接
r⋈s
比较r和s中共有的属性,对于s中的每个元组,如果r中某一个元组和s中的这个元组在这些共有属性上的值相同,那么将s中的这个元组的其他值,拼接在r中这个元组后,得到一个新的元组。将所有这些新元组组合起来得到一个新表
2.9 外连接
r⋈s
将自然连接中没有成功匹配的元组加入到新表,并给新表中没有的值用NULL代替
左外连接:只保留r中没有匹配的元组
右外连接:只保留s中没有匹配的元组
2.10 除法
r÷s
其中:
r=(A1…Am,B1…Bn)
s=(B1…Bn)
查找r中所有元组,对于s中每一个元组(bi1…bin),r中都存在(ai1…aim,bi1…bin)这样一个元组,那么将(ai1…aim)加入到新表中
三、SQL
1. 基于表操作
1.1 创建表
1 | create table table_name( |
1.2 撤销表
1 | drop table table_name |
1.3 修改表
1 | alter table table_name add data_name data_type; //添加字段 |
1.4 表运算
1 | r union s; //交 |
1.5 视图操作
视图是一个虚拟表,其内容由查询定义。同真实的表一样,视图包含一系列带有名称的列和行数据。但是,数据库中只存放了视图的定义,而并没有存放视图中的数据,这些数据存放在原来的表中。使用视图查询数据时,数据库系统会从原来的表中取出对应的数据。因此,视图中的数据是依赖于原来的表中的数据的。一旦表中的数据发生改变,显示在视图中的数据也会发生改变。同样对视图的更新,会影响到原来表的数据。视图可以用于简化查询,不用每次输入复杂的查询语句。视图是从不同的角度看待数据
1 | create view view_name(A1,...An) as(expression) |
1.6 索引
索引:用来查找记录的属性的集合
索引文件:索引+指针的形式
有序索引:有严格的顺序
哈希索引:乱序
主索引
副索引:找满足一定条件的值
稠密索引:包含了所有的属性值,如id有1234,索引包含了1234
稀疏索引:包含了部分的属性值,如id有1234,索引只包含14
B-树索引
创建索引
1 | create index index_name on table_name(table_attribute) |
删除索引
1 | drop index index_name on table_name |
经常更新、数据少、分布平均、大量重复的表不适合添加索引
经常用于查询、需要排列、唯一性的属性适合做索引
2. 基于数据库操作
1.1 查询操作
1 | //基本语句 |
select语句解析顺序:
- from
- where
- group by /having
- select
- order by
where的逻辑运算:
逻辑值:true false unknown
除了 unknown or true=true,
unknown and false=false,
其余unknown参与的逻辑运算都是unknown
r and s; //与
r or s; //或
not //非
1.2 插入操作
1 | insert into table_name |
1.3 更新操作
1 | update table_name |
1.4 删除操作
1 | delete from table_name |
3. 授权操作
授权类型(基于数据库):
- 查询
- 插入
- 修改
- 删除
授权类型(基于表): - 索引:允许添加删除索引
- 资源:允许创建新的表
- 更改:修改已存在的表结构
- 删除:删除表
赋予权限grant <privilegde> on <tablel_name or view_mame> to <user_list>
收回权限revoke <privilegde> on <tablel_name or view_mame> from <user_list or all>
创建角色create role <name>
继承grant <role_name> to <role_name or user_name>
4. 函数操作
1 | create function fun_name(parameter_list) |
5. 过程操作
1 | create procedure |
理解:过程和函数的区别,函数用于返回特定的数据,而过程用于执行特定的任务,如插入删除
6. 触发器操作
1 | create trigger tri_name |
四、事物和并发控制
1. 事物
数据库事务(Database Transaction)是指对数据库的一系列操作组成的逻辑工作单元。
1.1 事物特性
并非任意的数据库操作序列都是数据库事务。数据库管理系统(DBMS)在写入或更新资料的过程中,为保证交易(Transaction)正确可靠,必须具备四个特性,这四个特性通常称为 ACID 特性。
- 原子性(Atomicity)
事务作为一个整体被执行,包含在其中的对数据库的操作要么全部被执行,要么都不执行。 - 一致性(Consistency)
一致性确保事务将数据库从一种一致的状态转换为另一种一致的状态。换句话说,事务在执行前后,数据库必须满足一些预定义的一致性规则,如约束、触发器、级联等。如果事务执行后数据库不满足这些规则,整个事务将被回滚。
(不一致性一定是存在的,但数据库需要保证不一致状态只能在事物执行当中存在) - 隔离性(Isolation)
多个事务并发执行时,一个事务的执行不应影响其他事务的执行。 - 持久性(Durability)
已被提交的事务对数据库的修改应该永久保存在数据库中。
(一致性级别:
- 强一致性:要求对系统数据的修改可以立刻读取,用户体验性最好。
- 弱一致性:不保证什么时候能达到一致性,但是尽可能保证在某个时间级别后,数据达到一致性
- 最终一致性:弱一致性的一个特例,系统会保证在一定时间内,能够达到一个数据一致的状态。
)
1.2 状态
- 活动:开始执行就处于的状态
- 部分提交:所有指令执行完的状态
- 失败:指令不能正常执行时的状态
- 终止:回滚恢复到事物的初始状态
- 事务提交:事物执行完之后的状态
- 终结:包含终止状态和事务提交状态
状态跳转关系图:
1 | 部分提交 → 事务提交 |
2. 并发控制
目标是解决并发冲突,使并发执行过程等价于某个串行执行过程
2.1 锁
排他锁(X锁):拿到排他锁,能够对事物进行读写操作,其它事物不能进行任何操作。X锁和任何锁互斥
共享锁(S锁):拿到共享锁,可以对事物进行读操作,其他事物只能读不能写。S锁和S锁可以共存
申请锁,如果该锁和其它事物保持的锁相容,才能获得锁,否则就等待,直到互斥的锁被释放
存在问题:
死锁:互相等待对方释放锁
饿死:一直等待
解决方法:
锁协议:
两阶锁协议:
- 增长阶段:允许事物申请锁,不允许释放。在对任何数据进行读写前,要申请锁
- 消减阶段:允许事物释放锁,不允许申请。在事物执行完后才允许释放锁,且不允许再申请锁
两阶段协议会出现死锁
2.2 时间戳
对于每一个事物都赋予一个唯一的时间戳。时间戳越大执行顺序越靠后。W-t(Q)记录了成功执行write(Q)的事物的最大的时间戳,R-t(Q)同理。
例:当事物T要write时,比较W-t(Q),如果比它小,则T试图写的值已经过时,拒绝写,并将T回滚
3. 日志
3.1 WAL
WAL预写日志:修改并不直接写入到数据库文件中,而是写入到另外一个称为 WAL 的文件中;如果事务失败,WAL 中的记录会被忽略,撤销修改;如果事务成功,它将在随后的某个时间被写回到数据库文件中,提交修改。WAL包括了redo和undo信息
3.2 undo和redo
Redo Log(重做日志):为了系统崩溃之后恢复数据用的,让数据库照着日志,把没做好的事情重做一遍。保证了事物的持久性
Undo Log(回滚日志):为了回滚用的。保证了事物的原子性和一致性
更新数据时,把我要改的东西记录在日志里,我再根据日志统一写到磁盘中,万一我在写入磁盘的过程中系统崩溃了,等系统恢复,我先查看日志的完整性。
如果日志是完整的,里面有Commit Record,我就照着日志重新做一遍,最后也能成功。如果日志是不完整的,里面没有Commit Record,我就回滚整个事务,什么都不做。
这个日志就叫做 Redo Log,也就是“重做日志”,中途崩溃的数据库,根据这个日志把事务重做一遍。
Undo Log
五、数据库设计
1. E-R图设计数据库
1.1 概念设计
将需求分析得到的用户需求抽象为信息结构(即概念模型)的过程就是概念结构设计。
以下介绍使用E-R图设计概念模型
1.1.1 E-R图概念
E-R图包括:实体、属性、联系
实体
实体是某个特定的对象,其属性区别于其它实体。如学生、教室,也可以是事件如教学
弱实体:依赖于另一个实体的实体,没有另一个实体,就没有该实体
属性
属性是依附于实体的特征。如姓名、电话
属性分类:
- 单一属性和组合属性:组合属性,由其它属性组合而来,如姓+名组合出姓名
- 单值属性和多值属性:多值属性,一个实体可以有多个该属性的值,如一个人可以有多个电话
- 派生属性:可以由其它属性计算而来
联系
联系可以用于表示以下内容:
- 隶属:如员工隶属于部门
- 事件:由多个实体参与的事件。如教师、学生、课程构成事件上课
联系分类:
按参与的多寡分
- 一对一联系:A实体集中一个实体最多与B实体集中一个实体产生联系;B实体集中一个实体最多与A实体集中一个实体产生联系
- 一对多联系:A实体集中一个实体可以与B实体集中多个实体产生联系;B实体集中一个实体最多与A实体集中一个实体产生联系
- 多对多联系:A实体集中一个实体可以与B实体集中多个实体产生联系;B实体集中一个实体可以与A实体集中多个实体产生联系
按实体参与的级别分
6. 完全参与:实体集中的每个实体都参与联系
7. 部分参与:实体集中仅有部分实体参与联系
1.1.2 E-R图绘制
实体:用矩形表示
弱实体:用同心矩形表示
属性:用椭圆表示
多值属性:用同心椭圆表示
派生属性:用虚线椭圆表示
联系:用菱形表示
单一联系:连线上标注1
多联系:连线上标注 *
1.1.3 E-R图原则
- 属性没法产生联系,要想产生联系,需要将属性变为实体
- 某实体的属性不能是别的实体的属性,解决方法:1. 引入弱实体 2.将实体改为联系
- 联系也可以参与联系
1.2 逻辑设计
逻辑设计将E-R图转换为多个关系模式,每一个实体、联系就是一个模式,它们的属性、联系构成了模式的内容
1.2.1 实体
实体:代表一个关系模式
弱实体:其主码和其依赖的实体的主码构成它的主码,其另外的属性为其自身的属性
1.2.2 属性
属性:构成模式的属性集合
组合属性:被其组合项替代作为模式的属性
多值属性:独立构成一个关系模式,其所属的实体的主码作为其外码,其另外的属性为其自身代表的属性
派生属性:不在关系中体现
1.2.3 联系
多对多联系:该联系单独成关系表,把构成联系的实体的主码作为该联系的外码,其另外的属性为其自身的属性
一对多联系和多对一联系:将一的那一方的主码作为多的那一方的外码
一对一联系:可以采用一对多、多对一和多对多模式
2. 规范化设计数据库
数据库存在问题:
- 数据冗余:一个实体或联系不能只用一行来表达
- 修改异常:实体发生一次改变,数据库要修改多行
- 删除异常:删除某些行时,被迫把其它信息删除了。如表(老师,课程),有数据(A,俄语),A辞职了,删除该数据,数据库中俄语这门课程的信息也没有了
- 插入异常:想要插入一个信息,但是被迫的插入了一些没有的信息。如表(老师,课程),想添加俄语课程,但是还没有老师教学,老师对应的值就是空值
2.1 函数依赖
函数依赖:在关系模式r上,对于任意元组t1、t2,如果在a属性上有t1(a)=t2(a)可得在b属性上t1(b)=t2(b),那么函数依赖a决定b在r上成立
阿姆斯特朗公理:
- 包含规则:若y属于x,那么函数依赖x决定y
- 传递规则:若x决定y,y决定z,那么x决定z
- 增广规则:若x决定y,那么xz决定yz
- 合并规则(推论):若x决定y,x决定z,那么x决定yz
- 分解规则(推论):若x决定yz,x决定y,那么x决定z
2.2 函数依赖集的闭包
由已知的函数依赖集可以推出的所有函数依赖
2.3 属性集的闭包
由该属性集中的属性根据某个函数依赖集能决定的所有属性
初始令属性集=原属性集,遍历属性集的每个属性,查询函数依赖集,利用阿姆斯特朗公理,若能决定某个属性,加入属性集。不断循环,直到属性集没有新属性加入
判断函数依赖集是否可以推出x决定y成立,只需要判断,x在该函数依赖集上的属性集的闭包是否包含y,如果包含则成立,否则不成立
2.4 函数依赖集的覆盖
函数依赖集F可以推出G,那么F覆盖G(F的闭包包含G)
2.5 函数依赖集等价
F和G相互覆盖,则F和G等价
2.6函数依赖集冗余
函数依赖集的某些依赖可以被其它依赖集覆盖,或依赖的左右部分有多余
例:
一般冗余:{A->B,B->C,A->C},A->C多余
右手冗余:{A->B,B->C,A->CD}改为{A->B,B->C,A->D}
左手冗余:{A->B,B->C,AC->D}改为{A->B,B->C,A->D}
2.7 函数依赖集的最小等价覆盖
函数依赖集的最小等价覆盖,没有多余的依赖、多余的左右部分
求解步骤:
- 除去右手冗余:将某个依赖分解为多个依赖,并除去重复依赖
- 除去一般冗余:对于A->B,若将其从函数依赖集删除,新的函数依赖集和原来的函数依赖集等价,那么可以做该删除
- 除去左手冗余:对于α->B,若用α-A->B替换,新的函数依赖集和原来的函数依赖集等价,那么可以做该替换
2.8 函数依赖集的正则覆盖
函数依赖集F的正则覆盖是这样一个函数依赖集G,F和G等价,且G中没有相同的左部
构造方法:
计算函数依赖集的最小等价覆盖,然后将其中左部相同的依赖合并
2.9 候选码
候选码是这样一个属性集合,它是最小的能够决定r上的所有属性的集合
主属性:
候选码中的属性
构造方法:
- 将只出现在函数依赖中左边的属性,和未出现在函数依赖中的属性合并到一起加入候选码集合G
- 遍历剩余属性Y,取出单个属性Yi,计算GYi的闭包,如果等于全属性集合,则将记录Yi,并从Y中去除,如果不等于继续。
- 遍历剩余属性Y,取出两个属性Yii,计算GYii的闭包,如果等于全属性集合,记录Yii,并从Y中去除,如果不等于继续。
- …
- 取出Y中所有属性,计算(Y+G)的闭包,如果等于全属性集合,则记录GY,如果不等于结束。
- 将所有记录的属性加入到G
2.10 多值依赖
多值依赖:设R(U)是一个属性集U上的一个关系模式, X、 Y和Z是U的子集,并且Z=U-X-Y。关系模式R(U)中多值依赖 X→→Y成立,当且仅当对R(U)的任一关系r,给定的一对(x,z)值,有一组Y的值,这组值仅仅决定于x值而与z值无关
判断方法:对于任意关系中,如果存在两个元组(就是行),记为A,B,如果他们的某一属性X的值相等,那么我们交换它们另外的属性Y的值后,得到的新的两个元组,在表中是可以在原来的表中找到与它们相匹配的元组的。
2.10.1 平凡多值依赖
若多值依赖X->->Y,X交Y=R,则该多值依赖是平凡的
2.11 范式
2.11.1 一范式
属性都为原子性的关系集合都在一范式中
原子性:
- 没有组合属性
- 每个属性作为整体处理,而不是从中提取子串
- 一个元组中属性值只能取 一个值
2.11.2 二范式
没有非主属性部分依赖于候选码(非主属性不依赖于候选码的部分,如AB->C,C不会依赖于A,也不会依赖于B)
2.11.3 三范式
没有非主属性对码的传递依赖(如非主属性C,D,若存在C->D则就是存在传递依赖)
2.11.4 BC范式
函数依赖集中,所有左部都是超码(候选码连接其它属性)
2.11.1 四范式
不存在非平凡且非函数依赖的多值依赖
2.12 模式分解
将R<U,F>分解为多个Ri<Ui,Fi>
其中每个Ui都是U的子集,它们相交后等于U,且不存在Ui属于Uj。Fi继承了F中不出现Ui以外的属性的函数依赖。
2.12.1 无损连接
分解后的表子表自然连接后和原表一样
判定条件:
分解后子表的公共属性能够决定至少一个子表的所有属性
分解必须是无损的
2.12.2 保持函数依赖
分解后的每个Fi相交后等于F
尽可能保持函数依赖
六、NoSQL
哈希存储:键-值
分布式存储技术
优点:
数据结构不固定,适用于数据量爆发式增长
1. 特点
分布式数据库, 最大的特点就是分布式,即满足BASE,ASE方法通过牺牲一致性和孤立性来提高可用性和系统性能。
BASE为Basically Available, Soft-state, Eventually consistent,其中BASE分别代表:
- 基本可用(Basically Available):系统能够基本运行、一直提供服务。
- 软状态(Soft-state):系统不要求一直保持强一致状态。
- 最终一致性(Eventual consistency):系统需要在某一时刻后达到一致性要求。
2. 评估
CAP
C:一致性,对于客户端的每次读操作,要么读到的是最新的数据,要么读取失败。换句话说,一致性是站在分布式系统的角度,对访问本系统的客户端的一种承诺:要么我给您返回一个错误,要么我给你返回绝对一致的最新数据,不难看出,其强调的是数据正确。
A:可用性,任何客户端的请求都能得到响应数据,不会出现响应错误。换句话说,可用性是站在分布式系统的角度,对访问本系统的客户的另一种承诺:我一定会给您返回数据,不会给你返回错误,但不保证数据最新,强调的是不出错。
P:分区容忍性,由于分布式系统通过网络进行通信,网络是不可靠的。当任意数量的消息丢失或延迟到达时,系统仍会继续提供服务,不会挂掉。换句话说,分区容忍性是站在分布式系统的角度,对访问本系统的客户端的再一种承诺:我会一直运行,不管我的内部出现何种数据同步问题,强调的是不挂掉。
七、嵌入式SQL
数据库和高级程序语言通信
SQL通信区SQLCA:SQL语句执行后,系统反馈给应用程序信息 ,描述系统当前工作状态,描述运行环境。这些信息将送到SQL通讯区中,应用程序从SQL通信区中取出这些状态信息,据此决定接下来执行的语句
主变量:嵌入式SQL语句中可以使用主语言的程序变量来输入或输出数据。在SQL语句中使用的主语言程序变量简称为主变量(Host Variable)
指示变量:是一个整型变量,用来“指示”所指主变量的值或条件
游标的定义:游标是系统为用户开设的一个数据缓冲区,存放SQL语句的执行结果
每个游标区都有一个名字,也可以理解为该数据区的指针
用户可以用SQL语句逐一从游标中(指针所指示的位置)获取记录,并赋给主变量,交由主语言进一步处理
八、考点
第一章:
数据库四位图灵奖得主:查尔斯·巴赫曼、埃德加·科德、詹姆斯·格雷、迈克尔·斯通布雷克(背下来)
数据库管理系统概念
数据库物理层、逻辑层、视图层
第二章:
关系模式(所有都是重点)
第三章:
SQL语句:
表操作语句(要知道主码外码完整约束)
增删查改
创建视图
授权(必考)
嵌入式sql了解
主变量、指示变量、游标的概念要知道
函数和过程建议掌握(创建方法)
触发器掌握,语句级触发器和行级触发器
第四章:
E-R图(所有都是重点):完全参与、共同参与
规范化(所有都是重点):
第四范式了解,BC范式分解规则了解(最好知道规则)
第五章
索引哈希(最多是选择题):**什么时候不要用索引、什么时候用索引(重点)
第六章:
查询优化:查询基本概念、优化基本概念,等价规则,简化表达式(原则能投影先投影、能选择先选择,尽量不要连接)
第七章:
事物并发控制(重点):ACID,事物状态、并发、可串行化调度,一致性的级别。并发改造,锁,基于时间戳的协议
第八章:
恢复:什么时候需要undo,什么时候需要redo,什么是WAL
第九章:
nosql:什么时候使用sql,什么时候使用nosql,cap理论(什么时候cp,ca,ap),nosql和rdbms区别
第一道大题:关系表达式,sql语句
第二道大题:数据库设计(E-R图)
第三道大题:规范化(属性依赖集、等价等)
第四道大题:改写并发
转载请注明来源,欢迎对文章中的引用来源进行考证,欢迎指出任何有错误或不够清晰的表达。可以在下面评论区评论,也可以邮件至 21009200039@stu.xidian.edu.cn