浅谈对数据库范式的理解

标签：建立   style   font   用户表   区分   很多   关系   数据   family   

　　数据库的设计范式是数据库设计所需要满足的规范，若满足的数据库的规范，则该数据库是简洁的、结构明晰的，同时不会发生插入、删除、跟新操作异常。否则数据库的设计是不够合理的，会给编程人员带来很多麻烦，也可能会造成大量的数据冗余。下面谈一谈我最近对数据库范式的理解。

1.1第一范式（1NF）确保每列保持原子性

　　我理解的第一范式就是：数据表中的每一列都是不可再分割的了，就是同一列不能有多个值，也不能有重复的列。例

这个例子就是电话这一列出现了两个电话号，这是不符合1NF的，我们可以这样让他只添加一个电话号，或者再加一行。即

在任何一个关系数据库中，第一范式（1NF）是对关系模式的基本要求，不满足第一范式（1NF）的数据库就不是关系数据库。

1.2第二范式（2NF）属性完全依赖于主键

　　第二范式是在第一范式的基础上建立起来，即满足第二范式必须先满足第一范式。第二范式要求数据表中的每行的内容必须可以被唯一区分。简单来说就是每一个实例（行）都要有一个唯一标识（主键）。

　　例：现有一张选课关系表，字段包括（学号，姓名，年龄，课程名称，学分，成绩），关键字（主键）为（学号，课程名称），

存在：（学号，课程名称）——>（姓名，年龄，学分，成绩），

但这张表并不是2NF，因为我们可以看到他应存在：（课程名称）——>（学分）和（学号）——>（姓名，年龄）。

所以正确的2NF应该是将这张表拆分成三张表，即：学生表（学号，姓名，年龄），课程表（课程名称，学分），成绩表（学号，课程名称，成绩）

1.3第三范式（3NF）属性不依赖于其他非主属性

　　满足第三范式必须先满足第二范式，第三范式要求一个数据表中不包含已在其他表中已包含的非主键信息。简单来说就是，一张数据表只能包含其他数据表的主键字段。例如现有一张部门表（部门ID，部门名称，地址），还有用户表（用户ID，用户姓名，部门ID，部门名称，地址）。这是不满足三范式的，因为在用户表中已经存在了“部门ID”，就不需要再写“部门名称”和“地址”了。如果我们需要“部门名称”和“地址”的话，我们可以这样（用户ID）——>（部门ID）——>（部门名称，地址）。所以，正确的三范式应该是，部门表（部门ID，部门名称，地址），还有用户表（用户ID，用户姓名，部门ID）。

浅谈对数据库范式的理解

标签：建立   style   font   用户表   区分   很多   关系   数据   family   

原文地址：http://www.cnblogs.com/lcl-dcr/p/7632989.html