数据库的第一范式、第二范式、第三范式，BCNF范式

四大范式的基本概念
- 是否规范化的程度越高越好?
- 名词解释
范式优化实例
- 一个特别糟糕的关系模式
- 第一范式
- 第二范式
- 第三范式
- BCNF范式

此文章用于本人期末复习，适合对数据库范式分析还有一点记忆的同学，在此不多赘述各范式的概念

四大范式的基本概念

第一范式：不存在表中有表的情况，每一属性都不可再分
第二范式：在第一范式的基础上消除了非主属性对码的部分函数依赖
第三范式：在第二范式的基础上消除了非主属性对码的传递函数依赖
BCNF:在第三范式的基础上消除了主属性对于码的部分与传递函数依赖
可以把范式理解成一个关系模式升级的过程。
虽然满足越高范式所带来的表会更多，看似管理起来会更麻烦，但是在实际做表的增删改（查例外）时你就会发现单个表的结构越简单你修改的思路就会越清晰。特别是在做大型的数据库设计时，一般要满足三范式以上的规范程度。
但是

是否规范化的程度越高越好?

这要根据需要来决定，因为“分离”越深，产生的关系越多，关系过多，连接操作越频繁，
而连接操作是最费时间的，特别对以查询为主的数据库应用来说，频繁的连接会影响查询速度。所以，关系有时故意保留成非规范化的，或者规范化以后又反规范了，这样做通常是为了改进性能。
反规范的好处是降低连接操作的需求、降低外码和索引的数目，还可能减少表的数目，相应带来的问题是可能出现数据的完整性问题。加快查询速度，但会降低修改速度。
因此决定做反规范时，一定要权衡利弊，仔细分析应用的数据存取需求和实际的性能特点，好的索引和其它方法经常能够解决性能问题，而不必采用反规范这种方法。【此段引用这里：是否规范化的程度越高越好?】

名词解释

要想完全理解以上范式的概念，还需掌握以下几个名词的含义：
码：表中可以唯一确定一个元组的某个属性（或者属性组），如果这样的码有不止一个，那么大家都叫候选码，我们从候选码中挑一个出来做老大，它就叫主码。

主属性：一个属性只要在任何一个候选码中出现过，这个属性就是主属性。

非主属性：与上面相反，没有在任何候选码中出现过，这个属性就是非主属性。

范式优化实例

下面就用一个特别糟糕的关系模式作为例子，一步步优化成最高BCNF范式

一个特别糟糕的关系模式

首先，仓库和管理员之间是1对1的关系，仓库名和物品名间是多对多，且和进货数量也是多对多。物品名和物品种类编号是多对1，和种类名也是多对1，物品名和进货单价是1对1。

[仓库进货物品表]

很明显这个关系模式属于表中有表的情况。

第一范式

所以为了满足第一范式这里我们把进货数量，和进货单价分开来。

[仓库进货物品表]

这里的码为：仓库名，管理员，物品名，其他为非主属性
(仓库名，管理员，物品名)->进货数量；
(物品名)->物品种类编号，物品种类名，进货单价
可以看出，非主属性 “物品种类编号、物品种类名、进货单价” 都只存在对 “物品名” 存在依赖，与其他码 “仓库名、管理员” 都没有关系，属于对码的部分依赖。

第二范式

所以为了满足第二范式我们把
(物品名)->物品种类编号，物品种类名，进货单价
单独分出一个表

[仓库管理物品表]

[物品信息表]

继续看这个物品信息表
(物品名)->物品种类编号，物品种类名，进货单价
而实际上物品种类名只依赖与物品种类编号，即
(物品种类编号)->物品种类名
(物品名)->物品种类编号
这里存在非主属性 “物品种类编号” 对主属性 “物品名” 的传递函数依赖。

第三范式

所以为了满足第三范式我们将
(物品种类编号)->物品种类名
单独分出一个表
[物品信息表]

[物品种类表]

BCNF范式

我们再来看之前的
[仓库管理物品表]

仓库名 → 管理员，管理员 → 仓库名
(仓库名，物品名)->(物品名，数量)
(管理员，物品名)->(仓库名，数量)
这里的管理员和仓库名作为主属性又作为该表的码存在互相依赖的关系，属于主属性对于码的部分与传递函数依赖，所以为了满足BCNF范式我们将
仓库名 → 管理员
单独分出一个表，最后达到BCNF范式的关系模式如下图

如果还有不清楚的部分，可以参考这位大佬的，对于函数部分依赖，和传递依赖做了更详细的解释。
参考文档