JPH09305449A - データベース管理システム - Google Patents

Abstract

(57)【要約】 【課題】 長大可変長データ用データベース領域の再編
成時のオーバヘッドが小さく、且つ、セキュリティや処
理効率の問題を生じることがないデータベース管理シス
テムを提供する。 【解決手段】 基本データ項目のデータは基本行データ
ベース領域５０に格納し、長大可変長データ項目のデー
タは長大可変長データ用データベース領域６０に格納す
る。長大可変長データ６４には通番を付加し、その通番
を基本データ項目中の一つのデータ項目５２とし、あた
かも同じデータベース領域内に存在するかのように見せ
る。 【効果】 長大可変長データ用データベース領域６０を
再編成しても通番は変化しないから、基本行データベー
ス領域５０にアクセスする必要がなく、オーバヘッドを
小さく出来る。また、ファイル管理をシステムプログラ
ムに委ねることがないため、セキュリティや処理効率の
問題を生じない。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、データベース管理
システムに関し、さらに詳しくは、画像や音声，文書な
どの長大可変長データ項目のデータを効率良く管理する
ためのデータベース管理システムに関する。

【０００２】

【従来の技術】第１の従来技術では、基本データ項目
（長大可変長データ項目でないデータ項目）のデータ
は、基本行データベース領域に格納する。長大可変長デ
ータ項目のデータは、前記基本行データベース領域とは
異なる長大可変長データ用データベース領域に格納す
る。そして、その長大可変長データ項目のデータを格納
している領域への物理ポインタを、前記基本行データベ
ース領域に格納し、あたかも同じデータベース領域内に
存在するかのように見せる。第２の従来技術では、基本
データ項目のデータは、基本行データベース領域に格納
する。長大可変長データ項目のデータは、前記基本行デ
ータベース領域とは異なる長大可変長データ用データベ
ース領域に各データ毎のファイルとして格納する。そし
て、それらのファイル名を、前記基本行データベース領
域に格納し、あたかも同じデータベース領域内に存在す
るかのように見せる。上記のように、基本行データベー
ス領域と長大可変長データ用データベース領域とを別に
する理由は、両方のデータを同じデータベース領域に混
在させて格納すると、アクセス効率が非常に悪くなるか
らである。

【０００３】

【発明が解決しようとする課題】上記第１の従来技術で
は、長大可変長データ項目のデータを格納している領域
への物理ポインタを基本行データベース領域に格納して
いるため、長大可変長データ用データベース領域のデー
タ配置が乱れた場合に再編成を行うと、基本行データベ
ース領域に格納している物理ポインタを大幅に更新する
必要があり、再編成時のオーバヘッドが大きい問題があ
る。一方、上記第２の従来技術では、ファイル管理をシ
ステムプログラムに委ねることになるため、セキュリテ
ィの点および処理効率の点で問題がある。そこで、本発
明の目的は、長大可変長データ用データベース領域の再
編成時のオーバヘッドが小さく、且つ、セキュリティや
処理効率の問題を生じることがないデータベース管理シ
ステムを提供することにある。

【０００４】

【課題を解決するための手段】第１の観点では、本発明
は、基本データ項目（長大可変長データ項目でないデー
タ項目）のデータを格納するための第１のデータベース
格納領域と、長大可変長データ項目のデータを格納する
ための第２のデータベース格納領域とを備え、前記第１
のデータベース格納領域は、基本データ項目のデータを
物理的に固定長のページ単位で格納するデータ格納領域
と、そのデータ格納領域の空きをページ単位の使用／未
使用により管理する空き領域管理領域とを含み、前記第
２のデータベース格納領域は、長大可変長データ項目の
データを格納する長大可変長データ格納領域と、その長
大可変長データ格納領域の空きを管理する空き領域管理
領域と、前記長大可変長データ項目のデータの追加に伴
って単調に増加または減少する通番を付加する採番領域
と、前記通番と前記長大可変長データ項目のデータの格
納位置とを対応付けるデータマッピング領域とを含み、
さらに、前記基本データ項目は、前記長大可変長データ
項目のデータの格納位置を管理するデータ項目を含み、
そのデータ項目のデータは、前記通番を含むことを特徴
とするデータベース管理システムを提供する。上記第１
の観点によるデータベース管理システムでは、基本デー
タ項目のデータと長大可変長データ項目のデータとを異
なるデータベース領域に分離して格納すると共に、長大
可変長データ項目のデータには通番を付加し、その通番
を基本データ項目中の一つのデータ項目にし、あたかも
同じデータベース領域内に存在するかのように見せる。
第２のデータベース領域を再編成しても通番は変化しな
いから、第１のデータベース領域にアクセスする必要が
ない。従って、第１のデータベース領域と第２のデータ
ベース領域の再編成を独立に行えるようになり、オーバ
ヘッドを小さく出来る。また、ファイル管理をシステム
プログラムに委ねることがないため、セキュリティや処
理効率の問題を生じることもない。

【０００５】第２の観点では、本発明は、上記構成のデ
ータベース管理システムにおいて、長大可変長データ項
目のデータを挿入する要求が与えられた時、そのデータ
に対する通番を採番し、そのデータを第２のデータベー
ス領域に格納し、その格納位置と前記通番との対応をデ
ータマッピング領域に保持し、前記通番をデータ項目と
して含む基本データ項目のデータを作成し、そのデータ
を第１のデータベース領域に格納することを特徴とする
データベース管理システムを提供する。上記第２の観点
によるデータベース管理システムでは、長大可変長デー
タ項目のデータを好適に挿入することが出来る。

【０００６】第３の観点では、本発明は、上記構成のデ
ータベース管理システムにおいて、通番は、ロールバッ
ク対象としないことを特徴とするデータベース管理シス
テムを提供する。上記第３の観点によるデータベース管
理システムでは、障害からの回復時に、長大可変長デー
タ項目のデータの通番を新たに採番することとなるが、
その方が管理を簡単化できる。

【０００７】

【発明の実施の形態】以下、本発明の実施形態を添付図
面を用いて説明する。まず、図１〜図５により行挿入に
関する説明を行い、その後、図６〜図７により再編成に
関する説明を行う。

【０００８】図１は、本発明の一実施形態にかかるデー
タベース管理システム２０を含むコンピュータシステム
１０の構成図である。但し、データベース管理システム
２０の構成は、行挿入に関する部分を示している。この
コンピュータシステム１０は、ＣＰＵ１２、主記憶装置
１４、磁気ディスク等の外部記憶装置３０および多数の
端末１８で構成される。主記憶装置１４上には、データ
ベース管理システム２０が置かれている。外部記憶装置
３０上には、データベース管理システム２０が管理する
データベースとして、データベースに定義された表定義
情報や格納定義情報等を管理するデータディクショナリ
４０、基本データ項目のデータを格納する基本行データ
ベース領域５０、長大可変長データ項目のデータを格納
する長大可変長データ用データベース領域６０およびデ
ータベース更新履歴情報であるログファイル７０が格納
されている。

【０００９】データベース管理システム２０は、質問解
析処理部２１、データベース演算処理部２２、基本行デ
ータ管理部２３、長大可変長データ管理部２４、バッフ
ァプール管理部２５、ログ管理部２６、バッファプール
３２およびログバッファ３４を具備している。前記質問
解析処理部２１は、ユーザからのデータベース問合せ要
求であるＳＱＬ（構造化照会言語）を受け取り、構文解
析，意味解析処理を通してデータベースアクセスの最適
なアクセス経路を決定する最適化処理を行い、決定した
アクセス経路に基づいてデータベース処理用の内部処理
コードを生成する。前記データベース演算処理部２２
は、生成された内部処理コードを基にデータベースアク
セスを行う。前記基本行データ管理部２３は、基本行デ
ータベース領域５０に格納された基本データ項目のデー
タにアクセスする。前記長大可変長データ管理部２４
は、長大可変長データ用データベース領域６０に格納さ
れた長大可変長データ項目のデータにアクセスする。前
記バッファプール管理部２５は、データディクショナリ
４０，基本行データベース領域５０および長大可変長用
データベース領域６０からデータを確保したバッファプ
ール３２との間でデータの入出力を行う。前記ログ管理
部２６は、端末１８から投入されたトランザクションに
よって行われたデータの更新履歴情報であるログを管理
し、各ログレコードのログシーケンス番号を割り振り、
トランザクションの完了時にログバッファ３４からログ
ファイル７０に書き込む。

【００１０】図２は、データディクショナリ４０に格納
されたデータベース定義情報の説明図である。データベ
ース管理システム特にリレーショナルデータベース管理
システムでは、データは、複数の行からなる表（リレー
ション）で管理される。表は、複数の列から構成され
る。各列は、データ型，データ長等の属性情報を持つ。
また、データは、外部記憶装置３０の基本行データベー
ス領域５０または長大可変長データ用データベース領域
６０に格納されるため、データベース領域を管理する情
報を持つ必要がある。データベース領域管理表４１は、
データベース領域を管理する情報の表であり、データベ
ース領域名，当該データベース領域の種別を表す種別
（Ｄはデータディクショナリ４０，Ｒは基本行データベ
ース領域５０，Ｌは長大可変長データ用データベース領
域６０を示す）および構成ファイル数（当該データベー
ス領域を構成する論理的なファイル数）の列で構成され
る。データベース領域は、データベース容量の大規模化
に対応できるように論理的な領域として捉え、複数のフ
ァイルで構成する。データベース領域構成ファイル管理
表４２は、データベース領域を構成するファイルを管理
する表であり、データベース領域名，ファイルの順序を
示す番号および構成ファイル名の列で構成される。表管
理表４３は、表名，表の所有者，表の構成列数および表
の基本データ項目のデータを格納する（基本行）データ
ベース領域名の列で構成される。構成列情報管理表４４
は、表を構成する列の定義情報であり、列名，当該列を
持つ表名，表の所有者，当該列のデータ型（integer は
数値データ型，charは文字型，ＬＯＢは長大可変長デー
タ型）と最大データ長，当該列が表を構成する順序を示
す列番号および当該列が長大可変長データ項目である場
合にそのデータを格納する（長大可変長データ用）デー
タベース領域名の列で構成される。当該列が基本データ
項目のときは、データベース領域名の値には、ＮＵＬＬ
が格納される。

【００１１】図３は、基本行データベース領域５０およ
び長大可変長データ用データベース領域６０の格納構造
図である。基本行データベース領域５０は、空き領域を
管理する空き領域管理情報５１と、表の各行のデータ５
２ａ〜５２ｅから構成される。前記空き領域管理情報５
１は、基本行データベース領域５０を構成する複数のフ
ァイルについて、予め定義されたサイズに基づきファイ
ルを物理的に固定長の複数のページで区分けすることに
よって、すべてのページをビットマップで表現し、ペー
ジ単位で空きを管理する。行のデータ５２は、空き領域
管理情報５１に基づいて割り当てたページに格納され
る。１ページには、複数の行を格納する。各行の複数の
列の各データは、定義された列の順番で格納される。図
３の例では、表が４つの列で構成されている。列１から
列３は基本データ項目である。第４列目は、長大可変長
データ項目である。あたかもそこに長大可変長データが
存在するかのように見せるため、第４列目には、長大可
変長データ用データベース領域６０に格納したデータに
割り振られた通番（ＬＯＢＩＤ）が格納される。複数の
表のデータを基本行データベース領域５０に格納する場
合には、表毎のデータの格納情報を管理する情報が付加
されるとよい。

【００１２】長大可変長データ用データベース領域６０
は、領域内のデータに対して通番を付加するためのＬＯ
ＢＩＤ採番情報６１、空き領域を管理する空き領域管理
情報６２、通番に対応するデータの物理位置情報をマッ
ピングするデータマッピング領域６３およびデータ６４
ａ〜６４ｄから構成される。空き領域管理上６２は、長
大可変長データ用データベース領域を構成する複数のフ
ァイルについて、予め定義されたサイズに基づきファイ
ルを物理的に固定長の複数のページで区分けすることに
よって、すべてのページをビットマップ等で表現し、空
きをページ単位で管理する。なお、空き領域管理情報６
２は、空き領域の先頭および末尾の位置情報と総空き領
域長を持ち、各々の空き領域間をポインタによってチェ
インする方法で実現してもよい。

【００１３】次に、データベース管理システム２０の動
作を説明する。図１に示す端末１８から次のＳＱＬのＩ
ＮＳＥＲＴ文による行の挿入要求が投入された場合を想
定する。 INSERT INTO DOCUMENT VALUES(1001,'特許抄録1001',John,'発明の名称・・
・') 上記ＳＱＬが投入されると、データベース管理システム
２０は、質問解析処理部２１にて構文を解析する。解析
の結果、文法が正しいと判断されると、データディクシ
ョナリ４０を検索し、指定された表「ＤＯＣＵＭＥＮ
Ｔ」の存在を図２に示す表管理表４３によりチェックす
る。表「ＤＯＣＵＭＥＮＴ」の存在が確認できたら、表
「ＤＯＣＵＭＥＮＴ」のデータを格納する基本行データ
ベース領域名「ＡＲＥＡ２」を取得する。また、構成列
情報管理表４４から表名「ＤＯＣＵＭＥＮＴ」の構成列
情報を取得する。この時、列名「ＣＯＮＴＥＸＴ」は、
長大可変長データ項目のデータ型「ＬＯＢ」であり、長
大可変長データ用データベース領域名「ＡＲＥＡ３」に
格納することが判る。次に、質問解析処理部２１では、
取得した情報にしたがってデータベース処理用の内部処
理コードを生成し、その内部処理コードの実行要求をデ
ータベース演算処理部２２に発行する。ここでは、行の
挿入処理要求が発行される。具体的には、表「ＤＯＣＵ
ＭＥＮＴ」に対して、列名「ＣＯＮＴＥＸＴ」以外の列
のデータは基本行データベース領域「ＡＲＥＡ２」に格
納し、列名「ＣＯＮＴＥＸＴ」のデータは長大可変長デ
ータ用データベース領域「ＡＲＥＡ３」に格納すること
を指示した行の挿入処理要求が発行される。データベー
ス演算処理部２２は、処理要求を解析し、列名「ＣＯＮ
ＴＥＸＴ」以外のデータの挿入処理要求を基本行データ
管理部２３にて行い、列名「ＣＯＮＴＥＸＴ」のデータ
の挿入処理要求を長大可変長データ管理部２４にて行う
よう制御する。

【００１４】図４は、上記データベース演算処理部２２
により制御される行挿入処理のフローチャートである。
ステップ２３１０では、指定された表「ＤＯＣＵＭＥＮ
Ｔ」のデータを格納する基本行データベース領域「ＡＲ
ＥＡ２」に対して排他制御のためのロックを取得する。
これは、当該データベース領域の不当な削除を防止する
ためである。ステップ２３１２では、表「ＣＯＮＴＥＸ
Ｔ」に対しロックを取得する。ロックのモードとして
は、排他モード（Ｘ：Ｅxclusive）を取得することによ
り、他のユーザからの表に対する同時実行性を確保して
いる。より細かなロックのレベルとして、ページレベル
あるいは行レベルのロックをする機構が備わっていれ
ば、こうした表レベルの排他モードには、ＩＸ（Ｉnten
t Ｅxclusive）モードが望ましい。

【００１５】ステップ２３１４では、データベース管理
システム２０が主記憶装置１４上に確保した作業領域上
に、基本行の格納形式にしたがって、図３における基本
行データベース領域５０内の行５２のように行を組み立
てる。この時、列「ＣＯＮＴＥＸＴ」のデータは何でも
良い。ステップ２３１６では、長大可変長データがある
かどうかをチェックし、あればステップ２３１８へ進
み、なければステップ２３２２へジャンプする。ステッ
プ２３１８では、長大可変長データ挿入処理を行う。こ
の長大可変長データ挿入処理については図５を参照して
後述する。ステップ２３２０では、長大可変長データの
挿入によって採番された通番ＬＯＢＩＤを列「ＣＯＮＴ
ＥＸＴ」のデータとする。

【００１６】ステップ２３２２では、完成した基本行を
格納するためのデータベース領域「ＡＲＥＡ２」のペー
ジを空き領域管理情報５１から決定する。使用中のペー
ジであっても、前記基本行を格納できる空き領域があれ
ば、その使用中のページを行格納ページとして決定す
る。使用中のページに空き領域がなければ、新ページを
確保し、そのページを行格納ページとして決定する。さ
らに、前記基本行に対して識別子として行ｉｄを割り振
る。この行ｉｄは、ページ番号とページ内の格納位置を
示す番号で構成される。

【００１７】ステップ２３２４では、行ｉｄを使用し
て、行レベルのロックを排他モード（Ｘ：Ｅxclusive）
で取得する。ステップ２３２６では、バッファプール管
理部２５に対して行格納ページバッファの割り当て要求
を行い、バッファをバッファプール３２上に取得する。
この時、決定されている行格納ページが使用中のページ
であれば、その使用中のページに割り当てられているバ
ッファを取得する。また、決定されている行格納ページ
が新ページであれば、空きバッファを取得する。

【００１８】ステップ２３２８では、取得したページバ
ッファに対して行を挿入する前に、障害等による回復処
理のために、更新前ログを書き出す。ログの書き出しと
は、ログ管理部２６に対してログレコード書き出し要求
を行い、ログをログバッファ３４に書き込むことをい
う。なお、物理的なページのログを保持するデータベー
ス管理システムの場合にはログの書き出し処理が必要で
あるが、論理的な操作ログ（データを挿入したことを示
すログ、例えば前述したＳＱＬのＩＮＳＥＲＴ文と同様
な情報）を保持する場合にはログの書き出し処理は不要
である。

【００１９】ステップ２３３０では、ページバッファへ
の基本行の挿入処理を行う。ステップ２３３２では、更
新後ログを書き出す処理をログ管理部２６に要求する。
更新後ログを書き出す理由は、当該データの挿入処理を
含むトランザクションが完了した後に外部記憶装置３０
が故障した場合や、バッファプール３２上から外部記憶
装置３０上のデータベース領域に書き込みが完了する前
にシステム停止を生じた場合などに、回復可能にするた
めである。

【００２０】ステップ２３３４では、バッファプール管
理部２５に対して行格納ページバッファの書き込み要求
を行う。バッファプール管理部２５に対して要求された
書き込み要求は、必ずしも外部記憶装置３０上のデータ
ベース領域に即時に反映する必要はない。バッファプー
ル管理部２５がバッファプール３２の管理方法にしたが
ってページバッファの書き込みが必要になった時点で外
部記憶装置３０上のデータベース領域に書き込みが行わ
れればよい。ただし、トランザクション完了までには、
当該トランザクション内で書き出したログはログファイ
ル７０に出力されている必要がある。

【００２１】図５は、長大可変長データ挿入処理（ステ
ップ２３１８）のフローチャートである。ステップ２４
１０では、指定された表「ＤＯＣＵＭＥＮＴ」の長大可
変長データ列「ＣＯＮＴＥＸＴ」を格納する長大可変長
データ用データベース領域「ＡＲＥＡ３」に対してロッ
クを取得する。ステップ２４１２では、挿入する長大可
変長データに対して通番ＬＯＢＩＤを採番するため、バ
ッファプール管理２５に対してページバッファ取得要求
を行い、ＬＯＢＩＤ採番情報６１をページバッファに取
得する。このとき、他のユーザからの当該ＬＯＢＩＤ採
番情報６１に対する同時アクセスを禁止する必要があ
る。そこで、バッファプール管理部２５が、ページバッ
ファを取得する際に行うラッチ（ロックよりも高速で短
期間のバッファプールの物理的整合性を保証する手段）
にてアクセス禁止状態を設定する。なお、Ｘモードのロ
ックを取得する方法によって同時アクセスを禁止しても
よい。

【００２２】ステップ２４１４では、通番ＬＯＢＩＤの
現在の番号を“１”だけインクリメントし、新たな通番
ＬＯＢＩＤを取得する。ステップ２４１６では、ＬＯＢ
ＩＤ採番情報６１を格納したページバッファを即時に長
大可変長データ用データベース領域６０に書き込む。こ
れは、通番ＬＯＢＩＤは、ロールバック対象としないた
めである。通番ＬＯＢＩＤをロールバック対象としない
場合、障害からの回復時に、通番を新たに採番すること
になるが、通番を回復するよりも新たに採番した方が管
理を簡単化できる。

【００２３】ステップ２４１８では、長大可変長データ
を格納する領域を確保する。基本行を格納する基本行デ
ータベース領域と同様にページ単位の領域をビットマッ
プにて管理する場合、空き領域管理情報６２を用いて、
長大可変長データが格納できるだけのページを確保す
る。

【００２４】ステップ２４２０では、確保した長大可変
長データ格納領域の位置情報（ページ番号）を保持して
おき、指定された領域に列名「ＣＯＮＴＥＸＴ」のデー
タを書き込む。長大可変長データはデータ長が長いとい
う特徴から、バッファプール３２でのバッファリングに
よる入出力処理の削減効果を期待できないため、主記憶
装置１４上に確保した作業領域上に格納された列名「Ｃ
ＯＮＴＥＸＴ」のデータを、直接、長大可変長データ用
データベース領域６０に書き込む。

【００２５】ステップ２４２２では、列名「ＣＯＮＴＥ
ＸＴ」のデータを更新後ログとして書き出す。このと
き、更新後ログは、ログバッファ３４に書き出すだけで
なく、ログファイル７０に強制出力しておく必要があ
る。

【００２６】ステップ２４２４では、挿入したデータの
通番ＬＯＢＩＤに対応するデータマッピング領域６３
（図３）のエントリに、挿入したデータの位置情報を格
納する。

【００２７】さて、新たに行を追加したり，行を削除し
たり，列に対して更新を行ったりする操作を繰り返して
いると、データベース領域中の全てのページが使用中状
態となってはいるが実際には多くのページに空きが散在
する現象を生じる。これをデータの配置の乱れという。
データの配置の乱れを生じると、新たに行を追加しよう
とした時、その行を格納するための空き領域を探索する
処理時間のオーバヘッドが大きくなる。そこで、このオ
ーバヘッドを小さくするために、データベース領域中の
空き領域をまとめる処理を行う必要がある。この処理
を、データベースの再編成という。次に、データベース
再編成の動作について説明する。

【００２８】図６は、本発明の一実施形態にかかるデー
タベース管理システム２０を含むコンピュータシステム
１０の構成図である。但し、データベース管理システム
２０の構成は、再編成に関する部分を示している。デー
タベース管理システム２０は、再編成処理部２７を具備
している。この再編成処理部２７は、データベース検索
処理部２７１、アンロード処理部２７２およびリロード
処理部２７３から構成される。前記データベース検索処
理部２７１は、端末１８からデータベースの再編成要求
が投入されたとき、要求されたデータベース領域からデ
ータベース定義情報を検索する。前記アンロード処理部
２７２は、要求されたデータベース領域に存在するデー
タを外部記憶装置３０に用意されたアンロードファイル
８０に対してアンロードする。前記リロード処理部２７
３は、アンロード処理完了後にデータベース領域中の空
き領域管理部を初期化することによって、データベース
領域の空きを初期状態にする。そして、アンロードファ
イル８０からデータを読み出し、データベース領域にリ
ロードする。

【００２９】図７は、前記アンロードファイル８０の構
成図である。アンロードヘッダ部８１は、アンロードフ
ァイルであることを識別する情報、アンロード種別とし
て基本行データベース領域や長大可変長データ用データ
ベース領域を示す情報、アンロードファイルの作成者の
情報などから構成される。表情報部８２は、アンロード
したデータベース領域に含まれる表の定義情報（図３の
表管理表４３と同等の情報）から構成される。列情報部
８３は、表の定義情報に基づいて取得した列の情報（図
３の構成列情報管理表４４と同等の情報）から構成され
る。データ部８４は、アンロードしたデータが格納され
る。

【００３０】いま、データベース領域「ＡＲＥＡ３」を
再編成する要求が端末１８から投入されると、データベ
ース定義情報検索部２７１は、データディクショナリ４
０に存在するデータベース領域管理表４１およびデータ
ベース領域構成ファイル管理表４２から、データベース
領域「ＡＲＥＡ３」が存在し、それが長大可変長データ
用データベース領域であることを情報として取得する。
そして、その長大可変長データ用データベース領域「Ａ
ＲＥＡ３」のアンロード処理要求をアンロード処理部２
７２に対して発行する。

【００３１】アンロード処理部２７２は、長大可変長デ
ータ用データベース領域「ＡＲＥＡ３」に対してロック
（Ｘモード）を取得する。これにより、長大可変長デー
タ用データベース領域「ＡＲＥＡ３」に対するアクセス
が禁止される。但し、長大可変長データ項目の列「ＣＯ
ＮＴＥＸＴ」に対するアクセスが行われない限り、表
「ＤＯＣＵＭＥＮＴ」に対するアクセスは許可される。
次に、アンロード処理部２７２は、アンロードファイル
８０にアンロードヘッダ部８１，表情報部８２および列
情報部８３を書き込む。次に、アンロード処理部２７２
は、データマッピング領域６３（図３）を先頭から参照
し、値の存在するデータを見つけると、図７に示すよう
に、その通番ＬＯＢＩＤ，データ長および実際のデータ
をアンロードファイル８０のデータ部８４に書き込む。
長大可変長データ用データベース領域「ＡＲＥＡ３」に
存在するすべてのデータをアンロードファイル８０に書
き込んだら、リロード処理部２７３に制御を渡す。

【００３２】リロード処理部２７３は、空き領域管理情
報６２に含まれる長大可変長データ用データベース領域
「ＡＲＥＡ３」のすべてのビットマップを初期化する
（すべてのデータ格納領域を空きにする）。一般的に、
再編成時にデータを１件ずつ削除するよりも、空き領域
管理情報６２に含まれるビットマップデータを初期化す
る方が効率が良い。次に、リロード処理部２７３は、ア
ンロードファイル８０に格納されたデータの順番でデー
タを読み出しながら、図５と同様にして、通番ＬＯＢＩ
Ｄを指定した長大可変長データの挿入処理を行う。ただ
し、図５の場合と異なり、通番ＬＯＢＩＤの採番処理
（ステップ２４１４）は必要ない。また、ＬＯＢＩＤデ
ータマッピングエントリ更新処理（ステップ２４２４）
では、リロード時に新たに決定した格納位置情報を格納
する。アンロードファイル８０からすべてのデータをリ
ロードすると、長大可変長データ用データベース領域
「ＡＲＥＡ３」に対するロック（Ｘモード）を開放す
る。

【００３３】以上のように、長大可変長データ用データ
ベース領域「ＡＲＥＡ３」の再編成時には、基本行デー
タベース領域「ＡＲＥＡ２」には何らアクセスは発生し
ない。従って、更新処理のオーバヘッドを小さく出来
る。また、ファイル管理をシステムプログラムに委ねる
ことがないため、セキュリティや処理効率の問題を生じ
ることもない。

【００３４】

【発明の効果】本発明のデータベース管理システムによ
れば、基本データ項目のデータベース領域と長大可変長
データ項目のデータベース領域とを独立に再編成できる
ため、オーバヘッドが小さくなり、処理効率を向上でき
る。また、ファイル管理をシステムプログラムに委ねる
ことがないため、セキュリティの点および処理効率の点
で問題を生じない。

【図面の簡単な説明】

【図１】本発明の一実施形態にかかるデータベース管理
システム（行挿入関連部分）を含むコンピュータシステ
ムの構成図である。

【図２】データディクショナリの構成図である。

【図３】データベース領域の構成図である。

【図４】行挿入処理のフローチャートである。

【図５】長大可変長データ挿入処理のフローチャートで
ある。

【図６】本発明の一実施形態にかかるデータベース管理
システム（再編成関連部分）を含むコンピュータシステ
ムの構成図である。

【図７】アンロードファイルの構成図である。

【符号の説明】

１０：コンピュータシステム １２：ＣＰＵ １４：主記憶装置 １８：端末 ２０：データベース管理システム ２１：質問解析処理部 ２２：データベース演算処理部 ２３：基本行データ管理部 ２４：長大可変長データ管理部 ２５：バッファプール管理部 ２６：ログ管理部 ２７：再編成処理部 ２７１：データベース定義情報検索部 ２７２：アンロード処理部 ２７３：リロード処理部 ３０：外部記憶装置 ３２：バッファプール ３４：ログバッファ ４０：データディクショナリ ５０：基本行データベース領域 ５１：空き領域管理情報 ５２：行 ６０：長大可変長データ用データベース領域 ６１：ＬＯＢＩＤ採番情報 ６２：空き領域管理情報 ６３：データマッピング領域 ６４：長大可変長データ ７０：ログフィル ８０：アンロードファイル

───────────────────────────────────────────────────── フロントページの続き (72)発明者 原 憲宏 神奈川県川崎市幸区鹿島田890番地の12 株式会社日立製作所情報・通信開発本部内 (72)発明者 北村 健一 神奈川県横浜市中区尾上町６丁目81番地 日立ソフトウエアエンジニアリング株式会 社内

Claims (3)

【特許請求の範囲】
1. 【請求項１】 基本データ項目（長大可変長データ項目
   でないデータ項目）のデータを格納するための第１のデ
   ータベース格納領域と、長大可変長データ項目のデータ
   を格納するための第２のデータベース格納領域とを備
   え、 前記第１のデータベース格納領域は、基本データ項目の
   データを物理的に固定長のページ単位で格納するデータ
   格納領域と、そのデータ格納領域の空きをページ単位の
   使用／未使用により管理する空き領域管理領域とを含
   み、 前記第２のデータベース格納領域は、長大可変長データ
   項目のデータを格納する長大可変長データ格納領域と、
   その長大可変長データ格納領域の空きを管理する空き領
   域管理領域と、前記長大可変長データ項目のデータの追
   加に伴って単調に増加または減少する通番を付加する採
   番領域と、前記通番と前記長大可変長データ項目のデー
   タの格納位置とを対応付けるデータマッピング領域とを
   含み、 さらに、前記基本データ項目は、前記長大可変長データ
   項目のデータの格納位置を管理するデータ項目を含み、
   そのデータ項目のデータは、前記通番を含むことを特徴
   とするデータベース管理システム。
2. 【請求項２】 請求項１に記載のデータベース管理シス
   テムにおいて、長大可変長データ項目のデータを挿入す
   る要求が与えられた時、そのデータに対する通番を採番
   し、そのデータを第２のデータベース領域に格納し、そ
   の格納位置と前記通番との対応をデータマッピング領域
   に保持し、前記通番をデータ項目として含む基本データ
   項目のデータを作成し、そのデータを第１のデータベー
   ス領域に格納することを特徴とするデータベース管理シ
   ステム。
3. 【請求項３】 請求項１または請求項２に記載のデータ
   ベース管理システムにおいて、通番は、ロールバック対
   象としないことを特徴とするデータベース管理システ
   ム。