终极数据库笔记

动力猿本猿

已于 2024-04-06 09:05:51 修改

阅读量327

点赞数 5

分类专栏：数据库系统概论终极笔记文章标签：数据库笔记 oracle

于 2024-03-03 21:56:08 首次发布

本文链接：https://blog.csdn.net/m0_51203566/article/details/136431014

版权

数据库系统概论同时被 2 个专栏收录

12 篇文章 0 订阅

订阅专栏

终极笔记

4 篇文章 0 订阅

订阅专栏

系列文章目录

终极计网笔记
 终极C++笔记
 终极软工笔记

文章目录

系列文章目录
二、画E-R模型和转关系模式
三、代数查询和SQL查询
四、函数依赖的规范化
五、优化查询树
六、封锁
七、检查点恢复
八、非查询SQL语句
一、基础知识

动力猿在备考研究生复试过程中通过归纳大量真题和课后题后凝练的心血，足以应对数据库的期末考试或者考研复试。看官老爷感觉有哪些欠缺的地方，欢迎讨论交流，如果感觉有一定的帮助，还请点赞关注支持一下动力猿吧！

二、画E-R模型和转关系模式

1.画E-R图

实体有不认识的词E-R图就用中文。
要是课程、雇员什么常见的E-R图就用英文，首字母一定大写，联系名不知道单词就用实体的大写首字母拼起来。

实体一定要正方形分布画，这样好补充联系。

1.先看有没有给出关系模式：
只有一个主键的肯定是实体。
用另外两个表的主键当主键的表就是一个联系。

2.再看文字描述：
题目描述中发现名词实体用铅笔画方框，发现下面的联系画菱形——两名词实体间的动作肯定是关系/ “每个系有且仅有一名系主任” / “实体分为AB，其中A可以怎么样N种C，B只能怎么样一种C”

如果只说某个A实体分了几类每种是什么，而没有不同比例作用另一个实体B，那么按照哪个实体分类就给哪个实体添加一个Type属性。

不要疑神疑鬼是不是三元联系，三元联系会给的非常明显也就是两个实体的主键不能唯一确定它们之间的那个联系。

联系两端的数量：就看一个我能动作几个你你就是几。有的时候有特殊的数量要求
例如:学生一定要留有多个电话，并至少留两个及以上电话号码，学生累计
最多允许借阅图书 5 本，并且假设所有借阅的书都不相同。
在这里插入图片描述 3.画完之后别忘了给实体和联系加属性！

2.E-R图转关系模式

ER图画完后先找1对n/1对1的联系，写n实体的关系模式，将1的主键加到属性最后作为外键。1对1的联系考虑放在哪里比如一个部门被一个员工管理那么应该在部门表的最后加一个员工号属性表示经理，声明为外键。

然后把剩下的实体关系模式写了。

最后写m到n的联系的关系模式，主键是两个实体的主键结合起来。

3.画E-R图的例子

例1、给定一个学生一课程一教师管理系统,存在如下模式:
student(sno,sname,sex,age,dname),
sc(sno,cno,grade, year),
course(cno, cname, lhour, credit, semester),
teacher(tno,tname,dname)
department(dno,dname)
其中 student 描述了学生的学号、姓名、性别、年龄和所在系，
sc 描述了学号、课号、成绩和选课年份，
course 描述了课号、课程名、学时、学分和学期，
teacher 描述了教师的教师编号、姓名、所在系，
department 描述了系的系号和系名，
一名教师只属于一个系，每个系有一名教师担任系主任，一门课可由多名教师讲授，并且教师必须讲课，学生选指定一名教师讲的课。
在这里插入图片描述
例2、给定一个学生选课系统，存在如下模式:
S(So,Sname,age,sex)
SC(Sno.Cno.Grade) ,
C(Cno.Cname.lhour.credit)，
T(Tno,Tname.major)。
其中 S 描述了学生的学号、姓名、年龄和性别，SC描述了学号、课号、成绩，C 描述了课号、课程名、学时、学分，T描述了教师的教师编号、姓名、专业，教师分为从基础课教师和专业课教师。对于基础课教师，一个教师只能教一门课，一门课可由多位教师讲授。对于专业课教师，一位教师可以讲授多门课，一门课可由多为教师讲授，学生只能选某一位教师的课。

在这里插入图片描述例3、开发一个研究生学习管理系统。系统要求: 学生按参加的课题分为三类: 研究型(参加纵向课题的学生),应用型(参加横向课题的学生) 和其他(不参加课题的学生)。每个学生在研究生学习期间只参加一种课题的研究。根据学生的工作量和所属类型给学生发每个月的报酬，要求记下来学生在读期间每个月的报酬。
当每个月参加课题的时间大于 80 小时时，月报酬 E=580系数 C，
否则月报酬 E=5参加课题的时间 T系数 C，
其中，研究型学生的系数是 1.2，应用型学生的系数是 1.5，其他型的系数是 0。
每个学生的报酬只能从某个课题拨款，但不一定从学生参加的课题中拨款。一个课题可以给多个学生提供报酬。本管理系统至少要管理:学生(学生 id，学生姓名，年龄，研究方向等) : 课题信息(课题类别，课题名称等)，以及学生的报酬信息，不足的信息要求用户填补。

在这里插入图片描述

4.特殊的说法

一个公司数据库需要存储雇员、部门和雇员小孩的信息。雇员工作在部门(一个雇员只能工作在一个部门)，每个部门由一个雇员管理，每个雇员小孩的名字是唯一的，假定小孩只有一个家长工作在这个公司，而且我们不关心那些已经调离雇员的小孩情况。请画出ER图捕获这些信息，并将其转换为关系模型。

在这里插入图片描述

一门课可有多个教授讲授，一个教授可以讲授多门课程。教授可以在几个学期讲授同一门课程，每次讲授活动都需被记录下来。
在这里插入图片描述
每位教师必须讲授课程
每个教授只讲授一门课程，每门课程可有几位教授讲授

假定一些特定课程只能由一组教授联合讲授，且这些教授中的任一位不可能独立讲授这门课程：可以看到，最难的不过三元联系加上ISA罢了
在这里插入图片描述

在这里插入图片描述

三、代数查询和SQL查询

代数查询结束不用分号
SQL语句结束必须有分号

1.代数查询

“多个条件”：先投影再选择，每多一个条件就多连接一个表的条件选择。

“或”： $\vee$
在这里插入图片描述

“且”： $\wedge$

“满足条件一且不满足条件二”：满足条件一的投影减去满足条件二的投影
如查询所有1号教练指导过但2号教练没有指导过的会员的姓名。

在这里插入图片描述

“所有”：（目标信息+条件属性）的投影÷条件属性的投影
如查询被所有的男教练都指导过的会员的姓名。
在这里插入图片描述

2.SQL查询

关键字都大写
字符串是单引号
用到的两个表里有公共属性，使用该公共属性一定要在前面加个表名，不加不行

属性方面的要求多一点不怕

where里面用公共属性连接相关表然后挨个写条件就行。

“某一/任一”：比较运算符和any/all（SELECT……）相结合

“有/没有”

有/没有相当于在/不在符合条件的里面，我们用IN/NOT IN加SELECT嵌套查询更方便，值得注意的是如果内外SELECT里用到了相同的表，要用X、Y DX、DY来区分。

没有选修1号课程的学生名（选课表里没有选修记录）

SELECT s.sname
FROM S
WHERE sno NOT IN
( SELECT sno
FROM SC
WHERE cno = 1
);

“包含全部”、“至少”

“包含全部”、“至少”这两个概念使用两个NOT EXISTS和DISTINCT去重。

“全部”：用两个not exists 对于X来说，没有一个Y，能使得在XY的联系表Z里没有X选Y的记录

选修了全部课程的学生名（没有一门课没有选）
SELECT DISTINCT s.sname
FROM S
WHERE NOT EXISTS (
SELECT *
FROM C
WHERE NOT EXISTS (
SELECT *
FROM SC
WHERE SC.sno = S.sno
AND SC.cno = C.cno
)
);

设数据库中有 4 个关系表: 职工表 EMP(Eno,Ename,Sex,Rank)，其属性分别代表职工号、
姓名、性别和等级。工作表 WORKS(Eno,Cno)，其属性分别代表职工号，工作的公司编号。公司表COMP(Cno,Cname,City)，其属性分别代表公司编号,公司名和所在城市。级别工资 SALARY(Rank,Salary),其属性分别代表等级和工资。
查询包含所有等级的员工的公司名称和所在的城市

SELECT DISTINCT Cname, City
FROM COMP
WHERE
NOT EXISTS (
SELECT *
FROM SALARY
WHERE
NOT EXISTS (
SELECT *
FROM EMP, WORKS
WHERE EMP.Eno = WORKS.Eno AND WORKS.Cno = COMP .Cno AND EMP.Rank = SALARY .Rank
)
);

“至少”：用两个not exists 对于X来说，没有一条X1选Y的XY联系表记录，在该XY联系表的拷贝里没有X选相同Y的记录。

查询选修了学号为 200505 的同学所选修的课程的学生的学号和姓名，并写出关系代数。
以后看到“全部”“至少”直接考虑要用的表套模板就行。

在这里插入图片描述

“非属性数量要求”、“总和”、“平均”、“最”

首先，使用GROUP BY子句对数据进行分组，将具有相同值的行分成不同的组。

然后，使用聚集函数在每个分组上进行计算，生成每个分组的聚合结果。

最后，使用HAVING子句表现聚集函数要满足的条件（聚集函数不能放在where里才引入having的），对分组结果进行筛选，只保留满足条件的分组。

COUNT

查询在2005年超过50人选的课的课号和选课人数
在这里插入图片描述

一家超市的会员卡管理系统，会员卡分为三类:折扣卡，本次累计消费折扣卡和累计消费折扣卡。超市为消费者发放会员卡，每一会员只能拥有一种卡，当消费者购物时，根据消费者拥有的卡的类型进行打折消费，并记下消费金额以及折扣信息。存在的参考模型如下:
卡类别: Type(tid,tname),
卡信息: Card(cid,cname.tid)，
会员信息: Member(mid,mname. age.job,cid)，
会员的消费信息: Sell(sid, mid, date, cid, sum).

每种类别的卡交易了多少次？
在这里插入图片描述

SUM
统计各种类型卡的销售总金额
在这里插入图片描述

AVG

求出每个学生超过他自已选修课程平均成绩的课程号
Select Sno,Cno
From SC X
Where Grade>
(Select AVG(Grade)
From SC Y
Where YSno=X.Sno);

MAX/MIN查询满足最值的结果时一定要清醒，这两个函数单纯就是求数的不会帮你把最值连接到对应的属性上，需要你自己用=来嵌套

在这里插入图片描述

查询男生里面成绩最好的学生
SELECT Name, Sex, Grade
FROM Students
WHERE Sex = ‘男’ AND Grade = (SELECT MAX(Grade) FROM SC WHERE StudentID IN (SELECT StudentID FROM Students WHERE Sex = ‘男’));

计算机系最年轻的教授的姓名和年龄
在这里插入图片描述

两种条件要求，单独满足哪一种都很好表示，就是同时满足很难表示

两个查询的结果属性组必须是一样的才行

并集UNION
查询 CS 系或者不在 CS 系但讲授的课程名称包括CS的教授的名字;

交集INTERSECT

差集EXCEPT

格式

集合查询
两个SELECT语句之间用UNION / INTERSECT / EXCEPT来连接分别表示并交差三种操作。
单个查询
在这里插入图片描述

四、函数依赖的规范化

1.找候选码

按以下步骤求候选键：

1.没在依赖集中的属性一定存在于候选码当中，在R（）中画下划线
2.
FD左部的属性写一个不重复的左列，FD右部的属性写一个不重复的右列，划掉两列中相同的属性。
此时左列中没划掉的一定在候选码，在R（）中画下划线。
右列中没划掉的一定不在候选码，先从R（）画斜线删去。

画下划线的属性组上添加没画过线的属性形成组合，如果闭包为U，该组合是个候选码。

属性组的闭包是说：从属性组本身出发开始拓展闭包集，看当前闭包集包含哪个依赖的决定因素，那么将该依赖的被决定因素加入闭包集。然后继续扩展闭包集直到不能再拓展或者闭包已为全集。

2.判断范式类型

1NF：存在非主属性对码的部分依赖。

2NF：每个非主属性都完全依赖于任一候选码，但存在非主属性对码的传递依赖。

3NF：每个非主属性都不部分依赖或传递依赖于任一候选码
充分条件——所有属性都是主属性一定是3NF

BCNF：每一个决定因素都包含码。
充分条件——二目关系一定是4NF所以一定是BCNF

3.将模型转化为符合3NF规范的模型

只需要分解成每个表都满足：
非主属性都只能被主键唯一确定，而不能被其他属性所确定。
在这里插入图片描述

4.模式分解

1NF到2NF

设关系模式R(U)，有一个码是W，R上还存在 W真子集X—>非主属性Z，所以Z对W局部依赖。此时应把R分解成两个模式：
R1(XZ)，主键是X；
R2(U-Z)，主键仍是W，外键X。
利用外键和主键的链接，可以重新得到R。
如果R1和R2还不是2NF，重复上述过程，一直到每一个关系模式都是2NF为止。

2NF到3NF

设关系模式R(U)，有一个码是W，R上还存在非码属性组X—>非主属性Z，由于码W肯定能推出X，所以Z对W传递依赖。此时应把R分解成两个模式：
R1(XZ)，主键是X
R2(U-Z)，主键仍是W，外键是X（参照R1）。
利用外键和主键匹配机制，可以得到R
如果R1和R2还不是3NF，重复上述过程，一直到每一个关系模式都是3NF为止。

3NF到BCNF

对于每一个违反BCNF的函数依赖X -> Z（即X不包含码），将关系模式分解为两个模式：
R1（XZ）主键是X
R2 (U-Z)

对新生成的模式重复步骤1和2，直到所有的模式都满足BCNF。

判断模式分解是否满足无损连接/函数依赖

一个无损连接的分解不一定具有依赖保持性；一个依赖保持的分解也不一定具有无损连接性。

无损连接性
如果我们能够通过在分解后的关系上执行自然连接操作，无误差地重新获取原始关系，那么我们就可以说这个分解满足无损连接性。

无损连接性的判断：
如果一个关系R被分解为两个关系R1和R2，那么R1和R2的交集（即他们共有的属性集合）必须是R1或R2（或两者都是）的超键（包含候选码的一组属性）。

让我们来看一个例子：

假设有一个关系R(A, B, C)，其中：

A是候选键
B是候选键
C是非键属性

现在，我们将R分解为两个关系R1(A, C)和R2(B, C)。在这种情况下，R1和R2的交集是{C}，并且它不是R1或R2的超键。因此，这个分解不满足无损连接性。

如果我们将R分解为R1(A, C)和R2(A, B)。在这种情况下，R1和R2的交集是{A}，并且它是R1和R2的超键。因此，这个分解满足无损连接性。

如果一个关系R被分解为三个以上的关系，就得通过以下的算法来判断了:
在这里插入图片描述图上没有说但我们需要注意的是当某列的b都一样时（比如该列除了a3就是b13），把b全变成a。

初始表

结果表
在这里插入图片描述

依赖保持性
在这里插入图片描述

在这里插入图片描述

模式分解的极限

若要求具有无损分解性，模式分解总可以达到4NF
若要保持函数依赖，模式分解总可以达到3NF但不一定能达到BCNF
若要保持函数依赖和具有无损分解性，模式分解也总可以达到3NF，但不一定能达到BCNF

5.最小依赖/最小覆盖

步骤：
(1) 化单依赖右边的属性得F1。
(2) 去除依赖左边多余的属性得F2。
设XY→A是F的任一函数依赖,在F中求出X的闭包X+。如果X+包含了Y,则Y为多余属性,该函数依赖变为X→A。
(3)去除F2中多余的依赖得结果F3。
设X→A是F的任一函数依赖,在F-{X→A}中求出X的闭包X+。如果X+包含了A，则X→A为多余的函数依赖,应该去除；否则,不能去除。

例：设函数依赖集F={A→C,C→A,B→AC,D→AC,BD→A}，计算的等价最小依赖集。
（1）化单依赖右边的属性得F1：F1={A→C,C→A,B→A,B→C,D→A,D→C,BD→A}
（2）去除依赖左边多余的属性得F2。对于BD→A，由于有B→A，所以D属性多余， BD→A变成B→A，与前面的重复，所以结果变成F2：F2={A→C,C→A,B→A,B→C,D→A,D→C}
（3）去除F2中多余的依赖得结果F3。因为A→C,C→A,所以就有： B→A,B→C以及D→A,D→C中之一为多余的。取F3={A→C,C→A,B→A,D→A}
（4）在F3中:对于A→C,因为F3 -｛A→C｝中A的闭包是A,不包括属性C，所以A→C不多余，不能去除。
在F3中:对于C→A,因为F3 -｛C→A｝中C的闭包是C,不包括属性A，所以C→A不多余，不能去除。
在F3中:对于B→A,因为F3 -｛B→A｝中B的闭包是B,不包括属性A，所以B→A不多余，不能去除。
在F3中:对于D→A,因为F3 -｛D→A｝中D的闭包是D,不包括属性A，所以D→A不多余，不能去除。
所以，F3中没有多余的函数依赖。即F的等价最小依赖集为：{A→C,C→A,B→A,D→A}
注意：函数依赖集的最小集并不是唯一的

五、优化查询树

1.查询优化的优化原则

（1）选择运算尽可能先做
（2）投影运算和选择运算同时进行
（3）某些选择同它前面的笛卡尔积结合成一个连接
（4）投影和前后双目运算结合起来
（5）找出公共子表达式

启发式查询优化中关系代数执行顺序为：选择–>连接–>笛卡尔积

在这里插入图片描述

2.语法树

投影project，条件select，连接join
在这里插入图片描述

3.关系代数表示的语法树及优化

条件选择下沉到叶结点的表上，然后向上两两公共属性连接，最后根节点是投影目标属性。

在这里插入图片描述

3.构建哪些索引可以改善查询效率

在每个表有条件要求的属性上建立索引。

六、封锁

1.判断封锁协议

1.两段锁协议：事务分两个阶段对数据项进行加锁解锁，第一个阶段只获得锁，第二个阶段只释放锁。

若并发执行的所有事务均遵守两段封锁协议，则对这些事务的任何并发调度都是可串行化的。
也就是说两段锁协议能完全避免丢失修改、读脏数据和不可重复读这三种问题。

但是遵守两段封锁协议的事务仍可能发生死锁。

2.一次封锁法可以避免死锁。事务在执行过程中会一次性获取所有需要的锁，并在事务结束时一次性释放所有锁。

3.一级封锁协议:依次判断每个事务是否都符合以下规则——修改数据之前都先对其加X锁（X锁直到事务结束才释放），但是读数据前有没加S锁的
■仅能防止丢失修改■不能保证不读脏数据和可重复读

4.二级封锁协议:依次判断每个事务是否都符合以下规则——修改数据之前都先对其加X锁（X锁直到事务结束才释放），而且读数据之前都加S锁读完即释放S锁
■不光防丢失修改，还能保证不读脏数据■不能保证可重复读

5.三级封锁协议:依次判断每个事务是否都符合以下规则——修改数据之前都先对其加X锁，而且读数据之前都加S锁，两种锁都是事务结束才释放。
■三种问题全能防止

2.T1、T2并发执行过程

abort就是rollback的同义词，撤销该事务所有的操作。

有可能让写自己可串行化调度/导致三种错误的调度/发生死锁的调度：

在这里插入图片描述

满足两段锁但是死锁的调度：
在这里插入图片描述

3.冲突可串行化调度

可串行化调度

多个事务并发执行的结果与按某一次序串行地执行这些事务时的结果相同，此并发调度即为可串行化调度。
可串行性是并发事务正确调度的准则。

可串行化调度的充分非必要条件：冲突可串行化
在这里插入图片描述

事务数据都不同随便换。
事务不同数据相同只有读读能换。
事务相同数据不同不用换也不能换。
在这里插入图片描述

在这里插入图片描述

可串行化调度中事务的提交顺序与串行化序列不同

让我们考虑两个事务T1和T2。

T1: r1(x) r1(y)

T2: r2(y) w2(x)

一个可串行化调度是： r1(x) r2(y) w2(x) r1(y)
它的提交顺序是T2、T1
但是它所对应的串行化序列是 r1(x) r1(y) r2(y) w2(x)

七、检查点恢复

事务故障/介质故障/系统故障的处理过程

事务故障处理: 反向扫描日志文件，对事务的更新操作执行逆操作直到读到此事务的开始标记。

系统故障处理：正向扫描日志文件，对已经提交的事务执行REDO，对故障发生时未提交的事务执行UNDO。

介质故障处理:装入最新的数据库的后备副本，使数据库恢复到最近一次转储时的一致性状态;装入相应的日志文件副本，重做已经完成的事务。

从处理过程能看出事务故障和系统故障只需要日志，而介质故障不光需要日志还需要后备副本。

检查点在恢复中的作用

检测点的作用是改善恢复效率。
需要做的任务有:

从重新开始文件中找到最后一个检测点在日志文件中的地址，由该地址在日志文件中找到最后一个检测点记录，从检测点正向扫描日志文件。
每个新扫描到的事务都先归类到UNDO-List，然后向后扫描，如果扫描中发现UNDO-List里有事务在日志结束前提交了，就把该事务归类到REDO-List。
扫描结束后分别对两个事务队列执行相应的 REDO、UNDO 操作。

UNDO/REDO LIST

首先明确三点：
检查点前提交的事务的修改操作均已写入磁盘。
故障发生时当前一切正在进行的操作都会丢失。
事务提交后需要一定时间才能把修改操作写入磁盘。

我们的目的是在故障发生后抓紧达到一个一致性状态——必须把当前已提交的事务的修改操作全部写入磁盘里。

这样就很明确了：

事务提交时间在检查点前——事务已提交且修改操作早已写入磁盘。

事务提交时间位于检查点与故障发生时——事务已提交，但是不确定修改操作是否写入磁盘，只能重做一次保证修改肯定能写入磁盘。

事务提交时间位于故障发生后——没提交呢撤销不管了。

在这里插入图片描述

八、非查询SQL语句

现有关系数据库中的三个关系表如下:

EMPLOYEE(eno, ename, age)其属性分别代表员工号、员工姓名、年龄
COMPANY(cno, cname, city)其属性分别代表公司号、公司名称、公司所在城市
EC(eno, cno, salary)其属性分别代表员工号、公司号、工资

建表

CREATE TABLE EC (
eno int primary key ,//当主键有两个的时候只能在最后声明了
cno int not null ,
salary int check（salary>1000）,
foreign key(cno) references COMPANY(cno)
);

插入元组

值得注意的是可以只插入元组的部分属性值，但要在表名处声明属性列，这样没有插入的属性自动取NULL。
如果不在表名处声明属性列，那么就必须每个属性都要插入值。
还有就是可以把一个SELECT派生表插入到表里去，对多个元组就不能用values（）了

在这里插入图片描述

删除某些元组

1.删除只能删除元组，根本没得选，所以没有*。
2.删除的where一般都用in嵌套。也就是删除的依据在另一个表里，但是那个表和本表有公共属性。
3.有时2中的两个表都得删除，先删“派生的”后删“基本的”

会员的消费信息: Sell(sid, mid, date,cid,sum)
消费明细信息: Selldetail(sid, did,price,pid,number,subtotal)
将所有 2004 年之前的销售信息删除

在这里插入图片描述

某个属性是空值，不是=null而是is null
删除无成绩 (GRADE) 的学生的选课信息。
在这里插入图片描述

建立索引

索引名就是表名前三个字母加属性名

唯一索引UNIQUE INDEX
唯一索引用于确保列中的值是唯一的，适合查找某个具体值。

聚簇索引CLUSTER INDEX，在 cluster 索引表中，索引项的顺序和表中数据记录的物理顺序一致。
聚簇索引是根据指定的列对数据进行物理排序，并将数据存储在簇中，可以将具有相似或相邻年龄的行存储在物理上相邻的位置。适合查找符合范围的值。

学生表S (sno,sname.sex,age,dept）其属性分别代表学号，学生姓名，性别，年龄和院系
教师表T (tno,tname,title,cno）其属性分别代表教师编号，姓名，职称和所教课程
课程表C(cno,cname,hour）其属性分别代表课程编号，课程名称和课时
选课表SC( sno,cno,score）其属性分别代表学号，课程编号,授课教师编号和本课程的最终成绩
为了便于后续的查询，在S表上按学号升序建立唯一索引/聚簇索引

CREATE UNIQUE/CLUSTER INDEX Stusno ON S(sno ASC);
升序是ASC，降序是DESC

建立视图

视图可以在基本表上建立，也可以在视图上建立。
视图名就是IS_表名

建立CS 系选修了1号课程的学生的视图（包括学号、姓名和院系)

CREATE VIEW IS_T(sno,sname,dept) //这里一定要加属性列
AS
SELECT S.sno,S.sname,S.dept
FROM S,SC
WHERE S.dept=‘CS’ AND S.sno=SC.sno AND cno=‘1’;

更新

给所有的2级教练在原来的基础上再增加500元奖金。
UPDATE Alevel
SET award=award+500
WHERE level=2;

授权

（1）授予

GRANT INSERT, UPDATE, DELETE ON table_name TO user_name;

所有权限、所有表、所有用户
GRANT ALL PRIVILEGES ON ALL TABLES IN database_name TO PUBLIC;

最后加WITH GRANT OPTION选项，说明用户还可以把被授予的权限授予给别人。

（2）收回

REVOKE SELECT, INSERT, UPDATE ON table_name FROM user_name;

REVOKE ALL PRIVILEGES ON ALL TABLES IN database_name FROM user_name;

最后加
CASCADE:级联，回收用户的权限后把该用户转授别人的权限也从别人那里收回。
RESTRICT:如果要回收的权限也被用户转授给他人，拒绝执行回收语句。

（3）角色
挨个为每个用户都分配一个一个权限实在是太麻烦了！直接给用户授予一个角色（和官职一样，是权限的集合），用户是什么角色就有该角色的所有权限。

创建角色的语句：

CREATE ROLE role_name;
给角色授权的语句：

GRANT privilege_name ON object_name TO role_name;

将一个角色授权给其他角色或用户的语句：

GRANT role_name TO target_role_or_user;
收回角色权限的语句：

REVOKE privilege_name ON object_name FROM role_name;

定义事务

定义一个事务:删除"品质部”，并将原“品质部”的员工信息转到“生产部”。
注意一定要先改再删，删了就没法改了。

一、基础知识

1.数据库概念

DB的宿主是指具有访问该数据库权限的用户。

2.数据库

对于某个具体的数据库来说，E-R图、数据模型、数据库文件都不是唯一的。

5.数据库系统特点
数据结构化、数据共享性高冗余度低且易扩充、数据独立性高、数据由数据库管理系统统一管理和控制。

6.三级模式结构和二级映像功能

（1）三级模式结构：数据库系统由外模式、模式、内模式三级构成，是数据的三个级别抽象，把数据的具体组织留给数据库管理系统管理，使用户能逻辑抽象地处理数据而不必关心数据在计算机中的具体表示和存储方式。
请添加图片描述
模式：
数据库数据在逻辑级上的视图（因此又称逻辑模式），不涉及物理硬件和应用程序，一般是稳定不变的，是数据库的中心与关键独立于另外两个层次应当首先确定。
一个数据库只有一个模式而且是所有用户的公共数据视图，定义数据的逻辑结构（数据记录由哪些数据项构成、数据项的名字类型取值范围）、定义数据之间的联系、定义与数据有关的安全性、完整性要求。

内模式：
数据物理结构和存储方式的描述（因此又称存储模式），是数据在数据库内部的组织方式。依赖于模式、独立于外模式。
一个数据库只有一个内模式，定义记录的存储方式（升降序、聚簇）、索引按照什么方式组织（B+树、hash）、是否压缩存储是否加密、数据的存储记录结构有何规定等等。

外模式：
数据库用户（程序员和用户）的数据视图（因此也称子模式或用户模式），是与某一应用有关的数据的逻辑表示。依赖于模式、独立于内模式。
一个数据库可以有多个外模式，不同的用户在应用需求看待数据的方式等方面存在差异，则其外模式就是不同的。同一外模式也可以被多个应用所使用，但一个应用只能使用一个外模式。外模式有力保护了数据库的安全性，每个用户只能看见访问所对应的外模式中的数据，数据库中其余数据是不可见的。

（2）二级映像功能：为了在系统内部实现三个抽象层次的联系和转换，数据库管理系统在这三级模式之间提供了两层映像：外模式/模式映象和模式/内模式映像，从而保证了数据库系统中的数据能够具有较高的逻辑独立性和物理独立性。

外模式/模式映像：对于每一个外模式，数据库都有一个外模式/模式映像定义该外模式与模式之间的对应关系。当模式改变时（增加新属性、改变属性数据类型等），只需对各个外模式/模式映象作相应改变，而外模式仍保持不变从而无需修改应用程序，保证了数据与程序的逻辑独立性简称数据的逻辑独立性。

模式/内模式映象：数据库中只有一个模式也只有一个内模式，因此模式/内模式映像是唯一的，定义了数据全局逻辑结构与存储结构之间的对应关系（例如逻辑记录和字段在内部是如何表示的）。当数据库的内模式改变时（如选用另一种存储结构），只需对模式/内模式映像作相应改变，使模式保持不变从而无须修改应用程序，保证了数据与程序的物理独立性简称数据的物理独立性。

应用程序依赖于特定的某种外模式，而独立于模式和内模式。两层映像提供的数据与程序间的物理和逻辑独立性简称独立性保证了外模式的稳定性从而保证了应用程序的稳定性（除非应用需求发生变化否则一般不需修改应用程序），成功把数据的定义和描述从应用程序中分离出去。

7.数据字典

数据字典记录了数据库中所有的定义信息，包括关系模式定义、视图定义、索引定义、完整性约束定义、权限定义等。

所以数据字典可以保存的有元数据（描述数据的数据）、三级模式、约束定义等，但不可以保存副本数据，这是由后备副本保存的。

元数据：
元数据是关于数据的数据。它描述了其他数据的内容、格式、结构、来源等属性。

元数据具有如下几个主要功能：为数据提供详细的描述；帮助用户找到所需的信息；帮助组织、分类和管理数据；帮助保护数据的安全。
没有元数据，数据的价值就会大大降低，因为人们很难理解、找到、管理和保护数据。

8.数据库系统的独立性

数据库系统的数据独立性包括物理独立性（应用程序和数据库中的数据的物理存储是相互独立的）和逻辑独立性（应用程序和数据库的逻辑结构是相互独立的）。

9.数据模型的三要素
数据结构、数据操作、数据完整性约束

2.数据访问的安全性和并发执行的安全性

不是一个概念。

前者通过grant命令、视图机制实现。

后者通过加锁机制、隔离性控制实现。

3.并发执行产生的问题

丢失修改：

T1、T2都要读同一数据A并做修改，正确结果应该是对A依次执行两个修改。但并发的时候，T1读了A还没修改呢，T2就也读到原本的A然后自己修改了，这样两个事务执行完成后提交，A的值就是后提交的事务对A的修改结果。
显然先提交的事务的修改丢失了。

读脏数据：
读脏数据是指事务T1修改了某数据A0并将修改后的值A1写回数据库（注意这个地方要求的是写回数据库，而不是事务提交，因为根据事务的持久性，事务commit之后是不能rollback的），这时事务T2读到了修改后的值Al，但是之后事务T1因为一些原因没有commit而是rollback了，A1恢复到了A0，就产生了读脏数据的现象。

读脏数据读到的是已写回，未提交，未回退的数据。

不可重复读：

事务T1会两次读取某一数据,第一次读取后第二次读取前，事务T2增/删/改了同一数据，这样T1第二次读取时就无法再现前一次的读取结果。