NF(normal form)作为一个数据库设计里经常会提到的概念，是每一个初学者都应该了解并掌握的。复习数据库的时候发现 Database System Concepts 这本书里讲的过于抽象，而且网上也没有特别好的讲解，于是自己重新整理一份，有需者自取。
NF的意义
Normal form作为设计的标准范式，其最大的意义就是为了避免数据的冗余和插入/删除/更新的异常。举个例子
表1
school(stu-id,stu-name,major,dean-name,dean-telephone)
在学校这个表里面，学生的学号、姓名、专业、系主任以及系主任电话被放到了一起（典型的excel风格）。虽然这样有些时候也不是不可以，但当进行一些特定操作的时候，着实会给我们带来极大的困扰。
- 插入异常[ 输入新信息的时候，系主任电话号码输错 ] : 无法确认系主任的真正号码。
- 删除异常[ 某个系的学生全部退学了 ] : 该系对应的系主任名字和电话号码也随之丢失。
- 更新异常[ 系主任进行变更 / 系主任换手机号 ] : 我们需要把系里所有学生的行都给更新一遍，显然开销过大。
1NF
定义：所有的属性均有原子性
说人话：所有的属性均不可被再分割，国外比较喜欢拿人名来举例(first,middle,last)，但跟国内国情不太符合，我就举一个商品的例子好了。
TaobaoPucharsedLog(sid, date, buyer, seller, goods,amount)
显然“商品”会有更多详细的属性，例如商品名称，商品价格，产地等等。“用户”也有昵称，年龄，住址等，“商户”也是如此。这些属性都是可以再分割的，所以并不符合1NF范式，需要将其完全拆至不可分割为止。
修改示范：
TaobaoPucharsedLog(sid, date, buyer-id, buyer-name, buyer-age, seller, goods, amount) [仅拆开了buyer]
意义：嗯.. 这个还是等我们讲完四个定理再来说吧，现在讲解比较困难。
2NF（在满足1NF的前提上）
定义：如果依赖于主键，则需要依赖于所有主键，不能存在依赖部分主键的情况
说人话：对于上面那个例子，TaobaoPucharsedLog(sid, date, buyer-id, buyer-name, buyer-age, seller-id, seller-name, seller-age, goods-id, goods-name, amount)。可以看到里面有四个主键：sid, buyer-id, seller-id, goods-id。对于seller-name属性，它仅依赖于seller-id，跟buyer-id之类的没有任何关系，所以它对于主键的依赖是“部分依赖”，并不符合2NF。简单点说，就是不要把不相关的东西放到一个表里面。
修改示范：
拆解成以下四个
- TaobaoPucharsedLog(sid, buyer-id, seller-id, goods-id, amount)
- BuyerInformation(buyer-id, buyer-name, buyer-age)
- SellerInformation(seller-id, seller-name, seller-age)
- GoodsInformation(goods-id, goods-name)
意义：不相关的东西不要放在一起，用多个小表连接来代替大表，减少修改时候的负担。
3NF（在满足1NF和2NF的前提上）
定义：一个数据库表中不包含已在其它表中已包含的非主关键字信息。
说人话：不得存在传递式依赖，比如对于一张数据库，里面的元素有son, person, father, grand-father，依赖关系是son -> person, person -> father, father -> grand-father，明显有一个链表式的传递，3NF中禁止此类依赖的出现。
修改示范：
依赖关系修改为
- son -> person
- son -> father
- son -> grand-father
或者是拆成三张表
(其实就是并查集里面的路径压缩）
意义：避免查询路径过长而导致询问时间过长或者更新异常。以上面的家族关系为例，如果我想查询某位同学曾曾曾曾曾……曾祖父是谁，按照非3NF的依赖，则需要进行多次查询，而对于满足3NF的依赖，只需要进行一次查询。效率大大提高。
