JPH08129501A - データベースの予約アクセス処理方法 - Google Patents

Abstract

(57)【要約】 【目的】オンラインデータベースシステムにおいて、複
数レコードの更新又は参照を予約登録することにより、
オンラインシステムを停止することなくそれらの更新又
は参照処理を実行できるようにすることを目的とする。 【構成】多数のレコードからなるデータベーステーブル
を格納する記憶装置と、該テーブルの任意のレコードに
アクセスするための処理装置を有するデータベース処理
装置において、複数のレコードの更新又は参照処理をあ
らかじめ予約登録することにより、該予約されたアクセ
ス処理を指定された予約アクセス時刻に（見掛け上）実
行する。該予約更新処理は、該処理を予約登録するため
の前処理と、予約更新時刻以降の当該レコードへの最初
のアクセス時に行なわれる予約更新後処理とで実行さ
れ、該予約参照処理は、該処理を予約登録するための前
処理と、予約参照時刻以降に実行される後処理と、予約
参照時刻以降かつ後処理以前の間に発生する当該レコー
ドへの更新処理時に実行される予約参照バックアップ処
理とで実行される。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、複数レコードの一括更
新ならびに同時参照を行なうデータベースシステムに関
し、特に複数のレコードへのアクセスを該複数のレコー
ドの共用排他制御を行なわずに実行することが要求され
るオンラインデータベース処理システムにおける予約ア
クセス処理方法に関する。

【０００２】

【従来の技術】情報化社会の発達により、銀行のオンラ
インシステム等の大容量のデータを保持するオンライン
データベースシステムが構築されてきた。オンラインデ
ータベースシステムでは、テーブルのレコードに対する
参照、更新がオンラインで頻繁に行なわれる。

【０００３】特に、銀行口座の統計情報の取得や、利息
計算に基づく口座残高の更新、あるいはデータのバック
アップ等の大量レコードの更新及び参照を行なう大規模
バッチ処理は、データベースのテーブル全体を長時間排
他確保することが必要なため、オンラインシステムを停
止している間に行なう必要があった。ところが、近年の
データベースの大容量化、ならびに、オンラインシステ
ムの稼働時間延長への要求は、上記大規模バッチ処理を
システム停止時間に行なうという方法を不可能にしつつ
ある。

【０００４】これらの問題を解決するために、従来はシ
ステムを２重化して、一方をオンライン用に、他方を大
規模バッチ処理用に用いて、適当なタイミングで整合性
を取る方法や、データのバックアップを定期的に取り、
統計情報の作成等の参照系の大規模バッチ処理はバック
アップデータに対して行なう方法等が用いられてきた。
また、データのバージョンを複数管理することにより、
過去のある時点における一貫性のあるデータに対してア
クセスする機能を提供するデータベースのバージョン管
理方式等が提案されてきた。

【０００５】特に、データベースのバージョン管理方式
等は、種々の方法が提案されている。例えば、特開平６
−２８３１５号では、トランザクション処理と参照アク
セス処理を相互干渉させることなく効率的に並列実行す
るための方法が開示されている。すなわち、この公知例
では、データベースの各頁について有限数の論理バージ
ョンを保持し、これらをタイムスタンプにより管理し、
また現在進行中のトランザクションを管理するテーブル
およびシステム状態を表現する情報を記憶することによ
り、トランザクション進行中のテーブルに対する照会ア
クセスを、該トランザクションを停止することなく、よ
り新しいバージョンのデータベースにアクセスすること
を可能にしている。このようなデータベースのバージョ
ン管理方式は、データの更新を伴うトランザクション処
理と大量データの参照を行う参照系バッチ処理を並列に
実行する際に有効な技術である。

【０００６】

【発明が解決しようとする課題】上述したように、従来
のオンラインシステムでは、大規模バッチ処理を実行す
る際に、システムを停止するか、システムを２重化する
か、あるいは、データのバックアップまたは複数のデー
タのバージョンを取るかの方法を取っていた。

【０００７】しかしながら、オンラインシステムを停止
させその停止中に処理するという方法では、システムの
２４時間連続運転を不可能にするという大きな問題点が
ある。

【０００８】また、システムを２重化して一方をオンラ
インシステム用に、他方を大規模バッチ処理用に適用す
る方法では、それぞれのデータの一貫性を保証すること
が困難であり、オンラインで逐次更新されているデータ
を直接参照したい場合には適用不可能である。また、大
規模バッチ処理用のシステムで実行した更新系の処理結
果は、オンラインシステム用と大規模バッチ処理用のシ
ステム間のデータの整合性を取った後でなければオンラ
インシステム側で読み取ることができないという問題が
ある。

【０００９】さらに、データのバックアップを活用して
大規模バッチ処理を実行する方法では、データのバック
アップ処理自身が大規模参照系バッチ処理であり、バッ
クアップ処理のためのテーブルの排他制御が必要である
という問題点がある。

【００１０】また、データベースのバージョン管理を行
なう方法では、トランザクション処理と参照系のバッチ
処理を並行に処理する場合には有効であるが、トランザ
クション処理と更新系のバッチ処理を並行に処理するこ
とは不可能であり、また参照系のバッチ処理に関して
も、より新しいデータベースにアクセスすることはでき
るものの、ある時刻の正確な統計情報を得ることは不可
能であるという問題点があった。さらに、データベース
の複数のバージョンを常に保持するため、大容量の記憶
装置が必要になるという問題点があった。

【００１１】本発明は、大量レコードの更新や参照を、
当該レコードの排他制御を同時に確保せずに個々のレコ
ード単位の排他制御により実行する方法を提供すること
を目的とする。

【００１２】本発明の他の目的は、大量レコードの更新
を論理的には指定された時刻に同時に行なったようにデ
ータベースのユーザに対して見せる機能を提供すること
にある。

【００１３】さらに本発明の他の目的は、指定された時
刻における大量レコードの参照を必要最小限のデータの
バックアップのみで実現する機能を提供することにあ
る。

【００１４】また本発明の他の目的は、一つのレコード
に対して複数の予約アクセス登録を可能とする機能を提
供することにある。

【００１５】本発明の他の目的は、予約アクセス処理が
失敗した場合に、該予約アクセス処理全体を取り消すこ
とを可能とする機能を提供することにある。

【００１６】

【課題を解決するための手段】本発明に係る予約アクセ
ス処理方法では、複数のレコードの更新をあらかじめ予
約することにより、該予約された更新を指定された予約
更新時刻に論理的に同時に実行するための方法を提供す
る。この予約更新処理は、当該レコードの更新を予約登
録するための予約更新前処理と、予約更新時刻以降の当
該レコードへの最初のアクセス時に行なわれる予約更新
後処理とで実行される。予約更新前処理においては、前
記データベーステーブルの各レコードに１対１に対応し
た予約更新時刻と予約情報とで構成される予約更新情報
に該レコードの予約更新時刻ならびに更新内容を格納す
る。そして、データベースへのレコードのアクセス時に
は、該レコードに対する予約更新登録の有無及び現時刻
と予約更新時刻との比較を行ない、該レコードに対応す
る予約更新登録があり、かつ、現時刻が予約更新時刻以
降であれば予約更新後処理を実行してから当該レコード
に対するアクセス処理を実行し、予約更新登録がない場
合、もしくは、現時刻が予約更新時刻以前であれば予約
された更新は行なわずに該レコードに対するアクセス処
理を実行する。そして、予約更新後処理においては、当
該レコードに登録されている更新を実行して該予約更新
登録を削除する。

【００１７】前記予約更新時刻以降に、前記予約更新後
処理ステップを前記更新予約されたレコードのすべてに
関して実行するクリーンナップ処理を行なうようにして
もよい。また、前記予約更新前処理ステップで予約更新
登録を実行している途中で、現時刻が該予約更新登録の
予約更新時刻を過ぎてしまった場合には、該予約更新処
理の状態を予約更新前処理取消状態に設定し、それまで
に予約更新登録した全てのレコードの予約更新情報を削
除すると共に、前記予約更新後処理ステップを実行する
際には、当該予約更新処理の状態を確認して、該状態が
予約更新前処理取消であった場合には該予約更新登録を
破棄するようにする。予約更新処理の状態は、例えば予
約アクセス状態を管理するテーブルを設けることにより
管理するとよい。

【００１８】さらに、本発明に係る予約アクセス処理方
法では、複数のレコードの参照をあらかじめ予約するこ
とにより、該複数のレコードの共用排他アクセス権の確
保を同時に確保することなく、該予約参照時刻に全ての
レコードの参照を実行するための方法を提供する。予約
参照処理は、当該レコードの参照を予約登録するための
予約参照前処理と、予約参照時刻以降に実行される予約
参照後処理と、予約参照時刻以降かつ予約参照後処理以
前の間に発生する当該参照レコードへの更新処理時に実
行される予約参照バックアップ処理とで実行される。予
約参照前処理においては、前記データベーステーブルの
各レコードに１対１に対応した予約参照時刻と予約情報
とで構成される予約更新情報に該レコードの予約参照時
刻ならびに参照内容を格納する。そして、データベース
へのレコードの更新アクセス時には、該レコードに対す
る予約更新登録の有無及び現時刻と予約更新時刻との比
較を行ない、該レコードに対応する予約参照登録があ
り、かつ、現時刻が予約参照時刻以降であれば予約参照
バックアップ処理を実行して当該レコードのデータのバ
ックアップを作成してから当該レコードに対する更新ア
クセス処理を実行し、予約参照登録がない場合、もしく
は、現時刻が予約参照時刻以前であれば予約参照バック
アップ処理は行なわずに該レコードに対する更新アクセ
ス処理を実行する。また、予約参照時刻以降にタイマ割
り込み等により起動される予約参照後処理においては、
当該レコードのバックアップデータが作成されている場
合にはバックアップデータを参照してから該バックアッ
プデータ及び該予約参照登録を削除し、バックアップデ
ータが存在しない場合には当該レコードの内容を直接参
照してから該予約参照登録を削除する。

【００１９】前記予約参照前処理ステップで予約参照登
録を実行している途中で、現時刻が該予約参照登録の予
約参照時刻を過ぎてしまった場合には、該予約参照処理
の状態を予約参照前処理取消状態に設定し、それまでに
予約参照登録した全てのレコードの予約参照情報を削除
すると共に、前記予約参照バックアップ処理ステップ及
び前記予約参照後処理ステップを実行する際には、当該
予約参照処理の状態を確認して、該状態が予約参照前処
理取消であった場合には該予約参照登録を破棄するよう
にする。予約参照処理の状態は、例えば予約アクセス状
態を管理するテーブルを設けることにより管理するとよ
い。

【００２０】さらに、前記予約更新登録又は前記予約参
照登録において格納する予約更新情報又は予約参照情報
に、次の予約更新情報又は予約参照情報へのポインタを
設け、一つのレコードに対して複数の予約アクセスを登
録するようにしてもよい。

【００２１】

【作用】本発明の予約更新処理における予約更新前処理
ならびに予約更新後処理においては、現在処理中のレコ
ードに関連する排他制御処理のみを行なえばよく、更新
するレコード全体の排他制御を同時に行なう必要はな
い。このため、大量レコードの更新を個々のレコード単
位のロックのみで実現することが可能となった。

【００２２】また、予約更新登録されたレコードの更新
処理は予約更新時刻以降の最初の当該レコードに対する
アクセス処理時に行なわれるため、予約更新時刻には実
際にはデータベースの更新は行わない。このため、全て
のレコードの更新処理を一瞬にして実行したようにユー
ザに対して見せることが可能となった。

【００２３】一方、本発明の予約参照処理における予約
参照前処理、予約参照バックアップ処理ならびに予約参
照後処理においては、現在処理中のレコードに関連する
排他制御処理のみを行なえばよく、参照するレコード全
体の排他制御を同時に行なう必要はない。このため、大
量レコードの更新を個々のレコード単位のロックのみで
実現することが可能となった。

【００２４】また、予約参照されたレコードの参照処理
は予約参照時刻以降にタイマ割り込み等により起動され
た予約参照後処理により実行される。予約参照時刻には
実際にはデータベースの参照処理は行わないので、全て
のレコードの参照処理を一瞬にして実行したようにユー
ザに対して見せることが可能となった。

【００２５】また、予約参照登録されたレコードのバッ
クアップは、指定された予約参照時刻以降でかつ当該レ
コードの予約参照後処理がまだ実行されていない場合に
当該レコードに対して更新処理が行なわれた場合のみ実
行されるため、一貫性のあるデータの参照を実現するた
めに必要なデータのバックアップを最小限にすることが
可能となった。さらに、これらのバックアップデータ
は、予約参照後処理実行時に削除されるため、システム
全体のデータベース容量のオーバヘッドを低減すること
が可能となった。

【００２６】さらに本発明では、一つのレコードに対し
て複数の予約アクセス登録を可能にすることで種々のシ
ステムに対して本機能を提供することが可能となった。

【００２７】また、本発明では、予約アクセス状態を管
理するテーブルを設けることにより、予約アクセス前処
理が予約アクセス時刻までに完了しなかった場合に該予
約アクセス処理を取り消すための機能を提供することが
可能となった。

【００２８】

【実施例】以下、図面を用いて本発明の実施例を説明す
る。

【００２９】図２３は、本発明を実施するデータベース
システムの構成を示す図である。本システムは、データ
ベースをアクセスする複数の端末３００，３０１と、デ
ータベースをアクセスする一つ以上のアプリケーション
サーバ３０３，３０４と、データベースを保持するデー
タベースサーバ３０２とで構成される。データベースサ
ーバ３０２は、データベースシステム３０５およびデー
タベース３０８で構成される。データベースシステム３
０５は、アプリケーションから発行されるＳＱＬ（Stru
ctured Query Language）などの問い合わせ処理の実行
を制御する問い合わせ実行制御部３０６とデータベース
をアクセスするデータベースアクセス部３０７とで構成
される。本図ではデータベースサーバ３０２とアプリケ
ーションサーバ３０３，３０４とが異なるプロセッサ上
に実装されている図を示しているが、アプリケーション
サーバとデータベースサーバは同一プロセッサ上に実装
してもよい。また、データベースシステムは、単一のプ
ロセッサで動作する通常のデータベースシステムだけで
なく、複数のプロセッサ上で動作する並列データベース
システムであってもよい。

【００３０】今、端末３０１でデータベースのテーブル
を一括更新しようとしており、端末３００でテーブルを
参照しようとしているとする。具体的な例で説明する
と、アプリケーションサーバ３０４は給与振込みプログ
ラム、アプリケーションサーバ３０３は残高照会プログ
ラムであり、端末３０１から社員口座に給与振込を行な
おうとしており、端末３００からある人が自分の口座の
残高照会を行なおうとしている、と言った状況である。
本発明では、このような状況のときに、一括更新処理の
時刻を指定することによりデータベースの更新時刻のず
れをなくし、一貫性のあるデータに参照するための手段
を提供する。本発明による新しいデータベースアクセス
方法は、図２３のデータベースシステム内部の問い合わ
せ実行制御部３０６とデータベースアクセス部３０７に
実装される。以下の説明では、各実施例にしたがって、
新しいデータベースアクセス方法を説明する。

【００３１】［実施例１］実施例１では、データベース
の予約更新処理を提供するための方法について説明す
る。

【００３２】図１(a) は、本実施例における予約更新処
理の概要を説明する図である。横軸は時刻の流れを示
し、黒い四角は各時刻において実行される処理を示して
いる。予約更新処理は、レコードの更新を予約登録する
ための予約更新前処理(1) と、予約更新時刻(5)以降に
行なわれる予約更新後処理(2) の２つの処理で実現され
る。

【００３３】予約更新前処理(1) が完了したレコードに
対して、予約更新時刻(5)以前にアクセスする場合には
更新前のデータを提供し(3) 、更新時刻(5)より後で該
レコードにアクセスする場合には予約更新後処理(2) を
行ない予約されていた更新処理を実行してから更新後の
データを提供する(4) 。

【００３４】このように、レコードの更新を更新時刻以
降の最初のアクセスまで遅延させることにより、予約更
新時刻にはレコードの更新処理を実行せずに(5) 、該予
約更新時刻に全てのレコードの更新が同時に実行された
ように論理的に見せることが可能となる。

【００３５】図１(b) は、予約更新処理を実現するため
のテーブル構造を示す図である。口座テーブル(6)及び
支店テーブル(7)はアプリケーションが作成したデータ
ベーステーブル（ＤＢテーブル）であり、予約更新テー
ブル(8)及び予約管理テーブル(9)は予約更新処理を実現
するためにデータベースシステムが作成したテーブルで
ある。

【００３６】アプリケーションが作成したＤＢテーブル
のうち、アプリケーションからは、破線で囲った部分(1
0)のみ直接アクセスすることができる。予約更新時刻(1
1及び15)とアクセスＩＤ(12及び16)は、予約更新処理を
実現するためにデータベースシステムが付加した列であ
る。ＤＢテーブルに付加した列のうち、予約更新時刻(1
1及び15)には、各レコードの予約更新時刻が格納され
る。予約更新時刻(11及び15)に何も格納されていない場
合には、該レコードに対して更新の予約処理が登録され
ていないことを示す。アクセスＩＤ(12及び16)には、予
約更新テーブル(8)にアクセスするための識別子が格納
される。

【００３７】予約更新テーブル(8)は、データベースシ
ステム内に１つ存在し、アクセスＩＤ(13)と、予約情報
(14)とで構成される。アクセスＩＤ(13)は、予約更新テ
ーブル(8)内でユニークな識別子であり、ＤＢテーブル
(6及び7)と予約更新テーブル(8)との対応を取る。予約
情報(14)には、予約された更新処理の予約ＩＤ及び更新
処理内容が記述される。

【００３８】予約管理テーブル(9)は、データベースシ
ステム内に１つ存在し、予約ＩＤ(17)、予約状態(18)、
及び、予約更新時刻(19)とで構成される。予約ＩＤ(17)
は、論理的に同時に実行すべき予約更新処理１つにつき
１つ付与される番号であり、データベースシステム内で
ユニークな番号である。予約状態(18)は、前記同時に実
行すべき予約更新処理の処理状態を示す。処理状態とし
ては、予約更新前処理開始、予約更新前処理取消等があ
る。予約更新前処理開始は、当該予約更新の前処理を行
なっている最中であることを示し、予約更新前処理取消
は、当該予約更新の前処理が予約時刻までに終了しなか
ったため、既に登録している予約更新情報を取消中であ
ることを示す。一方、予約更新時刻(19)は、予約更新を
実行する時刻を格納している。

【００３９】本実施例で示している予約更新は、予約Ｉ
Ｄ(17)がR0050、更新時刻(19)が1992/06/10 9:00であ
り、現在予約更新前処理中であり、予約された更新内容
としては、口座テーブル(6)の口座番号670190048のレコ
ードの残高に200,000を加算し、口座番号670190049のレ
コードの残高に300,000を加算し、というようになって
いる。

【００４０】本実施例で示したテーブル構造ではＤＢテ
ーブル(6及び7)と予約更新テーブル(8)の対応や予約更
新テーブル(8)と予約管理テーブル(9)との対応を取るた
めに識別子を用いているが、ポインタ等を用いてこれら
の対応を取ることももちろん可能である。

【００４１】図２は、本実施例における予約更新前処理
の流れを示す図である。予約更新前処理（２０）では、
まず予約ＩＤを取得して、予約管理テーブル(9)へ該予
約ＩＤならびに予約時刻の登録を行なう（ステップ２
１）。予約ＩＤは、データベースシステム内でユニーク
な識別子である。次に、予約管理テーブル(9)の予約状
態を予約更新前処理開始に設定して（ステップ２２）、
全ての更新レコードについて、以下の処理を実行する。

【００４２】まず、更新すべきレコードの内容を後述の
データベースアクセス処理（ＤＢアクセス処理）により
取得する（ステップ２３）。次に、該レコードの予約更
新時刻フィールド(11又は15)を確認して、既に他の予約
更新が登録されているか否か判定する（ステップ２
４）。既に他の予約更新が登録されていたならば、エラ
ー処理（ステップ２９）に制御を移す。他の予約更新が
登録されていない場合には、登録中の予約更新処理の予
約時刻を既に過ぎていないかをチェックし（ステップ２
５）、もし予約時刻を過ぎていた場合には、当該予約更
新前処理が予定時刻に間に合わなかったとしてエラー処
理（ステップ２９）に制御を移す。

【００４３】ステップ２５で予約時刻を過ぎていない場
合には、予約情報を予約更新テーブル(8)に登録して
（ステップ２６）、次の更新レコードの処理に移る（ス
テップ２７）。全ての更新レコードの予約情報の登録が
完了したならば（ステップ２７）、予約管理テーブル
(9)から該予約更新に対応するエントリを削除して（ス
テップ２８）、処理を終了する。

【００４４】一方、各レコードの予約情報の登録中にエ
ラーが発生した場合には、まず予約管理テーブル(9)の
状態を予約更新前処理取消に設定して、該予約更新前処
理で登録した全ての予約情報をテーブルから削除し、最
後に予約管理テーブル(9)の状態を予約更新前処理失敗
に設定してエラーリターンする（ステップ２９）。

【００４５】図３は、本実施例におけるデータベースア
クセス処理（ＤＢアクセス処理）の流れを示す図であ
る。ＤＢアクセス処理は、レコードの参照処理及びレコ
ードの更新処理の両方を包含する。

【００４６】ＤＢアクセス処理（３０）では、まずアク
セス対象のレコードをＤＢテーブル(6又は7)から取得し
（ステップ３１）、そのレコードの予約更新時刻(11又
は15)が登録されており、かつ、現時刻が該予約更新時
刻を過ぎているか否かを判定する（ステップ３２）。予
約更新時刻を過ぎていたならば、該レコードのアクセス
ＩＤをキーにして予約更新テーブル(8)から予約情報(1
4)を取得し（ステップ３３）、該予約情報(14)に基づき
後述の予約更新後処理を行ない（ステップ３４）、その
後、該レコードのＤＢアクセス処理を実行する（ステッ
プ３５）。

【００４７】ステップ３２でアクセス対象のレコードの
予約更新時刻が登録されていない場合や、該レコードの
予約更新時刻がまだ過ぎていない場合には、予約更新後
処理は行なわずに現在のレコードに対してＤＢアクセス
処理（ステップ３５）を行なう。

【００４８】図４は、本実施例における予約更新後処理
の流れを示す図である。予約更新後処理（４０）では、
まず、予約管理テーブル(9)を予約ＩＤで検索して（ス
テップ４１）、予約管理テーブル(9)の状態(18)を確認
する（ステップ４２）。予約管理テーブル(9)の状態(1
8)が予約更新前処理取消以外であれば、予約情報(14)に
従って当該レコードの更新処理を行ない（ステップ４
３）、その後、予約更新テーブル(8)から該予約情報(1
4)を削除する（ステップ４４）。予約管理テーブル(9)
の状態(18)が予約更新前処理取消である場合には（ステ
ップ４２）、当該レコードの更新は行なわずに予約更新
テーブル(8)から予約情報(14)を削除して（ステップ４
４）、予約更新後処理を終了する。

【００４９】本実施例では、予約更新されたレコード
は、予約更新時刻以降に該レコードに対してＤＢアクセ
スが起こらないかぎり更新されることはない。しかしな
がら、通常のデータベースシステムにおいては、定期的
にバックアップ作業を行なっているため、該バックアッ
プ作業の際にＤＢアクセスが発生し、当該レコードの予
約更新後処理が実行される。バックアップを取らないシ
ステムにおいては、予約更新処理を終了させるために一
定期間毎に全データベースをアクセスするクリーンナッ
プ処理を実行することにより、予約更新後処理を実行さ
せることができる。

【００５０】本実施例では、ＤＢテーブルに予約更新時
刻フィールドを設け、ＤＢアクセス処理時に予約更新時
刻と現時刻の関係により予約更新を行なうか行なわない
かを決定する処理を設けたことに特徴がある。これによ
り、予約更新時刻にＤＢをアクセスすることなく、アプ
リケーションからは、該予約更新時刻にあたかも全レコ
ードが同時に更新されたように論理的に見える機能を提
供することが可能となった。

【００５１】また、全ての処理はテーブルのレコード単
位の排他制御を用いて実現できるため、システム稼働中
にも大量のレコードの一括更新を行なうことが可能であ
る。また、予約更新前処理が完了しないうちに予約時刻
を過ぎてしまった場合の予約更新情報の取り消し手段を
有することも本実施例の特徴の一つである。

【００５２】本実施例は、リレーショナル型のデータベ
ースシステムのみならず、構造型あるいは階層型のデー
タベースシステム等の、レコードを単位としてアクセス
するあらゆるデータベースに適用できることは明らかで
ある。

【００５３】［実施例２］次に、本発明の第２の実施例
を説明する。この実施例２では、データベースの予約参
照処理を提供するための方法について説明する。

【００５４】図５(a)は、本実施例における予約参照処
理の概要を説明する図である。横軸は時刻の流れを示
し、黒い四角は各時刻において実行される処理を示して
いる。予約参照処理は、レコードの参照を予約登録する
ための予約参照前処理(51)と、参照時刻(56)以降に行な
われる予約参照後処理(52)、および、参照時刻(56)以降
かつ予約参照後処理(52)以前の間に発生するＤＢ更新処
理時に行なわれる予約参照バックアップ処理(53)の３つ
の処理で実現される。

【００５５】予約参照前処理(51)が完了したレコードに
対して、予約参照時刻(56)以前に該レコードを更新する
場合には通常通り更新処理を行ない(54)、参照時刻(56)
より後かつ予約参照後処理(52)以前に該レコードの更新
処理を行なう場合には予約参照バックアップ処理(53)を
行ない予約参照されていたレコードのバックアップを作
成してから当該レコードの更新処理を行なう(55)。

【００５６】予約参照後処理(52)では、参照レコードの
バックアップが作成されている場合には該バックアップ
データを参照し、バックアップがない場合には該レコー
ドのデータを参照する。予約参照後処理(52)は、予約参
照時刻(56)以降の適当なタイミングで実行する。予約参
照後処理(52)を起動するタイミングは、参照時刻(56)以
降にタイマにより起動をかける方法や、参照時刻(56)以
降の最初のＤＢアクセス発生時点等、様々な方法により
実現することができる。

【００５７】本実施例では、予約参照後処理以前に更新
が行なわれるレコードのみバックアップを作成すること
により、予約参照時刻にはレコードの参照処理を実行せ
ずに(56)、該予約参照時刻に全てのレコードの参照が同
時に実行されたように論理的に見せることが可能とな
る。

【００５８】図５(b)は、予約参照処理を実現するため
のテーブル構造を示す図である。口座テーブル(500)及
び支店テーブル(501)は、アプリケーションが作成した
データベーステーブル（ＤＢテーブル）であり、予約参
照テーブル(502)、バックアップテーブル(503)及び予約
管理テーブル(504)は予約参照処理を実現するためにデ
ータベースシステムが作成したテーブルである。

【００５９】アプリケーションが作成した ＤＢテーブ
ルのうち、アプリケーションからは、破線で囲った部分
(505)のみ直接アクセスすることができる。予約参照時
刻(506及び508)とアクセスＩＤ(507及び509)は、予約参
照処理を実現するためにデータベースシステムが付加し
た列である。ＤＢテーブルに付加した列のうち、予約参
照時刻(506及び508)には、各レコードの予約参照時刻が
格納される。予約参照時刻(506及び508)に何も格納され
ていない場合には、該レコードに対して参照の予約処理
が登録されていないことを示す。アクセスＩＤ(507及び
509)には、予約参照テーブル(502)にアクセスするため
の識別子が格納される。

【００６０】予約参照テーブル(502)は、データベース
システム内に１つ存在し、アクセスＩＤ(510)と、予約
情報(511)とで構成される。アクセスＩＤ(510)は、予約
参照テーブル(502)内でユニークな識別子であり、ＤＢ
テーブル(500及び501)と予約参照テーブル(502)の対応
を取る。予約情報(511)には、予約された参照処理の予
約識別子及びバックアップ識別子が記述される。バック
アップ識別子（ＩＤ）は、バックアップが存在する場合
のバックアップＩＤを示し、予約参照テーブル(502)の
エントリとバックアップテーブル(503)のエントリの対
応を取る。予約情報(511)中のバックアップＩＤがNULL
値（初期値）のときは、未だ当該レコードのバックアッ
プを取っていないことを示す。

【００６１】バックアップテーブル(503)は、データベ
ースシステム内に一つ存在し、バックアップＩＤ(512)
とバックアップデータ(513)とで構成される。バックア
ップＩＤ(512)は、バックアップテーブル(503)内でユニ
ークな識別子である。バックアップデータ(513)には、
予約参照時刻以降に更新されるレコードのバックアップ
（更新する前のレコードのバックアップ）を格納する。
本実施例ではバックアップはレコード単位で格納してい
るが、参照されるフィールドのみのバックアップを取る
ことももちろん可能である。

【００６２】予約管理テーブル(504)は、データベース
システム内に１つ存在し、予約ＩＤ(514)、予約状態(51
5)、予約参照時刻(516)、及び、予約実行文(517)とで構
成される。予約ＩＤ(514)は、論理的に同時に実行すべ
き予約参照処理１つにつき１つ付与される番号であり、
データベースシステム内でユニークな番号である。予約
状態(515)は、前記同時に実行すべき予約参照処理の処
理状態を示す。処理状態としては、予約参照前処理開
始、予約参照前処理完了、予約参照前処理取消等があ
る。予約参照前処理開始は、当該予約参照の前処理を行
なっている最中であることを示し、予約参照前処理完了
は、当該予約参照の前処理が正常終了したことを示し、
予約参照前処理取消は、当該予約参照の前処理が予約時
刻までに終了しなかったため、既に登録している予約参
照情報を取消中であることを示す。一方、予約参照時刻
(516)には、予約参照を実行する時刻が格納され、予約
実行文には予約された参照実行文（問い合わせ実行文又
は問い合わせ実行コード）が格納される。

【００６３】本実施例で示している予約参照は、予約Ｉ
Ｄ(514)がR0119、参照時刻(516)が1992/06/10 7:00であ
り、現在予約参照前処理完了しており、口座テーブル(5
00)の口座番号670191000のレコード、670191001のレコ
ード、及び、支店テーブル(501)の支店番号670191のレ
コードがそれぞれ予約参照登録されている。また、口座
テーブル(500)の口座番号670191000及び支店テーブル(5
01)の支店番号670191のレコードは予約参照時刻以降に
更新処理が行なわれたため、バックアップテーブル(50
3)に予約参照時刻の時点におけるレコードの内容が保存
されている。

【００６４】本実施例で示したテーブル構造ではＤＢテ
ーブルと予約参照テーブルの対応や予約参照テーブルと
予約管理テーブル、あるいは、予約参照テーブルとバッ
クアップテーブルの対応を取るためにそれぞれ識別子を
用いているが、ポインタ等を用いてこれらの対応を取る
ことももちろん可能である。

【００６５】図６は、本実施例における予約参照前処理
の流れを示す図である。予約参照前処理（６０）では、
まず予約ＩＤを取得して、予約管理テーブル(504)へ該
予約ＩＤ、予約時刻および予約実行文の登録を行なう
（ステップ６１）。次に、予約管理テーブル(504)の予
約状態を予約参照前処理開始に設定して（ステップ６
２）、全ての参照レコードについて、以下の処理を実行
する。

【００６６】まず、参照すべきレコードの内容を取得す
る（ステップ６３）。次に、該レコードの予約参照時刻
フィールド(506又は508)を確認して、既に他の予約参照
が登録されているか否か判定する（ステップ６４）。既
に他の予約参照が登録されていたならば、エラー処理
（ステップ６９）に制御を移す。他の予約参照が登録さ
れていない場合には、登録中の予約参照処理の予約時刻
を既に過ぎていないかをチェックし（ステップ６５）、
もし予約時刻を過ぎていた場合には、当該予約参照前処
理が予定時刻に間に合わなかったとしてエラー処理（ス
テップ６９）に制御を移す。

【００６７】ステップ６５で予約時刻を過ぎていない場
合には、予約情報を予約参照テーブル(502)に登録して
（ステップ６６）、次の参照レコードの処理に移る（ス
テップ６７）。なお、予約情報(511)のバックアップＩ
Ｄは、NULL値（バックアップデータなし）に初期設定す
る。

【００６８】全ての参照レコードの予約情報の登録が完
了したならば（ステップ６７）、予約管理テーブル(50
4)の予約状態(515)を予約参照前処理完了に設定して
（ステップ６８）、処理を終了する。

【００６９】一方、各レコードの予約情報の登録中にエ
ラーが発生した場合には、まず予約管理テーブル(504)
の状態を予約参照前処理取消に設定して、該予約参照前
処理で登録した全ての予約情報をテーブルから削除し、
最後に予約管理テーブル(504)の状態を予約参照前処理
失敗に設定してエラーリターンする（ステップ６９）。

【００７０】図７は、本実施例における一行更新処理の
流れを示す図である。一行更新処理は、一つのレコード
の内容を更新する処理であり、データベースの更新処理
の中から呼び出される。

【００７１】一行更新処理（７０）では、まず、更新す
るレコードを取得して（ステップ７１）、該レコードの
予約参照時刻(506又は508)をチェックする（ステップ７
２）。該レコードの予約参照時刻が登録されており、か
つ、現時刻が該予約参照時刻を過ぎていたならば、該レ
コードのアクセスＩＤ(507又は509)をキーにして予約参
照テーブル(502)から予約情報(511)を取得し（ステップ
７３）、後述の予約参照バックアップ処理を行なう（ス
テップ７４）。その後、該レコードの更新処理を実行し
て（ステップ７５）、処理を終了する。

【００７２】ステップ７２でアクセス対象のレコードの
予約更新時刻が登録されていない場合や、該レコードの
予約更新時刻がまだ過ぎていない場合には、予約参照バ
ックアップ処理は行なわずに現在のレコードの更新処理
を行なって（ステップ７５）、処理を終了する。

【００７３】図８は、本実施例における予約参照バック
アップ処理の流れを示す図である。予約参照バックアッ
プ処理（８０）では、まず、予約管理テーブル(504)を
予約ＩＤで検索して（ステップ８５）、予約管理テーブ
ル(504)の状態(515)を確認する（ステップ８６）。予約
管理テーブル(504)の状態(515)が予約参照前処理取消で
あれば、エラーリターンする。

【００７４】ステップ８６で予約管理テーブル(504)の
状態(515)が予約参照前処理取消以外であれば、当該レ
コードに対応する予約情報(511)からバックアップＩＤ
を取得し、当該レコードのバックアップが存在するかど
うかをチェックする（ステップ８１）。当該レコードの
バックアップが既に存在する場合には、バックアップを
作成する必要がないため、予約参照バックアップ処理を
終了する。

【００７５】ステップ８１で当該レコードのバックアッ
プが存在しない場合には、バックアップＩＤを新規に取
得し（ステップ８２）、該レコードの内容をバックアッ
プテーブル(503)に登録し（ステップ８３）、予約情報
(511)に取得したバックアップＩＤを書き込み（ステッ
プ８４）、予約参照バックアップ処理を終了する。

【００７６】図９は、本実施例における予約参照後処理
の流れを示す図である。予約参照後処理（９０）では、
まず、予約管理テーブル(504)を予約ＩＤで検索し、予
約状態(515)及び予約実行文(517)を取得する（ステップ
９１）。次に、予約管理テーブル(504)の状態(515)をチ
ェックする（ステップ９２）。その状態が予約参照前処
理取消であれば、予約参照エラーとしてリターンする。
それ以外の場合には、各参照レコードについて以下の処
理を実行する。

【００７７】まず、参照レコードを通常処理通りに取得
する（ステップ９３）。次に、予約参照テーブル(502)
から該レコードに対応する予約情報(511)を取得し（ス
テップ９４）、該レコードのバックアップが存在するか
どうかをチェックする（ステップ９５）。

【００７８】バックアップデータが存在する場合には、
バックアップテーブル(503)から当該レコードのバック
アップデータ(513)を取得して（ステップ９６）、ステ
ップ９７に進む。バックアップデータが存在しない場合
には、ステップ９６をスキップしてステップ９７に進
む。

【００７９】そして、予約実行文に従って予約していた
参照処理を実行し（ステップ９７）、その後、予約参照
テーブル(502)から該予約情報(511)を削除する（ステッ
プ９８）。このとき、該レコードのバックアップデータ
(513)がある場合にはそのバックアップデータも削除す
る。そして、全てのレコードの参照が終了してから、予
約管理テーブル(504)から該予約参照に対応するエント
リを削除して（ステップ９９）、予約参照後処理を終了
する。

【００８０】本実施例では、予約参照されたレコードに
ついては、予約参照時刻以降に該レコードに対して更新
処理が起こらないかぎり該レコードのバックアップは作
成しない。また、予約参照後処理が終了すると該予約参
照処理のために生成したバックアップは全て消去される
ため、データベースの領域を長時間取り続けることがな
い。したがって、最小限のバックアップにより論理的に
一貫性のある大規模データの参照を行なうことが可能で
ある。

【００８１】また、全ての処理はテーブルのレコード単
位の排他制御を用いて実現できるため、システム稼働中
にも大量のレコードの同時参照を行なうことが可能であ
る。また、予約参照前処理が完了しないうちに予約時刻
を過ぎてしまった場合の予約参照情報の取り消し手段を
有することも本実施例の特徴の一つである。

【００８２】本実施例は、リレーショナル型のデータベ
ースシステムのみならず、構造型あるいは階層型のデー
タベースシステム等の、レコードを単位としてアクセス
するあらゆるデータベースに適用できることは明らかで
ある。

【００８３】［実施例３］次に、本発明の第３の実施例
を説明する。本実施例３では、データベースの予約更新
ならびに予約参照を同時に提供するための方法について
説明する。

【００８４】図１０は、本実施例における予約更新なら
びに予約参照の処理の概要を説明する図である。横軸は
時刻の流れを示し、黒い四角は各時刻において実行され
る処理を示している。予約更新処理は、実施例１と同様
に、予約更新前処理(101)と、予約更新後処理(102)の２
つの処理で実現される。一方、予約参照処理は、実施例
２と同様に、予約参照前処理(103)と、予約参照バック
アップ処理(104)と、予約参照後処理(105)の３つの処理
で実現される。

【００８５】予約更新処理に関しては、予約更新前処理
(101)が完了したレコードに対して予約更新時刻以前に
アクセスした場合には更新前のデータを提供し(106)、
更新時刻より後で該レコードにアクセスした場合には予
約更新後処理(102)を行ない予約されていた更新処理を
実行してから更新後のデータを提供する(107)。

【００８６】一方、予約参照処理に関しては、予約参照
前処理(103)が完了したレコードに対して、予約参照時
刻以前に該レコードを更新した場合には通常通り更新処
理を行ない(108)、参照時刻より後かつ予約参照後処理
(105)以前に該レコードを更新した場合には予約参照バ
ックアップ処理(104)を行ない予約参照されていたレコ
ードのバックアップを作成してから該レコードの更新処
理を行なう(109)。

【００８７】予約参照後処理(105)では、参照レコード
のバックアップが作成されている場合には該バックアッ
プデータを参照し、バックアップがない場合には該レコ
ードのデータを参照する。予約参照後処理(105)は、予
約参照時刻以降の適当なタイミングで実行する。予約参
照後処理(105)を起動するタイミングは、参照時刻以降
にタイマにより起動をかける方法や、参照時刻以降の最
初のＤＢアクセス発生時点等、様々な方法により実現す
ることができる。

【００８８】図１１は、予約更新及び予約参照処理を実
現するためのテーブル構造を示す図である。口座テーブ
ル(110)及び支店テーブル(111)はアプリケーションが作
成したデータベーステーブル（ＤＢテーブル）であり、
予約アクセステーブル(112)、バックアップテーブル(11
3)及び予約管理テーブル(114)は予約更新及び予約参照
処理を実現するためにデータベースシステムが作成した
テーブルである。

【００８９】アプリケーションが作成した ＤＢテーブ
ルのうち、アプリケーションからは、破線で囲った部分
(115)のみ直接アクセスすることができる。予約アクセ
ス時刻(1101及び1103)とアクセスＩＤ(1102及び1104)
は、予約更新及び予約参照処理を実現するためにデータ
ベースシステムが付加した列である。ＤＢテーブルに付
加した列のうち、予約アクセス時刻(1101及び1103)に
は、各レコードの予約アクセス時刻が格納される。予約
アクセス時刻(1101及び1103)に何も格納されていない場
合には、該レコードに対して更新又は参照の予約処理が
行なわれていないことを示す。アクセスＩＤ(1102及び1
104)には、予約アクセステーブルにアクセスするための
識別子が格納される。

【００９０】予約アクセステーブル(112)は、データベ
ースシステム内に１つ存在し、アクセスＩＤ(1105)と、
予約情報(1106)とで構成される。アクセスＩＤ(1105)
は、予約アクセステーブル内でユニークな識別子であ
り、ＤＢテーブル(110及び111)と予約アクセステーブル
(112)の対応を取る。予約情報(1106)には、予約された
処理の種別（更新又は参照）と該処理の予約識別子（Ｉ
Ｄ）が格納される。さらに、付加情報として、更新処理
の場合には更新処理内容が格納され、参照処理の場合に
はバックアップ識別子が記述される。バックアップ識別
子は、バックアップが存在する場合のバックアップＩＤ
を示し、予約アクセステーブル(112)のエントリとバッ
クアップテーブル(113)のエントリの対応を取る。

【００９１】バックアップテーブル(113)は、データベ
ースシステム内に一つ存在し、バックアップＩＤ(1107)
とバックアップデータ(1108)とで構成される。バックア
ップＩＤ(1107)は、バックアップテーブル(113)内でユ
ニークな識別子である。バックアップデータ(1108)に
は、予約アクセス時刻以降に更新されたレコードのバッ
クアップ（更新前の状態のバックアップ）を格納する。
本実施例ではバックアップはレコード単位で格納してい
るが、参照されるフィールドのみのバックアップを取る
ことももちろん可能である。

【００９２】予約管理テーブル(114)は、データベース
システム内に１つ存在し、予約ＩＤ(1109)、予約状態(1
110)、予約アクセス時刻(1111)、及び、予約実行文(111
2)とで構成される。

【００９３】予約ＩＤ(1109)は、論理的に同時に実行す
べき予約アクセス処理１つにつき１つ付与される番号で
あり、データベースシステム内でユニークな番号であ
る。予約状態(1110)は、前記同時に実行すべき予約参照
処理の処理状態を示す。処理状態としては、予約更新前
処理開始、予約更新前処理取消、予約参照前処理開始、
予約参照前処理完了、予約参照前処理取消等がある。予
約更新前処理開始及び予約参照前処理開始は、当該予約
アクセスの前処理を行なっている最中であることを示
し、予約参照前処理完了は、当該予約参照の前処理が正
常終了したことを示し、予約更新前処理取消及び予約参
照前処理取消は、当該予約アクセスの前処理が予約時刻
までに終了しなかったため、既に登録している予約情報
を取消中であることを示す。

【００９４】一方、予約アクセス時刻(1111)には、予約
アクセスを実行する時刻が格納され、予約実行文(1112)
には、予約された参照実行文（問い合わせ実行文又は問
い合わせ実行コード）が格納される。

【００９５】本実施例では、予約ＩＤがR0050の予約更
新処理、予約ＩＤがR0119の予約参照処理、及び予約Ｉ
ＤがR0120の予約参照処理がそれぞれ登録されている。
予約ＩＤがR0050の予約更新処理は、更新時刻が1992/06
/10 9:00であり、現在、予約更新前処理が完了してお
り、口座テーブルの口座番号670190048のレコードの残
高に200,000を加算し、口座番号670190049のレコードの
残高に300,000を加算する、という内容である。予約Ｉ
ＤがR0119の予約参照処理は、参照時刻が1992/06/10 7:
00であり、現在予約参照前処理完了しており、口座テー
ブルの口座番号670191000のレコード、670191001のレコ
ード、及び、支店テーブルの支店番号670191のレコード
がそれぞれ予約参照登録されており、口座テーブルの口
座番号670191000及び支店テーブルの支店番号670191の
レコードは予約アクセス時刻以降に更新処理が行なわれ
たため、バックアップテーブルに予約アクセス時刻の時
点におけるレコードの内容が保存されている。

【００９６】本実施例で示したテーブル構造ではＤＢテ
ーブルと予約アクセステーブルの対応や予約アクセステ
ーブルと予約管理テーブル、あるいは、予約アクセステ
ーブルとバックアップテーブルの対応を取るためにそれ
ぞれ識別子を用いているが、ポインタ等を用いてこれら
の対応を取ることももちろん可能である。

【００９７】図１２は、本実施例における予約更新前処
理の流れを示す図である。予約更新前処理（１２０）で
は、まず予約ＩＤを取得して、予約管理テーブル(114)
へ該予約ＩＤならびに予約時刻の登録を行なう（ステッ
プ１２１）。予約ＩＤは、データベースシステム内でユ
ニークな識別子である。次に、予約管理テーブル(114)
の予約状態(1110)を予約更新前処理開始に設定して（ス
テップ１２２）、全ての更新レコードについて、以下の
処理を実行する。

【００９８】まず、更新すべきレコードの内容を後述の
１行参照処理により取得する（ステップ１２３）。次
に、該レコードの予約アクセス時刻フィールド(1101又
は1103)を確認して、既に他の予約アクセスが登録され
ているか否かを判定する（ステップ１２４）。既に他の
予約アクセスが登録されていたならば、エラー処理（ス
テップ１２９）に制御を移す。他の予約アクセスが登録
されていない場合には、登録中の予約更新処理の予約時
刻を既に過ぎていないかをチェックし（ステップ１２
５）、もし予約時刻を過ぎていた場合には、当該予約更
新前処理が予定時刻に間に合わなかったとしてエラー処
理（ステップ１２９）に制御を移す。

【００９９】ステップ１２５で予約時刻を過ぎていない
場合には、予約情報を予約アクセステーブル(112)に登
録して（ステップ１２６）、次の更新レコードの処理に
移る（ステップ１２７）。なお、予約情報(1106)の処理
の種別は更新処理に設定し、更新処理内容には更新する
列名及び更新情報を設定する。

【０１００】全ての更新レコードの予約情報の登録が完
了したならば（ステップ１２７）、予約管理テーブル(1
14)から該予約更新に対応するエントリを削除して（ス
テップ１２８）、処理を終了する。

【０１０１】一方、各レコードの予約情報の登録中にエ
ラーが発生した場合には、まず予約管理テーブル(114)
の状態(1110)を予約更新前処理取消に設定して、該予約
更新前処理で登録した全ての予約情報をテーブルから削
除し、最後に予約管理テーブル(114)の状態(1110)を予
約更新前処理失敗に設定してエラーリターンする（ステ
ップ１２９）。

【０１０２】図１３は、本実施例における予約参照前処
理の流れを示す図である。予約参照前処理（１３０）で
は、まず予約ＩＤを取得して、予約管理テーブル(114)
へ該予約ＩＤ、予約時刻ならびに予約実行文の登録を行
なう（ステップ１３１）。次に、予約管理テーブル(11
4)の予約状態(1110)を予約参照前処理開始に設定して
（ステップ１３２）、全ての参照レコードについて、以
下の処理を実行する。

【０１０３】まず、参照すべきレコードを後述の１行参
照処理により取得する（ステップ１３３）。次に、該レ
コードの予約アクセス時刻フィールド(1101又は1103)を
確認して、既に他の予約アクセスが登録されているか否
かを判定する（ステップ１３４）。既に他の予約アクセ
スが登録されていたならば、エラー処理（ステップ１３
９）に制御を移す。他の予約アクセスが登録されていな
い場合には、登録中の予約参照処理の予約時刻を既に過
ぎていないかをチェックし（ステップ１３５）、もし予
約時刻を過ぎていた場合には、当該予約参照前処理が予
定時刻に間に合わなかったとしてエラー処理（ステップ
１３９）に制御を移す。

【０１０４】ステップ１３５で予約時刻を過ぎていない
場合には、予約情報を予約アクセステーブル(112)に登
録して（ステップ１３６）、次の参照レコードの処理に
移る（ステップ１３７）。なお、予約情報(1106)の処理
の種別は参照に設定し、バックアップＩＤはNULL値（バ
ックアップデータなし）に初期設定する。

【０１０５】全ての参照レコードの予約情報の登録が完
了したならば（ステップ１３７）、予約管理テーブル(1
14)の予約状態(1110)を予約参照前処理完了に設定して
（ステップ１３８）、処理を終了する。

【０１０６】一方、各レコードの予約情報の登録中にエ
ラーが発生した場合には、まず予約管理テーブル(114)
の状態(1110)を予約参照前処理取消に設定して、該予約
参照前処理で登録した全ての予約情報をテーブルから削
除し、最後に予約管理テーブル(114)の状態(1110)を予
約参照前処理失敗に設定してエラーリターンする（ステ
ップ１３９）。

【０１０７】図１４は、本実施例における一行更新処理
の流れを示す図である。一行更新処理は、一つのレコー
ドの内容を更新する処理であり、データベースの更新処
理の中から呼び出される。

【０１０８】一行更新処理（１４０）では、まず、更新
するレコードを取得して（ステップ１４１）、該レコー
ドの予約アクセス時刻(1101又は1103)をチェックする
（ステップ１４２）。該レコードの予約アクセス時刻が
登録されていたなら、現時刻が該予約アクセス時刻を過
ぎているか否か判定する（ステップ１４３）。該レコー
ドの予約アクセス時刻が登録されており、かつ現時刻が
該予約アクセス時刻を過ぎていたならば、該レコードの
アクセスＩＤ(1102又は1104)をキーにして予約アクセス
テーブル(112)から予約情報(1106)を取得し（ステップ
１４４）、予約情報(1106)のアクセス種別をチェックす
る（ステップ１４５）。

【０１０９】予約情報(1106)のアクセス種別が更新の場
合には、後述の予約更新後処理を行ない（ステップ１４
６）、アクセス種別が参照の場合には、予約参照バック
アップ処理を行なう（ステップ１４７）。そして、最後
に、該レコードの更新処理を実行する（ステップ１４
８）。予約参照バックアップ処理は、実施例２で説明し
た処理と全く同様である。

【０１１０】ステップ１４２，１４３で、アクセス対象
のレコードの予約アクセス時刻が登録されていない場合
や、該レコードの予約アクセス時刻がまだ過ぎていない
場合には、通常通りレコードの更新処理（ステップ１４
８）を行なう。

【０１１１】図１５は、本実施例における一行参照処理
の流れを示す図である。一行参照処理は、一つのレコー
ドの内容を参照する処理であり、データベースの参照処
理の中から呼び出される。

【０１１２】一行参照処理（１５０）では、まず、参照
するレコードを取得して（ステップ１５１）、該レコー
ドの予約アクセス時刻(1101又は1103)をチェックする
（ステップ１５２）。該レコードの予約アクセス時刻が
登録されていたなら、現時刻が該予約アクセス時刻を過
ぎているか否か判定する（ステップ１５３）。該レコー
ドの予約アクセス時刻が登録されており、かつ現時刻が
該予約アクセス時刻を過ぎていたならば、該レコードの
アクセスＩＤ(1102又は1104)をキーにして予約アクセス
テーブル(112)から予約情報(1106)を取得し（ステップ
１５４）、予約情報(1106)のアクセス種別をチェックす
る（ステップ１５５）。

【０１１３】予約情報(1106)のアクセス種別が更新の場
合には、後述の予約更新後処理を行ない（ステップ１５
６）、更新後のデータを参照データとして呼び出し元に
リターンする。ステップ１５５でアクセス種別が参照の
場合には、該レコードのデータをそのまま参照データと
して呼び出し元にリターンする。

【０１１４】ステップ１５２，１５３でアクセス対象の
レコードの予約アクセス時刻が登録されていない場合
や、該レコードの予約アクセス時刻がまだ過ぎていない
場合にも、該レコードのデータをそのまま参照データと
して呼び出し元にリターンする。

【０１１５】図１６は、本実施例における予約更新後処
理の流れを示す図である。予約更新後処理（１６０）で
は、まず、予約管理テーブル(114)を予約ＩＤで検索し
て（ステップ１６１）、予約管理テーブル(114)の状態
(1110)を確認する（ステップ１６２）。次に、予約管理
テーブル(114)の状態(1110)が予約更新前処理取消以外
であれば、予約情報(1106)に従って当該レコードの更新
処理を行ない（ステップ１６３）、その後、予約アクセ
ステーブル(112)から該予約情報(1106)を削除する（ス
テップ１６４）。ステップ１６２で予約管理テーブル(1
14)の状態(1110)が予約更新前処理取消の場合には、当
該レコードの更新は行なわずに予約アクセステーブル(1
12)から予約情報(1106)を削除して（ステップ１６
４）、予約更新後処理を終了する。

【０１１６】図１７は、本実施例における予約参照後処
理の流れを示す図である。予約参照後処理（１７０）で
は、まず、予約管理テーブル(114)を予約ＩＤで検索
し、予約状態(1110)及び予約実行文(1112)を取得する
（ステップ１７１）。次に、予約管理テーブル(114)の
状態(1110)が予約参照前処理取消であれば、予約参照エ
ラーとしてリターンする。それ以外の場合には、各参照
レコードについて以下の処理を実行する。

【０１１７】まず、参照レコードを通常処理通りに取得
する（ステップ１７３）。次に、予約アクセステーブル
(112)から該レコードに対応する予約情報(1106)を取得
し（ステップ１７４）、該レコードのバックアップが存
在するかどうかをチェックする（ステップ１７５）。バ
ックアップデータが存在する場合には、バックアップテ
ーブル(113)から当該レコードのバックアップデータ(11
08)を取得して（ステップ１７６）、ステップ１７７に
進む。バックアップデータ(1108)が存在しない場合に
は、そのままステップ１７７に進む。

【０１１８】そして、予約実行文に従って予約していた
参照処理を実行し（ステップ１７７）、その後、予約ア
クセステーブル(112)から該予約情報(1106)を削除する
（ステップ１７８）。このとき、該レコードのバックア
ップデータ(1108)がある場合には、そのバックアップデ
ータも削除する。そして、全てのレコードの参照が終了
してから、予約管理テーブル(114)から該予約参照に対
応するエントリを削除して（ステップ１７９）、予約参
照後処理を終了する。

【０１１９】本実施例は、実施例１で述べた予約更新処
理と実施例２で述べた予約参照処理を同時に実現すると
ころに特徴がある。本実施例では、これらの処理を同時
に実現するために予約情報としてアクセス種別を追加
し、１行更新処理及び１行参照処理において該アクセス
種別を判定して、予約更新後処理を行なうか、バックア
ップ処理を行なうかを決定しているところに特徴があ
る。

【０１２０】本実施例では、予約更新及び予約参照の処
理をデータベースシステムの機能として実現することに
より、大量レコードの更新処理および大量レコードの参
照を一瞬で行なうようにアプリケーションプログラムに
見せることが可能となる。このため、従来、データベー
スシステムを一時停止させて行なわなければならなかっ
た、データのバックアップ処理やデータベースの統計処
理、給与振込みのオンラインバッチ処理等の、種々の大
規模データベース処理を、システム稼働中に行なうこと
が可能となる。これにより、銀行オンラインの２４時間
連続運転等のデータベースシステムの無停止運転機能が
容易に実現可能となる。

【０１２１】なお、本実施例は、リレーショナル型のデ
ータベースシステムのみならず、構造型あるいは階層型
のデータベースシステム等の、レコードを単位としてア
クセスするあらゆるデータベースに適用できることは明
らかである。

【０１２２】［実施例４］上記実施例１から実施例３ま
での予約アクセス処理では、一つのレコードには１つの
予約アクセス処理しか登録できず、既に予約アクセスが
登録されているレコードに対して新たな予約アクセスを
登録するとエラーリターンする仕様となっていた。

【０１２３】そこで、実施例４では一つのレコードに対
して複数の予約アクセスを登録可能にする複数予約アク
セス登録機能を実現する方法について説明する。本実施
例では、実施例３で示した予約更新ならびに予約参照を
同時に実現する方法に複数予約アクセス登録機能を追加
した例を示すが、実施例１及び実施例２に複数予約アク
セス登録機能を追加することも、同様の方式で容易に実
現することが可能である。

【０１２４】図１８は、複数予約アクセス登録機能を実
現するためのテーブル構造を示す図である。口座テーブ
ル(181)及び支店テーブル(182)はアプリケーションが作
成したデータベーステーブル（ＤＢテーブル）であり、
予約アクセステーブル(183)、バックアップテーブル(18
4)及び予約管理テーブル(185)は複数予約アクセス登録
機能を実現するためにデータベースシステムが作成した
テーブルである。

【０１２５】アプリケーションが作成した ＤＢテーブ
ルのうち、アプリケーションからは、破線で囲った部分
(186)のみ直接アクセスすることができる。予約アクセ
ス時刻(1801及び1803)とアクセスＩＤ(1802及び1804)
は、予約更新及び予約参照処理を実現するためにデータ
ベースシステムが付加した列である。ＤＢテーブルに付
加した列のうち、予約アクセス時刻(1801及び1803)に
は、各レコードに登録されている予約アクセス処理のう
ち、最も処理時間が早い処理の予約アクセス時刻が格納
される。予約アクセス時刻(1801及び1803)に何も格納さ
れていない場合には、該レコードに対して更新又は参照
の予約処理が登録されていないことを示す。アクセスＩ
Ｄ(1802及び1804)には、各レコードに登録されている予
約アクセス処理のうち、最も処理時間が早い処理に対応
する識別子が格納される。

【０１２６】予約アクセステーブル(183)は、データベ
ースシステム内に１つ存在し、アクセスＩＤ(1805)と、
予約情報(1806)と、該予約アクセス処理の次に登録され
ている次予約アクセス時刻(1807)と、次アクセスＩＤ(1
808)とから構成される。

【０１２７】アクセスＩＤ(1805)は、予約アクセステー
ブル(183)内でユニークな識別子であり、ＤＢテーブル
(181及び182)と予約アクセステーブル(183)の対応を取
る。予約情報(1806)には、予約されたアクセス種別（更
新又は参照）と該処理の予約識別子が格納される。さら
に、付加情報として、更新処理の場合には更新処理内容
が格納され、参照処理の場合にはバックアップ識別子が
記述される。

【０１２８】一つのレコードに複数の予約アクセスがあ
る場合には、該複数の予約アクセス処理を予約時刻の早
い順に並べて予約アクセステーブル(183)の次予約時刻
(1807)と次予約アクセスＩＤ(1808)に順次登録する。次
予約アクセス時刻(1807)ならびに次アクセスＩＤ(1808)
が未登録の場合は、該予約アクセスが、該レコードに登
録されている予約アクセス処理の最後であることを示
す。このような予約アクセステーブル(183)のエントリ
のチェインのことを、以下の説明では、予約アクセスリ
ストと呼ぶ。

【０１２９】バックアップテーブル(184)は、データベ
ースシステム内に一つ存在し、バックアップＩＤ(1810)
とバックアップデータ(1811)とで構成される。バックア
ップＩＤ(1810)は、バックアップテーブル(184)内でユ
ニークな識別子である。バックアップＩＤ(1810)は、バ
ックアップが存在する場合のバックアップ識別子を示
し、予約アクセステーブル(183)のエントリとバックア
ップテーブル(184)のエントリとの対応を取る。バック
アップデータ(1811)には、予約アクセス時刻以降に更新
されたレコードのバックアップを格納する。本実施例で
はバックアップはレコード単位で格納しているが、参照
されるフィールドのみのバックアップを取ることももち
ろん可能である。

【０１３０】予約管理テーブル(185)は、データベース
システム内に１つ存在し、予約ＩＤ(1812)、予約状態(1
813)、予約アクセス時刻(1814)、及び、予約実行文(181
5)とで構成される。

【０１３１】予約ＩＤ(1812)は、論理的に同時に実行す
べき予約アクセス処理１つにつき１つ付与される番号で
あり、データベースシステム内でユニークな番号であ
る。予約状態(1813)は、前記同時に実行すべき予約参照
処理の処理状態を示す。処理状態としては、予約更新前
処理開始、予約更新前処理取消、予約参照前処理開始、
予約参照前処理完了、予約参照前処理取消等がある。予
約更新前処理開始及び予約参照前処理開始は、当該予約
アクセスの前処理を行なっている最中であることを示
し、予約参照前処理完了は、当該予約参照の前処理が正
常終了したことを示し、予約更新前処理取消及び予約参
照前処理取消は、当該予約アクセスの前処理が予約時刻
までに終了しなかったため、既に登録している予約情報
を取消中であることを示す。

【０１３２】一方、予約アクセス時刻(1814)には、予約
アクセスを実行する時刻が格納され、予約実行文(1815)
には、予約された参照実行文（問い合わせ実行文又は問
い合わせ実行コード）が格納される。

【０１３３】本実施例では、予約ＩＤがR0050の予約更
新処理及び、予約ＩＤがR0119の予約参照処理、予約Ｉ
ＤがR0120の予約参照処理がそれぞれ登録されている。
口座テーブルの口座番号670190049のレコードには、ア
クセスＩＤがA0002の予約更新処理と、アクセスＩＤがA
0350の予約参照処理の２つの予約アクセス処理が登録さ
れている。アクセスＩＤがA0002の予約更新処理の予約
時刻が9:00、アクセスＩＤがA0350の予約参照処理の予
約時刻が12:00であるので、アクセスＩＤがA0002の予約
更新処理が予約アクセスリストの先頭に登録されてお
り、アクセスＩＤがA0350の予約参照処理が予約アクセ
スリストの次の部分に登録されている。

【０１３４】本実施例で示したテーブル構造ではＤＢテ
ーブルと予約アクセステーブルの対応や予約アクセステ
ーブルと予約管理テーブル、あるいは、予約アクセステ
ーブルとバックアップテーブルの対応を取るためにそれ
ぞれ識別子を用いているが、ポインタ等を用いてこれら
の対応を取ることももちろん可能である。

【０１３５】図１９は、本実施例における予約更新前処
理の流れを示す図である。予約更新前処理では、まず予
約管理テーブル(185)の予約アクセス時刻(1814)を、登
録しようとしている予約アクセスの予約アクセス時刻で
検索し（ステップ１９０）、該アクセス時刻と一致する
予約アクセスが存在しその状態が前処理開始であるか否
かを判定する（ステップ１９１）。該アクセス時刻と一
致する予約アクセスが存在しその状態が前処理開始であ
れば、他の予約アクセス前処理と衝突しているため、エ
ラーリターンする。該エラーリターンを受け取ったアプ
リケーションプログラムは、予約アクセス時刻を変更す
るか、あるいは、現在実行中の予約アクセス前処理が終
了するまで待つかのいずれかの処理を行なうことにより
エラー状態から回復することが可能である。

【０１３６】予約アクセス前処理の衝突チェック（ステ
ップ１９１）が完了したならば、予約ＩＤを取得して、
予約管理テーブル(185)へ該予約ＩＤならびに予約時刻
の登録を行ない（ステップ１９２）、予約管理テーブル
(185)の予約状態(1813)を予約更新前処理開始に設定す
る（ステップ１９３）。そして、全ての更新レコードに
ついて、以下の処理を実行する。

【０１３７】まず、更新すべきレコードの内容を後述の
１行参照処理により取得する（ステップ１９４）。次
に、登録中の予約更新処理の予約時刻を既に過ぎていな
いかをチェックし（ステップ１９５）、もし予約時刻を
過ぎていた場合には、当該予約更新前処理が予定時刻に
間に合わなかったとしてエラー処理（ステップ１９９）
に制御を移す。

【０１３８】ステップ１９５で予約時刻を過ぎていない
場合には、予約情報を予約アクセステーブル(183)に登
録して（ステップ１９６）、次の更新レコードの処理に
移る（ステップ１９７）。予約情報(1806)のアクセステ
ーブル(183)への登録は、該更新レコードに既に登録さ
れている予約アクセスリストのうち、該予約アクセス時
刻より遅いアクセス時刻を持つ予約情報の直前に該予約
アクセス情報を登録する。該予約アクセス時刻より遅い
アクセス時刻を持つ予約情報がない場合には、予約アク
セスリストの最後に該予約アクセス情報を登録する。予
約情報(1806)の処理の種別は更新処理に設定し、更新処
理内容には更新する列名及び更新情報を設定する。

【０１３９】全ての更新レコードの予約情報の登録が完
了したならば（ステップ１９７）、予約管理テーブル(1
85)から該予約更新に対応するエントリを削除して（ス
テップ１９８）、処理を終了する。

【０１４０】一方、各レコードの予約情報の登録中にエ
ラーが発生した場合には、まず予約管理テーブル(185)
の状態を予約更新前処理取消に設定して、該予約更新前
処理で登録した全ての予約情報をテーブルから削除し、
最後に予約管理テーブル(185)の状態を予約更新前処理
失敗に設定してエラーリターンする（ステップ１９
９）。

【０１４１】図２０は、本実施例における予約参照前処
理の流れを示す図である。予約参照前処理では、まず予
約管理テーブル(185)の予約アクセス時刻(1814)を、登
録しようとしている予約アクセスの予約アクセス時刻で
検索し（ステップ２００）、該アクセス時刻と一致する
予約アクセスが存在しその状態が前処理開始であるか否
かを判定する（ステップ２０１）。該アクセス時刻と一
致する予約アクセスが存在しその状態が前処理開始であ
れば、他の予約アクセス前処理と衝突しているため、エ
ラーリターンする。該エラーリターンを受け取ったアプ
リケーションプログラムは、予約アクセス時刻を変更す
るか、あるいは、現在実行中の予約アクセス前処理が終
了するまで待つかのいずれかの処理を行なうことによ
り、エラー状態から回復することが可能である。

【０１４２】予約アクセス前処理の衝突チェック（ステ
ップ２０１）が完了したならば、予約ＩＤを取得して、
予約管理テーブル(185)へ該予約ＩＤ、予約時刻ならび
に予約実行文の登録を行い（ステップ２０２）、予約管
理テーブル(185)の予約状態(1813)を予約参照前処理開
始に設定する（ステップ２０３）。次に、全ての参照レ
コードについて、以下の処理を実行する。

【０１４３】まず、参照すべきレコードを後述の１行参
照処理により取得する（ステップ２０４）。次に、登録
中の予約参照処理の予約時刻を既に過ぎていないかをチ
ェックし（ステップ２０５）、もし予約時刻を過ぎてい
た場合には、当該予約参照前処理が予定時刻に間に合わ
なかったとしてエラー処理（ステップ２０９）に制御を
移す。

【０１４４】ステップ２０５で予約時刻を過ぎていない
場合には、予約情報を予約アクセステーブル(183)に登
録して（ステップ２０６）、次の参照レコードの処理に
移る（ステップ２０７）。予約情報(1806)のアクセステ
ーブル(183)への登録は、該更新レコードに既に登録さ
れている予約アクセスリストのうち、該予約アクセス時
刻より遅いアクセス時刻を持つ予約情報の直前に該予約
アクセス情報を登録する。該予約アクセス時刻より遅い
アクセス時刻を持つ予約情報がない場合には、予約アク
セスリストの最後に該予約アクセス情報を登録する。予
約情報(1806)の処理の種別は参照に設定し、バックアッ
プＩＤはNULL値（バックアップデータなし）に初期設定
する。

【０１４５】全ての参照レコードの予約情報の登録が完
了したならば（ステップ２０７）、予約管理テーブル(1
85)の予約状態(1813)を予約参照前処理完了に設定して
処理を終了する。

【０１４６】一方、各レコードの予約情報の登録中にエ
ラーが発生した場合には、まず予約管理テーブル(185)
の状態を予約参照前処理取消に設定して、該予約参照前
処理で登録した全ての予約情報をテーブルから削除し、
最後に予約管理テーブル(185)の状態を予約参照前処理
失敗に設定してエラーリターンする（ステップ２０
９）。

【０１４７】図２１は、本実施例における一行更新処理
の流れを示す図である。一行更新処理は、一つのレコー
ドの内容を更新する処理であり、データベースの更新処
理の中から呼び出される。

【０１４８】一行更新処理では、まず、更新するレコー
ドを取得して（ステップ２１０）、該レコードの予約ア
クセス時刻(1801又は1803)をチェックする（ステップ２
１１）。アクセス対象のレコードの予約アクセス時刻が
登録されていたら、現在の時刻が該レコードの予約アク
セス時刻を過ぎたか否かを判定する（ステップ２１
２）。アクセス対象のレコードの予約アクセス時刻が登
録されていない場合、または該レコードの予約アクセス
時刻がまだ過ぎていない場合には、通常通りレコードの
更新処理（ステップ２１９）を行なう。

【０１４９】ステップ２１１，２１２で、該レコードの
予約アクセス時刻が登録されており、かつ、現時刻が該
予約アクセス時刻を過ぎていたならば、該レコードのア
クセスＩＤ(1802又は1804)をキーにして予約アクセステ
ーブル(183)から予約情報(1806)を取得し（ステップ２
１３）、予約情報のアクセス種別をチェックする。

【０１５０】予約情報(1806)のアクセス種別が更新の場
合には、予約更新後処理を行ない（ステップ２１４）、
アクセス種別が参照の場合には、予約参照バックアップ
処理を行なう（ステップ２１５）。予約更新後処理は実
施例３で説明した処理と全く同様であり、予約参照バッ
クアップ処理は実施例２で説明した処理と全く同様であ
る。

【０１５１】次に、予約アクセステーブル(183)の次予
約アクセス時刻(1807)を確認し（ステップ２１６）、次
予約アクセス時刻(1807)の指定がある場合は、現時刻が
その次予約アクセス時刻を過ぎているか否かを判定する
（ステップ２１７）。次予約アクセス時刻の指定があ
り、かつ、現時刻が次予約アクセス時刻を過ぎていたな
らば、予約アクセステーブル(183)を次アクセスＩＤ(18
08)で検索して次に登録されている予約情報(1806)を取
得し（ステップ２１８）、アクセス種別のチェックに戻
る。

【０１５２】ステップ２１６，２１７で、次予約アクセ
ス時刻が登録されていない場合や、次予約アクセス時刻
をまだ過ぎていない場合には、予約アクセス処理のルー
プを脱出し、該レコードの更新処理（ステップ２１９）
を実行する。

【０１５３】図２２は、本実施例における一行参照処理
の流れを示す図である。一行参照処理は、一つのレコー
ドの内容を参照する処理であり、データベースの参照処
理の中から呼び出される。

【０１５４】一行参照処理では、まず、参照するレコー
ドを取得して（ステップ２２０）、該レコードの予約ア
クセス時刻(1801又は1803)をチェックする（ステップ２
２１）。アクセス対象のレコードの予約アクセス時刻が
登録されている場合は、現時刻が該レコードの予約アク
セス時刻を過ぎているか否かを判定する（ステップ２２
２）。アクセス対象のレコードの予約アクセス時刻が登
録されていない場合や、該レコードの予約アクセス時刻
がまだ過ぎていない場合には、該レコードのデータをそ
のまま参照データとして呼び出し元にリターンする。

【０１５５】ステップ２２１，２２２で、該レコードの
予約アクセス時刻が登録されており、かつ、現時刻が該
予約アクセス時刻を過ぎていたならば、該レコードのア
クセスＩＤ(1802又は1804)をキーにして予約アクセステ
ーブル(183)から予約情報(1806)を取得し（ステップ２
２３）、予約情報(1806)のアクセス種別をチェックす
る。

【０１５６】予約情報(1806)のアクセス種別が参照の場
合には、現在のデータを参照データとするとともに、予
約参照フラグをオンにして（ステップ２２７）、ステッ
プ２２８に進む。

【０１５７】予約情報(1806)のアクセス種別が更新の場
合には、予約参照フラグがオンであるか否かを判定し
（ステップ２２４）、オンであれば、予約参照バックア
ップ処理を行なってから（ステップ２２５）、予約更新
後処理を行ない（ステップ２２６）、ステップ２２８に
進む。ステップ２２４で、予約参照フラグがオフであれ
ば、予約更新後処理（ステップ２２６）のみを行なう。
予約更新後処理を行なった場合には更新後のデータを参
照データとする。予約更新後処理は実施例３で説明した
処理と全く同様であり、予約参照バックアップ処理は実
施例２で説明した処理と全く同様である。

【０１５８】次に、予約アクセステーブル(183)の次予
約アクセス時刻(1807)を確認し（ステップ２２８）、次
予約アクセス時刻(1807)の指定があれば、現時刻がその
次予約アクセス時刻を過ぎているか否かを判定する（ス
テップ２２９）。次予約アクセス時刻の指定があり、か
つ、現時刻が次予約アクセス時刻を過ぎていたならば、
予約アクセステーブル(183)を次アクセスＩＤ(1808)で
検索して次に登録されている予約情報(1806)を取得し
（ステップ２３０）、アクセス種別のチェックに戻る。

【０１５９】ステップ２２８，２２９で、次予約アクセ
ス時刻(1807)が登録されていない場合や次予約アクセス
時刻をまだ過ぎていない場合には、予約アクセス処理の
ループを脱出し、参照データを呼び出し元にリターンす
る。

【０１６０】本実施例によれば、複数の予約アクセスを
登録することができる。

【０１６１】

【発明の効果】本発明によれば、複数のレコードの一括
更新ならびに同時参照を行なうデータベースシステムに
おいて、該複数のレコードへのアクセスをあらかじめ時
刻指定で予約登録しておくことにより、該予約時刻に同
時に更新又は参照が実行されたようにアプリケーション
プログラムに対してみせることを可能とした。本発明で
は、登録された予約アクセス処理を予約時刻以前に行な
う予約アクセス前処理と、予約時刻以降に実行される予
約アクセス後処理に分割して実行することにより、デー
タベースシステムを停止することなく大量レコードの一
括更新および参照を実行することを可能とした。

【図面の簡単な説明】

【図１】第１の実施例における処理概要図およびテーブ
ル構成図

【図２】第１の実施例における予約更新前処理の流れ図

【図３】第１の実施例におけるDBアクセス処理の流れ図

【図４】第１の実施例における予約更新後処理の流れ図

【図５】第２の実施例における処理概要図およびテーブ
ル構成図

【図６】第２の実施例における予約参照前処理の流れ図

【図７】第２の実施例における１行更新処理の流れ図

【図８】第２の実施例における予約参照バックアップ処
理の流れ図

【図９】第２の実施例における予約参照後処理の流れ図

【図１０】第３の実施例における処理の概要図

【図１１】第３の実施例におけるテーブル構成図

【図１２】第３の実施例における予約更新前処理の流れ
図

【図１３】第３の実施例における予約参照前処理の流れ
図

【図１４】第３の実施例における１行更新処理の流れ図

【図１５】第３の実施例における１行参照処理の流れ図

【図１６】第３の実施例における予約更新後処理の流れ
図

【図１７】第３の実施例における予約参照後処理の流れ
図

【図１８】第４の実施例におけるテーブル構成図

【図１９】第４の実施例における予約更新前処理の流れ
図

【図２０】第４の実施例における予約参照前処理の流れ
図

【図２１】第４の実施例における１行更新処理の流れ図

【図２２】第４の実施例における１行参照処理の流れ図

【図２３】本発明を実施するデータベースシステムの構
成を示す図

【符号の説明】

1…予約更新前処理、2…予約更新後処理、5…予約更新
時刻、6…DBテーブル(口座テーブル)、7…DBテーブル
(支店テーブル)、8…予約更新テーブル、9…予約管理テ
ーブル、51…予約参照前処理、52…予約参照後処理、53
…予約参照バックアップ処理、56…予約参照時刻、502
…予約参照テーブル、503…バックアップテーブル。

Claims (8)

【特許請求の範囲】
1. 【請求項１】複数のレコードを含むデータベーステーブ
   ルを格納する記憶装置と、前記データベーステーブルの
   任意のレコードにアクセスするための処理装置とを有す
   るデータベース処理装置において、複数のレコードの更
   新をあらかじめ予約することにより、該予約された更新
   を見掛け上指定された予約更新時刻に実行する予約アク
   セス処理方法であって、 前記予約された更新処理は、当該レコードの更新を予約
   登録するための予約更新前処理ステップと、予約更新時
   刻以降の当該レコードへの最初のアクセス時に行なわれ
   る予約更新後処理ステップとで実行され、 前記予約更新前処理ステップにおいては、前記データベ
   ーステーブルの更新すべき各レコードに１対１に対応し
   た予約更新時刻と予約情報とで構成される予約更新情報
   として該レコードの予約更新時刻及び更新内容を格納す
   ることにより予約更新登録を行ない、 前記予約更新後処理ステップにおいては、当該レコード
   に対応する予約更新登録の更新内容に従って更新を実行
   し、該予約更新登録を削除し、 前記更新処理とは別に前記データベースへのレコードの
   アクセスが要求されたときは、該レコードに対する予約
   更新登録の有無及び現時刻と予約更新時刻との比較を行
   ない、該レコードに対応する予約更新登録があり、か
   つ、現時刻が予約更新時刻以降であれば前記予約更新後
   処理を実行してから当該レコードに対するアクセス処理
   を実行し、予約更新登録がない場合、又は、現時刻が予
   約更新時刻以前であれば予約された更新は行なわずに該
   レコードに対するアクセス処理を実行することを特徴と
   するデータベースの予約アクセス方法。
2. 【請求項２】前記予約更新時刻以降に、前記予約更新後
   処理ステップを前記更新予約されたレコードのすべてに
   関して実行するクリーンナップ処理を行なう請求項１に
   記載のデータベースの予約アクセス方法。
3. 【請求項３】前記予約更新前処理ステップで予約更新登
   録を実行している途中で、現時刻が該予約更新登録の予
   約更新時刻を過ぎてしまった場合には、該予約更新処理
   の状態を予約更新前処理取消状態に設定し、それまでに
   予約更新登録した全てのレコードの予約更新情報を削除
   すると共に、前記予約更新後処理ステップを実行する際
   には、当該予約更新処理の状態を確認して、該状態が予
   約更新前処理取消であった場合には該予約更新登録を破
   棄する請求項１または２のいずれか１つに記載のデータ
   ベースの予約アクセス方法。
4. 【請求項４】複数のレコードを含むデータベーステーブ
   ルを格納する記憶装置と、前記データベーステーブルの
   任意のレコードにアクセスするための処理装置とを有す
   るデータベース処理装置において、複数のレコードの参
   照をあらかじめ予約することにより、該複数のレコード
   の共用排他アクセス権を同時に確保することなく、見掛
   け上該予約参照時刻に該複数のレコードの参照を実行す
   る予約アクセス処理方法であって、 前記予約された参照処理は、当該レコードの参照を予約
   登録するための予約参照前処理ステップと、予約参照時
   刻以降に起動され実行される予約参照後処理ステップ
   と、予約参照時刻以降かつ予約参照後処理以前の間に発
   生する参照が予約された当該レコードへの更新処理時に
   実行される予約参照バックアップ処理ステップとで実行
   され、 前記予約参照前処理ステップにおいては、前記データベ
   ーステーブルの参照すべき各レコードに１対１に対応し
   た予約参照時刻と予約情報とで構成される予約参照情報
   として該レコードの予約参照時刻及び参照内容を格納す
   ることにより予約参照登録を行ない、 前記予約参照バックアップ処理ステップにおいては、参
   照が予約されたレコードへの更新処理を行なう前に該レ
   コードのバックアップデータを作成し、 前記予約参照後処理ステップにおいては、当該レコード
   のバックアップデータが作成されている場合にはバック
   アップデータを参照してから該バックアップデータ及び
   該予約参照登録を削除し、バックアップデータが存在し
   ない場合には当該レコードの内容を直接参照してから該
   予約参照登録を削除し、 前記参照処理とは別に前記データベースへのレコードの
   更新が要求されたときは、該レコードに対する予約参照
   登録の有無及び現時刻と予約参照時刻との比較を行な
   い、該レコードに対応する予約参照登録があり、かつ、
   現時刻が予約参照時刻以降であれば前記予約参照バック
   アップ処理を実行して当該レコードのバックアップデー
   タを作成してから当該レコードに対する更新アクセス処
   理を実行し、予約参照登録がない場合、又は、現時刻が
   予約参照時刻以前であれば予約参照バックアップ処理は
   行なわずに該レコードに対する更新アクセス処理を実行
   することを特徴とするデータベースの予約アクセス方
   法。
5. 【請求項５】前記予約参照後処理ステップは、前記予約
   参照時刻以降の適当なタイミングで、タイマ割込み又は
   最初のデータベースアクセス発生を契機として起動され
   る請求項４に記載のデータベースの予約アクセス方法。
6. 【請求項６】前記予約参照前処理ステップで予約参照登
   録を実行している途中で、現時刻が該予約参照登録の予
   約参照時刻を過ぎてしまった場合には、該予約参照処理
   の状態を予約参照前処理取消状態に設定し、それまでに
   予約参照登録した全てのレコードの予約参照情報を削除
   すると共に、前記予約参照バックアップ処理ステップ及
   び前記予約参照後処理ステップを実行する際には、当該
   予約参照処理の状態を確認して、該状態が予約参照前処
   理取消であった場合には該予約参照登録を破棄する請求
   項４または５のいずれか１つに記載のデータベースの予
   約アクセス方法。
7. 【請求項７】請求項１に記載の予約アクセス方法により
   複数のレコードの更新を見掛け上同時に実行するととも
   に、請求項４に記載の予約アクセス方法により複数のレ
   コードへの参照を該複数のレコードの共用排他アクセス
   権を同時に確保することなく実行することを特徴とする
   データベースの予約アクセス方法。
8. 【請求項８】前記予約更新登録又は前記予約参照登録に
   おいて格納する予約更新情報又は予約参照情報に、次の
   予約更新情報又は予約参照情報へのポインタを設け、一
   つのレコードに対して複数の予約アクセスを登録可能に
   した請求項１から３のいずれか１つに記載のデータベー
   スの予約アクセス方法。