信用卡中心数据仓库项目设计
【摘 要】 近年来我国信用卡业务获得了飞速的发展,商业银行信用卡业务已经逐步成为了一个成熟的金融市场的一种重要的商业产品,现在我国商业银行信用卡业务正处于快速增长的阶段,随着商业银行信用卡业务的高速发展,银行积累了大量的信用卡交易数据,如何将这些数据变成有用的信息,使银行的领导做出决策性的判断,是信用卡分析集市需要解决的问题。
为了解决上述问题,本课题对国内某家中小型银行的信用卡数据分析系统进行设计,并以数据仓库和数据集市的理论为基础,结合该银行的技术现状和业务需求,建设了基于数据仓库的信用卡数据分析集市。支持多维分析和灵活的报表展现。
本课题根据从源系统到用户的数据流向,设计了临时层、基础数据层、数据汇总层三大数据层次。临时层用于存放缓冲数据基本与源数据保持一致。基础数据层用于企业数据仓库,存储细节和历史数据。数据汇总层用于数据集市,支持数据挖掘,该层并且直接面向多维分析和灵活报表。
每个层次根据不同需求而设计,并且数据在导入的过程中存在一定依赖关系,基础层依赖临时层,汇总层依赖基础层。本系统实现的信用卡数据分析集市使该银行首次拥有了支持信用卡数据挖掘的数据分析平台。
【关键词】 数据仓库,信用卡,数据分析,ETL
Design and Implementation of Credit Card Analysis Data Market Based on Data Warehouse
【Abstract】Bank credit card business in China in recent years has been developed rapidly, the bank credit card business has become a mature financial market is a kind of important commercial products, now China's bank credit card business is in rapid growth stage, along with the high speed development of bank credit card business, the bank transactions to accumulate a huge mass of data, how to turn data into useful information, so that the leadership of the bank to make decision-making judgment, is the credit card market analysis problems need to be solved.
In order to solve the above problems, the subject of a domestic small and medium-sized bank credit card data analysis of information system design, and based on the theory of the data warehouse and data mart, combined with the current situation and business needs of the bank's construction based on data warehouse credit card data marts. Support multidimensional analysis and flexible reports show This subject from the source data system according to the user's data flow, design the temporary data layer, data collection layer three large data level. The temporary data layer store cache data and keep almost the same with the original data basic data layer for the enterprise data warehouse, store details and historical data. Data collection layer applied in data mart, and support the data mining and support multidimensional analysis and flexible reports. Three levels are using normalize, de-normalize and structure characteristics of star-shaped model, step by step summary.
At each level internal rational design subject fields and entity, meet the needs of different data. The system of the realization of the credit card data analysis to
the bank first market has the support of the credit card data mining data analysis platform. The platform to integrate the credit card transaction system, collection system, customer service system, integral system four system’s source data, that a comprehensive analysis of the data become possible. A source system, data warehouse-a data mart three-layer new architecture is settled, Either solved the past credit card between management information system and enterprise data warehouse with data redundancy result in inconsistencies or realization of a flexible application of the data under the unified storage.
【Keywords】Data Warehouse,Credit Card, Data Analysis,ETL(Extraction Transformation Loading)
目 录
绪论 1
第一章 数据仓库简介 1
1.1 数据仓库出现的背景 1
1.2 数据仓库的特性 2
1.3 数据仓库的技术要求及需要解决的问题 2
1.4 数据仓库系统与OLTP系统的比较 3
1.5 本章小结 3
第二章 可行性分析与需求分析 4
2.1可行性分析 4
2.2需求分析 4
2.3 本章小结 11
第三章 项目概述 12
3.1 项目背景 12
3.2 项目总体描述 12
3.3 项目内容描述 12
3.4 本章小结 13
第四章 信用卡中心数据仓库项目总体设计 14
4.1 项目总体设计思路 14
4.2 项目整体流程规划 14
4.3 项目总体设计原则 15
4.4 本章小结 15
第五章 信用卡中心数据仓库项目详细设计 16
5.1 项目的概念模型设计 16
5.2 项目的逻辑模型设计 16
5.3 项目的物理模型设计 22
5.4 项目的物理数据库设计 24
5.5 ETL调度的设计 29
5.6 用Cognos工具展示报表的表样的设计5.7 本章小结 32
第六章 项目的实现及报表展示 33
6.1 系统环境需求 33
6.2 项目实现过程 33
30
6.3 项目实现过程中用到的ETL算法 34
6.4 项目报表展示 35
6.4 本章小结 38
后记 39
致谢 39
参考文献 40
附录一: 41
1)项目中用到的相关工具及技术介绍 41
2)配置运行环境时需要注意要点 42
附录二: 44
1)项目包里的“PRO_CREDITCARD”文件夹下的各种PL文件说明2 )PERL部分脚本代码示例 46
绪论
44
随着我国市场经济的繁荣和发展,国内信用卡业也获得了飞速发展。伴随着信用卡业务量的不断增长,国内信用卡行业的市场竞争也日趋激烈。因此各大银行需要建立专门的组织机构和专业队伍从事数据分析工作。数据分析的内容包括为业务管理提供统计报表,在市场营销、风险管理、客户关系管理等方面,利用报表分析工具对信用卡数据进行深度的挖掘,利用分析成果指导业务决策。
本课题基于数据仓库和数据集市的基本理论,以实际开发过程和开发成果为基础,主要从总体技术方案和数据库设计两个方面,描述了某银行信用卡数据分析集市的设计和实现。主要内容包括以下几方面:数据仓库平台 ETL技术 作业调度 数据模型建设 cognos报表展示。
数据仓库简介
1.1 数据仓库出现的背景
在数据库技术的支持下,一大批成熟的业务信息系统投入运行,为企业发展做出了巨大贡献。各类信息系统大多属于面向事务处理的OLTP系统,经过多年的运行,积累了大量的数据,而管理决策层对数据分析基础平台的需求却日益强烈。
数据仓库概念的提出者是美国著名信息工程专家William Inmon博士,他在90年代初提出了数据仓库概念的一个表述。他认为:“数据仓库是一个面向主题的(Subject Oriented)、集成的(Integrated)、相对稳定的(Non-Volatile)、反映历史变化(Time Variant)的数据集合,用于支持管理决策和信息的全局共享。”它的出现主要由两方面的因素:
需求的变化。
业务系统的建设逐渐完善。
分析类需求不断增加。
不断增加的信息孤岛导致数据集成问题不断增加。
技术发展非常迅速。
关系数据库技术日趋成熟。
报表和复杂查询处理起来非常困难。
各个系统之间数据不一致。
1.2 数据仓库的特性
数据仓库的特性有以下几个:
面向主题的(Subject Oriented):是指数据仓库内的信息是按主题进行组织的,而不是像业务支撑系统那样是按照业务功能进行组织的。
集成的(Integrated):是指数据仓库中的信息不是从各个业务系统中简单抽取出来的,而是经过一系列加工、整理和汇总的过程,因此数据仓库中的信息是关于整个企业的一致的全局信息。
非易失的(Non-Volatile):数据仓库的数据通常以批量方式加载和被访问,历史数据一
般不被更新。当产生信息的后继变化时,变化会被记录下来。这样,数据仓库中就保留了数据的历史状况。
随时间变化(Time Variant):是指数据仓库内的信息并不只是反映企业当前的状态,而是记录了从过去某一时点到当前各个阶段的信息。通过这些信息,可以对企业的发展历程和未来趋势做出定量分析和预测。而信息本身相对稳定,是指一旦某个数据进入数据仓库以后,一般很少进行修改,更多的是对信息进行查询操作。
依据上面的定义,有人可能会把数据仓库简单地理解为仅仅是一个大型的数据存储机制,是一个静态的概念。实际上,数据仓库更像一个过程,这个过程涉及数据的收集、整理和加工,生成决策所需要的信息,并且最终把这些信息提供给需要这些信息的使用者,供他们做出改善业务经营的正确决策。数据仓库的重点与要求就是能够准确、安全、可靠地从业务系统中取出数据,经过加工转换成有规律信息之后,为管理人员进行分析使用。因此数据仓库是一个动态的概念,应该称为数据仓库工程Data Warehousing。
1.3 数据仓库的技术要求及需要解决的问题
数据仓库中没有联机的数据更新,只有非常少的一些锁定需要;而且对于远程处理接口的需要也只是最基本的。但是数据仓库的技术需求比较多:
管理大量数据的能力和元数据管理。
能够管理多种介质,高效地装载数据。
能够轻松容易有效的使用索引和监视数据。
对于接口?用各种不同的技术接受和传送数据。
允许程序员/设计者对数据存放位置的控制并能从一批介质上将数据快速、完全地恢复。
现有的操作型数据库系统(OLTP)用来处理分析型应用存在很多的问题,都能在数据仓库中得到解决,例如:
数据可信性:两个部门提供的数据是不一样的,让管理者无所适从 。
数据动态集成问题:不同的需求,要求将操作型环境和分析型环境相分离。
历史数据问题:单项系统之间保留的历史数据时间范围不一致,无法满足DSS分析的需要。
报表的生产率问题:由于OLTP的单项系统导致数据的分散性和相同元素定义不一致导致不可能把数据转换成信息。
1.4 数据仓库系统与OLTP系统的比较
1.5 本章小结
本章主要讲述了数据仓库出现的背景及数据仓库的一些相关特性,数据仓库作为一个分析型的系统,用来为管理层的决策、管理行为提供服务。与传统的操作型的系统相比较,数据仓库系统拥有很多的特性和优势。
可行性分析与需求分析
2.1可行性分析
可行性研究是抽象和简化了的系统分析和设计的全工程,它的目标是用最小代价尽快确定问题是否能够解决,以避免盲目投资带来的巨大浪费。而现存系统存在的问题及薄弱环节有以下几点:
(1)目前信用卡系统并非完整的核心系统,由尚未集中的重要数据需要集中整理,前台交易系统数据繁多,操作量太大,系统的实时性较差。
(2)银行卡的发卡结构不合理,信用卡渗透率低。
(3)授权中心业务过于繁忙的问题。
而新建成的数据仓库系统能满足根据业务需求抽取仓库中的相关数据,制成卡量-时间分析统计表、卡量-地区分析统计表、客户量-时间分析统计表、客户量-地区分析统计表。从技术上有系统主要采用cognos报表开发工具结合oracle数据库来完成,从经济上有提高银行的业务率,提高查询效率,减少分析人员的工作时间。从操作可行上有系统采用的cognos报表展现工具,该报表工具采用excel格式是大家熟悉报表样式。从社会因素上有各大银行都在建立自己的数据仓库系统,这是未来发展的趋势,也是银行未来有利竞争的关键因素。综合以上的几个方面,系统具有很高的开发可行性。
2.2需求分析
需求分析是为了项目能顺利的开发,减少大量开发成本,减小开发风险。而且有利于进一
步定制软件开发的细节问题,便于用户与开发商协调工作。
2.2.1 以下表格是客户提出的报表业务需求,均需满足:
发卡量满足的要求:以时间、地区为纬度,得到各项指标。
指标 业务定义
总发卡量 所有卡片量,卡表里所有记录不作任何剔除
有效卡 同时满足以下条件:1、卡片状态为不1,2的;2、卡片在有效期内的;3、剔除开卡半年外未激活卡;4、对应账户的锁定码状态非(R,L,S,D,T类)
注意本指标为时点值。
当月新增发卡量 激活日期在当月的卡片(按2009-08月份为当月)
新客户发卡 该客户在统计周期(即2009-08月之前)之前从未持有过卡(即持有有效卡的),在统计周期内有符合上述定义的客户新增发卡量
老客户发卡 在统计周期之前已持有卡,在统计周期内(即2009-08月内)有符合上述定义的客户新增发卡量
一年以上回流客户发卡 客户曾持有卡,统计周期前12月前(即2008-08-01)已注销名下所有卡片,统计周期内有新增发卡
一年以内回流客户发卡 客户曾持有卡,统计周期前12月内(即2008-09-01后)已注销名下所有卡片,统计周期内有新增发卡
当月发卡当月注销 统计当月发卡当月注销
新增过期失效卡 在统计周期内失效的卡片
当年发卡当年注销 统计年初至统计日期新增发卡量,在同期间注销的卡量
客户量报表满足的要求:以时间、地区、性别三个纬度,满足各项指标。
指标 业务定义
总客户量 所有的唯一客户记录数
有效客户量 统计时点客户至少有一个有效卡的
当月新增客户量 该客户在统计周期之前从未持有过卡的客户,在统计周期之内拥有至少一张有效卡的
当月注销客户量 该客户名下最后一个卡在当期内注销的客户量
人均持卡 有效卡/有效客户量
人均余额 有效卡的总余额/有效客户量
累计注销客户 所有卡中,在统计时点已为注销的客户
过期客户 统计时点客户名下所有卡片已过有效期,必须为非注销客户
其它客户 总客户量-有效客户-累计注销客户-过期客户
(3)账户报表满足的要求:以时间、地区作为纬度,满足各项指标。
指标 业务定义
总账户数 所有的账户数量
有效账户数 所有账户中,销户日期不为3000-12-31的,且账户状态不为C
当月新增账户数 在统计周期内新增的有效账户
当月注销账户数 在统计周期内销户的账户
户均余额 有效账户余额汇总/有效账户数
总逾期余额 逾期状态不为0的有效账户余额汇总
2.2.2 数据描述
静态数据: 源表数据
2.2.3 码表中各字段的取值范围分析
源表中给出的三张表格客户信息汇总表(CCM_CUST_AGG_INFO),账户信息汇总表(CCM_ACCT_AGG_INFO),卡信息汇总表(CCM_CARD_AGG_INFO)中,在以后的详细设计中都会建立码表,所以必须在需求分析阶段确立各个代码表选取字段的取值范围,以便确立字段的取值类型及字段长度。
字段 取值范围
性别代码 M F证件类型代码 01 学历代码 01 02 03 04 05
国家代码 CHM
婚姻状况代码 01 02
住房类型代码 01 02 03 04 职务代码 00 01 02 03 04
职称代码 03
行业代码 00 25 95
单位性质代码 0
04 09
05 06
机构代码
营销渠道代码 01 02 09
授信额度
取现额度
可用额度
公私客户标识代码 1
员工标志 0 1
客户逾期状态 1 2 4 5 6
表2-2-3 码表中的相关字段的取值分析
ORG代码 101 102 013
发卡机构代码
发卡类别代码 001 002009
营销渠道代码 01 0205 09
账户余额
上期余额
活动状态代码 000 100
账户状态代码 D A I Z
逾期状态代码 0 4 5 6 9
封锁码状态代码 C Z U
信用额度
发卡机构代码
营销渠道代码 00 0S 02 0X 01 03 09
BIN编号 356839 406252622658543159
LOGO代码 303 003 016 013 012 103 卡面类型代码 00 01 02 03 04 77 06 卡片状态代码 0
203 226 233 202
封锁码状态代码 0 U S Y L
人民币本周期总授权限额
美元本周期总授权限额
卡等级标识 01 02
2.2.4 样本数据取值分析
表2-2-4 样本数据取值分析
选取字段 取值类型及字段长度 取值结构 是否有不符合的数据
卡号 VARCHAR2(50) 19位数值 无
客户号 VARCHAR2(50) 19位数值 无
账户号 VARCHAR2(50) 19位数值,前3位是0 无
卡的到期日 DATE(7) 日期大于2009-08-31 无
卡的开卡日期 DATE(7) 小于销卡日期且2009-08-31 无
卡的激活日期 DATE(7) 在开卡日期和销卡日期之间 无
卡的销卡日期 DATE(7) 大于开卡日期 无
账户状态代码 VARCHAR2(3) 取值范围是D、A、I、Z 无
账户余额 NUMBER(22) 数值可以大于、小于、等于0 无
逾期状态代码 VARCHAR(1) 取值范围是0-9 无
账户的开户日期 DATE(7) 开户日期小于销户日期 无
账户的销户日期 DATE(7) 销户日期大于开户日期 无
2.2.5 入仓字段选取分析
表2-2-5 入仓库的字段选取分析
需求项(分析指标) 选取字段 选取原因
总发卡量 卡号 统计所有卡号就可以满足需求
有效卡 卡号到期日 满足卡片在有效期内
开卡日期 剔除开卡半年内未激活的卡
激活日期销卡日期 筛选非注销卡条件
当月新增发卡量 卡号激活日期 根据激活日期可以选出满足条件的卡片
新客户发卡 卡号客户号开卡日期 选出客户从未持有过卡
激活日期 满足卡是新增发卡
老客户发卡 卡号客户号开卡日期 选出曾持有过卡的客户
激活日期 满足卡是新增发卡
一年以上回流客户发卡 卡号客户号销卡日期 选出在统计周期之前已注销名下所有卡
激活日期 统计周期内有新增发卡
一年以内回流客户发卡 卡号客户号销卡日期 选出在统计周期之前已注销名下所有卡
激活日期 统计周期内有新增发卡
当月发卡当月注销 卡号开卡日期 在当月开卡
销卡日期 在当月注销卡
新增过期失效卡 卡号到期日 统计周期内到期的
销卡日期 统计周期内销卡的
当年发卡当年注销 卡号开卡日期 统计周期开卡
销卡日期 统计周期销卡
总客户量 客户号
有效客户量 客户号卡号 统计周期客户持有至少一张有效卡
到期日开卡日期销卡日期激活日期
当月新增客户量 客户号卡号开卡日期 统计周期前是否持有卡啊
到期日 统计周期后至少拥有一张卡
销卡日期激活日期
当月注销客户量 客户号卡号销卡日期 销卡日期在当月则此客户为注销客户
人均持卡 客户号 有效卡/有效客户量
卡号到期日开卡日期销卡日期激活日期
人均余额 客户号账号 有效卡对应的账号
账户余额卡号 有效卡
到期日开卡日期销卡日期激活日期
累计注销客户 客户号卡号 客户名下所有卡片
销卡日期 卡片是否为注销卡
过期客户 客户号卡号销卡日期 此客户必须为非销卡客户
到期日 此客户到期日在统计时点前
其他客户 客户号 总客户量-有效客户-累计注销客户-过期客户
卡号到期日开卡日期销卡日期激活日期
总账户数 账号
有效账户数 账号销户日期 销户日期为3000-12-31
账户状态代码 账户状态不为C
当月新增账户数 账号开户日期 开户日期在统计周期内此账户为新增账户
当月注销账户数 账号销户日期 销户日期在统计周期内此账户为注销账户
户均余额 账号销户日期 有效账户
账户状态代码账户余额
总逾期余额 账号销户日期 有效账户
账户状态代码账户余额逾期状态代码 逾期状态代码不为0
2.2.6 报表需求满足度分析
表2-2-6 报表需求满足度分析
报表展示结果 分析过程 满足程度
总发卡量 根据凭证表按照日期,地区分组 能
有效发卡量 根据凭证有效历史表按照日期,地区分组 能
当月新增发卡量 根据凭证表选出激活日期为周期内史表,按照激活日期,地区分组 能
新客户发卡情况 根据凭证表选出激活日期在当月的用户,并且统计时间前开卡记录为空 能
老客户发卡情况 根据凭证表选出激活日期在当月的用户,并且统计时间前开卡记录不为空 能
一年以上回流客户发卡情况 根据凭证表选出激活日期在当月的用户,并且在当事人
状态历史中销户状态的最大结束日期小于统计日期?1年 能
一年以内回流客户发卡情况 根据凭证表选出激活日期在当月的用户,并且在当事人
状态历史中销户状态的最大结束日期在统计日期?1年与统计日期之间 能
当月发卡当月注销 根据凭证选择发卡日期,销卡日期在统计周期内的卡号 能
新增过期失效卡 根据凭证选择到期日在统计周期内的卡号 能
总客户量 根据当事人表按照日期,地区分组 能
有效客户量 在有效卡历史表中选出固定日期有效的卡号,通过关联当事人凭证关系历史选出关联的客户号,再进行去重操作。
能
当月新增客户量 通过凭证状态历史关联当事人选择出客户号但是此客户号不存在根据凭证表关联当事人凭证关系历史选择出在统计日期前开卡筛选的客户号里面。 能
当月注销客户量 当事人凭证关系历史选出在统计周期内状态全为解除状态的客户号。
能
人均持卡 有效卡的数量/有效客户量
能
人均余额 根据有效卡卡号关联协议凭证关系历史选出其账户所对应的余额进行求和运算/有效客户数量 能
过期客户 可以根据总客户量-注销客户量?客户名下所有卡片都为失效状态的卡片量
能
其他客户 总客户量-有效客户-累计注销客户-过期客户能
总账户 根据协议表选着账号字段,进行count操作就可 能
有效账户 协议状态历史选择统计周期状态是有效的账号,进行count的操作 能
当月新增账户数 协议表中开户日期在统计周期内 能
当月注销账户数 协议表中销户日期在统计周期内 能
户均余额 通过协议状态历史选择出有效的账号关联账户余额历史求出对应的余额在进行求和操作/有效账户数 能
总逾期余额 通过协议状态历史选择出状态为有效并且与逾期状态不为0的对应账号关联账户余额历史求出对应的余额在进行求和操作. 能
2.3 本章小结
本章分析了本系统的可行性,分别从技术可行性、操作可行性、经济可行性、社会可行性等各方面都进行了分析;另外对源系统给的报表进行了样本数据取值的分析和入仓字段选取的确立和分析。这些需求的分析将影响到以后在报表中用户查询到的数据指标的准确性。因此这部分内容还得在以后的开发过程中不断与业务人员沟通并完善。
项目概述
3.1 项目背景
XXX银行是我们公司的客户,是国内知名的股份制商业银行。在信用卡业务营销方面的水平处于国内商行的前列。
前两天,XXX银行信用卡中心市场部的徐经理打来电话,希望我们帮忙建设卡中心的数据仓库系统,以便了解信用卡的开卡情况和使用情况,为下一年的营销目标提供决策支持。
3.2 项目总体描述
本课题基于数据仓库和数据集市的基本理论,结合企业已有信息系统的现状和信息总体规划,以实际开发过程和开发成果为基础,主要从总体技术方案和数据库设计两个方面来描述描述XXX银行信用卡数据分析集市的设计和实现。
(1).设计和实现信用卡数据分析系统的总体架构。研究了成熟的基于数据仓库系统的数据分析平台架构特点,结合企业现有信息系统架构和实际业务需求,设计了基于数据仓库的生产环境,应用于报表类数据分析。
(2).设计和实现信用卡数据分析集市的数据架构。本系统把数据从源到应用的数据流向,分为临时层、基础数据层、数据汇总层、报表集市层四大层次,临时层用于存放缓冲数据基本与源数据保持一致。基础数据层用于企业数据仓库,存储细节和历史数据,整合了来自各个源系统的数据。数据汇总层用于支持数据挖掘和支持数据集市。数据集市层则直接面向多维分析和灵活报表。四个层次主要使用规范化结构特点,逐级汇总。各层次内部合理设计主题域和实体,形成不同的数据粒度,满足不同的数据需求。
3.3 项目内容描述
本课题所要建设的信用卡数据分析系统,它需要建设主要内容包括以下几个方面:
(1). 数据模型建设
通过本项目的实施,完成数据仓库的基础层模型建设。本项目至少完成了当事人、协议和事件三个主题。数据模型包括逻辑模型和物理模型。逻辑模型使用ERWIN工具,物理模型的工具也是使用ERWIN(可以使用excel工具)。
(2). 物理数据库设计
根据数据仓库的数据架构中不同的区域,设计了不同的scheme对数据进行存放,对scheme进行过相应的文档说明。
(3). ETL脚本开发
1)针对仓库临时层的样本数据,开发加载脚本将样本数据加载到Oracle数据库中。并使用了Oracle的加载工具进行加载。
2)针对仓库的基础层数据模型,开发转换脚本将数据转换到基础层模型中。针对不同的模型表,选择了相对应的ETL算法。脚本具体的技术形式使用Perl脚本嵌入SQL语句的形式。
3)针对报表展现部分,根据报表的加工逻辑开发ETL脚本对数据进行加工,供报表展现使用。
(4). ETL调度设计
因为本项目中没有采用现成的ETL调度工具,所以对本项目中ETL调度系统进行了设计。具体包括:
1)ETL任务定义,包括命名规范及每个具体任务的命名;
2)依赖关系定义:针对不同的ETL任务,确认其执行的前置依赖任务。
3)自动化批处理程序的开发
(5). 报表开发
按照业务需求,利用报表工具(Cognos)开发出相关的报表来展示。
3.4 本章小结
本章介绍了项目建设的背景,信用卡数据分析系统的总体技术方案和数据库的设计,并详细介绍了项目的内容和需要完成哪些工作,为下面的设计提供了素材。项目概述主要的作用是清晰的定义了接下来项目的进行需要哪些工作,为后面的项目的规划作准备。
信用卡中心数据仓库项目总体设计
4.1 项目总体设计思路
XXX银行信用卡数据仓库建设采用“总体规划,分步实施,急用先行”的总体建设思路。
在建设实施层面,采用分步实施的原则,同时要求提高项目的可控性,减轻项目风险。
在应用建设方面,对于信用卡业务部门管理报表需求,以及董事长、行长等公司决策层的管理要求,要优先实现;并且将来数据中心里数据量的积累,要求为管理层和运营层的各种数据需求提供数据分析和报表展现服务。
4.2 项目整体流程规划
(1)项目整体规划流程图如下:
(2)项目实施过程中需要完成的任务有:
需求分析
分析样本数据,根据每个业务需求指标确定口径。同时编写好需求规格说明书文档ODS层
将样本数据导入数据仓库的ODS层
建模
逻辑模型建设、物理模型建设
同时编写好详细设计文档
基础层
根据建好的物理模型,用ETL将数据从ODS层导入基础层
汇总层
根据业务分析需求将基础层数据用ETL导入汇总层
Cognos 展示
将数据结构导入framework继续进行加工分析,并打包和发布,最后在Report Studio中进行展示
4.3 项目总体设计原则
可扩充性原则:所选用的系统软硬件平台具有良好的可扩充能力,支持系统规模的扩大和业务范围的扩展,能够满足今后业务发展的需要,在不更改系统整体架构的前提下,方便的支持系统扩充。
开放性原则:系统应遵循开放标准,适应将来业务和技术发展的需求,系统建设具有较强的独立性和高度的可扩展性。除提供标准的开放式技术接口外,还能够完成与现有相关系统的完全对接。
先进性原则:系统技术架构与技术实现手段在金融行业内具有一定的领先性。
前瞻性原则:系统总体架构和软件体系结构具有前瞻性,充分考虑未来业务发展和管理
的变化,方便对新业务和新需求的扩展和支持。
高效性原则:系统具备对大规模数据量、大规模数量用户的处理能力,并在大数据量以及大规模数量用户的情况下仍能高效地运行。
稳定性原则:系统能满足业务高峰处理的需要,适应各种特殊情况给系统带来的压力。
安全性原则:系统建立在成熟稳定的硬件环境和应用软件基础上,通过完善的备份恢复策略、安全控制机制、运行管理监控和故障处理手段来保障系统的安全、稳定。
可维护性原则:系统提供对运行情况的完善的监测和控制功能,方便系统的维护,在系统处理异常时能够根据日志,快捷方便的定位出错误位置、原因,并可主动告警。
4.4 本章小结
本章主要讲述了项目的总体设计思路及整体的流程规划,从项目的确定到项目的完成里,总体设计虽然不是最重要的,但也是不可缺少的,在总体设计中,不必追求项目的具体实施细节,不必纠结于一些编码的生成,这些工作可以在后面的详细设计中来做,在整体的角度来评估、衡量项目的整体流程和一些需要遵循的原则。
信用卡中心数据仓库项目详细设计
5.1 项目的概念模型设计
概念模型是现实业务的直接的、直观的反映,概念模型不需要经过太多的逻辑处理就能实现,将现实中的业务逻辑和业务之间的联系用E-R图能直观的表示出来,本项目的概念模
型如下图:
图5-1-1 项目的概念模型
5.2 项目的逻辑模型设计
5.2.1逻辑模型的主题分析和确定
1.当事人(PARTY)是指银行作为一个金融机构所服务的任意对象和感兴趣进行分析的各种个人客户或团体客户等。该项目中有客户量分析,都是个人客户,没有团体客户,所以确定个人客户为当事人主题。
2.协议(AGREEMENT)是金融机构与客户之间针对某种特定产品或服务而签立的契约关系。该项目中当事人客户和产品卡之间是用过账户建立关系的,所以确定账户为协议主题。
3.事件(EVENT)是银行与客户或潜在客户之间的联系或交易活动,它记录了详细的行为和交易数据,包括存取款,查询,网上交易等。该项目中有客户的各种交易记录,所以确定交易事件为事件主题。
对每个主题进行的分割,是为了更加明确和清晰每个主题的结构,便于对业务需求的阐释更加合理和规范,使建立的逻辑模型更加符合实际的业务需求。
5.2.2 各个主题的划分和分析
1.当事人(PARTY)主题
1)根据项目需求对客户量的分析要求,我们需要获取的数据有总客户量,有效客户量,当月新增客户量,当月注销客户量,人均持卡,人均余额,累计注销客户,过期客户,其他客户。根据这些需求我们有以下分析:
2)当成为银行的一个客户时,银行会给每个客户分配客户号。银行通过分析客户号可以来统计该行客户的数量。所以需要建立当事人重要日期历史表。
3)银行每次吸纳一个客户,基本信息都是要录入并保存的。例如:姓名,性别,出生日期,证件代码等,所以需要建立当事人基本信息历史表
4)本次项目主要研究的是信用卡服务,所以一个客户的信用等级是至关重要的。根据客户的收入情况,工作单位等信息来评估一个人的信用等级,然而一个人的信用等级是可以变化的,不是一尘不变的,所以我们需要记录每个客户的限额历史,需要建立当事人限额历史表。
5)为了要判断每个当事人的状态,需要建立当事人状态历史表。
当事人(PARTY)主题设计如下图:图5-2-2-1 当事人主题的逻辑模型
2.协议(AGREEMENT)主题
1)根据项目需求对账户的分析要求,我们需要获取的数据有总账户数,有效账户数,当月新增账户数,当月注销账户数,户均余额,总逾期额。根据这些需求我们有以下分析:
2)与客户号一样,每个账户号都有自己的基本信息历史表,用来记录账户的基本信息。所以需要建立协议基本历史表。
3)客户需要开立账户才能使用银行里服务,每个客户可以开多个账户,也可以注销账户,而银行需要记录这些历史,所以还需要建立协议重要日期历史表。
4)每个账户都有一个状态,根据它的状态来分辨它是否是有效账户,所以我们需要建立一张协议状态历史表[9]。
5)每个客户有多个账户号,而每个账户号的限额是在变化的,所以需要建立协议限额历史表。
6)信用卡不是产品,是一种凭证,它不能单独作为一个主题,必须放在协议主题下,客户通过持有卡然后才有信用卡,所以建立一个协议凭证之间的关系历史表。
7)为了使当事人和协议之间建立关系,我们需要建立当事人协议关系历史表。
根据凭证的特点,建立凭证的基本信息历史表,如下图:
图5-2-2-2 凭证的逻辑模型
图5-2-2-3 协议主题的逻辑模型
3.事件(EVENT)主题
每个客户每天都会进行许多操作,每个操作都会产生数据,比如一次查询,一次转账,一次交易,银行需要记录这些操作,所以需要建立一张事件信息历史表。该表中的字段有交易事件编号,客户号,卡号,账号,交易日期,交易代码,原交易币种,原交易金额[10]。
事件(EVENT)主题设计如下图:
图5-2-2-4 事件主题的逻辑模型
5.2.3主题与主题之间的关系分析
每个客户有一个客户号,一个客户号下面有多个账户,一个账户号下面又有多张卡。一个客户号可以对应多个账户号,一个账户号可以对应多个卡号。客户只能通过账户管理卡号,所以需要建立当事人和协议之间的关系历史,还有协议和凭证之间的关系历史。
基础层:(黄色为当事人主题,绿色为协议主题,蓝色为事件主题),如下图
图5-2-3 所有主题及主题关系的逻辑模型
5.3 项目的物理模型设计
5.3.1当事人(PARTY)主题
根据逻辑模型关系分析得到物理模型如下图:
图5-3-1 当事人主题物理模型
5.3.2 协议(AGREEMENT)主题
根据逻辑模型关系分析得到物理模型如下图:
图5-3-2 协议主题物理模型
5.3.3事件(EVENT)主题
根据逻辑模型关系分析得到物理模型图如下图:
图5-3-3 事件主题物理模型
5.3.4各主题之间的物理模型关系
根据逻辑模型关系分析得到物理模型图。
基础层:(黄色为当事人主题,绿色为协议主题,蓝色为事件主题),如下图:
图5-3-4 所主题及主题关系物理模型
5.4 项目的物理数据库设计
根据数据仓库的数据架构中不同的区域,设计了四个scheme进行对数据进行存放,分别为:源系统数据,临时区,基础层,汇总层。并在数据库中创建了四个用户:源数据库,用户名edw_ods;基础层数据库,用户名edw_basic;汇总层数据库,用户名edw_summary。
1. edw_summary分别存放每一scheme的表, edw_temp用户管理临时区中的表, 临时区中表基于ODS层进行数据抽取,数据清洗等。
2. edw_ods用户是存放从从EXCEL中抽取的数据,这一步首先经过数据清理,然会经过
ETL抽取过程把源数据存放在已经建立好的ODS层的表中。
3. edw_basic用户是数据仓库基础层的用户,这一层首先要根据业务需求建立物理模型,然后转化成物理模型,然后根据物理模型建立对应的基础层的表,然后用ETL过程把ODS层中的数据抽取到基础层所建立的表中。
4. edw_summary用户是数据仓库汇总层,这一层是根据业务的需求把我们需要的一些数据先计算出来,在这一层建立一些表,用于存放这些数据,然后用ETL算法从基础层抽取数据,进行轻度汇总。
物理数据库为数据仓库储存历史信息,表建在basic用户下。严格按照物理模型建表,表中各字段的字段名、数据类型及长度、中文说明均来自所给文档数据结构表。
以下是各个主题建表情况:
表5-4-1 数据仓库的基础层中建表说明
个人当事人-- PT_TABLE
字段中文名 英文名 字段类型 约束条件
客户号 CUST_NO VARCHAR250 主键
证件类型 CERT_TYPE VARCHAR210 无
证件号 CERT_NO VARCHAR250 唯一值
当事人姓名历史-- PT_NAME_TABLE
字段中文名 英文名 字段类型 约束条件
客户号 CUST_NO VARCHAR250 联合主键
客户号为外键,参照表为个人当事人,参照列为客户号
开始日期 START_DATE DATE
姓名 CUST_NAME VARCHAR2100 无
结束日期 END_DATE DATE 无
当事人人口统计学信息历史-- PT_POPU_STA_INFO_TABLE
字段中文名 英文名 字段类型 约束条件
客户号 CUST_NO VARCHAR250 联合主键
客户号为外键,参照表为个人当事人,参照列为客户号
开始日期 START_DATE DATE
详细信息 DETAIL_INFOVARCHAR2200 无
结束日期 END_DATE DATE 无
当事人状态历史,PT_STA_HIS_TABLE
字段中文名 英文名 字段类型 约束条件
客户号 CUST_NO VARCHAR250 联合主键
客户号为外键,参照表为个人当事人,参照列为客户号
当事人状态代码为外键,参照表为当事人状态码表,参照列为代码值
开始日期 START_DATE DATE
当事人状态代码 PT_STA_CODE VARCHAR250
结束日期 END_DATE DATE 无
当事人重要日期历史,PT_IMP_DT_HIS_TABLE
字段中文名 英文名 字段类型 约束条件
客户号 CUST_NO VARCHAR250 联合主键
客户号为外键,参照表为个人当事人,参照列为客户号
当事人重要日期代码为外键,参照表为当事人重要日期码表,参照列为代码值
开始日期 START_DATE DATE
当事人重要日期代码 PT_IMP_DT_CODE VARCHAR250
结束日期 END_DATE DATE 无
当事人凭证关系历史,PT_CERT_REL_HIS_TABLE
字段中文名 英文名 字段类型 约束条件
客户号 CUST_NO VARCHAR250 联合主键
客户号为外键,参照表为个人当事人,参照列为客户号
当事人凭证关系代码为外键,参照表为当事人凭证关系码表,参照列为代码值
开始日期 START_DATE DATE
当事人凭证关系代码 PT_CERT_REL_CODE VARCHAR250
结束日期 END_DATE DATE 无
协议-- AG_TABLE
字段中文名 英文名 字段类型 约束说明
账号 ACCT_NO VARCHAR250 联合主键
ORG代码 ORG_CODE VARCHAR23
客户号 CUST_NO VARCHAR250 外键,参照表为个人当事人,参照列为客户号
开户日期 OPEN_ACCT_DATE DATE 唯一
销户日期 CANCEL_ACCT_DATE DATE 无
发卡机构代码 BRANCE_CODE VARCHAR210 无
账户余额历史-- AG_BAL_HIS_TABLE
字段中文名 英文名 字段类型 约束说明
账号 ACCT_NO VARCHAR250 联合主键
账号为外键,参照表为协议,参照列为账号
开始日期 START_DATE DATE
ORG代码 ORG_CODE VARCHAR23
账户余额 CURR_BALANCE NUMBER22 无
结束日期 END_DATE DATE 无
协议状态历史-- AG_STA_HIS_TABLE
字段中文名 英文名 字段类型 约束条件
账号 ACCT_NO VARCHAR250 联合主键
账号为外键,参照表为协议,参照列为账号
无
协议状态类型代码为外键,参照表为协议状态类型码表,参照列为代码值
ORG代码 ORG_CODE VARCHAR23
因篇幅问题不能全部显示，请点此查看更多更全内容