数据库设计的三大范式——明确概念和通俗理解
一、数据库名词二、三大范式第一范式第二范式第三范式 三、总结一、数据库名词
在理解三大范式之前，我们先明确一下数据库一些名词的概念，方便我们之后的理解。
实体——某类事物的集合，每一类数据对象的个体称为实体属性——实体的一个特征，也称之为字段，数据库表中的列元组——实体所有属性构成的集合，数据库表中的一行信息关系——实体的元组构成的集合，数据库的表码——码就是能唯一标识实体的属性。他是整个实体集的性质，而不是单个实体的性质。它包括超码，候选码，主码。超码——一个或多个属性的集合，能唯一标识一个实体,即能找到数据库中唯一的一列信息候选码——超码的其中一种。候选码是最小的超码，候选码的任何一个真子集都不能成为超码主码——也称为主属性，主键。被数据库设计者选中的，用来在同一实体集中区分不同实体的候选码
以下图为例对这些概念进行解释
学生为实体学生的学号、姓名等成为属性(字段)。在数据库表中属性包括属性名，属性类型，属性值，值类型。如第一条数据的姓名属性，他的属性名为姓名，属性类型为非主属性，属性值为徐三，值类型为varchar。这里详细描述是想告诉大家属性不单单是指姓名这两个字，而是包含更多的内容。整个表即是一个关系，表中的每一行数据为一个元组超码：{学号}、{身份证号}、{学号、身份证号}、{学号、姓名}、{学号、院系}、{学号、身份证号、姓名、院系}等等都是超码，它们的集合都能唯一的标识一条数据，但是超码中可能会有一些冗余信息，比如
{学号、身份证号、姓名、院系}中姓名和院系都是冗余信息 ，甚至学号和身份证号中的其中一个也可视作冗余信息候选码：最小的超码，也就是去除了冗余信息，其真子集不是超码，如{学号}、{院系}。假设每个班级学生的姓名时唯一的，{院系、班级、姓名}也能构成一个候选码，他的真子集{学院}、{班级}、{姓名}、{学院、姓名}、{班级、姓名}、{学院、班级}都无法标识一条数据。主码 ：这里我们可以选用{学号}、{身份证号}两个其一都可以作为主码
二、三大范式
第一范式
当关系模式R的所有属性都不能在分解为更基本的数据单位时，称R是满足第一范式的，简记为1NF。
假设学生表如下则不满足第一范式，院系和班级信息可再分
简单理解：属性不可再分
第二范式
如果关系模式R满足第一范式，并且R的所有非主属性都完全依赖于R的每一个候选关键属性，称R满足第二范式，简记为2NF。
假设有一张成绩表如下则不满足第二范式
该表的主码为{学号、科目}，通过主码能唯一的标识一条数据，但是该条数据中的姓名是依赖学号找出的，而与科目属性无关，即姓名属性没有完全依赖于候选码的每一个属性，不满足第二范式。修改为两张表
简单理解：所有非主属性只能通过主键的属性集合查询出，不能通过主键的真子集属性（一个或多个不完全包含于主键的属性）查询出
第三范式
设R是一个满足第一范式条件的关系模式，X是R的任意属性集，如果X非传递依赖于R的任意一个候选关键字，称R满足第三范式，简记为3NF。
假设有一张学生表如下则不满足第三范式
设此表主键为{学号}，所有属性都完全依赖于学号，所以满足第二范式。但学院所在地址也可以通过院系查出，即学院所在地址属性直接依赖于院系，传递依赖于学号。
将它改成两张表
但从姓名属性来考虑，我认为他既可以看作直接依赖于主键学号，也可以看作直接依赖于身份证号，传递依赖于学号，此时它就不满足第三范式。
但数据库设计允许部分冗余，一般要求设计至少达到第二范式，这里可以不做修改。
简单理解：所有非主属性只能通过主键查出，不能通过非主属性查出
三、总结
第一范式要求字段必须具有原子性。——即属性不可再分。第二范式要求非主属性不能部分依赖于码。
——即所有非主属性只能通过主属性的属性集合查询出，不能通过主属性的真子集属性（一个或多个不完全包含于主键的属性）查询出第三范式要求非主属性既不部分依赖于码也不传递依赖于码。
——即所有非主属性只能通过主属性查出，不能通过非主属性查出
如果觉得《数据库设计的三大范式——明确概念和通俗理解》对你有帮助，请点赞、收藏，并留下你的观点哦！
