2、属性间的关系（去除冗余）

　　2NF-实体必须符合1NF，每个属性描述的东西都必须针对整个键（可以理解为oop中类型属性的内聚性）。

　　当前设计不符合2NF的“臭味”：

　　● 重复的键属性名字前缀（设计之外的数据冗余） 表明这些值可能描述了某些额外的实体。

　　● 有重复的数据组（设计之外的数据冗余） 这标志着属性间有函数依赖型。

　　● 没有外键的复合主键 这标志着键中的键值可能标识了多种事物，而不是一种事物。

　　3NF-实体必须符合2NF，非键属性不能描述其他非键属性。（与2NF不同，3NF处理的是非键属性和非键属性之间的关系，而不是和键属性之间的关系。

　　当前设计不符合3NF的“臭味”：

　　● 多个属性有同样的前缀。

　　● 重复的数据组。

　　● 汇总的数据，所引用的数据在一个完全不同的实体中。（有些人倾向于使用视图，我更倾向于使用对象集合，即由程序来完成。）

　　BCNF-实体满足第一范式，所有属性完全依赖于某个键，如果所有的判定都是一个键，则实体满足BCNF。（BCNF简单地扩展了以前的范式，它说的是：一个实体可能有若干个键，所有属性都必须依赖于这些键中的一个，也可以理解为“每个键必须标识实体，每个非键熟悉必须描述实体。”

　　3、去除实体组合键中的冗余

　　4NF-实体必须满足BCNF，在一个属性与实体的键之间，多值依赖（一条记录在整个表的性由多个值组合起来决定的）不能超过一个。

　　当前设计不符合4NF的“臭味”：

　　● 三元关系（实体：实体：实体）。

　　● 潜伏的多值属性。（如多个手机号。）

　　● 临时数据或历史值。（需要将历史数据的主体提出，否则将存在大量冗余。）

　　4、尽量将所有关系分解为二元关系

　　5NF-实体必须满足4NF，当分解的信息无损的时候，确保所有关系都被分解为二元关系。

　　5NF保证在第四范式中存在的任何可以分解为实体的三元关系都被分解。有的三元关系可以在不丢失信息的前提下被分解为二元关系，当分解为两个二元关系的过程要丢失信息时，关系被宣称为处于第四范式中。所以，第五范式建议是，好把现有的三元关系都分解为3个二元关系。

　　需要注意的是，规范化的结果可能是更多的表，更复杂的查询。因此，处理到何种程度，取决于性能和数据架构的多方考量。建议规范化到第四范式，原因是5NF的判断太过隐晦。例如：表X（老师，学生，课程）是一个三元关系，可以分解为表A（老师，学生），表B（学生，课程），表C（老师，课程）。表X表示某个老师是上某个学生的某个课程的老师；表A表示老师教学生；表B表示学生上课；表C表示老师教课。单独看是无法发现问题的，但是从数据出发，"表X=表A+表B+表C"并不一定成立，即不能通过连接构建分解前的数据。因为可能有多种组合，丧失了表X反馈出的业务规则。这种现象，容易在设计阶段被忽略，但好在在开放阶段会被显现，而且并不经常发生。

　　推荐做法：

　　● 尽可能地遵守上述规范化原则。

　　● 所有属性描述的都应该是体现被建模实体的本质的内容。

　　● 至少必须有一个键，它地标识和描述了所建实体的本质。

　　● 主键要谨慎选择。

　　● 在逻辑阶段能做多少规范化做多少（性能不是逻辑阶段考虑的范畴）。