（7.1.2）数据库原理之关系规范化

• 候选码：可以用来做主键的元组
• 主键：多个候选码中的一个，可以标识
• 主属性：包含在候选码中的属性
• 非主属性：不包含在任何一个候选码中的属性
• 第二范式、第三范式、BCNF区别：
  2NF：非主键列和主键列之间，是完全依赖于主键，还是依赖于主键的一部分（只依赖某个主键）；
  3NF：非主键列之间，不存在依赖，只直接依赖主键。
  BCNF：主键列之间，不存在依赖。

1NF（First Normal Form）：原子性

• 当且仅当所有域只包含原子值，即每个分量都是不可再分的数据项，则称实体E满足第一范式
• 所谓第一范式（1NF）是指数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。
• 第一范式的合理遵循需要根据系统的实际需求来定。比如某些数据库系统中需要用到“地址”这个属性，本来直接将“地址”属性设计成一个数据库表的字段就行。但是如果系统经常会访问“地址”属性中的“城市”部分，那么就非要将“地址”这个属性重新拆分为省份、城市、详细地址等多个部分进行存储，这样在对地址中某一部分操作的时候将非常方便。这样设计才算满足了数据库的第一范式，如下表所示。
  
• 上表所示的用户信息遵循了第一范式的要求，这样在对用户使用城市进行分类的时候就非常方便，也提高了数据库的性能。

2NF（Second Normal Form）：消除对主键的部分依赖

• 当且仅当实体E满足第一范式，且每一个非键属性完全依赖主键时，满足第二范式
• 第二范式需要确保数据库表中的每一列都和主键相关，而不能只与主键的某一部分相关（主要针对联合主键而言）。
• 示例
  订单信息表
  
  这样就产生一个问题：这个表中是以订单编号和商品编号作为联合主键。这样在该表中商品名称、单位、商品价格等信息不与该表的主键相关，而仅仅是与商品编号相关。所以在这里违反了第二范式的设计原则。
  
  而如果把这个订单信息表进行拆分，把商品信息分离到另一个表中，把订单项目表也分离到另一个表中，就非常完美了。如下所示。

这样设计，在很大程度上减小了数据库的冗余。如果要获取订单的商品信息，使用商品编号到商品信息表中查询即可。

3NF（Third Normal Form）：消除传递依赖

• 当且仅当实体E是第二范式（2NF），且E中没有非主属性传递依赖时，满足第三范式
• 第三范式需要确保数据表中的每一列数据都和主键直接相关，而不能间接相关。
• 示例
  比如在设计一个订单数据表的时候，可以将客户编号作为一个外键和订单表建立相应的关系。而不可以在订单表中添加关于客户其它信息（比如姓名、所属公司等）的字段。如下面这两个表所示的设计就是一个满足第三范式的数据库表。
  
  这样在查询订单信息的时候，就可以使用客户编号来引用客户信息表中的记录，也不必在订单信息表中多次输入客户信息的内容，减小了数据冗余。

BCNF

不存在关键字段决定关键字段的情况
1. 所有非主属性对每一个码都是完全函数依赖。
2. 所有的主属性对每一个不包含它的码,也是完全函数依赖。
3. 没有任何属性完全函数依赖于非码的任何一组属性。