数据库(数据库系统概论 第五版 王珊 萨师煊编著)】--考试重点
数据库
目录
- 数据库
-
- 绪论
-
- 数据库的四个基本概念
- 数据模型三要素
- 数据库系统的三级模式结构
- 数据库的二级映像功能与数据独立性
- 关系数据库
-
- 关系数据结构及形式化定义
- 关系操作
- 关系完整性
- SQL
-
- 数据查询
- 数据库安全性
-
- 用户身份鉴别
- 存取控制
- 自主存取控制方法
- 授权：授予与收回
- 数据库角色
- 强制存取控制方法
- 数据库完整性
-
- 实体完整性
- 参照完整性
- 用户定义的完整性
- 数据库的完整性是为了保证数据库中存储的数据是正确的
- 关系数据库管理系统完整性实现的机制
- 关系数据理论
-
- 规范化
- 函数最小依赖集（ Fm ）的求解
- 关系的闭包（XF ）
- 数据库的设计过程
-
- 需求分析
- 概念结构设计
- 逻辑结构设计
- 物理结构设计
- 数据库实施和维护
- 数据库编程
-
- 嵌入式SQL
- 过程化SQL
- 存储过程和函数
- ODBC编程
- 关系查询处理和查询优化
-
- 查询处理过程
- 查询优化
- 数据库回复技术
-
- 事物的概念和性质
- 故障的种类
- 恢复中最经常使用的技术
- 并发控制
-
- 封锁
- 封锁协议
- 两段锁协议
绪论
数据库的四个基本概念
-
数据
数据（Data）是数据库中存储的基本对象 数据的定义 描述事物的符号记录 数据的种类 数字、文字、图形、图像、音频、视频、学生的档案记录等 数据的含义称为数据的语义，数据与其语义是不可分的。 -
数据库
数据库的定义 数据库（Database，简称DB）是长期储存在计算机内、有组织的、可共享的大量数据的集合。 数据库的基本特征 数据按一定的数据模型组织、描述和储存 可为各种用户共享 冗余度较小 数据独立性较高 易扩展 -
数据库管理系统
位于用户与操作系统之间的一层数据管理软件 是基础软件，是一个大型复杂的软件系统 数据库管理系统的用途 科学地组织和存储数据、高效地获取和维护数据 数据库管理系统的主要功能 数据定义功能 提供数据定义语言（DDL） 定义数据库中的数据对象 数据组织、存储和管理 分类组织、存储和管理各种数据 确定组织数据的文件结构和存取方式 实现数据之间的联系 提供多种存取方法提高存取效率 数据操纵功能 提供数据操纵语言（DML） 实现对数据库的基本操作 （查询、插入、删除和修改） 数据库的事务管理和运行管理 数据库在建立、运行和维护时由数据库管理系统统一管理和控制 保证数据的安全性、完整性、多用户对数据的并发使用 发生故障后的系统恢复 数据库的建立和维护功能 数据库初始数据的装载和转换 数据库转储、恢复功能 数据库的重组织 性能监视、分析等 其它功能 数据库管理系统与网络中其它软件系统的通信 数据库管理系统系统之间的数据转换 异构数据库之间的互访和互操作 -
数据库系统
数据库系统的构成 数据库 数据库管理系统（及其应用开发工具） 应用程序 数据库管理员
数据模型三要素
-
数据结构
数据模型的数据结构 描述数据库的组成对象，以及对象之间的联系 描述的内容 1. 与对象的类型、内容、性质有关 2. 与数据之间联系有关 数据结构是对系统静态特性的描述 -
数据操作
数据操作 对数据库中各种对象（型）的实例（值）允许执行的 操作的集合，包括操作及有关的操作规则 数据操作的类型 查询 更新（包括插入、删除、修改） 数据模型对操作的定义 操作的确切含义 操作符号 操作规则（如优先级） 实现操作的语言 数据操作是对系统动态特性的描述 数据库中的数据随时间会发生变化 -
数据的完整性约束条件
一组完整性规则的集合 完整性规则：给定的数据模型中数据及其联系所具有的制约和依存规则 用以限定符合数据模型的数据库状态以及状态的变化，以保证数据的正确、有效和相容 数据模型对完整性约束条件的定义 反映和规定必须遵守的基本的通用的完整性约束条件。 提供定义完整性约束条件的机制，以反映具体应用所涉及的数据必须遵守的特定的语义约束条件。
数据库系统的三级模式结构
-
模式
模式（也称逻辑模式） 数据库中全体数据的逻辑结构和特征的描述 所有用户的公共数据视图 一个数据库只有一个模式 模式的地位：是数据库系统模式结构的中间层 与数据的物理存储细节和硬件环境无关 与具体的应用程序、开发工具及高级程序设计语言无关 模式的定义 数据的逻辑结构（数据项的名字、类型、取值范围等） 数据之间的联系 数据有关的安全性、完整性要求 -
外模式
数据库用户（包括应用程序员和最终用户）使用的局部数据的逻辑结构和特征的描述 数据库用户的数据视图，是与某一应用有关的数据的逻辑表示 外模式的地位：介于模式与应用之间 模式与外模式的关系：一对多 外模式通常是模式的子集 一个数据库可以有多个外模式。反映了不同的用户的应用需求、看待数据的方式、对数据保密的要求 对模式中同一数据，在外模式中的结构、类型、长度、保密级别等都可以不同 外模式与应用的关系：一对多 同一外模式也可以为某一用户的多个应用系统所使用 但一个应用程序只能使用一个外模式 外模式的用途 保证数据库安全性的一个有力措施 每个用户只能看见和访问所对应的外模式中的数据 -
内模式
（也称存储模式） 是数据物理结构和存储方式的描述 是数据在数据库内部的表示方式 记录的存储方式（例如，顺序存储，按照B树结构存储， 按hash方法存储等） 索引的组织方式 数据是否压缩存储 数据是否加密 数据存储记录结构的规定 一个数据库只有一个内模式
数据库的二级映像功能与数据独立性
三级模式是对数据的三个抽象级别
二级映象在数据库管理系统内部实现三个抽象层次的联系和转换
外模式／模式映像
模式／内模式映像
数据库模式
即全局逻辑结构是数据库的中心与关键
独立于数据库的其他层次
设计数据库模式结构时应首先确定数据库的逻辑模式
数据库的内模式
依赖于它的全局逻辑结构
独立于数据库的用户视图，即外模式
独立于具体的存储设备
将全局逻辑结构中所定义的数据结构及其联系按照一定的物理存储策略进行组织，以达到较好的时间与空间效率
数据库的外模式
面向具体的应用程序
定义在逻辑模式之上
独立于存储模式和存储设备
当应用需求发生较大变化，相应外模式不能满足其视图要求时，该外模式就得做相应改动
设计外模式时应充分考虑到应用的扩充性
特定的应用程序
在外模式描述的数据结构上编制的
依赖于特定的外模式
与数据库的模式和存储结构独立
不同的应用程序有时可以共用同一个外模式
数据库的二级映像
保证了数据库外模式的稳定性
从底层保证应用程序的稳定性，除非应用需求本身发生变化，否则应用程序一般不需要改
数据与程序之间的独立性，使得数据的定义和描述可以从应用程序中分离出去
数据的存取由数据库管理系统管理
简化了应用程序的编制
大大减少了应用程序的维护和修改
-
外模式/模式映像
模式：描述的是数据的全局逻辑结构 外模式：描述的是数据的局部逻辑结构 同一个模式可以有任意多个外模式 每一个外模式，数据库系统都有一个外模式／模式映象，定义外模式与模式之间的对应关系 映象定义通常包含在各自外模式的描述中 保证数据的逻辑独立性 当模式改变时，数据库管理员对外模式／模式映象作相应改变，使外模式保持不变 应用程序是依据数据的外模式编写的，应用程序不必修改，保证了数据与程序的逻辑独立性，简称数据的逻辑独立性 -
模式/内模式映像
模式／内模式映象定义了数据全局逻辑结构与存储结构之间的对应关系。 例如，说明逻辑记录和字段在内部是如何表示的 数据库中模式／内模式映象是唯一的 该映象定义通常包含在模式描述中 保证数据的物理独立性 当数据库的存储结构改变了（例如选用了另一种存储结构），数据库管理员修改模式／内模式映象，使模式保持不变。 应用程序不受影响。保证了数据与程序的物理独立性，简称数据的物理独立性。
关系数据库
关系数据结构及形式化定义
-
关系
单一的数据结构----关系 现实世界的实体以及实体间的各种联系均用关系来表示 逻辑结构----二维表 从用户角度，关系模型中数据的逻辑结构是一张二维表 建立在集合代数的基础上 （1） 关系 D1×D2×…×Dn的子集叫作在域D1，D2，…，Dn上的 关系，表示为 R（D1，D2，…，Dn） R：关系名 n：关系的目或度（Degree） （2）元组 关系中的每个元素是关系中的元组，通常用t表示。 （3）单元关系与二元关系 当n=1时，称该关系为单元关系或一元关系 当n=2时，称该关系为二元关系 （4）关系的表示 关系也是一个二维表，表的每行对应一个元组，表的每 列对应一个域 （5）属性 关系中不同列可以对应相同的域 为了加以区分，必须对每列起一个名字，称为属性 n目关系必有n个属性 （6）码 候选码（Candidate key） 若关系中的某一属性组的值能唯一地标识一个元组，则称 该属性组为候选码 简单的情况：候选码只包含一个属性 全码（All-key） 最极端的情况：关系模式的所有属性组是这个关系模式的 候选码，称为全码（All-key） 主码 若一个关系有多个候选码，则选定其中一个为主码 主属性 候选码的诸属性称为主属性（Prime attribute） 不包含在任何侯选码中的属性称为非主属性（Non-Prime attribute）或非码属性（Non-key attribute） （7）三类关系 基本关系（基本表或基表） 实际存在的表，是实际存储数据的逻辑表示 查询表 查询结果对应的表 视图表 由基本表或其他视图表导出的表，是虚表，不对 应实际存储的数据 （8）基本关系的性质 ① 列是同质的（Homogeneous） ② 不同的列可出自同一个域 其中的每一列称为一个属性 不同的属性要给予不同的属性名 ③ 列的顺序无所谓,，列的次序可以任意交换 ④ 任意两个元组的候选码不能相同 ⑤ 行的顺序无所谓，行的次序可以任意交换 ⑥ 分量必须取原子值 这是规范条件中最基本的一条 -
关系模式
关系模式（Relation Schema）是型 关系是值 关系模式是对关系的描述 元组集合的结构 属性构成 属性来自的域 属性与域之间的映象关系 完整性约束条件 关系模式可以形式化地表示为： R（U，D，DOM，F） R 关系名 U 组成该关系的属性名集合 D U中属性所来自的域 DOM 属性向域的映象集合 F 属性间数据的依赖关系的集合 关系模式 对关系的描述 静态的、稳定的 关系 关系模式在某一时刻的状态或内容 动态的、随时间不断变化的 关系模式和关系往往笼统称为关系 通过上下文加以区别 -
关系数据库
关系数据库 在一个给定的应用领域中，所有关系的集合构成一 个关系数据库 关系数据库的型与值 关系数据库的型: 关系数据库模式，是对关系数据 库的描述 关系数据库的值: 关系模式在某一时刻对应的关系 的集合，通常称为关系数据库-
关系模型的存储结构
关系数据库的物理组织
有的关系数据库管理系统中一个表对应一个操作系统
文件，将物理数据组织交给操作系统完成
有的关系数据库管理系统从操作系统那里申请若干个
大的文件，自己划分文件空间，组织表、索引等存储
结构，并进行存储管理
-
关系操作
常用的关系操作
查询操作：选择、投影、连接、除、并、差、交、笛卡
尔积
选择、投影、并、差、笛卡尔基是5种基本操作
数据更新：插入、删除、修改
关系操作的特点
集合操作方式：操作的对象和结果都是集合，一次一集
合的方式
关系完整性
- 实体完整性
实体完整性规则的说明
（1）实体完整性规则是针对基本关系而言的。
一个基本表通常对应现实世界的一个实体集。
（2）现实世界中的实体是可区分的，即它们具有某种唯
一性标识。
（3）关系模型中以主码作为唯一性标识。
（4）主码中的属性即主属性不能取空值。
主属性取空值，就说明存在某个不可标识的实体，即
存在不可区分的实体，这与第（2）点相矛盾，因此
这个规则称为实体完整性
-
参照完整性
1. 关系间的引用 在关系模型中实体及实体间的联系都是用关系来 描述的，自然存在着关系与关系间的引用。 2. 外码 设F是基本关系R的一个或一组属性，但不是关系R的码。 如果F与基本关系S的主码Ks相对应，则称F是R的外码 基本关系R称为参照关系（Referencing Relation） 基本关系S称为被参照关系（Referenced Relation） 或目标关系（Target Relation） 关系R和S不一定是不同的关系 目标关系S的主码Ks 和参照关系的外码F必须定义 在同一个（或一组）域上 外码并不一定要与相应的主码同名 当外码与相应的主码属于不同关系时，往往取相同的名 字，以便于识别 3. 参照完整性规则 规则2.2 参照完整性规则 若属性（或属性组）F是基本关系R的外码它与基本关系S 的主码Ks相对应（基本关系R和S不一定是不同的关系）， 则对于R中每个元组在F上的值必须为： 或者取空值（F的每个属性值均为空值） 或者等于S中某个元组的主码值 -
用户定义的完整性
针对某一具体关系数据库的约束条件，反映某一 具体应用所涉及的数据必须满足的语义要求 关系模型应提供定义和检验这类完整性的机制， 以便用统一的系统的方法处理它们，而不需由应 用程序承担这一功能
SQL
数据查询
重点看书练习
数据库安全性
用户身份鉴别
系统提供的最外层安全保护措施
用户标识：由用户名和用户标识号组成
（用户标识号在系统整个生命周期内唯一）
用户身份鉴别的方法
1.静态口令鉴别
静态口令一般由用户自己设定，这些口令是静态不变的
2.动态口令鉴别
口令是动态变化的，每次鉴别时均需使用动态产生的新口令登录数据库管理系统，即采用一次一密的方法
3.生物特征鉴别
通过生物特征进行认证的技术，生物特征如指纹、虹膜和掌纹等
4.智能卡鉴别
智能卡是一种不可复制的硬件，内置集成电路的芯片，具有硬件加密功能
存取控制
存取控制机制组成
定义用户权限，并将用户权限登记到数据字典中
用户对某一数据对象的操作权力称为权限
DBMS提供适当的语言来定义用户权限，存放在数据字典中，称做安全规则或授权规则
合法权限检查
用户发出存取数据库操作请求
DBMS查找数据字典，进行合法权限检查
用户权限定义和合法权检查机制一起组成了数据库管理系统的存取控制子系统
常用存取控制方法
自主存取控制（Discretionary Access Control ，简称DAC）
C2级
用户对不同的数据对象有不同的存取权限
不同的用户对同一对象也有不同的权限
用户还可将其拥有的存取权限转授给其他用户
强制存取控制（Mandatory Access Control，简称 MAC）
B1级
每一个数据对象被标以一定的密级
每一个用户也被授予某一个级别的许可证
对于任意一个对象，只有具有合法许可证的用户才可以存取
自主存取控制方法
通过 SQL 的GRANT 语句和REVOKE 语句实现
用户权限组成
数据对象
操作类型
定义用户存取权限：定义用户可以在哪些数据库对象上进行哪些类型的操作
定义存取权限称为授权
授权：授予与收回
1.GRANT
GRANT语句的一般格式：
GRANT <权限>[,<权限>]...
ON <对象类型> <对象名>[,<对象类型> <对象名>]…
TO <用户>[,<用户>]...
[WITH GRANT OPTION];
语义：将对指定操作对象的指定操作权限授予指定的用户
发出GRANT：
数据库管理员
数据库对象创建者（即属主Owner）
拥有该权限的用户
按受权限的用户
一个或多个具体用户
PUBLIC（即全体用户）
WITH GRANT OPTION子句:
指定：可以再授予
没有指定：不能传播
2.REVOKE
授予的权限可以由数据库管理员或其他授权者用REVOKE语句收回
REVOKE语句的一般格式为：
REVOKE <权限>[,<权限>]...
ON <对象类型> <对象名>[,<对象类型><对象名>]…
FROM <用户>[,<用户>]...[CASCADE | RESTRICT];
数据库管理员：
拥有所有对象的所有权限
根据实际情况不同的权限授予不同的用户
用户：
拥有自己建立的对象的全部的操作权限
可以使用GRANT，把权限授予其他用户
被授权的用户
如果具有“继续授权”的许可，可以把获得的权限再授予其他用户
所有授予出去的权力在必要时又都可用REVOKE语句收回
3.创建数据库模式的权限
数据库管理员在创建用户时实现
CREATE USER语句格式
CREATE USER
[WITH][DBA|RESOURCE|CONNECT];
注：
CREATE USER不是SQL标准，各个系统的实现相差甚远
CREATE USER语句格式说明
只有系统的超级用户才有权创建一个新的数据库用户
新创建的数据库用户有三种权限：CONNECT、RESOURCE和DBA
如没有指定创建的新用户的权限，默认该用户拥有CONNECT权限。拥有CONNECT权限的用户不能创建新用户，不能创建模式，也不能创建基本表，只能登录数据库
拥有RESOURCE权限的用户能创建基本表和视图，成为所创建对象的属主。但不能创建模式，不能创建新的用户
拥有DBA权限的用户是系统中的超级用户，可以创建新的用户、创建模式、创建基本表和视图等；DBA拥有对所有数据库对象的存取权限，还可以把这些权限授予一般用户
数据库角色
数据库角色：被命名的一组与数据库操作相关的权限
角色是权限的集合
可以为一组具有相同权限的用户创建一个角色
简化授权的过程
1.角色的创建
CREATE ROLE <角色名>
2.给角色授权
GRANT <权限>[,<权限>]…
ON <对象类型>对象名
TO <角色>[,<角色>]…
3.将一个角色授予其他的角色或用户
GRANT <角色1>[,<角色2>]…
TO <角色3>[,<用户1>]…
[WITH ADMIN OPTION]
该语句把角色授予某用户，或授予另一个角色
授予者是角色的创建者或拥有在这个角色上的ADMIN OPTION
指定了WITH ADMIN OPTION则获得某种权限的角色或用户还可以把这种权限授予其他角色
一个角色的权限：直接授予这个角色的全部权限加上其他角色授予这个角色的全部权限
4.角色权限的收回
REVOKE <权限>[,<权限>]…
ON <对象类型> <对象名>
FROM <角色>[,<角色>]…
用户可以回收角色的权限，从而修改角色拥有的权限
REVOKE执行者是
角色的创建者
拥有在这个（些）角色上的ADMIN OPTION
强制存取控制方法
可能存在数据的“无意泄露”
原因：这种机制仅仅通过对数据的存取权限来进行安全控制，而数据本身并无安全性标记
解决：对系统控制下的所有主客体实施强制存取控制策略
强制存取控制（MAC）
保证更高程度的安全性
用户不能直接感知或进行控制
适用于对数据有严格而固定密级分类的部门
军事部门
政府部门
在强制存取控制中，数据库管理系统所管理的全部实体被分为主体和客体两大类
主体是系统中的活动实体
数据库管理系统所管理的实际用户
代表用户的各进程
客体是系统中的被动实体，受主体操纵
文件、基本表、索引、视图
敏感度标记（Label）
对于主体和客体，DBMS为它们每个实例（值）指派一个敏感度标记（Label）
敏感度标记分成若干级别
绝密（Top Secret，TS）
机密（Secret，S）
可信（Confidential，C）
公开（Public，P）
TS>=S>=C>=P
主体的敏感度标记称为许可证级别（Clearance Level）
客体的敏感度标记称为密级（Classification Level）
强制存取控制规则
（1）仅当主体的许可证级别大于或等于客体的密级时，该主体才能读取相应的客体
（2）仅当主体的许可证级别小于或等于客体的密级时，该主体才能写相应的客体
强制存取控制（MAC）是对数据本身进行密级标记，无论数据如何复制，标记与数据是一个不可分的整体，只有符合密级标记要求的用户才可以操纵数据。
实现强制存取控制时要首先实现自主存取控制
原因：较高安全性级别提供的安全保护要包含较低级别的所有保护
自主存取控制与强制存取控制共同构成数据库管理系统的安全机制
数据库完整性
数据的正确性
是指数据是符合现实世界语义，反映了当前实际状况的
数据的相容性
是指数据库同一对象在不同关系表中的数据是符合逻辑的
例如，
学生的学号必须唯一
性别只能是男或女
本科学生年龄的取值范围为14~50的整数
学生所选的课程必须是学校开设的课程，学生所在的院系必须是学校已成立的院系
数据的完整性和安全性是两个不同概念
数据的完整性
防止数据库中存在不符合语义的数据，也就是防止数据库中存在不正确的数据
防范对象：不合语义的、不正确的数据
数据的安全性
保护数据库 防止恶意的破坏和非法的存取
防范对象：非法用户和非法操作
为维护数据库的完整性，数据库管理系统必须：
1.提供定义完整性约束条件的机制
完整性约束条件也称为完整性规则，是数据库中的数据必须满足的语义约束条件
SQL标准使用了一系列概念来描述完整性，包括关系模型的实体完整性、参照完整性和用户定义完整性
这些完整性一般由SQL的数据定义语言语句来实现
2.提供完整性检查的方法
数据库管理系统中检查数据是否满足完整性约束条件的机制称为完整性检查。
一般在INSERT、UPDATE、DELETE语句执行后开始检查，也可以在事务提交时检查
3.违约处理
数据库管理系统若发现用户的操作违背了完整性约束条件，就采取一定的动作
拒绝（NO ACTION）执行该操作
级连（CASCADE）执行其他操作
实体完整性
关系模型的实体完整性
CREATE TABLE中用PRIMARY KEY定义
单属性构成的码有两种说明方法
定义为列级约束条件
定义为表级约束条件
对多个属性构成的码只有一种说明方法
定义为表级约束条件
插入或对主码列进行更新操作时，关系数据库管理系统按照实体完整性规则自动进行检查。包括：
检查主码值是否唯一，如果不唯一则拒绝插入或修改
检查主码的各个属性是否为空，只要有一个为空就拒绝插入或修改
参照完整性
关系模型的参照完整性定义
在CREATE TABLE中用FOREIGN KEY短语定义哪些列为外码
用REFERENCES短语指明这些外码参照哪些表的主码
参照完整性违约处理
（1） 拒绝（NO ACTION）执行
不允许该操作执行。该策略一般设置为默认策略
（2） 级联（CASCADE）操作
当删除或修改被参照表（Student）的一个元组造成了与参照表（SC）的不一致，则删除或修改参照表中的所有造成不一致的元组
（3）设置为空值（SET-NULL）
当删除或修改被参照表的一个元组时造成了不一致，则将参照表中的所有造成不一致的元组的对应属性设置为空值。
对于参照完整性，除了应该定义外码，还应定义外码列是否允许空值
用户定义的完整性
用户定义的完整性是：针对某一具体应用的数据必须满足的语义要求
关系数据库管理系统提供了定义和检验用户定义完整性的机制，不必由应用程序承担
CREATE TABLE时定义属性上的约束条件
列值非空（NOT NULL）
列值唯一（UNIQUE）
检查列值是否满足一个条件表达式（CHECK）
属性上的约束条件检查和违约处理
插入元组或修改属性的值时，关系数据库管理系统检查属性上的约束条件是否被满足
如果不满足则操作被拒绝执行
在CREATE TABLE时可以用CHECK短语定义元组上的约束条件，即元组级的限制
同属性值限制相比，元组级的限制可以设置不同属性之间的取值的相互约束条件
元组上的约束条件检查和违约处理
插入元组或修改属性的值时，关系数据库管理系统检查元组上的约束条件是否被满足
如果不满足则操作被拒绝执行
数据库的完整性是为了保证数据库中存储的数据是正确的
关系数据库管理系统完整性实现的机制
- 完整性约束定义机制
- 完整性检查机制
- 违背完整性约束条件时DBMS采取的动作
关系数据理论
规范化
-
函数依赖
f ( Sno ) = Sname,Sname函数依赖于Sno，Sno决定Sname 记作: X → Y X和Y都是U的子集，x决定y，y函数依赖于x 非平凡的函数依赖：X→Y，但Y⊈X则称X→Y 平凡的函数依赖：X→Y，但Y⊆X 则称X→Y 完全函数依赖：在R(U)中，如果X→Y，并且对于X的任何一个真子集X’, 都有 X’ →Y，记作X → Y。 部分函数依赖：X→Y，但非完全函数依赖 传递函数以来：X→Y，Y→X，Y→Z，Z⊈Y：X→Z -
码
设K为R -
范式
范式是符合某一种级别的关系模式的集合。 关系数据库中的关系必须满足一定的要求。满足 不同程度要求的为不同范式。 各种范式之间存在联系： 某一关系模式R为第n范式，可简记为R∈nNF。-
2NF
若关系模式R∈1NF，并且每一个非主属性都完全函数依赖于任何一个候选码，则R∈2NF 一个关系模式不属于2NF，会产生以下问题： 插入异常 如果插入一个新学生，但该生未选课，即该生无Cno，由于插入元组时，必须给定码值，因此插入失败。 删除异常 如果S4只选了一门课C3，现在他不再选这门课，则删除C3后，整个元组的其他信息也被删除了。 修改复杂 如果一个学生选了多门课，则Sdept，Sloc被存储了多次。如果该生转系，则需要修改所有相关的Sdept和Sloc，造成修改的复杂化。 -
3NF
设关系模式R -
BCNF
设关系模式R -
4NF
关系模式R
-
-
多值依赖
设R(U)是属性集U上的一个关系模式。X,Y,Z是U的子集，并且Z=U-X-Y。关系模式R(U)中多值依赖X→→Y成立，当且仅当对R(U)的任一关系r，给定的一对(x,z)值，有一组Y的值，这组值仅仅决定于x值而与z值无关。 多值依赖的另一个等价的定义 在R(U)的任一关系r中，如果存在元组t，s使得t[X]=s[X] ，那么就必然存在元组w，v∈r，（w，v可以与s，t相 同）, 使得w[X]=v[X]=t[X]，而w[Y]=t[Y]，w[Z]=s[Z]， v[Y]=s[Y]，v[Z]=t[Z]（即交换s，t元组的Y值所得的两 个新元组必在r中则Y多值依赖于X，记为X→→Y。这里 X，Y是U的子集，Z=U-X-Y。 平凡多值依赖和非平凡的多值依赖 若X→→Y，而Z＝Ф，即Z为空，则称X→→Y为平凡的多值依赖。 否则称X→→Y为非平凡的多值依赖。 多值依赖的性质 （1）多值依赖具有对称性。 即若X→→Y，则X→→Z，其中Z＝U－X－Y （2）多值依赖具有传递性。 即若X→→Y，Y→→Z， 则 X→→Z -Y。 （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。 多值依赖与函数依赖的区别
函数最小依赖集（ Fm ）的求解
关系的闭包（XF ）
数据库的设计过程
需求分析
把需求收集和分析作为数据库设计的第一阶段是十分重要的。
第一阶段收集的基础数据（用数据字典来表达）是下一步进行概念设计的基础。
强调两点
（1）设计人员应充分考虑到可能的扩充和改变，使设计易于更改，系统易于扩充
（2）必须强调用户的参与
- 需求分析的任务
- 需求分析的方法
- 数据字典
概念结构设计
- 概念结构
- E-R模型
E-R图提供了表示实体型、属性和联系的方法：
实体型：用矩形表示，矩形框内写明实体名。
属性：用椭圆形表示，并用无向边将其与相应的实体型连接起来。
联系：用菱形表示，菱形框内写明联系名，并用无向边分别与有关实体型连接起来，同时在无向边旁标上联系的类型（1∶1，1∶n或m∶n）。
联系可以具有属性
实体与属性的划分原则
为了简化E-R图的处置，现实世界的事物能作为属性对待的，尽量作为属性对待。
两条准则：
（1）作为属性，不能再具有需要描述的性质。属性必须是不可分的数据项，不能包含其他属性。
（2）属性不能与其他实体具有联系，即E-R图中所表示的联系是实体之间的联系。
逻辑结构设计
- E-R图面向关系模型的转换
- 数据模型的优化
- 设计用户子模式
物理结构设计
- 数据库物理设计的内容和方法
- 关系模式存取方式的选择
- 评价物理结构
数据库实施和维护
- 数据的载入和应用程序的调试
- 数据库的试运行
- 数据库的运行和维护
数据库编程
嵌入式SQL
嵌入式SQL是将SQL语句嵌入程序设计语言中，被嵌入
的程序设计语言，如C、C++、Java，称为宿主语言，
简称主语言。
处理过程
预编译方法
为了区分SQL语句与主语言语句，所有SQL语句
必须加前缀EXEC SQL，
主语言为C语言时，语句格式：
EXEC SQL
过程化SQL
过程化SQL
SQL的扩展
增加了过程化语句功能
基本结构是块
块之间可以互相嵌套
每个块完成一个逻辑操作
过程化SQL块的基本结构
1. 定义部分
DECLARE 变量、常量、游标、异常等
定义的变量、常量等只能在该基本块中使用
当基本块执行结束时，定义就不再存在
2. 执行部分
BEGIN
SQL语句、过程化SQL的流程控制语句
EXCEPTION
异常处理部分
END；
存储过程和函数
过程化SQL块类型
命名块
编译后保存在数据库中，可以被反复调用，运行速度较
快，过程和函数是命名块
匿名块
每次执行时都要进行编译，它不能被存储到数据库中，
也不能在其他过程化SQL块中调用
函数和存储过程的异同
同：都是持久性存储模块
异：函数必须指定返回的类型
ODBC编程
ODBC优点
移植性好
能同时访问不同的数据库
共享多个数据资源
ODBC产生的原因
由于不同的数据库管理系统的存在，在某个关系数据
库管理系统下编写的应用程序就不能在另一个关系数
据库管理系统下运行
许多应用程序需要共享多个部门的数据资源，访问不
同的关系数据库管理系统
关系查询处理和查询优化
I/O代价的计算、启发式规则
查询处理过程
-
查询分析
查询分析的任务：对查询语句进行扫描、词法分析和语法分析 词法分析：从查询语句中识别出正确的语言符号 语法分析：进行语法检查 -
查询检查
查询检查的任务 合法权检查 视图转换 安全性检查 完整性初步检查 根据数据字典中有关的模式定义检查语句中的数据库对象，如关系名、属性名是否存在和有效 如果是对视图的操作，则要用视图消解方法把对视图的操作转换成对基本表的操作 根据数据字典中的用户权限和完整性约束定义对用户的存取权限进行检查 检查通过后把SQL查询语句转换成内部表示，即等价的关系代数表达式。 关系数据库管理系统一般都用查询树，也称为语法分析树来表示扩展的关系代数表达式。 -
查询优化
查询优化：选择一个高效执行的查询处理策略 查询优化分类 代数优化/逻辑优化：指关系代数表达式的优化 物理优化：指存取路径和底层操作算法的选择 查询优化的选择依据 基于规则(rule based) 基于代价(cost based) 基于语义(semantic based) -
查询执行
依据优化器得到的执行策略生成查询执行计划 代码生成器(code generator)生成执行查询计划的代码 两种执行方法 自顶向下（迭代器，最常用） 自底向上（数据驱动）
查询优化
- 代数优化
- 物理优化
数据库回复技术
事物的概念和性质
事务(Transaction)是用户定义的一个数据库操作序列，
这些操作要么全做，要么全不做，是一个不可分割的工作
单位。
事务和程序是两个概念
在关系数据库中，一个事务可以是一条SQL语句，一组
SQL语句或整个程序
一个程序通常包含多个事务
事务是恢复和并发控制的基本单位
事务的ACID特性：
原子性（Atomicity）：
事务是数据库的逻辑工作单位
事务中包括的诸操作要么都做，要么都不做
一致性（Consistency） ：
事务执行的结果必须是使数据库从一个一致性状态变
到另一个一致性状态
一致性状态
数据库中只包含成功事务提交的结果
不一致状态
数据库系统运行中发生故障，有些事务尚未完成就被迫
中断；
这些未完成事务对数据库所做的修改有一部分已写入物
理数据库，这时数据库就处于一种不正确的状态
隔离性（Isolation）
一个事务的执行不能被其他事务干扰
一个事务内部的操作及使用的数据对其他并发事务 是隔离的
并发执行的各个事务之间不能互相干扰
持续性（Durability ）
一个事务一旦提交，它对数据库中数据的改变就应该
是永久性的。
接下来的其他操作或故障不应该对其执行结果有任何
影响。
保证事务ACID特性是事务处理的任务
破坏事务ACID特性的因素
（1） 多个事务并发时，不同事务的操作交叉执行
数据库管理系统必须保证多个事务的交叉运行不影响这
些事务的隔离性
（2）事务在运行过程中被强行停止
数据库管理系统必须保证被强行终止的事务对数据库和
其他事务没有任何影响
事务是数据库的逻辑工作单位
数据库管理系统保证系统中一切事务的原子性、一致性、隔离性和持续性，就保证了事务处于一致状态
故障的种类
-
事务故障
1.事务内部的故障 有的是可以通过事务程序本身发现的 有的是非预期的，不能由事务程序处理的。 事务内部更多的故障是非预期的， 是不能由应用程序处理的。 运算溢出 并发事务发生死锁而被选中撤销该事务 违反了某些完整性限制而被终止等 以后，事务故障仅指这类非预期的故障 事务故障意味着 事务没有达到预期的终点(COMMIT或者显式ROLLBACK) 数据库可能处于不正确状态。 事务故障的恢复：事务撤消（UNDO） 强行回滚（ROLLBACK）该事务 撤销该事务已经作出的任何对数据库的修改，使得该事务 象根本没有启动一样 -
系统故障
2.系统故障 称为软故障，是指造成系统停止运转的任何事件，使得 系统要重新启动。 系统的正常运行突然被破坏 正在运行的事务都非正常终止 不破坏数据库外存，但内存中的信息全部丢失 特定类型的硬件错误（如CPU故障） 操作系统故障 数据库管理系统代码错误 系统断电 发生系统故障时，一些尚未完成的事务的结果可 能已送入物理数据库，造成数据库可能处于不正 确状态。 恢复策略：系统重新启动时，恢复程序让所有非正常 终止的事务回滚，强行撤消（UNDO）所有未完成事 务 发生系统故障时，有些已完成的事务可能有一部 分甚至全部留在缓冲区，尚未写回到磁盘上的物 理数据库中，系统故障使得这些事务对数据库的 修改部分或全部丢失 恢复策略：系统重新启动时，恢复程序需要重做 （REDO）所有已提交的事务 -
介质故障
3.介质故障 称为硬故障，指外存故障 磁盘损坏 磁头碰撞 瞬时强磁场干扰 介质故障破坏数据库或部分数据库，并影响正在存取这部 分数据的所有事务 介质故障比前两类故障的可能性小得多，但破坏性大得多 -
计算机病毒
4.计算机病毒 一种人为的故障或破坏，是一些恶作剧者研制的一种 计算机程序 可以繁殖和传播，造成对计算机系统包括数据库的危 害 计算机病毒种类 小的病毒只有20条指令，不到50B 大的病毒像一个操作系统，由上万条指令组成 计算机病毒的危害 有的病毒传播很快，一旦侵入系统就马上摧毁系统 有的病毒有较长的潜伏期，计算机在感染后数天或数月才开 始发病 有的病毒感染系统所有的程序和数据 有的只对某些特定的程序和数据感兴趣 计算机病毒已成为计算机系统的主要威胁，自然也是数据 库系统的主要威胁 数据库一旦被破坏仍要用恢复技术把数据库加以恢复
恢复中最经常使用的技术
-
数据库转储
转储是指数据库管理员定期地将整个数据库复制 到磁带、磁盘或其他存储介质上保存起来的过程 备用的数据文本称为后备副本(backup)或后援副本 数据库遭到破坏后可以将后备副本重新装入 重装后备副本只能将数据库恢复到转储时的状态 要想恢复到故障发生时的状态，必须重新运行自转储以后的所有更新事务-
静态转储和动态转储
静态转储 在系统中无运行事务时进行的转储操作 转储开始时数据库处于一致性状态 转储期间不允许对数据库的任何存取、修改活动 得到的一定是一个数据一致性的副本 优点：实现简单 缺点：降低了数据库的可用性 转储必须等待正运行的用户事务结束 新的事务必须等转储结束 动态转储 转储操作与用户事务并发进行 转储期间允许对数据库进行存取或修改 优点 不用等待正在运行的用户事务结束 不会影响新事务的运行 动态转储的缺点 不能保证副本中的数据正确有效 例在转储期间的某时刻Tc，系统把数据A=100转储到磁 带上，而在下一时刻Td，某一事务将A改为200。 后备副本上的A过时了 利用动态转储得到的副本进行故障恢复 需要把动态转储期间各事务对数据库的修改活动登记 下来，建立日志文件 后备副本加上日志文件就能把数据库恢复到某一时刻 的正确状态 -
海量转储和增量转储
海量转储: 每次转储全部数据库 增量转储: 只转储上次转储后更新过的数据 海量转储与增量转储比较 从恢复角度看，使用海量转储得到的后备副本进行恢 复往往更方便 如果数据库很大，事务处理又十分频繁，则增量转储 方式更实用更有效
-
-
登记日志文件
日志文件(log file)是用来记录事务对数据库的更新操作 的文件-
日志文件的格式和内容
以记录为单位的日志文件 各个事务的开始标记(BEGIN TRANSACTION) 各个事务的结束标记(COMMIT或ROLLBACK) 各个事务的所有更新操作 以上均作为日志文件中的一个日志记录 (log record) 每条日志记录的内容 事务标识（标明是哪个事务） 操作类型（插入、删除或修改） 操作对象（记录ID、Block NO.） 更新前数据的旧值（对插入操作而言，此项为空值） 更新后数据的新值（对删除操作而言, 此项为空值） 以数据块为单位的日志文件 每条日志记录的 内容 事务标识 被更新的数据块 -
日志文件的作用
用途 进行事务故障恢复 进行系统故障恢复 协助后备副本进行介质故障恢复 在静态转储方式中，也可以建立日志文件。 当数据库毁坏后可重新装入后援副本把数据库恢复到转 储结束时刻的正确状态 利用日志文件，把已完成的事务进行重做处理 对故障发生时尚未完成的事务进行撤销处理 不必重新运行那些已完成的事务程序就可把数据库恢复 到故障前某一时刻的正确状态 -
登记日志文件
为保证数据库是可恢复的，登记日志文件时必须遵循两 条原则 登记的次序严格按并发事务执行的时间次序 必须先写日志文件，后写数据库 写日志文件操作：把表示这个修改的日志记录写到 日志文件中 写数据库操作：把对数据的修改写到数据库中 为什么要先写日志文件 写数据库和写日志文件是两个不同的操作 在这两个操作之间可能发生故障 如果先写了数据库修改，而在日志文件中没有登记下这 个修改，则以后就无法恢复这个修改了 如果先写日志，但没有修改数据库，按日志文件恢复时 只不过是多执行一次不必要的UNDO操作，并不会影响 数据库的正确性
-
-
检查点技术
具有检查点（checkpoint）的恢复技术 在日志文件中增加检查点记录（checkpoint） 增加重新开始文件 恢复子系统在登录日志文件期间动态地维护日志 检查点记录的内容 建立检查点时刻所有正在执行的活跃事务清单 活跃事务最近一个日志记录的地址 重新开始文件的内容 记录各个检查点记录在日志文件中的地址 动态维护日志文件的方法 周期性地执行如下操作：建立检查点，保存数据库状态。 具体步骤是： （1）将当前日志缓冲区中的所有日志记录写入磁盘的日志文件上 （2）在日志文件中写入一个检查点记录 （3）将当前数据缓冲区的所有数据记录写入磁盘的数据库中 （4）把检查点记录在日志文件中的地址写入一个重新开始文件 恢复子系统可以定期或不定期地建立检查点,保存 数据库状态 定期 按照预定的一个时间间隔，如每隔一小时建立一个检查点 不定期 按照某种规则，如日志文件已写满一半建立一个检查点 使用检查点方法可以改善恢复效率 当事务T在一个检查点之前提交，T对数据库所做的修 改已写入数据库 写入时间是在这个检查点建立之前或在这个检查点建立之时 在进行恢复处理时，没有必要对事务T执行重做操作
并发控制
封锁
封锁就是事务T在对某个数据对象（例如表、记录等）操
作之前，先向系统发出请求，对其加锁
加锁后事务T就对该数据对象有了一定的控制，在事务T
释放它的锁之前，其它的事务不能更新此数据对象。
封锁是实现并发控制的一个非常重要的技术
一个事务对某个数据对象加锁后究竟拥有什么样
的控制由封锁的类型决定。
基本封锁类型
排它锁（Exclusive Locks，简记为X锁）
共享锁（Share Locks，简记为S锁
排它锁又称为写锁
若事务T对数据对象A加上X锁，则只允许T读取
和修改A，其它任何事务都不能再对A加任何类型 的锁
直到T释放A上的锁
保证其他事务在T释放A上的锁之前不能再读取和 修改A
共享锁又称为读锁
若事务T对数据对象A加上S锁，则事务T可以读A
但不能修改A，其它事务只能再对A加S锁，而不
能加X锁，直到T释放A上的S锁
保证其他事务可以读A，但在T释放A上的S锁之
前不能对A做任何修改
封锁协议
什么是封锁协议
在运用X锁和S锁对数据对象加锁时，需要约定一些规
则，这些规则为封锁协议（Locking Protocol）。
何时申请X锁或S锁
持锁时间
何时释放
对封锁方式规定不同的规则，就形成了各种不同的封
锁协议，它们分别在不同的程度上为并发操作的正确
调度提供一定的保证
一级封锁协议
事务T在修改数据R之前必须先对其加X锁，直到事务
结束才释放。
正常结束（COMMIT）
非正常结束（ROLLBACK）
一级封锁协议可防止丢失修改，并保证事务T是
可恢复的。
在一级封锁协议中，如果仅仅是读数据不对其进 行修改，是不需要加锁的，所以它不能保证可重 复读和不读“脏”数据。
二级封锁协议
一级封锁协议加上事务T在读取数据R之前必须先对其
加S锁，读完后即可释放S锁。
二级封锁协议可以防止丢失修改和读“脏”数据。
在二级封锁协议中，由于读完数据后即可释放S锁，所以它不能保证可重复读
三级封锁协议
一级封锁协议加上事务T在读取数据R之前必须先对其
加S锁，直到事务结束才释放。
三级封锁协议可防止丢失修改、读脏数据和不可
重复读。
三级协议的主要区别
什么操作需要申请封锁以及何时释放锁（即持锁时间）
不同的封锁协议使事务达到的一致性级别不同
封锁协议级别越高，一致性程度越高
两段锁协议
两段锁协议
指所有事务必须分两个阶段对数据项加锁和解锁
在对任何数据进行读、写操作之前，事务首先要获得
对该数据的封锁
在释放一个封锁之后，事务不再申请和获得任何其他
封锁
“两段”锁的含义
事务分为两个阶段
第一阶段是获得封锁，也称为扩展阶段
事务可以申请获得任何数据项上的任何类型的锁，但是
不能释放任何锁
第二阶段是释放封锁，也称为收缩阶段
事务可以释放任何数据项上的任何类型的锁，但是不能
再申请任何锁
事务遵守两段锁协议是可串行化调度的充分条件，而不是
必要条件。
若并发事务都遵守两段锁协议，则对这些事务的任何并发
调度策略都是可串行化的
若并发事务的一个调度是可串行化的，不一定所有事务都
符合两段锁协议
两段锁协议与防止死锁的一次封锁法
一次封锁法要求每个事务必须一次将所有要使用的数
据全部加锁，否则就不能继续执行，因此一次封锁法
遵守两段锁协议
但是两段锁协议并不要求事务必须一次将所有要使用
的数据全部加锁，因此遵守两段锁协议的事务可能发
生死锁