数据库建立的原则---三大范式（转载）

标准化表示从你的数据存储中移去数据冗余的过程。如果数据库设计达到了完全的标准化，则把所有的表通过关键字连接在一起时，不会出现任何数据的复本。标准化的优点是明显的，它避免了数据冗余，自然就节省了空间，也对数据的一致性提供了根本的保障，杜绝了数据不一致的现象，同时也提高了效率。

范式，是关系型数据库关系模式规范化的标准，从规范化的宽松到严格，分别为不同的范式，通常使用的有第一范式 (1NF) 、第二范式 (2NF) 、第三范式 (3NF) 等。

1NF ：字段具有原子性 , 不可再分。（所有关系型数据库系统都满足第一范式）

2NF ：对于具有组合关键字的表 . 不存在组合关键字中的任意字段决定其它非关键字字段的情况。

3NF ：在 2N 的基础上 , 每一个非主属性既不部分依赖于码也不传递依赖于码 .

第一范式（ 1NF ）

         第一范式是最低的规范化要求，第一范式要求数据表不能存在重复的记录，即存在一个关键字。 1NF 的第二个要求是每个字段都不可再分，即已经分到最小。这个单一属性由基本类型构成，包括整型、实数、字符型、逻辑型、日期型等。

例如：

符合第一范式：    字段 1 、字段 2 、字段 3 、字段 4
         不符合第一范式： 字段 1 、 字段 2 、字段 3 、字段 4    、字段 3.1 、字段 3.2
     很显然，在当前的任何关系数据库管理系统（ DBMS ）中，也不可能做出不符合第一范式的数据库，因为这些 DBMS 不允许你把数据库表的一列再分成二列或多列。 1NF 是关系模式应具备的最起码的条件，如果数据库设计不能满足第一范式，就不称为关系型数据库。关系数据库设计研究的关系规范化是在 1NF 之上进行的。满足 1NF 的关系模式有许多不必要的重复值，并且增加了修改其数据时疏漏的可能性。为了避免这种数据冗余和更新数据的遗漏，就引出了第二范式（ 2NF ）。   

第二范式（ 2NF ）

         如果一个关系属于 1NF ，且所有的非主关键字段都完全地依赖于主关键字，则称之为第二范式。简单的说，第二范式要满足以下的条件：首先要满足第一范式，其次每个非主属性要完全函数依赖与候选键，或者是主键。也就是说，每个非主属性是由整个主键函数决定的，而不能由主键的一部分来决定。
例如：

选课关系表 SelectCourse 中包括字段 ( 学号 , 姓名 , 年龄 , 课程名称 , 成绩 , 学分 ) ，关键字为组合关键字 ( 学号 , 课程名称 ) ，此表存在的决定关系： ( 学号 , 课程名称 ) → ( 姓名 , 年龄 , 成绩 , 学分 )
，这个表是不满足第二范式的，因为存在如下决定关系：
       ( 课程名称 ) → ( 学分 ) 

       ( 学号 ) → ( 姓名 , 年龄 )
       即存在组合关键字中的字段决定非关键字的情况。由于不符合 2NF ，这个选课关系表会存在如下问题：
        (1) 数据冗余：同一门课程由 n 个学生选修， " 学分 " 就重复 n-1 次；同一个学生选修了 m 门课程，姓名和年龄就重复了 m-1 次。
       (2) 更新异常：若调整了某门课程的学分，数据表中所有行的 " 学分 " 值都要更新，否则会出现同一门课程学分不同的情况。
        (3) 插入异常：假设要增加一门新的课程，暂时还没有人选修。这样，由于还没有 " 学号 " 关键字 , 课程名称和学分也无法记录入数据库。
       (4) 删除异常：假设一批学生已经完成课程的选修，这些选修记录就应该从数据库表中删除。但是，与此同时，课程名称和学分信息也被删除了。很显然，这也会导致插入异常。

如果把选课关系表改为如下三个表：
1 ）学生： Student( 学号 , 姓名 , 年龄 ) ；
2 ）课程： Course( 课程名称 , 学分 ) ；
3 ）选课关系： SelectCourse( 学号 , 课程名称 , 成绩 ) 。

这样的数据库表是符合第二范式的，消除了数据冗余、更新异常、插入异常和删除异常。另外，所有单关键字的数据库表都符合第二范式，因为不可能存在组合关键字。

第三范式（ 3NF ）
          如果一个关系属于 2NF ，且每个非关键字不传递依赖于主关键字，这种关系是 3NF 。
简单的说，第三范式要满足以下的条件：首先要满足第二范式，其次非主属性之间不存在函数依赖。由于满足了第二范式，表示每个非主属性都函数依赖于主键。如果非主属性之间存在了函数依赖，就会存在传递依赖，这样就不满足第三范式。
          所谓传递函数依赖，指的是如果存在 "A → B → C" 的决定关系，则 C 传递函数依赖于 A 。因此，满足第三范·式的数据库表应该不存在依赖关系：关键字段 → 非关键字段 x→ 非关键字段 y 。

例如：

学生关系表 Student 中字段包括 ( 学号 , 姓名 , 年龄 , 所在学院 , 学院地点 , 学院电话 ) ， 关键字为单一关键字 " 学号 " ，存在如下决定关系：
       ( 学号 ) → ( 姓名 , 年龄 , 所在学院 , 学院地点 , 学院电话 )
       这个数据库是符合 2NF 的，但是不符合 3NF ，因为存在如下决定关系：
       ( 学号 ) → ( 所在学院 ) → ( 学院地点 , 学院电话 )
    即存在非关键字段 " 学院地点 " 、 " 学院电话 " 对关键字段 " 学号 " 的传递函数依赖。它也会存在数据冗余、更新异常、插入异常和删除异常的情况。
       如果把学生关系表分为如下两个表：
       学生： ( 学号 , 姓名 , 年龄 , 所在学院 ) ；
       学院： ( 学院 , 地点 , 电话 ) 。
    这样的数据库表是符合第三范式的，消除了数据冗余、更新异常、插入异常和删除异常。

利弊

有一利必有一弊。它最大的不利是把信息放置在不同的表中，增加了操作的难度，同时把多个表连接在一起的花费也是巨大的。因为表和表的连接操作是做两个关系的笛卡儿积，必然会产生大量无用甚至无效的记录，性能的代价是巨大的。

规范化的优点也是明显的。避免了大量的数据冗余，节省了空间，保持了数据的一致性，如果完全达到 3NF ，就不会在超过一个地方更改同一个值。如果记录经常的改变，这个优点会超过所有可能的缺点！

即使花费很多的时间，作出一个完全规范化的数据库，它仍然不是完美的。规范化设计所带来的性能问题可能是无法承受的。如果出现这种情况，就要准备进行非规范化了。非规范化就是为了获得性能上的利益所进行的违反规范化规则的操作，不过大部分都与实际应用有关系，包括复制属性，复制外来关键字，表合并，表重新组合等等。 满足范式要求的数据库设计是结构清晰的，同时可避免数据冗余和操作异常。这并意味着不符合范式要求的设计一定是错误的，在数据库表中存在 1 ： 1 或 1 ： N 关系这种较特殊的情况下，合并导致的不符合范式要求反而是合理的。 总之，要学会根据实际的应用选择最有效的方法。