Created time
Oct 4, 2023 09:09 AM
date
status
category
Origin
summary
tags
type
URL
icon
password
slug
数据库八股
数据库三大范式是什么？其实，三范式这类问题，面试官想考察的是我们平时开发中建表、字段时的一些经验和见解，并不是希望听到那些理论的东西。建议面试的兄弟们可以多从实际经验角度出发，比如先简单说一下各范式区别，然后通过一个实际场景（数据表）来谈一谈自己对各级范式的理解。让面试官get到他想听到的点，足矣。
- 第一范式：每个列都不可以再拆分。
- 第二范式：在第一范式的基础上，非主键列完全依赖于主键，而不能是依 赖于主键的一部分。
- 第三范式：在第二范式的基础上，非主键列只依赖于主键，不依赖于其他 非主键。
在设计数据库结构的时候，要尽量遵守三范式，如果不遵守，必须有足够的理由。比如性能。事实上我们经常会为了性能而妥协数据库的设计。
范式的作用是？范式是我们设计数据库表时遵循的一种规范要求，主要有两个优点：
- 消除重复数据减少冗余数据，从而让数据库内的数据能划分的更合理，让磁盘空间得到更有效利用的一种标准化标准；
- 消除潜在的异常（插入异常，更新异常，删除异常）
数据库范式主要分为1NF，2NF，3NF，BCNF等。范式越高，要求就越细。一般在我们设计关系型数据库的时候，通常考虑到第三范式（3NF）就足够。需要注意的是，每当要符合高一级范式的设计规范，必须要以符合低一级范式为前提。例如符合第二范式（2NF）的前提，必须符合第一范式（1NF）。
以一张员工表为例，通过三范式进行一次规范测试：表结构如下：字段包括：employee_id（员工ID、部门名称、姓名、年龄、性别、归属地址、岗位、岗位描述、部门描述）
第一范式（1NF）
要求：强调的是列的原子性，即每一列都是不可再分的最小数据单元。
简单的说，第一范式就是每一个属性都不可再分。不符合第一范式则不能称为关系数据库。对于上表，不难看出Address是可以再分的，比如
”中国山东枣庄”，显然不符合第一范式要求，要符合第一范式，则至少需要将此属性拆分成3个字段，或分离到另一张address表，如下:
分成如下表，这样在数据层面无法再细分，足以保证了各列数据的原子性。
当然，如果明确业务上没有省市区划分要求，也可不划分。总之，最后还得根据实际业务来搞~
第二范式（2NF）
要求：1、满足1NF；2、表必须有一个主键；3、对于没有包含在主键中的列（非主键的其他列）必须完全依赖于主键，而不能只依赖于主键的一部分（比如某一个主键）。
对于第二范式，表中的属性必须完全依赖于全部主键，而不是部分主键。所以只有一个主键的表如果符合第一范式，那一定是第二范式。这样做的目的是进一步减少插入异常和更新异常。
在上表中，dept_desc是由主键dept_name所决定，但却不是由主键employee_id决定，所以dept_desc只依赖于两个主键中的一个，故要解决dept_desc对主键是部分依赖，从而满足第二范式，则需将dept_name、dept_desc拆分出来，如下表：
第三范式(3NF)
要求：1、满足2NF；2、非主键列必须直接依赖于主键，不能存在传递依赖。即不能存在：非主键列 A 依赖于非主键列 B，非主键列 B 依赖于主键的情况。
第三范式是为了消除数据库中关键字之间的依赖关系，在上面经过第二范式化的表中，可以看出job_desc(岗位职责)是由job(岗位)所决定，则job_desc依赖于job（job_desc → job → employee_id），可以看出这不符合第三范式，对表进行第三范式后的关系图为：
如上所示，解决了依赖关系。
总结
1NF： 字段是最小的的单元不可再分2NF：满足1NF，表中的字段必须完全依赖于全部主键而非部分主键3NF：满足2NF，非主键外的所有字段必须互不依赖面对于数据库范式进行分解的过程中不难看出，范式越高，冗余越低，一般要求到三范式或第二范式，再往上，表越来越多。你知道的，表多可不是好事儿，会带来很多问题：
- 查询时要连接多个表，增加了查询的复杂度
- 查询时需要连接多个表，降低了数据库查询性能
因此，并不是应用的范式越高越好，要看实际情况而定。第三范式已经很大程度上减少了数据冗余，并且减少了造成插入异常，更新异常，和删除异常了。我个人观点认为，大多数情况应用到第三范式已经足够，在一定情况下第二范式或第一范式也是可以的。甚至有时为了提高运行效率，可以让数据冗余( 反三范式 ，一般某个数据经常被访问时，比如数据表里存放了语文数学英语成绩，但是如果在某个时间经常要得到它的总分，每次都要进行计算会降低性能，不如加上总分这个冗余字段)。
这里简单地总结各范式区别:第一范式(1NF):每一列都具有原子数据类型,没有重复数据。它规范了基本数据表的 erd 要素,但并不严谨避免数据冗余。
第二范式(2NF):表符合第一范式,且所有完全依赖候选键的外部键都必须存在于单独的表中。它解决了第一范式的部分数据冗余问题。
第三范式(3NF):表符合第二范式,且不存在传递依赖。它解决了存在于第二范式中的部分冗余, data 更加稳定易用。3NF 是理想的表设计形式。
其次,就数据表设计一个具体场景来举例说明各范式理解:
表一(1NF): 商品信息表
商品id(主键) 商品名 价格 折扣率 分类id
表符合1NF,但分类id存在部分冗余,对于同一分类的商品将需要重复存储分类id。
将分类id提取到独立的分类表, converts 表一到2NF:
商品信息表:
商品id(主键) 商品名 价格 折扣率 分类id(外键)
分类表:
分类id(主键) 分类名
通过消除传递依赖,表一符合3NF,最终形式如下:
商品信息表:
商品id(主键) 商品名 价格 分类id(外键)
分类表:
分类id(主键) 分类名
紧接着还需要在各表上添加适当的主外键约束,以确保数据完整性。
参考资料
- https://blog.csdn.net/qq_39390545/article/details/115037994