特許 5959592 データベース管理方法、プログラム及び該管理システム、並びにデータベースのツリー構造

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】5959592

(24)【登録日】2016年7月1日

(45)【発行日】2016年8月2日

(54)【発明の名称】データベース管理方法、プログラム及び該管理システム、並びにデータベースのツリー構造

(51)【国際特許分類】

   G06F 17/30 20060101AFI20160719BHJP

   G06F 12/00 20060101ALI20160719BHJP

【ＦＩ】

   G06F17/30 414A

   G06F12/00 520A

   G06F17/30 140

【請求項の数】17

【全頁数】19

(21)【出願番号】特願2014-209249(P2014-209249)

(22)【出願日】2014年10月10日

(65)【公開番号】特開2015-79508(P2015-79508A)

(43)【公開日】2015年4月23日

【審査請求日】2014年10月10日

(31)【優先権主張番号】10-2013-0122951

(32)【優先日】2013年10月15日

(33)【優先権主張国】KR

(73)【特許権者】

【識別番号】505205812

【氏名又は名称】ネイバー コーポレーション

【氏名又は名称原語表記】ＮＡＶＥＲ Ｃｏｒｐｏｒａｔｉｏｎ

(74)【代理人】

【識別番号】110000408

【氏名又は名称】特許業務法人高橋・林アンドパートナーズ

(72)【発明者】

【氏名】徐 敬 植

(72)【発明者】

【氏名】金 甲 榮

(72)【発明者】

【氏名】李 基 烈

【審査官】 吉田 誠

(56)【参考文献】

【文献】 特開２００８−１３００８４（ＪＰ，Ａ）

【文献】 特開２００４−０６２４７５（ＪＰ，Ａ）

【文献】 特開平０９−１６７１１１（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ １７／３０

Ｇ０６Ｆ １２／００

(57)【特許請求の範囲】

【請求項1】

インデックス管理部が、各ページが含むことができる複数個のレコードの原本キー値の下限値である第１区分キー値をＬＦＫ（lower fence key）として保存し、前記複数個のレコードの原本キー値の上限値である第２区分キー値をＵＦＫ（upper fence key）として保存し、
前記インデックス管理部が、前記ページをなす前記複数個のレコードの原本キー値のうち共通領域をプレフィックスとして抽出し、
前記インデックス管理部が、前記複数個のレコードの原本キー値から、前記プレフィックスに該当する部分を除外した残りの部分を保存することを含むデータベース管理方法。

【請求項2】

前記各レコードは、複数個のキー値を含むマルチカラム形態のレコードであることを特徴とする請求項１に記載のデータベース管理方法。

【請求項3】

前記複数個の原本キー値のうち、１枚のページをなすレコードが同一値を有するキー値が、前記プレフィックスとして抽出されることを特徴とする請求項２に記載のデータベース管理方法。

【請求項4】

前記各ページは、Ｂツリー構造またはＢ＋ツリー構造のリーフノードであることを特徴とする請求項１ないし３のいずれか１項に記載のデータベース管理方法。

【請求項5】

前記データベース管理方法は、
前記インデックス管理部により、前記ページに含まれたレコードの前記原本キー値を復元することをさらに含み、
前記原本キー値を復元することは、
前記ページに、前記ＬＦＫと前記ＵＦＫとが存在するか否かということを確認し、
前記ページに、前記ＬＦＫと前記ＵＦＫとが存在する場合、前記ＬＦＫと前記ＵＦＫとを比較演算し、そこに共通するプレフィックスを抽出し、
前記抽出されたプレフィックスと、前記レコードのキー値とを結合して前記原本キー値を復元することを含むことを特徴とする請求項１に記載のデータベース管理方法。

【請求項6】

当該ページに、前記ＬＦＫと前記ＵＦＫのいずれかが存在しない場合、
各レコードに保存されたキー値が前記原本キー値であることを特徴とする請求項５に記載のデータベース管理方法。

【請求項7】

前記データベース管理方法は、
前記インデックス管理部により、前記ページに新たなレコードを追加するか、あるいは既存のレコードを変更することをさらに含み、
前記新たなレコードを追加するか、あるいは前記既存のレコードを変更することは、
前記ページに、前記ＬＦＫと前記ＵＦＫとが存在するか否かということを確認し、
前記ページに、前記ＬＦＫと前記ＵＦＫとが存在する場合、前記ＬＦＫと前記ＵＦＫとを比較演算し、そこに共通するプレフィックスを抽出し、
追加されたり、あるいは変更されたりするレコードから、前記プレフィックスが除外された残りのキー値をレコードとして追加したり、あるいはそこで変更したりすることを含むことを特徴とする請求項１ないし６のいずれか１項に記載のデータベース管理方法。

【請求項8】

前記ページに、前記ＬＦＫと前記ＵＦＫのいずれかが存在しない場合、
前記プレフィックスが抽出されず、前記ページにレコードが追加されたり、あるいはそこで変更されたりすることを特徴とする請求項７に記載のデータベース管理方法。

【請求項9】

Ｂツリー構造またはＢ＋ツリー構造のデータベース管理方法において、
Ｂツリー構造またはＢ＋ツリー構造のインデックスが生成され、
前記インデックスで、所定のレコードが復元され、
前記インデックスに所定のレコードが追加されたり、あるいはそこで変更されたりすることを含み、
前記インデックスが生成されることは、
一つ以上のリーフノードの少なくとも一端部に、前記リーフノードに属し得る原本キー値の下限値である第１区分キー値がＬＦＫ（lower fence key）として保存されるか、あるいは当該リーフノードに属し得る原本キー値の上限値である第２区分キー値がＵＦＫ（upper fence key）として保存され、前記リーフノードに属する原本キー値のうち共通領域をプレフィックスとして抽出され、前記リーフノードに属する原本キー値から、共通領域である前記プレフィックスに該当する部分を除いた残りのキー値が前記リーフノードに保存されることを含むデータベース管理方法。

【請求項10】

インデックス管理部により、各ページが含むことができる複数個のレコードの原本キー値の下限値である第１区分キー値をＬＦＫ（lower fence key）として保存し、前記複数個のレコードの原本キー値の上限値である第２区分キー値をＵＦＫ（upper fence key）として保存し、
前記インデックス管理部により、前記ページをなす前記複数個のレコードの原本キー値のうち共通領域をプレフィックスとして抽出し、
前記インデックス管理部により、前記複数個のレコードの原本キー値から、前記プレフィックスに該当する部分を除外した残りの部分を保存することを実行するプログラム。

【請求項11】

Ｂツリー構造またはＢ＋ツリー構造のインデックスが生成され、
前記インデックスで所定のレコードが復元され、
前記インデックスに所定のレコードが追加され、あるいはそこで変更されたりすることを実行するプログラムであり、
前記インデックスが生成されることは、
一つ以上のリーフノードの少なくとも一端部に、前記リーフノードに属し得る原本キー値の下限値である第１区分キー値がＬＦＫ（lower fence key）として保存されるか、あるいは前記リーフノードに属し得る原本キー値の上限値である第２区分キー値がＵＦＫ（upper fence key）として保存され、前記リーフノードに属する原本キー値のうち共通領域がプレフィックスとして抽出され、前記リーフノードに属する原本キー値から、共通領域である前記プレフィックスに該当する部分を除いた残りのキー値が前記リーフノードに保存されることを含むプログラム。

【請求項12】

特定テーブルに含まれたレコードの引出し要請、及び前記レコードに含まれた少なくとも１つのカラムに対する更新要請が共に定義された質疑文を受信して分析する質疑文分析部と、
前記分析された質疑文を実行するための実行計画を生成する実行計画生成部と、
前記実行計画により、前記レコードの引き出し、及び前記少なくとも１つのカラムに係わる更新を行うことにより、前記実行計画を実行する実行計画実行部と、
特定テーブルに係わるインデックスを生成し、前記インデックスの各ページに属し得る複数個の前記レコードの原本キー値の下限値である第１区分キー値をＬＦＫ（lower fence key）として保存するか、
あるいは前記レコードの原本キー値の上限値である第２区分キー値をＵＦＫ（upper fence key）として保存するインデックス生成部を含むインデックス管理部と、を含み、
前記インデックス生成部は、前記各ページをなす前記複数個のレコードの原本キー値のうち共通領域をプレフィックスとして抽出し、前記各ページをなす前記複数個のレコードの原本キー値から、共通領域である前記プレフィックスに該当する部分を除いた残りのキー値を前記インデックスに保存することを特徴とするデータベース管理システム。

【請求項13】

前記各レコードのうち、前記ＬＦＫまたは前記ＵＦＫが保存されるレコード以外のレコードには、各レコードの原本キー値のうち、前記プレフィックスを除いたキー値だけが保存されることを特徴とする請求項１２に記載のデータベース管理システム。

【請求項14】

前記インデックス管理部は、
前記インデックスの各ページに含まれたレコードから前記原本キー値を復元するレコード復元部をさらに含むことを特徴とする請求項１２に記載のデータベース管理システム。

【請求項15】

前記レコード復元部は、
前記ページに、前記ＬＦＫと前記ＵＦＫとが存在するか否かということを確認し、前記ページに、前記ＬＦＫと前記ＵＦＫとが存在する場合、前記ＬＦＫと前記ＵＦＫとを比較演算して前記プレフィックスを抽出し、抽出された前記プレフィックスと前記レコードの値とを結合して前記原本キー値を復元することを特徴とする請求項１４に記載のデータベース管理システム。

【請求項16】

前記インデックス管理部は、
前記インデックスの各ページに新たなレコードを追加するか、あるいは既存のレコードを変更するレコードアップデート部をさらに含むことを特徴とする請求項１２ないし１５のいずれか１項に記載のデータベース管理システム。

【請求項17】

前記レコードアップデート部は、
前記ページに、前記ＬＦＫと前記ＵＦＫとが存在するか否かということを確認し、前記ページに、前記ＬＦＫと前記ＵＦＫとが存在する場合、前記ＬＦＫと前記ＵＦＫとを比較演算して前記プレフィックスを抽出し、追加されたり、あるいは変更されたりするレコードから、前記プレフィックスが除外された残りのデータを、前記ページにレコードとして追加または変更することを特徴とする請求項１６に記載のデータベース管理システム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、データベース管理方法及び該管理システム、並びにデータベースのツリー構造に係り、詳細には、インデックス圧縮技法（index compression method）を利用したデータベース管理方法及び該管理システム、並びにデータベースのツリー構造に関する。

【背景技術】

【0002】

データベース管理システム（ＤＢＭＳ：database management system）は、膨大な量のデータが保存されているデータベースを管理するためのシステムであり、大量の情報が途切れなく生成されている現時代において、なくてはならない重要な要素として認識されている。

【0003】

このようなデータベース管理システムにおいては、全てのデータをテーブル（table）形態でデータベースに保存するが、ここで、テーブルとは、データベースにおいて、データを保存する基本構造をいい、１つのテーブルは、一つ以上のレコード（record）から構成される。ここで、レコードとは、テーブルの１行（row）を意味する。また、各レコードは、一つ以上のカラムから構成されるが、カラムとは、テーブルを構成する実際のテーブル項目を表現する名称を有したドメイン（domain）を意味するものであり、アトリビュート（attribute）またはフィールド（field）ともいう。

【0004】

このようなデータベース管理システムは、外部から特定質疑（query）が入力される場合、入力された質疑によって、データベースに対して、データを選択、挿入、更新、削除などの機能を実行する。ここで、質疑とは、データベースのテーブルに保存されているデータに係わるいかなる要求、すなわち、データに対するいかなる操作の実行を所望するかということを記述したものであって、ＳＱＬ（structured query language）のような言語を利用して表現する。

【0005】

一方、データの量がさらに膨大するにつれ、データベース管理システムは、一般的にインデックス（index）を具備する。ここで、インデックスとは、データベース分野において、テーブルに対する探索速度を高める資料構造を意味し、このようなインデックスは、データレコード（チュープル（tuple））に早くアクセスするために、｛キー値、ポインタ｝組で構成されるデータ構造を有する。

【0006】

前述の背景技術は、発明者が本発明の導出のために保有していたり、あるいは本発明の導出過程で習得した技術情報であり、必ずしも本発明の出願前に一般公衆に公開された公知技術というものではない。

【0007】

なお、関連先行技術文献としては、特許文献１がある。

【先行技術文献】

【特許文献】

【0008】

【特許文献1】韓国公開特許第２０１３−００８７２５０号公報

【発明の概要】

【発明が解決しようとする課題】

【0009】

本発明の一実施形態は、データベースのインデックス構成において、１ページに含まれる複数個のレコードのキー値の下限値及び上限値を区分子として保存し、それを利用して、複数個のレコードにおいて、キーの重複部分を削除することにより、インデックスページが保存される保存空間を節約し、それにより、データベースの性能が向上するデータベース管理方法及び該管理システム、並びにデータベースのツリー構造を提供することを目的とする。

【0010】

また、本発明の一実施形態は、圧縮するか否かをリアルタイムで設定することを可能にし、特定領域において、挿入／削除（insert/delete）負荷が高くなれば、圧縮を行わないように調整することにより、データベース運用効率が向上したデータベース管理方法及び該管理システム、並びにデータベースのツリー構造を提供することを目的とする。

【0011】

また、本発明の一実施形態は、副次的な圧縮方式及びその範囲に係わるメタデータを追加して記録する必要がないようにし、ページに保存されるレコードの個数が多くなるほど、圧縮されるレコードにメタ情報を含む既存の方法に比べ、圧縮効率が極大化されるデータベース管理方法及び該管理システム、並びにデータベースのツリー構造を提供することを目的とする。

【0012】

また、本発明の一実施形態は、インデックスのツリー構造を巡回（traverse）するたびに、各ページのＬＦＫ（lower fence key）及びＵＦＫ（upper fence key）を利用して、リーフノードの有効性検査（validity check）を行うことにより、インデックス構造のエラーを手軽にチェックすることができるデータベース管理方法及び該管理システム、並びにデータベースのツリー構造を提供することを目的とする。

【課題を解決するための手段】

【0013】

本発明の一実施形態は、各ページに含まれる複数個のレコードのキー値の下限値がＬＦＫ（lower fence key）として保存されるか、あるいはレコードのキー値の上限値がＵＦＫ（upper fence key）として保存される段階と、前記ページをなす複数個のレコードのキー値のうち共通領域がプレフィックス（prefix）として抽出される段階と、前記複数個のレコードのキー値から、前記プレフィックスに該当する部分を除外した残りの部分が保存される段階と、を含むデータベース管理方法を開示する。

【0014】

本実施形態において、前記プレフィックスは、ＬＦＫまたはＵＦＫに保存される。

【0015】

本実施形態において、前記各レコードのうち、ＬＦＫまたはＵＦＫが保存されるレコード以外のレコードには、各レコードの原本キー値のうち前記プレフィックスを除いたキー値が保存される。

【0016】

本実施形態において、前記レコードは、複数個のキー値を含むマルチカラム（multi column）形態のレコードでもある。

【0017】

本実施形態において、前記複数個のキー値のうち、１枚のページをなすレコードが同一値を有するキー値が、前記プレフィックスとして抽出されもする。

【0018】

本実施形態において、前記各ページは、Ｂツリー構造またはＢ＋ツリー構造のリーフノードでもある。

【0019】

本実施形態において、前記データベース管理方法は、前記ページに含まれたレコードの原本キー値が復元される段階をさらに含み、前記原本キー値が復元される段階は、当該ページに、前記ＬＦＫとＵＦＫとが存在するか否かということが確認される段階と、当該ページに、前記ＬＦＫとＵＦＫとが存在する場合、前記ＬＦＫとＵＦＫとを比較演算し、そこに共通するプレフィックスが抽出される段階と、前記抽出されたプレフィックスと、当該レコードのキー値とが結合して原本キー値が復元される段階と、を含んでもよい。

【0020】

本実施形態において、当該ページに、前記ＬＦＫとＵＦＫとが存在しない場合、各レコードに保存されたキー値が原本キー値でもある。

【0021】

本実施形態において、前記データベース管理方法は、前記ページに新たなレコードが追加されるか、あるいは既存のレコードが変更される段階をさらに含み、前記レコードが追加されるか、あるいは変更される段階は、当該ページに、前記ＬＦＫとＵＦＫとが存在するか否かということが確認される段階と、当該ページに、前記ＬＦＫとＵＦＫとが存在する場合、前記ＬＦＫとＵＦＫとを比較演算し、そこに共通するプレフィックスが抽出される段階と、追加されたり、あるいは変更されたりするレコードから、前記プレフィックスが除外された残りのキー値がレコードに追加されたり、あるいはそこで変更されたりする段階と、を含んでもよい。

【0022】

本実施形態において、当該ページに、前記ＬＦＫとＵＦＫとが存在しない場合、前記プレフィックスが抽出されず、当該ページにレコードが追加されたり、あるいはそこで変更されたりもする。

【0023】

本発明の他の実施形態は、Ｂツリー構造またはＢ＋ツリー構造のデータベース管理方法において、Ｂツリー構造またはＢ＋ツリー構造のインデックスが生成される段階と、前記インデックスで所定のレコードが復元される段階と、前記インデックスに所定のレコードが追加されたり、あるいはそこで変更されたりする段階と、を含み、前記インデックスが生成される段階は、一つ以上のリーフノードの少なくとも一端部に、当該リーフノードに属するキー値の下限値がＬＦＫとして保存されるか、あるいは当該リーフノードに属するキー値の上限値がＵＦＫとして保存される段階を含むデータベース管理方法を開示する。

【0024】

本発明の他の実施形態は、特定テーブルに含まれたレコードの引出し要請、及び前記レコードに含まれた少なくとも１つのカラムに対する更新要請が共に定義された質疑文を受信して分析する質疑文分析部と、前記分析された質疑文を実行するための実行計画を生成する実行計画生成部と、前記実行計画により、前記レコードの引き出し、及び前記少なくとも１つのカラムに対する更新を行うことにより、前記実行計画を実行する実行計画実行部と、特定テーブルに係わるインデックスを生成し、前記インデックスの各ページに属する複数の個レコードのキー値の下限値をＬＦＫとして保存するか、あるいはレコードのキー値の上限値をＵＦＫとして保存するインデックス生成部を含むインデックス管理部と、を含むデータベース管理システムを開示する。

【0025】

本実施形態において、前記インデックス生成部は、前記各ページをなす複数個のレコードのキー値のうち共通領域をプレフィックスとして抽出することができる。

【0026】

本実施形態において、前記インデックス生成部は、前記各ページをなす複数個のレコードのキー値から、共通領域である前記プレフィックスに該当する部分を除いた残りの部分をインデックスに保存することができる。

【0027】

本実施形態において、前記プレフィックスは、ＬＦＫまたはＵＦＫにのみ保存される。

【0028】

本実施形態において、前記各レコードのうち、ＬＦＫまたはＵＦＫが保存されるレコード以外のレコードには、各レコードの原本キー値のうち、前記プレフィックスを除いたキー値だけが保存される。

【0029】

本実施形態において、前記インデックス管理部は、前記インデックスの各ページに含まれたレコードから原本キー値を復元するレコード復元部をさらに含んでもよい。
本実施形態において、前記レコード復元部は、当該ページに、前記ＬＦＫとＵＦＫとが存在するか否かということを確認し、当該ページに、前記ＬＦＫとＵＦＫとが存在する場合、ＬＦＫとＵＦＫとを比較演算して前記プレフィックスを抽出し、抽出された前記プレフィックスと当該レコードの値とを結合して原本キー値を復元することができる。

【0030】

本実施形態において、前記インデックス管理部は、前記インデックスの各ページに新たなレコードを追加するか、あるいは既存のレコードを変更するレコードアップデート部をさらに含んでもよい。

【0031】

本実施形態において、前記レコードアップデート部は、当該ページに、前記ＬＦＫとＵＦＫとが存在するか否かということを確認し、当該ページに、前記ＬＦＫとＵＦＫとが存在する場合、ＬＦＫとＵＦＫとを比較演算して前記プレフィックスを抽出し、追加されたり、あるいは変更されたりするレコードから、前記プレフィックスが除外された残りのデータを当該ページにレコードとして追加されたり、あるいは変更されたりする。

【0032】

本発明の他の実施形態は、Ｂツリー構造またはＢ＋ツリー構造のデータベースのツリー構造において、ツリー構造の最上部に位置し、一つ以上の区分キー値を保存するルートノード；及び少なくとも一端部に当該リーフノードに属するキー値の下限値がＬＦＫとして保存されるか、あるいは当該リーフノードに属するキー値の上限値がＵＦＫとして保存される一つ以上のリーフノード；を含むデータベースのツリー構造を開示する。

【0033】

本実施形態において、前記リーフノードにおいて、ＬＦＫとＵＦＫとの間に存在するレコードは、前記レコードのキー値から共通領域を除外した残りのキー値のみを保存することができる。

【0034】

本実施形態において、前記ルートノードに保存された区分キー値は、互いに隣合うリーフノードのいずれか一側のＬＦＫ及び他の一側のＵＦＫにもなる。

【0035】

本実施形態において、複数個の前記リーフノードのうち最も左側に位置したリーフノードには、前記ＬＦＫが保存されず、複数個の前記リーフノードのうち最も右側に位置したリーフノードには、前記ＵＦＫが保存されない。

【発明の効果】

【0036】

本発明によれば、インデックスページが保存される保存空間を節約することができ、それによって、データベースの性能が向上するという効果を得ることができる。

【0037】

また、本発明の一実施形態は、圧縮するか否かをリアルタイムで設定することを可能にし、特定領域において、挿入／削除（insert/delete）負荷が高くなれば、圧縮を行わないように調整することにより、データベース運用効率性が向上するという効果を得ることができる。

【0038】

また、本発明の一実施形態は、副次的な圧縮方式及びその範囲に係わるメタデータを追加して記録する必要がないようにし、ページに保存されるレコードの個数が多くなるほど、圧縮効率が極大化されるという効果を得ることができる。

【0039】

また、本発明の一実施形態は、インデックスのツリー構造を巡回（traverse）するたびに、各ページのＬＦＫ及びＵＦＫを利用して、リーフノードの有効性検査（validity check）を行うことにより、インデックス構造のエラーを手軽にチェックするという効果を得ることができる。

【図面の簡単な説明】

【0040】

【図1】本発明の一実施形態によるデータベース管理システムの概略的なブロック図である。

【図2A】本発明の一実施形態によるデータベース管理方法のインデックス生成段階を示すフローチャートである。

【図2B】本発明の一実施形態によるデータベース管理方法のレコード復元段階を示すフローチャートである。

【図2C】本発明の一実施形態によるデータベース管理方法のレコード追加／変更段階を示すフローチャートである。

【図3】本発明のデータベース管理方法及び該管理システムが適用されるＢツリーインデックスの構造を例示的に図示した図面である。

【図4】一般的なＢツリーページのキー値の配列を示す図面である。

【図5】本発明のデータベース管理方法及び該管理システムによるＢツリーページのキー値の配列を示す図面である。

【図6A】本発明のデータベース管理方法及び該管理システムが適用されるＢツリーインデックスでページが分割される過程を示す図面である。

【図6B】本発明のデータベース管理方法及び該管理システムが適用されるＢツリーインデックスでページが分割される過程を示す図面である。

【発明を実施するための形態】

【0041】

以下で説明する本発明に係わる詳細な説明は、本発明が実施される特定実施形態の例示として添付図面を参照する。このような実施形態は、当業者が、本発明を実施するのに十分なほどに詳細に説明する。本発明の多様な実施形態は、互いに異なるにしても、相互排他的である必要はないということを理解しなければならない。例えば、本明細書に記載されている特定形状、構造及び特性は、本発明の精神及び範囲を外れずに、一実施形態から他の実施形態に変更されて具現化されもする。また、それぞれの実施形態内の個別構成要素の位置または配置も、本発明の精神及び範囲を外れずに変更されるということが理解されなければならない。従って、以下で行われる詳細な説明は、限定的な意味として行われるのではなく、本発明の範囲は、特許請求の範囲の請求項が請求する範囲、及びそれと均等な全ての範囲を包括するものであると受け止めなければならない。図面で類似した参照符号は、多くの側面にわたって、同一であるか、あるいは類似した構成要素を示している。

【0042】

以下、本発明が属する技術分野で当業者が本発明を容易に実施することができるように、本発明のさまざまな実施形態について、添付図面を参照しつつ詳細に説明する。

【0043】

図１は、本発明の一実施形態によるデータベース管理システム（ＤＢＭＳ：database management system）の概略的なブロック図である。図１を参照すれば、本発明の一実施形態によるデータベース管理システム１００は、次のように構成される。

【0044】

まず、データベース１１０には、多様なデータがテーブル形式で保存され、前述のように、各テーブルは、一つ以上のレコードで構成され、各レコードは、一つ以上のカラムで構成される。例えば、所定掲示板に係わる掲示物が保存されたデータベースである場合、該テーブルは、掲示物の集合を意味し、該レコードは、各掲示物を意味し、該カラムとは、掲示物識別子、掲示物の作成者、掲示物のヒット数などが保存される領域を意味する。図面には、データベース１１０が複数個具備されるように図示されているが、本発明は、それに制限されるものではなく、データベース管理システム１００の構成、保存されるデータ分量、用途などによって、データベース１１０の個数及び構成は、多様に変更可能である。

【0045】

データベース管理システム１００は、データベース１１０に接続され、データベース１１０に記録されたデータを更新または削除するか、あるいはデータベース１１０にデータを追加するなど、データベース１１０を統合的に管理する機能を実行するものであり、大きく見て、質疑文分析部１２０、実行計画生成部１３０、実行計画実行部１４０を含む。また、データベース管理システム１００は、エントリー管理部１５０及びインデックス管理部１６０をさらに含んでもよい。

【0046】

質疑文分析部１２０は、データベース管理システム１００と連動する多様な外部サーバ（図示せず）または管理者端末機（図示せず）から、データベース１１０に保存されているデータ処理のための質疑文を受信し、受信した質疑文を分析する。このような質疑文分析部１２０は、質疑文受信部及びパーザ（parser）を含み、有効性検証部をさらに含んでもよい。

【0047】

実行計画生成部１３０は、質疑文分析部１２０の有効性検証部によって、有効であると判断されたパースツリーを基に、要請されたレコードの引き出し、及びレコードに含まれたカラム更新のための実行計画を生成し、後述するメモリ１７０に保存する。ここで、実行計画とは、特定テーブルからレコードを引き出す方法、結果レコードリスト、更新要請されたカラムに対する増加演算いかんなどを含む資料構造を意味する。

【0048】

一実施形態において、実行計画生成部１３０は、要請されたレコードを特定テーブルから引き出す方法として、順次スキャン方法及びインデックススキャン方法のうちいずれか一つを選択することができる。ここで、順次スキャン方法とは、特定テーブルに含まれたレコードを順次にスキャンして行き、当該レコードの識別子を有したレコードを引き出す方法を意味し、インデックススキャン方法とは、各レコードの識別子別にインデックスが生成されており、このようなインデックスのみをスキャンすることにより、当該レコードを引き出す方法を意味する。このようなデータベース管理システムのインデックスについては、追って詳細に説明する。

【0049】

実行計画実行部１４０は、実行計画生成部１３０によって生成された実行計画によって、特定テーブルから当該レコードを引き出し、更新要請されたカラムの物理的位置に相応するレコード上のカラムに記録されたカラム値に、増加演算を行うことにより、当該カラム値を更新する。具体的には、実行計画実行部１４０は、実行計画生成部１３０によって生成された実行計画を実行するためのトランザクションを生成することにより、生成された実行計画を当該トランザクションの間に処理する。ここで、トランザクションとは、１つの論理的作業単位を構成するものであり、一つ以上のＳＱＬ文を利用して定義される。このようなトランザクションの使用によって、データの一致性とデータの同時発生とを保証することができる。

【0050】

データベース管理システム１００は、レコードの識別子、及び更新要請されるカラムの識別子で構成されるエントリーを生成または削除し、生成されたエントリーを、エントリーに含まれたカラム識別子に相応するカラム値とマッチングさせてメモリ１７０に保存するエントリー管理部１５０をさらに含んでもよく、メモリ１７０には、更新要請されたカラムのカラム値が、エントリー管理部１５０に生成されたエントリーとマッチングされて保存される。

【0051】

一方、データベース管理システム１００は、インデックスを生成または削除し、生成されたインデックスをメモリ１７０に保存するインデックス管理部１６０をさらに含んでもよい。このようなインデックス管理部１６０は、インデックス生成部１６１、レコード復元部１６３、レコードアップデート部１６５を含んでもよい。

【0052】

インデックス生成部１６１は、特定データベース１１０に係わるインデックスを生成し、このとき、インデックスの各ページに属するキー値の下限値をＬＦＫ（lower fence key）として保存し、キー値の上限値をＵＦＫ（upper fence key）として保存する役割を担う。また、インデックス生成部１６１は、各ページをなす複数個のレコードのキー値のうち、共通領域をプレフィックス（prefix）として抽出する役割を担う。また、インデックス生成部１６１は、各ページをなす数数個のレコードのキー値からプレフィックスに該当する部分を削除した後、インデックスに保存する役割を担う。

【0053】

レコード復元部１６３は、インデックスの各ページに含まれたレコードから原本キー値を復元する役割を行う。詳細には、レコード復元部１６３は、当該ページにＬＦＫとＵＦＫとが存在するか否かということを確認し、当該ページにＬＦＫとＵＦＫとが存在する場合、ＬＦＫとＵＦＫとを比較演算してプレフィックスを抽出し、抽出されたプレフィックスと当該レコードの値とを結合して原本キー値を復元する役割を担う。

【0054】

レコードアップデート部１６５は、インデックスの各ページに新たなレコードを追加するか、あるいは既存のレコードを変更する役割を担う。詳細には、レコードアップデート部１６５は、当該ページにＬＦＫとＵＦＫとが存在するか否かということを確認し、当該ページにＬＦＫとＵＦＫとが存在する場合、ＬＦＫとＵＦＫとを比較演算してプレフィックスを抽出し、追加されたり、あるいは変更されたりするレコードからプレフィックスが除外された残りのデータを、当該ページにレコードとして追加または変更する役割を担う。

【0055】

このようなインデックス生成部１６１のインデックス生成過程、レコード復元部１６３のレコード復元過程、レコードアップデート部１６５のレコードアップデート過程については、図２Ａ以下で詳細に説明する。

【0056】

以下、このように、区分子基盤のインデックス圧縮技法（serperator-based index compression method）を利用したデータベース管理方法について、さらに詳細に説明する。

【0057】

図２Ａ、図２Ｂ及び図２Ｃは、本発明の一実施形態によるデータベース管理方法を示すフローチャートである。一方、図３は、本発明のデータベース管理方法及び該管理システムが適用されるＢツリーインデックスの構造を例示的に図示した図面であり、図４は、一般的なＢツリーページのキー値の配列を示す図面であり、図５は、本発明のデータベース管理方法及び該管理システムによるＢツリーページのキー値の配列を示す図面である。

【0058】

図２Ａないし図５を参照すれば、本発明の一実施形態によるデータベース管理方法は、インデックスを生成する段階（Ｓ１００段階）、インデックスでレコードを復元する段階（Ｓ２００段階）、及びインデックスでレコードを追加／変更する段階（Ｓ３００段階）を含む。

【0059】

それらについてさらに詳細に説明すれば、次の通りである。

【0060】

インデックスは、データベース分野において、テーブルに対する動作の速度を速める資料構造をいう。インデックスは、テーブル内の１個のカラム（single column index）、あるいはいくつかのカラム（multi column index）を利用して生成されることができ、高速の検索動作だけではなく、レコードアクセスと係わり、効率的な手順付け動作に係わる基礎を提供する。インデックスを保存するのに必要なディスク空間は、普通テーブルを保存するのに必要なディスク空間より小さい。なぜならば、普通インデックスは、キーフィールドのみ有しており、テーブルの他の詳細項目は、有していないからである。

【0061】

Ｂツリー（あるいは、Ｂ＋ツリー）は、このようなインデックスを構成するために、データベース及びファイルシステムで広く使用されるツリー資料構造の一種であり、特定値（key）を有しているレコードを早く照会するための関連写像資料構造である。Ｂツリー（あるいは、Ｂ＋ツリー）は、アクセスが遅い大容量ディスクにデータが記録されている特性のために、Ｉ／Ｏ回数を減らすために、ページ単位のツリー構造になっている。１ページ内には、キーと、該キーをアトリビュート（attribute）として含んでいる実際レコードの位置（Object ＩＤあるいはRecord ＩＤ）がキーの順に記録されている。すなわち、｛Key−ＯＩＤ｝が結合し、それぞれのインデックスレコード（以下では、それをレコードとも称する）を構成するのである。

【0062】

前述のような特性により、１ページ内のレコードのキー値は、隣接している値同士相当な類似性を有することができる。例えば、一会社のメールシステムにおいて、各メールを区分するためのインデックスキーとして、社員番号、メールフォルダ番号、メール一連番号を指定した場合（すなわち、マルチカラムインデックス）、ある社員が、全体メールは１０万件であり、１つのメールフォルダに、１万件のメールを保管しているならば、インデックスにおいて１万件は、社員番号とメールフォルダ番号とが同一値であり、１０万件は、社員番号が同一値である。もし一般的なＢツリーの１ページに、既存の方式通り、１千件ずつ入れば、１０件ほどのページでは、社員番号とメールフォルダ番号とが重複して毎回保存されるであろう。従って、同一値が何回か重複保存されることにより、不要なメモリの浪費が発生するという問題点が存在した。

【0063】

このような問題点を解決するために、本発明の区分子基盤のインデックス圧縮技法（separator-based index compression method）を利用したデータベース管理方法及び該管理システムは、１ページのキー値のうち重複保存されるプレフィックス（prefix）を、ページ区分子であるＬＦＫ及びＵＦＫに保存し、メモリ空間を節約することを一特徴とする。

【0064】

さて、図２Ａを参照すれば、本発明の一実施形態によるデータベース管理方法において、インデックスを生成する段階（Ｓ１００段階）は、１枚のページに属するキー値の下限値がＬＦＫとして保存されるか、あるいは１枚のページに属するキー値の上限値がＵＦＫとして保存される段階（Ｓ１１０段階）、１枚のページをなす複数個のレコードのキー値のうち共通領域がプレフィックスとして抽出される段階（Ｓ１２０段階）、及び１枚のページをなす複数個のレコードのキー値で共通領域であるプレフィックスが削除された後で保存される段階（Ｓ１３０段階）を含む。それについて理解しやすく説明すれば、次の通りである。

【0065】

本発明が適用されたＢツリーインデックスの構造を図示した図３を参照すれば、データベースにおいて、レコードデータを早く検索するために使用されるインデックスにおいて、本発明で使用するＢツリーインデックスの構成は、実際レコードデータを示すリーフノード（leaf node）と、その上位の中間ノードとからなる。ルートノードは、中間ノードのうち最上位に存在する１つのノードである。図３には、４つのリーフノードと、１つの中間ノードとが存在し、その１つの中間ノードが、すなわち、ルートノードになる。このとき、それぞれのリーフノードは、すなわち、それぞれのページを構成する。すなわち、図３に図示された４つのリーフノードは、４枚のページを構成する。

【0066】

ここで、図３に図示されたＢツリーインデックスのルートノードは、３つの区分キー値Ｐ１，Ｐ２，Ｐ３を有する。第１区分キー値Ｐ１は、ページ１とページ２とを区分する区分子になり、第２区分キー値Ｐ２は、ページ２とページ３とを区分する区分子になり、第３区分キー値Ｐ３は、ページ３とページ４とを区分する区分子になる。

【0067】

このように、本発明の一実施形態によるデータベース管理方法は、それぞれのページに属するキー値の下限値をＬＦＫとして保存し、またそれぞれのページに属するキー値の上限値をＵＦＫとして保存することを特徴とする。このとき、ＬＦＫは、図面で見たとき、各ページの左端部に保存され、当該ページの下限値を定義し、ＵＦＫは、図面で見たとき、各ページの右端部に保存され、当該ページの上限値を定義する。

【0068】

そして、本発明の一実施形態によるデータベース管理方法は、各ページにおいて、ＬＦＫとＵＦＫとの間に存在する複数個のレコードのキー値のうち共通領域をプレフィックスとして抽出し、ＬＦＫとＵＦＫとを除いた残りのレコードでは、キー値からプレフィックスを削除した後、残りキー値のみを保存することにより、データの重複保存を防止してメモリ空間を節約する。

【0069】

すなわち、第１区分キー値Ｐ１は、ページ１のＵＦＫであるＵＦＫ１になるとともに、ページ２のＬＦＫであるＬＦＫ２になる。同様に、第２区分キー値Ｐ２は、ページ２のＵＦＫであるＵＦＫ２になるとともに、ページ３のＬＦＫであるＬＦＫ３になる。同様に、第３区分キー値Ｐ３は、ページ３のＵＦＫであるＵＦＫ３になるとともに、ページ４のＬＦＫであるＬＦＫ４になる。このとき、複数個のリーフノードのうち最も左側に位置する極左側リーフノード（ページ１）には、ＬＦＫを設定することができず、従って、当該ページでは、プレフィックス抽出も可能ではない。同様に、最も右側に位置した極右側リーフノード（ページ４）には、ＵＦＫを設定することができず、従って、当該ページでは、プレフィックス抽出も可能ではない。

【0070】

これについてさらに詳細に説明するために、一般的なＢツリーページのキー値の配列を示す図４と、本発明のデータベース管理方法及び該管理システムによるＢツリーページのキー値の配列を示す図５とを比較する。図４及び図５では、説明のために、１０個のレコードだけがある場合を想定した。

【0071】

図４を参照すれば、１枚のページを構成する１０個のレコードで、社員番号（ＫＲ１００００）とメールフォルダ番号（ＦＤ０００１）とが同一値として重複し、１０回保存される。それに対し、図５を参照すれば、本発明のデータベース管理方法による場合、１枚のページのキー値のうち重複保存される社員番号（ＫＲ１００００）とメールフォルダ番号（ＦＤ０００１）は、当該ページの下限値を設定するＬＦＫ、及び当該ページの上限値を設定するＵＦＫにのみ保存され、ＬＦＫとＵＦＫとの間の一般レコードには、プレフィックスが削除された状態のキー値だけが保存される。すなわち、図５のように、１０個のレコードに共通するキー値である社員番号（ＫＲ１００００）とメールフォルダ番号（ＦＤ０００１）は、いずれも削除され、ユニークなキー値であるメール一連番号だけが各レコードに保存される。

【0072】

以下では、本発明の一実施形態によるデータベース管理方法において、レコードを復元する段階について説明する。さて、図２Ｂ及び図５を参照すれば、本発明の一実施形態によるデータベース管理方法において、レコードを復元する段階（Ｓ２００段階）は、当該ページに、ＬＦＫとＵＦＫとが存在するか否かということを確認する段階（Ｓ２１０段階）、当該ページに、ＬＦＫとＵＦＫとが存在する場合、ＬＦＫとＵＦＫとを比較演算してプレフィックスを抽出する段階（Ｓ２２０段階）、及びプレフィックスと当該レコードの値とが結合して原本キー値が復元される段階（Ｓ２３０段階）を含む。それについてさらに詳細に説明すれば、次の通りである。

【0073】

まず、復元するキー値が属したページが、いずれのページであるかということを、バイナリ探索によって求めた後、当該ページに、ＬＦＫとＵＦＫとが存在するか否かということを確認する。当該ページに、ＬＦＫ及びＵＦＫ二つのうちいずれか一つでも存在しない場合、当該ページは、圧縮（すなわち、プレフィックスを利用した重複データ削除）が行われていないので、それぞれのレコードに保存されているキー値が、まさに原本キー値である（Ｓ２４０段階）。一方、当該ページに、ＬＦＫとＵＦＫとがいずれも存在する場合、当該ページは、プレフィックスを利用したデータ圧縮が行われたページであるので、所定の復元ルーチンを実行する。すなわち、ページの下限値であるＬＦＫと、ページの上限値であるＵＦＫとを比較し、ＬＦＫ及びＵＦＫの共通領域、すなわち、プレフィックスを抽出する。図５の例においては、ＬＦＫ及びＵＦＫの共通領域であるＫＲ１００００：ＦＤ０００１がプレフィックスとして抽出される。このように抽出されたプレフィックスと、各レコードに保存されているキー値とを結合して原本キー値が復元される。すなわち、ＳＮ１０００１を復元した原本キー値は、ＫＲ１００００：ＦＤ０００１：ＳＮ１０００１になる。

【0074】

以下では、本発明の一実施形態によるデータベース管理方法において、レコードを追加または変更する段階について説明する。ここで、図２Ｃ及び図５を参照すれば、本発明の一実施形態によるデータベース管理方法において、レコードを追加または変更する段階（Ｓ３００段階）は、当該ページに、ＬＦＫとＵＦＫとが存在するか否かということを確認する段階（Ｓ３１０段階）、当該ページに、ＬＦＫとＵＦＫとが存在する場合、ＬＦＫとＵＦＫとを比較演算してプレフィックスを抽出する段階（Ｓ３２０段階）、及び追加されたり、あるいは変更されたりするレコードからプレフィックスが除外された残りのデータが、当該ページにレコードとして追加されたり、あるいはそこで変更されたりする段階（Ｓ３３０段階）を含む。それについてさらに詳細に説明すれば、次の通りである。

【0075】

まず、追加または変更するキー値が属するページが、いずれのページであるかということを、バイナリ探索によって求めた後、当該ページに、ＬＦＫとＵＦＫとが存在するか否かということを確認する。当該ページに、ＬＦＫ及びＵＦＫ二つのうちいずれか一つでも存在しない場合、当該ページは、圧縮（すなわち、プレフィックスを利用した重複データ削除）が行われていないので、当該レコードの値を、別途の処理なしにそのまま追加したり、あるいは変更したりすればよい（Ｓ３４０段階）。一方、当該ページに、ＬＦＫとＵＦＫとがいずれも存在する場合、当該ページは、プレフィックスを利用したデータ圧縮が行われたページであるので、所定の分解ルーチンを実行する。すなわち、ページの下限値であるＬＦＫと、ページの上限値であるＵＦＫとを比較し、ＬＦＫ及びＵＦＫの共通領域、すなわち、プレフィックスを抽出する。図５の例においては、ＬＦＫ及びＵＦＫの共通領域であるＫＲ１００００：ＦＤ０００１がプレフィックスとして抽出される。次に、追加または変更するレコードのキー値からプレフィックスを除外した残りのキー値だけが、ページの当該位置に追加されたり、あるいはそこで変更されたりする。例えば、追加されるキー値が、ＫＲ１００００：ＦＤ０００１：ＳＮ１３０００であるならば、プレフィックスは、ＫＲ１００００：ＦＤ０００１になり、従って、当該ページには、キー値からプレフィックスを除外したＳＮ１３０００のみが追加される。

【0076】

以下では、本発明の一実施形態によるデータベース管理方法において、ページが分割または併合される過程について説明する。

【0077】

図６Ａ及び図６Ｂは、本発明のデータベース管理方法及び該管理システムが適用されるＢツリーインデックスにおいて、ページが分割される過程を示す図面である。

【0078】

図６Ａに図示されたＢツリーインデックスのルートノードは、初めには、２つの区分キー値Ｐ１，Ｐ２を有する。第１区分キー値Ｐ１は、ページ１とページ２とを区分する区分子になり、第２区分キー値Ｐ２は、ページ２とページ３とを区分する区分子になる。そして、第１区分キー値Ｐ１は、ページ１のＵＦＫであるＵＦＫ１になるとともに、ページ２のＬＦＫであるＬＦＫ２になる。同様に、第２区分キー値Ｐ２は、ページ２のＵＦＫであるＵＦＫ２になるとともに、ページ３のＬＦＫであるＬＦＫ３になる。

【0079】

この状態で、ページ２にそれ以上保存空間がなくなり、第１区分キー値Ｐ１と、第２区分キー値Ｐ２との間の任意の値であるＳを基準に、ページ２を分割しなければならないと仮定する。

【0080】

その場合、ページ２では、図６Ｂに図示されているように復元されたＳを、新たなＵＦＫであるＵＦＫ２として保存する。そして、既に存在していたＬＦＫであるＬＦＫ２と、新たに生成されたＵＦＫであるＵＦＫ２とを利用して、さらにデータを圧縮する。すなわち、ＬＦＫ２とＵＦＫ２とを比較演算してプレフィックスを抽出した後、ＬＦＫ２とＵＦＫ２とを除いた残りのレコードでは、キー値からプレフィックスを削除した後、残りのキー値のみを保存する。

【0081】

一方、新たに生成された図６Ｂのページ３では、Ｓを新たなＬＦＫであるＬＦＫ３として保存する。そして、図６Ａのページ２のＵＦＫであるＵＦＫ２が、図６Ｂのページ３のＵＦＫであるＵＦＫ３として保存される。そして、ＬＦＫ３とＵＦＫ３とを利用して、さらにデータを圧縮する。すなわち、ＬＦＫ３とＵＦＫ３とを比較演算してプレフィックスを抽出した後、ＬＦＫ３とＵＦＫ３とを除いた残りのレコードでは、キー値からプレフィックスを削除した後、残りのキー値のみを保存する。

【0082】

最後に、図６Ｂのページ３では、Ｓを新たな区分キー値として、親ノード（ここでは、ルートノード）の第１区分キー値Ｐ１と第２区分キー値Ｐ２との間に挿入する。

【0083】

一方、図示されていないが、圧縮されていないページ（すなわち、プレフィックスを利用した重複データ削除が行われていないページ）であるならば、新たな区分キー値Ｓを基準にしてページを分割するとき、既存のページには、新たな区分キー値ＳがＵＦＫとして設定され、既に存在していたＬＦＫと、新たに生成されたＵＦＫとを利用して、新たにデータを圧縮することができる。一方、新たに生成されたページには、新たな区分キー値ＳがＬＦＫとして設定されるが、ＵＦＫが設定されていないので、データ圧縮が行われない。

【0084】

また、図示されていないが、互いに隣合う２枚のページが併合可能な（mergeable）大きさであるとき（すなわち、２枚のページに保存されたレコード個数の和が、１枚のページに保存されるレコード個数の最大値以下である場合）には、２枚のページを併合することも可能である。そのとき、２枚のページがいずれも圧縮されたページ（すなわち、プレフィックスを利用して、重複データが削除されたページ）であるならば、２枚のページの併合後に新たに圧縮を行う。一方、２枚のページのうちいずれか一つでも圧縮されたページではない場合には、併合を行わない。

【0085】

下記表１は、一般的なデータベース管理方法及び該管理システムを適用した場合の全インデックスページの枚数（total page count）と、本発明の一実施形態によるデータベース管理方法及び該管理システムを適用した場合の全インデックスページの枚数とを比較した表である。そして、表２は、一般的なデータベース管理方法及び該管理システムを適用した場合の平均キー値の長さ（average key length）と、本発明の一実施形態によるデータベース管理方法及び該管理システムを適用した場合の平均キー値の長さとを比較した表である。

【0086】

【0087】

表１及び表２に示されているように、従来のデータベース管理方法及び該管理システムを適用した場合に比べ、本発明の一実施形態によるデータベース管理方法及び該管理システムを適用した場合、全インデックスページ数は、１９％ほど減少し、平均キー値長は、３１％ほど縮小された。すなわち、本発明により、保存空間を節約することができ、それにより、データベースの性能が向上するという効果を得る可能性があることが分かる。

【0088】

このような本発明の一実施形態によるデータベース管理方法は、Ｂツリーの１ページ内で、当該ページの区分子として使用されたキー値を、｛仮想のキー−ＯＩＤ｝レコードにし、当該ページの両端にフェンスキー（ＬＦＫ及びＵＦＫ）としてそれぞれ追加することにより、ＬＦＫ及びＵＦＫからの原本キー値の組み合わせ作業、及び原本キー値からプレフィックスを削除したりする分解作業を迅速に行うことができる。

【0089】

一方、当該ページに、ＬＦＫまたはＵＦＫが存在しなければ、既存の方式でレコードを保存することができ、従って、圧縮されたページ（すなわち、プレフィックスが各レコードから削除されたページ）と、圧縮されていないページ（すなわち、プレフィックスが各レコードから削除されていないページ）とが混在して維持されもする。また、ＬＦＫ及びＵＦＫが存在するページ内でも、圧縮されたレコードと、圧縮されていないレコードとが混在して維持されもする。従って、Ｂツリーの現在状態と係わりなく、圧縮するか否かをリアルタイムで設定することが可能になるという効果を得ることができる。そして、このような特徴を利用して、特定領域において、挿入／削除負荷が高くなれば、圧縮を行わないように調整し、データベース運用効率を向上させることができる。

【0090】

一方、プレフィックスを利用した圧縮をするか否かを、ＬＦＫ及びＵＦＫを使用して決定するために、副次的な圧縮方式及びその範囲に係わるメタデータを追加して記録する必要がない。従って、ページに保存されるレコードの個数が多くなるほど、圧縮されるレコードにメタ情報を含む既存の方法に比べ、圧縮効率が極大化されるという長所がある。

【0091】

このような本発明により、既存に比べ、プレフィックスを除いたキー値のみを保存するために、Ｂツリーの１ページに、さらに多くのレコードを保存することができる。それにより、保存空間を節約することができ、かように縮小された空間であるほど、主メモリのバッファキャッシュに含まれる可能性が大きくなり、データベースの性能が向上するという効果を得ることができる。さらに、本発明の一実施形態によるデータベース管理方法は、既存の他の圧縮方式に比べ、分割及び復元が簡単であり、保存構造の変更がなく、下位互換性側面で有利であり、ＬＦＫ及びＵＦＫを示すフラグ一つだけ追加されるのみ、追加して記録されるメタデータもなく、構造的に単純であるという長所を有する。

【0092】

さらに、本発明のデータベース管理方法を利用すれば、インデックスのツリー構造を巡回するたびに、各ページのＬＦＫ及びＵＦＫを利用して、リーフノードの有効性検査を行うことができ、インデックス構造のエラーを手軽にチェックできるという効果を得ることができる。また、ＬＦＫ及びＵＦＫにより、リーフノードの接続関係を把握することができるので、リーフノードからリンクを除去することができ、従って、ＳＭＯ（structure modification operation）時の性能及び効率を向上させるという効果を得ることができる。

【0093】

前述のデータベース管理方法は、多様なコンピュータ手段を利用して実行されるプログラム形態でも具現されるが、そのとき、データベース管理方法を実行するためのプログラムは、ハードディスク、ＣＤ（compact disc）−ＲＯＭ（read-only memory）、ＤＶＤ（digital versatile disc）、ＲＯＭ、ＲＡＭ（random-access memory）またはフラッシュメモリのようなコンピュータで読み取り可能な記録媒体に保存される。

【0094】

本明細書では、本発明について、限定された実施形態を中心に説明したが、本発明の範囲内で、多様な実施形態が可能である。また、説明されていないにしても、均等な手段も、本発明にそのまま結合されるものとすることができる。従って、本発明の真の保護範囲は、特許請求の範囲によって決まらなければならないのである。

【産業上の利用可能性】

【0095】

本発明のデータベース管理方法及び該管理システム、並びにデータベースのツリー構造は、例えば、情報処理関連の技術分野に効果的に適用可能である。

【符号の説明】

【0096】

１００ データベース管理システム
１１０ データベース
１２０ 質疑文分析部
１３０ 実行計画生成部
１４０ 実行計画実行部
１５０ エントリー管理部
１６０ インデックス管理部
１６１ インデックス生成部
１６３ レコード復元部
１６５ レコードアップデート部
１７０ メモリ

【図1】

【図2A】

【図2B】

【図2C】

【図3】

【図4】

【図5】

【図6A】

【図6B】