面试又双叒叕被问到数据库三大范式，该怎么答才能让面试官认可呢

小伙伴想精准查找自己想看的MySQL文章？喏 → MySQL江湖路 | 专栏目录

干饭人，干饭魂，吃饭干饭要拿盆

  上周三中午和公司另一个部门的春哥一起干饭，就在公司门口杏坛路上的丰源包子铺~ 不得不说和我在老家小时候吃的蒸包真是一个味儿，天天吃都不腻，唯一缺点就是老家包子一块钱个，这家2块5一个🙃。不得不说，真吃不起。。。

在这里插入图片描述

  饭桌上春哥问我面试时会不会问数据库的三大范式，回答的都咋样？

  因为在他最近面试问这问题时，发现很多同学对范式概念很模糊，有人倒是准备了，直接背起标准答案来。。他表示很无语。

  其实，三范式这类问题，面试官想考察的是我们平时开发中建表、字段时的一些经验和见解，并不是希望听到那些理论的东西。建议面试的兄弟们可以多从实际经验角度出发，比如先简单说一下各范式区别，然后通过一个实际场景（数据表）来谈一谈自己对各级范式的理解。让面试官get到他想听到的点，足矣。

  废话不多说，上车一起捋一波~

目录

• 范式的作用
• 1、第一范式（1NF）
• 2、第二范式（2NF）
• 3、第三范式(3NF)
• 总结
• 附、一张有故事的照片（十六）

范式的作用

范式是我们设计数据库表时遵循的一种规范要求，主要有两个优点：

1. 消除重复数据减少冗余数据，从而让数据库内的数据能划分的更合理，让磁盘空间得到更有效利用的一种标准化标准；
2. 消除潜在的异常（插入异常，更新异常，删除异常）

  数据库范式主要分为1NF，2NF，3NF，BCNF等。范式越高，要求就越细。一般在我们设计关系型数据库的时候，通常考虑到第三范式（3NF）就足够。需要注意的是，每当要符合高一级范式的设计规范，必须要以符合低一级范式为前提。例如符合第二范式（2NF）的前提，必须符合第一范式（1NF）。

  好了，咱们就以一张员工表为例，通过三范式进行一次规范测试吧~~

  表结构如下：字段包括：employee_id（员工ID、部门名称、姓名、年龄、性别、归属地址、岗位、岗位描述、部门描述）

在这里插入图片描述

1、第一范式（1NF）

要求：强调的是列的原子性，即每一列都是不可再分的最小数据单元。

mysql> select * from employee;
+-------------+--------------+-----------+------+------+-----------------------+--------------+--------------+-----------------------+
| employee_id | dept_name    | name      | age  | sex  | address               | job          | job_desc     | dept_desc             |
+-------------+--------------+-----------+------+------+-----------------------+--------------+--------------+-----------------------+
|           1 | 研发一部     | 陈哈哈      |   27 | 男   | 中国山东枣庄          | java研发     | 做web        | 做公司门户网站        |
|           2 | 宣传部       | 川建国      |   72 | 男   | 美国纽约曼哈顿        | 宣传部长     | 吹牛逼       | 跟客户吹逼            |
|           3 | 保卫科       | 盲僧       |   30 | 男    | 中国河南嵩山          | 保安队长     | 练回旋踢     | 站岗                  |
+-------------+--------------+-----------+------+------+-----------------------+--------------+--------------+-----------------------+
3 rows in set (0.00 sec)

  简单的说，第一范式就是每一个属性都不可再分。不符合第一范式则不能称为关系数据库。对于上表，不难看出Address是可以再分的，比如”中国山东枣庄”，显然不符合第一范式要求，要符合第一范式，则至少需要将此属性拆分成3个字段，或分离到另一张address表，如下:

在这里插入图片描述

  分成如下表，这样在数据层面无法再细分，足以保证了各列数据的原子性。

mysql> select * from address;
+------------+---------+----------+-----------+
| address_id | country | province | city      |
+------------+---------+----------+-----------+
|          1 | 中国    | 山东     | 枣庄      |
|          2 | 美国    | 纽约     | 曼哈顿    |
|          3 | 中国    | 河南     | 嵩山      |
+------------+---------+----------+-----------+
3 rows in set (0.00 sec)

  当然，如果明确业务上没有省市区划分要求，也可不划分。总之，最后还得根据实际业务来搞~

2、第二范式（2NF）

要求： 1、满足1NF； 2、表必须有一个主键； 3、对于没有包含在主键中的列（非主键的其他列）必须完全依赖于主键，而不能只依赖于主键的一部分（比如某一个主键）。

  对于第二范式，表中的属性必须完全依赖于全部主键，而不是部分主键。所以只有一个主键的表如果符合第一范式，那一定是第二范式。这样做的目的是进一步减少插入异常和更新异常。

  在上表中，dept_desc是由主键dept_name所决定，但却不是由主键employee_id决定，所以dept_desc只依赖于两个主键中的一个，故要解决dept_desc对主键是部分依赖，从而满足第二范式，则需将dept_name、dept_desc拆分出来，如下表：

在这里插入图片描述

3、第三范式(3NF)

要求： 1、满足2NF； 2、非主键列必须直接依赖于主键，不能存在传递依赖。即不能存在：非主键列 A 依赖于非主键列 B，非主键列 B 依赖于主键的情况。

  第三范式是为了消除数据库中关键字之间的依赖关系，在上面经过第二范式化的表中，可以看出job_desc(岗位职责)是由job(岗位)所决定，则job_desc依赖于job（job_desc → job → employee_id），可以看出这不符合第三范式，对表进行第三范式后的关系图为：

在这里插入图片描述

如上所示，解决了依赖关系。

总结

1NF： 字段是最小的的单元不可再分 2NF：满足1NF，表中的字段必须完全依赖于全部主键而非部分主键 3NF：满足2NF，非主键外的所有字段必须互不依赖

  面对于数据库范式进行分解的过程中不难看出，范式越高，冗余越低，一般要求到三范式或第二范式，再往上，表越来越多。你知道的，表多可不是好事儿，会带来很多问题：

1. 查询时要连接多个表，增加了查询的复杂度
2. 查询时需要连接多个表，降低了数据库查询性能

  因此，并不是应用的范式越高越好，要看实际情况而定。第三范式已经很大程度上减少了数据冗余，并且减少了造成插入异常，更新异常，和删除异常了。我个人观点认为，大多数情况应用到第三范式已经足够，在一定情况下第二范式或第一范式也是可以的。甚至有时为了提高运行效率，可以让数据冗余( 反三范式 ，一般某个数据经常被访问时，比如数据表里存放了语文数学英语成绩，但是如果在某个时间经常要得到它的总分，每次都要进行计算会降低性能，不如加上总分这个冗余字段)。

附、一张有故事的照片（十六）

在这里插入图片描述

老公，咱们也能这样白头偕老该多好啊！ 老伴儿啊，我仿佛又听到了从前你问过我的话。 一个看到了未来，一个看到了过去 一生很短。