JP2000322293A - データベース管理方法及びその実施装置並びにその処理プログラムを記録した記録媒体 - Google Patents

Abstract

(57)【要約】 【課題】 データベースの格納効率を向上させることが
可能な技術を提供する。 【解決手段】 レコードをブロックに格納して管理する
データベース管理方法において、レコード中のデータを
そのレコードが格納されるブロックとは別のブロックに
格納するかどうかを判定する為のしきい値を設定するス
テップと、レコード中のデータの長さが前記しきい値以
下である場合に、当該データをそのレコードが格納され
るブロックと同一のブロックに格納し、レコード中のデ
ータの長さが前記しきい値を超える場合に、当該データ
をそのレコードが格納されるブロックとは別のブロック
に格納するステップとを有するものである。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明はレコードをブロック
に格納して管理するデータベース管理装置に関し、特に
レコード中の可変長データをそのデータ長に応じて別の
ブロックに格納するデータベース管理装置に適用して有
効な技術に関するものである。

【０００２】

【従来の技術】データベース管理システムとは、データ
を記録し保持するコンピュータシステムである。特に、
データベース管理システムの内、リレーショナルデータ
ベース管理システムにおいては、データベースはユーザ
から二次元の表形式で見られる表（或いは、リレーショ
ン）から成り、かつ、この表は複数の行（レコード、或
いはタップル）から構成されている。また、タップルは
複数個の列（アトリビュート、或いはフィールド）から
構成され、各列にはその列の特性を示すデータ型、デー
タ長等が規定される。

【０００３】ユーザまたはアプリケーションプログラム
は、データベースに対する要求またはコマンドを発行す
る（問合せと呼ぶ）ことにより、データを処理（選択、
更新、挿入または削除）する。ＳＱＬ（構造化照会言
語）等のリレーショナル・データベース管理システムの
データ問合せ及び処理言語では、問合せは非定型であ
る。すなわち、ユーザまたはアプリケーションプログラ
ムは、必要なことを指定するだけで、それを実行する為
の処理手順を指定する必要がない。また、ユーザやアプ
リケーションプログラムは、問合せによってアクセスす
る表が格納されている場所を意識する必要もない。

【０００４】通常、データベースの格納については、一
般的に物理的に固定長のブロックを最小アクセス単位と
するデータベース領域に表を格納する。また、データベ
ース領域は、一つまたは複数の外部記憶装置上のファイ
ルで構成される。この場合、表の行は前記ブロック内に
複数の行が格納される様にする。

【０００５】従来、データベース管理ステムを使用して
構築した業務で取り扱うデータは、数値、文字（固定長
でかつ短い文字列）が主流であった。また、定義された
表も一つの行はなるべく必要最小限のデータから構成す
るものが多い為、短い行長で構成されることが多かっ
た。検索においても、固定長のデータであればＢ木イン
デクスによって高速なアクセスが可能であったが、可変
長データの場合にはＢ木インデクスが有効になるケース
が前方一致に限定された。こういったデータベースで
は、可変長データは検索条件に指定されることはなく、
条件によって絞り込まれたデータの中から取り出す情報
に含まれることが大半であった。

【０００６】こういったデータベースを取り扱うデータ
ベース管理システムではＳＱＬにおける可変長データ型
であるＶＡＲＣＨＡＲ型はブロック長よりも長いサイズ
の型を定義できるが、同じデータベース領域内に格納す
るのが一般的である。但し、ＶＡＲＣＨＡＲ型等の可変
長データを持つ行を格納する場合には、二通りの格納方
法がある。一つは、挿入する行の行長がブロック長を超
える場合、行の途中から別のブロックに格納する方法で
ある。もう一つは、可変長データ型の列のデータがある
一定の長さを超える場合、無条件にその列だけを別のブ
ロックに分岐して格納し、分岐先のポインタ（通常、行
番号）を行の該当する列の部分に格納する方法である。

【０００７】例えば、通常行内に格納し、可変長データ
列の長さを１バイトで管理する場合、２５５バイトを超
えるデータは内部形式上管理できないので、別のブロッ
クに格納する方法が取られる。これらの格納方法につい
ては、「ＴＲＡＮＳＡＣＴＩＯＮ ＰＲＯＣＥＳＳＩＮ
Ｇ：ＣＯＮＣＥＰＴＳ ＡＮＤ ＴＥＣＨＮＩＱＵＥＳ」
ＪＩＭ ＧＲＡＹ、ＡＮＤＲＥＡＳ ＲＥＵＴＥＲ共著、
ＭＯＲＧＡＮ ＫＡＵＦＭＡＮ発行の「１４ Ｔｈｅ Ｔ
ｕｐｌｅ−Ｏｒｉｅｎｔｅｄ Ｆｉｌｅ Ｓｙｓｔｅｍ」
に記述されている。

【０００８】近年、ＶＡＲＣＨＡＲ型よりも大きな可変
長データ型としてＢＬＯＢ型のデータ型が規格化され、
文書や画像等のマルチメディアデータが取り扱える様に
なった。ＢＬＯＢ型は、前者のＶＡＲＣＨＡＲ型よりも
長さの長いデータを格納するのに使用され、一般的には
別の専用のデータベース領域に格納し、通常の行と同じ
データベース領域には格納しない。ＢＬＯＢ型の様な長
大可変長データの格納方法については、特開平９−３０
５４４９号公報に記載されている。

【０００９】前記、ＢＬＯＢ型ではマルチメディアデー
タを扱える様にはなったが、依然として検索条件を与え
て検索することはできなかった。マルチメディアデータ
を扱った新しい業務形態の要望が高まり、文章や画像の
検索を可能にするデータベース管理システムが見られる
様になったが、文章や画像の全てが大きなデータではな
い為、新聞記事等の様な比較的短いデータはＢＬＯＢ型
として格納するよりもＶＡＲＣＨＡＲ型で格納すること
を期待するユーザが増えてきている。

【００１０】そうした場合に、従来の様なＶＡＲＣＨＡ
Ｒ型のデータの格納方法では格納効率が悪いという問題
に直面することになる。また、検索処理においても並列
データベース処理技術が浸透しつつあり、従来の様なイ
ンデクス検索を主体にするのではなく、全件検索等も行
われる様になり、ますます格納効率の向上への期待が高
まっている。

【００１１】

【発明が解決しようとする課題】前述の様に、従来の技
術ではデータベース領域へのデータの格納効率に関する
問題が生じる。格納効率で問題になるのは前記従来技術
における前者のＶＡＲＣＨＡＲ型のデータ長が一定のし
きい値を超える場合に無条件に別のブロックへ格納する
場合である。

【００１２】一定のしきい値を超える可変長データを無
条件に別のブロックへ格納するのは、その可変長データ
を含まない検索処理の効率を向上させる為であるが、こ
の場合、たとえ行の総長（可変長データ型定義列も含め
る）がブロック長を超えていなくとも、可変長データ列
がしきい値を超える為に当該列データが別ブロックに格
納されることになる。可変長データが別ブロックに格納
される際には、後の更新処理を考慮してそのブロック内
に空き領域が生じる様な格納が行われる為、こういった
列が複数存在する場合に最も格納効率が悪くなる。

【００１３】格納効率が悪くなった場合には、検索処理
性能にも影響を与えることになる。しきい値を超える可
変長データだけを格納する専用のブロックが存在する場
合を除くと、全件検索の様な場合には別ブロックに格納
された行イメージも読み込むことになる為、不要なアク
セスが生じる場合が発生する。特に、全件検索において
検索条件に指定する列に可変長データ列を含んでおら
ず、かつ、取り出す列にも含まれていない場合には無駄
なアクセスが発生する。これは、Ｉ／Ｏ発行回数にも大
きく影響する。

【００１４】また、検索条件に指定されていたり、取り
出しする列に含まれている場合にも、同一ブロック内の
行の中にデータが含まれていない為、必ず別ブロックに
格納された可変長データ列に対するアクセスが発生し、
アクセス効率が悪くなるという問題がある。

【００１５】データベース領域のブロックサイズによっ
て、格納効率を上げる手段を持つ方法もあるが、可変長
データ列は実際のデータが一定長を超える場合（多くの
場合、１バイトで表現できる長さ（２５５バイト）を超
える場合となる）に無条件に別ブロックに格納する為、
別ブロックへの分岐を抑制する点では効果がない。

【００１６】本発明の目的は上記問題を解決し、データ
ベースの格納効率を向上させることが可能な技術を提供
することにある。本発明の他の目的はデータベースの検
索効率を向上させることが可能な技術を提供することに
ある。

【００１７】

【課題を解決するための手段】本発明は、レコードをブ
ロックに格納して管理するデータベース管理装置におい
て、レコード中のデータに応じて指定されたしきい値に
よりレコード中のデータを分岐させるかどうかを制御す
るものである。

【００１８】本発明では、データベースの定義を行う際
に、レコード中のデータをそのレコードが格納されるブ
ロックとは別のブロックに格納するかどうかを判定する
為のしきい値を設定する。

【００１９】レコードの挿入処理を行う際にはレコード
中のデータの長さとそのしきい値を比較し、レコード中
のデータの長さが前記しきい値以下である場合に、当該
データをそのレコードが格納されるブロックと同一のブ
ロックに格納する。またレコード中のデータの長さが前
記しきい値を超える場合には、当該データをそのレコー
ドが格納されるブロックとは別のブロックに格納する。

【００２０】例えば、データベースのレコード中に定義
される可変長データ項目について、その可変長データ項
目に格納されるデータの長さがある程度予想できる場合
に、その平均的なデータ長を考慮し、平均的なデータ長
をある程度上回るしきい値や平均的なデータ長をある程
度下回るしきい値を設定する。

【００２１】平均的なデータ長をある程度上回るしきい
値を設定した場合には、それらのレコードの挿入処理の
際に多くのレコード中の可変長データの長さがそのしき
い値以下となるので、別のブロックへの分岐が抑制さ
れ、分岐先のブロックに生じる空き領域が減少してデー
タベースの格納効率を向上させることができる。

【００２２】また、平均的なデータ長をある程度下回る
しきい値を設定した場合には、それらのレコードの挿入
処理の際に多くのレコード中の可変長データの長さがそ
のしきい値以上となるので、別のブロックへの分岐が促
進され、分岐元のブロック中の長大データが減少して、
分岐したデータ以外の検索処理を行う際のデータベース
の検索効率を向上させることが可能である。

【００２３】以上の様に本発明のデータベース管理装置
によれば、レコード中のデータに応じて指定されたしき
い値によりレコード中のデータを分岐させるかどうかを
制御するので、データベースの格納効率を向上させるこ
とが可能である。

【００２４】

【発明の実施の形態】以下にレコード中の可変長データ
にしきい値を指定してその可変長データを別のブロック
に分岐させるかどうか制御する一実施形態のデータベー
ス管理装置について説明する。

【００２５】図１は本実施形態のデータベース管理装置
１０の概略構成を示す図である。図１に示す様に本実施
形態のデータベース管理装置１０は、しきい値指定処理
部１００と、データ挿入処理部１０１とを有している。

【００２６】しきい値指定処理部１００は、レコード中
のデータをそのレコードが格納されるブロックとは別の
ブロックに格納するかどうかを判定する為のしきい値を
設定する処理部である。データ挿入処理部１０１は、レ
コード中のデータの長さが前記しきい値以下である場合
に、当該データをそのレコードが格納されるブロックと
同一のブロックに格納し、レコード中のデータの長さが
前記しきい値を超える場合に、当該データをそのレコー
ドが格納されるブロックとは別のブロックに格納する処
理部である。

【００２７】データベース管理装置１０をしきい値指定
処理部１００及びデータ挿入処理部１０１として機能さ
せる為のプログラムは、ＣＤ−ＲＯＭ等の記録媒体に記
録され磁気ディスク等に格納された後、メモリにロード
されて実行されるものとする。なお前記プログラムを記
録する記録媒体はＣＤ−ＲＯＭ以外の他の記録媒体でも
良い。

【００２８】図１に示される様に本実施形態のデータベ
ースシステムは、主として、中央処理装置１１を有する
データベース管理装置１０とデータを物理的に格納する
記憶装置１３を備えている。データベース管理処理部１
２はデータベース管理装置１０上で動作し、記憶装置１
３上に実際のデータを格納しており、記憶装置１３に
は、データベース領域１４とそのデータの定義情報を格
納する為のシステム定義情報領域１５が存在している。

【００２９】図２は本実施形態のシステム定義情報領域
１５とデータベース領域１４の概略構成を示す図であ
る。本実施形態におけるデータベース領域１４は記憶装
置１３上の連続した領域に確保され、セグメント２０と
いう管理単位に分割される。入力されたデータは表単位
にまとめて、連続する記憶装置１３からなるデータベー
スのデータベース領域１４の記憶可能なエリアの管理単
位セグメント群として格納される。そのセグメント２０
は、実データを格納する為のデータ格納領域２１とその
データ格納領域を構成するディスク入出力の単位である
ページ群の空き状態を管理する為のページ管理ビットマ
ップ領域２２とから構成される。また、システム定義情
報領域１５にはデータベース中に定義された表の定義情
報を格納する為のＤＢ定義情報１６が存在する。

【００３０】次に、本実施形態の動作について説明す
る。図３は本実施形態のデータベースの表の定義例を示
す図である。図３において「ＮＥＷＳ」表は、リレーシ
ョナルデータベースにおけるデータベースアクセス言語
であるＳＱＬのデータ定義言語であるＣＲＥＡＴＥ Ｔ
ＡＢＬＥ文によって定義されるものである。

【００３１】表「ＮＥＷＳ」は、４個の列「ＮＥＷＳ＿
ＮＯ」、「ＤＡＴＥ」、「ＨＥＡＤＬＩＮＥ」、「ＣＯ
ＮＴＥＸＴ」で構成される。各々の列定義には、データ
型及びデータ長が指定される。

【００３２】「ＮＥＷＳ＿ＮＯ」列は、データ型として
数値型であるＩＮＴＥＧＥＲ型が指定され、データ長は
４バイトとなる。「ＤＡＴＥ」列は、データ型として固
定長文字列型であるＣＨＡＲ型が指定され、データ長は
１０バイトと指定している。

【００３３】「ＨＥＡＤＬＩＮＥ」列は、データ型とし
て可変長文字列型であるＶＡＲＣＨＡＲ型が指定され、
データ長として２５５バイトと指定している。「ＣＯＮ
ＴＥＸＴ」列は、データ型として可変長文字列型である
ＶＡＲＣＨＡＲ型が指定され、データ長として１２００
０バイトと指定している。

【００３４】固定長文字列の場合、入力するデータの最
大長は１０バイトであり、内部の実装上も１０バイトで
表現される。これに対して、可変長文字列の場合は指定
した長さを最大長とし、内部形式も実際のデータ長しか
格納しない。本定義では、更に「ＮＥＷＳ」表をデータ
ベース領域「ＡＲＥＡ１」に格納することを宣言してい
る。

【００３５】なお本実施形態において、表「ＮＥＷＳ」
にはニュースに関するデータが格納されるものとし、４
個の列「ＮＥＷＳ＿ＮＯ」、「ＤＡＴＥ」、「ＨＥＡＤ
ＬＩＮＥ」、「ＣＯＮＴＥＸＴ」それぞれには、ニュー
スの番号、日付、ヘッドライン、ニュースの内容が格納
されるものとする。また、この「ＨＥＡＤＬＩＮＥ」の
データは比較的短いデータであり、そのデータ長は通常
２５５バイト以下であるものとする。「ＣＯＮＴＥＸ
Ｔ」のデータは「ＨＥＡＤＬＩＮＥ」のデータよりも長
いデータであるが、動画データ等とは異なり、１０２４
バイト程度の長さで十分格納されうる新聞記事等のデー
タであるものとする。

【００３６】図４は本実施形態のＤＢ定義情報１６中の
定義情報の格納例を示す図である。図４に図３で示した
「ＮＥＷＳ」表に関する定義情報が、図２におけるＤＢ
定義情報１６中に格納されている様子を示す。ここで
は、ＤＢ定義情報として表定義情報管理テーブル８１と
列定義情報管理テーブル８２が格納されている。

【００３７】表定義情報管理テーブル８１には、表の情
報が格納され、図３における「ＮＥＷＳ」表の情報とし
て、表名、表番号、表の所有者、列数、データベース領
域名等の情報が格納される。また、列定義情報管理テー
ブル８２には、「ＮＥＷＳ」表を構成する５個の列であ
る「ＮＥＷＳ＿ＮＯ」、「ＤＡＴＥ」、「ＨＥＡＤ＿Ｌ
ＩＮＥ」、「ＣＯＮＴＥＸＴ」に関する列名、列番号、
表名、所有者、データ型、データ長及び可変長データを
別のブロックに格納するかどうかを判定する為のしきい
値等の情報が含まれる。

【００３８】本実施形態のしきい値指定処理部１００
は、図４に示す様にＤＢ定義情報である表定義情報管理
テーブル８１及び列定義情報管理テーブル８２の内容を
表示し、ユーザからしきい値が入力されると、入力され
たしきい値を、対応する列データのしきい値として列定
義情報管理テーブル８２に設定する。

【００３９】ユーザは、データベースのレコード中に定
義される可変長データ項目について、その可変長データ
項目に格納されるデータの長さがある程度予想できる場
合に、その平均的なデータ長を考慮し、平均的なデータ
長をある程度上回るしきい値や平均的なデータ長をある
程度下回るしきい値を設定することにより、分岐を行う
かどうかを制御することができる。

【００４０】例えば、図３における「ＮＥＷＳ」表の
「ＣＯＮＴＥＸＴ」列に格納されるデータが、「１０２
４」程度の長さでほぼ格納できると予想される場合に、
そのしきい値を「１０２４」とすることで分岐をできる
だけ抑止して格納効率の向上させることができる。

【００４１】なお図３における「ＮＥＷＳ」表では、
「ＣＯＮＴＥＸＴ」列定義において可変長データの別ブ
ロックへの分岐をできるだけ抑止する為のしきい値とし
て「１０２４」が指定されている。実際に「ＣＯＮＴＥ
ＸＴ」列に格納するデータ長が１０２４バイトを超える
場合には、そのデータは同じ行内ではなく、別ブロック
へ格納される。その他の列については、しきい値は全て
ＮＵＬＬと格納されており、列データの別ブロックへの
分岐を行わないかしきい値として固定値が用いられるこ
とを示している。

【００４２】図５は本実施形態のデータ挿入処理部１０
１の処理手順を示すフローチャートである。図５では本
実施形態で表のデータの挿入処理がどの様に実施されて
いるかを表しており、図５における１行挿入処理は、図
１におけるデータベース管理処理部１２上で動作し、ユ
ーザからＳＱＬのＩＮＳＥＲＴ文によって要求され、処
理されるものとする。ユーザから与えられる入力データ
は１行ずつ列単位で情報が渡されるものとする。本概略
フローを説明する前に行の格納形式を図６に示す。

【００４３】図６は本実施形態の行の格納形式の概要を
示す図である。図６では、図２の記憶装置１３上のデー
タベース領域１４のデータ格納領域２１を構成するペー
ジ内の行の格納形式を表しており、行は、先頭に行ヘッ
ダを持ち、行長及び可変長データ列が分岐した行なのか
否かを示す分岐行フラグ等の情報を持っている。行ヘッ
ダの直後には、当該行を構成する列数分の列データへの
オフセットを指すポインタ領域が置かれる。そして、各
列のオフセット領域の直後に列番号順に列データが格納
される。可変長データ型の列の場合には、列データの先
頭にそのデータの長さ情報が格納される。

【００４４】行の格納形式を踏まえて、図５の概略処理
フローを説明する。なお、予め図１におけるデータベー
ス管理装置１０上にデータベース管理処理部１２が確保
した行作成用領域上に行イメージを作成した後にデータ
ベース領域に出力するものとする。

【００４５】まず、図６に示した行ヘッダ中の行長に行
ヘッダ長を初期値として設定する（ステップ４００）。
次に、列数をカウントする為に初期値として列数を
「０」に設定する（ステップ４０１）。そして、入力さ
れた行データから１列ずつ列データを読み込む（ステッ
プ４０２）。列データを読み込み入力データが続く間、
行への列データの設定処理を行う（ステップ４０３）。

【００４６】各列データを読み込んだら、図４における
列定義情報から列のデータ型を照らし合わせ、可変長デ
ータ型かどうかを判定する（ステップ４０４）。可変長
データ型でない場合、すなわち図３における「ＮＥＷ
Ｓ」表の「ＮＥＷＳ＿ＮＯ」列、「ＤＡＴＥ」列では固
定長データ型であるので、現在の行長に列長を加える処
理を行う（ステップ４１２）。その後、入力したデータ
を行ヘッダ直後の列数分の列オフセット直後に各々の列
データを設定し、その列データの行内のオフセット値を
該当するオフセット領域に設定する（ステップ４１
３）。そして、現在の列数に列毎に「１」を加える（ス
テップ４１４）。

【００４７】「ＮＥＷＳ」表の「ＨＥＡＤＬＩＮＥ」列
の処理の場合、ステップ４０４において可変長データ型
であると認識され、続いて図４におけるＤＢ定義情報中
の列定義情報のしきい値情報を参照すると、しきい値は
ＮＵＬＬとなっていることが判る（ステップ４０５）。
つまり、しきい値の指定はない為、しきい値を固定値と
する（ステップ４０７）。固定値とはデータベース管理
処理部１２が予め定めた値であり、その予め定めたしき
い値を超える場合は無条件に列データを別ブロックに分
岐させるものである。ここでは、固定値のしきい値を
「２５５」と仮定する。「２５５」と仮定したのは、
「２５５」が行の内部形式において長さを表わす領域を
１バイトで表現した場合の最大長であり、可変長データ
型の場合には、その長さが２５５バイトを超えない場合
には分岐させず、更に長さを管理する領域も最小限にす
る必要があるからである。

【００４８】ここで処理フローに戻って、「ＨＥＡＤＬ
ＩＮＥ」列については、前記の様にその長さはしきい値
を超えることはないと仮定している為（ステップ４０
８）、通常の固定長型の列と同様にステップ４１２から
ステップ４１４までの処理を行って列データを設定す
る。最後に、「ＣＯＮＴＥＸＴ」列の入力データが与え
られると可変長データ型であると認識され（ステップ４
０４）、しきい値情報がＮＵＬＬではない為（ステップ
４０５）、指定された「１０２４」をしきい値に設定す
る（ステップ４０６）。

【００４９】そして、列長が指定されたしきい値を超え
るかどうかを判定する（ステップ４０８）。列長がしき
い値を超えていない場合は、当該列は現在の行にそのま
ま格納するものとし、ステップ４１２からステップ４１
４までの処理を行って行中に列を埋め込む。

【００５０】本実施形態では、「ＮＥＷＳ」表の「ＣＯ
ＮＴＥＸＴ」列に格納される新聞記事等のデータは「１
０２４」程度の長さでほぼ格納できるものとしているの
で、「ＣＯＮＴＥＸＴ」列の殆どのデータは現在の行に
そのまま格納される。この為、可変長データが別ブロッ
クに格納される際に生じていた、後の更新処理を考慮し
た空き領域が生じないので、格納効率を向上させること
が可能である。

【００５１】一方、ステップ４０８で、列長が指定され
たしきい値を超えている場合は、可変長データ挿入処理
（ステップ４０９）によって当該列を別のブロックに格
納する処理を行い、その別ブロックに格納した先頭の分
岐ポインタを返す処理を行う。別ブロックに分岐する場
合、１ブロックでは格納しきれない場合があるが、その
場合は１列を複数のブロックに分割して格納する処理を
行う。

【００５２】図７は本実施形態の可変長データ型の列が
別ブロックに分岐した場合の形態を示す図である。ここ
では、「行２」のある列が可変長データ型であって、か
つ、列長がしきい値を超えており、その列が別の２つの
ブロックに分割されて格納されている状態を示してい
る。その場合、元の行中の該当列の部分には、別ブロッ
クに分割された列データの先頭ブロックのポインタが格
納されている。

【００５３】また、別ブロックに格納された列データの
先頭ブロックの行の先頭には、更に分割した次のデータ
を格納したブロックの行へのポインタが格納されてい
る。最後に分割されたブロック上の行の分岐先のポイン
タには、これより先に分割していないことを示す為、ポ
インタ値として「０」が設定されている。

【００５４】図８は本実施形態の行形式による分割の形
態を示す図である。本分割の形態を更に行形式として詳
細に示したのが図８である。行形式の基本形式は、図６
の説明により示した通りである。図８では、図３の表の
定義例で示した「ＮＥＷＳ」表の「ＣＯＮＴＥＸＴ」列
の分岐している状態を示している。分岐した「ＣＯＮＴ
ＥＸＴ」列のブロックにも通常の行と同様に格納する
が、他の列データは持たない為、列オフセット領域は持
っていない。また、行ヘッダには、当該行の可変長デー
タが分岐されたことを示す分岐行フラグが設定されてい
る。全件検索時には、全てのブロックに格納された行を
対象にするが、当該行の様な場合、行ヘッダ部の行形式
を参照することによって、分岐行フラグが設定されてい
れば検索対象から外す処理が行われる。

【００５５】ここで、再度、図５の処理フローに戻る。
可変長データを分岐させる処理が行われると（ステップ
４０９）、返された分岐先のポインタを格納する為、ま
ず、行長に分岐ポインタの長さを加える（ステップ４１
０）。そして、実際に返された分岐ポインタを基の行の
中に設定する（ステップ４１１）。

【００５６】分岐ポインタの設定が終了するとステップ
４１２からステップ４１４までの処理を行う。最後にス
テップ４０２において次の列データがないことが判定さ
れると当該行の行長に列数分のオフセット領域の長さを
加える（ステップ４１５）。そして、作業用領域上に完
成した行イメージを格納すべきブロックを決定する（ス
テップ４１６）。本行格納ページ決定処理では、ブロッ
ク内に当該行長を格納するだけの空き領域を持つページ
を探す処理を行う。こうして、決定されたブロックへの
行の格納処理を行い行の挿入処理が完了する（ステップ
４１７）。行を挿入した場合には、必ず行の更新履歴と
してログを出力することは必須である。

【００５７】前記の様に本実施形態では、レコード中の
可変長データにしきい値を指定してその可変長データを
別のブロックに分岐させるかどうか制御する場合につい
て説明したが、レコード中の固定長データにしきい値を
指定してその固定長データを別のブロックに分岐させる
かどうか制御することとしても良い。

【００５８】すなわち、ユーザによっては、データベー
スの定義の際に本来可変長であるデータについても固定
長の定義を行って、レコード中のデータを全て固定長デ
ータとしている場合があるが、検索に用いられる頻度が
少なく、データ長の大きい固定長データに対してしきい
値を指定して分岐を促進する様にすれば、検索の際にそ
の固定長データが含まれていないブロックのみが参照さ
れ、分岐先の別のブロックが検索されることが無いの
で、データベースの検索効率を向上させることが可能で
ある。

【００５９】以上説明した様に本実施形態のデータベー
ス管理装置によれば、レコード中のデータに応じて指定
されたしきい値によりレコード中のデータを分岐させる
かどうかを制御するので、データベースの格納効率を向
上させることが可能である。

【００６０】

【発明の効果】本発明によればレコード中のデータに応
じて指定されたしきい値によりレコード中のデータを分
岐させるかどうかを制御するので、データベースの格納
効率を向上させることが可能である。

【図面の簡単な説明】

【図１】本実施形態のデータベース管理装置の概略構成
を示す図である。

【図２】本実施形態のシステム定義情報領域１５とデー
タベース領域１４の概略構成を示す図である。

【図３】本実施形態のデータベースの表の定義例を示す
図である。

【図４】本実施形態のＤＢ定義情報１６中の定義情報の
格納例を示す図である。

【図５】本実施形態のデータ挿入処理部１０１の処理手
順を示すフローチャートである。

【図６】本実施形態の行の格納形式の概要を示す図であ
る。

【図７】本実施形態の可変長データ型の列が別ブロック
に分岐した場合の形態を示す図である。

【図８】本実施形態の行形式による分割の形態を示す図
である。

【符号の説明】

１０…データベース管理装置、１１…中央処理装置、１
２…データベース管理処理部、１３…記憶装置、１４…
データベース領域、１５…システム定義情報領域、１０
０…しきい値指定処理部、１０１…データ挿入処理部、
１６…ＤＢ定義情報、２０…セグメント、２１…データ
格納領域、２２…ページ管理ビットマップ領域、８１…
表定義情報管理テーブル、８２…列定義情報管理テーブ
ル。

Claims (5)

【特許請求の範囲】
1. 【請求項１】 レコードをブロックに格納して管理する
   データベース管理方法において、 レコード中のデータをそのレコードが格納されるブロッ
   クとは別のブロックに格納するかどうかを判定する為の
   しきい値を設定するステップと、レコード中のデータの
   長さが前記しきい値以下である場合に、当該データをそ
   のレコードが格納されるブロックと同一のブロックに格
   納し、レコード中のデータの長さが前記しきい値を超え
   る場合に、当該データをそのレコードが格納されるブロ
   ックとは別のブロックに格納するステップとを有するこ
   とを特徴とするデータベース管理方法。
2. 【請求項２】 前記データが可変長データである場合
   に、そのレコードが格納されるブロックと同一のブロッ
   クに当該可変長データを格納する為のしきい値を設定す
   ることを特徴とするデータベース管理方法。
3. 【請求項３】 前記データが固定長データである場合
   に、そのレコードが格納されるブロックとは別のブロッ
   クに当該固定長データを格納する為のしきい値を設定す
   ることを特徴とするデータベース管理方法。
4. 【請求項４】 レコードをブロックに格納して管理する
   データベース管理装置において、 レコード中のデータをそのレコードが格納されるブロッ
   クとは別のブロックに格納するかどうかを判定する為の
   しきい値を設定するしきい値指定処理部と、レコード中
   のデータの長さが前記しきい値以下である場合に、当該
   データをそのレコードが格納されるブロックと同一のブ
   ロックに格納し、レコード中のデータの長さが前記しき
   い値を超える場合に、当該データをそのレコードが格納
   されるブロックとは別のブロックに格納するデータ挿入
   処理部とを備えることを特徴とするデータベース管理装
   置。
5. 【請求項５】 レコードをブロックに格納して管理する
   データベース管理装置としてコンピュータを機能させる
   為のプログラムを記録したコンピュータ読み取り可能な
   記録媒体において、 レコード中のデータをそのレコードが格納されるブロッ
   クとは別のブロックに格納するかどうかを判定する為の
   しきい値を設定するしきい値指定処理部と、レコード中
   のデータの長さが前記しきい値以下である場合に、当該
   データをそのレコードが格納されるブロックと同一のブ
   ロックに格納し、レコード中のデータの長さが前記しき
   い値を超える場合に、当該データをそのレコードが格納
   されるブロックとは別のブロックに格納するデータ挿入
   処理部としてコンピュータを機能させる為のプログラム
   を記録したことを特徴とする記録媒体。