理解什么是数据库规范化

规范化理论，在我参加问答论坛的这些年里，这个东西一直是数据库设计中非常热门的话题。
说实话，一开始看起来有点混乱，但后来我逐渐明白了它是如何工作的。

记得曾经有一个新手朋友问过我这个问题，我就用一个简单的例子给他解释了一下。
我们想象一下，一家超市的收银台每天都要处理各种产品的销售数据。
在标准化之前，每个收银员都可以记录自己的一组数据，因此信息会相当混乱且容易出错。

归一化理论就是为了解决这个烂摊子。
它将数据库中的关系分为多个级别，就像我们在学校的年级一样，从第一范式（1 NF）到第五范式（5 NF）。
级别越高，要求越严格。

第一范式是最基本的。
要求每个字段都是较小的、不可分割的数据单元，并且不能有重复的组。
例如，如果有一张记录学生信息的表，就不能出现“张三的数学成绩”这样的字段，因为成绩可以分为数学成绩和语文成绩。

然后是第二范式（2 NF），它要求在尊重第一范式的基础上，非主键字段必须完全依赖于主键。
例如，如果学生信息表的主键是学号，则性别、年龄等字段不能仅基于特定学生的姓名。

此外，第三范式（3 NF）要求非主键字段不能传递依赖于主键。
也就是说，如果一个字段依赖于另一个非主键字段，则该字段不应出现在表中。

后来还有BCNF、4 NF、5 NF。
所有这些范例都解决了更复杂的数据依赖性问题。
例如，4 NF 消除了多值依赖，5 NF 消除了联合依赖。

一般来说，规范化的作用是使数据库中的数据更加清晰、更加准确，并减少异常和冗余。
就像我们把房间收拾干净，把所有的东西都分类起来，使用起来会更方便吧？然而，越标准化越好。
有时过度规范化会增加数据库的复杂性并影响性能。
因此，必须根据实际情况来确定。

什么是第三范式?怎样进行第三范式规范化?

啊...第三范式...2 02 2 年仍在研究...这非常令人困惑。

就是这样...不能有传递依赖。
比如...订单表...订单号为主键...订单号指向订单金额...订单金额指向折扣码...这个就传过去了。
不。

后来我意识到...它是一个非主属性...它必须直接依赖于主键。
毫不拐弯抹角。

例如...假设有一个表...员工编号（主键）→部门编号→部门名称...这里存在传递依赖。
部门编号不是主键...而是取决于员工编号...因此部门名称取决于部门编号。

这不满足3 NF。
解决办法...就是拆掉时钟。
插入员工表...部门表...并创建相关表。
在每个表中......非主属性仅基于主键。

你看...我在2 02 2 年遇到了一个项目...数据冗余特别糟糕。
客户信息...存储在订单表和地址表...两者中。
客户编号是主键...但客户名称出现在订单表中...这是传递依赖。

拆表后...查询有点慢...我们需要连接表...但是数据维护很简单。
添加新客户...您无需编辑每个表。
省去了很多麻烦。

所以... 3 NF 可以减少这些扭曲。
但有时......为了性能......你可能不得不牺牲一些标准化。
这件事……实在是太扑朔迷离了。

数据库中为什么要对关系模式进行规范化？

说实话，当我刚开始学习标准化时，我对标准化感到很困惑。
后来我慢慢想起来，心里就稍微好受一些了。
就拿我之前接手的一个旧系统来说吧。
数据表就像打翻了一家香料店一样混乱——一张表上写满了客户信息、订单详情和付款记录。
结果，您必须加入三到四张桌子才能检查顾客购买的商品。
这是极其低效且容易出错的。

有趣的是，标准化的核心就四个字：“一物一处”。
我的一位导师举了一个非常生动的例子：想象一下超市收银台。
您将所有产品信息、促销信息和收银记录放入一张表中。
结果，你改了促销，就得改表里几十万条数据。
如果错过了更改怎么办？ 所以必须将它们分开，产品清单、促销清单、收银记录表各司其职。
这就像做饭一样。
菜市场和厨房分开，买菜、做饭都很方便。

但是拆解手表确实不像填一张表格那么简单。
我遇到过团队争论到脸红的情况，只是为了订单是否应该拆分为“订单标题”和“订单详细信息”。
一边说拆掉可以保证数据一致性，另一边说不断检查效率更高。
最终的妥协是：保持订单标题完整，单独使用详细信息，但使用触发器来同步库存。
说白了，数据一致性是底线，但不要为了它而让系统像蜗牛一样运行。

BCNF 听起来很花哨，但我也见过使用非 BCNF 表效果很好的场景。
例如，我们有一个报告系统。
数据更新频率低得可怜，但报表的需求却是压倒性的。
通过直接使用宽表结构，用户可以快速运行销售趋势图。
系统运维表示，如果改成第三范式，每次运行报表都要扫描几千万条数据进行冗余计算，直接烧毁CPU。
我自己没有运行过这个，但我记得数据是X十亿级别的，使用宽表时延迟只有零点几秒。

所以最关键的是找到平衡点。
BCNF 是理想的，但不是必需的。
就像你住房子的时候，家具齐全的话肯定会好看，但如果租客每天都搬家具，简单装修一下可能会更容易。
关键是要看系统的实际使用场景，不要把理论当作圣经。