关注点：如何让业务数据真正服务于分析？
在第三章对于信用卡业务相关的方方面面的数据及其获取来源进行了详细的介绍，但是即便清楚地了解到数据及其来源，分析人员面对这些数据仍然会比较困惑，使用起来仍然存在重重障碍。上述的各种数据均分布在与各个业务系统相关的数据库中，这些数据库建设之初主要是为了日常业务处理所用。当人们希望从这些数据库中直接获取数据，运用于分析或报表生成等决策支持工作时，却发现它不能令人满意，主要原因在于：
·操作处理的性能特点不同
在业务处理环境中，用户对与数据存取相关的操作的频率非常高，并且处理的时间较短，而在分析或报表生成处理的环境中，经常需要耗费几个小时来完成一次分析工作或报表生成的应用程序，其所消耗的系统资源非常大。
·对数据集成度的要求不同
分析或报表生成工作对数据集成度的要求很高，全面而正确的数据是实现有效地分析或准确的报表的首要前提。数据集成度越高，得到的结果越可靠，而业务处理对数据的要求更加侧重自动化和高效性，一般只需要与本部门业务操作相关的数据便可以实现，对于跨部门的数据集成要求不高，这也是目前很多企业内部数据非常分散的主要原因。
·对历史数据的需求度不同
在很多用于事务处理的数据库中，往往仅对短期内的数据进行存放，便足以支持正常业务的运作；而在分析或报表生成过程中，历史数据往往会起到非常重要的作用，没有对历史数据的准确分析就很难把握未来的发展趋势。因此，分析或生成报表对历史数据有着特殊的要求。
·对数据的综合程度要求不同
在各种业务数据库中存放了大量的细节数据，而在分析或报表生成过程中，往往不需要如此细致的数据。因此，需要对这些数据进行一定的综合，从而更加方便分析人员的使用。
鉴于上述关于业务处理与分析或报表生成之间的巨大差异，数据仓库的概念应运而生，并且逐步得到广泛应用。数据仓库概念最早由其创始人比尔·恩门【Bill Inmon】2002年在《建立数据仓库》一书中提出：“数据仓库是面向主题的、集成的、稳定的、随时间变化的数据集合，用以支持经营管理中的决策制定过程。”
实施目标：加工业务数据，建立数据仓库
√ 将各种业务系统中的数据统一导入数据仓库中
√ 对数据仓库中的数据存储进行相应设计与管理
数据仓库的建立过程，主要可以划分为两个阶段，即数据导入、数据存储，如图4.1所示。
数据导入
为了保证业务操作与分析或报表产生等决策支持工作各自的执行效率及要求，一般需要将服务于分析或报表生成的数据仓库独立于日常的业务操作系统之外。因此，这就涉及如何将来自各种不同的业务数据源中的数据以一定的方式导
入到数据仓库中，如果拥有外部数据源，也需要将外部数据源导入到数据仓库中。这种数据导入的方法，主要包括数据抽取、数据转换和数据加载三个过程，即通常所说的ETL【Extract/Transform/Load】方法。数据抽取过程主要是，从不同的数据源获得相关的业务数据，由于数据仓库不需要作出实时反应，因此只需要定期进行数据抽取便可以。同时，通过定期提取，还可以满足分析或报表生成工作对数据积累的需求。尽管可以从不同数据库中提取相关的业务数据，但是这些原始的数据还远远不能满足后续数据仓库应用的需要。因此，还要在数据抽取之后，在这些数据被导入到数据仓库之前，进行一定的数据转换。数据转换的目的主要有两方面：一方面是为了解决业务数据综合程度不高的问题，从而根据后续应用要求进行相应的数据粒度转换；另一方面，为了能够在后续顺利实现不同业务数据库之间的数据集成，需要解决不同数据库之间的某些数据不一致等问题。例如，一个数据库中对性别的记录为“男”、“女”，而另一个数据库则记录为“0”、“1”，因此在将这些数据导入到数据仓库之前需要通过相应的转换规则，统一格式。数据导入的最后一个步骤，是将抽取并进行过相应转换的数据加载到数据仓库中，从而完成数据仓库建设的初级阶段，为后续数据管理及应用提供基本的素材。
数据存储
在数据被导入到数据仓库之后，需要设计一定的存储方式，以方便未来数据的应用。数据存储的方式有很多种，其中最常见的是用关系型模型存放数据仓库数据，并且通过调用关系数据库引擎将数据以多维格式展现给用户。这里我们以最常见的星型模型【见图4.2】来讨论如何利用关系型模型进行数据存储。
图4.2是一个关于信用卡业务以促销活动为分析主题的星型结构图。在星型结构图的中心是一个事实表，事实表中包含了描述业务中特定事件的相关度量值【即事实，如交易量、客户反应情况等】以及与各个维度表相连的键，从而定义了多维空间的各个维度。例如，图4.2中的事实表包含了四个维度，即持卡人、促销活动方式、促销活动时间、促销活动渠道。维度键是系统生成的值，它们组合在一起就定义了事实表中的一条记录。维度键确定了由星型结构所代表的多维结构中的坐标系。
事实表中的每一个维度都可能拥有一个或者多个与之相关联的维度表。这些维度表就像星星的每个角，与位于中心的事实表构成了星型结构。维度表中包含了与某一维度相关的数据，维度表与事实表之间是一对多的关系【图4.2中连接维度表与事实表的连线来表征一对多的关系，连线与维度表连接的一端为单条直线，而与事实表连接一端为多条直线】，因此维度表远小于事实表。构成一个维度表的变量的选择，通常很大程度上取决于该星型结构所要回答的分析问题。以图4.2中的四个维度表为例，与持卡人维度相连的持卡人维度表中包含了储存在数据库中的每个持卡人姓名、性别、年龄等信息，与活动方式维度相连的活动方式维度表中包含了在促销活动中可能或已经使用过的各种活动方式，与活动时间维度相连的活动时间维度表可以帮助了解与所有促销活动相关的年、季、月、日信息，与宣传渠道维度相连的宣传渠道维度表则列出了目前可能采用的所有宣传渠道。
除了用于与各个维度表相连的维度键外，事实表中还包含了与每条记录相关的一个或多个事实信息。例如，图4.2事实表中所包含的客户反应情况记录，由此我们可以了解到，事实表中的第一条记录描述了姓名为孙宁、女性、26岁的客户，在2007年2月21日接收到了由电话渠道宣传的商户优惠促销活动信息，并且这位客户对该促销活动作出了反应。
关系型数据仓库模型除了上述的星型结构外，还有由星型结构变化而来的雪花型和星群型结构。雪花型结构即在星型结构维度表的基础上再进行细分，以原有的维度表为中心建立更细的维度表，这种结构的最大优势就在于它大大提高了存储效率。因为其中的冗余信息更少了，并且由于相关的各个表格更加小了，连接操作变得更为方便；但另一方面，表格数量的增加也会使同样的数据查询比在星型结构中更加复杂。星群型结构是指那些在关系网中心具有两个或两个以上事实表的关系型数据结构，如果一个数据仓库需要服务于多个主题，则这种结构的优势将会明显显现出来。
通常来说，在一个数据仓库建成之后，可以根据不同的分析主题从中整理和生成相应的数据集市，从而供制定分析和战略决策使用。但是，由于目前很多企业或银行在建立数据仓库的过程中，常常缺乏对数据仓库在未来的分析和决策支持中应用的充分认识、长远考虑，因此导致存放在数据仓库中的数据存在很多数据质量问题，尚未得到完全解决，甚至仅是对影响存储的部分问题进行了解决，仍然存在很多数据错误和缺失等情况，影响后续数据仓库的应用效果。另外，认识上的不充分还会使很多数据不能直接为分析所服务，缺乏一定的数据加工和融合的过程。因此，为了提高数据仓库的使用效果，在现有的数据仓库建设的基础上，还需要进行全面、充分的数据精练、数据融合的工作。
本章小结
本章主要关注如何将独立服务于不同业务部门的操作型数据转化为可供不同主题分析或报表生成的分析型数据。由于操作与分析过程对于数据要求的差异性，目前很多银行或企业纷纷建立起独立于各个业务系统的数据仓库，并且对数据仓库的具体建设过程，即数据导入和储存进行了详细介绍。同时，对目前数据仓库建设过程中所存在的影响其使用效果的问题进行了揭示，从而期待通过后续数据工程的相关步骤提高数据仓库的可用性，使其真正实现服务于分析和决策支持的目的。
