数据存储方法及数据仓库系统与流程

本发明涉及数据存储技术领域，尤其涉及一种数据存储方法及数据仓库系统。

背景技术：

数据仓库，由数据仓库之父Bill Inmon于1990年提出，主要功能是将企业组织通过联机交易的事务处理数据经年累月所累积的大量资料，透过数据仓库理论所特有的资料储存架构，作系统性的分析整理存储，并进而逐步构建出更专注、更细领域的数据集市，支持如决策支持系统的创建，帮助决策者能快速有效的自大量资料中，分析出有价值的资讯，以利决策拟定及快速回应外在环境变动，帮助建构商业智能。图1是现有技术的INMON式数据仓库结构图，通常情况下，INMON思路的数据仓库是自上而下三层数据结构，包括：应用集市、数据仓库和源系统数据。类似的有Kimball提出的自下而上的数据仓库构建理论。

金融服务逻辑数据模型(Financial Services Logical Data Model，简称为FS-LDM)是由TERADATA公司提出的在数据仓库的数据建设阶段为解决业务需求而定义的数据仓库模型解决方案，是可预先构建的，是一个成熟的产品框架，利用该模型可以直接开始数据仓库模型设计，该模型是指导数据仓库进行数据存放、数据组织、以及如何支持应用的蓝图，定义需要追踪和管理的各种重要实体、属性、关系。目前，FS-LDM基础模块包含10大实体对象，分别为：当事人、产品、协议、机构、事件、营销、渠道、区域、财务和资产。其中，当事人是指单个人或一组人；产品是指一种可以在市场上交易的产品或服务，包括条款或条件；协议是指在客户和金融机构之间达成的关于特定产品的协议；机构是指金融机构或保险公司内部的业务单元；事件是指会导致同客户达成合同的金融或非金融的事件；营销是指为了获取、挽留客户或提高用户的使用率而采取的战略、计划或促销活动；渠道是指客户和金融机构或保险公司进行接触的途径；区域是指地理区域，物理的或电子的地址；财务是指企业内部的会计系 统；资产是指当事人所有的具有价值且能够获得受益的事物。类似的其他厂商如IBM有银行业数据仓库模型(Banking Data Warehouse Model，简称为BDWM)。

目前传统的三层架构的数据仓库结构，在完整的生命周期过程中，表现出来的特点为源系统的个数，以及每个系统的数据在不断的增加，数据仓库由于采用FS-LDM(或BDWM)等比较稳定的数据架构，调整的幅度较少，在最下游的应用集市层上，业务的分析视角、分析深度不断扩展，从而应用集市也不断的增加数量和扩展数据加工量，从而容易出现以下问题：

(1)数据孤岛：在数据仓库的FS-LDM上构建的应用集市数量较多，应用集市之间的数据独立性较高，存在较多的“自建自用”情况，甚至存在“竖井式”的应用集市，如图2所示，A集市的数据加工深度相较于B、C两个集市来说较深，A是独立加工，所以A集市里面大量的数据，对外存在不透明性。

(2)重复加工：虽然目前架设在FS-LDM上的应用集市较多，但是由于集市间的不透明，每个集市内有多层数据加工，而这个加工过程，可能存在大量和其他应用集市相同或相似的数据加工步骤，如图2所示，假设A有6个数据加工层次，B有2个数据加工层次，C有1个数据加工层次，可能存在A的第二层和B的第一层同样都是加工客户的资产数据，A的第三层和C的第一层同样都是加工客户的产品持有信息，即同样的业务含义数据重复加工。

(3)数据差异：各应用独自加工的情况下，业务含义一致而规则不统一，则出现数据差异问题，如(2)中所述，可能存在A的客户资产信息、客户产品持有信息对外展示的结果和B的客户资产信息结果、C的客户产品持有信息结果有差异。

(4)成本过高：主要是以上问题的汇总体现，体现在沟通成本高、浪费重复成本、人员培养难度高、维护难度成本高等。

产生上述问题的原因如下：

(1)单独的应用需求驱动化开发

目前应用集市的数据构架过程是下游直接向系统应用供数，上游直接向FS-LDM取数。而应用开发模式则是，直接由应用系统进行需求驱动，应用集市完成数据加工的模式。随着应用集市的不断加工建设，FS-LDM主要只作为数据的提供方，数据的管理职能体现的较少，从而缺乏中间弥补机制，对应用数据的加工进行分离、复用重构处理，对应用需求驱动的内容进行分析整合。

(2)FS-LDM的高度抽象通用

FS-LDM是一个非常成熟的金融建模框架，有较强的通用性，而较强的通用性在对数据进行规划整理的过程中，将不少交易数据高度剥离抽象到实体数据进行存储，从而出现许多应用集市需要做类似数据加工内容，这部分类似的加工内容如没有统一的管理规划过程，则容易引发上述问题。

技术实现要素：

本发明提供了一种数据存储方法及数据仓库系统，以至少解决现有数据仓库系统存在的数据孤岛、重复加工、数据差异、成本过高的问题。

根据本发明的一个方面，提供了一种数据存储方法，包括：确定数据仓库系统中各应用集市之间的独立加工的共性数据；对所述共性数据按照不同业务主题进行分类，存储到对应的主题集市中，其中，所述主题集市位于所述数据仓库系统中的应用集市和基础数据仓库之间，用于向所述应用集市供应数据以及作为所述基础数据仓库的补充；删除各应用集市中存储的所述共性数据。

在一个实施例中，所述共性数据的加工过程和展现逻辑分离，其中，所述展现逻辑是指将不同信息集成到一起；不同共性数据的加工过程通过表解耦。

在一个实施例中，所述数据存储方法采用第三范式和拉链算法。

在一个实施例中，所述应用集市包括应用集市服务器，在所述应用集市服务器中设置宽表形式的数据访问接口。

在一个实施例中，所述方法还包括：所述应用集市服务器通过所述数据访问接口接收来自应用系统的数据读取指令，并根据所述数据读取指令输出数据。

在一个实施例中，在删除各应用集市中存储的所述共性数据之后，所述方法还包括：所述主题集市接收到新增数据，对所述新增数据进行分类，存储到对应的主题集市中。

在一个实施例中，所述主题集市包括：客户主题集市、风险主题集市、绩效主题集市、财务主题集市、公共主题集市；其中，所述公共主题集市存储有对客户主题集市、风险主题集市、绩效主题集市、财务主题集市的公共部分进行整合压缩得到的数据。

根据本发明的另一个方面，提供了一种数据仓库系统，所述数据仓库系统自下而 上包括：源系统数据仓库、基础数据仓库、主题集市和应用集市；其中，所述基础数据仓库中存储来源于所述源系统数据仓库的数据，并对所述数据按照预设的领域进行整合；所述主题集市中存储各应用集市之间的独立加工的共性数据，且所述共性数据按照业务主题进行分类；各应用集市存储的数据之间不存在共性数据。

通过本发明的数据存储方法及数据仓库系统，将各应用集市之间的各自独立加工的共性类深度数据从原来的应用集市中剥离出来，按照不同业务类视角(业务主题)进行整合、重构，使得数据的共享性、可知可视性、一致性大大提高，也大大简化了应用集市的开发难度以及整个仓库批量运维的难度。主题集市是面向业务主题的基础数据组织存储，而不是面向应用的组织存储，能有效隔离业务需求变更对应用系统架构的影响，从而保证数据逻辑框架的稳定性。同时，主题集市强调建立各个应用系统“共建共用”的共享数据集市，有利于消除系统间孤岛式的数据交流，建立统一的数据标准，解决现有技术中数据孤岛、重复加工、数据差异、成本过高的问题。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的限定。在附图中：

图1是现有技术的INMON式数据仓库结构图；

图2是现有技术的数据仓库架构示意图；

图3是本发明实施例的数据存储方法的流程图；

图4是本发明实施例的各主题集市面向应用集市的关系示意图；

图5是本发明实施例的数据仓库系统的结构示意图；

图6是本发明实施例的数据仓库系统的实施架构图；

图7是本发明实施例的客户主题集市的信息框架示意图；

图8是本发明实施例的客户主题集市的数据模块交互图。

具体实施方式

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

本发明实施例提供了一种数据存储方法，图3是本发明实施例的数据存储方法的流程图。如图3所示，该方法包括以下步骤：

步骤S301，确定数据仓库系统中各应用集市之间的独立加工的共性数据。

步骤S302，对共性数据按照不同业务主题进行分类，存储到对应的主题集市中，其中，主题集市位于数据仓库系统中的应用集市和基础数据仓库之间，用于向应用集市供应数据以及作为基础数据仓库的补充。

步骤S303，删除各应用集市中存储的共性数据。

通过上述方法，将各应用集市之间的各自独立加工的共性类深度数据从原来的应用集市中剥离出来，按照不同业务类视角(业务主题)进行整合、重构，使得数据的共享性、可知可视性、一致性大大提高，也大大简化了应用集市的开发难度以及整个仓库批量运维的难度。主题集市是面向业务主题的基础数据组织存储，而不是面向应用的组织存储，能有效隔离业务需求变更对应用系统架构的影响，从而保证数据逻辑框架的稳定性。同时，主题集市强调建立各个应用系统“共建共用”的共享数据集市，有利于消除系统间孤岛式的数据交流，建立统一的数据标准，解决现有技术中数据孤岛、重复加工、数据差异、成本过高的问题。

以业务领域信息模型指引，以明确的业务需求文档、现存应用系统的调研资料做基础，出发点以业务分析极有可能需要、多个应用均需要的，通过完整的体系结构维护，支持文档说明等辅助手段，集中加工、集中发布、集中管理来建设主题集市。

在数据组织方面，数据模型的组织方式延续数据仓库的主题分组。相同类型信息归类存放，和基础数据仓库(FS-LDM)中的数据在模型中共同组织，从而形成统一的业务主题模型，便于信息理解和检索。

在物理分层方面，主题集市和FS-LDM分库存放不同信息。根据不同来源作为划分依据，主题集市存放衍生出来的共性业务信息，FS-LDM存放来源于源系统的数据。两者数据间避免冗余，可以提高衍生出来的共性业务信息的访问时效性(不需要通过数据回流加载到数据仓库)，同时，不影响FS-LDM的完成时间(FS-LDM的完成时间和现有技术一样，只依赖于源系统)。

在一个实施例中，共性数据的加工过程和展现逻辑分离，其中，数据的加工过程是指对杂乱无序的数据根据需要进行排序、筛选、有条件透视等操作；展现逻辑是指 通过JION将不同信息集成到一起。不同共性数据的加工过程通过表解耦。

本实施例中，数据加工模式为减少耦合，降低复杂度。通过这种数据加工模式，提高系统的可维护性，提高加工逻辑的总体稳定性(即局部改变，不影响其它逻辑)。主题集市是一个逐步建设的过程，上述数据加工模式使得主题集市更易于扩展，作为共用的系统，可以保持良好的稳定性。

在一个实施例中，数据存储方法采用第三范式和拉链算法。第三范式有效简化了数据存储量，拉链方式的数据存储，也将每日之间的数据进行了压缩，总体上有效避免数据快速膨胀。

在一个实施例中，应用集市包括应用集市服务器，在应用集市服务器中设置宽表形式的数据访问接口。本实施例中，在对下游应用的供数接口方面，采用宽表形式的数据访问层，通过宽表的整合，简化了应用使用的接口，应用只需要通过单表或双表的简单访问，即可完成相关数据的使用。其中接口层表遵循要求为：数据粒度需要符合所支持的不同应用系统的使用需求，数据模型应保持对应用系统变更的稳定性。

在一个实施例中，上述方法还可以包括：应用集市服务器通过数据访问接口接收来自应用系统的数据读取指令，并根据数据读取指令输出数据。应用系统通过数据访问接口访问数据仓库系统中的应用集市(下游)，读取数据，利于决策者快速有效地从大量数据中分析出有价值的数据，以进行决策及快速回应外在环境的变动。

在一个实施例中，在删除各应用集市中存储的所述共性数据之后，上述方法还可以包括：主题集市接收到新增数据，对新增数据进行分类，存储到对应的主题集市中。本实施例中，将最初的共性数据存储到对应的主题集市，作为初始数据，如果接收到新增数据，对新增数据进行分类，分别存储到对应的主题集市中。

主题集市，也称为业务主题数据集市(Business Domain Data Mart，简称为BDDM)。在一个实施例中，以商业银行业务背景为例，主题集市可以包括：客户主题集市(Customer Related Mart，简称为CRM)、风险主题集市(Enterprise Risk Mart，简称为ERM)、绩效主题集市(Performance Modeling Mart，简称为PMM)、财务主题集市(Financial Modeling Mart，简称为FMM)、公共主题集市。其中，客户主题集市、风险主题集市、绩效主题集市和财务主题集市所主要面向的应用集市情况如图4所示，如，客户主题面向的应用集市包括：对私理财对账单、对公理财系统、贷记卡查询、卡平均余额等；风险主题面向的应用集市包括：贷记卡个人征信、资产负债、 零售反洗钱等；绩效主题面向的应用集市包括：绩效考核系统；财务主题面向的应用集市包括：会计计算、综合报表处理、税费网上支付导出系统等；每一个主题可以简化整合所主要面向的应用集市数据。公共主题集市存储有对客户主题集市、风险主题集市、绩效主题集市、财务主题集市的公共部分进行整合压缩得到的数据。

本实施例中，主题集市是面向业务主题的基础数据组织存储，而不是面向应用的组织存储，能有效隔离业务需求变更对应用系统架构的影响，从而保证数据逻辑框架的稳定性。同时，主题集市是对各个应用系统“自建自用”的数据集市的彻底否定，强调建立各个应用系统“共建共用”的共享数据集市，有利于消除系统间孤岛式的数据交流，建立统一的数据标准，解决现有技术中数据孤岛、重复加工、数据差异、成本过高的问题。

基于同一发明构思，本发明实施例还提供了一种数据仓库系统，可以通过上述实施例所描述的方法实现，用于存储数据。由于数据仓库系统解决问题的原理与数据存储方法相似，因此数据仓库系统的实施可以参见上述方法的实施，重复之处不再赘述。以下所使用的术语，数据仓库和集市可以实现预定功能的软件和/或硬件的组合。以下实施例所描述的系统可以使用软件、硬件、或者软件和硬件的组合来实现。

图5是本发明实施例的数据仓库系统的结构示意图，如图5所示，该数据仓库系统自下而上包括：源系统数据仓库10、基础数据仓库20、主题集市30和应用集市40。下面对该结构进行具体说明。

基础数据仓库20中存储来源于源系统数据仓库10的数据，并对所述数据按照预设的领域进行整合；

主题集市30中存储各应用集市之间的独立加工的共性数据，且共性数据按照业务主题进行分类；

各应用集市40存储的数据之间不存在共性数据。

通过上述数据仓库系统，将各应用集市之间的各自独立加工的共性类深度数据从原来的应用集市中剥离出来，按照不同业务类视角(业务主题)进行整合、重构，使得数据的共享性、可知可视性、一致性大大提高，也大大简化了应用集市的开发难度以及整个仓库批量运维的难度。主题集市是面向业务主题的基础数据组织存储，而不是面向应用的组织存储，能有效隔离业务需求变更对应用系统架构的影响，从而保证数据逻辑框架的稳定性。同时，主题集市强调建立各个应用系统“共建共用”的共享 数据集市，有利于消除系统间孤岛式的数据交流，建立统一的数据标准，解决现有技术中数据孤岛、重复加工、数据差异、成本过高的问题。

数据仓库系统中，各个部分可以通过服务器实现，例如，数据库服务器用于存储，管理服务器用于协调负荷。

以银行为例，源系统包括：账务类系统、业务类系统、渠道类系统、内部管理类系统、基础平台类系统等。其中，账务类系统主要包括核心系统；业务类系统主要包括信贷管理系统、国际业务管理系统、银保通系统、银证通系统、黄金交易系统等银行业务处理系统；渠道类系统包括网上银行、手机银行、微信银行、收单业务管理系统等；内部管理类系统包括内部评级系统、风险管理系统、绩效考核系统、客户关系管理系统等；基础平台类系统包括统一客户信息管理系统、统一用户信息管理系统、企业级押品管理系统、企业级额度管理系统等。

基础数据仓库中存储来源于所述源系统数据仓库的数据，来源于源系统的数据主要是面向交易过程的设计，因此数据管理以流程为主，但这种管理模式并不适用于统计分析，并且不同源系统之间的数据编码等也可能存在冲突或重复。因此，基础数据层建立了一个企业级的数据模型，将多个源系统的数据加载之后，根据其数据特征进行了重新的模型整合，从客户、产品、协议、事件等领域角度进行管理，并解决系统之间的重复或冲突数据。因此，后续对数据的处理过程就大大简化，不需要逐个源系统去了解，也不需要将散落在不同源系统中的数据进行关联整合，更不需要去关注源系统各自不同的数据管理方式，而只需要了解基础模型并通过基础模型进行数据处理。因此，虽然基础数据仓库相对于源系统数据仓库并没有新增任何数据，但其组织形式完全不同于源系统，为数据建立了统一的管理视图，主要是为数据的统计分析服务。

与现有技术中的三层结构相比，本方案的数据仓库系统增加了主题集市层，位于应用集市层和基础数据仓库(FS-LDM)层之间，用于存储各应用集市之间的共性数据，其定位是：作为应用集市层的供应数据集市，同时也作为FS-LDM层分析型数据的补充。另外，对原有的应用集市层的集市数量和集市内容进行了大量简化。

将各应用集市之间，各自独立加工的共性类深度数据从原来的应用集市中剥离出来，按照不同业务类视角(业务主题)进行整合、重构，使得数据的共享性、可知可视性、一致性大大提高，也大大简化了应用集市的开发难度以及整个仓库批量运维的 难度。

为了对上述数据存储方法及数据仓库系统进行更为清楚的解释，下面结合具体的实施例来进行说明，然而值得注意的是该实施例仅是为了更好地说明本发明，并不构成对本发明不当的限定。

以银行领域的数据仓库系统为例，实现方案架构图如图6所示，其中包括两个数据分支和一个数据主干。数据分支包括：元数据和归档区数据。其中，元数据是指数据的数据，主要包括数据的信息，例如，某个指标的含义、上游数据来源、下游应用等信息，以方便数据使用人员快速了解到数据的含义。归档区数据是指多年以上(例如，5年、7年等)的数据，由于不常使用，为节省资源，一般保存在磁带库中作为归档数据。

数据主干包括：源系统层、获取层、集成数据层(含BDDM)、访问层和终端接口层。其中，源系统层是指银行账户类、业务类、内部管理类等系统，它们都是数据仓库的来源系统；获取层从各个源系统把数据抽取出来，并加载到数据仓库中；集成数据层对抽取过来的源系统数据，首先通过基础数据模型进行重组织和整合，然后进入业务领域数据集市进行公共指标的再加工和再处理；访问层将集成数据层的数据，通过数据处理转换成后续应用所需的接口数据格式；终端接口层直接对下游统计分析类系统提供服务的访问接口。

其中，源系统层对应于源系统数据仓库10，集成数据层对应于基础数据仓库20(FS-LDM)和主题集市30，访问层对应于应用集市40。每个数据层之间的交互方式包括：数据访问、数据加载和数据导出。

图6中，元数据中的“DWETL”、“DWDDL”、“DWSDM”是数据管理的三个内容，即数据仓库数据处理信息、数据仓库表结构信息、数据仓库数据映射逻辑信息。FTP/CD表示数据传输的方式和工具，即以FTP方式(File Transfer Protocol，文件传输协议)通过CD进行传输。SDATA表示Source data，源系统数据加载过来之后，会先存储在SDATA区域中。PDATA表示公共数据。ACRM指的是分析型客户关系管理系统，OCRM指的是操作型客户关系管理系统，Data Marts指的是数据集市。

图6所示的架构主要分为以下数据区域：数据缓冲区、数据整合区、数据应用区和历史数据区。以下分别进行说明。

数据缓冲区(对应于获取层)是数据仓库的临时数据存放区，作为数据仓库后续 数据处理过程的数据源，其数据模型完全按照上游源系统的结构定义。针对上游源系统不同的数据卸载方式，目前数据仓库采用了全量和增量两种加载策略。根据贴源类(即直接基于SDATA的应用，如生产报表)应用需求，建立了SDATAFULL库对应用所需的增量数据进行全量累积。

数据整合区(对应于集成数据层)是整个数据仓库的核心，由核心基础和领域模型构成。

核心基础这部分是统一的、共享的基础数据，按照第三范式建模规则来组织数据，涵盖企业主要业务范围和相关数据，为下游各种应用提供一致的、规范的数据。核心基础中的实体涵盖当事人、产品、协议、事件、地理区域、渠道、账务、机构、资产、营销十大主题域。

数据仓库除了对来源于外部源系统的数据进行组织和管理外，数据仓库中各个应用还会进行数据的衍生(加工和汇总)处理。为改变各个应用“自建自用”数据衍生加工模式，消除应用间“孤岛式”的数据衍生加工，建立统一数据标准，在核心基础层建立了业务领域数据集市，通过业务需求为驱动，以业务视角为导向，集中加工、集中发布和集中管理各类应用共性衍生的数据，实现“共建共用”。

数据应用区(对应于访问层)是数据仓库对外系统提供数据服务的窗口，基于数据接口、数据分发等方式对外提供数据服务。在数据架构中，应用层在数据组织上，将更密切地按照业务领域数据集市来开发建设应用数据层，充分利用公共衍生和业务领域衍生所沉淀的共享衍生数据。

根据数据生命周期管理原则，历史数据可进一步细分为近线数据和归档数据。其中，归档数据统一上磁带库。近线数据存储在专门的数据库中，关注的是高压缩比和低成本，同时兼顾部分低时效性历史数据查询需求，当需要对历史数据进行操作时，可以从近线数据区快速同步到数据整合区中。

下面介绍具体实施过程中的步骤。

1、方案调研阶段

存量数据重构，对所有存量应用集市的数据进行调研分析，确立相关的重构内容，以及应用集市调整后的接口等。将重构内容按照业务主题，分门别类归至相对应的主题集市范畴。各主题集市以此作为初始化的集市数据。

新增数据整合，按照各应用提交反馈的需求内容，主题集市进行分析整合，并按 照每个主题集市所属范畴进行归至开发，相关分拆需求反馈至应用进行开发。

例如，前述商业银行业务背景下的主题集市建设方案，根据对各个应用集市的调研和梳理，可以分为如下主题：客户管理、风险管理、绩效管理和财务管理。业务领域数据集市也划分为相应的主题集市：客户主题集市、风险主题集市、绩效主题集市和财务主题集市。

2、设计规范阶段

主题集市逻辑模型，应保持相对的稳定性，仍按主题的方式进行分类，基本遵循FS-LDM的十大主题分类方式，同时针对主题集市融入了相关的业务视角，在主题命名上体现相关业务主题的含义，如客户主题集市的客户主题、账户主题、产品主题。客户主题集市(CRM)的信息框架(业务视角清单)如图7所示，CRM涉及以下内容：客户、产品、账户、机构、交易、功能视图、公共代码等。其中，客户包括：财务信息、产品持有、基本属性等；功能视图包括：对公客户账户查询、企业年金等。

3、概要方案设计阶段

对信息框架每个模块的定位和内涵进行说明和明确，同时给出概念性验证模型，模型的详细实体在后续详细设计阶段进行完善。如图8所示，CRM在业务视角清单分析整理后，一方面需要面向多维的分析，涉及多个数据加工粒度；另一方面需要明确落实与FS-LDM的数据接口，逻辑范围来看，客户主题集市中的数据包含FS-LDM基础数据(图8中延伸到EDW基础数据模块中的虚线表示该包含关系)，例如，FS-LDM可以是企业级数据仓库(Enterprise Data Warehouse，简称为EDW)。

4、详设阶段及以后

从详细设计阶段到部署运维阶段，该部分的实施方法均参照现有的FS-LDM标准的批量开发运维等一系列实施标准，此处不再赘述。

综上所述，本发明实施例描述的数据存储方法及数据仓库系统具有以下有益效果：

(1)架构更为符合实际需要，保障长期发展

在较长时间内为企业的信息资源提供稳定的服务，能够支撑相关主题内多个应用系统，并可有效提高应用系统的开发效率，整个架构有较强的健壮性的扩展性，从而避免无序的扩展、人员的不合理使用等问题。基于整合化、多层化、每层扁平化的数据仓库数据架构，批量存储流程得以简化。需求分析阶段，分析人员不再以项目组为 单位，而是以数据仓库整合的需求分析人员做需求整合，再反馈分拆后的需求至应用方，即采用业务需求整合的驱动开发思路。

(2)解决了重复计算、技术口径不一、数据冗余、应用相互依赖的问题

数据仓库的数据产生主要包括基数据衍生、汇总、四则运算等。有些数据的产生规则共性、客观，不融入任何特定的业务主题领域规则，有些则和特定的业务领域规则相关，在数据使用上，将各个集市数据产生和使用(如功能视图、多维展示)有效分离，使数据架构清晰，逻辑结构稳定性强，从而避免了为达到数据可用性可能会增加额外的计算、冗余甚至错误使用。

(3)完整的业务领域信息

通过在需求层面上面的整合处理，能够将各大业务面上的语义完整度、数据处理方式等有效的形成一份完整资料，从而在人员的业务知识培养、相关业务分析等各方面深度管理分析工作中，打造一个完备的平台。

需要说明的是，也可以采用SOA(Service-Oriented Architecture，面向服务的体系结构)方案，该方案可以解决重复计算、技术口径不一、数据冗余、应用相互依赖的问题，提高系统稳定性，但是该方案只适合小规模数据交互式供数以及数据的管理存储不够规范完整。

流程图中或在此以其他方式描述的任何过程或方法描述可以被理解为，表示包括一个或更多个用于实现特定逻辑功能或过程的步骤的可执行指令的代码的模块、片段或部分，并且本发明的优选实施方式的范围包括另外的实现，其中可以不按所示出或讨论的顺序，包括根据所涉及的功能按基本同时的方式或按相反的顺序，来执行功能，这应被本发明的实施例所属技术领域的技术人员所理解。

应当理解，本发明的各部分可以用硬件、软件、固件或它们的组合来实现。在上述实施方式中，多个步骤或方法可以用存储在存储器中且由合适的指令执行系统执行的软件或固件来实现。例如，如果用硬件来实现，和在另一实施方式中一样，可用本领域公知的下列技术中的任一项或他们的组合来实现：具有用于对数据信号实现逻辑功能的逻辑门电路的离散逻辑电路，具有合适的组合逻辑门电路的专用集成电路，可编程门阵列(PGA)，现场可编程门阵列(FPGA)等。

本技术领域的普通技术人员可以理解实现上述实施例方法携带的全部或部分步骤是可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存 储介质中，该程序在执行时，包括方法实施例的步骤之一或其组合。

此外，在本发明各个实施例中的各功能单元可以集成在一个处理模块中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。所述集成的模块如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。

上述提到的存储介质可以是只读存储器，磁盘或光盘等。

在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本发明的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不一定指的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任何的一个或多个实施例或示例中以合适的方式结合。

以上所述的具体实施例，对本发明的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本发明的具体实施例而已，并不用于限定本发明的保护范围，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。