JP2017091213A - データベース更新処理システムおよびデータベース更新処理方法 - Google Patents

Abstract

【課題】勘定系システムにおけるオンライン系の処理結果をバッチ系にリアルタイムに反映する。
【解決手段】データベース更新処理システム１０において、バッチ処理キュー１２５を保持する記憶装置１０１と、各オンライン系システムでのトランザクションに関し、データ更新対象の資源および自他各々のオンライン系システムでのトランザクション間のデータ更新完了順序の各情報に基づき、各トランザクションによる当該資源に対するデータ更新事象の情報を生成し、バッチ処理キュー１２５が規定するオンライン系システムの当該資源とデータ利用系システムの資源とに対応付けてデータ利用系システム２００に送る演算装置１０４を備えたオンライン系システム１０を含む構成とする。
【選択図】図２

Description

本発明は、データベース更新処理システムおよびデータベース更新処理方法に関するものであり、具体的には、勘定系システムにおけるオンライン系の処理結果をバッチ系にリアルタイムに反映する技術に関する。

金融機関における勘定系システムは、顧客の口座残高等の管理、入出金や振込、決済といった各種処理を実行する。そのため勘定系システムには高い性能と信頼性が要求され、大規模システムであるケースが多い。

こうした勘定系システムにおける処理は、大きく分けてオンライン系とバッチ系の２種類の処理からなる。このうちオンライン系は、例えば、顧客による口座からの現金引出し動作や口座への現金預け入れ動作の度に該当顧客の口座残高を更新するといった処理が該当する。一方、バッチ系は、上述のオンライン処理の結果を踏まえつつ、例えば、クレジットカード利用代金等を各顧客口座から引落として、口座残高を更新する処理などが該当する。

このようなオンライン系とバッチ系を含む情報システムにおけるデータアクセスの技術としては、例えば、ネットワークＮ１およびＮ２に接続している複数のデータ利用系システムと、ネットワークＮ２に接続している複数のデータ提供系システムと、を備えて構成される情報システムにおけるデータアクセス方法であって、データ利用系システムＰ１が、他のデータ利用系システムＰ２に対しデータ提供系システムＤ２のデータの利用要求をネットワークＮ１を通じて送信し、前記データ利用要求を受信したデータ利用系システムＰ２は、ネットワークＮ２を通じて前記データ利用要求に対応する処理の実行要求をデータ提供系システムＤ２に送信し、前記実行要求を受信したデータ提供系システムＤ２は、この実行要求に対応する処理を実行して必要なデータをネットワークＮ２を通じてデータ提供系システムＤ１に送信し、データ提供系システムＤ１は、前記データを受信してこれを記憶する情報システムにおけるデータアクセス方法（特許文献１参照）などが提案されている。

特開２００４−５４６０号公報

上述したオンライン系での取引結果は、夜間バッチ処理によって、バッチ系のＤＢおよびサブシステムに適宜反映されている。そのため、金融機関の所定担当者がサブシステムにて情報照会を行う場合、得られる情報は前日分までの取引結果でしかない。つまり上述の担当者はリアルタイムで顧客の取引情報を把握することが出来ない。

一方、オンライン系とバッチ系（およびサブシステム）とではデータベース構成が異なっており、サブシステムからオンラインＤＢを直接参照することや、オンラインＤＢのレプリカをサブシステム側に作成して参照用に用いる、といった構成を採用することも出来ない。また、勘定系取引では１取引で複数ＤＢを更新するため、単純なデータ転送でバッチ系のＤＢ更新を行うとしても、データの整合性が取れなくなる懸念がある。

そこで本発明の目的は、勘定系システムにおけるオンライン系の処理結果をバッチ系にリアルタイムに反映する技術を提供することにある。

上記課題を解決する本発明のデータベース更新処理システムは、所定のオンライン系システムでのデータ更新対象の資源と、当該オンライン系システムでのデータ更新結果を利用するデータ利用系システムの資源との対応関係を規定したテーブルを保持する記憶装置と、各オンライン系システムで実行されたトランザクションに関して、データ更新対象とされた資源、および自他それぞれのオンライン系システムでのトランザクション間のデータ更新完了順序、の各情報に基づき、各トランザクションによる当該資源に対するデータ更新事象の情報を生成し、当該生成した更新情報を、前記テーブルが規定するオンライン系システムの当該資源とデータ利用系システムの資源とに対応付け、更新要求として前記データ利用系システムに送信する演算装置と、を備えたオンライン系システムを含むことを特徴とする。

また、本発明のデータベース更新処理方法は、所定のオンライン系システムでのデータ更新対象の資源と、当該オンライン系システムでのデータ更新結果を利用するデータ利用系システムの資源との対応関係を規定したテーブルを保持する記憶装置を備えたオンライン系システムが、各オンライン系システムで実行されたトランザクションに関して、データ更新対象とされた資源、および自他それぞれのオンライン系システムでのトランザクション間のデータ更新完了順序、の各情報に基づき、各トランザクションによる当該資源に対するデータ更新事象の情報を生成し、当該生成した更新情報を、前記テーブルが規定するオンライン系システムの当該資源とデータ利用系システムの資源とに対応付け、更新要求として前記データ利用系システムに送信することを特徴とする。

本発明によれば、勘定系システムにおけるオンライン系の処理結果をバッチ系（情報系たるサブシステムの概念含む）にリアルタイムに反映することが可能となる。

本実施形態のデータベース更新処理システムの構成例を示す図である。 本実施形態のオンライン系システムのハードウェア構成例を示す図である。 本実施形態のデータ利用系システムのハードウェア構成例を示す図である。 本実施形態のバッチ処理キューのデータ構成例を示す図である。 本実施形態のバッチＤＢキューのデータ構成例を示す図である。 本実施形態のデータベース更新処理方法のフロー例１を示す図である。 本実施形態における各オンライン系でのトランザクション実行例を示す図である。 本実施形態のデータベース更新処理方法のフロー例２を示す図である。 本実施形態における更新要求の具体例を示す図である。 本実施形態におけるバッチＤＢキューでのレコード例を示す図である。 本実施形態における処理通番の比較概念を示す図である。 本実施形態におけるエントリシフトの概念を示す図である。 本実施形態のデータベース更新処理方法のフロー例３を示す図である。 本実施形態における自他の処理＃の合算概念を示す図である。 本実施形態のバッチＤＢキューでのエントリ管理の概念を示す図である。

−−−システム構成−−−
以下に本発明の実施形態について図面を用いて詳細に説明する。図１は、本実施形態の
データベース更新処理システム１０の構成例を示す図である。図１に示すデータベース更新処理システム１０は、金融機関における勘定系システムに該当する。こうしたデータベース更新処理システム１０は、当該勘定系システムにおけるオンライン系システム１００での処理結果を、データ利用系システム２００（バッチ系：情報系たるサブシステムの概念含む）のデータベース等の資源にリアルタイムに反映するコンピュータシステムである。

本実施形態におけるデータベース更新処理システム１０は、複数のオンライン系システム１００と、これの処理結果を利用するデータ利用系システム２００とから構成される。

各オンライン系システム１００において実行されたオンライントランザクションの結果は、オンラインＤＢ１１０の格納情報を更新すると共に、適宜な処理を経て更新情報となり、バッチ処理キュー１２５に格納される。このバッチ処理キュー１２５に格納された更新情報は更新要求としてデータ利用系システム２００に送信される。

一方、データ利用系システム２００が上述のオンライン系システム１００から受信した更新要求はバッチＤＢキュー２２５に格納され、適宜な処理を経てバッチＤＢ２１０（すなわち資源）の格納情報を更新するものとなる。

−−−ハードウェア構成−−−
図２は本実施形態のオンライン系システム１００のハードウェア構成例を示す図である。本実施形態におけるオンライン系システム１００のハードウェア構成は以下の如くとなる。すなわちオンライン系システム１００は、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）やハードディスクドライブなど適宜な不揮発性記憶素子で構成される記憶装置１０１、ＲＡＭなど揮発性記憶素子で構成されるメモリ１０３、記憶装置１０１に保持されるプログラム１０２をメモリ１０３に読み出すなどして実行し装置自体の統括制御を行なうとともに各種判定、演算及び制御処理を行なうＣＰＵなどの演算装置１０４、ネットワーク１と接続してデータ利用系システム２００との通信処理を担う通信装置１０５、を備える。

なお、記憶装置１０１内には、本実施形態におけるオンライン系システムとして必要な機能を実装する為のプログラム１０２に加えて、オンラインＤＢ１１０およびバッチ処理キュー１２５が少なくとも記憶されている。このうちオンラインＤＢ１１０は、従来から存在するオンライン系システム１００におけるデータベースである。他方、バッチ処理キュー１２５については後述する。

また当然ながら、当該オンライン系システム１００は、勘定系システムを構成するオンライン系システムとして従来から実装されている機能についても備えるものとする。

また、図３は本実施形態のデータ利用系システム２００のハードウェア構成例を示す図である。データ利用系システム２００のハードウェア構成は以下の如くとなる。すなわちデータ利用系システム２００は、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）やハードディスクドライブなど適宜な不揮発性記憶素子で構成される記憶装置２０１、ＲＡＭなど揮発性記憶素子で構成されるメモリ２０３、記憶装置２０１に保持されるプログラム２０２をメモリ２０３に読み出すなどして実行し装置自体の統括制御を行なうとともに各種判定、演算及び制御処理を行なうＣＰＵなどの演算装置２０４、ネットワーク１と接続しオンライン系システム１００との通信処理を担う通信装置２０５、を備える。

なお、記憶装置２０１内には、本実施形態のデータ利用系システムとして必要な機能を実装する為のプログラム２０２に加えて、バッチＤＢ２１０およびバッチＤＢキュー２２
５が少なくとも記憶されている。このうちバッチＤＢ２１０は、従来から存在するデータ利用系システム２００たるバッチ系システムにおけるデータベースである。他方、バッチＤＢキュー２２５については後述する。

また当然ながら、データ利用系システム２００は、勘定系システムを構成するデータ利用系システムとして従来から実装されている機能についても備えるものとする。

−−−データ構造例−−−
次に、本実施形態のデータベース更新処理システム１０が用いるテーブル類におけるデータ構造例について説明する。上述のように、オンラインＤＢ１１０およびバッチＤＢ２１０については既存のデータベースと同じものであり、説明は省略する。

まずここでは、オンライン系システム１００が保持するバッチ処理キュー１２５について説明する。図４は本実施形態におけるバッチ処理キュー１２５の構造例を示す図である。このバッチ処理キュー１２５は、各オンライン系システムでのデータ更新対象の資源すなわちオンラインＤＢ１１０と、当該オンライン系システムでのデータ更新結果を利用するデータ利用系システム２００の資源すなわちバッチＤＢ２１０との対応関係を規定したテーブルとも言える。

こうしたバッチ処理キュー１２５は、上述のように資源間の対応関係を予め定めたテーブル構造を有すると共に、当該資源間の対応関係にマッチする更新情報を格納するキューである。バッチ処理キュー１２５は、記憶装置１０１またはメモリ１０３の適宜な記憶領域に構築されている。そのデータ構造は、オンライン系システム１００の資源名すなわちオンラインＤＢ名とデータ利用系システム２００の資源名すなわちバッチＤＢ名との対応関係をキーとして、更新対象の資源に関して当該対応関係にマッチする更新情報をエントリとして対応付けた構造を有している。各オンラインＤＢにデータ更新が複数次生じる場合、当該オンラインＤＢに関して、複数のエントリが格納されることになる。

また、バッチ処理キュー１２５に格納される更新情報は、処理系＃、データポインタ、自処理＃、データ更新の完了時刻、および他処理＃といった値を対応付けたものである。
このうち処理系＃は、トランザクションが実行されたオンライン系システム１００の識別情報である。

またデータポインタは、そのオンライン系システム１００のオンラインＤＢ１１０においてデータ更新（格納）がなされた記憶領域を示すポインタである。

また自処理＃は、当該トランザクションを実行したオンライン系システム１００における、各トランザクション間での完了順を示す値である。この自処理＃は、各トランザクションが完了するごとに当該オンライン系システム１００が値をインクリメントして付与する処理通番となる。

またデータ更新の完了時刻は、当該トランザクションの完了時刻である。

また他処理＃は、当該トランザクションの実行完了時点での、当該トランザクションを実行したオンライン系システム１００以外の他オンライン系システムにおける、直近に完了したトランザクションの完了順（すなわち実行順序としては最も遅いタイミングで実行されたトランザクションの順序）を示す値である。この他処理＃は、他オンライン系システムにおいて、各トランザクションが完了するごとに当該他オンライン系システムが値をインクリメントして付与する処理通番となる。

図５は本実施形態のバッチＤＢキュー２２５のデータ構成例を示す図である。本実施形態のデータ利用系システム２００が保持するバッチＤＢキュー２２５は、データ利用系システム２００がオンライン系システム１００から受信した更新要求を格納するキューであり、記憶装置２０１またはメモリ２０３の適宜な記憶領域に構築されている。

こうしたバッチＤＢキュー２２５は、上述のバッチ処理キュー１２５と同様に、資源間の対応関係を予め定めたテーブル構造を有すると共に、当該資源間の対応関係にマッチする更新要求を格納するキューである。そのデータ構造は、オンライン系システム１００の資源名すなわちオンラインＤＢ名とデータ利用系システム２００の資源名すなわちバッチＤＢ名との対応関係をキーとして、更新対象の資源に関して当該対応関係にマッチする更新要求が示す更新情報をエントリとして対応付けた構造を有している。このバッチＤＢキュー２２５におけるエントリの登録管理については後述する。

−−−機能−−−
続いて、本実施形態のデータベース更新処理システム１０が備える機能について説明する。上述したように、以下に説明する機能は、例えばデータベース更新処理システム１０を構成する、オンライン系システム１００およびデータ利用系システム２００がそれぞれ備えるプログラムを実行することで実装される機能と言える。

このうちオンライン系システム１００は、各オンライン系システム１００で実行されたトランザクションに関して、データ更新対象とされたオンラインＤＢ１１０、および自他それぞれのオンライン系システム１００でのトランザクション間のデータ更新完了順序、の各情報に基づき、各トランザクションによる当該オンラインＤＢ１１０に対するデータ更新事象の情報を生成し、当該生成した更新情報を、バッチ処理キュー１２５が規定するオンライン系システム１００の当該オンラインＤＢ１１０とデータ利用系システム２００のバッチＤＢ２１０とに対応付け、更新要求としてデータ利用系システム２００に送信する機能を備えている。

また、データ利用系システム２００は、上述のオンライン系システム１００から更新要求を受信して記憶装置２０１のバッチＤＢキュー２２５に格納し、各更新要求が示すデータ更新完了順序に基づいて、各トランザクションに関する更新情報を、上述の自他のオンライン系システム１００を跨がったデータ更新完了順序でソートし、当該ソート後の順序に応じて当該データ利用系システム２００の当該バッチＤＢ２１０に対する更新情報に基づくデータ更新処理を実行する機能を備えている。

また、データ利用系システム２００は、上述の更新処理の実行ごとに、当該実行対象の更新情報に関する、上述のソート後の順序の値を、バッチキュー引き出し可能番号として記憶装置２０１に格納する機能を備えている。

この場合、データ利用系システム２００は、上述の順序の値、すなわちバッチキュー引き出し可能番号の格納後に新たに更新処理を実行するに際し、各更新情報に関する、上述のソート後の順序の値と、記憶装置２０１に格納してある直近のバッチキュー引き出し可能番号の値とを照合して、上述のソート後の順序の値が直近のバッチキュー引き出し可能番号の値以上の更新情報を特定し、当該特定した更新情報に基づくデータ更新処理を実行する機能を備えている。

また、本実施形態のデータ利用系システム２００は、上述のオンライン系システム１００から更新要求を受信した際、オンライン系システム１００のオンラインＤＢ１１０と当該データ利用系システム２００のバッチＤＢ２１０との対応関係に関して共通する他の更新要求が、既に記憶装置２０１のバッチＤＢキュー２２５に格納されているか判定する機
能を備えている。

この場合、データ利用系システム２００は、上述の判定の結果、当該他の更新要求と今次受信した更新要求との間で、各更新要求が示すデータ更新完了順序に基づき、上述の自他のオンライン系システム１００を跨がったデータ更新完了順序の先後を判定し、当該判定の結果に応じて、上述の他の更新要求と今次受信した更新要求との先後関係を規定した上で記憶装置２０１のバッチＤＢキュー２２５に格納する機能を備えている。

また、データ利用系システム２００は、上述のソートに際し、記憶装置２０１のバッチＤＢキュー２２５が保持する各更新要求のうち、先後関係の共通する各更新要求が示すデータ更新完了順序に基づいて、各トランザクションに関する更新情報を、上述の自他のオンライン系システム１００を跨がったデータ更新完了順序でソートする機能を備えている。

この場合、データ利用系システム２００は、上述の更新処理の実行対象となった更新要求に関して、上述の先後関係において次位の更新要求を最先のものと記憶装置２０１のバッチＤＢキュー２２５にて規定する機能を備えている。

−−−フロー例１−−−
以下、本実施形態におけるデータベース更新処理方法の実際手順について図に基づき説明する。以下で説明するデータベース更新処理方法に対応する各種動作は、データベース更新処理システム１０がメモリ等に読み出して実行するプログラムによって実現される。そして、このプログラムは、以下に説明される各種の動作を行うためのコードから構成されている。

図６は、本実施形態におけるデータベース更新処理方法のフロー例１を示す図であり、図７は本実施形態における各オンライン系でのトランザクション実行例を示す図である。
ここでオンライン系システム１００は、オンラインＤＢ１１０における所定のオンライントランザクションによるデータ更新結果を示すオンラインＤＢ更新情報から、データ更新対象のオンラインＤＢ名および当該オンラインＤＢでの更新データを抽出し、当該抽出したオンラインＤＢ名をキーに、バッチ処理キュー１２５における更新情報の登録先を特定する（ｓ１００）。なお、上述のオンラインＤＢ更新情報は、オンライン系システム１００が所定のオンライントランザクションを実行し、オンラインＤＢ１１０に対するデータ更新を実行するごとに自身で保持する情報である。

例えば、或るオンライントランザクションに由来するオンラインＤＢ更新情報から抽出したオンラインＤＢ名「オンＤＢＡ」をキーに、バッチ処理キュー１２５（図４）のテーブル構造に対する検索を実行すると、更新情報の登録先として、オンラインＤＢ名「オンＤＢＡ」とバッチＤＢ名「バッチＤＢα」との対応関係が規定されたエントリ欄を特定することとなる。

次にオンライン系システム１００は、上述の或るオンライントランザクションの完了時点における、他のオンライン系システムでの処理通番を、当該他オンライン系システムに対して照会し取得する（ｓ１０１）。この処理通番は、各オンライン系システム１００が保持するカウンタで管理される値であり、当該オンライン系システム１００で１つのオンライントランザクションが完了する毎にインクリメントされる。なお、このステップｓ１０１の処理に際し、オンライン系システム１００は、自身のカウンタで管理している値についても取得する。

上述の或るオンライントランザクションが、例えば、「オンライン１系」なるオンライ
ン系システム１００で実行されたものであり、図７で例示するオンライントランザクションのうち「ＴＲ３」であったとする。この「ＴＲ３」は、「オンライン１系」で最初に完了したオンライントランザクションであり、オンライン系システム１００が自身のカウンタから取得する値は「１」となる。

この場合、当該「オンライン１系」なるオンライン系システム１００は、他方の「オンライン２系」なるオンライン系システムに対して、上述の「ＴＲ３」完了時におけるカウンタの値を照会し、取得することとなる。図７で示す例であれば、「オンライン２系」では「ＴＲ３」完了時点で、いずれのオンライントランザクションも完了していない。そのため「ＴＲ３」完了時における「オンライン２系」のカウンタの値は「０」となる。よって「オンライン１系」のオンライン系システム１００は、他オンライン系システムでの処理通番として「０」を取得する。

続いてオンライン系システム１００は、上述の「ＴＲ３」なるオンライントランザクションの実行結果である、オンラインＤＢ更新情報から、データ利用系システム２００のバッチＤＢ２１０に反映させるべき更新情報として、エントリ欄の各項目に対応した情報を抽出する（ｓ１０２）。ここで抽出する情報とは、データポインタ、およびデータ更新の完了時刻、および他処理＃といった値になる。

次にオンライン系システム１００は、上述のまでの処理で例えば上述の「ＴＲ３」に関して得た、当該オンライントランザクションの完了時点における自他のオンライン系システムでの処理通番、データポインタ、および完了時刻、の各情報を、処理系＃「オンライン１系」の値と共に、キューエントリの雛形に設定して更新要求を生成する（ｓ１０３）。

続いてオンライン系システム１００は、上述のステップｓ１０３で生成した更新要求を、エントリとしてバッチ処理キュー１２５における、該当エントリ欄（ステップｓ１００で特定したもの）に格納する（ｓ１０４）。

次にオンライン系システム１００は、バッチ処理キュー１２５に格納した更新要求を、データ利用系システム２００に送信し（ｓ１０５）、当該フローを終了する。ここで送信する更新要求は、上述のエントリと、オンライン資源名たるオンラインＤＢ名およびデータ利用系システム２００の資源名たるバッチＤＢ名とを含んでいる。

なお、この送信処理の実行契機は、例えばオンライン系システム１００が情報処理装置として一般的に備えるタイマ機能により感知される一定時間経過のタイミングを想定出来る。

−−−フロー例２−−−
次に、データ利用系システム２００が上述のオンライン系システム１００から更新要求を受信した際の処理について説明する。図８は、本実施形態におけるデータベース更新処理方法のフロー例２を示す図である。

この場合、データ利用系システム２００は、上述のオンライン系システム１００から更新要求を受信し（ｓ２００）、当該更新要求が示すキー情報からバッチＤＢキュー２２５における登録先を特定する（ｓ２０１）。このキー情報とは、上述のオンライン系システム１００でデータ更新がなされたオンラインＤＢ１１０の名と、当該データ利用系システム２００のバッチＤＢ２１０の名のセットである。

例えば、図９に示す更新要求９００が示すキーとして、オンラインＤＢ名「オンＤＢＢ
」とバッチＤＢ名「バッチＤＢα」をキーに、バッチＤＢキュー２２５（図５）に対する検索を実行すると、更新要求の登録先として、オンラインＤＢ名「オンＤＢＢ」とバッチＤＢ名「バッチＤＢα」との対応関係が規定されたエントリ欄１０００（図１０）を特定することとなる。

続いてデータ利用系システム２００は、上述のステップｓ２０１で特定したバッチＤＢキュー２２５のエントリ欄１０００より、当該エントリ欄１０００に登録されている最後尾のエントリレコードの所定情報を取得する（ｓ２０２）。図１０の例であれば、「エントリ２」から、処理系＃「オンライン１系」、自処理通番「０００００２」、他処理通番「０００００５」、完了時刻「０：００：０３’０００」、およびデータポインタ「ＤＰ−ＸＸ」、といった情報を取得することになる。

次にデータ利用系システム２００は、上述のステップｓ２００で受信した更新要求が示す自処理通番と処理通番の合計値と、ステップｓ２０２取得した自処理通番と他処理通番の合計値とを比較する（ｓ２０３）。

図１１は本実施形態における処理通番の比較概念を示す図である。ここで例示するように、例えば、ｓ２００で受信した更新要求における自処理通番「０００００５」と他処理通番「０００００１」を合計して合計値「０００００６」を得たとする。また、ｓ２０２で得た最後尾のエントリレコードにおける自処理通番「０００００２」と他処理通番「０００００５」を合計して合計値「０００００７」を得たとする。

データ利用系システム２００は、これらを比較すると、今次受信した更新要求の処理通番合計「０００００６」が、最後尾のエントリレコードの処理通番合計「０００００７」より小さいと判定出来る（ｓ２０３：ｙ）。

データ利用系システム２００は、このような比較により、上述の合計値が小さいほうがオンライン系システム１００で先に処理されているものであり、データ利用系システム２００にて先に処理されるべきデータであると特定する（ｓ２０４）。

このように、ステップｓ２００で受信した更新要求が、バッチＤＢキュー２２５における既存の最後尾のエントリより先に処理されるべきデータであると特定した場合、データ利用系システム２００は、バッチＤＢキュー２２５における最後尾のエントリを、現在のエントリ欄における位置より１つ後ろのエントリにシフトする（ｓ２０５）。

図１２に本実施形態におけるエントリシフトの概念を示す。図１２の例では、バッチＤＢキュー２２５において、オンラインＤＢ名「オンＤＢＢ」とバッチＤＢ名「バッチＤＢα」をキーにしたエントリ欄１０００のうち最後尾の「エントリ３」に格納されていた、処理系＃「オンライン１系」、自処理通番「０００００２」、他処理通番「０００００５」、完了時刻「０：００：０３’０００」、およびデータポインタ「ＤＰ−ＸＸ」、といった情報を含むエントリを、エントリ欄１０００のうち「エントリ２」にシフトしている。

続いてデータ利用系システム２００は、上述のエントリシフトにより空欄となったエントリ「エントリ２」より１つ前に登録されているエントリレコード「エントリ１」の所定情報を取得する（ｓ２０６）。図１２の例であれば、「エントリ１」から、処理系＃「オンライン１系」、自処理通番「０００００１」、他処理通番「０００００３」、完了時刻「０：００：０３’０００」、およびデータポインタ「ＤＰ−ＸＸ」、といった情報を取得することになる。

次にデータ利用系システム２００は、上述のステップｓ２００で受信した更新要求が示す自処理通番と処理通番の合計値と、ステップｓ２０６で取得した自処理通番と他処理通番の合計値とを比較する（ｓ２０７）。

図１２のバッチＤＢキュー２２５の例であれば、ｓ２００で受信した更新要求における自処理通番「０００００５」と他処理通番「０００００１」の合計値「０００００６」と、ｓ２０６で得た上述の１つ前のエントリレコードにおける自処理通番「０００００１」と他処理通番「０００００３」の合計値「０００００４」を比較すると、今次受信した更新要求の処理通番合計「０００００６」が、１つ前のエントリレコードの処理通番合計「０００００４」より大きいと判定出来る（ｓ２０７：ｙ）。

データ利用系システム２００は、このような比較により、上述の合計値が小さいほうがオンライン系システム１００で先に処理されているものであり、データ利用系システム２００にて先に処理されるべきデータであると特定する。

データ利用系システム２００は、このように、ステップｓ２００で受信した更新要求が、バッチＤＢキュー２２５における１つ前のエントリより後に処理されるべきデータであると特定した場合、ｓ２００で受信した更新要求を、上述のエントリシフトによってバッチＤＢキュー２２５にて空欄となっている「エントリ２」に格納し（ｓ２０８）、処理を終了する。

他方、上述の比較により、今次受信した更新要求の処理通番合計が、上述の１つ前のエントリレコードの処理通番合計より小さいものであった場合（ｓ２０７：ｎ）、データ利用系システム２００は、更に１つ前のエントリレコードから所定情報を取得して、ステップｓ２０７以降と同様の処理を実行する（ｓ２０９）。

また、上述のステップｓ２０３において、比較の結果、今次受信した更新要求の処理通番合計が、最後尾のエントリレコードの処理通番合計以上と判定出来た場合（ｓ２０３：ｎ）、データ利用系システム２００は、最後尾のエントリより、今次受信した更新要求がオンライン系システム１００で後に処理されているものであり、データ利用系システム２００にて後に処理されるべきデータであると特定する（ｓ２１０）。

この場合、データ利用系システム２００は、ステップｓ２００で受信した更新要求を、バッチＤＢキュー２２５のエントリ欄における最後尾のエントリとして登録し（ｓ２１１）、処理を終了する。

このようにデータ利用系システム２００は、上述のステップｓ２０２〜ｓ２１１を適宜繰り返すことで、ステップｓ２００で受信した更新要求の格納位置を、バッチＤＢキュー２２５におけるエントリ欄１０００にて特定し、当該更新要求の格納を実行することとなる。

−−−フロー例３−−−
次に、データ利用系システム２００が更新要求に基づいてバッチＤＢ２１０でのデータ更新を実行する処理について図に基づき説明する。図１３は、本実施形態におけるデータベース更新処理方法のフロー例３を示す図である。

データ利用系システム２００は、バッチＤＢキュー２２５が保持する各更新要求のうち、先後関係の共通する、すなわちエントリ欄１０００で同じ列にある各エントリレコードから、自処理通番および他処理通番の各値を取得する（ｓ３００）。

次にデータ利用系システム２００は、上述のステップｓ３００で得た各エントリレコードの自処理通番および他処理通番の各値をそれぞれ合算し、その値の小さい順で各エントリレコードをソートする（ｓ３０１）。

図１４で示す例では、バッチＤＢキュー２２５において先頭エントリ「エントリ１」の全エントリレコードを読み取り、各エントリレコードから自処理通番および他処理通番の合算値を求めた結果、「バッチＤＢα」に関して合算値「０００００７」、「バッチＤＢβ」に関して合算値「０００００８」、「バッチＤＢγ」に関して合算値「０００００５」、「バッチＤＢδ」に関して合算値「０００００８」、の各値を得られている。また、この合算値の小さい順にエントリレコードをソートした結果、「バッチＤＢγ」、「バッチＤＢα」、「バッチＤＢβ」、「バッチＤＢδ」の順となった。

次にデータ利用系システム２００は、上述のソートの結果、先頭となった、すなわち最も早く処理すべきエントリレコード（更新要求）に関する上述の合算値を、既に述べたバッチキュー引き出し可能番号と比較する（ｓ３０２）。

上述の比較の結果、当該エントリレコードに関する上述の合算値が、バッチキュー引き出し可能番号の値に１を加算した値と同じであれば（ｓ３０２：ｙ）、データ利用系システム２００は、当該エントリレコードに基づき、当該バッチＤＢ２１０に対するデータ更新処理を実行する（ｓ３０３）。他方、当該エントリレコードに関する上述の合算値が、バッチキュー引き出し可能番号の値に１を加算した値と異なれば（ｓ３０２：ｎ）、データ利用系システム２００は、例えば所定時間待機して処理をｓ３００に戻す。

また、データ利用系システム２００は、上述のデータ更新処理に伴い、バッチＤＢキュー２２５から該当エントリレコードを削除し、それまで次位のエントリ「エントリ２」のエントリレコードを、「エントリ１」にシフトする（ｓ３０４）。

図１５に示す例では、バッチＤＢキュー２２５において「バッチＤＢγ」の「エントリ１」に基づくデータ更新処理の実行に伴い、「エントリ２」であるエントリレコードを、「エントリ１」にシフトする状況を示す。

また、データ利用系システム２００は、バッチキュー引き出し可能番号を、上述のステップｓ３０３でデータ更新処理の対象としたエントリレコードの自処理通番および他処理通番の合計値に置換し（ｓ３０５）、処理を終了する。

こうしたステップｓ３０２〜ｓ３０５の処理は、上述のステップｓ３０２の比較処理で、上述の合算値が、バッチキュー引き出し可能番号の値に１を加算した値と同じエントリレコードが、ソート後のエントリレコードから特定出来る限り、繰り返し実行される。

以上、本発明を実施するための最良の形態などについて具体的に説明したが、本発明はこれに限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能である。

こうした本実施形態によれば、勘定系システムにおけるオンライン系の処理結果をバッチ系（情報系たるサブシステムの概念含む）にリアルタイムに反映することが可能となる。こうした反映がなされるバッチ系ないしサブシステムを利用する金融機関の営業担当者等は、顧客の金融資産の増減動向等を迅速に認識して営業活動を行うことが可能となる。換言すれば、営業機会損失のリスクを抑制することが出来る。

また、勘定系システムにおけるＣＰＵのサイジングは夜間バッチ処理での必要性能を基点に設計されているため、本実施形態のデータベース更新処理技術を採用することで、情
報系還元処理の削減に伴うスペックダウンを図ることが可能となる。このことは、勘定系システムの導入、運用等に関するコスト削減効果につながる。

本明細書の記載により、少なくとも次のことが明らかにされる。すなわち、本実施形態のデータベース更新処理システムにおいて、前記オンライン系システムから前記更新要求を受信して記憶装置に格納し、各更新要求が示す前記データ更新完了順序に基づいて、各トランザクションに関する更新情報を、前記自他のオンライン系システムを跨がったデータ更新完了順序でソートし、当該ソート後の順序に応じて当該データ利用系システムの当該資源に対する前記更新情報に基づくデータ更新処理を実行する演算装置を備えたデータ利用系システムを更に含むとしてもよい。

これによれば、データ利用系システムにおける各資源間でのデータ更新順についても考慮したデータ更新を行うことが可能となる。

また、本実施形態のデータベース更新処理システムにおいて、前記データ利用系システムの前記演算装置は、前記更新処理の実行ごとに、当該実行対象の更新情報に関する、前記ソート後の順序の値を記憶装置に格納する処理を更に実行し、前記順序の値の格納後に新たに更新処理を実行するに際し、各更新情報に関する前記ソート後の順序の値と、前記記憶装置に格納してある直近の前記順序の値とを照合して、前記ソート後の順序の値が前記直近の前記順序の値以上の更新情報を特定し、当該特定した更新情報に基づくデータ更新処理を実行するものである、としてもよい。

これによれば、何らかの理由で遅延しているトランザクションに対応した更新要求等の受信を待って、正確な更新順序での齟齬の無いデータ更新処理が可能となる。

また、本実施形態のデータベース更新処理システムにおいて、前記データ利用系システムの前記演算装置は、前記オンライン系システムから前記更新要求を受信した際、オンライン系システムの資源と当該データ利用系システムの資源との対応関係に関して共通する他の更新要求が既に記憶装置に格納されていた場合、当該他の更新要求と前記受信した更新要求との間で、各更新要求が示す前記データ更新完了順序に基づき、前記自他のオンライン系システムを跨がったデータ更新完了順序の先後を判定し、当該判定の結果に応じて、前記他の更新要求と前記受信した更新要求との先後関係を規定して記憶装置に格納し、前記ソートに際し、記憶装置の各更新要求のうち、前記先後関係の共通する各更新要求が示す前記データ更新完了順序に基づいて、各トランザクションに関する更新情報を、前記自他のオンライン系システムを跨がったデータ更新完了順序でソートし、前記更新処理の実行対象となった更新要求に関して、前記先後関係において次位の更新要求を最先のものと記憶装置にて規定する処理を更に実行するものである、としてもよい。

これによれば、更新要求を受けるごとにトランザクション間での先後の関係をあらためて判定し、この先後関係に基づいた齟齬の無いデータ更新処理が可能となる。

また、本実施形態のデータベース更新処理方法において、前記データ利用系システムが、前記オンライン系システムから前記更新要求を受信して記憶装置に格納し、各更新要求が示す前記データ更新完了順序に基づいて、各トランザクションに関する更新情報を、前記自他のオンライン系システムを跨がったデータ更新完了順序でソートし、当該ソート後の順序に応じて当該データ利用系システムの当該資源に対する前記更新情報に基づくデータ更新処理を実行するとしてもよい。

また、本実施形態のデータベース更新処理方法において、前記データ利用系システムが、前記更新処理の実行ごとに、当該実行対象の更新情報に関する、前記ソート後の順序の
値を記憶装置に格納する処理を更に実行し、前記順序の値の格納後に新たに更新処理を実行するに際し、各更新情報に関する前記ソート後の順序の値と、前記記憶装置に格納してある直近の前記順序の値とを照合して、前記ソート後の順序の値が前記直近の前記順序の値以上の更新情報を特定し、当該特定した更新情報に基づくデータ更新処理を実行するとしてもよい。

また、本実施形態のデータベース更新処理方法において、前記データ利用系システムが、前記オンライン系システムから前記更新要求を受信した際、オンライン系システムの資源と当該データ利用系システムの資源との対応関係に関して共通する他の更新要求が既に記憶装置に格納されていた場合、当該他の更新要求と前記受信した更新要求との間で、各更新要求が示す前記データ更新完了順序に基づき、前記自他のオンライン系システムを跨がったデータ更新完了順序の先後を判定し、当該判定の結果に応じて、前記他の更新要求と前記受信した更新要求との先後関係を規定して記憶装置に格納し、前記ソートに際し、記憶装置の各更新要求のうち、前記先後関係の共通する各更新要求が示す前記データ更新完了順序に基づいて、各トランザクションに関する更新情報を、前記自他のオンライン系システムを跨がったデータ更新完了順序でソートし、前記更新処理の実行対象となった更新要求に関して、前記先後関係において次位の更新要求を最先のものと記憶装置にて規定する処理を更に実行する、としてもよい。

１ ネットワーク
１０ データベース更新処理システム
１００ オンライン系システム
１０１ 記憶装置
１０２ プログラム
１０３ メモリ
１０４ 演算装置
１０５ 通信装置
１１０ オンラインＤＢ
１２５ バッチ処理キュー
２００ データ利用系システム
２０１ 記憶装置
２０２ プログラム
２０３ メモリ
２０４ 演算装置
２０５ 通信装置
２１０ バッチＤＢ
２２５ バッチＤＢキュー

Claims (8)

1. 所定のオンライン系システムでのデータ更新対象の資源と、当該オンライン系システムでのデータ更新結果を利用するデータ利用系システムの資源との対応関係を規定したテーブルを保持する記憶装置と、
   各オンライン系システムで実行されたトランザクションに関して、データ更新対象とされた資源、および自他それぞれのオンライン系システムでのトランザクション間のデータ更新完了順序、の各情報に基づき、各トランザクションによる当該資源に対するデータ更新事象の情報を生成し、当該生成した更新情報を、前記テーブルが規定するオンライン系システムの当該資源とデータ利用系システムの資源とに対応付け、更新要求として前記データ利用系システムに送信する演算装置と、
   を備えたオンライン系システムを含むことを特徴とするデータベース更新処理システム。
2. 前記オンライン系システムから前記更新要求を受信して記憶装置に格納し、各更新要求が示す前記データ更新完了順序に基づいて、各トランザクションに関する更新情報を、前記自他のオンライン系システムを跨がったデータ更新完了順序でソートし、当該ソート後の順序に応じて当該データ利用系システムの当該資源に対する前記更新情報に基づくデータ更新処理を実行する演算装置を備えたデータ利用系システムを更に含むことを特徴とする請求項１に記載のデータベース更新処理システム。
3. 前記データ利用系システムの前記演算装置は、
   前記更新処理の実行ごとに、当該実行対象の更新情報に関する、前記ソート後の順序の値を記憶装置に格納する処理を更に実行し、
   前記順序の値の格納後に新たに更新処理を実行するに際し、各更新情報に関する前記ソート後の順序の値と、前記記憶装置に格納してある直近の前記順序の値とを照合して、前記ソート後の順序の値が前記直近の前記順序の値以上の更新情報を特定し、当該特定した更新情報に基づくデータ更新処理を実行するものである、
   ことを特徴とする請求項２に記載のデータベース更新処理システム。
4. 前記データ利用系システムの前記演算装置は、
   前記オンライン系システムから前記更新要求を受信した際、オンライン系システムの資源と当該データ利用系システムの資源との対応関係に関して共通する他の更新要求が既に記憶装置に格納されていた場合、当該他の更新要求と前記受信した更新要求との間で、各更新要求が示す前記データ更新完了順序に基づき、前記自他のオンライン系システムを跨がったデータ更新完了順序の先後を判定し、当該判定の結果に応じて、前記他の更新要求と前記受信した更新要求との先後関係を規定して記憶装置に格納し、
   前記ソートに際し、記憶装置の各更新要求のうち、前記先後関係の共通する各更新要求が示す前記データ更新完了順序に基づいて、各トランザクションに関する更新情報を、前記自他のオンライン系システムを跨がったデータ更新完了順序でソートし、
   前記更新処理の実行対象となった更新要求に関して、前記先後関係において次位の更新要求を最先のものと記憶装置にて規定する処理を更に実行するものである、
   ことを特徴とする請求項２に記載のデータベース更新処理システム。
5. 所定のオンライン系システムでのデータ更新対象の資源と、当該オンライン系システムでのデータ更新結果を利用するデータ利用系システムの資源との対応関係を規定したテーブルを保持する記憶装置を備えたオンライン系システムが、
   各オンライン系システムで実行されたトランザクションに関して、データ更新対象とされた資源、および自他それぞれのオンライン系システムでのトランザクション間のデータ更新完了順序、の各情報に基づき、各トランザクションによる当該資源に対するデータ更
   新事象の情報を生成し、当該生成した更新情報を、前記テーブルが規定するオンライン系システムの当該資源とデータ利用系システムの資源とに対応付け、更新要求として前記データ利用系システムに送信する、
   ことを特徴とするデータベース更新処理方法。
6. 前記データ利用系システムが、
   前記オンライン系システムから前記更新要求を受信して記憶装置に格納し、各更新要求が示す前記データ更新完了順序に基づいて、各トランザクションに関する更新情報を、前記自他のオンライン系システムを跨がったデータ更新完了順序でソートし、当該ソート後の順序に応じて当該データ利用系システムの当該資源に対する前記更新情報に基づくデータ更新処理を実行する、
   ことを特徴とする請求項５に記載のデータベース更新処理方法。
7. 前記データ利用系システムが、
   前記更新処理の実行ごとに、当該実行対象の更新情報に関する、前記ソート後の順序の値を記憶装置に格納する処理を更に実行し、
   前記順序の値の格納後に新たに更新処理を実行するに際し、各更新情報に関する前記ソート後の順序の値と、前記記憶装置に格納してある直近の前記順序の値とを照合して、前記ソート後の順序の値が前記直近の前記順序の値以上の更新情報を特定し、当該特定した更新情報に基づくデータ更新処理を実行する、
   ことを特徴とする請求項６に記載のデータベース更新処理方法。
8. 前記データ利用系システムが、
   前記オンライン系システムから前記更新要求を受信した際、オンライン系システムの資源と当該データ利用系システムの資源との対応関係に関して共通する他の更新要求が既に記憶装置に格納されていた場合、当該他の更新要求と前記受信した更新要求との間で、各更新要求が示す前記データ更新完了順序に基づき、前記自他のオンライン系システムを跨がったデータ更新完了順序の先後を判定し、当該判定の結果に応じて、前記他の更新要求と前記受信した更新要求との先後関係を規定して記憶装置に格納し、
   前記ソートに際し、記憶装置の各更新要求のうち、前記先後関係の共通する各更新要求が示す前記データ更新完了順序に基づいて、各トランザクションに関する更新情報を、前記自他のオンライン系システムを跨がったデータ更新完了順序でソートし、
   前記更新処理の実行対象となった更新要求に関して、前記先後関係において次位の更新要求を最先のものと記憶装置にて規定する処理を更に実行する、
   ことを特徴とする請求項６に記載のデータベース更新処理方法。

Images