数据库三大范式

嘿，你提到了数据库范例。
2 008 年我刚上班的时候，公司系统很小，数据一塌糊涂。
老板每天都骂我，所以我就想着如何做事更加规范。

我们先来谈谈范式，NF1 当时我们表中有一个字段叫“地址”，里面包含了省、市、区、街道、门牌号、楼层、房间号等所有信息。
一行数据被填满了。
事实证明，调查这一点是一件令人头疼的事情。
如果我想检查某个区域的所有商店，我必须扫描整个表。
我划分了，省一区，市一区，区一区，等等。
现在就这样了，每个区域都是最基本的，无法消除的。
这就是所谓的原子性，你知道吗？ 2 009 年，我们在另一个表中有一个“爱好”字段。
有的人填写“篮球、足球”，有的人填写“旅行、绘画”，用逗号隔开。
我就放弃了，说不行，每个爱好一个字段，爱填什么就填什么，不能混在一起。
老板还说我太严厉了，后来我才知道其实方便多了。

我们来谈谈第二范式，NF2 它首先必须满足NF1 那时我们有一个订单表。
主键是订单号，但表中还有“客户省份”、“客户城市”和“客户街道”。
我告诉你，这不行！客户的省份和城市取决于客户ID，不是直接写在订单号上。
我当时建议创建一个Customer表来存储客户ID、客户名称、省份、城市等。
在orders表中插入客户ID，并使用这个ID在客户表中查找详细地址。
这样，orders表中的地址信息完全依赖于主键订单号，没有部分依赖。
2 01 0年，当我们做出这个改变时，我们的老板仍然担心性能以及多表连接是否会很慢。
测试结果不再慢，数据结构清晰，查询速度快。

最后三分之一是正常形式，NF3 它必须满足NF2 在 NF2 之后，我们的表内外可能仍然存在一些传递依赖关系。
例如，在“客户”表中，“客户 ID”是主键，“客户名称”、“客户省份”和“客户国家”（例如中国）是主键。
有时候想要查询某个国家所有客户所在的省份，需要先通过客户姓名查ID，然后再查省份。
它有点长和宽。
我想知道客户国家是否可以分开？但后来发现订单中国家信息用得不多。
如果取出来，会创建过多的表，会带来维护问题。
所以对于NF3 来说，我们当时还没有完全实现。
2 01 1 年，在另一个项目中，我集中精力研究 NF3 结果表之间的关系太多了，我几乎画不出ER图，直到秃了。
但数据其实很是标准化的，没有冗余。

一般来说，NF1 保证每个字段不能再细分。
简单来说，一列中的数据必须是基本单位。
NF2 保证非主键字段完全依赖于主键，而不能仅依赖于主键的部分。
NF3 确保非主键字段不能依赖于其他非主键字段，并且不能具有传递依赖关系。
当时最大的缺点就是一开始不懂，数据乱七八糟。
后来逐渐分了，表多了，查询也好了很多。
不过，一切都要视情况而定。
越规范越好，就看实际中能不能用了。
我以前没接触过，不敢乱说。

数据库的三大范式？

1 . 第一范式（1 NF）：所有字段都是最小单位，字段不能重复。
例如，员工表中的姓名不能重复，每个姓名对应一个员工。

2 第二范式（2 NF）：完成1 NF并且非主键字段完全依赖于主键。
例如，如果员工表的主键是 ID，则电话号码不能仅依赖于主键的一部分，例如姓名的一部分。

3 第三范式（3 NF）：完成2 NF并且非主键字段不依赖于其他非主键字段。
例如，部门表的主键是部门ID，员工表中的部门名称不应该依赖于其他部门信息。

4 BCNF：它完成 3 NF，并且对于每个多值非平凡依赖 X→Y，X 包含候选代码。
例如，如果员工表的主键是id，那么如果部门id→部门名称，则部门id必须是整个候选人代码。

5 第四范式（4 NF）：满足 BCNF，并且对于每个非平凡多值依赖 X→Y，存在一个真正的超集，其中 X 不包含候选代码。
例如，Employee表的主键是ID。
如果存在一个具有多个值→多个部门名称的依赖部门ID，则该部门ID不能包含其他候选代码的真正超集。

6 第五范式（5 NF）：也称为完美范式，它完成了4 NF，关系中的每个属性既不传递地依赖于候选代码，也不功能性地依赖于候选代码。
例如，Employees 表的主键是 ID，所有字段都直接依赖于 ID。

以下范式可以提高数据库设计的质量并减少数据冗余，但并不是所有数据库都应该达到最高范式。
一般来说，第三范式就足够了。

数据库设计三大范式

说实话，这三种做法说起来还是挺复杂的，但是把例子一一分解就更清楚了。
当我第一次开始学习数据库时，我对第一个范式感到困惑。
例如，在订单中；您可以将客户的姓名和地址写在一栏内，例如“北京张三”。
这是一个笑话。
在第一范式中，每个字段必须是原子值并且不能混合。
我是一家电商公司的实习生，老师指着代码说：“你看你的地址栏，‘北京市海淀区’和‘北京市朝阳区’搞混了，客户说要拆开，因为跟售后地址不符。
改完后，每个地址单独一栏，问题立马就解决了。

第二个让我印象深刻的范式是在ERP系统中，当表是设计得相当大，但是非主键列是“客户州”和“客户城市”，导师说这是不可能的，因为非主键列是依赖于主键的规模不大，但如果以后业务拓展，走遍全国。
我们的导师声称这种设计迟早会引起问题。
最终分为“订单表”和“订单地址表”以及关联的主外键。
本课程教您在设计时钟时提前思考。

第三范式最令人不安的方面是传递依赖。
我在为一家旅游公司开发预订系统时遇到了这个问题。
他们的列表包含“景点 A 包含”和“景点 A 包含项目 B”。
我当时觉得很好，但是如果我改变套餐，A景点就会改变，B项目也会改变。
它相当于一个非主键列，或者通过另一个非主键列隐式依赖于主键。
教练拍着桌子，“快点！”后来又分为“套餐-吸引力图”和“吸引力-项目图”，并通过中间图关联起来。
说实话，拆分后查询复杂一点，但是数据一致性稳定，钱花得值。

但归根结底，三大范式不是学说，而是经验。
一些项目审查会议显示，由于性能原因，有一个时间表违反了第二范式。
但由于数据量较小，查询简单，所以暂时保持不变。
该小组最终同意了，但也提出了警告。
说白了，设计数据库就像做饭一样。
该拆的就拆，该整合的就整合。
有时固守某种范式只会导致陷阱。

数据库的三大范式

三个主要范式是：第一范式、第二范式和第三范式。

第一范式：每个字段只包含一个值，不能拆分。
示例：1 9 8 0 年，关系数据库开始要求原子性。

第二范式：非主属性完全依赖于主键。
例子。
1 9 9 0年，订单表结构要求产品ID和客户ID完全依赖于主键订单ID。

第三范式：非主属性不传递依赖于主键。
举例：2 000年，用户表结构要求用户的订单信息直接依赖于用户的ID，而不是依赖于用户的订单ID。

这是一个陷阱，不信，不做。