構造化文書管理システム及びプログラム
【課題】複数のタグの値による検索を高速に行うのに適した索引管理を実現する。
【解決手段】ドキュメント管理部５２は、文字列結合索引データの作成を指示するための外部から与えられる索引作成要求であって、作成された文字列結合索引データが付与されるタグを指定する索引作成要求に基づき、ＸＭＬ文書格納部４２１に新たに格納されるまたは既に格納されているＸＭＬ文書から当該索引作成要求で指定されたタグを検出する。索引管理部５４は、ドキュメント管理部５２によって検出されたタグを有するＸＭＬ文書に含まれている当該タグ以下に出現する複数のテキストノードの値を連結して索引化し、当該タグに付与される文字列結合索引データとして索引格納部４２２に格納する。
【解決手段】ドキュメント管理部５２は、文字列結合索引データの作成を指示するための外部から与えられる索引作成要求であって、作成された文字列結合索引データが付与されるタグを指定する索引作成要求に基づき、ＸＭＬ文書格納部４２１に新たに格納されるまたは既に格納されているＸＭＬ文書から当該索引作成要求で指定されたタグを検出する。索引管理部５４は、ドキュメント管理部５２によって検出されたタグを有するＸＭＬ文書に含まれている当該タグ以下に出現する複数のテキストノードの値を連結して索引化し、当該タグに付与される文字列結合索引データとして索引格納部４２２に格納する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、構造化文書を検索するのに用いられる索引を管理する構造化文書管理システム及びプログラムに関する。
【背景技術】
【０００２】
ＸＭＬ（Extensible Markup Language）形式の文書、つまりＸＭＬ文書に代表される構造化文書では、タグと呼ばれる文字列で階層的な構造が表現される。具体的には、１組のタグ（開始タグ及び終了タグの組）によってテキストを囲むことによって、当該テキストが構造化される。開始タグから終了タグまでの文字列はタグを含めて要素と呼ばれ、開始タグ及び終了タグで囲まれた文字列は、要素の内容と呼ばれる。構造化文書（ＸＭＬ文書）は木構造によって表現することが可能である。構造化文書の木構造において、構造化文書の要素に対応するノードは要素ノード、要素の内容（値）がテキストの場合の当該要素の内容に対応するノードはテキストノードと呼ばれる。テキストノードはテキストのみから構成される。つまりテキストノード＝テキストノードの値＝テキストである。
【０００３】
また、データベースサーバ上で動作するデータベース管理システム（Database Management System: ＤＢＭＳ）を始めとする、多数の構造化文書を管理し、大規模な検索処理を行うシステム（構造化文書管理システム）においては、例えば特許文献１または２に記載されているように、索引（インデックス）を用いて検索速度を向上させる手法が適用されている。
【０００４】
構造化文書中のデータ（値）による検索を高速化するために索引を付与する場合、検索対象となることの多い「要素ノード単位」に行われるのが一般的である。例えば、
＜住所＞
＜都道府県＞東京都＜／都道府県＞
＜市町村＞府中市武蔵台＜／市町村＞
＜番地＞一丁目一番地十五＜／番地＞
＜／住所＞
のようなデータを含むＸＭＬ文書に対して、「住所に"東京都府中市"が含まれる」という条件で検索する場合を想定する。
【０００５】
この場合、クライアント端末から構造化文書検索管理システムに対して与えられる検索要求の示す検索文字列（クエリ）は「／住所［都道府県／ｔｅｘｔ（）＝"東京都"ＡＮＤ［ｃｏｎｔａｉｎｓ（市町村／ｔｅｘｔ（），"府中市"）］」となる。このようなクエリに対するＸＭＬ文書検索を高速化するために、パス「／住所／都道府県」及びパス「／住所／市町村」でそれぞれ特定される要素ノード（＜都道府県＞タグ及び＜市町村＞タグ）に対して索引が作成・付与される。
【特許文献１】特開２０００−２０７４０９号
【特許文献１】特開２００６−１７２２６８号
【発明の開示】
【発明が解決しようとする課題】
【０００６】
しかし、要素ノード単位で作成される索引を利用してＸＭＬ文書検索の高速化を図る場合には＜住所＞タグ内に含まれるタグの自由度が制限される。例えば、図４に示される２つの文書＃１及び＃２
文書＃１：
＜住所＞
＜都道府県＞東京都＜／都道府県＞
＜市町村＞府中市武蔵台＜／市町村＞
＜番地＞一丁目一番地十五＜／番地＞
＜／住所＞
文書＃２：
＜住所＞
＜都道府県＞東京都＜／都道府県＞
＜区＞港区＜／区＞
＜市町村＞芝浦＜／市町村＞
＜番地＞一丁目一番地一＜／番地＞
＜／住所＞
に対して作成される索引を利用したＸＭＬ文書検索で、東京都に対してのみ＜市町村＞タグに加えて＜区＞タグを利用する場合を想定する。具体的には、「住所に"東京都港区芝浦"が含まれる」という条件で検索するものとする。この場合、クエリは「／住所［都道府県／ｔｅｘｔ（）＝"東京都" ＡＮＤ 区／ｔｅｘｔ（）＝"港区"ＡＮＤ［ｃｏｎｔａｉｎｓ（市町村／ｔｅｘｔ（），"芝浦"）］」となり、条件の値だけでなくクエリそのものも書き換える必要が生じる。
【０００７】
一方、ＸＭＬ文書の階層構造を指定するＸＰａｔｈと呼ばれるパス形式を用いて、例えば「／住所［ｃｏｎｔａｉｎｓ（．，"東京都港区芝浦"）］」と記述することにより、目的の検索を実現することが可能である。しかし、要素ノード単位で索引が作成される従来技術では、該当する索引が存在しないため、個々のＸＭＬ文書内をサーチして、条件に合致する文書かを確認する必要がある。このため、高速な検索を実現することは難しい。
【０００８】
また、要素ノード単位で作成された索引を利用して検索を行う場合、＜都道府県＞タグに付与された索引でヒットした結果と、＜市町村＞タグに付与された索引でヒットした結果と、＜区＞タグに付与された索引でヒットした結果が、同一文書に含まれているかどうかＡＮＤマージ処理を行う必要がある。このため、いずれか１つ、もしくは全ての索引での検索で大量のデータがヒットするようなケースでは、ＡＮＤマージ処理で検索の高速性が損なわれるおそれがある。
【０００９】
本発明は上記事情を考慮してなされたものでその目的は、複数のタグの値による検索を高速に行うのに適した索引管理を実現できる構造化文書管理システム及びプログラムを提供することにある。
【課題を解決するための手段】
【００１０】
本発明の１つの観点によれば、複数の構造化文書を管理する構造化文書管理システムが提供される。このシステムは、複数の構造化文書を格納する構造化文書格納手段と、前記構造化文書格納手段に格納されている構造化文書を検索するのに用いられる索引データを格納する索引格納手段と、文字列結合索引データの作成を指示するための外部から与えられる索引作成要求であって、作成された文字列結合索引データが付与されるタグを指定する索引作成要求に基づき、前記構造化文書格納手段に新たに格納されるまたは既に格納されている構造化文書から当該索引作成要求で指定されたタグを検出するタグ検出手段と、前記タグ検出手段によって検出されたタグを有する前記構造化文書に含まれている当該タグ以下に出現する複数のテキストノードの値を連結して索引化し、当該タグに付与される文字列結合索引データとして前記索引格納手段に格納する索引管理手段とを具備する。
【発明の効果】
【００１１】
本発明によれば、構造化文書の指定されたタグ以下に出現する複数のテキストノード、特に階層が異なる要素ノードの要素の値である複数のテキストノードの値を連結して、当該指定されたタグの索引（文字列結合索引）として管理することができる。したがって、この文字列結合索引を利用することにより、タグを跨ったデータを条件とした検索を高速化できると共に、ヒット件数が多い場合でも性能劣化を防ぐことができる。
【発明を実施するための最良の形態】
【００１２】
以下、本発明の実施の形態につき図面を参照して説明する。
図１は本発明の一実施形態に係る構造化文書管理システムを含むクライアント−サーバシステムのハードウェア構成を示すブロック図である。クライアント−サーバシステムは、主として、データベースサーバ（データベースサーバコンピュータ）１０と、複数のクライアント端末とから構成される。複数のクライアント端末はクライアント端末２０を含む。クライアント端末２０上では、データベースサーバ１０を利用するアプリケーション（アプリケーションプログラム）が動作する。クライアント端末２０を含む複数のクライアント端末は、ローカルエリアネットワーク（ＬＡＮ）のようなネットワーク３０を介してデータベースサーバ１０と接続されている。なお、図１にはクライアント端末２０以外のクライアント端末は省略されている。
【００１３】
データベースサーバ１０は、ハードディスクドライブのような外部記憶装置４０と接続されている。この外部記憶装置４０は、データベース管理プログラム４１及びＸＭＬデータベース４２を格納する。
【００１４】
データベース管理プログラム４１は、データベースサーバ１０によるＸＭＬデータベース４２の管理、及びクライアント端末からの検索要求に基づく検索処理に用いられる。ＸＭＬデータベース４２は構造化文書であるＸＭＬ文書（ＸＭＬ文書データ）を格納する構造化文書データベースである。ＸＭＬデータベース４２には、当該データベース４２に格納されるＸＭＬ文書に基づいて作成される索引等も格納される。
【００１５】
本実施形態では、データベースサーバ１０及び外部記憶装置４０によって構造化文書管理システム５０が実現される。
【００１６】
図２は構造化文書管理システム５０の主として機能構成を示すブロック図である。構造化文書管理システム５０は、ＸＭＬデータベース４２に加えて、コマンド管理部５１、ドキュメント管理部５２、検索エンジン５３、索引管理部５４及びデータベース操作部５５を含む。本実施形態において、これらの各部５１乃至５５は、図１のデータベースサーバ１０が外部記憶装置４０に格納されているデータベース管理プログラム４１を読み込んで実行することにより実現されるものとする。このプログラム４１は、コンピュータ読み取り可能な記憶媒体に予め格納して頒布可能である。また、このプログラム４１が、ネットワーク３０を介してデータベースサーバ１０にダウンロードされても構わない。
【００１７】
ＸＭＬデータベース４２には、ＸＭＬ文書格納部４２１、索引格納部４２２及び索引設定管理テーブル格納部４２３が確保されている。ＸＭＬ文書格納部４２１は、複数のＸＭＬ文書（ＸＭＬ文書データ）を格納するのに用いられる。索引格納部４２２は、ＸＭＬ文書格納部４２１に新たに格納されるまたは既に格納されているＸＭＬ文書に基づいて作成される索引（索引データ）を格納するのに用いられる。索引設定管理テーブル格納部４２３は、索引格納部４２２に格納されるべき索引の作成を管理する索引設定管理テーブル４２４を格納するのに用いられる。
【００１８】
コマンド管理部５１は、クライアント端末からネットワーク３０を介して与えられる各種のコマンド（要求）を受け付けて当該コマンドの種別を判別し、その判別結果に応じてドキュメント管理部５２、検索エンジン５３及び索引管理部５４のいずれかに当該コマンドの指定する処理を実行させる。ドキュメント管理部５２は、ＸＭＬデータベース４２内のＸＭＬ文書格納部４２１にＸＭＬ文書を登録する登録処理など、ＸＭＬ文書格納部４２１におけるＸＭＬ文書の管理を司る。
【００１９】
検索エンジン５３は、クライアント端末からの検索要求に従い、当該検索要求で指定される検索条件に合致するＸＭＬ文書をＸＭＬデータベース４２内の索引格納部４２２に格納されている索引を利用してＸＭＬ文書格納部４２１から検索する。索引管理部５４は、ＸＭＬ文書格納部４２１に格納されているＸＭＬ文書を検索するのに用いられる索引を管理する。この索引の管理は、索引の作成、作成された索引の索引格納部４２２への格納を含む。索引管理部５４は、索引格納部４２２から索引を検索する索引検索部５６を含む。なお、索引検索部５６が索引管理部５４から独立に設けられていても構わない。データベース操作部５５は、ドキュメント管理部５２、検索エンジン５３及び索引管理部５４がＸＭＬデータベース４２をアクセスするためのインタフェースとして機能する。
【００２０】
次に、本実施形態の動作について、（１）索引設定処理、（２）文書登録処理、（３）文書検索処理を例に、順に説明する。
【００２１】
（１）索引設定処理
まず、索引設定処理について図３のフローチャートを参照して説明する。
今、クライアント端末２０上では、当該端末２０から構造化文書管理システム５０を利用するためのアプリケーションが動作しているものとする。このような状態において、ユーザは構造化文書管理システム５０上で複数のテキストノードを跨った検索が必要な場合、クライアント端末２０を操作して、当該複数のテキストノードの値をそれぞれ要素の内容として含む要素ノードを下位ノードとするノード（タグ）を指定する。そしてユーザはクライアント端末２０を操作して、ＸＭＬ文書（の階層構造）上で、指定されたノード（指定ノード）以下に出現する、例えば全てのテキストノードの値（テキスト）を連結して索引（文字列結合索引）を作成することを指示する索引作成要求をクライアント端末２０から発行させる。指定ノードは、テキスト連結による索引作成の起点となると共に、作成された索引が設定（付与）されるノードである。
【００２２】
クライアント端末２０は、上述のユーザの操作を受けて、指定ノードの情報を含む索引作成要求（索引作成コマンド）をネットワーク３０を介してデータベースサーバ１０に発行する（ステップＳ１）。この索引作成要求は、データベースサーバ１０（構造化文書管理システム５０）のコマンド管理部５１で受け取られる。本実施形態では、指定ノードは、ＸＭＬ文書の階層構造上のルートノードから当該指定ノードへのパス（構造情報）によって表される。
【００２３】
コマンド管理部５１は、クライアント端末２０からの索引作成要求（つまりユーザによって指定された外部からの索引作成要求）を受け取ると、当該要求を解析する。コマンド管理部５１は、この要求（コマンド）解析結果に基づき、ドキュメント管理部５２、検索エンジン５３及び索引管理部５４の中から、当該要求を処理すべき機能部として索引管理部５４を選択し、当該索引管理部５４にクライアント端末２０からの索引作成要求を渡す（ステップＳ２）。
【００２４】
索引管理部５４は、コマンド管理部５１から渡された索引作成要求に基づき、新規の索引作成に必要な索引設定情報を生成して索引設定管理テーブル４２４に追加し、しかる後に当該索引作成要求に対する応答（例えば索引作成の正常終了通知）をコマンド管理部５１に返す（ステップＳ３）。索引設定情報は、索引作成要求によって指示された索引を作成する際に参照される情報であり、その詳細については後述する。なお、索引設定管理テーブル４２４のコピーをデータベースサーバ１０のメモリ（図示せず）上に置いて、当該索引設定管理テーブル４２４のコピー上で索引設定情報の追加登録・参照を行うならば、索引設定管理テーブル４２４へのアクセスを高速に行うことができる。
【００２５】
コマンド管理部５１は、索引管理部５４からの応答を、ネットワーク３０を介してクライアント端末２０に返す（ステップＳ４）。即ち、索引作成要求に対する応答が、索引管理部５４からクライアント端末２０に当該索引作成要求とは逆向きの経路を辿って返される。
【００２６】
図４は、ＸＭＬ文書格納部４２１に既に格納されている、或いは新たに格納される２つのＸＭＬ文書＃１及び＃２の例を示す。図５は、図４に示されるＸＭＬ文書＃１及び＃２を木構造で表現した例を示す。
【００２７】
図５において、“ｒｏｏｔ”で示されるノード５００は、ＸＭＬ文書＃１及び＃２のルート（ｒｏｏｔ）ノードである。ｒｏｏｔノードの子ノード（つまりｒｏｏｔノード下のノード）は、ＸＭＬ文書＃１及び＃２の＜住所＞タグを含む要素（つまり要素名が「住所」の要素）に対応する要素ノード５１０及び５２０である。要素ノード５１０及び５２０を、住所ノード５１０及び５２０と呼ぶこともある。図５では、ｒｏｏｔノード及び要素ノードは楕円で表され、テキストノードは矩形で表されている。
【００２８】
ノード５１０の子ノードは、ＸＭＬ文書＃１のそれぞれ＜都道府県＞タグ、＜市町村＞タグ及び＜番地＞タグを含む要素に対応する要素ノード５１１，５１２及び５１３である。要素ノード５１１，５１２及び５１３を、それぞれ都道府県ノード５１１、市町村ノード５１２及び番地ノード５１３と呼ぶこともある。
【００２９】
ノード５２０の子ノードは、ＸＭＬ文書＃２のそれぞれ＜都道府県＞タグ、＜区＞タグ、＜市町村＞タグ及び＜番地＞タグを含む要素に対応する要素ノード５２１，５２２，５２３及び５２４である。要素ノード５２１，５２２，５２３及び５２４を、それぞれ都道府県ノード５２１、区ノード５２２、市町村ノード５２３及び番地ノード５２４と呼ぶこともある。
【００３０】
ノード５１１，５１２及び５１３の子ノードは、それぞれ＜都道府県＞タグ、＜市町村＞タグ及び＜番地＞タグを含む要素の内容（値）であるテキスト「東京都」，「府中市武蔵台」及び「一丁目一番地十五」に対応するテキストノード５１１Ｔ，５１２Ｔ及び５１３Ｔである。ノード５２１，５２２，５２３及び５２４の子ノードは、それぞれ＜都道府県＞タグ、＜区＞タグ、＜市町村＞タグ及び＜番地＞タグを含む要素の内容であるテキスト「東京都」，「港区」，「芝浦」及び「一丁目一番地一」に対応するテキストノード５２１Ｔ，５２２Ｔ，５２３Ｔ及び５２４Ｔである。
【００３１】
本実施形態において、索引作成要求で指定されたノード（指定ノード）が＜住所＞タグを含む要素に対応する要素ノード５１０及び５２０であるものとする。この要素ノード５１０及び５２０へのパスは、「／住所」で表される。パス「／住所」に含まれている「／」は、この例のようにパスの先頭に位置している場合、ｒｏｏｔノードを示す。
【００３２】
図６（ａ）は、索引作成要求で指定されたノード（指定ノード）へのパスが「／住所」の場合に、索引管理部５４による索引設定情報追加後の索引設定管理テーブル４２４の一例を示す。この索引設定管理テーブル４２４の各エントリの情報（索引設定情報）は、図６（ａ）に示すように、設定パス及び索引種別の情報を含む。ここでは、設定パスとして指定ノードへのパス「／住所」を、索引種別として「文字列結合索引」をそれぞれ含む索引設定情報が索引設定管理テーブル４２４に格納されている。「文字列結合索引」とは、索引設定情報に当該「文字列結合索引」と対をなして設定されているパスによって指定されるノード（タグ）以下に出現する複数のテキストノードの値（テキスト）を出現順に連結することによって作成される索引である。本実施形態では、設定索引設定管理テーブル４２４に登録されている索引設定情報（中の索引種別）によって示される種別の索引は、次に述べるようにＸＭＬ文書の登録時に作成される。
【００３３】
（２）文書登録処理、
次に、文書登録処理について図７のフローチャートを参照して説明する。
今、ユーザによるクライアント端末２０の操作に従い、当該端末２０からデータベースサーバ１０に対して新たにＸＭＬ文書を登録することを指示する文書登録要求（文書登録コマンド）が発行されたものとする（ステップＳ１１）。この登録要求は、データベースサーバ１０（構造化文書管理システム５０）のコマンド管理部５１で受け取られる。
【００３４】
コマンド管理部５１は、クライアント端末２０からの文書登録要求を受け取ると、当該要求を解析する。コマンド管理部５１は、この要求（コマンド）解析結果に基づき、当該要求を処理すべき機能部としてドキュメント管理部５２を選択し、当該ドキュメント管理部５２にクライアント端末２０からの文書登録要求を渡す（ステップＳ１２）。
【００３５】
ドキュメント管理部５２は、コマンド管理部５１から渡された文書登録要求に従い、当該要求で指定された新たに登録されるべきＸＭＬ文書を先頭から順に解析しながら（ステップＳ１３）、索引設定管理テーブル４２４に登録されている索引設定情報中の設定パスで指定されるタグを含む要素（要素ノード）を検出するタグ検出手段として機能する。そしてドキュメント管理部５２は、解析された情報が、上記設定パスで指定される要素、つまり索引の付与（設定）が指定されている要素（要素ノード）であるかをチェックする（ステップＳ１４）。もし、解析された情報が索引の付与が指定されている要素中の情報（開始タグ、テキスト、終了タグ等）であるならば（ステップＳ１４）、ドキュメント管理部５２は、索引設定管理テーブル４２４に登録されている索引設定情報のうち、その要素へのパスの情報を含む索引設定情報から索引種別情報を取り出して、当該索引種別情報が「文字列結合索引」を示しているかを判定する（ステップＳ１５）。
【００３６】
もし、索引種別情報が「文字列結合索引」を示していないならば、ドキュメント管理部５２は解析された情報に対して通常の処理（従来と同様の処理）を行う。これに対して、索引種別情報が「文字列結合索引」を示しているならば、ドキュメント管理部５２は解析された情報の種類、即ち解析された情報が開始タグ（索引の付与が指定されている要素の開始タグ）、テキストまたは終了タグ（索引の付与が指定されている要素の終了タグ）のいずれであるかを判別する（ステップＳ１６）
解析された情報が開始タグの場合、ドキュメント管理部５２は文字列連結を開始する（ステップＳ１７）。解析された情報がテキストの場合、ドキュメント管理部５２は当該テキスト（文字列）を例えばデータベースサーバ１０のメモリに確保されている文字列連結領域内で連結する処理を実行する（ステップＳ１８）。解析された情報が終了タグの場合、ドキュメント管理部５２は索引管理部５４を起動して、その時点において文字列連結領域内で連結されている文字列による索引化を当該索引管理部５４に行わせる（ステップＳ１９）。
【００３７】
このように本実施形態においては、クライアント端末２０からの索引作成要求で指定されたノード（タグ）を含むＸＭＬ文書の登録時に、当該指定されたノード（指定ノード）へのパスの情報を含む索引設定情報に基づき、当該ＸＭＬ文書の指定ノード（パス）に対して索引（文字列結合索引）が作成される。この索引設定情報に基づいて索引を作成することは、当該索引設定情報の生成に用いられた索引作成要求に基づいて索引を作成することと等価である。但し本実施形態のように、索引設定情報に基づいて索引を作成する手法を適用することにより、クライアント端末２０からの索引作成要求を記憶しておき、新たにＸＭＬ文書を登録する毎に当該索引作成要求を解析して、その解析結果に基づいて索引を作成する手法と比べて、索引作成の高速化を図ることができる。
【００３８】
なお、ＸＭＬ文書格納部４２１に既に登録されているＸＭＬ文書（例えばユーザによって指定された既登録のＸＭＬ文書）を対象に、当該ＸＭＬ文書の指定ノード（パス）に対して索引の作成が行われても良い。即ち、ユーザの操作に応じてクライアント端末２０からデータベースサーバ１０（構造化文書管理システム５０）に対して既登録のＸＭＬ文書を指定して、当該指定されたＸＭＬ文書の指定ノード（パス）に対して索引の作成を行わせることも可能である。
【００３９】
ドキュメント管理部５２は、ステップＳ１７，Ｓ１８またはＳ１９が実行されるとステップＳ２０に進む。ドキュメント管理部５２はまた、解析された情報が索引作成が指定されている要素中の情報でないと判定された場合（ステップＳ１４）にもステップＳ２０に進む。このステップＳ２０において、ドキュメント管理部５２は、解析された情報をＸＭＬデータベース４２のＸＭＬ文書格納部４２１に格納するドキュメント格納処理を実行する。
【００４０】
ドキュメント管理部５２は、ステップＳ２０を実行すると、クライアント端末２０からの文書登録要求で指定されたＸＭＬ文書（ドキュメント）の登録が終了したかを判定する（ステップＳ２１）。もし、指定されたＸＭＬ文書の登録が終了していないならば、ドキュメント管理部５２はステップＳ１４に戻り、指定されたＸＭＬ文書中の次に解析された情報が索引作成が指定されている要素中の情報であるかを判定する。以下、同様にして、ドキュメント管理部５２は索引作成が指定されている要素中の開始タグを判別した後、当該要素中の終了タグを判別するまでの間に現れる文字列（テキスト）を出現順に全て連結する。そして索引作成が指定されている要素中の終了タグが判別されると、その時点までに連結されている文字列が索引管理部５４によって索引化される（ステップＳ１９）。この索引化によって作成される文字列結合索引（索引データ）は索引格納部４２２に格納される。この文字列結合索引は、索引促成要求によって指定されたノード（要素ノード）に対する（付与される）索引として管理される。索引の形式として例えばＢ木またはハッシュが適用可能であるが、他の形式でも構わない。
【００４１】
ドキュメント管理部５２は、指定されたＸＭＬ文書の登録処理を終了（完了）すると（ステップＳ２１）、文書登録要求に対する応答（例えば文書登録の正常終了通知）をコマンド管理部５１に返す（ステップＳ２２）。コマンド管理部５１は、ドキュメント管理部５２からの応答を、ネットワーク３０を介してクライアント端末２０に返す（ステップＳ２３）。即ち、文書登録要求に対する応答が、ドキュメント管理部５２からクライアント端末２０に当該索引作成要求とは逆向きの経路を辿って返される。
【００４２】
図８は、図６（ａ）の索引設定管理テーブル４２４に登録されている「パス＝／住所」及び「索引種別＝文字列結合」を指定する索引設定情報に従って、図５の木構造で示される２つの文書＃１及び＃２（図４参照）のパス「／住所」に対して作成された索引（文字列結合索引）を、当該木構造と対応付けて示す。
【００４３】
図８から明らかなように、文書＃１のパス「／住所」で指定される要素名が「住所」の要素ノード（つまり、「住所」ノードまたは＜住所＞タグ）以下のテキストノードは、テキストノード５１１Ｔ，５１２Ｔ及び５１３Ｔであり、その値（テキスト）は、それぞれ「東京都」，「府中市武蔵台」及び「一丁目一番地十五」である。この場合、図８に示されるように、これらのテキスト（文字列）が全て連結された索引（文字列結合索引）５３０が、パス「／住所」（「住所」ノードまたは＜住所＞タグ）に対する索引として作成される。
【００４４】
同様に、文書＃１のパス「／住所」で指定される要素名が「住所」の要素ノード（つまり、「住所」ノードまたは＜住所＞タグ）以下のテキストノードは、テキストノード５２１Ｔ，５２２Ｔ，５２３Ｔ及び５２４Ｔであり、その値（テキスト）は、それぞれ「東京都」，「港区」，「芝浦」及び「一丁目一番地一」である。この場合、図８に示されるように、これらのテキスト（文字列）が全て連結された索引（文字列結合索引）５４０がパス「／住所」（「住所」ノードまたは＜住所＞タグ）に対する索引として作成される。
【００４５】
図９は、作成された文字列結合索引（索引データ）の索引格納部４２２における配列（索引データ配列）のデータ構造の一例を示す。図９に示す索引データ配列内の各索引データは、ノード位置、都道府県ノード下のノード（都道府県ノードの子ノード）の値（テキスト）、区ノード下のノードの値、市町村ノード下のノードの値及び番地ノード下のノードの値の各情報から構成される。ノード位置の情報は、ＸＭＬ文書格納部４２１に格納されている該当するＸＭＬ文書中のノード、即ち索引設定管理テーブル４２４に登録されている索引設定情報中のパスによって指定されるノード（タグ）の格納位置、例えばＸＭＬ文書格納部４２１における相対的な格納位置を示す。
【００４６】
索引データを構成する各ノードの値（テキスト）は、都道府県ノード下のノード、区ノード下のノード、市町村ノード下のノード及び番地ノード下のノードの順番で連結される。但し、文書＃１に関しては、区ノード下のノードの値は存在しないため、都道府県ノード下のノード、市町村ノード下のノード及び番地ノード下のノードの順番で連結される。
【００４７】
（３）文書検索処理
次に、文書検索処理について図１０のフローチャートを参照して説明する。
今、ユーザによるクライアント端末２０の操作に従い、当該端末２０からデータベースサーバ１０に対してＸＭＬ文書を検索することを指示する検索要求が発行されたものとする（ステップＳ３１）。この検索要求は、データベースサーバ１０（構造化文書管理システム５０）のコマンド管理部５１で受け取られる。
【００４８】
コマンド管理部５１は、クライアント端末２０からの検索要求を受け取ると、当該要求を解析する。コマンド管理部５１は、この要求解析結果に基づき、当該要求を処理すべき機能部として検索エンジン５３を選択し、当該検索エンジン５３にクライアント端末２０からの検索要求を渡す（ステップＳ３２）。
【００４９】
検索エンジン５３は、コマンド管理部５１から渡された検索要求の示す検索文字列（クエリ、検索条件）を解析して（ステップＳ３３）、文字列結合索引が付与されている要素ノード（タグ）への、当該要素ノード（タグ）を跨ったデータでの検索が含まれるかを判定する（ステップＳ３４）。検索エンジン５３は、この条件に合致していると判定した場合、索引管理部５４の索引検索部５６に対して、該当する要素ノードに付与された索引（文字列結合索引）を検索させる（ステップＳ３５）。これに対し、上記の条件に合致しない検索要求の場合、検索エンジン５３は通常の検索処理を実行する（ステップＳ３６）。
【００５０】
索引管理部５４の索引検索部５６に文字列結合索引を検索させた場合、その検索の結果は、当該索引検索部５６から検索エンジン５３に返される。検索エンジン５３は、索引検索部５６による文字列結合索引の検索結果を取得すると、当該文字列結合索引に従ってＸＭＬ文書格納部４２１に格納されているＸＭＬ文書を検索して、そのＸＭＬ文書検索結果を取得する（ステップＳ３７）。コマンド管理部５１は、検索エンジン５３によって取得されたＸＭＬ文書検索結果を受け取って、クライアント端末２０に返す（ステップＳ３８）。
【００５１】
さて、本実施形態で適用される文字列結合索引の作成手法によれば、その作成原理から明らかなように、従来技術においてＸＭＬ文書の末端の要素ノード単位で作成される索引を検索した際に、当該末端の要素ノードに付与された索引でヒットした結果が同一文書に含まれているかどうかを確認するためのＡＮＤマージ処理に相当する処理が、既に文字列結合索引作成時に実行されていることと等価である。したがって、本実施形態のように、索引管理部５４の索引検索部５６によって検索された文字列結合索引を用いてＸＭＬ文書を検索することにより、ＡＮＤマージ処理が不要となるため、ヒット件数が多い場合でも性能劣化を防ぐことができる。
【００５２】
ここで、文字列結合索引を用いたＸＭＬ文書検索の具体例について説明する。ここでは検索要求で示されるクエリとして、「／住所［ｃｏｎｔａｉｎｓ（．，"東京都港区芝浦"）］」が用いられるものとする。この場合、図９の索引データ配列の例では、"東京都港区芝浦"を含む文字列結合索引「東京都港区芝浦一丁目一番地一」及び文書＃２の住所ノード（住所タグ）の位置（ＸＭＬ文書格納部４２１内の位置）が、索引検索部５６によって取得される。文字列結合索引「東京都港区芝浦一丁目一番地一」は、文書＃２の住所ノード以下に出現する全てのテキストノードの値（テキスト）を出現順に結合することによって作成されたものである。したがって、文書＃２の住所ノード（住所タグ）の位置は、「住所に"東京都港区芝浦"が含まれる」ＸＭＬ文書（文書＃２）の住所ノード（住所タグ）を特定する。検索エンジン５３は、この住所ノードの位置から「住所に"東京都港区芝浦"が含まれる」ＸＭＬ文書を検索することができる。
【００５３】
上述したように本実施形態においては、ＸＭＬ文書で指定ノード以下に出現する全てのテキストノードの値（テキスト）を連結して索引（文字列結合索引）が作成される。図１１はこの索引作成をモデル化して示す。図１１において、Ａ，Ｂ，Ｃ，Ｄ，Ｅ及びＸは、あるＸＭＬ文書を木構造で表した場合の要素ノード（タグ）を示し、文字列「ああ」、「いい」、「うう」、「ええ」及び「おお」は、それぞれ要素ノードＤ，Ｄ，Ｄ，Ｅ及びＸの要素の値（に対応するテキストノードの値）を示す。楕円で囲まれた要素ノードＡは、文字列結合索引が付与されるノード（指定ノード）である。図１１の例では、ノードＡ以下に出現する全てのテキスト（文字列）「ああ」、「いい」、「うう」、「ええ」及び「おお」を連結することによって文字列結合索引が作成される。
【００５４】
［第１の変形例］
次に、上記実施形態の第１の変形例について説明する。
上記実施形態では、指定ノード（タグ）以下に出現する全てのテキストノード（の値）が連結される。しかし、一部のテキストノードだけを検索条件として利用するような場合、その部分だけを索引化することにより、索引のボリュームが削減され、つまり外部記憶装置４０の記憶領域の中で索引格納部４２２の占める領域が少なくて済み、且つ検索の高速化が期待される。そこで第１の変形例の特徴は、指定ノード以下に出現する全てのテキストノードのうちの一部の複数のテキストノード（の値）だけを連結して索引化する点にある。
【００５５】
図１２は第１の変形例で適用される索引作成をモデル化して示す。図１２には、図１１と同一の木構造が示されている。図１２の例では、要素ノードＤ，Ｄ，Ｄ，Ｅ及びＸのうち、矩形で囲まれた要素ノードＤ，Ｄ及びＤの要素の値（に対応するテキストノードの値）である、文字列「ああ」、「いい」及び「うう」だけを連結することによって、要素ノード（タグ）Ａの索引（文字列結合索引）が作成される。
【００５６】
第１の変形例では、このような文字列結合索引の作成のために、クライアント端末２０から構造化文書管理システム５０に与えられる索引作成要求により、指定ノード（タグ）を指し示す要素ノードＡへのパス（設定パス）に加えて、指定ノード（タグ）以下に出現する全てのテキストノードのうち、索引化（結合）されるべきテキストノードが指定される。ここでは、指定ノードから索引化されるべきテキストノードの親ノードへの相対パス（結合対象パス）によって、索引化されるべきテキストノードが指定される。
【００５７】
図１２の例では、索引作成要求により、設定パスとして要素ノードＡへのパスが指定されると共に、結合対象パスとして、当該要素ノードＡからの相対パス「Ｂ／Ｃ／Ｄ」が指定される。索引管理部５４は、この索引作成要求を受けた場合、ノードＡ以下に出現する全てのテキストノードのうち、当該ノードＡからの相対パス「Ｂ／Ｃ／Ｄ」によって示されるノード下のテキストノードが、索引化（結合）されるべきテキストノードとして指定されているものと判断する。そして索引管理部５４は、索引設定管理テーブル４２４に索引作成要求に対応する索引設定情報を登録する（図３ステップＳ３）。
【００５８】
第１の変形例では、最大２個の結合対象パスが指定可能であるものとする。そこで、索引設定管理テーブル４２４に登録される索引設定情報は、図６（ａ）に示す設定パス及び索引種別の情報に加えて、２つの結合対象パス＃１及び＃２の情報を含む。結合対象パスとして「Ｂ／Ｃ／Ｄ」が指定されている上記の例では、設定パスとして指定ノードＡへのパスが、索引種別として「文字列結合索引」が、そして例えば結合対象パス＃１として「Ｂ／Ｃ／Ｄ」がそれぞれ設定された索引設定情報が、索引管理部５４によって索引設定管理テーブル４２４に登録される。ドキュメント管理部５２は、この索引設定情報に基づき、索引種別が文字列結合索引の場合には、設定パスで指定されるノードＡ以下に出現する全てのテキストノードのうち、結合対象パス＃１、つまりノードＡからの相対パス「Ｂ／Ｃ／Ｄ」によって示されるノード下のテキストノード（の値）だけを連結することができる。第１の変形例における連結の順番は、結合対象パス＃１によって示されるノード下のテキストノード→結合対象パス＃２によって示されるノード下のテキストノードとなる。１つの結合対象パス＃ｉ（ｉ＝１，２）によって複数のノードが示される場合、そのノード下のテキストノードを連結する順番は、出現順となる。
【００５９】
次に、索引作成要求により、要素ノードＤ下のテキストノードに加えて、要素ノードＥ下のテキストノードも索引化されるべきテキストノードとすることが指定されているものとする。この場合、設定パスとして指定ノードＡへのパスが、索引種別として「文字列結合索引」が、結合対象パス＃１として「Ｂ／Ｃ／Ｄ」が、そして結合対象パス＃２として「Ｂ／Ｃ／Ｅ」がそれぞれ設定された索引設定情報が、索引管理部５４によって索引設定管理テーブル４２４に登録される。ドキュメント管理部５２は、この索引設定情報に基づき、索引種別が文字列結合索引の場合、設定パスで指定されるノードＡ以下に出現する全てのテキストノードのうち、結合対象パス＃１、つまりノードＡからの相対パス「Ｂ／Ｃ／Ｄ」によって示されるノード下のテキストノード、及び結合対象パス＃２、つまりノードＡからの相対パス「Ｂ／Ｃ／Ｅ」によって示されるノード下のテキストノードだけを連結することができる。
【００６０】
もし、索引作成要求により、上記実施形態のようにノードＡ以下に出現する全てのテキストノードを索引化することが指定されている場合、索引管理部５４は索引設定情報の結合対象パス＃１及び＃２の欄に何も設定しない。この場合、ドキュメント管理部５２は、索引設定情報により結合対象パス＃１及び＃２が指定されていないとして、上記実施形態と同様に、設定パスで指定されるノードＡ以下に出現する全てのテキストノード（の値）を連結する。
【００６１】
図６（ｂ）は、第１の変形例で適用される索引設定管理テーブル４２４の一例を示す。この図６（ｂ）に示す索引設定管理テーブル４２４の各エントリの情報（索引設定情報）は、設定パス及び索引種別の情報に加えて、結合対象パス＃１及び＃２の情報を含む。図６（ｂ）において、設定パス及び索引種別としてそれぞれ「／住所」及び「文字列結合索引」が設定されている索引設定情報には、結合対象パス＃１及び＃２としてそれぞれ「住所ノードからの相対パス「都道府県」及び「市町村」が設定されている。
【００６２】
ドキュメント管理部５２は例えばＸＭＬ文書の登録特に、上述の索引設定情報に基づき、設定パス「／住所」で指定される住所ノード以下に出現する全てのテキストのうち、結合対象パス＃１及び＃２として索引設定情報に設定されている住所ノードからの相対パス「都道府県」及び「市町村」によってそれぞれ指定される都道府県ノード及び市町村ノードの値（つまり都道府県ノード下のテキストノードの値であるテキスト及び市町村ノード下のテキストノードの値であるテキスト）を結合する。
【００６３】
図１３は、図５の木構造で示される文書＃１及び＃２の登録時に、図６（ｂ）の索引設定管理テーブル４２４に登録されている上述の索引設定情報に基づいて、パス「／住所」に対して作成された索引（文字列結合索引）を当該木構造と対応付けて示す。ここでは、文書＃１に関しては、「住所」ノード以下に出現するテキストの値のうち、都道府県ノードの値「東京都」と市町村ノードの値「府中市武蔵台」とが連結された索引５３１が「住所」ノードに対する索引として作成される。同様に、文書＃２に関しては、「住所」ノード以下に出現するテキストの値のうち、都道府県ノードの値「東京都」と市町村ノードの値「芝浦」とが連結された索引５４１が「住所」ノードに対する索引として作成される。
【００６４】
なお、索引設定情報に含められる結合対象パスの数は２個に限るものではなく、Ｎを１以上の任意の整数であるとすると、Ｎ個としても良い。
【００６５】
［第２の変形例］
次に上記実施形態の第２の変形例について説明する。この第２の変形例の特徴は、クライアント端末２０からの索引作成要求により、索引化の対象となるテキストノードの優先順位（連結する順序）が指定されている場合に、その指定された優先順位に基づいて索引化の対象となるテキストノードを順序付けして管理する点にある。
【００６６】
図１４は、ＸＭＬ文書の一例を木構造で表した図である。図中の楕円または矩形はそれぞれノードを表している。楕円で表されたノードには名前があり、楕円の中に書かれた“ｒｏｏｔ”などの文字列はノード名である。一方、図中の矩形で示した末端のノードは、そのノードの親ノード（要素ノード）の要素の値（“ｆ１”などの値）を持つテキストノードであり、“ｔｅｘｔ”という固定ノード名を持つ。図１４に示すＸＭＬ文書の例では、ノード名が“ｎａｍｅ”のノード下、つまり“ｎａｍｅ”ノード下に、“ｆｉｒｓｔ”ノード及び“ｓｅｃｏｎｄ”ノードの対が存在する。
【００６７】
第２の変形例では、索引設定管理テーブル４２４に、設定パスとして“ｎａｍｅ”ノードへのパス（／ｎａｍｅ）を含み、索引種別として文字列結合索引を示す情報を含む索引設定情報が登録されているものとする。この索引設定情報は、結合対象パス＃１及び＃２として、それぞれ“ｎａｍｅ”ノードからの相対パス「ｆｉｒｓｔ」及び「ｓｅｃｏｎｄ」を含むものとする。第２の変形例では、作成される文字列結合索引データの配列（索引データ配列）において、結合対象パス＃１で指定される“ｆｉｒｓｔ”ノード下の“ｔｅｘｔ”ノードの値が、結合対象パス＃２で指定される“ｓｅｃｏｎｄ”ノード下の“ｔｅｘｔ”ノードの値よりも優先される。これにより、各索引データは、索引データ配列において、当該索引データに含まれる“ｆｉｒｓｔ”ノード下の“ｔｅｘｔ”ノードの値によってソートされる。そのため第２の変形例では、索引設定管理テーブル４２４に登録される索引設定情報に、結合対象パス＃１で指定される“ｆｉｒｓｔ”ノード下の“ｔｅｘｔ”ノードの値が索引データ配列において優先されることを示す情報が含まれている。
【００６８】
図１５は、図１４に示す木構造のＸＭＬ文書の登録時における上述の索引設定情報に基づく文字列結合索引作成により、索引格納部４２２に格納される索引データ配列のデータ構造例を示す。この図１５に示す索引データ配列における各索引データは、“ｎａｍｅ”ノードの位置情報と、当該“ｎａｍｅ”ノード下で対をなす“ｆｉｒｓｔ”ノード及び“ｓｅｃｏｎｄ”ノードの両ノード下の“ｔｅｘｔ”ノードの値とからなる。ここでは、“ｓｅｃｏｎｄ”ノードよりも優先順位の高い“ｆｉｒｓｔ”ノード下の“ｔｅｘｔ”ノードの値で、各索引データが例えば昇順にソートされている。また、“ｆｉｒｓｔ”ノード下の“ｔｅｘｔ”ノードの値が等しい索引データは、ｓｅｃｏｎｄ”ノード下の“ｔｅｘｔ”ノードの値に基づいて更にソートされている。
【００６９】
このため図１５に示す索引データ配列では、“ｆｉｒｓｔ”ノード下の“ｔｅｘｔ”ノードの値“ｆ１”を含む索引データが、索引データ配列における配列番号（索引データ配列番号）が小さい領域にまとまって配置され、“ｆｉｒｓｔ”ノード下の“ｔｅｘｔ”ノードの値“ｆ２”（但し、ｆ２＞ｆ１）を含む索引データが、索引データ配列における配列番号が大きい領域にまとまって配置されている。一方、“ｓｅｃｏｎｄ”ノード下の“ｔｅｘｔ”ノードの値“ｓ１”を含む索引データ、及び“ｓｅｃｏｎｄ”ノード下の“ｔｅｘｔ”ノードの値“ｓ２”を含む索引データは、索引データ配列内で分散して配置されている可能性が高い。
【００７０】
次に、図１５に示す索引（索引データ配列）を対象とする（図１０のステップＳ３５に相当する）索引検索処理の手順について図１６のフローチャートを参照して説明する。
【００７１】
まず索引管理部５４の索引検索部５６は、クライアント端末２０からの検索要求の示すクエリによって指定される目的の値を持つ索引データ配列内の索引データのうち、配列番号が最小の位置に格納されている索引データを検索して、その配列番号を変数ｉに代入する（ステップＳ４１）。次に索引検索部５６は、索引データ配列のｉ番目の要素（索引データ）が上記クエリによって指定される検索条件を満たしているかを判定する（ステップＳ４２）。
【００７２】
もし、索引データ配列のｉ番目の索引データが検索条件を満たしている場合、索引検索部５６は当該ｉ番目の索引データに含まれているノード位置情報を検索結果としてデータベースサーバ１０のメモリに格納する（ステップＳ４３）。次に索引検索部５６は、変数ｉを１インクリメントして、索引データ配列内の次の（隣接する）索引データの位置（索引データ配列番号）を指定する（ステップＳ４４）。そして索引検索部５６は、インクリメント後の変数ｉによって指定される索引データ配列内の索引データを対象に、検索条件を満たしているかを判定する（ステップＳ４２）。
【００７３】
第２の変形例においては、ｎａｍｅ”ノード下で対をなす“ｆｉｒｓｔ”ノード及び“ｓｅｃｏｎｄ”ノードのうちの“ｆｉｒｓｔ”ノードが優先され、当該“ｆｉｒｓｔ”ノード下の“ｔｅｘｔ”ノードの値で、各索引データが昇順にソートされている。このため、“ｆｉｒｓｔ”ノード下のノードの値が等しい索引データ同士は索引データ配列内で隣接している。よって、「“ｆｉｒｓｔ”下のノードの値が“ｆ１”と一致する。」あるいは「“ｆｉｒｓｔ”下のノードの値が“ｆ１”以上で且つ“ｆ２”以下である。」といった特定の検索条件の検索処理を高速に処理することができる。このような例では、索引データ配列のｉ番目の索引データが検索条件を満たしていないと判定されたならば（ステップＳ４２）、最早検索条件を満たす索引データは存在しないことから、索引検索部５６は直ちに索引検索処理を終了することができる。つまり第２の変形例においては、無用な索引検索が繰り返されるのを防止できる。
【００７４】
これに対し、「“ｓｅｃｏｎｄ”ノード下のノードの値がある文字列と一致する。」といった検索処理はヒットする索引データが索引データ配列内で分散している可能性があるため、探索範囲が広くなり高速に処理することができない。このような検索を高速化するためには、別途、“ｓｅｃｏｎｄ”ノードを“ｆｉｒｓｔ”ノードに優先させて新たな索引を設定すれば良い。
【００７５】
［第３の変形例］
次に、上記実施形態の第３の変形例について説明する。
ＸＭＬ文書によっては、ノードの構造だけでは値の型を特定できないことがある。検索条件で値の型が指定されている場合、このようなＸＭＬ文書を高速に検索することは難しい。第３の変形例の特徴は、クライアント端末２０からの索引作成要求に従う索引作成時に、ノードの値を当該要求で指定された型に変換する点にある。
【００７６】
図１７は、ノードの構造だけでは値の型を特定できないＸＭＬ文書の一例を木構造で表した図である。図１７のＸＭＬ文書では、“ｄａｔａ”ノード下に“ｔｙｐｅ”ノード及び“ｖａｌｕｅ”ノードの対が存在する。“ｔｙｐｅ”ノード下の“ｔｅｘｔ”ノードは“数量”、“品名”、“出荷日”など、種類を表す値を持つ。
【００７７】
これに対し、“ｔｙｐｅ”ノードと対をなす“ｖａｌｕｅ”ノードの下の“ｔｅｘｔ”ノードは、“ｔｙｐｅ”ノードの値に応じた値を持つ。例えば、“ｔｙｐｅ”ノード下の“ｔｅｘｔ”ノードの値が“数量”ならば“ｖａｌｕｅ”ノード下の“ｔｅｘｔ”ノードの値は整数値となる。また、“ｔｙｐｅ”ノード下の“ｔｅｘｔ”ノードの値が“品名”ならば“ｖａｌｕｅ”ノード下の“ｔｅｘｔ”ノードの値は文字列となる。同様に、“ｔｙｐｅ”ノード下の“ｔｅｘｔ”ノードの値が“出荷日”ならば“ｖａｌｕｅ”ノード下の“ｔｅｘｔ”ノードの値は日付となる。
【００７８】
図１７に示すＸＭＬ文書の特徴はノードの構造だけでは値の型を特定できないことである。つまり、パス「／ｄａｔａ／ｖａｌｕｅ」で指定される“ｖａｌｕｅ”ノード下の“ｔｅｘｔ”ノードという構造を表す情報だけでは、当該“ｔｅｘｔ”ノードの値が例えば整数値、文字列、日付のいずれの型であるか判別できない。
【００７９】
第３の変形例では、索引作成要求で、索引用の型が指定され、その型を指定する情報（型指定情報）が当該索引作成要求に応じて索引設定管理テーブル４２４に登録される索引設定情報に含められる。そして、索引設定情報に基づく索引作成時に、対象となる“ｔｅｘｔ”ノードの値が型指定情報に従って指定された型の値に変換される。
【００８０】
以下、索引管理部５４による索引作成時の型変換処理について図１８のフローチャートを参照して説明する。ここでは、クライアント端末２０からの索引作成要求で、設定パスとして「／ｄａｔａ」が指定され、結合対象パス＃１及び＃２としてそれぞれ「ｔｙｐｅ」及び「ｖａｌｕｅ」が指定され、更に“ｖａｌｕｅ”ノード下の“ｔｅｘｔ”ノードの型として整数値が指定されているものとする。
【００８１】
今、図１７に示すＸＭＬ文書の中から、結合対象パス＃２によって指定されている“ｖａｌｕｅ”ノード下のｔｅｘｔ”ノードの情報（値）が検出されたものとする。また、この“ｖａｌｕｅ”ノード下のｔｅｘｔ”ノードの値の型として、整数値、文字列及び日付のうちの整数値が指定されているものとする。なお、値の型は、この３種に限るものではなく、例えば浮動小数点なども適用可能である。
【００８２】
さて、“ｖａｌｕｅ”ノード下のｔｅｘｔ”ノードの値の型として整数値が指定されている場合、索引管理部５４は、ドキュメント管理部５２によって検出された“ｖａｌｕｅ”ノード下のｔｅｘｔ”ノードの値を、指定された型、つまり整数値に変換可能であるかを判定する（ステップＳ５１）。
【００８３】
もし、“ｖａｌｕｅ”ノードと対をなす“ｔｙｐｅ”ノードの値が「数量」である場合、“ｖａｌｕｅ”ノード下のｔｅｘｔ”ノードの値は整数値を表す文字列である。このような場合、索引管理部５４は検出された“ｖａｌｕｅ”ノード下のｔｅｘｔ”ノードの値を指定された型（つまり整数値）へ変換することが可能であると判定する（ステップＳ５１）。
【００８４】
次に索引管理部５４は、検出された“ｖａｌｕｅ”ノード下のｔｅｘｔ”ノードの値を指定された型の値に変換する（ステップＳ５２）。ここでは、整数値を示す文字列が整数値に変換される。索引管理部５４は、型変換後のｔｅｘｔ”ノードの情報（値）を索引データ配列に追加する（ステップＳ５３）。
【００８５】
これに対し、“ｖａｌｕｅ”ノード下のｔｅｘｔ”ノードの値が品名や日付を表す文字列である場合、索引管理部５４は検出された“ｖａｌｕｅ”ノード下のｔｅｘｔ”ノードの値を指定された型である整数値へ変換することができないと判定する（ステップＳ５１）。この場合、索引管理部５４は検出された“ｖａｌｕｅ”ノード下のｔｅｘｔ”ノードの情報を索引データ配列に追加するのを抑止する（ステップＳ５４）。
【００８６】
このようにして、索引データ配列には、“ｖａｌｕｅ”ノード下の“ｔｅｘｔ”ノードの値を数値（整数値）として扱う索引データのみが設定される。また、“ｖａｌｕｅ”ノードを“ｔｙｐｅ”ノードに優先させるならば、索引データ配列内では、索引データが、文字列の辞書順などではなく、“ｖａｌｕｅ”ノード下の“ｔｅｘｔ”ノードの値の数値としての大小関係に基づいて整列（ソート）される。また、索引データ内では“ｖａｌｕｅ”ノード下の“ｔｅｘｔ”ノードの値が文字列としてではなく数値（整数値）として保持される。つまり、“ｔｅｘｔ”ノードの型情報を利用して索引内部でのデータ保持方法を最適なものにできる。このため、索引データのデータ量が文字列の場合と比較して小さくなり、索引全体のデータ量を削減することができる。
【００８７】
このように整列された索引データを用いて、例えば「“ｔｙｐｅ”ノード下の“ｔｅｘｔ”ノードの値が“数量”であり、且つ、“ｖａｌｕｅ”ノード下の“ｔｅｘｔ”ノードの値が２０以上２５以下である」といった条件で検索を行うものとする。上記したように、索引データは“ｖａｌｕｅ”ノード下の“ｔｅｘｔ”ノードの値の数値としての大小関係に基づいて整列されている。このため、ヒットする索引データは索引データ配列内で近接しており、高速に検索処理を行うことができる。
【００８８】
このように第３の変形例においては、索引作成用に指定された型に基づいて、指定された型へ変換可能なノード情報のみを型変換して索引データ配列へ登録することにより、索引のデータ量を削減するとともに、検索速度を向上させることができる。更に、ノードの構造情報だけではノードの値の型を特定できないようなＸＭＬ文書の検索においても、検索速度を向上させる効果がある。
【００８９】
なお、本発明は、上記実施形態またはその変形例そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。例えば、上記実施形態またはその変形例では、構造化文書としてＸＭＬ文書を例にとって説明したが、これに限るものではない。本発明は、例えば、ＳＧＭＬ（Standard Generalized Markup Language）文書のようなＸＭＬ文書以外の構造化文書にも同様に適用できる。
【００９０】
また、上記実施形態またはその変形例では、クライアント端末２０がネットワーク３０を介して構造化文書管理システム５０のデータベースサーバ１０に接続されている。しかし、クライアント端末２０が直接に構造化文書管理システム５０のデータベースサーバ１０に接続されていても構わない。また、クライアント端末２０上で動作するのと同様のアプリケーションがデータベースサーバ１０上で動作する構成とすることにより、当該データベースサーバ１０が有するキーボード、ディスプレイ等をクライアント端末２０のように用いても、つまりデータベースサーバ１０をクライアント端末に兼用しても構わない。
【００９１】
また、上記実施形態またはその変形例に開示されている複数の構成要素の適宜な組み合せにより種々の発明を形成できる。例えば、実施形態またはその変形例に示される全構成要素から幾つかの構成要素を削除しても良い。
【図面の簡単な説明】
【００９２】
【図１】本発明の一実施形態に係る構造化文書管理システムを含むクライアント−サーバシステムのハードウェア構成を示すブロック図。
【図２】図１に示される構造化文書管理システムの主として機能構成を示すブロック図。
【図３】同実施形態における索引設定処理の手順を示すフローチャート。
【図４】２つのＸＭＬ文書の例を示す図。
【図５】図４に示される２つのＸＭＬ文書を木構造で表現した例を示す図。
【図６】索引設定管理テーブルの例を示す図であり、同図（ａ）は同実施形態で適用される索引設定管理テーブルの例を示し、同図（ｂ）は同実施形態の第１の変形例で適用される索引設定管理テーブルの例を示す。
【図７】同実施形態における文書登録処理の手順を示すフローチャート。
【図８】図６（ａ）の索引設定管理テーブルに登録されている索引設定情報に従って、図５の木構造で示される２つの文書のパス「／住所」に対して作成された索引を、当該木構造と対応付けて示す図。
【図９】同実施形態で作成される索引データ配列のデータ構造の一例を示す図。
【図１０】同実施形態における文書検索処理の手順を示すフローチャート。
【図１１】同実施形態で適用される索引作成をモデル化して示す図。
【図１２】同実施形態の第１の変形例で適用される索引作成をモデル化して示す図。
【図１３】上記第１の変形例において、図６（ｂ）の索引設定管理テーブルに登録されている索引設定情報に従って、図５の木構造で示される２つの文書のパス「／住所」に対して作成された索引を、当該木構造と対応付けて示す図。
【図１４】同実施形態の第２の変形例で適用されるＸＭＬ文書の一例を木構造で表した図。
【図１５】上記第２の変形例で作成される索引データ配列のデータ構造の一例を示す図。
【図１６】上記第２の変形例における索引検索処理の手順を示すフローチャート。
【図１７】同実施形態の第３の変形例で適用されるＸＭＬ文書の一例を木構造で表しす図。
【図１８】上記第３の変形例における索引作成時の型変換処理の手順を示すフローチャート。
【符号の説明】
【００９３】
１０…データベースサーバ、２０…クライアント端末、３０…ネットワーク、４０…外部記憶装置、４１…データベース管理プログラム、４２…ＸＭＬデータベース、５１…コマンド管理部、５２…ドキュメント管理部（タグ検出手段）、５３…検索エンジン（構造化文書検索手段）、５４…索引管理部、５５…データベース操作部、５６…索引検索部、４２１…ＸＭＬ文書格納部（構造化文書格納手段）、４２２…索引格納部、４２３…索引設定管理テーブル格納部、４２４…索引設定管理テーブル。
【技術分野】
【０００１】
本発明は、構造化文書を検索するのに用いられる索引を管理する構造化文書管理システム及びプログラムに関する。
【背景技術】
【０００２】
ＸＭＬ（Extensible Markup Language）形式の文書、つまりＸＭＬ文書に代表される構造化文書では、タグと呼ばれる文字列で階層的な構造が表現される。具体的には、１組のタグ（開始タグ及び終了タグの組）によってテキストを囲むことによって、当該テキストが構造化される。開始タグから終了タグまでの文字列はタグを含めて要素と呼ばれ、開始タグ及び終了タグで囲まれた文字列は、要素の内容と呼ばれる。構造化文書（ＸＭＬ文書）は木構造によって表現することが可能である。構造化文書の木構造において、構造化文書の要素に対応するノードは要素ノード、要素の内容（値）がテキストの場合の当該要素の内容に対応するノードはテキストノードと呼ばれる。テキストノードはテキストのみから構成される。つまりテキストノード＝テキストノードの値＝テキストである。
【０００３】
また、データベースサーバ上で動作するデータベース管理システム（Database Management System: ＤＢＭＳ）を始めとする、多数の構造化文書を管理し、大規模な検索処理を行うシステム（構造化文書管理システム）においては、例えば特許文献１または２に記載されているように、索引（インデックス）を用いて検索速度を向上させる手法が適用されている。
【０００４】
構造化文書中のデータ（値）による検索を高速化するために索引を付与する場合、検索対象となることの多い「要素ノード単位」に行われるのが一般的である。例えば、
＜住所＞
＜都道府県＞東京都＜／都道府県＞
＜市町村＞府中市武蔵台＜／市町村＞
＜番地＞一丁目一番地十五＜／番地＞
＜／住所＞
のようなデータを含むＸＭＬ文書に対して、「住所に"東京都府中市"が含まれる」という条件で検索する場合を想定する。
【０００５】
この場合、クライアント端末から構造化文書検索管理システムに対して与えられる検索要求の示す検索文字列（クエリ）は「／住所［都道府県／ｔｅｘｔ（）＝"東京都"ＡＮＤ［ｃｏｎｔａｉｎｓ（市町村／ｔｅｘｔ（），"府中市"）］」となる。このようなクエリに対するＸＭＬ文書検索を高速化するために、パス「／住所／都道府県」及びパス「／住所／市町村」でそれぞれ特定される要素ノード（＜都道府県＞タグ及び＜市町村＞タグ）に対して索引が作成・付与される。
【特許文献１】特開２０００−２０７４０９号
【特許文献１】特開２００６−１７２２６８号
【発明の開示】
【発明が解決しようとする課題】
【０００６】
しかし、要素ノード単位で作成される索引を利用してＸＭＬ文書検索の高速化を図る場合には＜住所＞タグ内に含まれるタグの自由度が制限される。例えば、図４に示される２つの文書＃１及び＃２
文書＃１：
＜住所＞
＜都道府県＞東京都＜／都道府県＞
＜市町村＞府中市武蔵台＜／市町村＞
＜番地＞一丁目一番地十五＜／番地＞
＜／住所＞
文書＃２：
＜住所＞
＜都道府県＞東京都＜／都道府県＞
＜区＞港区＜／区＞
＜市町村＞芝浦＜／市町村＞
＜番地＞一丁目一番地一＜／番地＞
＜／住所＞
に対して作成される索引を利用したＸＭＬ文書検索で、東京都に対してのみ＜市町村＞タグに加えて＜区＞タグを利用する場合を想定する。具体的には、「住所に"東京都港区芝浦"が含まれる」という条件で検索するものとする。この場合、クエリは「／住所［都道府県／ｔｅｘｔ（）＝"東京都" ＡＮＤ 区／ｔｅｘｔ（）＝"港区"ＡＮＤ［ｃｏｎｔａｉｎｓ（市町村／ｔｅｘｔ（），"芝浦"）］」となり、条件の値だけでなくクエリそのものも書き換える必要が生じる。
【０００７】
一方、ＸＭＬ文書の階層構造を指定するＸＰａｔｈと呼ばれるパス形式を用いて、例えば「／住所［ｃｏｎｔａｉｎｓ（．，"東京都港区芝浦"）］」と記述することにより、目的の検索を実現することが可能である。しかし、要素ノード単位で索引が作成される従来技術では、該当する索引が存在しないため、個々のＸＭＬ文書内をサーチして、条件に合致する文書かを確認する必要がある。このため、高速な検索を実現することは難しい。
【０００８】
また、要素ノード単位で作成された索引を利用して検索を行う場合、＜都道府県＞タグに付与された索引でヒットした結果と、＜市町村＞タグに付与された索引でヒットした結果と、＜区＞タグに付与された索引でヒットした結果が、同一文書に含まれているかどうかＡＮＤマージ処理を行う必要がある。このため、いずれか１つ、もしくは全ての索引での検索で大量のデータがヒットするようなケースでは、ＡＮＤマージ処理で検索の高速性が損なわれるおそれがある。
【０００９】
本発明は上記事情を考慮してなされたものでその目的は、複数のタグの値による検索を高速に行うのに適した索引管理を実現できる構造化文書管理システム及びプログラムを提供することにある。
【課題を解決するための手段】
【００１０】
本発明の１つの観点によれば、複数の構造化文書を管理する構造化文書管理システムが提供される。このシステムは、複数の構造化文書を格納する構造化文書格納手段と、前記構造化文書格納手段に格納されている構造化文書を検索するのに用いられる索引データを格納する索引格納手段と、文字列結合索引データの作成を指示するための外部から与えられる索引作成要求であって、作成された文字列結合索引データが付与されるタグを指定する索引作成要求に基づき、前記構造化文書格納手段に新たに格納されるまたは既に格納されている構造化文書から当該索引作成要求で指定されたタグを検出するタグ検出手段と、前記タグ検出手段によって検出されたタグを有する前記構造化文書に含まれている当該タグ以下に出現する複数のテキストノードの値を連結して索引化し、当該タグに付与される文字列結合索引データとして前記索引格納手段に格納する索引管理手段とを具備する。
【発明の効果】
【００１１】
本発明によれば、構造化文書の指定されたタグ以下に出現する複数のテキストノード、特に階層が異なる要素ノードの要素の値である複数のテキストノードの値を連結して、当該指定されたタグの索引（文字列結合索引）として管理することができる。したがって、この文字列結合索引を利用することにより、タグを跨ったデータを条件とした検索を高速化できると共に、ヒット件数が多い場合でも性能劣化を防ぐことができる。
【発明を実施するための最良の形態】
【００１２】
以下、本発明の実施の形態につき図面を参照して説明する。
図１は本発明の一実施形態に係る構造化文書管理システムを含むクライアント−サーバシステムのハードウェア構成を示すブロック図である。クライアント−サーバシステムは、主として、データベースサーバ（データベースサーバコンピュータ）１０と、複数のクライアント端末とから構成される。複数のクライアント端末はクライアント端末２０を含む。クライアント端末２０上では、データベースサーバ１０を利用するアプリケーション（アプリケーションプログラム）が動作する。クライアント端末２０を含む複数のクライアント端末は、ローカルエリアネットワーク（ＬＡＮ）のようなネットワーク３０を介してデータベースサーバ１０と接続されている。なお、図１にはクライアント端末２０以外のクライアント端末は省略されている。
【００１３】
データベースサーバ１０は、ハードディスクドライブのような外部記憶装置４０と接続されている。この外部記憶装置４０は、データベース管理プログラム４１及びＸＭＬデータベース４２を格納する。
【００１４】
データベース管理プログラム４１は、データベースサーバ１０によるＸＭＬデータベース４２の管理、及びクライアント端末からの検索要求に基づく検索処理に用いられる。ＸＭＬデータベース４２は構造化文書であるＸＭＬ文書（ＸＭＬ文書データ）を格納する構造化文書データベースである。ＸＭＬデータベース４２には、当該データベース４２に格納されるＸＭＬ文書に基づいて作成される索引等も格納される。
【００１５】
本実施形態では、データベースサーバ１０及び外部記憶装置４０によって構造化文書管理システム５０が実現される。
【００１６】
図２は構造化文書管理システム５０の主として機能構成を示すブロック図である。構造化文書管理システム５０は、ＸＭＬデータベース４２に加えて、コマンド管理部５１、ドキュメント管理部５２、検索エンジン５３、索引管理部５４及びデータベース操作部５５を含む。本実施形態において、これらの各部５１乃至５５は、図１のデータベースサーバ１０が外部記憶装置４０に格納されているデータベース管理プログラム４１を読み込んで実行することにより実現されるものとする。このプログラム４１は、コンピュータ読み取り可能な記憶媒体に予め格納して頒布可能である。また、このプログラム４１が、ネットワーク３０を介してデータベースサーバ１０にダウンロードされても構わない。
【００１７】
ＸＭＬデータベース４２には、ＸＭＬ文書格納部４２１、索引格納部４２２及び索引設定管理テーブル格納部４２３が確保されている。ＸＭＬ文書格納部４２１は、複数のＸＭＬ文書（ＸＭＬ文書データ）を格納するのに用いられる。索引格納部４２２は、ＸＭＬ文書格納部４２１に新たに格納されるまたは既に格納されているＸＭＬ文書に基づいて作成される索引（索引データ）を格納するのに用いられる。索引設定管理テーブル格納部４２３は、索引格納部４２２に格納されるべき索引の作成を管理する索引設定管理テーブル４２４を格納するのに用いられる。
【００１８】
コマンド管理部５１は、クライアント端末からネットワーク３０を介して与えられる各種のコマンド（要求）を受け付けて当該コマンドの種別を判別し、その判別結果に応じてドキュメント管理部５２、検索エンジン５３及び索引管理部５４のいずれかに当該コマンドの指定する処理を実行させる。ドキュメント管理部５２は、ＸＭＬデータベース４２内のＸＭＬ文書格納部４２１にＸＭＬ文書を登録する登録処理など、ＸＭＬ文書格納部４２１におけるＸＭＬ文書の管理を司る。
【００１９】
検索エンジン５３は、クライアント端末からの検索要求に従い、当該検索要求で指定される検索条件に合致するＸＭＬ文書をＸＭＬデータベース４２内の索引格納部４２２に格納されている索引を利用してＸＭＬ文書格納部４２１から検索する。索引管理部５４は、ＸＭＬ文書格納部４２１に格納されているＸＭＬ文書を検索するのに用いられる索引を管理する。この索引の管理は、索引の作成、作成された索引の索引格納部４２２への格納を含む。索引管理部５４は、索引格納部４２２から索引を検索する索引検索部５６を含む。なお、索引検索部５６が索引管理部５４から独立に設けられていても構わない。データベース操作部５５は、ドキュメント管理部５２、検索エンジン５３及び索引管理部５４がＸＭＬデータベース４２をアクセスするためのインタフェースとして機能する。
【００２０】
次に、本実施形態の動作について、（１）索引設定処理、（２）文書登録処理、（３）文書検索処理を例に、順に説明する。
【００２１】
（１）索引設定処理
まず、索引設定処理について図３のフローチャートを参照して説明する。
今、クライアント端末２０上では、当該端末２０から構造化文書管理システム５０を利用するためのアプリケーションが動作しているものとする。このような状態において、ユーザは構造化文書管理システム５０上で複数のテキストノードを跨った検索が必要な場合、クライアント端末２０を操作して、当該複数のテキストノードの値をそれぞれ要素の内容として含む要素ノードを下位ノードとするノード（タグ）を指定する。そしてユーザはクライアント端末２０を操作して、ＸＭＬ文書（の階層構造）上で、指定されたノード（指定ノード）以下に出現する、例えば全てのテキストノードの値（テキスト）を連結して索引（文字列結合索引）を作成することを指示する索引作成要求をクライアント端末２０から発行させる。指定ノードは、テキスト連結による索引作成の起点となると共に、作成された索引が設定（付与）されるノードである。
【００２２】
クライアント端末２０は、上述のユーザの操作を受けて、指定ノードの情報を含む索引作成要求（索引作成コマンド）をネットワーク３０を介してデータベースサーバ１０に発行する（ステップＳ１）。この索引作成要求は、データベースサーバ１０（構造化文書管理システム５０）のコマンド管理部５１で受け取られる。本実施形態では、指定ノードは、ＸＭＬ文書の階層構造上のルートノードから当該指定ノードへのパス（構造情報）によって表される。
【００２３】
コマンド管理部５１は、クライアント端末２０からの索引作成要求（つまりユーザによって指定された外部からの索引作成要求）を受け取ると、当該要求を解析する。コマンド管理部５１は、この要求（コマンド）解析結果に基づき、ドキュメント管理部５２、検索エンジン５３及び索引管理部５４の中から、当該要求を処理すべき機能部として索引管理部５４を選択し、当該索引管理部５４にクライアント端末２０からの索引作成要求を渡す（ステップＳ２）。
【００２４】
索引管理部５４は、コマンド管理部５１から渡された索引作成要求に基づき、新規の索引作成に必要な索引設定情報を生成して索引設定管理テーブル４２４に追加し、しかる後に当該索引作成要求に対する応答（例えば索引作成の正常終了通知）をコマンド管理部５１に返す（ステップＳ３）。索引設定情報は、索引作成要求によって指示された索引を作成する際に参照される情報であり、その詳細については後述する。なお、索引設定管理テーブル４２４のコピーをデータベースサーバ１０のメモリ（図示せず）上に置いて、当該索引設定管理テーブル４２４のコピー上で索引設定情報の追加登録・参照を行うならば、索引設定管理テーブル４２４へのアクセスを高速に行うことができる。
【００２５】
コマンド管理部５１は、索引管理部５４からの応答を、ネットワーク３０を介してクライアント端末２０に返す（ステップＳ４）。即ち、索引作成要求に対する応答が、索引管理部５４からクライアント端末２０に当該索引作成要求とは逆向きの経路を辿って返される。
【００２６】
図４は、ＸＭＬ文書格納部４２１に既に格納されている、或いは新たに格納される２つのＸＭＬ文書＃１及び＃２の例を示す。図５は、図４に示されるＸＭＬ文書＃１及び＃２を木構造で表現した例を示す。
【００２７】
図５において、“ｒｏｏｔ”で示されるノード５００は、ＸＭＬ文書＃１及び＃２のルート（ｒｏｏｔ）ノードである。ｒｏｏｔノードの子ノード（つまりｒｏｏｔノード下のノード）は、ＸＭＬ文書＃１及び＃２の＜住所＞タグを含む要素（つまり要素名が「住所」の要素）に対応する要素ノード５１０及び５２０である。要素ノード５１０及び５２０を、住所ノード５１０及び５２０と呼ぶこともある。図５では、ｒｏｏｔノード及び要素ノードは楕円で表され、テキストノードは矩形で表されている。
【００２８】
ノード５１０の子ノードは、ＸＭＬ文書＃１のそれぞれ＜都道府県＞タグ、＜市町村＞タグ及び＜番地＞タグを含む要素に対応する要素ノード５１１，５１２及び５１３である。要素ノード５１１，５１２及び５１３を、それぞれ都道府県ノード５１１、市町村ノード５１２及び番地ノード５１３と呼ぶこともある。
【００２９】
ノード５２０の子ノードは、ＸＭＬ文書＃２のそれぞれ＜都道府県＞タグ、＜区＞タグ、＜市町村＞タグ及び＜番地＞タグを含む要素に対応する要素ノード５２１，５２２，５２３及び５２４である。要素ノード５２１，５２２，５２３及び５２４を、それぞれ都道府県ノード５２１、区ノード５２２、市町村ノード５２３及び番地ノード５２４と呼ぶこともある。
【００３０】
ノード５１１，５１２及び５１３の子ノードは、それぞれ＜都道府県＞タグ、＜市町村＞タグ及び＜番地＞タグを含む要素の内容（値）であるテキスト「東京都」，「府中市武蔵台」及び「一丁目一番地十五」に対応するテキストノード５１１Ｔ，５１２Ｔ及び５１３Ｔである。ノード５２１，５２２，５２３及び５２４の子ノードは、それぞれ＜都道府県＞タグ、＜区＞タグ、＜市町村＞タグ及び＜番地＞タグを含む要素の内容であるテキスト「東京都」，「港区」，「芝浦」及び「一丁目一番地一」に対応するテキストノード５２１Ｔ，５２２Ｔ，５２３Ｔ及び５２４Ｔである。
【００３１】
本実施形態において、索引作成要求で指定されたノード（指定ノード）が＜住所＞タグを含む要素に対応する要素ノード５１０及び５２０であるものとする。この要素ノード５１０及び５２０へのパスは、「／住所」で表される。パス「／住所」に含まれている「／」は、この例のようにパスの先頭に位置している場合、ｒｏｏｔノードを示す。
【００３２】
図６（ａ）は、索引作成要求で指定されたノード（指定ノード）へのパスが「／住所」の場合に、索引管理部５４による索引設定情報追加後の索引設定管理テーブル４２４の一例を示す。この索引設定管理テーブル４２４の各エントリの情報（索引設定情報）は、図６（ａ）に示すように、設定パス及び索引種別の情報を含む。ここでは、設定パスとして指定ノードへのパス「／住所」を、索引種別として「文字列結合索引」をそれぞれ含む索引設定情報が索引設定管理テーブル４２４に格納されている。「文字列結合索引」とは、索引設定情報に当該「文字列結合索引」と対をなして設定されているパスによって指定されるノード（タグ）以下に出現する複数のテキストノードの値（テキスト）を出現順に連結することによって作成される索引である。本実施形態では、設定索引設定管理テーブル４２４に登録されている索引設定情報（中の索引種別）によって示される種別の索引は、次に述べるようにＸＭＬ文書の登録時に作成される。
【００３３】
（２）文書登録処理、
次に、文書登録処理について図７のフローチャートを参照して説明する。
今、ユーザによるクライアント端末２０の操作に従い、当該端末２０からデータベースサーバ１０に対して新たにＸＭＬ文書を登録することを指示する文書登録要求（文書登録コマンド）が発行されたものとする（ステップＳ１１）。この登録要求は、データベースサーバ１０（構造化文書管理システム５０）のコマンド管理部５１で受け取られる。
【００３４】
コマンド管理部５１は、クライアント端末２０からの文書登録要求を受け取ると、当該要求を解析する。コマンド管理部５１は、この要求（コマンド）解析結果に基づき、当該要求を処理すべき機能部としてドキュメント管理部５２を選択し、当該ドキュメント管理部５２にクライアント端末２０からの文書登録要求を渡す（ステップＳ１２）。
【００３５】
ドキュメント管理部５２は、コマンド管理部５１から渡された文書登録要求に従い、当該要求で指定された新たに登録されるべきＸＭＬ文書を先頭から順に解析しながら（ステップＳ１３）、索引設定管理テーブル４２４に登録されている索引設定情報中の設定パスで指定されるタグを含む要素（要素ノード）を検出するタグ検出手段として機能する。そしてドキュメント管理部５２は、解析された情報が、上記設定パスで指定される要素、つまり索引の付与（設定）が指定されている要素（要素ノード）であるかをチェックする（ステップＳ１４）。もし、解析された情報が索引の付与が指定されている要素中の情報（開始タグ、テキスト、終了タグ等）であるならば（ステップＳ１４）、ドキュメント管理部５２は、索引設定管理テーブル４２４に登録されている索引設定情報のうち、その要素へのパスの情報を含む索引設定情報から索引種別情報を取り出して、当該索引種別情報が「文字列結合索引」を示しているかを判定する（ステップＳ１５）。
【００３６】
もし、索引種別情報が「文字列結合索引」を示していないならば、ドキュメント管理部５２は解析された情報に対して通常の処理（従来と同様の処理）を行う。これに対して、索引種別情報が「文字列結合索引」を示しているならば、ドキュメント管理部５２は解析された情報の種類、即ち解析された情報が開始タグ（索引の付与が指定されている要素の開始タグ）、テキストまたは終了タグ（索引の付与が指定されている要素の終了タグ）のいずれであるかを判別する（ステップＳ１６）
解析された情報が開始タグの場合、ドキュメント管理部５２は文字列連結を開始する（ステップＳ１７）。解析された情報がテキストの場合、ドキュメント管理部５２は当該テキスト（文字列）を例えばデータベースサーバ１０のメモリに確保されている文字列連結領域内で連結する処理を実行する（ステップＳ１８）。解析された情報が終了タグの場合、ドキュメント管理部５２は索引管理部５４を起動して、その時点において文字列連結領域内で連結されている文字列による索引化を当該索引管理部５４に行わせる（ステップＳ１９）。
【００３７】
このように本実施形態においては、クライアント端末２０からの索引作成要求で指定されたノード（タグ）を含むＸＭＬ文書の登録時に、当該指定されたノード（指定ノード）へのパスの情報を含む索引設定情報に基づき、当該ＸＭＬ文書の指定ノード（パス）に対して索引（文字列結合索引）が作成される。この索引設定情報に基づいて索引を作成することは、当該索引設定情報の生成に用いられた索引作成要求に基づいて索引を作成することと等価である。但し本実施形態のように、索引設定情報に基づいて索引を作成する手法を適用することにより、クライアント端末２０からの索引作成要求を記憶しておき、新たにＸＭＬ文書を登録する毎に当該索引作成要求を解析して、その解析結果に基づいて索引を作成する手法と比べて、索引作成の高速化を図ることができる。
【００３８】
なお、ＸＭＬ文書格納部４２１に既に登録されているＸＭＬ文書（例えばユーザによって指定された既登録のＸＭＬ文書）を対象に、当該ＸＭＬ文書の指定ノード（パス）に対して索引の作成が行われても良い。即ち、ユーザの操作に応じてクライアント端末２０からデータベースサーバ１０（構造化文書管理システム５０）に対して既登録のＸＭＬ文書を指定して、当該指定されたＸＭＬ文書の指定ノード（パス）に対して索引の作成を行わせることも可能である。
【００３９】
ドキュメント管理部５２は、ステップＳ１７，Ｓ１８またはＳ１９が実行されるとステップＳ２０に進む。ドキュメント管理部５２はまた、解析された情報が索引作成が指定されている要素中の情報でないと判定された場合（ステップＳ１４）にもステップＳ２０に進む。このステップＳ２０において、ドキュメント管理部５２は、解析された情報をＸＭＬデータベース４２のＸＭＬ文書格納部４２１に格納するドキュメント格納処理を実行する。
【００４０】
ドキュメント管理部５２は、ステップＳ２０を実行すると、クライアント端末２０からの文書登録要求で指定されたＸＭＬ文書（ドキュメント）の登録が終了したかを判定する（ステップＳ２１）。もし、指定されたＸＭＬ文書の登録が終了していないならば、ドキュメント管理部５２はステップＳ１４に戻り、指定されたＸＭＬ文書中の次に解析された情報が索引作成が指定されている要素中の情報であるかを判定する。以下、同様にして、ドキュメント管理部５２は索引作成が指定されている要素中の開始タグを判別した後、当該要素中の終了タグを判別するまでの間に現れる文字列（テキスト）を出現順に全て連結する。そして索引作成が指定されている要素中の終了タグが判別されると、その時点までに連結されている文字列が索引管理部５４によって索引化される（ステップＳ１９）。この索引化によって作成される文字列結合索引（索引データ）は索引格納部４２２に格納される。この文字列結合索引は、索引促成要求によって指定されたノード（要素ノード）に対する（付与される）索引として管理される。索引の形式として例えばＢ木またはハッシュが適用可能であるが、他の形式でも構わない。
【００４１】
ドキュメント管理部５２は、指定されたＸＭＬ文書の登録処理を終了（完了）すると（ステップＳ２１）、文書登録要求に対する応答（例えば文書登録の正常終了通知）をコマンド管理部５１に返す（ステップＳ２２）。コマンド管理部５１は、ドキュメント管理部５２からの応答を、ネットワーク３０を介してクライアント端末２０に返す（ステップＳ２３）。即ち、文書登録要求に対する応答が、ドキュメント管理部５２からクライアント端末２０に当該索引作成要求とは逆向きの経路を辿って返される。
【００４２】
図８は、図６（ａ）の索引設定管理テーブル４２４に登録されている「パス＝／住所」及び「索引種別＝文字列結合」を指定する索引設定情報に従って、図５の木構造で示される２つの文書＃１及び＃２（図４参照）のパス「／住所」に対して作成された索引（文字列結合索引）を、当該木構造と対応付けて示す。
【００４３】
図８から明らかなように、文書＃１のパス「／住所」で指定される要素名が「住所」の要素ノード（つまり、「住所」ノードまたは＜住所＞タグ）以下のテキストノードは、テキストノード５１１Ｔ，５１２Ｔ及び５１３Ｔであり、その値（テキスト）は、それぞれ「東京都」，「府中市武蔵台」及び「一丁目一番地十五」である。この場合、図８に示されるように、これらのテキスト（文字列）が全て連結された索引（文字列結合索引）５３０が、パス「／住所」（「住所」ノードまたは＜住所＞タグ）に対する索引として作成される。
【００４４】
同様に、文書＃１のパス「／住所」で指定される要素名が「住所」の要素ノード（つまり、「住所」ノードまたは＜住所＞タグ）以下のテキストノードは、テキストノード５２１Ｔ，５２２Ｔ，５２３Ｔ及び５２４Ｔであり、その値（テキスト）は、それぞれ「東京都」，「港区」，「芝浦」及び「一丁目一番地一」である。この場合、図８に示されるように、これらのテキスト（文字列）が全て連結された索引（文字列結合索引）５４０がパス「／住所」（「住所」ノードまたは＜住所＞タグ）に対する索引として作成される。
【００４５】
図９は、作成された文字列結合索引（索引データ）の索引格納部４２２における配列（索引データ配列）のデータ構造の一例を示す。図９に示す索引データ配列内の各索引データは、ノード位置、都道府県ノード下のノード（都道府県ノードの子ノード）の値（テキスト）、区ノード下のノードの値、市町村ノード下のノードの値及び番地ノード下のノードの値の各情報から構成される。ノード位置の情報は、ＸＭＬ文書格納部４２１に格納されている該当するＸＭＬ文書中のノード、即ち索引設定管理テーブル４２４に登録されている索引設定情報中のパスによって指定されるノード（タグ）の格納位置、例えばＸＭＬ文書格納部４２１における相対的な格納位置を示す。
【００４６】
索引データを構成する各ノードの値（テキスト）は、都道府県ノード下のノード、区ノード下のノード、市町村ノード下のノード及び番地ノード下のノードの順番で連結される。但し、文書＃１に関しては、区ノード下のノードの値は存在しないため、都道府県ノード下のノード、市町村ノード下のノード及び番地ノード下のノードの順番で連結される。
【００４７】
（３）文書検索処理
次に、文書検索処理について図１０のフローチャートを参照して説明する。
今、ユーザによるクライアント端末２０の操作に従い、当該端末２０からデータベースサーバ１０に対してＸＭＬ文書を検索することを指示する検索要求が発行されたものとする（ステップＳ３１）。この検索要求は、データベースサーバ１０（構造化文書管理システム５０）のコマンド管理部５１で受け取られる。
【００４８】
コマンド管理部５１は、クライアント端末２０からの検索要求を受け取ると、当該要求を解析する。コマンド管理部５１は、この要求解析結果に基づき、当該要求を処理すべき機能部として検索エンジン５３を選択し、当該検索エンジン５３にクライアント端末２０からの検索要求を渡す（ステップＳ３２）。
【００４９】
検索エンジン５３は、コマンド管理部５１から渡された検索要求の示す検索文字列（クエリ、検索条件）を解析して（ステップＳ３３）、文字列結合索引が付与されている要素ノード（タグ）への、当該要素ノード（タグ）を跨ったデータでの検索が含まれるかを判定する（ステップＳ３４）。検索エンジン５３は、この条件に合致していると判定した場合、索引管理部５４の索引検索部５６に対して、該当する要素ノードに付与された索引（文字列結合索引）を検索させる（ステップＳ３５）。これに対し、上記の条件に合致しない検索要求の場合、検索エンジン５３は通常の検索処理を実行する（ステップＳ３６）。
【００５０】
索引管理部５４の索引検索部５６に文字列結合索引を検索させた場合、その検索の結果は、当該索引検索部５６から検索エンジン５３に返される。検索エンジン５３は、索引検索部５６による文字列結合索引の検索結果を取得すると、当該文字列結合索引に従ってＸＭＬ文書格納部４２１に格納されているＸＭＬ文書を検索して、そのＸＭＬ文書検索結果を取得する（ステップＳ３７）。コマンド管理部５１は、検索エンジン５３によって取得されたＸＭＬ文書検索結果を受け取って、クライアント端末２０に返す（ステップＳ３８）。
【００５１】
さて、本実施形態で適用される文字列結合索引の作成手法によれば、その作成原理から明らかなように、従来技術においてＸＭＬ文書の末端の要素ノード単位で作成される索引を検索した際に、当該末端の要素ノードに付与された索引でヒットした結果が同一文書に含まれているかどうかを確認するためのＡＮＤマージ処理に相当する処理が、既に文字列結合索引作成時に実行されていることと等価である。したがって、本実施形態のように、索引管理部５４の索引検索部５６によって検索された文字列結合索引を用いてＸＭＬ文書を検索することにより、ＡＮＤマージ処理が不要となるため、ヒット件数が多い場合でも性能劣化を防ぐことができる。
【００５２】
ここで、文字列結合索引を用いたＸＭＬ文書検索の具体例について説明する。ここでは検索要求で示されるクエリとして、「／住所［ｃｏｎｔａｉｎｓ（．，"東京都港区芝浦"）］」が用いられるものとする。この場合、図９の索引データ配列の例では、"東京都港区芝浦"を含む文字列結合索引「東京都港区芝浦一丁目一番地一」及び文書＃２の住所ノード（住所タグ）の位置（ＸＭＬ文書格納部４２１内の位置）が、索引検索部５６によって取得される。文字列結合索引「東京都港区芝浦一丁目一番地一」は、文書＃２の住所ノード以下に出現する全てのテキストノードの値（テキスト）を出現順に結合することによって作成されたものである。したがって、文書＃２の住所ノード（住所タグ）の位置は、「住所に"東京都港区芝浦"が含まれる」ＸＭＬ文書（文書＃２）の住所ノード（住所タグ）を特定する。検索エンジン５３は、この住所ノードの位置から「住所に"東京都港区芝浦"が含まれる」ＸＭＬ文書を検索することができる。
【００５３】
上述したように本実施形態においては、ＸＭＬ文書で指定ノード以下に出現する全てのテキストノードの値（テキスト）を連結して索引（文字列結合索引）が作成される。図１１はこの索引作成をモデル化して示す。図１１において、Ａ，Ｂ，Ｃ，Ｄ，Ｅ及びＸは、あるＸＭＬ文書を木構造で表した場合の要素ノード（タグ）を示し、文字列「ああ」、「いい」、「うう」、「ええ」及び「おお」は、それぞれ要素ノードＤ，Ｄ，Ｄ，Ｅ及びＸの要素の値（に対応するテキストノードの値）を示す。楕円で囲まれた要素ノードＡは、文字列結合索引が付与されるノード（指定ノード）である。図１１の例では、ノードＡ以下に出現する全てのテキスト（文字列）「ああ」、「いい」、「うう」、「ええ」及び「おお」を連結することによって文字列結合索引が作成される。
【００５４】
［第１の変形例］
次に、上記実施形態の第１の変形例について説明する。
上記実施形態では、指定ノード（タグ）以下に出現する全てのテキストノード（の値）が連結される。しかし、一部のテキストノードだけを検索条件として利用するような場合、その部分だけを索引化することにより、索引のボリュームが削減され、つまり外部記憶装置４０の記憶領域の中で索引格納部４２２の占める領域が少なくて済み、且つ検索の高速化が期待される。そこで第１の変形例の特徴は、指定ノード以下に出現する全てのテキストノードのうちの一部の複数のテキストノード（の値）だけを連結して索引化する点にある。
【００５５】
図１２は第１の変形例で適用される索引作成をモデル化して示す。図１２には、図１１と同一の木構造が示されている。図１２の例では、要素ノードＤ，Ｄ，Ｄ，Ｅ及びＸのうち、矩形で囲まれた要素ノードＤ，Ｄ及びＤの要素の値（に対応するテキストノードの値）である、文字列「ああ」、「いい」及び「うう」だけを連結することによって、要素ノード（タグ）Ａの索引（文字列結合索引）が作成される。
【００５６】
第１の変形例では、このような文字列結合索引の作成のために、クライアント端末２０から構造化文書管理システム５０に与えられる索引作成要求により、指定ノード（タグ）を指し示す要素ノードＡへのパス（設定パス）に加えて、指定ノード（タグ）以下に出現する全てのテキストノードのうち、索引化（結合）されるべきテキストノードが指定される。ここでは、指定ノードから索引化されるべきテキストノードの親ノードへの相対パス（結合対象パス）によって、索引化されるべきテキストノードが指定される。
【００５７】
図１２の例では、索引作成要求により、設定パスとして要素ノードＡへのパスが指定されると共に、結合対象パスとして、当該要素ノードＡからの相対パス「Ｂ／Ｃ／Ｄ」が指定される。索引管理部５４は、この索引作成要求を受けた場合、ノードＡ以下に出現する全てのテキストノードのうち、当該ノードＡからの相対パス「Ｂ／Ｃ／Ｄ」によって示されるノード下のテキストノードが、索引化（結合）されるべきテキストノードとして指定されているものと判断する。そして索引管理部５４は、索引設定管理テーブル４２４に索引作成要求に対応する索引設定情報を登録する（図３ステップＳ３）。
【００５８】
第１の変形例では、最大２個の結合対象パスが指定可能であるものとする。そこで、索引設定管理テーブル４２４に登録される索引設定情報は、図６（ａ）に示す設定パス及び索引種別の情報に加えて、２つの結合対象パス＃１及び＃２の情報を含む。結合対象パスとして「Ｂ／Ｃ／Ｄ」が指定されている上記の例では、設定パスとして指定ノードＡへのパスが、索引種別として「文字列結合索引」が、そして例えば結合対象パス＃１として「Ｂ／Ｃ／Ｄ」がそれぞれ設定された索引設定情報が、索引管理部５４によって索引設定管理テーブル４２４に登録される。ドキュメント管理部５２は、この索引設定情報に基づき、索引種別が文字列結合索引の場合には、設定パスで指定されるノードＡ以下に出現する全てのテキストノードのうち、結合対象パス＃１、つまりノードＡからの相対パス「Ｂ／Ｃ／Ｄ」によって示されるノード下のテキストノード（の値）だけを連結することができる。第１の変形例における連結の順番は、結合対象パス＃１によって示されるノード下のテキストノード→結合対象パス＃２によって示されるノード下のテキストノードとなる。１つの結合対象パス＃ｉ（ｉ＝１，２）によって複数のノードが示される場合、そのノード下のテキストノードを連結する順番は、出現順となる。
【００５９】
次に、索引作成要求により、要素ノードＤ下のテキストノードに加えて、要素ノードＥ下のテキストノードも索引化されるべきテキストノードとすることが指定されているものとする。この場合、設定パスとして指定ノードＡへのパスが、索引種別として「文字列結合索引」が、結合対象パス＃１として「Ｂ／Ｃ／Ｄ」が、そして結合対象パス＃２として「Ｂ／Ｃ／Ｅ」がそれぞれ設定された索引設定情報が、索引管理部５４によって索引設定管理テーブル４２４に登録される。ドキュメント管理部５２は、この索引設定情報に基づき、索引種別が文字列結合索引の場合、設定パスで指定されるノードＡ以下に出現する全てのテキストノードのうち、結合対象パス＃１、つまりノードＡからの相対パス「Ｂ／Ｃ／Ｄ」によって示されるノード下のテキストノード、及び結合対象パス＃２、つまりノードＡからの相対パス「Ｂ／Ｃ／Ｅ」によって示されるノード下のテキストノードだけを連結することができる。
【００６０】
もし、索引作成要求により、上記実施形態のようにノードＡ以下に出現する全てのテキストノードを索引化することが指定されている場合、索引管理部５４は索引設定情報の結合対象パス＃１及び＃２の欄に何も設定しない。この場合、ドキュメント管理部５２は、索引設定情報により結合対象パス＃１及び＃２が指定されていないとして、上記実施形態と同様に、設定パスで指定されるノードＡ以下に出現する全てのテキストノード（の値）を連結する。
【００６１】
図６（ｂ）は、第１の変形例で適用される索引設定管理テーブル４２４の一例を示す。この図６（ｂ）に示す索引設定管理テーブル４２４の各エントリの情報（索引設定情報）は、設定パス及び索引種別の情報に加えて、結合対象パス＃１及び＃２の情報を含む。図６（ｂ）において、設定パス及び索引種別としてそれぞれ「／住所」及び「文字列結合索引」が設定されている索引設定情報には、結合対象パス＃１及び＃２としてそれぞれ「住所ノードからの相対パス「都道府県」及び「市町村」が設定されている。
【００６２】
ドキュメント管理部５２は例えばＸＭＬ文書の登録特に、上述の索引設定情報に基づき、設定パス「／住所」で指定される住所ノード以下に出現する全てのテキストのうち、結合対象パス＃１及び＃２として索引設定情報に設定されている住所ノードからの相対パス「都道府県」及び「市町村」によってそれぞれ指定される都道府県ノード及び市町村ノードの値（つまり都道府県ノード下のテキストノードの値であるテキスト及び市町村ノード下のテキストノードの値であるテキスト）を結合する。
【００６３】
図１３は、図５の木構造で示される文書＃１及び＃２の登録時に、図６（ｂ）の索引設定管理テーブル４２４に登録されている上述の索引設定情報に基づいて、パス「／住所」に対して作成された索引（文字列結合索引）を当該木構造と対応付けて示す。ここでは、文書＃１に関しては、「住所」ノード以下に出現するテキストの値のうち、都道府県ノードの値「東京都」と市町村ノードの値「府中市武蔵台」とが連結された索引５３１が「住所」ノードに対する索引として作成される。同様に、文書＃２に関しては、「住所」ノード以下に出現するテキストの値のうち、都道府県ノードの値「東京都」と市町村ノードの値「芝浦」とが連結された索引５４１が「住所」ノードに対する索引として作成される。
【００６４】
なお、索引設定情報に含められる結合対象パスの数は２個に限るものではなく、Ｎを１以上の任意の整数であるとすると、Ｎ個としても良い。
【００６５】
［第２の変形例］
次に上記実施形態の第２の変形例について説明する。この第２の変形例の特徴は、クライアント端末２０からの索引作成要求により、索引化の対象となるテキストノードの優先順位（連結する順序）が指定されている場合に、その指定された優先順位に基づいて索引化の対象となるテキストノードを順序付けして管理する点にある。
【００６６】
図１４は、ＸＭＬ文書の一例を木構造で表した図である。図中の楕円または矩形はそれぞれノードを表している。楕円で表されたノードには名前があり、楕円の中に書かれた“ｒｏｏｔ”などの文字列はノード名である。一方、図中の矩形で示した末端のノードは、そのノードの親ノード（要素ノード）の要素の値（“ｆ１”などの値）を持つテキストノードであり、“ｔｅｘｔ”という固定ノード名を持つ。図１４に示すＸＭＬ文書の例では、ノード名が“ｎａｍｅ”のノード下、つまり“ｎａｍｅ”ノード下に、“ｆｉｒｓｔ”ノード及び“ｓｅｃｏｎｄ”ノードの対が存在する。
【００６７】
第２の変形例では、索引設定管理テーブル４２４に、設定パスとして“ｎａｍｅ”ノードへのパス（／ｎａｍｅ）を含み、索引種別として文字列結合索引を示す情報を含む索引設定情報が登録されているものとする。この索引設定情報は、結合対象パス＃１及び＃２として、それぞれ“ｎａｍｅ”ノードからの相対パス「ｆｉｒｓｔ」及び「ｓｅｃｏｎｄ」を含むものとする。第２の変形例では、作成される文字列結合索引データの配列（索引データ配列）において、結合対象パス＃１で指定される“ｆｉｒｓｔ”ノード下の“ｔｅｘｔ”ノードの値が、結合対象パス＃２で指定される“ｓｅｃｏｎｄ”ノード下の“ｔｅｘｔ”ノードの値よりも優先される。これにより、各索引データは、索引データ配列において、当該索引データに含まれる“ｆｉｒｓｔ”ノード下の“ｔｅｘｔ”ノードの値によってソートされる。そのため第２の変形例では、索引設定管理テーブル４２４に登録される索引設定情報に、結合対象パス＃１で指定される“ｆｉｒｓｔ”ノード下の“ｔｅｘｔ”ノードの値が索引データ配列において優先されることを示す情報が含まれている。
【００６８】
図１５は、図１４に示す木構造のＸＭＬ文書の登録時における上述の索引設定情報に基づく文字列結合索引作成により、索引格納部４２２に格納される索引データ配列のデータ構造例を示す。この図１５に示す索引データ配列における各索引データは、“ｎａｍｅ”ノードの位置情報と、当該“ｎａｍｅ”ノード下で対をなす“ｆｉｒｓｔ”ノード及び“ｓｅｃｏｎｄ”ノードの両ノード下の“ｔｅｘｔ”ノードの値とからなる。ここでは、“ｓｅｃｏｎｄ”ノードよりも優先順位の高い“ｆｉｒｓｔ”ノード下の“ｔｅｘｔ”ノードの値で、各索引データが例えば昇順にソートされている。また、“ｆｉｒｓｔ”ノード下の“ｔｅｘｔ”ノードの値が等しい索引データは、ｓｅｃｏｎｄ”ノード下の“ｔｅｘｔ”ノードの値に基づいて更にソートされている。
【００６９】
このため図１５に示す索引データ配列では、“ｆｉｒｓｔ”ノード下の“ｔｅｘｔ”ノードの値“ｆ１”を含む索引データが、索引データ配列における配列番号（索引データ配列番号）が小さい領域にまとまって配置され、“ｆｉｒｓｔ”ノード下の“ｔｅｘｔ”ノードの値“ｆ２”（但し、ｆ２＞ｆ１）を含む索引データが、索引データ配列における配列番号が大きい領域にまとまって配置されている。一方、“ｓｅｃｏｎｄ”ノード下の“ｔｅｘｔ”ノードの値“ｓ１”を含む索引データ、及び“ｓｅｃｏｎｄ”ノード下の“ｔｅｘｔ”ノードの値“ｓ２”を含む索引データは、索引データ配列内で分散して配置されている可能性が高い。
【００７０】
次に、図１５に示す索引（索引データ配列）を対象とする（図１０のステップＳ３５に相当する）索引検索処理の手順について図１６のフローチャートを参照して説明する。
【００７１】
まず索引管理部５４の索引検索部５６は、クライアント端末２０からの検索要求の示すクエリによって指定される目的の値を持つ索引データ配列内の索引データのうち、配列番号が最小の位置に格納されている索引データを検索して、その配列番号を変数ｉに代入する（ステップＳ４１）。次に索引検索部５６は、索引データ配列のｉ番目の要素（索引データ）が上記クエリによって指定される検索条件を満たしているかを判定する（ステップＳ４２）。
【００７２】
もし、索引データ配列のｉ番目の索引データが検索条件を満たしている場合、索引検索部５６は当該ｉ番目の索引データに含まれているノード位置情報を検索結果としてデータベースサーバ１０のメモリに格納する（ステップＳ４３）。次に索引検索部５６は、変数ｉを１インクリメントして、索引データ配列内の次の（隣接する）索引データの位置（索引データ配列番号）を指定する（ステップＳ４４）。そして索引検索部５６は、インクリメント後の変数ｉによって指定される索引データ配列内の索引データを対象に、検索条件を満たしているかを判定する（ステップＳ４２）。
【００７３】
第２の変形例においては、ｎａｍｅ”ノード下で対をなす“ｆｉｒｓｔ”ノード及び“ｓｅｃｏｎｄ”ノードのうちの“ｆｉｒｓｔ”ノードが優先され、当該“ｆｉｒｓｔ”ノード下の“ｔｅｘｔ”ノードの値で、各索引データが昇順にソートされている。このため、“ｆｉｒｓｔ”ノード下のノードの値が等しい索引データ同士は索引データ配列内で隣接している。よって、「“ｆｉｒｓｔ”下のノードの値が“ｆ１”と一致する。」あるいは「“ｆｉｒｓｔ”下のノードの値が“ｆ１”以上で且つ“ｆ２”以下である。」といった特定の検索条件の検索処理を高速に処理することができる。このような例では、索引データ配列のｉ番目の索引データが検索条件を満たしていないと判定されたならば（ステップＳ４２）、最早検索条件を満たす索引データは存在しないことから、索引検索部５６は直ちに索引検索処理を終了することができる。つまり第２の変形例においては、無用な索引検索が繰り返されるのを防止できる。
【００７４】
これに対し、「“ｓｅｃｏｎｄ”ノード下のノードの値がある文字列と一致する。」といった検索処理はヒットする索引データが索引データ配列内で分散している可能性があるため、探索範囲が広くなり高速に処理することができない。このような検索を高速化するためには、別途、“ｓｅｃｏｎｄ”ノードを“ｆｉｒｓｔ”ノードに優先させて新たな索引を設定すれば良い。
【００７５】
［第３の変形例］
次に、上記実施形態の第３の変形例について説明する。
ＸＭＬ文書によっては、ノードの構造だけでは値の型を特定できないことがある。検索条件で値の型が指定されている場合、このようなＸＭＬ文書を高速に検索することは難しい。第３の変形例の特徴は、クライアント端末２０からの索引作成要求に従う索引作成時に、ノードの値を当該要求で指定された型に変換する点にある。
【００７６】
図１７は、ノードの構造だけでは値の型を特定できないＸＭＬ文書の一例を木構造で表した図である。図１７のＸＭＬ文書では、“ｄａｔａ”ノード下に“ｔｙｐｅ”ノード及び“ｖａｌｕｅ”ノードの対が存在する。“ｔｙｐｅ”ノード下の“ｔｅｘｔ”ノードは“数量”、“品名”、“出荷日”など、種類を表す値を持つ。
【００７７】
これに対し、“ｔｙｐｅ”ノードと対をなす“ｖａｌｕｅ”ノードの下の“ｔｅｘｔ”ノードは、“ｔｙｐｅ”ノードの値に応じた値を持つ。例えば、“ｔｙｐｅ”ノード下の“ｔｅｘｔ”ノードの値が“数量”ならば“ｖａｌｕｅ”ノード下の“ｔｅｘｔ”ノードの値は整数値となる。また、“ｔｙｐｅ”ノード下の“ｔｅｘｔ”ノードの値が“品名”ならば“ｖａｌｕｅ”ノード下の“ｔｅｘｔ”ノードの値は文字列となる。同様に、“ｔｙｐｅ”ノード下の“ｔｅｘｔ”ノードの値が“出荷日”ならば“ｖａｌｕｅ”ノード下の“ｔｅｘｔ”ノードの値は日付となる。
【００７８】
図１７に示すＸＭＬ文書の特徴はノードの構造だけでは値の型を特定できないことである。つまり、パス「／ｄａｔａ／ｖａｌｕｅ」で指定される“ｖａｌｕｅ”ノード下の“ｔｅｘｔ”ノードという構造を表す情報だけでは、当該“ｔｅｘｔ”ノードの値が例えば整数値、文字列、日付のいずれの型であるか判別できない。
【００７９】
第３の変形例では、索引作成要求で、索引用の型が指定され、その型を指定する情報（型指定情報）が当該索引作成要求に応じて索引設定管理テーブル４２４に登録される索引設定情報に含められる。そして、索引設定情報に基づく索引作成時に、対象となる“ｔｅｘｔ”ノードの値が型指定情報に従って指定された型の値に変換される。
【００８０】
以下、索引管理部５４による索引作成時の型変換処理について図１８のフローチャートを参照して説明する。ここでは、クライアント端末２０からの索引作成要求で、設定パスとして「／ｄａｔａ」が指定され、結合対象パス＃１及び＃２としてそれぞれ「ｔｙｐｅ」及び「ｖａｌｕｅ」が指定され、更に“ｖａｌｕｅ”ノード下の“ｔｅｘｔ”ノードの型として整数値が指定されているものとする。
【００８１】
今、図１７に示すＸＭＬ文書の中から、結合対象パス＃２によって指定されている“ｖａｌｕｅ”ノード下のｔｅｘｔ”ノードの情報（値）が検出されたものとする。また、この“ｖａｌｕｅ”ノード下のｔｅｘｔ”ノードの値の型として、整数値、文字列及び日付のうちの整数値が指定されているものとする。なお、値の型は、この３種に限るものではなく、例えば浮動小数点なども適用可能である。
【００８２】
さて、“ｖａｌｕｅ”ノード下のｔｅｘｔ”ノードの値の型として整数値が指定されている場合、索引管理部５４は、ドキュメント管理部５２によって検出された“ｖａｌｕｅ”ノード下のｔｅｘｔ”ノードの値を、指定された型、つまり整数値に変換可能であるかを判定する（ステップＳ５１）。
【００８３】
もし、“ｖａｌｕｅ”ノードと対をなす“ｔｙｐｅ”ノードの値が「数量」である場合、“ｖａｌｕｅ”ノード下のｔｅｘｔ”ノードの値は整数値を表す文字列である。このような場合、索引管理部５４は検出された“ｖａｌｕｅ”ノード下のｔｅｘｔ”ノードの値を指定された型（つまり整数値）へ変換することが可能であると判定する（ステップＳ５１）。
【００８４】
次に索引管理部５４は、検出された“ｖａｌｕｅ”ノード下のｔｅｘｔ”ノードの値を指定された型の値に変換する（ステップＳ５２）。ここでは、整数値を示す文字列が整数値に変換される。索引管理部５４は、型変換後のｔｅｘｔ”ノードの情報（値）を索引データ配列に追加する（ステップＳ５３）。
【００８５】
これに対し、“ｖａｌｕｅ”ノード下のｔｅｘｔ”ノードの値が品名や日付を表す文字列である場合、索引管理部５４は検出された“ｖａｌｕｅ”ノード下のｔｅｘｔ”ノードの値を指定された型である整数値へ変換することができないと判定する（ステップＳ５１）。この場合、索引管理部５４は検出された“ｖａｌｕｅ”ノード下のｔｅｘｔ”ノードの情報を索引データ配列に追加するのを抑止する（ステップＳ５４）。
【００８６】
このようにして、索引データ配列には、“ｖａｌｕｅ”ノード下の“ｔｅｘｔ”ノードの値を数値（整数値）として扱う索引データのみが設定される。また、“ｖａｌｕｅ”ノードを“ｔｙｐｅ”ノードに優先させるならば、索引データ配列内では、索引データが、文字列の辞書順などではなく、“ｖａｌｕｅ”ノード下の“ｔｅｘｔ”ノードの値の数値としての大小関係に基づいて整列（ソート）される。また、索引データ内では“ｖａｌｕｅ”ノード下の“ｔｅｘｔ”ノードの値が文字列としてではなく数値（整数値）として保持される。つまり、“ｔｅｘｔ”ノードの型情報を利用して索引内部でのデータ保持方法を最適なものにできる。このため、索引データのデータ量が文字列の場合と比較して小さくなり、索引全体のデータ量を削減することができる。
【００８７】
このように整列された索引データを用いて、例えば「“ｔｙｐｅ”ノード下の“ｔｅｘｔ”ノードの値が“数量”であり、且つ、“ｖａｌｕｅ”ノード下の“ｔｅｘｔ”ノードの値が２０以上２５以下である」といった条件で検索を行うものとする。上記したように、索引データは“ｖａｌｕｅ”ノード下の“ｔｅｘｔ”ノードの値の数値としての大小関係に基づいて整列されている。このため、ヒットする索引データは索引データ配列内で近接しており、高速に検索処理を行うことができる。
【００８８】
このように第３の変形例においては、索引作成用に指定された型に基づいて、指定された型へ変換可能なノード情報のみを型変換して索引データ配列へ登録することにより、索引のデータ量を削減するとともに、検索速度を向上させることができる。更に、ノードの構造情報だけではノードの値の型を特定できないようなＸＭＬ文書の検索においても、検索速度を向上させる効果がある。
【００８９】
なお、本発明は、上記実施形態またはその変形例そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。例えば、上記実施形態またはその変形例では、構造化文書としてＸＭＬ文書を例にとって説明したが、これに限るものではない。本発明は、例えば、ＳＧＭＬ（Standard Generalized Markup Language）文書のようなＸＭＬ文書以外の構造化文書にも同様に適用できる。
【００９０】
また、上記実施形態またはその変形例では、クライアント端末２０がネットワーク３０を介して構造化文書管理システム５０のデータベースサーバ１０に接続されている。しかし、クライアント端末２０が直接に構造化文書管理システム５０のデータベースサーバ１０に接続されていても構わない。また、クライアント端末２０上で動作するのと同様のアプリケーションがデータベースサーバ１０上で動作する構成とすることにより、当該データベースサーバ１０が有するキーボード、ディスプレイ等をクライアント端末２０のように用いても、つまりデータベースサーバ１０をクライアント端末に兼用しても構わない。
【００９１】
また、上記実施形態またはその変形例に開示されている複数の構成要素の適宜な組み合せにより種々の発明を形成できる。例えば、実施形態またはその変形例に示される全構成要素から幾つかの構成要素を削除しても良い。
【図面の簡単な説明】
【００９２】
【図１】本発明の一実施形態に係る構造化文書管理システムを含むクライアント−サーバシステムのハードウェア構成を示すブロック図。
【図２】図１に示される構造化文書管理システムの主として機能構成を示すブロック図。
【図３】同実施形態における索引設定処理の手順を示すフローチャート。
【図４】２つのＸＭＬ文書の例を示す図。
【図５】図４に示される２つのＸＭＬ文書を木構造で表現した例を示す図。
【図６】索引設定管理テーブルの例を示す図であり、同図（ａ）は同実施形態で適用される索引設定管理テーブルの例を示し、同図（ｂ）は同実施形態の第１の変形例で適用される索引設定管理テーブルの例を示す。
【図７】同実施形態における文書登録処理の手順を示すフローチャート。
【図８】図６（ａ）の索引設定管理テーブルに登録されている索引設定情報に従って、図５の木構造で示される２つの文書のパス「／住所」に対して作成された索引を、当該木構造と対応付けて示す図。
【図９】同実施形態で作成される索引データ配列のデータ構造の一例を示す図。
【図１０】同実施形態における文書検索処理の手順を示すフローチャート。
【図１１】同実施形態で適用される索引作成をモデル化して示す図。
【図１２】同実施形態の第１の変形例で適用される索引作成をモデル化して示す図。
【図１３】上記第１の変形例において、図６（ｂ）の索引設定管理テーブルに登録されている索引設定情報に従って、図５の木構造で示される２つの文書のパス「／住所」に対して作成された索引を、当該木構造と対応付けて示す図。
【図１４】同実施形態の第２の変形例で適用されるＸＭＬ文書の一例を木構造で表した図。
【図１５】上記第２の変形例で作成される索引データ配列のデータ構造の一例を示す図。
【図１６】上記第２の変形例における索引検索処理の手順を示すフローチャート。
【図１７】同実施形態の第３の変形例で適用されるＸＭＬ文書の一例を木構造で表しす図。
【図１８】上記第３の変形例における索引作成時の型変換処理の手順を示すフローチャート。
【符号の説明】
【００９３】
１０…データベースサーバ、２０…クライアント端末、３０…ネットワーク、４０…外部記憶装置、４１…データベース管理プログラム、４２…ＸＭＬデータベース、５１…コマンド管理部、５２…ドキュメント管理部（タグ検出手段）、５３…検索エンジン（構造化文書検索手段）、５４…索引管理部、５５…データベース操作部、５６…索引検索部、４２１…ＸＭＬ文書格納部（構造化文書格納手段）、４２２…索引格納部、４２３…索引設定管理テーブル格納部、４２４…索引設定管理テーブル。
【特許請求の範囲】
【請求項１】
複数の構造化文書を管理する構造化文書管理システムにおいて、
複数の構造化文書を格納する構造化文書格納手段と、
前記構造化文書格納手段に格納されている構造化文書を検索するのに用いられる索引データを格納する索引格納手段と、
文字列結合索引データの作成を指示するための外部から与えられる索引作成要求であって、作成された文字列結合索引データが付与されるタグを指定する索引作成要求に基づき、前記構造化文書格納手段に新たに格納されるまたは既に格納されている構造化文書から当該索引作成要求で指定されたタグを検出するタグ検出手段と、
前記タグ検出手段によって検出されたタグを有する前記構造化文書に含まれている当該タグ以下に出現する複数のテキストノードの値を連結して索引化し、当該タグに付与される文字列結合索引データとして前記索引格納手段に格納する索引管理手段と
を具備することを特徴とする構造化文書管理システム。
【請求項２】
外部から与えられる検索要求の示す検索条件を満たす文字列結合索引データを前記索引格納手段から検索する索引検索手段と、
前記索引検索手段によって検索された文字列結合索引データを利用して構造化文書検索を行う構造化文書検索手段と
を更に具備することを特徴とする請求項１記載の構造化文書管理システム。
【請求項３】
前記索引管理手段は、前記索引作成要求が、当該要求で指定されるタグ以下に出現する全てのテキストノードのうち索引化の対象とすべき複数のテキストノードを指定する情報を含む場合、当該指定する情報で指定された複数のテキストノードの値だけを連結して索引化することを特徴とする請求項１記載の構造化文書管理システム。
【請求項４】
前記索引管理手段は、前記索引作成要求が、索引化の対象とすべき複数のテキストノードの優先順位を指定する情報を含む場合、構造化文書毎に作成されて前記索引格納手段に格納される文字列結合索引データを、当該索引格納手段内で、当該優先順位が高いテキストノードの値を優先させて整列させることを特徴とする請求項３記載の構造化文書管理システム。
【請求項５】
前記索引管理手段は、前記索引作成要求が、索引化の対象とすべきテキストノードの値の型を指定する情報を含み、且つ索引化の対象とすべきテキストノードの値を示す文字列を指定された型の値に変換可能である場合に限り、当該指定された型の値への変換を行って、その変換後のテキストノードの値を前記索引格納手段に追加することを特徴とする請求項３記載の構造化文書管理システム。
【請求項６】
構造化文書格納手段に格納されている複数の構造化文書、及び前記構造化文書格納手段に格納されている構造化文書を検索するのに用いられ、索引格納手段に格納されている索引データを管理する管理するデータベースサーバに、
文字列結合索引データの作成を指示するための外部から与えられる索引作成要求であって、作成された文字列結合索引データが付与されるタグを指定する索引作成要求を受け付けるステップと、
前記索引作成要求に基づき、前記構造化文書格納手段に新たに格納されるまたは既に格納されている構造化文書から当該索引作成要求で指定されたタグを検出するステップと、
前記検出されたタグを有する前記構造化文書に含まれている当該タグ以下に出現する複数のテキストノードの値を連結して索引化し、当該タグに付与される文字列結合索引データとして前記索引格納手段に格納するステップと
実行させるためのプログラム。
【請求項１】
複数の構造化文書を管理する構造化文書管理システムにおいて、
複数の構造化文書を格納する構造化文書格納手段と、
前記構造化文書格納手段に格納されている構造化文書を検索するのに用いられる索引データを格納する索引格納手段と、
文字列結合索引データの作成を指示するための外部から与えられる索引作成要求であって、作成された文字列結合索引データが付与されるタグを指定する索引作成要求に基づき、前記構造化文書格納手段に新たに格納されるまたは既に格納されている構造化文書から当該索引作成要求で指定されたタグを検出するタグ検出手段と、
前記タグ検出手段によって検出されたタグを有する前記構造化文書に含まれている当該タグ以下に出現する複数のテキストノードの値を連結して索引化し、当該タグに付与される文字列結合索引データとして前記索引格納手段に格納する索引管理手段と
を具備することを特徴とする構造化文書管理システム。
【請求項２】
外部から与えられる検索要求の示す検索条件を満たす文字列結合索引データを前記索引格納手段から検索する索引検索手段と、
前記索引検索手段によって検索された文字列結合索引データを利用して構造化文書検索を行う構造化文書検索手段と
を更に具備することを特徴とする請求項１記載の構造化文書管理システム。
【請求項３】
前記索引管理手段は、前記索引作成要求が、当該要求で指定されるタグ以下に出現する全てのテキストノードのうち索引化の対象とすべき複数のテキストノードを指定する情報を含む場合、当該指定する情報で指定された複数のテキストノードの値だけを連結して索引化することを特徴とする請求項１記載の構造化文書管理システム。
【請求項４】
前記索引管理手段は、前記索引作成要求が、索引化の対象とすべき複数のテキストノードの優先順位を指定する情報を含む場合、構造化文書毎に作成されて前記索引格納手段に格納される文字列結合索引データを、当該索引格納手段内で、当該優先順位が高いテキストノードの値を優先させて整列させることを特徴とする請求項３記載の構造化文書管理システム。
【請求項５】
前記索引管理手段は、前記索引作成要求が、索引化の対象とすべきテキストノードの値の型を指定する情報を含み、且つ索引化の対象とすべきテキストノードの値を示す文字列を指定された型の値に変換可能である場合に限り、当該指定された型の値への変換を行って、その変換後のテキストノードの値を前記索引格納手段に追加することを特徴とする請求項３記載の構造化文書管理システム。
【請求項６】
構造化文書格納手段に格納されている複数の構造化文書、及び前記構造化文書格納手段に格納されている構造化文書を検索するのに用いられ、索引格納手段に格納されている索引データを管理する管理するデータベースサーバに、
文字列結合索引データの作成を指示するための外部から与えられる索引作成要求であって、作成された文字列結合索引データが付与されるタグを指定する索引作成要求を受け付けるステップと、
前記索引作成要求に基づき、前記構造化文書格納手段に新たに格納されるまたは既に格納されている構造化文書から当該索引作成要求で指定されたタグを検出するステップと、
前記検出されたタグを有する前記構造化文書に含まれている当該タグ以下に出現する複数のテキストノードの値を連結して索引化し、当該タグに付与される文字列結合索引データとして前記索引格納手段に格納するステップと
実行させるためのプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【公開番号】特開２００８−５２６６２（Ｐ２００８−５２６６２Ａ）
【公開日】平成２０年３月６日（２００８．３．６）
【国際特許分類】
【出願番号】特願２００６−２３１０１２（Ｐ２００６−２３１０１２）
【出願日】平成１８年８月２８日（２００６．８．２８）
【出願人】（０００００３０７８）株式会社東芝 (54,554)
【出願人】（３０１０６３４９６）東芝ソリューション株式会社 (1,478)
【Ｆターム（参考）】
【公開日】平成２０年３月６日（２００８．３．６）
【国際特許分類】
【出願日】平成１８年８月２８日（２００６．８．２８）
【出願人】（０００００３０７８）株式会社東芝 (54,554)
【出願人】（３０１０６３４９６）東芝ソリューション株式会社 (1,478)
【Ｆターム（参考）】
[ Back to top ]