然而在无事实的事实表中没有这些度量值，只有多个维度外键。表面上看，无事实事实表是没有意义的，因为作为事实表，毕竟最重要的就是度量。但在数据仓库中，这类事实表有其特殊用途。...促销无事实的事实表包含多个维度的主键，可以是日期、产品、商店、促销等，将这些键作为促销商品的属性是不合适的，因为每个维度都有自己的属性集合。 促销无事实事实表看起来与销售事实表相似。...下面以销售订单数据仓库为例，说明如何处理源数据中没有度量的需求。建立一个无事实的事实表，用来统计每天发布的新产品数量。...产品源数据不包含产品数量信息，如果系统需要得到历史某一天新增产品的数量，很显然不能简单地从数据仓库中得到。这时就要用到无事实的事实表技术。使用此技术可以通过持续跟踪产品发布事件来计算产品的数量。...这里定义的新增产品是指在某一给定日期，源产品表中新插入的产品记录，不包括由于SCD2新增的产品版本记录。注意，单从这个简单需求来看，也可以通过查询产品维度表获取结果。
事实表与维度表 前文介绍了一维表和二维表的异同及相互转换 今天再来解释一下事实表与维度表 先来看下表。回忆下，这是一维表二维表？...单行记录就能锁定全部信息，个别列存在数量重复，没二话，显然是一维表 那是不是结账系统里的订单表就是这副样子？...这里只是打个花式比喻，不必较真） 上图可见，流水表里把大量汉字换成字母/数字编码，将对表格大小起到重要作用 修改信息时也只要在维度表定位、变更一条记录即可，而不必在流水表里进行全表扫描。...，那“事实表”也就不难理解了 事实表：表格里存储了能体现实际数据或详细数值，一般由维度编码和事实数据组成 维度表：表格里存放了具有独立属性和层次结构的数据，一般由维度编码和对应的维度说明(标签)组成 现实工作中...，都可以作为维度来拓展 没有通吃全行业的套路，一个行业 一套章法，沉浸于自己熟悉的业务领域，多学多练多交流
KDT#13 可以作为维度表使用的事实表 事实表从粒度的角度分为三种，分别是交易粒度事实表、周期快照事实表和累计快照事实表。 交易粒度事实表能提供某个确切时刻的描述信息。...这是一个典型的记录的度量事实都是文本型描述信息的事实表。这样的事实表和维度表之间的区别并不明显。 这个事实表中有三个是关联到普通维度表的外键，分别是变更日期、代理和交易类型。...帐户号（SK）是帐户的代理键，也是这个事实表的主键，它标识了这个事实表中的每一次变化。 我们可以将该事实表中的帐户号代理键做TYPE 2型缓慢变化维处理，并将它关联到其他事实表作为外键。...） 对后一个事实表进行分析，其中的一条记录可以准确的对应到前一张事实表中相应时点的帐号信息上，即我们可以得到每一次交易时点时帐户对应的客户信息。...我们会发现，前一张事实表和维度表并没有什么差别。
无事实的事实表 本篇讨论一种技术，用来处理源数据中没有度量的需求。例如，产品源数据不包含产品数量信息，如果系统需要得到产品的数量，很显然不能简单地从数据仓库中直接得到。...这时就要用到无事实的事实表技术。使用此技术可以通过持续跟踪产品的发布来计算产品的数量。可以创建一个只有产品（计什么数）和日期（什么时候计数）维度代理键的事实表。...之所以叫做无事实的事实表是因为表本身并没有度量。 ...产品发布的无事实事实表 本节说明如何实现一个产品发布的无事实事实表，包括新增和初始装载product_count_fact表。...使用下面的语句查询product_count_fact表以确认正确执行了初始装载，查询语句和结果显示如下。
事实表是维度建模的核心表和基本表。 它存储了业务过程中的各种度量和事实，而这些度量和事实正是下游数据使用人员所要关心和分析的对象。...目前事实表主要探讨三种： 事务事实表 快照事实表 累计快照事实表 还有一种特殊的事实表——无事实的事实表，最后还将讨论事实表的聚集和汇总。...事务事实表 事务事实表是维度建模事实表中最为常见、使用最为广泛的事实表。 事务事实表通常用于记录业务过程的事件，而且是原子粒度的事件。...但是实际上，商品的成本价是确定的，因此可以很容易地确定商品的销售毛利：（商品实际销售价格－商品成本价） 销售数量，基于下游使用便利这一因素，也应该将此放人事务事实表中。...，这样下游使用更为直接和便捷，不需要每次都关联相关维度表获取有关维度属性 也就是说，以存储的冗余为代价，换来了下游的使用便捷以及多次关联计算开销，而在大数据时代，这是完全划算的。
实际装载时，月销售周期快照事实表的数据源是已有的销售订单事务事实表，而并没有关联产品维度表。...添加id自增字段作为销售订单表的主键，它是表中的第一个字段。 依据源数据库事务表的结构，执行下面的脚本修改Hive中相应的过渡区表。...（11）在源数据库中插入数据作为这两个订单后面的里程碑：打包、配送和收货。注意四个状态日期可能相同。...转换中使用的流查询步骤支持从各种数据源和其它步骤查询数据，但只允许做等值查询。...在一些场景下，如维度数据和事实数据能同时准备好，先使用“表输入”步骤获取每个业务键最后一个版本的维度数据，然后再用“流查询”步骤把“表输入”步骤的结果作为输入，是查询大型维度表的最快方式。
当同时拥有事实记录和正确的当前维度行时，就能够从容地首先维护维度键，然后在对应的事实表行中使用这些最新的键。然而，各种各样的原因会导致需要ETL系统处理迟到的事实数据。...再或者出现某些极端情况，如源数据库系统出现故障，直到恢复后才能补上故障期间产生的数据。 在销售订单示例中，晚于订单日期进入源数据的销售订单可以看做是一个迟到事实的例子。...因此为了确定事实表中的一条销售订单记录是否是迟到的，需要把源数据中的登记日期列装载进销售订单事实表。为此在要销售订单事实表上添加登记日期代理键列。...为了获取登记日期代理键的值，还要使用维度角色扮演技术添加登记日期维度表。 ...注意sales_order源数据表及其对应的过渡表中都已经含有登记日期，只是以前没有将其装载进数据仓库。
事实表 每个数据仓库都包含一个或者多个事实数据表。事实数据表可能包含业务销售数据，如现金登记事务所产生的数据，事实数据表通常包含大量的行。...事实数据表的主要特点是包含数字数据（事实），并且这些数字信息可以汇总，以提供有关单位作为历史的数据，每个事实数据表包含一个由多个部分组成的索引，该索引包含作为外键的相关性纬度表的主键，而维度表包含事实记录的特性...一般来说，一个事实数据表都要和一个或多个纬度表相关联，用户在利用事实数据表创建多维数据集时，可以使用一个或多个维度表。...维度表 维度表可以看作是用户来分析数据的窗口，纬度表中包含事实数据表中事实记录的特性，有些特性提供描述性信息，有些特性指定如何汇总事实数据表数据，以便为分析者提供有用的信息，维度表包含帮助汇总数据的特性的层次结构...事实表就是销量表，维度表就是地区表。
事实表：每个数据仓库都包含一个或者多个事实数据表。事实数据表可能包含业务销售数据，如销售商品所产生的数据，与软件中实际表概念一样 维度：说明数据，维度是指可指定不同值的对象的描述性属性或特征。...维度和指标的关系：虽然维度和指标可以独立使用，但常见的还是相互结合使用。维度和指标的值以及这些值之间的关系，使您的数据具有了意义。为了挖掘尽可能多的深层次信息，维度通常与一个或多个指标关联在一起。...度量：事实表和维度交叉汇聚的点，度量和维度构成OLAP的主要概念，这里面对于在事实表或者一个多维立方体里面存放的数值型的、连续的字段，就是度量。
事实数据表的主要特点是包含数字数据（事实），并且这些数字信息可以汇总，以提供有关单位作为历史的数据，每个事实数据表包含一个由多个部分组成的索引，该索引包含作为外键的相关性维度表的主键，而维度表包含事实记录的特性...一、事实表基础 1. 事实表特征 事实表作为数仓维度建模的核心，紧紧围绕着业务过程来设计，通过获取描述业务过程的度量来表达业务过程，包含了引用的维度和业务过程有关的度量。...作为度量业务过程的事实（事实表属性），一般为整型或浮点型的十进制数值，有可加性、半可加性和不可加性三种类型： 可加性事实 是指可以按照与事实表关联的任意维度进行汇总。...在同一个事实表中不能有多种不同粒度的事实； 事实的单位要保持一致； 对事实的 null 值要处理；在数据库中null值对常用的大于或小于等SQL不生效，建议使用零值填充 使用退化维度提高事实表的易用性...使用业务过程的第一次发生日期还是最近发生日期，根据用户决定。 多源过程 针对多源业务建模，主要考虑事实表的粒度问题。
所谓的事实表和维度表技术，指的就是如何和构造一张事实表和维度表，是的事实表和维度表，可以涵盖现在目前的需要和方便后续下游数据应用的开发。 事实表，就是一个事实的集合。...简单的，我们可以大概分为事务事实表，周期快照事实表，累计快照事实表，无事实的事实表。事务事实表：事务事实表的一行对应空间或者时间上某点的度量事件。即流水行数据。...维度表的主键可以作为与之关联的任何事实表的外键，当然，维度表行的描述环境与事实表行完全对应。 维度表开发过程中有下面几个点。...维度代理键，维度表中会包含一个列，表示唯一主键，该主键不是操作型系统的自然键，如果采用自然键，需要多个维度行表示，另外，维度的自然键可能由多个源系统建立，这些自然键可能会出现兼容性问题。...所以这里可以对代理键做一些处理，具体可以看业务形态，如果源系统已经保证了唯一，直接应用也是没有问题的。
实际装载时，月销售周期快照事实表的数据源是已有的销售订单事务事实表，而并没有关联产品维度表。...rds.sales_order并没有增加id列，原因有两个：一是该列只作为MySQL源表中的自增主键，不用在目标同步表中存储；二是不需要再重新导入已有数据。...注意，本示例中的累积周期快照表仍然是以订单号字段作为主键。数据装载过程实际上是做了一个行转列的操作，用源数据表中的状态行信息更新累积快照的状态列。 5....然而在无事实的事实表中没有这些度量值，只有多个维度外键。表面上看，无事实事实表是没有意义的，因为作为事实表，毕竟最重要的就是度量。但在数据仓库中，这类事实表有其特殊用途。...产品源数据不包含产品数量信息，如果系统需要得到历史某一天新增产品的数量，很显然不能简单地从数据仓库中得到。这时就要用到无事实的事实表技术。使用此技术可以通过持续跟踪产品发布事件来计算产品的数量。
一、建立累积度量事实表 执行下面的脚本创建month_end_balance_fact事实表，用来存储销售订单金额和数量的月累积值。...(10,2), month_end_quantity_balance int ); comment on table month_end_balance_fact is '累积度量事实表...select fn_month_sum(201706); 执行累积度量定期装载脚本，以shell命令`date +%Y%m`的输出作为年月参数传入month_balance_sum.sql...五、查询 事实表中的数字度量值可划分为可加、半可加、不可加三类。可加性度量可以按照与事实表关联的任意维度汇总，就是说按任何维度汇总得到的度量和是相同的，事实表中的大部分度量属于此类。...如果重点考虑迟到事实数据和HAWQ无法行级更新的限制，也许使用查询视图方式实现累积度量是更佳选择。
一、前言 本文是《分布式数据仓库最佳实践》系列文章的第四部分第21篇《事实表设计》，针对事实表设计专题进行详细论述，内容包括事实表的类型划分，各种类型的事实表应用的场景、具有的特性和典型的案例。...2.2 事实表设计详解 首先，明确第一个问题：事实表是分类型的，既包括包含明确可度量指标的事实表，如订单事件；也包括没有明确的可度量数值的事实表，如网民的对网站的一次访问。...其次，对于包含事实的事实表，也可以根据事实表本身的特性，进行类型划分，具体而言就包括：事务型事实表、周期快照事实表和累积快照事实表。其各自使用的场景、具备的特性和典型案例如上图所示。...再次，事实表的设计，要基于自己业务特性和场景特点进行模型的选择，以使用为准，同时选择了某种事实表以后，伴随的问题就是要接受其固有特性。...三、未完待续 本文是《分布式数据仓库最佳实践》系列文章的第四部分第21篇《事实表设计》，针对事实表设计专题进行详细论述，内容包括事实表的类型划分，各种类型的事实表应用的场景、具有的特性和典型的案例。
这种对累积快照事实表行的一致性修改在三种类型的事实表（事务、周期快照、累积快照）中具有独特性，对于前面两类事实表只追加数据，不会对已经存在的行进行更新操作。...这五个里程碑的日期及其各自的数量来自源数据库的销售订单表。...修改源库表结构 执行下面的脚本将源数据库中销售订单事务表结构做相应改变，以处理五种不同的状态。...新增id字段作为销售订单表的主键，它是表中的第一个字段。 2. 重建销售订单外部表 执行下面的语句重建销售订单外部表，使其与源表结构一致。...三、重建增量抽取Sqoop作业 使用下面的脚本重建Sqoop作业，因为源表会有多个相同的order_number，所以不能再用它作为检查字段，将检查字段改为id。
周期快照事实表通常包含许多数据的总计，因为任何与事实表时间范围一致的记录都会被包含在内。...因此，好的做法是将事务型事实表作为一个基石事实数据，以此为基础，向上逐层建立需要的快照事实表。 ...实际装载时，月销售周期快照事实表的数据源是已有的销售订单事务事实表，而不需要关联产品维度表。...之所以可以这样做，是因为总是先处理事务事实表，再处理周期快照事实表，并且事务事实表中的产品代理键就是当时有效的产品描述。...* 100 + extract(month from current_date - interval '1 month') as int)); 周期快照表的外键密度是均匀的，因此这里使用外连接关联月份维度和事务事实表
二、事实表设计基础 事实表记录发生在现实世界中的操作型事件，其所产生的可度数值。事实表的设计完全依赖于物理活动，不受可能产生的最终报表的影响。...事实表中，除数字度量外，事实表总是包含外键，用于关联与之相关的维度，也可以包含退化的维度键和日期/时间戳。...三、分布式模式-维度建模新原则 （1）以值代键：针对键值唯一的维表，除非必要，否则不引入维表，如IP地址维表，采用IP作为维表的主键，事实表中存储IP值； （2）合理分表：传统关系型数据仓库存在多表整合的冲动...，如上图Event事实表，各种Acount Ind，Finance Ind等，用来扩展表的通用性，试图把所有的数据都存储到一张表 中。...分布式数据仓库的设计，恰恰相反，因为单表数据规模的问题，如果要满足分析和处理的性能，合理的按照业务进行数据的分表存储。如财务相关事件、账户相关事件，单独成表。更有利于数据的计算和分析。
目录 1、三种事实表概述 2、三种事实表对比 3、事实表设计 8 大原则 4、事实表设计方法 第一步：选择业务过程及确定事实表类型 第二步：声明粒度 第三步：确定维度 第四步：确定事实 ---- 事实表作为数据仓库维度建模的核心...粒度是一个订单一行数据，创建订单时间，付款时间，发货时间，收货时间，分别作为一个字段，便于计算不同业务过程的时间间隔。...3 个事实，应该采用统一的计量单位，统一为元或者分，以方便使用； 原则 7：对事实的 null 值要处理 原因：在数据库中，null 值对常用数字型字段的 SQL 过滤条件都不生效；如，大于、小于、...等于、大于或等于、小于或等于； 处理：用 0 代替 null ； 原则 8：使用退化维度提高事实表的易用性 事实表中存储各种类型的常用维度信息，较少下游用户使用时关联多个表的操作； 通过退化维度，可以实现对事实表的过滤查询...，这种方式来获取维度，谨慎使用退化维表；这与大数据领域的事实表设计不一样； 思路：通过增加冗余存储，减少计算开销，提高使用效率； 4、事实表设计方法 Kimball 的维度模型设计 4 步法：选择业务过程
背景 数据同步方式 事实表类型及使用场景 事实表设计合并依据 总结 背景 在构建数据仓库总线矩阵完成后，可着手事实表和维度表的设计。...同时，因上游业务系统老旧，表设计水平、使用场景等因素，或并不是都是标准3NF范式设计，将多个业务过程事件发生存储在一张表的情况，对于此种情况做事实表设计时，根据使用场景可能会进行表拆分考虑，这里不再展开...多个业务过程是否放到同一个事实表中,首先需要分析不同业务过程之间的相似性和业务源系统。...事实表设计是需识别业务过程、探查数据粒度、维度、事实等几个步骤，再根据数据粒度，数据更新方式、数据量大小和使用场景等因素判断是否进行多业务过程或表进行合并，再选择合适的事实表类型进行模型设计。...事实表类型及使用场景 事实表类型蛮多的可根据数据粒度更新方式或使用场景进行合理使用，在模型实际设计过程中，有的无相关使用场景或有的在平常已经在使用了这些事实表类型，但也不清楚是哪类事实表
而订单支付金额和订单票数作为上 层粒度的订单级事实，与该票级事实表的粒度不一致，且不能进行汇总。...比如订单 ID100901 的订单支付金额为 3700 元，订单票数为 张，如果这两个度量在该表进行汇总计算总订单金额和总票数，则会造成重复计算的问题所以不能作为该表的度量选人。...原则六 ：事实的单位要保持一致 对于同个事实表中事实的单位，应该保持一致。比如原订单金额、订单优惠金额、订单运费金额这三个事实，应该采用一致的计量单位，为元或分，以方便使用。...原则八 ：使用退化维度提高事实表的易用性 Kimbal 维度建模中，通常按照星形模型的方式来设计，对于维度的获取采用的是通过事实表的外键关联专门的维表的方式，谨慎使用退化维度。...这样设计的目的主要是为了减少下游用户使用时关联多个表的操作，直接通过退化维度实现对事实表的过滤查询、控制聚合层次、排序数据以及定义主从关系等。通过增加冗余存储的方式减少计算开销，提高使用效率。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
即时通信 IM
对象存储
