网上查找了一些资料，记录如下并加入自己的理解。
在设计关系数据库时，按照不同的规范要求，设计合理的关系数据库。 这些不同的规范要求被称为不同的范式，每个范式提出以下规范，越高的范式数据库冗余越小。 但是，追求规范化并减少冗馀可能会降低读写数据的效率。 在这种情况下，需要反转归一化，利用空间改变时间。
现在，关系数据库中存储有第一模式(1NF )、第二模式(2NF )、第三模式(3NF )、总线代码模式(BCNF )、第四模式(4NF )、第五模式(55 ) 满足最低要求的范式是第一范式(1NF )。 在第一范式的基础上进一步满足更多规范要求的称为第二范式(2NF )，其馀范式类推如下。 一般来说，数据库只需要满足第三模式(3NF )。 所以这里只记录3范式的相关知识。
3正则形式1NF:字段不能分离；
2NF:有主键，非主键字段取决于主键；
3NF:非主键字段不能相互依赖；
说明：
1NF:原子性字段不能重新分割。 否则，它不是关系数据库
2NF:唯一的表只说明一个东西；
3NF:各列与主键直接相关，无转发依赖；
第一范式(1NF )，即表示列的原子性、不可再分解，即列的信息是不可分解的。 只要数据库是关系数据库(MySQL/Oracle/DB2/Informix/sysbase/SQL server )，就会自动满足1NF。 数据库的每一列都是不可分割的原子数据项，而不是集合、数组、记录等非原子数据项。如果实体中的某个属性有多个值时，必须拆分为不同的属性常见的理解是一个字段只能存储一条信息。
关系数据库： MySQL/Oracle/DB2/Informix/sysbase/SQL服务器
非关系数据库： (特征：面向对象或集合) )。
NoSql数据库： MongoDB/redis (特点是面向文档) ) ) )。
第二范式(2NF )第二范式(2NF ) 2NF )基于第一范式(1NF )而构建，即要满足第二范式(2NF )，必须首先满足第一范式(1NF )。 第二正则表达式(2NF )必须能够唯一区分数据库表中的每个实例或行。 为了实现区分，通常需要设计和实现主键。 主键不包含业务逻辑。
也就是说，满足第一模式的前提，且存在多个主键的情况下，才会发生不符合第二模式的状况。 例如，有两个主键，不能存在这样的属性。 它只取决于其中一个主键。 我的意思是，这不符合第二范式。通俗理解是任意一个字段都只依赖表中的同一个字段(涉及表格拆分)
第三范式(3NF )是第三范式) 3NF )必须首先满足第二范式) 2NF )。 这意味着第三种模式(3NF )要求一个数据库表不包含已经包含在其他表中的非主键字段。 即，表的信息如果能够导出，则不应该单独设计并存储字段(如果能得到外键join，则使用外键join )。 在很多情况下，我们为了满足第三范式往往将一个表分为多个表。
也就是说，满足第二模式的假设，如果一个属性依赖于另一非主键属性，而另一非主键属性依赖于主键，那么该属性间接地依赖于主键，这被称为直通依赖主属性。通俗解释就是一张表最多只存两层同类型信息
反范式中没有冗馀的数据库并不一定是最好的数据库，为了提高运用效率，提高读取性能，有时必须降低范式标准，适当地保存冗馀的数据。 具体来说，在概念数据模型设计中，遵守第三范式，降低范式标准的工作在物理数据模型设计中进行考虑。 降低范式是增加字段，减少查询时的关联，提高查询效率。 这是因为在数据库操作中查询的比例远大于DML的比例。 但反范式要适度，本来要在满足三范式的基础上进行调整。
我知道对范式和反范式的理解：
数据库的设计也应该分为三个领域。
第一个领域，刚进入数据库设计，范式的重要性还没有被深刻理解。 这时出现的反范式设计，一般会引起问题。
第二领域随着面临问题解决，逐渐了解范式的真正好处，可以快速设计低冗馀高效的数据库。
第三境界，再经过n年的锻炼，就会发现范式的极限。 此时打破范式，设计更合理的反范式部分。
范式就像武侠中的一招，初学者妄想着羞于不按招而死。 毕竟，技是总结在沉默中心的精华。 武道进步，技能熟练，必然会发现技能的极限，要么忘记技能，要么自己动手。 只要努力，耐心多年，总是能达到第二境界，觉得范式很经典。 此时，不过度依赖范式，能够迅速突破范式极限的人，自然是沉默的中心。