商业银行数据仓库建设摘要：目前国内几大商业银行的数据大集中基本完成，为企业级数据仓库的建设创造了先决条件。
同时，银行管理层也希望从既有的海量数据库中获取信息，可以在精准营销、绩效考核、风险管理等方面发挥作用，这也成为建设企业级数据仓库的主要动力。
结合作者的工作背景，对银行数据仓库建设过程中的几个方面进行了阐述，以期望能对读者有所启发。
关键词：数据仓库；数据模型；数据标准；元数据管理；灵活查询0 引言数据挖掘是20世纪90年代中后期提出的概念，它是以传统的数据库技术作为存储数据和管理资源的基本手段，以统计分析技术作为分析数据和提取信息的有效方法。
以人工智能技术作为挖掘知识和发现规律的科学途径的一种解决问题的方案。
而数据仓库的建设，可以看作数据挖掘的一个重要预处理步骤。
在数据仓库的建设过程中，可以将支持企业日常运作的各个独立系统中的数据进行清理、集成和统一，并且可以将数据加载入不同于日常交易系统结构的易于查询分析的数据模型中，为后续数据挖掘高效地获取准确明晰的数据扫清障碍。
1 数据仓库根据数据仓库之父W.H.Inmon的说法，“数据仓库是一个面向主题的、集成的、时变的、非易失的数据集合，支持管理部门的决策过程”。
这个简短而又全面的定义指出了数据仓库的主要特征。
4个关键词，面向主题的、集成的、时变的、非易失的，将数据仓库与其他数据存储系统（如关系数据库系统、事务处理系统和文件系统）相区别。
数据仓库领域的领导厂商，美国Teradata公司给企业级数据仓库下过一个定义，“一个企业级数据仓库是一个由集成的、明细的、可扩展的数据组成的，集中的，保留历史的数据机，可以支持多个部门的各种决策分析，是整个企业分析型数据的唯一来源”。
这里有5个关键字：集成的、明细的、可扩展的、集中的、保留历史的。
从以上两个定义来看，时变的包含了保留历史的意思，而面向主题的结构保证了其结构和设计是可扩展的。
因此，从笔者的观点来看，数据仓库的关键字应该是：面向主题的、集成的、时变的、明细的、集中的和非易失的。
为了进一步理解数据仓库的概念，我们可以将数据仓库系统和操作型数据库系统进行一下比较，概括在表1中。
2 商业银行数据仓库所谓商业银行数据仓库，是将数据仓库技术运用到商业银行的经营分析中，从而为商业银行的精准营销、绩效考核、风险管理等提供强有力的数据支持。
从技术角度来看，商业银行的数据仓库与其他企业的数据仓库差别不大，具有数据仓库本身具有的一切技术特性。
但是其数据模型的设计，必须与商业银行的业务逻辑相切合，这样才能发挥其应有的作用。
商业银行数据仓库采集包括银行核心系统在内的交易系统数据，经过加载整理，按照银行业务主题（当事人、内部机构、资产、地址、产品、协议、事件、渠道、总账、营销等）进行组织和存储，形成商业银行数据仓库的基础模型区，特点为以数据驱动，保留基础、细节、历史、整合的数据。
3 数据仓库模型3.1 维度模型该模型将数据看作数据立方体(data cube)形式，立方体由维和事实定义。
维是关于一个组织想要记录的透视或实体。
每一个维都有一个表与之相联，该表称为维表，它进一步描述维。
维度数据模型围绕中心主题组织。
该主题用事实表表示。
事实是数值度量的。
把它们看作数量，是因为我们想根据他们分析维之间的关系。
事实表包括事实名称和度量，以及每个相关维表的关键字。
比如，银行想记录客户所持有的账户的相关信息，那么就要建一张账户的事实表来表示账户这个主题。
在账户表中有账户的余额、开户日期、开户机构、账户持有人等信息。
其中，账户余额就是账户表的度量字段。
而开户日期、开户机构等字段则是与其他日期、机构等维表关联的关键字。
3.2 星型模型是维度模型的一种，包括一个大的包含大批数据和不含冗余的中心表（事实表），一组小的附属表（维表），每维一个。
这种模型很像星星爆发，维表围绕中心表显示在射线上。
3.3 雪花模型雪花模型是星型模型的变种，其中某些维表是范式化的，因而把数据进一步分解到附加的表中。
结果模式图形成类似于雪花的形状。
雪花模型和星型模型的主要不同在于，雪花模型的维度可能是范式化形式，以便减少冗余。
这种表易于维护，并节省存储空间，因为当维结构作为列包含在内时，大维表可能非常大。
然而，与巨大的事实表相比，这种空间的节省可以忽略。
此外，由于执行查询需要更多的连接操作，雪花结构可能降低浏览的性能。
这样，系统的性能可能相对受到影响。
因此，在维度建模的数据仓库设计中，雪花模型不如星型模型流行。
3.4 范式化模型根据企业的业务特点，将整个业务流程抽象为若干个主题，主题内部遵循三范式以上的范式进行建模（必要时可以适当降范式），主题与主题间通过关系表连接。
比较类似于雪花纬度模型，但是范式化程度比雪花模型更高，也没有事实表和纬度表的概念。
3.5 商业银行数据仓库模型的选择从理论上来看，维度模型在查询上比较有优势，但是对于业务种类繁多，业务流程复杂的商业银行来说，用维度模型进行存储未必能将各个操作型系统的数据进行很好地整合。
而范式化模型可以将操作系统的各类数据很好地整合存储，但是范式化的结构不利于快速分析查询，需要经过多次的表间联接才能完成一次客户全视图查询。
因此，笔者认为单单使用维度建模或者范式化建模都不能很好地支持企业级数据仓库的建设和发展。
根据国际最佳实践以及笔者的项目实施经验，比较好的做法是在数据模型层使用范式化模型，而后通过视图将范式化模型转换为维度模型给数据集市供数。
4 商业银行数据仓库整体架构初探4.1 源系统文件（Source file）源系统文件就是将银行各操作型系统（比如客户信息系统、存贷款系统、中间业务系统、信用卡系统、电子银行系统等）数据表中的数据以文件形式下载给数据仓库系统。
同时，视相关业务数据量大小决定每天是全量下载还是增量下载。
4.2 操作型数据存储（ODS）层及其视图操作型数据存储区域的数据表结构一般与上游源表结构一致，数据也基本一致，等于是将上游数据复制一份到数据仓库系统，因此也称为源系统镜像（Source Image）。
操作型数据存储（ODS）视图，是为了数据安全性和查询性能等因素考虑建立的视图，其结构与ODS本身结构一致。
操作型数据存储(ODS)的作用主要有以下几个：①如果上游源系统文件每日下载增量数据给数据仓库，则可以在ODS进行全量累加；②对于上游源系统文件中部分错误数据（比如字段长度被截位等），可以在ODS及时发现，进行修复和清理，提高到达模型层数据的数据质量；③对于那些时效性要求高，不需要历史数据，且查询不是很复杂的业务需求（比如电话银行的增值业务等），可以绕过数据仓库模型层，由ODS直接供数。
4.3 范式化模型层根据商业银行日常运作的业务特点，抽象出若干个主题（比如当事人、内部机构、资产、地址、产品、协议、事件、渠道、总账、营销等），将银行各个交易系统中的数据经过整合加载入各主题内部的各个数据表中。
可以说，模型层的设计对于整个数据仓库建设的成败起着至关重要的作用，模型设计人员需要结合银行自身业务特点在模型的稳定性、准确性、完整性和易用性等方面进行权衡，从而设计出高效、稳定、准确的模型。
4.4 逻辑视图逻辑视图的主要目的是方便数据仓库下游各数据集市取数，由于是面向查询，建议使用维度建模。
随着数据仓库的发展，其下游的数据集市将会越来越多。
因此，对于逻辑视图的设计除了要方便查询以外，更要注意对于统计指标的重用，以及对于视图数量的合理规划。
需要在稳定性和易用性之间找到平衡点。
同时，从模型层到逻辑视图的转换逻辑复杂程度和转换性能也是需要考虑的一个问题。
5 数据标准、数据质量管理和元数据管理要建设好商业银行的企业级数据仓库，除了要选择一种合适的建模方法，有一个合理的数据架构以外，更要关注存入数据仓库的数据情况。
要真正体现数据仓库的价值，还是要依靠存入仓库中的数据，可以说数据是数据仓库的生命。
而说到数据，就必须要提数据标准、数据质量管理和元数据管理这3块内容。
5.1 数据标准数据标准是用来描述数据的，用来定义数据的业务含义和技术特征，可以分为业务数据标准和技术数据标准。
业务数据标准从银行业务角度来描述数据，比如账号可以描述为“与银行签订了特定协议的客户所持有的，用于存放交易金额的账户号”。
技术数据表准则从数据库技术的角度来描述数据，比如账号可以描述为“25位长度的数字串，由9位地区号+9位网点号+2位识别号+5位顺序号组成”。
5.2 数据质量管理数据质量管理是数据仓库建设的重要内容，是数据仓库应用及价值发挥的基础。
具体来说，数据质量管理需要部署数据质量检查规则。
对于在数据仓库中发现的数据质量问题，需要通过数据质量管理平台进行反馈、跟踪和验证，从而保证数据质量问题的有效解决。
5.3 元数据管理元数据管理的工作主要是建立一个物理平台，将数据标准在物理上实现落地。
元数据管理平台的建设要注意其范围和详细程度。
从范围上来说，最好是有一个覆盖全行所有数据和数据结构的大元数据系统，这样可以保证各个系统之间的数据结构和各个元数据的统一规划和设计。
从详细程度上来说，需要建立机制，要求各个系统的所有数据结构及其相关信息都要登记到元数据管理平台中，这样才能使其发挥应用的价值和作用。
5.4 数据标准、数据质量管理和元数据管理的关系数据标准、数据质量管理和元数据管理三者是相辅相成，相互作用的关系。
数据标准的建立给数据质量管理提供了判断依据，凡是不符合数据标准的数据都是有问题的数据。
同时，数据质量发现和解决的过程中也可能会产生新的数据标准。
元数据管理平台的建设则是需要和数据标准建立同步实施的，数据标准必须与元数据保持统一和同步。
6 灵活查询所谓灵活查询，就是在数据仓库中开辟一块空间，让业务用户直接从仓库中获取数据，以满足业务人员即时的、灵活的查询。
产品再好，也需要营销了才能让客户知晓。
灵活查询在数据仓库的建设过程中就是扮演了这么一个营销的角色。
让业务人员开始使用数据仓库，从中体会到数据仓库的优势。
同时，在业务人员使用数据仓库的过程中，也可能发现一些数据质量问题，这样也有利于改善数据仓库本身的数据质量情况。
对于数据仓库项目的设计开发来说，推广灵活查询也具有其积极的意义。
对于一般的数据集市应用类项目开发周期一般需要几个月时间，而且业务人员在提需求的时候，没有数据验证环节。
导致当项目完成了，或是已经失去市场机遇，或是没有达到业务人员的预期，效果未必令人满意。
灵活查询的推广，可以让业务人员在提需求前先通过数据仓库来验证自己的想法，有时还需要建立一些预测模型进行模型训练。
对于一些营销类项目，还可以较快地提取结果。
待到需求都成熟了，再向数据仓库项目组提需求，进行常规部署，这样也提高了项目开发的效率和效果。
参考文献：[1] JIAWEIEI HAN,MICHELINE KAMBER.数据挖掘[M].范明,孟晓峰,译.北京:北京出版社，2001.[2] DA VID HAND,HEIKKI MANNILA,PADHRAIC SMYTH.数据挖掘原理[M].张银奎,廖丽,宋俊,等,译.北京:机械工业出版社，2003.。
