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

Abstract

(57)【要約】本公報は電子出願前の出願データであるた
め要約のデータは記録されません。

Description

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

Ｂ、従来技術 データベース管理システムとは、データを記録・保持す
るためのコンピュータ・システムである。

リレーショナル・データベース管理システムにおけるデ
ータは、横方向の行と縦方向の列を持つ「テーブル」の
中に保管される。リレーショナル・データベースの考え
方は、Ｅ、Ｆ、コツト著「大規模共用データ・バンクの
ためのデータのリレーショナル・モデル（Ａ　Ｒｅ１ａ
ｔｉｏｎａｌ　Ｍｏｄｅｌ　ｏｆ　Ｄａｔａｆｏｒ　Ｌ
ａｒｇｅ　５ｈａｒｅｄ　Ｄａｔａ　Ｂａｎｋｓ　）　
Ｊ、ＣＡＣＭ、第１３巻第６号（１９７０年６月）で紹
介され、Ｅ、Ｆ、コツト著「より多くの意味を扱うため
のデータベース・リレーショナルモデルの拡張（Ｅｘｔ
ｅｎｄｉｎｇ　　ｔｈｅ　　Ｄａｔａｂａｓｅ　　Ｒｅ
１ａｔｉｏｎａｌ　　ｌイｏｄｅｌ　　ｔ。

Ｃａｐｔｕｒｅ　ｔ４ｏｒｅ　Ｍｅａｎｉｎｇ　）　Ｊ
、ＡＣＭ　　ＴＯＤＳ。

第４巻第４号（１９７９年１２月）により拡張された。

インターナショナル・ビジネス・マシーンズ・コーポレ
ーションズ（ＩＢＭ）社の製品「データベース２」は、
リレーショナル・データベース管理システムの典型例で
ある。

リレーショナル・データベースでは、「参照一貫性」の
機能が重要である。参照一貫性は、異なる２テーブル或
いは同一テーブルの関連列間におけるデータ値の一貫性
を確実にする。テーブル列間に要求される関連は「参照
制約」として知られる。「従属テーブル」の「外部キー
」値が、「親テーブル」のいずれかの行の「基本キー」
値として存在する場合か或いは、外部キーが空である場
合に、従属テーブルの行は制約に間し参照一貫性を持つ
、換言すれば従属テーブルの各行は、夫々対応する親フ
ァイルの親竹を持たなければならない。従属性の外部キ
ーが親テーブルの基本キー値と対応しないと、参照制約
が侵害され、それらのテーブルを含むデータベースの参
照一貫性が失われる。参照制約を実施してデータベース
の参照一貫性を保持するには、常に外部キー値が対応す
る基本キー値を持つようなシステムが確立されなくては
ならない。参照一貫性の実施時にはまた、基本キー値は
必ず一意的でなくてはならない。この特性は「実体一貫
性」として知られている。参照一貫性については、Ｃ，
Ｊ、ディト著「データベース・システム入門（Ａｎ　Ｉ
ｎｔｒｏｄｕｃｔｉｏｎ　ｔｏ　ＤａｔａｂａｓｅＳｙ
ｓｔｅｍｓ　）　ｊ第３版、アディソンーウェズリー出
版社（１９８１年）に説明されている。

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

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

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

また別の従来技術では、上述の操作及び制約の検査の手
順が逆になるが、２回のバスを必要とする点では同様で
ある。この方式ではデータが操作されるまで制約は検査
されず、いずれかの制約が侵害された場合には全操作が
削除又は取消される。

ここでもまた数行にわたり操作及び制約の検査の段階が
別々に行なわれるため、処理時間が増大し、システム・
パフォーマンスに影響が出る。よって、データ内で単一
のパスのみを使用する参照制約実施方式が要求される。

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

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

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

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

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

Ｅ、実施例 Ｅ−１，用語 リレーショナル・データベース管理システムとは、参照
制約により関連付けられたテーブルの集合として表され
るデータを、記憶及び保持するコンピュータ・システム
である。第６図及び第２図は、６つの参照制約により関
連付けられた３つのテーブルを持つリレーショナル・デ
ータベース５を示す、ＤＥＰＡＲＴＭＥＮＴテーブル１
０は、ある企業の各部門を番号ＤＥＰＴＮＯ及び名称Ｄ
ＥＰＴＮＡＭＥにより記述し、責任者ＭＧＲＮＯ及び業
務報告を行なう上位部門の番号Ｐ　Ｄ　Ｍ　ＲＤＥＰＴ
を識別する。ＥＭＰＬＯＹＩＥＥテーブル１２は、全従
業員を従業員番号ＥＭＰＮＯにて識別して基礎的人事情
報をリストし、従業員所属部門ＷＯＲＫＤＥＰＴｔ識別
する。ＰＲＯＪＥＣＴテーブル１４は、この企業が現在
従事している各プロジェクトについて記述するもので、
プロジェクト番号ＰＲＯＪＮＯ、プロジェクト名ＰＲＯ
ＪＮＡＭＥ、担当従業員、担当部門及び日程をリストし
、個々のプロジェクトが属する主プロジェクトＭＡ、ｙ
ｐａｏ、ｙ＠識別する。該テーブルのサンプル・データ
を第３図から第５図に示す。

第６図のテーブルは第２図に示すごとく６つの参照制約
によって、自己を含む相互が関連付けられている。制約
Ｒ１１６によれば、ＤＥＰＡＲＴＭＥＮＴテーブル１０
の上位部門ＡＤＭＲＤＥＰＴは、ＤＥＰＡＲＴＭＥＮＴ
テーブルの有効な部門番号ＤＥＰＴＮＯである必要があ
る。よって制約Ｒ１１６の親テーブルはＤＥＰＡＲＴＭ
ＥＮＴであり、基本キーはＤＥＰＡＲＴＭＥＮＴテーブ
ルのＤＥＰＴＮＯ列、基本インデックスはＤＥＰＴＮＯ
インデックスである。制約Ｒ１１６の外部キーはＤＥＰ
ＡＲＴＭＥＮＴテーブル１０のＡＤＭＲＤＥＰＴ列であ
り、これによりＤＥ　ＰＡＲＴ　Ｍ　Ｅ　Ｎ　Ｔは親で
ありかつ従属テーブルとなる。

親及び従属テーブルが同一であるので、制約Ｒ１１６は
自己参照制約である。

制約Ｒ２１８によれば、ＥＭＰＬＯＹＥＥテーブル１２
（従属）の各従業員所属部門ＷＯＲＫＤＥＰＴ（外部キ
ー）は、ＤＥＰＡＲＴＭＥＮＴテーブル１０（親）の有
効な部門番号ＤＥＰＴＮＯ（基本キー）である必要があ
る。制約Ｒ３２０によれば、ＰＲＯＪＩＥＣＴテーブル
１４の担当部門ＲＥＳＰＤＥＰＴは、ＤＥＰＡＲＴＭＥ
ＮＴテーブル１０の有効な部門番号ＤＥＰＴＮＯである
必要がある。制約Ｒ４２２によれば、ＤＥＰＡＲＴＭＥ
ＮＴテーブル１０の部門責任者ＭＧｌ’ｔＮＯは、ＥＭ
ＰＬＯＹＥＥテーブル１２の有効な従業員番号ＥＭＰＮ
Ｏである必要がある。制約Ｒ５２４によれば、ＰＲＯＪ
ＥＣＴテーブル１４のプロジェクト担当従業員ＲＥＳＰ
ＥＭＰは、ＥＭＰＬＯＹＥＥテーブル１２の有効な従業
員番号ＥＭＰＮＯである必要がある。最後に制約Ｒ６２
６によれば、ＰＲＯＪＥＣＴテーブル１４の主プロジェ
クトＭＡＪ　ＰＲＯＪはそれ自身が、ＰＲＯＪＥＣＴテ
ーブル１４の有効なプロジェクト番号ＰＲＯＪＮＯであ
る必要がある。Ｒ６もまた自己参照制約である。

本記述に用いられる用語を要約すると、「行」はテーブ
ル内に存在しているとおりのレコードの外見上の形を言
い、「レコード」はデータベースに保管された行データ
の内部表現を指す。「親竹」は「親テーブル」の−行で
あり、１以上の従属行の外部キー値と対応する「基本キ
ー値」を持つ。

「従属行」は「従属テーブル」の−行であり、いくつか
の親竹の基本キー値と対応する「外部キー値」を持つ、
「自己参照制約」は同一テーブル内で定義された制約で
あり、すなわち外部キーが同一テーブルの基本キーを参
照する。自己参照テーブルには「自己参照行」が存在す
ることがあり、ここでは外部キーが同一行の基本キーと
対応する。

制約Ｒ１１６及びＲ６２６は共に自己参照である。「循
環」とは、その循環の中にあるテーブルがそれ自身の従
属テーブルとなるような制約の組である。制約Ｒ２１８
及びＲ４２２は循環を成す。循環内には行の循環が存在
することがあり、ある行がそれ自身の従属行となること
がある。

参照一貫性の支援にあたっては、自己参照制約及び循環
が特殊な問題をいくつか提起するが、これを解決するの
が本発明の特徴である。

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

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

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

レコードに影響を与える参照制約が識別されると、その
参照制約が実施される。正確には、挿入、更新、削除な
どの各操作により検査のアルプリズムが異なる。各アル
プリズムの詳細は下記に示す。

レコード操作と関連する参照制約が侵害されると、侵害
探知までに命令文或いはトランザクション中に実行され
た操作は、すべて取消し或いは「撤回」され、制約侵害
を示すエラー戻りコードがユーザや適用業務プログラム
に対して出される。

第１図は、本発明による前記実施例の流れ図であり、リ
レーショナル・データベース・テーブルを操作する３つ
の主なＳＱＬ指令−−ＩＮＳＥＲＴ、ＵＰＤＡＴＥ、Ｄ
ＥＬＥＴＥに対するレコード・レベルの制約の実施方式
を示す。

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

マツチするインデックス・キーが見つかると、外部キー
とマツチする基本キーを親テーブルの一行が持つことに
なり、参照制約が満たされる。以降この検査は、挿入レ
コードに関する各制約に対して繰り返される。

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

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

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

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

第１表 コードによる　　時　照制約 １０１ＤＯ挿入操作に含まれる各レコードに対し。

１０２　　テーブルにレコードを挿入。

１０３　　全インデックスにレコードを結合。

１０４１Ｆレコードがいずれかの関連記述子における従
属行ならばＴＨＥＮ。

ＤＯ該レコードが従属行である各関連記述子に対し。

レコードの外部キーを取り出す。

ＩＰ外部キーが空でなければＴＨＥＮ。

Ｄｏ、／＝マツチする基本キー＝／ ／＝の存在検査　　　　＝／ 親テーブルの基本キー・インデッ クスを調べ、基本キー＝外部キー であるインデックス項目を探す。

ＩＦ項目がなければＴＨＥＮ。

／＝基本キーが見つから＝／ ／＝ない場合　　　　　＝／ １１１Ｄ○、／＝参照制約侵害処理 ＝／ 外部キー・エラーを示す戻り コードをＳＥＴ。

ＧＯＴＯ共通の中断処理手順。

ＥＮＤ。

Ｅ　Ｌ　Ｓ　Ｅ／＝基本キーがあれば ＝／ ／＝エラー処理不要＝／ ＤＯ何もしない。

ＥＮＤ。

ＥＮＤ。

ＥＬＳＥ／＝外部キー空がならば＝／ ／＝制約検査不要　　　＝／ ＤＯ何もしない。

ＥＮＤ。

ＥＮＤ　　Ｄｏレコードが従属性である各関連記述子に
対して。

ＥＬＳＥ　　／＝ニレコード従属でなげ＝／／＝れば制
約検査不要　　＝／ Ｄｏ何もしない。

１２５　　　　　ＥＮＤ。

１２６ＥＮＤ　　Ｄｏ挿入操作に含まれる全レコードに
対して。

第１表の行番号１０１から１２６は、挿入指令や操作に
含まれる各レコードをテーブルに挿入するためのＤＯル
ープを成す。まず行番号１０２で、テーブルへの実際の
各レコード挿入を行なう。重要なのは、参照制約の検査
以前にレコード挿入が行なわれる点である。これにより
特別な処理やコードなしに、共通のアルゴリズムによっ
て自己参照行制約を実施できる。

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

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

レコードがいずれかの関連において従属であれば（行番
号１０４）、その関連により定義された制約を行番号１
０５から１２１において実施する。

行番号１０５から１２１は、新規挿入レコードについて
、レコードを含むテーブルが従属である各制約を実施す
るためのＤｏループである。挿入操作時に制約を実施す
るにあたり、挿入レコードの各外部キー値が、関連する
制約の親テーブルレコードの基本キー値とマツチする必
要がある。関連記述子が従属テーブルの外部キー列を識
別するので、行番号１０６において挿入レコードの外部
キーを取り出すことができる。

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

行番号１０８から１１８では、挿入レコードの外部キー
とマツチする基本キーを検査して単一挿入レコードの単
一参照制約を実施し、見つからなければ挿入操作を中断
する。関連記述子が親テーブルの基本キーインデックス
を識別するので、マツチする基本キーがもしあれば探索
できる。行番号１０９では、親テーブルの基本キーイン
デックスを調べて行番号１０６で取り出した外部キー値
とマツチする目的基本キー値を探索し、基本インデック
ス内の目的基本キー値存在を示す標識を返す。

基本キーが見つかれば参照制約は満たされ、エラー処理
コード（行番号１１１から１１４）はスキツブされて何
も行なわない（行番号１１６及び１１７）。

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

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

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

ｌＮ５ＥＲＴ　　　ＩＮＴＯＰＲＯＪＥＣＴＶＡＬＵＥ
Ｓ（’ＡＤ３１１０”　ＧＥＮＡＤ、ＳＹＳ’、　　’
Ｄ２１　　°、　　’００００７０’、、、、　　’Ａ
Ｄ３１００　′　） これは、第５図に示すＰＲＯＪＥＣＴテーブル１４に次
の行を追加するものである。

ＰＲＯＪＮＯＰＲＯＪＮＡＭＥ　　　ＲＥＳＰＤＥＰＴ
　ＲＥＳＰＥＭＰ　　、、、ＭＡＪＰＲＯＪＡＤ３１１
０　ＧＥＭ　ＡＤ　　ＳＹＳ　　０２１　　　　０００
０７０　　　　　ＡＤ３１００第１図に示すレコード・
レベル制約実施方式によれば、レコードは３０でＰＲＯ
ＪＥＣＴテーブル１４に挿入されてインデックスが結合
され、３２で参照制約Ｒ３２０、Ｒ５２４、Ｒ６２６が
順次検査される。

最初に、ＰＲＯＪＥＣＴテーブル１４（従属）に新規追
加されるレコードに対し制約Ｒ３２０が実施される。こ
の制約によれば新規挿入プロジェクト行の担当部門ＲＥ
ＳＰＤＥＰＴ（外部キー）は、ＤＥＰＡＲＴＭＥＮＴテ
ーブル１０（親）の有効な部門番号ＤＥＰＴＮＯ（基本
キー）を参照する必要がある。新規挿入レコードのＲＥ
ＳＰＤＥＰＴ列から外部キー値゛Ｄ２１°を取り出すこ
とにより実施が開始する。キー値は空でないので、基本
キーＤＥＰＴＮＯのインデックスを調べれば値“Ｄ２１
°に対する項目が探索される。新規挿入プロジェクトは
制約Ｒ３２０を満たし、参照侵害は存在しない。

次に参照制約Ｒ５２４が実施される。この制約によれば
、各プロジェクトの担当従業員ＲＥＳＰＥＭＰが有効で
ある必要がある。新規挿入レコードから外部キー値“０
０００７０°が取り出される。キー値は空（ヌル）でな
いので、Ｅ　Ｍ　Ｐ　Ｌ　０ＹＥＥテーブル１２の基本
インデックスＥＭＰＮＯを調べれば°００００７０′に
対する項目が探索される。この値は探知され、新規レコ
ードは制約Ｒ５２４を満たす。

最後に参照制約Ｒ６２６が実施される。この制約によれ
ば、各プロジェクトの主プロジェクトＭＡＪＰＲＯＪが
該プロジェクトに対し有効である必要がある。ＰＩ”ｔ
ＯＪＥｃＴテーブル１４に新規挿入されるレコードのＭ
ＡＪＰＲＯＪ列から、外部キー値’ＡＤ３１００°が取
り出される。キー値はヌルでないので、ＰＲＯ，ＪＥＣ
Ｔテーブル１４の基本インデックスＰＲＯＪＮＯを調べ
れば。

ＡＤ３１００°に対する項目が探索される。この項目は
探知され、制約Ｒ５２４が満たされる。

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

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

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

この記述子は従属テーブル及び外部キーインデックス（
あれば）を識別し、従属テーブルの外部キー値探索に用
いられることもある。

外部キーインデックスがあればそれを調べて、旧基本キ
ー値とマツチする外部キー値が探索される。なければ全
従属テーブルを調べて、旧基本キー値とマツチする外部
キー値が探索される。マツチする外部キー値が４２にお
いて見つかると参照制約は侵害され、それまでの操作に
より更新されたレコードは３６において撤回（中断）さ
れる。外部キーが見つからなければ参照制約は満たされ
る。

更新されるテーブルが親である各制約について、３８で
この処理が繰り返される。基本キー制約侵害が見つから
なければ、レコード及び影響を受けるインデックスは更
新される。

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

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

マツチする基本キー値が４６で見つからなければ、参照
制約は侵害され、それまでの操作により更新されたレコ
ードは３６において撤回（中断）される。外部キーが見
つからなければ参照制約は満たされる。更新されるテー
ブルが従属である各制約について、この処理が繰り返さ
れる。

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

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

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

第２表 擬似コードによる　新時参照制 ２０１ＤＯ更新操作に含まれる各レコードに対し。

／＝ニレコード新前に基本キー制約＝／／＝実施　　　
　　　　　　　　　＝／２０２　　　レコードから旧基
本キーを取り出す。

／＝基本キーはヌルであってはなら＝／／＝ない　　　
　　　　　　　　　＝／２０３ｒＦ基本キー列が変更さ
れるならばＴＨＥＮ。

Ｄｏレコードが親である各開運記述子 （すなわち制約）に対し。

／＝更新レコードが親であるような＝／／＝各制約を検
査する　　　　　　＝／ＩＦ開連の外部キーにインデッ
クスが 存在すればＴ　ＨＥＮ　。

インデックスを調べて、外部キー＝ 旧基本キーである最初のインデック ス項目を探す。

ＥＬＳＥ／＝外部キーにインデツ＝／ ／＝クスが存在しなければ ＝／ 従属テーブルを調べて、外部キー＝ 旧基本キーである最初のレコードを 探す。

１Ｆ外部キーが見つかったならばＴＨ ＥＮ。

／＝参照制約が侵害された ＝／ Ｄｏ９ 基本キー更新時のエラー発生を示 す戻りコードをＳＥＴ。

ＧＯＴＯこれまでに行なわれた更 新を撤回する共通の中断処理手順 へ。

ＥＮＤ。

ＥＬＳＥ／＝外部キーが見つからない ＝／ ／＝それまでに制約侵害なし ＝／ Ｄｏ何もしない。

ＥＮＤ。

ＥＮＤ　　Ｄｏ更新レコードが親である各開運記述子に
対し。

ＥＬＳＥ　　　／＝基本キーが変更されない＝／ ／＝基本キー制約検査が＝／ ／＝要求されない　　　＝／ Ｄｏ何もしない。

ＥＮＤ。

／＝基本キー制約実施終了 ＝／ ／＝ニレコード新　　　＝／ レコードの新規値に影響を受ける全インデックスを更新
。

レコードを新規値により更新。

／＝外部キー制約実施　＝／ ＩＦ外部キー列が変更されていればＴＨＥＮ。

Ｄｏレコードが従属である各開運記述子（すなわち制約
）に対し。

１Ｆ関連の外部キーが変更されていれ ばＴＨＥＮ。

Ｄｏ、／＝制約実施　　　　　＝／ 新規外部キー値を取り出す。

ＩＦ新規外部キー値が空でなければ ＴＨＥＮ。

ＤＯｏ ／＝マツチする基本キー＝／ ／＝があるかどうか検査＝／ ／＝する　　　　　　　＝／ 親テーブルの基本キーインデッ クスを調べて、基本キー値＝新 規外部キー値であるインデック ス項目を探す。

１Ｆ項目が存在しなければＴＨ ＥＮ。

ＤＯｏ 外部キー更新時のエラー発 生を示す戻りコードをＳＥ Ｔ。

ＧＯＴＯ全更新操作を撤回 する共通の中断処理手順へ。

ＥＮＤ。

Ｅ　Ｌ　Ｓ　Ｅ／＝マツチする基＝／ ／＝本キーが見つ＝／ ／＝かった　　　＝／ ＤＯ何もしない。

ＥＮＤ。

ＥＮＤ。

ＥＮＤ、　　　／＝基本キー値と＝／ ／＝のマツチング＝／ ／＝検査終了　　＝／ ２４１　　　　ＥＬＳＥ　　　　／＝新規外部キー＝／
／＝がヌル　　　＝／ ２４２　　　　　　Ｄ　Ｏ何もしない。

２４３　　　　　　Ｅ　Ｎ　Ｄ ２４４　　　ＥＮＤ　　Ｄｏレコードが従属である各関
連記述子に対し。

２４５　　ＥＬＳＥ　　　　　／＝外部キーが変更＝／
／＝されない　　　＝／ ２４６　　　　Ｄｏ何もしない。

２４７　　　ＥＮＤ、　　　　／＝新規外部キー値＝／
／＝制約実施の終了＝／ ２４８ＥＮＤ　　Ｄｏ更新動作を行なう全レコードに対
し。

第２表の行番号２０１がら２４８は、更新オペレーショ
ンにより操作される各レコードを順次制約検査及び更新
するための、外側のＤｏループを成す。このループは異
なる３つのセクションを持つ。（１）基本キー値更新時
の親制約検査４０及び４２（行番号２０２から２２０）
、（２）制約侵害がない場合のレコード及びインデック
ス更新４８（行番号２２１及び２２２）、（３）外部キ
ー値更新時の従属制約検査４４及び４６（行番号２２３
から２４７）である。

巳−５，基本キー更新時の制約実施 各テーブルは１つの基本キーしか持たないので、日基本
キー値は参照制約実施以前に取り出される（行番号２０
２）。

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

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

行番号２０９で、インデックス探索（行番号２０６）或
いはテーブル探索（行番号２０８）の結果を調べ、マツ
チする外部キーがあるか判断する。

マツチする外部キーがあれば（行番号２１０）、そのレ
コードの基本キー更新は参照制約実施を侵害することに
なり、行番号２１０から２１３を実行してエラーを識別
し、それ以前に実行済の更新操作（もしあれば）を中断
（撤回）する。行番号２１１で、基本キー更新中の参照
制約侵害エラーを識別する、更新操作からの戻りコード
をセットする。行番号２１２で共通の中断処理手順を開
始し、これ以前に完了した更新を撤回する。こうして更
新操作によってレコードに生じた参照制約エラーを探知
すると、全更新作業が不成功に終わる。

一方マッチする外部キーが見つからなければ（行番号２
１４）、基本キー参照制約は満たされて処理は不要とな
る（行番号２１５及び２１６）。

ここで内側のＤｏループ（行番号２０３から２１７）を
繰り返し、現在の関連記述子を調べて同−親テーブルに
関するさらに別の開運記述子がある（すなわち他に実施
すべき参照制約がある）かどうか判断する。この内側ル
ープは、基本キー値の全制約が実施されるか、侵害が探
知されるまで繰り返す。基本制約侵害が探知されなけれ
ば、処理は行番号２２１及び２２２へ続く。

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

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

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

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

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

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

行番号２３１でマツチする基本キーがあるかどうか判断
する。もしあれば（行番号２３６）、参照制約は満たさ
れ、次の制約実施へ進む（行番号２３７及び２３８）。

もし基本キーインデックス内に基本キーが見つからない
、すなわち存在しないならば（行番号２３１）、参照制
約エラーとなり、上記（行番号２１０から２１３）同様
のエラー処理手順（行番号２３２から２３５）が実行さ
れる。前述同様に、参照制約侵害が探知された時点で更
新作業は撤回される。

行番号２３６から２３８（基本キーが見つかり参照制約
が満たされた）又は行番号２４１から２４３（新規外部
キー値がヌル）実行後、再び内側のＤｏループ（行番号
２２４から２４４）に入る。

ここで現在の関連記述子を調べて、関連記述子が次にあ
るか判断する。このループは、全従属制約が満たされる
か或いは侵害が探知されるまで繰り返す。

全部の親（行番号２０２から２２０）及び従属（行番号
２２３から２４７）参照制約を検査し終わると、更新操
作を行なう各レコードについて外側のＤｏループ（行番
号２０１から２４８）を繰り返す。全更新レコードが各
々の参照制約を満たすと、更新作業は完了となる。

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

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

ＵＰＤＡＴＥ　　　ＰＲＯＪＥＣＴ　　　ＳＥＴ　　　
ＰＲＯＪＮＯ＝’０Ｐ２０１５’　　　ＷＨＥＲＥ　　
　ＰＲＯＪＮＯ＝’０Ｐ２０１２’ これは、プロジェクト番号’　０Ｐ２０１２°である行
を新規プロジェクト番号“０Ｐ２０１５°に変更するも
のである。前述したように、プロジェクト番号ＰＦｔＯ
ＪＮＯは参照制約Ｒ６２６の基本キーである。旧基本キ
ー値である°０Ｐ２０１２“に従属する行は存在しない
ので、この更新作業は成功裡に終了する。

この更新操作についての制約は次のごと〈実施される。

まず０Ｐ２０１２′のプロジェクト番号を持つレコード
をＰＲＯＪＥＣＴテーブル１４より探して、旧基本キー
値’０Ｐ２０１２’を取り出す（行番号２０４）。次に
、ＰＲＯＪＥＣＴテーブル１４のＭＡＪＰＲＯＪ列にイ
ンデックスがないので（行番号２０５　）ＰＲＯＪＥＣ
Ｔテーブル１４を調べて、外部キーＭＡＪＰＲＯＪ、と
マツチする値を持つレコードを探す（行番号２０８）。

ＰＲＯＪＥＣＴテーブル１４には、更新レコードの旧基
本キー値’０Ｐ２０１２°と等しいＭＡＪＰＲＯＪの値
がない（行番号２１４から２１６）ので、制約Ｒ６２６
は満たされてレコードが更新される（行番号２５１）。

更新される外部キーがないので、操作は完了する。

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

ＵＰＤＡＴＥ　　　ＤＥＰＡＲＴＭＥＮＴ　　　５ＥＴ
ＤＥＰＴＮＯ＝’Ｄ１１　　°　　ＷＨＥＲＥ　　　Ｄ
ＥＰＴＮＯ＝　“　Ｄ２１　　“ これは、部門番号°Ｄ２１“である行を部門番号’Ｄｌ
ｌ’に更新するものである。ところが部門番号ＤＥＰＴ
ＮＯは３つの制約（Ｒ１、Ｒ２、Ｒ３）の基本キーであ
り、制約Ｒ２及びＥＭＰＬＯＹＥＥテーブル１２に影響
する参照制約侵害が起こる。従って更新は不成功に終わ
る。

まず、更新されるレコードはＤＥＰＡＲＴＭＥＮＴテー
ブル１０にある。制約は順不同に実施されるが、この例
では各部門の担当プロジェクトに関係する制約Ｒ３２０
が最初に実施される。レコードから旧基本キー値°Ｄ２
１“を取り出す（行番号２０４）ことにより制約検査が
開始する。

次にＰＲＯＪＥＣＴテーブル１４を調べて（行番号２０
８）、担当部門ＲＥＳＰＤＥＰＴ（外部キー）が部門レ
コードの旧基本キー値°Ｄ２１゜と等しいレコードを探
す。該レコードがないので（行番号２１４）、この更新
は制約Ｒ３２０を満たす。

従業員の所属部門に関係する制約Ｒ２１８の実施では、
ＥＭＰＬＯＹＥＥテーブル１２を調べて（行番号２０８
）、旧基本キー値°Ｄ２１°と等しい従業員所属部門Ｗ
ＯＲＫＤＥＰＴ（外部キー）を持つ従業員レコードを探
す。従業員番号ＥＭＰＮＯが°００００７０°であるレ
コードが該当する（行番号２０９）。旧基本キー値と等
しい外部キー値を持つレコードが存在するので参照制約
侵害となり、行番号２１０から２１３を実行して更新は
中断する。操作が中断するので、制約Ｒ１１６の検査は
実施されない。

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

ＵＰＤＡＴＥ　　　ＥＭＰＬＯＹＥＥ　　　ＳＥＴ　　
　ＷＯＲＫＤＥＰＴ＝　“Ｅ３１’　　　ＷＨＥＲＥ　
　　ＥＭＰＮＯ＝’　　０００３２０　　’ これは、従業員番号ＥＭＰＮＯが０００３２０であるＥ
ＭＰＬＯＹＥＥテーブル１２のレコードの部門番号ＷＯ
ＲＫＤＥＰＴを′Ｅ２１°から°Ｅ３１°に変更するも
のである。この更新によって影響を受ける外部キーはＷ
ＯＲＫＤＥＰＴのみであるので、制約Ｒ４２２だけが実
施される。

参照制約エラーが起こるので更新は不成功に終わる。

ＥＭＰＬＯＹＥＥテーブル１２で従業員番号ＥＭＰＮＯ
が°０００３２０°であるレコードが見つかる。基本キ
ーが変更されないのでレコードは更新される（行番号２
２１及び２２２）。外部キーＷＯＲＫＤＥＰＴが変更さ
れたので（行番号２２３）、新規外部キー値″Ｅ３１°
を取り出す（行番号２２７）。新規外部キー値がヌルで
ないので（行番号２２８）、基本キーインデックスを調
べて新規外部キー値とマツチする親テーブルＤＥＰＡＦ
ｔＴＭＥＮＴテーブル１０内の基本キー値を探す。ＤＥ
ＰＡＲＴＭＥＮＴテーブル１０には部門番号ＤＥＰＴＮ
Ｏが°Ｅ３１°であるレコードが存在しないので（行番
号２３１）、制約Ｒ４２２は侵害され、操作は中断して
更新作業が撤回される（行番号２３２から２３５）。

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

削除規則には３種類ある。ＤＥＬＥＴＥ　　ＲＥＳＴＲ
ＩＣＴ（限定削除）、ＤＥＬＥＴＥ　　ＳＥＴ　　ＮＵ
ＬＬ（セット・ヌル削除）、ＤＥＬＥＴＥ　　ＣＡＳＣ
ＡＤＥ（カスケード削除）である。

ＤＥＬＥＴＥ　ＲＥＳＴＲＩＣＴ規則の元では、マツチ
する外部キーが存在する場合基本キーは削除されず、基
本キー更新時と同様の方法で制約実施が行なわれる。マ
ツチする外部キーが見つかると制約侵害となり、操作は
中断及び撤回される。

マツチする外部キーが見つからなければレコードの制約
は満たされ、レコード削除が完了する。

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

ＤＥＬＥＴＥ　　ＣＡＳＣＡＤＥはＤＥＬＥＴＥＳＥＴ
　　ＮＵＬＬと似ているが、外部キー値をヌルにセット
するのではなく、マツチする旧外部キー値を含む全レコ
ードを従属テーブルから削除する。この削除は従属テー
ブルからその従属テーブル（削除レコードのテーブルを
親に持つテーブル）へ「カスケード」され、「カスケー
ド削除」として知られる従属レコード削除が行なわれる
。

削除レコードの従属テーブルのテーブル（レコード・タ
イプ）記述子を検査して、それが他の参照制約中の親テ
ーブルかどうか判断する。もしそうであればカスケード
削除されたレコードが親として扱われる、新規の削除制
約実施が開始され、その削除規則（ＲＥ、５ＴＲＩＣＴ
、ＳＥＴ　　ＮＵＬＬ、ＣＡＳＣＡＤＥのいずれか）が
実施される。

この削除規則もＤＥＬＥＴＥ　　ＣＡＳＣＡＤＥならば
上述の処理を繰り返す。そうでなければＤＥＬＥＴＥ　
　ＳＥＴ　　ＮＵＬＬ又はＤＥＬ巳ＴＥＲＥＳＴＲＩＣ
Ｔを実行する。ＤＥＬＥＴＥ　　ＣＡＳＣＡＤＥはすな
わち、レコード削除がなされる親テーブルに結合する全
従属テーブルに波及する、再帰操作である。実行中にＤ
ＥＬＥＴＥ　　ＲＥＳＴＩ”（ＩＣＴエラーが起こると
、カスケード削除を含む全削除操作が撤回されるや 挿入及び更新のルーチン同様、削除のルーチンもブロッ
ク５０に示すように、削除操作をレコード毎に行なって
処理する。第１図にあるように削除のアルゴリズムは、
自己参照行及び循環性を処理するため５２でまずレコー
ド削除を行ない、その後５４と５６で制約検査を行なう
。これにより確実に、−度にルコードが従属探索時に見
つかるようにする。５８でカスケード削除が行なわれる
と、経路６０の再帰的制御により削除ルーチンに戻る。

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

第３表 擬　コードによる削除時参照制約実施 ３０１ＤＯ削除操作時に削除される全レコードに対し。

ＣＡＳＣＡＤＥ：／＝カスケード削除＝／／；中におけ
る次の＝／ ／＝従属レコードを＝／ ／；削除するための＝／ ／＝再帰的エントリ＝／ レコードと全インデックスを切断する。

ＩＦレコードがいずれかの関連において従属ならばＴＨ
ＥＮ。

レコードから旧基本キー値を取り出し、後に外部キー値
と比較するため保管する。

テーブルからレコードを削除する。

ＩＦレコードがいずれかの関連において親ならばＴＨＥ
Ｎ。

Ｄｏレコードが親である各開運に対し。

ＩＦ外部キーにインデックスがあれば ＴＨＥＮ。

インデックスを調べて、開運につい て外部キー＝旧基本キーである最初 のレコードを探す。

Ｅ　Ｌ　Ｓ　Ｅ／＝外部キーにインデッ＝／／＝クスが
ない　　　　＝／ 従属テーブルを調べて、関連につい て外部キー＝旧基本キーである最初 のレコードを探す。

ＩＦマツチする外部キーが見つかれば Ｔ　ＨＥ　Ｎ　。

ＤＯ，／＝制約実施　　　　　＝／ ＩＦ削除規則がＲＥＳＴＲＩＣＴ ならばＴＨＥＮ。

ＤＯ，／＝参照制約エラー処理 ＝／ ＲＥＳＴＲ［ＣＴ削除規則エ ラーを示す戻りコードＳＥＴ。

ＧＯＴＯ共通の中断処理手順 へ。

ＥＮＤ。

ＥＬＳＥ／＝削除規則が　　＝／ ／＝ＣＡＳＣＡＤＥ＝／ ／＝又はＳＥＴ　　　＝／ ／＝ＮＵＬＬ　　　　＝／ Ｄｏ　　［ＪＮＴＩＬ外部キーがも う見つからなくなるまで。

／＝この関連内金従＝／ ／＝属に対しカス　＝／ ／＝ケート削除又は＝／ ／＝上セツトヌル　＝／ ＩＦ削除規則がＣＡＳＣＡＤ ＥならばＴＨＥＮ。

ＣＡＳＣＡＤＥをＣＡＬＬ。

／＝該従属レし−ド＝／ ／＝及びその従属を＝／ ／＝再起的に削除　＝／ ＥＬＳＥ／＝削除規則　＝／ ／＝ＳＥＴ　　　＝／ ／＝ＮＵＬＬ　　＝／ 外部キーの可能な値を全て ヌルにＳＥＴする。

外部キーインデックス又は従 属テーブルを調べて、関連に ついて外部キー＝旧基本キー である次のレコードを探す。

ＥＮＤ　　Ｄｏ外部キーがもう見 つからなければ。

ＥＮＤ　　ＤＯ，／＝制約実施終了 ＝／ ＥＬＳＥ　　　／＝開関連に従属が；／／＝存在しない
　　＝／ ＤＯ何もしない。

ＥＮＤ。

ＥＮＤ　　ＤＯレコードが親である各関連に対し、／＝
基本キーの全　＝／ ／＝制約検査終了　＝／ ＥＬＳＥ　　　／＝ニレコード親でない＝／／＝ので制
約検査不要　＝／ ＤＯ何もしない。

ＥＮＤ。

３３６ＥＮＤ　　Ｄｏ削除操作時に削除される全レコー
ドに対し。

第３表の擬似コードにおいて行番号３０１がら３３６は
、テーブル内の削除指定された全レコードを削除するた
めの、外側のＤｏループを成す。

行番号３０２は削除手順への再帰進入点である。

これをｒＣＡＳ　ＣＡＤＥＪと呼び、削除レコードの従
属に対してＣＡＳＣＡＤＥ　　ＤＥＬＥＴＥ規則を実施
するのに用いる。このｒｃＡｓｃＡＤＥ、、、１再進入
点については、行番号３２３に関連して後に述べる。

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

行番号３０４で、テーブルのレコード・タイプを調べて
、テーブルがいずれかの関連（参照制約）において親で
あるかどうか判断する。もしそうならば行番号３０５で
旧基本キー値をレコードより取り出し、マツチする外部
キーを後に探索するためこの値を保管する（行番号３０
９から３１２）。

各テーブルは基本キーを１つしか持たないので、取り出
しは、各開運に対してではなく一度のみ行なわれよう。

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

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

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

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

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

マツチする外部キーが見つかると（行番号３１３）、該
従属レコードを行番号３１４から３２８にある制約の削
除規則により処理する０行番号３１５で関連記述子を検
査して、削除規則がＲＥＳＴＲ■ＣＴかどうか判断する
。もしそうならば行番号３１３で見つかった外部キーが
参照制約エラーを起こすので、行番号３１６から３１９
を実行してエラー戻りコードをセットし、全削除操作は
中断（撤回）する。行番号３１８でコールされる一般の
中断処理手順により、行番号３０６で行なわれようとし
たレコード削除のみならず、それ以前に削除手順により
行なわれたレコード削除も撤回される。また中断処理に
より、削除レコードの参照制約実施の一環として以前に
行なわれた、カスケード削除及びセット・ヌル削除も撤
回される。

こうして、参照制約エラーが起こると全削除操作が撤回
されて、処理は不成功に終わる。

削除規則がＣＡＳＣＡＤＥかＳＥＴ　　ＮＵＬＬならば
（行番号３２０）、行番号３２１がら３２７で削除コー
ドの従属が処理される。この場合、削除レコードの旧基
本キー値とマツチする全外部キーを探索し、削除規則に
従って処理しなければならない。行番号３２１がら３２
７のＤｏループがこれを行なう。行３２２は削除ルール
がＣＡＳＣＡＤＨか否かをテストする。もしそうであれ
ば、行番号３２３が実行される。行番号３２３は削除処
理全体（行番号３０３から３２５）を行番号３０２のｒ
ＣＡＳＣＡＤＥ　：　Ｊ再進入点により再帰的に呼び出
し、探索された従属レコードを削除して、そのレコード
削除の参照制約を実施する。

一方最初に削除されるレコードの削除規則がＳＥＴ　　
ＮＵＬＬならば（行番号３２４）、探索された従属レコ
ードの外部キー列のうち、可能な値を全てヌルにセット
して（行番号３２５）削除レコードのＳＥＴ　　ＮＵＬ
Ｌ削除規則を実施する。

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

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

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

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

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

ＤＥＬＥＴＥ　　　ＦＲＯＭ　　　ＥＭＰＬＯＹＥＥ、
　　ＷＨＥＲＥ　　　ＥＭＰＮＯ＝’０ＯＯ０７０′こ
れは、従業員番号が°００００７０°である行をＥＭＰ
ＬＯＹＥＥテーブル１２から削除するものである。ＥＭ
ＰＬＯＹＥＥテーブル１２は、実施すべき２つの制約、
Ｒ４２２及びＲ５２４の親テーブルである。実施を開始
すると、ＥＭＰＬＯＹＥＥテーブル１２内で従業員番号
ＥＭＰＮＯが’００００７０°であるレコードを探し、
該レコードをＥＭＰＬＯＹＥＥテーブルのインデックス
と切断しく行番号３０３）、旧基本キー値゛００００７
０°を取り出して保管する（行番号３０５）。その後レ
コードを削除しく行番号３０６）、開運する制約を順不
同に実施する。

ＰＲＯＪＥＣＴテーブル１４から、旧基本キー値’００
００７０°と等しい外部キー値ＲＥＳＰＥＭＰを持つ最
初のレコードを探索して１、制約Ｒ５２４を実施する（
行番号３０９から３１２）、該レコードが存在しないの
で（行番号３１３及び３２９）、削除規則ＲＥＳＴＲＩ
ＣＴが支持されてこの削除についての制約Ｒ５２４は満
たされる。故に内側のＤｏループ（行番号３０８から３
３２）は、次の制約Ｒ４２２について繰り返す。

ＤＥＰＡＲＴＭＥＮＴテーブル１０から、旧基本キー値
’００００７０“と等しい外部キー値ＭＧＲＮＯを持つ
最初のレコードを探して、制約Ｒ４２２ｔ’実施する（
行番号３０９から３１２）。部門番号ＤＥＰＴＮＯがＤ
２１°であるレコードが探索される（行番号３１３）。

制約Ｒ４２２に対する削除規則はＳＥＴ　　ＮＵＬＬな
ので（行番号３２０）、該従属レコードの部門責任者Ｍ
ＧＲＮＯを゛ヌル°にセットする。ヌルにセットすべき
マツチする外部キー値は他にないので（行番号３２１か
ら３２８のＤｏループ）、制約Ｒ４２２は満たされる。

適用される全制約が満たされたので、内側のＤＯループ
（行番号３０８から３３２）は繰り返さない。

最後にＥＭＰＬＯＹＥＥテーブル１２内に、従業員番号
ＥＭＰＮＯが°００００７０°であるレコードがもうな
ければ（行番号３０１から３３６の外側Ｄｏループ）、
制約Ｒ４２２実施は終了して削除作業が成功裡に終わる
。

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

ＤＥＬＥＴＥ　　　ＦＲＯＭ　　　ＰＲＯＪＥＣＴ　　
　ＷＨＥＲＥ　　　ＰＲＯＪＮＯ＝’０Ｐ２０００　　
。

これは、プロジェクト番号’０Ｐ２０００°を持つ行を
ＰＲＯＪＥＣＴテーブル１４から削除するものである。

まず外側のＤｏループ（行番号３０１から３３６）に入
り、プロジェクト番号ＰＲＯＪＮＯが°０Ｐ２０００　
’である最初（かつ唯一）のレコードを削除する。

’０Ｐ２０００°のレコードは初めに削除ルーチン（行
番号３０３から３３２）に入る。レコードを探索し、、
ＰＲＯＪＥＣＴテーブル１４のインデックスと切断する
（行番号３０３）、ＰＲＯＪＥＣＴテーブル１４はある
関連において親であるので（行番号３０４）、レコード
の旧基本キー値’０Ｐ２０００°を取り出して保管する
（行番号３０５）。その後レコードを削除する（行番号
３０６）。

自己参照制約Ｒ６２６は内側のＤｏループ（行番号３０
８から３３２）に入り、旧基本キー値’０Ｐ２０００°
と等しい外部キー値ＭＡＪ　ＰＲＯＪを持つ最初のレコ
ードをＰＲＯＪＥＣＴテーブル１４から識別する（行番
号３０９から３１２）。プロジェクト番号ＰＲＯＪＮＯ
が°０Ｐ２０１０°であるレコードを探索しく行番号３
１３）、削除規則ＣＡＳＣＡＤＨが実施する（行番号３
２０から３２８）。ＰＲＯＪＮＯが°０Ｐ２０１０°の
レコードは最も内側のＤｏループ（行番号３２１から３
２８）に入り、ＣＡＳＣＡＤＥ進入点（行番号３０２）
を用いて削除ルーチンに再帰再進入し、削除及び該レコ
ードの制約実施を行なう。

この削除ルーチンへの二度目の再進入時に、’０Ｐ２０
１０’のレコードをインデックスと切断しく行番号３０
３）、旧基本キー値’０Ｐ２０１０°を取り出して保管
しく行番号３０５）、レコードを削除しく行番号３０６
）、レコード削除制約を実施するため内側のＤｏ小ルー
プ行番号３０８から３３２）に入る。ＰＲＯＪＥＣＴテ
ーブル１４から外部キー値ＭＡＪＰＲＯＪが０Ｐ２０１
０′（旧基本キー値は削除された）である最初のレコー
ドを探して、制約Ｒ６２６を実施する。

ＰＦｔＯＪＮＯが°０Ｐ２０１２°であるレコードが探
索される。制約Ｒ６２６に対する削除規則はＣＡＳＣＡ
ＤＥなので、ＰＲＯＪＮＯが°ｏｐ２０１２’のレコー
ドは最も内側のＤｏ小ループ行番号３２１から３２８）
に入り、ＣＡＳＣＡＤＨ進入点（行番号３０２）を用い
て削除ルーチンに再帰再進入し、削除及び該レコードの
制約実施を行なう。

削除ルーチンへの三度目の進入時に、０Ｐ２０１２°の
レコードをインデックスと切断しく行番号３０３）、旧
基本キー値’０Ｐ２０１２°を取り出して保管しく行番
号３０５）、レコードを削除しく行番号３０６）、レコ
ード削除制約を実施するため内側のＤＯループ（行番号
３０８から３３２）に入る。ＰＲＯＪＥＣＴテーブル１
４から外部キー値ＭＡＪＰＲＯＪが０Ｐ２０１２゜（旧
基本キー値は削除された）である最初のレコードを探し
て（行番号３０９から３１２Ｌ制約Ｒ６２６を実施する
。該レコードが見つからないので（行番号３２９）、プ
ロジェクト番号ＰＲＯＪＮＯが“０Ｐ２０１２°の削除
についての制約Ｒ６２６は満たされる。この削除に関し
他の制約はない（行番号３３２）。こうして削除ルーチ
ン三度目の進入は終了し、行番号３２３で三度目の進入
がコールされた（呼び込まれた）箇所の直前の、二度目
の進入の制御へ戻る。

行番号３２６で削除ルーチン二度目の呼込みへ戻り、Ｐ
ＲＯＪＥＣＴテーブル１４を調べて外部キー値ＭＡＪＰ
ＲＱＪが°０Ｐ２０１０°であるレコードが他にないか
探す。該レコードがないので、制約Ｒ６２６は満たされ
る。プロジェクト番号ＰＲＯＪＮＯが°０Ｐ２０１０°
の削除についての制約Ｒ６２６は満たされる。この削除
に闇し実施すべき他の制約はない（行番号３３２）。

こうして削除ルーチン二度目の進入は終了し、行番号３
２３の後の、削除ルーチン最初の呼込みへ制御は戻る。

行番号３２６で削除ルーチン最初の呼込みが再開し、Ｐ
ＲＯＪＥＣＴテーブル１４から外部キー値ＭＡＪ　ＰＲ
ＯＪが°０Ｐ２０００　’である次のレコードを探す。

該レコードは見つからない。故にプロジェクト番号’０
Ｐ２０００°削除についての制約Ｒ６２６は満たされる
。適用される制約が他にないので、全削除操作は成功裡
に終わる。

第３かつ最後の実施例では、２つのＤＥＬＥＴＥ　　Ｓ
ＥＴ　　ＮＵＬＬ制約は満たされるが、ＤＥＬＥＴＥ　
　ＣＡＳＣＡＤＥ制約の侵害により操作が中断・撤回さ
れる複雑な削除を示す。次のＳＱＬ命令文を見ていただ
きたい。

ＤＥＬＥＴＥ　　　ＦＲＯＭ　　ＤＥＰＡＲＴＭＥＮＴ
ＷＨＥＲＥ　　　ＤＥＰＴＮＯ＝’ＡＯＯ。

これは、部門番号ＤＥＰＴＮＯがＡＯＯ°である行をＤ
ＢＰＡＲＴＭＥＮＴテーブル１０から削除するものであ
る。制約Ｒ１１６、Ｒ２１８、Ｒ３２０はＤＥＰＡＲＴ
ＭＥＮＴテーブル１０を親テーブルに持つ。

操作開始後外側のＤｏ小ループ行番号３０１から３３６
）に入り、°Ａ００°を持つＤＥＰＡＲＴＭＥＮＴレコ
ードを探す。“ＡＯＯ’レコードをインデックスと切断
しく行番号３０３）、旧基本キー値゛Ａ００“を取り出
して保管しく行番号３０５）、レコードを削除しく行番
号３０６）、レコード削除についての３つの制約を実施
するため内側のＤｏ小ループ行番号３０８から３３２）
に入る。

制約Ｒ３２０を実施して、ＰＲＯＪＥＣＴテーブル１４
から外部キーＲＢＳＰＤＥＰＴの値がＡ００′である最
初のレコードを探す（行番号３０９から３１２）。該レ
コードがないので、この削除についての制約Ｒ３２０は
支持され、次の制約Ｒ２について内側のＤｏループを繰
り返す。

ＤＥＰＡＲＴＭＥＮＴレコード“ＡＯＯｏについての制
約Ｒ２１８を実施して、ＥＭＰＬＯＹＥＥテーブル１２
から外部キーＷＯＲＫＤＥＰＴの値が°ＡＯＯ°である
最初のレコードを探す（行番号３０９から３１２）。従
業員番号ＥＭＰＮＯが００００１０’であるレコードが
見つかる（行番号３１３）。制約Ｒ２１８に対する削除
規則はＳＥＴ　　ＮＵＬＬなので（行番号３２０）、従
業員番号’００００１０′のｗｏＲＫＤＥＰＴをヌルに
セットする（行番号３２５）。ＷＯＲＫＤＥＰＴの値が
°Ａ００゛であるＥＭＰＬＯＹＥＥレコードが他にない
ので、最も内側のＤＯループ（行番号３２１がら３２８
）を出て、部門番号°Ａ００°削除についての制約Ｒ２
１８は満たされ、最後の制約Ｒ１１６について内側のＤ
ｏループを繰り返す。

部門番号“ＡＯＯ’削除についての制約Ｒ１１６実施を
開始して、ＤＥＰＡＲＴＭＥＮＴテーブル１０から外部
キーＡＤＭＲＤＥＰＴの値が’ＡＯＯ’である最初のレ
コードを探す。自己参照行°Ａ００°はまた外部キー’
ＡＯＯ’も持つが、該レコードはすでに削除されている
ため（行番号３０６）ここでは見つからない。しかし部
門番号ＤＥＰＴＮＯがＤ０１°であるレコードが見つか
る。制約Ｒ１１６に対する削除規則はＣＡＳＣＡＤＥで
あるノテ、ＣＡＳＣＡＤＨ進入点（行番号３０２）にお
いて削除ルーチンに再帰進入しく行番号３２３）、部門
’Ｄ０１°のカスケード削除処理を行なう。

二度目の削除ルーチンに入り、部門’ＤＯＩ’の再帰的
削除を開始してレコードをＤＥＰＡＲＴＭＥＮＴテーブ
ルのインデックスと切断し、レコードの旧基本キー値“
Ｄｏｌｏを取り出して保管し、レコードを削除する（行
番号３０３がら３０６）。

部門’ＤＯＩ°削除についての制約Ｒ３２０を実施する
（行番号３０８から３３２）。外部キーＲＥＳＰＤＥＰ
Ｔの値が°ＤＯ１”である最初のレコードをＰＲＯＪＥ
ＣＴテーブル１４がら探索し、プロジェクト番号ＰＲＯ
ＪＮＯが“ＭＡ２１００“であるレコードが見つかる（
行番号３０９から３１３）。制約Ｒ３２０に対する削除
規則はＲＥＳＴＲＴＣＴであるので（行番号３１５）、
プロジェクト番号ＰＲＯＪＮＯが°ＭＡ２１００’であ
るレコードの存在がエラーを起こす。

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

Ｅ−１０，レコード・レベル制約実施による操作の制限 ある操作によりレコードが処理される順序が、関連操作
結果に影響してはならない、というのはリレーショナル
・データベース理論の原則である。

本発明による方式ではレコード・レベルで制約実施を行
なうので、複数行の関連操作時に全体として、処理の順
序が関連制約操作結果に影響する場合がある。例えば、
自己参照制約の削除規則がＲＥＳＴＲＩＣＴであった場
合、複数行操作時のレコード・アクセスの順序が結果に
影響する。

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

（１）　　自己参照制約の削除規則はＣＡＳＣＡＤＨで
あること。

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

（３）副照会を伴う削除操作時に、副照会で参照される
テーブルが、（ＣＡＳＣＡＤＥ又はＳＥＴ　　ＮＵＬＬ
を通じ）削除レコードを含むテーブルにより影響されて
はならない。

本制限は、副照会を含む削除に関するリレーショナル・
データベース理論における従来規則の拡張である。それ
は削除の対象テーブルは副照会中で参照されてはならな
い、というものである。

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

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

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

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

本発明を要約すると、３つの基本操作（ＩＮＳＥＲＴ、
ＵＰＤＡＴＥ、ＤＥＬＥＴＥ）いずれにおいても参照制
約は、個々のレコード操作時に実施されるということで
ある。制約実施は、適用業務プログラム及びデータへの
アクセス・パスと間係なく行なわれる。制約がデータ更
新操作そのものと一体的に実施されるので、パフォーマ
ンス・コストは従来技術による方式（データ操作及び制
約実施に２つのパスを必要とした）と比べ、最少限で済
む。操作のタイプが異なる毎にデータ操作及び制約実施
が行なわれる順序を適正に選択することにより、自己参
照行及び循環性が自動的に処理される。挿入及び削除時
には、各レコードはまず挿入又は削除され、次に制約が
実施される。エラーが探知されると、データ操作は撤回
される。

本方式は制約は大抵の場合支持される、という「楽天的
」な見方をしている（成功に関して最適化されている）
。更新時には、基本キー制約がまず実施され、次にレコ
ードが更新され、最後に更新された外部キーの制約が実
施される。

特定の実施例について述べてきたが、その他の例につい
ても本発明により実行受きる旨理解されよう。制約要素
の定義がレコード・レベル操作時にアクセスできる壱の
であればよい為、例えば外部カタログなど他の方法によ
っても、参照制約を保管しアクセスすることができる。

さらに制約実施コードは、上述してきたような「イン・
ライン」式の組み合せでなく、データ操作コードとは別
に集めることができる。この場合、レコード・レベル操
作時に検査すべき制約が探知されると、データ更新経路
からの「トリガ」によりコードが起動される。また制約
実施及びレコード操作は、上述例（次レコード操作以前
に各レコードが操作され制約が実施される）とは異なる
順序で行なわれることがある。

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

【図面の簡単な説明】

第１図は本発明による挿入、更新、削除中の参照制約実
施方式の流れ図である。 第２図は第６図における参照制約の仕様を示す表である
。 第３図は第６図のＤＥＰＡＲＴＭＥＮＴテーブルを示す
図であり、基本キー、外部キー及びサンプル・データを
含む。 示す図であり、基本キー、外部キー及びサンプル・デー
タを含む。 第５図は、第６図のＰＲＯＪＥＣＴテーブルを示す図で
あり、基本キー、外部キー及びサンプル・データを含む
。 第６図は、６つの参照制約により関連付けられた３テー
ブルを持つリレーショナル・データベースの概略図であ
る。 出願人　　インターナショナル・ビジネス・マシーンズ
・コーポレーション 代理人　　弁理士　　頓　　宮　　孝 （外１名） 第４図は第６図のＥＭＰＬＯＹＥＥテーブルを第３図 第４囚 第６図

Claims (2)

【特許請求の範囲】
1. （１）データベース管理システムにおいて複数のレコー
   ドを操作する動作を実行する方法であって、上記動作の
   対象のレコードを操作し、上記同じ動作により別のレコ
   ードが操作される前に上記レコードに関する参照制約を
   検査するステップを含む データベース・システムの動作方法。
2. （２）データの行より成るテーブルを有するリレーショ
   ナル・データベース管理システムにおいて、行を操作し
   且つ参照制約を実施する方法であって、少なくとも２つ
   の行を操作する動作を実行する時、 上記動作が行の挿入を含む場合は、該行を挿入し、次い
   で上記挿入の結果生じる参照制約の侵犯を識別するステ
   ップを実行し、 上記動作が行の更新を含む場合は、該行の基本キーの更
   新から生じる参照制約の侵犯を識別し、次いで該行を更
   新し、次いで該行の外部キーの更新から生じる参照制約
   の侵犯を識別するステップを実行し、 上記動作が行の削除を含む場合は、該行を削除し、次い
   で上記削除から生じる参照制約の侵犯を識別するステッ
   プを実行し、 上記参照制約の侵犯が識別されたならば上記動作を撤回
   する データベース・システムの動作方法。