什么是数据库三范式的通俗讲解

等一下，我昨天在整理客户的订单时发现了这个。
有一张表直接存储了“客户地址”，一整串，广东、广西、北京、上海都混在一起了。
结果查数据非常慢。
更新地址就得把整个地址改掉，换一张卡就花了半天时间。
我想，这不是典型的违反了第一范式，地址中县、市、区必须分开。
于是第二天我迅速把所有数据拆散，新建了三个字段：省、市、区。
我运行了几个查询，嘿，它显然更快。
不过我突然想到，如果客户在广东深圳，在广西桂林有店面，那么划分是不是有点问题呢？

数据库中第一二三四范式应该怎样去理解？

1 NF 简单来说就是一行中不能有重复的列。
您的员工电话号码示例是正确的。

2 NF 要求非主键列完全依赖于主键。
您的选课示例的CREDIT是正确的，但是分解后，SC1 和C2 可以映射到外键。

3 NF需要消除非主键列之间的依赖关系。
您的 S1 示例是正确的，并且分解为 S 和 D 是正确的。

BCNF 是 3 NF，但有一个附加条件：非主键不能依赖于非候选键。
WPE 示例对被分解为 EP 和 EW 以消除依赖性。

无损分解保证连接后数据不丢失。
必须保留功能依赖性。
BCNF太强了，一般3 NF就够了。

如何分解要看情况。
你的选课例子分解后需要加上外键对吧？

什么是数据库范式，为什么要反范式？

数据库设计范式是标准化表结构的指南。
目的是减少数据冗余，避免异常，保证一致性。
第一范式（1 NF）：字段原子性。
将地址字段分为地区、城市、县等。
单个地址字段不满足 1 NF。

第二范式（2 NF）：非主键字段完全依赖于主键。
订单明细表的主键是（订单ID，产品ID）。
产品的单价必须取决于完整的主键，否则违反了2 NF。

第三范式（3 NF）：非主键字段没有传递依赖。
员工台的部门经理不能依赖部门名称。
它需要直接依赖于主键，否则会违反3 NF。

完整范式的缺点： 查询性能较差，多表JOIN开销较高。
写入性能提升有限。

非规范化是一种优化查询的策略。
通过冗余数据减少表相关性。
提高响应速度并降低查询复杂度。

执行方法： 添加冗余字段，例如存储产品名称。
预聚合数据，例如存储订单总计。

挑战： 冗余数据需要同步更新，避免不一致。
占用更多存储空间。
适用场景： 多读少写业务，比如互联网应用。
高并发要求减少关键竞争。
在大数据量场景下，JOIN的成本较高。

重点是用时间交换空间。
增加存储成本并降低计算成本。
电商平台的商品详情页是一个常见的案例。