数据库三大范式

数据库的三个主要范式是第一范式、第二范式和第三范式。

第一个范式： 核心思想是每一列必须是原子的，不能再细分。
解释是，在1 NF中，数据库表中的每一列都是一个原子的基本数据项，即每一列的值都是原子的，并不像其他表或数组那样包含复合数据。
例如，个人手机号码和地址信息应作为单独的列存在。

第二范式： 核心是要求数据库表中的每一个非主属性都完全依赖于主键，而不能只依赖于部分主键。
解释是，在2 NF中，如果表包含共享主键，则非主键列必须完全依赖于共享主键，而不能仅依赖于主键的某一部分。
这样可以避免数据冗余并确保数据完整性。

第三范式： 核心思想是要求数据库表中的每个非主属性不传递依赖于主键。
解释是，在3 NF中，非主键列不能通过其他非主键列间接依赖于主键。
也就是说，如果一个非主键列依赖于另一个非主键列，并且该非主键列又依赖于主键，则不允许这种传递依赖。
遵循3 NF可以进一步减少数据冗余，提高数据独立性。

数据库的三大范式？

说白了，关系数据库范式就是一组保证数据不冗余、不重复，同时保持数据一致性和完整性的规则。
其实很简单。
我们通常所说的第一范式、第二范式、第三范式是三个不同的层次。

我们先来说说最重要的事情。
第一范式 (1 NF) 要求每一列都是一个原子数据项。
例如，在员工信息表中，每一列只能有一个值，并且一列中不能混合多个员工信息。
我们去年做的项目，数据量在3 000条左右。
我们严格按照1 NF进行设计，显着提高了运行效率。

还有一点：第二范式（2 NF）是在1 NF的基础上建立的，要求数据表中的每一行都能够唯一区分，通常是添加唯一的标识列，例如： B. 员工编号。
起初我以为这样就足够了，但后来我意识到这是错误的。
如果非主属性仅依赖于主关键字的一部分，仍然会出现数据冗余问题。

还有一个细节非常重要。
第三范式（3 NF）还要求数据表不包含其他表中已包含的非关键字信息。
例如，如果部门信息表包含部门编号、姓名和简介，则员工信息表不应再包含此信息，否则将是多余的。
用技术术语来说，我们所说的是雪崩效应。
事实上，前面的一点延迟就会让一切都停止。

说实话，这完全是一个骗局。
很多人不注意这一点。
我认为在数据库设计的早期阶段尝试遵循该范例是值得的。
虽然一开始可能需要更长的时间，但从长远来看，可以显着提高数据库的效率和稳定性。
再等一会儿：如果您发现数据表中存在重复数据，则可能存在范式规则违规，您需要重新评估您的数据库设计。

数据库的三大范式？

需要明确的是，数据库范式是为表设计设定规则，防止数据混乱。
这件事如何划分和依赖是复杂的。
我们先来说说最重要的1 NF。
在我们去年运行的一个电子商务项目中，用户的送货地址与名字和姓氏结合在一起，使得直接导入成功。
它应该分为两列：“姓氏”和“名字”，大约有 3 000 级数据。
仅此一步就花费了 2 天的时间来转换。
还有一点是，手机号码等受限制的字符直接存储为原子字符，然后在需要时连接在一起。
很多人不注意这一点。
还有一个非常重要的细节。
性别等常量值应设置为“男/女”。
不要使用“1 /0”，否则后期维护会很困难。

一开始我以为2 NF是加了主键，后来发现错了。
去年更新Orders表时，我们发现客户ID经常被ID号替换，导致主键不唯一。
当时还得加个自动添加ID，说实话挺尴尬的。
但这个ID解决了我困扰很长时间的一个查询性能问题。
等等，还有别的事。
你选择的候选键不会有太大的作用，但主键必须是唯一的。
很多人不重视这一点。

3 NF 主要是为了消除传递依赖，去年我在开发报告时遇到了一个陷阱。
例如，员工表包含部门 ID 和部门地址。
但导出员工信息时，部门地址是公司所有员工共享的。
当时以为添加一个字段就可以了，后来发现需要分成“员工-部门”关联表，数据出现频率降低了8 0%。
我认为值得一试。
请记住，一般项目应该只使用 3 NF。
不要让 BCNF 太复杂。
但对于多表的关系，依赖关系必须固定，否则就会出现无穷无尽的问题。