JP2021189569A - データ更新プログラム、データ更新装置及びデータ更新方法 - Google Patents

Abstract

【課題】データ供給元のデータベースに対する更新データの安全性を確保しながら、更新データをデータ供給先のデータベースに反映できるデータ更新プログラム等を提供する。【解決手段】コンピュータに、データ供給元のデータベースでのデータ更新を検出した場合に、更新後の更新対象データがアクセス制御対象であるか否かを判定する処理を実行させる。更に、コンピュータに、判定結果に基づいて、データ供給先のデータベースに対して出力する、前記更新対象データに関するクエリを変更する処理を実行させる。【選択図】図７

Description

本発明は、データ更新プログラム、データ更新装置及びデータ更新方法に関する。

例えば、データサイエンティストによるデータの分析、そしてビジネスへの反映は、企業にとって非常に重要なものとなっている。昨今は一つの企業内のデータだけで分析を行うのではなく、企業間で様々なデータをやりとりし、自社のビジネスに生かしていくことが重要である。しかしながら、このようなプラットフォームに企業がデータを提供するためには、提供者が管理するデータの保護が求められている。そこで、提供者が許可したデータのみを利用者に提供する仕組みが求められている。

提供者が、例えば、リレーショナルデータベース（ＲＤＢ：Relational DataBase）に記憶するデータを利用者に提供する場合、許可されるデータはファイル単位ではなく、行単位及び列単位で提供することになる。図１０は、第１のデータ提供システム３００の一例を示す説明図である。

図１０に示す第１のデータ提供システム３００は、提供者側サーバ３０２と、利用者側サーバ３０３とを有する。提供者は、例えば、個人データを管理する会社Ａ、利用者は、例えば、製薬会社Ｂとする。会社Ａが、例えば、利用許可した創薬向けの個人情報等のデータのみを製薬会社Ｂに提供する場合を想定する。

提供者側サーバ３０２は、提供者側のデータを記憶する提供者側ＲＤＢ３０２Ａを管理するサーバである。提供者側ＲＤＢ３０２Ａは、ＩＤと、名前と、年齢と、情報利用とを対応付けて管理する。ＩＤは、例えば、個人データを識別する識別子である。名前は、個人を識別する名前である。年齢は、個人の年齢である。情報利用は、個人データの情報利用の可否を識別する情報である。情報利用は、利用者に提供可能なデータを示す“ＴＲＵＥ”、利用者に提供不可のデータを示す“ＦＡＬＳＥ”である。利用者側サーバ３０３は、利用者側のデータを記憶する利用者側ＲＤＢ３０３Ａを管理するサーバである。

提供者側サーバ３０２は、提供者側ＲＤＢ３０２Ａから情報利用“ＴＲＵＥ”のデータ、例えば、情報利用“ＴＲＵＥ”のＩＤ“００１１”、“００２２”及び“０３３３”のデータを提供者側ＲＤＢ３０２Ａから抽出する。提供者側サーバ３０２は、抽出した情報利用“ＴＲＵＥ”のデータを利用者側サーバ３０３に送信する。利用者側サーバ３０３は、提供者側サーバ３０２から情報利用“ＴＲＵＥ”のデータを受信した場合、情報利用“ＴＲＵＥ”のデータを利用者側ＲＤＢ３０３Ａ内に登録する。その結果、利用者側サーバ３０３は、提供者側サーバ３０２から提供された情報利用“ＴＲＵＥ”のデータを使用できる。

また、２社間の契約内容（提供内容）やデータの種類によっては、提供者側ＲＤＢ３０２Ａ内のデータを更新（ＵＰＤＡＴＥ）、挿入（ＩＮＳＥＲＴ）、削除（ＤＥＬＥＴＥ）することも考えられる。最新のデータの反映は勿論のこと、個人情報等のセンシティブなデータはその持ち主の意向によって突然使えなくなることもある。例えば、提供者側ＲＤＢ３０２Ａ内のＩＤ“００１１”の情報利用を“ＴＲＵＥ”から“ＦＡＬＳＥ”にする場合も考えられる。

図１１は、第１のデータ提供システム３００の課題の一例を示す説明図である。提供者側ＲＤＢ３０２Ａ内のＩＤ“００１１”の情報利用が“ＴＲＵＥ”から“ＦＡＬＳＥ”になった場合には、利用者側ＲＤＢ３０３ＡからＩＤ“００１１”のデータを削除する必要がある。つまり、提供者側ＲＤＢ３０２Ａの内容の更新、追加や削除に応じて利用者側ＲＤＢ３０３Ａの内容を更新する必要があるが、提供者側ＲＤＢ３０２Ａの更新内容を利用者側ＲＤＢ３０３Ａに反映できないのが実情である。

そこで、このような事態に対処すべく、提供者側ＲＤＢ３０２Ａの更新内容を利用者側ＲＤＢ３０３Ａに反映できるロジカルレプリケーションの第２のデータ提供システム３１０が知られている。図１２は、第２のデータ提供システム３１０の一例を示す説明図である。

第２のデータ提供システム３１０は、提供者側ＲＤＢ３１２Ａを有する提供者側サーバ３１２と、利用者側ＲＤＢ３１３Ａを有する利用者側サーバ３１３とを有する。尚、説明の便宜上、提供者側ＲＤＢ３１２Ａは、例えば、情報利用“ＴＲＵＥ”のＩＤ“００１１”及び“００２２”のデータと、情報利用“ＦＡＬＳＥ”のＩＤ“１０１１”及び“９０５４”のデータとを記憶しているものとする。

先ず、提供者側サーバ３１２は、提供者側ＲＤＢ３１２Ａに記憶中のデータのコピーを利用者側サーバ３１３に送信する。利用者側サーバ３１３は、提供者側ＲＤＢ３１２Ａに記憶中のデータのコピーを利用者側ＲＤＢ３１３Ａに記憶する。

提供者側サーバ３１２は、提供者側ＲＤＢ３１２Ａ内に新たなデータ、例えば、ＩＤ“０３３３”、名前“Ａｎｇ”、年齢“１５”及び情報利用“ＴＲＵＥ”のデータを追加する場合、挿入のログ情報を利用者側サーバ３１３に送信する。尚、挿入のログ情報は、例えば、ＩＤ“０３３３”、名前“Ａｎｇ”、年齢“１５”及び情報利用“ＴＲＵＥ”のデータを含む挿入のログ情報である。

利用者側サーバ３１３は、挿入のログ情報を受信した場合、挿入のログ情報の内容を解析して利用者側ＲＤＢ３１３Ａ内にＩＤ“０３３３”、名前“Ａｎｇ”、年齢“１５”及び情報利用“ＴＲＵＥ”のデータを挿入する。つまり、提供者側サーバ３１２は、提供者側ＲＤＢ３１２Ａ内の内容の更新、削除や挿入のログを取得した場合、取得したログ情報を利用者側サーバ３１３に通知する。その結果、提供者側ＲＤＢ３１２Ａの内容の更新に応じて提供者側ＲＤＢ３１２Ａの差分内容を利用者側ＲＤＢ３１３Ａの内容に反映できる。

第２のデータ提供システム３１０では、提供者側ＲＤＢ３１２Ａの内容と利用者側ＲＤＢ３１３Ａの内容とを同一にするバックアップに使用するシステムである。しかしながら、提供者側サーバ３１２が許可した情報利用“ＴＲＵＥ”のデータのみを利用者側ＲＤＢ３１３Ａに提供するフィルタリング機能に適用したものではない。

そこで、このような事態に対処すべく、データの提供条件として事前定義クエリを設定する第３のデータ提供システム３２０が考えられる。図１３は、第３のデータ提供システム３２０の一例を示す説明図である。図１３に示す第３のデータ提供システム３２０は、提供者側ＲＤＢ３２２Ａを有する提供者側サーバ３２２と、利用者側ＲＤＢ３２３Ａを有する利用者側サーバ３２３とを有する。

提供者側サーバ３２２は、事前定義クエリに応じて、提供者側ＲＤＢ３２２Ａから情報利用“ＴＲＵＥ”のデータのみを抽出する。尚、事前定義クエリは、情報利用“ＴＲＵＥ”のデータのみを抽出して利用者側サーバ３２３に提供するデータ提供条件である。提供者側サーバ３２２は、抽出した情報利用“ＴＲＵＥ”のデータを利用者側サーバ３２３に送信する。利用者側サーバ３２３は、抽出した情報利用“ＴＲＵＥ”のデータを利用者側ＲＤＢ３２３Ａに登録する。その結果、提供者側サーバ３２２は、事前定義クエリに応じて許可したデータのみを利用者側サーバ３２３に提供できるフィルタリング機能を実現できる。

しかしながら、提供者側サーバ３２２は、提供者側ＲＤＢ３２２Ａ内の内容の更新、削除や挿入が行われる毎に、提供者側ＲＤＢ３２２Ａ内の全てのデータから事前定義クエリに応じたデータを抽出する処理を要する。しかも、提供者側サーバ３２２は、その抽出結果である許可したデータを利用者側サーバ３２３に送信するため、処理負担が大である。

そこで、このような事態に対処すべく、処理負担を軽減しながら、ロジカルレプリケーション及びフィルタリング機能を兼ね備えた第４のデータ提供システム３３０が考えられる。図１４は、第４のデータ提供システム３３０の一例を示す説明図である。

第４のデータ提供システム３３０では、フィルタリングを行わないが、レプリケーション先のデータベースの行単位及び列単位のセキュリティポリシーを用いることで、実際にデータは存在するが不可視の状況を実現できる。

図１４に示す第４のデータ提供システム３３０は、提供者側ＲＤＢ３３２Ａを有する提供者側サーバ３３２と、利用者側ＲＤＢ３３３Ａを有する利用者側サーバ３３３とを有する。尚、利用者側ＲＤＢ３３３Ａは、提供者側ＲＤＢ３３２Ａのデータのコピーを記憶しているものとする。

提供者側サーバ３３２は、提供者側ＲＤＢ３３２Ａ内に新たなデータ、例えば、ＩＤ“９０５４”、名前“Ｄａｉ”、年齢“４０”及び情報利用“ＦＡＬＳＥ”のデータを追加する場合、挿入のログ情報を利用者側サーバ３３３に送信する。更に、提供者側サーバ３３２は、利用者側サーバ３３３側で利用者側ＲＤＢ３３３Ａに記憶中の情報利用が“ＴＲＵＥ”のデータが参照可能で、情報利用“ＦＡＬＳＥ”のデータの参照不可のポリシー情報を定義しておく。そして、提供者側サーバ３３２は、ポリシー情報を利用者側サーバ３３３に送信する。

そして、利用者側サーバ３３３は、提供者側サーバ３３２から受信した挿入のログ情報に基づき、挿入の新たなデータを利用者側ＲＤＢ３３３Ａに登録する。そして、利用者側サーバ３３３は、提供者側サーバ３３２から受信したポリシー情報に基づき、利用者側ＲＤＢ３３３Ａに記憶中のデータの内、情報利用が“ＴＲＵＥ”のデータのみを参照可能にし、情報利用が“ＦＡＬＳＥ”のデータを参照不可の状態にする。

つまり、利用者側サーバ３３３では、提供者側ＲＤＢ３３２Ａ内の全てのデータがロジカルレプリケーションにより利用者側ＲＤＢ３３３Ａにコピーされている。実際に、利用者側サーバ３３３は、利用者側ＲＤＢ３３３Ａに記憶中のデータを参照する際、行単位のポリシー情報に基づき、情報利用が“ＦＡＬＳＥ”の行がマスクされているため、利用者は、情報利用が“ＴＲＵＥ”のデータのみが参照可能になる。

しかしながら、第４のデータ提供システム３３０の提供者側サーバ３３２では、利用者側サーバ３３３で参照不可のデータあっても、参照不可のデータが利用者側ＲＤＢ３３３Ａに記憶されていることになる。従って、提供者側の情報利用“ＦＡＬＳＥ”のデータの安全性を確保できない。

そこで、情報利用“ＦＡＬＳＥ”のデータの安全性を確保しながら、ロジカルレプリケーション及びフィルタリング機能を兼ね備えた第５のデータ提供システム３４０が考えられる。図１５は、第５のデータ提供システム３４０の一例を示す説明図である。図１５に示す第５のデータ提供システム３４０では、提供者側ＲＤＢ３４２Ａを有する提供者側サーバ３４２と、利用者側ＲＤＢ３４３Ａを有する利用者側サーバ３４３とを有する。尚、利用者側ＲＤＢ３４３Ａは、提供者側ＲＤＢ３４２Ａのデータのコピーを記憶しているものとする。

提供者側サーバ３４２は、提供者側ＲＤＢ３４２Ａ内に新たなデータ、例えば、ＩＤ“９０５４”、名前“Ｄａｉ”、年齢“４０”及び情報利用“ＦＡＬＳＥ”のデータを追加する場合、挿入のログ情報を利用者側サーバ３４３に送信する。更に、提供者側サーバ３４２は、利用者側ＲＤＢ３４３Ａ内の情報利用“ＦＡＬＳＥ”のデータを削除する削除クエリを利用者側サーバ３４３に送信する。

利用者側サーバ３４３は、挿入のログ情報を受信した場合、挿入のログ情報に基づき、新たな挿入のデータを利用者側ＲＤＢ３４３Ａに登録する。つまり、利用者側サーバ３４３は、ＩＤ“９０５４”、名前“Ｄａｉ”、年齢“４０”及び情報利用“ＦＡＬＳＥ”のデータを利用者側ＲＤＢ３４３Ａに登録する。次に、利用者側サーバ３４３は、削除クエリを受信した場合、利用者側ＲＤＢ３４３Ａ内の情報利用“ＦＡＬＳＥ”のデータを削除する。つまり、利用者側サーバ３４３は、削除クエリに応じて、利用者側ＲＤＢ３４３Ａに記憶中のデータの内、情報利用“ＦＡＬＳＥ”のＩＤ“９０５４”、名前“Ｄａｉ”及び年齢“４０”のデータを削除する。つまり、利用者側サーバ３４３では、提供者側ＲＤＢ３４２Ａ内の全てのデータがロジカルレプリケーションにより利用者側ＲＤＢ３４３Ａにコピーされているが、削除クエリに応じて利用者側ＲＤＢ３４３Ａから情報利用“ＦＡＬＳＥ”のデータを削除する。その結果、情報利用“ＦＡＬＳＥ”のデータの安全性を確保しながら、利用者は、参照可能な情報利用“ＴＲＵＥ”のデータのみが参照可能になる。

第５のデータ提供システム３４０では、利用者側ＲＤＢ３４３Ａ内で削除クエリに応じて情報利用“ＦＡＬＳＥ”のデータが削除されるため、提供者側ＲＤＢ３４２Ａのデータ内容と利用者側ＲＤＢ３４３Ａのデータ内容とが異なることになる。

図１６は、第５のデータ提供システム３４０の課題の一例を示す説明図である。提供者側サーバ３４２は、利用者側ＲＤＢ３４３Ａに記憶中のデータの情報利用を“ＦＡＬＳＥ”から“ＴＲＵＥ”に更新する場合、更新のログ情報を利用者側サーバ３４３に送信することになる。例えば、ＩＤ“９０５４”、名前“Ｄａｉ”、年齢“４０”のデータの情報利用“ＦＡＬＳＥ”を“ＴＲＵＥ”に更新した場合、更新のログ情報を利用者側サーバ３４３に送信することになる。

特開２０１７−７６２２９号公報 特開２００９−１１６８４６号公報

しかしながら、利用者側サーバ３４３は、情報利用が“ＦＡＬＳＥ”から“ＴＲＵＥ”に更新する更新のログ情報を受信したとしても、利用者側ＲＤＢ３４３Ａ内には更新のログ情報に対応した情報利用“ＦＡＬＳＥ”のデータが削除済みである。そもそも、利用者側サーバ３４３は、更新前に情報利用が“ＦＡＬＳＥ”のため、利用者側ＲＤＢ３４３Ａから、例えば、ＩＤ“９０５４”、名前“Ｄａｉ”、年齢“４０”のデータが削除済みである。従って、利用者側サーバ３４３は、利用者側ＲＤＢ３４３Ａ内にＩＤ“９０５４”に一致するデータがないため、ＩＤ“９０５４”のデータを利用者側ＲＤＢ３４３Ａ内で更新できず、ロジカルレプリケーションのエラーが生じる。その結果、利用者側ＲＤＢ３４３Ａ内に情報利用が“ＴＲＵＥ”のデータを登録できず、提供者は、利用者に対して情報利用“ＴＲＵＥ”のデータを提供できないことになる。

つまり、提供者側ＲＤＢ３４２Ａに対する更新データの安全性を確保しながら、更新データを利用者側ＲＤＢ３４３Ａに反映できるシステムが求められている。

一つの側面では、提供者側ＲＤＢに対する更新データの安全性を確保しながら、更新データを利用者側ＲＤＢに反映できるデータ更新プログラム等を提供することを目的とする。

１つの側面のデータ更新プログラムは、データ供給元のデータベースでのデータ更新を検出した場合に、更新後の更新対象データがアクセス制御対象であるか否かを判定する処理をコンピュータに実行させる。更に、データ更新プログラムは、判定結果に基づいて、データ供給先のデータベースに対して出力する、前記更新対象データに関するクエリを変更する処理をコンピュータに実行させる。

１つの側面によれば、データ供給元のデータベースに対する更新データの安全性を確保しながら、更新データをデータ供給先のデータベースに反映できる。

図１は、実施例１のデータ提供システムの一例を示す説明図である。 図２は、提供者側サーバ及び利用者側サーバの機能構成の一例を示すブロック図である。 図３は、提供者側ＲＤＢ及び利用者側ＲＤＢのテーブル構成の一例を示す説明図である。 図４は、提供条件のファイルの一例を示す説明図である。 図５は、他の提供条件のファイルの一例を示す説明図である。 図６Ａは、データ提供システムの情報利用（ＦＡＬＳＥ→ＴＲＵＥ）の更新時のクエリ変更動作の一例を示す説明図である。 図６Ｂは、データ提供システムの情報利用（ＴＲＵＥ→ＦＡＬＳＥ）の更新時のクエリ変更動作の一例を示す説明図である。 図６Ｃは、データ提供システムのデータ削除時のクエリ変更動作の一例を示す説明図である。 図６Ｄは、データ提供システムのデータ挿入時のクエリ変更動作の一例を示す説明図である。 図７は、データ更新処理に関わるクエリ変更部の処理動作の一例を示すフローチャートである。 図８は、実施例２のデータ提供システムの一例を示す説明図である。 図９は、データ更新プログラムを実行するコンピュータの一例を示す説明図である。 図１０は、第１のデータ提供システムの一例を示す説明図である。 図１１は、第１のデータ提供システムの課題の一例を示す説明図である。 図１２は、第２のデータ提供システムの一例を示す説明図である。 図１３は、第３のデータ提供システムの一例を示す説明図である。 図１４は、第４のデータ提供システムの一例を示す説明図である。 図１５は、第５のデータ提供システムの一例を示す説明図である。 図１６は、第５のデータ提供システムの課題の一例を示す説明図である。

以下、図面に基づいて、本願の開示するデータ更新プログラム等の実施例を詳細に説明する。尚、各実施例により、開示技術が限定されるものではない。また、以下に示す各実施例は、矛盾を起こさない範囲で適宜組み合わせても良い。

図１は、実施例１のデータ提供システム１の一例を示す説明図である。図１に示すデータ提供システム１は、提供者側サーバ２と、利用者側サーバ３とを有する。提供者側サーバ２は、データを提供する提供者側のコンピュータである。利用者側サーバ３は、提供者側サーバから提供されたデータを利用する利用者側のコンピュータである。

提供者側サーバ２は、ネットワークデバイス１１と、周辺機器制御部１２と、ハードディスク１３と、メモリ１４と、ＣＰＵ１５と、バス１６とを有する。ネットワークデバイス１１は、利用者側サーバ３との間の通信を司るＩＦである。周辺機器制御部１２は、例えば、キーボードやマウス等の利用者操作部１７Ａ等やディプレイ等の周辺機器１７を制御する。ハードディスク１３は、各種データ等を記憶する領域である。メモリ１４は、各種プログラム等を記憶する領域である。ＣＰＵ１５は、提供者側サーバ２全体を制御する。バス１６は、ネットワークデバイス１１、周辺機器制御部１２、ハードディスク１３、メモリ１４やＣＰＵ１５と接続するバスラインである。

ハードディスク１３は、提供者側ＲＤＢ（Relational Data Base）１３Ａと、提供条件ＤＢ１３Ｂとを有する。提供者側ＲＤＢ１３Ａは、例えば、提供対象のデータを行単位又は列単位で管理するＤＢである。提供条件ＤＢ１３Ｂは、提供者と利用者との間でデータの提供に関わる条件を管理するＤＢである。

メモリ１４は、データ通信プログラム１４Ａと、クエリ変更プログラム１４Ｂとを記憶する。データ通信プログラム１４Ａは、利用者側サーバ３との間の通信を実行するプログラムである。クエリ変更プログラム１４Ｂは、提供者側ＲＤＢ１３Ａに対するデータのクエリを、利用者側ＲＤＢ２３Ａに対応するクエリに変更するプログラムである。

利用者側サーバ３は、ネットワークデバイス２１と、周辺機器制御部２２と、ハードディスク２３と、メモリ２４と、ＣＰＵ２５と、バス２６とを有する。ネットワークデバイス２１は、提供者側サーバ２との間の通信を司るＩＦである。周辺機器制御部２２は、例えば、キーボードやマウス等の利用者側操作部２７Ａやディプレイ等の周辺機器２７を制御する。ハードディスク２３は、各種データ等を記憶する領域である。メモリ２４は、各種プログラム等を記憶する領域である。ＣＰＵ２５は、利用者側サーバ３全体を制御する。バス２６は、ネットワークデバイス２１、周辺機器制御部２２、ハードディスク２３、メモリ２４やＣＰＵ２５と接続するバスラインである。

ハードディスク２３は、利用者側ＲＤＢ２３Ａを有する。利用者側ＲＤＢ２３Ａは、例えば、利用者側のデータを行単位又は列単位で管理するＤＢである。メモリ２４は、データ通信プログラム２４Ａを記憶する。データ通信プログラム２４Ａは、提供者側サーバ２との間の通信を実行するプログラムである。

図２は、提供者側サーバ２及び利用者側サーバ３の機能構成の一例を示すブロック図である。提供者側サーバ２のＣＰＵ１５は、メモリ１４内のクエリ変更プログラム１４Ｂを読出し、読み出したクエリ変更プログラム１４Ｂを実行することで送信用コネクタ３０のクエリ変更を実行するクエリ変更部３１を有する。更に、提供者側サーバ２のＣＰＵ１５は、メモリ１４内のデータ通信プログラム１４Ａを読み出し、読み出したデータ通信プログラム１４Ａを実行することで送信用コネクタ３０のクエリ送信を実行するクエリ送信部３２を有する。

クエリ変更部３１は、提供者側ＲＤＢ１３Ａ内のデータに対するクエリを利用者側ＲＤＢ２３Ａに応じたクエリに変更する。尚、クエリは、例えば、提供者側ＲＤＢ１３Ａ内のデータの新規挿入、提供者側ＲＤＢ１３Ａ内のデータの削除や更新等の要求である。クエリ送信部３２は、クエリ変更部３１にて変更した利用者側ＲＤＢ２３Ａへのクエリを利用者側サーバ３に送信する。

クエリ変更部３１は、検出部３１Ａと、判定部３１Ｂと、変更部３１Ｃとを有する。検出部３１Ａは、データ供給元のＤＢである提供者側ＲＤＢ１３Ａでのデータ更新を検出する。判定部３１Ｂは、提供者側ＲＤＢ１３Ａでのデータ更新を検出した場合に、更新後の更新対象データがアクセス制御対象であるか否かを判定する。アクセス制御対象は、例えば、提供者側で利用者に提供可能の提供条件を満たしたデータである。変更部３１Ｃは、判定結果に基づいて、データ供給先のＤＢである利用者側ＲＤＢ２３Ａに対して出力する更新対象データに関するクエリを変更する。

判定部３１Ｂは、提供者側ＲＤＢ１３Ａでのデータ更新を検出した場合に、更新対象データが利用者側ＲＤＢ２３Ａ内に既存し、かつ、所定の提供条件を満たしているアクセス制御対象であるか否かを判定する。変更部３１Ｃは、更新対象データがアクセス制御対象である場合に、利用者側ＲＤＢ２３Ａに対して更新対象データを更新する更新クエリを出力する。変更部３１Ｃは、更新対象データがアクセス制御対象でない場合に、データ更新のクエリを、利用者側ＲＤＢ２３Ａから更新対象データを削除する削除クエリに変更する。

判定部３１Ｂは、提供者側ＲＤＢ１３Ａでのデータ更新を検出した場合に、更新対象データが利用者側ＲＤＢ２３Ａ内になく、かつ、所定の提供条件を満たしているアクセス制御対象であるか否かを判定する。変更部３１Ｃは、更新対象データがアクセス制御対象である場合に、データ更新のクエリを、利用者側ＲＤＢ２３Ａに対して更新対象データを挿入する挿入クエリに変更する。

判定部３１Ｂは、提供者側ＲＤＢ１３Ａでのデータ挿入を検出した場合に、挿入対象データがアクセス制御対象となるか否かを判定する。変更部３１Ｃは、挿入対象データがアクセス制御対象の場合に、利用者側ＲＤＢ２３Ａに対して挿入対象データを挿入する挿入クエリを出力する。変更部３１Ｃは、挿入対象データがアクセス制御対象でない場合に、挿入クエリの出力を抑制する。

判定部３１Ｂは、提供者側ＲＤＢ１３Ａでのデータ削除を検出した場合に、削除対象データが利用者側ＲＤＢ２３Ａ内に既存するアクセス制御対象となるか否かを判定する。変更部３１Ｃは、削除対象データがアクセス制御対象の場合に、利用者側ＲＤＢ２３Ａに対して削除対象データを削除する削除クエリを出力する。変更部３１Ｃは、削除対象データがアクセス制御対象でない場合に、削除クエリの出力を抑制する。

利用者側サーバ３のＣＰＵ２５は、メモリ２４内のデータ通信プログラム２４Ａを読み出し、読み出したデータ通信プログラム２４Ａを実行することで受信用コネクタ４０のクエリ受信を実行するクエリ受信部４１を有する。クエリ受信部４１は、提供者側サーバ２内のクエリ送信部３２からのクエリを受信する。

図３は、提供者側ＲＤＢ１３Ａ及び利用者側ＲＤＢ２３Ａのテーブル構成の一例を示す説明図である。図３に示す提供者側ＲＤＢ１３Ａは、提供者が管理する提供対象のデータを管理するＤＢである。提供者側ＲＤＢ１３Ａは、ＩＤ１３１Ａと、名前１３２Ａと、年齢１３３Ａと、情報利用１３４Ａとを対応付けて管理する。ＩＤ１３１Ａは、提供対象のデータを識別するＩＤである。名前１３２Ａは、提供対象のデータの対象者を識別する名前である。年齢１３３Ａは、提供対象のデータの対象者の年齢である。情報利用１３４Ａは、提供対象のデータが利用者に対して情報利用可能、例えば、参照可能にするか否かを識別する識別子である。情報利用１３４Ａは、提供対象のデータが参照可能の場合に“ＴＲＵＥ”、提供対象のデータが参照不可の場合に“ＦＡＬＳＥ”である。

提供者側ＲＤＢ１３Ａは、例えば、ＩＤ“００１１”、名前“Ｒｅｎ”、年齢“５４”及び情報利用“ＴＲＵＥ”のデータ、ＩＤ“００２２”、名前“Ｈｏｎｇ”を記憶している。更に、提供者側ＲＤＢ１３Ａは、年齢“５２”及び情報利用“ＴＲＵＥ”のデータ、ＩＤ“１０１１”、名前“Ｃａｏ”、年齢“５６”及び情報利用“ＦＡＬＳＥ”のデータを記憶している。更に、提供者側ＲＤＢ１３Ａは、例えば、ＩＤ“９０５４”、名前“Ｄａｉ”、年齢“４０”及び情報利用“ＦＡＬＳＥ”のデータ、ＩＤ“０３３３”、名前“Ａｎｇ”、年齢“１５”及び情報利用“ＴＲＵＥ”のデータを記憶している。

また、利用者側ＲＤＢ２３Ａは、提供者から提供されたデータを管理する。尚、利用者側ＲＤＢ２３Ａも、例えば、提供者側ＲＤＢ１３Ａと同様のＩＤ、名前、年齢及び情報利用を対応付けたデータを管理している。

図４は、提供条件のファイルの一例を示す説明図である。図４に示す提供条件のファイルは、識別名と、利用者のデータベース情報と、提供者のデータベース情報と、権限を付与するデータの指定とを、例えば、ｙａｍｌファイル方式で記載するものとする。尚、ｙａｍｌファイル方式に限定されるものではなく、適宜変更可能である。識別名は、提供条件を識別する、例えば、Agreement-001等の名称である。利用者のデータベース情報は、例えば、ホストuser-server等の利用者側ＲＤＢ２３Ａを識別する情報である。提供者のデータベース情報は、例えば、source-serverホストのPostgreSQLというＲＤＢ内のpublic.usersというテーブル等の提供者側ＲＤＢ１３Ａを識別する情報である。権限を付与するデータの指定は、提供者側サーバ２から利用者側サーバ３にデータを提供する条件である。条件としては、例えば、情報利用“ＴＲＵＥ”の場合である。

図５は、他の権限を付与するデータの指定のファイルの一例を示す説明図である。尚、図４に示す権限を付与するデータの指定としては、情報利用が“ＴＲＵＥ”の単一条件の場合を例示した。しかしながら、単一条件に限定されるものではなく、複数条件でも良い。例えば、情報利用が“ＴＲＵＥ”及び年齢が“２０”以上の場合に利用者にデータを提供しても良い。また、例えば、情報利用を創薬目的や公共機関目的の場合のように複数指定可能にし、情報利用（創薬）が“ＴＲＵＥ”又は情報利用（公共機関）が“ＴＲＵＥ”の場合に利用者にデータを提供しても良い。

実施例１のデータ提供システム１の動作について説明する。図６Ａは、データ提供システム１の情報利用（ＦＡＬＳＥ→ＴＲＵＥ）の更新時のクエリ変更動作の一例を示す説明図である。尚、説明の便宜上、提供者側サーバ２から利用者側サーバ３にデータを提供する際の提供条件は情報利用“ＴＲＵＥ”とする。

提供者側サーバ２内の提供者側ＲＤＢ１３Ａは、例えば、ＩＤ“００１１”、名前“Ｒｅｎ”、年齢“５４”及び情報利用“ＴＲＵＥ”のデータ、ＩＤ“００２２”のデータを記憶している。提供者側ＲＤＢ１３Ａは、名前“Ｈｏｎｇ”、年齢“５２”及び情報利用“ＴＲＵＥ”のデータ、ＩＤ“１０１１”、名前“Ｃａｏ”、年齢“５６”及び情報利用“ＦＡＬＳＥ”のデータを記憶している。更に、提供者側ＲＤＢ１３Ａは、例えば、ＩＤ“９０５４”、名前“Ｄａｉ”、年齢“４０”及び情報利用“ＦＡＬＳＥ”のデータ、ＩＤ“０３３３”、名前“Ａｎｇ”、年齢“１５”及び情報利用“ＴＲＵＥ”のデータを記憶している。

また、利用者側サーバ３内の利用者側ＲＤＢ２３Ａは、例えば、ＩＤ“００１１”、名前“Ｒｅｎ”、年齢“５４”及び情報利用“ＴＲＵＥ”のデータ、ＩＤ“００２２”のデータを記憶している。更に、利用者側ＲＤＢ２３Ａは、名前“Ｈｏｎｇ”、年齢“５２”及び情報利用“ＴＲＵＥ”のデータ、ＩＤ“０３３３”、名前“Ａｎｇ”、年齢“１５”及び情報利用“ＴＲＵＥ”のデータを記憶している。

この際、提供者側サーバ２は、提供者側ＲＤＢ１３Ａ内の例えば、ＩＤ“９０５４”、名前“Ｄａｉ”及び年齢“４０”のデータの情報利用“ＦＡＬＳＥ”を“ＴＲＵＥ”に変更する更新クエリが要求されたとする。尚、更新クエリは、例えば、「ＵＰＤＡＴＥ ｔｂｌ、ＳＥＴ 情報利用＝ＴＲＵＥ、ＷＨＥＲＥ ＩＤ＝Ｄａｉ」である。

提供者側サーバ２は、更新クエリに応じて、提供者側ＲＤＢ１３Ａ内のＩＤ“９０５４”、名前“Ｄａｉ”及び年齢“４０”のデータの情報利用“ＦＡＬＳＥ”を“ＴＲＵＥ”に変更する。

クエリ変更部３１は、名前“Ｄａｉ”のデータを情報利用“ＦＡＬＳＥ”から“ＴＲＵＥ”への更新クエリを検出した場合、情報利用が“ＴＲＵＥ”の提供条件を満たしているため、更新クエリを挿入クエリに変更する。尚、変更後の挿入クエリは、例えば、「ＩＮＳＥＲＴ ｔｂｌ、ＶＡＬＵＥＳ［９０５４，Ｄａｉ，４０，ＴＲＵＥ］」である。そして、クエリ送信部３２は、変更後の挿入クエリを利用者側サーバ３に送信する。

利用者側サーバ３内のクエリ受信部４１は、提供者側サーバ２から挿入クエリを受信した場合、利用者側ＲＤＢ２３Ａ内にＩＤ“９０５４”、名前“Ｄａｉ”、年齢“４０”及び情報利用“ＴＲＵＥ”のデータを挿入することになる。

クエリ変更部３１は、提供者側ＲＤＢ１３Ａ内のデータの情報利用が“ＦＡＬＳＥ”から“ＴＲＵＥ”に変更する更新クエリを検出した場合、更新クエリを挿入クエリに変更する。その結果、利用者側サーバ３は、挿入クエリに応じて“ＴＲＵＥ”に変更したデータを利用者側ＲＤＢ２３Ａに登録できるため、提供者側ＲＤＢ１３Ａに対する更新データを利用者側ＲＤＢ２３Ａに反映できる。

図６Ｂは、データ提供システム１の情報利用（ＴＲＵＥ→ＦＡＬＳＥ）の更新時のクエリ変更動作の一例を示す説明図である。尚、説明の便宜上、提供者側サーバ２から利用者側サーバ３にデータを提供する際の提供条件は情報利用“ＴＲＵＥ”とする。

提供者側サーバ２内の提供者側ＲＤＢ１３Ａは、例えば、ＩＤ“９０５４”、名前“Ｄａｉ”、年齢“４０”及び情報利用“ＴＲＵＥ”のデータを記憶している。また、利用者側サーバ３内の利用者側ＲＤＢ２３Ａも、ＩＤ“９０５４”、名前“Ｄａｉ”、年齢“４０”及び情報利用“ＴＲＵＥ”のデータを記憶している。

この際、提供者側サーバ２は、提供者側ＲＤＢ１３Ａ内の例えば、ＩＤ“９０５４”、名前“Ｄａｉ”及び年齢“４０”のデータの情報利用“ＴＲＵＥ”を“ＦＡＬＳＥ”に変更する更新クエリが要求されたとする。この際の更新クエリは、例えば、「ＵＰＤＡＴＥ ｔｂｌ、ＳＥＴ 情報利用＝ＦＡＬＳＥ、ＷＨＥＲＥ ＩＤ＝Ｄａｉ」である。

提供者側サーバ２は、更新クエリに応じて、提供者側ＲＤＢ１３Ａ内のＩＤ“９０５４”、名前“Ｄａｉ”及び年齢“４０”のデータの情報利用“ＴＲＵＥ”を“ＦＡＬＳＥ”に変更する。

クエリ変更部３１は、名前“Ｄａｉ”のデータを情報利用“ＴＲＵＥ”から“ＦＡＬＳＥ”への更新クエリを検出した場合、情報利用が“ＦＡＬＳＥ”の提供条件を満たしていないため、更新クエリを削除クエリに変更する。変更後の削除クエリは、例えば、「ＤＥＬＥＴＥ ｔｂｌ、ＷＨＥＲＥ ＩＤ＝Ｄａｉ」である。そして、クエリ送信部３２は、変更後の削除クエリを利用者側サーバ３に送信する。

利用者側サーバ３内のクエリ受信部４１は、提供者側サーバ２から削除クエリを受信した場合、利用者側ＲＤＢ２３Ａ内に記憶中のＩＤ“９０５４”、名前“Ｄａｉ”、年齢“４０”及び情報利用“ＴＲＵＥ”のデータを削除することになる。

クエリ変更部３１は、提供者側ＲＤＢ１３Ａ内のデータの情報利用が“ＴＲＵＥ”から“ＦＡＬＳＥ”に変更する更新クエリを検出した場合、更新クエリを削除クエリに変更する。その結果、利用者側サーバ３は、削除クエリに応じて“ＦＡＬＳＥ”に変更したデータを利用者側ＲＤＢ２３Ａから削除するため、提供者側ＲＤＢ１３Ａに対する更新データを利用者側ＲＤＢ２３Ａに反映する。そして、提供者は、利用者に対して参照不可のデータの安全性を確保できる。

図６Ｃは、データ提供システム１のデータ削除時のクエリ変更動作の一例を示す説明図である。尚、説明の便宜上、提供者側サーバ２から利用者側サーバ３にデータを提供する際の提供条件は情報利用“ＴＲＵＥ”とする。

提供者側サーバ２内の提供者側ＲＤＢ１３Ａは、例えば、ＩＤ“００１１”、名前“Ｒｅｎ”、年齢“５４”及び情報利用“ＴＲＵＥ”のデータを記憶している。また、利用者側サーバ３内の利用者側ＲＤＢ２３Ａは、例えば、ＩＤ“００１１”、名前“Ｒｅｎ”、年齢“５４”及び情報利用“ＴＲＵＥ”のデータを記憶しているものとする。

この際、提供者側サーバ２は、提供者側ＲＤＢ１３Ａから、例えば、ＩＤ“００１１”、名前“Ｒｅｎ”、年齢“５４”及び情報利用“ＴＲＵＥ”のデータを削除する削除クエリが要求されたとする。この際、削除クエリは、例えば、「ＤＥＬＥＴＥ ｔｂｌ、ＷＨＥＲＥ ＩＤ＝Ｒｅｎ」である。

提供者側サーバ２は、削除クエリに応じて、提供者側ＲＤＢ１３Ａ内のＩＤ“００１１”、名前“Ｒｅｎ”、年齢“５４”及び情報利用“ＴＲＵＥ”のデータを削除することなる。

クエリ変更部３１は、提供者側ＲＤＢ１３Ａ内のＩＤ“００１１”、名前“Ｒｅｎ”、年齢“５４”及び情報利用“ＴＲＵＥ”のデータを削除する削除クエリを検出した場合、削除クエリを出力する。この際、削除クエリは、例えば、「ＤＥＬＥＴＥ ｔｂｌ、ＷＨＥＲＥ ＩＤ＝Ｒｅｎ」である。そして、クエリ送信部３２は、変更後の削除クエリを利用者側サーバ３に送信する。

利用者側サーバ３内のクエリ受信部４１は、提供者側サーバ２から削除クエリを受信した場合、利用者側ＲＤＢ２３ＡからＩＤ“００１１”、名前“Ｒｅｎ”、年齢“５４”及び情報利用“ＴＲＵＥ”のデータを削除することになる。

クエリ変更部３１は、提供者側ＲＤＢ１３Ａ内の指定のデータを削除する削除クエリを検出した場合、削除クエリを利用者側サーバ３に要求する。その結果、利用者側サーバ３は、利用者側ＲＤＢ２３Ａから指定のデータを削除するため、提供者側ＲＤＢ１３Ａに対する更新データを利用者側ＲＤＢ２３Ａに反映する。そして、提供者は、利用者に対して参照不可のデータの安全性を確保できる。

図６Ｄは、データ提供システム１のデータ挿入時のクエリ変更動作の一例を示す説明図である。尚、説明の便宜上、提供者側サーバ２から利用者側サーバ３にデータを提供する際の提供条件は情報利用“ＴＲＵＥ”とする。

提供者側サーバ２内の提供者側ＲＤＢ１３Ａは、例えば、ＩＤ“００１１”、名前“Ｒｅｎ”、年齢“５４”及び情報利用“ＴＲＵＥ”のデータ、ＩＤ“００２２”、名前“Ｈｏｎｇ”、年齢“５２”及び情報利用“ＴＲＵＥ”のデータを記憶している。提供者側ＲＤＢ１３Ａは、ＩＤ“１０１１”、名前“Ｃａｏ”、年齢“５６”及び情報利用“ＦＡＬＳＥ”のデータ、名前“Ａｎｇ”、年齢“１５”及び情報利用“ＴＲＵＥ”のデータを記憶している。

また、利用者側サーバ３内の利用者側ＲＤＢ２３Ａは、例えば、ＩＤ“００１１”、名前“Ｒｅｎ”、年齢“５４”及び情報利用“ＴＲＵＥ”のデータ、ＩＤ“００２２”、名前“Ｈｏｎｇ”、年齢“５２”及び情報利用“ＴＲＵＥ”のデータを記憶している。更に、利用者側ＲＤＢ２３Ａは、ＩＤ“０３３３”、名前“Ａｎｇ”、年齢“１５”及び情報利用“ＴＲＵＥ”のデータを記憶している。

この際、提供者側サーバ２は、例えば、ＩＤ“９０５４”、名前“Ｄａｉ”及び年齢“４０”及び情報利用“ＴＲＵＥ”のデータを提供者側ＲＤＢ１３Ａに挿入する挿入クエリが要求されたとする。この際、挿入クエリは、例えば、「ＩＮＳＥＲＴ ＩＮＴＯ ｔｂｌ、ＶＡＬＵＥＳ［９０５４，Ｄａｉ，４０，ＴＲＵＥ］」である。

提供者側サーバ２は、挿入クエリに応じて、例えば、ＩＤ“９０５４”、名前“Ｄａｉ”、年齢“４０”及び情報利用“ＴＲＵＥ”のデータを利用者側ＲＤＢ２３Ａに挿入する。

クエリ変更部３１は、名前“Ｄａｉ”及び情報利用“ＴＲＵＥ”のデータの挿入クエリを検出した場合、情報利用が“ＴＲＵＥ”の提供条件を満たしているため、挿入クエリを出力する。この際、挿入クエリは、例えば、「ＩＮＳＥＲＴ ｔｂｌ、ＶＡＬＵＥＳ［９０５４，Ｄａｉ，４０，ＴＲＵＥ］」である。そして、クエリ送信部３２は、変更後の挿入クエリを利用者側サーバ３に送信する。

利用者側サーバ３内のクエリ受信部４１は、提供者側サーバ２から挿入クエリを受信した場合、利用者側ＲＤＢ２３Ａ内にＩＤ“９０５４”、名前“Ｄａｉ”、年齢“４０”及び情報利用“ＴＲＵＥ”のデータを挿入することになる。

クエリ変更部３１は、情報利用“ＴＲＵＥ”のデータの挿入クエリを検出した場合、挿入クエリを利用者側サーバ３に要求する。その結果、利用者側サーバ３は、情報利用“ＴＲＵＥ”のデータを利用者側ＲＤＢ２３Ａに登録できるため、提供者側ＲＤＢ１３Ａに対する更新データを利用者側ＲＤＢ２３Ａに反映する。そして、提供者は、利用者に参照可のデータを提供できる。

図７は、データ更新処理に関わるクエリ変更部３１の処理動作の一例を示すフローチャートである。尚、ログ種類は、例えば、挿入クエリ、削除クエリや更新クエリ等のログである。挿入クエリは、提供者側ＲＤＢ１３Ａに新規の挿入対象データを挿入する際のクエリである。削除クエリは、提供者側ＲＤＢ１３Ａに記憶中の削除対象データを削除する際のクエリである。更新クエリは、提供者側ＲＤＢ１３Ａに記憶中の更新対象データの一部を更新する際のクエリである。提供条件とは、例えば、提供者側ＲＤＢ１３Ａ内のデータの内、情報利用“ＴＲＵＥ”のデータを利用者に提供する条件である。

図７において提供者側サーバ２のクエリ変更部３１内の検出部３１Ａは、提供者側ＲＤＢ１３Ａに対するログを検出したか否かを判定する（ステップＳ１１）。検出部３１Ａは、提供者側ＲＤＢ１３Ａに対するログを検出した場合（ステップＳ１１：Ｙｅｓ）、ログ種類を判定する（ステップＳ１２）。

クエリ変更部３１内の判定部３１Ｂは、ログ種類が提供者側ＲＤＢ１３Ａに新規の挿入対象データを挿入する挿入クエリの場合、挿入対象データが提供条件を満たしたか否かを判定する（ステップＳ１３）。例えば、判定部３１Ｂは、提供者側ＲＤＢ１３Ａに挿入対象のデータの情報利用が“ＴＲＵＥ”であるか否かを判定する。

変更部３１Ｃは、挿入対象データが提供条件を満たした場合（ステップＳ１３：Ｙｅｓ）、すなわち挿入対象データの情報利用が“ＴＲＵＥ”の場合、挿入対象データを利用者側ＲＤＢ２３Ａに挿入する挿入クエリを出力する（ステップＳ１４）。そして、クエリ変更部３１は、クエリ送信部３２を通じて挿入クエリを利用者側サーバ３に送信した後、図７に示す処理動作を終了する。判定部３１Ｂは、挿入対象データが提供条件を満たしていない場合（ステップＳ１３：Ｎｏ）、すなわち挿入対象データの情報利用が“ＦＡＬＳＥ”の場合、挿入対象データを利用者側ＲＤＢ２３Ａに挿入することなく、挿入クエリを抑制し、図７に示す処理動作を終了する。

判定部３１Ｂは、ログ種類が提供者側ＲＤＢ１３Ａに記憶中のデータを削除する削除クエリの場合、削除対象データが利用者側ＲＤＢ２３Ａ内にあるか否かを判定する（ステップＳ１５）。変更部３１Ｃは、削除対象データが利用者側ＲＤＢ２３Ａ内にある場合（ステップＳ１５：Ｙｅｓ）、削除対象データを利用者側ＲＤＢ２３Ａから削除する削除クエリを出力する（ステップＳ１６）。そして、クエリ変更部３１は、クエリ送信部３２を通じて削除クエリを利用者側サーバ３に送信した後、図７に示す処理動作を終了する。判定部３１Ｂは、削除対象データが利用者側ＲＤＢ２３Ａ内にない場合（ステップＳ１５：Ｎｏ）、削除クエリを抑制し、図７に示す処理動作を終了する。

判定部３１Ｂは、ログ種類が提供者側ＲＤＢ１３Ａに記憶中のデータの一部を変更する更新クエリの場合、更新対象データが利用者側ＲＤＢ２３Ａ内にあるか否かを判定する（ステップＳ１７）。判定部３１Ｂは、更新対象データが利用者側ＲＤＢ２３Ａ内にある場合（ステップＳ１７：Ｙｅｓ）、更新対象データが提供条件を満たしたか否かを判定する（ステップＳ１８）。例えば、判定部３１Ｂは、提供者側ＲＤＢ１３Ａ内に更新対象データの情報利用が“ＴＲＵＥ”であるか否かを判定する。

変更部３１Ｃは、更新対象データが提供条件を満たした場合（ステップＳ１８：Ｙｅｓ）、すなわち更新対象データの情報利用が“ＴＲＵＥ”の場合、更新対象データを利用者側ＲＤＢ２３Ａに更新する更新クエリを出力する（ステップＳ１９）。そして、クエリ変更部３１は、クエリ送信部３２を通じて更新クエリを利用者側サーバ３に送信した後、図７に示す処理動作を終了する。変更部３１Ｃは、更新対象データが提供条件を満たしていない場合（ステップＳ１８：Ｎｏ）、すなわち更新対象データの情報利用が“ＦＡＬＳＥ”と判断する。変更部３１Ｃは、更新対象データの情報利用が“ＦＡＬＳＥ”の場合、更新クエリを、更新対象データを利用者側ＲＤＢ２３Ａから削除する削除クエリに変更する（ステップＳ２０）。そして、クエリ変更部３１は、クエリ送信部３２を通じて削除クエリを利用者側サーバ３に送信した後、図７に示す処理動作を終了する。

判定部３１Ｂは、更新対象データが利用者側ＲＤＢ２３Ａ内にない場合（ステップＳ１７：Ｎｏ）、更新対象データが提供条件を満たしたか否かを判定する（ステップＳ２１）。例えば、判定部３１Ｂは、提供者側ＲＤＢ１３Ａに更新対象データの情報利用が“ＴＲＵＥ”であるか否かを判定する。

変更部３１Ｃは、更新対象データが提供条件を満たした場合（ステップＳ２１：Ｙｅｓ）、すなわち更新対象データの情報利用が“ＴＲＵＥ”の場合、更新クエリを、更新対象データを利用者側ＲＤＢ２３Ａに挿入する挿入クエリに変更する（ステップＳ２２）。そして、クエリ変更部３１は、クエリ送信部３２を通じて挿入クエリを利用者側サーバ３に送信した後、図７に示す処理動作を終了する。クエリ変更部３１は、更新対象データが提供条件を満たしていない場合（ステップＳ２１：Ｎｏ）、すなわち更新対象データの情報利用が“ＦＡＬＳＥ”の場合、更新対象データを利用者側ＲＤＢ２３Ａに挿入することなく、図７に示す処理動作を終了する。

クエリ変更部３１は、挿入クエリの挿入対象データが提供条件を満たした場合、すなわち挿入対象データの情報利用が“ＴＲＵＥ”の場合、挿入対象データを利用者側ＲＤＢ２３Ａに挿入する挿入クエリを利用者側サーバ３に出力する。その結果、提供者側ＲＤＢ１３Ａ内で挿入クエリが発生した場合でも、利用者側ＲＤＢ２３Ａ内に挿入対象データを挿入できる。

クエリ変更部３１は、挿入クエリの挿入対象データが提供条件を満たしていない場合、すなわち挿入対象データの情報利用が“ＦＡＬＳＥ”の場合、挿入対象データを提供者側ＲＤＢ１３Ａのみに挿入する。その結果、提供者側ＲＤＢ１３Ａは、挿入対象データを追加して登録できる。提供者は、利用者側サーバ３に対して挿入対象データの安全性を確保できる。

クエリ変更部３１は、削除クエリの削除対象データが利用者側ＲＤＢ２３Ａ内にある場合、削除対象データを利用者側ＲＤＢ２３Ａから削除する削除クエリを利用者側サーバ３に出力する。その結果、提供者側ＲＤＢ１３Ａ内で削除クエリが発生した場合でも、利用者側ＲＤＢ２３Ａから削除対象データを削除できる。

クエリ変更部３１は、更新クエリの更新対象データが利用者側ＲＤＢ２３Ａ内にあり、かつ、更新対象データが提供条件を満たした、すなわち更新対象データの情報利用が“ＴＲＵＥ”の場合、更新クエリを出力する。更に、クエリ変更部３１は、更新クエリを利用者側サーバ３に送信する。その結果、提供者側ＲＤＢ１３Ａ内で情報利用“ＴＲＵＥ”の更新対象データの更新クエリが発生した場合でも、利用者側ＲＤＢ２３Ａに情報利用“ＴＲＵＥ”の更新対象データを更新できる。

クエリ変更部３１は、更新クエリの更新対象データが利用者側ＲＤＢ２３Ａ内にあり、かつ、更新対象データが提供条件を満たしていない、すなわち更新対象データの情報利用が“ＦＡＬＳＥ”の場合、更新クエリを削除クエリに変更する。更に、クエリ変更部３１は、削除クエリを利用者側サーバ３に送信する。その結果、提供者側ＲＤＢ１３Ａ内で情報利用“ＦＡＬＳＥ”の更新対象データの更新クエリが発生した場合でも、利用者側ＲＤＢ２３Ａから情報利用“ＦＡＬＳＥ”の更新対象データを削除できる。提供者は、利用者側サーバ３に対して更新対象データの安全性を確保できる。

クエリ変更部３１は、更新クエリの更新対象データが利用者側ＲＤＢ２３Ａ内になく、かつ、更新対象データが提供条件を満たした、すなわち更新対象データの情報利用が“ＴＲＵＥ”の場合、更新クエリを挿入クエリに変更する。更に、クエリ変更部３１は、挿入クエリを利用者側サーバ３に送信する。その結果、提供者側ＲＤＢ１３Ａ内で情報利用“ＴＲＵＥ”の更新対象データの更新クエリが発生した場合でも、利用者側ＲＤＢ２３Ａに情報利用“ＴＲＵＥ”の更新対象データを挿入できる。

実施例１の提供者側サーバ２は、提供者側ＲＤＢ１３Ａでのデータ更新を検出した場合に、更新後の更新対象データがアクセス制御対象であるか否かを判定する。提供者側サーバ２は、判定結果に基づいて利用者側ＲＤＢ２３Ａに対する更新対象データのクエリを変更する。その結果、提供者側ＲＤＢ１３Ａに対する更新データの安全性を確保しながら、更新データを利用者側ＲＤＢ２３Ａに安全に反映できる。

提供者側サーバ２は、提供者側ＲＤＢ１３Ａでのデータ更新を検出した場合に、更新対象データが利用者側ＲＤＢ２３Ａ内に既存し、かつ、所定の提供条件を満たしているアクセス制御対象であるか否かを判定する。提供者側サーバ２は、更新対象データがアクセス制御対象である場合に、データ更新の更新クエリを利用者側ＲＤＢ２３Ａに出力する。その結果、提供者側ＲＤＢ１３Ａに対する更新データの安全性を確保しながら、更新データを利用者側ＲＤＢ２３Ａに反映できる。

提供者側サーバ２は、更新対象データがアクセス制御対象でない場合に、データ更新のクエリを利用者側ＲＤＢ２３Ａへの削除クエリに変更する。その結果、提供者側ＲＤＢ１３Ａに対する更新データの安全性を確保しながら、更新データを利用者側ＲＤＢ２３Ａに反映できる。

提供者側サーバ２は、提供者側ＲＤＢ１３Ａでのデータ更新を検出した場合に、更新対象データが利用者側ＲＤＢ２３Ａ内になく、かつ、所定の提供条件を満たしているアクセス制御対象であるか否かを判定する。提供者側サーバ２は、更新対象データがアクセス制御対象である場合に、データ更新のクエリを利用者側ＲＤＢ２３Ａへの挿入クエリに変更する。その結果、提供者側ＲＤＢ１３Ａに対する更新データの安全性を確保しながら、更新データを利用者側ＲＤＢ２３Ａに反映できる。

提供者側サーバ２は、提供者側ＲＤＢ１３Ａでのデータ削除を検出した場合に、削除対象データが利用者側ＲＤＢ２３Ａ内に既存するアクセス制御対象であるか否かを判定する。提供者側サーバ２は、削除対象データがアクセス制御対象である場合に、利用者側ＲＤＢ２３Ａに対して削除対象データを削除する削除クエリを出力する。更に、提供者側サーバ２は、削除対象データがアクセス制御対象でない場合に、利用者側ＲＤＢ２３Ａへの削除クエリの出力を抑制する。その結果、提供者側ＲＤＢ１３Ａに対する更新データの安全性を確保しながら、更新データを利用者側ＲＤＢ２３Ａに反映できる。

提供者側サーバ２は、提供者側ＲＤＢ１３Ａでのデータ挿入を検出した場合に、挿入対象データがアクセス制御対象であるか否かを判定する。提供者側サーバ２は、挿入対象データがアクセス制御対象である場合に、利用者側ＲＤＢ２３Ａに対して挿入対象データを挿入する挿入クエリを出力する。更に、提供者側サーバ２は、挿入対象データがアクセス制御対象でない場合に、利用者側ＲＤＢ２３Ａへの挿入クエリの出力を抑制する。その結果、提供者側ＲＤＢ１３Ａに対する更新データの安全性を確保しながら、更新データを利用者側ＲＤＢ２３Ａに反映できる。

実施例１では、提供条件を反映したクエリ変更機構を備え、提供条件を満たしていないデータは利用者に提供することなく、利用者に提供する前に弾かれることをデータの安全性を確保できる。更に、提供者側ＲＤＢ１３Ａ内の更新データを利用者側ＲＤＢ２３Ａに反映できる。

例えば、１日毎に提供者側サーバ２から利用者側サーバ３にデータを提供し、利用者側ＲＤＢ２３Ａ内の１日のデータ数をＭ行（Ｍ個）の内、更新データ数をＮ行（Ｎ個）と仮定する。この場合、図１５に示す第５のデータ提供システム３４０では、提供者側サーバ３４２から利用者側サーバ３４３に提供するデータ量がＭ個分のデータ量に相当する。これに対して、本実施例のデータ提供システム１では、提供者側サーバ２から利用者側サーバ３にデータを提供する場合、少なくとも更新データ数Ｎ個分のログ情報で済む。ログ情報は、更新前後のデータを有するため、通常のデータの２倍のデータ量と仮定した場合でも、提供者側サーバ２から利用者側サーバ３に送信する際のデータ量が２Ｎ／Ｍとなる。従って、実施例１の提供者側サーバ２から利用者側サーバ３にデータを伝送する効率は、Ｍ行が多く、Ｎ行が少なくなるほど高くなることになる。例えば、提供データ１００万件の内、１日で１０００件のデータが更新されるとき、送信データ量は、図１５の第５のデータ提供システム３４０の送信データ量の０.００２倍で済む。また、例えば、提供データ５０００件の内、１日で１０００件のデータが更新される場合は、送信データ量は、第５のデータ提供システム３４０の送信データ量の０．４倍で済む。

尚、実施例１では、提供者側サーバ２のコンピュータと利用者側サーバ３のコンピュータとで実現する場合を例示したが、単一のコンピュータ内で提供者側サーバ２及び利用者側サーバ３を仮想化して実現しても良く、適宜変更可能である。

尚、実施例１のデータ提供システム１では、提供者側サーバ２から利用者側サーバ３に提供条件に応じたデータを提供する１対１のシステムを例示した。しかしながら、複数の提供者側サーバ２から複数の利用者側サーバ３に提供条件に応じたデータを提供する複数対複数のシステムに適用しても良く、その実施の形態につき、実施例２として以下に説明する。

図８は、実施例２のデータ提供システム１Ａの一例を示す説明図である。図８に示すデータ提供システム１Ａは、複数の提供者側サーバ２と、複数の利用者側サーバ３と、プラットフォームサーバ５とを有する。複数の提供者側サーバ２は、例えば、提供者Ａの提供者側サーバ２Ａと、提供者Ｂの提供者側サーバ２Ｂとを有する。複数の利用者側サーバ３は、例えば、利用者Ｃの利用者側サーバ３Ａと、利用者Ｄの利用者側サーバ３Ｂと、利用者Ｅの利用者側サーバ３Ｃとを有する。

プラットフォームサーバ５は、複数の提供者側サーバ２と複数の利用者側サーバ３との間のクエリをキューするメッセージキュー５１と、提供条件ＤＢ５２とを有する。尚、実施例１の提供条件ＤＢ１３Ｂは、提供者側サーバ２内で管理するのに対し、提供条件ＤＢ５２は、全ての提供条件をプラットフォームサーバ５内で管理する。

各提供者側サーバ２内のクエリ変更部３１は、提供条件ＤＢ５２内の提供条件を取得し、更新クエリの更新対象データ又は挿入クエリの挿入対象データが提供条件を満たしたか否かを判定する。

クエリ変更部３１は、挿入クエリを検出した場合に提供条件をプラットフォームサーバ５から取得する。クエリ変更部３１は、挿入クエリの挿入対象データが提供条件を満たした場合、すなわち挿入対象データの情報利用が“ＴＲＵＥ”の場合、挿入対象データを利用者側ＲＤＢ２３Ａに挿入する挿入クエリをメッセージキュー５１経由で利用者側サーバ３に出力する。その結果、提供者側ＲＤＢ１３Ａ内で挿入クエリが発生した場合でも、利用者側ＲＤＢ２３Ａ内に挿入対象データを挿入できる。

クエリ変更部３１は、挿入クエリの挿入対象データが提供条件を満たしていない場合、すなわち挿入対象データの情報利用が“ＦＡＬＳＥ”の場合、挿入対象データを提供者側ＲＤＢ１３Ａのみに挿入する。その結果、提供者側ＲＤＢ１３Ａは、挿入対象データを追加して登録できる。提供者は、利用者側サーバ３に対して挿入対象データの安全性を確保できる。

クエリ変更部３１は、削除クエリの削除対象データが利用者側ＲＤＢ２３Ａ内にある場合、削除対象データを利用者側ＲＤＢ２３Ａから削除する削除クエリをメッセージキュー５１経由で利用者側サーバ３に出力する。その結果、提供者側ＲＤＢ１３Ａ内で削除クエリが発生した場合でも、利用者側ＲＤＢ２３Ａから削除対象データを削除できる。

クエリ変更部３１は、更新クエリを検出した場合に提供条件をプラットフォームサーバ５から取得する。クエリ変更部３１は、更新クエリの更新対象データが利用者側ＲＤＢ２３Ａ内にあり、かつ、更新対象データが提供条件を満たした、すなわち更新対象データの情報利用が“ＴＲＵＥ”の場合、更新クエリを出力する。クエリ変更部３１は、更新クエリをメッセージキュー５１経由で利用者側サーバ３に送信する。その結果、提供者側ＲＤＢ１３Ａ内で情報利用“ＴＲＵＥ”の更新対象データの更新クエリが発生した場合でも、利用者側ＲＤＢ２３Ａに情報利用“ＴＲＵＥ”の更新対象データを更新できる。

クエリ変更部３１は、更新クエリの更新対象データが利用者側ＲＤＢ２３Ａ内にあり、かつ、更新対象データが提供条件を満たしていない、すなわち更新対象データの情報利用が“ＦＡＬＳＥ”の場合、更新クエリを削除クエリに変更する。クエリ変更部３１は、削除クエリをメッセージキュー５１経由で利用者側サーバ３に送信する。その結果、提供者側ＲＤＢ１３Ａ内で情報利用“ＦＡＬＳＥ”の更新対象データの更新クエリが発生した場合でも、利用者側ＲＤＢ２３Ａから情報利用“ＦＡＬＳＥ”の更新対象データを削除できる。提供者は、利用者側サーバ３に対して挿入対象データの安全性を確保できる。

クエリ変更部３１は、更新クエリを検出した場合に提供条件をプラットフォームサーバ５から取得する。クエリ変更部３１は、更新クエリの更新対象データが利用者側ＲＤＢ２３Ａ内になく、かつ、更新対象データが提供条件を満たした、すなわち更新対象データの情報利用が“ＴＲＵＥ”の場合、更新クエリを挿入クエリに変更する。クエリ変更部３１は、挿入クエリをメッセージキュー５１経由で利用者側サーバ３に送信する。その結果、提供者側ＲＤＢ１３Ａ内で情報利用“ＴＲＵＥ”の更新対象データの更新クエリが発生した場合でも、利用者側ＲＤＢ２３Ａに情報利用“ＴＲＵＥ”の更新対象データを挿入できる。

実施例２では、複数の提供者側サーバ２と複数の利用者側サーバ３との間をプラットフォームサーバ５で接続し、プラットフォームサーバ５は単一のコンピュータで実現する場合を例示した。しかしながら、提供者側サーバ２及び利用者側サーバ３を単一のコンピュータ内で仮想化して実現しても良く、また、提供者側サーバ２、利用者側サーバ３及びプラットフォームサーバ５を単一のコンピュータ内で仮想化して実現しても良く、適宜変更可能である。

提供者側ＲＤＢ１３Ａは、ＩＤ毎に名前、年齢及び情報利用を対応付けてデータを管理する場合を例示したが、そのデータ内容は適宜変更可能である。また、提供者側ＲＤＢ１３Ａは、管理するデータが個人情報に限定されるものではなく、利用者に提供可能なデータであれば良く、適宜変更可能である。

また、図示した各部の各構成要素は、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各部の分散・統合の具体的形態は図示のものに限られず、その全部又は一部を、各種の負荷や使用状況等に応じて、任意の単位で機能的又は物理的に分散・統合して構成することができる。

更に、各装置で行われる各種処理機能は、ＣＰＵ（Central Processing Unit）、ＤＳＰ（Digital Signal Processor）やＦＰＧＡ（Field Programmable Gate Array）等上で、その全部又は任意の一部を実行するようにしても良い。また、各種処理機能は、ＣＰＵ等で解析実行するプログラム上、又はワイヤードロジックによるハードウェア上で、その全部又は任意の一部を実行するようにしても良い。

各種情報を記憶する領域は、例えば、ＲＯＭ（Read Only Memory）や、ＳＤＲＡＭ（Synchronous Dynamic Random Access Memory）、ＭＲＡＭ（Magnetoresistive Random Access Memory）やＮＶＲＡＭ（Non-Volatile Random Access Memory）等のＲＡＭ（Random Access Memory）で構成しても良い。

ところで、本実施例で説明した各種の処理は、予め用意されたプログラムをコンピュータ内のＣＰＵ等のプロセッサで実行させることによって実現できる。そこで、以下では、上記実施例と同様の機能を有するプログラムを実行するコンピュータ２００の一例を説明する。図９は、データ更新プログラムを実行するコンピュータ２００の一例を示す説明図である。

図９に示すデータ更新プログラムを実行するコンピュータ２００は、通信ＩＦ２１０と、入力装置２２０と、出力装置２３０と、ＲＯＭ２４０と、ＲＡＭ２５０と、ＣＰＵ２６０と、バス２７０とを有する。通信ＩＦ２１０、入力装置２２０、出力装置２３０、ＲＯＭ２４０、ＲＡＭ２５０及びＣＰＵ２６０は、バス２７０を介して接続される。ＲＡＭ２５０は、データ供給元のデータベースである。通信ＩＦ２１０は、データ供給先のデータベースを管理する他のコンピュータとの通信を司る。

そして、ＲＯＭ２４０には、上記実施例と同様の機能を発揮するデータ更新プログラムが予め記憶されている。ＲＯＭ２４０は、データ更新プログラムとして検出プログラム２４０Ａ、判定プログラム２４０Ｂ及び変更プログラム２４０Ｃが記憶されている。尚、ＲＯＭ２４０ではなく、図示せぬドライブでコンピュータ読取可能な記録媒体に充電制御プログラムが記録されていても良い。また、記録媒体としては、例えば、ＣＤ−ＲＯＭ、ＤＶＤディスク、ＵＳＢメモリ等の可搬型記録媒体、フラッシュメモリ等の半導体メモリ等でも良い。

そして、ＣＰＵ２６０は、検出プログラム２４０ＡをＲＯＭ２４０から読み出し、ＲＡＭ２５０上で検出プロセス２５０Ａとして機能させる。更に、ＣＰＵ２６０は、判定プログラム２４０ＢをＲＯＭ２４０から読み出し、ＲＡＭ２５０上で判定プロセス２５０Ｂとして機能させる。更に、ＣＰＵ２６０は、変更プログラム２４０ＣをＲＯＭ２４０から読み出し、ＲＡＭ２５０上で変更プロセス２５０Ｃとして機能させる。

ＣＰＵ２６０は、データ供給元のデータベースでのデータ更新を検出した場合に、更新後の更新対象データがアクセス制御対象であるか否かを判定する。ＣＰＵ２６０は、判定結果に基づいて、データ供給先のデータベースに対して出力する、更新対象データに関するクエリを変更する。その結果、データ供給元のデータベースに対する更新データの安全性を確保しながら、更新データをデータ供給先のデータベースに安全に反映できる。

１ データ提供システム
２ 提供者側サーバ
３ 利用者側サーバ
１３Ａ 提供者側ＲＤＢ
２３Ａ 利用者側ＲＤＢ
３１ クエリ変更部
３１Ａ 検出部
３１Ｂ 判定部
３１Ｃ 変更部

Claims (8)

1. データ供給元のデータベースでのデータ更新を検出した場合に、更新後の更新対象データがアクセス制御対象であるか否かを判定し、
   判定結果に基づいて、データ供給先のデータベースに対して出力する、前記更新対象データに関するクエリを変更する
   処理をコンピュータに実行させることを特徴とするデータ更新プログラム。
2. 前記判定する処理は、前記データ供給元のデータベースでのデータ更新を検出した場合に、前記更新対象データが前記データ供給先のデータベース内に既存し、かつ、所定の提供条件を満たしているアクセス制御対象であるか否かを判定し、
   前記変更する処理は、前記更新対象データが前記アクセス制御対象である場合に、前記データ供給先のデータベースに対して前記更新対象データを更新する更新クエリを出力する
   ことを特徴とする請求項１に記載のデータ更新プログラム。
3. 前記変更する処理は、前記更新対象データが前記アクセス制御対象でない場合に、前記データ更新のクエリを、前記データ供給先のデータベースから前記更新対象データを削除する削除クエリに変更する
   ことを特徴とする請求項２に記載のデータ更新プログラム。
4. 前記判定する処理は、前記データ供給元のデータベースでのデータ更新を検出した場合に、前記更新対象データが前記データ供給先のデータベース内になく、かつ、所定の提供条件を満たしているアクセス制御対象であるか否かを判定し、
   前記変更する処理は、前記更新対象データが前記アクセス制御対象である場合に、前記データ更新のクエリを、前記データ供給先のデータベースに対して前記更新対象データを挿入する挿入クエリに変更する
   ことを特徴とする請求項１に記載のデータ更新プログラム。
5. 前記判定する処理は、前記データ供給元のデータベースでのデータ削除を検出した場合に、削除対象データが前記データ供給先のデータベース内に既存するアクセス制御対象であるか否かを判定し、
   前記変更する処理は、前記削除対象データが前記アクセス制御対象である場合に、前記データ供給先のデータベースに対して削除対象データを削除する削除クエリを出力すると共に、前記削除対象データが前記アクセス制御対象でない場合に、前記削除クエリの出力を抑制する
   ことを特徴とする請求項１に記載のデータ更新プログラム。
6. 前記判定する処理は、前記データ供給元のデータベースでのデータ挿入を検出した場合に、挿入対象データがアクセス制御対象であるか否かを判定し、
   前記変更する処理は、前記挿入対象データが前記アクセス制御対象である場合に、前記データ供給先のデータベースに対して挿入対象データを挿入する挿入クエリを出力すると共に、前記挿入対象データが前記アクセス制御対象でない場合に、前記挿入クエリの出力を抑制する
   ことを特徴とする請求項１に記載のデータ更新プログラム。
7. データ供給元のデータベースでのデータ更新を検出した場合に、更新後の更新対象データがアクセス制御対象であるか否かを判定する判定部と、
   前記判定部の判定結果に基づいて、データ供給先のデータベースに対して出力する、前記更新対象データに関するクエリを変更する変更部と
   を有することを特徴とするデータ更新装置。
8. コンピュータが、
   データ供給元のデータベースでのデータ更新を検出した場合に、更新後の更新対象データがアクセス制御対象であるか否かを判定し、
   判定結果に基づいてデータ供給先のデータベース）に対して出力する、前記更新対象データに関するクエリを変更する
   処理を実行することを特徴とするデータ更新方法。

Images