构建银行数据仓库经验谈

构建银行数据仓库经验谈

建设银行云南省分行鲍立瑾

建设银行安徽省分行汪旭

数据仓库技术的实现方式

作为一项数据管理领域的新技术，数据仓库的精髓在于针对联机分析处理（OLAP）提出了一种综合的解决方案，但与以往很多技术不同的是，它主要是一种概念，在此概念指导下完成系统的构造。既没有可以直接购买到的现成产品，也没有具体的分析规范和实现方法，也就是说没有成熟、可靠且被广泛接受的数据仓库标准。在以往关系数据库的设计和实现中，不仅有详细的理论推导，还有无数的设计实例，无论你使用的是什么公司的数据库产品、开发工具，只要按照规范做，那么实现同一业务需求的方案都会很相似。而现有数据仓库的实现中，出现了MOLAP方案和ROLAP方案的区别，出现了形形色色的数据仓库建模工具、表现工具，而设计人员的个人经验和素质也会在其中扮演很重要的角色。

笔者认为目前在数据仓库技术的实际应用中应包括如下几种具体实现方式。

一、在关系数据库上建立数据仓库（ROLAP）

二、在多维数据库上建立数据仓库（MOLAP）

上述两种方案的区别在于存储技术，究竟是使用多维数据库还是传统的关系数据库。

MOLAP方案是以多维方式来组织数据，以多维方式来存储数据；ROLAP方案则以二维关系表为核心表达多维概念，通过将多维结构划分为两类表：维表和事实表，使关系型结构能较好地适应多维数据的表示和存储。在多维数据模型的表达方面，多维矩阵比关系表更清晰且占用的存储更少，而通过关系表间的连接来查询数据的ROLAP系统，系统性能成为最大问题。MOLAP方案比ROLAP方案要简明，索引及数据聚合可以自动进行并自动管理，但同时丧失了一定的灵活性。ROLAP方案的实现较为复杂，但灵活性较好，用户可以动态定义统计和计算方式，另外能保护在已有关系数据库上的投资。

由于两种方案各有优劣，因此在实际应用中，往往将MOLAP和ROLAP结合使用，即所谓的混合模型。利用关系数据库存储历史数据、细节数据或非数值型数据，发挥关系数据库技术成熟的优势，减少花费，而在多维数据库中存储当前数据和常用统计数据，以提高操作性能。

三、在原有关系库上建立逻辑上的数据仓库

由于目前正在运行的OLTP系统中已经积累了海量数据，如何从中提取出决策所需的有用信息就成为用户最迫切的需要。新建数据仓库固然能从功能、性能各

方面给出一个完整的解决方案，但需要投入大量的人力、物力，并且数据仓库的建设和分析数据的积累需要一段时间，无法及时满足用户对信息分析的迫切需要。因此在筹建数据仓库的前期，可以采用一些合适的表现工具，在原有OLTP系统上建立起一个逻辑的数据仓库系统。尽管由于原有OLTP系统设计上的局限性，这样的系统可能无法实现很多分析功能，但这样一个系统中数据结构固定、信息分析需求相对稳定成熟，因此数据仓库的建模、实现过程会相对容易、便捷；同时，这样的系统也会成为将来真正数据仓库建设的原型。

信息系统与数据仓库的关系

由于数据量大、数据来源多样化，在商业银行构建管理信息系统时，不可避免地会遇上如何管理这些浩如烟海的数据，以及如何从中提取有用的信息的问题；而数据仓库的最大优点在于它能把企业网络中不同信息岛上的商业数据集中到一起，存储在一个单一的集成的数据库中，并提供各种手段对数据进行统计、分析。因此可以说，在银行使用数据仓库构建管理信息系统，既有压力，又有数据基础，它们之间的联系是必然的，难以割舍的。

数据仓库在商业银行的应用范围包括存款分析、贷款分析、客户市场分析、相关金融业分析决策（证券、外汇买卖）、风险预测、效益分析等。

笔者认为在银行信息系统构建时，由于历史情况和现实需求的不同，存在两种途径：

一、建设新系统

由于目前国内商业银行对银行内部运营的监管，缺乏很好的数据搜集机制，因此可以在构建管理信息系统时，分数据收集录入和数据汇总分析两部分来考虑。这样的系统中由于不需考虑大量历史数据的处理问题，同时考虑到搜集过程中可能存在多个数据来源，因此可以在系统建设的同时构建数据仓库，将搜集来的各种数据通过数据抽取整合到数据仓库中。

二、完善原有系统

而对于已经存在OLTP系统，其中沉淀了大量历史数据，则可以先在原有系统上建立逻辑数据仓库，即使用数据分析的表现工具，在关系模型上构建一个虚拟的多维模型。当系统需求稳定后，再建立物理数据仓库，这样既节省投资，又缩短开发工期。

实现中需要注意的问题

笔者曾参加中国建设银行信贷管理信息系统的开发，是其中数据仓库应用的主要设计和开发人员。建行信贷系统中的数据仓库采用的是ROLAP方案，后台使用INFORMIX Online存储海量数据，前端使用Business Objects作为数据分析、数据挖掘的表现工具。根据建行信贷业务的特点，将逻辑模型分为五大主题：合同、项目、客户、机构和清分，其中客户中又分为客户经营信息和客户

信贷信息两大部分。现结合开发中遇到的问题，总结使用关系数据库来实现数据仓库、构建银行管理信息系统的经验。

一、模型设计中的问题

模型设计（包括逻辑模型设计和物理模型设计）是系统的基础和成败的关键，在实际操作中，视实现技术的不同应分别对下列问题引起注意。

1、直接构建数据仓库

直接构建数据仓库时，必须按业务分析的要求重组OLTP系统中的数据，并要按不同侧重点分别组织，使之便于使用。

＊主题的确定

主题是一个逻辑概念，它应该能够完整、统一地刻画出分析对象所涉及的各项数据以及相互联系。划分主题的根据主要来源于两方面：对原有固定报表的分析和对业务人员的访谈。原有固定报表能较好地反映出以往工作对数据分析的需求，而且数据含义和格式相对成熟、稳定，在模型设计中需要大量借鉴。但仅仅满足于替代目前的手工报表还远远不应是构建管理信息系统的目标，还应该通过业务访谈，进一步挖掘出日常工作中潜在的更广、更深的分析需求。只有这样，才能真正了解构建数据仓库模型所需的主题划分。

＊分析内容的细化

主题的划分实际上是与分析内容的范围直接相关的，一旦主题划分清楚了，下一步就是细化分析的具体内容以及根据分析内容的性质确定它在数据仓库中的位置。通常维元素对应的是分析角度，而度量对应的是分析关心的具体指标。一个指标究竟是作为维元素、度量还是维属性，取决于具体的业务需求，但从实际操作中可以总结出如下的概念性经验：作为维元素或维属性的通常是离散型的数据，只允许有限的取值；作为度量的是连续型数据，取值无限。如果一定要用连续型数据作为维元素，则必须对其按取值进行分段，以分段值作为实际的维元素。判断分析指标是作为维元素还是维属性时，则需要综合考虑这个指标占用的存储空间与相关查询的使用频度。

需要特别强调的是，在细化分析内容的过程中，务必解决指标的歧义问题。在不同报表中以及在业务访谈中同一名称的指标，是否是在同样条件限定下，通过同样方法提取或计算得到的，它们之间的相互关系是什么，这些问题都必须从熟悉业务的分析人员那里得到准确、清晰的答案，否则将会影响到模型设计、数据提取、数据展现等多个方面。

＊粒度的设计

数据仓库模型中所存储的数据的粒度将对信息系统的多方面产生影响。事实表中以各种维度的什么层次作为最细粒度，将决定存储的数据能否满足信息分析