JP2007226452A - 構造化文書管理装置、構造化文書管理プログラムおよび構造化文書管理方法 - Google Patents

Abstract

【課題】構造化文書データの格納効率を向上させる。
【解決手段】構造化文書データの入力を受け付ける文書データ受付手段２４と、構造化文書データの階層構造情報の要約である構造ガイドデータを記憶する構造ガイドデータ記憶手段２１ａと、受け付けた構造化文書データを構文解析し、構造ガイドデータを用いて構造情報を構造ストリームデータに変換する構造ストリーム変換手段２５と、構造ストリームデータを記憶する構造ストリームデータ記憶手段２１ｂと、を備える。これにより、構造化文書データの原文比でも１／２０程度に圧縮することができ、ディスクＩ／Ｏを大幅に低減することができるので、格納効率を向上させることができる。
【選択図】 図３

Description

本発明は、階層化された論理構造をもつ構造化文書データを記憶・検索する構造化文書管理装置、構造化文書管理プログラムおよび構造化文書管理方法に関する。

ＸＭＬ（Extensible Markup Language）などで記述された構造化文書データを記憶・検索するための構造化文書管理システムとしては、いくつかの方式が考えられている。

第１の方式としては、構造化文書データをそのままテキストファイルとして管理する方式がある。この第１の方式では、データ数やサイズが大きくなると格納効率が悪くなるという問題がある。また、この第１の方式では、構造化文書の特性を生かした検索が困難になるという問題がある。

第２の方式としては、ＲＤＢ（Relational Database）に構造化文書データを管理する方式がある。この第２の方式は、基幹系などで広く使われている。

第３の方式としては、構造化文書データを管理するために開発されたＯＯＤＢ（Object Oriented Database）で管理する方式がある。この第３の方式は、ＲＤＢを拡張した、例えばＸＭＬ対応ＲＤＢである。

ＲＤＢは、データをフラットなテーブル形式に格納するため、ＸＭＬデータのような階層構造をテーブルに対応付ける複雑なマッピングが必要となる。このマッピングのため、テーブルに関する事前の構造（スキーマ）設計を十分に行わないと、パフォーマンスが低下してしまう問題が発生する。

そこで、近年においては、上述した第１〜第３の方式に代わる第４の方式が提案されている。第４の方式は、ネイティブに構造化文書データを管理する方式である。この第４の方式は、多種多様な階層構造を持つＸＭＬデータを特別なマッピング処理すること無しに格納するため、格納や取得時に特別なオーバヘッドが存在しない。また、コストのかかる事前のスキーマ設計が不要になり、ビジネス環境の変化により必要に応じてＸＭＬデータの構造を自由に変更することが可能である。

ところで、構造化文書データが効率良く格納されたからといって、格納されたデータを取り出す手段が無ければ意味が無い。この格納されたデータを取り出す手段として、問合せ言語がある。ＲＤＢの世界ではＳＱＬ（Structured Query Language）があるように、ＸＭＬではＸＱｕｅｒｙ（XML Query Language）が策定されている。このＸＱｕｅｒｙは、ＸＭＬデータをデータベースのように扱うための言語であり、条件に合致するデータ集合の取り出しや集計・分析を行うための手段が提供されている。

また、ＸＭＬデータは親子や兄弟などの要素が組み合わさった階層構造を持つため、この階層構造を辿る手段が提供されている。このように格納された構造化文書データの階層構造を辿りながら、検索条件で指定された特定の要素と特定の構造が含まれている構造化文書データを検索するための技術は、例えば特許文献１や特許文献２において開示されている。

特開２００１−０３４６１８号公報 特開２００５−０５７１６３号公報

ところが、前述したように、ＸＭＬデータは親子や兄弟などの要素が組み合わさった階層構造を持つため、格納効率が悪いという問題がある。

さらに、構造化文書データの構造が大規模になる程、データベースに格納されている構造化文書データの数が多い程、あるいは、検索条件が複雑な程、各構造化文書データの階層構造を構成する要素間を辿るという処理には時間がかかる。また、構造化文書データの数、あるいはサイズが大きくなれば、格納された構造化文書データをメモリ上に展開することは不可能であり、多くはハードディスクなど二次記憶に格納されることになる。

特に、ネイティブに構造化文書データを管理する方式では、構造化文書データは要素間の階層構造をそのまま記憶することから、検索条件として指定された要素や構造があるか否かを調べるためには、二次記憶上に格納された構造化文書データの要素間を頻繁にアクセスしなければならない。複雑な検索条件の場合はなおさらである。

すなわち、特許文献１や特許文献２において開示されているような階層構造を辿る手段によれば、データベース内の各構造化文書データの階層構造を構成する要素データ間を辿りながら、検索条件にて指定された要素や構造を持つ構造化文書データを検索するため、高速に検索できないという問題点がある。特に、構造化文書データのサイズが大きくなる程、検索対象の構造化文書データの数が多い程、あるいは、クエリデータ（検索条件）が複雑である程、検索処理の高速化が困難である。より具体的には、下記の通りである。
（１）複雑なＸＱｕｅｒｙの場合、複数のパスパターンがクエリに含まれる。複数のパスパターンへの照合を行うのに、同一構造化文書へのトラバースが繰り返し発生する。特にオンメモリにできないサイズを取り扱うケースでは、同一ページへのディスクＩ／Ｏが断続発生し、性能劣化が激しくなる。
（２）ＸＱｕｅｒｙのサブセットであるＸＰａｔｈの場合でも、高ヒット時には性能劣化が発生する。つまり、構造化文書の集合の大半をトラバースするケースでは、大量のディスクＩ／Ｏが発生してしまう。

また、同一の構造化文書データへのデータスキャンを抑えるアイデアとして、構造化文書ストリーム処理の技術がある。例えば、以下の参考文献が挙げられる。
（参考文献１）Y. Diao, P.Fischer, and M.J.Franklin. YFilter: Efficient and Scalable Filtering of XML Documents. In The 18th International Conference of Data Engineering, San Jose, February 2002.
（参考文献２）I. Avila-Campillo, D. Raven, T. Green, A. Gupta, Y. Kadiyska, M.Onizuka, and D. Suciu. An XML Toolkit for Light-weight XML Stream Processing,2002.

これは構造化文書データ全部を主記憶に記憶しないでＸＰａｔｈなどの問合わせを処理するものである。複数のＸＰａｔｈに現れる複数のパスパターンを状態遷移に変換して処理する方式も提案されている。しかし、現実には以下のような問題が発生してしまう。
（３）高ヒットでないＸＰａｔｈでは性能劣化が著しい。バックトラックベースであるため、ＣＰＵ処理上のオーバヘッドも大きい。処理の特性上、索引を使った問合わせ処理が難しい。

上述したように、構造化文書データを格納したデータベースに対して、複数のパスパターンを最小のディスクＩ／Ｏと少ない計算量で処理するのは困難であると言える。

本発明は、上記に鑑みてなされたものであって、構造化文書データの格納効率を向上させることを目的とする。

また、本発明は、クエリデータによる検索処理を高速化することを目的とする。

上述した課題を解決し、目的を達成するために、本発明の構造化文書管理装置は、階層化された論理構造を有している構造化文書データの入力を受け付ける文書データ受付手段と、前記構造化文書データの階層構造情報の要約である構造ガイドデータを記憶する構造ガイドデータ記憶手段と、前記文書データ受付手段により受け付けた前記構造化文書データを構文解析し、前記構造ガイドデータを用いて前記構造化文書データ中にある構造情報を１次元の配列データである構造ストリームデータに変換する構造ストリーム変換手段と、この構造ストリーム変換手段により変換された前記構造ストリームデータを記憶する構造ストリームデータ記憶手段と、を備える。

また、本発明の構造化文書管理プログラムは、階層化された論理構造を有している構造化文書データの入力を受け付ける文書データ受付機能と、前記文書データ受付機能により受け付けた前記構造化文書データを構文解析し、前記構造化文書データの階層構造情報の要約である構造ガイドデータを用いて前記構造化文書データ中にある構造情報を１次元の配列データである構造ストリームデータに変換する構造ストリーム変換機能と、この構造ストリーム変換機能により変換された前記構造ストリームデータを構造ストリームデータ記憶手段に記憶する機能と、をコンピュータに実行させる。

また、本発明の構造化文書管理方法は、階層化された論理構造を有している構造化文書データの入力を受け付ける文書データ受付工程と、前記文書データ受付工程により受け付けた前記構造化文書データを構文解析し、前記構造化文書データの階層構造情報の要約である構造ガイドデータを用いて前記構造化文書データ中にある構造情報を１次元の配列データである構造ストリームデータに変換する構造ストリーム変換工程と、この構造ストリーム変換工程により変換された前記構造ストリームデータを構造ストリームデータ記憶手段に記憶する工程と、を含む。

本発明によれば、構造化文書データを構文解析し、構造ガイドデータを用いて構造化文書データ中にある構造情報を１次元の配列データである構造ストリームデータに変換して記憶することにより、構造化文書データの原文比でも１／２０程度に圧縮することができ、ディスクＩ／Ｏを大幅に低減することができるので、格納効率を向上させることができるという効果を奏する。

また、本発明によれば、バックトラックでなく決定的な基本動作の繰返しであり、ＣＰＵ処理上のオーバヘッドが小さいことから、結果として、高速化が困難であった複雑なＸＱｕｅｒｙや複数のＸＰａｔｈなどのクエリデータによる検索処理を飛躍的に高速化することができるという効果を奏する。

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

［第１の実施の形態］
本発明の第１の実施の形態を図１ないし図１６に基づいて説明する。

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

図２は、サーバ１およびクライアント端末３のモジュール構成図である。サーバ１およびクライアント端末３は、例えば、一般的なパーソナルコンピュータである。

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

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

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

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

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

サーバ１は、ＯＳ上で動作する構造化文書管理プログラムが起動すると、この構造化文書管理プログラムに従い、ＣＰＵ１０１が各種の演算処理を実行して各部を集中的に制御する。一方、クライアント端末３は、ＯＳ上で動作する構造化文書入出力プログラムが起動すると、この構造化文書入出力プログラムに従い、ＣＰＵ１０１が各種の演算処理を実行して各部を集中的に制御する。サーバ１およびクライアント端末３のＣＰＵ１０１が実行する各種の演算処理のうち、本実施の形態の特長的な処理について以下に説明する。

図３は、サーバ１およびクライアント端末３の概略構成を示すブロック図である。図３に示すように、クライアント端末３は、構造化文書入出力プログラムに従うことにより、構造化文書登録部１１と、検索部１２とを備える。

構造化文書登録部１１は、入力部１０８から入力された構造化文書データやクライアント端末３のＨＤＤ１０４に予め記憶された構造化文書データを、後述するサーバ１の構造化文書データベース（構造化文書ＤＢ）２１に登録するためのものである。この構造化文書登録部１１は、登録すべき構造化文書データとともに格納要求をサーバ１に送信する。

ここで、図４は構造化文書データの一例を示したものである。構造化文書データを記述するための代表的な言語としてＸＭＬ（eXtensible Markup Language）が挙げられる。図４に示す構造化文書データは、ＸＭＬで記述されたものである。ＸＭＬでは、文書構造を構成する個々のパーツを「要素」（エレメント：Element）と呼び、要素はタグ（tag）を使って記述する。具体的には、要素の始まりを示すタグ（開始タグ）と、終わりを示すタグ（終了タグ）の２つのタグでデータを挟み込んで、１つの要素を表現している。なお、開始タグと終了タグで挟み込まれたテキストデータは、当該開始タグと終了タグで表された１つの要素に含まれるテキスト要素である。

図４に示す例では、＜ｂｏｏｋｓ＞というタグで囲まれた要素のルート要素が存在する。この「ｂｏｏｋｓ」要素は、＜ｂｏｏｋ＞のタグで囲まれた２つの子要素を包含する。＜ｂｏｏｋ＞は、＜ｔｉｔｌｅ＞、＜ａｕｔｈｏｒ＞の各タグで囲まれた複数の子要素を包含する。＜ｔｉｔｌｅ＞要素は、「ＸＭＬデータベース」というテキスト要素をもつ。１番目の＜ｂｏｏｋ＞は、２つの＜ａｕｔｈｏｒ＞要素を持ち、２番目の＜ｂｏｏｋ＞は１つの＜ａｕｔｈｏｒ＞要素を持つ。＜ｔｉｔｌｅ＞と＜ａｕｔｈｏｒ＞の順序であるが、１番目の＜ｂｏｏｋ＞では＜ｔｉｔｌｅ＞が先に出現し、２番目の＜ｂｏｏｋ＞では＜ａｕｔｈｏｒ＞が先に出現している。

なお、図４に示すように、テキスト要素を含めた各要素には、Ｅｉ（ｉ＝１〜２０）という要素ＩＤを使って各要素を参照することにする。

検索部１２は、ユーザにより入力部１０８から入力された指示に従って、構造化文書ＤＢ２１から所望のデータを検索するための検索条件などが記述されたクエリデータを作成し、当該クエリデータを含む検索要求をサーバ１へ送信する。また、検索部１２は、サーバ１から送信された当該検索要求に対応する結果データを受け取り、これを表示部１０７に表示する。

一方、サーバ１は、構造化文書管理プログラムに従うことにより、構造化文書ＤＢ２１と、格納処理部２２と、検索処理部２３とを備える。

格納処理部２２は、クライアント端末３からの格納要求を受けて、クライアント端末３から送信された構造化文書データを構造化文書ＤＢ２１に格納する処理を行う。この格納処理部２２は、格納インタフェース部２４と、構造ストリーム変換部２５とから構成されている。

格納インタフェース部２４は、構造化文書データの入力を受け付け（文書データ受付手段）、構造化文書データを格納するために構造ストリーム変換部２５を呼び出す。

構造ストリーム変換部２５は、構造ストリーム変換手段として機能するものであって、クライアント端末３から送信された構造化文書データを構文解析し、構造化文書ＤＢ２１の構造ガイドデータ記憶手段である構造ガイドデータ領域２１ａ内の構造ガイドデータを参照および更新することで、構造化文書データ中にある階層構造情報を構造ストリームデータに変換して構造化文書ＤＢ２１の構造ストリームデータ記憶手段である構造ストリームデータ領域２１ｂに格納する。また、構造ストリーム変換部２５は、構造化文書データ中にあるテキスト情報を、別途テキストデータに変換して構造化文書ＤＢ２１のテキストデータ領域２１ｃに格納する。

ここで、構造ガイドデータは、システムに格納された構造化文書データ集合の全体に渡る階層構造情報の要約である。構造ガイドデータは、階層構造をなしており、以下の条件を保持している。
（１）システムに格納された構造化文書データ集合に現れる全てのパスは、構造ガイドデータに現れる。
（２）構造ガイドデータに現れる全てのパスは、システムに格納された構造化文書データ集合に現れる。
（３）構造ガイドデータに現れるパスは全て一意的である。

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

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

図６は、構造ストリームデータの一例を示す説明図である。この構造ストリームデータの例は、図５に示した構造ガイドデータを使って図４の構造化文書データを配列データに変換したものである。各配列要素は、ＧＩＤを使って数値化されている。
Ｅ０ 「ＲＯＯＴ」に対応する配列要素 （Ｇ）０
Ｅ１ 「ｂｏｏｋｓ」に対応する配列要素 （Ｇ）１
Ｅ２ 「ｂｏｏｋ」に対応する配列要素 （Ｇ）２
・・・ ・・・ ・・・
・・・ ・・・ ・・・
このように配列データ、つまり構造ストリームに変換することで、２次元的な構造的なデータを１次元の配列データとして扱えるようになる。

ここで、図７に示すフローチャートを参照して、構造ストリーム変換部２５の構造ガイドデータの更新処理動作について説明する。

クライアント端末３からは、新たに格納すべき構造化文書データと、この構造化文書データの格納先のフォルダのＧＩＤを含む格納要求メッセージが送信される。

なお、クライアント端末３では、格納先のフォルダのＧＩＤは、次のようにして得ることができる。クライアント端末３の検索部１２は、構造化文書ＤＢ２１の概略構造（図５参照）を表示するためのＧＵＩ（Graphic User Interface）を有しており、このＧＵＩにより表示された構造からユーザが格納先のフォルダとして所望のガイドノード（フォルダ）を指示すると、当該ガイドノードに対応するＧＩＤを得るための問合せデータが作成され、サーバ１へ送信される。サーバ１では、当該問合せデータから、当該指示されたガイドノードのＧＩＤを獲得して、クライアント端末３の検索部１２へ返す。検索部１２は、この得られたＧＩＤを構造化文書登録部１１へ渡す。

さて、サーバ１は、新たなに格納すべき構造化文書データと格納先のフォルダのＧＩＤｐを含む格納要求メッセージを受け取る（ステップＳ１０１）。

格納要求メッセージに含まれる、格納すべき構造化文書データは、格納処理部２２の構造ストリーム変換部２５へ渡されて、当該構造化文書データの構文解析が行われる。この結果得られるものは、構造化文書データの複数のオブジェクトデータからなる階層構造であり、メモリ上に展開される（ステップＳ１０２）。すなわち、構造ストリーム変換部２５は、ＸＭＬデータである構造化文書データに対し、構文解析処理を行うことによりＤＯＭ（Document Object Model）形式のオブジェクトデータに展開するＸＭＬパーサに相当する機能を有するものである。

次に、構造ストリーム変換部２５は、解析結果をそのルートから辿ることによって、当該構造化文書データの構造、すなわち、当該構造化文書データ中の各要素に対応する複数のノードと、当該複数のノードからなる構造を抽出する。当該構造化文書データの構造をＳｃとする（ステップＳ１０３）。

そして、構造ストリーム変換部２５は、格納先フォルダのＧＩＤをキーに構造ガイドデータ領域２１ａから構造を取得する。取得したＧＩＤをＧＩＤｐと表す。構造ストリーム変換部２５は、ＧＩＤｐをキーにして構造ガイドデータ領域２１ａをスキャンすることで、対応する構造を取得する（ステップＳ１０４）。取得した構造をＳｐとする（ステップＳ１０５）。

その後、構造ストリーム変換部２５は、ＳｃとＳｐの照合を行う（ステップＳ１０６）。これはツリーの単純なマッチングである。すなわち、Ｓｃの構造要素に対応するＳｐの構造要素があれば、当該Ｓｃの構造要素に当該Ｓｐの構成要素のＧＩＤを付与する。Ｓｃの構造要素に対応するＳｐの構造要素がなければ、Ｓｐに存在せずに、Ｓｃに存在する新たな要素に新たなＧＩＤを付与し、Ｓｐに当該新たな要素を追加する。また、Ｓｃの当該新たな要素に当該新たなＧＩＤを付与する。この操作をＳｃの全ての構造要素に対し行う。

さらに、構造ストリーム変換部２５は、更新されたＳｐを構造ガイドデータ領域２１ａに格納する（ステップＳ１０７）。これにより、構造ガイドデータ領域２１ａに格納される構造ガイドデータの更新がなされる。

最後に、格納すべき構造化文書データの各要素にＧＩＤを付与する（ステップＳ１０８）。すなわち、格納すべき構造化文書データの各要素にＧＩＤを付与するタイミングは、構造ガイドデータ領域を更新した後である。

検索処理部２３は、クライアント端末３からの検索要求を受けて、指定された条件（クエリデータ）に合致するデータを構造化文書ＤＢ２１から探し出し、この探し出したデータを結果データとして返す処理を行う。この検索処理部２３は、検索インタフェース部２６と、パスパターンコンパイル部２７と、構造ストリーム走査部２８とから構成されている。

検索インタフェース部２６は、クエリデータの入力を受け付けて（クエリデータ受付手段）、受け付けたクエリデータを満足する結果データを得るためにパスパターンコンパイル部２７と構造ストリーム走査部２８を呼び出す。

パスパターンコンパイル部２７は、パスパターンコンパイル手段として機能するものであって、クライアント端末３から送信されたクエリデータ集合を構文解析し、構造化文書ＤＢ２１の構造ガイドデータ領域２１ａ内の構造ガイドデータを参照することでクエリデータに特化した処理手順を指定するパスパターン処理テーブル２９を生成する。

図８は、クエリデータの一例を示す説明図である。ＸＭＬでは、Ｗ３Ｃで提案されているＸＱｕｅｒｙ（XML Query Language）という問合せ言語があり、これに基づいた問合せ記述方法に則っている。図８には、下記に示すようなクエリデータＱ１が示されている。
Ｑ１：構造化文書ＤＢ「ＲＯＯＴ」の階層木の中に「ｂｏｏｋ」という要素があり、この「ｂｏｏｋ」という要素の中に、「ａｕｔｈｏｒ」という要素があり、この「ａｕｔｈｏｒ」という要素の中に、「ｆｉｒｓｔ」という要素がある構造化文書データの「ｂｏｏｋ」の一覧を返す。

ここで、パスパターンコンパイル部２７におけるパスパターンコンパイル処理について図９のフローチャートを参照して説明する。

まず、クライアント端末３から送信されたクエリデータから第１次構造グラフを生成する（ステップＳ１）。より詳細には、ＸＱｕｅｒｙで記述されたクエリデータを構文解析し、タグとタグ間の関連をツリー形式で表現する。図８に示したクエリデータＱ１について考えると、図１０に示すような第１次構造グラフが生成される。「ＲＯＯＴ」を起点として、「ｂｏｏｋ」との「//（Descendant-or-Self）」という関係で結ばれている。「ｂｏｏｋ」は、「ａｕｔｈｏｒ」と「ｃｈｉｌｄ」という関係で結ばれている。また、図８に示したＱ１では、構造化文書データの「ｂｏｏｋ」の一覧を返すので、「ｂｏｏｋ」は出力ノードの印（二重線）が付いている。

次いで、ステップＳ１で生成した第１次構造グラフと構造ガイドデータとを照合し、第２次構造グラフを生成する（ステップＳ２）。より詳細には、第１次構造グラフと構造ガイドデータとを照合し、ＧＩＤに変換して不要なノードを取り除いたものとして第２次構造グラフを生成する。ここで、図１０に示した第１次構造グラフについて考える。第１次構造グラフの各ノードが対応するＧＩＤを算出すると、下記に示すようになる。
「ＲＯＯＴ」 → （Ｇ）０
「ｂｏｏｋ」 → （Ｇ）２
「ａｕｔｈｏｒ」 → （Ｇ）５
「ｆｉｒｓｔ」 → （Ｇ）６
さらに、以下のルールで不要なノードを取り除く。
（１）出力ノード以外で中間ノードにあたり、ＡＮＤ条件がついていないもの Ｇ５
（２）ルートノードにあたるもの Ｇ０
その結果、図１１に示すような第２次構造グラフが生成される。

最後に、ステップＳ２で生成した第２次構造グラフからパスパターン処理テーブル２９を生成する（ステップＳ３）。

図１２は、図８に示すクエリデータＱ１に対するパスパターン処理テーブル２９の一例を示す説明図である。このようなパスパターン処理テーブル２９は、以下の要素から構成される。
（１）エントリーテーブル
ＧＩＤに対応した配列要素を持つテーブル。構造ストリーム走査部２８における構造ストリーム走査処理にて、構造ストリームデータの先頭要素から順にＧＩＤを読み込んでいく。読み込んだＧＩＤの位置はＥＩＤで示される。読み込んだＧＩＤに対応した手続きを実行する。手続きは、以下の２つである。
（１．１）PList
Placeに対してＥＩＤ（Token（トークン）と呼ぶ）を追加（プッシュ）する。
（１．２）CList
Placeに対してクリアする。
（２）Place（プレース）
中間データであるTokenのキューを保持する記憶領域の役割を持つ。
（３）Trans（トランス）
PlaceとPlaceを接続し、上位Placeに保持されたTokenを下位Placeに流す（フロー）役割を持つ。TransにはAND、CMBなどのより詳しい役割が与えられる。AND、CMBに関する説明は以下の通りである。
（３．１）AND
上位のPlace集合の全てにTokenが存在すれば、下位のPlaceにToken（True）を流す。
（３．２）CMB
上位のPlace集合の全てにTokenが存在すれば、そのTokenの組み合わせを流す（出力する）。

図１３は、パスパターン処理テーブル２９の生成処理（図９のステップＳ３）の流れを示すフローチャートである。

まず、Place_rを新規作成し（ステップＳ１１）、処理テーブル該当要素からPlace_rにPlistを張り（ステップＳ１２）、親ノードが有るか否かを判定する（ステップＳ１３）。親ノードが有ると判定した場合には（ステップＳ１３のＹｅｓ）、ステップＳ１４に進み、親ノードの処理テーブル該当要素からCListを張る。一方、親ノードが無いと判定した場合には（ステップＳ１３のＮｏ）、ステップＳ１５に進み、自ノードの処理テーブル該当要素からCListを張る。

その後、末端ノードであるか否かを判定する（ステップＳ１６）。末端ノードであれば（ステップＳ１６のＹｅｓ）、呼び出し元に戻る。

一方、末端ノードでなければ（ステップＳ１６のＮｏ）、ステップＳ１７に進み、ＡＮＤ条件であるか否かを判定する。ＡＮＤ条件であると判定した場合には（ステップＳ１７のＹｅｓ）、Trans（AND）を作り（ステップＳ１８）、Trans（AND）からPlace_rへのリンクを張る（ステップＳ１９）。次いで、各子ノードに対して処理テーブル生成し（ステップＳ２１）、返値Place_nからTrans（AND）へのリンクを張る（ステップＳ２２）。ステップＳ２１〜Ｓ２２の処理は、各子ノードを処理するまで（ステップＳ２０のＹｅｓ）、繰り返される。各子ノードを処理したと判定した場合には（ステップＳ２０のＹｅｓ）、ステップＳ２３に進み、Place_rを返す。

ＡＮＤ条件でないと判定した場合には（ステップＳ１７のＮｏ）、Trans（CMB）を作り（ステップＳ２４）、Trans（CMB）からPlace_rへのリンクを張る（ステップＳ２５）。次いで、子ノードに対して処理テーブル生成し（ステップＳ２６）、返値Place_nからTrans（CMB）へのリンクを張った後（ステップＳ２７）、ステップＳ２３に進み、Place_rを返す。

上述したように、パスパターン処理テーブル２９は、第２次構造グラフのルートノードから再帰的に処理することで生成される。

構造ストリーム走査部２８は、構造ストリーム走査手段として機能するものであって、構造化文書ＤＢ２１の構造ストリームデータ領域２１ｂから構造ストリームデータ集合を取得し、パスパターン処理テーブル２９と突き合わせることで、結果データを生成する。

ここで、構造ストリーム走査部２８における構造ストリームの走査処理について、図１４及び図１５のフローチャートを参照して説明する。図１４に示すように、まず、構造ストリームの要素を順に取り出して（ステップＳ２０１）、全ての要素を取り出したと判断するまで（ステップＳ２０２のＹｅｓ）、以下に示す処理（ステップＳ２０３〜Ｓ２０７）を繰り返す。全ての要素を取り出したと判断すると（ステップＳ２０２のＹｅｓ）、構造ストリームの走査処理を終了する。

全ての要素を取り出したと判断しなかった場合には（ステップＳ２０２のＮｏ）、構造ストリームの要素に対応するエントリテーブル要素を参照し（ステップＳ２０３）、CListがあれば（ステップＳ２０４のＹｅｓ）、CListに接続するPlaceをクリアする（ステップＳ２０５）。つまり、内部に保持するキューを空にする。

一方、PListがあれば（ステップＳ２０４のＮｏ，ステップＳ２０６のＹｅｓ）、PListに接続するPlaceにTokenをプッシュする（ステップＳ２０７）。

ステップＳ２０７における処理について図１５を参照して詳述する。PlaceへのTokenプッシュは、まず、Placeで保持するキューにTokenをプッシュする（ステップＳ３０１）。その後、Placeの先にあるTransを順に取り出し（ステップＳ３０２）、全てのPlaceを取り出したと判断するまで（ステップＳ３０３のＹｅｓ）、以下に示す処理（ステップＳ３０４〜Ｓ３０９）を繰り返す。全ての要素を取り出したと判断すると（ステップＳ３０３のＹｅｓ）、PlaceへのTokenプッシュ処理を終了する。

全てのPlaceを取り出したと判断しなかった場合には（ステップＳ３０３のＮｏ）、TransがANDタイプであれば（ステップＳ３０４のＹｅｓ）、上位のPlace集合の全てにTokenが存在するか否かをチェックする（ステップＳ３０５）。

上位のPlace集合の全てにTokenが存在すると判断した場合には（ステップＳ３０５のＹｅｓ）、下位のPlaceにToken（True）をプッシュし（ステップＳ３０６）、ステップＳ３０２に戻る。

一方、TransがCMBタイプであれば（ステップＳ３０４のＮｏ，ステップＳ３０７のＹｅｓ）、上位のPlace集合の全てにTokenが存在するか否かをチェックする（ステップＳ３０８）。

上位のPlace集合の全てにTokenが存在すると判断した場合には（ステップＳ３０８のＹｅｓ）、そのTokenの組み合わせを出力する（ステップＳ３０９）。一方、上位のPlace集合の全てにTokenが存在しないと判断した場合には（ステップＳ３０８のＹｅｓ）、ステップＳ３０２に戻る。

なお、TransがANDタイプでもCMBタイプでもない場合には（ステップＳ３０４のＮｏ，ステップＳ３０７のＮｏ）、エラー処理を行う。

図１６は、図１２で示したパスパターン処理テーブル２９に対して図６で示した構造ストリームデータを与えたときの進行図表である。
Ｅ０［Ｇ０］を走査した時、
PList、CListが存在しないので、何もしない。
Ｅ１［Ｇ１］を走査した時、
PList、CListが存在しないので、何もしない。
Ｅ２［Ｇ２］を走査した時、
PList、CListが存在する。Place0、Place1をクリアし、Place0にToken 2をプッシュする。Place1が空なので、Trans0は何も出力しない。
・・・
・・・
Ｅ６［Ｇ６］を走査した時、
PListが存在する。Place1に６をプッシュする。Place0、Place1にTokenが入っているので、Trans0は出力ノードに当たるPlace0のToken 2を出力する。
・・・
・・・
Ｅ１３［Ｇ２］を走査した時、
PList、CListが存在する。Place0、Place1をクリアし、Place0にToken 13をプッシュする。Place1が空なので、Trans0は何も出力しない。
・・・
Ｅ１５［Ｇ６］を走査した時、
ＰＬｉｓｔが存在する。Place1に１５をプッシュする。Place0、Place1にTokenが入っているので、Trans0は出力ノードに当たるPlace0のToken 13を出力する。
・・・
上述したような処理により、２，１３のTokenが出力されることになる。２は図４におけるＥ２に相当し、１３は図４におけるＥ１３に相当する。２，１３のTokenは、検索インタフェース部２６にて構造化文書ＤＢ２１のテキストデータ領域２１ｃに記憶されているテキストデータを取得し、構造化文書データとして文字列化され、結果データとしてクライアント端末３に出力される。

このように本実施の形態によれば、構造化文書データを構文解析し、構造ガイドデータを用いて構造化文書データ中にある構造情報を１次元の配列データである構造ストリームデータに変換して記憶することにより、構造化文書データの原文比でも１／２０程度に圧縮することができ、ディスクＩ／Ｏを大幅に低減することができるので、格納効率を向上させることができる。

また、本実施の形態によれば、バックトラックでなく、決定的な基本動作の繰返しであり、ＣＰＵ処理上のオーバヘッドが小さいことから、結果として、高速化が困難であった複雑なＸＱｕｅｒｙや複数のＸＰａｔｈなどのクエリデータによる検索処理を飛躍的に高速化することができる。

［第２の実施の形態］
次に、本発明の第２の実施の形態を図１７ないし図２１に基づいて説明する。なお、前述した第１の実施の形態と同じ部分は同じ符号で示し説明も省略する。本実施の形態においては、第１の実施の形態とはクエリデータの種類が異なっている。

図１７は、本実施の形態のクエリデータＱ２の一例を示す説明図である。図１７には、下記に示すようなクエリデータＱ２が示されている。
Ｑ２：構造化文書ＤＢ「ＲＯＯＴ」の階層木の中に「ｂｏｏｋ」という要素があり、この「ｂｏｏｋ」という要素の中に、「ａｕｔｈｏｒ」という要素があり、この「ａｕｔｈｏｒ」という要素の中に、「ｆｉｒｓｔ」と「ｌａｓｔ」という２つの要素がある構造化文書データの「ｂｏｏｋ」の一覧を返す。

ここで、図１８は図１７のクエリデータＱ２に対する第１次構造グラフを示す模式図、図１９は図１８の第１次構造グラフに基づく第２次構造グラフを示す模式図である。

図１８に示すように、クエリデータＱ２に対する第１次構造グラフは、「ａｕｔｈｏｒ」の下に「ｆｉｒｓｔ」と「ｌａｓｔ」の２つの要素を持つという条件が付いているので、ＡＮＤ条件がリンクに付加されている。そして、不要なノードを取り除くと、図１９に示すような第２次構造グラフが生成される。

図２０は、図１７に示すクエリデータＱ２に対するパスパターン処理テーブル２９の一例を示す説明図である。図１２に示したクエリデータＱ１に対するパスパターン処理テーブル２９の一例との違いは、Trans（AND）が追加されていることである。

図２１は、図２０で示したパスパターン処理テーブル２９に対して図６で示した構造ストリームデータを与えたときの進行図表である。
Ｅ０［Ｇ０］を走査した時、
PList、CListが存在しないので、何もしない。
Ｅ１［Ｇ１］を走査した時、
PList、CListが存在しないので、何もしない。
Ｅ２［Ｇ２］を走査した時、
PList、CListが存在する。Place0、Place3をクリアし、Place0にToken 2をプッシュする。Place1が空なので、Trans1は何も出力しない。
・・・
・・・
Ｅ５［Ｇ５］を走査した時、
CListが存在する。Place1、Place2をクリアする。
Ｅ６［Ｇ６］を走査した時、
PListが存在する。Place1にToken 6をプッシュする。Place2が空なので、Trans0は何も出力しない。
・・・
Ｅ８［Ｇ５］を走査した時、
PList、CListが存在する。Place1、Place2をクリアする。
Ｅ９［Ｇ８］を走査した時、
PListが存在する。Place2にToken 9をプッシュする。Place1が空なので、Trans0は何も出力しない。
・・・
・・・
Ｅ１４［Ｇ５］を走査した時、
PList、CListが存在する。Place1、Place2をクリアする。
Ｅ１５［Ｇ６］を走査した時、
PListが存在する。Place1にToken 15をプッシュする。Place2が空なので、Trans0は何も出力しない。
・・・
Ｅ１７［Ｇ８］を走査した時、
PListが存在する。Place2にToken 17をプッシュする。Place1、Place2にTokenが入っているので、Trans0はToken TrueをPlace3にプッシュする。Place0、Place3にTokenが入っているので、Trans1は出力ノードに当たるPlace0のToken 13を出力する。
・・・
上述したような処理により、１３のTokenが出力されることになる。１３は図４におけるＥ１３に相当する。１３のTokenは、検索インタフェース部２６にて構造化文書ＤＢ２１のテキストデータ領域２１ｃに記憶されているテキストデータを取得し、構造化文書データとして文字列化され、結果データとしてクライアント端末３に出力される。

第１の実施の形態の図１６と比較し、同じ構造ストリームデータであっても、パスパターン処理テーブルが異なれば、異なる結果データが得られることになる。

［第３の実施の形態］
次に、本発明の第３の実施の形態を図２２に基づいて説明する。なお、前述した第１の実施の形態または第２の実施の形態と同じ部分は同じ符号で示し説明も省略する。本実施の形態は、第１の実施の形態のクエリデータＱ１と第２の実施の形態のクエリデータＱ２とを同時に処理するようにしたものである。

図２２は、クエリデータＱ１、Ｑ２を同時に処理するパスパターン処理テーブル２９の一例を示す説明図である。これは、図１２に示したパスパターン処理テーブル２９と図２０に示したパスパターン処理テーブル２９とを合成することで得られる。図２２で示したパスパターン処理テーブル２９に対して図６で示した構造ストリームデータを与えたときには、下記に示すような出力が得られる。
（１）Trans0_1からは、２、１３のTokenが出力されることになる。
（２）Trans1からは、１３のTokenが出力されることになる。

このように本実施の形態によれば、単純なＸＰａｔｈだけでなく、複雑なＸＱｕｅｒｙでも、１回の構造ストリームデータの走査で複数の結果データを同時出力することができる。さらに、複数のＸＱｕｅｒｙを受け付けた場合、１回の構造ストリームデータの走査で複数の結果データを同時出力することができる。

［第４の実施の形態］
次に、本発明の第４の実施の形態を図２３および図２４に基づいて説明する。なお、前述した第１の実施の形態ないし第３の実施の形態と同じ部分は同じ符号で示し説明も省略する。

本実施の形態においては、構造化文書データが事前の構造情報を伴っている場合、すなわち構造化文書データの構造情報が事前に明確に定義されている場合、パスパターンコンパイル部２７が、構造ストリームデータの走査をスキップする処理手順を埋め込むようにした点で、第１の実施の形態ないし第３の実施の形態とは異なるものである。

図２３は、事前の構造情報を伴う１つの構造化文書データの一例を示す説明図である。図２３に示すように、取り扱う構造化文書データについて、文書構造を事前に定義することができる。この定義を可能にするのがスキーマ言語であり、ＸＭＬでは基本的なものとしてＤＴＤ（Data Type Definition）がある。ＤＴＤは、要素宣言、属性宣言、実体宣言、などの宣言集合から構成される。図２３では、「ｂｏｏｋｓ」、「ｂｏｏｋ」、「ｉｎｆｏ」、「ｉｓｂｎ」、「ｉｓｓｕｅＤａｔｅ」、「ｙｅａｒ」、「ｍｏｎｔｈ」、「ｄａｙ」といった要素宣言を行っている。
「ｂｏｏｋｓ」 複数の「ｂｏｏｋ」と１つの「ｉｎｆｏ」から構成される。＋は１個以上の繰り返しを許容することを意味する。
「ｉｎｆｏ」 「ｉｓｂｎ」と「ｉｓｓｕＤａｔｅ」から構成される。
「ｉｓｓｕｅＤａｔｅ」 「ｙｅａｒ」、「ｍｏｎｔｈ」、「ｄａｙ」から構成される。

新たな構造化文書データを格納するときに、事前に与えられたＤＴＤとの妥当性チェックが行われ、ＤＴＤに合致しなければ妥当性エラーとして格納しないことになる。

このように構造化文書ＤＢ２１のテキストデータ領域２１ｃにあるテキストデータにＤＴＤ（構造情報）が事前定義されている場合、パスパターンコンパイル部２７では構造ストリームデータの一部をスキップする手続きをパスパターン処理テーブル２９に埋め込んで、構造ストリーム走査部２８における走査処理を高速化することができる。

図２３の構造化文書データに対して図８に示したクエリデータＱ１を処理する例を以下に示す。クエリデータＱ１が与えられたパスパターンコンパイル部２７は、図２３のＤＴＤを参照し「ｉｎｆｏ」を構成する要素が１０個であることを計算する。つまり、
（１）ｉｎｆｏ
（２）ｉｓｂｎ
（３）ｉｓｂｎテキスト
（４）ｉｓｓｕｅＤａｔｅ
（５）ｙｅａｒ
（６）ｙｅａｒテキスト
（７）ｍｏｎｔｈ
（８）ｍｏｎｔｈテキスト
（９）ｄａｙ
（１０）ｄａｙテキスト
の１０個である。もちろん、これらの要素は構造化文書ＤＢ２１の構造ガイドデータ領域２１ａに反映される。

一方、クエリデータＱ１
//book[author[first]
に対応する第２構造グラフは、図１１に示したように、
２ − ６
であった。対応する構造ガイドデータ領域２１ａの部分木があるが、先の（１）〜（１０）に対応する構造ガイドデータ領域２１ａの部分木とは共有部分を持たない。

その結果、パスパターンコンパイル部２７は、「ｉｎｆｏ」に該当するＧＩＤ１２が来た場合には１０個分の配列要素をスキップできることを判断し、図２４に示すように、ＧＩＤ１２に対応するPListに１０個のスキップ手続きをパスパターン処理テーブル２９に設定しておく。

そして、構造ストリーム走査部２８では、ＧＩＤ１２を走査した時、１０個の構造ストリーム要素を飛ばして、走査処理を継続する。

なお、上記の例では、事前の構造情報を使った高速化を説明したが、格納された構造化文書データの統計情報を使っても同様に高速化することができる。

上記の例では、ＤＴＤが事前定義されていたケースを考えたが、同様にＤＴＤが事前定義されていなくても、全構造化文書データに「ｉｎｆｏ」以下の構造情報が現れていれば、パスパターンコンパイル部２７では構造ストリームデータの一部をスキップする手続きをパスパターン処理テーブル２９に埋め込んで、同様のスキップを実行することができる。そのために、構造ストリーム変換部２５にて、全構造化文書データに「ｉｎｆｏ」以下の構造が現れているフラグを構造ガイドデータ領域２１ａに記憶しておけばよい。

このように本実施の形態によれば、構造ストリームは途中再生可能であるため、構造ＩＤと統計情報（描画スキーマ、索引）を使うことで不要なトラバースをスキップすることができる。

本発明の第１の実施の形態にかかる構造化文書管理システムのシステム構築例を示す模式図である。 サーバおよびクライアント端末のモジュール構成図である。 サーバおよびクライアント端末の概略構成を示すブロック図である。 構造化文書データの一例を示す説明図である。 構造ガイドデータの一例を示す説明図である。 構造ストリームデータの一例を示す説明図である。 構造ガイドデータの更新処理の流れを示すフローチャートである。 クエリデータの一例を示す説明図である。 パスパターンコンパイル処理の流れを概略的に示すフローチャートである。 クエリデータＱ１に対する第１次構造グラフを示す模式図である。 図１０の第１次構造グラフに基づく第２次構造グラフを示す模式図である。 クエリデータＱ１に対するパスパターン処理テーブルの一例を示す説明図である。 パスパターン処理テーブルの生成処理の流れを示すフローチャートである。 構造ストリームの走査処理の流れを示すフローチャートである。 PlaceへのTokenプッシュ処理の流れを示すフローチャートである。 図１２で示したパスパターン処理テーブルに対して図６で示した構造ストリームデータを与えたときの進行図表である。 本発明の第２の実施の形態にかかるクエリデータＱ２の一例を示す説明図である。 クエリデータＱ２に対する第１次構造グラフを示す模式図である。 図１８の第１次構造グラフに基づく第２次構造グラフを示す模式図である。 クエリデータＱ２に対するパスパターン処理テーブルの一例を示す説明図である。 図２０で示したパスパターン処理テーブルに対して図６で示した構造ストリームデータを与えたときの進行図表である。 本発明の第３の実施の形態にかかるクエリデータＱ１、Ｑ２を同時に処理するパスパターン処理テーブルの一例を示す説明図である。 本発明の第４の実施の形態にかかる事前の構造情報を伴う１つの構造化文書データの一例を示す説明図である。 スキップ手続きが設定されたパスパターン処理テーブルの一例を示す説明図である。

符号の説明

１ 構造化文書管理装置
２１ａ 構造ガイドデータ記憶手段
２１ｂ 構造ストリームデータ記憶手段
２４ 文書データ受付手段
２５ 構造ストリーム変換手段
２６ クエリデータ受付手段
２７ パスパターンコンパイル手段
２８ 構造ストリーム走査手段
Ｑ１，Ｑ２ クエリデータ

Claims (16)

1. 階層化された論理構造を有している構造化文書データの入力を受け付ける文書データ受付手段と、
   前記構造化文書データの階層構造情報の要約である構造ガイドデータを記憶する構造ガイドデータ記憶手段と、
   前記文書データ受付手段により受け付けた前記構造化文書データを構文解析し、前記構造ガイドデータを用いて前記構造化文書データ中にある構造情報を１次元の配列データである構造ストリームデータに変換する構造ストリーム変換手段と、
   この構造ストリーム変換手段により変換された前記構造ストリームデータを記憶する構造ストリームデータ記憶手段と、
   を備えることを特徴とする構造化文書管理装置。
2. クエリデータの入力を受け付けるクエリデータ受付手段と、
   このクエリデータ受付手段により受け付けた前記クエリデータを構文解析し、前記構造ガイドデータ記憶手段に記憶されている前記構造ガイドデータを参照することで前記クエリデータに特化した処理手順を指定するパスパターン処理テーブルを生成するパスパターンコンパイル手段と、
   前記構造ストリームデータ記憶手段から前記構造ストリームデータ集合を取得し、前記パスパターン処理テーブルに対して前記構造ストリームを与えて処理手順を実行する構造ストリーム走査手段と、
   を更に備えることを特徴とする請求項１記載の構造化文書管理装置。
3. 前記パスパターンコンパイル手段は、複数の前記クエリデータを処理する場合、前記各クエリデータに係るそれぞれの前記パスパターン処理テーブルを合成して、複数の前記クエリデータのパスパターン処理テーブルとする、
   ことを特徴とする請求項２記載の構造化文書管理装置。
4. 前記パスパターンコンパイル手段は、前記構造化文書データの構造情報が定義されている場合、前記構造ストリームデータの一部をスキップする手続きを前記パスパターン処理テーブルに埋め込む、
   ことを特徴とする請求項２記載の構造化文書管理装置。
5. 前記パスパターンコンパイル手段は、前記構造化文書データの統計情報により構造情報が現れている場合、前記構造ストリームデータの一部をスキップする手続きを前記パスパターン処理テーブルに埋め込む、
   ことを特徴とする請求項２記載の構造化文書管理装置。
6. 前記構造化文書データの階層構造情報の要約である前記構造ガイドデータは、以下に示す（１）〜（３）の条件を保持している、
   （１）システムに格納された構造化文書データ集合に現れる全てのパスは、構造ガイドデータに現れる。
   （２）構造ガイドデータに現れる全てのパスは、システムに格納された構造化文書データ集合に現れる。
   （３）構造ガイドデータに現れるパスは全て一意的である。
   ことを特徴とする請求項１記載の構造化文書管理装置。
7. 階層化された論理構造を有している構造化文書データの入力を受け付ける文書データ受付機能と、
   前記文書データ受付機能により受け付けた前記構造化文書データを構文解析し、前記構造化文書データの階層構造情報の要約である構造ガイドデータを用いて前記構造化文書データ中にある構造情報を１次元の配列データである構造ストリームデータに変換する構造ストリーム変換機能と、
   この構造ストリーム変換機能により変換された前記構造ストリームデータを構造ストリームデータ記憶手段に記憶する機能と、
   をコンピュータに実行させることを特徴とする構造化文書管理プログラム。
8. クエリデータの入力を受け付けるクエリデータ受付機能と、
   このクエリデータ受付機能により受け付けた前記クエリデータを構文解析し、前記構造ガイドデータを参照することで前記クエリデータに特化した処理手順を指定するパスパターン処理テーブルを生成するパスパターンコンパイル機能と、
   前記構造ストリームデータ記憶手段から前記構造ストリームデータ集合を取得し、前記パスパターン処理テーブルに対して前記構造ストリームを与えて処理手順を実行する構造ストリーム走査機能と、
   を更にコンピュータに実行させることを特徴とする請求項７記載の構造化文書管理プログラム。
9. 前記パスパターンコンパイル機能は、複数の前記クエリデータを処理する場合、前記各クエリデータに係るそれぞれの前記パスパターン処理テーブルを合成して、複数の前記クエリデータのパスパターン処理テーブルとする、
   ことを特徴とする請求項８記載の構造化文書管理プログラム。
10. 前記パスパターンコンパイル機能は、前記構造化文書データの構造情報が定義されている場合、前記構造ストリームデータの一部をスキップする手続きを前記パスパターン処理テーブルに埋め込む、
    ことを特徴とする請求項８記載の構造化文書管理プログラム。
11. 前記パスパターンコンパイル機能は、前記構造化文書データの統計情報により構造情報が現れている場合、前記構造ストリームデータの一部をスキップする手続きを前記パスパターン処理テーブルに埋め込む、
    ことを特徴とする請求項８記載の構造化文書管理プログラム。
12. 階層化された論理構造を有している構造化文書データの入力を受け付ける文書データ受付工程と、
    前記文書データ受付工程により受け付けた前記構造化文書データを構文解析し、前記構造化文書データの階層構造情報の要約である構造ガイドデータを用いて前記構造化文書データ中にある構造情報を１次元の配列データである構造ストリームデータに変換する構造ストリーム変換工程と、
    この構造ストリーム変換工程により変換された前記構造ストリームデータを構造ストリームデータ記憶手段に記憶する工程と、
    を含むことを特徴とする構造化文書管理方法。
13. クエリデータの入力を受け付けるクエリデータ受付工程と、
    このクエリデータ受付工程により受け付けた前記クエリデータを構文解析し、前記構造ガイドデータを参照することで前記クエリデータに特化した処理手順を指定するパスパターン処理テーブルを生成するパスパターンコンパイル工程と、
    前記構造ストリームデータ記憶手段から前記構造ストリームデータ集合を取得し、前記パスパターン処理テーブルに対して前記構造ストリームを与えて処理手順を実行する構造ストリーム走査工程と、
    を更に含むことを特徴とする請求項１２記載の構造化文書管理方法。
14. 前記パスパターンコンパイル工程は、複数の前記クエリデータを処理する場合、前記各クエリデータに係るそれぞれの前記パスパターン処理テーブルを合成して、複数の前記クエリデータのパスパターン処理テーブルとする、
    ことを特徴とする請求項１３記載の構造化文書管理方法。
15. 前記パスパターンコンパイル工程は、前記構造化文書データの構造情報が定義されている場合、前記構造ストリームデータの一部をスキップする手続きを前記パスパターン処理テーブルに埋め込む、
    ことを特徴とする請求項１３記載の構造化文書管理方法。
16. 前記パスパターンコンパイル工程は、前記構造化文書データの統計情報により構造情報が現れている場合、前記構造ストリームデータの一部をスキップする手続きを前記パスパターン処理テーブルに埋め込む、
    ことを特徴とする請求項１３記載の構造化文書管理方法。

Images