(57)【要約】      （修正有）【課題】ビッグデータをリクエストするクエリにおいて、データロード時間を短縮し、参照条件に応じた基礎クエリの多量生成を抑止するシステムを提供する。【解決手段】処理サーバー５０は、クライアントがリクエストするデータキューブのリクエストクエリから、データキューブを参照してビッグデータをリクエストする基礎クエリと、サーバーキャッシュを参照してビッグデータをリクエストする拡張クエリとを生成する。基礎クエリに対する親クエリが存在するか否かを検索し、検索されなければ、基礎クエリの親クエリを生成して登録する。基礎クエリを親クエリと同じ内容で補正し、拡張クエリを親クエリによる親キャッシュを参照するクエリに補正する。親キャッシュのデータをデータキューブから取り込んでロードする際、親キャッシュを構成する単位キャッシュ単位でロードする。補正された拡張クエリを処理する際、親キャッシュの単位キャッシュ単位で参照する。【選択図】図１２
2018037055.tif 000002
【特許請求の範囲】
【請求項１】
クライアントがリクエストするデータキューブのリクエストクエリを処理する分析処理サーバーのキャッシュテーブル統合基盤の２段階クエリ処理システムにおいて、
前記リクエストクエリから前記データキューブを参照してビッグデータをリクエストする基礎クエリと、サーバーキャッシュを参照してビッグデータをリクエストする拡張クエリと、を生成するリクエストクエリ分析部と；
前記基礎クエリに対する親クエリが存在するか否かを検索し、検索されなければ、前記基礎クエリの親クエリを生成して登録する親クエリ検索部と；
前記基礎クエリを前記親クエリと同じ内容で補正し、前記拡張クエリを前記親クエリによる親キャッシュを参照するクエリに補正する拡張クエリ補正部と；
前記親クエリに対応する親キャッシュを構成し、前記親キャッシュのデータを前記データキューブから取り込んでロードするが、前記親キャッシュを構成する単位キャッシュ単位でロードする親キャッシュキャッシング部と；
前記親キャッシュを参照して前記補正された拡張クエリを処理するが、前記親キャッシュの単位キャッシュ単位で参照する拡張クエリ処理部と；を含むことを特徴とするキャッシュテーブルの統合基盤の２段階クエリ処理システム。
【請求項２】
前記リクエストクエリは、複数の値のうちの１つまたは複数の値を選択的に有する参照項目として定義される照会条件を含み、前記親クエリは、前記基礎クエリから前記照会条件を削除したクエリの内容と同じ内容を有するクエリであることを特徴とする請求項１に記載のキャッシュテーブルの統合基盤の２段階クエリ処理システム。
【請求項３】
前記親キャッシュは、前記リクエストクエリのメタデータの照会条件の参照項目の数（Ｎ個）に応じてＮ次元の単位キャッシュに分割されて構成されることを特徴とする請求項２に記載のキャッシュテーブルの統合基盤の２段階クエリ処理システム。
【請求項４】
前記親キャッシュのＮ次元の各次元は、照会条件の参照項目が有し得る値によって分割されることを特徴とする請求項３に記載のキャッシュテーブルの統合基盤の２段階クエリ処理システム。
【請求項５】
前記親キャッシュキャッシング部は、前記補正された拡張クエリでリクエストされる単位キャッシュのうち前記親キャッシュにロードされていないビッグデータだけをデータキューブから取り込んでロードすることを特徴とする請求項３に記載のキャッシュテーブルの統合基盤の２段階クエリ処理システム。
【請求項６】
前記親キャッシュは、Ｎ次元の単位キャッシュで構成され、
前記拡張クエリ補正部は、前記拡張クエリを、前記単位キャッシュを参照する単位拡張クエリをユニオン（Ｕｎｉｏｎ  Ａｌｌ）を使用して結合するクエリに補正することを特徴とする請求項３に記載のキャッシュテーブルの統合基盤の２段階クエリ処理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、テーブル関係と参照項目で構成されたメタデータを用いて、ピボットテーブル方式でクエリ（またはリクエストクエリ）を生成するオンライン分析処理（ＯＬＡＰ：ｏｎ−ｌｉｎｅ  ａｎａｌｙｔｉｃａｌ  ｐｒｏｃｅｓｓｉｎｇ）システムにおいて、前記リクエストクエリを基礎クエリと拡張クエリとに分け、前記基礎クエリによるビッグデータをキャッシュに保存し、前記拡張クエリによってキャッシュから最終的にリクエストクエリのデータを参照する、キャッシュテーブルの統合基盤の２段階クエリ処理システムに関する。
【０００２】
特に、本発明は、ビッグデータをリクエストするクエリ（リクエストクエリ）において、項目値を選択して参照条件を設定する参照項目に対して、各参照条件に応じたビッグデータをそれぞれ子キャッシュとして保存し、子キャッシュを統合して親キャッシュとして設定し、拡張クエリを、前記子キャッシュまたは親キャッシュを参照するクエリとして生成する、キャッシュテーブルの統合基盤の２段階クエリ処理システムに関する。
【背景技術】
【０００３】
一般に、ビジネス・インテリジェンス（ＢＩ：Ｂｕｓｉｎｅｓｓ  Ｉｎｔｅｌｌｉｇｅｎｃｅ）とは、企業の膨大なデータ（またはビッグデータ）を統計分析などの定型的または非定型的な方法を用いて様々に分析したり、分析された情報を理解し易い一目瞭然なレポートの形に加工したりして、ビジネスをより合理的に行えるようにサポートするための一連のツールのことをいう。その代表例として、データの抽出及び変換（ＥＴＴ）ツール、多次元データ分析のためのオンライン分析処理（ＯＬＡＰ）ツール、レポート作成のためのレポーティングツール、データ間の隠れた関連性を見出すためのデータマイニングツールなどが挙げられる。これらの一連のツールを一つのソフトウェアスイート（Ｓｏｆｔｗａｒｅ  ｓｕｉｔｅ）としてまとめたものが一種のビジネスインテリジェンス（ＢＩ）である。
【０００４】
特に、オンライン上で膨大なデータ（またはビッグデータ）を分析する技術が提案されている。たとえば、Ｗｅｂ環境下でデータ基盤を照会して分析するレポーティング技術が提案されている（下記の特許文献１）。また、オンライン上でＥｘｃｅｌのインターフェイスに基づいた分析レポートの作成システムなども提案されている（下記の特許文献２）。
【０００５】
上記のように、ビッグデータを用いて分析するためにオンライン分析処理（ＯＬＡＰ：ｏｎ−ｌｉｎｅ  ａｎａｌｙｔｉｃａｌ  ｐｒｏｃｅｓｓｉｎｇ）システムが導入されて用いられるが、ここで発生する最大の問題の一つは、データ処理速度の遅延である。つまり、多くのデータを処理するために長い時間がかかり、このため、オンライン上でユーザーは体感的に非常に長い時間を待っているような感じがする。
【０００６】
図１に示すように、従来の技術によるオンライン分析処理システムは、ユーザー端末に設けられるクライアント、前記クライアントの要求事項を処理するマトリックスサーバー、及びビッグデータを保存するデータ基盤からなる。
【０００７】
ユーザーは、Ｗｅｂブラウザ上でクライアントを介してレポートの形式（またはテンプレート）を作成し、そのレポートの形式に入力すべきデータをマトリックスサーバーにリクエストする（ステップ１）。すなわち、ユーザ―は、前記クライアントで作成されたレポートから抽出したデータ基盤・コード（ＤＢコード）、クエリ（ＳＱＬクエリ）などの所要の情報をマトリックスサーバーに送信する。次いで、マトリックスサーバーは、データ基盤に接続して所要のデータをリクエストする（ステップ２）。データ基盤は、リクエストされたデータのセット（またはクエリ結果、キューブデータ・セット）などを検索して抽出し、抽出された結果データをマトリックスサーバーに送信する（ステップ３）。マトリックスサーバは、データ基盤から受信したフィールド情報及びデータを圧縮してクライアントに送信する（ステップ４）。
【０００８】
上述した従来のオンライン分析処理システムは、源泉データが千万件を超える瞬間から、前記クエリ結果を受信するために１０分以上かかる場合が頻発する。このようにデータ処理速度が遅い理由は、データ基盤にリクエストする処理速度が急減するためである。商用化されたデータ基盤は、源泉テーブルが巨大である場合、例えば、データが１億個以上となる場合、多くのデータを処理するためにクエリの処理速度が急激に低下する。
【０００９】
特に、ビュー（Ｖｉｅｗ）の機能を使用する場合でも、クエリの処理速度が非常に遅くなる。一般的に、ビューとは、１以上のテーブルからのデータの部分集合を論理的に表現するものであり、実際にデータを有しているわけではなく、結果を一つの構造化問合せ言語（ＳＱＬ：Ｓｔｒｕｃｔｕｒｅｄ  Ｑｕｅｒｙ  Ｌａｎｇｕａｇｅ）として有している。ビュー（Ｖｉｅｗ）はアクセスを制限するために使用し、複雑な問合せを簡単に作成することができるが、リクエストするたびに内部的にＳＱＬを実行する。このため、源泉のビュー（Ｖｉｅｗ）が巨大であるかまたは複雑である場合、接続されたビュー（Ｖｉｅｗ）も遅くなる場合が発生する。
【００１０】
商用化されたデータ基盤は、上記のような問題点を解決するために自体的にクエリをチューニングしてより迅速でクエリを処理するソリューションを有している。しかしながら、このようなチューニングも一般的な状況に備えるためのものなので、自体システムに対するチューニングだけではある程度限界があるため、クエリ速度自体を大幅に向上させることができない。
【００１１】
上述した問題を解決するために、本出願人は、ＳＱＬによるクエリを２段階に分けて、基礎クエリのビッグデータを事前にキャッシュに保存し、拡張クエリに対してはキャッシュに保存されたデータを取り込むことにより、クエリ速度を飛躍的に改善した（下記の特許文献３）。
【００１２】
前記先行技術は、クライアントが問合せをリクエストするときにＳＱＬパーシングにより基礎クエリ（Ｂａｓｅ  Ｑｕｅｒｙ）と拡張クエリ（Ｅｘｔｅｎｄ  Ｑｕｅｒｙ）とに段階を分けて、ビッグデータを保存するデータ基盤から前記基礎クエリによるデータを取り込んでインメモリ基盤のサーバーキャッシュに保存する。また、前記サーバキャッシュのデータから拡張クエリを実行して所要のデータを抽出する。
【００１３】
前記先行技術を実務に適用してみたら、次のような改善点が発見された。
【００１４】
第一、最初からあまりにも大きい基礎クエリを実行する場合は、長いデータロード時間がかかり、データの更新時にさらにそれだけの時間がかかるという問題が発生する。
【００１５】
第二、同じキャッシュデータを用いるが、相異なる基礎クエリで重複データロードが発生し、その分ロード時間及び空間が無駄にされているという問題が発生する。基礎クエリの参照（Ｓｅｌｅｃｔ）文のカラム順序や条件（Ｗｈｅｒｅ）文の条件の包含関係に起因して、同じキャッシュデータであるが相異なる基礎クエリとして認識して処理することになるという問題が発生する。
【００１６】
第三、条件領域（コンボボックス、リストボックスなど）で選択した値を基礎クエリに適用してみると、類似した基礎クエリが多量に生成するという問題が発生する。
【先行技術文献】
【特許文献】
【００１７】
【特許文献１】韓国登録特許第１０−０４９７８１１号（２００５．０６．１８．公告）
【特許文献２】韓国登録特許第１０−０９６９６５６号（２０１０．０７．１４．公告）
【特許文献３】韓国登録特許第１０−１５４４５６０号（２０１５．０８．１７．公告）
【発明の概要】
【発明が解決しようとする課題】
【００１８】
本発明は、上述した問題点を解決するためのもので、その目的は、ビッグデータをリクエストするクエリ（リクエストクエリ）において、項目値を選択して参照条件を設定する参照項目に対して、各参照条件に応じたビッグデータをそれぞれ子キャッシュとして保存し、子キャッシュを統合して親キャッシュとして設定し、拡張クエリを、前記子キャッシュまたは親キャッシュを参照するクエリとして生成する、キャッシュテーブルの統合基盤の２段階クエリ処理システムを提供することである。
【課題を解決するための手段】
【００１９】
上記目的を達成するための本発明は、クライアントがリクエストするデータキューブのリクエストクエリを処理する分析処理サーバーのキャッシュテーブル統合基盤の２段階クエリ処理システムに関するものであり、前記リクエストクエリから前記データキューブを参照してビッグデータをリクエストする基礎クエリと、サーバーキャッシュを参照してビッグデータをリクエストする拡張クエリと、を生成するリクエストクエリ分析部と；前記基礎クエリに対する親クエリが存在するか否かを検索し、検索されなければ、前記基礎クエリの親クエリを生成して登録する親クエリ検索部と；前記基礎クエリを前記親クエリと同じ内容で補正し、前記拡張クエリを前記親クエリによる親キャッシュを参照するクエリに補正する拡張クエリ補正部と；前記親クエリに対応する親キャッシュを構成し、前記親キャッシュのデータを前記データキューブから取り込んでロードするが、前記親キャッシュを構成する単位キャッシュ単位でロードする親キャッシュキャッシング部と；前記親キャッシュを参照して前記補正された拡張クエリを処理するが、前記親キャッシュの単位キャッシュ単位で参照する拡張クエリ処理部と；を含むことを特徴とする。
【００２０】
また、本発明に係るキャッシュテーブルの統合基盤の２段階クエリ処理システムにおいて、前記リクエストクエリは、複数の値のうちの１つまたは複数の値を選択的に有する参照項目として定義される照会条件を含み、前記親クエリは、前記基礎クエリから前記照会条件を削除したクエリの内容と同じ内容を有するクエリであることを特徴とする。
【００２１】
また、本発明に係るキャッシュテーブルの統合基盤の２段階クエリ処理システムにおいて、前記親キャッシュは、前記リクエストクエリのメタデータの照会条件の参照項目の数（Ｎ個）に応じてＮ次元の単位キャッシュに分割されて構成されることを特徴とする。
【００２２】
また、本発明に係るキャッシュテーブルの統合基盤の２段階クエリ処理システムにおいて、前記親キャッシュのＮ次元の各次元は、照会条件の参照項目が有し得る値によって分割されることを特徴とする。
【００２３】
また、本発明に係るキャッシュテーブルの統合基盤の２段階クエリ処理システムにおいて、前記親キャッシュキャッシング部は、前記補正された拡張クエリでリクエストされる単位キャッシュのうち前記親キャッシュにロードされていないビッグデータだけをデータキューブから取り込んでロードすることを特徴とする。
【００２４】
また、本発明に係るキャッシュテーブルの統合基盤の２段階クエリ処理システムにおいて、前記親キャッシュは、Ｎ次元の単位キャッシュで構成され、前記拡張クエリ補正部は、前記拡張クエリを、前記単位キャッシュを参照する単位拡張クエリを集合演算子（Ｕｎｉｏｎ  Ａｌｌ）を使用して結合するクエリに補正することを特徴とする。
【発明の効果】
【００２５】
上述したように、本発明に係るキャッシュテーブルの統合基盤の２段階クエリ処理システムによれば、各参照条件に応じて、ビッグデータを子キャッシとして保存し、これらを統合して親キャッシュとして管理することにより、子キャッシュ単位でデータをロードすることにより、ロード時間を短縮することができ、参照条件に応じて重複しているキャッシュを削除することができ、参照条件に応じた基礎クエリの無差別的生成を防止することができるという効果が得られる。
【図面の簡単な説明】
【００２６】
【図１】従来の技術に係るオンライン分析処理システムを示す構成図である。
【図２】本発明を実施するための全体システムの構成を示すブロック図である。
【図３】本発明の一実施形態に係るＤＢテーブルの関係図を示す例示図である。
【図４】本発明の一実施形態に係るメタデータの参照項目テーブルを示す例示図である。
【図５】本発明の一実施形態に係るクエリデザイン画面を示す例示図である。
【図６】本発明の一実施形態に係るレポート作成画面を示す例示図である。
【図７】本発明の一実施形態に係る親キャッシュ構成の一例を示す図である。
【図８】本発明の一実施形態に係る親クエリの一例を示す図である。
【図９】本発明の一実施形態に係る単位クエリの一例を示す図である。
【図１０】本発明の一実施形態に係る子クエリの一例を示す図である。
【図１１】本発明の一実施形態に係る子クエリによって参照される親キャッシュの一例を示す図である。
【図１２】本発明の一実施形態に係るキャッシュテーブルの統合基盤の２段階クエリ処理システムの構成を示すブロック図である。
【図１３】本発明の一実施形態に係る基礎クエリと拡張クエリの一例を示す図である。
【図１４】本発明の一実施形態に係るマージテーブルの一例を示す図である。
【図１５】本発明の一実施形態により修正された基礎クエリと拡張クエリの一例を示す図である。
【図１６】本発明の一実施形態により単位拡張クエリで構成された、補正された拡張クエリの一例を示す図である。
【発明を実施するための形態】
【００２７】
以下、添付図面に基づいて、本発明の実施するための具体的な内容について説明する。
【００２８】
また、本発明を説明するに当たって、同じ構成要素には同じ符号を付し、その重複説明は省略する。
【００２９】
まず、本発明を実施するための全体システムを、図２を参照して説明する。
【００３０】
図２に示すように、本発明を実施するための全体システムは、クライアント２０、クエリ処理サーバー５０、マトリックスサーバ５０、及びデータキューブ９０からなる。特に、クエリ処理サーバー５０は、データキューブ９０から受信したデータの一部を保存するためのサーバーキャッシュ７０を備える。
【００３１】
好ましくは、データキューブ６０は、複数のＤＢテーブルで構成され、各ＤＢテーブルは、複数のレコードで構成され、各レコードが一つの情報または一連のデータを示す。つまり、各レコードは、複数のフィールドで構成され、各フィールドにフィールド値が保存される。一方、一つのＤＢテーブルに属するすべてのレコードは、同じフィールドを有する。つまり、１つのＤＢテーブルは、複数のフィールドを有し、ＤＢテーブルに記録されるレコードは、ＤＢテーブルのフィールドにフィールド値を保存する。
【００３２】
また、データキューブ６０は、データ（またはビッグデータ）を管理するためのデータ基盤管理システム（ＤＢＭＳ：ｄａｔａｂａｓｅ  ｍａｎａｇｅｍｅｎｔ  ｓｙｓｔｅｍ）を備え、データの保存、削除、検索などの作業をクエリを使用して行う。特に、データキューブ６０は、商用化されたデータ基盤であり、データを処理するための一般的なクエリ機能を利用してデータクエリサービスを行う。つまり、クエリは、ＤＢのテーブルと、当該ＤＢテーブルに対する参照項目（フィールドなど）とによって定義されるかまたは設定される。
【００３３】
クライアント２０は、ユーザー端末１０に設けられるクライアント用のプログラムシステムであり、Ｗｅｂブラウザを介してユーザー・インターフェイスを有する。つまり、ユーザーは、Ｗｅｂブラウザ又はＷｅｂブラウザのような画面のインタフェースを介して、オンライン上でデータの分析処理を行う。このとき、クライアント１０は、ユーザーのコマンドなどを入力され、当該コマンドを実行し、処理結果を画面上にまたはＷｅｂブラウザ上に表示する。一方、ユーザー端末１０は、パーソナルコンピュータ（ＰＣ：Ｐｅｒｓｏｎａｌ  Ｃｏｍｐｕｔｅｒ）、携帯情報端末（ＰＤＡ：Ｐｅｒｓｏｎａｌ  Ｄｉｇｉｔａｌ  Ａｓｓｉｓｔａｎｔ）、スマートフォンなどのコンピューティング機能を持つコンピュータ端末である。
【００３４】
また、クライアント２０は、データリクエスト、データ分析などのオンライン上で分析処理する作業をＯＬＡＰサーバー３０にリクエストし、その結果をＯＬＡＰサーバー３０から取り込んでＷｅｂブラウザ上に表示する。
【００３５】
ユーザ端末１０とＯＬＡＰサーバー３０はネットワークで接続されるので、ユーザー端末１０上のクライアント２０は、オンライン上で分析レポートの作成を行うことができる。
【００３６】
次に、ＯＬＡＰサーバー３０は、オンライン分析処理（ＯＬＡＰ）を行うサーバーであり、クライアント２０からメタデータ検索、ビッグデータクエリなどのリクエストを受信し、当該検索またはクエリのリクエストを処理してその結果をクライアント２０に送信するサーバーである。
【００３７】
特に、ＯＬＡＰサーバー３０は、ビッグデータをリクエストするクエリ（またはリクエストクエリ）を用いて、クエリ処理サーバー５０を介してデータキューブ９０に保存されたデータを取り込む。クエリとは、データギュブ６０に保存されたビッグデータの検索又は更新時に発生する問合せを記述するデータ操作言語のことを意味する。データ基盤においてクエリは、一種の命令語のような役割を果たす。関係データ基盤の構造化問合せ言語（Ｓｔｒｕｃｔｕｒｅｄ  Ｑｕｅｒｙ  Ｌａｎｇｕａｇｅ：以下、ＳＱＬ）の形式で表現されるが、場合によっては、ＳＱＬ以外の他の形式でも表現することもできる。
【００３８】
また、ＯＬＡＰサーバー３０は、メタデータを保存し、保存されたメタデータを取り込んで当該メタデータでクエリ作成（リクエストクエリの作成）環境を設定する。つまり、参照するＤＢテーブル、これらの間の関係、及び参照する項目などを設定する。好ましくは、これらクエリ作成環境をグラフィカル・ユーザー・インターフェース（ＧＵＩ：Ｇｒａｐｈｉｃａｌ  Ｕｓｅｒ  Ｉｎｔｅｒｆａｃｅ）の形で表示する。ユーザーは、ＯＬＡＰサーバー３０で設定されたクエリ作成環境下で簡単な操作（ドラッグ＆ドロップ）などで所望のデータを処理するクエリ（またはリクエストクエリ）を作成することができる。
具体的には、メタデータとは、クエリを作成するのために参照すべきＤＢテーブル及び、その参照項目、条件（照会条件）などを定義したデータのことをいう。特に、ＤＢテーブルが少なくとも２つの場合には、ＤＢのテーブル間の関係も定義される。すなわち、メタデータは、クエリの作成に用いられるＤＢテーブル、テーブル間の関係、参照項目（参照フィールド）、条件（照会条件）などを記録したデータである。
【００３９】
ユーザーは、データキューブ９０から所要のデータを抽出するために、メタデータを用いて簡単にクエリを作成することができる。つまり、メタデータにおいてＤＢテーブル、テーブル間の関係、参照項目が定義されているので、ユーザーは所望の出力形態で参照項目を定義するか、一部の条件を簡単に修正して所望のクエリを作成することができる。
【００４０】
また、ＯＬＡＰサーバー３０は、リクエストクエリによって取り込んだビッグデータを用いてレポートを作成することができる作成環境をサポートする。
【００４１】
次に、クエリ処理サーバー５０は、サーバーキャッシュ７０を備え、データキューブ９０から取り込んだデータの全部または一部を臨時に保存する。サーバーキャッシュ７０は、クエリ処理サーバー５０のメモリ（ＲＡＭ等）上に実現されてキャッシュメモリとして構成されるか、ハードディスクまたはソリッド・ステート・ディスク（ＳＳＤ：ｓｏｌｉｄ  ｓｔａｔｅ  ｄｉｓｋ）などに実現されてキャッシュディスクとして構成される。または、すべてのデータをディスクに保存し、一部のデータ、すなわち、所要のデータをキャッシュメモリにアップロードして使用することができる。
【００４２】
クエリ処理サーバー５０は、ＯＬＡＰサーバー３０からのリクエストクエリを受信し、リクエストクエリによって参照されるビッグデータをデータキューブ９０またはサーバーキャッシュ７０から取り込み、リクエストされたビッグデータを返信する。このとき、リクエストされたビッグデータ（リクエストクエリによってリクエストされたビッグデータ）をサーバーキャッシュ７０に保存し、サーバーキャッシュ７０上の当該ビッグデータの位置（参照位置）を返すこともできる。
【００４３】
また、クエリ処理サーバー５０は、リクエストクエリから基礎クエリと拡張クエリを生成し、基礎クエリにより、ビッグデータをデータキューブ９０から取り込んでサーバーキャッシュ７０に保存し、拡張クエリにより、サーバーキャッシュ７０に保存されたビッグデータから所要のビッグデータ（リクエストクエリによってリクエストされたビッグデータ）をクエリして取り込む。このとき、基礎クエリによるビッグデータがサーバーキャッシュ７０に既に保存されている場合には、データキューブ９０へのアクセスが不要であるので、リクエストクエリを非常に迅速に処理することができる。
【００４４】
また、好ましくは、クエリ処理サーバー５０は、サーバーで使用するデータを保存するためのデータ基盤６０を備える。データ基盤６０は、親クエリに関する情報を保存する親クエリＤＢ６１と、親クエリに対するキャッシュの構成及びその情報を保存するマージテーブルＤＢ６２と、からなる。しかしながら、前記データ基盤６０の構成は、好適な一実施形態に過ぎないものであり、具体的な装置を開発するにあたり、アクセス及び検索の容易性及び効率性などを勘案して、データ基盤の構築理論によって他の構造で構成することができる。
【００４５】
好ましくは、クエリ処理サーバー５０とデータキューブ９０との間にマトリックスサーバー（不図示）を構成することができる。マトリックスサーバー（不図示）は、データキューブ９０を中継するインターフェースサーバーの役割を果たす。つまり、マトリックスサーバー（不図示）は、分析処理サーバ５０からのクエリを受信し、当該クエリを使用してデータキューブ９０のデータを取り込む。または、データキューブ９０のＤＢＭＳにリクエストして当該データを取り込む。
【００４６】
また、マトリックスサーバー（不図示）は、異質な複数のデータキューブ９０で構成されても、当該データ基盤とのインターフェース方式に合わせて、クエリをリクエストしたりデータを受信したりする。さらに、マトリックスサーバー（不図示）は、データを送受信する際に暗号化したり、データの圧縮、またはファイル圧縮などのデータの送受信のための付加的な作業をも行う。
【００４７】
次いで、本発明の一実施形態に係るＯＬＡＰサーバー３０により、メタデータを用いてリクエストクエリを作成する方法について、図３乃至図５を参照して説明する。
【００４８】
ＯＬＡＰサーバー３０は、データキューブ６０のビッグデータを参照するために作成されたテーブルの関係図及び参照項目をメタデータとして構成して保存する。メタデータは、テーブルの関係図、参照項目、及び条件（照会条件）で構成される。
【００４９】
テーブル関係図は、ＤＢテーブル及びジョイン（ｊｏｉｎ）（またはリンク）の関係で構成される。テーブル関係図は、通常のＥＲ図（ＥＲＤ：Ｅｎｔｉｔｙ−Ｒｅｌａｔｉｏｎｓｈｉｐ  Ｄｉａｇｒａｍ：実体関連図）と類似している。ただし、特定の目的のデータ（データキューブのデータ）を参照するために、ＤＢテーブルのジョイン関係を事前に定義して自動的にＳＱＬを生成することができるジョイン関係を設定しておく。
【００５０】
ＤＢテーブルは、データキューブ６０に構成されるテーブルをいう。ＤＢテーブルは、通常のデータ基盤テーブルであり、複数のカラム（またはフィールド）で構成され、ＤＢテーブルの各データは、各フィールドの値を有する。
【００５１】
ジョイン関係は、少なくとも２つのＤＢテーブル間のジョイン（ｊｏｉｎ）をするための条件であり、ＤＢテーブルのフィールド間の条件として表示される。ジョイン関係は、通常のデータ基盤におけるジョイン関係であり、具体的な説明は省略する。
【００５２】
図３は、テーブル関係図を例示する。図３に示すように、テーブル関係図は４つのＤＢテーブルで構成される。つまり、＜従業員（Ｅｍｐｌｏｙｅｅ）＞、＜給与（Ｓａｌａｒｙ）＞、＜アドレス（Ａｄｄｒｅｓｓ）＞、及び＜職位（Ｗｏｒｋ  ｐｏｓｉｔｉｏｎ）＞の４つのＤＢテーブルで構成されている。また、ジョイン関係は、＜従業員−給与＞、＜従業員−アドレス＞、＜従業員−職位＞の間にそれぞれの関係を有する。＜従業員−給与＞の関係では、社員番号フィールドが同一であることを条件とし、＜従業員−アドレス＞の関係では、アドレスコードフィールドが同一であることを条件とし、＜従業員−職位＞の関係では、職位コードフィールドが同一であることを条件とする。
【００５３】
参照項目は、データキューブ６０のデータを参照するための項目であり、ＤＢテーブルのフィールド項目と、前記フィールド項目を加工して取得する派生項目と、で構成される。つまり、参照項目は、ユーザーが参照項目として選択したテーブルのカラム名（フィールド名）、またはユーザーがカラム名（フィールド名）などを用いて定義された参照項目（派生項目）で構成される。
【００５４】
一方、データキューブのデータを参照するためのクエリにおいて参照されたカラム（フィールド）だけを参照項目として選ばれる。つまり、ＤＢテーブルのすべてのカラム（フィールド）が参照項目として選ばれない。図３の例では、参照項目は、ＤＢテーブルにおいてチェック表示されたフィールド、すなわち、＜職位名＞、＜氏名＞、＜住民番号１＞、＜年月＞、＜郵便番号＞、＜アドレス＿都道府県＞、＜アドレス＿市区町村＞、＜基本給＞、＜手当＞などだけが選ばれる。＜従業員（Ｅｍｐｌｏｙｅｅ）＞テーブルの＜住民番号２＞、＜入社日＞、＜部署コード＞などは参照項目として選ばれない。
【００５５】
派生項目は、ＤＢテーブルのカラム（またはフィールド）に対する演算によりテーブル内にない項目を派生的に作り出したものをいう。参照項目の例として、＜期間＞テーブル内に＜年月＞というカラムが存在する場合、次のように、＜年度＞、＜月＞などを派生項目として作り出すことができる。
＜年度＞：ｓｕｂｓｔｒ（＜年月＞、１、４）
＜月＞：ｓｕｂｓｔｒ（＜年月＞、５、２）
【００５６】
また、計算式を利用した参照項目が生成されることができる。たとえば、ＤＢテーブルに＜生産量＞、＜処理量＞カラムが存在する場合、＜実収率＞カラムを、計算式を使用して派生項目として生成することができる。
＜実收率＞：＜生産量＞／＜処理量＞×１００
【００５７】
一方、参照項目は、次元（ｄｉｍｅｎｓｉｏｎ）形式と測定値（ｍｅａｓｕｒｅ）形式とに分けられる。好ましくは、参照項目（またはカラム）の値が文字である場合、次元の形式で指定し、参照項目の値が数値である場合、測定値の形式で指定する。データキューブ９０においてテーブルの各カラムは、次元（Ｄｉｍｅｎｓｉｏｎ）と測定値（Ｍｅａｓｕｒｅ）の形式とに事前に分類して設定することができる。特に、次元は構造化されたラベル情報を提供する。上記のように、データキューブ９０においてＤＢテーブルのフィールド（またはカラス）に対して事前に次元の形式または測定値の形式で設定されていれば、当該設定に応じて参照項目の種類が設定される。
【００５８】
一方、測定値は、ソートされていない数値、数値演算が可能な値を意味する。すべての場合に、文字列値が次元になり、数値が測定値になるわけではない。たとえば、製品番号という項目が数値や次元形式に分類される（すなわち、製品番号を数値演算することができない）。また、文字列の項目をカウント（ｃｏｕｎｔ）する場合（例えば、登録ユーザー数は、ユーザー名をカウントする。）、測定値の形式に分類されるべきである。自動的に分類する基準が文字列または数値であり、ユーザーまたは管理者によって、当該参照項目の種類が補正されることができる。
【００５９】
図３の例を参照すると、カラム名＜職位名＞、＜氏名＞、＜住民番号１＞、＜年月＞、＜郵便番号＞、＜アドレス＿都道府県＞、＜アドレス＿市区町村＞は、次元形式の項目であり、カラム名＜基本給＞、＜手当＞は、測定値形式の項目である。
【００６０】
好ましくは、メタデータの参照項目は、テーブルで構成されて保存できる。具体的には、図４に示すように、メタデータの参照項目は、メタデータの名前であるメタデータ名、参照項目の名前である参照項目名、ＤＢテーブルの名前であるテーブル名、テーブル内の参照フィールドであるカラム名、次元／測定値の形式を示す形式、計算式を用いる派生項目である場合に当該計算式を示す数式などで構成される。
【００６１】
さらに好ましくは、数式は、派生項目の数式（Ｆｏｒｍｕｌａ）属性として保存する。保存された数式は、後ほどメタデータを再利用して自動的にクエリ文（ＳＱＬ）を生成する際にそのまま用いられる。一方、数式は、ＳＱＬ文法のままの数式を用いることもでき、標準化された数式として管理し、データキューブ（またはデータ基盤）の種類に対応するクエリ文（ＳＱＬ）に自動的に変更することもできる。ＤＢ種類別に提供される関数（ｆｕｎｃｔｉｏｎ）の文法が異なる場合があるからである。例えば、サブストリング（ｓｕｂｓｔｒｉｎｇ）関数は、オラクル（商標ＯＲＡＣＬＥ）ではＳＵＢＳＴＲで、ＭＳ−ＳＱＬではＭＩＤであって、互いに異なる可能性がある。
【００６２】
その次、照会条件は、参照項目の条件を示す。照会条件は、当該参照項目が特定値を満足するデータのみを抽出するための条件である。好ましくは、照会条件は、複数の値（項目値）のうち１つまたは複数の値を選択して条件を設定することができる。この場合、当該参照項目の値が選択された値に属する場合のデータのみが抽出される。
【００６３】
さらに、ＯＬＡＰサーバー３０は、ユーザーによって選択されたメタデータの参照項目のみでクエリを構成できるインターフェース画面（以下、クエリデザイン画面）を表示する。特に、クエリデザイン画面は、ドラッグ・アンド・ドロップ（ｄｒａｇ＆ｄｒｏｐ）方式によるインターフェースを有する。
【００６４】
図５に示すように、クエリデザイン画面は、メタデータの参照項目を表示する領域（以下、項目表示領域）と、選択された参照項目を表示する領域（以下、選択表示領域）と、で構成される。選択された参照項目の領域（または選択表示領域）は、次元形式（次元領域）と測定値形式（またはデータ領域）に区分して表示される。好ましくは、選択された参照項目の領域には、フィルタリングにより選択される参照項目を表示するためのフィルタ領域が含まれて構成されることができる。
【００６５】
クエリデザイン画面において、ドラッグ・アンド・ドロップ方式により項目表示領域に表示される参照項目が選択され、選択表示領域に選択された参照項目が表示される。
【００６６】
ＯＬＡＰサーバー３０は、クエリデザイン画面における選択表示領域において参照項目が選択されると、自動的にクエリ文（リクエストクエリ）を生成する。加えて、ＯＬＡＰサーバー３０は、生成されたリクエストクエリをクエリ処理サーバー５０を用いて処理し、その結果として、リクエストされたデータを取り込む。
【００６７】
ユーザーが＜ＹＹＹＹ＞、＜ＦＡＣＴＯＲＹ＞、＜ＰＲＯＤＵＣＴ＞を選択した場合について説明する。当該キーワードを参照項目として有しているテーブル関係のメタデータをもって、自動的にクエリ文（ＳＱＬ）またはリクエストクエリが生成される。この時、参照項目の属性としてメタデータに定義された次元、測定値、グループ関数に基づいてグループ化され、データ件数を次元の固有値に最小化して、データキューブにデータを照会してレポートを作成する。ＳＱＬ文に必要なジョイン（ｊｏｉｎ）の構文は、テーブル関係のメタデータに数百のテーブルが定義されていても、選択した参照項目を有するテーブルのみが関係されたメタデータの関係図において最小全域木（Ｍｉｎｉｍｕｍ  ｓｐａｎｎｉｎｇ  ｔｒｅｅ）アルゴリズムでテーブル間の最小のジョイン（ｊｏｉｎ）により構成され、これによりＳＱＬが生成される。
【００６８】
すなわち、図５の画面に示すように、クエリ作成に経験の浅いユーザーに利便性を提供するために、参照項目の配置に応じて自動的にクエリが生成できるようにする。この時、照会条件領域には、前記メタデータの照会条件が表示されて、照会条件を設定することができる。
【００６９】
照会条件の領域に配置した参照項目と演算子の種類に応じて、クエリデザイン画面で条件領域が自動的に生成される。演算子が「ＩＮ」である場合には、多重選択リストボックスが自動生成され、「＝」である場合には、コンボボックスが自動的に生成される。つまり、これらの照会条件は、複数の値のうちから１つまたは複数の値を選択することにより、その条件の内容が設定される。
【００７０】
一方、クエリデザイン画面における照会条件は、リクエストクエリで条件文（ｗｈｅｒｅ節など）として定義されて挿入される。
【００７１】
さらに、ＯＬＡＰサーバー３０は、リクエストクエリを自動的に生成して、それをクエリ処理サーバー５０にリクエストし、その結果を取り込む。また、ＯＬＡＰサーバー３０は、レポートの結果として、画面上にその結果を表示する。レポートの画面の例が図６に示されている。
【００７２】
図６に示すように、ＯＬＡＰレポートは、メタデータを用いてレポートリクエストクエリを自動生成し、その結果を実行して作成する。ＯＬＡＰレポートの形態は、実行領域、条件領域、及び実行結果領域に大別される。
【００７３】
次に、本発明の一実施形態に係るサーバのキャッシュ９０で構成される親キャッシュについて図７を参照して説明する。
【００７４】
図７に示すように、本発明に係る親キャッシュは、メタデータの照会条件に応じてＮ次元の単位キャッシュに分割される。この時、各次元は照会条件の参照項目に該当する。つまり、照会条件の参照項目がＮ個であれば、親キャッシュはＮ次元に分割される。しかしながら、好ましくは、Ｎは１または２である。
【００７５】
図７の例において、参照項目はＹＹＹＹ、ＦＡＣＴＯＲＹなどの２つである。したがって、参照項目ＹＹＹＹは、Ｙ軸において１つの次元に分割され、ＦＡＣＴＯＲＹは、Ｘ軸において他の１つの次元に分割される。つまり、全体的に、親キャッシュは２次元に分割される。
【００７６】
また、参照項目による各次元は、当該参照項目が有し得る値により分割される。ＹＹＹＹの参照項目である場合、ＹＹＹＹが有し得る値である「２０１５」、「２０１６」に分割される。また、ＦＡＣＴＯＲＹの参照項目のＸ軸において、ＦＡＣＴＯＲＹが有し得る値である「ＦＣＴＲＹ０１」、「ＦＣＴＲＹ０２」、「ＦＣＴＲＹ０３」に分割される。
【００７７】
したがって、図７における親キャッシュは、２次元の３×２のアレイに分割される。この時、各アレイのセルに対応するキャッシュは単位キャッシュと呼ばれる。図７の例では、単位キャッシュは（２０１５、ＦＣＴＲＹ０１）、（２０１５、ＦＣＴＲＹ０２）、（２０１５、ＦＣＴＲＹ０３）、（２０１６、ＦＣＴＲＹ０１）、（２０１６、ＦＣＴＲＹ０２）、（２０１６、ＦＣＴＲＹ０３）である。
【００７８】
元の親キャッシュは、単一の親クエリに対応するキャッシュであり、親クエリによって参照されるビッグデータをキャッシュするデータである。つまり、親クエリをデータキューブ９０にクエリして、データキューブ９０から取り込み、サーバーキャッシュ７０にキャッシュする必要がある。
【００７９】
しかし、親キャッシュは、データ量が非常に膨大であるため、サーバーキャッシュ７０にロードするに多くの時間がかかる。故に、親キャッシュは、データをロードする際に、分割された単位キャッシュ単位でデータをサーバーキャッシュ７０にロードする。例えば、図７の例では、（２０１５、ＦＣＴＲＹ０１）、（２０１６、ＦＣＴＲＹ０１）の単位キャッシュだけを先にキャッシュすることができる。さらに、残りの４つの単位キャッシュはまだロードしていないので空になっている可能性がある。なお、後ほど必要な場合には、残りの単位キャッシュをサーバーキャッシュ７０にロードすることができる。
【００８０】
したがって、親キャッシュを用いることにより、データロード時間を短縮することができる。また、親キャッシュを単位キャッシュに分割することにより、膨大な親キャッシュを直接ロードするときに発生する問題を解決することができる。つまり、キャッシュを巨大な一つのテーブルとして持っていると、次のような問題点が引き起こされる。たとえば、データロード時間が比較的長くかかり、データ更新時にテーブルに反映して再構成するために、時間がかかる。また、収集データの量が増加するとロード時にエラーが発生する可能性が高くなる。よって、条件領域のために生成されるキャッシュを単位キャッシュに分割し、一つの親キャッシュに統合して作る。親キャッシュは、物理的に構成されているのではなく論理的に構成されているので、上記のような問題を解決することができる。
【００８１】
次に、本発明の一実施形態に係る親キャッシュに対する親クエリと単位クエリ、その子クエリについて図８乃至図１１を参照して説明する。
【００８２】
サーバーキャッシュ９０に保存されるキャッシュデータは、それぞれの基礎クエリに対応する。つまり、基礎クエリによってデータキューブ９０にリクエストし、その結果としてデータキューブ９０から取り込んだビッグデータを一つのキャッシュデータとしてサーバーキャッシュ９０に保存する。
【００８３】
したがって、親キャッシュも一つの親クエリに対応するキャッシュデータである。ただし、親キャッシュは、親クエリによってキャッシュデータをすべて取り込まずに、親キャッシュを構成する単位キャッシュ単位で取り込む。このとき、単位キャッシュを取り込むクエリは単位クエリと呼ばれる。
【００８４】
図８は、図７の親キャッシュを示す親クエリを示し、図９は、単位キャッシュを取り込む単位クエリを示す。
【００８５】
図８に示すように、親クエリには、照会条件を示す条件構造（ｗｈｅｒｅ節）に照会条件が示されていない。これに対し、図９に示すように、単位クエリには、照会条件がすべて示されている。特に、親キャッシュの各次元の参照項目が、それぞれ一つの値を満足する条件で設定される。図９の単位クエリでは、参照項目ＹＹＹＹは「２０１５」を満足する条件で、参照項目ＦＡＣＴＯＲＹは「ＦＣＴＲＹ０２」を満足する条件で、照会条件を持つ。
【００８６】
一方、図１０に示すように、親キャッシュ内の単位キャッシュを参照するクエリは、子クエリーと呼ばれる。つまり、子クエリは、親クエリの参照テーブルと参照項目を有するが、次元を形成する参照項目の照会条件を有するクエリである。特に、次元の参照項目照会条件は、参照項目が複数の値のうち１つまたは複数の値を選択的に有する条件である。
図１０（ａ）に示すように、子クエリの照会条件では、参照項目の条件が、すべての次元の参照項目に対するすべての条件を含むことができる。また、図１０（ｂ）に示すように、参照項目の条件が、すべての次元のうち一部次元の参照項目に対する条件のみを含むこともできる。
【００８７】
図１０の子クエリによって参照されるキャッシュは、図１１のとおりである。図１１において、赤色ボックス内の単位キャッシュが、図１０の子クエリを参照するキャッシュデータである。つまり、子クエリは、親キャッシュを構成する単位キャッシュを参照するクエリである。
【００８８】
また、上述した単位クエリも一つの子クエリに対応する。図１１の緑色ボックスの単位キャッシュは、図９の単位クエリまたは子クエリにおいて参照するキャッシュである。
【００８９】
次に、本発明の一実施形態に係るキャッシュテーブルの統合基盤の２段階のクエリ処理システムの構成を、図１２を参照してより具体的に説明する。
【００９０】
図１２に示すように、本発明の一実施形態に係るキャッシュテーブルの統合基盤の２段階クエリ処理システムは、リクエストクエリから基礎クエリと拡張クエリを生成するリクエストクエリ分離部５１と、基礎クエリに対する親クエリが存在するか否かを検索したり、親クエリを生成する親クエリ検索部５２と、拡張クエリを修正する拡張クエリ補正部５３と、基礎クエリまたは子クエリで必要とされる単位キャッシュをキャッシュする親キャッシュキャッシング部５４と、補正された拡張クエリを処理する拡張クエリ処理部５５と、で構成される。
【００９１】
先ず、リクエストクエリ分離部５１は、リクエストクエリから基礎クエリと拡張クエリを生成する。
【００９２】
図１０（ａ）のクエリをリクエストクエリの一例として説明する。リクエストクエリは、参照項目をを示す参照項目節（ＳＥＬＥＣＴ節）、ビッグデータを取り込むテーブル（またはジョイン）を定義する参照テーブル節（ＦＲＯＭ節）、所望のビッグデータの条件を定義する条件節（ＷＨＥＲＥ節）、集計や表示形態を定義するグループ節（ＧＲＯＵＰ  ＢＹ）または順序節（ＯＲＤＥＲ  ＢＹ）などで構成される。リクエストクエリにおいて定義された参照項目（データフィールドなど）、参照テーブル、条件文における変数（参照項目）などのすべては、データキューブ９０における源泉データのフィールド、テーブルなどを参照したものである。
【００９３】
基礎クエリは、データキューブ９０のビッグデータを参照してリクエストするクエリであり、拡張クエリは、基礎クエリによって抽出されたデータ（またはキャッシュデータ）を参照してリクエストするクエリである。図１０（ａ）のリクエストクエリから抽出した基礎クエリと拡張クエリの一例が図１３に示されている。
【００９４】
図１３に示すように、基礎クエリ（ＢａｓｅＳＱＬ）において、ＳＥＬＥＣＴ文に記載された「ＹＹＹＹ」、「ＰＲＯＤＵＣＴ」などのデータフィールドの名称や、「ＭＡＴＲＩＸ．ＭＡＴＲＩＸ＿ＤＥＭＯ＿ＳＳ」などを参照テーブルの名称や、「ＹＹＹＹ」などの条件文の変数（参照項目）は、全てデータキューブ９０の源泉データを直接参照する。
【００９５】
リクエストクエリから基礎クエリと拡張クエリを分離する方法は、クエリパーシング（ＡＮＴＬＲ４）を介して処理される。つまり、パーシングツリー及びパーシング結果を用いて参照項目節、参照テーブル節、条件節などを基礎クエリとして作る。条件節に備えた参照項目も基礎クエリに含める（特許文献３）。
【００９６】
拡張クエリ（ＥｘｔｅｎｄＳＱＬ）において、ＳＥＬＥＣＴ文に記載されたＭＨＣ．「Ｒ０１」、ＭＨＣ．「Ｒ０２」などはデータフィールドの別称であり、「｛＠ＯＲＩＧＩＮＡＬ＿ＳＱＬ＠｝」などの参照のテーブルは、すべて基礎クエリ（ＢａｓｅＳＱＬ）によって抽出して得られる結果データを直接参照する。
【００９７】
したがって、基礎クエリによって抽出されたデータが取得されると、拡張クエリは、取得された基礎クエリの結果データを参照してリクエストされるクエリである。拡張クエリによって得られる結果は、元のリクエストクエリによって得られる結果と同一である。
【００９８】
また、拡張クエリーによって得られる結果データの集合は、常に基礎クエリによって得られる結果データの集合と同じか小さい。つまり、拡張クエリのデータの集合は、基礎クエリのデータの集合の部分集合であると言える。
【００９９】
その次、親クエリ検索部５２は、基礎クエリに対する親クエリが存在するか否かを検索したり、親クエリがない場合、親クエリを生成する。
【０１００】
親クエリは、親クエリテーブル（または親クエリＤＢ）に登録される。親クエリテーブルを参照して、基礎クエリの親クエリが存在するか否かを検索する。
【０１０１】
一実施形態として、親クエリを確認するために、基礎クエリをパーシングして参照項目の集合（ＳＥＬＥＣＴＳＥＴ、Ｓｅｌｅｔ文の参照項目の集合）、テーブル節のハッシュコード（ＦＲＯＭＣＯＤＥ、Ｆｒｏｍ文のハッシュコード値）、集計条件節のハッシュコード（ＨＡＶＩＮＧＣＯＤＥ、Ｈａｖｉｎｇ文のハッシュコード値）などの三つの値を得、これらを親クエリと対比して検索する。また、追加的に、条件節を対比するが、照会条件を除いて、残りの条件の内容が同じか否かを対比することができる。２以上のＤＢテーブルを参照してクエリを行う場合には、２つのテーブルをジョイン（ｊｏｉｎ）するための条件も条件節（ｗｈｅｒｅ節））に含むことができる。したがって、このような条件（ジョイン条件）は同じでなければならない。
【０１０２】
他の実施形態として、基礎クエリにおいて照会条件に該当する参照項目、すなわち、複数の値のうちの１つまたは一部の値を選択的に有する参照項目を見出し、当該参照項目の条件を除いて基礎クエリから親クエリを抽出する。さらに、抽出された親クエリが親クエリテーブルに存在するか否かを検索する。すなわち、２つのクエリが同じ内容であるか否かを判断して検索する。
【０１０３】
一方、親クエリ検索部５２は、基礎クエリの親クエリが存在しない場合、当該基礎クエリから親クエリを抽出し、抽出された親クエリを親クエリテーブルに登録することができる。
【０１０４】
このとき、親クエリ検索部５２は、基礎クエリ（またはリクエストクエリ）のメタデータの照会条件に用いられた参照項目を検索し、当該参照項目に対する照会条件を基礎クエリから除外して親クエリを生成する。
【０１０５】
親クエリ検索部５２は、生成された親クエリを親クエリテーブルに登録し、親クエリに対応する親キャッシュを生成して、親キャッシュに対するマージテーブルを生成して登録する。このとき、当該照会条件の参照項目の個数（Ｎ個）に応じて親キャッシュをＮ次元に設定し、これらの情報をマージテーブルに登録する。
【０１０６】
また、図１４に示すように、マージテーブルルには、各単位キャッシュが親キャッシュにロードされたか否かを記録する。マージテーブルルは、図１４に示すように、テーブルの形や、Ｎ次元のアレイ（ａｒｒａｙ）の形に構成することができる。
【０１０７】
前記２つのクエリの内容が同じであるという意味は、参照項目節の参照項目の集合が同じであり、参照テーブル節が参照するテーブルが同じであり、条件節やグループ節などの各式、または条件式の集合が同一である場合をいう（特許文献３）。
【０１０８】
次に、拡張クエリ補正部５３は、基礎クエリを親クエリとして設定し、親クエリに合うように拡張クエリを修正する。
【０１０９】
拡張クエリ補正部５３は、基礎クエリから照会条件を削除して、前記基礎クエリを親クエリに合うように設定する。また、基礎クエリから削除された照会条件を拡張クエリに挿入することにより、拡張クエリを親クエリに合うように修正する。
【０１１０】
例えば、図１３（ａ）の基礎クエリから条件節（ｗｈｅｒｅ節）に記載された照会条件を削除して、図１５（ａ）のように修正された基礎クエリ（または親クエリ）が生成される。また、図１３（ｂ）の拡張クエリに照会条件を挿入して、図１５（ｂ）のように修正された拡張クエリが生成される。
【０１１１】
また、追加的に、拡張クエリ補正部５３は、拡張クエリを各単位キャッシュを参照できるように修正する。つまり、すべての参照項目に対する条件をそれぞれ設定し、各参照項目の条件が一つの値だけを持つように単位拡張クエリを作成し、これらをユニオン演算（Ｕｎｉｏｎ  Ａｌｌ）を使用して再度組み合わせる。つまり、条件フィールドのＩＮ演算子は、Ｕｎｉｏｎ  Ａｌｌを使用してクエリを再度組み合わせて実行する。図１５（ｂ）の拡張クエリを再度組み合わせた一例が図１６に示されている。一方、図１６の拡張クエリは、図１１の親キャッシュから赤色ボックス部分を参照する拡張クエリであり、個々の単位キャッシュを参照するクエリをユニオン（ｕｎｉｏｎ  Ａｌｌ）を使用して結合したクエリである。
【０１１２】
次いで、親キャッシュキャッシング部５４は、補正された拡張クエリにおいて所要の単位キャッシュをデータキューブ９０から取り込んで親キャッシュにロードする。つまり、複数の単位クエリ（単位拡張クエリ）で構成された拡張クエリに対して、各単位クエリに対応する単位キャッシュが親キャッシュに存在するか否かを確認し、親キャッシュに単位キャッシュが存在しない場合は、当該単位キャッシュデータをキューブ９０から取り込む。また、単位キャッシュが既に親キャッシュに存在する場合は、当該単位クエリによるビッグデータをリクエストしない。
【０１１３】
その次、拡張クエリ処理部５５は、補正された拡張クエリを親キャッシュに対してクエリして処理する。さらに、その結果、ビッグデータをＯＬＡＰサーバー３０に返す。
【０１１４】
前記拡張クエリ補正部５３によって拡張クエリは複数の単位拡張クエリに分割され、前記拡張クエリは、これらの単位拡張クエリをユニオン（ｕｎｉｏｎ  Ａｌｌ）を使用して結合したクエリである。そして、これらのユニットの拡張クエリは、親キャッシュを参照するクエリである。
【０１１５】
拡張クエリ処理部５５は、前記補正された拡張クエリを行い、親キャッシュから所望のビッグデータを取り込んだり、これらのビッグデータの位置を返してもらい、これをＯＬＡＰサーバー３０に返す。
【０１１６】
以上、本発明者によってなされた発明を実施形態に基づいて具体的に説明したが、本発明はそれに限定されるものではなく、その要旨を逸脱しない範囲において種々変更可能であることは言うまでもない。
【符号の説明】
【０１１７】
１０  ユーザー端末
２０  クライアント
３０  ＯＬＡＰサーバー
５０  クエリ処理サーバー
５１  リクエストクエリ分離部
５２  親クエリ検索部
５３  拡張クエリ補正部
５４  親キャッシュキャッシング部
５５  拡張クエリ処理部
６０  データ基盤
６１  親クエリＤＢ
６２  マージテーブルＤＢ  
７０  サーバキャッシュ
９０  データキューブ
【図１】
2018037055.tif 000003
【図２】
2018037055.tif 000004
【図３】
2018037055.tif 000005
【図４】
2018037055.tif 000006
【図５】
2018037055.tif 000007
【図６】
2018037055.tif 000008
【図７】
2018037055.tif 000009
【図８】
2018037055.tif 000010
【図９】
2018037055.tif 000011
【図１０】
2018037055.tif 000012
【図１１】
2018037055.tif 000013
【図１２】
2018037055.tif 000014
【図１３】
2018037055.tif 000015
【図１４】
2018037055.tif 000016
【図１５】
2018037055.tif 000017
【図１６】
2018037055.tif 000018