JPH0830633A - テキストデータ検索装置 - Google Patents

Abstract

(57)【要約】 【目的】 対象となるデータベース毎に最適な状態に維
持されたハッシュテーブル、および、文字成分表を使用
して、テキストデータの検索処理を高速に行えるテキス
トデータ検索装置を提供すること。 【構成】 文字成分表と、ハッシュテーブルと、テキス
トデータからなるデータベース本体をサーチする前に、
前記ハッシュテーブル、および、文字成分表を使用する
文字成分表サーチを含む補助サーチ行う第１の手段と、
前記第１の手段により絞り込まれた文書に対してテキス
トサーチを行う第２の手段とを具備する階層プリサーチ
方式のテキストデータ検索装置において、各データベー
ス毎の文字成分表、および、ハッシュテーブルと、文書
を登録あるいは削除した場合にハッシュテーブルの最適
化状態を判断し、新たに文字成分表、および、ハッシュ
テーブルを再作成する手段とを具備する。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、フルテキストサーチ方
式のテキストデータ検索装置に係わり、特に、その検索
処理を高速化したテキストデータ検索装置に関する。

【０００２】

【従来の技術】従来、インデックス情報を用いない文書
検索システムとして、例えば、特開平４−２７４５５７
号公報（テキストデータベース検索方法及び装置）に記
載されているように、検索文字列の探索処理を高速化す
るために、テキスト本体をサーチする以前にテキストデ
ータを予め情報圧縮しておいた補助ファイルをサーチ
し、テキスト本体をサーチする文書件数を絞り込むこと
によって等価的に高速なフルテキストサーチを実現する
文書検索方式（階層プリサーチ方式）が公知である。

【０００３】前記公報（特開平４−２７４５５７号）で
は、補助ファイルとして、テキストデータ内で使用可能
な全ての文字に対して１ビットの情報を割り付けたビッ
トリストである文字成分表と、テキストデータを単語レ
ベルで部分文字列に分割し、分割した部分文字列間で相
互に文字列の包含関係を調べ、他の部分文字列に含まれ
る文字列を排除した部分文字列の集合からなる凝縮テキ
ストを使用している。

【０００４】図１７は、前記公報（特開平４−２７４５
５７号）に記載されている階層プリサーチによる検索手
順を説明するための図である。

【０００５】図１７において、２０１は文字成分表であ
り、例えば、文書１には、「あ」、「い」、「音」、
「声」、「認」、「識」という文字が含まれているため
それぞれの文字に対応するビットがオンになっている。

【０００６】２０２は凝縮テキストであり、例えば、テ
キスト２０３の文書４では、「音声」、「対」、「音
声」、「応答」という単語を含んでいるが、この中で、
「音声」という単語は２度出現しており、凝縮テキスト
ではこの重複を排除して「音声」という単語は１つだけ
含まれるようにしている。

【０００７】２０３はテキストであり、テキスト２０３
はテキストデータを変更を加えずに格納したものであ
る。

【０００８】２００は階層プリサーチによる検索手順を
表しており、まず、文字成分表サーチで文字単位の絞り
込みを行い、次に、文字成分表サーチで絞り込まれた文
書に対し凝縮テキストサーチで単語単位の絞り込みを行
い、最後にテキストをサーチするという方式である。

【０００９】このように、最も検索に時間がかかるテキ
スト本体を探索する量を、文字成分表、および、凝縮テ
キストのサーチで減らすことにより、高速なフルテキス
トサーチを実現している。

【００１０】前記階層プリサーチ方式では、テキストデ
ータをサーチする量をできる限り少なくすることによ
り、より高速な検索を行うことができる。

【００１１】即ち、文字成分表、凝縮テキストといった
補助ファイルサーチ時の文書のヒット率を小さくする、
別の言い方をすれば、絞り込み率を小さくすることによ
り、より高速な検索を行うことができる。

【００１２】このような考え方にしたがい、前記公報
（特開平４−２７４５５７号公報）に記載されている文
字成分表について、テキトスデータに含まれる２文字以
上の文字列に対し、１ビットの情報を割り付けた連接文
字成分表により絞り込み率を向上させることが、例え
ば、特開平５−１７４０６４号公報（テキストデータベ
ース検索方法及び装置）に記載されている。

【００１３】図１８は、前記公報（特開平５−１７４０
６４号）に記載されている連接文字成分表の構造を説明
するための図である。

【００１４】図１８に示すように、前記公報（特開平５
−１７４０６４号）に記載されている連接文字成分表で
は、テキスト中の２文字以上の部分文字列を１エントリ
とする。

【００１５】検索時には、検索文字列を２文字以上の部
分文字列に分割し、文字成分表の該当ビットリストの論
理積をとることにより候補文書を抽出する。

【００１６】例えば、「オンライン」という検索文字列
ならば、「オン」、「ンラ」、「ライ」、「イン」とい
う部分文字列に分割し、そのそれぞれで文字成分表の該
当ビットリストの論理積をとる。

【００１７】このように２文字以上の部分文字列を使う
ことにより、１文字の場合よりもテキスト中での出現頻
度を抑えることができ、その結果、頻繁に使用される文
字でも十分な絞り込みが可能となる。

【００１８】しかし、このような２文字以上の部分文字
列で文字成分表を作成すると文字成分表のサイズが大き
くなりすぎるという問題がある。

【００１９】例えば、２文字の部分文字列による文字成
分表では、６，８７９文字種×６，８７９文字種＝４
７，３２０，６４１種のエントリを用意する必要があ
る。これは、メモリを大量に消費してしまい好ましいこ
とではない。

【００２０】そこで、前記公報（特開平５−１７４０６
４号）では、図１９に示すように、複数の文字成分表エ
ントリを一つのエントリにハッシングすることにより大
量のメモリを消費する文字成分表の縮小化も提案してい
る。

【００２１】前記方法では、図１９に示すハッシュテー
ブル４００を用いる。

【００２２】ハッシュテーブル４００には、どの部分文
字列が文字成分表のどのエントリにハッシングされてい
るかという情報が格納されている。

【００２３】例えば、図１９の例では、「関係」、「経
済」という部分文字列は同じ文字成分表エントリにハッ
シュされている。

【００２４】検索時には、まず、このハッシュテーブル
４００から、各検索文字列の部分文字列が文字成分表の
どのエントリに対応しているかという情報を得て、文字
成分表を引くことになる。

【００２５】しかし、このハッシュテーブル４００を用
いた連接文字成分表では、テキストデータに含まれてい
る部分文字列の使用頻度の違いにより、文字成分表の各
エントリに対応する文書数が多くなってしまうという問
題がある。

【００２６】即ち、使用頻度の高い部分文字列どうしを
同じ文字成分表エントリにハッシングしてしまうと、そ
の文字成分表エントリに対応する文書の数が多くなって
しまい、その結果として、その部分文字列による文字成
分表サーチでは十分に絞り込むことができず、検索性能
が低下してしまうという問題点があった。

【００２７】前記問題点に対して、前記公報（特開平５
−１７４０６４号）では、テキストデータに含まれてい
る部分文字列の使用頻度から、使用頻度の少ない文字ど
うしを同じエントリにハッシングする文字使用頻度情報
ハッシング方式を提案している。

【００２８】図２０は、前記文字使用頻度情報ハッシン
グ方式を説明するための図である。

【００２９】図２０に示すように、前記文字使用頻度情
報ハッシング方式の文字成分表を作成するには、まず、
第１のステップとして、テキストデータに含まれている
部分文字列の使用頻度のカウントを行う。

【００３０】図２０におけるグラフ５５０は、テキスト
データに含まれている２文字の部分文字列の使用頻度を
表したもので、縦軸がその部分文字列を含んでいる文書
の数で、横軸が２文字からなる部分文字列の種類であ
る。

【００３１】グラフ５５０に示したように、一般的にテ
キストデータからなるデータベースに含まれている文字
列の使用頻度は、各部分文字列によって異なる値とな
る。

【００３２】次に、第２のステップとして、この部分文
字列を使用頻度の多い順にソートする。

【００３３】図２０におけるグラフ５５１は、前記ソー
トした結果を表すグラフである。

【００３４】また、図２０におけるグラフ５５２は、横
軸、即ち、部分文字列の種類がＸで示された数になるよ
うに、ハッシングを行ったもので、Ｘが文字成分表のエ
ントリ数となる。

【００３５】使用頻度が基準値に満たなかった文字列
は、他の使用頻度が基準値に満たなかった文字列と同じ
エントリにハッシングされ、そのエントリでの使用頻度
の合計が基準値と等しくなるように平均化される。

【００３６】例えば、「電流」と「電圧」という文字列
は使用頻度が基準値よりも小さいため、一つのエントリ
にハッシングされ、このどちらの文字列で検索を行って
も、文字成分表でのヒット件数は基準値と等しくなる。

【００３７】即ち、基準値より使用頻度が小さかった文
字列については、どの文字列で検索を行っても文字成分
表でのヒット率は同じになる。

【００３８】また、「電気」という文字列のように、使
用頻度が基準値より大きい文字列は、他の文字列と重複
したハッシングは行わず、単独で一つのエントリとす
る。

【００３９】このように、従来では、頻度情報ハッシン
グ方式により、テキストデータに含まれている部分文字
列の使用頻度の違いによる文字成分表の絞り込み率悪化
を改善していた。

【００４０】

【発明が解決しようとする課題】前記公報（特開平５−
１７４０６４号）に記載されている文字使用頻度ハッシ
ングによる文字成分表においては、検索文字列として、
どの文字が使用されていても、平均的に最低の文字成分
表での絞り込み率を得るためには、ハッシュテーブル
が、検索対象となっているデータベース毎のテキストデ
ータの文字使用頻度を正確に反映したハッシングにより
作成されている必要がある。

【００４１】そのため、複数のデータベースを管理する
テキストデータ検索装置においては、データベースが異
なれば部分文字列の使用頻度も異なるため、あるデータ
ベースにおいては、検索性能が低下するという問題点が
あった。

【００４２】また、テキストデータの文字使用頻度は、
文書の登録、削除を繰り返すと変化してしまう。

【００４３】テキストデータから文字列使用頻度を取得
し、ハッシュテーブルを作成した直後では、図２１にお
けるグラフ６５０のように、文字成分表の各エントリに
入っている文書の数は平均化されている。

【００４４】しかしながら、例えば、「電流」という部
分文字列を含む文書が多数追加登録された場合、図２１
におけるグラフ６５１のように文字成分表のエントリに
入っている文書の数が平均値からずれてしまう。

【００４５】したがって、「電流」という部分文字列の
検索を行った場合、文字成分表での文書のヒット文書件
数は平均化された数より多くなり、検索性能は低下す
る。

【００４６】このような状態になった場合は、ハッシュ
テーブルをテキストデータの文字使用頻度と正確に一致
させるため、文字使用頻度を再度取得して、ハッシュテ
ーブルと文字成分表を再作成する必要がある。

【００４７】しかし、データベースの容量が大きくなる
と、この処理には長時間かかってしまうため、頻繁に行
うには現実的ではなく、かつ、いつこの再作成を行えば
良いかというタイミングをユーザが知ることは容易では
ないという問題点があった。

【００４８】また、文字使用頻度ハッシュ方式では、ハ
ッシュテーブルを作成することにより文字成分表の大き
さを圧縮すると共に、どの文字を含む検索文字列で検索
を行っても平均的に最低な文字成分表での絞り込み率を
維持することが可能となる。

【００４９】しかし、使用頻度が少ない部分文字列は、
複数個で一つの文字成分表エントリにハッシングされて
しまうため、もし、これらの使用頻度が少ない文字を他
の文字と重複したハッシングをせず、独立した文字成分
表でのエントリを持たせたならば文字成分表でのヒット
文書件数はもっと小さくできたにもかかわらず、平均値
と等しいヒット文書件数となってしまう。

【００５０】そのため、ユーザが、特定の部分文字列に
対する検索性能を高く維持したいような場合であって
も、特定の部分文字列に対するヒット文書件数が、平均
値と等しいヒット文書件数となってしまうという問題点
があった。

【００５１】本発明は、前記従来技術の問題点を解決す
るためになされたものであり、本発明の目的は、テキス
トデータ検索装置において、対象となるデータベース毎
に最適な状態に維持されたハッシュテーブル、および、
文字成分表を使用して、テキストデータの検索処理を高
速に行える技術を提供することにある。

【００５２】本発明の前記目的並びにその他の目的及び
新規な特徴は、本明細書の記載及び添付図面によって明
らかにする。

【００５３】

【課題を解決するための手段】本願において開示される
発明のうち、代表的なものの概要を簡単に説明すれば、
下記の通りである。

【００５４】（１）文書中で使用される文字の数より少
ないエントリに文字コードをマッピングした文字成分表
と、前記文字成分表をアクセスするための使用されるハ
ッシュテーブルと、テキストデータからなるデータベー
ス本体をサーチする前に、前記ハッシュテーブル、およ
び、文字成分表を使用する文字成分表サーチを含む補助
サーチ行う第１の手段と、前記第１の手段により絞り込
まれた文書に対してテキストサーチを行う第２の手段と
を具備する階層プリサーチ方式のテキストデータ検索装
置において、各データベースで使用される文字の使用頻
度を基づき最適化された、複数のデータベース毎の文字
成分表、および、ハッシュテーブルと、文書を登録ある
いは削除した場合にハッシュテーブルの最適化状態を判
断する判断手段と、前記判断手段に基づきハッシュテー
ブルが最適状態でないと判断した場合に、新たに文字成
分表、および、ハッシュテーブルを再作成する手段とを
具備することを特徴とする。

【００５５】

【作用】前記手段によれば、複数のデータベースを管理
するテキストデータ検索装置において、各データベース
毎に最も効率よく検索できるよう最適化された文字成分
表、および、ハッシュテーブルを使用し、また、文書を
登録あるいは削除した場合に、ハッシュテーブルの最適
化状態を判断し、新たに文字成分表、および、ハッシュ
テーブルを再作成して、各データベース毎のテキストデ
ータを検索するようにしたので、その検索処理を高速化
することが可能となる。

【００５６】

【実施例】以下、図面を参照して本発明の実施例を詳細
に説明する。

【００５７】なお、実施例を説明するための全図におい
て、同一機能を有するものは同一符号を付け、その繰り
返しの説明は省略する。

【００５８】（実施例１）図１は、本発明の一実施例
（実施例１）であるテキストデータ検索装置の概略構成
を示すブロック図である。

【００５９】図１に示すように、本実施例１のテキスト
データ検索装置は、ディスプレイ１００、キーボード１
０１、ＣＰＵ１０２、原文書を取り込むためのフロッピ
ディスク等からなる入力デバイス１０３、主メモリ１０
４、データベースを格納するディスク装置１２０から構
成される。

【００６０】主メモリ１０４には、テキスト登録プログ
ラム１０５、凝縮テキスト登録プログラム１０６、文字
成分表登録プログラム１０７、ハッシュテーブル登録プ
ログラム１０８、文書削除プログラム１０９、ハッシュ
テーブル最適化チェックプログラム１１０、これら文書
登録・削除のためのプログラムを制御する文書登録・削
除制御プログラム１１１という文書登録・削除関連プロ
グラム群と、検索条件式解析プログラム１１４、文字成
分表サーチプログラム１１５、凝縮テキストサーチプロ
グラム１１６、テキストサーチプログラム１１７、これ
らの文書検索のためのプログラムを制御する階層検索制
御プログラム１１８、その他データベースオープンプロ
グラム１１２、データベースクローズプログラム１１３
と、検索に必要なデータ、及びテーブルを格納するデー
タエリア１１９が存在する。

【００６１】ディスク装置１２０には、全データベース
に共通に使用する標準ハッシュテーブル１２１、各デー
タベース毎のテキスト１２２、凝縮テキスト１２３、文
字成分表１２４、ハッシュテーブル１２５が設けられ
る。

【００６２】データベース１は、それに対応するハッシ
ュテーブル１（１２５）、および、文字成分表１（１２
４）を使用して文字成分表サーチを行い、また、データ
ベース２は、それに対応するハッシュテーブル２（１２
５）、および、文字成分表２（１２４）を使用して文字
成分表サーチを行う。

【００６３】このように、検索対象のデータベースの文
字使用頻度に最適にハッシングされた文字成分表サーチ
を常に行うことにより、どのような検索文字列でも、平
均的に最低の文字成分表での絞り込み率を得ることがで
きる。

【００６４】例えば、「電子技術データベース」、「新
聞記事データベース」という２つのデータベースが存在
するとする。

【００６５】ここで、「電流」と「電圧」という２つの
文字列が両データベースに含まれているとし、かつ、
「電子技術データベース」でのこの２つの文字列の使用
頻度は、「新聞記事データベース」での使用頻度より高
いとする。

【００６６】その場合、それぞれのデータベースに対応
する文字成分表での、「電流」と「電圧」のハッシング
状況は図２に示すようになる。

【００６７】図２において、グラフ１５０が「電子技術
データベース」でのハッシング状況を、グラフ１５１が
「新聞記事データベース」でのハッシング状況を示して
いる。

【００６８】「電子技術データベース」では、「電流」
及び「電圧」という部分文字列の使用頻度が高いため、
それぞれ別々の文字成分表エントリになるようにハッシ
ングされ、「新聞記事データベース」では、これらの二
つの部分文字列の出現頻度が低かったため、一つの重複
した文字成分表エントリにハッシングされている状態を
示している。

【００６９】このように、各データベースのテキストデ
ータに含まれる部分文字列の使用頻度の違いにより、ハ
ッシングのされ方が大きく異なる場合がある。

【００７０】このような場合でも、各データベース毎
に、それに対応するハッシュテーブル（１２５）を持た
せることで、常に、平均的に最小の文字成分表ヒット率
を得ることができる。

【００７１】前記した如く、各データベースは、テキス
ト１２２、凝縮テキスト１２３、文字成分表１２４、ハ
ッシュテーブル１２５の４つのファイルから構成されて
おり、凝縮テキスト１２３、文字成分表１２４、ハッシ
ュテーブル１２５は、テキスト本体をサーチする文書数
を絞り込むために使用する補助ファイルである。

【００７２】即ち、テキスト本体をサーチする前にこれ
らの補助ファイルによるサーチを行い、そこで文書数を
より少なく絞り込むほど検索性能が向上する。

【００７３】次に、図３を使用して、テキスト１２２、
および、凝縮テキスト１２３について説明する。

【００７４】図３において、原文書１３０は、データベ
ースとして登録するテキストデータである。

【００７５】テキスト１２２は、この原文書を変更を加
えずに蓄積したものである。

【００７６】凝縮テキスト１２３は、テキストを単語レ
ベルで部分文字列に分割し、分割した部分文字列間で相
互に文字列の包含関係を調べ、他の部分文字列に含まれ
る文字列を排除した部分文字列の集合である。

【００７７】例えば、テキスト１２２における文書４の
「音声に対し音声で応答する」というテキストでは、ひ
らがなを取り除いた「音声、対、音声、応答」から、重
複する「音声」という部分文字列を一つだけに圧縮した
「音声、対、応答」が凝縮テキスト１２３となる。

【００７８】次に、文字成分表１２４、および、ハッシ
ュテーブル１２５について、前記図１９を使用して詳細
に説明する。

【００７９】図１に示す文字成分表１２４、および、ハ
ッシュテーブル１２５が、図１９における文字成分表４
０１、および、ハッシュテーブル４００に該当する。

【００８０】文字成分表４０１は、テキスト１２２の全
ての１文字以上の部分文字列に対して１ビットの情報を
割り付けたビットリストである。

【００８１】本実施例１では、２文字の部分文字列に対
し１ビットの情報を割り付けた連接文字成分表を使用す
る。

【００８２】ハッシュテーブル４００は、複数の部分文
字列を文字成分表の一つのエントリに対応付けている。

【００８３】例えば、「経済」という検索文字列で文字
成分表を検索する場合を考えてみると、「経済」という
部分文字列に対しハッシュテーブル４００の「関係、経
済」のエントリを引き、このハッシュテーブルエントリ
が指す文字成分表エントリのビットがオンとなる文書１
と文書３をヒットさせる。

【００８４】通常、ある１文字の部分文字列を含む文書
の数は、ある２文字以上の部分文字列を含む文書の数よ
り多くなる。

【００８５】例えば、２万件程度の一般的な新聞記事デ
ータで、「経」という１文字の部分文字列を含む文書は
約４０００件存在し、「経済」という２文字の部分文字
列を含む文書は１８００件存在するという実例がある。

【００８６】即ち、１文字の部分文字列に対し１ビット
情報を割り付けた文字成分表より、２文字の部分文字列
に対し１ビットの情報を割り付けた文字成分表の方がよ
り少ない文書に絞り込むことが可能であり、検索性能も
向上する。

【００８７】更に、より長い部分文字列に対し１ビット
の情報を割り付けた文字成分表の方がより少ない文書に
絞り込むことが可能である。

【００８８】また、２文字の連接文字成分表で、２文字
の部分文字列に対し単純に１ビットの情報を割当てたと
すると、シフトＪＩＳコードの場合には文字数が全部で
６，８７９あるため、６，８７９×６，８７９＝４７，
３２０，６４１種の組み合わせの文字列に対しエントリ
を用意する必要があり、これは、メモリを大量に消費し
実用上好ましくない。

【００８９】そのため、本実施例１では、ハッシュテー
ブル４００を用意し、複数の部分文字列を文字成分表の
一つのエントリにまとめることにより文字成分表を小さ
くしている。

【００９０】どの部分文字列を一つのハッシュテーブル
エントリに組み合わせるかということは、高い検索性能
を維持するために重要な項目である。

【００９１】テキストデータ内での各部分文字列が出現
する文書の数は、前記図２０におけるグラフ５５０のよ
うにばらばらに異なっている。

【００９２】このことから、誤って出現頻度の高い検索
文字列同士を同じハッシュテーブルエントリに組み合わ
せてしまうと、その部分文字列での文字成分表サーチで
はほとんど絞り込むことができず、検索性能が大幅に低
下することになる。

【００９３】例えば、前記図２０の例では、数の多い
「電気」と「電圧」という部分文字列の組み合わせがハ
ッシュテーブル４００のエントリとなった場合、これが
指す文字成分表エントリに含まれる文書の数は多くな
り、文字成分表で十分に文書を絞り込むことができなく
なる。

【００９４】このような問題を避けるために、本実施例
１では、図２０におけるグラフ５５２に示すように、出
現頻度の多い部分文字列は、単独のエントリを与え、出
現頻度の少ない部分文字列同士は同じハッシュテーブル
エントリに対応させ、各ハッシュテーブルエントリに対
応する文書の数が基準値で平均化するように調整する文
字使用頻度情報ハッシング方式を採用している。

【００９５】例えば、前記図２０では、「電流」と「電
圧」という基準値より出現頻度が少ない部分文字列同士
を同じハッシュテーブルエントリに組み合わせている。

【００９６】これにより、どの部分文字列で検索を行っ
ても、平均的に最低の文字成分表での絞り込み率を維持
することができる。

【００９７】また、データベースの内容が異なれば、各
部分文字列が出現する文書の数も異なる。

【００９８】そのため、本実施例１では、各データベー
ス毎に文字使用頻度ハッシング方式で最適化したハッシ
ュテーブル１２５を用意し、最高の検索性能が得られる
ようしている。

【００９９】即ち、各テキストデータ毎に文字成分表１
２４、および、ハッシュテーブル１２５がそれぞれ存在
し、ハッシュテーブル１２５は、各データベース毎のテ
キストデータの文字使用頻度情報を使用して、どの検索
文字列であっても、平均的に最小のヒット率が得られる
ようにハッシングが行われている。

【０１００】そして、検索を行う場合には、検索対象の
テキストデータに対応するハッシュテーブル１２５を使
用して文字成分表サーチを行う。

【０１０１】次に、図４を用いて、本実施例１における
検索時の動作を説明する。

【０１０２】始めに、ステップ３０１において、データ
ベースのオープンを行う。

【０１０３】キーボード１０１より検索を希望するデー
タベースをオープンするためのコマンドを入力すると、
データベースオープンプログラム１１２は、ディスク装
置１２０から指定されたデータベースのテキスト１２
２、凝縮テキスト１２３、文字成分表１２４、ハッシュ
テーブル１２５を主メモリ１０４上のデータエリア１１
９に展開する。

【０１０４】次に、ステップ３０２において、キーボー
ド１０１より検索コマンドと検索文字列を入力する。

【０１０５】検索コマンドと検索文字列は、検索条件式
解析プログラム１１４により解析が行われる。

【０１０６】その後、ステップ３０３において、文字成
分表サーチプログラム１１５により、ハッシュテーブル
１２５、文字成分表１２４を使用して文字成分表サーチ
を行う。

【０１０７】例えば、図５に示すように、「ライオン」
という検索文字列が与えられたとすると、まずこれを部
分文字列に分解する。

【０１０８】生成される部分文字列は、「ライ」、「イ
オ」、「オン」の３つとなる。

【０１０９】このそれぞれの部分文字列を使って、ハッ
シュテーブル１２５、文字成分表１２４を引く。

【０１１０】前記図１９に示すハッシュテーブル４００
では、「イオ」と「オン」は、同じハッシュテーブルエ
ントリに配置されているため、この両者から得られる文
字成分表エントリは同じものとなる。

【０１１１】このようにして得た各部分文字列に対応す
る文字成分表エントリのビットリストの論理積を取った
結果でビットがオンになっている文書がヒットした文書
となる。図５の場合には、文書１と文書３がヒットした
ことになる。

【０１１２】次に、ステップ３０４において、前記ステ
ップ３０３の文字成分表サーチで絞り込まれた文書に対
し、凝縮テキストサーチプログラム１１６により、凝縮
テキスト１２３を使って凝縮テキストサーチを行う。

【０１１３】凝縮テキストサーチは、検索文字列を単語
に分割し、分割された各単語単位に検索を行う。

【０１１４】例えば、「経済の発展」という検索文字列
であれば、「経済」、「発展」という単語単位で凝縮テ
キスト１２３をサーチし、その両方の単語が出現した文
書をヒットさせる。

【０１１５】次に、ステップ３０５において、前記ステ
ップ３０４の凝縮テキストサーチで絞り込まれた文書に
対し、テキストサーチプログラム１１７により、テキス
ト１２２を使用してテキストサーチを行う。

【０１１６】テキストサーチでは、検索文字列そのもの
をサーチする。

【０１１７】例えば、「経済と発展」という検索文字列
であれば、「経済と発展」という文字列が存在する文書
をヒットさせる。

【０１１８】以上の処理の結果得られた検索結果は、デ
ィスプレイ１００に表示される。

【０１１９】もし、まだ別の検索文字列による検索を続
ける場合には、繰返しキーボード１００から検索コマン
ドと検索文字列を入力し、以上説明してきたことと同様
の処理を行う。

【０１２０】検索を終了するには、ステップ３０６にお
いて、データベースのクローズを行う。

【０１２１】キーボード１０１よりデータベースをクロ
ーズするためのコマンドを入力すると、データベースク
ローズプログラム１１３が、主メモリのデータエリア１
１９に展開されているテキスト１２２、凝縮テキスト１
２３、文字成分表１２４、ハッシュテーブル１２５を解
放する。

【０１２２】階層検索制御プログラム１１８は、前記検
索条件式解析プログラム１１４、文字成分表サーチプロ
グラム１１５、凝縮テキストサーチプログラム１１６、
テキストサーチプログラム１１７の実行の制御を行う。

【０１２３】以上説明したように、本実施例１では階層
検索方式を採用しており、通常の場合、文字成分表サー
チで全文書件数の１０％程度まで絞り込み、凝縮テキス
トサーチで全文書件数の５％程度まで絞り込むことがで
きる。

【０１２４】即ち、最も検索に時間がかかるテキストサ
ーチを行う文書の数は全文書の５％程度で済むため、高
速な検索を実現している。

【０１２５】更に、本実施例１は、データベース毎に最
適化されたハッシュテーブル１２５を用意しているた
め、常に文字成分表で低い絞り込み率を維持することが
でき、ハッシュテーブル１２５をデータベース間で共用
する場合に比べて、より高い検索性能を実現している。

【０１２６】次に、図６を用いて、本実施例１の文書の
登録動作について説明する。

【０１２７】まず、キーボード１０１から文書登録を実
行するコマンドを入力し、入力デバイス１０３から登録
する文書のテキストデータを入力する。

【０１２８】始めに、ステップ５０１において、テキス
ト登録プログラム１０５によりテキスト１２２の作成、
および、ディスク装置１２０への登録を行う。

【０１２９】テキスト１２２の作成手順は、前記図３に
示すように、入力デバイス１０３から入力された原文書
１３０に変更を加えずにテキスト１２２に追加するとい
う手順により行う。

【０１３０】次に、ステップ５０２において、凝縮テキ
スト登録プログラム１０６により凝縮テキスト１２３の
作成、および、ディスク装置１２０への登録を行う。

【０１３１】凝縮テキスト１２３の作成手順は、前記図
３に示すように、テキスト１２２を単語レベルで部分文
字列に分割し、分割した部分文字列間で相互に文字列の
包含関係を調べ、他の部分文字列に含まれる文字列を排
除する。

【０１３２】例えば、テキスト１２２の文書４「音声に
対し音声で応答する」というテキストでは、ひらがなを
取り除いた「音声、対、音声、応答」から、重複する
「音声」という部分文字列を一つだけに圧縮した「音
声、対、応答」が凝縮テキスト１２３となる。

【０１３３】次に、ステップ５０３において、文字成分
表登録プログラム１０７により文字成分表１２４の作
成、および、ディスク装置１２０への登録を行う。

【０１３４】前記文字成分表１２４の作成手順につい
て、図７を用いて説明する。

【０１３５】始めに、ステップ６０１において、登録す
る文書のテキスト１２２に含まれる２文字からなる部分
文字列の全てを抽出する。

【０１３６】次に、ステップ６０２において、各部分文
字列で、ハッシュテーブル１２５を引く。

【０１３７】次に、ステップ６０３において、そのハッ
シュテーブルエントリが対応する文字成分表エントリの
新規文書のビットをオンにする。

【０１３８】例えば、図８に示すように、「・・経済の
発展には・・」という新規文書を登録する場合、このテ
キストデータの部分文字列「経済」に対しては、ハッシ
ュテーブル１２５から「経済」に対応するエントリを引
き、そのハッシュテーブルエントリに対応する文字成分
表エントリの新規文書に対応するビットをオンにする。

【０１３９】以下、このテキストデータ中の全部分文字
列に対し同様の処理を行う。

【０１４０】次に、ステップ５０４において、ハッシュ
テーブル最適化チェックプログラム１１０によるハッシ
ュテーブル１２５の最適化チェックを行う。

【０１４１】テキスト１２２に含まれる部分文字列の使
用頻度から正確にハッシュテーブル１２５を作成したと
しても、ハッシュテーブル１２５の決定後にテキストに
文書の登録を継続的に行った場合は、登録する文書に含
まれている部分文字列が、登録前の文字使用頻度情報で
ハッシングされている文字成分表１２４に追加されるこ
とになり、結果として、ハッシュテーブル１２５が最適
な状態から徐々に悪い方向へ変化していくことになる。

【０１４２】そのため、ハッシュテーブル１２５の最適
化をチェックし、テキスト１２２の実際の部分文字列の
使用頻度とハッシュテーブル１２５との不一致が発生し
た場合、再度テキスト１２２中の部分文字列の使用頻度
を採取し、ハッシュテーブル１２５、および、文字成分
表１２４を再作成する必要がある。

【０１４３】しかし、この作業は、計算機にとって負担
が大きいため、頻繁に実行すべきことではない。そこ
で、テキスト１２２中の部分文字列の使用頻度とハッシ
ュテーブル１２５との不一致による検索速度の低下の許
容範囲をユーザが定め、それを越えたときに、テキスト
１２２中の部分文字列の使用頻度情報の採取、ハッシュ
テーブル１２５、および、文字成分表１２４を再作成す
るようにした方が効果的である。

【０１４４】前記ハッシュテーブルの最適化チェックの
方式について、図９を用いて説明する。

【０１４５】図９に示すグラフ２５０は、何度か文書の
登録を行った後の各ハッシュテーブルエントリが対応す
る文字成分表エントリに含まれる文書の数を示してい
る。

【０１４６】文書の追加登録を行っていない状態では、
複数の部分文字列が一つのハッシュテーブルエントリに
ハッシングされているハッシュテーブルエントリに含ま
れる文書の数は基準値で一致しているはずであるが、文
書登録を繰り返すことにより、全テキストデータに含ま
れる部分文字列の数が偏って増加することになる。

【０１４７】その結果、基準値を越えるハッシュテーブ
ルエントリが出現するようになる。

【０１４８】例えば、図９に示すグラフ２５０では、
「電流」、「電圧」という部分文字列が含まれている文
書を多数登録したために、「電流」、「電圧」という部
分文字列が対応しているハッシュテーブルエントリに含
まれる文書の数が基準値より増加している。

【０１４９】このような状態になると、どの部分文字列
で文字成分表サーチを行った場合でも、ヒットする文書
件数は基準値に抑えられていたものが、例えば、「電
流」という部分文字列による文字成分表サーチを行った
場合には、基準値よりも多くの文書がヒットすることに
なり、文字成分表サーチで充分な絞り込みができなくな
るばかりでなく、「電圧」のように同一のエントリにマ
ッピングされた他の文字列で検索する場合も、充分な絞
り込みができなくなる。

【０１５０】ハッシュテーブル１２５の最適化チェック
は、図９に示すグラフ２５０のように、基準値に対し、
文字成分表での絞り込み悪化の許容範囲を設定し、これ
を上限基準値とする。

【０１５１】そして、複数の部分文字列の組み合わせで
ハッシングされているハッシュテーブルエントリが指す
文字成分表エントリに含まれる文書数がこの上限基準値
を越えていないかをハッシュテーブル最適化チェックプ
ログラム１１０がチェックする。

【０１５２】例えば、図９に示すグラフ２５０では、
「電流」、「電圧」の部分文字列のエントリが上限基準
値を越えているため、このハッシュテーブルは最適化さ
れていない状態と判断する。

【０１５３】もし、図９に示すグラフ２５１のように多
少基準値を越えていても、上限基準値を越えているエン
トリがなければ、そのハッシュテーブル１２５は最適化
されている状態と判断する。

【０１５４】前記ステップ５０４におけるハッシュテー
ブル最適化チェックプログラム１１０によるハッシュテ
ーブル１２５の最適化チェックで、ハッシュテーブル１
２５は最適化されている状態であると判断された場合に
は、そこで登録作業が終了する。

【０１５５】もし、ハッシュテーブル１２５が最適化さ
れていないと判断された場合には、検索性能を維持する
ために、ハッシュテーブル１２５を最適化された状態に
編成しなおす必要がある。

【０１５６】本実施例１では、ステップ５０５におい
て、ユーザにそのことを知らせるメッセージをディスプ
レイ１００に表示、警告し、文書の登録作業を終了す
る。

【０１５７】ユーザはこの警告に従い、ハッシュテーブ
ル１２５の再作成を実行することになる。

【０１５８】また、この方法以外に、ハッシュテーブル
１２５が、最適化されていないことをシステムが認識し
た時点で自動的にハッシュテーブル１２５の再作成を実
行するという方法でも可能である。

【０１５９】以下に、ハッシュテーブル１２５の作成手
順を、図１０を用いて説明する。

【０１６０】始めに、ステップ９０１において、テキス
トデータ中の全文書の部分文字列を抽出し、各部分文字
列の出現頻度を集計する。

【０１６１】その結果は、前記図２０のグラフ５５０の
ようになる。

【０１６２】通常の場合、このように各部分文字列が出
現する文書の数はばらばらの状態である。

【０１６３】前記図２０のグラフ５５１は、これらの部
分文字列を出現頻度が多い順に整列した結果を示してい
る。

【０１６４】次に、ステップ５０２において、ハッシュ
テーブルエントリの数（文字成分表エントリの数と等し
い）と全部分文字列の出現頻度数の合計から基準値を算
出する。

【０１６５】ハッシュテーブルエントリの数をＸ、全部
分文字列の出現頻度数の合計をＮとすると、基準値Ｚは
以下の式で求めることができる。

【０１６６】

【数１】 Ｚ＝Ｎ／Ｘ ・・・・・・・・・・・・
・（１−１）式 しかし、部分文字列の中には、出現頻度がＺよりも大き
いものが存在する。

【０１６７】そういう部分文字列は他の部分文字列と組
み合わせたハッシュテーブルエントリにはせずに、単独
に一つのハッシュテーブルエントリを割り当てなければ
ならない。

【０１６８】このような単独割当て部分文字列の数を
Ａ、全単独割当て部分文字列のデータベース内での出現
頻度数の合計をＡＮとして、（１−１）式を修正すると
以下の式になる。

【０１６９】

【数２】 Ｚ＝（Ｎ−ＡＮ）／（Ｘ−Ａ）・・・・
・（１−２）式 この（１−２）式で得られた基準値Ｚでも単独割当てに
変えなければならない部分文字列が存在する場合は、そ
の部分文字列をＡ、及びＡＮに加えて再計算を行う。

【０１７０】最終的に単独割当て部分文字列に変えなけ
ればならない部分文字列がなくなるような基準値が得ら
れるまで再計算を続け、単独割当て部分文字列に変えな
ければならない部分文字列が無くなった時点でのＺが真
の基準値となる。

【０１７１】次に、ステップ９０３において、出現頻度
が基準値に満たない部分文字列を他の出現頻度が基準値
に満たない部分文字列と同じハッシュテーブルエントリ
に組み合わせることによりそのハッシュテーブルエント
リが対応する文書の数を基準値と等しくする。

【０１７２】この操作を単独割当て部分文字列のハッシ
ュテーブルエントリ以外の全てのハッシュテーブルエン
トリに対して行う。

【０１７３】その結果が、前記図２０に示すグラフ５５
２である。

【０１７４】例えば、前記図２０に示すグラフ５５２で
は、出現頻度が基準値に満たない「電流」、「電圧」と
いう部分文字列が同じハッシュテーブルエントリにハッ
シングされている。

【０１７５】また、出現頻度が基準値より大きい「電
気」という部分文字列は単独で一つのハッシュテーブル
エントリが割当てられている。

【０１７６】最後に、ステップ９０４において、この新
規に作成したハッシュテーブル１２５を使い、文字成分
表１２４全体を新規に作成する。

【０１７７】次に、データベースの初期登録時のハッシ
ュテーブルについて述べる。

【０１７８】データベースの初期登録時はハッシュテー
ブルが存在しない。

【０１７９】また、登録文書件数が少ないとハッシング
による検索性能向上の効果は小さい。

【０１８０】このため、データベースの初期登録時は、
新聞記事等の一般的に出現する部分文字列に偏りが少な
いデータベースから作成した標準ハッシュテーブル１２
１を使用する。

【０１８１】そして、登録文書件数が充分増えた時点
で、前記したような方法でハッシュテーブル１２５を作
成する。

【０１８２】文書登録・削除制御プログラム１１１は、
前記テキスト登録プログラム１０５、凝縮テキスト登録
プログラム１０６、文字成分表登録プログラム１０７、
ハッシュテーブル登録プログラム１０８、ハッシュテー
ブル最適化チェックプログラム１１０の実行の制御を行
う。

【０１８３】次に、文書の削除操作について、図１１を
用いて説明する。

【０１８４】始めに、ステップ１００１において、テキ
スト１２２、凝縮テキスト１２３、文字成分表１２４か
ら削除する文書のデータを削除する。

【０１８５】次に、ステップ１００２において、ハッシ
ュテーブル最適化チェックを行う。

【０１８６】文書削除時のハッシュテーブル最適化チェ
ック方式を、図１２を用いて説明する。

【０１８７】文書の削除を繰返し行うと、ハッシュテー
ブルエントリに対応する文書の数が基準値より少ないも
のが出現する。

【０１８８】例えば、図１２に示すグラフ３５０は、
「電流」・「電圧」という部分文字列を含む文書を多数
削除した結果、「電流」・「電圧」という部分文字列の
ハッシュテーブルエントリが対応する文書数が基準値よ
り少なくなった場合を示している。

【０１８９】この状態は検索性能が低下することはない
が、基準値を計算し直すことで、基準値をより低い値に
設定することが可能となり、検索性能を向上させること
ができる。

【０１９０】そこで、ハッシュテーブルエントリに対応
する文書の数がある値よりも少なくなった場合に、基準
値を再計算すべき旨を伝える下限基準値をあらかじめ設
定しておき、ハッシュテーブル最適化チェックでは、こ
の下限基準値を下回る文書数のハッシュテーブルエント
リが一つでも存在すれば、ハッシュテーブルが最適化状
態でないと判断する。

【０１９１】また、対応する文書数が基準値より少ない
ハッシュテーブルエントリが存在しても、下限基準値を
下回る文書数のハッシュテーブルエントリが存在しなけ
れば最適化状態であると判断する。

【０１９２】例えば、図１２に示すグラフ３５１の場合
は、下限基準値を下回っているハッシュテーブルエント
リは存在しないため最適化状態であると判断され、図１
２に示すグラフ３５０の場合は、「電流」・「電圧」と
いう部分文字列のハッシュテーブルエントリが対応する
文書数が下限基準値を下回っているため最適化状態でな
いと判断される。

【０１９３】前記ステップ１００２におけるハッシュテ
ーブル最適化チェック処理で、ハッシュテーブル１２５
が最適化状態であれば、文書削除処理は終了する。

【０１９４】ハッシュテーブル１２５が最適化状態でな
ければ、ステップ１００３において、ユーザに対し、ハ
ッシュテーブル１２５の再作成を行う必要があることを
知らせるメッセージをディスプレイ１００に表示し、警
告を行い、文書削除処理を終了する。

【０１９５】また、ハッシュテーブル１２５が最適化状
態でない場合、自動的にハッシュテーブル１２５を再作
成してしまうという方法でも実現可能である。

【０１９６】前記文書削除プログラム１０９、ハッシュ
テーブル最適化チェックプログラム１１０は、文書登録
・削除制御プログラム１１１によって実行の制御が行わ
れる。

【０１９７】以上説明してきたように、本実施例１のテ
キストデータ検索装置では、各テキストデータ１２２毎
に、最適化されたハッシュテーブル１２５、文字成分表
１２４を用いて高い検索性能を維持することができる。

【０１９８】（実施例２）次に、本発明の他の実施例
（実施例２）について説明する。

【０１９９】本実施例２は、前記実施例１に対して、ユ
ーザ指定ハッシング方式で作成したハッシュテーブルを
提供することにより、文字成分表での文書の絞り込みを
より向上させ、検索性能を向上させるものである。

【０２００】本実施例２と前記実施例１とは、ディスク
装置内に格納される各データベースを構成するファイル
が相違するが、他の構成は同じである。

【０２０１】本実施例２におけるデータベースのファイ
ル構成を図１３を用いて説明する。

【０２０２】図１３において、２１００はディスク装置
であり、また、各データベースを構成するファイルは、
テキスト２１０１、凝縮テキスト２１０２、文字成分表
２１０３、ハッシュテーブル２１０４、ユーザ指定ハッ
シングファイル２１０５である。

【０２０３】テキスト２１０１、凝縮テキスト２１０
２、文字成分表２１０３は、前記実施例１と同じであ
る。

【０２０４】本実施例２のハッシュテーブル２１０４
は、ユーザが指定する部分文字列を単独のハッシュテー
ブルエントリにハッシングを行うというユーザ指定ハッ
シング方式によって作成されている。

【０２０５】ユーザ指定ハッシングファイル２１０５
は、ユーザ指定ハッシングで単独のハッシュテーブルエ
ントリを割り当てたい部分文字列を記述したファイルで
ある。

【０２０６】前記ユーザ指定ハッシング方式について、
図１４を用いて説明する。

【０２０７】図１４において、グラフ４５０に示すハッ
シングの状態は、前記した方法によるハッシング方式で
最適化されている状態である。

【０２０８】ここで、「電流」という部分文字列で文字
成分表サーチを行った場合、ヒットする文書件数は基準
値と一致する。

【０２０９】この「電流」という部分文字列は、この部
分文字列を含む文書の数が基準値より少ないため、他の
部分文字列と組み合わされたハッシュエントリとなって
いる。

【０２１０】これを単独のハッシュテーブルエントリと
したものが、図１４に示すグラフ４５１である。

【０２１１】この場合、「電流」という部分文字列で文
字成分表サーチを行った場合、ヒットする文書件数は基
準値より少なくなり、「電流」という部分文字列を含む
検索文字列での文字成分表サーチの絞り込み性能を向上
させることができる。

【０２１２】このように、ユーザ指定ハッシング方式に
より作成したハッシュテーブルはユーザが指定した特定
の部分文字列に対する検索性能向上させることを可能と
する。

【０２１３】ユーザが特定の部分文字列を指定するに
は、ユーザ指定ハッシングファイル２１０５にその部分
文字列を記述しておく。

【０２１４】図１５に、前記ユーザ指定ハッシングファ
イル２１０５の形式の一例を示す。

【０２１５】図１５に示す例では、「電流」、「電圧」
という部分文字列でユーザ指定ハッシングを行うよう指
定している。

【０２１６】前記ユーザ指定ハッシングの処理方式を、
図１６を用いて説明する。

【０２１７】始めに、ステップ１５０１において、テキ
スト２１０１中の全文書の２文字からなる部分文字列を
抽出し、各部分文字列の出現頻度を集計する。

【０２１８】次に、ステップ１５０２において、ユーザ
指定ハッシングファイル２１０５を読み込み、ユーザが
単独のハッシュテーブルエントリを割り当てるよう指定
している部分文字列を得る。

【０２１９】次に、ステップ１５０３において、基準値
の算出を行う。

【０２２０】ユーザ指定ハッシングファイル２１０５か
ら得られる、ユーザが単独のハッシュテーブルエントリ
を割り当てるよう指定している部分文字列の数をＵ、そ
の全部分文字列の使用頻度合計をＵＮとすると、ユーザ
指定ハッシング方式での基準値を求める計算式は、前記
実施例１での（１−２）式にＵ、ＵＮのパラメータを追
加し、以下のようになる。

【０２２１】

【数３】 Ｚ＝（Ｎ−ＡＮ−ＵＮ）／（Ｘ−Ａ−
Ｕ）・・・（２−１） この式から得られる基準値Ｚよりも単独での出現頻度が
多い部分文字列が存在する場合、その部分文字列を単独
にハッシュテーブルエントリを割当てる部分文字列に変
更し、その部分文字列の数をＡに加え、その部分文字列
のデータベース内での出現頻度をＡＮに加えて、再計算
を行う。

【０２２２】最終的に単独にハッシュテーブル２１０４
を割当てるように変更しなければならない部分文字列が
なくなった時点でのＺが真の基準値となる。

【０２２３】次に、ステップ１５０４において、ハッシ
ュテーブル２１０４の各エントリに対応する文書の数が
基準値と一致するように部分文字列の組み合わせを決定
する。

【０２２４】この時、ユーザが単独のハッシュテーブル
エントリを割り当てるよう指定している部分文字列は、
基準値計算時に単独のハッシュテーブルエントリに割当
てるよう判断された部分文字列と同様に、単独で一つの
ハッシュテーブルエントリを与える。

【０２２５】最後に、ステップ１５０５において、この
ハッシュテーブル２１０４を使用して文字成分表２１０
３を作成する。

【０２２６】なお、本実施例２では、ユーザが検索性能
を向上させたい文字列を、単独の文字成分表エントリを
与えるようにしたが、複数の文字列と重複した文字成分
表エントリにハッシングされても、そのエントリに対応
する文書の数が基準値よりも小さくなるようにハッシン
グを行っても良い。

【０２２７】以上説明したように、本実施例２によれ
ば、ユーザ指定ハッシングファイル２１０５を用いて、
ユーザ指定ハッシングを行うことにより、ユーザが希望
する部分文字列に対し最高の検索性能を実現するハッシ
ュテーブル２１０４を作成することが可能となる。

【０２２８】これにより、どの検索文字列でも文字成分
表でのヒット率を平均化してしまうのではなく、ユーザ
が高速な検索を望む検索文字列に対して、文字成分表で
のヒット率をより小さくし、ユーザのニーズに合わせた
文字成分表の最適化を行うことが可能となる。

【０２２９】以上、本発明を実施例に基づき具体的に説
明したが、本発明は、前記実施例に限定されるものでは
なく、その要旨を逸脱しない範囲で種々変更し得ること
は言うまでもない。

【０２３０】

【発明の効果】本願において開示される発明のうち代表
的なものによって得られる効果を簡単に説明すれば、下
記の通りである。

【０２３１】（１）テキストデータ検索装置において、
データベース毎のテキストデータで使用されている文字
の文字使用頻度に基づき最適な文字成分表、および、ハ
ッシュテーブルを用意するようにしたので、どのデータ
ベースのテキストデータが対象であっても、また、どの
ような検索文字列であっても、平均的に最低の文字成分
表での絞り込み率を得ることができ、検索性能を向上さ
せることができ、これにより、高速なフルテキストサー
チ方法が実現可能である。

【０２３２】（２）テキストデータ検索装置において、
文書の登録・削除の結果生じる各文字成分表エントリ中
に含まれる文書数の片寄りをチェックすることにより、
ハッシュテーブル、および、文字成分表を、常に各デー
タベースのテキストデータの文字使用頻度に最適な状態
に保つことができ、検索性能の低下を防ぐことができ
る。

【０２３３】（３）テキストデータ検索装置において、
ユーザが指定した部分文字列の文字成分表でのヒット件
数が最小になるようにハッシングすることにより、ユー
ザが希望する検索文字列の検索性能を向上させることが
できる。

【図面の簡単な説明】

【図１】本発明の一実施例（実施例１）であるテキスト
データ検索装置の概略構成を示すブロック図である。

【図２】文字使用頻度が異なるデータベースでのハッシ
ング状況を説明するための図である。

【図３】本実施例１における、テキスト、凝縮テキスト
の形式を示す図である。

【図４】本実施例１における、検索の手順を示すフロー
チャートである。

【図５】本実施例１における、文字成分表検索処理方式
を説明するための図である。

【図６】本実施例１における、文書登録の手順を示すフ
ローチャートである。

【図７】本実施例１における、文字成分表の作成手順を
示すフローチャートである。

【図８】本実施例１おける、文字成分表の作成手順を説
明するための図である。

【図９】本実施例１における、文書追加登録後のハッシ
ュテーブル最適化チェック方式を説明するための図であ
る。

【図１０】本実施例１における、ハッシュテーブルの作
成手順を示すフローチャートである。

【図１１】本実施例１における、文書削除の手順を示す
フローチャートである。

【図１２】本実施例１における、文書削除後のハッシュ
テーブル最適化チェック方式を説明するための図であ
る。

【図１３】本発明の他の実施例（実施例２）であるテキ
ストデータ検索装置の各データベースの構成を示す図で
ある。

【図１４】本実施例２における、ユーザ指定ハッシング
方式を説明するための図である。

【図１５】本実施例２における、ユーザ指定ハッシング
ファイルの一形式を示す図である。

【図１６】本実施例２における、ユーザ指定ハッシング
によるハッシュテーブルの作成手順を示すフローチャー
トである。

【図１７】従来のフルテキストサーチにおける、階層プ
リサーチによる検索手順を説明するための図である。

【図１８】従来のフルテキストサーチにおける、連接文
字成分表の構造を説明するための図である。

【図１９】従来のフルテキストサーチにおける、ハッシ
ングをおこなった連接文字成分表を説明するための図で
ある。

【図２０】従来のフルテキストサーチにおける、文字使
用頻度情報ハッシング方式を説明するための図である。

【図２１】従来のフルテキストサーチにおける、文書登
録による文字成分表エントリ中の文書数増加を説明する
ための図である。

【符号の説明】 １００…ディスプレイ、１０１…キーボード、１０２…
ＣＰＵ、１０３…入力デバイス、１０４…主メモリ、１
２０…ディスク装置、１０５…テキスト登録プログラ
ム、１０６…凝縮テキスト登録プログラム、１０７…文
字成分表登録プログラム、１０８…ハッシュテーブル登
録プログラム、１０９…文書削除プログラム、１１０…
ハッシュテーブル最適化チェックプログラム、１１１…
文書登録・削除制御プログラム、１１４…検索条件式解
析プログラム、１１５…文字成分表サーチプログラム、
１１６…凝縮テキストサーチプログラム、１１７…テキ
ストサーチプログラム、１１８…階層検索制御プログラ
ム、１１２…データベースオープンプログラム、１１３
…データベースクローズプログラム、１１９…データエ
リア、１２０…ディスク装置、１２１…標準ハッシュテ
ーブル、１２２，２１０１…各データベース毎のテキス
ト、１２３，２１０２…各データベース毎の凝縮テキス
ト、１２４，２１０３…各データベース毎の文字成分
表、１２５，２１０４…各データベース毎のハッシュテ
ーブル、２１００…ディスク装置、２１０５…ユーザ指
定ハッシングファイル。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 畠山 敦 神奈川県川崎市麻生区王禅寺1099番地 株 式会社日立製作所システム開発研究所内 (72)発明者 寺地 元 大阪府大阪市中央区北浜三丁目５番29号 日立西部ソフトウエア株式会社内 (72)発明者 友広 修造 神奈川県横浜市戸塚区戸塚町5030番地 株 式会社日立製作所ソフトウェア開発本部内

Claims (1)

【特許請求の範囲】
1. 【請求項１】 文書中で使用される文字の数より少ない
   エントリに文字コードをマッピングした文字成分表と、
   前記文字成分表をアクセスするための使用されるハッシ
   ュテーブルと、テキストデータからなるデータベース本
   体をサーチする前に、前記ハッシュテーブル、および、
   文字成分表を使用する文字成分表サーチを含む補助サー
   チ行う第１の手段と、前記第１の手段により絞り込まれ
   た文書に対してテキストサーチを行う第２の手段とを具
   備する階層プリサーチ方式のテキストデータ検索装置に
   おいて、 各データベースで使用される文字の使用頻度を基づき最
   適化された、複数のデータベース毎の文字成分表、およ
   び、ハッシュテーブルと、文書を登録あるいは削除した
   場合にハッシュテーブルの最適化状態を判断する判断手
   段と、前記判断手段に基づきハッシュテーブルが最適状
   態でないと判断した場合に、新たに文字成分表、およ
   び、ハッシュテーブルを再作成する手段とを具備するこ
   とを特徴とするテキストデータ検索装置。