超全数据库期末复习资料汇总整理（下）

4、RELATIONAL DATABASE THEORY

4.1 Functinal Dependency

定义:设一个关系为R(U),X和Y为属性集U上的子集,若对于X上的每个值都有Y上的一个唯一值与之对应,则称X和Y具有函数依赖关系,并称X 函数决定Y,或称Y函数依赖于X,记作X→Y,称X为决定因素。
简单地说，函数依赖就是：知道A可以确切的找到B，这样的函数叫做函数依赖。其实就是单值函数：例如：f（x）=2x（PS：后面会有详细的示例说明）

Trivial FD and NON-Trivial FD

Full FD and PARTIAL FD

Transitive FD

4.2 Identify Functional Dependency

Armstrong’s Axioms(1974)

---

Algorithm for Computing (X+)闭包

example：
例:已知关系模式R(ABC),F={A→C,B→C},求F+

解：∵U={A，B，C}，左部不同的属性集组合有23=8种：

Φ、A、B、C、AB、BC、AC、ABC。

（1）∴Φ→Φ

（2）∵(A)F+=AC

∴A→Φ、A→A、A→C、A→AC。

（3）∵(B)F+=BC

∴B→Φ、B→B、B→C、B→BC。

（4）∵©F+=C

∴C→Φ、C→C。

（5）∵(AB)F+=ABC

∴AB→Φ、AB→AB 、AB→A、AB→B 、AB→C、AB→BC 、AB→AC、AB→ABC 。

（6）∵(BC)F+=BC

∴BC→Φ、BC→BC、BC→B、BC→C。

（7）∵(AC)F+=BC

∴AC→Φ、AC→BC、AC→B、AC→C。

（8）∵(ABC)F+=ABC

∴ABC→Φ、ABC→ABC 、ABC→A、ABC→B 、ABC→C、ABC→BC 、ABC→AB、ABC→AC。

所以F+共有35个具体如下：

∴Φ→Φ、A→∅、A→A、A→C、A→AC

B→Φ、B→B、B→C、B→BC

C→Φ、C→C、 AB→∅、AB→AB 、AB→A、AB→B 、AB→C、AB→BC 、AB→AC、AB→ABC 、

BC→Φ、BC→BC、BC→B、BC→C、

AC→Φ、AC→BC、AC→B、AC→C、

ABC→Φ、ABC→ABC 、ABC→A、ABC→B 、ABC→C、ABC→BC 、ABC→AB、ABC→AC

---

Finding Candidate Keys from FDs

Method2:

---

4.3 Lossless Join Decomposition

如果是两个以上{U1，U2，U3…}这种，那就比较麻烦了，比如，有属性集，

ABCDEF，存在这样的函数依赖集{A->BC , CD->E , B->D , BE->F , EF->A},然后有

这样的分解{ABC , BD , BEF}。

4.4 Dependency-Preserving Decomposition

---

5、NORMALIZATION

5.1 Well-Structured Relations

A relation that contains minimal data redundancy and allows users to insert, delete, 

and update rows without causing data inconsistencies is called Well-Structured Relations.

5.2 1NF

强调的是列的原子性，即列不能够再分成其他几列。 
考虑这样一个表：【联系人】（姓名，性别，电话） 

如果在实际场景中，一个联系人有家庭电话和公司电话，那么这种表结构设计就没有达到 1NF。要符合 1NF 我们只需把列（电话）拆分，即：【联系人】（姓名，性别，家庭电话，公司电话）。1NF 很好辨别，但是 2NF 和 3NF 就容易搞混淆。 

说明：在任何一个关系数据库中，第一范式（1NF）是对关系模式的设计基本要求，一般设计中都必须满足第一范式（1NF）。不过有些关系模型中突破了1NF的限制，这种称为非1NF的关系模型。换句话说，是否必须满足1NF的最低要求，主要依赖于所使用的关系模型。

5.3 2NF

首先是 1NF，另外包含两部分内容，一是表必须有一个主键；二是没有包含在主键中的列必须完全依赖于主键，而不能只依赖于主键的一部分。 

考虑一个订单明细表：【OrderDetail】（OrderID，ProductID，UnitPrice，Discount，Quantity，ProductName）。 
因为我们知道在一个订单中可以订购多种产品，所以单单一个 OrderID 是不足以成为主键的，主键应该是（OrderID，ProductID）。显而易见 Discount（折扣），Quantity（数量）完全依赖（取决）于主键（OderID，ProductID），而 UnitPrice，ProductName 只依赖于 ProductID。所以 OrderDetail 表不符合 2NF。不符合 2NF 的设计容易产生冗余数据。 

可以把【OrderDetail】表拆分为【OrderDetail】（OrderID，ProductID，Discount，Quantity）和【Product】（ProductID，UnitPrice，ProductName）来消除原订单表中UnitPrice，ProductName多次重复的情况。

 第二范式（2NF）要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性，如果存在，那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体，新实体与原实体之间是一对多的关系。为实现区分通常需要为表加上一个列，以存储各个实例的唯一标识。简而言之，第二范式就是在第一范式的基础上属性完全依赖于主键。

5.4 3NF

在1NF基础上，任何非主属性不依赖于其它非主属性[在2NF基础上消除传递依赖]。

第三范式（3NF）是第二范式（2NF）的一个子集，即满足第三范式（3NF）必须满足第二范式（2NF）。

首先是 2NF，另外非主键列必须直接依赖于主键，不能存在传递依赖。即不能存在：非主键列 A 依赖于非主键列 B，非主键列 B 依赖于主键的情况。 考虑一个订单表【Order】（OrderID，OrderDate，CustomerID，CustomerName，CustomerAddr，CustomerCity）主键是（OrderID）。 

其中 OrderDate，CustomerID，CustomerName，CustomerAddr，CustomerCity 等非主键列都完全依赖于主键（OrderID），所以符合 2NF。不过问题是 CustomerName，CustomerAddr，CustomerCity 直接依赖的是 CustomerID（非主键列），而不是直接依赖于主键，它是通过传递才依赖于主键，所以不符合 3NF。 

通过拆分【Order】为【Order】（OrderID，OrderDate，CustomerID）和【Customer】（CustomerID，CustomerName，CustomerAddr，CustomerCity）从而达到 3NF。 

第二范式（2NF）和第三范式（3NF）的概念很容易混淆，区分它们的关键点在于，2NF：非主键列是否完全依赖于主键，还是依赖于主键的一部分；3NF：非主键列是直接依赖于主键，还是直接依赖于非主键列。

5.5 BCNF

5.6 4NF

没有多对多的关系

6、DATABASE DESIGN ER MODELING

6.1 Entity and Entity Set

6.2 Strong Entity and Weak Entity

6.3 ER Diagram Notations

6.3 Generalization(IS_A hierarchies)

Specialization反之

7、TRANSACTION AND CONCURRENCY CONTROL

7.1 Transaction

7.2 Schedule

Serial Schedule

Conflict Operations

Equivalent Schedules

Test Schedule Serializability

7.3 Locking-based Concurrency Control Protocols

Two-phase Locking Protocol(2PL)

7.4 Deadlock Handling

wait-die是年轻的优先(非抢占)
wound-wait是老的优先
且年轻的回滚，老的等待

Deadlock detection

以上