数据库总结

点击下载该文档密码：cqoq
本人自制了简答题的速记卡片地址，大家可以参考使用。[下载Markji App 使用]

第一章绪论

1.1 数据库系统概述

数据库管理系统(DBMS)的功能:
1. 数据定义功能
2. 数据组织、存储和管理
3. 数据库操纵功能
4. 数据库的事务和运行功能
5. 数据库的建立和维护功能
6. 其他功能
数据库管理技术经历的三个阶段
1. 人工管理阶段
2. 文件系统阶段
3. 数据库系统阶段
数据独立性
1. 物理独立性:是指用户的应用程序与数据库中数据的物理存储是相互独立的。
2. 逻辑独立性:是指用户的应用程序与数据库的逻辑结构是相互独立的。
3. 数据独立性是由数据库管理系统提供的二级映像功能来保证的。
  - 数据独立性是由DBMS的二级映像功能来保证的（外模式/模式映像，模式/内模式映像），这两层映像机制保证了数据库系统中数据的逻辑独立性和物理独立性。

1.2 数据模型

数据模型是数据库系统的核心和基础
两类数据模型
- 第一类
  - 概念模型:是现实到信息世界的第一层抽象,也是数据库设计人员和用户之间进行交流的语言
- 第二类:
  1. 逻辑模型
    - 层次模型
    - 网状模型
    - 关系模型
    - ……
  2. 物理模型:是对数据最底层的抽象，它描述数据在系统内部的表示方式和存取方法，或在磁盘或磁带上的存储方式和存取方法，是面向计算机系统的。
概念模型
- 信息世界中的基本概念
  - 实体:客观存在并可相互区别的事物称为实体。例如:学生,部门…
  - 属性:实体所具有的某一特性称为属性。例如:学生实体的学号,年龄…
  - 码:唯一标识实体的属性集称为码。例如:学号为学生实体的码
  - 实体型:具有相同属性的实体必然具有共同的特征和性质。用实体名及其属性名集合来抽象和刻画同类实体，称为实体型。例如，学生（学号，姓名，性别，出生年月，所在院系，入学时间）
  - 实体集:同一类型实体的集合称为实体集。例如，全体学生就是一个实体集。
  - 与关系模式表对应的关系:
    - 表:实体
    - 表的属性:属性
    - 表的码:码
    - 表的结构:实体集
    - 表的所有元组:实体集
  - 实体之间的关系:一对一,一对多,多对多
  - 概念模型的一种表示方法:E-R模型.全称是:实体-联系方法(Entity-Relationship approach)
- 数据模型的组成:
  1. 数据结构(组成对象与对象之间的联系)
  2. 数据操作(CRUD)
  3. 数据的完整性约束条件(实体完整性(主码),参照完整性(外码),用户自定义完整性)
- 常用的数据模型
  1. 层次模型:
    - 倒立的树
  2. 网状模型:
    - 有向图,链表
  3. 关系模型:
    - 二维表
    - 关系（relation）：一个关系对应一张表
    - 元组（tuple）：表中的一行即为一个元组。
    - 属性（attribute）：表中的一列即为一个属性，给每一个属性起一个名称即属性名。
    - 域（domain）：域是一组具有相同数据类型的值的集合。属性的取值范围来自某个域。
    - 分量：元组中的一个属性值。
    - 关系模式：对关系的描述，一般表示为关系名（属性l，属性2.….属性n）
      - 例如:学生（学号，姓名，年龄，性别，系名，年级）
  - 关系模型要求关系必须是规范化的，必须达到第一范式(1NF)
    - 关系模型的优缺点:
      
      （1）关系模型与格式化模型不同，它是建立在严格的数学概念的基础上的。
      
      （2）关系模型的概念单一。无论实体还是实体之间的联系都用关系来表示。数据结构简单、清晰，用户易懂易用。
      
      （3）关系模型的存取路径对用户透明，具有更高的数据独立性、更好的安全保密性，简化了程序员的工作和数据库开发建立的工作。
1. 面向对象数据模型
  - 表格具有抽象意义
- 关系,关系模式,关系模型区别和联系
  1. 关系:一个关系对应通常说的一张表
  2. 关系模式:关系的描述
  3. 关系模型:关系模型由关系数据结构,关系操作集合,关系完整性约束三部分组成.
  4. 关系和关系模式的区别
    1. 关系模式是型,关系是值,关系模式是对关系的描述
    2. 关系是关系模式在某一个时刻的状态或者内容,关系模式是静态的,稳定的,而关系是动态的,随时间不断变化的,因为关系操作在不断地更新着数据库中的数据
    3. 类似于面向对象程序设计中”类“与”对象“的区别。”关系“是”关系模式“的一个实例，可以把”关系”理解为一张带数据的表，而“关系模式”是这张数据表的表结构。
  5. 关系模型和关系的区别
    - 关系模型包含关系,关系是关系模型的数据结构,在关系模型中,现实世界的实体以及实体间的各级联系均用单一的结构类型,即关系来表示

1.3 数据库系统的结构

数据库系统的三级模式结构
1. 模式(逻辑模式或概念模式)
  - 逻辑模式中的这些表称为基表，与物理模式的表一一对应
2. 外模式(用户模式)
  - 模式的子集,给最终用户看到的数据的样子,视图
3. 内模式(存储模式)
  - 描述了数据在磁盘上是如何存储的
4. 为了能够在系统内部实现这三个抽象层次的联系和转换，数据库管理系统在这三级模式之间提供了两层映像：外模式/模式映像和模式/内模式映像。两层映像保证了数据库系统中的数据能够具有较高的逻辑独立性和物理独立性。

1.4 数据库系统的组成

数据库管理员(DBA,DataBase Administrator)
1. 决定数据库中的信息内容和结构。
2. 决定数据库的存储结构和存取策略。
3. 定义数据的安全性要求和完整性约束条件。
4. 监控数据库的使用和运行。
5. 数据库的改进和重组、重构。
数据库系统
- 应用程序+DBMS+数据库+DBA（数据库管理员）

第二章关系数据库

2.1 关系数据库

关系
1. 域:一组具有相同数据类型的值的集合
2. 笛卡尔积:一个域中的元素与另外的域中的元素分别结合构成一个元组
3. 关系
  1. 候选码:某一属性组的值能唯一地标识一个元组，而其子集不能，则称该属性组为候选码（candidate key）。
  2. 主码:若一个关系有多个候选码，则选定其中一个为主码（primary key）。
  3. 主属性和非主属性:候选码的诸属性称为主属性（prime attribute）。不包含在任何候选码中的属性称为非主属性（non-prime attribute）或非码属性（non-key attribute）。
  4. 全码:关系模式的所有属性是这个关系模式的候选码，称为全码（all-key）。
  5. 关系的三种类型:
    1. 基本关系(又称为基本表或基表):实际存在的表,是实际存储数据的表示,不可再分,必须规范化(也就是达到第一范式1NF)
    2. 查询表:查询结果对应的表
    3. 视图表:由基本表或其他视图表导出的表,是虚表,不对应实际存储数据

2.2 关系操作

关系操作
1. 查询
2. 插入
3. 删除
4. 修改
基本查询操作:
- 选择操作σ (Select)(横挑）从一个表中把满足条件的元组选出来
  - 选择是一种单目运算，即对一个关系施加的运算，按给定条件从关系中挑选满足条件的元组组成的集合
  - 语法格式：σ<选择条件>（<关系名>）
- 投影操作π (Project)(竖挑) 将需要的属性列出来
  - 投影操作是单目运算，从关系中挑选指定的属性组成的新关系。
  - 语法格式：π<属性表>（<关系名>）
- 笛卡尔乘积× :两个关系的拼接
- 集合差- 把属于关系A不属于关系B的元组找出来
- 并 ∪ 把两个模式相同的元组并起来
其他操作可由基本操作来定义和导出

2.3 关系的完整性

实体完整性原则(主码)
- 若属性（指一个或一组属性）A是基本关系R的主属性，则A不能取空值（null value）。所谓空值就是“不知道”或“不存在”或“无意义”的值。
参照完整性原则(外码)
- 设F是基本关系R的一个或一组属性，但不是关系R的码，Ks，是基本关系S的主码。如果F与Ks相对应，则称F是R的外码（foreign key），并称基本关系R为参照关系（referencing relation），基本关系S为被参照关系（referenced relation）或目标关系（target relation）。关系R和S不一定是不同的关系。

2.4 关系代数

分类
1. 传统的集合运算(从行的角度进行,二目运算,两个关系之间进行)
  1. 集合的并、交、差
    - 参与集合的两个关系要满足两个条件:
      1. 属性个数相同
      2. 属性类型要一样
    - 参与并、差操作的两个关系的元组必须限制为同类型的，即具有相同的目，且对应的属性的域相同——并兼容（union compatibility）;
      1. 关系操作优先级高于集合操作;
      2. 一元操作（单目）优先级高于二元操作。
  2. 笛卡尔积
    1. 结果模式包括进行操作的两个表的所有属性，两张表的每条元组之间两两拼接
    2. 若R和S中有相同的属性名，在这些属性名前加上关系名作为限定词(如：R.B,S.B)，进行区别。
2. 专门的关系运算(涉及行又涉及列)
  1. 选择操作σ (Select)(横挑）从一个表中把满足条件的元组选出来
    - 选择是一种单目运算，即对一个关系施加的运算，按给定条件从关系中挑选满足条件的元组组成的集合。
    - 语法格式：σ<选择条件>（<关系名>）
  2. projection 投影操作π (Project)(竖挑) 将需要的属性列出来
    - 投影操作是单目运算，从关系中挑选指定的属性组成的新关系。
    - 语法格式：π<属性表>（<关系名>）
  3. 连接
    1. 语法格式R∞<连接条件>S＝σ<连接条件>（R * S）
      - 解释:关系R和关系S在该条件的连接操作等于关系R和关系S先做笛卡尔乘积,再按照该条件做选择操作
    2. 等值连接:
      - 一种特殊的条件连接，连接条件只有等值的条件
      - 结果模式和笛卡尔乘积的模式类似，把等值的属性去掉一列
    3. 自然连接:两张表在所有的公共属性上做等值连接
      - 步骤：
        
        作R x S（笛卡儿积）
        
        在R x S上选择同名的属性组
        
        去掉重复属性
    - 一般的连接操作是从行的角度进行运算，但自然连接还需要取消重复列，所以是同时从行和列的角度进行运算。
  4. 除运算
    - 计算思路：比如对于A/B来说，我们要找在关系A中跟关系B中所有y值都有联系的x值。【也就是找出在关系B中没有一个y值与A的是没有联系的。否定的否定,就是找出B中的列的属性在A中都有关联的属性,B中列的属性不写.】
    - A/B: πx(A)-all disqualified tuples(所有不合格的元组) = πx((πx(A)×B)-A)
      - 先在A中找不满足除法条件的x
        
        先把A做一个投影，投影到x属性
        将投影结果和关系B做一个笛卡尔乘积
        用笛卡尔乘积结果-A
        对上一步结果做一个投影，投影到x
      - 把关系A所有的x值减去所有不满足条件的x值
        
        把关系A投影到x
        投影结果减去上一操作找到的所有不满足条件的x值
      - 注：常见关键词：“至少” “全部”；
        
        求AB一般思路：πAC ÷ C ⋈ πAB
    - 语法格式:A/B = {<x>|ョ<x,y>∈A，∀<y>∈B}
传统的集合运算：并、差、交、笛卡儿积
专门的关系操作：选择、投影、连接、除运算等
基本的关系操作：选择、投影、并、差、笛卡儿积
交、连接和除，均可以用这5种基本运算来表达
交运算：R∩S = R-(R-S)
连接运算：R⋈S=σ<ΑΘΒ>（R × S)

除运算：R(X，Y)÷ S(Y，Z)= πx ®- πx(πx®× πy(S)-R)

第三章关系数据库标准语言 SQL

3.1 SQL 概述

SQL:结构化查询语言（Structured Query Language）
▲SQL的特点
1. 综合统一
2. 高度非过程化
  - 关系代数是一种过程化的表达。
  - 关系演算是一个非过程化的表达。只需要说明得到的结果，不必标明过程,是说明性语言。
3. 面向集合的操作方式
4. 以同一种语法结构提供多种使用方式
5. 语言简洁,易学易用
SQL的基本概念
- 三级模式结构对应的关系：
  - 外模式–>视图
    - 视图是从一个或几个基本表导出的表。它本身不独立存储在数据库中，即数据库中只存放视图的定义而不存放视图对应的数据。这些数据仍存放在导出视图的基本表中，因此视图是一个虚表。视图在概念上与基本表等同，用户可以在视图上再定义视图。
  - 模式–>基本表
    - 基本表是本身独立存在的表，在关系数据库管理系统中一个关系就对应一个基本表。一个或多个基本表对应一个存储文件，一个表可以带若干索引，索引也存放在存储文件中。
  - 内模式–>存储文件
    - 存储文件的逻辑结构组成了关系数据库的内模式，存储文件的物理结构对最终用户是隐蔽的。

3.2 数据定义

模式的定义与删除
1. 定义模式
  - CREATE SCHEMA<模式名>AUTHORIZATION<用户名>；
    - AUTHORIZATION:授权
2. 删除模式
  - DROP SCHEMA<模式名><CASCADE|RESTRICT>；
    - CASCADE（级联），表示在删除模式的同时把该模式中所有的数据库对象全部删除；
    - RESTRICT（限制），表示如果该模式中已经定义了下属的数据库对象（如表、视图等），则拒绝该删除语句的执行。只有当该模式中没有任何下属的对象时才能执行DROP SCHEMA语句。
基本表的定义和删除与修改
1. 定义基本表
  - [例3.7]建立学生选课表SC。
```
CREATE TABLE SC
（Sno CHAR（9）.
Cno CHAR（4）.
Grade SMALLINT，
PRIMARY KEY（Sno.Cno），/*主码由两个属性构成，必须作为表级完整性进行定义*/
FOREIGN KEY（SnO）REFERENCES Student（Sno），/*表级完整性约束条件，Sno是外码，被参照表是Student*/
FOREIGN KEY（CnO）REFERENCES Course（Cno）/*表级完整性约束条件，Cno是外码，被参照表是Course*/
);
```
2. 数据类型
  1. CHAR(n):长度为n的定长字符串
  2. VARCHAR(n):最大长度为n的变长字符串
  3. DATE:年.月.日,YYYY-MM-DD
  4. TIME:时.分.秒,HH:MM:SS
3. 模式与表
  1. 用户创建表没有指定模式,系统根据搜索路径来确定该对象所属的模式
  2. 显示当前路径:search path
4. 修改表
  1. add,用于增加新列,添加约束条件
    - [例3.8]向Student表增加“入学时间”列，其数据类型为日期型。
```
ALTER TABLE Student ADD S_entrance DATE；
```
  2. 修改数据类型:alter
    - [例3.9]将年龄的数据类型由字符型（假设原来的数据类型是字符型）改为整数。
```
ALTER TABLE Student ALTER COLUMN Sage INT；
```
5. 删除基本表
  1. DROP TABLE<表名>[RESTRICT|CASCADE]；
    - 选择RESTRICT，则该表的删除是有限制条件的。欲删除的基本表不能被其他表的约束所引用（如CHECK，FOREIGNKEY等约束），不能有视图，不能有触发器（trigger），不能有存储过程或函数等。如果存在这些依赖该表的对象，则此表不能被删除。
    - 选择CASCADE，则该表的删除没有限制条件。在删除基本表的同时，相关的依赖对象，例如视图，都将被一起删除。
    - 默认情况下是RESTRICT

3.3 索引的建立和删除

建立索引的优点
- 建立索引是加快查询速度的有效手段。数据库索引类似于图书后面的索引，能快速定位到需要查询的内容。用户可以根据应用环境的需要在基本表上建立一个或多个索引，以提供多种存取路径，加快查找速度。
建立索引
- [例3.13]为学生-课程数据库中的Student、Course和SC三个表建立索引。其中Student表按学号升序建唯一索引，Course表按课程号升序建唯一索引，SC表按学号升序和课程号降序建唯一索引。
```
CREATE UNIQUE INDEX Stusno ON Student（Sno）；CREATE UNIQUE INDEX Coucno ON Course（Cno）；CREATE UNIQUE INDEX SCno ON SC（Sno ASC，Cno DESC）；
```
修改索引
- [例3.14]将SC表的SCno索引名改为SCSno。
```
ALTER INDEX SCno RENAME TO SCSno；
```

删除索引

[例3.15]删除Student表的Stusname索引。

DROP INDEX Stusname；/*删除索引时，系统会同时从数据字典中删去有关该索引的描述。*/

3.4 数据查询

单表查询
1. 选择表中的若干列,
  - [例3.16]查询全体学生的学号与姓名。
```
SELECT Sno，Sname FROM Student；-- 将Student表投影到Sno,Sname上
```
2. 选择表中的若干元组
  - 消除取消重复的行,两个本来并不完全相同的元组在投影到指定的某些列上后，可能会变成相同的行。可以用DISTINCT消除它们。
  - [例3.21]查询选修了课程的学生学号。
```
 SELECT DISTINCT Sno FROM SC;
```
  - 如果没有指定DISTINCT关键词，则默认为ALL，即保留结果表中取值重复的行。
```
SELECT Sno FROM SC；
等价于
SELECT ALL Sno FROM SC；
```
  - [例3.22]查询计算机科学系全体学生的名单。
```
SELECT Sname FROM Student WHERE Sdept='CS'；
```
  - 语句的执行过程
    - 对表进行全表扫描,扫描每个元组,检查该元组在Sdept列的值是否等于’CS’,如果相等,则取出Sname,组成一个新元素输出,否则跳过该元素重复该过程
      - 如果人多,可以在Sdept列上建立索引,系统会利用该索引找出Sdept='CS’元组,从中取出Sname形成结果关系.
  - 确定范围
    - BETWEEN AND
      - [例3.26]查询年龄不在20~23岁之间的学生姓名、系别和年龄。
        
        SELECT Sname，Sdept，Sage FROM Student WHERE Sage NOT BETWEEN 20 AND 23；
  - 确定集合:谓词IN可以用来查找指定集合的元组
    - [例3.27]查询计算机科学系（CS）、数学系（MA）和信息系（IS）学生的姓名和性别。
```
SELECT Sname，Ssex FROM Student WHERE  Sdept IN（'CS，；MA，IS'）；
```
  - 字符匹配:LIKE
    - [NOT]LIKE<匹配串>[ESCAPE’<换码字符>]
    - % 表示任意长度的字符串
    - _表示任意单个字符串
    - 如果用户要查询的字符串本身就含有通配符%或_，这时就要使用ESCAPE<换码字符>短语对通配符进行转义了。(在正则表达式中,使用 ?：表示出现0次或1次 *：表示出现0次或多次 +：出现1次或多次)
    - [例3.35]查询以“DB_”开头，且倒数第三个字符为i的课程的详细情况。
```
SELECT* FROM Course WHERE Cname LIKE DB\_%i_'ESCAPE'\；/*这里的匹配串为"DB\_%i__"第一个_前面有换码字符\，所以它被转义为普通的字符。而i后面的两个的前面均没有换码字符\，所以它们仍作为通配符。加/表示_不具有实际意义*/
```
  - 涉空值的查询
    - [例3.37]查所有有成绩的学生学号和课程号。
```
SELECT Sno，Cno FROM SC WHERE Grade IS NOT NULL；/*IS不能使用=代替*/
```
  - 多从条件的查询
    - AND的优先级高于OR,可以使用括号改变优先级
    - [例3.27]查询计算机科学系（CS）、数学系（MA）和信息系（IS）学生的姓名和性别。
```
SELECT Sname，Ssex FROM Student WHERE Sdept IN（"CS，MA'，IS）;=   /*IN谓词实际上是多个OR运算的缩写*/SELECT Sname,Ssex FROM Student WHERE Sdept='CS'OR Sdept='MA'OR Sdept='IS';
```
3. ORDER BY 子句
  - 用户可以用ORDERBY子句对查询结果按照一个或多个属性列的**升序（ASC）或降序（DESC）**排列，默认值为升序。
  - 注: ASC = ascend, DESC = descend; 词根:-de 表示向下
  - [例3.39]查询选修了3号课程的学生的学号及其成绩，查询结果按分数的降序排列。
```
SELECT Sno，Grade FROM SC WHERE Cno='3' ORDER BY Grade DESC；
```
4. 聚集函数
  - ```
  COUNT（*）统计元组个数
  COUNT（[DISTINCT|ALL]<列名>）统计一列中值的个数
  SUM（[DISTINCT|ALL]<列名>）计算一列值的总和（此列必须是数值型）
  AVG（[DISTINCT|ALL]<列名>）计算一列值的平均值（此列必须是数值型）
  MAX（[DISTINCT|ALL]<列名>）求一列值中的最大值
  MIN（[DISTINCT|ALL]<列名>）求一列值中的最小值
```
- 指定了DISTINCT,需要去除重复值,不指定默认为ALL,不需要去除掉
- [例3.45]查询学生201215012选修课程的总学分数。
```
  SELECT SUM（Ccredit）
  FROM SC，Course WHERE Sno'201215012'AND SC.Cno-Course.Cno；
  -- 当聚集函数遇到空值时，除COUNT(*)外，都跳过空值而只处理非空值。COUNT（*）是对元组进行计数，某个元组的一个或部分列取空值不影响COUNT的统计结果。
```
- 注意:WHERE子句中是不能用聚集函数作为条件表达式的。聚集函数只能用于SELECT子句和GROUP BY中的HAVING子句。
5. GROUP BY 子句
  - GROUP BY子句将查询结果按某一列或多列的值分组，值相等的为一组。如果未对查询结果分组，聚集函数将作用于整个查询结果。分组后聚集函数将作用于每一个组，即每一组都有一个函数值。
  - [例3.46]求各个课程号及相应的选课人数。
```
SELECT Cno，COUNT（Sno）
FROM SC GROUP BY Cno;-- 该语句对查询结果按Cno的值分组，所有具有相同Cno值的元组为一组，然后对每一组作用聚集函数COUNT进行计算，以求得该组的学生人数。
```
  - 如果分组后还要求按一定的条件对这些组进行筛选，最终只输出满足指定条件的组，则可以使用HAVING短语指定筛选条件。
  - WHERE子句与HAVING短语的区别在于作用对象不同。WHERE子句作用于基本表或视图，从中选择满足条件的元组。HAVING短语作用于组，从中选择满足条件的组。
  - [例3.48]查询平均成绩大于等于90分的学生学号和平均成绩。
```
-- 下面的语句是不对的：
SELECT Sno，AVG（Grade）
FROM SC 
WHERE AVG（Grade）>=90
GROUP BY Sno;
-- 因为WHERE子句中是不能用聚集函数作为条件表达式的，WHERE作用的是整个表,而聚集函数是作用于组的.
-- 正确的查询语句应该是：
SELECT Sno，AVG（Grade）
FROM SC GROUP BY Sno 
HAVING AVG（Grade）>=90;
-- WHERE和GROUP BY组合时,WHERE应该在前,因为它作用与整个表
-- HAVING和GROUP BY组合时,HAVING应该在后,因为只有先进行分组后HAVING才能使用,它是作用域组的.
```
连接查询
- 一个查询同时涉及多个表
1. 等值连接与非等值连接
  - 连接运算符为=
  - [例3.49]查询每个学生及其选修课程的情况。
```
SELECT Student.*，SC.*
FROM Student，SC
WHERE Student.Sno=SC.Sno；
/*将Student与SC中同一学生的元组连接起来*/
```
2. 自身连接(p101)
  - 表与自己的连接
3. 外连接
  - 同关系代数中的概念一样,把悬浮元组(作连接的时候被舍弃的元组)仍然保存到结果关系中.
  - 左外连接:left outer join,保留左边关系中的悬浮元组
  - 右外连接:right outer join,保留右边关系中的悬浮元组
4. 多表连接
  - 两个表以上的表进行连接
嵌套查询
- 在SQL语言中，一个SELECT-FROM-WHERE语句称为一个查询块。将一个查询块嵌套在另一个查询块的WHERE子句或HAVING短语的条件中的查询称为嵌套查询（nested query）。
- 上层的查询块称为外层查询或父查询，下层查询块称为内层查询或子查询。
- 子查询的SELECT语句中不能使用ORDER BY子句，ORDER BY子句只能对最终查询结果排序。
- 以层层嵌套的方式来构造程序正是SQL中“**结构化”**的含义所在。
1. 带有IN谓词的子查询
  1. 不相关子查询:子查询的结果不依赖与父查询
    - [例3.56]查询选修了课程名为“信息系统”的学生学号和姓名。
      - 本查询涉及学号、姓名和课程名三个属性。学号和姓名存放在Student表中，课程名存放在Course表中，但Student与Course两个表之间没有直接联系，必须通过SC表建立它们二者之间的联系。所以本查询实际上涉及三个关系。
```
SELECT Sno，Sname         -- ③最后在Student关系中取出Sno和Sname
FROM Student
WHERE Sno IN(SELECT Sno           -- ②然后在SC关系中找出选修了3号课程的学生a学号FROM SC WHERE Cno IN(SELECT Cno          -- ①首先在Course关系中找出“信息系统”的课程号，结果为3号	   FROM CourseWHERE Cname='信息系统')
);
-- 用连接查询实现：
SELECT Student.Sno，Sname 
FROM Student，SC，Course 
WHERE Student.Sno=SC.Sno AND SC.Cno=Course.Cno AND Course.Cname='信息系统；
```
2. 带有比较运算符的子查询(p106)
  - 父查询与子查询之间用比较运算符进行连接.
  - 相关子查询:子查询的查询条件依赖于父查询，整个查询语句称为相关嵌套查询（correlated nested query）语句。
    - [例3.57]找出每个学生超过他自己选修课程平均成绩的课程号。
```
SELECT Sno，Cno 
FROM SC x 
WHERE Grade >=(SELECT AVG(Grade)    -- 某学生的平均成绩FROM SC y WHERE y.Sno = x.Sno);
```
  - 相关子查询由于子查询与父查询有关,必须反复求值,而不相关子查询由于子查询与父查询无关,所以可以子查询可以一次求解出来

3.5 数据更新

插入数据:INSERT

[例3.69]将一个新学生元组（学号：201215128，姓名：陈冬，性别：男，所在系：IS，年龄：18岁）插入到Student表中。

INSERT INTO Student（Sno，Sname，Ssex，Sdept，Sage）
VALUES('201215128','陈冬','男','IS',18);
-- 字符串要用单引号引出来,如果这里Student后面没有指明属性名,values后面的属性值必须与创建的表中的属性值对应.

修改数据:UPDATE
- [例3.73]将学生201215121的年龄改为22岁。
```
UPDATE Student SET Sage=22
WHERE Sno='201215121';
```
删除数据
- [例3.76]删除学号为201215128的学生记录。
```
DELETE FROM Student WHERE Sno = '201215128';
```

3.6 空值的处理

概念:
- 所谓空值就是“不知道”或“不存在”或“无意义”的值。空值是一个特殊的值,含有不确定性
判断:
- IS NULL 或 IS NOT NULL

3.7 视图

概念:

视图是由一个或几个基本表(或视图)导出的表,是个虚表,基本表的数据改变了,数据库中只存放视图的定义，而不存放视图对应的数据，这些数据仍存放在原来的基本表中。视图中的查询出来的数据也随之改变,视图就像一个窗口，透过它可以看到数据库中自己感兴趣的数据及其变化。视图处于外模式

定义视图

视图建立在基本表上

[例3.84]建立信息系学生的视图。

CREATE VIEW IS_Student 
AS 
SELECT Sno，Sname，Sage
FROM Student 
WHERE Sdept=IS;
-- 关系数据库管理系统执行CREATE VIEW语句的结果只是把视图的定义存入数据字典，并不执行其中的SELECT语句。只是在对视图查询时，才按视图的定义从基本表中将数据查出。

视图建立在已经定义好的视图上

[例3.87]建立信息系选修了1号课程且成绩在90分以上的学生的视图。

CREATE VIEW IS_S2
AS 
SELECT Sno，Sname，Grade 
FROM IS SI 
WHERE Grade>=9;
-- 表中一般只存放数据,由基本数据计算派生出来的数据一般是不存储的,而视图中不存放数据,所以一般用视图来定义派生列,这些列也称为虚拟列

删除视图

格式:DROP VIEW<视图名>[CASCADE]；

删除视图的时候,如果该视图上还导出了其他的视图,那么不能删除,需要在后面加CASCADE,即级联操作,进而把该视图和它导出的所有视图删除.

[例3.91]删除视图BT_S和视图IS_S1：

DROP VIEW BT_S; -- 成功执行
DROP VIEW IS_S1; -- 拒绝执行
-- 执行此语句时由于IS_S1视图上还导出了IS_S2视图，所以该语句被拒绝执行。如果确定要删除，则使用级联删除语句：
DROP VIEW IS S1 CASCADE; -- 删除了视图IS_S1和由它导出的所有视图

查询视图
1. 视图消解:(p124)从数据字典中取出视图的定义，把定义中的子查询和用户的查询结合起来，转换成等价的对基本表的查询，然后再执行修正了的查询。这一转发过程称为视图消解（view resolution）。（即将定义视图的条件加入进去）
  - [例3.92]在信息系学生的视图中找出年龄小于20岁的学生。
```
-- IS_Student视图
CREATE VIEW IS_Student 
AS 
SELECT Sno,Sname,Sage 
FROM Student 
WHERE Sdept='IS';
-- 在该视图上查询
SELECT Sno，Sage
FROM IS_Student 
WHERE Sage<20;
-- 经过视图消解转换后的查询语句为
SELECT Sno,Sage 
FROM Student 
WHERE Sdept='IS' AND Sage<20;
```
  - 视图消解实际上就是把视图的中定义的子查询查询出来的结果,再在查询视图的语句上根据上面的结果写出视图消解的后的转换语句

更新视图

视图IS_Student

-- IS_Student视图
CREATE VIEW IS_Student 
AS 
SELECT Sno,Sname,Sage 
FROM Student 
WHERE Sdept='IS';

修改

[例3.95]将信息系学生视图IS_Student中学号为“201215122”的学生姓名改为“刘辰”。

- UPDATE IS Student SET Sname='刘辰’WHERE Sno='201215122'; -- 转换后的更新语句为UPDATE Student SET Sname='刘辰’WHERE Sno='201215122' AND Sdept='IS';

插入

[例3.96]向信息系学生视图IS_Student中插入一个新的学生记录，其中学号为“201215129”，姓名为“赵新”，年龄为20岁。

INSERT 
INTO IS_Student 
VALUES('201215129','赵新',20);
-- 转换为对基本表的更新：
INSERT 
INTO Student (Sno，Sname，Sage.Sdept)
VALUES('201215129','赵新',20,'IS');
-- 这里系统自动将系名IS放入VALUES子句中。

删除

[例3.97]删除信息系学生视图IS_Student中学号为“201215129”的记录。

DELETE 
FROM IS Student 
WHERE Sno='201215129';
-- 转换为对基本表的更新;
DELETE 
FROM Student
WHERE Sno='201215129' AND Sdept='IS';

视图的作用
1. 视图能够简化用户的操作
2. 视图能使用户能以多种角度看待同一数据
3. 视图对重构数据库提供了一定程度的逻辑独立性
4. 视图能够对机密数据提供安全保护
5. 适当利用视图可以更清晰地表达查询

第四章数据库安全性

4.2 数据库安全性描述

安全性控制的方法:
1. 用户标示鉴定
2. 存取控制
3. 审计
4. 数据加密
5. 视图的保护

存储控制
1. 自主存储控制（Discretionary Access Control，DAC）
  - 主要是通过SQL的GRANT语句和REVOKE语句来实现
  1. 授权:GRANT
    - [例4.5]把对表SC的INSERT权限授予U5用户，并允许将此权限再授予其他用户。
```
GRANT INSERT
ON TABLE SC 
TO U5
WITH GRANT OPTION;
-- 执行此SQL语句后，U5不仅拥有了对表SC的INSERT权限，还可以传播此权限，即由U5用户发上述GRANT命令给其他用户。例如U5可以将此权限授予U6（例4.6）。
```
    - [例4.6]
```
GRANT INSERT 
ON TABLE SC 
TO U6
WITH GRANT OPTION;
-- 同样，U6还可以将此权限授予U7,以此类推....
```
    - 定义了WITH GRANT OPTION语句的用户可以授权给其他用户,但是不能循环授权,也就是后面的授予前面的(这就类比类中的静态内容,静态的内容是不能访问非静态内容的,因为静态内容先存在,非静态内容后存在,这里继承的用户的权限后存在,肯定是从先存在的用户那里继承过来的权限,所以后面的授权用户不能反过来授予前面的用户.)
  2. 取消授权:REVOKE
    - [例4.10]把用户U5对SC表的INSERT权限收回。
```
REVOKE INSERT 
ON TABLE SC 
FROM U5 CASCADE;
-- 将用户U5的INSERT权限收回的同时，级联（CASCADE）收回了U6和U7的INSERT权限，否则系统将拒绝执行该命令。
```
2. 强制存储控制(p148)（Mandatory Access Control，MAC）
  1. 在强制存取控制中，数据库管理系统所管理的全部实体被分为主体和客体两大类。
    1. 主体是系统中的活动实体，既包括数据库管理系统所管理的实际用户，也包括代表用户的各进程。
    2. 客体是系统中的被动实体，是受主体操纵的，包括文件、基本表、索引、视图等
  2. 强制存取控制是对数据本身进行密级标记，无论数据如何复制，标记与数据是一个不可分的整体，只有符合密级标记要求的用户才可以操纵数据，从而提供了更高级别的安全性。

4.3 视图机制

通过视图机制把要保密的数据对无权存取的用户隐藏起来，从而自动对数据提供一定程度的安全保护。
就是通过视图对不同的用户授予不同的权限
- 例题:用户杨兰具有从每个部门职工中SELECT最高工资、最低工资、平均工资的权限，他不能查看每个人的工资。
  首先建立一个视图。然后对这个视图定义杨兰的存取权限。
```
CREATE VIEW 部门工资
AS 
SELECT 部门.名称，MAX（工资）,MIN（工资）,AVG（工资）
FROM 职工，部门
WHERE 职工.部门号=部门.部门号
GROUP BY 职工.部门号; 
GRANT SELECT ON TABLE 部门工资 TO 杨兰;
```

第五章数据库完整性

5.1 实体完整性主属性

关系模型的实体完整性在CREATE TABLE中用PRIMARY KEY定义。
列级约束条件:定义在属性的后面
- ```
Sno CHAR(9) PRIMARY KEY
```
表级约束条件:单独成一行,使用语句单独定义
- ```
PRIMARY KEY(Sno)
```

5.2 参照完整性外码

关系模型的参照完整性在CREATE TABLE中用FOREIGN KEY短语定义哪些列为外码，用REFERENCES短语指明这些外码参照哪些表的主码

[例5.3]定义SC中的参照完整性。

CREATE TABLESC
(Sno CHAR（9）NOT NULL,Cno CHAR（4）NOT NULL,Grade SMALLINT,PRIMARY KEY（Sno，Cno）,-- 在表级定义实体完整性FOREIGN KEY（Sno）REFERENCES Student（Sno）,-- 在表级定义参照完整性FOREIGN   KEY（Cno）REFERENCES Course（Cno）-- 在表级定义参照完整性)

5.3 用户定义的完整性

属性上的约束条件
- 列值非空（NOTNULL）。
- 列值唯一（UNIQUE）。
- 检查列值是否满足一个条件表达式（CHECK短语）。

元组上的约束条件

[例5.9]当学生的性别是男时，其名字不能以Ms.打头。

CREATE TABLE Student
(Sno CHAR（9）,Sname CHAR（8）NOT NULL,Ssex CHAR（2）,Sage SMALLINT,Sdept CHAR（20）,PRIMARY KEY（Sno）,CHECK（Ssex='女'OR Sname NOT LIKE'Ms.%'）
);
-- 定义了元组中Sname和Ssex两个属性值之间的约束条件

第六章关系数据理论

范式NF(Normal Form)
1. 关系数据库中的关系是要满足一定要求的，满足不同程度要求的为不同范式。
2. 一个低一级范式的关系模式通过模式分解（schema decomposition）可以转换为若干个高一级范式的关系模式的集合，这种过程就叫规范化（normalization）。
1NF:符合1NF的关系中的每个属性都不可再分,1NF是所有关系型数据库的最基本要求。
2NF
- 2NF在1NF的基础之上，消除了非主属性对于候选码的部分函数依赖。
3FN
- 在2NF的基础之上，消除了非主属性对于候选码的传递函数依赖。
BCNF
- 在 3NF 的基础上消除主属性对于候选码的部分与传递函数依赖。

6.1 问题的提出

五元组 R( U D DOM F )
- 关系名R是符号化的元组语义。
- U为一组属性。
- D为属性组U中的属性所来自的域。
- DOM为属性到域的映射。
- F为属性组U上的一组数据依赖。
数据依赖是一个关系内部属性与属性之间的一种约束关系。
第一范式(1FN):
- 一个二维表必须达到第一范式,也就是每一个分量(属性)是不可以分割的
函数依赖:
- Sname=f(Sno)，即Sno函数决定Sname，S或者说Sname函数依赖于Sno，记作Sno->Sname，
什么是一个好的关系模式?
- 一个好的模式应当不会发生插入异常、删除异常和更新异常，数据冗余应尽可能少。
  - 插入异常:数据本该插入却插入不了,可能由于实体完整性的约束导致插入失败
  - 删除异常:数据本该留下,却在删除其他数据的同时删除了该数据
  - 更新异常:更新某个数据导致每个数据都要更新
  - 数据冗余:某些数据存在重复

6.2 规范化

函数依赖：若在一张表中，在属性（或属性组）X的值确定的情况下，必定能确定属性Y的值，那么就可以说Y函数依赖于X，写作 X → Y。即在数据表中，不存在任意两条记录，它们在X属性（或属性组）上的值相同，而在Y属性上的值不同。
- 在关系表中找到任意两个元组，在属性X上的值相等，而在属性Y上的值也相等，则有X->Y。
1. 完全函数依赖
  - 在一张表中，若 X → Y，且对于 X 的任何一个真子集（假如属性组 X 包含超过一个属性的话），X ’ → Y 不成立，那么我们称 Y 对于 X 完全函数依赖,用F表示(注：若决定因素只有一个属性，则必然是完全函数依赖。)
    - (学号,课名)–> 分数
      - 学号和课名同时才能决定分数,他们两个之间的任何一个都不行
2. 部分函数依赖
  - Y 函数依赖于 X，但同时 Y 并不完全函数依赖于 X，那么我们就称 Y 部分函数依赖于 X,用P表示
    - (学号,课号)–>姓名
      - 学号就可以决定姓名
3. 传递函数依赖
  - Z 函数依赖于 Y，且 Y 函数依赖于 X ,Y 不包含于 X，且 X 不函数依赖于 Y(如果这样,就会变成直接传递依赖),就称 Z 传递函数依赖于 X,用T表示
    - Sno–>Sdept, Sdept–>Mname, 则有: Sno–>Mname
4. 平凡函数依赖:当Y包含于X时，称X→Y为平凡的函数依赖。
5. 非平凡函数依赖:当Y不包含于X时，称X→Y为平凡的函数依赖。
码
1. 候选码:某一个属性组的值能够唯一的标识一个元组,而其子集不能,则称该属性组为候选码
2. 超码:在候选码基础上拓展的集合，候选码的超集一定是超码，且是最小的超码。
3. 主码:若一个关系中有多个候选码,则选定其中的一个为主码
4. 主属性:候选码属性组中的各个属性称为主属性
5. 非主属性:不包含在候选码中的属性称为非主属性
6. 全码:关系模式的所有属性是这个关系的候选码,则称该属性组为全码
- 例子:关系模式学生信息(学号、姓名、性别、系别、身份证号码)
  - 候选码:学号,身份证号码
  - 主码:学号或身份证号码
  - 主属性:学号和身份证号码
  - 非主属性:姓名、性别、系别
  - 注意:这里的候选码不能为(学号,身份证号码),因为其不符合候选码的定义,但是它是一个超码.
  - 学号可以唯一的标识出一个同学的身份，我们可以设置学号为主码。是最简单的候选码。
  - 注意:主属性不能唯一的标识一个元组,而主码必定能够标识(因为主码必定是候选码),两者是不同的.
范式NF(Normal Form)
1. 关系数据库中的关系是要满足一定要求的，满足不同程度要求的为不同范式。
2. 一个低一级范式的关系模式通过模式分解（schema decomposition）可以转换为若干个高一级范式的关系模式的集合，这种过程就叫规范化（normalization）。
3. 1NF
  - 符合1NF的关系中的每个属性都不可再分,1NF是所有关系型数据库的最基本要求。
4. 2NF
  - 属于1NF，且每一个非主属性完全函数依赖于码
  - 2NF在1NF的基础之上，消除了非主属性对于候选码的部分函数依赖。
5. 3NF
  - 每一个非主属性既不部分依赖于码也不传递依赖于码
  - 在2NF的基础之上，消除了非主属性对于候选码的传递函数依赖。
  - 推论：任何二元关系模式R（A，B）必为3NF。(没有非主属性必为3NF)
6. BCNF
  - 在 3NF 的基础上消除主属性对于候选码的部分与传递函数依赖。
  - 所有非平凡函数依赖左侧必包含候选码(每一个决定因素都包含码–即超码)
  - 满足的条件：
    1. 所有非主属性对每一个码都是完全函数依赖。
    2. 所有主属性对每一个不包含它的码也是完全函数依赖。（主属性之间满足完全函数依赖）
    3. 没有任何属性完全函数依赖于非码的任何一组属性。
7. 4NF
  - 在 BCNF 的基础上消除非平凡的且非函数依赖的多值依赖。
8. 多值依赖：X,Y,Z是U的子集，并且Z=U-X-Y。多值依赖X->->成立，并且仅当对R(U)的任一关系r，给定一对（x,z），有一组Y的值，仅仅决定于x的值而于z的值无关
  - 多值依赖的性质：
    
    （1）具有对称性
    
    （2）传递性
    
    （3）函数依赖可以看作是多值依赖的特殊情况，即若X->Y,则X->->Y
    
    （4）若X->->Y,X->->Z,则X->->YZ
    
    （5）若X->->Y,X->->Z,则X->->Y∩Z
    
    （6）若X->->Y,X->->Z,则X->->Y-Z,X->->Z-Y

判断是第几范式的方法:
1. 找出数据表中所有的候选码。
2. 根据第一步所得到的码，找出所有的主属性。
3. 数据表中，除去所有的主属性，剩下的就都是非主属性了。
4. 查看是否存在属性对候选码的部分函数依赖或者传递函数依赖。
  1. 非主属性不存在对候选码的部分函数依赖,2NF
  2. 非主属性不存在对候选码的部分函数依赖和传递函数依赖,3NF
  3. 在第三范式的基础上,主属性存在对候选码的传递函数依赖与部分函数依赖,BCNF
- 对于第一步:
  1. 查看所有每一单个属性，当它的值确定了，是否剩下的所有属性值都能确定。
  2. 查看所有包含有两个属性的属性组，当它的值确定了，是否剩下的所有属性值都能确定。
  3. 依次类推…
    - 技巧:如果某属性或属性组A确定为候选码,那么包含了A的属性组,如:(A,B),(A,C),(A,B,C)等等,都不是候选码了,因为候选码的子集必须不能唯一确定一个元组,候选码中不能有候选码,这样也矛盾了,这里的(A,B),(A,C),(A,B,C)是超码
- 例题:
  - 学生表(学号,姓名,系名,系主任,课名,分数)
    1. 候选码:(学号,课名)
    2. 主属性:学号,课名
    3. 非主属性:姓名,系名,系主任,分数
    4. 依赖关系:
      1. 对于**（学号，课名） → 姓名**，有 学号 → 姓名，存在非主属性姓名对码**（学号，课名）**的部分函数依赖。
      2. 对于**（学号，课名） → 系名**，有 学号 → 系名，存在非主属性系名对码**（学号，课名）**的部分函数依赖。
      3. 对于**（学号，课名） → 系主任**，有 学号 → 系主任，存在非主属性对码**（学号，课名）**的部分函数依赖。
  1. 所以存在非主属性对于码的部分函数依赖，最高只符合1NF的要求，不符合2NF的要求。
  2. 进行模式分解后有关系模式:
    - 选课（学号，课名，分数）
      学生（学号，姓名，系名，系主任）
    - 对于选课表:
      - 候选码:(学号,课名)
      - 主属性:学号,课名
      - 非主属性:分数
      - 依赖关系:学号确定，并不能唯一确定分数，课名确定，也不能唯一确定分数，所以不存在非主属性分数对于码 **（学号，课名）**的部分函数依赖，所以此表符合2NF的要求。
    - 对于学生表:
      - 候选码:学号
      - 主属性:学号
      - 非主属性:姓名、系名和系主任
      - 依赖关系:
        因为码只有一个属性，所以不可能存在非主属性对于码的部分函数依赖，所以此表符合2NF的要求。
    - 对于该表判断是否符合第三范式的要求
      - 对于选课表，主码为（学号，课名），主属性为学号和课名，非主属性只有一个，为分数，不可能存在传递函数依赖，所以选课表的设计，符合3NF的要求。
        
        对于学生表，主码为学号，主属性为学号，非主属性为姓名、系名和系主任。因为学号 → 系名，同时系名 → 系主任，所以存在非主属性系主任对于码学号的传递函数依赖，所以学生表的设计，不符合3NF的要求。
  3. 进一步进行模式分解
    - 选课（学号，课名，分数）
      学生（学号，姓名，系名）
      系（系名，系主任）
    - 对于选课表，符合3NF的要求，之前已经分析过了。
    - 对于学生表，码为学号，主属性为学号，非主属性为系名，不可能存在非主属性对于码的传递函数依赖，所以符合3NF的要求。
    - 对于系表，码为系名，主属性为系名，非主属性为系主任，不可能存在非主属性对于码的传递函数依赖（至少要有三个属性才可能存在传递函数依赖关系），所以符合3NF的要求。
- 某公司有若干个仓库；
  1. 每个仓库只能有一名管理员，一名管理员只能在一个仓库中工作；
  2. 一个仓库中可以存放多种物品，一种物品也可以存放在不同的仓库中。每种物品在每个仓库中都有对应的数量。
  - 那么关系模式仓库（仓库名，管理员，物品名，数量）属于哪一级范式？
    1. 候选码：（管理员，物品名），（仓库名，物品名）
    2. 主属性：仓库名、管理员、物品名
    3. 非主属性：数量
    4. 已知函数依赖集：仓库名 → 管理员，管理员 → 仓库名，（仓库名，物品名）→ 数量
      码：（管理员，物品名），（仓库名，物品名）
  - ∵ 不存在非主属性对候选码的部分函数依赖和传递函数依赖。∴ 此关系模式属于3NF。
  - 造成此问题的原因：存在着主属性对于候选码的部分函数依赖与传递函数依赖。（在此例中就是存在主属性【仓库名】对于码【（管理员，物品名）】的部分函数依赖。
    - 进行模式分解后:
      - 在 3NF 的基础上消除主属性对于候选码的部分与传递函数依赖。
      - 仓库（仓库名，管理员）
        库存（仓库名，物品名，数量）
  - 这就是BCNF范式.
- 存在关系模式 R（A，B，C）函数依赖F = {A->C, BC->D}，该关系模式达到第几范式？
  - AB为候选码，C为非主属性。 AB->C,又A->C故存在非主属性对候选码的部分函数依赖，故二范式达不到，即为一范式。

模式分解方法
- 在执行关系模式分解时，必须遵守的原则是：保持无损连接和原有函数依赖关系
规范化小结
- 基本思想:逐步消除数据依赖中不适合的部分
- 模式设计原则:“一事一地”
- 规范化的实质:概念的单一化
- 关系模式的规范化过程是通过对关系模式的分解来实现的，即把低一级的关系模式分解为若干个高一级的关系模式

6.3 数据依赖的公理系统

逻辑蕴涵：给定R<U，F>；如果从F能够推出X→Y，则称F逻辑蕴涵X→Y。
Armstrong公理系统
1. 推理规则：
  1. 自反律（reflexivity rule）：若Y⊆ X⊆ U，则X→Y为F所蕴涵。（自己决定自己以及自己的任何子集）
  2. 增广律（augmentation rule）：若X→Y为F所蕴涵，且Z⊆ U，则XZ→YZ为F所蕴涵。
  3. 传递律（transitivity rule）：若X→Y及Y→Z为F所蕴涵，则X→Z为F所蕴涵。
  4. 合并规则（union rule）：由X→Y，X→Z，有X→YZ。
  5. 伪传递规则（pseudo transitivity rule）：由X→Y，WY→Z，有XW→Z。
  6. 分解规则（decomposition rule）：由X→Y及Z⊆ Y，有X→Z。
2. 有效性：由F出发根据Armstrong公理推导出来的每一个函数依赖一定在F+中；
  
  完备性：指的是F+中的每一个函数依赖，必定可以由F出发根据Armstrong公理推导出来。
模式分解的算法：
1. 若要求分解保持函数依赖，那么模式分离总可以达到3NF，但不一定能达到BCNF。
2. 若要求分解既保持函数依赖，又具有无损连接性，可以达到3NF，但不一定能达到BCNF。
3. 若要求分解具有无损连接性，那一定可达到4NF。

闭包：

函数依赖集的闭包：关系模式R<U，F>中为F所逻辑蕴含的函数依赖的全体所构成的集合称作F的闭包。
属性基于函数依赖的闭包：由F推导出来的某个属性集X所决定的某个属性的集合称为属性集的闭包。(由当前属性集经函数依赖集F推出得到的属性集)
设F为属性集U上的一组函数依赖，X、Y⊆ U，X→Y能由F根据Armstrong公理导出的充分必要条件是Y⊆ X的闭包。即求X->Y等价于转化为判断X的闭包是否包含Y。
作用：
- 判断A->B中A是否为超码，通过计算 $A^+_F$ ，看 $A^+_F$ 是否包含了R中的所有属性。若是，则A为R的超码。
- 通过检验是否B⊆ $A^+_F$ ，来验证函数依赖是否成立。即计算 $A^+_F$ ，看它是否包含B。

求法：

初始化所求闭包
从左到右依次扫描各个函数依赖
将左侧包含于闭包中的函数依赖的右侧并入构成新闭包
若扫描一轮后发现该轮闭包发生变化则进行新的一轮扫描，若闭包没变或者达到全集则停止扫描

【例1】R<U，F>，U =（A，B，C，D，E），F=（AB→CD，CE→A，AE→CD），计算 $AE_F^+$

轮次	扫描的函数依赖	$AE_F^+$
		AE(初始化所求闭包)
1	AB->CD	AE
	CE->A	AE
	AE->CD	ACDE(发现左侧AE在闭包中，将右侧CD加入闭包。扫描完毕闭包由AE变为ACDE，开启新一轮扫描)
2	AB->CD	ACDE
	CE->A	ACDE
	AE->CD	ACDE(扫描完毕，发现闭包没变，则终止扫描

【例2】R<U，F>，U =（A，B，C，G，H，I），F= ( B→H，CG→HI，A→BC），计算 $AG_F^+$

轮次	扫描的函数依赖	$AG_F^+$
		AG(初始化所求闭包)
1	B→H	AG
	CG→HI	AG
	A->BC	ABCG(发现左侧A在闭包中，将右侧BC加入闭包。扫描完毕闭包由AG变为ABCG，开启新一轮扫描)
2	B->H	ABCGH
	CG→HI	ABCGHI (发现闭包已经等于全集U，则提前终止。)

注：从属性的角度理解：如(学号A，姓名B)->性别C，学号A->年龄D，则有：(学号A，姓名B)->(性别C，年龄D)
简单方法： $AG_F^+$ = {AGBCHI} ；{AG}，A->BC将BC加入，此时有{AGBC}，B->H 加入H，此时有{AGBCH}，CG->HI,加入I。

极小函数依赖集
1. 满足的条件
  
  （1）F中任一函数依赖的右部仅含有一个属性。（单属性化）
  （2）F中不存在这样的函数依赖X→A，使得F与F - (X→A)等价。（F中的函数依赖均不能由F中其他函数依赖导出 无冗余化）
  （3）F中不存在这样的函数依赖X→A，X有真子集Z使得F -（X→A）U（Z→A）与F等价。（F中的各函数依赖左部均为最小属性集 即约化）
2. 求法：
  1. 应用分解规则，使F中每一个依赖的右部属性单一化。（右部属性单一化）
  2. 去掉多余的依赖。具体做法是：从第一个依赖开始，从F中去掉它（假设该依赖为X→Y），然后在剩下的依赖中求X+，看X+是否包含Y，若是，则去掉X→Y；若不包含Y，则不能去掉X→Y。（消除冗余函数依赖）
  3. 去掉各依赖左部多余的属性。具体做法是：一个一个地检查F中左边是非单属性的依赖，例如XY→A.现在要判断Y是否为多余的，即以X→A代替XY→A是否等价。只要在F中求X+，若X+包含A，则Y是多余的属性；否则Y不是多余属性。依次判断其他属性即可消除各依赖左边的多余属性。（消除左部属性的冗余）
    - 例：AB->C 假设去掉A，看B->C是否成立(即求B的闭包)，若成立则A可以去掉。若不成立则假设去掉B，看A->C是否成立,成立则证明B多余则可以去掉。
3. 例题：
正则覆盖
1. 定义： $F_C$ 是一个依赖集， $F_C$ 有如下性质：
  1. $F_C$ 中任何函数依赖都不含有无关属性。
  2. $F_C$ 中函数依赖的左半部都是唯一的。即 $F_C$ 中不存在两个依赖α1 → β1和α2 → β2，满足α1 = α2 。
2. 求法：
  1. 求出最小依赖集
  2. 左部相同属性函数依赖合并
3. 对上方例题：求出 $F_m$ ={B→D,DG→C,B→E,AG→B}，将左部相同属性的函数依赖合并有： $F_c$ ={B→DE,DG→C,AG→B}
4. 正则覆盖与最小函数依赖的区别：最小函数依赖集的右端必然只有一个属性，但正则覆盖无需。
候选码的求法
1. 若X为候选码，则必须满足两个条件：X的闭包是U且X没有冗余。
2. 定理：对于给定的关系模式R及其函数依赖集F
  （1）若X（X∈R）是L类属性，则X必为R的任一候选键的成员。
  （2）若X（X∈R）是L类属性，且 $X^+$ 包含了R的全部属性，则X必为R的唯一候选码。
  （3）若X（X∈R）是R类属性，则x不在任何候选键中。
  （4）若X（X∈R）是N类属性，则X必为R的任一候选码的成员。
  （5）若X（X∈R）是R的N类和L类属性组成的属性集，且 $X^+$ 包含了R的全部属性，则X是R的唯一候选码。
  （6）若X（X∈R）是时LR类属性，则x可能为R的任一候选码的成员，也可能不为R的任一候选码的成员。
  
  注：
  - L类,仅出现在F的函数依赖左部的属性。
  - R类,仅出现在F的函数依赖右部的属性。
  - N类,在F的函数依赖左部和右部均未出现的属性。
  - LR类,在F的函数依赖左部和右部两部均出现的属性。
3. 求法：
  - （1）属性分类（L、R，N和LR），X代表L类和N类属性，Y代表LR类属性。
    （2）若 $X^+$ 包含了R的全部属性，转(5)；否则，转(3)。
    （3）在Y中取一个属性A，求 $XA^+$ ，若它包含了R的全部属性，则转(4)；否则，调换一属性反复进行这一过程，直到试完所有Y中的属性。
    （4）如果已找出所有候选码，则转(5)；否则在Y中依次取两个属性三个属性…，求它们的属性集的闭包，直到其闭包包含R的全部属性。(注：单个属性选择完不用再取两个属性了，因为会发生冗余，候选码真子集不能为候选码)
    （5）停止，输出结果。
  - 分别列出L, LR, R, N 类属性，将L中的属性和N中的属性组合，求闭包，若为全集，则为候选码。否则将LR中的属性依次单个加入其中求闭包直到得到全集。
4. 例题：
  - 设有关系模式R（A，B，C，D，E，F）与它的函数依赖集F=（A→F，B→A，D→B，DE→B，DF→B）求R的所有候选码。
    
    L:D,E
    LR:A,B,F
    R:无
    N:C
    求DEF的闭包： $DEC^+$ = {DECBA}=U 故DEF为唯一候选码。
模式分解
1. 第三范式分解
  1. 保持函数依赖分解为3NF
    - 求正则覆盖 $F_C$
    - 每个依赖单独构成一个关系模式
  2. 保持函数依赖和无损连接性分解为3NF
    - 先分解为保持函数依赖的3NF
    - 查看分解后的关系模式是否包含候选码，不包含则以候选码作为一个单独的关系模式加入进去。
  3. 例题：
    1. R(U,F): U = {ABCD},F = {AB→C,C→D,D→A}
      - L类属性B， $B^+$ ={B}，所以候选码不唯一，候选码AB，BC， BD
      - R属于3NF
    2. R(U,F): U = {ABCD},F={B→C,B→D}
      - L类属性B，N类属性A，候选码AB
      - R不属于3NF
      - Fc={B→CD}
      - 分解为{ (BCD)、(AB) }
    3. R(U,F) : U = {ABCD},F={AB→C,BC→D,CD→A,AD→B}
      - 属于BDNF，也属于3NF
    4. R(U,F) : U = {ABCDE},F={AB→C,DE→C,B→D}
      - 候选码是ABE，不是3NF
      - F中没有无关属性，不需要合并，F既是Fc
      - 分解为{ (ABC)、(DEC)、 (BD)、 (ABE) }
    5. R(U,F): U = {ABCDEF},F= {A→B,C- >DF,AC-→E,D→F}
      - 候选码是AC，不属于3NF
      - Fc={A→B、 C→D、AC- >E、D- >F}
      - 分解为{ (AB)、(CD)、(ACE)、 (DF) }(候选码AC在关系模式ACE中了，故无需添加)
2. BCNF范式分解
  1. 方法
    1. 寻找关系模式中属性α的闭包，如果这个属性的闭包没有包含R中所有属性(即不为超码)，且为非平凡函数依赖，则需要拆解，否则直接构建新的关系模式。(判断是否是BCNF，不是则以这个函数依赖分解)
    2. 分解方法：
      - 非平凡函数依赖α→β，将原来R变为R-β，并构造一个新的关系模式α∪β，即分解为R1(αβ), R2(R-β)
      - 若分解后的关系模式为BCNF则无需继续分解，否则继续分解直到全部分解完毕。
      - 注：该算法只能保持无损连接分解。
  2. 例题
    1. R(U,F):U = {ABCD},F= {B→C,B→D}
      - $B^+_F$ ={CD}, 故B不是超码
      - 不属于BCNF
      - 分解方案:
        R1(BC), R2(ABD)
        R1(BC), R21(BD), R22(AB)
    2. R(U,F): U = {ABCD},F= {AB→C，BC→D, CD→A, AD→B}
      - AB，BC，CD，AD的闭包阶为全集
      - 属于BCNF
    3. R(U,F): U = {ABCDE},F={AB→C,DE→C,B→D}
      - 不属于BCNF
      - 分解方案:
        R1(ABC), R2(ABDE)
        R1(ABC), R21(BD), R22(ABE)
        属于BCNF
    4. R(U,F):∪= {ABCDEF},F={A→B,C→DF,AC→E,D→F}
      - 不属于BCNF
      - 分解方案1 :
        R1(AB), R2(ACDEF)
        R1(AB), R21(CDF), R22(ACE)
        R1(AB), R211(DF), R212(CD), R22(ACE)
      - 分解方案2 :
        R1(AB), R2(ACDEF)
        R1(AB), R21(DF), R22(ACDE)
        R1(AB), R21(DF), R221(CD), R222(ACE)
  3. 3NF与BCNF范式判断的简便方法
    1. 3NF判断
      - 对于 R 上的每个函数依赖 X->A, 以下条件中至少一个成立：
      1. X->A为平凡函数依赖即A ⊆ X
      2. X为超码
      3. A是R的候选码的一部分
      - 先找出候选码，再用上面的结论
    2. BCNF判断
      - 对于 R 上的每个函数依赖 X->A, 以下条件中至少一个成立：
        X->A为平凡函数依赖即A ⊆ X
        X为超码
      - 直接对每个函数依赖的左部属性(集)求闭包(也就是判断决定因素是否为超码)，只要有一个的闭包不为全集则不为BCNF范式。
    3. 例题：考虑一个具有五个属性的关系R，U = {ABCDE}, F={A-> B, BC-> E, ED-> A}
      1. 求R的所有候选码
        
        L：C，D
        
        LR：A，B
        
        R：E
        
        N：
        
        $ACD^+$ = {A、C、D、B、E} = U
        $BCD^+$ = {B、C、D、E、A} = U
        $ECD^+$ = {E、D、C、A、B} = U
        
        故候选码为ACD、BCD、CDE
      2. 判断R是否为3NF
        
        对A->B，B为候选码的一部分
        对BC->E，E为候选码的一部分
        对ED->A，A为候选码的一部分
        所以 R 是 3NF
      3. 判断R是否为BCNF
        
        对于A->B A不为超码且A->B不是平凡函数依赖
        对于BC->E BE不为超码且BC->E不是平凡函数依赖
        对于ED->A ED不为超码且ED->A不是平凡函数依赖
        所以 R 不是 BCNF(实际只需判断一个函数依赖不满足就可)

第七章数据库的设计

7.1 数据库设计概述

数据库设计
- 广义的讲:是数据库及其应用系统的设计，即设计整个数据库应用系统；
- 狭义的讲:是设计数据库本身，即设计数据库的各级模式并建立数据库;
数据库设计的基本步骤
1. 需求分析； -->数字词典,数据结构的描述
2. 概念结构设计；–>E-R图
3. 逻辑结构设计； -->将E-R图转化为对应的关系表
4. 物理结构设计； -->存储安排.存储路径的建立
5. 数据库实施； -->创建数据模式,装入数据,数据库试运行
6. 数据库运行和维护。 -->性能检测,数据库重组和重构.
数据库的各级模式
1. 外模式:视图
2. 逻辑模式:基本表
3. 内模式:物理结构

7.2 需求分析

数据词典
- 内容:数据字典的内容通常包括数据项、数据结构、数据流、数据存储和处理过程5个部分
- 作用:数据字典是关于数据库中数据的描述，在需求分析阶段建立，是下一步进行概念设计的基础，并在数据库设计过程中不断修改、充实和完善。

7.3 概念结构设计

E-R图的集成
1. 步骤
  1. 合并(消除冲突)
  2. 修改和重构(消除不必要的冗余)
E-R图之间的冲突
1. 属性冲突
2. 命名冲突
3. 结构冲突
- 在初步E-R图中可能存在一些冗余的数据和实体间冗余的联系。所谓冗余的数据是指可由基本数据导出的数据，冗余的联系是指可由其他联系导出的联系。冗余数据和冗余联系容易破坏数据库的完整性，给数据库维护增加困难，应当予以消除。消除了冗余后的初步E-R图称为基本E-R图。
- E-R图中描述两个实体之间的关系，可以先假定其中一个实体只有一个，再判断另外的一个实体对应的个数，反过来再判断。

7.4 逻辑结构设计

E-R图向关系模式的转换
1. 1:1
  1. 将联系转换成一个独立的关系模式，关系模式的名称为联系的名称。联系的属性包括该联系的属性和关联两个实体的主键，联系的主键为任意两个关联实体的主键之一。
  2. 将联系的属性归并到关联的两个实体的任一方，并将那一方实体集的主键加过来作为外键。
  - 例子:一个公司有一个经理，一个经理也只能在一个公司进行任职，所以公司和经理之间是一对一的关系。公司（公司编号，公司名，地址，电话），经理（职工编号，姓名，性别，电话）。经理任职会产生任职日期属性。
    - 转换为关系模式：
      1. 公司（公司编号，公司名，地址，电话）
        
        经理（职工编号，姓名，性别，电话）
      任职（公司编号，职工编号，任职日期）主键为公司编号或者是职工编号
      1. （1）公司（公司编号，公司名，地址，电话，职工编号，任职日期）主键为公司编号，外键为职工编号
      经理（职工编号，姓名，性别，电话）
```
（2）公司（公司编号，公司名，地址，电话） 
```
      经理（职工编号，姓名，性别，电话，公司编号，任职日期）主键为职工编号，外键为公司编号。
2. 1:n
  1. 将联系转换成一个独立的关系模式：名称为联系的名称，关系模式的属性两个实体的主键，联系的主键是多方（n方）实体集的主键。
  2. 将联系的属性和1端的主键加入多方（n方）
  - 例子:一个部门中有多个员工，但是每个员工只能属于一个部门，所以部门和员工之间的关系就是一对多。部门（部门号，部门名称，电话），员工（员工号，姓名，电话）。
    - 转换为关系模式：
      1. 1方：部门（部门号，部门名称，电话）
        
        n方：员工（员工号，姓名，电话）
        隶属（员工号，部门号）主键是n方
      2. 部门（部门号，部门名称，电话）
        
        员工（员工号，姓名，电话，部门号）主键为员工号，外键为部门号
3. M:N
  1. 多对多的联系只能转换成一个独立的关系模式，关系模式的名称取联系的名称，关系模式的属性取该联系所关联的所有实体集的主键和自身的属性，关系模式的主键由所有关联的实体集共同组成。
  - 例子:学生（学号，姓名，性别），课程（课程号，课程名称，授课老师）。
    - 转换为关系模式：
      1. 学生（学号，姓名，性别）
        
        课程（课程号，课程名称，授课老师）
        
        选课（学号，课程号，成绩）主键为学号和课程号的组合，外键为课程号，学号
数据模型的优化
1. 数据库逻辑设计不是唯一的
2. 并不是规范化程度越高的关系就越优
3. 模式分解
  1. 水平分解:水平分解是把（基本）关系的元组分为若干子集合，定义每个子集合为一个子关系，以提高系统的效率。根据“80/20原则”.
  2. 垂直分解:垂直分解是把关系模式R的属性分解为若干子集合，形成若干子关系模式。

7.5 物理结构设计

设计步骤
1. 确定数据库的物理结构，在关系数据库中主要指存取方法和存储结构
2. 对物理结构进行评价，评价的重点是时间和空间效率。
设计的内容:为关系模式选择存取方法，以及设计关系、索引等数据库文件的物理存储结构。

7.6 数据库的实施和维护

数据库应用程序的设计应该与数据库设计同时进行
数据库的试运行
1. 应分期分批地组织数据入库，先输入小批量数据做调试用，待试运行基本合格后再大批量输入数据，逐步增加数据量，逐步完成运行评价。
2. 要做好数据库的转储和恢复工作。一旦故障发生，能使数据库尽快恢复，尽量减少对数据库的破坏。

第八章数据库编程

游标
1. 概念
2. 使用步骤
3. 作用

第九章关系查询处理和查询优化

9.1 关系数据库系统的查询处理

查询处理步骤
1. 查询分析：词法分析、语法分析
2. 查询检查：安全性、完整性检查
3. 查询优化：代数优化、物理优化
4. 查询执行：代码生成

9.2 关系数据库系统的查询优化

试述关系数据库管理系统查询优化的一般准则。
1. 选择运算应尽可能先做。
2. 把投影运算和选择运算同时进行。
3. 把投影同其前或其后的双目运算结合起来执行。
4. 把某些选择同在它前面要执行的笛卡儿积结合起来成为一个连接运算。
5. 找出公共子表达式。
6. 选取合适的连接算法。
▲试述关系数据库管理系统查询优化的一般步骤。

①把查询转换成某种内部表示，通常用的内部表示是语法树。
②把语法树转换成标准（优化）形式，即利用优化算法把原始的语法树转换成优化的形式。
③选择低层的存取路径。
④生成查询计划，选择所需代价最小的计划加以执行。

第十章数据库恢复技术

10.1 事务的基本概念

事务：所谓事务是用户定义的一个数据库操作序列，这些操作要么全做，要么全不做，是一不可分割的工作单位。
定义事务的语句:
1. BEGIN TRANSACTION;
  - 开启事务
2. COMMIT;
  - 提交事务;提交事务的所有操作。正常结束
3. ROLLBACK;
  - 回滚事务:系统将事务中对数据库的所有已完成的操作全部撤销，回滚到事务开始时的状态。 异常终止
事务的ACID特性(ACID properties)
1. 原子性(Atomicity)
  - 是事务中的事情要么都做,要么都不做
2. 一致性(Consistency)
  - 事务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态.
    - 一致性状态：当数据库只包含成功事务提交的结果时，就说数据库处于一致性状态。
3. 隔离性(Isolation)
  - 一个事务的执行不能被其他事务干扰
4. 持续性(Durability)
  - 指一个事务一旦提交,它对数据库中数据的改变就应该是永久性的.

10.3 故障的种类

事务内部的故障
- 事务内部故障可分为预期的和非预期的，其中大部分的故障都是非预期的。预期的事务内部故障是指可以通过事务程序本身发现的事务内部故障;非预期的事务内部故障是不能由事务程序处理的，如运算溢出故障、并发事务死锁故障、违反了某些完整性限制而导致的故障等。
系统故障
- 系统故障也称为软故障，是指数据库在运行过程中，由于硬件故障、数据库软件及操作系统的漏洞、突然停电灯情况，导致系统停止运转，所有正在运行的事务以非正常方式终止，需要系统重新启动的一类故障。这类事务不破坏数据库，但是影响正在运行的所有事务。
介质故障
- 介质故障也称为硬故障，主要指数据库在运行过程中，由于磁头碰撞、磁盘损坏、强磁干扰、天灾人祸等情况，使得数据库中的数据部分或全部丢失的一类故障。
计算机病毒
- 计算机病毒故障是一种恶意的计算机程序，它可以像病毒一样繁殖和传播，在对计算机系统造成破坏的同时也可能对数据库系统造成破坏(破坏方式以数据库文件为主)。

10.4 恢复的实现技术

数据恢复的基本原理：冗余
- 建立冗余数据的常用技术为数据转储和登记日志文件。
数据转储

转储即数据库管理员定期地将整个数据库复制到磁带、磁盘或其他存储介质上保存起来的过程。这些备用的数据称为后备副本（backup）或后援副本。
静态转储:是在系统中无运行事务时进行的转储操作。
动态转储:是指转储期间允许对数据库进行存取或修改。即转储和用户事务可以并发执行。
方法
1. 动态海量转储
  1. 动态增量转储
  2. 静态海量转储
  3. 静态增量转储
    1. 海量转存:指每次转储全部数据库
    2. 增量转存:指每次只转储上一次转储后更新过的数据

登记日志文件
1. 内容:日志文件是用来记录事务对数据库更新操作的文件
  2. 日志文件的作用
  - （1）事务故障恢复和系统故障恢复必须用日志文件。
  （2）在动态转储方式中必须建立日志文件，后备副本和日志文件结合起来才能有效地恢复数据库。
  （3）在静态转储方式中也可以建立日志文件，当数据库毁坏后可重新装入后援副本把数据库恢复到转储结束时刻的正确状态，然后利用日志文件把已完成的事务进行重做处理，对故障发生时尚未完成的事务进行撤销处理。这样不必重新运行那些已完成的事务程序就可把数据库恢复到故障前某一时刻的正确状态.。
2. 登录日志文件必须遵守的两条规则
  1. 登记的次序严格按并发事务执行的时间次序。
  1. 必须先写日志文件，后写数据库。(防止破坏一致性)

10.5 恢复策略

事务故障的恢复
1. 反向扫描文件日志（即从最后向前扫描日志文件），查找该事务的更新操作。
2. 对该事务的更新操作执行逆操作。即将日志记录中“更新前的值”写入数据库。
  - 插入操作，“更新前的值”为空，则相当于做删除操作。
  - 删除操作，“更新后的值”为空，则相当于做插入操作。
  - 修改操作，则相当于用修改前值代替修改后值。
3. 继续反向扫描日志文件，查找该事务的其他更新操作，并做同样处理。
4. 如此处理下去，直至读到此事务的开始标记，事务故障恢复就完成了。
系统故障的恢复
1. 正向扫描日志文件（即从头扫描日志文件），找出在故障发生前已经提交的事务，加入重做队列，找出故障发生时尚未完成的事务，加入撤销队列。
2. 对撤销队列事务进行撤销处理反向扫描日志文件，对每个撤销事务的"作执行逆操作，即将日志记录中“更新前的值”写入数据库。
3. 对重做队列事务进行重做处理正向扫描日志文件，对每个重做事务重新执行登记的操作，将日志记录中“更新后的值”写入数据库。
介质故障的恢复
1. 装入最新的数据库后备副本（离故障发生时刻最近的转储副本），使数据库恢复到最近一次转储时的一致性状态。
2. 装入转储结束时刻的日志文件副本。
3. 启动系统恢复命令，由DBMS完成恢复功能，即重做已完成的事务。
登记日志文件时为什么必须先写日志文件后写数据库？
- 如果先写了数据库修改，而在运行记录中没有登记这个修改，则以后就无法恢复这个修改了。如果先写日志，但没有修改数据库，在恢复时只不过是多执行一次UNDO操作，并不会影响数据库的正确性。
什么是数据库镜像？它有什么用途？
- 数据库镜像即根据DBA的要求，自动把整个数据库或者其中的部分关键数据复制到另个磁盘上。每当主数据库更新时，DBMS自动把更新后的数据复制过去，即DBMS自动保证镜像数据与主数据的一致性。
- 数据库镜像的用途：
  1. 用于数据库恢复。当出现介质故障时，镜像磁盘可继续使用，同时DBMS自动利用镜像磁盘数据进行数据库的恢复，不需要关闭系统和重装数据库副本。
  2. 提高数据库的可用性。在没有出现故障时，当一个用户对某个数据加排他锁进行修改时，其他用户可以读镜像数据库上的数据，而不必等待该用户释放锁

第十一章并发控制

11.1 并发控制概述

事务是并发控制的基本单位,并发控制可以保证事务的一致性和隔离性，封锁是实现并发控制的主要技术。
并发控制带来的数据不一致性包括:
1. 丢失修改
  - 两个事务T1和T2读入同一数据并修改，T2提交的结果破坏了T1提交的结果，导致T1的修改被丢失
2. 不可重复读
  - 指事务T1读取数据后，事务T2执行更新操作，使T1无法再现前一次读取结果。
3. 读脏数据
  - 指事务T1修改某一数据并将其写回磁盘，事务T2读取同一数据后，T1由于某种原因被撤销，这时被T1修改过的数据恢复原值(ROLLBACK 恢复到原来的数据值)，T2读到的数据就与数据库中的数据不一致，则T2读到的数据就为“脏”数据，即不正确的数据。

11.2 封锁

概念：封锁就是事务T在对某个数据对象例如表、记录等操作之前，先向系统发出请求，对其加锁。加锁后事务T就对该数据对象有了一定的控制，在事务T释放它的锁之前，其他的事务不能更新或读取此数据对象。
基本的封锁类型
1. 排他锁(exclusive locks),简称X锁,又称写锁
  - 若事务T对数据对象A加上X锁，则只允许T读取和修改A，其他任何事务都不能再对A加任何类型的锁，直到T释放A上的锁为止。这就保证了其他事务在T释放A上的锁之前不能再读取和修改A。
2. 共享锁(share locks),简称S锁,又称读锁
  - 若事务T对数据对象A加上S锁，则事务T可以读A但不能修改A，其他事务只能再对A加S锁，而不能加X锁，直到T释放A上的S锁为止。这就保证了其他事务可以读A，但在T释放A上的S锁之前不能对A做任何修改。

11.3 封锁协议

一级封锁协议：事务T在修改数据R之前必须先对其加X锁，直到事务结束才释放。
二级封锁协议：在一级封锁协议基础上増加事务T在读取数据R之前必须先对其如S锁，读完后即可释放S锁。
三级封锁协议：在一级封锁协议的基础上増加事务T在读取数据R之前必须先对其加S锁，直到事务结束才释放。
- 注：在二级封锁协议中，由于读完数据后即可释放S锁，所以它不能保证可重复读。（读完后数据可能被修改，再读数据发生变化）
- 写时加X锁，事务结束后解锁。– 一级封锁协议
  
  读时加S锁，读完立即解锁。– 二级封锁协议
  
  读时加S锁，事务结束后解锁。 – 三级封锁协议

11.4 活锁和死锁

类比操作系统中的活锁和死锁的问题…

活锁:
1. 定义:一个事务等待时间太长，似乎被锁住了，实际上可能被激活。
2. 解决办法:先来先服务的策略,类比操作系统的FCFS调度算法…
死锁
1. 定义：多个事物之间互相请求对方的资源而等待，导致永不结束
2. 死锁的预防：
  1. 一次封锁法：要求每个事务必须一次将所有要使用的数据全部加锁否则就不能继续执行。
  2. 顺序封锁法：预先对数据对象规定一个封锁顺序所有书屋都按这个顺序实行封锁。
3. 死锁的诊断与解除
  1. 与操作系统类似，一般使用超时法或事务等待图法。
  2. DBMS并发控制子系统检测到死锁后，就要设法解除。通常采用的方法是选择一个处理死锁代价最小的事务，将其撤销，释放此事务持有的所有锁，使其他事务得以继续运行下去。

11.5 可串行化调度

定义：多个事务的并发执行时正确的，当且仅当其结果与按某一次序串行地执行这些事务时的结果相同。（并发执行结果 = 串行执行结果）
可串行性是并发事务正确调度的准则。
冲突可串行化调度
1. 冲突操作：指不同的事务对同一个数据的读写操作和写写操作。
2. 冲突可串行化：一个调度Sc在保证冲突操作的次序不变的情况下，通过交换两个事务不冲突操作的次序得到另一个调度Sc’，如果Sc’是串行的，称调度Sc为冲突可串行化的调度。
3. 冲突可串行化调度⇨可串行化调度

11.6 两段锁协议

所谓两段锁协议是指所有事务必须分两个阶段对数据项加锁和解锁。（一次性对所需封锁数据进行封锁）
- 在对任何数据进行读、写操作之前，首先要申请并获得对该数据的封锁；
- 在释放一个封锁之后，事务不再申请和获得任何其他封锁。
“两段”锁的含义是事务分为两个阶段:
1. 第一阶段是获得封锁，也称为扩展阶段，在这个阶段，事务可以申请获得任何数据项上的任何类型的锁，但是不能释放任何锁；
2. 第二阶段是释放封锁，也称为收缩阶段，在这个阶段，事务可以释放任何数据项上的任何类型的锁，但是不能再申请任何锁。
  - 例如，事务T，遵守两段锁协议，其封锁序列是
    Slock A Slock B Xlock C Unlock B Unlock A Unlock C；
    |<一扩展阶段一 > | |<一收缩阶段一>|
  - 又如，事务T，不遵守两段锁协议，其封锁序列是
    Slock A UnlockA Slock B Xlock C Unlock C UnlockB；
两段锁协议⇨可串行化调度
一次封锁法要求每个事务必须依次将所有要使用的数据全部加锁，因此遵守两段锁协议；但是两段锁协议并不要求事务必须一次将所有要使用的数据全部加锁，因此遵守两段锁协议的事务可能发生死锁。

11.7 封锁的粒度

概念:封锁的大小称为封锁的粒度
- 封锁的粒度越大，数据库所能够封锁的数据单元就越少，并发度就越小，系统开销也越小；
- 封锁的粒度越小，并发度较高，但系统开销也就越大。
多粒度封锁：
1. 多粒度树：多粒度树的根结点是整个数据库，表示最大的数据粒度。叶结点表示最小的数据粒度(一般为元组)。
2. 多粒度封锁协议：对多粒度树的每个结点独立地加锁，对一个结点加锁意味着对这个结点的所有后裔结点也被加以同样的锁。
  1. 显式封锁：应事务的要求直接加到数据对象上的锁；
  2. 隐式封锁：该数据对象没有被独立加锁，是由于其上级结点加锁而使该数据对象加上了锁。
意向锁：如果对一个结点加意向锁，则说明该结点的下层结点正在被加锁。

附录一概念总结

关系代数的五种基本操作
1. 并（Union）：设关系R和关系S具有相同的元数n，且相应的属性取自同一个域，则关系R和关系S的并由属于R或属于S的元组组成，其结果仍为n元的关系
2. 差（Difference）：设关系R和关系S具有相同的元数n，且相应的属性取自同一个域，则关系R和关系S的差由属于关系R而不属于关系S的元组组成，其结果仍为n元的关系
3. 笛卡尔积（Cartesian Product）：设关系R和关系S的元数分别为r和s。定义R和S的笛卡尔积是一个(r+s)元的元组集合，每个元组的前r个分量来自R的一个元组，后s个分量来自S的一个元组
4. 投影（Projection）：对关系进行垂直分割，消去某些列，并重新安排列的顺序，再删去重复元组
5. 选择（Selection）：根据某些条件对关系做水平分割，即选择符合条件的元组
四种组合操作
1. 交（Intersection）：设关系R和关系S具有相同的元数n，且相应的属性取自同一个域，则关系R和关系S的交由既属于关系R又属于关系S的元组组成，其结果仍为n元的关系。关系的交可以由关系的差来表示。
2. 连接（Join）：连接操作是笛卡尔积和选择操作的组合。
3. 自然连接（Natural Join）：是一种特殊的等值连接，它要求两个关系中进行比较的分量必须是相同的属性组，并且要在结果中把重复的属性去掉。
4. 除（Division）：设两个关系R和S的元数分别为r和s(设r>s>0)，那么R除S是一个(r-s)元的元组的集合。它是满足下列条件的最大关系：其中每个元组t与S中的每个元组u组成的新元组<t,u>必在关系R中。除运算是笛卡尔积的逆运算。
传统的集合运算
- 并，差，交，笛卡尔积
专门的关系运算
- 选择,投影,连接,除运算等
事务的特点
1. 原子性(Atomicity)
  - 是事务中的事情要么都做,要么都不做
2. 一致性(Consistency)
  - 事务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态.
3. 隔离性(Isolation)
  - 一个事务的执行不能被其他事务干扰
4. 持续性(Durability)
  - 指一个事务一旦提交,它对数据库中数据的改变就应该是永久性的.
数据库的三级结构
1. 外模式(又称为用户模式)
2. 模式(又称为逻辑模式或者概念模式)
3. 内模式(又称为物理模式)
数据库设计过程理论中,其核心作用的是数据依赖
- 关系数据库设计理论主要包括数据依赖、范式和关系模式规范化三个方面的内容，其中起核心作用的是数据依赖。范式和关系模式规范化都是在数据依赖的基础上定义和发展而来的。
规范化的基本原则:一是一地
数据的独立性分为:逻辑独立性和物理独立性
相关子查询:值查询的条件依赖于父查询

不相关子查询:子查询的条件不依赖于父查询
事务: 用户定义的一个数据库操作序列，这些操作要么全部要么全不做，是一个不可分割的工作单位。
关系的两个不变性:
1. 实体完整性:若属性A是基本关系R的主属性，则A不能去空值
2. 参照完整性: 若属性（或属性组）F是基本关系R的外码，它与基本关系S的主码K想对应（基本关系R和S不一定是不同的关系），则对于R 中的每个元组在F上的取值要么为空，要么等于S中某个元组的主码值。
日志文件:记录事务对数据库的更新操作的文件
E-R图之间的冲突
1. 属性冲突
2. 命名冲突
3. 结构冲突
故障的种类
1. 事务内部的故障
2. 系统故障
3. 介质故障
4. 计算机病毒
SQL语言的功能包括数据查询,数据定义,数据操纵和数据控制
CRUD:CRUD是数据库基本操作中的Create(创建)、Retrieve(读取)、Update（更新）、Delete（删除）。
数据依赖一般包括多值依赖,函数依赖和连续依赖
授予权限:GRANT … ON … TO … WITH GRANT OPTION

收回权限:REVOKE … ON … FROM …
数据库应用系统的维护阶段的任务
1. 数据库的转储和恢复
2. 数据库的安全性,完整性控制
3. 数据库性能的监督,分析和改造
4. 数据库的重组与重构造
  - 没有数据输入与测试
数据库系统中,物理存储视图用内模式描述
用户自定义完整性约束语句:NOT NULL, UNIQUE, CHECK
数据库角色:被命名的一组与数据库操作相关的权限，角色是权限的集合。
范式:关系数据库中的关系要满足一定要求，满足不同程度要求的为不同范式。
关系:笛卡尔集的子集，就是一个二维表。

附录二关系代数运算符

集合运算符

运算符	含义	英文
∪	并	Union
−	差	Difference
∩	交	Intersection
×	笛卡尔积	Cartesian Product

比较运算符

运算符	含义
>	大于
≥	大于等于
<	小于
≤	小于等于
=	等于
≠	不等于

专门的关系运算符

运算符	含义	英文
σ	选择	Selection
π	投影	Projection
⋈	链接	Join
÷	除	Division

逻辑运算符

运算符	含义
∧	与
∨	或
¬	非

附录三简答题总结

简述数据库管理系统的概念和功能？
1. 概念：数据库管理系统是位于用户与操作系统之间的一层数据管理软件。
2. 功能：
  1. 数据定义功能
  2. 数据组织、存储和管理
  3. 数据库操纵功能
  4. 数据库的事务和运行功能
  5. 数据库的建立和维护功能
  6. 其他功能，如不同数据库之间的互访和互操作功能等
简述数据库系统的三级模式结构。
1. 外模式，亦称子模式或用户模式，是数据库用户能够看见和使用的局部数据的逻辑结构和特征的描述，是数据库用户的数据视图。（用户程序根据需求展现给用户看的，如查询某个属性。）
2. 模式，亦称逻辑模式，是数据库中全体数据的逻辑结构和特性的描述，是所有用户的公共数据视图。模式描述的是数据的全局逻辑结构。外模式通常是模式的子集。（各个表在数据库中如何存放）
3. 内模式，亦称存储模式，是数据在数据库系统内部的表示，即对数据的物理结构和存储方式的描述。（数据库在硬盘中如何存放）
数据库系统的特点？

（1）数据结构化（是数据库的主要特征之一，也是数据库系统与文件系统的本质区别）；

（2）数据的共享性高，冗余度低，易扩充；

（3）数据独立性高——数据独立性是指程序和数据之间相互独立
SQL的特点？
1. 综合统一。SQL语言集数据定义语言（DDL）、数据操纵语言（DML）和数据控制语言（DCL）的功能于一体。
2. 高度非过程化。用SQL语言进行数据操作，只要提出“做什么”，而无须指明“怎么做”，因此无须了解存取路径。存取路径的选择以及SQL语句的操作过程由系统自动完成。
3. 面向集合的操作方式。不仅操作对象、查找结果可以是元组的集合，而且一次插入、删除、更新操作的对象也可以是元组的集合。
4. 以同一种语法结构提供两种使用方式。SQL语言既是自含式语言，又是嵌入式语言。
5. 语言简洁，易学易用。
数据库设计一般有那些过程？每个阶段的中心任务是什么？
1. 需求分析； -->数字词典,数据结构的描述
2. 概念结构设计；–>E-R图
3. 逻辑结构设计； -->将E-R图转化为对应的关系表
4. 物理结构设计； -->存储安排.存储路径的建立
5. 数据库实施； -->创建数据模式,装入数据,数据库试运行
6. 数据库运行和维护。 -->性能检测,数据库重组和重构.