设计范式

问题： 什么是范式化设计，为什么需要反规范化设计 ？

范式来自来自英文 Normal From 。开发过程中要设计一个好的数据库逻辑关系，必须满足一定的约束条件，此约束条件形成了开发范式，分成几个等级，一级比一级严格。

满足这些范式理论上可以让我们的数据库逻辑结构更加简洁、清晰。一下是常见的四种范式：

• 第一范式（1NF）
• 第二范式（2NF）
• 第三范式（3NF）
• 第四范式（BCNF）

第一范式（1NF）

1. 每一列都是不可再分的属性值，确保每一列的原子性；
2. 两列的属性相近或者相似或者一样，尽量合并属性一样的列，确保不产生冗余数据；
3. 单一属性的列为基本数据类型构成；
4. 设计出来的表都是简单的二维表。

举例：用户收货地址 反例：

姓名	电话	地址
张三	138000000	北京市-朝阳区-酒仙桥街道

正例：

姓名	电话	省	市	区	街道
张三	138000000	-	北京市	朝阳区	酒仙桥街道

总结：每列都是不可再分的原子值（一个列不可再分，比如通讯地址和省、市、区）

第二范式（2NF）

1. 第二范式（2NF）是在第一范式的基础上建立起来的。
2. 第二范式（2NF）要求实体的属性完全依赖与关联。所谓完全依赖是指非主属性列不能对主属性列存在部分函数依赖，如果存在这个属性和关键字部分应该分离出来形成一个新的实体，新实体与原实体是一对多的关系。

反例：

主键：产品id , 用户 id

产品 ID	用户ID	产品名称	用户姓名	购买数量	下单时间
100	1	微波炉 A102	王麻子	1	2022-08-08

正例：

主键：产品id , 用户 id

订单表

产品 ID	用户ID	购买数量	下单时间
100	1	1	2022-08-08

产品表

产品 ID	产品名称
100	微波炉 A102

用户表

用户ID	用户姓名
1	王麻子

总结：消除列对主键的部分函数依赖（对于组合主键的部分依赖，比如：产品ID + 用户ID 为主键，存在用户名称，产品名称等部分主键依赖字段）

第三范式 （3NF）

1. 满足第三范式（3NF）必须满足第二范式（2NF）。
2. 第三范式（3NF） 要求一个数据表中不包含已在其他表中包含的非主键关键字信息，即数据不能存在传递关系，即每个属性都跟主键有关系直接关系而不是间接关系。

反例：

订单ID	用户ID	产品ID	产品名称	产品厂家
1	1	100	微波炉 A102	美的
2	2	200	变频空调 B101	海尔

正例： 订单表

订单ID	用户ID	产品ID
1	1	100
2	2	200

商品信息表

产品ID	产品名称	产品厂家
100	微波炉 A102	美的
200	变频空调 B101	海尔

总结：消除字段对非主键的传递依赖（就是需要取消订单中比如商品名称、商品地址等冗余信息）。

范式化设计

在真正的数据库规范定义上，非常的严谨，比如第二范式（2NF）的定义“若某关系 R 术语第一范式，且每个非主属性完全函数依赖于候选码，则关系 R 属于第二范式”。

结论：并不是说完全符合规范化理论的设计是最完美的设计，而是要看具体的业务场景反复实践总结最合适的设计。

反规范化设计

所谓反规范化设计，就是针对规范化而言的。 1、为了性能和读取效率而适当的违反对数据库范式设计的要求； 3、为了查询的性能，允许存在部分（少量）冗余数据。换句话说，反规范化设计就是直接用空间换时间。

• 商品信息

  ID	商品名称	商品价格	商品描述	商品图片地址
  1	微波炉 A101	$100.99	可以加热食物的微波炉	tupian.baidu.com

• 分类信息

  分类 ID	分类名称
  1	电器

• 商品分类对应关系表

  商品ID	分类ID
  1	1

• 商品信息反规范化设计

  ID	商品名称	分类名称	商品价格	商品描述	商品图片地址
  1	1	电器	$100.99	可以加热食物的微波炉	tupian.baidu.com

设计总结

1. 数据库的规划化范式设计，在逻辑结构上可以让结构更加细粒度，容易理解。
2. 但是我们在实际的开发过程中，需要考虑性能和时间成本，往往或多或少，会允许数据冗余（反规范化设计），通常可以达到 2NF。