JP2007011438A - 絞り込み検索用インデクス構造及び情報検索装置 - Google Patents

Abstract

【課題】
キーワードの先頭から検索する文字を入力するごとに候補文字を絞り込む絞り込み検索を高速に実行できるようにする手段とインデクス構造を提案することを目的とする。
【解決手段】
人名や住所などのキーワード文字列を格納するデータに対して、そのキーワードの文字単位に、該当するデータ件数と、その文字に続く次候補文字情報を持つようにインデクスを構成する。このインデクスを使用して、１文字入力される毎に、それまで入力された文字を先頭から持つデータのデータ件数と、次に検索候補となる文字を次候補文字情報として格納する文字の種類に応じた長さのビットマップを返却することにより抽出し、最終的に絞り込まれた目的とするキーワードデータを抽出する。
【選択図】 図１０

Description

本発明は、情報検索装置において、キーワードの先頭から検索する文字を入力するごとに候補文字を絞り込む検索（以下、「絞り込み検索」と呼ぶ）を実現する技術に関するものである。

絞込み検索は、ユーザが目的の名称の情報を検索するための検索方式として、ナビゲーションシステムや、電子辞書や、歌手名を検索する端末装置などで用いられている。

その中の１つのナビゲーションシステムでは、近年、車両や道路交通網が発達するに伴い、ＧＰＳ（Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ）を利用して現在位置を取得し、目的地までの経路を誘導してくれるシステムが普及してきている。このようなナビゲーションシステムには、目的地への誘導を補助する機能として、「住所」、「電話番号」、あるいは「名称」といった様々なキーワードから目的地を探し出す検索機能がある。このうち「名称」から検索する機能では、ユーザが名称の先頭から文字を入力するごとに、入力された文字に前方一致するデータの該当件数を表示し、入力されている文字に続く候補文字となる文字だけを入力可能にすることで目的地を絞り込む絞込み検索が利用されている。

図１２は、このような検索システムの概要を表すブロック構成図である。この検索システムは、検索結果を表示するデータ表示部１２０１、キーワードとなる文字を入力するデータ入力部１２０２、データを検索するデータ処理部１２０３、及び、検索対象のデータが格納されている記憶装置１２０４を備える。このような構成の検索システムでは、データ入力部１２０２から入力されたキーワードとなる文字をもとにデータ処理部１２０３が記憶装置１２０４からデータを読み出し、表示部１２０１に検索結果を表示する。

下記特許文献１には、絞り込み検索を使用して入力を簡単化するナビゲーション装置が開示されている。この絞込み検索の方法は、文字が入力される毎に入力文字と検索対象データとの名称の前方一致比較を行い、一致した場合に、一致データリストへの登録と該当件数の加算により該当件数を求めるものである。

また、現在公知のインデクス構造を採用しているＤＢＭＳ（Ｄａｔａ Ｂａｓｅ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ）で絞り込み検索を実装することも可能である。この場合には、ＳＱＬ（Ｓｔｒｕｃｔｕｒｅｄ Ｑｕｅｒｙ Ｌａｎｇｕａｇｅ）と呼ばれる言語を使用してデータを操作する。ＳＱＬで使用する表名を「名称」、検索する列名を「キーワード」とする。ここでは、例えば、'あさ'をキーワードに、従来技術で絞り込み検索を実装する場合、まず、該当件数を求めるためのＳＱＬとして、
SELECT COUNT(*) FROM 名称 WHERE キーワード LIKE'あさ%'
を実行し、該当件数を求める。次に、次候補文字を検索するために、次のＳＱＬ、
SELECT * FROM 名称 WHERE キーワード LIKE'あさ%'
を実行し、すべての検索結果から、どの文字が次候補文字として存在しているかを求め直す必要がある。このように、ＤＢＭＳでも２つのＳＱＬを実行することにより絞り込み検索を実現できる。
特開２００３−２９４４７５

上記特許文献１に記載の技術では、一致データリストへの登録と該当件数を求めるので、入力文字に前方一致した一致データリストのデータ数が多い場合には、データ数分の前方一致比較処理を実施することになり、性能上の問題があった。

上記ＤＢＭＳでＳＱＬを用いて絞り込み検索を実装した場合、検索の度に２つのＳＱＬを実行するため、同じインデクスに２度アクセスしなければならない。また、該当する全てのインデクスにアクセスしなければならないため、該当する件数が多い場合には検索に時間がかかるという問題が発生する。

このように、公知のインデクス構造で絞り込み検索を実装する場合においても、該当件数を求める処理と次候補文字を求めるために該当するキーワードを含んでいる全てのインデクスにアクセスしなければならないため、検索性能上の問題があった。

本発明の目的は、より高速に絞り込み検索を行う手段、及びそれを実現するためのインデクス構造を提案することにある。

上記目的を達成するために、請求項１に係る発明は、所定のキーワード文字列を有するデータに対して、キーワードの先頭から検索する文字を１文字づつ入力し、目的とするデータを絞り込みながら検索する絞り込み検索用のインデクス構造であって、検索対象として登録するデータのキーワード文字列を文字毎に分解し、それらの各文字毎のインデクスキーを、ルートから順に下位方向にチェインで繋げ、各文字のインデクスキーに対応して、先頭からそのインデクスキーの文字までの文字列に前方一致するデータ件数と、その次に続くことが可能な文字である次候補文字情報とを備えるようにしたことを特徴とする。

請求項２に係る発明は、請求項１に記載の絞り込み検索用のインデクス構造において、登録するデータのキーワード文字列をインデクスキーとして登録するとき、ある文字以降は１つのキーワード文字列の並びしか可能性がないときには、文字毎のインデクスキーとする代わりに、複数文字のインデクスキーとすることを特徴とする。

請求項３に係る発明は、請求項１または２に記載の絞り込み検索用のインデクス構造において、前記次候補文字情報は、インデクスキーになる可能性のある文字の種類数分のビットからなるビット情報で表現されていることを特徴とする。

請求項４に係る発明は、請求項１から３の何れか１つに記載の絞り込み検索用のインデクス構造を利用した情報検索装置において、検索を行うユーザアプリケーションから１文字ずつ入力された文字に対して、前記インデクスキーをルートから順に辿り、そこまでに入力された文字を先頭から持つデータのデータ件数と、次に検索候補となる次候補文字情報を返却するユーザアプリケーションインターフェースを備えたことを特徴とする。

請求項５に係る発明は、請求項４に記載の情報検索装置において、検索する文字が１文字ずつ入力されていった途中でユーザから検索実行指示があったとき、ルートから辿っていってその時点で行き着いているインデクスキーからさらに下位にインデクスキーを辿り、最終的に絞り込まれた目的とするデータを抽出することを特徴とする。

本発明によれば、１文字入力される毎にインデクスを順に参照するだけで、そこまでに入力されたキーワードに前方一致するデータの該当件数と、そのキーワードに続く可能性のある文字を示す次候補文字情報を得られるため、絞り込み検索の検索性能を向上させることができる。また、ＤＢＭＳで絞り込み検索を実装する場合に、検索性能を向上させることができる。さらに、次候補文字情報をアプリケーションに返すインターフェースを提供できる。

以下、本発明を適用した情報検索装置の一実施の形態について、図面を参照して具体的に説明する。

図１は、本発明の一実施形態を示すブロック構成図である。この情報検索装置は、検索画面部１０１、検索するデータが格納されている地図関連データ群１０２、地図関連データに対するインデクスが格納されているインデクスデータ群１０３、及び、検索処理を行なう検索処理部１０６を備えている。

検索画面部１０１は、ナビゲーションシステムの画面に相当しており、検索する文字を入力するための入力部１０４と、検索した結果を表示する表示部１０５とを備えている。検索処理部１０６は、ＤＢＭＳなどの検索機能をもったソフトウェア及びそれを動作させるハードウェアに相当しており、入力部１０４から入力された情報をもとにインデクスデータ群１０２や地図関連データ群１０３への検索処理を行い、検索結果を１０５に返却する処理を行なうものである。

図２は、地図関連データ群１０２に格納される地図関連データの例を示す。地図関連データは施設ごとに登録される。なお、地図データも同様にして格納されているがここでは省略する。１つの施設を示す地図関連データは、施設名２０１、施設読み２０２、住所２０３、電話番号２０４、及び位置情報２０５から構成される。このうち、施設読みにインデクスが付与しており、施設読みからデータを絞り込み、住所、電話番号、位置等を特定するようになっている。なお、ここでは施設読みにインデクスを付与する例で説明するが、他の情報をインデクスとしても良い。

ここで、例えば「あさひきねんびょういん」を検索した場合、施設名の検索結果として「朝日記念病院」が表示されることになる。また、施設読みからデータを特定しているため、「旭記念病院」など読みが同じ別の施設がある場合、検索結果には両方が表示される。

図３は、インデクスデータ群１０３に格納されるインデクスデータを概念的に示したものである。なお、インデクスデータの実際の構造については後に詳述する。図３において、インデクスデータは、概念的に見ると、キーワード３０１、キーワードを含む該当件数３０２、及びキーワードに続く候補文字３０３から構成される。１行目のインデクスデータは、入力するキーワードが「あ」である場合、施設読み２０２の先頭が「あ」であるようなデータの該当件数が「１０万件」であり、その「あ」に続く候補文字が「あ、く、さ、し、…」であることを示している。従って、施設読み２０２が先頭から「ああ…」や「あく…」の施設はあるが、「あい…」や「あう…」の施設はないことが分る。２行目以降のインデクスデータも同様である。例えば、４行目のインデクスデータは、入力するキーワードが「あさひき」である場合、施設読み２０２が先頭から「あさひき…」であるようなデータの該当件数が「２０件」で、それに続く候補文字が「ね、り」であることを示している。これにより、地図関連データ中には「あさひきね…」や「あさひきり…」という施設読みのデータが格納されていることが分る。なお、この例では濁点も１文字とみなしているため、例えば「びょういん」は候補文字「ひ」の下に続く文字列とされる。もちろん、「び」のように濁点も含めて１文字とみなすようなデータ構成であってもよい。

図４は、概念的に図３のように表されるインデクスデータを、実際のデータとしてどのように構成するかを示したインデクス構成図である。インデクスデータは、検索時に検索対象となるインデクスキー４０１、先頭文字からインデクスキーまでのキーワードを含む該当件数４０２、及びインデクスキーに続く次候補文字ビットマップ４０３から構成されている。例えば、「あさひ」に対してインデクスを付与する場合、インデクスキー４０１が「あ」のデータ、その「あ」から下位にチェーンされるインデクスキー４０１が「さ」のデータ、及び、その「さ」から下位にチェーンされるインデクスキー４０１が「ひ」のデータというように、３つのインデクスキーのデータに分け、それぞれの文字ごとに該当件数と次候補文字ビットマップを保持する。

なお、先頭文字の「あ」は最上位ノードであるルートとチェーンされており、検索の際にはルートから１文字ずつチェーンをたどっていくようにしている。また、該当件数が１件になった時点で、それ以降の文字については文字毎に分けてインデクスキーを持つ必要がないので、インデクスキー４０１をそれ以降そのキーワードの最後の文字までの文字列とし、該当件数４０２は１件とし、次候補文字ビットマップ４０３にはそのキーワードの地図関連データ群１０２上の位置を格納する。例えば、キーワードの先頭から「あさひきねん」であるようなデータは５件あるが、「あさひきねんひ」であるデータは１件しかなく、それは「あさひきねんびょういん」であるので、インデクスキー４０１が「ん」の下位に、インデクスキー４０１が「びょういん」であるインデクスデータをチェインしている。インデクスキー４０１が「びょういん」のデータの該当件数４０２は１件であり、次候補ビットマップ４０３には「あさひきねんびょういん」の地図関連データ群１０２上の位置（図４では単に０で埋めているが、実際には位置情報が入る）を格納している。該当件数が１件になった時点でそれ以降の文字を１つのインデクスキーとして管理することで、文字ごとにインデクスキーを保持する場合に比べてインデクス容量を削減することができる。

該当件数４０２は、先頭文字からインデクスキーまでのキーワードを含む該当件数を表している。図４では、「あ」、「さ」、「ひ」の該当件数はそれぞれ１０００００、１００００、５００になっているが、これは施設読み２０２が「あ」から始まるデータが１０万件、「あさ」から始まるデータが１万件、「あさひ」から始まるデータが５００件あることをそれぞれ表している。インデクスキーを文字ごとに管理しているため、キーワード「あさひ」に対してインデクスを付与する場合は、「あ」、「さ」、「ひ」それぞれに該当件数を加算する。

次候補文字ビットマップ４０３は、インデクスキーの文字の次にどの文字が候補文字として存在しているかを表している。次候補文字ビットマップ４０３は、バイト単位の配列で構成される。どの文字が候補文字として存在するかは、配列の中で次候補文字が存在する部分のビットを「１」にすることで管理している。１バイトは８ビットであるため、１バイトで８文字を管理でき、管理する文字の種類によって配列の長さを決定する。

図５は、次候補文字ビットマップの各ビットと文字との対応関係の例を示す。図５（ａ）はアルファベットの大文字のみを管理する場合の対応関係である。５０１は図４で説明した次候補文字ビットマップ４０３の先頭からのビット列を示し、５０２はそれらの各ビットに対応するアルファベットの大文字を示す。この例では文字ＡとＪのビットが１であり、他のビットは０である。従って、次候補文字としてＡとＪがあることが分る。この例はアルファベットの大文字のみを管理する例であるので、次候補文字ビットマップ５０１は２６個の文字を管理できれば良い。１バイトで８文字管理できるため、次候補文字ビットマップ５０１は４バイトの配列で構成される。

図５（ｂ）は、「あいうえお…」の５０音と数字を利用する場合の対応関係である。図４で説明した次候補文字ビットマップ４０３の先頭からの各ビットに、「あいうえお…」の５０音と数字を対応させている。図３や図４及びこれ以降の説明では、図５（ｂ）の対応関係の次候補文字ビットマップを利用する。従って、例えば図３から「あさひき」に続く候補文字は「ね、り」であるから、図４のように、インデクスキー「き」の次候補文字ビットマップは「ね」、「り」の部分だけのビットが「１」となっている。このように、管理する文字が多い場合は、それに応じてビットマップの配列を大きくすることで対応することができる。すなわち、管理する文字の数に応じてビットマップの配列の長さを決定する。

図６を用いてインデクスデータを更新する方法を説明する。例えば、図４の状態からインデクスデータに「あさひきこう」を追加したいとする。この場合、図４から「あ」、「さ」、「ひ」、「き」までの文字は、既にインデクスキー６０１が存在しているため、「あ」、「さ」、「ひ」、「き」の該当件数６０２にそれぞれ１加算する。また、「あ」、「さ」、「ひ」までは新たに追加すべき候補文字はないため、これらのインデクスキーの次候補ビットマップは更新する必要がない。次に、「き」に続く候補文字に「こ」は存在していなかったので、まずインデクスキー「き」の次候補ビットマップ６０３上の「こ」のビットを「１」に更新する。次に、新たにインデクスキーを追加するが、「こう」以降は該当件数が１であるため、「こう」は１つのインデクスキーとして、「き」の下位にチェインするように、追加する。「こう」の該当件数６０２は１件であり、次候補ビットマップ６０３には地図関連データ群１０２上の施設読み２０２が「あさひきこう」であるデータの位置が格納される。このようにしてインデクスを更新する。

図７を用いて、本実施形態の絞り込み検索を実装した情報検索装置の操作方法を説明する。図７は、表示部１０５に表示される検索画面の例を示す。検索画面は、入力した文字を表示する検索文字欄７０１、それらの検索文字を含む該当件数を表示する該当件数欄７０２、検索を実行しその検索結果の一覧の表示を指示する検索ボタン７０３、入力する文字を選択する文字入力部７０４、及び、検索結果の一覧を表示する検索結果一覧表示領域７０５から構成される。検索を行う前の状態では、検索文字欄７０１は空白、該当件数欄７０２は０、検索結果一覧表示領域７０５も空白になっている。

ユーザが文字入力部７０４で検索する文字を入力すると、検索文字欄７０１には、入力された文字が順に表示され、該当件数欄７０２には、検索文字欄７０１に表示されている検索文字を含む該当件数が表示される。その際、文字入力部７０４は、次候補文字が存在する文字部分のみ選択可能である。検索文字の入力を進め、該当件数が絞り込まれたら、ユーザは検索ボタン７０３を選択する。これにより、地図関連データ群１０２の検索が実行され、検索結果一覧表示領域７０５に、該当件数欄７０２に表示されている該当件数分の検索結果一覧が表示される。

例えば、図７のように「あさひきねん」を検索する場合、まず「あ」と入力すると、図３から「あ」に続く該当件数が１０万件、次候補文字が「あ、く、さ、し、た、ぬ、み、ら、わ」であることから、該当件数欄７０２には該当件数「１０万」が表示され、文字入力部７０４は「あ、く、さ、し、た、ぬ、み、ら、わ」のみが入力可能となる。これを繰り返し「あさひきねん」まで入力すると、該当件数欄７０２には「５」が表示され、文字入力部７０４は「か、こ、た、ひ、ふ」のみが入力可能となる。次に、検索ボタン７０３により検索を実行すると、検索結果一覧表示領域７０５には、「あさひきねん」を含む該当件数の５件分の検索結果一覧として、「朝日記念病院」、「朝日記念会館」、「朝日記念体育館」、「朝日記念文化会館」、及び「朝日記念公園」が表示される。

以下、以上のように構成された情報検索装置の動作を説明する。

図８は、本情報検索装置における動作の概要を示すフローチャートである。本フローチャートは、ユーザの動作と本装置の動作の両方の流れを示したものである。まず、ユーザは文字入力部７０４で検索する文字を入力する（ステップ８０１）。本装置は、入力された文字を元にインデクスデータ群１０２から該当件数と次に続く次候補文字を検索し、該当件数を該当件数欄７０２に表示し、文字入力部７０４がその次候補文字のみ入力可能になるように制御する（ステップ８０２）。次に、ユーザは該当件数欄７０２の結果から該当件数が絞りこまれたか判断する（ステップ８０３）。該当件数が未だ多いと判断した場合、ユーザは再び文字入力部７０４で検索する文字を追加し再検索する。該当件数が十分絞り込まれた場合、ユーザは検索ボタン７０３を選択する。本装置は、その検索実行の指示に応じて、地図関連データ群１０２にアクセスし、検索結果一覧を検索結果一覧表示領域７０５に表示する（ステップ８０４）。

図９は、図８の流れを実現する情報検索装置の処理の概要を示すフローチャートである。ユーザの所定の操作で検索の開始が指示されると、本装置は、まず初期状態の検索画面（図７）を表示するとともに、インデクスデータ群１０３を検索し（ステップ９０１）、該当件数と次候補文字ビットマップを取得する（ステップ９０２）。検索の開始が指示された時点では、１文字も入力されていないので、ステップ９０１，９０２は、ルートインデクスを参照して該当件数と次候補文字ビットマップを取得する処理となる。該当件数は該当件数欄７０２に表示する。なお、このときの該当件数は全データ数となり大きすぎるので、該当件数が所定数以上の場合のみ該当件数欄７０２に表示することとしてもよい。また取得した次候補文字ビットマップに基づいて、文字入力部７０４でその次候補文字のみが入力可能になるように制御する。

次に、ユーザによる指示操作を判別する（ステップ９０３）。検索文字の追加があった場合は、そこまでに検索されているインデクスキーの下位に、当該入力した文字のインデクスキーが存在するかを判定する（ステップ９０４）。存在しなかった場合は、検索終了（検索終了とする代わりにステップ９０３に戻って再びユーザの指示操作を待っても良い）となる。存在していた場合、その下位インデクスにアクセスし（ステップ９０５）、ステップ９０１に戻る。ステップ９０３でユーザが検索文字を１文字削除（バックスペース）した場合は、現在までに検索されているインデクスの上位インデクスにアクセスし（ステップ９０６）、ステップ９０１に戻る。

ステップ９０３で検索ボタン７０３が押下された場合は、地図関連データ群１０２にアクセスし（ステップ９０７）、該当するデータを取得し、検索結果一覧表示領域７０５に表示する（ステップ９０８）。なお、ステップ９０７の処理では、そこまでに検索されているインデクスの該当件数１件である場合は、そのインデクスの次候補文字ビットマップの欄から該当データの地図関連データ群１０２上の位置を取得し、該当データを取得する。また、そこまでに検索されているインデクスの該当件数が複数件である場合は、そのインデクスから下位にインデクスをたどり、該当件数１件のインデクスまで取得し、そのインデクスが指す該当データを全て取得する。

図１０を用いて、実際の検索処理の流れを説明する。図１０は、「あさひきねんびょういん」に対するインデクス構成図であり、インデクスキーのルート１００１、「あ」に対するインデクスキー１００２、「さ」に対するインデクスキー１００３、…、「ん」に対するインデクスキー１００４、及び「びょういん」に対するインデクスキー１００５から構成される。インデクスキー１００５の次候補文字ビットマップ欄の位置情報に基づいて、地図関連データ群１００６内の「あさひきねんびょういん」のデータ（図２）を取得できる。

ルート１００１は、インデクスの一番上位のキーである。このルートキー１００１も、該当件数と次候補文字ビットマップを保持している。検索開始時は、まずこのルートインデクス１００１から、該当件数と次候補文字を求める。ルート１００１とインデクスキー１００２、インデクスキー１００２とインデクスキー１００３のように、上位と下位のインデクスはそれぞれチェーンで繋がっており、検索時は上位と下位、双方向へのアクセスが可能となっている。また、「びょういん」のインデクスキー１００５は、これ以降のキーが存在しないため、次候補文字ビットマップは保持しておらず、その代わりに地図関連データ群１００６上の当該データ「あさひきねんびょういん」の格納位置を保持している。つまり、一番下位のキーが地図関連データ群１００６の格納位置を保持しているため、インデクスにアクセスすることで地図関連データ群１００６の中から検索条件に該当するデータを得ることができる。

例えば、「あさひきねんびょういん」を検索する場合、検索開始時はルート１００１のインデクスを参照し、図９のステップ９０１，９０２，９０３が実行される。次にユーザにより「あ」が入力されると、ステップ９０３からステップ９０４に処理が移る。入力された文字が存在しているどうかは、インデクス１００１のビットマップを参照し、入力文字「あ」のビットが「１」かどうかで判定する。この場合、「あ」は存在しているので、ステップ９０５で下位の「あ」のインデクスキー１００２の情報を参照し、再びステップ９０１から９０３までの処理が実行される。次にユーザにより「さ」が入力された場合も同様の処理が行なわれ、今度はインデクスキー１００３の情報を参照する。このように文字が入力されるごとに下位のインデクスを参照していく。

「あさ」まで入力した時点では、インデクスキー１００３の情報を参照している。ここで、ユーザが「さ」を削除した場合、ステップ９０３から９０６に処理が移り、インデクスはそれぞれ上位と下位のチェーンを持っているため、インデクスキー１００３から上位インデクスへ戻り、インデクスキー１００２の情報を参照する。このように文字が削除されるごとに上位のインデクスを参照する。

「あさひきねん」まで入力した時点では、インデクスキー１００４を参照している。次にユーザが検索ボタン７０３を押下すると、ステップ９０７の処理により、インデクスキー１００４に繋がっている下位のインデクス全てを参照する。「あさひきねんびょういん」を参照する場合は、一番下位のインデクスキー１００５「びょういん」を参照すると、地図関連データの格納位置が分かるため、地図関連データベースにアクセスし、施設名の検索結果として「朝日記念病院」が表示される。

以上のような本実施形態の絞り込み検索方式はＤＢＭＳで実装することもできる（もちろんインデクスのデータ構造は上述した構造とする）。その場合、まず、検索するキーワードに該当する上位インデクスのみを参照し、該当件数と次候補文字ビットマップを返却するインターフェースを、ＤＢＭＳに実装する。次に、キーワードに該当する文字を検索する場合は、下位のインデクスを参照し、地図関連データ群から該当するデータを検索する。

この方法を実施する例として、ここでは、例えば、ＳＱＬで使用する表名を「施設データ」、列名を「施設読み」とすると、まず、次のＳＱＬを実行する。
SELECT * FROM 施設データ WHERE 施設読み LIKE '%'
このＳＱＬを実行した直後は、インデクスのルートを参照する状態となる。次に、'あ'、'さ'のように文字が入力されている間は、文字が入力されるたびに下位のインデクスを参照していき、該当件数と次候補文字を求める。入力文字なしで実行した場合には、キーワードに該当する全ての文字を検索する。このような方法により、本発明を適用した絞り込み検索をＤＢＭＳで実装できる。

図１１は、図３，４，１０などで説明したインデクスの更新処理の概要を示すフローチャートである。更新処理では、まず、インデクスデータに追加するデータを１文字ずつに分解し（ステップ１１０１）、分解した各文字を処理対象として順にステップ１１０３以降の追加処理を行なう。まず、ルートの該当件数に１を加算し（ステップ１１０２）、分解した文字のうちの先頭文字を処理対象として、ルートの下位に、その文字のインデクスキーが既に存在しているかを判定する（ステップ１１０３）。なお、ステップ１１０３以降の追加処理では所定のインデクスキーを参照するが、それを参照対象のインデクスキーと呼ぶ。ステップ１１０２から１１０３に進む時点では、ルートのインデクスキーが参照対象のインデクスキーである。

ステップ１１０３では、参照対象のインデクスキーの次候補文字ビットマップを参照し、その下位に、処理対象の文字のインデクスキーが存在するか否か判定する。存在しなかった場合、その処理対象の文字以降の文字については１つのインデクスキーとすれば良いから、処理対象の文字以降の文字（処理対象の文字を含む）をまとめて１つのインデクスキーにする（ステップ１１０４）。次に、参照対象のインデクスキーの次候補文字ビットマップの、ステップ１１０４で１つのインデクスキーにした文字列の先頭文字に対応するビットを、１に更新する（ステップ１１０５）。さらに、ステップ１１０４で作成したインデクスキーを新たなインデクスキーとして、参照対象のインデクスキーの下位にチェインするように追加する（ステップ１１０６）。この場合、追加したインデクスキーの該当件数には１を設定し、その次候補文字ビットマップの欄には当該追加データの地図関連データ群１０２内の位置を設定し（ステップ１１０７）、更新終了とする。

ステップ１１０３で参照対象のインデクスキーの下位に処理対象の文字のインデクスキーが既に存在していた場合、まず、その処理対象の文字のインデクスキーの該当件数に１を加算し（ステップ１１０８）、そのインデクスキー長が１かどうか判定する（ステップ１１０９）。キー長が１の場合は、キーを分解する必要がないので、残りの文字（すなわち、いま処理対象としている文字の次の文字）があるか判定する（ステップ１１１４）。残りの文字がある場合、その文字を新たに処理対象の文字とし、ステップ１１０８で該当件数に１を加算したインデクスキーを新たに参照対象のインデクスキーとして、ステップ１１０３から再実行する。ステップ１１１４で残りの文字がない場合は、更新終了とする。

ステップ１１０９でキー長が１でない場合、処理対象の文字以降の文字列と、ステップ１１０３で既に存在していたインデクスキーとが、全て一致しているか判定する（ステップ１１１０）。全て一致していた場合は、更新終了とする。残りのキーのどれかが一致してない場合（この場合は、先頭から部分的に一致し、それ以降が不一致）は、まず、既に存在しているキーの先頭部分（一致部分）のみを分解する（ステップ１１１１）。次に、分解したインデクスキーのビットマップを更新し（ステップ１１１２）、分解した残りのキー（後半の不一致部分）を新たなインデクスキーとして追加する（ステップ１１１３）。最後に、残りのキーがあるか判定し（ステップ１１１４）、残りのキーが存在している場合は、ステップ１１０３から処理を繰り返し、残りのキーがない場合は、更新終了となる。

ここでは、例えば、図１０のインデクスに対して「あさひきこう」を追加する場合、まず、「あ」、「さ」、「ひ」、「き」、「こ」、「う」に分解する。「あ」を追加する場合、まず、ルートの該当件数に１加算する。インデクスキー「あ」は、既に存在しているので該当件数に１を加算し、キー長は１であるので、次の「さ」を追加する処理に移る。これを繰り返していき、「こ」を追加する処理になった場合、まず、「き」の該当件数に１を加算する。次に、「き」の下位のインデクスキーには「こ」のインデクスキーは存在していないので、「こ」と「う」を一つのインデクスキーにする。次に、「き」のインデクスのビットマップを更新し、新たなインデクスキー「こう」を追加し、該当件数には１を設定する。このようにしてインデクスは更新される。

なお、上記実施形態では同じインデクス（同じ施設読み）のデータが複数有るケースを省略したが、その場合は、最下位のインデクスの該当件数を２件とし、次候補ビットマップからそれら２件のデータにアクセスできるようにし、参照するインデクスが最下位のものであることが分るようにすればよい。

本発明の一実施の形態例を示すシステム構成図である。 地図関連データベースに格納されているデータ構成図である。 インデクスデータベースに格納するデータ構成図である。 インデクスデータ構成図である。 次候補文字ビットマップの構成図である。 更新後のインデクスデータ構成図である。 検索画面の一例である。 絞り込み検索処理を示すフローチャートである。 インデクスデータ群、及び地図関連データ群を検索する処理を示すフローチャートである。 インデクス構成図である。 インデクスの更新処理の概要を示すフローチャートである。 従来の絞り込み検索の概略構成図である。

符号の説明

１０１…検索画面、１０２…地図関連データ群、１０３…インデクスデータ群、１０４…入力部、１０５…表示部、７０１…検索文字表示部、７０２…該当件数表示部、７０３…検索処理実行部、７０４…検索文字入力部、７０５…検索結果一覧表示部。

Claims (5)

1. 所定のキーワード文字列を有するデータに対して、キーワードの先頭から検索する文字を１文字づつ入力し、目的とするデータを絞り込みながら検索する絞り込み検索用のインデクス構造であって、
   検索対象として登録するデータのキーワード文字列を文字毎に分解し、それらの各文字毎のインデクスキーを、ルートから順に下位方向にチェインで繋げ、各文字のインデクスキーに対応して、先頭からそのインデクスキーの文字までの文字列に前方一致するデータ件数と、その次に続くことが可能な文字である次候補文字情報とを備えるようにしたことを特徴とする絞り込み検索用のインデクス構造。
2. 請求項１に記載の絞り込み検索用のインデクス構造において、
   登録するデータのキーワード文字列をインデクスキーとして登録するとき、ある文字以降は１つのキーワード文字列の並びしか可能性がないときには、文字毎のインデクスキーとする代わりに、複数文字のインデクスキーとすることを特徴とする絞り込み検索用のインデクス構造。
3. 請求項１または２に記載の絞り込み検索用のインデクス構造において、
   前記次候補文字情報は、インデクスキーになる可能性のある文字の種類数分のビットからなるビット情報で表現されていることを特徴とする絞り込み検索用のインデクス構造。
4. 請求項１から３の何れか１つに記載の絞り込み検索用のインデクス構造を利用した情報検索装置において、
   検索を行うユーザアプリケーションから１文字ずつ入力された文字に対して、前記インデクスキーをルートから順に辿り、そこまでに入力された文字を先頭から持つデータのデータ件数と、次に検索候補となる次候補文字情報を返却するユーザアプリケーションインターフェースを備えたことを特徴とする情報検索装置。
5. 請求項４に記載の情報検索装置において、
   検索する文字が１文字ずつ入力されていった途中でユーザから検索実行指示があったとき、ルートから辿っていってその時点で行き着いているインデクスキーからさらに下位にインデクスキーを辿り、最終的に絞り込まれた目的とするデータを抽出することを特徴とする情報検索装置。

Images