如何处理银行机构撤并的问题

作者:姜玲
2007/4/2 9:10:45
本文关键字: ttnn 2006年03期

Zhou.sinuo
20060309

银行系统内标志帐户的系统帐号前9位为该帐号的归属机构,因此当机构发生撤并时系统帐号也会随之发生变化;业务系统内会将老的帐号_update成新的帐号,而dw内的帐号还是老的系统帐号,这样当计算该账户的日均余额或是其他累计值时该账户的数据就会发生错误,现在只能采用发生撤并时也_update dw内这些发生撤并帐号的办法,总觉得这样处理涉及到的数据范围太广,一切与账户有关的表都需_update,不知各位有什么好办法

innovate

我对金融系统不太熟,不过如果生产系统比较成熟的话,应该有一个字段可以和系统账号一一对应的,它是不变的。这样无论是生产系统还是DW都可以通过这样的关联_update。

还有,如果账户本身就是一个维,那么可以通过相应的维表去控制,只修改维表,并和相应的各个事实表建立一个外健关系就ok。

Zhou.sinuo

最让我头痛就是在业务系统中没有这么一个不变字段和系统帐号一一对应,在data mart内机构是可以通过维表控制,因为数据粒度已经不是在账户级了,可银行有些需求如账户的贡献度之类是针对dw账户级粒度数据的计算得来的,系统帐号一发生改变造成而又没有和dw内历史的账户信息建立对应的关系的话会造成账户无法继承历史的一些相关属性,如年累计存款值等,这样就提供给了客户错误信息账户本身不是作为一个维来分析的

Innovate

你的意思是不是data mart内已经不是账户为最低粒度了?如果这样的话,建议在data mart层增加一个和DW的过渡层,俗称staging area,这样就可以继承DW的东西,而不至于断层了。

Dumpedjoe

对于客户帐号这样的渐变维,在dw中就不应该沿用业务系统的客户帐号,应该在dw初始化的过程中引入代理键,也就是建立客户帐号和dw中帐户标识的对照表(帐户标识初始化也有讲究,再说),团体和合约的主题整合都不做还能叫银行的dw嘛。

看弟兄也是搞银行的,初练都会碰到这个问题,如果你是甲方找集成商,现在这么不专业的好像不多,别急着付款,呵呵,开个玩笑。

Zhou.sinuo

设置代理键不是不是没有想过,只是其中涉及到银行其他外围系统和核心系统的对应帐号关系,这样做就复杂很多了;客户帐号和系统帐号是两回事,本身客户帐号理论上是可以用来唯一标志出一账户且不会变化的,只是客户账号有二义性,可能是存折号也可能是卡号,所以在系统中就不好用转换过来的客户帐号了.项目分了两期,各主题分析基本都在二期做,现在才做完一期,其中涉及了什么公检法查询之类的即席查询需求因此关注的数据粒度很多都还是帐户级.

偶确实做银行业务才不久,呵呵,因此对银行业务确实不太懂,不过做BI有几年了,水平不行,惭愧惭愧.

Dumpedjoe
20060310

建立帐户标识当然不能使用客户使用的客户帐号,在业务系统里面都有唯一标识客户使用帐号的系统帐号(有点拗口),与折卡无关,我想是涉及不到外围系统和核心系统的帐号对应,那是前置或者核心系统记帐前处理的事情,外围系统使用的帐号最终到业务系统记账都应该转换为核心系统的系统帐号。如果确实存在未上收的外围系统,在dw初始化时整合它与核心系统帐号是必须的,这也是合约整合的基础,一次性解决问题比现在困扰于更新所有变更帐户相关表不是好多了么,何况后者并不是解决问题的办法。

Innovate

我想楼主最后查询的时候,使用代理健也不能正确查出某账号的数据,因为代理健和账号的对应关系已经变了。

不知道楼主可不可以这样试下,把账号当作维来处理,通过缓慢变化维的处理方式,更新数据。如果数据量比较大,可以把账号按照地区等属性拆分小了再处理。

责编:姜玲
vsharing 微信扫一扫实时了解行业动态
portalart 微信扫一扫分享本文给好友
著作权声明:kaiyun体育官方人口 文章著作权分属kaiyun体育官方人口 、网友和合作伙伴,部分非原创文章作者信息可能有所缺失,如需补充或修改请与我们联系,工作人员会在1个工作日内配合处理。
畅享
首页
返回
顶部
×
畅享IT
    信息化规划
    IT总包
    供应商选型
    IT监理
    开发维护外包
    评估维权
客服电话
400-698-9918
Baidu
map