马上注册,结交更多数据大咖,获取更多知识干货,轻松玩转大数据
您需要 登录 才可以下载或查看,没有帐号?立即注册
x
一、文章概述 维度表数据仓库中承担着一个非常重大的角色。它们实际上是数据计算的约束条件与报表标签的来源。数据仓库在一些情况下可以说是维度属性的展现。数据仓库的健壮程度直接与维度属性的质量和深度正相关。
下面我们主要讨论多种维度表的设计方案:日期维度、因果维度、退化维度、多值维度与桥连接表、文本注释维度等。
二、维度表设计细节
1、日期维度 日期维度是一种特殊的维度,它几乎出现在所有的维度模型中。与其他维度不同的是,可以其他建立日期维度表。由于一年只有365/366天,因此可以在表中存储30年的数据,无非也就是365*30条。维度表可以包含历史和未来几十年的数据。建议将维度表按照下面的方式设计: 对于报表,需要增加长标识和缩写标识。例如月份有1月、年-月(YYYY-MM);季度(Q1)和2019年-Q1等写法。
需要建立详尽的维度表。不要依赖于SQL语句动态计算周、财务周期、季度、假日、周末等属性。建议将其放在维度表中,通过查询直接获得。 将当天的时间作为维度时,例如10分钟间隔,小时,分钟等。当天的时间最好从日期维度中剥离出来,以避免维度计算的复杂性。 文本属性的标识,与其他标识符类似,日期维度的节假日通常也会有两个可能的值。尽量采用假日或非假日,而不是使用神秘的Y/N。 对应当前和相对日期的属性,大多数的日期维度属性是不应该更新的。然而,某些属性可以增加到基本的日期维度中,这些属性可能会随着时间改变,包括is_current_day、is_current_month、is_prior_60_days等。还有一些之后的属性,例如0表示今天,-1表示昨天,+1表示明天。因此有时候需要每天动态更新这些属性。
2、产品维度
产品维度描述的是数据仓库中每个产品的维度信息。为每种产品定义一系列的描述信息,有助于数据仓库的管理。 具有内嵌含义的属性。在维度表中通常含有自然键操作的维度码值,通常情况下具有内嵌含义。例如身份证号是由地址码+出生日期码+顺序码+校验码组成。前六位表示地区码,因此需要将地区名称属性添加到维度表中。 作为属性或事实的数字值。有时候很难判断某些数字应该放入到维度属性分类,还是归入事实计算。如果数字同时用于计算和过滤/分组,那么应该在事实表和维度表中同时存储。 下钻维度属性。合理的产品维度需要包含几十个属性。每个属性或者作为约束条件或者作为行级标记来源。下钻是根据维度模型中的行头指针属性查询。上卷操作将移除行表头。可以根据属性从多个层次上卷或下钻,其中部分属性不是层次的组成部分。
3、商店维度 商店描述的是每个连锁门店。数据小组必须从数据源中提取信息,以构建商店维度所需的各种元素。
4、促销维度 促销维度主要是包含促销商品的促销条件。促销条件包含临时降价、广告投放、代金券等。促销维度通常被认为是一种因果维度,因为它描述了可能导致产品销售发生改变的因素。 促销产品的销售情况是否在促销期间获得大幅度提升。 促销产品在促销前和促销后的销售量,与促销期间相比是否下降,这种下降是否抵消了促销期间增加的收益。 促销产品在促销期间表现良好,但是其他相关的产品的销售额是否下降?降低了多少? 促销过程中所有的产品(包含非促销产品)的总收益是否有提升。 促销是否有利可图呢?从促销期间的前后几个月做汇总,与历史上同期相比,利润增发有多大? 促销期间是否有用户领了代金券,并未使用。这种获利多少?
各种可能存在的因果条件是高度关联的。临时降价通常与广告或者PUSH相关。纯粹的从逻辑上考虑,通过将4个不同的因果机制(广告、降价、PUSH、代金券)区分开,建立不同的维度而不是将他们合并在一个维度中。
对于不同的业务群体来说,不同的维度更易于理解。 不同的维度管理可能比对合并在一起的维度更容易。
注意:许多销售事务中包括未促销的产品。客户的购物车中可能会包含非促销产品,因此,促销维度中必须包含一行,具有唯一键0或者-1,用来表示不包含促销条件,避免事实表中出行空的促销键。
5、退化维度
退化维度顾名思义就是把部分维度信息退化到事实表中,增加事实表的可读性。把一些微博的状态(原创、转发、删除),发票代码、发票号码或者微博的mid直接放在事实表中,而没有对应的维度表与之关联。这种操作在互联网的hive事实表中非常常见,可以优化查询性能和增加可读性。
作者:清和 来源:大数据漫路求索
|