00:00
好,那第一范式的话呢,我们就说到这儿了啊,接下来的话呢,我们来看一下叫第二范式,那如果呢,我们说一个表啊,遵循了第二范式啊,那么它的前提呢,就已经是遵循了第一范式了啊,这个大家要注意一下,那么如果说他遵循第二范式呢,他在第一范式的基础上又增加了什么样的这个约束呢?哎,我们来看这个红字。说呢,诶,满足数据表里边每一条数据记录啊,都是可唯一标识的,诶都是可唯一标识的,诶那你想想我们这可唯一标识是谁来决定的事儿啊,我们是不是前面提到的概念叫做超建对吧?超建的话呢,就能够唯一标识我们这个,呃,每一行的这个记录了,那超建里边那个最短的是吧?你把那个没有用的这个给它扣除掉呢,就叫候选了,那候选键呢,随便挑一个是不是就是主键了呀?那杨IG呢,既然你能够唯一标识这个表中的每一条记录了,是不是就一定会有超件,一定有候选键,是不是就一定有主键了?诶,那这时候就提到了,说我们这个第二范式里边就提到了,我们得有这个主见啊,得有主见。而且呢,所有的这个非主键的字段啊,不是主见的这个字段都必须完全依赖于主键,不能够只依赖于主键的一部分。
01:08
啊,不能只依赖于主见的一部分,诶这里边呢,主要呢,关键词呢,就是这个完全依赖和这个部分依赖啊,就这样个概念啊,这个大家一定要注意一下,诶,我先泛泛的说一个这个,呃,抽象的一个模型啊,你比如说我们在一个表当中,这个主见啊,它是一个联合主键,也就说这个字段和这个字段合在一起,能够唯一的标识我们这个表中的一条记录了,那就是一个联合主见了,对吧?然后除了这俩字段之外呢,我们剩下的这个字段,假设有三个,这三个的话呢,诶,那就属于叫非主键字段。那满足我们第二范式是什么意思呢?就是比如说我们这仨字段每个都得是这样啊,这个字段的话呢,要想能够确定它这个值是多少,你得告诉我这个字段,且这个字段的值你要光告诉我前面这个字段的话呢,确定不了。哎,广告组,我后边这字呢,也确定不了,哎都得告诉我,那我才能够确定下来这个值是多少,才能够唯一的去做一个标识啊,后边这个字段也都是如此才行,哎都这叫满足第二范式,那怎么叫不满足呢?你比如说我现在有一个字段,这个字段的话呢,说这个值是多少啊,诶这个我们发现啊,说你只需要呢,告诉我这个字段的值是多少,我就知道它的值是多少了。
02:16
跟我们这个主键中的另外一个字段没有关系,那我们就说呢,你这呢叫什么呀,叫部分依赖。叫部分依赖,那这样呢,就不满足我们的第二反式,哎,就不满足第二反式,那不满足的话呢,诶会有什么问题呢,其实主要的一个问题就是冗余的问题啊,一会儿咱们会给大家说,呃,那该怎么去处理呢?咱们先泛泛一说,那怎么办呢?你就把你这个字段和你这个换个颜色啊。你就把你这个字段和你这个字段呢,你把它俩呢抽出来,你自己呢,独立建一张表,然后这个表呢,跟我们原来这个假设别的字段呢,都满足了这个,比如说这个字段也满足这个优质两个共同来决定的哈,跟原来这个表呢,你构成的是一对多的关系。啊,整个一说大家可能有点懵,来咱们下边看一下这个细节啊,举例比如说呢,我们现在有个表呢,叫做这个成绩表,这个成绩表里边有学号,有课程号,有成绩。
03:07
好,大家看这个表里边,比如我们有个学号呢,叫1001,这个1001的话呢,这个学生他可能要考好几门课啊,就好几门课,每门课的这个成绩呢不一样,对吧?同样的话呢,我们有一个课程号呢,叫001,这个001这个课的话呢,是不是也有好多同学呢去考啊,所以学号呢又不一样,那不同的学号的话呢,对应的成绩呢也不一样啊,那首先问大家,你说我们这个表里边儿这个主见是谁?啊,主键的话,你会发现呢,我们要单独用学号或课程号,是不是都不行啊,呃,也就是说呢,这两个合在一起构成我们的主键。嗯,你告诉我学号写告我这个课程号,我就能够决定成绩了啊,那反过来来讲的话呢,我们这个成绩要想确定一个成绩是多少,你光告诉我学号行不?你说啊,你你你告诉我一下1001考多少分,那不行,你得告诉我哪门课是吧?或者你说诶你告诉我一下这个001这个课呢,多少分,那不行,你得告诉我是哪个学生,诶所以说呢,这个成绩呢,它就完全依赖于我们这个主见叫学号且课程号。
04:03
那我们这儿呢,就是一个,呃,满足第二范式的一个情况。哎,他是满足的没问题是吧,好接着咱们看这个下边这个这个呢,有一个叫比赛表啊,Player game这个表里边儿呢,有这样的一些这个字段。哎,有这样一些字段,好,那咱们首先来捋一下这个里边的这主见应该是谁啊?呃,如果说我们这个主建呢,叫学员编号的话呢,你发现学员编号一定这个姓名啊,年龄啊,是不是就都定了,对吧?那那比赛编号能定吗?啊,这里边儿涉及到呢,这个球员编号呢,他可能会参加多场比赛,那你要光说球员编号这个比赛这块是不是就定不下来。啊,比赛定不下来时间啊,场地也定不下来是吧,那这是光用它当主线不行,那反过来的话呢,如果你要只告诉我这个比赛的编号的话呢。那么对应的这个比赛的时间啊,场地啊确定下来,但是这个比赛呢,是不是有好多这个球员参加了,呃,你你你能唯一定义下定义下来一个球员吗?是不行啊啊,要想能够唯一定义这个表中一条记录,那我们发现呢,是不是咱们要把这两个字段合在一起,哎,构成一个主键才行。
05:04
相当于我们这个组件里边呢,有两个字段。哎,这有两个字段,这个我们叫主属性是吧,好,那么剩下的这些呢,是不是都是这个非呃这个主属性了,呃,其他的一个字段了,行,那我们这块呢,就换成这样一个结构啊,把这个主键呢,我们就放在左边,其他的就放在这儿了,这我多了一个字叫得分啊,诶就更好的,我们能够说明这个问题了,行,大家来看说这个表啊。哎,这是主见,其他的是其他字段,我说呢,他就不满足二分式啊,为什么呢?哎,大家你会发现姓名和年龄,哎我们呢,是不是只依赖于这个球员的编号啊。你告诉我全员编号,我就知道他的姓名年龄跟我们这个比赛编号有关系吗?没有没有对吧?好,再接着比赛的时间和比赛的场地,这两个的话呢,是不是只依赖于我们的比赛编号啊。对吧,只依赖于我们的比赛编号,跟我们的球员编号有关系吗?没有是吧,所以说呢,这四个字段呢,你看它都属于叫部分依赖,诶不是完全依赖的啊,是部分依赖的,那这个得分呢。
06:04
诶,这个得分的话呢,还确实是完全依赖的,你比如说我想看一下得分啊,你告诉我说谁啊啊C罗,呃,咱就拿这个人名来说啊,呃,球员编号呢,就是C罗对应的那个球员编号哈,说C罗得分是多少,说那不行,你得告诉我是C罗参加哪场比赛的编号啊,你要广告说说这这场比赛得分是多少,那你得告诉我是哪个人哪个球员对吧?所以这个得分的话呢,它是完全依赖于这两个字段的。诶这个呢就清楚了,那就清楚了,行,那这时候呢,清楚以后的话呢,我们这个先说呢,应该怎么办吧。应该怎么办呢?我们就把你这个部分依赖的这个呢,你抽出来啊,你不是这两个字段部分依赖于他嘛,好,那你把这个球员编号呢抽出来,把你这两个字段也抽出来,你单独造一张表,然后这个比赛编号,诶抽出来放到这儿,然后呢,你不是决定了比赛时间和比赛场地嘛,诶好,你抽出来,你自己呢,也单独造一张表,那剩下还有个得分呢,得分呢,咱们不是说了它是呃完全依赖于这两个编号的,那就是这仨呢。
07:01
诶就是这两个和这一个,这三个字段呢,构成一张表,诶整个的话呢,相当于就是我们得用三张表来刻画,诶就是相当于是诶我们就满足第二范式了,学员表里边儿,哎有你这个学员编号,姓名和年龄。这个比赛表里边儿有我们这个比赛的编号,比赛的时间啊,比赛的场地对吧,然后呢,这个呃,球员比赛关系表里边有我们这个叫球员编号,比赛编号再加上一个得分是吧?哎,这样就行。有同学可能会这时候犯嘀咕了,说老师啊,这个原来我用一张表来刻画,嗯,感觉还行,那你现在呢,给我整成三张表了,这表多了是吧?表多了我就觉得麻烦,那表多了我就觉得反而不好,是吧?你要说这个三变一吧,在潜意识当中,三个原来用仨,现在用一个了,感觉挺好,你现在一个变成仨了,你怎么去让我去理解,说你这个要改呢?好,大家看,我们要是用这个不满足第二范式的这种场景,也就是我们用这个表的话呢,会出现什么问题啊,这个我一说你就能明白了,大家看。
08:01
首先第一个问题呢,就是典型的一个数据冗余啊,这个事呢,是我们其实很接受不了的,比如说我们这块呢,假设呢有一个球员,当然这叫球员编号啊,C罗啊,这个球员的话呢,他要参加很多场比赛,假设呢是M场赛。哎,那一个学员呢,有M场比赛,那我问是不是我们这边就有M条记录啊,那么M条记录里边,你现在是不是每一条记录都要记录一下C罗的这个这两个信息,这也得记录,这也记录。呃,后边这个呢,因为是M场比赛呢,每一场比赛的这些信息倒不一样,但是呢,这些信息是不是都一样啊,有M份儿,相当于呢,你本来只需要一份,那就是重复了,是不是M减一份。把这个都写出来了,没必要啊,没必要,所以这呢是冗誉的一部分,还有呢,比如我们一场比赛,一场比赛的话呢,不止一个球员参加吧,假设我们有N个球员去参加这一场比赛啊,某一场是吧,那这场比赛的这个信息呢,就写这儿了,然后这呢是你其中的一个球员的信息,呃,再一场,呃,这个这一场比赛呢,下个球员呢,就是这个信息,相信每个学员的信息都不一样,但是呢,你这一场比赛的话呢,写了N条记录,那是不是每一个里边的这些信息都一样啊。
09:04
一共是N行,那其中呢,是不是重复了N减一行,这呢也叫冗余对吧?诶这个呢是我们说诶比较严重的一个问题,数据的冗余,尤其呢是我们这个表中数据呢,你说要不多的时候呢,还能忍一下是吧,冗余就冗余了,但是你要我们这个数据量呢,很大的情况下,你就冗余度呢就很高了,那占用这个磁盘空间就有点过大。OK,除了冗易之外呢,你看我这还有叫插入异常,删除异常和更新异常,比如说哎,我们现在要添加一场新的比赛了。我添加一场这个新的比赛的话呢,你填了这个值了,将这个主建呢,一般我们主件里边呢,都没有这个空值的啊,你想想我们参加了比赛,把这个比赛呢,这个编号填到这儿了,这个呢也就都知道了,那接着呢,你是不是要签这个球员了,你说哎呀,我这个球员还不知道是谁来呢,就不太合适啊,相当于呢,就是主建里边你不能有这个空制啊,虽然这叫联合了啊呃,你不能有空值,你不能有空制,你这时候相当于你要想把这个比赛的信息填下来,你必须要把这个球员的信息填下来。这就有点恶心了,有的时候你可能还确定不下来,对吧,所以这是插入的一个问题,然后下边呢叫删除的问题,比如说我们要删除某个学员的编号。
10:08
我想删除某个球员编号的时候呢,你会发现呢,你把这个比赛编号也给删了,假设呢,这时候呢,关于这场比赛呢,目前就定下来这一个球员。啊,就确定C罗啊,要参加这个比如欧冠的这个某一场比赛了,诶这个目前呢,其他的这个球员还没确定下来,你现在把C罗给删掉了,是不是就把这场比赛的信息也给删掉了,这个呢,就是你删除的信息过多了。啊,不合适。然后下一个呢,叫做更新的一个异常,更新一个异常,你比如说我们现在某一场比赛呢,有N个这个球员呢去参加,然后呢,呃,现在呢,那就意味着我们这块呢,是不是就这就记录了这个重复的很多遍很多次是吧,有冗誉,然后呢,我们现在要这个改一下这场比赛的这个比赛时间,那问题来了,你改比赛时间的话,你可不能说把这改一下就完了,你就有N个球员参加,是不是把每一个的球员的这个比赛时间全都得改一下,那也就是说你要比赛场地改了也都得改,那你要有的丢了的话,那就麻烦了。啊成这个球员呢,还是这场比赛去另外一个地儿去参加,或者时间也不对,跟前面不一样,那就是错误,哎,所以更新的话呢,也很恶心。
11:08
你看通过刚才这样的讲解,大家应该知道,不满足这个二范式的时候呢,有这么多的问题。那我们就需要呢,把它改造成是一个满足第二范式的,OK啊,那这里边写的说一范式呢,是告诉我们字段的属性呢,是需要有原子性的,说二范式呢,告诉我们一张表啊,就是一个独立的对象,一张表呢只表达一个意思,范范来讲呢,大家你会发现这里边儿有球员的信息,有比赛的信息,那直接呢,就说球员呢归球员,比赛归比赛是吧?哎,所以把他们俩拆开。啊,OK。好,然后再给大家举个例子,那这呢涉及到这个订单啊,订单呢,诶大家应该都清楚,你买一你你你买个东西啊买东西啊,提交一个订单,一个订单里边是不是可能有多个商品吧?啊你比如说这个双11啊礼拜八呢,经常是买200,这个送200是吧,买300减300,诶买300减30。啊,满200减20啊,减的有点多了啊这个,那你买个东西呢,不足300,你是不是要凑单是吧?凑单呢,然后以一个订单的方式呢,去提交那一个订单里边呢,是不是有多个产品,诶这就我们说的这个问题,好,那假设呢,我们现在有一个表呢,就来衡量你这个订单,还有订单里边这个商品的信息,那这时候呢,你光订单的不行啊,因为这个订单里边可能有多个商品,所以呢,我们订单号和我们这个产品的这个编号呢,需要合在一起啊,构成一个联合组建。
12:25
那么这呢,我们发现呢,它就不满足这个二凡式了,为什么呢,你会发现呢,我们这个叫out date,就是你订单时间,订单时间的话呢,是不是直接的就我们这个订单编号来决定了。对吧,按订单编号就能确定,然后呢,这个诶以及以至于说呢,你这个叫custom ID,就是谁谁消费的这个订单,谁提交了一个订单,那实际上也是我们看这个all ID是不是就能确定下来,以及呢,你这个顾客啊,客户他的这个所在的公司啊,这是不是也是呢,我们就通过这个订单ID就能够确定下来了,不依赖于你这个产品的编号了。啊,或者你换句话说呢,就是呃,你这个订单当中啊,不管是哪个商这个商品了,是不是全都是这个人啊,全都是这个order order date了,就都是相同的,那你要这样写的话呢,是不是意味着就会存在这个冗余的问题。
13:09
啊,那我们得改造啊,怎么改造呢?你看啊,我刚才是不是勾的这三个,这三个的话呢,是不是它部分依赖于这个奥德ID啊,那我们就把这三个和这个奥德ID呢抽出来。诶,抽出来造这样的一张表叫奥ID啊抽出来了这三个了,那剩下谁了呢?是不是就剩下呢?你原来表中还有这俩,还有我们的叫康ity,就是你这个,呃,到底针对于某一个商品订单里边的某个商品,你到底购买量是多少是吧?啊就是QT了啊countity,然后呢,诶你剩下的这个呢,你还是这一张表。哎,还是这张表,那我们叫order details啊,这不就还是他吗?哎,就是这样的关系,哎,此时的话呢,我们说就满足这个第二范式了。啊,第二范式下边写说第二范式呢,要求实体的属性完全依赖于主关键字,如果存在不完全依赖呢,我们就把它,哎这个属性和主关键字抽取出来,哎构成一张新的实体啊这是我们举例二,哎举例三是不是都这样做的,然后呢,新实体跟原来这个实体啊之间呢,是一对多的管体,这个圆呢,用这个圆也行,或者我们这个原来的那个圆也可以一对多,你看这是我们是一个订单,然后呢,这个订单里边呢,诶具体的订单啊,订单的商品就这个是一个一,诶这一个一里边呢,是不是对应着我们这里边可能有多个呀,因为一个订单这里边可能具体的商品的话,你买了仨是不?这有三条,这是一对多是吧。
14:23
上面这个也是一样啊,这是这个具体的球员啊,这是具体一场比赛,然后这个球员和比赛,这关系表里边一个球员呢,在这里边是不是可能参加多场比赛是吧?哎,就是这样的情况,是一个一对多的关系,好那这里边呢,就是我们讲的这个第二范式啊,大家呢一定得弄清楚啊,三范式呢,别跟第二范式呢,给大家混了,OK。好,同学们,咱们接着来看一看,这个叫第三范式,这个第三范式一旦我们提到说某个表呢,符合第三范式呢,那前提呢,它是不是一定已经满足了第一范式和第二范式,对吧?那么在这个基础上的话呢,它还要求满足什么条件呢?来我们看一下说呢,还需要确保这个数据表中的每一个非主见字段都得和主见字段呢,是直接关联的,这里边儿呢,出现两个主体,一个呢叫非主键字段,一个叫主键字段,而且呢,重点要强调的是直接相关。
15:12
你不能间接相关对吧?啊,大家可能看这个呢,不太明白啊,我翻译了一下,也就是说呀,要求数据表当中的所有的非主见字段,不能依赖于其他非主键字段,你不是要求跟主键字段直接相关吗?1G呢,你就不能跟其他的那些非主键字段呢,是直接相关的了。啊,可能还是不明白是吧,来我们看后边的例子,比如说我们这里边儿有这个非主属性,哎,大家还记得什么叫非主属性了吗?我们在这块呢,是不是讲到这个属性是吧?非主属性呢,就是这个,诶非候选键当中的这些属性就叫做非主属性了啊但是这块呢,大家你可以先暂时理解成呢,我们就是非主键字段了。啊,因为咱们上面提的这个凡是这个主键的位置啊,其实大家都可以改成候选键了啊,其实这个非主属性跟非主键字段就算是一致的啊好。那么这个非主属性啊,依赖于非主属性B,而这个非主属性B呢,依赖于这个主键C。
16:06
那就是相当于存在这样的一个依赖关系,那这个呢,就是不满足我们的第三范式的。因为第三范式里边要求呢,就是啥呀,你这个A跟B,你俩不是这个非主见字段嘛,是吧,你哥俩的话呢,必须得直接关联于我们的这个主见字段,你不能你们之间还存在这种这个依赖关系啊,这就不合适了,所以说我们这个第三范式呢,想强调的点呢,大家可以这样去理解,就是说这个非主见这个属性之间啊,比如这里边这个A也好,B也好,他们呢,必须得啊,是相互独立的,不能有这种依赖关系。啊OK啊,你看我这里边讲的时候呢,这个非主间段跟这个非主属性我就混着用了啊,咱们上面讲这个非主属性的话呢,实际上是提到这个候选键的,对吧,那因为呢,我们这个第三范式里边呢,其实呢,就可以把上面的非主键字改成扣眼键啊,都是OK的。好,然后下面呢,咱们给大家去举这个例子啊,这个例子呢,首先看第一个叫部门信息表和这个员工信息表,那部门信息表里边呢,有这个部门编号,部门名称,部门简介啊OK,那员工信息表里边呢,那有这个员工编号,员工的姓名,这个部门的编号,那就这几个,那这个呢是没问题的,目前是遵守我们的第三范式的,怎么叫不遵循的呢?比如说我们在这个员工信息表里边呢,我们就没有必要呢再去提供一个叫部门名称了。
17:18
对吧,哎,部门名称就没有必要往这去列了,那么我们如果要列到这儿的话呢,大家你看遵不遵循这个第二范式呢。那你看上边这个呢,这都肯定是遵循的,对吧?这个显然是主见了,他是不是完全依赖于他,他也完全依赖于他,而对于我们这个表的话呢,员工编号,一个员工的编号定了之后呢,呃,员工的姓名是不是就决定了这是一个完全依赖的部门编号呢,是不是也也完全定了,然后这个员工的话呢,一个编号是不是唯一的,也决定了他是在哪个部门的名称上,呃,这个部门名称是吧,所以呢,这也是一个完全依赖的关系,就是这个呢,是符合二范式的,但是呢,第三范式就不满足了,因为什么呢,咱们可以认为呢,你这个部门名称如果要放在我们这个表中的话呢,这个部门名称呢,实际上呢,是不是它还依赖于我们这个部门的编号啊,那部门编号呢,依赖于我们这个员工的编号,所以它就存在这个,他们之间呢,是不是独立的一个关系。
18:06
哎,这就不行了。好,然后呢,我们再看这个举例二,这个举例二的话呢,大家来看这个呢,是我们这个商品的主件,商品的这个是商品的类别ID,这是商品类别的名称,这是商品名称,这是商品的价格,那首先呢,满足第二范式吗?满足那这里边呢,我们这是主件,剩下的这些呢,是不是都完全依赖于我们这个主件了,没问题,但是呢,不满足第三范式,因为呢,其中呢这两个字段。这两个字段的话呢,你可以理解成我们这个商品类别名称呢,实际上呢,它是不是可以理解成依赖于我们商品类别,商品类别ID,而商品类别ID呢,是依赖于我们这个主建的,对吧?那这种情况呢,就不允许它存在,怎么办呢?诶那就把这两个是不是单独先拿出来一下,诶我们这时候呢,就再先构建一个叫商品类别这个表,这个ID的话呢,就是我们这个商品类别的这个呃主建ID。啊,然后呢,我们还有这个商品类别的一个名称啊,这呢构成一张表,然后呢,在我们这个商品表里边儿呢,你只需要呢,罗列我们这个商品类别的ID就行了,不用再去罗列我们这个商品类别的名称。
19:07
哎,就这个意思啊,这呢就满足我们这叫三反式。好,接着我们再给大家举这个例子啊,就是多个例子呢去举,让你加深对这个散法式的一个理解,然后这儿呢,有个叫球员表对吧,学员表里边呢,有这个球员的姓名,有这个球队的名称,有这个教练的啊,球队这个教练啊这样的几个值。对吧,哎,这样几个值。那么这几个值的话呢,满足阿尔法式吗?显然是满足的,因为呢,我们这里边儿的看球员的名称,球队的这个名称,还有球队这个教练呢,他们呢,是不是都是完全依赖于这个球员编号的,对吧?但是呢,这里边儿呢,关于这个球队教练的话呢,发现他其实呢,是依赖于我们这个球队的名称的。然后球队名称呢,是依赖于我们这个球员编号的。哎,所以说这里边儿呢,它就不满足这个第三范式啊,那怎么办呢?那你就把这两个是不是单独拿出来,单独拿出来的话,你可以构成一个叫球队表,球队表里边呢,有这个球队名称,有这个球队的教练啊主教练,然后呢,这个球员表里边呢,你有这个球员的名称,呃,球员编号,球员名称,还有球队的名称啊就可以了。
20:08
没问题是吧?好,然后的话呢,诶,这是我们举的三个例子,咱再针对于咱们讲的这个第二范式里边的这个,呃,第三个例子呢,咱们在这个基础上呢,哎,再进行一个修正,相当于把它呢改成符合这个三范式的,杨丽呢,就是这个呢,它不满足我们的这个三范式啊,哪不满足了呢?嗯,主要呢,其实就到我们这里边,这呢是我们这个订单的ID,对吧?那么订单的时间呢,肯定是完全决定于订单ID的,然后那个customer ID的话,这其实也也是这样理解,阿尔凡式我就不多说了啊,就每一个呢,是不是都可以有我们这个逐渐的是完全依赖的,对吧。然后的话呢,你在看啥呢,我们这里边儿呢,其实关于这个叫company name啊,这个叫呃原其实就是这个顾客呢,他本身的所属的公司啊,对吧,他其实呢,是不是依赖于我们这个叫卡麦迪啊。对吧,哎,它这存在一个针对于这个非啊,你叫非这个主属性也行,或者叫这个非这个主键这个字段也可以啊,哎,这存在一个这样的依赖关系,他们之间相当于是不独立的是吧,只要不独立的话呢,就不满足我们这个三范式了。
21:11
啊,那这时候我们就得改造改造,你就把这俩拿出来,这就专门建一个是不是叫customers这样的一个表,然后一个customer ID我们的name,然后在我们的这个表里边呢,是不是只放一个custom ID就可以了。啊,没有问题,好啊,那这时候呢,我们也通俗的去理解一下这个三范式,这个三范式的话呢,诶既然说到三范式,它肯定是满足二范式的,所以把二三呢合在一起,就是每个呢飞剑的属性。可以说非主键属性是吧,它呢都依赖于这个键,然后都依赖于整个,呃,这个后边这个键呢,就是主键的意思啊,哎,非主键的属性呢,都依赖于这个主键啊,都依赖于整个这个主见啊,并且呢,除了这个主见之外呢,别无他物。啊,就是我们依赖于整个这个键呢,相当于想表达的就是我们满足的是这个二反式对吧,你不能部分依赖,然后呢,并且呢,依赖他们之外呢,还别无他物,就是你跟其他的这些呃键之外的这个非主键的这些属性啊,你你们之间是独立的啊,不能够有依赖关系的啊这呢就说的我们这个呃,纯粹的这个第三部分的这个范式的内容是吧?OK啊,这个呢,就是我们讲的这个三范式啊好,那这呢我们就讲完了,讲完以后的话呢,咱们来看一下这个小节,这里边呢,我们提到了第一范式,第二范式和第三范式,第一范式呢,主要是保证每列呢,是保证有这个原子性的不可再分了啊OK,然后第二范式呢,就是每一个列啊,跟我们这个主键呢,都得是完全依赖的关系。
22:31
啊,这个是非主见的这些属性对吧。好,然后呢,第三范式呢,就是说你这个呃,非主键的这些属性之间呢,呃,他们得是这种独立的关系。啊,跟主见之间呢,是直接相关的啊,你们不能直接再去这种有依赖关系了啊,就是你们之间好,那么这个呢,说清楚之后呢,咱们来看看这个范式呢,有什么优点啊,那主要的一个优点的话呢,就是我们消除了数据当中的一些冗余的特点。啊,应该大家能够非常直观的能够看到这个冗余的这个消除,对吧,然后呢,这个呃,第三范式呢,通常被认为在性能扩展性和数据完整性方面呢,达到了一个最好的平衡。
23:09
啊,那这时候呢,就提到说诶平衡,一般一说到平衡的话呢,是不是说就是说诶对这些有利,对那些有利是吧,就有好的有坏的,我们达到一个平衡的一个状态,那我们目前呢,这块提到了,其实都还算是一些比较好的一些特征,那现在呢,我们就要知道,哎范式呢,到底有哪些缺点。对吧,哎,大家缺点,诶大家你会发现呢,我们呃越往下拆的时候呢,原来咱们就只有一个叫订单表,现在呢,是不是拆成了三个表,越拆是不是表越多越拆呢,表越细,这时候呢,其实冗余呢就越低。冗越低,但是什么会越麻烦呀?查询是不是就越来越麻烦,你想原来呢,我们就只有一个叫orders这个表,那你要是查询相关的信息呢,是不是直接呢就从我们这一个表中去查就行,那你在过滤条件中是不是还可以用索引,但是现在呢,我们有三个表了,三个表就意味着你是不是要照了,那照的时候呢,有的时候我们这个写法不对的话呢,首先本身呢,多表查询呢,就会效率低一些,跟你单表比,其次的话呢,你要是照样写的不是特别合适的话呢,所以呢,是不是也就失效了。
24:08
哎,这呢,就是我们带来的相关的问题啊,整体来讲呢,范式呢,就会降低我们查询的效率。诶这个要关联多张表啊,这个首先呢,代价本身就很高昂,其次的话呢,可能会导致这个索引失效啊,诶就这么着,那那这时候实际情况呢,我们讲的说这个范式啊,只是我们提出了一个设计的标准,在实际设计表的时候呢,没有说非得要遵循这些标准了,你可以根据实际情况上,你看你遵循到哪一档上,诶就这个意思啊,但是一般情况下呢,咱们在开发中呢,通常呢,诶都会去遵循这个第三范式了啊,当然前提呢,是不是一二都满足了对吧?哎,一说到第三范式,一二肯定是已经满足的情况下。OK,就是我们就不会再去追求,比如说像呃八四范式啊,第四范式啊,第五范式啊,乃至这块写了个叫预见范式啊,就不会追求的那么高了,因为越往下追求呢,相应的这个弊端呢,也会更突出一些,对吧,OK。行,这就我们说的这个点啊,那么在实际咱们开发当中呢,有的时候呢,还为了呢,呃,要提升我们相应的一些这个执行的效率呢,咱们还要进行一些反范式化的一些设计,就是增加相应的一些少量的冗余,来提高我们这个毒的性能啊,那增加冗余的话呢,是不是相当于就浪费空间了,相当于我们就是通过空间呢来去换取时间啊,实际当中的话呢,大家要具体问题具体分析啊,哎,这就我们的最终的结论啊。
25:25
好,这呢,我们就提到这儿啊,这里边提到说没有完美的设计,只有合适的设计啊,这句话呢,其实放在哪是不是都对啊,没有完美的情人,只有适合自己的那口子是吧?哎,OK啊,就是什么情况下,其实很多时候都是这样子的啊吧,好,那这块呢,我们把这个3万式呢,就给大家交代清楚了。
我来说两句