Mysql的三范式设计和反范式设计

范式

• 利用规范化理论，是关系模式的函数依赖集满足特定的要求，满足特定要求的关系模式成为范式

第一范式
第一范式（1NF）要求数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值。
若某一列有多个值，可以将该列单独拆分成一个实体，新实体和原实体间是一对多的关系。
在任何一个关系数据库中，第一范式（1NF）是对关系模式的基本要求，不满足第一范式（1NF）的数据库就不是关系数据库。

第一范式是最基本的范式。如果数据库表中的所有字段值都是不可分解的原子值，就说明该数据库表满足了第一范式。

第一范式的合理遵循需要根据系统的实际需求来定。比如某些数据库系统中需要用到“地址”这个属性，本来直接将“地址”属性设计成一个数据库表的字段就行。但是如果系统经常会访问“地址”属性中的“城市”部分，那么就非要将“地址”这个属性重新拆分为省份、城市、详细地址等多个部分进行存储，这样在对地址中某一部分操作的时候将非常方便。这样设计才算满足了数据库的第一范式。

第二范式
满足第二范式（2NF）必须先满足第一范式（1NF）。
第二范式要求实体中没一行的所有非主属性都必须完全依赖于主键；即：非主属性必须完全依赖于主键。
完全依赖：主键可能由多个属性构成，完全依赖要求不允许存在非主属性依赖于主键中的某一部分属性。
若存在哪个非主属性依赖于主键中的一部分属性，那么要将发生部分依赖的这一组属性单独新建一个实体，并且在旧实体中用外键与新实体关联，并且新实体与旧实体间是一对多的关系。

第二范式在第一范式的基础之上更进一层。第二范式需要确保数据库表中的每一列都和主键相关，而不能只与主键的某一部分相关（主要针对联合主键而言）。也就是说在一个数据库表中，一个表中只能保存一种数据，不可以把多种数据保存在同一张数据库表中。

第三范式
满足第三范式必须先满足第二范式。
第三范式要求：实体中的属性不能是其他实体中的非主属性。因为这样会出现冗余。即：属性不依赖于其他非主属性。
如果一个实体中出现其他实体的非主属性，可以将这两个实体用外键关联，而不是将另一张表的非主属性直接写在当前表中。

第三范式需要确保数据表中的每一列数据都和主键直接相关，而不能间接相关。

什么叫做反范式化设计

不满足范式的模型，就是反范式模型。

	反范式化是针对范式化而言的，在前面介绍了数据库设计的范式，所谓的反范
	式化就是为了性能和读取效率的考虑而适当的对数据库设计范式的要求进行违
	反，而允许存在少量的数据冗余，换句话来说反范式化就是使用空间来换取时
	间。

反范式跟范式所要求的正好相反，在反范式的设计模式，我们可以允许适当的数据的冗余，用这个冗余去取操作数据时间的缩短。本质上就是用空间来换取时间，把数据冗余在多个表中，当查询时可以减少或者是避免表之间的关联；

两者的对比

范式化模型
		数据没有冗余，更新容易	
		当表的数量比较多，
		查询设计需要很多关联模型（join）时，会导致查询性能低下


反范式化模型	
	数据冗余将带来很好的读取性能
	（因为不需要join很多表，而且通常反范式模型很少做更新操作）
	需要维护冗余数据，从目前NoSQL的发展可以看到，
	对磁盘空间的消耗是可以接受的