大数据仓库分析报告系统整体方案设计.docx

大数据库房剖析报告系统整体方案设计 大数据库房剖析报告系统整体方案设计 大数据库房剖析报告系统整体方案设计 适用标准文档 目 录 一、概括 2 二、四科室需求 . 3 1、风险科需求 3 2、市场科需求 14 3、业务管理科需求 15 4、方案资本科需求 16 三、需求剖析 . 25 1、维表 25 2、事实表 25 3、事务——业务办理过程及业务术语 25 4、主键 26 5、外键 26 四、系统构造图及业务数据流图 27 1、系统构造图 27 2、数据流图 28 五、源数据表构造 . 29 1、 BCS系统 29 2、 CARDPOOL系统 36 3、 NAS系统 38 4、 BCS系统报表 39 六、生成表构造 . 41 七、码表构造 . 45 八、结果表构造 . 53 九、数据表创办方法 54 1、 BCS系统 54 2、 CARDPOOL系统 60 3、 NAS系统 62 4、生成表 62 5、码表 66 十、数据办理过程 . 73 1、目录构造 73 2、流程说明 73 十一、问题及办理方法 86 文案大全 适用标准文档 一、概括 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-60 天内透支额 本月 30-60 天内透支户还款数 60-90 天内透支额 本月 60-90 天内透支户还款数 90-180 天内透支额 本月 90-180 天内透支户还款数 180-360 天内透支额 本月 180-360 天内透支户还款数