【MySQL】三大范式（设计理念、优点、不足之处）_数据库设计三范式优劣

  刷完基础视频，对数据库设计范式有了一些了解，也经过了实际动手设计数据库有一些感悟。三大范式，还是只能说出大概，今天就把这个点搞通透。

1.为什么需要范式

  一个软件项目基本都会用到数据库，项目开发前期分析客户的业务和数据处理需求，然后设计数据库的E-R模型图，确认需求信息的正确和完整。再就要将E-R图转换为多张表，表设计后，很可能结构不合理，出现数据重复保存，简称数据的冗余，这对数据的增删改查带来很多后患，所以我们需要审核是否合理，就像施工图设计后，还需要其他机构进行审核图纸是否设计合理一样。
  如何审核呢？需要一些有关数据库设计的理论指导规则，这些规则业界简称数据库的范式。数据库范式为数据库的设计、开发提供了一个可参考的典范。
  那么范式的提出是为了解决什么问题？

• 比如用户表中的地址信息，拆分为省、市这种明确的字段，可以按独立的字段检索、查询。
  第一范式，要求将列尽可能最小的分割，希望消除某个列存储多个值的冗余的行为

• 比如订单表中的商品分类、详情信息，只需要由商品信息表存储一份即可。
  第二范式，要求唯一的主键，且不存在对主键的部分依赖，希望消除表中存在冗余(多余)的列

• 比如用户表中不需要存储额外的 其所在城市的人口、城市特点等信息。
  第三范式，要求没有间接依赖于主键的列，即仍然是希望消除表中冗余的列

很明显，这些范式大都是为了消除冗余而提出的，即尽可能的减少存储成本。

2.什么是范式

  一些约束、规范、规则 来优化数据库表的设计和存储，这些规则就称为范式。前面提到了三大范式的要求是啥，比较官话。下面简而言之并举例。

第一范式

  第一范式(1NF)：数据库表的每一列都是不可分割的原子项。
  假设有一张用户信息表，上面除了用户编号、姓名之外，还会记录地址信息：

在这里面，地址信息一栏就是不符合第一范式(1NF)，因此，应该拆分为：

第二范式

  第二范式(2NF)：就是在第一范式的基础上所有列完全依赖于主键列。
  完全依赖是指不能存在仅依赖主键一部分的列，第二范式要求每个表只描述一件事情，确保表中的每列，都和主键相关。
  以一个订单表为例，通常在淘宝上下单时会产生包含多个商品的订单，如下：

  该订单表符合了第一范式，不符合第二范式。第二范式首先要求的是存在一个唯一的主键，因为表中[商品名称]、[价格]是必须依赖于[订单号]和[商品号]这两个属性的，[订单号]或[商品号]都不能作为主键，必须将[订单号]和[商品号]作为一个复合主键才能满足唯一主键要求。并且这样设定后表中所有列完全依赖于主键列。我们增加一个[商品类别]的属性：

一般[商品类别]属性只与[商品号]相关，即仅仅是依赖于主键的一部分。违反了第二范式中"其他属性必须完全依赖于主键"的规则，因此需要将该属性分离到商品信息表(其它表)中。
  从上述中可以知道，当表中存在一个复合主键包含多个主键列的时候，才会发生不符合第二范式的情况。比如有一个主键有两个列，不能存在这样的属性，它只依赖于其中一个列，这就是不符合第二范式。

第三范式

  第三范式(3NF)：数据表中的非主键列都和主键直接相关，而不能间接相关。同样，第三范式也需要建立在第二范式的基础之上。
  让我们回到一开始的用户表，如果在用户信息表中，同时补充一些城市的信息：

  用户[编号]为主键列，这张表符合1NF、2NF，但不符合第三范式，因为存在间接的传递决定关系：编号->城市->城市特点、城市人口。这里的[城市特点]、[城市人口]属性都仅仅依赖于用户所在的城市，而不是用户[编号]。
  符合第三范式的设计是将城市相关的属性分离到一个城市信息表中。将这张表拆分成用户信息表和城市信息表，[城市]作为前者的外键，后者的主键。

其它范式

  目前关系数据库有六种范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、巴斯-科德范式（BCNF） 、第四范式(4NF）和第五范式（5NF，又称完美范式）。
  满足最低要求的范式是第一范式（1NF）。在第一范式的基础上进一步满足更多规范要求的称为第二范式（2NF），其余范式以次类推。一般来说，数据库只需满足第三范式(3NF)就行了。

3.如何应用范式

  三范式的具体使用上面已经提到，这里想谈一下在实际工作中的数据库设计理念。
  借助三范式的理念，我们可以设计出很精炼的数据库表结构。理解范式是做好数据库设计的一门基础，比如选择合适的主键、清晰的划分每一列属性等等。
  而实际上的项目应用并不会完全遵循范式的理念，原因在于：

1. 性能原因，没有任何冗余的表设计会产生更多关联以至于更多的查询行为，这意味着会产生更多次的数据库IO操作。在一些实时交互的系统中，就会慢得让人难以忍受。
2. 数据存储成本，数据库范式是在20世纪提出的，当时的磁盘存储成本还很高。随着科技发展，数据存储的成本已经大幅度缩减，对于采用范式设计(规避冗余)带来的成本缩减收益已经不那么明显。对一些实际数据库应用，以时间换空间就不那么明智了。

反范式化

  由于数据库的三大范式和数据库的性能有时是矛盾的。没有冗余的数据库设计可以做到。但是，没有冗余的数据库未必是最好的数据库，有时为了提高运行效率，就必须降低范式标准，适当保留冗余数据。
  具体做法是：在概念数据模型设计时遵守第三范式，降低范式标准的工作放到物理数据模型设计时考虑。降低范式就是增加字段，允许冗余，达到以空间换时间的目的。

小结

  三大范式是设计数据库的基本理念，可以建立冗余较小、结构合理的数据库。如果有特殊情况，当然要特殊对待，数据库设计最重要的是看需求跟性能，需求>性能>表结构。所以不能一味的去追求范式建立数据库，为了性能，需要做适当折中，适当牺牲规范化的要求，来提高数据库的性能。

4.总结

  回到主题对三大范式小结

欢迎点赞评论，指出不足，笔者由衷感谢哦！~