关系数据库 on zcys univ II Hugo ver

Chapter7 分解算法(大概是7.4-7.5)

Tue, 11 Nov 2025 00:00:00 +0800

Functional-Dependency Theory

SQL for judging FDs

Closure of a Set of Functional Dependencies

The set of all functional dependencies logically implied by F is the closure of F, which is denoted as F+. It is the set of all functional dependencies that can be inferred from F using Armstrong’s axioms.

Armstrong’s Axioms

Armstrong’s axioms are a set of rules used to infer all the functional dependencies in a relational database. They are sound (i.e., they only produce valid dependencies) and complete (i.e., they can produce all valid dependencies).

Reflexivity: If Y is a subset of X, then X → Y holds.
Augmentation: If X → Y holds, then XZ → YZ holds for any Z.
Transitivity: If X → Y and Y → Z hold, then X → Z holds.

Additional Rules

Union: If X → Y and X → Z hold, then X → YZ holds.
Decomposition: If X → YZ holds, then X → Y and X → Z hold.
Pseudotransitivity: If X → Y and YZ → W hold, then XZ → W holds. （可由先argumentation和transitivity推导出）

属性集闭包

属性集X在函数依赖集F下的闭包，记为X+，是指在F中可以由X推导出的所有属性的集合。计算X+的算法：

初始化X+为X。
重复以下步骤，直到X+不再变化：
- 对于F中的每个函数依赖A → B，如果A是X+的子集，则将B添加到X+中。

例子

设有关系R(A, B, C, D)和函数依赖集F = {A → B, B → C}，计算属性集A的闭包A+：

初始化A+ = {A}。
应用A → B，因为A是A+的子集，添加B到A+，得到A+ = {A, B}。
应用B → C，因为B是A+的子集，添加C到 A+，得到A+ = {A, B, C}。
没有更多的函数依赖可以应用，算法终止。最终，A+ = {A, B, C}。

Canonical Cover【最简函数依赖集】

函数依赖集F的规范覆盖（Canonical Cover），记为Fc，是一个等价于F的最小函数依赖集。 A canonical cover for F is a set of dependencies Fc such that:

F logically implies all dependencies in Fc
Fc logically implies all dependencies in F

(F+ = Fc+)

no functional dependency in Fc contains an extraneous attribute
each left side of functional dependency in Fc is unique. That is, there are no two dependencies in Fc, with the same left side i.e. X → Y and X → Z cannot both be in Fc

计算规范覆盖的步骤

do{
    1、使用Union rule结合右侧
    2、去除Fc中的冗余属性
}while(Fc不变)

例子

F、F+、Fc

Extraneous Attributes（冗余属性）

在函数依赖X → Y中，如果存在属性A ∈ X，使得在去掉A后，X - {A} → Y仍然成立，则称A是冗余属性。

例子

设有函数依赖集F = {AB → C, A → B}，检查属性A在AB → C中是否冗余：

计算B的闭包B+：
- 初始化B+ = {B}。
- 没有函数依赖可以应用，B+ = {B}。
检查是否B+包含C：
- B+不包含C，因此A不是冗余属性。最终，属性A在AB → C中不是冗余属性。

对于右端冗余属性的检查：在函数依赖X → Y中，如果存在属性B ∈ Y，使得在去掉B后，X → Y - {B}仍然成立，则称B是冗余属性。

移除左端冗余属性，得到更强的函数依赖【所需左端前提条件更少】

移除右端冗余属性，得到更弱的函数依赖【结论更少】

一个依赖关系under F的意思是可以从F中推导出该依赖关系

Dependency Preservation（依赖保持）

在关系模式分解中，如果分解后的每个子模式的函数依赖集的联合能够推导出原始模式的所有函数依赖，则称该分解是依赖保持的。

与holds on的区别在于， holds on是指某个具体的关系实例满足某个函数依赖，而dependency preservation是指分解后的模式在所有可能的关系实例中都能保持原始模式的函数依赖。

Fi：

7.5 Algorithms for Decomposition Using Functional Dependencies

本节内容 BCNF

Testing for BCNF /判断关系模式是否是BCNF
Testing Decomposition for BCNF/ 判断分解后的子模式是否是BCNF
BCNF decomposition algorithm/将关系模式分解为BCNF的方法

3NF

Testing for 3NF
3NF decomposition algorithm
Comparison of BCNF and 3NF

Testing for BCNF

To check if a non-trivial dependency $\alpha$ causes a violation of BCNF

compute $\alpha^+$ (the attribute closure of $\alpha$), and
verify that it includes all attributes of R, that is, $\alpha$ is a superkey of R.

Simplified but Incorrect test: To check if a relation schema R is in BCNF, it suffices to check only the dependencies in the given set F for violation of BCNF, rather than checking all dependencies in F+.

If none of the dependencies in F causes a violation of BCNF, then none of the dependencies in F+ will cause a violation of BCNF either.

However, simplified test using only F is incorrect when testing a relation in a decomposition of R

也就是说判断BCNF可以使用F作为充分条件，因为F无违例说明F+也无违例，但是判断子模式（a decomposition of R）只用F是错的！！！

Testing Decomposition for BCNF

Note:

the restriction of F to Ri 的意思是：将函数依赖集F中的所有函数依赖限制在子模式Ri上，即只保留那些在Ri中有效的函数依赖。举例子：设有关系模式R(A, B, C)和函数依赖集F = {A → B, B → C}，将R分解为子模式R1(A, B)和R2(B, C)。 the restriction of F to R1是{A → B}，因为B → C在R1中无效。

测试由R分解后的子模式Ri是否BCNF，不能仅凭R上的F，应该采用F+

Decomposition Algorithm for BCNF

检查关系模式R是否是BCNF。如果是，则返回R作为分解结果。（to determine whether or not Ri is in BCNF, the restriction of F to Ri and the candidate keys of Ri need to be computed）
如果R不是BCNF，找到一个违反BCNF的函数依赖X → Y，其中X不是R的超键。
将R分解为两个子模式R1和R2：
- R1 = X ∪ Y
- R2 = R - Y + X
递归地对R1和R2应用步骤1-3，直到所有子模式都是BCNF。

Note:

3中R1的意思是包含X和Y的所有属性的子模式，R2的意思是R中去掉Y属性后再加上X属性的子模式
该算法可能不会产生依赖保持的分解。
该算法确保每个子模式都是BCNF。

BCNF分解不保证依赖保持

Testing for 3NF

Need to check only FDs in F, no checking all FDs in F+.

Step1. Use attribute closure to check for each dependency $\alpha$, if $\alpha$ is a superkey

检查每个函数依赖左端是否为超键

Step2. If $\alpha$ is not a superkey, we have to verify if each attribute in $\beta$ is contained in a candidate key of R

如果左端不是超键，检查右端属性是否包含在某个候选键中

This test is rather more expensive, since it involve finding all candidate keys

Testing for 3NF has been shown to be NP-hard!

Interestingly, decomposition into third normal form (described shortly) can be done in polynomial time

Decomposition Algorithm for 3NF

为什么需要3NF分解算法？因为BCNF分解不保证依赖保持，而3NF分解算法可以保证依赖保持。

算法步骤：

计算函数依赖集F的规范覆盖Fc。
对于Fc中的每个函数依赖X → Y，创建一个子模式R_i = X ∪ Y。
如果没有子模式包含R的候选键，则添加一个子模式R_k，该子模式包含R的一个候选键。
返回所有子模式作为分解结果。

Note:

只要有一个候选键包含在第2步构造出的某个子模式Ri中，就无需在第3步中，为候选键单独构造子模式。任意挑选R的一个候选键【只需挑选一个】，对该候选健单独构造一个关系模式；无需考虑全部候选键!!!

Example of 3NF Decomposition 设有关系模式R(A, B, C, D)和函数依赖集F = {A → B, B → C}，应用3NF分解算法：

计算规范覆盖Fc = {A → B, B → C}。
创建子模式：
- R1 = {A, B}（对应A → B）
- R2 = {B, C}（对应B → C）（R1、R2都是BCNF）
R的候选键是{A, D}，没有子模式包含它，因此添加R3 = {A, D}。
返回子模式R1, R2, R3作为分解结果。

对比记忆BCNF和3NF算法

3NF合成：依赖于一个预先处理好的、最小化的规范覆盖Fc来“合成”模式。Fc是它的输入。

BCNF分解：是一个递归的、基于验证的分解过程，它直接使用当前模式上成立的函数依赖（来自原始F或其投影）来指导分解。它不关心F是否最小化。

因此，计算BCNF分解一般不需要计算Fc。

Appendix 7-1 Computing Candidate Keys

计算候选键的步骤：

step1. 将R的所有属性分为四类：

L类：仅出现在F中函数依赖左部的属性
R类：仅出现在F中函数依赖右部的属性
N类：在F中函数依赖左右两边均未出现的属性
LR类：在F中函数依赖左右两边均出现的属性令X_set=L类 ∪ N类，Y_set=LR类

step2. 求X_set +，

如果X_set+ =R，则X_set为R的唯一候选键，转step5；否则转step3

step3.

在Y_set中取一属性A，求(X_set ∪ A)+，若它包含了R的所有属性，则转step4; 否则，调换一属性反复进行这一过程，直到试完所有Y_set中的属性

step4.

如果已找出所有的候选键，则转step5; 否则，在Y_set中依此取两个、三个，…，求其属性闭包，直至其闭包包含R的所有的属性

step5. 停止，输出结果

最后，为什么需要4NF

在某些情况下，关系模式可能存在多值依赖（MVD），这会导致数据冗余和更新异常。4NF通过消除非平凡的多值依赖，进一步规范化关系模式，从而提高数据的完整性和一致性。

考题类型

判断最高范式 计算候选键，从BCNF向下找

Chapter7 关系规范化(7.1-7.3)

Sat, 01 Nov 2025 00:00:00 +0800

关系数据库设计步骤

无损连接

有损连接：拆分再恢复时出现多余错误记录如果R1、R2没有公共属性，则join时会退化成笛卡尔积

规范化理论

数据依赖

在逻辑DBS设计过程中，将E-R图转换，得到面向特定应用领域的初始关系模式集。这些初始关系模式集中可能存在多种作为完整性约束的关系模式属性间的数据依赖 (Data Dependencies) 关系

函数依赖 (Functional Dependencies, FD, §7.2) 多值依赖 (Mutivalued Dependencies, MVD, §7.4, 7.6) 连接依赖 (Join Dependencies, JD) （略）

函数依赖是特殊的多值依赖多值依赖又是连接依赖的特例

范式关系

保证关系模式的函数无损连接性、函数依赖保持性进行关系规范化处理即模式分解

1NF

原子属性

2NF

由1NF消除非主属性对键的部分（函数）依赖得到不包含非主属性对键的部分依赖

3NF

由2NF消除非主属性对键的传递依赖得到不包含非主属性的对键的部分、传递依赖

BCNF

由3NF消除主属性对键的部分和传递依赖得到不包含主属性、非主属性对键的部分和传递依赖

4NF

由BCNF消除非平凡且非函数依赖的多值依赖得到

5NF

由4NF消除非平凡的连接依赖得到

概念

函数依赖

可参考 Chapter 7 函数依赖

函数依赖保持

区分satisfy与holds on

满足是局部满足，保持是所有合法关系实例都必须满足此FD

平凡FD

主属性与传递依赖

部分依赖

左端非最小化

函数依赖闭包$F^{+}$

目的：从已知函数依赖，推导出全部隐含函数依赖

函数依赖定义的无损连接分解

范式

1NF

所有属性都是原子的 A relational schema R is in first normal form if the domains of all attributes of R are atomic. 比如应该把学院放进属性列而非使用学号编码

2NF

不存在非主属性对候选键的部分依赖非主属性要么不依赖，要么完全依赖于候选键

BCNF

不存在非主属性、主属性对候选键的部分、传递依赖 A relation schema R is in BCNF with respect to a set F of functional dependencies, if for all functional dependencies in $F^{+}$ of the form $\alpha \rightarrow \beta$ where $\alpha \subset \beta $ R and $\beta \subseteq R$, at least one of the following holds: $\alpha \rightarrow \beta$ is trivial (i.e., $\beta \subseteq \alpha$) $\alpha$ is a superkey for R 如何分解成BCNF？说白了就是让不属于原模式超键的属性都变为新模式的主键，并从原模式中去掉依赖式右端的属性

分解BCNF也存在函数依赖保持和非保持

总之就一句话： the functional dependency
s_ID, dept name → i_ID can only be checked by computing the join of the decomposed relations

3NF

Because it is not always possible to achieve both BCNF and dependency preservation, we consider a weaker normal form, known as third normal form (3NF). A relation schema R is in third normal form with respect to a set F of functional dependencies, if for all functional dependencies in $F^{+}$ of the form $\alpha \rightarrow \beta$ where $\alpha \subset \beta $ R and $\beta \subseteq R$, at least one of the following holds: $\alpha \rightarrow \beta$ is trivial (i.e., $\beta \subseteq \alpha$) $\alpha$ is a superkey for R Each attribute A in $\beta - \alpha$ is part of some candidate key for R If a relation is in BCNF, it is also in 3NF (since in BCNF one of the first two conditions above must hold). Third condition is a minimal relaxation（放宽） of BCNF to ensure dependency preservation (will see why later)

3NF缺点

Redundancy in 3NF【缺点:数据冗余】

3NF对比BCNF

Advantages to 3NF over BCNF

It is always possible to obtain a 3NF design without sacrificing losslessness or dependency preservation 3NF分解可以保证无损连接、函数依赖保持 BCNF分解保证无损连接，但不保证函数依赖保持

Disadvantages to 3NF

We may have to use null values to represent some of the possible meaningful relationships among data items.
There is the problem of repetition of information

分解目标

分解要求：从函数依赖角度 1. 分解为2NF, 3NF, BCNF 2. 必修保证无损连接分解，尽可能保证函数依赖保持

Chapter 6.8 ISA

Thu, 23 Oct 2025 00:00:00 +0800

ISA关系（6.8）

ISA Relationship 指的是一种特定的数据建模技术，用于在概念模型（如ER图）中表示实体之间的继承关系。

ISA 是 “IS-A” 的缩写，例如 “A Manager IS-AN Employee”（一个经理是一个员工）。它描述了一种父类型（超类型） 和子类型 之间的层次关系。

核心概念

在数据库设计中，ISA关系用于捕捉现实世界中存在的分类结构。

超类型 / 父类： 一个更一般化、更抽象的实体。
- 例如：人(Person)、账户(Account)、车辆(Vehicle)
子类型 / 子类： 一个更具体、更特化的实体，它是超类型的一种。
- 例如：员工(Employee) 和 学生(Student) 是 人(Person) 的子类型。
- 储蓄账户(SavingsAccount) 和 支票账户(CheckingAccount) 是 账户(Account) 的子类型。

ISA关系的两个关键约束

当你在设计中使用ISA关系时，必须定义两个重要的约束：

1. 重叠约束（Disjoint/Overlapping Constraint）

规定一个超类型的实例是否可以同时属于多个子类型。

不允许重叠： 一个超类实例只能属于一个子类型。
- 例如：一个 账户(Account) 要么是 储蓄账户(SavingsAccount)，要么是 支票账户(CheckingAccount)，但不能同时是两者。用 “OR” 表示。
允许重叠： 一个超类实例可以同时属于多个子类型。
- 例如：一个 人(Person) 可以同时是 员工(Employee) 和 学生(Student)。用 “AND” 表示。

2. 完备性约束（Completeness constraint）

规定超类型中的每一个实例是否都必须至少属于一个子类型。

全完备性（total）： 超类型的每一个实例都必须是某个子类型的实例。
- 例如：公司规定，每一个 员工(Employee) 都必须是 小时工(HourlyEmployee) 或 月薪工(SalariedEmployee) 中的一种。超类型 员工(Employee) 不会存在不属于任何子类的“孤例”。在ER图中，用双线表示。
部分完备性（partial）： 超类型的实例可以不属于任何子类型。
- 例如：一个 人(Person) 可以只是普通人，既不是 员工(Employee)，也不是 学生(Student)。在ER图中，用单线表示。

在数据库中的实现方式

ISA层次结构在物理数据库中主要有三种实现方式：

1. 每个具体类一张表

方法： 忽略超类型，只为每个子类型创建一张表。这张表包含该子类型特有的属性，以及从超类型继承来的所有属性。
举例： 创建 学生表(Students) 和 员工表(Employees)，没有 人表(Persons)。Students表中有 student_id, name, age, major 等字段。
优点： 查询特定子类型的数据时速度快。
缺点：
- 数据冗余（如果一个人既是学生又是员工，他的name和age信息会在两张表中重复存储）。
- 难以对所有人进行统一查询（需要UNION操作）。
- 无法表示不属于任何子类的人。

2. 单张表

方法： 将整个层次结构“扁平化”为一张表。这张表包含超类型和所有子类型的所有属性。同时，增加一个“类型鉴别”字段来标识每一行属于哪个子类型。
举例： 创建一张 人表(Persons)，包含字段：person_id, name, age, person_type, major, salary, department。
- 如果 person_type = ‘Student’，那么 major 字段有意义，salary 字段为NULL。
- 如果 person_type = ‘Employee’，那么 salary 字段有意义，major 字段为NULL。
优点： 统一查询非常简单，不需要JOIN操作。
缺点：
- 表中存在大量NULL值，浪费存储空间。
- 表结构会随着子类型的增加而变得非常庞大和复杂。

3. 超类型和子类型分别建表

方法： 为超类型和每一个子类型都创建一张表。
- 超类型表包含所有实例共享的公共属性（和一个主键）。
- 子类型表只包含其特有的属性，并共享超类型表的主键（即子类型表的主键同时也是引用超类型表的外键）。
举例：
- 人表(Persons)：person_id (PK), name, age
- 学生表(Students)：person_id (PK, FK references Persons), major
- 员工表(Employees)：person_id (PK, FK references Persons), salary, department
优点：
- 设计规范，消除了数据冗余。
- 易于添加新的子类型。
- 能很好地支持重叠约束（一个人可以同时在Students和Employees表中有记录）。
缺点： 查询数据时需要频繁使用JOIN操作，性能可能成为瓶颈。

总结

在数据库领域中，ISA Relationship 是一个强大的概念建模工具，它清晰地表达了 “是一个” 的继承关系。理解并正确定义其重叠约束和完备性约束至关重要，因为它直接影响到最终数据库表结构的设计选择（每种实现方式都有其优缺点，需要根据具体应用场景进行权衡）。

Chapter6 ER模型

Thu, 23 Oct 2025 00:00:00 +0800

Chapter 6 The Entity-Relationship Model

Entity Sets（实体集，实体型）

一张学生表是一个实体集，一个学生是一个实体（一行记录）

Relationship Sets(关系集)

选课表就是一个关系集。它定义了“学生”和“课程”之间的“选修”这种关系。关系表示特定实体之间的一次具体关联。它对应的是联系表中的一行记录。关系集也可以拥有自己的属性（关系集属性），用于描述关系的特征。它同样对应联系表中的列。选课表这个关系集可以有成绩、选修日期等属性，这些属性不属于学生，也不属于课程，而是属于“选修”这个行为本身。

Choice of Primary key for Binary Relationship

在多的那一端把一的主键拿过来当外键

多元联系(non-binary)

先转成多个二元联系再转表：将其他实体集的主键和关系自身属性建成表，各实体集不存放多余属性。

E-R图（概念设计结果）

Representing Cardinality Constraints in ER Diagram

→：一 —：多 (one,many) x (one,many) = 4 种

参与约束(Participant Constraints)

完全参与、部分参与

逻辑设计阶段

E-R图转关系模式实体、联系、属性（单值属性、多值属性、复合属性）如何转表？多值属性单独转表复合属性拆开（如时间、地址）

弱实体集、强实体集；用实体还是属性？ Not to use the primary-key of an entity set as an attributes of another entity set (to represent implicitly association between these two entity sets), it is better to use an relationship set to explicitly show this association e.g. for the entity student, do not use instructor.id as its attribute, in stead of, representing association among student and instructor using relationship advisor.

用实体还是关系？“动作”对应“联系”

弱实体集理解

扩展ER （详情看ISA那篇）

面向对象ER：Object-oriented (OO) E-R

specialization （特化，特殊化，例化）自上而下，底层实体集是高层实体集的真子集高层：超类；底层：子类

generalization (概括化，泛化，普遍化) 自底向上

attributes inheritance （属性继承）联系也可以继承

Aggregation

relationship on relationship（联系的联系）

ER图记号总结

Chapter2 关系数据库基础

Wed, 10 Sep 2025 00:00:00 +0800

关系数据库结构

table、relation、attributes

key

A superkey (超键) is a set of one or more attributes that, taken collectively, can be used to identify uniquely a tuple in the relation.

K is a candidate key (候选键) if K is minimal super key. e.g.{ID} is a candidate key for instructor, assuming no two instructors can possibly have the same identifiers. A relation may have several candidate keys

Primary key (主键) is a candidate key chosen by the database designer as principal means to identify tuples within a relation

Def. Primary attributes (主属性!) taking the key as a attribute set, the attributes in the candidate keys, i.e. the element of the primary key is called the primary attributes non-primary attributes (非主属性)

Super key >= candidate key >= primary key

relational algebra (关系代数)

Six basic operators

(选择) select: $\sigma$ (投影) project: (笛卡尔积) Cartesian product: x (集合并) union: (集合差) set difference: – (重命名) rename:

复合关系运算

暂时值（Assignment）

Chapter1 基本概念

Mon, 01 Sep 2025 00:00:00 +0800

名词

Database (DB)
The term DBS and DBMS are used interchangeably in the textbook
Database application system DB + DBMS + Application programs + Users/Administers
DBS = DB + DBMS

OS文件系统缺点

Data redundancy and inconsistency
Difficulty in accessing data
Data isolation/独立性（信号量）

数据库系统目的

Integrity/完整性 problems【语义约束】
Atomicity/原子性 of updates
Concurrent access/并发访问 by multiple users
Security problems

数据模型、数据建模、数据抽象

data models a collection of conceptual tools for describing:

data, data relationships/联系
data semantics/语义
consistency/一致性 constraints
specifications for data organization and access

data modeling organize application data in the database, according to data model, by data abstraction
data abstraction

database modeling mechanism
hide the complexity of data structures to represent data in the database from users through view-logical-physical levels of data abstraction

Levels of Abstraction

Physical level

describes how a record (e.g., instructor) is stored and accessed in database files

Logical level

Implementation/DB-oriented describes data stored in database, and the relationships among the data.

View level

application programs hide details of data types views can also hide information (such as an employee’s salary) for security purposes.
described as Entity-relationship (E-R) diagrams

DDL DML

Data Definition Language
DML

procedural/过程性 DML – require a user to specify what data are needed and how to get those data [e.g. relational algebra]
declarative/声明性 DML – require a user to specify what data are needed without specifying how to get those data [e.g. SQL]

数据库设计阶段

从保持data independence角度出发，根据data models所定义的数据规范形式，在view、logical 、 physical三个层次，通过data abstraction，经过概念设计、逻辑设计、物理设计三个步骤，构造面向具体应用领域的DBS的 E-R diagrams, external schema/logical schema , internal schema的集合, 得到conceptual DB 、logical DB 、physical DB设计结果