在前面的部分，我们学习了ER建模方法，一种泛化的自上而下的数据库设计方法，在这一节，我们学习另外的一种泛化的数据库设计的方法，叫做规范化。在数据库设计中，规范化可以有两种使用方法，第一种是把规范化用作自下而上的数据库设计方法，第二种是把规范化方法与ER建模结合起来使用，把规范化作为自下而上的方法包括分析属性之间的关联，基于这个分析，把属性结合在一起形成代表实体和关系的表，然而在属性很多的时候，使用这种方法很难奏效， 因为很难建立属性之间的所有重要的关联。由于这些原因，建议应该使用自上而下的数据库设计方法，先理解数据，我们使用ER建模技术创建代表主要实体和关系的数据模型，然后把ER模型翻译成代表数据的一组表。在这一点我们使用规范化方法检查表的设计是否良好。
规范化是一种用来产生表的集合的技术，这些表具有符合要求的属性，并能支持用户或公司的需求，规范化通常作为对表结构的一系列测试来决定它是否满足或者符合给定范式。存在几种范式形式，但是最常用的是第一范式，第二范式和第三范式。所有这些范式都是基于在表中的列之间的关系的。在以下的内容中，我们首先指出引起数据冗余的错误的结构化表是怎样导致问题的出现的，这些问题叫做更新异常，错误的结构化表可能产生于原始ER模型或者在将ER模型转化成表时出现的错误，然后给出第一范式，第二范式和第三范式的定义，并解释每个范式是怎样用来确定和更正表中的不同类型的问题的。
数据异常和更新异常，关系数据库设计的一个主要目的是把列组合成表使数据的冗余最小，并减少实现基表所需要的文件存储空间，例如有以下的表的定义StaffBranch（StaffNo,name,position,salary,branchNo,branchAddress,telNo）
在StaffBranch表中有冗余数据，因为分公司的细节信息在分公司的每个员工那里被重复了一遍，如果删除所有员工的信息，那么也就没有了分公司的信息。这样就会导致删除异常，如果更新了一个员工所在的分公司的信息，那么员工所在的分公司信息就会不一致，这样就会导致更改异常，如果分公司的新员工尚不存在，插入新员工时就会导致插入异常，所有这些异常统称为更改异常。
如果把StaffBranch表拆分为两个表，Staff和Branch表Staff（StaffNo,name,position,salary）,branch(branchNo,branchAddress,telNo)则他们不会出现以上所示的异常，他们符合一定的范式，下面介绍一下范式的概念。
第一范式：记录的每个列包含一个而且只包含一个值的表，或者说数据项是不可拆分的表，如果一个记录的某一个列有多个值，那么就不是1NF，比如一个电话号码列包含了110,120，119多个电话号码。
第二范式：一个第一范式的表并且任何一个非主属性都完全依赖于主键的表。部分依赖是指一个非主属性可以从主键的部分属性或者部分属性的组合中得到。完全功能依赖是指如任何一个非主属性都必须由主键的全部属性组合中得到。
第三范式：一个已经是第一和第二范式的表，并且所有的非主键列的值只能从主键中得到，而不能从其他的途径得到。也就是说消除了传递依赖。任何一个非主键属性都不传递依赖于主键。
在数据库设计中经常遇到的范式就是第三范式，经过多年的发展不仅有BCNF,第四范式，同时也有了第五范式，他们都在不同程度上解决了一定的数据冗余问题。对于一般的数据库应用，第三范式已经足够使用，因此不需要赘述。有兴趣的读者可以到baidu上搜索以下，在此不多作介绍。
本文转自凌辉博客51CTO博客，原文链接http://blog.51cto.com/tianli/54271如需转载请自行联系原作者
lili00okok
