一篇文章搞懂数据仓库：三种事实表（设计原则，设计方法、对比） |
您所在的位置：网站首页 › 数据仓库题目 › 一篇文章搞懂数据仓库：三种事实表（设计原则，设计方法、对比） |
一篇文章搞懂数据仓库：三种事实表（设计原则，设计方法、对比）
|
目录 1、三种事实表概述 2、三种事实表对比 3、事实表设计 8 大原则 4、事实表设计方法 第一步：选择业务过程及确定事实表类型 第二步：声明粒度 第三步：确定维度 第四步：确定事实 事实表作为数据仓库维度建模的核心，紧紧围绕着业务过程来设 计，通过获取描述业务过程的度量来表达业务过程，包含了引用的维度 和与业务过程有关的度量。 1、三种事实表概述事实表有三种类型 : 事务事实表、周期快照事实表和累积快照事实表。 1.1 事务事实表也称原子事实表，描述业务过程，跟踪控件或时间上某点的度量事件，保存的是最原子的数据； 个人理解：类似于mysql binlog日志，每一次相关的 change 都记录下来，生成一行新的数据 1.2 周期快照事实表以一个周期为时间间隔，来记录事实，一般周期可以是每天、每周、每月、每年等； 个人理解：只看某个业务过程，比如订单收货，数据按订单收货时间来切分，周期可以为每天、每月等。 1.3 累积快照事实用来描述过程开始和结束之间的关键步骤事件，覆盖过程的整个生命周期，通常具有多个日期字段来记录关键时间点；当过程随着生命周期不断变化时，记录也会随着过程的变化而被修改； 个人理解：要看整个生命周期的多个业务过程，比如：创建订单 → 买家付款 → 卖家发货 → 买家确认收货。粒度是一个订单一行数据，创建订单时间，付款时间，发货时间，收货时间，分别作为一个字段，便于计算不同业务过程的时间间隔。 2、三种事实表对比 事务事实表 周期快照事实表 累积快照事实表 时期/时间 离散事务时间点 以有规律的、可预测的 用于时间跨度不确定的不断变化的工作流 日期维度 事务日期 快照日期 相关业务过程涉及的多个日期 粒度每行代表实体的一个事务 每行代表某时间周期的一个实体 每行代表一个实体的生命周期 事实 事务事实累积事实相关业务过程事实和时间间隔事实 事实表加载 插入 插入 插入与更新 事实表更新 不更新 不更新 业务过程变更时更新 3、事实表设计 8 大原则 原则 1：尽可能包含所有与业务过程相关的事实 分析哪些事实与业务过程相关，是设计过程中非常重要的关注点；在事实表中，尽量包含所有与业务过程相关的事实，即使存在冗余，由于事实通常是数字型，存储开销不会太大； 原则 2：只选择与业务过程相关的事实 如，订单的下单这个业务过程，事实表中不应该存在支付金额这个表示支付业务过程的事实； 原则 3：分解不可加性事实为可加的组件 如，订单的优惠率，应分解为订单原价金额与订单优惠金额两个事实存储在事实表中； 原则 4：在选择维度和事实之前必须先声明粒度 粒度用于确定事实表中一行所表示业务的细节层次，决定了维度模型的扩展性；每个维度和事实必须与所定义的粒度保持一致；设计事实表时，粒度定义越细越好，一般从最低级别的原子粒度开始； 因为原子粒度提供了最大限度的灵活性，可以支持无法预期的各种细节层次的用户需求； 原则 5：在同一个事实表中不能有多种不同粒度的事实 疑问：怎么判断不同事实的粒度是否相同？ 粒度为票一级；（实际业务中，一个订单可以同时支付多张票）票支付金额和票折扣金额，两个事实的粒度为 “票级”，与定义的粒度一致；订单支付金额和订单票数，两个事实的粒度为 “订单级”，属于上一层订单级数据，与 “票级” 事实表的粒度不一致，且不能进行汇总；如果，以订单金额和订单票数这两个维度汇总总金额和总票数，会造成大量的重复计算；原则 6：事实的单位要保持一致 如，订单金额、订单优惠金额、订单运费这 3 个事实，应该采用统一的计量单位，统一为元或者分，以方便使用；原则 7：对事实的 null 值要处理 原因：在数据库中，null 值对常用数字型字段的 SQL 过滤条件都不生效；如，大于、小于、等于、大于或等于、小于或等于；处理：用 0 代替 null ；原则 8：使用退化维度提高事实表的易用性 事实表中存储各种类型的常用维度信息，较少下游用户使用时关联多个表的操作；通过退化维度，可以实现对事实表的过滤查询、控制聚合层次、排序数据、定义主从关系等； 易用性：对事实表，更较少关联操作、过滤查询、控制聚合层次、排序数据、定义主从关系等； 在 Kimball 的维度建模中，通常按照星形模型的方式设计，通过事实表的外键关联专门的维表，这种方式来获取维度，谨慎使用退化维表；这与大数据领域的事实表设计不一样； 思路：通过增加冗余存储，减少计算开销，提高使用效率； 4、事实表设计方法 Kimball 的维度模型设计 4 步法：选择业务过程、声明粒度、确定维度、确定事实； 当前的互联网大数据环境，维度模型的设计，是基于 Kimball 的四步维度建模方法进行了更进一步的改进： 第一步：选择业务过程及确定事实表类型 思路：详细分析需求，对业务的整个生命周期进行分析，明确关键的业务步骤，从而选择与需求有关的业务过程；以实例说明：如何选择业务过程？如何确定事实表类型？ 例：淘宝的一个交易订单
分析业务的生命周期：如上图，业务过程通常使用行为动词表示业务执行的活动；明确关键的业务步骤：该订单流转的业务过程有 4 个：创建订单 → 买家付款 → 卖家发货 → 买家确认收货；根据业务需求，选择与维度建模有关的业务过程；
如，是选择 “买家付款” 这个业务过程，还是选择 “创建订单” 和 “买家付款” 这两个业务过程，具体根据业务情况来定；根据所选的业务过程确定事实表类型；
如，选择 “买家付款” 这个业务过程，则事实表类型应为只包含买家付款这一个业务过程的 “单事务事实表”；如，选择了所有 4 个业务过程，并且需要分享各业务过程的时间间隔，则事实表类型应为包含了所有 4 个业务过程的 “累积快照事实表”； 第二步：声明粒度
粒度的作用：
粒度的声明，意味着精确定义事实表的每一行所表示的业务含义；明确的粒度能够确保对实表中行的意思的理解不会产生混淆，保证所有的事实按照同样的细节层次记录；粒度的选择：尽量选择最细级别的原子粒度，以确保事实表的应用具有最大的灵活性；
灵活性：支持无法预期的各种细节层次的用户需求；对于订单级别，粒度可以定义为最细的订单级别；（如，父子订单，事实表的粒度可以定 “子订单级别” ；） 第三步：确定维度
完成了粒度声明，就意味着确定了主键，对应的维度组合以及相关的维度字段也可以确定了；选择维度的原则：应该选择能够描述清楚业务过程所处的环境的维度信息；
如，淘宝订单 “付款事务事实表” 中，粒度为 “子订单”，相关的维度有买家、卖家、商品、收货人信息、业务类型、订单时间等； 第四步：确定事实
确定原则：选择与业务过程有关的所有事实，且事实的粒度要与所声明的事实表的粒度一致；思路：可以通过回答 “过程的度量是什么” 来确定；注意：将不可加性事实分解为可加的组件；（分解的原则：可以通过分解后的可加的属性值，计算得到不可加性事实）
汇总图： 参考文献：阿里巴巴大数据之路
整理不易，点个赞吧~ |
【本文地址】