ＤＢＭＳに格納されたデータの整合性を担保するためのシステム
【課題】 ２フェーズコミットメント機能を有しないＤＢＭＳを利用した場合でも、データの整合性を担保する。
【解決手段】 インタフェースサーバ１がリクエスト要求元からのリクエストを受け付けて、このリクエストにリクエストＩＤを付与する。業務処理サーバ３は、このクエストに基づいてＤＢＭＳ５に複数の更新処理を依頼した場合、このリクエストに付与された識別情報と関連づけられた各更新処理の内容に関するテーブル更新情報５５を、ＤＢＭＳ５から取得する。さらに、業務処理サーバ３は、ＤＢＭＳ５に依頼したすべての更新処理の処理結果に基づいて、リクエストの成否を判定する。インタフェースサーバ１は、リクエスト成否とテーブル更新情報５５とを、リクエストＩＤで関連づけてトランザクションジャーナル１３へ記憶する。
【解決手段】 インタフェースサーバ１がリクエスト要求元からのリクエストを受け付けて、このリクエストにリクエストＩＤを付与する。業務処理サーバ３は、このクエストに基づいてＤＢＭＳ５に複数の更新処理を依頼した場合、このリクエストに付与された識別情報と関連づけられた各更新処理の内容に関するテーブル更新情報５５を、ＤＢＭＳ５から取得する。さらに、業務処理サーバ３は、ＤＢＭＳ５に依頼したすべての更新処理の処理結果に基づいて、リクエストの成否を判定する。インタフェースサーバ１は、リクエスト成否とテーブル更新情報５５とを、リクエストＩＤで関連づけてトランザクションジャーナル１３へ記憶する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＤＢＭＳ（Database Management System）を利用するシステムにおいて、ＤＢＭＳに格納された複数のテーブル間のデータの整合性を担保するための技術に関する。
【背景技術】
【０００２】
近年、誰でもが自由に利用できるようにするため、ソフトウェアのソースコードをオープンソースとして、インターネットなどを通じて無償で公開することが行われている。そして、オープンソースのソフトウェアを利用すれば、低コストでアプリケーションシステムの構築が可能となることから、企業なども徐々に利用し始めている。
【発明の開示】
【発明が解決しようとする課題】
【０００３】
ＤＢＭＳ（Database Management System；データベース管理システム）もオープンソースとして公開されているものがある。オープンソースのＤＢＭＳの場合、２フェーズコミットメントなどのような高度な機能が実装されていないものがある。このようなＤＢＭＳが利用された場合、データの整合性を担保するためには２フェーズコミットメントを行うべきときであっても、それが行われないことになる。そうなると、データの不整合が生じ、このデータを利用するアプリケーションシステムにおいて不都合が生じる。
【０００４】
そこで、本発明の目的は、２フェーズコミットメント機能を有しないＤＢＭＳを利用した場合でも、データの整合性を担保するための技術を提供することである。
【課題を解決するための手段】
【０００５】
本発明の一実施態様に従うＤＢＭＳ（Database Management System）と接続され、前記ＤＢＭＳに格納されたデータの整合性を担保するためのシステムは、リクエスト要求元からのリクエストを受け付けると、前記リクエストに識別情報を付与する手段と、前記ＤＢＭＳに対して、前記リクエストに基づくデータの更新処理を依頼する更新手段と、前記更新手段が前記リクエストに基づいて前記ＤＢＭＳに複数の更新処理を依頼した場合、前記リクエストに付与された識別情報と関連づけられた各更新処理の内容に関する更新情報を、前記ＤＢＭＳから取得する更新情報取得手段と、前記更新手段が前記ＤＢＭＳに依頼したすべての更新処理の処理結果に基づいて、前記リクエストの成否を判定するリクエスト成否判定手段と、前記リクエスト成否判定手段による判定結果と前記更新情報取得手段により取得した更新情報とを、前記リクエストに付与された識別情報で関連づけて記憶する記憶手段と、前記リクエスト成否判定手段による判定結果を、前記リクエスト要求元に対して出力する手段と、を備える。
【０００６】
好適な実施形態では、前記更新情報は、前記更新手段が依頼した更新処理別になっていて、各更新処理が正常終了したときに、当該更新処理に関する更新情報が前記ＤＢＭＳによって生成されてもよい。
【０００７】
好適な実施形態では、リクエスト成否判定手段は、前記更新手段が依頼したすべての更新処理が正常終了したときはリクエスト成功と判定し、前記更新手段が依頼した更新処理のいずれか一つ以上が正常終了でないときはリクエスト不成功と判定するようにしてもよい。
【０００８】
好適な実施形態では、前記記憶手段に、ある識別情報が付与されているリクエストの判定結果がリクエスト不成功と記憶されていて、かつ、前記更新情報取得手段が取得した、当該識別情報に係る一部の前記更新情報が記憶されているときは、前記ＤＢＭＳに格納された複数のテーブル間で不整合が生じていると判定する整合性判定手段を、さらに備えてもよい。
【発明を実施するための最良の形態】
【０００９】
本発明の一実施形態に係る、２フェーズコミットメントがサポートされていないＤＢＭＳを利用したトランザクション処理を行うシステムについて、図面を用いて説明する。
【００１０】
図１は、本実施形態に係るトランザクション処理システム１０とその監視装置２０の構成を示す図である。トランザクション処理システム１０は、外部とのデータ入出力を行うインタフェースサーバ１と、所定の業務処理を行う業務処理サーバ３と、ＤＢＭＳ５とを備える。監視装置２０は、例えば、インタフェースサーバ１と接続されている。
【００１１】
本実施形態では、ＤＢＭＳ５が在庫マスタを有し、業務処理サーバ３が商品の発注、在庫管理等を行っているときに、インタフェースサーバ１が商品の発注をリクエストするトランザクションを受け付けたときの処理を例にとって説明する。
【００１２】
インタフェースサーバ１、業務処理サーバ３、ＤＢＭＳ５および監視装置２０は、いずれも例えば汎用的なコンピュータシステムにより構成され、以下に説明する各サーバ等１，３，５、２０内の個々の構成要素または機能は、例えば、コンピュータプログラムを実行することにより実現される。
【００１３】
インタフェースサーバ１は、リクエスト要求元の装置からのリクエストをトランザクションとして受け付け、このリクエストが正常終了したか否かを示すリクエスト成否をリクエスト要求元へ返信する。また、インタフェースサーバ１は、内部の機能として、受け付けたトランザクションに含まれるリクエストに識別情報であるＩＤを付与するリクエストＩＤ付与部１１と、トランザクションの処理履歴を記録するトランザクションジャーナル１３とを有する。
【００１４】
リクエストＩＤ付与部１１は、トランザクション処理システム１０内でユニークなリクエストＩＤを、各トランザクションに係るリクエストに対して付与し、業務処理サーバ３へ送る。
【００１５】
トランザクションジャーナル１３には、各トランザクションに係るリクエストごとに、その処理結果などの情報が格納される。例えば、業務処理サーバ３から返信されたリクエストに対するリプライが、トランザクションジャーナル１３に格納される。
【００１６】
図２には、トランザクションジャーナル１３のデータ構造の一例を示す。トランザクションジャーナル１３は、データ項目として、リクエストＩＤ２１と、リクエスト成否２２と、在庫マスタテーブルのテーブル更新情報２３と、トランザクションテーブルのテーブル更新情報２４とを有する。リクエスト成否２２，及びテーブル更新情報２３，２４については後述する。
【００１７】
再び図１を参照すると、ＤＢＭＳ５は、それぞれデータが格納されている種々のテーブル５１，５３と、テーブル更新情報５５とが記憶されている。テーブル更新情報５５には、各テーブルの更新（上書き及び挿入）が行われたときに、その更新内容などが格納される。テーブル更新情報５５は、テーブル別になっている。
【００１８】
テーブル更新情報５５のデータ構造を図３に示す。テーブル更新情報５５は、テーブル名４１と、上書き／挿入種別４２と、更新の主キー４３と、更新前情報４４と、更新後情報４５と、リクエストＩＤ４６とをデータ項目として有する。テーブル更新情報５５は、各テーブルの更新処理が完了した時点で、その更新処理に係るレコードが追加される。従って、ＤＢＭＳ５が業務処理サーバ３からデータの更新依頼を受けた場合でも、その更新が正常終了しなければ、その更新処理に係るレコードが生成されない。この結果、リクエストＩＤ４６をキーにしてテーブル更新情報５５を参照することにより、各更新処理の成否を判定することができる。
【００１９】
図１の例では、ＤＢＭＳ５は、在庫マスタテーブル５１とトランザクションテーブル５３とを有している。そして、テーブル更新情報５５には、在庫マスタテーブルの更新情報５５１とトランザクションテーブルの更新情報５５２とが格納される。
【００２０】
業務処理サーバ３は、トランザクション制御を行うトランザクション制御部３１と、複数の個別処理３３１，３３２を有する業務処理部３３とを備える。ここで、個別処理には在庫処理３３１と、注文処理３３２とがある。
【００２１】
トランザクション制御部３１は、インタフェースサーバ１から通知されたトランザクションを受け付けて、そのトランザクションに含まれるリクエストに応じた個別処理を業務処理部３３から選択して実行させる。そして、トランザクション制御部３１は、業務処理部３３の個別処理の結果に応じて、リクエストに対する処理が正常に終了したか否か（リクエスト成否）を判定する。さらに、リクエストＩＤをキーにしてＤＢＭＳ５からテーブル更新情報５５を取得して、リクエスト成否とともにトランザクションに対するリプライとしてインタフェースサーバ１へ返信する。
【００２２】
業務処理部３３の各個別処理は、それぞれ所定の業務処理を実行する。さらに、各個別処理は、ＤＢＭＳ５内の各テーブルの参照、更新の際は、ＤＢＭＳ５に対して処理を依頼する。ＤＢＭＳ５へ処理を依頼するときは、リクエストＩＤもあわせて通知する。
【００２３】
例えば、インタフェースサーバ１から商品発注リクエストのトランザクションが通知されると、トランザクション制御部３１は、在庫処理３３１と注文処理３３２を順次呼び出してそれぞれの処理を実行させる。ここで、在庫処理３３１としては、在庫引き当て、在庫マスタテーブル５１の更新等を行う。在庫マスタテーブル５１の更新は、ＤＢＭＳ５に対して処理を依頼する。注文処理３３２としては、例えば、商品発注に対する注文ＩＤを採番し、トランザクションテーブル５３への注文情報の格納を、ＤＢＭＳ５に対して依頼する。
【００２４】
次に、図４のフローチャートを用いて、商品発注のトランザクション処理について説明する。
【００２５】
まず、インタフェースサーバ１が商品発注リクエストを含むトランザクションを受け付けると、リクエストＩＤ付与部１１が、そのトランザクションにリクエストＩＤを付与する（Ｓ１１）。そして、リクエストＩＤが付与されたトランザクションは、業務処理サーバ３へ通知される。
【００２６】
業務処理サーバ３では、トランザクション制御部３１がトランザクションを受け付けると、そのトランザクションに応じた、業務処理部３３の個別処理３３１，３３２を順次実行させる（Ｓ１２）。ここで実行される各個別処理の中で、ＤＢＭＳ５内のテーブルを更新するときは、ＤＢＭＳ５に対してテーブルの更新を依頼する（Ｓ１３）。このテーブルの更新依頼には、受け付けたトランザクションに付与されているリクエストＩＤが付されている。
【００２７】
本実施形態では、トランザクション制御部３１は、商品発注のトランザクションに対して、まず在庫処理３３１を実行させる。在庫処理３３１では、在庫引き当て処理を行った後、ＤＢＭＳ５に在庫マスタテーブル５１の更新要求を出力する。
【００２８】
ＤＢＭＳ５がテーブル更新の依頼を受けると、それに応じてテーブルの更新を行う（Ｓ１４）。そして、このテーブルの更新が成功すると、ＤＢＭＳ５がこのテーブルの更新に基づいてテーブル更新情報５５（図３参照）を格納する（Ｓ１５）。
【００２９】
本実施形態では、ＤＢＭＳ５は、在庫マスタテーブル５１を更新するとともに、在庫マスタのテーブル更新情報５５１に、その更新に係る情報を格納する。
【００３０】
ＤＢＭＳ５での処理が終了すると、トランザクション制御部３１へ個別処理が正常終了したか否かを示す処理結果が通知され、これにより個別処理が終了する（Ｓ１６）。トランザクション制御部３１は、他にも行うべき個別処理があるか否かを判定し、すべての個別業務処理を上記ステップＳ１２〜Ｓ１６に従って実行させる（Ｓ１７）。
【００３１】
本実施形態では、上述の在庫処理３３１が終了すると、トランザクション制御部３１がこれに続いて注文処理３３２を実行させる。つまり、注文処理３３２について、ステップＳ１２以降の処理が再び実行される。注文処理３３２では、注文ＩＤを採番して、ＤＢＭＳ５にトランザクションテーブル５３の更新要求を出力する。ＤＢＭＳ５は、トランザクションテーブル５３を更新するとともに、トランザクションテーブルのテーブル更新情報５５２に、その更新に係る情報を格納する。そして、これらの処理結果をトランザクション制御部３１へ通知して処理を終了する。
【００３２】
すべての個別処理が終了すると（Ｓ１７：Ｙｅｓ）、トランザクション制御部３１は、リクエストの成否を判定する（Ｓ１８）。すなわち、このトランザクションに基づいて処理を行った個別処理のすべてが正常終了していればトランザクションは成功であり、個別処理のいずれか一つでも正常終了でなければ、トランザクションは不成功（エラー）である。個別処理の成否判定は、ＤＢＭＳ５から通知される処理結果に基づいて行われる。さらに、トランザクション制御部３１は、ＤＢＭＳ５からテーブル更新情報５５を取得し、ここで取得したテーブル更新情報５５と、リクエスト成否及びリクエストＩＤとを含むリプライを、インタフェースサーバ１へ返信する。
【００３３】
本実施形態では、トランザクション制御部３１は、在庫処理３３１及び注文処理３３２のいずれもが正常終了したときは、リクエスト成否を「成功」とし、いずれか一方または両方ともが正常終了でないときは、リクエスト成否を「エラー」とする。さらに、トランザクション制御部３１は、在庫マスタ及びトランザクションテーブルのテーブル更新情報５５１，５５２を取得して、インタフェースサーバ１へリプライを返す。
【００３４】
インタフェースサーバ１では、業務処理サーバ３からのリプライをトランザクションジャーナル１３（図２参照）に格納し、リクエスト成否をトランザクションの処理結果として出力して処理を終了する（Ｓ１９）。
【００３５】
これにより、トランザクションジャーナル１３には、各トランザクション（リクエストＩＤ２１）について、そのトランザクションに係るリクエストの全処理が成功したか否かを示すリクエスト成否２２と、各テーブルに対する個別の処理内容を示すテーブル更新情報２３，２４が格納される。従って、トランザクションジャーナル１３を参照することにより、データの不整合が生じているか否かを確認することができる。例えば、監視装置２０がトランザクションジャーナル１３の記憶内容を取得して、表示装置などに出力することにより、システム管理者が確認できるようにしてもよい。出力された内容の整合性及び個別の対処方法は、次に説明するトランザクション整合性チェック表で確認できる。
【００３６】
図５には、トランザクション整合性チェック表１００を示す。このチェック表１００は、リクエスト成否２２に対して，テーブル更新情報（在庫マスタ）２３及びテーブル更新情報（トランザクション）２４が登録済みであるか否かに応じて、システム管理者が採るべき対処方法を示す。ここで、テーブル更新情報２３，２４は、テーブルの更新が正常終了したときにだけ生成されるので、テーブル更新情報２３，２４が未登録であるときは、テーブルの更新が正常終了していないことを意味する。
【００３７】
例えば、項番３のリクエスト成否２２が「エラー」でテーブル更新情報２３，２４がいずれも「未登録」であるときと、項番４のリクエスト成否２２が「成功」でテーブル更新情報２３，２４がいずれも「登録済み」であるときは、データの整合性はとれているので、データベースに対する特別な対応は必要ない。
【００３８】
一方、項番２のリクエスト成否２２が「エラー」であり、テーブル更新情報２３は「登録済み」であるが、テーブル更新情報２４は「未登録」であるときは、データの不整合が生じている。つまり、この場合は、在庫マスタテーブル５１を正常に更新した後、トランザクションテーブル５３の更新に失敗をしているため、不整合となっている。この場合、システム管理者は、リクエストＩＤによりテーブル更新情報５５を検索して、手動でロールバックを行う。
【００３９】
２フェーズコミットメントがサポートされているＤＢＭＳの場合、上記のようなケースでは、在庫マスタテーブル５１の更新処理はロールバックされ、整合性が保たれるようになっている。しかし、本実施形態のように２フェーズコミットメントがサポートされていないＤＢＭＳでは、在庫マスタテーブル５１のロールバックがされないので、これを検出する必要がある。
【００４０】
また、上記のようにシステム管理者が不整合を検出して、手動でロールバックを行ってもよいが、それ以外に、監視装置２０が自動的に不整合判定を行ってその結果をシステム管理者へ通知してもよいし、さらには、自動的にロールバックまで行って、その結果をシステム管理者へ通知してもよい。自動、手動を問わず、不整合の検出及びロールバックの実行は、トランザクション処理とは同期していなくてもよい。
【００４１】
なお、項番１，５〜７の場合は、システム障害またはＤＢＭＳ障害が生じていると考えられるので、それぞれ適切な対応が必要である。
【００４２】
上述した本発明の実施形態は、本発明の説明のための例示であり、本発明の範囲をそれらの実施形態にのみ限定する趣旨ではない。当業者は、本発明の要旨を逸脱することなしに、他の様々な態様で本発明を実施することができる。
【００４３】
例えば、上述した実施形態では、同一のＤＢＭＳ内の複数のテーブル間でのデータの整合性を担保する場合について説明したが、同様のやり方で異なるＤＢＭＳ間の整合性を担保することもできる。
【図面の簡単な説明】
【００４４】
【図１】本発明の一実施形態に係るトランザクション処理システム１０とその監視装置２０を示す図である。
【図２】トランザクションジャーナル１３のデータ構造の一例を示す図である。
【図３】テーブル更新情報のデータ構造の一例を示す図である。
【図４】処理手順を示すフローチャートである。
【図５】トランザクション整合性チェック表の一例を示す図である。
【符号の説明】
【００４５】
１ インタフェースサーバ
３ 業務処理サーバ
５ ＤＢＭＳ
１０ トランザクション処理システム
１１ リクエストＩＤ付与部
１３ トランザクションジャーナル
２０ 監視装置
３１ トランザクション制御部
３３ 業務処理部
５１ 在庫マスタテーブル
５３ トランザクションテーブル
５５ テーブル更新情報
【技術分野】
【０００１】
本発明は、ＤＢＭＳ（Database Management System）を利用するシステムにおいて、ＤＢＭＳに格納された複数のテーブル間のデータの整合性を担保するための技術に関する。
【背景技術】
【０００２】
近年、誰でもが自由に利用できるようにするため、ソフトウェアのソースコードをオープンソースとして、インターネットなどを通じて無償で公開することが行われている。そして、オープンソースのソフトウェアを利用すれば、低コストでアプリケーションシステムの構築が可能となることから、企業なども徐々に利用し始めている。
【発明の開示】
【発明が解決しようとする課題】
【０００３】
ＤＢＭＳ（Database Management System；データベース管理システム）もオープンソースとして公開されているものがある。オープンソースのＤＢＭＳの場合、２フェーズコミットメントなどのような高度な機能が実装されていないものがある。このようなＤＢＭＳが利用された場合、データの整合性を担保するためには２フェーズコミットメントを行うべきときであっても、それが行われないことになる。そうなると、データの不整合が生じ、このデータを利用するアプリケーションシステムにおいて不都合が生じる。
【０００４】
そこで、本発明の目的は、２フェーズコミットメント機能を有しないＤＢＭＳを利用した場合でも、データの整合性を担保するための技術を提供することである。
【課題を解決するための手段】
【０００５】
本発明の一実施態様に従うＤＢＭＳ（Database Management System）と接続され、前記ＤＢＭＳに格納されたデータの整合性を担保するためのシステムは、リクエスト要求元からのリクエストを受け付けると、前記リクエストに識別情報を付与する手段と、前記ＤＢＭＳに対して、前記リクエストに基づくデータの更新処理を依頼する更新手段と、前記更新手段が前記リクエストに基づいて前記ＤＢＭＳに複数の更新処理を依頼した場合、前記リクエストに付与された識別情報と関連づけられた各更新処理の内容に関する更新情報を、前記ＤＢＭＳから取得する更新情報取得手段と、前記更新手段が前記ＤＢＭＳに依頼したすべての更新処理の処理結果に基づいて、前記リクエストの成否を判定するリクエスト成否判定手段と、前記リクエスト成否判定手段による判定結果と前記更新情報取得手段により取得した更新情報とを、前記リクエストに付与された識別情報で関連づけて記憶する記憶手段と、前記リクエスト成否判定手段による判定結果を、前記リクエスト要求元に対して出力する手段と、を備える。
【０００６】
好適な実施形態では、前記更新情報は、前記更新手段が依頼した更新処理別になっていて、各更新処理が正常終了したときに、当該更新処理に関する更新情報が前記ＤＢＭＳによって生成されてもよい。
【０００７】
好適な実施形態では、リクエスト成否判定手段は、前記更新手段が依頼したすべての更新処理が正常終了したときはリクエスト成功と判定し、前記更新手段が依頼した更新処理のいずれか一つ以上が正常終了でないときはリクエスト不成功と判定するようにしてもよい。
【０００８】
好適な実施形態では、前記記憶手段に、ある識別情報が付与されているリクエストの判定結果がリクエスト不成功と記憶されていて、かつ、前記更新情報取得手段が取得した、当該識別情報に係る一部の前記更新情報が記憶されているときは、前記ＤＢＭＳに格納された複数のテーブル間で不整合が生じていると判定する整合性判定手段を、さらに備えてもよい。
【発明を実施するための最良の形態】
【０００９】
本発明の一実施形態に係る、２フェーズコミットメントがサポートされていないＤＢＭＳを利用したトランザクション処理を行うシステムについて、図面を用いて説明する。
【００１０】
図１は、本実施形態に係るトランザクション処理システム１０とその監視装置２０の構成を示す図である。トランザクション処理システム１０は、外部とのデータ入出力を行うインタフェースサーバ１と、所定の業務処理を行う業務処理サーバ３と、ＤＢＭＳ５とを備える。監視装置２０は、例えば、インタフェースサーバ１と接続されている。
【００１１】
本実施形態では、ＤＢＭＳ５が在庫マスタを有し、業務処理サーバ３が商品の発注、在庫管理等を行っているときに、インタフェースサーバ１が商品の発注をリクエストするトランザクションを受け付けたときの処理を例にとって説明する。
【００１２】
インタフェースサーバ１、業務処理サーバ３、ＤＢＭＳ５および監視装置２０は、いずれも例えば汎用的なコンピュータシステムにより構成され、以下に説明する各サーバ等１，３，５、２０内の個々の構成要素または機能は、例えば、コンピュータプログラムを実行することにより実現される。
【００１３】
インタフェースサーバ１は、リクエスト要求元の装置からのリクエストをトランザクションとして受け付け、このリクエストが正常終了したか否かを示すリクエスト成否をリクエスト要求元へ返信する。また、インタフェースサーバ１は、内部の機能として、受け付けたトランザクションに含まれるリクエストに識別情報であるＩＤを付与するリクエストＩＤ付与部１１と、トランザクションの処理履歴を記録するトランザクションジャーナル１３とを有する。
【００１４】
リクエストＩＤ付与部１１は、トランザクション処理システム１０内でユニークなリクエストＩＤを、各トランザクションに係るリクエストに対して付与し、業務処理サーバ３へ送る。
【００１５】
トランザクションジャーナル１３には、各トランザクションに係るリクエストごとに、その処理結果などの情報が格納される。例えば、業務処理サーバ３から返信されたリクエストに対するリプライが、トランザクションジャーナル１３に格納される。
【００１６】
図２には、トランザクションジャーナル１３のデータ構造の一例を示す。トランザクションジャーナル１３は、データ項目として、リクエストＩＤ２１と、リクエスト成否２２と、在庫マスタテーブルのテーブル更新情報２３と、トランザクションテーブルのテーブル更新情報２４とを有する。リクエスト成否２２，及びテーブル更新情報２３，２４については後述する。
【００１７】
再び図１を参照すると、ＤＢＭＳ５は、それぞれデータが格納されている種々のテーブル５１，５３と、テーブル更新情報５５とが記憶されている。テーブル更新情報５５には、各テーブルの更新（上書き及び挿入）が行われたときに、その更新内容などが格納される。テーブル更新情報５５は、テーブル別になっている。
【００１８】
テーブル更新情報５５のデータ構造を図３に示す。テーブル更新情報５５は、テーブル名４１と、上書き／挿入種別４２と、更新の主キー４３と、更新前情報４４と、更新後情報４５と、リクエストＩＤ４６とをデータ項目として有する。テーブル更新情報５５は、各テーブルの更新処理が完了した時点で、その更新処理に係るレコードが追加される。従って、ＤＢＭＳ５が業務処理サーバ３からデータの更新依頼を受けた場合でも、その更新が正常終了しなければ、その更新処理に係るレコードが生成されない。この結果、リクエストＩＤ４６をキーにしてテーブル更新情報５５を参照することにより、各更新処理の成否を判定することができる。
【００１９】
図１の例では、ＤＢＭＳ５は、在庫マスタテーブル５１とトランザクションテーブル５３とを有している。そして、テーブル更新情報５５には、在庫マスタテーブルの更新情報５５１とトランザクションテーブルの更新情報５５２とが格納される。
【００２０】
業務処理サーバ３は、トランザクション制御を行うトランザクション制御部３１と、複数の個別処理３３１，３３２を有する業務処理部３３とを備える。ここで、個別処理には在庫処理３３１と、注文処理３３２とがある。
【００２１】
トランザクション制御部３１は、インタフェースサーバ１から通知されたトランザクションを受け付けて、そのトランザクションに含まれるリクエストに応じた個別処理を業務処理部３３から選択して実行させる。そして、トランザクション制御部３１は、業務処理部３３の個別処理の結果に応じて、リクエストに対する処理が正常に終了したか否か（リクエスト成否）を判定する。さらに、リクエストＩＤをキーにしてＤＢＭＳ５からテーブル更新情報５５を取得して、リクエスト成否とともにトランザクションに対するリプライとしてインタフェースサーバ１へ返信する。
【００２２】
業務処理部３３の各個別処理は、それぞれ所定の業務処理を実行する。さらに、各個別処理は、ＤＢＭＳ５内の各テーブルの参照、更新の際は、ＤＢＭＳ５に対して処理を依頼する。ＤＢＭＳ５へ処理を依頼するときは、リクエストＩＤもあわせて通知する。
【００２３】
例えば、インタフェースサーバ１から商品発注リクエストのトランザクションが通知されると、トランザクション制御部３１は、在庫処理３３１と注文処理３３２を順次呼び出してそれぞれの処理を実行させる。ここで、在庫処理３３１としては、在庫引き当て、在庫マスタテーブル５１の更新等を行う。在庫マスタテーブル５１の更新は、ＤＢＭＳ５に対して処理を依頼する。注文処理３３２としては、例えば、商品発注に対する注文ＩＤを採番し、トランザクションテーブル５３への注文情報の格納を、ＤＢＭＳ５に対して依頼する。
【００２４】
次に、図４のフローチャートを用いて、商品発注のトランザクション処理について説明する。
【００２５】
まず、インタフェースサーバ１が商品発注リクエストを含むトランザクションを受け付けると、リクエストＩＤ付与部１１が、そのトランザクションにリクエストＩＤを付与する（Ｓ１１）。そして、リクエストＩＤが付与されたトランザクションは、業務処理サーバ３へ通知される。
【００２６】
業務処理サーバ３では、トランザクション制御部３１がトランザクションを受け付けると、そのトランザクションに応じた、業務処理部３３の個別処理３３１，３３２を順次実行させる（Ｓ１２）。ここで実行される各個別処理の中で、ＤＢＭＳ５内のテーブルを更新するときは、ＤＢＭＳ５に対してテーブルの更新を依頼する（Ｓ１３）。このテーブルの更新依頼には、受け付けたトランザクションに付与されているリクエストＩＤが付されている。
【００２７】
本実施形態では、トランザクション制御部３１は、商品発注のトランザクションに対して、まず在庫処理３３１を実行させる。在庫処理３３１では、在庫引き当て処理を行った後、ＤＢＭＳ５に在庫マスタテーブル５１の更新要求を出力する。
【００２８】
ＤＢＭＳ５がテーブル更新の依頼を受けると、それに応じてテーブルの更新を行う（Ｓ１４）。そして、このテーブルの更新が成功すると、ＤＢＭＳ５がこのテーブルの更新に基づいてテーブル更新情報５５（図３参照）を格納する（Ｓ１５）。
【００２９】
本実施形態では、ＤＢＭＳ５は、在庫マスタテーブル５１を更新するとともに、在庫マスタのテーブル更新情報５５１に、その更新に係る情報を格納する。
【００３０】
ＤＢＭＳ５での処理が終了すると、トランザクション制御部３１へ個別処理が正常終了したか否かを示す処理結果が通知され、これにより個別処理が終了する（Ｓ１６）。トランザクション制御部３１は、他にも行うべき個別処理があるか否かを判定し、すべての個別業務処理を上記ステップＳ１２〜Ｓ１６に従って実行させる（Ｓ１７）。
【００３１】
本実施形態では、上述の在庫処理３３１が終了すると、トランザクション制御部３１がこれに続いて注文処理３３２を実行させる。つまり、注文処理３３２について、ステップＳ１２以降の処理が再び実行される。注文処理３３２では、注文ＩＤを採番して、ＤＢＭＳ５にトランザクションテーブル５３の更新要求を出力する。ＤＢＭＳ５は、トランザクションテーブル５３を更新するとともに、トランザクションテーブルのテーブル更新情報５５２に、その更新に係る情報を格納する。そして、これらの処理結果をトランザクション制御部３１へ通知して処理を終了する。
【００３２】
すべての個別処理が終了すると（Ｓ１７：Ｙｅｓ）、トランザクション制御部３１は、リクエストの成否を判定する（Ｓ１８）。すなわち、このトランザクションに基づいて処理を行った個別処理のすべてが正常終了していればトランザクションは成功であり、個別処理のいずれか一つでも正常終了でなければ、トランザクションは不成功（エラー）である。個別処理の成否判定は、ＤＢＭＳ５から通知される処理結果に基づいて行われる。さらに、トランザクション制御部３１は、ＤＢＭＳ５からテーブル更新情報５５を取得し、ここで取得したテーブル更新情報５５と、リクエスト成否及びリクエストＩＤとを含むリプライを、インタフェースサーバ１へ返信する。
【００３３】
本実施形態では、トランザクション制御部３１は、在庫処理３３１及び注文処理３３２のいずれもが正常終了したときは、リクエスト成否を「成功」とし、いずれか一方または両方ともが正常終了でないときは、リクエスト成否を「エラー」とする。さらに、トランザクション制御部３１は、在庫マスタ及びトランザクションテーブルのテーブル更新情報５５１，５５２を取得して、インタフェースサーバ１へリプライを返す。
【００３４】
インタフェースサーバ１では、業務処理サーバ３からのリプライをトランザクションジャーナル１３（図２参照）に格納し、リクエスト成否をトランザクションの処理結果として出力して処理を終了する（Ｓ１９）。
【００３５】
これにより、トランザクションジャーナル１３には、各トランザクション（リクエストＩＤ２１）について、そのトランザクションに係るリクエストの全処理が成功したか否かを示すリクエスト成否２２と、各テーブルに対する個別の処理内容を示すテーブル更新情報２３，２４が格納される。従って、トランザクションジャーナル１３を参照することにより、データの不整合が生じているか否かを確認することができる。例えば、監視装置２０がトランザクションジャーナル１３の記憶内容を取得して、表示装置などに出力することにより、システム管理者が確認できるようにしてもよい。出力された内容の整合性及び個別の対処方法は、次に説明するトランザクション整合性チェック表で確認できる。
【００３６】
図５には、トランザクション整合性チェック表１００を示す。このチェック表１００は、リクエスト成否２２に対して，テーブル更新情報（在庫マスタ）２３及びテーブル更新情報（トランザクション）２４が登録済みであるか否かに応じて、システム管理者が採るべき対処方法を示す。ここで、テーブル更新情報２３，２４は、テーブルの更新が正常終了したときにだけ生成されるので、テーブル更新情報２３，２４が未登録であるときは、テーブルの更新が正常終了していないことを意味する。
【００３７】
例えば、項番３のリクエスト成否２２が「エラー」でテーブル更新情報２３，２４がいずれも「未登録」であるときと、項番４のリクエスト成否２２が「成功」でテーブル更新情報２３，２４がいずれも「登録済み」であるときは、データの整合性はとれているので、データベースに対する特別な対応は必要ない。
【００３８】
一方、項番２のリクエスト成否２２が「エラー」であり、テーブル更新情報２３は「登録済み」であるが、テーブル更新情報２４は「未登録」であるときは、データの不整合が生じている。つまり、この場合は、在庫マスタテーブル５１を正常に更新した後、トランザクションテーブル５３の更新に失敗をしているため、不整合となっている。この場合、システム管理者は、リクエストＩＤによりテーブル更新情報５５を検索して、手動でロールバックを行う。
【００３９】
２フェーズコミットメントがサポートされているＤＢＭＳの場合、上記のようなケースでは、在庫マスタテーブル５１の更新処理はロールバックされ、整合性が保たれるようになっている。しかし、本実施形態のように２フェーズコミットメントがサポートされていないＤＢＭＳでは、在庫マスタテーブル５１のロールバックがされないので、これを検出する必要がある。
【００４０】
また、上記のようにシステム管理者が不整合を検出して、手動でロールバックを行ってもよいが、それ以外に、監視装置２０が自動的に不整合判定を行ってその結果をシステム管理者へ通知してもよいし、さらには、自動的にロールバックまで行って、その結果をシステム管理者へ通知してもよい。自動、手動を問わず、不整合の検出及びロールバックの実行は、トランザクション処理とは同期していなくてもよい。
【００４１】
なお、項番１，５〜７の場合は、システム障害またはＤＢＭＳ障害が生じていると考えられるので、それぞれ適切な対応が必要である。
【００４２】
上述した本発明の実施形態は、本発明の説明のための例示であり、本発明の範囲をそれらの実施形態にのみ限定する趣旨ではない。当業者は、本発明の要旨を逸脱することなしに、他の様々な態様で本発明を実施することができる。
【００４３】
例えば、上述した実施形態では、同一のＤＢＭＳ内の複数のテーブル間でのデータの整合性を担保する場合について説明したが、同様のやり方で異なるＤＢＭＳ間の整合性を担保することもできる。
【図面の簡単な説明】
【００４４】
【図１】本発明の一実施形態に係るトランザクション処理システム１０とその監視装置２０を示す図である。
【図２】トランザクションジャーナル１３のデータ構造の一例を示す図である。
【図３】テーブル更新情報のデータ構造の一例を示す図である。
【図４】処理手順を示すフローチャートである。
【図５】トランザクション整合性チェック表の一例を示す図である。
【符号の説明】
【００４５】
１ インタフェースサーバ
３ 業務処理サーバ
５ ＤＢＭＳ
１０ トランザクション処理システム
１１ リクエストＩＤ付与部
１３ トランザクションジャーナル
２０ 監視装置
３１ トランザクション制御部
３３ 業務処理部
５１ 在庫マスタテーブル
５３ トランザクションテーブル
５５ テーブル更新情報
【特許請求の範囲】
【請求項１】
ＤＢＭＳ（Database Management System）と接続され、前記ＤＢＭＳに格納されたデータの整合性を担保するためのシステムであって、
リクエスト要求元からのリクエストを受け付けると、前記リクエストに識別情報を付与する手段と、
前記ＤＢＭＳに対して、前記リクエストに付与された識別情報を含む、前記リクエストに基づくデータの更新処理を依頼する更新手段と、
前記更新手段が前記リクエストに基づいて前記ＤＢＭＳに複数の更新処理を依頼した場合、前記リクエストに付与された識別情報と関連づけられた各更新処理の内容に関する更新情報を、前記ＤＢＭＳから取得する更新情報取得手段と、
前記更新手段が前記ＤＢＭＳに依頼した前記複数の更新処理のすべての処理結果に基づいて、前記リクエストの成否を判定するリクエスト成否判定手段と、
前記リクエスト成否判定手段による判定結果と前記更新情報取得手段が取得した更新情報とを、前記リクエストに付与された識別情報で関連づけて記憶する記憶手段と、
前記リクエスト成否判定手段による判定結果を、前記リクエスト要求元に対して出力する手段と、を備えたシステム。
【請求項２】
前記更新情報取得手段が取得した更新情報は、前記更新手段が依頼した更新処理別になっていて、
各更新処理が正常終了したときに、当該更新処理に関する更新情報が前記ＤＢＭＳによって生成されることを特徴とする請求項１記載のシステム。
【請求項３】
リクエスト成否判定手段は、前記更新手段が依頼したすべての更新処理が正常終了したときはリクエスト成功と判定し、前記更新手段が依頼した更新処理のいずれか一つ以上が正常終了でないときはリクエスト不成功と判定することを特徴とする請求項１記載のシステム。
【請求項４】
前記記憶手段に、ある識別情報が付与されているリクエストの判定結果がリクエスト不成功と記憶されていて、かつ、前記更新情報取得手段が取得した、当該識別情報に係る一部の前記更新情報が記憶されているときは、前記ＤＢＭＳに格納された複数のテーブル間で不整合が生じていると判定する整合性判定手段を、さらに備える請求項１記載のシステム。
【請求項５】
ＤＢＭＳ（Database Management System）を利用するシステムが、前記ＤＢＭＳに格納された複数のテーブル間のデータの整合性を担保するための方法であって、
リクエスト要求元からリクエストを受け付けると、前記リクエストに識別情報を付与するステップと、
前記ＤＢＭＳに対して、前記リクエストに基づいて複数の更新処理を依頼するステップと、
前記リクエストに付与された識別情報と関連づけられた各更新処理の内容に関する更新情報を、前記ＤＢＭＳから取得するステップと、
前記依頼したすべての更新処理の処理結果に基づいて、前記リクエストの成否を判定するステップと、
前記リクエスト成否の判定結果と前記取得した更新情報とを、前記リクエストに付与された識別情報で関連づけて記憶するステップと、
前記リクエスト成否判定手段による判定結果を、前記リクエスト要求元に対して出力するステップと、を有する方法。
【請求項６】
ＤＢＭＳ（Database Management System）に格納されたデータの整合性を担保するためのコンピュータプログラムであって、
コンピュータに実行されると、
リクエスト要求元からリクエストを受け付けると、前記リクエストに識別情報を付与するステップと、
前記ＤＢＭＳに対して、前記リクエストに基づいて複数の更新処理を依頼するステップと、
前記リクエストに付与された識別情報と関連づけられた各更新処理の内容に関する更新情報を、前記ＤＢＭＳから取得するステップと、
前記依頼したすべての更新処理の処理結果に基づいて、前記リクエストの成否を判定するステップと、
前記リクエスト成否の判定結果と前記取得した更新情報とを、前記リクエストに付与された識別情報で関連づけて記憶するステップと、
前記リクエスト成否判定手段による判定結果を、前記リクエスト要求元に対して出力するステップと、が行われるコンピュータプログラム。
【請求項１】
ＤＢＭＳ（Database Management System）と接続され、前記ＤＢＭＳに格納されたデータの整合性を担保するためのシステムであって、
リクエスト要求元からのリクエストを受け付けると、前記リクエストに識別情報を付与する手段と、
前記ＤＢＭＳに対して、前記リクエストに付与された識別情報を含む、前記リクエストに基づくデータの更新処理を依頼する更新手段と、
前記更新手段が前記リクエストに基づいて前記ＤＢＭＳに複数の更新処理を依頼した場合、前記リクエストに付与された識別情報と関連づけられた各更新処理の内容に関する更新情報を、前記ＤＢＭＳから取得する更新情報取得手段と、
前記更新手段が前記ＤＢＭＳに依頼した前記複数の更新処理のすべての処理結果に基づいて、前記リクエストの成否を判定するリクエスト成否判定手段と、
前記リクエスト成否判定手段による判定結果と前記更新情報取得手段が取得した更新情報とを、前記リクエストに付与された識別情報で関連づけて記憶する記憶手段と、
前記リクエスト成否判定手段による判定結果を、前記リクエスト要求元に対して出力する手段と、を備えたシステム。
【請求項２】
前記更新情報取得手段が取得した更新情報は、前記更新手段が依頼した更新処理別になっていて、
各更新処理が正常終了したときに、当該更新処理に関する更新情報が前記ＤＢＭＳによって生成されることを特徴とする請求項１記載のシステム。
【請求項３】
リクエスト成否判定手段は、前記更新手段が依頼したすべての更新処理が正常終了したときはリクエスト成功と判定し、前記更新手段が依頼した更新処理のいずれか一つ以上が正常終了でないときはリクエスト不成功と判定することを特徴とする請求項１記載のシステム。
【請求項４】
前記記憶手段に、ある識別情報が付与されているリクエストの判定結果がリクエスト不成功と記憶されていて、かつ、前記更新情報取得手段が取得した、当該識別情報に係る一部の前記更新情報が記憶されているときは、前記ＤＢＭＳに格納された複数のテーブル間で不整合が生じていると判定する整合性判定手段を、さらに備える請求項１記載のシステム。
【請求項５】
ＤＢＭＳ（Database Management System）を利用するシステムが、前記ＤＢＭＳに格納された複数のテーブル間のデータの整合性を担保するための方法であって、
リクエスト要求元からリクエストを受け付けると、前記リクエストに識別情報を付与するステップと、
前記ＤＢＭＳに対して、前記リクエストに基づいて複数の更新処理を依頼するステップと、
前記リクエストに付与された識別情報と関連づけられた各更新処理の内容に関する更新情報を、前記ＤＢＭＳから取得するステップと、
前記依頼したすべての更新処理の処理結果に基づいて、前記リクエストの成否を判定するステップと、
前記リクエスト成否の判定結果と前記取得した更新情報とを、前記リクエストに付与された識別情報で関連づけて記憶するステップと、
前記リクエスト成否判定手段による判定結果を、前記リクエスト要求元に対して出力するステップと、を有する方法。
【請求項６】
ＤＢＭＳ（Database Management System）に格納されたデータの整合性を担保するためのコンピュータプログラムであって、
コンピュータに実行されると、
リクエスト要求元からリクエストを受け付けると、前記リクエストに識別情報を付与するステップと、
前記ＤＢＭＳに対して、前記リクエストに基づいて複数の更新処理を依頼するステップと、
前記リクエストに付与された識別情報と関連づけられた各更新処理の内容に関する更新情報を、前記ＤＢＭＳから取得するステップと、
前記依頼したすべての更新処理の処理結果に基づいて、前記リクエストの成否を判定するステップと、
前記リクエスト成否の判定結果と前記取得した更新情報とを、前記リクエストに付与された識別情報で関連づけて記憶するステップと、
前記リクエスト成否判定手段による判定結果を、前記リクエスト要求元に対して出力するステップと、が行われるコンピュータプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図２】
【図３】
【図４】
【図５】
【公開番号】特開２００６−２６０１２１（Ｐ２００６−２６０１２１Ａ）
【公開日】平成１８年９月２８日（２００６．９．２８）
【国際特許分類】
【出願番号】特願２００５−７６２０２（Ｐ２００５−７６２０２）
【出願日】平成１７年３月１７日（２００５．３．１７）
【出願人】（０００１５５４６９）株式会社野村総合研究所 (1,067)
【Ｆターム（参考）】
【公開日】平成１８年９月２８日（２００６．９．２８）
【国際特許分類】
【出願日】平成１７年３月１７日（２００５．３．１７）
【出願人】（０００１５５４６９）株式会社野村総合研究所 (1,067)
【Ｆターム（参考）】
[ Back to top ]