(57)【要約】【課題】データベースにおける解析処理において、アグリゲーション結果を格納する場所を探すことに起因する遅延を解消し、解析処理の時間を短縮する。【解決手段】ジョイン処理の結果を保持すると共に、該ジョイン処理の結果を用いてアグリゲーションの結果の格納先を決定し、該決定した格納先の場所を指す情報であるアグリゲーション結果格納先情報を保持しておき、その後、前記ジョイン処理の結果のインデックスを辿ってアグリゲーション処理を行い、該アグリゲーション結果をアグリゲーション結果格納先情報により特定される格納先に格納する。【選択図】図１
2013092873.tif 000002
【特許請求の範囲】
【請求項１】
ジョイン処理の結果を保持すると共に、該ジョイン処理の結果を用いてアグリゲーションの結果の格納先を決定し、該決定した格納先の場所を指す情報であるアグリゲーション結果格納先情報を保持しておき、その後、前記ジョイン処理の結果のインデックスを辿ってアグリゲーション処理を行い、該アグリゲーション結果をアグリゲーション結果格納先情報により特定される格納先に格納することを特徴とするデータベース処理装置。
【請求項２】
請求項１に記載のデータベース処理装置であって、
アグリゲーション結果の格納場所の決定に必要とされるジョイン処理を行い、該ジョイン処理の結果をジョイン結果格納部に格納するジョイン部と、
前記ジョイン処理の結果を用いてアグリゲーションの結果の格納先を決定し、該決定した格納先の場所を指す情報であるアグリゲーション結果格納先情報をアグリゲーション結果格納先情報格納部に格納するアグリゲーション結果格納先決定部と、
前記ジョイン結果格納部を参照して、クエリのセレクション処理を行うセレクション部と、
前記セレクション処理の結果に基づいてアグリゲーション処理を行うと共に、前記アグリゲーション結果格納先情報格納部からアグリゲーション結果格納先情報を得て、該アグリゲーション結果をアグリゲーション結果格納先情報により特定される格納先に格納するアグリゲーション計算部と、
を備えることを特徴とするデータベース処理装置。
【請求項３】
請求項２に記載のデータベース処理装置であって、
データの解析処理を実行するクエリに対して影響を与えるレコードの、挿入や更新のイベントを調べることによりイベントの内容の検知を行う検知部を更に備え、
前記ジョイン部は、アグリゲーション結果の格納場所の決定ができるイベントを前記検知部が検知した場合に動作し、
前記セレクション部は、アグリゲーションを計算できるイベントを前記検知部が検知した場合に動作することを特徴とするデータベース処理装置。
【請求項４】
請求項３に記載のデータベース処理装置であって、
前記検知部が少なくとも、アグリゲーション結果の格納場所の決定に必要なアトリビュート及びアグリゲーションの計算に必要なアトリビュートを、取得するために必要とされるジョインができるイベントであることを検知し、
前期ジョイン部が少なくとも、アグリゲーション結果の格納場所の決定に必要なアトリビュート及びアグリゲーションの計算に必要なアトリビュートを、取得するために必要とされるジョイン処理を行うことを特徴とするデータベース処理装置。
【請求項５】
請求項２乃至４の何れか１項に記載のデータベース処理装置であって、
前記アグリゲーション結果格納先情報参照部及び前記アグリゲーション計算部は、前記セレクション結果が真、あるいはセレクション項のリテラルが変更された他のクエリのために結果を格納する場合に動作することを特徴とするデータベース処理装置。
【請求項６】
請求項２乃至５の何れか１項に記載のデータベース処理装置であって、
前記ジョイン部は、アグリゲーションの結果を格納する場所を決めるのに必要なアトリビュートに加えて、セレクションに必要なアトリビュート、入力レコードには含まれていないがアグリゲーション計算には必要なアトリビュート及びHAVINGに必要なアトリビュート、が揃ったという条件を同時に満たした場合に動作することを特徴とするデータベース処理装置。
【請求項７】
請求項１乃至６の何れか１項に記載のデータベース処理装置であって、
前記アグリゲーション結果格納先情報とは、アグリゲーション結果を格納する記憶装置上のアドレスであって間接参照を必要としないアドレスであることを特徴とするデータベース処理装置。
【請求項８】
データの解析処理を実行するデータベース処理装置が行うデータベース処理方法であって、
ジョイン処理の結果を保持すると共に、該ジョイン処理の結果を用いてアグリゲーションの結果の格納先を決定し、該決定した格納先の場所を指す情報であるアグリゲーション結果格納先情報を保持しておき、その後、前記ジョイン処理の結果のインデックスを辿ってアグリゲーション処理を行い、該アグリゲーション結果をアグリゲーション結果格納先情報により特定される格納先に格納することを特徴とするデータベース処理方法。
【請求項９】
請求項８に記載のデータベース処理方法であって、
アグリゲーション結果の格納場所の決定に必要とされるジョイン処理を行い、該ジョイン処理の結果をジョイン結果格納部に格納するジョインステップと、
前記ジョイン処理の結果を用いてアグリゲーションの結果の格納先を決定し、該決定した格納先の場所を指す情報であるアグリゲーション結果格納先情報をアグリゲーション結果格納先情報格納部に格納するアグリゲーション結果格納先決定ステップと、
前記ジョイン結果格納部を参照して、クエリのセレクション処理を行うセレクションステップと、
前記セレクション処理の結果に基づいてアグリゲーション処理を行うと共に、前記アグリゲーション結果格納先情報格納部からアグリゲーション結果格納先情報を得て、該アグリゲーション結果をアグリゲーション結果格納先情報により特定される格納先に格納するアグリゲーション計算ステップと、
を備えることを特徴とするデータベース処理方法。
【請求項１０】
データの解析処理を実行するデータベース処理装置に組み込まれるデータベース処理プログラムであって、
ジョイン処理の結果を保持すると共に、該ジョイン処理の結果を用いてアグリゲーションの結果の格納先を決定し、該決定した格納先の場所を指す情報であるアグリゲーション結果格納先情報を保持しておき、その後、前記ジョイン処理の結果のインデックスを辿ってアグリゲーション処理を行い、該アグリゲーション結果をアグリゲーション結果格納先情報により特定される格納先に格納するデータベース処理装置としてコンピュータを機能させることを特徴とするデータベース処理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データベースの解析処理に関する。
【背景技術】
【０００２】
データベースに関する技術として、解析処理、或いはＯＬＡＰ（Online Analytics Processing）処理と呼ばれる処理が存在する。これらの処理により、企業データのレポートや解析を行うことが可能となる。具体例としては、リテール業者が、ＰＯＳ（Point of sale system）の記録のレポートや解析を行うことで、事業の状況を把握したり、売り上げ向上のために製品配置を工夫したりすることが可能となる。
【０００３】
これらの処理においては、クエリに指示されたアグリゲーションの計算に必要なアトリビュートを持つレコードが挿入され、その後にレコードが更新され、その直後にアグリゲーションを含むデータに対して解析クエリが実行される。もっとも、これらの一連の処理において遅延が生じることがあり問題となっている。この点について詳細に説明する。
【０００４】
以下の（１−１）から（１−８）のステップで解析の準備処理と解析処理が行われる。
【０００５】
（１−１）アグリゲーションの計算に必要なアトリビュートを持つレコードである、入力レコードが挿入あるいは更新される。
【０００６】
（１−２）解析の準備処理を開始する。入力レコードを用いて他のテーブルとのジョイン処理を行って、セレクション項に要求されているアトリビュートを取得する。
【０００７】
（１−３）セレクション処理を行う。
【０００８】
（１−４）セレクションが真であった場合、テーブル間でのジョイン処理を行って、アグリゲーション処理に必要なアトリビュートを取得する。
【０００９】
（１−５）アグリゲーション処理を行う。
【００１０】
（１−６）アグリゲーションの結果をテーブルに保存する。この際に、他のクエリでもこのアグリゲーションの結果を再利用できるようにする。具体的には、他のクエリでセレクションやGROUP BYやHAVINGで用いられる可能性のあるアトリビュートに対するインデックスを作成する。更に、インデックスを辿って、結果を保存する場所を特定、または決定する。
【００１１】
（１−７）解析処理を開始する。
【００１２】
（１−８）アグリゲーション結果が格納されているテーブルからアグリゲーション結果を取得する。
【００１３】
ここで、上記（１−６）の処理、特にインデックスを辿る処理に起因した遅延が問題であった。
【００１４】
この点について、図４を参照して具体例を用いながら説明する。
【００１５】
今回の説明では、顧客からの注文を受け、料金を受け取り、商品を発送する、という業務について、それらの情報を格納するデータベースを例として取り上げる。
【００１６】
ordersテーブルに、ある１セットの注文の情報を格納する。o_orderkeyが注文のID、o_orderdateが発注の年月日に対応する。図４を参照すると今回の例ではo_orderkeyは200であり、o_orderdateは、2011-04-01である。
【００１７】
lineitemテーブルに、注文に含まれる一つ一つの部品の注文の情報を格納する。l_orderkeyが部品のID、l_custkeyが発注者である顧客のID、l_extendedpriceが最終的な価格に対応する。図４を参照すると今回の例ではl_orderkeyは200であり、l_custkeyは100であり、l_extendedpriceは、$200である。また、lineitemのレコードは、l_linenumというID（図示を省略する）を持つ。
【００１８】
次に、customerテーブルに顧客情報を格納する。c_custkeyが顧客のID、c_mktsegementが顧客のマーケットセグメントに対応する。図４を参照すると今回の例ではc_orderkeyは200であり、c_mktsegementは、automotiveである。
【００１９】
今回の説明では、まず、lineitemのレコードを挿入し、次にそれを更新し、最後に解析処理を開始するとする。また、解析処理として、注文日が2011/3/3より後で、自動車のマーケットの注文について、注文年月日ごとに金額の合計を算出する以下のクエリを実行するケースを考える。
【００２０】
＜実行するクエリ＞
SELECT o_orderdate, SUM(l_extendedprice) WHERE l_orderkey = o_orderkey AND o_orderdate > 2011-03-03 and l_custkey = c_custkey and c_mktsegment = automotive GROUP BY o_orderdate;
【００２１】
また、前提として、上述したようにc_custkeyが100、c_mktsegmentがautomotiveのレコードがcustomerテーブルに用意され、o_orderkeyが200、o_orderdateが2011-04-01のレコードがordersテーブルに用意されているとする。
【００２２】
次に、l_orderkeyが200、l_cuskeyが100、のレコードが挿入され、その後にl_extendedpriceが$200に更新されるとする。
【００２３】
更に、解析の準備処理で用いるaggregationテーブルを用意する。このaggregationテーブルでは、セレクションのc_mktsegmentの項のリテラル部が変化したクエリにおいても再利用できるように、c_mktsegmentで分けて値を格納し、c_mktsegmentで辿れるインデックスを作成しておくとする。
【００２４】
ここで、次のステップで解析の準備処理と、解析処理が行われる。
【００２５】
（２−１）lineitemへレコードを挿入し、次にそのレコードを更新する。このレコードを入力レコードと呼ぶ。
【００２６】
（２−２）解析の準備処理を開始する。まず、入力レコードのl_custkeyの値を使って、customerテーブルとジョインする。すなわち、セレクションに必要なc_mktsegmentのアトリビュートを取得する。同様に、orderテーブルとジョインして、セレクションに必要なo_orderdateのアトリビュートを取得する。
【００２７】
（２−３）セレクション処理を行う。すなわち、c_mktsegmentの値がautomotiveであり、o_orderdateが4/1であり3/3より後ろであるので、セレクションの結果は真となる。
【００２８】
（２−４）セレクションの結果が真であったので、入力レコードのl_orderkeyの値を使って、ordersテーブルとジョインする。すなわち、アグリゲーション処理のうち、GROUP BYの処理に必要なアトリビュートo_orderdateを取得する。
【００２９】
（２−５）アグリゲーション処理を行う。
【００３０】
（２−６）アグリゲーションの結果をテーブルに保存する。つまり、c_mktsegmentと、o_orderdateを使ってインデックスを辿る。c_mktsegmentで辿るのは他のクエリで再利用できるようにするため、o_orderdateで辿るのは、GROUP BYの処理がアグリゲーション処理結果をいくつかの行に分けて格納することを要求しているためである。そして、見つけた場所に結果を保存する。
【００３１】
（２−７）解析処理を開始する。
【００３２】
（２−８）c_mktsegmentと、o_orderdateを使ってインデックスをたどり、アグリゲーション結果が格納されている場所を取得する。更に、この場所に保存されている情報を用いて、アグリゲーション結果を取得する。
【００３３】
ここで、ステップ（２−６）、特にインデックスを辿る処理の遅延が課題であった。
【００３４】
この点、上述したような解析クエリの遅延を短縮するための方法として、解析の準備処理段階で中間テーブルにジョイン結果やアグリゲーション結果を格納するという方法がある。この方法を以下の説明では「中間テーブル利用方法」と呼ぶ。
【００３５】
この、中間テーブル利用方法では、中間テーブルにジョイン結果やアグリゲーション結果を格納した後に解析処理を開始して、その中間テーブルを参照して途中結果を再利用する。これにより、解析処理の遅延を削減することができる。この中間テーブルには、例えば、解析クエリを素早く計算できるようなデータ配置を行い、更にインデックスを持たせる。
【００３６】
より詳細に説明すると、解析の準備処理では、複数の解析クエリに対して再利用できる中間テーブルを作成する。すなわち、セレクションやGROUP BYやHAVINGで用いられる可能性のあるアトリビュートに対して行を分割する。そして、更にそれらのアトリビュートに対するインデックスを作成して、クエリごとに、セレクションやGROUP BYやHAVINGの条件に応じて適切な途中結果を再利用できるようにする。
【００３７】
このような中間テーブル利用方法を利用する技術としては、例えば特許文献１乃至３が挙げられる。特許文献１乃至３ではこれらの中間テーブル利用方法を用いた解析処理用データベースに関する技術が記載されている。以下、図５と図６を参照して、これらの解析処理用データベースについて説明する。
【００３８】
図５のブロック図には、代表的な解析処理用データベース５００が表されている。
【００３９】
図５を参照すると、解析処理用データベース５００は、入力格納部５０１、ジョイン部５０２、ジョイン結果格納部５０３、インデックス格納部５０４、テーブル格納部５０５、セレクション部５０６、アグリゲーション計算部５０７、インデックストラバーサル部５０８及びアグリゲーション結果格納部５０９を含む。
【００４０】
そして、入力格納部５０１が入力レコードを格納し、解析準備処理が開始されると、ジョイン部５０２がクエリに指示されたセレクションとアグリゲーションに必要なアトリビュートを取得するためのジョイン処理を行う。その際に、インデックス格納部５０４とテーブル格納部５０５を参照する。そして、ジョインの結果をジョイン結果格納部５０３に格納する。
【００４１】
また、セレクション部５０６がジョイン結果格納部５０３からセレクションに必要なアトリビュートを取得し、セレクション処理を行う。更に、セレクション結果が真の場合、ジョイン結果格納部５０３からアグリゲーションに必要なアトリビュートを取得し、アグリゲーション計算部５０７がアグリゲーション計算を行う。更に、インデックストラバーサル部５０８が、アグリゲーション結果格納部５０９の、アグリゲーション結果を格納するレコードの場所を、インデックス格納部５０４を参照して取得する。そして、アグリゲーション結果格納部５０９にアグリゲーション結果を格納する。解析処理が開始されると、アグリゲーション結果格納部５０９を参照して結果を取得する。
【００４２】
続いて、図６に表される具体例を参照して解析処理用データベース５００が行う処理について更に説明する。
【００４３】
今回の説明では、顧客からの注文を受け、料金を受け取り、商品を発送する、という業務について、それらの情報を格納するデータベースを例として取り上げる。
【００４４】
ordersテーブルに、ある１セットの注文の情報を格納する。o_orderkeyが注文のID、o_orderdateが発注の年月日に対応する。図６を参照すると今回の例ではo_orderkeyは200であり、o_orderdateは、2011-04-01である。
【００４５】
lineitemテーブルに、注文に含まれる一つ一つの部品の注文の情報を格納する。l_orderkeyが部品のID、l_custkeyが発注者である顧客のID、l_extendedpriceが最終的な価格に対応する。図６を参照すると今回の例ではl_orderkeyは200であり、l_custkeyは100であり、l_extendedpriceは、$200である。また、lineitemのレコードは、l_linenumというID（図示を省略する）を持つ。
【００４６】
customerテーブルに顧客情報を格納する。c_custkeyが顧客のID、c_mktsegementが顧客のマーケットセグメントに対応する。図６を参照すると今回の例ではc_orderkeyは200であり、c_mktsegementは、automotiveである。
【００４７】
今回の説明では、まず、lineitemのレコードを挿入し、次にそれを更新し、最後に解析処理を開始するとする。また、解析処理として、注文日が2011/3/3より後で、自動車のマーケットの注文について、注文年月日ごとに金額の合計を算出する以下のクエリを実行するケースを考える。
【００４８】
＜実行するクエリ＞
SELECT o_orderdate, SUM(l_extendedprice) WHERE l_orderkey = o_orderkey AND o_orderdate > 2011-03-03 and l_custkey = c_custkey and c_mktsegment = automotive GROUP BY o_orderdate;
また、前提として、上述のようにc_custkeyが100、c_mktsegmentがautomotiveのレコードがcustomerテーブルに用意され、o_orderkeyが200、o_orderdateが2011-04-01のレコードがordersテーブルに用意されているとする。
【００４９】
次に、l_orderkeyが200、l_cuskeyが100、のレコードが挿入され、その後にl_extendedpriceが$200に更新されるとする。
【００５０】
更に、解析の準備処理で用いるaggregationテーブルを用意する。セレクションのc_mktsegmentの項のリテラル部が変化したクエリにおいても再利用できるように、aggregationテーブルでは、c_mktsegmentで分けて値を格納し、c_mktsegmentで辿れるインデックスを作成しておくとする。
【００５１】
ここで、次のステップで解析の準備処理と、解析処理が行われる。
【００５２】
（３−１）l_orderkeyが200、l_custkeyが100のlineitemのレコードをlineitemに挿入する。次にl_extendedpriceを$200に更新する。このレコードを入力レコードと呼ぶ。
【００５３】
（３−２）解析の準備処理を開始する。入力レコードとcustomerテーブル、ordersテーブルとジョインして、セレクションとアグリゲーションに必要とされるアトリビュートを取得し、joinedテーブルに挿入する。あるいは、これらのアトリビュートをジョイン対象のテーブル上で特定できるIDを取得し、joinedテーブルに挿入する。
【００５４】
（３−３）ジョイン結果を参照して、セレクションに合致していることを確認する。ひとつ前のステップで、アトリビュートの代わりにアトリビュートを指すIDを挿入した場合は、IDを用いてテーブルからアトリビュートを取り出して、その値を用いてセレクションに合致していることを確認する。
【００５５】
（３−４）aggregationテーブルをインデックスによって辿る。つまり、c_mktsegmentと、o_orderdateを使ってインデックスを辿る。c_mktsegmentで辿るのは他のクエリで再利用できるようにするためである。また、o_orderdateで辿るのは、GROUP BYの処理がアグリゲーション処理をいくつかの行に分けて格納することを要求しているためである。
【００５６】
（３−５）見つけた場所にl_extendedpriceの和を足しこむ。
【００５７】
（３−６）解析処理を開始する。c_mktsegmentと、o_orderdateを使ってインデックスを辿り、アグリゲーション結果が格納されている場所を取得する。更に、この場所の情報を用いて、アグリゲーション結果を取得する。
【先行技術文献】
【特許文献】
【００５８】
【特許文献１】特開２００６−６５８４６号公報
【特許文献２】特表２００２−５１００８８号公報
【特許文献３】特開２０００−３３９３９０号公報
【発明の概要】
【発明が解決しようとする課題】
【００５９】
上述したように、特許文献１乃至３等に記載されているような中間テーブル利用方法では、解析の準備処理において、クエリのセレクション処理やアグリゲーション処理に必要なアトリビュートについて、ジョイン結果を事前に実行して、その結果を中間テーブルに格納しておく。そして、解析処理の際に、クエリはジョインを行うことなく、その中間テーブルを参照する。こうすることで、解析処理の際に、セレクション処理やアグリゲーション処理に必要なジョイン処理を省略できて遅延が短縮される。
【００６０】
しかし、アグリゲーション結果を格納する場所を探すステップ（上記のステップ（３−４））で依然インデックスを辿る処理が生じており、この点に起因する遅延については解消できていなかった。
【００６１】
そこで、本発明は、データベースにおける解析処理において、アグリゲーション結果を格納する場所を探すことに起因する遅延を解消し、解析処理の時間を短縮することが可能な解析処理用のデータベース装置、解析処理方法及び解析処理プログラムを提供することを目的とする。
【課題を解決するための手段】
【００６２】
本発明の第１の観点によれば、ジョイン処理の結果を保持すると共に、該ジョイン処理の結果を用いてアグリゲーションの結果の格納先を決定し、該決定した格納先の場所を指す情報であるアグリゲーション結果格納先情報を保持しておき、その後、前記ジョイン処理の結果のインデックスを辿ってアグリゲーション処理を行い、該アグリゲーション結果をアグリゲーション結果格納先情報により特定される格納先に格納することを特徴とするデータベース処理装置が提供される。
【００６３】
本発明の第２の観点によれば、データの解析処理を実行するデータベース処理装置が行うデータベース処理方法であって、ジョイン処理の結果を保持すると共に、該ジョイン処理の結果を用いてアグリゲーションの結果の格納先を決定し、該決定した格納先の場所を指す情報であるアグリゲーション結果格納先情報を保持しておき、その後、前記ジョイン処理の結果のインデックスを辿ってアグリゲーション処理を行い、該アグリゲーション結果をアグリゲーション結果格納先情報により特定される格納先に格納することを特徴とするデータベース処理方法が提供される。
【００６４】
本発明の第３の観点によれば、データの解析処理を実行するデータベース処理装置に組み込まれるデータベース処理プログラムであって、ジョイン処理の結果を保持すると共に、該ジョイン処理の結果を用いてアグリゲーションの結果の格納先を決定し、該決定した格納先の場所を指す情報であるアグリゲーション結果格納先情報を保持しておき、その後、前記ジョイン処理の結果のインデックスを辿ってアグリゲーション処理を行い、該アグリゲーション結果をアグリゲーション結果格納先情報により特定される格納先に格納するデータベース処理装置としてコンピュータを機能させることを特徴とするデータベース処理プログラムが提供される。
【発明の効果】
【００６５】
本発明によれば、データベースにおける解析処理において、アグリゲーション結果を格納する場所を探すことに起因する遅延を解消し、解析処理の時間を短縮することが可能となる。
【図面の簡単な説明】
【００６６】
【図１】本発明の実施形態であるデータベース処理装置の基本的構成を表すブロック図である。
【図２】本発明の実施形態であるデータベース処理装置の基本的動作を表すフローチャートである。
【図３】本発明の実施形態であるデータベース処理装置におけるデータベースのテーブルの一具体例を表す図である。
【図４】背景技術を説明するためのデータベースのテーブルを表す図である。
【図５】一般的な技術におけるデータベース処理装置のブロック図である。
【図６】一般的な技術におけるデータベースのテーブルの一具体例を表す図である。
【発明を実施するための形態】
【００６７】
次に、本発明の実施の形態について図面を参照して詳細に説明する。
【００６８】
《実施の形態》
図１を参照すると、本発明の実施の形態にかかる解析処理用データベース装置１００は、イベントフェーズ検知部１０１と、ジョイン部１０２と、アグリゲーション結果格納先決定部１３１と、ジョイン結果格納部１１１と、アグリゲーション結果格納先情報格納部１１２と、インデックス格納部１１３と、テーブル格納部１１４と、セレクション部１２１と、アグリゲーション結果格納先情報参照部１２３と、アグリゲーション計算部１２２と、アグリゲーション結果格納部１２４とを含む。
【００６９】
イベントフェーズ検知部１０１は、入力レコードからイベントのフェーズを検知する機能を有する。
【００７０】
ジョイン部１０２は、入力レコードを用いてクエリに必要なアトリビュートを揃える機能を有する。
【００７１】
アグリゲーション結果格納先決定部１３１は、アグリゲーションの結果の格納先を決定する機能を有する。
【００７２】
ジョイン結果格納部１１１は、ジョインの結果を格納する記憶装置である。また、アグリゲーション結果格納先情報格納部１１２は、アグリゲーション結果の格納先のアドレスを格納する記憶装置である。更に、インデックス格納部１１３は、テーブルのインデックスを格納する記憶装置である。加えて、テーブル格納部１１４は、入力レコードやジョイン対象のテーブルを格納する記憶装置である。
【００７３】
セレクション部１２１は、クエリによって指示されたセレクションを行う機能を有する。
【００７４】
アグリゲーション結果格納先情報参照部１２３は、アグリゲーション結果の格納先情報を取り出す機能を有する。
【００７５】
アグリゲーション計算部１２２は、アグリゲーションを計算する機能を有する。
【００７６】
アグリゲーション結果格納部１２４は、アグリゲーションの結果を格納する記憶装置である。
【００７７】
解析処理用データベース装置１００は、ハードウェアとして実現することもできるし、ハードウェアとソフトウェアの組合せにより実現できる。具体的には、汎用のサーバやパーソナルコンピュータ又は本実施形態専用の機器、といったコンピュータに、本実施形態特有のプログラムを組み込み、コンピュータが有する演算処理部がこのプログラムに応じた演算処理を行うことにより解析処理用データベース装置１００を実現することができる。
【００７８】
また、解析処理用データベース装置１００が有する各格納部は、例えば、ＨＤＤ（Hard disk drive）やＦｌａｓｈ  ＳＳＤ（Solid State Drive）又はＤＲＡＭ（Dynamic Random Access Memory）等により実現される。また、この記憶装置は汎用のサーバや、パーソナルコンピュータといったコンピュータ内にある必要はなく、外部の記憶装置を利用するようにしてもよい。この場合記憶装置を別のコンピュータとして実現し、バスやＵＳＢ（Universal Serial Bus）規格に準拠したケーブルや、インターネット等の手段を用いて接続するようにしてもよい。また、解析処理用データベース装置１００が有する各格納部は、単一の記憶装置により実現することもできるが、複数の記憶装置により実現してもよい。
【００７９】
また、解析処理用データベース装置１００に含まれる各部は以下のように協働して動作を行う。
【００８０】
つまり、イベントフェーズ検知部１０１が、レコードの挿入や更新のイベントについて、そのレコードを調べる。そして、イベントフェーズ検知部１０１は、アグリゲーションの結果を格納する場所を決めるのに必要なアトリビュートが揃ったフェーズなのか、アグリゲーションに必要なアトリビュートが揃ったフェーズなのかを検知する。
【００８１】
ジョイン部１０２は、アグリゲーションの結果を格納する場所を決めるのに必要なアトリビュートが揃ったフェーズをイベントフェーズ検知部１０１が検知した場合に、クエリに必要なアトリビュートを揃えるためにジョイン処理を行う。そして、ジョイン部１０２は、このジョイン処理を行うために、インデックス格納部１１３とテーブル格納部１１４を参照する。ジョイント処理の結果はジョイン結果格納部１１１に格納する。
【００８２】
アグリゲーション結果格納先決定部１３１は、クエリに指示されたアグリゲーション処理について、アグリゲーション結果の格納先を決定する。ここで格納先とは、アグリゲーション結果格納先情報格納部１１２のアドレスである。更に、アグリゲーション結果格納先決定部１３１は、決定したアドレスに基づいてアグリゲーション結果格納先情報格納部１１２にアグリゲーション結果を格納する。
【００８３】
セレクション部１２１は、ジョイン結果格納部１１１からセレクションの実行に必要なアトリビュートを取得し、セレクションを実行する。
【００８４】
アグリゲーション計算部１２２は、セレクションの結果が真の場合に、ジョイン結果格納部１１１からアグリゲーションに必要なアトリビュートを取得し、アグリゲーション計算を行う。更に、アグリゲーション計算部１２２は、アグリゲーション結果格納先情報参照部１２３を経由して、アグリゲーション結果格納先情報格納部１１２からアグリゲーション結果を格納するアドレスを取得する。そして、アグリゲーション計算部１２２は、アグリゲーション結果を、取得したアドレスに基づいてアグリゲーション結果格納部１２４に格納する。
【００８５】
次に本実施の形態にかかる解析処理用のデータベース装置１００の動作について、図２のフローチャートを参照して説明する。
【００８６】
前提として、解析に必要とされるレコードは、まず挿入されて、その後更新されるものとする。また、挿入されるときに、アグリゲーションの結果を格納する場所が決定できる情報が揃うものとする。また、更新されるときに、アグリゲーションの結果を計算できるものとする。更に、解析のクエリの処理に関係するレコードのことを入力レコードと呼ぶ。
【００８７】
まず、イベントフェーズ検知部１０１が、レコードの挿入や更新のイベントを調べる。続いて、イベントフェーズ検知部１０１が、インデックス格納部１１３に格納されているインデックスを参照し、このインデックスに基づいて、入力レコードをテーブル格納部１１４に格納する（ステップＳ１１００）。
【００８８】
ここで、アグリゲーションの結果を格納する場所を決めるのに必要なアトリビュートが揃った場合は（ステップＳ１１０１においてＹｅｓ）、ステップＳ１１０２に進む。
【００８９】
一方、アグリゲーションの結果を格納する場所を決めるのに必要なアトリビュートが揃わない場合は（ステップＳ１１０１においてＮｏ）、ステップＳ１２０１に進む。
【００９０】
なお、ステップＳ１１０１での判断条件を変更することも可能である。具体的には、アグリゲーションの結果を格納する場所を決めるのに必要なアトリビュートに加えて、セレクションに必要なアトリビュート、入力レコードにはないアグリゲーション計算に必要なアトリビュート及びHAVINGに必要なアトリビュートが揃ったという条件を同時に満たした場合にステップＳ１１０１においてＹｅｓと判断し、ステップＳ１１０２に進むようにしてもよい。
【００９１】
ステップＳ１１０２では、ジョイン部１０２が、入力レコードのアトリビュートに加えて、インデックス格納部１１３及びテーブル格納部１１４を参照することにより、アグリゲーション結果を格納する場所を決めるのに必要なアトリビュートを集める。
【００９２】
また、セレクションに必要なアトリビュート、入力レコードには含まれていないがアグリゲーション計算には必要なアトリビュート、HAVINGに必要なアトリビュートを取得して、ジョイン結果格納部１１１に格納する。
【００９３】
ステップＳ１１０３では、アグリゲーション結果格納先決定部１３１が、アグリゲーション結果を格納する場所を決定し、その場所を指す情報を、アグリゲーション結果格納先情報格納部１１２に保存する。そして、ステップＳ１１００に戻る。ここで、その場所を示す情報とは、アグリゲーション結果格納先情報格納部１１２上のアドレスであって間接参照を必要としないアドレスである。上述したように本実施形態は任意の記憶装置により実現できるため、場所を示す情報は、その記憶装置に応じて変化する。
例えば、ＲＡＭのアドレスでもよいし、フラッシュメモリの物理アドレスでもよいし、ハードディスクドライブの物理アドレスでもよい。
【００９４】
ステップＳ１１００で、イベントトフェーズ検知部１０１が、レコードの挿入や更新のイベントを調べた結果、アグリゲーションを計算するのに必要なアトリビュートが揃った場合は（ステップＳ１２０１においてＹｅｓ）、ステップＳ１２０２に進む。そうでない場合は（ステップＳ１２０１においてＮｏ）、ステップＳ１１００に戻る。
【００９５】
ステップＳ１２０２では、セレクション部１２１が、ジョイン結果格納部１１１から、セレクションに必要なアトリビュートを取得して、セレクションを実行する。このときに、入力レコードのIDを使ってインデックスを辿って取得してもよい。
【００９６】
セレクション結果が真、あるいはセレクション項のリテラルが変更された他のクエリのために結果を格納する場合は（ステップＳ１２０３においてＹｅｓ）、ステップＳ１２０４に進む。それ以外の場合、すなわち、セレクション結果が偽であり、且つ、セレクション項のリテラルが変更された他のクエリのために結果を格納しない場合は（ステップＳ１２０３においてＮｏ）、アルゴリズムを終了する。
【００９７】
ステップＳ１２０４では、アグリゲーション結果格納先情報参照部１２３が、アグリゲーション結果格納先情報格納部１１２から、アグリゲーション結果の格納場所の情報を得る。このときに、ステップＳ１２０２でセレクションに必要なアトリビュートを取得する際のインデックスを辿る操作を、アグリゲーション結果の格納場所の情報を探す際のインデックスを辿る操作と兼用させることができる。このため、グリゲーション結果の格納場所の情報を探すための追加のコストなく、アグリゲーション結果を格納する場所につけられたインデックスを辿る必要もなく、アグリゲーション結果の格納場所の情報を得ることができる。
【００９８】
続いて、アグリゲーション計算部１２２が、ジョイン結果格納部１１１から、必要なアトリビュートを取得し、アグリゲーションを計算し、結果をアグリゲーション結果格納部１２４に格納する（ステップＳ１２０５）。必要なアトリビュートがジョインを必要とする際には、ジョイン処理を行ってもよい。
【００９９】
次に、本実施形態の効果について説明する。
【０１００】
本実施形態は、データベースの解析処理の処理時間を短縮することができる、という効果を奏する。
【０１０１】
その理由は、アグリゲーションを計算し、その結果を格納する場所を探す際に、アグリゲーション結果格納先情報格納部より、間接参照が不要な、格納する場所の情報を得ることができ、更に、これを追加でインデックスを辿らずに得ることができるからである。すなわち、ジョイン結果格納部のインデックスをセレクションの実行のため、あるいはGROUP BYのため、あるいはアグリゲーションの計算自身のため辿る必要があり、この辿る操作をアグリゲーション結果格納場所の情報を探す際のインデックスを辿る操作に兼用できるため、追加で他のインデックスを辿る必要はないためである。
【０１０２】
《実施の形態の具体例》
図１、図２及び図３を参照して、本実施形態にかかるデータベース処理装置１００の具体例を説明する。
【０１０３】
今回の説明では具体例として、顧客からの注文を受け、料金を受け取り、商品を発送する、という業務について、それらの情報を格納するデータベースを取り上げる。
【０１０４】
ordersテーブルに、ある１セットの注文の情報を格納する。o_orderkeyが注文のID、o_orderdateが発注の年月日に対応する。図３を参照すると今回の例ではo_orderkeyは200であり、o_orderdateは、2011-04-01である。
【０１０５】
lineitemテーブルに、注文に含まれる一つ一つの部品の注文の情報を格納する。l_orderkeyが部品のID、l_custkeyが発注者である顧客のID、l_extendedpriceが最終的な価格に対応する。図３を参照すると今回の例ではl_orderkeyは200であり、l_custkeyは100であり、l_extendedpriceは、$200である。また、lineitemのレコードは、l_linenumというID（図示を省略する）を持つ。
【０１０６】
customerテーブルに顧客情報を格納する。c_custkeyが顧客のID、c_mktsegementが顧客のマーケットセグメントに対応する。図３を参照すると今回の例ではc_orderkeyは200であり、c_mktsegementは、automotiveである。
【０１０７】
まず、lineitemのレコードを挿入し、次にそれを更新し、最後に解析処理を開始するとする。
【０１０８】
解析として、注文日が2011/3/3より後で、自動車のマーケットの注文について、注文年月日ごとに金額の合計を算出する以下のクエリを実行するケースを考える。
【０１０９】
＜実行するクエリ＞
SELECT o_orderdate, SUM(l_extendedprice) WHERE l_orderkey = o_orderkey AND o_orderdate > 2011-03-03 and l_custkey = c_custkey and c_mktsegment = automotive GROUP BY o_orderdate;
【０１１０】
更に、解析の準備処理で用意するテーブルでは、セレクションのc_mktsegmentの項のリテラル部が変化したクエリにおいても再利用できるように、c_mktsegmentで分けて値を格納し、c_mktsegmentで辿れるインデックスを作成するとする。
【０１１１】
まず、l_orderkeyが200、l_custkeyが100のlineitemのレコードを挿入する。このレコードを入力レコードと呼ぶ。
【０１１２】
イベントフェーズ検知部１０１が、入力レコードの挿入のイベントを調べる（ステップＳ１１００）。そして、アグリゲーションの結果を格納する場所を決めるのに必要なアトリビュート、セレクションに必要なアトリビュート、入力レコードには含まれていないがアグリゲーション計算には必要なアトリビュート、HAVINGに必要なアトリビュートが揃ったことを検知する（ステップＳ１１０１においてＹｅｓ）。
【０１１３】
ここで、アグリゲーションの結果を格納する場所を決めるのに必要なアトリビュートは、セレクション項のc_mktsegmentと、GROUP BYのo_orderdateである。c_mktsegmentについては、ジョインで取得できるため、l_custkeyがあればよい。o_orderdateについても同様に、l_orderkeyがあればよい。そのため、アグリゲーションの結果を格納する場所を決めるのに必要なアトリビュートは、l_orderkeyと、l_custkeyと分かる。 セレクションに必要なアトリビュートは、同様にl_orderkeyと、l_custkeyである。また、入力レコードにない、アグリゲーション計算に必要なアトリビュートはない。更に、HAVINGに必要なアトリビュートもない。
【０１１４】
また、イベントフェーズ検知部１０１は、入力レコードを、インデックス格納部１１３を利用してテーブル格納部１１４に格納する（ステップＳ１１００）。
【０１１５】
次に、ジョイン部１０２が、入力レコードのアトリビュートに加えて、インデックス格納部１１３及びテーブル格納部１１４を参照することにより、アグリゲーション結果を格納する場所を決めるのに必要なアトリビュートを集める。
【０１１６】
必要なアトリビュートはc_mktsegmentとo_orderdateであり、それぞれcustomerテーブル、orderテーブルとのジョインによって得られる。更に、クエリに必要なアトリビュートをジョインによって取得する。この場合、必要なアトリビュートは、セレクション項のo_orderdateとc_mktsegment、GROUP BYのo_orderdateであるので、追加でジョインで取得する必要はない。更に、これらの値を、ジョイン結果格納部１１１に格納する（ステップＳ１１０２）。
【０１１７】
更に、アグリゲーション結果格納先決定部１３１が、これらの値を用いて、アグリゲーション結果を格納する場所を決定し、その場所を指す情報を、アグリゲーション結果格納先情報格納部１１２に格納する（ステップ１１０３）。今回の説明では、場所を表す情報は、メモリのアドレスとする。アグリゲーションの結果に対しては、セレクションのc_mktsegmentの項のリテラルが変化したクエリにおいても再利用できるように、c_mktsegmentで分けて格納し、c_mktsegmentで辿れるインデックスを作成する。また、GROUP BYの処理がアグリゲーション結果をo_orderdateごとに分けて格納することを要求しているため、o_orderdateで分けて値を格納し、o_orderdateで辿れるインデックスを作成する。
【０１１８】
次に、入力レコードについて、l_extendedpriceが$200に更新される。イベントフェーズ検知部１０１が、入力レコードの更新のイベントを調べる（ステップＳ１１００）。そして、アグリゲーションを計算するのに必要なアトリビュートが揃ったことを検知する（ステップＳ１２０１においてＹｅｓ）。ここで、アグリゲーションを計算するのに必要なアトリビュートは、アグリゲーションにあらわれているl_extendedpriceと、GROUP BYのo_orderdateである。最初のものは入力レコードから、残りはジョイン結果格納部１１１から得られるため、アグリゲーションに必要なアトリビュートが揃ったと判定される。
【０１１９】
次に、セレクション部１２１が、ジョイン結果格納部１１１から、セレクションに必要なアトリビュートを取得し、セレクションを実行する。
【０１２０】
この場合は、入力レコードのIDであるl_linenumを使ってインデックスを辿って、o_orderdateと、c_mktsegmentを取り出す。また、クエリのセレクションの結果は真となる（ステップＳ１２０２）。
【０１２１】
セレクション結果が真であったので、ステップＳ１２０４へ進む（ステップＳ１２０３においてＹｅｓ）。
【０１２２】
次に、アグリゲーション結果格納先情報参照部１２３が、アグリゲーション結果格納先情報格納部１１２から、アグリゲーション結果の格納場所の情報を得る（ステップＳ１２０４）。この例では、ステップＳ１２０２において、セレクションに必要なアトリビュートを取得する際のインデックスを辿る操作を、アグリゲーション結果の格納場所の情報を探す際のインデックスを辿る操作と兼用させることができる。このため、追加のコストなく、アグリゲーション結果の格納場所につけられたインデックスを辿る必要もなく、アグリゲーション結果の格納場所の情報を得ることができる。
【０１２３】
次に、アグリゲーション計算部１２２が、ジョイン結果格納部１１１から、必要なアトリビュートを取得し、アグリゲーションを計算し、結果をアグリゲーション結果格納部１２４に格納する（ステップＳ１２０５）。今回の説明では、$200を加算する。
【０１２４】
《その他の実施の形態》
以上、上述した実施形態は、本発明の好適な実施形態ではあるが、本発明は以上の実施の形態にのみ限定されず、本発明の要旨を逸脱しない範囲においてその他各種の付加変更が可能である。例えば、上述した実施形態において、イベントフェーズを、アグリゲーション結果の格納場所を決定するのに必要なアトリビュートが揃ったフェーズ、セレクションとHAVINGに必要なアトリビュートが揃ったフェーズ、アグリゲーションを計算するのに必要なアトリビュートが揃ったフェーズ、に分ける構成にすることも可能である。
【０１２５】
なお、上記のデータベース処理装置は、ハードウェア、ソフトウェア又はこれらの組合わせにより実現することができる。また、上記のデータベース処理装置により行なわれるデータベース処理方法も、ハードウェア、ソフトウェア又はこれらに組合わせにより実現することができる。ここで、ソフトウェアによって実現されるとは、コンピュータがプログラムを読み込んで実行することにより実現されることを意味する。
【０１２６】
プログラムは、様々なタイプの非一時的なコンピュータ可読媒体(non-transitory computer readable medium)を用いて格納され、コンピュータに供給することができる。非一時的なコンピュータ可読媒体は、様々なタイプの実体のある記録媒体(tangible storage medium)を含む。非一時的なコンピュータ可読媒体の例は、磁気記録媒体（例えば、フレキシブルディスク、磁気テープ、ハードディスクドライブ）、光磁気記録媒体（例えば、光磁気ディスク）、ＣＤ−ＲＯＭ(Read Only Memory)、ＣＤ−Ｒ、ＣＤ−Ｒ／Ｗ、半導体メモリ（例えば、マスクＲＯＭ、ＰＲＯＭ(Programmable ROM)、ＥＰＲＯＭ(Erasable PROM)、フラッシュＲＯＭ、ＲＡＭ(random access memory)）を含む。また、プログラムは、様々なタイプの一時的なコンピュータ可読媒体(transitory computer readable medium)によってコンピュータに供給されてもよい。一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。一時的なコンピュータ可読媒体は、電線及び光ファイバ等の有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給できる。
【０１２７】
上記の実施形態の一部又は全部は、以下の付記のようにも記載されうるが、以下には限られない。
【０１２８】
（付記１）  ジョイン処理の結果を保持すると共に、該ジョイン処理の結果を用いてアグリゲーションの結果の格納先を決定し、該決定した格納先の場所を指す情報であるアグリゲーション結果格納先情報を保持しておき、その後、前記ジョイン処理の結果のインデックスを辿ってアグリゲーション処理を行い、該アグリゲーション結果をアグリゲーション結果格納先情報により特定される格納先に格納することを特徴とするデータベース処理装置。
【０１２９】
（付記２）  付記１に記載のデータベース処理装置であって、
アグリゲーション結果の格納場所の決定に必要とされるジョイン処理を行い、該ジョイン処理の結果をジョイン結果格納部に格納するジョイン部と、
前記ジョイン処理の結果を用いてアグリゲーションの結果の格納先を決定し、該決定した格納先の場所を指す情報であるアグリゲーション結果格納先情報をアグリゲーション結果格納先情報格納部に格納するアグリゲーション結果格納先決定部と、
前記ジョイン結果格納部を参照して、クエリのセレクション処理を行うセレクション部と、
前記セレクション処理の結果に基づいてアグリゲーション処理を行うと共に、前記アグリゲーション結果格納先情報格納部からアグリゲーション結果格納先情報を得て、該アグリゲーション結果をアグリゲーション結果格納先情報により特定される格納先に格納するアグリゲーション計算部と、
を備えることを特徴とするデータベース処理装置。
【０１３０】
（付記３）  付記２に記載のデータベース処理装置であって、
データの解析処理を実行するクエリに対して影響を与えるレコードの、挿入や更新のイベントを調べることによりイベントの内容の検知を行う検知部を更に備え、
前記ジョイン部は、アグリゲーション結果の格納場所の決定ができるイベントを前記検知部が検知した場合に動作し、
前記セレクション部は、アグリゲーションを計算できるイベントを前記検知部が検知した場合に動作することを特徴とするデータベース処理装置。
【０１３１】
（付記４）  付記３に記載のデータベース処理装置であって、
前記検知部が少なくとも、アグリゲーション結果の格納場所の決定に必要なアトリビュート及びアグリゲーションの計算に必要なアトリビュートを、取得するために必要とされるジョインができるイベントであることを検知し、
前期ジョイン部が少なくとも、アグリゲーション結果の格納場所の決定に必要なアトリビュート及びアグリゲーションの計算に必要なアトリビュートを、取得するために必要とされるジョイン処理を行うことを特徴とするデータベース処理装置。
【０１３２】
（付記５）  付記２乃至４の何れか１に記載のデータベース処理装置であって、
前記アグリゲーション結果格納先情報参照部及び前記アグリゲーション計算部は、前記セレクション結果が真、あるいはセレクション項のリテラルが変更された他のクエリのために結果を格納する場合に動作することを特徴とするデータベース処理装置。
【０１３３】
（付記６）  付記２乃至５の何れか１に記載のデータベース処理装置であって、
前記ジョイン部は、アグリゲーションの結果を格納する場所を決めるのに必要なアトリビュートに加えて、セレクションに必要なアトリビュート、入力レコードには含まれていないがアグリゲーション計算には必要なアトリビュート及びHAVINGに必要なアトリビュート、が揃ったという条件を同時に満たした場合に動作することを特徴とするデータベース処理装置。
【０１３４】
（付記７）  付記１乃至６の何れか１に記載のデータベース処理装置であって、
前記アグリゲーション結果格納先情報とは、アグリゲーション結果を格納する記憶装置上のアドレスであって間接参照を必要としないアドレスであることを特徴とするデータベース処理装置。
【０１３５】
（付記８）  データの解析処理を実行するデータベース処理装置が行うデータベース処理方法であって、
ジョイン処理の結果を保持すると共に、該ジョイン処理の結果を用いてアグリゲーションの結果の格納先を決定し、該決定した格納先の場所を指す情報であるアグリゲーション結果格納先情報を保持しておき、その後、前記ジョイン処理の結果のインデックスを辿ってアグリゲーション処理を行い、該アグリゲーション結果をアグリゲーション結果格納先情報により特定される格納先に格納することを特徴とするデータベース処理方法。
【０１３６】
（付記９）  付記８に記載のデータベース処理方法であって、
アグリゲーション結果の格納場所の決定に必要とされるジョイン処理を行い、該ジョイン処理の結果をジョイン結果格納部に格納するジョインステップと、
前記ジョイン処理の結果を用いてアグリゲーションの結果の格納先を決定し、該決定した格納先の場所を指す情報であるアグリゲーション結果格納先情報をアグリゲーション結果格納先情報格納部に格納するアグリゲーション結果格納先決定ステップと、
前記ジョイン結果格納部を参照して、クエリのセレクション処理を行うセレクションステップと、
前記セレクション処理の結果に基づいてアグリゲーション処理を行うと共に、前記アグリゲーション結果格納先情報格納部からアグリゲーション結果格納先情報を得て、該アグリゲーション結果をアグリゲーション結果格納先情報により特定される格納先に格納するアグリゲーション計算ステップと、
を備えることを特徴とするデータベース処理方法。
【０１３７】
（付記１０）  データの解析処理を実行するデータベース処理装置に組み込まれるデータベース処理プログラムであって、
ジョイン処理の結果を保持すると共に、該ジョイン処理の結果を用いてアグリゲーションの結果の格納先を決定し、該決定した格納先の場所を指す情報であるアグリゲーション結果格納先情報を保持しておき、その後、前記ジョイン処理の結果のインデックスを辿ってアグリゲーション処理を行い、該アグリゲーション結果をアグリゲーション結果格納先情報により特定される格納先に格納するデータベース処理装置としてコンピュータを機能させることを特徴とするデータベース処理プログラム。
【符号の説明】
【０１３８】
１００  データベース処理装置
１０１  イベントフェーズ検知部
１０２  ジョイン部
１３１  アグリゲーション結果格納先決定部
１１１  ジョイン結果格納部
１１２  アグリゲーション結果格納先情報格納部
１１３  インデックス格納部
１１４  テーブル格納部
１２１  セレクション部
１２２  アグリゲーション計算部
１２３  アグリゲーション結果格納先情報参照部
１２４  アグリゲーション結果格納部
５００  データベース処理装置
５０１  入力格納部
５０２  ジョイン部
５０３  ジョイン結果格納部
５０４  インデックス格納部
５０５  テーブル格納部
５０６  セレクション部
５０７  アグリゲーション計算部
５０８  インデックストラバーサル部
５０９  アグリゲーション結果格納部
【図１】
2013092873.tif 000003
【図２】
2013092873.tif 000004
【図３】
2013092873.tif 000005
【図４】
2013092873.tif 000006
【図５】
2013092873.tif 000007
【図６】
2013092873.tif 000008