空白诗007

这个屌丝很懒，什么也没留下！

热门标签

数据库原理与应用课程知识点_数据库原理及应用知识点总结

作者：空白诗007 | 2024-07-31 12:08:05

踩

数据库原理及应用知识点总结

数据库原理与应用课程知识点

文章目录

数据库原理与应用课程知识点

第一章绪论

数据、数据库、数据库管理系统、数据库系统的概念

信息（Information）

是数据经过加工处理后得到的另一种形式的数据，这种数据在某种程度上影响接收者的行为。具有客观真实性、传递性、时效性和有用性
数据（Data）

描述事物的符号记录称为数据。数据的种类由数字、文字、图形、图像、声音、正文等。数据与语义是不可分的

信息是加工过的数据，是数据的内涵，数据是现象，信息反映实质
数据库（DataBase，DB）

长期存储在 计算机内、有组织的、可共享 的大量的数据集合
数据库管理系统（DataBase Management System，DBMS）

是位于用户与操作系统之间的一层数据管理软件。和操作系统一样是计算机的基础软件，也是一个大型复杂的软件系统

数据管理技术发展的三个阶段及各阶段的优缺点

人工管理阶段

特点：
- 数据不保存
- 应用程序
- 数据不共享
- 数据不具有独立性
文件管理阶段

优点：
- 数据可以长期保存
- 由文件系统管理数据
缺点：
- 数据共享性差，冗余度大
- 数据独立性差
数据库管理系统阶段

特点;
- 数据结构化
- 数据共享度高、冗余度低且易扩展
- 数据独立性高
  - **物理独立性：**用户的应用程序与数据库中的数据的物理存储时相互独立的
  - **逻辑独立性：**用户的应用程序与数据库的逻辑结构是相互独立的
- 数据由数据库管理系统统一管理和控制
  - 数据的 安全性（security） 保护
  - 数据的 完整性（integrity） 保护
  - 并发（concurrenc）控制
  - 数据库恢复（recovery）

数据模型

是对现实世界数据特征的抽象
是数据库系统的核心与基础
分类
- 概念模型
- 逻辑模型和物理模型
  - 层次模型（树）
  - 网状模型（图）
  - 关系模型（表）本书主要学习
  - 面向对象数据类型和面向关系数据类型
  - 半结构化书籍类型

概念模型中的基本术语

概念模型

概念模型是从现实世界到机器世界的一个中间层次
把现实世界中的客观对象抽象为某种信息结构，这种信息结构不依赖于具体的计算机系统，完全不涉及信息在计算机系统中的结构。
强调语义表达能力，概念简单清晰，易于理解，是用户和DB设计人员交流的工具
表示方法——实体联系方法(Entity Relationship Model）使用E-R图

基本术语

实体(Entity): 客观存在并可相互区分的事物
实体集(Entity Set): 同类型实体的集合。每个实体集必须命名
属性(Attribute): 实体所具有的特征和性质
属性值(Attribute Value): 为实体的属性取值
域(Domain): 属性值的取值范围
码(Key): 唯一标识实体集中一个实体的属性或属性集
实体型(Entity Type): 表示实体信息结构，由实体名及其属性名集合表示

eg：实体名(属性1,属性2,…) 学生(学号，姓名，性别，年龄)

逻辑模型的三个组成要素

数据结构：描述数据库的组成对象以及对象之间的联系
数据操作：对数据库中各种对象的实例允许执行的操作的集合，包括操作及有关的操作规则
数据的完整性约束条件：一组完整性规则，给定的数据模型中数据及其联系所具有的制约和依存规则（详见第五章）

层次模型的数据结构、数据操纵与完整性约束，层次模型的优缺点

层次模型

层次模型是数据库系统中最早出现的数据模型
层次数据库系统的典型代表是IBM公司的IMS（Information Management System）数据库管理系统
层次模型用树形结构来表示各类实体以及实体间的联系。
特点：
- 结点的 双亲是唯一 的
- 只能直接处理 一对多 的实体联系
- 任何记录只有 按其路径查看时 才能显出它的全部意义
- 没有一个子女记录值能够脱离双亲记录值而独立存在
层次模型的数据操纵：
- 查询
- 插入
- 删除
- 更新
层次模型的完整性约束条件：
- 无相应的双亲结点值就不能插入子女结点值
- 如果删除双亲结点值，则相应的子女结点值也被同时删除
优点：
- 层次模型的数据结构比较简单清晰
缺点：
- 结点之间的多对多联系表示不自然
- 对插入和删除操作的限制多，应用程序的编写比较复杂
- 查询子女结点必须通过双亲结点

网状模型的数据结构、数据操纵与完整性约束，网状模型的优缺点

网状模型

网状数据库系统采用网状模型作为数据的组织方式。
典型代表是DBTG系统（亦称CODASYL系统，20世纪70年代由DBTG提出的一个系统方案）
满足下面两个条件的基本层次联系的集合：
- 允许一个以上的结点无双亲
- 一个结点可以有多于一个的双亲
优点：
- 能够更为直接地描述现实世界，如一个结点可以有多个双亲
- 良好的性能，存取效率较高
缺点：
- 结构比较复杂，而且随着应用环境的扩大，数据库的结构就变得越来越复杂，不利于最终用户掌握
- DDL、DML语言复杂，用户不容易使用

关系模型的基本术语与优缺点

关系模型

最重要的一种数据模型,也是目前主要采用的数据模型
1970年由美国IBM公司San Jose(圣约瑟)研究室的研究员Edgar Frank Codd(埃德加·佛兰克·科德)首次提出，开创了数据库关系方法和关系数据库理论的研究，为数据库技术奠定了理论基础
从用户观点看，关系模型由一组关系组成。每个关系的数据结构是一张规范化的二维表

关系模型的术语：

关系(Relation)：一个关系对应通常说的一张表
**元组(Tuple)：**表中的一行即为一个元组
**属性(Attribute)：**表中的一列即为一个属性，给每一个属性起一个名称即属性名
**码(Key)：**表中的某个属性组，它可以唯一确定一个元组
**域(Domain)：**一组具有相同数据类型的值的集合。属性的取值范围来自某个域
**分量：**元组中的一个属性值

关系模型的数据结构：

关系必须是规范化的，满足一定的规范条件、
最基本的规范条件：关系的每一个分量必须是一个不可分的数据项

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

查询、插入、删除、更新
这些操作必须满足关系的完整性约束条件。三大类完整性约束：实体完整性、参照完整性和用户定义的完整性
数据操作是集合操作，操作对象和操作结果都是关系，即若干元组的集合
存取路径对用户隐蔽，用户只要指出“干什么”，不必详细说明“怎么干”，大大提高了数据的独立性

关系模型的优缺点:

优点：
- 建立在严格的数学概念的基础上：集合代数
- 关系模型的概念单一：关系
- 关系模型的存取路径对用户隐藏：更好的安全保密性
缺点：
存取路径对用户隐藏，查询效率往往不如格式化数据模型

外模式、模式、内模式的概念

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

模式：

也称逻辑模式，数据库中全体数据的逻辑结构和特征的描述，所有用户的公共数据视图
一个数据库只有一个模式
模式的地位：是数据库系统模式结构的中间层
- 与数据的物理存储细节和硬件环境无关
- 与具体的应用程序、开发工具及高级程序设计语言无关
定义模式
- 定义数据的逻辑结构(数据项的名字、类型、取值范围等)
- 定义数据之间的联系
- 定义数据有关的安全性、完整性要求

外模式（External Schema）

也称子模式或用户模式，数据库用户(包括应用程序员和最终用户)能够看见和使用的局部数据的逻辑结构和特征的描述，数据库用户的数据视图，是与某一应用有关的数据的逻辑表示
外模式的地位：介于模式与应用之间
模式与外模式的关系：一对多
- 外模式通常是模式的子集
- 一个数据库可以有多个外模式

内模式(internal Schema)

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

关系数据库对三级模式结构的支持：

外模式/模式映像、模式/内模式映像二级映像功能与数据独立性

外模式／模式映象

定义外模式与模式之间的对应关系
每一个外模式都对应一个外模式／模式映象
映象定义通常包含在各自外模式的描述中
保证数据的逻辑独立性
- 当模式改变时，数据库管理员修改有关的外模式／模式映象，使外模式保持不变
- 应用程序是依据数据的外模式编写的，从而应用程序不必修改，保证了数据与程序的逻辑独立性，简称数据的逻辑独立性

模式/内模式映像

模式／内模式映象定义了数据全局逻辑结构与存储结构之间的对应关系。
数据库中模式／内模式映象是唯一的
该映象定义通常包含在模式描述中
保证数据的物理独立性
- 当数据库的存储结构改变了(例如选用了另一种存储结构)，数据库管理员修改模式／内模式映象，使模式保持不变
- 应用程序不受影响，保证了数据与程序的物理独立性，简称数据的物理独立性

小结

第二章关系数据库

笛卡尔积、关系、候选码、主码、主属性、非主属性的概念

域：是一组具有相同数据类型的值的集合

笛卡儿积：给定一组域 $D 1 、 D 2 、 \dots 、 D n$ (这些域中可以有相同的)

$D 1 、 D 2 、 \dots 、 D n$ 的笛卡尔积为：

$D_1\times D_2\times ... \times D_n=\{(d_1,d_2,...,d_n)|d_i \in D_i,i=1,2,...,n\}$

其中每一个元素 $(d 1, d 2, \dots, d n)$ 叫作一个n元组或简称元组,元素中的每一个值di叫作一个分量

$D_1\times D_2\times ... \times D_n$ 基数 $M$ 为 $M=\prod_{i=1}^{n}m_i $
笛卡尔积可表示为一个二维表。表中的每行对应一个元组，表中的每列对应一个域

关系： $D_1×D_2×…×D_n$ 的子集叫做在域 $D_1,D_2,…，D_n$ 上的关系(Relation) ，表示为：
$R (D 1, D 2 \dots, D n)$
R是关系名，n为关系的目。

关系是笛卡尔积的有限子集，所以关系也是一个二维表
若关系中的某一个或多个属性的集合能唯一地标识一个元组，则称该属性或属性组为超码
如果构成超码属性组的任意真子集都不能成为超码，这样的最小超码称为候选码
若一个关系有多个候选码，则选定其中一个为主码。候选码的诸属性称为主属性
不包含在任何候选码中的属性称为非主属性或非码属性

基本关系具有的六个性质

基本关系具有的性质

列是同质的，每一列中的分量是同一类型的数据，来自同一个域
不同的列可出自同一个域，其中的每一列称为一个属性，不同的属性要给予不同的属性名
列的顺序无所谓，列的次序可以任意交换
任意两个元组的候选码不能相同
行的顺序无所谓，行的次序可以任意交换
分量必须取原子值，每一个分量都必须是不可分的数据项

关系域二维表的对应：

关系模式的概念及五元组所表示的含义

关系模式：

关系模式是对关系的描述
关系是元组的集合，因此关系模式必须指出这个元组集合的结构，即它由哪些属性构成，这些属性来自哪些域，以及属性与域之间的映象关系
现实世界的许多已有事实限定了关系模式所有可能的关系必须满足一定的完整性约束
这些约束或者通过对属性取值范围的限定，或者通过属性值间的相互关连反映出来。关系模式应当刻划出这些完整性约束条件
因此一个关系模式应当是一个5元组
定义： 关系的描述称为关系模式，它可以形式化地表示为：

$R (U, D, d o m, F)$

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

关系模式简记为：
$R(U)或R(A_1,A_2,...,A_n)$
其中R为关系名， $A 1, A 2, \dots, A n$ 为属性名。而域名及属性向域的映象(dom)常常直接说明为属性的类型、长度

关系模式与关系

关系模式是型，关系是值
关系是关系模式在某一时刻的状态或内容
关系模式是静态的、稳定的，关系是动态的、随时间变化的

关系的基本操作，关系数据语言的分类

关系的基本操作

查询

选择、投影、连接、除、并、交、差、笛卡尔积等
数据更新

插入、删除、修改
查询的表达能力是其中最主要的部分
关系操作的特点
- 集合操作方式，即操作的对象和结果都是集合，一次一集合
- 相应地，非关系数据模型的数据操作方式：一次一记录

关系数据语言的种类

关系代数语言
- 用对关系的运算来表达查询要求
- 典型代表：IBM-实验性系统ISBL
关系演算语言：用谓词来表达查询要求
- 元组关系演算语言
  - 谓词变元的基本对象是元组变量
  - 典型代表：APLHA, QUEL
- 域关系演算语言
  - 谓词变元的基本对象是域变量
  - 典型代表：QBE
具有关系代数和关系演算双重特点的语言
典型代表：SQL

关系代数概述

**关系代数：**一种抽象的 查询语言，用对关系的运算来表达查询

关系代数运算的三要素：运算对象：关系运算，结果：关系，运算符：四类

关系运算符

集合运算符( $∩\ －\ ∪\ ×$ )
- 将关系看成元组的集合
- 运算是从关系的“水平”方向即行的角度来进行
专门的关系运算符( $σ\quad π \quad ÷$ )
- 不仅涉及行而且涉及列
比较运算符( $<\ >\ ≥\ ≤\ =\ ≠$ )
- 辅助专门的关系运算符进行操作
逻辑运算符($∧\ ∨\ \neg $)
- 辅助专门的关系运算符进行操作

关系代数运算的分类

传统的集合运算
并、差、交、广义笛卡尔积
专门的关系运算
选择、投影、连接、除

并、交、差与广义笛卡尔积运算

并、交、差

R和S满足的条件
- 具有相同的目n（即两个关系都有n个属性）
- 相应的属性取自同一个域
$R \cup S$

$\{t | t \in R\ ∨\ t \in S \}$

$R - S$

$\{t | t \in R\ ∨\ t \notin S \}$

$R \cap S$

$KaTeX parse error: Undefined control sequence: \and at position 23: …\{t | t \in R\ \̲a̲n̲d̲\ t \in S \}\\ …$

广义笛卡尔积

R：n目关系，k1个元组。
S：m目关系，k2个元组。
$R \times S$
- 列：(n+m）列的元组的集合
  - 元组的前n列是关系R的一个元组
  - 后m列是关系S的一个元组
- 行： $k 1 \times k 2$ 个元组

$\{\stackrel\frown{t_rt_s} | t_r \in R ∧ t_s \in S \}$

选择、投影、θ连接、等值连接、自然连接、外连接

选择
$\sigma_{条件}(表名)$
投影
${\textstyle \prod_{属性列名}^{}}(表名)=\{ t[A]|t\in R\}$

投影之后不仅取消了原关系中的某些列，而且还可能取消某些元组（避免重复行）

θ连接：从两个关系的笛卡尔积中选取属性间满足一定条件的元组
$KaTeX parse error: Undefined control sequence: \and at position 70: …t_s}|t_r\in R\ \̲a̲n̲d̲\ t_s \in t_r[A…$

A和B：分别为R和S上度数相等且可比的属性组
θ：比较运算符

**等值连接：**θ为“＝”的连接运算称为等值连接

自然连接（Natural join）：
$R\bowtie S$

自然连接是一种特殊的等值连接
两个关系进行比较的分量必须是同名的属性组
在等值连接的结果中去掉重复的属性列

连接名词解释

悬浮元组：在做自然连接时被舍弃的元组称为悬浮元组
外连接：如果把悬浮元组也保存在结果关系中，而在其它属性上填空值，那么这种连接就叫做外连接（outer join）
左外连：如果只保留左边关系R中的悬浮元组就叫做左外连（left outer join）
右外连：如果只保留右边关系S中的悬浮元组就叫做右外连（right outer join）

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

SQL的发展、特点及基本概念

SQL(Structured Query Language)，1974年提出

SQL特点

综合统一
高度非过程化
面向集合的操作方式
一同一种语法结构提供两种使用方法
语言简洁，易学易用

基本表的定义、删除与修改

基本表的定义：

CREATE TABLE <表名>
       (<列名> <数据类型>[ <列级完整性约束条件> ]
       [，<列名> <数据类型>[<列级完整性约束条件>] ] …
       [，<表级完整性约束条件> ] );
1
2
3
4

其中：

<表名>：所要定义的基本表的名字
<列名>：组成该表的各个属性（列）
<列级完整性约束条件>：涉及相应属性列的完整性约束条件
<表级完整性约束条件>：涉及一个或多个属性列的完整性约

完整性约束：

实体完整性约束：primary key

//列级完整性约束条件
<列名> <数据类型> primary key,
//表级完整性约束条件（若住吗有两个或两个以上属性列必须使用此方法）
primary key(列名1,列名2,...)
1
2
3
4

参照完整性约束：foreign key

//表级约束
foreign key (列名) references <被参照表表名>(列名)
1
2

用户自定义的完整性约束：
- check约束
- 唯一性约束（unique）
- 非空值约束（not null）

修改基本表

ALTER TABLE <表名>
[ ADD <新列名> <数据类型> [ 完整性约束 ] ]	//加入数据列
[ ADD <表级完整性约束> ]				   //添加表记约束性条件按
[ DROP  COLUMN <列名> ]				  //删除列
[ DROP CONSTRAINT <完整性约束名> ]	   //删除完整性约束名（注意是约束的名）
[ MODIFY <列名> <数据类型> ];			  //修改列的数据类型
1
2
3
4
5
6

删除基本表

    DROP TABLE <表名>;
1

索引的概念，索引的建立与删除

索引的概念

在关系数据库中，索引是一种单独的、物理的对数据库表中一列或多列的值进行排序的一种存储结构
它是某个表中一列或若干列值的集合和相应的指向表中物理标识这些值的数据页的逻辑指针清单
建立索引是加快查询速度的有效手段
谁建立索引？ DBA或表的属主或DBMS自动建立
谁维护索引？DBMS自动完成
谁使用索引？DBMS自动选择

索引的建立

创建索引的方法分为 间接创建 与 直接创建
间接创建： 在表中创建其他对象是附加创建了索引 eg: 主键约束 或 唯一性约束
直接创建： 使用 create index 方法
```
CREATE [UNIQUE|BITMAP] INDEX <索引名> 
    ON <表名>(<列名>[<次序>][,<列名>[<次序>] ]…);
1
2
```
- 用**<次序>**指定索引值的排列次序，升序：ASC，降序：DESC，缺省值：ASC
- UNIQUE表明此索引的每一个索引值只对应唯一的数据记录
- BITMAP表示要建立的索引是位图索引，位图索引主要用来节省空间，减少ORACLE对数据块的访问

修改索引

ALTER INDEX <旧索引名> RENAME TO <新索引名>;
1

删除索引

DROP INDEX <索引名>;
1

单表查询、连接查询、嵌套查询与集合查询

单表查询

SELECT [ALL|DISTINCT] <目标列表达式>[，<目标列表达式>] …
FROM <表名或视图名>[， <表名或视图名> ] …
[ WHERE <条件表达式> ]
[ GROUP BY <列名1> [ HAVING <条件表达式> ] ]
[ ORDER BY <列名2> [ ASC|DESC ] ]；
1
2
3
4
5

查询全部列 **使用 * **
消除取值重复的行(在目标表达式之前添加 distinc)
查询满足条件的值（where子句中）

字符串匹配：[not] like <匹配串>

*代表一串字符，_代表一个字符

涉及空值查询只能使用 is null 或is not all
使用 and、or 连接多个条件
对查询结果排序

使用 order by 子句 。升序ASC（省缺，空值最后展示） 和 降序DESC（空值最先展示）

使用集函数

COUNT（[DISTINCT|ALL] *）		 //统计个数
COUNT（[DISTINCT|ALL] <列名>）
SUM（[DISTINCT|ALL] <列名>）	//求和
AVG（[DISTINCT|ALL] <列名>）	//求平均
MAX（[DISTINCT|ALL] <列名>）	//求最大
MIN（[DISTINCT|ALL] <列名>）	//求最小	
1
2
3
4
5
6

除了 count 其他必须要求number
DISTINCT短语：在计算时要取消指定列中的重复值
ALL短语：不取消重复值
ALL为缺省值

对查询结果分组
- 使用GROUP BY子句将查询结果表按某一列或多列值分组，值相等的为一组
- 未对查询结果分组，集函数将作用于整个查询结果
- 对查询结果分组后，集函数将分别作用于每个组
- GROUP BY子句的作用对象是查询的中间结果表
- 使用GROUP BY子句后，SELECT子句的列名列表中只能出现分组属性和集函数
- 只有满足HAVING短语指定条件的组才输出
- HAVING短语与WHERE子句的区别：作用对象不同
  - WHERE子句作用于基表或视图，从中选择满足条件的元组
  - HAVING短语作用于组，从中选择满足条件的组

连接查询

若一个查询同时涉及两个以上的表，则称之为连接查询
连接查询的WHERE子句中用来连接两个表的条件称为连接条件或连接谓词

一般格式

  [<表名1>.]<列名1>  <比较运算符>  [<表名2>.]<列名2>
         比较运算符：=、>、<、>=、<=、!=
   [<表名1>.]<列名1> BETWEEN [<表名2>.]<列名2> AND [<表名2>.]<列名3>
1
2
3

等值连接（运算符为’=‘）
自身连接
- 一个表与其自己进行连接，称为表的自身连接
- 需要给表起别名以示区别
- 由于所有属性名都是同名属性，因此必须使用表别名前缀
```
SELECT a.sno
     FROM sc  a,sc  b
     WHERE a.sno=b.sno
1
2
3
```
外连接（Outer Join）
- 如果把两个关系R、S在做自然连接时舍弃的悬浮元组保存在结果关系中，在其它属性上填空值，那么这种连接就叫做全外连(full outer join)
- 如果只把左边关系R中要舍弃的悬浮元组保留就叫做左外连(left outer join)
- 如果只把右边关系S中要舍弃的悬浮元组保留就叫做右外连(right outer join)
```
from <左表名> <full|left|right outer join> <右表名>(条件)
1
```

嵌套查询

一个SELECT-FROM-WHERE语句称为一个查询块
将一个查询块嵌套在另一个查询块的WHERE子句或HAVING短语的条件中的查询称为嵌套查询

eg:
SQL语言允许多层嵌套查询
不能使用ORDER BY子句
层层嵌套方式反映了 SQL语言的结构化
有些嵌套查询可以用连接查询替代
嵌套查询的分类
- 不相关子查询：子查询的查询条件不依赖于父查询
- 相关子查询：子查询的查询条件依赖于父查询
引出子查询的谓词
- 带有IN谓词的子查询
- 带有比较运算符的子查询 子查询返回值是单值
- 带有ANY或ALL谓词的子查询 配合比较运算符使用 ANY：任意值 ALL：所有值
- 带有EXISTS谓词的子查询 返回true（查询有结果）或false（查询无结果）

集合查询

并（UNION）
交（INTERSECT）
- 补（EXCEPT,MINUS）ORCAL使用MINUS，PL/SQL使用EXCEPT

插入、修改与删除数据

插入数据

插入单个元组

INSERT
INTO <表名> [(<属性列1>[，<属性列2 >…])]
VALUES (<常量1> [，<常量2> … ])
1
2
3

如果不指定属性列，则必须插入所有元素，无属性值的为NULL

插入子查询结果

insert
into <表名> [(<属性列1>[，<属性列2 >…])]
	select 查询语句
commit;
1
2
3
4

修改数据

update <表名>
set 属性列 = 某个值
where 条件
commit;
1
2
3
4

删除数据

DELETE
FROM <表名>
[WHERE <条件>]；
1
2
3

不指定条件则删除表中所有元素

视图的概念，视图的定义、查询与更新，视图的作用

视图的概念

让所有用户都看到整个逻辑模型是不合适的。出于安全考虑，需要向用户隐藏特定的数据
除了安全考虑，我们还可能希望创建一个比逻辑模型更符合特定用户直觉的个人化的关系集合
视图是从一个或几个基本表（或视图）导出的表，它与基本表不同，是一个虚表
数据库中只存放视图的定义，而不存放视图对应的数据，这些数据仍存放在原来的基本表中，不会出现数据冗余
基表中的数据发生变化，从视图中查询出的数据也随之改变

视图的定义

CREATE [OR REPLACE] VIEW <视图名> [(<列名> [，<列名>]…)]
AS <子查询>
[WITH  CHECK  OPTION]；
1
2
3

DBMS执行CREATE VIEW语句时只是把视图的定义存入数据字典，并不执行其中的SELECT语句
在对视图查询时，按视图的定义从基本表中将数据查出
With Check Option表示对视图进行Update、Insert和Delete操作时要保证更新、插入或删除的行满足视图定义中的谓词条件（即子查询中的条件表达式）

视图的查询

视图创建以后，用户就可以像对基本表一样对视图进行查询
DBMS内部执行对视图的查询时采用的的方法：视图消解(转化为对基本表的查询)
语句与对 基本表查询形同

视图的更新

在关系数据库中，并不是所有的视图都是可更新的，因为对有些视图的更新不能唯一地有意义地转换成对相应基本表的更新
DB2对视图更新的限制：
- 若视图是由两个以上基本表导出的，则此视图不允许更新
- 若视图的字段来自字段表达式或常数，则不允许对此视图执行INSERT和UPDATE操作，但允许执行DELETE操作
- 若视图的字段来自**集函数，**则此视图不允许更新
- 若视图定义中含有GROUP BY子句，则此视图不允许更新
- 若视图定义中含有DISTINCT短语，则此视图不允许更新
- 若视图定义中有嵌套查询，并且内层查询的FROM子句中涉及的表也是导出该视图的基本表，则此视图不允许更新
- 一个不允许更新的视图上定义的视图也不允许更新
对视图的更新不同系统有不同限制，在Oracle中可以通过数据字典user_updatable_columns进行查看

视图的删除

 DROP  VIEW  <视图名>；
1

该语句从数据字典中删除指定的视图定义
由该视图导出的其他视图定义仍在数据字典中，但已不能使用，必须显式删除
删除基表时，由该基表导出的所有视图定义都必须显式删除

视图的作用

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

第四章数据库安全性

数据库安全性概念，数据库的不安全因素

数据库的安全性是指保护数据库以防止不合法的使用所造成的数据泄漏、更改或破坏

对数据库安全性产生威胁的因素

非授权用对数据库的恶意存取和破坏
数据库中重要或敏感的数据被泄露
安全环境的脆弱性

用户身份鉴别方法的基本原理

用户身份鉴别是数据库管理系统提供的最外层安全保护措施

基本方法

系统提供一定的方式让用户标识自己的名字或身份
系统内部记录着所有合法用户的标识
每次用户要求进入系统时，由系统核对用户提供的身份标识
通过鉴定后才提供使用数据库管理系统的权限

鉴别方法

静态口令鉴别：鉴别时只用输入正确的口令
动态口令鉴别：口令时动态化的
生物特征鉴别
智能卡鉴别：智能卡时不可复制的硬件

自主存取控制方法

数据库安全最重要的一点就是确保只授权给有资格的用户访问数据库的权限，同时令所有未被授权的人员无法接近数据，这主要通过数据库系统的存取控制机制实现

存储控制机制包括两部分

定义用户权限，并将用户权限登记到数据字典中
- 用户对某一数据对象的操作权力称为权限
- DBMS系统提供适当的语言来定义用户权限，这些定义经过编译后存放在数据字典中，被称做安全规则或授权规则
合法权限检查
- 每当用户发出存取数据库的操作请求后，DBMS查找数据字典，根据安全规则进行合法权限检查，若用户的操作请求超出了定义的权限，系统将拒绝执行此操作

常用存取控制方法

在自主存取控制中（Discretionary Access Control ，简称DAC）(只学这个)
- 同一用户对于不同的数据对象有不同的存取权限
- 不同的用户对同一对象也有不同的权限
- 用户还可将其拥有的存取权限转授给其他用户
在强制存取控制中（Mandatory Access Control，简称 MAC）
- 每一个数据对象被标以一定的密级
- 每一个用户也被授予某一个级别的许可证
- 对于任意一个对象，只有具有合法许可证的用户才可以存取

Oracle安全性控制

Oracle安全性控制

用户管理
模式
权限管理
角色管理

用户管理

用户管理是Oracle中实现安全性的一个重要方法，只有通过用户验证，用户才能访问数据库
用户管理包括创建用户、修改用户和删除用户
创建用户：在oracle中要创建一个新的用户，一般当前用户是具有dba(数据库管理员)的权限才能使用
创建用户

create user 用户名 
identified {by 口令 | externally}	//身份验证方式
      [default tablespace 默认表空间名]	
      [temporary tablespace 临时表空间名]
         [quota {整数[K | M]| unlimited} on 表空间名]	//设置存储配额
         [quota {整数[K | M]| unlimited} on 表空间名]
             [password expire]
                 [account {lock | unlock}]		//设置用户是否被锁定，锁定为无法登录
                 [profile {概要文件名 | default}]
1
2
3
4
5
6
7
8
9

创建的新用户没有任何权限，甚至连登录数据库的权限都没有，需要为其指定相应的权限

eg:

create user u1 identified  by 123456 
      default tablespace users 
      temporary tablespace temp
      quota unlimited on users 
1
2
3
4

修改用户 除了create变为alter其余一模一样

alter user 用户名 
identified {by 口令 | externally}
      [default tablespace 默认表空间名]
      [temporary tablespace 临时表空间名]
         [quota {整数[K | M]| unlimited} on 表空间名]
         [quota {整数[K | M]| unlimited} on 表空间名]
             [password expire]
                 [account {lock | unlock}]
                 [profile {概要文件名 | default}]
1
2
3
4
5
6
7
8
9

删除用户 一般以dba的身份删除某个用户，其他用户必须拥有 drop user 权限

drop user 用户名 [cascade]
1

如果指定cascade，将会删除这个用户所拥有的所有对象

模式

模式是指一系列逻辑数据结构或对象的集合
模式与用户相对应**，一个模式只能被一个数据库用户所拥有**，并且模式的名称与这个用户的名称相同
通常情况下，用户所创建数据库对象都保存在与自己同名的模式中
同一模式中数据库对象的名称必须唯一，而在不同模式中的数据库对象可以同名
默认情况下，用户引用的对象是与自己同名模式中的对象，如果要引用其他模式中的对象，需要在该对象名之前指明对象所属模式
用户主要是用来连接数据库和访问数据库。模式是数据库对象的集合，是用来创建和管理对象的
Oracle数据库中不能通过create schema语句来新创建一个模式，要想创建一个模式，只能通过创建一个用户的方法解决，Oracle中虽然有create schema语句，但它并不是用来创建模式的
模式的选择与切换
- 如果用户以 normal 身份登录，则进入同名模式
- 若以sysdba身份登录，则进入sys模式
- 如果以sysoper身份登录，则进入public模式
模式对象与非模式对象
- 模式对象：属于特定的模式。包括——表、索引、索引化表、分区表、物化视图、视图、数据库链接、序列、同义词、PL/SQL包、存储函数与存储过程、Java类与其他Java资源
- 非模式对象：不属于任何模式。包括——表空间、用户、角色、目录、概要

权限管理

一个新的用户被创建后，该用户还无法操作数据库，还需要为用户授予相关的权限
权限是指在数据库中执行某种操作的权利
Oracle有两种类型的权限：系统权限和对象权限
系统权限：允许用户在数据库的任何模式上执行特定操作所需要的权限称为系统权限，这些操作包括建立、修改和删除表、视图、索引、表空间、触发器、用户、角色等
- 系统权限可以分配给一个用户、角色或Public。
  Oracle 11g中含有208种系统权限，这些系统权限都被列举在system_privilege_map视图中
- 授予系统权限：可以使用Grant语句把系统权限授予一个用户或一个角色，语句格式：
```
grant {系统权限|角色}[,{系统权限|角色}]…
to  {用户|角色|public}[,{用户|角色|public}] …
[with admin option]	//允许将自己的权限赋予其他用户或角色
1
2
3
```
- 回收系统权限：使用REVOKE语句可以从用户或角色中回收系统权限。语句格式：
```
revoke { 系统权限 | 角色 } [, { 系统权限 | 角色 } ]…
from  { 用户 | 角色 | public} [, { 用户 | 角色 | public}] …
1
2
```

部分常用系统权限

系统权限	说明	系统权限	说明
Create session	连接数据库	Update any table	修改任何用户模式中的表的记录
Create tablespace	创建表空间	Delete any table	删除任何用户模式中的表的记录
Alter tablespace	修改表空间	Create view	创建视图
Drop tablespace	删除表空间	Create any view	在任何用户模式中创建视图
Create user	创建用户	Drop any view	删除任何用户模式中的视图
Alter user	修改用户	Create role	创建角色
Drop user	删除用户	Alter any role	修改任何角色
Create table	创建表	Grant any role	将任何角色授予其它用户
Create any table	在任何用户模式中创建表	Alter datebase	修改数据库结构
Drop any table	删除任何用户模式中的表	Create procedure	创建存储过程
Alter any table	修改任何用户模式中的表	Create any procedure	在任何用户模式中创建存储过程
Select any table	查询任何用户模式中基本表的记录	Alter any procedure	修改任何用户模式中的存储过程
Insert any table	向任何用户模式中的表插入记录	Drop any procedure	删除任何用户模式中的存储过程

对象权限：允许用户访问一个特定对象并对特定对象执行特定操作所需要的权限称为对象权限
- 对象权限针对不同模式的对象，如表、视图、序列、过程、函数等
- 对象权限可以是对数据的查询(select)、修改(update)、删除(delete) 、插入(insert)或引用(references) ，也可以是是否可以**执行(execute)**程序的权限，或修改对象结构(alter)的权限
- 授予对象权限：使用grant语句授予对象权限，语句格式：
```
grant  {对象权限[,对象权限]…| all[privileges]}
on [模式.] 对象名
to  { 用户|角色|public}[,{用户|角色|public}] …
[with grant option]
1
2
3
4
```
- 回收对象权限：使用Revoke语句回收对象权限，语句格式：
```
revoke  {对象权限[,对象权限 ]…|all[privileges]}
on [模式.] 对象名
from  { 用户|角色|public}[,{用户|角色|public}] …
[cascade constraints]	//级联回收
1
2
3
4
```

角色管理

角色将用户权限归为一组，对权限进行组管理
角色是一组权限的集合
如果将一个角色授予一个用户，意味着这个用户拥有这个角色内的所有权限
数据库建立时，Oracle会自动创建一些角色，称为预定义角色
- connect：连接数据库
- resource：建立聚集、索引类型、操作者、序列、表、触发器、类型等数据库对象
- DBA：所有系统权限

创建角色语句格式：

create role 角色名
[not identified | identified { by 口令 | externally | globally}]
1
2

修改角色语句格式：

alter  role 角色名
not identified | identified { by 口令 | externally | globally}]
1
2

删除角色语句格式：
```
drop role 角色名            
1
```
授予角色权限与回收角色权限与对象操作相同

强制存取控制方法实现更高级别安全性的原理

好像没学过吧

强制存取控制

**强制存取控制(MAC)**是指系统为保证更高程度的安全性，按照TDI/TCSEC标准中安全策略的要求，所采取的强制存取检查手段
MAC适用于对数据有严格而固定密级分类的部门
- 军事部门
- 政府部门
在MAC中，DBMS所管理的全部实体被分为主体和客体两大类
- 主体是系统中的活动实体 eg：用户
- 客体是系统中的被动实体，是受主体操纵的 eg：文件，表，视图···
对于主体和客体，DBMS为它们每个实例（值）指派一个敏感度标记（Label）
- 主体的敏感度标记称为**许可证级别（**Clearance Level）
- 客体的敏感度标记称为密级（Classification Level）
强制存取控制规则：当某一用户（或某一主体）以标记label注册进入系统后，系统要求他对任何客体的存取必须遵循下面两条规则：
- 仅当主体的许可证级别大于或等于客体的密级时，该主体才能读相应的客体
- 仅当主体的许可证级别小于或等于客体的密级时，该主体才能写相应的客体
强制存取控制的特点
- MAC是对数据本身进行密级标记
- 无论数据如何复制，标记与数据是一个不可分的整体
- 只有符合密级标记要求的用户才可以操纵数据，从而提供了更高级别的安全性

视图机制，审计机制及数据加密

视图机制

进行存取权限控制时可以为不同的用户定义不同的视图，把数据对象限制在一定的范围内
视图机制把要保密的数据对无权存取这些数据的用户隐藏起来，从而自动地对数据提供一定程度的安全保护

审计

什么是审计
- 启用一个专用的审计日志（Audit Log）将用户对数据库的所有操作记录在上面
- 审计员可以利用审计日志监控数据库中的各种行为，重现导致数据库现有状况的一系列事件，找出非法存取数据的人、时间和内容等
- C2以上安全级别的DBMS必须具有审计功能
审计功能的可选性
- 审计很费时间和空间
- DBA可以根据应用对安全性的要求，灵活地打开或关闭审计功能

数据加密

防止数据库中数据在存储和传输中失密的有效手段
加密的基本思想
- 根据一定的算法将原始数据（术语为明文，Plain text）变换为不可直接识别的格式（术语为密文，Cipher text）
- 不知道解密算法的人无法获知数据的内容

第四章小结

第五章数据库完整性

完整性的概念

数据库的完整性是指数据的正确性和有效性。是指数据是符合现实世界语义、反映当前实际状况的
通过对关系（二维表）中取值的约束，可以保证数据库的完整性，保证数据的正确性
关系模型中有三类完整性约束：
- 实体完整性
- 参照完整性
- 用户定义的完整性
数据的完整性和安全性是两个不同的概念
- 完整性为了防止数据库中存在不符合语义的数据，也就是防止数据库中存在不正确的数据。它检查和控制的防范对象是不合语义的、不正确的数据，防止它们进入数据库
- 安全性保护数据库防止恶意的破坏和非法的存取。它防范对象是非法用户和非法操作，防止他们对数据库数据的非法存取

实体完整性的定义、检查和违约处理

实体完整性规则：若属性A是基本关系R的主属性，则属性A不能取空值，不能有相同值

eg：

实体完整性的实现

在create table语句中用primary key定义哪些列为主码（主键）

单属性构成的码有两种说明方法
- 定义为列级约束条件
- 定义为表级约束条件
对多个属性构成的码只有一种说明方法
- 定义为表级约束条件

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

参照完整性的定义、检查和违约处理

参照完整性规则

若属性F是基本关系R的外码，它与基本关系S的主码Ks相对应，则对于R中每个元组在F上的值必须为：
- 或者取空值
- 或者等于S中某个元组的主码值

参照完整性实现

在create table语句中用foreign key短语定义哪些列为外码
用references短语指明这些外码参照哪些表的主码
指定外码后参照完整性规则自动生效
- 表级：
- 列级：

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

用户定义的完整性中属性上的约束条件和元组上的约束条件

用户定义的完整性规则

用户定义的完整性是针对某一具体关系数据库的约束条件，反映某一具体应用所涉及的数据必须满足的语义要求
用户定义的完整性没有统一的规则，由数据库设计人员根据具体应用中数据的语义要求来创建

用户定义的完整性实现

Create table语句中
- 列值非空：not null
- 列值唯一：unique
- 检查列值是否满足一个布尔表达式：check

用户定义的完整性检查和违约处理

元组上的约束条件的定义

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

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

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

第六章关系数据理论

“不好”的关系模式中存在的问题：插入异常、删除异常、修改异常和数据冗余

关系模式问题：

数据冗余
更新异常
插入异常
删除异常

原因
关系模式中的函数依赖存在某些“不好”的性质

如何改造？
规范化理论：通过分解关系模式来消除其中不合适的数据依赖，以解决插入异常、删除异常和数据冗余等问题

函数依赖的概念，平凡函数依赖与非平凡函数依赖，部分函数依赖与完全函数依赖，传递函数依赖

函数依赖的定义：
$$
设 R(U) 是一个属性集 U 上的关系模式，X和 Y 是 U 的子集\
若对于 R(U) 的任意一个可能的关系 r ，r 中不可能存在两个元组在 X 上的属性值相等\
而在 Y 上的属性值不等，则称\ X函数确定Y\ 或 \ Y函数依赖于X\ ，记\ X→Y

函数依赖不是指关系模式R的某个或某些关系实例满足的约束条件，而是指R的所有关系实例均要满足的约束条件
函数依赖是语义范畴的概念。只能根据数据的语义来确定函数依赖
$若 X \to Y ，并且 Y \to X, 则记为 X \leftarrow\to Y$
若 $Y 不函数依赖于 X, 则记为 X \to Y$
eg：

平凡函数依赖与非平凡函数依赖
$\\ 如果 X→Y，但 Y \nsubseteq X，则称 X→Y 是非平凡的函数依赖\\ 若 X→Y，但 Y \subseteq X, 则称X→Y 是平凡的函数依赖$

eg:

完全函数依赖与部分函数依赖
$\rightarrow Y , 并且对于 X 的任何一个真子集X^{\prime}，都有：\\ X^{\prime} \nrightarrow Y , 则称 Y 完全函数依赖于 X , 记作 X \stackrel{f}{\longrightarrow} Y \\ 若 X \longrightarrow Y , 但 Y 不完全函数依赖于 X , 则称 Y 部分函数依赖于 X , 记作 X \stackrel{P}{\longrightarrow} Y$
eg:

传递函数依赖
$\nrightarrow Y\ (Y\nsubseteq X),Y \nrightarrow X,Y \rightarrow Z(Z\nsubseteq Y)\\ 则称Z传递函数依赖于X，记为 \quad X \overset{传递}{\longrightarrow}Z \\ 注:如果 Y \rightarrow X,即X \leftarrow \rightarrow Y，则称Z直接依赖于X$

规范化的思想，范式的概念

构造数据库必须遵循一定的规则，在关系数据库中，这种规则就是范式
一个低一级范式的关系模式，通过模式分解可以转换为若干个高一级范式的关系模式的集合，这种过程就叫规范化

1NF的定义

1NF的要求：如果一个关系模式R的所有属性都是不可分的基本数据项，则R∈1NF

eg: Student(Sno, Sdept, Mname, Cno, Grade)

2NF的定义

2NF的要求：若关系模式R∈1NF，并且每一个非主属性都完全函数依赖于R的码，则R∈2NF

eg:

3NF的定义

3NF的要求：若关系模式R∈1NF，并且每一个非主属性不传递函数依赖于R的码，则R∈3NF

在满足第三范式的关系模式中，前面提到的一些问题（如数据冗余、插入异常、删除异常等）基本消失了

eg: 因为SL表中 $SNO\rightarrow SDEPT$ 而 $\rightarrow MNAME$ 所以 $SNO\overset{传递}{\longrightarrow}MNAME$

关系模式规范化

规范化的基本思想

消除不合适的数据依赖
使各关系模式达到某种程度的“分离”
采用“一事一地”的模式设计原则。
让一个关系描述一个概念、一个实体或者实体间的一种联系。若多于一个概念就把它“分离”出去
所谓规范化实质上是概念的单一化

关系模式规范化的基本步骤

关系模式的分解准则

模式分解要满足：
- 模式分解具有无损连接性
  
  无损连接是指分解后的关系通过自然连接可以恢复成原来的关系，即通过自然连接得到的关系与原来的关系相比，既不多出信息、又不丢失信息
- 模式分解能够保持函数依赖
  
  保持函数依赖分解是指在模式的分解过程中，函数依赖不能丢失的特性，即模式分解不能破坏原来的语义

第七章数据库设计

数据库设计的特点、方法与基本步骤

把使用数据库的各类信息系统统称为数据库应用系统

什么是数据库设计？

数据库设计是指对于一个给定的应用环境，构造最优的数据库模式，建立数据库及其应用系统，使之能够有效地存储数据，满足各种用户的应用需求，包括信息管理要求和数据操作要求

数据库设计的特点

三分技术，七分管理，十二分基础数据
结构（数据）设计和行为（处理）设计相结合
- 结构（数据）设计：设计数据库框架或数据库结构
- 行为（处理）设计：设计应用程序、事务处理等

数据库设计的六步骤

需求分析
概念结构设计
逻辑结构设计
数据库的物理设计
数据库的物理实施
数据库的运行与维护

需求分解的任务与方法，数据字典和数据流程图

需求分析就是分析用户的需要与要求

需求分析是设计数据库的起点
需求分析的结果是否准确地反映了用户的实际要求，将直接影响到后面各个阶段的设计，并影响到设计结果是否合理和实用

需求分析的任务

通过详细调查现实世界要处理的对象（组织、部门、企业等），充分了解原系统（手工系统或计算机系统）工作概况，明确用户的各种需求
在此基础上确定新系统的功能。新系统必须充分考虑今后可能的扩充和改变，不能仅仅按当前应用需求来设计数据库
需求分析的重点
- 需求分析的重点是调查、收集与分析用户在数据管理中的信息要求、处理要求、安全性与完整性要求
- 信息要求
  - 用户需要从数据库中获得信息的内容与性质
  - 由用户的信息要求可以导出数据要求，即在数据库中需要存储哪些数据
- 处理要求
  - 要完成什么处理功能
  - 对处理的响应时间的要求
  - 对处理方式的要求(批处理/联机处理)
- 安全性与完整性要求
需求分析的难点
- 确定用户最终需求的难点
- 设计人员必须采用有效的方法，与用户不断深入地进行交流，才能逐步得以确定用户的实际需求(使用SA方法)

需求分析的方法 : SA方法 从最上层的系统组织机构入手，采用逐层分解的方式分析系统，并用数据流程图和数据字典描述系统

数据流程：指数据在系统中产生、传输、加工处理、使用、存储的过程
数据流程图：可以用少数几种符号综合地反映出信息在系统中的流动、处理和存储情况

eg:

数据字典

为什么建立数据字典？
- 数据流程图表达不够准确、具体。只有当数据流程图中出现的每一个成分都给出定义之后，才能完整、准确地描述一个系统
- 建立数据字典来对数据流程图中的各个元素作出详细的说明
数据字典的用途
- 在数据字典中建立的一组严密一致的定义有助于改进系统分析员和用户之间的通信，从而消除它们之间的许多误解
- 有助于改进在不同的开发人员或不同的开发小组之间的通信，加快系统开发的进度。如果要求所有开发人员都根据公共的数据字典描述的数据来设计模块，则能避免许多数据不一致而造成的麻烦
数据字典的内容
- 数据项
- 数据结构
- 数据流
- 数据存储
- 处理过程

数据流程图同数据字典的区别和联系

区别
- 数据流程图：是一种能全面地描述系统数据流程的主要工具，它用一组符号来描述整个系统中信息的全貌，综合地反映出信息在系统中的流动、处理和存储情况
- 数据字典:是对数据流程图中的数据项、数据结构、数据流、处理逻辑和数据存储进行定义和描述的工具，也是数据分析和管理工具，同时也是系统设计阶段进行数据库设计的重要依据
联系：
- 没有数据字典，数据流程图就不严格；没有数据流程图，数据字典也难于发挥作用
- 只有数据流程图和对数据流程图中每个元素的精确定义放在一起，才能共同构成系统的规格说明

E-R模型，概念结构设计的方法、步骤，E-R图的合并

什么是概念结构设计？

将需求分析得到的用户需求抽象为信息结构即概念模型的过程就是概念结构设计
概念结构是各种数据模型的共同基础，它比数据模型更独立于机器、更抽象，从而更加稳定
概念结构设计是整个数据库设计的关键

概念模型的表示方法：实体-联系方法(Entity-Relationship)

E-R图

实体型－用矩形框表示，实体集名子写在框中
联系－用菱形框表示，联系名写在框中，用无向边与相关实体集连接，并注明联系类型
属性－用椭圆表示，属性名写在椭圆中，如果为码属性，其名字带下划线。用无向边将实体集和它的全部属性连接起来
若联系也有属性，把属性和菱形用无向边连起来
三种联系方式
- 一对一 1:1
- 一对多 1:n
- 多对一 m:n

概念结构设计

常用策略
- 自顶向下地进行需求分析
- 自底向上地设计概念结构
自底向上设计概念结构的步骤。
- 第1步：抽象数据并设计局部视图（局部E-R图）
- 第2步：集成局部视图，得到全局概念结构（总E-R图）

E-R图的合并

合并。将各分E-R图合并起来，合理消除各分E-R图的冲突，生成初步E-R图。（如：属性冲突、命名冲突、结构冲突）
修改与重构。消除不必要的冗余（冗余的数据、冗余的联系），生成基本E-R图

逻辑结构设计的步骤，E-R图向关系模型的转换，数据模型的优化，设计用户子模式

逻辑结构设计的任务

概念结构是各种数据模型的共同基础
逻辑结构设计的任务就是把概念结构设计阶段设计好的基本E-R图转换为与选用DBMS产品所支持的数据模型相符合的逻辑结构

E-R图向关系模型的转化

转换内容
- 将E-R图转换为关系模型：将实体、实体的属性和实体之间的联系转化为关系模式
转换原则
- 一个 实体型 转化为一个关系模式
  - 关系的属性：实体型的属性
  - **关系的码：**实体型的码
- 一个 m:n 联系转换为一个关系模式
  - 关系的属性： 与该联系相连的各实体的主码以及联系本身的属性
  - **关系的主码：**各实体主码的组合
- 一个1:n联系可以转换为一个独立的关系模式，也可以与n端对应的关系模式合并
  - 转换为一个独立的关系模式
  - **关系的属性：**与该联系相连的各实体的主码以及联系本身的属性
  - 关系的主码：n端实体的主码
  - 与n端对应的关系模式合并
    合并后关系的属性：在n端关系中加入1端关系的主码和联系本身的属性。
    合并后关系的主码：不变
- 一个1:1联系可以转换为一个独立的关系模式，也可以与任意一端对应的关系模式合并
  - 转换为一个独立的关系模式
    - 关系的属性：与该联系相连的各实体的主码以及联系本身的属性
    - 关系的候选码：每个实体的主码均是该关系的候选码
  - 与某一端对应的关系模式合并
    - **合并后关系的属性：**加入对应关系的主码和联系本身的属性
    - **合并后关系的主码：**不变
- 三个或三个以上实体间的一个多元联系转换为一个关系模式
  - **关系的属性：**与该多元联系相连的各实体的主码以及联系本身的属性
  - **关系的主码：**各实体主码的组合
- 具有相同码的关系模式可合并

数据模型的优化

关系数据模型的优化通常以规范化理论为指导

设计用户子模式

定义数据库全局模式主要是从系统的时间效率、空间效率、易维护等角度出发
定义用户外模式时应该更注重考虑用户的习惯与方便。包括三个方面：
- 使用更符合用户习惯的别名
- 针对不同级别的用户定义不同的外模式，以满足系统对安全性的要求
- 简化用户对系统的使用：
  如果某些局部应用中经常要使用某些很复杂的查询为了方便用户，可以将这些复杂查询定义为视图

物理结构设计的内容和方法，存取方法的选择，物理结构的评价

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

为关系模式选择存取方法(建立存取路径)
- 索引存取方法
- 聚簇存取（Cluster）方法
- HASH存取方法
确定数据库的存储结构
确定数据的存放位置和存储结构
确定系统配置

数据库的实施与维护

数据库实施的工作内容

用DDL定义数据库结构
组织数据入库
编制与调试应用程序
数据库试运行

数据库的维护

市场型维护作用有DBA完成，包括：
- 数据库的转储和恢复
- 数据库的安全性、完整性控制
- 数据库性能的监督、分析和改进
- 数据库的重组织和重构造

第八章数据库编程

L/SQL编程的基础知识：PL/SQL程序的3个组成部分，变量的使用方法，数据类型，运算符与表达式，三大程序控制结构

PL/SQL也是一种程序语言，叫过程化SQL语言(Procedural Language/SQL)

PL/SQL程序

PL/SQL程序的组成 3部分
- 声明部分
- 执行部分
- 异常处理部分

程序结构

DECLARE  
   /* 声明部分: 在此声明PL/SQL用到的变量,类型及游标，以及局部的存储过程和函数 ，可选*/
BEGIN
    /*执行部分: 过程及SQL语句,即程序的主要部分，必须*/
EXCEPTION
    /* 执行异常部分: 错误处理，可选*/
END;
1
2
3
4
5
6
7

变量及数据类型

变量的声明

declare
	变量名 数据类型;
	变量名 表名.列名%type;	   //变量与类所对应的数据类型相同
	变量名 表名%powtype;		//数据类型与表的数据结构相同
1
2
3
4

变量赋值

变量名 := 常量或表达式		 //在声明与执行阶段均可执行
1

运算符与表达式
- 一般运算符
- 关系运算符
- 逻辑运算符
pl/sql流程控制语句
- PL/SQL的流程控制语句, 包括如下三类:、
- 顺序语句:
  - GOTO语句：无条件跳转到指定的标号
  - NULL语句：说明“不用做任何事情”的意思，相当于一个占位符
- 条件语句:
  - IF 语句
- 循环语句:
  - LOOP…END LOOP语句
  - WHILE语句
  - FOR循环语句

常用方法：dbms_output.put_line('字符串' || 变量)

游标的概念，游标的使用步骤

游标的概念

在 PL/SQL 程序中，对于处理多行记录的事务经常使用游标来实现
游标是系统为用户开设的一个数据缓冲区，内存中一段连续的存储单元，存放SQL语句的执行结果。每个游标区都有一个名字
PL/SQL通过游标提供了一个对结果集进行逐行处理的能力，游标可以看作一种特殊的指针，它与某个查询结果相联系，可以指向结果集的任意位置，以便对指定位置的数据进行处理

游标的使用步骤

声明游标

declare 
cursor 游标名称 is
	select查询语句;
1
2
3

打开游标
```
open 游标名称;
1
```

提取游标元素

loop
	fetch 游标名称 into 变量1, 变量2, ...;
	exit when 游标名称%notfound;
end loop;
1
2
3
4

关闭游标
```
close 游标名称
1
```

游标的属性

%FOUND：布尔型属性
- 游标刚打开，指针指向第一行元组之前时，值为NULL
- 游标指针指向查询结果集时，值为TRUE
- 其它，值为FALSE
%NOTFOUND：布尔型属性，与%FOUND相反
%ISOPEN：布尔型属性，当游标已打开时返回 TRUE
%ROWCOUNT：数字型属性，返回已从游标中读取的记录数

存储过程的概念，创建与执行存储过程

存储过程的概念

ORACLE 提供可以把PL/SQL 程序存储在数据库中，并可以在任何地方来运行它。这样就叫存储过程
存储过程就是一系列PL/SQL语句的集合，为了完成某个会重复使用的特定功能

创建存储过程

语法格式：
CREATE [OR REPLACE] PROCEDURE <过程名>
[(<参数名><参数类型><数据类型>[DEFAULT <默认值>][,…n])]
{ IS | AS }
[<变量声明> ]
BEGIN
<过程体>
END[过程名];

1
2
3
4
5
6
7
8
9

参数类型有三种
- IN：参数是输入给过程的
- OUT：参数在过程中将被赋值，可以传给过程体的外部
- IN OUT：既可以向过程体传值，也可以在过程体中赋值

存储过程的调用

begin
	<过程名>[([<参数名>=>]<实参>[,…n])]; 
end;
1
2
3

删除存储过程

DROP PROCEDURE   存储过程名
1

触发器的概念与基本原理，定义触发器，激活触发器，删除触发器

触发器是一种特殊的存储过程，当某个ORACLE事件发生时系统自动地运行，所以运行触发器就叫触发,触发器不能接收参数

触发器由三个部分组成：事件、条件、动作。

事件：或称为触发事件，当某个事件发生的时候就运行触发器

条件：判断是否达到指定的条件，如果没有达到条件将不执行
动作：条件通过后所要做的事情

动作，可以留空，表示直接执行动作

创建触发器

CREATE OR REPLACE TRIGGER  trigger_name 
	{BEFORE | AFTER} <触发事件> ON <表名>
    [FOR EACH ROW]
    [WHEN <触发条件>]
    <触发动作体>

1
2
3
4
5
6

before|after 触发时序
<触发事件>：insert，delete，update
for each row：行触发
当触发器被激活时，在触发体中要使用激活触发器的语句中操作的数据，需要用到以下两个修饰符
- :new修饰符，如果激活触发器的语句为Insert，Update，被插入的数据与被更新后的数据在触发体中由:new引用
- :old修饰符，如果激活触发器的语句为Delete，Update，被删除的数据与被更新前的数据在触发体中由:old引用。

删除触发器

DROP TRIGGER trigger_name;
1

第十章数据库恢复技术

事务的概念及ACID性

什么是事物？

事务(Transaction)是用户定义的一个数据库操作序列，这些操作要么全做，要么全不做，是一个不可分割的工作单位
事务和程序是两个概念
- 在关系数据库中，一个事务可以是一条SQL语句，一组SQL语句或整个程序
- 一个程序通常包含多个事务
事务是恢复和并发控制的基本单位
显式定义方式
隐式定义的方式

事务的ACID特性：

原子性（Atomicity）

事务是数据库的逻辑工作单位，事务中包括的诸操作要么都做，要么都不做
一致性（Consistency）

事务执行的结果必须是使数据库从一个一致状态变到另一个一致状态
隔离性（Isolation）

对并发执行而言，一个事务的执行不能被其他事务干扰
持续性（Durability ）

一个事务一旦提交，它对数据库中数据的改变就应该是永久性的

事务故障、系统故障及介质故障的产生及特点

故障的种类

事物内部的故障

某个事务在运行过程中由于种种原因未运行至正常终止点就夭折了
系统故障

造成系统停止运转的任何事件，使得系统要重新启动
介质故障

介质故障又称为硬故障，这类故障使存储在外存中的数据部分丢失或全部丢失
计算机病毒

一种人为的故障或破坏，是一些恶作剧者研制的一种计算机程序

对数据库的影响

数据库本身被破坏
数据库没有被破坏，但数据可能不正确

数据转储的概念与用途，日志文件的内容及作用

恢复操作的基本原理：冗余

利用存储在系统其它地方的冗余数据来重建数据库中已被破坏或不正确的那部分数据

恢复机制涉及的关键问题

如何建立冗余数据
数据转储
登录日志文件
如何利用这些冗余数据实施数据库恢复

转储是指DBA通过DBMS的恢复子系统，将整个数据库复制到磁带或另一个磁盘上保存起来的过程，这些备用的数据称为后备副本或后援副本

数据库遭到破坏后可以将后备副本重新装入
但重装后备副本只能将数据库恢复到转储时的状态

静态转储与动态转储

静态转储：在系统中无运行事务时进行转储，转储开始时数据库处于一致性状态，转储期间不允许对数据库的任何存取、修改活动
动态转储：转储操作与用户事务并发进行转储期间允许对数据库进行存取或修改。

海量转储与增量转储

海量转储: 每次转储全部数据。
增量转储: 只转储上次转储后更新过的数据

日志文件：是用来记录事务对数据库的更新操作的文件

每个事务开始的标记、每个事务的结束标记和每个更新操作均作为日志文件中的一个日志记录 (log record)
日志的内容
- 事务标识（标明是哪个事务）
- 操作类型（插入、删除或修改）
- 操作对象（记录内部标识）
- 更新前数据的旧值（对插入操作而言，此项为空值）
- 更新后数据的新值（对删除操作而言, 此项为空值）
日志文件的用途
- 事务故障恢复和系统故障恢复必须用日志文件
- 在动态转储方式中必须建立日志文件，后援副本和日志文件综合起来才能有效地恢复数据库
- 在静态转储方式中，也可以建立日志文件

事务故障、系统故障和介质故障的恢复

**事务故障：**事务在运行至正常终止点前被中止。

恢复方法
- 由恢复子系统应利用日志文件撤消（UNDO）此事务已对数据库进行的修改。
事务故障的恢复由系统自动完成，不需要用户干预

**系统故障：**造成系统停止运转的任何事件，使得系统要重新启动

系统故障造成数据库不一致状态的原因
- 一些未完成事务对数据库的更新已写入数据库
- 一些已提交事务对数据库的更新还留在缓冲区没来得及写入数据库
恢复方法
- Undo 故障发生时未完成的事务
- Redo 已完成的事务
系统故障的恢复由系统在重新启动时自动完成，不需要用户干预

**介质故障：**介质故障又称为硬故障，这类故障使存储在外存中的数据部分丢失或全部丢失

恢复步骤
- 装入最新的后备数据库副本，使数据库恢复到最近一次转储时的一致性状态
- 装入有关的日志文件副本（转储结束时刻的日志文件副本），重做已完成的事务
介质故障的恢复需要DBA介入
DBA的工作
- 重装最近转储的数据库副本和有关的各日志文件副本
- 执行系统提供的恢复命令
具体的恢复操作仍由DBMS完成

第十一章并发控制

丢失修改、不可重复读和读“脏”数据三类不一致性的现象与本质

并发操作不正确的调度方式带来的数据不一致性现象：

丢失修改（Lost Update）
- 现象：事务T2的提交结果破坏了事务T1提交的结果，导致T1的修改丢失
- 本质：两个事务执行相互干扰，破坏了事务的隔离性
不可重复读（Non-repeatable Read）
- 现象：事务T1读取数据后，事务T2执行更新操作，使T1无法再现前一次读取结果
- 本质：两个事务执行相互干扰，破坏了事务的隔离性
读“脏”数据（Dirty Read）
- 现象：事务T2读取T1已修改过又恢复原值的数据，读到了不存在的数据
- 本质：两个事务执行相互干扰，破坏了事务的隔离性
结论：不正确的方式调度并发操作会破坏事务的隔离性，最终导致数据库中数据不一致

排他锁与共享锁的概念，锁的相容矩阵

并发控制概述

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

封锁：

就是事务T在对某个数据对象（例如表、记录等）操作之前，先向系统发出请求，对其加锁
加锁后事务T就对该数据对象有了一定的控制，在事务T释放它的锁之前，其它的事务不能更新此数据对象
基本封锁类型
- 排它锁（Exclusive Locks，简记为X锁）
  
  若事务T对数据对象A加上排它锁，则只允许T读取和修改A。其它任何事务都不能再对A加任何类型的锁，直到T释放A上的锁
- 共享锁（Share Locks，简记为S锁）
  
  若事务T对数据对象A加上共享锁，则事务T可以读A但不能修改A。其它事务只能再对A加共享锁，而不能加排它锁，直到T释放A上的共享锁

锁的相容矩阵

一级、二级和三级封锁协议

封锁协议
运用封锁方法时，对数据对象加锁时需要约定一些规则：

何时申请X锁或S锁
持锁时间
何时释放封锁等
对封锁方式制定不同的规则，就形成了各种不同的封锁协议

三种封锁协议：

一级封锁协议：事务T在修改数据R之前必须先对其加X锁，直到事务结束才释放
二级封锁协议：在一级封锁协议的基础上增加事务T在读取数据R之前必须先对其加S锁，读完后即可释放S锁
三级封锁协议：在一级封锁协议的基础上增加事务T在读取数据R之前必须先对其加S锁，直到

活锁的产生及避免方法

封锁技术可以有效地解决并发操作的一致性问题，但也带来一些新的问题：

死锁
活锁

活锁

假设T1对A加锁，T2等待，等到T1解锁后T3又对A加锁，导致T2一直等待
避免活锁：采用先来先服务的策略
- 当多个事务请求封锁同一数据对象时
- 按请求封锁的先后次序对这些事务排队
- 该数据对象上的锁一旦释放，首先批准申请队列中第一个事务获得锁

死锁的产生，死锁的避免方法，死锁的诊断与解除

死锁

产生死锁的原因是两个或多个事务都已封锁了一些数据对象，然后又都请求对已被其他事务封锁的数据对象加锁，从而出现死等待
预防死锁的发生就是要破坏产生死锁的条件
- 一次封锁法
  
  要求每个事务在执行之前必须一次将所有要使用的数据全部加锁，否则就不能继续执行
  - 降低并发度
  - 难于事先精确确定封锁对象
- 顺序封锁法
  
  顺序封锁法是预先对数据对象规定一个封锁顺序，所有事务都按这个顺序实行封锁
  - 维护成本高
  - 难于实现

死锁的诊断与解除

死锁的诊断
- 超时法
  
  系统设置一个时间段，每隔规定的时间对系统中的事务进行检查，如果一个事务的等待时间超过了规定的时限，就认为发生了死锁
  - 优点：实现简单
  - 缺点：等待时间难于设置
- 事务等待图法
  
  用事务等待图动态反映所有事务的等待情况
解除死锁
- 选择一个处理死锁代价最小的事务，将其撤消
- 释放此事务持有的所有的锁，使其它事务能继续运行下去

可串行化调度的定义，可串行性的含义，冲突可串行化调度的作用

可串行化调度

多个事务并发执行，当且仅当其执行结果与按某一次序串行地执行这些事务时的结果相同，多个事务的并发执行是正确的，称这种调度策略为可串行化的调度
可串行性
- 是并发事务正确调度的准则
- 一个给定的并发调度，当且仅当它是可串行化的，才认为是正确调度
冲突操作
冲突操作是指不同的事务对同一个数据的读写操作和写写操作
可串行化调度的充分条件
- 一个调度Sc在保证冲突操作的次序不变的情况下，通过交换两个事务不冲突操作的次序得到另一个调度Sc’，如果Sc’是串行的，称调度Sc为冲突可串行化的调度
- 一个调度是冲突可串行化，一定是可串行化的调度

两段锁协议的内容及作用

目前DBMS普遍采用**两段锁协议（Two-Phase-Locking，简称2PL）**的方法实现并发调度的可串行性，从而保证调度的正确性

两段锁协议
指所有事务必须分两个阶段对数据项加锁和解锁

在对任何数据进行读、写操作之前，事务首先要获得对该数据的封锁
在释放一个封锁之后，事务不再申请和获得任何其他封锁
“两段”锁的含义
事务分为两个阶段：
- 第一阶段是获得封锁，也称为扩展阶段
  事务可以申请获得任何数据项上的任何类型的锁，但是不能释放任何锁
- 第二阶段是释放封锁，也称为收缩阶段
  事务可以释放任何数据项上的任何类型的锁，但是不能再申请任何锁
事务遵守两段锁协议是可串行化调度的充分条件，而不是必要条件

声明：本文内容由网友自发贡献，不代表【wpsshop博客】立场，版权归原作者所有，本站不承担相应法律责任。如您发现有侵权的内容，请联系我们。转载请注明出处：https://www.wpsshop.cn/w/空白诗007/article/detail/908794