00:00
嗯,好,同学们,那现在我们看一下这个三范式当中的第一个the first normal form,也就是第一范式对吧?来,我们现在打开这个PPT看看第一范式,那它的这个,诶核心的这个规范是什么?来看一下他说第一范式the first normal form,它的核心原则就是属性不可切割,诶那这呢,提到了一个概念叫做属性,对吧?这个属性是啥意思?属性是啥意思?实际上这个属性呢,是哎,这个ER模型当中的概念,是ER模型当中的概念啊,也就是那个实体和关系模型里边概念,之前我们提到了实体关系模型,我们是不是把所有的数据都抽象为实体加关系啊,对吧?那这个属性指的是谁的属性呢?指的就是实体的属性,就是实体的一个一个的属性,比如说我现在这个实体我是一个班级,对吧?那咱那个班级可能有哪些属性呢?我可能有班级的名称,有班级所在的那个教室的编号等等等,这是不是都是这个班级的属性啊,对吧?就是这个意思啊好,那完之后呢,我们继续往下进行,那这个实体关系模型,最终最终咱们是不是需要给它,诶翻译成这个所谓的关系模型啊,对吧?你得翻译成一张一张的二维表,对吧?那实体关系模型当中这个属性就会对应关系模型当中的什么东西啊。
01:17
说白了就是那个表里边一个一个的啥呀,是不是字段呀,没问题吧,对不对,你比如说我这儿呢,有一个学班级属性,我会有一个是不是班级,班级的一个表跟他对应啊,对吧,那班级属班级里边的属性对应就是班级这张表的各个字段啊,就这个意思啊,所以他这所提到的这个属性不可切割,实际上指的就是啥呢。就是表当中那个字段,它不能切割对吧?那什么叫做不可切割呢?哎,首先我们先看一个这种可以切割的这样的一个返利啊,来咱们看一下,那这儿大家看到的就是一个比较简陋的一个订单表啊,比较简陋的一个订单表,这个比较简单内容,咱们来简单看一看,里边大概有什么内容啊,那首先呢,这里边呢,有一个商品,有一个商家,有一个用户ID,这相当于什么呀,是不就是记录了这个人在这家里边买了这点商品啊对吧?是这样的,好,当然这张表其实就是一个非常明显的不符合第一范式的一个设计,哪个字段不不符合呢?实际上一眼就能看出来,对吧,显然就是谁啊,就是商品对吧?OK,那我要想让它符合第一范式,我应该怎么去设计它呢?
02:23
怎么办呀,我给它拆开数就行了,对吧?一个字段我是不是拆成俩字段,一个是商品的名称,一个是商品的数量,哎,那这样一来咱们就符合第一范式了,诶,那这实际上呢,就是第一范式的核心原则,那就是啥呢?就是字段里边的内容是必须得是原子性的,不可切割的才行,OK啊好,那当然呢,这个第一范式它用到我们刚刚所提到的那个函数依赖了,其实并没有用到对吧?哎,我们后边的第二第三范式才会用到函数依赖的概念啊,这个第一范式相对比较简单啊,那它的简单体现在哪呢?首先第一个简单在于,呃,如果一张这个表它不符合第一范式,我是不是一眼就能看出来,对吧?其实这个很容易发现的啊,是这样的啊,然后呢,我发现这种所谓的第一范式的这个问题之后,我怎样让他去满足第一范式呢?其实也很简单,是不是又把这个字段我拆成多个字段,那就完事了,对吧?啊,也就是第一范式相对比较简单,虽然它简单啊,但是它非常重要,为什么呢?因为第一范式是所有。
03:24
找的这个范式的一个基础,对吧,如果这个要是不满足后边的第二范式,第三范式是不是也没有办法满足啊,对吧?那所以说它非常简单,但是很重要啊,好了,那第一范式咱们理解到这个程度就够了,紧接着我们来看第二范式,第二范式相对来说就没这么简单了啊,我们首先先来看一下第二番式,那它的一个核心的要求是什么,来看一眼。他说了第二范式的核心原则是不能存在部分函数依赖啊,当然各位其实这个说实话啊,他这么说,这句话说的不是特别的完整,这句话说完整了应该怎么说呢?应该这么说是不能存在非主见字段,部分函数依赖于主键字段。
04:08
啊,来,我再重复一下这句话有点长是吧?啊,但是不能存在非主见字段,部分函数依赖于主见字段啊,是这样的啊OK,非主见字段和主见字段这应该是能够搞清楚的对吧?啊OK,好,那咱接下来呢,我们来看一下这个第二范式核心原则具体怎么体现啊来看一眼,那这张表咱又给它搬出来了,这是就刚才我们看到的这张成绩单呀,对吧?生绩单里边是不是显然是存在数据冗余的,没问题吧?好,那完之后我们现在就来看一看,就是这张表它到底符不符合我们这个所谓的第二范式啊OK,好,那咱们就来找一找,到底是不是存在非主键字段部分依赖于部分还是依赖于这个主键字段啊,对吧,咱们找一找就行了,好,那现在我们先来明确一下,谁是主键字段呀。学号是主键字段吗,是吗?显然不是,为啥呢?主键是不是得具有这个非空且唯一的特点,对吧?那这个显然是是唯一的吗?它不是唯一的呀,对吧?那所以它肯定不是主键,那谁是主键。
05:08
对,应该是学号加课名,是不是组成一个联合主件对吧?这都标红了对吧,大家还说不对,呃,这是这是咱们所谓的联合主件啊好,那接下来咱们继续往下进行啊,好,主键咱们已经确定了,那接下来我们就来明确一下,这边到底是否存在这个所谓的非主键字段,部分函数依赖于主见字段的现象,OK,那这是主见字段,其余的是不是就是所谓的非主见字段呀,对吧?那咱们找一找呗,你看这个。它是不是部分函数依赖于主键字段呢?显然是吧,对不对,那它是不是只依赖于我这个主键当中的学号啊,对吧,所以这个是部分还是依赖好继续往下看,那戏名呢。其实也是一样的吧,你只要知道这个人的学号是多少,你是不是就能断定他是哪个系的呀,对不对,跟他学什么课程是没没有多大关系,对吧?那所以在这儿呢,系名也是部分还是依赖于选号的,呃,加这个课名的,哎,这也是啊,好,继续往下走。
06:04
系主任呢?系主任跟系主任通常是通常是一对一的一个关系啊,对吧,那所以说你系名要是部分还是依赖于主见,那系主任是不是也是部分还是依赖主见啊对吧?那所以说这三个字段都是部分函数依赖于主键字段,好最后分数分数它是部分函数依赖是不是。分数不是,刚才咱们就分析过了,分数实际上呢,是完全函数依赖于学号加科名的,对吧?那所以说分数这儿不是部分函数依赖,那所以咱这儿存在不存在这个部分函数依赖,这个这个概念呢,是存在的,对吧?那所以说咱这是不是有这个数据的冗余啊,对吧?好,那现在咱们思考一个问题,我怎样去把这些所谓的部分还是依赖给消除。大家说怎样能把这个所谓的部分二依赖消除?怎样能消除?怎么消除?其实很简单,你想一想啊,既然这三个字段对不对,它不依赖于课名,那我就可以怎么做了。
07:03
我是不是单独的成立一张表对吧?这张表当中我只有谁,只有姓名,姓名系主任这仨字的再加谁,再加上他们所依赖的那个学号是就完事了,对吧?那剩下的这张表里边就只有谁了,只有学号科名加分数了,对吧?哎,那这样一来是不能解决这个所谓的部分还是依赖的问题,好,那假如说我们按照我们刚才的规划给它拆开了,拆成这样了,拆这样之后,你会发现这里边有一个神奇的现象,什么现象呢?数据的冗余是不是消失了对不对?你看啊,就是原来你像这条信息我可能会存多份对吧?这一条我是不是也存了多份,这条我同样存份,但是你拆完之后,你会发现是不是各自只需要存一份就完事了,对吧?那数据的冗余是不是也随之消失了呀,对吧?那这实际上呢,就是我们第二范式它的一个呃,核心的原则对吧?就是你只要把这里边存在的这种所谓的部分还依赖消除,对吧?那我们的数据的冗余自然而然就能够消失,对吧?但是啊,不是完全消失对不对?细心的同学应该能够发现,就是我们这个表拆完之后仍然存在数据冗余。
08:06
哪儿存在,大家来看一下,你看系主任,呃,这个经济系王强,经济王强是不是还是重复存储两份啊,对吧?所以这儿仍然存在所谓的数据冗余,但这个数据冗余是由于我们不满足第二范式导致的,其实并不是刚才我们已经把这个第二范式里边的部分还是一类已经消除了,对吧?我们现在已经满足第二范式了,但它仍然存在数字主义,那就不是他的问题了,那应该是谁的问题呢?应该是下边一个第三范式的问题了,对吧,他可能是不满足第三范式的,好,那现在我们再来看一看第三范式。来,那大家一起来看一眼,那第三算式的核心要求是什么呢?这个先不用看啊,来看上面他说第三范式的核心要求就是不能存在传递函数依赖,OK,好,那当然这句话其实说的也不全,说全了应该怎么说呢?也应该是不能存在非主键字段传递函数依赖于主键字段,哎,OK,那这样一来的话,我们应该把这个核心原则就说完了,我们一起来看一下它具体怎么体现啊来,我们还是找到刚刚我们拆完的那张表,这是我们刚刚拆开来的一张表,对吧?这张表是不是也存在数据冗余啊,对吧?好,那现在咱就来分析分析这张表里到底是否存在所谓的传递函数依赖啊,存在肯定是存在的,这儿已经说的很清楚了,对吧?但这个东西他给出来的,那我们可能体会不深,对吧,怎么样能体会的更深刻一点了,咱们自己找一下,我们自己找一下,这里边有没有所谓的传递,还未来。
09:33
这个怎么找啊,你要想找到传递函数依赖,那你就得把什么,把这张表当中所有的函数依赖是不是都得找着,都找着是不是才能看它有没有传递啊,对吧?好,那咱接下来就开始找啊,那首先我们先以这个主键作为自变量,用它作为X,那你想一想用它能不能推出来姓名。能对吧,学号到姓名,这肯定是一个函数依赖对吧,这个没问题,好学号到系名呢。
10:00
可以,给一个学号,能出来系名没问题,那系主任是不是同理,对吧?给你一个学号是不是能得到咱们系主任的名称,那这个名字啊,对吧,应该是没问题的,好,我们继续往下走,那完后我们再找谁呢?我们再以姓名作为自变量,对吧?然后用它去推其他字,咱们看能不能推出来啊,给一个姓名,大家说能不能到一个学号。就能得到,这个就不能了,为啥?因为姓名他是人对吧?人是不是他是人名对吧?人名是不是可能会重复啊,对吧?那重复之后会出现什么问题,比如说有俩叫李晓明的,那可能说什么问题,是不是一个李小明对应两个学号啊。没问题吧,OK,那这相当于是什么?它还是函数吗?不是函数,函数不有要求一个X只能对应一个Y啊,对吧,你相当于一个X不对用两个Y了,对吧?它连函数它都不是,就更别提什么函数依赖了,对吧?所以说姓名是不能作为自变量的,没没问题吧,它是不是直接pass掉了,对吧?你从姓名到姓名,系名到系数,人是不是都会存在同样的问题对吧?这个直接pass掉下一个我们看戏名,那戏名大说能不能推出来学号。
11:01
也推不出来,一个系下边是不是有太多的学生来,对吧,也是一个X对多和Y这个不行,那同理姓名到姓名也不行,那系名到系主任呢,能不能推出来。这个就是大家可能有时会抬杠啊,就是你这一个系下边要是俩主任,那那那是不是就不行了,对吧,那咱这不去抬杠,我们就假定一个系下边就一个系主任,那所以说一个系名能不能推出来一个系主任是可以的,对吧,咱们还定就一个啊好,这是能推出来的,所以这个没有问题,那这是一个函数以外,好,我们继续往下走,那系名,那系主任能不能作为自变量的。能不能?不能,他也是人名对吧,人名就可能会重名对不对,假如俩系主任都叫王强对吧,那我可能会对应两个不同的系对吧,那这个肯定也不行,所以他也不能作为自变量,那就是到目前为止,咱这张表当中存在的所有的函数依赖,咱是不是就都找到了呀,对吧?那里边儿存在不存在传递函数依赖呢?是不一眼就能看出来对不对,是不是学号到系名,系名到水准任这是一个传递啊,对吧,那我们这里边我们说谁呢?我们说系主任是传递函数依赖于谁呢?学号的是这样的,OK,那所以说在这儿呢,咱们是存在这个所谓的传递函数依赖的,OK,那存在我们是不是就得想办法给它消除啊,对吧,好如何消除。
12:14
啊,其实下面已经给出来方案了,怎么消除啊。是不是还是拆表啊对吧?OK,好,那刚才提到了,就是你的系名,系主任再加学号,他们之间有这种所谓的传递关系,对吧?你有传递关系我就直接给你,是不是一刀两断呀,对吧,我直接给你斩开,你是不是就没有这个传递了,对吧?好,那斩完之后是什么样的呢?诶长这个样子,哎,大家来看一看啊,就首先那我这边那是不是咱们应该是这俩字段呀,对吧?那里边还存在那个数据冗余的情况吗?就。不存在了,对吧,就不存在了,你看这时候很明显啊,对吧,这里边有,诶精气王翔,那原来是两条,那我现在是不是只有一条了,对吧?那法律系刘伶,那我也只有一条,这个是没有问题的,好了,那左边咱们剩下的字段有谁呢?有学号,有姓名,有姓名对不对,这里边本身就没有冗余,对吧?所以说这个是OK的啊OK,那这样一来的话,那我们这部分数据冗余它也就给它消除了啊OK啊,当然这个消除之后呢,我们正常情况下,这里边还得再做进一步的处理啊,就是一个表拆完之后,你不能直接就这么放着,我们这通常我们需要怎么去做呢?咱们通常会这样去做啊,OK,我会在这张表当中,我给它加上一个什么呢?加一个字段,对,加上一个ID,相当于是一个什么的ID呢?你可以理解为是一个系的ID对吧?OK,比如说这个ID是一对吧,那我这个ID是二对吧,那我这边我还去保留经济系什么法律系这个词吗?我不保留这个文字说明了我只保留一个什么就行了,系的ID是不就完事了对吧?这个放个一,这个放个一,这个放二,通常你需要再做进一步的。
13:45
处理OK啊好了,那这就是咱们这个第三范式的核心原则,好了,各位同学,三范式咱们现在就学完了,对吧?学完之后,那大家现在应该已经对数据库规范化有了一个比较充分的这个了解了,对不对,咱们现在应该是知道什么叫做规范化了,对吧?到底什么叫规范化呀,是不是就使用我们刚刚所提到那一系列的规范去对数据库里边的表进行一个呃这个设计啊,对吧?在设计的过程当中,我们呃不断的遵循这个范式,那我们的数据的冗余会不断的消除,对不对,当然这个表呢,是会不断的被拆开啊,对吧?那这就是数据库规范化的这样的一个过程,对吧?那规范化完成之后,我们确实能够实现减少数据冗余的目标的,这个大家应该是能够亲眼看到的,对吧?诶这一点大家体会下就行了,好了,数据库规范化的概念咱们也就说完了,好,那说完之后呢,我把视频给他停一下啊。
14:36
啊好,各位同学,那咱接下来呢,再回过头来看一下这个比尔伊蒙对吧?他建议我们的见文方法到底是什么?来一起再把它读一遍,他说舒仓之富呢,呃,比尔一蒙他提出的建文方法是从全企业的高度,呃,这个从全企业的高度,这个大家是怎么理解的?什么叫从全企业的高度?哎,这个应该这么去理解啊,就是我们当然呢,这个企业咱们规模有大的有小的,对吧?OK,那我一些就是规模比较大的这个企业呢?OK,那它里边可能会下分为什么呀,就是不同的业务板块啊,是这样的,比如举个例子啊,咱们以这个,呃,阿里巴巴为例,对吧?那它下边实际上呢,是不是会分,为什么淘宝会分,为什么天猫还会还有一个1688对吧?
15:22
没错吧,那个应该是就做那个就是批发的对吧?诶是这样的,它有不同的业务板块,那我所谓的从全企业的高度,这个什么意思呢?这啥意思啊,什么叫从权企业高度,是不是就是说我需要把整个企业里边的所有的业务板块的数据,或者所有部门的数据,我是不是都统一的进行建管处里啊,对吧?啊,这就从全企业的高度啊,也就是我会打造一个中央的数据仓库,是一个企业级别的中央的数据仓库这样的,这就所谓的从全企的高度啊好,那你把这些所有的业务板块,所有部门的数据都收集到一起之后,接下来干啥呢?你需要用这个所谓的实体关系模型去描述这个数据啊,所谓描述数据就是怎么做呢?诶,你就要把所有的数据拿过来之后呢,我是不是给它统一的抽象成一个一个的实体,对吧,然后呢,再去明确每个实体与每个实体之间的这个这个关联关系啊对吧,还是际是一对一还是一对多,还是多对多等等等,你需要去画一个这种企业级别的这样ER图对吧。
16:22
好,那完成之后,咱接下来需要干啥呢?是不是我们需要把这个ER模型翻译成什么模型?关系型数据库里边的模型,也就是所谓的关系模型,对吧?哎,你需要去翻译成关系模型,但是翻译成关系模型说的具体一点就是干啥呢?你需要最终在买四个当中,把这个诶一张一张的表是不是给它建出来啊,对吧?诶当这个表呢,我们不能随便建,你建完这个表之后呢,你需要对它进行一个什么操作,是不是进行一个数据库的规范化的操作啊,对吧?那规范化的时候,我们应该是不是用什么去规范化,是不是用那个三个范式啊,对吧?诶是这样的,那我在规范的时候呢,我不需要规范到最高的级别,我只需要规范到第几范式就够了呢,我只需要呃规范到第三范式就够了,因为在第三范式呢,我是能够取得一个就是查询性能和数据冗余之间的一个平衡的,对吧?诶是这样的,诶这个查询性能我们也能接受,数据的冗余我们也能接受,那所以说在这样的,诶,他要求我们规范到第三范式就可以了,OK,那这就是比尔伊蒙他所建议的这个建模的方式,OK啊好了,那到现在为止,大家这段话应该是差不多能理解了啊啊。
17:30
那接下来呢,为了呃,加深大家的一个理解啊,我们再继续往下看,我们下边那有一张图往下走,哎,这一张图,这张图呢,就是一个什么?就是一个采用比尔伊蒙所倡导的建玩方式构建的模型,对吧?那大家看到这个模型之后,你的第一感觉是什么?你看这个模型之后第一感觉是什么?嗯,第一感觉啥呀,第一感觉就是不想看是吧?第一感觉是啥呀?呃,其实文档上说的很清楚,那我们从这个图里边,我们应该是能够感受出来,就是这个表它较为怎么样,这个模型较为是松散零碎啊对吧?物理表的数量比较多,这应该是我们看到这个模型之后的一个直观感受,对吧?好,大家可以想一想,你说为什么这种模型它会有这样的一个特点呢?为什么松散零碎,为什么物理表数量多。
18:20
很简单,因为按照比尔伊蒙的这个建议,我们需要对这个数据库里边的表进行什么操作来着,规范化的,你在规范化的时候是不是自然而然的会把表是不是一个一个的给拆开啊,对吧,拆完之后是不是就会得到一个这样松散零碎的物理表数量多的模型啊,对吧,就是这样的,所以大家在第一的这个职工感受应该是没有问题的啊,那接下来咱继续往下看,我们再深入的去熟悉一下这个所谓的模型,来咱们看一下,他说其实下边有一个诶总结,这个总结还是比较到位的啊,他怎么说的,你看他说这种建盟方式,这个这种指的是是比尔伊蒙倡导的这种建盟方式,对吧?OK,那他的出发点是什么呢?是整合数据,他的这个主要目的是整合数据,对不对,那他是要干啥呢?是要将整个企业的数据进行组合和合并,并且进行规范化处理,呃,然后呢,诶要干啥呢?要减少数据冗余,保证数据的一致性,那也就是说实际上比尔伊蒙所倡导的这种键门。
19:21
方式,它的终极目标其实是什么呢?是整合数据,是减少数据的冗余性,它其实并没有过多的去考虑数据分析这个事儿啊,是这样的啊,那所以说呢,那这种模型呢,并不适合直接用于分析统计,并不适合直接用于分析统计,这个是怎么理解呢?大家想想这个模型它不适合直接用于分析统计,这个怎么理解?哎,这个模型就摆在这了,问一下大家这个东西适不适合呃去做分析统计啊,适不适合呀,但是我也不知道是吧?OK啊,好,那现在给大家说一下啊,就是为什么这个模型它不适合直接用于分析统计呢?其实呃,适不适合咱们自己试一试是不是就知道了呀,对吧?比如说各位同学,那现在呢,诶,我们就要用这样的一个ER模型,对吧?去做一个数据的分析统计的一个需求,我们看一看这个东西好不好做,好做它就是适合,不好做就是不适合,对吧?好,那现在咱们就来试一试啊,那当然了,我们要想用这个模型去做分析统计,我们首先得先干啥呢?得先了解这个模型才行,得熟悉这个模型的表才行,对吧?好,那现在咱们就一起来把这个模型给它大致的过一下啊呃,首先我们先看一看这个模型它是一个什么主题的啊,这是一个什么主题的呀,应该也是一个订单主题吧,对吧?你看最中间的这张表是不是叫做older hier啊对吧?是就是订单对吧?好,那完了之后它其实就有点类似于咱们那个电商系统当中的哪张表呢。
20:50
Older ino啊,类似于older ino啊好,那接下来我们继续往上看看,这这是不是还有一个older details啊,对吧,它其实对应的就是我们那个older detail表,OK,好,那接下来继续往下走看这边这是啥?Product商品是不是就有点类似于我们的SKU啊对吧?好,继续往后,往后看,这是什么?Product sub category对吧?这个是product category对吧?这是啥呀?是不是一级分类二级分类啊对吧?哎,商品的分类这个应该很简单,我们继续往左边看啊,这个是什么?是date,这个是什么是month,这个是什么是year,相当于就是什么年月日对吧?你看啊,它甚至把年月日是不是都给它分开了,对不对?那年月日这个东西你要分开之后,为什么要分开,是不是肯定还是因为你不分开的话有数据的冗余吧,对不对?为什么年月日放一起会有数据冗余,这个大家能想明白,年月日放一起会不会有数据冗余,这个大家能想明白,你放在同一张表里肯定有冗余,为什么你想啊,你放在。
21:50
同一张表里,那你说我这张这张表里一行代表的应该是一个什么呢?应该是一个日期吧,一行应该是一个日期,对吧?那我一年里边我是不是有365天,你这365个日期,他们的所属的一页,所属的年是不是都是同一年对不对,是不是相当于年,这个信息你会重复的存储300多份啊,对吧?这个道理啊,所以你放进息肯定有冗余,那你为了消除冗余,是不是得给它拆开,拆成不同的表啊,是不是还是规范化的这个问题啊,对吧?规范完之后就给它拆开了,好,那接下来我们继续往后边看啊,看这这是啥呢?Customer。
22:23
这个指的就是顾客了,对吧,或者对应的我们那个用户对不对?好,继续往下走,这个是啥?是真的,真的是不是就是性别的意思对吧,你看啊,性别它是不是也给它单独的拿出来了,对不对,这个相当于是什么呢?是不是也是数据的规范化呀,对吧?好,继续往后边看这一个location,这儿还有一个country location是不是就是地址啊,对吧,那地址后边还有一个什么。地址所属的国家country嘛,对吧,很简单,好,那接来往这儿走,这儿还有一个salesle,这个你就可以把它理解为是一个reporty,就是啥呢?是不是仓库啊,对吧?OK啊,这个大家理解一下就行了,好了,各位同学,那到目前为止这个模型当中的表咱们大概都熟悉了,好,那现在问题来了,我们来用这个模型去做一个分析统计,就是将来呢,我们去做完数仓之后,咱们会做各种各样的指标啊,就这种典型的指标是哪什么样的呢?典型的指标就是这样,比如说让你去统计一下2020年对吧,各个国家的订单总额,诶,那我们典型的需求基本上就是类似的啊,那现在我们就来看一看啊,就是这样的需求,我们用这个模型怎样去实现?来,我再把这个需求重复一遍啊,让咱们统计的是2020年的各个国家的订单总额,来大家琢磨琢磨,你说用这个模型咱们怎样去算这个数?
23:42
嗯,2020年的各个国家的订单总额,诶什么需求啊,首先咱得先找着那个订单的金额,对吧,订单金额在哪呢。找半天,这里边order he里边没有,对吧,哪有order detail里边是有对吧?明细里边是有的,好,那完了之后呢,你想啊,你要拿的是什么什么总额对吧?总额最终肯定是要对这个每个订单明细的金额求和的,对吧?啊,没问题吧?好,那接下来咱继续拿走,那你要求的什么是2020年的对吧?那所以说你是不是得先找了我这个订单明细所属的年份是哪一年的呀?对吧?你怎么才能找到它呢?你得用它去关联older header对不对?进而去关联date,进而去关联month,进而再去关联year,它是不是应当是这样的一个关联关系啊,对吧,就在这儿呢?你需要去关联这么一大串的表,你才能拿到这个订单明细所属的年份,拿到之后,将来你是不是才可以去做一个过滤啊,对吧,我因为我只算2020年了吧,对不对,好,那继续往下走,还得拿什么信息。
24:44
对,你还得拿到国家,因为你得算各个国家的嘛,所以说你得知道这个明细是哪个国家的,对吧?那所以说你还得去找国家,国家从哪儿找,你是不是也得根据它来去关联older head,对吧?关联上之后呢,进而关联customer,进而关联location,进而再去关联country,没问题吧,OK,好,那这样一来才能拿到这个金额所属的国家,好,那现在年份拿到了,国家拿到了,接下来怎么做,接下来其实就简单了,我们只需要怎么做用义去做一个过滤吧,对吧,应该是where year name等于2020对不对?好,那完之后呢。
25:19
对,分组你得by country name对吧?你得按照国家进行分组,把同一个国家的订单分到一组,对吧?然后呢,再对这一组进行一个什么操作呢?求和对吧?你对这个sales amount再进行一个萨求和,那这样一来你就能得到2020年各个国家的订单总额了,对不对,OK,那这个需求其实并不难,对吧?但是你会发现这个东西写起来是不是就比较恶心啊,对吧?你为了算这样的一个小指标,你需要去关联一大串的表,对不对,OK啊,是这样的,那所以说呃,那这样一来的话,那你应该就能体会出来,就是咱这个模型它适合去做这种分析统计嘛,其实并不是适合,并不适合,这个不适合体现在两点,第一点呢,就是啥呢?就是你这个使用成本有点高对吧,就是咱这这几张表还比较少对吧,那我是不是还得先花一点时间去熟悉你这些表啊,对吧?那如果当我这个模型里边的表非常多的时候,你再想去熟悉这个表,可能就不是花这点时间了,你可能会花更长的时间去熟悉这个模型,对不对,那所以说这个模型使用起来。
26:19
学习成本比较高,那再有一个呢,是什么呢?就是你这个真正的把这个模型熟悉了,我这个circle真写完了,我去算的时候,它的计算效率是不是也不高啊,对吧?你需要关联这么多的点,关联越多,我的这个查询性能是不是就会越差呀,对吧?那所以说那从哪个角度去考虑的,不管从哪个角度去考虑,那这种模型都不太适合直接用作分析统计,诶这一点大家现在应该是能够有所体会的啊OK啊好了,那截止到现在呢,我们就已经把这个比尔伊蒙所倡导的这个建模方方法给他了解完了啊,最终咱们得到一个这样的结论,就是比尔伊蒙他的这个建模方法的出发点是整合数据,减少数据冗余,对不对,他是不太适合直接用于分析统计的,这一点要搞清楚,行了,完成之后视频我给你停一下。
我来说两句