要说数据库什么最抽象，我认为是这三种模式。 虽然不太理解，但是表在设计时还必须知道这样的规则。
首先用最简洁的话来说，这三种范式是：
第一范式(1NF:The First Normal Form )各列不能再分割。
如果满足第二范式(2NF:The Second Normal Form ) 1NF条件，则每个列的非主键列可以完全依赖于主键并且不应该仅依赖于联合主键的一部分(主键可以是联合主键
当满足第三范式(3NF:The Third Normal Form ) 2NF条件时，非主键列不能依赖于非主键列；
看了这三个词肯定也听不懂。 那么，用图来理解一下吧
1 .第一范式
简而言之，不能创建以下表格： 您可以看到地址列可以拆分。
一般情况下，用关系数据库创建的表都满足第一正则表达式。
2 .第二范式
请看下表，这里是主键(学校号码、科目)的组合。 只有确定了这两个值，才能确定其他列。 比如分数，如果只靠学号，学号是1的时候，有两个分数，不能唯一确定； 如果只依赖科目，科目为国语时，对应分数也有2分；
请注意上表中的名称。 这只是取决于学校号码，根据学校号码可以找到唯一对应的名字。 因此，此时，非主键列“名字”的部分依赖于联合主键“学校号码、科目”，并不完全依赖，因此不满足第二范式。
我们需要提取名为的列。 下表显示了完全依赖主键的内容位于一个表中，而部分依赖主键的内容位于另一个表中。
3 .第三范式
什么是非主键列不能依赖于非主键列？ 光看不知道.
不要着急。 再看一个表吧。
学部名称可以依赖学号。 毕竟，一个学生肯定对应的是唯一的本科，系主任呢？ 系主任一定取决于系名。 不能依赖某个学生吧。 因此，存在这样的依赖关系。 学号-系名-系主任、系主任间接地依赖主键，这不满足第三范式。
所以我们有必要让系主任出来，单独做表格：
以上是我对范式的理解。 看了几个视频，找了几个博客总结出来吧。 其实可以用更专业的语言来谈范式的转变。 感兴趣的人请看这位老哥哥的博客。 传送门((() )，这是专业的。 哈哈
4 .反三范式
在逻辑上，根据三种模式设计数据库后，可以避免冗余数据，从而简化数据库结构。但是，在这种设计中，查询表时可能需要进行相关查询。 例如，如上所述，在第二范式的情况下，名字不需要分别制作表。
需要单独制作表格，调查学生的姓名、科目和分数时，需要相关调查，但不要单独表格，调查一次就足够了；
因此，适当的冗馀数据是可以接受的，可以提高查询的效率。 3不应该为了遵守范式而制定设计表，而应该衡量自己项目的实际需求，在三种范式和反三种范式之间进行权衡。
我在这里也大致谈了一下我的理解，但一定有什么地方不准确。 哈哈，在实际项目中表格一定非常复杂。 那就要多分析分析了%%%%%%%。