(57)【要約】【課題】  最適化されたインデックス検索方法及び装置を提供する。【解決手段】  所定のインデックスから第１キー値に対応する第１フィールドを検索するステップと、所定の検索要請が入力される場合、検索された第１フィールドを基準にインデックスから検索要請に対応するレベルの第２フィールドを検索するステップ、及び検索された第２フィールドに対応する識別子を抽出するステップを含む。【選択図】  図４
2008130084.tif 000002
【特許請求の範囲】
【請求項１】
所定のインデックスから第１キー値に対応する第１フィールドを検索するステップと、
所定の検索要請が入力される場合、前記検索された第１フィールドを基準に前記インデックスから前記検索要請に対応するレベルの第２フィールドを検索するステップと、
前記検索された第２フィールドに対応する識別子を抽出するステップとを含むことを特徴とする最適化されたインデックス検索方法。
【請求項２】
前記インデックスはフィールド単位でキー値を格納することを特徴とする請求項１に記載の最適化されたインデックス検索方法。
【請求項３】
前記インデックスのフィールドは先行キー値及び後行キー値が格納されているノードを示すポインタのうち少なくとも１つを格納することを特徴とする請求項２に記載の最適化されたインデックス検索方法。
【請求項４】
前記先行キー値または前記後行キー値が同じノードに存在すれば、前記ポインタの格納を省略することを特徴とする請求項３に記載の最適化されたインデックス検索方法。
【請求項５】
前記インデックスは他のノードを参照しなくても所定のキー値の上位レベルのキー値を検索できるように現在ノードに前記上位レベルのキー値を別に格納することを特徴とする請求項１に記載の最適化されたインデックス検索方法。
【請求項６】
前記抽出された識別子によって所定のコンテンツのメタデータまたはコンテンツを提供するステップをさらに含むことを特徴とする請求項１に記載の最適化されたインデックス検索方法。
【請求項７】
所定のインデックスから第１キー値に対応する第１フィールドを検索し、所定の検索要請が入力される場合、前記検索された第１フィールドを基準に前記インデックスから前記検索要請に対応するレベルの第２フィールドを検索する検索部と、
前記検索された第２フィールドに対応する識別子を抽出する抽出部とを含むことを特徴とする最適化されたインデックス検索装置。
【請求項８】
前記インデックスはフィールド単位でキー値を格納することを特徴とする請求項７に記載の最適化されたインデックス検索装置。
【請求項９】
前記インデックスのフィールドは先行キー値及び後行キー値が格納されているノードを示すポインタのうち少なくとも１つを格納することを特徴とする請求項８に記載の最適化されたインデックス検索装置。
【請求項１０】
前記先行キー値または前記後行キー値が同じノードに存在すれば、前記ポインタの格納を省略することを特徴とする請求項９に記載の最適化されたインデックス検索装置。
【請求項１１】
前記インデックスは他のノードを参照しなくても所定のキー値の上位レベルのキー値を検索できるように現在ノードに前記上位レベルのキー値を別に格納することを特徴とする請求項７に記載の最適化されたインデックス検索装置。
【請求項１２】
前記抽出された識別子によって所定のコンテンツのメタデータまたはコンテンツを提供するコンテンツ提供部をさらに含むことを特徴とする請求項７に記載の最適化されたインデックス検索装置。
【請求項１３】
前記検索要請を入力できるように複数レベルで構成されたＵＩを提供するＵＩ提供部をさらに含むことを特徴とする請求項７に記載の最適化されたインデックス検索装置。
【請求項１４】
前記検索部は前記複数レベルのうちユーザが指定したレベルのキー値に対応するフィールドを検索することを特徴とする請求項１３に記載の最適化されたインデックス検索装置。
【請求項１５】
前記検索部は前記指定されたレベルを基準に上位または下位レベルのキー値に対応するフィールドを検索することを特徴とする請求項１４に記載の最適化されたインデックス検索装置。
【請求項１６】
前記検索部は前記指定されたレベルを基準に先行または後行キー値に対応するフィールドを検索することを特徴とする請求項１４に記載の最適化されたインデックス検索装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、最適化されたインデックス検索装置に関し、より詳しくは、より効率的なインデックスによる検索方法の提供及び格納空間の活用度を高め、多様なオペレーションを提供してインデックスを利用した外部モジュール具現の効率性を高める最適化されたインデックス検索装置に関するものである。
【背景技術】
【０００２】
メタデータ基盤のＵＩ（ユーザインタフェース）はデジタル機器のコンテンツ量が多くなるにつれて非常に人気あるＵＩ方式になった。対象コンテンツの数が数千、数万個になれば、フォルダ及びファイル名だけで所望のコンテンツを検索するのが難しい反面、メタデータ基盤のＵＩは検索基準を変えながら所望のコンテンツを検索することができ、ユーザがメタデータ値を容易に記憶することができるという長所を有している。
【０００３】
特に、メタデータ基盤のブラウジングの中でもマルチレベルクラスタリング基盤のＵＩはユーザがより便利にコンテンツの分布状況を把握することができ、多様な検索基準を適用して所望のコンテンツに効果的にアクセスできるようにする。また、マルチレベルクラスタリング基盤のＵＩはコンテンツをレベル別にクラスタ化して提示し、クラスタ間の移動のためにインデックスを使用する。
【０００４】
前記マルチレベルクラスタリングとは、Ｎ（Ｎ＞＝１）番目基準によって分けられた各クラスタがさらにＮ＋１番目基準によってより細部的なクラスタに分けられ得ることを意味する。そして、前記クラスタリングとは、類似する部類の個体をグループ化することを意味する。したがって、コンテンツブラウザがクラスタリング基盤のＵＩを採択したということは、全体コンテンツが所定の基準によって複数のクラスタに分けられてユーザに提示されることを意味する。また、ユーザがクラスタ内部をブラウジングしたり、クラスタをスキップしながらブラウジングすることができることを意味する。
【０００５】
図１は写真情報を格納するテーブルのスキーマに関する例示図である。
図１に示すように、テーブルの各レコードについて、年、月、日に関する情報を含むフィールド１２が存在する。テーブルによって管理される写真はマルチレベルクラスタリングＵＩを介して、年、月、日フィールド１２を基準に３つのレベル別にクラスタ化されて画面に表示され、最下位レベルの「日」基準のクラスタはタイトル順に整列されて出力される。このようにマルチレベルクラスタリングＵＩを具現するにはクラスタに属する写真レコードをデータベースから抽出することができなければならない。
【０００６】
例えば、最下位クラスタの１つである２００６年（１レベル）５月（２レベル）１日（３レベル）に属する写真をブラウジングする場合、以下のクエリによって画面に出力するレコードを抽出することができる。
‘Ｓｅｌｅｃｔ＊ｆｒｏｍ  Ｔａｂｌｅ  ｗｈｅｒｅ  年＝２００６  ａｎｄ  月＝５  ａｎｄ  日＝１  ｏｒｄｅｒ  ｂｙ  タイトル’
前記クエリのように複数フィールドに対して所定の条件がある場合、適切なインデックスなしでクエリを処理すれば、写真レコードの個数が増加することによってクエリ処理時間が長くなる。したがって、前記クエリのように「Ｅｑｕａｌ（＝）」条件で構成され、最下位フィールドに対してソーティング条件がある場合、該当フィールドを組み合わせてインデックスのキーにするマルチカラムＢ＋ツリーインデックスを使用するのが好ましい。
【０００７】
図２はマルチカラムＢ＋ツリーインデックスの構成を示す図面である。
図２に示すように、年、月、日、タイトルを組み合わせてインデックスのキーにするマルチカラムＢ＋ツリーインデックス２０を使用すれば、年、月、日が特定の値に決定されたとき、所定の条件を満足するインデックスのエントリが既にタイトル順に整列されて隣接しているため、別途の整列動作を必要としない。そして、前記整列動作の除去はクエリ応答時間を大きく改善する。また、最下位の３レベル（日単位）クラスタでない２レベル（月単位）または１レベル（年単位）でクラスタをブラウジングする場合、マルチカラムＢ＋ツリーインデックスを使用することができる。
【０００８】
しかし、後述する図３に示すように追加のインデックスが必要である。その理由は、前記マルチカラムＢ＋ツリーインデックス２０だけでは上位レベルが各々示すべきクラスタ名を求める時間が長くなるためである。前記マルチカラムＢ＋ツリーインデックス２０だけで１番目レベルで示すべきクラスタ名を得るためにはインデックスのエントリを全部読み込まなければならず、このような方式のクエリ処理はインタラクティブな画面構成に必要な応答時間を満足させることができない。
【０００９】
図３はマルチレベルクラスタリング格納のためのマルチカラムＢ＋ツリーインデックスを示す図面である。
【００１０】
前述したように、前記応答時間を減らすためには、１番目レベル（「年」）に該当するフィールドにどういう値が存在するかを速い時間内に検索できるように追加のインデックスが必要である（３０）。１番目レベルを構成するクラスタを画面に出力したいときは１番目レベルのクラスタ名をインデックスとして使用する。所定のクラスタ（例えば、２００５年に該当するクラスタ）に属するレコードを画面に出力したいときはマルチカラムＢ＋ツリーインデックスから２００５年度（「年＝２００５」）のレコードを順次に読み込む。
【００１１】
また、２番目レベルでクラスタをブラウジングするとき、応答時間を減らすためには「年，月」のマルチカラムＢ＋ツリーインデックスが必要であり、３番目レベルでクラスタをブラウジングするためには「年，月，日」のマルチカラムＢ＋ツリーインデックスが必要である（４０，５０）。したがって、全体レベルを構成するフィールドの数がＮであれば、必要なマルチカラムＢ＋ツリーインデックスの総数はＮ個である。そして、それによって１番目レベルのキー値はＮ個のインデックスに重複して格納され、２番目レベルのキー値はＮ−１個のインデックスに格納されるなど格納空間の浪費の要因となる。
【特許文献１】韓国公開特許第10-2004-0056638号公報
【発明の開示】
【発明が解決しようとする課題】
【００１２】
本発明は、最適化されたインデックス検索方法及び装置を提供し、より効率的なインデックスによる検索方法の提供及び格納空間の活用度を高め、多様なオペレーションを提供してインデックスを利用した外部モジュール具現の効率性を高めるのにその目的がある。
【００１３】
本発明の目的は以上に言及した目的に制限されず、言及していないさらなる目的は下記によって当業者に明確に理解できるものである。
【課題を解決するための手段】
【００１４】
前記目的を達成するために、本発明の実施形態による最適化されたインデックス検索方法は、所定のインデックスから第１キー値に対応する第１フィールドを検索するステップと、所定の検索要請が入力される場合、検索された第１フィールドを基準にインデックスから検索要請に対応するレベルの第２フィールドを検索するステップ、及び検索された第２フィールドに対応する識別子を抽出するステップを含む。
【００１５】
本発明の実施形態による最適化されたインデックス検索装置は、所定のインデックスから第１キー値に対応する第１フィールドを検索し、所定の検索要請が入力される場合、検索された第１フィールドを基準にインデックスから検索要請に対応するレベルの第２フィールドを検索する検索部、及び検索された第２フィールドに対応する識別子を抽出する抽出部を含む。
その他、実施形態の具体的な事項は詳細な説明及び図面に含まれている。
【発明の効果】
【００１６】
前記のような本発明の最適化されたインデックス検索方法及び装置によれば、次のような効果が１つまたはそれ以上ある。
【００１７】
第一に、本発明で提案するインデックスによって格納空間の活用度を高め、多様なオペレーションを提供して外部モジュールの具現が容易であるという長所がある。
【００１８】
第二に、単一レベルでクラスタリングされた場合、既存のＢ＋ツリーインデックスと同様に動作できるように設計されて、１〜Ｎレベルでクラスタリングされたデータに対してＢ＋ツリーインデックスやマルチカラムＢ＋ツリーインデックスを置きかえて適用することができるという長所もある。
【発明を実施するための最良の形態】
【００１９】
本発明の利点及び特徴、そしてそれらを達成する方法は添付する図面とともに詳細に後述する実施形態を参照すれば明確になる。しかし、本発明は以下に開示される実施形態に限定されず、相異なる多様な形態によって具現でき、単に本実施形態は本発明の開示を完全なものにし、本発明の属する技術分野における通常の知識を有する者に発明の範疇を完全に知らせるために提供するものであって、本発明は請求項の範疇によってのみ定義される。明細書全体にわたって同じ参照符号は同じ構成要素を示す。
【００２０】
以下、添付する図面を参照して本発明の好ましい実施形態を詳細に説明する。
【００２１】
図４は本発明の一実施形態による最適化されたインデックス検索装置のブロック図である。
【００２２】
最適化されたインデックス検索装置２００は、格納部２０５、管理部２０７、検索部２１０、ＵＩ提供部２１５、抽出部２２０、コンテンツ提供部２３０を含む。
【００２３】
格納部２０５はインデックスにキー値及び識別子などを格納する。このとき、フィールド単位にキー値を格納することができ、識別子はＲＩＤ（Ｒｅｃｏｒｄ  ＩＤ）であり得る。そして、インデックスのフィールドは先行キー値及び後行キー値が格納されているノードを示すポインタのうち少なくとも１つを格納する。このとき、前記先行キー値または前記後行キー値が同じノードに存在すれば、前記ポインタの格納が省略できる。本発明で提案するインデックス構造は図６ないし図９を参照して説明する。
【００２４】
管理部２０７は前記格納部２０５に格納されている値を管理する。例えば、管理部２０７は格納されている値に対して整列、追加、削除、更新などを行う。
【００２５】
検索部２１０は所定のインデックスから所定のキー値に対応するフィールドを検索する。そして、所定の検索要請が入力される場合、前記検索されたフィールドを基準に前記インデックスから前記検索要請に対応するレベルのフィールドを検索する。このとき、検索部２１０はＵＩ提供部２１５を含むことができる。
【００２６】
ＵＩ提供部２１５はユーザにＵＩを提供し、提供されたＵＩを介してユーザが所定のキー値に対応するフィールドを検索することができるようにする。すなわち、ＵＩ提供部２１５によってユーザが所定のキー値を選択すれば、それに対応するフィールドが検索部２１０によって検索される。これに関する実施形態として図１０を参照する。
【００２７】
抽出部２２０は前記検索部２１０から検索されたフィールドに対応する識別子を抽出する。このとき、識別子はＲＩＤ（レコードＩＤ）値であり得、キー値と対応するＲＩＤ値が抽出される。
【００２８】
コンテンツ提供部はユーザに前記ＲＩＤ値によってコンテンツのメタデータまたはコンテンツを提供する。最適化されたインデックス検索装置２００内に含まれている多様なオペレーションの例は図１０を参照する。
【００２９】
図４に示すそれぞれの構成要素は一種の「モジュール」で構成され得る。前記「モジュール」は、ソフトウェアまたはＦｉｅｌｄ  Ｐｒｏｇｒａｍｍａｂｌｅ  Ｇａｔｅ  Ａｒｒａｙ（ＦＰＧＡ）または注文型半導体（Ａｐｐｌｉｃａｔｉｏｎ  Ｓｐｅｃｉｆｉｃ  Ｉｎｔｅｇｒａｔｅｄ  Ｃｉｒｃｕｉｔ、ＡＳＩＣ）のようなハードウェア構成要素を意味し、モジュールはある役割を行う。しかし、モジュールはソフトウェアまたはハードウェアに限定される意味ではない。モジュールはアドレシングできる格納媒体にあるように構成することができ、１つまたはそれ以上のプロセッサを実行させるように構成することもできる。したがって、一例としてモジュールは、ソフトウェア構成要素、オブジェクト指向ソフトウェア構成要素、クラス構成要素及びタスク構成要素などのような構成要素と、プロセス、関数、属性、プロシージャ、サブルーチン、プログラムコードのセグメント、ドライバ、ファームウェア、マイクロコード、回路、データ、データベース、データ構造、テーブル、アレイ、及び変数を含む。構成要素とモジュールにより提供される機能は、さらに小さい数の構成要素及びモジュールで結合されたり、追加的な構成要素とモジュールにさらに分離できる。
【００３０】
図５は本発明の一実施形態による最適化されたインデックス検索方法のフローチャートである。
まず、検索部２１０は所定のインデックスから所定のキー値に対応するフィールドを検索する（Ｓ５０１）。このとき、従来技術と違って、マルチカラムでインデックスを構成した場合、検索するキー（値）のレベルを指定することができる。すなわち、ユーザに所定のＵＩが提供される場合、ＵＩを介して検索するキー値のレベルを指定することができ、前記キー値に対応するフィールドが検索部２１０によって検索される。前記レベルを指定することは、好ましくはＵＩを介して検索しようとするフィールドに移動して検索要請を入力するという意味である。このとき、検索部２１０は所定の検索要請がＵＩを介して入力される場合、前記検索されたフィールドを基準に前記インデックスから前記検索要請に対応するレベルのフィールドを検索する。より具体的な例は図１０を参照する。
次のステップで、抽出部２２０は検索されたフィールドに対応する識別子を抽出する（Ｓ５１１）。
【００３１】
したがって、コンテンツ提供部２３０はユーザに前記識別子（ＲＩＤ）によってコンテンツのメタデータまたはコンテンツを提供する（Ｓ５２１）。
【００３２】
図６は本発明の一実施形態によるインデックスのリーフノードを示す図面である。
図６に示すように、インデックスのリーフノードにおいて１番目レベルのフィールドは数字値を有し、２番目レベルのフィールドは英文字、３番目レベルのフィールドはハングルでキーが構成されると仮定する。このとき、キーとＲＩＤ（レコードＩＤ）で構成されるエントリはセル６００構造で格納できる。
【００３３】
従来にはキー全体をバイナリストリングで認識してプレフィックスを区分する反面、本実施形態におけるインデックスはフィールド別にキーを区分することができる。例えば、「２００５，１０」と「２００５，１２」で、従来のプレフィックスは「２００５，１＊」になるが、本実施形態では「２００５」になる。したがって、図６に示すように各セルの「１，ａ，イ」６０２と「ｂ，イ」６０４で、本来は「１，ａ，イ」と「１，ｂ，イ」であるが、１番目レベルのフィールド値が同じであるため、これを省略して格納していることが分かる。
【００３４】
まず、＃１００番（ノードのページ番号）ノードに格納されている「３，ａ，ロ」６０６で、１番目レベルのキーである「３」は先行キーが同じノード（＃１００番）に格納されている「２」であり、後行キーが＃３００番ノードに格納されている「４」である。したがって、１番目レベルのキーである「３」は先行キーが格納されているノードである自身が属するノード（＃１００番）を示し、後行キーが格納されているノードとして＃３００番ノードを示している。
【００３５】
このようにインデックスの各フィールドは先行キー及び後行キーが格納されているノードを示すポインタを有しているため、迅速に先後行キーを検索することができる。
【００３６】
また、＃２００番ノードで「３，ａ，ニ」を格納するときには「３，ａ」６０８を「ニ」６１０と分離して格納する。すなわち、「３，ａ，ハ」６０７で「３，ａ，ニ」と異なるキーを有するキーフィールドは３番目レベルのフィールドであるため、「ニ」６１０のみ格納し、「３，ａ」６０８はノードプレフィックスとして別に格納する。ノードプレフィックスを格納しておく理由は、リーフノードによってキーを検索するとき、他のノードを参照しなくても上位レベルのキー値が分かるようにするためである。
【００３７】
例えば、＃３００番ノードの「４，ａ，ロ」６１２位置から３番目レベルのキーである「ロ」の先行キーを検索するとき、他のノードを参照しなくても先行キー値が「３，ｄ，ニ」６１４であることが分かる。以下、図７を参照して具体的なインデックスのノード構造について説明する。
【００３８】
図７は本発明の一実施形態によるインデックスのノード構造を示す。
本発明で提案するインデックス構造の特性はＢ＋−ツリーであり得る。１９７０年代に紹介されたＢ−ツリーはＢ＋−ツリー、Ｂ＊−ツリー、プレフィックスＢ−ツリーなどいくつの変形されたＢ−ツリーバージョンが存在するが、本発明で提案するインデックスはマルチレベルクラスタリングキーも効果的に格納できる変形されたＢ＋−ツリー形態であると言える。また、本発明で提案するインデックスはＢ＋−ツリーのようにバランスツリーであり得る。したがって、いずれのキーを検索してもリーフノードから該当キーを検索できるため、ルートノードから任意のキーを探索する時間は同じである。
【００３９】
一方、キーとＲＩＤで構成されるエントリはセル構造で格納できる。そして、全体キーの長さが可変的であるため、可変長キーを格納するためにセルの格納方式を実際データを格納する領域７０４とデータのオフセットを格納する領域７０２（各データの長さを格納する領域）に区分して可変的に格納空間を活用することができる。すなわち、オフセットを格納する領域７０２は前から後へ、データが格納される領域７０４は後から前へデータを流動的に格納することによって格納空間の活用度を高めることができる。
【００４０】
前記両領域７０２，７０４の大きさを一定に固定させた場合、実際データの長さが長ければ、データが格納される領域７０４は直ちにフル（ｆｕｌｌ）になり、実際データの長さが相対的に非常に短ければ、オフセットが格納される領域７０２はフルになるが、データが格納される領域７０４はまだ空いているため、格納空間を効率的に利用することができない。
【００４１】
そして、前記ノードプレフィックスを格納する場合のためにノードプレフィックスのオフセットを格納する領域７０６が必要である。ノードプレフィックスが要らないノードである場合にはノードプレフィックスオフセット領域７０６が０（ｚｅｒｏ）値に初期化され得る。
【００４２】
また、各フィールドは先行キーが格納されているノードと後行キーが格納されているノードを示すポインタを格納することができる。このとき、ポインタ１つ当たり４バイトを使用する場合、全てのキーに対してポインタを常に２つずつ保つようになれば、それだけ実際データを格納できる空間が減少し得る。
【００４３】
したがって、前記インデックスの各フィールドは現在検索されているキーを基準に先行キーまたは後行キーが現在ノードと同じノードにあれば、先行キーまたは後行キーが格納されているノードを示すポインタの格納を省略することによって、実際データを格納できる空間をさらに確保することができる。
【００４４】
このために、ｉ番目レベルの先行／後行キーが現在ノード内に存在すれば、ｉ＋１番目レベルの先行／後行キーも現在ノード内に存在し、ｉ番目レベルの先行／後行キーが他のノードに存在すれば、ｉ−１番目レベルの先行／後行キーも他のノードに存在する原理を利用することができる。このとき、１番目レベルが最上位レベルであると仮定する。
【００４５】
このように、上位レベルに対する下位レベルの従属性を利用して現在検索されているキーを基準に先行キーまたは後行キーが格納されているノードを示すポインタの格納を省略することができる。そして、上位レベルのキー及び下位レベルのキーが１つのエントリ内に格納されるため、検索するレベルを調節するとき追加ノードのアクセスが発生しない。
【００４６】
前記上位レベルと下位レベルの間の従属性について具体的に例を挙げれば、第１ノード、すなわち［（２０００年，８月，１６日）（２０日）（９月，１日）（２日）（４日）］と第２ノード、すなわち［（２００１年，１月，４日），．．．］で、２０００年９月１日が現在検索されているキー値であるとき、月単位レベルの先行キー（２０００年８月）が現在ノードに存在するため、それよりさらに細分化されたクラスタリングレベルである日単位の先行キーが現在ノードに存在する。すなわち、月単位の値が変更されたことは日単位のクラスタリングでも値が変更されていることを意味する。同様に２０００年８月１６日が現在検索されているキー値であるとき、月単位レベルの後行キーが現在ノードにあるため、日単位の後行キーも現在ノードにあるということが保障される。
【００４７】
以下、図８及び図９を参照してインデックスのセル構造について説明する。このとき各フィールドに入力される値の単位はビットまたはバイト単位であり得る。単位は図面に示されており、以下の説明では単位を省略して所定値と表示する。
【００４８】
図８は本発明の一実施形態によるインデックスのリーフノードにおけるセルの構造を示す図面である。
図８に示すように、カウント情報領域８１０におけるフィールドカウント（Ｆｉｅｌｄ  Ｃｎｔ）フィールド８０１は現在検索されているキーが存在するセルがいくつのフィールドで構成されているかを示す。セルのフィールドカウントフィールド８０１によってインデックスから各レベル別の境界地点を検索することができる。すなわち、同じノード内では所定レベルの境界地点をセルのフィールドカウント値で検索し、所定レベルの境界地点が同じノード内にない場合にはノードプレフィックス値を利用して検索すれば、境界地点を迅速に検索することができる。これによって、各レベル別に同じキー値を有するエントリの最初と最後を迅速に検索することができる。
【００４９】
そして、先行カウントフィールド８０２は後述する先行ポインタ（Ｐｒｅｖ  Ｐｔｒ）の個数を示し、後行カウントフィールド８０３は後述する後行ポインタ（Ｎｅｘｔ  Ｐｔｒ）の個数を示す。パディング（Ｐａｄｄｉｎｇ）フィールド８０４は所定の予約（ｒｅｓｅｒｖｅｄ）された格納空間である。
【００５０】
ポインタ領域８２０はレベル別に先行キーまたは後行キーが存在するノードを示すポインタを格納する。具体的に先行ポインタフィールド８２２はｉ番目レベルでブラウジングするとき、ｉ番目レベルを基準に先行キーが格納されているノードのポインタを格納し、このときポインタはノードのページ番号であり得る。例えば、先行ポインタ１は１番目レベルを基準に先行キーが格納されているノードを示すポインタを格納する。そして、先行ポインタ２は２番目レベルを基準に先行キーが格納されているノードを示すポインタを格納する。また、先行ポインタ３は３番目レベルを基準に先行キーが格納されているノードを示すポインタを格納する。
【００５１】
後行ポインタフィールド８２４はｉ番目レベルでブラウジングするとき、ｉ番目レベルを基準に後行キーが格納されているノードを示すポインタを格納する。例えば、後行ポインタ１は１番目レベルを基準に後行キーが格納されているノードを示すポインタを格納する。そして、後行ポインタ２は２番目レベルを基準に後行キーが格納されているノードを示すポインタを格納する。また、後行ポインタ３は３番目レベルを基準に後行キーが格納されているノードを示すポインタを格納する。
【００５２】
次いで、キー値を格納する領域８３０で、キーサイズフィールド８３２はキーｉのフィールド長を示す。例えば、全体レベル数をｘとすれば（すなわち、年，月，日であれば、ｘ＝３）、キーサイズはｘ−Ｎ＋ｉ番目レベルのフィールドデータ長（バイト単位）を有するようになる。そして、キーフィールド８３４は所定レベルのデータを示し、ｘ−Ｎ＋Ｉ番目レベルのフィールドデータを格納する。
【００５３】
例えば、カウント情報領域８１０で、フィールドカウントフィールド８０１の値が２である場合、キーサイズは前記ｘ−Ｎ＋ｉで３−２＋１であり、キーサイズフィールド８３２は２番目レベルのフィールドデータ長、すなわち月データの長さを示す。そして、キーフィールド８３４は月データ値を格納する。
【００５４】
前記図６のデータに基づいて説明すれば、まず前記図６で１番目レベルを基準に全てのキーを順に抽出するときは「１，２，３，４」に抽出でき、２番目レベルを基準に全てのキーを順に抽出するときは「１ａ，１ｂ，２ａ，３ａ，３ｂ，３ｃ，３ｄ，４ａ，５ｂ」に抽出できる。そして、３番目レベルを基準に全てのキーを順に抽出するときは「１ａイ，１ｂイ，２ａロ，２ａハ，２ａニ，３ａロ，３ａハ，３ａニ，３ａホ，３ｂイ，３ｂロ」に抽出できる。したがって、３，ａ，ロ６０６（または３ａロ）でフィールドカウントフィールド８０１は３値、先行カウントフィールド８０２は０値、後行カウントフィールド８０３は２値を格納する。後行ポインタ１フィールド８２４は１番目レベル（すなわち３）を基準に後行キー（すなわち４）が＃３００ノードに格納されているため、＃３００が格納される。先行ポインタフィールド８２２は先行カウントフィールド８０２の値が０（ｚｅｒｏ）、すなわち１番目レベル（すなわち３）、２番目レベル（すなわち３ａ）、３番目レベル（すなわち３ａロ）の以前値が全て現在ノードである＃１００に存在するため、先行ポインタが格納されない。後行ポインタ２フィールド８２４は２番目レベル（すなわち３ａ）を基準に後行キー（すなわち３ｂ）が＃２００ノードに格納されているため、＃２００が格納される。後行ポインタ３フィールド８２４は後行カウントフィールド８０３が２値で、３番目レベル（すなわち３ａロ）の次の値が現在ノードである＃１００に存在するため、格納される後行ポインタ値が存在しない。また、キーサイズフィールド８３２でキーサイズ１フィールドは４値、キーサイズ２フィールドは１値、キーサイズ３フィールドは２値が格納され、キーフィールド８３４でキー１フィールドは３値、キー２フィールドはａ値、キー３フィールドはロ値が格納される。
【００５５】
一方、内部ノードでは連続的なキーの検索が行われないため、互いに異なるノードにあるキー間にリンクを維持する必要がない。したがって、リーフノードのセル構造が有している先行ポインタ、及び後行ポインタは内部ノードのセル構造では除去できる。内部ノードでもプレフィックスを分離した構造を有することができ、または一般的なマルチカラムＢ＋ツリーインデックスのように全体キー値を常に保つこともできる。
【００５６】
前述したように、ノードプレフィックスは以前ノードにある隣接キーで既にプレフィックスとして使用された上位レベルフィールド値であっても現在ノードで上位レベルフィールド値を知るために再記録することができる。ノードプレフィックスは下位レベルフィールド値と同じセルに格納せずに、ノードプレフィックス部分のみ別個のセルで構成することができる。
【００５７】
図９は本発明の一実施形態によるノードプレフィックスのセル構造の例示図である。
図９は前記図６で例示した＃２００ノードのノードプレフィックス「３，ａ」９１０のセル構造を前記図８を参考して示す。すなわち、＃２００ノードのノードプレフィックス「３，ａ」９１０のセル構造で、現在キーが２つのフィールドで構成されているため、フィールドカウントフィールド８０１には２値、先行／後行ポインタ個数がないため、先行／後行カウントフィールド８０２，８０３は０値が格納される。そして、キーサイズフィールド８３２には「３，ａ」９１０それぞれのキー値のサイズに対して１値と２値、そしてキーフィールド８３４のキー値として３とａ値が格納される。各値の単位は前記図８を参照する。
【００５８】
図１０は本発明の一実施形態によるインデックス検索のためのＵＩを示す図面である。
図１０に示すように、ユーザはＵＩを介する検索要請によって所望のコンテンツを検索してサービスを受けることができる。このとき、本発明で提案するインデックス構造を利用した各オペレーション（関数）（ｆｉｎｄ＿ｋｅｙ，ｆｉｎｄ＿ｎｅｘｔ＿ｅｎｔｒｙ，ｆｉｎｄ＿ｐｒｅｖ＿ｅｎｔｒｙ，ｆｉｎｄ＿ｆｉｒｓｔ＿ｋｅｙ，ｆｉｎｄ＿ｌａｓｔ＿ｋｅｙ，ｆｉｎｄ＿ｎｅｘｔ＿ｋｅｙ，ｆｉｎｄ＿ｐｒｅｖ＿ｋｅｙ，ｆｉｎｄ＿ｕｐｐｅｒ＿ｋｅｙ，ｆｉｎｄ＿ｄｏｗｎ＿ｋｅｙ）が利用できる。そして、優先順位が最も高いクラスタリングキー（またはキー）のレベルが１レベルと仮定するとき、年単位を１レベル、月単位を２レベル、日単位を３レベルとする。また、図示のように各フィールド別にキー値及び識別子（ＲＩＤ）情報を含んでおり、ユーザの選択によってフィールド間の移動が可能である。
【００５９】
すなわち、ユーザがＵＩを介してフィールド間を移動するとき検索要請が入力されるようになる。例えばＵＩを介して２００５年５月（２００５，５と表記）フィールド１０００に移動すれば、２００５，５値（２レベル）が入力されて該当キー値とマッチング（対応）する識別子が抽出される。このとき、前記抽出された識別子が複数である場合、該当フィールド１０００の１番目値が返還でき、前記フィールド内の識別子と対応するコンテンツまたはコンテンツのメタデータがユーザに提供できる。このようにＵＩを介してユーザが検索しようとするキー値のレベル（２レベル）を直ちに指定することができ、指定されたレベルを基準に多様なオペレーションを利用してフィールドを検索することができる。
【００６０】
以下、オペレーションを図１０を参考してより具体的に説明する。
まず、ｆｉｎｄ＿ｋｅｙオペレーションは、検索しようとするキー値とマッチングするエントリ（またはフィールド）をリーフノードから検索して識別子、すなわちＲＩＤを返還する。キー値とマッチングするＲＩＤが多い場合には１番目ＲＩＤを返還する。このとき、従来技術と違って、マルチカラムでインデックスを構成した場合に検索するキーのレベルを指定することができる。例えば図１０で、ユーザがＵＩを介して「２００５，５」フィールド１０００に移動した場合、ＲＩＤは５７１１（ａ）が返還される。すなわち、「２００５，５」フィールド１０００は下位レベルとして５、６フィールドを含み、各フィールドは複数のＲＩＤ値を含んでいる。このとき、１番目ＲＩＤ値である５７１１（ａ）が返還できる。そして、検索されたフィールド１０００内の識別子に対応するコンテンツまたはコンテンツのメタデータがユーザに提供できる。また、以後に動作するオペレーションは「２００５，５」キー値（またはフィールド）を基準に検索を行うことができる。
【００６１】
次に、ｆｉｎｄ＿ｎｅｘｔ＿ｅｎｔｒｙオペレーションは、最も最近に検索したエントリの次のエントリを検索してキーとＲＩＤを返還する。現在検索中であるレベルのキー値が変更されれば、キーを構成するフィールド値の中で変化されたフィールドのうち最上位レベル番号をともに返還する。例えば、２番目レベルを基準にエントリを検索するうちに、１番目及び２番目レベルのフィールド値が変更されて新しい２レベルキーを得るようになればレベル番号１を返還する。例えば図１１で、「２００５，５」をｆｉｎｄ＿ｋｅｙオペレーションで検索した場合、ｆｉｎｄ＿ｎｅｘｔ＿ｅｎｔｒｙオペレーションを行えば、ＲＩＤは５７１２（ｂ）が返還される。
【００６２】
次に、ｆｉｎｄ＿ｐｒｅｖ＿ｅｎｔｒｙオペレーションは、最も最近に検索したエントリの以前のエントリを検索してキーとＲＩＤを返還する。現在検索中であるレベルのキー値が変更されれば、キーを構成するフィールド値の中で変化されたフィールドのうち最上位レベル番号をともに返還する。例えば、２番目レベルを基準にエントリを検索するうちに、１番目及び２番目レベルのフィールド値が変更されて新しい２レベルキーを得るようになればレベル番号１を返還する。例えば図１１で、「２００５，５」をｆｉｎｄ＿ｋｅｙオペレーションで検索した場合、ｆｉｎｄ＿ｐｒｅｖ＿ｅｎｔｒｙオペレーションを行えば、新しいキー値「２００５，４」とＲＩＤは５７１０（ｃ）が返還される。このとき、２番目レベルを基準にエントリを検索するうちに、２番目フィールド値が５から４に変わったため、レベル番号２がともに返還される。
【００６３】
次に、ｆｉｎｄ＿ｆｉｒｓｔ＿ｋｅｙオペレーションは、リーフノード上で１番目キーと該当キーを有する１番目ＲＩＤを返還する。このとき、従来技術と違って、変換されるキーのレベルｉを入力することができる。以後に動作するオペレーションはｉレベルを基準にキー値を検索する。例えば図１１で、２レベルに対してｆｉｎｄ＿ｆｉｒｓｔ＿ｋｅｙオペレーションを行えば、「１９９３，１」キーを検索し、ＲＩＤは「０００１」（ｄ）が返還される。
【００６４】
次に、ｆｉｎｄ＿ｌａｓｔ＿ｋｅｙオペレーションは、リーフノード上で最後キーと該当キーを有する最後ＲＩＤを返還する。上位レベルのフィールド値が変更されれば、最上位レベル番号をともに返還する。例えば、３番目レベルを基準に検索するうちに、１番目及び２番目レベルのフィールド値が変更されれば、最上位レベル番号１を返還する。このとき、従来技術と違って、返還されるキーのレベルｉを入力することができる。以後に動作するオペレーションはｉレベルを基準にキー値を検索する。例えば図１１で、２番目レベルに対してｆｉｎｄ＿ｌａｓｔ＿ｋｅｙオペレーションを行えば、「２００６，１２」キーを検索し、ＲＩＤは「６２２０」（ｅ）が返還される。
【００６５】
次に、ｆｉｎｄ＿ｎｅｘｔ＿ｋｅｙオペレーションは、リーフノードで最も最近に検索したキー値の後行キー値を検索してＲＩＤとともに返還する。上位レベルのフィールド値が変更されれば、最上位レベル番号をともに返還する。例えば、３番目レベルを基準に検索するうちに、１番目及び２番目レベルのフィールド値が変更されれば、最上位レベル番号１を返還する。このとき、従来技術と違って、最近に検索したキーのレベルがｉ番目であれば、該当レベル上における後行キーを返還することができる。例えば図１１で、「２００５，５」をｆｉｎｄ＿ｋｅｙオペレーションで検索した場合、ｆｉｎｄ＿ｎｅｘｔ＿ｋｅｙオペレーションを行えば、新しいキー値「２００５，６」とＲＩＤは５７２０（ｆ）が返還される。
【００６６】
また、ｆｉｎｄ＿ｎｅｘｔ＿ｋｅｙオペレーションは現在検索中であるキーのレベルをｉとするとき、検索完了条件はフィールドカウント値が（最大フィールドカウント＋１−ｉ）と同じかあるいは大きいものを検索したり、これ以上検索するノードがないときである。そして、検索方向は後述するｒｅａｄ＿ｋｅｙ＿ｈｅａｄｅｒオペレーションの動作を行って後行カウント値などを得る。後行カウント値がｉより小さい場合は後行キーが現在ノードにある場合であるため、現在ノード内のセルを現在セル位置から後へ検索する。後行カウント値がｉと同じかあるいは大きい場合は後行キーが他のノードにある場合であるため、後行ポインタ（Ｎｅｘｔ  Ｐｔｒｉ）が示すノードで１番目セルから後へ検索する。
【００６７】
次に、ｆｉｎｄ＿ｐｒｅｖ＿ｋｅｙオペレーションは、リーフノードから最も最近に検索したキー値の先行キー値を検索してＲＩＤとともに返還する。上位レベルのフィールド値が変更されれば、最上位レベル番号をともに返還する。例えば、３番目レベルを基準に検索するうちに、１番目及び２番目レベルのフィールド値が変更されれば、最上位レベル番号１を返還する。このとき従来技術と違って、最近に検索したキーのレベルがｉ番目であれば、該当レベル上における先行キーを返還することができる。例えば図１１で、「２００５，５」をｆｉｎｄ＿ｋｅｙオペレーションで検索した場合、ｆｉｎｄ＿ｐｒｅｖ＿ｋｅｙオペレーションを行えば、新しいキー値「２００５，４」とＲＩＤは５７０６（ｇ）が返還される。
【００６８】
また、ｆｉｎｄ＿ｐｒｅｖ＿ｋｅｙオペレーションの検索完了条件は現在検索中であるキーのレベルをｉとするとき、フィールドカウント値が（最大フィールドカウント＋１−ｉ）と同じかあるいは大きいものを検索したり、これ以上検索するノードがないときである。そして、検索方向は後述するｒｅａｄ＿ｋｅｙ＿ｈｅａｄｅｒオペレーションの動作を行って先行カウント値などを得る。先行カウント値がｉより小さい場合は先行キーが現在ノードにある場合であるため、現在ノード内のセルを現在セル位置から前へ検索する。先行カウント値がｉと同じかあるいは大きい場合は先行キーが他のノードにある場合であるため、先行ポインタ（Ｐｒｅｖ  Ｐｔｒｉ）が示すノードで最後セルから最初セル方向へ検索する。
【００６９】
次に、ｆｉｎｄ＿ｕｐｐｅｒ＿ｋｅｙオペレーションは、現在検索中であるキーのレベルがｉであれば、検索レベルをｉ−１に変更する。以後に行う全ての演算はｉ−１レベルキーを基準に行われる。
【００７０】
また、ｆｉｎｄ＿ｕｐｐｅｒ＿ｋｅｙペレーションは現在検索中であるキーのレベルをｉとするとき、検索完了条件はｉが１であったり、（現在レベルが最上位レベルであるため）フィールドカウント（Ｆｉｅｌｄ  Ｃｎｔ）が（最大フィールドカウント＋１−ｉ）より大きい場合（現在セルに上位レベルのキーが含まれている）である。そして、検索方向は後述するｒｅａｄ＿ｋｅｙ＿ｈｅａｄｅｒオペレーションの動作を行ってフィールドカウント値などを得る。現在ノード内で検索するが、現在位置から検索完了条件を満足するまで前のセルへ移動しながら検索する。現在ノードの１番目エントリでも検索できない場合、ノードプレフィックスから上位キーを検索する。
【００７１】
次に、ｆｉｎｄ＿ｄｏｗｎ＿ｋｅｙオペレーションは、現在検索中であるキーのレベルがｉであれば、ｉ＋１番目レベルのキーを返還する。以後に行う全ての演算はｉ＋１レベルキーを基準に行われる。
【００７２】
また、ｆｉｎｄ＿ｄｏｗｎ＿ｋｅｙオペレーションは現在検索中であるキーのレベルをｉとするとき、ｉが最大フィールドカウントと同じであれば、現在キーレベルが最下位レベルであるため、返還する下位キー値がない。ｉが最大フィールドカウントと異なれば、現在セルから下位キー値を検索して返還する。
【００７３】
ｒｅａｄ＿ｋｅｙ＿ｈｅａｄｅｒオペレーションは現在検索中であるレベルのキー値を含むセルのヘッダ値を読み取る動作をする。ｆｉｎｄ＿ｎｅｘｔ＿ｅｎｔｒｙオペレーション、ｆｉｎｄ＿ｐｒｅｖ＿ｅｎｔｒｙオペレーションまたはｆｉｎｄ＿ｕｐｐｅｒ＿ｋｅｙオペレーションなどを行った場合、最近検索したセルが検索中であるレベルのキーを含んでいないことがある。すなわち、現在検索中であるレベルをｉとし、現在検索カーソルが位置するセルにおけるフィールドカウント値がｆとすれば、ｆ＜（最大フィールドカウント＋１−ｉ）である場合が発生する。このとき、検索中であるキー値は既に知っている状態である。したがって、キー値と検索レベルｉを入力してｆｉｎｄ＿ｋｅｙオペレーションを行って該当キーを含むセルを検索することができる。
【００７４】
また、ｒｅａｄ＿ｋｅｙ＿ｈｅａｄｅｒオペレーションはｆ＞＝（最大フィールドカウント＋１−ｉ）である場合は現在セルからｉ番目キーに該当する情報を読み取る。ｆ＜（最大フィールドカウント＋１−ｉ）である場合はｆｉｎｄ＿ｋｅｙオペレーションを行って検索したセルからｉ番目キーに該当する情報を読み取る。
【００７５】
以上、添付する図面を参照して本発明の実施形態を説明したが、本発明の属する技術分野における通常の知識を有する者は本発明がその技術的思想や必須的な特徴を変更せずに他の具体的な形態によって実施できることを理解することができる。したがって前述した実施形態はすべての面で例示的なものであって、限定的なものではないことを理解しなければならない。
【図面の簡単な説明】
【００７６】
【図１】写真情報を格納するテーブルのスキーマに関する例示図である。
【図２】マルチカラムＢ＋ツリーインデックスの構成を示す図である。
【図３】マルチレベルクラスタリング格納のためのマルチカラムＢ＋ツリーインデックスを示す図である。
【図４】本発明の一実施形態による最適化されたインデックス検索装置のブロック図である。
【図５】本発明の一実施形態による最適化されたインデックス検索方法のフローチャートである。
【図６】本発明の一実施形態によるインデックスのリーフノードを示す図である。
【図７】本発明の一実施形態によるインデックスのノード構造を示す図である。
【図８】本発明の一実施形態によるインデックスのリーフノードにおけるセルの構造を示す図である。
【図９】本発明の一実施形態によるノードプレフィックスのセル構造の例示図である。
【図１０】本発明の一実施形態によるインデックス検索のためのＵＩを示す図である。
【符号の説明】
【００７７】
２１０      検索部
２２０      抽出部
【図１】
2008130084.tif 000003
【図２】
2008130084.tif 000004
【図３】
2008130084.tif 000005
【図４】
2008130084.tif 000006
【図５】
2008130084.tif 000007
【図６】
2008130084.tif 000008
【図７】
2008130084.tif 000009
【図８】
2008130084.tif 000010
【図９】
2008130084.tif 000011
【図１０】
2008130084.tif 000012