JP3563823B2 - 文書管理装置 - Google Patents

Description

【０００１】
【産業上の利用分野】
本発明は、文書管理装置に関し、より詳細には、文字成分表を利用し、全文書に対して文字列を検索する文書管理装置に関するもので、例えば、文書管理システムや画像管理システム，データベース管理システム等に適用し得るものである。
【０００２】
【従来の技術】
従来の文書管理装置について記載した公知文献としては、例えば、特開平５−３２４７２２号公報がある。この公報のものは、文字列検索において、利用する文字成分表を小さく抑え、かつ、検索程度を上げ、高速な文書登録を可能とするために、入力部に入力された検索文字列は、処理部の文字列入力処理で処理し、文書検索処理部において、データ部の文字成分表を利用して文字列を含むと思われる文書を検索する。検索した文書に対応する文書データを文書出力処理により出力部に出力し、文書登録処理では、登録する文書を文書データに登録し、文書データより文字成分を抽出して文字成分表に登録する。検索文字列を文書から検索する場合、文字成分表として、文字から算出される値が文書中に存在するか否かを示す１文字成分表及び隣接する文字から算出される値が文書中に存在するか否かを示す隣接文字成分表を利用して文書を検索する。すなわち、文書ごとに出現した文字を記録した文字成分表を用いて文書を高速に検索するシステムである。
【０００３】
また、前述した特開平５−３２４７２２号公報や、先に提案した特願平５−２９８４３３号に記載のものは、文字成分が文書中に存在するか否かを示す単一文字成分表、及び隣接する文字から抽出したある文字成分が文書中に存在するか否かを示す隣接文字成分表を利用して文書を検索するものである。
【０００４】
【発明が解決しようとする課題】
しかし、前記公報等に記載の方式には、以下に示すような問題点がある。
▲１▼．文字成分表の構成が固定的だった。
▲２▼．検索文字列が長くなるのに応じて検索時間がかかる。
▲３▼．単一の文字列しか検索条件として指定できない。そのため、複数の文字列を論理演算子（ＡＮＤ，ＯＲ）で組み合わせた条件を満たす文書を検索することができない。
▲４▼．文字成分表のビットマップデータを格納するブロックの大きさ（ブロックサイズ）が固定的であるため、ブロックサイズを小さくすると検索速度が低下し、ブロックサイズを大きくすると登録速度が低下してしまう。
▲５▼．複数の文書を一括して登録する機能がなく、多量の文書を登録するのに処理時間がかかる。
▲６▼．文書のデータがシステム内にあるので、ユーザにとって参照するのに手間がかかったり、文書の登録，削除，更新などの処理が面倒である。
【０００５】
本発明は、このような実情に鑑みてなされたもので、▲１▼文字成分表の構成を目的に合わせて変更できるようにすること、▲２▼重複エントリを単一化して最適化すること、また、文字成分表のエントリに３文字以上のものを含めること、▲３▼論理演算子に対応すること、また、論理演算子に合わせた最適化すること、▲４▼ブロックサイズに大小２種類用意すること、▲５▼従来の文字成分表ではデータブロックが小さく二次記憶上で分散し、広範囲の二次記憶をアクセスすることになり、検索速度が遅いので、それを改善すること、▲６▼従来では文字エントリへのアクセス、つまり二次記憶へのアクセスが多く、検索速度の低下を招いていたので、それを改善すること、▲７▼多数の文書の登録処理の速度を改善すること、▲８▼ユーザや他のアプリケーションによる登録文書の参照を容易にすること、▲９▼複数の文書の登録時の文書指定を容易にすること、また、文書の登録，更新，削除があった場合に当該装置の文書管理の自動化を行うようにした文書管理装置を提供することを目的としている。
【０００６】
【課題を解決するための手段】
本発明は、上記目的を達成するために、（１）登録文書を保存するとともに、該登録文書に含まれる各文字あるいは連続する２文字から算出される値を文字成分表に登録し記録する文書登録手段と、前記文字成分表を用いて検索条件に該当する文書を高速に探し出す文書検索手段とを有し、前記文書登録手段は、前記文字成分表の構成を指定した文字成分表エントリ指定を参照して前記登録文書から文字成分を抽出し、該文字成分から文字成分表エントリを計算して前記文字成分表を作成するようにし、前記文書検索手段は、前記文字成分表エントリ指定を参照して検索文字列から文字成分を抽出して、該抽出した文字成分から文字成分表エントリを計算して検索するようにしたこと、或いは、（２）前記（１）において、前記文書登録手段は、前記登録文書を複数に分類してそれぞれ別々のフォルダに分割して管理可能で、かつ、該フォルダに登録された登録文書に対する文字成分表の構成を指定する文字成分表エントリ指定を持たせるようにしたこと、或いは、（３）前記（１）において、前記文書検索手段で単一の文字列から抽出される文字成分に同一のものが２個以上ある場合、前記文字成分表の文字成分に対するアクセスを一回しか行わないこと、或いは、（４）前記（１）において、文字成分の算出値として、連続する３文字以上の文字列から算出される値をも用いること、或いは、（５）前記（４）において、文書登録時の文字成分の算出において、連続する３文字以上の文字列から算出される値を用いる場合には、該文字列から１文字あるいは連続する２文字から算出される値を文字成分表に登録しないこと、或いは、（６）前記（１）において、前記文書検索手段において、単一の文字列あるいは複数の文字列をＡＮＤ論理演算子あるいはＯＲ論理演算子で組み合わせた検索条件を処理可能とすること、或いは、（７）前記（６）において、前記文書検索手段でＡＮＤ論理演算子で結合される２つの文字列から抽出される文字成分に同一のものが２個以上ある場合、文字成分表の文字成分に対するアクセスを一回しか行わないこと、或いは、（８）前記（６）において、前記文書検索手段でＯＲ論理演算子で結合される２つの文字列から抽出される文字成分に同一のものが２個以上ある場合、文字成分表の文字成分に対するアクセスを一回しか行わないこと、或いは、（９）前記（１）において、前記文字成分表を、該文字成分表を保存する大小２種類のブロックから構成されるデータファイルと、文字成分ごとのブロック位置を記録するインデックスファイルによって記憶し、複数の小さいブロックを大きいブロックにまとめるブロック融合手段を有すること、或いは、（１０）前記（９）において、前記ブロック融合手段において、データファイルの前方に大きいブロックをまとめ、後方に小さいブロックをまとめること、或いは、（１１）前記（１０）において、前記ブロック融合手段において、データファイルの小さいブロックが存在する領域のみをブロック融合の対象とすること、或いは、（１２）前記（９）において、前記ブロック融合手段において、検索時に高速に文字成分表エントリを二次記憶から読み出すために、複数の固定長ブロックに分割された各文字成分表エントリを大きな固定長ブロックにまとめあげる時に大きな固定長ブロックをアロケートの単位とし、まとめ上げられた大きな固定長ブロック及びまとめあげられなかった残りの小さな固定長ブロックを詰め込んだ大きな固定長ブロックを順時書き出すことによって、文字成分表のデータを一回のスキャンで処理し、高速にかつ処理時に必要な二次記憶領域を最小限に抑えること、或いは、（１３）前記（１）において、前記文字成分表の構成を、文書の各文字および連続する２文字から算出される値を記録するものとした場合、前記文書検索手段が検索文字列から、連続する２文字から算出される値のみを抽出すること、或いは、（１４）前記（１３）において、前記文書検索手段が、検索文字列からの連続する２文字から算出される値と、該検索文字列の末尾の１文字から算出される値を抽出すること、或いは、（１５）前記（１３）において、前記文書検索手段が、検索文字列からの連続する２文字から算出される値と、該検索文字列の先頭の１文字から算出される値を抽出すること、或いは、（１６）前記（１５）において、前記文字成分表の構成を連続する３文字以上の文字列から算出される値をも用いる場合、前記文書検索手段が、検索文字列から前記文字エントリが抽出される時には、該文字列エントリに対応する文字列に含まれる１文字あるいは前記文字列にその前後の文字を含めた文字列に含まれる２文字から算出される値を抽出しないこと、或いは、（１７）前記（１３）において、前記文書検索手段が、単一の文字列あるいは複数の文字列を「論理積」,「論理和」あるいは「論理差」論理演算子で組み合わせた検索条件を処理可能なこと、或いは、（１８）前記（１７）において、前記文書検索手段で「論理差」で結合される２つの文字列の処理において、後側の文字列を処理しないこと、或いは、（１９）前記（１）において、前記文書登録手段が、多数の文書を一括して登録する場合に、一文書を登録するごとに生成された文字成分表データを直接二次記憶上の文字成分表に書き込むのではなく一旦メモリ上に登録し、その後、一括してメモリ上の文字成分表データを二次記憶の文字成分表に書き出すことによって、高速に文書の一括登録を行うこと、或いは、（２０）前記（１）において、前記文書登録手段により登録されたファイルシステム上の登録文書のディレクトリパス名を二次記憶上で管理し、文書内容を参照する場合には、登録したディレクトリパス名を基に直接ファイルシステム上のオリジナルデータを参照することによって、文書管理システムが内部にオリジナルデータを持つ必要がないだけでなく、ユーザや他のアプリケーションによる登録文書の参照を容易にすること、或いは、（２１）前記（１）において、前記文書登録手段により登録されたファイルシステム上の登録文書のオリジナルデータのディレクトリパス名を管理し、文書内容を参照する場合には、登録したディレクトリパス名を基に直接ファイルシステム上のオリジナルデータを参照するようにし、文書の登録時にディレクトリを指定し、そのディレクトリ内およびその下位ディレクトリの文書をすべて登録することにより、複数の文書の登録時の文書指定を容易にすること、或いは、（２２）前記（１）において、前記文書登録手段により登録されたファイルシステム上の登録文書のオリジナルデータのディレクトリパス名を管理し、文書内容を参照する時には、登録したディレクトリパス名を基に直接ファイルシステム上のオリジナルデータを参照するようにし、あらかじめ登録対象とするディレクトリを指定しておき、そのディレクトリ上での文書の登録，更新，削除を常に監視し、文書の登録，更新，削除があった場合には、自動的に当該の文書について文字成分表に登録，更新，削除を行うことによって、ユーザの文書管理の手間を削減することを特徴としたものである。
【０００７】
【作用】
本発明の文書管理装置は、（１）登録文書を保存するとともに、該登録文書に含まれる各文字あるいは連続する２文字から算出される値を文字成分表に登録し記録する文書登録手段と、前記文字成分表を用いて検索条件に該当する文書を高速に探し出す文書検索手段とを有しており、前記文字成分表エントリ指定により文字成分表の構成を変更可能とし、前記登録文書を複数のフォルダに分割して管理可能で、かつフォルダごとに文字成分表エントリ指定できるようにし、文字成分表の構成を目的に合わせて変更できるようにしたため、効率的な文書管理システムを構築できる。
【０００８】
（２）前記文書検索手段で単一の文字列から抽出される文字成分に同一のものが２個以上ある場合、前記文字成分表の文字成分に対するアクセスを一回しか行わないようにし、また、文字成分の算出において、連続する３文字以上の文字列から算出される値をも用いるようにし、さらに、文書登録時の文字成分の算出において、連続する３文字以上の文字列から算出される値を用いる場合には、該文字列から１文字あるいは連続する２文字から算出される値を文字成分表に登録しないようにしたので、検索文字列が長い場合でも、高速に文書検索できる。
【０００９】
（３）前記文書検索手段において、単一の文字列あるいは複数の文字列をＡＮＤあるいはＯＲ論理演算子で組み合わせた検索条件を処理可能とし、また、前記文書検索手段でＡＮＤ論理演算子で結合される２つの文字列から抽出される文字成分に同一のものが２個以上ある場合、文字成分表の文字成分に対するアクセスを一回しか行わないようにし、さらに、前記文書検索手段でＯＲ論理演算子で結合される２つの文字列から抽出される文字成分に同一のものが２個以上ある場合、文字成分表の文字成分に対するアクセスを一回しか行わないようにした。検索条件を複数の文字列を論理演算子（ＡＮＤ，ＯＲ）で組み合わせで表現できるので、複雑な検索要求を表現することが可能となる。また、論理演算子に合わせた最適化を行うので、高速に文書検索できる。
【００１０】
（４）前記文字成分表を、該文字成分表を保存する大小２種類のブロックから構成されるデータファイルと、文字成分ごとのブロック位置を記録するインデックスファイルによって記憶し、複数の小さいブロックを大きいブロックにまとめるブロック融合手段を有し、また、前記ブロック融合手段において、データファイルの前方に大きいブロックをまとめ、後方に小さいブロックをまとめるようにし、さらに、前記ブロック融合手段において、データファイルの小さいブロックが存在する領域のみをブロック融合の対象とするようにし、文字成分表のビットマップデータを格納するブロックの大きさに大小２種類用意したため、登録／検索速度をともに高速化できる。
【００１１】
（５）前記ブロック融合手段において、検索時に高速に文字成分表エントリを二次記憶から読み出すために、複数の固定長ブロックに分割された各文字成分表エントリを大きな固定長ブロックにまとめあげる時に大きな固定長ブロックをアロケートの単位とし、まとめ上げられた大きな固定長ブロック及びまとめあげられなかった残りの小さな固定長ブロックを詰め込んだ大きな固定長ブロックを順時書き出すことによって、文字成分表のデータを一回のスキャンで処理し、高速にかつ処理時に必要な二次記憶領域を最小限に抑えるようにし、文字エントリの小さなブロックを大きなブロックにまとめ上げることにより、検索速度が向上する。
【００１２】
（６）特定のビットマップのビットを横方向に順時調べ、ビットが１の場合には、他のビットマップエントリの対応するビットを調べる。つまり、縦方向にビットを調べ、すべてのビットが１の場合は、ビットに対応する文書が検索結果の文書となるようにする。また、各文字エントリ中に出現するビット１の出現数を予めカウントしておき、前述のビットを調べる処理の時にビット出現数が小さい順に並び代え、同様の処理を行うことによって、さらに参照するデータ量を減らすことが可能となる。さらに、文字エントリの一部しか参照しない場合には、全ブロックをアクセスすることなしにブロックテーブルから直接該当するブロックを得られ、高速に検索することができる。このように従来技術では文字エントリのアクセスが多く、検索速度の低下を招いていたが、検索時の処理のアルゴリズム及びデータ構成を変えることによって検索速度が向上する。
【００１３】
（７）前記文字成分表の構成を文書の各文字および連続する２文字から算出される値を記録するものとした場合、前記文書検索手段が検索文字列から連続する２文字から算出される値のみを抽出し、また、前記文書検索手段が検索文字列から連続する２文字から算出される値と、該検索文字列の末尾の１文字から算出される値を抽出し、また、検索文字列から連続する２文字から算出される値と、該検索文字列の先頭の１文字から算出される値を抽出し、さらに、前記文字成分表の構成を連続する３文字以上の文字列から算出される値をも用いる場合、前記文書検索手段が検索文字列から前記文字エントリが抽出される時には、該文字列エントリに対応する文字列に含まれる１文字あるいは前記文字列にその前後の文字を含めた文字列に含まれる２文字から算出される値を抽出しないようにしたので、検索処理において検索文字列から抽出するエントリ数が削減され、検索処理を高速化できる。
【００１４】
（８）前記文書検索手段が単一の文字列あるいは複数の文字列を「論理積」，「論理和」あるいは「論理差」論理演算子で組み合わせた検索条件を処理可能とし、また、前記文書検索手段で「論理差」で結合される２つの文字列の処理において、後側の文字列を処理しないことにしたので、検索条件を複数の文字列を論理演算子（ＡＮＤ，ＯＲ，ＮＯＴ）で組み合わせで表現できるので、複雑な検索要求を表現することが可能となる。また、論理演算子に合わせた最適化を行うので、高速に文書検索できる。
【００１５】
（９）多数の文書を一括して登録する場合に、一文書を登録するごとに生成された文字成分表データを直接二次記憶上の文字成分表に書き込むのではなく、多数の文書を一括して登録するには、従来の方法では文字成分表データが二次記憶上にある場合には、一文書を登録するごとに二次記憶にアクセスすることになり、速度が遅い。そこで、一括登録する文書については、一旦メモリ上に文字成分表を一時的に生成登録し、その後、処理の最後にメモリ上の文字成分表データを二次記憶上の文書成分表データにアペンドする。こうすることによって、二次記憶へのアクセスが減り、高速に複数文書の一括登録が可能となる。
【００１６】
（１０）当該文書管理装置のシステム内には、文書データを持たず、その代わりに文書の情報の一つとして、オリジナル文書のファイルシステム上での位置を示すディレクトリパス名を管理する。参照には、ディレクトリパス名を基にファイルシステム上のオリジナル文書を直接参照することになるので、当該装置のシステムが内部にオリジナルデータを持つ必要がなく、二次記憶を無駄に利用しないだけでなく、システムを介することなくユーザや他のアプリケーションによる登録文書の参照が可能となる。
【００１７】
（１１）文書の登録時にディレクトリを指定し、そのディレクトリ内およびその下位ディレクトリの文書をすべて登録することにより、文書管理装置においてファイルシステム上の登録文書のオリジナルデータの該ディレクトリパス名を管理する。文書内容を参照する場合には、登録したディレクトリパス名を基に直接ファイルシステム上のオリジナルデータを参照するようになし得る。
この様なことで、オリジナル文書をユーザが普段利用するファイルシステム上に置く場合には、一つのディレクトリ階層に存在する文書をそのまま文書管理装置で管理するシステムとすることが可能となる。また、ディレクトリを指定することによって、そのディレクトリ中に含まれる文書または下位のディレクトリ中に含まれる全文書を自動的に登録することができるようにすることで、ディレクトリ上の全文書を一つ一つユーザが指定する必要があった従来のユーザの負担を軽減することができる。
【００１８】
（１２）当該文書管理装置では、ファイルシステム上の登録文書のオリジナルデータのディレクトリパス名を管理する。文書内容を参照する時には、登録したディレクトリパス名を基に直接ファイルシステム上のオリジナルデータを参照することになり、また、事前に当該文書管理装置に登録したい文書を置くディレクトリをユーザが指定しておくと、当該装置のシステムは、そのディレクトリ上での文書の登録，更新，削除を常に監視し、文書の登録，更新，削除が行われた場合には、同じ操作を自動的に文字成分表に反映させ、登録，更新，削除を行う。このようにすることで、ユーザの文書操作の負担を軽減することができる。
【００１９】
【実施例】
実施例について、図面を参照して以下に説明する。
図１は、本発明による文書管理装置の一実施例（請求項１）を説明するための構成図で、図中、１は登録文書、２は文書登録手段、３は検索条件、４は文書検索手段、５は該当文書、６は文字成分表エントリ指定、７は文字成分表、８は文書本文データ、９は文書データベースである。
【００２０】
文書登録手段２は、登録文書１を文書データベース９に登録操作を行う。該文書データベース９には、文書本文データ８と文字成分表７と文字成分表エントリ指定６とが含まれる。文字成分表７とは、登録文書１に含まれる各文字あるいは文字列から抽出された情報の存在の有無を文書ごとに記録した表である。文書登録手段２は、登録文書１を保存するとともに、該登録文書１に含まれる各文字あるいは連続する２文字から算出される値を文字成分表７に登録し記録する。文書検索手段４は、前記文字成分表７を用いて検索条件３に該当する文書５を高速に探し出す。文字成分表エントリ指定６により文字成分表７の構成を変更可能とする。
【００２１】
図２は、文字成分表の一例を示す図である。
ここで示した文字成分表では、各文字の出現のみを記録した構成である。これは、各文字のコードに関数を作用させ、算出される値をエントリとするものである（各文字の出現をそのまま記録する図２の方式は、関数としてｆ（ｘ）＝ｘとしたものである）。このような１文字から算出されるエントリを単一文字エントリと呼ぶ。
【００２２】
図３は、文字成分表の他の例を示す図である。
ここで示した文字成分表では、各文字と連続する２文字からそれぞれの文字コードの下位４ビットをビット連結して得られる値をエントリとしている。例えば、「ぐ」，「だ」，「ば」のＪＩＳコードは、各々 ０ｘ２４３０，０ｘ２４４０，０ｘ２４５０ であり、下位４ビットを連結して得られる８ビットを文字成分表のエントリとした場合、「ぐぐ」，「ぐだ」，「ぐば」…は全て同じ ０ｘ００ のエントリにまとめられる。すなわち、連続する２文字のコードに関数を作用させ、算出される値をエントリとすることができる（前側の文字ｘ，後側の文字ｙに対して、関数ｇ（ｘ，ｙ）の値をエントリとする）。このような連続する２文字から算出されるエントリ（文字成分）を隣接文字エントリと呼ぶ。図３の文字成分表は、単一文字エントリと隣接文字エントリを組み合わせたものである。
【００２３】
このように、文字成分表には様々な構成が可能であり、本発明では、図１の文字成分表エントリ指定６によって文字成分表７の構成を指定できるものとする。以下の説明では、簡単のため、図２のような各文字の出現のみを記録した文字成分表を使用するものとする。
【００２４】
文書登録手順は、次の通りである。
▲１▼．登録文書１を文書本文データ８に登録する。
▲２▼．登録文書１の内容を文字成分表７に登録する。
文書本文から文字成分表エントリ指定６で規定されるエントリを抽出する。登録文書番号をｉ，抽出されたエントリ番号をｊとした場合、すべてのｊについて文字成分表の点（ｉ，ｊ）の値を“１”にする。
【００２５】
また、文書検索手順は、次の通りである。
▲１▼．文字成分表７を用いて検索文字列を含む可能性のある文書番号を求める。
（ａ）検索文字列から文字成分表エントリ指定６で規定されるエントリを抽出する。
（ｂ）抽出された全てのエントリのビットマップ（図２の横一列）を文字成分表から抜きだし、ビットＡＮＤをとる。
▲２▼．前記▲１▼で求まった文書番号の文書本文を文書本文データ８から読みだし、検索文字列が含まれているか調べ、含まれている文書集合を検索結果とする。
【００２６】
文字成分表の検索精度（文字成分表を用いて得られる文書に検索文字列が含まれている割合）は文字成分表の構成に依存する。本発明では、文字成分表エントリ指定により、文字成分表の構成を任意に変更できる。そのため、登録される文書に合わせて効率的な文書管理システムを構築できる。
【００２７】
次に、請求項２に記載の発明について説明する。
図４は、本発明による文書管理装置の他の実施例（請求項２）を説明するための構成図で、図中、９−１〜９−ｎは文書データベースで、その他、図１と同じ作用をする部分は同一の符号を付してある。なお、図１の構成と異なる点は、文書データベース９−１〜９−ｎが多数存在している点である。
文書には様々な用途のものがあるため、異なる文書集合は異なる文書データベースに保存することが望まれる。その際、異なる文書集合は、文書の長さや文字の出現頻度なども違う。そこで、本発明の文書管理装置では、文書データベース９ごとに文字成分表エントリ指定６を異なったものを用いることができるため、効率的な文書管理を行える。
【００２８】
次に、請求項３に記載の発明について説明する。
これまでの方式だと、検索文字列が長くなるに従い、文字成分表でアクセスすべきエントリが増加するため、検索速度が低下する。実際には、検索語から算出される文字成分表エントリにも同一のものが含まれることがある。その場合、そのエントリに複数回アクセスする必要はないため、検索語に複数個出現したエントリへのアクセスを一回に押えることで、検索に必要な文字成分表へのアクセス回数を減らし、検索を高速化できる。
【００２９】
例えば、図２の文字成分表を用いた場合、検索語「マンマシンシステム」は９文字から構成されているため、文字成分表には「マ」「ン」「マ」「シ」「ン」「シ」「ス」「テ」「ム」の９回のアクセスが必要になる。しかし、実際には、「マ」「ン」「シ」は２回ずつ出現しているため、これらエントリへのアクセスは１回にまとめることができる。すなわち、文字成分表への実際のアクセスは、「マ」「ン」「シ」「ス」「テ」「ム」の６回ですむ。
【００３０】
次に、請求項４に記載の発明について説明する。
これまでの方式だと、文字成分表のエントリは最大２文字からのみ構成される。これに対し、３文字以上の長い文字列（から算出される値）をエントリに用いることとすれば、文字成分表へのアクセス回数を減らし、検索を大幅に高速化できる。
図５は、長い文字列をエントリとして持つ文字成分表を示す図である。
「システム」「パターン」などが文字列エントリである。文字列エントリは、文書における出現頻度の高い文字列を選出すれば良い。
【００３１】
登録時には、「…あのマンマシンシステムは…」からは、文字として「あ」「の」「マ」「ン」「シ」「ス」「テ」「ム」「は」、文字列として「システム」が抽出され、文字成分表に記録される。
検索時には、検索語「マンマシンシステム」からは、文字として「マ」「ン」「マ」「シ」「ン」、文字列として「システム」が抽出されるが、「システム」に含まれる「シ」および単一文字の重複を削除する。結局、「マ」「ン」「システム」の３つのエントリにアクセスするだけでよく、検索時間は大幅に短縮できる。
【００３２】
次に、請求項５に記載の発明について説明する。
前記請求項４に記載した方式では、文書登録時に文字列エントリに含まれる文字エントリも抽出し、文字成分表に記録する。しかし、その部分は、通常検索文字列でも文字列として含まれる場合が多いので、文字成分表に記録する必要は必ずしもない。このような文字エントリを登録しないことにより、文字成分表を小型化することができる。
【００３３】
例えば、前項の例文「…あのマンマシンシステムは…」の登録時には、文字として登録するのは「あ」「の」「マ」「ン」「は」だけでよい（文字列として「システムが抽出され、文字成分表に記録される）。ただし、検索文字列に文字列エントリの部分文字列が含まれている場合、この方式では、検索洩れが起こり得る。例えば、検索文字列が「システ」の場合（「システム」の部分文字列）、この方式では検索できないことになる。
【００３４】
次に、請求項６に記載の発明について説明する。
本実施例では、検索条件として複数の文字列を論理演算子（ＡＮＤ，ＯＲ）で組み合わせたものを受け付ける（単一の文字列もこの検索条件に含める）。ここで、“ＡＮＤ”は前後の文字列をともに含む文書を検索すること、“ＯＲ”は前後の文字列を少なくとも一つ含む文書を検索することを意味する。さらに、必要に応じて、演算子の作用順序を明示するために、“（”，“）”を用いることができるものとする。論理演算子を検索条件に用いることができるようにすることで、複雑な検索要求を表現することが可能となる。例えば、「マンマシンシステム」，「文書検索ＡＮＤ文書登録」，「文書検索ＯＲ情報検索」，「（新聞ＯＲ雑誌）ＡＮＤカラー」などが上記の検索条件になる。
【００３５】
次に、請求項７に記載の発明について説明する。
前記請求項３に記載の発明では、単一の検索文字列内のアクセスの単一化を提案したが、ここでは、論理演算子ＡＮＤで結合される２つないしはそれ以上の検索文字列にまたがったアクセスの単一化を導入する。例えば、検索条件「文書検索ＡＮＤ文書登録」から、従来方式では、「文」「書」「検」「索」「文」「書」「登」「録」の８つのエントリにアクセスする。一方、本項目の単一化（最適化）により「文」「書」の重複が削除され、文字成分表へのアクセスは６回に減らすことができる。
【００３６】
次に、請求項８に記載の発明について説明する。
前記請求項３に記載の発明では、単一の検索文字列内のアクセスの単一化を提案したが、ここでは、論理演算子ＯＲで結合される２つないしはそれ以上の検索文字列にまたがったアクセスの単一化を導入する。例えば、検索条件「文書検索ＯＲ情報検索」から、従来方式では、「文」「書」「検」「索」「情」「報」「検」「索」の８つのエントリにアクセスする。一方、本項目の単一化（最適化）により「検」「索」の重複が削除され、文字成分表へのアクセスは６回に減らすことができる。
【００３７】
次に、請求項９に記載の発明について説明する。
文字成分表は、ファイルとして保存される。文字成分表ファイルの構成は、文字成分表のエントリに対応するビットマップデータに簡単にアクセスできることが望まれるが、それを実現するために、例えば、インデックスファイルと固定長ブロックから構成されるビットマップデータファイルの２つのファイルで構成することができる。この場合、インデックスファイルは、次の２つのフィールドを含むブロックから構成することができる。
・先頭ブロックオフセットフィールド
・末尾ブロックオフセットフィールド
【００３８】
インデックスファイルに含まれるブロック数は、文字成分表エントリ指定によって決まる。ビットマップデータファイルは、次の２つのフィールドを含むブロックから構成される。
・次ブロックオフセットフィールド
・データフィールド
【００３９】
ブロックサイズは、性能要求に合わせて数十バイトから数キロバイトの範囲に設定すれば良い。
図６（ａ）は、文字成分表のためのファイル構成の一例を示す図である。なお、インデックスファイルを半導体メモリ上にロードしておくことは、高速化に有効である。
【００４０】
ビットマップデータファイルのブロックサイズは、登録・検索性能等に与える影響が大きい。ブロックサイズが大きい場合、検索は高速だが登録が遅く、小さい場合、登録は高速だが検索は遅くなる。また、データファイルのうち、ビットマップデータの記録に使用されていない領域の割合は、そこで、ブロックを大きいものと小さいものの２種類を用意する。以下では、小さいブロックを「バケット」、大きいブロックを「コンテナ」と呼び、コンテナとバケットの大きさの比を「Ｍ」と書くこととする。コンテナの大きさは、バケットの数倍から十数倍程度とする（Ｍ＝数倍〜十数）。
【００４１】
図６（ｂ）は、２種類の大きさのブロックを導入した場合の文字成分表のファイル構成の一例を示す図である。ここでは、ブロックオフセットの最上位ビットが“１”，“０”によって、そのオフセット位置のブロックがコンテナかバケットかを示すようにしている。
【００４２】
文書検索システム利用開始時点では、ブロックサイズを小さいものとして、登録速度を優先する（登録文書数が少ない間は、検索速度が多少遅くても検索時間が小さいので、ほとんど問題とならない）。多数の文書が登録され、ビットマップデータファイルに含まれるブロック数が増大した段階で、複数のバケットをコンテナにまとめあげるブロック融合処理を行う。通常のオペレーティングシステムでは、データを小さいブロックに分割しておくよりも大きいブロックにまとめておく方がアクセスが高速だからである。その結果、ブロック融合処理により検索速度が向上され、登録文書数が多い場合でも検索時間を小さくできる。
【００４３】
ブロック融合処理手順▲１▼
▲１▼．書き出し用の一時ファイルを作成する。
▲２▼．文字成分表を構成する全てのエントリのビットマップデータに対して、次の処理を行う。
（ａ）コンテナはそのまま一時ファイルに書き出す。
（ｂ）コンテナにまとめ上げられる（Ｍ個の）バケットは、１個のコンテナとし、一時ファイルに書き出す。
（ｃ）残りのコンテナにまとめ上げられない（Ｍ個未満の）バケットは、一時ファイルに書き出す。
▲３▼．これまでのビットマップデータファイルを削除する。
▲４▼．一時ファイルを新たなビットマップデータファイルとする。
【００４４】
図７（ａ），（ｂ）は、ブロック融合処理の概要を示す図である。
網掛けによって各バケット／コンテナがどのエントリ（ここでは文字ごとにエントリを立てている）に対応しているかを示す。ここでは、コンテナはバケットの８倍の大きさとしている。例えば、「あ」は、融合処理前にバケット１７個なので、融合処理後はコンテナ２個とバケット１個になる。「い」は、同様にしてバケット１１個がコンテナ１個とバケット３個になる。「う」は、バケットが７個しかないので、コンテナには１個も生成されず、バケット７個のままである（ただし、この場合でもバケットがお互いに隣接する位置に配置されるため、アクセスが高速化され、検索速度が向上する）。
【００４５】
次に、請求項１０に記載の発明について説明する。
前述の方式では、データファイル中にバケットとコンテナが混在する。２次記憶装置上のデータへのアクセスは、オペレーティングシステムの最適化などによりページ単位に行われるため、バケットとコンテナが混在していると、コンテナのような大きいブロックを導入しても、コンテナの配置が２次記憶装置のページ境界と一致せず、期待通りの性能向上が行われないことがある。そこで、本発明の方法では、データファイルの前方にコンテナをまとめ、後方にブロックをまとめることで、コンテナを必ずページ境界に配置し、性能向上を図る。
【００４６】
ブロック融合処理手順▲２▼
▲１▼．書き出し用の一時ファイルを２つ作成する。１つを「コンテナ用一時ファイル」、もう１つを「バケット用一時ファイル」と呼ぶ。
▲２▼．文字成分表を構成する全てのエントリのビットマップデータに対して、次の処理を行う。
（ａ）コンテナはそのままコンテナ用一時ファイルに書き出す。
（ｂ）コンテナにまとめ上げられる（Ｍ個の）バケットは１個のコンテナとし、コンテナ用一時ファイルに書き出す。
（ｃ）残りのコンテナにまとめ上げられない（Ｍ個未満の）バケットは、バケット用一時ファイルに書き出す。
▲３▼．これまでのビットマップデータファイルを削除する。
▲４▼．コンテナ用一時ファイルにバケット用一時ファイルを連結し、新たなビットマップデータファイルとする。
【００４７】
図７（ａ），（ｃ）は、上記アルゴリズムによるブロック融合処理の概要を示す図である。このアルゴリズムでは、ブロック融合処理後（図７（ｃ）の状態）は、データファイルの先頭部分にコンテナが集まり、Ａ点以降はバケットが集合した状態となる。
【００４８】
次に、請求項１１に記載の発明について説明する。
ブロック融合処理後にも文書は追加登録される。追加登録後のブロックタイプはバケットなので、追加登録文書数が増大すると、再び検索速度が低下してしまう。その場合、再びブロック融合処理手順▲２▼によりブロック融合処理を行えばよい。しかし、ブロック融合処理手順▲２▼では、２つの一時ファイルの大きさの合計は、データファイルとほぼ等しくなってしまう。多量の文書が登録された場合、データファイルの大きさが膨大となるため、これは極めて望ましくない。次に示すブロック融合処理手順▲３▼はこの点を改良し、一時ファイルの大きさの合計をデータファイルのバケット部分の大きさ程度で済むようにした。
【００４９】
ブロック融合処理手順▲３▼
▲１▼．書き出し用の一時ファイルを２つ作成する。１つを「コンテナ用一時ファイル」、もう１つを「バケット用一時ファイル」と呼ぶ。
▲２▼．文字成分表を構成する全てのエントリのビットマップデータに対して、次の処理を行う。
（ａ）コンテナは無視する。
（ｂ）コンテナにまとめ上げられる（Ｍ個の）バケットは、１個のコンテナとし、コンテナ用一時ファイルに書き出す。
（ｃ）残りのコンテナにまとめ上げられない（Ｍ個未満の）バケットは、バケット用一時ファイルに書き出す。
▲３▼．ビットマップデータファイルのバケット部分を削除する。
▲４▼．ビットマップデータファイルにコンテナ用一時ファイル、さらにバケット用一時ファイルを連結する。
【００５０】
前記請求項１０及び請求項１１に記載の方式の相違を図８（ａ）〜（ｃ）に示す。図８（ａ）に示すように、バケット融合処理後に再び文書が登録された場合、データファイルの末尾（図８（ａ）のＢ点）からバケットが順次挿入された状態になる。ブロック融合処理手順▲２▼では、図８（ｂ）のように、データファイルのブロックが整理され、検索速度が向上する。しかし、２つの一時ファイルの合計の大きさは、データファイルの大きさと等しい。これに対し、本項で提案するブロック融合処理手順▲３▼では、データファイルのＡ点以降の部分のみを処理の対象とする。ブロック融合処理結果を示したものが図８（ｃ）である。新たに作成されたコンテナは、融合前にバケットが存在していたＡ点以降に配置される。同一エントリに対するコンテナが必ずしも連続する位置に配置されるわけではないが（例えば、「い」のコンテナ）、そのことにより速度低下は極めて小さい。
【００５１】
図９は、本発明による文書管理装置の更に他の実施例（請求項１２）を説明するための構成図で、図中、１１は入力部、１２は処理部、１３は文字列入力処理部、１４は文書検索処理部、１５は文書出力処理部、１６は文書登録処理部、１７はデータ部、１８は文字成分表、１９は出力部、２０は文書データである。
【００５２】
入力部１１に入力された検索文字列は、処理部１２の文字列入力処理１３で処理する。文書検索処理部１４においてデータ部１７の文字成分表１８を利用して文字列を含むと思われる文書を検索する。そして、検索した文書に対応する文書データ２０を文書出力装置１５により出力部１９に出力する。文書登録処理部１６では、登録する文書を文書データ２０に登録し、該文書データ２０より文字成分を抽出して文字成分表１８に登録する。
以下の説明では、対象文書は１バイト文字コード（例えば、ＡＳＣＩＩ）及び２バイト文字コード（ＥＵＣ：Ｅｘｔｅｎｄｅｄ ＵＮＩＸ ＣＯＤＥ）からなるテキストデータとする。しかし、対象とする文字コードはＥＵＣ以外にも容易に適用可能である。
【００５３】
文書をデータ部に登録する時には、単一文字成分及び隣接文字成分を抽出し、文字成分表を作成する。単一文字成分は各内部文字コードの２バイトコードとし、隣接文字成分は隣接する内部文字コードから変換したコードである。本実施例では内部文字コードのビット成分を適当に抽出したビット列を隣接文字成分とする。上記方法で得られた文字成分及び隣接文字成分に対して、図１０に示すように、それぞれ単一文字成分表及び図１１に示す隣接文字成分表を生成する。図１１では隣接する文字の下位１バイトを合わせて２バイトとしている。各文字成分表は、各単一文字成分または隣接文字成分が各文書に存在するか否かを０と１で示す。図１１の隣接文字成分表を例とすると、ａ０ａ０（１６進）のビット列は文書１、２、３、ｎには存在せず、文書４、５には存在することを意味する。文書登録時に上記方法により文書から文字成分を抽出し、各文字成分テーブルに加える。
【００５４】
仮に、隣接文字成分表として各文字成分の下位１バイトのみを利用した場合には、検索文字列とは異なる隣接文字でも下位バイトが一致する隣接文字を含む文書を検索する場合がある。ひらがな及びカタカナは頻繁に出現するので、検索の精度が低くなる。また漢字は文書中の出現頻度が低いので、本来検索精度が高い文字種であるにも関わらず、検索精度が低い他の文字種の影響を受けて検索精度が低くなってしまう。そこで、文字種ごとに異なる隣接文字成分表を作成し、検索時に検索文字列の文字種ごとに異なる隣接文字成分表を利用することによって、ひらがななどの頻繁に文書に出現する文字種の影響を受けず、検索精度を上げることができる。
以下、単一文字成分表、隣接文字成分表について説明する。
【００５５】
・単一文字成分表：文字がどの文書に出現するか否かを示す表
・隣接文字成分表
−同種隣接文字成分表：隣接する同種の文字のペアがどの文書に出現するか否かを示す表
＊記号
＊英数時
＊ひらがな
＊カタカナ
＊ギリシャ文字、グラフィック文字など
＊１バイト文字コード
＊第一水準漢字
＊第二水準漢字
−異種隣接文字成分表：隣接する異種の文字のペアがどの文書に出現するか否かを示す表
【００５６】
検索時には登録時と同様に検索文字列から単一文字成分と隣接文字成分を抽出し、それぞれ文字成分表から各成分を含む文書を検索する。
図１２は、従来の検索方法を説明するための図である。
図１２において、ビットの１は文字成分が出現することを示し、０は文字成分が出現しないことを意味する。従来の検索方法では検索文字列から文字種を判別して単一文字成分、隣接文字成分を登録時と同様に抽出し、各文字成分に対応する単一文字成分表及び隣接文字成分表から文字エントリのビットマップを抽出してＡＮＤ演算を行う。したがって、対象となるすべての文字エントリのデータを参照することになる。
【００５７】
本実施例では、図１３に示すように、特定のビットマップのビットを横方向に順時調べ、ビットが１の場合には、他のビットマップエントリの対応するビットを調べる。つまり、図１３で縦方向にビットを調べ、すべてのビットが１の場合は、ビットに対応する文書が検索結果の文書となる。ビットが０の時には、図１３の一番上の文字エントリに戻り、順時同様に繰り返す。こうすることによって、矢印で示されるビットのみを参照することになり、従来の検索方法に比較して参照するデータ量が格段に減少する。
【００５８】
さらに、図１４に示すように、各文字エントリ中に出現するビット１の出現数を予めカウントしておき、前述のビットを調べる処理の時に、図１４に示すように、ビット出現数が小さい順に並び代え、同様の処理を行うことによって、さらに参照するデータ量を減らすことが可能となる。
【００５９】
従来の検索方法では、各文字エントリのビットマップデータである可変長ビットマップデータは、複数の固定長ブロックに分割され、二次記憶に格納されている。したがって、前述の検索処理時に再度複数の固定長ブロックを可変長のビットマップに結合復元する。また、各文字エントリの一部のデータしかアクセスしない場合でも、文字エントリの全固定長データブロックを読み込み結合し、可変長ビットマップデータに復元する処理が必要となる。
【００６０】
本実施例では、前述の文字エントリは二次記憶上で、図１５に示すように、インデックスとブロックテーブルとブロックとから構成される。インデックスは各内部文字コードに対してブロックテーブルポインタとビット出現数（エントリ内に出現するビット１の数）のペアからなる。ブロックテーブルは先頭に次のブロックテーブルへのポインタを有し、ブロックポインタとブロック最終登録文書ＩＤ（ブロック内の最後に登録されている文書のＩＤ）からなる。したがって、内部文字コード「あ」に対応する全ブロックは、図１５に示すように、ブロックテーブルから示されるブロックとなる。
【００６１】
文書ＩＤが４０００の文書内に内部文字コードが「あ」の文字が出現する否かを調べる場合を例に、以下に説明する。
・インデックスの「あ」に対応するブロックテーブルポインタからブロックテーブルを得る。
・ブロック最終登録文書ＩＤから文書ＩＤ４０００を含むブロック（ブロックポインタ５１２０）を得る。
・ブロック（５１２０）のデータが圧縮されている場合には伸長し、文書ＩＤ４０００に該当するビットを得る。
このように、文字エントリの一部しか参照しない場合には、全ブロックをアクセスすることなしにブロックテーブルから直接該当するブロックを得られ、高速に検索することができる。
【００６２】
検索の時間で最も多く占めるのがディスクからデータのＲＥＡＤ時間である。ＲＥＡＤするページ（物理的なディスク読み書きの単位）が多ければ多いほど検索処理は遅くなる。文書登録を行なうと、図１６（ａ）のように、文字エントリのブロックは複数のページに分散する。したがって、検索処理では分散しているブロックを含むページをすべてＲＥＡＤすることにより処理が遅くなる。
本実施例では、図１６（ｂ）のように、分散したブロックをページ単位にまとめ上げることで検索処理時にＲＥＡＤするページを減らし、処理を速くすることができる。図１６に示す例では、まとめ上げ前には６ページ以上をＲＥＡＤしなければならなかったが、まとめ上げ後には３ページとなり、ＲＥＡＤの時間が半分以下になる。このようにブロックをページ単位にまとめ上げる処理をまとめ上げ処理と呼ぶ。
【００６３】
まとめ上げ処理では、図１６（ｂ）のように、ブロックをページにまとめ上げるが、ページにまとめ上げられなかった、ブロックについてはまとめ上げられなかったブロックを格納するためのページ（残ブロックページと呼ぶ）に集められる。したがって、図１７に示すように、残ブロックページには、様々な文字エントリの残ブロックが格納される。また、まとめ上げられたページはファイル中で混在することになる。
【００６４】
まとめ上げの処理手順を以下に示す。なお、説明中のバッファはメモリ上の領域を意味する。
▲１▼前処理
（ａ）文字成分表をオープンする。
（ｂ）まとめ上げ用文字成分表を作成しオープンする。
（ｃ）残ブロックページをアロケートする。
【００６５】
▲２▼文字エントリ単位のまとめ上げ処理
（ａ）ページへのまとめ上げ処理
ｉ．１ランレングスを読みページバッファに詰める。
ｉｉ．ページバッファにデータが満たされたらページバッファを書き出し、ページバッファをクリアする。
ｉｉｉ．ランレングスをすべて読み終るまで前記ｉ．に戻る。
（ｂ）ページにまとめ上げられなかったブロック（残ブロック）の書き出し処理ｉ．まとめ上げられなかったランレングスから再度１ランレングスを読み、残ブロックバッファに詰める。
ｉｉ．残ブロックバッファにデータが満たされたら残ブロックページに書き出す。
ｉｉｉ．残ブロックページの領域をすべて使い果たしたら新たに残ブロックページをアロケートする。
ｉｖ．ランレングスをすべて読み終るまで前記ｉ．に戻る。
【００６６】
▲３▼後処理
（ａ）書き出されていない残ブロックページを書き出す。
（ｂ）文字成分表及びまとめ上げ文字成分表をクローズする。
こうすることによって、文字成分表を１回スキャンするだけまとめ上げ処理が可能となり、処理が高速であるだけでなく、処理時に必要な二次記憶の領域を最小限に抑えられる。
【００６７】
次に、請求項１３に記載の発明について説明する。
本実施例の検索処理では、検索文字列から抽出されるエントリ数が少なければ、文字成分表へのアクセスが少なくなり、検索が高速になる。文字成分表エントリ指定において、単一文字エントリと隣接文字エントリを定義した場合、検索文字列がｎ文字の時、ｎ個の単一文字エントリとｎ−１個の隣接文字エントリが抽出されるので、トータルでは２ｎ−１個のエントリが抽出され、検索が遅い。
【００６８】
例えば、検索文字列が「パターンマッチ」である時、次のエントリが抽出される。
・単一文字エントリ：以下の文字に関数ｆ（ｘ）を作用させる。
パ，タ，ー，ン，マ，ッ，チ
・隣接文字エントリ：以下の２文字に関数ｇ（ｘ，ｙ）を作用させる。
パタ，ター，ーン，ンマ，マッ，ッチ
【００６９】
しかし、ｆ（ｘ）＝ｘ，ｇ（ｘ，ｙ）＝ｘ＋αｙ（ここで、αは文字コードの取り得る最大値）のような場合を考える。この時、検索文字列からｇ（Ｘ，Ｙ）が抽出される時には、必ずｆ（Ｘ），ｆ（Ｙ）も抽出される（例えば、ｇ（パ，タ）が抽出される時は、必ずｆ（パ），ｆ（タ）も抽出される）。したがって、検索文字列を含む文書を特定する上で、単一文字エントリは意味をなさない。そこで、検索文字列からは単一文字エントリを抽出せず、隣接文字エントリのみを抽出する。その結果、ｎ文字の検索文字列からｎ−１個の隣接文字エントリのみが抽出されるので、検索が高速化できる。
【００７０】
例えば、検索文字列が「パターンマッチ」である時、次のエントリが抽出される。
・単一文字エントリ：抽出しない。
・隣接文字エントリ：以下の２文字に関数ｇ（ｘ，ｙ）を作用させる。
パタ，ター，ーン，ンマ，マッ，ッチ
なお、この方式が有効なのは、ｆ（ｘ）＝ｘ，ｇ（ｘ，ｙ）＝ｘ＋αｙに限らない。
【００７１】
次に、請求項１４に記載の発明について説明する。
本実施例も、請求項１３に記載の発明と同様の効果を狙ったものであり、文字成分表エントリ定義がｆ（ｘ）＝ｘ，ｇ（ｘ,ｙ）＝ｘ＋α（ｙ mod β)(ここで、αは文字コードの取り得る最大値、βは適当な定数）のような場合を扱う。この時、検索文字列からｇ（Ｘ,Ｙ）が抽出される時には、必ずｆ（Ｘ）は抽出される（例えば、ｇ（パ,タ）が抽出される時は、必ずｆ（パ）も抽出される）。したがって、検索文字列を含む文書を特定する上で、末尾の１文字を除いては単一文字エントリは意味をなさない。そこで、検索文字列からは末尾の１文字から算出される単一文字エントリと、隣接文字エントリを抽出する。その結果、ｎ文字の検索文字列から１個の単一文字エントリとｎ−１個の隣接文字エントリのトータルｎ個のエントリが抽出されるので、検索が高速化できる。
【００７２】
例えば、検索文字列が「パターンマッチ」である時、次のエントリが抽出される。
・単一文字エントリ：以下の文字に関数ｆ（ｘ）を作用させる。
チ
・隣接文字エントリ：以下の２文字に関数ｇ（ｘ，ｙ）を作用させる。
パタ，ター，ーン，ンマ，マッ，ッチ
なお、この方式が有効なのは、ｆ（ｘ）＝ｘ，ｇ（ｘ，ｙ）＝ｘ＋α（ｙ ｍｏｄ β）に限らない。
【００７３】
次に、請求項１５に記載の発明について説明する。
本実施例も請求項１４に記載の発明と同様の効果を狙ったものであり、文字成分表エントリ定義がｆ（ｘ）＝ｘ，ｇ（ｘ,ｙ）＝ｙ＋α（ｘ mod β）のような場合を扱う。この時、検索文字列からｇ（Ｘ,Ｙ）が抽出される時には、必ずｆ（Ｙ）は抽出される（例えば、ｇ（パ,タ）が抽出される時は、必ずｆ（タ）も抽出される）。したがって、検索文字列を含む文書を特定する上で、先頭の１文字を除いては単一文字エントリは意味をなさない。そこで、検索文字列からは先頭の１文字から算出される単一文字エントリと、隣接文字エントリを抽出する。その結果、ｎ文字の検索文字列から１個の単一文字エントリとｎ−１個の隣接文字エントリのトータルｎ個のエントリが抽出されるので、検索が高速化できる。
【００７４】
例えば、検索文字列が「パターンマッチ」である時、次のエントリが抽出される。
・単一文字エントリ：以下の文字に関数ｆ（ｘ）を作用させる。
パ
・隣接文字エントリ：以下の２文字に関数ｇ（ｘ，ｙ）を作用させる。
パタ，ター，ーン，ンマ，マッ，ッチ
なお、この方式が有効なのは、ｆ（ｘ）＝ｘ，ｇ（ｘ，ｙ）＝ｙ＋α（ｘ ｍｏｄ β）に限らない。
【００７５】
次に、請求項１６に記載の発明について説明する。
前述した請求項４に記載の発明では、文字成分表のエントリに３文字以上の長い文字列（から算出される値）をエントリに用いることで、文字成分表へのアクセス回数を減らし、検索を大幅に高速化できることを示した。図５に長い文字列をエントリとして持つ文字成分表を示す。「システム」「パターン」などが文字列エントリである。
【００７６】
文字成分表エントリ指定において、単一文字エントリと隣接文字エントリを定義し、さらに、文字列エントリを導入した場合の検索処理を考える。請求項４に記載の発明では、検索文字列中に含まれる文字列エントリに対応する文字列から抽出される単一／隣接文字エントリは、検索処理に用いないとしていた。
【００７７】
例えば、検索文字列が「パターンマッチ」で「パターン」が文字列エントリとして定義されている時、次のエントリが抽出される。
・単一文字エントリ：以下の文字に関数ｆ（ｘ）を作用させる。
マ，ッ，チ
・隣接文字エントリ：以下の２文字に関数ｇ（ｘ，ｙ）を作用させる。
ンマ，マッ，ッチ
・文字列エントリ：
パターン
【００７８】
もちろん、請求項４記載の発明に本発明の請求項１３〜１５に記載の発明を組み合わせることも可能である。
一方、本発明では、隣接文字エントリについては該当する文字列エントリに前後の文字を加えた文字列から抽出されるエントリを抽出しないことで、検索文字列から抽出エントリ数を削減し、検索を高速化する（単一文字エントリについては、これまで通り、該当する文字列エントリから抽出されるエントリを抽出しないこととする）。
【００７９】
例えば、「パターンマッチ」から抽出されるエントリは、以下のようになり、エントリ数を一つ減らすことができる。
・単一文字エントリ：以下の文字に関数ｆ（ｘ）を作用させる。
マ，ッ，チ
・隣接文字エントリ：以下の２文字に関数ｇ（ｘ，ｙ）を作用させる。
マッ，ッチ
・文字列エントリ：
パターン
【００８０】
次に、請求項１７に記載の発明について説明する。
前述した請求項６に記載の発明では、検索条件として複数の文字列を論理演算子（ＡＮＤ，ＯＲ）で組み合わせたもの（単一の文字列もこの検索条件に含める）を受け付けるとしていた。ここで、“ＡＮＤ”は前後の文字列をともに含む文書を検索すること、“ＯＲ”は前後の文字列を少なくとも一つ含む文書を検索することを意味する。さらに、必要に応じて、演算子の作用順序を明示するために、“(”,“)”を用いることができるものとする。論理演算子を検索条件に用いることができるようにすることで、複雑な検索要求を表現することが可能となった。
【００８１】
しかし、ＡＮＤ，ＯＲだけでは「「文書検索」を含むが「画像検索」を含んでいないこと」のような否定を含む検索要求を表現することはできない。そこで、本実施例では、検索条件として複数の文字列を論理演算子（ＡＮＤ，ＯＲ，ＮＯＴ）で組み合わせたものを受け付ける。ここで、“ＮＯＴ”は前の文字列を含むが、後の文字列は含まない文書を検索することを意味する。
【００８２】
次に、請求項１８に記載の発明について説明する。
ＡＮＤ，ＯＲの処理では、演算子の前後の検索文字列に対するビット列を計算し（検索手順のステップ１）、それらのビットＡＮＤあるいはビットＯＲを取れば良かった。しかし、ＮＯＴでは、同様の処理（前後の検索文字列に対するビット列を計算し、後側のビット列のビット反転して前側のビット列とビットＡＮＤを取る）では、検索洩れの可能性がある。これは、文字成分表を用いて得られる各検索文字列に対するビット列は、正確にその文字列を含む文書番号の表現ではなく、実際には、その文字列を含んでいない誤検索も含んでいるためである。その結果、ビット反転したビット列には、その文字列を含んでいない文書（番号）の一部は含まれないことになり、検索洩れが発生する。
【００８３】
そこで、本実施例では、ＮＯＴについては前側の検索文字列に対するビット列をＮＯＴの処理結果のビット列とする。その結果、ＮＯＴの処理結果には、後側の検索文字列を含む文書が含まれ、誤検索が発生する（誤検索は検索処理のステップ２で排除できるので、実用上は問題ない）。しかし、後側の検索文字列を含まない文書が含まれないことはなくなり、検索洩れを完全に防ぐことができる（検索洩れは検索処理のステップ２で救うことができないので、実用上の問題となる）。また、この方式では、後側の検索文字列を処理する必要がないので、文字成分表検索の高速化にも効果がある。
【００８４】
次に、請求項１９に記載の発明について説明する。
文書から文字成分を抽出し、文字成分表を生成するまでの過程は、図９〜図１１に従って記述された請求項１２の発明の実施例と同様に行われる。
これにより得られる文字成分表の構成は、図１８に示されるようにインデックスとビットマップデータから成る。インデックス部は、文字成分とビットマップデータへのポインタの対応表である。ビットマップデータは文字成分表の文書中に文字成分が出現するか否かを示す０，１のデータである。大量の文書を登録する場合に、ビットマップデータは巨大になることから、メモリ上には置かず二次記憶に置く。
【００８５】
二次記憶への登録の手法を特徴とするこの発明の実施例によると、一文書を登録するごとに文字成分表が生成され、その都度、直接二次記憶上の文字成分表に書き込むのではなく、一旦メモリ上に登録し、その後一括してメモリ上のデータを二次記憶の文字成分表に書き出す。図１８に一括登録時のデータ構成を示す。この例では、簡便のために二次記憶上のデータ構成とメモリ上の構成を同じにしている。一括文書登録時にはメモリ上のテーブルに一時的に登録したデータ（図中の網かけ）を処理の最後に二次記憶のビットマップテーブルにコピーし、登録処理を完了する。
【００８６】
次に、請求項２０に記載の発明について説明する。当該文書管理装置のシステム内には、文書データを持たず、その代わりに文書の情報の一つとしてオリジナル文書のファイルシステム上での位置を示すディレクトリパス名を二次記憶上で管理し、参照にはディレクトリパス名を基に外部のファイルシステム上のオリジナル文書を直接参照するようになされている。
したがって、当該装置のシステム内部にオリジナルの文書データを持つ必要がなく、内部の二次記憶を無駄に利用しないだけではなく、該システムを介する煩わしさがなく、ユーザや他のアプリケーションによる登録文書の参照が可能となる。
【００８７】
次に、請求項２１に記載の発明について説明する。
文書の登録時にファイルシステム上の登録文書のオリジナルデータのディレクトリを指定し、そのディレクトリ内或いはその下位ディレクトリの文書をすべて登録しておき、当該文書管理装置において、該ディレクトリパス名を管理し、文書内容を参照する場合には、登録したディレクトリパス名を基に直接外部のファイルシステム上のオリジナルデータを参照するようになされている。
したがって、オリジナル文書をユーザが普段利用するファイルシステム上に置く場合には、一つのディレクトリ階層に存在する文書をそのまま当該文書管理装置で管理するシステムとすることが可能となる。また、ディレクトリを指定することによって、そのディレクトリ中に含まれる文書および下位のディレクトリ中に含まれる全文書を自動的に登録することができるようにすることで、ディレクトリ上の全文書を一つ一つユーザが指定する必要があったところの従来のユーザの負担を軽減することになる。
【００８８】
次に、請求項２２に記載の発明について説明する。
上述したと同様に、ディレクトリパス名を基に直接外部のファイルシステム上のオリジナルデータを参照するようにした文書管理装置において、事前に当該装置に登録したい文書を置くディレクトリをユーザが指定しておくと、当該装置は、そのディレクトリを常に監視し、文書の登録，更新，削除が行われた場合には、同じ操作を自動的に文字成分表に反映させ、登録，更新，削除を行う。このようにすることで、ユーザの文書操作の負担を軽減することができる。
ディレクトリを監視する方法としては、一定時間ごとに指定されたディレクトリの変化を調べる方法やＯＳなどの基本システムのファイル操作のシステムコールの処理を変更し、ファイル操作があった場合に文書管理システムに通知する方法などを採用し得る。
【００８９】
【発明の効果】
以上の説明から明らかなように、本発明によると、以下のような効果がある。
（１）請求項１,２に対応する効果：登録文書を保存するとともに、該登録文書に含まれる各文字あるいは連続する２文字から算出される値を文字成分表に登録し記録する文書登録手段と、前記文字成分表を用いて検索条件に該当する文書を高速に探し出す文書検索手段とを有し、前記文字成分表エントリ指定により文字成分表の構成を変更可能とし、前記登録文書を複数のフォルダに分割して管理可能で、かつフォルダごとに文字成分表エントリ指定できるようにし、文字成分表の構成を目的に合わせて変更できるようにしたため、効率的な文書管理システムを構築できる。
（２）請求項３,４,５に対応する効果：前記文書検索手段で単一の文字列から抽出される文字成分に同一のものが２個以上ある場合、前記文字成分表の文字成分に対するアクセスを一回しか行わないようにし、また、文字成分の算出において、連続する３文字以上の文字列から算出される値をも用いるようにし、さらに、文書登録時の文字成分の算出において、連続する３文字以上の文字列から算出される値を用いる場合には、該文字列から１文字あるいは連続する２文字から算出される値を文字成分表に登録しないようにしたので、検索文字列が長い場合でも、高速に文書検索できる。
（３）請求項６,７,８に対応する効果：前記文書検索手段において、単一の文字列あるいは複数の文字列をＡＮＤあるいはＯＲ論理演算子で組み合わせた検索条件を処理可能とし、また、前記文書検索手段でＡＮＤ論理演算子で結合される２つの文字列から抽出される文字成分に同一のものが２個以上ある場合、文字成分表の文字成分に対するアクセスを一回しか行わないようにし、さらに、前記文書検索手段でＯＲ論理演算子で結合される２つの文字列から抽出される文字成分に同一のものが２個以上ある場合、文字成分表の文字成分に対するアクセスを一回しか行わないようにした。検索条件を複数の文字列を論理演算子（ＡＮＤ，ＯＲ）で組み合わせで表現できるので、複雑な検索要求を表現することが可能となる。また、論理演算子に合わせた最適化を行うので、高速に文書検索できる。
（４）請求項９,１０,１１に対応する効果：前記文字成分表を、該文字成分表を保存する大小２種類のブロックから構成されるデータファイルと、文字成分ごとのブロック位置を記録するインデックスファイルによって記憶し、複数の小さいブロックを大きいブロックにまとめるブロック融合手段を有し、また、前記ブロック融合手段において、データファイルの前方に大きいブロックをまとめ、後方に小さいブロックをまとめるようにし、さらに、前記ブロック融合手段において、データファイルの小さいブロックが存在する領域のみをブロック融合の対象とするようにし、文字成分表のビットマップデータを格納するブロックの大きさに大小２種類用意したため、登録／検索速度をともに高速化できる。
（５）請求項１２に対応する効果：前記ブロック融合手段において、検索時に高速に文字成分表エントリを二次記憶から読み出すために、複数の固定長ブロックに分割された各文字成分表エントリを大きな固定長ブロックにまとめあげる時に大きな固定長ブロックをアロケートの単位とし、まとめ上げられた大きな固定長ブロック及びまとめあげられなかった残りの小さな固定長ブロックを詰め込んだ大きな固定長ブロックを順時書き出すことによって、文字成分表のデータを一回のスキャンで処理し、高速にかつ処理時に必要な二次記憶領域を最小限に抑えるようにし、文字エントリの小さなブロックを大きなブロックにまとめ上げることにより、検索速度が向上する。
（６）請求項１３〜１６に対応する効果：前記文字成分表の構成を文書の各文字および連続する２文字から算出される値を記録するものとした場合、前記文字検索手段が検索文字列から連続する２文字から算出される値のみを抽出し、また、前記文書検索手段が検索文字列から連続する２文字から算出される値と、該検索文字列の末尾の１文字から算出される値を抽出し、また、検索文字列から連続する２文字から算出される値と、該検索文字列の先頭の１文字から算出される値を抽出し、さらに、前記文字成分表の構成を連続する３文字以上の文字列から算出される値をも用いる場合、前記文書検索手段が検索文字列から前記文字エントリが抽出される時には、該文字列エントリに対応する文字列に含まれる１文字あるいは前記文字列にその前後の文字を含めた文字列に含まれる２文字から算出される値を抽出しないようにしたので、検索処理において検索文字列から抽出するエントリ数を削減し、検索処理を高速化できる。
（７）請求項１７，１８に対応する効果：前記文書検索手段が単一の文字列あるいは複数の文字列を「論理積」,「論理和」あるいは「論理差」論理演算子で組み合わせた検索条件を処理可能とし、また、前記文書検索手段で「論理差」で結合される２つの文字列の処理において、後側の文字列を処理しないことにしたので、検索条件を複数の文字列を論理演算子（ＡＮＤ，ＯＲ，ＮＯＴ）で組み合わせで表現できるので、複雑な検索要求を表現することが可能となる。また、論理演算子に合わせた最適化を行うので、高速に文書検索できる。
（８）請求項１９に対応する効果：従来の方法では、文字成分表データが二次記憶上にある場合には、一文書を登録するごとに二次記憶にアクセスすることになり、速度が遅くなってしまうが、本発明によると、一括登録する文書については、一旦メモリ上に文字成分表を一時的に生成登録し、その後、処理の最後にメモリ上の文字成分表データを二次記憶上の文書成分表データにアペンドする。こうすることによって、二次記憶へのアクセスが減り、高速に複数文書の一括登録が可能となる。
（９）請求項２０に対応する効果：外部にあるオリジナル文書のファイルシステム上でのディレクトリパス名を当該文書管理装置で管理し、参照には、ディレクトリパス名を基に外部の該ファイルを直接参照することになるので、当該装置のシステムが内部にオリジナルデータを持つ必要がなく、二次記憶を無駄に利用しないだけでなく、システムを介することなくユーザや他のアプリケーションによる登録文書の参照が可能となる。
（１０）請求項２１に対応する効果：上述と同様に、ディレクトリパス名を管理する場合に、ディレクトリ内およびその下位ディレクトリの文書をすべて登録するようになっているので、オリジナル文書をユーザが普段利用するファイルシステム上に置く場合には、一つのディレクトリ階層に存在する文書をそのまま文書管理装置で管理するシステムとすることが可能となる。また、ディレクトリを指定することによって、そのディレクトリ中に含まれる文書または下位のディレクトリ中に含まれる全文書を自動的に登録することができるようにすることで、ディレクトリ上の全文書を一つ一つユーザが指定する必要があった従来のユーザの負担を軽減することができる。
（１１）請求項２２に対応する効果：登録したい文書を置くディレクトリをユーザがあらかじめ指定しておくと、当該文書管理装置は、そのディレクトリ上での文書の登録，更新，削除を常に監視し、文書の登録，更新，削除が行われた場合には、同じ操作を自動的に文字成分表に反映させ、登録，更新，削除を行う。このようにすることで、ユーザの文書操作の負担を軽減することができる。
【図面の簡単な説明】
【図１】本発明による文書管理装置の一実施例を説明するための構成図である。
【図２】本発明における文字成分表の一例を示す図である。
【図３】本発明における文字成分表の他の例を示す図である。
【図４】本発明による文書管理装置の他の実施例を説明するための構成図である。
【図５】本発明における長い文字列をエントリとして持つ文字成分表の例を示す図である。
【図６】本発明における文字成分表のためのファイル構成の一例を示す図である。
【図７】本発明における文字成分表ファイルのブロック融合処理の概要（その１）を示す図である。
【図８】本発明における文字成分表ファイルのブロック融合処理の概要（その２）を示す図である。
【図９】本発明による文書管理装置の更に他の実施例を説明するための構成図である。
【図１０】本発明における単一文字成分表を示す図である。
【図１１】本発明における隣接文字成分表を示す図である。
【図１２】従来の検索方式を説明するための図である。
【図１３】本発明における検索方式（その１）を説明するための図である。
【図１４】本発明における検索方式（その２）を説明するための図である。
【図１５】本発明におけるデータ構成を示す図である。
【図１６】本発明におけるまとめ上げ処理（その１）を説明するための図である。
【図１７】本発明におけるまとめ上げ処理（その２）を説明するための図である。
【図１８】本発明における一括登録処理の例を説明するための図である。
【符号の説明】
１…登録文書、２…文書登録手段、３…検索条件、４…文書検索手段、５…該当文書、６…文字成分表エントリ指定、７…文字成分表、８…文書本文データ、９…文書データベース、９−１〜９−ｎ…文書データベース、１１…入力部、１２…処理部、１３…文字列入力処理部、１４…文書検索処理部、１５…文書出力処理部、１６…文書登録処理部、１７…データ部、１８…文字成分表、１９…出力部、２０…文書データ。

Claims (22)

1. 登録文書を保存するとともに、該登録文書に含まれる各文字あるいは連続する２文字から算出される値を文字成分表に登録し記録する文書登録手段と、前記文字成分表を用いて検索条件に該当する文書を高速に探し出す文書検索手段とを有し、前記文書登録手段は、前記文字成分表の構成を指定した文字成分表エントリ指定を参照して前記登録文書から文字成分を抽出し、該文字成分から文字成分表エントリを計算して前記文字成分表を作成するようにし、前記文書検索手段は、前記文字成分表エントリ指定を参照して検索文字列から文字成分を抽出して、該抽出した文字成分から文字成分表エントリを計算して検索するようにしたことを特徴とする文書管理装置。
2. 前記文書登録手段は、前記登録文書を複数に分類してそれぞれ別々のフォルダに分割して管理可能で、かつ、該フォルダに登録された登録文書に対する文字成分表の構成を指定する文字成分表エントリ指定を持たせるようにしたことを特徴とする請求項１記載の文書管理装置。
3. 前記文書検索手段で単一の文字列から抽出される文字成分に同一のものが２個以上ある場合、前記文字成分表の文字成分に対するアクセスを一回しか行わないことを特徴とする請求項１記載の文書管理装置。
4. 文字成分の算出値として、連続する３文字以上の文字列から算出される値をも用いることを特徴とする請求項１記載の文書管理装置。
5. 文書登録時の文字成分の算出において、連続する３文字以上の文字列から算出される値を用いる場合には、該文字列から１文字あるいは連続する２文字から算出される値を文字成分表に登録しないことを特徴とする請求項４記載の文書管理装置。
6. 前記文書検索手段において、単一の文字列あるいは複数の文字列をＡＮＤ論理演算子あるいはＯＲ論理演算子で組み合わせた検索条件を処理可能とすることを特徴とする請求項１記載の文書管理装置。
7. 前記文書検索手段でＡＮＤ論理演算子で結合される２つの文字列から抽出される文字成分に同一のものが２個以上ある場合、文字成分表の文字成分に対するアクセスを一回しか行わないことを特徴とする請求項６記載の文書管理装置。
8. 前記文書検索手段でＯＲ論理演算子で結合される２つの文字列から抽出される文字成分に同一のものが２個以上ある場合、文字成分表の文字成分に対するアクセスを一回しか行わないことを特徴とする請求項６記載の文書管理装置。
9. 前記文字成分表を、該文字成分表を保存する大小２種類のブロックから構成されるデータファイルと、文字成分ごとのブロック位置を記録するインデックスファイルによって記憶し、複数の小さいブロックを大きいブロックにまとめるブロック融合手段を有することを特徴とする請求項１記載の文書管理装置。
10. 前記ブロック融合手段において、データファイルの前方に大きいブロックをまとめ、後方に小さいブロックをまとめることを特徴とする請求項９記載の文書管理装置。
11. 前記ブロック融合手段において、データファイルの小さいブロックが存在する領域のみをブロック融合の対象とすることを特徴とする請求項１０記載の文書管理装置。
12. 前記ブロック融合手段において、検索時に高速に文字成分表エントリを二次記憶から読み出すために、複数の固定長ブロックに分割された各文字成分表エントリを大きな固定長ブロックにまとめあげる時に大きな固定長ブロックをアロケートの単位とし、まとめ上げられた大きな固定長ブロック及びまとめあげられなかった残りの小さな固定長ブロックを詰め込んだ大きな固定長ブロックを順時書き出すことによって、文字成分表のデータを一回のスキャンで処理し、高速にかつ処理時に必要な二次記憶領域を最小限に抑えることを特徴とする請求項９記載の文書管理装置。
13. 前記文字成分表の構成を、文書の各文字および連続する２文字から算出される値を記録するものとした場合、前記文書検索手段が検索文字列から、連続する２文字から算出される値のみを抽出することを特徴とする請求項１記載の文書管理装置。
14. 前記文書検索手段が、検索文字列からの連続する２文字から算出される値と、該検索文字列の末尾の１文字から算出される値を抽出することを特徴とする請求項１３記載の文書管理装置。
15. 前記文書検索手段が、検索文字列からの連続する２文字から算出される値と、該検索文字列の先頭の１文字から算出される値を抽出することを特徴とする請求項１３記載の文書管理装置。
16. 前記文字成分表の構成を連続する３文字以上の文字列から算出される値をも用いる場合、前記文書検索手段が、検索文字列から前記文字エントリが抽出される時には、該文字列エントリに対応する文字列に含まれる１文字あるいは前記文字列にその前後の文字を含めた文字列に含まれる２文字から算出される値を抽出しないことを特徴とする請求項１５記載の文書管理装置。
17. 前記文書検索手段が、単一の文字列あるいは複数の文字列を「論理積」,「論理和」あるいは「論理差」論理演算子で組み合わせた検索条件を処理可能なことを特徴とする請求項１３記載の文書管理装置。
18. 前記文書検索手段で「論理差」で結合される２つの文字列の処理において、後側の文字列を処理しないことを特徴とする請求項１７記載の文書管理装置。
19. 前記文書登録手段が、多数の文書を一括して登録する場合に、一文書を登録するごとに生成された文字成分表データを直接二次記憶上の文字成分表に書き込むのではなく一旦メモリ上に登録し、その後、一括してメモリ上の文字成分表データを二次記憶の文字成分表に書き出すことによって、高速に文書の一括登録を行うことを特徴とする請求項１記載の文書管理装置。
20. 前記文書登録手段により登録されたファイルシステム上の登録文書のディレクトリパス名を二次記憶上で管理し、文書内容を参照する場合には、登録したディレクトリパス名を基に直接ファイルシステム上のオリジナルデータを参照することによって、文書管理システムが内部にオリジナルデータを持つ必要がないだけでなく、ユーザや他のアプリケーションによる登録文書の参照を容易にすることを特徴とする請求項１記載の文書管理装置。
21. 前記文書登録手段により登録されたファイルシステム上の登録文書のオリジナルデータのディレクトリパス名を管理し、文書内容を参照する場合には、登録したディレクトリパス名を基に直接ファイルシステム上のオリジナルデータを参照するようにし、文書の登録時にディレクトリを指定し、そのディレクトリ内およびその下位ディレクトリの文書をすべて登録することにより、複数の文書の登録時の文書指定を容易にすることを特徴とする請求項１記載の文書管理装置。
22. 前記文書登録手段により登録されたファイルシステム上の登録文書のオリジナルデータのディレクトリパス名を管理し、文書内容を参照する時には、登録したディレクトリパス名を基に直接ファイルシステム上のオリジナルデータを参照するようにし、あらかじめ登録対象とするディレクトリを指定しておき、そのディレクトリ上での文書の登録，更新，削除を常に監視し、文書の登録，更新，削除があった場合には、自動的に当該の文書について文字成分表に登録，更新，削除を行うことによって、ユーザの文書管理の手間を削減することを特徴とする請求項１記載の文書管理装置。

Images