范式的转变
1NF:字段不可分离；
2NF:有主键，非主键字段取决于主键；
3NF:非主键字段不能相互依赖；
说明：
1NF:原子性字段不能重新分割。 否则，它不是关系数据库
2NF:唯一的表只说明一个东西；
3NF:各列与主键直接相关，无转发依赖；
第一范式(1NF ) )。
也就是说，表的列是原子性的，不可再分解。 即，列的信息是不可分解的，只要数据库是关系数据库(MySQL/Oracle/DB2/Informix/sysbase/SQL server )，就会自动满足1NF。 数据库的每一列都是不可分割的原子数据项，而不是集合、数组、记录等非原子数据项。 如果实体中的一个属性有多个值，则必须将其拆分为不同的属性。 常见的理解是一个字段只能存储一条信息。
关系数据库： MySQL/Oracle/DB2/Informix/sysbase/SQL server非关系数据库3360 (特征：面向对象或集合) NoSql数据
第二范式(2NF ) )。
第二范式(2NF )基于第一范式) 1NF )构建，即要满足第二范式(2NF )必须首先满足第一范式) 1NF )。 第二正则表达式(2NF )必须能够唯一区分数据库表中的每个实例或行。 为了实现区分，通常需要设计和实现主键。 主键不包含业务逻辑。
也就是说，满足第一模式的前提，且存在多个主键的情况下，才会发生不符合第二模式的状况。 例如，有两个主键，不能存在这样的属性。 它只取决于其中一个主键。 我的意思是，这不符合第二范式。 很容易理解的是，所有字段都只依赖于表中的同一字段。 (涉及表格分割)
请看下面的学生选择列表：
学额课程成绩课程学分
10001
数学
100
6
10001
国语
90
2
10001
英语
85
3
10002
数学
90
6
10003
数学
99
6
10004
国语
89
2
表中的主键为(学号、课程)，可以表示为(学号、课程)-)成绩、学分)，表示所有非主键列)成绩、学分)取决于主键)学号、课程)。 但是，表中还有一个依赖。 (课程)-) (以课程为单位)。 这样是非主键列“课程单位‘依赖于一部分主键列’的课程”，所以上表不满足第二范式。
把这个分解成以下两张表。
学生选择列表：
学校号码课程成绩
10001
数学
100
10001
国语
90
10001
英语
85
10002
数学
90
10003
数学
99
10004
国语
89
课程信息表：
课程学分
数学
6
国语
3
英语
2
那么，上面2个表，学生选择表的主键是[学校号码、课程]，课程信息表的主键是[课程]，表中所有的非主键列完全依赖于主键。 不仅符合第二范式，也符合第三范式。
请看这样的学生信息表：
学号名性别班sdhm
10001
张三
男人
一班
mhddy
10002
李四
男人
一班
mhddy
10003
王五
男人
两班
小李
10004
张小三
男人
两班
小李
在上述表中，主键是()学校号码)，所有字段)、姓名、性别、班级、sdhm )是主键)、学校号码)，对主键没有部分依存。 所以就是要满足第二范式。
第三范式(3NF ) )。
要满足第三范式(3NF )，首先必须满足第二范式(2NF )。 这意味着第三种模式(3NF )要求一个数据库表不包含已经包含在其他表中的非主键字段。 即，表的信息如果能够导出，则不应该单独设计并存储字段(如果能得到外键join，则使用外键join )。 在很多情况下，我们为了满足第三范式往往将一个表分为多个表。
也就是说，满足第二模式的假设，如果一个属性依赖于另一非主键属性，而另一非主键属性依赖于主键，那么该属性间接地依赖于主键，这被称为直通依赖主属性。 一般解释是，一个表最多只存储两个相同类型的信息。
反范式
无冗馀数据库并不一定是最好的数据库，为了提高操作效率和读取性能，可能必须降低规范化标准，妥善保留冗馀数据。 具体来说，在概念数据模型设计中，遵守第三范式，降低范式标准的工作在物理数据模型设计中进行考虑。 降低范式是增加字段，减少查询时的关联，提高查询效率。 这是因为在数据库操作中查询的比例远大于DML的比例。 但反范式要适度，本来要在满足三范式的基础上进行调整。