开头先讲讲概念
计算机相关专业科班出身的同学们肯定都学过数据库原理，在数据库原理中肯定会学关系代数，学到范式部分的时候，都会通过关系代数来解释什么是范式。
估计大部分人学的时候理解了，过不了多久，这样的概念用得不多自然也就忘了。
凡是跟数学有关的内容估计都会有种不明觉厉的感觉？
暂且不说关系代数，用一种不烧脑的方式再来看看范式吧。
进行范式化的目的：
去除冗余和提高灵活性！去除冗余和提高灵活性！去除冗余和提高灵活性！
那么问题来了什么是冗余，怎么去除冗余呢？
冗余（Redundancy）就是数据的重复，范式的目的是去除冗余，但，不是将重复的数据变成零，而是，通过关联的方式，保留最少的关联信息之后，将冗余降低到最少。
还有一个问题是如何提高灵活性？
在去除冗余的过程中，建立的关系，通过数据和数据之间进行关联和设计的方法来提高灵活性。
范式有哪些？
理论上范式分为第一范式、第二范式、第三范式、BCNF范式、第四范式和第五范式。
这样的理论就不具体说了，百度或者谷歌吧。
实际在数据模型设计的过程中，做到第三范式就OK了，记住这点就行。
具体讲讲各种范式
第一范式：解决冗余数据组（Repeating Group）
先看一组数据。
客户编号是这张表的主键，保证每个客户的唯一性。
兴趣爱好的种类很多，每个人有很多个爱好，每个爱好都被放进了一个属性里面。
如果某个人又多了一个爱好的话怎么办？“再添加在现有爱好的后面，更新进去”？
现在兴趣的数量少而且长度短，如果哪个人爱好特别多，并且说明的内容特别长，组合起来超过了这个属性的长度了咋办？又如何保证每个人同种兴趣爱好只放一次呢？
从计算机处理和存储的角度来看，会有很多问题。
怎么办？
像图里一样，把一个属性里只放一个兴趣，每个属性单独再复制一份兴趣爱好信息，这样的话，100个属性也不怕。
好吧，这样做的话不用我说，也能看出问题吧？100个兴趣爱好，同一个人的信息就得重复100遍。而且，客户编号也无法保证数据的唯一性。
解决方案如图：
把兴趣爱好单独放一张表里，每个人的信息也都放在一个表里，通过一张关系表，建立客户和兴趣爱好的关联性，这样是不是不但提高了灵活性，也解决了冗余问题？
在数据模型中形态的变化如下。
第二范式：解决部分依赖现象（Partial Dependency）
第二范式的前提是满足第一范式并且表中存在组合键（两个属性组合起来，一起作为主键使用）。
部分依赖现象用一句话来说是：表中的非主键字段不仅全部依赖于主键，其中的一部分字段还依赖于组合主键中的一部分。
依赖的意思是指能够被唯一识别。通过主键能够唯一地识别每一行数据，也就可以说表中的非主键字段依赖于主键。
理论总结完了，看看数据吧。
客户表里的主键是客户编号，订单表里面的主键是订单编号和商品编号（一个订单可以包含多个商品）。
好吧，客户张三的编号是CUST0001，所以，可以看出来这三个商品都是张三买的，如果张三买了100个不同的商品的话，请问仅仅和这个订单相关的信息（如购买数量，订货时间，订货人，当然实际上还有其他更多的属性）是不是就得重复100遍？
再看看这张表的主键是订单编号和商品编号，通过这两个属性就能保证表中每一行数据的唯一性，但是，商品名称和商品描述其实并不需要同时依赖这两个属性，也就是说只要有商品编号这一个主键，就能保证商品名称和商品描述这两个属性的唯一性。换句话说，其实产生数据冗余的原因也就是因为把两张表合到了一张表。
相信到这一步理解的话，怎么解决也就明白了，拆拆拆~
这样的结构，即使张三买一万个商品，商品名称和商品描述信息都不会冗余。
在数据模型中形态的变化如下。
第三范式：解决传递性函数依赖现象（Transitive Dependency）
第三范式的前提肯定是满足前两个范式，第二范式解决的是部分依赖问题，而第三范式要解决的叫传递依赖问题。
想想在学校里选课的场景，从表里能看出来，张三选了三门课，李四选了一门课。
选课表里面的主键是学生编号和序号，通过这两个字段就能保证每行数据的唯一性。
可以看见表里每一门课的课程名称也都放在这张表里面，如果有课程说明相关的内容也都放在这里的话，学生选几门课都会把所有的信息都放在这里。张三和李四都选了“数据结构和算法”这门课，如果100个学生都选这门课的话，是不是这门课程相关的信息就会被重复存储100遍？
解法也很简单，拆拆拆呗~
把课程相关的信息单独拿出来，选课的时候只保存课程编号，这样的话，所有的课程相关信息都只保留一次，课程想怎么选就怎么选~
在数据模型中形态的变化如下。
整理一下三种范式的规律
第一范式要解决的是如下状态：
A为主键，A能够保证数据唯一性，但是，其中有一个字段中保存了A1,A2,A3这样的数据。
第二范式中说的部分依赖如下：
A和B为组合键，共同保证数据的唯一性，但是其中D可以单独依赖主键中的B来识别。
第三范式中的传递性依赖示例如下：
A和B为组合键，共同保证数据的唯一性，但是其中E可以单独依赖非主键属性C来识别。
A+B => C, D, E 的同时 C => E，这样的关系就被成为传递性依赖。
总结一下
通过范式化，可以最大程度上消除数据中的冗余，仅仅保留他们之间的关联性。
这是关系型数据库中最基本的原理知识，在数据模型设计的过程当中，按照设计方法论，可以最大程度上使数据达到这样的状态，这也是逻辑模型设计过程中，必需的过程。
还有一个和范式化紧密联系的理论知识也很重要，就是通过范式可以解决数据的变更异常（Modify Anomaly）现象，其中包含插入异常（Insertion anomaly）、更新异常（Update anomaly）、删除异常（Deletion anomaly），道理其实很简单，去除冗余之后就能够保证同样的数据不会被分散存储到多个地方，这样的话，不管是插入、更新还是删除都可以只针对一个地方做变更就可以了，如果不这样的话，每次变更就需要变更分散在各个地方的数据，无法严格地保证数据的一致性，还得通过其他手段去做。
逻辑模型设计的前期，通过这样的手段保证数据模型遵守最基本的规则。但是，在模型设计的后期，会考虑到性能和使用的便利性，通过反范式的手段，适当地增加冗余，反范式的方法和设计的方法以后再说吧。
