数据库设计中的五个范式

第一范式：

对于表中的每一行，必须且仅仅有唯一的行值.在一行中的每一列仅有唯一的值并且具有原子性.

（第一范式是通过把重复的组放到每个独立的表中，把这些表通过一对多关联联系起来这种方式来消除重复组的。）

第二范式：

第二范式要求非主键列是主键的子集，非主键列活动必须完全依赖整个主键。主键必须有唯一性的元素,一个主键可以由一个或更多的组成唯一值的列组成。一旦创建，主键无法改变，外键关联一个表的主键。主外键关联意味着一对多的关系.

（第二范式处理冗余数据的删除问题。当某张表中的信息依赖于该表中其它的不是主键部分的列的时候，通常会违反第二范式。）

第三范式：

第三范式要求非主键列互不依赖.

（第三范式规则查找以消除没有直接依赖于第一范式和第二范式形成的表的主键的属性。我们为没有与表的主键关联的所有信息建立了一张新表。每张新表保存了来自源表的信息和它们所依赖的主键。）

第四范式：

第四范式禁止主键列和非主键列一对多关系不受约束

（）

第五范式：

第五范式将表分割成尽可能小的块，为了排除在表中所有的冗余.

（）

在数据库设计时，大家应该时刻的注意到这几个范式。其中第五范式是最难实现的。但是，还是需要尽量的去实现这些功能。

范式目标之一：逻辑正确。例如，经理管理部门信息，人事管理员工。如果采用范式分成“部门”“员工”主子2表，人事管理员工时，只能为员工指定现在存在的合法部门ID。如果不采用范式，部门和员工的信息在一个表中，管理员工时，就可能因为人事疏忽、或程序不完善为员工指定了一个错误、不存在的部门名称。或者同一个部门，在不同的记录中，简称一样，名称却不一样等等。这样，公司的部门就被搞乱套了。范式化的数据模型具有健壮性，能够抵御一定程度的人为和程序的疏忽，保证数据的完整性。

在实际业务逻辑中，会遇到前面几位提到的例子，是否需要保存冗余的历史信息，也就是范式中最关键的词汇“依赖”是否在发生变动时永远都能够成立。否则，就不是“依赖”，不用范式。就这个送货地址变更例子而言，怎样看待这个“依赖”成立，可以站在不同的角度上，短时间段内，还是系统的全寿命内，得出的结论自然不同，每个人的不同观点在自己的角度上看都是对的，但是最终还是要看业务规则是否要这个“依赖”。

范式目标之二：成本、代价、"cost"。当初制定范式时的代价和现在的代价含义已经大不相同。那时存储是稀缺资源，需要各种

手段节约存储（Y2K问题就是一个佐证）。但是现在，存储是极廉价的（无论大机还是微机，扩内存和硬盘的代价远低于升级CPU或升主频），而时间和程序员是稀缺资源。采用范式最大的好处是节约存储，但坏处是做某些复杂查询时，需要高级的程序员写出极复杂的多级关联查询语句。我曾经为一个范式系统写过一条select查询语句，仅一句（含多次关联、集合等操作）就有近2000字长，如果在DOS下整个一屏幕都显示不下，天哪！这种典型的范式系统浪费了最稀缺的资源：技术员、开发时间、运行时的等候时间，而且这样的程序的维护性几乎是0。

另外一个考虑因素是后来引出来的。原来的系统多是OLTP，面向交易处理，插入、删除、修改操作占多。有实践工作经验的人都知道，在这样的范式系统中，要做灵活复杂的报表有多么痛苦，就算是有各种智能辅助报表工具也是令人遗憾。而现在的系统，决策、分析占了很重要的角色，如果要问数据库仓库的分析工具为什么能够快速做出各种复杂的分析？关键就是非范式化。但是我们设计的每个系统都能够使用OLTP加一个数据库仓库这种配置吗？显然不现实，在系统中实现一定的非范式化，可以简化查询、报表的工作，丰富其功能。

非范式系统的最大的问题是数据的一致性，DBMS的KEY & FKEY帮不上忙了，就需要额外的机制来保证。怎样权衡，还需要实践，就不是一次能够讲清楚的了。