数据库范式

第一范式
1、每一列属性都是不可再分的属性值，确保每一列的原子性
2、两列的属性相近或相似或一样，尽量合并属性一样的列，确保不产生冗余数据。

1

2

如果需求知道那个省那个市并按其分类，那么显然第一个图是不容易满足需求的，也不符合第一范式。

1

2

显然第一个图结构不但不能满足足够多物品的要求，还会在物品少时产生冗余。也是不符合第一范式的。

第二范式
每一行的数据只能与其中一列相关，即一行数据只做一件事。只要数据列中出现数据重复，就要把表拆分开来。

1

一个人同时订几个房间，就会出来一个订单号多条数据，这样子联系人都是重复的，就会造成数据冗余。我们应该把他拆开来。

2

3

这样便实现了一条数据做一件事，不掺杂复杂的关系逻辑。同时对表数据的更新维护也更易操作。
补充1
2NF：满足1NF,表中的字段必须完全依赖于全部主键而非部分主键

第三范式
数据不能存在传递关系，即每个属性都跟主键有直接关系而不是间接关系。像：a-->b-->c 属性之间含有这样的关系，是不符合第三范式的。

比如Student表（学号，姓名，年龄，性别，所在院校，院校地址，院校电话）

这样一个表结构，就存在上述关系。 学号--> 所在院校 --> (院校地址，院校电话)

这样的表结构，我们应该拆开来，如下。

（学号，姓名，年龄，性别，所在院校）--（所在院校，院校地址，院校电话）
补充1
3NF：满足2NF,非主键外的所有字段必须互不依赖

BC范式
主属性之间没有依赖关系。
BCNF 在第三范式的基础上，数据库表中如果不存在任何字段对任一候选关键字段的传递函数依赖。

（1）所有非主属性对每一个码都是完全函数依赖；
（2）所有的主属性对于每一个不包含它的码，也是完全函数依赖；
（3）没有任何属性完全函数依赖于非码的任意一个组合。

R属于3NF，不一定属于BCNF，如果R属于BCNF，一定属于3NF。

假设仓库管理关系表为StorehouseManage(仓库ID, 存储物品ID, 管理员ID, 数量)，且有一个管理员只在一个仓库工作；一个仓库可以存储多种物品。这个数据库表中存在如下决定关系：

(仓库ID, 存储物品ID) →(管理员ID, 数量)
(管理员ID, 存储物品ID) → (仓库ID, 数量)

所以，(仓库ID, 存储物品ID)和(管理员ID, 存储物品ID)都是StorehouseManage的候选关键字，表中的唯一非关键字段为数量，它是符合第三范式的。但是，由于存在如下决定关系：

(仓库ID) → (管理员ID)
(管理员ID) → (仓库ID)
所以不符合BC范式

最后：
范式只是一般设计数据库的基本理念，可以建立冗余较小、结构合理的数据库。如果有特殊情况，当然要特殊对待，数据库设计最重要的是看需求跟性能，需求>性能>表结构。所以不能一味的去追求范式建立数据库。