事实表结构:
事实表:即发生在现实世界中的操作性事件.从最低的粒度级别来看,事实表行对应一个度量事件,反之亦然.因此事实表的设计完全依赖于物理活动,不受可能产生的最终报表的影响.除数字度量外,事实表总是包含外键,用于关联与之相关的维度,查询请求的主要目标是基于事实表开展计算和聚集操作.
相关名词解析:
可加事实:指可以按照与事实表相关的所有维度进行累加
半可加事实:只能按照与事实表相关的一部分维度进行累加,周期性快照事实表中的事实.例如差额
不可加事实:完全不具备可加性,例如比率型事实
事实表中的空值
事实表中可以存在空值度量,但是在事实表的外键中不能存在空值,否则会导致违反参照完整性的情况发生.关联的维度表必须用默认行(代理键)而不是空值外键表示未知或无法应用的条件
事实表代理键
不与任何维度关联的事实表代理键的主要作用:
- 作为事实表的唯一主键列;
- 在ETL中,用作事实表行的直接标识符,不必查询多个维度;
- 允许将事实表更新操作分解为风险更小的插入和删除操作;
一致性事实
如果某些度量出现在不同的事实表中,需要注意,如果需要比较或计算不同事实表中的事实,应保证针对事实的技术定义是相通的.如果不同的事实表定义是一致的,则这些一致性事实应该具有相同的命名,如果它们不兼容,则应由不同的命名用于告诫业务用户和BI应用.
三种常用事实表
事务事实表:用来记录各业务过程,它保存的是各业务过程的原子操作事件,即最细粒度的操作事件.粒度是指事实表中一行数据所表达的业务细节程度.
弊端:事务事实表不适宜存储以下特征的数据:
1)存量性指标
2)多事务关联统计
周期快照事实表:以具有规律性的、可预见的时间间隔来记录事实主要用于分析一些存量型或者状态型指标。用来处理例如每日-每个仓库-每种商品数量的事实。
累积快照事实表:是基于一个业务流程中的多个关键业务过程联合处理而构建的事实表,如交易流程中的下单、支付、发货、确认收货业务过程.
三种事实表的区别:
扩展事实表
- 无事实的事实表
尽管多数度量事件获取的结果是数字化的,但也存在某些事件仅仅记录一系列某一时刻发生的多维实体.例如,在给定的某一天发生的学生参加课程的事件,可能没有可记录的数字化事实,但该事实带有一个包含日历天、学生、教师、地点、课程等定义良好的外键.同样,客户交际也是一种事件,但没有相关的度量.利用无事实的事实表也可以分析发生了什么.这类查询总是包含两个部分:包含所有可能事件的无事实覆盖表,包含实际发生的事件的活动表.当活动从覆盖表中减除是,其结果是尚未发生的事件. - 聚集事实表
聚集事实表是对原子粒度事实表数据进行简单的数字化上卷操作,目的是为了查询性能. - 合并事实表
通常将来自多个过程的,以相同粒度表示的事实合并为一个单一的合并事实表,这样做能够带来方便.合并事实表特别适合那些经常需要共同分析的多过程度量. - 蜈蚣事实表
蜈蚣事实表一般含有以下几个重要的要素:
中心事实表(Core Fact Table):根据业务场景设计的事实表,例如销售、订购或服务等;
维度表(Dimension Tables):用于描述事实表中的维度属性,例如时间、地理位置、产品、客户等;
桥接表(Bridge Tables):用于解决多对多关系的中间表;
指标(Measures):用于衡量和度量业务过程的数量或规模,例如销售额、客户数量、交易次数等。
优点:
易于理解和管理:该设计模型将事实表放置于中央,将维度表放置于周围,使整个模型架构清晰,易于理解和管理。
灵活性强:由于每个“爪子”对应着一个维度表,因此蜈蚣事实表可解决具有多个维度的复杂数据分析问题,并能扩展适用于不同的业务场景。
提高查询效率:该设计模型的桥接表可进行多表关联,因此可以提高查询效率。
弊端:
结构复杂:尽管该设计模型清晰简单,但事实表连接的维度多,需要建立与之对应的大量的维度表,导致结构复杂,维护成本高。
索引效率低:蜈蚣事实表的连接需要使用多个外键,同时需要建立复杂的多键聚集索引或分组索引才能提高查询效率,而索引效率低会导致查询效率降低。
桥接表数据冗余:蜈蚣事实表中的桥接表是为了解决多对多关系而设计,特殊情况下该模型需要建立到桥接表的多层级表关系,此时将导致桥接表中大量数据的冗余,增加了存储和计算的成本。