00:00
呃,来各位同学,那咱接下来呢,看一下我们下面的一个知识点,这个知识点呢,名称叫做多值维度,首先我先告诉大家什么叫做多值维度呢?多值维度是一个现象,是我们在去设计维度模型的时候,可能会出现的一个现象啊,那这个现象呢,诶,我们需要去解决它,OK,好,那接下来咱们先看一看这个现象到底是什么啊,来看一下啊,他说如果事实表当中的一条记录对吧?在某个维度表当中有多条记录与之对应,那这个现象呢,我们就称之为多值维度,诶这个怎么理解啊,来大家琢磨琢磨啊,你说正常情况下我的一个事实表对吧?去关联维度表的时候,事实表里的一行数据应该关联维度表里的几行数据。事时跟维度正常关联,事时表的一行应该关联维度边的几行是不是正常,应该就是一行对比,我举个例子啊,假设这个事时表我们是一个下单的实时表,那下单的实时表里边,比如说我会有用户这个维度ID对吧?那用户ID我是不是正常就只关联一个用户啊对不对?那这里边我是不是还有可能会有,比如说呃,这个地区ID对吧?那我是不是只关联一个地区啊对吧?那通常情况下是不是就是呃事实表里的一行关联维度表里的一行数据啊,对吧?通常是这样的,但是呢,在我们设计这个维度模型的时候,如果你设计的不是那么的合理,就可能会出现这样的一个情况啊,什么情况呢?就说OK,我这儿有一张实时表,那这儿呢,是我设计出来的维度表,OK,那完了之后呢,我的事实跟维度它会有这样的一个关系,事值表里的一行会对应某张维度表里边的多行数据,那这个现象呢,我们就称之为多值维度,哎,是这样的啊,好了,弄完之后呢,接下来我们就来琢磨琢磨啊,就是这个多值维度的问题咱们如何去解决。
01:50
啊,如何去解决啊,大家想一想啊,你你这里边为什么这是一个问题啊,为什么是一个问题,这个其实很很好想,大家想一想啊,就是正常情况下,我们这个事实表当中,理论上是不是会有各种各样的维度I键呀,对吧?那一个维度ID下边,比如说用户ID下边,我是不是理论上就存一个UID,然后呢,让他去关联一个U就完事了,对吧?好,那如果你像出现这种情况,我是不标的一行数据,我需要怎么样去关联这个维度表里的三行数据,那理论上你这个维度ID是不是应该有三个不一样的ID啊对不对,这三个不一样的ID在这我怎么存呢?是不是不太好存,这是不是咱们需要面临的一个问题啊,对吧?那就是多值维度是我们在设计维度模型的时候遇到的一个问题,好,这个问题如何解决?那现在呢,我们一起来看一下,那先生在这儿呢,我们通常有这样的两种情况啊,首先第一种情况呢,就是啥?就是降低事实表的力度啊,OK,这个可能听起来有点费解啊,那在这儿我给大家举一个具体的例子,大家应应该就能想明白了,OK。
02:50
那各位同学啊,就像咱们前前面其实咱们提到过,就是我们在设计事实表的时候,设计事实表的时候啊,我们每一张事实表,我那个力度是不是应该尽量的选择最小力度啊,对不对,这个其实之前提到过啊,那假如说我们现在呢,哎,要设计一张事物实表,这张事务时表呢,它对应的业务过程是下单是下单啊,那理论上下单这个业务过程,咱们最细力度应该定到哪个力度,应该定到明细力度对吧?应该精确到一个订单里边的一个商品才行,对吧?但是假如大家在设计这个实时表的时候呢,没有考虑到这一点,或者没有想到最细力度到之后呢,你把下单时表的力度定为什么了,就定为older info,诶你这么去定的话呢,就可能会出现多值维度的情况,为什么会出现,你想一想,你想啊下单你说跟商品维度有没有关系,是有的,对吧,OK,好,那么之后,所以这儿呢,我正常是不是会有一个SKU这样的一个商品维度表啊,对吧?好,那一行就是一个SKU,那你想一想,我事实表当中,我现在一行是一个。
03:50
什么是一个info,那一个order info里边是不是可能会有多个SKU,对吧?那这不就出现了咱们这所谓的多值维度的问题了吗?你一个order info是不是就会对应多个SKU啊,对吧?哎,那这就是所谓的多值维度,好,那这个问题怎么出现的呢?实际上大家应该能感觉出来,这是不是就是由于我们事实这张事实表的这个力度选择不合理导致的呀,对吧?好,那这时候你怎样去解决这个问题呢?
04:15
好,那我是不是只需要将事实表的力度降为什么就行了,降为明细力度,我一行我现在是一个older detail,而不是一个olderf对吧?好,那完之后呢,一行一个older detail,一个older detail是不是只关联一个SK对不对?OK,那这样一来,这个多值维度的问题是不是就解决了呀,对吧?哎,这是我们解决多值维度问题的一个方案,那这其实也是呃,最常用的一种方案啊,也就是绝大多数情况下,你出现了多值维度的问题了,那很有可能就是咱们这个市十表的力度你没有选对,你没有选择对齐力度啊,所以说以后大家如果在设计的过程当中遇到了这个多值维度的现象,首先就得先反映一下,或者先去看一看,看看自己的实时表的力度是不是有问题啊,这样的啊,OK,有问题那就降力度,那如果说实在是这个力度没法降,我已经是最小力度了,OK,那这时候呢,我们就得考虑第二一种方案了,好了,OK,那接下来呢,我再举一个具体的例子,我们看一看,就是在什么情况下,我这个力度是没法降。
05:15
比如说我这儿有一个这样的场景啊,什么场景呢?呃,假如假如说我有一张实时表,那它所对应的业务过程是什么呢?是签合同这个业务过程,那比如说我们这儿呢,是一个呃个呃什么样的公司,咱们背景就不多说了啊,大家就随便举个例子就行了,那这个市表对应的业务过程是签合同,那你想一想啊,可能我每一个合同是不是都可能需要由多个业务员去负责呀,对吧?啊,这样的一个合同可能由多个业务员负责,对不对?OK,好,那完之后呢,我这张实施表当中,你说我每行数据,我代表的应该是一个什么含义呢?是不是应该是一个合同我作为一行啊,对吧?签订一个合同我就作为一条记录,签订一个合同我就作为一条记录,对吧,那完了之后呢,我们刚才提到了一个合同是不是可能由多个业务员去负责,对吧?那业务员在这儿应该算一个什么呢?是不是算一个维度啊,没问题吧,算一个维度好,那这个维度当中呢,每行是不是应该是一个业务员的信息,对吧?那刚才提到了一个合同可能由多个业务员负责,对不对?那。
06:15
这时候是不是也出现了,我们刚刚提到那个问题,什么问题啊,是不是多支维度啊,对吧?一个合同是不是由多个业务员负责,那是不是也是多支维度,好,那这种情况下,那我们能用第一种方案去解决吗?我能不能说把师表的力度给他降一下,这个有法降,这个就没法降了,对吧?你这一个合同我咋降啊,对不对,我我怎么给他拆呢?对吧?诶这个没法拆,就是在这种情况下,你这个降力度就不好使了,实在是降不了力度,那这时候怎么办呢?采用第二种方案,那第二种方案怎么去做呢?你可以这样去做啊,在事实表当中采用多个字段去保存多个维度值,那完事之后呢,相当于是每个字段保存一个维度ID,哎,啥意思呢?你这儿不是说了吗?我一个合同,我是不是比如说有三个业务员去负责,那我这可以怎么做,我加上三个业务员的ID呗,对吧,业务员1ID,业务员2ID,业务员3ID,那么之后是不是让这三个ID分别去关联与之对应的三个业务员啊,对吧,你这样就能把这个,呃,就是一个合同。
07:15
对应三个业务员的这个关系保存下来了,也就是说我加三个业务员维度外建,哎,你可以这样去做,但是这样去做的话,其实是不是有一定的弊端呀,对吧?有什么弊端,是不是有可能会出现这样一个情况,就我有的合同我需要三个业务员,我有的合同呢,我可能需要五个业务员,但是有的合同呢,我只要一个业务员,对吧?那这样一来的话,你设计几个维度外建比较合适呢?对吧,你设计三个满足不了五个的对吧?哎,你设计一个满足不了三个的,对你这个怎么设计比较合适呢?百东和说了,我设计最高的,你是不是最多就五个呀,对吧?那我就来五个维度外线,但是你五个维度外建啊,这里边其实可能会有大量的什么出现。空值对吧?比如说我这个就一个业务员,那你是不是空着四个字段呀,对吧,这个其实是不太合适的,对吧?所以在这种情况下呢,呃,这种方案只适用于哪种啊,适用于是不是多只维度个数固定的情况,对吧?我所有的合同都是三个业务员,那你们就加加加三字段,这个是合理的对吧,是这样,但是对于那种就数个数不固定的情况,你这么做就不好使了,那不固定我应该怎么做呢?呃,对,其实也不用接子,咱们现在你说咱们用的是have对吧,咱们用have have当中是不是有一个复杂数据类型的概念对不对,复杂数据的咱们有什么复杂数据来着,有数组A,还有map对不对,还有什么来着,Stra的结构体对不对?OK,那所以在这呢,你可以用什么字段数数组实际上就可以,对吧,你就来个数组对吧,数组里边我想保存几个ID,我就保存几个ID,没问题吧,是不是就来一个数组类型的字段里边呢,保存我们每一个合同相关的业务员ID呢,就完事了,对吧?那是这样的啊,那所以对于这种个数不固定情况,我们可以考虑使用have当中的复杂数据类型去进行存储。
08:55
啊好了同学们,那截止到现在呢,多值维度的这个问题咱们就说完了啊这样的啊,然后呢,大家一定要知道什么叫做多值维度,然后呢,出现这个多支维度的现象之后,咱们怎样去解决,那最常见的其实就是第一种,如果你的试表的力度不合适,往往就会出现咱们这个多支维度的问题啊这个大家注意一下就行了,行,完成之后视频我停一下。
我来说两句