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

原创
03/21 20:50
阅读数 74

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

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

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

在这里插入图片描述

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

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

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

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

范式的作用

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

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. 查询时需要连接多个表,降低了数据库查询性能

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

附、一张有故事的照片(十六)

在这里插入图片描述

老公,咱们也能这样白头偕老该多好啊! 

老伴儿啊,我仿佛又听到了从前你问过我的话。

一个看到了未来,一个看到了过去 
一生很短。

 

展开阅读全文
打赏
0
0 收藏
分享
加载中
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部