DW002 - 数据仓库模型设计

 

数据模型

关系模型与维度模型

常见数据模型设计方法

 

 

数据模型

 

1. 什么是数据模型

• 模型 - Model
  • 模型是指对于某个实际问题或者客观事物、规律进行抽象后的一种形式化表达方式
  • 比如地图、建筑设计沙盘、模型飞机等等……
  • 模型的建立为某些领域，带来了更多实际的意义
• 数据模型DM - Data Model
  • 数据模型一般多指在设计和建立数据库时，用于提供数据表示和操作手段的形式架构
  • 使用数据模型，可以提供一些良好的特性，以适应特定场景
• 企业数据模型EDM - Enterprise Data Model
  • 企业数据模型是企业数据特征的抽象，主要用于体现企业的业务规则以及信息。
  • 通过图形的实体和关系方式反映一个业务过程，是进行数据管理、分析和交流的重要手段，是模型、ETL、业务人员沟通的桥梁。

 

2. 数据模型的层次

• 概念模型（CDM，Concept Data Model）
  • 定义了重要的业务概念和彼此的关系
  • 由核心实体或其集合，及实体间的业务关系组成
  • 类似行业数据模型
• 逻辑模型（LDM，Logical Data Model）
  • 对概念数据模型的进一步分解和细化
  • 描述实体、属性、以及实体与实体之间的关系
• 逻辑模型（PDM，Physical Data Mode）
  • 描述模型实体的细节，对数据冗余与性能进行平衡
  • 关注数据库的物理实现，解决细节技术问题
  • 需要考虑数据类型、长度、索引等因素
  • 需确定数据平台和架构

 

3. LDM & PDM

  逻辑数据模型（Logical Data Model，PDM），是数据仓库在数据建设阶段为解决业务需求而定义的模型解决方案，是战略层面的，主要决定模型的总体架构，它是连接数据仓库的数据与最终用户之间的逻辑桥梁，但它还不能直接拿来实施，它并不是数据仓库数据的真实物理反映。

  物理数据模型（Physical Data Model，即PDM）是基于逻辑数据模型的物理化，它是在继承逻辑模型设计框架和原则的基础上，针对系统性能和应用需求而进行的适当的非范式化的物理模型设计，它更着眼于实施、操作和性能，更贴近数据，它是数据仓库数据的真实物理反映。

• 相同点
  • 主题一致、主体结构一致、主要实体一致和主要字段相同
  • PDM继承了LDM的灵活性，易于扩展等优点
  • LDM有利于业务人员和最终用户对PDM的理解
  • LDM是PDM成功实施的基础性保障
• 不同点
  • PDM更着眼于实施、操作和性能，更贴近数据
  • PDM需要经常性的维护
  • PDM更多的考虑系统物理特性
  • PDM更多的考虑数据处理性

 

 

 

关系模型与维度模型

 

1. 关系模型

• 关系数据模型的规范化是一种组织数据的技术
  • 规范化方法对表进行分节，以消除数据冗余，避免异常更新，提高数据完整性
  • 通过实体关系（ER）描述企业业务和业务规则
    • 实体：客观存在并且可以相互区别的事物称为实体
    • 关系：描述实体间的关联性，实体间的关系基本上有三种（一对一，一对多，多对多）
    • 属性：一个属性是在数据模型中用来描述一个事物的最基本元素。是描述一个事物或交易在数据元素级上的抽象定义
• 关系模型 - 3NF
  • 在范式理论上符合 3NF
    • 每个属性值唯一，不具有多义性；
    • 每个非主属性必须完全依赖于整个主键，而非部分主键；
    • 每个非主属性不能依赖于其他关系中的属性，因为这样的话，这种属性应该归到其他关系中去。
  • 数据仓库中的3NF与OLTP系统中的3NF的区别在于，它是站在企业角度面向主题的抽象，而不是针对某个具体业务的抽象。
  • 优点：模型稳定、相对简单
  • 典型行业：传统金融、证券行业，如银行。

 

2. 维度模型

• 维度模型
  • 维度模型是一种趋于支持最终用户的、从分析决策的需求出发的数据模型
  • 关注用户如何更快地完成需求分析，同时具有较好的大规模复杂查询响应能力
  • 特点：易理解、高性能、易扩展
  • 维度模型将表分为维度表和事实表：
    • 维度表（Dimension）：对数据进行分类的表，用于从特定的角度观察数据。维度是事实表的入口点或链接，充当“查询”或“报表”约束的主要来源；维度通常是高度反范式的，通常占总数据的10%左右。例如：时间、地区、产品等
    • 度量表（Measure）：又叫事实表（Fact），是维度建模中最基本的表，存放业务度量数据，例如数量、金额、汇总等流水和快照数据。

 

事实表

• 数仓/数集维度建模的核心，围绕业务过程进行设计
• 通过获取表述业务过程的度量来表达业务过程
• 包含了应用的维度和与业务过程有关的度量
• 基础结构
  • 一个或者多个数值型的度量字段，我们称之为事实（Fact）
  • 一组关联到维表的外键，而这些的维表提供了事实表度量的上下文
  • 一个或者多个退化维度（Degenerate Dimensions）
    • 退化维度存在于事实表，但是他们不是外键，不关联任何真正的维表
    • 可能会是事实表的主键

 

• 事实表分类：事务事实表
  • 用来描述业务过程，跟踪空间或时间上某点的度量事件
  • 保存的是最原子的数据，也称为“原子事实表”、“交易事实表”
• 事实表分类：事务事实表设计原则
  • 事实完整性
    • 事实表包含与其描述的过程有关的所有事实，即尽可能多地获取所有的度量
    • 比如支付业务过程，在子订单粒度上的支付金额、支付邮费、支付红包、支付积分、支付折扣都有所包含，覆盖全面
  • 事实一致性
    • 在确定事务事实表的事实时，明确存储每一个事实以确保度量的一致性
    • 比如在下单业务国城中，有下单商品数量和商品价格两个事实，但在事实表中计算了下单金额和下单有效金额
  • 事实可加性
    • 事实表确定事实时，往往会遇到非可加性度量，比如分摊比例、利润率等，虽然他们也是下游分析的关键点，但往往在事务事实表中关注更多的是可加性事实，下游用户在聚合统计时更加方便。
• 事实表分类：周期快照事实表
  • 周期快照事实表表现的是一个时间段，或者规律性的重复。这类表非常适合跟踪长期的过程，例如银行账户和其他形式的财务报表。
• 事实表分类：周期快照事实表特点
  • 密度与稀疏性
    • 快照事实表和事务事实表的一个关键区别在密度上。
    • 事务事实表是稀疏的，只有当天发生的业务过程，事实表才会记录该业务过程的事实。
    • 快照事实表是稠密的，无论当天是否有业务过程发生，都会记录一行。
  • 半可加性
    • 在快照事实表中收集到的状态度量都是半可加的。
    • 与事务事实表的可加性事实不同，半可加性事实不能根据时间维度获得有意义的汇总结果。
      • 在每个采样周期内不能对状态度量进行汇总
      • 虽然不能汇总，但是可以计算一些平均值，比如计算每天一个下单的平均值。
• 事实表分类：累积快照事实表
  • 累积快照事实表用于描述那些有明确开始和结束的过程，例如合同履行，保单受理以及常见的工作流。累积快照不适合长期连续的处理，如跟踪银行账户或者描述连续的生产制造过程，如造纸。
  • 累积快照事实表的粒度是一个实体从其创建到当前状态的完整的历史。
  • 对于类似于研究事件之间时间间隔的需求，采用累积快照事实表可以很好地解决。
• 事实表分类：无事实的事实表
  • 第一种是事件类：每个事实表的粒度是一个事件量测。在某些情况下，事件可以发生，但是没有具体的测量值。例如一个事实表用来记录交通事故事件。每个事件的发生是无可质疑的，维度设计是强制性且非常直接的。
  • 第二种是条件、范围或资格类的：记录维度与维度多对多之间的关系。比如客户和销售人员的分配情况、产品的促销范围等。

 

维度表

• 维表提供了事实表的上下文；维表通常比事实表小得多；提供了查看数据的入口。
• 基础结构：
  • 代理键
    • 一个无意义的，唯一标识的字段
    • 维表的主键，事实表的外键
  • 自然键
    • 一个或多个字段
    • 从源系统抽取来的有意义的字段
  • 描述属性
    • 静态或者变化比较慢的字段
    • 会有多个
• 缓慢变化维
  • 数据仓库的重要特点之一是反映历史变化，如何处理维度的变化是维度设计的重要工作之一。
  • 在现实世界中，维度的属性并不是静态的，它会随着时间的流逝发生缓慢的变化。
  • 与数据增长较为快速的事实表相比，维度的变化相对缓慢。
  • 在某些情况下，保留历史数据没有什么分析价值；而在另一些情况下，保留历史数据将会起到至关重要的作用。
  • 使用代理键作为每个维表的主键，方便处理缓慢变化维。
  • 在Kimball的理论中，有三种处理缓慢变化维的方式：
    • 重写纬度值
    • 插入新的维度行
    • 添加维度列

 

 

常见数据模型设计方法