JPH0916616A - 索引データ生成検索装置 - Google Patents

Abstract

(57)【要約】 【目的】 記憶容量を低減することができ、高速検索可
能な日本語全文検索システムを提供する。 【構成】 混在データ記憶手段３は、異なる文字種で構
成された文書を複数記憶している。索引データ決定手段
５は、カタカナについては、同じ種類の文字が連続した
部分を一ブロックとして決定し各ブロックごとに、前記
混在データにおける位置を表す位置情報が付加されたカ
タカナ索引データを出力し、索引データ記憶手段７に記
憶される。検索手段９は、カタカナで構成された検索文
字列が与えられると、索引データ記憶手段７に記憶され
た索引データを参照して、前記位置情報を得て、混在デ
ータ記憶手段３に記憶された文書から与えられた検索文
字列を検索する。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】この発明は、データベースシステ
ムに関し、特に、文字種による索引データのデータ形式
変更に関する。

【０００２】

【従来技術およびその課題】今日、日本語テキストに対
する検索システムの一つとして全文検索システムが知ら
れている。全文検索システムとは、記憶されているファ
イルに用いられている文字列で検索を行なうシステムで
ある。具体的には、ファイル中の各文字について、ファ
イル番号および当該ファイルにおける文字位置カウンタ
値を一文字づつ記憶させたインデックス部を生成してお
く。そして検索文字列が与えられると、その検索対象の
文字列を１文字づつに分割し、分割した１文字が存在す
るファイルおよびその位置を求め、検索対象の文字列が
連続して存在する文字列のみを抽出する。

【０００３】このように、全文検索システムにおいて
は、あらかじめ人間がキーワードを付する必要がないの
で、キーワード設定作業が不要となり、また、キーワー
ドの選定による検索もれを防止することができる。

【０００４】しかしながら、従来の全文検索システムに
おいては、以下のような問題点があった。１文字づつフ
ァイル名および文字位置カウンタ値を記憶するようにし
ているので、膨大な記憶容量が必要となる。また検索文
字列の文字数が増えると、検索速度も極端に低下する。
これは上記検索において、複数の文字が連続して存在す
る部分を見つける必要があるからである。

【０００５】この発明は、上記の問題点を解決して、記
憶容量の節約および検索速度を向上させることができる
索引データ生成装置または検索装置を提供することを目
的とする。

【０００６】また、この発明は、上記の問題点を解決し
て、記憶容量の節約および検索速度を向上させることが
できる日本語文書管理装置、日本語文書管理方法を提供
することを目的とする。

【０００７】

【課題を解決するための手段】請求項１の索引データ生
成装置においては、第１種類の文字および第２種類の文
字が混在する混在データが与えられると、第１種類の文
字については一文字を一ブロックとして決定し各ブロッ
クごとに、前記混在データにおける位置を表す位置情報
が付加された第１文字種索引データを出力するととも
に、第２種類の文字については、同じ種類の文字が連続
した部分を一ブロックとして決定し各ブロックごとに、
前記混在データにおける位置を表す位置情報が付加され
た第２文字種索引データを文字種別索引データとして出
力する索引データ決定手段、前記文字種別索引データを
記憶する索引データ記憶手段、を備えたことを特徴とす
る。

【０００８】請求項２の索引データ生成装置において
は、前記混在データは、さらに第３種類の文字を含み、
前記索引データ決定手段は、この第３種類の文字につい
ても、同じ種類の文字が連続した部分を一ブロックとし
て決定し各ブロックごとに、前記混在データにおける位
置を表す位置情報が付加された第３文字種索引データを
含む文字種別索引データを出力し、前記索引データ記憶
手段は、この第３文字種索引データを含む文字種別索引
データを記憶すること、を特徴とする。

【０００９】請求項３の索引データ生成装置において
は、前記混在データは、複数のファイルから構成されて
おり、前記文字種別索引データは、各々以下の1)第１イ
ンデックスおよび2)第２インデックスを有すること、1)
各ブロックを構成する文字で構成された第１インデック
ス、2)前記第１インデックスに関連づけられた第２イン
デックスであって、前記第１インデックスを有するファ
イル名、前記第１インデックスが当該ファイルに存在す
る個数、および前記第１インデックスが当該ファイルに
存在する位置を有する第２インデックス、を特徴とす
る。

【００１０】請求項４の検索装置においては、第１種類
の文字および第２種類の文字が混在する混在データを記
憶する混在データ記憶手段、前記第１種類の文字につい
ては、一文字で一ブロックとし、前記第２種類の文字に
ついては、同じ種類の文字が連続した部分を一ブロック
として、各ブロックごとに、前記混在データにおける位
置を表す位置情報が付加された文字種別索引データを記
憶する索引データ記憶手段、前記第２種類の文字で構成
された文字列が、検索文字列として与えられると、前記
索引データ記憶手段に記憶された文字種別索引データを
参照して、前記位置情報を得て、前記混在データから前
記検索文字列を検索する検索手段、を備えたことを特徴
とする。

【００１１】請求項５の検索装置においては、前記検索
手段は、1)前記第１種類の文字および前記第２種類の文
字が混在する混在検索文字列が与えられると、前記第１
種類の文字については、一文字で一検索ブロックとし、
前記第２種類の文字については、同じ種類の文字が連続
した部分を一検索ブロックとして決定する検索ブロック
決定手段、2)前記検索ブロック決定手段が決定した一検
索ブロックに基づいて、前記混在検索文字列が存在する
か検索する混在検索文字列検索手段、3)前記各検索ブロ
ックが、前記混在データ記憶手段に前記混在検索文字列
の順序で存在するか否か判断する判断手段、を有してい
ることを特徴とする。

【００１２】請求項６の日本語文書管理装置において
は、ひらがな、漢字、およびカタカナが混在する文書を
記憶する文書記憶手段、前記文書記憶手段に記憶された
文書についての索引データを生成する索引データ生成手
段であって、注目する文字がひらがな又は漢字である場
合には、一文字ごとに前記文書における位置を表す位置
情報が付加された索引データを生成し、注目する文字が
カタカナである場合には、カタカナが連続する部分が１
のブロックであると判断して、このブロックの前記文書
における位置を表す位置情報が付加された索引データを
生成する索引生成手段、前記索引データを文字種別に記
憶する文字種別索引データ記憶手段、カタカナで構成さ
れた検索文字列が与えられた場合には、前記文字種別索
引データ記憶手段に記憶された文字種別索引データを参
照して、前記検索文字列の位置情報を得て、前記文書か
ら前記検索文字列を検索する検索手段、を備えたことを
特徴とする。

【００１３】請求項７の索引データ生成方法において
は、第１種類の文字および第２種類の文字が混在する混
在データが与えられると、第１種類の文字については、
一文字で一ブロックとし、第２種類の文字については、
同じ種類の文字が連続した部分を一ブロックとして決定
するとともに、各ブロックごとに、前記混在データにお
ける位置を表す位置情報が付加された文字種別索引デー
タを生成することを特徴とする。

【００１４】請求項８の検索方法においては、第１種類
の文字および第２種類の文字が混在する混在データ中の
第１種類の文字については一文字で一ブロックとし、第
２種類の文字については、同じ種類の文字が連続した部
分を一ブロックとして、前記各ブロックごとに、前記混
在データにおける位置を表す位置情報が付加された索引
データを記憶しておき、前記第２種類の文字で構成され
た文字列が、検索文字列として与えられると、前記索引
データを参照して前記位置情報を得て、前記混在データ
から前記検索文字列を検索することを特徴とする。

【００１５】請求項９の日本語文書管理方法において
は、ひらがな、漢字、およびカタカナが混在する文書を
記憶しておき、前記文書について、注目する文字がひら
がな又は漢字である場合には、一文字ごとに前記文書に
おける位置を表す位置情報が付加された索引データを生
成し、注目する文字がカタカナである場合には、カタカ
ナが連続する部分が１のブロックであると判断して、こ
のブロックの前記文書における位置を表す位置情報が付
加された索引データを生成して、記憶しておき、カタカ
ナで構成された検索文字列が与えられた場合には、前記
索引データを参照して当該検索文字列の位置情報を得
て、前記文書から前記検索文字列を検索すること、を特
徴とする。

【００１６】請求項１０のコンピュータを稼働させるプ
ログラムを記憶した記憶媒体は、第１種類の文字および
第２種類の文字が混在する混在データが与えられると、
第１種類の文字については、一文字で一ブロックとし、
第２種類の文字については、同じ種類の文字が連続した
部分を一ブロックとして決定するとともに、各ブロック
ごとに、前記混在データにおける位置を表す位置情報が
付加された索引データを生成させることを特徴とする。

【００１７】請求項１１のコンピュータを稼働させるプ
ログラムを記憶した記憶媒体においては、第２文字種で
構成された検索文字列が与えられると、この検索文字列
が、同じ種類の文字が連続した部分を一ブロックとした
索引データとして記憶されているか否かを判断し、前記
索引データとして記憶されている場合には、この索引デ
ータに基づいて、前記第１種類の文字および前記第２種
類の文字が混在する混在データから前記検索文字列を検
索させることを特徴とする。

【００１８】

【作用】請求項１、請求項７の索引データ生成装置また
は索引データ生成方法においては、第１種類の文字およ
び第２種類の文字が混在する混在データが与えられる
と、第１種類の文字については、一文字で一ブロックと
し、第２種類の文字については、同じ種類の文字が連続
した部分を一ブロックとして決定するとともに、各ブロ
ックごとに、前記混在データにおける位置を表す位置情
報が付加された索引データを生成する。したがって、第
２種類の文字については、複数文字から構成された１ブ
ロックの索引データを得ることができる。このように、
第２種類の文字だけでも、１ブロックの索引データで索
引情報を構成することにより、記憶容量の削減および検
索速度を向上させることができる。

【００１９】また、その際、文字の種類を判断するだけ
でよい。これにより、第２種類の文字については、辞書
等と照合することなく、複数の文字列から構成された索
引データを作成することができる。

【００２０】請求項２の索引データ生成装置において
は、前記混在データは、さらに第３種類の文字を含み、
この第３種類の文字についても、同じ種類の文字が連続
した部分を一ブロックとして決定するとともに、各ブロ
ックごとに、前記混在データにおける位置を表す位置情
報が付加された索引データを生成する。したがって、こ
の第３種類の文字についても、１ブロックの索引データ
で索引情報を構成することにより、記憶容量をより削減
でき、さらに検索速度を向上させることができる。

【００２１】請求項３の索引データ生成装置において
は、前記索引データは、各ブロックを構成する文字で構
成された第１インデックスを有している。したがって、
検索の際に、この第１インデックスを検索するだけで、
当該文字列が存在するか否かを判断することができる。
さらに、前記第２インデックスは、各ファイルに存在す
る個数および存在する位置を有する。このように第２イ
ンデックスは、ファイルと存在する位置というペア情報
ではないので、同一ファイル中に、前記第１インデック
スが複数存在する場合であっても、記憶容量がそれほど
増えることがない。

【００２２】請求項４、請求項８の検索装置または検索
方法においては、第１種類の文字および第２種類の文字
が混在する混在データ中の第１種類の文字については一
文字で一ブロックとし、第２種類の文字については、同
じ種類の文字が連続した部分を一ブロックとして、前記
各ブロックごとに、前記混在データにおける位置を表す
位置情報が付加された索引データを記憶しておき、前記
第２種類の文字について記憶されている索引データが、
検索文字列として与えられると、前記索引データを参照
して前記位置情報を得て、前記混在データから前記検索
文字列を検索する。したがって、検索の際に、前記第２
種類の文字については、複数のブロックを組合わせるこ
となく、検索が可能となる。これにより、高速検索がで
きる。

【００２３】請求項５の検索装置においては、前記第１
種類の文字および前記第２種類の文字が混在する混在検
索文字列が与えられると、前記第１種類の文字について
は、一文字で一検索ブロックとし、前記第２種類の文字
については、同じ種類の文字が連続した部分を一検索ブ
ロックとして決定する。決定した一検索ブロックに基づ
いて、前記混在検索文字列が存在するか検索する。そし
て、前記各検索ブロックが、前記混在データに前記混在
検索文字列の順序で存在するか否か判断する。前記第２
種類の文字については一検索ブロックが複数の文字から
構成されているので、組合わせ数が全体として減少する
ので、高速検索ができる。

【００２４】請求項６、請求項９の日本語文書管理装置
または日本語文書管理方法においては、ひらがな、漢
字、およびカタカナが混在する文書について、注目する
文字がひらがな又は漢字である場合には、一文字ごとに
前記文書における位置を表す位置情報が付加された索引
データを生成し、注目する文字がカタカナである場合に
は、カタカナが連続する部分が１のブロックであると判
断して、このブロックの前記文書における位置を表す位
置情報が付加された索引データを生成して、記憶する。
したがって、この索引データは、カタカナについては連
続する部分が１のブロックであると認識される。したが
って、記憶容量を低減することができる。

【００２５】また、カタカナで構成された検索文字列が
与えられた場合には、前記索引データを参照して当該検
索文字列の位置情報を得て、前記文書から前記検索文字
列を検索する。したがって、検索の際に、カタカナにつ
いては、複数のブロックを組合わせることなく、検索が
可能となる。したがって、高速検索ができる。

【００２６】請求項１０のプログラムを記憶した記憶媒
体においては、第１種類の文字および第２種類の文字が
混在する混在データが与えられると、第１種類の文字に
ついては、一文字で一ブロックとし、第２種類の文字に
ついては、同じ種類の文字が連続した部分を一ブロック
として決定するとともに、各ブロックごとに、前記混在
データにおける位置を表す位置情報が付加された索引デ
ータを生成させるように、コンピュータを稼働させる。
したがって、コンピュータは、第２種類の文字について
は、複数文字から構成された１ブロックの索引データを
得ることができる。このように、第２種類の文字だけで
も、１ブロックの索引データで索引情報を構成すること
により、記憶容量の削減および検索速度を向上させるこ
とができる。

【００２７】請求項１１のプログラムを記憶した記憶媒
体においては、第２文字種で構成された検索文字列が与
えられると、この検索文字列が、同じ種類の文字が連続
した部分を一ブロックとした索引データとして記憶され
ているか否かを判断し、前記索引データとして記憶され
ている場合には、この索引データに基づいて、前記第１
種類の文字および前記第２種類の文字が混在する混在デ
ータから前記検索文字列を検索させるようにコンピュー
タを稼働させる。したがって、検索の際に、第２種類の
文字については、複数のブロックを組合わせることな
く、検索が可能となる。したがって、高速検索ができ
る。

【００２８】

【実施例】

１．機能ブロック図の説明 本発明の一実施例を図面に基づいて説明する。図１に示
す索引データ生成検索装置１においては、索引データ決
定手段５、索引データ記憶手段７、混在データ記憶手段
３および検索手段９を備えている。

【００２９】混在データ記憶手段３は、複数のファイル
を記憶しており、各ファイルは第１種類、第２種類およ
び第３種類の文字が混在する混在データから構成されて
いる。索引データ決定手段５は、第１種類、第２種類お
よび第３種類の文字が混在する混在データが与えられる
と、第１種類の文字については一文字を一ブロックとし
て決定し各ブロックごとに、前記混在データにおける位
置を表す位置情報が付加された第１文字種索引データを
出力する。また、第２種類の文字については、同じ種類
の文字が連続した部分を一ブロックとして決定し各ブロ
ックごとに、前記混在データにおける位置を表す位置情
報が付加された第２文字種索引データを出力する。ま
た、第３種類の文字については、同じ種類の文字が連続
した部分を一ブロックとして決定し各ブロックごとに、
前記混在データにおける位置を表す位置情報が付加され
た第３文字種索引データを出力する。索引データ記憶手
段７は、この第１文字種索引データ、第２文字種索引デ
ータ、および第３文字種索引データを記憶する。

【００３０】第１文字種索引データは、各々、以下に説
明する第１文字種第１インデックスおよび第１文字種第
２インデックスを有する。第１文字種第１インデックス
は、各ブロックを構成する文字列で構成されている。第
１文字種第２インデックスは、第１文字種第１インデッ
クスに関連づけられており、第１文字種第１インデック
スを有するファイル名、第１文字種第１インデックスが
当該ファイルに存在する個数、および第１文字種第１イ
ンデックスが当該ファイルに存在する位置を有する。第
２文字種索引データについても、同様に、第２文字種第
１インデックスおよび第２文字種第２インデックスを有
する。第３文字種索引データについても、同様に、第３
文字種第１インデックスおよび第３文字種第２インデッ
クスを有する。

【００３１】検索手段９は、第２種類の文字で構成され
た文字列が、検索文字列として与えられると、索引デー
タ記憶手段７に記憶された文字種別索引データ（第１文
字種索引データ、第２文字種索引データ、および第３文
字種索引データ）を参照して、前記位置情報を得て、混
在データ記憶手段３に記憶された混在データから与えら
れた検索文字列を検索する。

【００３２】検索手段９の詳細について説明する。検索
手段９は、検索ブロック決定手段１１、混在検索文字列
検索手段１２、および判断手段１３を有している。検索
ブロック決定手段１１は、第１種類の文字および前記第
２種類の文字が混在する混在検索文字列が与えられる
と、第１種類の文字については、一文字で一検索ブロッ
クとし、第２種類の文字については、同じ種類の文字が
連続した部分を一検索ブロックとして決定する。混在検
索文字列検索手段１２は、検索ブロック決定手段１１が
決定した一検索ブロックに基づいて、混在検索文字列が
存在するか検索する。判断手段１３は、各検索ブロック
が、混在データ記憶手段３に混在検索文字列の順序で存
在するか否か判断する。

【００３３】本実施例においては、カタカナが第２種類
の文字に該当し、アルファベットが第３種類の文字に該
当し、上記以外の漢字およびひらがなが第１種類の文字
に該当する。

【００３４】２．ハードウェア構成の説明 図２は、図１に示す全文検索システム１をＣＰＵを用い
て実現したハードウェア構成の一例を示す。

【００３５】全文検索システム１は、ＣＰＵ２３、ＦＤ
Ｄ２５、メモリ２７、ハードディスク２６、キーボード
２８、マウス３３、バスライン２９、プリンタ３１およ
びＣＲＴ３０を備えている。キーボード２８およびマウ
ス３３は、各種の命令を入力する命令入力手段である。

【００３６】ＣＰＵ２３は、ハードディスク２６に記憶
された制御プログラムにしたがいバスライン２９を介し
て、各部を制御する。

【００３７】この制御プログラムは、ＦＤＤ３３を介し
て、プログラムが記憶されたフレキシブルディスクから
読み出されてハードディスク２６に記憶された（インス
トールされた）ものである。メモリ２７は、カタカナ文
字列バッファ、アルファベット文字列バッファ、その他
文字列バッファ、索引バッファ、トークンバッファ、ワ
ークエリアを有している。

【００３８】ハードディスク２６は、文書データ記憶
部、カタカナ第１インデックス記憶部、カタカナ第２イ
ンデックス記憶部、アルファベット第１インデックス記
憶部、アルファベット第２インデックス記憶部、その他
第１インデックス記憶部、その他第２インデックス記憶
部を有している。

【００３９】ＣＲＴ３０には、ＣＰＵ２３が処理した処
理結果等が表示される。

【００４０】３．フローチャートの説明 3-1．索引生成のフローチャートについて つぎに、図５を用いて、ハードディスク２６に記憶され
ているプログラムについて説明する。

【００４１】まず、索引生成のフローチャートを説明す
る。ここでは、図３に示す文書０、および図４に示す文
書１が与えられたとして説明する。なお、図３、図４に
おいては、漢字の後は空白となっているが、これは、漢
字は２バイト、それ以外は１バイトがデータが構成され
ている為、先頭からの位置（バイト数）を理解しやすく
するものであり、現実のデータはデータが連続してい
る。

【００４２】ＣＰＵ２３は、図３および図４に示す文書
０、文書１のテキストデータを読み込む（図５ステップ
ＳＴ１）。ハードディスク２６の文書データ記憶部か
ら、メモリ２７のワークエリアに読み込まれることによ
り、これらのテキストの読み込みが行われる。

【００４３】つぎに、ＣＰＵ２３は、索引作成処理を行
なう（図５ステップＳＴ３）。索引作成処理について図
６、図７を用いて説明する。

【００４４】ＣＰＵ２３は、処理対象文字数ｉおよびカ
レント状態ｓを初期化する（図６ステップＳＴ１１）。
つぎに、ＣＰＵ２３は、前状態ｒとしてカレント状態ｓ
の状態を記憶する（ステップＳＴ１３）。つぎに、ＣＰ
Ｕ２３は、図８に示す状態遷移図を用いて、カレント状
態ｓおよびｉ番目の文字種に基づき、カレント状態ｓが
どのように変化するか（変化しない場合も含む）を求め
る（図６ステップＳＴ１５）。

【００４５】状態遷移図について図８を用いて説明す
る。カレント状態が状態０でｉ番目の文字種がカタカナ
である場合は、カレント状態は状態１となる。この状態
１からカタカナ以外の文字種が与えられると（ＥＯＦを
含む）、カレント状態は状態４に移る。状態１にて、文
字種としてカタカナが与えられている間は、カレント状
態は、状態１のまま保持される。

【００４６】また、状態０でｉ番目の文字種がアルファ
ベットである場合には、カレント状態は状態２となる。
そして、この場合も状態１の場合と同様に、この状態か
らアルファベット以外（ＥＯＦを含む）が与えられる
と、カレント状態は状態４となる。

【００４７】また、状態０からその他の文字が与えられ
ると、カレント状態は状態３に移る。この実施例では、
その他の文字として、ひらがな、漢字およびその他の記
号を採用した。状態３では、つぎに、いずれの種類の文
字が与えられた場合でも、カレント状態は状態４に移
る。状態４からは、状態０に移る。

【００４８】具体的に、図３に示す文書０が与えられた
場合の処理について説明する。まずこの場合、処理対象
文字数ｉ＝０に設定されているので、ＣＰＵ２３は、文
書０（図３参照）の０バイト目の文字「Ｑ」を読み込
む。文字「Ｑ」はアルファベットであるので、図６ステ
ップＳＴ１５において、図８に示す状態遷移図にしたが
って、カレント状態は、状態０から状態２となる。

【００４９】つぎに、ＣＰＵ２３は、カレント状態が状
態４か（ｓ＝４）否か判断する（図６ステップＳＴ１
６）。この場合、カレント状態は状態２であるので、ス
テップＳＴ１７に進み、ｉ番目（０番目）の文字種類に
ついて判断する。この場合、０番目の文字種類はアルフ
ァベットであるので、メモリ２７のアルファベット文字
列バッファに、文字「Ｑ」を記憶する（ステップＳＴ１
９）。つぎに、ＣＰＵ２３は、処理対象文字数ｉをイン
クリメントし（ステップＳＴ２１）、カレント状態ｓを
前状態ｒとして記憶する（図６ステップＳＴ１３）。カ
レント状態は状態２であるので、前状態ｒには状態２が
記憶される。

【００５０】つぎにＣＰＵ２３は、ステップＳＴ１５の
処理を行なう。この場合、処理対象文字数ｉ＝１なの
で、１バイト目の文字「ｕ」の文字種を判断する。文字
「ｕ」はアルファベットであるので、図８に示す状態遷
移図に示すように、状態２のままで保持される。したが
って、カレント状態ｓは状態２のまま変化しない。

【００５１】ＣＰＵ２３は、カレント状態ｓが状態４か
否か判断する（図６ステップＳＴ１６）。この場合、カ
レント状態ｓは状態２であるので、ステップＳＴ１７に
進み、ｉ番目（１番目）の文字種類を判断する。この場
合、文字種類はアルファベットであるので、ＣＰＵ２３
は、メモリ２７のアルファベット文字列バッファに１番
目の文字「ｕ」を追加記憶する（ステップＳＴ１９）。
すなわち、アルファベット文字列バッファには、「Ｑ
ｕ」と記憶される。

【００５２】このような処理を、処理対象文字数ｉ＝７
まで繰返して、アルファベット文字列バッファに、「Ｑ
ｕａｎｔｉｆｙ」と記憶される。

【００５３】つぎに、ＣＰＵ２３は、ステップＳＴ２１
にて処理対象文字数ｉをインクリメントし（ｉ＝８）、
カレント状態ｓを前状態ｒとして記憶する（図６ステッ
プＳＴ１３）。この場合、カレント状態は状態２である
ので、前状態ｒは状態２が記憶される。

【００５４】ここでｉ番目（８番目）の文字種は、ひら
がな「は」であるので、図８に示す状態遷移図に基づい
て、カレント状態ｓは状態４となる（図６ステップＳＴ
１５）。ＣＰＵ２３は、カレント状態ｓが状態４である
ので、ステップＳＴ１６からステップＳＴ２２に進む。
ステップＳＴ２２では、前状態ｒが状態１、状態２、ま
たは状態３であるかを判断する。この場合、前状態ｒが
状態２であるので、ＣＰＵ２３はステップＳＴ２５に進
み、アルファベット文字列バッファの内容「Ｑｕａｎｔ
ｉｆｙ」をトークンとしてメモリ２７のワークエリアに
記憶する。

【００５５】そして、ステップＳＴ２６に進み、アルフ
ァベット文字列バッファをクリアする。つぎに、ＣＰＵ
２３は、ステップＳＴ３０に進み、カレント状態を状態
０とする。

【００５６】ＣＰＵ２３は、メモリ２７のワークエリア
に記憶したトークン「Ｑｕａｎｔｉｆｙ」が、既に登録
されているか否か判断する（図７ステップＳＴ３３）。
この場合、はじめてのトークンであるので、当該トーク
ン、および索引データを、メモリ２７の索引バッファに
記憶する（ステップＳＴ３４）。本実施例においては、
索引データとして、ファイル番号および文字位置カウン
タ値を採用した。すなわち、この場合、索引バッファに
は、トークン「Ｑｕａｎｔｉｆｙ」、ファイル番号
「０」、および文字位置カウンタ「０」が記憶される。
このように、して、ｉ−１番目（７番目）までの文字に
ついての処理が終了する。

【００５７】つぎに、ＣＰＵ２３は、ファイルの最終ま
で処理したか否か判断する（ステップＳＴ３７）。この
場合、ファイルの最終まで処理が終了していないので、
ｉ番目（８番目）の文字の処理を行う。

【００５８】ステップＳＴ３０にて、カレント状態ｓを
状態０としたので、ｉ番目（８番目）の文字について、
再度ステップＳＴ１３、ステップＳＴ１５の処理を行
う。これにより、前状態ｒ＝０、カレント状態ｓ＝３と
なる。ステップＳＴ１６にて、カレント状態は状態３で
あるので、ステップＳＴ１７に進み、ｉ番目（８番目）
の文字種類について判断する。この場合、ｉ番目（８番
目）の文字種類は、ひらがなである。したがって、メモ
リ２７のその他文字列バッファに、文書０の８番目の文
字「は」を記憶する（図６ステップＳＴ２０）。そし
て、ＣＰＵ２３は、ｉをインクリメントして、処理対象
文字数ｉ＝９とする。

【００５９】つぎに、ＣＰＵ２３は、前状態ｒとして、
カレント状態ｓの状態（この場合状態３）を記憶する
（図６ステップＳＴ１３）。そして、ステップＳＴ１５
の処理を行なう。

【００６０】ここで９番目の文字種は句点「、」である
ので、図８に示す状態遷移図に基づいて、カレント状態
ｓは、状態３から状態４となる。ＣＰＵ２３は、ステッ
プＳＴ１６にて、カレント状態ｓが状態４であるので、
ステップＳＴ２２に進み、前状態ｒの値を判断する。こ
の場合、前状態ｒは状態３であるので、ステップＳＴ２
８に進み、その他文字列バッファの内容を、トークンと
してメモリ２７に記憶する。すなわち、ひらがな「は」
が記憶される。ＣＰＵ２３は、その他文字列バッファの
内容をクリアし（ステップＳＴ２９）、カレント状態ｓ
を状態０とする（ステップＳＴ３０）。

【００６１】ＣＰＵ２３は、トークン「は」が既に登録
されているトークンか否か判断する（図７ステップＳＴ
３３）。この場合、ひらがな「は」は、登録されている
トークンではないので、当該トークン「は」、ファイル
番号「０」、文字位置カウンタ「８」が、索引バッファ
に記憶される。この状態の索引バッファのデータ構造
を、図９Ｂに示す。図に示すように、トークン「Ｑｕａ
ｎｔｉｆｙ」とトークン「は」について、夫々、索引デ
ータ「０、０」と「０、８」が記憶されている。

【００６２】つぎに、ＣＰＵ２３は、ステップＳＴ３７
に進み、ファイルエンドか否か判断する。この場合、フ
ァイルエンドではないので、ｉ番目（９番目）の文字に
ついて、再度図６ステップＳＴ１３、ステップＳＴ１５
の処理を行う。これにより、前状態ｒ＝０、カレント状
態ｓ＝３となる。ステップＳＴ１６にて、カレント状態
は状態３であるので、ステップＳＴ１７に進み、ｉ番目
（９番目）の文字種類について判断する。この場合、ｉ
番目（９番目）の文字種類は、記号である。したがっ
て、その他文字列バッファに、文書０の９番目の文
字「、」を記憶する（図６ステップＳＴ２０）。そし
て、ｉをインクリメントして、処理対象文字数ｉ＝１０
とする。

【００６３】つぎに、ＣＰＵ２３は、前状態ｒとして、
カレント状態ｓの状態（この場合状態３）を記憶する
（図６ステップＳＴ１３）。そして、ステップＳＴ１５
の処理を行なう。

【００６４】ここで１０番目の文字種は、カタカナ
「ア」であるので、図８に示す状態遷移図に基づいて、
カレント状態ｓは、状態３から状態４となる。ＣＰＵ２
３は、ステップＳＴ１６にて、カレント状態ｓが状態４
であるので、ステップＳＴ２２に進み、前状態ｒの値を
判断する。この場合、前状態ｒは状態３であるので、ス
テップＳＴ２８に進み、その他文字列バッファの内容
を、トークンとしてメモリ２７に記憶する。すなわち、
記号「、」が記憶される。ＣＰＵ２３は、その他文字列
バッファの内容をクリアし（ステップＳＴ２９）、カレ
ント状態ｓを状態０とする（ステップＳＴ３０）。

【００６５】ＣＰＵ２３は、トークン「、」が既に登録
されているトークンか否か判断する（図７ステップＳＴ
３３）。この場合、トークン「、」は、既に登録されて
いるトークンではないので、当該トークン「、」、ファ
イル番号「０」、文字位置カウンタ「９」が、索引バッ
ファに記憶される（図示せず）。

【００６６】つぎに、ＣＰＵ２３は、ステップＳＴ３７
に進み、ファイルエンドか否か判断する。この場合、フ
ァイルエンドではないので、ｉ番目（１０番目）の文字
について、再度図６ステップＳＴ１３、ステップＳＴ１
５の処理を行う。これにより、前状態ｒ＝０、カレント
状態ｓ＝１となる。ステップＳＴ１６にて、カレント状
態は状態１であるので、ステップＳＴ１７に進み、ｉ番
目（１０番目）の文字種類について判断する。この場
合、ｉ番目（１０番目）の文字種類は、カタカナであ
る。したがって、メモリ２７のカタカナ文字列バッファ
に、文書０の１０番目の文字「ア」を記憶する（図６ス
テップＳＴ１８）。そして、ｉをインクリメントして、
処理対象文字数ｉ＝１１とする。

【００６７】つぎにＣＰＵ２３は、ｉをインクリメント
し（ステップＳＴ２１）、ステップＳＴ１３にてカレン
ト状態ｓ（状態１）を前状態ｒとして記憶する。つぎに
ＣＰＵ２３は、ステップＳＴ１５の処理を行なう。この
場合、ｉ番目（１１番目）の文字種はカタカナ「プ」で
あるので、カレント状態ｓは状態１のまま変化しない。

【００６８】つぎに、ＣＰＵ２３は、ステップＳＴ１６
にて、カレント状態ｓが状態４でないと判断し、ステッ
プＳＴ１７にてｉ番目（１１番目）の文字種類を判断す
る。この場合、１１番目の文字種類はカタカナであるの
で、カタカナ文字列バッファに「プ」が記憶される。す
なわち、カタカナ文字列バッファには、「アプ」が記憶
される。

【００６９】このような処理を、処理対象文字数ｉ＝１
７まで繰返して、カタカナ文字列バッファに、「アプリ
ケーション」と記憶される。

【００７０】ＣＰＵ２３は、ステップＳＴ２１にて処理
対象文字数ｉをインクリメントし、処理対象文字数ｉ＝
１８となった場合、図６ステップＳＴ１３にてカレント
状態ｓ（状態１）が前状態ｒとして記憶される。

【００７１】ステップＳＴ１５にて、１８番目の文字
種、この場合１８番目の文字種はひらがな「の」である
ので、カレント状態ｓは状態４となる。したがってＣＰ
Ｕ２３は、ステップＳＴ１６からステップＳＴ２２に進
み、前状態ｒについて判断する。この場合、前状態ｒ＝
１であるので、ステップＳＴ２３に進み、カタカナ文字
列バッファの内容をトークンとして記憶する。すなわ
ち、この場合、「アプリケーション」がトークンとして
記憶される。

【００７２】つぎにＣＰＵ２３は、カタカナ文字列バッ
ファの内容をクリアする（ステップＳＴ２４）。そして
ステップＳＴ３０にてカレント状態ｓを状態０とする。

【００７３】つぎに、ＣＰＵ２３は、ステップＳＴ３３
に進み、トークン「アプリケーション」が登録されてい
るトークンか否か判断する。この場合、「アプリケーシ
ョン」は登録されていないので、当該トークン「アプリ
ケーション」、ファイル番号「０」、文字位置カウンタ
「１０」が、索引バッファに記憶される（図７ステップ
ＳＴ３４）。

【００７４】つぎに、ＣＰＵ２３は、ファイルエンドか
否か判断する（ステップＳＴ３７）。この場合、ファイ
ルエンドではないので、ｉ番目（１８番目）の文字につ
いて、再度図６ステップＳＴ１３、ステップＳＴ１５の
処理を行う。これにより、前状態ｒ＝０、カレント状態
ｓ＝３となる。ステップＳＴ１６にて、カレント状態は
状態３であるので、ステップＳＴ１７に進み、ｉ番目
（１８番目）の文字種類について判断する。この場合、
ｉ番目（１８番目）の文字種類は、ひらがなである。し
たがって、その他文字列バッファに、文書０の１８番目
の文字「の」を記憶する（図６ステップＳＴ２０）。そ
して、ｉをインクリメントして、処理対象文字数ｉ＝１
９とする。このようにして、ファイル「０」の文字列
が、文字種毎に索引バッファに記憶される。

【００７５】本実施例においては、以上説明したよう
に、カタカナおよびアルファベットについては、それが
連続している限り１つのトークンとして記憶される。

【００７６】なお、図７ステップＳＴ３３において、既
に登録されているトークンであると判断した場合は、Ｃ
ＰＵ２３は登録されているトークンの後に、当該トーク
ンのファイル番号と文字位置カウンタを追加記憶する
（ステップＳＴ３５）。具体的には、図９Ｃに示すよう
に、トークン「Ｑｕａｎｔｉｆｙ」索引データ「０，
０」とある後に「０，９２」が記憶される。このような
処理を、ファイルエンドまで繰り返す。ステップＳＴ３
７にてファイルエンドとなった場合には、索引生成処理
が終了する。

【００７７】つぎに、ＣＰＵ２３は、図５ステップＳＴ
７にて、全てのテキストについて索引生成処理が終了し
たか否か判断し、終了していない場合には図５ステップ
ＳＴ１およびステップＳＴ３の処理を繰り返す。このよ
うにして、図９Ｄに示すように、メモリ２７の索引バッ
ファにトークンおよび索引データが記憶される。

【００７８】ＣＰＵ２３は、図５ステップＳＴ７にて全
てのテキスト処理が終了したと判断した場合には、索引
整理処理（図５ステップＳＴ９）を行なう。索引整理処
理について、図１０および図１１を用いて説明する。

【００７９】ＣＰＵ２３は、索引バッファの処理対象番
号ｐを初期化する（図１０ステップＳＴ５１）。つぎ
に、ファイル番号ｑを初期化する（ステップＳＴ５
３）。つぎに、ｐ番目のトークンを索引バッファから読
み出す（ステップＳＴ５５）。この場合、図９Ｄに示す
ように、ｐ番目（０番目）のトークンは、トークン「Ｑ
ｕａｎｔｉｆｙ」であるので、当該トークン「Ｑｕａｎ
ｔｉｆｙ」が読み出される。

【００８０】つぎに、ＣＰＵ２３は、読み出されたトー
クンの文字種類について判断する（図１０ステップＳＴ
５７）。この場合、文字種としては、アルファベットで
あるので、ステップＳＴ７１に進み、ファイル番号ｑ
（この場合、ファイル０）の文字位置カウンタがあるか
どうか判断する。この場合、ファイル０のデータが２つ
存在するので、この個数２と文字位置カウンタ「０，９
２」をハードディスク２６のアルファベット第２インデ
ックス記憶部に記憶する（ステップＳＴ７３）。

【００８１】つぎに、ファイル番号が最終か否か判断
し、最終でなければ、ステップＳＴ７７でファイル番号
ｑをインクリメントし、ステップＳＴ７１以下の処理を
繰り返す。この場合、図９Ｄに示すように、ファイル１
のデータが存在しないので、ステップＳＴ７５に進み、
ファイル番号が最終であるので、ステップＳＴ７９に進
み、当該トークン、アルファベット第２インデックス上
の位置、およびそのサイズを、ハードディスク２６のア
ルファベット第１インデックス記憶部に記憶する（ステ
ップＳＴ７９）。この場合、トークン「Ｑｕａｎｔｉｆ
ｙ」、アルファベット第２インデックス上の位置
「０」、サイズ「１６」が、図１２Ｂに示すように記憶
される。

【００８２】なお、この場合、サイズが１６となってい
るのは、図１２Ａに示すように、「０，２，０，９２」
と４つのデータがあり、各データについて、４バイトで
表した為、４×４＝１６となったものである。

【００８３】つぎに、ＣＰＵ２３は、図１１ステップＳ
Ｔ９１に進み、索引バッファに記憶されているデータ
が、全て処理したか否か判断する。終了していない場合
には、ステップＳＴ９３に進み、処理対象ファイルｐを
インクリメントし、ステップＳＴ５３以下の処理を繰り
返す。この場合、図９Ｄに示す索引バッファには、つぎ
に「は」が記憶されているので、この１番目のトークン
が読み出される（図１０ステップＳＴ５５）。つぎに、
読み出されたトークンの文字種類について判断する（ス
テップＳＴ５７）。この場合、読み出されたトークン
は、ひらがなであるので、図１１ステップＳＴ８０に進
み、ひらがな「は」のファイル番号ｑのデータを抽出す
る。この場合、図９Ｄに示すようにファイル番号ｑ（こ
の場合、ファイル０）のデータとしては、文字位置カウ
ンタ８および文字位置カウンタ１００が存在するので、
ステップＳＴ８１にてデータが存在すると判断し、その
個数「２」と文字位置カウンタ「８，１００」が、図１
３Ａに示すように、ハードディスク２６の、その他第２
インデックス記憶部に「２，８，１００」と記憶される
（ステップＳＴ８３）。

【００８４】ＣＰＵ２３は、ファイル番号が最終か否か
判断する（ステップＳＴ８５）。この場合、最終でない
ので、ファイル番号ｑをインクリメントし（ステップＳ
Ｔ８７）、ステップＳＴ８０にて、ファイル１のデータ
を抽出する。この場合ファイル１には、文字位置カウン
タ「３３，１２２」のデータが存在するので、ステップ
ＳＴ８１にてデータがあると判断し、その個数「２」と
文字位置カウンタ「３３，１２２」が、その他第２イン
デックス記憶部に追加記憶される。この状態を、図１３
Ｂに示す。

【００８５】つぎに、ＣＰＵ２３は、図１１ステップＳ
Ｔ８５にて、ファイル番号ｑが最終か否か判断する。こ
の場合、最終であるので、ステップＳＴ８９に進み、当
該トークン「は」、その他第２インデックス上の位置
「０」、およびそのサイズ「３２」が、図１３Ｃに示す
ように、アルファベット第１インデックス記憶部に記憶
される。

【００８６】なお、この場合、サイズが３２となってい
るのは、図１３Ｂに示すように、「０，２，８，１０
０，１，２，３３，１２２」と８つのデータがあり、各
データについて、４バイトで表す為である。

【００８７】つぎに、ＣＰＵ２３は、図１１ステップＳ
Ｔ９１にて、索引バッファに記憶されているデータが最
終かどうか判断する。この場合、最終でないので、ステ
ップＳＴ９３に進み、ファイル番号ｐをインクリメント
し、図１０ステップＳＴ５３、ステップＳＴ５５の処理
を行なう。

【００８８】ここで、図９Ｄに示すトークン「アプリケ
ーション」が、ｐ番目の索引データとしてステップＳＴ
５５にて読み出された場合の処理について説明する。

【００８９】トークン「アプリケーション」の文字種類
はカタカナであるので、ステップＳＴ５７からステップ
ＳＴ６１に進む。ステップＳＴ６１では、トークン「ア
プリケーション」について、ファイル番号ｐ（この場合
ファイル０）のデータがあるかどうか判断する。この場
合、ファイル０については、文字位置カウンタ「１０，
７０」にデータが存在するので、その個数「２」および
文字位置カウンタ「１０，７０」が、ハードディスク２
６のカタカナ第２インデックス記憶部に記憶される（図
１０ステップＳＴ６３）。

【００９０】つぎに、ＣＰＵ２３は、ファイル番号が最
終か否か判断する（ステップＳＴ６５）。この場合、最
終ではないので、ステップＳＴ６７に進み、ｑをインク
リメントし、ステップＳＴ６１に進む。つぎに、ＣＰＵ
２３は、ファイル番号ｑ（この場合ファイル１）のデー
タが存在するので、ステップＳＴ６３に進み、その個数
「１」および文字位置カウンタ「１３９」を、カタカナ
第２インデックス記憶部に記憶する。

【００９１】つぎに、ステップＳＴ６５にて、ファイル
番号が最終か否か判断する。この場合最終であるので、
ステップＳＴ６９に進み、当該トークン「アプリケーシ
ョン」、カタカナ第２インデックス上の位置「０」およ
びそのサイズ「２８」が、ハードディスク２６のカタカ
ナ第１インデックス記憶部に記憶される。図１４Ａにカ
タカナ第２インデックス記憶部の内容を、図１４Ｂにカ
タカナ第１インデックス記憶部の内容を各々示す。

【００９２】つぎに、ＣＰＵ２３は、図１１ステップＳ
Ｔ９１に進み、索引バッファに記憶されているデータが
最終か否か判断する。この場合、最終ではないのでファ
イル番号ｐをインクリメントする（ステップＳＴ９
３）。そして、図１０ステップＳＴ５３以下の処理を繰
り返す。

【００９３】このようにして、カタカナ、アルファベッ
ト、その他の文字種別の索引データが種類を区分して、
それぞれハードディスク２６のカタカナ第１インデック
ス記憶部、カタカナ第２インデックス記憶部、アルファ
ベット第１インデックス記憶部、アルファベット第２イ
ンデックス記憶部、その他第１インデックス記憶部、そ
の他第２インデックス記憶部に記憶される。

【００９４】つぎに、図９Ｄに示すトークン「パフォー
マンス」が、ｐ番目の索引データとして読み出された場
合の処理について説明する。この場合、ＣＰＵ２３は、
文字種類としてはカタカナであるので、ステップＳＴ６
１に進み、ファイル番号ｑ（この場合ファイル０）のデ
ータが有るか否か判断する（ステップＳＴ６１）。この
場合、ファイル０のデータは２つ存在するので、その個
数「２」および文字位置カウンタ「１０２，１５３」
を、カタカナ第２インデックス記憶部に追加記憶する
（ステップＳＴ６３）。この状態のカタカナ第２インデ
ックス記憶部を図１４Ｃに示す。このように、カタカナ
第２インデックス記憶部には、別のトークンのデータが
連続して記憶される。

【００９５】つぎに、ファイル番号が最終か否か判断す
る。この場合、最終ではないので、ステップＳＴ６７に
進み、ファイル番号ｑをインクリメントし、ステップＳ
Ｔ６１に戻りファイル１のデータが存在するか否か判断
する。この場合、ファイル１のデータが１つ存在するの
で、その個数「１」および文字位置カウンタ「９」が、
カタカナ第２インデックス記憶部にさらに追加記憶され
る。この状態のカタカナ第２インデックス記憶部のデー
タ構造を図１４Ｄに示す。

【００９６】つぎに、ＣＰＵ２３は、ファイル番号が最
終か否か判断する（ステップＳＴ６５）。この場合最終
であるので、図１４Ｅに示すように、当該トークン「パ
フォーマンス」、カタカナ第２インデックス記憶部上の
位置「３２」および、そのサイズ「２８」がカタカナ第
１インデックス記憶部に記憶される。ＣＰＵ２３は、索
引バッファが最終か否か判断し、最終でない場合には、
ステップＳＴ９３に進み、図１０ステップＳＴ５３以下
の処理を繰り返す。

【００９７】これに対して、図１１ステップＳＴ９１に
て、索引バッファのデータが最終である場合には、索引
整理処理を終了する。このようにして、図３、４に示す
文書０および文書１が与えられた場合には、図１２、図
１３、図１４に示すそれぞれのデータが、インデックス
情報として生成される。

【００９８】3-2．検索処理のフローチャートについて つぎに、生成したインデックス情報に基づいた検索処理
について説明する。ＣＰＵ２３は、図１５に示す検索フ
ローチャートにて検索処理を行なう。まず、カタカナ第
１インデックス記憶部、アルファベット第１インデック
ス記憶部、その他第１インデックス記憶部に記憶されて
いるデータを、メモリ２７のワークエリアに読み込む
（ステップＳＴ１０１）。

【００９９】つぎに、検索文字列をメモリ２７に読み込
む（ステップＳＴ１０３）。ここでは、索引生成処理
（図５ステップＳＴ３）にて図１６に示すインデックス
情報が作成されており、検索文字列として「パフォーマ
ンス最適化」が与えられたものとして説明する。

【０１００】ＣＰＵ２３は、当該検索文字列を各トーク
ンに分割して、メモリ２７のトークンバッファにトーク
ン毎に記憶する（ステップＳＴ１０５）。この状態を図
１７に示す。このように、検索文字列「パフォーマンス
最適化」は、トークン「パフォーマンス」、トークン
「最」、トークン「適」、トークン「化」に分割されて
記憶される。なお、各トークンに分割する手法として
は、既に説明した索引生成処理における分割手法と同様
であるので説明は省略する。

【０１０１】つぎに、ＣＰＵ２３は、処理対象トークン
番号ｉを初期化し（ステップＳＴ１０７）、ステップＳ
Ｔ１０９にて、トークンバッファ記憶数Ｎが処理対象ト
ークン番号ｉよりも大きいか否か判断する。この場合、
トークンバッファ記憶数Ｎは０、１、２、３の４つであ
り、処理対象トークン番号ｉが０であるので、Ｎ＞ｉと
してステップＳＴ１１１に進む。

【０１０２】ＣＰＵ２３は、ｉ番目（０番目）のトーク
ンを検索キーとし、該当する文字種の第１インデックス
記憶部を検索する（ステップＳＴ１１１）。この場合、
ｉ番目（０番目）のトークンは、文字種がカタカナであ
るので、カタカナ第１インデックス記憶部にトークン
「パフォーマンス」が存在するか否か判断する（ステッ
プＳＴ１１３）。この場合、図１６Ａに示すように、ト
ークン「パフォーマンス」が存在するので、ＣＰＵ２３
は、図１６Ｂに示すカタカナ第２インデックス記憶部か
ら必要なデータを読み出して、メモリ２７のワークエリ
アに記憶する（ステップＳＴ１１５）。この場合のワー
クエリアのデータ構造を図１８Ａに示す。図に示す様
に、アドレス０には「〈０，１０２，１５３〉〈１，
９〉」と記憶されている。なお、この場合、カタカナ第
２インデックス記憶部のデータのうち、ファイル番号の
後の個数は省略されて記憶される。すなわち、ファイル
０の文字位置カウンタ「１０２，１５３」および、ファ
イル１の文字位置カウンタ「１，９」に当該トークンが
存在することを示している。

【０１０３】つぎに、ＣＰＵ２３は、処理対象トークン
番号ｉをインクリメントし（図１５ステップＳＴ１１
７）、ステップＳＴ１０９に戻る。ここでは、トークン
バッファ記憶数Ｎが処理対象トークン番号ｉよりも大き
いので（Ｎ＝４、ｉ＝１）、１番目のトークン「最」を
キーとして、該当する文字種類の第１インデックスを検
索する（ステップＳＴ１１１）。この場合、１番目のト
ークンの文字種類は漢字であるので、その他第１インデ
ックス記憶部に当該トークン「最」が存在するか否か判
断する（ステップＳＴ１１３）。

【０１０４】ここで、トークン「最」が、図１６Ｃに示
すその他第１インデックス記憶部に存在するので、図１
６Ｄに示すその他第２インデックス記憶部からデータを
読み出して（先頭位置１０２４バイト目から２４バイト
分）、前記ワークエリアに記憶する（ステップＳＴ１１
５）。この場合のワークエリアのデータ構造を図１８Ｂ
に示す。図に示す様に、アドレス１に「〈０，１６０〉
〈１，１６〉」と記憶されている。

【０１０５】つぎに、ＣＰＵ２３は、処理対象トークン
番号ｉをインクリメントし、ステップＳＴ１０９に戻
る。ここでは、トークンバッファ記憶数Ｎが処理対象ト
ークン番号ｉよりも大きいので、２番目のトークンをキ
ーとして該当する文字種類の第１インデックスを検索す
る（ステップＳＴ１１１）。この場合、２番目のトーク
ンは「適」であるので、その他第１インデックス記憶部
に当該トークン「適」が存在するか否か判断する（ステ
ップＳＴ１１３）。この場合、トークン「適」が存在す
るのでステップＳＴ１１５に進み、図１６Ｄに示すその
他第２インデックス記憶部からデータを読み出し（先頭
位置１０４８バイト目から２４バイト分）、前記ワーク
エリアに記憶する（ステップＳＴ１１５）。この場合の
ワークエリアのデータ構造を図１８Ｃに示す。図に示す
様に、アドレス２に「〈０，１６２〉〈１，１８〉」と
記憶されている。

【０１０６】つぎに、ＣＰＵ２３は、処理対象トークン
番号ｉをインクリメントし、ステップＳＴ１０９に戻
る。ここで、処理対象トークン番号ｉ＝３であるので、
ステップＳＴ１１１に進み、３番目のトークンをキーと
して該当する文字種の第１インデックスが検索される。
この場合、３番目のトークンは「化」であるので、図１
６Ｃに示すその他第１インデックス記憶部に、当該トー
クン「化」が存在するか否か判断する（ステップＳＴ１
１３）。この場合存在するので、図１６Ｄに示すその他
第２インデックス記憶部からデータを読み出して（先頭
位置１０７２バイト目から２８バイト分）、前記ワーク
エリアに記憶する。この場合のワークエリアのデータ構
造を図１８Ｃに示す。図に示す様に、アドレス３に
「〈０，１６４，１７５〉〈１，２０〉」と記憶されて
いる。

【０１０７】つぎに、ＣＰＵ２３は、処理対象トークン
番号ｉをインクリメントし（ステップＳＴ１１７）、ス
テップＳＴ１０９に戻る。ここで、処理対象トークン番
号ｉ＝４であるので、ステップＳＴ１０９ではＮ＞ｉで
ないと判断し、ステップＳＴ１２１に進む。ステップＳ
Ｔ１２１では個数Ｎが１か否か判断する。この場合、個
数Ｎは１ではないので、ステップＳＴ１２３に進み、各
トークンが連続しており与えられた検索文字列を構成す
るデータ以外のデータを、前記ワークエリアから削除す
る。この削除について図１７、図１８Ｄを用いて説明す
る。

【０１０８】まず、ＣＰＵ２３は、図１８Ｄに示す各ア
ドレスのデータについて、存在するファイル番号を調べ
て、全てのアドレスに共通するデータのみ取り出す。他
は排除する。例えば、アドレス０には、ファイルｎ，ｎ
＋１に当該トークンが存在し、アドレス１には、ファイ
ルｎ，ｎ＋１、ｎ＋２に当該トークンが存在し、アドレ
ス３には、ファイルｎ，ｎ＋１、ｎ＋３に当該トークン
が存在し、アドレス４には、ファイルｎ，ｎ＋１、ｎ＋
２、ｎ＋３に当該トークンが存在する場合、全てのアド
レスに共通するファイルは、ファイルｎ，ｎ＋１であ
る。したがって、各アドレスのうち、これ以外のファイ
ル（ファイルｎ＋２、ｎ＋３）のデータについては排除
する。

【０１０９】このような排除処理を行うことにより、後
述する減算処理をする対象を減らすことができ、より高
速処理が可能である。

【０１１０】この場合は、アドレス０からアドレス３に
ついて、ファイル０、ファイル１が、この共通のファイ
ルとなるので（ファイル０、１については全てのアドレ
スに共通に存在する）、かかる排除処理は行わない。

【０１１１】つぎに、連続する位置に存在するデータか
否か判断するために、図１７に示す各トークンの文字数
を文字列カウンタ位置から減算する。例えば、前記ワー
クエリアのアドレス０については、文字位置カウンタに
は、ファイル０に「１０２，１５３」、ファイル１に
「１，９」が存在する。ここで、０番目のトークン「パ
フォーマンス」の開始位置が０であるので、「１０２，
１５３，１，９」からそれぞれ０を引く。これにより
「１０２，１５３，１，９」が得られる。

【０１１２】つぎに、図１８Ｄに示す前記ワークエリア
のアドレス１についても同様の処理を行なう。この場
合、ファイル０には、文字位置カウンタ「１，１６０」
が存在し、ファイル１には、「１，１６」が存在する。
このトークン「最」は、検索文字列の先頭開始位置を０
バイト目とすると、７バイト目となる。したがって、そ
れぞれの文字位置カウンタから「７」を引く。これによ
り「−６、１５３、−６、９」が得られる。

【０１１３】同様に、図１７に示すアドレス２のトーク
ン「適」についても先頭から９バイト目にあるので、各
々の文字位置カウンタ数から９を減算する。同様に、図
１８Ｄに示す前記ワークエリアのアドレス３についても
処理を行なう。

【０１１４】ＣＰＵ２３は、前記ワークエリアのうちそ
の前に存在する文字のバイト数だけ減算した値が等しく
なるものについては連続して存在することになるので、
それ以外のデータを削除する。これにより、図１９に示
すように、アドレス０には、「〈０，１５３〉〈１，
９〉」、アドレス１には、「〈０，１６０〉〈１，１
６〉」、アドレス２には、「〈０，１６２〉〈１，１
８〉」、アドレス３には、「〈０，１６４〉〈１，２
０〉」が得られる。このようにして、図１５ステップＳ
Ｔ１２３の処理が終了する。

【０１１５】ＣＰＵ２３は、削除後の前記ワークエリア
に、データが存在するか否か判断し（ステップＳＴ１２
５）、存在しない場合には、ステップＳＴ１２７に進
み、メッセージ「検索文字列は存在しません」をＣＲＴ
３０に表示する（図２参照）。なお、ステップＳＴ１１
３にて、該当する文字種の第１インデックスにデータが
存在しない場合も、ステップＳＴ１２７に進み、同様に
表示して、検索処理は終了する。

【０１１６】なお、ステップＳＴ１２１にてＮ＝１の場
合は、連続するか否かの判断が不要となるので、ステッ
プＳＴ１２３、ステップＳＴ１２５の処理は行わない。

【０１１７】一方、ステップＳＴ１２５にてデータが存
在する場合には、検索結果を表示する（ステップＳＴ１
２９）。検索結果の表示については、ステップＳＴ１２
３の処理終了後のワークエリアに記憶されているデータ
のファイル名をＣＲＴ３０に表示し、その表示するファ
イルが特定された場合は、図２０Ａに示すように、検索
文字列「パフォーマンス最適化」の部分が、他の部分よ
りも目立つように表示される。

【０１１８】図２０Ａは、ファイル０についての検索文
字列「パフォーマンス最適化」が表示された例であり、
図２０Ｂは、ファイル１について検索文字列「パフォー
マンス最適化」が表示された例である。このように、本
実施例では、検索結果の表示としてファイル名を表示し
た後、内容を表示するコマンドが与えられると、当該フ
ァイルのうち検索文字列が存在する部分を他の部分より
も目立つようにして表示するようにしている。

【０１１９】なお、このようにファイル名表示させる際
に、そのファイルにキーワードが付されている場合に
は、ファイル名とともに、そのキーワードの内容を表示
するようにしてもよい。これによって、そのファイルの
内容について判断が容易となり、不要なファイルを開く
必要がなくなる。

【０１２０】また、ファイル名を表示することなく、フ
ァイル毎に検索文字列が存在する部分が判るようにその
前後とともに、ＣＲＴ３０上に表示するようにしてもよ
い。

【０１２１】このように、本実施例においては、各トー
クンについて、インデックス情報として、ファイル名と
その文字位置カウンタというペア情報を整理して、各フ
ァイル別に個数および文字位置カウンタ値というように
して記憶している。したがって、同じファイルに同じト
ークンが多数ある場合に、必要な記憶容量を小さくする
ことができる。

【０１２２】さらに、カタカナおよびアルファベットに
ついては、連続する部分を１トークンとして記憶するよ
うにしている。したがって、記憶容量を削減できると共
に、その検索速度も向上する。

【０１２３】なお、上記実施例においては、検索文字列
がトークンとして記憶されている文字列を含む場合を例
として説明した。すなわち、４つのトークン「パフォー
マンス」、「最」、「適」および「化」から構成された
検索文字列「パフォーマンス最適化」が与えられた場合
である。

【０１２４】しかしこれに限定されず、１トークンの一
部の文字列を検索文字列として、前方一致または後方一
致で検索することもできる。例えば、トークン「データ
ビット」、トークン「データベース」、トークン「デジ
タル」がカタカナ第１インデックス記憶部に記憶されお
り、前方一致検索の対象文字列として「データ」が与え
られた場合、以下のようにして、高速検索が可能とな
る。

【０１２５】まず、カタカナ第１インデックス記憶部に
記憶されているトークンについて、先頭のトークンのう
ち、図２１に示すような先頭文字「デ」で始まるトライ
構造データを作成する。そして、検索文字列「データ」
を検索するのである。すなわち、図２１に示すトライ構
造データでは、検索文字列「データ」を含むトークン
は、トークン「データビット」、「データベース」であ
り、トークン「デジタル」、「デバイスドライバ」は検
索文字列を含まないことがわかる。

【０１２６】また、後方一致検索する場合は、各トーク
ンについて、後方から同様のトライ構造データを作成す
ればよい。例えば、トークン「ユーザインタフェイ
ス」、「マンマシンインタフェイス」、および「パフォ
ーマンス」が存在する場合に、検索文字列「インタフェ
イス」で後方一致検索する場合は、図２２に示すような
トライ構造データを作成すればよい。

【０１２７】このように、一般に、カタカナおよびアル
ファベットについては、トークンとして記憶されている
文字列の一部が検索文字列として与えられるとして、前
方一致または後方一致で検索する場合が殆どであり、中
間一致で検索すること（例えば、上記例で、検索文字列
「インタ」で中間一致検索する場合をいう）は殆ど考え
られない。したがって、このような中間一致検索をする
ことが殆どないような文字種については、上記実施例の
様に、連続する部分を１トークンとして記憶するように
しても、検索処理が問題となることはない。

【０１２８】なお、漢字の場合は、中間一致で検索する
ことも考えられる。例えば、「転送処理速度向上に伴う
・・・・一方、書込処理速度低下・・・」という文書が
ある場合に、もし、漢字についても、連続する部分を１
トークンとして記憶すると、トークン「転送処理速度向
上」、「書込処理速度低下」が記憶される。この場合、
検索文字列として「処理速度」が与えられることも考え
られる。このような中間一致検索については、第１イン
デックス記憶部に当該検索文字列を含むトークンが存在
するか否かを１つ１つ判断する必要がある。したがっ
て、検索速度が低下するおそれがある。したがって、本
実施例においては、漢字については、カタカナおよびア
ルファベットとは異なり、１文字を１トークンとして記
憶するようにした。

【０１２９】なお、このような中間一致での高速検索処
理が問題とならないのであれば、漢字もカタカナおよび
アルファベットと同様に連続する部分を１トークンとし
て記憶するようにしてもよい。これにより、記憶容量を
削減することができる。

【０１３０】４．その他なお、本実施例においては、前
記各機能を実現する為に、ＣＰＵ２３を用い、ソフトウ
ェアによってこれを実現している。しかし、その一部も
しくは全てを、ロジック回路等のハードウェアによって
実現してもよい。

【０１３１】また、上記実施例においては、プログラム
をフレキシブルディスクに記憶させて、これをハードデ
ィスク２６にインストールするようにしたが、他の記憶
媒体、例えば、ＲＯＭ、ＩＣカード、光ディスク、ＣＤ
−ＲＯＭ等からインストールしてもよく、さらにこれら
記憶媒体から直接プログラムを読み出して実行するよう
にしてもよい。

【０１３２】また、本実施例においては、日本語文書の
全文検索システムに適用した場合について説明したが、
これに限定されず、第１種類の文字および第２種類の文
字が混在し、かつ文字列の切れ目が明瞭でない言語につ
いても同様にして適用することができる。

【０１３３】

【発明の効果】請求項１、請求項２、請求項７の索引デ
ータ生成装置または索引データ生成方法においては、第
１種類の文字および第２種類の文字が混在する混在デー
タが与えられると、第１種類の文字については、一文字
で一ブロックとし、第２種類の文字については、同じ種
類の文字が連続した部分を一ブロックとして決定すると
ともに、各ブロックごとに、前記混在データにおける位
置を表す位置情報が付加された索引データを生成する。
したがって、第２種類の文字については、複数文字から
構成された１ブロックの索引データを得ることができ
る。このように、第２種類の文字だけでも、１ブロック
の索引データで索引情報を構成することにより、記憶容
量の節約および検索速度を向上させることができる索引
データ生成装置、索引データ生成方法を提供することが
できる。

【０１３４】請求項３の索引データ生成装置において
は、前記索引データは、各ブロックを構成する文字で構
成された第１インデックスを有している。したがって、
検索の際に、この第１インデックスを検索するだけで、
当該文字列が存在するか否かを判断することができる。
さらに、前記第２インデックスは、各ファイルに存在す
る個数および存在する位置を有する。このように第２イ
ンデックスは、ファイルと存在する位置というペア情報
ではないので、同一ファイル中に、前記第１インデック
スが複数存在する場合であっても、記憶容量がそれほど
増えることがない。

【０１３５】したがって、より記憶容量を少なくし、検
索速度をより向上させることができる索引データ生成装
置を提供することができる。

【０１３６】請求項４、請求項８の検索装置または検索
方法においては、第１種類の文字および第２種類の文字
が混在する混在データ中の第１種類の文字については一
文字で一ブロックとし、第２種類の文字については、同
じ種類の文字が連続した部分を一ブロックとして、前記
各ブロックごとに、前記混在データにおける位置を表す
位置情報が付加された索引データを記憶しておき、前記
第２種類の文字について記憶されている索引データが、
検索文字列として与えられると、前記索引データを参照
して前記位置情報を得て、前記混在データから前記検索
文字列を検索する。したがって、記憶容量を少なくし、
検索速度をより向上させることができる検索装置、検索
方法を提供することができる。

【０１３７】請求項５の検索装置においては、前記第１
種類の文字および前記第２種類の文字が混在する混在検
索文字列が与えられると、前記第１種類の文字について
は、一文字で一検索ブロックとし、前記第２種類の文字
については、同じ種類の文字が連続した部分を一検索ブ
ロックとして決定する。決定した一検索ブロックに基づ
いて、前記混在検索文字列が存在するか検索する。そし
て、前記各検索ブロックが、前記混在データに前記混在
検索文字列の順序で存在するか否か判断する。したがっ
て、より記憶容量を少なくし、検索速度をより向上させ
ることができる検索装置、検索方法を提供することがで
きる。

【０１３８】請求項６、請求項９の日本語文書管理装置
または日本語文書管理方法においては、ひらがな、漢
字、およびカタカナが混在する文書について、注目する
文字がひらがな又は漢字である場合には、一文字ごとに
前記文書における位置を表す位置情報が付加された索引
データを生成し、注目する文字がカタカナである場合に
は、カタカナが連続する部分が１のブロックであると判
断して、このブロックの前記文書における位置を表す位
置情報が付加された索引データを生成して、記憶する。
したがって、記憶容量を低減することができ、高速検索
可能な日本語文書管理装置または管理方法を提供するこ
とができる。

【図面の簡単な説明】

【図１】本発明にかかる索引データ生成検索装置１の機
能ブロック図である。

【図２】図１に示す索引データ生成検索装置１をＣＰＵ
で実現したハードウェア構成を示す図である。

【図３】索引生成の対象となる文書０を示す図である。

【図４】索引生成の対象となる文書１を示す図である。

【図５】索引生成の全体処理フローチャートである。

【図６】索引生成における作成処理のフローチャートで
ある。

【図７】索引生成における作成処理のフローチャートで
ある。

【図８】状態遷移を説明する為の図である。

【図９】索引バッファのデータ構造を示す図である。

【図１０】索引生成における整理処理のフローチャート
である。

【図１１】索引生成における整理処理のフローチャート
である。

【図１２】アルファベット第１インデックス記憶部およ
びアルファベット第２インデックス記憶部のデータ構造
を示す図である。

【図１３】その他第１インデックス記憶部およびその他
第２インデックス記憶部のデータ構造を示す図である。

【図１４】カタカナ第１インデックス記憶部およびカタ
カナ第２インデックス記憶部のデータ構造を示す図であ
る。

【図１５】検索処理のフローチャートである。

【図１６】索引生成処理にて作成されたカタカナ第１イ
ンデックス記憶部、カタカナ第２インデックス記憶部、
その他第１インデックス記憶部およびその他第２インデ
ックス記憶部のデータ構造を示す図である。

【図１７】検索文字列を分割して記憶したワークエリア
のデータ構造を示す図である。

【図１８】検索文字列のトークンが存在する場合のワー
クエリアのデータ構造を示す図である。

【図１９】不要な索引データ削除後のワークエリアのデ
ータ構造を示す図である。

【図２０】検索文字列の部分を他の部分よりも目立つよ
うに表示した状態を示す図である。

【図２１】前方検索のための作成するトライ構造のデー
タ例を示す図である。

【図２２】後方検索のための作成するトライ構造のデー
タ例を示す図である。

【符号の説明】

３・・・・混在データ記憶手段 ５・・・・索引データ決定手段 ７・・・・索引データ記憶手段 ９・・・・検索手段

───────────────────────────────────────────────────── フロントページの続き (72)発明者 高橋 誠 大阪府吹田市江の木町11番30号 株式会社 東洋情報システム内

Claims (11)

【特許請求の範囲】
1. 【請求項１】第１種類の文字および第２種類の文字が混
   在する混在データが与えられると、第１種類の文字につ
   いては一文字を一ブロックとして決定し各ブロックごと
   に、前記混在データにおける位置を表す位置情報が付加
   された第１文字種索引データを出力するとともに、第２
   種類の文字については、同じ種類の文字が連続した部分
   を一ブロックとして決定し各ブロックごとに、前記混在
   データにおける位置を表す位置情報が付加された第２文
   字種索引データを文字種別索引データとして出力する索
   引データ決定手段、 前記文字種別索引データを記憶する索引データ記憶手
   段、 を備えたことを特徴とする索引データ生成装置。
2. 【請求項２】請求項１の索引データ生成装置において、 前記混在データは、さらに第３種類の文字を含み、 前記索引データ決定手段は、この第３種類の文字につい
   ても、同じ種類の文字が連続した部分を一ブロックとし
   て決定し各ブロックごとに、前記混在データにおける位
   置を表す位置情報が付加された第３文字種索引データを
   含む文字種別索引データを出力し、 前記索引データ記憶手段は、この第３文字種索引データ
   を含む文字種別索引データを記憶すること、 を特徴とする索引データ生成装置。
3. 【請求項３】請求項１または請求項２の索引データ生成
   装置において、 前記混在データは、複数のファイルから構成されてお
   り、 前記文字種別索引データは、各々以下の1)第１インデッ
   クスおよび2)第２インデックスを有すること、 1)各ブロックを構成する文字で構成された第１インデッ
   クス、 2)前記第１インデックスに関連づけられた第２インデッ
   クスであって、前記第１インデックスを有するファイル
   名、前記第１インデックスが当該ファイルに存在する個
   数、および前記第１インデックスが当該ファイルに存在
   する位置を有する第２インデックス、 を特徴とする索引データ生成装置。
4. 【請求項４】第１種類の文字および第２種類の文字が混
   在する混在データを記憶する混在データ記憶手段、 前記第１種類の文字については、一文字で一ブロックと
   し、前記第２種類の文字については、同じ種類の文字が
   連続した部分を一ブロックとして、各ブロックごとに、
   前記混在データにおける位置を表す位置情報が付加され
   た文字種別索引データを記憶する索引データ記憶手段、 前記第２種類の文字で構成された文字列が、検索文字列
   として与えられると、前記索引データ記憶手段に記憶さ
   れた文字種別索引データを参照して、前記位置情報を得
   て、前記混在データから前記検索文字列を検索する検索
   手段、 を備えたことを特徴とする検索装置。
5. 【請求項５】請求項４の検索装置において、 前記検索手段は、 1)前記第１種類の文字および前記第２種類の文字が混在
   する混在検索文字列が与えられると、前記第１種類の文
   字については、一文字で一検索ブロックとし、前記第２
   種類の文字については、同じ種類の文字が連続した部分
   を一検索ブロックとして決定する検索ブロック決定手
   段、 2)前記検索ブロック決定手段が決定した一検索ブロック
   に基づいて、前記混在検索文字列が存在するか検索する
   混在検索文字列検索手段、 3)前記各検索ブロックが、前記混在データ記憶手段に前
   記混在検索文字列の順序で存在するか否か判断する判断
   手段、 を有していることを特徴とする検索装置。
6. 【請求項６】ひらがな、漢字、およびカタカナが混在す
   る文書を記憶する文書記憶手段、 前記文書記憶手段に記憶された文書についての索引デー
   タを生成する索引データ生成手段であって、注目する文
   字がひらがな又は漢字である場合には、一文字ごとに前
   記文書における位置を表す位置情報が付加された索引デ
   ータを生成し、注目する文字がカタカナである場合に
   は、カタカナが連続する部分が１のブロックであると判
   断して、このブロックの前記文書における位置を表す位
   置情報が付加された索引データを生成する索引生成手
   段、 前記索引データを文字種別に記憶する文字種別索引デー
   タ記憶手段、 カタカナで構成された検索文字列が与えられた場合に
   は、前記文字種別索引データ記憶手段に記憶された文字
   種別索引データを参照して、前記検索文字列の位置情報
   を得て、前記文書から前記検索文字列を検索する検索手
   段、 を備えたことを特徴とする日本語文書管理装置。
7. 【請求項７】第１種類の文字および第２種類の文字が混
   在する混在データが与えられると、第１種類の文字につ
   いては、一文字で一ブロックとし、第２種類の文字につ
   いては、同じ種類の文字が連続した部分を一ブロックと
   して決定するとともに、各ブロックごとに、前記混在デ
   ータにおける位置を表す位置情報が付加された文字種別
   索引データを生成すること、 を特徴とする索引データ生成方法。
8. 【請求項８】第１種類の文字および第２種類の文字が混
   在する混在データ中の第１種類の文字については一文字
   で一ブロックとし、第２種類の文字については、同じ種
   類の文字が連続した部分を一ブロックとして、前記各ブ
   ロックごとに、前記混在データにおける位置を表す位置
   情報が付加された索引データを記憶しておき、 前記第２種類の文字で構成された文字列が、検索文字列
   として与えられると、前記索引データを参照して前記位
   置情報を得て、 前記混在データから前記検索文字列を検索すること、 を特徴とする検索方法。
9. 【請求項９】ひらがな、漢字、およびカタカナが混在す
   る文書を記憶しておき、 前記文書について、注目する文字がひらがな又は漢字で
   ある場合には、一文字ごとに前記文書における位置を表
   す位置情報が付加された索引データを生成し、注目する
   文字がカタカナである場合には、カタカナが連続する部
   分が１のブロックであると判断して、このブロックの前
   記文書における位置を表す位置情報が付加された索引デ
   ータを生成して、記憶しておき、 カタカナで構成された検索文字列が与えられた場合に
   は、前記索引データを参照して当該検索文字列の位置情
   報を得て、前記文書から前記検索文字列を検索するこ
   と、 を特徴とする日本語文書管理方法。
10. 【請求項１０】第１種類の文字および第２種類の文字が
    混在する混在データが与えられると、第１種類の文字に
    ついては、一文字で一ブロックとし、第２種類の文字に
    ついては、同じ種類の文字が連続した部分を一ブロック
    として決定するとともに、各ブロックごとに、前記混在
    データにおける位置を表す位置情報が付加された索引デ
    ータを生成させるようにコンピュータを稼働させるプロ
    グラムを記憶した記憶媒体。
11. 【請求項１１】第２文字種で構成された検索文字列が与
    えられると、この検索文字列が、同じ種類の文字が連続
    した部分を一ブロックとした索引データとして記憶され
    ているか否かを判断し、前記索引データとして記憶され
    ている場合には、この索引データに基づいて、前記第１
    種類の文字および前記第２種類の文字が混在する混在デ
    ータから前記検索文字列を検索するようにコンピュータ
    を稼働させるプログラムを記憶した記憶媒体。