【MySQL】三十一、数据库设计三范式

口诀

第一范式：有主键，原子性，不可再分；

第二范式：不可产生部分依赖；（多对多，三张表，关系表加外键。）

第三范式：不可产生传递依赖；（一对多，两张表，多的表加外键。）

一对一的设计：主键共享，外键唯一

提醒： 在实际的开发中，以满足客户的需求为主，并非全部遵循三范式，有的时候会拿冗余换执行速度。

1. 什么是设计范式

设计表的依据。按照这个三范式设计的表不会出现数据冗余。

2. 三范式

2.1 第一范式

第一范式：任何一张表都应该有主键，并且每一个字段原子性不可再分。

不符合第一范式的示例：

存在问题：

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

改进后：

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

2.2 第二范式

第二范式：建立在第一范式的基础之上，所有非主键字段完全依赖主键，不能产生部分依赖。

不符合第二范式的示例：

确定主键：

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

解决方案：

学生信息表：

教师信息表：

教师和学生的关系表：

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

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

口诀：多对多，三张表，关系表两个外键。

2.3 第三范式

第三范式：建立在第二范式的基础之上，所有非主键字段直接依赖主键，不能产生传递依赖。

不符合第三范式的示例：

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

学生信息表：

班级信息表：

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

口诀：一对多，两张表，多的表加外键。

3. 三范式总结

• 第一范式：有主键，具有原子性，字段不可分割；

• 第二范式：完全依赖，没有部分依赖；

• 第三范式：没有传递依赖

提醒： 在实际的开发中，以满足客户的需求为主，有的时候会拿冗余换执行速度。

4. 一对一怎么设计？

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

（1）第一种：主键共享；

id既是主键，又是外键；

t_user_login 用户登录表：

id(pk)		username			password
-----------------------------------------
1				zs					123
2				ls					456

t_user_detail 用户详细信息表：

id(pk+fk)	realname			tel			....
------------------------------------------------
1				张三		  1111111111
2				李四		  1111415621

（2）第二种：外键唯一；

t_user_login 用户登录表：

id(pk)		username		  password
--------------------------------------
1				zs				 123
2				ls				 456

由于外键是可以为空的，主键是唯一不为空，所以希望外键也有这个功能，就用外键保证不为空，唯一表示不重复。

t_user_detail 用户详细信息表：

id(pk)	   realname			tel			userid(fk+unique)....
-----------------------------------------------------------
1			张三	   1111111111			2
2			李四	   1111415621			1

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