数据仓库建模篇-维度剑魔

本文详细介绍了维度建模,包括定义、基本要素如维度表和事实表,以及星型和雪花模型。维度是业务实体或属性,如用户、商品;事实表描述业务动作,如下单、支付。通过维度建模,可以更有效地实现统计分析。实施步骤包括数据矩阵、维度、粒度和事实的确定。星型模型简化查询,适合指标分析;雪花模型减少冗余,适合维度分析。
摘要由CSDN通过智能技术生成

目录

定义

基本要素

维度表

常见的维度表

事实表

什么是事实表?

如何构建事实表?

常见事实表类型?

两种模式

星型模型

雪花模型

总结

实施维度建模

数据矩阵

维度

粒度

事实

总结

定义

       上回聊到,业务系统的建模目的是为了实现业务功能,数据建模是为了实现统计分析。数据建模常用维度建模作为方法论来实现,那么维度建模有哪些内容?如何实施呢?(方法论的学习是枯燥且乏味的,但是方法论就像一个武林高手的内功,内功修炼好了,招式才可以千变万化,Come on!

       维度建模:按照事实表维度表来构建数据仓库模型的方法,称之为维度建模。根据维度表和事实表之间的链接方式,分为星型模型和雪花模型。那么事实表、维度表是什么东西?常听到的业务过程、属性、事实、度量、粒度、指标又都是什么东西?名词太多傻傻分不清。我们看下图

      大部分的名词从上面的图中都可以反映出来,但是理解起来还是比较抽象。我们尽量用人话来分析一下。

     维度:维度是看数据的角度,一般是业务涉及的实体或者属性,比如用户、商家、商品、城市,甚至于一堆属性的集合都能作为一个单独的维度;

      属性:用作描述维度的特征。比如用户维度的年龄、性别、身高、是否秃顶等等~

      事实:这个是最抽象的,可以理解成一个或者多个业务动作,比如下单、点赞、评论,这些都是事实,同时为了描述事实,会通过比较下单时间、下单状态等等来体现这个事实;

      度量:对事实的衡量,比如下单金额、积分等等

      指标:看上去和度量很像,但是一般指标都伴随着维度,所以个人理解,还没构建维度建模之前的衡量叫度量,构建维度建模的时候度量变成了指标,同时指标也可以通过多个度量生成

      粒度:粒度说的是事实表的主键,比如交易域中的订单事实表,一般有两个,一个父订单粒度,一个子订单粒度,为什么呢?因为父订单只关心用户这次下单花了多少钱,实付多少钱。但是子订单关心用户这次下单里面的每个商品多少钱,实付多少钱。这两个粒度是同时存在的,那有同学就要问了,很明显子订单粒度比父订单细,那为什么还需要存在父订单粒度呢?这个啊是因为子订单的原价和实付价不能直接上卷出父订单的原价和实付价,这是为什么呢?因为补贴的存在,补贴有商家补贴、平台补贴、商品补贴,如果是零售行业,还存在配送费补贴,那这时候实付部分的分担就是个问题了。举个栗子

    1. 商品1:原价100,现加价50;

    2. 商品2:原价100,现价60;

    3. 配送费20,免了;

    4. 平台红包5块。

对于父订单粒度:原价100+100+20=220;

                           实付:50+60-5=105。

对于子订单粒度:商品1:原价:100,实付:50;

                           商品2:原价:100,实付:60。

无法从子订单粒度累加父订单的度量

       那么有同学就要问了,你这不讲道理,你在子订单粒度上没加配送费和平台红包。ok,确实没加,但是怎么加呢?不管怎么加都是一个口径,那这个口径变了呢?如何维护?所以这两个粒度是同时存在的。是不是觉得不够严谨,那么我们加一句话就好了-仅代表个人观点。Perfect~

基本要素

维度表

      维度建模中维度占了两个字,这证明维度表在建模中的地位。那么维度表一般有哪几种呢?

常见的维度表

单值维度

      顾名思义,就是只通过一个外键关联并且维度属性没有层级关系,那必须举个栗子:用户维度表,通过用户id关联,用户属性没有层级关系,nice;

用户id(主键)

  • 1
    点赞
  • 3
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值