数据库三范式

数据库三范式

开发工具与关键技术：SQL Server 2014 Management Studios
作者：郭海明
撰写时间：2019年6 月 26日

数据库是项目的核心，衡量一个项目的好坏，数据库起到了决定性的作用。如果想要创建出一个好的数据库，那么就要遵循创建数据库的三大范式了。当然，三范式其实是创建数据库最基础的，先在已经不止三范式了，有些数据库已经用到了五范式和六范式。但是对于我们新手来说，肯定是要先遵循三范式，熟悉三范式以后，如果项目需要，就再学习和使用五范式和六范式。
相对应我们新手做的简单项目来说，三范式其实已经完全足够写一般项目了。那么我们接下来就讲讲三范式到底试什么吧。首先我们要理解我们为什么要遵循三范式，数据库的设计范式是数据库所需要满足的规范，如果满足了范式的规范，写出来的数据库才会简洁，结构清晰，在项目里面可以实现插入（新增）、修改和删除，以及以后的项目更新数据库。反之不遵循范式的数据库，结构则很混乱不仅会给数据库的编程人员制造麻烦，而且还会给数据库带来大量不需要的数据冗余信息。所以我们就要遵循范式。
三范式，顾名思义就是三个范式规则，首先我们先写第一范式，就是字段原子性，也就是说数据库表中的字段都是单一的属性，不可以再分。这个单一属性由基本类型构成，包括整形、实数、字符型、逻辑型、日期型等。

就像这个学生表的学生信息，字段都是单一的属性，姓名、学号、身高、体重都是符合第一范式的，如果我们将姓名，拆分为姓、名两个字段，学号拆为学、号，身高拆为身、高、，体重拆为体、重，那么显然就是不符合第一范式了。因为第一范式的字段都是单一属性，不可再分。

在比如像字段3这样，将字段拆分，就是不符合第一范式。当然，在数据库管理系统里面，是不可能做出不符合第一范式的数据库，因为数据库管理系统并不允许你把数据表的一列分为两列或者多列，所以我们一般都不会在数据库做出不符合三范式的数据库的。然后是第二范式， 第二范式是在第一范式的基础上建立起来的，既满足第二范式必须先满足第一范式。第二范式（2NF）要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性，如果存在，那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体，新实体与原实体之间是一对多的关系。为实现区分通常需要为表加上一个列，以存储各个实例的惟一标识。简而言之，第二范式就是非主属性非部分依赖于主关键字。也就是说第二范式要求实体属性不能存在仅以来主关键一部分的属性，如果存在，那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体，新实体与原实体之间是一对多的关系。
就比如我们要在给学生课程，在学生表（学生姓名，学号，年龄）里面添加课程的信息，将学生表添加为（学生姓名，学号，年龄，课程名称，成绩，学分），很显然，这样直接在学生表里面添加课程的内容是不符合第二范式的。
数据冗余，因为同一门课程由n个学生选修,“学分”就重复了n次，同一个学生选修了m门课程，姓名和年龄就重复了m次，这就是不符合第二范式所带来的数据冗余。不符合第二范式不仅会导致数据冗余，
还会导致数据库的更新异常.如果我们调整了某门课程的学分，数据库表中所以的学分都要更新，就会出现同一门课程学分不同的情况了。
还有插入的异常，如果我们想要添加一门新的课程，由于还没有人报名这个课程，所以没有“学号”这个关键字。所以课程名称和学分也无法记录进数据库里面，这就导致了插入的异常了。
删除异常：如果有一批学生已经完成了课程的选修，这些选修记录就应该从数据库里面删除，但是，如果将该学生表的学生删除，和他相对应的课程和学分也会被删除，所以，也会导致删除的异常。
正确的方法就是我们应该把这些关系建为三个表：
学生表（学号 姓名 年龄）
课程表（课程名称 学分）
选课关系表（学号 课程名称 成绩）
这样就符合了第二范式，消除了数据的冗余、跟新的异常、插入异常和删除异常。另外，所有单关键字的数据库都符合第二范式，因为不可能存在组合关键字。
接下来就是第三范式了，在第二范式的基础上，，数据表众如果不存在非关键字段对任一候选字段的传递函数依赖则符合第三范式。
个人理解为并不属于表一的关键字段，而是表二的关键字段，就不能将表二的关键字段直接写在表一里面，这样就属于不符合第三范式。
比如学生表（学号、姓名、年龄、学院、学院地址、学院电话）这个表就不符合三范式，因为学院的地址和学院的电话并不属于学生表，所以我们需要创建两个表：
把他们分为 学生表（学号ID 姓名 年龄 学院ID）
学院表（学院ID 学院名称 学院地址 学院电话）
这样就符合第三范式了。
这就是数据的三大范式，当然有些时候我们并不需要遵循数据库的三大设计范式，但是当我们还没有成为数据库大神的时候，最好还是要遵循三范式，因为这并没有坏处。