数据库系统概论复习笔记(五)笔记汇总

教材：数据库系统概论（第五版）
出版社：高等教育出版社
（之前写好的笔记一直没发出来，排版方面与现在的笔记相比稍有欠缺。后面的章节比较零散就一次把全部笔记整合在一起了，并调整了一下排版。）

第一章 绪论

1.1 数据库系统概述

1.1.1 四个基本概念

1. 数据

定义：

• 数据（Data）是数据库中存储的基本对象

• 数据是描述事物的符号记录

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

2. 数据库(DB)

定义：是长期储存 在计算机内、有组织 的、可共享 的大量数据的集合

3. 数据库管理系统(DBMS)

定义：

• 位于用户与操作系统之间的一层数据管理软件

• 是基础软件，是一个大型复杂的软件系统

4. 数据库系统(DBS)

定义：是由数据库、数据库管理系统(及其应用开发工具)、应用程序和数据库管理员(DBA)组成的存储、管理、处理和维护数据的系统

1.2 数据模型

定义：是对现实世界数据特征的模拟

1.2.1 两大类数据模型

• 概念模型，也称信息模型，它是按用户的观点来对数据和信息建模，用于数据库设计。

• 逻辑模型和物理模型

1. 逻辑模型主要包括网状模型、层次模型、关系模型、面向对象数据模型、对象关系数据模型、半结构化数据模型等。按计算机系统的观点对数据建模，用于DBMS实现。

2. 物理模型是对数据最底层的抽象，描述数据在系统内部的表示方式和存取方法，在磁盘或磁带上的存储方式和存取方法。

1.2.2 概念模型

• 实体(可以是具体的人事物，也可以是抽象的概念和联系)

• 属性(描述实体所具有的某一特征，如学生实体可以由学号等属性组成)

• 码（唯一标识实体的属性集）

• 实体型(比如学生)

• 实体集(同一类型实体的集合，比如全体学生)

• 联系(实体集之间的联系通常是指不同实体集之间的联系)

• 实体-联系方法(E-R方法/E-R模型)//第七章

1.2.3 数据模型的组成要素

• 数据结构（静态特性）

• 数据操作（动态特性）

• 数据的完整性约束条件

1.2.7 关系模型

关系模型是数据模型的一种

1. 数据结构

• 关系：表

• 元组：行

• 属性：列

• 码：表里的某个属性组，它可以唯一确定一个元组

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

• 分量：元组中的一个属性值

• 关系模式：对关系的描述

2. 数据操控和完整性约束

数据操控：查询、插入、更新和删除数据

完整性约束条件：实体完整性、参照完整性和用户定义完整性

3. 关系模型的优缺点

略.

1.3 数据库系统的结构

数据库系统通常采用三级模式结构

数据库的二级映像功能

1.3.2 三级模式结构

• 模式(逻辑模式)：是数据库中全体数据的逻辑结构和特征的描述，是所有用户的公共数据视图

• 一个数据库只有一个模式

• 外模式(子模式/用户模式)：用户能看到、使用的局部数据的逻辑结构和特征的描述，是DB用户的数据视图，是与某一应用有关的数据的逻辑表示

• 外模式是模式的子集

• 一个数据库可以有多个外模式

• 内模式(存储模式)：是数据物理结构和存储方式的描述，是数据在数据库内部的组织方式

• 一个数据库只有一个内模式

1.3.3 二级映像功能和数据独立性

1. 外模式/模式映像

• 模式描述的是数据的全局逻辑结构

• 外模式描述的是数据的局部逻辑结构

• 同一个模式可以有任意多个外模式

• 每一个外模式，数据库系统都有一个外模式／模式映象，定义外模式与模式之间的对应关系

• 映象定义通常包含在各自外模式的描述中

保证了数据的逻辑独立性

当模式改变时，由数据库管理员对映像做相应改变，可使外模式保持不变，而应用程序是根据外模式编写的，从而应用模式不用更改，保证了数据和程序的逻辑独立性。

2. 模式/内模式映像

• 数据库中只有一个模式，也只有一个内模式，所以模式/内模式映像是唯一的

• 定义了数据全局逻辑结构与存储结构之间的对应关系

保证了数据的物理独立性

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

第二章 关系数据库

关系数据库系统：是支持关系模型的数据库系统

关系模型：由关系数据结构、关系操作集合和关系完整性约束三部分组成

关系模型的基础：集合代数

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

关系模型的数据结构(单一)：关系

2.1.1 关系

1. 相关概念

（1）域

• 一组具有相同数据类型的值的集合

• 定义了列的取值范围

（2）笛卡尔积

• 是所有可能的组合
  • 笛卡尔积可表示为一张二维表
  • 表中的每行对应一个元组，表中的每列对应一个域

（3）元组

• 笛卡尔积中每一个元素$（d_1，d_2，\dots ，d_n）$叫作一个n元组（n-tuple）或简称元组

（4）分量

• 笛卡尔积元素$（d_1，d_2，\dots ，d_n）$中的每一个值 $d_i$ 叫作一个分量

2. 关系

• 是笛卡尔积的一个有实际意义的有限子集

• 是元组的集合

• $D_1\times D_2\times \dots \times D_n$的有实际意义子集叫作在域$D_1，D_2，\dots ，D_n$上的关系，常常表示为$R（D_1，D_2，\dots ，D_n）$

  • $R$：关系名
  • $n$：关系的目或度（Degree）

（1）单元关系与二元关系

• 当n=1时，称该关系为单元关系或一元关系

• 当n=2时，称该关系为二元关系

（2）候选码(Candidate Key)/候选键

关系中的某一组属性能唯一的标识一个元组，而它的子集不能

候选码可以有多个

（3）主码

若一个关系中有多个候选码，则选定其中一个作为主码

主码只有一个，唯一标识一个元组

（4）主属性

组成候选码的属性

（5）非主属性/非码属性

不包含在任何侯选码中的属性

（6）关系的三种类型

• 基本关系(基本表/基表)

• 查询表

• 视图表(是虚表，不对应实际存储的数据)

（7）基本关系的性质

• 列是同质的。列中的分量是同类型数据，

• 不同的列可出自同一个域，其中的每一列称为一个属性，不同的属性要给予不同的属性名

• 列的顺序无所谓，列的次序可以任意交换

• 任意两个元组的候选码不能相同

• 行的顺序无所谓，行的次序可以任意交换

• 分量必须取原子值。即每个分量都是不可分的数据项 （属性是不可分割的数据项）

2.1.2 关系模式

是对关系的描述（有哪些属性，各个属性之间的依赖关系如何）

1. 关系模式的表示

关系模式可以形式化地表示为：R（U，D，DOM，F）

• R：关系名

• U：组成该关系的属性名集合

• D：U中属性所来自的域

• DOM：属性向域的映象集合

• F：属性间数据的依赖关系的集合

  可以简记为R (U)或$R(A_1，A_2，\dots ，A_n)$

• R: 关系名

• $A_1，A_2，\dots ，A_n$ : 属性名

  如：学生（学号，姓名，年龄，性别，系名，年级）

2. 关系模式与关系的区别

• 关系模式是型；关系是值

• 关系模式是静态的、稳定的；关系是动态的，随时间不断变化的。

• 关系模式是对关系的描述；关系是关系模式在某一时刻的状态或内容

2.1.3 关系数据库

在一个给定的应用领域中，所有关系的集合构成一个关系数据库

关系数据库的型: 关系数据库模式，是对关系数据库的描述

关系数据库的值: 关系模式在某一时刻对应的关系的集合，通常称为关系数据库

2.1.4 关系模型的存储结构

• 有的关系数据库管理系统中一个表对应一个操作系统文件，将物理数据组织交给操作系统完成

• 有的关系数据库管理系统从操作系统那里申请若干个大的文件，自己划分文件空间，组织表、索引等存储结构，并进行存储管理；

2.2 关系操作

• 查询

  选择、投影、连接、除、并、交、差

• 数据更新

  插入、删除、修改

集合操作方式：操作的对象和结果都是集合，也称为一次一集合的方式

2.3 关系的完整性

• 实体完整性和参照完整性

  是关系模型必须满足的完整性约束条件称为关系的两个不变性，应该由关系系统自动支持

• 用户定义的完整性

  应用领域需要遵循的约束条件，体现了具体领域中的语义约束

1. 实体完整性

若属性A是基本关系R的主属性，则属性A不能取空值 (主属性不能取空值)

2. 参照完整性

若属性（或属性组）F是基本关系R的外码它与基本关系S的主码Ks相对应（基本关系R和S不一定是不同的关系），则对于R中每个元组在F上的值必须为：

• 或者取空值（F的每个属性值均为空值）

• 或者等于S中某个元组的主码值

例子

学生（学号，姓名，性别，专业号，年龄，班长）

• “班长”是外码

• 学生关系既是参照关系也是被参照关系

“班长”属性值(外码)可以取两类值：

1. 空值，表示该学生所在班级尚未选出班长

2. 非空值，该值必须是本关系中某个元组的学号值

（1）外码

设F是基本关系R的一个或一组属性，但不是关系R的码。如果F与基本关系S的主码Ks相对应，则称F是R的外码。（F是R中一个或一组属性，但不是R的码，是S的主码，则F是R的外码）

• 基本关系R称为参照关系

• 基本关系S称为被参照关系或目标关系

注意：

• 关系R和S不一定是不同的关系(如班长与学号的例子)

• 目标关系S的主码Ks 和参照关系的外码F必须定义在同一个（或一组）域上

• 外码并不一定要与相应的主码同名(当外码与相应的主码属于不同关系时，往往取相同的名字，以便于识别)

例子

学生（学号，姓名，性别，专业号，年龄）

专业（专业号，专业名）

• “专业号”属性是学生关系的外码

• 专业关系是被参照关系，学生关系为参照关系

3. 用户定义的完整性

关系模型应提供定义和检验这类完整性的机制，以便用统一的系统的方法处理它们，而不需由应用程序承担这一功能

2.4 关系代数

是一种抽象的查询语言，它用对关系的运算来表达查询

运算三大要素：

• 运算对象(关系)

• 运算符(集合运算符和专门的关系运算符)

• 运算结果(关系)

2.4.1 传统的集合运算

1. 并

$R\cup S=\{t|t\in R\vee t\in S\}$

仍为n目关系，由属于R或属于S的元组组成

2. 差

$R-S=\{t|t\in R\wedge t\notin S\}$

仍为n目关系，由属于R而不属于S的所有元组组成

3. 交

$R\cap S=\{t|t\in R\wedge t\in S\}$

仍为n目关系，由既属于R又属于S的元组组成

4. 笛卡尔积

无条件的头尾连接

• $R:n目关系，k_1个元组$

• $S:m目关系，k_2个元组$

R×S ：

• 列：$（n+m）$列元组的集合

元组的前n列是关系R的一个元组

元组的后m列是关系S的一个元组

• 行：$k_1\times k_2$个元组

2.4.2 专门的关系运算

1. 引入记号

(2)分量：$t[A_i]$

设关系模式为$R(A_1，A_2，\dots ，A_n)$

它的一个关系设为R

$t\in R$表示t是R的一个元组

$t[A_i]$则表示元组t中相应于属性$A_i$的一个分量

(2)剩余属性组

(3)元组的连接

(4)象集

本质上是一次选择行的运算和一次选择列的运算

• 给定一个关系$R（X，Z）$，X和Z为属性组

• 当$t[X]=x$时，x在R中的象集（Images Set）为：

  $Z_x=\{t[Z]|t\in R，t[X]=x\}$

  • 它表示R中属性组X上值为x的诸元组在Z上分量的集合

• 本质上是一次选择行的运算和一次选择列的运算

• 求$x_1$在表A中的象集

  • 先选出所有x属性中$x=x_1$的那些行
  • 然后选择出不包含x1的那些列

2. 选择

从行的角度进行的运算

• 在关系R中选择满足给定条件的诸元组

• ${\sigma }_{F(R)}=\{t|t\in R\wedge F(t){=}^{\prime }{真}^{\prime }\}$

  • F：选择条件，是一个逻辑表达式，取值为“真”或“假”

  • $F=X_1\theta Y_1$

  • θ表示比较运算符，它可以是＞，≥，＜，≤，＝或<>

  • 例：查询信息系（IS系）全体学生

    ${\sigma }_{Sdept}=‘I{S}_{(Student)}^{\prime }$

3. 投影

主要是从列的角度进行运算

• 从R中选择出若干属性列组成新的关系

• ${\pi }_{A(R)}=\{t[A]|t\in R\}$

  • A：R中的属性列

  • 例：查询学生的姓名和所在系

    ${\pi }_{Sname,Sdept}(Student)$

4. 连接

从行的角度进行运算

• 也称θ连接

• 从两个关系的笛卡尔积中选取属性间满足一定条件的元组

（1）等值连接

• θ为“=”时的θ连接

（2）自然连接

• 自然连接还需要取消重复列，所以是同时从行和列的角度进行运算

• 是特殊的等值联结

  • 两个关系中进行比较的分量必须是相同的属性组
  • 在结果中把重复的属性列去掉

（3）悬浮元组

• 两个关系R和S在做自然连接时，关系R中某些元组有可能在S中不存在公共属性上值相等的元组，从而造成R中这些元组在操作时被舍弃了，这些被舍弃的元组称为悬浮元组

（4）外连接

• 如果把悬浮元组也保存在结果关系中，而在其他属性上填空值(Null)，就叫做外连接
  • 左外连接只保留左边关系R中的悬浮元组
  • 右外连接只保留右边关系S中的悬浮元组

5. 除运算

同时从行和列角度进行运算

对于表A和表B，求A÷B

• 找出表B中与A属性相同的那些列

• 求表A中各个不同x对应的象集

• 找表A中的x，这个x要满足：表B是x的象集的子集

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

SQL：结构化查询语言，是关系数据库的标准语言

3.1 SQL概述

SQL的特点

1. 综合统一

2. 高度非过程化(必须指定存取路径)

3. 面向集合的操作方式

4. 以同一种语法结构提供两种使用方法

5. 语言简洁，易学易用

SQL支持关系数据库三级模式结构

3.3 数据定义

数据库（有的系统称为目录）→ 模式 → 表以及视图、索引等

• 一个关系数据库管理系统的实例（Instance）中可以建立多个数据库

• 一个数据库中可以建立多个模式

• 一个模式下通常包括多个表、视图和索引等数据库对象

3.3.1 数据库模式的定义与删除

这里的模式，不是关系模式,也不是三级模式结构中的模式，指的是数据库管理系统（软件）的一个层次，也是实际的一个用户数据库

1. 定义模式

CREATE SCHEMA  AUTHORIZATION

定义数据库模式实际上定义了一个命名空间

2. 删除模式

DROP SCHEMA

（1）CASCADE（级联）

删除模式的同时把该模式中所有的数据库对象全部删除

（2）RESTRICT（限制）

• 如果该模式中定义了下属的数据库对象（如表、视图等），则拒绝该删除语句的执行。

• 仅当该模式中没有任何下属的对象时才能执行。

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

1. 定义基本表

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


  CREATE TABLE Student  
  (Sno CHAR(9) PRIMARY KEY, 
    Sname CHAR(20) UNIQUE,
    Ssex CHAR(2),
    Sage SMALLINT,
    Sdept CHAR(20)
  ); 

常用完整性约束

• 主码约束：PRIMARY KEY

• 唯一性约束：UNIQUE

• 非空值约束：NOT NULL

• 参照完整性约束 FOREIGN KEY

2. 修改基本表

ALTER TABLE <表名>
[ ADD <新列名> <数据类型> [ 完整性约束 ] ]
[ DROP <完整性约束名> ]
[ ALTER COLUMN <列名> <数据类型> ]；

ALTER TABLE Student ADD S_entrance DATE;

• <表名>：要修改的基本表

• ADD子句：增加新列和新的完整性约束条件

• DROP子句：删除表中的列和删除指定的完整性约束条件

• ALTER COLUMN子句：用于修改列名和数据类型

3. 删除基本表

直接删除属性列:

例：ALTER TABLE Student Drop Scome；

3.3.3 索引的建立与删除

建立索引的目的：加快查询速度

索引类型：

• 顺序文件上的索引

• B+树索引(具有动态平衡的优点)

• 散列（hash）索引(具有查找速度快的特点)

• 位图索引

• 采用B+树

1. 建立索引

CREATE [UNIQUE] [CLUSTER] [NONCLUSTERED] INDEX <索引名>
ON <表名>(<列名>[<次序>][,<列名>[<次序>] ]…);

• <表名>：要建索引的基本表的名字

• 索引：可以建立在该表的一列或多列上，各列名之间用逗号分隔

• <次序>：指定索引值的排列次序，升序：ASC，降序：DESC，缺省值：ASC

• UNIQUE：此索引的每一个索引值只对应唯一的数据记录

• CLUSTER：表示要建立的索引是聚簇索引

• NONCLUSTERED：创建非聚集索引。缺省是创建非聚集索引

例子

SC表按学号升序和课程号降序建唯一索引

CREATE UNIQUE INDEX  SCno ON SC(Sno ASC,Cno DESC);

2. 修改索引

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

例子

将SC表的SCno索引名改为SCSno

    ALTER INDEX SCno RENAME TO SCSno;

3. 删除索引

DROP INDEX <索引名>;
DROP INDEX <表名>.<索引名>

例子

删除Student表的Stusname索引

DROP INDEX Stusname;

3.3.4 数据字典

数据字典是关系数据库管理系统内部的一组系统表，它记录了数据库中所有定义信息

• 关系模式定义

• 视图定义

• 索引定义

• 完整性约束定义

• 各类用户对数据库的操作权限

• 统计信息等

关系数据库管理系统在执行SQL的数据定义语句时，实际上就是在更新数据字典表中的相应信息

3.4 数据查询

SELECT [ALL|DISTINCT] <目标列表达式>[,<目标列表达式>] …
   FROM <表名或视图名>[,<表名或视图名> ]…|(SELECT 语句)  
   [AS]<别名>
[ WHERE <条件表达式> ]
[ GROUP BY <列名1> [ HAVING <条件表达式> ] ]
[ ORDER BY <列名2> [ ASC|DESC ] ];

• SELECT子句：指定要显示的属性列

• FROM子句：指定查询对象（基本表或视图）

• WHERE子句：指定查询条件

• GROUPBY子句：对查询结果按指定列的值分组，该属性列值相等的元组为一个组。通常会在每组中作用聚集函数。

• HAVING短语：只有满足指定条件的组才予以输出

• ORDER BY子句：对查询结果表按指定列值的升序或降序排序

3.4.1 单表查询

查询仅涉及一个表

1. 选择表中的若干列

查询全部列：SELECT * FROM Student;

2. 选择表中的若干元组

（1）消除取值重复的行

指定DISTINCT关键词，去掉表中重复的行(作用范围是所有目标列)

（2）查询满足条件的元组

• 确定范围

  • BETWEEN … AND …

  • NOT BETWEEN … AND …

• 确定集合

  • IN
  • NOT IN
  • 例：WHERE Sdept IN ('CS','MA’,'IS' );

• 字符匹配

  • [NOT] LIKE ‘<匹配串>’

• 当匹配模板为固定字符串时：

  • 可以用 = 运算符取代 LIKE 谓词
  • 用 != 或 < >运算符取代 NOT LIKE 谓词

• 匹配串：

  • % （百分号） 代表任意长度（长度可以为0）的字符串
  • _ （下横线） 代表任意单个字符。
  • [ ]：匹配[ ]中的任意一个字符
  • [^ ]：不匹配[ ]中的任意一个字符
  • 涉及空值的查询
    • IS NULL
    • IS NOT NULL

• 多重条件查询

  • AND和 OR来连接多个查询条件

3. ORDER BY子句

可以按一个或多个属性列排序

例：ORDER BY Grade DESC;

4. 聚集函数

聚合函数就用来输入多个数据，输出一个数据的

WHERE子句中不能用聚集函数作为条件表达式。聚集函数只能用于SELECT子句和GROUP BY
中的HAVING子句

• 统计元组个数

  COUNT(*)
  

• 统计一列中值的个数

  COUNT([DISTINCT|ALL] <列名>)
  

• 计算一列值的总和（此列必须为数值型）

  SUM([DISTINCT|ALL] <列名>)	
  

• 计算一列值的平均值（此列必须为数值型）

  AVG([DISTINCT|ALL] <列名>)
  

• 求一列中的最大值和最小值

  MAX([DISTINCT|ALL] <列名>)
  MIN([DISTINCT|ALL] <列名>)
  

5. GROUP BY子句(分组查询)

• 如果未对查询结果分组，聚集函数将作用于整个查询结果
• 对查询结果分组后，聚集函数将分别作用于每个组
  • 按指定的一列或多列值分组，值相等的为一组
  • GROUP BY子句的作用对象是查询的中间结果表

3.4.2 连接查询

1. 等值与非等值连接查询

等值连接：连接运算符为=

2. 自身连接

• 一个表与其自己进行连接

• 需要给表起别名以示区别

• 由于所有属性名都是同名属性，因此必须使用别名前缀

例

查询每一门课的间接先修课（即先修课的先修课）

SELECT  FIRST.Cno, SECOND.Cpno
 FROM  Course  FIRST, Course  SECOND
 WHERE FIRST.Cpno = SECOND.Cno;

3. 多表连接

查询每个学生的学号、姓名、选修的课程名及成绩

  SELECT Student.Sno, Sname, Cname, Grade
   FROM Student, SC, Course/*多表连接*/
   WHERE Student.Sno = SC.Sno 
         AND SC.Cno = Course.Cno;

3.4.3 嵌套查询

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

3.4.4 集合查询

种类：

• 并操作UNION

  • 参加UNION操作的各结果表的列数必须相同；对应项的数据类型也必须相同
  • 自动去掉重复元组，如果要保留重复元组，用ALL。

• 交操作INTERSECT

• 差操作EXCEPT

3.4.5基于派生表的查询

子查询不仅可以出现在WHERE子句中，还可以出现在FROM子句中，这时子查询生成的临时派生表成为主查询的查询对象

3.5 数据更新

3.5.1 插入数据

1. 两种插入数据方式

（1） 插入元组

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

INTO子句

• 指定要插入数据的表名及属性列

• 属性列的顺序可与表定义中的顺序可以不一致

• 没有指定属性列：表示要插入的是一条完整的元组，且属性列属性与表定义中的顺序一致

• 指定部分属性列：插入的元组在其余属性列上取空值

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

INSERT
INTO  Student
VALUES ('201215128','陈冬','男', 18, 'IS');

（2）插入子查询结果

可以一次插入多个元组

3.5.2 修改数据

UPDATE  <表名>
SET  <列名>=<表达式>[,<列名>=<表达式>]…
[WHERE <条件>];

• 修改指定表中满足WHERE子句条件的元组

• SET子句给出的值用于取代相应的属性列

• 如果省略WHERE子句，表示要修改表中的所有元组

例子：将计算机系学生的年龄增加1岁。

UPDATE Student
SET Sage= Sage+1
WHERE sdept='cs';

3.5.3 删除数据

   DELETE
   FROM     <表名>
   [WHERE <条件>];

3.7 视图

视图的特点

• 虚表，是从一个或几个基本表（或视图）导出的表

• 只存放视图的定义，不存放视图对应的数据

• 基表中的数据发生变化，从视图中查询出的数据也随之改变

• 对视图数据的操作最终都会转换为对基本表的操作

3.7.1 定义视图

1. 建立视图 CREATE VIEW

   CREATE  VIEW <视图名>  [(<列名>  [,<列名>]…)]
   AS  <子查询>
   [WITH  CHECK  OPTION];

组成视图的属性列名：全部省略或全部指定

（1）全部省略:

由子查询中SELECT目标列中的诸字段组成

（2）明确指定视图的所有列名:

• 某个目标列是聚集函数或列表达式

• 多表连接时选出了几个同名列作为视图的字段

• 需要在视图中为某个列启用新的更合适的名字

关系数据库管理系统执行CREATE
VIEW语句时只是把视图定义存入数据字典，并不执行其中的SELECT语句

（3）行列子集视图

若一个视图是从单个基本表导出的，并且只是去掉了基本表的某些行和某些列，保留了主码

（4）带表达式的视图

带虚拟列的视图

（5）分组视图 带有GROUP

BY子句的查询来定义视图

2. 修改视图 ALTER VIEW

ALTER VIEW  视图名 [( 列名[ ,...n ] )] 
AS
查询语句 

3. 删除视图 DROP VIEW

DROP  VIEW  <视图名>[CASCADE];

3.7.2 查询视图

略

3.7.3 更新视图 允许对行列子集视图进行更新

3.7.4 视图的作用

• 视图能够简化用户的操作

• 视图使用户能以多种角度看待同一数据

• 视图对重构数据库提供了一定程度的逻辑独立性

• 视图能够对机密数据提供安全保护

• 适当的利用视图可以更清晰的表达查询

第四章 数据库安全性

4.2 数据库安全性控制

4.2.2 存取控制

常用存取控制方法

（1）自主存取控制

• 用户对不同的数据对象有不同的存取权限

• 不同的用户对同一对象也有不同的权限

• 用户还可将其拥有的存取权限转授给其他用户

（2）强制存取控制

• 每一个数据对象被标以一定的密级

• 每一个用户也被授予某一个级别的许可证

• 对于任意一个对象，只有具有合法许可证的用户才可以存取

4.2.4 授权：授予与回收

PUBLIC:全体用户

1. GRANT

   GRANT <权限>[,<权限>]... 
   ON <对象类型> <对象名>[,<对象类型> <对象名>]…
   TO <用户>[,<用户>]...
   [WITH GRANT OPTION];

语义：将对指定操作对象的指定操作权限授予指定的用户

例子

把查询Student表权限授给用户U1

  GRANT   SELECT 
  ON   TABLE   Student 
  TO   U1;

把对Student表和Course表的全部权限授予用户U2和U3

  GRANT ALL PRIVILIGES 
  ON TABLE Student,Course 
  TO U2,U3;

2. REVOKE

REVOKE <权限>[,<权限>]... 
ON <对象类型> <对象名>[,<对象类型><对象名>]…
FROM <用户>[,<用户>]...[CASCADE | RESTRICT];

4.2.5 数据库角色

角色是权限的集合

角色的创建 CREATE ROLE

4.2.6 强制存取控制方法

1. 强制存取控制规则

• 仅当主体的许可证级别大于或等于客体的密级时，该主体才能读取相应的客体

• 仅当主体的许可证级别小于或等于客体的密级时，该主体才能写相应的客体

第五章 数据库完整性

数据的完整性是指数据的正确性和相容性

• 数据的正确性

  是指数据是符合现实世界语义，反映了当前实际状况的

• 数据的相容性

  是指数据库同一对象在不同关系表中的数据是符合逻辑的

5.1 实体完整性

5.1.1 实体完整性定义

CREATE TABLE中用PRIMARY KEY定义

单属性构成的码有两种说明方法

• 定义为列级约束条件

• 定义为表级约束条件

• CREATE TABLE Student  
  ( Sno CHAR(9) PRIMARY KEY,  
  Sname CHAR(20) NOT NULL,  
  Ssex CHAR(2),  
  Sage SMALLINT,  
  Sdept CHAR(20)  
  );
  

对多个属性构成的码只有一种说明方法

• 定义为表级约束条件

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

入或对主码列进行更新操作时，关系数据库管理系统按照实体完整性规则自动进行检查。包括：

• 检查主码值是否唯一，如果不唯一则拒绝插入或修改

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

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 元组上的约束条件

在CREATE TABLE时可以用CHECK短语定义元组上的约束条件，即元组级的限制

5.6 断言

SQL中，可以使用CREATE ASSERTION语句，通过声明性断言来指定更具一般性的约束。

5.7 触发器

触发器（Trigger）是用户定义在关系表上的一类由事件驱动的特殊过程

第六章 关系数据理论

6.1 问题的提出

• 关系模式是一个五元组

• R(U, D, DOM, F)

  • 关系名R是符号化的元组语义
  • U为一组属性
  • D为属性组U中的属性所来自的域
  • DOM为属性到域的映射
  • F为属性组U上的一组数据依赖

本章把关系模式看作一个三元组：

• R
  • 当且仅当U上的一个关系r满足F时，r称为关系模式R的一个关系
  • 作为二维表，关系要符合一个最基本的条件：每个分量必须是不可分割的数据项。满足了这个条件的关系模式就属于第一范式（1NF）

数据依赖

通过属性间值的相等与否以及相互之间制约等体现出来的数据间相互联系

主要类型

• 函数依赖（FD）

• 多值依赖（MVD）

• 其他

6.2 规范化

6.2.1 函数依赖

1.函数依赖

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

(1)说明：

1. 函数依赖不是指关系模式R的某个或某些关系实例满足的约束条件，而是指R的所有关系实例均要满足的约束条件

2. 函数依赖是语义范畴的概念。只能根据数据的语义来确定函数依赖

3. 数据库设计者可以对现实世界作强制的规定

(2)一些符号与标记：

• 若$X\to Y$，则X称为这个函数依赖的决定属性组，也称为决定因素

• 若$X\to Y$，$Y\to X$，则记作$X\leftarrow \to Y$

• 若Y不函数依赖于X，则记作$X\nrightarrow Y$

2.平凡函数依赖与非平凡函数依赖

• $X\to Y$，但$Y⊈X$则称$X\to Y$是非平凡的函数依赖

• $X\to Y$，但$Y\subseteq X$ 则称$X\to Y$是平凡的函数依赖

  对于任一关系模式，平凡函数依赖都是必然成立的

3.完全函数依赖与部分函数依赖

• 在R(U)中，如果$X\to Y$，并且对于X的任何一个真子集$X’$, 都有 $X’\nrightarrow Y$，则称Y对X完全函数依赖(X的真子集不能决定Y).否则，若$X\to Y$，但Y不完全函数依赖于X，则称Y对X部分函数依赖

4.传递函数依赖

在R(U)中，如果$X\to Y(Y⊈X)，Y\nrightarrow X，Y\to Z，Z⊈Y$, 则称Z对X传递函数依赖

注: 如果$Y\to X$, 即$X\leftarrow \to Y$，则Z直接依赖于X，而不是传递函数依赖

6.2.2 码

通常专指候选码

（1）候选码与超码

• 设K为R中的属性或属性组合。若U完全函数依赖K，则K称为R的一个候选码

• 如果U部分函数依赖于K，则K称为超码

• 若关系模式R有多个候选码，则选定其中的一个做为主码

（2）主属性与非主属性

• 主属性：包含在任何一个候选码中的属性

• 非主属性/非码属性：不包含在任何码中的属性

• 全码：整个属性组是码

6.2.3 范式

1NF

• 每一个分量(所有的属性)都是不可分的数据项

6.2.4 2NF

• 若关系模式$R\in 1NF$，并且每一个非主属性都完全函数依赖于任何一个候选码，则$R\in 2NF$

  （就是有一个唯一主键，并且非主属性对候选键是完全依赖。）

• $1NF\to 2NF$：消除了非主属性对码的部分函数依赖

6.2.5 3NF

• 设关系模式$R\in 1NF$,若R中不存在这样的码X、属性组Y及非主属性$Z（Y⊈Z）$,
  使得$X\to Y，Y\to Z成立，Y\nrightarrow X$不成立，则称$R\in 3NF$
• 若$R\in 3NF$，则每一个非主属性既不部分依赖于码也不传递依赖于码
• $2NF\to 3NF$：消除了非主属性对码的传递函数依赖

6.2.6 BCNF

• 设关系模式$R\in 1NF$，若$X\to Y且Y⊈X$，时X必含有码，则$R\in BCNF$

  （候选键存在多个属性时，多个主属性直接要消除传递依赖关系）

  (不能存在关键字段决定关键字段的情况)

性质

• 所有非主属性都完全函数依赖于每个候选码

• 所有主属性都完全函数依赖于每个不包含它的候选码

• 没有任何属性完全函数依赖于非码的任何一组属性

3NF与BCNF的关系

• 如果关系模式$R\in BCNF$，必定有$R\in 3NF$

• 如果$R\in 3NF$，且R只有一个候选码，则R必属于BCNF

  $3NF\to BCNF$：消除了主属性对码的部分和传递函数依赖

6.2.7 多值依赖

设R(U)是属性集U上的一个关系模式。X,Y,Z是U的子集，并且$Z=U-X-Y$。关系模式$R(U)$中多值依赖$X\to \to Y$成立，当且仅当对$R(U)$的任一关系r，给定的一对(x,z)值，有一组Y的值与之对应，这组值仅仅决定于x值而与z值无关

$X\to \to Y$：$Y$多值依赖于$X$

平凡多值依赖和非平凡的多值依赖

• $若X\to \to Y$，而$Z＝Ф$，即$Z$为空，则称$X\to \to Y$为平凡的多值依赖$

• 否则称$X\to \to Y$为非平凡的多值依赖

性质

• 多值依赖具有对称性

• 多值依赖具有传递性

• 函数依赖是多值依赖的特殊情况

6.2.8 4NF

• 关系模式$R\in 1NF$，如果对于R的每个非平凡多值依赖$X\to \to Y（Y⊈X）$，$X$都含有码，则$R\in 4NF$

  （一个表的主键只对应一个多值，要求把同一表内的多对多关系删除）

6.3 数据依赖的公理系统

1. 逻辑蕴含

• 对于满足一组函数依赖F的关系模式R，其任何一个关系r，若函数依赖$X\to Y$都成立（即r中任意两元组t、s，若$t[X]=s[X]$，则$t[Y]=s[Y]$），则称F逻辑蕴涵$X\to Y$

2. Armstrong公理系统

• 用途：

  • 求给定关系模式的码
  • 从一组函数依赖求得蕴涵的函数依赖

• Armstrong公理系统 设U为属性集总体，F是U上的一组函数依赖， 于是有关系模式R 。对R
  来说有以下的推理规则：

  • A1 自反律：若$Y\subseteq X\subseteq U$，则$X →Y $为F所蕴涵
  • A2 增广律：若$X\to Y$为F所蕴涵，且$Z\subseteq U$，则$XZ\to YZ$为F所蕴涵
  • A3 传递律：若$X\to Y$及$Y\to Z$为F所蕴涵，则$X\to Z$为F所蕴涵

• 自反律所得到的函数依赖均是平凡的函数依赖

• 自反律的使用并不依赖于F

（1）推理规则

• 合并规则：$（A2，A3）由X\to Y，X\to Z，有X\to YZ$

• 伪传递规则：$（A2，A3）由X\to Y，WY\to Z，有XW\to Z$

• 分解规则：$（A1，A3）由X\to Y及Z\subseteq Y，有X\to Z$

（2）闭包

• 在关系模式R中为F所逻辑蕴涵的函数依赖的全体叫作F的闭包，记为$F^{+}$

• 设F为属性集U上的一组函数依赖，$X、Y\subseteq U$， $X_F^{+}=\{A|X\to A能由F根据Armstrong公理导出\}$，$X_F^{+}$称为属性集X关于函数依赖集F的闭包

• 设F为属性集U上的一组函数依赖，$X、Y\subseteq U$，$X\to Y$能由F根据Armstrong公理导出的充分必要条件是$Y\subseteq X_F^{+}$

• 用途：判定$X\to Y$是否能由F根据Armstrong公理导出的问题，就转化为求出$X_F^{+}$，判定Y是否为$X_F^{+}$的子集的问题

求闭包算法

闭包就是由一个属性直接或间接推导出的所有属性的集合

• 第一步：设最终将成为闭包的属性集是Y，把Y初始化为X；

• 第二步：检查F中的每一个函数依赖A→B，如果属性集A中所有属性均在Y中，而B中有的属性不在Y中，则将其加入到Y中；

• 第三步：重复第二步，直到没有属性可以添加到属性集Y中为止。 最后得到的Y就是X＋

例子

已知关系模式R，$其中U=\{A,B,C,D,E\}；F=\{AB\to C,B\to D,C\to E,EC\to B,AC\to B\}。求(AB)F^{+}$

• $X(0)=AB$

• $X(1)=X(0)\cup CD(\because AB\to C,B\to D)=ABCD$

• $X(2)=X(1)\cup EB(\because C\to E，AC\to B)=ABCDE$

• $\because X(2)已等于全部属性集合，\therefore (AB)F+=ABCDE$

（3）候选码的求解方法

对于给定的关系模式$R(A_1,A_2,\dots ,A_n)$和函数依赖集F

• R的属性分为四类:

  • L类：仅出现在函数依赖左部的属性
  • R类：仅出现在函数依赖右部的属性
  • N类：在函数依赖的左部和右部均不出现的属性
  • LR类：在函数依赖的左部和右部均出现的属性。

• 过程：

  • 找出L、R、N、LR类属性

  • 若存在L类属性，查看该属性的闭包是否包括全部属性

    • 若有，则是关系模式中唯一的候选码；

    • 若无，则L类的属性必然在任一候选码中

  • 查看LR类属性，他们必有部分或者全部在某个候选码中。依次与L类属性结合，求闭包

对R中的属性X的结论

• 若X是L类属性，则X一定包含在关系模式R的任何一个候选码中；若$X^{+}$包含了R的全部属性，则X为关系模式R的唯一候选码

• 若X是R类属性，则X不包含在关系模式R的任何一个候选码中

• 若X是N类属性，则X一定包含在关系模式R的任何一个候选码中。若L类N类属性组闭包包含了R的全部属性，则L类N类属性组为关系模式R的唯一候选码(L、N的闭包组合为U，则是唯一的候选码)

• 若X是LR类属性，则X可能包含在关系模式R的某个候选码中

例子

$R（U，F），U=\{A，B，C，D，E，G\}，F=\{A\to D，E\to D，D\to B，BC\to D，DC\to A\}$，求R的所有候选码

• C、E是L类属性，因此C、E必定在R的任何一个候选码中。

• G是N类属性，故G也必定在R的任何一个候选码中。

• 又由于$(CEG)+=ABCDEG=R$的全部属性，因此，CEG是R的唯一候选码

Armstrong公理系统是有效的、完备的

如果函数依赖集F满足下列条件，则称F为一个极小函数依赖集，亦称为最小依赖集或最小覆盖。

• F中任一函数依赖的右部仅含有一个属性。

• F中不存在这样的函数依赖$X\to A$，使得$F与F-\{X\to A\}$等价。

• F中不存在这样的函数依赖$X\to A$，X有真子集Z使得$F-\{X\to A\}\cup \{Z\to A\}$与F等价

第七章 数据库设计

7.1 数据库设计概述

设计的基本步骤

• 需求分析

  需求分析是整个设计过程的基础 - 概念结构设计

  通过对用户需求进行综合、归纳与抽象，形成一个独立于具体数据库管理系统的概念模型(E-R图)

• 逻辑结构设计

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

• 物理结构设计

  为逻辑数据结构选取一个最适合应用环境的物理结构

• 数据库实施

  根据逻辑设计和物理设计的结果构建数据库，编写与调试应用程序，组织数据入库并进行试运行

• 数据库运行和维护

  经过试运行后即可投入正式运行，在运行过程中必须不断对其进行评估、调整与修改

7.2 需求分析

7.2.1 需求分析的任务

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

  • 详细调查现实世界要处理的对象（组织、部门、企业等）
  • 充分了解原系统（手工系统或计算机系统）工作概况
  • 明确用户的各种需求
  • 在此基础上确定新系统的功能

• 调查的重点是“数据”和“处理”，获得用户对数据库的要求

  • 信息要求
  • 处理要求
  • 安全性与完整性要求

7.2.2 需求分析的方法

1. 调查用户需求的步骤

• 调查组织机构情况

• 调查各部门的业务活动情况

• 协助用户明确对新系统的各种要求，包括信息要求、处理要求、完全性与完整性要求

• 确定新系统的边界

2. 常用调查方法

• 跟班作业

• 开调查会

• 请专人介绍

• 询问

• 设计调查表请用户填写

• 查阅记录

7.2.3 数据字典

• 数据字典的内容

  • 数据项
  • 数据结构
  • 数据流
  • 数据存储
  • 处理过程

• 数据项是数据的最小组成单位

• 若干个数据项可以组成一个数据结构

• 数据字典通过对数据项和数据结构的定义来描述数据流、数据存储的逻辑内容

7.3 概念结构设计

将需求分析得到的用户需求抽象为信息结构（即概念模型）的过程就是概念结构设计

7.3.2 E-R模型

1. 实体之间的联系

• 两个实体型之间的联系：

  • 一对一联系（1∶1）
  • 一对多联系（1∶n）
  • 多对多联系（m∶n）

• 两个以上的实体型之间的联系

• 单个实体型内的联系

• 联系的度：参与联系的实体型的数目

  • 2个实体型之间的联系度为2，也称为二元联系；
  • 3个实体型之间的联系度为3，称为三元联系；
  • N个实体型之间的联系度为N，也称为N元联系

2. E-R图

• 实体型：用矩形表示，矩形框内写明实体名

• 属性：用椭圆形表示，并用无向边将其与相应的实体型连接起来

• 联系：用菱形表示，菱形框内写明联系名，并用无向边分别与有关实体型连接起来，同时在无向边旁标上联系的类型（1∶1，1∶n或m∶n）

7.3.5 概念结构设计

1. 实体与属性的划分原则

原则

为了简化E-R图的处置，现实世界的事物能作为属性对待的，尽量作为属性对待

两条准则

• 作为属性，不能再具有需要描述的性质。属性必须是不可分的数据项，不能包含其他属性。

• 属性不能与其他实体具有直接联系，即E-R图中所表示的联系是实体之间的联系

2. E-R图的集成

自顶向下进行需求分析，自底向上地设计概念模型

两步

• 合并。解决各部分E-R图之间的冲突，将分E-R图合并起来生成初步E-R图
• 冲突：属性冲突、命名冲突、结构冲突
• 修改和重构。消除不必要的冗余，生成基本E-R图
  • 冗余的数据是指可由基本数据导出的数据
  • 冗余的联系是指可由其他联系导出的联系

ER图画法

• 确定所有的实体集合；

• 选择实体集应包含的属性；

• 确定实体集之间的联系；

• 确定实体集的关键字，用下划线在属性上表明关键字的属性组合；

• 确定联系的类型，在用线将表示联系的菱形框联系到实体集时，在线旁注明是1或n(多）来表示联系的类型

7.4 逻辑结构设计

把基本E-R图转为逻辑结构

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

1. 转换内容

• E-R图由实体型、实体的属性和实体型之间的联系三个要素组成

• 关系模型的逻辑结构是一组关系模式的集合

• 将E-R图转换为关系模型：将实体型、实体的属性和实体型之间的联系转化为关系模式

2. 转换原则

（1）一个实体型转换为一个关系模式

• 关系的属性：实体的属性

• 关系的码：实体的码

（2）实体型间的联系有以下不同情况

• 一个1:1联系：可以转换为一个独立的关系模式，也可以与任意一端对应的关系模式合并

  • ① 转换为一个独立的关系模式
    • 关系的属性：与该联系相连的各实体的码以及联系本身的属性
    • 关系的候选码：每个实体的码均是该关系的候选码
  • ②与某一端实体对应的关系模式合并
    • 合并后关系的属性：加入对应关系的码和联系本身的属性
    • 合并后关系的码：不变

• 一个1:n联系：可以转换为一个独立的关系模式，也可以与n端对应的关系模式合并

  • ①转换为一个独立的关系模式
    • 关系的属性：与该联系相连的各实体的码以及联系本身的属性
    • 关系的码：n端实体的码
  • ②与n端对应的关系模式合并
    • 合并后关系的属性：在n端关系中加入1端关系的码和联系本身的属性
    • 合并后关系的码：不变

• 一个m:n联系转换为一个关系模式

  • 关系的属性：与该联系相连的各实体的码以及联系本身的属性
  • 关系的码：各实体码的组合

• 三个或三个以上实体间的一个多元联系转换为一个关系模式

  • 关系的属性：与该多元联系相连的各实体的码以及联系本身的属性
  • 关系的码：各实体码的组合

• 具有相同码的关系模式可合并

  • 目的：减少系统中的关系个数
  • 合并方法：
    • ①将其中一个关系模式的全部属性加入到另一个关系模式中
    • ②然后去掉其中的同义属性（可能同名也可能不同名）
    • ③适当调整属性的次序

7.4.2 数据模型的优化

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

优化数据模型的方法

• 确定数据依赖

• 对于各个关系模式之间的数据依赖进行极小化处理，消除冗余的联系

• 按照数据依赖的理论对关系模式进行分析，考察是否存在部分函数依赖、传递函数依赖、多值依赖等，确定各关系模式分别属于第几范式

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

• 对关系模式进行必要分解，提高数据操作效率和存储空间的利用率

  • 常用分解方法：

    • 水平分解

      把(基本)关系的元组分为若干子集合，定义每个子集合为一个子关系

    • 垂直分解

      把关系模式R的属性分解为若干子集合，形成若干子关系模式

7.4.3设计用户子模式

定义用户外模式时应该更注重考虑用户的习惯与方便。包括三个方面：

• 使用更符合用户习惯的别名

• 针对不同级别的用户定义不同的视图，以保证系统的安全性

• 简化用户对系统的使用

7.5 物理结构设计

为逻辑模型选定最适合应用要求的物理模型的过程

数据库物理设计的步骤

• 确定数据库的物理结构

  在关系数据库中主要指存取方法和存储结构

• 对物理结构进行评价

  评价的重点是时间和空间效率

关系模式存取方法选择

常用存取方法

• B+树索引存取方法

• Hash索引存取方法

• 聚簇存取方法

7.6 数据库的实施和维护

7.6.3 数据库的运行和维护

• 数据库的转储和恢复

• 数据库的安全性、完整性控制

• 数据库性能的监督、分析和改进

• 数据库的重组织与重构造

7.7 小结

数据库各级模式的形成

• 需求分析阶段：综合各个用户的应用需求（现实世界的需求）。

• 概念设计阶段：概念模式（信息世界模型），用E-R图来描述。

• 逻辑设计阶段：逻辑模式、外模式。

• 物理设计阶段：内模式

另外：

• 在逻辑设计阶段将E-R图转换成具体的数据库产品支持的数据模型如关系模型，形成数据库逻辑模式。

• 然后根据用户处理的要求，安全性的考虑，在基本表的基础上再建立必要的视图，形成数据的外模式

• 在物理设计阶段根据DBMS特点和处理的需要，进行物理存储安排，设计索引，形成数据库内模式