共计 2127 个字符，预计需要花费 6 分钟才能阅读完成。
这篇文章将为大家详细讲解有关如何进行数据库三大范式的分析，文章内容质量较高，因此丸趣 TV 小编分享给大家做个参考，希望大家阅读完这篇文章后对相关知识有一定的了解。
一：引言
作为一个数据库的学习者，搞懂关系数据库的三大范式是很有用的。然而教科书上有关数据库范式的介绍都是采用学术性的定义，语法羞涩，让人难懂，故写下自己对数据库范式的理解，给初学者提供帮助，也备日后查看。下面不介绍规范化程度高于 3NF 的范式，因为其在实际应用中基本不会用到，原因也是很明显的（查询代价变大），因此，对于很多大型复杂的系统，其数据库设计都没有遵循所谓的范式，这也是为什么会出现所谓的逆规范化，好了，进入正题吧。
二：范式介绍
a：第零范式
第零范式就是指没有使用任何范式的设计，其添加数据的行为非常诡异，看看下表便知：
假设一个学生学习了三门课程，每门课程都有成绩，那么，采用第零范式的设计将会是如下情况
表 a_0
这样的话，会使得往表中添加数据变得非常麻烦，每次添加一个新的数据，都要添加相应的字段，而且，因为表中其他的记录可能不需要这么多字段，因此会浪费
很多空间。如表 a_1 所示。
表 a_1
由此可以看出，不对数据库任用任何范式是非常愚蠢的，因为不仅会产生大量无用的表字段，而且会使得表结构非常难以维护。由此，引出第一范式的介绍
b: 第一范式
第一范式就是在第零范式的基础上进行的改进，网上有很多人认为，所谓第一范式就是指表中的所有字段都是原子的、不可再分的，我个人认为此种理解也是正确的，原因不解释，我对第一范式的理解是，将
第零范式中重复的字段抽取出来，作为表的数据，从而形成一个稳定的、冗余数据少得表结构。
由此，可以得出符合第一范式的表结构应该是：
此时，表的结构变得稳定了，而且表中的冗余信息相对第零范式也少了很多。可是，第一范式只是关系数据库设计的最低满足的范式，第一范式中仍然有很多的冗余信息，由此，需要引入第二范 式。
c: 第二范式
第二范式是满足属性对主键是完全函数依赖的，因此，满足第二范式的表当然也是满足第一范式的，第二范式的目的就是消除表中的部分依赖。
这里，有几个概念要解释下，
1：完全函数依赖
设有属性集 K 和 P，若 K 中的所有属性共同能够推出 P 中的任意属性，且对于 K 的任何真子集，都不能推出 P 中的任意属性，则成 K 完全函数依赖 P。
2：部分函数依赖
与上相似，只是，K 中存在真子集使得，该子集能推出 p 中任意属性。
概念性的东西，往往都难懂，举个例子，方便大家理解：
假如有一张学生成绩表，包含如下属性 (学生 Id，课程 Id，课程分数，学生名字)，其中，主键为 (学生 id，课程 id)，表中的数据如下：
那么，此时这张表的设计就不满足第二范式， 因为 主键 (学生 id，课程 id) 能够唯一确定学生的姓名，因此，不满足属性完全函数依赖主键，因此不是第二范式。
从上面的表数据易知，不满足第二范式的表至少有以下几个缺点：
1：数据重复，浪费空间，因为每存一条记录，都要存学生的名字，这样就是得存在大量重复的数据。
2: 插入异常，若学生还没有成绩，那么这个学生就没有名字。
3： 更新异常，删除异常等
解决方法：
将 student_name 字段放入学生表中，即消除表中的部分依赖。
d: 第三范式
第三范式是指在满足第二范式的情况下，消除表中的传递依赖。
所谓传递依赖，就是指 x – y,y– z, 那么可以得到 y – z.
传递依赖常发生在主键、外键、外键相关的属性上，例如，假设有这样的表
学生表 (学生 id，学生姓名，院系 id，院系名) ，此处主键为（学生 id），外键为 (院系 id)
院系表 (院系 id，院长名称)，主键为（院系 id）
很明显，此处存在传递依赖，因为 学生 id 可以唯一确定 院系 id，而 院系 id 可以唯一确定 院系名。
表中的数据如下
从上面的表数据易知，不满足第三范式的表至少有以下几个缺点：
1： 数据重复，浪费空间，因为学生表每存一条记录，都会记录住院系的名字，存在大量的重复数据。
2： 插入异常，若新建一个院系，而该院系没有学生的话，该院系就没有名字。
3： 更新异常，删除异常等
三：数据库设计的经验
1: 表的数目不要太多，一般 20-30 张就够了。如果表的数目太多，则可以考虑采用同化操作，即将大体相同的实体放入到一张表中。
2：当数据库中的信息非常庞大时，不要使用外键 (逆规范化)，因为由此可能带来非常大的性能损失。
3：一般以消耗存储空间来换取效率。
关于如何进行数据库三大范式的分析就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。
