JP2015197909A - 大容量データを処理するための、ｓｑｌパーシングによる２レベルクエリー及び結果キャッシングを用いたオンライン分析プロセッシング方法 - Google Patents

Abstract

【課題】データベースに対する要請クエリーの起動、結果提供速度を画期的に改善する、ＳＱＬパーシングによる２レベルクエリー及び結果キャッシングを用いたオンライン分析プロセッシング方法を提供する。
【解決手段】（ａ）要請クエリーに含まれているカラム名をを参照項目とし、要請クエリーが参照するテーブルを参照するクエリー（以下、基礎クエリー）と、基礎クエリーの結果データを参照して、要請クエリーが要請する結果データを取り込む拡張クエリーを生成するステップＳ１２と、（ｂ）基礎クエリーの結果データをサーバキャッシュから検索するステップＳ１３と、（ｃ）サーバキャッシュに結果データがなければ、基礎クエリーでデータベースにデータを要請し、結果データをサーバキャッシュに格納するステップＳ１４と、（ｄ）拡張クエリーを基礎クエリーの結果データに適用して結果データを取得するステップＳ１５と、を含む。
【選択図】図３

Description

本発明は、クライアントが質疑を要請したときに、ＳＱＬパーシングにより基礎クエリー（Ｂａｓｅ Ｑｕｅｒｙ）と拡張クエリー（Ｅｘｔｅｎｄ Ｑｕｅｒｙ）とにレベルを分けて、大容量データまたはビックデータを格納するデータベースから前記基礎クエリーによるデータを取り込んでインメモリ基盤のサーバキャッシュに格納し、前記サーバキャッシュのデータから拡張クエリーを起動して所要のデータを抽出する、ＳＱＬパーシングによる２レベルクエリー及び結果キャッシングを用いたオンライン分析プロセッシング方法に関する。

一般に、ビジネス・インテリジェンス（ＢＩ：Ｂｕｓｉｎｅｓｓ Ｉｎｔｅｌｌｉｇｅｎｃｅ）とは、企業の膨大なデータを統計分析などの定型的若しくは非定型的な方法を用いて様々に分析したり、分析された情報を理解し易い一目瞭然な報告書の形式に加工したりして、ビジネスをより合理的に行うようにサポートする一連のツールのことをいう。

企業がビジネスを行う間に蓄積されるデータの量は非常に膨大である。これらのデータはビジネス現場の生々しい内容を伝えるものであり、正常に分析されれば、そこからビジネスに必要な情報を取り出すことができる。しかしながら、現場で蓄積された相当量のデータから有意な分析結果を導き出すことはあまり簡単な作業ではない。

このような分析のための数多くのツールが個別的に開発されてきた。その代表例として、データ抽出及び変形（ＥＴＴ）ツール、多次元データ分析のためのオンライン分析処理（ＯＬＡＰ）ツール、報告書作成のためのレポーティングツール、データ間の隠れた連関性を見出すデータマイニングツールなどが挙げられる。これらの一連のツールを単一のソフトウェア製品群にしたものが一種のビジネスインテリジェンス（ＢＩ）である。

しかしながら、従来のビジネスインテリジェンス（ＢＩ）は、様々な分析ツールを集めておいたものであるが、ユーザは様々な分析ツールを取り扱うために熟練された知識を有することを余儀なくされるため、特定の分析を除いては普遍的に利用することが困難であった。これらの点を改善して、ウェブ環境下でデータベースを照会して分析するレポーティング技術が提案されている（例えば、下記の特許文献１参照）。なお、オンライン上でエクセル・インターフェースに基づいて分析報告書を作成するシステムなども提案されている（例えば、下記の特許文献２参照）。

ところが、最近、ソーシャル・ネットワーキング・サービス（ＳＮＳ）、ソーシャルメディアなどのデータに対する分析の重要性が次第に高くなるに伴い、企業体の製品に対する顧客管理や製品広報などのためのビックデータ（Big data）を収集して分析を行おうとする企業が段々増えてきている。ビックデータという用語は、ある程度経過した時間内に属するデータを収集、管理、格納、検索、共有、分析及び視覚化するための通常のソフトウェアツール及びコンピュータシステムでは取り扱い難いレベルのデータ量を有するデータセット（data set）に対して主として適用される。ビックデータのサイズは、テラバイト、エクサバイトまたはゼタバイトの範囲を有していてもよい。ビックデータは様々な分野に存在するが、例えば、ウェブログ（ｗｅｂ ｌｏｇｓ）、無線周波数認識装置（ＲＦＩＤ）、センサーネットワーク、ソーシャルネットワーク、ソーシャルデータ、インターネットテキストと文書、インターネット検索インデキシング、販売時点（ＰＯＳ：ｐｏｉｎｔ ｏｆ ｓａｌｅｓ）データ、販売記録、医療記録、写真記録、ビデオ記録及び電子商取引などが挙げられる。

このようなビックデータを用いて分析を行うためにオンライン分析プロセッシング（ＯＬＡＰ：ｏｎ-ｌｉｎｅ ａｎａｌｙｔｉｃａｌ ｐｒｏｃｅｓｓｉｎｇ）システムが導入されて用いられるが、このときに発生する最大の問題点の一つは、データ処理速度の遅延である。すなわち、数多くのデータを処理するための時間が長引くことにより、オンライン上でユーザが体感的に非常に長い時間を待つような感じがする。

図１に示すように、従来の技術によるオンライン分析プロセッシングシステムは、ユーザ端末に設けられるクライアントと、前記クライアントのデータ要求事項を処理するＢＩサーバ及びビックデータを格納するデータベースを備える。

ユーザは、ウェブブラウザ上でクライアントを介して報告書形式（または、テンプレート）を作成し、当報告書形式に入力すべきデータをＢＩサーバに要請する（ステップ１）。すなわち、前記クライアントで作成された報告書から抽出したデータベースコード（ＤＢコード）、クエリー（ＳＱＬクエリー）など所要の情報をＢＩサーバに転送する。次いで、ＢＩサーバはデータベースに接続して所要のデータを要請する（ステップ２）。データベースは、要請されたデータのセット（または、クエリー結果、キューブデータセット）などを検索して抽出し、抽出された結果データをＢＩサーバに転送する（ステップ３）。ＢＩサーバは、データベースから受信したフィールド情報とデータを圧縮してクライアントに転送する（ステップ４）。

上述した従来の技術によるオンライン分析プロセッシングシステムは、源泉データが千万件を超える瞬間から、上記のクエリー結果を受信するのに１０分以上かかる場合が頻発する。例えば、特定のサイトの場合、４億件の結果照会だけでも５分以上かかる。データベースのデータをフォーマットするのにも１５〜３０秒の時間がかかる。

このようにデータ処理速度が遅い理由は、データベースに要請する処理速度が急減するためである。データベースとしては、通常、商用化されて標準的なデータベース（ＤＢ：Ｄａｔａｂａｓｅ）機能を処理するデータサーバを用いる。このような商用化されたデータベースは、源泉テーブルが巨大である場合、例えば、データが１億個以上となる場合、多くのデータを処理するためにクエリー処理速度が急減する。

特に、ビュー（Ｖｉｅｗ）の機能を使用する場合にも、クエリー処理速度が非常に遅くなる。一般的に、ビューとは、１以上のテーブルからデータの部分集合を論理的に表現するものであり、実際にデータを有しているわけではなく、結果を一つのＳＱＬとして有している。ビューはアクセスを制限するために使用し、複雑な質疑を簡素化させることができるが、要請する度に内部的にＳＱＬを起動する。このため、源泉のビューが巨大あるいは複雑である場合、接続されたビューも遅くなる場合が発生する。なお、クエリー内にジョイン（Join）関数などの機能を用いてクエリーそのものが複雑である場合にも、その処理速度が非常に遅くなる。

商用化されたデータベースは、上述した問題点を解消するために自体的にクエリーをチューニングしてより高速でクエリーを処理するソリューションを有している。しかしながら、このようなチューニングも一般的な状況に備えるためのものであるため、自体システムに対するチューニングだけではある程度限界を有し、その結果、クエリー速度自体を画期的に改善することはできない。

例えば、商用化されたデータベースは一般的且つ標準化された場合のみに備えるためのものであるため、同じ又は類似のクエリー要請に対して同じ作業を繰り返し行う。

上述した問題に起因して、従来の技術によるオンライン分析プロセッシング（ＯＬＡＰ）システムは、オンライン上で非常に長い待ち時間を発生し、ユーザにとって使い勝手が悪い。

大韓民国登録特許第１０−０４９７８１１号（２００５年０６月１８日付け公告） 大韓民国登録特許第１０−０９６９６５６号（２０１０年０７月１４日付け公告）

本発明は上記の事情に鑑みてなされたものであり、その目的は、クライアントが質疑を要請したときに、ＳＱＬパーシングにより基礎クエリーと拡張クエリーとに分けて、大容量データまたはビックデータを格納するデータベースから前記基礎クエリーによるデータを取り込んでインメモリ基盤のサーバキャッシュに格納し、前記サーバキャッシュのデータから拡張クエリーを起動して所要のデータを抽出する、ＳＱＬパーシングによる２レベルクエリー及び結果キャッシングを用いたオンライン分析プロセッシング方法を提供することである。

前記目的を達成するために、本発明は、クライアントが要請するデータベースに対する要請クエリーを処理する分析処理サーバのＳＱＬパーシングによる２レベルクエリー及び結果キャッシングを用いたオンライン分析プロセッシング方法に関するものであり、（ａ）前記要請クエリーをパーシングして、前記要請クエリーに含まれているカラム名を抽出するステップと、（ｂ）抽出されたカラム名を参照項目として、前記要請クエリーが参照するテーブルと同じテーブルを参照するクエリー（以下、基礎クエリー）と、前記基礎クエリーの結果データを参照して、前記要請クエリーが要請する結果データを取り込む拡張クエリーを生成するステップと、（ｃ）前記基礎クエリーの結果データを前記サーバのサーバキャッシュから検索するステップと、（ｄ）前記サーバキャッシュに基礎クエリーの結果データがなければ、前記基礎クエリーで前記データベースにデータを要請し、受信した基礎クエリーの結果データを前記サーバキャッシュに格納するステップと、（ｅ）前記拡張クエリーを前記基礎クエリーの結果データに適用して前記拡張クエリーの結果データを取得し、取得された結果データを前記クライアントに転送するステップと、を含むことを特徴とする。

また、本発明は、クライアントが要請するデータベースに対する要請クエリーを処理する分析処理サーバのＳＱＬパーシングによる２レベルクエリー及び結果キャッシングを用いたオンライン分析プロセッシング方法に関するものであり、（ａ）前記要請クエリーをパーシングして、前記要請クエリーに含まれているカラム名を抽出するステップと、（ｂ）抽出されたカラム名を参照項目として、前記要請クエリーが参照するテーブルと同じテーブルを参照するクエリー（以下、基礎クエリー）と、前記基礎クエリーの結果データを参照して、前記要請クエリーが要請する結果データを取り込む拡張クエリーを生成するステップと、（ｃ）前記基礎クエリーの結果データを前記サーバのサーバキャッシュから検索するステップと、（ｄ）前記サーバキャッシュに基礎クエリーの結果データがなければ、前記要請クエリーで前記データベースにデータを要請し、受信した要請クエリーの結果データを前記クライアントに転送するステップと、（ｅ）前記基礎クエリーで前記データベースにデータを要請し、受信した基礎クエリーの結果データを前記サーバキャッシュに格納するステップと、を含むことを特徴とする。

さらに、本発明は、ＳＱＬパーシングによる２レベルクエリー及び結果キャッシングを用いたオンライン分析プロセッシング方法において、前記サーバは、前記拡張クエリーの結果データをキャッシュファイルとして前記サーバキャッシュに格納し、前記方法は、（ｆ）前記ステップ（ｂ）後に、前記拡張クエリーのキャッシュファイルが前記サーバキャッシュから検索される場合、検索されたキャッシュファイルをクライアントに転送するステップをさらに含むことを特徴とする。

さらに、本発明は、ＳＱＬパーシングによる２レベルクエリー及び結果キャッシングを用いたオンライン分析プロセッシング方法において、前記ステップ（ａ）において、前記カラム名が識別可能な固有キーを生成し、前記ステップ（ｂ）において、前記基礎クエリーの参照項目節で前記カラム名に対して前記固有キーでエイリアスを定義し、前記拡張クエリーは、前記エイリアスを用いてカラムを参照することを特徴とする。

さらに、本発明は、ＳＱＬパーシングによる２レベルクエリー及び結果キャッシングを用いたオンライン分析プロセッシング方法において、前記固有キーは、当該カラム名のデータベースの名前、参照テーブルの名前及びカラム名をハッシュして得ることを特徴とする。

さらに、本発明は、ＳＱＬパーシングによる２レベルクエリー及び結果キャッシングを用いたオンライン分析プロセッシング方法において、前記ステップ（ｂ）において、前記基礎クエリーは、参照項目節、テーブル参照節及び条件節から構成され、前記基礎クエリーのテーブル参照節及び条件節は、前記要請クエリーのテーブル参照節及び条件節と同じ構造を有することを特徴とする。

さらに、本発明は、ＳＱＬパーシングによる２レベルクエリー及び結果キャッシングを用いたオンライン分析プロセッシング方法において、前記ステップ（ｂ）において、前記拡張クエリーは、テーブル参照節で前記基礎クエリー又は前記基礎クエリーの結果データを参照し、前記テーブル参照節以外の節が前記要請クエリーの節と同じ構造を有するように生成されることを特徴とする。

さらに、本発明は、ＳＱＬパーシングによる２レベルクエリー及び結果キャッシングを用いたオンライン分析プロセッシング方法において、前記ステップ（ｂ）において、前記要請クエリーでテーブルに対するエイリアスが定義された場合、前記テーブルのエイリアスを削除し、前記テーブルのエイリアスを前記テーブルの名前に置き換えて前記拡張クエリーを生成することを特徴とする。

さらに、本発明は、ＳＱＬパーシングによる２レベルクエリー及び結果キャッシングを用いたオンライン分析プロセッシング方法において、前記サーバキャッシュは、インメモリストレージとキャッシュディスクとから構成され、前記基礎クエリーの結果データを前記インメモリストレージに格納することを特徴とする。

以上述べたように、本発明によるＳＱＬパーシングによる２レベルクエリー及び結果キャッシングを用いたオンライン分析プロセッシング方法によれば、要請されたクエリーのうち基本クエリーのデータをキャッシングすることにより、ビジネスインテリジェンスの分析環境下でクエリーの起動速度を画期的に改善してユーザに分析処理結果をリアルタイムにて提供することができるという効果が奏される。

従来の技術によるオンライン分析プロセッシングシステムの構成図である。 本発明によるＳＱＬパーシングによる２レベルクエリー及び結果キャッシングを用いたオンライン分析プロセッシング方法を実施するための全体システムの構成に対するブロック図である。 本発明の第１実施形態によるＳＱＬパーシングによる２レベルクエリー及び結果キャッシングを用いたオンライン分析プロセッシング方法を説明するためのフローチャートである。 本発明の第１実施形態による要請クエリーの一例を示す図である。 本発明の第１実施形態による基礎クエリー及び拡張クエリーの一例を示す図である。 本発明の第２実施形態によるＳＱＬパーシングによる２レベルクエリー及び結果キャッシングを用いたオンライン分析プロセッシング方法を説明するためのフローチャートである。 本発明の第３実施形態によるＳＱＬパーシングによる２レベルクエリー及び結果キャッシングを用いたオンライン分析プロセッシング方法を説明するためのフローチャートである。 本発明の第４実施形態によるサーバキャッシュの構成図である。 本発明による第１状況を説明するためのフローチャートである。 本発明による第２状況を説明するためのフローチャートである。 本発明による第３状況を説明するためのフローチャートである。 本発明の状況による処理結果に対する比較表である。

以下、添付図面に基づき、本発明の実施のための具体的な内容について説明する。

また、本発明を説明するに当たって、同じ構成要素には同じ符号を附し、その重複する説明は省略する。

先ず、図２に基づき、本発明による基礎クエリーの結果キャッシング基盤のオンライン分析プロセッシングシステム及び方法を実施するための全体システムについて説明する。

図２に示すように、本発明を実施するための全体システムは、クライアント２０と、分析処理サーバ３０と、ＢＩサーバ５０及びデータベース６０を備える。特に、分析処理サーバ３０は、データベース６０から受信した一部のデータを格納するためのサーバキャッシュ４０を備える。

クライアント２０は、ユーザ端末１０に設けられるクライアント用プログラムシステムであり、ウェブブラウザを介してユーザインターフェースを有する。すなわち、ユーザは、ウェブブラウザまたはウェブブラウザなどの画面のインターフェースを介して、オンライン上でデータ分析処理作業を行う。このとき、クライアント１０は、ユーザの指令などを受信して当該指令を実行し、処理結果を画面上またはウェブブラウザ上に表示する。一方、ユーザ端末１０は、個人向けコンピュータ（ＰＣ）、個人用の携帯情報端末（ＰＤＡ）、スマートフォンなどコンピューティング機能を有するコンピュータ端末である。

また、クライアント２０は、データ要請、データ分析などオンライン上で分析処理する作業を分析処理サーバ３０に要請し、その結果をサーバ３０から取り込んでウェブブラウザ上に表示する。

次いで、分析処理サーバ３０は、オンライン分析プロセッシング（ＯＬＡＰ）を処理するサーバであり、クライアント２０からデータ分析に対する要請を受信して、当該分析要請を処理してその結果をクライアント２０に転送するサーバである。

特に、分析処理サーバ３０は、データを要請するクエリーを用いて、データベース６０に格納されたデータを取り込む。クエリーとは、データベースに格納されたデータの検索または更新時に発生する質問または問い合わせを記述するデータ操作言語のことをいい、データベースにおいてクエリーは一種のコマンドのような役割を果たす。関係データベースの構造的な質疑言語（Ｓｔｒｕｃｔｕｒｅｄ Ｑｕｅｒｙ Ｌａｎｇｕａｇｅ：以下、ＳＱＬ）の形式で表現されるが、場合によってはＳＱＬ以外の形式で表現される。

また、分析処理サーバ３０はサーバキャッシュ４０を備え、データベース６０から取り込んだデータの全体または一部を一時的に格納する。サーバキャッシュ４０は、分析処理サーバのメモリ（ＲＡＭなど）上に実現されてキャッシュメモリとして構成されるか、あるいは、ハードディスクまたはソリッドステートドライブ（ＳＳＤ：ｓｏｌｉｄ ｓｔａｔｅ ｄｉｓｋ）などで実現されてキャッシュディスクとして構成される。あるいは、全てのデータをディスクに格納し、一部のデータ、すなわち、所要のデータをキャッシュメモリにアップロードして用いることができる。

次いで、ＢＩサーバ５０は、データベース６０を中継するデータベース（ＤＢ）インターフェースサーバの役割を果たす。すなわち、ＢＩサーバ５０は、分析処理サーバ３０からクエリーを受信して、当該クエリーを用いてデータベース６０のデータを取り込む。あるいは、データベース６０のデータベース管理システム（ＤＢＭＳ）に要請して当該データを取り込む。

また、ＢＩサーバ５０は、異質的な多数のデータベース６０から構成されても、当該データベースとのインターフェース方式に合わせて、クエリーを要請したりデータを受信したりする。さらに、ＢＩサーバ５０は、データを送受信するときに暗号化するか、あるいは、データ圧縮またはファイル圧縮などデータの送受信のための付加的な作業も行う。

次いで、データベース６０は、データを格納するための通常のデータベース（ＤＢ）であり、データを管理するためのＤＢＭＳを備え、データの格納、削除、検索などの作業をクエリーを用いて行う。特に、データベース６０は商用化されたデータベースであり、データを処理するための通常のクエリー機能を用いて、データクエリーサービスを行う。

特に、データベース６０は、ビックデータを格納するデータベースである。また、好ましくは、データベース６０は、関係型データベース（ＲＤＢ）から構成される。

次いで、図３に基づき、本発明の第１実施形態によるＳＱＬパーシングによる２レベルクエリー及び結果キャッシングを用いたオンライン分析プロセッシング方法についてより具体的に説明する。

図３に示すように、本発明の第１実施形態によるＳＱＬパーシングによる２レベルクエリー及び結果キャッシングを用いたオンライン分析プロセッシング方法は、（ａ）要請クエリーを受信してパーシングするステップ（Ｓ１１）と、（ｂ）基礎クエリー及び拡張クエリーを生成するステップ（Ｓ１２）と、（ｃ）基礎クエリーの結果をサーバキャッシュから検索するステップ（Ｓ１３）と、（ｄ）基礎クエリーの結果がサーバキャッシュから検索されなければ、基礎クエリーをデータベースから取り込んでサーバキャッシュに格納するステップ（Ｓ１４）と、（ｅ）前記基礎クエリーの結果に拡張クエリーを適用して要請クエリーの結果を取得するステップ（Ｓ１５）と、（ｆ）要請クエリーの結果を転送するステップ（Ｓ１６）と、を含む。

先ず、要請クエリーを受信してパーシングするステップ（Ｓ１１）について説明する。分析処理サーバ３０は、クライアント２０から要請クエリーを受信し、前記要請クエリーをパーシングする（Ｓ１１）。

ユーザ端末１０に設けられたクライアント２０において、所要のデータをクエリーで分析処理サーバ３０に要請する。好ましくは、要請クエリーはＳＱＬクエリーとして作成される。図４は、要請クエリーの一例を示している。

ＳＱＬクエリーとして作成された要請クエリーは、参照項目節（ＳＥＬＥＣＴ節）、テーブル節及びジョイン節（ＦＲＯＭ節）、条件節（ＷＨＥＲＥ節）、グループ節（ＧＲＯＵＰ ＢＹ）、順序節（ＯＲＤＥＲ ＢＹ）などから構成される。参照項目節（ｓｅｌｅｃｔ ｌｉｓｔ）は、所望のデータテーブルのフィールド／カラムを定義する節であり、テーブル節（ｔａｂｌｅ ｒｅｆｅｒｅｎｃｅ）は、データを取り込むテーブルを定義する節であり、ジョイン節（ｊｏｉｎ ｃｌａｕｓｅ）は、テーブル間のジョインを定義する節であり、条件節（ｗｈｅｒｅ ｃｌａｕｓｅ）は、条件を定義する節である。そして、グループ節（ｇｒｏｕｐ ｂｙ）や順序節（ｏｒｄｅｒ ｂｙ ｃｌａｕｓｅ）は、集計や表示のタイプを定義する節である。要請クエリーで定義されたデータフィールド、参照テーブル、条件文における変数などはいずれもデータベース６０にある源泉データのフィールド、テーブルなどを参照したものである。

要請ＳＱＬクエリーのパーシングは、要請ＳＱＬクエリーの構文を分析して、カラムリスト（ｓｅｌｅｃｔ ｌｉｓｔ）、テーブル参照（ｔａｂｌｅ ｒｅｆｅｒｅｎｃｅ）、ジョイン節（ｊｏｉｎ ｃｌａｕｓｅ）、条件節（ｗｈｅｒｅ ｃｌａｕｓｅ）、グループ節（ｇｒｏｕｐ ｂｙ ｃｌａｕｓｅ）、順序節（ｏｒｄｅｒ ｂｙ ｃｌａｕｓｅ）などを集合の形で抽出するものである。

特に、ＳＥＬＥＣＴ節（または、参照項目節）の参照項目からカラム名を抽出する。また、ジョイン節、条件節、グループ節、順序節などで参照するカラム名を全て抽出する。

要請クエリーがＳＱＬクエリーである場合、パーシングのためのＳＱＬ構文は、下記の通りである。

ｑｕｅｒｙ_ｂｌｏｃｋ
：(ｓｕｂｑｕｅｒｙ_ｆａｃｔｏｒｉｎｇ_ｃｌａｕｓｅ)？
ＳＥＬＥＣＴ(((ＤＩＳＴＩＮＣＴ|ＵＮＩＱＵＥ)|ＡＬＬ)？)ｓｅｌｅｃｔ_ｌｉｓｔ
ＦＲＯＭ(ｔａｂｌｅ_ｒｅｆｅｒｅｎｃｅ|ｊｏｉｎ_ｃｌａｕｓｅ) (ＣＯＭＭＡ(ｔａｂｌｅ_ｒｅｆｅｒｅｎｃｅ|ｊｏｉｎ_ｃｌａｕｓｅ))＊
ｗｈｅｒｅ_ｃｌａｕｓｅ？
ｈｉｅｒａｒｃｈｉｃａｌ_ｑｕｅｒｙ_ｃｌａｕｓｅ？
ｇｒｏｕｐ_ｂｙ_ｃｌａｕｓｅ？
ｏｒｄｅｒ_ｂｙ_ｃｌａｕｓｅ？
| ｑｕｅｒｙ_ｂｌｏｃｋ ((ＵＮＩＯＮ ＡＬＬ?) | (ＩＮＴＥＲＳＥＣＴ|Ｓ_ＭＩＮＵＳ)) ｑｕｅｒｙ_ｂｌｏｃｋ
| ＬＰＡＲＥＮ ｑｕｅｒｙ_ｂｌｏｃｋ ＲＰＡＲＥＮ

特に、参照項目が計算式である場合に、計算式内に含まれているカラム名を抽出する。また、条件節など他の節で参照する条件や数式などで用いられるカラム名も抽出する。

さらに、抽出されたカラム名に対して他のカラム名と識別可能な識別子または固有キーを生成する。このときの固有キーは、カラムの絶対名前に対する識別子（または、固有キー）である。絶対名前とは、参照データベースの名前、参照テーブルの名前、カラム名から構成された名前のことをいう。このため、カラムの絶対名前は、下記のように表わされる。

カラムの絶対名前＝＜データベースの名前＞．＜テーブルの名前＞．＜カラム名＞

または、データベースをあえて識別しなければ、下記のように表わされる。

カラムの絶対名前＝＜テーブルの名前＞．＜カラム名＞

絶対名前と比べて、カラム名をカラムの相対名前とも呼ぶこともある。

カラム名の固有キーは、カラム名の絶対名前を用いてハッシングにより得る。固有キーを生成する数式は、下記の通りである。

固有キー＝ ｈａｓｈ((ｄｏｍａｉｎ ｎａｍｅ) + ｄａｔａｂａｓｅ ｎａｍｅ + ｔａｂｌｅ ｎａｍｅ + ｃｏｌｕｍｎ ｎａｍｅ + ｆｕｎｃｔｉｏｎ ｎａｍｅ)

このため、カラム名の固有キーは、カラムを識別する識別子の機能を行う。すなわち、固有キーでカラムを識別することができる。

カラム名の固有キーは、基礎クエリーまたは要請クエリーを生成するときにエイリアシング（ａｌｉａｓｉｎｇ、別称）により各カラム名を識別するのに用いられる。カラム名の固有キーを用いて基礎クエリーのカラム名を全て別称（ａｌｉａｓ）で記載して、基礎クエリーによる結果データのテーブルにおけるカラム名を全て固有キーで生成する。すなわち、カラム名を識別子（または、固有キー）でエイリアスする理由は、自動的に生成されたクエリーにおいてカラムを識別するためである。

例えば、１番クエリーと２番クエリーが下記の通りであると仮定する。

［１番クエリー］
ｓｅｌｅｃｔ ｔ１.ｃｕｓｔｏｍｅｒ
ｆｒｏｍ ｍａｔｉｒｘ_ｄｅｍｏ ｔ１

［２番クエリー］
ｓｅｌｅｃｔ ｍ.ｃｕｓｔｏｍｅｒ
ｆｒｏｍ ｍａｔｒｉｘ_ｄｅｍｏ ｍ

この場合、１番クエリー及び２番クエリーにおいて、ｃｕｓｔｏｍｅｒは同じテーブルの同じカラムである。しかしながら、ａｌｉａｓキーがないため、ｔ１．ｃｕｓｔｏｍｅｒとｍ．ｃｕｓｔｏｍｅｒが異なるものであると認めることができる。

また、１番クエリー及び２番クエリーが下記の通りであると仮定する。

［１番クエリー］
ｓｅｌｅｃｔ ｔ.ｉｄ
ｆｒｏｍ ｍａｔｒｉｘ_ｄｅｍｏ１ ｔ

［２番クエリー］
ｓｅｌｅｃｔ ｔ.ｉｄ
ｆｒｏｍ ｍａｔｒｉｘ_ｄｅｍｏ２ ｔ

この場合にも、エイリアス（別称）の固有キーがないため一見して同じものであるかのように思えるが、実際には異なるカラムである。

このとき、固有キーを適用してエリアシングすれば、下記のようにクエリーが生成される。

［１番クエリー］
ｓｅｌｅｃｔ ｔ１. ｃｕｓｔｏｍｅｒ Ｃ９Ａ５９ＦＤ７Ｂ
ｆｒｏｍ ｍａｔｉｒｘ_ｄｅｍｏ ｔ１

［２番クエリー］
ｓｅｌｅｃｔ ｍ.ｃｕｓｔｏｍｅｒ Ｃ９Ａ５９ＦＤ７Ｂ
ｆｒｏｍ ｍａｔｒｉｘ_ｄｅｍｏ ｍ

このため、固有キー「Ｃ９Ａ５９ＦＤ７Ｂ」のみを見ると、同じデータベース名、同じテーブル名、同じカラム名、同じ関数名であることが分かる。

また、好ましくは、テーブル節からテーブル名のエイリアスを除去し、テーブル名のエイリアスと命名された構文を全て元のテーブル名に変更する。例えば、上述した例において、ＭＡＴＲＩＸ＿ＤＥＭＯがＴとエイリアスされて命名されていれば、元のテーブル名ＭＡＴＲＩＸ＿ＤＥＭＯに変更する。

さらに、好ましくは、多数のデータベースを用いる場合、テーブル参照節における各テーブル名に対するテーブルの絶対名前を求める。テーブルの絶対名前は、データベース名前とテーブル名前とから構成され、＜データベース名前＞．＜テーブル名前＞で表わされる。

一方、テーブル節とジョイン節はＳＱＬ構文における「ＦＲＯＭ」節に含まれる。すなわち、ＦＲＯＭ節はテーブルを参照するための節であり、テーブルとジョインとから構成される。このため、以下、テーブル節とジョイン節を含む節を「テーブル参照節」と呼ぶ。

次いで、分析処理サーバ３０は、パーシングした要請クエリーを用いて、基礎クエリーと拡張クエリーを生成する（Ｓ１２）。

基礎クエリーは、データベース６０のデータを参照して要請するクエリーであり、拡張クエリーは、基礎クエリーにより抽出されたデータ（または、基礎クエリーの結果データ）を参照して要請するクエリーである。基礎クエリーと拡張クエリーの一例が図５に示されている。

図５に示すように、基礎クエリー（Ｂａｓｅ ＳＱＬ）において、ＳＥＬＥＣＴ文に記載された「ＣＵＳＴＯＭＥＲ」、「ＰＲＯＤＵＣＴ」、「Ｃ」、「Ｃ２」などのデータフィールドの名称や、「ＭＡＴＲＩＸ＿ＤＥＭＯ」などの参照テーブルの名称や、「ＹＹＹＹ」などの条件文の変数（または、データフィールドの変数）はいずれもデータベース６０の源泉データを直接的に参照する。

先ず、基礎クエリーは、下記のようにして生成する。

ＳＱＬパーシングから抽出したカラム名（または、カラムリスト）で参照項目を作成する。このとき、好ましくは、要請クエリーの参照項目が計算式である場合、要請クエリーの計算式に含まれているカラム名で基礎クエリーの参照項目を生成する。なお、条件節など他の節で参照するカラム名も基礎クエリーの参照項目で生成する。

図４の例において、要請クエリーの３番目の参照項目は「ＳＵＭ（Ｔ．Ｈ＿ＶＡＬ）」の計算式である。また、条件節（ｗｈｅｒｅ ｃｌａｕｓｅ）における「Ｔ．ＹＹＹＹ＝ '２０１３'」は条件であるが、その条件内に「Ｔ．ＹＹＹＹ」カラム名が含まれている。このため、図５の基礎クエリーにおける参照項目には、計算式「ＳＵＭ（Ｔ．Ｈ＿ＶＡＬ）」内のカラム名「Ｔ．Ｈ＿ＶＡＬ」と、条件「Ｔ．ＹＹＹＹ＝ '２０１３'」内のカラム名「Ｔ．ＹＹＹＹ」を参照項目節の参照項目で生成する。

また、参照項目にカラム名の固有キーをエイリアシングする。すなわち、固有キーを別称で定義する。

そして、基礎クエリーのテーブル節（または、テーブル参照節）、ジョイン節、条件節は、要請クエリーのテーブル節、ジョイン節、条件節と同様に構成する。

但し、好ましくは、要請クエリーのテーブル節においてテーブル名がエイリアスされていれば、エイリアスされた別称を削除する。そして、参照項目節、ジョイン節、条件節において別称が記載されたテーブル名を全てテーブルの名前（または、絶対名前）に変更する。

例えば、要請クエリーが下記の通りである場合について説明する。

［要請クエリー１］
ｓｅｌｅｃｔ ｔ.ｃｕｓｔｏｍｅｒ, ｓｕｍ(ｔ.ｈ_ｖａｌ)
ｆｒｏｍ ｍａｔｒｉｘ_ｄｅｍｏ ｔ
ｗｈｅｒｅ ｔ.ｙｙｙｙ = '２０１３'
ｇｒｏｕｐ ｂｙ ｔ.ｃｕｓｏｍｅｒ

このとき、前記要請クエリー１から生成した基礎クエリーは、下記の通りである。

［基礎クエリー１］
ＳＥＬＥＣＴ ＭＡＴＲＩＸ_ＤＥＭＯ.ＣＵＳＴＯＭＥＲ Ｃ９Ａ５９ＦＤ７Ｂ, ＭＡＴＲＩＸ_ＤＥＭＯ.ＹＹＹＹ ＣＥＢ４１ＦＦＦ７, ＭＡＴＲＩＸ_ＤＥＭＯ.Ｈ_ＶＡＬ ＣＢ１６５Ｅ５Ｃ５
ＦＲＯＭ ＭＡＴＲＩＸ.ＭＡＴＲＩＸ_ＤＥＭＯ
ＷＨＥＲＥ ＭＡＴＲＩＸ_ＤＥＭＯ.ＹＹＹＹ = '２０１３'

すなわち、要請クエリーにおいてテーブルｍａｔｒｉｘ＿ｄｅｍｏの別称を「ｔ」と宣言したが、基礎クエリーでは全てテーブルの名前であるｍａｔｒｉｘ＿ｄｅｍｏに変更された。

次いで、拡張クエリーを生成する。

拡張クエリーは、テーブル節を除いては、要請クエリーと同じ構造を有し、テーブル節で参照するテーブルの代わりに、基礎クエリーまたは基礎クエリーの結果データテーブル（基礎クエリーが源泉データベースから取り込んだ結果テーブル）を参照する。

また、カラム名を全てカラムの固有キーに変更する。すなわち、拡張クエリーが参照するテーブルが基礎クエリーの結果テーブルであるため、参照するテーブルのカラムは全て基礎クエリーで宣言した固有キーで参照せねばならない。

先ず、［要請クエリー１］と［基礎クエリー１］による拡張クエリーは、下記の通りである。

［拡張クエリー１］
ＳＥＬＥＣＴ ＭＨＣ.Ｃ９Ａ５９ＦＤ７Ｂ, ＳＵＭ(ＭＨＣ.ＣＢ１６５Ｅ５Ｃ５) ＡＳ"ＣＢ１６５Ｅ５Ｃ５"
ＦＲＯＭ ( {＠ＯＲＩＧＩＮＡＬ_ＳＱＬ＠} ) ＭＨＣ
ＷＨＥＲＥ ＭＨＣ.ＣＥＢ４１ＦＦＦ７ = '２０１３'
ＧＲＯＵＰ ＢＹ
ＭＨＣ.Ｃ９Ａ５９ＦＤ７Ｂ

ここで、「｛＠ＯＲＩＧＩＮＡＬ＿ＳＱＬ＠｝」は、基礎クエリーまたは基礎クエリーの結果テーブルを参照することを表わす。

このため、基礎クエリーにより抽出されたデータが取得されれば、拡張クエリーは、取得された基礎クエリーの結果データを参照して要請されるクエリーである。拡張クエリーにより得られる結果は、元の要請クエリーにより得られる結果と同様である。また、拡張クエリーにより得られる結果データの集まりは、常に基礎クエリーにより得られる結果データの集まりよりも小さい。すなわち、拡張クエリーのデータの集まりは、基礎クエリーのデータの集まりの部分集合であるといえる。

さらに、基礎クエリーの結果データがない場合、［拡張クエリー１］において、｛＠ＯＲＩＧＩＮＡＬ＿ＳＱＬ＠｝に基礎クエリーを代入し、源泉データベースに質疑すれば、要請クエリーの結果が得られる。

次いで、基礎クエリーの結果データがサーバキャッシュ４０に格納されているか否かを検索する（Ｓ１３）。

基礎クエリーによりデータベース６０から取り込んだデータ（または、基礎クエリーの結果データ）は、サーバキャッシュ４０に格納して保管する。分析処理サーバ３０は、上記で求めた基礎クエリーをサーバキャッシュ４０から検索する。すなわち、格納しておいた基礎クエリーに上記で求めた基礎クエリーが存在するか否かを検索する。

検索のための比較過程について説明すれば、参照項目節、テーブル節／ジョイン節及び条件節が同じであるか否かで判断する。但し、参照するテーブル（または、テーブル間のジョインも含まれる）が同じである場合には、参照項目節（ＳＥＬＥＣＴ節）と条件節（ｗｈｅｒｅ ｃｌａｓｕｅ）のみが同じであるか否かを比較する。特に、参照項目節では、カラム名の固有キーのみを比較すればよい。すなわち、エイリアスが同じであるか否かのみを比較する。

例えば、本出願人のマトリックス（ｍａｔｒｉｘ）で用いられるＳＱＬは、メタを用いて自動的に生成されたＳＱＬである。メタアイテム１とメタアイテム２を選択したならば、既に当該メタアイテムのテーブルコード、カラムコード、ジョイン条件を自動的に生成することができる。同じメタで自動的に生成されたＳＱＬはフィールドａｌｉａｓの比較だけでも同じであることが分かる。すなわち、追加的に条件比較のみを行えば、基礎クエリーの再使用有無をチェックすることができる。しかしながら、メタなしにクエリーのみを比較するのであれば、テーブル及びこれらの間のジョイン関係も比較せねばならない。

次いで、基礎クエリーの結果データがサーバキャッシュに格納されていなければ、前記基礎クエリーでデータベース６０にデータを要請し、基礎クエリーの結果データを受信すれば、これをサーバキャッシュ４０に格納する（Ｓ１４）。

上述したように、基礎クエリーはデータベース６０に格納されたデータを直接的に参照するクエリーであるため、当該基礎クエリーでデータベース６０にクエリー要請をする。クエリー要請は、ＢＩサーバ５０を介してデータベース６０に対して行われ、データベース６０から前記基礎クエリーにより抽出されたデータはＢＩサーバ５０を介して分析処理サーバ３０に戻る。分析処理サーバ３０は、受信した前記基礎クエリーの結果データをサーバキャッシュ４０に格納する。

一方、基礎クエリーの結果データは、データベース６０のデータ構造と同じ形式または同じ構造で格納される。すなわち、データベース６０のデータがテーブルの形式で格納されるのであれば、基礎クエリーの結果データもテーブルの形式で格納される。さらに、サーバキャッシュ４０に格納される結果データの各フィールドのタイプやサイズなどがデータベース６０に設けられたフィールドのタイプやサイズと同様になるように構成される。これは、拡張クエリーがデータベース６０に格納されたデータの代わりに基礎クエリーの結果データを参照してもクエリーが起動されるようにするためである。

このとき、結果テーブルのカラム名は、カラムの固有キーに変更される。

次いで、分析処理サーバ３０は、基礎クエリーの結果に拡張クエリーを適用して要請クエリーの結果を取得する（Ｓ１５）。

拡張クエリーは要請クエリーと同じ構造を有し、データベース６０を参照する代わりに、基礎クエリーを参照するクエリーである。このため、拡張クエリーでデータベース６０を参照する名称（以下、データベース参照名称）を基礎クエリーの結果データを参照する名称（以下、基礎クエリー参照名称）に変更して生成する。上述したように、拡張クエリーで参照するテーブルの名称は基礎クエリーにより生成されたテーブル（または、結果テーブル）を参照するように全て変更され、拡張クエリーで参照するデータフィールドの名称（または、カラム名）は全て基礎クエリーにより生成されたデータフィールドの名称（または、カラム名の固有キー）に変更される。

上記のステップＳ１３において、基礎クエリーの結果データがサーバキャッシュ４０に格納されていてもよく、格納されていなくてもよい。しかしながら、格納されていない場合、ステップＳ１４において、基礎クエリーでデータベース６０にクエリーを要請してデータを受信してサーバキャッシュ４０に格納する。このため、今回は、ステップＳ１５においては、基礎クエリーの結果データはサーバキャッシュ４０に必ず格納されている。

また、拡張クエリーは基礎クエリーのデータを参照するクエリーである。このため、拡張クエリーを基礎クエリーの結果データに適用することができる。基礎クエリーの結果データを参照して拡張クエリーを適用すれば、元の要請された要請クエリーの結果データを得ることができる。

最後に、上記で拡張クエリーを適用して得た結果データを要請クエリーの結果として、クライアント２０に転送する（Ｓ１６）。

次いで、図６に基づき、本発明の第２実施形態によるＳＱＬパーシングによる２レベルクエリー及び結果キャッシングを用いたオンライン分析プロセッシング方法についてより具体的に説明する。

図６に示すように、本発明の第２実施形態によるＳＱＬパーシングによる２レベルクエリー及び結果キャッシングを用いたオンライン分析プロセッシング方法は、（ａ）要請クエリーを受信してパーシングするステップ（Ｓ２１）と、（ｂ）基礎クエリーと拡張クエリーを生成するステップ（Ｓ２２）と、（ｃ）基礎クエリーの結果をサーバキャッシュから検索するステップ（Ｓ２３）と、（ｄ）基礎クエリーの結果がサーバキャッシュから検索されなければ、要請クエリーをデータベースから取り込んで転送するステップ（Ｓ２４）と、（ｈ）基礎クエリーをデータベースから取り込んでサーバキャッシュに格納するステップ（Ｓ２８）と、（ｅ）基礎クエリーの結果がサーバキャッシュから検索されれば、拡張クエリーを起動するステップと、（ｆ）前記基礎クエリーの結果に拡張クエリーを適用して要請クエリーの結果を取得するステップ（Ｓ２５）と、（ｇ）要請クエリーの結果を転送するステップ（Ｓ２６）と、を含む。

上述した第１実施形態と比較すれば、基礎クエリーをサーバキャッシュから検索したとき、サーバキャッシュから基礎クエリーが検索されなければ、要請クエリーでデータベース６０に要請してその結果を直ちにクライアント２０に転送する点（Ｓ２４）で相違点がある。そして、要請クエリーの結果データを転送した後、基礎クエリーを再びデータベース６０に要請して基礎クエリーの結果データをサーバキャッシュ４０に格納する（Ｓ２８）。以下、説明のうち省略された部分は、上述した第１実施形態の説明を参照する。

先ず、分析処理サーバ３０は、クライアント２０から要請クエリーを受信してパーシングする（Ｓ２１）。上述した第１実施形態と同様である。次いで、分析処理サーバ３０は、パーシング結果を用いて基礎クエリー及び拡張クエリーを生成する（Ｓ２２）。

そして、基礎クエリーの結果データがサーバキャッシュ４０に格納されているか否かを検索する（Ｓ２３）。基礎クエリーによりデータベース６０から取り込んだデータ（または、基礎クエリーの結果データ）はサーバキャッシュ４０に格納して保管する。分析処理サーバ３０は、上記で得た基礎クエリーを、サーバキャッシュ４０に格納しておいた基礎クエリーの結果データと比較して検索する。

次いで、基礎クエリーの結果データがサーバキャッシュに格納されていなければ、前記要請クエリーでデータベース６０にデータを要請し、前記要請クエリーの結果データを受信すれば、これをクライアント２０に転送する（Ｓ２４）。このとき、拡張クエリー内でテーブル節を基礎クエリーに置き換えた後、拡張クエリーを直ちにデータベース６０に要請しても、所望の結果データ（または、結果テーブル）を取得することができる。

クライアント２０に要請クエリーの結果データを転送した後、分析処理サーバ３０は前記基礎クエリーでデータベース６０にデータを要請し、基礎クエリーの結果データを受信すれば、これをサーバキャッシュ４０に格納する（Ｓ２８）。特に、分析処理サーバ３０は、スケジューラーにより、データベース６０の要請が殺到せず、しかも、トラフィックに余裕がある時間に前記基礎クエリーに関するデータを要請してその結果をサーバキャッシュ４０に格納する。

次いで、基礎クエリーの結果データがサーバキャッシュに格納された場合について説明する。分析処理サーバ３０は、基礎クエリーの結果データに拡張クエリーを適用して要請クエリーの結果を取得する（Ｓ２５）。次いで、取得された結果データをクライアント２０に転送する（Ｓ２６）。

次いで、図７に基づき、本発明の第３実施形態によるＳＱＬパーシングによる２レベルクエリー及び結果キャッシングを用いたオンライン分析プロセッシング方法についてより具体的に説明する。

図３に示すように、本発明の第３実施形態によるＳＱＬパーシングによる２レベルクエリー及び結果キャッシングを用いたオンライン分析プロセッシング方法は、（ａ）要請クエリーを受信してパーシングするステップ（Ｓ３０）と、（ｂ）基礎クエリーと拡張クエリーを生成するステップ（Ｓ３１）と、（ｃ）前記基礎クエリーと拡張クエリーを組み合わせてキャッシュファイルから検索するステップ（Ｓ３２）と、（ｄ）キャッシュファイルが検索されれば、キャッシュファイルをクライアントに転送するステップ（Ｓ３３）と、（ｅ）キャッシュファイルが検索されなければ、第１または第２実施形態を行うステップ（３４）と、（ｆ）要請クエリーの結果データをキャッシュファイルとして格納するステップ（Ｓ３５）と、を含む。

本発明の第３実施形態は、上述した第１または第２実施形態を補完する実施形態である。すなわち、要請クエリーの結果データをキャッシュファイルとしてバイナリ形式で格納していて、同じクエリーで再び要請されれば、当該キャッシュファイルを直ちにクライアント２０に転送する。

キャッシュファイルとは、要請クエリーの結果データをファイルとして格納したものをいう。分析処理サーバ３０が、クライアント２０が要請した結果データを作成して最終的に転送するとき、ファイルの形式で転送する。キャッシュファイルは、転送するときと同じファイルである。このため、キャッシュファイルのクエリーと同じ要請クエリーで要請すれば、当該キャッシュファイルを直ちに転送すればよい。

好ましくは、キャッシュファイルは、分析処理サーバ３０のサーバキャッシュ４０に格納される。

具体的に、分析処理サーバ３０は、クライアント２０から要請クエリーを受信してパーシングする（Ｓ３０）。上述した第１または第２実施形態と同様である。分析処理サーバ３０は、基礎クエリーと拡張クエリーを組み合わせて、格納されたキャッシュファイルのクエリーを比較して、同じクエリーがあるか否かを検索する（Ｓ３２）。

もし、同じクエリーがキャッシュファイルにあれば、検索されたキャッシュファイルを直ちにクライアント２０に転送する（Ｓ３３）。

もし、同じクエリーがなければ、上述した第１または第２実施形態の３番目の検索ステップ（Ｓ１３、Ｓ２３）を行う（Ｓ３４）。すなわち、サーバキャッシュに基礎クエリーの結果データがあるか否かを検索する。サーバキャッシュに基礎クエリーの結果データがあれば、基礎クエリーを対象に拡張クエリーを作成して結果データを取得する。取得された結果データをクライアントに転送する。サーバキャッシュに基礎クエリーの結果データがなければ、基礎クエリーまたは要請クエリーでデータベース６０から結果データを取り込む。取り込んだ結果データが基礎クエリーデータであれば、拡張クエリーにより要請クエリーの結果データを生成する。最終的に、要請クエリーの結果データをクライアント２０に転送する。

第１または第２実施形態を終えると、生成された基礎クエリー及び拡張クエリーの組み合わせの結果データ（または、クライアントに転送した結果データ）をキャッシュファイルとしてサーバキャッシュ４０に格納する（Ｓ３５）。

次いで、図８に基づき、本発明の第４実施形態によるＳＱＬパーシングによる２レベルクエリー及び結果キャッシングを用いたオンライン分析プロセッシング方法について具体的に説明する。

本発明の第４実施形態は、上述した第１から第３実施形態と同じ構成を有する。但し、サーバキャッシュ４０の構成がより細分化される。

図８に示すように、本発明の第４実施形態では、サーバキャッシュ４０をキャッシュメモリ４１とキャッシュディスク４２とに分ける。

キャッシュメモリ４１は、分析処理サーバ３０のＲＡＭ（Random access memory）から構成される。特に、キャッシュメモリ４１は、インメモリストレージから構成される。キャッシュディスク４２は、分析処理サーバ３０のハードディスクまたはソリッドステートドライブ（ＳＳＤ）などから構成される。

上記の本発明の第１から第３実施形態において、サーバキャッシュ４０に格納される基礎クエリーの結果データは全てキャッシュメモリ４１に格納される。但し、キャッシュメモリ４１の格納容量よりも基礎クエリーの結果データの方がさらに多い場合、キャッシュメモリの容量を超える結果データはキャッシュディスク４２に格納される。

このとき、キャッシュディスク４２に移される基礎クエリーの結果データは予め定められたポリシーにより選別される。選別ポリシーの例として、結果データへのアクセス頻度、最近のアクセス時刻などに基づいて、アクセス頻度が低いか、あるいは、最近のアクセス時刻が最も古い結果データを選別する。

また、第３実施形態のキャッシュファイルはキャッシュディスク４２に格納される。

以下、図９から図１２に基づき、本発明の効果についてより具体的に説明する。

本発明は、ビジネスインテリジェンス（ＢＩ）基盤のビックデータを処理するためのプラットフォームに関するものである。特に、ビックデータを要請したとき、応答時間を１０秒以内の早い時間内にすることにより、リアルタイムに近い処理を行う。本発明は、リアルタイムに近い処理のためのキャッシュファイルとキャッシュメモリテーブルを用いる。このために、要請クエリーをパーシングして、基礎クエリーと拡張クエリーとに分ける。

また、メモリの限界によるファイル形式のロード／格納／フィルタリングの構造を定義する。例えば、約１億件をメモリテーブルにロードするのに約５Ｇがかかるとしたとき、３２Ｇサーバの環境下であれば、約１０億件をメモリに保管しているわけにはいかない。このため、一部のデータをファイル形式で速やかに格納し、必要に応じて、再びメモリにロードするような構造が必要である。ファイル自体に条件（フィルタリングとクエリーをパーシングして当該カラムから条件を抽出する）を与えて所望のデータのみを処理する。

また、要請クエリーを基礎クエリー（Ｂａｓｅ ＳＱＬ）と拡張クエリーとに分ける理由は、相対的に速度が下がる関係型データベース（ＲＤＢ）を用いるわけではなく、分析処理サーバ３０に設けられたサーバキャッシュ（インメモリデータベース）を用いるためである。これにより、速度が画期的に改善される。インメモリデータベース（Ｉｎ-ｍｅｍｏｒｙ Ｄａｔａｂａｓｅ）は、データストレージのメインメモリに設けられて運営される方式のデータベース管理システムである。ディスクに設けられる方式に比べて処理速度が速い。

具体的に、本発明の第１から第４実施形態を適用する場合、各状況における処理速度について説明する。

先ず、第１状況は、基礎クエリーと拡張クエリーがいずれも一致しない場合である。すなわち、第１状況は最初にクエリーが起動される場合に相当し、全体の処理速度は従来の技術によるシステムと同様である。

図９に示すように、先ず、マトリックス報告書から抽出したＤＢコード、ＳＱＬ情報を基礎クエリー（Ｂａｓｅ ＳＱＬ）と拡張クエリー（Ｅｘｔｅｎｄ ＳＱＬ）に分けて分析処理サーバ（ＳＯＬＡＰサーバ）に要請する（ステップ１）。一致する基礎クエリー（Ｂａｓｅ ＳＱＬ）と拡張クエリー（Ｅｘｔｅｎｄ ＳＱＬ）がないため、クエリーを元の要請クエリーとしてＢＩサーバ（Ｍａｔｒｉｘ Ｓｅｒｖｅｒ）に要請する（ステップ２）。ＢＩサーバがターゲットＤＢに接続してデータを要請する（ステップ３）。ターゲットＤＢがキューブ（ｃｕｂｅ）データを転送する（ステップ４）。そして、フィールド情報とデータを圧縮して転送する（ステップ５）。転送されたファイルをキャッシュファイルとして格納する（ステップ６）。キャッシュファイルをブラウザ（または、クライアント）に転送する（ステップ７）。最後に、スケジューラーが基礎クエリー（Ｂａｓｅ ＳＱＬ）を源泉ＤＢで起動してキャッシュメモリ４０に格納（Ｂａｃｋｇｒｏｕｎｄ起動）する（ステップ８）。

次いで、第２状況は、基礎クエリーは一致し、拡張クエリーは一致しない場合である。基礎クエリー（Ｂａｓｅ ＳＱＬ）に相当するキャッシュメモリテーブルを生成した場合に相当し、速度は１０秒内外であり、第１状況（または、従来の技術）に比べて１０〜５０倍向上する。

図１０に示すように、先ず、マトリックス報告書から抽出したＤＢコード、ＳＱＬ情報を基礎クエリー（Ｂａｓｅ ＳＱＬ）と拡張クエリー（Ｅｘｔｅｎｄ ＳＱＬ）とに分けてＳＯＬＡＰサーバに要請する（ステップ１）。基礎クエリー（Ｂａｓｅ ＳＱＬが一致し、拡張クエリー（Ｅｘｔｅｎｄ ＳＱＬ）がない場合、拡張クエリー（Ｅｘｔｅｎｄ ＳＱＬ）のターゲットテーブルはサーバキャッシュに格納されたテーブル名に変更して起動する（ステップ２）。そして、サーバキャッシュがキューブデータを転送する（ステップ３）。転送されたファイルをキャッシュファイルとして格納する（ステップ４）。最後に、キャッシュファイルをブラウザに転送する（ステップ５）。

次いで、第３状況は、基礎クエリーと拡張クエリーの両方が一致する場合である。基礎クエリー（Ｂａｓｅ ＳＱＬ）と拡張クエリー（Ｅｘｔｅｎｄ ＳＱＬ）の両方が一致する場合に相当し、速度は３秒以内外であり、第１状況または従来の技術に比べて１００倍以上向上する。

図１１に示すように、マトリックス報告書から抽出したＤＢコード、ＳＱＬ情報を基礎クエリー（Ｂａｓｅ ＳＱＬ）と拡張クエリー（Ｅｘｔｅｎｄ ＳＱＬ）とに分けて分析処理サーバに要請する（ステップ１）。基礎クエリー（Ｂａｓｅ ＳＱＬ）と拡張クエリー（Ｅｘｔｅｎｄ ＳＱＬ）がいずれも一致する場合にハッシュキー値が存在する（ステップ２）。そして、キャッシュファイルをブラウザに転送する（ステップ３）。

前記第１から第３状況の処理速度などを比較した表が図１２に示されている。同じクエリーが起動されれば、状態が自動的に移行する。すなわち、第１状況から第２状況に、第２状況から第３状況に移行する。また、同時ユーザ数が増大すれば、キャッシュファイルの使用頻度が急増する（９０％以上であると予想される）。大多数のユーザは５分から３秒へのクエリー時間の減少を経験する。また、最初の起動において、基礎クエリーに関するデータはスケジューラーで起動することができる。すなわち、スケジューラーにより余裕のある時間にデータを取り込むことができて、体感速度に影響を及ぼさない。

以上、本発明者により案出された発明について実施形態を挙げて具体的に説明したが、本発明は実施形態に限定されるものではなく、その要旨を逸脱しない範囲内で種々に変更可能であるということはいうまでもない。

１０：ユーザ端末
２０：クライアント
３０：分析処理サーバ
４０：サーバキャッシュ
４１：キャッシュメモリ
４２：キャッシュディスク
５０：ＢＩサーバ
６０：データベース

Claims (9)

1. クライアントが要請するデータベースに対する要請クエリーを処理する分析処理サーバのＳＱＬパーシングによる２レベルクエリー及び結果キャッシングを用いたオンライン分析プロセッシング方法において、
   （ａ）前記要請クエリーをパーシングして、前記要請クエリーに含まれているカラム名を抽出するステップと、
   （ｂ）抽出されたカラム名を参照項目として、前記要請クエリーが参照するテーブルと同じテーブルを参照するクエリー（以下、基礎クエリー）と、前記基礎クエリーの結果データを参照して、前記要請クエリーが要請する結果データを取り込む拡張クエリーを生成するステップと、
   （ｃ）前記基礎クエリーの結果データを前記サーバのサーバキャッシュから検索するステップと、
   （ｄ）前記サーバキャッシュに基礎クエリーの結果データがなければ、前記基礎クエリーで前記データベースにデータを要請し、受信した基礎クエリーの結果データを前記サーバキャッシュに格納するステップと、
   （ｅ）前記拡張クエリーを前記基礎クエリーの結果データに適用して前記拡張クエリーの結果データを取得し、取得された結果データを前記クライアントに転送するステップと、
   を含むことを特徴とするＳＱＬパーシングによる２レベルクエリー及び結果キャッシングを用いたオンライン分析プロセッシング方法。
2. クライアントが要請するデータベースに対する要請クエリーを処理する分析処理サーバのＳＱＬパーシングによる２レベルクエリー及び結果キャッシングを用いたオンライン分析プロセッシング方法において、
   （ａ）前記要請クエリーをパーシングして、前記要請クエリーに含まれているカラム名を抽出するステップと、
   （ｂ）抽出されたカラム名を参照項目として、前記要請クエリーが参照するテーブルと同じテーブルを参照するクエリー（以下、基礎クエリー）と、前記基礎クエリーの結果データを参照して、前記要請クエリーが要請する結果データを取り込む拡張クエリーを生成するステップと、
   （ｃ）前記基礎クエリーの結果データを前記サーバのサーバキャッシュから検索するステップと、
   （ｄ）前記サーバキャッシュに基礎クエリーの結果データがなければ、前記要請クエリーで前記データベースにデータを要請し、受信した要請クエリーの結果データを前記クライアントに転送するステップと、
   （ｅ）前記基礎クエリーで前記データベースにデータを要請し、受信した基礎クエリーの結果データを前記サーバキャッシュに格納するステップと、
   を含むことを特徴とするＳＱＬパーシングによる２レベルクエリー及び結果キャッシングを用いたオンライン分析プロセッシング方法。
3. 前記サーバは、前記拡張クエリーの結果データをキャッシュファイルとして前記サーバキャッシュに格納し、
   前記方法は、
   （ｆ）前記ステップ（ｂ）後に、前記拡張クエリーのキャッシュファイルが前記サーバキャッシュから検索される場合、検索されたキャッシュファイルをクライアントに転送するステップをさらに含むことを特徴とする請求項１または２に記載のＳＱＬパーシングによる２レベルクエリー及び結果キャッシングを用いたオンライン分析プロセッシング方法。
4. 前記ステップ（ａ）において、前記カラム名が識別可能な固有キーを生成し、
   前記ステップ（ｂ）において、前記基礎クエリーの参照項目節で前記カラム名に対して前記固有キーでエイリアスを定義し、前記拡張クエリーは、前記エイリアスを用いてカラムを参照することを特徴とする請求項１または２に記載のＳＱＬパーシングによる２レベルクエリー及び結果キャッシングを用いたオンライン分析プロセッシング方法。
5. 前記固有キーは、当該カラム名のデータベースの名前、参照テーブルの名前及びカラム名をハッシュして得ることを特徴とする請求項１または２に記載のＳＱＬパーシングによる２レベルクエリー及び結果キャッシングを用いたオンライン分析プロセッシング方法。
6. 前記ステップ（ｂ）において、前記基礎クエリーは、参照項目節、テーブル参照節及び条件節から構成され、前記基礎クエリーのテーブル参照節及び条件節は、前記要請クエリーのテーブル参照節及び条件節と同じ構造を有することを特徴とする請求項１または２に記載のＳＱＬパーシングによる２レベルクエリー及び結果キャッシングを用いたオンライン分析プロセッシング方法。
7. 前記ステップ（ｂ）において、前記拡張クエリーは、テーブル参照節で前記基礎クエリーまたは前記基礎クエリーの結果データを参照し、前記テーブル参照節以外の節が前記要請クエリーの節と同じ構造を有するように生成されることを特徴とする請求項６に記載のＳＱＬパーシングによる２レベルクエリー及び結果キャッシングを用いたオンライン分析プロセッシング方法。
8. 前記ステップ（ｂ）において、前記要請クエリーでテーブルに対するエイリアスが定義された場合、前記テーブルのエイリアスを削除し、前記テーブルのエイリアスを前記テーブルの名前に置き換えて前記拡張クエリーを生成することを特徴とする請求項７に記載のＳＱＬパーシングによる２レベルクエリー及び結果キャッシングを用いたオンライン分析プロセッシング方法。
9. 前記サーバキャッシュは、インメモリストレージとキャッシュディスクとから構成され、
   前記基礎クエリーの結果データを前記インメモリストレージに格納することを特徴とする請求項１または２に記載のＳＱＬパーシングによる２レベルクエリー及び結果キャッシングを用いたオンライン分析プロセッシング方法。