JP2015138298A - 管理装置、その制御方法およびコンピュータプログラム - Google Patents

Abstract

【課題】クエリの形式に応じて非同期でデータが削除される場合に、クライアントから受信したデータ取得依頼に対し、非同期による削除対象のデータが含まれないようにデータを制御する管理装置を提供すること。
【解決手段】管理装置１１１は、データベース１１２に対し非同期でデータを削除するよう指示し、削除クエリを受信したことに応じて、クライアント１００から受信したデータベース１１２からデータを取得するための取得クエリにより取得されることとなるデータの中に、削除クエリにより削除されるデータが含まれないよう取得クエリの検索条件を変更するための情報を保存する。管理装置１１１は、取得クエリを受信したことに応じて、保存された情報を基に取得クエリの検索条件を変更しデータベース１１２からデータを取得する。
【選択図】 図２

Description

本発明は、クライアント装置から受け付けたリクエストに応じてデータベースに対してデータを取得または削除しデータを管理する技術に関する。

クラウドサービスの普及に伴い、ネットワーク経由で各種データの管理を行うデータ管理システムが提案されている。このようなシステムでは、複数のクライアント装置とデータ管理システムとが、ＬＡＮ（Local Area Network）、ＷＡＮ（Wide Area Network）、インターネットなどを介して互いに接続されている。近年では、ＯＤａｔａ（Open Data Protocol）と呼ばれるＷｅｂデータプロトコルのように、Ｗｅｂ上のデータベースリソースに対する検索条件をクエリオプション形式を用いてフレキシブルに指定できる技術も広く一般化してきている。ＯＤａｔａでは、ＵＲＩにクエリオプションを記述でき、フィルタオプションを用いることでデータベースが管理するデータの取得、削除などの検索条件を指定できる。フィルタオプションでは、論理演算子や比較演算子、算術演算子を複数組み合わせて使うことができる。このような技術を適用することにより、クライアント装置は、ネットワーク経由でデータ管理システムに対して、任意の複雑な検索条件でデータを登録したり削除することができる。

このようなクライアント−サーバ型のデータ管理システムにおいて、管理システムが大量のデータを処理する場合がある。管理システムは、データベースに対する登録、更新、削除処理が遅い場合には、クライアント装置へ応答を早く返すためにしばしばバッチ処理で処理する形態を採る。この形態では、データ管理システムは、クライアント装置からのリクエスト受信時にデータベースに対する処理の内容をファイルやテーブルに記録し、その時点でクライアント装置へ応答を返す。そして、データ管理システムの別のバックグラウンドの処理で、ファイルやテーブルに記録された内容を読み込み、データベースに対する処理を実行する。

しかし、このようなバッチ処理では、データベースへの反映がクライアント装置に応答を返すタイミングより遅れる。そのため、クライアント装置からは削除処理が終了しているように見えても当該データを取得できてしまう、といった不整合が起こりうる。一般的に、データベースへの反映遅れに伴う不整合を防止するため、削除対象のデータを取得できないような対策が行われる。多くの処理をバッチ処理で実行させようとすると、バックグラウンドでのバッチ処理の負荷が増大するだけでなく、この不整合を防止する管理が複雑になる。そのため、データベースに対する処理の時間が問題にならないのであれば、クライアント装置からのリクエスト受信時にデータベースに対する処理までを完了させるリアルタイム処理で実行させることが望ましい。

このような場合を鑑み、特許文献１は、データベースに対する登録、更新、削除処理に要する時間を推計し、その推計値に応じてリアルタイム処理とバッチ処理とを切り替える方法を提案している。データベースに対する処理が早く終わると推定される処理をバッチ処理にしないことで、データベースへの登録や更新、削除を迅速に行うとともに、バッチ処理の負荷も軽減させることができる。

特開平９−３１９６３５号公報

データベースに対するデータ削除の条件を、ＯＤａｔａのようにクエリオプション形式でフレキシブルに指定できるようにした場合、その削除条件によって時間がかかるケースが存在する。特許文献１に開示された技術は、クライアント装置からのデータの削除リクエストにおいて、削除対象のデータ件数が予めわかっていることを前提としている。削除対象のデータ件数情報に基づいてレコード操作の処理時間を推計し、それによってリアルタイム処理とバッチ処理とを切り替えるようにしている。しかしながら、データベースに対する削除条件をクエリオプション形式を用いてフレキシブルに指定できる場合、クエリオプションの条件文からは削除対象のレコード数を把握することが困難である。また、削除条件をフレキシブルに指定できるため、バッチ処理とした場合のデータベースへの反映遅れに伴う不整合の対策も困難となる。

本発明は、クエリの形式に応じて非同期でデータが削除される場合に、クライアントから受信したデータ取得依頼に対し、非同期による削除対象のデータが含まれないようにデータを制御する管理装置を提供することを目的とする。

本発明の一実施形態の管理装置は、データベースに対し非同期でデータを削除するよう指示する指示手段と、削除クエリを受信したことに応じて、クライアントから受信した前記データベースからデータを取得するための取得クエリにより取得されることとなるデータの中に、前記削除クエリにより削除されるデータが含まれないよう前記取得クエリの検索条件を変更するための情報を保存する保存手段と、前記取得クエリを受信したことに応じて、前記保存手段により保存された情報を基に前記取得クエリの検索条件を変更し前記データベースからデータを取得する取得手段と、を備える。

本発明の管理装置によれば、クエリの形式に応じて非同期でデータが削除される場合に、クライアントから受信したデータ取得依頼に対し、非同期による削除対象のデータが含まれないようにデータを制御することが可能となる。また、クエリオプション形式を用いてフレキシブルに指定できるようにした場合でも非同期で一部のデータが削除されるため、クライアント装置からのリクエストに対するレスポンス効率を向上させることが可能となる。

本発明の一実施形態のシステム構成例を示す図である。 実施例１のデータ管理システムのソフトウェア構成例を示す図である。 クライアント装置がデータ管理システムに送信するリクエストの例を示す。 実施例１のデータベースサーバが備える削除条件テーブルの一例である。 リクエスト受信時の処理を示すフローチャートである。 演算子変換ロジックテーブルと除外条件の一例である。 バッチ処理での削除処理を示すフローチャートである。 実施例２のデータ管理システムのソフトウェア構成例を示す図である。 実施例２のデータベースサーバが備える削除条件テーブルの一例である。 リクエスト受信時の処理を示すフローチャートである。 リクエスト受信時の処理を示すフローチャートである。

（実施例１）
以下、本発明を実施するための形態について図面を用いて説明する。図１は、本発明の一実施形態に係るシステム構成例を示す図である。クライアント装置１００とデータ管理システム１１０は、互いに通信回線１２０を介して接続されている。クライアント装置１００は、ユーザが直接操作するＰＣや、ユーザにサービスを提供するアプリケーションサーバなどが想定される。データ管理システム１１０に接続されるクライアント装置１００は、複数存在しても良い。

データ管理システム１１０は、ウェブサーバ１１１とデータベースサーバ１１２とから構成され、ユーザにサービスを提供するための各種データを格納し、管理する。ウェブサーバ１１１は、通信回線１２０とファイアウォールなどを介して接続され、クライアント装置１００から、データの取得や登録、削除のリクエストを受け付ける。データベースサーバ１１２は、データベースに格納された各種データの取得や登録、削除の処理を行う。また、データベースサーバ１１２は、クライアント装置１００がリクエストによって操作できるデータのほか、データ管理システム１１０が動作するのに必要な管理データも保持する。

これらデータの管理には、多くの場合、Ｍｉｃｒｏｓｏｆｔ社のＳＱＬ ＳｅｒｖｅｒやＯｒａｃｌｅ社のＯｒａｃｌｅ Ｄａｔａｂａｓｅに代表されるデータベース管理システムが用いられる。なお、データ管理システム１１０の構成はこれに限られるものではなく、１台のサーバでこれら機能を構成していても良く、冗長化構成のために複数のサーバに分散した構成を採るようにしても良い。通信回線１２０は、ＬＡＮやＷＡＮ、インターネットなどが想定され、有線であっても無線であっても良い。

図２は、データ管理システム１１０のソフトウェア構成の中で、特に本発明に係る部分のソフトウェア構成を表す図である。ウェブサーバ１１１、データベースサーバ１１２が備える各ＣＰＵは、図２に示すソフトウェアプログラムをウェブサーバ１１１、データベースサーバ１１２が備える各ＨＤＤまたはＲＯＭに記憶している。ウェブサーバ１１１、データベースサーバ１１２の各ＣＰＵは、当該プログラムをワークメモリとして機能する各ＲＡＭにロードし、実行することにより図２に示す各種機能を実現する。

図２に示すように、データ管理システム１１０のウェブサーバ１１１は、リクエスト受信部２０１、リクエスト解析部２０２、検索条件判別部２０３、削除条件記録部２０４、リアルタイム削除部２０５を備える。また、ウェブサーバ１１１は、削除処理結果送信部２０６、バッチ削除部２０７、取得部２０８、取得処理結果送信部２０９を備える。また、データベースサーバ１１２は、複数のデータテーブル２１１と削除条件テーブル２１２を備える。リクエスト受信部２０１は、クライアント装置１００からデータの取得、登録、削除などのリクエストを受け付ける。リクエストは、ネットワーク経由で例えばＨＴＴＰを使用して送信される。

本実施例では、ＵＲＩの記述にＷｅｂデータプロトコルであるＯＤａｔａを適用した例を元に説明する。図３（Ａ）と図３（Ｂ）は、クライアント装置１００がデータ管理システム１１０にＨＴＴＰで送信するリクエストの一部の例を表す図である。クライアント装置１００からのリクエストには、データ種別の情報、検索条件、データ種別に対する操作種別の情報（取得、登録、削除の分類）が含まれる。図３（Ａ）、図３（Ｂ）の例では、ＵＲＩ３００、３５０がデータの削除クエリや取得クエリとして機能し、データ種別や検索条件が指定される。

ホストネーム部３０１、３５１は、データ管理システム１１０のウェブサーバ１１１を特定するＦＱＤＮ（Fully Qualified Domain Name）を表す。図３（Ａ）の例では、ウェブサーバ１１１のＦＱＤＮが”hostname”であることを示す。リソースネーム部３０２、３５２は、取得、登録、削除対象のデータ種別を特定するためのリソースパス及びリソース名を表す。また、リクエスト元の識別情報、例えば販売会社のテナントＩＤもリソースネーム部３０２、３５２に含まれる。”$filter”句に続く検索条件部３０３、３５３は、操作対象のデータ種別に対する検索条件であることを示している。

ＯＤａｔａ形式のクエリオプションでは、”eq”（等しい）、”ne”（等しくない）、”gt”（大なり）などの比較演算子、”add”（加算）などの算術演算子などを複数組み合わせ、複雑な条件を指定できる。その他、クエリオプションは、”and”（And条件）や”or”（Or条件）などを組み合わせることもできる。また、データ操作関数として、日付形式のデータに対しては”month()”（月要素）や”year()”（年要素）といった日付操作関数を用いて条件を指定することができる。さらに、文字列形式のデータに対しては”startswith()”（前方一致）といった文字列操作関数を用いて条件を指定することもできる。

ＵＲＩ３００は、リソースネーム部３０２で指定されたデータ種別”resourcename”のうち、検索条件部３０３で指定された条件に合致するデータに対してのリクエストであることを示す。検索条件部３０３は、評価対象３１１、演算子３１２、評価値３１３から構成され、「ＵｓｅｒＩＤに対応する”Received”データの年要素が”2010”より小さいこと」を検索条件としていることを示す。同様に、ＵＲＩ３５０は、リソースネーム部３５２で指定されたデータ種別”resourcename”のうち、検索条件部３５３で指定された条件に合致するデータに対してのリクエストであることを示す。検索条件部３５３は、演算子を複数組み合わせて構成されており、「”UserID”が”UID”で始まること」かつ「”Received”の年要素が”2010”より小さいこと」を検索条件としていることを示す。そして、ＨＴＴＰメソッドにPOST（登録）、GET（取得）、またはDELETE（削除）などが指定され、登録操作なのか取得操作なのか、または削除操作なのかといった操作種別が判別される。

クライアント装置１００は、ＨＴＴＰメソッドを指定してこのＵＲＩに送信することで、データ管理システム１１０に対して、データの登録、取得、削除の操作を指示する。なお、本実施例ではＵＲＩのクエリオプションで操作対象のデータ種別に対する検索条件を指定したが、ＨＴＴＰボディに指定するなど他の形式であっても良い。

リクエスト解析部２０２は、リクエスト受信部２０１が受信したリクエスト内容を解析する。前述のリクエスト指定の例では、ＨＴＴＰメソッドから操作種別を、ＵＲＩからデータ種別の特定と検索条件の抽出を行う。検索条件判別部２０３は、操作種別が削除操作である場合に、検索条件が所定形式であるかによって、バッチ処理で削除を行うか判別する。

本発明では、大量データを処理する場合などデータベースサーバ１１２での削除処理が遅い場合を考慮している。従って、データ管理システム１１０は、クライアント装置１００へ応答を早く返すために、バッチ処理で対応可能な削除処理をバッチ処理で行うように構成される。

バッチ処理の場合には、データベースへの削除の反映がクライアント装置１００に応答を返すタイミングより遅れるため、バッチ処理で削除する対象のデータをクライアント装置１００から取得できないような対策が必要である。削除処理の検索条件の記述が複雑な場合にはその対策が困難となるため、本発明のデータ管理システム１１０は対策が容易な形式の場合に絞ってバッチ処理を行う。

具体的には、例えば、検索条件判別部２０３は、検索条件が「評価対象、演算子、評価値」の１組のみの形式である場合、バッチ処理を行うと判別する。この例に従えば、図３（Ａ）の検索条件部３０３は、「評価対象、演算子、評価値」の１組のみの形式であり、検索条件判別部２０３はバッチ処理で削除を行うと判別する。一方、図３（Ｂ）の検索条件部３５３は”ａｎｄ“で結ばれた２つの評価値を含む。よって「評価対象、演算子、評価値」の１組のみの形式ではないため、検索条件判別部２０３はバッチ処理ではなく、リアルタイム処理で削除を行うと判別する。

なお、所定形式であるかの判別条件は、この例に限ったものではなく、例えば評価対象や演算子を限定して定めるようにしても良い。また、データ種別によって判別条件を変えるようにしても良いし、検索条件の形式に関わらず全ての削除処理をリアルタイム処理で行うデータ種別が存在していても良い。削除条件記録部２０４は、リクエスト解析部２０２で抽出した検索条件を、データベースサーバ１１２の削除条件テーブル２１２に保存する。この抽出された検索条件が、クライアント装置１００から受信した取得クエリにより取得されることとなるデータの中に、削除クエリにより削除されるデータが含まれないよう検索条件を変更するための情報として使用される。

図４は、データベースサーバ１１２の削除条件テーブル２１２の一例を表す図である。削除条件テーブル４００は、バッチ処理で削除を行う対象のデータ種別ごとに用意される。削除条件テーブル４００は、評価対象４０１、演算子４０２、評価値４０３などのフィールドを持ち、バッチ処理で削除を行う対象の検索条件をこれらフィールドの組み合わせで記録できるように構成している。図３（Ａ）の例の場合、削除条件記録部２０４は、検索条件部３０３を削除条件テーブル４００にレコードを追加して記録する。具体的には、削除条件記録部２０４は、評価対象４０１を”year(Received)”、演算子４０２を”lt”、評価値４０３を”2010”とするレコードを、削除条件テーブル４００に追加する。

リアルタイム削除部２０５は、リクエスト解析部２０２が特定・抽出したデータ種別と検索条件に従って、データベースサーバ１１２のデータテーブル２１１の対象データを削除する命令文を生成し、実行する。削除処理結果送信部２０６は、データ管理システム１１０が削除処理を受け付けた結果をクライアント装置１００に送信する。ここで削除処理結果送信部２０６は、バッチ処理でデータを削除する場合には削除条件記録部２０４が記録した結果を、リアルタイム処理でデータを削除する場合にはリアルタイム削除部２０５が削除処理を実行した結果をクライアント装置１００に送信する。

バッチ削除部２０７は、クライアント装置１００からリクエストの受信とは非同期に、データ管理システム内の別のバックグラウンドで、定期的あるいは不定期に処理を実行する。バッチ削除部２０７は毎日の所定の時刻に起動しても良いし、削除条件記録部２０４の削除条件テーブル２１２への記録処理をトリガーに起動しても良い。バッチ削除部２０７は、データベースサーバ１１２の削除条件テーブル２１２を読み込み、削除条件テーブル２１２の内容に従って、データベースサーバ１１２のデータテーブル２１１の対象データを削除する命令文を生成し、実行する。

取得部２０８は、操作種別が取得操作である場合に、リクエスト解析部２０２が特定・抽出したデータ種別と検索条件に従って、データベースサーバ１１２のデータテーブル２１１から対象データを取得する命令文を生成し、実行する。取得操作に対しては、クライアント装置１００へ取得したデータを返却する必要があるため、取得部２０８は検索条件の指定に関わらずリアルタイムに処理を行う。またこのとき取得部２０８は、削除条件テーブル２１２にレコードが存在する場合には、バッチ処理で削除する対象のデータをクライアント装置１００から取得させないようにするため、削除条件テーブル２１２のレコードから除外条件を生成する。取得部２０８は、生成した除外条件を検索条件に追加してデータを取得する命令文を生成する。

取得処理結果送信部２０９は、取得部２０８が取得処理を実行した結果をクライアント装置１００に送信する。このとき、取得部２０８が取得処理を実行した結果、検索条件に該当するデータが存在した場合には、取得処理結果送信部２０９はそのデータをＨＴＴＰで送信可能な形式に生成し、送信する。ＨＴＴＰで送信可能な形式とは、例えばＨＴＴＰのボディに指定可能な形式であって、ＸＭＬ形式やＪＳＯＮ形式、ＣＳＶ形式などが想定される。

図５は、データ管理システム１１０のリクエスト受信時の処理を示すフローチャートである。以下、図５のフローチャートに従って、クライアント装置１００からリクエストを受信した際のデータ管理システム１１０の処理を説明する。リクエスト受信部２０１がクライアント装置１００からリクエストを受信すると、リクエスト解析部２０２がリクエストのＨＴＴＰメソッドから操作種別を特定する（ステップＳ５０１）。

また、リクエスト解析部２０２がリクエストＵＲＩを解析してデータ種別を特定し（ステップＳ５０２）、検索条件を抽出する（ステップＳ５０３）。ステップＳ５０１で特定した操作種別によって処理は分岐し（ステップＳ５０４）、操作種別が削除操作である場合には、検索条件判別部２０３により検索条件がバッチ処理を行う所定の形式であるかを判別する（ステップＳ５０５）。

ステップＳ５０５で検索条件がバッチ処理を行う形式であると判別すると、削除条件記録部２０４は検索条件を削除条件テーブル２１２に記録する（ステップＳ５０６）。バッチ処理でデータを削除する場合は、データベースサーバ１１２への削除処理の実行を待たずに、削除処理結果送信部２０６が削除条件記録部２０４の処理結果をクライアント装置１００に送信して（ステップＳ５０７）、リクエスト受信時の処理を終了する。

一方、ステップＳ５０５で検索条件がバッチ削除を行う形式ではないと判別すると、リアルタイム削除部２０５が対象のデータを削除する命令文を生成する（ステップＳ５０８）。リアルタイム削除部２０５は、データベースサーバ１１２に生成した命令文を発行し、データ削除を実行する（ステップＳ５０９）。そして、削除処理結果送信部２０６が命令文の実行結果をクライアント装置１００に送信して（ステップＳ５０７）、リクエスト受信時の処理を終了する。

ステップＳ５０４で操作種別が取得操作である場合には、取得部２０８がリクエスト解析部２０２で特定・抽出したデータ種別と検索条件に従って、データテーブル２１１の対象データを取得する。取得部２０８は、まず削除条件テーブル２１２を参照し、削除条件テーブル２１２にレコードが存在するかを確認する（ステップＳ５１０）。ステップＳ５１０でレコードが存在することを確認した場合、取得部２０８は、削除条件テーブル２１２のレコードから除外条件を生成する（ステップＳ５１１）。図４に示すテーブルが確認された場合、”UserID”が”'UID00001'”に等しいデータ及び、”year(Received)”が”2010”より小さいデータを除外する必要がある。除外条件の生成は、図６（Ａ）に示す演算子変換ロジックテーブル６００を参照することにより行われる。

図６（Ａ）は、取得部２０８がステップＳ５１１で参照する演算子変換ロジックテーブルの一例を表す図である。演算子変換ロジックテーブル６００は、演算子６０１と変換後演算子６０２のフィールドを持つ。変換後演算子６０２は、演算子６０１の否定に相当する演算子である。取得部２０８は、削除条件テーブル２１２から取得した演算子を、演算子変換ロジックテーブル６００に従って演算子６０１に対応する変換後演算子６０２に置換することにより、除外条件を生成する。

図６（Ｂ）は、取得部２０８が図４の削除条件テーブル４００から生成した除外条件の例である。図４の例の場合、１レコード目の演算子４０２が”eq”であることから、演算子６０１”eq”に対応する変換後演算子６０２は”ne”と決定される。これにより、削除条件テーブル４００の１レコード目に対する除外条件として除外条件６５１を生成する。削除条件テーブル２１２に複数のレコードが存在する場合は、それら全てについて同様に除外条件を生成する。

取得部２０８はさらに、削除条件テーブル４００の２レコード目に対する除外条件として除外条件６５２を生成する。取得部２０８は、これらを演算子”and”を用いて結合した除外条件６５０を、リクエストＵＲＩから抽出した検索条件に付加する（ステップＳ５１２）。そして取得部２０８は、対象のデータを取得する命令文を生成し（ステップＳ５１３）、データベースサーバ１１２にその命令文を発行し、実行することによりデータを取得する（ステップＳ５１４）。ステップＳ５１４でデータを取得すると、取得処理結果送信部２０９は取得したデータをクライアント装置１００に送信して（ステップＳ５１５）、リクエスト受信時の処理を終了する。

なお、クライアント装置１００は複数のＵｓｅｒＩＤを指定してデータ取得リクエストを行うことが一般的である。例えば、クライアント装置１００がユーザＩＤ００００１に対応するデータをデータ管理システム１１０から削除し、その後、ユーザＩＤ００００１及びユーザＩＤ００００２に対応するデータをデータ管理システム１１０から取得する例を考える。この場合、図６（Ｂ）に示す（ＵｓｅｒＩＤ ｎｅ ＵＩＤ００００１）と（ｙｅａｒ（Ｒｅｃｅｉｖｅｄ）ｇｅ ２０１０）は（）で閉じられることとなる。つまり、（（ＵｓｅｒＩＤ ｎｅ ＵＩＤ００００１） ａｎｄ （ｙｅａｒ（Ｒｅｃｅｉｖｅｄ）ｇｅ ２０１０））と記述される。これにより、２０１０年より前のユーザＩＤ００００２に対応するデータの取得が確保される。

また、クライアント装置１００が、ユーザＩＤ００００１及びユーザＩＤ００００２に対応する、２０１３年までのデータをデータ管理システム１１０から取得する例を考える。この場合も、（ＵｓｅｒＩＤ ｎｅ ＵＩＤ００００１）と（ｙｅａｒ（Ｒｅｃｅｉｖｅｄ）ｇｅ ２０１０）は（）で閉じられることとなる。これにより、２０１０年より前のユーザＩＤ００００１に対応するデータを除外しつつ２０１０年より後であって２０１３年までのユーザＩＤ００００１に対応するデータの取得が確保される。

図７は、データ管理システム１１０のバッチ処理での削除処理を示すフローチャートである。以下、図７のフローチャートに従って、バッチ処理でのデータ管理システム１１０の削除処理を説明する。バッチ処理は、クライアント装置１００からリクエストを受信したのとは非同期に、例えば夜間の特定の時刻といった定期的に自動的に起動される。

バッチ処理が起動されると、まずバッチ削除部２０７は、削除条件テーブル２１２にレコードが存在するかを確認する（ステップＳ７０１）。削除条件テーブル２１２にレコードが存在しない場合には、バッチ処理で削除する対象のデータが存在しないためそのままバッチ処理を終了する。

ステップＳ７０１で削除条件テーブル２１２にレコードが存在する場合は、バッチ削除部２０７は、削除条件テーブル２１２のレコードを取得し、取得したレコードからデータを削除する命令文を生成する（ステップＳ７０２）。ステップＳ７０２で生成した命令文は、データベースサーバ１１２に発行され、実行される（ステップＳ７０３）。図４に示す例では、ＵｓｅｒＩＤが“ＵＩＤ００００１”である識別情報に紐付けられた２０１０年よりも前のデータが、バッチ処理で削除される。

ステップＳ７０３でデータの削除に成功すると、バッチ削除部２０７は、削除に成功した対象のレコードを削除条件テーブル２１２から削除して（ステップＳ７０４）、バッチ処理を終了する。ここで、削除条件テーブル２１２に複数のレコードが存在する場合は、ステップＳ７０２〜Ｓ７０４の一連の処理を１レコードずつ繰り返し実行するようにしても良いし、演算子”or”を用いて連結して条件を生成し、一度に削除するようにしても良い。

以上、本発明の管理装置によれば、クエリの形式に応じて非同期でデータが削除される場合に、クライアントから受信したデータ取得依頼に対し、非同期による削除対象のデータが含まれないようにデータを制御することが可能となる。従って、ＯＤａｔａのようにデータベースリソースに対しての削除条件をフレキシブルに指定できるようにした場合であっても、条件に応じてリアルタイム処理とバッチ処理とを切り替えられる。バッチ処理で対応可能な削除条件の場合に絞ってバッチ処理で行うため、データベースへの反映遅れに伴う不整合を防止しながら、一部をバッチ処理にすることでクライアント装置へのレスポンス効率を向上させることが可能となる。

（実施例２）
第一の実施例においては、クライアント装置１００によらず、クライアント装置１００がリクエストによって操作できるデータの範囲が変わらないことを前提とした。しかし、複数のユーザがデータ管理システム１１０を共有する場合には、ユーザが操作できるデータの範囲を限定することがある。例えば、データベースサーバ１１２におけるデータ領域をテナントごとに分割し、データ管理システム１１０としてテナント分離を実現しているような場合である。クライアント装置１００またはクライアント装置１００が所属するグループに対して権限が設定され、アクセスできるデータの範囲が限定される場合も同様である。そこで実施例２では、データ管理システム１１０としてテナント分離が実現されている場合に、クライアント装置１００からのリクエストに応じて管理装置がデータベースからデータを取得または削除する実施形態について説明する。

本実施例のシステム全体の概略図は、図１とほぼ同一である。図８は、データ管理システム１１０のソフトウェア構成の中で、特に本発明に係る部分のソフトウェア構成を表す図である。データ管理システム１１０のソフトウェア構成の中で本実施例において特徴的な部分を、図８を用いて説明する。

クライアント装置認証部８０１は、リクエスト受信部２０１が受信したリクエストに含まれる認証情報の有効性を検証することにより、リクエスト送信元のクライアント装置１００を認証する。認証情報とは、クライアント装置１００に割り振られたＩＤとパスワードのようなものでも良いし、別途認証サーバ（図示せず）がクライアント装置１００に発行したトークンのようなものであっても良い。認証情報の有効性検証は、クライアント装置１００から受信したＩＤ情報がデータ管理システム１１０に登録されたＩＤ情報と一致するか否かにより確認されても良いし、前述の認証サーバに問い合わせを行うことで実現されても良い。

認可確認部８０２は、リクエストに含まれる認証情報からクライアント装置１００の所属テナント情報やクライアント装置１００に割り当てられたロールを特定し、クライアント装置１００が該リクエストの操作権限を有しているかを確認する。ロールとは、クライアント装置１００がデータ管理システム１１０に対して実行できる操作の権限を定義した情報である。例えば、管理者ロール、顧客ロールなどが定義され、それぞれのロールに対して、クライアント装置１００が許可されたデータ種別や操作種別があらかじめ設定される。

認可確認部８０２は、ロールにより制限されるデータ種別や操作種別と、テナント分離の仕組みで所属テナント情報により制限されるデータの範囲により、該リクエストを実行しても良いかを判断する。また、本実施例において削除条件記録部２０４は、リクエスト解析部２０２で抽出した検索条件に加えて、認可確認部８０２が特定した所属テナント情報を、データベースサーバ１１２の削除条件テーブル２１２に記録する。

図９は、本実施例におけるデータベースサーバ１１２の削除条件テーブル２１２の一例を表す図である。削除条件テーブル９００は、バッチ処理で削除を行う対象のデータ種別ごとに用意される。削除条件テーブル９００は、所属テナントＩＤ９０１、評価対象９０２、演算子９０３、評価値９０４などのフィールドを持ち、バッチ処理で削除を行う対象の検索条件及び所属テナント情報を、これらフィールドの組み合わせで記録できるように構成している。

図３（Ａ）に示すクエリ例の場合、削除条件記録部２０４は、検索条件部３０３及び認可確認部８０２により特定した所属テナント情報を、削除条件テーブル９００のレコードに追加して記録する。具体的には、所属テナントＩＤ９０１に認可確認部８０２で特定した所属テナント情報を設定し、評価対象９０２、演算子９０３、評価値９０４に検索条件部３０３の情報をそれぞれ指定したレコードを、削除条件テーブル９００に追加する。

図１０および図１１は、本実施例におけるデータ管理システム１１０のリクエスト受信時の処理を示すフローチャートである。以下、図１０および図１１のフローチャートに従って、クライアント装置１００からリクエストを受信した際のデータ管理システム１１０の処理の中で、本実施例において特徴的な部分を説明する。

リクエスト受信部２０１がクライアント装置１００からリクエストを受信すると、クライアント装置認証部８０１がリクエストに含まれる認証情報から認証情報の有効性を検証する（ステップＳ１００１）。ステップＳ１００１で認証情報の有効性検証に失敗したならばステップＳ１００２で処理は分岐し、クライアント装置１００へ認証に失敗した情報を送信して（ステップＳ１００３）、以降の処理を中止する。

ステップＳ１００１で認証情報の有効性検証に成功すると、リクエスト解析部２０２が続くステップＳ５０１〜Ｓ５０３で、リクエストから操作種別とデータ種別を特定し、検索条件を抽出する。そして、認可確認部８０２が認証情報からクライアント装置１００の所属テナント情報やロールを特定する（ステップＳ１００４）。ステップＳ１００４で特定したクライアント装置１００の所属テナント情報やロールが、ステップＳ５０２で特定したデータ種別に対するステップＳ５０１で特定した操作種別の操作権限を有しているかを確認する（ステップＳ１００５）。換言すると、データベースに対するデータの削除や取得は、認証情報に基づいて、クライアント装置１００に許可されたデータに限定される。ここでは、ロールにより制限されるデータ種別や操作種別と、所属テナント情報により制限されるデータの範囲により、該リクエストを実行しても良いかを判断する。

ステップＳ１００５で操作権限を有していると確認できなかったならば図１１のステップＳ１００６で処理は分岐し、クライアント装置１００へ操作権限を有していないという情報を送信して（ステップＳ１００７）、以降の処理を中止する。ステップＳ１００５で操作権限を有していると確認すると、ステップＳ５０１で特定した操作種別によって処理は分岐する（ステップＳ５０４）。

操作種別が削除操作である場合には、検索条件判別部２０３は検索条件がバッチ処理を行う所定の形式であるかを判別する（ステップＳ５０５）。ステップＳ５０５で検索条件がバッチ処理を行う形式であると判別すると、削除条件記録部２０４は検索条件とともにステップＳ１００４で特定した所属テナント情報を削除条件テーブル２１２に記録する（ステップＳ１００８）。バッチ処理での削除の場合は、データベースサーバ１１２への削除処理の実行を待たずに、削除処理結果送信部２０６が削除条件記録部２０４の処理結果をクライアント装置１００に送信して（ステップＳ５０７）、リクエスト受信時の処理を終了する。

一方、ステップＳ５０５で検索条件がバッチ削除を行う形式ではないと判別すると、リアルタイム削除部２０５が対象のデータを削除する命令文を生成し（ステップＳ５０８）、データベースサーバ１１２にその命令文を発行し、実行する（ステップＳ５０９）。このとき命令文は、ステップＳ１００４で特定した所属テナントに範囲を限定するよう、実行される。そして、削除処理結果送信部２０６がその命令文の実行結果をクライアント装置１００に送信して（ステップＳ５０７）、リクエスト受信時の処理を終了する。

ステップＳ５０４で操作種別が取得操作である場合には、取得部２０８がリクエスト解析部２０２で特定・抽出したデータ種別と検索条件に従って、データテーブル２１１の対象データを取得する。そこにおいて取得部２０８は、まず削除条件テーブル２１２を参照し、削除条件テーブル２１２にレコードが存在するかを確認する（ステップＳ５１０）。

ステップＳ５１０でレコードが存在することを確認した場合、取得部２０８は、削除条件テーブル２１２のレコードから除外条件を生成する（ステップＳ５１１）。このとき、ステップＳ１００４で特定した所属テナントに関係するレコードのみを対象とする。ステップＳ１００４で特定した所属テナントが「１００１」であったとすると、図９の例の場合、取得部２０８は所属テナントＩＤ９０１が一致する１レコード目のみを対象に除外条件を生成する。

取得部２０８は、ステップＳ５１１で生成した除外条件６５０を、リクエストＵＲＩから抽出した検索条件に付加する（ステップＳ５１２）。そして取得部２０８は、対象のデータを取得する命令文を生成し（ステップＳ５１３）、データベースサーバ１１２にその命令文を発行し、実行することによりデータを取得する（ステップＳ５１４）。このとき命令文は、ステップＳ１００４で特定した所属テナントに範囲を限定するよう、実行される。ステップＳ５１４でデータを取得すると、取得処理結果送信部２０９は取得したデータをクライアント装置１００に送信して（ステップＳ５１５）、リクエスト受信時の処理を終了する。

以上、実施例２では、データ管理システム１１０としてテナント分離が実現されているような場合であっても、条件に応じてリアルタイム処理とバッチ処理とを切り替えられる。バッチ処理で対応可能な削除条件の場合に絞ってバッチ処理で行うため、データベースへの反映遅れに伴う不整合を防止しながら、一部をバッチ処理にすることでクライアント装置へのレスポンス効率を向上させることが可能となる。

（その他の実施形態）
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（コンピュータプログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給する。そしてそのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。この場合、そのプログラム、及び該プログラムを記憶した記憶媒体は本発明を構成することになる。

Claims (8)

1. データベースに対し非同期でデータを削除するよう指示する指示手段と、
   削除クエリを受信したことに応じて、クライアントから受信した前記データベースからデータを取得するための取得クエリにより取得されることとなるデータの中に、前記削除クエリにより削除されるデータが含まれないよう前記取得クエリの検索条件を変更するための情報を保存する保存手段と、
   前記取得クエリを受信したことに応じて、前記保存手段により保存された情報を基に前記取得クエリの検索条件を変更し前記データベースからデータを取得する取得手段と、を備える
   ことを特徴とする管理装置。
2. 前記指示手段は、前記削除クエリが所定形式であれば前記データベースに対し非同期でデータを削除するよう指示し、前記所定形式でなければ前記データベースに対し同期でデータを削除するように指示する
   ことを特徴とする請求項１に記載の管理装置。
3. 前記取得クエリの検索条件を変更するための情報は前記削除クエリに含まれる情報であり、
   前記取得手段は、前記削除クエリにより削除されるデータを前記取得クエリにより取得されることとなるデータから除外する除外条件を生成し、当該除外条件を前記検索条件に追加して前記取得クエリの検索条件を変更する
   ことを特徴とする請求項１または２に記載の管理装置。
4. 前記保存手段は、前記データを識別するための識別情報に紐付けて前記データを保存しており、
   前記指示手段は、前記削除クエリが所定形式であれば、前記削除クエリにより特定される識別情報に紐付けられたデータをバッチ処理で削除するように前記データベースに対して指示する
   ことを特徴とする請求項２または３に記載の管理装置。
5. 前記指示手段は、前記削除クエリに含まれる評価対象、演算子および評価値から構成されるクエリオプションに基づいて前記所定形式であるかを判断する
   ことを特徴とする請求項４に記載の管理装置。
6. 前記クライアントを認証する認証手段を備え、
   前記データベースに対する前記データの削除または取得は、前記認証の結果、前記クライアントに許可された前記識別情報に対応するデータに限定される
   ことを特徴とする請求項１乃至５のいずれか一項に記載の管理装置。
7. データベースに対し非同期でデータを削除するよう指示する指示工程と、
   削除クエリを受信したことに応じて、クライアントから受信した前記データベースからデータを取得するための取得クエリにより取得されることとなるデータの中に、前記削除クエリにより削除されるデータが含まれないよう前記取得クエリの検索条件を変更するための情報を保存する保存工程と、
   前記取得クエリを受信したことに応じて、前記保存手段により保存された情報を基に前記取得クエリの検索条件を変更し前記データベースからデータを取得する取得工程と、を有する
   ことを特徴とする管理装置の制御方法。
8. 請求項７に記載の制御方法をコンピュータにより実行させることを特徴とするコンピュータプログラム。

Images