范式
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即可，甚至有时会了提高查询效率会有意降低范式要求【反范式】