(57)【要約】【課題】  多様なクエリを含むデータ取得リクエストを受け付ける管理システムにおいて、特定のデータ取得条件において、より効率的なデータの取得が可能となる場合がある。しかしながら、多数の組み合わせがありうるデータ取得条件の指定内容ごとに最適な取得手段を設けるのは、とても現実的ではない。【解決手段】  そこで、本発明の管理システムでは、クライアントから受信したリクエストからクエリを抽出する抽出手段と、前記クエリに基づいて前記データベースに対して、特定の用途に最適化されたデータの取得処理を実行する第一のデータ取得手段と、前記クエリに基づいて前記データベースに対して、それとは異なる取得処理を実行する第二のデータ取得手段と、前記抽出されたクエリの内容に応じて、第一のデータ取得手段、及び第二のデータ取得手段の何れかを選択する選択手段と、を有することを特徴とする。【選択図】  図３
2016004306.tif 000002
【特許請求の範囲】
【請求項１】
データベースを用いてデータを管理する管理システムであって、
クエリのフォーマットパターンを少なくとも１つ保持するクエリパターン保持手段と、
クライアントからクエリを含むリクエストを受信する受信手段と、
前記受信手段が受信したリクエストからクエリを抽出する抽出手段と、
前記クエリに基づいて、前記データベースに対して、特定の用途に最適化されたデータの取得処理を実行する第一のデータ取得手段と、
前記クエリに基づいて、前記データベースに対して、前記第一のデータ取得手段による取得処理とは異なる取得処理を実行する第二のデータ取得手段と、
前記抽出されたクエリが、前記クエリパターン保持手段の保持するフォーマットパターンと一致しているか否かの判定に従い、第一のデータ取得手段、及び第二のデータ取得手段の何れかを選択する選択手段と、
前記第一のデータ取得手段、或いは前記第二のデータ取得手段により取得されたデータを、前記クライアントに前記リクエストに対するレスポンスとして送信する送信手段と、
を有することを特徴とする管理システム。
【請求項２】
前記第一のデータ取得手段は、特定のクエリに最適化したデータの取得処理を、前記クエリに基づいて実行し、一方、
前記第二のデータ取得手段は、汎用的なクエリに対応するためのデータの取得処理を前記クエリに基づいて実行することを特徴とする請求項１に記載の管理システム。
【請求項３】
前記管理システムは、テナントを特定するための特定情報を保持し、マルチテナントによるデータの管理を行い、
さらに、前記管理システムは、
前記受信手段により受信されたリクエストからデータの取得先のテナントを特定し、該テナントへのアクセス権が有るかを確認する検証手段を、有し、
前記選択手段は、前記検証手段によりアクセス権が確認された取得先のテナントについて行われる前記保持された特定情報を用いた判定に従い、前記第一のデータ取得手段、及び前記第二のデータ取得手段の何れかを選択することを特徴とする請求項１または２に記載の管理システム。
【請求項４】
前記第一のデータ取得手段は、特定のテナントからのデータ取得で使用される特定のクエリに最適化したデータの取得処理を前記クエリに基づいて実行し、一方、
前記第二のデータ取得手段は、汎用的なクエリに対応するためのデータの取得処理を前記クエリに基づいて実行することを特徴とする請求項３に記載の管理システム。
【請求項５】
前記管理システムは、クライアントを特定するための特定情報を保持し、
さらに、前記管理システムは、
前記受信されたリクエストに含まれる認証情報を検証し、当該リクエストを送信したクライアントを特定する特定手段を、有し、
前記選択手段は、前記特定されたクライアントについて行われる前記保持された特定情報を用いた判定に従い、前記第一のデータ取得手段、及び前記第二のデータ取得手段の何れかを選択することを特徴とする請求項１乃至４のいずれか１項に記載の管理システム。
【請求項６】
前記第一のデータ取得手段は、特定のクライアントが使用する特定のクエリに最適化したデータの取得処理を前記クエリに基づいて実行し、一方、
前記第二のデータ取得手段は、汎用的なクエリに対応するためのデータの取得処理を前記クエリに基づいて実行することを特徴とする請求項５に記載の管理システム。
【請求項７】
データベースを用いてデータを管理する管理システムにおける方法であって、
クエリのフォーマットパターンを少なくとも１つ保持するクエリパターン保持工程と、
クライアントからクエリを含むリクエストを受信する受信工程と、
前記受信されたリクエストからクエリを抽出する抽出工程と、
前記抽出されたクエリが前記保持されたフォーマットパターンと一致しているか否かの判定に従い、前記クエリに基づく前記データベースに対する取得処理について、特定の用途に最適化されたデータの取得処理を実行する第一のデータ取得部と、前記第一のデータ取得手段による取得処理とは異なる取得処理を実行する第二のデータ取得部と、の何れかを選択する選択工程と、
前記第一のデータ取得部、或いは前記第二のデータ取得部により取得されたデータを、前記クライアントに前記リクエストに対するレスポンスとして送信する送信工程と、
を有することを特徴とする方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、クライアントからリクエストを受け付け、そのリクエストに応じてデータベースに対して、データの取得処理を実行可能な管理システムに関するものである。
【背景技術】
【０００２】
クラウドサービスの普及に伴い、ネットワーク経由で各種データの管理を行うデータ管理システムが登場してきている。このようなシステムでは、複数のクライアントとデータ管理システムとが、ＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）やＷＡＮ（Ｗｉｄｅ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）、インターネットなどを介して互いに接続されている。近年では、ＯＤａｔａ（Ｏｐｅｎ  Ｄａｔａ  Ｐｒｏｔｏｃｏｌ）と呼ばれるＷｅｂデータプロトコルのように、Ｗｅｂ上のデータリソースに対するデータ取得条件をクエリオプション形式でフレキシブルに指定できる技術も広く一般化してきている。ＯＤａｔａは、データリソースに対する取得操作のデータ取得条件として検索条件や並び替え順序などをＵＲＩに指定できる。このような技術をデータ管理システムに適用することにより、クライアントはＵＲＩにリクエストを送信することで、任意の複雑な検索条件や並び替え順序を指定したデータリソースの取得が行える。
【０００３】
データリソースが管理されるデータベースサーバーには、リレーショナルデータベース管理システム（ＲＤＢＭＳ）が広く採用されている。ＲＤＢＭＳは、ＳＱＬ（Ｓｔｒｕｃｔｕｒｅｄ  Ｑｕｅｒｙ  Ｌａｎｇｕａｇｅ）と呼ばれる標準化された照会言語を介して操作され、検索条件や並び替え順序などのデータ取得条件を指定してデータの取得が行えるよう構成されている。データ取得条件を指定したＳＱＬ文を生成してＲＤＢＭＳに実行を指示することにより、ＲＤＢＭＳは最適と思われる検索処理手続き（アクセスパス）で対象のデータリソースを検索し、検索結果を抽出する。
【０００４】
しかし、データベーステーブルのインデックスの作成方法やレコード件数、また検索キーの組み合わせによっては必ずしも最適な検索処理手続きを判断できない場合がある。このような場合を鑑みて、特許文献１では、検索条件に指定されるキーが設定ファイルに記載されている条件に合致する場合に、設定ファイルに記載のアクセスパスを指定してＳＱＬの実行をＲＤＢＭＳに指示するように構成している。これにより、アクセスパスが必ずしも最適とならない場合があるのに対し、設定ファイルに記載されているキーで検索する場合において、ＲＤＢＭＳに最適なアクセスパスを選択させることが可能となる。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００６−１６３９６８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
ＯＤａｔａといったＷｅｂデータプロトコルの技術をデータ管理システムに適用することにより、管理システムは、Ｗｅｂ経由での任意の複雑な検索条件や並び替え順序といったデータ取得条件を指定したデータリソースの取得に対応できる。このような管理システムでは、データ取得条件を指定したクエリから、ＳＱＬ文やアクセスパスを生成する仕組みを備える。これによりデータ管理システムは汎用的なクエリへの対応を実現している。
【０００７】
しかしながら、この仕組みであっても、データベーステーブルのインデックスの作成方法やデータのばらつき、件数、データ取得条件の指定内容の組み合わせによって、必ずしも最適なＳＱＬ文やアクセスパスとならない。また、テーブルに格納されるデータの特性によっては、特定のデータ取得条件のときに指定された以外の検索条件を付加して検索させることで、より効率的なデータの取得が可能となる場合もある。
【０００８】
ここで、多数の組み合わせがあり得るデータ取得条件の指定内容ごとに、最適な取得手段（取得インターフェース）を設けるのは、とても現実的ではない。また、特定のデータ取得条件において有利なインターフェースが存在する場合、そのデータ取得条件に特化したインターフェースをデータ管理システムに設けて、クライアントに提供（公開）することはできる。しかし、データ取得条件ごとにクライアント側が意識してデータ取得用のインターフェースを選択するのは、利用者にとって手間である。
【０００９】
本発明の目的は、多様なクエリを含むデータ取得リクエストを受け付ける管理システムにおいて、クライアント側にデータ取得のためのインターフェースの選択を意識させることなく、よりパフォーマンスを向上させたデータの取得サービスを提供することである。
【課題を解決するための手段】
【００１０】
上記課題を解決するために、本発明は、データベースを用いてデータを管理する管理システムであって、クエリのフォーマットパターンを少なくとも１つ保持するクエリパターン保持手段と、クライアントからクエリを含むリクエストを受信する受信手段と、前記受信手段が受信したリクエストからクエリを抽出する抽出手段と、前記クエリに基づいて、前記データベースに対して、特定の用途に最適化されたデータの取得処理を実行する第一のデータ取得手段と、前記クエリに基づいて、前記データベースに対して、前記第一のデータ取得手段による取得処理とは異なる取得処理を実行する第二のデータ取得手段と、前記抽出されたクエリが、前記クエリパターン保持手段の保持するフォーマットパターンと一致しているか否かの判定に従い、第一のデータ取得手段、及び第二のデータ取得手段の何れかを選択する選択手段と、前記第一のデータ取得手段、或いは前記第二のデータ取得手段により取得されたデータを、前記クライアントに前記リクエストに対するレスポンスとして送信する送信手段と、を有することを特徴とする。
【発明の効果】
【００１１】
発明によれば、管理システムが、クライアント側にデータ取得のためのインターフェースの選択を意識させることなく、よりパフォーマンスを向上させたデータの取得サービスを提供できる。
【図面の簡単な説明】
【００１２】
【図１】ネットワークシステムの構成例を示す図である。
【図２】管理システム１１０のハードウェア構成を表す図である。
【図３】管理システム１１０の中で、特に本システムに係る部分の第一実施例でのソフトウェア構成図である。
【図４】第一実施例での管理システム１１０のリクエスト受信時の処理を示すフローチャートである。
【図５】取得リクエストの一部やクエリのフォーマットパターンの例を表す図である。
【図６】管理システム１１０の中で、特に本システムに係る部分の実施例２でのソフトウェア構成図である。
【図７】実施例２での管理システム１１０のリクエスト受信時の処理を示すフローチャートである。
【図８】管理システム１１０の中で、特に本システムに係る部分の実施例３でのソフトウェア構成図である。
【図９】実施例３での管理システム１１０のリクエスト受信時の処理を示すフローチャートである。
【発明を実施するための形態】
【００１３】
以下、本発明を実施するための最良の形態について図面を用いて説明する。
【００１４】
（実施例１）
図１は、本発明の実施の形態に係るネットワークシステムの構成を示す図である。
【００１５】
クライアント１００と管理システム１１０は、互いに通信回線１２０を介して接続されている。クライアント１００は、ユーザーが直接操作するＰＣや、ユーザーにサービスを提供するアプリケーションサーバーなどが想定される。管理システム１１０に接続されるクライアント１００は、複数存在しても良い。
【００１６】
管理システム１１０は、ウェブサーバー１１１とデータベースサーバー１１２とから構成され、ユーザーにサービスを提供するための各種データを格納し、管理する。ウェブサーバー１１１は、通信回線１２０とファイアウォールなどを介して接続され、クライアント１００から、データの取得リクエストを受け付ける。データベースサーバー１１２は、ウェブサーバー１１１からの指示に基づき、データベースに格納された各種データの取得処理などを行う。データベースサーバー１１２におけるデータの管理には、多くの場合、Ｍｉｃｒｏｓｏｆｔ社のＳＱＬ  ＳｅｒｖｅｒやＯｒａｃｌｅ社のＯｒａｃｌｅ  Ｄａｔａｂａｓｅに代表されるデータベース管理システムが用いられる。なお、管理システム１１０の構成はこれに限られるものではなく、１台のサーバーでこれら機能を構成していても良く、冗長化構成のために複数のサーバーに分散した構成を採るようにしても良い。通信回線１２０は、ＬＡＮやＷＡＮ、インターネットなどが想定され、有線であっても無線であっても良い。
【００１７】
図２は、本発明の実施の形態に係る管理システム１１０のハードウェア構成を表す図である。管理システム１１０は、ディスプレイなどの出力装置と接続する出力Ｉ／Ｆ部２０１と、キーボードなどの入力装置と接続する入力Ｉ／Ｆ部２０２、記憶装置２０３、メモリ２０４、ＣＰＵ２０５、通信Ｉ／Ｆ部２０６からなる。記憶装置２０３には、ＯＳ（Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ）や特に本システムに係る部分のデータ管理プログラム、ユーザーにサービスを提供するための各種データが格納されている。ＣＰＵ２０５は、記憶装置２０３からデータ管理プログラムをメモリ２０４にロードし、実行する。通信Ｉ／Ｆ部２０６は、通信回線１２０に接続され、クライアント１００からデータの取得リクエストを受信する。
【００１８】
図３は、管理システム１１０のソフトウェア構成の中で、特に本発明に係る部分の機能ブロックを表す図である。
【００１９】
リクエスト受信部３０１は、クライアント１００からのデータの取得リクエストを受け付ける。取得リクエストは、ネットワーク経由で例えばＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）を使用して送信される。クエリ抽出部３０２は、リクエスト受信部３０１が受信した取得リクエスト内容を解析し、検索条件や並び替え順序などのデータ取得条件を指定したクエリを抽出する。選択部３０３は、クエリ抽出部３０２で抽出したクエリの指定内容に応じて、データベースに実行する取得処理を複数のデータ取得部から選択する。選択部３０３が選択する際のクエリのフォーマットパターンの条件は、クエリパターン保持部３０４によって保持される。クエリパターン保持部３０４は、例えば、設定ファイルの形式や設定テーブルでの保持が想定される。選択部３０３は、クエリパターン保持部３０４が保持する条件に従う判定により、２つの異なるデータ取得用のインターフェース（第一データ取得部３０５、第二データ取得部３０６）からいずれかを選択する。この選択部３０３の制御により、いずれのデータ取得用のインターフェースを利用する場合であっても、クライアント装置１００からのリクエストのフォーマットなどを共通化することができる。
【００２０】
第一データ取得部３０５は、特定の用途に特化された、該用途でパフォーマンスが向上するよう最適化されたデータ取得処理を実現するインターフェースである。具体的には、本実施例では、クエリの内容であるクエリに指定されたパラメータに従って最適化された、対象データを取得するＳＱＬ文を生成し、データベースに対して、実行する。第二データ取得部３０６は、様々なクエリに汎用的に対応したデータ取得処理を実現するインターフェースである。具体的には、クエリの指定内容に従って対象データを取得するＳＱＬ文を生成し、データベースに対して実行する。
【００２１】
レスポンス送信部３０７は、第一データ取得部３０５或いは第二データ取得部３０６が取得処理を実行した結果を、取得リクエストに対するレスポンスとしてクライアント１００に応答する。このとき、取得処理を実行した結果で検索条件に該当するデータが存在した場合には、そのデータをＸＭＬ形式やＪＳＯＮ形式などのＨＴＴＰプロトコル上で送信可能な形式に整形して、送信する。
【００２２】
図４は、管理システム１１０の取得リクエスト受信時の処理を説明するためのフローチャートである。以下、図４のフローチャートに従って、クライアント１００から取得リクエストを受信した際の管理システム１１０の処理を説明する。リクエスト受信部３０１がクライアント１００から取得リクエストを受信すると、本フローチャートの処理が開始される。
【００２３】
ここで、取得リクエストには、データベースのデータに対する検索条件や並び替え順序などのデータ取得条件が含まれる。本実施例では、データ取得条件の指定に、ＷｅｂデータプロトコルであるＯＤａｔａを適用した例を元に説明する。図５（Ａ）は、クライアント１００が管理システム１１０にＨＴＴＰで送信する取得リクエストのＵＲＩの例を表す図である。図５（Ａ）の例では、ＵＲＩ５００で取得対象のデータリソースやデータ取得条件を指定する。ホスト名部５０１は、管理システム１１０を特定するＦＱＤＮ（Ｆｕｌｌｙ  Ｑｕａｌｉｆｉｅｄ  Ｄｏｍａｉｎ  Ｎａｍｅ）を表す。図５（Ａ）の例では、管理システム１１０のＦＱＤＮが”ｈｏｓｔｎａｍｅ”であることを示す。リソース名部５０２は、取得を行う対象データを特定するためのリソースパス及びリソース名を表す。
【００２４】
クエリ部５１０は、取得対象データに対する検索条件や並び替え順序などのデータ取得条件であり、クエリオプションと呼ばれる。クエリ部５１０のうち”＄ｆｉｌｔｅｒ＝”で始まる検索条件部５１１は、取得対象データに対する検索条件が指定される。検索条件部５１１は、”ｅｑ”（等しい）や”ｎｅ”（等しくない）、”ｇｔ”（大なり）などの比較演算子、”ａｄｄ”（加算）などの算術演算子、”ａｎｄ”（Ａｎｄ条件）や”ｏｒ”（Ｏｒ条件）などを複数組み合わせて、複雑な条件を指定できる。
【００２５】
ＵＲＩ５００は、リソース名部５０２で指定されたリソース名のうち、検索条件部５１１で指定された条件に合致するデータを取得する取得リクエストであることを示す。図５（Ａ）の例では、「”ＬａｓｔＵｐｄａｔｅｄ”が”２０１４−０５−０１”以降」を検索条件とすることを示す。クエリ部５１０のうち”＄ｏｒｄｅｒｂｙ＝”で始まる並び替え順序部５１２は、検索したデータを並び替える際の対象の項目とその並び替え方法が指定される。図５（Ａ）の例では、「”ＬａｓｔＵｐｄａｔｅｄ”の昇順で並び替えること」を並び替え順序とすることを示す。並び替え順序の指定が不要な場合は、並び替え順序部５１２を省略することもできる。クライアント１００は、ＨＴＴＰメソッドにＧＥＴ（取得）を指定してこのＵＲＩに送信することで、管理システム１１０に対して、データの取得操作を指示する。なお、本実施例ではＵＲＩのクエリオプションで取得対象のデータに対するデータ取得条件を指定したが、ＨＴＴＰボディに指定するなど他の形式であっても良い。
【００２６】
Ｓ４０１で、クエリ抽出部３０２が、リクエスト受信部３０１が受信した取得リクエストの内容を解析して、データリソースを特定し、クエリを抽出する。前述の取得リクエストの例では、ＵＲＩからリソース名部５０２とクエリ部５１０の抽出を行う。Ｓ４０２で、選択部３０３は、クエリパターン保持部３０４が保持するクエリのフォーマットパターンを参照する。そして、Ｓ４０３で、選択部３０３は、取得リクエストのクエリ部５１０がフォーマットパターンの何れかと一致するか否かの判定を行う。
【００２７】
図５（Ｂ）は、クエリパターン保持部３０４が保持するクエリのフォーマットパターンの例を表す図である。選択部３０３が選択する際の条件はリソース名５５１とクエリパターン５５２で定められ、予め１つ以上が登録される。条件５６１及び５６２は、いずれもリソース名が”ｒｅｓｏｕｒｃｅＡ”である場合の条件であることを示す。図５（Ｂ）の例におけるクエリパターン５５２の”＜ｐａｒａｍ＞”は任意のパラメータが指定可能であることを示す。図５（Ａ）のクエリ部５１０の例の場合は、条件５６１及び５６２のうち条件５６１に合致する。
【００２８】
Ｓ４０３で何れかの条件に一致すると判定された場合には、Ｓ４０４で、選択部３０３は第一データ取得部３０５を選択する。第一データ取得部３０５が選択されると、Ｓ４０５で第一データ取得部３０５はクエリに指定されたパラメータに従って、データベースに対してデータの取得処理を実行する。Ｓ４０５のデータ取得処理は、クエリパターン保持部３０４が保持するクエリのフォーマットパターンに最適化されたデータ取得処理であって、該フォーマットパターンに対応するＳＱＬ文を生成してデータベースに送出し、データを取得する。ここで。第一データ取得部３０５は、クエリパターン保持部３０４が保持するクエリの各フォーマットパターンに対応して、複数のデータ取得処理を備えることもできる。その場合、どのフォーマットパターンに合致するかによって、複数のデータ取得処理から対応するデータ取得処理が選択され、実行される。
【００２９】
一方、Ｓ４０３で何れの条件にも合致しないと判定された場合には、Ｓ４０６で、選択部３０３は第二データ取得部３０６を選択する。第二データ取得部３０６が選択されると、Ｓ４０７で、第二データ取得部３０６はクエリの指定内容に従ってデータの取得処理を実行する。Ｓ４０７のデータ取得処理は、クエリの様々な指定内容に汎用的に対応したデータ取得処理であって、指定されたクエリを満たすＳＱＬ文を生成してデータベースに送出し、データを取得する。Ｓ４０５或いはＳ４０７でデータを取得すると、Ｓ４０８で、レスポンス送信部３０７は、取得したデータをＸＭＬ形式などのフォーマットに整形し、取得リクエストに対するレスポンスとしてクライアント１００に送信する。そして管理システム１１０は、取得リクエスト受信時の処理を終了する。
【００３０】
以上、詳細に説明した実施例１では、多様なクエリを含むデータ取得リクエストを受け付けるデータ管理システムにおいて、汎用的なクエリへの対応を確保しつつ、特定のクエリに対してパフォーマンスを向上させることが可能となる。特に、パフォーマンスを向上させることが可能なインターフェースの利用を、管理システムが、クエリの内容に従い判別して、切り替える。そのため、クライアント側に、管理システム内のデータ取得のための内部的なインターフェースの選択を意識させることなく、よりパフォーマンスを向上させたデータ取得サービスを提供できる。
【００３１】
（実施例２）
実施例１においては、クエリの指定内容に応じて、データベースに実行するデータ取得処理を複数のデータ取得部から選択した。
【００３２】
しかし、マルチテナントでデータを管理する管理システム１１０において、データの取得対象テナントによって、利用用途が異なる場合やデータベースの各テナントに格納されるデータセットの特性が異なる場合が考えられる。取得対象テナントに指定されるクエリのフォーマットパターンが固定している場合には、特定の取得対象テナントのときに、該取得対象テナントに指定されるクエリに最適化したインターフェースを選択するようにしても良い。そこで本実施例では、管理システム１１０としてテナント分離を実現している場合の、データベースに実行するデータ取得のインターフェースを、データの取得対象テナントに応じて選択する場合について、実施の形態を説明する。本実施例のシステム構成図は図１と、管理システム１１０のハードウェア構成は図２と、同一である。
【００３３】
図６は、管理システム１１０のソフトウェア構成の中で、特に本発明に係る部分の機能ブロックを表す図である。図３と同じ構成要素には同じ符号を付し、管理システム１１０の機能ブロックの中で本実施例において特徴的な部分を、図６を用いて説明する。
【００３４】
前提として、テナント分離のために、リクエスト受信部３０１が受信する取得リクエストは、データ取得条件などのほか、クライアント１００を認証する認証情報やデータの取得対象テナントを特定するテナント情報を含む。
【００３５】
クライアント認証部６０１は、リクエスト受信部３０１が受信した取得リクエストに含まれる認証情報の有効性を検証することにより、取得リクエスト送信元のクライアント１００を認証する。認証情報とは例えば、クライアント１００ごとに割り振られたクライアントを特定する特定情報（ＩＤとパスワードなど）のようなものである。各クライアント１００は、アクセスできるテナントが限定されており、テナント検証部６０２にクライアントを特定するＩＤとアクセスできる対象のテナント情報との対応情報を保持する。テナント検証部６０２は、取得リクエストからデータの取得対象テナントを特定し、ＩＤとテナント情報との対応情報からクライアント１００が取得対象テナントへのアクセス権限を有しているかを確認する。これにより管理システム１１０は、クライアント１００が許可されたテナントへのアクセスのみが認められるテナント分離を実現する。なお、認証情報は、別途認証サーバー（図示せず）がクライアント１００に発行したトークンのようなものであっても良く、認証サーバーにトークンの正当性を問い合わせることによりクライアント１００を認証しても良い。また、データの取得対象テナントは、トークンなどの認証情報から、クライアント１００の所属するテナントにより特定しても良い。選択部３０３は、データの取得対象テナントに応じて、データベースに実行する取得処理を複数のデータ取得部から選択する。選択部３０３が選択する際のテナントの条件は、テナント情報保持部６０３によって保持される。テナント情報保持部６０３は、例えば設定ファイルの形式や設定テーブルでの保持が想定され、予め１つ以上のテナント情報が登録される。選択部３０３は、テナント情報保持部６０３が保持するテナント情報の何れかと合致するか否かの判定により、第一データ取得部３０５、或いは第二データ取得部３０６を選択する。
【００３６】
図７は、管理システム１１０の取得リクエスト受信時の処理を説明するためのフローチャートである。以下、図７のフローチャートに従って、クライアント１００から取得リクエストを受信した際の管理システム１１０の処理を説明する。リクエスト受信部３０１がクライアント１００から取得リクエストを受信すると、本フローチャートの処理が開始される。
【００３７】
ここで、取得リクエストには、データベースのデータに対するデータ取得条件に加え、認証情報とデータの取得対象テナントのテナント情報が含まれる。データの取得対象テナントの情報は、例えば、取得リクエストのＵＲＩのリソース名部５０２に含めるようにし、クライアント１００が指定する。
【００３８】
Ｓ７０１で、クライアント認証部６０１は、取得リクエストに含まれる認証情報から、管理システム１１０に登録されたＩＤ情報と照合して認証情報の有効性を検証する。そして、Ｓ７０２で、クライアント認証部６０１は、Ｓ７０１での検証の結果を判定する。ここで、認証情報の有効性の検証に失敗した場合は、Ｓ７０３で、取得リクエストに対するレスポンスとして、クライアント１００へ認証に失敗した情報を送信して、以降の処理を中止する。認証情報の有効性検証に成功すると、Ｓ７０４に進む。
【００３９】
Ｓ７０４で、テナント検証部６０２が取得リクエストからデータの取得先となる取得対象テナントを特定し、Ｓ７０５でさらに取得対象テナントへのアクセス権限をクライアント１００が有しているかを確認する。Ｓ７０６で、テナント検証部６０２がＳ７０５での確認の結果を判定する。ここで、アクセス権限を有していることが認められなかった場合は、Ｓ７０３で取得リクエストに対するレスポンスとして、クライアント１００へ認可に失敗した情報を送信して、以降の処理を中止する。アクセス権限を有していることが認められた場合には、Ｓ７０７に進む。
【００４０】
Ｓ７０７で、クエリ抽出部３０２が、取得リクエストの内容を解析して、データリソースを特定し、クエリを抽出する。そして、Ｓ７０８で、選択部３０３が、テナント情報保持部６０３が保持するテナント情報を参照し、Ｓ７０９で、さらに、ここまでで特定された取得対象テナントが含まれるか否かの判定を行う。
【００４１】
Ｓ７０９でテナント情報保持部６０３が保持するテナント情報に取得対象テナントが含まれると判定された場合には、Ｓ７１０で選択部３０３は、第一データ取得部３０５を選択する。第一データ取得部３０５が選択されると、Ｓ７１１で第一データ取得部３０５は、クエリに指定されたパラメータに従ってデータ取得処理を実行する。Ｓ７１１のデータ取得処理は、テナント情報保持部６０３が保持するテナントからデータ取得される際のクエリに最適化されたデータ取得処理である。具体的には、該クエリに対応するＳＱＬ文を生成してデータベースに送出し、データを取得する。ここで第一データ取得部３０５は、テナント情報保持部６０３が保持する各テナントに対応して、複数のデータ取得処理を備えることもできる。その場合、どのテナント情報に合致するかによって、複数のデータ取得処理から各テナント情報に対応する対応するデータ取得処理が選択され、実行される。
【００４２】
一方、Ｓ７０９でテナント情報保持部６０３が保持するテナント情報に取得対象テナントが含まれないと判定された場合には、Ｓ７１２で選択部３０３は第二データ取得部３０６を選択する。第二データ取得部３０６が選択されると、Ｓ７１３で第二データ取得部３０６はクエリの指定内容に従ってデータ取得処理を実行する。Ｓ７１３のデータ取得処理は、クエリの様々な指定内容に汎用的に対応したデータ取得処理である。指定されたクエリを満たすＳＱＬ文を生成してデータベースに送出し、データを取得する。
【００４３】
Ｓ７１１或いはＳ７１３でデータを取得すると、レスポンス送信部３０７は取得したデータをＸＭＬ形式などのフォーマットに整形し、取得リクエストに対するレスポンスとしてクライアント１００に送信する（Ｓ７１４）。そして管理システム１１０は、取得リクエスト受信時の処理を終了する。
【００４４】
以上、詳細に説明した本発明を適用できる本実施形態では、マルチテナントでデータを管理する管理システム１１０において、汎用的なクエリへの対応を確保しつつ、特定のテナント条件の場合にパフォーマンスを向上させることが可能となる。本実施例においては、データの取得対象テナントによって、指定されるクエリのフォーマットパターンが固定されることがある場合に、該テナントを管理システムが判別した上で、データ取得のためのインターフェースを切り替える。これにより、クライアント１００側にデータ取得手段の選択を意識させることなく、よりパフォーマンスを向上させたデータ取得サービスを提供できる。
【００４５】
（実施例３）
実施例１においては、クエリの指定内容に応じて、データベースに実行する取得処理を複数の取得処理部から選択した。
【００４６】
しかし、管理システム１１０において、リクエスト元のクライアント１００によってクエリの指定内容が異なる場合が考えられる。クライアント１００が指定するクエリのフォーマットパターンが固定している場合には、特定のクライアント１００のときに、クライアント１００が指定するクエリに最適化したデータ取得処理を選択するようにしても良い。そこで本実施例では、データベースに実行する取得処理をリクエスト元のクライアントに応じて選択する場合について、実施の形態を説明する。
【００４７】
本実施例のシステム構成図は図１と、管理システム１１０のハードウェア構成は図２と同一である。
【００４８】
図８は、管理システム１１０のソフトウェア構成の中で、特に本発明に係る部分の機能ブロックを表す図である。図３と同じ構成要素には同じ符号を付し、管理システム１１０の機能ブロックの中で本実施例において特徴的な部分を、図８を用いて説明する。
【００４９】
ここで、リクエスト受信部３０１が受信する取得リクエストは、データ取得条件などのほか、クライアント１００を認証する認証情報を含む。
【００５０】
クライアント特定部８０１は、リクエスト受信部３０１が受信した取得リクエストに含まれる認証情報の有効性を検証することにより、取得リクエスト送信元のクライアント１００を特定する。認証情報とは例えば、クライアント１００ごとに割り振られたクライアントを特定するＩＤとパスワードのようなものである。選択部３０３は、取得リクエスト送信元のクライアント１００に応じて、データベースに実行する取得処理を複数のデータ取得部から選択する。選択部３０３が選択する際のクライアントの条件は、クライアント情報保持部８０２によって保持される。クライアント情報保持部８０２は、例えば設定ファイルの形式や設定テーブルでの保持が想定され、クライアントを特定するＩＤなどのクライアント情報が予め１つ以上登録される。選択部３０３は、クライアント情報保持部８０２が保持するクライアント情報の何れかと合致するか否かの判定により、第一データ取得部３０５、或いは第二データ取得部３０６を選択する。
【００５１】
図９は、管理システム１１０の取得リクエスト受信時の処理を説明するためのフローチャートである。以下、図９のフローチャートに従って、クライアント１００から取得リクエストを受信した際の管理システム１１０の処理を説明する。リクエスト受信部３０１がクライアント１００から取得リクエストを受信すると、本フローチャートの処理が開始される。
【００５２】
前提として、取得リクエストには、データベースのデータに対するデータ取得条件に加え、認証情報を含む。
【００５３】
Ｓ９０１で、クライアント特定部８０１は、取得リクエストに含まれる認証情報から、管理システム１１０に登録されたＩＤ情報と照合して認証情報の有効性を検証する。Ｓ９０２で、検証の結果を判定する。ここで認証情報の有効性の検証に失敗した場合は、取得リクエストに対するレスポンスとして、Ｓ９０３で、クライアント１００へ認証に失敗した情報を送信して、以降の処理を中止する。認証情報の有効性検証に成功するとＳ９０４に進む。
【００５４】
Ｓ９０４で、クライアント特定部８０１は、認証情報から取得リクエスト送信元のクライアント１００を特定する。そして、Ｓ９０５で、クエリ抽出部３０２が取得リクエストの内容を解析して、データリソースを特定し、クエリを抽出する。Ｓ９０６で選択部３０３が、クライアント情報保持部８０２が保持するクライアント情報を参照し、Ｓ９０４で特定したクライアント１００が含まれるか否かの判定を行う（Ｓ９０７）。Ｓ９０７で、クライアント情報保持部８０２が保持するクライアント情報にクライアント１００が含まれると判定された場合には、Ｓ９０８で選択部３０３は第一データ取得部３０５を選択する。第一データ取得部３０５が選択されると、Ｓ９０９で、第一データ取得部３０５は、クエリに指定されたパラメータに従ってデータ取得処理を実行する。Ｓ９０９のデータ取得処理は、クライアント１００が指定するクエリに最適化されたデータ取得のための処理であって、該クエリに対応するＳＱＬ文を生成してデータベースに送出し、データを取得する。ここで、第一データ取得部３０５は、クライアント情報保持部８０２が保持する各クライアントに対応して、複数のデータ取得処理を備えることもできる。その場合、どのクライアント情報に合致するかによって、複数のデータ取得処理から各クライアント情報に対応するデータ取得処理が選択され、実行される。
【００５５】
一方、Ｓ９０７でクライアント情報保持部８０２が保持するクライアント情報にクライアント１００が含まれないと判定された場合には、Ｓ９１０で、選択部３０３は第二データ取得部３０６を選択する。第二データ取得部３０６が選択されると、Ｓ９１１で、第二データ取得部３０６はクエリの指定内容に従ってデータ取得処理を実行する。Ｓ９１１のデータ取得処理は、クエリの様々な指定内容に汎用的に対応したデータ取得処理であって、指定されたクエリを満たすＳＱＬ文を生成してデータベースに送出し、データを取得する。Ｓ９０９或いはＳ９１１でデータを取得すると、Ｓ９１２で、レスポンス送信部３０７は取得したデータをＸＭＬ形式などのフォーマットに整形し、取得リクエストに対するレスポンスとしてクライアント１００に送信する。そして管理システム１１０は、取得リクエスト受信時の処理を終了する。
【００５６】
以上、本実施例では、データ取得リクエストを受け付ける管理システム１１０において、汎用的なクエリへの対応を確保しつつ、特定のクライアント条件の場合にパフォーマンスを向上させることが可能となる。本実施例においては、リクエスト元のクライアント１００によって、指定されるクエリのフォーマットパターンが固定されることがある場合に、該クライアントをデータ管理システムが判別してデータ取得手段を切り替える。これにより、クライアント１００側にデータ取得手段の選択を意識させることなく、よりパフォーマンスを向上させたデータ取得サービスを提供できる。
【００５７】
（応用例）
本発明は、上述した実施形態を適宜組み合わせることにより構成されたシステムやその方法も含まれるものとする。具体的には、図３，６，８に含まれる構成を、重複なく管理システムに実装し、オペレーターによる設定、時間や運用に従う条件などに応じて、適宜、選択的に利用することも可能である。
【００５８】
（他の実施例）
ここで、本発明は、上述した実施形態の機能を実現する１以上のソフトウェア（プログラム）を実行する主体となる装置あるいはシステムである。また、その装置あるいはシステムで実行される上述した実施形態を実現するための方法も本発明の一つである。また、そのプログラムは、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給され、そのシステム或いは装置の１以上のコンピュータ（ＣＰＵやＭＰＵ等）によりそのプログラムが読み出され、実行される。つまり、本発明の一つとして、さらにそのプログラム自体、あるいは該プログラムを格納したコンピュータにより読み取り可能な各種記憶媒体も含むものとする。また、上述した実施形態の機能を実現する回路（例えば、ＡＳＩＣ）によっても、本発明は実現可能である。
【符号の説明】
【００５９】
１００  クライアント
１１０  管理システム
１１１  ウェブサーバー
１１２  データベースサーバー
１２０  通信回線
【図１】
2016004306.tif 000003
【図２】
2016004306.tif 000004
【図３】
2016004306.tif 000005
【図４】
2016004306.tif 000006
【図５】
2016004306.tif 000007
【図６】
2016004306.tif 000008
【図７】
2016004306.tif 000009
【図８】
2016004306.tif 000010
【図９】
2016004306.tif 000011