数据库设计三范式
第一范式：要求任何一张表必须有主键，每一个字段原子性不可再分。
第二范式：建立在第一范式之上，要求所有非主键字段必须完全依赖主键，不能部分依赖
第三范式：建立在第二范式之上，要求所有非主键字段必须直接依赖主键，不要产生传递依赖
按照三范式设计数据库，可以避免表中数据的冗余，造成空间不必要的浪费。
三种基本关系：
第一范式
必须有主键，并且每一个字段都是原子性不可再分。
学生编号 学生姓名 联系方式
------------------------------------------
1001 张三 zs@gmail.com,1359999999
1002 李四 ls@gmail.com,13699999999
1001 王五 ww@163.net,13488888888
不满足第一范式：没有主键，并且联系方式可再分
修改：
学生编号(pk) 学生姓名 邮箱地址 联系电话
---------------------------------------------------------
1001 张三 zs@gmail.com 1359999999
1002 李四 ls@gmail.com 13699999999
1003 王五 ww@163.net 13488888888
第二范式
要求所有非主键字段必须完全依赖主键，不要产生部分依赖。
学生编号 学生姓名 教师编号 教师姓名
-----------------------------------------------------
1001 张三 001 王老师
1002 李四 002 赵老师
1003 王五 001 王老师
1001 张三 002 赵老师
不满足第一范式：
学生编号+教师编号(pk) 学生姓名 教师姓名
----------------------------------------------------
1001 001 张三 王老师
1002 002 李四 赵老师
1003 001 王五 王老师
1001 002 张三 赵老师
但是由于复合主键，导致部分依赖主键：“张三”依赖1001，“王老师”依赖001，显然产生了部分依赖。数据冗余了。空间浪费了。“张三”重复了，“王老师”重复了。
对于这种多对多关系，我们采取“建立三张表，关系表两外键”的方式
学生表
学生编号(pk) 学生名字
------------------------------------
1001 张三
1002 李四
1003 王五
教师表
教师编号(pk) 教师姓名
--------------------------------------
001 王老师
002 赵老师
学生教师关系表
id(pk) 学生编号(fk) 教师编号(fk)
------------------------------------------------------------
1 1001 001
2 1002 002
3 1003 001
4 1001 002
第三范式
要求所有非主键字典必须直接依赖主键，不要产生传递依赖。
学生编号（PK） 学生姓名 班级编号 班级名称
---------------------------------------------------------
1001 张三 01 一年一班
1002 李四 02 一年二班
1003 王五 03 一年三班
1004 赵六 03 一年三班
一年一班依赖01，01依赖1001，产生了传递依赖。
对于这种一对多的关系，我们采取建立两张表，多的表加外键
班级表：一
班级编号(pk) 班级名称
----------------------------------------
01 一年一班
02 一年二班
03 一年三班
学生表：多
学生编号（PK） 学生姓名 班级编号(fk)
-------------------------------------------
1001 张三 01
1002 李四 02
1003 王五 03
1004 赵六 03
总结
-
一对多
两张表，多的表加外键
-
多对多
三张表，关系表两个外键
-
一对一
对于一些巨大的表，需要对表进行拆分，拆成两张表，外键唯一
数据库设计三范式是理论上的。
实践和理论有的时候有偏差。
最终的目的都是为了满足客户的需求，有的时候会拿冗余换执行速度。
因为在sql当中，表和表之间连接次数越多，效率越低。（笛卡尔积）
有的时候可能会存在冗余，但是为了减少表的连接次数，这样做也是合理的，并且对于开发人员来说，sql语句的编写难度也会降低。
面试的时候把这句话说上：他就不会认为你是初级程序员了！
