JP4729683B2 - データ分散格納装置、そのデータ構成管理サーバ、クライアント端末、および、データ分散格納装置を備えた業務委託システム - Google Patents

Description

本発明は、特に、関係データベースのデータを分散して格納する装置、および、これを利用した業務委託システムに関する。

従来から、企業の業務データなどを関係データベース管理システムで管理することが行われている。業務データが膨大なデータ量になる場合、関係一時テーブル管理機能の処理負担などを考慮し、図１１（ａ）に示すように、複数の関係一時テーブル管理機能１０１と管理用サーバ１０２とを備える分散データベースシステム１００を構築することが多い（例えば、特許文献１参照）。

特開２００３−２２８５０８号公報

しかしながら、上記のような分散データベースシステム１００では、個々の関係一時テーブル管理機能１０１ごとにテーブルの残り領域などを管理する必要があり、テーブル領域を拡張する場合、記憶装置を追加して関係一時テーブル管理機能１０１などの設定を変更しなければならない。また、関係一時テーブル管理機能１０１のアップデートや業務データのバックアップも個々の関係データベースごとに行う必要がある。このため、分散データベースシステム１００は、システムの運用コストが高く、メンテナンスに手間を要するという問題があった。

さらに、分散データベースシステム１００は、個々の関係一時テーブル管理機能１０１がネットワーク１０３を介して管理サーバに接続されており、不正アクセスされ易い。もし、いずれかの一時テーブル管理機能１０１のセキュリティが破られると、分散データベースシステム１００は、個々の関係一時テーブル管理機能１０１が、図１１（ｂ）に関係データベースを概念的に示すように、実体データＡからなるテーブル１０４の形で有するため、業務データの意味内容が外部に漏れるという問題があった。

一方、例えば、業務を外部委託する委託元企業が委託先企業に業務データを貸与し、委託先企業が貸与された業務データを分散データベースシステム１００で運用する場合、委託先企業のオペレータなどがクライアント端末１０５を用いてソーシャルエンジニアリングなどの不正アクセスを行う恐れが有り、このような事態を防止することも求められていた。

そこで、本発明の課題は、メンテナンスが容易であると共に、不正アクセスに対する安全性の高いデータ分散格納装置および業務委託システムを提供することにある。

上記課題を解決するため、本発明に係る参考の手段として、データ分散格納装置を、関係データベースの実体データを属性ごとに分けて格納されるデータ格納サーバ群と、このデータ格納サーバ群と物理的に分離した状態で通信回線を介して接続されており、上記実体データを管理するデータ管理機能および上記実体データの格納場所情報から構成されるテーブルを管理するテーブル管理機能を有するデータ構成管理サーバとを備え、上記データ管理機能は、上記実体データを上記データ格納サーバ群に格納すると、上記実体データの格納場所情報を作成して上記テーブル管理機能に渡し、上記テーブル管理機能は、受け取った上記格納場所情報から上記テーブルを構成し、上記関係データベースを取り扱うアプリケーションから上記実体データへのアクセスを要求された場合に、上記実体データの上記格納場所情報を上記テーブルから取得して上記データ管理機能に渡し、上記データ管理機能は、受け取った上記格納場所情報を元に上記データ格納サーバ群より上記実体データを取得して上記テーブル管理機能に渡し、上記テーブル管理機能は、受け取った上記実体データを上記アプリケーションに渡すように構成した。

参考の手段のデータ分散格納装置では、上記データ格納サーバ群に関係データベースの上記実体データが属性ごとに分けて格納されるため、個々のデータ格納サーバに不正アクセスをされても、属性ごとの実体データが流出するだけとなり、上記実体データの意味内容を把握できる形で流出することがなくなる。特に、実体データにダミーデータなどを紛れ込ませておけば、大量の実体データが流出したとしても関係データベース全体を復元することが困難になる。

また、参考の手段のデータ分散格納装置では、物理的に分離された個々のデータ格納サーバごとに上記実体データが属性ごとに格納されているので、ソーシャルエンジニアリングが困難となる。なお、属性ごとにとは、レコードを構成する一属性ごとに、一つのデータ格納サーバを割り当てることのみに限定されず、属性の意味内容が無関係な組合せとなる実体データ同士をまとめて一つのデータ格納サーバに格納することも含まれる。また、物理的に分離されたとは、互いを別体のハードウェアから構成した状態をいうが、ソーシャルエンジニアリングなどに対する安全性を高めるため、本発明においては、別体のハードウェアとした上で、異なる場所（部屋、建物、地理的位置）に設置することが好ましい。

さらに、参考の手段のデータ分散格納装置では、上記データ管理機能は、上記実体データを上記データ格納サーバ群に格納すると、上記実体データの格納場所情報を作成して上記テーブル管理機能に渡し、上記テーブル管理機能は、受け取った上記格納場所情報から上記テーブルを構成し、上記関係データベースを取り扱うアプリケーションから上記実体データへのアクセスを要求された場合に、上記実体データの上記格納場所情報を上記テーブルから取得して上記データ管理機能に渡し、上記データ管理機能は、受け取った上記格納場所情報を元に上記データ格納サーバ群より上記実体データを取得して上記テーブル管理機能に渡し、上記テーブル管理機能は、受け取った上記実体データを上記アプリケーションに渡すため、上記データ構成管理サーバに不正アクセスされても、上記格納場所情報が流出するだけとなり、上記実体データが外部に漏れることを防止できる。

加えて、参考の手段のデータ分散格納装置では、上記データ構成管理サーバが上記データ格納サーバ群と物理的に分離した状態で配置されているため、ソーシャルエンジニアリングがより困難となる。

また、参考の手段のデータ分散格納装置では、上記テーブルが上記実体データの上記格納場所情報から構成されているため、上記実体データのデータサイズと無関係になる。すなわち、一格納場所情報当りのデータサイズが一定なので、上記テーブルのテーブルサイズが、単純に、上記実体データ数に比例するようになる。これにより、参考の手段のデータ分散格納装置では、上記データ構成管理サーバのテーブルサイズの試算が容易になり、装置の設計が行い易くなる。

また、参考の手段のデータ分散格納装置では、上記データ格納サーバ群にデータ格納サーバの追加や削除を行う際は、上記データ管理機能の環境設定を行うだけなので、上記データ格納サーバ群の格納容量の調整が容易になると共に、上記関係データベースの運用を停止する時間が短くなる。

特に、参考の手段のデータ分散格納装置を、上記テーブル管理機能が上記格納場所情報を上記論理的格納場所情報の形で保持し、上記データ管理機能が上記格納場所情報を物理的格納場所情報の形で保持し、両格納場所情報の対応付けを示すメタデータを保持するようにすることが好ましい。

この構成によれば、上記実体データの更新などで上記物理的格納場所情報が変化しても、上記メタデータに両格納場所情報の対応付けが示されているため、上記論理的格納場所情報を変更する必要がなくなる。これにより、参考の手段のデータ分散格納装置は、同一の上記実体データの論理的格納場所情報が変化しないようになり、上記アプリケーションに対するデータ透過性を確保することができる。

ところで、参考の手段のデータ分散格納装置では、上記データ構成管理サーバを複数設けることができる。これにより、上記データ構成管理サーバが冗長化されるので、データ分散格納装置の定常運転が容易になる。

さらに、参考の手段のデータ分散格納装置においては、上記データ構成管理サーバは、上記格納場所情報を暗号鍵にて暗号化し、上記暗号鍵の復号鍵を、少なくとも、上記データ構成管理サーバに入力される管理サーバ用復号鍵片と上記アプリケーションを利用するクライアント端末より入力される端末用復号鍵片から構成し、全ての復号鍵片が入力された状態で上記格納場所情報を復号化するように構成することができる。

この構成によれば、全ての復号鍵片が入力された状態でないと、上記格納場所情報が分からないため、不正アクセスに対する安全性がより一層高くなる。なお、上記復号鍵を、必要に応じてより多くの復号鍵片から構成することもできる。例えば、上記関係データベースを取り扱うアプリケーションが格納されたアプリケーションサーバに入力されるＡＰサーバ用復号鍵片、上記データ格納サーバ群に入力される格納サーバ用復号鍵片を加えることもできる。

上述のように参考の手段のデータ分散格納装置は、関係データベースのテーブルに実体データを保持しない。それ故、上記実体データは、上記データ管理機能および上記テーブル管理機能による処理を介して上記アプリケーションと上記データ格納サーバ群との間で受け渡しされる。したがって、参考の手段のデータ分散格納装置では、上記テーブルの規模や上記実体データの受け渡し処理量が大きくなると、装置側の処理負担が非常に大きくなり、また、上記データ構成管理サーバと上記データ格納サーバ群との間の通信負担も大きくなるので、上記アプリケーションと上記データ構成管理サーバとの間のトランザクション速度が遅くなる。

そこで、本発明は、関係データベースの実体データを格納されるデータ格納サーバ群と、このデータ格納サーバ群と物理的に分離した状態で通信回線を介して接続されており、上記実体データを保持させたテーブルを揮発性メモリ上で取り扱う一時テーブル管理機能、および上記実体データの格納場所情報を記述したメタデータを上記テーブルの構造と対応させて管理するメタデータ管理機能を含むデータ構成管理サーバとを備え、上記一時テーブル管理機能は、アプリケーションからの追加処理又は更新処理要求のＳＱＬを受けて当該処理を成す都度、バックグラウンドで、当該処理対象のレコードに保持させた実体データを属性ごと分けて上記データ格納サーバ群に格納する処理と、格納した各実体データの上記メタデータを作成して上記メタデータ管理機能に送る処理とを行い、上記一時テーブル管理機能は、上記アプリケーションからの検索処理要求のＳＱＬを受けて、上記実体データを保持させたテーブルから該当実体データを取得して当該アプリケーションに渡す処理を行い、上記一時テーブル管理機能は、上記揮発性メモリが初期化された状態で、上記メタデータ管理機能が管理するメタデータとこのメタデータの格納構造に基づいて、上記実体データを保持させたテーブルを上記揮発性メモリ上に復元する処理を行い、上記揮発性メモリが初期化されると、上記実体データを保持させたテーブルが装置から完全に消去されるデータ分散格納装置に構成した。

本発明のデータ分散格納装置では、関係データベースの実体データを属性ごとに分けて格納されるデータ格納サーバ群と、このデータ格納サーバ群と物理的に分離した状態で通信回線を介して接続されており、上記実体データを保持させたテーブルを揮発性メモリ上で取り扱う一時テーブル管理機能、および上記実体データの格納場所情報を記述したメタデータを上記テーブルの構造と対応付けて管理するメタデータ管理機能を含むデータ構成管理サーバを備えるので、例えばデータの検索時には上記実体データが上記関係データベースを取り扱うアプリケーションと上記データベースサーバとの間だけで直接的に受け渡しされる。このため、本発明のデータ分散格納装置は、上記テーブルの規模や上記実体データの受け渡し処理量が大きくなっても、上記アプリケーションと上記データ構成管理サーバとの間の処理速度が参考の手段に比べて遅くならない。

しかし、上記テーブルは、実体データを保持するので、夜間などに上記ハードディスクドライブを設置した建物に侵入された場合に実体データが意味内容を理解できる形で大量流出することになる。これを防止するための手段として、上記関係データベースの利用時間外に上記テーブルの実体データを消去してしまうことが考えられる。

従来、上記テーブルの実体データはハードディスクドライブ上に記録されているが、上記テーブルの実体データを完全に消去するには、ハードディスクドライブのオーバーライト処理を行う必要がある。この処理は、時間を要するので、管理者の手を煩わせることになる。特に、顧客管理データの関係データベースのように、日々利用されるものの場合、日々管理者が手動でテーブルの実体データを消去することは不可能に近い。

そこで本発明のデータ分散格納装置では、上記データベースサーバが上記実体データを保持させたテーブルを揮発性メモリ上で取り扱うようにし、上記実体データを属性ごとに分けて上記データ格納サーバ群に格納されるように工夫した。これにより、上記テーブルは、揮発性メモリ上に保持されるので、揮発性メモリをクリアするか、或は装置の通電が止まると消失する。このため、上記テーブルの完全消去作業は、ハードディスクドライブをオーバーライトする場合と比して極短時間で行うことができる。また、上記一時テーブル管理機能を実装したサーバ等が盗難にあってもデータ流出の心配がない。なお、上記データ格納サーバ群に関係データベースの上記実体データが属性ごとに分けて格納される点で得られる効果は、上記参考の手段のデータ分散格納装置と同じである。

しかし、本発明の手段のデータ分散格納装置では、上記テーブルが完全に消去されるので、上記テーブルの復元性を確保しなければならない。つまり、個々の実体データに対して、レコード番号、属性、セル番号、インデックス等のように上記テーブルの構造と実体データとの対応付け情報を、揮発性メモリ上のテーブルとは別のハードディスク上のテーブルにて管理しなければならなくなるが、その場合、参考の手段よりもさらに多くの情報を管理しなければならなくなり、アプリケーションからのデータ更新処理要求時の処理速度改善効果があまり期待できなくなる。

そこで、本発明のデータ分散格納装置では、上記データ構成管理サーバは、上記実体データの格納場所情報を記述したメタデータを上記テーブルの構造と対応させて管理するメタデータ管理機能を含み、上記実体データを上記データ格納サーバ群に格納すると上記メタデータを作成し、上記メタデータ管理機能が管理するメタデータとこのメタデータの格納構造に基づいて上記テーブルを上記揮発性メモリ上に復元するように構成した。これにより、上記テーブルのレコード番号、属性、セル番号、インデックス等のような上記テーブルの構造と、上記実体データとが上記メタデータ管理機能を介して対応付けられるので、上記テーブルが復元可能となる。また、上記データ構成管理サーバに不正アクセスされて、上記メタデータが流出したとしても、直接的に上記実体データが外部に漏れることは防止できる。

なお、上記実体データの上記データ格納サーバ群への格納は、上記テーブルの耐障害性を確保するために、更新等の処理がなされる都度、バックグラウンドで格納するようにすることが好ましいが、装置停止前に一括格納するようにしてもよい。

しかし、上記データ構成管理サーバと上記データ格納サーバ群の両方に不正アクセスされると、上記メタデータに基づいて上記テーブルが復元される恐れがある。このため、上記参考の手段と同様、上記メタデータを暗号化することが好ましい。

そこで、本発明のデータ分散格納装置においても、上記データ構成管理サーバは、上記メタデータ管理機能が管理するメタデータを暗号鍵にて暗号化し、上記暗号鍵の復号鍵を、少なくとも、上記データ構成管理サーバに入力される管理サーバ用復号鍵片と上記関係データベースを利用するクライアント端末より入力される端末用復号鍵片から構成し、全ての復号鍵片が入力された状態で上記メタデータを復号化するように構成することができる。

上述のように、本発明のデータ分散格納装置では、上記実体データを保持させたテーブルを揮発性メモリ上で取り扱うため、バックグラウンドで上記実体データの格納処理を行うことができる。このため、上記実体データの格納時に複雑な処理を施すことが可能になる。

そこで、本発明のデータ分散格納装置では、上記データ構成管理サーバは、属性ごとに分けた実体データを一定単位データで区切り、単位間の順序関係を可逆的に入れ替え、入れ替え法則情報を保持すると共に、この入れ替え後のスクランブルデータを分割して上記データ格納サーバ群に格納する構成を採用することが好ましい。この構成によれば、上記実体データが、上記データ格納サーバ群から流出しても、その内容を把握することが極めて困難となる。より好ましくは、上記入れ替え法則情報も上記メタデータと同様に暗号化すれば、上記入れ替え法則情報が盗まれても上記実体データの安全性がより高くなる。

また、本発明のデータ分散格納装置でも、上記データ格納サーバ群にデータ格納サーバの追加や削除を行う際は、上記データ構成管理サーバの環境設定を行うだけなので、上記データ格納サーバ群の格納容量の調整が容易になると共に、上記関係データベースの運用を停止する時間が短くなる。

また、本発明のデータ分散格納装置では、上記メタデータを、その実体データから一意に導かれる文字列からなる論理的格納場所情報と上記データ格納サーバ群への物理的格納場所情報とを対応させた構造とすることが好ましい。

この構成によれば、上記実体データの更新などで上記物理的格納場所情報が変化しても、上記論理的格納場所情報を変更する必要がなくなる。これにより、本発明のデータ分散格納装置でも、上記アプリケーションに対するデータ透過性を確保することができる。

勿論、本発明のデータ分散格納装置でも、上記データ構成管理サーバを複数設けることができる。

また、本発明では、業務委託システムを、委託元から業務を外部委託される委託先企業に配置されたクライアント端末と、上記委託元および上記委託先企業と第三者の立場にある第三者機関に配置された本発明に係るデータ分散格納装置と、このデータ分散格納装置と接続されると共に上記クライアント端末と通信回線を介して接続されたアプリケーションサーバとを備え、上記関係データベースの上記実体データが上記委託元の業務データからなり、上記関係データベースを取り扱うアプリケーションを上記アプリケーションサーバに格納している構成とした。

本発明に係る業務委託システムでは、上述のように、業務データが不正アクセスに対する安全性の高いデータ分散格納装置に格納されるので、業務データからなる上記実体データが意味内容を理解できる形で漏れることを防止できる。また、本発明に係る業務委託システムによれば、上記データ分散格納装置を第三者機関の管理下に配置したため、ソーシャルエンジニアリングに対する安全性の高い業務委託システムとなる。

以上に述べたように、本発明に係るデータ分散格納装置によれば、関係データベースの管理と実体データの管理を独立させたので、装置のメンテナンスが容易であると共に、上記実体データが流出しただけだと上記実体データの意味内容を把握することが困難である。このため、本発明に係るデータ分散格納装置は、不正アクセスに対する安全性を高めることができる。また、本発明に係るデータ分散格納装置を用いた業務委託システムによれば、業務データへの不正アクセス、特にソーシャルエンジニアリングに対する安全性の高い業務委託システムを提供できる。

以下、図１から図７を参照して上記参考の手段に係るデータ分散格納装置と業務委託システムの参考例１を説明する。図１に示すように、業務委託システム１は、委託元（図示省略）から業務を外部委託される委託先企業Ｏに配置されたクライアント端末２と、上記委託元および委託先企業Ｏと第三者の立場にある第三者機関Ｔに配置されたデータ分散格納装置３と、このデータ分散格納装置３と通信回線５で接続されると共にクライアント端末２と通信回線４を介して接続されたアプリケーションサーバ６とを備える。

データ分散格納装置３は、データ格納サーバ群３０と、このデータ格納サーバ群３０と物理的に分離された状態で通信回線３１を介して接続されたデータ構成管理サーバ３２とを備える。

通信回線４、通信回線５、通信回線３１には、例えば、双方向通信の専用線またはＩＰネットワークなどを用いることができる。

データ格納サーバ群３０は、物理的に分離した状態のデータ格納サーバ３０ａ、３０ｂ、３０ｃを有し、関係データベースの実体データＡを属性ごとに分けた実体データＡが格納されている。ここで、実体データＡは、通常の関係データベースのテーブルに保持されるデータである（図１１（ｂ）参照）。

なお、本発明においては、データ格納サーバ３０ａ、３０ｂ、３０ｃにストレージを用いることができる。しかし、実体データＡの管理を後述のデータ構成管理サーバ３２が行うので、個々のデータ格納サーバ３０ａ、３０ｂ、３０ｃにＤＢＭＳを構築する必要がない。また、個々のデータ格納サーバ３０ａ、３０ｂ、３０ｃには、属性ごとに実体データＡが格納されるだけなので、通常の関係データベース程の記憶容量を求められない。このため、データ分散格納装置３は、個々のデータ格納サーバ３０ａ、３０ｂ、３０ｃに、例えば、パーソナルコンピュータなどの装置を使用すると低コスト化を実現できる。

データ構成管理サーバ３２は、図２に示すように、実体データＡを管理するデータ管理機能３３と、実体データＡの格納場所情報から構成されるテーブル３８を管理するテーブル管理機能３４とを有し、後述の論理的格納場所情報を作成する。

データ管理機能３３は、データ格納サーバ群３０を仮想的に一元管理しており、実体データＡをデータ格納サーバ群３０に格納すると、実体データＡの格納場所情報として、データ格納サーバ群３０における実体データＡの物理的格納場所情報を作成する。

図２、図３（ａ）（ｂ）に示すように、物理的格納場所情報には、物理ファイル名３５を、論理的格納場所情報には、論理ファイル名（ＵＲＬ）３６を用いることができる。例えば、ＵＲＬ３６は、データ格納サーバ群３０を構成する各データ格納サーバに対応付けられたノード名：パス／ファイル名からなる。

また、データ管理機能３３は、物理的格納場所情報と論理的格納場所情報の対応付けを示すメタデータを作成し、メタデータファイル３７として保持する。メタデータファイル３７は、図３（ａ）に概念的に示すように、物理ファイル名３５とＵＲＬ３６を対応付けたデータファイルである。なお、データ管理機能３３は、チェックサム、データ複製情報、データサイズ、アクセス権、システムログ、更新ログなどをメタデータファイル３７に記録する。

データ管理機能３３は、ＵＲＬ３６をテーブル管理機能３４に渡し、テーブル管理機能３４から受け取ったＵＲＬ３６を元にメタデータファイル３７から物理ファイル名３５を取得し、これをファイルハンドルとして、データ格納サーバ群３０より実体データＡを取得してテーブル管理機能３４に渡す。

一方、テーブル管理機能３４は、受け取ったＵＲＬ３６からテーブル３８を構成する。テーブル３８は、図３（ｂ）に概念的に示すように、関係データベースのテーブルにＵＲＬ３６を格納したものである。なお、テーブル３８を正規化して複数のテーブルに分割することもできる。

また、テーブル管理機能３４は、上記関係データベースを取り扱うアプリケーション３９から実体データＡへのアクセスを要求された場合に、実体データＡのＵＲＬ３６をテーブル３８から取得してデータ管理機能３３に渡し、受け取った実体データＡからレコードを復元してアプリケーション３９に渡す。

アプリケーション３９（ＡＰ）は、アプリケーションサーバ６に格納されている。アプリケーション３９は、ＳＱＬなどによりテーブル管理機能３４のテーブル３８にアクセスし、上記関係データベースを取り扱うものである。

一方、データ構成管理サーバ３２は、ＵＲＬ３６を暗号鍵にて暗号化する。その復号鍵は、データ構成管理サーバ３２に入力される管理サーバ用復号鍵片とクライアント端末２より入力される端末用復号鍵片とから構成することができる。このような暗号化法としては、例えば、秘密分散法を用いることができる。データ構成管理サーバ３２は、全ての復号鍵片が入力された状態でＵＲＬ３６を復号化する。

上記構成の業務委託システム１のシステムフローを図４から図７を用いて説明する。業務委託システム１では、運用開始の前提として、委託元が委託先企業Ｏに業務委託を行う際、第三者機関Ｔに業務データを貸与する。

第三者機関Ｔでは、データ分散格納装置３に、貸与された業務データが初期データとして入力される。データ構成管理サーバ３２は、実体データＡを属性ごとに分けてデータ格納サーバ群３０に格納する。データ管理機能３３はメタデータファイル３７に、テーブル管理機能３４はテーブル３８に上記の各種情報を書き込む。この際、テーブル管理機能３４は、テーブル３８の各ＵＲＬ３６を暗号鍵で暗号化し、秘密分散法により、その暗号鍵から端末用復号鍵片と管理サーバ用復号鍵片とを作成する。

委託先企業Ｏは、第三者機関Ｔから、アプリケーション３９を利用するためのパスワードと、ＩＣカードに入力された端末用復号鍵片を受け取り、クライアント端末２に入力する。そして、第三者機関Ｔは、管理サーバ用復号鍵片をデータ構成管理サーバ３２からデータ格納サーバ群３０に格納すると、データ管理機能３３は、管理サーバ用復号鍵片の格納場所情報を作成する。なお、クライアント端末２に、委託先企業Ｏのオペレータの指紋認証データを入力するようにしてもよい。

以上で、業務委託システム１とデータ分散格納装置３はスタンバイ状態となる。

上記業務委託システムへのログインについて述べる。図４に示すように、委託先企業Ｏが上記業務データからなる実体データＡを利用する場合、アプリケーションサーバ６に対してログインする。クライアント端末２よりパスワードと端末用復号鍵片を入力し、アプリケーションサーバ６に送る（Ｓ１）。アプリケーションサーバ６は、端末用復号鍵片と共に復号鍵復元要求をデータ構成管理サーバ３２に送る（Ｓ２）。

データ構成管理サーバ３２のテーブル管理機能３４が管理サーバ用復号鍵片の格納場所情報を取得し、データ管理機能３３に送り（Ｓ３）、データ管理機能３３がデータ格納サーバ群３０に管理サーバ用復号鍵片の格納場所情報と取得要求を送る（Ｓ４）。

データ格納サーバ群３０は、受け取った管理サーバ用復号鍵片の格納場所情報に基いて管理サーバ用復号鍵片を、データ構成管理サーバ３２のテーブル管理機能３４に送る（Ｓ５）。

テーブル管理機能３４が、管理サーバ用復号鍵片の取得に成功したか判断する（Ｓ６）。ここで、取得に失敗したと判断した場合、再取得を行い（Ｓ８）、一方、取得したと判断した場合、テーブル管理機能３４は、管理サーバ用復号鍵片と端末用復号鍵片とから復号鍵を復元（Ｓ９）する。テーブル管理機能３４は、復号鍵が復元できたか判断する（Ｓ７）。ここで、テーブル管理機能３４は、復元失敗と判断した場合、アプリケーションサーバ６に認証拒絶を通知し、アプリケーションサーバ６は、認証が拒絶されたことをクライアント端末２に通知し（Ｓ１６）、クライアント端末２は、ログインの失敗を表示する（Ｓ１７）。

一方、テーブル管理機能３４は、Ｓ７において復元成功と判断した場合、復号鍵をメモリに常駐させる（Ｓ１０）。

Ｓ１０の次に、アプリケーションサーバ６は、パスワード認証を行い、認証が成功したか判断する（Ｓ１１）。ここで、パスワードの認証に成功した場合、クライアント端末２にログイン許可を通知し、クライアント端末２は、ログインの成功を表示する（Ｓ１２）。

以上で、業務委託システム１のログイン処理が完了し、委託先企業Ｏは、アプリケーション３９を利用することが可能になる。

一方、パスワードの認証に失敗した場合、クライアント端末２とテーブル管理機能３４に通知する（Ｓ１３）。通知を受けたクライアント端末２は、ログインの失敗を表示する（Ｓ１４）。また、通知を受けたテーブル管理機能３４は、復号鍵のメモリ常駐を開放する（Ｓ１５）。

次に、委託先企業Ｏがアプリケーションサーバ６からログアウトする場合のフローを述べる。図５に示すように、クライアント端末２からログアウト命令を入力してアプリケーションサーバ６に送り（Ｓ２１）、アプリケーションサーバ６は、ログアウト要求をテーブル管理機能３４に通知する（Ｓ２２）。

通知を受けたテーブル管理機能３４は、復号鍵のメモリ常駐を開放し、そのことをアプリケーションサーバ６に通知する（Ｓ２３）。アプリケーションサーバ６では、アプリケーション３９が必要な内部処理を行い（Ｓ２４）、クライアント端末２に処理結果を送り、処理結果を受け取ったクライアント端末２は、ログアウトの完了を表示する（Ｓ２５）。

以上で、業務委託システム１のログアウト処理が完了する。

次に、委託先企業Ｏが委託業務実行中にデータ分散格納装置１のデータ更新作業を行う場合のフローを図６に基づき説明する。先ず、委託先企業Ｏはクライアント端末２から業務データを追加入力して、アプリケーションサーバ６に送る（Ｓ３１）。追加の業務データを受け取ったアプリケーションサーバ６は、関係デ−タベースのレコード追加要求をテーブル管理機能３４に送る（Ｓ３２）。

テーブル管理機能３４は、新規レコード追加処理を開始し（Ｓ３３）、受け取った業務データの中の実体データＡをデータ管理機能３３に送る（Ｓ３４）。データ管理機能３３は、実体データＡの格納場所を決定し（Ｓ３５）、データ格納サーバ群３０に実体データＡを転送する（Ｓ３６）。データ格納サーバ群３０は、受け取った実体データＡを格納する（Ｓ３７）。

次に、データ管理機能３３は、実体データＡの追加ログを記録すると共に、実体データＡのメタデータファイル３７などに書き込みを行い（Ｓ３８）、実体データＡのＵＲＬ３６をテーブル管理機能３４に通知する（Ｓ３９）。通知を受けたテーブル管理機能３４は、レコードを更新すると共にＵＲＬ３６を暗号化し（Ｓ４０）、アプリケーションサーバ６に更新の完了を通知する。通知を受けたアプリケーションサーバ６では、アプリケーション３９が必要な内部処理を行い（Ｓ４１）、クライアント端末２にアプリケーション３９の処理結果を送る。処理結果を受けたクライアント端末２は、その更新結果を表示する（Ｓ４２）。

以上で、業務委託システム１のデータ更新作業が完了する。

なお、データ管理機能３３は、複製命令を受けて実体データＡを複製する場合、データ格納サーバ群３０に実体データＡを転送する（Ｓ４３）。データ格納サーバ群３０は、受け取った実体データＡを格納する（Ｓ４４）。次に、データ管理機能３３は、実体データＡの冗長ログ記録を作成する（Ｓ４５）。

次に、委託先企業Ｏが委託業務実行中に実体データＡの検索作業を行う場合のフローを図７に基づき説明する。先ず、委託先企業Ｏはクライアント端末２から検索条件を入力し、アプリケーションサーバ６に送る（Ｓ５１）。検索条件を受け取ったアプリケーションサーバ６は、データベース検索要求をテーブル管理機能３４に送る（Ｓ５２）。これを受けてテーブル管理機能３４は、テーブル３８のＵＲＬ３６を復号化し、レコード検索処理を開始し（Ｓ５３）、該当する業務データが有るか判断する（Ｓ５４）。

テーブル管理機能３４は、該当する業務データが有ると判断した場合、その実体データＡのＵＲＬ３６を取得し、そのＵＲＬ３６をデータ管理機能３３に送る（Ｓ５５）。これを受けてデータ管理機能３３は、メタデータファイル３７を参照して実体データＡの取得要求をデータ格納サーバ群３０に送り（Ｓ５８）、これらを受けてデータ格納サーバ群３０は、その実体データＡをデータ管理機能３３に送る（Ｓ５９）。

データ管理機能３３は、実体データＡの取得に成功したか判断する（Ｓ６０）。ここで、データ管理機能３３は、実体データＡの取得に成功したと判断した場合、テーブル管理機能３４に渡す。テーブル管理機能３４は、レコードを復元し、これをアプリケーションサーバ６に送る（Ｓ６１）。レコードを受け取ったアプリケーションサーバ６では、アプリケーション３９が必要な内部処理を行い（Ｓ６２）、クライアント端末２にアプリケーション３９の処理結果を送る。処理結果を受けたクライアント端末２は、その更新結果を表示する（Ｓ６３）。これにより、業務データの検索作業が完了する。

一方、データ管理機能３３は、実体データＡの取得に失敗したと判断した場合、実体データＡの再取得を試みる（Ｓ６４）。

以上に述べたように、参考例１に係る業務委託システム１およびデータ分散格納装置３によれば、関係データベースの管理と実体データＡの管理を独立させたので、メンテナンスを容易に行えると共に、実体データＡが流出した場合でも、業務データの意味内容を把握することが困難になるため、不正アクセスに対する安全性を高めることができる。

参考例１に係るデータ分散格納装置３は、他の業務システムに利用することも可能である。例えば、参考例２を図８に示す。なお、以下、上記参考例１と同じ構成要素については、同一の符号を付し、その説明を省略する。この参考例２では、アプリケーションサーバ６には、ＤＢＭＳサーバ４０が接続され、ＤＢＭＳサーバ４０は、データ構成管理サーバ３２とも接続されている。また、データ構成管理サーバ３２は、予備通信回線によりアプリケーションサーバ６と接続されている。

この構成においては、従来から広く行われているように、通常は、ＤＢＭＳサーバ４０で上記関係データベースの運用を行い、データ分散格納装置３をＤＢＭＳサーバ４０のバックアップシステムとして利用する。上述のように、データ分散格納装置３は、データ格納サーバの増設が容易であり、データ格納サーバ群３０の低コスト化を図れるので、バックアップシステムとして特に好適なものである。

また、参考例１に係るデータ分散格納装置３は、データ構成管理サーバ３２を二重化することができる。例えば、参考例３を図９に示す。この参考例３では、アプリケーションサーバ６に２セットのデータ構成管理サーバ３２、３２が接続されており、データ格納サーバ群３０は、両方のデータ構成管理サーバ３２、３２と接続されている。

この構成においては、両データ構成管理サーバ３２、３２を同期させると、運転時にそれぞれのデータ構成管理サーバ３２に加わる負荷を分散することができ、いずれか一方のデータ構成管理サーバ３２が故障した場合には、他方のデータ構成管理サーバ３２で縮退運転することができる。

さらに別の二重化形態として、参考例４を図１０に示す。この参考例４では、上記参考例３において、それぞれのデータ構成管理サーバ３２ごとにアプリケーションサーバ６が接続されている。また、それぞれのデータ構成管理サーバ３２、３２は互いに物理的に分離された状態で配置されている。

この構成においては、クライアント端末２、２ごとにアクセスさせるデータ構成管理サーバ３２、３２を分けることができるので、セキュリティ対策をより局所的に行えるようになると共に、利用ユーザに回線距離が短い方のデータ構成管理サーバ３２にアクセスさせると通信負担を低減できる。

本発明に係る実施形態の全体構成を図１２に示す。この実施形態に係るデータ分散格納装置５０は、アプリケーションサーバ６に接続されたデータ構成管理サーバ５１と、データ格納サーバ群５２とを備え、データ構成管理サーバ５１とデータ分散格納装置５０がネットワーク５３を介して物理的に分離した状態で接続されたものである。

データ構成管理サーバ５１は、関係データベースの顧客管理テーブル６０を揮発性メモリ５７上で取り扱う一時テーブル管理機能５４、およびテーブル６０に保持させた実体データの格納場所情報を記述したメタデータ７０をテーブル６０の構造と対応させて管理するメタデータ管理機能５６を含み、それぞれサーバとして構成された一時テーブル管理機能５４およびメタデータ管理機能５６が通信回線５５を介して接続されているものである。なお、データ格納サーバ群５２は、参考例１と同様のものなので説明を省略する。

一時テーブル管理機能５４は、揮発性メモリ５７を仮想的にハードディスクドライブとみなしてデータ保存等に利用するＲＡＭディスク機能の他、図１３に概念的に示すように、レコード６１ａを一ファイル単位とし、例えば、レコード６１ａの属性が顧客ＩＤ６２である実体データ６３ａ（ＡＢ１２・・・）のように、実体データを保持させた顧客管理テーブル６０を揮発性メモリ５７上で取り扱うデータベースマネジメント機能を備える。この一時テーブル管理機能５４は、属性ごとに分けた実体データを一定単位データで区切り、単位間の順序関係を可逆的に入れ替え、入れ替え法則情報を保持すると共に、この入れ替え後のスクランブルデータを分割してデータ格納サーバ群５２に格納するようになっている。

また、一時テーブル管理機能５４は、顧客管理テーブル６０の実体データをデータ格納サーバ群５２に格納すると、メタデータ７０を作成するようになっている。メタデータ７０は、図１４に概念的に示すように、顧客管理テーブル７１の属性名を有するディレクトリ構造となっており、例えば、顧客ＩＤ７２のように、顧客管理テーブル６０の属性ごとに実体データのメタデータが格納される下位階層が設けられた構造となっており、メタデータ管理機能５６により管理される。

一時テーブル管理機能５４は、レコード６１ａに保持させた実体データを、属性ごとに、或はデータ流出しても問題とならない意味内容の組み合わせとなるように分ける。すなわち、顧客管理テーブル６０では、顧客ＩＤ、名前と住所、電話番号と生年月日等というように分けられる。以下の処理は、顧客ＩＤ６２の実体データ６３ａ（ＡＢＣＤ１２３４５６７８９０）を代表例に説明する。

次に、一時テーブル管理機能５４は、実体データ６３ａを一定データ長で断片化する。断片する一定データ長は、後述するパックサイズの整数倍であることがアクセス性能上好ましいので、この例では、断片データ６４ａ、６４ｂの一定データ長を８バイトとしている。以下の処理は、断片データ６４ａ（ＡＢＣＤ１２３４）を例に説明する。

次に、一時テーブル管理機能５４は、断片データ６４ａを一定単位データで区切り、単位間の順序関係を可逆的に入れ替える（以下、一定単位データをシャッフルサイズという）。この例では、シャッフルサイズが１バイトなっているので、単位間の順序関係は、図１３において左から順に（０）、（１）、・・・、（７）の順次関係となっている。入れ替え法則情報には、実体データ６３ａに固有の乱数が用いられており、入れ替えは、断片データ６４ａをシャッフルサイズ単位に区切り、上記乱数で決定する任意の２つの単位を交換することで行われる。

この例では、実体データ６３ａの固有乱数が「０６１４２５３７」とすると、乱数の構成数字を左側から２個１セットごとに区分して交換単位とし、該当する順序関係の一定単位データが交換される。すなわち、断片データ６４ａの（０）番面のデータ「Ａ」と（６）番面のデータ「３」、（１）番面のデータ「Ｂ」と（４）番面のデータ「１」というように入れ替えられるようになっており、断片データ６４ａからスクランブルデータ６５ａが得られる。上記乱数は、実体データ６３ａの入れ替え法則情報としてメタデータに記述され、暗号化された状態でメタデータ管理機能５６に格納されるようになっている。

次に、一時テーブル管理機能５４は、スクランブルデータ６５ａを、さらに一定サイズ（以下、一定サイズをパックサイズという）で分割する。アクセス性能上、断片データのデータ長をパックサイズの倍数にすることが望ましいことから、この例では、パックサイズを２バイトとし、断片データのデータ長を８バイトとしている。

なお、分割データ６６ａ〜ｄは、データ格納サーバ群５２の各ノード５２ａ〜ｄに対してランダムに格納する。ここで、分割データ６６ａ〜ｄをランダムに格納するのは、データ流出に対する安全性をより高めるためである。

実体データ６３ａは、上記各処理を逆順に行うことによって復元される。すなわち、分割データ６６ａ〜ｄを結合すると元のスクランブルデータ６５ａが得られ、上記乱数を参照して再度同じ交換処理を行うと断片データ６４ａが得られ、断片データ６４ａ、６４ｂを結合すると実体データ６３ａが復元される。

なお、一時テーブル管理機能５４は、断片データのいずれかが一定データ長に足らない場合、乱数データを追加して一定データ長に整える。例えば、断片データ６４ｂ（５６７８９０＄％）では、本来６バイト（５６７８９０）しかないので、乱数データ「＄％」を追加することにより８バイトとされている。このように乱数データが追加されると、分割データ６６ａ〜ｄの復元や判読が困難になるという利点がある。分割データに含まれる乱数データは、断片データ６４ａ、６４ｂを結合する段階で除去される。

一時テーブル管理機能５４は、実体データ６３ａを分割データ６６ａ〜ｄとしてデータ格納サーバ群５２に格納すると、実体データ６３ａの論理的格納場所情報と、分割データ６６ａ〜ｄの物理的格納場所情報を合わせてメタデータとしてメタデータ管理機能５６に渡す。例えば顧客ＩＤ７２の下位階層内に格納された実体データ６３ａのメタデータは、その論理的格納場所情報と、分割データ６６ａ〜ｄのデータ格納サーバ群５２への物理的格納場所情報とを対応させた構造となっている。

論理的格納場所情報は、レコード６１ａに保持される実体データを一方向性関数（ハッシュ関数）により計算したハッシュ値に、顧客管理テーブル６０の属性の並びに対応するシーケンシャル番号を付けた文字列からなる。また、物理的格納場所情報には、ランダムに格納された各分割データ６６ａ〜ｄの物理的格納場所情報が記述されている。

一時テーブル管理機能５４は、顧客ＩＤ７２内の論理的格納場所情報を参照して各分割データ６６ａ〜ｄから実体データ６３ａを復元し、顧客管理テーブル７１の他の下位階層からも同様にレコード６１ａを構成する他の実体レコードを復元し、各実体データの物理的格納場所情報に対応する論理的格納場所情報のシーケンシャル番号に基づいて結合することにより、顧客管理テーブル６０の属性の並び順に実体データが保持されたレコード６１ａを１ファイルとして復元する。

上述のように、メタデータ７０が全体として顧客管理テーブル６０の構造と同一に対応させた階層構造とされているため、データ構成管理サーバ５１は、メタデータ７０が（テーブル名−属性名）というディレクトリ構造になっていることから、上位にあるテーブル名を指定することにより、顧客管理テーブル６０を揮発性メモリ５７上に一括で復元することができる。また、一時テーブル管理機能５４は、顧客管理テーブル６０に関する全実体データの格納場所を一括取得することが可能になるので、一時テーブル管理機能５４からデータ格納サーバ群５２へのアクセスを並列処理することにより他のレコード６１ｂも並列的に復元し、トランザクション速度の高速化を図ることができる。

また、データ構成管理サーバ５１は、上記参考例１と同様に、メタデータ管理機能５６が管理するメタデータ７０を暗号鍵にて暗号化し、暗号鍵の復号鍵を、少なくとも、データ構成管理サーバ５１に入力される管理サーバ用復号鍵片と上記関係データベースを利用するクライアント端末より入力される端末用復号鍵片から構成し、全ての復号鍵片が入力された状態でメタデータ７０を復号化するようになっている。

上記の構成を有するデータ分散格納装置５０のシステムフローを図１５から図１９に基づいて説明する。なお、以下では理解を容易にするため、適宜図１２から１４の符号を付して説明するが、図１５から図１９中では符号を省略する。

データ分散格納装置５０の利用前段階として、委託先企業の業務管理者（Ｏ）は、アプリケーションサーバ６を管理し、顧客管理テーブル６０の利用権限を有する者である。第三者機関は、データ分散格納装置５０へのアクセスを可能とするシステムキーをデータベース単位に一つ作成している。このシステムキーは、上記暗号鍵と復号鍵に相当するものであり、固有の乱数からなる。管理サーバ用復号鍵片は、システムキーを業務管理者（Ｏ）のパスワードもしくは指紋データのハッシュ値（以下、ユーザキーという。）でＸＯＲ分割したものであり、データ格納サーバ群５２に格納されている。なお、メタデータ管理機能５６には、業務管理者（Ｏ）のユーザ名のハッシュ値からなる論理的格納場所情報と対応させて管理サーバ用復号鍵片の物理的格納場所情報が格納されている。一方、端末用復号鍵片は、業務管理者（Ｏ）の保持する上記ユーザキーである。なお、この実施形態では、アプリケーションサーバ６が上記クライアント端末として機能する。

図１５、図１６は、業務管理者（Ｏ）がアプリケーションサーバ６よりデータ分散格納装置５０へアクセスし、アプリケーションサーバ６がスタンバイ状態になるまでの概略フローを示している。図１５に示すように、先ず、業務管理者（Ｏ）は、アプリケーションサーバ６からＤＢＭＳサーバ５４に対して、業務開始要求、ユーザ名、上記ユーザキーを送る（ｓ２００）。

一時テーブル管理機能５４は、この業務開始要求に応じて業務開始機能を呼び出し（ｓ２０１）、業務開始機能が、システムキーの復元処理要求、前記のユーザ名のハッシュ値、上記ユーザキーをメタデータ管理機能５６に送る（ｓ２０２）。

メタデータ管理機能５６は、前記のユーザ名のハッシュ値からなる論理的格納場所情報に対応する管理サーバ用復号鍵片の物理的格納場所情報を取得し（ｓ２０４）、この物理的格納場所情報に基づいてデータ格納サーバ群５２から管理サーバ用復号鍵片を取り寄せ（ｓ２０５）、この管理サーバ用復号鍵片と前記のユーザキーとをＸＯＲ演算してシステムキーを復元し、復元完了通知を一時テーブル管理機能５４の業務開始機能に送る（ｓ２０６）。

一時テーブル管理機能５４の業務開始機能は、メタデータ管理機能５６に対してメタデーモン起動要求を送る（ｓ２０８）。

メタデータ管理機能５６は、これを受けてメタデーモン機能を起動させ（ｓ２０９）、起動完了通知を一時テーブル管理機能５４の業務開始機能に送る。ここで、メタデーモン機能は、システムキーをそのシステムメモリに常駐させると共に、メタデータ７０等の暗号化・復号化処理を可能な状態とする。

一時テーブル管理機能５４の業務開始機能がメタデーモンの起動完了通知を受けると、データ分散格納装置５０は利用準備状態になる（ｓ２１０）。

図１６に示すように、業務開始機能は、ＲＡＭ−ＤＢ開始要求をＲＡＭ−ＤＢ開始機能に送り（ｓ２１１）、ＲＡＭ−ＤＢ開始機能は、これを受けてＲＡＭディスク機能、データベースマネジメント機能の起動（ｓ２１２、ｓ２１３）と、ＲＡＭディスク機能による揮発性メモリ５７の初期化処理（ｓ２１４）を図り、一時テーブル管理機能５４の業務開始機能に初期化完了通知を送る（ｓ２１５）。

一時テーブル管理機能５４の業務開始機能は、これを受けて、顧客管理テーブル６０の復元要求を一時テーブル管理機能５４のＤＢロード実行機能に送り（ｓ２１６）、ＤＢロード実行機能は、これを受けて、メタデータ管理機能５６に対してメタデータ７０の一括送信要求を送り（ｓ２１７）、メタデータ管理機能５６は、これを受けて、メタデータ７０を復号化し、ＤＢロード実行機能に一括送信する（ｓ２１８）。

一時テーブル管理機能５４のＤＢロード実行機能は、受け取ったメタデータ７０から顧客管理テーブル６０に保持させる実体データの送信要求をデータ格納サーバ群５２の各ノード５２ａ〜ｄに送り、データ格納サーバ群５２から各分割データを受け取ると、随時実体データを復元する（ｓ２１９）。

次に、一時テーブル管理機能５４のＤＢロード実行機能は、復元された実体データをその論理的格納場所情報のシーケンシャル番号に基づいて結合することにより１レコードのファイルを作成し、それを随時テキストファイルに追記して行くことによってＤＢロードファイルを作成する（ｓ２２０）。次に、ＤＢロード実行機能は、前記のＤＢロードファイルをデータベースマネジメント機能に送信し、それを受信したデータベースマネジメント機能は、揮発性メモリ５７上に実体データの保持された顧客管理テーブル６０を完全に復元し、復元完了通知を一時テーブル管理機能５４の業務開始機能に送る（ｓ２２１）。

一時テーブル管理機能５４の業務開始機能は、これを受けて、ＤＢ更新開始要求を一時テーブル管理機能５４のＤＢ更新処理開始機能に送り（ｓ２２３）、ＤＢ更新処理開始機能は、この要求を受けて起動し（ｓ２２４）、ＤＢ更新トリガ処理を有効化し（ｓ２２５）、ＤＢ更新デーモンを起動させ、起動完了通知を一時テーブル管理機能５４の業務開始機能に送る（ｓ２２６）。ここまでの処理を経て、顧客管理テーブル６０が更新処理準備状態になる。

一時テーブル管理機能５４の業務開始機能は、ＤＢ更新デーモンの起動完了通知を受けて、アプリケーションサーバ６に結果表示を出力させ（ｓ２２７）、アプリケーションサーバ６がスタンバイ状態となる（ｓ２２８）。

図１７、図１８は、業務管理者（Ｏ）の管理するクライアント端末２が、アプリケーションサーバ６に格納されたアプリケーション３９を介して顧客管理テーブル６０へアクセスし、各種の取り扱い処理を実行する際のシステムフローを概略的に示している。

図１７に示すように、先ず、クライアント端末２は、アプリケーションサーバ６にログイン要求を送り（ｓ２２９）、アプリケーションサーバ６は、これを受けてログイン認証を行い（ｓ２３０）、ログイン許可を受けて、クライアント端末２は、アプリケーション３９を介して顧客管理テーブル６０へアクセス可能となる（ｓ２３１）。

（ｓ２３１）の状態で、クライアント端末２が検索処理要求をアプリケーションサーバ６に送ると（ｓ２３２）、アプリケーションサーバ６は、「ＳＥＬＥＣＴ」のＳＱＬを一時テーブル管理機能５４に送り（ｓ２３３）、一時テーブル管理機能５４はＳＥＬＥＣＴ処理を行い（ｓ２３４）、顧客管理テーブル６０から該当ファイルや実体データを取得し（ｓ２３５）、その検索結果をアプリケーションサーバ６を介してクライアント端末２に表示させる（ｓ２３６）。

（ｓ２３１）の状態で、クライアント端末２が追加処理要求と追加データをアプリケーションサーバ６に送ると（ｓ２３７）、アプリケーションサーバ６は、「ＩＮＳＥＲＴ」のＳＱＬを一時テーブル管理機能５４に送り（ｓ２３８）、一時テーブル管理機能５４はトリガ処理を実行してそのファイル挿入機能を起動させる（ｓ２４１）。

一時テーブル管理機能５４のファイル挿入機能は、追加データをスクランブルデータにして分割データを作成し（ｓ２４２）、各分割データをデータ格納サーバ群５２に対してランダムに格納すると共に、追加データの論理的格納場所情報を作成し（ｓ２４３）、各分割データの物理的格納場所情報をメタデータ管理機能５６に送る（ｓ２４４）。メタデータ管理機能５６は、該当するメタデータを更新することにより、ファイル挿入機能が作成した論理的格納場所情報と各分割データの物理的格納場所情報を対応させ、更新完了通知を一時テーブル管理機能５４のファイル挿入機能に送る（ｓ２４５）。

一時テーブル管理機能５４のファイル挿入機能は、これを受けて、トリガ処理を終了し（ｓ２４６）、クライアント端末２に追加処理結果をアプリケーションサーバ６を介して表示させる（ｓ２４７）。

図１８に示すように、（ｓ２３１）の状態で、クライアント端末２が更新処理要求と更新データをアプリケーションサーバ６に送ると（ｓ２４８）、アプリケーションサーバ６は、「ＵＰＤＡＴＥ」のＳＱＬを一時テーブル管理機能５４に送り（ｓ２４９）、一時テーブル管理機能５４は、これを受けてＵＰＤＡＴＥ処理を行い（ｓ２５０）、顧客管理テーブル６０から該当する更新対象ファイルを検索し（ｓ２６０）、更新対象ファイルを発見するとトリガ処理を実行し、一時テーブル管理機能５４のファイル削除機能を起動させる（ｓ２７０）。ファイル削除機能は、更新対象ファイルに保持された実体データの削除要求をデータ格納サーバ群５２に送り（ｓ２７１）、データ格納サーバ群５２は、これを受けて該当実体データを削除し、その結果をメタデータ管理機能５６に送り（ｓ２７２）、メタデータ管理機能５６は、これを受けて、該当実体データのメタデータを削除し、完了通知を一時テーブル管理機能５４に送る（ｓ２７３）。

一時テーブル管理機能５４は、これを受けてトリガ処理を実行し（ｓ２７４）、ファイル挿入機能を起動させる（ｓ２７５）。ファイル挿入機能は、更新データをスクランブルデータにして分割データを作成し（ｓ２７６）、各分割データをデータ格納サーバ群５２に対してランダムに格納すると共に、更新データの論理的格納情報を作成し（ｓ２７７）、各分割データの物理的格納場所情報と合わせてメタデータ管理機能５６に送る（ｓ２７８）。メタデータ管理機能５６は、該当するメタデータを更新することにより、ファイル挿入機能が作成した論理的格納場所情報と各分割データの物理的格納場所情報を対応させ、更新完了通知を一時テーブル管理機能５４のファイル挿入機能に送る（ｓ２７８）。

一時テーブル管理機能５４は、これを受けてトリガ処理を終了し（ｓ２７９）、クライアント端末２に更新処理結果をアプリケーションサーバ６を介して結果表示させる（ｓ２８０）。

図１９は、業務管理者（Ｏ）がアプリケーションサーバ６とデータ分散格納装置５０とのアクセスを終了させる際の概略フローを示している。図１９に示すように、先ず、業務管理者（Ｏ）は、アプリケーションサーバ６がスタンバイ状態で、アプリケーションサーバ６から一時テーブル管理機能５４に対して、業務終了要求を送る（ｓ２８１）。

一時テーブル管理機能５４は、これを受けて業務終了機能を起動させ（ｓ２８２）、業務終了機能は、ＤＢ更新処理停止要求を一時テーブル管理機能５４のＤＢ更新処理停止機能に送り（ｓ２８３）、ＤＢ更新処理停止機能は、ＤＢ更新デーモンを停止させ（ｓ２８４）、ＤＢ更新トリガを無効化し（ｓ２８５）する。

次に、業務終了機能は、顧客管理テーブル６０の消去要求をＲＡＭ−ＤＢ停止機能に送り（ｓ２８９）、ＲＡＭ−ＤＢ停止機能は、これを受けて顧客管理テーブル６０の処理を停止させ（ｓ２９０）、揮発性メモリ５７上の顧客管理テーブル６０を消去し、業務終了機能に消去完了通知を送る（ｓ２９１）。

業務終了機能は、これを受けてメタデーモン停止要求をメタデータ管理機能５６に送り（ｓ２９３）、メタデータ管理機能５６は、メタデーモン機能を停止させて、停止完了通知を一時テーブル管理機能５４の業務終了機能に送る（ｓ２９４）。

業務終了機能は、これを受けて、業務終了処理結果をアプリケーションサーバ６に表示させ（ｓ２９５）、アプリケーションサーバ６とデータ分散格納装置５０とのアクセスが終了状態となる（ｓ２９６）。

本発明に係る業務委託システムおよびデータ分散格納装置の参考例１を示す全体構成図。 図１のデータ分散格納装置のシステム構成図。 （ａ）図１のデータ構成管理サーバのデータ管理機能で作成されるメタデータファイルの構成図、（ｂ）テーブル管理機能で作成されるテーブル構成図。 図１の業務委託システムおよびデータ分散格納装置のログイン時におけるシステムフロー図。 図１の業務委託システムおよびデータ分散格納装置のログアウト時におけるシステムフロー図。 図１の業務委託システムおよびデータ分散格納装置のデータ更新作業時におけるシステムフロー図。 図１の業務委託システムおよびデータ分散格納装置のデータ検索作業時におけるシステムフロー図。 参考例２を示す全体構成図。 参考例３を示す全体構成図。 参考例４を示す全体構成図。 （ａ）従来の分散型データベースの全体構成図、（ｂ）従来の分散型データベースで作成されるテーブル構成図。 本発明に係るデータ分散格納装置の実施形態を示す全体構成図。 実施形態のデータ分散格納装置で取り扱う顧客管理テーブルと、この顧客管理テーブルに保持される実体データの格納処理を示す概念図。 実施形態のメタデータ管理機能に格納されたメタデータの全体構造を示す概念図。 実施形態において、業務管理者がアプリケーションサーバより実施形態のデータ分散格納装置へアクセスし、アプリケーションサーバがスタンバイ状態になるまでの概略フローの前半を示す概略部分システムフロー図。 図１５の続きを示す概略部分システムフロー図。 実施形態において、クライアント端末が顧客管理テーブルへアクセスする処理、クライアント端末が顧客管理テーブルを検索する処理、上記クライアント端末が顧客管理テーブルにデータを追加する処理の概略システムフロー図。 実施形態において、クライアント端末が顧客管理テーブルを更新する処理の概略システムフロー図。 実施形態において、業務管理者がアプリケーションサーバとデータ分散格納装置とのアクセスを終了させる処理の概略システムフロー図。

符号の説明

１ 業務委託システム
２ クライアント端末
３、５０ データ分散格納装置
４、５、３１ 通信回線
６ アプリケーションサーバ
３０、５２ データ格納サーバ群
３０ａ、３０ｂ、３０ｃ データ格納サーバ
３２、５１ データ構成管理サーバ
３３ データ管理機能
３４ テーブル管理機能
３５ 物理ファイル名
３６ 論理ファイル名
３７ メタデータファイル
３８ テーブル
３９ アプリケーション
５１ データ構成管理サーバ
５４ 一時テーブル管理機能
５６ メタデータ管理機能
５７ 揮発性メモリ
６０ 顧客管理テーブル
６３ａ、Ａ 実体データ
６５ａ スクランブルデータ
６６ａ〜ｄ分割データ
７０ メタデータ
Ｏ 委託先企業
Ｔ 第三者機関

Claims (7)

1. 関係データベースの実体データを格納されるデータ格納サーバ群と、このデータ格納サーバ群と物理的に分離した状態で通信回線を介して接続されており、上記実体データを保持させたテーブルを揮発性メモリ上で取り扱う一時テーブル管理機能、および上記実体データの格納場所情報を記述したメタデータを上記テーブルの構造と対応させて管理するメタデータ管理機能を含むデータ構成管理サーバとを備え、
   上記一時テーブル管理機能は、アプリケーションからの追加処理又は更新処理要求のＳＱＬを受けて当該処理を成す都度、バックグラウンドで、当該処理対象のレコードに保持させた実体データを属性ごと分けて上記データ格納サーバ群に格納する処理と、格納した各実体データの上記メタデータを作成して上記メタデータ管理機能に送る処理とを行い、
   上記一時テーブル管理機能は、上記アプリケーションからの検索処理要求のＳＱＬを受けて、上記実体データを保持させたテーブルから該当実体データを取得して当該アプリケーションに渡す処理を行い、
   上記一時テーブル管理機能は、上記揮発性メモリが初期化された状態で、上記メタデータ管理機能が管理するメタデータとこのメタデータの格納構造に基づいて、上記実体データを保持させたテーブルを上記揮発性メモリ上に復元する処理を行い、
   上記揮発性メモリが初期化されると、上記実体データを保持させたテーブルが装置から完全に消去されるデータ分散格納装置。
2. 上記メタデータ管理機能は、上記テーブルの属性名を有するディレクトリ構造であって上記テーブルの属性ごとに分けて下位階層が設けられた構造で管理し、上記一時テーブル管理機能から渡された上記メタデータを該当する属性の下位階層に格納し、
   上記メタデータは、上記実体データから一意に導かれる文字列からなる論理的格納場所情報と上記データ格納サーバ群への物理的格納場所情報とを対応させた構造であり、
   上記論理的格納場所情報は、上記テーブルの属性の並びに対応するシーケンシャル番号を含み、
   上記一時テーブル管理機能は、その論理的格納場所情報のシーケンシャル番号に基づいて結合することにより前記レコードを復元することを特徴とする請求項１に記載のデータ分散格納装置。
3. 上記データ構成管理サーバは、上記メタデータ管理機能が管理するメタデータを暗号鍵にて暗号化し、上記暗号鍵の復号鍵を、少なくとも、上記データ構成管理サーバに入力される管理サーバ用復号鍵片と上記関係データベースを利用するクライアント端末より入力される端末用復号鍵片から構成し、全ての復号鍵片が入力された状態で上記メタデータを復号化することを特徴とする請求項１または２に記載のデータ分散格納装置。
4. 上記データ構成管理サーバは、属性ごとに分けた実体データを一定単位データで区切り、単位間の順序関係を可逆的に入れ替え、入れ替え法則情報を保持すると共に、この入れ替え後のスクランブルデータを分割して上記データ格納サーバ群に格納することを特徴とする請求項１から３のいずれか１項に記載のデータ分散格納装置。
5. 委託元から業務を外部委託される委託先企業に配置されたクライアント端末と、上記委託元および上記委託先企業と第三者の立場にある第三者機関に配置された請求項１から４のいずれか１項に記載のデータ分散格納装置と、このデータ分散格納装置の上記データ構成管理サーバと接続されると共に上記クライアント端末と通信回線を介して接続されたアプリケーションサーバとを備え、上記関係データベースの上記実体データが上記委託元の業務データからなり、上記アプリケーションを上記アプリケーションサーバに格納している業務委託システム。
6. 請求項１から５のいずれか１項に記載のデータ構成管理サーバ。
7. 上記アプリケーションが格納されたアプリケーションサーバを介して請求項１から４のいずれか１項に記載のデータ分散格納装置の上記データ構成管理サーバに接続されているクライアント端末。

Images