2014数据仓库分析系统整体设计方案.docVIP

目 录 一、概述 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-90天内透支额本月60-90天内透支户还款数90-180天内透支额本月90-180天内透支户还款数180-360天内透支额本月180-360天内透支户还款数360-720天内透支额本月360-720天内透支户还款数720天以上透支额本月720天以上透支户还款数注：上月付100，本月付80，虽还欠款，但算还款户。还款数额包括结息数额，由结息带来的实际还款也算还款户。 第一列的时间段应允许人为调整，时间的累计是以某一天开始，倒推统计数据。 表3． XXXX年第X季度关于信用卡透支情况的报告 （每季一份） 总行： 根