首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

使用Factless事实表作为事实表源

Factless事实表是一种在数据仓库中使用的事实表类型,它包含了没有事实度度量的事实表。事实表是数据仓库中存储度量数据的主要表,它通常包含数值型数据,并且可以被用于数据分析和报表生成。

Factless事实表的设计思路是将某些情况下的事实数据存储在没有度量的事实表中,以便捕捉和跟踪某些事实之间的关联关系,而不考虑具体的度量值。它可以用于记录事实发生的时间、地点、对象或其他特定的属性,以支持跨多个维度的分析和查询。

Factless事实表的优势主要体现在以下几个方面:

  1. 灵活性:Factless事实表可以灵活地捕捉各种事实之间的关联关系,而不仅仅局限于数值型度量数据。
  2. 扩展性:通过使用Factless事实表,可以方便地扩展数据仓库的模型,满足新的分析需求,而无需对已有的度量数据进行修改。
  3. 可解释性:Factless事实表可以用于存储一些关键性质的数据,例如事件发生的时间、地点等,这些属性可以帮助分析人员理解数据背后的具体情境。

应用场景: Factless事实表适用于一些没有明显度量值的分析需求,例如:

  1. 事件跟踪:当需要跟踪不同类型事件之间的关联关系时,可以使用Factless事实表来记录事件的发生时间、地点等属性。
  2. 多对多关系:当需要分析多个实体之间的多对多关系时,可以使用Factless事实表来记录关联关系的发生情况。
  3. 事务分析:当需要进行事务分析,例如检测异常行为或者分析业务流程时,可以使用Factless事实表来记录事务发生的轨迹。

推荐的腾讯云相关产品: 在腾讯云上,可以使用以下产品来支持Factless事实表的存储和分析:

  1. 腾讯云数据仓库:提供灵活的数据仓库解决方案,支持对Factless事实表的存储和查询。
  2. 腾讯云分析型数据库(TDSQL):提供高性能的在线分析处理(OLAP)能力,支持对Factless事实表的复杂查询和分析。
  3. 腾讯云云原生数据库TBase:具备弹性伸缩和高可用性的分布式数据库,可以支持大规模数据存储和查询。

更多腾讯云产品信息,请参考:腾讯云产品与服务

页面内容是否对你有帮助?
有帮助
没帮助

相关·内容

HAWQ取代传统数仓实践(十五)——事实技术之无事实事实

然而在无事实事实中没有这些度量值,只有多个维度外键。表面上看,无事实事实是没有意义的,因为作为事实,毕竟最重要的就是度量。但在数据仓库中,这类事实有其特殊用途。...促销无事实事实包含多个维度的主键,可以是日期、产品、商店、促销等,将这些键作为促销商品的属性是不合适的,因为每个维度都有自己的属性集合。 促销无事实事实看起来与销售事实表相似。...下面以销售订单数据仓库为例,说明如何处理数据中没有度量的需求。建立一个无事实事实,用来统计每天发布的新产品数量。...产品数据不包含产品数量信息,如果系统需要得到历史某一天新增产品的数量,很显然不能简单地从数据仓库中得到。这时就要用到无事实事实技术。使用此技术可以通过持续跟踪产品发布事件来计算产品的数量。...这里定义的新增产品是指在某一给定日期,产品中新插入的产品记录,不包括由于SCD2新增的产品版本记录。注意,单从这个简单需求来看,也可以通过查询产品维度获取结果。

96770

事实与维度

事实与维度 前文介绍了一维和二维的异同及相互转换 今天再来解释一下事实与维度 先来看下表。回忆下,这是一维二维?...单行记录就能锁定全部信息,个别列存在数量重复,没二话,显然是一维 那是不是结账系统里的订单就是这副样子?...这里只是打个花式比喻,不必较真) 上图可见,流水表里把大量汉字换成字母/数字编码,将对表格大小起到重要作用 修改信息时也只要在维度定位、变更一条记录即可,而不必在流水表里进行全扫描。...,那“事实”也就不难理解了 事实:表格里存储了能体现实际数据或详细数值,一般由维度编码和事实数据组成 维度:表格里存放了具有独立属性和层次结构的数据,一般由维度编码和对应的维度说明(标签)组成 现实工作中...,都可以作为维度来拓展 没有通吃全行业的套路,一个行业 一套章法,沉浸于自己熟悉的业务领域,多学多练多交流

2.2K40
  • 数据仓库专题(11)-可以作为维度使用事实

    KDT#13 可以作为维度使用事实 事实从粒度的角度分为三种,分别是交易粒度事实、周期快照事实和累计快照事实。 交易粒度事实能提供某个确切时刻的描述信息。...这是一个典型的记录的度量事实都是文本型描述信息的事实。这样的事实和维度之间的区别并不明显。 这个事实中有三个是关联到普通维度的外键,分别是变更日期、代理和交易类型。...帐户号(SK)是帐户的代理键,也是这个事实的主键,它标识了这个事实中的每一次变化。 我们可以将该事实中的帐户号代理键做TYPE 2型缓慢变化维处理,并将它关联到其他事实作为外键。...) 对后一个事实进行分析,其中的一条记录可以准确的对应到前一张事实中相应时点的帐号信息上,即我们可以得到每一次交易时点时帐户对应的客户信息。...我们会发现,前一张事实和维度并没有什么差别。

    96320

    维度模型数据仓库(十七) —— 无事实事实

    事实事实         本篇讨论一种技术,用来处理数据中没有度量的需求。例如,产品数据不包含产品数量信息,如果系统需要得到产品的数量,很显然不能简单地从数据仓库中直接得到。...这时就要用到无事实事实技术。使用此技术可以通过持续跟踪产品的发布来计算产品的数量。可以创建一个只有产品(计什么数)和日期(什么时候计数)维度代理键的事实。...之所以叫做无事实事实是因为本身并没有度量。        ...产品发布的无事实事实  本节说明如何实现一个产品发布的无事实事实,包括新增和初始装载product_count_fact。...使用下面的语句查询product_count_fact以确认正确执行了初始装载,查询语句和结果显示如下。

    86810

    维度建模技术实践——深入事实

    事实是维度建模的核心和基本。 它存储了业务过程中的各种度量和事实,而这些度量和事实正是下游数据使用人员所要关心和分析的对象。...目前事实主要探讨三种: 事务事实 快照事实 累计快照事实 还有一种特殊的事实——无事实事实,最后还将讨论事实的聚集和汇总。...事务事实 事务事实是维度建模事实中最为常见、使用最为广泛的事实。 事务事实通常用于记录业务过程的事件,而且是原子粒度的事件。...但是实际上,商品的成本价是确定的,因此可以很容易地确定商品的销售毛利:(商品实际销售价格-商品成本价) 销售数量,基于下游使用便利这一因素,也应该将此放人事务事实中。...,这样下游使用更为直接和便捷,不需要每次都关联相关维度获取有关维度属性 也就是说,以存储的冗余为代价,换来了下游的使用便捷以及多次关联计算开销,而在大数据时代,这是完全划算的。

    1.6K20

    Kettle构建Hadoop ETL实践(九):事实技术

    实际装载时,月销售周期快照事实的数据是已有的销售订单事务事实,而并没有关联产品维度。...添加id自增字段作为销售订单的主键,它是中的第一个字段。 依据数据库事务的结构,执行下面的脚本修改Hive中相应的过渡区。...(11)在数据库中插入数据作为这两个订单后面的里程碑:打包、配送和收货。注意四个状态日期可能相同。...转换中使用的流查询步骤支持从各种数据和其它步骤查询数据,但只允许做等值查询。...在一些场景下,如维度数据和事实数据能同时准备好,先使用输入”步骤获取每个业务键最后一个版本的维度数据,然后再用“流查询”步骤把“输入”步骤的结果作为输入,是查询大型维度的最快方式。

    5.9K12

    HAWQ取代传统数仓实践(十六)——事实技术之迟到的事实

    当同时拥有事实记录和正确的当前维度行时,就能够从容地首先维护维度键,然后在对应的事实行中使用这些最新的键。然而,各种各样的原因会导致需要ETL系统处理迟到的事实数据。...再或者出现某些极端情况,如数据库系统出现故障,直到恢复后才能补上故障期间产生的数据。         在销售订单示例中,晚于订单日期进入数据的销售订单可以看做是一个迟到事实的例子。...因此为了确定事实中的一条销售订单记录是否是迟到的,需要把数据中的登记日期列装载进销售订单事实。为此在要销售订单事实上添加登记日期代理键列。...为了获取登记日期代理键的值,还要使用维度角色扮演技术添加登记日期维度。        ...注意sales_order数据及其对应的过渡中都已经含有登记日期,只是以前没有将其装载进数据仓库。

    1.4K80

    数据仓库中的维度事实概述

    事实 每个数据仓库都包含一个或者多个事实数据事实数据可能包含业务销售数据,如现金登记事务所产生的数据,事实数据通常包含大量的行。...事实数据的主要特点是包含数字数据(事实),并且这些数字信息可以汇总,以提供有关单位作为历史的数据,每个事实数据包含一个由多个部分组成的索引,该索引包含作为外键的相关性纬度的主键,而维度包含事实记录的特性...一般来说,一个事实数据都要和一个或多个纬度表相关联,用户在利用事实数据创建多维数据集时,可以使用一个或多个维度。...维度 维度可以看作是用户来分析数据的窗口,纬度中包含事实数据事实记录的特性,有些特性提供描述性信息,有些特性指定如何汇总事实数据数据,以便为分析者提供有用的信息,维度包含帮助汇总数据的特性的层次结构...事实就是销量表,维度就是地区

    4.7K30

    事实,维度,度量,指标之间的关系

    事实:每个数据仓库都包含一个或者多个事实数据事实数据可能包含业务销售数据,如销售商品所产生的数据,与软件中实际概念一样 维度:说明数据,维度是指可指定不同值的对象的描述性属性或特征。...维度和指标的关系:虽然维度和指标可以独立使用,但常见的还是相互结合使用。维度和指标的值以及这些值之间的关系,使您的数据具有了意义。为了挖掘尽可能多的深层次信息,维度通常与一个或多个指标关联在一起。...度量:事实和维度交叉汇聚的点,度量和维度构成OLAP的主要概念,这里面对于在事实或者一个多维立方体里面存放的数值型的、连续的字段,就是度量。

    2.4K10

    数据仓库:详解维度建模之事实

    事实数据的主要特点是包含数字数据(事实),并且这些数字信息可以汇总,以提供有关单位作为历史的数据,每个事实数据包含一个由多个部分组成的索引,该索引包含作为外键的相关性维度的主键,而维度包含事实记录的特性...一、事实基础 1. 事实特征 事实作为数仓维度建模的核心,紧紧围绕着业务过程来设计,通过获取描述业务过程的度量来表达业务过程,包含了引用的维度和业务过程有关的度量。...作为度量业务过程的事实事实属性),一般为整型或浮点型的十进制数值,有可加性、半可加性和不可加性三种类型: 可加性事实 是指可以按照与事实关联的任意维度进行汇总。...在同一个事实中不能有多种不同粒度的事实事实的单位要保持一致; 对事实的 null 值要处理;在数据库中null值对常用的大于或小于等SQL不生效,建议使用零值填充 使用退化维度提高事实的易用性...使用业务过程的第一次发生日期还是最近发生日期,根据用户决定。 多过程 针对多业务建模,主要考虑事实的粒度问题。

    2.5K10

    数仓基础(三):维度建模理论之事实

    维度建模理论之事实一、事实概述事实作为数据仓库维度建模的核心,紧紧围绕着业务过程来设计。其包含与该业务过程有关的维度引用(维度外键)以及该业务过程的度量(通常是可累加的数字类型字段)。...此处以电商中的虚拟货币为例,虚拟货币业务包含的业务过程主要包括获取货币和使用货币,两个业务过程各自对应一张事务型事实,一张存储所有的获取货币的原子操作事件,另一张存储所有使用货币的原子操作事件。...由于获取货币和使用货币均会影响到余额,故需要对两张事务型事实进行聚合,且需要区分两者对余额的影响(加或减),另外需要对两张的全数据聚合才能得到统计结果。...对于空气温度、行驶速度这些状态型指标,由于它们的值往往是连续的,我们无法捕获其变动的原子事务操作,所以无法使用事务型事实统计此类需求。而只能定期对其进行采样,构建周期型快照事实。...例如前文提到的用户下单到支付的平均时间间隔,使用累积型快照事实进行统计,就能避免两个事务事实的关联操作,从而变得十分简单高效。

    11310

    数据仓库(08)数仓事实和维度技术

    所谓的事实和维度技术,指的就是如何和构造一张事实和维度,是的事实和维度,可以涵盖现在目前的需要和方便后续下游数据应用的开发。 事实,就是一个事实的集合。...简单的,我们可以大概分为事务事实,周期快照事实,累计快照事实,无事实事实。事务事实:事务事实的一行对应空间或者时间上某点的度量事件。即流水行数据。...维度的主键可以作为与之关联的任何事实的外键,当然,维度行的描述环境与事实行完全对应。 维度开发过程中有下面几个点。...维度代理键,维度中会包含一个列,表示唯一主键,该主键不是操作型系统的自然键,如果采用自然键,需要多个维度行表示,另外,维度的自然键可能由多个系统建立,这些自然键可能会出现兼容性问题。...所以这里可以对代理键做一些处理,具体可以看业务形态,如果系统已经保证了唯一,直接应用也是没有问题的。

    1K10

    Greenplum 实时数据仓库实践(8)——事实技术

    实际装载时,月销售周期快照事实的数据是已有的销售订单事务事实,而并没有关联产品维度。...rds.sales_order并没有增加id列,原因有两个:一是该列只作为MySQL中的自增主键,不用在目标同步中存储;二是不需要再重新导入已有数据。...注意,本示例中的累积周期快照表仍然是以订单号字段作为主键。数据装载过程实际上是做了一个行转列的操作,用数据中的状态行信息更新累积快照的状态列。 5....然而在无事实事实中没有这些度量值,只有多个维度外键。表面上看,无事实事实是没有意义的,因为作为事实,毕竟最重要的就是度量。但在数据仓库中,这类事实有其特殊用途。...产品数据不包含产品数量信息,如果系统需要得到历史某一天新增产品的数量,很显然不能简单地从数据仓库中得到。这时就要用到无事实事实技术。使用此技术可以通过持续跟踪产品发布事件来计算产品的数量。

    1.6K11

    HAWQ取代传统数仓实践(十七)——事实技术之累积度量

    一、建立累积度量事实         执行下面的脚本创建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无法行级更新的限制,也许使用查询视图方式实现累积度量是更佳选择。

    856100

    分布式数据仓库最佳实践(21)- 事实设计

    一、前言 本文是《分布式数据仓库最佳实践》系列文章的第四部分第21篇《事实设计》,针对事实设计专题进行详细论述,内容包括事实的类型划分,各种类型的事实应用的场景、具有的特性和典型的案例。...2.2 事实设计详解 首先,明确第一个问题:事实是分类型的,既包括包含明确可度量指标的事实,如订单事件;也包括没有明确的可度量数值的事实,如网民的对网站的一次访问。...其次,对于包含事实事实,也可以根据事实本身的特性,进行类型划分,具体而言就包括:事务型事实、周期快照事实和累积快照事实。其各自使用的场景、具备的特性和典型案例如上图所示。...再次,事实的设计,要基于自己业务特性和场景特点进行模型的选择,以使用为准,同时选择了某种事实以后,伴随的问题就是要接受其固有特性。...三、未完待续 本文是《分布式数据仓库最佳实践》系列文章的第四部分第21篇《事实设计》,针对事实设计专题进行详细论述,内容包括事实的类型划分,各种类型的事实应用的场景、具有的特性和典型的案例。

    95130

    HAWQ取代传统数仓实践(十三)——事实技术之周期快照

    周期快照事实通常包含许多数据的总计,因为任何与事实时间范围一致的记录都会被包含在内。...因此,好的做法是将事务型事实作为一个基石事实数据,以此为基础,向上逐层建立需要的快照事实。        ...实际装载时,月销售周期快照事实的数据是已有的销售订单事务事实,而不需要关联产品维度。...之所以可以这样做,是因为总是先处理事务事实,再处理周期快照事实,并且事务事实中的产品代理键就是当时有效的产品描述。...* 100 + extract(month from current_date - interval '1 month') as int));         周期快照表的外键密度是均匀的,因此这里使用外连接关联月份维度和事务事实

    1.8K80

    HAWQ取代传统数仓实践(十四)——事实技术之累积快照

    这种对累积快照事实行的一致性修改在三种类型的事实(事务、周期快照、累积快照)中具有独特性,对于前面两类事实只追加数据,不会对已经存在的行进行更新操作。...这五个里程碑的日期及其各自的数量来自数据库的销售订单。...修改结构         执行下面的脚本将数据库中销售订单事务结构做相应改变,以处理五种不同的状态。...新增id字段作为销售订单的主键,它是中的第一个字段。 2. 重建销售订单外部         执行下面的语句重建销售订单外部,使其与结构一致。...三、重建增量抽取Sqoop作业         使用下面的脚本重建Sqoop作业,因为会有多个相同的order_number,所以不能再用它作为检查字段,将检查字段改为id。

    2K60

    数据仓库专题(3)-分布式数据仓库事实设计思考

    二、事实设计基础       事实表记录发生在现实世界中的操作型事件,其所产生的可度数值。事实的设计完全依赖于物理活动,不受可能产生的最终报表的影响。...事实中,除数字度量外,事实总是包含外键,用于关联与之相关的维度,也可以包含退化的维度键和日期/时间戳。...三、分布式模式-维度建模新原则 (1)以值代键:针对键值唯一的维,除非必要,否则不引入维,如IP地址维,采用IP作为的主键,事实中存储IP值;       (2)合理分:传统关系型数据仓库存在多表整合的冲动...,如上图Event事实,各种Acount Ind,Finance Ind等,用来扩展的通用性,试图把所有的数据都存储到一张 中。...分布式数据仓库的设计,恰恰相反,因为单数据规模的问题,如果要满足分析和处理的性能,合理的按照业务进行数据的分存储。如财务相关事件、账户相关事件,单独成。更有利于数据的计算和分析。

    96730

    一篇文章搞懂数据仓库:三种事实(设计原则,设计方法、对比)

    目录 1、三种事实概述 2、三种事实对比 3、事实设计 8 大原则 4、事实设计方法 第一步:选择业务过程及确定事实类型 第二步:声明粒度 第三步:确定维度 第四步:确定事实 ---- 事实作为数据仓库维度建模的核心...粒度是一个订单一行数据,创建订单时间,付款时间,发货时间,收货时间,分别作为一个字段,便于计算不同业务过程的时间间隔。...3 个事实,应该采用统一的计量单位,统一为元或者分,以方便使用; 原则 7:对事实的 null 值要处理 原因:在数据库中,null 值对常用数字型字段的 SQL 过滤条件都不生效;如,大于、小于、...等于、大于或等于、小于或等于; 处理:用 0 代替 null ; 原则 8:使用退化维度提高事实的易用性 事实中存储各种类型的常用维度信息,较少下游用户使用时关联多个的操作; 通过退化维度,可以实现对事实的过滤查询...,这种方式来获取维度,谨慎使用退化维;这与大数据领域的事实设计不一样; 思路:通过增加冗余存储,减少计算开销,提高使用效率; 4、事实设计方法 Kimball 的维度模型设计 4 步法:选择业务过程

    6K21

    数仓建模系列:关于事实设计,多业务过程要不要合并,依据啥?

    背景 数据同步方式 事实类型及使用场景 事实设计合并依据 总结 背景 在构建数据仓库总线矩阵完成后,可着手事实和维度的设计。...同时,因上游业务系统老旧,设计水平、使用场景等因素,或并不是都是标准3NF范式设计,将多个业务过程事件发生存储在一张的情况,对于此种情况做事实设计时,根据使用场景可能会进行拆分考虑,这里不再展开...多个业务过程是否放到同一个事实中,首先需要分析不同业务过程之间的相似性和业务系统。...事实设计是需识别业务过程、探查数据粒度、维度、事实等几个步骤,再根据数据粒度,数据更新方式、数据量大小和使用场景等因素判断是否进行多业务过程或进行合并,再选择合适的事实类型进行模型设计。...事实类型及使用场景 事实类型蛮多的可根据数据粒度更新方式或使用场景进行合理使用,在模型实际设计过程中,有的无相关使用场景或有的在平常已经在使用了这些事实类型,但也不清楚是哪类事实

    2K20
    领券