00:00
好,上一节我们简单熟悉了一下电商系统的业务流程对吧?啊,那本节呢,我们就要开始熟悉业务数据了啊,这个呢,其实才是我们的重点啊,因为我们数仓啊,要分析的主要就是这些业务数据啊,那分析数据的前提是不是就得熟悉数据啊,那所以说呢,熟悉业务数据还是比较重要的啊好,那我们的业务数据是不是主要就存储在MYSQL数据库当中啊对吧?那所以说我们要熟悉的啊,其实主要就是这些表,那这么多的表我们应该如何下手呢?在这儿呢,我可以给大家介绍一下我的一点小经验啊,那我去熟悉数据库的时候呢,一般就会分为三步啊,那第一步啊,我会先宏观的去看一下整个数据库。那主要就是去看一下啊,那都有什么表啊,那每张表存储的内容大致是什么?那第二步呢,诶,我会去熟悉一下每张表的表结构啊,然后大家要注意一下啊,就是我们关数据库当中啊,每表它都是一个二维的表,对吧?啊,那我们去熟悉这张表的时候呢,不要光看它的每个字段都是啥啊,我们还得注一它的每行数据是什么,这个一定要注意一下啊,那第三呢啊,我们了解了每张表的表之后啊,再结合具体的业务过程啊,去分析每张表的数据它是如何发生变化的。
01:17
啊,那这三步要是完成之后呢,诶,我们对数据库应该就比较熟悉了,那现在呢,我们就先进行第一步啊,就是去宏观的看一下整个数据库啊,咱们先简单的看一看每张表它里边存储的什么数据,来一个一个看啊来我们看第一张表活动信息表,那它的名称是activity in for对吧?啊,这里边存储的是什么信息呢?简单看一下啊,那这里边有什么活动的ID,活动名称,那什么活动类型,活动描述,看时间,结束时间,创建时间,这都是啥?是不是都是一些活动的基本信息啊对吧?对,都我我通过这个注释,我是不是就能看出来这张表存的什么内容啊,大致看一下就行,诶这张表里存储的就是活动的基本信息,这个活动大家肯定都知道是啥啊,就是我们电商的一些营销活动,对不对,促销活动啊,好下来往下走,下一个活动规则表,那它的名字呢,叫做activity rule,哎,这个活动规则表咱们看名字其实也能猜出来里边存那个是啥。
02:14
是不是应该是每个活动的具体规则没错吧?啊,然后大家想一想啊,我们一个活动它的规则是不是通常情况下会有多个呀,对吧?啊,活动活动肯定就是优惠活动,对不对?那我们的优惠级别可能有多个,比如说举个例子啊,假如咱这儿的活动呢,是一个满减类型的活动啊,那我可能会有这样的三条规则,满100减十,满200减30,满300呢,比如说我减了80对不对,这是不是有不同的规则呀,对吧?那这张表当中存储的就是啥。诶,就是这个活动的具体的规则没错吧?啊,那至于这个规则它到底怎么存的,那后续我们再去看啊,那这里边儿呢,有什么满减的金额,满减的件数,优惠的金额,优惠的折扣,那这些字段它的业务逻辑到底是什么样的呢?这个咱们现在先不用管,咱就知道这张表存的是规则就行了啊,然后具具体的内容咱们后边再看,来看下一个,下面一个呢,叫做活动商品关联表。
03:09
诶,Activity SKU啊,这个是不是就是存储了一个活动与商品之间的关联关系啊,没错吧,那你看一下这里边儿一共两个核心字段,一个是活动ID,一个是商品ID,没错吧?啊,那你想一想这个活动商品关联表,这个关联关系指的是啥呀?活动跟商品什么时候会有关联关系啊,商品,呃,商品参加活动啊,那商品参加活动,你的不叫商品参加活动啊,你叫订单参与活动啊,你刚说的是是这个意思对吧?那也是有同学可能会想啊,那这里边是不是会记录有哪些商品参与了哪个活动啊。是不是有同学是这么理解的?这个理解其实不对的啊,你要想记录能有哪些商品在下单时参与活动了,那你应该记录的是谁与谁之间的关系,应该是订单与活动之间的关系,而不是商品与活动之间的关系。
04:09
没错吧,啊,那这个商品与活动之间的关系指的是什么呀?其实就相当于是划定了一个活动的优惠范围。啊,就是说哪些商品是可以参与这个活动呢?那这样一来,只要有人去下单这个商品的,那他是不是就会参与这个活动啊。能理解吧,啊,也是这里边记录的,在再明确一下啊,这里边记录的是啊,哪些商品能够参与这个活动。啊,比如说我这里边儿有一个这样的记录啊,活动一商品ID是二啊,那你说这个商品在将来就一定会参与这个活动吗。一定吗?不一定,为啥,我可能根本就没有人买这个商品,对吧?他不买这个商品,是不是这个商品就没有参与活动啊,能理解吧,也是在这儿呢,相当于我们这儿就是划定了一个活动的优惠范围,这个一定要搞清楚啊,是这样的啊,这跟大家想的是不一样的啊,那你要真想去记录到底有哪些人购买哪些商品的时候参与活动了,那我们记录的关系不应该是商品与活动之间的关系,而是订单与活动之间的关系,没错吧?啊,这个咱们搞清楚啊,好,那接着我们继续往下走,下一个。
05:17
下一个啥,下一个呢是平台属性表,对吧,它的名字呢,是贝斯at tr in for平台属性,平台属性这个概念我们是不是刚看了呀,对吧,那这个表里边存着啥呢。你再往下看啊,下边还有一个与之对应的平台属性指标。对吧,Base at t y9它俩是不是应该是一对啊,对吧,那你说这两张表当中存的应该是啥数据啊。存的啥数据啊,咱们可以简单看一看里边的内容,看一看字段,是不是能猜出来是啥数据啊,对吧?一会看一下那平台属性表也是第一张表里存的啥,这有一个ID啊,一个编号对不对?那下一个呢,At tr name是不是属性名称,没错吧?啊,那下面呢,是它关联的这个商品的分类对不对?那接着往下走看下面这个,那这儿也有一个ID,也是编号,那下面呢,Value name是不是属性值名称啊对不对?那从这儿我们大概就能猜出来啊,你说这张表里存那个是啥?是不是应该是所有的属性名称。
06:20
对不对,那下边呢,存的是什么?是所有的属性值名称没错吧,也就具体是啥,我们往上看来找到平台属性和销售属性来,我再放大一点啊,大家看这。也就是说,平台属性表里存储的实际上是哪些内容?什么品牌、CPU型号,屏幕尺寸,热点等等等等,没错吧,包括下面还有一些什么存储卡、操作系统,这些是不是都是属于平台属性的名称啊,对不对?那这些都是啥?是不是都是属性值?没错吧,那哪张表里存的属性值是不是就是平台属性值,表里边存的就是属性值啊,能理解吧?哎,这就是这两张两张表的内容啊,然后呢,在这我们多讲一点,大家思考一下啊,你说这两张表,他们两张表的对应关系应该是什么样的啊?对,这个对应关系呢?我指的是关型数据库当中这个表的什么一对一,一对多,或者是多对多的关系,你说这两张表应该什么关系,显然是一对多,对不对啊,谁是一谁是多呀,上面一下面多对不对?因为一个属性,咱们刚才看到的后边是不是可能会有多个属性值啊,对吧?啊,那这个一对多的关系在这是怎么实现的呀。
07:27
很简单,是不是通过一个外键就可以对吧?大家注意看下边这张表,在这边这是不是那个多对不对,在多的这里边是不是会有一个一的外键呀,对吧?那它是不是可以关联到我们上面的一个属性,那这样一来我们就知道呃,这个属性值它对应的属性名是谁了,没错吧,哎,是这样的啊,就是它,哎从通过这个外键去实现这个一对多的关系,这咱们简单理解一下啊好,现在再往下走啊,下面的是不是就是这个123级分类来呀,对吧?那这个呢,就比较简单了啊,那大家都知道,我们在一个电商平台上边去搜索我们想要的商品的时候呢,诶,我们可以进行全文检索,对吧?也可以进行分类检索。
08:06
没错吧?啊,那实际上这三张表当中存储的就是供我们进行分类检索的商品分类信息,我们可以去咱的电商首页看一下啊,来大家看一下,那此处是不是会有一个全部商品的分类信息?没错吧?啊,当我们把鼠标指向其中一个分类的时候,你会发现它后边会出现更加细致的分类信息,没错吧?那比如说我指向这个家用电器了,对吧?那这里边儿呢,会出现大家电,厨卫家电,厨房小店等等等等,那在这个大家电后边是不是还会出现更加细致的分类信息,没错吧,里边有平板电视,有空调,有冰箱,有洗衣机等等等等啊在这儿大家就能看出来,咱这个分类信息呢,是分级别的对不对?那实际上这就是我们所谓的一级分类,那这个呢,就是二级分类,那它呢就是三级分类,那我们的这三张分类表当中所存储的内容就是刚刚我们看到的这些分类信息啊,那同样的道理,123级分类这几张表他们的关系是啥样的?
09:06
是不是也是一对多没错吧,是不是一个一级分类下边会有多个二级分类对吧?一个二级分类下边是不是会有多个三级分类,是这个道理吧?啊,咱们把它搞清楚啊,这个我们就不再多说了啊,现在往下走字典表。啊,这个字典表呢,其实跟业务没有太多的关系啊,字典表跟业务没有太多的关系啊,就是不管咱们这个业数据库是什么样的业务,你是电商业务也好啊,还是什么金融的业务也好,它里边都可能会存在一个这样的字典表啊,这其实很简单,这字典表里存的就是啥呢?其实说白了就是KV建值,对啊,它里边的核心字段就是谁啊,就是这个,呃,Dic code和dic name啊,相当就是一个啥,就是一个K,一个V,能理解吧,那这个字典表里存的这些KV到底是什么呢?啊,其实说白了就是对一些编码的解释。啊,对一些编码的解释,诶,那这编码指的是什么编码呢?我给大家解释一下啊,那我们后边呢,会讲一个订单表啊,这个订单表里边呢,有一个字段叫做订单状态啊,大家都知道这个订单的状态呢,是会发生变化的,对吧?啊那当然呢,它只能是固定的几个状态,我只有什么未支付的状态,然后呢,已支付的状态,然后什们已发货的状态,人们已完成的状态,是不是会有这样的几个状态,没错吧,那我们每个订单里边是不是都会存储一个这个订单的状态,对吧?但是大家要注意,我们真正在这个订单表当中存储的并不是这些状态的汉字,我们不会去存储什么未支付,不会去存储已支付,我们存储的是什么呢?是这些状态的一些编码值对吧,那比如说我用1001代替未支付,我用1002代替已支付,我们存储的这些这些编码值啊,那在这个所谓的字典表当中存储的就是啥。
10:48
就是对这些编码值的解释啊,比如说K就是1001,那我指代的就是未支付的状态,那1002我指指代的就是已支付的状态,这个大家能理解吧?哎,这就是所谓的字典表啊,咱们简单理解一下就行,好,现在往下走,下边一个呢是省份表,这个其实不用多说吧,它很简单,对不对啊,省份表里边存储的就是每个省份的信息,来继续往下走,地区表,地区表也不用多说,存储的就是地区信息吧,当然这个地区啊,大家注意,不是咱们国际上的那个地区啊,不是什么中东地区啊那些啊,指的啥是国内的地区啊,什么华北地区,东北地区,西北地区等等等等,这个大家能理解对吧?好,现在往下走。
11:26
下面一个呢是品牌表,这个也不用多说,看名字咱就知道是啥对吧?Base trademark啊,可能看名字咱也不知道是啥,不认识这个单词对吧?Base trademark啊,因为大家都经常见到,就是比如我那个商品的商标上面会有一个会有一个TM对吧。对不对,TM其实就是啥,呃,就是trademark就这个意思啊,这个咱们理解下去啊,那这个其实就是咱们那个品牌表啊品牌表,那好现在我继续往下走,那下边呢,还有一个啥,还有一个是购物车表card in,那你说购物车表里边存的应该是啥。是不是就是每个用户的购物车里边的商品呀,对吧?啊,通过这张表我们就能知道每哪个用户他的购物车里边有哪件商品,没错吧,然后他加购了几件,然后一共有多少钱,是不是咱们都能看出来啊,对吧?诶这就是这张表它的作用,好下边评价表,Comment info。
12:16
啊,首先评价这个业务咱得知道啊,就是用户下完单之后完成这个订单,是不是之后是可以去进行评价的呀,对吧?啊,这个评价表里边存储的就是用户来给这个订单所做的一些评价的内容,没错吧?哎,这是所谓的comment info,接下来下一个啊,Coupon ino这是啥呀。是不是优惠券信息表啊,库房印你说啊优惠券信息表啊,那这个优惠券信息表里存的就是啥。是不是就是优惠券的一些基本信息,没错吧,大家看一下就可以啊,来看简单看一看啊,这里边有啥,你比如说这有有什么,这有什么这个优惠券的名称啊,优惠券的类型对不对,那这些是不是一些优惠券的基本信息,那下边还有一些东西啊,下边是啥。
13:01
什么满额税,什么满减税,什么减金额折扣,这都属于什么呢?这应该是属于优惠券的优惠规则了吧,是是这个道理吧,诶,那他可能会有疑问了啊,为什么这个优惠券,他把优惠券的基本信息和优惠规则放在一张表了。而我们前面讲的那个活动,活动跟优惠券其实有点类似,对不对,那活动我们把活动的一些基本信息跟活动的规则是不是分到两张表边去了。对不对啊,你看前面咱们活动是不是分了一个什么activity in for,里边存储了活动的名称,活动类型等基本信息,对吧?然后又有一个单独的表,叫做activity rule去存储啥呀?是不是存储这个活动的规则,你说为什么会有这样的一个区别?这为什么要分开?下边为什么要放一起?那当然这个其实不属于我们数仓开发人员的工作啊,这是实际上属于谁呀,是不是属于我们业务系统数据库啊,这个设计工作者的一个他的一个职责呀,对吧,他的一个职责,那当然在这儿呢,我们也理解也了解一下啊,那你说为什么这会给它分开啊,而下边为什么又放在一起了。
14:08
思考思考。啊,这个呢,其实跟关系建模是有关的啊,关系建模有关,那咱们现在关那个就是业务系统使用数据库,是不是用的都是关系数据库啊,没错吧,关型数据库里边是不是也是一堆的库,一堆的表啊,那我们去建表的时候也要有一个什么样的操作呀,是不是建模的操作呀,对吧?那关型数据库建模一般采用就是关系间玩啊是这样的,关系建模的时候呢,有一个非常重要的一个111个点啊,就什么点呢,叫做范式。啊,范式,这个范式呢,我们后边会讲,所谓范式呢,就是我们在进行关系建模的时候,需要遵循的一套规范啊,一套规范,那这个范式的终极目标是什么呢?就是消除数据的冗余,消除数据的冗余,那什么叫冗余啊?什么叫冗余?对,就是一条相同的信息重复存储了多遍,那是不是就叫冗余?没错吧?那接下来我们就来来分析一下,就是这儿为什么会把活动信息表和活动规则表拆开,而下边的优惠券没有拆开,这个其实就跟范式有关啊,接下来咱们分析啊,假定啊,我现在把活动信息表和活动规则表我给他并到同一张表了。
15:21
啊,假性并到一起,并到一起是不是把它俩字段给它拼一起就可以了,对吧?那这样一来会有什么样的问题出现了,咱们来思考一下,由于一个活动会有多条规则,没错吧?啊,那我并在一起之后,那我的每行数据是不是应该是一个活动的一个规则呀,对不对?那我前面的活动的基本信息就得怎么样。是不是就得重复存储多份啊,没错吧,那这样一来这就出现了什么呀,这是不是就出现了数据的冗余了,对不对,那我把它拆开之后呢?诶,我把活动基本信息放在一张表里,活动规则诶我放在另外的一张表里,那这样一来活动信息我还用重复存储多份了,是不是就不用了,没错吧?哎,那这样一来就能够解决这个数据的冗余啊,是这样的啊,那为什么下边优惠券这个信息表我们没有给它拆开呢?
16:08
因为它没有荣誉,因为你想啊,一个优惠券它能有多个优惠规则吗?一个优惠券不会对吧,一个优惠券它的规则是不是就是唯一的,那所以说一个基本信息对应一个规则,它是不是不会出现冗余,所以它就没有拆开,能理解吧,其际上这么一回事啊,那像刚才我们讲的这个东西呢,其实都是关系建模当中的一些这个知识点啊,主要就是一个范式啊,这个范式呢,在我们后续讲数仓建模的时候呢,我们也会再给大家去详细的讲一下的啊在这儿呢,大家理解一下就可以啊,理解下就行啊,那接来我们继续往下看啊,来下一个,下一个是啥是优惠券优惠范围表,那就是这张表里存的应该就是啥呀。那是不是就是优惠券的优惠范围对不对,也就是哪些商品可以用我这个券,或者哪些品牌可用我这个券,或者是哪些品类可以用我这个券,能理解吧?这个咱们不多说,再来看下一个,下一个是什么?是优惠券领用表,这张表里存的那个是啥?
17:07
对,其实里边存储的就是用用户领取优惠券的记录,对不对,对吧,比如说张三领了一个优惠券,那OK,我就会在这里边是不是来一个记录对不对?李四,诶,我用一个券是不是也会有一个记录啊,对吧?OK,那这就是这张表里存的这个内容,好接来往下走,下一个收收藏表对不对?Favor沃in for,那收藏表里存那个是啥?是不是就是用户对商品的收藏记录对吧?张三收藏了一个商品,那是不是会有一条记录对应啊,对吧?诶这个比较简单,好下一个,下一个呢是订单明细表,叫做older detail啊,那现在呢,我们先不不说它啊,咱们先说谁,我就先说这个。订单表先说order info啊,Order info这张表比较简单,它里边存的就是啥。是不是就是一个订单?这张表里一行数据是不是就是一个订单?没错吧?啊,那OK,那订单明细里到底存的是啥呢?
18:00
你可以看一下啊,看一下它里边的核心字段,首先有一个OID,这个是不是可以关联到我们的订单表,没错吧,那下边还有一个谁SKUID,这是不是商品ID对不对?那你说订单明细表里存那个是啥?对,应该是一个订单当中的一个商品的相关信息。能理解吧,啥意思?就是咱们的一个订单里边是不是可能会包含多件商品,没错吧,咱们下单的时候都都都知道我一个订单里边可能会包含商品A,商品B,商品C,第一个我卖了一件,第二个买两件,第三个呢,买了三件,这是不是一个订单?没错吧?那订单明细表当中存储的就是这些商品的详细信息啊,也就是说,比如说这个订单里边的这个商品我买了几个,你这是不是有一个SK number啊,对吧?啊,那是这样的啊,这这就是订单明细表里它所存储的数据,存储的就是订单里边的商品信息。啊,那在这呢,我们举一个例子啊,假如说啊。
19:01
假如说张三啊,他下了一个订单,这个订单呢里边呢,一共买了三件商品,一共买三件商品啊,那三张分别是商品一啊商品二和商品三,那第一个呢,买了两件啊,第二个呢,买了这个一件,第三个呢,买了比如说四件,OK,那他下完一个这样的订单之后,那你说这两张表的数据会发生什么样的变化?一个订单明细,一个订单表会发生什么样的变化?怎么样变化呀。下一个这样的单之后,首先order ino这张表里是不是会新增一条数据,因为这张表里一条数据是不是就是一个订单,没错吧,诶它会新增一条数据,那这个表呢,他会新增几条数据,新增几条,咱得搞清楚这张表的每行数据是啥对吧?那这张表其实每行数据就是啥呀,是一个订单里边的一个SKU对不对?那也就是说这张表当中会增加三行数据。是这个道理吧啊OK,那大家要知道订单明细里存的到底是什么内容啊,好了,那现在订单明细和订单表我们就都说完了啊,接下来我们继续往下看啊。
20:06
看一下这两张表。这两张表其实也有点儿类似,这两本分别是啥?订单明细活动关联表这个呢。订单明细优惠券,我那表。对不对,也就是他们,呃,分别是不是干什么作用的,是不是将订单明细和优惠券关联起来,将订单明细和活动关联起来,是这个道理吧?啊,那你说这里边存的应该是啥呀。啊,其实很简单,这里边存储的就是哪个订单参与了哪个活动啊,那下面这张表呢,是不是就存储了,呃,哪个订单参与了哪个优使用了哪个优惠券啊,对不对,没错吧,哎,这也其实也就是说白了就是订单参与活动或者是订单订单使用优惠券的记录啊,就在这两这两上面就存着。OK,那为什么这两张表我们叫做订单明细活动关联表和订单明细优惠券关联表呢?
21:02
你说咱们这关联的时候,实际上是用谁关联的,是用具体的订单明细去关联的,对不对?那为什么我们没有用订单去关联?好多干,诶,因为这个大家肯定能想到啊,就是一个订单里边,首先它是有多个订单明细的,对不对啊,但是你想啊,整个订单里边不是说所有的订单明细都一定会去参与某个活动,或者都去使用优惠券,对不对?是这个道理吧,比如说我这儿一共有三个商品,那只有前两个商品符合参与活动的条件,第三个商品是参与不了活动的,没错吧?那这种情况下我们要用order ID,用订单ID去关联活动,是不是就不太准确了呀,对吧?那所以说我们要为了准确的记录这个订单与活动和优惠券的关系,那应该用谁去关联比较好,可能是用单单明细去关联,对吧?那这样一来我们就知道到底是哪个明细,哪个商品参与了哪个活动,或者是使用了哪个优惠券能理解吧,把这个大家搞清楚啊,好接来继续往下走啊,下边就是订单明细优惠券关联表,跟刚才一样,咱们就不再解释了啊,下一个下一个就是ordero订单表,我们刚才已经说过了,对吧?来下一个,下一个是啥?是不是退单表啊,Order refundo refund,是不是就退单的意思,那这张表里存储的肯定是啥。
22:11
是不是就是退单记录对不对,只要用户哎,我发起退单,那这张表里是不是就会新增一条记录,没错吧?啊,接下来继续往下走,下边还有一个,下边这个是啥呀?订单状态流水表叫做order status logg,也就这张表里实际上记录的就是啥?是不是就是订单状态啊,对吧?诶,那订单状态流水表它的意义是什么?它的作用是什么呢?什么叫流水,说什么什么叫流水啊,之前咱们小学的时候写日记应该有一个概念叫流水账对吧?啊,比如早上起来几点睁眼,几点起床,几点几点刷牙,对不对啊,就为了凑字数候那个当时是,那这就是所谓的流水,这流水呢,就会把最详细的信息是不是都记录下来,对不对,那这个订单状态流水记录的就是啥呢?就是所有的订单的所有的状态变化啊,当然具体指的状态变化的什么呀。
23:05
是不是时间呀,对吧?啊,那为什么会存在一个这样的表。我给大家解释一下啊来,我们要想知道这张表的作用,那我们得先去看一下订单表里边的一个字段,这张表里是不是有一个order status字段,刚才我已经给大家说过这个字段了,对吧?啊,叫做订单状态,这个订单状态呢,当然以这张表,呃,从从这张表的角度去考虑啊,那这个order status里边存储的数据应该是什么?应该是啥?是不是应该是每个订单的最新状态?是这个道理吧,大家都知道订单的状态会发生变化,没错吧?那订单状态只要一变,那它是不是就会变为最新状态,原来的状态还有吗?是不是没有了,是不是直接覆盖掉了呀,对吧?啊是这样的啊,但是大家想一想,我们在查看自己这个订单的时候,那是不是会有一个从开始至今的一个呃,一个历史记录啊,对吧?就是说订单什么时候下的,什么时候支付的,诶什么时候这个呃收货的什么时候完成的,是不是会有一个这样的一个历史记录,对不对?那你说我这要把原来的这些状态都覆盖了,那你说我还能找到这些记录吗?
24:10
是不是找不到了,对不对,那我是不是得想办法把这些所有的记录都存储下来,没错,在这是怎么存的呀,是不是就用这个older data log这张表去存啊,对吧啊,那也就是这张表里会存储所有订单的所有状态。是这样的,大家把这个搞清楚啊,那至至于这张表到底怎么存啊,那咱是不是就得看这张表的表结构了呀,对吧?啊,我们得知道它每行数据是什么,它的列有哪些,那这个呢,我们一会儿再看啊,不着急啊,来,往下走,下一个支付表啊,支付表里存的是啥?不用多说,肯定是一条一条的支付记录,没错吧?啊,现在咱们继续往下走,下一个退款表,退款表也不用多说,里边存在个啥,是不是一条一条的退款记录啊啊OK,继续往下走,下边呢,还有一个啊,这张表是什么?是SKU平台属性表。SKU平台属性表,诶,那这个SKU平台属性表又是啥呀?
25:06
也跟平台属性相关,对不对,那我们跟平台属性相关表,刚刚才咱是不是已经讲过两张了,没错吧,一个是啥?一个是平台属性表,一个是平台属性值表,对不对?那这个表里存的是所有的K,这个里边呢,存的是所有的value,没错吧,那咱们下边这张表存的到底又是什么东西呢?什么叫做SKU平台属性表啊?其实很简单,这张表里存储的就是SKU与平台属性之间的关联关系。这句话怎么理解啊,这样怎么理解,大家都知道平台属性是谁的属性,是商品SKU的属性,对不对啊,那虽然我们现在已经有两张表了,一张表里存了所有的K,另外一张表里呢,存了所有的VALUE6,对不对?但是你想一想,这个K和Y6跟我的SKU有关系吗?
26:00
目前如果没有这张表的话,它俩有关系吗?他俩没有关系对吧?我也不知道这个K这个属性是哪个商品的属性,没错吧?啊是是这个道理吧?啊,但是咱们需不需要去保存这个关系呢?那肯定需要啊,你想一想啊,咱们这个平台属性它的意义是什么?是不是就是我可以根据平台属性去定位到我具体的商品对吧?我上面选择具体的属性值之后,下边是不是得能够能够给咱们把具体的SKU展示出来才行,是这个道理吧?那所以说咱是不是必须得有一张表去存储SKU和平台属性之间的关联关系,没错吧,那谁存的这个关系啊,就是这张表。啊,这两表的存储的就是SKU与平台属性之间的关系,来咱们一起看一下啊,这里边最核心的字段其实就是谁啊,SKID,那它是不是可以关联上具体的一个SK,没错吧,那这里边还有谁?是不是还有at Di ID和Y6ID,那他们是不是能够关联到具体的。平台属性的K以及平台属性的V是这个道理吧?啊,那这样一来的话呢,我们就能够把商品和平台属性关联起来了,这个咱们得搞清楚啊好,那接下来我们继续往下进行啊,这个表大家应该知道是干啥的了,对吧?啊,接着往下走啊,下边我们再往下走,下一个是啥呀。
27:14
SKU信息表,这个比较简单吧,这个不用多说了吧,啊存里边存储的就是一个一个的SKU啊SKU的信息再往下走,那再往下呢,这个是什么。呃,我们看一下这三张表啊,看一下这张表,再加上这样的两张表。啊,那这三张表实际上跟我们刚才所讲的与平台属性相关的三张表是什么样的呀?是对应的,诶他们的设计是对称的,是一样的啊来我们看一下,先看下边这个,这个叫做PU销售属性表对不对?PU cor,你说这张表里存的是什么呀?孙队长。是所有的销售属性,也就是什么那个K。也就是所有的销售属性的K,大家还记得销售属性在哪对吧?啊销售属性的K,那这个里边呢。
28:03
显然就是所有的销售属性里边的value对吧,那他俩是不是正好对应我们刚才讲到的平台属性和平台属性值这这样的两张表啊,没错吧,那这这张表存的是啥呢?哎,对,就是存储的SKU与谁的关联关系啊,与销售属性之间的关联关系,没错吧,这两这三张表跟我们刚才讲的与平台属性相关的三张表是对应的啊,那三张表理解了这三张表大家就能理解啊好,那现在我们就继续往下看下面一个表,SPU信息表,那这张表里存的就是啥?是不是显然就是s po的基本信息啊,对吧?这个咱不多说,来继续往下走,那这两张表已经说过了,我们再看这只剩下最后两张表了,大家再坚持一下啊,来我们看一下下边先看下面这个吧,下面这是啥?是不是用户信息表,没错吧,用户信息表里边,嗯,就是一些用户的基本信息,这个不用多说,来我们看上面这个用户地址表,User address。诶,那用户地址表示理论上是不是也属于用户的信息,没错吧,那你说为什么没有把用户的地址也给他存储到用户信息表里边呢?为啥呀?诶是不是还是咱们之前提到的那个关系型数据库,它那个关系建模的范式啊,对吧?跟那个有关对不对?范式是不是得解决数据的冗余,对吧?那咱这儿是不是如果放在一块儿又会出现数据的冗余,为啥?因为一个用户他是不是可能会有多个地址,没错,多个地址我要并在一起,那每行数据一个地址,那前面这些用户的基本信息,咱是不是得重复存储多份啊,对吧?啊,那所以在这儿呢,咱们需要给它拆开啊,单独存储,那这样一来数据的冗余就会消失,OK,那这就是咱们最后的这两张表啊,那也就到目前为止啊,我们这一共是34张表对吧,那每张表里存储的这个大致的内容,我们大家应该有一个宏观的把握了,对吧?OK,我把视频录一下。
我来说两句