JPH0760407B2 - データベース・システムの動作方法 - Google Patents

Description

【発明の詳細な説明】 A.産業上の利用分野 本発明は、リレーショナル・データベース管理システム
に関し、特に、リレーショナル・データベースにおける
データの論理的に矛盾のない状態を、参照一貫性により
保持する技術に関する。

B.従来技術 データベース管理システムとは、データを記録・保持す
るためのコンピュータ・システムである。リレーショナ
ル・データベース管理システムにおけるデータは、横方
向の行と縦方向の列を持つ「テーブル」の中に保管され
る。リレーショナル・データベースの考え方は、E.F.コ
ッド著「大規模共用データ・バンクのためのデータのリ
レーショナル・モデル（A Relational Model of Data f
or Large Shared Data Banks）」、CACM、第13巻第６号
（1970年６月）で紹介され、E.F.コッド著「より多くの
意味を扱うためのデータベース・リレーショナルモデル
の拡張（Extending the Database Relational Model to
Capture More Meaning）」、ACM TODS、第４巻第４号
（1979年12月）により拡張された。インターナショナル
・ビジネス・マシーンズ・コーポレーションズ（IBM）
社の製品「データベース２」は、リレーショナル・デー
タベース管理システムの典型例である。

リレーショナル・データベースでは、「参照一貫性」の
機能が重要である。参照一貫性は、異なる２テーブル或
いは同一テーブルの関連列間におけるデータ値の一貫性
を確実にする。テーブル列間に要求される関連は「参照
制約」として知られる。「従属テーブル」の「外部キ
ー」値が、「親テーブル」のいずれかの行の「基本キ
ー」値として存在する場合か或いは、外部キーが空であ
る場合に、従属テーブルの行は制約に関し参照一貫性を
持つ。換言すれば従属テーブルの各行は、夫々対応する
親ファイルの親行を持たなければならない。従属行の外
部キーが親テーブルの基本キー値と対応しないと、参照
制約が侵害され、それらのテーブルを含むデータベース
の参照一貫性が失われる。参照制約を実施してデータベ
ースの参照一貫性を保持するには、常に外部キー値が対
応する基本キー値を持つようなシステムが確立されなく
てはならない。参照一貫性の実施時にはまた、基本キー
値は必ず一意的でなくてはならない。この特性は「実体
一貫性」として知られている。参照一貫性については、
C.J.デイト著「データベース・システム入門（An Intro
duction to Database Systems）」第３版、アディソン
−ウェズリー出版社（1981年）に説明されている。

参照一貫性のある実施形態では、テーブルの基本キー値
を素早く探すため、親テーブルの「基本キー・インデッ
クス」（又は「基本インデックス」）が用いられること
がある。一般にデータ処理システムにおけるインデック
スは、データ行の即時探索に用いられる。インデックス
はテーブルの行を、「インデックス・キー」の値に基づ
いた順序に従い順序付ける。基本インデックスは、基本
キーの各々の値がインデックス中で一意的であることを
要請することにより、親テーブル中の基本キー値の一意
性を強制する。同様に、従属テーブルの外部キーの「外
部キー・インデックス」は、ある外部キー値を即時に探
索するのに役立つ。

データベースのデータが操作された結果、基本又は外部
キーが影響を受ける場合には常に、参照制約が実施され
なければならない。構造化照会言語（SQL）を使用する
リレーショナル・データベース管理システムでは、デー
タは主にLOAD（読出し）指令、INSERT（挿入）指令、UP
DATE（更新）指令、DELETE（削除）指令とその結果のオ
ペレーションにより操作される。LOAD及びINSERTはいず
れもデータベースにデータを追加する指令であるが、典
型的にはLOADは多数行を追加し、INSERTは数行追加す
る。UPDATEはデータの１以上の行内容を変更する指令、
DELETEは１以上の行を削除する指令である。データベー
スの参照一貫性を確実にするには、これらのオペレーシ
ョンのいずれかが発生する場合には常に、当該行を含む
参照制約が実施されなければならない。従来技術におい
て、参照一貫性実行及び参照制約実施の方法が種々存在
している。

ある従来技術の参照制約実施方式は、まず操作中（例：
読出し、挿入、更新、削除などのオペレーション中）に
発生する可能性のある制約侵害を検査し、侵害された制
約がなければ次に操作を実行する。実行にあたりトラン
ザクション或いは命令文（ステートメント）が与えられ
ると、各トランザクション或いは命令文毎にこの検査及
び実行の手順が行なわれる。一命令文は典型的には一行
または数行を操作する。一トランザクションは典型的に
は数個の命令文から成るので、より多数の行を操作する
ことになる。この従来技術では、データ上の各命令文或
いはトランザクション毎に操作及び検査の段階が別々に
行なわれるため、データの２回のパス（pass）が必要と
なる。各パスにおいて当該各行がアクセスされ読み取ら
れなくてはならず、ほとんどのデータ処理システムで操
作時間が増大する。２回のパスの実行というのは非効率
的であり、システム・パフォーマンスの遅滞を招く。

また別の従来技術では、上述の操作及び制約の検査の手
順が逆になるが、２回のパスを必要とする点では同様で
ある。この方式ではデータが操作されるまで制約は検査
されず、いずれかの制約が侵害された場合には全操作が
削除又は取消される。ここでもまた数行にわたり操作及
び制約の検査の段階が別々に行なわれるため、処理時間
が増大し、システム・パフォーマンスに影響が出る。よ
って、データ内で単一のパスのみを使用する参照制約実
施方式が要求される。

参照一貫性に係るさらに別の従来技術は、親及び従属レ
コード間の制約を表す経路すなわち「リンク」と、親デ
ータへの基本アクセス経路とを一つにする。この「リン
ク式」参照制約の方式は典型的には、親から全従属レコ
ードへの連鎖リスト、或いは全従属レコードを指すべく
親をルートにしたＢ木を用いて実行される。この方式に
は不利な点がいくつかある。まずリンク式参照制約実施
では、自己参照及び循環制約を探知・解決する特別な方
法が必要となる点。次に、現存データへの制約の追加又
は削除はリンク自体を修正しないとできないが、リンク
修正にはデータの再構築が大抵必要となる点である。よ
って、データを再構築せず制約の修正が可能となる、効
率的な参照制約実施方式が要求される。

C.発明が解決しようとする問題点 本発明の目的は、データ更新にあたり２回のパスを必要
としない参照制約実施方式を提供することである。

また本発明の目的は、自己参照及び循環制約が他の制約
と同様、特別な処置なしに実施できる参照制約実施方式
を提供することである。

D.問題点を解決するための手段 本発明は、参照制約実施の改良方式を提供することによ
り、前述の目的を達成する。本方式は、複数レコードに
影響を与えうるオペレーションに対応して、データ・レ
コードが操作されるデータベース管理システムのいずれ
にも有効である。本発明の改良方式では、他のレコード
が同一オペレーションにより操作される前に、各レコー
ドに関する参照制約を実施する。レコード挿入又は削除
後であるのに基本キー更新前であり外部キー更新後とい
う時に、制約を実施するのが本発明の特に有効な実行方
法である。

本発明の他の特徴及び利点については、後述実施例にお
ける詳細説明及び付記する図面により理解されよう。

E.実施例 Ｅ−1.用語 リレーショナル・データベース管理システムとは、参照
制約により関連付けられたテーブルの集合として表され
るデータを、記憶及び保持するコンピュータ・システム
である。第６図及び第２図は、６つの参照制約により関
連付けられた３つのテーブルを持つリレーショナル・デ
ータベース５を示す。DEPARTMENTテーブル10は、ある企
業の各部門を番号DEPTNO及び名称DEPTNAMEにより記述
し、責任者MGRNO及び業務報告を行なう上位部門の番号P
DMRDEPTを識別する。EMPLOYEEテーブル12は、全従業員
を従来員番号EMPNOにて期別して基礎的人事情報をリス
トし、従業員所属部門WORKDEPTを識別する。PROJECTテ
ーブル14は、この企業が現在従属している各プロジェク
トについて記述するもので、プロジェクト番号PROJNO、
プロジェクト名PROJNAME、担当従業員、担当部門及び日
程をリストし、個々のプロジェクトが属する主プロジェ
クトMAJPROJを識別する。該テーブルのサンプル・デー
タを第３図から第５図に示す。

第６図のテーブルは第２図に示すごとく６つの参照制約
によって、自己を含む相互が関連付けられている。制約
R1 16によれば、DEPARTMENTテーブル10の上位部門ADMRD
EPTは、DEPARTMENTテーブルの有効な部門番号DEPTNOで
ある必要がある。よって制約R1 16の親テーブルはDEPAR
TMENTであり、基本キーはDEPARTMENテーブルのDEPTNO
列、基本インデックスはDEPTNOインデックスである。制
約R1 16の外部キーはDEPARTMENTテーブル10のADMRDEPT
列であり、これによりDEPARTMENTは親でありかつ従属テ
ーブルとなる。親及び従属テーブルが同一であるので、
制約R1 16は自己参照制約である。

制約R2 18によれば、EMPLOYEEテーブル12（従属）の各
従業員所属部門WORKDEPT（外部キー）は、DEPARTMENTテ
ーブル10（親）の有効な部門番号DEPTNO（基本キー）で
ある必要がある。制約R3 20によれば、PROJECTテーブル
14の担当部門RESPDEPTは、DEPARTMENTテーブル10の有効
な部門番号DEPTNOである必要がある。制約R4 22によれ
ば、DEPARTMENTテーブル10の部門責任者MGRNOは、EMPLO
YEEテーブル12の有効な従業員番号EMPNOである必要があ
る。制約R5 24によれば、PROJECTテーブル14のプロジェ
クト担当従業員RESPEMPは、EMPLOYEEテーブル12の有効
な従業員番号EMPNOである必要がある。最後に制約R6 26
によれば、PROJECTテーブル14の主プロジェクトMAJPROJ
はそれ自身が、PROJECTテーブル14の有効なプロジェク
ト番号PROJNOである必要がある。R6もまた自己参照制約
である。

本記述に用いられる用語を要約すると、「行」はテーブ
ル内に存在しているとおりのレコードの外見上の形を言
い、「レコード」はデータベースに保管された行データ
の内部表現を指す。「親行」は「親テーブル」の一行で
あり、１以上の従属行の外部キー値と対応する「基本キ
ー値」を持つ。「従属行」は「従属テーブル」の一行で
あり、いくつかの親行の基本キー値と対応する「外部キ
ー値」を持つ。「自己参照制約」は同一テーブル内で定
義された制約であり、すなわち外部キーが同一テーブル
の基本キーを参照する。自己参照テーブルには「自己参
照行」が存在することがあり、ここでは外部キーが同一
行の基本キーと対応する。制約R1 16及びR6 26は共に自
己参照である。「循環」とは、その循環の中にあるテー
ブルがそれ自身の従属テーブルとなるような制約の組で
ある。制約R2 18及びR4 22は循環を成す。循環内には行
の循環が存在することがあり、ある行がそれ自身の従属
行となることがある。参照一貫性の支援にあたっては、
自己参照制約及び循環が特徴な問題をいくつか提起する
が、これを解決するのが本発明の特徴である。

「関連記述子」すなわち「制約記述子」は、単一の参照
制約を定義し、親テーブル及び従属テーブル並びに外部
キーを構成する例を識別する。関連記述子はまた、親テ
ーブルとその基本キーの基本インデックスを識別し、そ
の基本インデックスは基本キーの列を識別する。インデ
ックスが外部キーの列にも定義されていれば（これは任
意）、関連記述子は外部キー・インデックスも識別す
る。

関連記述子は、テーブルのレコード・タイプ記述子（テ
ーブル記述子と言うこともある）と連鎖しないのが望ま
しい。関連記述子がメモリー内制御ブロック中にあれ
ば、制約実施中に記述子に迅速なアクセスができる。し
かし、本発明方式使用の目的に対しては、該テーブル・
レコードにて制約実施中に、データベース・テーブルに
影響を与える参照制約を定義する要素にアクセス可能で
ありさえすればよい。

Ｅ−2.レコード・レベル制約実施の概論 本発明によれば、参照制約は読出し、挿入、更新、削除
などの指令によりレコード操作が行なわれる時に実施さ
れる。操作が起動されると、そのレコードが存在するテ
ーブルのテーブル記述子が調べられ、操作時に実施すべ
き参照制約があるかどうか検査される。制約の存在は、
テーブルに対する制約を表す最初の関連記述子の（テー
ブル記述子内の）識別子により示される。

レコードに影響を与える参照制約が識別されると、その
参照制約が実施される。正確には、挿入、更新、削除な
どの各操作により検査のアルゴリズムが異なる。各アル
ゴリズムの詳細は下記に示す。レコード操作と関連する
参照制約が侵害されると、侵害探知までに命令文或いは
トランザクチョン中に実行された操作は、すべて取消し
或いは「撤回」され、制約侵害を示すエラー戻りコード
がユーザや適用業務プログラムに対して出される。

第１図は、本発明による前記実施例の流れ図であり、リ
レーショナル・データベース・テーブルを操作する３つ
の主なSQL指令−−INSERT、UPDATE、DELETEに対するレ
コード・レベルの制約の実施方式を示す。

Ｅ−3.挿入操作時の制約実施 第１図の参照番号28に示すごとく、テーブルに対し新規
レコード追加操作が行なわれるとその操作中に、他レコ
ードと関係なく各レコードの追加及び制約実施が行なわ
れる。まず30でテーブルにレコードが追加され、テーブ
ル内の全インデックスが新規レコードに結合される、す
なわち新規レコード入力の情報が各インデックスに挿入
される。次に32で従属レコードを含む各制約に対し参照
制約検査が行なわれ、新規挿入レコードの外部キー値と
マッチする基本キー値を持つレコードの親テーブルに確
実にあるか調べられる。これは、挿入行の外部キーとマ
ッチするキー値について、親テーブルの基本インデック
ス（関連記述子内に識別される）を検査することにより
行なわれる。マッチするインデックス・キーが見つかる
と、外部キーとマッチする基本キーを親テーブルの一行
が持つことになり、参照制約が満たされる。以降この検
査は、挿入レコードに関する各制約に対して繰り返され
る。

34で、参照制約に従属する挿入レコードについてマッチ
する基本キー値が見つからなかった場合、制約は侵害さ
れ、36のエラー処理が行なわれる。エラー処理は以下の
手順より成る。全テーブル及びインデックスに関する、
挿入指令により発生したエラー地点までの操作を撤回
し、ユーザにエラー戻りコードを返す。中断された指令
及び操作撤回の方法は、従来技術により熟知されるとこ
ろである。

全レコードが制約侵害なく挿入されると操作は37で終了
となり、データベース更新が完了する。

最初に挿入し次に検査するという本発明の方式により、
特別なプログラミングの必要なく自己参照行を処理でき
る。基本キー及び関連するインデックス項目を最初に挿
入することで、挿入後に制約検査が行なわれると常に、
同一行の新規外部キーとマッチする基本キーが見つかる
こととなり、制約が満たされる。

第１表に、本発明における挿入時参照制約実施方式の、
擬似コードによる実施態様を示す。

第１表 擬似コードによる挿入時参照制約実施 101 DO挿入操作に含まれる各レコードに対し． 102 テーブルにレコードを挿入． 103 全インデックスにレコードを結合． 104 IFレコードがいずれかの関連記述子における従属
行ならばTHEN. 105 DO該レコードが従属行である各関連記述子に対
し． 106 レコードの外部キーを取り出す． 107 IF外部キーが空でなければTHEN. 108 DO./＝マッチする基本キー＝／ /＝の存在検査 ＝／ 109 親テーブルの基本キー・インデックスを調べ、基
本キー＝外部キーであるインデックス項目を探す． 110 IF項目がなければTHEN. ／＝基本キーが見つから＝／ ／＝ない場合 ＝／ 111 DO./＝参照制約侵害処理 ＝／ 112 外部キー・エラーを示す戻りコードをSET. 113 GOTO共通の中断処理手順． 114 END. 115 ELSE/＝基本キーがあれば ＝／ /＝エラー処理不要＝／ 116 DO何もしない． 117 END. 118 END. 119 ELSE/＝外部キー空がならば＝／ /＝制約検査不要 ＝／ 120 DO何もしない． 121 END. 122 END DOレコードが従属行である各関連記述子に対
して． 123 ELSE /＝レコードが従属でなけ＝／ /＝れば制約検査不要 ＝／ 124 DO何もしない． 125 END. 126 END DO挿入操作に含まれる全レコードに対して． 第１表の行番号101から126は、挿入指令や操作に含まれ
る各レコードをテーブルに挿入するためのDOループを成
す。まず行番号102で、テーブルへの実際の各レコード
挿入を行なう。重要なのは、参照制約の検査以前にレコ
ード挿入が行なわれる点である。これにより特別な処理
やコードなしに、共通のアルゴリズムによって自己参照
行制約を実施できる。

行番号103で、レコード挿入が行なわれるテーブル内に
定義済の全インデックスに、レコードを結合する。「イ
ンデックスに結合する」とは、新規レコードを参照する
項目をインデックスに挿入して、そのインデックスをレ
コード探索経路として用いられるようにするという意味
である。重要なのは、参照制約の検査以前にインデック
スを結合する点である。これにより行番号109で基本イ
ンデックスを探索すると、基本キーが同一の新規挿入行
内で外部キーとマッチするような自己参照行が見つか
る。

行番号104でテーブルのレコード・タイプ記述子を検査
し、テーブルがいずれかの関連（参照制約）において従
属であるかどうか判断する。レコードがいずれの関連に
おいても従属でなければ、制約実施コード（行番号105
から122）はスキップされて何も行なわず（行番号124及
び125）、次の挿入レコードを処理する。

レコードがいずれかの関連において従属であれば（行番
号104）、その関連により定義された制約を行番号105か
ら121において実施する。行番号105から121は、新規挿
入レコードについて、レコードを含むテーブルが従属で
ある各制約を実施するためのDOループである。挿入操作
時に制約を実施するにあたり、挿入レコードの各外部キ
ー値が、関連する制約の親テーブルレコードの基本キー
値とマッチする必要がある。関連記述子が従属テーブル
の外部キー列を識別するので、行番号106において挿入
レコードの外部キーを取り出すことができる。

外部キー列のいずれかが空ならば（行番号107）全外部
キー値が空であると見なされ、レコードに対し現在の参
照制約は実施できない。この場合制約実施コード（行番
号108から118）はスキップされて何も行なわない（行番
号120及び121）。

行番号108から118では、挿入レコードの外部キーとマッ
チする基本キーを検査して単一挿入レコードの単一参照
制約を実施し、見つからなければ挿入操作を中断する。
関連記述子が親テーブルの基本キーインデックスを識別
するので、マッチする基本キーがもしあれば探索でき
る。行番号109では、親テーブルの基本キーインデック
スを調べて行番号106で取り出した外部キー値とマッチ
する目的基本キー値を探索し、基本インデックス内の目
的基本キー値存在を示す標識を返す。基本キーが見つか
れば参照制約は満たされ、エラー処理コード（行番号11
1から114）はスキップされて何も行なわない（行番号11
6及び117）。

目的基本キー値が見つからなければ、すなわち行番号11
0で外部キー値とマッチする基本インデックス内に項目
がなければ、参照制約は侵害され、行番号111から114で
エラー処理が行なわれる。行番号112で、参照制約侵害
エラーを識別する、挿入操作からの戻りコードをセット
する。行番号113で一般の中断処理手順を開始し、その
時点で挿入しようとしたレコード及び、同一挿入操作に
よるそれ以前の挿入済レコード（エラーなし）を撤回す
る。データベース操作撤回の中断処理手順については従
来技術により熟知されるところであり、ここでは詳述し
ない。このように、最初の参照制約エラーが見つかった
時点で、全操作が撤回されて不成功に終わる。

関連記述子はまた同一テーブルが従属である次の関連記
述子の識別も行なうので、行番号105から122までのDOル
ープが「レコードが従属である各関連」について継続す
る。全従属関連記述子を成功裡に実施するとDOループ
（行番号105から122）を脱出し、次レコード挿入操作を
行なう。全挿入レコードにわたる外側のDOループ（行番
号101から126）は、挿入操作全体に含まれる全レコード
の挿入及び参照制約実施を行なって挿入操作完了となる
まで繰り返す。

本発明による、挿入操作時の参照制約実施例については
下記に述べる。次のSQL命令文を見ていただきたい。

INSERT INTO PROJECT VALUES（AD3110，GENAD SY
S，D21，000070,...AD3100） これは、第５図に示すPROJECTテーブル14に次の行を追
加するものである。

第１図に示すレコード・レベル制約実施方式によれば、
レコードは30でPROJECTテーブル14に挿入されてインデ
ックスが結合され、32で参照制約R3 20、R5 24、R6 26
が順次検査される。

最初に、PROJECTテーブル14（従属）に新規追加される
レコードに対し制約R3 20が実施される。この制約によ
れば新規挿入プロジェクト行の担当部門RESPDEPT（外部
キー）は、DEPARTMENTテーブル10（親）の有効な部門番
号DEPTNO（基本キー）を参照する必要がある。新規挿入
レコードのRESPDEPT列から外部キー値D21を取り出
すことにより実施が開始する。キー値は空でないので、
基本キーDEPTNOのインデックスを調べれば値D21に
対する項目が探索される。新規挿入プロジェクトは制約
R3 20を満たし、参照侵害は存在しない。

次に参照制約R5 24が実施される。この制約によれば、
各プロジェクトの担当従業員RESPEMPが有効である必要
がある。新規挿入レコードから外部キー値000070が
取り出される。キー値は空（ヌル）でないので、EMPLOY
EEテーブル12の基本インデックスEMPNOを調べれば000
070に対する項目が探索される。この値は探知され、
新規レコードは制約R5 24を満たす。

最後に参照制約R6 26が実施される。この制約によれ
ば、各プロジェクトの主プロジェクトMAJPROJが該プロ
ジェクトに対し有効である必要がある。PROJECTテーブ
ル14に新規挿入されるレコードのMAJPROJ列から、外部
キー値AD3100が取り出される。キー値はヌルでない
ので、PROJECTテーブル14の基本インデックスPROJNOを
調べればAD3100に対する項目が探索される。この項
目は探知され、制約R5 24が満たされる。

新規プロジェクト行がこれら３つの参照制約を満たすの
で、操作は完了する。１以上のレコードが挿入される場
合にも、各々が上述の通り処理され、次レコード挿入以
前に参照制約が実施される。

Ｅ−4.更新操作時の制約実施 参照制約実施という文脈において、更新操作は２つのタ
イプに分類される。親テーブルの基本キー値に対する更
新、及び従属テーブルの外部キー値に対する更新であ
る。基本キー値は参照制約の親テーブル行が変更された
ときに更新される。同様に、外部キー値は従属テーブル
行が変更されたときに更新される。各更新について異な
る参照制約検査が必要となるが、レコード毎に制約を実
施するという根本の方式は変わらない。第１図に示すの
は、更新操作38に対し各更新レコードについて制約実施
する方式である。

新規基本キー値により親テーブル行が更新されると、旧
基本キー値は消失する。従属テーブル行が外部キー値と
して持っているのが旧基本キー値であった場合、親テー
ブル行が更新されると同時に従属行は親行を持たなくな
り、参照一貫性が侵害される。基本キー値を持つ行が更
新されると、この侵害を探知するため更新テーブルが親
である各参照制約を検査し、制約内従属テーブルのどの
行も確実に、旧基本キー値と等しい外部キー値を持たな
いようにする。この検査40は、親テーブルの関連記述子
を調べることにより、基本行更新以前に行なわれる。こ
の記述子は従属テーブル及び外部キーインデックス（あ
れば）を識別し、従属テーブルの外部キー値探索に用い
られることもある。

外部キーインデックスがあればそれを調べて、旧基本キ
ー値とマッチする外部キー値が探索される。なければ全
従属テーブルを調べて、旧基本キー値とマッチする外部
キー値が探索される。マッチする外部キー値が42におい
て見つかると参照制約は侵害され、それまでの操作によ
り更新されたレコードは36において撤回（中断）され
る。外部キーが見つからなければ参照制約は満たされ
る。更新されるテーブルが親である各制約について、38
でこの処理が繰り返される。基本キー制約侵害が見つか
らなければ、レコード及び影響を受けるインデックスは
更新される。

行の基本キー検査後、48でレコードが更新される。同時
に行インデックスも新規の値に応じて更新される。この
更新については、従来技術にて熟知されている。更新時
制約実施の最終ステップは、行の外部キー制約実施であ
る。

従属テーブル行が更新されると、新規外部キー値とマッ
チする基本キーが各親テーブルにあるかどうか検査しな
くてはならない。マッチする基本キー値が存在しなけれ
ば、参照一貫性は侵害される。この侵害を探知するため
44で、更新テーブルが従属である各参照制約を検査し、
制約の親テーブルの行が更新される外部キー値と等しい
基本キー値を持つことを保証する。この検査44は、48で
従属行が更新された後に、制約の基本キーインデックス
を識別する従属テーブルの関連記述子を調べ、新規外部
キーとマッチする該基本キー値インデックスを探索する
ことにより行なわれる。

マッチする基本キー値が46で見つからなければ、参照制
約は侵害され、それまでの更新操作により行なわれた更
新は36において撤回（中断）される。

更新されるテーブルが従属である各制約について、この
処理が繰り返される。

レコード更新前の基本キー制約検査実施及びレコード更
新後の外部キー制約検査実施により、特別なコードなし
に、同一行の外部キーとマッチする基本キーを持つ自己
参照行の検査が行なえる。

参照一貫性の実行において、マッチする外部キー（すな
わち従属行）を持つ基本キーを直接更新することは許さ
れない。この規則は参照一貫性の文献では「更新制限」
規則と呼ばれる。自己参照行はそれ自身が自己の従属行
となる。ゆえに更新制限規則により、自己参照行の基本
キー更新は不可能である。この実施例の方法では、旧基
本キー値を新しいものと置き変える前に、旧基本キー値
とマッチする外部キー値がないかどうか検査することに
より、自己参照行の基本キー値更新を自動的に防ぐ機能
がある。これにより常に新規基本キー値は拒絶される。

この実施形態では参照制約検査が外部キー値更新後に実
施されるため、自己参照行の外部キーが生じるような更
新が行なわれることがある。外部キー値を基本キー及び
関連する基本キーインデックス更新後に検査することに
より、自己参照行の基本キーが常に見つかり、制約が満
たされる。第２表に、更新時参照制約実施方式の、擬似
コードによる実施を示す。

第２表 擬似コードによる更新時参照制約実施 201 DO更新操作に含まれる各レコードに対し． /＝レコード更新前に基本キー制約＝／ /＝実施 ＝／ 202 レコードから旧基本キーを取り出す． /＝基本キーはヌルであってはなら＝／ /＝ない ＝／ 203 IF基本キー列が変更されるならばTHEN. 204 DOレコードが親である各関連記述子（すなわち制
約）に対し． /＝更新レコードが親であるような＝／ /＝各制約を検査する ＝／ 205 IF関連の外部キーにインデックスが存在すればTHE
N. 206 インデックスを調べて、外部キー＝旧基本キーで
ある最初のインデックス項目を探す． 207 ELSE/＝外部キーにインデッ＝／ /＝クスが存在しなければ ＝／ 208 従属テーブルを調べて、外部キー＝旧基本キーで
ある最初のレコードを探す． 209 IF外部キーが見つかったならばTHEN. ／＝参照制約が侵害された ＝／ 210 DO. 211 基本キー更新時のエラー発生を示す戻りコードをS
ET. 212 GOTOこれまでに行なわれた更新を撤回する共通の
中断処理手順へ． 213 END. 214 ELSE/＝外部キーが見つからない ＝／ /＝それまでに制約侵害なし ＝／ 215 DO何もしない． 216 END. 217 END DO更新レコードが親である各関連記述子に対
し． 218 ELSE/＝基本キーが変更されない ＝／ /＝基本キー制約検査が＝／ /＝要求されない ＝／ 219 DO何もしない． 220 END. /＝基本キー制約実施終了 ＝／ /＝レコード更新 ＝／ 221 レコードの新規値に影響を受ける全インデックス
を更新． 222 レコードを新規値により更新． /＝外部キー制約実施 ＝／ 223 IF外部キー値が変更されていればTHEN. 224 DOレコードが従属である各関連記述子（すなわち
制約）に対し． 225 IF関連の外部キーが変更されていればTHEN. 226 DO./＝制約実施 ＝／ 227 新規外部キー値を取り出す． 228 IF新規外部キー値が空でなければTHEN. 229 DO. /＝マッチする基本キ−＝／ /＝があるかどうか検査＝／ /＝する ＝／ 230 親テーブルの基本キーインデックッスを調べて、
基本キー値＝新規外部キー値であるインデックス項目を
探す． 231 IF項目が存在しなければTHEN. 232 DO. 233 外部キー更新時のエラー発生を示す戻りコードをS
ET. 234 GOTO全更新操作を撤回する共通の中断処理手順
へ． 235 END. 236 ELSE/＝マッチする基＝／ ／＝本キーが見つ＝／ ／＝かった ＝／ 237 DO何もしない． 238 END. 239 END. 240 END. ／＝基本キー値と＝／ ／＝のマッチング＝／ ／＝検査終了 ＝／ 241 ELSE ／＝新規外部キー＝／ ／＝がヌル ＝／ 242 DO何もしない． 243 END. 244 END DOレコードが従属である各関連記述子に対
し． 245 ELSE ／＝外部キーが変更＝／ ／＝されない ＝／ 246 DO何もしない． 247 END. ／＝新規外部キー値＝／ ／＝制約実施の終了＝／ 248 END DO更新動作を行なう全レコードに対し． 第２表の行番号201から248は、更新オペレーションによ
り操作される各レコードを順次制約検査及び更新するた
めの、外側のDOループを成す。このループは異なる３つ
のセクションを持つ。（１）基本キー値更新時の親制約
検査40及び42（行番号202から220）、（２）制約侵害が
ない場合のレコード及びインデックス更新48（行番号22
1及び222）、（３）外部キー値更新時の従属制約検査44
及び46（行番号223から247）である。

Ｅ−5.基本キー更新時の制約実施 各テーブルは１つの基本キーしか持たないので、旧基本
キー値は参照制約実施以前に取り出される（行番号20
2）。

行番号203で、更新される基本キー列があるかどうか判
断する。基本キー列はレコード・タイプ記述子で識別さ
れるので、変更（更新）列が基本キーの一部であれば容
易に探知できる。レコード更新により変更される基本キ
ーがなければ行番号218の処理が継続し、基本キーの参
照制約実施コード（行番号204から217）はスキップされ
る。

基本キーが変更されれば、内側のDOループ（行番号204
から217）に入り、レコード毎に基本キー制約を実施す
る。前述したように、基本キーが更新される場合の制約
実施時には、いずれの制約においても旧基本キー値が外
部キーとマッチしてはならない。レコード・タイプ記述
子は、そのテーブルが親である最初の関連の関連記述子
を識別する。各関連記述子は順次、該テーブルが親であ
る次関連記述子を識別するので、ループは「レコードが
親である各関連記述子」について継続する。行番号205
で、外部キーにインデックスがあるかどうか関連記述子
を調べる。もしあれば行番号206でインデックスを調べ
て、行番号204で取り出した旧基本キー値とマッチする
外部キー値を探索する。外部キーにインデックスがなけ
れば（行番号207）行番号208で全従属テーブルを調べ
て、更新レコードの旧基本キー値とマッチする外部キー
を持つレコードを探す。

行番号209で、インデックス探索（行番号206）或いはテ
ーブル探索（行番号208）の結果を調べ、マッチする外
部キーがあるか判断する。マッチする外部キーがあれば
（行番号210）、そのレコードの基本キー更新は参照制
約実施を侵害することになり、行番号210から213を実行
してエラーを識別し、それ以前に実行済の更新操作（も
しあれば）を中断（撤回）する。行番号211で、基本キ
ー更新中の参照制約侵害エラーを識別する、更新操作か
らの戻りコードをセットする。行番号212で共通の中断
処理手順を開始し、これ以前に完了した更新を撤回す
る。こうして更新操作によってレコードに生じた参照制
約エラーを探知すると、全更新作業が不成功に終わる。

一方マッチする外部キーが見つからなければ（行番号21
4）、基本キー参照制約は満たされて処理は不要となる
（行番号215及び216）。ここで内側のDOループ（行番号
203から217）を繰り返し、現在の関連記述子を調べて同
一親テーブルに関するさらに別の関連記述子がある（す
なわち他に実施すべき参照制約がある）かどうか判断す
る。この内側ループは、基本キー値の全制約が実施され
るか、侵害が探知されるまで繰り返す。基本制約侵害が
探知されなければ、処理は行番号221及び222へ続く。

コードの第２セクションでは、テーブルのインデックス
及びレコード自体の更新を行なう。行番号221で、レコ
ードの列更新によりキーが変更された全インデックスを
更新（又は「作成」）する。そして行番号222でレコー
ド自体の更新を行なう。

Ｅ−6.外部キー更新時の制約実施 行番号223から247で、外部キー制約が実施される。行番
号223で、更新される外部キーがあるかどうか判断す
る。前記同様外部キー列はテーブルのレコード・タイプ
記述子で識別されるので、外部キーに含まれる列の変更
（更新）は容易に探知できる。更新操作により変更され
る外部キーがなければ制約実施は不要となり、行番号24
5へスキップされる。

外部キーが変更されると行番号224から244で、新規外部
キー値の制約を実施する第２の内側DOループに入る。前
述したように、外部キー値更新に対する参照制約実施と
は、レコードの新規外部キー値が制約の親テーブル内の
いくつかのレコードの基本キー値とマッチしなければな
らない、という事である。前記同様、関連記述子が従属
テーブルの外部キー列及び親テーブルの基本キーインデ
ックスを識別する。さらに関連記述子は同一テーブルが
従属である次関連記述子も識別するので、内側のDOルー
プ（行番号224から244）は「レコードが従属である各関
連」について継続しうる。

行番号228で、値がヌルである新規外部キー列があるか
どうか判断する。もしあれば全外部キー値がヌルである
とみなされ更新レコードに対する参照制約実施は阻止さ
れ、残りの制約実施コード（行番号229から240）はスキ
ップされて次の制約へ進む（行番号241から244）。

新規外部キーがヌルでなければ、制約が実施される（行
番号230から239）。外部キー新規値に対する参照制約
は、新規外部キーとマッチする基本キーがなければなら
ない。もしマッチする基本キーが見つからなければ、更
新作業は中断されそれまでの更新は撤回される。

外部キーが変更されなければ、制約検査処理はスキップ
されて次の制約へ進むが、そうでなければ行番号230
で、親テーブルの基本キーインデックス（関連記述子に
より識別される）を調べて新規外部キー値とマッチする
基本キー値があるか探索し、結果を示す標識を返す。

行番号231でマッチする基本キーがあるかどうか判断す
る。もしあれば（行番号236）、参照制約は満たされ、
次の制約実施へ進む（行番号237及び238）。もし基本キ
ーインデックス内に基本キーが見つからない、すなわち
存在しないならば（行番号231）、参照制約エラーとな
り、上記（行番号210から213）同様のエラー処理手順
（行番号232から235）が実行される。前述同様に、参照
制約侵害が探知された時点で更新作業は撤回される。

行番号236から238（基本キーが見つかり参照制約が満た
された）又は行番号241から243（新規外部キー値がヌ
ル）実行後、再び内側のDOループ（行番号224から244）
に入る。ここで現在の関連記述子を調べて、関連記述子
が次にあるか判断する。このループは、全従属制約が満
たされるか或いは侵害が探知されるまで繰り返す。

全部の親（行番号202から220）及び従属（行番号223か
ら247）参照制約を検査し終わると、更新操作を行なう
各レコードについて外側のDOループ（行番号201から24
8）を繰り返す。全更新レコードが各々の参照制約を満
たすと、更新作業は完了となる。

Ｅ−7.更新における実施例 第２図に示すテーブルの擬似コードによる操作を、いく
つかの例を挙げて第３図から第６図と関連させながら詳
述する。後述の各例では、上記テーブル・データは初期
状態である。各例において、SQL命令文で表す関連操作
を実行し、本発明による参照制約実施を行なうレコード
・レベル操作を記述する。

最初の例として次のSQL命令文を見ていただきたい。

UPDATE PROJECT SET PROJNO＝‘OP2015' WHERE PR
OJNO＝‘OP2012' これは、プロジェクト番号‘OP2012'である行を新規プ
ロジェクト番号‘OP2015'に変更するものである。前述
したように、プロジェクト番号PROJNOは参照制約R6 26
の基本キーである。旧基本キー値である‘OP2012'に従
属する行は存在しないので、この更新作業は成功裡に終
了する。

この更新操作についての制約は次のごとく実施される。
まず‘OP2012'のプロジェクト番号を持つレコードをPRO
JECTテーブル14より探して、旧基本キー値‘OP2012'を
取り出す（行番号204）。次に、PROJECTテーブル14のMA
JPROJ列にインデックスがないので（行番号205）PROJEC
Tテーブル14を調べて、外部キーMAJPROJとマッチする値
を持つレコードを探す（行番号208）。PROJECTテーブル
14には、更新レコードの旧基本キー値‘OP2012'と等し
いMAJPROJの値がない（行番号214から216）ので、制約R
6 26は満たされてレコードが更新される（行番号25
1）。更新される外部キーがないので、操作は完了す
る。

第２図に示すテーブルの擬似コードによる第２の操作例
として、次のSQL命令文を挙げる。

UPDATE DEPARTMENT SET DEPTNO＝‘D11' WHERE DE
PTNO＝‘D21' これは、部門番号‘D21'である行を部門番号‘D11'に更
新するものである。ところが部門番号DEPTNOは３つの制
約（R1、R2、R3）の基本キーであり、制約R2及びEMPLOY
EEテーブル12に影響する参照制約侵害が起こる。従って
更新は不成功に終わる。

まず、更新されるレコードはDEPARTMENTテーブル10にあ
る。制約は順不動に実施されるが、この例では各部門の
担当プロジェクトに関係する制約R3 20が最初に実施さ
れる。レコードから旧基本キー値‘D21'を取り出す（行
番号204）ことにより制約検査が開始する。次にPROJECT
テーブル14を調べて（行番号208）、担当部門RESPDEPT
（外部キ−）が部門レコードの旧基本キー値‘D21'と等
しいレコードを探す。該レコードがないので（行番号21
4）、この更新は制約R3 20を満たす。

従業員の所属部門に関係する制約R2 18の実施では、EMP
LOYEEテーブル12を調べて（行番号208）、旧基本キー値
‘D21'と等しい従業員所属部門WORKDEPT（外部キー）を
持つ従業員レコードを探す。従業員番号EMPNOが‘00007
0'であるレコードが該当する（行番号209）。旧基本キ
ー値と等しい外部キー値を持つレコードが存在するので
参照制約侵害となり、行番号210から213を実行して更新
は中断する。操作が中断するので、制約R1 16の検査は
実施されない。

第２図に示すテーブルの擬似コードによる第３の操作例
は、外部キー更新を含む。次のSQL命令文を見ていただ
きたい。

UPDATE EMPLOYEE SET WORKDEPT＝‘E31' WHERE EMPNO
＝‘000320' これは、従業員番号EMPNOが‘000320'であるEMPLOYEEテ
ーブル12のレコードの部門番号WORKDEPTを‘E21'から
‘E31'に変更するものである。この更新によって影響を
受ける外部キーはWORKDEPTのみであるので、制約R4 22
だけが実施される。参照制約エラーが起こるので更新は
不成功に終わる。

EMPLOYEEテーブル12で従業員番号EMPNOが‘000320'であ
るレコードが見つかる。基本キーが変更されないのでレ
コードは更新される（行番号221及び222）。外部キーWO
RKDEPTが変更されたので（行番号223）、新規外部キー
値‘E31'を取り出す（行番号227）。新規外部キー値が
ヌルでないので（行番号228）、基本キーインデックス
を調べて新規外部キー値とマッチする親テーブルDEPART
MENTテーブル10内の基本キー値を探す。DEPARTMENTテー
ブル10には部門番号DEPTNOが‘E31'であるレコードが存
在しないので（行番号231）、制約R4 22は侵害され、操
作は中断して更新作業が撤回される（行番号232から23
5）。

Ｅ−8.削除操作時の制約実施 削除操作時の参照制約実施に当たって問題となるのは、
基本キーが削除されることがあり、それとマッチする外
部キー値を持つ従属行の参照一貫性侵害を検査する必要
がある点である。削除された基本キーとマッチする各従
属テーブル外部キーを探す方法は、「基本キー更新時の
制約実施」の項で述べた通りである。外部キーのインデ
ックス（もしあれば）、或いは従属テーブル全体が探索
される。外部キーが見つかった後の動作は、制約作成時
に指定された特定の削除規則による。

削除規則には３種類ある。DELETE RESTRICT（限定削
除）、DELETE SET NULL（セット・ヌル削除）、DELETE
CASCADE（カスケード削除）である。DELETE RESTRICT規
則の元では、マッチする外部キーが存在する場合基本キ
ーは削除されず、基本キー更新時と同様の方法で制約実
施が行なわれる。マッチする外部キーが見つかると制約
侵害となり、操作は中断及び撤回される。マッチする外
部キーが見つからなければレコードの制約は満たされ、
レコード削除が完了する。

DELETE SET NULL規則は、旧外部キー値とマッチする基
本キー値の削除に当たって外部キー列のうち可能なもの
を全てヌルにセットする。DELETE SET NULLにより、従
属テーブル中のマッチする旧外部キー値は全てヌルとな
る。

DELETE CASCADEはDELETE SET NULLと似ているが、外部
キー値をヌルにセットするのではなく、マッチする旧外
部キー値を含む全レコードを従属テーブルから削除す
る。この削除は従属テーブルからその従属テーブル（削
除レコードのテーブルを親に持つテーブル）へ「カスケ
ード」され、「カスケード削除」として知られる従属レ
コード削除が行なわれる。削除レコードの従属テーブル
のテーブル（レコード・タイプ）記述子を検査して、そ
れが他の参照制約中の親テーブルかどうか判断する。も
しそうであればカスケード削除されたレコードが親とし
て扱われる、新規の削除制約実施が開始され、その削除
規則（RESTRICET、SET NULL、CASCADEのいずれか）が実
施される。この削除規則もDELETE CASCADEならば上述の
処理を繰り返す。そうでなければDELETE SET NULL又はD
ELETE RESTRICTを実行する。DELETE CASCADEはすなわ
ち、レコード削除がなされる親テーブルに結合する全従
属テーブルに波及する、再帰操作である。実行中にDELE
TE RESTRICTエラーが起こると、カスケード削除を含む
全削除操作が撤回される。

挿入及び更新のルーチン同様、削除のルーチンもブロッ
ク50に示すように、削除操作をレコード毎に行なって処
理する。第１図にあるように削除のアルゴリズムは、自
己参照行及び循環行を処理するため52でまずレコード削
除を行ない、その後54と56で制約検査を行なう。これに
より確実に、一度に１レコードが従属探索時に見つかる
ようにする。58でカスケード削除が行なわれると、経路
60の再帰的制御により削除ルーチンに戻る。

第３表は、削除操作中の参照制約実施方式の、擬似レコ
ードによる実行である。

第３表 擬似コードによる削除時参照制約実施 301 DO削除操作時に削除される全レコードに対し． 302 CASCADE:/＝カスケード削除＝／ /＝中における次の＝／ /＝従属レコードを＝／ /＝削除するための＝／ /＝再帰的エントリ＝／ 303 レコードを全インデックスを切断する． 304 IFレコードがいずれかの関連において従属ならばT
HEN. 305 レコードから旧基本キー値を取り出し、後に外部
キー値と比較するため保管する． 306 テーブルからレコードを削除する． 307 IFレコードがいずれかの関連において親ならばTHE
N. 308 DOレコードが親である各関連に対し． 309 IF外部キーにインデックスがあればTHEN. 310 インデックスを調べて、関連について外部キー＝
旧基本キーである最初のレコードを探す． 311 ELSE/＝外部キーにインデッ＝／ /＝クスがない ＝／ 312 従属テーブルを調べて、関連について外部キー＝
旧基本キーである最初のレコードを探す． 313 IFマッチする外部キーが見つかればTHEN. 314 DO./＝制約実施 ＝／ 315 IF削除規則がRESTRICTならばTHEN. 316 DO./＝参照制約エラー処理 ＝／ 317 RESTRICT削除規則エラーを示す戻りコードSET. 318 GOTO共通の中断処理手順へ． 319 END. 320 ELSE/＝削除規則が ＝／ /＝CASCADE＝／ /＝又はSET ＝／ /＝NULL ＝／ 321 DO UNTIL外部キーがもう見つからなくなるまで． /＝この関連内全従＝／ /＝属に対しカス ＝／ /＝ケード削除又は＝／ /＝セット・ヌル ＝／ 322 IF削除規則がCASCADEならばTHEN. 323 CASCADEをCALL. /＝該従属レコード＝／ /＝及びその従属を＝／ /＝再起的に削除 ＝／ 324 ELSE/＝削除規則 ＝／ /＝SET ＝／ /＝NULL ＝／ 325 外部キーの可能な値を全てヌルにSETする． 326 外部キーインデックス又は従属テーブルを調べ
て、関連について外部キー＝旧基本キーである次のレコ
ードを探す． 327 END DO外部キーがもう見つからなければ． 328 END DO./＝制約実施終了 ＝／ 329 ELSE /＝関連内に従属が＝／ /＝存在しない ＝／ 330 DO何もしない． 331 END. 332 END DOレコードが親である各関連に対し./＝基本
キーの全 ＝／ ／＝制
約検査終了 ＝／ 333 ELSE /＝レコードが親でない＝／ /＝ので制約検査不要 ＝／ 334 DO何もしない． 335 END. 336 END DO削除操作時に削除される全レコードに対
し． 第３表の擬似コードにおいて行番号301から336は、テー
ブル内の削除指定された全レコードを削除するための、
外側のDOループを成す。行番号302は削除手順への再帰
進入点である。これを「CASCADE」と呼び、削除レコー
ドの従属に対してCASCADE DELETE規則を実施するのに用
いる。この「CASCADE」再進入点については、行番号323
に関連して後に述べる。

行番号303で、削除レコードと、レコード削除が行なわ
れるテーブル上に定義された全インデックスを「切断」
する。すなわち、削除されるレコードを参照するインデ
ックス項目をインデックスより除去し、そのインデック
スがレコードを指さないようにする。

行番号304で、テーブルのレコード・タイプを調べて、
テーブルがいずれかの関連（参照制約）において親であ
るかどうか判断する。もしそうならば行番号305で旧基
本キー値をレコードより取り出し、マッチする外部キー
を後に探索するためこの値を保管する（行番号309から3
12）。各テーブルは基本キーを１つしか持たないので、
取り出しは、各関連に対してではなく一度のみ行なわれ
よう。

行番号306でレコードをテーブルから削除する。重要な
のは、参照制約の検査以前にまずレコード及び結合され
たインデックス項目が削除される点である。これによ
り、特別なコードや処理なしに自己参照行及び循環行の
検査を実施できる。いったんレコード及びインデックス
項目が削除されれば、マッチする外部キー探索中にその
レコードは見つからないことになる。

行番号307で再びテーブルのレコード・タイプ記述子を
調べて、テーブルがいずれかの関連において親であるか
どうか判断する。そうでなければそのレコードは実施す
べき参照制約を持たないので、制約実施コード（行番号
308から332）はスキップされる。しかしレコード・タイ
プ記述子が親テーブルを含む関連記述子を識別すれば、
制約を実施して処理は継続する（行番号308から332）。

行番号308から332は、レコード削除の際にテーブルが親
である各制約を実施する、内側のDOループを成す。レコ
ード・タイプ記述子は、親テーブルを含む最初の関連の
関連記述子を識別する。各関連記述子は順次、同じ親テ
ーブルを含む次関連記述子を識別するので、ループは
「レコードが親である各関連」について継続しよう。

行番号309から312で、旧基本キー値とマッチする最初の
外部キー値を探す。行番号309で関連記述子を調べて、
外部キーにインデックスがあるかどうか判断する。もし
あれば、行番号310でそのインデックスを調べて、旧基
本キー値（行番号305で取り出される）とマッチする外
部キー値を探す。外部キーにインデックスがなければ
（行番号311）、行番号312で全従属テーブルを調べて、
マッチする外部キーを持つ最初のレコードを探す。

行番号313で、左記のインデックスもしくはテーブル探
索の結果を検査し、マッチする外部キー値が見つかった
か判断する。もしマッチする外部キー値が見つからなけ
れば、削除される親レコードの関連には従属レコードが
存在しないので制約実施は不要となり、処理は次の制約
実施へと継続する（行番号328）。

マッチする外部キーが見つかると（行番号313）、該従
属レコードを行番号314から328にある制約の削除規則に
より処理する。行番号315で関連記述子を検査して、削
除規則がRESTRICTかどうか判断する。もしそうならば行
番号313で見つかった外部キーが参照制約エラーを起こ
すので、行番号316から319を実行してエラー戻りコード
をセットし、全削除操作は中断（撤回）する。行番号31
8でコールされる一般の中断処理手順により、行番号306
で行なわれようとしてレコード削除のみならず、それ以
前に削除手順により行なわれたレコード削除も撤回され
る。また中断処理により、削除レコードの参照制約実施
の一環として以前に行なわれた、カスケード削除及びセ
ット・ヌル削除も撤回される。こうして、参照制約エラ
ーが起こると全削除操作が撤回されて、処理は不成功に
終わる。

削除規則がCASCADEかSET NULLならば（行番号320）、行
番号321から327で削除レコードの従属が処理される。こ
の場合、削除レコードの旧基本キー値とマッチする全外
部キーを探索し、削除規則に従って処理しなければなら
ない。行番号321から327のDOループがこれを行なう。行
322は削除ルールがCASCADEか否かをテストする。もしそ
うであれば、行番号323が実行される。行番号323は削除
処理全体（行番号303から325）を行番号302の「CASCAD
E:」再進入点により再帰的に呼び出し、探索された従属
レコードを削除して、そのレコード削除の参照制約を実
施する。

一方最初に削除されるレコードの削除規則がSET NULLな
らば（行番号324）、探索された従属レコードの外部キ
ー列のうち、可能な値を全てヌルにセットして（行番号
325）削除レコードのSET NULL削除規則を実施する。

カスケード削除（行番号323）又はセット・ヌル（行番
号325）の後、行番号326で旧基本キー値と等しい外部キ
ーを持つ次レコードを探す。これは、行番号309から312
の箇所で述べた外部キー・インデックスもしくはテーブ
ル探索を用いて行なわれよう（ここでは再び詳述せ
ず）。こうして探索されたレコードは、制約の削除規則
に従って処理される次の従属レコードとなり、行番号32
1から327のDOループが再び実行される。外部キーがもう
見つからなければ、親レコード削除に関係する制約実施
は成功裡に終了する。

行番号328（全従属レコードの参照制約実施）、或いは
行番号329から331（従属レコードが見つからない）の
後、現在の関連記述子を調べて同じ親テーブルを持つ関
連記述子が他にあるかどうか判断する。もしあれば、旧
基本キー値が削除されたため実施すべき参照制約が他に
もあることとなり、レコード削除に対する全制約の実施
が終わるか又は制約侵害が探知されるまで、内側のDOル
ープ（行番号308から332）を繰り返す。

行番号332（全制約検査終了）、或いは行番号333から33
5（検査する制約がない）が終了すると、１レコードの
削除及び結果として起こるカスケード削除は完了する。
外側のDOループ（行番号301から336）は、削除操作によ
って削除される全レコードの処理が終わるか又は制約侵
害により操作が中断（撤回）されるまで繰り返す。

Ｅ−9.削除における実施例 後述の各例では、上記テーブル・データは初期状態であ
る。各例において、SQL命令文で表す関連操作を実行
し、本発明による参照制約実施を行なうレコード・レベ
ル操作を記述する。

最初の例として次のSQL命令文を見ていただきたい。

DELETE FROM EMPLOYEE WHERE EMPNO＝‘000070' これは、従業員番号が‘000070'である行をEMPLOYEEテ
ーブル12から削除するものである。EMPLOYEEテーブル12
は、実施すべき２つの制約、R4 22及びR5 24の親テーブ
ルである。実施を開始すると、EMPLOYEEテーブル12内で
従業員番号EMPNOが‘000070'であるレコードを探し、該
レコードをEMPLOYEEテーブルのインデックスと切断し
（行番号303）、旧基本キー値‘000070'を取り出して保
管する（行番号305）。その後レコードを削除し（行番
号306）、関連する制約を順不同に実施する。

PROJECTテーブル14から、旧基本キー値‘000070'と等し
い外部キー値RESPEMPを持つ最初のレコードを探索し
て、、制約R5 24を実施する（行番号309から312）。該
レコードが存在しないので（行番号313及び329）、削除
規則RESTRICTが支持されてこの削除についての制約R5 2
4は満たされる。故に内側のDOループ（行番号308から33
2）は、次の制約R4 22について繰り返す。

DEPARTMENTテーブル10から、旧基本キー値‘000070'と
等しい外部キー値MGRNOを持つ最初のレコードを探し
て、制約R4 22を実施する（行番号309から312）。部門
番号DEPTNOが‘D21'であるレコードが探索される（行番
号313）。制約R4 22に対する削除規則はSET NULLなので
（行番号320）、該従属レコードの部門責任者MGRNOを
‘ヌル’にセットする。ヌルにセットすべきマッチする
外部キー値は他にないので（行番号321から328のDOルー
プ）、制約R4 22は満たされる。適用される全制約が満
たされたので、内側のDOループ（行番号308から332）は
繰り返さない。

最後にEMPLOYEEテーブル12内に、従業員番号EMPNOが‘0
00070'であるレコードがもうなければ（行番号301から3
36の外側DOループ）、制約R4 22実施は終了して削除作
業が成功裡に終わる。

第２の実施例は、次のSQL命令文を用いたカスケード削
除である。

DELETE FROM PROJECT WHERE PROJNO＝‘OP2000' これは、プロジェクト番号‘OP2000'を持つ行をPROJECT
テーブル14から削除するものである。まず外側のDOルー
プ（行番号301から336）に入り、プロジェクト番号PROJ
NOが‘OP2000'である最初（かつ唯一）のレコードを削
除する。

‘OP2000'のレコードは初めに削除ルーチン（行番号303
から332）に入る。レコードを探索し、PROJECTテーブル
14のインデックスと切断する（行番号303）。PROJECTテ
ーブル14はある関連において親であるので（行番号30
4）、レコードの旧基本キー値‘OP2000'を取り出して保
管する（行番号305）。その後レコードを削除する（行
番号306）。

自己参照制約R6 26は内側のDOループ（行番号308から33
2）に入り、旧基本キー値‘OP2000'と等しい外部キー値
MAJPROJを持つ最初のレコードをPROJECTテーブル14から
識別する（行番号309から312）。プロジェクト番号PROJ
NOが‘OP2010'であるレコードを探索し（行番号313）、
削除規則CASCADEが実施する（行番号320から328）。PRO
JNOが‘OP2010'のレコードは最も内側のDOループ（行番
号321から328）に入り、CASCADE進入点（行番号302）を
用いて削除ルーチンに再帰再進入し、削除及び該レコー
ドの制約実施を行なう。

この削除ルーチンへの二度目の再進入時に、‘OP2010'
のレコードをインデックスと切断し（行番号303）、旧
基本キー値‘OP2010'を取り出して保管し（行番号30
5）、レコードを削除し（行番号306）、レコード削除制
約を実施するため内側のDOループ（行番号308から332）
に入る。PROJECTテーブル14から外部キー値MAJPROJが
‘OP2010'（旧基本キー値は削除された）である最初の
レコードを探して、制約R6 26を実施する。PROJNOが‘O
P2012'であるレコードが探索される。制約R6 26に対す
る削除規則はCASCADEなので、PROJNOが‘OP2012'のレコ
ードは最も内側のDOループ（行番号321から328）に入
り、CASCADE進入点（行番号302）を用いて削除ルーチン
に再帰再進入し、削除及び該レコードの制約実施を行な
う。

削除ルーチンへの三度目の進入時に、‘OP2012'のレコ
ードをインデックスと切断し（行番号303）、旧基本キ
ー値‘OP2012'を取り出して保管し（行番号305）、レコ
ードを削除し（行番号306）、レコード削除制約を実施
するため内側のDOループ（行番号308から332）に入る。
PROJECTテーブル14から外部キー値MAJPROJが‘OP2012'
（旧基本キー値は削除された）である最初のレコードを
探して（行番号309から312）、制約R6 26を実施する。
該レコードが見つからないので（行番号329）、プロジ
ェクト番号PROJNOが‘OP2012'の削除についての制約R6
26は満たされる。この削除に関し他の制約はない（行番
号332）。こうして削除ルーチン三度目の進入は終了
し、行番号323で三度目の進入がコールされた（呼び込
まれた）箇所の直前の、二度目の進入の制御へ戻る。

行番号326で削除ルーチン二度目の呼込みへ戻り、PROJE
CTテーブル14を調べて外部キー値MAJPROJが‘OP2010'で
あるレコードが他にないか探す。該レコードがないの
で、制約R6 26は満たされる。プロジェクト番号PROJNO
が‘OP2010'の削除についての制約R6 26は満たされる。
この削除に関し実施すべき他の制約はない（行番号33
2）。こうして削除ルーチン二度目の進入は終了し、行
番号323の後の、削除ルーチン最初の呼込みへ制御は戻
る。

行番号326で削除ルーチン最初の呼込みが再開し、PROJE
CTテーブル14から外部キー値MAJPROJが‘OP2000'である
次のレコードを探す。該レコードは見つからない。故に
プロジェクト番号‘OP2000'削除についての制約R6 26は
満たされる。適用される制約が他にないので、全削除操
作は成功裡に終わる。

第３かつ最後の実施例では、２つのDELETE SET NULL制
約は満たされるが、DELETE CASCADE制約の侵害により操
作が中断・撤回される複雑な削除を示す。次のSQL命令
文を見ていただきたい。

DELETE FROM DEPARTMENT WHERE DEPTNO＝‘A00' これは、部門番号DEPTNOが‘A00'である行をDEPATMENT
テーブル10から削除するものである。制約R1 16、R2 1
8、R3 20はDEPARTMENTテーブル10を親テーブルに持つ。

操作開始後外側のDOループ（行番号301から336）に入
り、‘A00'を持つDEPARTMENTレコードを探す。‘A00'レ
コードをインデックスと切断し（行番号303）、旧基本
キー値‘A00'を取り出して保管し（行番号305）、レコ
ードを削除し（行番号306）、レコード削除についての
３つの制約を実施するため内側のDOループ（行番号308
から332）に入る。

制約R3 20を実施して、PROJECTテーブル14から外部キー
RESPDEPTの値が‘A00'である最初のレコードを探す（行
番号309から312）。該レコードがないので、この削除に
ついての制約R3 20は支持され、次の制約R2について内
側のDOループを繰り返す。

DEPARTMENTレコード‘A00'についての制約R2 18を実施
して、EMPLOYEEテーブル12から外部キーWORKDEPTの値が
‘A00'である最初のレコードを探す（行番号309から31
2）。従業員番号EMPNOが‘000010'であるレコードが見
つかる（行番号313）。制約R2 18に対する削除規則はSE
T NULLなので（行番号320）、従業員番号‘000010'のWO
RKDEPTをヌルにセットする（行番号325）。WORKDEPTの
値が‘A00'であるEMPLOYEEレコードが他にないので、最
も内側のDOループ（行番号321から328）を出て、部門番
号‘A00'削除についての制約R2 18は満たされ、最後の
制約R1 16について内側のDOループを繰り返す。

部門番号‘A00'削除についての制約R1 16実施を開始し
て、DEPARTMENTテーブル10から外部キーADMRDEPTの値が
‘A00'である最初のレコードを探す。自己参照行‘A00'
はまた外部キー‘A00'も持つが、該レコードはすでに削
除されているため（行番号306）ここでは見つからな
い。しかし部門番号DEPTNOが‘D01'であるレコードが見
つかる。制約R1 16に対する削除規則はCASCADEであるの
で、CASCADE進入点（行番号302）において削除ルーチン
に再帰進入し（行番号323）、部門‘D01'のカスケード
削除処理を行なう。

二度目の削除ルーチンに入り、部門‘D01'の再帰的削除
を開始してレコードをDEPARTMENTテーブルにインデック
スと切断し、レコードの旧基本キー値‘D01'を取り出し
て保管し、レコードを削除する（行番号303から306）。
部門‘D01'削除についての制約R3 20を実施する（行番
号308から332）。外部キーRESPDEPTの値が‘D01'である
最初のレコードをPROJECTテーブル14から探索し、プロ
ジェクト番号PROJNOが‘MA2100'であるレコードが見つ
かる（行番号309から313）。制約R3 20に対する削除規
則はRESTRICTであるので（行番号315）、プロジェクト
番号PROJNOが‘MA2100'であるレコードの存在がエラー
を起こす。

適切な戻りコードをセットして（行番号317）制約侵害
エラーを識別し、部門‘A00'の削除操作は36にて中断す
る。操作中に削除又は「ヌル」にセットされた全レコー
ドは、一般の中断処理手順により元の状態に戻る（行番
号318）。

Ｅ−10.レコード・レベル制約実施による操作の制限 ある操作によりレコードが処理される順序が、関連操作
結果に影響してはならない、というのはリレーショナル
・データベース理論の原則である。本発明による方式で
はレコード・レベルで制約実施を行なうので、複数行の
関連操作時に全体として、処理の順序が関連制約操作結
果に影響する場合がある。例えば、自己参照制約の削除
規則がRESTRICTであった場合、複数行操作時のレコード
・アクセスの順序が結果に影響する。

従って、参照一貫性を持つ関連結果を保持するため本発
明では、矛盾する結果を生じる可能性のある操作及び削
除規則について制限を設ける。本制限とは、次の通りで
ある。

（１）自己参照制約の削除規則はCASCADEであること。

（２）２以上のテーブルの間の循環制約中の削除規則は
削除操作時に、どのテーブルも（カスケードを通じ）自
己に影響しないようにすること。

（３）副照会を伴う削除操作時に、副照会で参照される
テーブルが、（CASCADE又はSET NULLを通じ）削除レコ
ードを含むテーブルにより影響されてはならない。本制
限は、副照会を含む削除に関するリレーショナル・デー
タベース理論における従来規則の拡張である。それは削
除の対象テーブルは副照会中で参照されてはならない、
というものである。

（４）自己参照テーブルに対する副選択を伴う挿入操作
は、２以上の行を戻してはならない。

（５）自己参照テーブルの複数行を削除してはならな
い。

（６）基本キーを複数行に亙って更新してはならない。

これらの制限は必要に応じ、適用業務プログラミング技
術或いは他の方法により回避できる。もし制限が厳しけ
れば、特定の場合他の方法で制約を実施して制限を除く
ことも、データベース管理システムでは可能である。

本発明を要約すると、３つの基本操作（INSERT、UPDAT
E、DELETE）いずれにおいても参照制約は、個々のレコ
ード操作時に実施されるということである。制約実施
は、適用業務プログラム及びデータへのアクセス・パス
と関係なく行なわれる。制約がデータ更新操作そのもの
と一体的に実施されるので、パフォーマンス・コストは
従来技術による方式（データ操作及び制約実施に２つの
パスを必要とした）と比べ、最少限で済む。操作のタイ
プが異なる毎にデータ操作及び制約実施が行なわれる順
序を適正に選択することにより、自己参照行及び循環行
が自動的に処理される。挿入及び削除時には、各レコー
ドはまず挿入又は削除され、次に制約が実施される。エ
ラーが探知されると、データ操作は撤回される。本方式
は制約は大抵の場合支持される、という「楽天的」な見
方をしている。（成功に関して最適化されている）。更
新時には、基本キー制約がまず実施され、次にレコード
が更新され、最後に更新された外部キーの制約が実施さ
れる。

特定の実施例について述べてきたが、その他の例につい
ても本発明により実行できる旨理解されよう。制約要素
の定義がレコード・レベル操作時にアクセスできるもの
であればよい為、例えば外部カタログなど他の方法によ
っても、参照制約を保管しアクセスすることができる。
さらに制約実施コードは、上述してきたような「イン・
ライン」式の組み合わせでなく、データ操作コードとは
別に集めることができる。この場合、レコード・レベル
操作時に検査すべき制約が探知されると、データ更新経
路からの「トリガ」によりコードが起動される。また制
約実施及びレコード操作は、上述例（次レコード操作以
前に各レコードが操作され制約が実施される）とは異な
る順序で行なわれることがある。

F.発明の効果 本発明の用いればリレーショナル・データベースにおけ
る参照制約の検査の実施を効果的に行なうことができ
る。

【図面の簡単な説明】

第１図は本発明による挿入、更新、削除中の参照制約実
施方式の流れ図である。 第２図は第６図における参照制約の仕様を示す表であ
る。 第３図は第６図のDEPARTMENTテーブルを示す図であり、
基本キー、外部キー及びサンプル・データを含む。 第４図は第６図のEMPLOYEEテーブルを示す図であるり、
基本キー、外部キー及びサンプル・データを含む。 第５図は、第６図のPROJECTテーブルを示す図であり、
基本キー、外部キー及びサンプル・データを含む。 第６図は、６つの参照制約により関連付けられた３テー
ブルを持つリレーショナル・データベースの概略図であ
る。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 ハワード・ウインズトン・ヘロン アメリカ合衆国カリフオルニア州サン・ホ セ、ビング・ドライブ1444番地 (56)参考文献 情報処理学会第36回（昭和63年前期）全 国大会講演論文集 ｐ．501−502

Claims (1)

【特許請求の範囲】
1. 【請求項１】データの行より成る複数のテーブルを有
   し、該テーブルは親テーブル及び従属テーブルを含み、
   上記テーブルの行は基本キー及び外部キーを有し、上記
   テーブルは上記基本キー及び外部キーのインデックスを
   有するリレーショナル・データベース管理システムにお
   いて行を操作し且つ参照制約を維持する方法であって、 少なくとも、２つの行を操作する動作が１つの行の更新
   を含んでおり、 新規な基本キーを以て１つの行を更新するとき、更新さ
   れる古い基本キーとマッチする従属テーブルの外部キー
   の存在を該外部キーのインデックスをたどって調べるこ
   とにより該行の基本キーの更新から生じる参照制約の侵
   犯を識別する段階、 次いで該行を更新し、且つこれとともに当該テーブルの
   インデックスを更新する段階、 次いで該行の更新された外部キーとマッチする親テーブ
   ルの基本キーの存在を該基本キーのインデックスをたど
   って調べることにより、該更新された外部キーから生じ
   る参照制約の侵犯を識別する段階、 上記参照制約の侵犯が識別する段階において参照制約の
   侵犯が識別されたならば上記更新動作を撤回する段階、 を含むリレーショナル・データベース・システムの動作
   方法。