通存通兑 是如何实现的!! 看看下面这段银行的数据库说明!!

frankhuai 2003-10-06 06:39:35
对银行560个服务器实现通存通兑,实现统一的会计账务管理.
数据库按地域划分为不同的地区数据库,不同的数据库放置于不同的主机上,数据库的划分应不影响到上下级行的隶属关系。每个数据库中包括共享表、历史数据表、文件表和各地区数据表。


通存通兑 是如何实现的!
比如一个持卡人在西安办的卡, 但他去北京消费刷卡, 而北京没有他的存款纪录,是不是建立一个共享表,现将消费的金额,卡号,等等数据记录的共享表里。 然后再将数据传到总服务器,总服务器在将数据传到西安的服务器来检查存款余额是不是足够和账户是不是有效。
...全文
112 25 打赏 收藏 转发到动态 举报
写回复
用AI写文章
25 条回复
切换为时间正序
请发表友善的回复…
发表回复
frankhuai 2003-10-07
  • 打赏
  • 举报
回复
有个问题, 比如刚才的西安改为纽约。 他们都只能和一个服务器通信(visa) 而visa 服务器并没有客户的具体资料,这样的话如何解决。 是不是必须用共享表。
zosky 2003-10-07
  • 打赏
  • 举报
回复
如果你是从头做起,不考虑和以前系统的兼容的话还是只设一个主服务器,所有交易都上主服务器,下挂若干个客户机,这样可以避免很多麻烦。
如果交易不是联机的话那会员卡必须可以透支,不能透支的话也可以用IC卡小额圈存,现在也有成熟的系统了
frankhuai 2003-10-07
  • 打赏
  • 举报
回复
To: j9988(j9988)
那就是说只要在客户的存款明细表里增加一个列, 异地存取款列,

其他的表是银行和银行之间结算方面的。
frankhuai 2003-10-07
  • 打赏
  • 举报
回复
j9988(j9988) 可真是老师!!


听他一席话胜看3天书
frankhuai 2003-10-07
  • 打赏
  • 举报
回复
TO: dragoner()
分布式事务不就是这样的吗?
begin distributed transaction
同时向几个服务器发布准备命令,如果ok 然后同时写数据到各个服务器的数据库中。


我现在的问题是: 有一个服务器没有联网, 只是在规定的时间联网。

zosky 2003-10-07
  • 打赏
  • 举报
回复
看起来做需求的人也不太懂,楼主也不太懂,作出来的系统。。不敢想象
劝楼主还是先搞清楚一些银行系统的基本架构再说
dragoner 2003-10-07
  • 打赏
  • 举报
回复
如果我来做数据库设计的话, 首先将银行的交易结做一完成图表, 加文字说明将各种可能都举出来,不要考虑有几个服务器。 E-R图也行。 然后问银行真的正的需求, 以及可以想象的的以后银行的需求。 进行一只有一个服务器的数据库设计。 这样你可以对整个需求,整个数据库架构很清楚。 在这基础上你去看一下分布式数据库设计。 其中的很多设思想你可以拿过用。 再过考虑有几台服务器。 你连分布式数库设计的一些基本理信念都不是很清楚。 即时告诉你解决办法也没有用啊。否则都是白说。你也不能说清问题啊,人家也帮不了你,。
zjcxc 元老 2003-10-07
  • 打赏
  • 举报
回复
坐听学.
j9988 2003-10-07
  • 打赏
  • 举报
回复
这是定时对帐的问题,会员卡一般可以透支。且支付有限额的(或通过电话受权)。
没什么关系啊。
只要发生地点留下卡号,交易金额,交易地点等必要信息。
等时间到时,往发卡地区服务器上记帐。
frankhuai 2003-10-07
  • 打赏
  • 举报
回复
这样说,他们都24小时一直互联着的。
我现在遇到的问题是: 比如有一个世纪会员卡, 拿着这个会员卡可以到全国任何地方去消费,现在会员卡公司服务器24小时, 两个客户端,一个是发卡地区,一个是消费地区。但客户端不是总联网,只是在规定的时候从总服务器取一下数据。 这种情况下。想直接访问对方发卡地区主机,但主机没有联网,怎么解决好。

j9988 2003-10-07
  • 打赏
  • 举报
回复
服务器通信(visa)可以访问双方的机器啊。
一般来说银行都是用小型或大型机,每项业务都有前置机。VISA机如果是中间通信机,必须访问对应业务的前置机。绝对不可能有共亨表。VISA机最多只留下这笔业务信息供对帐用。
zhoutian618 2003-10-07
  • 打赏
  • 举报
回复
没有做过银行方面的。
我来学习一下。
frankhuai 2003-10-07
  • 打赏
  • 举报
回复
根据j9988(j9988) 和 HeroRose() 的解说和建议:
我决定这样处理:
建立存款纪录表, 和共享存借款记录表
1,判断如果是本地卡,直接在本地的存款纪录表里插入一列数据。
2,如果是异地卡:使用分布式事务处理,验证后,同时向总部服务器和本地的共享存借款记录表插入一条记录。再在本地的共享存借款记录表里做一触发器插入本地存款纪录表一条记录。(具体我是同时向本地的两个表和服务器的一个表插入纪录,这样说便于理清思路)
3,另外的一个服务器访问总服务器,检查共享存借款记录表,判断如果有新的记录那么将这条记录插入本地表。
zosky 2003-10-06
  • 打赏
  • 举报
回复
单靠数据库触发器什么的是肯定不行的,做到后面肯定没法做

你是只做数据库还是整个一套系统?
j9988 2003-10-06
  • 打赏
  • 举报
回复
比如一个持卡人在西安办的卡, 但他去北京消费刷卡,数据传到西安的服务器来检查存款余额是不是足够和账户是不是有效。
这时各产生两笔帐务。

一个借方:北京经办部门现金付出(借方)
     北京代理应收(贷方)

西安   被代理业务应付(贷方)
     帐户现金付出(借方)
但都是直接方问对方服务器。不必生成共亨表。因为有公共接口。夸行取款出一样。
这一点我可以保证。
frankhuai 2003-10-06
  • 打赏
  • 举报
回复
是的,我的确没有方案, 我正在建立表, 我计划建立几个共享表:
如果不是本地消费而是异地消费,那么就将纪录插入到共享表里。 共享表建立一个触发器。传给总部服务器, 总部服务器认证,总部服务器再传给原来地。 原来的地区认证后做一条记录。记录下来消费纪录,然后再传给总部,总部再传给消费地。
zosky 2003-10-06
  • 打赏
  • 举报
回复
我觉得你一点思路都没有啊,是全行大集中还是各个地区都有自己的地区中心?
你搞清楚需求再说
ps,我不是银行的,也不是软件公司的,有些细节也不太清楚
frankhuai 2003-10-06
  • 打赏
  • 举报
回复
我现在设计表,想知道 一个服务器先建立基本的存款纪录表,消费纪录表, 如果是,通存通兑,还需要设计什么表。
zosky 2003-10-06
  • 打赏
  • 举报
回复
并不是所有的卡号都放进一张表里,只是头几位,数据量不大,就和IP的B网段C网段一样,
银联有点象路由器,二三磁道都有可能存卡号,卡号是不是合法不单靠验证码判,有的银行没有验证码的
frankhuai 2003-10-06
  • 打赏
  • 举报
回复
中国最少还没有一亿张银行卡,我就有8张银行卡。 这样数据量不就太大了吗? 难道都写在一张表里。 我知道银联卡的卡号判断是不是合法,是第二磁道的有一验证码。来验证卡号是不是合法! 第三磁道写的是一些信息。
加载更多回复(5)
随着人们对大型数据系统研究、管理、维护等方面的深刻识认和不断完善,在总结、丰富、集中多行企业信息的经验之后,为数据仓库给出了更为精确的定义,即“数据仓库是在企业管理和决策中面向主题的、集成的、与时间相关的、不可修改的数据集合”。

数据仓库并没有严格的数学理论基础,也没有成熟的基本模式,且更偏向于工程,具有强烈的工程性。因此,在技术上人们习惯于从工作过程等方面来分析,并按其关键技术部份分为数据的抽取、存储与管理以及数据的表现等三个基本方面。

  ⑴数据的抽取:数据的抽取是数据进入仓库的入口。由于数据仓库是一个独立的数据环境,它需要通过抽取过程将数据从联机事务处理系统、外部数据源、脱机的数据存储介质中导入到数据仓库。数据抽取在技术上主要涉及互连、复制、增量、转换、调度和监控等方面。数据仓库中的数据并不要求与联机事务处理系统保持实时同步,因此数据抽取可以定时进行,但多个抽取操作执行的时间、相互的顺序、成败对数据仓库中信息的有效性则至关重要。

  ⑵存储和管理:数据仓库的真正关键是数据的存储和管理。数据仓库的组织管理方式决定了它有别于传统数据库,同时也决定了其对外部数据的表现形式。要决定采用什么产品和技术来建立数据仓库的核心,则需要从数据仓库的技术特点着手分析。

  ⑶数据的表现:数据表现实际上相当于数据仓库的门面,其性能主要集中在多维分析、数理统计和数据挖掘方面。而多维分析又是数据仓库的重要表现形式,近几年来由于互联网的发展,使得多维分析领域的工具和产品更加注重提供基于Web前端联机分析界面,而不仅仅是在网上发布数据。

  提到数据仓库,人们难免会想到仅有一字之差的数据库,那么,数据仓库和我们经常提到的数据库有哪些区别呢?为什么要使用数据仓库呢?

数据库到数据仓库
  市场需求是技术发展的源动力。在数据库应用的早期,计算机系统所处理的是从无到有的问题,是传统手工业务自动化的问题。例如银行的储蓄系统、电信的计费系统,它们都属于典型的联机事务处理系统。在当时,一个企业可以简单地通过拥有联机事务处理的计算机系统而获得强大的市场竞争力。记得在80年代末,北京工商银行率先推出了全市个人储蓄通存通兑业务,广大市民便将先前就近存于不同银行的存款一并取出而存入了工商银行。这便是通过联机事务处理系统而获得市场优势的案例。其次,当时单位容量的联机存储介质比现在昂贵得多,相对于市场竞争的压力,将大量的历史业务数据长时间联机保存去用于分析显然是过于奢侈了。因此,联机事务处理系统只涉及当前数据,系统积累下的历史业务数据往往被转储到脱机的环境中。此外,在计算机系统应用的早期,还没有积累大量的历史数据可供统计与分析。从而,联机事务处理成为整个80年代直到90年代初数据库应用的主流。

  然而,应用在不断地进步,当联机事务处理系统应用到一定阶段的时候,企业家们便发现单靠拥有联机事务处理系统已经不足以获得市场竞争的优势;他们需要对其自身业务的运作以及整个市场相关行业的态势进行分析,从而做出有利的决策。同样就拿北京各银行的储蓄业务来说,如今各家都拥有了联网的储蓄系统,再要获得市场竞争的优势,就需要在决策上下功夫,例如在业务密集地区增设自助网点、推出有针对性(如:某类职业圈、某年龄段)的储蓄服务计划。这些决策需要对大量的业务数据包括历史业务数据进行分析才能得到,而这种基于业务数据的决策分析,我们把它称之为联机分析处理。如果说传统联机事务处理强调的是更新数据库——向数据库中添加信息,那么联机分析处理就是要从数据库中获取信息、利用信息。因此,著名的数据仓库专家Ralph Kimball写道:“我们花了20多年的时间将数据放入数据库,如今是该将它们拿出来的时候了。”

  事实上,将大量的业务数据应用于分析和统计原本是一个非常简单和自然的想法。但在实际的操作中,人们却发现要获得有用的信息并非想象的那么容易:第一,所有联机事务处理强调的是数据更新处理性能和系统的可靠性,并不关心数据查询的方便与快捷;联机分析和事务处理对系统的要求不同,同一个数据库在理论上难以做到两全;第二,业务数据往往被存放于分散的异构环境中,不易统一查询访问,而且还有大量的历史数据处于脱机状态,形同虚设;第三,业务数据的模式是针对事务处理系统而设计的,数据的格式和描述方式并不适合非计算机专业人员进行业务上的分析和统计。于是,有人感叹:20年前查询不到数据是因为数据太少了,而今天查询不到数据是因为数据太多了。针对这一问题,人们专门为业务的统计分析建立一个数据中心,它的数据可以从联机的事务处理系统、异构的外部数据源、脱机的历史业务数据中得到;它是一个联机的系统,专门为分析统计和决策支持应用服务,通过它可满足决策支持和联机分析应用所要求的一切。这个数据中心就叫做数据仓库。如果需要给数据仓库一个定义的话,那么可以把它看作一个作为决策支持系统和联机分析应用数据源的结构化数据环境。数据仓库所要研究和解决的问题就是从数据库中获取信息。

  那么数据仓库与数据库(主要指关系数据库)又是什么关系呢?回想当初, 人们固守封闭式系统是出于对事务处理的偏爱, 人们选择关系数据库是为了方便地获得信息。我们只要翻开 C.J. Date博士的经典之作《An Introduction to Database Systems》便会发现:今天数据仓库所要提供的正是当年关系数据库要所倡导的。然而,“成也萧何,败也萧何”,由于关系数据库系统在联机事务处理应用中获得的巨大成功,使得人们已不知不觉将它划归为事务处理的范畴;过多地关注于事务处理能力的提高,使得关系数据库在面对联机分析应用时又显得“老革命遇到新问题”——今天的数据仓库对关系数据库的联机分析能力提出了更高的要求,采用普通关系型数据库作为数据仓库在功能和性能上都是不够的,它们必须有专门的改进。因此,数据仓库与数据库的区别不仅仅是应用的方法和目的上的,同时也涉及产品和配置。

  以辩证的眼光来看,数据仓库的兴起实际上是数据管理的一种回归,是螺旋式的上升。今天的数据库就好比当年的层次数据库和网型数据库,它们面向事务处理;今天的数据仓库就好比是当年的关系数据库,它针对联机分析。所不同的是,今天的数据仓库不必再为联机事务处理的特性而奔忙,由于技术的专业化,它可更专心于联机分析领域的发展和探索。

  从厂商的角度看,经过长期发展,联机事务处理系统的市场至90年代中期出现饱和迹象,其增长速度明显减慢。这导致各大数据库厂商的传统业务增长面临严峻挑战,寻求新的业务增长点成为他们的当务之急。数据仓库的兴起无疑为数据库产品创造了巨大的市场,它成为20世纪末到21世纪初数据库市场的一个新的增长点。因此,数据仓库这个词儿打一开始便伴随着轰轰烈烈的市场炒作。对于广大用户来说,只有从自身应用需求出发,破除技术和概念的神秘性,奉行“拿来主义”,避虚就实,密切关注技术发展的方向,方可获得满意的产品、解决方案和经济效益。

  总之,数据仓库并非是一个仅仅存储数据的简单信息库,因为这实际上与传统数据库没有两样。数据仓库实际上是一个“以大型数据管理信息系统为基础的、附加在这个数据库系统之上的、存储了从企业所有业务数据库中获取的综合数据的、并能利用这些综合数据为用户提供经过处理后的有用信息的应用系统”。如果说传统数据库系统的重点与要求是快速、准确、安全、可靠地将数据存进数据库中的话,那么数据仓库的重点与要求就是能够准确、安全、可靠地从数据库中取出数据,经过加工转换成有规律信息之后,再供管理人员进行分析使用。

34,590

社区成员

发帖
与我相关
我的任务
社区描述
MS-SQL Server相关内容讨论专区
社区管理员
  • 基础类社区
  • 二月十六
  • 卖水果的net
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧