范式建模

该方法的主要由Inmon所提倡,主要利用关系型数据库进行数据仓库的建设,且模型的建设方法和业务系统的数据模型比较类似
经典范式理论中,一个符合第三范式的关系必须具有以下三个条件:

  • 1NF:每个属性值唯一,不具有多义性;
  • 2NF:每个非主属性必须完全依赖于整个主键,而非主键的一部分;
  • 3NF:每个非主属性不能依赖于其他关系中的属性。

优点:

  • 节约存储
  • 结构清晰
  • 易于理解
  • 适合关系型数据库

缺点:

  • 构建比较繁琐
  • 查询复杂
  • 不适合构建在大数据分布式环境下

虽然有这些缺点,但是范式建模的理论,仍然是需要我们去熟练掌握。原因有如几点:

  • 数据仓库的上游有相当一部分数据源是业务数据库,而这些业务数据库,其理论一般基于范式理论;
  • 数据源的规范定义需要我们了解范式理论;
  • 数据仓库下游系统比如报表系统设计时,可能会用到范式理论。

维度建模

范式由于存在上述的问题,Kimball根据自己的经验,提出的维度建模的理论,即数据都可以抽象成事实和维度,维度为观察事物的角度,事实为对应某粒度下的度量值,一般,维度建模的步骤如下:

  • 1.选择业务过程
    业务过程是-系列操作活动,转换为事实表中的事实,例如每个月每个账单快照
  • 2.声明粒度
    粒度是指事实表中的一行代表什么。同一事实表不要混用粒度,最好从最小粒度开始设计维度,因其能承受用户无法预知的查询需求。
  • 3.确认维度
    维度是根据粒度将表分开成多个维度表,即从不同维度(角度)去看。
    维度是数据仓库的灵魂,是BI的入口和驱动
  • 4.确认事实
    事实是指一种在某个粒度下的度量,例如在销售维度中,销量和总额是良好的事实,而商店经理的工资则不允许出现在该维度中。

优点:

  • 方便使用
  • 适合大数据下的数据处理
  • 适合进行OL AP操作

缺点:

  • 维度补全造成的数据存储的浪费
  • 维度变化造成的数据更新量大
  • 与范式理论差异很大,是典型的反三范式

维度建模举例

假设我们要构建的是一张订单表,那业务过程即为这个具体是哪种业务场景下的订单数据;

粒度即为该表中的每一 条数据具体是细化到如何的程度,是一条数据代表一个订单还是多个订单;

维度即为该订单有哪些的附属信息,比方说订单类型、支付方式、城市信心、日期信息等等;

事实是指具体的订单量的数值。

那么,我们可以假设,这个订单表的基础信息包括:

编号字段
01订单ID
02发货人ID
03收件人ID
04发货时间
05发货地点
06快递单号
07物品件数
08订单总金额
09订单状态
10下单时间
11支付订单号
12支付时间
13支付状态
14收货时间
15收货状态

业务过程:用户购买商品的订单记录表
申明粒度:每一条记录代表一个有效订单
确认维度:商户维度、用户维度、支付维度、收货维度
确认事实:订单总金额

通过对不同的维度进行统计组合,我们就会得到一个多维数据集,来从多角度观察我们的业务过程的好坏情况。


参考:https://www.bilibili.com/video/BV1Z4411m7NV?p=6