JP6359762B2 - 口座データ管理システム - Google Patents

Description

この発明は口座データ管理システムに係り、特に、銀行等の口座に対する入出金や送金、残高照会に伴うデータ処理方式に関する。

銀行等の金融機関は、昔から顧客の預金を口座番号に紐付けて管理してきたが、最近では口座数の増大に柔軟に対処できるよう、一定数の口座グループ単位で複数のデータベースに分散して口座データを管理している。

図４は、この分散管理の一例を示すものであり、口座番号を1,000件単位で別個のDBサーバ50に割り振り、それぞれに入金テーブル52、出金テーブル54、残高テーブル56が設けられている。
ここで、例えば口座番号：００００１のユーザαがATM端末58からATMサーバ60経由でAPサーバ62にアクセスし、自己の口座に対する10,000円の入金処理を依頼すると、APサーバ62はユーザαのデータを管理している第１のDBサーバ50Aに入金データの登録を依頼する。
これに対し第１のDBサーバ50Aは、入金テーブル52Aに指定された金額分の入金データを格納する。
つぎにAPサーバ62は、第１のDBサーバ50Aに残高データの更新を依頼する。これを受けた第１のDBサーバ50Aは、残高テーブル56Aに格納されたユーザαの残高に対し、10,000円を加算する更新処理を実行する。

また、口座番号：０１００１のユーザβがATM端末58からATMサーバ60経由でAPサーバ62にアクセスし、自己の口座からの10,000円の引出処理を依頼すると、APサーバ62はユーザβのデータを管理している第２のDBサーバ50Bに出金データの登録を依頼する。
これに対し第２のDBサーバ50Bは、出金テーブル54Bに指定された金額分の出金データを格納する。
つぎにAPサーバ62は、第２のDBサーバ50Bに残高データの更新を依頼する。これを受けた第２のDBサーバ50Bは、残高テーブル56Bに格納されたユーザβの残高に対し、10,000円を減算する更新処理を実行する。

また、口座番号：０２００１のユーザγがATM端末58からATMサーバ60経由でAPサーバ62にアクセスし、自己の口座に対する残高照会処理を依頼すると、APサーバ62はユーザγのデータを管理している第３のDBサーバ50Cに残高の照会を依頼する。
これに対し第３のDBサーバ50Cは、残高テーブル56Cに格納された現時点におけるユーザγの残高データを、APサーバ62に送信する。
この残高データは、ATMサーバ60経由でATM端末58に送信され、ディスプレイに表示される。

このように、口座番号のグループ単位で異なるDBサーバ50にデータ管理を割り当てることにより、DBサーバ50側の負荷分散を図ることが可能となる。
また、口座番号が増えた場合にも、新規のDBサーバ50を追加することにより、簡単にスケールアップすることが可能となる。
さらに、何れかのDBサーバ50に障害が発生した場合であっても、影響を受けるのは一部のグループに属する口座に限定され、それ以外の口座に対しては通常通りのサービスを継続できる利点も備えている。

しかしながら、ユーザαからユーザβに対して10,000円の送金処理を行う場合、第１のDBサーバ50A内に格納されたユーザαの出金テーブル54Aに対して10,000円分の出金データを登録すると同時に、第２のDBサーバ50B内に格納されたユーザβの入金テーブル52Bに対して10,000円分の入金データを登録し、両処理の完了を確認した上でユーザαの残高テーブル56A及びユーザβの残高テーブル56Bデータを更新するという、複雑で時間を要する処理を実行しなければならない。
また、これらの途中で何れかのDBサーバ50において障害が発生した場合、APサーバ60はすべての処理を取り消して元に戻すロールバックを実行する必要が生じる（非特許文献１参照）。

さらっと覚えるSQL＆T-SQL入門（12）インターネットURL：http://www.atmarkit.co.jp/ait/articles/0803/24/news138.html 検索日：２０１５年２月２６日

この発明は、このような現状を鑑みて案出されたものであり、口座データの管理に関してDBサーバ側の分散化を実現すると同時に、口座間を跨る送金処理の簡素化を達成することを目的としている。

上記の目的を達成するため、請求項１に記載した口座データ管理システムは、出金管理用DBサーバと、入金管理用DBサーバと、APサーバと、ユーザの操作する端末装置を備え、上記出金管理用DBサーバは、出金ID、口座番号及び出金額を含む出金データを格納する出金テーブルと、送金IDを含む送金データを格納する送金テーブルと、送金IDと出金IDとの対応関係を表す出金／送金データを格納する出金／送金テーブルと、送金IDを含む送金完了データを格納する送金完了テーブルを備えており、上記入金管理用DBサーバは、入金ID、口座番号及び入金額を含む入金データを格納する入金テーブルと、送金IDを含む送金受付データを格納する送金受付テーブルと、送金IDと入金IDとの対応関係を表す入金／送金データを格納する入金／送金テーブルを備えており、上記APサーバは、上記端末装置からユーザの口座番号、金額及び送金先の口座番号を伴う送金依頼が送信された場合に、上記出金管理用DBサーバに対し、上記出金テーブルにユーザの口座番号に係る出金データを追加登録すること、上記送金テーブルにユニークな送金IDを含む送金データを追加登録すること、上記出金／送金テーブルに出金／送金データを追加登録することを依頼し、上記出金管理用DBサーバから登録完了通知が送信された場合に、上記入金管理用DBサーバに対し、上記入金テーブルに振込先の口座番号に係る入金データを追加登録すること、上記送金受付テーブルに送金受付データを追加登録すること、上記入金／送金テーブルに上記入金ID及び送金IDを含む入金／送金データを追加登録することを依頼し、当該入金管理用DBサーバから登録完了通知が送信された場合に、上記出金管理用DBサーバに対し、上記送金完了テーブルに送金完了データを追加登録することを依頼することを特徴としている。

請求項２に記載した口座データ管理システムは、請求項１のシステムであって、さらに、上記APサーバが、特定の口座番号に係る残高を参照するに際し、上記出金テーブルから当該口座番号に係る出金データを取得する処理と、各出金データの金額を加算することによって出金額の合計を算出する処理と、上記入金テーブルから上記口座番号に係る入金データを取得する処理と、各入金データの金額を加算することによって入金額の合計を算出する処理と、この入金額の合計から上記出金額の合計を減算することにより、上記口座番号の残高を導出する処理を実行することを特徴としている。

請求項３に記載した口座データ管理システムは、請求項１または２のシステムであって、さらに上記APサーバが、上記送金テーブルに格納された送金データの中で、その送金IDが上記送金完了テーブルに登録されていないものに関しては、対応の入金データ、送金受付データ、入金／送金データを上記入金管理用DBサーバに再送し、各テーブルへの追加登録を依頼することを特徴としている。

請求項４に記載した口座データ管理システムは、請求項１〜３のシステムであって、さらに、上記APサーバには複数台の出金管理用DBサーバが接続されており、上記出金管理用DBサーバにデータの登録をする際、上記APサーバは全ての出金管理用DBサーバに対して同一のデータを追加登録することを依頼すると共に、データを参照する際には、任意のDBサーバに対して必要なデータの送信を依頼し、また上記APサーバには複数台の入金管理用DBサーバが接続されており、上記入金管理用DBサーバにデータの登録をする際、上記APサーバは全ての入金管理用DBサーバに対して同一のデータを追加登録することを依頼すると共に、データを参照する際には、任意のDBサーバに対して必要なデータの送信を依頼することを特徴としている。

請求項５に記載した口座データ管理システムは、請求項４のシステムであって、さらに、上記出金管理用DBサーバ内の各テーブル及び入金管理用DBサーバ内の各テーブルには、データの追加のみが許容され、データの削除及び更新が禁止される制約が課せられていることを特徴としている。

請求項１に記載した口座データ管理システムの場合、口座管理に係るデータの格納先が出金管理用DBサーバと入金管理用DBサーバに二分されるため、DBサーバ側の負担を２系統に分散させることが可能となる。
また、APサーバが出金管理用DBサーバに出金データ、送金データ、出金／送金データを登録させた後、入金管理用DBサーバに入金データ、送金受付データ、入金／送金データを登録させ、その後出金管理用DBサーバに送金完了データを登録させることにより、入金管理用と出金管理用の２系統にDBサーバを分割させながらも、口座間を跨ぐ送金処理を有効に実現することができる。

請求項２に記載した口座データ管理システムによれば、入金額の合計から出金額の合計を減算することにより、各口座の残高を計算によって導出することが可能となり、残高管理専用のテーブルを設ける必要がなくなる。

請求項３に記載した口座データ管理システムの場合、送金完了テーブルに送金IDが登録されていない送金案件については、APサーバによって入金管理用DBサーバに対して対となる入金データ等が再送されるため、送金処理において出金データの登録だけで停滞することを有効に回避でき、結果的にデータの整合性を担保することができる。

請求項４に記載した口座データ管理システムによれば、出金管理用DBサーバが複数用意されると共に、それぞれに共通のデータが重複格納され、また、入金管理用DBサーバも複数用意されると共に、それぞれに共通のデータが重複格納される仕組みを備えているため、データの保全性を高めることができる。
また、データの参照に際し、APサーバは複数のDBサーバ中の任意のものからデータを取得することができるため、DBサーバ側の負荷分散が可能となる。

請求項５に記載した口座データ管理システムによれば、DBサーバ側の処理内容が単純化される結果、応答性能を向上させることが可能となる。
また、障害発生時には、単純に他のDBサーバから不足データをコピーするだけでデータの復旧が可能となる。

図１は、この発明に係る口座データ管理システム10の全体構成を示すものであり、APサーバ12と、入金管理用DBサーバ14と、口座管理用DBサーバ16と、出金管理用DBサーバサーバ18を備えている。

APサーバ12には、Webサーバ20を介してPC等よりなる複数のクライアント端末22が接続されている。
また、APサーバ12には、ATMサーバ24を介して複数のATM端末26が接続されている。
図示は省略したが、APサーバ12は、ロードバランサを介した多重化により、負荷分散が図られている。

入金管理用DBサーバ14には、少なくとも入金テーブル30と、入金／送金テーブル32と、送金受付テーブル34が設けられている。
入金テーブル30には、入金ID、口座番号、金額等のデータ項目を備えたレコードが格納されている。
また、入金／送金テーブル32には、入金ID、送金ID等のデータ項目を備えたレコードが格納されている。
送金受付テーブル34には、送金ID等のデータ項目を備えたレコードが格納されている。

口座管理用DBサーバ16には、少なくとも口座テーブル36が設けられている。
この口座テーブル36には、口座番号、暗証番号、預金種別、口座名義等のデータ項目を備えたレコードが格納されている。

出金管理用DBサーバ18には、少なくとも出金テーブル38と、出金／送金テーブル40と、送金テーブル42と、送金完了テーブル44が設けられている。
出金テーブル38には、出金ID、口座番号、金額等のデータ項目を備えたレコードが格納されている。
また、出金／送金テーブル40には、出金ID、送金ID等のデータ項目を備えたレコードが格納されている。
送金テーブル42には、送金ID等のデータ項目を備えたレコードが格納されている。
送金完了テーブル44には、送金ID等のデータ項目を備えたレコードが格納されている。

入金管理用DBサーバ14としては、同じテーブル（入金テーブル30、入金／送金テーブル32、送金受付テーブル34）を備えた複数のDBサーバ14', 14"…が設けられており、各DBサーバ14に対してはAPサーバ12から同時に同一データが送信され、各テーブルへの追加登録が重複実行される。
また、出金管理用DBサーバ18としても、同じテーブル（出金テーブル38、出金／送金テーブル40、送金テーブル42、送金完了テーブル44）を備えた複数のDBサーバ18', 18"…が用意されており、各DBサーバ18に対してはAPサーバ12から同時に同一データが送信され、各テーブルへの追加登録が重複実行される。

このように、それぞれ同じデータを格納した入金管理用DBサーバ14と出金管理用DBサーバ18が複数用意されているため、APサーバ12はデータの参照時には何れのDBサーバからでも自由にデータを読み出すことが可能となり、データ参照処理の効率化が図れる。
また、同じ内容を備えた一部のDBサーバを遠隔地に配置することにより、地震等の大規模災害に備えることも可能となる。

さらに、入金管理用DBサーバ14と出金管理用DBサーバ18には、データの追加と参照のみが許容され、データの更新や削除が禁止されるという制約が予め設定されている。

すなわち、一般的なDBサーバのようにデータの更新や削除を認めるとなると、一部のDBサーバに障害が発生した場合に、そのデータを復旧させるためには当該DBサーバが保持している更新ログに基づき、一定の時点からデータの追加や削除、更新を順番に再現する必要があり、これに多大な時間を要するのみならず、更新ログを確実に保存する仕組みをDBサーバ側に設ける必要性も生じる。

これに対し、データの登録に関しては「追加」のみが許容されるのであれば、他の正常に動作しているDBサーバに登録されたデータと比較し、その差分を単純にコピーするだけで追い付くことができるため、更新ログの保存が不要となり、復旧までの時間も大幅に短縮可能となる。

また、このようにデータの復旧が容易であるため、複数のDBサーバに同一データを重複格納するに際し、「２相コミット」と称するDBサーバ間での面倒な調停方式を踏襲する必要がなくなり、各DBサーバに対して単純に同一データの追加登録を依頼し、それぞれから完了通知が返ってきた時点で当該データを読み取り可能とすることができる（いわゆるオートコミットの実現）。

銀行のユーザは、ATM端末26やクライアント端末22を操作することにより、自己の口座に現金を預金したり、自己の口座から現金を引き出したりすることができる。
例えば、ユーザがATM端末26のディスプレイに表示されたサービスメニューから「預け入れ」を選択した後、キャッシュカードを挿入し、口座の暗証番号を入力すると、ATMサーバ24経由でAPサーバ12に口座番号と暗証番号が送信される。
これを受けたAPサーバ12は、口座管理用DBサーバ16の口座テーブル36を参照し、該当の口座番号及び暗証番号の正当性をチェックする。

つぎに、ユーザがATM端末26に現金を投入すると、ATM端末26からAPサーバ12に入金額が送信される。
これを受けたAPサーバ12は、入金データ（入金ID、口座番号、金額等）を入金管理用DBサーバ14に送信する。
入金管理用DBサーバ14は、この入金データを入金テーブル30に追加登録する。

また、上記のサービスメニューからユーザが「引き出し」を選択し、金額の指定を行うと、ATMサーバ24経由でAPサーバ12に引き出し金額が送信される。

これを受けたAPサーバ12は、まず当該口座の残高を算出する（残高の算出方法については後述）。
そして、残高が引き出し金額を上回っている場合には、現金払い出しの指示データをATM端末26に送信すると共に、対応の出金データ（出金ID、口座番号、金額等）を生成し、出金管理用DBサーバ18に送信する。
出金管理用DBサーバ18は、この出金データを出金テーブル38に追加登録する。

ユーザは、自宅や職場に置かれたクライアント端末22からWebサーバ20経由でAPサーバ12にアクセスし、電子マネーカードを用いた預け入れや引き出し（チャージ）を行うこともできる。

つぎに、図２のフローチャートに従い、このシステム10を用いた口座間での送金方法について説明する。
まず、ユーザがATM端末26のディスプレイに表示されたサービスメニューから「振り込み」を選択した後、金額の指定、振込先口座番号の指定を行うと、ATMサーバ24経由でAPサーバ12に送金依頼データが送信される。この送信依頼データには、ユーザの口座番号、振込先の口座番号及び金額が含まれている。

これを受けたAPサーバ12は（Ｓ10）、ユニークな送金ID及び出金IDを生成すると共に、送金データ（送金ID等）、出金データ（出金ID、ユーザの口座番号、金額等）、出金／送金データ（出金ID、送金ID等）を生成し、これらを出金管理用DBサーバ18に送信して、送金テーブル42、出金テーブル38、出金／送金テーブル40への登録を依頼する（Ｓ12）。

これを受けた出金管理用DBサーバ18では、送金テーブル42、出金テーブル38、出金／送金テーブル40に対して、送金データ、出金データ、出金／送金データが、一つのトランザクションとして一括して追加される。

出金管理用DBサーバ18から各テーブルに対する登録完了通知を受け取ったAPサーバ12はユニークな入金IDを生成した上で、送金受付データ（送金ID等）、入金データ（入金ID、振込先の口座番号、金額等）、入金／送金データ（入金ID、送金ID等）を生成し、これらを入金管理用DBサーバ14に送信して、送金受付テーブル34、入金テーブル30、入金／送金テーブル32への登録を依頼する（Ｓ14）。

これを受けた入金管理用DBサーバ14では、送金受付テーブル34、入金テーブル30、入金／送金テーブル32に対して、送金受付データ、入金データ、入金／送金データが、一つのトランザクションとして一括して追加される。

入金管理用DBサーバ14からの登録完了通知を受け取ったAPサーバ12は、送金完了データ（送金ID等）を出金管理用DBサーバ18に送信し、送金完了テーブルへの登録を依頼する（Ｓ16）。

この送金完了テーブルに送金IDが登録された時点で、一連の送金処理が無事に完了したこととなるため、APサーバ12は定期的に送金テーブル42と送金完了テーブル44をチェックし、送金テーブル42に送金IDが登録されていない送金処理が存在する場合（Ｓ18／Ｎ）、入金データ、入金／送金データ、送金受付データを入金管理用DBサーバ14に再送する（Ｓ14）。

何らかの原因によって最初の依頼が到達していなかった場合、入金管理用DBサーバ14は再送された登録依頼に基づき、改めて各データの一括追加を完了させた後、登録完了通知をAPサーバ12に送信する。
これに対し、最初の依頼に基づいて各データの追加登録が完了しており、ただ通信障害等によって登録完了通知がAPサーバ12に届いていなかったような場合、入金管理用DBサーバ14は２回目以降の登録依頼に基づいてデータを重複登録することはせずに、登録完了通知を再送する。

これは、同一IDを備えたデータの重複登録を自動的に排除するDBサーバ本来の機能に基づいて実現される。
すなわち、入金データ及び入金／送金データのプライマリキーである「入金ID」としては、入金データの再送毎に新規のIDが払い出されることになるが、送金受付データのプライマリキーには当初の「送金ID」が充填されているため、この送金IDをチェックすることでDBサーバはデータの重複登録を回避することが可能となる。

入金管理用DBサーバ14からの登録完了通知を受け取ったAPサーバ12は、送金完了データを出金管理用DBサーバ18に送信し、送金完了テーブルへの登録を依頼する（Ｓ16）。

送金完了テーブル44に対応の送金IDが登録されていることを確認したAPサーバ12は（Ｓ18／Ｙ）、ATMサーバ24経由でATM端末26に送金完了を通知する（Ｓ20）。

なお、上記Ｓ18→Ｓ14→Ｓ16の処理を一定回数繰り返しても送金完了テーブル44に送金IDが登録されない場合、APサーバ12はATM端末26に対してタイムアウトエラーの電文を送信する。

つぎに、図３のフローチャートに従い、このシステム10を用いた口座の残高照会の手順について説明する。
まず、ユーザがATM端末26のディスプレイに表示されたサービスメニューから「残高照会」を選択すると、ATMサーバ24経由でAPサーバ12に口座番号を伴う残高照会依頼が送信される。

これを受けたAPサーバ12は（Ｓ30）、上記口座番号を出金管理用DBサーバ18に送信し、当該口座番号に関連付けられた出金データの抽出を依頼する（Ｓ32）。
そして、出金管理用DBサーバ18から該当の出金データが送信されると、APサーバ12は、各出金データの金額を加算し、その合計金額を求める（Ｓ34）。

つぎにAPサーバ12は、上記口座番号を入金管理用DBサーバ14に送信し、当該口座番号に関連付けられた入金データの抽出を依頼する（Ｓ36）。
そして、入金管理用DBサーバ14から該当の入金データが送信されると、APサーバ12は各入金データの金額を加算し、その合計金額を求める（Ｓ38）。

つぎにAPサーバ12は、入金データの上記合計金額から出金データの上記合計金額を減算することにより、現時点における残高を導出する（Ｓ40）。
この残高データは、ATMサーバ24を経由してATM端末26に送信され（Ｓ42）、ディスプレイに表示される。

上記においては、ATM端末26上でユーザが残高照会を選択した場合について説明したが、引き出しや振り込みの前処理として口座の残高を確認する場合であっても、APサーバ12は同様の処理手順によって口座の残高を算出する。

このように、口座の残高を管理する専用のテーブルをDBサーバ側に設けることなく、必要に応じて計算によって算出する方式を採用することにより、送金という口座間を跨る処理を行う際に、送金元口座からの出金処理と、送金先口座への入金処理とを切り離すことが可能となる。

すなわち、従来のように残高テーブルを設けて残高の管理を行うとなると、送金処理に際し送金元口座からの出金と送金先口座への入金を同時に行い、その結果を両者の残高に反映させる必要が生じ、複数のDBサーバ間におけるタイミングの調整（２相コミット）が不可欠となる。
また、万が一何れか一方の処理が失敗した場合には、各テーブルの状態を元に戻す処理（ロールバック）が必要となる。

もちろん、残高確認の必要性が生じる都度、計算によって残高を算出するとなると、APサーバ12側の負荷が増大することは否めないが、上記のようにロードバランサを介してAPサーバ12を多重化したり、マルチコア化したサーバコンピュータでAPサーバ12を構成したりすることにより、十分に対応可能となる。

また、このシステム10の場合、上記のように入金管理用DBサーバ14及び出金管理用DBサーバ18に格納されるテーブルには、レコードの削除及び更新が禁止される制約が課せられており、単にレコードの追加と参照のみが許可される仕組みであるため、DBサーバ側の処理も効率化される利点がある。

このシステム10によれば、送金処理において、出金側データの登録処理と入金側データの登録処理との間に若干のタイムラグが生じることは避けられないが、取引の実情を考慮すれば問題にならないレベルといえる。
また、送金完了テーブル44に送金IDが登録されるまで、APサーバ12から入金管理用DBサーバ14に対して入金データ、入金／送金データ、送金受付データが再送される仕組みを備えているため、複数の入金管理用DBサーバ14…中の少なくとも１台と、複数の出金管理用DBサーバ18…中の少なくとも１台が稼働している限りにおいて結果的にデータの整合性が担保される利点を有している。

また、データ管理機能を入金管理用DBサーバ14と出金管理用DBサーバ18に二分した結果、分散処理による効率化が図れる。
しかも、入金管理用DBサーバ14と出金管理用DBサーバ18を、それぞれ同一のテーブル、同一のデータを備えた複数のDBサーバによって多重化することにより、APサーバ12は複数のDBサーバから同時並行的にデータの抽出を行うことができ、さらなる処理の効率化が図れる。

上記においては、銀行の預金口座に係るデータ管理にこのシステム10を適用した例を示したが、この発明はこれに限定されるものではない。
例えば、ユーザのポイントを管理する口座のデータ管理にこのシステム10を適用することが考えられる。
この場合、「入金」は「ポイント追加」と、「出金」は「ポイント利用（適用）」と、「送金」は「ポイント譲渡」と、「残高」は「ポイント残高」と、「金額」は「ポイント数」と、「口座番号」は「アカウント」などと読み替えればよい。

この発明に係る口座データ管理システムの全体構成を示す模式図である。 このシステムにおける送金処理の手順を示すフローチャートである。 このシステムにおける残高照会処理の手順を示すフローチャートである。 従来の口座データ管理手法の一例を示す模式図である。

10 口座データ管理システム
12 APサーバ
14 入金管理用DBサーバ
16 口座管理用DBサーバ
18 出金管理用DBサーバサーバ
20 Webサーバ
22 クライアント端末
22 クライアント端末
24 ATMサーバ
26 ATM端末
30 入金テーブル
32 入金／送金テーブル
34 送金受付テーブル
36 口座テーブル
38 出金テーブル
40 出金／送金テーブル
42 送金テーブル
44 送金完了テーブル

Claims (5)

1. 出金管理用DBサーバと、入金管理用DBサーバと、APサーバと、ユーザの操作する端末装置を備え、
   上記出金管理用DBサーバは、出金ID、口座番号及び出金額を含む出金データを格納する出金テーブルと、送金IDを含む送金データを格納する送金テーブルと、送金IDと出金IDとの対応関係を表す出金／送金データを格納する出金／送金テーブルと、送金IDを含む送金完了データを格納する送金完了テーブルを備えており、
   上記入金管理用DBサーバは、入金ID、口座番号及び入金額を含む入金データを格納する入金テーブルと、送金IDを含む送金受付データを格納する送金受付テーブルと、送金IDと入金IDとの対応関係を表す入金／送金データを格納する入金／送金テーブルを備えており、
   上記APサーバは、上記端末装置からユーザの口座番号、金額及び送金先の口座番号を伴う送金依頼が送信された場合に、上記出金管理用DBサーバに対し、上記出金テーブルにユーザの口座番号に係る出金データを追加登録すること、上記送金テーブルにユニークな送金IDを含む送金データを追加登録すること、上記出金／送金テーブルに出金／送金データを追加登録することを依頼し、
   上記出金管理用DBサーバから登録完了通知が送信された場合に、上記入金管理用DBサーバに対し、上記入金テーブルに振込先の口座番号に係る入金データを追加登録すること、上記送金受付テーブルに送金受付データを追加登録すること、上記入金／送金テーブルに上記入金ID及び送金IDを含む入金／送金データを追加登録することを依頼し、
   当該入金管理用DBサーバから登録完了通知が送信された場合に、上記出金管理用DBサーバに対し、上記送金完了テーブルに送金完了データを追加登録することを依頼することを特徴とする口座情報管理システム。
2. 上記APサーバが、特定の口座番号に係る残高を参照するに際し、
   上記出金テーブルから当該口座番号に係る出金データを取得する処理と、
   各出金データの金額を加算することによって出金額の合計を算出する処理と、
   上記入金テーブルから上記口座番号に係る入金データを取得する処理と、
   各入金データの金額を加算することによって入金額の合計を算出する処理と、
   この入金額の合計から上記出金額の合計を減算することにより、上記口座番号の残高を導出する処理と、
   を実行することを特徴とする請求項１に記載の口座情報管理システム。
3. 上記APサーバは、上記送金テーブルに格納された送金データの中で、その送金IDが上記送金完了テーブルに登録されていないものに関しては、対応の入金データ、送金受付データ、入金／送金データを上記入金管理用DBサーバに再送し、各テーブルへの追加登録を依頼することを特徴とする請求項１または２に記載の口座情報管理システム。
4. 上記APサーバには、複数台の出金管理用DBサーバが接続されており、上記出金管理用DBサーバにデータの登録をする際、上記APサーバは全ての出金管理用DBサーバに対して同一のデータを追加登録することを依頼すると共に、データを参照する際には、任意のDBサーバに対して必要なデータの送信を依頼し、
   また、上記APサーバには、複数台の入金管理用DBサーバが接続されており、上記入金管理用DBサーバにデータの登録をする際、上記APサーバは全ての入金管理用DBサーバに対して同一のデータを追加登録することを依頼すると共に、データを参照する際には、任意のDBサーバに対して必要なデータの送信を依頼することを特徴とする請求項１〜３の何れかに記載の口座情報管理システム。
5. 上記出金管理用DBサーバ内の各テーブル及び入金管理用DBサーバ内の各テーブルには、データの追加のみが許容され、データの削除及び更新が禁止される制約が課せられていることを特徴とする請求項４に記載の口座情報管理システム。

Images