详解各种范式

前言：关于如何设计并优化数据库的理论知识快要结束了，知乎这一篇文章写的比我更加详细

第一范式（1NF）

之前说过：第一范式就是关系模式 R 中所有的属性都是原子性的

1NF 是所有关系型数据库的最基本要求，

第二范式（2NF）

在第一范式的基础下：为了设计出更好的数据库。为了增删改更加自然，我们提出了第二范式：

无关属性不能与码的部分有函数依赖

要搞清楚这句话，首先我们得知道什么是码：

在这里的码通常是指候选码的意思，候选码就是超码的最小子集。

那什么是无关属性呢？所有候选码并集中的所有属性就是主属性，所以除去所有属性的剩下属性就是无关属性

那么码的部分是什么呢？候选码有时候不只一个属性，码的部分就是候选码的不包括自己以及空集的子集

在结束「第二范式」之前我举一个例子

举个例子

假设有这么一张表 r 有属性 A B C D 函数依赖如下：

F = {
    A ➜ D,
    B ➜ C
}

那么这张表是否满足第二范式呢？不满足！

很明显「码」是 A B，主属性是 A、B。无关属性 C 与 A 有函数依赖，无关属性 D 与 B 有函数依赖，所以不是

为了满足第二范式我们应该把这张表拆成两张表：

A D
B C

第三范式（3NF）

到了第三范式，条件又严格了：

非主属性对于码的部分不能有传递函数依赖

什么叫做传递函数依赖，假设有依赖如下：

A ➜ B,
B ➜ C

由于我们之前说到的公理可得：

A ➜ C

这就是「第三范式」，在理解第二范式的基础上，理解第三范式十分容易，理所当然我再举一个例子

举个例子

假设又这么一张表 r 有属性 A B C D 函数依赖如下：

F = {
    A ➜ D,
    B ➜ C,
    A ➜ B
}

那么这张表是否满足第三范式呢？满足！

通过函数依赖我们可以得到

A ➜ C

所以很容易推出主键是 A，由于主属性只有一个，所以肯定满足「第三范式」

BC 范式（BCNF）

哪怕满足了「第三范式」数据库的设计还是不够好。

「BC 范式」就是：

主属性对于码的部分不能有函数依赖与传递函数依赖

我们通过一个例子学习这一范式

例子

假如有这么一张表：

存在的函数依赖如下：

F = {
    仓库名 ➜  管理员,
    管理员 ➜  仓库名,
    仓库名，物品名 ➜  数量
}

对于这么一个关系我们可以推出：

• 码是[仓库名, 物品名] 或 [管理员，物品名]
• 主属性：仓库名、管理员、物品名
• 非主属性：数量

不存在非主属性对码的部分函数依赖和传递函数依赖。∴ 此关系模式属于 3NF

哪怕这张表已经满足了 3NF，但依然设计的不好。

比如某仓库被清空后，需要删除所有与这个仓库相关的物品存放记录，会带来什么问题？——仓库本身与管理员的信息也被随之删除了

而我们不想这样，想要保留仓库本身的信息和管理员的信息

造成此问题的原因：存在着主属性对于码的部分函数依赖与传递函数依赖。（在此例中就是存在主属性【仓库名】对于码【（管理员，物品名）】的部分函数依赖。

解决办法就是要在 3NF 的基础上消除主属性对于码的部分与传递函数依赖。

得到新的两张表：

仓库（仓库名，管理员）
库存（仓库名，物品名，数量）

总结

大概学习了一下数据库的设计与优化，我可能开始真真正正的开发我的第一款应用