CN117851522A - 基于电网大数据中心的数据仓库建模方法 - Google Patents

基于电网大数据中心的数据仓库建模方法 Download PDF

Info

Publication number
CN117851522A
CN117851522A CN202311849591.5A CN202311849591A CN117851522A CN 117851522 A CN117851522 A CN 117851522A CN 202311849591 A CN202311849591 A CN 202311849591A CN 117851522 A CN117851522 A CN 117851522A
Authority
CN
China
Prior art keywords
data
relationship
processed
model
relation
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.)
Pending
Application number
CN202311849591.5A
Other languages
English (en)
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.)
China Southern Power Grid Digital Platform Technology Guangdong Co ltd
Original Assignee
China Southern Power Grid Digital Platform Technology Guangdong 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 China Southern Power Grid Digital Platform Technology Guangdong Co ltd filed Critical China Southern Power Grid Digital Platform Technology Guangdong Co ltd
Priority to CN202311849591.5A priority Critical patent/CN117851522A/zh
Publication of CN117851522A publication Critical patent/CN117851522A/zh
Pending legal-status Critical Current

Links

Classifications

    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y04INFORMATION OR COMMUNICATION TECHNOLOGIES HAVING AN IMPACT ON OTHER TECHNOLOGY AREAS
    • Y04SSYSTEMS INTEGRATING TECHNOLOGIES RELATED TO POWER NETWORK OPERATION, COMMUNICATION OR INFORMATION TECHNOLOGIES FOR IMPROVING THE ELECTRICAL POWER GENERATION, TRANSMISSION, DISTRIBUTION, MANAGEMENT OR USAGE, i.e. SMART GRIDS
    • Y04S10/00Systems supporting electrical power generation, transmission or distribution
    • Y04S10/50Systems or methods supporting the power network operation or management, involving a certain degree of interaction with the load-side end user applications

Landscapes

  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

本申请涉及一种基于电网大数据中心的数据仓库建模方法、装置、计算机设备、存储介质和计算机程序产品。方法包括:获取待处理数据表;确定待处理数据表对应的数据明细表,并获取数据明细表之间的第一逻辑关系;基于第一逻辑关系,在各数据明细表之间设置逻辑关系,得到第一关系表;基于第一关系表,建立电网大数据中心的数据明细模型,并获取第一共享数据维度;从第一关系表中获取与第一共享数据维度匹配的第二关系表,并确定第二关系表对应的数据汇总表;基于数据汇总表,建立电网大数据中心的数据汇总模型,并组合数据明细模型与数据汇总模型,生成电网大数据中心的数据仓库模型。采用本方法能够高效进行数据仓库建模。

Description

基于电网大数据中心的数据仓库建模方法
技术领域
本申请涉及大数据技术领域,特别是涉及一种基于电网大数据中心的数据仓库建模方法、装置、计算机设备、存储介质和计算机程序产品。
背景技术
随着物联网与移动应用等新技术的出现,为数据价值的广泛挖掘提供了可能,目前,尤其对于电网大数据中心来说,数据已经成为了企业的一份重要生产要素和重要战略资源。而随着数据规模的快速膨胀、数据更新频率的不断提高、数据类型的日益丰富,如何将数据进行有序、有结构的存储,是对数据管理核心能力的挑战。
在相关技术中,对数据进行有序、有结构的存储一般是通过数据库来实现的。具体地,对需要存储的数据进行分类,并对数据库进行分类,并将需要存储的数据存储至对应类别的数据仓库中。如采用关系型数据库存储关系型数据,采用非关系型数据库存储非关系型数据。但是,对于电网大数据中心来说,采用数据库来存储数据的措施仍然不够高效。
发明内容
基于此,有必要针对上述技术问题,提供一种高效的基于电网大数据中心的数据仓库建模方法、装置、计算机设备、计算机可读存储介质和计算机程序产品。
第一方面,本申请提供了一种基于电网大数据中心的数据仓库建模方法,包括:
获取待处理数据表,所述待处理数据表携带至少两个不同电网大数据中心的数据;
确定所述待处理数据表对应的数据明细表,并获取所述数据明细表之间的第一逻辑关系;
基于所述第一逻辑关系,在各所述数据明细表之间设置逻辑关系,得到第一关系表;
基于所述第一关系表,建立所述电网大数据中心的数据明细模型,并获取第一共享数据维度;
从所述第一关系表中获取与所述第一共享数据维度匹配的第二关系表,并确定所述第二关系表对应的数据汇总表;
基于所述数据汇总表,建立所述电网大数据中心的数据汇总模型,并组合所述数据明细模型与所述数据汇总模型,生成所述电网大数据中心的数据仓库模型。
第二方面,本申请还提供了一种基于电网大数据中心的数据仓库建模装置,包括:
数据表获取模块,用于获取待处理数据表,所述待处理数据表携带至少两个不同电网大数据中心的数据;
明细表确定模块,用于确定所述待处理数据表对应的数据明细表,并获取所述数据明细表之间的第一逻辑关系;
关系表生成模块,用于基于所述第一逻辑关系,在各所述数据明细表之间设置逻辑关系,得到第一关系表;
第一模型建立模块,用于基于所述第一关系表,建立所述电网大数据中心的数据明细模型,并获取第一共享数据维度;
汇总表确定模块,用于从所述第一关系表中获取与所述第一共享数据维度匹配的第二关系表,并确定所述第二关系表对应的数据汇总表;
第二模型建立模块,用于基于所述数据汇总表,建立所述电网大数据中心的数据汇总模型,并组合所述数据明细模型与所述数据汇总模型,生成所述电网大数据中心的数据仓库模型。
第三方面,本申请还提供了一种计算机设备,包括存储器和处理器,所述存储器存储有计算机程序,所述处理器执行所述计算机程序时实现以下步骤:
获取待处理数据表,所述待处理数据表携带至少两个不同电网大数据中心的数据;
确定所述待处理数据表对应的数据明细表,并获取所述数据明细表之间的第一逻辑关系;
基于所述第一逻辑关系,在各所述数据明细表之间设置逻辑关系,得到第一关系表;
基于所述第一关系表,建立所述电网大数据中心的数据明细模型,并获取第一共享数据维度;
从所述第一关系表中获取与所述第一共享数据维度匹配的第二关系表,并确定所述第二关系表对应的数据汇总表;
基于所述数据汇总表,建立所述电网大数据中心的数据汇总模型,并组合所述数据明细模型与所述数据汇总模型,生成所述电网大数据中心的数据仓库模型。
第四方面,本申请还提供了一种计算机可读存储介质,其上存储有计算机程序,所述计算机程序被处理器执行时实现以下步骤:
获取待处理数据表,所述待处理数据表携带至少两个不同电网大数据中心的数据;
确定所述待处理数据表对应的数据明细表,并获取所述数据明细表之间的第一逻辑关系;
基于所述第一逻辑关系,在各所述数据明细表之间设置逻辑关系,得到第一关系表;
基于所述第一关系表,建立所述电网大数据中心的数据明细模型,并获取第一共享数据维度;
从所述第一关系表中获取与所述第一共享数据维度匹配的第二关系表,并确定所述第二关系表对应的数据汇总表;
基于所述数据汇总表,建立所述电网大数据中心的数据汇总模型,并组合所述数据明细模型与所述数据汇总模型,生成所述电网大数据中心的数据仓库模型。
第五方面,本申请还提供了一种计算机程序产品,包括计算机程序,该计算机程序被处理器执行时实现以下步骤:
获取待处理数据表,所述待处理数据表携带至少两个不同电网大数据中心的数据;
确定所述待处理数据表对应的数据明细表,并获取所述数据明细表之间的第一逻辑关系;
基于所述第一逻辑关系,在各所述数据明细表之间设置逻辑关系,得到第一关系表;
基于所述第一关系表,建立所述电网大数据中心的数据明细模型,并获取第一共享数据维度;
从所述第一关系表中获取与所述第一共享数据维度匹配的第二关系表,并确定所述第二关系表对应的数据汇总表;
基于所述数据汇总表,建立所述电网大数据中心的数据汇总模型,并组合所述数据明细模型与所述数据汇总模型,生成所述电网大数据中心的数据仓库模型。
上述基于电网大数据中心的数据仓库建模方法、装置、计算机设备、存储介质和计算机程序产品,获取待处理数据表,待处理数据表携带至少两个不同电网大数据中心的数据;确定待处理数据表对应的数据明细表,并获取数据明细表之间的第一逻辑关系;基于第一逻辑关系,在各数据明细表之间设置逻辑关系,得到第一关系表;基于第一关系表,建立电网大数据中心的数据明细模型,并获取第一共享数据维度;从第一关系表中获取与第一共享数据维度匹配的第二关系表,并确定第二关系表对应的数据汇总表;基于数据汇总表,建立电网大数据中心的数据汇总模型,并组合数据明细模型与数据汇总模型,生成电网大数据中心的数据仓库模型。整个过程中,在获取待处理数据表后,能够从逻辑关系与共享数据维度两个维度出发,对待处理数据表对应的数据明细表中所需的数据进行高效汇总,避免需要一个个对待处理数据表进行处理的情况;进一步地,对由数据明细表建立的数据明细模型、以及由数据汇总表建立的数据汇总模型直接组合,高效生成电网大数据中心的数据仓库模型。
附图说明
为了更清楚地说明本申请实施例或相关技术中的技术方案,下面将对实施例或相关技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本申请的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1为一个实施例中基于电网大数据中心的数据仓库建模方法的应用环境图;
图2为一个实施例中基于电网大数据中心的数据仓库建模方法的流程示意图;
图3为一个实施例中数据汇总表的构造流程示意图;
图4为一个实施例中电网大数据中心的数据仓库的结构示意图;
图5为一个实施例中待处理数据表在数据仓库建模中的逻辑示意图;
图6为一个实施例中基于电网大数据中心的数据仓库建模装置的结构框图;
图7为一个实施例中计算机设备的内部结构图。
具体实施方式
为了使本申请的目的、技术方案及优点更加清楚明白,以下结合附图及实施例,对本申请进行进一步详细说明。应当理解,此处描述的具体实施例仅仅用以解释本申请,并不用于限定本申请。
本申请实施例提供的基于电网大数据中心的数据仓库建模方法,可以应用于如图1所示的应用环境中。其中,终端102通过网络与服务器104进行通信。数据存储系统可以存储服务器104需要处理的数据。数据存储系统可以集成在服务器104上,也可以放在云上或其他网络服务器上。
用户在终端102界面中发出数据仓库建模请求,终端102将数据仓库建模请求向服务器104上传,服务器104获取数据仓库建模请求,基于数据仓库建模请求,向生成业务数据的源业务系统,也就是电网大数据中心的源业务系统抽取数据,得到待处理数据表,待处理数据表携带至少两个不同电网大数据中心的数据;确定待处理数据表对应的数据明细表,并获取数据明细表之间的第一逻辑关系;基于第一逻辑关系,在各数据明细表之间设置逻辑关系,得到第一关系表;基于第一关系表,建立电网大数据中心的数据明细模型,并获取第一共享数据维度;从第一关系表中获取与第一共享数据维度匹配的第二关系表,并确定第二关系表对应的数据汇总表;基于数据汇总表,建立电网大数据中心的数据汇总模型,并组合数据明细模型与数据汇总模型,生成电网大数据中心的数据仓库模型。进一步地,数据仓库模型可以以可视化的形式推送至终端102,由终端102展示至用户。
其中,终端102可以但不限于是各种个人计算机、笔记本电脑、智能手机、平板电脑、物联网设备和便携式可穿戴设备,物联网设备可为智能音箱、智能电视、智能空调、智能车载设备等。便携式可穿戴设备可为智能手表、智能手环、头戴设备等。服务器104可以用独立的服务器或者是多个服务器组成的服务器集群来实现。
在一些实施例中,如图2所示,提供了一种基于电网大数据中心的数据仓库建模方法,以该方法应用于图1中的服务器104为例进行说明。
S100,获取待处理数据表。
其中,待处理数据表携带至少两个不同电网大数据中心的数据。
具体地,用户在终端界面中发出数据仓库建模请求,终端将数据仓库建模请求向服务器上传,服务器获取数据仓库建模请求,基于数据仓库建模请求,向生成业务数据的源业务系统,也就是电网大数据中心的源头业务系统抽取数据,得到待处理数据表,待处理数据表携带至少两个不同电网大数据中心的数据。且待处理数据表是同一业务域的表格。
进一步地,服务器将待处理数据表通过抽取、洗净、以及传输的方式发送至ODS(Operational Data Store,操作数据存储)层,其中,ODS层是面向主题的数据运营层,是最接近数据源中数据的一层,数据源中的数据,可以经过抽取、洗净、以及传输后,加载入本层,ODS层也是数据仓库建模中的一部分。ODS层的数据,大多是按照源头业务系统的分类方式进行分类的。可以理解的是,ODS层是各业务域建模形成的数据模型,ODS层中存储的数据保持了业务和技术的完整性、唯一性、有效性、一致性、正确性、以及及时性,可用于指标计算、标签计算、数据挖掘等数据计算。在将数据源中的数据从源业务系统抽取时,可以基于抽取的数据进行设计分层,形成数据仓库的各个层级。
S200,确定待处理数据表对应的数据明细表,并获取数据明细表之间的第一逻辑关系。
其中,数据明细表可以是与业务有关的在线事实表,它与ODS层中数据会保持一致,在数据明细表中保存的是最细粒度的数据。其中,粒度是指数据记录中包含的细节和精度程度。在数据明细表中,只需要做简单宽表、增加编码名称、以及管理属性字段,其他非业务相关的参数表、支撑表原则上不能成为数据明细表,但是,非业务相关的表可以按照需要按天以历史拉链的方式进行增量。
具体地,在获取待处理数据表后,会对待处理数据表中的表格信息进行一定的转换,但是,待处理数据表数据不变,改变的表格信息可以是表格的字段信息。在得到待处理数据表对应的数据明细表后,还可以判断不同的数据明细表之间的第一逻辑关系,得到数据明细表之间的第一逻辑关系。
S300,基于第一逻辑关系,在各数据明细表之间设置逻辑关系,得到第一关系表。
具体地,基于数据明细表之间的第一逻辑关系,可以在各数据明细表之间设置逻辑关系,以得到各数据明细表之间设置逻辑关系后关系表,即第一关系表,第一关系表中是设置有逻辑关系的各数据明细表。
举例来说,若数据明细表A与数据明细表B中存在逻辑关系为关联关系,则可以在数据明细表A与数据明细表B之间设置关联关系,以将数据明细表A与数据明细表B关联起来,得到各数据明细表对应的第一关系表。此外,逻辑关系并不局限在两个数据明细表之间,多个数据明细表之间均可以设置逻辑关系。
S400,基于第一关系表,建立电网大数据中心的数据明细模型,并获取第一共享数据维度。
具体地,数据明细模型又可以被看作是数据明细层,基于不同的第一关系表,可以建立在电网大数据中心的数据明细层。也就是说,数据明细层中包括有若干个第一关系表。通过获取若干个待处理数据表,得到待处理数据表对应的数据明细表后,获取数据明细表之间的第一逻辑关系,得到不同的第一关系表,基于不同的关系表,建立电网大数据中心的数据明细模型,建立数据明细模型是指建立数据仓库中数据明细层。数据明细层中只保存了最细粒度的数据,可以对数据明细层中的第一关系表进行轻度汇总。此处的轻度汇总,可以是进行低粒度汇总。在进行轻度汇总之前,需要获取第一共享数据维度。
进一步地,第一共享数据维度是在公共维度表中获取的,公共维度表包括但不限于在线表与拉链表等,如,可以按照业务域从数据明细表中全量加载维度表至公共维度表中,也可以以历史拉链表的方式增量加载。公共维度表可以支撑电网大数据中心的数据仓库建模,为各数据表的聚合与分组提供条件。进一步地,共享数据维度是在电网大数据中心的数据仓库建模时,每个步骤均能够使用的共享数据维度,且共享数据维度不止一个,每个共享数据维度可以对应一个共享数据维度表。举例来说,共享数据维度可以包括时间维度与单位维度等,在共享数据维度为日期维度时,可以建立共享数据维度对应的日期共享维度表,用于识别工作日和节假日,且在数据仓库建模时可以关联该日期共享维度表,即可分维度算出工作日或节假日的数据有多少。同理,在共享数据维度为单位维度时,此时,可以建立一个有A地、B地等地方维度的表,与数据表关联时即可算出A地、B地的数据分别有多少。
S500,从第一关系表中获取与第一共享数据维度匹配的第二关系表,并确定第二关系表对应的数据汇总表。
具体地,从第一关系表中获取与第一共享数据维度匹配的第二关系表,也就是说,可以从第一关系表中获取与第一共享数据维度匹配的数据,并通过与第一共享数据维度匹配的数据,形成第二关系表。进一步地,可以将第二关系表进行转换,得到第二关系表对应的数据汇总表。也就是说,数据汇总表可以结合第一共享数据维度与数据明细表得到,能够形成原子粒度的宽表与指标库表,并提供全网可复用和共享的模型。
举例来说,若第一共享数据维度为日期共享维度表,则可以从第一关系表中获取与日期维度有关的数据,并基于与第一关系表中与日期维度有关的数据,形成新的关系表,也就是第二关系表。
S600,基于数据汇总表,建立电网大数据中心的数据汇总模型,并组合数据明细模型与数据汇总模型,生成电网大数据中心的数据仓库模型。
其中,数据汇总模型可以称为是数据汇总层,数据汇总层是指通过业务主题对数据明细层的数据进行最细粒度的轻度汇总和聚合。数据汇总模型可以为上层提供可复用、减少重复开发,提高效率。
具体地,电网大数据中心的数据仓库模型包括数据明细模型与数据汇总模型,也就是说,电网大数据中心的数据仓库包括数据明细层与数据汇总层,在对数据仓库进行建模时,需要对数据明细层与数据汇总层一起建模。在对数据明细层建模时,是通过待处理数据表对应的第一关系表建立的,而在对数据汇总层建模时,是通过第二关系表对应的数据汇总表建立的,其中,第二关系表由第一关系表得到。
进一步地,对由数据明细表建立的数据明细模型、以及由数据汇总表建立的数据汇总模型直接组合,生成电网大数据中心的数据仓库模型。数据仓库模型即是数据仓库层,但是,整个数据仓库中不仅包括数据仓库层,还可以包括ODS层与数据集市层。
上述基于电网大数据中心的数据仓库建模方法中,获取待处理数据表,待处理数据表携带至少两个不同电网大数据中心的数据;确定待处理数据表对应的数据明细表,并获取数据明细表之间的第一逻辑关系;基于第一逻辑关系,在各数据明细表之间设置逻辑关系,得到第一关系表;基于第一关系表,建立电网大数据中心的数据明细模型,并获取第一共享数据维度;从第一关系表中获取与第一共享数据维度匹配的第二关系表,并确定第二关系表对应的数据汇总表;基于数据汇总表,建立电网大数据中心的数据汇总模型,并组合数据明细模型与数据汇总模型,生成电网大数据中心的数据仓库模型。整个过程中,在获取待处理数据表后,能够从逻辑关系与共享数据维度两个维度出发,对待处理数据表对应的数据明细表中所需的数据进行高效汇总,避免需要一个个对待处理数据表进行处理的情况;进一步地,对由数据明细表建立的数据明细模型、以及由数据汇总表建立的数据汇总模型直接组合,高效生成电网大数据中心的数据仓库模型。
在一些实施例中,通过对数据仓库进行分层建模,能够从以下四个方面对相关技术进行一定程度的优化:
1、访问性能的优化:建立数据模型并进行分层管理,能够快速查询所需的数据,减少数据I/O的吞吐。
2、数据成本的优化:建立数据模型并进行分层管理,减少不必要的数据几余,实现计算结果的复用,降低大数据系统中的存储成本和计算成本。
3、使用效率的优化:同一业务类型/场景,复用同一个数据模型,减少用户重新梳理业务次数,改善用户使用数据的体验,提高使用效率。
4、数据质量的优化:按业务主题建立统一数据仓库模型,改善数据统计口径的不一致性,减少数据计算错误的可能性,提供高质量的、一致的数据访问平台。
在一些实施例中,确定待处理数据表对应的数据明细表,包括:
获取待处理数据表对应的第一预设字段规则;基于第一预设字段规则,对待处理数据表进行更新,得到待处理数据表的数据明细表。
具体地,在需要根据待处理数据表生成数据明细表,并由数据明细表建立数据明细模型时,可以首先获取要建立的数据明细模型中的预设字段规则,每个待处理数据表有不同的预设字段规则,预设字段规则只是对字段的基础规则进行定义,如定义编码规则、键规则、以及命名规则等,并未定义数据字段的具体值或字段对应的具体数值。
进一步地,基于第一预设字段规则,对待处理数据表进行更新,如对待处理数据表设置编码、设置键、以及更新命名等,使得待处理数据表成为规范化的数据,得到待处理数据表的数据明细表,数据明细表是设置了编码字段、键、以及更新了命名的表。
本实施例中,通过采用待处理数据表对应的第一预设字段规则,能够对待处理数据表进行高效的更新,避免需要一个个对待处理数据表进行更新,实现了待处理数据表的数据明细表,提高了对数据明细层的建模效率。
在一些实施例中,确定第二关系表对应的数据汇总表,还包括:
获取第二关系表对应的第二预设字段规则;基于第二预设字段规则,对第二关系表进行更新,得到第二关系表对应的数据汇总表。
具体地,在建立数据明细模型后,可以继续建立数据汇总模型。在建立数据汇总模型时,需要得到数据汇总表。也就是说,首先,需要获取第二关系表对应的第二预设字段规则,同样地,每个第二关系表有不同的预设字段规则,预设字段规则只是对字段的基础规则进行定义,如定义编码规则、键规则、以及命名规则等,并未定义数据字段的具体值或字段对应的具体数值。
进一步地,基于第二预设字段规则,对第二关系表进行更新,如对第二关系表设置编码、设置键、更新命名等,得到第二关系表对应的数据汇总表。
本实施例中,通过采用第二预设字段规则,能够对第二关系表进行高效的更新,避免需要一个个对第二关系表进行更新,得到了第一关系表的数据汇总表,提高了对数据汇总层的建模效率。
在一些实施例中,在获取第一共享数据维度时,获取的共享数据维度为至少一种数据维度,且获取的共享数据维度是围绕业务过程的数据维度,即可以通过共享数据维度对数据明细表进行业务上的划分。
如图3所示,为数据汇总表的一个构造流程。数据汇总表可以是聚合轻度汇总表,也可以是多维明细宽表。首先,可以选取需要进行分析决策的业务过程,在选择业务过程时,可以从业务域、数据域、数据主题、依次自上而下划分到业务过程。其中,数据域是面向业务分析,将业务过程或者维度进行抽象集合,业务过程可以概况为一个个不可拆分的行为事件。在业务过程之下,可以定义指标,如可以定义维度,维度是指度量的环境,例如买家下单事件中买家是维度;也可以定义原子指标,原子指标是基于某一个业务事件行为下的度量,是业务定义中不可以在拆分的指标,是具有明确业务含义的名词,如支付金额。基于维度和原子指标,可以得到最细粒度的业务数据宽表,也就是多维明细宽表。
在图3中,还可以确定修饰词类,修饰词类包括若干修饰词,其中,修饰词是指除了统计维度以外指标的业务场景限定抽象,如在日志域的访问终端类型下有修饰词:电脑端、无线端等;并将修饰词类与统计周期结合,得到按照一定周期聚合汇总的宽表,即聚合轻度汇总表。进一步地,还可以拆分出维度表,维度包括维度属性,维度表可以作为共享数据维度,对共享数据维度进行维护,共享数据维度中汇集了全域维度的属性宽表。也就是说,在识别、分析业务过程的基础上,理清关注的数据项、指标,拆分出统计周期、维度、度量,并确认数据粒度,可以得到数据汇总表,并建立数据汇总层。
更进一步地,本申请还对数据汇总表获取过程中的数据主题进行一定的设计,其中,数据主题提供模型的高阶视图,是类的逻辑分组。根据业务要求将类组织成一些独立完整的领域,每个主题域对应某一领域所涉及的类对象,并在较高层次上对该领域内数据进行完整一致的描述。数据主题扩展可以根据客观对象、业务关注点定义新的数据对象范围。数据主题设计是从业务角度对数据的组织形式进行规范,数据主题域一般按照业务层级展开进行分层。
在数据仓库建模过程中,数据主题包括:1、一级主题域:简称主题域,原则上不进行调整;2、二级主题域:又称子域,对主题域进行细化,原则上是业务中完整的业务流程或核心的对象,进行子域设计时应明确该域下对应的业务流程或对象,由于数据仓库面向在线分析过程,因此也可以通过识别分析主题,再对联系紧密的主题进行汇总的方式描述子域;3、数据仓库三级主题域:原则上不进行三级及更细颗粒度的主题域设计,过多的层级不利于数据的查找、入库、分析应用开发等工作;4、包:主题域进一步划分为一个或者多个包。包是将相关模型元件分组的通用方法,无特殊语义,包的划分是为了使模型更易于设计、理解与查看。类可以持有越过许多包边界的关联,每一个应用系统使用多个包中所表示的信息。
此外,定义数据主题的原则包括:同一主题下由相关性强的概念或内容聚合而成;同一层级的主题域具有互斥性,上一级和下一级是父子关系;数据主题对应的业务域之间需要建立关联关系。
在一些实施例中,在确定第二关系表对应的数据汇总表后,还包括:
获取第二逻辑关系;基于第二逻辑关系,在各第二关系表之间设置逻辑关系,得到第三关系表,并获取第二共享数据维度;从第三关系表中获取与第二共享数据维度匹配的第四关系表,并基于第四关系表,得到待处理数据表在数据集市层对应的集市表。
其中,第二逻辑关系为不同待处理数据表对应的第二关系表之间的逻辑关系。
具体地,在构建多维明细宽表和聚合轻度汇总表,维护公共维度表后,即构建数据汇总层后,可以再次汇总数据汇总层中的数据表,生成业务宽表,也就是数据集市层中的集市表。也就是说,数据集市层的集市表主要是对数据汇总层中的数据汇总表高度汇总生成的。集市表直接面向应用,在一些情况下,集市表也可以从原子宽表、维度表、数据明细表中加工宽表,支撑前端决策分析展示。其中,原子宽表是源端业务系统中的表。
在对数据汇总表进行高度汇总时,需要先将数据汇总层中的数据汇总表之间设置第二逻辑关系,使得每个表不是孤立的,从而可以实现高效的高度汇总。其中,第二逻辑关系是在高度汇总时每个第二关系表之间的逻辑关系,基于第二逻辑关系,在各第二关系表之间设置逻辑关系,可以得到第三关系表。
进一步地,获取第二共享数据维度,基于第二共享数据维度对第三关系表进行高度汇总,从第三关系表中获取与第二共享数据维度匹配的第四关系表,将第四关系表作为待处理数据表在数据集市层对应的集市表,也就是业务宽表。
本实施例中,通过从逻辑关系和共享数据维度两方面出发,对第二关系表进行高效且准确的汇总。也就是说,基于第二逻辑关系,能够对第二关系表之间设置逻辑关系,使得获取维度匹配时的处理数据更为准确;且通过第二共享数据维度来进行数据汇总的方式更为高效。
在一些实施例中,基于第四关系表,得到待处理数据表在数据集市层对应的集市表包括:
获取第三预设字段规则;基于第三预设字段规则,对第四关系表进行更新,得到待处理数据表在数据集市层的集市表。
其中,第三预设字段规则为各第四关系表在数据集市层对应的规则。
具体地,在得到集市表时,不仅需要对第三关系表进行汇总,还需要将通过维度聚合后的第四关系表进行字段规则的转换,具体可以通过获取第三预设字段规则得到。可以理解的是,待处理数据表在数据明细层中需要进行一次转换,更新在数据明细层中的物理结构表,即得到数据明细表,对数据明细表之间设置逻辑关系,得到第一关系表,并基于第一数据共享维度提取第一关系表;数据明细表在数据汇总层中需要进行一次转换,更新在数据汇总层中的物理结构表,即得到数据汇总表,将数据汇总表关联,得到第三关系表,并对第三关系表与第二数据共享维度搭配,得到第四关系表,将第四关系表传到数据集市层;第四关系表在数据集市层中需要进行一次转换,更新在数据集市层中的物理结构表,得到集市表。
也就是说,对第四关系表进行更新实质上是对第四关系表的物理结构进行更新,即基于第三预设字段规则,对第四关系表的物理结构进行更新,得到待处理数据表在数据集市层的集市表,预设字段规则包括但不限于编码规则、键规则、以及命名规则等。
本实施例中,通过第三预设字段规则,能够准确对第四关系表进行更新,进而准确得到待处理数据表在数据集市层的集市表。
在一些实施例中,第一预设字段规则、第二预设字段规则、以及第三预设字段规则包括待处理数据表中字段分别对应的预设数据类型规则、数据类型对应的值域规则、编码规则、约束规则、键规则、以及命名规则;
第一逻辑关系与第二逻辑关系包括关联关系;或,第一逻辑关系与第二逻辑关系包括关联关系和附加关系,附加关系包括聚合关系、组合关系、以及泛化关系中的至少一种。
具体地,首先,对于逻辑关系来说,在各表之间设置逻辑关系可以认为是建立各表之间的概念模型,也就是说,在各数据明细表之间设置第一逻辑关系,是建立在各数据明细表之间的概念模型;在各第二关系表之间设置第二逻辑关系,是建立在各第二关系表之间的概念模型。
概念模型设计的要求是设计人员在最初的数据库设计阶段将精力集中在数据之间的联系上,而不用同时关注数据的底层细节(如所用的计算机系统的特性以及数据库管理系统的特性)。其主要的在于分析数据之间的联系,是用户对数据存储的一种高度抽象,反应的是用户的一种业务层面的综合信息。进一步地,概念模型可以按一级数据主题、二级数据主题和包进行组织。
建立概念模型,也就是在数据表之间设置逻辑关系。在本申请中,可以将数据表作为一个实体,也就是说本申请中的数据实体是对应数据仓库中实际存储的表结构。在设置逻辑关系时,应当至少包含以下步骤:
A、识别数据实体。具体地,数据实体的识别是概念模型设计关键的部分,数据仓库中的概念模型与业务系统的概念模型不同,数据仓库的概念模型设计需要综合考虑业务特性、访问特性、以及计算特性,并参考采集到的数据实体得到。举例来说,数据仓库中的数据实体可以以矩形框的形式表示,且可以在矩形框中注明矩形名称。
B、明确实体间逻辑关系。具体地,实体间逻辑关系主要描述数据结构内数据间的语法、词义联系、制约和依存关系、以及数据动态变化的规则,以保证数据的正确性、有效性和相容性,如一个具体场景下某个项目的各预算表之间的关系表,可以包括设备信息、设备维护预算、人力资源计划预算、财务预算、项目投资预算、汇集科目预算、以及其他业务预算等,且各表之间设置有逻辑关系。
为充分说明实体间关系可以分为多种,本申请仅对关联关系强制要求,即两个表之间的逻辑关系中至少需要包含关联关系。具体地:
1)、关联关系:是两个数据实体对应实例之间的数量关系,表示目标实体和源实体有关系。角色为目标实体的名字,可以带或不带动词。关联是实体之间的一种概念上的联系。每一种关联都有两个角色。每一个角色表示了关联中的一种方向,表示目标类角色和源角色有关系。比如,表A与表B之间存在关联关系,其中,表A可以是源实体,也可以是目标实体。
每个角色还有基数,用来表示有多少对象可以参加到给定的关系中。其中,基数在关联的两端都有相应的显示。关联关系通过关联两端是集聚为一条直线或发散成多条直线,可以用来表示关联的数据实体之间的一对一、一对多、多对一和多对多关联。但是,关联关系没有进一步说明关联的两个实体是否有一方可以不存在,即“零对一”或者“零对多”的情况,如果业务中对一个数据实体的空值有明确要求,那在概念模型设计时应当考虑此种情况,而聚合和组合关系就是针对这种情况的进一步设计。
基数在关联的两端都有相应的显示,举例来说,一个分接头调节器对象可以有0、1或者多个分接头计划,而一个分接头计划对象必须属于1个分接头调节器对象。
2)泛化关系:泛化关系是一种继承关系,表示一般与特殊的关系,它指定了子类如何特化父类的所有特征和行为。例如:配变、主变都是变压器的子类,配变和主变有共同的属性从变压器继承。泛化是普遍类与具体类之间的一种关系,具体类在普遍类基础上附加信息,泛化关系可以使具体类从它上层普遍类继承属性和关系。进一步地,泛化关系用半圆表示,箭头指向被继承的一方,即父对象。如一个实际应用场景下泛化关系为例,断路器是保护开关更为具体的类型,保护开关是开关更为具体的类型,开关是导电设备更为具体的类型,导电设备又是设备更为具体的类型,设备是电力系统资源更为具体的类型。变压器是设备的另一个具体类型。
3)聚合关系:聚合关系表明数据实体与数据实体之间的关系是一种整体和部分的关系,整体类由部分类“构成”或“包含”部分类,而部分类是整体类的“一部分”,而且部分类可以离开整体类而单独存在。如,车和轮胎是整体和部分的关系,轮胎离开车仍然可以存在。聚合关系是关联关系的一种特殊情况,是强的关联关系;关联和聚合在语法上无法区分,因此必须考察具体的逻辑关系。进一步地,聚合关系双方的实体有一方是可以不存在的,可以不存在的一方用空心圆标识。
4)组合关系:组合关系是整体与部分的关系,但部分不能离开整体而单独存在。例如:公司和部门是整体和部分的关系,没有公司就不存在部门。组合关系是关联关系的一种,是比聚合关系还要强的关系,要求普通的聚合关系中代表整体的对象负责代表部分的对象的生命周期。进一步地,组合关系双方的实体有一方是当对方存在时才存在的,被依赖一方用竖线标识,举例来说,每条应收记录可能对应一张或多张发票,但是,有应收记录不代表一定会有发票;每张发票必须对应有且仅有一条应收记录,有发票就代表一定会有应收记录。
而预设字段规则是在关系表的基础上,考虑各种具体的技术实现因素,进行数据仓库的物理体系结构设计,真正实现数据在数据仓库中的存放。进一步地,在物理实现上的考虑,可能会导致基于预设字段规则对关系表进行修改。
其中,预设字段规则至少包括待处理数据表中字段分别对应的预设数据类型规则、数据类型对应的值域规则、编码规则、约束规则、键规则、以及命名规则。
具体来说,1、预设数据类型规则:采用域的方式规范属性的数据类型和值域,域是数据模型中属性全面定义的一部分,它定义了与“属性取值”相关的业务概念层次的内容,而具体实现、存储层面的内容暂不属于域的定义范畴。为了使定义清晰明确,从概到细按照“域组/域”对域体系进行定义。将数据分成十一大域组,分别为:编码类、代码类、命名类、指示器类、文本类、金额类、数值类、百分比类、日期类、时间类、日期时间类。根据属性取值的多样性将每个域组划分为多个域。
2、与数据类型对应的值域规则:值域明确该字段允许的数值范围区间,一般采用域组和域的方式来规范约束数据类型和值域。域是数据模型中属性全面定义的一部分,它定义了与“属性取值”相关的业务概念层次的内容,而具体实现、存储层面的内容暂不属于域的定义范畴。
3、编码规则:字段代码是对表中的属性(字段)编写相应的英文字符编码。
4、约束规则:包括空值约束与默认值。其中,空值约束是指基于业务要求,对字段值是否为空进行设计,空值约束与概念模型设计时的组合关系及聚合关系有关。默认值是指当该字段不允许为空时填充的默认值,字段默认值并非业务上对于空值和零值的处理规则。
5、键规则:包括物理主键、自然键、代理键、物理外键、以及分布键。
5.1物理主键是指各个表的物理主键,通常以逻辑模型中所有维度属性作为联合主键,同时要考虑查询性能,选择被访问最多的符合主键条件的字段作为主键,其他情况参考代理键。
5.2自然键是指由现有实体存在的属性组成的键值,在业务概念上是唯一的;代理键是指不具有业务含义的键值表示数据唯一,如使用代理键需要说明代理键的编码规则。对于自然键,它不需要引入一个新的非自然列,自然键与业务直接紧密耦合,透过自然键就可以清楚明确业务上唯一的标准。但是,自然键由于直接对接业务属性值,当源端数据变更时,可能导致属性发生变更,唯一键可能就要重新指定。
5.3代理键可以区别于自然键,对于代理键,需要引入一个新的非自然列,它不与业务直接耦合,更容易维护。当源端数据发生变更时,不会对它产生影响。从某种意义上讲代理键可以看作是直接物理存储唯一性的键值。但其自身由于与业务没有直接耦合,通常是不可读的,无法通过一个代理键值直接定位出数据的业务含义。在实际情况中,可以对自然键与代理键进行自定义选择。举例来说,对于自然人唯一性的判别,可以以姓名+身份证件类型+身份证件号码为主唯一标识,但实际我们存储的时候并没有采用这三个属性字段作为唯一键,而是采用了自增序列的代理键,登记序号作为唯一键。
5.4物理外键是指针对主键的调整,对逻辑模型的外键进行调整。
5.5分布键是指:如数据仓库底层数据库为分布式并行处理架构,每个表数据均匀分布在各个数据节点才能充分发挥分布式并行处理架构的处理优势,特定类型以分布键确定数据如何分布,每个物理表必须选取作为分布键的字段,选择数据值域离散的字段作为分布键。具体来说,分布键选择原则:
5.5.1数据明细表必须指定分布键,选择值域离散分布的字段。
5.5.2如果存在业务自带的分布键,就选择业务分布键。如果没有业务分布键,就必须使用随机分布,不能使用系统默认。
5.5.3分布键的选择不要选择经常用于WHERE条件中的字段做分布键。
5.5.4不要使用日期或时间字段做分布键。
5.5.5分布键和分区键不能使用同一字段。
5.5.6对经常执行JOIN操作的大表,优先考虑使用关联字段做分布键。
5.5.7使用业务分布键在数据加载以后需要进行监控,查看数据的分布情况,避免出现数据倾斜,带来性能问题。
除上述强制要求的设计内容外,根据设计需要以下内容进行参考:
5.5.8引入数据存储所需要素:数据实体进行物理化工作,最终需要在数据存储环境上实现该数据结构,因此需要增加数据存储有关的要素,例如针对关系数据库的表空间、分区键等。
5.5.9引入性能优化所需要素:叠加数据库非功能性属性,增加诸如索引、视图、分库分表、数据复制、读写分离等要素表达。
5.5.10引入数据处理所需要素:落地后的数据库表需要被数据仓库数据加工任务处理所使用,因此需要增加与处理有关的属性字段,例如处理流水号,处理日期等。
在通过预设字段规则对表进行更新时,得到的是物理数据表,物理数据表的部分可以继承逻辑数据表,如,表名和字段,每个物理数据模型设计主要为实体描述规范,以表格形式展开每个实体,也就是说,物理数据模型实质上是表格。实体描述规范对数据实体内部进行设计,即对表结构进行设计,举例来说,在物理模型设计阶段可以按照如下表1所示的格式设计实体。
表1物体模型设计格式实例
6、数据仓库中数据表内包括通用字段和个性化业务字段两部分。通用字段采用统一命名规则。如表2所示,可以看作是一个具体应用实例中各字段的命名规则。
表2一个具体应用实例中各字段的命名规则
/>
由上表2可得,通用字段中包括主键、时间维度、机构维度、技术信息、以及维度组字段等,其中,主键采用代理键方式生成序号,也就是自增序号;时间维度:遵循“主题词_修饰词_类词”的命名规则,参照标准词根统一命名,如:实际完成日期-FACT_FINISH_DATE、电费月份-OWE_MON,在有多个业务时间的需要声明多个;机构维度是统一命名,基于源表使用组织维度中间表进行加工转换后的人资组织机构字段。技术信息中包括的插入时间是作业调度生成目标库数据的时间,开发人员是开发数据作业函数名称,省编码是数据加载来源分省编码,若对技术信息如果设计拉链表,则需增加tw_start_time、tw_end_time、tw_status_flag三个字段;维度组字段对应数据项字典的维度分类,为枚举类型,可以没有维度组字段,且维度组字段需要以维度值id、维度编码、维度值名称成对设计,根据需要可以有多组。
而其他业务字段属于个性化信息,可以根据数据仓库建模的需要设计业务字段,业务字段是来源于源表的非时间、组织字段的其他业务字段。字段取值为非中文的字段,需有对应的中文取值字段。
7、预设字段规则还包括命名规则,设计命名规范可以约束数据仓库设计阶段的命名,以命名清晰可理解,命名清晰、一致,命名需易于下游的理解和使用,做到见表识意为目标。命名规范主要用来规范数据对象的命名,主要提供命名规范的原则、数据主题、实体、字段等命名规则等。命名规范是数据对象在命名时需要遵从的构词结构、词源清单等规范,主要包括:主题域/包/实体/字段命名规则、基本词清单、类词清单等。
7.1主题域命名规范:包括中文名命名规范与代码规范。其中,中文名命名规范中包括编号、名称及描述。主题域名称以中文简洁概括主题的内容、范围。主题子域和包的命名方式相同,以2-6个汉字为宜。
代码规范中包括命名结构与码值规范,在命名结果中包括编码、代码、主题域编码、子域编码、以及包编码等。码值规范中包括编码、代码、以及缩写,编码需要两位数字顺序码,子域在主题域编码后跟“-”和子域编码数字。代码需要1-3个英文单词,首字母大写。缩写需要英文单词中两个字母大写。如,主题域可以被命名为:02_Human_Resource、01-02_Client_Marketing、或04-02-05_Purchase_Request等。
7.2数据库命名规范:包括中文名命名结构与码值规范。命名结构包括主题段+业务段+技术段。在码值规范中,主题段的主题域需要缩写;业务段由小写英文以及下划线组成,说明数据内容;技术段在不同库下不同,如业务库不需要技术段;备份库内的技术段为正式库名_yyyymmdd_bak;临时库的技术段为数据集市层p。举例来说,在正式数据命名时,可以使用小写英文以及下划线组成,尽量说明包含的数据内容,可以是数据主题。比如:HR_web_19floor_netHR_web_car。而在备份数据库名命名中,可以使用正式库名加上备份时间组成,如:HR_web_19floor_net_20070403_bak、或HR_web_car_20070403_bak。
7.3数据库模式命名规范:模式是一组对象的集合,比如表、视图、存储过程、索引,数据仓库模型命名规范,依据数据仓库分层、主题域命名,命名规范:分层前缀+数据域+<单位>,具体如下表3所示:
表3数据库模式命名规范
7.4数据库表命名规范:数据仓库及数据集市层表的命名规范,依据数据中数据仓库分层、主题域命名及业务实体特征进行数据表的命名,表名使用英文小写字母,单词之间用下划线分开,长度不超过80个字符,命名规范:分层前缀_<数据域_数据主题/分析主题>_实体描述_后缀,如下表4所示:
表4数据库表命名规范
/>
7.5视图命名规范:通常视图定义不做聚合操作,只做简单的字段范围扩展。命名规范如下:普通视图命名规范:V_<分层前缀_数据域>_实体描述。其中,“<>”表示可选可不选,结合实际情况确定;物理视图命名规范:MV_<分层前缀_数据域>_实体描述。其中,<>表示可选可不选,结合实际情况确定。
7.6、字段命名规范:字段的英文名和注释要能表现具体的业务意义,不能采用数字编号,命名遵循“主题词_修饰词_类词”。字段名大小写建议使用大写,如数据库对大小写敏感则必须使用小写。例如:检查日期对应的命名为:CHECK_DATE。
7.7主键命名规范:主键的命名格式为:PK_表名字段。如:PK_DJ_ZRR;同时应该指定主键使用索引存储表空间。
7.8外键命名规范:外键的命名格式为:FK_从表名字段_主表名字段。
7.9索引命名规范:IDX_表名(可以缩写)_字段名,同时指定存储的索引表空间,对于本地分区索引需要增加local属性。
本实施例中,通过对预设字段规则和逻辑关系进行定义设计,能够对数据仓库的建模过程中的信息进行规范化,使得后续能够通过逻辑关系快速的查询所需数据,减少数据输入输出的吞吐,且能够减少不必需要的数据冗余,使得用户的使用更加便利。
在一些实施例中,本申请中的建模可以理解为:对数据进行抽取、对数据进行分层设计、以及对命名进行设计,其中,对数据仓库进行分层设计包括对模型进行设计和对存储进行设计。其中,模型设计是指从业务维度出发明确数据应当存在哪里、以什么形式(如表结构与库表关系等)存储,模型设计要结合业务情况和来源数据情况,业务上要有前瞻性的保证模型能涵盖所有业务需要,当前可能尚未有对应的系统数据支撑。从来源数据情况出发,主要是对来源表进行拆分和组合,此时要与业务能够对应,也要考虑到业务对数据的访问特征进行性能的优化设计。存储设计是指模型设计最细的颗粒度是数据实体,数据实体对应数据仓库实际存储中的表结构,存储设计则是从数据仓库性能和健壮性角度进一步明确数据仓库中具体的逻辑存储单元,如数据库、数据表、以及数据字段等,一个数据库对应若干个数据表,一个数据表对应若干个数据字段。
在一些实施例中,如图4所示,电网大数据中心的数据仓库中不仅包括数据明细层与数据汇总层,还包括ODS层与数据集市层,数据明细层与数据汇总层构成电网大数据中心的数据仓库层。在建立电网大数据中心的数据仓库时,还会有公共维度表的参与。数据明细层中存在数据明细表,也就是业务事实表,是由ODS层中的数据转换而来,对业务事实表采用逻辑关系与公共维度进行双重处理,进行轻度汇总,得到数据汇总层中的数据汇总表。再对数据汇总表采用逻辑关系与公共维度进行双重处理,进行高度汇总,得到数据集市层中的集市表,也就是业务宽表。
在一个实施例中,基于电网大数据中心的数据仓库建模方法包括:
1、待处理数据表的抽取:通过CDC(change data capture,变化数据捕捉)技术将数据从源端业务系统抽取数据库数据到数据仓库,如下图5中抽取“客服工单、抢修业务信息、答复客服记录、投诉业务信息”这四个待处理数据表。
2、设计概念模型。在每层的建模中,都需要确定当前层中各数据表之间的逻辑关系,并基于逻辑关系,在各数据表之间设置逻辑关系,得到关系表。
3、设计物理模型。物理模型设计也分为数据明细层、数据汇总层、以及数据集市三层的物理模型设计,如下图5,抽取四个表,成为数据明细层中的数据明细表,四个表之间关联,搭配维度,轻度汇总成数据汇总层中的数据汇总表,再根据业务需求对数据汇总表高度汇总成数据集市层中的集市表。且也可以是对数据汇总表进行关联后再进行搭配维度进行高度汇总成为集市表。
应该理解的是,虽然如上所述的各实施例所涉及的流程图中的各个步骤按照箭头的指示依次显示,但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明,这些步骤的执行并没有严格的顺序限制,这些步骤可以以其它的顺序执行。而且,如上所述的各实施例所涉及的流程图中的至少一部分步骤可以包括多个步骤或者多个阶段,这些步骤或者阶段并不必然是在同一时刻执行完成,而是可以在不同的时刻执行,这些步骤或者阶段的执行顺序也不必然是依次进行,而是可以与其它步骤或者其它步骤中的步骤或者阶段的至少一部分轮流或者交替地执行。
基于同样的发明构思,本申请实施例还提供了一种用于实现上述所涉及的基于电网大数据中心的数据仓库建模方法的基于电网大数据中心的数据仓库建模装置。该装置所提供的解决问题的实现方案与上述方法中所记载的实现方案相似,故下面所提供的一个或多个基于电网大数据中心的数据仓库建模装置实施例中的具体限定可以参见上文中对于基于电网大数据中心的数据仓库建模方法的限定,在此不再赘述。
在一些实施例中,如图6所示,提供了一种基于电网大数据中心的数据仓库建模装置,包括:数据表获取模块100、明细表确定模块200、关系表生成模块300、第一模型建立模块400、汇总表确定模块500和第二模型建立模块600,其中:
数据表获取模块100,用于获取待处理数据表,待处理数据表携带至少两个不同电网大数据中心的数据;
明细表确定模块200,用于确定待处理数据表对应的数据明细表,并获取数据明细表之间的第一逻辑关系;
关系表生成模块300,用于基于第一逻辑关系,在各数据明细表之间设置逻辑关系,得到第一关系表;
第一模型建立模块400,用于基于第一关系表,建立电网大数据中心的数据明细模型,并获取第一共享数据维度;
汇总表确定模块500,用于从第一关系表中获取与第一共享数据维度匹配的第二关系表,并确定第二关系表对应的数据汇总表;
第二模型建立模块600,用于基于数据汇总表,建立电网大数据中心的数据汇总模型,并组合数据明细模型与数据汇总模型,生成电网大数据中心的数据仓库模型。
在一些实施例中,明细表确定模块200还用于获取待处理数据表对应的第一预设字段规则;基于第一预设字段规则,对待处理数据表进行更新,得到待处理数据表的数据明细表。
在一些实施例中,汇总表确定模块500还用于获取第二关系表对应的第二预设字段规则;基于第二预设字段规则,对第二关系表进行更新,得到第二关系表对应的数据汇总表。
在一些实施例中,基于电网大数据中心的数据仓库建模装置中还包括集市表生成模块,集市表生成模块用于获取第二逻辑关系,第二逻辑关系为不同待处理数据表对应的第二关系表之间的逻辑关系;基于第二逻辑关系,在各第二关系表之间设置逻辑关系,得到第三关系表,并获取第二共享数据维度;从第三关系表中获取与第二共享数据维度匹配的第四关系表,并基于第四关系表,得到待处理数据表在数据集市层对应的集市表。
在一些实施例中,集市表生成模块还用于获取第三预设字段规则,第三预设字段规则为各第四关系表在数据集市层对应的规则;基于第三预设字段规则,对第四关系表进行更新,得到待处理数据表在数据集市层的集市表。
在一些实施例中,第一预设字段规则、第二预设字段规则、以及第三预设字段规则包括待处理数据表中字段分别对应的预设数据类型规则、数据类型对应的值域规则、编码规则、约束规则、键规则、以及命名规则;第一逻辑关系与第二逻辑关系包括关联关系;或,第一逻辑关系与第二逻辑关系包括关联关系和附加关系,所述附加关系包括聚合关系、组合关系、以及泛化关系中的至少一种。
上述基于电网大数据中心的数据仓库建模装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中,也可以以软件形式存储于计算机设备中的存储器中,以便于处理器调用执行以上各个模块对应的操作。
在一些实施例中,提供了一种计算机设备,该计算机设备可以是服务器,其内部结构图可以如图7所示。该计算机设备包括处理器、存储器、输入/输出接口(Input/Output,简称I/O)和通信接口。其中,处理器、存储器和输入/输出接口通过系统总线连接,通信接口通过输入/输出接口连接到系统总线。其中,该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质和内存储器。该非易失性存储介质存储有操作系统、计算机程序和数据库。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的数据库用于存储待处理数据表等数据。该计算机设备的输入/输出接口用于处理器与外部设备之间交换信息。该计算机设备的通信接口用于与外部的终端通过网络连接通信。该计算机程序被处理器执行时以实现一种基于电网大数据中心的数据仓库建模方法。
本领域技术人员可以理解,图7中示出的结构,仅仅是与本申请方案相关的部分结构的框图,并不构成对本申请方案所应用于其上的计算机设备的限定,具体的计算机设备可以包括比图中所示更多或更少的部件,或者组合某些部件,或者具有不同的部件布置。
在一些实施例中,还提供了一种计算机设备,包括存储器和处理器,存储器中存储有计算机程序,该处理器执行计算机程序时实现上述各方法实施例中的步骤。
在一些实施例中,提供了一种计算机可读存储介质,其上存储有计算机程序,该计算机程序被处理器执行时实现上述各方法实施例中的步骤。
在一些实施例中,提供了一种计算机程序产品,包括计算机程序,该计算机程序被处理器执行时实现上述各方法实施例中的步骤。
需要说明的是,本申请所涉及的用户信息(包括但不限于用户设备信息、用户个人信息等)和数据(包括但不限于用于分析的数据、存储的数据、展示的数据等),均为经用户授权或者经过各方充分授权的信息和数据,且相关数据的收集、使用和处理需要符合相关规定。
本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程,是可以通过计算机程序来指令相关的硬件来完成,所述的计算机程序可存储于一非易失性计算机可读取存储介质中,该计算机程序在执行时,可包括如上述各方法的实施例的流程。其中,本申请所提供的各实施例中所使用的对存储器、数据库或其它介质的任何引用,均可包括非易失性和易失性存储器中的至少一种。非易失性存储器可包括只读存储器(Read-OnlyMemory,ROM)、磁带、软盘、闪存、光存储器、高密度嵌入式非易失性存储器、阻变存储器(ReRAM)、磁变存储器(Magnetoresistive Random Access Memory,MRAM)、铁电存储器(Ferroelectric Random Access Memory,FRAM)、相变存储器(Phase Change Memory,PCM)、石墨烯存储器等。易失性存储器可包括随机存取存储器(Random Access Memory,RAM)或外部高速缓冲存储器等。作为说明而非局限,RAM可以是多种形式,比如静态随机存取存储器(Static Random Access Memory,SRAM)或动态随机存取存储器(Dynamic RandomAccess Memory,DRAM)等。本申请所提供的各实施例中所涉及的数据库可包括关系型数据库和非关系型数据库中至少一种。非关系型数据库可包括基于区块链的分布式数据库等,不限于此。本申请所提供的各实施例中所涉及的处理器可为通用处理器、中央处理器、图形处理器、数字信号处理器、可编程逻辑器、基于量子计算的数据处理逻辑器等,不限于此。
以上实施例的各技术特征可以进行任意的组合,为使描述简洁,未对上述实施例中的各个技术特征所有可能的组合都进行描述,然而,只要这些技术特征的组合不存在矛盾,都应当认为是本说明书记载的范围。
以上所述实施例仅表达了本申请的几种实施方式,其描述较为具体和详细,但并不能因此而理解为对本申请专利范围的限制。应当指出的是,对于本领域的普通技术人员来说,在不脱离本申请构思的前提下,还可以做出若干变形和改进,这些都属于本申请的保护范围。因此,本申请的保护范围应以所附权利要求为准。

Claims (10)

1.一种基于电网大数据中心的数据仓库建模方法,其特征在于,所述方法包括:
获取待处理数据表,所述待处理数据表携带至少两个不同电网大数据中心的数据;
确定所述待处理数据表对应的数据明细表,并获取所述数据明细表之间的第一逻辑关系;
基于所述第一逻辑关系,在各所述数据明细表之间设置逻辑关系,得到第一关系表;
基于所述第一关系表,建立所述电网大数据中心的数据明细模型,并获取第一共享数据维度;
从所述第一关系表中获取与所述第一共享数据维度匹配的第二关系表,并确定所述第二关系表对应的数据汇总表;
基于所述数据汇总表,建立所述电网大数据中心的数据汇总模型,并组合所述数据明细模型与所述数据汇总模型,生成所述电网大数据中心的数据仓库模型。
2.根据权利要求1所述的方法,其特征在于,所述确定所述待处理数据表对应的数据明细表,包括:
获取所述待处理数据表对应的第一预设字段规则;
基于所述第一预设字段规则,对所述待处理数据表进行更新,得到所述待处理数据表的数据明细表。
3.根据权利要求2所述的方法,其特征在于,所述确定所述第二关系表对应的数据汇总表,还包括:
获取所述第二关系表对应的第二预设字段规则;
基于所述第二预设字段规则,对所述第二关系表进行更新,得到所述第二关系表对应的数据汇总表。
4.根据权利要求3所述的方法,其特征在于,在确定所述第二关系表对应的数据汇总表后,还包括:
获取第二逻辑关系,所述第二逻辑关系为不同待处理数据表对应的所述第二关系表之间的逻辑关系;
基于所述第二逻辑关系,在各所述第二关系表之间设置逻辑关系,得到第三关系表,并获取第二共享数据维度;
从所述第三关系表中获取与所述第二共享数据维度匹配的第四关系表,并基于所述第四关系表,得到所述待处理数据表在数据集市层对应的集市表。
5.根据权利要求4所述的方法,其特征在于,所述基于所述第四关系表,得到所述待处理数据表在数据集市层对应的集市表包括:
获取第三预设字段规则,所述第三预设字段规则为各所述第四关系表在数据集市层对应的规则;
基于所述第三预设字段规则,对所述第四关系表进行更新,得到所述待处理数据表在所述数据集市层的集市表。
6.根据权利要求5所述的方法,其特征在于,所述第一预设字段规则、所述第二预设字段规则、以及所述第三预设字段规则包括所述待处理数据表中字段分别对应的预设数据类型规则、数据类型对应的值域规则、编码规则、约束规则、键规则、以及命名规则;
所述第一逻辑关系与所述第二逻辑关系包括关联关系;或,所述第一逻辑关系与所述第二逻辑关系包括关联关系和附加关系,所述附加关系包括聚合关系、组合关系、以及泛化关系中的至少一种。
7.一种基于电网大数据中心的数据仓库建模装置,其特征在于,所述装置包括:
数据表获取模块,用于获取待处理数据表,所述待处理数据表携带至少两个不同电网大数据中心的数据;
明细表确定模块,用于确定所述待处理数据表对应的数据明细表,并获取所述数据明细表之间的第一逻辑关系;
关系表生成模块,用于基于所述第一逻辑关系,在各所述数据明细表之间设置逻辑关系,得到第一关系表;
第一模型建立模块,用于基于所述第一关系表,建立所述电网大数据中心的数据明细模型,并获取第一共享数据维度;
汇总表确定模块,用于从所述第一关系表中获取与所述第一共享数据维度匹配的第二关系表,并确定所述第二关系表对应的数据汇总表;
第二模型建立模块,用于基于所述数据汇总表,建立所述电网大数据中心的数据汇总模型,并组合所述数据明细模型与所述数据汇总模型,生成所述电网大数据中心的数据仓库模型。
8.一种计算机设备,包括存储器和处理器,所述存储器存储有计算机程序,其特征在于,所述处理器执行所述计算机程序时实现权利要求1至6中任一项所述的方法的步骤。
9.一种计算机可读存储介质,其上存储有计算机程序,其特征在于,所述计算机程序被处理器执行时实现权利要求1至6中任一项所述的方法的步骤。
10.一种计算机程序产品,包括计算机程序,其特征在于,该计算机程序被处理器执行时实现权利要求1至6中任一项所述的方法的步骤。
CN202311849591.5A 2023-12-28 2023-12-28 基于电网大数据中心的数据仓库建模方法 Pending CN117851522A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202311849591.5A CN117851522A (zh) 2023-12-28 2023-12-28 基于电网大数据中心的数据仓库建模方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202311849591.5A CN117851522A (zh) 2023-12-28 2023-12-28 基于电网大数据中心的数据仓库建模方法

Publications (1)

Publication Number Publication Date
CN117851522A true CN117851522A (zh) 2024-04-09

Family

ID=90543191

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202311849591.5A Pending CN117851522A (zh) 2023-12-28 2023-12-28 基于电网大数据中心的数据仓库建模方法

Country Status (1)

Country Link
CN (1) CN117851522A (zh)

Similar Documents

Publication Publication Date Title
CN111241185B (zh) 数据处理方法以及装置
US8234308B2 (en) Deliver application services through business object views
US9037579B2 (en) Generating dynamic hierarchical facets from business intelligence artifacts
CN112269792B (zh) 数据查询方法、装置、设备及计算机可读存储介质
US20140279839A1 (en) Integration of transactional and analytical capabilities of a database management system
US8626543B2 (en) Tracing software execution of a business process
CN103348598A (zh) 生成数据模式信息
CN102541867A (zh) 数据字典生成方法及系统
CN111145011B (zh) 一种银行业务系统搭建方法及装置
US20220269702A1 (en) Intelligent annotation of entity-relationship data models
Vajk et al. Automatic NoSQL schema development: A case study
JP2004030221A (ja) 変更対象テーブル自動検出方法
US20080294673A1 (en) Data transfer and storage based on meta-data
CN115080765A (zh) 一种航天质量知识图谱构建方法、系统、介质和设备
CN114253939A (zh) 一种数据模型的构建方法、装置、电子设备及存储介质
US20140143248A1 (en) Integration to central analytics systems
Yang et al. User story clustering in agile development: a framework and an empirical study
Vahdati et al. Mapping large scale research metadata to linked data: A performance comparison of HBase, CSV and XML
CN115329011A (zh) 数据模型的构建方法、数据查询的方法、装置及存储介质
Cecelja Manufacturing Information and Data Systems: Analysis, Design and Practice
CN117851522A (zh) 基于电网大数据中心的数据仓库建模方法
CN114860819A (zh) 商业智能系统的构建方法、装置、设备和存储介质
CN114490571A (zh) 一种建模方法、服务器及存储介质
El Beggar et al. Towards an MDA-oriented UML profiles for data warehouses design and development
Ahmed et al. Generating data warehouse schema

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