数仓建模篇（二）

1.星型模型与OLAP多维数据库

• 在关系型库管理系统中实现的维度模型称为星型模型，因为其结构类似星型结构

• 在多维数据库环境中实现的维度模型通常称为联机分析处理

   

2.用于度量的事实表

• 维度模型中的事实表存储组织机构业务过程事件的性能度量结果

  • 尽量将来与同一个业务过程的底层度量结果存储于一个维度模型中

  • 允许多个组织的业务用户访问同一个单一的集中式数据仓库

  • 事实表的每一行对应一个度量事件

注：物理世界的每一个度量事件与对应的事实表行具有一对一的关系，这一思想是维度建模的基本原则，其他工作都是以此为基础建立的

 

• 事实表类型

  • 数值类型和可加类型事实

    • 美元销售额

  • 半可加事实

    • 账户结余

  • 不可加事实

    • 单位价格

• 事实通常以连续值描述，这样做有助于区分到底是事实表还是维度属性的问题

• 事实表的粒度

  • 事务

  • 周期性快照

  • 累计快照

3.用于描述环境的维度表

• 维度表包含于业务过程度量事件有关的文本环境，用于描述“5W2Y”有关的事件

• 维度属性可作为查询约束、分组、报表标识的主要来源

  • 操作码具有一些智能含义

    • 头两位数字表示业务类型

    • 3-4位表示全球区域

• 维度属性的设置决定数仓好坏

  • 确保属性值的质量耗费时间越多，效果就越好

  • 强大的维度属性=》健壮的分片-分块分析能力

• 星型模式中维度与事实的连接

  • 维度模型包含每个业务过程

    • 事实表存储事件的数值化度量

    • 维度表包含实践发生时实际存在的文本环境

• 基于Kimball架构的DW/BI环境组成

  • 核心架构

    • 操作性源系统

      • 记录的操作型系统，用于获取业务事务

        • 关注处理性能和可用性

        • 不维护历史信息

        • 一种针对特性意图的应用

          • 不与其他系统共享

    • 获取-转换-加载系统

      • ETL

    • 用于支持商业智能决策的展现区

      • 数据应该以维度模型来展现，要么采用星型模型，要么采用OLAP多维数据库

      • 必须包含详细的原子数据

      • 围绕业务过程度量事件来构建

      • 必须使用公共的、一致性的维度建立维度结构

    • 商业智能应用

      • 查询工具

      • 复杂的数据挖掘或建模应用

• 其他DW/BI架构

  • 独立数据集市架构

    • 各部门自建数据集市

  • 辐射状企业信息工厂Inmon架构

    • 采用CIF方法的企业通常允许业务用户根据数据细节成都和数据可用性要求访问EDW仓库

  • 混合辐射架构与Kimball架构

    • 利用了CIF中处于中心地位的EDW

    • 与Kimball结合

• 维度建模神话

  • 维度模型仅包含汇总数据

    • 不可能预测业务用户提出的所有问题，因此必须向业务用户提供对明细数据的查询访问

    • 存储有限的历史数据

  • 维度模型时部门级而不是企业级

    • 维度模型应该围绕业务过程组织，例如，订单、发货、服务调用等，而不是按照组织中部门的职责划分

    • 多部门往往需要分析来自同一业务过程的相同的度量

  • 维度模型时不可扩展的

    • 维度模型非常易于扩展

  • 维度模型仅用于预测

    • 设计以度量为中心

    • 维度模型中正确的做法是以最详细的粒度表达数据，这样可以获得最好的灵活性和可扩展性

  • 维度模型不能被集成

    • 如果遵循企业数据仓库总线结构，维度模型多数都能够被集成

4.使用维度模型的理由

• 考虑报表和控制面板的业务过程度量是什么

• 数据管理或治理项目首先应该关注主维度集

• 敏捷性考虑

  • 敏捷方法与Kimball最佳实践契合

  • 企业数据仓库总线矩阵=》强有力工具