【一文秒懂】带你彻底搞懂范式与反范式数据库设计

小伙伴们对数据库编程感兴趣吗？是否正在学习相关知识点？如果是，那么本文《【一文秒懂】带你彻底搞懂范式与反范式数据库设计》，就很适合你，本篇文章讲解的知识点主要包括MySQL、数据库、后端、数据库设计、范式。在之后的文章中也会多多分享相关知识点，希望对大家的知识积累有所帮助！

范式

1NF 第一范式

啥玩意是不再可分？例如用户名、性别、年龄联系方式则就是不能再分了。
但例如城市，北京市通州区，我们还是可以再分的，将一个字段分为省：北京市 区：通州区

首先，我们看到用户信息表中，所在城市是可以在进行细分的。

下表我们根据上述用户信息表，将城市分为省和市两个字段，这样设计后，该数据表则符合了第一范式的要求。

我们再以商品表做一个说明

依旧是依照上述规则，首先我们找到已无法再次分割的属性

现在不可再分割的属性有 编码、价格（以只有RMB为准）、库存，而商品名称及制造工厂想必大家也知道，这是可以再分的属性吧，那么看下方符合第一范式的数据表设计

我们将商品名称与制造工厂进行以下的拆分，以达到不可再分的属性

其关系模式为：

商品名称（品牌,型号,颜色）
制造工厂（制造工厂所在城市,制造工厂名称）

看到这里，想必你已经搞懂第一范式的设计规则了，那么我们继续第二范式的学习。

2NF 第二范式

遵循的规则：首先必须符合第一范式要求，其次一个表中只能保存一种数据,确保每一列都与主键相关，我们以课程编码为主键，除课程名称以外的其他信息与主键无关，所以我们只需要独立课程编码与课程名称，其他则新建一张表。

课程表

老师表

这样拆分后，我们就符合了第二范式的要求，并且也符合第一范式的要求，没有可再分的属性。

我们再以上述符合第一范式的商品表为例

这里以编码和品牌为联合主键，与主键无关的属性新建立一张表。

生产商表

商品表

这样既符合了第二范式要求。

我们已经对第二范式有了一个大概得了解，不要停，第三范式在等你！

3NF 第三范式

遵循的规则：要先符合第二范式的要求，并且除主键列的其它列之间，不能有传递依赖关系。

这里先解释下，啥是传递依赖，以下列订单表为例 ，我们通过订单编码可以查到商品名称，但通过商铺编码也可以查找到发货仓及联系方式。既订单编码->发货仓，商铺编码->发货仓，这则产生传递依赖，通俗点讲究是如果除了主键（订单编码）外，不能再有有属性相关的非主键（商铺编码|发货仓），我们只能通过主键查到所有信息，达到独占的情况，意味着下条SQL语句不能让他有效，则就达到了第三范式的要求。

SELECT 发货仓,店铺电话 FROM 订单表 WHERE 商铺编码 = S1

根据下述拆分达到第三范式要求

订单表

商铺表

刚刚讲到第三范式一定满足第二范式，而第一范式一定满足第一范式，那么我们看下刚刚拆好的订单表

1. 无再可拆分的属性，符合第一范式。
2. 无与主键无关属性，符合第二范式。
3. 无传递依赖关系，符合第三范式。

所以说，当你符合第三范式时，你实际已经符合了第一第二范式，那么关系型数据库的三大范式我们就讲到这里，数据中可能有些歧义，请理解原理，勿细纠结，谢谢。

反范式设计的目的

当然范式只是提出的规范，但一些特殊情况下，我们要考虑的点比较多，例如

1. 并发读。
2. 减少表关联次数。
3. 数据表的冗余设计。
4. 热数据与冷数据。
5. 数据的非实时性。

这里与三大范式做一个对比（个人见解）

• 减少表关联次数 = 违反了第二范式
• 数据表的冗余设计 = 违反了第三范式

当然也不是一概而论，这里以订单表为导向，来讲解一下为什么我们会迫不得已违反范式规则。

用户下单后，商品的基本信息如果进行表关联的方式，既订单表的商品编码关联商品表的编码，会出现什么问题？

大概会出现这样一个问题：

用户购买了一台HP打印机1999元后，商家对当前这个商品进行了修改，改为了一台华硕笔记本，那么通过表关联（设符合范式规则），用户会不会疯掉？

那么如何解决这一问题？

这就使用了我上述提出的数据的冗余设计，将商品基本信息直接存入订单表中，这是根据常识而定的，就跟你去商场买了一个西瓜花了20元，次日这个西瓜无论涨价还是降价，商场不会要求你补足差价，你也无法要求商场返还差价（当然这与某东买贵包赔无关，不要较劲）。

那么在互联网的时代，当你下单的那一时刻，你购买的商品信息则就已经固定，无论商家是修改商品，还是删掉商品，或者商家倒闭了关闭店铺。你购买的商品永远会在你的订单内看到，当然如果商品失效，你在点击进入后，某宝可能会给到你一个快照，这个快照依旧是在你下单时保存的数据。

你现在应该可以理解，为什么需要反范式，类似的例子还有很多，我在我的电商设计相关文章内有多次提出类似的需求，至此我就不一一例举了

当然在正常情况下，你依旧需要根据三大范式去设计你的业务，这是行业规范，只有规范统一，你才不会太“坑”你的接锅班人。

那么反范式设计的优点有哪些呢？

1. 提高查询速度。
2. 避免多表查询。
3. 降低数据库的压力。

反范式应该注意的问题

1. 过多冗余数据导致存储量过大。
2. 必要时需配合内存数据库实行。
3. 违反了范式规则，会出现插入异常、查询异常等。

致谢

感谢你看到这里，希望本篇可以帮助到你，谢谢。

文中关于mysql的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《【一文秒懂】带你彻底搞懂范式与反范式数据库设计》文章吧，也可关注golang学习网公众号了解相关技术文章。