(57)【要約】【課題】  単一条件における検索結果の概数を、検索に要する処理の負荷を低減した計数処理により算出することが可能な検索技術を提供すること。【解決手段】  複数の階層を有し、それぞれの階層に複数のエントリデータを格納するノードが複数配置されているツリーインデックスを用いた検索装置は、ツリーインデックスの中から指定された検索条件に一致するツリーノードを特定する特定部と、ツリーノードの検索条件に一致するエントリデータの数をカウントし、所定数のエントリデータがカウントされたか否かを判定する判定部と、所定数のエントリデータがカウントされたと判定された場合、判定部の判定処理の対象をツリーノードの階層に対応する上位の階層のツリーノードのエントリデータにする照合部と、ツリーノードのエントリデータが検索条件に一致しないと判定された場合、判定処理の対象となった階層の各ツリーノードにおけるエントリデータ数の平均値を用いて、検索条件に対する検索結果の概数を算出する算出部と、を備える。【選択図】  図１３
2013008248.tif 000002
【特許請求の範囲】
【請求項１】
複数の階層を有し、それぞれの階層に複数のエントリデータを格納するノードが複数配置されているツリーインデックスを用いた検索装置であって、
前記ツリーインデックスの中から指定された検索条件に一致するツリーノードを特定する特定手段と、
前記ツリーノードの前記検索条件に一致するエントリデータの数をカウントし、所定数のエントリデータがカウントされたか否かを判定する判定手段と、
前記所定数のエントリデータがカウントされたと判定された場合、前記判定手段の判定処理の対象を前記ツリーノードの階層に対応する上位の階層のツリーノードのエントリデータにする照合手段と、
前記ツリーノードのエントリデータが検索条件に一致しないと判定された場合、前記判定処理の対象となった階層の各ツリーノードにおけるエントリデータ数の平均値を用いて、前記検索条件に対する検索結果の概数を算出する算出手段と、
を備えることを特徴とする検索装置。
【請求項２】
前記照合手段は、前記判定手段により前記検索条件に一致する連続した所定数のエントリデータがカウントされた場合に、前記上位の階層のツリーノードに前記判定手段の判定処理を移すことを特徴とする請求項１に記載の検索装置。
【請求項３】
地理上の領域の検索範囲の指定を取得する取得手段と、
前記地理上の領域を複数の部分領域に区分する複数のメッシュから前記検索範囲を覆うメッシュを選定する選定手段と、
前記選定手段で選定されたメッシュについて、前記算出手段により前記検索条件に対する検索結果の概数が所定以上になると算出される場合、前記メッシュを更に詳細な部分領域を示すメッシュに分割する分割手段と、
前記選定手段で選定されたメッシュまたは前記分割手段で分割されたメッシュの地理上の位置を示すコードを検索文字列として検索を行う検索手段と、
を更に備えることを特徴とする請求項１または２に記載の検索装置。
【請求項４】
前記検索手段は、前記検索文字列の末尾文字を除く文字列が、予め記憶されているメッシュコードと一致するものを検索結果候補として検索することを特徴とする請求項３に記載の検索装置。
【請求項５】
前記選定手段で選定されたメッシュまたは前記分割手段で分割されたメッシュが前記検索範囲に部分的に含まれる場合、前記検索手段は、当該メッシュの検索結果を除外することを特徴とする請求項３または４に記載の検索装置。
【請求項６】
前記検索手段の検索結果を表示する表示手段を更に備えることを特徴とする請求項３乃至５のいずれか１項に記載の検索装置。
【請求項７】
請求項１乃至６のいずれか１項に記載の検索装置を有することを特徴とする画像撮影装置。
【請求項８】
複数の階層を有し、それぞれの階層に複数のエントリデータを格納するノードが複数配置されているツリーインデックスを用いた検索装置における検索方法であって、
前記検索装置の特定手段が、前記ツリーインデックスの中から指定された検索条件に一致するツリーノードを特定する特定工程と、
前記検索装置の判定手段が、前記ツリーノードの前記検索条件に一致するエントリデータの数をカウントし、所定数のエントリデータがカウントされたか否かを判定する判定工程と、
前記検索装置の照合手段が、前記所定数のエントリデータがカウントされたと判定された場合、前記判定工程の判定処理の対象を前記ツリーノードの階層に対応する上位の階層のツリーノードのエントリデータにする照合工程と、
前記検索装置の算出手段が、前記ツリーノードのエントリデータが検索条件に一致しないと判定された場合、前記判定処理の対象となった階層の各ツリーノードにおけるエントリデータ数の平均値を用いて、前記検索条件に対する検索結果の概数を算出する算出工程と、
を有することを特徴とする検索方法。
【請求項９】
コンピュータを、請求項１乃至６のいずれか１項に記載の検索装置の各手段として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データベースを用いて検索を行う検索装置、画像撮影装置、検索方法及びプログラムに関する。
【背景技術】
【０００２】
近年、ストレージや記録メディアの大容量化が進み、比較的小規模な機器においても、大量に蓄積されたデータを扱うことになり、検索機能が必須となりつつある。
【０００３】
例えば、カメラにおいて撮影写真等が格納されるフラッシュメディアでは、現在、容量６４ＧＢのＳＤＸＣ規格のカードが市販されており、１枚あたり１ＭＢの写真が６万枚以上格納されることになる。このように大量の写真から目的の写真を引き出すには、従来のような撮影順の閲覧機能だけでは不十分であり、日付、撮影場所、被写体名等、写真データに付与された様々なメタデータを用いた検索機能が不可欠である。大量のデータからユーザの検索意図に合致するものを絞り込む過程で用いられる指標として検索ヒット件数がある。検索条件の結果として得られる検索ヒット件数を見ることで次にどのような絞り込みの条件を加えるべきかを判断することができる。一般的に、データベースの検索を行うための言語としてＳＱＬ（ＳＴＲＵＣＴＵＲＥＤ Ｑｕｅｒｙ Ｌａｎｇｕａｇｅ）で検索ヒット件数を求める際には「ＳＥＬＥＣＴ  ＣＯＵＮＴ（＊）  ＦＲＯＭ  ＴＡＢＬＥ  ＷＨＥＲＥ  条件文」というクエリを用いる。このクエリの結果を導出する際には、どのような検索条件でも件数が算出できるように処理する。まず、ツリーインデックスで行データの場所を特定し、次に一件ずつ条件を満たすかを確認しながらカウントアップしていく。このように検索結果数を算出する処理時間は実際にヒットする件数に左右され、相当程度の時間がかかる重い処理となる。高速アクセス可能なメモリリソースを備え、計算能力の潤沢な検索サーバであればヒット件数が数万件、数十万件オーダーのカウント処理であっても瞬時に結果返却可能だが、組込み機器上で同様の処理を行う場合には多くの処理時間を要する。
【０００４】
このような検索ヒット件数の導出時間を短縮するための手段として、従来から検索結果数の概数を求めるという手法が存在する。特許文献１では複数の検索条件を組合せた際の処理時間の拡大を回避するため、個々の検索条件に関する正確な検索ヒット件数を元に、計算によってそれら条件を組み合わせた結果件数の概数を求める方法が提案されている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００９−１４０３１７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
特許文献１で提案されている方法は、複数の検索条件を組み合わせた際の概数を、処理の負荷を低減した計算によって算出する方式である。しかしながら、特許文献１で提案されている方法では、単一の条件に関する結果数の計数処理についてはコスト削減の効果が得られない。一方、検索装置においては、単一の検索条件を組み合せた複数の検索条件や複雑な条件式で検索する事はむしろ稀である。そのため、単一条件における件数の概数を、検索に要する処理の負荷を低減した計数処理により推定することが課題となっている。
【０００７】
本発明は、単一条件における検索結果の概数でも、検索に要する処理の負荷を低減した計数処理により算出することが可能な検索技術を提供する。
【課題を解決するための手段】
【０００８】
本発明の一つの側面にかかる検索装置は、複数の階層を有し、それぞれの階層に複数のエントリデータを格納するノードが複数配置されているツリーインデックスを用いた検索装置であって、
前記ツリーインデックスの中から指定された検索条件に一致するツリーノードを特定する特定手段と、
前記ツリーノードの前記検索条件に一致するエントリデータの数をカウントし、所定数のエントリデータがカウントされたか否かを判定する判定手段と、
前記所定数のエントリデータがカウントされたと判定された場合、前記判定手段の判定処理の対象を前記ツリーノードの階層に対応する上位の階層のツリーノードのエントリデータにする照合手段と、
前記ツリーノードのエントリデータが検索条件に一致しないと判定された場合、前記判定処理の対象となった階層の各ツリーノードにおけるエントリデータ数の平均値を用いて、前記検索条件に対する検索結果の概数を算出する算出手段と、を備えることを特徴とする。
【発明の効果】
【０００９】
本発明によれば、単一条件における検索結果の概数を、検索に要する処理の負荷を低減した計数処理により算出することが可能になる。
【図面の簡単な説明】
【００１０】
【図１】実施形態にかかる画像撮影装置の構成を示すブロック図。
【図２】地理情報検索の地理範囲指定検索の例を示す図。
【図３】実施形態にかかる地理領域を表現するための地理コード体系を説明する図。
【図４】実施形態にかかる検索装置において、検索範囲を覆うメッシュ群を求める例を示す図。
【図５】撮像部により撮影された写真等の画像データの属性情報を格納するテーブルの構成を示す図。
【図６】指定された検索範囲を管理するためのテーブルの構成を示した図。
【図７】検索範囲を覆うメッシュ群を求める際に使用して、隣接するメッシュのメッシュコードを順次求めるための末尾文字遷移テーブルの構成を示す図。
【図８】メッシュの統合および詳細化の際に使用するテーブルを説明する図。
【図９】検索結果数の概算を推定する処理を説明する図。
【図１０】実施形態にかかる検索処理の流れを説明する図。
【図１１】検索処理の詳細な流れを説明する図。
【図１２】メッシュ群選定処理の流れを説明する図。
【図１３】検索結果の概数を取得する処理の流れを説明する図。
【図１４】検索範囲に内包されないメッシュについての検索結果を偽検索結果として除外する処理の流れを説明する図。
【図１５】写真登録処理の流れを説明する図。
【発明を実施するための形態】
【００１１】
＜実施形態１＞
以下、図面を参照しながら本発明の実施形態を詳細に説明する。図１は、本発明の実施形態１にかかる検索方法を実行することが可能な画像撮影装置の全体構成を示すブロック図である。画像撮影装置としては、例えば、デジタルカメラ、デジタルビデオカメラが含まれ得る。以下の説明では、デジタルカメラ、デジタルビデオカメラを想定して画像撮影装置を例示的に説明する。
【００１２】
ＣＰＵ１０１は検索処理、写真登録処理、画面制御処理、写真撮影処理等のための演算、論理判断等を行い、バスを介してバスに接続された各デバイスを制御する。
【００１３】
ＢＵＳ１０６はバスであり、ＣＰＵ１０１の制御対象である各デバイスを指示するアドレス信号、コントロール信号を転送する。また、ＢＵＳ１０６は各デバイス間のデータ転送を行う。入力部１０２は、例えば、ボタン、タッチパネル等であり、オペレータは、入力部１０２を介して各種の指示を行うことが可能である。
【００１４】
表示部１０３は、例えば、液晶ディスプレイ等である。撮像部１０４は、例えば、撮像センサ等であり、映像を読み取って電子データに変換することが可能である。通信部１０５は、例えば、ネットワークコントローラであり、有線あるいは無線の通信路を介して外部とのデータ交換を行うことが可能である。
【００１５】
ＲＯＭ１０７は読出専用の不揮発性メモリである。ＲＯＭ１０７はＣＰＵ１０１によるブートプログラム、システムの制御プログラム、後述する処理で使用される末尾文字遷移テーブル、及び各種処理で参照される各種初期データ等を記憶する。ブートプログラムはシステム起動時に初期データをＲＡＭ１０８にロードし、ＣＰＵ１０１に制御プログラムを実行させる。制御プログラムについては、後にフローチャートを参照して詳述する。
【００１６】
ＲＡＭ１０８は読み書き可能なランダムアクセスメモリであって、各デバイスからの各種データの一次記憶に用いる。ＲＡＭ１０８には、処理に必要なデータを記憶し、処理中に値変更が行われる各種データが格納される各種ワーク領域、指定される検索範囲を記憶する範囲指定テーブルが格納される。また、検索範囲を覆うメッシュ群を記憶する範囲メッシュテーブル、メッシュの統合および詳細化の際に一時的に作成される前方文字列テーブル、末尾文字テーブル、追加末尾文字テーブル等が格納される。
【００１７】
ＦＬＡＳＨ１０９は、ブロック単位で一括消去可能な大容量の不揮発性メモリであり、大量のデータを変更可能に記憶するためのものである。ＦＬＡＳＨ１０９は、例えば、ＳＤカード、ＣＦカード等のフラッシュメディアであり、ハードディスク等で代用することもできる。ＦＬＡＳＨ１０９には、後述する処理で使用する代表位置テーブル、写真テーブル等を保持したリレーショナルデータベースが格納され、必要に応じて随時内容が修正される。尚、ＣＰＵ１０１により実行される制御プログラムを、ＦＬＡＳＨ１０９に格納する構成も可能である。その場合は、必要に応じてＲＡＭ１０８に示す主記憶にロードし、実行することになる。そのようにすることで固定プログラムではなく、途中で修正可能な柔軟なシステムを構成することができる。
【００１８】
実施形態１にかかる検索装置は、上述の各部を有しており、入力部１０２等からの各種イベントに応じて作動する。入力部１０２等からのインタラプトが供給されるとインタラプト信号がＣＰＵ１０１に送られる。それに伴ってイベントが発生し、イベントに応じてＣＰＵ１０１がＲＯＭ１０７またはＲＡＭ１０８内に記憶されている各種命令を読み出し、ＣＰＵ１０１の実行によって各種の制御が行われる。
【００１９】
尚、ＣＰＵ１０１はプログラムを実行することで各種の手段として機能することが可能である。なお、ＣＰＵ１０１と協調して動作するＡＳＩＣなどの制御回路がこれらの手段として機能してもよい。また、ＣＰＵ１０１と検索装置の動作を制御する制御回路との協調によってこれらの手段が実現されてもよい。また、ＣＰＵ１０１は単一のものである必要はなく、複数であってもよい。この場合、複数のＣＰＵは分散して処理を実行することが可能である。また、複数のＣＰＵは単一のコンピュータに配置されていてもよいし、物理的に異なる複数のコンピュータに配置されていてもよい。なお、ＣＰＵがプログラムを実行することで実現する手段が専用の回路によって実現されてもよい。
【００２０】
図２は、地理情報検索の地理範囲指定検索の例を示す図である。図２（ａ）は、検索指示前の画面の表示例を示している。画面上にはある地図領域が表示されており、地図上の地点２０１を黒丸印で示している。矩形２０２は、地図上の検索範囲を示しており、検索範囲内に内包される地点の検索を行おうとしている。図２（ｂ）は、検索実行後の画面の表示例を示している。各地点が検索結果となったか、ならなかったかが画面上に表示される。検索結果となった（検索範囲に内包される）地点はヒット２０３として丸印で表示され、検索結果とならなかった（検索範囲に内包されない）地点は非ヒット２０４としてバツ印で表示される。
【００２１】
図３は、実施形態１における地理領域を表現するための地理コード体系を説明する図である。地表を階層的なメッシュで区分し、緯度・経度情報に基づいてメッシュの位置を地理コードで表現する。本実施形態においては、地理コードは文字列で表現される。図３（ａ）は、緯度・経度情報を地理コードに変換する具体例を示している。地表を緯度または経度の方向に沿って２分割していき、分割の度に０又は１のビットを割り当てる。緯度、経度のそれぞれに対して、そのビットを大分割から順番に並べてビット列を作成し、メッシュの緯度情報３０１及び経度情報３０２とする。このように生成されたビット列に対して、緯度、経度の順番で先頭から交互に１ビットずつ選択していき、ビット列３０３を生成する。ビット列３０３を先頭から５ビットずつに分割し、各５ビットを変換表３０４に従って文字コードに変換して地理コード３０５とする。各メッシュは地表の分割回数に応じて階層的に詳細化されたものになる。詳細化されたメッシュほど、緯度・経度情報のビット数が多くなり、変換後の文字列の文字数も多くなる。文字数がメッシュの精度を表現することになるので、メッシュの精度を文字列の文字数と定義する。このように生成されたメッシュの地理コードをメッシュコードと呼ぶ。
【００２２】
図３（ｂ）はメッシュが構成する階層構造の例を説明する図である。メッシュ３０６は地理コード３０５の“ｅ”が表現する精度＝１（すなわち、文字数＝１）のメッシュであり、図中の１文字を追加することによって下位メッシュに３２分割される。ここでは、３２進法（ＢＡＳＥ３２）を用いている。次の地理コード３０５の１文字が“７”の場合は、精度＝２のメッシュ３０７になり、メッシュコードが“ｅ７”となる。メッシュ３０８はメッシュ３０７に対応する下位メッシュである。同様に次の１文字を追加することによって３２分割される。次の１文字が“ｓ”の場合は、精度＝３のメッシュ３０９となり、メッシュコードは“ｅ７ｓ”となる。このようにメッシュコードの文字数に応じてメッシュが階層化されていることが分かる。メッシュコードの文字数が同じメッシュ群を、同じ階層に属していると言い表す。このように階層化されたメッシュが表現する地理領域の、赤道付近における概略面積を図３（ｃ）の表３０１０に例示する。これによれば、精度＝３のメッシュは１５６ｋｍ×１５６ｋｍの矩形を表現することが分かる。精度を大きくすればより詳細な地理領域を表現できる。例えば、精度１２のメッシュコードは、１．８ｃｍ×３．７ｃｍの概略面積を表現することになり、事実上、地図上の特定の地点を表現することになる。そこで本実施形態においては、地点を特定する場合は、システム上最も詳細な精度のメッシュコードで表現することにしている。
【００２３】
図４は、検索範囲を覆うメッシュ群を求める例を示す図である。図４（ａ）に示す検索範囲４０１に対して、これを覆うメッシュが図４（ｂ）に示すように求められる。検索範囲４０１は本実施形態の検索装置が提供する地理検索条件指定機能を使いユーザが指定することが可能である。各メッシュ４０２は、一旦すべて同じ階層に属すように求められる。メッシュのうち、メッシュ全体を検索範囲が内包するメッシュ４０３を完全内包メッシュと呼び、検索範囲がメッシュを部分的に含む（内包）するメッシュ４０４を部分内包メッシュと呼ぶ。完全内包メッシュは更に上位階層のメッシュに統合することが可能である。図４（ｃ）はメッシュ統合の例を示している。統合されたメッシュ４０５は４つの完全内包メッシュが下位メッシュとして１つの上位メッシュに置換され統合されている。尚、図３に示した変換方式によれば、階層を１段階上げるためには本来３２個のメッシュを統合する必要があるが、ここでは図面スペースの関係で４つのメッシュが１つのメッシュに統合されたとして説明している。図４（ｄ）はメッシュ詳細化の例を示している。詳細化されたメッシュ４０６は１つのメッシュが３２の各下位メッシュ４０７に分割され詳細化されている。
【００２４】
図５は、撮像部１０４により撮影された写真等の画像データの属性情報を格納するテーブルの構成を示す図である。写真等の撮影された画像データの撮影地点は、図５（ａ）の代表位置テーブルに記憶される。写真等は複数枚まとめて撮影されることが多いので同一地点（同一メッシュ範囲）で撮影された写真群に対して、代表して１つの撮影地点が設定され、代表位置ＩＤが付与されて代表位置テーブルで管理される。代表位置テーブルのカラム５０１には撮影地点のメッシュコードが格納され、カラム５０２には代表位置ＩＤが格納される。写真等に関する他の属性情報は、例えば、図５（ｂ）に示す写真テーブル中に、写真1枚ごとに情報が記憶される。写真テーブルのカラム５０３には撮影された個々の写真の識別情報（ＩＤ）が格納され、カラム５０４には、撮影された写真が撮影された撮影地点の代表位置ＩＤが格納される。カラム５０５には、写真に関して記憶すべきそれ以外の情報が格納される。
【００２５】
図６は、指定された検索範囲を管理するためのテーブルの構成を示した図である。図６（ａ）は範囲指定テーブルの構成を示している。指定された地図上の矩形の検索範囲に対して、範囲指定テーブルの左上地点６０１は、検索範囲の左上の位置にある地点のメッシュコードを保持し、右下地点６０２は、検索範囲の右下の位置にある地点のメッシュコードを保持する。この指定された検索範囲に対して、それを覆うメッシュ群が設定され、図６（ｂ）に示すような範囲メッシュテーブルで管理される。例えば、検索範囲６０３に対しては、メッシュ６０４、６０５、６０６、６０７が設定される。メッシュ６０４〜６０７は、地点６０１，６０２の上位階層メッシュである。このメッシュ群は、図６（ｂ）に示す範囲メッシュテーブルで管理される。範囲メッシュテーブルのカラム６０８には各メッシュのメッシュコードが記憶される。カラム６０９には、各メッシュの領域を検索範囲が完全に内包するかどうかを示すフラグ（「完全フラグ」と呼ぶ）が記憶される。完全に内包するとき（「完全内包」と呼ぶ）“１”を、部分的に内包するとき（「部分内包」と呼ぶ）“０”を記憶する。この例では、各メッシュには検索範囲に入らない部分が必ず存在しているので、全メッシュに対して部分内包を示す“０”が記憶されている。
【００２６】
図７は、検索範囲を覆うメッシュ群を求める際に使用して、隣接するメッシュのメッシュコードを順次求めるための末尾文字遷移テーブルの構成を示す図である。図７（ａ）は、精度が偶数（文字数が偶数）のメッシュについて使用する偶数精度用末尾文字遷移テーブルである。各セル内に記憶される文字はメッシュの末尾文字を意味し、上下左右に隣接するセルに記憶される文字は該メッシュの上下左右に隣接するメッシュの末尾文字と対応する。例えば、メッシュ７０１（“ｐ”を示している）の右の文字が“ｒ”であることから、メッシュコードの末尾が“ｐ”の偶数精度のメッシュの右隣のメッシュのメッシュコードの末尾は“ｒ”であることが分かる。図７（ｂ）は、同様に精度が奇数（文字数が奇数）のメッシュについて使用する奇数精度用末尾文字遷移テーブルである。同様にメッシュ７０２（“ｂ”を示している）の右の文字が“ｃ”であることから、メッシュコードの末尾が“ｂ”の奇数精度のメッシュの右隣のメッシュのメッシュコードの末尾は“ｃ”であることが分かる。図７（ｃ）は、この末尾文字遷移テーブルを使用して検索範囲のメッシュをスキャンしていく状況を示した図である。図中のメッシュコードを、例えば、“４ｐｒｕｙｑ”とすると、メッシュコードの末尾文字は“ｑ”になる。このとき、１段階上位の階層のメッシュ７０３のメッシュコードは“４ｐｒｕｙ”となる。メッシュ７０３の右に隣接するメッシュ７０４のメッシュコードの末尾文字は、図７（ｂ）を参照すると、末尾“ｙ”の右隣りの末尾文字“ｚ”となり、メッシュ７０４のメッシュコードは“４ｐｒｕｚ”となる。検索範囲７０５に対する左上地点と右下地点の位置が、範囲指定テーブル７０６においてメッシュコードで記憶される。このとき、精度６で検索範囲を覆うメッシュを求めるには、まず左上メッシュのメッシュコード（“４ｐｒｕｙｋ”）を求める。これは左上地点のメッシュコード“４ｐｒｕｙｋｄｅ”を文字数＝６にトランケート（精度＝６なので）することにより実行できる。この後、矢印の方向に沿ってメッシュをスキャンしていく。例えば“４ｐｒｕｙｋ”から右にスキャンするときは次のように行う。まず、図７（ａ）に示す偶数精度用末尾文字遷移テーブルを参照して末尾文字“ｋ”の右隣の文字“ｓ”を取得する。次に“４ｐｒｕｙｋ”の末尾文字“ｋ”を“ｓ”に置き換える。これによって、右隣のメッシュのメッシュコード“４ｐｒｕｙｓ”を生成することができる。下にスキャンするときも同様にしてメッシュコードを求めることができる。このようにスキャンしていくことによって、検索範囲７０５を覆うメッシュ群のリストが図７（ｄ）に示すようにリストアップされていく。スキャンに応じて、メッシュコード以外に、指定される検索範囲中での相対位置（左上、上、右上、内部、下）、完全フラグの情報（完全内包か部分内包か）も取得できる。
【００２７】
図８は、メッシュの統合および詳細化の際に使用するテーブルを説明する図である。図８（ａ）は前方文字列テーブルである。メッシュのスキャンの際、末尾文字を除くメッシュコードの前方文字列を前方文字列テーブルのカラム８０１に記憶する。メッシュコードの文字列判定によって、同じ前方文字列は１つにまとめて格納される。末尾文字は、図８（ｂ）に示す末尾文字テーブルに記憶していく。末尾文字テーブルのカラム８０２に末尾文字の文字コードを記憶し、カラム８０３に完全フラグの値を記憶する。すなわち、メッシュが完全内包か部分内包に応じて“１”または“０”を記憶する。また、カラム８０４にはこのメッシュに含まれる検索結果概数を記録する。検索結果概数はメッシュの詳細化対象である非完全内包メッシュに関してのみ格納される。完全内包メッシュの場合、検索結果概数の欄には“ＮＵＬＬ”が格納される。
【００２８】
ここで検索結果概数が検索装置で事前に定めた所定数を超えるメッシュに関しては更に詳細化され、例えば、図８（ｃ）に示す追加末尾文字テーブルに１段下位の末尾文字に関する情報が記憶される。追加末尾文字テーブルは末尾文字テーブルと同様にカラム８０５に末尾文字の文字コードを記録し、カラム８０６に完全フラグの値が記憶される。前方文字列テーブル（図８（ａ））と、末尾文字テーブル（図８（ｂ））および追加末尾文字テーブル（図８（ｃ））からメッシュコードの情報を合成して、範囲メッシュテーブル（図８（ｄ））が作成される。ここで範囲メッシュテーブルには６桁のメッシュコードと、太枠で示す７桁のメッシュコードの２パターンのメッシュコードが格納されている。“４ｐｒｕｙｅ”を始めとする６桁のメッシュコードについては上位階層への統合対象となる。一方“４ｐｒｕｙｋ０”を始めとする７桁のメッシュコードについてはメッシュコードが“４ｐｒｕｙｋ”であるメッシュが１段下位の階層に詳細化されたものである。このとき、完全内包のメッシュ（完全フラグの値“１”）を部分内包（完全フラグの値“０”）より先に置き、完全フラグの値が同じメッシュについては文字コード順にソートしておく。部分内包のメッシュから得られる検索結果候補に対しては、真に検索範囲にはいっているかどうかをチェック（「詳細チェック」と呼ぶ）する必要がある。これに対して、完全内包のメッシュは検索範囲に完全に内包されるので、それから得られる検索結果候補に対しては詳細チェックの必要がなく、検索結果と判定できる。完全内包のメッシュを、部分内包のメッシュよりも先に置くことによって、完全内包のメッシュから優先的に検索結果が得られることになる。検索装置を組み込んだ画像撮影装置はリソースの制限が強いので、大量の検索結果を処理しきることが元々できず、大量の処理がある場合は、処理を途中で中断して打ち切ることが通例行われる。完全内包のメッシュを優先することによって、詳細チェックの処理を少なくでき、処理負荷を軽減するという効果が期待できる。尚、ここで想定する大量処理とは検索結果として画面表示用データだけでなくアプリ内に保持する制御データ等、様々なデータをレコードとしてフェッチするため、前述の検索結果件数の概数を得るための処理に比べはるかに処理負荷が大きい。
【００２９】
図９は、検索結果数の概数を推定する処理を説明する図である。図９（ａ）は分岐したツリーインデックス（以下、Ｂツリーインデックス）を示した図である。Ｂツリーインデックスは、複数の階層を有し、それぞれの階層に複数のエントリデータ（以下、エントリ）を格納するノードが複数配置されている。本実施形態では写真テーブルの代表位置ＩＤカラムにＢツリーインデックスが作成されている。Ｂツリーインデックスはそのエントリとして代表位置ＩＤを複数格納したノードによって構成され、それらは格納する値の大小比較によって上位階層と下位階層とに分岐した階層構造を取る。ノードにはいくつかの種類があり、最も上位に位置するルートノード９０１、中間がブランチノード９０２、最も下位に位置するのがリーフノード９０３である。ブランチノードについてはレコード数が多くなる場合は複数存在し、逆にレコード数が少ない場合は存在しないこともある。
【００３０】
写真レコード９０４へのポインタはブランチノードのみに存在し、ブランチノードはリーフノードのポインタを保持し、ルートノードはブランチノードのポインタを保持する。各ノードには、一意にノードを特定するためのノード番号が付与されている。例えば、ルートノード９０１のノード番号は１番であり、ルートノード９０１の左側に記述されている数字が各ノードのノード番号を意味する。例えば、ノード番号３番のリーフノードが格納する代表位置ＩＤは値の小さい順に“７２”、“７３”、“７５”となる。
【００３１】
ここで本実施形態の検索装置において実際にＢツリーインデックスを用いて検索を行う際には、例えば、次のようなＳＱＬクエリを用いる。ＳＱＬの一例は「ＳＥＬＥＣＴ  ＣＯＵＮＴ（＊）  ＦＲＯＭ  写真テーブル、代表位置テーブル  ＷＨＥＲＥ  代表位置テーブル.メッシュコード  ＬＩＫＥ  “４ｐｒｕｙｋ％”」である。メッシュコードを地理検索条件として指定することで文字列の前方一致検索が可能となる。
【００３２】
これを受けたデータベースエンジンはＳＱＬを解析し、ＷＨＥＲＥ句の条件式で使用されるメッシュコードを、例えば図５のテーブルを用いて代表位置ＩＤに変換する。変換されたＷＨＥＲＥ句の条件指定は「ＷＨＥＲＥ  代表位置ＩＤ＞＝７２  ＡＮＤ  代表位置ＩＤ＜＝７３４」となる。これによって以降の検索で代表位置テーブルの参照は不要となる。以上の手順によって書き換えられたＳＱＬを用いた処理手順について、以下に一般的な処理方法と本実施形態を適用した場合の検索処理方法とをそれぞれ説明する。一般的な検索結果のカウント処理手順を示したものが図９（ｂ）である。まず条件に指定された最小値に合致する代表位置ＩＤをＢツリーインデックスのリーフから特定する。その後、条件に指定された最大値を超える代表位置ＩＤが見つかるまで次のエントリを順次評価していく。図９（ｂ）ではまずノード番号３のエントリ“７２”を特定し、その後、エントリ“７３”、“７５”を順次評価する。順次評価を繰り返した後、ノード６４のエントリ “７３５”で条件に指定された代表位置ＩＤの最大値を超えたと判定される。最後にエントリ“７３２”までカウントした値を結果として確定する。この処理手順で必要とされる処理時間は検索でヒットする件数に依存する。この処理手順では、最大値に達するまでアプリケーションに制御を返すことができない。検索結果を画面に表示できる件数には制限があり、所定以上の結果数を厳密にカウントする必要のない画像撮影装置での処理には適さない。これに対し、本実施形態における検索結果数の概数を推定する処理の手順を示したものが図９（ｃ）である。まず条件に指定された最小値に合致する代表位置ＩＤをＢツリーインデックスのリーフから特定する。その後、所定の評価対象のエントリ数の上限に達するまで同一階層のノードについてスキャン処理を行う。スキャン処理では、ノード内に存在する検索条件に合致するエントリかどうかを評価し、合致するエントリの数をカウントアップする。ここで所定の評価対象のエントリ数の上限値については機器の性能に合わせて事前にＲＯＭ１０７に記録しておく。たたし、ルートノードについてはこれ上位の階層のノードが存在しないため、スキャン処理では全てのエントリを評価する。
【００３３】
評価対象のエントリ数の上限に達し、なお条件に一致し続ける場合は次の評価対象のエントリを現在評価中のＢツリー階層の次のエントリではなく、上位階層の次のエントリにスキャン処理をスキップする。図９（ｃ）ではノード番号３のエントリ“７２”、“７３”、“７５”を順次評価したが、評価対象のエントリ数の上限である“３”に達してなお条件に一致し続けるため上位の階層のノード番号２の親エントリ“７２”の次のエントリ“８９”を評価している。また、ここで上位の階層のノードに評価対象を移す前に、現階層の各ツリーノードに存在するカウント対象となるエントリデータ数の平均値（平均エントリ数）を記録しておく。これは最終的に概数を算出するためのエントリ数推定情報として使用する。以降、同様に同一階層内のエントリを順次評価し、更に評価対象のエントリ数の上限に達してなお条件に一致し続ける場合は上位階層のエントリを照合するように評価対象を移す。このような処理を最終的に検索条件で指定された最大値を超える代表位置ＩＤが見つかるまで繰り返す。図９（ｃ）では最終的にルートノード９０１の末尾エントリ“８９２”に到達し、条件に指定された最大値を超える代表位置ＩＤが見つかったと判定される。最後に検索結果の概数を推定し処理を終了する。
【００３４】
検索結果の概数は導出式（１）によって算出することが可能である。
【００３５】
検索結果概数＝（階層Ｎで条件に合致するノードの平均エントリ数）  ×  （階層Ｎ＋１で条件に合致するノードの平均エントリ数）  ×  （階層Ｎ＋２で条件に合致するノードの平均エントリ数）  ×  ・・・・                    （１）
（ＮはＢツリーインデックスの階層数）
ここで図９（ａ）のＢツリーに対して図９（ｂ）、図９（ｃ）で示すそれぞれの方式での計算処理の負荷を比較してみる。ここで、画像撮影装置の画面表示に必要なデータは４件であり、それぞれの階層で上限合致するノードの平均エントリ数をそれぞれ４とする。また所定の評価対象のエントリ数の上限が４に設定されていたとする。これを図９（ｂ）の方式で処理した場合、評価対象のエントリ数は４１エントリであり、オーバーヘッドは３７エントリ分（＝４１−４）の評価となる。一方、図９（ｃ）の方式で処理した場合、評価対象のエントリ数は１２エントリであり、オーバーヘッドは８（＝１２−４）となる。実際にはこれに概数を計算するための計算処理の負荷を考慮する必要があるが、ＦＬＡＳＨメモリからデータを読み込む処理に比べればごく僅かの時間で済む。以上の手順により、検索でヒットする件数の影響を受けずに高速に検索ヒット件数の概数を推定する事ができる。
【００３６】
実施形態１にかかる上述の検索処理の流れを図１０のフローチャートに従って説明する。図１０は実施形態１の検索装置のＣＰＵ１０１の処理手順を示す。ステップＳ１００１において、ＣＰＵ１０１は、検索装置の初期化処理として、各種パラメータの初期化や初期画面の表示等を行う。ステップＳ１００２において、ＣＰＵ１０１は、例えば、タッチパネル等の入力部１０２を介した指示により何らかのイベントが発生するのを待機する。イベントが発生すると、ステップＳ１００３において、ＣＰＵ１０１がこのイベントの種類を判別し、ステップＳ１００４において、ＣＰＵ１０１はイベントの種類に応じて各種の処理を実行する。イベントの種類に応じた処理として、検索処理（図１１）、写真登録処理（図１５）を後に詳細に説明する。他の処理としては、画面制御処理、写真撮影処理などの処理がある。
【００３７】
ステップＳ１００５において、ＣＰＵ１０１は上記の各処理の処理結果や処理終了をユーザに通知するための表示処理を行う。検索結果出力の画面表示、エラーがあった場合のエラー表示、正常な処理が行われた場合の画面表示への反映などの処理が本ステップで実行される。ステップＳ１００５の表示処理の終了後、処理はステップＳ１００２に戻され、次のイベント待ちの状態でＣＰＵ１０１は待機する。新たなイベントが発生した場合（Ｓ１００２）、ステップＳ１００３〜Ｓ１００５の処理が同様に繰り返される。
【００３８】
図１１は、検索処理の詳細な流れを説明するフローチャートである。本処理は、ＣＰＵ１０１により実行される。まず、ステップＳ１１０１において、検索範囲を取得する。すなわち、検索範囲を取得して範囲指定テーブルを設定する。この検索範囲は、例えば、図４の検索範囲４０１に示すものであり、検索装置が提供する地理検索条件指定機能を使いユーザが地理上の領域を指定することが可能である。
【００３９】
ステップＳ１１０２において、図１２に詳述するようにメッシュ群選定処理を行う。地理上の領域を複数の部分領域に区分する複数のメッシュから、先のステップＳ１１０１で取得された検索範囲を覆うメッシュ群を選定し、範囲メッシュテーブルを作成する。範囲メッシュテーブルは、例えば、先に説明した図６（ｂ）に示すテーブルであり、図６（ａ）の検索範囲６０３に対しては、４つのメッシュ６０４、６０５、６０６、６０７が設定され、範囲メッシュテーブルで管理される。範囲メッシュテーブルのメッシュコード（図６（ｂ）のカラム６０８）を参照することにより各メッシュを特定することができる。また、図６（ｂ）のカラム６０９を参照することにより、検索範囲に対して各メッシュが完全内包メッシュであるか部分内包メッシュであるかを判定することできる。
【００４０】
ステップＳ１１０３において、範囲メッシュテーブルからメッシュを1つずつ順番に取得する。範囲メッシュテーブルは完全内包メッシュから優先されるようにソートされて作成されているため、完全内包メッシュが部分内包メッシュに優先して取得される。
【００４１】
ステップＳ１１０４において、取得されたメッシュのメッシュコードを検索文字列として設定する。ステップＳ１１０５では、先のステップＳ１１０４で設定された検索文字列に対して検索結果候補取得を行う。代表位置テーブル（例えば、図５（ａ））を検索して、設定された検索文字列の末尾文字を除く前方文字列が、代表位置テーブルに記憶されている撮影地点のメッシュコードと一致するものを抽出してリストアップする。抽出されたメッシュコードが検索結果候補となる。
【００４２】
ステップＳ１１０６において、今回、範囲指定テーブルから取得されたメッシュが完全内包メッシュか部分内包メッシュであるかを判定する。完全内包メッシュの場合（Ｓ１１０６−Ｙｅｓ）、今回の検索処理でリストアップされた検索結果候補をすべて正式な検索結果として、ステップＳ１１０８に処理を進める。一方、ステップＳ１１０６の判定で、部分内包メッシュの場合（Ｓ１１０６−Ｎｏ）、処理はステップＳ１１０７に進められ、検索範囲に内包されない検索結果を偽検索結果として除外するための処理（偽検索結果除外処理）を行う。本処理の具体的な処理の流れは図１４の参照により後に詳細に説明する。偽検索結果除外処理により、ステップＳ１１０５で見つかった検索結果の候補のうち真の検索範囲に入らないものは除外される。
【００４３】
ステップＳ１１０８において、これまでに検出された検索結果数が所定数（例えば、１００件）を超えたかどうかを判定し、所定数を超えていれば（Ｓ１１０８−Ｙｅｓ）、それ以上処理しきれないので処理を中断してリターンする。一方、ステップＳ１１０８において、検索結果数が所定数以下である場合（Ｓ１１０８−Ｎｏ）、処理はステップＳ１１０９に進められる。ステップＳ１１０９では、範囲メッシュテーブルに未処理のメッシュがまだ存在するかを判定し、未処理のメッシュが存在すれば、処理はステップＳ１１０２に戻され、次のメッシュを範囲指定テーブルから取得して、以下同様の処理を繰り返す。
【００４４】
図１２はステップＳ１１０２（図１１）のメッシュ群選定処理の具体的な処理の流れを説明するフローチャートである。本処理は、ＣＰＵ１０１により実行される。ステップＳ１２０１において、検索範囲の面積を求める。面積Ｓは最も詳細な精度（ｎとする）で必要なメッシュ数として、縦方向に必要なメッシュ数と、横方向に必要なメッシュ数とを乗算することで求める。
【００４５】
ステップＳ１２０２において、適正な精度（Ｎ）の推定を行う。ここでは、検索範囲が正方形に近い形を例にして、それを覆うメッシュ群のメッシュ数が所定個数以下となる精度、例えば、３２以上６４未満となる精度が適正であると想定して計算する。初期値Ｎ＝ｎから開始して、精度が１段階変わるごとにメッシュ数が３２倍変化することから、面積Ｓを３２で除算して商が２以上ならばＮを１減算し、商（整数）を新たな面積Ｓとする操作を繰り返していく。ステップＳ１２０３では、ステップＳ１２０２で推定された適正精度Ｎにより検索範囲を覆うメッシュ群を求め、図８に示した前方文字列テーブル、末尾文字テーブルを作成し、完全フラグを設定する。
【００４６】
ステップＳ１２０４において、前方文字列テーブル、末尾文字テーブルを参照し、文字列判定して共通の前方文字列を持つメッシュ群を取得する。ステップＳ１２０５において、それらのメッシュ群のうち完全内包となっているメッシュ数が所定個数存在するか判定する。所定個数として、ここでは３２以上存在するかを判定する。所定数以上でなければ（Ｓ１２０５−Ｎｏ）、ステップＳ１２１１に分岐する。所定数以上なら（Ｓ１２０５−Ｙｅｓ）、ステップＳ１２０６において、上位階層のメッシュに統合する。ここでは、例えば、前方文字列“４ｐｒｕｙ”に対して、“ｐ”“ｒ”“ｘ”などで構成される３２個の末尾文字が全て完全内包となっていた場合、このメッシュ群を１個の上位メッシュコードに統合する。統合されたメッシュコードの末尾文字を末尾文字テーブル（例えば、図８（ｂ））に追加して、末尾文字テーブルを修正（更新）する。
【００４７】
ステップＳ１２０５において、完全内包となっているメッシュ数が所定個数以上存在しない場合（Ｓ１２０５−Ｎｏ）、処理はステップＳ１２１１に進められ、メッシュの詳細化を行う。ステップＳ１２１１からステップＳ１２１３までの処理については評価中の前方文字列に対応する末尾文字テーブルの全てのレコードに対して処理を行うループ処理である。ステップＳ１２１１では、前方文字列テーブルと末尾文字テーブルの文字とを連結したメッシュコード内に含まれる検索結果の概数を取得する。次に、ステップＳ１２１２において、検索結果の概数が所定数以上であるかを判定し、所定数（Ｘ件）以上であれば（Ｓ１２１２−Ｙｅｓ）、ステップＳ１２１３に進む。ステップＳ１２１３では、ステップＳ１１０２で選定されたメッシュを更に詳細な部分領域を示すメッシュに分割する。本ステップでは、ステップＳ１２０２で求められた精度Ｎよりも高い精度を示す精度Ｎ＋１で、検索範囲を覆うメッシュ群を求め、図８に示した前方文字列テーブル、末尾文字テーブルを作成する。これにより検索装置の検索結果を表示出力する領域の表示精度を詳細化する（表示精度詳細化処理）。
【００４８】
ステップＳ１２０７において、前方文字列テーブルから次の前方文字列を取得する。ステップＳ１２０８において、すべての前方文字列の処理が終了したかを判定し、終了していなければ（Ｓ１２０８−Ｎｏ）、処理はステップＳ１２０４に戻され、同様の処理が繰り返される。すべての前方文字列の処理が終了している場合（Ｓ１２０８−Ｙｅｓ）、処理はステップＳ１２０９に進められる。ステップＳ１２０９において、前方文字列テーブルと末尾文字テーブルを参照して、完全内包となっているメッシュについて、メッシュコードのリストを作成し、文字コード順に範囲メッシュテーブル（図６（ｂ））に登録する。
【００４９】
ステップＳ１２１０において、前方文字列テーブルと末尾文字テーブルを参照して、部分内包となっているメッシュについて、メッシュコードのリストを作成し、文字コード順に範囲メッシュテーブル（図６（ｂ））に追加登録し、本処理を終了する。
【００５０】
図１３は、ステップＳ１２１１の検索結果の概数を取得する具体的な処理（検索ヒット件数の概数推定処理）の流れを説明するフローチャートである。本処理は、ＣＰＵ１０１により実行される。ステップＳ１３０１において検索条件に合致する最初のツリーノードを特定する。最初のツリーノードが検索の起点となる。その後、ステップＳ１３０２、ステップＳ１３０３、ステップＳ１３０４を一連の処理手順とするスキャン処理を繰り返す。まず、ステップＳ１３０２において、ツリーノードのエントリが検索条件に一致するか否かを判定し、一致する場合（Ｓ１３０２−Ｙｅｓ）はステップＳ１３０３に進む。ステップＳ１３０３において評価中のＢツリーインデックスの階層において所定数（例えばＹ件（Ｙ：自然数））のエントリに対して検索条件に一致するかどうかを判定する。所定数のエントリをまだ評価していない場合はステップＳ１３０４に進み、評価対象を次のエントリに進める。検索条件に一致する連続した所定数のエントリがカウントされたことにより所定数のエントリについて評価済となった場合（Ｓ１３０３−Ｙｅｓ）、ステップＳ１３０５に処理は進められる。そして、ステップＳ１３０５において、評価中である現在のＢツリーインデックスの現階層のノード内に含まれる検索条件に合致するエントリ数の平均値を算出し記録する。ステップＳ１３０６では、現在のＢツリーインデックススの階層よりも上位の階層のツリーノードに、ステップＳ１３０２〜Ｓ１３０３における判定処理の対象を移す（スキップ処理）。以降、同様の手順をステップＳ１３０２にてエントリが条件に一致しないと判定されるまで繰り返す。エントリが条件に一致しないと判定された場合（Ｓ１３０２−Ｎｏ）、処理はステップＳ１３０７に進められ、検索結果の概数を、図９（ｃ）の説明で参照した導出式（１）によって算出し、本処理を終了する。尚、一度も上位のＢツリーの階層のノードに評価対象を移動させる必要が無かった場合、カウント数は概数でなく実際のカウント値となる。
【００５１】
図１４は検索範囲に内包されないメッシュについての検索結果を偽検索結果として除外する具体的な処理（偽検索結果除外処理）の流れを説明するフローチャートである。本処理は、ＣＰＵ１０１により実行される。ステップＳ１４０１において、検索結果候補を１つずつ順次取得する。ステップＳ１４０２において、検索結果候補を取得できたかどうか判定する。すべての候補について処理が終了しており、検索結果候補が取得できなかったとき本処理は終了する。ステップＳ１４０２において、検索結果候補を取得できた場合（Ｓ１４０２−Ｙｅｓ）、処理はステップＳ１４０３に進められる。ステップＳ１４０３において、取得された検索結果候補が、もともとの範囲指定テーブルが規定する検索範囲に入っているかどうかを判定する。判定は、検索範囲が矩形の場合、左上地点と右下地点の緯度・経度情報を判定することにより行う。検索範囲に入っていれば（Ｓ１４０３−Ｙｅｓ）、ステップＳ１４０５に処理は進められる。一方、ステップＳ１４０３の判定で検索範囲に入っていなければ（Ｓ１４０３−Ｎｏ）、ステップＳ１４０４に進み、その検索結果候補をリストから除外する。ステップＳ１４０５において、次の検索結果候補を取得し、ステップＳ１４０２以降の処理を繰り返す。ステップＳ１４０２の判定で、検索結果候補が取得できないと判定された場合（Ｓ１４０２−Ｎｏ）、本処理は終了する。
【００５２】
図１０のステップＳ１００４における各種イベント対応処理として、写真登録処理の具体的な流れを図１５のフローチャートを参照して説明する。本処理は、ＣＰＵ１０１により実行される。
【００５３】
ステップＳ１５０１において、指定された写真の撮影地点が既に代表位置テーブル（例えば、図５（ａ））に登録されているかどうか確認する。ステップＳ１５０２において、撮影地点が既登録か判定し、既登録でなければ（Ｓ１５０２−Ｎｏ）、ステップＳ１５０３に処理は進められる。ステップＳ１５０３において、撮影地点に対して新規の代表位置ＩＤを付与して、撮影地点を代表位置テーブルに登録する。一方、ステップＳ１５０２の判定において、既登録であれば（Ｓ１５０２−Ｙｅｓ）、処理はステップＳ１５０４に進められる。そして、ステップＳ１５０４において、既登録のＩＤを取得して、このＩＤを撮影地点の代表位置ＩＤとする。ステップＳ１５０５において、指定された写真の情報を、ステップＳ１５０３またはＳ１５０４で求めた代表位置ＩＤの情報と共に、写真テーブルに登録し、本処理を終了する。尚、図１５の処理では、画像撮影装置としてデジタルカメラにより撮影された写真の登録を例として説明したが、この例に限定されず、例えば、デジタルビデオカメラにより撮影された動画を登録する場合にも適用可能である。
【００５４】
実施形態１の構成によれば、実際のヒット件数を求めることなく、単一条件における検索結果の概数を、検索に要する処理の負荷を低減した計数処理により計算することが可能になる。また、メッシュを細かく分割して検索範囲内に存在する完全内包メッシュをより多く作成することが可能となり、検索の精度を向上させることができる。
【００５５】
＜実施形態２＞
なお、本発明は上述の実施形態１に限定されるのではなく、本発明の趣旨を逸脱しない限りにおいて適宜変更が可能である。例えば、検索条件を満たすＢツリーのノード数をカウントして検索結果件数の概数を推定することも可能である。与えられた検索条件に合致するか否かの判定をＢツリーインデックスのルートノード上のエントリに限定して行い、そのエントリの下層に存在するノード数をカウントする処理を行うことで検索結果件数の概数を推定する方法も考えられる。これによりインデックスのエントリデータを取り出して判定する計算コストも省略可能となるため、更に計算負荷を軽減して検索結果件数の概数を推定することができる。
【００５６】
本発明は他にも日付や被写体名等を用いた条件を同時に満たす写真を検索する複合条件検索におけるインデックス選定処理にも適用できる。ここで日付、被写体名それぞれにインデックスが作成されていた場合を想定する。通常どちらのインデックスを利用すればより少ない計算量で結果が推定できるかを判断するには事前にデータを分析し、記憶しておく必要がある。この処理を、検索装置を組み込んだ画像撮影装置上で処理するには計算の負荷が大きい。しかしながら、本発明を適用すれば検索結果概数を軽量に推定できるため、事前にデータの実数を分析すること無く検索に有効なインデックスを選定することが可能になる。
【００５７】
（その他の実施例）
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。
【図１】
2013008248.tif 000003
【図２】
2013008248.tif 000004
【図３】
2013008248.tif 000005
【図４】
2013008248.tif 000006
【図５】
2013008248.tif 000007
【図６】
2013008248.tif 000008
【図７】
2013008248.tif 000009
【図８】
2013008248.tif 000010
【図９】
2013008248.tif 000011
【図１０】
2013008248.tif 000012
【図１１】
2013008248.tif 000013
【図１２】
2013008248.tif 000014
【図１３】
2013008248.tif 000015
【図１４】
2013008248.tif 000016
【図１５】
2013008248.tif 000017