JP7071938B2

JP7071938B2 - データベース管理サービス提供システム

Info

Publication number: JP7071938B2
Application number: JP2019009349A
Authority: JP
Inventors: 宏文猪股; 雅文木下; 宏明郡浦
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2019-01-23
Filing date: 2019-01-23
Publication date: 2022-05-19
Anticipated expiration: 2039-01-23
Also published as: US11797556B2; US20220129473A1; JP2020119207A; CN113168405A; KR102598619B1; KR20210082481A; BR112021013970A2; WO2020153053A1

Description

本発明は、データベース管理サービス提供システムに関する。

昨今、企業規模に関わらず、グローバル化やビジネス強化のため、迅速かつ柔軟なサプライチェーン構築が重要になってきている。ＩＴインフラによって、サプライチェーン（ＥｌｅｃｔｒｏｎｉｃＤａｔａＩｎｔｅｒｃｈａｎｇｅを含む）に参加するパートナ企業間での迅速な情報共有（それぞれの参加企業が提供する情報の相互関連性の情報も含む）が重要になってきている。このようなサプライチェーンにおいて、パートナ企業（企業連合に参加する企業）の参加や脱退を、データベース管理システム（ＤＢＭＳ）を利用したＩＴシステムで、一元管理している。このサプライチェーンへの参加には、参加承認手続きや、各パートナ企業の保持するＩＴシステムとの接続ためのシステム構築や接続試験に、時間がかかり、ビジネスのアジリティ向上の妨げになってきている。以降の説明では、「パートナ企業」を、「パートナ」と略す。

また、昨今、情報共有のために、一元管理（もしくは、集中管理）を必要としない分散帳票技術（もしくは、ブロックチェーン技術）と呼ばれる技術も、普及し始めている。この技術は、長大なデータを扱うのは得意ではないが、ネットワーク上で疎結合されているＩＴシステムの間で、相互に情報の複製を持ち合うためのデータベース多重化技術の一種である。以降の説明では、この「分散帳票技術」を、「ＢＣ技術」と略す。また、「ブロックチェーン」を、「ＢＣ」と略す。

上記の背景から、今後、パートナのコーポレートガバナンスの強化並びにアジリティ向上のニーズが高まってくると考えている。本発明は、特に、サプライチェーンに属するパートナ間の情報共有（例：情報銀行、情報連携／対応付け）のアジリティを向上させるためのデータベース管理システムのサービス提供システムを対象としている。以下の説明では、サプライチェーンを、例として説明する。なお、サプライチェーンを、情報を共有する複数の企業グループと読み替えても、差し支えない。

特許文献１は、分散保管されている情報（ファイルなどのコンテンツ）の共有において、コンテンツのメタ情報を、一元的管理する仕組みを開示している。特許文献２は、分散する１台以上ファイルサーバに格納されるファイルのメタ情報（ファイル格納場所情報、等）を、ＢＣ技術によって共有することにより、同じファイルの重複保存を防ぐ仕組みを開示している。特許文献３は、ＢＣ技術を利用した商取引を実現するＩＴシステムの例を開示している。

米国特許第６０４４３７４号特開２０１８－１９０２２７号公報米国特許第９８７０５６２号

今後、例えばサプライチェーンにおいて、適用業務拡大に伴うアジリティ向上の要求が高くなってくる。まず、サプライチェーンにおいて、適用業務が定型でなく多種の業務への対応や、パートナ企業の参加や脱退の承認が集中管理され、各パートナ企業の参加／脱退を、前記サプライチェーンの部分的な企業グループの単位で容易に出来ず、手続きに時間がかかる傾向がある。すなわち、ＩＴインフラにおける情報共有ために、まず、多数の企業に散在する多様なアプリケーションから、それぞれのパートナ企業が保持するＤＢＭＳ及びデータベース（ＤＢ）を使用するためのＤＢＭＳ管理情報を、これらのパートナ企業で、迅速かつ柔軟に共有することが望まれる。

更に、複数のパートナで共有される情報（コンテンツ）は、インターネットに接続されるサーバのローカル・データベースに保持していても、昨今の通信性能向上から、インターネットを介して、どこからも滞りないアクセスが可能である一方、そのローカル・データベースを、他のサーバから、アクセスするために必要な管理情報を取得するなどの手続きや、そのアクセスを実現するＩＴシステム構築作業が、アジリティ向上の妨げになってきている。

本発明の一態様は、複数のサーバ及び１以上のデータベースを含む、データベース管理サービス提供システムである。前記複数のサーバは、第１のサーバと、第２のサーバと、を含む。前記複数のサーバの各サーバは、他のサーバと共有する情報を格納する共有情報格納領域を含む。前記複数のサーバは、前記共有情報格納領域のデータを一致させるように動作する。前記第１のサーバは、第１のローカル・データベースを管理する。前記第２のサーバは、前記第１のローカル・データベースへのアクセスのためのクエリ情報を生成し、前記クエリ情報を、前記第２のサーバの前記共有情報格納領域に格納する。前記第１のサーバは、前記第１のサーバの前記共有情報格納領域から前記クエリ情報を取得し、前記クエリ情報に対する結果を前記第１のサーバの前記共有情報格納領域に格納する。前記第２のサーバは、前記第２のサーバの前記共有情報格納領域から前記結果を取得する。

本発明の一態様によれば、データベースの利用についての処理を効率的に行うことができる。

ネットワーク全体構成システム構成サーバの内部構成サーバのメモリ構成サーバ構成データの構成管理データベースの構成ローカル・データベースの構成例エンド・ユーザ・デバイスの内部構成デバイス構成データの構成ＢＣトランザクションの手順概要クエリ結果収集の構成例ＳｅｒｖｅｒＡｐｐｌｉｃａｔｉｏｎＰｒｏｇｒａｍ例の動作フローＢＣＳｅｒｖｉｃｅＰｒｏｇｒａｍの動作フローＤＢＭＳＰｒｏｇｒａｍの動作フローエンド・ユーザ・デバイス・アプリケーション・プログラムの動作フロー異種のＢＣトランザクションの手順概要ＲｅｌａｙＰｒｏｇｒａｍの動作フロー

本実施形態の概要を説明する。本実施形態は、例えば企業間の情報共有を実現する、ＩＴインフラ及びデータベース管理システムに関する技術を説明する。ほ実施形態のシステム及び方法は、特に、企業連合（例：サプライチェーン）の管理と、当該企業連合に属する企業間の情報共有を実現する分散データベース管理システムに好適である。

パートナ間で共有する情報は、比較的大きな情報も含め、それぞれ、各パートナが有するサーバのＤＢＭＳ（データベース管理システム）プログラムを使用して、データベースに保管する。この際、それぞれのＤＢＭＳプログラムを使用／実行するために必要となる構成情報や管理情報を、ＢＣ（ブロックチェーン）技術によって、パートナ間で共有させる。これにより、パートナは、ブロックチェーン・ネットワーク（ＢＣ技術により情報共有するグループ）に加入することで、他のサーバにある上記ＤＢＭＳプログラムを介して、それぞれのローカル・データベースにアクセスできるようになる。

本発明を実施するための形態を、実施例に基づき、図面を参照し、説明する。以下、各要素の構成並びに、動作フローを用いて詳細を説明する。なお、実施例では、ブロックチェーン（ＢＣ）・ネットワークを実現するＢＣＳｅｒｖｉｃｅＰｒｏｇｒａｍの内部動作並びに仕様に関しては、公知のブロックチェーン・プラットフォームを適用できる。

公知のブロックチェーン・プラットフォームは、例えば、特許文献２で開示される例の他、ＯｐｅｎＳｏｕｒｃｅＳｏｆｔｗａｒｅ（ＯＳＳ）として公開されているブロックチェーン・プラットフォームが知られている。これらは、例えば、ＨｙｐｅｒｌｅｄｇｅｒＦａｂｒｉｃ、Ｅｔｈｅｒｅｕｍ、Ｑｕｏｒｕｍ、Ｂｉｔｃｏｒｅ、ＬＩＳＫ等である。

これらブロックチェーン・プラットフォームの間において機能を呼び出す関数名などに違いあるものの、本実施例は、どのブロックチェーン・プラットフォームでも提供されている機能を使用することができる。従って、以降、ブロックチェーン・ネットワークを実現するＢＣＳｅｒｖｉｃｅＰｒｏｇｒａｍの内部動作の詳細に関する説明は省略する。

上記ブロックチェーン・プラットフォームで採用されるブロックチェーン技術の概要を説明する。一般的に、通信ネットワークに接続される複数のサーバで、データを共有するいくつかの方式が知られている。１つの方式例は集中方式であって、特定のサーバに、共有するデータを保持させ、他のサーバが、その特定のサーバにデータアクセスすることにより、複数のサーバでデータを共有する。しかし、例えば、多数の企業に散在するアプリケーションから共有される長大なデータに関しては、特定のローカル・データベースに保持されると、個々の企業のＩＴインフラ（例えば、サーバ、データストレージ、ネットワーク）の性能に制限される。

他の方式例は、分散方式であって、データを共有する複数のサーバが、共有するデータの複製を相互に保持する。分散方式は、各サーバでのデータ更新を低負荷に行える一方、データ真正性の保証が難しい。

ブロックチェーン技術は、後者の分散方式を採用したデータ共有技術である。ブロックチェーン技術は、共有するデータの真正性を保証するため、更新後のデータだけを共有するのでなく、更新前のデータの履歴とともにデータ更新を行ったサーバ又はユーザの電子署名を付与する。これにより、第三者の改ざんを防止するとともに、改ざん検知を容易化する。ブロックチェーン技術は、集中方式よりも低負荷でデータ共有を提供し、集中方式と同程度の信頼性を提供できる。

図１と図２を参照して、本実施例を実施するデータベース管理サービス提供システムの構成を説明する。図１は、本システムのネットワーク構成を説明する。サプライチェーン１０１に属する１社以上の企業が保持するサーバ１０４、１０５、１０６、１０７、１０８、１０９と、エンド・ユーザ・デバイス１１０とは、インターネット１０２に接続し、それを介して通信する。

サプライチェーン１０１に属する１社以上の企業が保持するサーバ１０４、１０５、１０６、１０７、１０８、１０９は、さらに、ブロックチェーン・ネットワーク１０３に接続し、それを介して通信する。図１の例において、インターネット１０２は、ブロックチェーン・ネットワーク１０３を含む。サーバ１０４、１０５、１０６、１０７、１０８、１０９は、それぞれＬｏｃａｌＤＢ（データベース）４０７を有する。但し、図１では、処理の説明に必要なサーバ１０４、１０５、１０９のＬｏｃａｌＤＢのみ、記載している。サーバ１０５は、ＳｅｒｖｅｒＡｐｐｌｉｃａｔｉｏｎＰｒｏｇｒａｍ４０１を有する。

複数本の破線１１８は、ブロックチェーン・ネットワーク１０３におけるサーバ間の信頼関係を、模式的に表示している。破線１１８が接続するサーバ間に信頼関係が存在する。ブロックチェーン・プラットフォーム（図２においてＢＣＳｅｒｖｉｃｅＰｒｏｇｒａｍ４０２により）は、ブロックチェーン・ネットワーク１０３上のＢＣトランザクションの通信を、破線１１８が示す信頼関係を有するサーバ間のデータ交換の連鎖によって、実現する。

以上のネットワーク構成で、例えば、企業Ｘがサプライチェーン１０１に加入し、それに伴い、サーバ１０９が、ブロックチェーン・ネットワーク１０３に参加した後、サーバ１０５のＳｅｒｖｅｒＡｐｐｌｉｃａｔｉｏｎＰｒｏｇｒａｍ４０１は、ＥｎｄＵｓｅｒＤｅｖｉｃｅ１１０からの操作を、インターネット１０２を介して受信する。ＳｅｒｖｅｒＡｐｐｌｉｃａｔｉｏｎＰｒｏｇｒａｍ４０１は、処理に必要なデータを、他のサーバ１０４又は１０９が有するそれぞれのＬｏｃａｌＤＢ４０７から取得するために、サーバ１０４又は１０９へ、クエリを、ブロックチェーン・ネットワーク１０３を介して、送信する。

図２では、以降の動作説明で参照される論理的構成を説明する。インターネット１０２は、ブロックチェーン・ネットワーク１０３、２０３を含み、サーバ１０４、１０５、１０９、エンド・ユーザ・デバイス１１０は、インターネット１０２に接続する。サーバ１０４、１０５、１０９は、ブロックチェーン・ネットワーク１０３に接続する。図２に示すいずれのサーバも、ブロックチェーン・ネットワーク２０３に接続していない。

サーバ１０４、１０５、１０９のそれぞれは、ＢＣＳｅｒｖｉｃｅＰｒｏｇｒａｍ４０２、ＤＢＭＳＰｒｏｇｒａｍ４０３、ＭａｎａｇｅｍｅｎｔＤＢ４０６、ＬｏｃａｌＤＢ４０７を有する。更に、サーバ１０５は、１つ以上のＳｅｖｅｒＡｐｐｌｉｃａｔｉｏｎＰｒｏｇｒａｍ４０１を有する。サーバ１０５は、それぞれ異なるＬｏｃａｌＤＢに対応する複数のＳｅｖｅｒＡｐｐｌｉｃａｔｉｏｎＰｒｏｇｒａｍを有してもよい。

エンド・ユーザ・デバイス１１０は、ＥｎｄＵｓｅｒＤｅｖｉｃｅＡｐｐｌｉｃａｔｉｏｎＰｒｏｇｒａｍ８０６を有する。ＥｎｄＵｓｅｒＤｅｖｉｃｅＡｐｐｌｉｃａｔｉｏｎＰｒｏｇｒａｍ８０６は、インターネット１０２経由で、ＳｅｖｅｒＡｐｐｌｉｃａｔｉｏｎＰｒｏｇｒａｍ４０１へ、操作１１５を指示する。本例において、操作１１５は、指定したデータベースへのアクセスである。

ＢＣＳｅｒｖｉｃｅＰｒｏｇｒａｍ４０２は、ブロックチェーン・プラットフォームを実現するプログラムモジュールである。このモジュールは、一般的に、ＯＳＳで公開されるソフトウェアで、本実施例では、共通的な機能を使用するので、以降の詳細説明では、内部動作の説明は省略する。本実施例では、主に、ＢＣトランザクションの通信及び複数サーバでのデータ多重化（複製）などの共通的な機能を使用する。

ＢＣトランザクションは、ブロックチェーン・ネットワークを介したトランザクションである。また、ブロックチェーン・プラットフォームは、サーバ間で共有されるデータが多重化される。つまり、サーバは、共有情報格納領域に格納されているデータが一致するように動作する。本実施例においては、後述するＭａｎａｇｅｍｅｎｔＤＢ４０６のデデータが多重化され、サーバは、ＭａｎａｇｅｍｅｎｔＤＢ４０６が一致するように動作（通信）する。ＭａｎａｇｅｍｅｎｔＤＢ４０６（の格納領域）は、共有情報格納領域の例である。

ＤＢＭＳＰｒｏｇｒａｍ４０３は、一般的なデータベース管理システム（ＤＢＭＳ）を実現するプログラムに、ブロックチェーン・ネットワークとの接続するための機能を追加したプログラムモジュールである。以降の詳細説明では、データベース管理システムが提供するクエリ処理の機能は一般的に既知であり、詳細の説明は省略する。例えば、ＩＳＯ規格が定めるＳＱＬデータベース言語を採用するデータベース管理システムが利用できる。

また、本実施例では、ＤＢＭＳＰｒｏｇｒａｍ４０３として、キー・バリュー・ストレージ（ＫｅｙＶａｌｕｅＳｔｏｒａｇｅ）、オブジェクト・ストレージ（ＯｂｊｅｃｔＳｔｏｒａｇｅ）、Ｗｅｂサーバ（ＷｅｂＳｅｒｖｅｒ）など、ＳＱＬデータベース言語を採用していないデータストレージを実現するプログラムモジュールを使用してもよい。

ＭａｎａｇｅｍｅｎｔＤＢ４０６は、ＤＢＭＳＰｒｏｇｒａｍ４０３を実行する上で必要となる構成情報及び管理情報を保持するデータベース又は、ストレージである。構成情報はＤＢＭＳＰｒｏｇｒａｍ４０３の起動に必要な情報であり、管理情報はＤＢＭＳＰｒｏｇｒａｍ４０３がＬｏｃａｌＤＢ４０７の管理のために参照するデータである。ＭａｎａｇｅｍｅｎｔＤＢ４０６が保持するデータは、ＢＣＳｅｒｖｉｃｅＰｒｏｇｒａｍ４０２によって、複数のサーバの各ＭａｎａｇｅｍｅｎｔＤＢ４０６で、多重化される。

ＬｏｃａｌＤＢ４０７は、ＤＢＭＳＰｒｏｇｒａｍ４０３が管理するデータベースを保持するストレージである。ＥｎｄＵｓｅｒＤｅｖｉｃｅＡｐｐｌｉｃａｔｉｏｎＰｒｏｇｒａｍ８０６は、ＳｅｒｖｅｒＡｐｐｌｉｃａｔｉｏｎＰｒｏｇｒａｍ４０１を、インターネット１０２経由で操作するめのプログラムモジュールである。

以下、図３から図９を用いて、本システムの構成要素を説明する。上記１台以上のサーバ１０４、１０５、１０６、１０７、１０８、１０９の内部構成は、説明の簡略化のため同じとして説明する。なお、各サーバの動作で使用しない構成要素は有していなくともよい。

図３にて、上記１台以上のサーバのハードウェア内部構成を、図中のサーバ３０１を例として、説明する。サーバ３０１は、ＭＰＵ３０２、Ｍｅｍｏｒｙ３０３、インターネット１０２へ接続するＮＩＣ３０４と、それらを接続するデータバス３０５を有する。ＭＰＵ３０２は、マイクロプロセッサ・ユニットであり、プロセッサの一例である。Ｍｅｍｏｒｙ３０３は、主メモリであり、記憶装置の一例である。ＮＩＣ３０４は、インターネット１０２へ接続するネットワーク・インタフェース・カードである。図４にて、サーバ３０１のＭｅｍｏｒｙ３０３のデータ構成を説明する。Ｍｅｍｏｒｙ３０３は、ＳｅｒｖｅｒＡｐｐｌｉｃａｔｉｏｎＰｒｏｇｒａｍ４０１、ＢＣＳｅｒｖｉｃｅＰｒｏｇｒａｍ４０２、ＤＢＭＳＰｒｏｇｒａｍ４０３、ＳｅｒｖｅｒＣｏｎｆｉｇｕｒａｔｉｏｎＤａｔａ４０５、ＭａｎａｇｅｍｅｎｔＤＢ４０６、ＬｏｃａｌＤＢ４０７を有する。

ＳｅｒｖｅｒＡｐｐｌｉｃａｔｉｏｎＰｒｏｇｒａｍ４０１は、エンド・ユーザが利用する業務アプリケーションを実現するプログラムモジュールである。ＢＣＳｅｒｖｉｃｅＰｒｏｇｒａｍ４０２は、ブロックチェーン・プラットフォームを実現するプログラムモジュールである。

ＤＢＭＳＰｒｏｇｒａｍ４０３は、ブロックチェーン・ネットワークに参加するデータベース管理システムを実現するプログラムモジュールである。なお、各プログラムモジュール動作は、以降の動作フローで説明する。

ＳｅｒｖｅｒＣｏｎｆｉｇｕｒａｔｉｏｎＤａｔａ４０５は、自サーバに固有の構成情報及び管理情報を保持するデータ格納領域である。ＭａｎａｇｅｍｅｎｔＤＢ４０６（管理データベース）は、ＤＢＭＳＰｒｏｇｒａｍ４０３を実行する上で、必要となる構成情報及び管理情報を保持するデータ格納領域である。ＤＢＭＳＰｒｏｇｒａｍ４０３を使用するために必要な管理情報は、一般的に、採用するＤＢＭＳＰｒｏｇｒａｍ４０３の仕様により異なるが、共通的な情報も含まれている。

例えば、共通した構成情報としては、ＤＢＭＳＰｒｏｇｒａｍ４０３が管理するＬｏｃａｌＤＢ４０７のデータソース名、データベース名、ＬｏｃａｌＤＢ４０７が保持するデータベース・テーブル名などがあり、ＭａｎａｇｅｍｅｎｔＤＢ４０６は、これらの一部又は全てが保持することができる。また、共通した管理情報としては、ＤＢＭＳＰｒｏｇｒａｍ４０３を使用できるユーザの在存と、ユーザ権限などを保持するユーザ・アカウント情報などがある。ＭａｎａｇｅｍｅｎｔＤＢ４０６に、これらの一部又は全てを保持することができる。

本実施例の実施のためには、これらの構成情報及び管理情報は、ＤＢＭＳＰｒｏｇｒａｍ４０３を使用する上で必要となる任意の情報であり、これらの情報のＤＢＭＳＰｒｏｇｒａｍ４０３内部での処理の説明は省略する。

ＬｏｃａｌＤＢ４０７（ローカル・データベース）は、ＳｅｒｖｅｒＡｐｐｌｉｃａｔｉｏｎＰｒｏｇｒａｍ４０１が、ＤＢＭＳＰｒｏｇｒａｍ４０３を介して、使用するデータベースを保持するデータ格納領域である。なお、ＭａｎａｇｅｍｅｎｔＤＢ４０６並びに、ＬｏｃａｌＤＢ４０７は、外部接続のストレージ装置に保持させてもよい。

図５にて、ＳｅｒｖｅｒＣｏｎｆｉｇｕｒａｔｉｏｎＤａｔａ４０５の内部構成を説明する。ＳｅｒｖｅｒＣｏｎｆｉｇｕｒａｔｉｏｎＤａｔａ４０５は、ＤａｔａｂａｓｅＩＤ５０１、ＤａｔａＴａｂｌｅ “ＰｅｅｒＬｉｓｔ”５０２、ＤａｔａＴａｂｌｅ “ＬｏｃａｌＡｃｃｏｕｎｔＬｉｓｔ”５０３を有する。

ＤａｔａｂａｓｅＩＤ５０１は、自サーバのＬｏｃａｌＤＢを区別するための識別情報を保持するデータ格納領域である。図５の例においては、サーバが保持するＬｏｃａｌＤＢは一つであるが、複数のＬｏｃａｌＤＢが保持されてもよい。この識別子は、システム内で重複のない連番の他、各サーバのインターネット・アドレスなど、重複のない情報であればよい。

ＤａｔａＴａｂｌｅ “ＰｅｅｒＬｉｓｔ”５０２は、自サーバが信頼関係１１８を有するサーバ（ノード）のリストであり、通信を行う他のサーバのリストである。ブロックチェーン・ネットワークにおいて共有されるべき更新情報は、ＤａｔａＴａｂｌｅ “ＰｅｅｒＬｉｓｔ”５０２が示す全てのサーバに送信される。ＰｅｅｒＬｉｓｔ５０２により、信頼関係を有するピア・ツー・ピア通信により、ブロックチェーン・ネットワークネットワークの全サーバが情報を共有できる。

ＤａｔａＴａｂｌｅ “ＰｅｅｒＬｉｓｔ”５０２は、カラム”ＵＲＩ”と、カラム”ＰｅｅｒＩＤ”を有するデータ・テーブルである。カラム“ＵＲＩ”は、自サーバのＢＣＳｅｒｖｉｃｅＰｒｏｇｒａｍ４０２が直接、通信する他サーバ（信頼関係１１８を有するサーバ）のインターネット・アドレスでよい。カラム“ＰｅｅｒＩＤ”は、ブロックチェーン・ネットワーク上のサーバ識別情報である。このサーバ識別情報には、一般的に、ブロックチェーン・プラットフォームが採用する公開鍵暗号方式に基づいて、サーバ毎に生成される公開キーが使用される。

ＤａｔａＴａｂｌｅ “ＬｏｃａｌＡｃｃｏｕｎｔＬｉｓｔ”５０３は、自サーバが管理しているテーブルのリストである。ＤａｔａＴａｂｌｅ “ＬｏｃａｌＡｃｃｏｕｎｔＬｉｓｔ”５０３のレコードは、カラム“ＤａｔａｂａｓｅＩＤ”、カラム“ＴａｂｌｅＮａｍｅ”、カラム“ＢＣＡｃｃｏｕｎｔＩＤ”、カラム“ＳｅｃｒｅｔＫｅｙ”を有する。カラム”ＤａｔａｂａｓｅＩＤ”は、ローカル・データベースのデータベース・テーブルが保持されるサーバのＤａｔａｂａｓｅＩＤを保持する。

カラム“ＴａｂｌｅＮａｍｅ”は、データベース・テーブルの名称を保持する。カラム”ＢＣＡｃｃｏｕｎｔＩＤ”は、ブロックチェーン・ネットワーク上のサーバ識別情報（公開キー）を保持する。カラム“ＳｅｃｒｅｔＫｅｙ”は、ブロックチェーン・ネットワーク上のサーバ識別情報の秘密キーを保持する。

図６にて、ＭａｎａｇｅｍｅｎｔＤＢ４０６のデータ構成を説明する。ＭａｎａｇｅｍｅｎｔＤＢ４０６は、ブロックチェーン・ネットワーク上において、サーバ間で共有される情報である。いずれかのサーバにおけるＭａｎａｇｅｍｅｎｔＤＢ４０６の更新は、ブロックチェーン・ネットワーク上の全てのサーバに反映される。

ＭａｎａｇｅｍｅｎｔＤＢ４０６（管理データベース）は、ＤＢＴａｂｌｅ “ＤＢＴａｂｌｅＬｉｓｔ”６０１、ＤＢＴａｂｌｅ “ＧｌｏｂａｌＡｃｃｏｕｎｔＬｉｓｔ”６０２、データ格納領域“ＢＣＴｒａｎｓａｃｔｉｏｎＰａｙｌｏａｄｆｏｒＤＢＩｎｑｕｉｒｙ”６０３（クエリ格納領域）、データ格納領域“ＢＣＴｒａｎｓａｃｔｉｏｎＰａｙｌｏａｄｆｏｒＤＢＩｎｑｕｉｒｙＲｅｓｐｏｎｓｅ”６０４（クエリレスポンス格納領域）を有する。

ＤＢＴａｂｌｅ “ＤＢＴａｂｌｅＬｉｓｔ”６０１は、ブロックチェーン・ネットワーク上のサーバが管理するデータベースについての情報であり、本例において、ブロックチェーン・ネットワーク上の全てのテーブルのリストである。これにより、ブロックチェーン・ネットワーク上のサーバが、いずれのサーバに対するクエリ情報も生成できる。ＤＢＴａｂｌｅ “ＤＢＴａｂｌｅＬｉｓｔ”６０１は、カラム”ＤａｔａｂａｓｅＩＤ”、カラム”ＴａｂｌｅＮａｍｅ”、カラム”ＢＣＡｃｃｏｕｎｔＩＤ”を有する。

ＤＢＴａｂｌｅ“ＧｌｏｂａｌＡｃｃｏｕｎｔＬｉｓｔ”６０２は、ブロックチェーン・ネットワークに接続する全てのエンド・ユーザのリストである。ＤＢＴａｂｌｅ“ＧｌｏｂａｌＡｃｃｏｕｎｔＬｉｓｔ”６０２は、カラム”ＵｓｅｒＩＤ”、カラム”ＢＣＡｃｃｏｕｎｔＩＤ”を有する。

カラム”ＵｓｅｒＩＤ”は、エンド・ユーザの識別情報を保持する。この識別情報は、重複のない文字列もしくは、数値でよい。カラム”ＢＣＡｃｃｏｕｎｔＩＤ”は、エンド・ユーザに割り当てあれるブロックチェーン・ネットワーク上の識別情報で、サーバ識別情報と同様に、公開キーを保持する。

データ格納領域“ＢＣＴｒａｎｓａｃｔｉｏｎＰａｙｌｏａｄｆｏｒＤＢＩｎｑｕｉｒｙ”６０３（クエリ格納領域）は、ブロックチェーン・ネットワーク越しに、他のサーバのＤＢＭＳＰｒｏｇｒａｍ４０３へ送信するクエリ情報を保持する。クエリ情報は、新たなクエリ情報が生成されると更新される。

データ格納領域“ＢＣＴｒａｎｓａｃｔｉｏｎＰａｙｌｏａｄｆｏｒＤＢＩｎｑｕｉｒｙ”６０３は、データ・フィールド“ＤａｔａＫｉｎｄ”６０５（データ種別情報）、データ・フィールド“ＤＢＩｎｑｕｉｒｙ”６０６（クエリ情報）、データ・フィールド“ＲｅｓｐｏｎｓｅＤｅｓｔｉｎａｔｉｏｎ”６０７（応答先）、データ・フィールド“ＤＢＩｎｑｕｉｒｙＩＤ”６０８（クエリ識別情報）を保持する。

データ・フィールド“ＤａｔａＫｉｎｄ”６０５（データ種別情報）は、ＢＣＴｒａｎｓａｃｔｉｏｎＰａｙｌｏａｄのデータ内容の種類を特定する識別情報を保持する。特に、クエリのＢＣトランザクションでは、クエリを意味する識別情報を保持する。

データ・フィールド“ＤＢＩｎｑｕｉｒｙ”６０６（クエリ情報）は、ＤＢＭＳＰｒｏｇｒａｍ４０３に送るクエリ情報を保持する。例えば、ＳＱＬでの検索では、文字列“ＳＥＬＥＣＴＣｏｌｕｍｎ＿１ＦＲＯＭＡＡＡＷＨＥＲＥＣｏｌｕｍｎ＿２＝‘ｅ’”などを保持する。これは、ＤＢＴａｂｌｅ“ＡＡＡ”から、カラム”Ｃｏｌｕｍｎ＿２”の値が、“ｅ”と同じレコードのカラム“Ｃｏｌｕｍｎ＿１”の値を求めることを意味する。このように、データ・フィールド“ＤＢＩｎｑｕｉｒｙ”６０６は、アクセス先のテーブルを指定する。

データ・フィールド“ＲｅｓｐｏｎｓｅＤｅｓｔｉｎａｔｉｏｎ”６０７（応答先）は、ＤＢＭＳＰｒｏｇｒａｍ４０３のクエリ実行の応答の返し先を保持する。この応答の返し先は、サーバのＢＣＡｃｃｏｕｎｔＩＤや、ＵＲＩ（インターネット・アドレス）などでよい。後述するように、データ・フィールド“ＲｅｓｐｏｎｓｅＤｅｓｔｉｎａｔｉｏｎ”６０７は、クエリ結果の送り先情報である。ＲｅｓｐｏｎｓｅＤｅｓｔｉｎａｔｉｏｎ６０７は、ＤＢＭＳＰｒｏｇｒａｍ４０３が、（ＢＣＳｅｒｖｉｃｅＰｒｏｇｒａｍ４０２を介することなく）直接に、クエリ送信元のサーバに応答を変える場合に参照される。
データ・フィールド“ＤＢＩｎｑｕｉｒｙＩＤ”６０８（クエリ識別情報）は、クエリを識別するための識別情報で、重複のない連番や、ブロックチェーン上のトランザクション識別情報でよい。

データ格納領域“ＢＣＴｒａｎｓａｃｔｉｏｎＰａｙｌｏａｄｆｏｒＤＢＩｎｑｕｉｒｙＲｅｓｐｏｎｓｅ”６０４（クエリレスポンス格納領域）は、他のサーバに送信したクエリ情報に対する応答情報を保持する。この応答情報は、例えば、検索結果の場合、文字列“ｔｈｅｒｅｔｕｒｎｃｏｄｅ、ｔｈｅｒｅｓｕｌｔ ‘１’”を保持する。

データ格納領域“ＢＣＴｒａｎｓａｃｔｉｏｎＰａｙｌｏａｄｆｏｒＤＢＩｎｑｕｉｒｙＲｅｓｐｏｎｓｅ”６０４（クエリレスポンス格納領域）は、データ・フィールド“ＤａｔａＫｉｎｄ”６０５（データ種別）、データ・フィールド“ＤＢＩｎｑｕｉｒｙＲｅｓｐｏｎｓｅ”６１０（クエリレスポンス情報）、データ・フィールド“ＤＢＩｎｑｕｉｒｙＩＤ”６１１（クエリ識別情報）を有する。

データ・フィールド“ＤａｔａＫｉｎｄ”６０５（データ種別）は、クエリ応答を示す識別情報を保持する。データ・フィールド“ＤＢＩｎｑｕｉｒｙＲｅｓｐｏｎｓｅ”６１０（クエリレスポンス情報）は、クエリ実行によるＤＢＭＳＰｒｏｇｒａｍ４０３からの応答情報を保持する。データ・フィールド“ＤＢＩｎｑｕｉｒｙＩＤ”６１１（クエリ識別情報）は、ＤＢＭＳＰｒｏｇｒａｍ４０３で実行したクエリのＤＢＩｎｑｕｉｒｙＩＤ（ＤＢＩｎｑｕｉｒｙＩＤ６０８に格納されている値）を保持して、クエリの送信元が、当該送信元が送信したクエリに対するクエリ応答を特定できるようにする。

なお、ＤＢＩｎｑｕｉｒｙＩＤ６０８、６１１は、クエリを識別するための連番として説明するが、重複のない識別情報であればよく、ＢＣＳｅｒｖｉｃｅＰｒｏｇｒａｍ４０２内部で管理されるＢＣトランザクションの識別情報を使用してもよい。例えば、ブロックチェーン・プラットフォームＥｔｈｅｒｅｕｍが提供するコマンドｇｅｔｈでのＢＣトランザクション送信に際して、識別情報が取得できる。

ＢＣトランザクションの受信側のＤＢＭＳＰｒｏｇｒａｍでも、その識別情報が取得できるので、その情報を応答に含めることができる。送信側が、既にｇｅｔｈから取得している識別情報と、応答に含まれる識別情報とを比較することで、送信したＢＣトランザクションに対する応答か否かを判定できる。

図７にて、ＬｏｃａｌＤＢ４０７のデータ構成を説明する。ＬｏｃａｌＤＢ４０７は、動作説明のための例として、ＳｅｒｖｅｒＡｐｐｌｉｃａｔｉｏｎＰｒｏｇｒａｍが使用するデータベース・テーブルの一例を示している。ＳｅｒｖｅｒＡｐｐｌｉｃａｔｉｏｎＰｒｏｇｒａｍの内容は、エンド・ユーザやサプライチェーンに依存するので、それに応じて、異なるデータベース・テーブルを保持してもよい。

ＬｏｃａｌＤＢ４０７は、例えば、ＤＢＴａｂｌｅ “ＡＡＡ”７０１、ＤＢＴａｂｌｅ “ＢＢＢ”７０２を有する。ＤＢＴａｂｌｅ “ＡＡＡ”７０１のレコードは、カラム“Ｃｏｌｕｍｎ＿１”、カラム“Ｃｏｌｕｍｎ＿２”を有する。ＤＢＴａｂｌｅ “ＢＢＢ”７０２のレコードは、カラム“Ｃｏｌｕｍｎ＿１”、カラム” Ｃｏｌｕｍｎ＿２”を有する。

図８は、エンド・ユーザ・デバイス１１０の内部構成例を示す。エンド・ユーザ・デバイス１１０は、ＭＰＵ８０１、Ｍｅｍｏｒｙ８０２、インターネットに接続するＮＩＣ８０３、エンド・ユーザの操作入力及び情報表示を行うＵｓｅｒＩＦ８０４と、それらを接続するデータバス８０３を有する。ＭＰＵ８０１は、一般的なマイクロプロセッサ・ユニットであり、プロセッサの例である。

Ｍｅｍｏｒｙ８０２は、主メモリであり、記憶装置の例である。また、Ｍｅｍｏｒｙ８０２は、ＥｎｄＵｓｅｒＤｅｖｉｃｅＡｐｐｌｉｃａｔｉｏｎＰｒｏｇｒａｍ８０６と、ＤｅｖｉｃｅＣｏｎｆｉｇｕｒａｔｉｏｎＤａｔａ８０７を有する。ＥｎｄＵｓｅｒＤｅｖｉｃｅＡｐｐｌｉｃａｔｉｏｎＰｒｏｇｒａｍ８０６は、ＳｅｒｖｅｒＡｐｐｌｉｃａｔｉｏｎＰｒｏｇｒａｍ４０１を操作するためのプログラムモジュールである。

ＤｅｖｉｃｅＣｏｎｆｉｇｕｒａｔｉｏｎＤａｔａ８０７は、ＥｎｄＵｓｅｒＤｅｖｉｃｅ１１０固有の構成情報や管理情報を保持する。ＮＩＣ８０３は、ネットワーク・インタフェース。カードである。ＵｓｅｒＩＦ８０４は、エンド・ユーザの操作入力並ぶに情報表示を行うモジュールである。

図９は、Ｍｅｍｏｒｙ８０６のデータ格納領域、ＤｅｖｉｃｅＣｏｎｆｉｇｕｒａｔｉｏｎＤａｔａ８０６のデータ構成を示す。ＤｅｖｉｃｅＣｏｎｆｉｇｕｒａｔｉｏｎＤａｔａ８０６は、ＤａｔａＴａｂｌｅ “ＡｐｐｌｉｃａｔｉｏｎＡｃｃｏｕｎｔＬｉｓｔ”９０１を有する。ＤａｔａＴａｂｌｅ “ＡｐｐｌｉｃａｔｉｏｎＡｃｃｏｕｎｔＬｉｓｔ”９０１は、エンド・ユーザが使用するＳｅｒｖｅｒＡｐｐｌｉｃａｔｉｏｎＰｒｏｇｒａｍの一覧である。

ＤａｔａＴａｂｌｅ “ＡｐｐｌｉｃａｔｉｏｎＡｃｃｏｕｎｔＬｉｓｔ”９０１のレコードは、カラム“ＡｐｐｌｉｃａｔｉｏｎＩＤ”、カラム“ＢＣＡｃｃｏｕｎｔＩＤ”、カラム“ＳｅｃｒｅｔＫｅｙ”、カラム“ＵＲＩ”を有する。カラム“ＵＲＩ”は、ＥｎｄＵｓｅｒＤｅｖｉｃｅ８０６の使用者が、使用するＳｅｒｖｅｒＡｐｐｌｉｃａｔｉｏｎＰｒｏｇｒａｍへ接続先ＵＲＬを保持する。

上述のように、サーバ又はエンド・ユーザ・デバイスは計算機構成を有することができる。計算機構成において、プロセッサは、記憶装置に格納されているプログラムを実行することで、様々な機能部として動作することができる。以下において、プログラムを主語とする文章は、プロセッサ又はプロセッサを含む装置を主語とすることができる。また、サーバ及びエンド・ユーザ・デバイスの機能の少なくとも一部は、プロセッサと異なるＬＳＩによって実現されてもよい。さらに、同サーバ及びエンド・ユーザ・デバイスは、クラウドコンピューティングサービスが提供する仮想マシンによって実現してもよい。

以上で、システムの構成を説明した。次に、動作フローの詳細説明の前に、本システムの主要動作の概要を説明する。図１０は、サーバ１０５（第２のサーバ）のＳｅｒｖｅｒＡｐｐｌｉｃａｔｉｏｎＰｒｏｇｒａｍ４０１から、サーバ１０９（第１のサーバ）のローカル・データベース４０７が保持するデータベース・テーブルのデータをアクセスするための主なデータの流れを示している。図１０において、ＢＣＳｅｒｖｉｃｅＰｒｏｇｒａｍ４０２及びＤＢＭＳＰｒｏｇｒａｍ４０３を指示する破線矩形は、それぞれのプログラム４０２及び４０３が有する機能を示す。

エンド・ユーザ・デバイス１１０からの要求に応答して、サーバ１０５のＳｅｒｖｅｒＡｐｐｌｉｃａｔｉｏｎＰｒｏｇｒａｍ４０１は、サーバ１０９のローカル・データベース４０７へのクエリを生成する。ＡｐｐｌｉｃａｔｉｏｎＰｒｏｇｒａｍ４０１は、サーバ１０５のＢＣＳｅｒｖｉｃｅＰｒｏｇｒａｍ４０２経由で、サーバ１０５のＭａｎａｇｅｍｅｎｔＤＢのＢＣＴｒａｎｓａｃｔｉｏｎＰａｙｌｏａｄｆｏｒＤＢＩｎｑｕｉｒｙ６０３（クエリ格納領域）に書き込む。

サーバ１０５及び１０９を含む複数のサーバが保持するＢＣＳｅｒｖｉｃｅＰｒｏｇｒａｍ４０２は、パケット“ＢＣＴｒａｎｓａｃｔｉｏｎｆｏｒＤＢＩｎｑｕｉｒｙ”１００１を、信頼関係１１８に基づいて、転送して、サーバ１０５のＭａｎａｇｅｍｅｎｔＤＢ４０６への更新を自サーバのＭａｎａｇｅｍｅｎｔＤＢ４０６に反映する。なお、本例では、クエリについての格納領域６０３、６０４の更新を説明するが、いずれかのサーバにおけるＭａｎａｇｅｍｅｎｔＤＢ４０６に更新は、ブロックチェーン・ネットワーク上の全てのサーバのＭａｎａｇｅｍｅｎｔＤＢ４０６に反映される。

各サーバが保持するＤＢＭＳＰｒｏｇｒａｍ４０３は、ＢＣＳｅｒｖｉｃｅＰｒｏｇｒａｍ４０２を介して、ＭａｎａｇｅｍｅｎｔＤＢ４０６が保持するＢＣＴｒａｎｓａｃｔｉｏｎＰａｙｌｏａｄｆｏｒＤＢＩｎｑｕｉｒｙ６０３（クエリ格納領域）の内容更新を判定して、クエリ情報を取得して、クエリを実行する。

ＤＢＭＳＰｒｏｇｒａｍ４０３は、実行応答を、ＢＣＳｅｒｖｉｃｅＰｒｏｇｒａｍ４０２を介して、又は、直接に、ＲｅｓｐｏｎｓｅＤｅｓｔｉｎａｔｉｏｎ６０７が示すクエリ送信元に返送する。

例えば、ＤＢＭＳＰｒｏｇｒａｍ４０３は、返送するデータのサイズに基づいて、いずれの方法で返送するか決定する。例えば、データサイズが規定値以下である場合に、実行応答は、ＢＣＳｅｒｖｉｃｅＰｒｏｇｒａｍ４０２（ブロックチェーン・ネットワーク／プロトコル）を介して、ブロックチェーン・ネットワークのパケット１００７として、クエリ送信元を含む複数のサーバに転送される。データサイズが規定値より大きい場合に、実行応答は、共有情報格納領域に格納することなく、インターネット１０２上のアウトバンドのパケット１００８として、返送される。

図１１は、例として、サーバ１０９のＤＢＭＳＰｒｏｇｒａｍ４０３が管理するＬｏｃａｌＤＢ４０７が、他のサーバに複製されている構成を示す。ＬｏｃａｌＤＢ４０７が、長大なデータを多く保持している場合に、本構成例は好適である。

サーバ１０９のＤＢＭＳＰｒｏｇｒａｍ４０３は、ブロックチェーン・ネットワークの信頼関係１１０９、１１１０を有するサーバ１０７、１０８が、ＬｏｃａｌＤＢ４０７の複製を持つように動作する。本例において、サーバ１０７、１０８は、サーバ１０９のＰｅｅｒＬｉｓｔ５０２に記載の全てのサーバである。サーバ１０７、１０８は、ＰｅｅｒＬｉｓｔ５０２内のサーバの一部でもよい。

サーバ１０９のＤＢＭＳＰｒｏｇｒａｍ４０３が、サーバ１０９のＳｅｒｖｅｒＡｐｐｌｉｃａｔｉｏｎＰｒｏｇｒａｍ４０１へ、クエリの実行結果を返す場合、ＬｏｃａｌＤＢ４０７の複製を持つサーバの情報をクエリの実行結果に含める。本例において、サーバ１０９は、サーバ１０９のＰｅｅｒＬｉｓｔ５０２を実行結果としてＰａｙｌｏａｄに含める。ＬｏｃａｌＤＢ４０７の複製を有するサーバが、ＰｅｅｒＬｉｓｔ５０２の一部のサーバである場合、当該一部のサーバのリストが含められる。

これにより、クエリ応答を取得したＳｅｒｖｅｒＡｐｐｌｉｃａｔｉｏｎＰｒｏｇｒａｍ４０１は、クエリ応答が保持するＰｅｅｒＬｉｓｔ５０２にある、サーバ１０９のＬｏｃａｌＤＢ４０７の複製を有する他サーバからもクエリ結果を得るように動作できる。１台以上の他サーバからも並列にクエリ結果を得られるようになるので、クエリ結果の取得時間を短縮し、ＩＴリソースによる性能の頭打ちを軽減し、性能を向上できる。以下、各プログラムの動作の詳細を説明する。

図１２は、ＳｅｒｖｅｒＡｐｐｌｉｃａｔｉｏｎＰｒｏｇｒａｍ４０１の動作フロー例である。ＳｅｒｖｅｒＡｐｐｌｉｃａｔｉｏｎＰｒｏｇｒａｍ４０１は、まず、動作ブロック１２０１を実行する。動作ブロック１２０１にて、ＥｎｄＵｓｅｒＤｅｖｉｃｅ１１０からのデータベース問合せ要求を受信し、動作ブロック１２０２を実行する。

動作ブロック１２０２にて、ＳｅｒｖｅｒＡｐｐｌｉｃａｔｉｏｎＰｒｏｇｒａｍ４０１は、ＤＢＴａｂｌｅＬｉｓｔ６０１を参照して、当該データベース問合せと連番を合わせたレコードを生成し、自サーバのＢＣＳｅｒｖｉｃｅＰｒｏｇｒａｍ４０２に、当該レコードと共にトランザクション送信を要求する。トランザクション送信は、自サーバのＭａｎａｇｅｍｅｎｔＤＢ４０６のＢＣＴｒａｎｓａｃｔｉｏｎＰａｙｌｏａｄｆｏｒＤＢＩｎｑｕｉｒｙ６０３に情報を書き込む要求である。

ＳｅｒｖｅｒＡｐｐｌｉｃａｔｉｏｎＰｒｏｇｒａｍ４０１は、次に、動作ブロック１２０３を実行する。動作ブロック１２０３にて、ＳｅｒｖｅｒＡｐｐｌｉｃａｔｉｏｎＰｒｏｇｒａｍ４０１は、自サーバのＢＣＳｅｒｖｉｃｅＰｒｏｇｒａｍ４０２に、ＭａｎａｇｅｍｅｎｔＤＢ４０６のＢＣＴｒａｎｓａｃｔｉｏｎＰａｙｌｏａｄｆｏｒＤＢＩｎｑｕｉｒｙＲｅｓｐｏｎｓｅ６０４からのトランザクション受信を要求する。当該トランザクション受信の要求は、Ｐａｙｌｏａｄ６０４の内容（情報）の取得要求である。

当該Ｐａｙｌｏａｄ６０４が保持する連番が、上記トランザクション送信要求されたＴｒａｎｓａｃｔｉｏｎＰａｙｌｏａｄｆｏｒＤＢＩｎｑｕｉｒｙ６０３の連番と異なる場合は、ＳｅｒｖｅｒＡｐｐｌｉｃａｔｉｏｎＰｒｏｇｒａｍ４０１は、トランザクション受信の要求を繰り返し、動作ブロック１２０４を実行する。

動作ブロック１２０４にて、ＳｅｒｖｅｒＡｐｐｌｉｃａｔｉｏｎＰｒｏｇｒａｍ４０１は、上記ＤＢＴｒａｎｓａｃｔｉｏｎＰａｙｌｏａｄｆｏｒＤＢＩｎｑｕｉｒｙＲｅｓｐｏｎｓｅ６０４が保持する実行結果を、ＥｎｄＵｓｅｒＤｅｖｉｃｅ１１０へ送信し、終了する。以上により、ＥｎｄＵｓｅｒＤｅｖｉｃｅ１１０に対して、データベース管理サービスを提供できる。

図１３は、ＢＣＳｅｒｖｉｃｅＰｒｏｇｒａｍ４０２の動作フロー例である。ＢＣＳｅｒｖｉｃｅＰｒｏｇｒａｍ４０２は、まず、動作ブロック１３０１を実行する。動作ブロック１３０１にて、ＢＣＳｅｒｖｉｃｅＰｒｏｇｒａｍ４０２は、受信した要求がＢＣトランザクション送信か否か判定する。ＢＣトランザクション送信であれば、ＢＣＳｅｒｖｉｃｅＰｒｏｇｒａｍ４０２は、動作ブロック１３０２を実行する。そうでなければ、ＢＣＳｅｒｖｉｃｅＰｒｏｇｒａｍ４０２は、動作ブロック１３０４を実行する。

動作ブロック１３０２にて、ＢＣＳｅｒｖｉｃｅＰｒｏｇｒａｍ４０２は、受け取ったデータを、自サーバのＭａｎａｇｅｍｅｎｔＤＢ４０６のＢＣＴｒａｎｓａｃｔｉｏｎＰａｙｌｏａｄｆｏｒＤＢＩｎｑｕｉｒｙ６０３のＰａｙｌｏａｄとして書き込み、動作ブロック１３０３を実行する。動作ブロック１３０３にて、自サーバのＭａｎａｇｅｍｅｎｔＤＢ４０６の変更内容を、ＰｅｅｒＬｉｓｔ５０２にある全てのサーバのＢＣＳｅｒｖｉｃｅＰｒｏｇｒａｍ４０２へ送信し、終了する。

動作ブロック１３０４にて、ＢＣＳｅｒｖｉｃｅＰｒｏｇｒａｍ４０２は、他のサーバのＢＣＳｅｒｖｉｃｅＰｒｏｇｒａｍ４０２から受信したＭａｎａｇｅｍｅｎｔＢＤ４０６の変更内容を、自サーバのＭａｎａｇｅｍｅｎｔＤＢ４０６へ反映する。ＢＣＳｅｒｖｉｃｅＰｒｏｇｒａｍ４０２は、ＰｅｅｒＬｉｓｔ５０２にあるサーバのＢＣＳｅｒｖｉｃｅＰｒｏｇｒａｍ４０２へ、変更内容を転送し、動作ブロック１３０５を実行する。これにより、ＰｅｅｒＬｉｓｔ５０２が示す信頼関係を介して、ＭａｎａｇｅｍｅｎｔＢＤ４０６の変更内容が、ブロックチェーン・ネットワークの全てのサーバに伝播する。

動作ブロック１３０５にて、ＢＣＳｅｒｖｉｃｅＰｒｏｇｒａｍ４０２は、受信した要求がＢＣトランザクション受信か否かを判定する。ＢＣトランザクション受信であれば、ＢＣＳｅｒｖｉｃｅＰｒｏｇｒａｍ４０２は、動作ブロック１３０６を実行する。そうでなければ、ＢＣＳｅｒｖｉｃｅＰｒｏｇｒａｍ４０２は、フローを終了する。

動作ブロック１３０６にて、ＢＣＳｅｒｖｉｃｅＰｒｏｇｒａｍ４０２は、ＭａｎａｇｅｍｅｎｔＤＢ４０６内の指定されたＢＣＴｒａｎｓａｃｔｉｏｎＰａｙｌｏａｄｆｏｒＤＢＩｎｑｕｉｒｙＲｅｓｐｏｎｓｅ６０４のＰａｙｌｏａｄ（内容）を、呼び出し元のプログラムに応答し、終了する。なお、ＢＣＳｅｒｖｉｃｅＰｒｏｇｒａｍ４０２は、ＭａｎａｇｅｍｅｎｔＤＢ４０６内の指定されたＰａｙｌｏａｄが更新されるのを待ってもよい。

図１４は、ＤＢＭＳＰｒｏｇｒａｍ４０３の動作フロー例である。ＤＢＭＳＰｒｏｇｒａｍ４０３は、まず、動作ブロック１４０１を実行する。動作ブロック１４０１は、自サーバのＭａｎａｇｅｍｅｎｔＤＢ４０６内のＢＣＴｒａｎｓａｃｔｉｏｎＰａｙｌｏａｄｆｏｒＤＢＩｎｑｕｉｒｙ６０３について、ＢＣＳｅｒｖｉｃｅＰｒｏｇｒａｍ４０２に、トランザクション受信を要求する。

ＤＢＭＳＰｒｏｇｒａｍ４０３は、ＢＣＴｒａｎｓａｃｔｉｏｎＰａｙｌｏａｄｆｏｒＤＢＩｎｑｕｉｒｙ６０３から、データ種別、データベース問合せ、連番を取得する。データ種別が、「ＤＢＭＳ」でなければ、ＤＢＭＳＰｒｏｇｒａｍ４０３は、繰り返しトランザクション受信を要求し、動作ブロック１４０２を実行する。

また、ＤＢＭＳＰｒｏｇｒａｍ４０３は、ＬｏｃａｌＡｃｃｏｕｎｔＬｉｓｔ５０３を参照し、アクセス先が自ら管理しているテーブルであるか判定する。自ら管理するテーブルではない場合、ＤＢＭＳＰｒｏｇｒａｍ４０３は、繰り返しトランザクション受信を要求し、動作ブロック１４０２を実行する。

動作ブロック１４０２にて、ＤＢＭＳＰｒｏｇｒａｍ４０３は、上記データベース問合せを、ＬｏｃａｌＤＢ４０７に対して実行し、結果を得て、動作ブロック１４０３を実行する。動作ブロック１４０３にて、ＤＢＭＳＰｒｏｇｒａｍ４０３は、当該結果とＢＣＴｒａｎｓａｃｔｉｏｎＰａｙｌｏａｄｆｏｒＤＢＩｎｑｕｉｒｙ６０３が保持する連番を合わせて、ＭａｎａｇｅｍｅｎｔＤＢ４０６内のＢＣＴｒａｎｓａｃｔｉｏｎＰａｙｌｏａｄｆｏｒＤＢｉｎｑｕｉｒｙＲｅｓｐｏｎｓｅ６０４のＰａｙｌｏａｄとして、ＢＣＳｅｒｖｉｃｅＰｒｏｇｒａｍ４０２へトランザクション送信を要求し、終了する。

図１５は、ＥｎｄＵｓｅｒＤｅｖｉｃｅＡｐｐｌｉｃａｔｉｏｎＰｒｏｇｒａｍ８０６の動作フローである。ＥｎｄＵｓｅｒＤｅｖｉｃｅＡｐｐｌｉｃａｔｉｏｎＰｒｏｇｒａｍ８０６は、まず、動作ブロック１５０１を実行する。動作ブロック１５０１にて、ＥｎｄＵｓｅｒＤｅｖｉｃｅＡｐｐｌｉｃａｔｉｏｎＰｒｏｇｒａｍ８０６は、ＵｓｅｒＩＦ経由で入力されたデータベース問合せを、例えば、サーバ１０５のＳｅｒｖｅｒＡｐｐｌｉｃａｔｉｏｎＰｒｏｇｒａｍ４０１（ａｃｃｅｓｓｉｎｇｔｏＤＢ（Ｘ））へ送信し、動作ブロック１５０２を実行する。

動作ブロック１５０２にて、ＥｎｄＵｓｅｒＤｅｖｉｃｅＡｐｐｌｉｃａｔｉｏｎＰｒｏｇｒａｍ８０６は、サーバ１０５のＳｅｒｖｅｒＡｐｐｌｉｃａｔｉｏｎＰｒｏｇｒａｍ４０１（ａｃｃｅｓｓｉｎｇｔｏＤＢ（Ｘ））からの応答を、ＵｓｅｒＩＦ経由で表示して、終了する。

以上で、本実施例のシステム構成及び動作を説明した。本実施例により、サプライチェーンに参加する企業のサーバは、ブロックチェーン・ネットワークへの参加することで、ブロックチェーン・ネットワークに参加する他のサーバのデータベースにアクセスできるようになる。これにより、ＤＢＭＳプログラムに、サーバ・アプリケーション・プログラムをサポートするためのプログラム追加も不要なり、サプライチェーンに参加のためのシステム構築が容易になり、ビジネスのアジリティ向上が期待できる。

多数の企業に散在するアプリケーションから共有される長大なデータに関しては、特定のローカル・データベースに保持されると、個々の企業のＩＴインフラ（例えば、サーバ、データストレージ、ネットワーク）の性能に制限される。本実施例の構成は、複数のローカル・データベースに分散してデータを格納することができるので、長大な共有データへのアクセス性能の向上が期待できる。

なお、ローカル・データベース及び管理データベースが保持するデータは、暗号化やデータ圧縮されていてもよく、その場合、データが処理される前に暗号や圧縮が復号される手段が備わっていればよい。

ＤＢＭＳプログラムは、リレーショナル・データベース管理システム（ＲＤＢＭＳ）が、一般的に採用され、その場合のクエリ情報は、ＳＱＬ言語により表現される。ＲｅｐｒｅｓｅｎｔａｔｉｏｎａｌＳｔａｔｅＴｒａｎｓｆｅｒインターフェスを採用するＫｅｙＶａｌｕｅＳｔｏｒａｇｅ（又は、ＯｂｊｅｃｔＳｔｏｒａｇｅ）を、ＤＢＭＳに採用する場合、クエリ情報は、ＲＥＳＴＡｐｐｌｉｃａｔｉｏｎＰｒｏｇｒａｍｍｉｎｇＩｎｔｅｒｆａｃｅで表記されたものでもよい。

また、ＨＴＴＰプロトコルを採用するＷｅｂサーバをＤＢＭＳプログラムとして採用する場合、クエリ情報として、ＨＴＭＬ（ＨｙｐｅｒＴｅｘｔＭａｒｋｕｐＬａｎｇｕａｇｅ）で表現されたものでもよい。クエリ情報は、それぞれ、採用するデータベース管理システム・プログラムの仕様に合わせたものを、使用すればよい。

本実施例のデータベースへのアクセスは、サプライチェーンとは異なるシステムに適用することができる。いずれのシステムにおいても、本実施例により、ブロックチェーン・ネットワークへの参加することで、迅速にかつ容易に他のサーバのデータベースにアクセスできるようになる。また、システムは、ブロックチェーン技術とは異なる技術により、データベース管理サービスの提供のための情報を共有してもよい。

ＢＣＴｒａｎｓａｃｔｉｏｎＰａｙｌｏａｄｆｏｒＤＢＩｎｑｕｉｒｙ６０３及びＢＣＴｒａｎｓａｃｔｉｏｎＰａｙｌｏａｄｆｏｒＤＢＩｎｑｕｉｒｙＲｅｓｐｏｎｓｅ６０４に代わり、一般的なオペレーティング・システム・プログラムにおいてプロセスを管理や制御するために採用されるプロセス制御ブロックのデータ形式を採用してもよい。

ＳｅｒｖｅｒＡｐｐｌｉｃａｔｉｏｎＰｒｏｇｒａｍ４０１からのクエリを実行するプロセスとして、ＢＣＳｅｒｖｉｃｅＰｒｏｇｒａｍ４０２を介して、他のＳｅｒｖｅｒともクエリを共有する。他のサーバは、プロセス制御ブロックの内容に基づき、クエリを実行するためのプロセスを起動する。

これにより、データベース管理システム以外のプログラムでも、迅速に、複数のサーバで共有し使用することができるようになる。なお、ここで記載の「プロセス」は、「ジョブ」、「タスク」、「スレッド」と読み替えてもよい。また、「プロセス制御ブロック」を、一般的なネットワーク・バランサ・プログラムで採用される「イベント制御ブロック」とも、読み替えてもよい。

図１６は、実施例２のシステム構成例を示す。本システム構成例は、実施例１のシステム構成例と異なり、ＬｏｃａｌＤＢ４０７をＤＢＭＳＰｒｏｇｒａｍ４０３で管理せず、ブロックチェーン・プラットフォームで管理する。図１６は、本実施例のシステム構成例における主なデータの流れを示している。

本構成例において、サーバ１０９は、二つのブロックチェーン・ネットワーク１０３及び２０３に接続されている。本構成例において、実施例１におけるＤＢＭＳＰｒｏｇｒａｍ４０３の代わりに、ＲｅｌａｙＰｒｏｇｒａｍ４０４が動作する。ＲｅｌａｙＰｒｏｇｒａｍ４０４は、異なるブロックチェーン・ネットワーク間で、ＢＣトランザクションを仲介するプログラムモジュールである。ＲｅｌａｙＰｒｏｇｒａｍ４０４を指示する破線矩形内には、ＲｅｌａｙＰｒｏｇｒａｍ４０４の機能が示されている。

サーバ１０９は、さらに、実施例１の構成に加えて、ブロックチェーン・ネットワーク２０３でのＢＣトランザクションのためのＢＣＳｅｒｖｉｃｅＰｒｏｇｒａｍ４１２を有する。図１６は示していないが、サーバ１０９は、ブロックチェーン・ネットワーク１０３及び２０３のそれぞれに対して、ＳｅｒｖｅｒＣｏｎｆｉｇｕｒａｔｉｏｎｄＡＴＡ４０５及びＭａｎａｇｅｍｅｎｔＤＢ４０６を有する。ブロックチェーン・ネットワーク２０３用のＭａｎａｇｅｍｅｎｔＤＢ４０６は、第２の共有情報格納領域である。ＤＢＴａｂｌｅＬｉｓｔ６０１は、ブロックチェーン・ネットワーク１０３及び２０３に共通であり、双方のテーブルを示す。

図１７は、ＲｅｌａｙＰｒｏｇｒａｍ４０４の動作フロー例である。ここでは、ブロックチェーン・ネットワーク１０３からクエリのアクセス先が、ブロックチェーン・ネットワーク２０３に含まれるサーバ（第３のサーバ）のＬｏｃａｌＤＢであり、ブロックチェーン・ネットワーク２０３に転送される。また、ブロックチェーン・ネットワーク２０３からのクエリ応答が、ブロックチェーン・ネットワーク１０３に転送される。

ＲｅｌａｙＰｒｏｇｒａｍ４０４は、まず、動作ブロック１７０１を実行する。動作ブロック１７０１にて、ＲｅｌａｙＰｒｏｇｒａｍ４０４は、ブロックチェーン・ネットワーク１０３のＢＣＳｅｒｖｉｃｅＰｒｏｇｒａｍ４０２に、ＭａｎａｇｅｍｅｎｔＤＢ４０６内のＢＣＴｒａｎｓａｃｔｉｏｎＰａｙｌｏａｄｆｏｒＤＢＩｎｑｕｉｒｙ６０３について、トランザクション受信を要求する。

ＲｅｌａｙＰｒｏｇｒａｍ４０４は、当該ＢＣＴｒａｎｓａｃｔｉｏｎＰａｙｌｏａｄｆｏｒＤＢＩｎｑｕｉｒｙ６０３から、データ種別、データベース問合せ、連番を取得する。ＢＣＴｒａｎｓａｃｔｉｏｎＰａｙｌｏａｄｆｏｒＤＢＩｎｑｕｉｒｙ６０３からの情報を得るまで、ＲｅｌａｙＰｒｏｇｒａｍ４０４は、繰り返しトランザクション受信を要求し、動作ブロック１７０２を実行する。

動作ブロック１７０２にて、ＲｅｌａｙＰｒｏｇｒａｍ４０４は、当該ＢＣＴｒａｎｓａｃｔｉｏｎＰａｙｌｏａｄｆｏｒＤＢＩｎｑｕｉｒｙ６０３が保持するクエリを、他のブロックチェーン・ネットワーク２０３へＢＣトランザクションとして転送し、動作ブロック１７０３を実行する。

具体的には、ＲｅｌａｙＰｒｏｇｒａｍ４０４は、ブロックチェーン・ネットワーク２０３のＤＢＴａｂｌｅＬｉｓｔ６０１を参照して、アクセス先がブロックチェーン・ネットワーク２０３のＬｏｃａｌＤＢであると判定する。ＲｅｌａｙＰｒｏｇｒａｍ４０４は、取得したクエリをブロックチェーン・ネットワーク２０３用のＭａｎａｇｅｍｅｎｔＤＢ４０６のＢＣＴｒａｎｓａｃｔｉｏｎＰａｙｌｏａｄｆｏｒＤＢＩｎｑｕｉｒｙ６０３に書き込むため、ブロックチェーン・ネットワーク２０３のＢＣＳｅｒｖｉｃｅＰｒｏｇｒａｍ４１２に、トランザクション送信を要求する。

ＢＣＳｅｒｖｉｃｅＰｒｏｇｒａｍ４１２は、ブロックチェーン・ネットワーク２０３のＰｅｅｒＬｉｓｔ５０２のサーバに、ＭａｎａｇｅｍｅｎｔＤＢ４０６の更新を送信する。

動作ブロック１７０３にて、ＲｅｌａｙＰｒｏｇｒａｍ４０４は、ブロックチェーン・ネットワーク２０３のＢＣＳｅｒｖｉｃｅＰｒｏｇｒａｍ４１２に、ブロックチェーン・ネットワーク２０３用のＢＣＴｒａｎｓａｃｔｉｏｎＰａｙｌｏａｄｆｏｒＤＢＩｎｑｕｉｒｙＲｅｓｐｏｎｓｅ６０４からの、ＢＣトランザクション受信を要求する。ＲｅｌａｙＰｒｏｇｒａｍ４０４は、上記クエリに対する応答（上記トランザクション送信の結果）を取得する。

さらに、ＲｅｌａｙＰｒｏｇｒａｍ４０４は、上記トランザクション送信の結果と、ブロックチェーン・ネットワーク１０３のＢＣＴｒａｎｓａｃｔｉｏｎＰａｙｌｏａｄｆｏｒＤＢＩｎｑｕｉｒｙ６０３が保持する連番とを合わせたレコードを生成する。

ＲｅｌａｙＰｒｏｇｒａｍ４０４は、当該レコードを、ブロックチェーン・ネットワーク１０３のＭａｎａｇｅｍｅｎｔＤＢ４０６内のＢＣＴｒａｎｓａｃｔｉｏｎＰａｙｌｏａｄｆｏｒＤＢｉｎｑｕｉｒｙＲｅｓｐｏｎｓｅ６０４に書き込む。具体的には、ＲｅｌａｙＰｒｏｇｒａｍ４０４は、ブロックチェーン・ネットワーク１０３のＢＣＳｅｒｖｉｃｅＰｒｏｇｒａｍ４０２へ、当該レコードについてトランザクション送信を要求する。その後、ＲｅｌａｙＰｒｏｇｒａｍ４０４は、終了する。

上述のように、本実施例は、異なるブロックチェーン・ネットワーク（異なるブロックチェーン技術による他の情報共有グループ）と情報を共有するため、クエリ情報を、異種のブロックチェーン技術を採用したプログラムモジュールのアプリケーション・プログラミング・インターフェイス（ＡＰＩ）へ変換するＲｅｌａｙＰｒｏｇｒａｍを備える。

本実施例により、異なるブロックチェーン・ネットワークのデータベースのアクセスも可能になり、システム構築のアジリティ向上の他、柔軟性向上の期待もできる。具体的には、本実施例により、異種ブロックチェーン技術の混在する環境での情報共有において、サーバ・アプリケーション・プログラムは、違いを考慮することなく動作が可能となり、サーバ・アプリケーション・プログラムの改変も不要であり、多様な業務への対応が容易となる。

なお、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明したすべての構成を備えるものに限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることも可能である。また、各実施例の構成の一部について、他の構成の追加・削除・置換をすることが可能である。

また、上記の各構成・機能・処理部等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ（ＳｏｌｉｄＳｔａｔｅＤｒｉｖｅ）等の記録装置、または、ＩＣカード、ＳＤカード等の記録媒体に置くことができる。また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしもすべての制御線や情報線を示しているとは限らない。実際には殆どすべての構成が相互に接続されていると考えてもよい。

１０１：サプライチェーンの範囲を模式的に示す境界線
１０２：Ｉｎｔｅｒｎｅｔ
１０３：ブロックチェーン・ネットワーク（ＢｌｏｃｋｃｈａｉｎＮｅｔｗｏｒｋ）
１０４、１０５、１０６、１０７、１０８、１０９：サーバ（Ｓｅｒｖｅｒ）
１１０：エンド・ユーザ・デバイス（ＥｎｄＵｓｅｒＤｅｖｉｃｅ）
１１５：操作の流れ
１１６、１１７：クエリの流れ
１１８：信頼関係
４０１：サーバ・アプリケーション・プログラム（ＳｅｒｖｅｒＡｐｐｌｉｃａｔｉｏｎＰｒｏｇｒａｍ）
２０３：異種のブロックチェーン・ネットワーク
３０１：サーバ（Ｓｅｒｖｅｒ）
３０２：マイクロプロセッサ・ユニット（ＭＰＵ）
３０３：メモリ（Ｍｅｍｏｒｙ）
３０４：ネットワーク・インタフェース・カード（ＮＩＣ）
３０５：データバス
４０２：ＢＣサービス・プログラム（ＢＣＳｅｒｖｉｃｅＰｒｏｇｒａｍ）
４０３：ＤＢＭＳプログラム（ＤＢＭＳＰｒｏｇｒａｍ）
４０４：リレー・プログラム（ＲｅｌａｙＰｒｏｇｒａｍ）
４０５：サーバ構成データ（ＳｅｒｖｅｒＣｏｎｆｉｇｕｒａｔｉｏｎＤａｔａ）
４０６：管理データベース（ＭａｎａｇｅｍｅｎｔＤＢ）
４０７：ローカル・データベース（ＬｏｃａｌＤＢ）
５０１：データベース識別情報（ＤａｔａｂａｓｅＩＤ）
５０２：データＴａｂｌｅ「信頼一覧」（ＰｅｅｒＬｉｓｔ）
５０３：データＴａｂｌｅ「ローカル・アカウント一覧」
６０１：ＤＢＴａｂｌｅ「データベース・テーブル一覧」
６０２：ＤＢＴａｂｌｅ「グローバル・アカウント一覧」
６０３：クエリ情報（Ｉｎｑｕｉｒｙ）
６０４：レスポンス情報（Ｒｅｓｐｏｎｓｅ）
６０５、６０９：データ種別（ＤａｔａＫｉｎｄ）
６０６：データベースクエリ情報（ＤＢＩｎｑｕｉｒｙ）
６０７：応答先情報（ＲｅｓｐｏｎｓｅＤｅｓｔｉｎａｔｉｏｎ）
６０８、６１１：クエリ識別情報（ＤＢＩｎｑｕｉｒｙＩＤ）
６１０：クエリ応答情報（ＤＢＩｎｑｕｉｒｙＲｅｓｐｏｎｓｅ）
７０１：ＤＢＴａｂｌｅ「ＡＡＡ」
７０１：ＤＢＴａｂｌｅ「ＢＢＢ」
８０１：マイクロプロセッサ・ユニット（ＭＰＵ）
８０２：メモリ（Ｍｅｍｏｒｙ）
８０３：ネットワーク・インタフェース・カード（ＮＩＣ）
８０４：ユーザ・インタフェース（ＵｓｅｒＩＦ）
８０５：データバス
８０６：エンド・ユーザ・デバイス・アプリケーション・プログラム（ＥｎｄＵｓｅｒＤｅｖｉｃｅＡｐｐｌｉｃａｔｉｏｎＰｒｏｇｒａｍ）
８０７：デバイス構成データ（ＤｅｖｉｃｅＣｏｎｆｉｇｕｒａｔｉｏｎＤａｔａ）
９０１：データＴａｂｌｅ「アプリケーション・アカウント一覧」
１００１：クエリのためのＢＣトランザクション・パケット（ＢＣＴｒａｎｓａｃｔｉｏｎＰａｃｋｅｔｆｏｒＩｎｑｕｉｒｙ）
１００２：ＢＣトランザクション・パケットのペイロード（ＢＣＴｒａｎｓａｃｔｉｏｎＰａｙｌｏａｄ）
１００３：データ種別（ＤａｔａＫｉｎｄ）
１００４：クエリ（ＤＢＩｎｑｕｉｒｙ）
１００５：応答先（ＲｅｓｐｏｎｓｅＤｅｓｔｉｎａｔｉｏｎ）
１００６：クエリ識別情報（ＤＢＩｎｑｕｉｒｙＩＤ）
１００７：クエリ応答のためのＢＣトランザクション・パケット（ＢＣＴｒａｎｓａｃｔｉｏｎＰａｃｋｅｔｆｏｒｉｎｑｕｉｒｙｒｅｓｐｏｎｓｅ）
１００８：アウトバンドによるクエリ結果のパケット（ＯｕｔｂｏｕｎｄＰａｃｋｅｔｆｏｒＩｎｑｕｉｒｙＲｅｓｕｌｔ）
１１０１：信頼一覧を保持したＢＣトランザクション・パケット（ＢＣＴｒａｎｓａｃｔｉｏｎＰａｃｋｅｔｆｏｒＰｅｅｒＬｉｓｔ）
１１０２、１１０３、１１０４：クエリ結果の流れ
１１０９、１１１０：信頼関係
１２０１：異種のＢＣトランザクション・パケット

Claims

複数のサーバ及び１以上のデータベースを含む、データベース管理サービス提供システムであって、
前記複数のサーバは、
第１のサーバと、
第２のサーバと、を含み、
前記複数のサーバの各サーバは、他のサーバと共有する情報を格納する共有情報格納領域を含み、
前記複数のサーバは、前記共有情報格納領域のデータを一致させるように動作し、
前記第１のサーバは、第１のローカル・データベースを管理し、
前記第２のサーバは、
前記第１のローカル・データベースへのアクセスのためのクエリ情報を生成し、
前記クエリ情報を、前記第２のサーバの前記共有情報格納領域に格納し、
前記第１のサーバは、
前記第１のサーバの前記共有情報格納領域から前記クエリ情報を取得し、
前記クエリ情報に対する結果を前記第１のサーバの前記共有情報格納領域に格納し、
前記第２のサーバは、前記第２のサーバの前記共有情報格納領域から前記結果を取得する、データベース管理サービス提供システム。
請求項１に記載のデータベース管理サービス提供システムであって、
前記共有情報格納領域は、前記複数のサーバが管理する複数のデータベースについての情報を格納している、データベース管理サービス提供システム。
請求項１に記載のデータベース管理サービス提供システムであって、
前記複数のサーバの各サーバは、前記複数のサーバにおいて通信を行う他のサーバのリストを保持し、
前記複数のサーバの各サーバは、前記共有情報格納領域における更新を前記リストに示される前記他のサーバに送信する、データベース管理サービス提供システム。
請求項１に記載のデータベース管理サービス提供システムであって、
前記第２のサーバは、
エンド・ユーザ・デバイスからの指示に応答して前記クエリ情報を生成し、
前記第２のサーバの前記共有情報格納領域から取得した前記結果を前記エンド・ユーザ・デバイスに送信する、データベース管理サービス提供システム。
請求項１に記載のデータベース管理サービス提供システムであって、
前記第１のサーバは、
前記第１のサーバの前記共有情報格納領域から、前記第１のローカル・データベースに対する第２のクエリ情報を取得し、前記第２のクエリ情報は、クエリ結果の送り先情報を含み、
前記第２のクエリ情報の結果を前記第１のサーバの前記共有情報格納領域に格納することなく、前記送り先情報が示すサーバに前記第２のクエリ情報の結果を送信する、データベース管理サービス提供システム。
請求項１に記載のデータベース管理サービス提供システムであって、
前記複数のサーバにおける前記第１のサーバと異なる１以上のサーバが、前記第１のローカル・データベースの複製を管理し、
前記第１のサーバは、
前記第１のサーバの前記共有情報格納領域から、前記第１のローカル・データベースに対する第３のクエリ情報を取得し、
前記１以上のサーバの情報を含む前記第３のクエリ情報の結果を、前記第１のサーバの前記共有情報格納領域に格納する、データベース管理サービス提供システム。
請求項１に記載のデータベース管理サービス提供システムであって、
前記共有情報格納領域は第１の共有情報格納領域であり、
前記第１のサーバは、
第２のデータベース管理サービス提供システムに含まれ、
前記第２のデータベース管理サービス提供システムの他のサーバと共有する情報を格納する第２の共有情報格納領域を含み、
前記第１のサーバの前記第１の共有情報格納領域から、前記第２のデータベース管理サービス提供システムに含まれる第３のサーバが管理する第３のローカル・データベースに対する第４のクエリ情報を取得し、
前記第１のサーバの前記第２の共有情報格納領域に前記第４のクエリ情報を格納し、
前記第１のサーバの前記第２の共有情報格納領域から前記第４のクエリ情報に対する結果を取得し、
前記第４のクエリ情報に対する結果を前記第１のサーバの前記第１の共有情報格納領域に格納する、データベース管理サービス提供システム。
複数のサーバ及び１以上のデータベースを含むシステムによる、データベース管理サービス提供方法であって、
前記複数のサーバは、
第１のサーバと、
第２のサーバと、を含み、
前記複数のサーバの各サーバは、他のサーバと共有する情報を格納する共有情報格納領域を含み、
前記複数のサーバは、前記共有情報格納領域のデータを一致させるように動作し、
前記データベース管理サービス提供方法は、
前記第１のサーバが、第１のローカル・データベースを管理し、
前記第２のサーバが、前記第１のローカル・データベースへのアクセスのためにクエリ情報を生成し、
前記第２のサーバが、前記クエリ情報を、前記第２のサーバの前記共有情報格納領域に格納し、
前記第１のサーバが、前記第１のサーバの前記共有情報格納領域から前記クエリ情報を取得し、
前記第１のサーバが、前記クエリ情報に対する結果を前記第１のサーバの前記共有情報格納領域に格納し、
前記第２のサーバが、前記第２のサーバの前記共有情報格納領域から前記結果を取得する、データベース管理サービス提供方法。