(57)【要約】【課題】検索結果をドルダウンする場合の検索キーの指定順序を自由にする。検索時に指定できる検索キーの個数を増やす。【解決手段】コンバータ１０４は、多数のデータアイテムに対する検索方法を定義した検索方法定義ファイル１６０を読み、多数のデータアイテムにそれぞれ関連付けられた多数のサーチ用ファイル１２２、１２２、…を作成し保存する。各サーチ用ファイル１２２のファイル名は、各データアイテムに関する複数のキーアイテム（又はそれらの識別符号）を連結した文字列である。検索エンジン１０２は、ユーザにより指定された検索キーにマッチするファイル名を、サーチ用ファイル１２２、１２２、…の母群１２３から検索する。異なる検索キーで検索結果を段階的に絞り込む場合、各段階にて、今段階と以前の段階で指定された検索キーの全てにマッチするファイル名を、ファイル名母群１２３から検索する。【選択図】図２
2009093405.tif 000002
【特許請求の範囲】
【請求項１】
多数のデータアイテムの中から、検索キーにマッチするデータアイテムを検索するためのシステムにおいて、
多数のデータアイテムにそれぞれ関連付けられた多数の文字列からなる文字列母群を保存する保存手段であって、前記文字列母群内の各文字列は、各データアイテムに関する複数のカテゴリにそれぞれ属する複数のキーアイテムを連結したもの又は前記複数のキーアイテムの識別符号を連結したものを含む、前記保存手段と、
前記文字列母群に含まれるキーアイテムの中から、ユーザの選択に従って、検索キーを選択する第１の検索キー選択手段と、
前記選択された検索キーにマッチする文字列を前記文字列母群の中から検索するための検索要求を発行する検索手段と、
前記検索要求に対する検索結果として得られた検索された文字列の中から、前記ユーザにより指定されたカテゴリに属するキーアイテムを抽出し、前記抽出されたキーアイテムを表示するキーアイテム表示手段と、
前記表示されたキーアイテムの中から、前記ユーザの選択に従って、次の検索キーを選択して、前記選択された次の検索キーと前記第１の検索キー選択ステップにより選択された検索キーとの双方にマッチする文字列を前記文字列母群の中から検索するための検索要求を発行するよう、前記検索手段を再び動作させる第２の検索キー選択手段と
を備え、
前記第２の検索キー選択手段は、前記ユーザの選択の繰り返しに従って複数回繰り返して動作し、各回において、今回選択された次の検索キーと以前の回で選択された検索キーと前記第１の検索キー選択ステップにより選択された検索キーとの全部にマッチする文字列を前記文字列母群の中から検索するための検索要求を発行するよう、前記検索手段を再び動作させる、データ検索のためのシステム。
【請求項２】
多数のデータアイテムの中から、検索キーにマッチするデータアイテムを検索するための方法において、
多数のデータアイテムにそれぞれ関連付けられた多数の文字列からなる文字列母群を保存する保存ステップであって、前記文字列母群内の各文字列は、各データアイテムに関する複数のカテゴリにそれぞれ属する複数のキーアイテムを連結したもの又は前記複数のキーアイテムの識別符号を連結したものを含む、前記保存ステップと、
前記文字列母群に含まれるキーアイテムの中から、ユーザの選択に従って、検索キーを選択する第１の検索キー選択ステップと、
前記選択された検索キーにマッチする文字列を前記文字列母群の中から検索するための検索要求を発行する検索ステップと、
前記検索要求に対する検索結果として得られた検索された文字列の中から、前記ユーザにより指定されたカテゴリに属するキーアイテムを抽出して表示するキーリスト表示ステップと、
前記表示されたキーアイテムの中から、前記ユーザの選択に従って、次の検索キーを選択して、前記選択された次の検索キーと前記第１の検索キー選択手段により選択された検索キーとの双方にマッチする文字列を前記文字列母群の中から検索するための検索要求を発行するよう、前記検索手段を再び動作させる第２の検索キー選択ステップと、
手段とする第２の検索キー選択ステップと、
前記ユーザの選択の繰り返しに従って、前記第２の検索キー選択ステップを複数回繰り返し、各回において、今回選択された次の検索キーと以前の回で選択された検索キーと前記第１の検索キー選択手段により選択された検索キーとの全部にマッチする文字列を前記文字列母群の中から検索するための検索要求を発行するよう、前記検索手段を再び動作させる繰り返しステップと
を有するデータ検索のための方法。
【請求項３】
多数のデータアイテムの中から、検索キーにマッチするデータアイテムを検索するための方法を、コンピュータに実行させるためのコンピュータプログラムにおいて、前記方法が、
多数のデータアイテムにそれぞれ関連付けられた多数の文字列からなる文字列母群を保存する保存ステップであって、前記文字列母群内の各文字列は、各データアイテムに関する複数のカテゴリにそれぞれ属する複数のキーアイテムを連結したもの又は前記複数のキーアイテムの識別符号を連結したものを含む、前記保存ステップと、
前記文字列母群に含まれるキーアイテムの中から、ユーザの選択に従って、検索キーを選択する第１の検索キー選択ステップと、
前記選択された検索キーにマッチする文字列を前記文字列母群の中から検索するための検索要求を発行する検索ステップと、
前記検索要求に対する検索結果として得られた検索された文字列の中から、前記ユーザにより指定されたカテゴリに属するキーアイテムを抽出して表示するキーリスト表示ステップと、
前記表示されたキーアイテムの中から、前記ユーザの選択に従って、次の検索キーを選択して、前記選択された次の検索キーと前記第１の検索キー選択手段により選択された検索キーとの双方にマッチする文字列を前記文字列母群の中から検索するための検索要求を発行するよう、前記検索手段を再び動作させる第２の検索キー選択ステップと、
手段とする第２の検索キー選択ステップと、
前記ユーザの選択の繰り返しに従って、前記第２の検索キー選択ステップを複数回繰り返し、各回において、今回選択された次の検索キーと以前の回で選択された検索キーと前記第１の検索キー選択手段により選択された検索キーとの全部にマッチする文字列を前記文字列母群の中から検索するための検索要求を発行するよう、前記検索手段を再び動作させる繰り返しステップと
を有する、データ検索のためのコンピュータプログラム。
【請求項４】
請求項３記載のコンピュータプログラムにおいて、
前記保存ステップは、前記多数のデータアイテムに関連付けられた多数のサーチ用ファイルを保存するステップを含み、
前記保存された多数のサーチ用ファイルの各々のファイル名に、前記多数の文字列の各々が組み込まれている、データ検索のためのコンピュータプログラム。
【請求項５】
請求項４記載のコンピュータプログラムにおいて、
前記検索ステップは、前記各回において、
今回選択された次の検索キーと、以前の回で選択された検索キーと、前記第１の検索キー選択手段により選択された検索キーと、他のカテゴリの未選択の検索キーの代用としてのワイルドカードとを連結してなる検索ファイル名を作成するステップと、
前記作成された検索ファイル名にマッチする前記サーチ用ファイルのファイル名を検索するための検索要求を発行するステップと
を含む、データ検索のためのコンピュータプログラム。
【請求項６】
請求項５記載のコンピュータプログラムにおいて、
各サーチ用ファイルのファイル名に組み込まれた前記各文字列では、各キーアイテム又は前記各キーアイテムの識別符号が所定の区切り文字により両側から挟まれるようにして、前記複数のキーアイテム又は前記複数のキーアイテムの識別符号が連結されるとともに、前記複数のキーアイテム又は前記複数のキーアイテムの識別符号を連結したものの先頭と末尾にそれぞれ所定の接頭文字と接尾文字が付加されている、データ検索のためのコンピュータプログラム。
【請求項７】
請求項４〜６のいずれか一項記載のコンピュータプログラムにおいて、
各サーチ用ファイルには、各データアイテムの参照情報が格納されている、データ検索のためのコンピュータプログラム。
【請求項８】
請求項３記載のコンピュータプログラムにおいて、
前記保存ステップは、キーアイテムリストファイルを保存するステップを含み、
前記保存されたキーアイテムリストファイル内に、前記多数の文字列が互いに区別されて格納されている、データ検索のためのコンピュータプログラム。
【請求項９】
請求項３〜８のいずれか一項記載のコンピュータプログラムにおいて、
前記各文字列は、前記各データアイテムに関する前記複数のキーアイテムの識別符号を連結したものを含み、
各キーアイテムの識別符号は、前記各キーアイテムを構成する文字の各々の文字コードを、M進数（Mは２より大きい数）を表す文字列に変換したものである、データ検索のためのコンピュータプログラム。
【請求項１０】
請求項３〜８のいずれか一項記載のコンピュータプログラムにおいて、
前記方法が、前記多数のデータアイテムに関する多数のキーアイテムが登録された中間テーブルファイルを保存するステップを、更に有し、
前記各文字列は、前記各データアイテムに関する前記複数のキーアイテムの識別符号を連結したものを含み、
各キーアイテムの識別符号は、前記中間テーブルファイル上で前記各キーアイテムを識別するための符号である、データ検索のためのコンピュータプログラム。
【請求項１１】
請求項１０記載のコンピュータプログラムにおいて、
前記各キーアイテムの識別符号は、前記中間テーブルファイル上での前記各キーアイテムの位置を特定するための符号である、データ検索のためのコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、高速にデータの検索を行なうためのシステム、方法及びコンピュータプログラムに関する。
【背景技術】
【０００２】
従来の一般的なデータベースにおいては、データベースの構築時に、検索キーとして使用される予定の複数のキーアイテムを登録したインデックステーブルが、検索対象のデータ項目（以下、データアイテムという）を格納したファイルとは別途に作成される。検索キーを用いた目的ファイルのサーチは、そのインデックステーブル上で行われ、それによる検索速度は速い。しかし、インデックステーブルに登録されていないキーアイテムを検索キーとして用いて検索を行う場合は、全てのデータアイテムファイルを開いて全てのデータアイテムを読み出し、それらのデータアイテムと検索キーとの比較を行う必要があるため、きわめて検索速度が遅くなる。従って、従来のデータベースでは、高速に検索を行なうためには、事前に作成されたインデックステーブルに登録されたキーアイテムの範囲内で検索キーを選択せざるを得ない。
【０００３】
また、ドリルダウンと呼ばれる検索結果のデータアイテム群の段階的な絞り込みを行う場合（例えば、まず、カテゴリ「県」の検索キー「神奈川県」を指定してマッチするデータアイテム群を検索し、次に、カテゴリ「市」の検索キー「横浜市」を指定してそのデータアイテム群を絞り込むというように、カテゴリの異なる複数の検索キーを順次に指定することで検索結果のデータアイテム群を段階的に絞り込んでいく場合）、それぞれのカテゴリの検索キーを指定できる順序は、データベース構築時に作成されたインデックステーブルの構造に依存して制限的に決められる（例えば、カテゴリ「県」の検索キーを指定して検索した後でないと、カテゴリ「市」の検索キーが指定できない）。このような検索キーの指定順序を変更するためには、インデックステーブルの構造を変更する必要がある。インデックステーブルの構造を変更するとは、すなわち、改めてテーブル定義を変更し、データベースを再構築することを意味する。
【０００４】
このようなインデックステーブルの作成の労力を省くために、例えば特許文献１には、検索対象の各ファイルの内容を体系化されたコード（例えば、複数のキーアイテムをそれぞれ示すコードを所定順序で連結したもの）で表現し、そのコードをファイル名として各ファイルに付与し、そして、検索キーを用いてファイル名のサーチを行うことで目的ファイルを検索する方法が開示されている。
【０００５】
また、特許文献２には、検索対象の各画像ファイルがもつ複数の属性を所定順序で連結したものを、ファイル名として各画像ファイルに付与するとともに、その画像ファイルが保存されたディレクトリのディレクトリ名にも、上記複数の属性の少なくとも一部を含ませ、そして、検索時には、利用者から指定された特定の属性の検索キーに基づいて検索用パス名と検索用ファイル名を作成し、その検索用パス名と検索用ファイル名を用いてディレクトリ名とファイル名をサーチすることで、目的ファイルを検索する方法が開示されている。
【０００６】
このように、ファイル名やディレクトリ名にキーアイテムを含ませる検索方法によれば、インデックステーブルに頼らずに目的ファイルを高速に検索することが可能である。
【０００７】
【特許文献１】特開２００３−６０１４号公報
【特許文献２】特開２００６−１０６９２２号公報
【発明の開示】
【発明が解決しようとする課題】
【０００８】
しかし、上述した検索結果をドリルダウンする場合の検索キーの指定順序の制限の問題に関しては、特許文献１，２は明確な解決策を提供していない。
【０００９】
また、コンピュータのOSが取り扱えるファイル名の長さには限界があるため、１つのファイル名に組み込むことができるキーアイテムの個数が制限される。その結果、検索時に指定できる検索キーの個数が制限される。
【００１０】
従って、本発明の一つの目的は、検索結果をドルダウンする場合における検索キーの指定順序が自由に変更できるようにすることにある。
【００１１】
別の目的は、検索時に指定できる検索キーの個数を増やすことにある。
【課題を解決するための手段】
【００１２】
本発明の一つの側面に従う、多数のデータアイテムの中から、検索キーにマッチするデータアイテムを検索するためのシステムは、
多数のデータアイテムにそれぞれ関連付けられた多数の文字列からなる文字列母群を保存する保存手段であって、前記文字列母群内の各文字列は、各データアイテムに関する複数のカテゴリにそれぞれ属する複数のキーアイテムを連結したもの又は前記複数のキーアイテムの識別符号を連結したものを含む、前記保存手段と、
前記文字列母群に含まれるキーアイテムの中から、ユーザの選択に従って、検索キーを選択する第１の検索キー選択手段と、
前記選択された検索キーにマッチする文字列を前記文字列母群の中から検索するための検索要求を発行する検索手段と、
前記検索要求に対する検索結果として得られた検索された文字列の中から、前記ユーザにより指定されたカテゴリに属するキーアイテムを抽出し、前記抽出されたキーアイテムを表示するキーアイテム表示手段と、
前記表示されたキーアイテムの中から、前記ユーザの選択に従って、次の検索キーを選択して、前記選択された次の検索キーと前記第１の検索キー選択手段により選択された検索キーとの双方にマッチする文字列を前記文字列母群の中から検索するための検索要求を発行するよう、前記検索手段を再び動作させる第２の検索キー選択手段と
を備え、
前記第２の検索キー選択手段は、前記ユーザの選択の繰り返しに従って複数回繰り返して動作し、各回において、今回選択された次の検索キーと以前の回で選択された検索キーと前記第１の検索キー選択手段により選択された検索キーとの全部にマッチする文字列を前記文字列母群の中から検索するための検索要求を発行するよう、前記検索手段を再び動作させる。
【００１３】
本発明の別の側面に従う、多数のデータアイテムの中から、検索キーにマッチするデータアイテムを検索するための方法は、
多数のデータアイテムにそれぞれ関連付けられた多数の文字列からなる文字列母群を保存する保存ステップであって、前記文字列母群内の各文字列は、各データアイテムに関する複数のカテゴリにそれぞれ属する複数のキーアイテムを連結したもの又は前記複数のキーアイテムの識別符号を連結したものを含む、前記保存ステップと、
前記文字列母群に含まれるキーアイテムの中から、ユーザの選択に従って、検索キーを選択する第１の検索キー選択ステップと、
前記選択された検索キーにマッチする文字列を前記文字列母群の中から検索するための検索要求を発行する検索ステップと、
前記検索要求に対する検索結果として得られた検索された文字列の中から、前記ユーザにより指定されたカテゴリに属するキーアイテムを抽出して表示するキーリスト表示ステップと、
前記表示されたキーアイテムの中から、前記ユーザの選択に従って、次の検索キーを選択して、前記選択された次の検索キーと前記第１の検索キー選択ステップにより選択された検索キーとの双方にマッチする文字列を前記文字列母群の中から検索するための検索要求を発行するよう、前記検索手段を再び動作させる第２の検索キー選択ステップと、
手段とする第２の検索キー選択ステップと、
前記ユーザの選択の繰り返しに従って、前記第２の検索キー選択ステップを複数回繰り返し、各回において、今回選択された次の検索キーと以前の回で選択された検索キーと前記第１の検索キー選択ステップにより選択された検索キーとの全部にマッチする文字列を前記文字列母群の中から検索するための検索要求を発行するよう、前記検索手段を再び動作させる繰り返しステップと
を有する。
【００１４】
本発明のまた別の側面に従うコンピュータプログラムは、上述した検索方法をコンピュータに実行させるものである。
【００１５】
上述した本発明のデータ検索のためのシステム、方法及びコンピュータプログラムのそれぞれによれば、検索結果をドルダウンする場合における検索キーの指定順序が自由に変更できる。
【００１６】
本発明の好適な一つの実施形態によれば、前記多数のデータアイテムに関連付けられた多数のサーチ用ファイルが保存される。保存された多数のサーチ用ファイルの各々のファイル名に、前記多数の文字列の各々が組み込まれている。そして、検索キーが選択された各回において、今回選択された次の検索キーと、以前の回で選択された検索キーと、最初に選択された検索キーと、他のカテゴリの未選択の検索キーの代用としてのワイルドカードとを連結してなる検索ファイル名が、作成される。そして、作成された検索ファイル名にマッチする前記サーチ用ファイルのファイル名を検索するための検索要求が、発行される。
【００１７】
この構成によれば、コンピュータのOSが提供するファイル名検索の機能を利用して所望のデータアイテムが検索できるので、検索速度が高速である。
【００１８】
上記実施形態によれば、さらに、各サーチ用ファイルのファイル名に組み込まれた前記各文字列では、各キーアイテム又は前記各キーアイテムの識別符号が所定の区切り文字により両側から挟まれるようにして、前記複数のキーアイテム又は前記複数のキーアイテムの識別符号が連結されるとともに、前記複数のキーアイテム又は前記複数のキーアイテムの識別符号を連結したものの先頭と末尾にそれぞれ所定の接頭文字と接尾文字が付加されている。
【００１９】
この構成によると、選択された検索キーとワイルドカードを連結して検索ファイル名を作成する時に、検索ファイル名の先頭と末尾に必ずワイルドカードを付けることができ、その結果、マッチするファイル名をサーチするときに、検索ファイル名内の検索キーが先頭又は末尾かどうかをチェックする手間が省け、検索速度が向上する。
【００２０】
またさらに、上記実施形態によれば、各サーチ用ファイルには、各データアイテムの参照情報を格納することができる。それにより、各データアイテム自体は、サーチ用ファイルからは分離して、コンピュータ内外の任意の場所に存在することができる。
【００２１】
本発明の別の好適な実施形態によれば、キーアイテムリストファイルが保存され、その保存されたキーアイテムリストファイル内に、前記多数の文字列が、互いに区別されて格納される。この構成によれば、（前述のようにサーチ用ファイルのファイル名に、前記複数のキーアイテム又はそれらの識別符号を連結してなる文字列を組み込んだ場合には、ファイル名の長さの限界により、ファイル名に組み込めるキーアイテムの個数、つまり指定できる検索キーの個数が制限されるのに対し）、ファイル名の長さの限界により指定できる検索キーの個数が制限されるという問題はない。
【００２２】
上記いずれの実施形態においても、前記各文字列が、前記各データアイテムに関する前記複数のキーアイテムの識別符号を連結したものを含む場合には、各キーアイテムの識別符号として、前記各キーアイテムを構成する文字の各々の文字コードを、M進数（Mは２より大きい数）を表す文字列に変換したものを採用することができる。或いは、別の方法として、前記多数のデータアイテムに関する多数のキーアイテムが登録された中間テーブルファイルを用意し、そして、各キーアイテムの識別符号として、前記中間テーブルファイル上で前記各キーアイテムを識別するための符号を採用してもよい。後者の方法においては、前記各キーアイテムの識別符号として、例えば、前記中間テーブルファイル上での前記各キーアイテムの位置を特定するための符号を用いることができる。
【００２３】
このような方法により、キーアイテム自体ではなく、キーアイテムの識別符号を使用して上記文字列を構成することにより、各キーアイテム（検索キー）を表記する文字数が減る可能性が高いので、指定できる検索キーの個数が増大する。
【発明を実施するための最良の形態】
【００２４】
以下、図面を参照して、本発明の好適な実施形態を説明する。
【００２５】
図１は、本発明の第１の実施形態にかかる検索システムの全体構成を示す。
【００２６】
本実施形態にかかる検索システム１００は、（必ずしもそうでなければならないわけではないが）典型的にはコンピュータプログラムにより実装され、１または複数のコンピュータにより実行される。図１に示すように、検索システム１００は、検索エンジン１０２とコンバータ１０４を有する。
【００２７】
検索エンジン１０２は、ファイル名検索の方法を用いて、多数のデータアイテムの中から、特定のデータアイテムを検索する機能をもつ。すなわち、検索エンジン１０２は、図１に矢印で示されるように、ユーザから指定された検索キーを入力し（処理１３０）、指定された検索キーにマッチするファイル名の検索要求をコンピュータのOSのファイルシステム１１０へ送り（処理１３２）、そのファイル名検索の検索結果（検索されたファイル名）のリストをファイルシステム１１０から受け取り（処理１３４）、そして、その受け取った検索結果リストに基づいてユーザに提示すべき所定情報の表示を作成してコンピュータの表示装置へ表示する（処理１３６）。ここで、処理１３６で表示されるユーザに提示すべき所定情報とは、例えば、ユーザが次の検索キーとして指定することができるキーアイテムのリストである。
【００２８】
コンバータ１０４は、上述したファイル名検索の対象であるファイル１２２，１２２,…（以下、サーチ用ファイルという）の群からなるデータベース１２６を、ストレージ装置１２０内に自動的に生成する機能をもつ。すなわち、コンバータ１０４は、図１に矢印で示すように、多数のデータアイテムに関する検索方法（例えば、何のカテゴリの何のキーアイテムが、検索キーとして指定できるか）を定義した検索方法定義情報を入力し（処理１４０）、入力された検索方法定義情報に基づいて、上記多数のデータアイテムにそれぞれ関連付けられた多数のサーチ用ファイル１２２，１２２,…を自動的に生成し、そして、生成されたサーチ用ファイル１２２，１２２,…を、ファイルシステム１１０を介して、ストレージ装置１２０の所定ディレクトリに保存する（処理１４０，１４２）。上述した検索エンジン１０２によるファイル名検索が実行されるより前に、準備作業として、コンバータ１０４により自動的に（又は、ユーザの手動入力により）、サーチ用ファイル１２２，１２２,…が、ストレージ装置１２０内に保存されている必要がある。
【００２９】
検索エンジン１０２が実行されるコンピュータと、コンバータ１０４が実行されるコンピュータと、ストレージ装置１２０を管理するコンピュータとは、同じマシンであっても、異なるマシンであってもよい。
【００３０】
サーチ用ファイル１２２，１２２,…の各々は、ユーザにとっての最終的な検索対象である複数のデータアイテムの各々に関連付けられている。本実施形態では、一例として、各データアイテムは、各ファイル１２２の内容それ自体又はその内容の一部である。従って、各ファイル１２２を開くことで、ユーザは各データアイテムにアクセスすることができる。或いは、変形例として、各データアイテムそれ自体ではなく、各データアイテムの参照情報が、各ファイル１２２の内容それ自体又はその内容の一部であってもよい。ここで、各データアイテムの参照情報とは、例えば、各データアイテムを格納した各ファイル（以下、上記のサーチ用ファイルと区別するために実体ファイルという）のパス情報、各実体ファイルへのリンク又は各実体ファイルのエイリアスなどである。この場合、各実体ファイル（つまり、各データアイテム）は、各ファイル１２２とは別の保存場所（そのコンピュータ内外の何処でもよい）に存在していてよい。各サーチ用ファイル１２２を開いてその中の参照情報を操作することで、ユーザは各データアイテムにアクセスすることができる。
【００３１】
各サーチ用ファイル１２２のファイル名は、各ファイル１２２に関連付けられた各データアイテムを検索するときに検索キーとして使用することができる所定の複数のキーアイテムに基づいて一定の法則に従って生成された文字列であり、これは、コンバータ１０４によって自動的に決定される。すなわち、上述した処理１４０でコンバータ１０４に入力される検索方法定義情報に、複数のデータアイテムの各々毎に、上述した検索キーとして使用可能な複数のキーアイテムが、検索方法の一項目として定義されており、その定義に基づいてコンバータ１０４が、各データアイテムに関連付けられた各サーチ用ファイル１２２のファイル名を生成する。
【００３２】
各サーチ用ファイル１２２のファイル形式は、予め固定的に定まっていても（例えば、テキスト（.txt）形式で固定でも）よいし、各ファイル１２２の内容に応じて異なってもよいが、いずれにしても、これも、コンバータ１０４によって自動的に決定される。例えば、上述した処理１４０で入力される検索方法定義情報に、データアイテム毎に、サーチ用ファイルの形式が、検索方法の一項目として定義されており、その定義に基づいてコンバータ１０４が、各データアイテムに関連付けられた各サーチ用ファイル１２２のファイル形式を決定する。
【００３３】
また、各サーチ用ファイル１２２の内容は、前述したように、各データアイテムそれ自体を含んだデータであっても、或いは、各データアイテムの参照情報を含んだデータであってもよいが、いずれにしても、これも、コンバータ１０４によって自動的に決定される。例えば、上述した処理１４０で入力される検索方法定義情報に、データアイテム毎に、サーチ用ファイルの内容を決定するための情報（例えば、各データアイテムそれ自体（例えばテキストデータ）、又は各データアイテムを格納した実体ファイルの参照情報）が、検索方法の一項目として定義されており、その定義に基づいてコンバータ１０４が、各データアイテムに関連付けられた各サーチ用ファイル１２２の内容を決定する（例えば、検索方法定義情報に定義された各データアイテムそれ自体もしくは実体ファイルの参照情報を、サーチ用ファイル１２２の内容とする、又は、その参照情報により特定される実体ファイルの内容を、サーチ用ファイル１２２の内容とする、など）。
【００３４】
上述した検索エンジン１０２によるサーチ用ファイル１２２，１２２，…のファイル名検索は、高速に行うことができる。すなわち、OSのファイルシステム１１０は、一般に、それが管理するストレージ装置１２０内にファイル１２２，１２２，…を保存するときに、それらのファイル１２２，１２２，…のファイル名とそれらのファイル１２２，１２２，…それ自体へのリンクとをファイル名管理情報１２４にエントリし、そのファイル名管理情報１２４を、ストレージ装置１２０内で、ファイル１２２，１２２，…それ自体から分離して、ストレージ装置１２０内のOSが使用する特別の領域に保存している。そして、ファイル名管理情報１２４は、ほぼ常にコンピュータの主メモリ上にキャッシュされている。そして、ファイルシステム１１０は、前述した処理１３２で検索エンジン１０２からファイル名検索の要求を受け取ると、キャッシュされたファイル名管理情報１２４上でファイル名のサーチを行ない、そのときに、サーチ用ファイル１２２，１２２，…それ自体へのアクセスは行われない。そのため、ファイル名検索は高速に行われる。
【００３５】
このファイル名検索の高速性の利点を活かして、検索エンジン１０２は、いわゆるドリルダウンと呼ばれる検索結果の段階的な絞込みを行う場合に、前の絞り込み段階で得られた検索結果（絞り込まれたファイル名群）上で次の絞り込み段階のサーチを行うという従来の一般的な方法を用いず、その代わりに、どの絞り込み段階においても、ファイル名の母群（すなわち、全てのサーチ用ファイル１２２，１２２，…のファイル名の群）上でサーチを行うという方法を行う。そして、このような絞り込み方法を可能にするために、ワイルドカード、特に任意の長さの任意の文字を意味するワイルドカード（典型的には「*」）が効果的に使用される。その結果、従来のようなドリルダウンのための検索キーの指定順序の制限が解消され、自由な順序で検索キーが指定できる。
【００３６】
図２は、コンバータ１０４によるサーチ用ファイル１２２，１２２，…の作成方法を示す。
【００３７】
図２に示されるように、前述した検索方法定義情報が登録された例えばCSV形式の一つのファイル（以下、検索方法定義ファイルという）１６０が、コンバータ１０４に入力される。検索方法定義ファイル１６０には、既に説明したように、複数のデータアイテムの各々について、検索キーとして使用可能な複数のキーアイテム、サーチ用ファイルの形式、及びサーチ用ファイルの内容を決定するための情報（例えば、各データアイテムそれ自体、又は各データアイテムを格納した実体ファイルの参照情報）が定義されている。図２に示された検索方法定義ファイル１６０の具体例では、第１行に、検索キーとして使用可能な複数のキーアイテムのカテゴリ名（例えば「データアイテム番号」、「都道府県」、「市区」、「町村」、「会社」、「姓」、「名」及び「参照ファイル名」などが、順に定義されている。第２行目以降の各行は、各データアイテムに対応しており、そこには、各データアイテムの検索キーとして使用可能な複数の上記カテゴリに属するキーアイテムをそれぞれ示す文字列が順に定義されている。
【００３８】
なお、この具体例では、データアイテム毎のカテゴリ「参照ファイル名」のキーアイテムは、単に検索キーとして使用できるキーアイテムの一つであるだけでなく、サーチ用ファイルのファイル形式を指定していてもよいし（例えば、識別子「.txt」がテキスト形式を指定している）、又は、各データアイテムを格納した実体ファイルを指定してもよい（例えば、実体ファイル「0001.txt」にデータアイテム番号「001」のデータアイテムが格納されている）。この具体例のように、検索方法定義ファイル１６０上の特定のキーアイテムが、サーチ用ファイルのファイル形式又は実体ファイルを指定する役割を兼ねていてもよいが、変形例として、サーチ用ファイルのファイル形式を指定する情報及び／又は実体ファイルを指定する情報が、キーアイテムとは別に検索方法定義ファイル１６０上で定義されてもよい。
【００３９】
このような検索方法定義ファイル１６０を作成すること、並びに、このような検索方法定義ファイル１６０上で検索キーの追加、変更及び消去、並びにデータアイテムの追加、変更及び消去を行うことは、ユーザにとり容易である。要するに、データベースのメンテナンスが容易である。そのため、スケジューラのように分単位でデータが増えていく用途にも適する。
【００４０】
コンバータ１０４は、検索方法定義ファイル１６０を入力し、検索方法定義ファイル１６０の内容に従って、複数のデータアイテムにそれぞれ関連付けられた複数のサーチ用ファイル１２２，１２２，…を自動的に作成し保存する。そのとき、コンバータ１０４は、検索方法定義ファイル１６０から入力された各データアイテムの複数のキーアイテムを、一定の法則にしたがって、各データアイテムに関連付けられたサーチ用ファイル１２２のファイル名に変換する。１つのデータアイテムに関して、単一のサーチ用ファイルを生成してもよいし、２以上の所定数のサーチ用ファイルを生成してもよい。１つのデータアイテムに関して２以上のサーチ用ファイルを生成する場合には、それら２以上のサーチ用ファイルは異なるフォルダ（ディレクトリ）に配置されることが望ましい。
【００４１】
各サーチ用ファイル１２２のファイル名の命名方法には多くのバリエーションがある。最も単純な方法の一つは、本明細書において「直接型」と呼ぶ命名方法である。直接型の命名方法を用いて、データアイテム毎に単一のサーチ用ファイル１２２を生成する場合、検索方法定義ファイル１６０から入力されたデータアイテム毎の複数のキーアイテムを直接的に表現する文字列を、一定の順序で（例えば、検索方法定義ファイル１６０上での配列順とおりの順序で）、単純に連結することにより、その単一のサーチ用ファイル１２２のファイル名が決定される。この場合、入力された文字列をそのままファイル名で用いてもよいし、或いは、入力された文字列が日本語のような２バイトコード文字を含む場合には、（複数バイト文字は、サーバーや通信環境によって使えないことがあるので）日本語から英語への翻訳のような自然言語翻訳を伴って２バイトコード文字を１バイトコード文字に変換し、変換後の１バイトコード文字を用いてもよい。いずれにしても、連結された隣り合うキーアイテムの間には、所定の区切り文字（例えば、アンダーバー「_」が挿入されることが望ましい。区切り文字を利用することにより、各キーアイテムの文字数に関係なく、ファイル名に組み込まれたキーアイテムの各々がどのカテゴリに属するのかが、判断できる。
【００４２】
ここに、一つの具体例を示す。一例として、CSV形式の検索方法定義ファイル１６０上で、データアイテム毎の複数のキーアイテムが以下のように定義されていたと想定する。下記の例では、1行目はキーアイテムのカテゴリを定義し、２行目以下の各行が各データアイテムの複数のキーアイテムを定義している。
【００４３】
＜キーアイテム定義の例＞
番号,氏,名,生まれ年,生まれ月,生まれ日,性別,実施年，実施月，実施日，終了月日，予定年，予定月，予定日，期限，参照ファイル名
001,渉,庄司,1950,04,27,2007,男,09,10,0910,2007,09,10,1020,200709012330.txt
002, 暁生,村田,1967,12,06,男,2007,09,10,0910,2007,09,10,1020,20070801010.txt
【００４４】
このキーアイテム定義の例に基づくと、それぞれのデータアイテムに関連付けられたサーチ用ファイルのファイル名は、例えば以下のように決定される。
【００４５】
＜直接型の命名法によるファイル名の例＞
001_Wataru_Shoji_1950_04_27_m_2007_09_10_0910_2007_09_10_1020_200709012330.txt
002_Akio_Murata_1967_12_06_m_2007_09_10_0910_2007_09_10_1020_20070801010.txt
【００４６】
直接型の命名法の上記例では、各データアイテムの複数のキーアイテムの全てが、各データアイテムのサーチ用ファイルのファイル名に組み込まれている。この場合、異なるデータアイテムのサーチ用ファイルが、同じディレクトリ（フォルダ）に保存されてよい。
【００４７】
他方、直接型の変形例として、階層型のディレクトリ（フォルダ）を利用して、異なるデータアイテムのサーチ用ファイルが、異なるディレクトリ（フォルダ）に保存されてもよい。この場合、上記例のように各データアイテムの複数のキーアイテムの全てが、各データアイテムのサーチ用ファイルのファイル名に組み込まれてもよいが、別法として、複数のキーアイテムの内の一部がディレクトリ名に組み込まれ、残りがファイル名に組み込まれるというように、各データアイテムの複数のキーアイテムがディレクトリ名とファイル名に分散して組み込まれてもよい。要するに、この別法では、ディレクトリ名とファイル名を合わせたパス名が、複数のキーアイテムの連結によって構成される。具体例は、以下のとおりである。下記の例では、スラッシュ「/」が階層の異なるディレクトリ（フォルダ）間の区切りを意味している。
【００４８】
＜直接型の別の命名法によるパス名の例＞
Wataru_Shoji_1950_04_27_m/2007/09/10_0910_10_1020_200709012330.txt
Akio_Murata_1967_12_06_m/2007/09/10_0910_2007_09_10_1020_20070801010.txt
【００４９】
同じディレクトリ（フォルダ）に多数のサーチ用ファイルが存在することは、コンピュータにとっては実際上の問題にならない。例えば、現時点で市販されている一般的なパーソナルコンピュータは、１つのフォルダに少なくとも１０万個のサーチ用ファイルが存在しても、支障なくファイル名検索を行なうことができる。しかし、ユーザにとっては、上述した後者の方法のように、適切に命名された階層型のフォルダに分類されてサーチ用ファイルが保存されている方が、便利である。例えばスケジューラにこの実施形態を用いる場合には、例えば、人別の複数のフォルダを用意し、各人のフォルダの中に、年別の複数のフォルダを用意し、各年のフォルダの中に、月別の複数のフォルダを用意し、さらに、各月のフォルダの中に複数のサーチ用ファイルを保存し、各サーチ用ファイルのファイル名に日付＋開始時間＋終了時間＋場所情報＋参照ファイル名を組み込む、というような運用ができる。
【００５０】
このように、階層型のディレクトリ（フォルダ）にサーチ用ファイルを分類して保存し、それぞれのサーチ用ファイルのパス名に、複数のキーアイテムを組み込むという方法は、上述した直接型の命名法だけでなく、以下に説明される他の型の命名法においても採用できる。従って、以下の他の型の命名法についての説明において、「ファイル名」という用語は、文字通りのファイル名だけを意味するものではなく、パス名を意味してもよい。
【００５１】
さて、サーチ用ファイルの別の型の命名法として、本明細書で「エンコード型」と呼ばれる方法がある。エンコード型の命名法では、入力された各キーアイテムの各文字が、（日本語のように複数バイト文字を含んでいても自然言語翻訳を行うことなしに、コンバータ１０４により自動的に）１バイト文字の文字列にエンコードされる。そして、それらエンコードされた文字列で表現された複数のキーアイテムの連結したものが、サーチ用ファイルのファイル名にされる。エンコード方法としては、入力された各文字の文字コード（例えば、UTF-8（Unicode Translation Format - 8）を基本にした文字コード）を、M進数（Mは２より大きい数）、例えば１６進数を表す１バイト文字群（0-9,
A-F）を用いた文字列に、変換する方法が採用される。具体例を挙げると、例えば、入力された複数のキーアイテムの文字列が、
庄司,渉,1950,04,27,男
である場合、エンコード型の命名法によれば、ファイル名は、例えば、
5E8453F8_6E09_G31G39G35G30_G3H34_G32G37_7537.txt
となる。エンコード型の命名法は、日本語文字で検索することが多い用途、例えば、名刺管理や住所録などの用途の場合に便利である。
【００５２】
また別の型のファイル名の命名法として、本明細書で「複合型」と呼ばれる方法がある。この命名方法は、上述した直接型とエンコード型の命名法を組み合わせたものである。すなわち、上記のエンコード型の方法では、入力文字が半角英数文字である場合、それはより長い文字列にエンコードされるという問題がある。この問題を解決するため、複合型の命名法では、複数のキーアイテムのカテゴリを、エンコードするべきものとエンコードしないものとに分類して、前者のカテゴリに属するキーアイテムはエンコードして、エンコード後の文字列を用い、後者のカテゴリに属するキーアイテムはエンコードせずに、入力された文字列をそのまま用いて、ファイル名を生成する。この場合、そこに属する全てのキーアイテムの入力文字列が半角英数文字のみからなるカテゴリは、エンコードされないものとして、それ以外のカテゴリは、エンコードされるものとして、分類されることになる。そのような分類は、例えば、検索方法定義ファイル１６０において、キーアイテムのカテゴリ毎にエンコードするか否かのフラグ情報を付記するというような方法で、予め設定されていてもよいし、或いは、コンバータ１０４が検索方法定義ファイル１６０に記述されたキーアイテムの文字種を分析することで自動的に行われてもよい。
【００５３】
複合型の命名法の具体例を挙げると、定義された複数のキーアイテムが、
庄司,渉,1950,04,27,男
である場合、半角英数文字で表現されてないキーアイテム「庄司」、「渉」及び「男」だけがエンコードされるので、ファイル名は、例えば、
5E8453F8_6E09_1950_04_27_7537.txt
となる。複合型の命名法は、日本語文字と半角英数文字の双方で検索することが多い用途、例えば名刺管理や住所録やスケジューラなどの用途で便利である。
【００５４】
ところで、上述したエンコード型や複合型の命名法において、エンコード後のキーアイテムの表記に使用できる文字群は、上述した１６進数文字群だけに限られるわけではない。１６進数文字群に代えて、より大きい進数の文字群、例えば、６２進数文字群（例えば、0-9, a-z, A-Z）を使用することにより、ファイル名をより短くするか又はファイル名中にさらに多くのキーアイテムを組み込むことが可能になる。ファイル名が短くなれば、検索速度はさらに向上する。
【００５５】
以上のように、本実施形態におけるデータベースでは、各データアイテムの持つ複数のキーアイテムがファイル名の中に組み込まれる。それにより、データアイテムの検索や抽出の仕組みが、OSの基本機能であるファイル名検索に置き換えられる。その結果、高速に検索が行なえる。本実施形態におけるデータベースでは、データベースのインデックスにファイル名が使される、ということができる。その結果、データアイテム自体のデータ形式として、画像、動画、ワープロ文書、スプレッドシートなど、コンピュータ上で扱える全ての形式が許容できる。従って、種々のデータ形式のデータアイテムを統括的に扱うことができる。また、サーチ用ファイルをXMLやHTMLで記述してもよく、そうすることで、コンピュータ内のストレージ装置内だけでなく外部の情報も統括的に処理することができる。
【００５６】
次に、図１に示された検索システム１０２が行う検索方法について説明する。
【００５７】
この検索方法では、ユーザから指定される１以上の検索キーを用いて検索ファイル名が作られ、そして、その検索ファイル名にマッチするファイル名をもつサーチ用ファイルが検索される。このようなファイル名検索が１回以上行なわれて、検索結果としてのファイル名リストが得られる。その後に、そのファイル名リスト中からユーザにより選択されたサーチ用ファイルが開かれて、その選択されたサーチ用ファイルに関連付けられたデータアイテム（ユーザにとっての最終的な検索目的）が得られる。
【００５８】
上記のファイル名検索においてサーチされる範囲は、図３に示されるように、サーチ用ファイルのファイル名の母群（全てのサーチ用ファイルのファイル名）１２３である。複数の検索キーを順次に指定しながらファイル名群を段階的に絞り込む（ドリルダウン）場合でも、各段階でサーチされる範囲は、前段階で絞り込まれたファイル名群ではなく、ファイル名の母群である。ファイル名検索で使用される検索ファイル名は、ユーザにより指定された１以上の検索キーと、ワイルドカード「*」とを用いて、検索エンジン１０２により自動的に作られる。すなわち、ユーザにより指定された１以上のカテゴリの検索キーと、それ以外のカテゴリについてのワイルドカード「*」とが、ファイル名の中でのカテゴリの配列順序に対応した順序で、連結文字「_」を介して連結されることで、検索ファイル名が作成される。
【００５９】
複数の検索キーを順次に指定して検索結果をドリルダウンする場合には、その各段階において、今段階とそれ以前の全ての段階にてユーザにより指定されたカテゴリの検索キーと、それ以外のカテゴリについてのワイルドカード「*」とが連結されることで、検索ファイル名が作成される。
【００６０】
検索エンジン１０２による検索ファイル名の作成方法の具体例を以下に示す。例えば、サーチ用ファイルのファイル名の母群が次のようなものであるとする（各ファイル名内のキーアイテムのカテゴリは、左から順に「番号」、「名」、「姓」、「生まれ年」、「生まれ月」、「生まれ日」、「性別」、「都道府県」、「参照ファイル名」である）。
【００６１】
001_Wataru_Shoji_1950_04_27_m_Tokyo_0001.txt
002_Maiko_Shoji_1978_05_27_f_Tokyo_0002.txt
003_Satoru_Shoji_1952_01_20_m_Tokyo_0003.txt
004_Akio_Murata_1967_12_06_m_Tokyo_0004.txt
005_Hiroaki_Otsuka_1949_04_04_m_Tokyo_0005.txt
006_Yoshie_Kidokoro_1960_04_25_f_Tokyo_0006.txt
007_Issei_Shoji_1990_04_27_m_Kanagawa_0007.txt
008_Hanako_Kidokoro_1990_04_25_f_Tokyo_0008.txt
【００６２】
この場合、カテゴリ「生まれ月」の検索キー「04」が指定された場合は、検索ファイル名は、
*_*_*_*_04_*_*_*_*.txt
というように、指定された検索キー「04」と、指定されてない検索キーの代用としてのワイルドカードとが連結されたものとなる。
【００６３】
また、カテゴリ「氏」の検索キー「Shoji」が指定された場合は、検索ファイル名は、
*_*_Shoji_*_*_*_*_*_*.txt
となる。
【００６４】
また、上記両方の検索キーが指定された場合には、検索ファイル名は、
*_*_Shoji_*_04_*_*_*_*.txt
となる。
【００６５】
また、検索結果をドリルダウンする場合、例えば、最初の段階でカテゴリ「生まれ月」の検索キー「04」を指定してファイル名群を絞り込み、次の段階で、カテゴリ「氏」の検索キー「Shoji」を指定して、さらにファイル名群を絞り込に、さらに次の段階でカテゴリ「都道府県」の検索キー「Tokyo」で、もっと絞り込む場合には、次のようになる。
【００６６】
最初の段階では、検索ファイル名は、
*_*_*_*_04_*_*_*_*.txt
となる。
【００６７】
次の段階では、検索ファイル名は、
*_*_Shoji_*_04_*_*_*_*.txt
のように、この段階と最初の段階で指定された検索キー「04」と「Shoji」の双方が組み込まれたものになる。
【００６８】
さらに次の段階では、検索ファイル名は、
*_*_Shoji_*_04_*_*_Tokyo_*.txt
のように、この段階と以前の段階で指定された検索キー「04」と「Shoji」と「Tokyo」の全部が組み込まれたものになる。
【００６９】
そして、最初の段階だけでなく、以後のどの段階でも、サーチ範囲は、前の段階で絞り込まれたファイル名群ではなく、ファイル名の母群である。
【００７０】
なお、上記具体例では、検索ファイル名の未指定のカテゴリの検索キーの１つ１つにワイルドカード「*」が１つずつ設定されているが、必ずしもそうでなければならないわけではない。指定された検索キーがどのカテゴリであるかが検索ファイル名から識別できる限り、未指定の連続する複数のカテゴリの検索キーをまとめて、それに１つのワイルドカード「*」を設定することもできる。例えば、上記の最初の段階で例示された検索ファイル名、
*_*_*_*_04_*_*_*_*.txt
は、例えば、
*_04_*_*_*_*.txt
とすることもできる。
【００７１】
このように、ファイル名検索では、検索結果をドリルダウンする場合であっても、サーチ範囲はファイル名の母群である。そして、予めインデックステーブルを作成しておく必要はない。その結果、検索結果をドリルダウンする時に指定できる検索キーのカテゴリやその順序には、格別の制約はなく、ユーザが自由に決めることができる。また、このように毎回母群からサーチしても、（検索ファイル名内のワイルドカードの数が非常に多くならない限りは）検索速度は高速である。なお、ワイルドカードは、上記のように未指定の検索キーの代用として使えるだけでなく、一般的なあいまい検索の目的（各検索キー中のあいまい個所の代用）にも使える。
【００７２】
図３は、検索エンジン１０２が提供するGUI（グラフィカルユーザインタフェース）ウィンドウの例を示す。図４〜図７は、検索エンジン１０２が行う検索のプロセスフローを示す。以下、これらの図を参照して、検索エンジン１０２が行う検索プロセスについて説明する。
【００７３】
図４に示すように、検索エンジン１０２は、ステップ２００で、検索ファイル名のテンプレートを用意する。検索ファイル名のテンプレートは、検索ファイル名に含まれるべき検索キーと同じ個数の変数（図中、番号で示された部分）が、連結文字「_」を介して連結したものである。各変数には、検索キーまたはワイルドカードを入れることができる。
【００７４】
ステップ２０２で、検索エンジン１０２は、検索方法定義ファイル１６０（図２参照）の第１行からコンバータ１０４により読み取られたキーアイテムの全てのカテゴリを、図３に示されたようなGUIウィンドウ１７０内の「キーカテゴリ一覧」ボックス１７２に、一覧表示する。
【００７５】
ステップ２０４で、ユーザが、「キーカテゴリ一覧」ボックス１７２内から、任意のカテゴリを指定する。すると、検索エンジン１０２は、ユーザにより指定されたカテゴリを選択し、その選択されたカテゴリをGUIウィンドウ１７０内の「選択キーカテゴリ」ボックス１７４に表示する。それとともに、検索エンジン１０２は、その選択されたカテゴリが属するキーアイテムのファイル名の中での配置位置（例えば、そのキーアイテムがファイル名の左から何番目であるか）を把握し（例えば、検索方法定義ファイル１６０をコンバータ１０４が読み取った結果に基づいて把握する）、その把握された配置位置を変数n1に入れる。
【００７６】
ステップ２０６で、検索エンジン１０２は、GUIウィンドウ１７０上に「第1キーリスト」ボックス１８０を表示し、その中身を空にする。ここで、「第1キーリスト」ボックス１８０は、ユーザが最初に検索キーとして指定することができるキーアイテムのリストを表示するためのボックスである。
【００７７】
ステップ２０８で、検索エンジン１０２は、OSのファイルシステム１１０に要求してサーチ用ファイルのファイル名の母群のリストを獲得する。そして、ステップ２０８〜２１６で、検索エンジン１０２は、そのファイル名母群リスト中の全てのファイル名を逐次にチェックする。
【００７８】
このファイル名母群のチェックの過程では、ステップ２１２で、各ファイル名の中の変数n1に該当する位置のキーアイテムが抽出されて、そのキーアイテムが変数Tに入れられ、そして、ステップ２１４と２１６で、その変数Tの中身が「第1キーリスト」ボックス１８０に追加され（既に追加されたキーアイテムは追加されない）、そして、ステップ２１０により、上記のチェック処理がファイル名母群リスト中の最後のファイル名まで繰り返される。
【００７９】
この結果として、ステップ２１８で、ユーザにより最初に指定されたカテゴリに属する全てのキーアイテムが抽出されて、「第1キーリスト」ボックス１８０に一覧表示される。換言すれば、ユーザが最初の検索キーとして選択可能なキーアイテムが、「第1キーリスト」ボックス１８０に一覧表示される。
【００８０】
次に図５を参照する。ステップ２２０で、ユーザがGUIウィンドウ１７０の「キーカテゴリ一覧」ボックス１７２内から、先ほど選択したカテゴリと異なる任意のカテゴリを指定する。すると、検索エンジン１０２は、ユーザにより指定されたカテゴリを選択し、その選択されたカテゴリをGUIウィンドウ１７０内の「選択キーカテゴリ」ボックス１７４に表示する。このとき、既に「選択キーカテゴリ」ボックス１７４に表示されている最初のカテゴリの下に、今回選択されたカテゴリが表示される。それとともに、検索エンジン１０２は、その選択されたカテゴリが属するキーアイテムのファイル名の中での配置位置（例えば、そのキーアイテムがファイル名の左から何番目であるか）を把握し（例えば、検索方法定義ファイル１６０をコンバータ１０４が読み取った結果に基づいて把握する）、その把握された配置位置を変数n2に入れる。
【００８１】
ステップ２２２で、ユーザがGUIウィンドウ１７０の「第1キーリスト」ボックス１８０内から、任意のキーアイテムを検索キーとして選択する。すると、検索エンジン１０２は、その選択された検索キー（キーアイテム）を変数k1に入れ、そして、その変数k1を用いて検索ファイル名を作成する。すなわち、ステップ２０２で用意した検索ファイル名のテンプレート中の、変数n1に該当する配置位置の変数を、上記変数k1にリプレイスし、それ以外の変数をワイルドカード「*」にリプレイスすることにより、検索ファイル名が作成される。
【００８２】
ステップ２２４で、検索エンジン１０２は、作成された検索ファイル名にマッチするファイル名を、サーチ用ファイルのファイル名の母群から検索するよう、OSのファイルシステム１１０に要求し、そして、ファイルシステム１１０はその検索結果としての第1ファイル名リストを検索エンジン１０２に返す。第1ファイル名リストには、ユーザにより最初に指定された検索キーで絞り込まれたファイル名群が記述されている。
【００８３】
ステップ２２６で、検索エンジン１０２は、GUIウィンドウ１７０上に「第2キーリスト」ボックス１８２を標示し、その中身を空にする。ここで、「第2キーリスト」ボックス１８２は、ユーザが２番目に検索キーとして指定することができるキーアイテムのリストを表示するためのボックスである。
【００８４】
ステップ２２８〜２３６で、検索エンジン１０２は、最初の検索結果として得た第1ファイル名リスト中の全てのファイル名を逐次にチェックする。
【００８５】
この第1ファイル名リストのチェックの過程では、ステップ２３２で、各ファイル名の中の変数n2に該当する位置のキーアイテムが抽出されて、そのキーアイテムが変数Tに入れられ、そして、ステップ２３４と２３６で、その変数Tの中身が「第2キーリスト」ボックス１８２に追加され（既に追加されたキーアイテムは追加されない）、そして、ステップ２３０により、上記のチェック処理が第1ファイル名リスト中の最後のファイル名まで繰り返される。
【００８６】
この結果として、ステップ２３８で、ユーザにより最初に指定された検索キーで絞り込まれたファイル名群がもつ、２番目に指定されたカテゴリに属する全てのキーアイテムが、「第2キーリスト」ボックス１８２に一覧表示される。換言すれば、ユーザが２番目の検索キーとして選択可能なキーアイテムが、「第2キーリスト」ボックス１８２に一覧表示される。
【００８７】
次に図６を参照する。この後、ステップ２４０で、ユーザが更に次のカテゴリを指定しない場合には、制御は図７に示す流れへ進むが、次のカテゴリを指定する場合には、制御はステップ２４２へ進む。
【００８８】
ステップ２４２で、ユーザがGUIウィンドウ１７０の「キーカテゴリ一覧」ボックス１７２内から、今まで選択したカテゴリとは異なる任意のカテゴリを指定する。すると、検索エンジン１０２は、ユーザにより指定されたカテゴリを選択し、その選択されたカテゴリをGUIウィンドウ１７０内の「選択キーカテゴリ」ボックス１７４に表示する。このとき、既に「選択キーカテゴリ」ボックス１７４に表示されている今まで選択されたカテゴリの下に、今回選択されたカテゴリが表示される。それとともに、検索エンジン１０２は、その選択されたカテゴリが属するキーアイテムのファイル名の中での配置位置（例えば、そのキーアイテムがファイル名の左から何番目であるか）を把握し（例えば、検索方法定義ファイル１６０をコンバータ１０４が読み取った結果に基づいて把握する）、その把握された配置位置を変数n3に入れる。
【００８９】
ステップ２４４で、ユーザがGUIウィンドウ１７０の「第2キーリスト」ボックス１８２内から、任意のキーアイテムを検索キーとして選択する。すると、検索エンジン１０２は、その選択された検索キー（キーアイテム）を変数k2に入れ、そして、前回の変数k1と今回の変数k2とを用いて検索ファイル名を作成する。すなわち、ステップ２０２で用意した検索ファイル名のテンプレート中の、変数n1に該当する配置位置の変数を、上記変数k1にリプレイスし、変数n2に該当する配置位置の変数を、上記変数k2にリプレイスし、それ以外の変数をワイルドカード「*」にリプレイスすることにより、検索ファイル名が作成される。
【００９０】
ステップ２４６で、検索エンジン１０２は、作成された検索ファイル名にマッチするファイル名を、サーチ用ファイルのファイル名の母群から検索するよう、OSのファイルシステム１１０に要求し、そして、ファイルシステム１１０はその検索結果としての第2ファイル名リストを検索エンジン１０２に返す。第2ファイル名リストには、ユーザにより最初に指定された検索キーと２番目に指定された検索キーの双方で絞り込まれたファイル名群が記述されている。
【００９１】
ステップ２４８で、検索エンジン１０２は、GUIウィンドウ１７０上に「第3キーリスト」ボックス１８４を表示し、その中身を空にする。ここで、「第3キーリスト」ボックス１８４は、ユーザが３番目に検索キーとして指定することができるキーアイテムのリストを表示するためのボックスである。
【００９２】
ステップ２５０〜２５８で、検索エンジン１０２は、２回目の検索結果として得た第2ファイル名リスト中の全てのファイル名を逐次にチェックする。
【００９３】
この第2ファイル名リストのチェックの過程では、ステップ２５４で、各ファイル名の中の変数n3に該当する位置のキーアイテムが抽出されて、そのキーアイテムが変数Tに入れられ、そして、ステップ２５６と２５８で、その変数Tの中身が「第3キーリスト」ボックス１８４に追加され（既に追加されたキーアイテムは追加されない）、そして、ステップ２５２により、上記のチェック処理が第2ファイル名リスト中の最後のファイル名まで繰り返される。
【００９４】
この結果として、ステップ２６０で、ユーザにより最初と２番目に指定された検索キーの双方で絞り込まれたファイル名群がもつ、３番目に指定されたカテゴリに属する全てのキーアイテムが、「第3キーリスト」ボックス１８４に一覧表示される。換言すれば、ユーザが３番目の検索キーとして選択可能なキーアイテムが、「第3キーリスト」ボックス１８４に一覧表示される。
【００９５】
以後、ステップ２６２に示すように、ユーザが所望する絞り込み回数だけ、上述したカテゴリの選択から次の「キーリスト」ボックスの作成までの処理が繰り返される。例えば、図３に示した例では、絞り込みが４回繰り返され、それにより「第4キーリスト」ボックス１８６が作成されている。
【００９６】
次に図７を参照する。i回目までの絞り込みが行われた段階で、ユーザがそれ以上の絞り込みを望まなかったとする。このとき、GUIウィンドウ１７０には、「第iキーリスト」ボックス（図３の例では「第4キーリスト」ボックス１８６）が表示されている。この場合において、ステップ２６４で、ユーザが、「第iキーリスト」ボックス内から、任意のキーアイテムを検索キーとして選択する。すると、検索エンジン１０２は、その選択された検索キー（キーアイテム）を変数kiに入れ、そして、今までの変数k1〜kiを用いて検索ファイル名を作成する。すなわち、ステップ２０２で用意した検索ファイル名のテンプレート中の、変数n1〜niにそれぞれ該当する配置位置の変数を、上記変数k1〜kiにリプレイスし、それ以外の変数をワイルドカード「*」にリプレイスすることにより、検索ファイル名が作成される。
【００９７】
ステップ２６６で、検索エンジン１０２は、作成された検索ファイル名にマッチするファイル名を、サーチ用ファイルのファイル名の母群から検索するよう、OSのファイルシステム１１０に要求し、そして、ファイルシステム１１０はその検索結果としての第iファイル名リストを検索エンジン１０２に返す。第iファイル名リストには、ユーザにより最初から今回までに指定された全ての検索キーで絞り込まれたファイル名群が記述されている。
【００９８】
ステップ２６８で、検索エンジン１０２は、第iファイル名リストの中の全てのファイル名から、所定の１以上のカテゴリのキーアイテムを抽出し、抽出されたキーアイテムを、GUIウィンドウ１７０上の「検索結果」ボックス１８８を表示する。ここで抽出されるキーアイテムは、ユーザにとって、対応するデータアイテムが何であるかを特定することが容易であるようなカテゴリのものが望ましい。例えば、データアイテムが商品データであるならば、カテゴリ「商品名」と「商品番号」のキーアイテムがそれに適するであろう。
【００９９】
ステップ２７０で、ユーザが、「検索結果」ボックス１８８内から任意のキーアイテムを選択する。すると、検索エンジン１０２は、OSのファイルシステム１１０に要求して、その選択されたキーアイテムに対応するサーチ用ファイルを開いて、そのサーチ用ファイルに関連付けられたデータアイテムを取得する。このとき、もし、そのサーチ用ファイル内にそのデータアイテム自体が格納されているならば、そのサーチ用ファイルを開くことでそのデータアイテムを得ることができる。他方、もし、そのサーチ用ファイル内にそのデータアイテムの参照情報が格納されているならば、まずそのサーチ用ファイルを開いてそのデータアイテムの参照情報を得て、次にその参照情報を用いてそのデータアイテムを獲得することができる。
【０１００】
ステップ２７２で、検索エンジン１０２は、獲得されたデータアイテムを、GUIウィンドウ１７０上の「データ内容」ボックス１９０に表示する。
【０１０１】
以上説明した検索プロセスによれば、検索結果をドリルダウンするときに、種々のカテゴリの検索キーを、任意の順序で指定することができる。
【０１０２】
さて、上述した実施形態において、１つのファイル名を構成するキーアイテムの個数は、OSが扱えるファイル名の長さの限界に制約される。また、たとえ、ファイル名の長さがその限界長さ以下に収まったとしても、検索ファイル名に組み込まれるワイルドカードの個数が多い（数十個程度以上）場合には、ファイル名検索の高速性が悪化するという問題がある。さらに、データアイテムの個数に相当する個数のサーチ用ファイルが必要であることに、抵抗を感じるユーザがいるかもしれない。また、データベースのバックアップをとる場合、データアイテム数分のサーチ用ファイルのコピーが必要である。
【０１０３】
以下では、このような問題を改善するための、改良されたファイル名命名法を幾つか説明する。
【０１０４】
まず、本明細書で「表対応型」と呼ばれる命名法を説明する。表対応型の命名法は、１つのファイル名に組み込めるキーアイテムの数の制限、及び、ワイルドカードの多用による検索速度の悪化という問題に対して改善を提供する。表対応型の命名法は、検索方法定義ファイル１６０（図２参照）とサーチ用ファイル１２２，１２２，…との間に、個々のキーアイテムの文字数を減らすための中間テーブルを介在させる。中間テーブルは、検索方法定義ファイル１６０に基づいて作成される。中間テーブルには、検索方法定義ファイル１６０により定義されたキーアイテムとそれらのカテゴリが登録されている。そして、中間テーブルは、カテゴリ毎に何個のキーアイテムが存在し、そして、そのテーブル内のどの位置（どの行位置）に何というカテゴリが登録され、各行内のどの位置（どの列位置）に何というキーアイテムが登録するかということが分かるように構成される。
【０１０５】
この方法は、さらに、本明細書で「列位置型」及び「行列位置型」とそれぞれ呼ばれる２つの命名法に分類できる。
【０１０６】
「列位置型」の命名法では、ファイル名を作成する際、複数のキーアイテムを連結する代わりに、それぞれのキーアイテムの中間テーブル内での列位置を示す符号を、それぞれのキーアイテムのカテゴリの行位置の順序で連結することで、ファイル名が生成される。
【０１０７】
その具体例を以下に示す。例えば、CSV形式の検索方法定義ファイル１６０が次のようにキーアイテムを定義していたとする。
【０１０８】
＜キーアイテムの定義例＞
番号,氏,名,性別,年齢,生まれ年,生まれ月,生まれ日,郵便番号,都道府県
01,庄司,渉,男,57,1950,04,27,1620067,東京都
02,庄司,悟,男,56,1952,01,20,1620067,東京都
03,城所,良江,女,47,1960,04,25,1401234,東京都
04,大塚,裕章,男,58,1949,04,04,1500001,東京都
05,田中,法子,女,40,1966,07,13,2220005,愛知県
06,岡本,由紀子,女,50,1967,09,25,3130088,神奈川県
07,伊藤,久美子,女,59,1949,10,13,2220000,埼玉県
【０１０９】
このような検索方法定義ファイル１６０から、例えば、CSVファイルの形式で次のような中間テーブルが作成される。
【０１１０】
＜中間テーブルの例＞
番号 (7),01,02,03,04,05,06,07
氏 (6),庄司,城所,大塚,田中,岡本,伊藤
名 (7),渉,悟,良江,裕章,法子,由紀子,久美子
性別 (2),男,女
年齢 (7),57,56,47,58,40,50,59
生まれ年 (6),1950,1952,1960,1949,1966,1967
生まれ月 (5),04,01,07,09,10
生まれ日 (5),27,20,25,04,13
郵便番号 (6),1620067,1401234,1500001,2220005,3130088,2220000
都道府県 (4),東京都,愛知県,神奈川県,埼玉県
【０１１１】
この中間テーブルでは、そこに登録された各キーアイテムが、このテーブル上での行位置と列位置によって識別できる。すなわち、行位置により、各キーアイテムが属するカテゴリが識別され、各行内の列位置により、各カテゴリに属する各キーアイテムが識別できる。さらに、この中間テーブルでは、カテゴリ毎のキーアイテムの個数（括弧書きの数字）が分かる。上記の例では、（最上行の「番号」は、検索キーとして使用しないカテゴリであるため、これは無視して）１行目はカテゴリ「氏」に対応し、このカテゴリ「氏」のキーアイテムの個数は７個であり、それらは「01」、「02」、「03」、「04」、「05」、「06」及び「07」であって、それぞれの先頭文字は（キーアイテムが登録された列範囲内での）１、４、７、１０、１３、１６，１９列目にそれぞれ対応し、また、２行目はカテゴリ「性別」に対応し、このカテゴリ「性別」のキーアイテムの個数は２個であり、それらは「男」及び「女」であって、それぞれの先頭文字は（キーアイテムが登録された列範囲内での）１列目と３列目にそれぞれ対応する、ということが分かる。この中間テーブルのファイルは、コンバータ１０４（図２参照）が検索方法定義ファイル１６０から自動的に作成して保存することができる。
【０１１２】
コンバータ１０４は、上記のような中間テーブルを利用して、検索方法定義ファイル１６０から、以下のようなファイル名をもったサーチ用ファイル群を作成する。
【０１１３】
＜サーチ用ファイル群のファイル名の例＞
01_1_1_1_1_1_1_1_1_1.txt
02_1_2_1_2_2_2_2_1_1.txt
03_2_3_2_3_3_1_3_2_1.txt
04_3_4_1_4_4_1_4_3_1.txt
05_4_5_2_5_5_3_5_4_2.txt
06_5_6_2_6_6_4_3_5_3.txt
07_6_7_2_7_4_5_5_6_4.txt
【０１１４】
上記各ファイル名では、区切り文字「_」で両側から挟まれた各符号（例えば数字）が、各キーアイテムを指している。そして、ファイル名の中での各符号の位置（例えば、左から何番目か）が、各キーアイテムが属するカテゴリの上記中間テーブルでの行位置（例えば、上から何番目のカテゴリか）（要するに、カテゴリの識別符号）を意味し、各符号（例えば数字）の値が、各キーアイテムの先頭文字の上記中間テーブルでの列位置（例えば、左から何番目の文字か）（要するに、各カテゴリの中でのキーアイテムの識別符号）を意味している。
【０１１５】
この場合の検索ファイル名の作成方法は、指定された検索キーの上記中間テーブル内での列位置を示す符号と、未指定の検索キーの代用としてのワイルドカードとを、区切り文字「_」を介して、上記中間テーブル内でのカテゴリの行順序で連結するという方法である。この方法において、未指定の1つ1つの検索キーの位置にワイルドカードを１つ１つ設定する必要は必ずしもなく、指定された検索キーのカテゴリが識別できさえすれば、複数の未指定の検索キーの塊に対して１つのワイルドカードを設定することができる。例えば、カテゴリ「性別」の検索キー「男」が指定された場合、検索ファイル名は、
*_*_*_1_*.txt
とすることができる。
【０１１６】
この検索ファイル名の例では、ファイル名中の左からの位置によって検索キーのカテゴリが識別される。そのため、指定された検索キーの右側の全ての検索キーが未指定であれば、それら右側の全ての検索キーに対して１つのワイルドカードを設定することができる。この例の場合、より頻繁に使う検索キーほどより左の方に配置しておくと、設定すべきワイルドカードの数が減るので、検索速度が向上する。
【０１１７】
この「列位置型」の命名法を採用した場合においても、図３〜図７を参照して説明した検索プロセスがそのまま適用できる。
【０１１８】
この「列位置型」の命名法によれば、ファイル名をより短くすることができ、又は、制限された長さのファイル名に組み込めるキーアイテムの数を増やすことができる。また、上述した中間テーブルに例示されているように、各カテゴリに属するキーアイテムの個数が予め計数されているので、この計数されたカテゴリ毎のキーアイテム個数を、検索用のGUIウィンドウに表示する（例えば、図３では、「キーカテゴリ一覧」ボックス１７２や他の幾つかのボックスで、カテゴリ毎のキーアイテム個数が表示されている）ことで、ユーザにとり、検索結果のドリルダウンを行う時に、どの順序でどのカテゴリの検索キーを指定することが適切であるかの判断が、容易になる。
【０１１９】
ただし、この「列位置型」の命名法においては、直接的なあいまい検索（検索ファイル名上で各検索キーの一部分にワイルドカードを設定すること）はできない。しかし、検索ファイル名作成のプロセスの前に次のような別のプロセスを行えば、この問題は解消できる。すなわち、上記別プロセスにおいて、指定されたあいまいな検索キーにマッチするキーアイテムを、検索方法定義ファイル１６０に定義された全てのキーアイテムの中からサーチし、その結果検索されたキーアイテムの中から、検索ファイル名に組み込むべき検索キーを確定する。
【０１２０】
以上が、「表対応型」の命名法の中の１番目の方法である、「列位置型」の命名法である。次に、「表対応型」の命名法の中の２番目の方法である、「行列位置型」の命名法について説明する。
【０１２１】
「行列位置型」の命名法においても、上記中間テーブルの作成については、上述した「列位置型」の命名法と同様のプロセスが適用できる。「行列位置型」の方法と「列位置型」の方法との間の相違点は、サーチ用ファイル群のファイル名を作成するプロセスにある。すなわち、「行列位置型」の命名法では、ファイル名の中の各キーアイテムに対応する符号が、中間テーブル内の各キーアイテムの列位置だけではなく、行位置と列位置のペア（つまり行列座標）を示している。なお、ファイル名に組み込まれた符号の値から一意に、対応するキーアイテムが識別できるので、或るカテゴリのキーアイテムが無用である場合には、その無用のカテゴリに対応する符号は、ファイル名から省略することができる（要するに、検索方法定義ファイル１６０に定義された全てのカテゴリに対応する符号を、ファイル名に組み込む必要はない）。
【０１２２】
具体例を示す。上述した「行列位置型」の命名法によれは、サーチ用ファイル群のファイル名は次のようであった。
【０１２３】
＜「列位置型」の命名法によるファイル名の例＞
01_1_1_1_1_1_1_1_1_1.txt
02_1_2_1_2_2_2_2_1_1.txt
03_2_3_2_3_3_1_3_2_1.txt
04_3_4_1_4_4_1_4_3_1.txt
05_4_5_2_5_5_3_5_4_2.txt
06_5_6_2_6_6_4_3_5_3.txt
07_6_7_2_7_4_5_5_6_4.txt
【０１２４】
これに対し、「行列位置型」の命名法によれば、サーチ用ファイル群のファイル名は次のようになる。
【０１２５】
＜「行列位置型」の命名法によるファイル名の例＞
01_1A_2A_3A_4A_5A_6A_7A_8A_9A_Z.txt
02_1A_2C_3A_4D_5F_6D_7D_8A_9A_Z.txt
03_1D_2E_3C_4G_5K_6A_7G_8I_9A_Z.txt
04_1G_2H_3A_4J_5P_6A_7J_8Q_9A_Z.txt
05_1J_2K_3C_4M_5U_6G_7M_8Y_9E_Z.txt
06_1M_2N_3C_4P_5Z_6J_7G_8BG_9I_Z.txt
07_1P_2R_3C_4S_5P_6M_7M_8BO_9N_Z.txt
【０１２６】
各ファイル名の中の各キーアイテムに対応する符号は、数字とアルファベットのペアからなっている。各ペア中の数字は、中間テーブル上での各キーアイテムが属するカテゴリの行位置（要するに、カテゴリの識別符号）を意味し、次のアルファベットは、中間テーブル上での各キーアイテムの列位置（要するに、各カテゴリの中でのキーアイテムの識別符号）を意味している。アルファベットとしては、例えば、２６進数を表すアルファベット文字（２６文字）が使用される。例えば、「A」は「１」、「B」は「２」、…、「AA」は「２７」を指す。
【０１２７】
下記の中間テーブルの例の場合、或るキーアイテムに対応する符号が例えば「２Ｒ」であれば、そのうちの数字「２」は、（最上行の「番号」は、検索キーとして使用しないカテゴリであるため、これは無視して）２行目のカテゴリ「名」を指し、アルファベット「Ｒ」は、そのカテゴリ「名」の中の（キーアイテムが登録された列範囲内での）１８列目から開始するキーアイテム「久美子」を指す。よって、符号「２Ｒ」はカテゴリ「名」のキーアイテム「久美子」を指す。
【０１２８】
＜中間テーブルの例＞
番号 (7),01,02,03,04,05,06,07
氏 (6),庄司,城所,大塚,田中,岡本,伊藤
名 (7),渉,悟,良江,裕章,法子,由紀子,久美子
性別 (2),男,女
年齢 (7),57,56,47,58,40,50,59
生まれ年 (6),1950,1952,1960,1949,1966,1967
生まれ月 (5),04,01,07,09,10
生まれ日 (5),27,20,25,04,13
郵便番号 (6),1620067,1401234,1500001,2220005,3130088,2220000
都道府県 (4),東京都,愛知県,神奈川県,埼玉県
【０１２９】
この場合の検索ファイル名の作成方法は、指定された検索キーの上記中間テーブル内での行列位置を示す符号と、未指定の検索キーの代用としてのワイルドカードとを、区切り文字「_」を介して連結するという方法である。この方法において、指定された検索キーのカテゴリは符号から識別できるので、複数の未指定の検索キーの塊に対して１つのワイルドカード「*」を設定することができる。また、検索ファイル名の両端に必ずワイルドカード「*」を付ける。例えば、カテゴリ「性別」の検索キー「男」が指定された場合、検索ファイル名は、
*3A*
とすればよい。また、カテゴリ「性別」の検索キー「男」と、カテゴリ「氏」の検索キー「庄司」とが指定された場合は、検索ファイル名は、
*1A*3A* 
とすればよい。
【０１３０】
検索ファイル名の両端にワイルドカード「*」を付ける理由は、もし、最初（左端）の検索キーの前又は最後（左端）の後にワイルドカード「*」が付いてないと、検索キーにマッチする文字列がファイル名内にあるか否かを判別する時に、その検索キーが最初又は最後であるかをチェックしなければなららないため、判別に手間がかかるからである。そのために、上述したサーチ用ファイル群のファイル名の例に示されているように、各サーチ用ファイルのファイル名の最後（右端）のキーアイテムの符号の後には、接尾文字「_Z」が付されている。接尾文字「_Z」が有ることで、検索ファイル名の最後にワイルドカード「*」を付けることができる。なお、検索ファイル名の最初には、検索キーとしては使用されないキーアイテム番号が付されており、このキーアイテム番号が接頭文字として、接尾文字「_Z」と同様な役割をするので、検索ファイル名の最初にもワイルドカード「*」を付けることができる。
【０１３１】
この「行列位置型」の命名法を採用した場合においても、図３〜図７を参照して説明した検索プロセスがそのまま適用できる。
【０１３２】
この「行列位置型」の命名法によれば、ファイル名を短くすることができ、又は長さが制限されたファイル名に組み込める検索キーの個数を増やすことができる。特に、無用なカテゴリに対応する符号はファイル名において省略できる点は、ファイル名を短くするために貢献する。例えば、キーアイテムのカテゴリが全部で２０個ある場合において、次のファイル名
00032_1A_6IJ_7O_8CQ_14BT_15BT_Z.txt
では、２、３、４、５、９〜１３、１６〜２０番目のカテゴリのキーアイテムが省略されている。
【０１３３】
また、ファイル名に組み込まれた２６進数文字が、それに対応するキーアイテムの先頭文字の位置を示していることにより、ファイル名の作成にかかる時間が短縮できる。中間テーブルのような２次元のマトリックス上で、或るアイテムがどこにあるかを探すより、文字列の中ににある或る文字の位置を調べる方が、処理時間が短いからである。また、後から、キーアイテムを追加しても、既存のファイル名を変更する必要がない。さらに、２６進数文字は暗号化に役にたつ。例えば、２６進数を、そのアルファベット順序を入れ替えたテーブルを使って暗号化すると、正解を見つけるために２６の階乗分の組み合わせを探る必要があるので、暗号の解読が困難である。
【０１３４】
以上、改良された幾つかのファイル名命名法を解説した。上記の説明においては、命名法が何であっても、１つのデータアイテムに対して１つのサーチ用ファイルが作成される。しかし、１つのデータアイテムに対して複数のサーチ用ファイルを作成することもできる。それえにより、ファイル名の長さの制限による問題を解決することができる。この場合にも、上述した種々の命名法のいずれもが、適用可能である。
【０１３５】
図８は、１つのデータアイテムに対して複数のサーチ用ファイルを作成するように構成された本発明の変形実施形態におけるデータフロー図である。
【０１３６】
この変形実施形態でも、システムの基本構成は、図１に示されたものと同様である。図８に示すように、コンバータ１０４は、入力された検索方法定義ファイルを解析して、データアイテム毎に、複数（例えば２つ）のサーチ用サブファイル３００、３０２を作成し、そして、それら複数のサーチ用サブファイル３００、３０２を、それぞれ異なる所定のディレクトリに保存する。
【０１３７】
１つのデータアイテムに関連付けられた複数のサーチ用サブファイル３００、３０２のファイル名には、それぞれ、そのデータアイテムのもつ異なるカテゴリ群のキーアイテムがそれぞれ組み込まれている。例えば、図８に示された例では、一方のサーチ用サブファイル３００のファイル名には、前半のカテゴリ＃１〜＃３のキーアイテムが組み込まれ、他方のサーチ用サブファイル３０２のファイル名には、後半のカテゴリ＃４〜＃６のキーアイテムが組み込まれている。このように、各データアイテムのもつ多数のカテゴリのキーアイテムが複数の群に分割されて、異なるカテゴリ群のキーアイテムが異なるサーチ用サブファイル３００、３０２のファイル名にそれぞれ組み込まれる。なお、いずれのサーチ用サブファイル３００、３０２のファイル名にも、それに関連付けられたデータアイテムのデータアイテム番号は共通に組み込まれる。
【０１３８】
検索エンジン１０２は、指定された検索キーを用いて、複数の検索サブファイル名３０４、３０６を作成し、それらの検索サブファイル名３０４、３０６をそれぞれ用いて、上記異なるディレクトリからファイルをそれぞれ検索する。これら複数の検索サブファイル名３０４には、上記異なるカテゴリ群に属する検索キーがそれぞれ組み込まれている。例えば、図８に示された例では、一方の検索サブファイル名３０４には、前半のカテゴリ＃１〜＃３の検索キーが組み込まれ、他方の検索サブファイル名３０６には、後半のカテゴリ＃４〜＃６の検索キーが組み込まれている。もし、或る検索サブファイル名に組み込まれるべきカテゴリ群に属する検索キーが未指定の場合には、その検索サブファイル名内の全ての検索キーはワイルドカードに置き換えられる。
【０１３９】
上記異なるディレクトリからのサブ検索結果としての複数のサブファイル名リスト３０８、３１０がファイルシステム１１０から返送されると、検索エンジン１０２は、それら複数のサブファイル名リスト３０８、３１０を論理演算により合成することで、合成検索結果３１２を作成する。すなわち、複数のサブファイル名リスト３０８、３１０の全てに、共通のデータアイテム番号をもつサブファイル名が含まれていたならば、それらのサブファイル名はヒットしたこと（つまり、その共通のデータアイテム番号で識別されるデータアイテムがヒットしたこと）を意味するから、その共通のデータアイテム番号（さらに、その共通のデータアイテム番号をもつサブファイル名に組み込まれているキーアイテムを加えてもよい）を合成検索結果３１２とすることができる。
【０１４０】
以上、本発明の好適な一実施形態とその変形例を説明した。上記実施形態では、ファイル名検索を利用するので、検索速度が高速である。また、検索結果をドリルダウンする時における複数の検索キーの指定順序は、ユーザが任意に決めることができる。
【０１４１】
反面、上記実施形態では、多数のサーチ用ファイルをストレージ装置内の所定ディレクトリに保存する必要がある。また、使用できる検索キーのカテゴリ数が、コンピュータで扱えるファイル名の長さの限界によって制限される。
【０１４２】
このような問題を克服するための、本発明の第２の実施形態について、以下に説明する。
【０１４３】
図９は、この第２の実施形態にかかる検索システムの全体構成を示す。図９において、図１に示した構成と同様又は類似の役割をもつブロックには、同じ参照番号を付して、重複した説明を省略する。
【０１４４】
以下、具体例を示しながら、この実施形態にかかる検索システムの構成と動作について説明する。
【０１４５】
図９に示すように、コンバータ１０４は、入力された検索方法定義ファイル１６０（例えばCSV形式のファイル）に基づいて、中間テーブルファイル３２０とキーアイテムリストファイル３２２を作成してストレージ装置１２０に保存する（ステップ４００）。
【０１４６】
具体例を示す。検索方法定義ファイル１６０によりキーアイテムが次のように定義されているとする。
【０１４７】
＜キーアイテムの定義例＞
番号,氏,名,性別,年齢,生まれ年,生まれ月,生まれ日,郵便番号,都道府県
01,庄司,渉,男,57,1950,04,27,1620067,東京都
02,庄司,悟,男,56,1952,01,20,1620067,東京都
03,城所,良江,女,47,1960,04,25,1401234,東京都
04,大塚,裕章,男,58,1949,04,04,1500001,東京都
05,田中,法子,女,40,1966,07,13,2220005,愛知県
06,岡本,由紀子,女,50,1967,09,25,3130088,神奈川県
07,伊藤,久美子,女,59,1949,10,13,2220000,埼玉県
【０１４８】
この場合、中間テーブルファイル３２０は例えばCSVファイルの形式で次のような内容で作成される。この内容は、上述した第１の実施形態における「表対応型」（「列位置型」と「行列位置型」）の命名法に関して説明した中間テーブルと同様である。
【０１４９】
＜中間テーブルファイル３２０の例＞
番号 (7),01,02,03,04,05,06,07
氏 (6),庄司,城所,大塚,田中,岡本,伊藤
名 (7),渉,悟,良江,裕章,法子,由紀子,久美子
性別 (2),男,女
年齢 (7),57,56,47,58,40,50,59
生まれ年 (6),1950,1952,1960,1949,1966,1967
生まれ月 (5),04,01,07,09,10
生まれ日 (5),27,20,25,04,13
郵便番号 (6),1620067,1401234,1500001,2220005,3130088,2220000
都道府県 (4),東京都,愛知県,神奈川県,埼玉県
【０１５０】
次に、上記の中間テーブルファイル３２０の内容に基づいて、キーアイテムリストファイル３２２が、例えばテキストファイルの形式で、次のような内容で作成される。
【０１５１】
＜キーアイテムリストファイル３２２の例＞
01_1A_2A_3A_4A_5A_6A_7A_8A_9A_Z
02_1A_2C_3A_4D_5F_6D_7D_8A_9A_Z
03_1D_2E_3C_4G_5K_6A_7G_8I_9A_Z
04_1G_2H_3A_4J_5P_6A_7J_8Q_9A_Z
05_1J_2K_3C_4M_5U_6G_7M_8Y_9E_Z
06_1M_2N_3C_4P_5Z_6J_7G_8BG_9I_Z
07_1P_2R_3C_4S_5P_6M_7M_8BO_9N_Z
【０１５２】
このように、キーアイテムリストファイル３２２は、上述した第１の実施形態における「表対応型」（「列位置型」と「行列位置型」）の命名法に関して説明した各サーチ用ファイのファイル名から拡張子を除去した各文字列（つまり、各データアイテムの各々がもつ複数のキーアイテムの上記中間テーブルファイル３２０上での行列位置を示す符号を連結してなる各文字列）を、１つのテキストファイルの１行に（要するに、互いに区別して）書き込んだものに他ならない。従って、キーアイテムリストファイル３２２には、多数のデータアイテムにそれぞれ関連付けられた多数の上記文字列（文字列の母群）が、記載されている。検索キーを用いたサーチは、キーアイテムリストファイル３２２上で行われるので、指定できる検索キーの数がファイル名の長さによって制限されることはない。
【０１５３】
検索エンジン１０２は、検索要求を受ける（ステップ１３０）度に、中間テーブルファイル３２０とキーアイテムリストファイル３２２を読み込み、それらファイル３２０、３２２の内容、すなわち、中間テーブル３２４とキーアイテムリスト３２６を、コンピュータの主メモリ３２８上に展開する（ステップ４０２）。検索キーを用いたデータアイテムの検索（ステップ４０４）は、主メモリ３２８上の中間テーブル３２４とキーアイテムリスト３２６を参照して行われる。ファイル名検索のように使用できる検索キーの個数がファイル名の長さにより制限されるという問題は、存在しない。中間テーブル３２４は、指定された検索キーを、キーアイテムリスト３２６でサーチをするための文字列（すなわち、その検索キーの中間テーブルファイル３２０上での行列位置を示す符号、換言すれば、その検索キーの識別符号）に変換するために使用される。
【０１５４】
検索キーを用いたデータアイテムの検索（ステップ４０４）では、ファイル名検索ではないので、ワイルドカード「*」を使っての検索はできない。その代わりに、或る文字列「XXXX」の中に或る文字列「YYY」が存在するかをチェックする関数が利用される。例えば、カテゴリ「性別」の検索キー「男」及びカテゴリ「都道府県」の検索キー「東京都」でサーチを行う場合には、その関数を用いて、キーアイテムリスト３２６の各行に対して、検索キー「男」に対応する文字列「_3A_」を含み、且つ検索キー「東京都」に対応する文字列「_9A_」を含むかどうかをチェックし、ヒットした行の最初の番号を返す、という処理を実行する。
【０１５５】
複数の検索キーが連続して並ぶ場合、例えば、カテゴリ「名前」の検索キー「渉」と隣のカテゴリ「性別」の検索キー「男」でサーチする場合には、キーアイテムリスト３２６の各行に対して、それら連続する検索キーに対応する符号を連結した文字列「_2A_3A_」を含むかチェックすればよい。
【０１５６】
この第２の実施形態においても、図３〜図７を参照して説明した検索プロセスが基本的に適用できる。ただし、図３〜図７を参照して説明した検索プロセスでは、指定された検索キーを組み込んだ検索ファイル名にマッチするサーチ用ファイルのファイル名が検索されるのに対し、この第２の実施形態での検索プロセスでは、指定された検索キーに対応する文字列（すなわち、その検索キーの中間テーブルファイル３２０上での行列位置を示す符号、換言すれば、その検索キーの識別符号）を含んだキーアイテムリストファイル３２２上の行の文字列が検索される。この相違点以外の処理において、図３〜図７を参照して説明した検索プロセスが適用できる。
【０１５７】
以上説明した第２の実施形態によれば、使用できる検索キーの個数に制限がない。検索キーの選択や、検索キーの順序は、ユーザが都度に自由に決定することができ、それが、検索の速度に影響することもない。ストレージ装置に保存すべきファイルの数は、データアイテムの数に関わらず、中間テーブルファイル３２０とキーアイテムリストファイル３２２の２つで足りるので、データベースのメンテナンス及びバックアップが極めて容易である。
【０１５８】
なお、上記第２の実施形態では、キーアイテムリストファイル３２２内の各データアイテムに関連付けられた文字列の作成方法として、上述した「表対応型」、特に「行列位置型」の命名法が使用されているが、それに代えて、既に説明した他の命名法、例えば「直接型」、「エンコード型」又は「列位置型」の命名法を使用することも可能である（「直接型」又は「エンコード型」の命名法を用いる場合、中間テーブルファイル３２０は不要である）。また、上記第２の実施形態では、１つのキーアイテムリストファイル３２２が用いられるが、それに代えて、そのキーアイテムリストファイル３２２の内容を分割したのと同等の内容をもつ複数のサブファイルを用いることもできる。
【０１５９】
以上、説明された本発明の幾つかの実施形態は、本発明の説明のための例示であり、本発明の範囲を制限する趣旨ではない。本発明は、その要旨を逸脱することなしに、これらの実施形態とは異なる種々の形態でも実施することができる。
【図面の簡単な説明】
【０１６０】
【図１】本発明の第１の実施形態にかかる検索システムの全体構成を示すブロック線図。
【図２】コンバータ１０４によるサーチ用ファイル１２２，１２２，…の作成方法の具体例を示すデータフロー図。
【図３】検索エンジン１０２が提供するグラフィカルユーザインタフェースの例を示す図。
【図４】検索エンジン１０２が行う検索のプロセスフロー図の一部。
【図５】検索エンジン１０２が行う検索のプロセスフロー図の一部。
【図６】検索エンジン１０２が行う検索のプロセスフロー図の一部。
【図７】検索エンジン１０２が行う検索のプロセスフロー図の一部。
【図８】１つのデータアイテムに対して複数のサーチ用ファイルを作成するように構成された本発明の変形実施形態のデータフロー図。
【図９】本発明の第２の実施形態にかかる検索システムの全体構成を示すブロック線図。
【符号の説明】
【０１６１】
１００  検索システム
１０２  検索エンジン
１０４  コンバータ
１１０  OSのファイルシステム
１２０  ストレージ装置
１２２  サーチ用ファイル
１６０  検索方法定義情報
１７０  GUIウィンドウ
３００、３０２  サーチ用サブファイル
３０４、３０６  検索サブファイル名
３１２  合成検索結果
３２０  中間テーブルファイル
３２２  キーアイテムリストファイル
３２４  中間テーブル
３２６  キーアイテムリスト
【図１】
2009093405.tif 000003
【図２】
2009093405.tif 000004
【図３】
2009093405.tif 000005
【図４】
2009093405.tif 000006
【図５】
2009093405.tif 000007
【図６】
2009093405.tif 000008
【図７】
2009093405.tif 000009
【図８】
2009093405.tif 000010
【図９】
2009093405.tif 000011