CN116976800A - 数据处理方法、装置、存储介质及电子设备 - Google Patents

数据处理方法、装置、存储介质及电子设备 Download PDF

Info

Publication number
CN116976800A
CN116976800A CN202210412715.2A CN202210412715A CN116976800A CN 116976800 A CN116976800 A CN 116976800A CN 202210412715 A CN202210412715 A CN 202210412715A CN 116976800 A CN116976800 A CN 116976800A
Authority
CN
China
Prior art keywords
index
business
data
basic
data processing
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
CN202210412715.2A
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.)
SF Technology Co Ltd
Original Assignee
SF 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 SF Technology Co Ltd filed Critical SF Technology Co Ltd
Priority to CN202210412715.2A priority Critical patent/CN116976800A/zh
Publication of CN116976800A publication Critical patent/CN116976800A/zh
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/25—Integrating or interfacing systems involving database management systems
    • G06F16/252—Integrating or interfacing systems involving database management systems between a Database Management System and a front-end application
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/25—Integrating or interfacing systems involving database management systems
    • G06F16/258—Data format conversion from or to a database
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/10—Office automation; Time management
    • G06Q10/103—Workflow collaboration or project management

Landscapes

  • Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Human Resources & Organizations (AREA)
  • General Engineering & Computer Science (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Tourism & Hospitality (AREA)
  • General Business, Economics & Management (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

本申请实施例提供了一种数据处理方法、装置、存储介质及电子设备。本申请实施例首先基于业务场景的数据处理需求，获取所述业务场景的业务实质；然后根据业务实质定义出所述业务场景的基础指标；进而根据定义的基础指标构建所述业务场景的指标字典。本申请实施例根据业务场景的业务实质抽象出基础指标，对业务实质指标化，将业务数据化繁为简，化多样为统一，根据生成的指标构建统一的指标字典，该指标字典可以作为不同部门处理业务数据的统一参照，提高数据处理的效率。

Description

数据处理方法、装置、存储介质及电子设备
技术领域
本申请涉及数据处理技术领域，尤其涉及一种数据处理方法、装置、存储介质及电子设备。
背景技术
随着企业日益发展和壮大，各职能部门在信息化的过程中建立了各自的系统。各职能部门的业务系统分别搭建各自的功能、生成报告。企业各部门跨部门数据合作频繁，业务流相互关联，紧密联动。
然而，各部门站在自己的角度对业务数据进行理解和定义，使得相同的业务数据被赋予不同的含义，不同的业务数据又被赋予相同的含义，从而导致数据的处理效率低。
发明内容
本申请实施例提供一种数据处理方法、装置、存储介质及电子设备，能够提高数据的处理效率。
第一方面，本申请实施例提供一种数据处理方法，包括：
基于业务场景的数据处理需求，获取业务场景的业务实质；
根据业务实质定义出业务场景的基础指标；
根据定义的基础指标构建业务场景的指标字典。
第二方面，本申请实施例提供了一种数据处理装置，包括：
第一获取模块，用于基于业务场景的数据处理需求，获取业务场景的业务实质；
指标定义模块，用于根据业务实质定义出业务场景的基础指标；
第一构建模块，用于根据定义的基础指标构建业务场景的指标字典。
在本申请一种可能的实现方式中，在根据定义的基础指标构建业务场景的指标字典时，第一构建模块具体还用于：
确定用于生成复合指标的目标基础指标和目标运算规则，目标运算规则用于根据目标基础指标生成复合指标；
根据目标运算规则，对目标基础指标进行运算处理，生成复合指标；
根据基础指标以及复合指标构建业务场景的指标字典。
在本申请一种可能的实现方式中，数据处理装置还包括第二获取模块、数据存储模块和第二构建模块：
第二获取模块，用于响应于指标使用指令，获取指标使用指令指示的待使用指标的指标数据，待使用指标包括基础指标和/或复合指标；
数据存储模块，用于确定指标数据的存储格式，并按照存储格式存储指标数据；
第二构建模块，用于根据存储的指标数据构建指标数据库。
在本申请一种可能的实现方式中，指标数据库中，所有指标数据的存储格式相同。
在本申请一种可能的实现方式中，存储格式包括时间维度、组织、指标编码、指标名称和指标值中的至少一项。
在本申请一种可能的实现方式中，数据处理装置还包括第三获取模块和数据分析模块：
第三获取模块，用于响应于数据分析指令，获取数据分析指令指示的目标指标数据；
数据分析模块，用于从指标数据库中调用目标指标数据进行分析，得到分析结果。
在本申请一种可能的实现方式中，在根据业务实质定义出业务场景的基础指标时，指标定义模块具体还用于：
根据业务实质，获取用于生成基础指标的指标信息，其中，指标信息包括指标编码、指标名称、指标定义、口径、计算逻辑、时间维度和所属业务部门中的至少一项；
根据指标信息定义出业务场景的基础指标。
第三方面，本申请实施例还提供一种计算机可读的存储介质，存储介质上存储有计算机程序，计算机程序被处理器执行以实现本申请实施例提供的任一种数据处理方法中的步骤。
第四方面，本申请实施例还提供一种电子设备，电子设备包括处理器、存储器以及存储于存储器中并可在处理器上运行的计算机程序，处理器执行计算机程序以实现本申请实施例提供的任一种数据处理方法中的步骤。
本申请实施例中，首先基于业务场景的数据处理需求，获取业务场景的业务实质；然后根据业务实质定义出业务场景的基础指标；进而根据定义的基础指标构建业务场景的指标字典。本申请实施例根据业务场景的业务实质抽象出基础指标，对业务实质指标化，将业务数据化繁为简，化多样为统一，根据生成的指标构建统一的指标字典，该指标字典可以作为不同部门处理业务数据的统一参照，提高数据处理的效率。
附图说明
为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍。显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1为本申请实施例提供的数据处理方法的第一种场景示意图。
图2为本申请实施例提供的数据处理方法的一种流程示意图。
图3为本申请实施例中提供的步骤S30的一个实施例流程示意图。
图4为本申请实施例中提供的步骤S40～S60的一个实施例流程示意图。
图5为本申请实施例中提供的步骤S70与S80的一个实施例流程示意图。
图6为本申请实施例提供的数据处理方法的第二种场景示意图。
图7为本申请实施例提供的数据处理装置的第一种结构示意图。
图8为本申请实施例提供的数据处理装置的第二种结构示意图。
图9为本申请实施例电子设备的结构示意图。
具体实施方式
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
在本申请实施例的描述中，需要理解的是，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者更多个特征。在本申请实施例的描述中，“多个”的含义是两个或两个以上，除非另有明确具体的限定。
为了使本领域任何技术人员能够实现和使用本申请，给出了以下描述。在以下描述中，为了解释的目的而列出了细节。应当明白的是，本领域普通技术人员可以认识到，在不使用这些特定细节的情况下也可以实现本申请。在其它实例中，不会对公知的过程进行详细阐述，以避免不必要的细节使本申请实施例的描述变得晦涩。因此，本申请并非旨在限于所示的实施例，而是与符合本申请实施例所公开的原理和特征的最广范围相一致。
本申请实施例提供一种数据处理方法、装置、电子设备和计算机可读存储介质。其中，该数据处理装置可以集成在电子设备中，该电子设备可以是服务器，也可以是终端等设备。
在介绍本申请实施例之前，先介绍下本申请实施例关于应用背景的相关内容。
随着企业日益发展和壮大，各职能部门在信息化的过程中建立了各自的系统。企业各部门的业务流是相互关联，紧密联动的。但是职能部门间的系统却像一个个的孤岛。无论是统筹看企业的经营状况，还是部门间联动、数据的关联分析均因以上的矛盾而困难重重，同时各系统分别浪费大量的研发资源重复搭建相同、相似的功能、报告。
首先，数据在不同部门是独立存储，独立维护，彼此孤立的，形成物理上的孤岛。
其次，各部门站在自己的角度进行理解和定义，命名不规范，使得相同数据被赋予不同的含义；口径和来源上也不统一，不同的数据又被赋予相同的含义。加大了跨部门数据合作的沟通成本。
再者，因为这些系统都是在企业发展的不同时期，由不同的部门，站在自己应用的角度而研发的。各自的结构不统一，复用性差，存在大量的重复研发。
并且，业务场景太过复杂，熟悉业务系统，理解业务模式的研发人员培养周期长，成本高。
综合上述种种，由于各部门对业务数据的管理上没有统一的标准，导致在实现跨部门数据合作时，数据处理的效率很低。
基于上述问题，本申请实施例提供了一种数据处理方法，本申请实施例数据处理方法的执行主体可以为本申请实施例提供的数据处理装置，或者集成了该数据处理装置的服务器设备、物理主机或者用户设备(User Equipment，UE)等不同类型的电子设备，其中，数据处理装置可以采用硬件或者软件的方式实现，UE具体可以为智能手机、平板电脑、笔记本电脑、掌上电脑、台式电脑或者个人数字助理(Personal Digital Assistant，PDA)等终端设备。
该电子设备可以采用单独运行的工作方式，或者也可以采用设备集群的工作方式，通过应用本申请实施例提供的数据处理方法，可以通过指标字典为不同部门提供业务数据处理的统一参照，提高数据处理的效率。
例如，参见图1，图1是本申请实施例所提供的数据处理方法的第一种场景示意图。其中，该数据处理系统可以包括电子设备100，电子设备100中集成有数据处理装置。例如，该电子设备可以基于业务场景的数据处理需求，获取业务场景的业务实质；根据业务实质定义出基础指标；为基础指标定义统一的存储格式；根据定义的基础指标构建指标字典。
另外，在如图1所示的应用场景中，可以包括存储器200，用于存储数据，如业务场景的业务实质、定义的基础指标、构建的指标字典等。
需要说明的是，图1所示的数据处理方法的场景示意图仅仅是一个示例，本申请实施例描述的数据处理方法以及场景是为了更加清楚的说明本申请实施例的技术方案，并不构成对于本申请实施例提供的技术方案的限定，本领域普通技术人员可知，随着业务数据的演变和新业务场景的出现，本发明实施例提供的技术方案对于类似的技术问题，同样适用。
下面，开始介绍本申请实施例提供的数据处理方法，本申请实施例中以电子设备作为执行主体，为了简化与便于描述，后续方法实施例中将省略该执行主体。
参照图2，图2为本申请实施例提供的数据处理方法的一种流程示意图。需要说明的是，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。该数据处理方法包括步骤S10～S30，其中：
S10、基于业务场景的数据处理需求，获取业务场景的业务实质。
S20、根据业务实质定义出业务场景的基础指标。
S30、根据定义的基础指标构建业务场景的指标字典。
各步骤具体说明如下：
S10、基于业务场景的数据处理需求，获取业务场景的业务实质。
不同的职能部门可以从各种复杂的业务场景中获取到业务数据，业务数据中可以包括用户数据(例如用户的基本情况)、行为数据(指用户做过什么的数据，主要包括用户做了哪些行为，发生行为的时间等)、商品数据(包括商品名称、商品类别、商品评论、库存等)等大量的信息。
一般情况下，业务数据不会逐条地将业务实质直接呈现，而是将多个业务实质糅杂在一起。本申请实施例中，首先获取业务场景的业务实质，该业务实质是业务人员基于业务场景的数据处理需求，根据场景中业务数据的业务逻辑构成，从业务数据中抽象出来的。
业务实质可以理解为例如发生在某个地方、某个时间点、发生一个什么事情这样单独的项。对于各种不同的业务场景，业务人员都可以从“谁”、“在哪里”、“干什么”、“什么时候”、“多久”等这些单独的项出发，拆分业务数据的业务逻辑构成，从而抽象出业务场景包含的业务实质。而获取业务数据的业务实质的过程，实际就是将业务数据中的所有的业务事实打散，将其中单独的、最基础、最简单的业务事实拿出来作为业务实质的过程。业务实质是从业务数据中抽象出的最基础、最简单的业务事实，并且不可再拆分。
本申请实施例中，由业务人员对业务场景的业务数据进行处理，抽象出业务实质，设备端可以通过接收用户的输入，获取业务场景的业务实质。
例如，一业务场景为统计用户的跑步数据，获取到的数据表明，用户A在早上10:00在公园跑步，跑了1公里，花了7分钟。则对该业务场景而言，其中的业务逻辑构成包括了“谁”、“什么时候”、“在哪里”、“干什么”，还包括“距离”、“耗时”。业务人员根据该业务场景的逻辑构成，可以抽象出其中的业务实质包括“用户A(谁)”、“早上10:00(什么时候)”、“公园(在哪里)”、“跑步(干什么)”、“1公里(距离)”、“7分钟(耗时)”。设备端通过接收用户的输入，获取到该业务场景下的这些业务实质。
在一实施例中，根据实际的数据处理需求，并不需要统计业务场景中的所有业务实质。此时，可以基于业务场景的数据处理需求，获取所需要的那些业务实质。例如，在上述统计跑步的业务场景中，如果只需要统计用户的跑步距离和耗时，而并不关注什么时候跑、在哪里跑，则可以只抽取其中的“用户A(谁)”、“1公里(距离)”、“7分钟(耗时)”这三项业务实质输入到设备中。因而，设备所获取到的业务场景的业务实质，可以是基于业务场景的数据处理需求获取的。
在一些情况下，业务数据中包含的业务事实并非最基础最简单的，业务人员在抽象出业务实质时，需要考虑到各项业务事实是否已经是最基础、最简单的最小单位——业务实质，若不是业务事实最基础最简单的，则需要先从这些业务事实中提取出业务实质。
例如，利润可以拆分为成本和收益，在统计财务报表的业务场景中，报表中可以包括收益、成本、利润三种数据，而其中利润是由收益和成本计算得到，并非最基础、最简单的业务实质，收益和成本才是。虽然可以从报表中分别抽象出收益、成本、利润这三项业务事实，但只有收益和成本才是基于该业务场景的数据处理需求获取的业务实质。业务人员根据统计财务报表的数据处理需求，根据该业务场景的业务逻辑构成，从一堆零散的收益、成本、利润三种数据抽象出该业务场景的业务实质为“成本”和“利润”，输入到设备中，设备则获取到该业务场景的业务实质——“成本”和“利润”。
此外，对于除上述举例外的其他场景，业务人员都可以从“谁”、“在哪里”、“干什么”、“什么时候”、“多久”等这些单独的项出发，分析业务场景中业务数据的业务逻辑构成，抽象出业务场景的业务实质，此处不一一赘述。设备通过接收业务人员的输入，即可获取到业务场景的业务实质。S20、根据业务实质定义出业务场景的基础指标。
获取到业务场景的业务实质后，可以对获取到的每一项业务实质单独处理，进行指标化。例如，当业务实质包含收益和成本时，将收益作为单独的一项，成本作为单独的一项，然后，对每一项业务实质单独定义出基础指标。
本申请实施例中，各基础指标的指标信息包含统一的指标维度，在对业务实质进行指标化的过程中，根据业务实质定义出基础指标包含的各项指标维度的指标信息。
其中，统一的指标维度用于规范指标化的内容。可选的指标维度举例如下，各基础指标的指标信息中可以包括下述至少一项的指标维度：
1、指标编码，用于赋予基础指标以编码，作为基础指标的唯一标识，便于标准化、信息的分类、检索等。
2、指标名称，用于赋予基础指标唯一的业务含义。
3、指标定义，用于对基础指标所反映的业务事实进行定义。
4、口径，用于限定基础指标的取数来源、范围。
以营收为例，虽然都是营收，但当营收的口径不同时，这两种营收就不同，定义出的指标也相应不同。例如，营收的口径可以包括付款口径和妥投口径，其中付款口径的营收即确确实实收到款的收入，而妥投口径的营收指，只要快件从收件、运输到派件、直至收件方接收到了该快件，即在财务上认定属于收到款了，可以确认为妥投口径的营收。妥投口径的营收和付款口径的营收由于口径不同，因而有所差别。
5、计算逻辑，计算逻辑与口径相对应，用于记录如何得到对应该口径的数据算。
计算逻辑包括从哪个数据源取数、有哪些过滤条件，为了实现相应口径的取数，可以包括复杂的计算过程。例如，快递里面的代收货款，财务上并不将之认定为营收，因而在计算营收时会将其过滤掉。而营收中又可以包括运费、增值服务费(比如超长超重费用、偏远附加费用、上楼投递费用)等。为实现相应口径的取数，复杂的数据来源、剔除筛选的流程、以及数据的构成，都是口径对应的计算逻辑。
6、时间维度，用于对基础指标的时效进行定义，说明该基础指标反映的是日、周、月、季、年中的哪个时间区间的业务情况。
7、所属业务部门，用于记录该基础指标所覆盖的范围是哪个部门。需要说明的是，由于不同业务部门可能包含同样的业务实质，但是不同部门的同一业务实质在指标化时，需要做不同看待。例如不同部门的营收，营收所属业务部门可以是整个集团，也可以是财务部、运输部这样的某个部门，也可以是某个项目组。因而，在根据业务实质定义出基础指标时，对于所属业务部门不同的指标，即使口径、时间维度等其他维度的指标信息均相同，也视为不同的指标。
在一些实施例中，统一的指标维度包括上述指标编码、指标名称、指标定义、口径、计算逻辑、时间维度和所属业务部门中的至少一项。当确定出统一的指标维度包括上述哪些指标维度后，所有的基础指标即根据统一的指标维度的指标信息，对业务实质进行指标化得到。即，在根据业务实质定义出基础指标时，可以根据业务实质，获取用于生成基础指标的指标信息，根据指标信息定义出基础指标。其中，指标信息可以包括指标编码、指标名称、指标定义、口径、计算逻辑、时间维度和所属业务部门中的至少一项。
例如，若统一的指标维度包括上述例举的所有指标维度(指标编码、指标名称、指标定义、口径、计算逻辑、时间维度和所属业务部门)，则所有业务实质在指标化时，均包含上述例举的所有指标维度的指标信息，即定义出的基础指标中，包含指标编码、指标名称、指标定义、口径、计算逻辑、时间维度和所属业务部门这些指标信息。
例如，请参阅表1，表1为本申请实施例提供的指标信息的示意，以定义出的指标包含上述所有指标维度的指标信息为例。
表1
如表1所示，指标编码101的指标，指标名称为营收，指标定义为实际入账金额，口径为付款口径，计算逻辑包括取数数据源1和过滤条件1，时间维度为2022年2月，所属业务部门为空运部；指标编码102的指标，指标名称为营收，指标定义为实际入账金额，口径为付款口径，计算逻辑包括取数数据源2和过滤条件1，时间维度为2022年3月，所属业务部门为空运部；指标编码103的指标，指标名称为营收，指标定义为应入账及已入账金额，口径为妥投口径，计算逻辑包括取数数据源2和过滤条件2，时间维度为2022年3月，所属业务部门为陆运部；指标编码104的指标，指标名称为营收，指标定义为实际入账金额，口径为付款口径，计算逻辑包括取数数据源3和过滤条件1，时间维度为2021年，所属业务部门为集团。
表1中所例举的定义出的4个指标的指标名称均为营收，在某一或某些指标维度包含相同的指标信息，但是当在指标定义、口径、计算逻辑、时间维度、业务部门这些指标维度中至少有一个指标维度的指标信息不同时，上述4种营收应做不同的指标看待，用不同的指标编码进行区分。
在一实施例中，根据业务实质定义出基础指标包含的各项指标维度的指标信息的过程，即根据统一包含的所有指标维度的指标信息定义出指标的过程。即，设备在接收指标信息时，可以接收上述例举的所有指标维度的指标信息，从而设备根据这些指标信息定义出各个指标，且各指标间的相同点和区别点都清晰可见，为各部门人员提供统一参照。
S30、根据定义的基础指标构建业务场景的指标字典。
在一实施例中，在根据业务实质定义出基础指标包含的各项指标维度的指标信息后，可以将各基础指标的各项指标维度的指标信息进行存储，形成指标字典。该指标字典中包含各基础指标的各项指标维度的指标信息，设备可以通过检索指标字典，了解各项基础指标都指的是什么。例如，上述表1中所例举的几种指标，可以存储在指标字典中。在指标字典中可以以表1中例举的表格的形式，或者本申请实施例未例举的其他形式(如文字或者绘图等形式)，对各项指标所包含的所有指标维度的指标信息进行存储，同时，指标字典可以提供搜索功能。
举例来说，当某个部门的人员需要用到“营收”相关的指标时，可以搜索“营收”，即可在指标字典中搜索到所有与“营收”相关的指标，然后，通过阅览这些指标的指标定义、口径等信息，对各项指标进行了解，从中找到需要的“营收”指标。
从而，在指标字典中，单独的基础指标包含最简单的业务场景。指标字典为各部门提供统一的认知参照，能够规避掉数据混乱的问题。例如，A部门认为利润上升了，而B部门认为利润下降了，这种数据混乱的问题是由于不同部门对于利润的定义不同，导致计算的方式也不同。而当统一了认知后，不同部门看待业务实质的角度相同，计算方式也会统一，得到的结果统一，避免了数据混乱问题。
此外，不了解相关业务知识的研发人员无需了解整体业务、全系统链路，只需按文档取数和存储就能够形成指标，并且由于每个指标都是最简单最基础的，便于理解，业务人员无需去全面系统地了解业务知识，可以节省大量的培训时间。
并且，构建出的指标字典，任何人都可以在其中查阅，也都可以向其中添加新的指标，无需专人专责，能够实现资源的灵活调配。
在一些实施例中，在S30根据定义的基础指标构建业务场景的指标字典时，根据需要，还可以生成复合指标，根据基础指标和复合指标共同构建指标字典。由于基础指标都是根据最基础、最简单的单项业务实质定义出来的，当需要分析一些复杂的业务数据时，仅基础指标或许无法囊括。例如，一些情况下，需要分析利润，而指标字典中的基础指标只有营收和支出，若要计算利润，则需要涉及到大量的计算、重新取数等。这时，若有一项“利润”的复合指标，则可以直接拿来用，节约计算资源。复合指标可以在基础指标的基础上生成，根据基础指标和复合指标共同构建的指标字典中包含的指标更加全面，既包含简单业务事实的基础指标，又包含复杂业务事实的复合指标。
请参阅图3，图3是本申请实施例中提供的步骤S30的一个实施例流程示意图。下面，将介绍指标字典的另一种构建方式，即根据基础指标和复合指标构建业务场景的指标字典。S30中根据定义的基础指标构建业务场景的指标字典的步骤，还可以包括：
S31、确定用于生成复合指标的目标基础指标和目标运算规则，目标运算规则用于根据目标基础指标生成复合指标；
S32、根据目标运算规则，对目标基础指标进行运算处理，生成复合指标；
S33、根据基础指标以及复合指标构建业务场景的指标字典以下分别具体说明：
S31、确定用于生成复合指标的目标基础指标和目标运算规则，目标运算规则用于根据目标基础指标生成复合指标。
本申请实施例中，复合指标不由业务实质抽象得到，而是根据目标基础指标和目标运算规则生成。在构建指标字典时，可以根据基础指标以及复合指标构建指标字典。
其中，目标基础指标即用于生成复合指标的基础指标，目标运算规则即用于根据该目标基础指标生成相应复合指标的规则。
在一些情况下，生成不同的复合指标时，所用到的目标基础指标和目标运算规则不同，相同的目标基础指标和不同的目标运算规则、以及不同的目标基础指标和相同的目标运算规则，所生成的复合指标不同。
复合指标可以通过基础指标生成，其中根据基础指标生成复合指标的运算规则可以包括以下几种：
1、第一类复合指标，由若干基础指标相加得到，记为其中C1,C2,...,CN为组成该复合指标的基础指标。例如，运输成本/>其中C1是中转成本，C2是装机成本，C3是散航成本。
2、第二类复合指标，由两个基础指标相除得到，记为I＝I1/I2。其中I1是作为分子的基础指标，I2是作为分母的基础指标。例如，经营毛利率PR＝P/I，其中P为经营毛利，I为不含税收入净额。
3、第三类复合指标，由若干基础指标加、减的方式得到。该第三类复合指标可以通过在第一类复合指标的基础上，将运算中要加上或者减去的基础指标，参数设置为±1的方式实现。
需要说明的是，本申请配置的根据基础指标得到复合指标的运算规则不限于上述举例的三种情况，本领域技术人员也可以根据实际需求，配置其它运算规则来得到复合指标，上述举例不作为对本申请实施例的限制。
在生成复合指标之前，先从基础指标中确定出用于生成复合指标的目标基础指标和目标运算规则，其中，目标运算规则用于根据目标基础指标生成复合指标，目标运算规则可以从上述例举的以及未例举的规则中选取。根据目标基础指标以及目标运算规则，生成复合指标。
S32、根据目标运算规则，对目标基础指标进行运算处理，生成复合指标。
确定好目标基础指标以及目标运算规则后，即可根据目标运算规则对目标基础指标进行运算处理，生成对应的复合指标。根据多组目标基础指标以及目标运算规则，可以生成多个复合指标。
本申请实施例中，所有复合指标和所有基础指标一样，包含统一指标维度的指标信息。具体的，统一的指标维度包括上述指标编码、指标名称、指标定义、口径、计算逻辑、时间维度和所属业务部门中的至少一项。
在获取目标运算规则时，可以根据目标运算规则，定义用于生成复合指标的各项指标维度的指标信息。
例如，根据目标基础指标得到复合指标时，若目标基础指标的时间维度的指标信息相同时，生成的复合指标在时间维度的指标信息可以与目标基础指标保持一致，又例如，可以根据目标运算规则定义复合指标的计算逻辑。
关于各项指标维度的具体描述，可参见步骤S20中的描述，在此不再赘述。
S33、根据基础指标以及复合指标构建业务场景的指标字典。
在一实施例中，在生成复合指标后，可以将各基础指标以及各复合指标的各项指标维度的指标信息进行存储，形成指标字典。该指标字典中包含各基础指标以及各复合指标的各项指标维度的指标信息，设备可以通过检索指标字典，了解各项基础指标以及各项复合指标都指的是什么。
指标字典中，所有复合指标和所有基础指标一样，包含上述各项指标维度的指标信息。即，各基础指标以及各复合指标的指标信息包含统一的指标维度，指标维度包括指标编码、指标名称、指标定义、口径、计算逻辑、时间维度和所属业务部门中的至少一项。
各基础指标间通过不同运算规则结合，可以得到多种多样的复合指标，显著提高指标字典中指标的丰富程度。
本申请通过配置运算规则，利用已存在的基础指标直接生成复合指标，能够减少大量重复研发工作，提升研发效率，提升研发资源利用率。大量加总的、率的指标通过配置生成。
请参阅图4，图4是本申请实施例中提供的步骤S40～S60的流程示意图。在一实施例中，在S30根据定义的基础指标构建业务场景的指标字典之后，还包括：
S40、响应于指标使用指令，获取指标使用指令指示的待使用指标的指标数据，待使用指标包括基础指标和/或复合指标；
S50、确定指标数据的存储格式，并按照存储格式存储指标数据；
S60、根据存储的指标数据构建指标数据库。
以下分别具体说明：
S40、响应于指标使用指令，获取指标使用指令指示的待使用指标的指标数据，待使用指标包括基础指标和/或复合指标。
在一些情况下，基于统计业务数据的需求，需要应用到指标字典中的指标。根据需要，设备可以获取用户输入的指标使用指令，指标使用指令中携带用户需要调用的待使用指标。例如，当用户需要调用到待使用指标时，在指标字典中进行相应的交互操作(例如对“调用”按键的点击操作)，向设备输入指标使用指令。
设备响应于指标使用指令，根据指标使用指令指示的待使用指标，调用该待使用指标，并使用该待使用指标获取到相应的指标数据。其中，待使用指标可以包括基础指标，也可以包括复合指标，也可以既包括基础指标，也包括复合指标。
例如，当指标使用指令指示的待使用指标为上述表1中编号101的“营收”指标时，指标编码101的指标，指标名称为营收，指标定义为实际入账金额，口径为付款口径，计算逻辑包括取数数据源1和过滤条件1，时间维度为2022年2月，所属业务部门为空运部。设备响应于该指标使用指令，调用编号101的“营收”指标，获取空运部在2022年2月，付款口径的实际入账金额作为指标数据。
S50、确定指标数据的存储格式，并按照存储格式存储指标数据。
本申请实施例中，对于获取到的各指标数据，确定指标数据的存储格式，以便于对各指标数据进行存储。
其中，存储格式中可以包括以下至少一项：
1、时间维度，用于说明该基础指标反映的是日、周、月、季、年中的哪个时间区间的业务情况。
2、组织，用于记录该基础指标反映的是发生在哪个地方、哪个职能、组织中的业务情况。
3、指标编码，基础指标的唯一标识，便于标准化、信息的分类、检索等。
4、指标名称，用于赋予基础指标唯一的业务含义，说明基础指标反映的是什么样的业务情况，比如收入、成本、客诉率等等。
5、指标值，用于反映该基础指标当前的客观业务量。系统确定出指标使用指令指示的待使用指标后，根据该待使用指标的口径、计算逻辑、定义等去业务数据中搜寻并计算出该指标的指标值。例如，对于上述例举的表1中的编号101的指标，取数后的指标值即为空运部在2022年2月付款口径实际入账的金额数。
其中，存储格式中包含的时间维度、指标编码和指标名称与指标维度中包含的时间维度、指标编码和指标名称含义相同。
在一实施例中，指标数据库中，所有指标数据的存储格式相同。在存储指标数据时，各指标数据采用统一的存储格式。统一的存储格式包括上述时间维度、组织、指标编码、指标名称和指标值中的至少一项。当确定出统一的存储格式包括上述哪几项后，所有的基础指标即按照该统一的存储格式进行存储。
例如，若统一的存储格式包括上述例举的所有项(时间维度、组织、指标编码、指标名称和指标值)，则所有指标数据在存储时，都会存储指标数据的时间维度、组织、指标编码、指标名称和指标值。
S60、根据存储的指标数据构建指标数据库。
基于实际的业务处理需求，根据指标字典中的各项指标(基础指标及复合指标)对业务数据进行取数，得到各指标数据后，将各指标数据进行存储，构建出指标数据库。当指标数据库构建出来之后，此后获取的所有指标数据，都可以存储进该指标数据库。该指标数据库可以作为各部门人员进行数据分析的数据基础。而其中的各项指标数据由于是按照指标字典中统一的指标进行取数的，因而可以规避各部门理解不同的情况，帮助各部门实现对各项数据的统一认知。
由于使用了同一标准的指标，统一了来源、口径，相同数据赋予了相同的业务含义，因而数据统计得更加全面，统计结果更加精准。
此外，本申请构建的指标数据库中，原来业务数据的复杂格式(例如报表)，被指标格式替代，原分系统专人专职负责的方式，被灵活拆分细化的研发方式替代，这样的结构能够降低风险。当整个系统来源面出现风险，原本可能需要排查很多指标，而根据本申请实施例提供的数据处理方法，用统一标准将相同业务实质统一为同一指标，从而只需要排查某个指标点的指标数据即可，
例如，原本收入、重量、票数之类的业务数据可能是堆叠在一起的，若是将包含这些业务数据的复杂业务场景直接用于研发，则容易导致系统性的风险。只要存在一点错误，比如说收入算错了，那么整个系统中的其他数据也存在错误的可能，数据的可信度降低，且风险难以排查。而本申请提供的指标数据库中的指标数据为指标格式，被拆分得很细，A人员研发收入、B人员研发重量、C人员研发票数，当收入计算出现错误时，只会错收入这一个指标点的指标数据，系统中的其他数据不会受到影响，好排查，好解决。因而，本申请提供的数据处理方法在风险控制和风险排查方面也存在不小的优势。
请参阅图5，图5是本申请实施例中提供的步骤S70与S80的一个实施例流程示意图。S60根据存储的指标数据构建指标数据库的步骤之后，可以包括：
S70、响应于数据分析指令，获取数据分析指令指示的目标指标数据；
S80、从指标数据库中调用目标指标数据进行分析，得到分析结果。
以下分别具体说明：
S70、响应于数据分析指令，获取数据分析指令指示的目标指标数据。
当各部门人员有数据分析的需求时，向设备输入数据分析指令。设备响应于用户输入的数据分析指令，获取数据分析指令指示的目标指标数据。目标指标数据此前根据指标取数获取，并存储在指标数据库中，随时可以调用。
S80、从指标数据库中调用目标指标数据进行分析，得到分析结果。
根据实际的数据分析需求，从指标数据库中调用出相应的目标指标数据，就可以对这些目标指标数据进行分析，得到分析结果。其中，分析结果可以包括主题应用表、主题报告等。
请参阅图6，图6为本申请实施例提供的数据处理方法的第二种场景示意图。如图6所示，根据构建的指标字典，可以从各个业务系统中进行取数，得到指标数据，构建出指标数据库，其中每个基础指标只反映某个最简单的业务事实。然后，通过配置基础指标得到复合指标的规则，可以生成复合指标，补充至指标字典。以指标字典为统一参照，可以获取各项指标数据，得到指标数据库。该指标库可以被不同的业务部门调取进行数据分析，生成的各种主题应用表或者主题报告通过统计各项指标的指标值，衍生出同环比、累计值、增长率等多种数值。需要衍生的同环比等业务量全部一次生成，无需重新研发。
由上可知，本申请实施例中，首先基于业务场景的数据处理需求，获取业务场景的业务实质；然后根据业务实质定义出业务场景的基础指标；进而根据定义的基础指标构建业务场景的指标字典。本申请实施例根据业务场景的业务实质抽象出基础指标，对业务实质指标化，将业务数据化繁为简，化多样为统一，根据生成的指标构建统一的指标字典，该指标字典可以作为不同部门处理业务数据的统一参照，提高数据处理的效率。
为便于更好的实施本申请实施例提供的数据处理方法，本申请实施例还提供一种基于上述数据处理方法的装置。其中名词的含义与上述数据处理方法中相同，具体实现细节可以参考方法实施例中的说明。
请参阅图7，图7为本申请实施例提供的数据处理装置400的第一种结构示意图。该数据处理装置400包括第一获取模块401、指标定义模块402和第一构建模块403：
第一获取模块401，用于基于业务场景的数据处理需求，获取业务场景的业务实质；
指标定义模块402，用于根据业务实质定义出业务场景的基础指标；
第一构建模块403，用于根据定义的基础指标构建业务场景的指标字典。
在一实施例中，在根据定义的基础指标构建业务场景的指标字典时，第一构建模块403可以用于：
确定用于生成复合指标的目标基础指标和目标运算规则，目标运算规则用于根据目标基础指标生成复合指标；
根据目标运算规则，对目标基础指标进行运算处理，生成复合指标；
根据基础指标以及复合指标构建业务场景的指标字典。
请参阅图8，图8为本申请实施例提供的数据处理装置400的第二种结构示意图。在一实施例中，数据处理装置400还包括第二获取模块404、数据存储模块405和第二构建模块406：
第二获取模块404，用于响应于指标使用指令，获取指标使用指令指示的待使用指标的指标数据，待使用指标包括基础指标和/或复合指标；
数据存储模块405，用于确定指标数据的存储格式，并按照存储格式存储指标数据；
第二构建模块406，用于根据存储的指标数据构建指标数据库。
在一实施例中，指标数据库中，所有指标数据的存储格式相同。
在一实施例中，存储格式包括时间维度、组织、指标编码、指标名称和指标值中的至少一项。
请继续参阅图8，在一实施例中，数据处理装置400还可以包括第三获取模块407和数据分析模块408：
第三获取模块407，用于响应于数据分析指令，获取数据分析指令指示的目标指标数据；
数据分析模块408，用于从指标数据库中调用目标指标数据进行分析，得到分析结果。
在一实施例中，在根据业务实质定义出业务场景的基础指标时，指标定义模块402可以用于：
根据业务实质，获取用于生成基础指标的指标信息，其中，指标信息包括指标编码、指标名称、指标定义、口径、计算逻辑、时间维度和所属业务部门中的至少一项；
根据指标信息定义出业务场景的基础指标。
由上可知，本申请实施例提供的数据处理装置，首先第一获取模块401基于业务场景的数据处理需求，获取业务场景的业务实质；然后指标定义模块402根据业务实质定义出业务场景的基础指标；进而第一构建模块403根据定义的基础指标构建业务场景的指标字典。本申请实施例根据业务场景的业务实质抽象出基础指标，对业务实质指标化，将业务数据化繁为简，化多样为统一，根据生成的指标构建统一的指标字典，该指标字典可以作为不同部门处理业务数据的统一参照，提高数据处理的效率。
具体实施时，以上各个单元可以作为独立的实体来实现，也可以进行任意组合，作为同一或若干个实体来实现，以上各个单元的具体实施可参见前面的方法实施例，在此不再赘述。
由于该数据处理装置可以执行本申请如图1至图6对应任意实施例中数据处理方法中的步骤，因此，可以实现本申请如图1至图6对应任意实施例中数据处理方法所能实现的有益效果，详见前面的说明，在此不再赘述。
此外，为了更好实施本申请实施例中数据处理方法，在数据处理方法基础之上，本申请实施例还提供一种电子设备，参阅图9，图9示出了本申请实施例电子设备的结构示意图，具体的，本申请实施例提供的电子设备包括处理器501，处理器501用于执行存储器502中存储的计算机程序时实现如图1至图6对应任意实施例中数据处理方法的各步骤；或者，处理器501用于执行存储器502中存储的计算机程序时实现如图7至图8对应实施例中各模块的功能。
示例性的，计算机程序可以被分割成一个或多个模块/单元，一个或者多个模块/单元被存储在存储器502中，并由处理器501执行，以完成本申请实施例。一个或多个模块/单元可以是能够完成特定功能的一系列计算机程序指令段，该指令段用于描述计算机程序在计算机装置中的执行过程。
电子设备可包括，但不仅限于处理器501、存储器502。本领域技术人员可以理解，示意仅仅是电子设备的示例，并不构成对电子设备的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件，例如电子备还可以包括输入输出设备、网络接入设备、总线等，处理器501、存储器502、输入输出设备以及网络接入设备等通过总线相连。
处理器501可以是中央处理单元(Central Processing Unit，CPU)，还可以是其他通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现成可编程门阵列(Field-Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等，处理器是电子设备的控制中心，利用各种接口和线路连接整个电子设备的各个部分。
存储器502可用于存储计算机程序和/或模块，处理器501通过运行或执行存储在存储器502内的计算机程序和/或模块，以及调用存储在存储器502内的数据，实现计算机装置的各种功能。存储器502可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序(比如声音播放功能、图像播放功能等)等；存储数据区可存储根据电子设备的使用所创建的数据(比如音频数据、视频数据等)等。此外，存储器可以包括高速随机存取存储器，还可以包括非易失性存储器，例如硬盘、内存、插接式硬盘，智能存储卡(Smart Media Card，SMC)，安全数字(Secure Digital，SD)卡，闪存卡(Flash Card)、至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。
所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的数据处理装置、电子设备及其相应单元的具体工作过程，可以参考如图1至图6对应任意实施例中数据处理方法的说明，具体在此不再赘述。
本领域普通技术人员可以理解，上述实施例的各种方法中的全部或部分步骤可以通过指令来完成，或通过指令控制相关的硬件来完成，该指令可以存储于一计算机可读存储介质中，并由处理器进行加载和执行。
为此，本申请实施例提供一种计算机可读存储介质，其中存储有多条指令，该指令能够被处理器进行加载，以执行本申请如图1至图6对应任意实施例中数据处理方法中的步骤，具体操作可参考如图1至图6对应任意实施例中数据处理方法的说明，在此不再赘述。
其中，该计算机可读存储介质可以包括：只读存储器(ROM，Read Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁盘或光盘等。
由于该计算机可读存储介质中所存储的指令，可以执行本申请如图1至图6对应任意实施例中数据处理方法中的步骤，因此，可以实现本申请如图1至图6对应任意实施例中数据处理方法所能实现的有益效果，详见前面的说明，在此不再赘述。
以上对本申请实施例所提供的一种数据处理方法、装置、电子设备及计算机可读存储介质进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上，本说明书内容不应理解为对本申请的限制。

Claims (10)

1.一种数据处理方法，其特征在于，包括：
基于业务场景的数据处理需求，获取所述业务场景的业务实质；
根据所述业务实质定义出所述业务场景的基础指标；
根据定义的基础指标构建所述业务场景的指标字典。
2.根据权利要求1所述的数据处理方法，其特征在于，所述根据定义的基础指标构建所述业务场景的指标字典包括：
确定用于生成复合指标的目标基础指标和目标运算规则，所述目标运算规则用于根据所述目标基础指标生成所述复合指标；
根据所述目标运算规则，对所述目标基础指标进行运算处理，生成所述复合指标；
根据所述基础指标以及所述复合指标构建所述业务场景的指标字典。
3.根据权利要求1或2所述的数据处理方法，其特征在于，所述根据定义的基础指标构建所述业务场景的指标字典之后，还包括：
响应于指标使用指令，获取所述指标使用指令指示的待使用指标的指标数据，所述待使用指标包括基础指标和/或复合指标；
确定所述指标数据的存储格式，并按照所述存储格式存储指标数据；
根据存储的指标数据构建指标数据库。
4.根据权利要求3所述的数据处理方法，其特征在于，所述指标数据库中，所有指标数据的存储格式相同。
5.根据权利要求4所述的数据处理方法，其特征在于，所述存储格式包括时间维度、组织、指标编码、指标名称和指标值中的至少一项。
6.根据权利要求3所述的数据处理方法，其特征在于，所述根据存储的指标数据构建指标数据库之后，还包括：
响应于数据分析指令，获取所述数据分析指令指示的目标指标数据；
从所述指标数据库中调用所述目标指标数据进行分析，得到分析结果。
7.根据权利要求1所述的数据处理方法，其特征在于，所述根据所述业务实质定义出所述业务场景的基础指标包括：
根据所述业务实质，获取用于生成所述基础指标的指标信息，其中，所述指标信息包括指标编码、指标名称、指标定义、口径、计算逻辑、时间维度和所属业务部门中的至少一项；
根据所述指标信息定义出所述业务场景的基础指标。
8.一种数据处理装置，其特征在于，包括：
第一获取模块，用于基于业务场景的数据处理需求，获取所述业务场景的业务实质；
指标定义模块，用于根据所述业务实质定义出所述业务场景的基础指标；
第一构建模块，用于根据定义的基础指标构建所述业务场景的指标字典。
9.一种计算机可读的存储介质，其特征在于，所述存储介质上存储有计算机程序，所述计算机程序被处理器执行以实现如权利要求1至7任一项所述的数据处理方法。
10.一种电子设备，其特征在于，所述电子设备包括处理器、存储器以及存储于所述存储器中并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序以实现如权利要求1至7任一项所述的数据处理方法。
CN202210412715.2A 2022-04-19 2022-04-19 数据处理方法、装置、存储介质及电子设备 Pending CN116976800A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202210412715.2A CN116976800A (zh) 2022-04-19 2022-04-19 数据处理方法、装置、存储介质及电子设备

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202210412715.2A CN116976800A (zh) 2022-04-19 2022-04-19 数据处理方法、装置、存储介质及电子设备

Publications (1)

Publication Number Publication Date
CN116976800A true CN116976800A (zh) 2023-10-31

Family

ID=88483633

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202210412715.2A Pending CN116976800A (zh) 2022-04-19 2022-04-19 数据处理方法、装置、存储介质及电子设备

Country Status (1)

Country Link
CN (1) CN116976800A (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117252676A (zh) * 2023-11-20 2023-12-19 成都新希望金融信息有限公司 业务处理方法、装置、电子设备和指标策略系统

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117252676A (zh) * 2023-11-20 2023-12-19 成都新希望金融信息有限公司 业务处理方法、装置、电子设备和指标策略系统
CN117252676B (zh) * 2023-11-20 2024-02-02 成都新希望金融信息有限公司 业务处理方法、装置、电子设备和指标策略系统

Similar Documents

Publication Publication Date Title
CN108376364B (zh) 一种支付系统对账的方法、设备及终端设备
US9020988B2 (en) Database aggregation of purchase data
CN114510735B (zh) 基于角色管理的智慧共享财务管理方法及平台
CN113205402A (zh) 对账方法、装置、电子设备及计算机可读介质
CN112559524A (zh) 一种指标数据库建立方法、装置及存储介质
CN113268500A (zh) 业务处理方法、装置及电子设备
CN116976800A (zh) 数据处理方法、装置、存储介质及电子设备
CN111476013A (zh) 信息收集方法、装置、介质及电子设备
CN112258306B (zh) 账务信息核对的方法、装置、电子设备和存储介质
CN109947797B (zh) 一种数据检查装置及方法
CN111292068B (zh) 一种合同信息审核方法、装置、电子设备及存储介质
CN112835910A (zh) 一种企业信息与政策信息的处理方法和装置
CN109542890B (zh) 数据修改方法、装置、计算机设备及存储介质
CN115994830A (zh) 取数模型的构建方法和数据归集方法及相关装置
US10042902B2 (en) Business rules influenced quasi-cubes with higher diligence of data optimization
CN116050359A (zh) 一种保单托管录入方法、系统、终端设备及存储介质
CN110348983A (zh) 交易信息管理方法及装置、电子设备和非暂态存储介质
CN114265887A (zh) 一种维度数据处理方法、装置、存储介质及电子设备
CN114860819A (zh) 商业智能系统的构建方法、装置、设备和存储介质
CN113901046A (zh) 虚拟维度表构建方法及装置
CN114155038B (zh) 受疫情影响用户识别方法
CN111353288B (zh) 报表处理方法、系统、装置和计算机可读存储介质
CN115423595B (zh) 文件信息处理方法、装置、计算机设备和存储介质
CN110765118B (zh) 一种数据的修订方法、修订装置及可读存储介质
CN118134665A (zh) 自动化计量方法、装置、设备、介质和程序产品

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