数据仓库多分析系统整体设计方案.doc

目 录 一、概述 2 二、四科室需求 3 1、风险科需求 3 2、市场科需求 13 3、业务管理科需求 14 4、计划资金科需求 15 三、需求分析 23 1、维表 23 2、事实表 23 3、事务——业务处理过程及业务术语 23 4、主键 24 5、外键 24 四、系统结构图及业务数据流图 25 1、系统结构图 25 2、数据流图 26 五、源数据表结构 27 1、BCS系统 27 2、Cardpool系统 34 3、NAS系统 36 4、BCS系统报表 37 六、生成表结构 39 七、码表结构 43 八、结果表结构 50 九、数据表创建方法 51 1、BCS系统 51 2、Cardpool系统 57 3、NAS系统 58 4、生成表 58 5、码表 62 十、数据处理过程 68 1、目录结构 68 2、流程说明 68 十一、问题及处理方法 80 一、概述 Bill Inmon（数据仓库之父）在Building the Data Warehouse （John Wiley Sons Inc., 1996）书中把数据仓库描述为一个“面向主题的、完整的、非易失的、不同时间的、用于支持决策管理的数据集合”。 数据仓库是只用于制作报表的数据库。 对我们而言，数据仓库是某个“宽广”的数据仓储。它包括许多的主题领域。而一个数据集市，恰恰相反，它把眼睛盯在商业活动的某个非常有限的部分上。它往往涉及某个单独主题或单个类型的分析。 在日常工作中，IT人员经常听到这样的抱怨：“我要求的报表怎么还没出来？”或者是“我要对XX报表做些修改，怎么还没结果？”等等。 在IT飞速发展的最近几年里，银行信用卡部先后针对业务上了一些计算机系统。这些系统的特点是：信息量规模小、数据经常实时更新、适用于业务人员快速录入数据、使用模式相对来说是可以预测的、模式很复杂、业务流程难以更改、数据在线保存的时间较短及各系统之间缺乏必要的联系等。这样的系统被称之为OLTP系统。OLTP系统的这些特点也就决定了有如此抱怨。 如何解决这些问题呢？我们首先想到的是：把数据集中、完整地存储在中心数据库中。所有的业务处理在中心数据库上进行。所有的报表工作脱离数据库。这听起来难道不是有点像一个数据仓库吗？我们为什么不在OLTP的业务系统数据库的基础上生成报表呢？答案很简单：因为报表经常需要大量的、长时间的数据做依据，然后经过大量的运算，才能得出你想要的结论。这对业务系统的正常运转影响很大，以至于业务系统无法正常运转。 当然，不是什么时候都需要一个数据仓库的。正如数据仓库的定义：是用于支持决策管理的数据集合。 中国银行北京分行从1986年6月1日发行第一张人民币长城卡到现在拥有将近20万的持卡人。从过去手工处理业务到现在拥有几个OLTP业务系统。信用卡业务有了飞速的发展。但也应看到信用卡市场的激烈竞争。如何给决策者及时提供决策支持信息，是在激烈的市场竞争中立于不败之地的关键。 二、四科室需求 1、风险科需求 表1． 北京市分行/（XX支行）信用卡透支利息统计表 年 月 日 金卡 普通卡 比例 合计 自年初累计 户数 金额 户数 金额 户数 金额 户数 金额 户数 金额 应收透支利息 本月实收透支利息 透支30天内应收息 透支30天内本月实收息 透支30-60天内应收息 透支30-60天内本月实收息 透支60-90天内应收息 透支60-90天内本月实收息 透支90-180天内应收息 透支90-180天内本月实收息 透支180-360天内应收息 透支180-360天内本月实收息 透支360-720天内应收息 透支360-720天内本月实收息 透支720天以上应收息 透支720天以上本月实收息 注：第一列的时间段缺省设置是表中值，但应允许人为修改各时间段的取值及范围。 表2． 北京市分行/（ XX支行）信用卡透支还款分析表 年 月 日 金卡 普通卡 比例 合计 自年初累计 户数 金额 户数 金额 户数 金额 户数 金额 户数 金额 全辖透支数额 本月实收透支额 30天内透支额 本月30天内透支户还款数 30-60天内透支额 本月30-60天内透支户还款数 60