数据库三范式

数据库设计的三范式

1、第一范式 

数据库表中不能出现重复记录，每个字段是原子性的不能再分

不符合第一范式的示例

学生编号	学生姓名	联系方式
1001	张三	zs@gmail.com,1359999999
1002	李四	ls@gmail.com,13699999999
1001	王五	ww@163.net,13488888888

存在问题： 

1. 最后一条记录和第一条重复（不唯一，没有主键）
2. 联系方式字段可以再分，不是原子性的

学生编号(pk)	学生姓名	email	联系电话
1001	张三	zs@gmail.com	1359999999
1002	李四	ls@gmail.com	13699999999
1003	王五	ww@163.net	13488888888

关于第一范式，每一行必须唯一，也就是每个表必须有主键，这是我们数据库设计的最基本要求，主要通常采用数值型或定长字符串表示，关于列不可再分，应该根据具体的情况来决定。如联系方式，为了开发上的便利行可能就采用一个字段了。

2、第二范式

第二范式是建立在第一范式基础上的，另外要求所有非主键字段完全依赖主键，不能产生部分依赖

示例：

学生编号	学生姓名	教师编号	教师姓名
1001	张三	001	王老师
1002	李四	002	赵老师
1003	王五	001	王老师
1001	张三	002	赵老师

 

确定主键：

学生编号(PK)	教师编号(PK)	学生姓名	教师姓名
1001	001	张三	王老师
1002	002	李四	赵老师
1003	001	王五	王老师
1001	002	张三	赵老师

以上虽然确定了主键，但此表会出现大量的冗余，主要涉及到的冗余字段为“学生姓名”和“教师姓名”，出现冗余的原因在于，学生姓名部分依赖了主键的一个字段学生编号，而没有依赖教师编号，而教师姓名部门依赖了主键的一个字段教师编号，这就是第二范式部分依赖。

解决方案如下：

学生信息表

学生编号（PK）	学生姓名
1001	张三
1002	李四
1003	王五

 

教师信息表

教师编号（PK）	教师姓名
001	王老师
002	赵老师

 

教师和学生的关系表

学生编号(PK)  fkà学生表的学生编号	教师编号(PK) fkà教师表的教师编号
1001	001
1002	002
1003	001
1001	002

 

如果一个表是单一主键，那么它就复合第二范式，部分依赖和主键有关系

以上是一种典型的“多对多”的设计

 

3、第三范式

建立在第二范式基础上的，非主键字段不能传递依赖于主键字段。（不要产生传递依赖）

学生编号（PK）	学生姓名	班级编号	班级名称
1001	张三	01	一年一班
1002	李四	02	一年二班
1003	王五	03	一年三班
1004	六	03	一年三班

从上表可以看出，班级名称字段存在冗余，因为班级名称字段没有直接依赖于主键，班级名称字段依赖于班级编号，班级编号依赖于学生编号，那么这就是传递依赖，解决的办法是将冗余字段单独拿出来建立表，如：

学生信息表

学生编号（PK）	学生姓名	班级编号（FK）
1001	张三	01
1002	李四	02
1003	王五	03
1004	六	03

 

班级信息表

班级编号（PK）	班级名称
01	一年一班
02	一年二班
03	一年三班

以上设计是一种典型的一对多的设计，一存储在一张表中，多存储在一张表中，在多的那张表中添加外键指向一的一方的主键

4、三范式总结

第一范式：有主键，具有原子性，字段不可分割（分量不可再分）

第二范式：完全依赖，没有部分依赖（除了对主键字段有依赖以外，还依赖于其他非主键字段）

第三范式：没有传递依赖 （某一字段A依赖于非主键字段B，B有依赖于主键，则存在传递依赖）

一对一设计，有两种设计方案：

第一种设计方案：主键共享

第二种设计方案：外键唯一

       5、在实际开发过程中，数据库设计尽量遵循三范式，但是还是根据实际情况进行取舍，有时可能会拿冗余换速度，最终用目的要满足客户需求。