(57)【要約】【課題】利用者ごとに異なるデータ領域を有するデータベースにアクセスするアプリケーションの開発を簡便化させることのできるデータアクセス制御方法の提供を目的とする。【解決手段】クライアント装置より受信するログイン要求に基づいて該クライアント装置のユーザのユーザＩＤを取得し、該ユーザＩＤに対応するテナントＩＤをテナントＩＤ管理テーブルから取得して識別情報記憶手段に記録する手順と、クライアント装置より受信する処理要求に応じたアプリケーションソフトウェアを起動する手順と、アプリケーションソフトウェアからデータベースへのアクセス要求を受け付け、識別情報記憶手段に記録されているテナントＩＤに基づいて、データベースにおける複数のデータ領域のうち該テナントＩＤに対応するデータ領域に対するアクセス要求をデータベース管理部に送信する手順とを有することにより上記課題を解決する。【選択図】図４
2010026653.tif 000002
【特許請求の範囲】
【請求項１】
クライアント装置とネットワークを介して接続されるコンピュータが実行するデータアクセス制御方法であって、
前記クライアント装置より受信するログイン要求に基づいて該クライアント装置のユーザのユーザＩＤを取得し、該ユーザＩＤに対応するテナントＩＤを、ユーザＩＤとテナントＩＤとを対応付けて記憶するテナントＩＤ管理テーブルから取得して識別情報記憶手段に記録する識別情報記録手順と、
前記クライアント装置より受信する処理要求に応じたアプリケーションソフトウェアを起動するアプリケーションソフトウェア起動手順と、
前記アプリケーションソフトウェアからデータベースへのアクセス要求を受け付け、前記識別情報記憶手段に記録されている前記テナントＩＤに基づいて、前記データベースにおける複数のデータ領域のうち該テナントＩＤに対応するデータ領域に対するアクセス要求をデータベース管理部に送信するアクセス手順とを有するデータアクセス制御方法。
【請求項２】
前記識別情報記録手順は、前記コンピュータと前記クライアント装置とのセッションを管理するためのデータの一部として前記テナントＩＤを前記識別情報記憶手段に記録する請求項１記載のデータアクセス制御方法。
【請求項３】
前記アクセス手順は、前記テナントＩＤの従属関係を記憶する親子関係記憶手段を用いて前記識別情報記憶手段に記録された前記テナントＩＤに従属する複数の子テナントＩＤを取得し、前記複数の子テナントＩＤに対応するデータ領域に対するアクセス要求をデータベース管理部に送信し、該アクセス要求の結果をマージして前記アプリケーションソフトウェアに回答する請求項１又は２記載のデータアクセス制御方法。
【請求項４】
クライアント装置とネットワークを介して接続されるデータアクセス制御装置であって、
前記クライアント装置より受信するログイン要求に基づいて該クライアント装置のユーザのユーザＩＤを取得し、該ユーザＩＤに対応するテナントＩＤを、ユーザＩＤとテナントＩＤとを対応付けて記憶するテナントＩＤ管理テーブルから取得して識別情報記憶手段に記録する識別情報記録手段と、
前記クライアント装置より受信する処理要求に応じたアプリケーションソフトウェアを起動するアプリケーションソフトウェア起動手段と、
前記アプリケーションソフトウェアからデータベースへのアクセス要求を受け付け、前記識別情報記憶手段に記録されている前記テナントＩＤに基づいて、前記データベースにおける複数のデータ領域のうち該テナントＩＤに対応するデータ領域に対するアクセス要求をデータベース管理部に送信するアクセス手段とを有するデータアクセス制御装置。
【請求項５】
クライアント装置とネットワークを介して接続されるコンピュータに、
前記クライアント装置より受信するログイン要求に基づいて該クライアント装置のユーザのユーザＩＤを取得し、該ユーザＩＤに対応するテナントＩＤを、ユーザＩＤとテナントＩＤとを対応付けて記憶するテナントＩＤ管理テーブルから取得して識別情報記憶手段に記録する識別情報記録手順と、
前記クライアント装置より受信する処理要求に応じたアプリケーションソフトウェアを起動するアプリケーションソフトウェア起動手順と、
前記アプリケーションソフトウェアからデータベースへのアクセス要求を受け付け、前記識別情報記憶手段に記録されている前記テナントＩＤに基づいて、前記データベースにおける複数のデータ領域のうち該テナントＩＤに対応するデータ領域に対するアクセス要求をデータベース管理部に送信するアクセス手順とを実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データアクセス制御方法、データアクセス制御装置、及びプログラムに関し、データベースに対するデータアクセス制御方法、データアクセス制御装置、及びプログラムに関する。
【背景技術】
【０００２】
従来、ＡＳＰ（Application Service Provider）と等において提供されるＷｅｂアプリケーションについては、利用者に応じたニーズに対応するため、Ｗｅｂサーバ側において、一つのアプリケーションを利用者ごとにカスタマイズし、それぞれを別個に管理及び動作させる必要があった。なお、ここでいう利用者とは、企業、団体、官公庁等、ＡＳＰの提供者とサービスの利用契約を結んでいる組織をいう。
【０００３】
一方、昨今注目されているＳａａＳ（Software as a Service）と呼ばれるシステム形態では、同一のＷｅｂアプリケーションを同一のサーバ上で動かし、複数の利用者に同一のＷｅｂアプリケーションを利用させることで、運用コストの削減を図っている。
【特許文献１】特開２００４−３１０３５６号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかしながら、例えば、データベースを利用した情報管理系のＷｅｂアプリケーションがＳａａＳの形態によって提供される場合、データベースによって管理される情報は、セキュリティ上の観点等より利用者ごとに適切に区分されて管理されることが望ましい。具体的には、利用者ごとに異なるデータ領域が用意されることが望ましい。
【０００５】
但し、データベースを利用するＷｅｂアプリケーションは各種存在する。したがって、利用者に応じたデータ領域を判定し、当該データ領域にアクセスするためのロジックをＷｅｂアプリケーションごとに実装するのは開発作業の煩雑化、開発コストの増大等を招くという問題があった。
【０００６】
本発明は、上記の点に鑑みてなされたものであって、利用者ごとに異なるデータ領域を有するデータベースにアクセスするアプリケーションの開発を簡便化させることのできるデータアクセス制御方法、データアクセス制御装置、及びプログラムの提供を目的とする。
【課題を解決するための手段】
【０００７】
そこで上記課題を解決するため、クライアント装置とネットワークを介して接続されるコンピュータが実行するデータアクセス制御方法であって、前記クライアント装置より受信するログイン要求に基づいて該クライアント装置のユーザのユーザＩＤを取得し、該ユーザＩＤに対応するテナントＩＤを、ユーザＩＤとテナントＩＤとを対応付けて記憶するテナントＩＤ管理テーブルから取得して識別情報記憶手段に記録する識別情報記録手順と、前記クライアント装置より受信する処理要求に応じたアプリケーションソフトウェアを起動するアプリケーションソフトウェア起動手順と、前記アプリケーションソフトウェアからデータベースへのアクセス要求を受け付け、前記識別情報記憶手段に記録されている前記テナントＩＤに基づいて、前記データベースにおける複数のデータ領域のうち該テナントＩＤに対応するデータ領域に対するアクセス要求をデータベース管理部に送信するアクセス手順とを有する。
【０００８】
このようなデータアクセス制御方法では、利用者ごとに異なるデータ領域を有するデータベースにアクセスするアプリケーションの開発を簡便化させることができる。
【発明の効果】
【０００９】
本発明によれば、利用者ごとに異なるデータ領域を有するデータベースにアクセスするアプリケーションの開発を簡便化させることのできるデータアクセス制御方法、データアクセス制御装置、及びプログラムを提供することができる。
【発明を実施するための最良の形態】
【００１０】
以下、図面に基づいて本発明の実施の形態を説明する。図１は、本発明の実施の形態におけるシステム構成例を示す図である。
【００１１】
同図において、Ｗｅｂサーバ１０及びＤＢ（Data Base）サーバ２０は、例えば、ＳａａＳ（Software as a Service）と呼ばれる形態によってインターネットを介してアプリケーションソフトウェア（以下、説明の便宜上単に「アプリケーション」という。）の機能によるサービスをテナント（後述する）に提供するサービス提供者側に属するコンピュータである。また、クライアント装置３０ａ、３０ｂ、及び３０ｃ等（以下、総称する場合「クライアント装置３０」という。）は、サービス利用者側に属するコンピュータである。クライアント装置３０ａ、クライアント装置３０ｂ、クライアント装置３０ｃは、それぞれテナントＡ、テナントＢ、テナントＣに属する。本実施の形態においてテナントとは、サービス提供者との間でサービスの利用契約を結んだ企業又は団体等の組織をいう。したがって、テナントは一人以上のユーザの集合であるといえる。
【００１２】
ＤＢサーバ２０は、ＤＢＭＳ（DataBase Management System）２１及び業務ＤＢ２２等を有する。
【００１３】
業務ＤＢ２２は、業務アプリケーション１３によって管理対象とされる情報を体系的に管理するデータベースである。同図において、業務ＤＢ２２は、テーブルＡ２２１ａ、テーブルＢ２２１ｂ、及びテーブルＣ２２１ｃ（以下、総称する場合「テーブル２２１」という。）を含む。テーブルＡ２２１ａはテナントＡに対応するテーブル（データ管理領域）である。テーブルＢ２２１ｂはテナントＢに対応するテーブルである。テーブルＣ２２１ｃはテナントＣに対応するテーブルである。このように、業務ＤＢ２２においては、テナント毎にデータ領域が明確に区別されている。
【００１４】
例えば、図２は、業務ＤＢにおけるテーブルの構成例を示す図である。同図では、便宜上、テーブルＡ２２１ａ及びテーブルＢ２２１ｂの構成例が示されている。同図では、各テーブルのスキーマ（構造）は同じ例が示されている。すなわち、テーブルＡ２２１ａ及びテーブルＢ２２１ｂのいずれのレコードも項目Ａ及び項目Ｂより構成される。但し、各テーブル２２１のスキーマは必ずしも同一でなくてもよい。
【００１５】
ＤＢＭＳ２１は、いわゆるＤＢＭＳ（データベース管理部）であり、例えば、ＳＱＬ（Structured Query Language）文の入力に応じ、当該ＳＱＬ文に従った処理を業務ＤＢ２２に対して行う。
【００１６】
Ｗｅｂサーバ１０は、データアクセス制御装置の一例であり、ＨＴＴＰ（HyperText Transfer Protocol）サーバ１１、アプリケーションサーバ１２、業務アプリケーション１３、及びマルチテナント制御部１４等のソフトウェアを有する。
【００１７】
ＨＴＴＰサーバ１１は、クライアント装置３０との通信を制御する。例えば、ＨＴＴＰサーバ１１は、クライアント装置３０からの要求（ＨＴＴＰリクエスト）を受信し、当該要求に対する応答（ＨＴＴＰレスポンス）を返信する。
【００１８】
アプリケーションサーバ１２は、クライアント装置３０からの要求に応じた（ＵＲＬ（Uniform Resource Locator）に対応した）業務アプリケーション１３を起動させる（呼び出す）。
【００１９】
業務アプリケーション１３は、いわゆるＷｅｂアプリケーションであり、機能に応じて複数存在する。本実施の形態において、各業務アプリケーション１３は、ＤＢサーバ２０を利用した情報管理機能を提供する。また、各業務アプリケーション１３は、それぞれ複数のテナントより共通的に利用される。
【００２０】
マルチテナント制御部１４は、各テナントに属するクライアント装置３０からの要求に応じ、業務ＤＢ２２内のテーブル２２１のうちいずれをアクセス先とするかを制御する。マルチテナント制御部１４は、斯かる制御の仕組みを各業務アプリケーション１３に対して共通に提供する。換言すれば、各業務アプリケーション１３は、マルチテナント制御部１４によって提供される仕組みによって、テナントとテーブル２２１との対応関係を意識する必要はない。
【００２１】
マルチテナント制御部１４は、テナント判定部１４１、データベースアクセス部１４２、及びセッションスコープアクセスＡＰＩ（Application Program Interface）１４３等を含む。テナント判定部１４１は、ＨＴＴＰサーバ１１によって受信されるＨＴＴＰリクエストに含まれている情報に基づいて当該ＨＴＴＰリクエストの送信元のクライアント装置３０（ユーザ）が属するテナントを判定する。データベースアクセス部１４２は、業務アプリケーション１３に対してＤＢＭＳ２１へのアクセス用のインタフェース（関数又はメソッド）を提供する。データベースアクセス部１４２は、当該インタフェースを介したＤＢＭＳ２１へのアクセス要求に応じ当該アクセス要求に対応するＳＱＬ文を生成し、ＤＢサーバ２０に送信する。この際、データベースアクセス部１４は、テナント判定部１４１によって判定されたテナントに対応するテーブル２２１をアクセス対象とする。セッションスコープアクセスＡＰＩ１４３は、セッションスコープ１５に対するアクセス手段を提供する関数群である。本実施の形態において「セッションスコープ」とは、クライアント装置３０とのセッション（又はセッション情報）を管理するためにメモリ装置１０３内に生成されるデータをいい、例えば、一般的にセッションオブジェクトと呼ばれる。例えば、テナント判定部１４１は、セッションスコープアクセスＡＰＩ１４３を利用して、判定結果としてのテナントの識別情報（以下、「テナントＩＤ」という。）をセッションスコープ１５に記録（登録）する。なお、テナントＩＤは、テナントごとに一意となるように割り当てられている。また、データベースアクセス部１４２は、セッションスコープ１５に登録されているテナントＩＤをセッションスコープアクセスＡＰＩ１４３を利用して取得する。
【００２２】
なお、Ｗｅｂサーバ１０とＤＢサーバ２０とは、ＬＡＮ（Local Area Network）又はインターネット等のネットワーク（有線又は無線の別は問わない。）を介して接続されている。また、クライアント装置３０とＷｅｂサーバ１０とはインターネット等を介して接続されている。
【００２３】
図３は、本発明の実施の形態におけるＷｅｂサーバのハードウェア構成例を示す図である。図３のＷｅｂサーバ１０は、それぞれバスBで相互に接続されているドライブ装置１００と、補助記憶装置１０２と、メモリ装置１０３と、ＣＰＵ１０４と、インタフェース装置１０５とを有する。
【００２４】
Ｗｅｂサーバ１０での処理を実現するプログラムは、ＣＤ−ＲＯＭ等のコンピュータ読み取り可能な記録媒体１０１によって提供される。プログラムを記録した記録媒体１０１がドライブ装置１００にセットされると、プログラムが記録媒体１０１からドライブ装置１００を介して補助記憶装置１０２にインストールされる。但し、プログラムのインストールは必ずしも記録媒体１０１より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。補助記憶装置１０２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。
【００２５】
メモリ装置１０３は、プログラムの起動指示があった場合に、補助記憶装置１０２から読み出されたプログラムが格納される。ＣＰＵ１０４は、メモリ装置１０３に格納されたプログラムに従ってＷｅｂサーバ１０に係る機能を実行する。インタフェース装置１０５は、ネットワークに接続するためのインタフェースとして用いられる。
【００２６】
以下、Ｗｅｂサーバ１０の処理手順について説明する。図４は、Ｗｅｂサーバによる処理手順を説明するためのフローチャートである。
【００２７】
ＨＴＴＰサーバ１１によるクライアント装置３０からのＨＴＴＰリクエストの受信に応じ（Ｓ１０１）、テナント判定部１４１は、当該クライアント装置３０とのセッションに対応するセッションスコープ１５にテナントＩＤが登録されているか否かを判定する（Ｓ１０２）。
【００２８】
なお、各セッションはセッションＩＤによって識別される。セッションＩＤは、セッションの開設時にアプリケーションサーバ１２によって割り当てられ、クライアント装置３０に送信される。クライアント装置３０は、セッションＩＤをＣｏｏｋｉｅ等に保持しておき、ＨＴＴＰリクエストの度にＷｅｂサーバ１０に対して送信する。また、セッションスコープ１５は、セッションの開設時にセッションＩＤと共にアプリケーションサーバ１２によって生成され、セッションＩＤに関連付けられて管理されている。したがって、テナント判定部１４１は、セッションＩＤに基づいて現在のセッションに対応するセッションスコープ１５を取得することができる。
【００２９】
ところで、本実施の形態においてセッションスコープ１５にテナントＩＤが登録されていないという状態は、受信されたＨＴＴＰリクエストがログイン要求である場合に相当する。ログイン要求には、クライアント装置１０のＷｅｂブラウザに表示されているログイン画面に対して入力されたユーザＩＤ（各ユーザを識別するＩＤ）及びパスワードが含まれている。そこで、この場合（Ｓ１０２でＮｏ）、テナント判定部１４１は、テナントＩＤ管理テーブルに基づいて、ＨＴＴＰリクエスト（ログイン要求）に含まれているユーザＩＤに対応するテナントＩＤを判定する（Ｓ１０３）。
【００３０】
図５は、テナントＩＤ管理テーブルの構成例を示す図である。同図に示されるように、テナントＩＤ管理テーブル１６には、ユーザＩＤとテナントＩＤとの対応情報が登録されている。例えば、ログイン要求に含まれているユーザＩＤが「ｕｓｅｒ０１」であった場合、テナント判定部１４１は、対応するテナントＩＤは「ＡＡＡ」であると判定する。
【００３１】
続いて、テナント判定部１４１は、判定結果としてのテナントＩＤをセッションスコープ１５に登録する（Ｓ１０４）。
【００３２】
一方、セッションスコープにテナントＩＤが既に登録されている場合（すなわち、ＨＴＴＰリクエストがログイン要求以外の業務ロジックの実行要求の場合）（Ｓ１０２でＹｅｓ）、ステップＳ１０３及びＳ１０４の処理は行われない。
【００３３】
続いて、アプリケーションサーバ１２は、ＨＴＴＰリクエストの内容（例えば、ＨＴＴＰリクエストに含まれるＵＲＬ等）に応じた業務アプリケーション１３を判定し、当該業務アプリケーション１３を呼び出す（又は起動する）（Ｓ１０５）。ＨＴＴＰリクエストの内容に応じた業務アプリケーション１３の判定は、例えば、補助記憶装置１０２に記録されている、ＵＲＬと業務アプリケーション１３との対応情報等に基づいて行えばよい。
【００３４】
続いて、呼び出された業務アプリケーション１３は、自らに実装されている業務ロジックを実行する（Ｓ１０６）。業務アプリケーション１３は、業務ロジックを実行する過程において業務ＤＢ２２に対するアクセス（データの検索、登録、更新、又は削除等の操作）をデータベースアクセス部１４２に要求する（Ｓ１０７）。この際、業務アプリケーション１３は、いずれのテナントに対するテーブルをアクセス対象とするかについては関与しない。例えば、図１又は図２に示されるように、テナントごとに一つのテーブル２２１が存在する場合は、業務アプリケーション１３はアクセス対象とするテーブル名は指定しない。また、テナントごとに複数のテーブル２２１が存在する場合（例えば、テナントごとに商品情報テーブル及び顧客情報テーブル等が有る場合）、業務アプリケーション１３は、アクセス対象が商品情報テーブルか顧客情報テーブルかを指定するのみで、いずれのテナントのテーブル２２１であるかは指定しない。
【００３５】
続いて、データベースアクセス部１４２は、セッションスコープ１５よりテナントＩＤを取得する（Ｓ１０８）。ここで、テナント判定部１４１及びデータベースアクセス部１４２は同一スレッド内において動作する。したがって、データベースアクセス部１４２は、テナント判定部１４１によって当該スレッド空間内に取得されたセッションスコープ１５を参照すればよい。
【００３６】
続いて、データベースアクセス部１４２は、取得されたテナントＩＤに対応するテーブル２２１に基づいてアクセス対象とするテーブル２２１を判定する。データベースアクセス部１４２は、アクセス対象とされたテーブル２２１に対して業務アプリケーション１３より要求されたアクセスを実行するためのＳＱＬ文を生成し、当該ＳＱＬ文をＤＢＭＳ２１に送信する（Ｓ１０９）。なお、テナントＩＤに基づくアクセス対象とするテーブル２２１の判定は、補助記憶装置１０２に保存されている各テナントＩＤと各テーブル２２１のテーブル名との対応情報に基づいて行えばよい。また、各テーブル名が各テナントＩＤと一致する場合、テナントＩＤをそのままＳＱＬ文におけるテーブル名として判定すればよい。
【００３７】
当該ＳＱＬ文に応じてＤＢＭＳ２１は、業務ＤＢ２２に対するアクセス（操作）を行う。したがって、ＨＴＴＰリクエストの送信元のテナントに対応するテーブル２２１に対してアクセスが行われる。
【００３８】
続いて、データベースアクセス部１４２は、業務ＤＢ２２へのアクセス結果（例えば、検索結果等）をＤＢＭＳ２１より受信すると、当該アクセス結果を業務アプリケーション１３に通知する（Ｓ１１０）。続いて、業務アプリケーション１３は、当該アクセス結果を利用して業務ロジックの続きを実行し、当該業務ロジックの結果を表示させるＨＴＭＬ（HyperText Markup Language）データを生成する（Ｓ１１１）。続いて、ＨＴＴＰサーバ１１は、業務アプリケーション１３によって生成されたＨＴＭＬデータをＨＴＴＰレスポンスに含めてクライアント装置３０に送信する（Ｓ１１２）。
【００３９】
上述したように、本実施の形態におけるＷｅｂサーバ１０によれば、マルチテナント制御部１４が、ＨＴＴＰリクエストの要求元のテナントＩＤの判定及び当該テナントＩＤに対応するテーブル２２１の判定を行う。したがって、複数のテナントから共通的に利用される各業務アプリケーション１３にはこれらの判定を行うためのロジックを実装する必要はない。よって、各業務アプリケーション１３の開発作業を簡便化させることができる。
【００４０】
なお、上記においては、ユーザＩＤに対応するテナントＩＤの判定をテナント判定部１４１が行う例を説明したが、当該判定をデータベースアクセス部１４２が行うようにしてもよい。この場合、テナント判定部１４１はユーザＩＤをセッションスコープ１５に登録しておけばよい。データベースアクセス部１４２は、セッションスコープ１５に登録されているユーザＩＤとテナントＩＤ管理テーブル１６とに基づいてテナントＩＤを判定すればよい。
【００４１】
また、テナント管理テーブル１６においてテナントＩＤと対応付ける情報は、ユーザＩＤでなくてもよい。クライアント装置３０ごとの任意の識別情報であってもよい。
【００４２】
更に、ログイン時において、ユーザＩＤ及びパスワードが指定されるのではなく、テナントＩＤ及びパスワードが指定される場合（すなわち、同一のテナントに属するユーザは、同一のテナントＩＤによってログインする場合）、テナント管理テーブル１６は必要ではない。
【００４３】
ところで、テナント間に親子関係（従属関係）が存在する場合がある。例えば、各テナントが企業である場合、親会社に対応するテナントと、当該親会社の複数の子会社に対応する複数のテナントが存在しうる。また、テナントが一つの企業内の組織である場合、事業部に対応するテナントと、当該事業部に属する複数の部に対応する複数のテナントが存在しうる。このようにテナント間に親子関係が存在する場合において、親テナントが複数の子テナントのテーブル２２１にまとめてアクセスすることができると便利である。
【００４４】
斯かる機能を実現する場合、図４のステップＳ１０９を次のように変更すればよい。図６は、テナント間に親子関係が存在する場合のデータベースアクセス部による業務ＤＢへのアクセス処理を説明するための図である。
【００４５】
ステップＳ１０９１において、セッションスコープ１５より取得されたテナントＩＤに係るテナントに子テナントが存在するか否かを判定する。当該判定は、補助記憶装置１０２に記録されている親子関係管理テーブルに基づいて行えばよい。
【００４６】
図７は、親子関係管理テーブルの構成例を示す図である。同図において親子関係管理テーブル１７には、子テナントを有するテナントのテナントＩＤ（親テナントＩＤ）ごとに、子テナントのテナントＩＤ（親テナントＩＤに従属するテナントＩＤ）の一覧が登録されている。
【００４７】
したがって、ステップＳ１０９１において、セッションスコープ１５より取得されたテナントＩＤが親テナントＩＤとして親子関係管理テーブル１７に登録されている場合、子テナントは存在すると判定する。また、セッションスコープ１５より取得されたテナントＩＤが親テナントＩＤとして親子関係管理テーブル１７に登録されていない場合、子テナントは存在しないと判定する。
【００４８】
子テナントが存在すると判定した場合、親子関係管理テーブル１７に登録されている各子テナントＩＤに対応する各テーブル２２１に対して、図４のステップＳ１０９と同じ処理を実行する（Ｓ１０９２）。
【００４９】
子テナントが存在しないと判定した場合、セッションスコープ１５より取得されたテナントＩＤに対応するテーブル２２１に対して、ステップＳ１０９と同じ処理を実行する（Ｓ１０９３）。
【００５０】
なお、子テナントが複数存在した場合、アクセス要求が検索であるときは各子テナントに対応するそれぞれのテーブル２２１に対して検索が実行され、その検索結果が取得される。この場合、データベースアクセス部１４２は、当該検索結果をそのまま業務アプリ２２１に出力してもよいし、検索結果の内容をマージ（統合）した結果を業務アプリ２２１に出力してもよい。
【００５１】
検索結果の内容をマージする例としては、例えば、親会社（又は事業部）が子会社（又は部）の売り上げ等の合計値を親テナントに提供する場合等に便利である。
【００５２】
以上、本発明の実施例について詳述したが、本発明は斯かる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。
【図面の簡単な説明】
【００５３】
【図１】本発明の実施の形態におけるシステム構成例を示す図である。
【図２】業務ＤＢにおけるテーブルの構成例を示す図である。
【図３】本発明の実施の形態におけるＷｅｂサーバのハードウェア構成例を示す図である。
【図４】Ｗｅｂサーバによる処理手順を説明するためのフローチャートである。
【図５】テナントＩＤ管理テーブルの構成例を示す図である。
【図６】テナント間に親子関係が存在する場合のデータベースアクセス部による業務ＤＢへのアクセス処理を説明するための図である。
【図７】親子関係管理テーブルの構成例を示す図である。
【符号の説明】
【００５４】
１０      Ｗｅｂサーバ
１１      ＨＴＴＰサーバ
１２      アプリケーションサーバ
１３      業務アプリケーション
１４      マルチテナント制御部
１５      セッションスコープ
２０      ＤＢサーバ
２１      ＤＢＭＳ
２２      業務ＤＢ
１００    ドライブ装置
１０１    記録媒体
１０２    補助記憶装置
１０３    メモリ装置
１０４    ＣＰＵ
１０５    インタフェース装置
１４１    テナント判定部
１４２    データベースアクセス部
１４３    セッションスコープアクセスＡＰＩ
Ｂ        バス
【図１】
2010026653.tif 000003
【図２】
2010026653.tif 000004
【図３】
2010026653.tif 000005
【図４】
2010026653.tif 000006
【図５】
2010026653.tif 000007
【図６】
2010026653.tif 000008
【図７】
2010026653.tif 000009