数据库知识点概要

绪论

1.1 数据库系统概述

1.1.1 四个基本概念

数据(Data)

数据(Data)是数据库中存储的基本对象

数据的定义
描述事物的符号记录
能够由计算机处理的数据、文本、图形、图像、音频、视频、学生的档案记录等

数据的含义称为数据的语义，数据与其语义是不可分的

数据库(Database)

数据库的定义
数据库(Database,简称DB)是长期储存在计算机内、有组织的、可共享的大量数据的集合

数据库的基本特征
数据按一定的数据模型组织、描述和储存
可为各种用户共享
冗余度较小
数据独立性较高
易扩展

数据库管理系统(DBMS)

位于用户与操作系统之间的一层数据管理软件。
是基础软件，是一个大型复杂的软件系统
科学地组织和存储数据、高效地获取和维护数据
例如Orcale、SQL Server、 MySQL、Access

数据定义功能
提供数据定义语言(DDL)
定义数据库中的数据对象
数据组织、存储和管理
分类组织、存储和管理各种数据
确定组织数据的文件结构和存取方式
实现数据之间的联系
提供多种存取方法提高存取效率

数据操纵功能
提供数据操纵语言(DML)
实现对数据库的基本操作 (查询、插入、删除和修改)

数据库的事务管理和运行管理
数据库在建立、运行和维护时由DBMS统一管理和控制
保证数据的安全性、完整性、多用户对数据的并发使用
发生故障后的系统恢复

数据库的建立和维护功能(实用程序)
数据库初始数据装载转换
数据库转储
介质故障恢复
数据库的重组织
性能监视分析等
其它功能
DBMS与网络中其它软件系统的通信
两个DBMS系统的数据转换
异构数据库之间的互访和互操作

数据库系统(DBS)

什么是数据库系统（Database System，简称DBS）
在计算机系统中引入数据库后的系统构成

扫描二维码关注公众号，回复： 12584396 查看本文章

数据库系统的构成
数据库
数据库管理系统（及其开发工具）
应用系统
数据库管理员

数据库系统的特点

数据结构化
数据的共享性高，冗余度低，易扩充
数据独立性高
数据由DBMS统一管理和控制

1.1.2 数据管理技术的产生和发展

什么是数据管理
对数据进行分类、组织、编码、存储、检索和维护
数据处理的中心问题

数据管理技术的发展过程
人工管理阶段(20世纪40年代中–50年代中)
文件系统阶段(20世纪50年代末–60年代中)
数据库系统阶段(20世纪60年代末–现在)

数据管理技术的发展动力
应用需求的推动
计算机硬件的发展
计算机软件的发展

人工管理阶段

特点
数据的管理者：用户（程序员），数据不保存
数据面向的对象：某一应用程序
数据的共享程度：无共享、冗余度极大
数据的独立性：不独立，完全依赖于程序
数据的结构化：无结构
数据控制能力：应用程序自己控制

文件系统阶段

特点
数据的管理者：文件系统，数据可长期保存
数据面向的对象：某一应用程序
数据的共享程度：共享性差、冗余度大
数据的结构化：记录内有结构,整体无结构
数据的独立性：独立性差，数据的逻辑结构改变必须
修改应用程序
数据控制能力：应用程序自己控制

数据库阶段

特点：
数据高度结构化
数据共享性高
高度数据独立性
具有专门管理系统：数据库管理系统（database management system，DBMS）

1.2 数据模型

1.2.1 概念模型

现实世界 信息世界 机器世界

现实世界 -----> 概念模型 数据库设计人员完成

概念模型 ----->逻辑模型 数据库设计人员完成

逻辑模型 -----> 物理模型 由DBMS完成

概念模型的用途
概念模型用于信息世界的建模
是现实世界到机器世界的一个中间层次
数据库设计人员和用户之间进行交流的语言

信息世界中的基本概念

(1) 实体（Entity）
客观存在并可相互区别的事物称为实体。
可以是具体的人、事、物或抽象的概念。
例如：一个学生、一门课等
(2) 属性（Attribute）
实体所具有的某一特性称为属性。
一个实体可以由若干个属性来刻画。
例如：学生实体由学号、姓名、专业名、性别等属性组成

(3) 码（Key）
唯一标识实体的属性集称为码。
例如：
一个属性是码：学生的学号就是学生实体的码，学生姓名不是码，因为可能有重名。
属性集合是码：选课实体由学号、课程号、成绩三个属性，码是学号+课程号。

(4) 域（Domain）
属性的取值范围称为该属性的域。
例如：性别域为（男，女）
(5) 实体型（Entity Type）
用实体名及其属性名集合来抽象和刻画同类实体称为实体型
例如：学生（学号、姓名、专业名）是一个实体型

(6) 实体集（Entity Set）
同一类型实体的集合称为实体集
例如：全体学生
(7) 联系（Relationship）
现实世界中事物内部以及事物之间的联系在信息世界中反映为实体内部的联系和实体之间的联系。
实体内部的联系通常是指组成实体的各属性之间的联系
实体之间的联系通常是指不同实体集之间的联系

1.2.2 数据模型

在数据库中用数据模型这个工具来抽象、表示和处理现实世界中的数据和信息。
通俗地讲数据模型就是现实世界的模拟。

数据模型应满足三方面要求
能比较真实地模拟现实世界
容易为人所理解
便于在计算机上实现

数据模型的组成要素

数据结构
数据操作
完整性约束条件

什么是数据结构
描述数据库的组成对象，以及对象之间的联系

描述的内容
与数据类型、内容、性质有关的对象
与数据之间联系有关的对象

数据结构是对系统静态特性的描述

数据操作
对数据库中各种对象(型)的实例(值)允许执行的
操作及有关的操作规则
数据操作的类型
查询
更新(包括插入、删除、修改)

数据的完整性约束条件
一组完整性规则的集合。
完整性规则：给定的数据模型中数据及其联系所具有的制约和储存规则
用以限定符合数据模型的数据库状态以及状态的变化，以保证数据的正确、有效、相容。

最常用的数据模型

层次模型(Hierarchical Model)
网状模型(Network Model)
关系模型(Relational Model)
面向对象模型(Object Oriented Model）

层次模型

层次模型是数据库系统中最早出现的数据模型
层次数据库系统的典型代表是IBM公司的IMS（Information Management System）数据库管理系统
层次模型用树形结构来表示各类实体以及实体间的联系

层次模型的优缺点

优点
层次模型的数据结构比较简单清晰
查询效率高，性能优于关系模型，不低于网状模型
层次数据模型提供了良好的完整性支持
缺点
多对多联系表示不自然
对插入和删除操作的限制多，应用程序的编写比较复杂
查询子女结点必须通过双亲结点
由于结构严密，层次命令趋于程序化

网状模型

网状数据库系统采用网状模型作为数据的组织方式
典型代表是DBTG系统：
亦称CODASYL系统
70年代由DBTG提出的一个系统方案
奠定了数据库系统的基本概念、方法和技术
实际系统
Cullinet Software Inc.公司的 IDMS
Univac公司的 DMS1100
Honeywell公司的IDS/2
HP公司的IMAGE

网状模型
满足下面两个条件的基本层次联系的集合：

1允许一个以上的结点无双亲；

2一个结点可以有多于一个的双亲。

网状数据模型的优缺点

优点
能够更为直接地描述现实世界，如一个结点可以有多个双亲
具有良好的性能，存取效率较高

缺点
结构比较复杂，而且随着应用环境的扩大，数据库的结构就变得越来越复杂，不利于最终用户掌握
DDL、DML语言复杂，用户不容易使用

关系模型

关系数据库系统采用关系模型作为数据的组织方式
1970年美国IBM公司San Jose研究室的研究员E.F.Codd首次提出了数据库系统的关系模型
计算机厂商新推出的数据库管理系统几乎都支持关系模型

关系数据模型的数据结构

关系（Relation）
一个关系对应通常说的一张表
元组（Tuple）
表中的一行即为一个元组
属性（Attribute）
表中的一列即为一个属性，给每一个属性起一个名称即属性名

主码（Key）
表中的某个属性组，它可以唯一确定一个元组。
域（Domain）
属性的取值范围。
分量
元组中的一个属性值。
关系模式
对关系的描述
关系名（属性1，属性2，…，属性n）
学生（学号，姓名，年龄，性别，系，年级）

关系数据模型的操纵与完整性约束

数据操作是集合操作，操作对象和操作结果都是关系
查询
插入
删除
更新

关系的完整性约束条件
实体完整性
参照完整性
用户定义的完整性

优点
建立在严格的数学概念的基础上
概念单一
实体和各类联系都用关系来表示
对数据的检索结果也是关系
关系模型的存取路径对用户透明
具有更高的数据独立性，更好的安全保密性
简化了程序员的工作和数据库开发建立的工作

缺点
存取路径对用户透明导致查询效率往往不如非
关系数据模型
为提高性能，必须对用户的查询请求进行优化
增加了开发DBMS的难度

1.3 数据库系统结构

1.3.1 三级模式结构

“型” 和“值” 的概念
型(Type)
对某一类数据的结构和属性的说明
值(Value)
是型的一个具体赋值
例如
学生记录型：
（学号，姓名，性别，系别，年龄，籍贯）
一个记录值：
（900201，李明，男，计算机，22，江苏）

数据库系统模式的概念

模式（Schema）
数据库逻辑结构和特征的描述
是型的描述
反映的是数据的结构及其联系
模式是相对稳定的
实例（Instance）
模式的一个具体值
反映数据库某一时刻的状态
同一个模式可以有很多实例
实例随数据库中的数据的更新而变动

数据库系统的三级模式结构

模式（Schema）

外模式（External Schema）

内模式（Internal Schema）

模式（Schema）

模式（也称逻辑模式）
数据库中全体数据的逻辑结构和特征的描述
所有用户的公共数据视图，综合了所有用户的需求
一个数据库只有一个模式
模式的地位：是数据库系统模式结构的中间层
与数据的物理存储细节和硬件环境无关
与具体的应用程序、开发工具及高级程序设计语言无关

外模式（External Schema）

外模式（也称子模式或用户模式）
数据库用户（包括应用程序员和最终用户）使用的局部数据的逻辑结构和特征的描述
数据库用户的数据视图，是与某一应用有关的数据的逻辑表示

外模式的地位：介于模式与应用之间
模式与外模式的关系：一对多
外模式通常是模式的子集
一个数据库可以有多个外模式。反映了不同的用户的应用需求、看待数据的方式、对数据保密的要求
对模式中同一数据，在外模式中的结构、类型、长度、保密级别等都可以不同
外模式与应用的关系：一对多
同一外模式也可以为某一用户的多个应用系统所使用
但一个应用程序只能使用一个外模式

内模式（Internal Schema）

内模式（也称存储模式）
是数据物理结构和存储方式的描述
是数据在数据库内部的表示方式
记录的存储方式（顺序存储，按照B树结构存储，
按hash方法存储）
索引的组织方式
数据是否压缩存储
数据是否加密
数据存储记录结构的规定
一个数据库只有一个内模式

数据库的二级映像功能与数据独立性

二级映像在DBMS内部实现这三个抽象层次的联系和转换
外模式／模式映像
模式／内模式映像

外模式／模式映象

模式：描述的是数据的全局逻辑结构
外模式：描述的是数据的局部逻辑结构
同一个模式可以有任意多个外模式
每一个外模式，数据库系统都有一个外模式／模式映象，定义外模式与模式之间的对应关系
映象定义通常包含在各自外模式的描述中

保证数据的逻辑独立性
当模式改变时，数据库管理员修改有关的外模式／模式映象，使外模式保持不变
应用程序是依据数据的外模式编写的，从而应用程序不必修改，保证了数据与程序的逻辑独立性，简称数据的逻辑独立性。

模式／内模式映象

模式／内模式映象定义了数据全局逻辑结构与存储结构之间的对应关系。
例如，说明逻辑记录和字段在内部是如何表示的
数据库中模式／内模式映象是唯一的
该映象定义通常包含在模式描述中

保证数据的物理独立性
当数据库的存储结构改变了（例如选用了另一种存储结构），数据库管理员修改模式／内模式映象，使模式保持不变
应用程序不受影响。保证了数据与程序的物理独立性，简称数据的物理独立性

1.4 小结

关系数据库

2.1 关系数据结构及形式化定义

2.1.1 关系

单一的数据结构----关系
现实世界的实体以及实体间的各种联系均用关系来表示
逻辑结构----二维表
从用户角度，关系模型中数据的逻辑结构是一张二维表
建立在集合代数的基础上

域（Domain）

笛卡尔积（Cartesian Product）

关系（Relation）

三类关系
基本关系（基本表或基表）
实际存在的表，是实际存储数据的逻辑表示
查询表
查询结果对应的表
视图表
由基本表或其他视图表导出的表，是虚表，不对
应实际存储的数据

2.1.2 关系模式

关系模式（Relation Schema）是型
关系是值
关系模式是对关系的描述
元组集合的结构
属性构成
属性来自的域
属性与域之间的映象关系
元组语义以及完整性约束条件
属性间的数据依赖关系集合

​ R（U，D，DOM，F）
​ R 关系名
​ U 组成该关系的属性名集合
​ D 属性组U中属性所来自的域
​ DOM 属性向域的映象集合
​ F 属性间的数据依赖关系集合

2.2 关系操作

常用的关系操作
查询：选择、投影、连接、除、并、交、差
数据更新：插入、删除、修改
查询的表达能力是其中最主要的部分
选择、投影、并、差、笛卡尔积是5种基本操作

关系操作的特点
集合操作方式：操作的对象和结果都是集合，一次一集合的方式

关系代数语言
用对关系的运算来表达查询要求
代表：ISBL
关系演算语言：用谓词来表达查询要求
元组关系演算语言
谓词变元的基本对象是元组变量
代表：APLHA, QUEL
域关系演算语言
谓词变元的基本对象是域变量
代表：QBE
具有关系代数和关系演算双重特点的语言
代表：SQL（Structured Query Language）

2.3 关系的完整性

2.3.1 关系的三类完整性约束

实体完整性和参照完整性：
关系模型必须满足的完整性约束条件
称为关系的两个不变性，应该由关系系统自动支持
用户定义的完整性：
应用领域需要遵循的约束条件，体现了具体领域中的语义约束

2.3.2 实体完整性

2.3.3 参照完整性

2.3.4 用户定义的完整性

2.4 关系代数

概述
传统的集合运算
专门的关系运算

2.5 小结

关系数据库语言SQL

3.1 SQL语言概况

SQL简介
结构化查询语言SQL（Structured Query Language）是一个通用的、功能极强的关系数据库语言。目前已成为关系数据库的标准语言。
SQL语言的版本包括：SQL-86、SQL-89、SQL-92， SQL-99、SQL2003

SQL特点
1 综合统一：SQL语言集数据查询（data query）、数据操纵（data manipulation）、数据定义（data definition）和数据控制（data control）功能于一体。
2 高度非过程化：SQL只要提出“做什么”，无须了解存取路径。存取路径的选择以及SQL的操作过程由系统自动完成。
3 SQL采用集合操作方式： 操作对象、查找结果可以是元组的集合、一次插入、删除、更新操作的对象可以是元组的集合。

4 以同一种语法结构提供两种使用方式:
SQL是独立的语言: 能够独立地用于联机交互的使用方式
SQL又是嵌入式语言:SQL能够嵌入到高级语言（例如C，C++，Java）程序中，供程序员设计程序时使用

5 语言简洁，易学易用

SQL的基本概念
SQL语言支持关系数据库三级模式结构。其中外模式对应于视图，模式对应于基本表，内模式对应于存储文件。

SQL的基本功能
（1）数据定义功能
● 基本表的建立、取消与更改。
● 索引的建立与取消。
● 视图的创建与取消。
（2）数据查询功能（包括数据表和视图）
（3）数据更新功能
●数据插入、删除、修改功能。
（4）数据控制功能
●数据库保护功能（安全性和完整性保护）。
●事务管理功能（数据库故障恢复和并发事务处理）。

3.2 SQL数据定义语言

索引类型：
唯一索引：不允许其中任何两行具有相同值的索引 。
聚簇索引： 其物理存放顺序与主键顺序一致。因为数据只有一个物理存放顺序，所以一个表只有一个聚簇索引。 默认主键为簇索引，所以一般建立的都为非簇索引。
非聚簇索引：非聚集索引并不改变其所在表的物理结构，而是额外生成一个聚集索引的B树结构，叶节点的信息也是按聚集索引的键值按顺序存储，叶节点的信息存储的并不是实际的数据，是相应数据对象的存放地址指针

3.3 SQL数据查询语言

3.4 数据更新

3.5 视图管理

数据库安全性

4.1 计算机安全性概述

为计算机系统建立和采取的各种安全保护措施，以保护计算机系统中的硬件、软件及数据，防止其因偶然或恶意的原因使系统遭到破坏，数据遭到更改或泄露等。

4.1.1 计算机系统的三类安全性问题

技术安全类
管理安全类
政策法律类

4.1.2 安全标准简介

TCSEC/TDI标准的基本内容
TCSEC/TDI，从四个方面来描述安全性级别划分的指标
安全策略
责任
保证
文档

CC
提出国际公认的表述信息技术安全性的结构
把信息产品的安全要求分为
安全功能要求
安全保证要求

CC文本组成
简介和一般模型
安全功能要求
安全保证要求

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-9miAAyUd-1592829535695)(C:\Users\ASUS\AppData\Roaming\Typora\typora-user-images\image-20200617233104169.png)]

4.2 数据库安全性控制

4.2.1 用户标识与鉴别

系统提供的最外层安全保护措施

1 用户标识

2 口令
系统核对口令以鉴别用户身份

3 用户名和口令易被窃取
每个用户预先约定好一个计算过程或者函数

4 存取控制机制组成
定义用户权限
合法权限检查

5 用户权限定义和合法权检查机制一起组成了 DBMS的安全子系统

4.2.2 存取控制

常用存取控制方法
自主存取控制（Discretionary Access Control ，简称DAC）
C2级
灵活
强制存取控制（Mandatory Access Control，简称 MAC）
B1级
严格

4.2.3 自主存取控制方法

通过 SQL 的 GRANT 语句和 REVOKE 语句实现
用户权限组成
数据对象
操作类型
定义用户存取权限：定义用户可以在哪些数据库对象上进行哪些类型的操作
定义存取权限称为授权

发出GRANT：
DBA
数据库对象创建者（即属主Owner）
拥有该权限的用户

按受权限的用户
一个或多个具体用户
PUBLIC（全体用户）

自主存取控制缺点

可能存在数据的“无意泄露”
原因：这种机制仅仅通过对数据的存取权限来进行安全控制，而数据本身并无安全性标记
解决：对系统控制下的所有主客体实施强制存取控制策略

4.2.4 授权与回收

数据库角色：被命名的一组与数据库操作相关的权限
角色是权限的集合
可以为一组具有相同权限的用户创建一个角色
简化授权的过程

4.2.5 数据库角色

4.2.6 强制存取控制方法

强制存取控制（MAC)
1保证更高程度的安全性
2用户能不能直接感知或进行控制
3适用于对数据有严格而固定密级分类的部门
军事部门
政府部门

主体是系统中的活动实体
DBMS所管理的实际用户
代表用户的各进程

客体是系统中的被动实体，是受主体操纵的
文件
基表
索引
视图

敏感度标记（Label）
绝密（Top Secret）
机密（Secret）
可信（Confidential）
公开（Public）

主体的敏感度标记称为许可证级别（Clearance Level）
客体的敏感度标记称为密级（Classification Level）

强制存取控制规则
(1)仅当主体的许可证级别大于或等于客体的密级时，该主体才能读取相应的客体
(2)仅当主体的许可证级别等于客体的密级时，该主体才能写相应的客体
修正规则
主体的许可证级别 <=客体的密级  主体能写客体

规则的共同点
禁止了拥有高许可证级别的主体更新低密级的数
据对象

MAC与DAC

DAC与MAC共同构成DBMS的安全机制
实现MAC时要首先实现DAC
原因：较高安全性级别提供的安全保护要包含较低级别的所有保护

4.3 视图机制

把要保密的数据对无权存取这些数据的用户隐藏起来，对数据提供一定程度的安全保护
间接实现了支持存取谓词的用户权限定义

4.4 审计（Audit）

1 审计日志（Audit Log）
将用户对数据库的所有操作记录在上面
2 DBA利用审计日志
找出非法存取数据的人、时间和内容
3 C2以上安全级别的DBMS必须具有

4.5 数据加密

数据加密
防止数据库中数据在存储和传输中失密的有效手段

加密的基本思想
根据一定的算法将原始数据（明文）变换为不可直接识别的格式（密文），从而使得不知道解密算法的人无法获知数据的内容。

加密方法
替换方法：使用密钥将明文中的每一个字符转换为密文中的一个字符。
置换方法：将明文的字符按不同的顺序重新排列。
混合方法：替换+置换

DBMS中的数据加密

4.6 统计数据库安全性

1 统计数据库
允许用户查询聚集类型的信息（如合计、平均值等）
不允许查询单个记录信息
例如：查询“程序员平均工资是多少”合法，查询“程序员张勇的工资是多少” 不合法。

2 统计数据库中特殊的安全性问题
隐蔽的信息通道
能从合法的查询中推导出不合法的信息
例如合法查询：
本公司共有多少女高级程序员？
本公司女高级程序员平均工资是多少？
当公司只有一个女高级程序员，那就可以获知该女高级程序员工资信息。

3 定义查询规则：
规则1：任何查询至少要涉及N(N足够大)个以上的记录
规则2：任意两个查询的相交数据项不能超过M个
规则3：任一用户的查询次数不能超过1+(N-2)/M

4 数据库安全机制的设计目标：
试图破坏安全的人所花费的代价 >> 得到的利益

4.7 小结

实现数据库系统安全性的技术和方法
存取控制技术
视图技术
审计技术

数据库完整性

5.1 实体完整性

5.1.1 实体完整性定义

关系模型的实体完整性
CREATE TABLE中用PRIMARY KEY定义
单属性构成的码有两种说明方法
定义为列级约束条件
定义为表级约束条件
对多个属性构成的码只有一种说明方法
定义为表级约束条件

插入或对主码列进行更新操作时，RDBMS按照实体完整性规则自动进行检查。包括：
1 检查主码值是否唯一，如果不唯一则拒绝插入或修改

​ 2检查主码的各个属性是否为空，只要有一个为空就拒绝插入或修改

5.1.2 实体完整性检查和违约处理

检查记录中主码值是否唯一的一种方法是进行全表扫描

索引:为了避免全表扫描， DBMS一般在主码中建立索引，如下图的B+树索引

5.2 参照完整性

5.2.1 参照完整性定义

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

5.2.2 参照完整性检查和违约处理

5.3 用户定义的完整性

5.3.1 属性上的约束条件的定义

CREATE TABLE时定义
列值非空（NOT NULL）
列值唯一（UNIQUE）
检查列值是否满足一个布尔表达式（CHECK）

5.3.2 属性上的约束条件检查和违约处理

插入元组或修改属性的值时，RDBMS检查属性上的约束条件是否被满足
如果不满足则操作被拒绝执行

5.3.3 元组上的约束条件的定义

在CREATE TABLE时可以用CHECK短语定义元组上的约束条件，即元组级的限制
同属性值限制相比，元组级的限制可以设置不同属性之间的取值的相互约束条件

5.3.4元组上的约束条件检查和违约处理

插入元组或修改属性的值时，RDBMS检查元组上的约束条件是否被满足
如果不满足则操作被拒绝执行

5.4 完整性约束命名子句

5.5 触发器

5.6 小结

数据库的完整性是为了保证数据库中存储的数据是正确的

RDBMS完整性实现的机制
完整性约束定义机制
完整性检查机制
违背完整性约束条件时RDBMS应采取的动作

关系数据理论

6.1 问题的提出

关系数据库逻辑设计
针对具体问题，如何构造一个适合于它的数据模式
数据库逻辑设计的工具──关系数据库的规范化理论

关系模式由五部分组成，即它是一个五元组：
R(U, D, DOM, F)
R： 关系名
U： 组成该关系的属性名集合
D： 属性组U中属性所来自的域
DOM： 属性向域的映象集合
F： 属性间数据的依赖关系集合

1. 数据依赖
   一个关系内部属性与属性之间的约束关系
   现实世界属性间相互联系的抽象
   数据内在的性质
   是数据库模式设计的关键
   语义的体现
2. 数据依赖的类型
   函数依赖（Functional Dependency，简记为FD）
   多值依赖（Multivalued Dependency，简记为MVD）

关系模式R（U, D, DOM, F）
简化为一个三元组：
R（U, F）
当且仅当U上的一个关系r满足F时，r称为关系模式 R（U, F）的一个关系

关系模式Student<U, F>中存在的问题

1. 数据冗余太大
   ——如所在的系、系主任名字不断重复出现
2. 更新异常（Update Anomalies）
   ——如系主任改变后，需要修改多行数据
3. 插入异常（Insertion Anomalies）
   ——如一个系没有学生，则无法输入该系信息
4. 删除异常（Deletion Anomalies）
   ——如某个系学生都毕业后，删除该系学生信息的时候需要把系主任信息也删除

6.2 规范化

​ 规范化理论正是用来改造关系模式，通过分解关系模式来消除其中不合适的数据依赖，以解决插入异常、删除异常、更新异常和数据冗余问题

6.2.1 函数依赖

平凡函数依赖与非平凡函数依赖
完全函数依赖与部分函数依赖
传递函数依赖

非平凡函数依赖： (Sno, Cno) → Grade
平凡函数依赖： (Sno, Cno) → Sno
(Sno, Cno) → Cno

在R(U)中，如果X→Y，并且对于X的任何一个真子集X’，都有X’ Y, 则称Y对X完全函数依赖，记作
X F Y。
若X→Y，但Y不完全函数依赖于X，则称Y对X部分函数依赖，记作X P Y

6.2.2 码

6.2.3 范式

范式是符合某一种级别的关系模式的集合
关系数据库中的关系必须满足一定的要求。满足不同程度要求的为不同范式
范式的种类：
第一范式(1NF)
第二范式(2NF)
第三范式(3NF)
BC范式(BCNF)
第四范式(4NF)
第五范式(5NF)

1NF的定义
如果一个关系模式R的所有属性都是不可分的基本数据项，则R∈1NF
第一范式是对关系模式的最起码的要求。不满足第一范式的数据库模式不能称为关系数据库
但是满足第一范式的关系模式并不一定是一个好的关系模式

缺点

(1) 插入异常
没有选课的学生插入不进去信息

(2) 删除异常
假如要删除选课信息，可能会把学生信息删除掉

(3) 数据冗余度大
学生所在的系和住处随着选课信息不断重复出现

(4) 修改复杂
学生换一个系需要修改多行信息

6.2.4 2NF

2NF的定义
定义6.6 若R∈1NF，且每一个非主属性完全函数依赖于码，则R∈2NF

6.2.5 3NF

若R∈3NF，则每一个非主属性既不部分依赖于码也不传递依赖于码，也就是R∈2NF。

6.2.6 BCNF

定义6.8 关系模式R<U，F>∈1NF，若X→Y且Y  X时X必含有码，则R<U，F> ∈BCNF。

等价于：每一个决定属性因素都包含码

若R∈BCNF
所有非主属性对每一个码都是完全函数依赖
所有的主属性对每一个不包含它的码，也是完全函数依赖
没有任何属性完全函数依赖于非码的任何一组属性

6.2.7 多值依赖

Teaching具有唯一候选码(C，T，B)， 即全码
Teaching∈BCNF

6.2.8 4NF

6.2.9 规范化小结

6.3 数据依赖的公理系统

6.4 小结

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-USqWXwCw-1592829535701)(C:\Users\ASUS\AppData\Roaming\Typora\typora-user-images\image-20200618232839521.png)]

数据库设计

7.1 数据库设计概述

数据库设计
数据库设计是指对于一个给定的应用环境，构造（设计）优化的数据库逻辑模式和物理结构，并据此建立数据库及其应用系统，使之能够有效地存储和管理数据，满足各种用户的应用需求，包括信息管理要求和数据操作要求。
目标：为用户和各种应用系统提供一个信息基础设施和高效率的运行环境

数据库建设的基本规律
三分技术，七分管理，十二分基础数据
管理
数据库建设项目管理
企业（即应用部门）的业务管理
基础数据
收集、入库
更新新的数据

结构（数据）设计和行为（处理）设计相结合
将数据库结构设计和数据处理设计密切结合

需求分析和概念设计独立于任何数据库管理系统
逻辑设计和物理设计与选用的DBMS密切相关

7.2 需求分析

通过调查和分析，了解用户的信息需求和处理需求，并以数据流图、数据字典等形式描述
最困难、最耗费时间的一步

7.2.1 需求分析的任务

详细调查现实世界要处理的对象（组织、部门、企业等）
充分了解原系统（手工系统或计算机系统）
明确用户的各种需求
确定新系统的功能
充分考虑今后可能的扩充和改变

调查的重点是“数据”和“处理”，获得用户对数据库要求
信息要求
处理要求
安全性与完整性要求

确定用户最终需求
用户缺少计算机知识
设计人员缺少用户的专业知识
解决方法
设计人员必须不断深入地与用户进行交流

7.2.2 需求分析的方法

⑴ 调查组织机构情况
⑵ 调查各部门的业务活动情况。
⑶ 在熟悉业务活动的基础上，协助用户明确对新系统的各种要求。
⑷ 确定新系统的边界

常用调查方法

(1)跟班作业
(2)开调查会
(3)请专人介绍
(4)询问
(5)设计调查表请用户填写
(6)查阅记录

结构化分析方法（Structured Analysis，简称SA方法）
从最上层的系统组织机构入手
自顶向下、逐层分解分析系统

7.2.3 数据流图和数据字典

数据流图：表达数据和处理的关系

数据流图（简称DFD）是结构化分析方法中使用的工具,它以图形的方式描绘数据在系统中流动和处理的过程。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ArmG7njd-1592829535704)(C:\Users\ASUS\AppData\Roaming\Typora\typora-user-images\image-20200617160316949.png)]

数字字典：系统中各类数据描述的集合

7.2.3 数据流图

7.3 概念结构设计

通过对用户需求进行综合、归纳与抽象，形成一个独立于具体DBMS的概念模型
整个数据库设计的关键，E-R模型是概念模式设计工具

概念结构设计的特点
(1) 能真实、充分地反映现实世界
(2) 易于理解
(3) 易于更改
(4) 易于向关系、网状、层次等各种数据模型转换

7.3.1 概念结构

E-R模型

实体

属性

联系

7.3.2 概念结构设计的方法与步骤

设计概念结构的四类方法

自顶向下

自底向上

逐步扩张

混合策略

7.3.3 数据抽象与局部视图设计

三种常用抽象

分类（Classification）
定义某一类概念作为现实世界中一组对象的类型
抽象了对象值和型之间的“is member of”的语义

聚集（Aggregation）
定义某一类型的组成成分
抽象了对象内部类型和成分之间“is part of”的语义

概括（Generalization）
定义类型之间的一种子集联系
抽象了类型之间的“is subset of”的语义
继承性

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-emf8LzTT-1592829535711)(C:\Users\ASUS\AppData\Roaming\Typora\typora-user-images\image-20200617161359838.png)]

7.3.4 视图的集成

逐一设计分E-R图

视图集成的两种方式

多个分E-R图一次集成

逐步集成

分E-R图冲突

命名冲突
同名异义：不同意义的对象在不同的局部应用中具有相同的名字
异名同义（一义多名）：同一意义的对象在不同的局部应用中具有不同的名字

属性冲突：
属性域冲突，相同的属性在不同E-R图中有不同的域
属性取值单位冲突

结构冲突：
同一对象在不同应用中具有不同的抽象：同一个概念在一处为实体而在另一处为属性或者联系
同一实体在不同的局部E-R图中所包含的属性个数和属性的排列次序不完全相同

7.4 逻辑结构设计

将概念结构转换为某个DBMS所支持的数据模型，并对其进行优化

7.4.1 E-R图向关系模型的转换

7.4.2 数据模型的优化

确定数据依赖

消除 冗余的联系

确定所属范式

按照需求分析阶段得到的各种应用对数据处理的要求，分析对于这样的应用环境这些模式是否合适，确定是否要对它们进行合并或分解。

常用分解方法
水平分解

什么是水平分解
把(基本)关系的元组分为若干子集合，定义每个子集合为一个子关系，以提高系统的效率

水平分解的适用范围
满足“80/20原则”的应用
并发事务经常存取不相交的数据

垂直分解

什么是垂直分解
把关系模式R的属性分解为若干子集合，形成若干子关系模式
垂直分解的适用范围
取决于分解后R上的所有事务的总效率是否得到了提高

7.4.3 设计用户子模式

7.5 数据库的物理设计

为逻辑数据模型选取一个最适合应用环境的物理结构（包括存储结构和存取方法）

7.5.1 数据库物理设计的内容和方法

关系数据库物理设计的内容
为关系模式选择存取方法(建立存取路径)
设计关系、索引等数据库文件的物理存储结构

7.5.2 关系模式存取方法选择

数据库系统是多用户共享的系统，对同一个关系要建立多条存取路径才能满足多用户的多种应用要求
物理设计的任务之一就是要确定选择哪些存取方法，即建立哪些存取路径

DBMS常用存取方法
索引方法
目前主要是B+树索引方法
经典存取方法，使用最普遍
聚簇（Cluster）方法
HASH方法

7.5.3 确定数据库的存储结构

7.6 数据库实施和维护

运用DBMS提供的数据库语言（如SQL）及宿主语言（如JAVA），根据逻辑设计和物理设计的结果
建立数据库
编制与调试应用程序
组织数据入库
进行试运行

数据库应用系统经过试运行后即可投入正式运行
在数据库系统运行过程中必须不断地对其进行评价、调整与修改

7.7 小结

数据库恢复技术

10.1 事务的基本概念

定义
一个数据库操作序列
一个不可分割的工作单位
恢复和并发控制的基本单位

事务的特性(ACID特性)

原子性（Atomicity）：一个事务对于数据库的所有操作是一个不可分割的操作整体，这些操作要么全执行，要么全不执行。这也是事务最基本要求。

一致性（Consistency）：数据库中数据不因事务的执行而受到破坏，事务执行的结果应当使得数据库由一种一致性达到另一种新的一致性。数据的一致性保证数据库的完整性。

隔离性（Isolation）：事务的并发执行与这些事务单独执行的结果一样。事务的隔离性是事务并发控制的技术基础。

持续性（Durability ）：事务对数据库的更新应永久地反映在数据库中。事务的持久性保证数据库可恢复。

事务的创建

事务可以由下述四个基本操作组成
事务开始(starting)：事务开始执行。
事务执行(read and write)：事务进行数据的读或写操作。
事务提交(commit)：事务完成所有数据操作，同时保存操作结果，它标志着事务成功完成。
事务回滚(rollback)：事务未完成所有数据操作，重新返回事务开始，它标志着事务的撤销。

10.2 故障的种类

事务内部的故障

有的是可以通过事务程序本身发现的(见下面转账事
务的例子)
有的是非预期的

系统故障

系统故障
称为软故障，是指造成系统停止运转的任何事件，使得
系统要重新启动。
整个系统的正常运行突然被破坏
所有正在运行的事务都非正常终止
不破坏数据库
内存中数据库缓冲区的信息全部丢失

特定类型的硬件错误（如CPU故障）
操作系统故障
DBMS代码错误
系统断电

发生系统故障时，事务未提交
恢复策略：强行撤消（UNDO）所有未完成事务
发生系统故障时，事务已提交，但缓冲区中的信息尚未完全写回到磁盘上。
恢复策略：重做（REDO）所有已提交的事务

介质故障

介质故障
称为硬故障，指外存故障
磁盘损坏
磁头碰撞
操作系统的某种潜在错误
瞬时强磁场干扰

介质故障的恢复

装入数据库发生介质故障前某个时刻的数据副本
重做自此时始的所有成功事务，将这些事务已提交的结果重新记入数据库

计算机病毒

计算机病毒
一种人为的故障或破坏，是一些恶作剧者研制的一种计算机程序
可以繁殖和传播
危害
破坏、盗窃系统中的数据
破坏系统文件

10.3 恢复的实现技术

恢复操作的基本原理：冗余
利用存储在系统其它地方的冗余数据来重建数据库中已被破坏或不正确的那部分数据
恢复机制涉及的关键问题
如何建立冗余数据
数据转储（backup）
登录日志文件（logging）
如何利用这些冗余数据实施数据库恢复

数据转储

转储是指DBA将整个数据库复制到磁带或另一个磁盘上保存起来的过程，备用的数据称为后备副本或后援副本
如何使用
数据库遭到破坏后可以将后备副本重新装入
重装后备副本只能将数据库恢复到转储时的状态

各类故障，对数据库的影响有两种可能性
一是数据库本身被破坏
二是数据库没有被破坏，但数据可能不正确，这是由于事务的运行被非正常终止造成的。

转储方法

1．静态转储与动态转储
2．海量转储与增量转储

静态转储

在系统中无运行事务时进行的转储操作
转储开始时数据库处于一致性状态
转储期间不允许对数据库的任何存取、修改活动
得到的一定是一个数据一致性的副本
优点：实现简单
缺点：降低了数据库的可用性
转储必须等待正运行的用户事务结束
新的事务必须等转储结束

动态转储

转储操作与用户事务并发进行
转储期间允许对数据库进行存取或修改
优点
不用等待正在运行的用户事务结束
不会影响新事务的运行
动态转储的缺点
不能保证副本中的数据正确有效
[例]在转储期间的某个时刻Tc，系统把数据A=100转储到磁带上，而在下一时刻Td，某一事务将A改为200。转储结束后，后备副本上的A已是过时的数据了

利用动态转储得到的副本进行故障恢复
需要把动态转储期间各事务对数据库的修改活动登记下来，建立日志文件
后备副本加上日志文件才能把数据库恢复到某一时刻的正确状态

海量转储与增量转储

海量转储: 每次转储全部数据库

增量转储: 只转储上次转储后更新过的数据

海量转储与增量转储比较
从恢复角度看，使用海量转储得到的后备副本进行恢复往往更方便
但如果数据库很大，事务处理又十分频繁，则增量转储方式更实用更有效

登记日志文件

一、日志文件的格式和内容
二、日志文件的作用
三、登记日志文件

日志文件的格式和内容

什么是日志文件
日志文件(log)是用来记录事务对数据库的更新操作的文
件

日志文件的格式
以记录为单位的日志文件
以数据块为单位的日志文件

日志文件的格式和内容

以记录为单位的日志文件内容
各个事务的开始标记(BEGIN TRANSACTION)
各个事务的结束标记(COMMIT或ROLLBACK)
各个事务的所有更新操作
以上均作为日志文件中的一个日志记录 (log record)

以记录为单位的日志文件，每条日志记录的内容
事务标识（标明是哪个事务）
操作类型（插入、删除或修改）
操作对象（记录内部标识）
更新前数据的旧值（对插入操作而言，此项为空值）
更新后数据的新值（对删除操作而言, 此项为空值）

以数据块为单位的日志文件，每条日志记录的内容
事务标识（标明是那个事务）
被更新的数据块

日志文件的作用

进行事务故障恢复
进行系统故障恢复
协助后备副本进行介质故障恢复

登记日志文件

基本原则
登记的次序严格按并行事务执行的时间次序
必须先写日志文件，后写数据库
写日志文件操作：把表示这个修改的日志记录
写到日志文件
写数据库操作：把对数据的修改写到数据库中

为什么要先写日志文件
写数据库和写日志文件是两个不同的操作
在这两个操作之间可能发生故障
如果先写了数据库修改，而在日志文件中没有登记下这个修改，则以后就无法恢复这个修改了
如果先写日志，但没有修改数据库，按日志文件恢复时只不过是多执行一次不必要的UNDO操作，并不会影响数据库的正确性

10.4 恢复策略

事务故障的恢复

事务故障：事务在运行至正常终止点前被终止
恢复方法
由恢复子系统应利用日志文件撤消（UNDO）此事务已对数据库进行的修改
事务故障的恢复由系统自动完成，对用户是透明的，不需要用户干预

1. 反向扫描文件日志（即从最后向前扫描日志文件），查找该事务的更新操作。

2. 3. 继续反向扫描日志文件，查找该事务的其他更新操作，并做同样处理。

3. 对该事务的更新操作执行逆操作。即将日志记录中“更新前的值” 写入数据库。
   插入操作， “更新前的值”为空，则相当于做删除操作
   删除操作，“更新后的值”为空，则相当于做插入操作
   若是修改操作，则相当于用修改前值代替修改后值

4. 如此处理下去，直至读到此事务的开始标记，事务故障恢复就完成了。

系统故障的恢复

系统故障造成数据库不一致状态的原因
未完成事务对数据库的更新已写入数据库
已提交事务对数据库的更新还留在缓冲区没来得及写入数据库
恢复方法

1. Undo 故障发生时未完成的事务

2. Redo 已完成的事务
   系统故障的恢复由系统在重新启动时自动完成，不需要用户干预

1正向扫描日志文件（即从头扫描日志文件）
重做(REDO) 队列: 在故障发生前已经提交的事务
这些事务既有BEGIN TRANSACTION记录，也有COMMIT记录
撤销 (Undo)队列:故障发生时尚未完成的事务
这些事务只有BEGIN TRANSACTION记录，无相应的COMMIT记录

2. 对撤销(Undo)队列事务进行撤销(UNDO)处理
   反向扫描日志文件，对每个UNDO事务的更新操作执行逆操作
   即将日志记录中“更新前的值”写入数据库

   3. 对重做(Redo)队列事务进行重做(REDO)处理
      正向扫描日志文件，对每个REDO事务重新执行登记的操作
      即将日志记录中“更新后的值”写入数据库

介质故障的恢复

1.重装数据库
2.重做已完成的事务

恢复步骤

1. 装入最新的后备数据库副本(离故障发生时刻最近的转储副本) ，使数据库恢复到最近一次转储时的一致性状态。
   对于静态转储的数据库副本，装入后数据库即处于一致性状态
   对于动态转储的数据库副本，还须同时装入转储时刻的日志文件副本，利用与恢复系统故障的方法（即REDO+UNDO），才能将数据库恢复到一致性状态。

2. 装入有关的日志文件副本(转储结束时刻的日志文件副本) ，重做已完成的事务。
   首先扫描日志文件，找出故障发生时已提交的事务的标识，将其记入重做队列。
   然后正向扫描日志文件，对重做队列中的所有事务进行重做处理。即将日志记录中“更新后的值”写入数据库

介质故障的恢复需要DBA介入
DBA的工作
重装最近转储的数据库副本和有关的各日志文件副本
执行系统提供的恢复命令
具体的恢复操作仍由DBMS完成

10.5 小结

如果数据库只包含成功事务提交的结果，就说数据库处于一致性状态。保证数据一致性是对数据库的最基本的要求。
事务是数据库的逻辑工作单位
DBMS保证系统中一切事务的原子性、一致性、隔离性和持续性

DBMS必须对事务故障、系统故障和介质故障进行恢复
恢复中最经常使用的技术：数据库转储和登记日志文件
恢复的基本原理：利用存储在后备副本、日志文件和数据库镜像中的冗余数据来重建数据库

常用恢复技术
事务故障的恢复
UNDO
系统故障的恢复
UNDO + REDO
介质故障的恢复
重装备份并恢复到一致性状态 + REDO

并发控制

11.1 并发控制概述

并发控制机制的任务
对并发操作进行正确调度
保证事务的隔离性
保证数据库的一致性

并发操作带来的数据不一致性
丢失修改（Lost Update）
不可重复读（Non-repeatable Read）
读“脏”数据（Dirty Read）

记号
R(x):读数据x
W(x):写数据x

11.2 封锁

封锁就是事务T在对某个数据对象（例如表、记录等）操作之前，先向系统发出请求，对其加锁
加锁后事务T就对该数据对象有了一定的控制，在事务T释放它的锁之前，其它的事务不能更新此数据对象。

一个事务对某个数据对象加锁后究竟拥有什么样的控制由封锁的类型决定。
基本封锁类型
排它锁（Exclusive Locks，简记为X锁）
共享锁（Share Locks，简记为S锁）

锁的相容矩阵

在锁的相容矩阵中：
最左边一列表示事务T1已经获得的数据对象上的锁的类型，其中横线表示没有加锁。
最上面一行表示另一事务T2对同一数据对象发出的封锁请求。
T2的封锁请求能否被满足用矩阵中的Y和N表示
Y表示事务T2的封锁要求与T1已持有的锁相容，封锁请求可以满足
N表示T2的封锁请求与T1已持有的锁冲突，T2的请求被拒绝

预防死锁的方法

一次封锁法

要求每个事务必须一次将所有要使用的数据全部加锁，否则就不能继续执行
存在的问题
降低系统并发度
难于事先精确确定封锁对象

顺序封锁法

顺序封锁法是预先对数据对象规定一个封锁顺序，所有事务都按这个顺序实行封锁。
顺序封锁法存在的问题
维护成本
数据库系统中封锁的数据对象极多，并且在不断地变化。
难以实现：很难事先确定每一个事务要封锁哪些对象

在操作系统中广为采用的预防死锁的策略并不很适合数据库的特点
DBMS在解决死锁的问题上更普遍采用的是诊断并解除死锁的方法

死锁的诊断与解除

死锁的诊断
超时法
事务等待图法

超时法

如果一个事务的等待时间超过了规定的时限，就认为发生了死锁
优点：实现简单
缺点
时限设置太短，有可能误判死锁
时限若设置得太长，死锁发生后不能及时发现

等待图法

解除死锁
选择一个处理死锁代价最小的事务，将其撤消
释放此事务持有的所有的锁，使其它事务能继续运行下去

11.3 活锁和死锁

11.4 并发调度的可串行性

可串行化(Serializable)调度
多个事务的并发执行是正确的，当且仅当其结果与按某一次序串行地执行这些事务时的结果相同
可串行性(Serializability)
是并发事务正确调度的准则
一个给定的并发调度，当且仅当它是可串行化的，才认为是正确调度

冲突可串行化调度是可串行化调度的充分条件，不是必要条件。还有不满足冲突可串行化条件的可串行化调度

11.5 两段锁协议

封锁协议
运用封锁方法时，对数据对象加锁时需要约定一些规则
何时申请封锁
持锁时间
何时释放封锁等
两段封锁协议(Two-Phase Locking，简称2PL)是最常用的一种封锁协议，理论上证明使用两段封锁协议产生的是可串行化调度

两段锁协议
指所有事务必须分两个阶段对数据项加锁和解锁
在对任何数据进行读、写操作之前，事务首先要获得对该数据的封锁
在释放一个封锁之后，事务不再申请和获得任何其他封锁

“两段”锁的含义
事务分为两个阶段
第一阶段是获得封锁，也称为扩展阶段
事务可以申请获得任何数据项上的任何类型的锁，但是不能释放任何锁
第二阶段是释放封锁，也称为收缩阶段
事务可以释放任何数据项上的任何类型的锁，但是不能再申请任何锁

事务遵守两段锁协议是可串行化调度的充分条件，而不是必要条件。
若并发事务都遵守两段锁协议，则对这些事务的任何并发调度策略都是可串行化的
若并发事务的一个调度是可串行化的，不一定所有事务都符合两段锁协议

11.6 封锁的粒度

封锁粒度

封锁对象的大小称为封锁粒度(Granularity)
封锁的对象：逻辑单元，物理单元
例：在关系数据库中，封锁对象：
逻辑单元: 属性值、属性值集合、元组、关系、索引项、整个索引、整个数据库等
物理单元：页（数据页或索引页）、物理记录等

选择封锁粒度原则

封锁粒度与系统的并发度和并发控制的开销密切相关。
封锁的粒度越大，数据库所能够封锁的数据单元就越少，并发度就越小，系统开销也越小；
封锁的粒度越小，并发度较高，但系统开销也就越大

多粒度封锁(Multiple Granularity Locking)
在一个系统中同时支持多种封锁粒度供不同的事务选择
选择封锁粒度
同时考虑封锁开销和并发度两个因素，适当选择封锁粒度
需要处理多个关系的大量元组的用户事务：以数据库为封锁单位
需要处理大量元组的用户事务：以关系为封锁单元
只处理少量元组的用户事务：以元组为封锁单位

多粒度树
以树形结构来表示多级封锁粒度
根结点是整个数据库，表示最大的数据粒度
叶结点表示最小的数据粒度

意向锁

引进意向锁（intention lock）目的
提高对某个数据对象加锁时系统的检查效率

如果对一个结点加意向锁，则说明该结点的下层结点正在被加锁
对任一结点加基本锁，必须先对它的上层结点加意向锁
例如，对任一元组加锁时，必须先对它所在的数据库和关系加意向锁

常用意向锁

意向共享锁(Intent Share Lock，简称IS锁)
意向排它锁(Intent Exclusive Lock，简称IX锁)
共享意向排它锁(Share Intent Exclusive Lock，简称SIX锁)

IS锁
如果对一个数据对象加IS锁，表示它的后裔结点拟（意向）加S锁

IX锁
如果对一个数据对象加IX锁，表示它的后裔结点拟（意向）加X锁

SIX锁
如果对一个数据对象加SIX锁，表示对它加S锁，再加IX锁，即SIX = S + IX。

锁的强度
锁的强度是指它对其他锁的排斥程度
一个事务在申请封锁时以强锁代替弱锁是安全的，反之则不然

具有意向锁的多粒度封锁方法
申请封锁时应该按自上而下的次序进行
释放封锁时则应该按自下而上的次序进行
例如：事务T1要对关系R1加S锁
要首先对数据库加IS锁
检查数据库和R1是否已加了不相容的锁(X或IX)
不再需要搜索和检查R1中的元组是否加了不相容的锁(X锁)

11.7 小结

数据共享与数据一致性是一对矛盾
数据库的价值在很大程度上取决于它所能提供的数据共享度
数据共享在很大程度上取决于系统允许对数据并发操作的程度
数据并发程度又取决于数据库中的并发控制机制
数据的一致性也取决于并发控制的程度。施加的并发控制愈多，数据的一致性往往愈好

数据库的并发控制以事务为单位
数据库的并发控制通常使用封锁机制
两类最常用的封锁

并发控制机制调度并发事务操作是否正确的判别准则是可串行性
并发操作的正确性则通常由两段锁协议来保证。
两段锁协议是可串行化调度的充分条件，但不是必要条件

对数据对象施加封锁，带来问题
活锁： 先来先服务
死锁：
预防方法
一次封锁法
顺序封锁法
死锁的诊断与解除
超时法
等待图法

1. 数据，数据库，数据库系统的区别

   数据是用来描述客观事实的可识别的符号系列，用来记录事物的情况，数据用类型和值表示，不同数据库类型记录的事物性质不一样

   数据库是指长期存储在计算机内的，有结构的，大量的，可共享的数据集合

   数据库管理系统是位于用户与操作之间的一层数据管理软件，在数据建立，运行和维护时对数据库进行统一的控制，统一的管理，是用户方便的定义数据和操纵数据，并能保证数据在安全性，完整性，多用户对数据的并发使用及发生故障和的系统恢复

2. 数据库系统的好处

   数据的结构化

   数据共享性高，冗余度低

   维护独立性高

   数据存取粒度小

   数据库使用DBMS集中管理

   为用户提供友好的接口

完整性检查和控制的防范对象_不合语义的_、不正确的数据，防止它们进入数据库

安全性控制的防范对象时非法用户，防止其对数据库的存取