JP2004178614A - 文書管理方法および文書管理装置 - Google Patents

Abstract

【課題】従来では文字エントリへのアクセス、つまり二次記憶へのアクセスが多く、検索速度の低下を招いていたので、それを改善する文書管理方法を提供する。
【解決手段】特定のビットマップのビットを横方向に順時調べ、ビットが１の場合には、他のビットマップエントリの対応するビットを調べる。つまり、縦方向にビットを調べ、すべてのビットが１の場合は、ビットに対応する文書が検索結果の文書となるようにする。また、各文字エントリ中に出現するビット１の出現数を予めカウントしておき、前述のビットを調べる処理の時にビット出現数が小さい順に並び代え、同様の処理を行うことによって、さらに参照するデータ量を減らすことが可能となる。さらに、文字エントリの一部しか参照しない場合には、全ブロックをアクセスすることなしにブロックテーブルから直接該当するブロックを得られ、高速に検索することができる。
【選択図】図９

Description

本発明は、文書管理方法および文書管理装置に関し、より詳細には、文字成分表を利用し、全文書に対して文字列を検索する文書管理方法および文書管理装置に関するもので、例えば、文書管理システムや画像管理システム，データベース管理システム等に適用し得るものである。

従来の文書管理装置について記載した公知文献としては、例えば、特許文献１がある。この公報のものは、文字列検索において、利用する文字成分表を小さく抑え、かつ、検索程度を上げ、高速な文書登録を可能とするために、入力部に入力された検索文字列は、処理部の文字列入力処理で処理し、文書検索処理部において、データ部の文字成分表を利用して文字列を含むと思われる文書を検索する。検索した文書に対応する文書データを文書出力処理により出力部に出力し、文書登録処理では、登録する文書を文書データに登録し、文書データより文字成分を抽出して文字成分表に登録する。検索文字列を文書から検索する場合、文字成分表として、文字から算出される値が文書中に存在するか否かを示す１文字成分表及び隣接する文字から算出される値が文書中に存在するか否かを示す隣接文字成分表を利用して文書を検索する。すなわち、文書ごとに出現した文字を記録した文字成分表を用いて文書を高速に検索するシステムである。

また、前述した特許文献１や、先に提案した特許文献２に記載のものは、文字成分が文書中に存在するか否かを示す単一文字成分表、及び隣接する文字から抽出したある文字成分が文書中に存在するか否かを示す隣接文字成分表を利用して文書を検索するものである。
特開平５−３２４７２２号公報 特開平７−１６０７２４号公報

しかし、前記公報等に記載の方式には、以下に示すような問題点がある。
（１）文字成分表の構成が固定的だった。
（２）検索文字列が長くなるのに応じて検索時間がかかる。
（３）単一の文字列しか検索条件として指定できない。そのため、複数の文字列を論理演算子（ＡＮＤ，ＯＲ）で組み合わせた条件を満たす文書を検索することができない。
（４）文字成分表のビットマップデータを格納するブロックの大きさ（ブロックサイズ）が固定的であるため、ブロックサイズを小さくすると検索速度が低下し、ブロックサイズを大きくすると登録速度が低下してしまう。
（５）複数の文書を一括して登録する機能がなく、多量の文書を登録するのに処理時間がかかる。
（６）文書のデータがシステム内にあるので、ユーザにとって参照するのに手間がかかったり、文書の登録，削除，更新などの処理が面倒である。

本発明は、このような実情に鑑みてなされたもので、従来では文字エントリへのアクセス、つまり二次記憶へのアクセスが多く、検索速度の低下を招いていたので、それを改善する文書管理方法および文書管理方法および文書管理装置を提供することを目的としている。

本発明は、上記目的を達成するために、請求項１の発明は、大量の文書データを保持し、入力装置から入力された検索文字列を含む文書を検索し、出力装置により検索した文書を出力する文書管理方法であって、文書登録時に文書より各文字コード成分及び２文字以上の隣接文字からビット列成分を算出し、各文書がそれぞれの成分を含むか否かを示す単一文字成分表及び一つ以上の隣接文字成分表を生成し、該文字成分表の可変長の各文字成分のエントリを複数の固定長ブロックに分割して二次記憶に登録し、検索時には検索文字列から登録時と同様に単一文字成分及び２文字以上の隣接文字成分を抽出し、該隣接文字成分に対応する二次記憶上の固定長ブロックを統合し、各文字エントリを生成して文書を検索する文書管理方法において、仮に文字エントリで文字成分が出現するビットを１とし、出現しないビットを０とした場合に、検索時に複数の文字エントリのビットマップのＡＮＤ処理を行う時に対象となる文字エントリを一つ適当に選択し、ビット列をスキャンして値が１である時だけ他のエントリの対応するビットを調べ、全てのエントリの対応するビットの値が１である文書を検索結果とすることにより、文字エントリのビットマップへのアクセスを最小限に全文検索を行うことを特徴とする。

請求項２の発明は、請求項１記載の文書管理方法において、文字エントリごとに該文字エントリに出現する１のビットの個数をあらかじめ二次記憶に記録しておき、検索時に複数の文字エントリのビットマップのＡＮＤ処理を行う時に対象となる文字エントリのうち、該ビット出現数の最も少ない文字エントリを選択し、ビット列をスキャンして値が１である時だけビット出現数の少ない順に他の文字エントリの対応するビットを調べ、全ての文字エントリの対応するビットの値が１である文書を検索結果とすることにより、文字エントリのビットマップへのアクセスを最小限に抑え全文検索を行うことを特徴とする。

請求項３の発明は、請求項２記載の文書管理方法において、文字エントリの一部へのアクセスの場合に、文字エントリの全ブロックを読み出す必要がないように、可変長の文字エントリのビットマップデータを複数の固定長のブロックに分割して二次記憶に格納し、各固定長のブロックを管理するブロックテーブルを二次記憶上に有し、該ブロックテーブルから任意の固定長ブロックをアクセスできるようにすることによって、必要のない二次記憶上のブロックへのアクセスを減らして全文検索を行うことを特徴とする。

請求項４の発明は、請求項３記載の文書管理方法において、大量の文書データを保持し、入力装置から入力された検索文字列を含む文書を検索し、出力装置により検索した文書を出力する文書管理装置であって、文書登録時に文書より各文字コード成分及び２文字以上の隣接文字からビット列成分を算出し、各文書がそれぞれの成分を含むか否かを示す単一文字成分表及び一つ以上の隣接文字成分表を生成し、該文字成分表の可変長の各文字成分のエントリを複数の固定長ブロックに分割して二次記憶に登録する文書登録処理部と、検索時には検索文字列から登録時と同様に単一文字成分及び２文字以上の隣接文字成分を抽出する文字列入力処理部と、該隣接文字成分に対応する二次記憶上の固定長ブロックを統合し、各文字エントリを生成して文書を検索する文書検索処理部とを有する文書管理装置において、前記文書検索処理部は、仮に文字エントリで文字成分が出現するビットを１とし、出現しないビットを０とした場合に、検索時に複数の文字エントリのビットマップのＡＮＤ処理を行う時に対象となる文字エントリを一つ適当に選択し、ビット列をスキャンして値が１である時だけ他のエントリの対応するビットを調べ、全てのエントリの対応するビットの値が１である文書を検索結果とすることにより、文字エントリのビットマップへのアクセスを最小限に全文検索を行うことを特徴とする。

請求項５の発明は、請求項４記載の文書管理装置において、前記文書検索処理部は、文字エントリごとに該文字エントリに出現する１のビットの個数をあらかじめ二次記憶に記録しておき、検索時に複数の文字エントリのビットマップのＡＮＤ処理を行う時に対象となる文字エントリのうち、該ビット出現数の最も少ない文字エントリを選択し、ビット列をスキャンして値が１である時だけビット出現数の少ない順に他の文字エントリの対応するビットを調べ、全ての文字エントリの対応するビットの値が１である文書を検索結果とすることにより、文字エントリのビットマップへのアクセスを最小限に抑え全文検索を行うことを特徴とする。

請求項６の発明は、請求項５記載の文書管理装置において、前記文書検索処理部は、文字エントリの一部へのアクセスの場合に、文字エントリの全ブロックを読み出す必要がないように、可変長の文字エントリのビットマップデータを複数の固定長のブロックに分割して二次記憶に格納し、各固定長のブロックを管理するブロックテーブルを二次記憶上に有し、該ブロックテーブルから任意の固定長ブロックをアクセスできるようにすることによって、必要のない二次記憶上のブロックへのアクセスを減らして全文検索を行うことを特徴とする。

本発明によれば、特定のビットマップのビットを横方向に順時調べ、ビットが１の場合には、他のビットマップエントリの対応するビットを調べる。つまり、縦方向にビットを調べ、すべてのビットが１の場合は、ビットに対応する文書が検索結果の文書となるようにする。
また、各文字エントリ中に出現するビット１の出現数を予めカウントしておき、前述のビットを調べる処理の時にビット出現数が小さい順に並び代え、同様の処理を行うことによって、さらに参照するデータ量を減らすことが可能となる。
さらに、文字エントリの一部しか参照しない場合には、全ブロックをアクセスすることなしにブロックテーブルから直接該当するブロックを得られ、高速に検索することができる。
このように従来技術では文字エントリのアクセスが多く、検索速度の低下を招いていたが、検索時の処理のアルゴリズム及びデータ構成を変えることによって検索速度が向上する。

実施例について、図面を参照して以下に説明する。
図１は、本発明による文書管理装置の一実施例を説明するための構成図で、図中、１は登録文書、２は文書登録手段、３は検索条件、４は文書検索手段、５は該当文書、６は文字成分表エントリ指定、７は文字成分表、８は文書本文データ、９は文書データベースである。

文書登録手段２は、登録文書１を文書データベース９に登録操作を行う。該文書データベース９には、文書本文データ８と文字成分表７と文字成分表エントリ指定６とが含まれる。文字成分表７とは、登録文書１に含まれる各文字あるいは文字列から抽出された情報の存在の有無を文書ごとに記録した表である。文書登録手段２は、登録文書１を保存するとともに、該登録文書１に含まれる各文字あるいは連続する２文字から算出される値を文字成分表７に登録し記録する。文書検索手段４は、前記文字成分表７を用いて検索条件３に該当する文書５を高速に探し出す。文字成分表エントリ指定６により文字成分表７の構成を変更可能とする。

図２は、文字成分表の一例を示す図である。
ここで示した文字成分表では、各文字の出現のみを記録した構成である。これは、各文字のコードに関数を作用させ、算出される値をエントリとするものである（各文字の出現をそのまま記録する図２の方式は、関数としてｆ(ｘ)＝ｘとしたものである）。このような１文字から算出されるエントリを単一文字エントリと呼ぶ。

図３は、文字成分表の他の例を示す図である。
ここで示した文字成分表では、各文字と連続する２文字からそれぞれの文字コードの下位４ビットをビット連結して得られる値をエントリとしている。例えば、「ぐ」,「だ」,「ば」のJISコードは、各々 0x2430，0x2440，0x2450 であり、下位４ビットを連結して得られる８ビットを文字成分表のエントリとした場合、「ぐぐ」,「ぐだ」,「ぐば」…は全て同じ 0x00 のエントリにまとめられる。すなわち、連続する２文字のコードに関数を作用させ、算出される値をエントリとすることができる（前側の文字ｘ，後側の文字ｙに対して、関数ｇ(ｘ,ｙ)の値をエントリとする）。このような連続する２文字から算出されるエントリ（文字成分）を隣接文字エントリと呼ぶ。図３の文字成分表は、単一文字エントリと隣接文字エントリを組み合わせたものである。

このように、文字成分表には様々な構成が可能であり、本発明では、図１の文字成分表エントリ指定６によって文字成分表７の構成を指定できるものとする。以下の説明では、簡単のため、図２のような各文字の出現のみを記録した文字成分表を使用するものとする。

文書登録手順は、次の通りである。
（１）登録文書１を文書本文データ８に登録する。
（２）登録文書１の内容を文字成分表７に登録する。
文書本文から文字成分表エントリ指定６で規定されるエントリを抽出する。登録文書番号をｉ，抽出されたエントリ番号をｊとした場合、すべてのｊについて文字成分表の点（ｉ,ｊ）の値を“１”にする。

また、文書検索手順は、次の通りである。
（１）文字成分表７を用いて検索文字列を含む可能性のある文書番号を求める。
(a)検索文字列から文字成分表エントリ指定６で規定されるエントリを抽出する。
(b)抽出された全てのエントリのビットマップ（図２の横一列）を文字成分表から抜きだし、ビットＡＮＤをとる。
（３）前記（１）で求まった文書番号の文書本文を文書本文データ８から読みだし、検索文字列が含まれているか調べ、含まれている文書集合を検索結果とする。

文字成分表の検索精度（文字成分表を用いて得られる文書に検索文字列が含まれている割合）は文字成分表の構成に依存する。本発明では、文字成分表エントリ指定により、文字成分表の構成を任意に変更できる。そのため、登録される文書に合わせて効率的な文書管理システムを構築できる。

図４は、本発明による文書管理装置の他の実施例を説明するための構成図で、図中、９-1〜９-nは文書データベースで、その他、図１と同じ作用をする部分は同一の符号を付してある。なお、図１の構成と異なる点は、文書データベース９-1〜９-nが多数存在している点である。
文書には様々な用途のものがあるため、異なる文書集合は異なる文書データベースに保存することが望まれる。その際、異なる文書集合は、文書の長さや文字の出現頻度なども違う。そこで、本発明の文書管理装置では、文書データベース９ごとに文字成分表エントリ指定６を異なったものを用いることができるため、効率的な文書管理を行える。

これまでの方式だと、検索文字列が長くなるに従い、文字成分表でアクセスすべきエントリが増加するため、検索速度が低下する。実際には、検索語から算出される文字成分表エントリにも同一のものが含まれることがある。その場合、そのエントリに複数回アクセスする必要はないため、検索語に複数個出現したエントリへのアクセスを一回に押えることで、検索に必要な文字成分表へのアクセス回数を減らし、検索を高速化できる。

例えば、図２の文字成分表を用いた場合、検索語「マンマシンシステム」は９文字から構成されているため、文字成分表には「マ」「ン」「マ」「シ」「ン」「シ」「ス」「テ」「ム」の９回のアクセスが必要になる。しかし、実際には、「マ」「ン」「シ」は２回ずつ出現しているため、これらエントリへのアクセスは１回にまとめることができる。すなわち、文字成分表への実際のアクセスは、「マ」「ン」「シ」「ス」「テ」「ム」の６回ですむ。

これまでの方式だと、文字成分表のエントリは最大２文字からのみ構成される。これに対し、３文字以上の長い文字列（から算出される値）をエントリに用いることとすれば、文字成分表へのアクセス回数を減らし、検索を大幅に高速化できる。
図５は、長い文字列をエントリとして持つ文字成分表を示す図である。
「システム」「パターン」などが文字列エントリである。文字列エントリは、文書における出現頻度の高い文字列を選出すれば良い。

登録時には、「…あのマンマシンシステムは…」からは、文字として「あ」「の」「マ」「ン」「シ」「ス」「テ」「ム」「は」、文字列として「システム」が抽出され、文字成分表に記録される。
検索時には、検索語「マンマシンシステム」からは、文字として「マ」「ン」「マ」「シ」「ン」、文字列として「システム」が抽出されるが、「システム」に含まれる「シ」および単一文字の重複を削除する。結局、「マ」「ン」「システム」の３つのエントリにアクセスするだけでよく、検索時間は大幅に短縮できる。

上述の３文字以上の長い文字列（から算出される値）をエントリに用いる方式では、文書登録時に文字列エントリに含まれる文字エントリも抽出し、文字成分表に記録する。しかし、その部分は、通常検索文字列でも文字列として含まれる場合が多いので、文字成分表に記録する必要は必ずしもない。このような文字エントリを登録しないことにより、文字成分表を小型化することができる。

例えば、前項の例文「…あのマンマシンシステムは…」の登録時には、文字として登録するのは「あ」「の」「マ」「ン」「は」だけでよい（文字列として「システムが抽出され、文字成分表に記録される）。ただし、検索文字列に文字列エントリの部分文字列が含まれている場合、この方式では、検索洩れが起こり得る。例えば、検索文字列が「システ」の場合（「システム」の部分文字列）、この方式では検索できないことになる。

また、検索条件として複数の文字列を論理演算子（ＡＮＤ，ＯＲ）で組み合わせたものを受け付ける（単一の文字列もこの検索条件に含める）。ここで、“ＡＮＤ”は前後の文字列をともに含む文書を検索すること、“ＯＲ”は前後の文字列を少なくとも一つ含む文書を検索することを意味する。さらに、必要に応じて、演算子の作用順序を明示するために、“(”,“)”を用いることができるものとする。論理演算子を検索条件に用いることができるようにすることで、複雑な検索要求を表現することが可能となる。例えば、「マンマシンシステム」,「文書検索ＡＮＤ文書登録」,「文書検索ＯＲ情報検索」,「(新聞ＯＲ雑誌)ＡＮＤカラー」などが上記の検索条件になる。

次に、単一の検索文字列内のアクセスの単一化ではなく、論理演算子ＡＮＤで結合される２つないしはそれ以上の検索文字列にまたがったアクセスの単一化を導入する。例えば、検索条件「文書検索ＡＮＤ文書登録」から、従来方式では、「文」「書」「検」「索」「文」「書」「登」「録」の８つのエントリにアクセスする。一方、本項目の単一化（最適化）により「文」「書」の重複が削除され、文字成分表へのアクセスは６回に減らすことができる。

また、単一の検索文字列内のアクセスの単一化ではなく、論理演算子ＯＲで結合される２つないしはそれ以上の検索文字列にまたがったアクセスの単一化を導入する。例えば、検索条件「文書検索ＯＲ情報検索」から、従来方式では、「文」「書」「検」「索」「情」「報」「検」「索」の８つのエントリにアクセスする。一方、本項目の単一化（最適化）により「検」「索」の重複が削除され、文字成分表へのアクセスは６回に減らすことができる。

次に、文字成分表は、ファイルとして保存される。文字成分表ファイルの構成は、文字成分表のエントリに対応するビットマップデータに簡単にアクセスできることが望まれるが、それを実現するために、例えば、インデックスファイルと固定長ブロックから構成されるビットマップデータファイルの２つのファイルで構成することができる。この場合、インデックスファイルは、次の２つのフィールドを含むブロックから構成することができる。
・先頭ブロックオフセットフィールド
・末尾ブロックオフセットフィールド

インデックスファイルに含まれるブロック数は、文字成分表エントリ指定によって決まる。ビットマップデータファイルは、次の２つのフィールドを含むブロックから構成される。
・次ブロックオフセットフィールド
・データフィールド

ブロックサイズは、性能要求に合わせて数十バイトから数キロバイトの範囲に設定すれば良い。
図６（ａ）は、文字成分表のためのファイル構成の一例を示す図である。なお、インデックスファイルを半導体メモリ上にロードしておくことは、高速化に有効である。

ビットマップデータファイルのブロックサイズは、登録・検索性能等に与える影響が大きい。ブロックサイズが大きい場合、検索は高速だが登録が遅く、小さい場合、登録は高速だが検索は遅くなる。また、データファイルのうち、ビットマップデータの記録に使用されていない領域の割合は、そこで、ブロックを大きいものと小さいものの２種類を用意する。以下では、小さいブロックを「バケット」、大きいブロックを「コンテナ」と呼び、コンテナとバケットの大きさの比を「Ｍ」と書くこととする。コンテナの大きさは、バケットの数倍から十数倍程度とする（Ｍ＝数倍〜十数）。

図６（ｂ）は、２種類の大きさのブロックを導入した場合の文字成分表のファイル構成の一例を示す図である。ここでは、ブロックオフセットの最上位ビットが“１”,“０”によって、そのオフセット位置のブロックがコンテナかバケットかを示すようにしている。

文書検索システム利用開始時点では、ブロックサイズを小さいものとして、登録速度を優先する（登録文書数が少ない間は、検索速度が多少遅くても検索時間が小さいので、ほとんど問題とならない）。多数の文書が登録され、ビットマップデータファイルに含まれるブロック数が増大した段階で、複数のバケットをコンテナにまとめあげるブロック融合処理を行う。通常のオペレーティングシステムでは、データを小さいブロックに分割しておくよりも大きいブロックにまとめておく方がアクセスが高速だからである。その結果、ブロック融合処理により検索速度が向上され、登録文書数が多い場合でも検索時間を小さくできる。

ブロック融合処理手順Ａ
（１）書き出し用の一時ファイルを作成する。
（２）文字成分表を構成する全てのエントリのビットマップデータに対して、次の処理を行う。
(a)コンテナはそのまま一時ファイルに書き出す。
(b)コンテナにまとめ上げられる（Ｍ個の）バケットは、１個のコンテナとし、一時ファイルに書き出す。
(c)残りのコンテナにまとめ上げられない（Ｍ個未満の）バケットは、一時ファイルに書き出す。
（３）これまでのビットマップデータファイルを削除する。
（４）一時ファイルを新たなビットマップデータファイルとする。

図７（ａ）,（ｂ）は、ブロック融合処理の概要を示す図である。
網掛けによって各バケット／コンテナがどのエントリ（ここでは文字ごとにエントリを立てている）に対応しているかを示す。ここでは、コンテナはバケットの８倍の大きさとしている。例えば、「あ」は、融合処理前にバケット１７個なので、融合処理後はコンテナ２個とバケット１個になる。「い」は、同様にしてバケット１１個がコンテナ１個とバケット３個になる。「う」は、バケットが７個しかないので、コンテナには１個も生成されず、バケット７個のままである（ただし、この場合でもバケットがお互いに隣接する位置に配置されるため、アクセスが高速化され、検索速度が向上する）。

次に、前述の方式では、データファイル中にバケットとコンテナが混在する。２次記憶装置上のデータへのアクセスは、オペレーティングシステムの最適化などによりページ単位に行われるため、バケットとコンテナが混在していると、コンテナのような大きいブロックを導入しても、コンテナの配置が２次記憶装置のページ境界と一致せず、期待通りの性能向上が行われないことがある。そこで、本発明の方法では、データファイルの前方にコンテナをまとめ、後方にブロックをまとめることで、コンテナを必ずページ境界に配置し、性能向上を図る。

ブロック融合処理手順Ｂ
（１）書き出し用の一時ファイルを２つ作成する。１つを「コンテナ用一時ファイル」、もう１つを「バケット用一時ファイル」と呼ぶ。
（２）文字成分表を構成する全てのエントリのビットマップデータに対して、次の処理を行う。
(a)コンテナはそのままコンテナ用一時ファイルに書き出す。
(b)コンテナにまとめ上げられる（Ｍ個の）バケットは１個のコンテナとし、コンテナ用一時ファイルに書き出す。
(c)残りのコンテナにまとめ上げられない（Ｍ個未満の）バケットは、バケット用一時ファイルに書き出す。
（３）これまでのビットマップデータファイルを削除する。
（４）コンテナ用一時ファイルにバケット用一時ファイルを連結し、新たなビットマップデータファイルとする。

図７（ａ）,（ｃ）は、上記アルゴリズムによるブロック融合処理の概要を示す図である。このアルゴリズムでは、ブロック融合処理後（図７（ｃ）の状態）は、データファイルの先頭部分にコンテナが集まり、Ａ点以降はバケットが集合した状態となる。

次に、データファイルの小さいブロックが存在する領域のみをブロック融合の対象とするブロック融合手段について説明する。
ブロック融合処理後にも文書は追加登録される。追加登録後のブロックタイプはバケットなので、追加登録文書数が増大すると、再び検索速度が低下してしまう。その場合、再びブロック融合処理手順Ｂによりブロック融合処理を行えばよい。しかし、ブロック融合処理手順Ｂでは、２つの一時ファイルの大きさの合計は、データファイルとほぼ等しくなってしまう。多量の文書が登録された場合、データファイルの大きさが膨大となるため、これは極めて望ましくない。次に示すブロック融合処理手順Ｃはこの点を改良し、一時ファイルの大きさの合計をデータファイルのバケット部分の大きさ程度で済むようにした。

ブロック融合処理手順Ｃ
（１）書き出し用の一時ファイルを２つ作成する。１つを「コンテナ用一時ファイル」、もう１つを「バケット用一時ファイル」と呼ぶ。
（２）文字成分表を構成する全てのエントリのビットマップデータに対して、次の処理を行う。
(a)コンテナは無視する。
(b)コンテナにまとめ上げられる（Ｍ個の）バケットは、１個のコンテナとし、コンテナ用一時ファイルに書き出す。
(c)残りのコンテナにまとめ上げられない（Ｍ個未満の）バケットは、バケット用一時ファイルに書き出す。
（３）ビットマップデータファイルのバケット部分を削除する。
（４）ビットマップデータファイルにコンテナ用一時ファイル、さらにバケット用一時ファイルを連結する。

ブロック融合処理手順Ｂ及びブロック融合処理手順Ｃの方式の相違を図８（ａ）〜（ｃ）に示す。図８（ａ）に示すように、バケット融合処理後に再び文書が登録された場合、データファイルの末尾（図８（ａ）のＢ点）からバケットが順次挿入された状態になる。ブロック融合処理手順Ｂでは、図８（ｂ）のように、データファイルのブロックが整理され、検索速度が向上する。しかし、２つの一時ファイルの合計の大きさは、データファイルの大きさと等しい。これに対し、ブロック融合処理手順Ｃでは、データファイルのＡ点以降の部分のみを処理の対象とする。ブロック融合処理結果を示したものが図８（ｃ）である。新たに作成されたコンテナは、融合前にバケットが存在していたＡ点以降に配置される。同一エントリに対するコンテナが必ずしも連続する位置に配置されるわけではないが（例えば、「い」のコンテナ）、そのことにより速度低下は極めて小さい。

図９は、本発明による文書管理装置の更に他の実施例を説明するための構成図で、図中、１１は入力部、１２は処理部、１３は文字列入力処理部、１４は文書検索処理部、１５は文書出力処理部、１６は文書登録処理部、１７はデータ部、１８は文字成分表、１９は出力部、２０は文書データである。

入力部１１に入力された検索文字列は、処理部１２の文字列入力処理部１３で処理する。文書検索処理部１４においてデータ部１７の文字成分表１８を利用して文字列を含むと思われる文書を検索する。そして、検索した文書に対応する文書データ２０を文書出力装置１５により出力部１９に出力する。文書登録処理部１６では、登録する文書を文書データ２０に登録し、該文書データ２０より文字成分を抽出して文字成分表１８に登録する。
以下の説明では、対象文書は１バイト文字コード（例えば、ＡＳＣＩＩ）及び２バイト文字コード（ＥＵＣ：Ｅxtended ＵＮＩＸ（Ｒ） ＣＯＤＥ）からなるテキストデータとする。しかし、対象とする文字コードはＥＵＣ以外にも容易に適用可能である。

文書をデータ部に登録する時には、単一文字成分及び隣接文字成分を抽出し、文字成分表を作成する。単一文字成分は各内部文字コードの２バイトコードとし、隣接文字成分は隣接する内部文字コードから変換したコードである。本実施例では内部文字コードのビット成分を適当に抽出したビット列を隣接文字成分とする。上記方法で得られた文字成分及び隣接文字成分に対して、図１０に示すように、それぞれ単一文字成分表及び図１１に示す隣接文字成分表を生成する。図１１では隣接する文字の下位１バイトを合わせて２バイトとしている。各文字成分表は、各単一文字成分または隣接文字成分が各文書に存在するか否かを０と１で示す。図１１の隣接文字成分表を例とすると、a0a0（１６進）のビット列は文書１、２、３、ｎには存在せず、文書４、５には存在することを意味する。文書登録時に上記方法により文書から文字成分を抽出し、各文字成分テーブルに加える。

仮に、隣接文字成分表として各文字成分の下位１バイトのみを利用した場合には、検索文字列とは異なる隣接文字でも下位バイトが一致する隣接文字を含む文書を検索する場合がある。ひらがな及びカタカナは頻繁に出現するので、検索の精度が低くなる。また漢字は文書中の出現頻度が低いので、本来検索精度が高い文字種であるにも関わらず、検索精度が低い他の文字種の影響を受けて検索精度が低くなってしまう。そこで、文字種ごとに異なる隣接文字成分表を作成し、検索時に検索文字列の文字種ごとに異なる隣接文字成分表を利用することによって、ひらがななどの頻繁に文書に出現する文字種の影響を受けず、検索精度を上げることができる。
以下、単一文字成分表、隣接文字成分表について説明する。

・単一文字成分表：文字がどの文書に出現するか否かを示す表
・隣接文字成分表
−同種隣接文字成分表：隣接する同種の文字のペアがどの文書に出現するか否かを示す表
＊記号
＊英数時
＊ひらがな
＊カタカナ
＊ギリシャ文字、グラフィック文字など
＊１バイト文字コード
＊第一水準漢字
＊第二水準漢字
−異種隣接文字成分表：隣接する異種の文字のペアがどの文書に出現するか否かを示す表

検索時には登録時と同様に検索文字列から単一文字成分と隣接文字成分を抽出し、それぞれ文字成分表から各成分を含む文書を検索する。
図１２は、従来の検索方法を説明するための図である。
図１２において、ビットの１は文字成分が出現することを示し、０は文字成分が出現しないことを意味する。従来の検索方法では検索文字列から文字種を判別して単一文字成分、隣接文字成分を登録時と同様に抽出し、各文字成分に対応する単一文字成分表及び隣接文字成分表から文字エントリのビットマップを抽出してＡＮＤ演算を行う。したがって、対象となるすべての文字エントリのデータを参照することになる。

次に、本発明における検索方式を説明する。図１３に示すように、特定のビットマップのビットを横方向に順時調べ、ビットが１の場合には、他のビットマップエントリの対応するビットを調べる。つまり、図１３で縦方向にビットを調べ、すべてのビットが１の場合は、ビットに対応する文書が検索結果の文書となる。ビットが０の時には、図１３の一番上の文字エントリに戻り、順時同様に繰り返す。こうすることによって、矢印で示されるビットのみを参照することになり、従来の検索方法に比較して参照するデータ量が格段に減少する。

さらに、図１４に示すように、各文字エントリ中に出現するビット１の出現数を予めカウントしておき、前述のビットを調べる処理の時に、図１４に示すように、ビット出現数が小さい順に並び代え、同様の処理を行うことによって、さらに参照するデータ量を減らすことが可能となる。

従来の検索方法では、各文字エントリのビットマップデータである可変長ビットマップデータは、複数の固定長ブロックに分割され、二次記憶に格納されている。したがって、前述の検索処理時に再度複数の固定長ブロックを可変長のビットマップに結合復元する。また、各文字エントリの一部のデータしかアクセスしない場合でも、文字エントリの全固定長データブロックを読み込み結合し、可変長ビットマップデータに復元する処理が必要となる。

次に、データ構成について説明する。
本実施例では、前述の文字エントリは二次記憶上で、図１５に示すように、インデックスとブロックテーブルとブロックとから構成される。インデックスは各内部文字コードに対してブロックテーブルポインタとビット出現数（エントリ内に出現するビット１の数）のペアからなる。ブロックテーブルは先頭に次のブロックテーブルへのポインタを有し、ブロックポインタとブロック最終登録文書ＩＤ（ブロック内の最後に登録されている文書のＩＤ）からなる。したがって、内部文字コード「あ」に対応する全ブロックは、図１５に示すように、ブロックテーブルから示されるブロックとなる。

文書ＩＤが４０００の文書内に内部文字コードが「あ」の文字が出現する否かを調べる場合を例に、以下に説明する。
・インデックスの「あ」に対応するブロックテーブルポインタからブロックテーブルを得る。
・ブロック最終登録文書ＩＤから文書ＩＤ４０００を含むブロック（ブロックポインタ５１２０）を得る。
・ブロック（５１２０）のデータが圧縮されている場合には伸長し、文書ＩＤ４０００に該当するビットを得る。
このように、文字エントリの一部しか参照しない場合には、全ブロックをアクセスすることなしにブロックテーブルから直接該当するブロックを得られ、高速に検索することができる。

検索の時間で最も多く占めるのがディスクからデータのＲＥＡＤ時間である。ＲＥＡＤするページ（物理的なディスク読み書きの単位）が多ければ多いほど検索処理は遅くなる。文書登録を行なうと、図１６（ａ）のように、文字エントリのブロックは複数のページに分散する。したがって、検索処理では分散しているブロックを含むページをすべてＲＥＡＤすることにより処理が遅くなる。
本実施例では、図１６（ｂ）のように、分散したブロックをページ単位にまとめ上げることで検索処理時にＲＥＡＤするページを減らし、処理を速くすることができる。図１６に示す例では、まとめ上げ前には６ページ以上をＲＥＡＤしなければならなかったが、まとめ上げ後には３ページとなり、ＲＥＡＤの時間が半分以下になる。このようにブロックをページ単位にまとめ上げる処理をまとめ上げ処理と呼ぶ。

まとめ上げ処理では、図１６（ｂ）のように、ブロックをページにまとめ上げるが、ページにまとめ上げられなかった、ブロックについてはまとめ上げられなかったブロックを格納するためのページ（残ブロックページと呼ぶ）に集められる。したがって、図１７に示すように、残ブロックページには、様々な文字エントリの残ブロックが格納される。また、まとめ上げられたページはファイル中で混在することになる。

まとめ上げの処理手順を以下に示す。なお、説明中のバッファはメモリ上の領域を意味する。
（１）前処理
（ａ）文字成分表をオープンする。
（ｂ）まとめ上げ用文字成分表を作成しオープンする。
（ｃ）残ブロックページをアロケートする。

（２）文字エントリ単位のまとめ上げ処理
（ａ）ページへのまとめ上げ処理
ｉ．１ランレングスを読みページバッファに詰める。
ii．ページバッファにデータが満たされたらページバッファを書き出し、ページバッファをクリアする。
iii．ランレングスをすべて読み終るまで前記ｉ．に戻る。
（ｂ）ページにまとめ上げられなかったブロック(残ブロック)の書き出し処理
ｉ．まとめ上げられなかったランレングスから再度１ランレングスを読み、残ブロックバッファに詰める。
ii．残ブロックバッファにデータが満たされたら残ブロックページに書き出す。
iii．残ブロックページの領域をすべて使い果たしたら新たに残ブロックページをアロケートする。
iv．ランレングスをすべて読み終るまで前記ｉ．に戻る。

（３）後処理
（ａ）書き出されていない残ブロックページを書き出す。
（ｂ）文字成分表及びまとめ上げ文字成分表をクローズする。
こうすることによって、文字成分表を１回スキャンするだけまとめ上げ処理が可能となり、処理が高速であるだけでなく、処理時に必要な二次記憶の領域を最小限に抑えられる。

次に、検索処理について説明する。
本実施例の検索処理では、検索文字列から抽出されるエントリ数が少なければ、文字成分表へのアクセスが少なくなり、検索が高速になる。文字成分表エントリ指定において、単一文字エントリと隣接文字エントリを定義した場合、検索文字列がｎ文字の時、ｎ個の単一文字エントリとｎ−１個の隣接文字エントリが抽出されるので、トータルでは２ｎ−１個のエントリが抽出され、検索が遅い。

例えば、検索文字列が「パターンマッチ」である時、次のエントリが抽出される。
・単一文字エントリ：以下の文字に関数ｆ（ｘ）を作用させる。
パ,タ,ー,ン,マ,ッ,チ
・隣接文字エントリ：以下の２文字に関数ｇ（ｘ,ｙ）を作用させる。
パタ,ター,ーン,ンマ,マッ,ッチ

しかし、ｆ（ｘ）＝ｘ，ｇ（ｘ,ｙ）＝ｘ＋αｙ（ここで、αは文字コードの取り得る最大値）のような場合を考える。この時、検索文字列からｇ（Ｘ,Ｙ）が抽出される時には、必ずｆ（Ｘ），ｆ（Ｙ）も抽出される（例えば、ｇ（パ,タ）が抽出される時は、必ずｆ（パ），ｆ（タ）も抽出される）。したがって、検索文字列を含む文書を特定する上で、単一文字エントリは意味をなさない。そこで、検索文字列からは単一文字エントリを抽出せず、隣接文字エントリのみを抽出する。その結果、ｎ文字の検索文字列からｎ−１個の隣接文字エントリのみが抽出されるので、検索が高速化できる。

例えば、検索文字列が「パターンマッチ」である時、次のエントリが抽出される。
・単一文字エントリ：抽出しない。
・隣接文字エントリ：以下の２文字に関数ｇ（ｘ,ｙ）を作用させる。
パタ,ター,ーン,ンマ,マッ,ッチ
なお、この方式が有効なのは、ｆ（ｘ）＝ｘ，ｇ（ｘ,ｙ）＝ｘ＋αｙに限らない。

次に、他の検索処理について説明する。
本実施例も、上述の検索処理と同様の効果を狙ったものであり、文字成分表エントリ定義がｆ（ｘ）＝ｘ，ｇ（ｘ,ｙ）＝ｘ＋α（ｙ mod β)(ここで、αは文字コードの取り得る最大値、βは適当な定数）のような場合を扱う。この時、検索文字列からｇ（Ｘ,Ｙ）が抽出される時には、必ずｆ（Ｘ）は抽出される（例えば、ｇ（パ,タ）が抽出される時は、必ずｆ（パ）も抽出される）。したがって、検索文字列を含む文書を特定する上で、末尾の１文字を除いては単一文字エントリは意味をなさない。そこで、検索文字列からは末尾の１文字から算出される単一文字エントリと、隣接文字エントリを抽出する。その結果、ｎ文字の検索文字列から１個の単一文字エントリとｎ−１個の隣接文字エントリのトータルｎ個のエントリが抽出されるので、検索が高速化できる。

例えば、検索文字列が「パターンマッチ」である時、次のエントリが抽出される。
・単一文字エントリ：以下の文字に関数ｆ（ｘ）を作用させる。
チ
・隣接文字エントリ：以下の２文字に関数ｇ（ｘ,ｙ）を作用させる。
パタ,ター,ーン,ンマ,マッ,ッチ
なお、この方式が有効なのは、ｆ（ｘ）＝ｘ，ｇ（ｘ,ｙ）＝ｘ＋α（ｙ mod β)に限らない。

次に、他の検索処理について説明する。
本実施例も上述の検索処理と同様の効果を狙ったものであり、文字成分表エントリ定義がｆ（ｘ）＝ｘ，ｇ（ｘ,ｙ）＝ｙ＋α（ｘ mod β）のような場合を扱う。この時、検索文字列からｇ（Ｘ,Ｙ）が抽出される時には、必ずｆ（Ｙ）は抽出される（例えば、ｇ（パ,タ）が抽出される時は、必ずｆ（タ）も抽出される）。したがって、検索文字列を含む文書を特定する上で、先頭の１文字を除いては単一文字エントリは意味をなさない。そこで、検索文字列からは先頭の１文字から算出される単一文字エントリと、隣接文字エントリを抽出する。その結果、ｎ文字の検索文字列から１個の単一文字エントリとｎ−１個の隣接文字エントリのトータルｎ個のエントリが抽出されるので、検索が高速化できる。

例えば、検索文字列が「パターンマッチ」である時、次のエントリが抽出される。
・単一文字エントリ：以下の文字に関数ｆ（ｘ）を作用させる。
パ
・隣接文字エントリ：以下の２文字に関数ｇ（ｘ,ｙ）を作用させる。
パタ,ター,ーン,ンマ,マッ,ッチ
なお、この方式が有効なのは、ｆ（ｘ）＝ｘ，ｇ（ｘ,ｙ）＝ｙ＋α（ｘ mod β)に限らない。

また、文字成分表のエントリに３文字以上の長い文字列（から算出される値）をエントリに用いることで、文字成分表へのアクセス回数を減らし、検索を大幅に高速化できることを示した。図５に長い文字列をエントリとして持つ文字成分表を示す。「システム」「パターン」などが文字列エントリである。

文字成分表エントリ指定において、単一文字エントリと隣接文字エントリを定義し、さらに、文字列エントリを導入した場合の検索処理を考える。上述の説明では、検索文字列中に含まれる文字列エントリに対応する文字列から抽出される単一／隣接文字エントリは、検索処理に用いないとしていた。

例えば、検索文字列が「パターンマッチ」で「パターン」が文字列エントリとして定義されている時、次のエントリが抽出される。
・単一文字エントリ：以下の文字に関数ｆ（ｘ）を作用させる。
マ,ッ,チ
・隣接文字エントリ：以下の２文字に関数ｇ（ｘ,ｙ）を作用させる。
ンマ,マッ,ッチ
・文字列エントリ：
パターン

もちろん、上述した文字成分表のエントリに３文字以上の長い文字列（から算出される値）をエントリに用いる検索方式にここで説明した検索処理を組み合わせることも可能である。
一方、本発明では、隣接文字エントリについては該当する文字列エントリに前後の文字を加えた文字列から抽出されるエントリを抽出しないことで、検索文字列から抽出エントリ数を削減し、検索を高速化する（単一文字エントリについては、これまで通り、該当する文字列エントリから抽出されるエントリを抽出しないこととする）。

例えば、「パターンマッチ」から抽出されるエントリは、以下のようになり、エントリ数を一つ減らすことができる。
・単一文字エントリ：以下の文字に関数ｆ（ｘ）を作用させる。
マ,ッ,チ
・隣接文字エントリ：以下の２文字に関数ｇ（ｘ,ｙ）を作用させる。
マッ,ッチ
・文字列エントリ：
パターン

次に、前述した説明では、検索条件として複数の文字列を論理演算子（ＡＮＤ，ＯＲ）で組み合わせたもの（単一の文字列もこの検索条件に含める）を受け付けるとしていた。ここで、“ＡＮＤ”は前後の文字列をともに含む文書を検索すること、“ＯＲ”は前後の文字列を少なくとも一つ含む文書を検索することを意味する。さらに、必要に応じて、演算子の作用順序を明示するために、“(”,“)”を用いることができるものとする。論理演算子を検索条件に用いることができるようにすることで、複雑な検索要求を表現することが可能となった。

しかし、ＡＮＤ，ＯＲだけでは「「文書検索」を含むが「画像検索」を含んでいないこと」のような否定を含む検索要求を表現することはできない。そこで、本実施例では、検索条件として複数の文字列を論理演算子（ＡＮＤ，ＯＲ，ＮＯＴ）で組み合わせたものを受け付ける。ここで、“ＮＯＴ”は前の文字列を含むが、後の文字列は含まない文書を検索することを意味する。

このＡＮＤ，ＯＲの処理では、演算子の前後の検索文字列に対するビット列を計算し（検索手順のステップ１）、それらのビットＡＮＤあるいはビットＯＲを取れば良かった。しかし、ＮＯＴでは、同様の処理（前後の検索文字列に対するビット列を計算し、後側のビット列のビット反転して前側のビット列とビットＡＮＤを取る）では、検索洩れの可能性がある。これは、文字成分表を用いて得られる各検索文字列に対するビット列は、正確にその文字列を含む文書番号の表現ではなく、実際には、その文字列を含んでいない誤検索も含んでいるためである。その結果、ビット反転したビット列には、その文字列を含んでいない文書（番号）の一部は含まれないことになり、検索洩れが発生する。

そこで、本実施例では、ＮＯＴについては前側の検索文字列に対するビット列をＮＯＴの処理結果のビット列とする。その結果、ＮＯＴの処理結果には、後側の検索文字列を含む文書が含まれ、誤検索が発生する（誤検索は検索処理のステップ２で排除できるので、実用上は問題ない）。しかし、後側の検索文字列を含まない文書が含まれないことはなくなり、検索洩れを完全に防ぐことができる（検索洩れは検索処理のステップ２で救うことができないので、実用上の問題となる）。また、この方式では、後側の検索文字列を処理する必要がないので、文字成分表検索の高速化にも効果がある。

次に、多数の文書を一括して登録する場合について説明する。
文書から文字成分を抽出し、文字成分表を生成するまでの過程は、図９〜図１１に従って記述された実施例と同様に行われる。
これにより得られる文字成分表の構成は、図１８に示されるようにインデックスとビットマップデータから成る。インデックス部は、文字成分とビットマップデータへのポインタの対応表である。ビットマップデータは文字成分表の文書中に文字成分が出現するか否かを示す０，１のデータである。大量の文書を登録する場合に、ビットマップデータは巨大になることから、メモリ上には置かず二次記憶に置く。

二次記憶への登録の手法を特徴とするこの発明の実施例によると、一文書を登録するごとに文字成分表が生成され、その都度、直接二次記憶上の文字成分表に書き込むのではなく、一旦メモリ上に登録し、その後一括してメモリ上のデータを二次記憶の文字成分表に書き出す。図１８に一括登録時のデータ構成を示す。この例では、簡便のために二次記憶上のデータ構成とメモリ上の構成を同じにしている。一括文書登録時にはメモリ上のテーブルに一時的に登録したデータ（図中の網かけ）を処理の最後に二次記憶のビットマップテーブルにコピーし、登録処理を完了する。

さらに、当該文書管理装置のシステム内には、文書データを持たず、その代わりに文書の情報の一つとしてオリジナル文書のファイルシステム上での位置を示すディレクトリパス名を二次記憶上で管理し、参照にはディレクトリパス名を基に外部のファイルシステム上のオリジナル文書を直接参照するようになされている。
したがって、当該装置のシステム内部にオリジナルの文書データを持つ必要がなく、内部の二次記憶を無駄に利用しないだけではなく、該システムを介する煩わしさがなく、ユーザや他のアプリケーションによる登録文書の参照が可能となる。

また、文書の登録時にファイルシステム上の登録文書のオリジナルデータのディレクトリを指定し、そのディレクトリ内或いはその下位ディレクトリの文書をすべて登録しておき、当該文書管理装置において、該ディレクトリパス名を管理し、文書内容を参照する場合には、登録したディレクトリパス名を基に直接外部のファイルシステム上のオリジナルデータを参照するようになされている。
したがって、オリジナル文書をユーザが普段利用するファイルシステム上に置く場合には、一つのディレクトリ階層に存在する文書をそのまま当該文書管理装置で管理するシステムとすることが可能となる。また、ディレクトリを指定することによって、そのディレクトリ中に含まれる文書および下位のディレクトリ中に含まれる全文書を自動的に登録することができるようにすることで、ディレクトリ上の全文書を一つ一つユーザが指定する必要があったところの従来のユーザの負担を軽減することになる。

次に、上述したと同様に、ディレクトリパス名を基に直接外部のファイルシステム上のオリジナルデータを参照するようにした文書管理装置において、事前に当該装置に登録したい文書を置くディレクトリをューザが指定しておくと、当該装置は、そのディレクトリを常に監視し、文書の登録，更新，削除が行われた場合には、同じ操作を自動的に文字成分表に反映させ、登録，更新，削除を行う。このようにすることで、ユーザの文書操作の負担を軽減することができる。
ディレクトリを監視する方法としては、一定時間ごとに指定されたディレクトリの変化を調べる方法やＯＳなどの基本システムのファイル操作のシステムコールの処理を変更し、ファイル操作があった場合に文書管理システムに通知する方法などを採用し得る。

本発明による文書管理装置の一実施例を説明するための構成図である。 本発明における文字成分表の一例を示す図である。 本発明における文字成分表の他の例を示す図である。 本発明による文書管理装置の他の実施例を説明するための構成図である。 本発明における長い文字列をエントリとして持つ文字成分表の例を示す図である。 本発明における文字成分表のためのファイル構成の一例を示す図である。 本発明における文字成分表ファイルのブロック融合処理の概要（その１）を示す図である。 本発明における文字成分表ファイルのブロック融合処理の概要（その２）を示す図である。 本発明による文書管理装置の更に他の実施例を説明するための構成図である。 本発明における単一文字成分表を示す図である。 本発明における隣接文字成分表を示す図である。 従来の検索方式を説明するための図である。 本発明における検索方式（その１）を説明するための図である。 本発明における検索方式（その２）を説明するための図である。 本発明におけるデータ構成を示す図である。 本発明におけるまとめ上げ処理（その１）を説明するための図である。 本発明におけるまとめ上げ処理（その２）を説明するための図である。 本発明における一括登録処理の例を説明するための図である。

符号の説明

１…登録文書、２…文書登録手段、３…検索条件、４…文書検索手段、５…該当文書、６…文字成分表エントリ指定、７…文字成分表、８…文書本文データ、９…文書データベース、９-1〜９-n…文書データベース、１１…入力部、１２…処理部、１３…文字列入力処理部、１４…文書検索処理部、１５…文書出力処理部、１６…文書登録処理部、１７…データ部、１８…文字成分表、１９…出力部、２０…文書データ。

Claims (6)

1. 大量の文書データを保持し、入力装置から入力された検索文字列を含む文書を検索し、出力装置により検索した文書を出力する文書管理方法であって、文書登録時に文書より各文字コード成分及び２文字以上の隣接文字からビット列成分を算出し、各文書がそれぞれの成分を含むか否かを示す単一文字成分表及び一つ以上の隣接文字成分表を生成し、該文字成分表の可変長の各文字成分のエントリを複数の固定長ブロックに分割して二次記憶に登録し、検索時には検索文字列から登録時と同様に単一文字成分及び２文字以上の隣接文字成分を抽出し、該隣接文字成分に対応する二次記憶上の固定長ブロックを統合し、各文字エントリを生成して文書を検索する文書管理方法において、仮に文字エントリで文字成分が出現するビットを１とし、出現しないビットを０とした場合に、検索時に複数の文字エントリのビットマップのＡＮＤ処理を行う時に対象となる文字エントリを一つ適当に選択し、ビット列をスキャンして値が１である時だけ他のエントリの対応するビットを調べ、全てのエントリの対応するビットの値が１である文書を検索結果とすることにより、文字エントリのビットマップへのアクセスを最小限に全文検索を行うことを特徴とする文書管理方法。
2. 文字エントリごとに該文字エントリに出現する１のビットの個数をあらかじめ二次記憶に記録しておき、検索時に複数の文字エントリのビットマップのＡＮＤ処理を行う時に対象となる文字エントリのうち、該ビット出現数の最も少ない文字エントリを選択し、ビット列をスキャンして値が１である時だけビット出現数の少ない順に他の文字エントリの対応するビットを調べ、全ての文字エントリの対応するビットの値が１である文書を検索結果とすることにより、文字エントリのビットマップへのアクセスを最小限に抑え全文検索を行うことを特徴とする請求項１記載の文書管理方法。
3. 文字エントリの一部へのアクセスの場合に、文字エントリの全ブロックを読み出す必要がないように、可変長の文字エントリのビットマップデータを複数の固定長のブロックに分割して二次記憶に格納し、各固定長のブロックを管理するブロックテーブルを二次記憶上に有し、該ブロックテーブルから任意の固定長ブロックをアクセスできるようにすることによって、必要のない二次記憶上のブロックへのアクセスを減らして全文検索を行うことを特徴とする請求項２記載の文書管理方法。
4. 大量の文書データを保持し、入力装置から入力された検索文字列を含む文書を検索し、出力装置により検索した文書を出力する文書管理装置であって、文書登録時に文書より各文字コード成分及び２文字以上の隣接文字からビット列成分を算出し、各文書がそれぞれの成分を含むか否かを示す単一文字成分表及び一つ以上の隣接文字成分表を生成し、該文字成分表の可変長の各文字成分のエントリを複数の固定長ブロックに分割して二次記憶に登録する文書登録処理部と、検索時には検索文字列から登録時と同様に単一文字成分及び２文字以上の隣接文字成分を抽出する文字列入力処理部と、該隣接文字成分に対応する二次記憶上の固定長ブロックを統合し、各文字エントリを生成して文書を検索する文書検索処理部とを有する文書管理装置において、前記文書検索処理部は、仮に文字エントリで文字成分が出現するビットを１とし、出現しないビットを０とした場合に、検索時に複数の文字エントリのビットマップのＡＮＤ処理を行う時に対象となる文字エントリを一つ適当に選択し、ビット列をスキャンして値が１である時だけ他のエントリの対応するビットを調べ、全てのエントリの対応するビットの値が１である文書を検索結果とすることにより、文字エントリのビットマップへのアクセスを最小限に全文検索を行うことを特徴とする文書管理装置。
5. 前記文書検索処理部は、文字エントリごとに該文字エントリに出現する１のビットの個数をあらかじめ二次記憶に記録しておき、検索時に複数の文字エントリのビットマップのＡＮＤ処理を行う時に対象となる文字エントリのうち、該ビット出現数の最も少ない文字エントリを選択し、ビット列をスキャンして値が１である時だけビット出現数の少ない順に他の文字エントリの対応するビットを調べ、全ての文字エントリの対応するビットの値が１である文書を検索結果とすることにより、文字エントリのビットマップへのアクセスを最小限に抑え全文検索を行うことを特徴とする請求項４記載の文書管理装置。
6. 前記文書検索処理部は、文字エントリの一部へのアクセスの場合に、文字エントリの全ブロックを読み出す必要がないように、可変長の文字エントリのビットマップデータを複数の固定長のブロックに分割して二次記憶に格納し、各固定長のブロックを管理するブロックテーブルを二次記憶上に有し、該ブロックテーブルから任意の固定長ブロックをアクセスできるようにすることによって、必要のない二次記憶上のブロックへのアクセスを減らして全文検索を行うことを特徴とする請求項５記載の文書管理装置。