数据库前三大范式
前言：
- 一共有六个范式，在此文章中只学前三个，学会这前三个，在正常的一般的工作中等等就够用了。
- 范式对应的英文：Normal Form，简称NF。
范式：
- 在设计数据库时需要遵守的几个规范，
- 可以在设计完数据库后看一看这几个范式，验证一下设计的数据库是否合理。
范式的作用：
- 在设计数据库时我们如果遵循了这三大范式，那么我们的数据库表就会非常的合理。（越高的范式数据库冗余越小）
第一范式：数据库表的每一列都是不可分割的原子数据项
eg:修改前：
因为在“系”一列，它有两个子列，所以这张表就不符合第一范式。
修改后：
这样它就符合了第一范式。
抛出范式不想，思考一下这张表存在的问题：
- 存在的问题分析：
- 1.数据冗余：eg：张三丰存储了三次
- 2.数据与数据之前的关联性太大：eg：删除张三丰这个人，那么张三丰所对应的其他列也会被删除，不能因为删除一个人而把整个系删除吧。（正常来说一个系当然不会只有一个人，但是举得这个例子嘛）
- 3.添加数据不合理：eg：如果想添加一个系，而对应的学生等其他信息没有，那么我们添加数据时不合法。
于是后面的范式解决了这些问题……
第二范式：在1NF的基础上，非码属性必须完全依赖于码（在1NF基础上消除非主属性对主码的部分函数依赖）
- 因为术语较多，所以在了解第二范式之前我们要先知道几个概念：
- 1.函数依赖：如果通过a属性(属性组)的值能确认b属性的值，那么我们称b依赖于a（就像函数似的 y = 2x，y通过x的值来确定，我们就称y依赖于x）eg：学号–>姓名（通过学号能确认唯一的姓名）
- 属性组：多个数据的属性和 就叫属性组。eg：学号+课程名称
- 完全函数依赖：如果b完全函数依赖于a，（a是一个属性组）那么b一定函数依赖于a中所有属性的值。eg：学号+课程名称–>分数（通过学号和课程名称可以确认分数，而分数是即依赖于学号，又依赖于课程名称的，所以这就叫完全函数依赖），当然有完全肯定也有不完全呗。
- 部分函数依赖：eg：学号+课程名称–>姓名，通过学号我们就可以确认姓名，姓名不函数依赖于课程名称，这就叫部分函数依赖。
- 传递函数依赖：a–>b–>c，如果b依赖于a，c依赖于b，那么我们就可以说c依赖于a。eg：通过“学号”可以确认“系名”，通过系名我们可以确认“系主任”。这就叫传递函数依赖
- 码：如果表中的属性/属性组被表中其他所有属性所完全依赖，那么这个属性/属性就叫做“码”。
- 主属性：码属性组重的所有属性
- 非主属性：除码属性中的属性
了解了这些概念后，我们再来翻译一下术语：
其实第二范式就是在说，一个表中必须有一个码，也就是有一个主属性，其他的属性都完全依赖于这个主属性
那么现在我们再分析一下这张表：
姓名、系名、系主任都完全依赖于学号；分数完全依赖于学号+课程名称，所以我们就分两个表设计：
第一张表：
第二张表：
-
分析：(第二张表把重复的去掉了，因为可以不用再重复写了) 第一张表码/主属性为学号+课程名称，第二张表码/主属性为学号
-
那么我们现在再分析一下第一次的那些问题：
- 1.数据冗余：eg：张三丰存储了三次。
- 2.数据与数据之前的关联性太大：eg：删除张三丰这个人，那么张三丰所对应的其他列也会被删除，不能因为删除一个人而把整个系删除吧。（正常来说一个系当然不会只有一个人，但是举得这个例子嘛）
- 3.添加数据不合理：eg：如果想添加一个系，而对应的学生等其他信息没有，那么我们添加数据时不合法。
- 数据重复储存的问题解决了，但是后两个问题好像还是没有解决。那么我们接着玩下看：
第三范式：在2NF基础上，任何非主属性不依赖于其它非主属性（在2NF基础上消除传递依赖）
- 我们来看这张表：
系主任依赖于学号，但同时，系主任也依赖于系名，系名依赖于学号，这不就是传递函数依赖吗？所以第三范式就是再说，我们要消除这种传递依赖。或者说非主属性除了依赖于主属性外不能再依赖其他主属性了。
那么第三次修改：
分析：因为和第二次分析一样，前两张表就不分析了；第三种表：码/主属性为系名，非主属性（系主任）都完全依赖于主属性（系名）(当然也可以把系主任当成码，但是常理来说说是先看系名再看系主任嘛)。
再来分析一下最开始的三个问题：
- 1.数据冗余：eg：张三丰存储了三次
- 2.数据与数据之前的关联性太大：eg：删除张三丰这个人，那么张三丰所对应的其他列也会被删除，不能因为删除一个人而把整个系删除吧。（正常来说一个系当然不会只有一个人，但是举得这个例子嘛）
- 3.添加数据不合理：eg：如果想添加一个系，而对应的学生等其他信息没有，那么我们添加数据时不合法。
这三个问题就全部都解决了！！
附录：本博客的图片来自b站javaweb教程，本人小白一个，最近在家开始自学javaweb知识。