写在开头
在明白了多种依赖理论后，应该想到在数据库中存在哪些依存关系，那在设计过程中我们应该如何避免数据库的一致性问题？这就是数据库规范性设计的重要性。
这里学到关系范式，那什么是关系范式呢？课本中给出的定义是这样的“符合某一种级别的关系模式的集合，表示一个关系内部各属性之间的联系的合理化程度”，那其实简单来说就是一个表示设计表时某种规范化设计标准的级别而已。
第一范式
如果关系R中的属性值都是不可再分的最小数据单位，则称为第一范式，记为R∈1NF。符合第一范式的属性都是“不可再分的”，每行每列都是单一的。（当通过面向对象的数据模型时可以运行多行多列的，通过封装等方法可以解决这种问题）
第二范式
若R中每一非属性组都完全依赖于R的候选键，且R∈1NF，则称为第二范式，R∈2NF。
在这个定义中，有这些重点：每一非主属性、完全依赖
第二范式的作用主要是消除了非主属性对候选键的部分依赖，让存在部分依赖的关系拆分为一个个没有部分依赖的关系
第三范式
要判别一个关系R是否为3NF，那么可以进行一下步骤：
①找出候选码和非主属性
②看看是否存在非主属性对候选码的部分函数依赖，若存在，说明不是2NF，也就不会是3NF，否则进行下一步。
③判断非主属性间是否存在函数依赖，若不存在，则是3NF。
那看起来第三范式比较复杂，但其实实质上是要求没有传递依赖的关系，那就是满足第三范式的。
关于如何让关系符合第三范式，其实是可以直接粗暴的将关系集合拆解为几个简单的小关系，再简单合并。当然，，这就很粗暴emmmm
⭐通过前面三个范式我们发现第二和第三范式只是将非主属性对候选码部分函数依赖和传递函数依赖消除了，但并未消除主属性本身对候选码的部分函数依赖或者传递函数依赖，所以后来就有人提出了3NF的改进形式：BCNF。
BCNF范式
Boyce-Codd范式，是作为3NF的补充说明提出的，比3NF更为严格。它的定义是这样的：设关系模式R<U，F>∈1NF，如果对于R的每个函数依赖X→Y，若Y不属于X，则X必含有超码，那么R∈BCNF。
当然，好像关于集合论的每一个定义都显得那么复杂难懂（当然我是这样认为的hhhh）.....但简单通俗来讲，就是满足BCNF的关系范式要满足：关系模式内所有关系依赖都是依赖与候选键的。换而言之，满足这个范式的模型中是没有不依赖于候选键（全部）的函数依赖存在的，这个成为了我们判断BCNF范式的常用依据。
这种范式消除了主属性本身对候选码的部分和传递函数依赖，也就解决了上面的那个问题。
配合例题实用更香喔
那么关系范式如何分解为BCNF范式呢：我们找到一种方法是将左边不含候选键的函数依赖单独组成一个关系，将包含候选键的组成一个关系
例子如下：
多值依赖的第四范式
多值依赖定义：
当然都会觉得书面定义不是什么人话....但是看例自可能会理解一点，要知道一点当例中u和v（1、2、3、4行）要同时存在才满足多值依赖。也就是说两个元组中x属性相同，交换y属性的值得到两个新的元组，新的元组还属于关系r就符合多值依赖。
多值依赖特性：
如例子：
第四范式：
简单来说，第四范式消除了非主属性对候选键以外的多值依赖，如果有多值依赖，则一定依赖于候选键，该条件成为了判断是否为第四范式的常用依据
总结
这一篇主要运用上一篇中讲述的函数依赖和各种概念来定义了什么是关系范式，那么何为范式，其实就是规范的形式，在进行数据库设计的时候我们最基本的要求是要保证我们的关模式是符合第三范式或BCNF范式的。
第四范式比较困难，一般不要求应用emmmm
