　データベースの内容が変わらない「Read Only DB」であれば、あらかじめインクリメンタルサーチに対応したインデックスをプログラム側で作成して保持しておくことも可能だ。しかし、電子番組ガイド（EPG：Electronic Program Guide）など、データが随時変わる用途では、こうした方法は取れない。結局、LINK条件を使いながら、1文字入力されるたびにSELECTを回すことになる。レコード数が多いとこの操作に時間がかかってしまい、操作性を阻害する。

　ここで活躍するのが、「絞り込みインデックス」と呼ばれる木構造のインデックスである。図2は電話帳を例に取ったものだが、インデックスそのものがインクリメンタルサーチに対応したものになっている。絞り込んだ文字について、次候補の件数と文字列を一発で引けるためレスポンスタイムは最小に抑えられ、操作性を阻害することがない。もちろん、絞り込みインデックスを生成したテーブルに行のINSERTを行うと、それに合わせてインデックスが反映されるから、EPGのような用途でも問題なく利用できる。

図2　絞り込みインデックスの構造。データベースにデータを格納するタイミングで次候補の件数と文字列を計算する

　プログラム的にはフェッチを拡張し、カーソルを使ってこの木構造を取得するようになっているという。従って、カーソルの操作周りを拡張するだけでインクリメンタルサーチの機能が利用できることになる。

空間検索

　空間検索とは、2次元の地図上における検索を指す。具体的には、携帯などによる道案内やカーナビのナビゲーション機能がターゲットだ。データベースの中にあらかじめ座標と属性を格納しておき、検索条件で「空間」を指定すると、該当するデータを返してくれるというものだ（図3）。

図3　空間検索

　空間検索は、「OpenGIS」（地理情報システムの標準化団体）の認定を受けた地理データ保持方式をベースに、多少機能を省いて高速かつ省リソースで検索できるようにチューニングしたGeomPoint型（注）というデータタイプを用いている。

※注

GeomPoint型では、地点の属性値をユーザーが自由に持てるようになっている。この属性値に建物の種別などを持たせることで図3の検索例のような機能を実現している。

　図3では2つの検索例が示されている。最初の例は座標範囲として中心円情報（円の中心座標と半径）を与えたもの、2つ目の例は折線情報（車の進行ルートに沿って「道の左側何メートル」という範囲を生成する関数）を与えたものである。

　同じことを通常のSQLで行うとすると、かなり面倒な作業になるのは容易に想像できる。例えば範囲が円を描いている時点で、単に東西南北の幅を与えるだけでは駄目なことが分かる。それでは矩形の範囲（正方形）になってしまうからだ。SQLで円の内部かどうかを計算するのは面倒だから、一度正方形の領域に含まれるデータを全部取り出し、次にそのデータについて円の中に入っているかどうかの判定を行ってから出力、という形になるだろう。これは折線情報のケースも同じであるが、こちらは「道の左側」の判定から始めなければならないため、処理はさらに遅くなるだろう。こうしたことを考えると、いかにこの機能拡張が特定分野に大きな効果を及ぼすか、想像に難くない。