目录
定义
上回聊到,业务系统的建模目的是为了实现业务功能,数据建模是为了实现统计分析。数据建模常用维度建模作为方法论来实现,那么维度建模有哪些内容?如何实施呢?(方法论的学习是枯燥且乏味的,但是方法论就像一个武林高手的内功,内功修炼好了,招式才可以千变万化,Come on!)
维度建模:按照事实表、维度表来构建数据仓库模型的方法,称之为维度建模。根据维度表和事实表之间的链接方式,分为星型模型和雪花模型。那么事实表、维度表是什么东西?常听到的业务过程、属性、事实、度量、粒度、指标又都是什么东西?名词太多傻傻分不清。我们看下图
大部分的名词从上面的图中都可以反映出来,但是理解起来还是比较抽象。我们尽量用人话来分析一下。
维度:维度是看数据的角度,一般是业务涉及的实体或者属性,比如用户、商家、商品、城市,甚至于一堆属性的集合都能作为一个单独的维度;
属性:用作描述维度的特征。比如用户维度的年龄、性别、身高、是否秃顶等等~
事实:这个是最抽象的,可以理解成一个或者多个业务动作,比如下单、点赞、评论,这些都是事实,同时为了描述事实,会通过比较下单时间、下单状态等等来体现这个事实;
度量:对事实的衡量,比如下单金额、积分等等
指标:看上去和度量很像,但是一般指标都伴随着维度,所以个人理解,还没构建维度建模之前的衡量叫度量,构建维度建模的时候度量变成了指标,同时指标也可以通过多个度量生成;
粒度:粒度说的是事实表的主键,比如交易域中的订单事实表,一般有两个,一个父订单粒度,一个子订单粒度,为什么呢?因为父订单只关心用户这次下单花了多少钱,实付多少钱。但是子订单关心用户这次下单里面的每个商品多少钱,实付多少钱。这两个粒度是同时存在的,那有同学就要问了,很明显子订单粒度比父订单细,那为什么还需要存在父订单粒度呢?这个啊是因为子订单的原价和实付价不能直接上卷出父订单的原价和实付价,这是为什么呢?因为补贴的存在,补贴有商家补贴、平台补贴、商品补贴,如果是零售行业,还存在配送费补贴,那这时候实付部分的分担就是个问题了。举个栗子:
-
-
商品1:原价100,现加价50;
-
商品2:原价100,现价60;
-
配送费20,免了;
-
平台红包5块。
-
对于父订单粒度:原价100+100+20=220;
实付:50+60-5=105。
对于子订单粒度:商品1:原价:100,实付:50;
商品2:原价:100,实付:60。
无法从子订单粒度累加父订单的度量。
那么有同学就要问了,你这不讲道理,你在子订单粒度上没加配送费和平台红包。ok,确实没加,但是怎么加呢?不管怎么加都是一个口径,那这个口径变了呢?如何维护?所以这两个粒度是同时存在的。是不是觉得不够严谨,那么我们加一句话就好了-仅代表个人观点。Perfect~
基本要素
维度表
维度建模中维度占了两个字,这证明维度表在建模中的地位。那么维度表一般有哪几种呢?
常见的维度表
单值维度
顾名思义,就是只通过一个外键关联并且维度属性没有层级关系,那必须举个栗子:用户维度表,通过用户id关联,用户属性没有层级关系,nice;
用户id(主键) |