精华内容
下载资源
问答
  • 维度建模理论
    2021-02-22 22:34:17

    维度建模和关系建模

    实体-关系建模是面向应用,遵循第三范式,以消除数据冗余为目标的设计技术。

    维度建模是面向分析,为了提高查询性能可以增加数据冗余,反规范化的设计技术。

    关系模型 - 在关系型数据库使用,适用于OLTP,应用第三范式,减少不于主键直接关联的字段,减少数据冗余。

    维度模型 - 在大数据中使用,适用OLAP,在大规模数据中,跨表分析统计查询过程会造成多表关联,这会大大降低执行效率

     

    维度建模

    按照事实表,维度表来构建数据仓库,数据集市。

    事实表:表中的每行数据代表一个业务事件(如下单、支付、退款、收藏、评价等)

    维度表:一般是对事实的描述信息。每一张维度表对应现实世界中的一个对象或者概念。例如:用户、商品、日期、地区等。

     

     

    星型模型:维度表和事实表直接关联。

    雪花模型:对星型模型的扩展,维表可以有子维表(存在维表不与事实表直接关联)

    理论:https://blog.csdn.net/weixin_30470643/article/details/98408175

     

     

     

     

     

    更多相关内容
  • 维度建模理论与数仓分层思想 维度建模 ODS 层因为保留原始数据, 所以和业务数据库 (关系模型) 一样是关系模型. DWD 层即进行了维度建模, 将下面的模型 ↓ 转化为了下面的维度模型, 即以事实表为中心, 周围有一圈的...

    维度建模理论与数仓分层思想

    维度建模

    ODS 层因为保留原始数据, 所以和业务数据库 (关系模型) 一样是关系模型.

    DWD 层即进行了维度建模, 将下面的模型 ↓

    关系模型

    转化为了下面的维度模型, 即以事实表为中心, 周围有一圈的维度表 ↓

    维度建模示意图

    维度模型中的表数据 (数据特征) 可能有冗余, 但查询时一般只需要进行事实表和维度表进行 join, 不用 join 太多表, 查询性能更好.

    在维度建模的基础上又分为三种模型:星型模型、雪花模型、星座模型。

    星型模型和雪花模型

    但生产中事实表不可能只有一张, 所以多个事实表多个维度表结合形成了星座模型:

    星座模型

    维度模型的好处

    • Understandability: 表结构简单, 分析人员更好理解事实与维度数据的表结构;
    • Performance: 减少 join, 提高查询性能;
    • 方便进行 OLAP 多维分析: 后续数仓中单纯的聚合值意义不大, 一般需要计算某些维度下的聚合值才有意义, 比如 select 维度 agg(事实) from table group by 维度.

    维度模型的扩展

    维度模型对数据关系的变化也具有很高的适应性. 当发生以下变化时, 不需要改变现存的 BI 查询或应用, 就可以方便地适应, 且查询结果不会有任何改变:

    • 新增的事实与存在的事实表粒度一致时, 可以创建新列;
    • 如果新增的维度表与事实表的粒度一致, 可以通过在事实表中建立新的外键列, 可以将新的维度关联到已经存在的事实表上.
    • 如果某维度表新增的维度列, 直接在维度表上建立新列即可;
    • 可以使事实表的粒度更原子化, 方法是在维度表上增加属性, 然后以更细的粒度重置事实表, 小心保存事实表及维度表的别名.

    星型模型与 OLAP

    如果, DW 采用了星型模式建模, 或 OLAP 建模, 都可以说是利用了维度的概念, 他们对维度的认识是一样的, 只是物理实现上不一样. OLAP 一般用于即席查询, 通常会进行与计算, 索引策略和其他的优化方法; 同时有很多比 SQL 更好的分析函数, 使得OLAP的查询和分析性能更好, 不需要提出新的查询.

    但是, 一般在 OLAP 之前, 我们还是会将详细的, 原子的信息加载到星型模型中, 然后由此建立 OLAP 分析模型.

    星型模型主要包含事实表, 以及通过主键/外键关系与之关联的维度表, 联机分析处理 ( OLAP) 多维数据库是实现在多维数据库之上的多维结构, 它与星型模型内容等价, 或者说来源于星型模型.

    OLAP 多维数据库也是包含维度属性和事实表, 但它能够使用比 SQL 语言具有更强的分析能力的语言访问, 比如 XMLA 和 MDX 等.

    OLAP 多维数据库通常是部署 DW/BI 的最后步骤, 或者作为基于多个原子关系型模式的聚集结构.

    事实表

    事实表

    事实表中的每行数据代表一个业务事件或业务度量, 比如下单, 支付, 退款, 评价等.

    事实表一般包含两部分字段:

    • 维度字段. 即与维表相连接的外键, 通常具有两个和两个以上的外键, 外键之间表示维表之间多对多的关系.
    • 度量值. 即具有可加性的数值型的度量值, 像可统计次数, 个数, 金额等. 例如, 订单事件中的下单金额.

    事实表的特征:

    • 非常的大;
    • 内容相对的窄: 列数较少;
    • 经常发生变化, 每天会新增加很多.

    业务过程度量事件转换到事实表中

    事实度量

    最终计算通常在 DW 的上层或 OLAP 多维数据库层.

    可加

    最主要是数值类型和可加类型:

    • 数值类型: 销售额
    • 可加类型: 销售量

    这些都可以按照某些维度, 比如时间维度进行聚合, 这是最关键的.

    半可加

    半可加度量可以对某些维度进行汇总, 但不能对所有维度进行汇总.

    比如, 差额是常见的半可加事实, 除了时间维度外, 他们可以跨所有维度进行加法操作.

    不可加

    比率是最常见的不可加度量.

    一般对于这种, 非可加度量一般拆解为其全完可加分量.

    粒度 - 事实表分类

    事实表中每行数据是一个特定级别的细节数据, 称为粒度. 同一张事实表的粒度相同, 不会出现重复计算度量的问题.

    事务型粒度 (最常见)

    最常见, 最典型的事实表. 它和上面介绍的事实表的基本描述是一样的.

    每个事务或事件为单位,例如一个销售订单记录,一笔支付记录等,作为事实表里的一行数据。一旦事务被提交,事实表数据被插入,数据就不再进行更改,其更新方式为增量更新。

    特点:

    • 数据写入这样的事实表中就不会再进行修改了.
    • 最多.
    • 数据维护: 不变.
    • 采集中的同步策略: 增量 (数据不会变, 每天增量分区表).

    无事实事实表

    有些可能没有可以记录的数字化事实, 比如:

    • 某一天学生参加课程的时间, 包含时间, 学生, 教师, 地点, 课程等维度, 但没有数字度量.
    • 客户交际也是一种事件, 也没有相关的维度.

    比如日志数据, 一般也可以转换成无事实事实表.

    周期型快照粒度

    周期型快照事实表中不会保留所有数据 (这句话是跟事务型事实表进行对比的),只保留固定时间间隔的数据,例如每天或者每月的销售额,或每月的账户余额, 或者加购物车事实表。

    比如加购物车事实表:

    最原子性的事件是加购物车和取消购物车, 但我们并不关注加减的过程或加了几次, 减了几次, 我们关注的是购物车中剩下的商品, 这些商品可能就是用户想买却舍不得买的商品, 这样我们就可以对其进行一个促销, 让大量用户进行购买, 这是我们关注的.

    而购物车中的商品每天都可能会有变化, 所以我们一般周期性地记录购物车中的数据.

    数仓中的具体实践是在 Hive 中建立日期为分区的购物车事实表, 然后 MySql 中的购物车表每天固定时间导入到 Hive 的当天日期分区中, 也就是每天打一个快照.

    特点:

    • 相对较少.
    • 数据维护: 不变.
    • 采集中的同步策略: 全量 (每天全量分区表).

    累积型快照粒度

    累计快照事实表用于跟踪业务事实的变化。例如,数据仓库中可能需要累积或者存储订单从下订单开始,到订单商品被打包、运输、和签收的各个业务阶段的时间点数据, 来跟踪订单生命周期进展情况

    当这个业务过程进行时,事实表的记录也要不断更新。也就是一行数据没办法一次写完, 需要分多个阶段累计写完的, 每个阶段都是一个里程碑.

    订单id用户id下单时间打包时间发货时间签收时间订单金额
    3-83-83-93-10

    特点:

    • 最少.
    • 数据维护: 不像事务型事实表和周期型快照事实表, 累积型快照事实表每行数据是会改变的. 但 Hive 一般不对数据进行修改, 而是采用先 select 查询出来, 查询过程中进行判断, 看需不需要修改数据, 需要改的话进行修改, 修改之后, insert overwrite 回原表.
    • 采集中的同步策略: 新增及变化 (一般按照第一个里程碑时间建立分区表).

    维度表

    维度表: 一般是对事实的描述信息. 每一张维表对应现实世界中的一个对象或者概念. 例如: 用户, 商品, 日期, 地区等.

    数仓的好坏取决于维度的设置, 分析能力取决于维度的质量和深度.

    属性应该包含真实使用的词汇, 而不是令人感到迷惑的缩写, 尽量少使用代码, 而是使用文本.

    操作码

    有的操作码有确定的业务含义, 比如前两位表示业务类别, 3~4位表示区域, 与其用户查询过滤操作码, 不如前期就将操作码差分, 然后以不同维度展现给用户, 这样用户就能方便地展开过滤, 分组和制作报表等工作. 其实就是一个 ETL 的过程.

    在分析操作码时, 如何确定某些元素是维度还是事实?

    • 包含多个值并后续参与计算, 往往是事实属性;
    • 对具体指的描述, 是一个常量, 某一约束和行标识, 往往是维度属性.
    • 连续值是事实, 离散型的不太大的列表一般是维度. 价格由于经常变化, 可以认为是一种事实度量.

    维表的特征

    • 维表的范围很宽 (具有多个属性, 列比较多, 一般都是宽表 50 ~ 100 个), 比如将日期或者商品相关的字段全部放入一个表里;
    • 通常以层次关系表示.
    • 跟事实表相比, 行数相对较小: 通常 < 10万条;
    • 内容相对固定 (跟事实表对比): 像事实表, 比如订单表, 每下单一次就增加一行, 每天增加很多. 但维度表比如商品表, 即每天的商品表, 改变并不大, 因为每天商品基本一样, 不可能说每天上架大量的商品. 还有些编码表, 地区表和时间表等都不会变.
    • 同步策略: 除了某些特殊不变的维度表只在第一次初始化的时候全量同步一次, 其他的维度表一般来说每日全量同步. 注意: 像用户维度表使用的是拉链表, 这个需要注意一下, 还有拉链表是否需要分区等等, 待探讨.

    维度表举例 - 时间维度表

    日期IDday of weekday of year季度节假日
    2020-01-01211元旦
    2020-01-02321
    2020-01-03431
    2020-01-04541
    2020-01-05651

    数据仓库各层建模

    ODS

    • 保持数据原貌不做任何修改,起到备份数据的作用.
    • 数据采用压缩 lzo (数据是 load 来的),减少磁盘存储空间(例如:原始数据100G,可以压缩到10G左右. 如果采用列式存储 (同样类型数据压缩到一起), 压缩效率会更高).
    • 创建分区表,防止后续的全表扫描.

    DWD

    ETL + 维度建模.

    ETL

    日志数据在 DWD 层按照内容解析, 分为 5 类, 解析成 5 张表: 页面, 曝光, 事件操作, 启动, 错误.

    这里用到自定义解析 json 的函数.

    维度建模

    DWD层需构建维度模型,一般采用星型模型,呈现的状态一般为星座模型。

    维度建模一般按照以下四个步骤

    选择业务过程→声明粒度→确认维度→确认事实

    1 选择业务过程

    在业务系统中,挑选我们感兴趣的业务线,比如下单业务,支付业务,退款业务,物流业务,一条业务线对应一张事实表。

    尽可能全地选择业务, 以应对后续业务需求的变更.

    2 声明粒度

    数据粒度指数据仓库的数据表中保存数据的细化程度或综合程度的级别

    一张事实表需要确定一个表的粒度, 即声明粒度意味着精确定义事实表中的一行数据表示什么,应该尽可能选择最细粒度,以此来应各种各样的需求。

    为什么选择最细粒度? 我们从 DWD 层进行聚合时是从最小粒度开始聚合的, 最小粒度可以聚合为更粗的粒度, 但反之只有粗粒度是无法得到细粒度的. 所以有了最小粒度就意味着可以聚合得到各种粒度.

    典型的粒度声明如下:

    • Order Detail 中,每行数据对应一个订单中的一个 sku,Order Info 中,每行数据对应一个订单, 所以订单事实表最细粒度为一个订单中的一个 sku. 但我们实建模过程中并不是完全遵照这样的, 就比如对下单来说应该是按照 Order Detail 中的 sku 来声明最细粒度, 但是对于下单, 我们其实建立了两个事实表, 一个 Order Info 事实表按照一个订单来声明粒度, 一个 Order Detail 事实表按照一个订单中的一个 sku 声明粒度. 这样做的好处? 因为有些需求我们是没必要去最细粒度去查询聚合的, 通过粗粒度事实表反而更容易获取, 比如, 想统计今天订单金额的总和, 按照 Order Detail 粒度就是每个商品价格和数量相乘再相加, 这样 数据量和计算量大, 反而不如在 Order Info 中直接对每一个订单金额求和即可来得方便.
    • 比如支付事实表, 我们只有一张 Payment Info 表, 那么支付事实表的最细粒度就是这张表的每一行数据指代的内容: 一条支付记录.
    • 一般情况下, 如果一个业务事实只有一张表的话, 粒度也就被确认了, 没有其他选择.
    3 确定维度

    维度的主要作用是描述业务事实,主要表示的是 “谁,何处,何时” 等信息。

    实际上就是确定事实表中有哪些外键.

    一般就是先把所有维度列出来, 然后看每个事实表和哪些维度 (group by 的字段) 有关.

    4 确定事实

    此处的 “事实” 一词,指的是业务中的度量值,例如

    订单金额、下单次数, 单价, 折扣, 净支付价格等。

    在 DWD 层,以 业务过程为建模驱动,基于每个具体业务过程的特点,构建最细粒度的明细层事实表。事实表可做适当的宽表化处理。

    粒度时间用户地区商品优惠券活动编码快递商仓库度量值
    订单一条订单件数/金额
    订单详情订单中一件商品件数/金额
    支付一条支付记录金额
    加购物车一个购物车记录件数/金额
    收藏用户一次收藏个数
    评价一次评价个数
    退款一次款款记录件数/金额
    优惠券领用一个用户领一个券的记录个数

    这些关系是比较灵活的, 但前提是能关联上的, 能关联上的尽量关联上.

    什么是能关联上? 一般关系模型的一张事实表中的维度外键是直接关联上的, 但还有一些是可以间接关联上的. 比如支付表和位置, 直接关联不上, 但支付和订单相关, 订单和位置相关, 这样就关联起来了.

    至此,数仓的维度建模已经完毕,DWS、DWT 和 ADS 和维度建模已经没有关系了。

    DWS 和 DWT 都是建宽表,宽表都是按照主题去建。主题相当于观察问题的角度。对应着维度表。

    DWS & DWT

    这两层是款表层.

    DWS

    统计各个主题对象的当天行为,服务于 DWT 层的主题宽表。

    DWS 层宽表

    DWT

    以分析的主题对象为建模驱动,基于上层的应用和产品的指标需求,构建主题对象的全量宽表。

    DWT 层主题宽表

    DWS 和 DWT 的作用

    DWS 和 DWT 都一定程度进行了聚合, 没有 DWS 和 DWT 层可以吗? 可以, 但是:

    • 有些聚合操作是重复的, 需要重复计算;
    • DWD 是明细数据, 都从这一层去查询, 数据量比较大.

    所以 DWS 和 DWT 层存在的意义就是减少数据重复计算, 提高数据的复用性, 优化数仓性能.

    举例, 有以下需求:

    1 统计今天每个省份订单的个数是多少?

    select province, count(*) from orderInfo group by province where dt = 'xxxx-xx-xx'
    

    2 统计今天每个省份下单的总金额是多少?

    select province, sum(amount) from orderInfo group by procince where dt = 'xxxx-xx-xx'
    

    这两个需求其实是类似的, 但如果从 DWD 来查询, 重复计算了两遍, 降低了效率.

    DWS 和 DWT 设计

    从上面来看, 对于相同维度的聚合, 我们可以进行一次计算, 所以, DWS 和 DWT 层宽表应该以:

    • 维度为基准 (宽表有哪些);
    • 所有与此维度相关的事实表中的度量值的聚合值为字段 (宽表有哪些字段).
    • 时间尺度不同:
      • DWS 为每个维度对象的当天的统计值;
      • DWT 为每个维度对象的累积值 (订单金额, 次数等…), 比如最近 7 天, 最近 15 天, 最近一个月, 从开始至今的累积值等.

    DWD 和宽表层的关系

    DWD 层进行了维度建模, 款表层只是我们为了优化数仓建的两层, 和维度建模没有任何的关系.

    DWD 进行维度建模时不是以需求为驱动的, 主要以维度建模思路和步骤驱动的; 款表层是由需求指标为驱动的.

    ADS

    对电商系统各大主题指标分别进行分析。

    对接数据仓库后续的应用, 比如 BI 报表, 用户画像, 机器学习等. 这些应用都需要数仓中的数据, 它们需要什么数据, 我们就在 ADS 层提供对应的数据.

    比如, BI 报表需要展示结果, 比如一个聚合值, 那我们就把这个聚合值放到 ADS 层以供 BI 查询即可, 比如日活, 月活, 留存用户, 新增用户等.

    比如, 机器学习需要大量的样例数据, 也可以放入 ADS 层;

    比用户画像需要用户大量的各种信息, 也可以放在 ADS 层.

    也就是说, 不同的应用, 在 ADS 层准备的数据是不同的.

    维度建模举例

    零售

    选择业务过程

    建模的业务过程是 POS 零售交易, 该数据保证商业用户能够分析被销售的产品, 他们是在哪几天, 在哪个商店, 处于何种促销环境中被销售的.

    声明粒度

    最细粒度是 POS 交易的每个单品, 假设 POS 系统按照一个购物车中某种产品.

    确定维度

    日期, 产品, 门店, 促销, 收银员, 支付方式

    确定事实

    销售数量, 单价, 折扣, 净支付价格;

    扩展折扣额;

    扩展销售额 = 销量 ✖️ 单价;

    扩展成本;

    扩展毛利润;

    零售模式中的可度量事实

    维度表

    日期维度表

    日期维度表

    样例报表

    产品维度

    产品维度示例行

    产品维度表

    按照维度属性下钻

    引用

    确定事实

    销售数量, 单价, 折扣, 净支付价格;

    扩展折扣额;

    扩展销售额 = 销量 ✖️ 单价;

    扩展成本;

    扩展毛利润;

    [外链图片转存中…(img-PXM3uxaq-1606195310738)]

    维度表

    日期维度表

    [外链图片转存中…(img-199gR92j-1606195310738)]

    [外链图片转存中…(img-p8VNuXAQ-1606195310739)]

    产品维度

    [外链图片转存中…(img-fF1sRQXp-1606195310740)]

    [外链图片转存中…(img-HZIF5K6e-1606195310740)]

    [外链图片转存中…(img-wekvGH3U-1606195310741)]

    引用

    Kimball - 数据仓库工具箱

    展开全文
  • 维度建模的基本理论

    2021-10-26 14:27:44
    维度建模 围绕三个问题来展开 1、怎么组织数据仓库中的数据? 2、怎么组织才能使得数据的使用最为方便和便捷? 3、怎么组织才能使得数据仓库具有良好的可扩展性和可维护性? 维度建模两大派系 Bill Inmon(数据...

    维度建模


        围绕三个问题来展开
        1、怎么组织数据仓库中的数据?
        2、怎么组织才能使得数据的使用最为方便和便捷?
        3、怎么组织才能使得数据仓库具有良好的可扩展性和可维护性?
        
    维度建模两大派系 Bill Inmon(数据仓库之父) 的企业信息化工厂模式和 Ralph Kimball (商业智能之父)的维度建模模式

    Ralph kimball维度建模


        基本理论
        一般过程
        维度表审计
        事实表设计

    维度建模关键概念


        1、度量和环境(产品和数据分析师提出的)


            维度建模支持对业务过程的分析,这是通过对业务过程度量进行建模来实现。
            什么是度量?实际上通过业务方、需求方交谈,或者阅读报表、图表等,可以很容易地识别度量。
            考虑如下业务需求:
                店铺上个月的销售额如何?
                店铺库存趋势如何?
                店铺的访问情况如何(pv,uv)?
                店铺访问的熟客占比多少?
                这里的销售额、库存、访问量、熟客量就是度量
            缺乏上下文和环境来谈论度量,是没有意义的。比如销售额是3000元,并不知道一天还是多天,一件商品还是整个店铺,一个用户单个订单还是多个用户的订单合计?没有上下文和环境,度量没有意义。

            所有的维度建模也正是通过对度量和及其上下文和环境的详细设计来实现的。
            


        2、事实和维度


            在Kimball的维度建模理论中,度量称为事实,上下文和环境则称为维度。
            通常来说,事实表以数值形式出现,而且一般都被大量文本形式的上下文包围着。
            这些文本形式的上下文描述了事实的 " 5个W " (When 、where、What、Who、Why)信息,通常可被直观地分割为独立的逻辑块,每一个独立的逻辑块即为一个维度,
            比如一个订单可以非常直观地分为商品、卖家、买家等多个维度。
            
            在维度建模和设计过程中,可以根据需求描述或者基于现有报表,很容易地将信息和分析需求分类到事实和度量中。
            比如业务人员需求为"按照一级类目,统计本店铺上月的销售额情况","按照一级类目"这个描述,很清楚地说明需求方希望对一级类目的销售额进行统计分析,这里的一级类目即为一个维度。类似的是,"上月"为另一个维度,而销售额明显是事实。
            


        3、事实表


            事实表是维度模型中的基本表,或者说核心表。事实上,业务过程的所有度量在维度建模中都是存储在事实表的,除此之外,事实表还存储了引用的维度。
            
            事实表通常和一个企业的业务过程紧密相关,由于一个业务的业务过程数据构成了其所有数据的绝大部分,因此事实表也通常占用了数据仓库存储的绝大部分。比如对于某个超市来书,其销的明细数据通常占其拥有数据的绝大部分且每天还在不断地累计和增长,而商店、门店、员工、设备等其他数据相对来说股东且变化不大。
            
            
            事实表的一行对应一个度量事件。事实上,每行对应的度量事件可粗可细,比如对某个超市来说,在设计其维度模型时,表示顾客购买事件的事实表的一行即可以记录一张顾客的小票,也可以记录顾客小票的一个子项,那么应该到哪种级别?维度建模认为事实表应该包含最底层、最原子的细节,这样会带来最大的灵活性。维度建模中,细节的级别称为事实表的粒度,比如上文顾客购买行为实施表的粒度应该是小票子项,而非小票。
            
            
            事实表中最常用的度量一般是数值型和可加类型的,比如小票子项的销售数量、销售金额等。可加性对于数据分析来说至关重要,因为数据应用一般不仅检索事实表的单行数据,而往往一次性检索数百、数千乃至数百万行的事实,并且处理这么多行的最有用的和常见的事会是将它们加起来,而且是从各个角度和维度加起来。
            
            但事实表中的度量并不都是可加的,有些是半可加性质的,另一些则是非可加性质的。半加性事实是指仅仅某些维度可加,例如库存,可以把各个地方仓库的库存加起来,或者把一个仓库不同的商品加起来,但是很明显不能把一个仓库同一商品在不同时期的库存加起来。银行的账户余额,但是不能把不同月份的账户余额加起来,非可加性事实则指根本就不能相加的事实,比如商品的价格以及订单的状态等。
            
            除了存储的事实外,事实表都会包含多个相关的外键,用于关联和连接相应的维度表。例如,订单事实表会包含连接到商品表的商品外键、连接到会员表的买家外键、或者连接到门店表的门店外键等。正是通过这些外键,才能进行各个角度、各个维度的分析。
                                                                                                     


            事实表根据粒度的角度划分不同,可分为事务事实表、周期快照事实表和累计快照事实表。
                    
                事务事实表用于承载事务数据,通常粒度比较低,例如产品交易事务事实、ATM交易事务事实。
                周期快照事实表用于记录有规律的、固定时间间隔的业务累计数据,通常粒度比较大,例如账户月平均余额事实表。
                累计快照事实表用于记录具有时间跨度的业务处理过程的整个信息,通常这类事实表比较少见。
                这里需要注意的是,在进行事实表的设计时,一定要注意一个事实表只能有一个粒度,不能将不用粒度的事实建立在同一张事实表中。


        4、维度表


            维度表是维度建模的灵魂,通常来说,维度表设计得好坏直接决定了而维度建模的好坏。
            维度表包含了事实表所记录的业务过程度量的上下文和环境,它们除了记录 "5个W" 等信息外,通常还包含了很多的描述字段和标签字段等。
            
            维度表通常有多列或者多个属性。实际应用中,包含几十甚至上百属性的维度表并不少见。维度表应该尽可能多地包括一些有意义的文字性描述,以方便下游用户使用。
            


            维度属性是查询约束条件(SQL where 条件)、分组(SQL group 语句)与报表标签生成的基本来源。在查询与报表需求中,属性用by 这个单词进行标识。
            例如:一个用户表示要按"产品合约编号"与"机构编号"来查看账户余额,那么"产品合约编号"与"机构编号"就必须是可用的维度属性。
            维度属性在数仓中承担着一个重要的角色,由于它们实际上是所有令人感兴趣的约束条件与报表标签的来源,是数仓易学易用的关键。在许多方面,数仓不过是纬度属性的体验而已。数仓的能力直接与维度属性的质量和深度成正比。在提供详细的业务用于属性方面所花的时间越多,数据仓库就越好;在保证属性列值的质量方面所花的时间越多,数据仓库就越好。
            维度表是进入事实表的入口。丰富的维度属性给出了丰富的分析切割能力。维度给用户提供了共用数仓的接口。最好的属性是文本和离散的,属性应该是真正的文字而不应是一些编码简写符号。应该通过用更为详细的文本属性取代编码,力求最大限度地减少编码在维度表中的使用。有时候在设计数据库时,并不能很确定从数据源析取出的一个数字型数据字段到底应该作为事实还是维度属性看待。通常可以这样来做出决定,即看字段是一个含有许多取值并参与运算的度量值(当事实看待),还是一个变化不多并作为约束条件的离散取值的描述(当维度属性看待)。
            

        5、星形架构和雪花架构


            在理解了事实表和维度表之后,接下来的问题就是如何组合它们。在维度建模中,存在两种组合维度表和事实表的基本架构:星形架构和雪花架构。
            当所有维度表直接连接到事实表时,整个组合的形状类似于星星,所以被称为星形架构。星形架构是一种非规范化的结构,其数据存储存在冗余,比如考虑商品的维度表,其品牌信息在商品的每一行中都存在,包括其品牌ID、名称、品牌拥有者等。
            
            通常很多商品的品牌都是一样的,所以在商品维度表中品牌的信息被重复存储了很多次,也就是存在冗余。
            
            当有一个或者多个维度表没有直接连接到事实表,而是通过其他维度表连接到事实表上时,整个组合的形状就像雪花一样,这种架构被称为雪花架构。
            
            雪花架构是对星形架构维度表的规范化,比如上述的商品表例子,在雪花架构中,其每一行仅存储品牌ID,而品牌的所有其他信息(包括品牌名称、拥有者、注册地等所有描述信息)都存储在单独的品牌维度表内。通过品牌ID 这个外键,商品表可以间接获取到所有品牌描述信息。
            
            雪花架构去除了数据冗余,节省了部分存储,但是也给下游用户的使用带来了不便,如下游用户需要分析品牌的销售额,必须自己先用订单表关联商品表,然后用商品表再关联品牌表。正是由于这一点,在维度建模的实际中,雪花架构很少得到使用。
            
            有时候简单的方案是最美的、最有力的,也是最有效的。基于星形架构的维度建模就是这种情况。星形架构牺牲了部分存储的冗余,但是带来了使用上的极度便捷,也使下游用户的使用和学习成本变得非常低。即使是没有任何技术背景或者维度建模背景知识的业务人员,也很容易理解,更何况目前的存储成本极低,多出的这份存储开销相比后续每次的关联计算、用户使用和学习成本来说,是非常划算的。

            星形架构中,每个维度都是均等的,所有维度表都是进入事实表的对等入口,用户可以从任一维度、任一维度属性或者任意多个维度组合、任意多个维度属性组合,方便地对数据进行过滤和聚合(汇总、均值、最大、最小等)操作,而且非常符合业务分析直觉。业务是多变的,模型的设计必须能够经受住业务多变的需求。在实际中,可以通过添加新维度或者向维度表中加入维度属性来满足业务新视角的分析需求。
              
                 大多数情况下,数据仓库模型设计中都会采用星形架构,但是在某些特殊情况下,比如必须使用桥接表的情况下等,必须使用雪花架构。
     

       6.1.2 维度建模一般过程

                                                                                             
                维度建模一般采用具有顺序的4个步骤来进行设计,即选择业务过程、定义粒度、确定维度和确定事实。维度建模的这4个步骤贯穿了维度建模的整个过程和环节,下面逐一介绍。
                1、选取业务过程
                    业务过程即企业和组织的业务活动,他们一般都有相应的源头业务系统支持。对于一个超市来说,其最基本的业务活动就是用户收银台付款;对于一个保险公司来说,最基本的业务活动是理赔和保单等。当然在实际操作中,业务活动有可能并不是那么简单直接,此时听取用户的意见通常是这一环节最为高效的方式。
                    
                    但需要注意的是,这里谈到的业务过程并不是指业务部门或者只能。模型设计中,应将注意力几种放在业务过程而不是业务部门。如果建立的维度模型是同部门捆绑在一起的,就无法避免出现数据不一致的情况(如业务编码、含义等)。因此,确保数据一致性的最佳办法是从企业和公司全局与整体角度,对于某一个业务过程建立单一的、一致的维度模型。
                    
                2、定义粒度
                        定义粒度意味着对事实表行实际代表的内容和含义给出明确的说明。粒度传递了事实表度量值相联系的细节所达到的程度信息。其实质就是如何描述事实表的单个行。
                        典型的粒度定义包括:
                            超市顾客小票的每一个子项;
                            医院收费单的明细子项;
                            个人银行账户的每一次存款或者取款行为;
                            个人银行账户每个月的余额快照。
                        对于维度设计来说,在事实表粒度上达成一致非常重要,如果没有明确的粒度定义,则不能进入后面的环节。如果在后面的环节环节中发现粒度的定义不够或者是错误的,那么也必须返回这一环节重新定义粒度。
                        在定义粒度过程中,应该最大限度地选择业务过程中最为原子性的粒度,这样可以带来后续的最大灵活度,也可以满足业务用户的任何粒度的分析需求。
                
                3、确定维度
                    定义了粒度之后,相关业务过程的细节也就确定了,对应的维度也很容易确定。正如前文所述,维度是对度量的上下文和环境的描述。通过维度、业务过程度量与事实就会变得丰富和丰满起来。对于订单来说,常见的维度会包含商品、日期、卖家、卖家门店等。而每个维度还可以包含大量的描述信息,比如商品维度表会包含商品名称、标签价、商品品牌、商品类目、商品上线时间等。
                    
                4、确定事实
                        确定事实通过业务过程分析可能要分析什么来确定。定义粒度之后,事实和度量一般也很容易确定,比如超市的订单活动,相关的度量显然是销售数量和销售金额。
                        在实际维度事实设计中,可能还会碰到度量拆分的问题,比如超市开展单个小票满100减10元的活动,如果小票金额超过10元,这10元的优惠如何分配到每一个小票子项?实际设计中,可以和业务方具体讨论并制定具体的拆分分配算法。

    6.2 维度表设计


                    维度表是维度建模的灵魂,在维度设计中碰到的问题(如维度变化、维度层次、维度一致性、维度整合和拆分等)直接关系到维度建模的好坏,因此本节将深入介绍维度表设计,并详细解释相关概念和技术。
            


    6.2.1 维度变化

           维度表的数据通常来自于前台业务系统,比如商品维度表可能来自于EPR或者超市POS系统的商品表,但商品是会发生变化的,比如商品所属的类目,商品标签价格、商品描述等。这些变化有可能是之前有错误需要订正所致的,或者是实际的业务情况变化。不管哪种情况,维度设计过程中,确定源头数据变化在维度表中如何表示非常重要。在维度建模中,这一现象称为缓慢变化的维度,简称缓慢变化维。
           根据变化内容的不同,下游的分析可能要求用不同的办法来处理。比如对于商品的描述信息,也许业务人员对此并不敏感,或者认为无关紧要,此种情况可以直接覆盖。但是对于商品所属的类目发生变化,则需要认真考虑,因为这涉及归类这个商品的销售活动到哪个类目---是全部归到新类目,还是全部归到旧类目?变化前归到旧类目,还是变化后归到新类目?这实际上也涉及了缓慢变化维的几种处理办法。


           1、重写维度值


            当一个维度值属性发生变化时,重写维度值方法直接用新值覆盖旧值。该技术适用于维度建模中不需要保留此维度属性历史变化的情况,常用于错误订正或者维度属性改变无关紧要的场景,比如用户的生日之前发声输入错误,不需要保留之前的生日历史数据。 
             采用重写维度值的方法,将改变此维度属性的所有历史度量。比如,分析师希望分析星座和销售的关系,之前用户的生日属于白羊座。因此维度设计人员只在必要情况下使用此方法。同时需要告知下游分析用户。
             采用重写维度值方法的维度表和事实表变化如图6-4示。
     

    2、插入新的维度行


           相比重写维度值方法不维护维度属性变化的特点,插入新的维度行方法则通过在维度表中插入新的行来保存和记录变化的情况。属性改变前的事实表行和旧的维度值关联,而新的事实表行和新的维度值关联。
           图6-5 展示了采用这种技术方法处理缓慢变化维的示例。
           仔细观察变化后的维度表可以发现,新复制了一行该用户的信息,唯一不同在于 state 的不同(之前是AZ,之后是CA)。同时,仔细观察订单事实表也会发现,过去的订单是和旧的维度行关联,而新的订单和新的维度行关联。
           通过新增维度行,我们保存了维度的变化,并实现了维度值变化前的事实和变化后的事实分别与各自的新旧维度值关联。但是这也给维度表用户带来了困惑,为什么查询一个会员会在维度表中发现多行记录?尽管可以向用户解释,但是用户的使用和学习成本无疑增加了,而且数据开发人员对于维度变化的处理逻辑无疑更复杂了。
                            

    3、插入新的维度列


                 在某些情况下,可能用户会希望既能用变化前的属性值,又能用变化后的属性值来分析变化前后的所有事实,此时可以采用插入新的维度列这种方法。
                 不同于前一种方法的添加一行,这种方法通过新增一列,比如用 region_previous 列表示之前的所属大区,同时新增 region_current 来表示变化后的所属大区。这种方法的技术细节如6-6所示。
                 上述示例只能捕获了一次属性值的变化,如果有多次变化呢?此时就需要有多个列来存储。如果不希望新增列,那么将只保存最近的两次变化。
                 实际上,这三种方法都能从不同角度解决维度变化的问题,还有通过组合这三种方法形成的其他各种技术可用于处理维度变化,在此不一一阐述。
                 不管哪种技术,在大数据时代都不是完美的,而且有一定的处理复杂度和学习使用成本。如何以一种最简单、直接的办法来解决维度变化呢?后续章节介绍快照技术,以解决大数据时代的维度变化问题。

    6.2.2 维度层次

            维度层次指的是某个维度表中属性之间存在的从属关系问题。比如商品的类目可能是有层次的(一级类目、二级类目、三级类目等,尤其对于宝洁、联合利华等大的快消企业集团),同时类目、品牌和产品实际上也是有层次的,比如宝洁的化妆品会分为男士、女士和儿童等,而男士化妆品下面又有不同的子品牌,每个子品牌下面又有不同的产品。那么维度建模如何处理这些层次结构呢?
              实际上有两种处理办法: 第一种是将所有维度层次结构全部扁平化、冗余存储到一个维度表中,比如商品的一至三级类目分别用三个字段来存储,品牌等的处理也是类似的。第二种是新建类目维度表,并在维度表中维护父子关系。第一种就是前文所说的星型架构,而第二种就是前文所说的雪花架构。在维度建模中,我们采用第一种来处理维度的层级问题,这样反规范化的处理牺牲了部分存储,但是给用户使用带来了便捷,也降低了学习使用成本。

               维度层次结构通常和钻取联系在一起,所谓钻取即使对信息的持续深入挖掘。钻取分为向上钻取和向下钻取。比如对于某零售商的年度销售报表,其年度销售总额显示增长20%,那么从时间上分析师哪个季度的增长量比较高呢?此时可以向下分析各个季度的增长率,同样可以继续向下分析到月增值率乃至天增长率,同样的分析也可以应用到类目、品牌等,来分析到底是哪个类目的增长或者哪个品牌的增长导致了年度总销售额的增长 20%。
              上述的钻取一般被称为向下钻取,与之相对的是向上钻取。钻取的实质是增加或者减少维度,增加维度(向下钻取)从汇总数据深入到细节数据,而减少维度(向上钻取)则从细节数据概括到汇总数据。通过钻取,用户对数据能更深入地了解数据,更容易发现问题,从而做出正确的决策。
     

    6.2.3    维度一致性       


            在 Kimball 的维度设计理论中,并没有物理上的数据仓库。数据仓库是在对多个主题、多个业务过程的多次迭代过程中逐步建立的,这些多个主题、多个业务过程的多次迭代过程被从逻辑上划分为数据集市。所谓数据集市一般由一张和多张紧密关联的事实表以及多个维度表组成,一般是部门级的或者面向某个特定的主题。数据仓库则是企业级的、面向主题的、集成的数据集合。
           物理上的数据集市组合成逻辑上的数据仓库,但数据集市的建立是逐步完成的,如果分布建立数据集市的过程中维度表不一致,那么数据集市就会变成孤立的集市,不能从逻辑上组成一个集成的数据仓库,而维度一致性的正是为了解决这个问题。
           维度一致性的意思是指,两个维度如果有关系,要么就是完全一样的,要门就是一个维度在数学意义上是另一个维度的子集。不一致既包含维度表内容的不一致,也包含维度属性上的不一致,比如对于一个电子商务公司,如果其浏览等相关主题域的商品维度表包含了该企业的所有商品的访问信息,但是由于某种原因其交易域的商品缺失了部分商品(有可能是成交在其他平台完成),那么对这些缺失商品的交易分析就无法完成。同样如果两者的商品属性不同,比如日期格式、类目划分(有可能浏览分为前天类目,成交是后台类目)等不一致,那么夸浏览域和交易域的对类目和日期的交叉分析就无法进行,因为其类目划分就不一致。
            比如希望分析某类目的用户浏览-成交转化率(计算公式为成交订单数/用户浏览数),但是该类目仅在浏览域存在,在交易域不存在,那么显然缺失了分子,此类目的转化率就无法计算。
            上述的跨主题交叉分析,在维度建模中称为横向钻取(相对于向下和向上的纵向钻取)。                    维度一致性对于数据集市集成为数据仓库起着关键作用,实际数据集市设计和开发过程中,必须保证维度一致性,具体可以采用共享同一个维度表或者让其中一个维度表是另外一个维度表的子集等方式来保证一致性,从而避免孤立数据集市的出现。

    6.2.4 维度整合和拆分


              实际维度表设计中,有时候会出现同一个维度表来自多个前台业务系统的问题,此时就会带来维度整合和拆分问题。
              前台的业务系统通常是比较复杂的,比如移动端交易系统和PC端交易系统的系统架构和底层数据库、表结构等完全不一致,而且即使PC端相同,也可能由于历史原因或者业务整合、拆分等原因存在多条业务系统,此时就存在维度的整合问题。
            在实际整合中,同一个维度的整合需要考虑如下问题。
            命名规范:要确保一致和统一。
            字段类型:统一整合为一个字段类型。
            字段编码和含义:编码及含义要整合为一致,比如前台A 系统可以用 Y/N 标识商品在线状态,而B系统用 0/1 表示,此时需要为一致的。实际中还可能碰到商品状态A系统有三个,而B系统有四个的情况,此时需要和业务人员或者需求方共同讨论确定整合逻辑。
            与整合相对的是拆分。对于大的集团公司来说,以中石化为例,其主业为成品油销售,
            但是同时其还有中石化加油站的快捷零售店(在此仅做说明问题使用),它们的商品表字段和属性由于业务的不同而存在很大的差异(石油商品和零售店销售的食品、饮料等),此时需要用一个统一整合的商品表么(从直觉来说是不需要的,因为业务差异巨大)?
             在维度建模理论中,对于上述情况通常有两种处理办法。
                    1) 建一个基础的维度表,此基础维度表包含这些不同业务的共有属性,同时建立各自业务的单独维度表以包含其特殊的业务属性。比如,上述例子就可以建立一个共有的商品维度表记录商品价格、商品描述等共有属性字段,同时建立成品油销售的商品维度表记录油标号(92、95、97等)等成品油独特的商品属性,另外建立一个零售商品维度表记录便利店的各种商品属性(实际操作中通常先建立两个单独的维度表,然后基于单独维度表生成共有的商品维度表或者视图)。
                            
                    2) 拆分,即不合并,即各个业务差异独特性的业务各自建立完全独立的两个维度表,各自管理各自维度表和属性。
                            
                      实际操作中,对于业务差异大的业务,偶合在一起并不能带来很大的便利和好处,因此通常倾向于拆分(既不合并),各自管理各自的维度表。对于业务相似度比较大的业务,则可以采用上述的第一种方法。

    6.2.5     维度其他


                       1、退化维度


                            所谓退化维度,是指在事实表中那些看起来像是事实表的一个维度关键字,但实际上并没有对应的维度表的字段。退化维度一般都是事务的编号,如购物小票编号、发票编号等。退化维度在分析中通常用来对事实表进行分组,比如通常购物小票编号可以把顾客某次的购买行为全部关联起来,同时分析人员也可以统计用户的购买频次等。
                            
                        2、行为维度


                            行为问题是基于过去维度成员的行为进行分组或者过滤事实的办法。行为维度即将事实转化为维度,以确保获得更多的分析能力。
                            对于某零售公司来说,考虑这样一个问题,年购买频次超过30次或者年购买额达到10万的顾客,和年购买频次1次或者购买额在1000元一下的顾客,他们得到的折扣是相同的吗?营销活动中对于他们的处理应该一致的吗?实际商业实践中,常基于顾客过去的购买行为进行评级(普卡、银卡、金卡、白金卡等),并基于其评级用户给予不同的权益(如商品折扣、免排队等),行为维度通常会缓慢变化,因此需要采用缓慢变化维进行处理。
                            
                        3、角度维度
                            角色维度指的是一个事实表中多个外键指向同一个维度表。
                            考虑银行的房屋抵押贷款业务,通常顾客的一次抵押贷款至少会涉及两个银行角色:
                            首先是客户经理,其负责收集客户资料并和客户沟通等;其次是审批人,其负责审核客户递交的各种资料并决定是否审批通过。这样在抵押贷款事实表中将存在客户经理和审批人两个外键,同时指向员工维度表,即一个维度扮演了两种角色。
                            当事实表和维度表存在上述多对一关系时,没必要为维度表建立多个副本,只需基于维度表建立多个视图即可。
                            
                        4、杂项维度
                            杂项维度一般由前台业务系统中的指示符或者标志字段组合而成。
                            在对业务活动建模过程中,经常会发现在定义好各种维度后,还剩下一些在小范围内取离散值的指示符或者标志字段。例如支付类型字段包括现金和信用卡两种类型(在源系统中他们可能是维护在类型表中,也可能直接保存在交易表中),一张事实表中可能会存在好几个类似的字段。如果作为事实存放在事实表中,会导致事实表占用空间过大;如果单独建立维度表,外键关联到事实表,会出现维度过多的情况。如果将这些字段删除,则更不可行。
                            
                            这时,通常的解决方案就是建立杂项维度,将这些字段建立到一个维度表中,在事实表中只需保存一个外键。几个字段的不同取值组成一条记录,生成代理健,存入维度表,并将该代理健保存至相应的事实表字段。建议不要直接使用所有组合生成完整的杂项维度表,在抽取时遇到新的组合时生成相应记录即可。杂项维度的ETL过程比的维度略微复杂。
                            
                            
                        5、微型维度


                            微型维度的提出主要是为了解决快变超大维度问题。
                            以客户维度为例,如果维度表中有数百万、千万甚至以亿计的记录,而且这些记录的字段又经常变化,则将这样的维度表一般称为快变超大维度。对于快变超大维度,设计人员一般不会使用插入新的维度行的缓慢变化维处理方法,因为本来超大的维度表中添加更多频繁变化的行即不划算也不合适。
                            
                            解决的方法是,将分析频率比较高或者变化率比较大的字段提取出来,建立一个单独的维度表。这个单独维度表就是微型维度表。
                            
                            微型维度表有自己的主键关键字,这个关键字和原客户维度表的关键字一起接入事实表。有时为了分析的方便,可以把微型维度的关键字的最新值作为关键字接入客户维度表。
                            
                        6、多值维度和属性


                            当事实表的一行涉及维度表的多行时,会产生多值维度。同样,当维度表的一行需要获取单一属性的多个值时,也会产生多值维度。
                            
                            考虑银行账户交易明细事实表,通常一个银行账户的拥有人只有一个,但是银行实际上也支持联名账户,如果是联名账户,那么在账户交易明细事实表中账户的维度应该存那个账户人呢?这就是多值维度需要解决的问题。
                            
                            通常有两种办法可以解决多值维度或者多值属性。
                            
                            1) 扁平化多值维度: 在事实表中引入多列,比如联名账户最多三人拥有,那么就在账户交易事实表中引入三个账户拥有人列(比如第一账户拥有人、第二账户拥有人和第三账户拥有人)。此外考虑到业务的可变性,可同时添加预留字段(比如第四、第五账户拥有人)。
                            2) 桥接表: Kimball 的维度建模理论也提出了采用桥接表方式来解决此问题。所谓桥接表、是指在事实表和多值维度表之间新增一个表,这个表起到桥接的作用,所以叫桥接表。比如上述多账户的例子,可在事实表和账户人维度表之间添加一个桥接表,这个桥接表将账户人分组,并用分组主键和事实表关联,用分组中的账户人和实际的账户维度表关联。如图 6-7所示。
                            但是在实际项目操作中,很少使用桥接表的方式来解决多值问题,因为桥接表是一把双刃剑。桥接表无疑提供了强大的能力和灵活性,但是在这后面是引入的复杂性和巨大的使用风险,客户使用成本很高,而且极易用错产生多重计算,因此很多实际项目中都不推荐使用桥接表。
                             
                            此外,用于多值属性来说,除了上述两种解决办法,还可以将多值的属性存储到一个大字段内,并用指定的分隔符方便下游提取和使用。    
                                
                            

    6.3 深入事实表


                事实表是维度建模的核心表和基本表。事实表存储了业务过程中的各种度量和事实。而这些度量和事实正是下游数据使用人员索要关心和分析的对象。
                
                本节将重点探讨事实表,包括事实表的三种主要类型: 事务事实表、快照事实表和累计快照事实表。除此之外本书还介绍了一种特殊的事实表----无事实的事实表,最后还将讨论事实表的聚集和汇总。


     6.3.1 事务事实表


                事务事实表是维度建模事实表中最为常见、使用最广泛地事实表。
                事务事实表通常用于记录业务过程的事件,而且是原子粒度的事件。事务事实表中的数据在事务事件发生后产生,数据的粒度通常是每个事务一条记录。一旦事务被提交,事实表数据被插入,数据就不再进行更改。通过事务事实表存储单次业务事件/行为的细节,以及存储与事件的维度细节,用户即可单独或者聚合分析业务事件和行为。
                
                事务事实表的粒度确定是事务事实表设计过程中的关键步骤,一般都会包含可加的度量和事实。
                
                理解概念的最佳途径无疑是实际的例子,因此下面将结合超市零售业务以及维度建模的四个环节来说明事务事实表。
                
                
                (1) 选择业务过程
                在超市的零售示例中,业务用户要做的事情是更好地理解POS 系统记录的顾客购买情况,那么很容易确定业务过程就是POS系统,即在什么时候,什么商品、哪个收银台、销售了哪些产品等。
                
                (2)定义粒度
                顾客单词购买行为的体现是一张购物小票,但正如上述所言,事务事实表应该选择最原子粒度的事件,所言小票的子项(在业务上的动作即为收银员每次扫描的商品条码)应是超时零售事务表的粒度。
                
                (3) 确定维度
                小票子项的粒度确定后,销售日期、销售商品、销售收银台、收银员、销售门店等维度很容易被确定了。另一个不太容易考虑到的维度是促销行为,但是通过和业务人员交流或者查看报表表头等也能够发现此维度。
                
                (4) 确定事实
                维度设计的最后一步,是确定哪些事实和度量应该在事实表中出现。对于本例,商品销售数量、销售价格和销售金额很容易确定下来。但是实际上,商品的成本价是确定的,因此可以很容易地确定商品的销售毛利:(商品实际销售价格-商品成本价)x 销售数量,基于下游使用便利这一因素,也应该将此放入事务事实表中。
                
                基于毛利润也可以计算出毛利率,那么毛利率这种比例应该放入事务事实表吗?在事实表的设计中,一个常见的原则是指存放比例的分子和分母,因为比例的计算是和业务强相关的,业务逻辑可能比较复杂而且比例是非可加的,所以一般不将比例的计算放入事实表中。
                
                至此,已经完成了超市零售事务维度表和事实表的设计,超市零售事务事实表以及相关的维度如图所示。(只展现了日期、门店、商品和促销维度)。

    6.3.2 快照事实表


                在实际的业务活动中,除了关心单次的业务事件和行为外,很多时候还关心业务的状态(当前状态、历史状态)。以超市零售业务为例,管理人员和分析人员除了关心销售情况,还会关心商品的库存股情况,例如哪些商品库存告罄需要补货、哪些积压需要促销,而这正是快照事实表(周期快照事实表)所需要解决的范畴。
                
                所谓周期快照事实表,是指间隔一定的周期对业务的状态进行一次拍照并记录下来的事实表。最常见的例子是销售库存、银行账户余额等。
                
                与事务事实表的稀疏性不同(这里的稀疏性是相对的),周期快照事实表通常被认为是稠密的。因为事务事实表只有事务发生才会记录,但是周期快照则必须捕获当前每个实体的状态。比如,某个商品如果某天没有销售,那么这个商品是不会存在于当天的事务事实表中,但是为了记录其库存情况,即使没有销售行为,也必须在周期快照事实表中对其拍照。
                
                周期快照事实表的周期通常需要和业务方共同确定,最常见的周期是天、周和月等。
                周期快照事实表中的事实一般是半可加的,入某个商品的库存可以跨商品、仓库等相加,但是明显在时间上相加是没有意义的。
                下面以超市的库存业务为例来介绍周期快照事实表的设计过程。
                (1) 选择业务过程
                本例是为了更好地理解超市的库存情况,因此业务过程就是商品的库存情况,即在什么时候、什么商品、那个仓库的库存量如何。
                (2) 定义粒度
                  这里的粒度主要指库存的周期,商品的粒度很容易确定(需要注意这里的商品是SKU级别,而不是商品型号级别,比如一双特定型号的鞋子有尺码,每个尺码还有颜色,这里的库存显然应该在SKU级别,即某个型号的、某个尺码的、某种颜色的鞋子库存)。选择库存的周期需要考虑到数据量的膨胀情况。考虑如下例子,某个超市有1万个商品(即SKU),其中有100加连锁店,那么对其库存拍照将有100X10 000 = 100万行记录,那么一年将有 365* 1000 000=3.65亿条记录。当然随着目前存储的日益廉价,这些都不是问题,但是设计人员需要考虑到这些因素。
                (3) 确定维度
                    对于超市零售库存,相应的维度为周期(天、周、月等)、商品、仓库(总仓、分仓或者门店等)。
                (4) 确定事实
                    这里的事实很容易确定,即库存量。但是仅仅记录现存库存量是不够充分的,因为业务上通常会和其他事实协同来度量库存的变化趋势、快慢等,所以还可对周期快照实施表的事实进行增强,常见增量度量包括库存价值(库存量*销售价格)、库存成本(库存量*成本价格)、周期销量(库存周期内销量)和去化天数(基于周期内销量预计需要的库存售罄天数)等。
                    周期快照事实表及相关维度如图:
                    
                    

            
    6.3.3 累计快照事实表


                事实表的第三种类型是累计快照事实表,相比前两者,累计快照事实表没那么常见,但是对于某些业务场景来说非常有价值。
                
                累计快照事实表非常适用于具有工作流或者流水线形式业务的分析,这些业务通常涉及多个时间节点或者主要的里程碑事件,而累计快照事实表是从全流程角度对其业务状态的拍照。
                
                考虑车险理赔业务,一次车险的理赔通常包括客户报案、保险公司立案、客户提交理赔材料、理赔审批通过和付款等关键步骤,而累积快照事实表正是从全流程角度对每个车险理赔单的拍照,拍照内容即是其关键步骤的各个状态,便于业务人员一目了然地分析各个理赔单的状态、步骤间的耗时等。
                
                下面以车险理赔业务为例来介绍累计周期快照事实表。
                (1) 选择业务过程
                本例是为了更好地理解保险公司得车险理赔业务,因此业务过程就是车险理赔,即在什么时候、哪个理赔申请所处的状态如何。
                
                (2) 定义粒度
                    累计周期快照实施表的粒度一般很容易确定,就是业务的某个实体,这里即为保险理赔申请。
                
                (3) 确定维度
                
                    对于累计周期快照事实表,相关的维度包含快照周期(天、周、月和年等)、理赔申请人、受理人、审核人、网点(电话或者实体)等。
                
                (4) 确定事实
                    这里的事实包括索赔金额、审批金额、大款金额、处理时长等。
                基于上述设计的累计快照事实表及相关维度表如图:

     6.3.4 无事实的事实表


            在维度建模中,事实表是过程度量的核心,也是存储度量的地方。但事实表并不总是包含度量和事实。这类不包含事实的事实表被称为无事实的事实表。
            
            乍听有点奇怪,但是请考虑下面业务场景,银行客户服务中心接受客户电话咨询或者在线业务咨询,这里并没有任何的业务度量值,唯一的度量值就是单次咨询事件。
            其他类似事件还有学生课程出现情况、用户在网站上的浏览行为、客户对广告的点击行为。
            
            无事实的事实表通常人为增加一个常量列(其列的值总是为1)来方便对业务事件的统计分析。
            
            如图是以学生在各门课程中的出席情况为例给出无事实的事实表的维度设计方案。
            类似【统计学生签到表】

         

    6.3.5 汇总的事实表


                尽管在当今的大数据时代,计算和存储的代价越来越低,但不代表是没有代价的。处于对性能以及下游使用便捷性的考虑,数据仓库还经常对事实表预先进行聚合和汇总。
                
                通过仔细的规划和设计,汇总的事实表能够给计算和存储的成本、数据仓库的性能带来很大的收益。
                尽管聚集和汇总能带来良好的收益,但是也需要付出代价。代价就是带来额外的聚集和汇总任务的维护,尤其是上游明细有任何改动或者更新,如果需要重新更新汇总的事实表,那么重刷事实表的代价也是比较大的。
                
                实际项目中,常常根据业务需求的频繁性来确定需要聚集的维度。此外,为了保证数据的一致性,汇总的事实表通常基于明细表的维度和事实进行计算,以保证维度和计算口径的一致。
                

    6.4.2 维度表


            大数据时代对于维度表设计改变最为明显的是缓慢变化维的处理。在传统缓慢变化维的处理中,需要根据实际情况选用6.2.1 的三种方法或者其组合等来处理维度的缓慢变化情况。大数据时代的处理则更为简单和直接,既然存储已经变得廉价,那么为什么不讲维度表的快照每天存储一份呢?毕竟相对事实表来说,维度表所占用的存储小的很多。
            用维度表快照的方式来处理缓慢变化维,实际上也是用存储的冗余开销换来了缓慢变化维复杂逻辑的消除以及下游使用的便捷。想想传统方式要捕获每个维度字段的缓慢变化以及维护对应在事实表代理键的处理复杂性,还有给下游维度表使用所带来的困惑和使用成本,快照的缓慢变化维处理方式还是非常值得的,因为相应的ETL 逻辑要简化很多,而且下游使用也更为直接和方便。
               用快照方式处理缓慢变化维还直接带来了微型维度的消除,因为不管是维度的缓慢变化,还是微型维度要解决的维度频繁变化,快照的方式已经包含了所有历史变化。
            大数据时代对维度表设计改变的还有维度层次、杂项维度以及多值维度/属性。大数据对这些维度设计的处理时扁平化和反规范化。
            维度层次的扁平化也就是在单一维度表中用冗余字段来存储所有层次,维度有5个层次就用5个层次字段,有10个就用10个层次字段,存储和成本不是问题。
            杂项维度和多值维度/属性同样也是多字段解决方案。比如前文所述的账户交易事实表对应多个账户人的问题,有几个账户人就用几个账户字段(当然实际中可以加以限制,比如通过大字段存储超过2个的其余共同账户人),多值属性也可以通过类似方案来解决(当然也可以通过大字段的方式来解决,比如把多值属性组装成键值对放在一个长字符串内。)
            


        6.5 本章小节

            本章主要介绍了维度建模的只是,包括维度建模的基本概念(度量、事实、事实表、维度表、雪花架构、星形架构)和维度建模的一般过程(选定业务过程、定义粒度、确定维度和确定事实)。
            
            在此基础上,本章还深入探讨了维度表和事实表设计,包括如何处理维度变化、维度层次、维度一致性、维度整合和拆分以及维度的其他概念(退化维度、行为维度、角色维度、杂项维度、微型维度、多值维度和属性),还有事务事实表、快照事实表、累计快照事实表、无事实表的事实表和汇总事实表的设计等。
            
            最后,本章就大数据时代对于维度建模理论设计的主要改良和优化进行了介绍。
            至此,离线数据开发的相关知识均已介绍完毕。下一章将以一个实例为例,总和运用这些内容,尤其是在大数据的维度建模实践方面。
                

    展开全文
  • Kimball维度建模基本理论

    千次阅读 2019-08-15 15:21:07
    维度建模基础理论,以及优越之处和应用场景。阐明了何为事实和维,并且解释了相关细分类别和应用场景。
    本文相关基本理论摘录自《数据仓库工具箱–维度建模的完全指南-第二版》和《数据仓库声明周期工具箱》

    维度建模介绍

    维度建模是一种将数据结构化的逻辑设计方法,将客观世界划分为度量和上下文。机构的每一个业务过程都可以使用维度模型来描述,维度模型由一系列含有数值型度量的事实表组成,而事实表中的数值型度量则被一系列带有文本形式上下文的维度表所环绕。
    度量(事实)

    由机构的业务过程和支持他们的业务源系统来捕捉的。常以数值形式出现,以此称为“事实

    上下文(维)

    就是解释度量中数值的具体含义,上下文是围绕这度量存在的,只有当事实被记录时上下文才为真。上下文被直观的分割成多个独立的逻辑块,我们称为“”。维度描述了度量上下文的5W(who,what,when,where,why)信息,以及这些上下文是如何作用的。

    维度建模的优点
    • 可理解性,易于使用
    • 查询性能高
    • 修改的灵活度高

    一、事实表

    事实表: 存储了从机构业务活动或者事件中提炼出来的性能度量。术语 “事实” 就是指每种性能度量 ,事实表的一行对应一个度量值,所有度量值必须具有相同的粒度。
    (1)事实表粒度都归属于三类:

    1. 事务粒度事实表 : 粒度是每一行对应一个事务,事务粒度是空间和时间的焦点,一个事务粒度上的度量必须在那个时刻为真。事务事实表在活动发生时才会插入行。
    2. 周期快照事实表:能够按照一个定义良好的时间周期间隔来捕捉业务过程的执行情况,并且将这些描述装载到事实表中。
    3. 积累快照事实表:用于描述业务过程(有明确的开端和结尾)中某个不确定时间跨度里的活动。

    事务和快照是数据仓库的阴阳两面,事务是展现细节行为最为完整的视图,快照使我们迅速而容易的监视总体执行情况

    (2)事实表的字段分类

    1. 可加性: 例如 条数,金额等
    2. 半可加性 : 表示某一时间点的强度度量,例如: 库存量,账户结余
    3. 完全不可加性: 例如: 单位价格,温度等

    备注:百分比和比率这类数值都是非加性的分子与分母都应该存在事实表中。可以利用数据存取工具计算出事实表中任何数据形式的比率,要记住,求取的是合计值的比率而不是比率的求和

    二、维度表

    (1) 时间维度

    每个事实表都是一个观测值的时间序列,事实表总是有一个或者多个日期维。下图显示了一个以天为粒度的标准日期维度表。
    在这里插入图片描述

    (2)退化维

    定义: 像订单号,发票号,机票号等这类编号正是设计父-子关系的事务处理系统时所用到的父标题键,不要忽略这些标题编号,而是应当直接添加到事实表中,标题票号可以作为维度键,但是如果像事务日期和客户维那样将标题记录信息分解成独立的维,那么这个维就没有其他属性了。我们称之为退化维
    退化维常常出现在事务事实表的设计过程中,本身就具有一种父-子关系的数据结构

    个人理解: 退化维就是没有对应维度表的维度,本质上它是存在于事实表中,并且相应的编码,号码字段没有与之对应的维度表,因为此类维度没有对应的上下文解释。但是,退化维在事实表中普遍存在,并且经常会和其他一些维度组合形成事实表的主键。

    例如:在Kimball提出的维度建模中,事实表应该保存最细粒度的数据。所以对于象销售单这样的事实表来说,需要销售单编号和产品来共同作为主键,而不能用销售日期、商场、产品等用来分析的维度共同作为主键。

    (3)缓慢变化维
    • 类型一: 覆盖维度属性
    • 类型二: 添加一个新的维度行
    • 类型三: 添加一个新的维度属性
    • 类型四: 微型维,添加一个新维,将经常变化的客户属性分解开放到独立的维度表中。原理就是将变化频率比较大的维度拆分出来单独作为维度表处理。

    关于SCD的详细介绍参照博客 缓慢变化维(SCD)的处理方法

    (4)雪花型和支架
    当冗余属性和译码都被转移到单独的表,并且通过人工键连接到原始表时,维就变成了雪花型了。
    支架是一个统计属性集合,存在于每个辖区层次,一个辖区的所有客户都共享一个相同的属性集合。

    例如:
    在这里插入图片描述

    (4)维度属性应该具有以下特点
    1. 是冗长的
    2. 是描述性的
    3. 是完整性的-没有遗漏值
    4. 是离散取值的
    5. 质量是有保证的
    (5) 事实表和维度表的判断
    一个比较好的经验性法则是看看属性是否是离散取值的,以及是否用过过滤和标记。如果满足这些条件就应当放在维度表中。如果属性有许多值可选,并且可以用于计算,则应该将其放入事实表。

    供应链管理: 一个产品的流动过程是从获取原材料到加工称为成品,再到最终交付给客户的整个过程,从原始起点到消费终点的整个流程的管理 唱唱是被称作“供应链管理”

    (6) 一致性维度
    一致性维度是企业数据仓库的“总线”, 一个强大的基于一致性维度的架构将一组业务过程紧密联系到一起就形成了企业数据仓库。

    一致性维度对于企业级的数据仓库极为重要,有以下优点:

    • 1 一致性: 每个事实表都使用一致的过滤条件,产生的查询结果集合也被唯一地标识。
    • 2 集成: 首先单独查询每个事实表,最后将结果集连接到一个公共的维度属性上
    • 3 开发周期短:若一致性维度建立起来,后续的项目开发时间会极大的缩减,不需要重复创建相关的维度表
    展开全文
  • 维度建模经典理论 维度建模是数据仓库建设中的一种数据建模方法,将数据结构化的逻辑设计方法,它将客观世界划分为度量和上下文,Kimball最先提出这一概念。 其最简单的描述就是,按照事实表,维度表来构建数据...
  • Kimball维度建模

    2020-05-30 16:43:13
    文章参考经典书籍:《数据仓库工具箱(第3版)-维度建模指南》 基本概念: 维度建模: 事实表 维度表 Kimball维度建模4步骤 选择业务过程 声明粒度 确认维度 确认事实 ...
  • 文章目录1 数仓分层1.1 基本分层模型1.2 数据集市和数据仓库2 数仓理论2.1 范式理论2.2 关系建模和维度建模2.2.1 关系建模2.2.2 维度建模2.2.2.1 维度建模的三种模型2.3 维度表和事实表2.3.1 维度表2.3.2 事实表 ...
  • 下面的内容,是笔者在学习和工作中的一些总结,其中概念性的内容大多来自书中,实践性的内容大多来自自己的...因此,下面的将详细地阐述数据建模中的典型代表:维度建模,对它的的相关理论以及实际使用做深入的分析。
  • 维度建模基本理论

    2021-01-22 11:53:05
    Kimball维度建模基本理论
  •   维度建模是一种将数据结构化的逻辑设计方法,也是一种广泛应用的数仓建模方式,它将客观世界划分为度量和上下文。度量是常常是以数值形式出现,事实周围有上下文包围着,这种上下文被直观地分成独立的逻辑块,称...
  • 维度建模

    千次阅读 2021-05-16 23:00:36
    1 维度建模关键概念 1.1 度量和环境 1.2 事实和维度 在维度建模中,度量称为事实,上下文和环境称为维度。 1.3 事实表 事实常以数值形式出现,而且一般都被大量文本形式的上下文包围着。这些文本形式的上下文描述了...
  • 遵循这些原则进行维度建模可以保证数据粒度合理,模型灵活,能够适应未来的信息资源,违反这些原则你将会把用户弄糊涂,并且会遇到数据仓库障碍。 原则1、载入详细的原子数据到维度结构中 维度建模应该使用最基础的...
  • 维度建模的数据仓库中,有一个概念叫Bus Architecture,中文一般翻译为“总线架构”。总线架构是Kimball的多维体系结构(MD)中的三个关键性概念之一,另两个是一致性维度(Conformed Dimension)和一致性事实...
  • 数据仓库(二)之维度建模

    万次阅读 多人点赞 2018-09-12 22:29:28
    维度建模是一种将数据结构化的逻辑设计方法,它将客观世界划分为度量和上下文。度量是常常是以数值形式出现,事实周围有上下文包围着,这种上下文被直观地分成独立的逻辑块,称之为维度。它与实体-关系建模有很大的...
  • 维度建模方法论

    千次阅读 2022-02-11 15:20:21
    维度建模方法 一、前言 本人学习《数仓工具箱》的学习总结,纯学习分享,供大家参考。 二、经典数仓架构理论 围绕着维度建模,那就不得不了解,早期的数据仓库构架方法。这里介绍一下两个经典的数仓架构理论。 2.1...
  • 1. 维度建模理论概要 1.1 维度设计的主要流程 1.1.1 选择业务过程 业务过程是组织完成的操作性活动,例如:获得订单、处理保险索赔、学生课程注册或每个月每个账单的快照等。业务过程事件建立或获取性能度量,并...
  • 建模流程2. 迭代流程3. 维度表4. 事实表 1. 建模流程 确认每个主题域,明确范围,即事实表清单。 根据业务流程(比如投保->承保->…)拆分相关实体 确认维度维度退化:who?when?where? 根据不同实体内容...
  • 数仓维度建模实例

    千次阅读 2022-04-14 17:35:25
    本文将介绍维度建模理论,基于自己经验的实施步骤 数据模型就是数据组织和存储方法,它强调从业务、数据存取和使用角度合理存储数据.... 只有数据模型将数据有序的组织和存储起来之后,大数据才能得到高性能、低...
  • 关系建模与维度建模

    2022-01-26 14:05:59
    关系建模与维度建模
  • 文章目录一、前言二、什么是维度建模三、维度建模的基本要素3.1 事实表3.2 维度表 一、前言 学习数据仓库,你一定会了解到两个人:数据仓库之父比尔·恩门(Bill Inmon)和数据仓库权威专家Ralph Kimball。 Inmon和...
  • 本系列既有数据仓库的形而上学理论体系,也有结合公司业务的实践,既有大厂如阿里巴巴,京东,头条的分享交流,也有小公司数仓迭代案例的建设分析。感兴趣的小伙伴可以私信交流。 0.数仓相关系列历史篇章回顾 1. ...
  • 1.事实表 2.维度表 3.模型 4.粒度 5.层次
  • 对于 Inmon 和 Kimball 两种建模方式可以长篇大论叙述,但理论是很枯燥的,尤其是晦涩难懂的文字,大家读完估计也不会收获太多,所以笔者根据自己的理解用通俗的语言提炼出最核心的概念。 范式建模 范式建模是数仓...
  • 维度建模和范式建模对比

    千次阅读 2021-04-14 18:24:45
    对于 Inmon 和 Kimball 两种建模方式可以长篇大论叙述,但理论是很枯燥的,尤其是晦涩难懂的文字,大家读完估计也不会收获太多,所以我根据自己的理解用通俗的语言提炼出最核心的概念。 范式建模 范式建模是数仓之父...
  • 数仓理论之关系建模与维度建模

    千次阅读 2019-04-26 20:37:42
    维度模型主要应用于OLAP系统中,因为关系模型虽然冗余少,但是在大规模数据,跨表分析统计查询过程中,会造成多表关联,这会大大降低执行效率。 所以把相关各种表整理成两种:事实表和维度表两种。所有维度表围绕着...
  • 大数据之维度建模中的重要概念

    千次阅读 2022-03-16 16:20:13
    本篇博客,是在经历了小10轮大数据开发面试后,博主对大数据建模中,比较重要的知识点进行了梳理,截取了书中一些常考的概念,供大家参考。

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 21,196
精华内容 8,478
关键字:

维度建模理论