JPH0969113A - 文書管理方式 - Google Patents

Abstract

(57)【要約】 【課題】 長い文書を登録する場合における誤検索を減
らす。 【解決手段】 文書登録時に文書より各文字コード成分
及び２文字以上の隣接文字からビット列成分を算出し、
各文書がそれぞれの成分を含むか否かを示す単一文字成
分表及び一つ以上の隣接文字成分表を生成し、該文字成
分表の各文字成分のエントリを複数のブロックに分割し
て二次記憶に一括登録する。一括登録の開始時に、ユー
ザが指定したサイズのメモリ領域を確保し、確保したメ
モリ上にすべての各文字エントリに対して１つのブロッ
クをそれぞれ割り当てる。登録時に、ブロック内に書き
込む余地が無くなった場合には、そのブロックを二次記
憶に書き出して空にした後登録するようにして、登録途
中でメモリが不足して登録が中断することがないように
した。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、文書管理方式に関
し、より詳細には、文字成分表を利用して、全文書に対
して文字列を検索する文字検索方式に関するものであ
る。

【０００２】

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

【０００３】また、前述した特開平５−３２４７２２号
公報や、特開平７−１６０７２４号公報に記載のもの
は、文字成分が文書中に存在するか否かを示す単一文字
成分表、及び隣接する文字から抽出したある文字成分が
文書中に存在するか否かを示す隣接文字成分表を利用し
て文書を検索するものであるが、これら従来方法では、
複数の文書を一括して登録する機能がなく、多量の文書
を登録するのに処理時間がかかった。また、本出願人が
先に提案した特願平７−１２１３７０号においては、長
い文書を登録した場合には、誤検索が多くなるので、文
書の誤検索を減らすために、文書を分割して登録するよ
うにしたが、その場合に、機械的に一定サイズで分割す
ると文字列が途中で分割されて検索できない場合があっ
た。

【０００４】

【発明が解決しようとする課題】上述のように、従来の
方法では、多数の文書を一括して登録する処理が遅く、
また、長い文書を登録した場合には、誤検索が多くなる
ため、文書の誤検索を減らすために文書を分割して登録
していたが、機械的に一定サイズで分割すると文字列が
途中で分割されて検索できない場合があった。本発明
は、上述のごとき従来技術の問題点を改善することを目
的としてなされたものである。

【０００５】

【課題を解決するための手段】請求項１の発明は、大量
の文書データを保持し、入力装置から入力された検索文
字列を含む文書を検索し、出力装置により検索した文書
を出力する文書管理方式であって、文書登録時に文書よ
り各文字コード成分及び２文字以上の隣接文字からビッ
ト列成分を算出し、各文書がそれぞれの成分を含むか否
かを示す単一文字成分表及び一つ以上の隣接文字成分表
を生成し、該文字成分表の各文字成分のエントリを複数
のブロックに分割して二次記憶に一括登録する文書管理
方式において、一括登録の開始時に、ユーザが指定した
サイズのメモリ領域を確保し、確保したメモリ上にすべ
ての各文字エントリに対して１つのブロックをそれぞれ
割り当て、登録処理時、ブロック内に書き込む余地が無
くなった場合には、そのブロックを二次記憶に書き出し
て空にした後登録することによって、登録途中でメモリ
が不足して登録を中断することがないようにすることを
特徴とし、多数の文書を一括登録する場合に、登録文書
のデータをメモリ上に置き、処理の最後に二次記憶に書
き出すことによって、高速に登録することを可能とした
ものである。

【０００６】請求項２の発明は、大量の文書データを保
持し、入力装置から入力された検索文字列を含む文書を
検索し、出力装置により検索した文書を出力する文書管
理方式であって、文書登録時に文書より各文字コード成
分及び２文字以上の隣接文字からビット列成分を算出
し、各文書がそれぞれの成分を含むか否かを示す単一文
字成分表及び一つ以上の隣接文字成分表を生成し、該文
字成分表の各文字成分のエントリを複数のブロックに分
割して二次記憶に一括登録する文書管理方式において、
一括登録の開始時に、ユーザが指定したサイズのメモリ
領域を確保し、全エントリ数分のブロックで、かつ、数
種類のサイズからなるブロックを確保し、文書の登録処
理時、ブロック内の空きがなくなり、メモリ上に書き出
したデータ量が多いブロックについては大きいサイズの
ブロックを利用することにより、二次記憶へ書き出す回
数を減らし、高速に大量文書を一括登録ができるように
することを特徴とし、多数の文書を一括登録する場合
に、登録文書のデータをメモリ上に置き、処理の最後に
二次記憶に書き出すことによって、高速に登録すること
を可能としたものである。

【０００７】請求項３の発明は、登録文書をある一定サ
イズに分割し、それぞれを別文書として登録し、検索時
には、ひとつの文書として検索することにより、長い文
書の適合率を高めるようにした文書管理方式において、
単純に一定サイズに分割すると、通常検索語となるよう
な文字列の途中で二つの文書に分割されてしまい、検索
時に検索できない問題が生ずるが、句読点などのように
検索語の中に通常現れない文字を予め分割区切り文字と
し、一定サイズで機械的に分割した位置が分割区切り文
字でない場合には分割区切り文字までテキストを辿り、
該分割区切り文字まできた時に分割することにより、検
索できなくなる文字列がないようにすることを特徴と
し、登録文書が長い場合に、従来技術では検索精度が低
下したが、上述のごとく文書を分割することで検索精度
の低下を抑え、かつ、分割する位置を検索の対象としな
い文字にすることで検索できない文字列をなくすことを
可能としたものである。

【０００８】

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

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

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

【００１１】図４は、一括登録処理の例を説明するため
の図で、図示のように、文字成分表のデータ構成は、イ
ンデックスとビットマップデータからなる。インデック
ス部は文字成分とビットマップデータへのポインタの対
応表である。ビットマップデータは文字成分表の文書中
に文字成分が出現するか否かを示す０，１のデータであ
る。大量の文書を登録する場合にビットマップデータは
巨大になることからメモリ上には置かず二次記憶に置
く。

【００１２】多数の文書を一括して登録するには、従来
の方法では、ビットマップデータが二次記憶上にある場
合には、一文書を登録するごとに二次記置にアクセスす
ることになり速度が遅い。そこで、一括登録する文書に
ついては、メモリ上に文字成分表を一時的に生成し、処
理の最後にメモリ上のビットマップデータを二次記憶上
のビットマップデータにアペンドすることによって、二
次記憶へのアクセスを減らし、高速に複数文書の一括登
録を可能とする。すなわち、請求項１の発明のように、
一括登録の開始時に、ユーザが指定したサイズのメモリ
領域を確保し、確保したメモリ上にすべての各文字エン
トリに対して１つのブロックをそれぞれ割り当て、登録
時にブロック内に書き込む余地が無くなった場合には、
そのブロックを二次記憶に書き出して空にした後に登録
することによって、登録途中でメモリが不足して登録を
中断することがないようにする。

【００１３】図５は、メモリ上のデータ構成を示す図
で、図中のインデックステーブルの各フィールドについ
て以下に説明する。 ・ブロックポインタ(Block Pointer)：ビットマップデ
ータへのポインタ ・最終テキストＩＤ(Last ID)：ビットマップデータの
最終のテキストＩＤ ビットマップブロックの各フィールドを以下に説明す
る。 ・長さ(Length)：ビットマップデータのサイズ（ビット
長） ・ビットマップデータ(Bitmap Data)：登録テキストの
ビットマップデータ メモリ上のデータ構成は、二次記憶上の文字成分表の構
成に似ているが、大きく違うところは、二次記憶上のビ
ットマップデータのブロックは文字成分エントリごとに
複数持ち、リスト構造をとって可変長の文字エントリを
実現する必要があるが、メモリ上の文字成分表では一つ
のブロックしか持たない。以下に一括登録処理の流れを
示す。

【００１４】１．初期化 インデックスをメモリ上のインデックスにロードする。
データブロックとして利用するデータブロック領域をア
ロケートする。データブロック領域のサイズはユーザが
指定し、文字成分表の全文字成分エントリ数で割った値
が一つのデータブロックのサイズとなる。したがって、
全文字エントリに対して一つずつデータブロックを確保
するので、一括登録処理中にデータブロックが足りなく
ならない。 ２．登録 (a)エントリＩＤに対応するデータブロックが存在しな
い場合には、データブロック領域からデータブロックを
アロケートする。 (b)データブロックにビットデータを加える。加えるス
ペースがない場合には、データブロックのデータを二次
記憶に書き出してデータブロックを空にしてから加え
る。 (c)全てのエントリを登録するまで(a)に戻る。 ３．後処理 データブロック及びインデックスを二次記憶に書き出
す。

【００１５】さらに、二次記憶へのアクセスを減らし、
一括登録処理を高速にするために、初期化時に同じブロ
ックサイズではなく、数種類のサイズのブロックを確保
する。図６は、データブロックの例を示し、図示のよう
に、登録文書中に何度も現れる文字成分、つまり二次記
憶へ書き出すデータ量が多い文字成分については、メモ
リ上の大きなブロック（Ｂ２area，Ｂ３area）を利用す
ることにより、二次記憶への書き出す回数を減らすこと
ができ、登録速度が早くなる。すなわち、請求項２の発
明のように、一括登録の開始時に、ユーザが指定したサ
イズのメモリ領域を確保し、全エントリ数分のブロック
で、かつ、数種類のサイズからなるブロックを確保し、
文書の登録処理時では、ブロック内の空きがなくなり、
メモリ上に書き出したデータ量が多いブロックについて
は大きいサイズのブロックを利用することにより、二次
記憶へ書き出す回数を減らし高速に大量文書を一括登録
するようにする。以下に詳細な処理の流れを示す。

【００１６】１．初期化 インデックスをメモリ上のインデックスにロードする。
データブロックとして利用するデータブロック領域をア
ロケートする。データブロック領域のサイズはユーザが
指定し、全文字成分の全エントリ数分のデータブロック
を生成する。ただし、データブロックのサイズは図６に
示したように複数のサイズをもつ。全文字エントリに対
して一つずつデータブロックを確保するので、一括登録
処理中にデータブロックが足りなくなることはない。 (a)エントリＩＤに対応するデータブロックが存在しな
い場合には、一番小さいデータブロック（Ｂ１）領域か
らデータブロックをアロケートする。ただし、Ｂ１領域
がすべて使用されている場合には、Ｂ１のデータブロッ
クの中でデータ量が最大であるブロックをＢ２の空きブ
ロックにコピーする。Ｂ２に空きデータブロックがない
場合には、同様の処理を繰り返し、さらに大きなブロッ
クにデータを移動する。あらかじめ全体のブロック数は
全エントリ数分確保しておくので、ブロックが確保でき
ないことはない。 (b)データブロックにビットデータを加える。加えるス
ペースがない場合には、データブロックのデータを、次
に大きいブロックをアロケートして登録する。次に、大
きなブロックの空きがない場合には、前述と同様の処理
を繰り返す。ただし、この場合、空きブロックが見つか
らない場合もあるが、その時は、ブロックのデータを二
次記憶に書き出してデータブロックを空にして、そのま
ま同じブロックを利用する。 (c)全てのエントりを登録するまで(a)に戻る。 ２．後処理 データブロック及びインデックスを二次記憶に書き出
す。

【００１７】上述のように、予め指定されたサイズより
大きいテキストは、その指定サイズ単位に分割して登録
する。こうすることによって、長いテキストの場合に誤
検索が増えるという問題点を回避することができる。し
かし、指定サイズ単位で分割すると、検索文字列の対象
となる文字列の途中で分割する場合が生じ、その文字列
では検索できなくなる。すなわち、単純に一定サイズに
分割すると通常検索語となるような文字列の途中で二つ
の文書に分割されてしまい、検索時に検索できない問題
が生ずる。しかし、請求項３の発明のように、句読点な
どのように、検索語の中に通常現れない文字を予め分割
区切り文字とし、一定サイズで機械的に分割した位置が
分割区切り文字でない場合には、分割区切り文字までテ
キストを辿り、分割区切り文字に達した時に、該分割区
切り文字で分割するようにすると、検索できなくなる文
字列がないようにすることができる。

【００１８】上述のように、登録文書をサイズ単位に分
割する際に、サイズ単位に分割した位置が文字列中なら
ば、そこからテキストの文字列を順に調べ、通常の検索
文字列には含まれない文字の後で分割するようにしたも
のであるが、例えば、以下の文字｛「、」(句
点)，「。」(読点)，「，」(カンマ)，「．」(ピリオ
ド)，タブ｝を通常の検索文字列には含まれない文字と
して分割の区切り文字とする。例えば、 テキスト：文字列の途中で分割すると、その文字列で検
索できなくなる。 において、分割位置を“…分割すると、…”の句
点「、」位置とする。

【００１９】上述のごときテキストを分割登録するため
には、テキストＩＤの管理を行うが、図７に、そのテキ
ストＩＤの管理について示す。テキストＩＤは外部テキ
ストＩＤは外部テキストＩＤと内部テキストＩＤの２種
類をもつ。大きなテキストを登録した場合には、前述の
ように幾つかのテキストに分割され、分割された各テキ
ストには、それぞれ内部テキストＩＤが割り当てられ、
同時に外部テキストＩＤが一つ割り当てられる。内部テ
キストＩＤと外部テキストＩＤの対応は、ＩＤテーブル
によって示される。内部テキストＩＤは文字成分表のＩ
Ｄとして利用され、外部テキストＩＤはユーザから見た
テキストＩＤとして利用される。

【００２０】

【発明の効果】請求項１の発明は、一括登録の開始時に
ユーザが指定したサイズのメモリ領域を確保し、確保し
たメモリ上にすべての各文字エントリに対して１つのブ
ロックをそれぞれ分り当て、登録時にブロック内に書き
込む余地が無くなった場合には、そのブロックを二次記
憶に書き出して空にした後、登録するようにし、処理の
最後に二次記憶に書き出すようにしたので、登録途中で
メモリが不足して登録を中断することがなく、高速に登
録することが可能となる。

【００２１】請求項２の発明は、一括登録の開始時にユ
ーザが指定したサイズのメモリ領域を確保し、全エント
リ数分のブロックで、かつ、数種類のサイズからなるブ
ロックを確保し、文書の登録処理時では、ブロック内の
空きがなくなり、メモリ上に書き出したデータ量が多い
ブロックについては、大きいサイズのブロックを利用す
ることにより、二次記憶へ書き出す回数を減らすように
したので、高速に大量文書を一括登録することができ
る。

【００２２】請求項３の発明は、長い文書の適合率を高
めるために、登録文書をある一定サイズに分割し、それ
ぞれを別文書として登録し、検索時にはひとつの文書と
して検索するが、その場合に、単純に一定サイズに分割
すると、通常検索語となるような文字列の途中で二つの
文書に分割されてしまい、検索時に検索できない問題が
生ずる点に鑑み、句読点などのように、検索語の中に通
常現れない文字を予め分割区切り文字とし、一定サイズ
で機械的に分割した位置が分割区切り文字でない場合に
は、分割区切り文字までテキストを辿り、到達した分割
区切り文字で分割するようにしたので、検索できなくな
る文字列がない。また、登録文書が長い場合に、文書を
分割することで検索精度の低下を抑え、かつ、分割する
位置を検索の対象としない文字にすることができ、検索
できない文字列をなくすことができる。

【図面の簡単な説明】

【図１】 本発明が適用される文書管理方式の一例を説
明するためのブロック図である。

【図２】 単一文字成分表の一例を示す図である。

【図３】 隣接文字成分表の一例を示す図である。

【図４】 一括登録処理の一例を説明するための図であ
る。

【図５】 メモリ上のデータ構成を示す図である。

【図６】 データブロックの例を示す図である。

【図７】 テキストＩＤの管理を説明するための図であ
る。

【符号の説明】

１…入力部、２…処理部、３…文字列入力処理部、４…
文書検索処理部、５…文書出力処理部、６…文書登録処
理部、７…データ部、８…文字成分表、９…出力部、１
０…文書データ。

【手続補正書】

【提出日】平成８年６月１０日

【手続補正１】

【補正対象書類名】明細書

【補正対象項目名】請求項３

【補正方法】変更

【補正内容】

【手続補正２】

【補正対象書類名】明細書

【補正対象項目名】００１６

【補正方法】変更

【補正内容】

【００１６】１．初期化 インデックスをメモリ上のインデックスにロードする。
データブロックとして利用するデータブロック領域をア
ロケートする。データブロック領域のサイズはユーザが
指定し、全文字成分の全エントリ数分のデータブロック
を生成する。ただし、データブロックのサイズは図６に
示したように複数のサイズをもつ。全文字エントリに対
して一つずつデータブロックを確保するので、一括登録
処理中にデータブロックが足りなくなることはない。 （ａ）エントリＩＤに対応するデータブロックが存在し
ない場合には、一番小さいデータブロック（Ｂ１）領域
からデータブロックをエントリＩＤに対応するデータブ
ロックとしてアロケートする。ただし、Ｂ１領域がすべ
て使用されている場合には、Ｂ１のデータブロックの中
でデータ量が最大であるブロツクをＢ２の空きブロック
に移動する。Ｂ２に空きデータブロックがない場合に
は、同様の処理を繰り返し、さらに大きなブロックにデ
ータを移動する。移動して空いたブロックをエントリＩ
Ｄに対応するデータブロックとする。あらかじめ全体の
ブロック数は全エントリ数分確保しておくので、ブロッ
クが確保できないことはない。 （ｂ）エントリＩＤに対応するデータブロックにビット
データを加える。加えるスペースがない場合には、デー
タブロックのデータを、次に大きいブロックをアロケー
トして登録する。次に、大きなブロックの空きがない場
合には、前述と同様の処理を繰り返す。ただし、この場
合、空きブロックが見つからない場合もあるが、その時
は、ブロックのデータを二次記憶に書き出してデータブ
ロックを空にして、そのまま同じブロックを利用する。 （ｃ）全てのエントリを登録するまで（ａ）に戻る。 ２．後処理 データブロック及びインデックスを二次記憶に書き出
す。

Claims (3)

【特許請求の範囲】
1. 【請求項１】 大量の文書データを保持し、入力装置か
   ら入力された検索文字列を含む文書を検索し、出力装置
   により検索した文書を出力する文書管理方式であって、
   文書登録時に文書より各文字コード成分及び２文字以上
   の隣接文字からビット列成分を算出し、各文書がそれぞ
   れの成分を含むか否かを示す単一文字成分表及び一つ以
   上の隣接文字成分表を生成し、該文字成分表の各文字成
   分のエントリを複数のブロックに分割して二次記憶に一
   括登録する文書管理方式において、一括登録の開始時
   に、ユーザが指定したサイズのメモリ領域を確保し、確
   保したメモリ上にすべての各文字エントリに対して１つ
   のブロックをそれぞれ割り当て、登録処理時、ブロック
   内に書き込む余地が無くなった場合には、そのブロック
   を二次記憶に書き出して空にした後登録することによっ
   て、登録途中でメモリが不足して登録を中断することが
   ないようにすることを特徴とする文書管理方式。
2. 【請求項２】 大量の文書データを保持し、入力装置か
   ら入力された検索文字列を含む文書を検索し、出力装置
   により検索した文書を出力する文書管理方式であって、
   文書登録時に文書より各文字コード成分及び２文字以上
   の隣接文字からビット列成分を算出し、各文書がそれぞ
   れの成分を含むか否かを示す単一文字成分表及び一つ以
   上の隣接文字成分表を生成し、該文字成分表の各文字成
   分のエントリを複数のブロックに分割して二次記憶に一
   括登録する文書管理方式において、一括登録の開始時
   に、ユーザが指定したサイズのメモリ領域を確保し、全
   エントリ数分のブロックで、かつ、数種類のサイズから
   なるブロックを確保し、文書の登録処理時、ブロック内
   の空きがなくなり、メモリ上に書き出したデータ量が多
   いブロックについては大きいサイズのブロックを利用す
   ることにより、二次記憶へ書き出す回数を減らし、高速
   に大量文書を一括登録ができるようにすることを特徴と
   する文書管理方式。
3. 【請求項３】 登録文書をある一定サイズに分割し、そ
   れぞれを別文書として登録し、検索時にはひとつの文書
   として検索することにより、長い文書の適合率を高める
   ようにした文書管理方式において、検索語の中に通常現
   れない文字を予め分割区切り文字とし、一定サイズで機
   械的に分割した位置が分割区切り文字でない場合には前
   記分割区切り文字までテキストを辿り、該分割区切り文
   字で分割するようにすることを特徴とする文書管理方
   式。