木構造のデータに対する集約計算を行うコンピュータ・システム、並びにその方法及びコンピュータ・プログラム
【課題】ノードを含む木構造のデータに対する集約計算を行うために、インデックスを作成する方法を提供する。
【解決手段】ノードのそれぞれはノードの種類を示す１つのラベル及び０個以上の値を含む。ノードそれぞれに後行順（post-order）でノードｉｄを割り振るノードｉｄ割振部と、ノードそれぞれのノードｉｄと、ノードに含まれる値とを含む１以上の組のデータを有するところの第１のインデックスを作成する第１のインデックス作成部と、ノードそれぞれのノードｉｄと、ノードの少なくとも１つの子孫ノードの間で最小のノードｉｄを有する子孫ノードのノードｉｄとを含む１以上の組のデータを有するところの第２のインデックスを作成する第２のインデックス作成部と、特定の値を含む１以上のノードのノードｉｄを含む１以上の組のデータを有する第３のインデックスを作成する第３のインデックス作成部とを含む。
【解決手段】ノードのそれぞれはノードの種類を示す１つのラベル及び０個以上の値を含む。ノードそれぞれに後行順（post-order）でノードｉｄを割り振るノードｉｄ割振部と、ノードそれぞれのノードｉｄと、ノードに含まれる値とを含む１以上の組のデータを有するところの第１のインデックスを作成する第１のインデックス作成部と、ノードそれぞれのノードｉｄと、ノードの少なくとも１つの子孫ノードの間で最小のノードｉｄを有する子孫ノードのノードｉｄとを含む１以上の組のデータを有するところの第２のインデックスを作成する第２のインデックス作成部と、特定の値を含む１以上のノードのノードｉｄを含む１以上の組のデータを有する第３のインデックスを作成する第３のインデックス作成部とを含む。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、木構造のデータに対する集約計算を行うために、インデックスを作成するコンピュータ・システム、並びにその方法及びコンピュータ・プログラムに関する。さらに、本発明は、木構造のデータに対する集約計算を行うコンピュータ・システム、並びにその方法及びコンピュータ・プログラムに関する。
【背景技術】
【０００２】
リレーショナル・データベース（ＲＤＢ）における「ＧＲＯＵＰ ＢＹ」及び「ＨＡＶＩＮＧ」などとともに、集約関数を使用して値を集計するという操作が、検索及びデータベースの諸分野に見られる。該集計を効率的に行なうために、様々なインデックス及びデータフォーマットが提案されている。
【０００３】
従来の手法は、汎用的な検索及び集約に対して成果を挙げている。しかし、該手法は、集約のために冗長なデータを持っている。そのために、該手法は、大規模データに対するパフォーマンスに難がある。
【０００４】
また、ＲＤＢで一般的なＢ−ｔｒｅｅ（Ｂ＋−ｔｒｅｅ）を用いた集約についても、検索条件が緩いとき、例えばデータ全体の５０％が集計対象の場合などにおいて処理が遅いという問題がある。
【０００５】
下記特許文献１は、「Ｌａｙｅｒｅｄ Ｉｎｄｅｘ」及び「Ｐａｔｒｉｃｉａ Ｔｒｅｅ」という二種類の既存の木構造インデックスを組み合わせたインデックス構造を記載する。しかし、該インデックス構造は、検索のためにノードの数を絞り込むときには有効であるが、大量のノードを処理する必要がある場合に不向きである。また、下記特許文献２は、データフォーマットについて従来のＲＤＢのものを用いている。
【０００６】
【特許文献１】米国特許第７，２８７，０３３号明細書
【特許文献２】米国特許第７，３３０，８４８号明細書
【発明の開示】
【発明が解決しようとする課題】
【０００７】
検索及びデータベースの諸分野において、値を効率的に集計する手法が求められている。
【課題を解決するための手段】
【０００８】
本発明は、少なくとも１つのノードを含む少なくとも１つの木構造のデータに対する集約計算を行うために、インデックスを作成するコンピュータ・システムを提供する。上記ノードのそれぞれは該ノードの種類を示す１つのラベル及び任意の数の値（value）を含む。任意の数は、０個以上である。上記コンピュータ・システムは、
上記ノードそれぞれに後行順（post-order）でノードｉｄを割り振るノードｉｄ割振部と、
上記ノードそれぞれのノードｉｄと、該ノードに含まれる値とを含む１以上の組のデータを有するところの第１のインデックスを作成する第１のインデックス作成部であって、該１以上の組のデータは上記ラベル毎に作成される、上記第１のインデックス作成部と、
上記ノードそれぞれのノードｉｄと、該ノードの少なくとも１つの子孫ノードの間で最小のノードｉｄを有する子孫ノードのノードｉｄとを含む１以上の組のデータを有するところの第２のインデックスを作成する第２のインデックス作成部であって、該１以上の組のデータは上記ラベル毎に作成される、上記第２のインデックス作成部と、
特定の値を含む１以上のノードのノードｉｄを含む１以上の組のデータを有する第３のインデックスを作成する第３のインデックス作成部であって、該１以上の組のデータは上記ラベル毎の上記特定の値毎に作成される、上記第３のインデックス作成部と
を含む。集約計算を行うための検索式の結果が、上記作成し第１、第２及び第３のインデックスに基づいて、求められる。上記検索式は例えば、値、又は該値及びその頻度を集計する。特に、上記検索式は、所与のラベルを持つノードを集計単位として、該ノードの値、又は該値及びその頻度を集計する。
【０００９】
本発明の１つの実施態様では、上記第１のインデックスが、上記ノードそれぞれのノードｉｄと、該ノードに含まれる値とを含む組のデータをシーケンシャルに格納したファイルである。
【００１０】
本発明の１つの実施態様では、上記ノードそれぞれのノードｉｄと、該ノードの少なくとも１つの子孫ノードの間で最小のノードｉｄを有する子孫ノードのノードｉｄとを含む組のデータをシーケンシャルに格納したファイルであるである。
【００１１】
本発明の１つの実施態様では、上記第３のインデックスが、上記特定の値を含む１以上のノードのノードｉｄを含む１以上の組のデータをシーケンシャルに格納したファイルである。
【００１２】
本発明の１つの実施態様では、上記コンピュータ・システムはさらに、上記ラベルのそれぞれにラベルｉｄを割り振るラベルｉｄ割振部をさらに含む。
【００１３】
本発明の１つの実施態様では、上記コンピュータ・システムはさらに、上記ノードそれぞれのノードｉｄと、該ノードｉｄそれぞれに関連付けられたポインタとを含む組のデータが格納されている第４のインデックス作成部を含む。上記ポインタは上記第１のインデックスを成す上記１以上の組のデータにおけるノードｉｄのデータの位置を示す。
【００１４】
本発明はまた、少なくとも１つのノードを含む少なくとも１つの木構造のデータに対する集約計算を行うためのコンピュータ・システムを提供する。上記ノードのそれぞれは該ノードの種類を示す１つのラベル及び任意の数の値を含む。任意の数は、０個以上である。上記ノードのそれぞれは後行順（post-order）でノードｉｄを割り振られている。上記コンピュータ・システムは、
集約計算を行うための検索式を受信する受信部と
上記検索式の検索対象である値を用い及び、特定の値を含む１以上のノードのノードｉｄを含む１以上の組のデータを有するインデックスを用いて、上記検索式の検索対象である上記値を有する１以上のノードのノードｉｄを含む第１のリストを取得する第１のリスト取得部であって、該１以上の組のデータは上記ラベル毎の上記特定の値毎に作成される、上記第１のリスト取得部と、
上記取得した第１のリストを用い及び、上記ノードそれぞれのノードｉｄと、該ノードの少なくとも１つの子孫ノードの間で最小のノードｉｄを有する子孫ノードのノードｉｄとを含む１以上の組のデータを有するところのインデックスを用いて、上記検索式の検索対象である上記値を有する１以上のノードを子孫に持つ各木構造のルート・ノードの１以上のルート・ノードｉｄを含む第２のリストを取得する第２のリスト取得部であって、該１以上の組のデータは上記ラベル毎に作成される、上記第２のリスト取得部と、
上記取得した第２のリストに基づいて、上記検索式の検索対象である上記値を検索する検索部であって、上記検索式の検索対象である上記値が少なくとも１つのキーワードに対応する、上記検索部と
を含む。
【００１５】
本発明の１つの実施態様では、上記コンピュータ・システムはさらに、
上記取得した第２のリストを用いて及び、上記ノードそれぞれのノードｉｄと、該ノードに含まれる値とを含む１以上の組のデータを有するところのインデックスを用いて、上記検索式の検索条件を満たす、１以上のノードの１以上の値を含む第３のリストを取得する第３のリスト取得部であって、該１以上の組のデータは上記ラベル毎に作成される、上記第３のリスト取得部と、
上記取得した第３のリストに基づいて、上記検索式の結果を求める計算部と
を含む。
【００１６】
本発明はまた、中央演算処理ユニット、メモリー及び木構造のデータを記憶する記憶部を有するコンピュータ・システムにおいて、少なくとも１つのノードを含む少なくとも１つの木構造のデータに対する集約計算を行うために、インデックスを作成する方法を提供する。上記ノードそれぞれは、該ノードの種類を示す１つのラベル及び任意の数の値を含む。任意の数は、０個以上である。上記方法が、上記中央演算処理ユニットに下記ステップを実行させることを含む。該ステップは、
上記ノードの情報を上記メモリー内に読み込み、上記情報を読み込んだノードそれぞれに後行順（post-order）でノードｉｄを割り振るステップと、
上記ノードそれぞれのノードｉｄと、該ノードに含まれる値とを含む１以上の組のデータを有するところの第１のインデックスを作成し、該作成した第１のインデックスを上記記憶部に格納するステップであって、該１以上の組のデータは上記ラベル毎に作成される、上記第１のインデックスを格納するステップと、
上記ノードそれぞれのノードｉｄと、該ノードの少なくとも１つの子孫ノードの間で最小のノードｉｄを有する子孫ノードのノードｉｄとを含む１以上の組のデータを有するところの第２のインデックスを作成し、該作成した第２のインデックスを上記記憶部に格納するステップであって、該１以上の組のデータは上記ラベル毎に作成される、上記第２のインデックスを格納するステップと、
特定の値を含む１以上のノードのノードｉｄを含む１以上の組のデータを有する第３のインデックスを作成し、該作成した第３のインデックスを上記記憶部に格納するステップであって、該１以上の組のデータは上記ラベル毎の上記特定の値毎に作成される、上記第３のインデックスを格納するステップと
を含む。集約計算を行うための検索式の結果が、上記作成し第１、第２及び第３のインデックスに基づいて、求められる。
【００１７】
本発明の１つの実施態様では、上記第１のインデックスを上記記憶部に格納するステップが、上記ノードそれぞれのノードｉｄと、該ノードに含まれる値とを含む組のデータをシーケンシャルに格納するステップをさらに含む。
【００１８】
本発明の１つの実施態様では、上記第２のインデックスを上記記憶部に格納するステップが、上記ノードそれぞれのノードｉｄと、該ノードの少なくとも１つの子孫ノードの間で最小のノードｉｄを有する子孫ノードのノードｉｄとを含む組のデータをシーケンシャルに格納するステップをさらに含む。
【００１９】
本発明の１つの実施態様では、上記第３のインデックスを上記記憶部に格納するステップが、上記特定の値を含む１以上のノードのノードｉｄを含む１以上の組のデータをシーケンシャルに格納するステップをさらに含む。
【００２０】
本発明の１つの実施態様では、上記方法が、上記中央演算処理ユニットに下記ステップをさらに実行させることを含む。該ステップは、上記ラベルのそれぞれにラベルｉｄを割り振るステップを含む。
【００２１】
本発明の１つの実施態様では、上記方法が、上記中央演算処理ユニットに下記ステップをさらに実行させることを含む。該ステップは、
上記第１のインデックスにおける値又は上記第３のインデックスにおけるノードｉｄを圧縮するステップを含む。
【００２２】
本発明の１つの実施態様では、上記方法が、上記中央演算処理ユニットに下記ステップをさらに実行させることを含む。該ステップは、上記第１のインデックスを作成する前に、上記値が文字列である場合、該文字列を数値に置き換えるステップを含む。
【００２３】
本発明の１つの実施態様では、上記方法が、上記中央演算処理ユニットに下記ステップをさらに実行させることを含む。該ステップは、上記第３のインデックスを作成した後に、上記置き換えられた数値を、上記文字列にさらに置き換えるステップを含む。
【００２４】
本発明の１つの実施態様では、上記方法が、上記中央演算処理ユニットに下記ステップをさらに実行させることを含む。該ステップは、上記ノードそれぞれのノードｉｄと、該ノードｉｄそれぞれに関連付けられたポインタとを含む組のデータが格納されている第４のインデックスを作成するステップを含む。上記ポインタは上記第１のインデックスを成す上記１以上の組のデータにおけるノードｉｄのデータの位置を示す。
【００２５】
本発明はまた、中央演算処理ユニット、メモリー及び木構造のデータを記憶する記憶部を有するコンピュータ・システムにおいて、少なくとも１つのノードを含む少なくとも１つの木構造のデータに対する集約計算を行うために、インデックスを作成するためのコンピュータ・プログラムを提供する。上記コンピュータ・プログラムは、上記中央演算処理ユニットに上記に記載の各ステップを実行させることを含む。
【００２６】
本発明はまた、中央演算処理ユニット、メモリー及び上記木構造のデータを記憶する記憶部を有するコンピュータ・システムにおいて、少なくとも１つのノードを含む少なくとも１つの木構造のデータに対する集約計算を行う方法を提供する。上記ノードそれぞれは該ノードの種類を示す１つのラベル及び任意の数の値を含む。任意の数は、０個以上である。上記ノードそれぞれは、後行順（post-order）でノードｉｄを割り振られている。上記方法が中央演算処理ユニットに下記ステップを実行させるステップを含む。該ステップが、
集約計算を行うための検索式を受信し、該受信した検索式を上記メモリー内に記憶するステップと、
上記検索式の検索対象である値を用い及び、特定の値を含む１以上のノードのノードｉｄを含む１以上の組のデータを有するインデックスを用いて、上記検索式の検索対象である上記値を有する１以上のノードのノードｉｄを含む第１のリストを取得し、該取得した第１のリストを上記記憶部に記憶するステップであって、該１以上の組のデータは上記ラベル毎の上記特定の値毎に作成される、上記第１のリストを記憶するステップと、
上記取得した第１のリストを用い及び、上記ノードそれぞれのノードｉｄと、該ノードの少なくとも１つの子孫ノードの間で最小のノードｉｄを有する子孫ノードのノードｉｄとを含む１以上の組のデータを有するところのインデックスを用いて、上記検索式の検索対象である上記値を有する１以上のノードを子孫に持つ各木構造のルート・ノードの１以上のルート・ノードｉｄを含む第２のリストを取得し、該取得した第２のリストを上記記憶部に記憶するステップであって、該１以上の組のデータは上記ラベル毎に作成される、上記第２のリストを記憶するステップと、
上記取得した第２のリストに基づいて、上記検索式の検索対象である上記値を検索するステップであって、上記検索式の検索対象である上記値が少なくとも１つのキーワードに対応する、上記検索するステップと
を含む。
【００２７】
本発明の１つの実施態様では、上記方法が、上記中央演算処理ユニットに下記ステップをさらに実行させることを含む。該ステップは、
上記取得した第２のリストを用い及び、上記ノードそれぞれのノードｉｄと、該ノードに含まれる値とを含む１以上の組のデータを有するところのインデックスを用いて、上記検索式の検索条件を満たす、１以上のノードの１以上の値を含む第３のリストを取得し、該取得した第３のリストを上記記憶部に記憶するステップであって、該１以上の組のデータは上記ラベル毎に作成される、上記第３のリストを記憶するステップと、
上記取得した第３のリストに基づいて、上記検索式の結果を求めるステップと
を含む。
【００２８】
本発明の１つの実施態様では、上記第３のリストが、上記ノードそれぞれのノードｉｄと、該ノードに含まれる値とを含む１以上の組のデータを有するところのインデックスを用いてシーケンシャルアクセスにより取得される。
【００２９】
本発明の１つの実施態様では、上記第３のリストが、上記ノードそれぞれのノードｉｄと、該ノードに含まれる値とを含む１以上の組のデータを有するところのインデックス、及び上記ノードそれぞれのノードｉｄと、該ノードｉｄそれぞれに関連付けられたポインタとを含む組のデータが格納されているインデックスを用いてランダムアクセスにより取得される。
【００３０】
本発明の１つの実施態様では、上記第３のリストの一部が、上記ノードそれぞれのノードｉｄと、該ノードに含まれる値とを含む１以上の組のデータを有するところのインデックスを用いてシーケンシャルアクセスにより取得され、及び
上記第３のリストの残りが、上記ノードそれぞれのノードｉｄと、該ノードに含まれる値とを含む１以上の組のデータを有するところのインデックス、及び上記ノードそれぞれのノードｉｄと、該ノードｉｄそれぞれに関連付けられたポインタとを含む組のデータが格納されているインデックスを用いてランダムアクセスにより取得され、
上記第３のリストが、上記シーケンシャルアクセスと上記ランダムアクセスとを切り替えることによって取得される。
【００３１】
本発明はまた、中央演算処理ユニット、メモリー及び木構造のデータを記憶する記憶部を有するコンピュータ・システムにおいて、少なくとも１つのノードを含む少なくとも１つの木構造のデータに対する集約計算を行うためのコンピュータ・プログラムを提供する。上記コンピュータ・プログラムは、中央演算処理ユニットに上記方法に記載の各ステップを実行させることを含む。
【００３２】
本発明はまた、中央演算処理ユニット、メモリー及び木構造のデータを記憶する記憶部を有するコンピュータ・システムにおいて、少なくとも１つのノードを含む少なくとも１つの木構造のデータに対する集約計算を行う方法を提供する。上記ノードそれぞれは該ノードの種類を示す１つのラベル及び任意の数の値を含む。任意の数は、０個以上である。上記方法が、上記中央演算処理ユニットに下記ステップを実行させることを含む。該ステップが、
上記ノードの情報を上記メモリー内に読み込み、上記情報を読み込んだノードそれぞれに後行順（post-order）でノードｉｄを割り振るステップと、
上記ノードそれぞれのノードｉｄと、該ノードに含まれる値とを含む１以上の組のデータを有するところの第１のインデックスを作成し、該作成した第１のインデックスを上記記憶部に格納するステップであって、該１以上の組のデータは上記ラベル毎に作成される、上記第１のインデックスを格納するステップと、
上記ノードそれぞれのノードｉｄと、該ノードの少なくとも１つの子孫ノードの間で最小のノードｉｄを有する子孫ノードのノードｉｄとを含む１以上の組のデータを有するところの第２のインデックスを作成し、該作成した第２のインデックスを上記記憶部に格納するステップであって、該１以上の組のデータは上記ラベル毎に作成される、上記第２のインデックスを格納するステップと、
特定の値を含む１以上のノードのノードｉｄを含む１以上の組のデータを有する第３のインデックスを作成し、該作成した第３のインデックスを上記記憶部に格納するステップであって、該１以上の組のデータは上記ラベル毎の上記特定の値毎に作成される、上記第３のインデックスを格納するステップと、
上記メモリー内に記憶した集約計算を行うための検索式の検索対象である値及び上記第３のインデックスを用いて、上記検索式の検索対象である上記値を有する１以上のノードのノードｉｄを含む第１のリストを取得し、該取得した第１のリストを上記記憶部に記憶するステップと、
上記取得した第１のリスト及び上記第２のインデックスを用いて、上記検索式の検索対象である上記値を有する１以上のノードを子孫に持つ各木構造のルート・ノードの１以上のルート・ノードｉｄを含む第２のリストを取得し、該取得した第２のリストを上記記憶部に記憶するステップと、
上記取得した第２のリスト及び上記第１のインデックスを用いて、上記検索式の検索条件を満たす、１以上のノードの１以上の値を含む第３のリストを取得し、該取得した第３のリストを上記記憶部に記憶するステップと、
上記取得した第３のリストに基づいて、上記検索式の結果を求めるステップと
を含む。
【発明の効果】
【００３３】
本発明の実施態様によると、木構造のノードに含まれる値及び該値の頻度を高速に集計することが可能になる。該値は、集約計算を行うための検索式におけるキーワードに対応する。また、本発明の実施態様によると、大量のデータを木構造により扱うことが可能になる。
【発明を実施するための最良の形態】
【００３４】
以下、図面に従って、本発明の実施態様を説明する。本実施態様は、本発明の好適な態様を説明するためのものであり、本発明の範囲をここで示すものに限定する意図はないことを理解されたい。また、以下の図を通して、特に断らない限り、同一の符号は、同一の対象を指す。
【００３５】
コールセンターでは、オペレータが、顧客からの問い合わせを受けて応答を行う。コールセンターのシステムは、顧客からの問い合わせ及び該問い合わせに対する応答をログ・データとして記録しうる。ログ・データを分析し活用しようという試みは、データマイニングの分野で見られうる。例えば、「顧客からの問い合わせが、「ＸＸＸウイルス」という言葉を含む場合に、オペレータによって多く照会された言葉は、「Ａ」及び「Ｂ」のどちらなのかを求める」という分析、或いは「問い合わせと応答で使用される動詞の違いを求める」という分析が考えられる。ログ・データに記録された会話文などの文書は、多くの場合、文書に含まれる文及び単語などの任意の部分をノードとする木構造で表すことができる。木構造を集めたものは、ある問題を解決するための情報の一つになりうる。例えば、コールセンターのログ・データを表した木構造を集めたものは、過去に受けた問い合わせ及び応答の集合である。よって、オペレータがこれから発生しうる問い合わせについて応答をする際に、上記木構造を集めたものが情報として利用されうる。ログ・データに記録された会話文などの文書を木構造で表すために、自然言語処理（Natural Language Processing：ＮＬＰ）と呼ばれる技術が用いられうる。ＮＬＰとは、自然言語で記述されたテキストから、単語及び単語間の依存関係などの情報を抽出する技術である。ＮＬＰ処理によってログ・データから抜き出された単語および単語間の依存関係などの情報は、木構造に任意の方法でマッピングされうる。
【００３６】
図１Ａ及び図１Ｂは、本発明の実施態様である、ＮＬＰを用いてログ・データを処理する方法を示す。
図１Ａは、コールセンターにおけるログ・データ（１００）の例を示す。ログ・データ（１００）では、顧客からの問い合わせがＱ及びオペレータの応答がＡとして示される。
図１Ａはまた、上記ログ・データ（１００）にマークアップ言語のタグを付加したデータ（１０１）の例を示す。該タグは、ログ・データ（１００）に木構造を与えるために付加される。マークアップ言語として、例えばＸＭＬ（Extensible Markup Language）が使用されうる。タグは、ユーザーによって任意に設定されうる。タグ＜Document＞及び＜/Document＞は、該ログ・データ（１００）の種類を示す。タグ＜Q＞及び＜/Q＞は、質問部分であることを示す。タグ＜A＞及び＜/A＞は、回答部分であることを示す。
図１Ｂは、ＮＬＰを使用して該ログ・データ（１００）から文及び／又は単語を抜き出したデータ（１０２）を示す。ＮＬＰ処理を実施するためのソフトウェア技術は例えば、ＵＩＭＡ（Unstructured Information Management Architecture）である。データ（１０２）では、ログ・データ（１００）のうち、ＮＬＰ処理により抜き出された個所の前後にタグが付加されている。タグ＜expression_desire＞及び＜/expression_desire＞は、願望の表現を含む部分であることを示す。タグ＜noun＞及び＜/noun＞は、名詞を含む部分であることを示す。タグ＜verb＞及び＜/verb＞は、動詞を含む部分であることを示す。タグ＜proper_noun＞及び＜/proper_noun＞は、固有名詞を含む部分であることを示す。
図１Ｂはまた、データ（１０２）からＮＬＰ処理により抜き出されなかった個所を除いたデータ（１０３）の例を示す。データ（１０３）が、下記に述べる木構造のデータを作成するために使用されうる。
なお、データ（１０２、１０３）は、ＮＬＰ処理により抜き出されたデータのフォーマットの一例であり、図示した構造を必ずしもとるものではない。上記ＮＬＰ処理は、コールセンターのログ・データに限らず、さまざまな文書についても応用することができる。
【００３７】
図２は、本発明の実施態様である、２つの木構造（２００Ａ及び２００Ｂ）の例を示す。
木構造は、少なくとも１つのノードを含む。ノードは、ユニットともいう。木構造について、図２の木構造（２００Ａ）を用いて説明する。木構造（２００Ａ）は、ルート・ノード（２１６）及び複数のノード（２１０〜２１５）を有する。同様に、木構造（２００Ｂ）は、ルート・ノード（２２７）及び複数のノード（２２０〜２２６）を有する。各ノード（２０１）は、リンク（２０６）で結ばれる。リンクで結ばれたノード（２０１）のうち、上方に存在するノードを親ノードといい、一方下方に存在するノードを子ノードという。例えば、ノード（２１０）の親ノードは、ノード（２１４）である。例えば、ノード（２１６）の子ノードは、ノード（２１３〜２１５）である。ある親ノードから見て、子ノード、子ノードの子ノード（孫ノードである）、・・・、及び最下方に存在する子ノードをまとめて子孫ノードという。例えば、ノード（２１６）の子孫ノードは、ノード（２１０〜２１５）である。ノード（２０１）は、０個以上の子ノードを持ちうる。ノード（２０１）のうち、最上流のノードをルート・ノード（２０２）という。
【００３８】
ノード（２０１）は、データとして、セクション（２０３）及び値（２０４）を含む。
セクション（２０３）は、ノード（２０１）の種類を示すラベルである。ラベルは、ノード（２０１）毎に１つ割り当てられる。例として、ノード（２１０、２１２）のセクションには、ラベル“Ｎｏｕｎ”が割り当てられている。同様に、ノード（２１１）のセクションには、ラベル“Ｖｅｒｂ”が割り当てられている。ルート・ノード（２０２）に割り当てるセクションがない場合には、仮想のセクション（２０５）が割り当てられる。
値（２０４）は、数値、文字列、又はそれらの組み合わせを含む。１つのノード（２０１）は、０個以上の値（２０４）を含む。例として、ノード（２１３）の値は、２００７１１１２の１つであり、ノード（２１２）の値は、“Ｉｎｔｅｒｎｅｔ”及び“ｍｏｄｅｍ”の２つである。また、ノード（２１４）は値を有しないので、０個の値を含む。０個の値は、ＮＵＬＬ又は空白で表現されうる。
【００３９】
図２の木構造のデータは、上記ログ・データを木構造のデータに変換した一例を示す。木構造（２００Ａ、２００Ｂ）のそれぞれが、ログ・データ（１００）の文書を表す。
木構造（２００Ａ、２００Ｂ）のルート・ノード（２１６、２２７）の仮想セクション（２０５）は、該木構造が“ＤＯＣＵＭＥＮＴ”についてのものであることを示す。木構造（２００Ａ、２００Ｂ）のノード（２０１）それぞれが、木構造（２００Ａ、２００Ｂ）の文書の持つ情報を示す。例えば、セクションが“Ｄａｔｅ”のノード（２１３、２２３）は、文書の作成日の情報を持つことを示す。文書の作成日は、値として示される。また、セクションが“Ｑｕｅｓｔｉｏｎ”であるノード（２１４、２２４及び２２５）は、顧客からの問い合わせ内容の情報を持つことを示す。ただし、木構造（２００Ａ、２００Ｂ）では、セクションが“Ｑｕｅｓｔｉｏｎ”であるノード（２１４、２２４及び２２５）それ自体は、顧客からの問い合わせの内容を値として持たない。“Ｑｕｅｓｔｉｏｎ”のノード（２１４、２２４及び２２５）は、顧客からの問い合わせの内容をさらに種類ごとに細分化した子ノード（それぞれ２１０〜２１１、２２０及び２２１）を持つからである。例えば、子ノード（２１０〜２１１、２２０及び２２１）のうち、セクションが“Ｎｏｕｎ”であるノード（２１０、２２０及び２２１）は、問い合わせに含まれる名詞を値として持つ。セクションが“Ｖｅｒｂ”であるノード（２１１及び２２２）は、問い合わせに含まれる動詞を値として持つ。木構造のデータを作成する際に値に保存する対象はキーワードでありうる。キーワードは、問い合わせの本文中からＮＬＰ処理などの技術を用いて抽出される。抽出の方法は、慣用の方法を使用しうる。例えば、単語の出現頻度を解析して抽出する方法、大規模な単語リストを用いて抽出する方法、及び文の構造を解析して抽出する方法が用いられうる。
【００４０】
図２の木構造（２００Ａ、２００Ｂ）のデータを用いて、集約計算を説明する。
集約計算とは、与えられた任意のセクションを持つノードを集計単位として、値を集計することを意味する。集計単位とは、木構造においてノードの子孫ノードに同じ値が何回出現しても１回とカウントする基準である。集計とは例えば、値について、値及びその出現回数（頻度ともいう）の組を頻度の降順若しくは昇順に出力する処理、又は任意の集合関数を用いて計算する処理をいう。任意の集合関数は例えば、ｃｏｕｎｔ（件数）、ｓｕｍ（合計）、ｍｉｎ（最小値）、ｍａｘ（最大値）及びａｖｇ（平均）であり、ユーザーが独自に定義した関数も含みうる。
【００４１】
図３の表（３００）は、下記検索条件において、値及び頻度を降順に出力した結果を示す。
検索条件：図２の各木構造（２００Ａ、２００Ｂ）について、セクションが“Ｄｏｃｕｍｅｎｔ”であるノード（２１６、２２７）を集計単位として、セクションが“Ｎｏｕｎ”であるノード（２１０、２１２、２２０、２２１）に含まれる値及びその頻度を降順に出力する。
以下に、上記検索条件による結果を導くプロセスを示す。
最初に、ルート・ノード（２１６）を集計単位のノードとした場合を考える。集計単位であるルート・ノード（２１６）の子孫ノードであり且つセクションが“Ｎｏｕｎ”であるノードは、ノード（２１０、２１２）の２つである。ノード（２１０）の値は、“Ｉｎｔｅｒｎｅｔ”、“ＰＣ”及び“ｐｈｏｎｅ”である。ノード（２１２）の値は、“Ｉｎｔｅｒｎｅｔ”及び“ｍｏｄｅｍ”である。よって、ルート・ノード（２１６）を集計単位のノードとした場合、発生した値は、“Ｉｎｔｅｒｎｅｔ”、“ＰＣ”、“ｐｈｏｎｅ”及び“ｍｏｄｅｍ”である。ここで、“Ｉｎｔｅｒｎｅｔ”は、ノード（２１０）及びノード（２１２）の両方に重複して出現する。しかし、いずれのノード（２１０、２１２）も集計単位となるルート・ノード（２１６）の子孫ノードであるので、値“Ｉｎｔｅｒｎｅｔ”の出現回数は１回と数えられる。
次に、ルート・ノード（２２７）を集計単位のノードとした場合を考える。集計単位であるルート・ノード（２２７）の子孫ノードであり且つセクションが“Ｎｏｕｎ”であるノードは、ノード（２２０、２２１）の２つである。 ノード（２２０）の値は、“Ｉｎｔｅｒｎｅｔ”及び“ｐｈｏｎｅ”である。ノード（２２１）の値は、“Ｉｎｔｅｒｎｅｔ”及び“ｍｏｄｅｍ”である。よって、ルート・ノード（２２７）を集計単位のノードとした場合、発生した値は、“Ｉｎｔｅｒｎｅｔ”、“ｐｈｏｎｅ”及び“ｍｏｄｅｍ”である。ここで、“Ｉｎｔｅｒｎｅｔ”は、ノード（２２０）及びノード（２２１）の両方に重複して出現する。しかし、いずれのノード（２２０、２２１）も集計単位となるルート・ノード（２２７）の子孫ノードであるので、値“Ｉｎｔｅｒｎｅｔ”の出現回数は１回と数えられる。
以上より、セクションが“Ｄｏｃｕｍｅｎｔ”であるルート・ノード（２１６、２２７）を集計単位として、セクションが“Ｎｏｕｎ”であるノード（２１０、２１２、２２０、２２１）に含まれる値及びその頻度を求めた場合、値“Ｉｎｔｅｒｎｅｔ”が２回であり、値“ｍｏｄｅｍ”が２回であり、値“ｐｈｏｎｅ”が２回であり、及び値“ＰＣ”が１回である。
上記例では、ルート・ノードを集計単位のノードとして考えたが、それ以外のノードの場合にも、上記プロセスが適用される。下記にその例を示す。
【００４２】
図３の表（３０１）は、下記検索条件において、値及びその頻度を降順に出力した結果を示す。以下に、該結果を導くプロセスを示す。
検索条件：図２の各木構造（２００Ａ、２００Ｂ）について、セクションが“Ｑｕｅｓｔｉｏｎ”であるノード（２１４、２２４、２２５）を集計単位として、セクションが“Ｎｏｕｎ”であるノード（２１０、２１２、２２０、２２１）に含まれる値及びその頻度を降順に出力する。
最初に、集計単位となるノードの１つであるノード（２１４）の子孫ノードであり且つセクションが“Ｎｏｕｎ”であるノードは、ノード（２１０）である。ノード（２１０）の値は、“Ｉｎｔｅｒｎｅｔ”、“ＰＣ”及び“ｐｈｏｎｅ”である。
次に、集計単位となるノードの１つであるノード（２２４）の子孫ノードであり且つセクションが“Ｎｏｕｎ”であるノードは、ノード（２２０）である。ノード（２２０）の値は、“Ｉｎｔｅｒｎｅｔ”及び“ｐｈｏｎｅ”である。
最後に、集計単位となるノードの１つであるノード（２２５）の子孫ノードであり且つセクションが“Ｎｏｕｎ”であるノードは、ノード（２２１）である。ノード（２２１）の値は、“Ｉｎｔｅｒｎｅｔ”及び“ｍｏｄｅｍ”である。
以上より、セクションが“Ｑｕｅｓｔｉｏｎ”であるノード（２１４、２２４、２２５）を集計単位として、セクションが“Ｎｏｕｎ”であるノード（２１０、２１２、２２０、２２１）に含まれる値及びその頻度を求めた場合、値“Ｉｎｔｅｒｎｅｔ”が３回であり、値“ｐｈｏｎｅ”が２回であり、値“ｍｏｄｅｍ”が１回であり、及び値“ＰＣ”が１回である。
【００４３】
図３の表（３０２）は、下記検索条件における値の集約の結果を示す。
検索条件：図２の各木構造（２００Ａ、２００Ｂ）について、セクションが“Ｄｏｃｕｍｅｎｔ”であるノード（２１６、２２７）を集計単位として、セクションが“Ｑｕｅｓｔｉｏｎ”であるノードの子ノードであり、該子ノードのセクションが“Ｎｏｕｎ”であり、及び該子ノードに含まれる値が“Ｉｎｔｅｒｎｅｔ”である場合に、セクションが“Ａｎｓｗｅｒ”であるノードの子ノードであり、該子ノードのセクションが“Ｎｏｕｎ”であるノードの値及びその頻度を集計する。
該検索結果の値は、ノード（２１２）の値である“Ｉｎｔｅｒｎｅｔ”及び“ｍｏｄｅｍ”である。該検索結果の頻度は、“Ｉｎｔｅｒｎｅｔ”が１であり、及び“ｍｏｄｅｍ”が１である。
上記検索条件は、複雑な集約の例である。該集約は、セクションが“Ａｎｓｗｅｒ”であるノードの子ノードにおいてセクションが“Ｎｏｕｎ”であるノード（３１２）のみが集計の対象になる。該集約によって、例えば顧客がインターネットについて言及しているときに、オペレータが発している言葉の内訳を知ることができる。
【００４４】
図４は、本発明の実施態様である、各ノードに後行順（post-order）でノードｉｄを割り振る例を示す。
ノードｉｄの割り振りには、木構造の走査（traversal）方法の１つである後行順（post-order）を用いる。後行順（post-order）は、後置順とも呼ばれる。木構造に対する後行順（post-order）とは、木のルート・ノードを T、T の子要素を T1、．．．、Tk としたとき、「T1をルート・ノードとする木を後行順で処理」、「T2をルート・ノードとする木を後行順で処理」・・・「Tkをルート・ノードとする木を後行順で処理」及び「Tを処理」というように再帰的に定義される処理順序のことである。ノードｉｄは例えば、整数値でありうる。
図４の木構造４００Ａ及び４００Ｂは、図２の木構造２００Ａ及び２００Ｂにそれぞれ対応する。図４のid：１〜１５が、各ノードに割り振られたノードｉｄである。
【００４５】
以下に、木構造（４００Ａ、４００Ｂ）について、各ノードに後行順（post-order）でノードｉｄを割り振る手順を示す。
最初に、木構造（４００Ａ）のルート・ノードであるノード（４１６）を選択する。次に、ノード（４１６）の子ノードのうち、左から１番目の子ノードであるノード（４１３）を選択する。ノード（４１３）は子ノードを持たないので、ノード（４１３）にノードｉｄ：１を割り振る。次に、ノード（４１３）の親ノード（４１６）を選択する。親ノード（４１６）の子ノードのうち、左から２番目の子ノードであるノード（４１４）を選択する。ノード（４１４）はさらに子ノードを（４１０、４１１）持つため、左から１番目の子ノードであるノード（４１０）を選択する。ノード（４１０）は子ノードを持たないので、ノード（４１０）にノードｉｄ：２を割り振る。次に、ノード（４１０）の親ノード（４１４）を選択する。次に、ノード（４１４）の子ノードのうち、左から２番目の子ノードであるノード（４１１）を選択する。ノード（４１１）は子ノードを持たないので、ノード（４１１）にノードｉｄ：３を割り振る。次に、ノード（４１１）の親ノード（４１４）を選択する。ノード（４１４）の全ての子ノード（４１０、４１１）にｉｄが割り振られているので、ノード（４１４）にノードｉｄ：４を割り振る。次に、ノード（４１４）の親ノード（４１６）を選択する。ノード（４１６）の子ノードのうち、左から３番目の子ノードであるノード（４１５）を選択する。ノード（４１５）は、さらに子ノード（４１２）を持つため、左から１番目の子ノードであるノード（４１２）を選択する。ノード（４１２）は子ノードを持たないので、ノード（４１２）にノードｉｄ：５を割り振る。次に、ノード（４１２）の親ノード（４１５）を選択する。ノード（４１５）の全ての子ノード（４１２）にｉｄが割り振られているので、ノード（４１５）にノードｉｄ：６を割り振る。次に、ノード（４１５）の親ノード（４１６）を選択する。ノード（４１６）の全ての子ノード（４１３、４１４、４１５）にｉｄが割り振られているので、ノード（４１６）にノードｉｄ：７を割り振る。以上の手順により、木構造（４００Ａ）に含まれる全てのノードに、ノードｉｄが割り振られる。
引き続き別の木構造（４００Ｂ）について、各ノードに後行順（post-order）でノードｉｄを割り振る場合、ノードｉｄの割り振りは続きのid番号（上記例においては８）から始められる。木構造（４００Ｂ）について、各ノードに後行順（post-order）でノードｉｄを割り振った結果は、図４を参照されたい。
【００４６】
以下の実施態様では、図４の木構造に示されるデータを参照する。また、該木構造に示されるデータの定義は、以下の通りである。
木構造を有するデータの集合を、Ｄ＝{Ｔ１,Ｔ２,...,Ｔｉ,...,Ｔｍ}（１≦ｉ≦ｍ）で表す。ここで、ｍは少なくとも１である。各Ｔは、有限個のノードを含む。以下、記号Ｔｉを用いて、Ｔｉのルート・ノードも指す。Ｔｉに含まれるノードの個数をｎｉとする。
各ノードは、１つのセクション及び０個以上の値を有する。セクションは、ノードの種類を示す１つのラベル（ｂ）を含む。よって、上記ノードの定義において、セクションをラベルと読み替えることができる。以下では、セクションをＳで表し、値をＶＬで表す。１つのノードは、ノードの親子関係の情報のほかに、{ｂ；ＶＬ１, ＶＬ２,..., ＶＬｉ,..., ＶＬｋ}（０≦ｉ≦ｋ）という情報を有する。ここで、ｋは０であってよい。すなわち、ノードがＶＬを持たなくてもよい。本発明の１つの実施態様では、値、例えば“ｍｏｄｅｍ”のような文字列、は、一意な整数値で符号化されうる。
Ｄに現れるすべてのラベルの集合をＬ＝{ｂ１,ｂ２,...,ｂｉ,...,ｂｐ}（１≦ｂ≦ｐ）で表す。各ラベルｂｉは、圧縮に適した整数値で符号化しうる。符号化の例は、Ｄｏｃｕｍｅｎｔ＝１、Ｄａｔｅ＝２、及びＱｕｅｓｔｉｏｎ＝３である。Ｄ内の木構造を順次読んでいき、未知のラベルが出現した場合は、その都度、新しい整数値がそのラベルに割り振られうる。
上記ルート・ノードのセクションは、全て等しいものである必要はない。なぜならば、後述する集約単位のセクションＳｃに対して、その子孫ノードに対するｊｏｉｎ操作をすることにより、上記ルート・ノードのセクションが全て等しい場合と同じ結果を得ることができるからである。
【００４７】
本発明の実施態様では、木構造のデータに対する集約計算を行うために、３つのインデックス、すなわち第１のインデックス、第２のインデックス及び第３のインデックスを作成する。
【００４８】
第１のインデックス（以下ｕ２ｖインデックス）とは、ノードそれぞれのノードｉｄと、該ノードに含まれる値とを含む１以上の組のデータを保管したものをいう。ｕ２ｖインデックスにおいて、該組のデータは、セクション毎に作成される。本発明の１つの実施態様では、ｕ２ｖインデックスは、上記組のデータをシーケンシャルに格納している。
図５Ａは、本発明の実施態様である、ｕ２ｖインデックスの概念スキーマ及び保管の例を示す。ｕ２ｖインデックスの概念スキーマは、セクション・ポインター・ツリー（５００）及び表（５０１、５０２）で示される。セクション・ポインター・ツリー（５００）は、表（５０１）の各行へのポインタの集合データを示す。表（５０１）の各行は、１セクション分のインデックスを示す。１列目は、行のサイズである。２列目は、セクションに対応するノードの数である。３列目以降は、セクションに対応するノードの数分のＥｎｔｒｙである。表（５０２）は、Ｅｎｔｒｙの詳細を示す。１列目は、ノードｉｄを示す。２列目は、ノードｉｄが割り振られたノードに含まれる値の数を示す。３列目以降は、ノードｉｄが割り振られたノードに含まれる値を示す。本発明の１つの実施態様として、３列目以降に設定される値は、差分圧縮されうる。差分圧縮の方法については後述する。
【００４９】
１セクション分のｕ２ｖインデックスのデータフォーマットは、次の通りである。該データフォーマットは、テーブル（５０１）の１行目に対応する。
{byte_size_of_array}(N:number_of_nodes)
[id_1][M1:number_of_values_1]
<value_1,1><value_1,2 -value_1,1>...<value_1,M1- value_1,M1-1>
[id_2][M2:number_of_values_2]
<value_2,1><value_2,2 -value_2,1>...<value_2,M2- value_2,M2-1>
......
[id_N][MN:number_of_value_N]
<value_N,1><value_N,2 -value_N,1>...<value_N,MN- value_N,MN-1>
上記データフォーマット内の改行は、見易さのためであり、データに含まれない。また、{}、()、[]及び<>などの区切りは、論理的なデータの区切りを表示するためのものであり、データに含まれない。{}は、非圧縮long(8bytes)を意味する。()は、非圧縮int(4bytes)を意味する。非圧縮とは、２の補数表記による標準的な符号化のことをいう。また、[]は、圧縮intを意味する。<>は、差分圧縮intを意味する。圧縮は、可変長の符号化でありうる。
byte_size_of_arrayは、先頭の[id_1]から最後の<value_N,MN - value_N,MN-1>までのバイト列の長さを示す。Nは、格納されているノードの数を示す。idは、ノードｉｄを示す。アンダーバーの後に続く値は、ノードを識別するために振った表記上の番号である。Mは、値の数を示す。Mの右下付で示された値は、ノードを識別するために振った表記上の番号である。valueは、値である。アンダーバーの後に続く値は、ノードを識別するために振った表記上の番号である。カンマの後に続く値は、値を識別するために振った表記上の番号である。
ｕ２ｖインデックスとは、全てのセクションに対して上記データフォーマットを作り、連結したものである。本発明の１つの実施態様として、該データフォーマットは、シーケンシャルに連結されている。セクションが例えば２種類しかなければ、該データフォーマットは次の通りである。
{byte_size_of_array}(N1:number_of_nodes)
[id_1][M1:number_of_values_1]
<value_1,1><value_1,2 -value_1,1>...<value_1,M1- value_1,M1-1>
......
[id_N1][MN1:number_of_value_N1]
<value_N1,1><value_N1,2 -value_N1,1>...<value_N1,MN1- value_N1,MN1-1>
{byte_size_of_array}(N2:number_of_nodes)
[id_1][M1:number_of_values_1]
<value_1,1><value_1,2 -value_1,1>...<value_1,M1- value_1,M1-1>
......
[id_N2][MN2:number_of_value_N2]
<value_N2,1><value_N2,2 -value_N2,1>...<value_N2,MN2- value_N2,MN2-1>
【００５０】
上記データフォーマットは、インデックス作成効率向上のために、できるだけコンピュータのメモリー上に記憶しておくのが好ましい。しかし、該メモリーの容量にも限界があるため、該コンピュータは、一定量のデータがメモリー内に蓄積されると該データをファイルに書き出す。ファイルに書き出すタイミングは例えば、処理済みのノード数で判断される。例えば、ファイルの書き出しは、１０００００ノードごとに行われる。データフォーマットからわかるように、複数のファイルに分割された場合でも、該ファイルのマージは容易である。
【００５１】
本発明の実施形態では、任意の圧縮方法を使用しうる。例えば、一般にギャップ符号化（Ｇａｐ ｃｏｄｉｎｇ）という名前で知られている全文検索エンジン ルシーン（Ｌｕｃｅｎｅ）で用いられる手法と同じものを用いる。ギャップ符号化は、単調に増大する整数列（例：１、４、３７、５１、８０、...）について差分をとる方法である。例えば、あるノードが（１、４、３７、５１、８０）という５個の値を持つとする。最初に、この手法では、値を昇順に並べる。次に、前の値との差分を求める。該差分を（１、３、３３、１４、２９）という数列に変換し、変換後の各値を「小さい数字に対し、より小さなビット数を割り当てるように」符号化する。復号化の際は、直前の値を覚えておき（初期値は０）、各数字を順に復号したあと直前の値に足すことを繰り返せばよい。この方法によって、特に１つのノードに多くの値が含まれるときに高い圧縮率が得られる。
図５Ａの表（５０２）の例では、最小の値であるvalue[１]を３列目に設定する。次に、２番目に小さい値であるvalue[２]と最小の値であるvalue[１]の差分を４列目に設定する。以下、同様の処理を繰り返す。最後に、最大の値であるvalue[Ｍ]と２番目に大きい値である［Ｍ−１］の差分を最終列に設定する。
【００５２】
差分をとったあとの圧縮手法について、例えば下記手法が知られている。
可変長符号化（Ｖａｒｉａｂｌｅ−ｌｅｎｇｔｈ ｃｏｄｅ）法は、ハフマン符号化、ランレングス符号化、算術符号化及び適応ビット割当に分けられる。
ガンマ符号化（Ｇａｍｍａ ｃｏｄｅ）法は、整数を２進数で表現し、そのビット数から１を引いた数の「０」と、整数を２進数で表現した値を合わせた値を、出力する手法である。
ゴーロム符号化（Ｇｏｌｕｍｂ ｃｏｄｅ）法は、次の三つの手順により構成される。
１．はじめに、floor(n/m)を計算し、このunarycodeを出力する。ここで、floor(x)はxを上回らない最大整数、また正数aのunary codeはa個の“0”とそれに続く１個の“1”から構成される符号“00・・・01”、をそれぞれ表す。
２．続いて、n/mの剰余mod(n/m)を計算し、それをfloor(log2(m))桁のバイナリ符号で表したものを出力する。
３．両者をこの順番で結合したものがnのゴーロム符号となる。
【００５３】
図５Ｂの表（５０３）は、圧縮効果の結果を示す。圧縮の比較に使用したデータは、コールセンターのログ・データ３２４６７７件である。比較は、セクションごとに作成したｕ２ｖインデックスファイルを用いて行った。表（５０３）１列目は、任意のセクションを示す。２列目の非圧縮時のインデックスのファイル・サイズ（Ａ）は、圧縮を行わなかった場合のｕ２ｖインデックスファイルのファイル・サイズを示す。３列目の圧縮時のインデックスのファイル・サイズ（Ｂ）は、可変長符号化（Ｖａｒｉａｂｌｅ−ｌｅｎｇｔｈ ｃｏｄｅ）法で圧縮したｕ２ｖインデックスファイルのファイル・サイズを示す。４列目の圧縮率は、圧縮を行った場合と行わなかった場合のファイル・サイズの圧縮率（％）を示す。
表（５０３）に見られるように、圧縮率はセクションの種類によって異なる。圧縮を行った場合、ｕ２ｖインデックスファイルのファイル・サイズは、圧縮を行わなかった場合から３５％〜５２％のサイズを減らしたサイズになる。
【００５４】
図５Ｃの表（５０４）は、本発明の実施態様である、各木構造（４００Ａ、４００Ｂ）のデータからｕ２ｖインデックスを作成した際のＥｎｔｒｙの例を示す。但し、１列目、「セクション」の列は、説明のために追加した列である。表（５０４）の値に示されている値は、キーワードを示している。本発明の１つの実施態様では、該値は数値に変換される。本発明のさらなる実施態様では、該数値は圧縮される。
【００５５】
木構造（４００Ａ、４００Ｂ）のデータから、セクションがＮｏｕｎであるノード（４１０、４１２、４２０、４２１）及びセクションがＶｅｒｂであるノード（４１１、４２２）について、ｕ２ｖインデックスを作成する例を、以下に示す。
最初に、セクションがＮｏｕｎであるノード（４１０、４１２、４２０及び４２１）について示す。
ノード（４１０）のノードｉｄは、２である。従って、表（５０４）のセクションがＮｏｕｎの行のＥｎｔｒｙ［１］のノードｉｄの列には、２が設定される。ノード（４１０）の持つ値は、Ｉｎｔｅｒｎｅｔ、ＰＣ、ｐｈｏｎｅの３つである。従って、セクションがＮｏｕｎの行のＥｎｔｒｙ［１］の値の数の列には、３が設定される。セクションがＮｏｕｎの行のＥｎｔｒｙ［１］の値の列には、Ｉｎｔｅｒｎｅｔ、ＰＣ、ｐｈｏｎｅが設定される。
ノード（４１２）のノードｉｄは、５である。従って、表（５０４）のセクションがＮｏｕｎの行のＥｎｔｒｙ［２］のノードｉｄの列には、５が設定される。ノード（４１２）の持つ値は、Ｉｎｔｅｒｎｅｔ、ｍｏｄｅｍの２つである。従って、セクションがＮｏｕｎの行のＥｎｔｒｙ［２］の値の数の列には、２が設定される。セクションがＮｏｕｎの行のＥｎｔｒｙ［２］の値の列には、Ｉｎｔｅｒｎｅｔ、ｍｏｄｅｍが設定される。
ノード（４２０）のノードｉｄは、９である。従って、表（５０４）のセクションがＮｏｕｎの行のＥｎｔｒｙ［３］のノードｉｄの列には、９が設定される。ノード（４２０）の持つ値は、Ｉｎｔｅｒｎｅｔ、ｐｈｏｎｅの２つである。よって、セクションがＮｏｕｎの行のＥｎｔｒｙ［３］の値の数の列には、２が設定される。セクションがＮｏｕｎの行のＥｎｔｒｙ［３］の値の列には、Ｉｎｔｅｒｎｅｔ、ｐｈｏｎｅが設定される。
ノード（４２１）のノードｉｄは、１１である。従って、表（５０４）のセクションがＮｏｕｎの行のＥｎｔｒｙ［４］のノードｉｄの列には、１１が設定される。ノード（４２１）の持つ値は、Ｉｎｔｅｒｎｅｔ、ｍｏｄｅｍの２つである。従って、セクションがＮｏｕｎの行のＥｎｔｒｙ［４］の値の数の列には、２が設定される。セクションがＮｏｕｎの行のＥｎｔｒｙ［４］の値の列には、Ｉｎｔｅｒｎｅｔ、ｍｏｄｅｍが設定される。
次に、セクションがＶｅｒｂであるノード（４１１、４２２）について示す。
ノード（４１１）のノードｉｄは、３である。従って、表（５０４）のセクションがＶｅｒｂの行のＥｎｔｒｙ［１］のノードｉｄの列には、３が設定される。ノード（４１１）の持つ値は、ｃｏｎｎｅｃｔ、ｔｙｐｅの２つである。従って、セクションがＶｅｒｂの行のＥｎｔｒｙ［１］の値の数の列には、２が設定される。セクションがＶｅｒｂの行のＥｎｔｒｙ［１］の値の列には、ｃｏｎｎｅｃｔ、ｔｙｐｅが設定される。
ノード（４２２）のノードｉｄは、１３である。従って、表（５０４）のセクションがＶｅｒｂの行のＥｎｔｒｙ［２］のノードｉｄの列には、１３が設定される。ノード（４２２）の持つ値は、ｃｏｎｎｅｃｔ、ｒｅａｄの２つである。従って、Ｖｅｒｂの行のＥｎｔｒｙ［２］の値の数の列には、２が設定される。Ｖｅｒｂの行のＥｎｔｒｙ［２］の値の列には、ｃｏｎｎｅｃｔ、ｒｅａｄが設定される。
【００５６】
ｕ２ｖインデックスは、ファイルに保管される。該ファイルは、１つのファイルである必要はなく、複数のファイルでよい。実装では、各セクションに対するｕ２ｖインデックスのオフセットを記録したファイル（図示せず）にセクション・ポインター・ツリー（５００）も書き出す。該ファイルには、対応する開始位置、すなわち何バイト目から始まるかの位置を保管する。この保管形式は任意でよい。例えば、Ｂ−ｔｒｅｅが用いられる。
【００５７】
第２のインデックス（以下、ｒｅｌａｔｉｏｎインデックス）とは、ノードそれぞれのノードｉｄと、該ノードの少なくとも１つの子孫ノードの間で最小のノードｉｄを有する子孫ノードのノードｉｄとを含む１以上の組のデータを保管したものをいう。ｒｅｌａｔｉｏｎインデックスにおいて、該組のデータは、セクション毎に作成される。本発明の１つの実施態様では、ｒｅｌａｔｉｏｎインデックスは、上記組のデータをシーケンシャルに格納している。
図６Ａは、本発明の実施態様である、ｒｅｌａｔｉｏｎインデックスの概念スキーマ及び保管の例を示す。ｒｅｌａｔｉｏｎインデックスの概念スキーマは、セクション・ポインター・ツリー（６００）及び表（６０１、６０２）で示される。セクション・ポインター・ツリー（６００）は、表（６０１）の各行へのポインタの集合データを示す。表（６０１）の各行は、１セクション分のインデックスを示す。１列目は、行のサイズである。２列目は、セクションに対応するノードの数である。３列目以降は、セクションに対応するノードの数分のＥｎｔｒｙである。表（６０２）は、Ｅｎｔｒｙの詳細を示す。１列目は、ノードｉｄを示す。２列目は、子孫ノードのノードｉｄのうち、最小のｉｄを示す。
【００５８】
１セクション分のｒｅｌａｔｉｏｎインデックスのデータフォーマットは、次の通りである。該データフォーマットは、テーブル（６０１）の１行目に対応する。
{byte_size_of_array}(N:number_of_nodes)
[id_1][min_id_1][id_2][min_id_2]......[id_N][min_id_N]
上記データフォーマット内の改行は、見易さのためであり、データに含まれない。また、{}、()、[]などの区切りは、論理的なデータの区切りを表示するためのものであり、データに含まれない。{}は非圧縮long(8bytes)を意味する。()は、非圧縮int(4bytes)を意味する。非圧縮とは、２の補数表記による標準的な符号化のことを示す。また、[]は圧縮intを意味する。圧縮は、可変長の符号化でありうる。
byte_size_of_arrayは、先頭の[id_1]から最後の[min_id_N]までのバイト列の長さを示す。Nは、格納されているノードの数を示す。idは、ノードiｄを示す。アンダーバーの後に続く値は、ノードを識別するために振った表記上の番号である。min_idは、同じ表記上の番号が振られたノードｉｄの子孫ノードのうち、最小のノードｉｄを持つノードのノードｉｄを示す。
【００５９】
図６Ｂの表（６０３）は、本発明の実施態様である、各木構造（４００Ａ、４００Ｂ）のデータからｒｅｌａｔｉｏｎインデックスを作成した際のＥｎｔｒｙの例を示す。但し、１列目、「セクション」の列は、説明のために追加した列である。
【００６０】
上記データフォーマットは、インデックス作成効率向上のために、できるだけコンピュータのメモリー上に記憶しておくのが好ましい。しかし、該メモリーの容量にも限界があるため、該コンピュータは、一定量のデータがメモリー内に蓄積されると該データをファイルに書き出す。ファイルに書き出すタイミングは例えば、処理済みのノード数で判断される。例えば、ファイルの書き出しは、１０００００ノードごとに行われる。データフォーマットからわかるように、複数のファイルに分割された場合でも、該ファイルのマージは容易である。
【００６１】
木構造（４００Ａ、４００Ｂ）のデータからｒｅｌａｔｉｏｎインデックスを作成する例を、以下に示す。
セクションがＤｏｃｕｍｅｎｔであるノード（４１６、４２７）について考える。対応するインデックスは、表（６０３）の２行目、セクションが“Ｄｏｃｕｍｅｎｔ”の行である。ノード（４１６）のノードｉｄは、７である。従って、表（６０３）の２列目、「ノードｉｄ」に７を設定する。ノード（４１６）の子孫ノード（４１０〜４１５）のうち、最小のノードｉｄを持つノードは、ノード（４１３）である。ノード（４１３）のノードｉｄは、１である。従って、表（６０３）の３列目、「最小のノードｉｄ」に１を設定する。ノード（４２７）のノードｉｄは、１５である。従って、表（６０３）の４列目、「ノードｉｄ」に１５を設定する。ノード（４２７）の子孫ノード（４２０〜４２６）のうち、最小のノードｉｄを持つノードは、ノード（４２３）である。ノード（４２３）のノードｉｄは、１である。従って、表（６０３）の５列目、「最小のノードｉｄ」に８を設定する。
セクションがＱｕｅｓｔｉｏｎであるノード（４１４、４２４、４２５）について考える。対応するインデックスは、表（６０３）の３行目、セクションが“Ｑｕｅｓｔｉｏｎ”の行である。ノード（４１４）のノードｉｄは、４である。従って、表（６０３）の２列目、「ノードｉｄ」に４を設定する。ノード（４１４）の子孫ノード（４１０〜４１１）のうち、最小のノードｉｄを持つノードは、ノード（４１０）である。ノード（４１０）のノードｉｄは、２である。従って、表（６０３）の３列目、「最小のノードｉｄ」に２を設定する。ノード（４２４）のノードｉｄは、１０である。従って、表（６０３）の４列目、「ノードｉｄ」に１０を設定する。ノード（４２４）の子孫ノード（４２０）のうち、最小のノードｉｄを持つノードは、ノード（４２０）である。ノード（４２０）のノードｉｄは、９である。従って、表（６０３）の５列目、「最小のノードｉｄ」に９を設定する。ノード（４２５）のノードｉｄは、１２である。従って、表（６０３）の６列目、「ノードｉｄ」に１２を設定する。ノード（４２５）の子孫ノード（４２１）のうち、最小のノードｉｄを持つノードは、ノード（４２１）である。ノード（４２１）のノードｉｄは、１１である。従って、表（６０３）の７列目、「最小のノードｉｄ」に１１を設定する。
セクションがＡｎｓｗｅｒであるノード（４１５、４２６）について考える。対応するインデックスは、表（６０３）の４行目、セクションが“Ａｎｓｗｅｒ”の行である。ノード（４１５）のノードｉｄは、６である。従って、表（６０３）の２列目、「ノードｉｄ」に６を設定する。ノード（４１５）の子孫ノード（４１２）のうち、最小のノードｉｄを持つノードは、ノード（４１２）である。ノード（４１２）のノードｉｄは、５である。従って、表（６０３）の３列目、「最小のノードｉｄ」に５を設定する。ノード（４２６）のノードｉｄは、１４である。従って、表（６０３）の４列目、「ノードｉｄ」に１４を設定する。ノード（４２６）の子孫ノード（４２２）のうち、最小のノードｉｄを持つノードは、ノード（４２２）である。ノード（４２２）のノードｉｄは、１３である。従って、表（６０３）の５列目、「最小のノードｉｄ」に１３を設定する。
セクションがＤａｔｅ、Ｎｏｕｎ及びＶｅｒｂであるノード（４１３、４１０、４１１、４１２、４２３、４２０、４２１及び４２２）は、子孫ノードを持たない。このような子ノードを持たないノードであるリーフノードに対しては、ｒｅｌａｔｉｏｎインデックスは作成されない。
【００６２】
ｒｅｌａｔｉｏｎインデックスは、ファイルに保管される。該ファイルは、１つのファイルである必要はなく、複数のファイルでよい。実装では、各セクションに対するｒｅｌａｔｉｏｎインデックスのオフセットを記録したファイル（図示せず）にセクション・ポインター・ツリー（６００）も書き出す。該ファイルには、対応する開始位置、すなわち何バイト目から始まるかの位置を保管する。この保管形式は任意でよい。例えば、Ｂ−ｔｒｅｅが用いられる。
【００６３】
第３のインデックス（以下ｖ２ｕインデックス）とは、特定の値を含む１以上のノードのノードｉｄを含む１以上の組のデータを保管したものをいう。ｖ２ｕインデックスにおいて、該組のデータは、ラベル毎に且つ特定の値毎に作成される。本発明の１つの実施態様では、ｖ２ｕインデックスは、上記組のデータをシーケンシャルに格納している。ｖ２ｕインデックスは、各ノードの値から、該値を含むセクションのノードｉｄの一覧を検索できるデータフォーマットをとる。
図７Ａは、本発明の実施態様である、ｖ２ｕインデックスの概念スキーマ及び保管の例を示す。ｖ２ｕインデックスの概念スキーマは、セクション・ポインター・ツリー（７００）、セクションに対応する数のハッシュ構造（７０１）及びハッシュ構造に対応する表（７０２）で示される。セクション・ポインター・ツリー（７００）は、セクションごとに用意されたハッシュ構造（７０１）へのポインタの集合データを示す。ハッシュ構造（７０１）は、表（７０２）に示す各行へのポインタの集合データを示す。表（７０２）の各行は、特定の値毎のインデックスを示す。１列目は、行のサイズである。２列目は、特定の値を有するノードの数である。３列目以降は、特定の値を有するノードのノードｉｄである。本発明の１つの実施態様では、表（７０２）の３列目以降に含まれるノードｉｄは、ｕ２ｖインデックスの例と同様に圧縮される。
【００６４】
図７Ｂの表（７０３）は、本発明の実施態様である、各木構造（４００Ａ、４００Ｂ）のデータからセクションがＮｏｕｎであるノード（４１０、４１２、４２０、４２１）について、ｖ２ｕインデックスを作成した際のデータの例を示す。但し、１列目、「値」の列は、説明のために追加した列であり、ｖ２ｕインデックスに含まれない。また、本発明の１つの実施態様として、ノードｉｄは、圧縮されている。
【００６５】
１セクション分の１つの値に対するｖ２ｕインデックスのデータフォーマットは、次の通りである。データフォーマットは、表（７０２）の１行目と対応する。
{byte_size_of_array}(N:number_of_nodes)
<id,1><id,2 - id,1>...<id,N1- id,N1-1>
上記データフォーマット内の改行は、見易さのためであり、データに含まれない。また、{}、()、<>などの区切りは、論理的なデータの区切りを表示するためのものであり、データに含まれない。{}は、非圧縮long(8bytes)を意味する。()は、非圧縮int(4bytes)を意味する。非圧縮とは、２の補数表記による標準的な符号化のことをいう。<>は、差分圧縮intを意味する。圧縮は、可変長の符号化でありうる。
byte_size_of_arrayは、先頭の<id,1>から最後の<id,N1 - id,N1-1>までのバイト列の長さを示す。Nは、格納されているノードの数を示す。idはノードｉｄを示す。カンマの後に続く値は、ノードを識別するために振った表記上の番号である。
【００６６】
上記データフォーマットは、インデックス作成効率向上のために、できるだけコンピュータのメモリー上に記憶しておくのが好ましい。しかし、該メモリーの容量にも限界があるため、該コンピュータは、一定量のデータがメモリー内に蓄積されると該データをファイルに書き出す。ファイルに書き出すタイミングは例えば、処理済みのノード数で判断される。例えば、ファイルの書き出しは、１０００００ノードごとに行われる。データフォーマットからわかるように、複数のファイルに分割された場合でも、該ファイルのマージは容易である。
【００６７】
木構造（４００Ａ、４００Ｂ）のデータから、セクションがＮｏｕｎであるノード（４１０、４１２、４２０、４２１）について、ｖ２ｕインデックスを作成する例を、以下に示す。
セクションがＮｏｕｎであるノード（４１０、４１２、４２０及び４２１）のうち、値にｉｎｔｅｒｎｅｔを持つノードは、ノード（４１０、４１２、４２０及び４２１）である。従って、表（７０２）の１行目には、ノード（４１０、４１２、４２０、４２１）のノードｉｄである、２、５、９、１１が設定される。
セクションがＮｏｕｎであるノード（４１０、４１２、４２０及び４２１）のうち、値にＰＣを持つノードは、ノード（４１０）である。従って、表（７０２）の２行目には、ノード（４１０）のノードｉｄである、２が設定される。
セクションがＮｏｕｎであるノード（４１０、４１２、４２０及び４２１）のうち、値にｍｏｄｅｍを持つノードは、ノード（４１２、４２１）である。従って、表（７０２）の３行目には、ノード（４１２、４２１）のノードｉｄである、５、１１が設定される。
セクションがＮｏｕｎであるノード（４１０、４１２、４２０及び４２１）のうち、値にｐｈｏｎｅを持つノードは、ノード（４１０、４２０）である。従って、表（８０２）の４行目には、ノード（４１０、４２０）のノードｉｄである、２、９が設定される。
【００６８】
ｖ２ｕインデックスは、ファイルに保管される。該ファイルは、１つのファイルである必要はなく、複数のファイルでよい。実装では、各セクションに対するｖ２ｕインデックスのオフセットを記録したファイル（図示せず）にセクション・ポインター・ツリー（７００）も書き出す。該ファイルには、対応する開始位置、すなわち何バイト目から始まるかの位置を保管する。この保管形式は、任意でありうる。例えば、Ｂ−ｔｒｅｅが用いられる。さらに、value（値）が与えられたとき、表（７０２）の各行にランダムアクセスするためのポインタをハッシュ（７０１）で保持する。このハッシュの仕組みは，value（値）に対して定数時間でポインタの値を引くことができれば任意で良い。また、ハッシュもセクションごとに作成するため、セクションからハッシュ構造へのポインタも保持する。
【００６９】
図８Ａ〜図８Ｆは、インデックスの作成のフローチャート及びそれに付随する図を示す。
フローチャートで使用する用語を以下に説明する。木構造をＴで表す。また、|Ｔ|と記載した場合、|Ｔ|は、Ｔの持つノードの個数を表す。木構造（４００Ａ）の例では、|Ｔ|＝７である。ノードをＮで表す。ノードＮの持つセクションを、Ｎ.ｓｅｃｔｉｏｎで表す。ノードＮの持つ値を、Ｎ．Ｖａｌｕｅｓで表す。ノードＮに割り振られたノードｉｄをＮ．ｕｎｉｔＩｄで表す。また、セクションは、あらかじめ数値に変換されているものとする。例えば、“Ｄｏｃｕｍｅｎｔ”＝１であり、“Ｑｕｅｓｔｉｏｎ”＝２であり、“Ｎｏｕｎ”＝３などである。
ノード（４１０）の例では、Ｎ.ｓｅｃｔｉｏｎは、“Ｎｏｕｎ”＝３であり、Ｎ．valuesは、“Ｉｎｔｅｒｎｅｔ”、“ＰＣ”及び“ｐｈｏｎｅ”であり、Ｎ．ｕｎｉｔＩｄは２である。
【００７０】
図８Ａは、本発明の実施態様である、インデックスを作成または更新する処理の全体のフローチャートを示す。
ステップ８００では、コンピュータが、変数currentUnitIdを０で初期化する。currentUnitIdは、コンピュータが処理対象の木構造にノードｉｄを割り振る際の初期値を保管する変数である。０での初期化は、最初に振られるノードｉｄが０であることを示す。本発明の１つの実施態様として、値が文字列である場合、該文字列を数値に置き換えることが可能である。
ステップ８０１では、コンピュータが、処理対象の木構造がまだ存在するかの判定を行う。処理対象の木構造がある場合、ステップ８０２に進む。全ての木構造について処理済みであれば、ステップ８０７に進む。
ステップ８０２では、コンピュータが、後続のステップ（８０３〜８０６）で用いる木構造を選択する処理である。後続のステップ（８０３〜８０６）は木構造の単位で処理を行う。
ステップ８０３では、ステップ８０２で選択した木構造について、コンピュータが、後行順でノードｉｄを割り振る。ノードｉｄの開始値には、currentUnitIdを用いる。
ステップ８０４では、コンピュータが、Ｒｅｌａｔｉｏｎインデックスを作成または更新する。Ｒｅｌａｔｉｏｎインデックス及び該処理については、後述する。
ステップ８０５では、コンピュータが、ｕ２ｖインデックスを作成または更新する。ｕ２ｖインデックス及び該処理については、後述する。ステップ８０４とステップ８０５は、どちらのステップを先に実行してもかまわない。
ステップ８０６では、コンピュータが、変数currentUnitIdに|Ｔ|を加える処理を行う。該処理で求めた値は、次に処理対象とする木にノードｉｄを割り振る際の初期値になる。
ステップ８０７では、コンピュータが、ｖ２ｕインデックスを作成または更新する。本発明の１つの実施態様として、ｖ２ｕインデックスを作成または更新後に、上記文字列が数値に置き換えられた値について、該数値を文字列に再び置き換えることが可能である。
【００７１】
図８Ｂは、本発明の実施態様である、ｒｅｌａｔｉｏｎインデックスを作成または更新する処理のフローチャートを示す。また、図８Ｂは、図８Ａのステップ（８０４）の詳細を示す。該フローチャートは、１つの木構造Ｔについてのものである。
ステップ８１０では、コンピュータが、木のノードを、ｕｎｉｔＩｄの小さい順に並べる。
ステップ８１１では、コンピュータが、処理対象のノードがまだ残っているかの判定を行う。処理対象のノードがある場合は、ステップ８１２に進む。全てのノードについて処理済みであれば、処理を終了し、図８Ａのステップ８０５へ進む。
ステップ８１２では、コンピュータが、木構造ＴからノードＮを取り出す。
ステップ８１３では、コンピュータが、ステップ８１２で取り出したノードＮの子孫ノードのうち、ノードｉｄが最少のノードを選択する。ここで、ノードｉｄが最少のノードをＮ´とする。
ステップ８１４では、コンピュータが、ステップ８１２で取り出したノードＮが持つノードｉｄ、及びステップ８１３で選択したノードＮ´が持つノードｉｄをｒｅｌａｔｉｏｎインデックスに追加する。追加先は、ノードＮに設定されたセクションに対応する個所である。上記追加先は、セクション・ポインター・ツリーから求めることができる。コンピュータは、セクション・ポインター・ツリーから該セクションを指すポインタを取得し、ｒｅｌａｔｉｏｎインデックスにおいて、そのポインタの指す先の最後尾にノードＮが持つノードｉｄ及びノードＮ´が持つノードｉｄを追加すればよい、新規のセクションの場合は、セクション・ポインター・ツリーに、該セクションを指すポインタを追加する。コンピュータは、ｒｅｌａｔｉｏｎインデックスの設定項目であるノードの数及び行のサイズを更新する。
【００７２】
図８Ｃは、本発明の実施態様である、ｕ２ｖインデックスを作成または更新する処理のフローチャートを示す。また、図８Ｃは、図８Ａのステップ８０５の詳細を示す。該フローチャートは、１つの木構造Ｔについてのものである。
ステップ８２０では、コンピュータが、木のノードを、ｕｎｉｔＩｄの小さい順に並べる。
ステップ８２１では、コンピュータが、処理対象のノードがまだ残っているかの判定を行う。処理対象のノードがある場合は、ステップ８２２に進む。全てのノードについて処理済みであれば、処理を終了し、図８Ａのステップ８０６へ進む。
ステップ８２２では、コンピュータが、木構造ＴからノードＮを取り出す。
ステップ８２３では、コンピュータが、ステップ８２２で取り出したノードＮが持つノードｉｄ、値及び値の数をｕ２ｖインデックスに追加する。追加先は、ノードＮに設定されたセクションに対応する個所である。上記追加先は、セクション・ポインター・ツリーから求めることができる。コンピュータは、セクション・ポインター・ツリーから該セクションを指すポインタを取得し、ｕ２ｖインデックスにおいて、そのポインタの指す先の最後尾にノードＮが持つノードｉｄ、値及び値の数を追加すればよい、新規のセクションの場合は、セクション・ポインター・ツリーに、該セクションを指すポインタを追加する。差分圧縮を行う場合は、該ステップで行う。コンピュータは、ｕ２ｖインデックスの設定項目であるノードの数及び行のサイズを更新する。
【００７３】
図８Ｄは、本発明の実施態様である、ｖ２ｕインデックスを作成または更新する処理のフローチャートを示す。
ステップ８３０では、コンピュータが、処理対象のセクションがまだ残っているかの判定を行う。処理対象のセクションがある場合は、ステップ８３１に進む。全てのセクションについて処理済みであれば、処理を終了する。
ステップ８３１では、コンピュータが、転置行列Ｉを作成する。コンピュータは、Ｓｅｃｔｉｏｎ Ｓを１つ選び、ｕ２ｖインデックスからセクションＳに対応する部分を読み込む。そして、コンピュータは、該読み込んだデータから転置行列Ｉを作成する。転置行列については後述する。
ステップ８３２では、コンピュータが、転置行列を書き出す。転置行列とは、ｕ２ｖインデックス内のデータを、各値に対してその値を含むノードのノードｉｄを保持する形式に変換したものである。転置行列は、検索エンジンのインデックスとして一般的な行列である。上記書き出す処理については後述する。該書き出す処理が終了したら、コンピュータは、再びステップ８３０に処理を戻す。
コンピュータは、ステップ（８３０〜８３２）の処理を、処理するセクションがなくなるまで繰り返す。
【００７４】
図８Ｅは、本発明の実施態様である、転置行列の例を示す。
表（８４０）は、あるセクションにおけるｕ２ｖインデックス内のデータの例を示す。該データの例は、転置行列に変換する前のデータの例に相当する。表（８４１）は、表（８４０）のデータを、転置行列に変換した例を示す。本願発明の１つの実施態様では、表に含まれる値は、数字で表現されうる。
表（８４０）において、値“Ｉｎｔｅｒｎｅｔ”は、ノードｉｄが２、５、９、１１の行に含まれる。値“ＰＣ”は、ノードｉｄが２の行に含まれる。値“ｐｈｏｎｅ”は、ノードｉｄが２、９の行に含まれる。値“ｍｏｄｅｍ”は、ノードｉｄが５、１１の行に含まれる。値“ｋｅｙｂｏａｒｄ”は、ノードｉｄが１１の行に含まれる。この関係を表したものが、表（８４１）で示す転置行列になる。
【００７５】
図８Ｆは、本発明の実施態様である、転置行列の書き出しの処理を示すフローチャートである。該フローチャートは、セクションごとに実施される。
ステップ８５０では、コンピュータが、ｖ２ｕの値ハッシュの初期化を行う。値ハッシュとは、図７Ａのハッシュ構造（７０１）を示す。コンピュータは、空の値ハッシュを新規作成する。コンピュータは、値ハッシュにポインタを設定するための変数であるｐｏｉｎｔｅｒに、０をセットする。
ステップ８５１では、コンピュータが、処理対象の値がまだ残っているかの判定を行う。コンピュータは、処理対象の値がある場合は、ステップ８５２に進む。コンピュータは、全ての値について処理済みであれば、図８Ｄのステップ８３０に進む。
ステップ８５２では、コンピュータが、圧縮リストＣＬ（ｖ）を作成する。圧縮リストＣＬ（ｖ）は、図７Ａの表（７０２）における各行に対応するデータを指す。コンピュータは、値ｖを１つ選ぶ。コンピュータは、ステップ（８３１）で作成した転置行列Ｉから、該値ｖに対応するノードｉｄを読み出す。コンピュータは、該読み出したノードｉｄ、ノードｉｄの数及び、該ノードｉｄと該ノードｉｄの数のサイズを用いて、圧縮リストＣＬ（ｖ）作成する。本発明の１つの実施態様では、該ノードｉｄは差分圧縮される。
ステップ８５３では、コンピュータが、値ハッシュ及びｖ２ｕインデックスにデータを設定する。コンピュータは、値ｖとｐｏｉｎｔｅｒの組を、値ハッシュに追加する。
また、コンピュータは、ＣＬ（ｖ）をｖ２ｕインデックスに追加する。コンピュータは、ｖ２ｕインデックスが存在しない場合は、ｖ２ｕインデックスを作成する。
ステップ８５４では、コンピュータが、ｐｏｉｎｔｅｒにＣＬ（ｖ）のサイズを加える。該ステップの処理が終了したら、コンピュータは、再びステップ８５１に処理を戻す。
コンピュータは、ステップ（８５１〜８５４）の処理を、処理する値がなくなるまで繰り返す。
【００７６】
図９Ａ〜図９Ｃは、本発明の実施態様である、インデックスを用いた集約処理のフローチャートを示す。
該フローチャートにおける入力パラメータの定義は、以下の通りである。
検索条件値をｖとする。ｖは例えば、検索エンジンを使うときに用いるキーワードに該当する。例えば、値 “ｐｈｏｎｅ”（電話）が該当する。また、単一の値の代わりに、値の任意の論理式を用いることもできる。ｖの例は、「ｐｈｏｎｅ ａｎｄ Ｉｎｔｅｒｎｅｔ」である。
検索条件セクションをＳｓとする。Ｓｓは、ｖを含むセクションの指定であり、ｖとのペアで意味を持つ。Ｓｓの例は、「Ａｎｓｗｅｒセクションの中に値“ｐｈｏｎｅ”が存在するような木に関して集約する。」という場合におけるＡｎｓｗｅｒセクションである。
ルートセクションをＳｒとする。Ｓｒは、集約対象の木構造のルート・ノードのセクションの指定である。Ｓｒの例は、Ｄｏｃｕｍｅｎｔである。
集約対象セクションをＳａとする。Ｓａは、集約する値を含むセクションの指定である。Ｓａの例は、「Ｎｏｕｎセクションの値を集約する。」場合におけるＮｏｕｎセクションである。
集約単位セクションをＳｃとする。Ｓｃは、集約関数を適用する単位の指定であり、Ｓａとのペアで意味を持つ。Ｓｃの例は、「Ｑｕｅｓｔｉｏｎセクションの単位で、Ｎｏｕｎセクションの値を集約する。」場合における、Ｑｕｅｓｔｉｏｎセクションである。
集約処理の出力は、ｖと、集約関数ｆのｖ上での値ｆ(ｖ)との組(ｖ, ｆ(ｖ))のリストで表される。以下、ｆ(ｖ)＝(ｖのＳｃ単位の出現回数)とする。ｆとして任意の集約関数を用いることもできる。
【００７７】
図９Ａは、本発明の実施態様である、集約処理の主処理を示すフローチャートである。該主処理には、入力パラメータとして、ｖ、Ｓｓ、Ｓｒ、Ｓａ、Ｓｃが与えられる。該主処理は、検索条件処理（９００）及び値集約処理（９０１）を実行する。
【００７８】
図９Ｂは、本発明の実施態様である、検索条件処理（９００）のフローチャートを示す。該検索条件処理（９００）では、ｖ２ｕインデックス及びｒｅｌａｔｉｏｎインデックスを使用して、値、すなわちキーワードが求められうる。
ステップ９１０では、コンピュータが、セクションＳｓを用いてｖ２ｕインデックスの検索を行い、圧縮リスト（以下ＣＬ（ｖ））を取得する。１つの実施態様として、該検索はシーケンシャルに行われる。
ステップ９１１では、コンピュータが、ステップ９１０で取得したＣＬ（ｖ）を解凍し、ノードｉｄのリスト（以下Ｌ（ｖ））を取得する。該ノードｉｄのリストが、第１のリストに対応する。
ステップ９１２では、コンピュータが、ｒｅｌａｔｉｏｎインデックスを検索して、セクションＳｒの行（以下Ｒ（Ｓｒ））を取得する。１つの実施態様として、該検索は、シーケンシャルに行われうる。
ステップ９１３では、コンピュータが、Ｌ（ｖ）とＲ（Ｓｒ）のマッチングを行い、Ｒ（Ｓｒ）の部分集合（以下Ｒ’（Ｓｒ））を取得する。該Ｒ’（Ｓｒ）が、第２のリストに対応する。
【００７９】
図９Ｃは、本発明の実施態様である、マッチング処理のフローチャートを示す。
図９Ｃは、例としてＬ（ｖ）とＲ（Ｓｒ）とのマッチング処理を示す。Ｌ（ｖ）の行に含まれる各数値は、ｖを持つノードのノードｉｄを示す。例えば、リスト（９２０）において、ノードｉｄの各数値は、３，７，１６，２０及び３８である。また、Ｒ（Ｓｒ）の行に含まれる各数値は、セクションＳｒを持つノードのノードｉｄと、そのノードｉｄを持つノードの子孫ノードのうち最小のノードｉｄを持つノードのノードｉｄの組を示す。例えば、リスト（９２０）において、（５，１）、（１５，１０）及び（４５，２７）の各組が、ノードｉｄの組である。なお、（５，１）という表記は、５がセクションＳｒのノードｉｄであり、１が、ノードｉｄが５であるノードの子孫ノードの持つノードｉｄのうちの最小のノードｉｄであることを意味する。
他のデータについてのマッチング処理についても上記と同様である。
【００８０】
図９Ｃのマッチング処理の手順は、以下の通りである。
コンピュータは、カーソル（９２４）を各リスト（Ｌ（ｖ）、Ｒ（Ｓｒ））の先頭にセットする（９２１）。
コンピュータは、Ｌ（ｖ）のカーソルが指すノードｉｄが、Ｒ（Ｓｒ）の指す値のペアの範囲に入っているかどうかチェックし、入っていたらそのペアを、メモリー上に保管する。マッチング対象のリスト（９２１）の例では、３は範囲（５,１）に入っているため、コンピュータは、（５，１）をメモリー上に保管する（９２１）。
次に、コンピュータは、Ｌ（ｖ）のカーソルを、ノードｉｄの値が現在のＲ（Ｓｒ）のペアの範囲を越えるまで（すなわち、７）移動する（９２２）。
次に、コンピュータは、Ｒ（Ｓｒ）のカーソルを移動する。
上記を繰り返すことによって、条件を満たすペアがすべて求まる。そのペア全体Ｒ’（Ｓｒ）とする。図９Ｃの例では、Ｒ’（Ｓｒ）＝｛(５，１),(４５，２７)｝である。
【００８１】
図９Ｄは、本発明の実施態様である、値の集約処理のフローチャートを示す。
ステップ９３０では、コンピュータは、ｒｅｌａｔｉｏｎインデックスを検索し、セクションＳｃの行（以下Ｒ（Ｓｃ））を取得する。該検索はシーケンシャルに行う。
ステップ９３１では、コンピュータは、Ｒ’（Ｓｒ）とＲ（Ｓｃ）をマッチングして、Ｒ（Ｓｒ）の部分集合（以下Ｒ’（Ｓｃ））を求める。
ステップ９３２では、コンピュータは、ｕ２ｖインデックスを検索し、セクションＳａの行（以下Ｒ（Ｓａ））を取得する。該検索はシーケンシャルアクセスに限らず、下記のランダムアクセスを使用することもできる。該取得したＲ（Ｓａ）とＲ’（Ｓｃ）とをマッチングする。該マッチングによって、集約計算を行うための検索式の検索条件を満たすｖのリストを取得する。該ｖのリストが第３のリストに対応する。該ｖのリストを使用して、値の集計を行う。
ステップ９３２において、コンピュータが、ｕ２ｖインデックスを検索する場合、シーケンシャルアクセスの他に、ランダムアクセスを使用しうる。はじめの検索条件値ｖがきつく（厳しい）且つ集計対象のノード数が少ない場合は、シーケンシャルアクセスよりもランダムアクセスのほうが高速な場合がある。
【００８２】
図９Ｅは、本発明の実施態様である、シーケンシャルアクセスとランダムアクセスにおけるヒット率と実行時間との関係を示す。グラフ（９４０）の横軸は、ヒット率を示す。ＳｒとＳａとの関係がわかっている場合は、検索条件さえ分かれば、シーケンシャルアクセスとランダムアクセスのいずれが有利であるかを、例えば下記の切り替えアルゴリズムを使用して推定することが可能である。
以下に、ＳｒとＳａが１：１の場合、記号を以下のように定める
Tk ：ランダムアクセスによるｕ２ｖインデックスでのシーク時間
Tq ：シーケンシャルアクセスによるユニット当たりのリード時間
N ：Ｓａのｕ２ｖインデックスにおけるユニットの数
Nv : Ｓａのｕ２ｖインデックスにおける、検索式を満たすユニットの数
TS及びTRそれぞれをシーケンシャルアクセス及びランダムアクセスの実行時間とすると、以下のように見積もられる。
TS = Tk + N* Tq
TR = Nv * (Tk + Tq)
TS = TR を解くと，切り替えの閾値を与える Nv の値が求まる
Nv 〜 N/ (1 + (Tk/Tq))
【００８３】
図９Ｆは、本発明の実施態様である、ランダムアクセス用インデックスの概念スキーマを示す。
ランダムアクセスを行う場合は、ランダムアクセス用インデックスを使用する。ランダムアクセス用インデックスとは、セクション毎に、各ノードｉｄとｕ２ｖインデックス内のアクセスしたいＥｎｔｒｙの位置をシーケンシャルに保管したものをいう。
ランダムインデックスの概念スキーマが、表（９５１）で示される。また、表（９５０）は、前述したｕ２ｖインデックスの概念スキーマの表（５０１）と同一のものである。
表（９５１）は、ある１つのセクションについての例である。表（９５１）の各行は、ある１つのセクションに含まれる１つのノードを示す。１列目は、ユニットｉｄ（ノードｉｄと同じ）を示す。２列目は、ｕ２ｖインデックス（９５０）内において、該ノードの情報を持つＥｎｔｒｙの位置を指すＰｏｉｎｔｅｒを示す。該Ｐｏｉｎｔｅｒは、該当するセクションの先頭からのバイト数で表わされる。１列目、２列目ともに固定長である。例えば、１列目を４バイト、２列目を８バイトとすることができる。
【００８４】
図９Ｇは、本発明の実施態様である、ランダムアクセスを行う場合の、値の集約処理（９０１）のフローチャートを示す。
ステップ９６０は、ステップ９３０と同じ処理である。ステップ９６１は、ステップ９３１と同じ処理である。ステップ９６２は、ステップ９３２に対応する。ステップ９６２とステップ９３２との違いは、コンピュータが、ｕ２ｖインデックスを検索する際に、シーケンシャルアクセスではなく、ランダムアクセスインデックスを使用してランダムアクセスをする点のみである。ランダムアクセスインデックスを使用してｕ２ｖインデックスを検索する方法は、ランダムアクセスをサポートするインデックスであれば任意のものが使える。例えば、ランダムアクセスインデックス内をノードｉｄに関して二分探索し、Ｐｏｉｎｔｅｒを求める方法、ランダムアクセスインデックス内のノードｉｄをＢ−ｔｒｅｅに当てはめて、Ｐｏｉｎｔｅｒを求める方法がある。コンピュータは、ｕ２ｖインデックスの各ノードｉｄを読み込む際に、ランダムアクセスを行うことにより、集約の結果に含まれないノードｉｄの読み込みをなくすことができる。
【００８５】
テキストマイニングでは、文書データに対して大量の処理結果（名詞及び動詞などの抽出されたキーワード）を伴う。該処理結果をデータベースに格納する場合、レコード数が元文書数に対して大幅に増大することが知られている。
以下では、本発明の実施態様のプロトタイプと、関係データベースとして広く使われているＰｏｓｔｇｒｅＳＱＬとの性能を比較した結果を示す。性能比較は、２種類のデータを用いて行った。該データは、ＰＣコールセンターのログ・データ及び、生命科学のデータである。ここで、ＰＣコールセンターのログ・データを用いて行った比較を実験１、生命科学のデータを用いて行った比較を実験２とする。
【実施例１】
【００８６】
実験１で用いたデータの件数は、３２４６７７件である。図１０Ａの木構造（１０００）は、本実験１で使用したデータの構造を示す。セクション、ノードｉｄ及び値の３つ組の異なり数は、２５１５００４２である。
ＰｏｓｔｇｒｅＳＱＬのテーブルスキーマは、現在広く用いられる細分化手法で作成する。また、該テーブルスキーマは、高速化のために必要最小限のデータを扱うのに適した構造にする。具体的には、ＰｏｓｔｇｒｅＳＱＬのテーブルは、セクションごとに作成した。該テーブルは、２つのＩＮＴ列を持つ。セクションがＤｏｃｕｍｅｎｔ、Ｑｕｅｓｔｉｏｎ及びＡｎｓｗｅｒのノードに対応するテーブル列には、親ノードのノードｉｄとノードｉｄを設定した。セクションが、Ｄｏｃｕｍｅｎｔ、Ｑｕｅｓｔｉｏｎ及びＡｎｓｗｅｒ以外のノードに対応するテーブル列には、親ノードのノードｉｄと値を設定した。値が複数個ある場合は、値分のレコードを用意した。また、全てのテーブルに対して、１列目から２列目、及び２列目から１列目の両方向にＢ−ｔｒｅｅインデックスを張った。
実験１で使用したコンピュータは、Ｐｅｎｔｉｕｍ（商標）４ ３ＧＨｚのＣＰＵを２台、及び３ギガバイトのメモリーを含む。また、該コンピュータのＯＳは、Ｌｉｎｕｘ ＲＨＥＬ３．０である。
図１０Ｂは、実験１で使用した９種類のクエリを示す。表（１００１）の「・・・のどこかに・・・」という表現は、「あるセクションを持つノードの子孫ノードのどこかに」という意味である。また、集計対象のスコアは、すべてｃｏｕｎｔである。なお、表（１００１）で、ｖとして用いた値には、頻度がそれぞれ４５４３７、１６２９３、１３４０と違うものを使用した。ここで頻度とは、セクションがｄｏｃｕｍｅｎｔのノードを単位とした頻度である。頻度にばらつきを持たせたのは、検索条件を変化させたときにパフォーマンスがどのように変わるかを見るのが目的である。
また、表（１００１）の各クエリと対応するＳＱＬを以下に示す。該ＳＱＬは、該クエリをＰｏｓｔｇｒｅＳＱＬ用に変換したものである。
Q1:
select x.value, count(distinct z.value) as freq from L12 as x, B8 as z where x.pid = z.value group by x.value order by freq desc
Q2-1、Q2-2、Q2-3、Q2-4:
select x.value, count(distinct z.value) as freq from L12 as x, L12 as y, B8 as z where x.pid=z.value and y.pid=z.value and y.value=V group by x.value order by freq desc
ここで、y.value=VのVには、検索キーワードに対応するキーワードIDが入る。
Q3-1、Q3-2、Q3-3、Q3-4:
select x.value, count(distinct w.value) as freq from L12 as x, L12 as y, M9 as v, M19 as w, B8 as z where x.pid=w.value and w.pid=z.value and z.value=v.pid and v.value=y.pid and y.value=V group by x.value order by freq desc
ここで、y.value=VのVには、検索キーワードに対応するキーワードIDが入る。
また、B8、M9、M19及びL12は、それぞれ“Ｄｏｃｕｍｅｎｔ”、“Ｑｕｅｓｔｉｏｎ”、“Ａｎｓｗｅｒ”及び“Ｎｏｕｎ”のセクションに対応するテーブルを表す。
【００８７】
図１０Ｃは、実験１の結果を示す。グラフ（１００２）の横軸は、テストケースを示す。該テストケースは、表（１００１）のクエリと対応する。グラフ（１００２）の縦軸は、クエリの実行時間（秒、対数目盛）を示す。また、グラフ（１００２）の“PostgreSQL”は、ＰｏｓｔｇｒｅＳＱＬを用いた場合の集約の処理時間を示す。“SAWAN-R”は、本発明の実施形態の一つであるランダムアクセスを用いた場合の集約の処理時間を示す。“SAWAN-S”は、本発明の実施形態の一つであるシーケンシャルアクセスを用いた場合の集約の処理時間を示す。本発明の実施形態の１つであるシーケンシャルアクセスを用いた集約では、全てのテストケースにおいて、１秒前後（０．４秒〜１．１秒）の処理時間である。また、本発明の実施形態の１つであるランダムアクセスを用いた集約では、処理にかかる時間は、０．４秒〜３０．１秒である。一方、ＰｏｓｔｇｒｅＳＱＬを用いた集約では、一番処理時間が少ないテストケースである、クエリＱ３−３の例でも約３．２秒である。また、一番処理時間が多いテストケースであるクエリＱ１の例では、約３８．４秒である。
実験１の結果より、シーケンシャルアクセスを用いた集約の性能は、検索の種類に依存しないことが分かる。また、ＰｏｓｔｇｒｅＳＱＬを用いた集約は、特定の検索を行う場合にのみ優れていることがわかる。これは、Ｂ＋−Ｔｒｅｅを実装するランダムアクセスによるものである。
【実施例２】
【００８８】
実験２で使用したデータの件数は、生命科学のデータ７０００７１件である。これは、実験１で使用したデータの約２倍の数のデータである。図１０Ｄの木構造（１００３）は、該データの構造を示す。セクション、ノードｉｄ及び、値の３つ組の異なり数は、１６３９９４６７６である。これは、実験１で使用したデータの異なり数の約６．５倍以上の数である。データ件数の比約２．２（＝７０００７１÷３２４６７７）に比べて大きいのは、生命科学のデータの方が１文書中あたりのテキスト量が多く、従って１文書あたりキーワードの個数も多いためである。
実験２で使用した、ＰｏｓｔｇｒｅＳＱＬのテーブルスキーマ、クエリ及び該クエリに対応するＳＱＬは、実験１の“Ｑｕｅｓｔｉｏｎ”が“Ｔｉｔｌｅ”に及び実験１の“Ａｎｓｗｅｒ”が“ＡｂｓｔｒａｃｔＴｅｘｔ”に変わる以外は、実験１で使用したそれらと同じである。ただし、キーワードの値は、生命科学のデータから実験に適した任意のものを使用した。実験２で使用したコンピュータの構成は、実験１で使用したものと同じである。
【００８９】
図１０Ｅは、実験２で使用した９種類のクエリを示す。図１０Ｆは、実験２の結果を示す。グラフ（１００５）の横軸は、テストケースを示す。該テストケースは、表（１００４）のクエリ番号と対応する。グラフ（１００５）の縦軸は、クエリの実行時間（秒、対数目盛）を示す。グラフ（１００５）の“PostgreSQL”は、ＰｏｓｔｇｒｅＳＱＬを用いた場合の集約の処理時間を示す。“SAWAN-R”は、本発明の実施形態の一つであるランダムアクセスを用いた場合の集約の処理時間を示す。“SAWAN-S”は、本発明の実施形態の一つであるシーケンシャルアクセスを用いた場合の集約の処理時間を示す。本発明の実施形態の１つであるシーケンシャルアクセスを用いた集約では、処理にかかる時間は、１．７秒〜１３．２秒である。また、本発明の実施形態の１つであるランダムアクセスを用いた集約では、処理にかかる時間は、０．６秒〜７９．９秒である。一方、ＰｏｓｔｇｒｅＳＱＬを用いた集約では、処理にかかる時間は、２２．３秒〜１１４１．１秒である。Ｑ１のクエリのように、検索にキーワードを使用しなかった場合、ＰｏｓｔｇｒｅＳＱＬを用いて集約を求める処理は、千秒以上かかる。
【００９０】
以下に、実験１、２より得られた、本発明の実施形態による集約処理の２つの特徴を示す。本発明の実施形態による集約処理は、検索条件を指定しないときでも数秒で処理を終えることができる。また、ランダムアクセスは、検索条件が選択的である時、優れたパフォーマンスを示す可能性がある。
以上の実験結果より、本発明の実施形態の有効性がわかる。本発明の実施形態の１つであるシーケンシャルアクセスを用いた場合に、集約にかかる時間がほぼ一定である理由は、ほとんどの時間がインデックスのシーケンシャルリードに費やされているからである。シーケンシャルリードは、検索条件に依存しない。ＰｏｓｔｇｒｅＳＱＬでは、検索条件が強いほどｓｅｌｅｃｔｉｖｉｔｙが効いて高速になっているが、もっとも良く効いている場合でも本発明の実施形態の１つであるシーケンシャルアクセスに比べて２倍以上遅い。
【００９１】
図１０Ｇは、インデックスの構築にかかる時間を示す。表（１００６）は、実験１及び２で使用したデータについて、ＰｏｓｔｇｒｅＳＱＬ上でのインデックス作成処理にかかった時間と、本発明の実施形態であるインデックス作成処理にかかった時間を示す。ＰｏｓｔｇｒｅＳＱＬ上でのインデックス作成処理にかかった時間には、ＸＭＬファイルの構文解析をする時間、及びキーワードにｉｄを割り振る時間を含まない。また、入力データは、ＣＳＶ形式のデータを使用した。ＣＳＶ形式のデータは、Ｊａｖａとデータベースの接続のためのＡＰＩであるＪＤＢＣを使用してデータベースにデータを取り込む際に優れたデータである。一方、本発明の実施形態であるインデックス作成処理にかかった時間には、ＸＭＬファイルの構文解析をする時間及びキーワードにｉｄを割り振る時間を含む。
本発明の実施形態は、インデックス構築にかかる時間についても、ＲＤＢにおけるインデックス構築処理よりも速い。
【００９２】
本発明の実施態様では、インクリメンタルにインデックスを作成することができるため、複数台のコンピュータを用意し、各コンピュータ上に独立してインデックスを作成することが可能である。すなわち，システム及び処理の並列化が可能である。利用者は、並列プログラミングの規格であるＭＰＩなど既存の並列化フレームワークも利用することができる。
【００９３】
また、本発明の実施態様では、集約計算の実行時に、各コンピュータがそれぞれ独立して集約計算を実行する。最後に、集約サーバが、結果をマージしうる。集約サーバを別途独立に用意してもよいし、上記コンピュータのうちから１台を集約サーバとして選択してもよい。
【００９４】
図１１は、本発明の実施態様で使用されうるコンピュータの例を示す。該コンピュータは、ＣＰＵとメイン・メモリと含み、これらはバスに接続されている。ＣＰＵは好ましくは、３２ビットまたは６４ビットのアーキテクチャに基づくものであり、例えば、インテル社のＸｅｏｎ（商標）シリーズ、Ｃｏｒｅ（商標）シリーズ、Ｐｅｎｔｉｕｍ（商標）シリーズ、Ｃｅｌｅｒｏｎ（商標）シリーズ、ＡＭＤ社のＰｈｅｎｏｍ（商標）シリーズ、Ａｔｈｌｏｎ（商標）シリーズなどを使用することができる。ＣＰＵはさらに、その内部にキャッシュ・メモリーを含みうる。バスには、ディスプレイ・コントローラを介して、ＬＣＤモニタなどのディスプレイが接続される。ディスプレイは、コンピュータの管理のために、通信回線を介してネットワークに接続されたコンピュータについての情報と、そのコンピュータ上で動作中のソフトウェアについての情報を、適当なグラフィック・インターフェースで表示するために使用される。バスにはまた、ＩＤＥ又はＳＡＴＡコントローラを介して、ハードディスク又はシリコン・ディスクと、ＣＤ−ＲＯＭ又はＤＶＤドライブが接続される。
【００９５】
ハードディスクには、オペレーティング・システム、Ｊ２ＥＥなどのＪａｖａ（商標）処理環境を提供するプログラム、その他のプログラム及びデータが、メイン・メモリにロード可能に記憶されている。本発明の１つの実施態様として、ハードディスクは、ｕ２ｖインデックス、ｒｅｌａｔｉｏｎインデックス、ｖ２ｕインデックス、及び集約計算に使用するために上記インデックスから作成されたデータ、例えば第１のリスト、第２のリスト及び第３のリスト、並びに木構造を格納している。
【００９６】
ＣＤ−ＲＯＭ、ＤＶＤ又はＢＤドライブは、必要に応じて、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ又はＢＤからプログラムをハードディスクに追加導入するために使用される。バスには更に、キーボード・マウス・コントローラを介して、キーボード及びマウスが接続されている。
【００９７】
通信インタフェースは、例えばイーサネット（商標）・プロトコルに従うものであり、通信コントローラを介してバスに接続され、コンピュータ及び通信回線を物理的に接続する役割を担い、コンピュータのオペレーティング・システムの通信機能のＴＣＰ／ＩＰ通信プロトコルに対して、ネットワーク・インターフェース層を提供する。尚、通信回線は、有線ＬＡＮ環境、或いは例えばＩＥＥＥ８０２．１１ａ／ｂ／ｇ／ｎなどの無線ＬＡＮ接続規格に基づく無線ＬＡＮ環境であってもよい。
【図面の簡単な説明】
【００９８】
【図１Ａ】本発明の実施態様である、ＮＬＰを用いてログ・データを処理する方法を示す。
【図１Ｂ】本発明の実施態様である、ＮＬＰを用いてログ・データを処理する方法を示す。
【図２】本発明の実施態様である、２つの木構造の例を示す。
【図３】本発明の実施態様である、集約計算の結果の例を示す。
【図４】本発明の実施態様である、ノードそれぞれに後行順（post-order）でノードｉｄを割り振る例を示す。
【図５Ａ】本発明の実施態様である、ｕ２ｖインデックスの概念スキーマ及び保管の例を示す。
【図５Ｂ】本発明の実施態様である、圧縮効果の結果を示す。
【図５Ｃ】本発明の実施態様である、ｕ２ｖインデックスを作成した際のＥｎｔｒｙの例を示す。
【図６Ａ】本発明の実施態様である、ｒｅｌａｔｉｏｎインデックスの概念スキーマ及び保管の例を示す。
【図６Ｂ】本発明の実施態様である、ｒｅｌａｔｉｏｎインデックスを作成した際のＥｎｔｒｙの例を示す。
【図７Ａ】本発明の実施態様である、ｖ２ｕインデックスの概念スキーマ及び保管の例を示す。
【図７Ｂ】本発明の実施態様である、ｖ２ｕインデックスを作成した際のデータの例を示す。
【図８Ａ】本発明の実施態様である、インデックスを作成または更新する処理の全体のフローチャートを示す。
【図８Ｂ】本発明の実施態様である、ｒｅｌａｔｉｏｎインデックスを作成または更新する処理のフローチャートを示す。
【図８Ｃ】本発明の実施態様である、ｕ２ｖインデックスを作成または更新する処理のフローチャートを示す。
【図８Ｄ】本発明の実施態様である、ｖ２ｕインデックスを作成または更新する処理のフローチャートを示す。
【図８Ｅ】本発明の実施態様である、転置行列の例を示す。
【図８Ｆ】本発明の実施態様である、転置行列の書き出しの処理を示すフローチャートである。
【図９Ａ】本発明の実施態様である、集約処理の主処理を示すフローチャートである。
【図９Ｂ】本発明の実施態様である、検索条件処理のフローチャートを示す。
【図９Ｃ】本発明の実施態様である、マッチング処理のフローチャートを示す。
【図９Ｄ】本発明の実施態様である、値の集約処理のフローチャートを示す。
【図９Ｅ】本発明の実施態様である、シーケンシャルアクセスとランダムアクセスにおけるヒット率と実行時間との関係を示す。
【図９Ｆ】本発明の実施態様である、ランダムアクセス用インデックスの概念スキーマを示す。
【図９Ｇ】本発明の実施態様である、ランダムアクセスを行う場合の、値の集約処理のフローチャートを示す。
【図１０Ａ】実験１で使用した木構造を示す。
【図１０Ｂ】実験１で使用した９種類のクエリを示す。
【図１０Ｃ】実験１の結果を示すグラフである。
【図１０Ｄ】実験２で使用した木構造を示す。
【図１０Ｅ】実験２で使用した９種類のクエリを示す。
【図１０Ｆ】実験２の結果を示すグラフである。
【図１０Ｇ】インデックスの構築にかかる時間を示す。
【図１１】本発明の実施態様である、コンピュータの構成図を示す。
【技術分野】
【０００１】
本発明は、木構造のデータに対する集約計算を行うために、インデックスを作成するコンピュータ・システム、並びにその方法及びコンピュータ・プログラムに関する。さらに、本発明は、木構造のデータに対する集約計算を行うコンピュータ・システム、並びにその方法及びコンピュータ・プログラムに関する。
【背景技術】
【０００２】
リレーショナル・データベース（ＲＤＢ）における「ＧＲＯＵＰ ＢＹ」及び「ＨＡＶＩＮＧ」などとともに、集約関数を使用して値を集計するという操作が、検索及びデータベースの諸分野に見られる。該集計を効率的に行なうために、様々なインデックス及びデータフォーマットが提案されている。
【０００３】
従来の手法は、汎用的な検索及び集約に対して成果を挙げている。しかし、該手法は、集約のために冗長なデータを持っている。そのために、該手法は、大規模データに対するパフォーマンスに難がある。
【０００４】
また、ＲＤＢで一般的なＢ−ｔｒｅｅ（Ｂ＋−ｔｒｅｅ）を用いた集約についても、検索条件が緩いとき、例えばデータ全体の５０％が集計対象の場合などにおいて処理が遅いという問題がある。
【０００５】
下記特許文献１は、「Ｌａｙｅｒｅｄ Ｉｎｄｅｘ」及び「Ｐａｔｒｉｃｉａ Ｔｒｅｅ」という二種類の既存の木構造インデックスを組み合わせたインデックス構造を記載する。しかし、該インデックス構造は、検索のためにノードの数を絞り込むときには有効であるが、大量のノードを処理する必要がある場合に不向きである。また、下記特許文献２は、データフォーマットについて従来のＲＤＢのものを用いている。
【０００６】
【特許文献１】米国特許第７，２８７，０３３号明細書
【特許文献２】米国特許第７，３３０，８４８号明細書
【発明の開示】
【発明が解決しようとする課題】
【０００７】
検索及びデータベースの諸分野において、値を効率的に集計する手法が求められている。
【課題を解決するための手段】
【０００８】
本発明は、少なくとも１つのノードを含む少なくとも１つの木構造のデータに対する集約計算を行うために、インデックスを作成するコンピュータ・システムを提供する。上記ノードのそれぞれは該ノードの種類を示す１つのラベル及び任意の数の値（value）を含む。任意の数は、０個以上である。上記コンピュータ・システムは、
上記ノードそれぞれに後行順（post-order）でノードｉｄを割り振るノードｉｄ割振部と、
上記ノードそれぞれのノードｉｄと、該ノードに含まれる値とを含む１以上の組のデータを有するところの第１のインデックスを作成する第１のインデックス作成部であって、該１以上の組のデータは上記ラベル毎に作成される、上記第１のインデックス作成部と、
上記ノードそれぞれのノードｉｄと、該ノードの少なくとも１つの子孫ノードの間で最小のノードｉｄを有する子孫ノードのノードｉｄとを含む１以上の組のデータを有するところの第２のインデックスを作成する第２のインデックス作成部であって、該１以上の組のデータは上記ラベル毎に作成される、上記第２のインデックス作成部と、
特定の値を含む１以上のノードのノードｉｄを含む１以上の組のデータを有する第３のインデックスを作成する第３のインデックス作成部であって、該１以上の組のデータは上記ラベル毎の上記特定の値毎に作成される、上記第３のインデックス作成部と
を含む。集約計算を行うための検索式の結果が、上記作成し第１、第２及び第３のインデックスに基づいて、求められる。上記検索式は例えば、値、又は該値及びその頻度を集計する。特に、上記検索式は、所与のラベルを持つノードを集計単位として、該ノードの値、又は該値及びその頻度を集計する。
【０００９】
本発明の１つの実施態様では、上記第１のインデックスが、上記ノードそれぞれのノードｉｄと、該ノードに含まれる値とを含む組のデータをシーケンシャルに格納したファイルである。
【００１０】
本発明の１つの実施態様では、上記ノードそれぞれのノードｉｄと、該ノードの少なくとも１つの子孫ノードの間で最小のノードｉｄを有する子孫ノードのノードｉｄとを含む組のデータをシーケンシャルに格納したファイルであるである。
【００１１】
本発明の１つの実施態様では、上記第３のインデックスが、上記特定の値を含む１以上のノードのノードｉｄを含む１以上の組のデータをシーケンシャルに格納したファイルである。
【００１２】
本発明の１つの実施態様では、上記コンピュータ・システムはさらに、上記ラベルのそれぞれにラベルｉｄを割り振るラベルｉｄ割振部をさらに含む。
【００１３】
本発明の１つの実施態様では、上記コンピュータ・システムはさらに、上記ノードそれぞれのノードｉｄと、該ノードｉｄそれぞれに関連付けられたポインタとを含む組のデータが格納されている第４のインデックス作成部を含む。上記ポインタは上記第１のインデックスを成す上記１以上の組のデータにおけるノードｉｄのデータの位置を示す。
【００１４】
本発明はまた、少なくとも１つのノードを含む少なくとも１つの木構造のデータに対する集約計算を行うためのコンピュータ・システムを提供する。上記ノードのそれぞれは該ノードの種類を示す１つのラベル及び任意の数の値を含む。任意の数は、０個以上である。上記ノードのそれぞれは後行順（post-order）でノードｉｄを割り振られている。上記コンピュータ・システムは、
集約計算を行うための検索式を受信する受信部と
上記検索式の検索対象である値を用い及び、特定の値を含む１以上のノードのノードｉｄを含む１以上の組のデータを有するインデックスを用いて、上記検索式の検索対象である上記値を有する１以上のノードのノードｉｄを含む第１のリストを取得する第１のリスト取得部であって、該１以上の組のデータは上記ラベル毎の上記特定の値毎に作成される、上記第１のリスト取得部と、
上記取得した第１のリストを用い及び、上記ノードそれぞれのノードｉｄと、該ノードの少なくとも１つの子孫ノードの間で最小のノードｉｄを有する子孫ノードのノードｉｄとを含む１以上の組のデータを有するところのインデックスを用いて、上記検索式の検索対象である上記値を有する１以上のノードを子孫に持つ各木構造のルート・ノードの１以上のルート・ノードｉｄを含む第２のリストを取得する第２のリスト取得部であって、該１以上の組のデータは上記ラベル毎に作成される、上記第２のリスト取得部と、
上記取得した第２のリストに基づいて、上記検索式の検索対象である上記値を検索する検索部であって、上記検索式の検索対象である上記値が少なくとも１つのキーワードに対応する、上記検索部と
を含む。
【００１５】
本発明の１つの実施態様では、上記コンピュータ・システムはさらに、
上記取得した第２のリストを用いて及び、上記ノードそれぞれのノードｉｄと、該ノードに含まれる値とを含む１以上の組のデータを有するところのインデックスを用いて、上記検索式の検索条件を満たす、１以上のノードの１以上の値を含む第３のリストを取得する第３のリスト取得部であって、該１以上の組のデータは上記ラベル毎に作成される、上記第３のリスト取得部と、
上記取得した第３のリストに基づいて、上記検索式の結果を求める計算部と
を含む。
【００１６】
本発明はまた、中央演算処理ユニット、メモリー及び木構造のデータを記憶する記憶部を有するコンピュータ・システムにおいて、少なくとも１つのノードを含む少なくとも１つの木構造のデータに対する集約計算を行うために、インデックスを作成する方法を提供する。上記ノードそれぞれは、該ノードの種類を示す１つのラベル及び任意の数の値を含む。任意の数は、０個以上である。上記方法が、上記中央演算処理ユニットに下記ステップを実行させることを含む。該ステップは、
上記ノードの情報を上記メモリー内に読み込み、上記情報を読み込んだノードそれぞれに後行順（post-order）でノードｉｄを割り振るステップと、
上記ノードそれぞれのノードｉｄと、該ノードに含まれる値とを含む１以上の組のデータを有するところの第１のインデックスを作成し、該作成した第１のインデックスを上記記憶部に格納するステップであって、該１以上の組のデータは上記ラベル毎に作成される、上記第１のインデックスを格納するステップと、
上記ノードそれぞれのノードｉｄと、該ノードの少なくとも１つの子孫ノードの間で最小のノードｉｄを有する子孫ノードのノードｉｄとを含む１以上の組のデータを有するところの第２のインデックスを作成し、該作成した第２のインデックスを上記記憶部に格納するステップであって、該１以上の組のデータは上記ラベル毎に作成される、上記第２のインデックスを格納するステップと、
特定の値を含む１以上のノードのノードｉｄを含む１以上の組のデータを有する第３のインデックスを作成し、該作成した第３のインデックスを上記記憶部に格納するステップであって、該１以上の組のデータは上記ラベル毎の上記特定の値毎に作成される、上記第３のインデックスを格納するステップと
を含む。集約計算を行うための検索式の結果が、上記作成し第１、第２及び第３のインデックスに基づいて、求められる。
【００１７】
本発明の１つの実施態様では、上記第１のインデックスを上記記憶部に格納するステップが、上記ノードそれぞれのノードｉｄと、該ノードに含まれる値とを含む組のデータをシーケンシャルに格納するステップをさらに含む。
【００１８】
本発明の１つの実施態様では、上記第２のインデックスを上記記憶部に格納するステップが、上記ノードそれぞれのノードｉｄと、該ノードの少なくとも１つの子孫ノードの間で最小のノードｉｄを有する子孫ノードのノードｉｄとを含む組のデータをシーケンシャルに格納するステップをさらに含む。
【００１９】
本発明の１つの実施態様では、上記第３のインデックスを上記記憶部に格納するステップが、上記特定の値を含む１以上のノードのノードｉｄを含む１以上の組のデータをシーケンシャルに格納するステップをさらに含む。
【００２０】
本発明の１つの実施態様では、上記方法が、上記中央演算処理ユニットに下記ステップをさらに実行させることを含む。該ステップは、上記ラベルのそれぞれにラベルｉｄを割り振るステップを含む。
【００２１】
本発明の１つの実施態様では、上記方法が、上記中央演算処理ユニットに下記ステップをさらに実行させることを含む。該ステップは、
上記第１のインデックスにおける値又は上記第３のインデックスにおけるノードｉｄを圧縮するステップを含む。
【００２２】
本発明の１つの実施態様では、上記方法が、上記中央演算処理ユニットに下記ステップをさらに実行させることを含む。該ステップは、上記第１のインデックスを作成する前に、上記値が文字列である場合、該文字列を数値に置き換えるステップを含む。
【００２３】
本発明の１つの実施態様では、上記方法が、上記中央演算処理ユニットに下記ステップをさらに実行させることを含む。該ステップは、上記第３のインデックスを作成した後に、上記置き換えられた数値を、上記文字列にさらに置き換えるステップを含む。
【００２４】
本発明の１つの実施態様では、上記方法が、上記中央演算処理ユニットに下記ステップをさらに実行させることを含む。該ステップは、上記ノードそれぞれのノードｉｄと、該ノードｉｄそれぞれに関連付けられたポインタとを含む組のデータが格納されている第４のインデックスを作成するステップを含む。上記ポインタは上記第１のインデックスを成す上記１以上の組のデータにおけるノードｉｄのデータの位置を示す。
【００２５】
本発明はまた、中央演算処理ユニット、メモリー及び木構造のデータを記憶する記憶部を有するコンピュータ・システムにおいて、少なくとも１つのノードを含む少なくとも１つの木構造のデータに対する集約計算を行うために、インデックスを作成するためのコンピュータ・プログラムを提供する。上記コンピュータ・プログラムは、上記中央演算処理ユニットに上記に記載の各ステップを実行させることを含む。
【００２６】
本発明はまた、中央演算処理ユニット、メモリー及び上記木構造のデータを記憶する記憶部を有するコンピュータ・システムにおいて、少なくとも１つのノードを含む少なくとも１つの木構造のデータに対する集約計算を行う方法を提供する。上記ノードそれぞれは該ノードの種類を示す１つのラベル及び任意の数の値を含む。任意の数は、０個以上である。上記ノードそれぞれは、後行順（post-order）でノードｉｄを割り振られている。上記方法が中央演算処理ユニットに下記ステップを実行させるステップを含む。該ステップが、
集約計算を行うための検索式を受信し、該受信した検索式を上記メモリー内に記憶するステップと、
上記検索式の検索対象である値を用い及び、特定の値を含む１以上のノードのノードｉｄを含む１以上の組のデータを有するインデックスを用いて、上記検索式の検索対象である上記値を有する１以上のノードのノードｉｄを含む第１のリストを取得し、該取得した第１のリストを上記記憶部に記憶するステップであって、該１以上の組のデータは上記ラベル毎の上記特定の値毎に作成される、上記第１のリストを記憶するステップと、
上記取得した第１のリストを用い及び、上記ノードそれぞれのノードｉｄと、該ノードの少なくとも１つの子孫ノードの間で最小のノードｉｄを有する子孫ノードのノードｉｄとを含む１以上の組のデータを有するところのインデックスを用いて、上記検索式の検索対象である上記値を有する１以上のノードを子孫に持つ各木構造のルート・ノードの１以上のルート・ノードｉｄを含む第２のリストを取得し、該取得した第２のリストを上記記憶部に記憶するステップであって、該１以上の組のデータは上記ラベル毎に作成される、上記第２のリストを記憶するステップと、
上記取得した第２のリストに基づいて、上記検索式の検索対象である上記値を検索するステップであって、上記検索式の検索対象である上記値が少なくとも１つのキーワードに対応する、上記検索するステップと
を含む。
【００２７】
本発明の１つの実施態様では、上記方法が、上記中央演算処理ユニットに下記ステップをさらに実行させることを含む。該ステップは、
上記取得した第２のリストを用い及び、上記ノードそれぞれのノードｉｄと、該ノードに含まれる値とを含む１以上の組のデータを有するところのインデックスを用いて、上記検索式の検索条件を満たす、１以上のノードの１以上の値を含む第３のリストを取得し、該取得した第３のリストを上記記憶部に記憶するステップであって、該１以上の組のデータは上記ラベル毎に作成される、上記第３のリストを記憶するステップと、
上記取得した第３のリストに基づいて、上記検索式の結果を求めるステップと
を含む。
【００２８】
本発明の１つの実施態様では、上記第３のリストが、上記ノードそれぞれのノードｉｄと、該ノードに含まれる値とを含む１以上の組のデータを有するところのインデックスを用いてシーケンシャルアクセスにより取得される。
【００２９】
本発明の１つの実施態様では、上記第３のリストが、上記ノードそれぞれのノードｉｄと、該ノードに含まれる値とを含む１以上の組のデータを有するところのインデックス、及び上記ノードそれぞれのノードｉｄと、該ノードｉｄそれぞれに関連付けられたポインタとを含む組のデータが格納されているインデックスを用いてランダムアクセスにより取得される。
【００３０】
本発明の１つの実施態様では、上記第３のリストの一部が、上記ノードそれぞれのノードｉｄと、該ノードに含まれる値とを含む１以上の組のデータを有するところのインデックスを用いてシーケンシャルアクセスにより取得され、及び
上記第３のリストの残りが、上記ノードそれぞれのノードｉｄと、該ノードに含まれる値とを含む１以上の組のデータを有するところのインデックス、及び上記ノードそれぞれのノードｉｄと、該ノードｉｄそれぞれに関連付けられたポインタとを含む組のデータが格納されているインデックスを用いてランダムアクセスにより取得され、
上記第３のリストが、上記シーケンシャルアクセスと上記ランダムアクセスとを切り替えることによって取得される。
【００３１】
本発明はまた、中央演算処理ユニット、メモリー及び木構造のデータを記憶する記憶部を有するコンピュータ・システムにおいて、少なくとも１つのノードを含む少なくとも１つの木構造のデータに対する集約計算を行うためのコンピュータ・プログラムを提供する。上記コンピュータ・プログラムは、中央演算処理ユニットに上記方法に記載の各ステップを実行させることを含む。
【００３２】
本発明はまた、中央演算処理ユニット、メモリー及び木構造のデータを記憶する記憶部を有するコンピュータ・システムにおいて、少なくとも１つのノードを含む少なくとも１つの木構造のデータに対する集約計算を行う方法を提供する。上記ノードそれぞれは該ノードの種類を示す１つのラベル及び任意の数の値を含む。任意の数は、０個以上である。上記方法が、上記中央演算処理ユニットに下記ステップを実行させることを含む。該ステップが、
上記ノードの情報を上記メモリー内に読み込み、上記情報を読み込んだノードそれぞれに後行順（post-order）でノードｉｄを割り振るステップと、
上記ノードそれぞれのノードｉｄと、該ノードに含まれる値とを含む１以上の組のデータを有するところの第１のインデックスを作成し、該作成した第１のインデックスを上記記憶部に格納するステップであって、該１以上の組のデータは上記ラベル毎に作成される、上記第１のインデックスを格納するステップと、
上記ノードそれぞれのノードｉｄと、該ノードの少なくとも１つの子孫ノードの間で最小のノードｉｄを有する子孫ノードのノードｉｄとを含む１以上の組のデータを有するところの第２のインデックスを作成し、該作成した第２のインデックスを上記記憶部に格納するステップであって、該１以上の組のデータは上記ラベル毎に作成される、上記第２のインデックスを格納するステップと、
特定の値を含む１以上のノードのノードｉｄを含む１以上の組のデータを有する第３のインデックスを作成し、該作成した第３のインデックスを上記記憶部に格納するステップであって、該１以上の組のデータは上記ラベル毎の上記特定の値毎に作成される、上記第３のインデックスを格納するステップと、
上記メモリー内に記憶した集約計算を行うための検索式の検索対象である値及び上記第３のインデックスを用いて、上記検索式の検索対象である上記値を有する１以上のノードのノードｉｄを含む第１のリストを取得し、該取得した第１のリストを上記記憶部に記憶するステップと、
上記取得した第１のリスト及び上記第２のインデックスを用いて、上記検索式の検索対象である上記値を有する１以上のノードを子孫に持つ各木構造のルート・ノードの１以上のルート・ノードｉｄを含む第２のリストを取得し、該取得した第２のリストを上記記憶部に記憶するステップと、
上記取得した第２のリスト及び上記第１のインデックスを用いて、上記検索式の検索条件を満たす、１以上のノードの１以上の値を含む第３のリストを取得し、該取得した第３のリストを上記記憶部に記憶するステップと、
上記取得した第３のリストに基づいて、上記検索式の結果を求めるステップと
を含む。
【発明の効果】
【００３３】
本発明の実施態様によると、木構造のノードに含まれる値及び該値の頻度を高速に集計することが可能になる。該値は、集約計算を行うための検索式におけるキーワードに対応する。また、本発明の実施態様によると、大量のデータを木構造により扱うことが可能になる。
【発明を実施するための最良の形態】
【００３４】
以下、図面に従って、本発明の実施態様を説明する。本実施態様は、本発明の好適な態様を説明するためのものであり、本発明の範囲をここで示すものに限定する意図はないことを理解されたい。また、以下の図を通して、特に断らない限り、同一の符号は、同一の対象を指す。
【００３５】
コールセンターでは、オペレータが、顧客からの問い合わせを受けて応答を行う。コールセンターのシステムは、顧客からの問い合わせ及び該問い合わせに対する応答をログ・データとして記録しうる。ログ・データを分析し活用しようという試みは、データマイニングの分野で見られうる。例えば、「顧客からの問い合わせが、「ＸＸＸウイルス」という言葉を含む場合に、オペレータによって多く照会された言葉は、「Ａ」及び「Ｂ」のどちらなのかを求める」という分析、或いは「問い合わせと応答で使用される動詞の違いを求める」という分析が考えられる。ログ・データに記録された会話文などの文書は、多くの場合、文書に含まれる文及び単語などの任意の部分をノードとする木構造で表すことができる。木構造を集めたものは、ある問題を解決するための情報の一つになりうる。例えば、コールセンターのログ・データを表した木構造を集めたものは、過去に受けた問い合わせ及び応答の集合である。よって、オペレータがこれから発生しうる問い合わせについて応答をする際に、上記木構造を集めたものが情報として利用されうる。ログ・データに記録された会話文などの文書を木構造で表すために、自然言語処理（Natural Language Processing：ＮＬＰ）と呼ばれる技術が用いられうる。ＮＬＰとは、自然言語で記述されたテキストから、単語及び単語間の依存関係などの情報を抽出する技術である。ＮＬＰ処理によってログ・データから抜き出された単語および単語間の依存関係などの情報は、木構造に任意の方法でマッピングされうる。
【００３６】
図１Ａ及び図１Ｂは、本発明の実施態様である、ＮＬＰを用いてログ・データを処理する方法を示す。
図１Ａは、コールセンターにおけるログ・データ（１００）の例を示す。ログ・データ（１００）では、顧客からの問い合わせがＱ及びオペレータの応答がＡとして示される。
図１Ａはまた、上記ログ・データ（１００）にマークアップ言語のタグを付加したデータ（１０１）の例を示す。該タグは、ログ・データ（１００）に木構造を与えるために付加される。マークアップ言語として、例えばＸＭＬ（Extensible Markup Language）が使用されうる。タグは、ユーザーによって任意に設定されうる。タグ＜Document＞及び＜/Document＞は、該ログ・データ（１００）の種類を示す。タグ＜Q＞及び＜/Q＞は、質問部分であることを示す。タグ＜A＞及び＜/A＞は、回答部分であることを示す。
図１Ｂは、ＮＬＰを使用して該ログ・データ（１００）から文及び／又は単語を抜き出したデータ（１０２）を示す。ＮＬＰ処理を実施するためのソフトウェア技術は例えば、ＵＩＭＡ（Unstructured Information Management Architecture）である。データ（１０２）では、ログ・データ（１００）のうち、ＮＬＰ処理により抜き出された個所の前後にタグが付加されている。タグ＜expression_desire＞及び＜/expression_desire＞は、願望の表現を含む部分であることを示す。タグ＜noun＞及び＜/noun＞は、名詞を含む部分であることを示す。タグ＜verb＞及び＜/verb＞は、動詞を含む部分であることを示す。タグ＜proper_noun＞及び＜/proper_noun＞は、固有名詞を含む部分であることを示す。
図１Ｂはまた、データ（１０２）からＮＬＰ処理により抜き出されなかった個所を除いたデータ（１０３）の例を示す。データ（１０３）が、下記に述べる木構造のデータを作成するために使用されうる。
なお、データ（１０２、１０３）は、ＮＬＰ処理により抜き出されたデータのフォーマットの一例であり、図示した構造を必ずしもとるものではない。上記ＮＬＰ処理は、コールセンターのログ・データに限らず、さまざまな文書についても応用することができる。
【００３７】
図２は、本発明の実施態様である、２つの木構造（２００Ａ及び２００Ｂ）の例を示す。
木構造は、少なくとも１つのノードを含む。ノードは、ユニットともいう。木構造について、図２の木構造（２００Ａ）を用いて説明する。木構造（２００Ａ）は、ルート・ノード（２１６）及び複数のノード（２１０〜２１５）を有する。同様に、木構造（２００Ｂ）は、ルート・ノード（２２７）及び複数のノード（２２０〜２２６）を有する。各ノード（２０１）は、リンク（２０６）で結ばれる。リンクで結ばれたノード（２０１）のうち、上方に存在するノードを親ノードといい、一方下方に存在するノードを子ノードという。例えば、ノード（２１０）の親ノードは、ノード（２１４）である。例えば、ノード（２１６）の子ノードは、ノード（２１３〜２１５）である。ある親ノードから見て、子ノード、子ノードの子ノード（孫ノードである）、・・・、及び最下方に存在する子ノードをまとめて子孫ノードという。例えば、ノード（２１６）の子孫ノードは、ノード（２１０〜２１５）である。ノード（２０１）は、０個以上の子ノードを持ちうる。ノード（２０１）のうち、最上流のノードをルート・ノード（２０２）という。
【００３８】
ノード（２０１）は、データとして、セクション（２０３）及び値（２０４）を含む。
セクション（２０３）は、ノード（２０１）の種類を示すラベルである。ラベルは、ノード（２０１）毎に１つ割り当てられる。例として、ノード（２１０、２１２）のセクションには、ラベル“Ｎｏｕｎ”が割り当てられている。同様に、ノード（２１１）のセクションには、ラベル“Ｖｅｒｂ”が割り当てられている。ルート・ノード（２０２）に割り当てるセクションがない場合には、仮想のセクション（２０５）が割り当てられる。
値（２０４）は、数値、文字列、又はそれらの組み合わせを含む。１つのノード（２０１）は、０個以上の値（２０４）を含む。例として、ノード（２１３）の値は、２００７１１１２の１つであり、ノード（２１２）の値は、“Ｉｎｔｅｒｎｅｔ”及び“ｍｏｄｅｍ”の２つである。また、ノード（２１４）は値を有しないので、０個の値を含む。０個の値は、ＮＵＬＬ又は空白で表現されうる。
【００３９】
図２の木構造のデータは、上記ログ・データを木構造のデータに変換した一例を示す。木構造（２００Ａ、２００Ｂ）のそれぞれが、ログ・データ（１００）の文書を表す。
木構造（２００Ａ、２００Ｂ）のルート・ノード（２１６、２２７）の仮想セクション（２０５）は、該木構造が“ＤＯＣＵＭＥＮＴ”についてのものであることを示す。木構造（２００Ａ、２００Ｂ）のノード（２０１）それぞれが、木構造（２００Ａ、２００Ｂ）の文書の持つ情報を示す。例えば、セクションが“Ｄａｔｅ”のノード（２１３、２２３）は、文書の作成日の情報を持つことを示す。文書の作成日は、値として示される。また、セクションが“Ｑｕｅｓｔｉｏｎ”であるノード（２１４、２２４及び２２５）は、顧客からの問い合わせ内容の情報を持つことを示す。ただし、木構造（２００Ａ、２００Ｂ）では、セクションが“Ｑｕｅｓｔｉｏｎ”であるノード（２１４、２２４及び２２５）それ自体は、顧客からの問い合わせの内容を値として持たない。“Ｑｕｅｓｔｉｏｎ”のノード（２１４、２２４及び２２５）は、顧客からの問い合わせの内容をさらに種類ごとに細分化した子ノード（それぞれ２１０〜２１１、２２０及び２２１）を持つからである。例えば、子ノード（２１０〜２１１、２２０及び２２１）のうち、セクションが“Ｎｏｕｎ”であるノード（２１０、２２０及び２２１）は、問い合わせに含まれる名詞を値として持つ。セクションが“Ｖｅｒｂ”であるノード（２１１及び２２２）は、問い合わせに含まれる動詞を値として持つ。木構造のデータを作成する際に値に保存する対象はキーワードでありうる。キーワードは、問い合わせの本文中からＮＬＰ処理などの技術を用いて抽出される。抽出の方法は、慣用の方法を使用しうる。例えば、単語の出現頻度を解析して抽出する方法、大規模な単語リストを用いて抽出する方法、及び文の構造を解析して抽出する方法が用いられうる。
【００４０】
図２の木構造（２００Ａ、２００Ｂ）のデータを用いて、集約計算を説明する。
集約計算とは、与えられた任意のセクションを持つノードを集計単位として、値を集計することを意味する。集計単位とは、木構造においてノードの子孫ノードに同じ値が何回出現しても１回とカウントする基準である。集計とは例えば、値について、値及びその出現回数（頻度ともいう）の組を頻度の降順若しくは昇順に出力する処理、又は任意の集合関数を用いて計算する処理をいう。任意の集合関数は例えば、ｃｏｕｎｔ（件数）、ｓｕｍ（合計）、ｍｉｎ（最小値）、ｍａｘ（最大値）及びａｖｇ（平均）であり、ユーザーが独自に定義した関数も含みうる。
【００４１】
図３の表（３００）は、下記検索条件において、値及び頻度を降順に出力した結果を示す。
検索条件：図２の各木構造（２００Ａ、２００Ｂ）について、セクションが“Ｄｏｃｕｍｅｎｔ”であるノード（２１６、２２７）を集計単位として、セクションが“Ｎｏｕｎ”であるノード（２１０、２１２、２２０、２２１）に含まれる値及びその頻度を降順に出力する。
以下に、上記検索条件による結果を導くプロセスを示す。
最初に、ルート・ノード（２１６）を集計単位のノードとした場合を考える。集計単位であるルート・ノード（２１６）の子孫ノードであり且つセクションが“Ｎｏｕｎ”であるノードは、ノード（２１０、２１２）の２つである。ノード（２１０）の値は、“Ｉｎｔｅｒｎｅｔ”、“ＰＣ”及び“ｐｈｏｎｅ”である。ノード（２１２）の値は、“Ｉｎｔｅｒｎｅｔ”及び“ｍｏｄｅｍ”である。よって、ルート・ノード（２１６）を集計単位のノードとした場合、発生した値は、“Ｉｎｔｅｒｎｅｔ”、“ＰＣ”、“ｐｈｏｎｅ”及び“ｍｏｄｅｍ”である。ここで、“Ｉｎｔｅｒｎｅｔ”は、ノード（２１０）及びノード（２１２）の両方に重複して出現する。しかし、いずれのノード（２１０、２１２）も集計単位となるルート・ノード（２１６）の子孫ノードであるので、値“Ｉｎｔｅｒｎｅｔ”の出現回数は１回と数えられる。
次に、ルート・ノード（２２７）を集計単位のノードとした場合を考える。集計単位であるルート・ノード（２２７）の子孫ノードであり且つセクションが“Ｎｏｕｎ”であるノードは、ノード（２２０、２２１）の２つである。 ノード（２２０）の値は、“Ｉｎｔｅｒｎｅｔ”及び“ｐｈｏｎｅ”である。ノード（２２１）の値は、“Ｉｎｔｅｒｎｅｔ”及び“ｍｏｄｅｍ”である。よって、ルート・ノード（２２７）を集計単位のノードとした場合、発生した値は、“Ｉｎｔｅｒｎｅｔ”、“ｐｈｏｎｅ”及び“ｍｏｄｅｍ”である。ここで、“Ｉｎｔｅｒｎｅｔ”は、ノード（２２０）及びノード（２２１）の両方に重複して出現する。しかし、いずれのノード（２２０、２２１）も集計単位となるルート・ノード（２２７）の子孫ノードであるので、値“Ｉｎｔｅｒｎｅｔ”の出現回数は１回と数えられる。
以上より、セクションが“Ｄｏｃｕｍｅｎｔ”であるルート・ノード（２１６、２２７）を集計単位として、セクションが“Ｎｏｕｎ”であるノード（２１０、２１２、２２０、２２１）に含まれる値及びその頻度を求めた場合、値“Ｉｎｔｅｒｎｅｔ”が２回であり、値“ｍｏｄｅｍ”が２回であり、値“ｐｈｏｎｅ”が２回であり、及び値“ＰＣ”が１回である。
上記例では、ルート・ノードを集計単位のノードとして考えたが、それ以外のノードの場合にも、上記プロセスが適用される。下記にその例を示す。
【００４２】
図３の表（３０１）は、下記検索条件において、値及びその頻度を降順に出力した結果を示す。以下に、該結果を導くプロセスを示す。
検索条件：図２の各木構造（２００Ａ、２００Ｂ）について、セクションが“Ｑｕｅｓｔｉｏｎ”であるノード（２１４、２２４、２２５）を集計単位として、セクションが“Ｎｏｕｎ”であるノード（２１０、２１２、２２０、２２１）に含まれる値及びその頻度を降順に出力する。
最初に、集計単位となるノードの１つであるノード（２１４）の子孫ノードであり且つセクションが“Ｎｏｕｎ”であるノードは、ノード（２１０）である。ノード（２１０）の値は、“Ｉｎｔｅｒｎｅｔ”、“ＰＣ”及び“ｐｈｏｎｅ”である。
次に、集計単位となるノードの１つであるノード（２２４）の子孫ノードであり且つセクションが“Ｎｏｕｎ”であるノードは、ノード（２２０）である。ノード（２２０）の値は、“Ｉｎｔｅｒｎｅｔ”及び“ｐｈｏｎｅ”である。
最後に、集計単位となるノードの１つであるノード（２２５）の子孫ノードであり且つセクションが“Ｎｏｕｎ”であるノードは、ノード（２２１）である。ノード（２２１）の値は、“Ｉｎｔｅｒｎｅｔ”及び“ｍｏｄｅｍ”である。
以上より、セクションが“Ｑｕｅｓｔｉｏｎ”であるノード（２１４、２２４、２２５）を集計単位として、セクションが“Ｎｏｕｎ”であるノード（２１０、２１２、２２０、２２１）に含まれる値及びその頻度を求めた場合、値“Ｉｎｔｅｒｎｅｔ”が３回であり、値“ｐｈｏｎｅ”が２回であり、値“ｍｏｄｅｍ”が１回であり、及び値“ＰＣ”が１回である。
【００４３】
図３の表（３０２）は、下記検索条件における値の集約の結果を示す。
検索条件：図２の各木構造（２００Ａ、２００Ｂ）について、セクションが“Ｄｏｃｕｍｅｎｔ”であるノード（２１６、２２７）を集計単位として、セクションが“Ｑｕｅｓｔｉｏｎ”であるノードの子ノードであり、該子ノードのセクションが“Ｎｏｕｎ”であり、及び該子ノードに含まれる値が“Ｉｎｔｅｒｎｅｔ”である場合に、セクションが“Ａｎｓｗｅｒ”であるノードの子ノードであり、該子ノードのセクションが“Ｎｏｕｎ”であるノードの値及びその頻度を集計する。
該検索結果の値は、ノード（２１２）の値である“Ｉｎｔｅｒｎｅｔ”及び“ｍｏｄｅｍ”である。該検索結果の頻度は、“Ｉｎｔｅｒｎｅｔ”が１であり、及び“ｍｏｄｅｍ”が１である。
上記検索条件は、複雑な集約の例である。該集約は、セクションが“Ａｎｓｗｅｒ”であるノードの子ノードにおいてセクションが“Ｎｏｕｎ”であるノード（３１２）のみが集計の対象になる。該集約によって、例えば顧客がインターネットについて言及しているときに、オペレータが発している言葉の内訳を知ることができる。
【００４４】
図４は、本発明の実施態様である、各ノードに後行順（post-order）でノードｉｄを割り振る例を示す。
ノードｉｄの割り振りには、木構造の走査（traversal）方法の１つである後行順（post-order）を用いる。後行順（post-order）は、後置順とも呼ばれる。木構造に対する後行順（post-order）とは、木のルート・ノードを T、T の子要素を T1、．．．、Tk としたとき、「T1をルート・ノードとする木を後行順で処理」、「T2をルート・ノードとする木を後行順で処理」・・・「Tkをルート・ノードとする木を後行順で処理」及び「Tを処理」というように再帰的に定義される処理順序のことである。ノードｉｄは例えば、整数値でありうる。
図４の木構造４００Ａ及び４００Ｂは、図２の木構造２００Ａ及び２００Ｂにそれぞれ対応する。図４のid：１〜１５が、各ノードに割り振られたノードｉｄである。
【００４５】
以下に、木構造（４００Ａ、４００Ｂ）について、各ノードに後行順（post-order）でノードｉｄを割り振る手順を示す。
最初に、木構造（４００Ａ）のルート・ノードであるノード（４１６）を選択する。次に、ノード（４１６）の子ノードのうち、左から１番目の子ノードであるノード（４１３）を選択する。ノード（４１３）は子ノードを持たないので、ノード（４１３）にノードｉｄ：１を割り振る。次に、ノード（４１３）の親ノード（４１６）を選択する。親ノード（４１６）の子ノードのうち、左から２番目の子ノードであるノード（４１４）を選択する。ノード（４１４）はさらに子ノードを（４１０、４１１）持つため、左から１番目の子ノードであるノード（４１０）を選択する。ノード（４１０）は子ノードを持たないので、ノード（４１０）にノードｉｄ：２を割り振る。次に、ノード（４１０）の親ノード（４１４）を選択する。次に、ノード（４１４）の子ノードのうち、左から２番目の子ノードであるノード（４１１）を選択する。ノード（４１１）は子ノードを持たないので、ノード（４１１）にノードｉｄ：３を割り振る。次に、ノード（４１１）の親ノード（４１４）を選択する。ノード（４１４）の全ての子ノード（４１０、４１１）にｉｄが割り振られているので、ノード（４１４）にノードｉｄ：４を割り振る。次に、ノード（４１４）の親ノード（４１６）を選択する。ノード（４１６）の子ノードのうち、左から３番目の子ノードであるノード（４１５）を選択する。ノード（４１５）は、さらに子ノード（４１２）を持つため、左から１番目の子ノードであるノード（４１２）を選択する。ノード（４１２）は子ノードを持たないので、ノード（４１２）にノードｉｄ：５を割り振る。次に、ノード（４１２）の親ノード（４１５）を選択する。ノード（４１５）の全ての子ノード（４１２）にｉｄが割り振られているので、ノード（４１５）にノードｉｄ：６を割り振る。次に、ノード（４１５）の親ノード（４１６）を選択する。ノード（４１６）の全ての子ノード（４１３、４１４、４１５）にｉｄが割り振られているので、ノード（４１６）にノードｉｄ：７を割り振る。以上の手順により、木構造（４００Ａ）に含まれる全てのノードに、ノードｉｄが割り振られる。
引き続き別の木構造（４００Ｂ）について、各ノードに後行順（post-order）でノードｉｄを割り振る場合、ノードｉｄの割り振りは続きのid番号（上記例においては８）から始められる。木構造（４００Ｂ）について、各ノードに後行順（post-order）でノードｉｄを割り振った結果は、図４を参照されたい。
【００４６】
以下の実施態様では、図４の木構造に示されるデータを参照する。また、該木構造に示されるデータの定義は、以下の通りである。
木構造を有するデータの集合を、Ｄ＝{Ｔ１,Ｔ２,...,Ｔｉ,...,Ｔｍ}（１≦ｉ≦ｍ）で表す。ここで、ｍは少なくとも１である。各Ｔは、有限個のノードを含む。以下、記号Ｔｉを用いて、Ｔｉのルート・ノードも指す。Ｔｉに含まれるノードの個数をｎｉとする。
各ノードは、１つのセクション及び０個以上の値を有する。セクションは、ノードの種類を示す１つのラベル（ｂ）を含む。よって、上記ノードの定義において、セクションをラベルと読み替えることができる。以下では、セクションをＳで表し、値をＶＬで表す。１つのノードは、ノードの親子関係の情報のほかに、{ｂ；ＶＬ１, ＶＬ２,..., ＶＬｉ,..., ＶＬｋ}（０≦ｉ≦ｋ）という情報を有する。ここで、ｋは０であってよい。すなわち、ノードがＶＬを持たなくてもよい。本発明の１つの実施態様では、値、例えば“ｍｏｄｅｍ”のような文字列、は、一意な整数値で符号化されうる。
Ｄに現れるすべてのラベルの集合をＬ＝{ｂ１,ｂ２,...,ｂｉ,...,ｂｐ}（１≦ｂ≦ｐ）で表す。各ラベルｂｉは、圧縮に適した整数値で符号化しうる。符号化の例は、Ｄｏｃｕｍｅｎｔ＝１、Ｄａｔｅ＝２、及びＱｕｅｓｔｉｏｎ＝３である。Ｄ内の木構造を順次読んでいき、未知のラベルが出現した場合は、その都度、新しい整数値がそのラベルに割り振られうる。
上記ルート・ノードのセクションは、全て等しいものである必要はない。なぜならば、後述する集約単位のセクションＳｃに対して、その子孫ノードに対するｊｏｉｎ操作をすることにより、上記ルート・ノードのセクションが全て等しい場合と同じ結果を得ることができるからである。
【００４７】
本発明の実施態様では、木構造のデータに対する集約計算を行うために、３つのインデックス、すなわち第１のインデックス、第２のインデックス及び第３のインデックスを作成する。
【００４８】
第１のインデックス（以下ｕ２ｖインデックス）とは、ノードそれぞれのノードｉｄと、該ノードに含まれる値とを含む１以上の組のデータを保管したものをいう。ｕ２ｖインデックスにおいて、該組のデータは、セクション毎に作成される。本発明の１つの実施態様では、ｕ２ｖインデックスは、上記組のデータをシーケンシャルに格納している。
図５Ａは、本発明の実施態様である、ｕ２ｖインデックスの概念スキーマ及び保管の例を示す。ｕ２ｖインデックスの概念スキーマは、セクション・ポインター・ツリー（５００）及び表（５０１、５０２）で示される。セクション・ポインター・ツリー（５００）は、表（５０１）の各行へのポインタの集合データを示す。表（５０１）の各行は、１セクション分のインデックスを示す。１列目は、行のサイズである。２列目は、セクションに対応するノードの数である。３列目以降は、セクションに対応するノードの数分のＥｎｔｒｙである。表（５０２）は、Ｅｎｔｒｙの詳細を示す。１列目は、ノードｉｄを示す。２列目は、ノードｉｄが割り振られたノードに含まれる値の数を示す。３列目以降は、ノードｉｄが割り振られたノードに含まれる値を示す。本発明の１つの実施態様として、３列目以降に設定される値は、差分圧縮されうる。差分圧縮の方法については後述する。
【００４９】
１セクション分のｕ２ｖインデックスのデータフォーマットは、次の通りである。該データフォーマットは、テーブル（５０１）の１行目に対応する。
{byte_size_of_array}(N:number_of_nodes)
[id_1][M1:number_of_values_1]
<value_1,1><value_1,2 -value_1,1>...<value_1,M1- value_1,M1-1>
[id_2][M2:number_of_values_2]
<value_2,1><value_2,2 -value_2,1>...<value_2,M2- value_2,M2-1>
......
[id_N][MN:number_of_value_N]
<value_N,1><value_N,2 -value_N,1>...<value_N,MN- value_N,MN-1>
上記データフォーマット内の改行は、見易さのためであり、データに含まれない。また、{}、()、[]及び<>などの区切りは、論理的なデータの区切りを表示するためのものであり、データに含まれない。{}は、非圧縮long(8bytes)を意味する。()は、非圧縮int(4bytes)を意味する。非圧縮とは、２の補数表記による標準的な符号化のことをいう。また、[]は、圧縮intを意味する。<>は、差分圧縮intを意味する。圧縮は、可変長の符号化でありうる。
byte_size_of_arrayは、先頭の[id_1]から最後の<value_N,MN - value_N,MN-1>までのバイト列の長さを示す。Nは、格納されているノードの数を示す。idは、ノードｉｄを示す。アンダーバーの後に続く値は、ノードを識別するために振った表記上の番号である。Mは、値の数を示す。Mの右下付で示された値は、ノードを識別するために振った表記上の番号である。valueは、値である。アンダーバーの後に続く値は、ノードを識別するために振った表記上の番号である。カンマの後に続く値は、値を識別するために振った表記上の番号である。
ｕ２ｖインデックスとは、全てのセクションに対して上記データフォーマットを作り、連結したものである。本発明の１つの実施態様として、該データフォーマットは、シーケンシャルに連結されている。セクションが例えば２種類しかなければ、該データフォーマットは次の通りである。
{byte_size_of_array}(N1:number_of_nodes)
[id_1][M1:number_of_values_1]
<value_1,1><value_1,2 -value_1,1>...<value_1,M1- value_1,M1-1>
......
[id_N1][MN1:number_of_value_N1]
<value_N1,1><value_N1,2 -value_N1,1>...<value_N1,MN1- value_N1,MN1-1>
{byte_size_of_array}(N2:number_of_nodes)
[id_1][M1:number_of_values_1]
<value_1,1><value_1,2 -value_1,1>...<value_1,M1- value_1,M1-1>
......
[id_N2][MN2:number_of_value_N2]
<value_N2,1><value_N2,2 -value_N2,1>...<value_N2,MN2- value_N2,MN2-1>
【００５０】
上記データフォーマットは、インデックス作成効率向上のために、できるだけコンピュータのメモリー上に記憶しておくのが好ましい。しかし、該メモリーの容量にも限界があるため、該コンピュータは、一定量のデータがメモリー内に蓄積されると該データをファイルに書き出す。ファイルに書き出すタイミングは例えば、処理済みのノード数で判断される。例えば、ファイルの書き出しは、１０００００ノードごとに行われる。データフォーマットからわかるように、複数のファイルに分割された場合でも、該ファイルのマージは容易である。
【００５１】
本発明の実施形態では、任意の圧縮方法を使用しうる。例えば、一般にギャップ符号化（Ｇａｐ ｃｏｄｉｎｇ）という名前で知られている全文検索エンジン ルシーン（Ｌｕｃｅｎｅ）で用いられる手法と同じものを用いる。ギャップ符号化は、単調に増大する整数列（例：１、４、３７、５１、８０、...）について差分をとる方法である。例えば、あるノードが（１、４、３７、５１、８０）という５個の値を持つとする。最初に、この手法では、値を昇順に並べる。次に、前の値との差分を求める。該差分を（１、３、３３、１４、２９）という数列に変換し、変換後の各値を「小さい数字に対し、より小さなビット数を割り当てるように」符号化する。復号化の際は、直前の値を覚えておき（初期値は０）、各数字を順に復号したあと直前の値に足すことを繰り返せばよい。この方法によって、特に１つのノードに多くの値が含まれるときに高い圧縮率が得られる。
図５Ａの表（５０２）の例では、最小の値であるvalue[１]を３列目に設定する。次に、２番目に小さい値であるvalue[２]と最小の値であるvalue[１]の差分を４列目に設定する。以下、同様の処理を繰り返す。最後に、最大の値であるvalue[Ｍ]と２番目に大きい値である［Ｍ−１］の差分を最終列に設定する。
【００５２】
差分をとったあとの圧縮手法について、例えば下記手法が知られている。
可変長符号化（Ｖａｒｉａｂｌｅ−ｌｅｎｇｔｈ ｃｏｄｅ）法は、ハフマン符号化、ランレングス符号化、算術符号化及び適応ビット割当に分けられる。
ガンマ符号化（Ｇａｍｍａ ｃｏｄｅ）法は、整数を２進数で表現し、そのビット数から１を引いた数の「０」と、整数を２進数で表現した値を合わせた値を、出力する手法である。
ゴーロム符号化（Ｇｏｌｕｍｂ ｃｏｄｅ）法は、次の三つの手順により構成される。
１．はじめに、floor(n/m)を計算し、このunarycodeを出力する。ここで、floor(x)はxを上回らない最大整数、また正数aのunary codeはa個の“0”とそれに続く１個の“1”から構成される符号“00・・・01”、をそれぞれ表す。
２．続いて、n/mの剰余mod(n/m)を計算し、それをfloor(log2(m))桁のバイナリ符号で表したものを出力する。
３．両者をこの順番で結合したものがnのゴーロム符号となる。
【００５３】
図５Ｂの表（５０３）は、圧縮効果の結果を示す。圧縮の比較に使用したデータは、コールセンターのログ・データ３２４６７７件である。比較は、セクションごとに作成したｕ２ｖインデックスファイルを用いて行った。表（５０３）１列目は、任意のセクションを示す。２列目の非圧縮時のインデックスのファイル・サイズ（Ａ）は、圧縮を行わなかった場合のｕ２ｖインデックスファイルのファイル・サイズを示す。３列目の圧縮時のインデックスのファイル・サイズ（Ｂ）は、可変長符号化（Ｖａｒｉａｂｌｅ−ｌｅｎｇｔｈ ｃｏｄｅ）法で圧縮したｕ２ｖインデックスファイルのファイル・サイズを示す。４列目の圧縮率は、圧縮を行った場合と行わなかった場合のファイル・サイズの圧縮率（％）を示す。
表（５０３）に見られるように、圧縮率はセクションの種類によって異なる。圧縮を行った場合、ｕ２ｖインデックスファイルのファイル・サイズは、圧縮を行わなかった場合から３５％〜５２％のサイズを減らしたサイズになる。
【００５４】
図５Ｃの表（５０４）は、本発明の実施態様である、各木構造（４００Ａ、４００Ｂ）のデータからｕ２ｖインデックスを作成した際のＥｎｔｒｙの例を示す。但し、１列目、「セクション」の列は、説明のために追加した列である。表（５０４）の値に示されている値は、キーワードを示している。本発明の１つの実施態様では、該値は数値に変換される。本発明のさらなる実施態様では、該数値は圧縮される。
【００５５】
木構造（４００Ａ、４００Ｂ）のデータから、セクションがＮｏｕｎであるノード（４１０、４１２、４２０、４２１）及びセクションがＶｅｒｂであるノード（４１１、４２２）について、ｕ２ｖインデックスを作成する例を、以下に示す。
最初に、セクションがＮｏｕｎであるノード（４１０、４１２、４２０及び４２１）について示す。
ノード（４１０）のノードｉｄは、２である。従って、表（５０４）のセクションがＮｏｕｎの行のＥｎｔｒｙ［１］のノードｉｄの列には、２が設定される。ノード（４１０）の持つ値は、Ｉｎｔｅｒｎｅｔ、ＰＣ、ｐｈｏｎｅの３つである。従って、セクションがＮｏｕｎの行のＥｎｔｒｙ［１］の値の数の列には、３が設定される。セクションがＮｏｕｎの行のＥｎｔｒｙ［１］の値の列には、Ｉｎｔｅｒｎｅｔ、ＰＣ、ｐｈｏｎｅが設定される。
ノード（４１２）のノードｉｄは、５である。従って、表（５０４）のセクションがＮｏｕｎの行のＥｎｔｒｙ［２］のノードｉｄの列には、５が設定される。ノード（４１２）の持つ値は、Ｉｎｔｅｒｎｅｔ、ｍｏｄｅｍの２つである。従って、セクションがＮｏｕｎの行のＥｎｔｒｙ［２］の値の数の列には、２が設定される。セクションがＮｏｕｎの行のＥｎｔｒｙ［２］の値の列には、Ｉｎｔｅｒｎｅｔ、ｍｏｄｅｍが設定される。
ノード（４２０）のノードｉｄは、９である。従って、表（５０４）のセクションがＮｏｕｎの行のＥｎｔｒｙ［３］のノードｉｄの列には、９が設定される。ノード（４２０）の持つ値は、Ｉｎｔｅｒｎｅｔ、ｐｈｏｎｅの２つである。よって、セクションがＮｏｕｎの行のＥｎｔｒｙ［３］の値の数の列には、２が設定される。セクションがＮｏｕｎの行のＥｎｔｒｙ［３］の値の列には、Ｉｎｔｅｒｎｅｔ、ｐｈｏｎｅが設定される。
ノード（４２１）のノードｉｄは、１１である。従って、表（５０４）のセクションがＮｏｕｎの行のＥｎｔｒｙ［４］のノードｉｄの列には、１１が設定される。ノード（４２１）の持つ値は、Ｉｎｔｅｒｎｅｔ、ｍｏｄｅｍの２つである。従って、セクションがＮｏｕｎの行のＥｎｔｒｙ［４］の値の数の列には、２が設定される。セクションがＮｏｕｎの行のＥｎｔｒｙ［４］の値の列には、Ｉｎｔｅｒｎｅｔ、ｍｏｄｅｍが設定される。
次に、セクションがＶｅｒｂであるノード（４１１、４２２）について示す。
ノード（４１１）のノードｉｄは、３である。従って、表（５０４）のセクションがＶｅｒｂの行のＥｎｔｒｙ［１］のノードｉｄの列には、３が設定される。ノード（４１１）の持つ値は、ｃｏｎｎｅｃｔ、ｔｙｐｅの２つである。従って、セクションがＶｅｒｂの行のＥｎｔｒｙ［１］の値の数の列には、２が設定される。セクションがＶｅｒｂの行のＥｎｔｒｙ［１］の値の列には、ｃｏｎｎｅｃｔ、ｔｙｐｅが設定される。
ノード（４２２）のノードｉｄは、１３である。従って、表（５０４）のセクションがＶｅｒｂの行のＥｎｔｒｙ［２］のノードｉｄの列には、１３が設定される。ノード（４２２）の持つ値は、ｃｏｎｎｅｃｔ、ｒｅａｄの２つである。従って、Ｖｅｒｂの行のＥｎｔｒｙ［２］の値の数の列には、２が設定される。Ｖｅｒｂの行のＥｎｔｒｙ［２］の値の列には、ｃｏｎｎｅｃｔ、ｒｅａｄが設定される。
【００５６】
ｕ２ｖインデックスは、ファイルに保管される。該ファイルは、１つのファイルである必要はなく、複数のファイルでよい。実装では、各セクションに対するｕ２ｖインデックスのオフセットを記録したファイル（図示せず）にセクション・ポインター・ツリー（５００）も書き出す。該ファイルには、対応する開始位置、すなわち何バイト目から始まるかの位置を保管する。この保管形式は任意でよい。例えば、Ｂ−ｔｒｅｅが用いられる。
【００５７】
第２のインデックス（以下、ｒｅｌａｔｉｏｎインデックス）とは、ノードそれぞれのノードｉｄと、該ノードの少なくとも１つの子孫ノードの間で最小のノードｉｄを有する子孫ノードのノードｉｄとを含む１以上の組のデータを保管したものをいう。ｒｅｌａｔｉｏｎインデックスにおいて、該組のデータは、セクション毎に作成される。本発明の１つの実施態様では、ｒｅｌａｔｉｏｎインデックスは、上記組のデータをシーケンシャルに格納している。
図６Ａは、本発明の実施態様である、ｒｅｌａｔｉｏｎインデックスの概念スキーマ及び保管の例を示す。ｒｅｌａｔｉｏｎインデックスの概念スキーマは、セクション・ポインター・ツリー（６００）及び表（６０１、６０２）で示される。セクション・ポインター・ツリー（６００）は、表（６０１）の各行へのポインタの集合データを示す。表（６０１）の各行は、１セクション分のインデックスを示す。１列目は、行のサイズである。２列目は、セクションに対応するノードの数である。３列目以降は、セクションに対応するノードの数分のＥｎｔｒｙである。表（６０２）は、Ｅｎｔｒｙの詳細を示す。１列目は、ノードｉｄを示す。２列目は、子孫ノードのノードｉｄのうち、最小のｉｄを示す。
【００５８】
１セクション分のｒｅｌａｔｉｏｎインデックスのデータフォーマットは、次の通りである。該データフォーマットは、テーブル（６０１）の１行目に対応する。
{byte_size_of_array}(N:number_of_nodes)
[id_1][min_id_1][id_2][min_id_2]......[id_N][min_id_N]
上記データフォーマット内の改行は、見易さのためであり、データに含まれない。また、{}、()、[]などの区切りは、論理的なデータの区切りを表示するためのものであり、データに含まれない。{}は非圧縮long(8bytes)を意味する。()は、非圧縮int(4bytes)を意味する。非圧縮とは、２の補数表記による標準的な符号化のことを示す。また、[]は圧縮intを意味する。圧縮は、可変長の符号化でありうる。
byte_size_of_arrayは、先頭の[id_1]から最後の[min_id_N]までのバイト列の長さを示す。Nは、格納されているノードの数を示す。idは、ノードiｄを示す。アンダーバーの後に続く値は、ノードを識別するために振った表記上の番号である。min_idは、同じ表記上の番号が振られたノードｉｄの子孫ノードのうち、最小のノードｉｄを持つノードのノードｉｄを示す。
【００５９】
図６Ｂの表（６０３）は、本発明の実施態様である、各木構造（４００Ａ、４００Ｂ）のデータからｒｅｌａｔｉｏｎインデックスを作成した際のＥｎｔｒｙの例を示す。但し、１列目、「セクション」の列は、説明のために追加した列である。
【００６０】
上記データフォーマットは、インデックス作成効率向上のために、できるだけコンピュータのメモリー上に記憶しておくのが好ましい。しかし、該メモリーの容量にも限界があるため、該コンピュータは、一定量のデータがメモリー内に蓄積されると該データをファイルに書き出す。ファイルに書き出すタイミングは例えば、処理済みのノード数で判断される。例えば、ファイルの書き出しは、１０００００ノードごとに行われる。データフォーマットからわかるように、複数のファイルに分割された場合でも、該ファイルのマージは容易である。
【００６１】
木構造（４００Ａ、４００Ｂ）のデータからｒｅｌａｔｉｏｎインデックスを作成する例を、以下に示す。
セクションがＤｏｃｕｍｅｎｔであるノード（４１６、４２７）について考える。対応するインデックスは、表（６０３）の２行目、セクションが“Ｄｏｃｕｍｅｎｔ”の行である。ノード（４１６）のノードｉｄは、７である。従って、表（６０３）の２列目、「ノードｉｄ」に７を設定する。ノード（４１６）の子孫ノード（４１０〜４１５）のうち、最小のノードｉｄを持つノードは、ノード（４１３）である。ノード（４１３）のノードｉｄは、１である。従って、表（６０３）の３列目、「最小のノードｉｄ」に１を設定する。ノード（４２７）のノードｉｄは、１５である。従って、表（６０３）の４列目、「ノードｉｄ」に１５を設定する。ノード（４２７）の子孫ノード（４２０〜４２６）のうち、最小のノードｉｄを持つノードは、ノード（４２３）である。ノード（４２３）のノードｉｄは、１である。従って、表（６０３）の５列目、「最小のノードｉｄ」に８を設定する。
セクションがＱｕｅｓｔｉｏｎであるノード（４１４、４２４、４２５）について考える。対応するインデックスは、表（６０３）の３行目、セクションが“Ｑｕｅｓｔｉｏｎ”の行である。ノード（４１４）のノードｉｄは、４である。従って、表（６０３）の２列目、「ノードｉｄ」に４を設定する。ノード（４１４）の子孫ノード（４１０〜４１１）のうち、最小のノードｉｄを持つノードは、ノード（４１０）である。ノード（４１０）のノードｉｄは、２である。従って、表（６０３）の３列目、「最小のノードｉｄ」に２を設定する。ノード（４２４）のノードｉｄは、１０である。従って、表（６０３）の４列目、「ノードｉｄ」に１０を設定する。ノード（４２４）の子孫ノード（４２０）のうち、最小のノードｉｄを持つノードは、ノード（４２０）である。ノード（４２０）のノードｉｄは、９である。従って、表（６０３）の５列目、「最小のノードｉｄ」に９を設定する。ノード（４２５）のノードｉｄは、１２である。従って、表（６０３）の６列目、「ノードｉｄ」に１２を設定する。ノード（４２５）の子孫ノード（４２１）のうち、最小のノードｉｄを持つノードは、ノード（４２１）である。ノード（４２１）のノードｉｄは、１１である。従って、表（６０３）の７列目、「最小のノードｉｄ」に１１を設定する。
セクションがＡｎｓｗｅｒであるノード（４１５、４２６）について考える。対応するインデックスは、表（６０３）の４行目、セクションが“Ａｎｓｗｅｒ”の行である。ノード（４１５）のノードｉｄは、６である。従って、表（６０３）の２列目、「ノードｉｄ」に６を設定する。ノード（４１５）の子孫ノード（４１２）のうち、最小のノードｉｄを持つノードは、ノード（４１２）である。ノード（４１２）のノードｉｄは、５である。従って、表（６０３）の３列目、「最小のノードｉｄ」に５を設定する。ノード（４２６）のノードｉｄは、１４である。従って、表（６０３）の４列目、「ノードｉｄ」に１４を設定する。ノード（４２６）の子孫ノード（４２２）のうち、最小のノードｉｄを持つノードは、ノード（４２２）である。ノード（４２２）のノードｉｄは、１３である。従って、表（６０３）の５列目、「最小のノードｉｄ」に１３を設定する。
セクションがＤａｔｅ、Ｎｏｕｎ及びＶｅｒｂであるノード（４１３、４１０、４１１、４１２、４２３、４２０、４２１及び４２２）は、子孫ノードを持たない。このような子ノードを持たないノードであるリーフノードに対しては、ｒｅｌａｔｉｏｎインデックスは作成されない。
【００６２】
ｒｅｌａｔｉｏｎインデックスは、ファイルに保管される。該ファイルは、１つのファイルである必要はなく、複数のファイルでよい。実装では、各セクションに対するｒｅｌａｔｉｏｎインデックスのオフセットを記録したファイル（図示せず）にセクション・ポインター・ツリー（６００）も書き出す。該ファイルには、対応する開始位置、すなわち何バイト目から始まるかの位置を保管する。この保管形式は任意でよい。例えば、Ｂ−ｔｒｅｅが用いられる。
【００６３】
第３のインデックス（以下ｖ２ｕインデックス）とは、特定の値を含む１以上のノードのノードｉｄを含む１以上の組のデータを保管したものをいう。ｖ２ｕインデックスにおいて、該組のデータは、ラベル毎に且つ特定の値毎に作成される。本発明の１つの実施態様では、ｖ２ｕインデックスは、上記組のデータをシーケンシャルに格納している。ｖ２ｕインデックスは、各ノードの値から、該値を含むセクションのノードｉｄの一覧を検索できるデータフォーマットをとる。
図７Ａは、本発明の実施態様である、ｖ２ｕインデックスの概念スキーマ及び保管の例を示す。ｖ２ｕインデックスの概念スキーマは、セクション・ポインター・ツリー（７００）、セクションに対応する数のハッシュ構造（７０１）及びハッシュ構造に対応する表（７０２）で示される。セクション・ポインター・ツリー（７００）は、セクションごとに用意されたハッシュ構造（７０１）へのポインタの集合データを示す。ハッシュ構造（７０１）は、表（７０２）に示す各行へのポインタの集合データを示す。表（７０２）の各行は、特定の値毎のインデックスを示す。１列目は、行のサイズである。２列目は、特定の値を有するノードの数である。３列目以降は、特定の値を有するノードのノードｉｄである。本発明の１つの実施態様では、表（７０２）の３列目以降に含まれるノードｉｄは、ｕ２ｖインデックスの例と同様に圧縮される。
【００６４】
図７Ｂの表（７０３）は、本発明の実施態様である、各木構造（４００Ａ、４００Ｂ）のデータからセクションがＮｏｕｎであるノード（４１０、４１２、４２０、４２１）について、ｖ２ｕインデックスを作成した際のデータの例を示す。但し、１列目、「値」の列は、説明のために追加した列であり、ｖ２ｕインデックスに含まれない。また、本発明の１つの実施態様として、ノードｉｄは、圧縮されている。
【００６５】
１セクション分の１つの値に対するｖ２ｕインデックスのデータフォーマットは、次の通りである。データフォーマットは、表（７０２）の１行目と対応する。
{byte_size_of_array}(N:number_of_nodes)
<id,1><id,2 - id,1>...<id,N1- id,N1-1>
上記データフォーマット内の改行は、見易さのためであり、データに含まれない。また、{}、()、<>などの区切りは、論理的なデータの区切りを表示するためのものであり、データに含まれない。{}は、非圧縮long(8bytes)を意味する。()は、非圧縮int(4bytes)を意味する。非圧縮とは、２の補数表記による標準的な符号化のことをいう。<>は、差分圧縮intを意味する。圧縮は、可変長の符号化でありうる。
byte_size_of_arrayは、先頭の<id,1>から最後の<id,N1 - id,N1-1>までのバイト列の長さを示す。Nは、格納されているノードの数を示す。idはノードｉｄを示す。カンマの後に続く値は、ノードを識別するために振った表記上の番号である。
【００６６】
上記データフォーマットは、インデックス作成効率向上のために、できるだけコンピュータのメモリー上に記憶しておくのが好ましい。しかし、該メモリーの容量にも限界があるため、該コンピュータは、一定量のデータがメモリー内に蓄積されると該データをファイルに書き出す。ファイルに書き出すタイミングは例えば、処理済みのノード数で判断される。例えば、ファイルの書き出しは、１０００００ノードごとに行われる。データフォーマットからわかるように、複数のファイルに分割された場合でも、該ファイルのマージは容易である。
【００６７】
木構造（４００Ａ、４００Ｂ）のデータから、セクションがＮｏｕｎであるノード（４１０、４１２、４２０、４２１）について、ｖ２ｕインデックスを作成する例を、以下に示す。
セクションがＮｏｕｎであるノード（４１０、４１２、４２０及び４２１）のうち、値にｉｎｔｅｒｎｅｔを持つノードは、ノード（４１０、４１２、４２０及び４２１）である。従って、表（７０２）の１行目には、ノード（４１０、４１２、４２０、４２１）のノードｉｄである、２、５、９、１１が設定される。
セクションがＮｏｕｎであるノード（４１０、４１２、４２０及び４２１）のうち、値にＰＣを持つノードは、ノード（４１０）である。従って、表（７０２）の２行目には、ノード（４１０）のノードｉｄである、２が設定される。
セクションがＮｏｕｎであるノード（４１０、４１２、４２０及び４２１）のうち、値にｍｏｄｅｍを持つノードは、ノード（４１２、４２１）である。従って、表（７０２）の３行目には、ノード（４１２、４２１）のノードｉｄである、５、１１が設定される。
セクションがＮｏｕｎであるノード（４１０、４１２、４２０及び４２１）のうち、値にｐｈｏｎｅを持つノードは、ノード（４１０、４２０）である。従って、表（８０２）の４行目には、ノード（４１０、４２０）のノードｉｄである、２、９が設定される。
【００６８】
ｖ２ｕインデックスは、ファイルに保管される。該ファイルは、１つのファイルである必要はなく、複数のファイルでよい。実装では、各セクションに対するｖ２ｕインデックスのオフセットを記録したファイル（図示せず）にセクション・ポインター・ツリー（７００）も書き出す。該ファイルには、対応する開始位置、すなわち何バイト目から始まるかの位置を保管する。この保管形式は、任意でありうる。例えば、Ｂ−ｔｒｅｅが用いられる。さらに、value（値）が与えられたとき、表（７０２）の各行にランダムアクセスするためのポインタをハッシュ（７０１）で保持する。このハッシュの仕組みは，value（値）に対して定数時間でポインタの値を引くことができれば任意で良い。また、ハッシュもセクションごとに作成するため、セクションからハッシュ構造へのポインタも保持する。
【００６９】
図８Ａ〜図８Ｆは、インデックスの作成のフローチャート及びそれに付随する図を示す。
フローチャートで使用する用語を以下に説明する。木構造をＴで表す。また、|Ｔ|と記載した場合、|Ｔ|は、Ｔの持つノードの個数を表す。木構造（４００Ａ）の例では、|Ｔ|＝７である。ノードをＮで表す。ノードＮの持つセクションを、Ｎ.ｓｅｃｔｉｏｎで表す。ノードＮの持つ値を、Ｎ．Ｖａｌｕｅｓで表す。ノードＮに割り振られたノードｉｄをＮ．ｕｎｉｔＩｄで表す。また、セクションは、あらかじめ数値に変換されているものとする。例えば、“Ｄｏｃｕｍｅｎｔ”＝１であり、“Ｑｕｅｓｔｉｏｎ”＝２であり、“Ｎｏｕｎ”＝３などである。
ノード（４１０）の例では、Ｎ.ｓｅｃｔｉｏｎは、“Ｎｏｕｎ”＝３であり、Ｎ．valuesは、“Ｉｎｔｅｒｎｅｔ”、“ＰＣ”及び“ｐｈｏｎｅ”であり、Ｎ．ｕｎｉｔＩｄは２である。
【００７０】
図８Ａは、本発明の実施態様である、インデックスを作成または更新する処理の全体のフローチャートを示す。
ステップ８００では、コンピュータが、変数currentUnitIdを０で初期化する。currentUnitIdは、コンピュータが処理対象の木構造にノードｉｄを割り振る際の初期値を保管する変数である。０での初期化は、最初に振られるノードｉｄが０であることを示す。本発明の１つの実施態様として、値が文字列である場合、該文字列を数値に置き換えることが可能である。
ステップ８０１では、コンピュータが、処理対象の木構造がまだ存在するかの判定を行う。処理対象の木構造がある場合、ステップ８０２に進む。全ての木構造について処理済みであれば、ステップ８０７に進む。
ステップ８０２では、コンピュータが、後続のステップ（８０３〜８０６）で用いる木構造を選択する処理である。後続のステップ（８０３〜８０６）は木構造の単位で処理を行う。
ステップ８０３では、ステップ８０２で選択した木構造について、コンピュータが、後行順でノードｉｄを割り振る。ノードｉｄの開始値には、currentUnitIdを用いる。
ステップ８０４では、コンピュータが、Ｒｅｌａｔｉｏｎインデックスを作成または更新する。Ｒｅｌａｔｉｏｎインデックス及び該処理については、後述する。
ステップ８０５では、コンピュータが、ｕ２ｖインデックスを作成または更新する。ｕ２ｖインデックス及び該処理については、後述する。ステップ８０４とステップ８０５は、どちらのステップを先に実行してもかまわない。
ステップ８０６では、コンピュータが、変数currentUnitIdに|Ｔ|を加える処理を行う。該処理で求めた値は、次に処理対象とする木にノードｉｄを割り振る際の初期値になる。
ステップ８０７では、コンピュータが、ｖ２ｕインデックスを作成または更新する。本発明の１つの実施態様として、ｖ２ｕインデックスを作成または更新後に、上記文字列が数値に置き換えられた値について、該数値を文字列に再び置き換えることが可能である。
【００７１】
図８Ｂは、本発明の実施態様である、ｒｅｌａｔｉｏｎインデックスを作成または更新する処理のフローチャートを示す。また、図８Ｂは、図８Ａのステップ（８０４）の詳細を示す。該フローチャートは、１つの木構造Ｔについてのものである。
ステップ８１０では、コンピュータが、木のノードを、ｕｎｉｔＩｄの小さい順に並べる。
ステップ８１１では、コンピュータが、処理対象のノードがまだ残っているかの判定を行う。処理対象のノードがある場合は、ステップ８１２に進む。全てのノードについて処理済みであれば、処理を終了し、図８Ａのステップ８０５へ進む。
ステップ８１２では、コンピュータが、木構造ＴからノードＮを取り出す。
ステップ８１３では、コンピュータが、ステップ８１２で取り出したノードＮの子孫ノードのうち、ノードｉｄが最少のノードを選択する。ここで、ノードｉｄが最少のノードをＮ´とする。
ステップ８１４では、コンピュータが、ステップ８１２で取り出したノードＮが持つノードｉｄ、及びステップ８１３で選択したノードＮ´が持つノードｉｄをｒｅｌａｔｉｏｎインデックスに追加する。追加先は、ノードＮに設定されたセクションに対応する個所である。上記追加先は、セクション・ポインター・ツリーから求めることができる。コンピュータは、セクション・ポインター・ツリーから該セクションを指すポインタを取得し、ｒｅｌａｔｉｏｎインデックスにおいて、そのポインタの指す先の最後尾にノードＮが持つノードｉｄ及びノードＮ´が持つノードｉｄを追加すればよい、新規のセクションの場合は、セクション・ポインター・ツリーに、該セクションを指すポインタを追加する。コンピュータは、ｒｅｌａｔｉｏｎインデックスの設定項目であるノードの数及び行のサイズを更新する。
【００７２】
図８Ｃは、本発明の実施態様である、ｕ２ｖインデックスを作成または更新する処理のフローチャートを示す。また、図８Ｃは、図８Ａのステップ８０５の詳細を示す。該フローチャートは、１つの木構造Ｔについてのものである。
ステップ８２０では、コンピュータが、木のノードを、ｕｎｉｔＩｄの小さい順に並べる。
ステップ８２１では、コンピュータが、処理対象のノードがまだ残っているかの判定を行う。処理対象のノードがある場合は、ステップ８２２に進む。全てのノードについて処理済みであれば、処理を終了し、図８Ａのステップ８０６へ進む。
ステップ８２２では、コンピュータが、木構造ＴからノードＮを取り出す。
ステップ８２３では、コンピュータが、ステップ８２２で取り出したノードＮが持つノードｉｄ、値及び値の数をｕ２ｖインデックスに追加する。追加先は、ノードＮに設定されたセクションに対応する個所である。上記追加先は、セクション・ポインター・ツリーから求めることができる。コンピュータは、セクション・ポインター・ツリーから該セクションを指すポインタを取得し、ｕ２ｖインデックスにおいて、そのポインタの指す先の最後尾にノードＮが持つノードｉｄ、値及び値の数を追加すればよい、新規のセクションの場合は、セクション・ポインター・ツリーに、該セクションを指すポインタを追加する。差分圧縮を行う場合は、該ステップで行う。コンピュータは、ｕ２ｖインデックスの設定項目であるノードの数及び行のサイズを更新する。
【００７３】
図８Ｄは、本発明の実施態様である、ｖ２ｕインデックスを作成または更新する処理のフローチャートを示す。
ステップ８３０では、コンピュータが、処理対象のセクションがまだ残っているかの判定を行う。処理対象のセクションがある場合は、ステップ８３１に進む。全てのセクションについて処理済みであれば、処理を終了する。
ステップ８３１では、コンピュータが、転置行列Ｉを作成する。コンピュータは、Ｓｅｃｔｉｏｎ Ｓを１つ選び、ｕ２ｖインデックスからセクションＳに対応する部分を読み込む。そして、コンピュータは、該読み込んだデータから転置行列Ｉを作成する。転置行列については後述する。
ステップ８３２では、コンピュータが、転置行列を書き出す。転置行列とは、ｕ２ｖインデックス内のデータを、各値に対してその値を含むノードのノードｉｄを保持する形式に変換したものである。転置行列は、検索エンジンのインデックスとして一般的な行列である。上記書き出す処理については後述する。該書き出す処理が終了したら、コンピュータは、再びステップ８３０に処理を戻す。
コンピュータは、ステップ（８３０〜８３２）の処理を、処理するセクションがなくなるまで繰り返す。
【００７４】
図８Ｅは、本発明の実施態様である、転置行列の例を示す。
表（８４０）は、あるセクションにおけるｕ２ｖインデックス内のデータの例を示す。該データの例は、転置行列に変換する前のデータの例に相当する。表（８４１）は、表（８４０）のデータを、転置行列に変換した例を示す。本願発明の１つの実施態様では、表に含まれる値は、数字で表現されうる。
表（８４０）において、値“Ｉｎｔｅｒｎｅｔ”は、ノードｉｄが２、５、９、１１の行に含まれる。値“ＰＣ”は、ノードｉｄが２の行に含まれる。値“ｐｈｏｎｅ”は、ノードｉｄが２、９の行に含まれる。値“ｍｏｄｅｍ”は、ノードｉｄが５、１１の行に含まれる。値“ｋｅｙｂｏａｒｄ”は、ノードｉｄが１１の行に含まれる。この関係を表したものが、表（８４１）で示す転置行列になる。
【００７５】
図８Ｆは、本発明の実施態様である、転置行列の書き出しの処理を示すフローチャートである。該フローチャートは、セクションごとに実施される。
ステップ８５０では、コンピュータが、ｖ２ｕの値ハッシュの初期化を行う。値ハッシュとは、図７Ａのハッシュ構造（７０１）を示す。コンピュータは、空の値ハッシュを新規作成する。コンピュータは、値ハッシュにポインタを設定するための変数であるｐｏｉｎｔｅｒに、０をセットする。
ステップ８５１では、コンピュータが、処理対象の値がまだ残っているかの判定を行う。コンピュータは、処理対象の値がある場合は、ステップ８５２に進む。コンピュータは、全ての値について処理済みであれば、図８Ｄのステップ８３０に進む。
ステップ８５２では、コンピュータが、圧縮リストＣＬ（ｖ）を作成する。圧縮リストＣＬ（ｖ）は、図７Ａの表（７０２）における各行に対応するデータを指す。コンピュータは、値ｖを１つ選ぶ。コンピュータは、ステップ（８３１）で作成した転置行列Ｉから、該値ｖに対応するノードｉｄを読み出す。コンピュータは、該読み出したノードｉｄ、ノードｉｄの数及び、該ノードｉｄと該ノードｉｄの数のサイズを用いて、圧縮リストＣＬ（ｖ）作成する。本発明の１つの実施態様では、該ノードｉｄは差分圧縮される。
ステップ８５３では、コンピュータが、値ハッシュ及びｖ２ｕインデックスにデータを設定する。コンピュータは、値ｖとｐｏｉｎｔｅｒの組を、値ハッシュに追加する。
また、コンピュータは、ＣＬ（ｖ）をｖ２ｕインデックスに追加する。コンピュータは、ｖ２ｕインデックスが存在しない場合は、ｖ２ｕインデックスを作成する。
ステップ８５４では、コンピュータが、ｐｏｉｎｔｅｒにＣＬ（ｖ）のサイズを加える。該ステップの処理が終了したら、コンピュータは、再びステップ８５１に処理を戻す。
コンピュータは、ステップ（８５１〜８５４）の処理を、処理する値がなくなるまで繰り返す。
【００７６】
図９Ａ〜図９Ｃは、本発明の実施態様である、インデックスを用いた集約処理のフローチャートを示す。
該フローチャートにおける入力パラメータの定義は、以下の通りである。
検索条件値をｖとする。ｖは例えば、検索エンジンを使うときに用いるキーワードに該当する。例えば、値 “ｐｈｏｎｅ”（電話）が該当する。また、単一の値の代わりに、値の任意の論理式を用いることもできる。ｖの例は、「ｐｈｏｎｅ ａｎｄ Ｉｎｔｅｒｎｅｔ」である。
検索条件セクションをＳｓとする。Ｓｓは、ｖを含むセクションの指定であり、ｖとのペアで意味を持つ。Ｓｓの例は、「Ａｎｓｗｅｒセクションの中に値“ｐｈｏｎｅ”が存在するような木に関して集約する。」という場合におけるＡｎｓｗｅｒセクションである。
ルートセクションをＳｒとする。Ｓｒは、集約対象の木構造のルート・ノードのセクションの指定である。Ｓｒの例は、Ｄｏｃｕｍｅｎｔである。
集約対象セクションをＳａとする。Ｓａは、集約する値を含むセクションの指定である。Ｓａの例は、「Ｎｏｕｎセクションの値を集約する。」場合におけるＮｏｕｎセクションである。
集約単位セクションをＳｃとする。Ｓｃは、集約関数を適用する単位の指定であり、Ｓａとのペアで意味を持つ。Ｓｃの例は、「Ｑｕｅｓｔｉｏｎセクションの単位で、Ｎｏｕｎセクションの値を集約する。」場合における、Ｑｕｅｓｔｉｏｎセクションである。
集約処理の出力は、ｖと、集約関数ｆのｖ上での値ｆ(ｖ)との組(ｖ, ｆ(ｖ))のリストで表される。以下、ｆ(ｖ)＝(ｖのＳｃ単位の出現回数)とする。ｆとして任意の集約関数を用いることもできる。
【００７７】
図９Ａは、本発明の実施態様である、集約処理の主処理を示すフローチャートである。該主処理には、入力パラメータとして、ｖ、Ｓｓ、Ｓｒ、Ｓａ、Ｓｃが与えられる。該主処理は、検索条件処理（９００）及び値集約処理（９０１）を実行する。
【００７８】
図９Ｂは、本発明の実施態様である、検索条件処理（９００）のフローチャートを示す。該検索条件処理（９００）では、ｖ２ｕインデックス及びｒｅｌａｔｉｏｎインデックスを使用して、値、すなわちキーワードが求められうる。
ステップ９１０では、コンピュータが、セクションＳｓを用いてｖ２ｕインデックスの検索を行い、圧縮リスト（以下ＣＬ（ｖ））を取得する。１つの実施態様として、該検索はシーケンシャルに行われる。
ステップ９１１では、コンピュータが、ステップ９１０で取得したＣＬ（ｖ）を解凍し、ノードｉｄのリスト（以下Ｌ（ｖ））を取得する。該ノードｉｄのリストが、第１のリストに対応する。
ステップ９１２では、コンピュータが、ｒｅｌａｔｉｏｎインデックスを検索して、セクションＳｒの行（以下Ｒ（Ｓｒ））を取得する。１つの実施態様として、該検索は、シーケンシャルに行われうる。
ステップ９１３では、コンピュータが、Ｌ（ｖ）とＲ（Ｓｒ）のマッチングを行い、Ｒ（Ｓｒ）の部分集合（以下Ｒ’（Ｓｒ））を取得する。該Ｒ’（Ｓｒ）が、第２のリストに対応する。
【００７９】
図９Ｃは、本発明の実施態様である、マッチング処理のフローチャートを示す。
図９Ｃは、例としてＬ（ｖ）とＲ（Ｓｒ）とのマッチング処理を示す。Ｌ（ｖ）の行に含まれる各数値は、ｖを持つノードのノードｉｄを示す。例えば、リスト（９２０）において、ノードｉｄの各数値は、３，７，１６，２０及び３８である。また、Ｒ（Ｓｒ）の行に含まれる各数値は、セクションＳｒを持つノードのノードｉｄと、そのノードｉｄを持つノードの子孫ノードのうち最小のノードｉｄを持つノードのノードｉｄの組を示す。例えば、リスト（９２０）において、（５，１）、（１５，１０）及び（４５，２７）の各組が、ノードｉｄの組である。なお、（５，１）という表記は、５がセクションＳｒのノードｉｄであり、１が、ノードｉｄが５であるノードの子孫ノードの持つノードｉｄのうちの最小のノードｉｄであることを意味する。
他のデータについてのマッチング処理についても上記と同様である。
【００８０】
図９Ｃのマッチング処理の手順は、以下の通りである。
コンピュータは、カーソル（９２４）を各リスト（Ｌ（ｖ）、Ｒ（Ｓｒ））の先頭にセットする（９２１）。
コンピュータは、Ｌ（ｖ）のカーソルが指すノードｉｄが、Ｒ（Ｓｒ）の指す値のペアの範囲に入っているかどうかチェックし、入っていたらそのペアを、メモリー上に保管する。マッチング対象のリスト（９２１）の例では、３は範囲（５,１）に入っているため、コンピュータは、（５，１）をメモリー上に保管する（９２１）。
次に、コンピュータは、Ｌ（ｖ）のカーソルを、ノードｉｄの値が現在のＲ（Ｓｒ）のペアの範囲を越えるまで（すなわち、７）移動する（９２２）。
次に、コンピュータは、Ｒ（Ｓｒ）のカーソルを移動する。
上記を繰り返すことによって、条件を満たすペアがすべて求まる。そのペア全体Ｒ’（Ｓｒ）とする。図９Ｃの例では、Ｒ’（Ｓｒ）＝｛(５，１),(４５，２７)｝である。
【００８１】
図９Ｄは、本発明の実施態様である、値の集約処理のフローチャートを示す。
ステップ９３０では、コンピュータは、ｒｅｌａｔｉｏｎインデックスを検索し、セクションＳｃの行（以下Ｒ（Ｓｃ））を取得する。該検索はシーケンシャルに行う。
ステップ９３１では、コンピュータは、Ｒ’（Ｓｒ）とＲ（Ｓｃ）をマッチングして、Ｒ（Ｓｒ）の部分集合（以下Ｒ’（Ｓｃ））を求める。
ステップ９３２では、コンピュータは、ｕ２ｖインデックスを検索し、セクションＳａの行（以下Ｒ（Ｓａ））を取得する。該検索はシーケンシャルアクセスに限らず、下記のランダムアクセスを使用することもできる。該取得したＲ（Ｓａ）とＲ’（Ｓｃ）とをマッチングする。該マッチングによって、集約計算を行うための検索式の検索条件を満たすｖのリストを取得する。該ｖのリストが第３のリストに対応する。該ｖのリストを使用して、値の集計を行う。
ステップ９３２において、コンピュータが、ｕ２ｖインデックスを検索する場合、シーケンシャルアクセスの他に、ランダムアクセスを使用しうる。はじめの検索条件値ｖがきつく（厳しい）且つ集計対象のノード数が少ない場合は、シーケンシャルアクセスよりもランダムアクセスのほうが高速な場合がある。
【００８２】
図９Ｅは、本発明の実施態様である、シーケンシャルアクセスとランダムアクセスにおけるヒット率と実行時間との関係を示す。グラフ（９４０）の横軸は、ヒット率を示す。ＳｒとＳａとの関係がわかっている場合は、検索条件さえ分かれば、シーケンシャルアクセスとランダムアクセスのいずれが有利であるかを、例えば下記の切り替えアルゴリズムを使用して推定することが可能である。
以下に、ＳｒとＳａが１：１の場合、記号を以下のように定める
Tk ：ランダムアクセスによるｕ２ｖインデックスでのシーク時間
Tq ：シーケンシャルアクセスによるユニット当たりのリード時間
N ：Ｓａのｕ２ｖインデックスにおけるユニットの数
Nv : Ｓａのｕ２ｖインデックスにおける、検索式を満たすユニットの数
TS及びTRそれぞれをシーケンシャルアクセス及びランダムアクセスの実行時間とすると、以下のように見積もられる。
TS = Tk + N* Tq
TR = Nv * (Tk + Tq)
TS = TR を解くと，切り替えの閾値を与える Nv の値が求まる
Nv 〜 N/ (1 + (Tk/Tq))
【００８３】
図９Ｆは、本発明の実施態様である、ランダムアクセス用インデックスの概念スキーマを示す。
ランダムアクセスを行う場合は、ランダムアクセス用インデックスを使用する。ランダムアクセス用インデックスとは、セクション毎に、各ノードｉｄとｕ２ｖインデックス内のアクセスしたいＥｎｔｒｙの位置をシーケンシャルに保管したものをいう。
ランダムインデックスの概念スキーマが、表（９５１）で示される。また、表（９５０）は、前述したｕ２ｖインデックスの概念スキーマの表（５０１）と同一のものである。
表（９５１）は、ある１つのセクションについての例である。表（９５１）の各行は、ある１つのセクションに含まれる１つのノードを示す。１列目は、ユニットｉｄ（ノードｉｄと同じ）を示す。２列目は、ｕ２ｖインデックス（９５０）内において、該ノードの情報を持つＥｎｔｒｙの位置を指すＰｏｉｎｔｅｒを示す。該Ｐｏｉｎｔｅｒは、該当するセクションの先頭からのバイト数で表わされる。１列目、２列目ともに固定長である。例えば、１列目を４バイト、２列目を８バイトとすることができる。
【００８４】
図９Ｇは、本発明の実施態様である、ランダムアクセスを行う場合の、値の集約処理（９０１）のフローチャートを示す。
ステップ９６０は、ステップ９３０と同じ処理である。ステップ９６１は、ステップ９３１と同じ処理である。ステップ９６２は、ステップ９３２に対応する。ステップ９６２とステップ９３２との違いは、コンピュータが、ｕ２ｖインデックスを検索する際に、シーケンシャルアクセスではなく、ランダムアクセスインデックスを使用してランダムアクセスをする点のみである。ランダムアクセスインデックスを使用してｕ２ｖインデックスを検索する方法は、ランダムアクセスをサポートするインデックスであれば任意のものが使える。例えば、ランダムアクセスインデックス内をノードｉｄに関して二分探索し、Ｐｏｉｎｔｅｒを求める方法、ランダムアクセスインデックス内のノードｉｄをＢ−ｔｒｅｅに当てはめて、Ｐｏｉｎｔｅｒを求める方法がある。コンピュータは、ｕ２ｖインデックスの各ノードｉｄを読み込む際に、ランダムアクセスを行うことにより、集約の結果に含まれないノードｉｄの読み込みをなくすことができる。
【００８５】
テキストマイニングでは、文書データに対して大量の処理結果（名詞及び動詞などの抽出されたキーワード）を伴う。該処理結果をデータベースに格納する場合、レコード数が元文書数に対して大幅に増大することが知られている。
以下では、本発明の実施態様のプロトタイプと、関係データベースとして広く使われているＰｏｓｔｇｒｅＳＱＬとの性能を比較した結果を示す。性能比較は、２種類のデータを用いて行った。該データは、ＰＣコールセンターのログ・データ及び、生命科学のデータである。ここで、ＰＣコールセンターのログ・データを用いて行った比較を実験１、生命科学のデータを用いて行った比較を実験２とする。
【実施例１】
【００８６】
実験１で用いたデータの件数は、３２４６７７件である。図１０Ａの木構造（１０００）は、本実験１で使用したデータの構造を示す。セクション、ノードｉｄ及び値の３つ組の異なり数は、２５１５００４２である。
ＰｏｓｔｇｒｅＳＱＬのテーブルスキーマは、現在広く用いられる細分化手法で作成する。また、該テーブルスキーマは、高速化のために必要最小限のデータを扱うのに適した構造にする。具体的には、ＰｏｓｔｇｒｅＳＱＬのテーブルは、セクションごとに作成した。該テーブルは、２つのＩＮＴ列を持つ。セクションがＤｏｃｕｍｅｎｔ、Ｑｕｅｓｔｉｏｎ及びＡｎｓｗｅｒのノードに対応するテーブル列には、親ノードのノードｉｄとノードｉｄを設定した。セクションが、Ｄｏｃｕｍｅｎｔ、Ｑｕｅｓｔｉｏｎ及びＡｎｓｗｅｒ以外のノードに対応するテーブル列には、親ノードのノードｉｄと値を設定した。値が複数個ある場合は、値分のレコードを用意した。また、全てのテーブルに対して、１列目から２列目、及び２列目から１列目の両方向にＢ−ｔｒｅｅインデックスを張った。
実験１で使用したコンピュータは、Ｐｅｎｔｉｕｍ（商標）４ ３ＧＨｚのＣＰＵを２台、及び３ギガバイトのメモリーを含む。また、該コンピュータのＯＳは、Ｌｉｎｕｘ ＲＨＥＬ３．０である。
図１０Ｂは、実験１で使用した９種類のクエリを示す。表（１００１）の「・・・のどこかに・・・」という表現は、「あるセクションを持つノードの子孫ノードのどこかに」という意味である。また、集計対象のスコアは、すべてｃｏｕｎｔである。なお、表（１００１）で、ｖとして用いた値には、頻度がそれぞれ４５４３７、１６２９３、１３４０と違うものを使用した。ここで頻度とは、セクションがｄｏｃｕｍｅｎｔのノードを単位とした頻度である。頻度にばらつきを持たせたのは、検索条件を変化させたときにパフォーマンスがどのように変わるかを見るのが目的である。
また、表（１００１）の各クエリと対応するＳＱＬを以下に示す。該ＳＱＬは、該クエリをＰｏｓｔｇｒｅＳＱＬ用に変換したものである。
Q1:
select x.value, count(distinct z.value) as freq from L12 as x, B8 as z where x.pid = z.value group by x.value order by freq desc
Q2-1、Q2-2、Q2-3、Q2-4:
select x.value, count(distinct z.value) as freq from L12 as x, L12 as y, B8 as z where x.pid=z.value and y.pid=z.value and y.value=V group by x.value order by freq desc
ここで、y.value=VのVには、検索キーワードに対応するキーワードIDが入る。
Q3-1、Q3-2、Q3-3、Q3-4:
select x.value, count(distinct w.value) as freq from L12 as x, L12 as y, M9 as v, M19 as w, B8 as z where x.pid=w.value and w.pid=z.value and z.value=v.pid and v.value=y.pid and y.value=V group by x.value order by freq desc
ここで、y.value=VのVには、検索キーワードに対応するキーワードIDが入る。
また、B8、M9、M19及びL12は、それぞれ“Ｄｏｃｕｍｅｎｔ”、“Ｑｕｅｓｔｉｏｎ”、“Ａｎｓｗｅｒ”及び“Ｎｏｕｎ”のセクションに対応するテーブルを表す。
【００８７】
図１０Ｃは、実験１の結果を示す。グラフ（１００２）の横軸は、テストケースを示す。該テストケースは、表（１００１）のクエリと対応する。グラフ（１００２）の縦軸は、クエリの実行時間（秒、対数目盛）を示す。また、グラフ（１００２）の“PostgreSQL”は、ＰｏｓｔｇｒｅＳＱＬを用いた場合の集約の処理時間を示す。“SAWAN-R”は、本発明の実施形態の一つであるランダムアクセスを用いた場合の集約の処理時間を示す。“SAWAN-S”は、本発明の実施形態の一つであるシーケンシャルアクセスを用いた場合の集約の処理時間を示す。本発明の実施形態の１つであるシーケンシャルアクセスを用いた集約では、全てのテストケースにおいて、１秒前後（０．４秒〜１．１秒）の処理時間である。また、本発明の実施形態の１つであるランダムアクセスを用いた集約では、処理にかかる時間は、０．４秒〜３０．１秒である。一方、ＰｏｓｔｇｒｅＳＱＬを用いた集約では、一番処理時間が少ないテストケースである、クエリＱ３−３の例でも約３．２秒である。また、一番処理時間が多いテストケースであるクエリＱ１の例では、約３８．４秒である。
実験１の結果より、シーケンシャルアクセスを用いた集約の性能は、検索の種類に依存しないことが分かる。また、ＰｏｓｔｇｒｅＳＱＬを用いた集約は、特定の検索を行う場合にのみ優れていることがわかる。これは、Ｂ＋−Ｔｒｅｅを実装するランダムアクセスによるものである。
【実施例２】
【００８８】
実験２で使用したデータの件数は、生命科学のデータ７０００７１件である。これは、実験１で使用したデータの約２倍の数のデータである。図１０Ｄの木構造（１００３）は、該データの構造を示す。セクション、ノードｉｄ及び、値の３つ組の異なり数は、１６３９９４６７６である。これは、実験１で使用したデータの異なり数の約６．５倍以上の数である。データ件数の比約２．２（＝７０００７１÷３２４６７７）に比べて大きいのは、生命科学のデータの方が１文書中あたりのテキスト量が多く、従って１文書あたりキーワードの個数も多いためである。
実験２で使用した、ＰｏｓｔｇｒｅＳＱＬのテーブルスキーマ、クエリ及び該クエリに対応するＳＱＬは、実験１の“Ｑｕｅｓｔｉｏｎ”が“Ｔｉｔｌｅ”に及び実験１の“Ａｎｓｗｅｒ”が“ＡｂｓｔｒａｃｔＴｅｘｔ”に変わる以外は、実験１で使用したそれらと同じである。ただし、キーワードの値は、生命科学のデータから実験に適した任意のものを使用した。実験２で使用したコンピュータの構成は、実験１で使用したものと同じである。
【００８９】
図１０Ｅは、実験２で使用した９種類のクエリを示す。図１０Ｆは、実験２の結果を示す。グラフ（１００５）の横軸は、テストケースを示す。該テストケースは、表（１００４）のクエリ番号と対応する。グラフ（１００５）の縦軸は、クエリの実行時間（秒、対数目盛）を示す。グラフ（１００５）の“PostgreSQL”は、ＰｏｓｔｇｒｅＳＱＬを用いた場合の集約の処理時間を示す。“SAWAN-R”は、本発明の実施形態の一つであるランダムアクセスを用いた場合の集約の処理時間を示す。“SAWAN-S”は、本発明の実施形態の一つであるシーケンシャルアクセスを用いた場合の集約の処理時間を示す。本発明の実施形態の１つであるシーケンシャルアクセスを用いた集約では、処理にかかる時間は、１．７秒〜１３．２秒である。また、本発明の実施形態の１つであるランダムアクセスを用いた集約では、処理にかかる時間は、０．６秒〜７９．９秒である。一方、ＰｏｓｔｇｒｅＳＱＬを用いた集約では、処理にかかる時間は、２２．３秒〜１１４１．１秒である。Ｑ１のクエリのように、検索にキーワードを使用しなかった場合、ＰｏｓｔｇｒｅＳＱＬを用いて集約を求める処理は、千秒以上かかる。
【００９０】
以下に、実験１、２より得られた、本発明の実施形態による集約処理の２つの特徴を示す。本発明の実施形態による集約処理は、検索条件を指定しないときでも数秒で処理を終えることができる。また、ランダムアクセスは、検索条件が選択的である時、優れたパフォーマンスを示す可能性がある。
以上の実験結果より、本発明の実施形態の有効性がわかる。本発明の実施形態の１つであるシーケンシャルアクセスを用いた場合に、集約にかかる時間がほぼ一定である理由は、ほとんどの時間がインデックスのシーケンシャルリードに費やされているからである。シーケンシャルリードは、検索条件に依存しない。ＰｏｓｔｇｒｅＳＱＬでは、検索条件が強いほどｓｅｌｅｃｔｉｖｉｔｙが効いて高速になっているが、もっとも良く効いている場合でも本発明の実施形態の１つであるシーケンシャルアクセスに比べて２倍以上遅い。
【００９１】
図１０Ｇは、インデックスの構築にかかる時間を示す。表（１００６）は、実験１及び２で使用したデータについて、ＰｏｓｔｇｒｅＳＱＬ上でのインデックス作成処理にかかった時間と、本発明の実施形態であるインデックス作成処理にかかった時間を示す。ＰｏｓｔｇｒｅＳＱＬ上でのインデックス作成処理にかかった時間には、ＸＭＬファイルの構文解析をする時間、及びキーワードにｉｄを割り振る時間を含まない。また、入力データは、ＣＳＶ形式のデータを使用した。ＣＳＶ形式のデータは、Ｊａｖａとデータベースの接続のためのＡＰＩであるＪＤＢＣを使用してデータベースにデータを取り込む際に優れたデータである。一方、本発明の実施形態であるインデックス作成処理にかかった時間には、ＸＭＬファイルの構文解析をする時間及びキーワードにｉｄを割り振る時間を含む。
本発明の実施形態は、インデックス構築にかかる時間についても、ＲＤＢにおけるインデックス構築処理よりも速い。
【００９２】
本発明の実施態様では、インクリメンタルにインデックスを作成することができるため、複数台のコンピュータを用意し、各コンピュータ上に独立してインデックスを作成することが可能である。すなわち，システム及び処理の並列化が可能である。利用者は、並列プログラミングの規格であるＭＰＩなど既存の並列化フレームワークも利用することができる。
【００９３】
また、本発明の実施態様では、集約計算の実行時に、各コンピュータがそれぞれ独立して集約計算を実行する。最後に、集約サーバが、結果をマージしうる。集約サーバを別途独立に用意してもよいし、上記コンピュータのうちから１台を集約サーバとして選択してもよい。
【００９４】
図１１は、本発明の実施態様で使用されうるコンピュータの例を示す。該コンピュータは、ＣＰＵとメイン・メモリと含み、これらはバスに接続されている。ＣＰＵは好ましくは、３２ビットまたは６４ビットのアーキテクチャに基づくものであり、例えば、インテル社のＸｅｏｎ（商標）シリーズ、Ｃｏｒｅ（商標）シリーズ、Ｐｅｎｔｉｕｍ（商標）シリーズ、Ｃｅｌｅｒｏｎ（商標）シリーズ、ＡＭＤ社のＰｈｅｎｏｍ（商標）シリーズ、Ａｔｈｌｏｎ（商標）シリーズなどを使用することができる。ＣＰＵはさらに、その内部にキャッシュ・メモリーを含みうる。バスには、ディスプレイ・コントローラを介して、ＬＣＤモニタなどのディスプレイが接続される。ディスプレイは、コンピュータの管理のために、通信回線を介してネットワークに接続されたコンピュータについての情報と、そのコンピュータ上で動作中のソフトウェアについての情報を、適当なグラフィック・インターフェースで表示するために使用される。バスにはまた、ＩＤＥ又はＳＡＴＡコントローラを介して、ハードディスク又はシリコン・ディスクと、ＣＤ−ＲＯＭ又はＤＶＤドライブが接続される。
【００９５】
ハードディスクには、オペレーティング・システム、Ｊ２ＥＥなどのＪａｖａ（商標）処理環境を提供するプログラム、その他のプログラム及びデータが、メイン・メモリにロード可能に記憶されている。本発明の１つの実施態様として、ハードディスクは、ｕ２ｖインデックス、ｒｅｌａｔｉｏｎインデックス、ｖ２ｕインデックス、及び集約計算に使用するために上記インデックスから作成されたデータ、例えば第１のリスト、第２のリスト及び第３のリスト、並びに木構造を格納している。
【００９６】
ＣＤ−ＲＯＭ、ＤＶＤ又はＢＤドライブは、必要に応じて、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ又はＢＤからプログラムをハードディスクに追加導入するために使用される。バスには更に、キーボード・マウス・コントローラを介して、キーボード及びマウスが接続されている。
【００９７】
通信インタフェースは、例えばイーサネット（商標）・プロトコルに従うものであり、通信コントローラを介してバスに接続され、コンピュータ及び通信回線を物理的に接続する役割を担い、コンピュータのオペレーティング・システムの通信機能のＴＣＰ／ＩＰ通信プロトコルに対して、ネットワーク・インターフェース層を提供する。尚、通信回線は、有線ＬＡＮ環境、或いは例えばＩＥＥＥ８０２．１１ａ／ｂ／ｇ／ｎなどの無線ＬＡＮ接続規格に基づく無線ＬＡＮ環境であってもよい。
【図面の簡単な説明】
【００９８】
【図１Ａ】本発明の実施態様である、ＮＬＰを用いてログ・データを処理する方法を示す。
【図１Ｂ】本発明の実施態様である、ＮＬＰを用いてログ・データを処理する方法を示す。
【図２】本発明の実施態様である、２つの木構造の例を示す。
【図３】本発明の実施態様である、集約計算の結果の例を示す。
【図４】本発明の実施態様である、ノードそれぞれに後行順（post-order）でノードｉｄを割り振る例を示す。
【図５Ａ】本発明の実施態様である、ｕ２ｖインデックスの概念スキーマ及び保管の例を示す。
【図５Ｂ】本発明の実施態様である、圧縮効果の結果を示す。
【図５Ｃ】本発明の実施態様である、ｕ２ｖインデックスを作成した際のＥｎｔｒｙの例を示す。
【図６Ａ】本発明の実施態様である、ｒｅｌａｔｉｏｎインデックスの概念スキーマ及び保管の例を示す。
【図６Ｂ】本発明の実施態様である、ｒｅｌａｔｉｏｎインデックスを作成した際のＥｎｔｒｙの例を示す。
【図７Ａ】本発明の実施態様である、ｖ２ｕインデックスの概念スキーマ及び保管の例を示す。
【図７Ｂ】本発明の実施態様である、ｖ２ｕインデックスを作成した際のデータの例を示す。
【図８Ａ】本発明の実施態様である、インデックスを作成または更新する処理の全体のフローチャートを示す。
【図８Ｂ】本発明の実施態様である、ｒｅｌａｔｉｏｎインデックスを作成または更新する処理のフローチャートを示す。
【図８Ｃ】本発明の実施態様である、ｕ２ｖインデックスを作成または更新する処理のフローチャートを示す。
【図８Ｄ】本発明の実施態様である、ｖ２ｕインデックスを作成または更新する処理のフローチャートを示す。
【図８Ｅ】本発明の実施態様である、転置行列の例を示す。
【図８Ｆ】本発明の実施態様である、転置行列の書き出しの処理を示すフローチャートである。
【図９Ａ】本発明の実施態様である、集約処理の主処理を示すフローチャートである。
【図９Ｂ】本発明の実施態様である、検索条件処理のフローチャートを示す。
【図９Ｃ】本発明の実施態様である、マッチング処理のフローチャートを示す。
【図９Ｄ】本発明の実施態様である、値の集約処理のフローチャートを示す。
【図９Ｅ】本発明の実施態様である、シーケンシャルアクセスとランダムアクセスにおけるヒット率と実行時間との関係を示す。
【図９Ｆ】本発明の実施態様である、ランダムアクセス用インデックスの概念スキーマを示す。
【図９Ｇ】本発明の実施態様である、ランダムアクセスを行う場合の、値の集約処理のフローチャートを示す。
【図１０Ａ】実験１で使用した木構造を示す。
【図１０Ｂ】実験１で使用した９種類のクエリを示す。
【図１０Ｃ】実験１の結果を示すグラフである。
【図１０Ｄ】実験２で使用した木構造を示す。
【図１０Ｅ】実験２で使用した９種類のクエリを示す。
【図１０Ｆ】実験２の結果を示すグラフである。
【図１０Ｇ】インデックスの構築にかかる時間を示す。
【図１１】本発明の実施態様である、コンピュータの構成図を示す。
【特許請求の範囲】
【請求項１】
少なくとも１つのノードを含む少なくとも１つの木構造のデータに対する集約計算を行うために、インデックスを作成するコンピュータ・システムであって、前記ノードのそれぞれは該ノードの種類を示す１つのラベル及び０個以上の値を含み、
前記コンピュータ・システムが、
前記ノードそれぞれに後行順（post-order）でノードｉｄを割り振るノードｉｄ割振部と、
前記ノードそれぞれのノードｉｄと、該ノードに含まれる値とを含む１以上の組のデータを有するところの第１のインデックスを作成する第１のインデックス作成部であって、該１以上の組のデータは前記ラベル毎に作成される、前記第１のインデックス作成部と、
前記ノードそれぞれのノードｉｄと、該ノードの少なくとも１つの子孫ノードの間で最小のノードｉｄを有する子孫ノードのノードｉｄとを含む１以上の組のデータを有するところの第２のインデックスを作成する第２のインデックス作成部であって、該１以上の組のデータは前記ラベル毎に作成される、前記第２のインデックス作成部と、
特定の値を含む１以上のノードのノードｉｄを含む１以上の組のデータを有する第３のインデックスを作成する第３のインデックス作成部であって、該１以上の組のデータは前記ラベル毎の前記特定の値毎に作成される、前記第３のインデックス作成部と
を含む、前記コンピュータ・システム。
【請求項２】
前記第１のインデックスが、前記ノードそれぞれのノードｉｄと、該ノードに含まれる値とを含む組のデータをシーケンシャルに格納したファイルである、請求項１に記載のコンピュータ・システム。
【請求項３】
前記第２のインデックスが、前記ノードそれぞれのノードｉｄと、該ノードの少なくとも１つの子孫ノードの間で最小のノードｉｄを有する子孫ノードのノードｉｄとを含む組のデータをシーケンシャルに格納したファイルである、請求項１に記載のコンピュータ・システム。
【請求項４】
前記第３のインデックスが、前記特定の値を含む１以上のノードのノードｉｄを含む１以上の組のデータをシーケンシャルに格納したファイルである、請求項１に記載のコンピュータ・システム。
【請求項５】
前記ラベルのそれぞれにラベルｉｄを割り振るラベルｉｄ割振部をさらに含む、請求項１に記載のコンピュータ・システム。
【請求項６】
前記ノードそれぞれのノードｉｄと、該ノードｉｄそれぞれに関連付けられたポインタとを含む組のデータが格納されている第４のインデックス作成部をさらに含み、前記ポインタは前記第１のインデックスを成す前記１以上の組のデータにおけるノードｉｄのデータの位置を示す、請求項１に記載のコンピュータ・システム。
【請求項７】
少なくとも１つのノードを含む少なくとも１つの木構造のデータに対する集約計算を行うコンピュータ・システムであって、前記ノードのそれぞれは該ノードの種類を示す１つのラベル及び０個以上の値を含み、前記ノードのそれぞれは後行順（post-order）でノードｉｄを割り振られており、
前記コンピュータ・システムが、
集約計算を行うための検索式を受信する受信部と
前記検索式の検索対象である値を用い及び、特定の値を含む１以上のノードのノードｉｄを含む１以上の組のデータを有するインデックスを用いて、前記検索式の検索対象である前記値を有する１以上のノードのノードｉｄを含む第１のリストを取得する第１のリスト取得部であって、該１以上の組のデータは前記ラベル毎の前記特定の値毎に作成される、前記第１のリスト取得部と、
前記取得した第１のリストを用い及び、前記ノードそれぞれのノードｉｄと、該ノードの少なくとも１つの子孫ノードの間で最小のノードｉｄを有する子孫ノードのノードｉｄとを含む１以上の組のデータを有するところのインデックスを用いて、前記検索式の検索対象である前記値を有する１以上のノードを子孫に持つ各木構造のルート・ノードの１以上のルート・ノードｉｄを含む第２のリストを取得する第２のリスト取得部であって、該１以上の組のデータは前記ラベル毎に作成される、前記第２のリスト取得部と、
前記取得した第２のリストに基づいて、前記検索式の検索対象である前記値を検索する検索部であって、前記検索式の検索対象である前記値が少なくとも１つのキーワードに対応する、前記検索部と
を含む、前記コンピュータ・システム。
【請求項８】
前記取得した第２のリストを用いて及び、前記ノードそれぞれのノードｉｄと、該ノードに含まれる値とを含む１以上の組のデータを有するところのインデックスを用いて、前記検索式の検索条件を満たす、１以上のノードの１以上の値を含む第３のリストを取得する第３のリスト取得部であって、該１以上の組のデータは前記ラベル毎に作成される、前記第３のリスト取得部と、
前記取得した第３のリストに基づいて、前記検索式の結果を求める計算部と
をさらに含む、請求項７に記載のコンピュータ・システム。
【請求項９】
中央演算処理ユニット、メモリー及び木構造のデータを記憶する記憶部を有するコンピュータ・システムにおいて、少なくとも１つのノードを含む少なくとも１つの木構造のデータに対する集約計算を行うために、インデックスを作成する方法であって、前記ノードそれぞれは該ノードの種類を示す１つのラベル及び０個以上の値を含み、
前記方法が、前記中央演算処理ユニットに下記ステップを実行させることを含み、該方法が、
前記ノードの情報を前記メモリー内に読み込み、前記情報を読み込んだノードそれぞれに後行順（post-order）でノードｉｄを割り振るステップと、
前記ノードそれぞれのノードｉｄと、該ノードに含まれる値とを含む１以上の組のデータを有するところの第１のインデックスを作成し、該作成した第１のインデックスを前記記憶部に格納するステップであって、該１以上の組のデータは前記ラベル毎に作成される、前記第１のインデックスを格納するステップと、
前記ノードそれぞれのノードｉｄと、該ノードの少なくとも１つの子孫ノードの間で最小のノードｉｄを有する子孫ノードのノードｉｄとを含む１以上の組のデータを有するところの第２のインデックスを作成し、該作成した第２のインデックスを前記記憶部に格納するステップであって、該１以上の組のデータは前記ラベル毎に作成される、前記第２のインデックスを格納するステップと、
特定の値を含む１以上のノードのノードｉｄを含む１以上の組のデータを有する第３のインデックスを作成し、該作成した第３のインデックスを前記記憶部に格納するステップであって、該１以上の組のデータは前記ラベル毎の前記特定の値毎に作成される、前記第３のインデックスを格納するステップと
を含む、前記方法。
【請求項１０】
前記第１のインデックスを前記記憶部に格納するステップが、前記ノードそれぞれのノードｉｄと、該ノードに含まれる値とを含む組のデータをシーケンシャルに格納するステップをさらに含む、請求項９に記載の方法。
【請求項１１】
前記第２のインデックスを前記記憶部に格納するステップが、前記ノードそれぞれのノードｉｄと、該ノードの少なくとも１つの子孫ノードの間で最小のノードｉｄを有する子孫ノードのノードｉｄとを含む組のデータをシーケンシャルに格納するステップをさらに含む、請求項９に記載の方法。
【請求項１２】
前記第３のインデックスを前記記憶部に格納するステップが、前記特定の値を含む１以上のノードのノードｉｄを含む１以上の組のデータをシーケンシャルに格納するステップをさらに含む、請求項９に記載の方法。
【請求項１３】
前記方法が、前記中央演算処理ユニットに下記ステップをさらに実行させることを含み、該方法が、
前記ラベルのそれぞれにラベルｉｄを割り振るステップを含む、請求項９に記載の方法。
【請求項１４】
前記方法が、前記中央演算処理ユニットに下記ステップをさらに実行させることを含み、該方法が、
前記第１のインデックスにおける値又は前記第３のインデックスにおけるノードｉｄを圧縮するステップを含む、請求項９に記載の方法。
【請求項１５】
前記方法が、前記中央演算処理ユニットに下記ステップをさらに実行させることを含み、該方法が、
前記第１のインデックスを作成する前に、前記値が文字列である場合、該文字列を数値に置き換えるステップを含む、請求項９に記載の方法。
【請求項１６】
前記方法が、前記中央演算処理ユニットに下記ステップをさらに実行させることを含み、該方法が、
前記第３のインデックスを作成した後に、前記置き換えられた数値を、前記文字列にさらに置き換えるステップを含む、請求項１５に記載の方法。
【請求項１７】
前記方法が、前記中央演算処理ユニットに下記ステップをさらに実行させることを含み、該方法が、
前記ノードそれぞれのノードｉｄと、該ノードｉｄそれぞれに関連付けられたポインタとを含む組のデータが格納されている第４のインデックスを作成するステップを含み、前記ポインタは前記第１のインデックスを成す前記１以上の組のデータにおけるノードｉｄのデータの位置を示す、請求項９に記載の方法。
【請求項１８】
中央演算処理ユニット、メモリー及び木構造のデータを記憶する記憶部を有するコンピュータ・システムにおいて、少なくとも１つのノードを含む少なくとも１つの木構造のデータに対する集約計算を行う方法であって、前記ノードそれぞれは該ノードの種類を示す１つのラベル及び０個以上の値を含み、前記ノードそれぞれは後行順（post-order）でノードｉｄを割り振られており、
前記方法が中央演算処理ユニットに下記ステップを実行させるステップを含み、
該方法が、
集約計算を行うための検索式を受信し、該受信した検索式を前記メモリー内に記憶するステップと、
前記検索式の検索対象である値を用い及び、特定の値を含む１以上のノードのノードｉｄを含む１以上の組のデータを有するインデックスを用いて、前記検索式の検索対象である前記値を有する１以上のノードのノードｉｄを含む第１のリストを取得し、該取得した第１のリストを前記記憶部に記憶するステップであって、該１以上の組のデータは前記ラベル毎の前記特定の値毎に作成される、前記第１のリストを記憶するステップと、
前記取得した第１のリストを用い及び、前記ノードそれぞれのノードｉｄと、該ノードの少なくとも１つの子孫ノードの間で最小のノードｉｄを有する子孫ノードのノードｉｄとを含む１以上の組のデータを有するところのインデックスを用いて、前記検索式の検索対象である前記値を有する１以上のノードを子孫に持つ各木構造のルート・ノードの１以上のルート・ノードｉｄを含む第２のリストを取得し、該取得した第２のリストを前記記憶部に記憶するステップであって、該１以上の組のデータは前記ラベル毎に作成される、前記第２のリストを記憶するステップと、
前記取得した第２のリストに基づいて、前記検索式の検索対象である前記値を検索するステップであって、前記検索式の検索対象である前記値が少なくとも１つのキーワードに対応する、前記検索するステップと
を含む、前記方法。
【請求項１９】
前記方法が、前記中央演算処理ユニットに下記ステップをさらに実行させることを含み、該方法が、
前記取得した第２のリストを用い及び、前記ノードそれぞれのノードｉｄと、該ノードに含まれる値とを含む１以上の組のデータを有するところのインデックスを用いて、前記検索式の検索条件を満たす、１以上のノードの１以上の値を含む第３のリストを取得し、該取得した第３のリストを前記記憶部に記憶するステップであって、該１以上の組のデータは前記ラベル毎に作成される、前記第３のリストを記憶するステップと、
前記取得した第３のリストに基づいて、前記検索式の結果を求めるステップと
をさらに含む、請求項１８に記載の方法。
【請求項２０】
前記第３のリストが、前記ノードそれぞれのノードｉｄと、該ノードに含まれる値とを含む１以上の組のデータを有するところのインデックスを用いてシーケンシャルアクセスにより取得される、請求項１９に記載の方法。
【請求項２１】
前記第３のリストが、前記ノードそれぞれのノードｉｄと、該ノードに含まれる値とを含む１以上の組のデータを有するところのインデックス、及び前記ノードそれぞれのノードｉｄと、該ノードｉｄそれぞれに関連付けられたポインタとを含む組のデータが格納されているインデックスを用いてランダムアクセスにより取得される、請求項１９に記載の方法。
【請求項２２】
前記第３のリストの一部が、前記ノードそれぞれのノードｉｄと、該ノードに含まれる値とを含む１以上の組のデータを有するところのインデックスを用いてシーケンシャルアクセスにより取得され、及び
前記第３のリストの残りが、前記ノードそれぞれのノードｉｄと、該ノードに含まれる値とを含む１以上の組のデータを有するところのインデックス、及び前記ノードそれぞれのノードｉｄと、該ノードｉｄそれぞれに関連付けられたポインタとを含む組のデータが格納されているインデックスを用いてランダムアクセスにより取得され、
前記第３のリストが、前記シーケンシャルアクセスと前記ランダムアクセスとを切り替えることによって取得される、請求項１９に記載の方法。
【請求項２３】
中央演算処理ユニット、メモリー及び木構造のデータを記憶する記憶部を有するコンピュータ・システムにおいて、少なくとも１つのノードを含む少なくとも１つの木構造のデータに対する集約計算を行う方法であって、前記ノードそれぞれは該ノードの種類を示す１つのラベル及び０個以上の値を含み、
前記方法が、前記中央演算処理ユニットに下記ステップを実行させることを含み、該方法が、
前記ノードの情報を前記メモリー内に読み込み、前記情報を読み込んだノードそれぞれに後行順（post-order）でノードｉｄを割り振るステップと、
前記ノードそれぞれのノードｉｄと、該ノードに含まれる値とを含む１以上の組のデータを有するところの第１のインデックスを作成し、該作成した第１のインデックスを前記記憶部に格納するステップであって、該１以上の組のデータは前記ラベル毎に作成される、前記第１のインデックスを格納するステップと、
前記ノードそれぞれのノードｉｄと、該ノードの少なくとも１つの子孫ノードの間で最小のノードｉｄを有する子孫ノードのノードｉｄとを含む１以上の組のデータを有するところの第２のインデックスを作成し、該作成した第２のインデックスを前記記憶部に格納するステップであって、該１以上の組のデータは前記ラベル毎に作成される、前記第２のインデックスを格納するステップと、
特定の値を含む１以上のノードのノードｉｄを含む１以上の組のデータを有する第３のインデックスを作成し、該作成した第３のインデックスを前記記憶部に格納するステップであって、該１以上の組のデータは前記ラベル毎の前記特定の値毎に作成される、前記第３のインデックスを格納するステップと、
前記メモリー内に記憶した集約計算を行うための検索式の検索対象である値及び前記第３のインデックスを用いて、前記検索式の検索対象である前記値を有する１以上のノードのノードｉｄを含む第１のリストを取得し、該取得した第１のリストを前記記憶部に記憶するステップと、
前記取得した第１のリスト及び前記第２のインデックスを用いて、前記検索式の検索対象である前記値を有する１以上のノードを子孫に持つ各木構造のルート・ノードの１以上のルート・ノードｉｄを含む第２のリストを取得し、該取得した第２のリストを前記記憶部に記憶するステップと、
前記取得した第２のリスト及び前記第１のインデックスを用いて、前記検索式の検索条件を満たす、１以上のノードの１以上の値を含む第３のリストを取得し、該取得した第３のリストを前記記憶部に記憶するステップと、
前記取得した第３のリストに基づいて、前記検索式の結果を求めるステップと
を含む、前記方法。
【請求項１】
少なくとも１つのノードを含む少なくとも１つの木構造のデータに対する集約計算を行うために、インデックスを作成するコンピュータ・システムであって、前記ノードのそれぞれは該ノードの種類を示す１つのラベル及び０個以上の値を含み、
前記コンピュータ・システムが、
前記ノードそれぞれに後行順（post-order）でノードｉｄを割り振るノードｉｄ割振部と、
前記ノードそれぞれのノードｉｄと、該ノードに含まれる値とを含む１以上の組のデータを有するところの第１のインデックスを作成する第１のインデックス作成部であって、該１以上の組のデータは前記ラベル毎に作成される、前記第１のインデックス作成部と、
前記ノードそれぞれのノードｉｄと、該ノードの少なくとも１つの子孫ノードの間で最小のノードｉｄを有する子孫ノードのノードｉｄとを含む１以上の組のデータを有するところの第２のインデックスを作成する第２のインデックス作成部であって、該１以上の組のデータは前記ラベル毎に作成される、前記第２のインデックス作成部と、
特定の値を含む１以上のノードのノードｉｄを含む１以上の組のデータを有する第３のインデックスを作成する第３のインデックス作成部であって、該１以上の組のデータは前記ラベル毎の前記特定の値毎に作成される、前記第３のインデックス作成部と
を含む、前記コンピュータ・システム。
【請求項２】
前記第１のインデックスが、前記ノードそれぞれのノードｉｄと、該ノードに含まれる値とを含む組のデータをシーケンシャルに格納したファイルである、請求項１に記載のコンピュータ・システム。
【請求項３】
前記第２のインデックスが、前記ノードそれぞれのノードｉｄと、該ノードの少なくとも１つの子孫ノードの間で最小のノードｉｄを有する子孫ノードのノードｉｄとを含む組のデータをシーケンシャルに格納したファイルである、請求項１に記載のコンピュータ・システム。
【請求項４】
前記第３のインデックスが、前記特定の値を含む１以上のノードのノードｉｄを含む１以上の組のデータをシーケンシャルに格納したファイルである、請求項１に記載のコンピュータ・システム。
【請求項５】
前記ラベルのそれぞれにラベルｉｄを割り振るラベルｉｄ割振部をさらに含む、請求項１に記載のコンピュータ・システム。
【請求項６】
前記ノードそれぞれのノードｉｄと、該ノードｉｄそれぞれに関連付けられたポインタとを含む組のデータが格納されている第４のインデックス作成部をさらに含み、前記ポインタは前記第１のインデックスを成す前記１以上の組のデータにおけるノードｉｄのデータの位置を示す、請求項１に記載のコンピュータ・システム。
【請求項７】
少なくとも１つのノードを含む少なくとも１つの木構造のデータに対する集約計算を行うコンピュータ・システムであって、前記ノードのそれぞれは該ノードの種類を示す１つのラベル及び０個以上の値を含み、前記ノードのそれぞれは後行順（post-order）でノードｉｄを割り振られており、
前記コンピュータ・システムが、
集約計算を行うための検索式を受信する受信部と
前記検索式の検索対象である値を用い及び、特定の値を含む１以上のノードのノードｉｄを含む１以上の組のデータを有するインデックスを用いて、前記検索式の検索対象である前記値を有する１以上のノードのノードｉｄを含む第１のリストを取得する第１のリスト取得部であって、該１以上の組のデータは前記ラベル毎の前記特定の値毎に作成される、前記第１のリスト取得部と、
前記取得した第１のリストを用い及び、前記ノードそれぞれのノードｉｄと、該ノードの少なくとも１つの子孫ノードの間で最小のノードｉｄを有する子孫ノードのノードｉｄとを含む１以上の組のデータを有するところのインデックスを用いて、前記検索式の検索対象である前記値を有する１以上のノードを子孫に持つ各木構造のルート・ノードの１以上のルート・ノードｉｄを含む第２のリストを取得する第２のリスト取得部であって、該１以上の組のデータは前記ラベル毎に作成される、前記第２のリスト取得部と、
前記取得した第２のリストに基づいて、前記検索式の検索対象である前記値を検索する検索部であって、前記検索式の検索対象である前記値が少なくとも１つのキーワードに対応する、前記検索部と
を含む、前記コンピュータ・システム。
【請求項８】
前記取得した第２のリストを用いて及び、前記ノードそれぞれのノードｉｄと、該ノードに含まれる値とを含む１以上の組のデータを有するところのインデックスを用いて、前記検索式の検索条件を満たす、１以上のノードの１以上の値を含む第３のリストを取得する第３のリスト取得部であって、該１以上の組のデータは前記ラベル毎に作成される、前記第３のリスト取得部と、
前記取得した第３のリストに基づいて、前記検索式の結果を求める計算部と
をさらに含む、請求項７に記載のコンピュータ・システム。
【請求項９】
中央演算処理ユニット、メモリー及び木構造のデータを記憶する記憶部を有するコンピュータ・システムにおいて、少なくとも１つのノードを含む少なくとも１つの木構造のデータに対する集約計算を行うために、インデックスを作成する方法であって、前記ノードそれぞれは該ノードの種類を示す１つのラベル及び０個以上の値を含み、
前記方法が、前記中央演算処理ユニットに下記ステップを実行させることを含み、該方法が、
前記ノードの情報を前記メモリー内に読み込み、前記情報を読み込んだノードそれぞれに後行順（post-order）でノードｉｄを割り振るステップと、
前記ノードそれぞれのノードｉｄと、該ノードに含まれる値とを含む１以上の組のデータを有するところの第１のインデックスを作成し、該作成した第１のインデックスを前記記憶部に格納するステップであって、該１以上の組のデータは前記ラベル毎に作成される、前記第１のインデックスを格納するステップと、
前記ノードそれぞれのノードｉｄと、該ノードの少なくとも１つの子孫ノードの間で最小のノードｉｄを有する子孫ノードのノードｉｄとを含む１以上の組のデータを有するところの第２のインデックスを作成し、該作成した第２のインデックスを前記記憶部に格納するステップであって、該１以上の組のデータは前記ラベル毎に作成される、前記第２のインデックスを格納するステップと、
特定の値を含む１以上のノードのノードｉｄを含む１以上の組のデータを有する第３のインデックスを作成し、該作成した第３のインデックスを前記記憶部に格納するステップであって、該１以上の組のデータは前記ラベル毎の前記特定の値毎に作成される、前記第３のインデックスを格納するステップと
を含む、前記方法。
【請求項１０】
前記第１のインデックスを前記記憶部に格納するステップが、前記ノードそれぞれのノードｉｄと、該ノードに含まれる値とを含む組のデータをシーケンシャルに格納するステップをさらに含む、請求項９に記載の方法。
【請求項１１】
前記第２のインデックスを前記記憶部に格納するステップが、前記ノードそれぞれのノードｉｄと、該ノードの少なくとも１つの子孫ノードの間で最小のノードｉｄを有する子孫ノードのノードｉｄとを含む組のデータをシーケンシャルに格納するステップをさらに含む、請求項９に記載の方法。
【請求項１２】
前記第３のインデックスを前記記憶部に格納するステップが、前記特定の値を含む１以上のノードのノードｉｄを含む１以上の組のデータをシーケンシャルに格納するステップをさらに含む、請求項９に記載の方法。
【請求項１３】
前記方法が、前記中央演算処理ユニットに下記ステップをさらに実行させることを含み、該方法が、
前記ラベルのそれぞれにラベルｉｄを割り振るステップを含む、請求項９に記載の方法。
【請求項１４】
前記方法が、前記中央演算処理ユニットに下記ステップをさらに実行させることを含み、該方法が、
前記第１のインデックスにおける値又は前記第３のインデックスにおけるノードｉｄを圧縮するステップを含む、請求項９に記載の方法。
【請求項１５】
前記方法が、前記中央演算処理ユニットに下記ステップをさらに実行させることを含み、該方法が、
前記第１のインデックスを作成する前に、前記値が文字列である場合、該文字列を数値に置き換えるステップを含む、請求項９に記載の方法。
【請求項１６】
前記方法が、前記中央演算処理ユニットに下記ステップをさらに実行させることを含み、該方法が、
前記第３のインデックスを作成した後に、前記置き換えられた数値を、前記文字列にさらに置き換えるステップを含む、請求項１５に記載の方法。
【請求項１７】
前記方法が、前記中央演算処理ユニットに下記ステップをさらに実行させることを含み、該方法が、
前記ノードそれぞれのノードｉｄと、該ノードｉｄそれぞれに関連付けられたポインタとを含む組のデータが格納されている第４のインデックスを作成するステップを含み、前記ポインタは前記第１のインデックスを成す前記１以上の組のデータにおけるノードｉｄのデータの位置を示す、請求項９に記載の方法。
【請求項１８】
中央演算処理ユニット、メモリー及び木構造のデータを記憶する記憶部を有するコンピュータ・システムにおいて、少なくとも１つのノードを含む少なくとも１つの木構造のデータに対する集約計算を行う方法であって、前記ノードそれぞれは該ノードの種類を示す１つのラベル及び０個以上の値を含み、前記ノードそれぞれは後行順（post-order）でノードｉｄを割り振られており、
前記方法が中央演算処理ユニットに下記ステップを実行させるステップを含み、
該方法が、
集約計算を行うための検索式を受信し、該受信した検索式を前記メモリー内に記憶するステップと、
前記検索式の検索対象である値を用い及び、特定の値を含む１以上のノードのノードｉｄを含む１以上の組のデータを有するインデックスを用いて、前記検索式の検索対象である前記値を有する１以上のノードのノードｉｄを含む第１のリストを取得し、該取得した第１のリストを前記記憶部に記憶するステップであって、該１以上の組のデータは前記ラベル毎の前記特定の値毎に作成される、前記第１のリストを記憶するステップと、
前記取得した第１のリストを用い及び、前記ノードそれぞれのノードｉｄと、該ノードの少なくとも１つの子孫ノードの間で最小のノードｉｄを有する子孫ノードのノードｉｄとを含む１以上の組のデータを有するところのインデックスを用いて、前記検索式の検索対象である前記値を有する１以上のノードを子孫に持つ各木構造のルート・ノードの１以上のルート・ノードｉｄを含む第２のリストを取得し、該取得した第２のリストを前記記憶部に記憶するステップであって、該１以上の組のデータは前記ラベル毎に作成される、前記第２のリストを記憶するステップと、
前記取得した第２のリストに基づいて、前記検索式の検索対象である前記値を検索するステップであって、前記検索式の検索対象である前記値が少なくとも１つのキーワードに対応する、前記検索するステップと
を含む、前記方法。
【請求項１９】
前記方法が、前記中央演算処理ユニットに下記ステップをさらに実行させることを含み、該方法が、
前記取得した第２のリストを用い及び、前記ノードそれぞれのノードｉｄと、該ノードに含まれる値とを含む１以上の組のデータを有するところのインデックスを用いて、前記検索式の検索条件を満たす、１以上のノードの１以上の値を含む第３のリストを取得し、該取得した第３のリストを前記記憶部に記憶するステップであって、該１以上の組のデータは前記ラベル毎に作成される、前記第３のリストを記憶するステップと、
前記取得した第３のリストに基づいて、前記検索式の結果を求めるステップと
をさらに含む、請求項１８に記載の方法。
【請求項２０】
前記第３のリストが、前記ノードそれぞれのノードｉｄと、該ノードに含まれる値とを含む１以上の組のデータを有するところのインデックスを用いてシーケンシャルアクセスにより取得される、請求項１９に記載の方法。
【請求項２１】
前記第３のリストが、前記ノードそれぞれのノードｉｄと、該ノードに含まれる値とを含む１以上の組のデータを有するところのインデックス、及び前記ノードそれぞれのノードｉｄと、該ノードｉｄそれぞれに関連付けられたポインタとを含む組のデータが格納されているインデックスを用いてランダムアクセスにより取得される、請求項１９に記載の方法。
【請求項２２】
前記第３のリストの一部が、前記ノードそれぞれのノードｉｄと、該ノードに含まれる値とを含む１以上の組のデータを有するところのインデックスを用いてシーケンシャルアクセスにより取得され、及び
前記第３のリストの残りが、前記ノードそれぞれのノードｉｄと、該ノードに含まれる値とを含む１以上の組のデータを有するところのインデックス、及び前記ノードそれぞれのノードｉｄと、該ノードｉｄそれぞれに関連付けられたポインタとを含む組のデータが格納されているインデックスを用いてランダムアクセスにより取得され、
前記第３のリストが、前記シーケンシャルアクセスと前記ランダムアクセスとを切り替えることによって取得される、請求項１９に記載の方法。
【請求項２３】
中央演算処理ユニット、メモリー及び木構造のデータを記憶する記憶部を有するコンピュータ・システムにおいて、少なくとも１つのノードを含む少なくとも１つの木構造のデータに対する集約計算を行う方法であって、前記ノードそれぞれは該ノードの種類を示す１つのラベル及び０個以上の値を含み、
前記方法が、前記中央演算処理ユニットに下記ステップを実行させることを含み、該方法が、
前記ノードの情報を前記メモリー内に読み込み、前記情報を読み込んだノードそれぞれに後行順（post-order）でノードｉｄを割り振るステップと、
前記ノードそれぞれのノードｉｄと、該ノードに含まれる値とを含む１以上の組のデータを有するところの第１のインデックスを作成し、該作成した第１のインデックスを前記記憶部に格納するステップであって、該１以上の組のデータは前記ラベル毎に作成される、前記第１のインデックスを格納するステップと、
前記ノードそれぞれのノードｉｄと、該ノードの少なくとも１つの子孫ノードの間で最小のノードｉｄを有する子孫ノードのノードｉｄとを含む１以上の組のデータを有するところの第２のインデックスを作成し、該作成した第２のインデックスを前記記憶部に格納するステップであって、該１以上の組のデータは前記ラベル毎に作成される、前記第２のインデックスを格納するステップと、
特定の値を含む１以上のノードのノードｉｄを含む１以上の組のデータを有する第３のインデックスを作成し、該作成した第３のインデックスを前記記憶部に格納するステップであって、該１以上の組のデータは前記ラベル毎の前記特定の値毎に作成される、前記第３のインデックスを格納するステップと、
前記メモリー内に記憶した集約計算を行うための検索式の検索対象である値及び前記第３のインデックスを用いて、前記検索式の検索対象である前記値を有する１以上のノードのノードｉｄを含む第１のリストを取得し、該取得した第１のリストを前記記憶部に記憶するステップと、
前記取得した第１のリスト及び前記第２のインデックスを用いて、前記検索式の検索対象である前記値を有する１以上のノードを子孫に持つ各木構造のルート・ノードの１以上のルート・ノードｉｄを含む第２のリストを取得し、該取得した第２のリストを前記記憶部に記憶するステップと、
前記取得した第２のリスト及び前記第１のインデックスを用いて、前記検索式の検索条件を満たす、１以上のノードの１以上の値を含む第３のリストを取得し、該取得した第３のリストを前記記憶部に記憶するステップと、
前記取得した第３のリストに基づいて、前記検索式の結果を求めるステップと
を含む、前記方法。
【図１Ａ】
【図１Ｂ】
【図２】
【図３】
【図４】
【図５Ａ】
【図５Ｂ】
【図５Ｃ】
【図６Ａ】
【図６Ｂ】
【図７Ａ】
【図７Ｂ】
【図８Ａ】
【図８Ｂ】
【図８Ｃ】
【図８Ｄ】
【図８Ｅ】
【図８Ｆ】
【図９Ａ】
【図９Ｂ】
【図９Ｃ】
【図９Ｄ】
【図９Ｅ】
【図９Ｆ】
【図９Ｇ】
【図１０Ａ】
【図１０Ｂ】
【図１０Ｃ】
【図１０Ｄ】
【図１０Ｅ】
【図１０Ｆ】
【図１０Ｇ】
【図１１】
【図１Ｂ】
【図２】
【図３】
【図４】
【図５Ａ】
【図５Ｂ】
【図５Ｃ】
【図６Ａ】
【図６Ｂ】
【図７Ａ】
【図７Ｂ】
【図８Ａ】
【図８Ｂ】
【図８Ｃ】
【図８Ｄ】
【図８Ｅ】
【図８Ｆ】
【図９Ａ】
【図９Ｂ】
【図９Ｃ】
【図９Ｄ】
【図９Ｅ】
【図９Ｆ】
【図９Ｇ】
【図１０Ａ】
【図１０Ｂ】
【図１０Ｃ】
【図１０Ｄ】
【図１０Ｅ】
【図１０Ｆ】
【図１０Ｇ】
【図１１】
【公開番号】特開２００９−２９４９６７（Ｐ２００９−２９４９６７Ａ）
【公開日】平成２１年１２月１７日（２００９．１２．１７）
【国際特許分類】
【出願番号】特願２００８−１４８７９８（Ｐ２００８−１４８７９８）
【出願日】平成２０年６月６日（２００８．６．６）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．Ｌｉｎｕｘ
【出願人】（３９０００９５３１）インターナショナル・ビジネス・マシーンズ・コーポレーション (4,084)
【氏名又は名称原語表記】ＩＮＴＥＲＮＡＴＩＯＮＡＬ ＢＵＳＩＮＥＳＳ ＭＡＳＣＨＩＮＥＳ ＣＯＲＰＯＲＡＴＩＯＮ
【復代理人】
【識別番号】１０００８５５４５
【弁理士】
【氏名又は名称】松井 光夫
【復代理人】
【識別番号】１００１１８５９９
【弁理士】
【氏名又は名称】村上 博司
【Ｆターム（参考）】
【公開日】平成２１年１２月１７日（２００９．１２．１７）
【国際特許分類】
【出願日】平成２０年６月６日（２００８．６．６）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．Ｌｉｎｕｘ
【出願人】（３９０００９５３１）インターナショナル・ビジネス・マシーンズ・コーポレーション (4,084)
【氏名又は名称原語表記】ＩＮＴＥＲＮＡＴＩＯＮＡＬ ＢＵＳＩＮＥＳＳ ＭＡＳＣＨＩＮＥＳ ＣＯＲＰＯＲＡＴＩＯＮ
【復代理人】
【識別番号】１０００８５５４５
【弁理士】
【氏名又は名称】松井 光夫
【復代理人】
【識別番号】１００１１８５９９
【弁理士】
【氏名又は名称】村上 博司
【Ｆターム（参考）】
[ Back to top ]