数据库范式

这两天开始做一个商城项目，但是在做的过程中用到数据库，在生成数据库表时，由于表与表之间需要遵循数据库范式规则，而之前上课时也没有讲过关于数据库范式相关的内容，所以今天上网搜了一些关于数据库范式的相关内容，数据库共有六大范式：第一范式（1NF）、第二范式（2NF）、第三范式 （3NF）、第四范式（4NF）、第五范式（5NF）和第六范式（6NF），而我们平常会用到前三种范式：
1、每一列属性都是不可再分的属性值，确保每一列的原子性，也就是第一范式是指数据库表中的每一列都是不可分割的基本数据项，同一列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。 如果出现重复的属性，就可能需要定义一个新的实体，新的实体由重复的属性构成，新实体与原实体之间为一对多关系。第一范式的模式要求属性值不可再分裂成更小部分，即属性项不能是属性组合或是由一组属性构成。 简而言之，第一范式就是无重复的列，在任何一个关系数据库中，第一范式（1NF）是对关系模式的基本要求，不满足第一范式（1NF）的数据库就不是关系数据库，例如，由“学号”“姓名”“电话号码”组成的表(一个人可能有一部办公电话和手机)，这时将其规范化为1NF可以将电话号码分为“办公电话”和“手机”两个属性，即学生(学号，姓名，办公电话，移动电话)
2、第二范式(2NF)是在第一范式(1NF)的基础上建立起来的，即满足第二范式(2NF)必须先满足第一范式(1NF)，第二范式(2NF)要求数据库表中的每个实例或行必须可以被唯一地区分，为实现区分通常需要为表加上一个列，以存储各个实例的唯一标识，每一行的数据只能与其中一列相关，即一行数据只做一件事，只要数据列中出现数据重复，就要把表拆分开来例如，在选课关系表(学号，课程号，成绩，学分)，关键字为组合关键字(学号，课程号)，但由于非主属性学分仅依赖于课程号，对关键字(学号，课程号)只是部分依赖，而不是完全依赖，因此此种方式会导致数据冗余以及更新异常等问题，解决办法是将其分为两个关系模式：学生表(学号，课程号，分数)和课程表(课程号，学分)，新关系通过学生表中的外关键字课程号联系，在需要时进行连接。
3、第三范式数据不能存在传递关系，即每个个属性都跟主键有直接关系而不是间接关系。像：a–>b–>c 属性之间含有这样的关系，是不符合第三范式的，如果关系模型R是第二范式，且每个非主属性都不传递依赖于R的候选键，则称R是第三范式的模式。
以学生表(学号，姓名，课程号，成绩)为例，其中学生姓名无重名，所以该表有两个候选码(学号，课程号)和(姓名，课程号)，故存在函数依赖：学号——>姓名，(学号，课程号)——>成绩，唯一的非主属性成绩对码不存在部分依赖，也不存在传递依赖，所以属性属于第三范式
4、第四范式也可以说是BCNF(BC范式)构建在第三范式的基础上，如果关系模型R是第一范式，且每个属性都不传递依赖于R的候选键，那么称R为BCNF的模式，禁止主键列和非主键列一对多关系不受约束：
（1）所有非主属性对每一个码都是完全函数依赖；
（2）所有的主属性对于每一个不包含它的码，也是完全函数依赖；
（3）没有任何属性完全函数依赖于非码的任意一个组合。
R属于3NF，不一定属于BCNF，如果R属于BCNF，一定属于3NF
5、第五范式是指关系模式R依赖均由R候选码所隐含，如果关系模式R中的每一个连接依赖均由R的候选码所隐含。
我们在设计数据库的时候，只用到前三种范式，而其它范式则很少用到，哈哈哈，今天终于理清了数据库表与表的关系啦！