基于Oracle Hyperion的滚动预算系统及方法

摘要

本公开揭示了基于Oracle Hyperion的数据处理系统及方法，特别是一种滚动预算数据处理系统及方法，系统涉及如下：设置单元、匹配及设计单元、外部连接单元、历史数据解析单元、存储单元。通过本公开，其实现了如下技术效果：利用Oracle Hyperion对不同系统的源数据库进行统一多维数据处理，可用于保险领域的滚动预算。

说明书

技术领域

本公开涉及数据处理领域，特别涉及一种基于Oracle Hyperion的数据处理系统、方法，尤其用于滚动预算方面的技术方案。

背景技术

随着信息化在各个行业的日趋盛行，企业为满足其管理需要，已经通过现代化的信息技术搭建了众多的数据源，但将这些海量数据用于综合性管理活动时，存在缺乏多维数据的存储平台，数据规范性程度不高，多维数据的展现、计算工作量巨大，现有聚合数据在不同年度口径不一致导致二次利用效果较差，数据背后信息难挖掘，等等问题。

特别是在保险、银行等金融领域，这种问题更加严重。具体表现为：由于上述金融领域涉及销售、运营、利润、支出等经营管理各个环节的数据分散在多个系统中，那么以滚动预算管理这种综合性管理为例，其预测准确性和预算管理对经营决策的响应能力随之就受到了挑战。

发明内容

为了解决数据分散在多个系统的数据处理问题以及滚动预算的问题，特别是保险领域的滚动预算方面的上述技术问题，本公开揭示了一种基于Oracle Hyperion的数据处理系统，包括：

设置单元，其用于：在Oracle Hyperion中设置目标数据库所需的多个维度ID，其中所述目标数据库与Oracle Hyperion默认连接，且所述目标数据库包括多个表单；

匹配及设计单元，其用于：根据各个表单的功能需求，从所述多个维度ID中选择与所述目标数据库中各个表单匹配的维度ID，以对所述各个表单的维度ID进行设计；

外部连接单元，其用于建立Oracle Hyperion与其外部的、多个不同源数据库的连接；

历史数据解析单元，其用于：从所述外部的、多个不同源数据库的历史数据中解析相应的历史数据ID，并将所述历史数据ID匹配到所述匹配及设计单元所设计的各个表单中对应的维度ID；

存储单元，其用于：通过所述历史数据解析单元，存储单元从所述外部的、多个不同源数据库获取所述历史数据并将其存储到所述目标数据库中的各个表单。

此外，本公开还揭示了一种基于Oracle Hyperion的数据处理方法，包括如下步骤：

S100、在Oracle Hyperion中设置目标数据库所需的多个维度ID，其中所述目标数据库与Oracle Hyperion默认连接，且所述目标数据库包括多个表单；

S200、根据各个表单的功能需求，从所述多个维度ID中选择与所述目标数据库中各个表单匹配的维度ID，以对所述各个表单的维度ID进行设计；

S300、建立Oracle Hyperion与其外部的、多个不同源数据库的连接；

S400、从所述外部的、多个不同源数据库的历史数据中解析相应的历史数据ID，并将所述历史数据ID匹配到步骤S200设计的各个表单中对应的维度ID；

S500、根据步骤S400匹配的结果，从所述外部的、多个不同源数据库获取所述历史数据并将其存储到所述目标数据库中的各个表单。

通过本公开的技术方案，可以充分、高效的利用Oracle Hyperion的计算能力和其他优点，对来自于不同系统的不同源数据库进行统一的多维数据处理，既可以通过浏览器来访问，也可以通过Excel等软件来访问，还可以根据用户级别分配不同的使用权限。这不仅有利于进一步实现数据的聚集和深度挖掘，以便不同系统的数据汇总到Hyperion进行统一处理，特别是滚动处理。此外，也有利于综合利用Oracle Hyperion落实数据管理职责。

附图说明

图1为本公开一个实施例中的示意图；

图2为本公开另一个实施例中的示意图。

具体实施方式

下面将结合各个实施例及有关附图1-2，对各个实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本公开一部分实施例，而不是全部的实施例。基于本公开中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本公开保护的范围。

参见图1，在一个实施例中，本公开揭示了基于Oracle Hyperion的数据处理方法，包括如下步骤：

S100、在Oracle Hyperion中设置目标数据库所需的多个维度ID，其中所述目标数据库与Oracle Hyperion默认连接，且所述目标数据库包括多个表单；

S200、根据各个表单的功能需求，从所述多个维度ID中选择与所述目标数据库中各个表单匹配的维度ID，以对所述各个表单的维度ID进行设计；

S300、建立Oracle Hyperion与其外部的、多个不同源数据库的连接；

S400、从所述外部的、多个不同源数据库的历史数据中解析相应的历史数据ID，并将所述历史数据ID匹配到步骤S200设计的各个表单中对应的维度ID；

S500、根据步骤S400匹配的结果，从所述外部的、多个不同源数据库获取所述历史数据并将其存储到所述目标数据库中的各个表单。

对于上述实施例，很明显的，上述实施例并不会受限于数据的含义，无论是行业中的含义还是其他属性的含义，此外：

其一，该实施例属于基于Oracle Hyperion的二次数据处理；

其二，步骤S100、S200体现了维度设置和表单设计这两个本实施例的核心思想；

其三，步骤S300至S500则实现了从外部的、不同的源数据库获取数据并匹配、存储到Hyperion下的目标数据库的各个表单；

也就是说，上述实施例实现了从外部不同系统的数据库来获取数据、汇总到Hyperion下的一个目标数据库的目标，从而实现了基于Oracle Hyperion的数据处理方法。显然的，该实施例综合利用Oracle Hyperion，使得不同系统的数据能够汇总到Hyperion进行统一处理，既有利于充分挖掘不同系统的数据、也有利于充分挖掘Hyperion的计算优势并提高Hyperion的利用率，更有利于围绕Oracle Hyperion来打通各个系统的数据壁垒，从而实现统一的多维数据存储方法、便于后续各种数据挖掘。其中，所述设计可以是不限于各个表单的维度ID的数据格式或数据类型、或默认数值的那些设计、初始化等。

优选的，在另一个实施例中，所述方法还包括如下步骤：

S600、建立各个表单内维度ID之间、跨表单的维度ID之间的计算规则；

S700、对于步骤S400执行后、各个表单中存在的如下所述未匹配维度ID：与任何一个历史数据ID都没有匹配关系的维度ID，则根据所述计算规则，进行表单内计算或跨表计算，以生成与所述未匹配维度ID关联的数值并存储到相应的表单中。

就该实施例而言，其侧重于统一多维数据存储后，可能存在的如下技术问题：如何获得那些需要计算的数据，而这些数据并不在原来的源数据库中存在，但是这些需要计算的数据是能够依赖原有的源数据库的某些维度有关的数据来计算的。该实施例所侧重的这一技术问题往往出于数据挖掘的需要，本领域技术人员可能需要结合不同的数据挖掘的需要来计算这些数据。

值得关注的是，该实施例给出了表内计算和跨表计算的两种方式，这体现了该实施例的技术效果，即不限于表内计算来获得需要计算的数据。

优选的，在另一个实施例中，当需要获得那些需要计算的数据时，也可通过如下方式实现表内计算和跨表计算：

与步骤S700所述的未匹配维度ID相对的，则为步骤S400匹配后所谓的已匹配维度ID，而对于每个要计算的所述的未匹配维度ID所关联的数据，只需要根据计算规则，遍历所有表单中的已匹配维度ID，以找到符合计算规则的那些维度ID，一旦找到，则利用其关联的数据和计算规则来进行计算，以获得那些需要计算的数据。

更优选的，在另一个实施例中，可通过如下方式实现表内计算和跨表计算：

预先对计算规则进行明确的设置，使得在计算规则中明确计算所需的有关维度ID，以及有关的各个表单自身的表单ID，和所述有关维度ID与各个表单ID的隶属关系。

更优选的，也可以预先设置所述有关维度ID在各个表单中的具体定位信息。

毫无疑问，上述技术手段能够使得不论是通过表内计算来获得有关需要的数据，还是通过跨表计算来获得有关需要的数据，都不受限于表内，且能够保证计算过程中更加快速的访问到有关维度ID及其关联数据，从而一定程度上节省计算所需的时间。

更优选的，在另一个实施例中，无论是对于上述通过遍历的技术方案还是上述通过预先对计算规则进行明确的设置，都可以在获得那些需要计算的数据的同时，继续遍历各个表单以查找与所述计算的数据存在关联的维度ID及其数据，以便通过别的维度对已经计算的数据进行复核和验证，从而验证数据的一致性、增强数据的准确性。

优选的，在另一个实施例中，所述步骤S100还包括如下子步骤：

S101、设置与每个维度ID关联的数值的数据格式，以及各个维度ID的父子关系。

容易理解，此实施例是为了便于数据的统一、多维度存储，实现对于不同数据格式的不同处理；而明确维度ID的父子关系，则是更多为了数据深度挖掘考虑，从而有利于快速从父维度找到子维度，或者反之，这对于具有父子关系的多维度数据处理，是有益的，至少能够提高数据定位的速度，节约数据处理的时间开支，也有利于数据维度关系的整理，便于后续数据处理。

优选的，在另一个实施例中，所述步骤S400中的所述历史数据包括财务预算历史数据，所述历史数据ID包括财务预算历史数据ID。或者，所述步骤S400中的所述历史数据包括绩效历史数据，所述历史数据ID包括绩效历史数据ID。

就该实施例而言，其意在限定历史数据在不同具体细分技术领域内所可能包括的各种数据类型。该实施例针对的是除了预算数据处理(下文另外记载有预算数据处理方面，特别是保险领域的滚动预算方面)之外的绩效管理，特别是绩效数据处理，即该实施例限定了绩效数据处理这一应用场景下历史数据的有关内容。绩效历史数据，指的是已经发生过的绩效数据，这些数据是来自于外部的、不同源数据库的，被汇总到Hyperion来按照本公开的发明构思来进行数据处理。如果常规应用场景设定为保险领域，那么：财务预算历史数据包括周边业务历史数据和财务核心历史数据，详见下文有关实施例。实际上，除了能够很好的用于保险领域的预算、考核数据处理之外，Hyperion还能够用于资源配置、盈利预测等企业管理的需要。

优选的，在另一个实施例中，所述步骤S300是通过Web Service连接所述外部的、多个不同源数据库。例如，通过Oracle Hyperion的自有Web Service API，或者另行自定义Web Service或其他合适接口。

对于该实施例，其揭示了Oracle Hyperion连接不同源数据库的技术方案，这也再次反映了本公开的技术方案是基于Oracle Hyperion来具体一步步实现的，而不是任何的本领域常用技术手段。

优选的，在另一个实施例中，根据设置的滚动间隔周期t，每隔一个所述滚动间隔周期t，滚动执行一次所述步骤S500。

对于该实施例，其意在将前述有关实施例应用于以滚动方式处理的数据方面，因为：一方面，外部的、多个不同源数据库往往不断的在更新数据；另一方面，数据可能是预算数据或绩效数据或者其他具备预测性的企业管理数据，也存在很强的滚动处理的需求。需要说明的是，所述执行一次，通常情况下涉及到原有数据依然需要继续保留。

优选的，在另一个实施例中，所述方法还包括如下步骤：

S800：运行一Web浏览器，并且建立所述Web浏览器与Oracle Hyperion的连接，使得通过该Web浏览器来访问所述目标数据库中的各个表单。

优选的，在另一个实施例中，所述方法还包括如下步骤：

S900：运行一表格处理软件的插件(例如Microsoft Office系列的Excel)，并且建立所述表格处理软件与Oracle Hyperion的连接，使得通过该表格处理软件来访问所述目标数据库中的各个表单。

对于上述涉及Web浏览器、表格处理软件的实施例，其表明本公开所述实施例可用于互相的连接甚至是操作，便于部署各种访问架构，无论是BS架构还是CS架构。此外，Web浏览器、表格处理软件皆属于用户一侧熟悉的应用软件，特别是Web浏览器使得本公开实施例具备云计算的潜质，而传统表格处理软件，例如Excel则具备强大的本地计算能力，便于数据的进一步后期处理。

优选的，在另一个实施例中：根据设置的滚动间隔周期t，每隔一个所述滚动间隔周期t，滚动执行一次所述步骤S500，以及步骤S700。

与前一个实施例类似，该实施例额外包括了对要计算的那些数据的滚动处理。

优选的，在另一个实施例中，

所述财务预算历史数据包括周边业务历史数据和财务核心历史数据，所述历史数据ID包括周边业务历史数据ID和财务核心历史数据ID；并且，

根据设置的滚动间隔周期t，每隔一个所述滚动间隔周期t，滚动执行一次所述步骤S500，以及步骤S700。

就该实施例而言，针对具体细分的保险业务领域，对财务预算历史数据、历史数据ID等进行了具体适应性限定，并通过滚动间隔周期t实现了不同源数据库以滚动的方式、汇总到Hyperion下以便进行统一的多维数据处理，并进一步实现了对需要通过计算规则来生成的数据进行滚动处理，从而在保险业务领域，实现了基于Oracle Hyperion的滚动预算。需要说明的是，此处滚动间隔周期t可以是6个季度或者其他时间间隔，这些具体设置都仅仅是示例而不作为对有关实施例的限定。

更优先的，在另一个实施例中，

所述周边业务历史数据包括如下保险领域的历史数据：准备金系统的历史数据、收付费系统的历史数据、再保系统的历史数据、理赔系统的历史数据；

所述滚动周期间隔t为6个季度；

所述维度ID包括如下维度的ID：年、期间、组织、科目、险种、渠道、业务类型、分保类型、情景、版本、数据类型。

对于该实施例，其针对保险领域，明确限定了历史数据的具体选择，还明确限定了保险领域滚动预算方面的具体维度ID，这些历史数据的具体选择和具体维度ID均为保险领域的本领域技术人员所知。换言之，本实施例显然是与具体业务数据有关，如果将来具体保险业务中发生了变化，那么本实施例也依然适用，本实施例只需要做简单的适应性变化即可。

更优选的，在另一个实施例中，

所述表单包括一个利润表，且所述各个表单按模块划分的话，所有模块累计起来，至少包括如下模块：产品线模块、再保模块、理赔模块、精算模块、财会模块；

所述周边业务历史数据包括如下保险领域的历史数据：准备金系统的历史数据、收付费系统的历史数据、再报系统的历史数据、理赔系统的历史数据；

所述滚动周期间隔t为1个季度；

所述维度ID包括如下维度的ID：年、期间、组织、科目、险种、渠道、业务类型、分保类型、情景、版本、数据类型。

就该实施例而言，其针对保险领域的利润的滚动预算，可以通过Hyperion对来自不同源数据库的数据进行汇总后，以上述表单实现模块化数据处理，并基于这些模块来对利润表的所有科目进行每1个季度滚动预测一次。

更优的，参见图2，其针对组织为某地保险公司、险种为商业车险，给出了一个自2016年6月至2017年12月之间，按季度滚动预算的具体实施例，对该图2的有关说明和计算规则的公式说明，如下：

说明：

1、本表由省公司或地市公司各险种责任部门填报；

2、单位：万元；

3、填报内容：存量保单和6个季度新增保单在各预算期内的保费资金到账金额。需要针对该实施例说明的是，就保险领域的预算编制而言，由于从其他系统接入的源数据更多是预算编制的参考数据，因此预算编制必然涉及一些手工录入信息，此处的填报内容，指那些需要手工录入的信息；

4、表内计算：[应收保费]、[应收保费率]由根据本表单的计算规则计算得出；

5、表间计算：[保费收入]、[过去12个月保费收入]由本系统其它预算表单计算得出；

6、外部数据获取：[存量保单]的[应收保费]从核心财务系统获取；

就图2而言，如下公式仅作为保险领域中某些计算规则的示例而不是限定：

1、[不区分业务类型]的[应收保费]＝[存量保单]的[应收保费]+[当期保单]的[保费收入]-当前预算期的存量和新签单的[应收保费累计到账金额]之和；

2、[过去12个月保费收入]＝[过去9个月保费收入]+[当季保单保费收入]，过去9个月保费收入从核心财务系统获取，[当季保单保费收入]由本系统其它预算表单计算得出；

3、[应收保费率]＝[应收保费]/[过去12个月保费收入]。

更优选的，在另一个实施例中，所述方法还包括如下步骤：

S1000：对前述各个步骤、和/或各个表单、和/或各个维度进行用户权限的设置。

对于该实施例而言，其表明本公开的技术方案具备完整的用户权限管理，无论是在步骤层面，还是表单层面，还是维度层面，只要应用场景需要控制用户的权限，甚至是用户的等级，那么均能够实现相应的控制，典型的权限包括：读、写、执行，推而广之的，还可以进一步丰富为：修改、删除等。

与前述实施例类似的，本公开还揭示了如下一组数据处理系统的实施例：

在另一个实施例中，本公开揭示了基于Oracle Hyperion的数据处理系统，包括：

设置单元，其用于：在Oracle Hyperion中设置目标数据库所需的多个维度ID，其中所述目标数据库与Oracle Hyperion默认连接，且所述目标数据库包括多个表单；

匹配及设计单元，其用于：根据各个表单的功能需求，从所述多个维度ID中选择与所述目标数据库中各个表单匹配的维度ID，以对所述各个表单的维度ID进行设计；

外部连接单元，其用于建立Oracle Hyperion与其外部的、多个不同源数据库的连接；

历史数据解析单元，其用于：从所述外部的、多个不同源数据库的历史数据中解析相应的历史数据ID，并将所述历史数据ID匹配到所述匹配及设计单元所设计的各个表单中对应的维度ID；

存储单元，其用于：通过所述历史数据解析单元，存储单元从所述外部的、多个不同源数据库获取所述历史数据并将其存储到所述目标数据库中的各个表单。

对于上述实施例，很明显的，上述实施例并不会受限于数据的含义，无论是行业中的含义还是其他属性的含义，此外：

其一，该实施例属于基于Oracle Hyperion的二次数据处理；

其二，设置单元、匹配及设计单元这两个单元体现了维度设置和表单设计这两个本实施例的核心思想；

其三，上述实施例中的其余单元则实现了从外部的、不同的源数据库获取数据并匹配、存储到Hyperion下的目标数据库的各个表单；

也就是说，上述实施例实现了从外部不同系统的数据库来获取数据、汇总到Hyperion下的一个目标数据库的目标，从而实现了基于Oracle Hyperion的数据处理系统。显然的，该实施例综合利用Oracle Hyperion，使得不同系统的数据能够汇总到Hyperion进行统一处理，既有利于充分挖掘不同系统的数据、也有利于充分挖掘Hyperion的计算优势并提高Hyperion的利用率，更有利于围绕Oracle Hyperion来打通各个系统的数据壁垒，从而实现统一的多维数据存储系统、便于后续各种数据挖掘。其中，所述设计可以是不限于各个表单的维度ID的数据格式或数据类型、或默认数值的那些设计、初始化等。

优选的，在另一个实施例中，所述系统还包括：

计算规则建立单元，其用于建立各个表单内维度ID之间、跨表单的维度ID之间的计算规则；

计算单元，其用于：根据历史数据解析单元的解析结果，对于各个表单中存在的如下所述未匹配维度ID：与任何一个历史数据ID都没有匹配关系的维度ID，所述计算单元利用计算规则建立单元中的计算规则，进行表单内计算或跨表计算，以生成与所述未匹配维度ID关联的数值并存储到相应的表单中。

更优选的，在另一个实施例中，所述设置单元还包括如下子单元：

格式及父子关系设置单元，其用于设置与每个维度ID关联的数值的数据格式，以及各个维度ID的父子关系。

更优选的，在另一个实施例中，所述历史数据包括财务预算历史数据，所述历史数据ID包括财务预算历史数据ID。

更优选的，在另一个实施例中，所述历史数据包括绩效历史数据，所述历史数据ID包括绩效历史数据ID。

更优选的，在另一个实施例中，所述外部连接单元是通过Web Service来连接所述外部的、多个不同源数据库。

更优选的，在另一个实施例中，根据设置的滚动间隔周期t，每隔一个所述滚动间隔周期t，所述存储单元滚动执行一次。

更优选的，在另一个实施例中，所述系统还包括如下单元：

浏览器运行单元，其用于：运行一Web浏览器，并且建立所述Web浏览器与Oracle Hyperion的连接，使得通过该Web浏览器来访问所述目标数据库中的各个表单。

更优选的，在另一个实施例中，所述系统还包括如下单元：

表格运行单元，其用于：运行一表格处理软件的插件(例如Microsoft Office系列的Excel)，并且建立所述表格处理软件与Oracle Hyperion的连接，使得通过该表格处理软件来访问所述目标数据库中的各个表单。

更优选的，在另一个实施例中，根据设置的滚动间隔周期t，每隔一个所述滚动间隔周期t，滚动执行一次所述存储单元和计算单元。

更优选的，在另一个实施例中，所述财务预算历史数据包括周边业务历史数据和财务核心历史数据，所述历史数据ID包括周边业务历史数据ID和财务核心历史数据ID；并且，

根据设置的滚动间隔周期t，每隔一个所述滚动间隔周期t，滚动执行一次所述存储单元和计算单元。

更优选的，在另一个实施例中，所述周边业务历史数据包括如下保险领域的历史数据：准备金系统的历史数据、收付费系统的历史数据、再保系统的历史数据、理赔系统的历史数据；

所述滚动周期间隔t为1个季度；

所述维度ID包括如下维度的ID：年、期间、组织、科目、险种、渠道、业务类型、分保类型、情景、版本、数据类型。

更优选的，在另一个实施例中，对于所述滚动周期间隔t，通过确定预算的起期、止期(例如从2016年7月1日到2017年12月31日)，来确定滚动预算期次(例如滚动6个季度)，每期预算跨度则为1个季度，即3个月。

更优选的，在另一个实施例中，所述系统还包括：

权限设置单元，用于对其余单元、和/或各个表单、和/或各个维度进行用户权限的设置。

本说明书中每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。此外，本说明书对所公开的实施例的上述说明，已使本领域专业技术人员能够实现或使用本公开。对这些实施例的多种不经创造性劳动的修改，对本领域的专业技术人员来说将是显而易见的。此外，本文中所定义的一般原理可以在不脱离本公开的精神或范围的情况下，在其它实施例中实现。因此，本公开将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。