软考详解---三范式
关系型数据库是现在广泛应用的数据库类型，对关系型数据库的设计就是对数据进行组织化和结构化的过程。对于小规模的数据库我们处理起来还是比较轻松，但是随着数据库规模的扩大我们将发现用户操控数据库的SQL语句将变得笨拙、复杂。更糟糕的是很有可能导致数据不完整，不准确。所以我们有必要将数据设计的更加符合规范。怎样使我们的数据库更加规范呢，在数据库的世界里一共总结了五个范式，常用的有三个，今天小编就简单的总结一下三范式，三范式的内容也是软考中必考内容，希望对小伙伴们有帮助，小编会首先简单的介绍一个各个范式的概念，接着举一个小例子对各个范式进行讲解说明。
第一范式
首先，我们来看第一范式的定义：（1NF）是指数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。我们来看一个例题：
例题：职工号、姓名、电话号码组成一个表（一个人可能有一个办公室电话和一个家里电话号码），如何将其规范为1NF。我们来分析一下这个例题，职工号、姓名、电话号码组成一个表，一个人可能有一个办公室电话和家里电话号码，我们要把这个表规范为第一范式，有三种方法，首先我们需要提出的是，这个表是不符合第一范式的，为什么nie，他的电话号码还分了子项，电话号码分了办公室电话和家里电话号码，这样电话号码这个项他就不是一个不可分割的项，要把这个表规范为第一范式，我们有三种方法，第一种是重复存储职工号和姓名，即每个人的一个电话号码占用 一条记录，这样，关键字只能是电话号码。第二种方法，以职工号为关键字，电话号码分为单位号码和住宅电话。第三种是以职工号为关键字，但强制每条记录只能有一个电话号码，三种方法，可以将其规范为第一范式，第一种方法最不可取，按实际情况可选取后两种情况。我们再来看一个关于规范第一范式的例题，如下图所示：
vczK2rrNuLG9zMrawb249sr00NS8tL/Jo6zI58/Cy/nKvqO6PC9wPgo8cD4gICAgICAgPGltZyBzcmM9"http://www.2cto.com/uploadfile/Collfiles/20150518/2015051809330334.png" alt="\">
第二范式
我们来看第二范式的概念：2NF，当且仅当实体E是第一范式，且每一个非主属性完全依赖主键（没有不完全依赖时），则称实体E是第二范式。我们来看一个例子：
选课关系SC1(SNO，CNO，GRADE，CREDIT)中SNO为学号，CNO为课程号，GRADEGE为成绩，CREDIT为学分，由以上条件的关键字为组合关键字（SNO，CNO），我们来分析一下上面的这个问题，有一个选课关系sc1，里面有四个字段，这个关系的主键是sno和cno的组合，也就意味着这个组合可以确定成绩和学分，我们写出所有函数依赖SNO CNO ---GRADE/CREDIT，除此之外，是不是还有其他的呢，我们可以发现GREDIT是学分，然而一门课程的学分只要课程号确定了学分肯定能确定，因为课程的学分是固定的，所以还有一个函数依赖，cno可以确定credit，所以这里存在部分函数依赖，因为主键的一部分就可以确定credit这个属性，这样就产生了部分函数依赖，在实际应用中，这样一个关系存在问题，如下所示：
我们再来看一个例题，如下所示：
分析一下数据的内部结构，这个表中包含四个属性，仓库号和设备号有可能是这个表中的主键，我们发现仓库号有重复的元素，所以她不能够是主键，设备号也存在这种情况，所以只能将二者拼合作为主键，我们发现其中没有重复的数据项了，并且每一个项能够确定数量和地点，所以我们选定这两个组合作为数据表的主键，我们在看其他的对应关系，这样才能判断是否满足第二方式，仓库号和地点之间是否有关联，发现比如wh1所对应的地点都是北京，我们可以得到一个函数依赖，仓库号对应着地点，产生了部分函数依赖，我们刚才已经确定了仓库号和设备号的拼和是主键，这个时候有出现了仓库号可以确定地点号，所以不满足第二范式，so
第三范式
首先我们来一起了解一下第三范式的概念：当且仅当实体E是第二范式，且E中没有非主属性传递依赖于码时，则称实体E是第三范式，我们来看一个例题：
如S1(SNO、SNAME、DNO、DNAME、LOCATION）各属性分别代表学号、姓名、所在系、系名称、系地址。关键字SNO决定各个属性，由于是单个关键字，没有部分依赖的问题，肯定是2NF，但这关系会有大量的冗余，有关学生所在系的几个属性DNO、DNAME、LOCATION将重复存储，在插入和删除、修改时也将产生类似于上例的情况。我们来分析一下这个问题，如果某个关系模式他的关键字，他的主键是单关键字，而不是多个关键字的组合，那么这一个关系模式至少是第二范式，原因就是他是单属性，所以不存在部分函数依赖。
产生上述错误的原因：关系中存在传递依赖造成的，即SNO-->DNO，而DNO-->SNO却不存在，DNO-->LOCATION，因此关键字SNO对LOCATION函数决定是通过函数依赖SNO-->LOCATION实现的，也就是说，SNO不直接决定非主属性LOCATION。原因是关系中存在传递依赖造成的，比如说，在这样一个数据表中，sno确定dno，这是因为非主属性依赖于我们知道一个学生的学号以后，可以知道他所在系的，、系号，但是我们知道一个系号却不能够确定学生的学号，因为一个系有多个人，同时系号能够确定系所在的位置，这样一些条件组合起来，就满足了传递函数依赖的一个条件，所以就形成了sno到loction的一个传递的函数依赖，也就是说Sno不直接决定非主属性location，这样这个关系模式他就不符合第三
范式了。现在我们来寻求一种解决方法，消除数据冗余，以及插入、删除、修改有可能出现的错误，要解决这个问题，必须要把所有的传递函数依赖给消除掉，我们可以把这个关系模式拆分为两个，应该是这个样子滴：S（SNO，SNAME，DNO），D（DNO、DNAME、LOCATION）这样两个关系模式都符合第三范式了，但是我们需要注意的是，关系S中不能没有外关键字DNO，否则两个关系之间会失去联系，在关系数据库中，除了函数依赖之外还有多值属性，联接依赖的问题，从而提出了第四范式，第五范式等更高一级的规范化要求。我们再来看一个例题，如下所示：
我们来分析一下，有四个字段，这一个仓库表中，有哪些函数依赖关系呢，我们来看，一个所在省，一个所在城市，他们之间是有关联的，如果我知道了所在城市就能够确定所在省，这是唯一确定的，然而我们知道仓库号的话，要能够知道仓库所在的城市，这样子也产生了一个，但是你知道仓库所在的城市，你不一定知道仓库号，因为所在城市所在城市武汉就有三条记录，但是武汉这个城市就有三个仓库，这样的话，所在城市是不够确定仓库号的，综合这些条件，产生了一个传递函数依赖，就是所在省传递依赖函数仓库号，我们要将其规范为第三范式就要打破这种局面，我们要怎么做nie，如下所示：
系统原理中已经相遇过了，但是对于三范式一直是稀里糊涂的，这次在软考中，再次遇见了数据库的三范式的相关内容，小编把相关的知识总结成博文，希望对有需要的小伙伴有帮助，然考之路，未完待续......