Database Management Review (2)

8 SQL概述

8.1 什么是SQL

SQL（Structured Query Language）结构化查询语言，是关系数据库的标准语言
SQL是一个通用的、功能极强的关系数据库语言
- 综合统一
- 高度非过程化
- 面向集合的操作方式
- 以同一种语法结构提供两种使用方法
- 语言简洁，易学易用

注意，SQL只是一种规范性的语言，但是在不同的数据库管理系统中，语法可能会有所不同，比如在MySQL中的语法和在Oracle中的语法可能就有所不同。

8.2 SQL的特点

8.2.1 综合统一

集数据定义语言（DDL），数据操纵语言（DML），数据控制语言（DCL）功能于一体。
可以独立完成数据库生命周期中的全部活动：
- 定义和修改、删除关系模式，定义和删除视图，插入数据，建立数据库;
- 对数据库中的数据进行查询和更新;
- 数据库重构和维护
- 数据库安全性、完整性控制，以及事务控制
- 嵌入式SQL和动态SQL定义
用户数据库投入运行后，可根据需要随时逐步修改模式，不影响数据库的运行。
数据操作符统一

8.2.2 高度非过程化

非关系数据模型的数据操纵语言“面向过程”，必须指定存取路径。
SQL只要提出“做什么”，无须了解存取路径。
存取路径的选择以及SQL的操作过程由系统自动完成。

8.2.3 面向集合的操作方式

非关系数据模型采用面向记录的操作方式，操作对象是一条记录
SQL采用集合操作方式（无序，取出的顺序由DBMS决定）
- 操作对象、查找结果可以是元组的集合
- 一次插入、删除、更新操作的对象可以是元组的集合

8.2.4 以同一种语法结构提供多种适用方式

SQL是独立的语言，能够独立地用于联机交互的使用方式
SQL又是嵌入式语言，能够嵌入到高级语言（例如C，C++，Java）程序中，供程序员设计程序时使用

8.2.5 语言简洁，易学易用

SQL功能极强，完成核心功能只用了9个动词:
- 数据定义：CREATE，DROP，ALTER
- 数据查询：SELECT
- 数据操作：INSERT，UPDATE，DELETE
- 数据控制：GRANT，REVOKE

8.3 SQL与关系数据库三级模式

8.3.1 基本表

本身独立存在的表
一个关系对应一个基本表
一个（或多个）基本表对应一个存储文件
一个表可以带若干索引

8.3.2 存储文件

逻辑结构组成了关系数据库的内模式
物理结构对用户是隐蔽的

8.3.3 视图

从一个或几个基本表中导出的表
数据库中只存放视图的定义而不存放试图对应的数据
视图是一个虚表
用户可以在视图上再定义视图

9 SQL数据定义

层次化的数据库对象命名机制

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

在MySQL中，一个数据库只对应一个模式，即"database"和“schema”两个词是同义的
一个模式下通常包括多个表、视图和索引等数据库对象。

接下来是SQL基本的增删改查语句用法，这里省略

10 SQL 中的空值

空值一般有以下几种情况：

该属性应该有一个值，但目前还不知道它的具体值

该属性不该有值

由于某种原因不便于填写

对于空值的判断用 IS NULL 或 IS NOT NULL 来判断

例：从Student表中找出漏填了数据的学生信息

SELECT *
FROM `Student`
WHERE `Sname` IS NULL OR `Ssex` IS NULL OR `Sage` IS NULL OR `Sdept` IS NULL;

属性定义（或者域定义）中：
- 有 NOT NULL 约束条件的不能取空值
- 加了 UNIQUE 限制的属性不能取空值
- 码属性不能取空值

10.1 空值的运算

空值与另一个值（包括另一个空值）的算术运算的结果为空值
空值与另一个值（包括另一个空值）的比较运算结果为UNKNOWN。
传统二值（TRUE、FALSE）因为 UNKNOWN 的扩展成了三值逻辑。

x	y	x AND y	x OR y	NOT X
T	T	T	T	T
T	U	U	T	F
T	F	F	T	F
U	T	U	T	U
U	U	U	U	U
U	F	F	U	U
F	T	F	T	T
F	U	F	U	T
F	F	F	F	F

11 视图

视图的特点：

虚表，是从一个或几个基本表（或视图）导出的表
只存放视图的定义，不存放视图对应的数据
基表中的数据发生变化，从视图中查询出的数据也随之改变。

11.1 建立视图

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

WITH CHECK OPTION：对树突进行 UPDATE 、INSERT、DELETE 操作时要保证更新、插入或删除的行满足视图定义中的谓词条件（即子查询中的条件表达式）。
子查询可以是任意的 SELECT 语句，是否可以含有 ORDER BY 子句和 DISTINCT 短语，则决定于具体系统的实现。
组成视图的属性列明：全部省略或全部指定
1. 全部省略：由子查询中 SELECT 目标列中的诸字段组成
2. 明确指定视图的所有列名：
  1. 某个目标列是聚集函数或列表达式
  2. 多表连接时选出了几个同名列作为视图的字段
  3. 需要在视图中为某个列启用新的更合适的名字
关系数据库管理系统执行 CREATE VIEW 语句时只是把视图定义存入数据字典，并不执行其中的 SELECT 语句。
在对视图查询时，按视图的定义从基本表中将数据查出。

例：建立信息系学生的视图。

CREATE VIEW IS_Student
AS  SELEECT Sno, Sname, Sage
	FROM Student
	WHERE Sdept = 'IS';

若一个视图是从单个基本表导出的，并且只是去掉了基本表的某些行和某些列，但保留了主码，我们称这类视图为行列子集视图。

注意点：

可以在视图之上建立视图
可以基于多个基表建立视图

可以建立分组视图

将学生的学号及平均成绩定义为一个视图

CREATE VIEW student_grade(Sno, Gavg)
AS  SELECT Sno, AVG(Grade)
	FROM SC
	GROUP BY Sno;

11.2 删除视图

DROP VIEW <视图名> [CASCADE]

该语句从数据字典中删除指定的视图定义
如果该视图上还导出了其他视图，使用CASCADE级联删除语句，把该视图和由它导出的所有视图一起删除
删除基表时，由该基表导出的所有视图定义都必须显式地使用DROP VIEW语句删除

11.3 查询视图

用户角度：查询视图与查询基本表相同
关系数据库管理系统实现视图查询的方法
- 视图消解法（View Resolution）
- 进行有效性检查
- 转换成等价的对基本表的查询
- 执行修正后的查询

视图消解法并不一定能够生成正确的查询，在使用了聚集函数的情况下，比如AVG()，就并不一定能够正确的生成出查询对应基表的 SELECT 表达式。

11.4 更新视图

允许对行列子集视图进行更新
对其他类型视图的更新不同系统有不同限制
更新视图的限制：一些视图是不可更新的，因为对这些视图的更新不能唯一地有意义地转换成对相应基本表的更新

比如更新一列通过 AVG() 获得的视图的列，是没办法对原表进行更新操作的
一个不允许更新的视图上定义的视图也不允许更新

11.5 视图的作用

当视图中数据不是直接来自基本表时，定义视图能够简化用户的操作
- 基于多张表连接形成的视图
- 基于复杂嵌套查询的视图
- 含导出属性的视图
视图机制能使不同用户以不同方式看待同一数据，
适应数据库共享的需要

12 数据库安全性

数据库的不安全因素：

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

安全级别	定义
A1	验证设计（Verified Design）
B3	安全域（Security Domains）
B2	结构化保护（Structural Protection）
B1	标记安全保护（Labeled Security Protection）
C2	受控的存取保护（Controlled Access Protection）
C1	自主安全保护（Discretionary Security Protection）
D	最小保护（Minimal Protection）

D级：将一切不符合更高标准的系统均归于D组
C1级：
1. 非常初级的自主安全保护
2. 能够实现对用户和数据的分离，进行自主存取控制（DAC），保护或限制用户权限的传播。
3. 现有的商业系统稍作改进即可满足
C2级：
1. 安全产品的最低档次
2. 提供受控的存取保护，将C1级的DAC进一步细化，以个人身份注册负责，并实施审计和资源隔离
3. 达到C2级的产品在其名称中往往不突出“安全”（Security）这一特色
B1级：
1. 标记安全保护。“安全”（Security）或“可信的”（Trusted）产品。
2. 对系统的数据加以标记，对标记的主体和客体实施强制存取控制（MAC）、审计等安全机制
B2级：
1. 结构化保护
2. 建立形式化的安全策略模型并对系统内的所有主体和客体实施DAC和MAC
B3级：
1. 安全域
2. 该级的TCB必须满足访问监控器的要求，审计跟踪能力更强，并提供系统恢复过程
A1级：验证设计，即提供B3级保护的同时给出系统的形式化设计说明和验证以确信各安全保护真正实现。

12.1 存取控制

存取控制机制组成
- 定义用户权限，并将用户权限登记到数据字典中
  - 用户对某一数据对象的操作权力称为权限
  - DBMS提供适当的语言来定义用户权限，存放在数据字典中，称做安全规则或授权规则
- 合法权限检查
  - 用户发出存取数据库操作请求
  - DBMS查找数据字典，进行合法权限检查
用户权限定义和合法权检查机制一起组成了数据库管理系统的存取控制子系统

自主存取控制（Discretionary Access Control, DAC）

C2级
用户对不同的数据对象有不同的存取权限
不同的用户对同一对象也有不同的权限
用户还可将其拥有的存取权限转授给其他用户

强制存取控制（Mandatory Access Control, MAC）

B1级
每一个数据对象被标以一定的密级
每一个用户也被授予某一个级别的许可证
对于任意一个对象，只有具有合法许可证的用户才可以存取

12.1.1 自主存取控制方法

通过 SQL 的 GRANT 语句和 REVOKE 语句实现

用户权限组成：
- 数据对象
- 操作类型
定义用户存取权限：定义用户可以在哪些数据库对象上进行哪些类型的操作
定义存取权限称为授权

SQL中的授权机制

数据库管理员：
- 拥有所有对象的所有权限
- 根据实际情况不同的权限授予不同的用户
用户：
- 拥有自己建立的对象的全部的操作权限
- 可以使用GRANT，把权限授予其他用户
被授权的用户
- 如果具有“继续授权”的许可，可以把获得的权限再授予其他用户
- 所有授予出去的权力在必要时又都可用REVOKE语句收回

12.1.2 GRANT

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

这里的对象类型在SQL中指：视图、表、属性列（必须指定列名）等

权限：ALL PRIVILIGES 代表所有权限，其他还包括 SELECT 等

用户：PUBLIC 表示给所有用户，其他指定用户名

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

WITH GRANT OPTION子句：

指定：该用户可以再授予别人权限
没有指定：不能传播

不允许循环授权

12.1.3 REVOKE

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

CASCADE：级联回收，即回收一个用户的权限时，该用户授权的所有用户的该权限都会被回收。

例：U5 给予了 U6 SELECT 的权限，在回收 U5 的 SELECT 权限的时候，U6 的 SELECT 权限也会被回收。（但如果 U6 从别的用户那里也得到过 SELECT 权限，则 U6 仍然具有该权限）

RESTRICT：与上述相反，非级联的回收

12.1.4 创建数据库模式的权限

CREATE USER <username> 
[WITH] [DBA | RESOURCE | CONNECT]

注：CREATE USER不是 SQL 标准，各个系统的实现相差甚远。

CONNECT：如没有指定创建的新用户的权限，默认该用户拥有CONNECT权限。拥有CONNECT权限的用户不能创建新用户，不能创建模式，也不能创建基本表，只能登录数据库
RESOURCE：拥有RESOURCE权限的用户能创建基本表和视图，成为所创建对象的属主。但不能创建模式，不能创建新的用户
DBA：拥有DBA权限的用户是系统中的超级用户，可以创建新的用户、创建模式、创建基本表和视图等；DBA拥有对所有数据库对象的存取权限，还可以把这些权限授予一般用户

12.1.5 强制存取控制

保证更高程度的安全性
用户不能直接感知或进行控制
适用于对数据有严格而固定密级分类的部门

在强制存取控制中，数据库管理系统所管理的全部实体被分为主体和客体两大类。

主体是系统中的活动实体
- 数据库管理系统所管理的实际用户
- 代表用户的各进程
客体是系统中的被动实体，受主体操纵
- 文件、基本表、索引、视图

强制存取控制规则：

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

强制存取控制（MAC）是对数据本身进行密级标记，无论数据如何复制，标记与数据是一个不可分的整体，只有符合密级标记要求的用户才可以操纵数据。

13 数据库完整性

数据库的正确性：是指数据时符合现实世界语义，反映了当前实际状况的。
数据的相容性：是指数据库同一对象在不同关系表中的数据时符合逻辑的。

13.1 完整性 vs 安全性

数据的完整性和安全性是两个不同概念

数据的完整性：
- 防止数据库中存在不符合语义的数据，也就是防止数据库中存在不正确的数据
- 防范对象：不合语义的、不正确的数据
数据的安全性
- 保护数据库，防止恶意的破坏和非法的存取
- 防范对象：非法用户和非法操作

13.2 完整性机制

提供定义完整性约束条件的机制
- 完整性约束条件也称为完整性规则，是数据库中的数据必须满足的语义约束条件
- SQL标准使用了一系列概念来描述完整性，包括关系模型的实体完整性、参照完整性和用户定义完整性
- 这些完整性一般由SQL的数据定义语言语句来实现
提供完整性检查的方法
- 数据库管理系统中检查数据是否满足完整性约束条件的机制称为完整性检查。
- 一般在INSERT、UPDATE、DELETE语句执行后开始检查，也可以在事务提交时检查
违约处理
- 数据库管理系统若发现用户的操作违背了完整性约束条件，就采取一定的动作
  - 拒绝（NO ACTION）执行该操作
  - 级连（CASCADE）执行其他操作

当然，也可以在应用程序的层面来实现完整性的约束，比如用Java来实现完整性的约束和检查。

13.3 实体完整性

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

例：

单属性我们可以用以下两种方式来定义其为主码

CREATE TABLE `user`
(
    `user_id`	BIGINT NOT NULL AUTO_INCREAMENT PRIMARY KEY
) ENGINE = InnoDB CHARSET = utf8;

CREATE TABLE `user`
(
    `user_id`	BIGINT NOT NULL AUTO_INCREAMENT,
    CONSTRAINT PRIMARY KEY (`user_id`)
) ENGINE = InnoDB CHARSET = utf8;

对于多属性，只能用下面这种方法来定义主码。

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

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

检查主码值是否唯一，如果不唯一则拒绝插入或修改
检查主码的各个属性是否为空，只要有一个为空就拒绝插入或修改

如何实现这种检查是否唯一的方法，如果进行全表扫描，在数据十分多的情况下是十分耗时的，因此，DBMS一般都会在主码上建立索引，比如用B+树索引来减少DBMS检查主码是否唯一时间。

13.4 参照完整性

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

例：

CREATE TABLE `user`
(
    `user_id` BIGINT NOT NULL AUTO_INCREAMENT,
    `user_no` BIGINT NOT NULL,
    CONSTRAINT PRIMARY KEY (`user_id`),
    CONSTRAINT FOREIGN KEY (`user_no`) REFERENCES `Course`(`user_no`)
)

一个参照完整性将两个表中的相应元组联系起来
对被参照表和参照表进行增删改操作时有可能破坏参照完整性，必须进行检查

参照完整性违约处理

拒绝（NO ACTION）执行：不允许该操作执行。该策略一般设置为默认策略
级联（CASCADE）操作：当删除或修改被参照表的一个元组造成了与参照表的不一致，则删除或修改参照表中的所有造成不一致的元组
设置为空值（SET-NULL）
- 当删除或修改被参照表的一个元组时造成了不一致，则将参照表中的所有造成不一致的元组的对应属性设置为空值。
- 对于参照完整性，除了应该定义外码，还应定义外码列是否允许空值

参照完整性一般会在程序层面来进行定义，而不会给数据库中直接添加外键，因为外键的删除和插入都涉及到太过复杂的关系。

13.5 用户定义的完整性

用户定义的完整性是：针对某一具体应用的数据必须满足的语
义要求
- 属性上的约束条件
- 元组上的约束条件
  - 同属性值限制相比，元组级的限制可以设置不同属性之间的取值的相互约束条件
关系数据库管理系统提供了定义和检验用户定义完整性的机制，不必由应用程序承担
- 插入元组或修改属性的值时，关系数据库管理系统检查约束条件是否被满足
- 如果不满足则操作被拒绝执行

CHECK()语句可以自定义完整性。

完整性约束命名子句

创建完整性约束
- 完整性约束命名子句
  - CONSTRAINT <完整性约束条件名><完整性约束条件>
  - <完整性约束条件>包括NOT NULL、UNIQUE、PRIMARY KEY短语、FOREIGN KEY短语、CHECK短语等
修改完整性约束
- 使用ALTER TABLE语句修改表中的完整性限制

14 断言

创建断言的语句格式：
CREATE ASSERTION <断言名> <CHECK 子句>
- 每个断言都被赋予一个名字， <CHECK 子句> 中的约束条件与 WHERE 子句的表达式类似
删除断言的语句格式为
DROP ASSERTION <断言名>;

15 触发器

触发器（Trigger）是用户定义在关系表上的一类由事件驱动的特殊过程
- 触发器保存在数据库服务器中
- 任何用户对表的增、删、改操作均由服务器自动激活相应的触发器
- 触发器可以实施更为复杂的检查和操作，具有更精
  细和更强大的数据控制能力
不同的RDBMS产品触发器语法各不相同

15.1 定义触发器

CREATE TRIGGER <触发器名>
[BEFORE | AFTER] <触发事件> ON <表名>
REFERENCING NEW | OLD ROW AS <变量>
FOR EACH [ROW | STATEMENT]
[WHEN <触发条件>] <触发动作体>

触发器又叫做事件-条件-动作（event-condition-action）规则。
- 当特定的系统事件发生时，对规则的条件进行检查，如果条件成立则执行规则中的动作，否则不执行该动作。规则中的动作体可以很复杂，通常是一段SQL存储过程。

15.2 删除触发器

DROP TRIGGER <触发器名> ON <表名>

触发器必须是一个已经创建的触发器，并且只能由具有相应权限的用户删除。

16 关系模式及范式

关系模式由五部分组成，是一个五元组：

$R(U, D, DOM,F)$

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

由于 $D$ 、 $DOM$ 与模式设计关系不大，因此可以把关系模式看作一个三元组： $R<U, F>$

当且仅当 $U$ 上的一个关系 $r$ 满足 $F$ 时， $r$ 称为关系模式 $R<U, F>$ 的一个关系

作为二维表，关系要符合一个最基本的条件：每个分量必须是不可分开地数据项。满足了这个条件的关系模式就属于第一范式（1NF）

范式的种类：

第一范式（1NF）
第二范式（2NF）
第三范式（3NF）
BC范式（BCNF）
第四范式（4NF）
第五范式（5NF）

16.1 数据依赖

是一个关系内部属性与属性之间的一种约束关系：通过属性间值的相等与否体现出来的数据间相关联系
是现实世界属性间相互联系的抽象
是数据内在的性质
是语义的体现

数据依赖的主要类型：

函数依赖（Functional Dependency, FD）
多值依赖（Multi-Valued Dependency, MVD）

16.2 1NF

每个分量必须是不可分开地数据项。满足了这个条件的关系模式就属于第一范式（1NF）

第一范式的问题：

数据冗余：浪费大量的存储空间。

每一个系主任的姓名重复出现，重复次数与该系所有学生的所有课程成绩出现次数相同。
更新异常（Update Anomalies）：数据冗余，更新数据时，维护数据完整性代价大。

某系更换系主任后，必须修改与该系学生有关的每一个元组。
插入异常（Insertion Anomalies）

如果一个系刚成立，尚无学生，则无法把这个系及其系主任的信息存入数据库。
删除异常（Deletion Anomalies）

如果某个系的学生全部毕业了，则在删除该系学生信息的同时，把这个系及其系主任的信息也丢掉了。

16.3 函数依赖与码

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

函数依赖不是指关系模式 $R$ 的某个或某些关系实例满足的约束条件，而是指 $R$ 的所有关系实例均要满足的约束条件。
函数依赖是语义范畴的概念。只能根据数据的语义来确定函数依赖。
- 例如“姓名→年龄”这个函数依赖只有在不允许有同名人的条件下成立
数据库设计者可以对现实世界作强制的规定。例如规定不允许同名人出现，函数依赖“姓名→年龄”成立。所插入的元组必须满足规定的函数依赖，若发现有同名人存在，则拒绝装入该元组。

16.3.1 平凡函数依赖于非平凡函数依赖

在关系模式 $R(U)$ 中，对于 $U$ 的子集 $X$ 和 $Y$ ，

如果 $X \rightarrow Y$ ，但 $Y \notin X$ ，则称 $X \rightarrow Y$ 是非平凡的函数依赖
若 $X \rightarrow Y$ ，但 $Y \in X$ , 则称 $X \rightarrow Y$ 是平凡的函数依赖

例：在关系SC(Sno, Cno, Grade)中

非平凡函数依赖：(Sno, Cno) -> Grade
平凡函数依赖：
1. (Sno, Cno) -> Sno
2. (Sno, Cno) -> Cno

对于任一的关系模式，平凡函数依赖都是必然成立的，它不反应新的语义，因此若不特别声明，我们总是讨论非平凡函数依赖。

16.3.2 完全函数依赖与部分函数依赖

16.3.3 传递函数依赖

16.4 2NF

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

一个关系如果不属于2NF，那么会出现以下的问题：

插入异常
删除异常
修改复杂

16.5 3NF

定义：设关系模式 $R<U, F> \in 1NF$ ，若 $R$ 中不存在这样的码 $X$ 、属性组 $Y$ 及非主属性 $Z (Y \notin Z)$ ，使得 $X \rightarrow Y$ ， $Y \rightarrow Z$ 成立， $Y \not \rightarrow X$ 不成立，则称 $R<U, F> \in 3NF$ 。

16.6 BCNF

定义：设关系模式 $R<U,F> \in 1NF$ ，若 $X \rightarrow Y$ 且 $Y \notin X$ 时 $X$ 必含有码，则 $R<U,F> \in BCNF$ 。

BCNF的关系模式所具有的性质

所有非主属性都完全函数依赖于每个候选码
所有主属性都完全函数依赖于每个不包含它的候选码
没有任何属性完全函数依赖于非码的任何一组属性

16.7 多值依赖与4NF

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

平凡多值依赖：若 $X \rightarrow \rightarrow Y$ ，而 $Z = \Phi$ ，即 $Z$ 为空，则称 $X \rightarrow \rightarrow Y$ 为平凡的多值依赖
否则成 $X \rightarrow \rightarrow Y$ 为非平凡的多值依赖

多值依赖的性质

多值依赖具有对称性：即若 $X \rightarrow \rightarrow Y$ $X \to \to Y$ ，则 $X \rightarrow \rightarrow Z$ $X \to \to Z$ ，其中 $Z = U - X - Y$ $Z = U - X - Y$ 。
- 多值依赖的对称性可以用完全二分图直观地表示出来
多值依赖具有传递性：即若 $X \rightarrow \rightarrow Y$ , $Y \rightarrow \rightarrow Z$ , 则 $X \rightarrow \rightarrow Z - Y$
函数依赖是多值依赖的特殊情况：即若 $X \rightarrow Y$ ，则 $X \rightarrow \rightarrow Y$

4NF的定义：关系模式 $R<U,F> \in 1NF$ ，如果对于 $R$ 的每个非平凡多值依赖 $X \rightarrow \rightarrow Y（Y \notin X）$ ， $X$ 都含有码，则 $R<U,F> \in 4NF$ 。

4NF就是限制关系模式的属性之间不允许有非平凡且非函数依赖的多值依赖。4NF所允许的非平凡多值依赖实际上是函数依赖。
如果一个关系模式是4NF，则必为BCNF。

Reference

数据库系统概论（第五版）
数据库系统概念
南京大学软件学院2022春季学期数据管理基础课程