JP4796108B2 - 構造化文書検索装置、方法及びプログラム - Google Patents

Description

本発明は、複数の要素が階層化されて含まれる構造化文書データを記憶し検索条件に応じて該当の構造化文書データを検索する構造化文書検索装置、方法及びプログラムに関する。

ＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）などで記述された構
造化文書データを記憶・検索するための構造化文書管理システムとしては、いくつかの方
式が考えられている。第１の方式としては、構造化文書データをそのままテキストファイルとして管理する方式がある。この第１の方式では、データ数やサイズが大きくなると格納効率が悪くなるという問題がある。また、この第１の方式では、構造化文書の特性を生かした検索が困難になるという問題がある。第２の方式としては、ＲＤＢ（Ｒｅｌａｔｉｏｎａｌ Ｄａｔａｂａｓｅ）に構造化文書データを管理する方式がある。この第２の方式は、基幹系などで広く使われている。第３の方式としては、構造化文書データを管理するために開発されたＯＯＤＢ（Ｏｂｊｅ ｃｔ Ｏｒｉｅｎｔｅｄ Ｄａｔａｂａｓｅ）で管理する方式がある。この第３の方式は、ＲＤＢを拡張した、例えばＸＭＬ対応ＲＤＢである。ＲＤＢは、データをフラットなテーブル形式に格納するため、ＸＭＬデータのような階層構造をテーブルに対応付ける複雑なマッピングが必要となる。このマッピングのため、テーブルに関する事前の構造（スキーマ）設計を十分に行わないと、パフォーマンスが低下してしまう問題が発生する。そこで、近年においては、上述した第１〜第３の方式に代わる第４の方式が提案されている。第４の方式は、ネイティブに構造化文書データを管理する方式である。この第４の方式は、多種多様な階層構造を持つＸＭＬデータを特別なマッピング処理すること無しに格納するため、格納や取得時に特別なオーバヘッドが存在しない。また、コストのかかる事前のスキーマ設計が不要になり、ビジネス環境の変化により必要に応じてＸＭＬデータの構造を自由に変更することが可能である。

ところで、構造化文書データが効率良く格納されたからといって、格納されたデータを取り出す手段が無ければ意味が無い。この格納されたデータを取り出す手段として、問合せ言語がある。ＲＤＢの世界ではＳＱＬ（Ｓｔｒｕｃｔｕｒｅｄ Ｑｕｅｒｙ Ｌａｎｇｕ ａｇｅ）があるように、ＸＭＬではＸＱｕｅｒｙ（ＸＭＬ Ｑｕｅｒｙ Ｌａｎｇｕａｇｅ）が策定されている。このＸＱｕｅｒｙは、ＸＭＬデータをデータベースのように扱うための言語であり、条件に合致するデータ集合の取り出しや集計・分析を行うための手段が提供されている。また、ＸＭＬデータは親子や兄弟などの要素が組み合わさった階層構造を持つため、この階層構造を辿る手段が提供されている。このように格納された構造化文書データの階層構造を辿りながら、検索条件で指定された特定の要素と特定の構造とが含まれている構造化文書データを検索するための技術は、例えば特許文献１や特許文献２において開示されている。

ところが、前述したように、ＸＭＬデータは親子や兄弟などの要素が組み合わさった階層構造を持つため、データベースの格納効率が悪いという問題がある。さらに、構造化文書データの構造が大規模になる程、データベースに格納されている構造化文書データの数が多い程、あるいは、検索条件が複雑な程、各構造化文書データの階層構造を構成する要素間を辿るという処理には時間がかかる。また、構造化文書データの数、あるいはサイズが大きくなれば、格納された構造化文書データをメモリ上に展開することは不可能であり、多くはハードディスクなど二次記憶に格納されることになる。特に、ネイティブに構造化文書データを管理する方式では、構造化文書データは要素間の階層構造をそのまま記憶することから、検索条件として指定された要素や構造があるか否かを調べるためには、二次記憶上に格納された構造化文書データの要素間を頻繁にアクセスしなければならない。複雑な検索条件の場合はなおさらである。すなわち、特許文献１や特許文献２において開示されているような階層構造を辿る手段によれば、データベース内の各構造化文書データの階層構造を構成する要素データ間を辿りながら、検索条件にて指定された要素や構造を持つ構造化文書データを検索するため、高速に検索できないという問題点がある。特に、構造化文書データのサイズが大きくなる程、検索対象の構造化文書データの数が多い程、あるいは、クエリデータ（検索条件）が複雑である程、検索処理の高速化が困難である。より具体的には、下記の通りである。
（１）複雑なＸＱｕｅｒｙの場合、複数のパスパターンがクエリに含まれる。複数のパスパターンへの照合を行うのに、同一構造化文書データへのトラバースが繰り返し発生する。特にオンメモリにできないサイズを取り扱うケースでは、同一ページへのディスクＩ／Ｏが断続発生し、性能劣化が激しくなる。
（２）ＸＱｕｅｒｙのサブセットであるＸＰａｔｈの場合でも、高ヒット時には性能劣化が発生する。つまり、構造化文書の集合の大半をトラバースするケースでは、大量のディスクＩ／Ｏが発生してしまう。

また、同一の構造化文書データへのデータスキャンを抑えるアイデアとして、構造化文書ストリーム処理の技術がある。例えば、非特許文献１〜２に記載された技術が挙げられる。これらの技術は構造化文書データ全部を主記憶に記憶しないでＸＰａｔｈなどの問合わせを処理するものである。複数のＸＰａｔｈに現れる複数のパスパターンを状態遷移に変換して処理する方式も提案されている。しかし、現実には以下のような問題が発生してしまう。
（３）高ヒットでないＸＰａｔｈでは性能劣化が著しい。バックトラックベースであるため、ＣＰＵ処理上のオーバヘッドも大きい。処理の特性上、索引を使った問合わせ処理が難しい。

上述したように、構造化文書データを格納したデータベースに対して、複数のパスパターンを最小のディスクＩ／Ｏと少ない計算量とで処理するのは困難であると言える。このような上記の課題に鑑みてなされた技術が特許文献３に開示されている。特許文献３の技術では、構造化文書データを構文解析し、構造ガイドデータを用いて構造化文書データ中にある構造情報を１次元の配列データである構造ストリームデータに変換して記憶する。これにより、構造化文書データの原文比でも１／２０程度に圧縮することができ、ディスクＩ／Ｏを大幅に低減することができる。このため、データベースの格納効率を向上させることができるという効果を奏する。また、特許文献３の技術によれば、バックトラックでなく決定的な基本動作の繰返しであり、ＣＰＵ処理上のオーバヘッドが小さい。このことから、結果として、高速化が困難であった複雑なＸＱｕｅｒｙや複数のＸＰａｔｈなどのクエリデータによる検索処理を飛躍的に高速化することができるという効果を奏する。特許文献３の技術は、要素順序を保持しながら構造データやテキストデータをストリームという概念で永続化したものである。単なる構造データの並びは圧縮符号化しやすいので、高速化や軽量化などの効果が見込まれる。

特開２００１−０３４６１８号公報 特開２０００−０５７１６３号公報 特開２００７−２２６４５２号公報 Ｙ． Ｄｉａｏ、 Ｐ．Ｆｉｓｃｈｅｒ、 ａｎｄ Ｍ．Ｊ．Ｆｒａｎｋ ｌｉｎ． ＹＦｉｌｔｅｒ： Ｅｆｆｉｃｉｅｎｔ ａｎｄ Ｓｃａｌａｂｌｅ Ｆｉｌ ｔｅｒｉｎｇ ｏｆ ＸＭＬ Ｄｏｃｕｍｅｎｔｓ． Ｉｎ Ｔｈｅ １８ｔｈ Ｉｎｔ ｅｒｎａｔｉｏｎａｌ Ｃｏｎｆｅｒｅｎｃｅ ｏｆ Ｄａｔａ Ｅｎｇｉｎｅｅｒｉｎｇ、 Ｓａｎ Ｊｏｓｅ、 Ｆｅｂｒｕａｒｙ ２００２． Ｉ． Ａｖｉｌａ−Ｃａｍｐｉｌｌｏ、 Ｄ． Ｒａｖｅｎ、 Ｔ． Ｇ ｒｅｅｎ、 Ａ． Ｇｕｐｔａ、 Ｙ． Ｋａｄｉｙｓｋａ、 Ｍ．Ｏｎｉｚｕｋａ、 ａ ｎｄ Ｄ． Ｓｕｃｉｕ． Ａｎ ＸＭＬ Ｔｏｏｌｋｉｔ ｆｏｒ Ｌｉｇｈｔ−ｗｅ ｉｇｈｔ ＸＭＬ Ｓｔｒｅａｍ Ｐｒｏｃｅｓｓｉｎｇ、２００２．

ところで、ＸＱｕｅｒｙを高速に処理するためには、テキスト条件や構造条件を使って、テキスト索引とＸＭＬデータとの走査範囲をできるだけ絞り込む必要がある。しかし、特許文献３の技術のように、直列的なリレーでは、構造条件を使ってテキスト索引の走査範囲を絞り込むことが困難であり、テキスト条件に関連する全てのテキスト索引を走査しなければならない。結果として、ディスクＩ／Ｏコストが増大するという恐れがあった。また、テキスト索引での大量ヒット時には、大きなサイズの中間データを保持する必要があり、メモリコストが増大する可能性があった。

本発明は、上記に鑑みてなされたものであって、ディスクＩ／Ｏコストやメモリコストの増大を抑制しつつ、検索条件に応じた検索を高速に行うことが可能な構造化文書検索装置、方法及びプログラムを提供することを目的とする。

上述した課題を解決し、目的を達成するために、本発明は、複数の要素が階層化されて各々含まれる複数の構造化文書データを記憶する構造化文書検索装置であって、前記複数の構造化文書データに各々含まれる各要素が構文解析の結果順に配列されたデータストリームを第１記憶領域に格納する第１格納手段と、前記複数の構造化文書データに各々含まれ且つ当該構造化文書データを検索する際の索引となる前記要素を構文解析の結果順に並べた少なくとも１つの索引ストリームを第２記憶領域に格納する第２格納手段と、前記構造化文書データを検索するための検索条件に基づいて、前記データストリーム及び前記索引ストリームに対する走査を命じる走査プランを生成する生成手段と、前記走査プランによって命じられた前記データストリーム及び前記索引ストリームのうち少なくとも一方に対する走査を実行する実行手段とを備え、前記生成手段は、前記検索条件に基づいて、文書単位で、前記データストリーム及び前記索引ストリームを含む複数のストリームのうち第１のストリームに対する走査を命じ、当該走査の結果に応じて第２のストリームに対する走査を命じる走査プランを生成し、前記第１格納手段は、固定長のデータブロック毎に配列された前記データストリームについて、前記構造化文書データ毎に先頭の前記データブロックの先頭に同期記号を埋め込んで、当該データストリームを前記第１記憶領域に格納し、前記実行手段は、前記同期記号が出現してから次の前記同期記号が出現するまでのデータブロックを前記文書単位として前記データストリームに対する走査を実行するものであり、前記走査プランによって命じられた前記第１のストリームに対する走査を文書単位で実行し、前記走査の結果に応じて、前記データストリームである前記第２のストリームについて前記同期記号が出現してから次の前記同期記号が出現するまでのデータブロックに対する走査をスキップすることを特徴とする。

また、本発明は、第１格納手段と、第２格納手段と、生成手段と、実行手段とを備え、複数の要素が階層化されて各々含まれる複数の構造化文書データを記憶する構造化文書検索装置で実行される構造化文書検索方法であって、前記第１格納手段が、前記複数の構造化文書データに各々含まれる各要素が構文解析の結果順に配列されたデータストリームを第１記憶領域に格納する第１格納ステップと、前記第２格納手段が、前記複数の構造化文書データに各々含まれ且つ当該構造化文書データを検索する際の索引となる前記要素を構文解析の結果順に並べた少なくとも１つの索引ストリームを第２記憶領域に格納する第２格納ステップと、前記生成手段が、前記構造化文書データを検索するための検索条件に基づいて、前記データストリーム及び前記索引ストリームに対する走査を命じる走査プランを生成する生成ステップと、前記実行手段が、前記走査プランによって命じられた前記データストリーム及び前記索引ストリームのうち少なくとも一方に対する走査を実行する実行ステップとを含み、前記生成ステップは、前記検索条件に基づいて、文書単位で、前記データストリーム及び前記索引ストリームを含む複数のストリームのうち第１のストリームに対する走査を命じ、当該走査の結果に応じて第２のストリームに対する走査を命じる走査プランを生成し、前記第１格納ステップは、固定長のデータブロック毎に配列された前記データストリームについて、前記構造化文書データ毎に先頭の前記データブロックの先頭に同期記号を埋め込んで、当該データストリームを前記第１記憶領域に格納し、前記実行ステップは、前記同期記号が出現してから次の前記同期記号が出現するまでのデータブロックを前記文書単位として前記データストリームに対する走査を実行するものであり、前記走査プランによって命じられた前記第１のストリームに対する走査を文書単位で実行し、前記走査の結果に応じて、前記データストリームである前記第２のストリームについて前記同期記号が出現してから次の前記同期記号が出現するまでのデータブロックに対する走査をスキップすることを特徴とする。

本発明によれば、ディスクＩ／Ｏコストやメモリコストの増大を抑制しつつ、検索条件に応じた検索を高速に行うことが可能になる。

以下に添付図面を参照して、この発明にかかる構造化文書検索装置、方法及びプログラムの最良な実施の形態を詳細に説明する。

図１は、本実施の形態にかかる構造化文書管理システムの構成を例示する図である。本システムは、同図に示すように、構造化文書検索装置であるサーバコンピュータ（以下、サーバという）１にＬＡＮ（Local Are Network）等のネットワーク２を介して構造化文書入出力装置であるクライアントコンピュータ（以下、クライアント端末という）３が複数台接続されたサーバクライアントシステムである。

図２は、サーバ１及びクライアント端末３のハードウェア構成を例示する図である。サーバ１及びクライアント端末３のハードウェア構成は、一般的なパーソナルコンピュータと同様である。サーバ１及びクライアント端末３は、情報処理を行うＣＰＵ（Central Processing Unit）１０１、ＢＩＯＳなどを記憶した読出し専用メモリであるＲＯＭ（Read Only Memory）１０２、各種データを書換え可能に記憶するＲＡＭ（Random Access Memory）１０３、各種データベースとして機能するとともに各種のプログラムを格納するＨＤＤ（Hard Disk Drive）１０４、記憶媒体１１０を用いて情報を保管したり外部に情報を配布したり外部から情報を入手するためのＣＤ−ＲＯＭドライブ等の媒体駆動装置１０５、ネットワーク２を介して外部の他のコンピュータと通信により情報を伝達するための通信制御装置１０６、処理経過や結果等を操作者に表示するＣＲＴ（Cathode Ray Tube）やＬＣＤ（Liquid Crystal Display）等の表示部１０７、並びに操作者がＣＰＵ１０１に命令や情報等を入力するためのキーボードやマウス等の入力部１０８等から構成されており、これらの各部間で送受信されるデータをバスコントローラ１０９が調停して動作する。

このようなサーバ１及びクライアント端末３では、ユーザが電源を投入するとＣＰＵ１０１がＲＯＭ１０２内のローダーというプログラムを起動させ、ＨＤＤ１０４よりＯＳ（Operating System）というコンピュータのハードウェアとソフトウェアとを管理するプログラムをＲＡＭ１０３に読み込み、このＯＳを起動させる。このようなＯＳは、ユーザの操作に応じてプログラムを起動したり、情報を読み込んだり、保存を行ったりする。ＯＳのうち代表的なものとしては、Ｗｉｎｄｏｗｓ（登録商標）、ＵＮＩＸ（登録商標）等が知られている。これらのＯＳ上で走る動作プログラムをアプリケーションプログラムと呼んでいる。なお、アプリケーションプログラムは、所定のＯＳ上で動作するものに限らず、後述の各種処理の一部の実行をＯＳに肩代わりさせるものであってもよいし、所定のアプリケーションソフトやＯＳなどを構成する一群のプログラムファイルの一部として含まれているものであってもよい。

ここで、サーバ１は、アプリケーションプログラムとして、構造化文書管理プログラムをＨＤＤ１０４に記憶している。この意味で、ＨＤＤ１０４は、構造化文書管理プログラムを記憶する記憶媒体として機能する。一方、クライアント端末３は、アプリケーションプログラムとして、構造化文書入出力プログラムをＨＤＤ１０４に記憶している。この意味で、ＨＤＤ１０４は、構造化文書入出力プログラムを記憶する記憶媒体として機能する。

また、一般的には、サーバ１及びクライアント端末３のＨＤＤ１０４にインストールされるアプリケーションプログラムは、ＣＤ−ＲＯＭやＤＶＤなどの各種の光ディスク、各種光磁気ディスク、フレキシブルディスクなどの各種磁気ディスク、半導体メモリ等の各種方式のメディア等の記憶媒体１１０に記録され、この記憶媒体１１０に記録された動作プログラムがＨＤＤ１０４にインストールされる。このため、ＣＤ−ＲＯＭ等の光情報記録メディアやＦＤ等の磁気メディア等の可搬性を有する記憶媒体１１０も、アプリケーションプログラムを記憶する記憶媒体となり得る。さらには、アプリケーションプログラムは、例えば通信制御装置１０６を介して外部から取り込まれ、ＨＤＤ１０４にインストールされても良い。

サーバ１は、ＯＳ上で動作する構造化文書管理プログラムが起動すると、この構造化文書管理プログラムに従い、ＣＰＵ１０１が各種の演算処理を実行して各部を集中的に制御し各種機能を実現させる。一方、クライアント端末３は、ＯＳ上で動作する構造化文書入出力プログラムが起動すると、この構造化文書入出力プログラムに従い、ＣＰＵ１０１が各種の演算処理を実行して各部を集中的に制御し各種機能を実現させる。

ここで、クライアント端末３において実現される各種機能について説明する。図３は、サーバ１の機能的構成及びクライアント端末３の機能的構成を例示する図である。同図に示されるように、クライアント端末３は、構造化文書登録部３０と、構造化文書検索処理部３１とを有する。構造化文書登録部３０は、入力部１０８から入力された構造化文書データやクライアント端末３のＨＤＤ１０４に予め記憶された構造化文書データを、後述するサーバ１の構造化文書のデータベース（構造化文書ＤＢ）１３に登録するためのものである。この構造化文書登録部３０は、登録すべき構造化文書データとともに登録要求をサーバ１に送信する。構造化文書検索処理部３１は、ユーザにより入力部１０８から入力された指示に従って、構造化文書ＤＢ１３に格納された構造化文書データのうち所望の構造化文書データを検索するための検索条件などが記述されたクエリデータを作成し、当該クエリデータを検索要求としてサーバ１へ送信する。また、構造化文書検索処理部３１は、サーバ１から送信された当該検索要求に応じた結果データを受け取り、これを表示部１０７に表示する。

次に、サーバ１において実現される各種機能について図３を用いて説明する。サーバ１は、格納処理部１１と、検索処理部１２と、構造化文書ＤＢ１３とを有する。構造化文書ＤＢ１３は、例えばＨＤＤ１０４に生成されるデータベースであり、構造化文書ＤＢ１３には構造化文書データが格納される。図４〜６は、構造化文書ＤＢ１３に格納される構造化文書データを例示する図である。

構造化文書データを記述するための代表的な言語としてＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）が挙げられる。図４〜６に示される構造化文書データは、ＸＭＬで記述されたものである。ＸＭＬでは、文書構造を構成する個々のパーツを要素（エレメント：Ｅｌｅｍｅｎｔ）と呼び、要素はタグ（ｔａｇ）を使って記述する。具体的には、要素の始まりを示すタグ（開始タグ）と、終わりを示すタグ（終了タグ）の２つのタグでデータを挟み込んで、１つの要素を表現している。なお、開始タグと終了タグで挟み込まれたテキストデータは、当該開始タグと終了タグで表された１つの要素に含まれるテキスト要素（テキストノード）である。また、テキスト要素を挟み込む開始タグ及び終了タグの組を構造要素という。図４に示される文書１は、＜書籍＞というタグで囲まれた要素のルート要素が存在する。この「書籍」という構造要素は、＜タイトル＞、＜筆者＞、＜本文＞といったタグで囲まれた複数の子要素となる構造要素を包含する。そして、＜タイトル＞は、「ＸＭＬデータベース」というテキスト要素をもつ。構造要素＜筆者＞は２つ存在している。「服部〜」というテキスト要素を子要素に持った構造要素＜筆者＞が先頭であり、「田中〜」というテキスト要素を子要素に持った構造要素＜筆者＞がそれに続く。図５に示される文書２は、＜本＞いうタグで囲まれた要素のルート要素が存在する。同様に、図６に示される文書３は、＜書籍＞というタグで囲まれた要素のルート要素が存在する。

また、構造化文書ＤＢ１３には、構造ガイドデータ領域１３ａとデータストリーム領域１３ｂと索引ストリーム領域１３ｃとが設けられる。構造ガイドデータ領域１３ａには、構造ガイドデータが格納される。構造ガイドデータとは、構造化文書ＤＢ１３に格納された構造化文書データの集合全体に渡る階層構造の要約を示すデータである。データストリーム領域１３ｂには、構造ガイドデータに基づいて構造化文書データから生成されるデータストリームが格納される。索引ストリーム領域１３ｃには、構造化文書データを検索する際の索引となる索引ストリームが格納される。これらの構造ガイドデータ、データストリーム及び索引ストリームの詳細については後述する。

格納処理部１１は、クライアント端末３からの登録要求を受けて、クライアント端末３から送信された構造化文書データを構造化文書ＤＢ１３に格納する。格納処理部１１は、格納インターフェイス部２０とストリーム変換部２１とデータストリーム格納部２２と索引ストリーム格納部２３とを有する。格納インターフェイス部２０は、クライアント端末３から送信された構造化文書データを構文解析した後、ストリーム変換部２１を呼び出して、データストリーム及び索引ストリームを生成させる。

ストリーム変換部２１は、格納インターフェイス部２０が構文解析した構造化文書データについて、構造化文書ＤＢ１３の構造ガイドデータ領域１３ａに格納されている構造ガイドデータを参照及び更新することで、当該構造化文書データ中にある階層構造情報をデータストリームに変換する。即ち、ストリーム変換部２１は、構造化文書データの構文解析の結果得られる要素の並びとして、構造要素及びテキスト要素を発生順に並べたものをデータストリームとして生成する。要素の発生順とは、構造化文書をルート要素からトラバースするときの結果の順番、即ち構文解析の結果順である。つまり、構造化文書データを親要素から子要素、兄要素から弟要素という要素の順番をさす。

ここでストリーム変換部２１がデータストリームを生成する方法の概要について説明する。まず、その生成に用いる構造ガイドデータについて説明する。構造ガイドデータは、階層構造をなしており、以下の条件を保持している。
（a）システムに格納された構造化文書データ集合に現れる全てのパスは、構造ガイドデータに現れる。
（b）構造ガイドデータに現れる全てのパスは、システムに格納された構造化文書データ集合に現れる。
（c）構造ガイドデータに現れるパスは全て一意的である。

図７は、構造ガイドデータの一例を概念的に示す図である。図４に示した構造化文書データを構文解析した結果、構造ガイドデータが生成される。構造ガイドデータは複数のガイドノードとアークとからなる階層構造である。各ガイドノードには、タグ名が記されている。テキスト要素に対しては、「ｔｅｘｔ（）」という組み込みタグ名が記されている。また、ルートのガイドノードには「ＲＯＯＴ」というタグ名が設定されている。各ガイドノードには、一意なＩＤ（ＧＩＤ）が割り当てられており、Ｇ０〜Ｇ９までのＩＤが使われている。新たな構造化文書データが構造化文書ＤＢ１３に格納される毎に、それまで存在しなかったガイドノード集合が構造化文書ＤＢ１３の構造ガイドデータ領域１３ａに追加されることで、構造ガイドデータは漸増的に更新されていく。

データストリームは、構造化文書データをルートから深さ優先で辿って行くときに通過する文書ノードに対応するＧＩＤを並べた配列となる。このように配列された各要素を配列要素という。

図８は、データストリームの一例を概念的に示す図である。このデータストリームの例は、図７に示した構造ガイドデータを使って図４の構造化文書データをＧＩＤの配列に変換したものである。各配列要素は、ＧＩＤを使って数値化されている。
Ｅ０ 「ＲＯＯＴ」に対応する配列要素：（Ｇ）０
Ｅ１ 「書籍」に対応する配列要素：（Ｇ）１
Ｅ２ 「筆者」に対応する配列要素：（Ｇ）２
・・・
このように要素を配列してデータストリームを生成することで、２次元的な構造の構造化文書データを１次元の配列データとなるデータストリームにストリーム変換部２１は変換する。

ここでストリーム変換部２１が構造ガイドデータを更新する方法の概要について説明する。ストリーム変換部２１は、新たに格納すべき構造化文書データと、この構造化文書データの格納先のフォルダのＧＩＤを含む登録要求をクライアント端末３から受け取ると、当該構造化文書データの構文解析を行う。なお、クライアント端末３は、格納先のフォルダのＧＩＤをサーバ１に問い合わせて予め取得しているものとする。そして、ストリーム変換部２１は、構造化文書データの複数のオブジェクトデータからなる階層構造を解析結果として得て、これをＲＡＭ１０３などのメモリ上に展開する。ＸＭＬ形式の構造化文書データについてはＤＯＭ（Document Object Model）形式のオブジェクトデータに展開される。そして、ストリーム変換部２１は、解析結果をそのルートから辿ることによって、当該構造化文書データの構造、すなわち、当該構造化文書データ中の各要素に対応する複数のノードと、当該複数のノードからなる構造（Ｓｃとする）とを抽出する。そして、ストリーム変換部２１は、格納先フォルダのＧＩＤ（ＧＩＤｐとする）をキーに構造ガイドデータ領域１３ａを走査して対応する構造（Ｓｐとする）を取得する。その後、ストリーム変換部２１は、ＳｃとＳｐとの照合を行い、Ｓｃの構造要素に対応するＳｐの構造要素があれば、当該Ｓｃの構造要素に当該Ｓｐの構成要素のＧＩＤを付与し、Ｓｃの構造要素に対応するＳｐの構造要素がなければ、Ｓｐに存在せずに、Ｓｃに存在する新たな要素に新たなＧＩＤを付与し、Ｓｐに当該新たな要素を追加する。また、ストリーム変換部２１は、Ｓｃの当該新たな要素に当該新たなＧＩＤを付与する。この操作をＳｃの全ての構造要素に対しストリーム変換部２１は行う。そして、ストリーム変換部２１は、更新したＳｐを構造ガイドデータ領域１３ａに格納する。これにより、構造ガイドデータ領域１３ａに格納される構造ガイドデータの更新がなされる。最後に、ストリーム変換部２１は、格納すべき構造化文書データの各要素にＧＩＤを付与する。尚、以上の処理の詳細については例えば特許文献３に示されているためここでは詳細な説明を省略する。

また、ストリーム変換部２１は、格納インターフェイス部２０が構文解析した構造化文書データについて、事前に設定された設定情報に基づいて、当該構造化文書データ中にあるテキスト要素を索引ストリームに変換する。即ち、ストリーム変換部２１は、構造化文書データの構文解析の結果得られる要素のうち、設定情報に合致するテキスト要素の集合を選択して、発生順に並べたものを索引ストリームとして生成する。設定情報は、索引化すべきテキスト要素を指定するものであり、通常は構造化文書データに対するパス指定を使う。図９は、設定情報の一例を示す図である。同図に示されるように、設定情報は、「：」が区切り記号になっているカラム付きのレコード表現である。第１カラムがパス指定を示しており、第２カラムがストリーム番号を示している。例えば、第１レコードは、構造化文書データのルート直下（．／）の構造要素＜タイトル＞の子要素となるテキスト要素を索引化して索引ストリーム１に格納するという指定を意味している。まだ、第２レコードは、ルート直下の構造要素＜筆者＞の子要素となるテキスト要素を索引化して索引ストリーム２に格納するという指定を意味している。これは、構造化文書データが格納される度に更新するなど自動的に設定することもできるが、ユーザが事前に指定することもある。尚、索引ストリームには文書単位毎に索引となるテキスト要素が含まれる。複数種類のテキスト要素が指定される場合は、ストリーム変換部２１は索引ストリームを複数個生成する。

図３の説明に戻る。データストリーム格納部２２は、ストリーム変換部２１が生成したデータストリームに対して文書単位毎に同期信号ＳＹＭＣをヘッダ情報に埋め込むと共に文書数を示すブロック数もヘッダ情報に埋め込んで、当該データストリームをデータストリーム領域１３ｂに格納する。索引ストリーム格納部２３は、ストリーム変換部２１が生成した索引ストリームに対して対応する文書単位毎に同期信号ＳＹＭＣをヘッダ情報に埋め込んで、当該索引ストリームを索引ストリーム領域１３ｃに格納する。

図１０は、以上のようにして、図４〜６に示される構造化文書データから変換されたデータストリーム及び索引ストリームを例示する図である。データストリームは必ず１本である。索引ストリームは図５の設定情報の通り２本存在する。図４〜６に各々示される文書１、文書２及び文書３が順番に格納されている。各ストリームは、１２８Ｂ、１０２４Ｂ、４０９６Ｂといった固定長のブロックの並びで構成されている。ここで簡単のため、データストリームの場合はＤａｔａＢｌｏｃｋ［ｉ］（ｉ＝０、１、２、．．．）という１次元の配列イメージで参照することにする。索引ストリームの場合は複数存在するので、ＩｎｄｅｘＢｌｏｃｋ［ｊ］［ｉ］（ｉ＝０、１、２、．．．．；ｊ＝０、１、２、．．．；ｊは索引ストリームの本数）という２次元の配列イメージで参照することにする。

データストリームのＤａｔａＢｌｏｃｋ［ｘ］、ＤａｔａＢｌｏｃｋ［ｘ＋１］には文書１が格納されている。文書１の＜タイトル＞要素の子要素となるテキスト要素は索引ストリーム１のＩｎｄｅｘＢｌｏｃｋ［１］［ｙ］に格納されている。文書１の構造要素＜筆者＞の子要素となるテキスト要素は索引ストリーム２のＩｎｄｅｘＢｌｏｃｋ［２］［ｚ］に格納されている。データストリームのＤａｔａＢｌｏｃｋ［ｘ＋２］には文書２が格納されている。文書２の構造要素＜タイトル＞の子要素となるテキスト要素は索引ストリーム１のＩｎｄｅｘＢｌｏｃｋ［１］［ｙ＋１］に格納されている。文書２の構造要素＜筆者＞の子要素となるテキスト要素は索引ストリーム２のＩｎｄｅｘＢｌｏｃｋ［２］［ｚ＋１］、ＩｎｄｅｘＢｌｏｃｋ［２］［ｚ＋２］に格納されている。データストリームのＤａｔａＢｌｏｃｋ［ｘ＋３］には文書３が格納されている。文書３の構造要素＜タイトル＞の子要素となるテキスト要素は索引ストリーム１のＩｎｄｅｘＢｌｏｃｋ［１］［ｙ＋２］に格納されている。文書３の構造要素＜筆者＞の子要素となるテキスト要素は索引ストリーム２のＩｎｄｅｘＢｌｏｃｋ［２］［ｚ＋３］に格納されている。各文書の先頭にはヘッダ情報があり、このヘッダ情報内にＳＹＮＣ（Ｓ）と呼ばれる同期記号が埋め込まれている。この同期信号により文書単位でデータブロックを区別することができる。その後、＜書籍＞、＜タイトル＞、「ＸＭＬデータベース」、＜／タイトル＞、．．．というように出現順に各要素が格納されている。１ブロックでは格納できないので、連続してＤａｔａＢｌｏｃｋ［ｘ＋１］にも要素が格納されている。この格納処理はイベントベースのＸＭＬパーサＳＡＸ（Ｓｉｍｐｌｅ ＡＰＩ ｆｏｒ ＸＭＬ）を組み合わせることで実現できる。

図１１は、ＤａｔａＢｌｏｃｋ［ｘ］とＤａｔａＢｌｏｃｋ［ｘ＋１］を具体化した図である。ＤａｔａＢｌｏｃｋ［ｘ］のヘッダ情報には上述した同期信号ＳＹＮＣと本文書のブロック数（２）とが格納されている。尚、データストリーム、索引ストリーム１及び索引ストリーム２を区別する必要がない場合には、これらを単にストリームという。

図３の説明に戻る。検索インターフェイス部２４は、クライアント端末３から送信された検索要求を受けて、当該検索要求であるクエリデータを構文解析した後、ストリーム集合走査プラン生成部２５を呼び出して走査プランを生成させる。ここでは例えばＸＱｕｅｒｙにより記述されたクエリデータを取り扱う。

ＸＭＬでは、Ｗ３Ｃで提案されているＸＱｕｅｒｙ（ＸＭＬ Ｑｕｅｒｙ Ｌａｎｇｕａｇｅ）という問合せ言語があり、これに基づいた問合せ記述方法に則っている。ＸＱｕｅｒｙは、ＦＬＷＲ（ｆｏｒ-ｌｅｔ-ｗｈｅｒｅ-ｒｅｔｕｒｎ）という構文パターンで説明できる。以下に、ＸＱｕｅｒｙの言語仕様を手続き的な観点で説明する。ｆｏｒ節の構文は、「ｆｏｒ 変数 ｉｎ 式」である。ｆｏｒ節の構文は、式を満足するものを変数に代入してループするという意味を持つ。ｌｅｔ節の構文は、「ｌｅｔ 変数 := 式」である。ｌｅｔ節の構文は、式を満足するものを集約してシーケンスとして変数に代入するという意味を持つ。シーケンスとは、フラットなリストである。ｗｈｅｒｅ節は、Fで繰り返されるループを制限するものである。ｗｈｅｒｅ節の構文は、「ｗｈｅｒｅ 式」である。ｗｈｅｒｅ節の構文は、式を満足するものだけループをまわし、そうでないものはループをスキップするという意味を持つ。ｒｅｔｕｒｎ節は、ＸＱｕｅｒｙを処理した結果をフォーマット化するものである。ｒｅｔｕｒｎ節の構文は、「ｒｅｔｕｒｎ 式」である。ｒｅｔｕｒｎ節の構文は、変数を含む任意のＸＭＬデータを記述することができる。変数の構文は、「＄文字列」である。入れ子問い合わせなどで二重宣言された場合を除き、同じ文字列を持つ変数は同一のものと見なされる。ＸＭＬデータの要素間の階層条件を指定するオペレータとして、ＸＱｕｅｒｙでは以下のようなものがある。
・“／” 要素間は親子関係であることを示すオペレータ
・“／／” 要素間は先祖子孫関係であることを示すオペレータ
・“．” 任意の要素

図１２は、以上のようなＸＱｕｅｒｙにより記述されたクエリデータの一例を示す図である。同図には、検索要求として以下のことを要求するクエリデータ１が示されている。構造化文書ＤＢ「ＲＯＯＴ」の階層木の中に＜書籍＞という構造要素があり、この＜書籍＞という構造要素の中に＜タイトル＞という構造要素があり、この＜タイトル＞という構造要素の中に「ＸＭＬ」というテキスト要素が出現し、この＜書籍＞という構造要素の中に＜筆者＞という構造要素があり、この＜筆者＞という構造要素の中に「服部」というテキスト要素が出現する構造化文書データの＜書籍＞の一覧を返すことである。

ストリーム集合走査プラン生成部２５は、検索インターフェイス部２４からの呼び出しに応じて、クエリデータから走査プランを生成する。走査プランを生成する具体的な方法については後述の動作欄で説明する。

さらに、検索インターフェイス部２４は、ストリーム集合走査プラン実行部２６を呼び出して、ストリーム集合走査プラン生成部２５が生成した走査プランを実行させる。その後、検索インターフェイス部２４は、詳細条件検査部２７を呼び出して最終的な結果データを生成させてこれを例えばＲＡＭ１０３に記憶させる。そして、検索インターフェイス部２４は、当該結果データを検索要求に応じた検索結果としてクライアント端末３に送信する。ストリーム集合走査プラン生成部２５は、上述した設定情報を参照して、走査プラン構造化文書ＤＢ１３にアクセスするための手順として走査プランを生成する。上述したように、構造化文書ＤＢ１３には、データストリームや索引ストリームなどの複数のストリームが存在する。このような複数のストリームをどの手順で走査するかを示す走査プランをストリーム集合走査プラン生成部２５は生成する。ストリーム集合走査プラン実行部２６は、ストリーム集合走査プラン生成部２５が生成した走査プランを実行して結果データを生成する。詳細条件検査部２７は、クエリデータで指定された検索条件のうち、ストリーム集合走査プラン生成部２５が生成した走査プランだけではチェックできない詳細な検索条件（詳細条件という）に基づいて結果データを検査して、最終的な結果データを生成してこれをＲＡＭ１０３に記憶させる。

（２）動作
＜走査プラン生成処理＞
次に、本実施の形態にかかるサーバ１の行う処理の手順について説明する。まず、サーバ１が走査プランを生成する処理の手順について図１３を用いて説明する。検索インターフェイス部２４は、クライアント端末３から送信された検索要求を受け取ると、当該検索要求であるクエリデータを構文解析した後、ストリーム集合走査プラン生成部２５を呼び出して走査プランを生成させる。ストリーム集合走査プラン生成部２５は、まず、クエリデータからクエリグラフを生成する（ステップＳ１）。クエリグラフは、タグとタグとの間の関連をツリー形式で表現することで生成することができる。ＸＱｕｅｒｙにより記述されるクエリデータからのクエリグラフは、Ｙａｃｃ（Ｙｅｔ Ａｎｏｔｈｅｒ Ｃｏｍｐｉｌｅｒ Ｃｏｍｐｉｌｅｒ）などの構文解析ツールを使うことで機械的に生成することができる。このようなクエリグラフの生成は、例えば、特許文献３に示されるパスパターンコンパイル処理と類似処理とにより行うことができる。

図１４は、図８に示したクエリデータ１から生成されたクエリグラフを示す模式図である。同図に示すように、クエリグラフとは、クエリデータを構成する条件をグラフで表現したものになっている。図８に示したクエリデータを構成する条件とは、以下の通りである。
・ＸＭＬデータの要素間階層条件
−root要素の子孫要素（／／）に構造要素＜書籍＞がある。
−構造要素＜書籍＞の子要素（／）に構造要素＜タイトル＞がある。
−構造要素＜書籍＞の子要素（／）に構造要素＜筆者＞がある。
・ＸＭＬデータのテキスト比較条件
−構造要素＜タイトル＞のテキスト要素は「ＸＭＬ」を含んでいる（contains）。
−構造要素＜筆者＞のテキスト要素は「服部」を含んでいる（contains）。

尚、構造化文書ＤＢ１３上のＸＭＬデータの要素が束縛される変数に相当するものを変数ノードと呼ぶ。これは図１４においては丸印で示されている。また、クエリデータで明示的に宣言された変数「＄文字列」に相当する変数ノードを軸ノードと呼ぶこれは図１４においては二重丸で示されている。また、変数ノード間に対する条件をクエリグラフ述語（以下、述語ノードという）と呼ぶ。これは図１４においては菱形で示されている。

次いで、ストリーム集合走査プラン生成部２５は、このようなクエリグラフを走査しクエリグラフ述語をチェックすることで、クエリグラフを複数のサブグラフに分解する。分解する観点には以下のようなものがある。
・テキスト比較条件ＣＭＰを有するサブグラフ
・要素間階層条件ＴＡＧだけで構成されるサブグラフ

図１５は、図１４に示したクエリグラフを上述の観点から分解したサブグラフを例示する図である。同図に示されるように、ここでは、３つの重なったサブグラフに分解される。それぞれサブグラフＡ、Ｂ、Ｃと名付ける。
・サブグラフＡは、要素間階層条件ＴＡＧだけで構成されるサブグラフである。
・サブグラフＢ,Ｃは、テキスト比較条件ＣＭＰを各々有するサブグラフである。

そして、ストリーム集合走査プラン生成部２５は、このように分解した各サブグラフに対してストリームを割り当てる（ステップＳ２）。ここでは例えば以下のようにサブグラフＡ〜Ｃに対して順にデータストリーム、索引ストリーム１及び索引ストリーム２が各々割り当てられる。
・サブグラフＡは構造に関するものなので、サブグラフＡにはデータストリームが割り当てられる。
・サブグラフＢは構造要素＜タイトル＞に関する比較条件を有するものである。ここでは図９に示した設定情報が参照され、サブグラフＢには索引ストリーム１が割り当てられる。
・サブグラフＣは構造要素＜筆者＞に関する比較条件を有するものである。ここでは図９に示した設定情報を参照が参照され、サブグラフＣには索引ストリーム２が割り当てられる。

このようにしてストリーム集合走査プラン生成部２５は、クエリグラフの各要素を索引ストリームで処理できる部分とデータストリームで処理できる部分とに分類すると共に、設定情報を参照して、サブグラフ毎に各ストリームを割り当てる。

次いで、ストリーム集合走査プラン生成部２５は、ストリームのデータサイズや選択率を考慮することで、３つのストリームの走査の順番を決定する（ステップＳ３）。尚、この決定には様々なヒューリスティックスを用いることができる。最も簡単なものとして、各ストリームのデータサイズの優先順位が挙げられる。この場合例えばデータサイズの小さい順に各ストリームの順位をストリーム集合走査プラン生成部２５は決定する。尚、一般的なデータベース技術において、検索条件が索引（ストリーム）に設定されたときに検索条件を満足する要素の数の割合を選択率（SELECTIVITY）と称する。これには区間度数分布情報などの統計データが用いられる。索引が低い選択率を有する場合には、その索引は、データベース表内の比較的少数のレコードを表す。索引が高い選択率を有する場合には、その索引は、データベース表内の比較的多数のレコードを表す。ここでは、事前の統計情報により選択率が索引ストリーム１、索引ストリーム２、データストリームの順番で大きいものとし、この順番を用いる。

次いで、ストリーム集合走査プラン生成部２５は、各ストリームに対する走査を命じる走査命令と、サブグラフ間、即ち、各サブグラフが割り当てられたストリーム間の論理関係に応じて各ストリームに対する走査命令を接続する制御命令とを含む走査プランを生成する（ステップＳ４）。具体的には、ストリーム集合走査プラン生成部２５は、ストリーム間の論理関係がＡＮＤ関係であれば「ＦＩＬＴＥＲ」といった制御命令で各ストリームの走査命令を接続し、ストリーム間の論理関係がＯＲ関係であれば「ＯＲ」といった制御命令で各ストリームの走査命令を接続して走査プランを生成する。これらの「ＦＩＬＴＥＲ」や「ＯＲ」といった制御命令は、第１のストリームに対する走査命令に従った走査の結果に応じて第２のストリームに対する走査が実行されるように当該第２のストリームに対する走査命令を接続する制御命令となる。

図１６は、クエリデータ１に対してストリーム集合走査プラン生成部２５が生成する走査プランを示す図である。この走査プランは、索引ストリーム１に対する走査を命じる走査命令と、索引ストリーム２に対する走査を命じる走査命令と、データストリームに対する走査を命じる走査命令とを含む。各ストリーム間の論理関係はＡＮＤ関係であるため、これらが「ＦＩＬＴＥＲ」といった制御命令で接続されている。走査の手順としては、索引ストリーム１を走査した後、索引ストリーム２を走査し、最後にデータストリームを走査するという手順となる。また段数という概念があり、索引ストリーム１の走査が１段目、索引ストリーム２の走査が２段目ということになる。そして「ＦＩＬＴＥＲ」が、上位段数の走査結果を受けて、走査範囲を絞り込むという制御命令を示している。つまり、この走査プランによれば、索引ストリーム１に対する走査命令に従って走査が実行された結果に応じて、制御命令によって当該走査命令に接続される、索引ストリーム２に対する走査命令に従った走査が実行されないことにより、索引ストリーム２に対する不要な走査がスキップされる。また、索引ストリーム２に対する走査命令に従って走査が実行された結果に応じて、制御命令によって当該走査命令に接続される、データストリームに対する走査命令に従った走査が実行されないことにより、データストリームに対する不要な走査がスキップされる。

＜走査プラン実行処理＞
次に、サーバ１が走査プランを実行する処理の手順について図１７を用いて説明する。サーバ１のストリーム集合走査プラン実行部２６は、走査プランに従って、ストリームの終端に到達するまで（ステップＳ２０：ＹＥＳ）、文書単位で以下の処理を繰り返し行う。まず、ストリーム集合走査プラン実行部２６は、走査プランを実行するためのパラメータとして「Ｎ：＝１、ＯＰ：＝ＳＣＡＮ」を設定する（ステップＳ２１）。即ちここでストリーム集合走査プラン実行部２６は、走査の対象の段Ｎを「１段目」に設定し、実行内容として「走査」を設定する。そして、走査の対象となる段Ｎが最終段でなく（ステップＳ２３：ＮＯ）、実行内容が「走査」であり（ステップＳ２４：ＳＣＡＮ）、制御命令が「ＦＩＬＴＥＲ」である場合（ステップＳ２５：ＹＥＳ）、ステップＳ２６に進む。ステップＳ２６では、ストリーム集合走査プラン実行部２６は、走査対象の段Ｎのストリームについて、次の同期信号ＳＹＮＣが出現するまで走査して、走査範囲内における検索条件に該当するものがあるか否かを判定する。即ち、ストリーム集合走査プラン実行部２６は、同期信号が出現してから次の同期信号が出現するまでの間のデータブロックを文書単位の走査範囲として走査する。ただし、この間のデータブロックが複数ある場合には、検索条件によっては、全てのデータブロックではなく一部のデータブロックのみ走査すれば良い場合もある。

次いで、ストリーム集合走査プラン実行部２６は、ステップＳ２６の走査結果が肯定的である場合（ステップＳ２７：ＹＥＳ）、ストリーム集合走査プラン実行部２６は、実行内容として「走査」を設定して、ステップＳ２２に進む。一方、ステップＳ２６の走査結果が否定的である場合（ステップＳ２７：ＮＯ）、ストリーム集合走査プラン実行部２６は、実行内容として「スキップ」を設定して、ステップＳ２２に進む。ステップＳ２２では、ストリーム集合走査プラン実行部２６は、走査プランを実行するためのパラメータとして「Ｎ：Ｎ＋１」を設定する（ステップＳ２２）。即ちここでストリーム集合走査プラン実行部２６は、走査の対象の段Ｎを１つ増加させる。そしてストリーム集合走査プラン実行部２６はステップＳ２３以降の処理を行う。

尚、制御命令が「ＦＩＬＥＲ」ではなく（ステップＳ２５：ＮＯ）、制御命令が「ＯＲ」である場合（ステップＳ３０：ＹＥＳ）、ステップＳ３１に進む。ステップＳ３１では、ストリーム集合走査プラン実行部２６は、走査対象の段Ｎのストリームについて、次の同期信号ＳＹＮＣが出現するまで走査して、走査範囲内における検索条件に該当するものがあるか否かを判定する。次いで、ストリーム集合走査プラン実行部２６は、ステップＳ３１の走査結果が肯定的である場合（ステップＳ３２：ＹＥＳ）、ストリーム集合走査プラン実行部２６は、実行内容として「走査」を設定して、上述のステップＳ２２に進む。一方、ステップＳ３１の走査結果が否定的である場合（ステップＳ３２：ＮＯ）、ストリーム集合走査プラン実行部２６は、現在の走査対象の段Ｎの次の段のストリームが存在するか否かを判定する（ステップＳ３４）。当該判定結果が否定的である場合、ストリーム集合走査プラン実行部２６は、実行内容として「スキップ」を設定して、上述のステップＳ２２に進む。また、ステップＳ３４の判定結果が肯定的である場合には、上述のステップＳ３１に進む。

尚、実行内容が「走査」ではなく「スキップ」である場合（ステップＳ２４：ＳＫＩＰ）、ストリーム集合走査プラン実行部２６は、走査対象の段Ｎのストリームについて、次の同期信号ＳＹＮＣが出現するまで走査をスキップして（ステップＳ３６）、ステップＳ２２に進む。また、走査の対象の段が最終段を超える場合（ステップＳ２３：ＹＥＳ）、ストリーム集合走査プラン実行部２６は、詳細条件に基づいて結果データを検査して、最終的な結果データを生成して、ステップＳ２０に進む。以上のようにして、ストリーム集合走査プラン実行部２６は走査プランを実行し、ストリームの終端に到達すると（ステップＳ２０：ＹＥＳ）、その実行を終了する。

ここで、サーバ１が走査を実行する処理の具体例について説明する。図１８は、図１６に示した走査プランをサーバ１が実行する処理イメージを示す図である。この例ではストリーム集合走査プラン実行部２６は、索引ストリーム１に含まれる全てのブロックＩｎｄｅｘＢｌｏｃｋ［１］［ｉ］（ｉ＝０、１、２、．．．）を走査することになる。
(GS1)まず、ストリーム集合走査プラン実行部２６は、走査対象の段として１段目である索引ストリーム１のＩｎｄｅｘＢｌｏｃｋ［１］［ｙ］を走査すると、走査範囲内における検索条件として「ＸＭＬ」というテキスト要素が存在するか否かを判定し、ここではこれが存在していると判定する（ステップＳ２１，Ｓ２３〜Ｓ２８）。
(GS2)次いで、ストリーム集合走査プラン実行部２６は、走査対象の段として２段目である索引ストリーム２のＩｎｄｅｘＢｌｏｃｋ［２］［ｚ］を走査すると、走査範囲内における検索条件として「服部」というテキスト要素が存在するか否かを判定し、ここではこれが存在していると判定する（ステップＳ２２，Ｓ２３〜Ｓ２８）。
(GS3)次いで、ストリーム集合走査プラン実行部２６は、走査対象の段として３段目であるデータストリームのＤａｔａＢｌｏｃｋ［ｘ］を走査して、結果データ、即ち、文書１のデータを得る（ステップＳ２２，Ｓ２３〜Ｓ２８）。

その後、詳細条件検査部２７が、（GS3）で得られた結果データを詳細条件に基づいて検査して、最終的な結果データを生成してこれをＲＡＭ１０３に記憶させる（ステップＳ２２，Ｓ２３，Ｓ３７）。

(GS4)そして、ストリーム集合走査プラン実行部２６は、走査対象の段として１段目である索引ストリーム１の走査に戻り、次のブロックＩｎｄｅｘＢｌｏｃｋ［１］［ｙ＋１］を走査すると、「ＸＭＬ」というテキスト要素が存在していないと判定する（ステップＳ２０〜Ｓ２１，Ｓ２３〜Ｓ２７，Ｓ２９）。
(GS5)この場合、ストリーム集合走査プラン実行部２６は、次に走査対象となる２段目である索引ストリーム２のデータブロックＩｎｄｅｘＢｌｏｃｋ［２］［ｚ＋１］及びＩｎｄｅｘＢｌｏｃｋ［２］［ｚ＋２］の走査をスキップする（ステップＳ２２〜Ｓ２４，Ｓ３６）。
(GS6)同様に、ストリーム集合走査プラン実行部２６は、次に走査対象となる３段目であるデータストリームのデータブロックＤａｔａＢｌｏｃｋ［ｘ＋２］の走査をスキップする（ステップＳ２２〜Ｓ２４，Ｓ３６）。

(GS7)次いで、ストリーム集合走査プラン実行部２６は、走査対象の段として１段目である索引ストリーム１の走査に戻り、次のブロックＩｎｄｅｘＢｌｏｃｋ［１］［ｙ＋２］を走査すると、「ＸＭＬ」というテキスト要素が存在していると判定する（ステップＳＳ２０〜２１，Ｓ２３〜Ｓ２８）。
(GS8)次いで、ストリーム集合走査プラン実行部２６は、走査対象の段として２段目である索引ストリーム２のＩｎｄｅｘＢｌｏｃｋ［２］［ｚ＋３］を走査すると、「服部」というテキスト要素が存在していると判定する（ステップＳ２２，Ｓ２３〜Ｓ２８）。
(GS9)次いで、ストリーム集合走査プラン実行部２６は、走査対象の段として３段目であるデータストリームのＤａｔａＢｌｏｃｋ［ｘ＋３］を走査して、結果データ、即ち、文書３のデータを得る（ステップＳ２２，Ｓ２３〜Ｓ２８）。

その後、詳細条件検査部２７が、（GS9）で得られた結果データを詳細条件に基づいて検査して、最終的な結果データを生成してこれをＲＡＭ１０３に記憶させる（ステップＳ２２，Ｓ２３，Ｓ３７）。

(GS10)その後、ストリーム集合走査プラン実行部２６は、走査対象の段として１段目である索引ストリーム１の走査に戻り、上述の処理を継続する。

以上のようにして、ストリーム集合走査プラン実行部２６は、図１６に示した走査プランについて、索引ストリーム１に対する走査命令に従って走査を実行した結果に応じて、制御命令によって当該走査命令に接続される、索引ストリーム２に対する走査命令に従った走査を実行しないことにより、索引ストリーム２に対する不要な走査をスキップする。また、ストリーム集合走査プラン実行部２６は、索引ストリーム２に対する走査命令に従って走査が実行した結果に応じて、制御命令によって当該走査命令に接続される、データストリームに対する走査命令に従った走査を実行しないことにより、データストリームに対する不要な走査をスキップする。

次に、クエリデータの他の例に基づいて走査プランを生成してこれを実行する場合について説明する。図１９は、クエリデータの他の例を示す図である。同図には、検索要求として以下のことを要求するクエリデータ２が示されている。構造化文書ＤＢ「ＲＯＯＴ」の階層木の中に＜本＞という構造要素があり、この＜本＞という構造要素の中に＜タイトル＞という構造要素があり、この＜タイトル＞という構造要素の中に「ＸＭＬ」というテキスト要素が出現し、この＜本＞という構造要素の中に＜筆者＞という構造要素があり、この＜筆者＞という構造要素の中に「服部」というテキスト要素が出現する構造化文書データの＜本＞の一覧を返すことである。

図２０は、図１９に示したクエリデータ２に対してストリーム集合走査プラン生成部２５が生成する走査プランを示す図である。この走査プランは、データストリームに対する走査命令と、索引ストリーム１に対する走査命令と、索引ストリーム２に対する走査命令とを含み、これらが「ＦＩＬＴＥＲ」といった制御命令で接続されている。走査の手順としては、データストリームを走査した後、索引ストリーム１を走査し、最後に索引ストリーム２を走査するという手順となる。つまり、この走査プランによれば、データストリームを走査した結果、索引ストリーム１の不要な走査をスキップし、索引ストリーム２を走査した結果、索引ストリーム２の不要な走査をスキップすることになる。

次に、図２０に示した走査プランをサーバ１が実行する処理の概要について図２１を道いて説明する。この例ではストリーム集合走査プラン実行部２６は、データストリームに含まれる全てのブロックＤａｔａＢｌｏｃｋ［ｉ］（ｉ＝０、１、２、．．．）を走査することになる。
(GS1´)まず、ストリーム集合走査プラン実行部２６は、走査対象の段として１段目であるデータストリームのＩｎｄｅｘＢｌｏｃｋ［１］［ｘ］を走査すると、走査範囲内における検索条件として、「ＲＯＯＴ」の階層木の中に「本」という構造要素が存在するか否かを判定し、ここではこれが存在しないと判定する（ステップＳ２１，Ｓ２３〜Ｓ２７，Ｓ２９）。尚、「本」という構造要素は同一の文書内の要素のうち１番目の要素であるため、同一の文書についてのブロックのうち２番目以降のブロック、ここでは、ＤａｔａＢｌｏｃｋ［ｘ＋１］を走査する必要はない。
(GS2´)この場合、ストリーム集合走査プラン実行部２６は、走査対象の段として２段目である索引ストリーム１のＩｎｄｅｘＢｌｏｃｋ［１］［ｙ］の走査をスキップする（ステップＳ２２〜Ｓ２４，Ｓ３６）。
(GS3´)同様に、ストリーム集合走査プラン実行部２６は、次に走査対象となる３段目である索引ストリーム２のデータブロックＩｎｄｅｘＢｌｏｃｋ［２］［ｚ］の走査をスキップする（ステップＳ２２〜Ｓ２４，Ｓ３６）。

(GS4´)そして、ストリーム集合走査プラン実行部２６は、走査対象の段として１段目であるデータストリームの走査に戻り、次のブロックＤａｔａＢｌｏｃｋ［ｘ＋２］を走査すると、「ＲＯＯＴ」の階層木の中に「本」という構造要素が存在すると判定する（ステップＳＳ２０〜２１，Ｓ２３〜Ｓ２８）。
(GS5´)次いで、ストリーム集合走査プラン実行部２６は、走査対象の段として２段目である索引ストリーム１のＩｎｄｅｘＢｌｏｃｋ［１］［ｙ＋１］を走査すると、走査範囲内における検索条件として「ＸＭＬ」というテキスト要素が存在するか否かを判定し、ここではこれが存在していないと判定する（ステップＳ２２〜Ｓ２７，Ｓ２９）。
(GS6´)この場合、ストリーム集合走査プラン実行部２６は、次に走査対象となる３段目である索引ストリーム２のデータブロックＩｎｄｅｘＢｌｏｃｋ［２］［ｚ＋１］及びＩｎｄｅｘＢｌｏｃｋ［２］［ｚ＋２］の走査をスキップする（ステップＳ２２〜Ｓ２４，Ｓ３６）。

(GS7´)そして、ストリーム集合走査プラン実行部２６は、走査対象の段として１段目であるデータストリームの走査に戻り、次のブロックＤａｔａＢｌｏｃｋ［ｘ＋３］を走査すると、「ＲＯＯＴ」の階層木の中に「本」という構造要素が存在しないと判定する（ステップＳ２１，Ｓ２３〜Ｓ２７，Ｓ２９）。
(GS8´)この場合、ストリーム集合走査プラン実行部２６は、走査対象の段として２段目である索引ストリーム１のＩｎｄｅｘＢｌｏｃｋ［１］［ｙ＋２］の走査をスキップする（ステップＳ２２〜Ｓ２４，Ｓ３６）。
(GS9´)同様に、ストリーム集合走査プラン実行部２６は、次に走査対象となる３段目である索引ストリーム２のデータブロックＩｎｄｅｘＢｌｏｃｋ［２］［ｚ＋３］の走査をスキップする（ステップＳ２２〜Ｓ２４，Ｓ３６）。
(GS10´)その後、ストリーム集合走査プラン実行部２６は、走査対象の段として１段目であるデータストリームの走査に戻り、上述の処理を継続する。

以上のようにして、ストリーム集合走査プラン実行部２６は、図２０に示した走査プランについて、データストリームに対する走査命令に従って走査を実行した結果に応じて、制御命令によって当該走査命令に接続される、索引ストリーム１に対する走査命令に従った走査を実行しないことにより、索引ストリーム１に対する不要な走査をスキップする。また、ストリーム集合走査プラン実行部２６は、索引ストリーム１に対する走査命令に従って走査が実行した結果に応じて、制御命令によって当該走査命令に接続される、索引ストリーム２に対する走査命令に従った走査を実行しないことにより、索引ストリーム２に対する不要な走査をスキップする。

また、クエリデータのその他の例に基づいて走査プランを生成してこれを実行する場合について説明する。図２２は、クエリデータのその他の例を示す図である。同図には、検索要求として以下のことを要求するクエリデータ３が示されている。構造化文書ＤＢ「ＲＯＯＴ」の階層木の中に＜書籍＞という構造要素があり、この＜書籍＞という構造要素の中に＜タイトル＞という構造要素があり、この＜タイトル＞という構造要素の中に「ＸＭＬ」というテキスト要素が出現するか、又は、この＜書籍＞という構造要素の中に＜筆者＞という構造要素があり、この＜筆者＞という構造要素の中に「服部」というテキスト要素が出現する構造化文書データの＜書籍＞の一覧を返すことである。

図２３は、図２２に示したクエリデータ３に対してストリーム集合走査プラン生成部２５が生成する走査プランを示す図である。この走査プランは、索引ストリーム１に対する走査命令と、索引ストリーム２に対する走査命令と、データストリームに対する走査命令とを含み、索引ストリーム１に対する走査命令と索引ストリーム２に対する走査命令とが「ＯＲ」といった制御命令で接続されている。走査の手順としては、索引ストリーム１の走査と索引ストリーム２の走査とを行った後、データストリームを走査するという手順となる。「ＯＲ」は、上位段数の走査結果を受けて、走査範囲を絞り込むという制御命令を示している。上述の「ＦＩＬＴＥＲ」と異なるのは、複数の上位段数の走査結果を省略することができる点である。つまり、この走査プランによれば、索引ストリーム１を走査した結果を受けて、索引ストリーム２の走査をスキップすることもある。

次に、図２３に示した走査プランをサーバ１が実行する処理の概要について図２４を用いて説明する。この例ではストリーム集合走査プラン実行部２６は、索引ストリーム１に含まれる全てのブロックＩｎｄｅｘＢｌｏｃｋ［１］［ｉ］（ｉ＝０、１、２、．．．）を走査することになる。
(GS1”)まず、ストリーム集合走査プラン実行部２６は、走査対象の段として１段目である索引ストリーム１のＩｎｄｅｘＢｌｏｃｋ［１］［ｙ］を走査すると、走査範囲内における検索条件として「ＸＭＬ」というテキスト要素が存在するか否かを判定し、ここではこれが存在していると判定する（ステップＳ２１，Ｓ２３〜Ｓ２８）。
(GS2”)この場合、ストリーム集合走査プラン実行部２６は、次に走査対象となる２段目である索引ストリーム２のデータブロックＩｎｄｅｘＢｌｏｃｋ［２］［ｚ］の走査をスキップする（ステップＳ２２〜Ｓ２４，Ｓ３６）。
(GS3”)次いで、ストリーム集合走査プラン実行部２６は、走査対象の段として３段目であるデータストリームのＤａｔａＢｌｏｃｋ［ｘ］を走査して、結果データ、即ち、文書１のデータを得る（ステップＳ２２，Ｓ２３〜Ｓ２８）。

その後、詳細条件検査部２７が、（GS3”）で得られた結果データを詳細条件に基づいて検査して、最終的な結果データを生成してこれをＲＡＭ１０３に記憶させる（ステップＳ２２，Ｓ２３，Ｓ３７）。

(GS4”)そして、ストリーム集合走査プラン実行部２６は、走査対象の段として１段目である索引ストリーム１の走査に戻り、次のブロックＩｎｄｅｘＢｌｏｃｋ［１］［ｙ＋１］を走査すると、「ＸＭＬ」というテキスト要素が存在していないと判定する（ステップＳ２０〜Ｓ２１，Ｓ２３〜Ｓ２７，Ｓ２９）。
(GS5”)次いで、ストリーム集合走査プラン実行部２６は、走査対象の段として２段目である索引ストリーム２のＩｎｄｅｘＢｌｏｃｋＩｎｄｅｘＢｌｏｃｋ［２］［ｚ＋１］及びＩｎｄｅｘＢｌｏｃｋ［２］［ｚ＋２］を走査すると、走査範囲内における検索条件として「服部というテキスト要素が存在するか否かを判定し、ここではこれが存在していないと判定する（ステップＳ２０〜Ｓ２１，Ｓ２３〜Ｓ２７，Ｓ２９）。
(GS6”)この場合、ストリーム集合走査プラン実行部２６は、次に走査対象となる３段目であるデータストリームのデータブロックＤａｔａＢｌｏｃｋ［ｘ＋２］の走査をスキップする（ステップＳ２２〜Ｓ２４，Ｓ３６）。

(GS7”)そして、ストリーム集合走査プラン実行部２６は、走査対象の段として１段目である索引ストリーム１の走査に戻り、次のブロックＩｎｄｅｘＢｌｏｃｋ［１］［ｙ＋２］を走査すると、「ＸＭＬ」というテキスト要素が存在していると判定する（ステップＳＳ２０〜２１，Ｓ２３〜Ｓ２８）。
(GS8”)この場合、ストリーム集合走査プラン実行部２６は、走査対象の段として２段目である索引ストリーム２のＩｎｄｅｘＢｌｏｃｋ［２］［ｚ＋３］の走査をスキップする（ステップＳ２２〜Ｓ２４，Ｓ３６）。
(GS9”)次いで、ストリーム集合走査プラン実行部２６は、走査対象の段として３段目であるデータストリームのＤａｔａＢｌｏｃｋ［ｘ＋３］を走査して、結果データ、即ち、文書３のデータを得る（ステップＳ２２，Ｓ２３〜Ｓ２８）。

その後、詳細条件検査部２７が、（GS9”）で得られた結果データを詳細条件に基づいて検査して、最終的な結果データを生成してこれをＲＡＭ１０３に記憶させる（ステップＳ２２，Ｓ２３，Ｓ３７）。

(GS10”)その後、ストリーム集合走査プラン実行部２６は、走査対象の段として１段目である索引ストリーム１の走査に戻り、上述の処理を継続する。

以上のようにして、ストリーム集合走査プラン実行部２６は、図２３に示した走査プランについて、索引ストリーム１に対する走査命令に従って走査を実行した結果に応じて、制御命令によって当該走査命令に接続される、索引ストリーム２に対する走査命令に従った走査を実行しないことにより、索引ストリーム２に対する不要な走査をスキップする。また、ストリーム集合走査プラン実行部２６は、索引ストリーム１に対する走査命令及び索引ストリーム２に対する走査命令に従って走査が実行した結果に応じて、制御命令によって当該走査命令に接続される、データストリームに対する走査命令に従った走査を実行しないことにより、データストリームに対する不要な走査をスキップする。

以上のように、本実施の形態においては、構造化文書データ本体に相当するデータストリームと文書毎の索引となる索引ストリームとを相互に走査させながら、索引と文書本体との走査範囲を同時に絞り込む。この結果、不必要な走査をスキップすることができるので、構造化文書ＤＢへのアクセス回数を低減させ、効率的な走査を行うことができる。このため、検索の応答性を向上させることができる。

なお、本発明は前記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、前記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。また、以下に例示するような種々の変形が可能である。

上述の実施の形態においては、構造ガイドデータを用いてデータストリーム及び索引ストリームを生成する方法を例示したが、データストリーム及び索引ストリームを生成する方法は上述の例に限定されない。

また、上述の実施の形態においては、索引ストリームの数を２つとしたが、この数に限定されない。

一実施の形態にかかる構造化文書管理システムの構成を例示する図である。 同実施の形態にかかるサーバ１及びクライアント端末３のハードウェア構成を例示する図である。 同実施の形態にかかるサーバ１の機能的構成及びクライアント端末３の機能的構成を例示する図である。 同実施の形態にかかる構造化文書ＤＢ１３に格納される構造化文書データを例示する図である。 同実施の形態にかかる構造化文書ＤＢ１３に格納される構造化文書データを例示する図である。 同実施の形態にかかる構造化文書ＤＢ１３に格納される構造化文書データを例示する図である。 同実施の形態にかかる構造ガイドデータの一例を概念的に示す図である 同実施の形態にかかるデータストリームの一例を概念的に示す図である。 同実施の形態にかかる設定情報の一例を示す図である。 図４〜６に示される構造化文書データから変換されたデータストリーム及び索引ストリームを例示する図である。 同実施の形態にかかるＤａｔａＢｌｏｃｋ［ｘ］とＤａｔａＢｌｏｃｋ［ｘ＋１］を具体化した図である。 同実施の形態にかかるクエリデータの一例を示す図である。 同実施の形態にかかるサーバ１が走査プランを生成する処理の手順を示すフローチャートである。 図８に示したクエリデータ１から生成されたクエリグラフを示す模式図である。 図１４に示したクエリグラフを上述の観点から分解したサブグラフを例示する図である。 図１２に示したクエリデータ１に対してストリーム集合走査プラン生成部２５が生成する走査プランを示す図である。 同実施の形態にかかるサーバ１が走査プランを実行する処理の手順を示すフローチャートである。 図１６に示した走査プランをサーバ１が実行する処理イメージを示す図である。 同実施の形態にかかるクエリデータの他の例を示す図である。 図１９に示したクエリデータ２に対してストリーム集合走査プラン生成部２５が生成する走査プランを示す図である。 図２０に示した走査プランをサーバ１が実行する処理イメージを示す図である。 同実施の形態にかかるクエリデータのその他の例を示す図である。 図２２に示したクエリデータ３に対してストリーム集合走査プラン生成部２５が生成する走査プランを示す図である。 図２３に示した走査プランをサーバ１が実行する処理イメージを示す図である。

符号の説明

１ サーバ
２ ネットワーク
３ クライアント端末
１１ 格納処理部
１２ 検索処理部
１３ 構造化文書ＤＢ
１３ａ 構造ガイドデータ領域
１３ｂ データストリーム領域
１３ｃ 索引ストリーム領域
２０ 格納インターフェイス部
２１ ストリーム変換部
２２ データストリーム格納部
２３ 索引ストリーム格納部
２４ 検索インターフェイス部
２５ ストリーム集合走査プラン生成部
２６ ストリーム集合走査プラン実行部
２７ 詳細条件検査部
３０ 構造化文書登録部
３１ 構造化文書検索処理部
１０５ 媒体駆動装置
１０６ 通信制御装置
１０７ 表示部
１０８ 入力部
１０９ バスコントローラ
１１０ 記憶媒体

Claims (11)

1. 複数の要素が階層化されて各々含まれる複数の構造化文書データを記憶する構造化文書検索装置であって、
   前記複数の構造化文書データに各々含まれる各要素が構文解析の結果順に配列されたデータストリームを第１記憶領域に格納する第１格納手段と、
   前記複数の構造化文書データに各々含まれ且つ当該構造化文書データを検索する際の索引となる前記要素を構文解析の結果順に並べた少なくとも１つの索引ストリームを第２記憶領域に格納する第２格納手段と、
   前記構造化文書データを検索するための検索条件に基づいて、前記データストリーム及び前記索引ストリームに対する走査を命じる走査プランを生成する生成手段と、
   前記走査プランによって命じられた前記データストリーム及び前記索引ストリームのうち少なくとも一方に対する走査を実行する実行手段とを備え、
   前記生成手段は、前記検索条件に基づいて、文書単位で、前記データストリーム及び前記索引ストリームを含む複数のストリームのうち第１のストリームに対する走査を命じ、当該走査の結果に応じて第２のストリームに対する走査を命じる走査プランを生成し、
   前記第１格納手段は、固定長のデータブロック毎に配列された前記データストリームについて、前記構造化文書データ毎に先頭の前記データブロックの先頭に同期記号を埋め込んで、当該データストリームを前記第１記憶領域に格納し、
   前記実行手段は、前記同期記号が出現してから次の前記同期記号が出現するまでのデータブロックを前記文書単位として前記データストリームに対する走査を実行するものであり、前記走査プランによって命じられた前記第１のストリームに対する走査を文書単位で実行し、前記走査の結果に応じて、前記データストリームである前記第２のストリームについて前記同期記号が出現してから次の前記同期記号が出現するまでのデータブロックに対する走査をスキップする
   ことを特徴とする構造化文書検索装置。
2. 前記第２格納手段は、固定長のデータブロック毎に配列された前記索引ストリームについて、前記構造化文書データに対応するデータブロック毎にその先頭に同期記号を埋め込んで、当該索引ストリームを前記第１記憶領域に格納し、
   前記実行手段は、前記同期記号が出現してから次の前記同期記号が出現するまでのデータブロックを前記文書単位として前記索引ストリームに対する走査を実行するものであり、前記走査プランによって命じられた前記第１のストリームに対する走査を文書単位で実行し、前記走査の結果に応じて、前記索引ストリームである前記第２のストリームについて前記同期記号が出現してから次の前記同期記号が出現するまでのデータブロックに対する走査をスキップする
   ことを特徴とする請求項１に記載の構造化文書検索装置。
3. 前記検索条件を示す検索要求であるクエリデータをクライアント装置から取得する取得手段を更に備え、
   前記生成手段は、前記クエリデータを用いて、前記走査プランを生成する
   ことを特徴とする請求項１または２に記載の構造化文書検索装置。
4. 前記生成手段は、
   前記クエリデータを構文解析して前記検索条件をツリー形式で表したクエリグラフを生成するグラフ生成手段と、
   前記クエリグラフを複数のサブグラフに分解する分解手段と、
   各前記サブグラフに対して、前記データストリーム及び前記索引ストリームを含む複数のストリームのうち少なくとも１つのストリームを割り当てる割当手段と、
   前記サブグラフに対して割当られた各前記ストリームに対する走査を命じる走査命令と、前記サブクラフ間の論理関係に応じて各前記走査命令の手順を決定する制御命令であり、第１のストリームに対する走査命令に従った走査の結果に応じて第２のストリームに対する走査が実行されるように当該第２のストリームに対する前記走査命令を接続する制御命令とを含む走査プランを生成するプラン生成手段とを有する
   ことを特徴とする請求項３に記載の構造化文書検索装置。
5. 前記割当手段は、各前記ストリームのデータサイズ及び検索条件がストリームに設定されたときに検索条件を満足する要素の数の割合を示す選択率のうち少なくとも一方に基づいて、各前記サブグラフに対して、前記少なくとも１つのストリームを割り当てる
   ことを特徴とする請求項４に記載の構造化文書検索装置。
6. 前記実行手段は、前記走査プランに含まれる、前記第１のストリームに対する前記走査命令に従って走査を実行した後、前記走査の結果に応じて、前記制御命令によって当該走査命令に接続された、前記第２のストリームに対する前記走査命令に従った走査を実行しないことにより、当該第２のストリームに対する走査をスキップする
   ことを特徴とする請求項４又は５に記載の構造化文書検索装置。
7. 前記構造化文書データを構文解析し、当該構造化文書データの階層構造の要約を示す構造ガイドデータを用いて、当該構造化文書データに含まれる各要素を構文解析の結果順に配列したデータストリームを生成する第１生成手段を更に備える
   ことを特徴とする請求項１乃至６のいずれか一項に記載の構造化文書検索装置。
8. 前記構造化文書データを構文解析し、前記構造ガイドデータと、前記複数の要素のうち索引とする要素を指定する設定情報とを用いて、当該構造化文書データに含まれ前記設定情報によって指定された要素を構文解析の結果順に配列した索引ストリームを生成する第２生成手段を更に備える
   ことを特徴とする請求項１乃至７のいずれか一項に記載の構造化文書検索装置。
9. 前記実行結果に基づいて、前記検索要求に応じた検索結果を出力する出力手段を更に備える
   ことを特徴とする請求項１乃至８のいずれか一項に記載の構造化文書検索装置。
10. 第１格納手段と、第２格納手段と、生成手段と、実行手段とを備え、複数の要素が階層化されて各々含まれる複数の構造化文書データを記憶する構造化文書検索装置で実行される構造化文書検索方法であって、
    前記第１格納手段が、前記複数の構造化文書データに各々含まれる各要素が構文解析の結果順に配列されたデータストリームを第１記憶領域に格納する第１格納ステップと、
    前記第２格納手段が、前記複数の構造化文書データに各々含まれ且つ当該構造化文書データを検索する際の索引となる前記要素を構文解析の結果順に並べた少なくとも１つの索引ストリームを第２記憶領域に格納する第２格納ステップと、
    前記生成手段が、前記構造化文書データを検索するための検索条件に基づいて、前記データストリーム及び前記索引ストリームに対する走査を命じる走査プランを生成する生成ステップと、
    前記実行手段が、前記走査プランによって命じられた前記データストリーム及び前記索引ストリームのうち少なくとも一方に対する走査を実行する実行ステップとを含み、
    前記生成ステップは、前記検索条件に基づいて、文書単位で、前記データストリーム及び前記索引ストリームを含む複数のストリームのうち第１のストリームに対する走査を命じ、当該走査の結果に応じて第２のストリームに対する走査を命じる走査プランを生成し、
    前記第１格納ステップは、固定長のデータブロック毎に配列された前記データストリームについて、前記構造化文書データ毎に先頭の前記データブロックの先頭に同期記号を埋め込んで、当該データストリームを前記第１記憶領域に格納し、
    前記実行ステップは、前記同期記号が出現してから次の前記同期記号が出現するまでのデータブロックを前記文書単位として前記データストリームに対する走査を実行するものであり、前記走査プランによって命じられた前記第１のストリームに対する走査を文書単位で実行し、前記走査の結果に応じて、前記データストリームである前記第２のストリームについて前記同期記号が出現してから次の前記同期記号が出現するまでのデータブロックに対する走査をスキップする
    ことを特徴とする構造化文書検索方法。
11. 請求項１０に記載の方法をコンピュータに実行させることを特徴とするプログラム。

Images