本文将详细解释如何分析数据库的三种范式。文章内容质量很高，所以边肖会分享给大家作为参考。希望大家看完这篇文章能有所了解。
一： 引言
作为一名数据库学习者，了解关系数据库的三种范式非常有用。但是教材中引入的数据库范式都是学术定义，语法比较腼腆，让人难以理解。所以，写下你对数据库范式的理解，给初学者提供帮助，为以后参考做准备。下面我就不介绍规范化程度高于3NF的范式了，因为在实际应用中基本没有用到，原因很明显(查询成本变大)。因此，对于许多大型复杂系统，数据库设计并不遵循所谓的范式，这就是为什么会出现所谓的反规范化。好了，让我们言归正传。
二： 范式介绍
a：第零范式
零范式是指不使用任何范式的设计，其添加数据的行为非常奇怪。看下表。
假设一个学生学习了三门课程，每门都有得分，那么第零范式的设计将如下： .
表A0
这样，向表中添加数据会非常麻烦。每次添加新数据，都要添加相应的字段。而且，因为表中的其他记录可能不需要这么多字段，所以会浪费掉。
很大的空间。如表a1所示。
表a_1
由此可以看出，不对数据库任用任何范式是非常愚蠢的，因为不仅会产生大量无用的表字段，而且会使得表结构非常难以维护。由此，引出第一范式的介绍
b: 第一范式
第一范式是基于第零范式的改进。网上很多人认为所谓的第一范式是指表中所有字段都是原子的，不可分割的。个人认为这个理解是正确的，原因没有说明。我对第一范式的理解是
第零范式中的重复字段被提取为表数据，从而形成具有较少冗余数据的稳定表结构。
因此，可以得出符合第一范式的表结构应该是：
此时，表的结构变得稳定了，而且表中的冗余信息相对第零范式也少了很多。可是，第一范式只是关系数据库设计的最低满足的范式，第一范式中仍然有很多的冗余信息，由此，需要引入第二范 式。
c: 第二范式
第二个范例是满足属性完全依赖于主键的功能。因此，满足第二范式的表肯定满足第一范式，第二范式的目的是消除表中的部分依赖。
这里有几个概念需要解释，
1.完全功能依赖
nbsp; 设有属性集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：一般以消耗存储空间来换取效率。
关于如何进行数据库三大范式的分析就分享到这里了，希望
内容来源网络，如有侵权，联系删除，本文地址：https://www.230890.com/zhan/131405.html