CN114595294B - 一种数据仓库建模和抽取方法及系统 - Google Patents

一种数据仓库建模和抽取方法及系统 Download PDF

Info

Publication number
CN114595294B
CN114595294B CN202210237026.2A CN202210237026A CN114595294B CN 114595294 B CN114595294 B CN 114595294B CN 202210237026 A CN202210237026 A CN 202210237026A CN 114595294 B CN114595294 B CN 114595294B
Authority
CN
China
Prior art keywords
dimension
data
database
fact
tables
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN202210237026.2A
Other languages
English (en)
Other versions
CN114595294A (zh
Inventor
杨万勇
杨耀庭
华健
张兵
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beijing Mengcheng Technology Co ltd
Original Assignee
Beijing Mengcheng Technology Co ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Beijing Mengcheng Technology Co ltd filed Critical Beijing Mengcheng Technology Co ltd
Priority to CN202210237026.2A priority Critical patent/CN114595294B/zh
Publication of CN114595294A publication Critical patent/CN114595294A/zh
Application granted granted Critical
Publication of CN114595294B publication Critical patent/CN114595294B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/28Databases characterised by their database models, e.g. relational or object models
    • G06F16/283Multi-dimensional databases or data warehouses, e.g. MOLAP or ROLAP
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24Querying
    • G06F16/242Query formulation
    • G06F16/2433Query languages
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/25Integrating or interfacing systems involving database management systems
    • G06F16/254Extract, transform and load [ETL] procedures, e.g. ETL data flows in data warehouses

Landscapes

  • Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Data Mining & Analysis (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Mathematical Physics (AREA)
  • Computational Linguistics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本发明提出一种数据仓库建模和抽取方法及系统。其中,方法包括:对具体的业务事实创建数据仓库的主题,然后根据所述主题生成一组维度表、事实表和汇聚表,再根据主题、维度表、事实表和汇聚表建立数据仓库;在数据仓库的存储上设计了两个数据库,一个是前台库,另外一个是后台库;所述前台库是所述数据仓库对外提供查询的数据库,所述后台库是所述数据仓库在执行数据抽取的库;ETL执行时,根据所述事实表和维度表的描述信息,生成对应的sql语句,在所述后台库上按租户启动抽取任务。本发明提出的方案,同以往相比大大缩短了开发周期,并且能支持客户个性化的配置。相比同类别更新周期最多不超过1小时,极大的提升了客户体验。

Description

一种数据仓库建模和抽取方法及系统
技术领域
本发明属于数据仓库领域,尤其涉及一种数据仓库建模和抽取方法及系统。
背景技术
ETL是数据抽取(Extract)、转换(Transform)、加载(Load)的简写,它是将OLTP系统中的数据经过抽取,并将不同数据源的数据进行转换、整合,得出一致性的数据,然后加载到数据仓库中。简而言之ETL是完成从OLTP系统到OLAP系统的过程
数据仓库的架构
数据仓库(Data Warehouse\DW)是基于OLTP系统的数据源,为了便于多维分析和多角度展现将其数据按特定的模式进行存储而建立的关系型数据库,它不同于多维数据库,数据仓库中的数据是细节的,集成的,数据仓库是面向主题的,是以OLAP系统为分析目的。它包括星型架构与雪花型架构,其中星型架构中间为事实表,四周为维度表,类似星星;雪花型架构中间为事实表,两边的维度表可以再有其关联子表,而在星型中只允许一张表作为维度表与事实表关联,雪花型一维度可以有多张表,而星型不可以。考虑到效率时,星型聚合快,效率高,不过雪花型结构明确,便于与OLTP系统交互。
ETL构建企业级数据仓库模型的步骤
1.确定主题
确定数据分析或前端展现的某一方面的分析主题,例如我们分析某年某月某一地区的啤酒销售情况,就是一个主题。主题要体现某一方面的各分析角度(维度)和统计数值型数据(量度),确定主题时要综合考虑,一个主题在数据仓库中即为一个数据集市,数据集市体现了某一方面的信息,多个数据集市构成了数据仓库。
2.确定量度
在确定了主题以后,我们将考虑要分析的技术指标,诸如年销售额此类,一般为数值型数据,或者将该数据汇总,或者将该数据取次数,独立次数或取最大最小值等,这样的数据称之为量度。量度是要统计的指标,必须事先选择恰当,基于不同的量度可以进行复杂关键性能指标(KPI)等的计算。
3.确定事实数据粒度
在确定了量度之后我们要考虑到该量度的汇总情况和不同维度下量度的聚合情况,考虑到量度的聚合程度不同,应该采用“最小粒度原则”,即将量度的粒度设置到最小,例如我们将按照时间对销售额进行汇总,目前的数据最小记录到天,即数据库中记录了每天的交易额,那么我们不能在ETL时将数据进行按月或年汇总,需要保持到天,以便于后续对天进行分析。
4.确定维度
维度是要分析的各个角度,例如我们希望按照时间,或者按照地区,或者按照产品进行分析,那么这里的时间、地区、产品就是相应的维度,基于不同的维度我们可以看到各量度的汇总情况,我们可以基于所有的维度进行交叉分析。
5.创建事实表
在确定好事实数据和维度后,就可以开始创建事实表。事实表就是原始数据,各种台账,交易生成的原始数据与维度表关联后产生所数据存储的表。事实数据表是数据仓库的核心,所有基于数仓的报表、BI分析查询都是基于事实表进行。为了优化性能,实际应用中还可以进一步从事实表定时生成物化的视图,加速查询过程。
ETL算法和工具
常用的ETL工具主要有三大主流工具,分别是Ascential公司的Datastage、Informatica公司的Powercenter、NCR Teradata公司的ETL Automation。还有其他开源工具,如PDI(Kettle)等。
ETL是DW系统的基础:
DW系统以事实发生数据为基础,自产数据较少。
一个企业往往包含多个业务系统,均可能成为DW数据源。
业务系统数据质量良莠不齐,必须学会去伪存真。
业务系统数据纷繁复杂,要整合进数据模型。
源数据之间关系也纷繁复杂,源数据在加工进DW系统时,有些必须遵照一定的先后次序关系。
源数据的分类:
流水事件表:此类源表用于记录交易等动作的发生,在源系统中会新增、大部分不会修改和删除,少量表存在删除情况。如定期存款登记簿。
常规状态表:此类源表用于记录数据信息的状态。在源系统中会新增、修改,也存在删除的情况。如客户信息表。
代码参数表:此类源表用于记录源系统中使用到的数据代码和参数。
数据文件的类型:
数据文件大多数以1天为固定的周期从源系统加载到数据仓库。数据文件包含增量,全量以及待删除的增量。
增量数据文件:数据文件的内容为数据表的增量信息,包含表内新增及修改的记录。
全量数据文件:数据文件的内容为数据表的全量信息,包含表内的所有数据。
带删除的增量:数据文件的内容为数据表的增量信息,包含表内新增、修改及删除的记录,通常删除的记录以字段DEL_IND='D'标识该记录。
ETL标准算法可划分为:历史拉链算法、追加算法(事件表)、Upsert算法(主表)及全删全加算法(参数表)。
ETL标准算法选择:
历史拉链:根据业务分析要求,对数据变化都要记录,需要基于日期的连续历史轨迹;
追加(事件表):根据业务分析要求,对数据变化都要记录,不需要基于日期的连续历史轨迹;
Upsert(主表):根据业务分析要求,对数据变化不需要都要记录,当前数据对历史数据有影响;
全删全加算法(参数表):根据业务分析要求,对数据变化不需要都要记录,当前数据对历史数据无影响。
现有技术的缺点:
行业内大多数数据仓库产品都集中在使用数据库仓库环节,也就是数据怎么抽取,转换,怎么生成报表,BI。而在数据仓库建设初期,可视化建模,转换为数据抽取处理逻辑这个环节,相关产品好用的不是太多。
跟本发明类似的产品有某公司ABI中关于数据仓可视化建模部分,但这个也只是作为他的BI产品中的一个亮点,并没有作为主要的发展方向。
这款产品更注重的是可视化交互,涵盖了事实表,维度表设计,简单的数据抽提流程配置,以及通用的数据源集成能力。在实际使用中发现对于一般交易型数据比较适合,一项订单涉及到的数据量不会太多。对于项目管理这类以时间维度为中心的数据仓库建模在一些细节实现上基本上无法满足要求,更多的是针对单一客户(例如一个公司,一个集团内)的使用场景。在saas系统中要应对国内各家客户个性化数仓设计,面对各种定制化指标,时间周期(例如统计月起始/结束)无法提供有效的解决方案。
另外这款产品面向的是实施人员和开发人员,使用上来说尽管有可视化操作界面,但是仍然比较复杂,包含的数仓概念比较多。基本上无法交给最终客户自己管理和创建定制的数仓schema和etl。并且数据在抽取过程用时比较长,会对数据仓库里现有的数据会产生一些影响,在一定时间内会出现新旧数据交替的状态,因此一般的数仓ETL的过程都是一天只做一次,并且时间都在半夜使用最少的阶段。
发明内容
为解决上述技术问题,本发明提出一种数据仓库建模和抽取方法及系统的技术方案,以解决上述技术问题。
本发明第一方面公开了一种数据仓库建模和抽取方法,所述方法包括:
步骤S1、模型设计:对具体的业务事实创建数据仓库的主题,然后根据所述主题生成一组维度表、事实表和汇聚表,再根据主题、维度表、事实表和汇聚表建立数据仓库;
步骤S2、ETL过程:在数据仓库的存储上设计了两个数据库,一个是前台库,另外一个是后台库;所述前台库是所述数据仓库对外提供查询的数据库,所述后台库是所述数据仓库在执行数据抽取的库;ETL执行时,根据所述事实表和维度表的描述信息,生成对应的sql语句,在所述后台库上按租户启动抽取任务。
根据本发明第一方面的方法,在所述步骤S1中,所述对具体的业务事实创建数据仓库的主题,然后根据所述主题生成一组维度表、事实表和汇聚表,再根据主题、维度表、事实表和汇聚表建立数据仓库的具体方法包括:
步骤S1.1、在目录列表创建主题名称,定义好主题各种属性;
步骤S1.2、为体现主题若干项的各分析角度,定义各项维度表,存储稳定的、不易修改的数据,并且所述数据一般是事实表的某个属性字段;
步骤S1.3、根据确定好的事实数据和维度,创建事实表,存储实际产生的业务数据;
步骤S1.4、根据所述事实表和维度表的设计汇聚表,用于把多个事实表和维度表按需组合形成到一张表中,对外提供统一的查询方式。
根据本发明第一方面的方法,在所述步骤S1中,设计所述项维度表的具体方法包括:
使用单一代理主键:如果某一个维度确实由多个字段才能唯一确定,就把这些字段拼接成一个字段作为所述维度表的主键;
使用版本号做增量更新:如果维度表更新,也需要保留原始的记录,生成一条新的维度信息,两条维度信息都对应着同一个维度值,只是版本号不一样,版本号是根据时间信息生成的,在不同的查询周期内使用对应版本号的维度值;
记录来源信息:记录维度数据从哪里来的,根据来源信息追溯维度数据来源,维度数据之间血缘关系;
假删除:维度数据一旦生成,就不会删掉。
根据本发明第一方面的方法,在所述步骤S1中,所述设计所述项维度表的具体方法还包括:
将日期维度的复杂度封装到维度表中,简化事实表。
根据本发明第一方面的方法,在所述步骤S1中,所述数据仓库的数据集市的职责是由所述汇聚表来承担;所述汇聚表是所述数据仓库的出口,所述数据仓库的访问主要通过汇聚表进行;
所述汇聚表的设计方法包括:
从各项角度分析原始数据结构,定义各项维度;
根据维度字段一次性选择所有维度字段;
选择事实表的度量和汇聚方式,生成汇聚表。
根据本发明第一方面的方法,在所述步骤S2中,所述前台库和后台库在结构上完全一样,在物理上完全隔离,程序里配置一个参数作为数据库的标识,指示当前使用的是哪一个数据库,后台数据库无法由使用者直接访问到。
根据本发明第一方面的方法,在所述步骤S2中,当所述后台数据库上的抽取任务完成后,会执行一条指令修改当前数据库的标识,把原来的前台库切换为后台库,把后台库切换为前台库,新旧数据库瞬间完成切换过程。
本发明第二方面公开了一种数据仓库建模和抽取系统,所述系统包括:
第一处理模块,被配置为,模型设计:对具体的业务事实创建数据仓库的主题,然后根据所述主题生成一组维度表、事实表和汇聚表,再根据主题、维度表、事实表和汇聚表建立数据仓库;
第二处理模块,被配置为,ETL过程:在数据仓库的存储上设计了两个数据库,一个是前台库,另外一个是后台库;所述前台库是所述数据仓库对外提供查询的数据库,所述后台库是所述数据仓库在执行数据抽取的库;ETL执行时,根据所述事实表和维度表的描述信息,生成对应的sql语句,在所述后台库上按租户启动抽取任务。
根据本发明第二方面的系统,第一处理模块,被配置为,在目录列表创建主题名称,定义好主题各种属性;为体现主题若干项的各分析角度,定义各项维度表,存储稳定的、不易修改的数据,并且所述数据一般是事实表的某个属性字段;根据确定好的事实数据和维度,创建事实表,存储实际产生的业务数据;根据所述事实表和维度表的设计汇聚表,用于把多个事实表和维度表按需组合形成到一张表中,对外提供统一的查询方式。
根据本发明第二方面的系统,第一处理模块,被配置为,使用单一代理主键:如果某一个维度确实由多个字段才能唯一确定,就把这些字段拼接成一个字段作为所述维度表的主键;使用版本号做增量更新:如果维度表更新,也需要保留原始的记录,生成一条新的维度信息,两条维度信息都对应着同一个维度值,只是版本号不一样,版本号是根据时间信息生成的,在不同的查询周期内使用对应版本号的维度值;记录来源信息:记录维度数据从哪里来的,根据来源信息追溯维度数据来源,维度数据之间血缘关系;假删除:维度数据一旦生成,就不会删掉。
根据本发明第二方面的系统,第一处理模块,被配置为,将日期维度的复杂度封装到维度表中,简化事实表。
根据本发明第二方面的系统,第一处理模块,被配置为,所述数据仓库的数据集市的职责是由所述汇聚表来承担;所述汇聚表是所述数据仓库的出口,所述数据仓库的访问主要通过汇聚表进行;
所述汇聚表的设计方法包括:
从各项角度分析原始数据结构,定义各项维度;
根据维度字段一次性选择所有维度字段;
选择事实表的度量和汇聚方式,生成汇聚表。
根据本发明第二方面的系统,第二处理模块,被配置为,所述前台库和后台库在结构上完全一样,在物理上完全隔离,程序里配置一个参数作为数据库的标识,指示当前使用的是哪一个数据库,后台数据库无法由使用者直接访问到。
根据本发明第二方面的系统,第二处理模块,被配置为,当所述后台数据库上的抽取任务完成后,会执行一条指令修改当前数据库的标识,把原来的前台库切换为后台库,把后台库切换为前台库,新旧数据库瞬间完成切换过程。
本发明第三方面公开了一种电子设备。电子设备包括存储器和处理器,存储器存储有计算机程序,处理器执行计算机程序时,实现本发明第一方面中任一项的一种数据仓库建模和抽取方法中的步骤。
本发明第四方面公开了一种计算机可读存储介质。计算机可读存储介质上存储有计算机程序,计算机程序被处理器执行时,实现本发明第一方面中任一项的一种数据仓库建模和抽取方法中的步骤。
本发明提出的方案,具有如下有益效果:业务人员跟客户交流的过程中可以一边讨论一边用该工具提取出指标,维度等信息,根据一个个分析主题设计出事实表。可实时看到想要的数据。从开始设计到上线顺利的话最多一天时间就可以推上线。同以往相比大大缩短了开发周期,并且能支持客户个性化的配置,特别是各家时间统计窗口的不同带来的问题。相比同类别的数仓数据更新时间都是最短的,更新周期最多不超过1小时,极大的提升了客户体验。
附图说明
为了更清楚地说明本发明具体实施方式或现有技术中的技术方案,下面将对具体实施方式或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图是本发明的一些实施方式,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1为根据本发明实施例的一种数据仓库建模和抽取方法的流程图;
图2为根据本发明实施例的数据仓库建模和抽取在整个数仓架构中的位置示意图;
图3为根据本发明实施例的使用版本号做增量更新示例图;
图4a-4b为根据本发明实施例的非自然周期示意图;
图5为根据本发明实施例的数仓存储结构示意图;
图6为根据本发明实施例的前台库切换为后台库示意图;
图7为根据本发明实施例的一种数据仓库建模和抽取系统的结构图;
图8为根据本发明实施例的一种电子设备的结构图。
具体实施方式
为使本发明实施例的目的、技术方案和优点更加清楚,下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例只是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。
本发明第一方面公开了一种数据仓库建模和抽取方法。图1为根据本发明实施例的一种数据仓库建模和抽取方法的流程图,如图1和图2所示,所述方法包括:
步骤S1、模型设计:对具体的业务事实创建数据仓库的主题,然后根据所述主题生成一组维度表、事实表和汇聚表,再根据主题、维度表、事实表和汇聚表建立数据仓库;
步骤S2、ETL过程:在数据仓库的存储上设计了两个数据库,一个是前台库,另外一个是后台库;所述前台库是所述数据仓库对外提供查询的数据库,所述后台库是所述数据仓库在执行数据抽取的库;ETL执行时,根据所述事实表和维度表的描述信息,生成对应的sql语句,在所述后台库上按租户启动抽取任务。
在步骤S1,模型设计:对具体的业务事实创建数据仓库的主题,然后根据所述主题生成一组维度表、事实表和汇聚表,再根据主题、维度表、事实表和汇聚表建立数据仓库。
在一些实施例中,在所述步骤S1中,所述对具体的业务事实创建数据仓库的主题,然后根据所述主题生成一组维度表、事实表和汇聚表,再根据主题、维度表、事实表和汇聚表建立数据仓库的具体方法包括:
步骤S1.1、在目录列表创建主题名称,定义好主题各种属性;
步骤S1.2、为体现主题若干项的各分析角度,定义各项维度表,存储稳定的、不易修改的数据,并且所述数据一般是事实表的某个属性字段,方便于工具生成汇聚表和生成查询;比如日期,项目,材料,材料类别等;
如果维度已存在,可以直接跳过此步。维度表与事实表在使用上的区别是维度表可以被其它事实表引用,生成维度字段,但是事实表不能被其它事实表引用。
步骤S1.3、根据确定好的事实数据和维度,创建事实表,存储实际产生的业务数据,例如合同台账,施工日志等,这类数据主要是由用户使用系统过程中产生的;
步骤S1.4、根据所述事实表和维度表的设计汇聚表,用于把多个事实表和维度表按需组合形成到一张表中,对外提供统一的查询方式。
设计所述项维度表的具体方法包括:
使用单一代理主键:如表1所示,如果某一个维度确实由多个字段才能唯一确定,就把这些字段拼接成一个字段作为所述维度表的主键,比如时间里的日期,就是由年,月,日,产品线编码,等联合组成;
使用版本号做增量更新:维度表在定义上就要求不能轻易变更,只能增加,一个变更设计时就的内容一般都不会轻易变更新,不会更新,只会随着时间变化而增加;如果维度表更新,也需要保留原始的记录,生成一条新的维度信息,两条维度信息都对应着同一个维度值,只是版本号不一样,版本号是根据时间信息生成的,在不同的查询周期内使用对应版本号的维度值,保证历史查询信息不会因为维度信息发生变更而发生变化;
如图3所示,版本号只是一个示例,实际使用中版本号比这个要复杂一点。
从图3中可以看出,这条维度数据是在2019年8月27号生成的,在2020年3月1日发生过变更。在查询2019年8月27号至2020年3月1号之间的数据时,使用的上面那项维度数据;在查询2020年3月1日之后的数据时,使用的是后面的那项维度数据;如果查询区间跨过了2020年3月31日,会把查询区间分成两段,一段是在2020年3月1日之前的,一段是2020年3月1日之后的,查询完成后再合并到一起;
记录来源信息:记录维度数据从哪里来的,根据来源信息追溯维度数据来源,维度数据之间血缘关系;
假删除:维度数据一旦生成,就不会删掉,因为之前的事实表已经跟这条维度数据发生关联了。如果删除了的话,以前的事实表的数据就失去了关联的信息。按照该维度统计时就会漏统计。
维度表里有一个比较特殊的维度就是日期维度,由于项目管理业务中,统计周期概念的存在,使得日期维度非常复杂。他的复杂性主要体现在以下4个方面:
非自然周期:如图4a-图4b所示,统计周期往往不是自然周期,比如月报是26号到下月25号,年报可能是上一年12月26号到本年12月25号,周报可能是周一到周日,也可能是上一个周六到本周五。周遇到月时还存在截断和不截断的情况;
客户和组织差异:不同客户不同的组织结构,统计要求不同,统计周期也不相同;
不同产品统计周期不同;
统计周期变化:管理制度发生变化导致统计周期发生变化。
设计时时间维度时,如表2所示,把维度分成日/周/月/季/年5个层次,分存存放在对应的维度表里,同时前面的会冗余后面所有层次的信息。这样在使用时间维度的时候只需要关联该业务能够用到的最细粒度的那一级。例如细分到日的维度表里,包含了所属日,所属周,所属月和所属年的信息。当需要统计表细化到日时,就可以在关联时间维度时关联到日层级的维度,由于日层级维度里包含了其它层级的信息,就可以很方便的进行汇总聚合。
表1
year_id pp-p-2020-645099242715136 产品-组织层级-年-orgid
quarter_id pp-p-20201-645099242715136 产品-组织层级-季-orgid
month_id pp-p-202001-645099242715136 产品-组织层级-月-orgid
week_id pp-p-20200104~20200110-645099242715136 产品-组织层级-开始日期~结束日期-orgid
date_id pp-p-20200106-645099242715136 产品-组织层级-日期-orgid
表2
Figure BDA0003542638540000131
如果事实表使用了细化到日的时间维度,另一个目标事实表使用了细化到季的时间维度,两个事实表要放在一起统计分析的话,由于统计周期在不同项目中不固定,不能直接按自然月进行统计,此时就可以根据细化到日的时间维度里包含了所属月的id信息建立两个事实表的时间关系,从而在相同的时间跨度上进行统计。
所述设计所述项维度表的具体方法还包括:
将日期维度的复杂度封装到维度表中,简化事实表。
事实表在设计中分成三种类型,事务型、周期快照型和计算型。事务型事实表是原始数据的直接映射,基本上与原始数据是一一对应的,事务型事实表在处理删除时用的是假删除方式,要求原始表有一个能表达version含义的字段,根据versiOn做增量更新。每次都用最新的版本替换旧的版本,不保留历史信息,因为事务型事实表反映的就是数据的最新状态,这种设计方式完全能够满足当前行业在业务上的需要。
周期快照型事实表是按固定周期对原始数据的一些简单加工,设计这种类型是为了在查询阶段加快查询速度,这种事实表更像是一种物化的视图,与视图的区别是,视图本身是由事实表生成的,使用时不能再与任何事实表关联达询。这种周期快照事实表仍然可以与其它事实表一起联合查询分析。
还有一种计算型事实表一般是用在分层级的树状数据上,例如按组织层级统计材料信息,算量结果等,按wbs节点统计汇总等等,这类数据如果不预先计算好每一层级的汇总值的话,这样的事实表在数仓里面基本上没法直接拿来使用。
事实表的字段分为主键(surrogate_key),普通维度(dim_fk),退化维度(degenerate_dim),保留字段(reserved),度量值字段(measure)。其中普通维度关联的是某一类维度表的信息,在查询分析时可以被选择器列出供选择,使用的查询条件只有等于,不等,(列表)包含,(列表)不包含。退化维度功能相当于一个维度字段,只不过没有对应的维度表,类型为普通字符串,同样可用于查询过滤,过滤时只能是字符串的等于,不等于,包含,不包含等操作。保留字段为内部使用,用于分析数据来源血缘关系信息。
所述数据仓库的数据集市的职责是由所述汇聚表来承担;所述汇聚表是所述数据仓库的出口,所述数据仓库的访问主要通过汇聚表进行;
维度表和事实表是相对稳定的,汇聚表是灵活变化的;
汇聚表建模过程,是业务人员可以胜任的,不需要技术背景;
汇聚表的数据,是自动生成的,不需要人工编程ETL;
汇聚表是预计算并落盘的,在预计算的过程中处理大量的连接、聚合操作,以提高查询时的效率;
所述汇聚表的设计方法包括:
从各项角度分析原始数据结构,定义各项维度;
根据维度字段一次性选择所有维度字段;
选择事实表的度量和汇聚方式,生成汇聚表。
在步骤S2,ETL过程:如图5所示为数仓存储结构示意图,为了能达到1小时抽取一次,而对线上使用数据仓库的业务不产生影响,如图6所示,在数据仓库的存储上设计了两个数据库,一个是前台库,另外一个是后台库;所述前台库是所述数据仓库对外提供查询的数据库,所述后台库是所述数据仓库在执行数据抽取的库;ETL执行时,根据所述事实表和维度表的描述信息,生成对应的sql语句,在所述后台库上按租户启动抽取任务,按照数据量最大的租户算整个抽取过程用时可以控制在40分钟以内,因此完全可以做到1小时抽取一次数据,抽取完成后可立即被外部应用查询使用。
在一些实施例中,在所述步骤S2中,所述前台库和后台库在结构上完全一样,在物理上完全隔离,程序里配置一个参数作为数据库的标识,指示当前使用的是哪一个数据库,后台数据库无法由使用者直接访问到,此时抽取程序在后台库上所有操作对使用数据仓库的人来说都是完全透明的。
在一些实施例中,如图6所示,当所述后台数据库上的抽取任务完成后,会执行一条指令修改当前数据库的标识,把原来的前台库切换为后台库,把后台库切换为前台库,新旧数据库瞬间完成切换过程。
综上,本发明提出的方案,业务人员跟客户交流的过程中可以一边讨论一边用该工具提取出指标,维度等信息,根据一个个分析主题设计出事实表。可实时看到想要的数据。从开始设计到上线顺利的话最多一天时间就可以推上线。同以往相比大大缩短了开发周期,并且能支持客户个性化的配置,特别是各家时间统计窗口的不同带来的问题。相比同类别的数仓数据更新时间都是最短的,更新周期最多不超过1小时,极大的提升了客户体验。
本发明第二方面公开了一种数据仓库建模和抽取系统。图7为根据本发明实施例的一种数据仓库建模和抽取系统的结构图;如图7所示,所述系统100包括:
第一处理模块101,被配置为,模型设计:对具体的业务事实创建数据仓库的主题,然后根据所述主题生成一组维度表、事实表和汇聚表,再根据主题、维度表、事实表和汇聚表建立数据仓库;
第二处理模块102,被配置为,ETL过程:在数据仓库的存储上设计了两个数据库,一个是前台库,另外一个是后台库;所述前台库是所述数据仓库对外提供查询的数据库,所述后台库是所述数据仓库在执行数据抽取的库;ETL执行时,根据所述事实表和维度表的描述信息,生成对应的sql语句,在所述后台库上按租户启动抽取任务。
根据本发明第二方面的系统,所述第一处理模块101具体被配置为,所述对具体的业务事实创建数据仓库的主题,然后根据所述主题生成一组维度表、事实表和汇聚表,再根据主题、维度表、事实表和汇聚表建立数据仓库的具体方法包括:
在目录列表创建主题名称,定义好主题各种属性;
为体现主题若干项的各分析角度,定义各项维度表,存储稳定的、不易修改的数据,并且所述数据一般是事实表的某个属性字段,方便于工具生成汇聚表和生成查询;比如日期,项目,材料,材料类别等;
如果维度已存在,可以直接跳过此步。维度表与事实表在使用上的区别是维度表可以被其它事实表引用,生成维度字段,但是事实表不能被其它事实表引用。
根据确定好的事实数据和维度,创建事实表,存储实际产生的业务数据,例如合同台账,施工日志等,这类数据主要是由用户使用系统过程中产生的;
根据所述事实表和维度表的设计汇聚表,用于把多个事实表和维度表按需组合形成到一张表中,对外提供统一的查询方式。
设计所述项维度表的具体方法包括:
使用单一代理主键:如表1所示,如果某一个维度确实由多个字段才能唯一确定,就把这些字段拼接成一个字段作为所述维度表的主键,比如时间里的日期,就是由年,月,日,产品线编码,等联合组成;
使用版本号做增量更新:维度表在定义上就要求不能轻易变更,只能增加,一个变更设计时就的内容一般都不会轻易变更新,不会更新,只会随着时间变化而增加;如果维度表更新,也需要保留原始的记录,生成一条新的维度信息,两条维度信息都对应着同一个维度值,只是版本号不一样,版本号是根据时间信息生成的,在不同的查询周期内使用对应版本号的维度值,保证历史查询信息不会因为维度信息发生变更而发生变化;
如图3所示,版本号只是一个示例,实际使用中版本号比这个要复杂一点。
从图3中可以看出,这条维度数据是在2019年8月27号生成的,在2020年3月1日发生过变更。在查询2019年8月27号至2020年3月1号之间的数据时,使用的上面那项维度数据;在查询2020年3月1日之后的数据时,使用的是后面的那项维度数据;如果查询区间跨过了2020年3月31日,会把查询区间分成两段,一段是在2020年3月1日之前的,一段是2020年3月1日之后的,查询完成后再合并到一起;
记录来源信息:记录维度数据从哪里来的,根据来源信息追溯维度数据来源,维度数据之间血缘关系;
假删除:维度数据一旦生成,就不会删掉,因为之前的事实表已经跟这条维度数据发生关联了。如果删除了的话,以前的事实表的数据就失去了关联的信息。按照该维度统计时就会漏统计。
维度表里有一个比较特殊的维度就是日期维度,由于项目管理业务中,统计周期概念的存在,使得日期维度非常复杂。他的复杂性主要体现在以下4个方面:
非自然周期:如如图4a-图4b所示,统计周期往往不是自然周期,比如月报是26号到下月25号,年报可能是上一年12月26号到本年12月25号,周报可能是周一到周日,也可能是上一个周六到本周五。周遇到月时还存在截断和不截断的情况;
客户和组织差异:不同客户不同的组织结构,统计要求不同,统计周期也不相同;
不同产品统计周期不同;
统计周期变化:管理制度发生变化导致统计周期发生变化。
设计时时间维度时,如表2所示,把维度分成日/周/月/季/年5个层次,分存存放在对应的维度表里,同时前面的会冗余后面所有层次的信息。这样在使用时间维度的时候只需要关联该业务能够用到的最细粒度的那一级。例如细分到日的维度表里,包含了所属日,所属周,所属月和所属年的信息。当需要统计表细化到日时,就可以在关联时间维度时关联到日层级的维度,由于日层级维度里包含了其它层级的信息,就可以很方便的进行汇总聚合。
如果事实表使用了细化到日的时间维度,另一个目标事实表使用了细化到季的时间维度,两个事实表要放在一起统计分析的话,由于统计周期在不同项目中不固定,不能直接按自然月进行统计,此时就可以根据细化到日的时间维度里包含了所属月的id信息建立两个事实表的时间关系,从而在相同的时间跨度上进行统计。
所述设计所述项维度表的具体方法还包括:
将日期维度的复杂度封装到维度表中,简化事实表。
事实表在设计中分成三种类型,事务型、周期快照型和计算型。事务型事实表是原始数据的直接映射,基本上与原始数据是一一对应的,事务型事实表在处理删除时用的是假删除方式,要求原始表有一个能表达version含义的字段,根据version做增量更新。每次都用最新的版本替换旧的版本,不保留历史信息,因为事务型事实表反映的就是数据的最新状态,这种设计方式完全能够满足当前行业在业务上的需要。
周期快照型事实表是按固定周期对原始数据的一些简单加工,设计这种类型是为了在查询阶段加快查询速度,这种事实表更像是一种物化的视图,与视图的区别是,视图本身是由事实表生成的,使用时不能再与任何事实表关联达询。这种周期快照事实表仍然可以与其它事实表一起联合查询分析。
还有一种计算型事实表一般是用在分层级的树状数据上,例如按组织层级统计材料信息,算量结果等,按wbs节点统计汇总等等,这类数据如果不预先计算好每一层级的汇总值的话,这样的事实表在数仓里面基本上没法直接拿来使用。
事实表的字段分为主键(surrogate_key),普通维度(dim_fk),退化维度(degenerate_dim),保留字段(reserved),度量值字段(measure)。其中普通维度关联的是某一类维度表的信息,在查询分析时可以被选择器列出供选择,使用的查询条件只有等于,不等,(列表)包含,(列表)不包含。退化维度功能相当于一个维度字段,只不过没有对应的维度表,类型为普通字符串,同样可用于查询过滤,过滤时只能是字符串的等于,不等于,包含,不包含等操作。保留字段为内部使用,用于分析数据来源血缘关系信息。
所述数据仓库的数据集市的职责是由所述汇聚表来承担;所述汇聚表是所述数据仓库的出口,所述数据仓库的访问主要通过汇聚表进行;
维度表和事实表是相对稳定的,汇聚表是灵活变化的;
汇聚表建模过程,是业务人员可以胜任的,不需要技术背景;
汇聚表的数据,是自动生成的,不需要人工编程ETL;
汇聚表是预计算并落盘的,在预计算的过程中处理大量的连接、聚合操作,以提高查询时的效率;
所述汇聚表的设计方法包括:
从各项角度分析原始数据结构,定义各项维度;
根据维度字段一次性选择所有维度字段;
选择事实表的度量和汇聚方式,生成汇聚表。
根据本发明第二方面的系统,所述第二处理模块102具体被配置为,ETL过程:如图5所示为数仓存储结构示意图,为了能达到1小时抽取一次,而对线上使用数据仓库的业务不产生影响,如图6所示,在数据仓库的存储上设计了两个数据库,一个是前台库,另外一个是后台库;所述前台库是所述数据仓库对外提供查询的数据库,所述后台库是所述数据仓库在执行数据抽取的库;ETL执行时,根据所述事实表和维度表的描述信息,生成对应的sql语句,在所述后台库上按租户启动抽取任务,按照数据量最大的租户算整个抽取过程用时可以控制在40分钟以内,因此完全可以做到1小时抽取一次数据,抽取完成后可立即被外部应用查询使用。
所述前台库和后台库在结构上完全一样,在物理上完全隔离,程序里配置一个参数作为数据库的标识,指示当前使用的是哪一个数据库,后台数据库无法由使用者直接访问到,此时抽取程序在后台库上所有操作对使用数据仓库的人来说都是完全透明的。
当所述后台数据库上的抽取任务完成后,会执行一条指令修改当前数据库的标识,把原来的前台库切换为后台库,把后台库切换为前台库,新旧数据库瞬间完成切换过程。
本发明第三方面公开了一种电子设备。电子设备包括存储器和处理器,存储器存储有计算机程序,处理器执行计算机程序时,实现本发明公开第一方面中任一项的一种数据仓库建模和抽取方法中的步骤。
图8为根据本发明实施例的一种电子设备的结构图,如图8所示,电子设备包括通过系统总线连接的处理器、存储器、通信接口、显示屏和输入装置。其中,该电子设备的处理器用于提供计算和控制能力。该电子设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统和计算机程序。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该电子设备的通信接口用于与外部的终端进行有线或无线方式的通信,无线方式可通过WIFI、运营商网络、近场通信(NFC)或其他技术实现。该电子设备的显示屏可以是液晶显示屏或者电子墨水显示屏,该电子设备的输入装置可以是显示屏上覆盖的触摸层,也可以是电子设备外壳上设置的按键、轨迹球或触控板,还可以是外接的键盘、触控板或鼠标等。
本领域技术人员可以理解,图8中示出的结构,仅仅是与本公开的技术方案相关的部分的结构图,并不构成对本申请方案所应用于其上的电子设备的限定,具体的电子设备可以包括比图中所示更多或更少的部件,或者组合某些部件,或者具有不同的部件布置。
本发明第四方面公开了一种计算机可读存储介质。计算机可读存储介质上存储有计算机程序,计算机程序被处理器执行时,实现本发明公开第一方面中任一项的一种数据仓库建模和抽取方法中的步骤中的步骤。
请注意,以上实施例的各技术特征可以进行任意的组合,为使描述简洁,未对上述实施例中的各个技术特征所有可能的组合都进行描述,然而,只要这些技术特征的组合不存在矛盾,都应当认为是本说明书记载的范围。以上实施例仅表达了本申请的几种实施方式,其描述较为具体和详细,但并不能因此而理解为对发明专利范围的限制。应当指出的是,对于本领域的普通技术人员来说,在不脱离本申请构思的前提下,还可以做出若干变形和改进,这些都属于本申请的保护范围。因此,本申请专利的保护范围应以所附权利要求为准。

Claims (4)

1.一种数据仓库建模和抽取方法,其特征在于,所述方法包括:
步骤S1、模型设计:对具体的业务事实创建数据仓库的主题,然后根据所述主题生成一组维度表、事实表和汇聚表,再根据主题、维度表、事实表和汇聚表建立数据仓库;
步骤S2、ETL过程:在数据仓库的存储上设计了两个数据库,一个是前台库,另外一个是后台库;所述前台库是所述数据仓库对外提供查询的数据库,所述后台库是所述数据仓库在执行数据抽取的库;ETL执行时,根据所述事实表和维度表的描述信息,生成对应的sql语句,在所述后台库上按租户启动抽取任务;
在所述步骤S1中,所述对具体的业务事实创建数据仓库的主题,然后根据所述主题生成一组维度表、事实表和汇聚表,再根据主题、维度表、事实表和汇聚表建立数据仓库的具体方法包括:
步骤S1.1、在目录列表创建主题名称,定义好主题各种属性;
步骤S1.2、为体现主题若干项的各分析角度,定义各项维度表,存储稳定的、不易修改的数据,并且所述数据是事实表的某个属性字段;
步骤S1.3、根据确定好的事实数据和维度,创建事实表,存储实际产生的业务数据;
步骤S1.4、根据所述事实表和维度表的设计汇聚表,用于把多个事实表和维度表按需组合形成到一张表中,对外提供统一的查询方式;
在所述步骤S1中,设计所述各项维度表的具体方法包括:
使用单一代理主键:如果某一个维度确实由多个字段才能唯一确定,就把这些字段拼接成一个字段作为所述维度表的主键;
使用版本号做增量更新:如果维度表更新,也需要保留原始的记录,生成一条新的维度信息,两条维度信息都对应着同一个维度值,只是版本号不一样,版本号是根据时间信息生成的,在不同的查询周期内使用对应版本号的维度值;
记录来源信息:记录维度数据从哪里来的,根据来源信息追溯维度数据来源,维度数据之间血缘关系;
假删除:维度数据一旦生成,就不会删掉;
在所述步骤S1中,所述设计所述各项维度表的具体方法还包括:
将日期维度的复杂度封装到维度表中,简化事实表;
在所述步骤S1中,所述数据仓库的数据集市的职责是由所述汇聚表来承担;所述汇聚表是所述数据仓库的出口,所述数据仓库的访问主要通过汇聚表进行;
所述汇聚表的设计方法包括:
从各项角度分析原始数据结构,定义各项维度;
根据维度字段一次性选择所有维度字段;
选择事实表的度量和汇聚方式,生成汇聚表;
在所述步骤S2中,所述前台库和后台库在结构上完全一样,在物理上完全隔离,程序里配置一个参数作为数据库的标识,指示当前使用的是哪一个数据库,后台数据库无法由使用者直接访问到;
在所述步骤S2中,当所述后台数据库上的抽取任务完成后,会执行一条指令修改当前数据库的标识,把原来的前台库切换为后台库,把后台库切换为前台库,新旧数据库瞬间完成切换过程。
2.一种用于数据仓库建模和抽取系统,其特征在于,所述系统包括:
第一处理模块,被配置为,模型设计:对具体的业务事实创建数据仓库的主题,然后根据所述主题生成一组维度表、事实表和汇聚表,再根据主题、维度表、事实表和汇聚表建立数据仓库;
所述对具体的业务事实创建数据仓库的主题,然后根据所述主题生成一组维度表、事实表和汇聚表,再根据主题、维度表、事实表和汇聚表建立数据仓库的具体包括:
在目录列表创建主题名称,定义好主题各种属性;
为体现主题若干项的各分析角度,定义各项维度表,存储稳定的、不易修改的数据,并且所述数据是事实表的某个属性字段;
根据确定好的事实数据和维度,创建事实表,存储实际产生的业务数据;
根据所述事实表和维度表的设计汇聚表,用于把多个事实表和维度表按需组合形成到一张表中,对外提供统一的查询方式;
设计所述各项维度表的具体包括:
使用单一代理主键:如果某一个维度确实由多个字段才能唯一确定,就把这些字段拼接成一个字段作为所述维度表的主键;
使用版本号做增量更新:如果维度表更新,也需要保留原始的记录,生成一条新的维度信息,两条维度信息都对应着同一个维度值,只是版本号不一样,版本号是根据时间信息生成的,在不同的查询周期内使用对应版本号的维度值;
记录来源信息:记录维度数据从哪里来的,根据来源信息追溯维度数据来源,维度数据之间血缘关系;
假删除:维度数据一旦生成,就不会删掉;
所述设计所述各项维度表的具体还包括:
将日期维度的复杂度封装到维度表中,简化事实表;
所述数据仓库的数据集市的职责是由所述汇聚表来承担;所述汇聚表是所述数据仓库的出口,所述数据仓库的访问主要通过汇聚表进行;
所述汇聚表的设计具体包括:
从各项角度分析原始数据结构,定义各项维度;
根据维度字段一次性选择所有维度字段;
选择事实表的度量和汇聚方式,生成汇聚表;
第二处理模块,被配置为,ETL过程:在数据仓库的存储上设计了两个数据库,一个是前台库,另外一个是后台库;所述前台库是所述数据仓库对外提供查询的数据库,所述后台库是所述数据仓库在执行数据抽取的库;ETL执行时,根据所述事实表和维度表的描述信息,生成对应的sql语句,在所述后台库上按租户启动抽取任务;
所述前台库和后台库在结构上完全一样,在物理上完全隔离,程序里配置一个参数作为数据库的标识,指示当前使用的是哪一个数据库,后台数据库无法由使用者直接访问到;
当所述后台数据库上的抽取任务完成后,会执行一条指令修改当前数据库的标识,把原来的前台库切换为后台库,把后台库切换为前台库,新旧数据库瞬间完成切换过程。
3.一种电子设备,其特征在于,所述电子设备包括存储器和处理器,所述存储器存储有计算机程序,所述处理器执行所述计算机程序时,实现权利要求1所述的一种数据仓库建模和抽取方法中的步骤。
4.一种计算机可读存储介质,其特征在于,所述计算机可读存储介质上存储有计算机程序,所述计算机程序被处理器执行时,实现权利要求1所述的一种数据仓库建模和抽取方法中的步骤。
CN202210237026.2A 2022-03-11 2022-03-11 一种数据仓库建模和抽取方法及系统 Active CN114595294B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202210237026.2A CN114595294B (zh) 2022-03-11 2022-03-11 一种数据仓库建模和抽取方法及系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202210237026.2A CN114595294B (zh) 2022-03-11 2022-03-11 一种数据仓库建模和抽取方法及系统

Publications (2)

Publication Number Publication Date
CN114595294A CN114595294A (zh) 2022-06-07
CN114595294B true CN114595294B (zh) 2022-09-20

Family

ID=81817010

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202210237026.2A Active CN114595294B (zh) 2022-03-11 2022-03-11 一种数据仓库建模和抽取方法及系统

Country Status (1)

Country Link
CN (1) CN114595294B (zh)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115292274B (zh) * 2022-06-29 2023-12-26 江苏昆山农村商业银行股份有限公司 一种数据仓库主题模型构建方法和系统
CN115328883B (zh) * 2022-06-29 2024-06-18 江苏昆山农村商业银行股份有限公司 一种数据仓库建模方法和系统
CN117874009B (zh) * 2024-03-13 2024-07-05 云筑信息科技(成都)有限公司 一种数仓模型创建和管理的系统

Family Cites Families (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7657576B1 (en) * 2001-05-24 2010-02-02 Oracle International Corporation Asynchronous change capture for data warehousing
US7415487B2 (en) * 2004-12-17 2008-08-19 Amazon Technologies, Inc. Apparatus and method for data warehousing
US7752230B2 (en) * 2005-10-06 2010-07-06 Avaya Inc. Data extensibility using external database tables
CN101042746A (zh) * 2006-03-21 2007-09-26 上海浦东国际集装箱码头有限公司 基于数据仓库的集装箱码头智能化报表及方法
EP1953655A3 (en) * 2007-02-01 2008-12-31 Acei Ab Transaction processing system and method
US7822712B1 (en) * 2007-10-18 2010-10-26 Google Inc. Incremental data warehouse updating
US8078570B2 (en) * 2009-05-01 2011-12-13 International Business Machines Corporation Versioning data warehouses
CN101916261B (zh) * 2010-07-28 2013-07-17 北京播思软件技术有限公司 一种分布式并行数据库系统的数据分区方法
GB2488147A (en) * 2011-02-17 2012-08-22 Equi Media Ltd A method for generating an OLAP cube from a database of user activity on a network
US9600500B1 (en) * 2013-06-21 2017-03-21 Amazon Technologies, Inc. Single phase transaction commits for distributed database transactions
MY187720A (en) * 2014-08-05 2021-10-14 Mimos Berhad Method for data input into a database
CN104317928A (zh) * 2014-10-31 2015-01-28 北京思特奇信息技术股份有限公司 一种基于分布式数据库的业务etl方法及系统
US10353918B2 (en) * 2014-11-07 2019-07-16 Amobee, Inc. High availability and disaster recovery in large-scale data warehouse
US10360231B2 (en) * 2015-07-06 2019-07-23 Oracle International Corporation Dynamically switching between data sources
CN109189764A (zh) * 2018-09-20 2019-01-11 北京桃花岛信息技术有限公司 一种基于Hive的高校数据仓库分层设计方法
US11487776B2 (en) * 2020-02-26 2022-11-01 International Business Machines Corporation Managing extract-transform-load operations
CN112084182A (zh) * 2020-09-10 2020-12-15 重庆富民银行股份有限公司 一种用于数据集市和数据仓库的数据建模方法
CN112506937A (zh) * 2020-10-30 2021-03-16 福建亿能达信息技术股份有限公司 一种数据库模型的在线配置方法、装置、设备和介质
CN114036147A (zh) * 2021-10-28 2022-02-11 建信金融科技有限责任公司 数据仓库构建方法、装置、设备及存储介质

Also Published As

Publication number Publication date
CN114595294A (zh) 2022-06-07

Similar Documents

Publication Publication Date Title
CN114595294B (zh) 一种数据仓库建模和抽取方法及系统
US20230334030A1 (en) System and method for slowly changing dimension and metadata versioning in a multidimensional database environment
US10459940B2 (en) Systems and methods for interest-driven data visualization systems utilized in interest-driven business intelligence systems
EP3513314B1 (en) System for analysing data relationships to support query execution
US9922054B2 (en) Data retrieval apparatus, program and recording medium
US10540363B2 (en) Systems and methods for providing performance metadata in interest-driven business intelligence systems
US7457807B2 (en) Data migration and analysis
CN104781812A (zh) 策略驱动的数据放置和信息生命周期管理
GB2343763A (en) Databases
JP2006503357A (ja) オンライン分析処理(olap)のための方法およびシステム
Subekti et al. The 3 steps of best data warehouse model design with leaning implementation for sales transaction in franchise restaurant
CN107729500B (zh) 一种联机分析处理的数据处理方法、装置及后台设备
Bhaskara et al. Data warehouse implemantation to support batik sales information using MOLAP
US11216486B2 (en) Data retrieval apparatus, program and recording medium
Gupta et al. A Review of Data Warehousing and Business Intelligence in different perspective
Vaisman et al. Data warehouse concepts
CN118227767B (zh) 知识图谱驱动大模型的商业智能决策问答系统及方法
US20150379585A1 (en) Single Sheet Planning
Vavouras et al. A metadata-driven approach for data warehouse refreshment
CN115576940A (zh) 用于管理报表编制的方法、处理器、系统及可读存储介质
Plattner et al. The Impact of HANA on the Design of Enterprise Applications
Bog et al. Enterprise Data Management for Transaction and Analytical Processing
CN117609362A (zh) 一种数据处理方法、装置、计算机设备及存储介质
Meier et al. Postrelational Databases
Rizzi et al. Date Warehouse Design.

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant