数据库中的范式

范式 NF

设计关系数据库时，遵从不同的规范要求，设计出合理的关系型数据库，这些不同的规范要求被称为不同的范式，各种范式呈递次规范，越高的范式数据库冗余越小。

目前关系数据库有 5+1 级范式：第一范式 (1NF) 、第二范式 (2NF) 、第三范式 (3NF) 、巴斯 - 科德范式

(BCNF) 、第四范式 (4NF) 和第五范式 (5NF ，又称完美范式 ) 。满足最低要求的范式是第一范式 (1NF) 。在第一范式的基础上进一步满足更多规范要求的称为第二范式(2NF) ，其余范式以次类推。如果不满足所要求的范式，则将不满足范式要求的部分进行分表。一般说来，数据库只需满足第三范式(3NF) 就行了。

数据库设计中的概念

实体：现实世界中客观存在并可以被区别的事物。比如 “ 一个学生 ” 、 “ 一本书 ” 、 “ 一门课 ” 等等。值得

强调的是这里所说的 “ 事物 ” 不仅仅是看得见摸得着的 “ 东西 ” ，它也可以是虚拟的，不如说 “ 老师与学

校的关系 ” 。

属性：教科书上解释为： “ 实体所具有的某一特性 ” ，由此可见，属性一开始是个逻辑概念，比如

说， “ 性别 ” 是 “ 人 ” 的一个属性。在关系数据库中，属性又是个物理概念，属性可以看作是 “ 表的一

列 ” 。

元组：表中的一行就是一个元组。

分量：元组的某个属性值。在一个关系数据库中，它是一个操作原子，即关系数据库在做任何操作

的时候，属性是 “ 不可分的 ” 。否则就不是关系数据库了。

码：表中可以唯一确定一个元组的某个属性（或者属性组），如果这样的码有不止一个，那么叫候

选码，从候选码中挑一个出来做老大，它就叫主码。

全码：如果一个码包含了所有的属性，这个码就是全码。

主属性：一个属性只要在任何一个候选码中都出现过，这个属性就是主属性。

非主属性：与上面相反，没有在任何候选码中出现过，这个属性就是非主属性。

外码：一个属性（或属性组），它不是码，但是它别的表的码，它就是外码。

候选码： 若关系中的某一属性或属性组的值能唯一的标识一个元组，而其任何真子集都不能再标

识，则称该属性组为（超级码）候选码。

主键的定义

主键可分为 2 大类：自然主键和代理主键。一般建议使用代理主键

将表中的所有列的组合当作主键 -- 候选码

去除其中某些列查看是否还能唯一标识一行数据

最后找到的所有候选码的真子集就是主码

最佳实践：可以在表中添加一个与业务无关的字段充当主键 id bigint primary key auto_increment

NF1

所有列不可分，字段满足原子性

定义学生，学生 ( 编号、班级编号、姓名、亲属 ) ，这个亲属列是可分的，所以将亲属列划分到另外表中，从而使剩余的列满足NF1 ，最终结构选择为 学生 ( 编号、班级编号、姓名 ) 、学生亲属 ( 姓名、关系、外码 )

NF2

消除对主键的部分依赖

定义学生，学生 ( 编号、班级编号、姓名、宿舍楼号 ) ，主键为复合主键 ( 编号、班级编号 ) ，这里会发现一旦班级编号确定则所属的系别就确定，系别确定则宿舍楼号确定。宿舍楼号部分依赖主键，不是依赖整个主键。解决问题的方法为分表 学生 ( 编号、班级编号、姓名 ) 学生住宿 ( 班级编号、宿舍楼号 )

NF3

消除对主键的传递依赖

定义学生，学生（学号 pk 、系别、宿舍楼号），主键为学号，所以自然满足 NF2 ，但是一旦系别确定则宿舍楼号确定，所以宿舍楼号依赖于系别，不是依赖于学号。这里就是传递依赖：宿舍楼号--> 系别 --> 学号pk 。解决问题的方法为分表

范式和反范式

应用范式可以减少数据冗余，但是范式级别越高，则创建表的数量越多，查询效率则越低。所以在具体开发中经常采用降低范式要求，采用合理冗余数据的方式以提高查询效率考虑查询效率，所以一般只达到NF3即可，甚至有时会了提高查询效率会有意降低范式要求【反范式】