MySQL教程-74-数据库设计三范式原创

来讲一下咱们重点各位啊，收一下尾，重点啊叫数据库设计三范式，这是一个重点内容啊，面试经常问的，面试经常问啊，那首先是什么是设计范式啊。就是设计表的什么依据。就是按照这个什么，按照这个三范式设计的表，不会出现数据冗余。明白吧，这数据冗余这个事不是提过吗？对不对？哎，那再往下呢，我们就来看一看啊，三范式都是哪些？来，我们先说啊，一个一个看啊，第一范式，第一范式任何一张表都应该有主见，并且每一个字段原子性不可再分。

每一个字段原子性不可再分。第一反是啊。诶，这个说的是什么？我们来看第一范式。这个符合不符合第一范式不符合，第一有主件吗？没有，没有主见啊，第二这个联系方式能不能拆成两个字段，一个叫邮箱，一个叫电话。对吧，改了之后满足不满足，第一范式，第一有没有主见，第二是不是这个原子性不可再分啊，有的老师不对，这个可以分姓和名。可以分是吧，但你没必要啊。他就是个姓名啊。

对吧，哎，那你再拆分，像这种情况再继续往下拆分的话，那你反而就会更麻烦了，更麻烦了，对你别较真啊，那这个也可以拆分。电话前几位可以拆分，那你这个你再你再拆分没有意义，是不是你这电话一个完整的电话就是联系方式啊，你不要再拆了啊好，这是一范式，大家记住了吗？得有主键，每个字段原子性不可拆分，第二范式看第二范式是这样的，所有非主键字段完全依赖主件，不能产生部分依赖，所有非主见字段啊，就首先二范是建立在什么第一范式的基础之上，所有非主见字段完全依赖主线，不能产生部分依赖。不能产生部分依赖。

先看看。这个满足不满足第一范式。有没有主见？没有主见吧？不满足。第一份吃。这是学生和老师的。讲师跟学生应该是一对多嘛。还是多多多多。一对多多对多多对多，一个讲师应该关联多个学生，一个学生也应该关联多个讲师嘛，是不是多得多关系啊，大家看好这个满足不满足，一犯不满足，因为第一没主见，第二大家看是不是确定主见了，主见是联合主键对吧，就是复合主键，大家听说过吧，一个表是不是只能有一个主键，所以这两个字段联合起来添加了几个主键，一个主键加了之后。

满足第一范式了，但是他满足第二范式吗？满足不满足？第二，第二范式是所有非主见字段。完全依赖组建，不要产生部分依赖。学生张三，实际上他只依赖这两个主见值当中的其中一个。产生了部分依赖吧，产生了部分依赖，所以这就是我之前给大家说的，我不建议你们在开发的时候使用什么复合组件。因为你采用复合主件，就意味着多个字段添加一个组件约束将来有一些字段可能是依赖这一部分，有的字段呢，可能依赖这一部分，那有的时候老师产生部分依赖又咋的？我现在就产生部分依赖了，好各位，产生部分依赖就一直数据冗余，张三出现了两次，王老师也出现了两次，这个数据完全没必要说出现两次对吧？数据冗余就意意味着数据库的空间浪费吗？

对吧，所以接下来怎么做。怎么做？多对多三张表。关系表。两个外键。看好了啊，有一个叫学生s number和s name，这个是主见，S name是学生的名字吧，来一张三二李四三王五啊很简单，再往下t teacher啊，这是讲师表啊，T和t name，然后接下来这个t number 123，然后一这块，比如说王老师，张老师。

啊，李老师，好了，那么接下来呢，在这有个关系表叫t t student吗？Teacher relation啊有这么一个叫学生讲师关系表，那在这块应该有他自己的一个ID，对吧？ID这个应该注意，这个应该是谁主键。是不是，然后这个地方这张表是不是应该有主键，然后这块应该有谁啊，有s number这是谁FK还有谁t number是不是FK外键，然后接下来呢，这个这是主键啊，就不用管了，那这个s number呢，就写上112。23333。

312313。行不行？啥意思啊？这不一个学生吗？对应两个老师啊。一不是一个学生吗？对俩老师吗？好，那我问你这三三是不是一个老师，三和三是不是一个老师，但对应的学生是两个，两个学生学哦对对对对，333他对应的是。所以这样是不是就可以描述清楚多对多关系啊，多对多关系。非常经典背口诀啊，以后遇到多对多背口诀多对多，三张表两张。这个关系边怎么着，关系边两个外键。

多对多三张表，关系表两个外键。以后呢，就就不用再说再想象了，怎么怎么去设计这个东西，就是但凡是多对多，你就记住它的表设计关系是。多对多三张表，关系表两个外键，大家看张三是不是只写一次，王老师也出现一次对吧？往下只是一个纯关系关系表。嗯。啊，就这样。多多三张表，关系表两个外键，多对多三张表。关系表两个外键。多对多三张表关系表里边有两个外键啊，多对多，这是第二范式，各位啊，接下来第三范式，第三范式是建立在第二范式的基础之上，所有非主键字段又是啊，所有非主键字段。

直接依赖什么主键字段，所有非主键字段直接依赖主键吧，不能产生传递依赖。这个是不能产生部分依赖，第三方是要求是不能产生传递依赖。好，我们一起来看看这个数据，各位看数据啊，三范式，首先这个满足满足一范。这是不是学生跟班级的关系？学生和班级是一个什么关系？就你在上高中的时候，你的你学生跟班级的关系什么关系？对学生跟班级是多对一，反过来班级跟学生就是一对多，不会多对多吧。一个班级有多个学生嘛，就像你来到动力节点之后，你永远都在这个教室嘛。在一个教室当中有很多学生吧？好一对多。一对多啊。这个学生和班级。

大家看这个满足，你就先说满足不满足一犯吧，二犯满足吗。二份也满足。对不对，为啥？因为他没有复合主键，没有复合主键就意味着单一主键，单一主键是一个字段上添加主键，一个字段上添加主件，你别的数据你没有办法，你这些这些这些只能去依赖这一个，所以现在已经满足第二范式了。你好好想想，到底有没有满足第二范式，第二范式之所以这个不满足的原因是因为什么？是因为它这个主键是两个字段，你现在是不是复合主线，你张三依赖的是这两个字段当中其中一个，对吧？诶理解什么意思吧，你现在这张表的这个组件，你字段没办法，你这主件只有一个字段呀，你这不是复合呀，你剩下这三个记录是不是都是依赖它？

所以满足满足二犯啊，二犯满足三犯呢，不满足三犯是说不能产生传递依赖，大家看清楚吧，是不是一年一般它依赖是零一零一再去依赖的这一个值。这种情况就表示产生了传递依赖。各位。传递呢？三犯背会啊？一饭是什么？有主见不可再分，二犯是不能产生部分依赖，三犯是不能产生传递依赖。我再强调一下，范式最终的目的都是为了解决数据冗余，只要您遵守这三个范式，最后设计的这些表肯定不会有数据冗余的现象。在讲三范式的过程当中，我给大家说了，第二范式经常见的就是多对多，三张表，关系表，两个外键，那第三范式主要是一个班级和什么学生，这是非常经典的什么一对多。

各位啊，这是一对多来班级，有什么班级编号，这是不是主见班级的名字对不对班级的名字，然后接下来呢，我们学生这一块有什么呀？学生的编号是主见吧，学生的名字再往后是不是应该有个班级的编号，是外建一对多吗？是不是好一号学生2344号学生来，这个是A来，把这个复制一下拿过来，嗯，接下来改一改CDABCD4个学生班级，1001或者101这个班。嗯，是班啊，这是班级啊，这是班级，这是班级，然后这会101这个学生吧，101学生啊，这个呢，就是张三吧，啊随便写吧，啊来拿过来上面班级啊上面班级来这个拿过来。

随便改吧，随便起个名啊，10102030405CLASS number这块的话就写写什么呢，就是说比如一一对吧，二二理理解什么意思吧，啊然后这块呢，咱们给两个数据得了啊。这块改点改改一下班级一班级二。一对多吗？班级信息，学生信息是不是我们今天讲的那个外建吗？这不一个班嘛，一个班对几个学生，俩张一张二嘛。这个班对应三个学生吗？一对多背口诀啊来有口诀啊，一对多两张表，多的表加外键。

一对多两张表，多的这方加外键。一个班级不是对应多个学生吗？一对多两张表，多个表加外键，多对多三张表关系表两外键，背口诀啊，以后再进行表设计的时候，绝对就不允许你再想了，我一说一对多，您必须马上反应出来，一对多两张表，多对表加外建，一对多两张表，多对表加外键，多对多三张表关系表两外键。多对多三张表，关系表，两个外键，一对多两张表，多的表加外键，你把这个给我背会。能背会吗？多最多三张表，关系表两外键一对多两张表，多的表加外键。

对，是这样。一对多啊。三范式大家理解了吗？我再说一下啊，一犯一犯啊，必须有主见，每一个字段原子性不可再分，二范不能产生部分依赖，三范不能产生传递依赖表满足三范式的目的都是为了减少数据的冗余啊，减少数据冗余。另外口诀你得记住，多对多三张表，关系表，两个外键，一对多两张表，多对表加外键。记住行吧，记住啊。好，那么三范式有哪些，我们也说了，多对多的设计也说了，然后呢，一对多我们的设计也有了，那么接下来我们来总结，或者说最后啊，需要提醒的是，需要提醒一下各位啊，提醒什么呢？在实际的开发过程当中。

我们是以满足客户的需求为主。有的时候会拿冗余来换速度。注意啊，提醒一下，在实际的开发中。以什么满足客户的需求为主？有的时候会拿冗余换什么速度，执行速度好，这么说吧，同学们表连接越多，SQL语句的执行效率是不是越慢？如果我硬要把学生跟班级放一块儿，就一张表，不需要做表连接。这个执行速度是不是快，但是数据是不是会有冗余啊，所以面试的时候把这句话说上去会给你加分。

别人叫他。明白什么意思吧，就是面试官问你了啊，就是你知道数据库设计三范式吗？我这个知道是吧？数据设计三范式分别有，第一范式是说那个所有表的应该有主见啊，每个字段原子性不可再分，第二份是所有非主键字段。完全依赖主见，不能产生部分依赖，第三范式呢，其实就是这个所有非主见字段，直接依赖主见，不能产生传递依赖，但是这三个范式啊，其实这是理论上的一个一个一个说辞啊，范式的一个你就可以继续说呀，对吧，范式三范式的目的就是为了减少数据的冗余嘛，但我们以前在开发的时候，你可以这样说呀，但但我们以前在开发的时候，我们有，诶主要以满足客户的需求为主嘛，啊当然就是说我们有的时候可能会拿这个冗余，诶换一下这个速度啊，这种情况也是存在的，你把这句话说上去就给你加分。就他可以体现你的一个真实的一个开发经验，我们以前在表设计的时候，也不是说完全三方都遵守。有的时候我们就说它冗余点对吧，但它执行速度快啊，不需要表连查，表连查扫描技术条数是什么比卡尔机呀。

知道吧。那如果不连查，我单独扫这张表，那就很单纯，这张表里边多少条多少条记录，我就扫多少条，效率再低，我再加个索引。对不对，所以说有的时候我们可能会牺牲一下这个空间。来换一下这个速度。希望能把这句话记住。啊，设计3万式只是理论上的一个实践，跟理论还是有区别的，把这句话说出来，说出来。好了，这个呢，是关于咱们数据库设计三范式，各位啊。