[已结帖][分享知识 原创连载]信用卡模型表分析，做X行信用卡学到的业务皮毛和自己...

493527009@qq.co

前言

       首先要说的是写这篇东西可以算是赶鸭子上架吧。所以也就只能说下我在做X行信用卡时学到的一些业务皮毛和自己对核心系统的模型表的一点自己的见解。大家一起来进行沟通讨论下，我就先来抛砖引玉了。
       这里对模型表的模型分析都是以业务规则、业务知识为基础去说的，所以里面很多时候说道业务方面的知识。
       因为能力有限，所以不可避免会有一些错误和缺漏，还望各位海涵。
       感谢ERP100提供的平台，也感谢纵横斑竹发起的这个活动。
      
@iamagoodmaster

纵横四海

个人简介：数据库开发人员   打过电信、银行的酱油，目前在电商打酱油
连载主题：信用卡部分底层模型表模型构建分析
计划发布日期：2013.7.13或2013.7.14
计划发布的版块：服务器与操作系统≡› 数据库
更新周期：不定时（一周多更或者多周一更）
本连载的主题：信用卡部分底层模型表模型分析（结合业务规则）
其他要说的话：酱油人员的酱油总结。

纵横四海点评：对于绝大部分人对信用卡系统是不太了解的，不过信用卡系统因其交易量大，我想其对性能的考虑是很必须的；希望楼主的连载能够让我们能够对信用卡系统的底层有一个了解；其实很多系统都是相通的，可以通过学习信用卡系统来举一反三，灵活应用到我们的实际工作中；期待楼主的连载；我也会召集金融行业的朋友来参与讨论；

493527009@qq.co

连载1.1  整体梳理
      一般我们个人用的信用卡基本都是两种：贷记卡、准贷记卡。而针对公司、企业这种会有一种叫做公司卡的。
      国内大多发行的都是贷记卡，也有准贷记卡。贷记卡和准贷记卡最大的区别在于是否会有存款利息。
      对于用户来说，信用卡最直观接触到的信息就是：卡号、持卡人的信息、额度值、账单日、交易流水、还款金额等。这些词都比较直接，我想用过信用卡的都不会陌生，也就不多说了。
      对于内部系统来说，就是三种关系。卡——账户——客户。所有的模型表都跟这三个脱离不了关系。
      对于信用卡来说，这三个之间的关系是N:N:N的关系。这里的N:N:N看起来似乎是很不合理，其实这三个之间的关系粒度很粗，当把数据粒度进行细化后，并且结合对应的业务之后，那么一切都明朗了。
      一切的数据和模型搭建都是以业务为基础模式，所以就先从业务方面分析下N:N:N的原因。
      卡：分为主卡和附属卡，一个主卡可以有一张或者多张附属卡。一张单币主卡对应一个本币账户，一张双币主卡对应两个账户，一个本币账户、一个外币账户。一般来说国内发卡的本币是人民币，外币是美元。国外发卡的外币都是人民币。附属卡正常情况下不会单独存在，所以附属卡一般没有单独的账户号。
      账户：一个账户下可以有多张卡（多张主卡和附属卡，但同一产品的主卡只能有一张。比如我是招行的young卡，我只能有一张young卡）；一个账户下可以有多个人（例如主副卡分别属于不同的人，但是他们共用同一个账户）。
      客户：一个客户可以持多张不同卡产品的主卡，也可以持有多张不同卡产品的附属卡。持有多张主卡的话他就会有多个账户。
      可能看起来感觉很混乱，其实主要就是主卡才会有账户（纯附属卡不在此例，基本也没遇到过实例，所以不对其做深究），主副卡公用一个账户，一个人可以有多张主卡。

      下一次将通过账户去分析表的模型。
      

493527009@qq.co

连载2.1   账户表相关
      先从账户相关的东西进行一个整体概括，账户相关的：账户余额、账户状态（系统中分为自动状态和手动状态）、账单日、账单金额、预期金额、信用额度。主要跟账户相关的大致也就这些东西了。
    一个比较有意思的设计就是系统有一张表存储全部的账户，而且对账户进行了分级、分层。例如一张个人双币主卡会有一个本币账户和一个外币账户，在本币和外币账户时已经涉及到了金额，所以有种说法是这些账户又被称为挂卡层账户，而在挂卡层账户之上有一个顶层账户。每一个挂卡层账户（实际跟金额挂钩的账户）都有一个顶层账户。顶层账户我感觉可以认为是一个父节点，而这个父节点是实际对应着一个客户的。通过顶层账户可以找到一个客户下全部子账户。这样设计的好处可以通过顶层账户去找到客户，然后进行统计分析或者反洗钱或者个人信用相关的信息。虽然通过每一个账户去找客户最后进行汇总统计也可以达到相应的目的，但是就会繁琐的多。
    然后再说账户相关的表之间的关系的设计模型吧。
    我的感觉是一切表都以账户信息为主。比如账户额度信息表、账单表、账户逾期信息表、分期信息表、客户联系信息表等，都是由账户表发散出来的，并且对账户信息表中信息进行扩展。
    在账户信息表中会有账户的余额、账户状态和更改日期、发卡的机构和网点等。在这里面有一个比较有趣的设计就是账户状态会分为账户自动状态、账户手动状态、账户自动状态的更新日期、账户手动状态的更新日期。自动状态就是系统自动根据具体的还款进行进行状态变更，这个状态是实时的，所以日期也是实时的。手动状态是用来客服和业务人员进行手动更改的字段。因为这里面存在一种情况。例如：如果一个账户逾期六个月及以上的时候，这个时候客服和业务人员就会把状态给手动调整成呆账。因为呆账是一个不可逆的行为，所以当客户还清欠款的时候就需要进行手动调节。
    账户信息表是以账户键值为主键，这个键值是系统内部之间用来表与表之间进行关联的内部账户号。而对应的则有一个外部账户号，这个账户号就是客户可见的，客户自己的账户号，这个账户号是不唯一的。内部和外部账户号之间有一个映射关系，可以对应到客户的。

yanshopping

期待您的更新，让我们有更多地了解。先为自己做个介绍吧：巨灵鸟免费ERP软件，官方网站：http://www.jlnrj.com，软件下载地址：http://www.onlinedown.net/soft/267095.htm。有兴趣的可以看看，谢谢您的光临！

王明雷

期待更新，第一次了解信用卡模型表的知识，卡——账户——客户 三者N:N:N 的关系楼主写的很清晰。希望对我以后的设计能起到帮助

493527009@qq.co

王明雷 发表于 2013/7/21 17:03
期待更新，第一次了解信用卡模型表的知识，卡——账户——客户 三者N:N:N 的关系楼主写的很清晰。希望对我 ...

呵呵
只是根据别人的模型说一点自己的看法而已.
写出来抛砖引玉大家一起交流下.

493527009@qq.co

连载2.2   账户额度、账户状态、账单
    对账户来说，重要的指标就是额度、状态、金额（这里金额包含的比较多，比如账户余额、账单金额、逾期金额、超限金额等）。
    先说账户额度这一块，有的人可能会说我的额度是卡的额度吧，跟账户有什么实际关系吗？其实一直都没说一个东西，就是客户角度和系统角度的不同。对于客户来说，他面向的是银行，极端一点的说就是他只是面对一个银行，是1：1的关系。而银行是面对很多客户的，所以它是1：N的关系。个人感觉这之间的关系可以认为系统是对实体的一种抽象化的结果。
    对于银行来说额度一般分为四种额度：信用额度（也就是账户总的额度值）、取现额度、分期额度这三种，还有一种类型叫做大额额度（此类型额度只是一个概念化的东西，暂时还未正式使用）。这三种额度具体就不用多说了。在系统中他们是存放在同一张表中，它的设计模型是以账户和额度类型还有币种（加入币种的原因是因为有双币卡的存在）作为主键。记得我第一次看到这个设计结构时还纳闷了一下为什么它不是把各种类型的额度分别作为一列而是一行。后来才发现这种设计方式是标准的数据仓库的设计方式。这种设计的扩展性、伸缩性、可维护性都是比较优秀的。
    又提到账户状态是为了引出逾期表的设计。系统中有个表专门存放账户最近十二个月的逾期状态，这个表的更新是按账单日走的，根据账单后账户的状态来决定是否在表中展现。只要账户当期逾期就会插入在此表中，这个表会存放账户历史的逾期信息。这里这样设计的一个好处是可以挖掘客户的历史信息，记录下客户的历史信用情况。而且人行征信系统也会要客户历史逾期的次数的。这种设计模式带来的一个问题就是数据量成倍的增长，对于服务器、存储空间的压力都会增长。对于银行系统来说，如果在保持数据的完整性、规律性和增加硬件之间选择的话，银行系统肯定会选择前者。换一个角度来说如果非国企和垄断行业的话，可能就不会选择这种模型。如果是我的话，我想我可能是在历史状态上进行更新，忽略其中一部分变化过程。
    关于这张表的设计有一个比较有意思的地方就是对于同一个账户，如果连续几期都是逾期的话，那么他的逾期情况变化就是一个三角形的。具体的样式就是类似于这种样式：
账户号     账期   逾期一期金额   逾期二期金额    逾期三期金额.......
001             1              1                    0                       0
001             2              1                    2                       0
001             3              1                    2                       3
      这里先提出两个概念：事务事实表就是一个行为的数据存放在表中，有则存放，无则不存放（这个里面会存放一个周期内变化的明细）；快照事实表则是一个行为的数据，发生了存放、不发生也按照一个周期存放进来（这个只体现当个周期内汇总后的变化）。这两种表都是一个事务变化的动向表，可以去研究事务的走向和趋势。
      对于账单这一块的设计方式是用了两张表，一张表是如果当期账户有金额变动才会插入到表中，一张是不管当期账户有没有金额变动都会插入到表中。对于第一种感觉是类似于事务事实表，对于第二种类似于快照事实表。这两张表都是按账期走的，也都保留历史数据。设计模型是类似于但是却又不相同，因为数据仓库最终的理念是要对数据进行汇总的，是结果。而账单涉及的两张表都只是一个明细表，是一个走势，一个过程。
    下一次就从调额历史表说下存放历史数据的设计。
   

王明雷

看了两遍，终于看出点名堂来，感觉这里面账户额度表和逾期金额的表和PeopleSoft中表层次结构设计有点类似，PeopleSoft 的特点就是他的灵活性和可扩展性，因为没有了解别的ERP系统，不知道是不是都是这个设计模式。

493527009@qq.co

由于公司项目进度问题，一直在加班赶进度，下次更新预计在下周双休或者下下周双休。

493527009@qq.co

连载2.3:交易表的存放设计、客户表的设计
    交易表的设计倒是比较有意思也比较有代表性。因为人行的要求是交易明细信息必须要存放一年。而对于交易信息，因为每天一个账户有可能会有多笔交易记录，然后在设计的时候就加了一个序列号，从1开始，每发生一笔交易记录就会自动加1（这里面的交易记录就是全部的交易记录，不管是你刷卡消费，还是手续费，利息，冲正等等），然后到下一账期又会从1开始重新计数。然后每一笔交易又会对应一个交易码、交易类型。当然也会有一个借贷记的标识,来区分是借还是贷，也就是区分是银行借出去还是收回来。
    在客户表的设计中,这里就会引出星状模型,在数据仓库维度设计中提出了一个雇员地址存放的例子,例子里提出了对雇员历史住址的历史信息的存放,它提出的一种设计理念是存放雇员的历史地址信息的变迁,对于每一次的变迁都存放在内,这里面也涉及到历史信息的存放。而在我接触的这个银行里对于客户的地址存放只存放最新的，不保留历史的记录，不考虑变迁。但是对于客户信息的设计却是一个很有意思的设计。对于很多公司来说，在设计客户信息表时，可能只会有一张表来存放。然后有一个主键来链接到别的表，通过主键来与别的表进行关联出客户信息。而这边的设计却是对于客户的信息进行分类，按属性进行划分进行区分细化。比如客户的地址信息在一张表中,客户的属性信息(性别,年龄等等)存放在另外一张表,客户的联系信息也在单独的一张表。感觉这种设计模式的好处就是扩展性，扩展性十分好。但是劣势就是在于对于信息的整合需要花费额外的性能。不过不管怎么说，老外的设计模式真的是一本理论的教科书，而国人的设计方面基本都是土八路，各有千秋吧，根据公司实际情况来决定最终的设计模式。
    下一章就举例来说历史数据的存放。
   

493527009@qq.co

2.4 历史数据的存放与比较
    对于历史数据的存放，系统中比较有代表性的例子，就是账单信息，调额信息这两块吧。
    先说数据仓库理论中比较具有代表性的保存方式。一般是有三种不同的方式去存放。自己归纳一下感觉处理方式还是就是分为：不保留历史内容而只保留最新的内容、保留历史内容（用两个字段分别去存放新的内容和旧的内容，只保留一次历史内容）、保留历史数据（用两个字段去存放新的内容和旧的内容，并且每一次更新都插入一行，保留每一次的历史内容）。当然也可以把这些模式进行组合来设计。
    这里根据系统去进行分析，发现银行系统这一块的确是做的很好。举例来说，就信用卡账户对应的信用额度来说，信用卡的额度是可以进行调整的。而系统对于信用卡的额度更改用了另外一张额度历史表去存放，每个账户每一次更改额度序号就加一，通过序号就可以判断额度更改的历史，而每次更改额度都会有永久和临时更改的标识、开始时间和截至时间，通过这些就可以对额度的历史信息进行数据分析。当然调额其实会涉及一个比较复杂的问题,就是在临时调额后额度会增加,如果没到账期,但是临时调额的时效消失了,这时候会不会属于超额呢?对于这个问题没有问过,但是理论上应该是不属于的.
      差点忘了,其实卡信息表也是一个比较明显的例子。比如卡会对应到账户，账户号是基本不会变的，当丢卡了或者换卡了之后，对于每张卡都会有一个发卡键值和发卡次数的字段，每键值对应的卡新发卡一次那么发卡次数就会自动加一，这样就可以对应到具体哪次发卡才是有效的和最新的，而且有换卡的原因和发卡的时间日期，通过这些就可以对卡的相关信息做相关分析类报表；而且对于每次换卡都会有一个字段去存放上次的卡号，而对于第一次发卡的这个系统是默认置空的。根据这个可以标识出上次的卡号，找出上次的卡号和换卡的原因，因为对于续期换卡这些卡号是不会发生变化的，而丢卡、补卡这些卡号是会发生变化的。仔细品品，真的感觉设计的很有意思，很有深意，很完美。
    当然了,历史数据的存放要以具体的业务来决定,脱离了业务一切的设计和开发都是没意义的。
   

493527009@qq.co

     本次连载也就到此为止了，比较主要的模型表设计也就这些了，至少是我接触到的层次也就到这样了，写的也比较白话。对于系统底层模型表的设计其实也就是接触到了，学到了这么一点皮毛，然后就在这连载出来。有不对的和没想到的希望各位见谅，也希望各位可以进行补充，大家一起交流探讨下。
    感谢纵横斑竹提供的机会和ERP100提供的平台，感谢纵横斑竹、王明雷的回帖支持，也感谢看过我这篇酱油帖的会员。
    再次感谢各位，谢谢。

493527009@qq.co

王明雷 发表于 2013/7/29 06:48
看了两遍，终于看出点名堂来，感觉这里面账户额度表和逾期金额的表和PeopleSoft中表层次结构设计有点类似， ...

没做过ERP
不过系统的设计和架构应该都是会从业务角度出发
然后从考虑实现和优化和扩展吧

晨露

493527009@qq.co 发表于 2013/7/12 16:20
连载1.1  整体梳理
      一般我们个人用的信用卡基本都是两种：贷记卡、准贷记卡。而针对公司、企业这种 ...

了解了，学习了。谢谢！

Doraemon

493527009@qq.co 发表于 2013/8/11 13:42
本次连载也就到此为止了，比较主要的模型表设计也就这些了，至少是我接触到的层次也就到这样了，写的 ...

本文是很结地气的文章，这一篇写完了，楼主打算再写点啥呢？不会就这样金盆洗手了吧？

493527009@qq.co

晨露 发表于 2013/8/11 16:48
了解了，学习了。谢谢！

大家共同学习，共同进步。

493527009@qq.co

Doraemon 发表于 2013/8/11 21:03
本文是很结地气的文章，这一篇写完了，楼主打算再写点啥呢？不会就这样金盆洗手了吧？

就等手里的这个供应平台的项目正式上线了
写一下供应平台的开发历程