JP2001282592A - 参照保全性制約によるリレーショナル・データベース動作の順序付け - Google Patents

Abstract

(57)【要約】 【課題】 参照保全性制約違反を避けるために、リレー
ショナル・データベースに対して実行される動作を計画
的に順序付ける技法を提供すること。 【解決手段】 影響を受ける表について定義された参照
保全性制約に従って動作を自動的に順序付けることによ
って、任意のリレーショナル・データベースに対して実
行される動作の効率を高める方法、システム、およびコ
ンピュータ・プログラム。順序付けは、計画的に実行さ
れるので、アプリケーション開発者は、参照保全性制約
に違反しない形でのアプリケーションの構成を試みると
いう重荷から解放される。データベース変更の効率が、
この技法を使用することによって大幅に高まる。順序付
けは、データベース・エンジン側で実行することができ
る。既存のアプリケーションは、アプリケーション自体
の変更を必要とせずに、この順序付け技法を利用するこ
とができる。この技法を使用する時には、バッチモード
書込動作が可能であり、これによって、実行しなければ
ならないネットワーク・ラウンドトリップの数が減る。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、コンピュータ・プ
ログラミングの分野に関し、具体的には、影響される表
について定義された参照保全性制約に従って、計画的に
動作を順序付けることによって、リレーショナル・デー
タベースに対して実行される動作の効率を高める方法、
システム、およびコンピュータ可読コードに関する。

【０００２】

【従来の技術】「参照保全性（referential integrit
y）」とは、データベースの表の間の一貫性が維持され
る、リレーショナル・データベースの特性を指す。具体
的に言うと、参照保全性を維持するためには、各表の行
の外部キー値のすべてが有効であることが必要である。
外部キーが有効であるのは、その値が、（１）ヌルでな
いか、（２）識別される表のある行に主キーとして現れ
るかのいずれかの場合である。主キーが含まれる表を、
しばしば「親」表と呼び、外部キーが含まれる表を、
「従属」表と呼ぶ。特定の表が外部キーを有しない場合
があり、この場合には、この表に関して実施される参照
保全性制約はなく、そうでない場合には、表が１つまた
は複数の外部キーを有する。表が複数の外部キーを有す
る時には、複数の親表／従属表関係が存在し、そのよう
な関係のそれぞれについて参照保全性制約を実施しなけ
ればならない。

【０００３】参照保全性制約は、表の行の挿入または削
除を行う動作がデータベースに対して実行される時と、
更新動作が外部キーの値に影響する時に実施されなけれ
ばならない。挿入制約では、挿入される行の各外部キー
値が、必ず対応する親表に主キー値として現れなければ
ならないことが必要である。たとえば、Employee（従業
員）表とDepartment（部署）表を有するデータベースが
あり、Employee表の各行が、その従業員が働いている部
署を識別する列項目を有すると仮定する。この部署列
を、外部キーとして定義することができ、その場合に
は、対応する主キーが、Department表の部署番号にな
る。この例では、参照保全性を維持するために、ある部
署についてEmployee表で従業員を定義する前に、その部
署をDepartment表で作成することが必要になる。削除制
約では、削除される行の主キーが、従属表の１つまたは
複数の行の外部キー値として指定されていないことが必
要である。例として同一のEmployee表およびDepartment
表を使用すると、部署がDepartment表から削除される場
合には、参照保全性を維持するために、その部署の部署
番号を参照しているすべてのEmployee行を、まず削除し
なければならない（そうしなければ、削除動作を行うこ
とができない）ことが必要である。更新制約では、外部
キー値に対する更新が、親表にすでに主キーとして現れ
ている新しい値を使用しなければならない（または、更
新によって、外部キー値にヌルがセットされる）ことが
必要である。

【０００４】したがって、リレーショナル・データベー
スに対して実行される動作の順序が、データベースの参
照保全性を維持するのに非常に重要であることがわか
る。潜在的な参照保全性制約違反の検出を提供し、不整
合データベースにつながる動作を実行できなくする、多
くのデータベース・システムが市販されている（たとえ
ば、無効な挿入動作が、まだ主キー値として使用された
ことがない外部キー値を含むことを示すエラー・メッセ
ージを生成する可能性がある）。InternationalBusines
s Machines Corporation（ＩＢＭ）社の一般にＤＢ／２
（商標）と称するＤＡＴＡＢＡＳＥ２（商標）製品が、
この種のデータベース・システムの初期の例である
（「ＤＡＴＡＢＡＳＥ２」はＩＢＭ社の商標であり、
「ＤＢ／２」はＩＢＭ社の商標である）。

【０００５】参照保全性制約違反を避けるために動作を
実行しなければならない順序は、通常は、アプリケーシ
ョン・プログラム内でリレーショナル行が作成または削
除される順序と一致しない。したがって、行をデータベ
ースに挿入または削除する必要がある順序は、アプリケ
ーションのイベント・フローから推論することができな
い。さらに、ユーザが、行の作成または削除に関する情
報を対話的に供給する場合、参照保全性を維持するため
の正しい順序で情報を指定するようにユーザに要求する
ことは、（おそらくは複雑な）表の相互関係を理解する
という非現実的な重荷をユーザに課し、柔軟性のない非
直観的な形で作業することをユーザに要求する。

【０００６】参照保全性制約違反を避けるために、リレ
ーショナル・データベースに対して実行される動作を計
画的に順序付ける技法の１つとして、オブジェクト指向
プログラミング・アプリケーションのために、オブジェ
クトの間のアソシエーションを使用して、オブジェクト
・レベルで動作を順序付ける方法が考えられる。

【０００７】オブジェクト指向でないアプリケーション
と共に使用することができるか、変更を生成するアプリ
ケーションの有効範囲の外部で（アプリケーションから
の順序付けられない動作の受取時にリレーショナル・デ
ータベース・エンジンで、など）使用することができ、
これによってアプリケーション自体の変更を回避する
か、その両方である、計画的に動作を順序付ける技法を
有することが有利であろう。自動的なデータベース動作
順序付けがなければ、プログラマが、動作を生成するア
プリケーション・プログラムに動作順序付けを手作業で
コーディングするか、データベース内の参照保全性規則
実施を使用不能にするかのいずれかを行う必要がある。
動作順序付けの手作業のコーディングは、時間がかか
り、誤りをおかしやすく、簡単に維持不能なコードにつ
ながる。参照保全性規則検査の使用不能化は、不整合デ
ータベースにつながる可能性がある。

【０００８】したがって、リレーショナル・データベー
スに対して実行される動作を自動的に順序付ける、改良
された技法が必要である。

【０００９】

【発明が解決しようとする課題】本発明の目的は、参照
保全性制約違反を避けるために、リレーショナル・デー
タベースに対して実行される動作を計画的に順序付ける
技法を提供することである。

【００１０】本発明のもう１つの目的は、リレーショナ
ル・データベース動作の効率が高まるように、この順序
付け技法を提供することである。

【００１１】本発明のもう１つの目的は、順序付けで、
影響される表について定義された参照保全性制約が使用
される、この方針に基づく順序付け技法を提供すること
である。

【００１２】本発明のもう１つの目的は、バッチ・モー
ド処理を使用可能にし、これによって、複数のリレーシ
ョナル・データベース記憶動作を同時に実行でき、これ
によって、アプリケーションとデータベース・エンジン
の間のラウンドトリップの数を減らし、したがって、シ
ステム全体の効率を高める、方針に基づく順序付け技法
を提供することである。

【００１３】本発明のもう１つの目的は、オブジェクト
指向アプリケーションと共に使用することに制限されな
い、方針に基づく順序付け技法を提供することである。

【００１４】本発明のもう１つの目的は、データベース
変更動作を生成するアプリケーション・プログラムの有
効範囲の外部で使用することができ、これによって、ア
プリケーション自体を無変更のままにすることを可能に
する、方針に基づく順序付け技法を提供することであ
る。

【００１５】本発明の他の目的および長所は、部分的に
は以下の説明および図面に示され、部分的には説明から
明白になるか、本発明の実践によって習得することがで
きる。

【００１６】

【課題を解決するための手段】前述の目的を達成するた
めに、本明細書で広く説明する本発明の目的に従い、本
発明は、リレーショナル・データベースに対して実行さ
れる動作の効率を高めると同時に参照保全性制約違反を
回避する方法、システム、およびコンピュータ・プログ
ラムを提供する。これは、実行される動作を計画的に順
序付ける技法を使用して達成される。この技法には、デ
ータベースの複数の表の間で挿入順序を判定するステッ
プと、この複数の表の間で削除順序を判定するステップ
と、変更のそれぞれによって実行される動作に従い、変
更のそれぞれによって影響を受ける表の特定の１つに従
って、データベースに対して行われる複数の変更をクラ
スタ化するステップと、クラスタ化された変更をデータ
ベースに適用するステップとが含まれる。クラスタ化さ
れた変更を適用するステップには、さらに、まず、挿入
順序に従って、動作が挿入であるクラスタ化された変更
のすべてを適用するステップと、次に、動作が更新であ
るクラスタ化された変更のすべてを適用するステップ
と、最後に、削除順序に従って、動作が削除であるクラ
スタ化された変更のすべてを適用するステップとが含ま
れる。動作が更新であるクラスタ化された変更は、任意
の順序で適用することができる。

【００１７】挿入順序および削除順序の判定は、変更の
クラスタ化および適用の前の時に実行することができ
る。

【００１８】この技法は、リレーショナル・データベー
ス・エンジンで動作することができる。この技法は、変
更を生成するアプリケーション・プログラムとは別に動
作することもできる。

【００１９】変更のクラスタ化および適用は、後続の複
数の変更のそれぞれについて、繰り返して実行すること
ができる。変更の適用は、バッチ書込モードで実行する
ことができる。

【００２０】挿入順序の判定には、さらに、表の選択さ
れた１つのそれぞれについて、１つまたは複数の関係す
る表を識別するステップと、選択された表および関係す
る表のそれぞれの中から、挿入優先順位を判定するステ
ップと、選択された表がそれに関する挿入優先順位を有
する関係する表の前に選択された表を順序付け、選択さ
れた表がそれに対する挿入優先順位を有しない関係する
表の後に選択された表を順序付けるステップとを含める
ことができる。

【００２１】挿入優先順位を判定するステップには、さ
らに、選択された表および関係する表の各特定の１つに
ついて、選択された表と特定の関係する表との間の関係
が制約を有するかどうかを判定するステップと、制約が
存在する時に、制約の外部キーが特定の関係する表内に
配置されているかどうか判定するステップと、制約が存
在しない時、または外部キーが特定の関係する表内に配
置されていない時に、選択された表が挿入優先順位を有
しないと結論するステップと、外部キーが特定の関係す
る表内に配置されている時に、選択された表が挿入優先
順位を有すると結論するステップとを含めることができ
る。

【００２２】削除順序を判定するステップには、さら
に、表の選択された１つのそれぞれについて、１つまた
は複数の関係する表を識別するステップと、選択された
表および関係する表のそれぞれについて、削除優先順位
を判定するステップと、選択された表がそれに関する削
除優先順位を有する関係する表の前に選択された表を順
序付け、選択された表がそれに関する削除優先順位を有
しない関係する表の後に選択された表を順序付けるステ
ップとを含めることができる。

【００２３】削除優先順位を判定するステップには、さ
らに、選択された表および関係する表の各特定の１つに
ついて、選択された表と特定の関係する表との間の関係
が制約を有するかどうかを判定するステップと、制約が
存在する時に、制約の外部キーが選択された表内に配置
されているかどうかを判定するステップと、制約が存在
しない時または外部キーが選択された表内に配置されて
いない時に、選択された表が削除優先順位を有しないと
結論するステップと、外部キーが選択された表内に配置
されている時に、選択された表が削除優先順位を有する
と結論するステップとを含めることができる。

【００２４】これから、図面を参照して本発明を説明す
るが、図では、同様の符号がすべての図を通じて同一の
要素を表す。

【００２５】

【発明の実施の形態】図１に、本発明を実践することが
できる代表的なワークステーション・ハードウェア環境
を示す。図１の環境には、パーソナル・コンピュータな
ど、関連する周辺装置を含む、代表的な単一ユーザのワ
ークステーション１０が含まれる。ワークステーション
１０には、マイクロプロセッサ１２および、既知の技法
に従ってマイクロプロセッサ１２とワークステーション
１０の構成要素とを接続し、これらの間の通信を可能に
するのに使用されるバス１４が含まれる。ワークステー
ション１０には、通常は、ユーザ・インターフェース・
アダプタ１６が含まれ、ユーザ・インターフェース・ア
ダプタ１６は、バス１４を介して、キーボード１８、マ
ウス２０、または、接触感知画面、ディジタル化入力パ
ッドなどのユーザ・インターフェース装置とすることが
できる他のインターフェース装置２２など、１つまたは
複数のインターフェース装置にマイクロプロセッサ１２
を接続する。バス１４は、ＬＣＤ画面またはモニタなど
のディスプレイ装置２４も、ディスプレイ・アダプタ２
６を介してマイクロプロセッサ１２に接続する。バス１
４は、マイクロプロセッサ１２を、メモリ２８および、
ハード・ドライブ、ディスケット・ドライブ、テープ・
ドライブなどを含めることができる長期保管３０も接続
する。

【００２６】ワークステーション１０は、たとえば通信
チャネルまたはモデム３２を介して、他のコンピュータ
またはコンピュータのネットワークと通信することがで
きる。その代わりに、ワークステーション１０は、ＣＤ
ＰＤ（セルラ・ディジタル・パケット・データ）カード
などの、通信チャネルまたはモデム３２にある無線イン
ターフェースを使用して通信することができる。ワーク
ステーション１０は、ＬＡＮまたはＷＡＮでそのような
他のコンピュータと関連することができ、また、ワーク
ステーション１０は、別のコンピュータなどとのクライ
アント／サーバ配置のクライアントとすることができ
る。これらの構成のすべてならびに適当な通信ハードウ
ェアおよび通信ソフトウェアが、当技術分野で既知であ
る。

【００２７】図２に、本発明を実践することができるデ
ータ処理ネットワーク４０を示す。データ処理ネットワ
ーク４０には、無線ネットワーク４２およびネットワー
ク４４などの複数の個々のネットワークを含めることが
でき、これらのネットワークのそれぞれに、複数の個々
のワークステーション１０を含めることができる。さら
に、当業者が諒解するように、１つまたは複数のＬＡＮ
を含めることができ（図示せず）、ＬＡＮには、ホスト
・プロセッサに結合された複数のインテリジェント・ワ
ークステーションを含めることができる。

【００２８】さらに図２を参照すると、無線ネットワー
ク４２およびネットワーク４４には、ゲートウェイ・コ
ンピュータ４６またはアプリケーション・サーバ４７
（データ・リポジトリ４８にアクセスすることができ
る）などのメインフレーム・コンピュータまたはサーバ
も含めることができる。ゲートウェイ・コンピュータ４
６は、各ネットワーク４４の入口点として働く。ゲート
ウェイ・コンピュータ４６は、通信リンク５０ａによっ
て別の無線ネットワーク４２に結合できることが好まし
い。ゲートウェイ・コンピュータ４６は、通信リンク５
０ｂ、５０ｃを使用して１つまたは複数のワークステー
ション１０に直接に結合することもできる。ゲートウェ
イ・コンピュータ４６は、ＩＢＭ社から入手可能なEnte
rprise Systems Architecture/370、Enterprise System
s Architecture/390コンピュータなどを使用して実施す
ることができる。応用分野に応じて、Application Syst
em/400（ＡＳ／４００とも称する）などのミッドレンジ
・コンピュータを使用することができる（「Enterprise
Systems Architecture/370」はＩＢＭ社の商標であ
り、「Enterprise Systems Architecture/390」、「App
lication System/400」、および「ＡＳ／４００」はＩ
ＢＭ社の登録商標である）。

【００２９】ゲートウェイ・コンピュータ４６は、記憶
装置（データ・リポジトリ４８など）に結合４９するこ
ともできる。さらに、ゲートウェイ・コンピュータ４６
は、１つまたは複数のワークステーション１０に直接に
または間接的に結合することができる。

【００３０】当業者は、ゲートウェイ・コンピュータ４
６を、無線ネットワーク４２から地理的に大きく離れて
配置することができ、同様に、ワークステーション１０
を、無線ネットワーク４２およびネットワーク４４から
かなりの距離に配置することができることを諒解するで
あろう。たとえば、無線ネットワーク４２を、米国カリ
フォルニア州に配置し、ゲートウェイ・コンピュータ４
６を、米国テキサス州に配置し、１つまたは複数のワー
クステーション１０を、米国ニューヨーク州に配置する
ことができる。ワークステーション１０を、ＴＣＰ／Ｉ
Ｐ（Transmission Control Protocol/Internet Protoco
l）などのネットワーキング・プロトコルを使用し、セ
ルラ電話、無線ネットワーク、衛星ネットワークなどの
多数の代替接続媒体を介して、無線ネットワーク４２に
接続することができる。無線ネットワーク４２は、ＩＰ
上のＴＣＰまたはＵＤＰ（ユーザ・データグラム・プロ
トコル）、Ｘ．２５、フレーム・リレー、ＩＳＤＮ（サ
ービス総合ディジタル網）、ＰＳＴＮ（公衆交換電話
網）などの通信リンク５０ａを使用してゲートウェイ・
コンピュータ４６に接続されることが好ましい。ワーク
ステーション１０は、代替案では、ダイヤル接続による
通信リンク５０ｂまたは５０ｃを使用してゲートウェイ
・コンピュータ４６に直接に接続することができる。さ
らに、無線ネットワーク４２およびネットワーク４４
は、図２に示されたものに類似の形で、１つまたは複数
の他のネットワーク（図示せず）に接続することができ
る。

【００３１】本発明を実施するソフトウェア・プログラ
ミング・コードは、通常は、ワークステーション１０ま
たはアプリケーション・サーバ４７のマイクロプロセッ
サ１２によって、ＣＤ−ＲＯＭドライブまたはハード・
ドライブなどのある種類の長期保管３０からアクセスさ
れる。ソフトウェア・プログラミング・コードは、ディ
スケット、ハード・ドライブ、またはＣＤ−ＲＯＭなど
のデータ処理システムと共に使用するためのさまざまな
既知の媒体のいずれかで実施することができる。このコ
ードは、そのような媒体上で配布することができ、ま
た、あるコンピュータ・システムのメモリまたは記憶装
置からある種類のネットワークを介して他のコンピュー
タ・システムへ、そのような他のコンピュータ・システ
ムのユーザによる使用のためにユーザに配布することが
できる。その代わりに、プログラミング・コードを、メ
モリ２８内で実施し、バス１４を使用してマイクロプロ
セッサ１２によってアクセスすることができる。ソフト
ウェア・プログラミング・コードをメモリ内または物理
媒体上で実施するか、ネットワークを介してソフトウェ
ア・コードを配布するか、その両方を行う技法および方
法は、周知であり、本明細書ではこれ以上説明しない。

【００３２】本発明のユーザは、ワイヤライン（wireli
ne）接続または無線接続を使用して、自分のコンピュー
タをサーバに接続することができる。ワイヤライン接続
とは、ケーブルおよび電話回線などの物理媒体を使用す
る接続であり、無線接続は、衛星リンク、無線電波、お
よび赤外線波などの媒体を使用する。多数の接続技法
を、これらのさまざまな媒体と共に使用することがで
き、コンピュータのモデムを使用して電話回線を介する
接続を確立する、トークン・リングまたはイーサネット
などのＬＡＮカードを使用する、セルラ・モデムを使用
して無線接続を確立するなどを行うことができる。ユー
ザのコンピュータは、ラップトップ・コンピュータ、ハ
ンドヘルド・コンピュータ、またはモバイル・コンピュ
ータ、車載装置、デスクトップ・コンピュータ、メイン
フレーム・コンピュータなど、処理機能および通信機能
を有するすべての種類のコンピュータ・プロセッサとす
ることができる。同様に、リモート・サーバは、処理機
能および通信機能を有する多数の異なるタイプのコンピ
ュータのいずれかとすることができる。これらの技法
は、当技術分野で周知であり、それらの使用を可能にす
るハードウェア・デバイスおよびソフトウェアは、簡単
に入手できる。以下では、ユーザのコンピュータを、同
等に「ワークステーション」、「装置」、または「コン
ピュータ」と呼称し、これらの用語のいずれかまたは用
語「サーバ」の使用は、上で説明したいずれかの種類の
計算装置を指す。

【００３３】本発明では、行がデータベースに記憶され
るか削除される時に、任意の基礎になるリレーショナル
・データベースについて定義された参照保全性制約に従
って、挿入動作、更新動作、および削除動作を計画的に
順序付ける技法が定義される。本明細書では、主キー列
対外部キー列対によって記述されるデータベース内の関
係する表の間で定義される関係情報およびこれらの列対
に関する保全性規則を使用する順序付けアルゴリズムを
定義する。

【００３４】本発明を使用することができる計算環境に
は、インターネット環境、イントラネット環境、エクス
トラネット環境、または他のタイプのネットワーク環境
を含めることができる。これらの環境は、クライアント
・サーバ・アーキテクチャまたは多層アーキテクチャを
使用して構成することができる。本発明は、動作の順序
付けが、データベース・エンジンが配置されるのと同一
の計算機で実行されるか、結果の順序付けされた動作を
データベース・エンジンに送信するためにネットワーク
に接続する前に動作の順序付けが実行される、切断モー
ド（すなわちスタンドアロン・モード）で使用すること
もできる。

【００３５】本発明の好ましい実施形態を、図３ないし
１８を参照して説明する。

【００３６】好ましい実施形態では、本発明は、１つま
たは複数のコンピュータ・ソフトウェア・プログラムと
して実施される。本発明のソフトウェアの実施形態は、
サーバまたはネットワーク内の中間装置で、１つまたは
複数のモジュール（コード・サブルーチンまたは、オブ
ジェクト指向プログラミングで「オブジェクト」とも称
する）として動作することができる。その代わりに、本
明細書で開示される発明的概念から逸脱せずに、ソフト
ウェアがユーザのワークステーションで動作することが
できる。本発明を、リレーショナル・データベースにア
クセスするすべてのシステムならびにリレーショナル・
データベース・エンジンによって使用することができ
る。

【００３７】本発明の実施形態は、（ｉ）実行時に排他
的に、または（ｉｉ）部分的に実行時の前（たとえば開
発時）に実行される前処理ステップとしておよび部分的
に実行時に、実行することができる。どちらの場合で
も、アプリケーションによって作成される（順序付けら
れていない）変更の組が、データベースに適用される前
に本発明を使用して順序付けられる。順序付けは、デー
タベース・エンジンが常駐するサーバで、クライアント
計算機から変更の組を受け取った後に適用することがで
きる。または、順序付けを、クライアント計算機で適用
し、順序付けられた変更の組を、データベース・エンジ
ンによる直接適用のためにサーバに送ることができる。
場合（ｉ）には、順序付け技法が、アプリケーションが
実行を完了した後に実行されて、そのアプリケーション
によって生成された変更を順序付け、適用する状況が含
まれる。場合（ｉｉ）では、特定のアプリケーションに
よって使用される表の間の順序付け関係を、アプリケー
ションを使用して変更を生成する前に、本発明に従っ
て、計画的に判定することができる。

【００３８】図３ないし７に、従来技術による、リレー
ショナル・データベース表に記憶されるデータ値の簡単
な例を示す。この例を使用して、本発明の動作を示す。
たとえば、対象の表は、Company（会社）表３００、Dep
artment（部署）表３１０、Employee（従業員）表３２
０、Spouse（配偶者）表３３０、およびAddress（住
所）表３４０である。Company表３００の各行３０１お
よび３０２には、単一の会社の情報が格納される。Comp
any表３００は、この表にアクセスするための主キーと
して働き、したがって各行の一意の要素であるCompany
Number（会社番号）３０３によって編成される。この例
では、各行が、会社名のフィールド（列として示され
る）Company Name３０４も有する。Department表３１０
は、この表の主キーであるDepartment Number（部署番
号）３１５によって編成される。各行３１１、３１２、
３１３、および３１４は、部署名のフィールドDepartme
nt Name３１６およびこの部署が存在する会社番号のフ
ィールドCompany Number３１７を有する。Company Numb
er３１７は、この例では外部キーであり、各部署の行
を、関連する会社を表すCompany表３００からの行とリ
ンクする。同様に、Employee表３２０は、その主キーと
してEmployee Number（従業員番号）３２５を有し、こ
の表の行をDepartment表３１０およびSpouse表３３０に
リンクする外部キー列３２７および３２８を有する。Sp
ouse表３３０は、その主キーとしてSpouse Identifier
（配偶者識別子）３３５を有し、外部キーを含まない。
Address表３４０は、主キーとしてAddress Identifier
（住所識別子）３４５を使用し、外部キー列３４７を含
む。この外部キー列３４７の値は、Employee表３２０の
行を指し、この住所が定義されている従業員を識別する
（図３ないし７で使用される表が、本発明を示すために
簡略化されており、実際のアプリケーションに使用され
る表が、通常は図３ないし７に示されたものよりより多
数のフィールドおよび多数の行を有することは、当業者
に明白であろう）。

【００３９】前に述べたように、データベース行に対し
て実行することができる関係演算には、挿入動作、更新
動作、および削除動作の３種類がある。これらの動作タ
イプの間の依存性は次の通りである。 （１）挿入動作は、他の挿入に依存する（すなわち、挿
入される行が、挿入されるもう１つの行を参照する）可
能性があるが、他の種類の動作には依存しない。挿入の
間の依存性の例として、新しい部署の従業員の従業員情
報が、図３ないし７に示されたデータベースに挿入され
ると仮定する。Employee表３２０は、外部キー列３２７
についてDepartment表３１０に依存するので、新しい部
署の行が、その部署の新しい従業員の行の前に挿入され
なければならない。 （２）更新動作は、他の更新には依存しないが、挿入に
依存する（すなわち、ある行が、挿入される行を参照す
るように更新される）可能性がある。更新と挿入の間の
依存性の例として、従業員０００５０（行３２２）が部
署Ｅ０１から部署Ｅ１０に異動したので、図３ないし７
に示されたデータベースを変更しなければならず、部署
Ｅ１０が、挿入される新しい部署であると仮定する。こ
の場合、従業員の行３２２の更新を実行する前に、新し
い部署Ｅ１０の行を挿入しなければならない。 （３）削除動作は、他の削除に依存する（すなわち、削
除される行が、削除される別の行を参照する）可能性が
あり、更新に依存する（行を更新して、削除される行の
参照を解除しなければならない）可能性がある。削除の
間の依存性の例として、部署Ｅ０１およびその従業員の
すべてを削除すると仮定する。参照保全性を維持するた
めには、まず従業員の行を削除することが必要であり、
その後、部署の行を削除することができる。削除と更新
の間の依存性の例として、部署Ｅ０１が削除されるが、
その従業員が削除されないと仮定する。この場合、部署
の行３１２の削除が発生する前に、この部署のすべての
従業員の行（この例では行３２２および３２３）を変更
して、その部署の外部キー列３２７の値を変更しなけれ
ばならない。

【００４０】特定のデータベースの表に関する異なるデ
ータベース動作の間の優先関係が、複雑な前提条件木を
形成する。しかし、動作実行の正しい順序を決定できる
ようになるために、これらの前提条件を完全に解決する
必要はない。その代わりに、挿入動作の間および削除動
作の間でのみ前提条件を解決する必要があり、異なる動
作タイプの間の高水準で解決する必要はあるが、異なる
動作タイプにまたがって個別に解決する必要はない。動
作タイプの間での高水準の動作の解決には、動作を３つ
の相すなわち、まず挿入動作、次に更新動作、最後に削
除動作の順で実行することだけが必要である。この順序
は、上で説明した動作タイプの間の依存性に合わせて調
整されていることがわかる。したがって、おそらく更新
される行によって参照される可能性がある行のすべて
が、すでにデータベース内にあることになるので、挿入
動作を実行した後に更新動作を実行することが安全であ
る。すべての可能な参照解除が更新相中に行われるの
で、更新動作の後に削除動作を実行することができる。

【００４１】挿入動作の間の詳細な順序付けを決定する
ために重要な判断基準が、行が挿入される表と、その行
の外部キーによって参照される表である。用語「参照す
る」行または表は、本明細書では、前者を記述するのに
使用され、用語「参照される」行または表は、後者を記
述するのに使用される。図３ないし７の例を使用する
と、外部キー列３２７（Department Number）を使用し
て、Employee表３２０内で「従業員Ｘが部署Ｙで働いて
いる」関係を示す場合、Employee表３２０に挿入される
行は、参照する表としてEmployee表、参照される表とし
てDepartment表３１０を有する。したがって、新しい従
業員０００１１を、新しい部署Ｅ１１に挿入する（下で
詳細に説明する図８に示されている）場合、参照する行
は行４１０であり、参照される行は行４２０である。し
たがって、行４２０は、行４１０が挿入される前にデー
タベースに挿入されなければならない。

【００４２】一般に、挿入に関するこの順序付け要件
は、「行を挿入する時に、表Ａ内の参照される行を、表
Ｂの参照する行の前に挿入しなければならない」と記述
される。すべての参照される行が表Ａに挿入されている
場合、表Ｂの行によって参照される可能性がある表Ａ内
のすべての行が、すでにデータベース内にあるので、表
Ｂに参照する行を挿入しても安全である。したがって、
挿入動作は、１時に１つの表について実行することがで
き、まず表Ａにすべての参照される行を挿入し、その
後、表Ｂにすべての参照する行を挿入する。したがっ
て、詳細な挿入優先順位は、本発明の技法を使用する時
に、個々の行の間ではなく、表の間で解決するだけでよ
い。

【００４３】削除に関する順序付け要件は、「行を削除
する時に、表Ｂの参照する行を、表Ａの参照される行を
削除する前に削除しなければならない」と記述される。
表Ｂからすべての参照する行を削除した場合、表Ｂの、
おそらく表Ａの行を参照する可能性があるすべての行が
データベースから除去されているので、表Ａの参照され
る行を削除しても安全である。したがって、削除動作
は、１時に１つの表について実行することができ、まず
表Ｂからすべての参照する行を削除し、その後、表Ａか
らすべての参照される行を削除する。したがって、詳細
な削除優先順位では、本発明の技法を使用する時に、個
々の行の間ではなく、表の間で解決するだけでよい。

【００４４】本発明によって定義される順序付け技法で
は、まず、行を挿入する動作および行を削除する動作の
それぞれについて、影響を受ける表の間で順序付け要件
を判定する（参照される表および参照する表について上
で定義した規則を使用する）。これによって、順序付け
された挿入表リストおよび順序付けされた削除表リスト
（それぞれ図１０の要素５１０および５２０によって示
される）がもたらされる。影響を受ける行が、その後、
変更される表および実行されるデータベース動作のタイ
プに従ってクラスタ化される。すなわち、挿入動作が、
表によってクラスタ化または分離され、更新動作が、
（厳密には必要でないが、好ましい実施形態によれば表
によって）分離され、削除動作が、表によって分離され
る。これによって、表ごとに３つのリストすなわち、挿
入される行のリスト、更新される行のリスト、および削
除される行のリストがもたらされる（明白であるとお
り、動作タイプごとの個々の表リストは、３つの総合リ
ストに組み合わせることができ、その結果の挿入リスト
および削除リストは、順序付けされた挿入表リストおよ
び順序付けされた削除表リストに従って順序付けされ
る）。

【００４５】更新動作を有する表は、上で述べたよう
に、動作順序付けを必要としない。挿入動作および削除
動作について、好ましい実施形態では、ほぼ理想的なア
ルゴリズム（図１０および図１４ないし１６に関して下
で詳細に説明する）を使用して、表の間の詳細な前提条
件を解決する。それぞれの場合で、順序付けアルゴリズ
ムでは、表の２つのリストすなわち、変更が実行される
表の元の順序付けられていないリスト（本明細書では、
同等に未ソート・リストと称する）および順序付けられ
た表リスト（本明細書では同等にソート済みリストと称
する）を使用する。当初、順序付けられた表リストは空
である。順序付けアルゴリズムは、順序付けられていな
いリスト内の表について反復する。反復される表のそれ
ぞれ（「現行表」と称する）が、まず順序付けられた表
リストの末尾に追加される。このアルゴリズムは、その
後、現行表が他の表に対して有する関係（すなわち、そ
れらへまたはそれらからの外部キー）について反復す
る。そのような関係のそれぞれについて、このアルゴリ
ズムは、現行表がその関係で挿入優先順位（挿入順序付
けを実行する時）または削除優先順位（削除順序付けを
実行する時）を有するかどうかをテストする。現行表
が、関係での優先順位を有し、関係する表が、すでに順
序付けられたリストに含まれる（現行表の前の位置に）
場合には、関係する表のそれぞれおよびその下位の優先
順位の関係する表が、再帰的にリストの末尾に移動され
る。順序付けアルゴリズムの完了時に、順序付けられた
リスト内の表の順序は、データベースで定義された参照
保全性規則に対応する、すなわち、ソート済み挿入リス
トが、挿入動作を実行しなければならない順序を規定
し、ソート済み削除リストも同様である。

【００４６】現行表は、関係する表が現行表内の主キー
列を参照する外部キー列を有し、この主キー列／外部キ
ー列対に関して定義された制約がある場合に、関係に対
する挿入優先順位を有する。現行表は、現行表が関係す
る表内の主キー列を参照する外部キー列を有し、この主
キー列／外部キー列対に関して定義された制約がある場
合に、関係に対する削除優先順位を有する。

【００４７】順序付け相およびクラスタ化相が完了した
後に、ソート済み表リスト内の順序に従って、行の挿
入、更新、および削除を行うことができる。

【００４８】この処理の動作を、例に関して説明する。
図８に、図３ないし７のサンプル・データに対して実行
することができる変更を示し、図９に、本発明による順
序付けの後のこれらの変更を示す。図１０に、図３ない
し７からの例の表のサブセットと、各表について作成さ
れた動作リストを使用する、本発明に従って実行される
表順序付けの例を示す。

【００４９】図８に、図３ないし７の５つの表のデータ
に対して行うことができる７つの代表的な変更の行４１
０ないし４４０を示す。図８および図９で使用される表
フォーマットは、例示を目的とし、本発明と共に使用さ
れる構造を示す目的のものでないことに留意されたい。
さらに、各変更のデータ値のサブセットだけが含まれ、
そのサブセットは、本発明によって使用される関連する
情報を示すものであることに留意されたい。図８の列４
０５からわかるように、通常のアプリケーションによっ
て作成される動作のタイプは、混合されている。本発明
による順序付けの後に、動作は、挿入に関する第１の順
序付けられたグループ（４２０、４１０、４３５）、次
に、更新に関する順序付けられていないグループ（この
例では単一の変更の行４１５だけを含む）、最後に、削
除に関する順序付けられたグループ（４４０、４３０、
４２５）にクラスタ化される。

【００５０】図８の列４０６では、変更によって影響を
受ける表名が識別され、列４０７では、その表の主キー
値が指定される。したがって、行４１０では、主キー値
０００１１（Employee Number３２５列の）を有する新
しい従業員が、Employee表３２０に挿入される。列４０
８では、この新しい従業員のために使用される外部キー
列３２７の値が指定され、列４０９では、この外部キー
が主キーとして定義されている表が識別される（Employ
ee表３２０の追加の外部キー列３２８は、図を単純にす
るために行４１０から省略されているが、図１３ないし
１７の論理に関して詳細に説明するように、外部キー列
３２７と同様の形で処理される）。したがって、行４１
０の最後の２つの項目は、この新しい従業員が部署Ｅ１
１のメンバであることを示す。図４には、この部署番号
の行が含まれておらず、したがって、データベースに行
４１０を直接に挿入しようと試みると、参照保全性制約
に違反することに留意されたい。しかし、図８の行４２
０は、Department表３１０にこの部署を作成する挿入動
作である。したがって、本発明の順序付け動作は、計画
的に、図９の最初の２つの順序付けられた行（４２０、
４１０）によって示されるように、行４１０の挿入動作
の前に行４２０の挿入動作が行われるようにし、これに
よって、違反を避ける。行４３５の残りの挿入動作で
は、従業員番号０００１２を有する新しい従業員が追加
されるが、この従業員は、部署Ｅ２１にいるものとして
定義されている。この部署番号は、Department表３１０
ですでに定義されているので、行４３５の挿入は、制約
違反を引き起こさない。この挿入の行４３５は、順序付
けられた挿入動作の３番目として図９に示されている。
しかし、挿入の間（および削除の間）の正確な順序付け
は、必要でないことに留意することが重要である。順序
付け要件は、表によるのであって、特定の表に対する個
々の変更によるのではない。したがって、行４１０およ
び４３５（およびEmployee表に対する他の更新）の間の
順序付けは、重要でない。

【００５１】行４１５の更新動作は、図９では、本発明
に従って、更新が挿入の後、削除の前に実行されること
を示すために、行４２０、４１０、および４３５の挿入
動作の後に現れる。複数の更新の間の順序付け（複数の
更新は例に示されてはいないが）は不要である。

【００５２】順序付けられた変更の最後のグループが、
削除である。図８の未ソート変更リストには、３つの削
除の行４２５、４３０、および４４０が含まれる。デー
タベースから行を削除する時には、問題の外部キーが、
行を挿入する時と異なる。行を削除するためには、削除
される行の主キーを外部キーとして指定している他の表
の行が存在することができない。図８では、星印を使用
して、この依存性を示す。たとえば、行４２５では、部
署番号Ｅ３１を有する部署が、Department表３１０から
削除される。図３ないし７の残りの表を検査することに
よって、Employee表３２０が、外部キー列３２７として
Ｅ３１を使用する行３２４を有することがわかる。した
がって、行４２５の列４０８および４０９は、この削除
動作がEmployee表３２０の従業員００３２０の行に依存
することを意味する目的のものであり、したがって、削
除動作を実行すると、データベースの参照保全性制約に
違反することになる。しかし、従業員００３２０の従業
員レコードを先に削除する場合、部署Ｅ３１の削除は、
この違反をもたらさない。図８の行４３０は、この従業
員の削除を指定するものであり、したがって、本発明の
方針に基づく順序付け動作によって、これら２つの削除
の間の順序が、図９の順序付けられた行４３０、４２５
に示されているように変更される。しかし、従業員００
３２０の行の削除は、それ自体の制約違反を引き起こす
はずである。行４３０の列４０８および４０９に示され
ているように、この従業員００３２０は、Address表３
４０からの行との依存性関係を有する。というのは、行
３４１が、（主キー値ＡＤ００１を使用して）その外部
キー列３４７からこの従業員を参照しているからであ
る。図８の行４４０は、この住所の行３４１の削除動作
である。図３ないし７の表のどの行も、この住所の行３
４１に依存しないので、列４０８および４０９は、この
削除動作の行４４０に関する前提条件がないことを示す
ために空白のままにされていた。したがって、３つの削
除動作の最終的な順序は、図９に示されているように４
４０、４３０、４２５であり、この順序は、Address
表、Employee表、およびDepartment表の間の関係に基づ
いて判定された。

【００５３】Employee表、Address表、およびDepartmen
t表を、図３ないし７のデータベースの例からのサブセ
ットと見なし（残りの表と外部キーを無視し）て、図１
０に、これらの表の間の順序付けが本発明に従ってどの
ように実行されるかを示す。図８および図９の例の動作
に関して述べたように、外部キー列３２７および３４７
のゆえに、これらの表の間に依存性関係が存在する。挿
入に関する参照する表／参照される表の順序を使用し
て、本発明は、挿入に関する正しい順序付けが、まずDe
partment５１１、次にEmployee５１２、最後にAddress
５１３であると判定する。削除に関する参照する表／参
照される表の順序を使用すると、これらの表の順序は、
Address５２１、Employee５２２、およびDepartment５
２３に逆転する。図１０には、表ごとに３つの動作リス
トが作成されることも示されている。Employee表５０１
に対して実行される変更に関して、３つのリストは、挿
入される従業員情報のすべてを含むリスト５３１、従業
員更新に関するリスト５３２、および削除される従業員
に関するリスト５３３である。類似するリスト５４１な
いし５４３および５５１ないし５５３が、それぞれAddr
ess表５０２およびDepartment表５０３について作成さ
れる。個々のリスト内では、順序付けは不要であり、こ
れによって、本発明の動作が、参照保全性を維持するた
めの非常に効率的な解決策になる。

【００５４】図１１および図１２に、それぞれ、図３な
いし７の例のデータベースの５つの表の組全体およびそ
れらの図に示された外部キー関係のすべてを使用して実
行される挿入順序付けおよび削除順序付けを示す。アプ
リケーション・プログラムが、これらの図の左欄に示さ
れた順序で動作のグループを作成し、Address表に影響
する動作（６０１）が最初であり、Employee表に対する
動作（６０２）、Department表に対する動作（６０
３）、Spouse表に対する動作（６０４）、およびCompan
y表に対する動作（６０５）が続くと仮定する。矢印６
１１ないし６１４は、図３ないし７の例による、これら
の表の間の外部キー関係を示す。検査からわかるよう
に、本発明の参照する／参照される規則は、挿入動作を
適用する表順序が、Company６２１、Department６２
２、Spouse６２３、Employee６２４、およびAddress６
２５であることを必要とする。図１２の右欄に示された
削除順序では、これらの表が逆の順序で配置される。

【００５５】本発明の順序付け技法の好ましい実施形態
を実施するのに使用することができる論理を、図１３な
いし１８と、図１０の例の表に関して詳細に説明する。
この説明では、行われる変更（挿入、更新、および削
除）を、情報の「タプル」と称する。

【００５６】図１３に、本発明の順序付け技法の好まし
い実施形態の主高水準フローの論理を示す。処理は、ブ
ロック７００で開始され、ここで、挿入に使用される表
順序が判定される。この処理を、図１４で詳細に説明す
る。図１０を参照すると、ブロック７００で、挿入順序
付け情報であるDepartment５１１、Employee５１２、お
よびAddress５１３が作成される。次に、削除に使用さ
れる表順序を判定する（ブロック７１０）が、この削除
順序付けは、図１４の論理によって説明する。これによ
って、図１０の削除順序付け情報であるAddress５２
１、Employee５２２、およびDepartment５２３が作成さ
れる（明白なとおり、ブロック７００およびブロック７
１０を実行する順序は、結果を変更せずに逆転すること
ができる）。その後、アプリケーション・プログラムに
よって作成されたタプルを、表および動作タイプによっ
てクラスタ化する（ブロック７２０）。図１７で、この
処理を詳細に説明する。図１０の図を参照すると、ブロ
ック７２０のクラスタ化では、タプルが適当なリスト５
３１ないし５３３、５４１ないし５４３、または５５１
ないし５５３に置かれる。これらのリストは、リンク・
リスト構造を使用して作成されることが好ましい。参照
保全性制約に違反しないようにタプルが順序付けられた
ので、ブロック７３０、７４０、および７５０で、デー
タベースでの行の挿入、更新、および削除の動作を（こ
の特定の順番で）適用する。図１３には、ブロック７２
０ないし７５０が１回だけ行われるものとして図示され
ているが、特定のアプリケーションのための実施形態
で、これらのブロックの反復繰り返しを選択することが
できることに留意されたい。たとえば、対話的に変更を
行うユーザによって駆動されるアプリケーションは、そ
のアプリケーションが終了するまで、制御が図１３のブ
ロック７５０からブロック７２０に返されるようにし
て、データベースに対する生成された変更を周期的に適
用することができる。もう１つの例として、トランザク
ション指向アプリケーションと共に使用される時に、ブ
ロック７２０ないし７５０の処理を、各トランザクショ
ンの完了時に実行して、トランザクションの有効範囲中
に生成された変更を適用することができる。図１３を変
更してこの代替反復手法を実施する方法は、当業者には
明白であろう。

【００５７】各動作タイプの個々のタプルについて、変
更の適用を、従来技術の技法を使用して実行することが
でき、したがって、ブロック７３０、７４０、および７
５０の論理を詳細に説明しなかったことに留意された
い。すなわち、挿入動作が表によって正しく順序付けら
れた後に、各挿入を、既存の技法を使用して順番に適用
することができ、更新および削除についても同様であ
る。本発明の長所は、複数の動作が１回でデータベース
に書き込まれるバッチモード記憶動作を実行することが
できることである。バッチモード書込機能は、従来技術
に存在するが、参照保全性制約を有するデータベース表
と共に使用されることはほとんどない。というのは、従
来技術に、制約に違反しないように表の任意のグループ
に関して複数の書込動作を順序付ける方法を計画的に決
定する技法がないからである（また、表の特定の組に関
する順序付けを実施する論理を手作業でコーディングす
ることが、極端に難しく、誤りをおかしやすいからであ
る）。

【００５８】図１４の論理は、本発明による、参照保全
性制約に違反しない、正しい表順序付けを判定するのに
使用される論理の好ましい実施形態を示すものである。
図１５に、図１４が図１３のブロック７００から呼び出
される時に使用される、挿入動作に関する表の優先順位
を判定するアルゴリズムを示す。図１６に、図１４がブ
ロック７１０から呼び出される時に使用される、削除動
作に関する表の優先順位を判定するのに使用される同様
のアルゴリズムを示す。これらの異なるアルゴリズム
は、たとえば図１４の論理が挿入の処理または削除の処
理のどちらのために呼び出されたかを示すフラグをセッ
トすることによって、ブロック８３５から選択的に呼び
出されることが好ましい（その代わりに、図１４の論理
を、挿入と削除について複製することができ、この場合
には、図１５および図１６の論理を、適用可能なコピー
に組み込むことができる）。

【００５９】図１４の処理は、変更が適用される入力表
の順序付けられていないリストから開始される（この情
報は、生成されたタプルまたはデータベース・スキーマ
の知識から抽出することができる）。図１０の図を参照
して、元の未ソート表順序が、Employee表５０１、Addr
ess表５０２、およびDepartment表５０３であると仮定
する（上で述べたように、挿入に関する結果の順序は、
Department５１１、Employee５１２、およびAddress５
１３になり、削除に関する結果の順序は、５２１、５２
２、および５２３になる）。ブロック８００で、この順
序付けられていない入力リストの最初の表を指すように
現行表ポインタをセットする。ブロック８０５で、この
表の識別子を、図１４の出力として生成される（当初は
空である）順序付けされたリストの末尾に追加する。図
１０の例では、現行ポインタは、Employee表を指し、順
序付けられていないリストには、Address表およびDepar
tment表だけが含まれ、順序付けされたリストに、Emplo
yee表が含まれる。

【００６０】ブロック８１０で、現行表が関係を有する
かどうかを検査する。本明細書で使用する「関係」は、
現行表内に存在するものとして定義された外部キーなら
びに他の表内で定義され、現行表を参照する外部キーを
指す。したがって、現行のEmployee表について、２つの
関係すなわち、Departmentとの１つの関係およびAddres
sとの１つの関係があり、したがって、ブロック８１０
は、肯定の結果を有する。制御はブロック８３０に移
り、ここで、現行データベース・スキーマの表に関する
関係リスト（図１４では「ｒ．ｓ．リスト」と称する）
から、現行表を含む最初の関係を得る。この関係リスト
は、順序付けられないものとすることができ、特定のス
キーマで表の間の関係を判定するための、当技術分野で
既知の技法を使用して得ることができる。図１８に、図
１０の表および関係に対応するスキーマを示す。図１８
では、第１の関係１２０５、１２０６が、表１２００の
列１２０３と表１２２０の列１２２２の間で定義され、
第２の関係１２１０、１２１１が、表１２００の列１２
０１と表１２３０の列１２３２の間で定義されている。

【００６１】現行表に関する関係がない時には、評価す
る必要がある順序付け制約がなく、したがって、制御
は、単純にブロック８１０からブロック８１５に移る。
これによって、この表の詳細な順序付け論理の動作がバ
イパスされ、この表は順序付けされた出力リストのこの
位置にとどまる。

【００６２】この例では、Employeeを含む最初の（した
がって現行の）関係が、Employee（「現行」表）とDepa
rtment（したがって「関係する」表）の間の関係である
と仮定する。その場合、ブロック８３５が、挿入動作と
削除動作のどちらを実行するかに応じて図１５または図
１６の論理を呼び出して、現行表が現行の関係に対する
優先順位を有するかどうかを判定する。

【００６３】挿入処理が実行される場合には、次に図１
５のブロック９００を実行する。ブロック９００では、
現行関係が制約を有するかどうかを尋ねる。例のEmploy
ee対Department関係の場合、部署番号に対する制約（外
部キー列３２７を使用する）がある。したがって、ブロ
ック９００は肯定の結果を有し、制御はブロック９２０
に移る（制約がない時には、ブロック９００は否定の結
果を有し、ブロック９１０で、図１４の呼出し元論理に
否定の回答を返す）。その後、ブロック９２０で、関係
する表が現行関係に関して外部キーを有するかどうかを
検査する。この例では、外部キーは、現行表であるEmpl
oyee表内にあり、関係するDepartment表内にはなく、そ
の結果、ブロック９２０は否定の結果を有する。結果が
否定の時には、ブロック９４０で、ブロック８３５に否
定の回答を返す（そうでない場合には、ブロック９３０
で肯定の回答を返す）。

【００６４】比較からわかるように、図１６の削除処理
は、図１５の挿入処理とほとんど同一である。削除処理
でも、現行関係の制約があるかどうかを検査し（ブロッ
ク１０００）、ない場合にはブロック８３５に否定の回
答を返す。しかし、ブロック１０２０のテストでは、ブ
ロック９２０で現行関係の外部キーが関係する表内にあ
るかどうかを尋ねたのに対して、現行関係の外部キー
が、現行表内にあるかどうかを尋ねる。したがって、順
序付けらていないEmployee表５０１、Address表５０
２、およびDepartment表５０３に関する削除処理を実行
し、Employee対Department関係を評価する（図１５に関
して上で説明した）時には、ブロック１０２０は、この
関係によって使用される外部キー列３２７が、現行（Em
ployee）表内に存在するので、肯定の結果を有する。図
１６の残りの論理は、図１５の論理と同一である。

【００６５】ここで図１４のブロック８３５の処理に戻
って、図１５（削除を処理する時には図１６）から否定
の回答が返される場合には、制御はブロック８４０に移
り、現行表のすべての関係をすでに処理したかどうか
（すなわち、関係リストの終りに達したかどうか）を検
査する。そうでない場合には、制御はブロック８６０に
移る。Employee対Department関係では、挿入処理に関し
て否定の結果が返されるので、この例では、ブロック８
３５に制御が戻った後にブロック８４０が実行される。
ブロック８４０は、この時点で否定の結果を有する。と
いうのは、現行Employee表を含むもう１つの関係がある
からであり、その関係は、Employee表とAddress表の間
の関係である。したがって、ブロック８４５で、関係リ
ストからこの関係を得、その後、ブロック８３５で、現
行表がこの特定の関係で優先順位を有するかどうかを判
定する。挿入処理についてもう一度図１５を参照する
と、現行のEmployee対Address関係は制約を有し、した
がって、ブロック９００のテストが肯定の結果を有す
る。この場合、評価される関係で、Address表３４０の
外部キー列３４７が使用されている。Address表は、図
１５のこの呼出しでの関係する表であり、したがって、
ブロック９２０が肯定の結果を有し、ブロック９３０で
ブロック８３５に肯定の回答が返されることになる。

【００６６】もう一度ブロック８３５に戻って、この例
の第２の関係評価に関して返される肯定の結果が、ブロ
ック８６０への制御の移動を引き起こす。ブロック８６
０では、関係する表が、作成中の順序付けられたリスト
にすでに含まれるかどうかを尋ねる。この例では、この
時点で、順序付けられたリストにEmployee表だけが含ま
れ、関係するAddress表は含まれないので、ブロック８
６０は否定の結果を有し、制御はブロック８４０に戻
る。ブロック８４０では、関係リストに、まだ評価され
ていない現行表に関する関係があるかどうかをもう一度
検査する。評価すべき関係がない場合、この例ではこの
時点でそうなるが、制御はブロック８１５に移り、図１
４によって使用されているスタックが空であるかどうか
を検査する。まだスタックに何もプッシュしていないの
で、このテストはこの例では肯定の結果を有し、処理は
ブロック８２０で継続される。ブロック８２０では、順
序付けられていないリストが空であるかどうかを訪ねる
が、これは、そのリストが完全に処理された時に真にな
る。このテストの結果が肯定である場合には、図１４の
動作は、それが呼び出された目的である挿入処理または
削除処理に関して完了し、制御は図１３の呼出し元論理
に戻る。

【００６７】ブロック８２０が否定の結果を有する時に
は、順序付けられていない入力リストから処理しなけれ
ばならない表がまだある。したがって、ブロック８２５
で、順序付けられていないリストからの次の表を指すよ
うに現行表ポインタをセットし、ブロック８０５で、順
序付けられていないリストから、作成中の順序付けられ
た出力リストの末尾へ表を移動する。この例では、現行
表ポインタが、Address表を指し、順序付けられていな
いリストに、Department表だけが含まれ、順序付けられ
たリストに、Employee表およびAddress表が含まれる
（当業者に明白であるように、本明細書でのあるリスト
から別のリストへの「表の移動」への言及は、表の識別
子の移動、またはこれと同等に、表へのポインタまたは
表の識別子の移動の短縮表記を意図するものである）。
現行表（Address）は、Employee表に対する単一の関係
を有し、したがって、ブロック８１０は、肯定の結果を
有する。ブロック８３０、８３５、８４０、８１５、お
よび８２０が、前に説明したように実行され、ブロック
８３５での呼出しから図１５のブロック９００、９２
０、および９４０が実行され、否定の結果が返される。
ブロック８２０は、この例ではやはり否定の結果を有
し、ブロック８２５で、順序付けされないリストの次の
表（最後の表でもあるDepartment）を指すように現行表
ポインタをセットする。その後、ブロック８０５をもう
一度実行し、Department表を順序付けされたリストの末
尾に移動する。したがって、順序付けされないリストは
空になり、順序付けられたリストにはEmployee、Addres
s、およびDepartmentが含まれる。

【００６８】Department表について、Employeeとの１つ
の関係とAddressとの１つの関係の２つの関係が存在す
る。したがって、ブロック８１０は、肯定の結果を有す
る。Department対Employeeの関係を評価する時に、ブロ
ック８３５は、肯定の結果を有し、処理はブロック８６
０に達する。ブロック８６０は、関係する表（Employe
e）がすでに順序付けられたリストにあるので、やはり
肯定の結果を有する。したがって、ブロック８６５で、
図１４のために使用されるスタックに現行表（Departme
nt）をプッシュし、ブロック８７０で、現行表ポインタ
を変更し、その結果、現行表ポインタが、関係する（Em
ployee）表を指すようになる。ブロック８０５は、現行
（Employee）表を、順序付けられたリスト内のその既存
の位置から順序付けられたリストの末尾に移動し、これ
は、スタックにプッシュされたばかりの表と現行表の間
の関係に従ってリストを順序付けるという効果を有す
る。この例では、この時点で、順序付けられたリストに
Address、Department、およびEmployeeが含まれ、Emplo
yeeは、リスト内でDepartmentより後の位置（したがっ
て、挿入に関するより低い優先順位）に移動されてい
る。

【００６９】その後、ブロック８１０、８３０、および
８３５をもう一度実行し、今回は、Employee対Departme
nt関係を評価し、図１５から否定の結果が返される。そ
の後、ブロック８４０および８４５を実行し、Employee
対Address関係を得る。この関係について、ブロック８
３５は、肯定の結果を有し、制御は再びブロック８６０
に達する。ブロック８６０では、関係するAddress表が
すでに順序付けられたリストにあることが検出され、し
たがって、ブロック８６５で、現行Employee表がスタッ
クにプッシュされる（スタックには、EmployeeとDepart
mentが含まれる）。その後、ブロック８７０および８０
５で、Address表が、順序付けられたリストの一番前の
既存の位置から移動されて、リストの末尾の最後の項目
になる。この例の順序付けられたリストは、図１０のDe
partment５１１、Employee５１２、およびAddress５１
３に示されているように、挿入に関して正しい順序にな
っている。

【００７０】図１４の処理が、この例に関して終了する
形を、これから手短に説明する。Address対Employee関
係が評価され、ブロック８３５で否定の結果を有する。
これはAddressに関する唯一の関係なので、ブロック８
４０からブロック８１５に制御が移される。この時点
で、スタックには２つの項目があり、したがって、制御
はブロック８１５からブロック８５０に移され、ここ
で、一番上の要素（Employee）をポップし、現行表にす
る。制御はブロック８４０に戻り、ここで、Employeeに
関するすべての関係が、Employeeがスタックにプッシュ
された前の処理サイクル中にすでに処理されていること
が判定される。しかし、スタックのプッシュ動作が、現
行表の最後の関係でない関係のゆえに発生した場合に
は、ブロック８４０が、否定の結果を有し、制御はブロ
ック８４５に移って、その表の残りの関係の処理を開始
する。Employeeについて評価すべき関係がもうないこと
の検出によって、制御が再びブロック８１５に移り、次
にブロック８５０に移り、ここで、Department表が、ス
タックからポップされ、現行表にされる。Employeeと同
様に、Departmentは、その最後の関係の評価中にスタッ
クにプッシュされたので、ブロック８４０は、肯定の結
果を有し、制御は再びブロック８１５に達する。スタッ
クはこの時空なので、制御はブロック８２０に移り、順
序付けられていないリストが空であることが検出され
る。その後、制御は図１３のブロック７００に戻り、任
意のデータベース・スキーマの表に関する正しい挿入順
序が、計画的に決定されている。

【００７１】図１４に示した順序付けアルゴリズムは、
通常はネットワーク構造を形成する、表の間の関係情報
をとりあげ、関連する情報のフラット化された順次表現
を生成するのに使用することができる手法の１つにすぎ
ないことに留意されたい。テーブルの対の間の、関係全
体ではなく制約だけを考慮することによって、このネッ
トワークを木として扱うことができる。したがって、循
環が存在することが不可能になる。図１４で説明した手
法は、木をフラット化されたリストに変換する比較的単
純直裁な技法であり、したがって、好ましい実施形態と
して使用される。その代わりに、本明細書で開示される
発明的概念から逸脱せずに、木をフラット化されたリス
トに変換する他の手法を使用することができる。たとえ
ば、上で説明したように、２つの表の間の順序付けを実
施するために、表を順序付けられたリストの末尾に移動
するのではなく、表が、それが依存する表の直後になる
ように表を移動する、より複雑な手法を使用することが
できる。

【００７２】ブロック７００および７１０が完了した後
に、挿入順序付けおよび削除順序付けが決定されてい
る。本発明が、前に述べたように部分的に前処理ステッ
プとして使用され、部分的に実行時に使用される時に
は、前処理に、この順序付けの決定が（まず、前に述べ
た従来技術の技法を使用して、対象のスキーマの表およ
び関係を判定した後に）含まれる。クラスタ化処理（そ
の次に図１３のブロック７２０から呼び出されるものと
して図示）およびデータベースを変更するためにアプリ
ケーション・プログラムによって生成されたタプルを適
用するための動作の実行（ブロック７３０ないし７５
０）は、実行時に行われる（または、変更のクラスタ化
および適用を、アプリケーションがその実行時処理を完
了した後に適用することができる）。

【００７３】図１７に移って、本発明の好ましい実施形
態によって、タプルを適当なリスト（図１０の５３１な
いし５３３、５４１ないし５４３、または５５１ないし
５５３など）に入れるのに使用されるクラスタ化技法を
説明する。この処理に入る際に、データベースに対して
行われる変更を表すタプルの順序付けられていないリス
トが、アプリケーション・プログラムによって作成され
ている。たとえば、トランザクション指向アプリケーシ
ョンと共に使用される時には、この論理を、各トランザ
クションの完了時に呼び出して、前に説明したように、
トランザクションの有効範囲中に生成された変更を実行
することができる。その場合には、タプル・リストが、
そのトランザクションに関する変更を表す。または、図
１７の論理が、アプリケーションが完了した時に限って
呼び出される場合には、タプル・リストに、アプリケー
ションの全有効範囲中に生成されたすべての変更が含ま
れる。

【００７４】ブロック１１００で、タプル・リストから
最初の要素を得、ブロック１１１０で、このタプルによ
って影響される表（すなわち、タプルでその主キー値が
指定されている表）を判定する。ブロック１１４０で、
タプルが挿入動作に関するものであるかどうかを尋ね
る。そうである場合には、ブロック１１５０で、ブロッ
ク１１１０で決定された表の挿入リストにタプルを追加
する。そうでない場合には、ブロック１１６０で、タプ
ルが削除動作に関するものであるかどうかを尋ねる。こ
の場合、ブロック１１７０で、適当な表の削除リストに
タプルを追加し、そうでない場合には、ブロック１１８
０で、適当な表の更新リストにタプルを追加する。前に
述べたように、本発明の長所は、特定の表についてリス
ト内の順序付けが不要であり、したがって、図１７のク
ラスタ化論理が高速かつ効率的であることである。タプ
ルを適当なリストに追加した後に、制御はブロック１１
３０に達し、ここで、すべてのタプルを処理したかどう
かを調べるために検査する。そうである場合には、図１
７の処理が完了し、制御は呼出し元の論理（図１３のブ
ロック７２０）に戻る。そうでない場合には、ブロック
１１２０で、タプル・リストから次の要素を得、ブロッ
ク１１３０が否定の結果を有するまで、説明した形で各
タプルを適当なリストに追加する処理を継続する。

【００７５】上で示したように、本発明は、任意のリレ
ーショナル・データベースに対して実行される動作を計
画的に順序付けると同時に、そのデータベースの表の間
の参照保全性を自動的に維持する、効率的な技法を提供
する。この技法は、データベース・エンジン自体で使用
することができる。アプリケーションは、アプリケーシ
ョン自体の変更を必要とせずに、方針に基づく順序付け
技法を有利に利用することができる。Enterprise JavaB
eansと共に使用される時には、この技法によって、コン
テナをパーシスタンス機構から独立にすることが可能に
なり、コンテナがパーシスタンス実現方法の詳細を知る
必要がなくなる。さらに、変更タプルが、本発明を使用
する時に表によってクラスタ化されるので、特定の表に
対して実行されるすべての変更を知ることが可能になる
（この「ビッグ・ピクチャ」ビューが使用可能でない従
来技術の技法と対照的に）。この技法では、バッチ書込
動作の使用も可能になり、従来技術で一般的な手法（す
なわち、書込の間の順序を解決するという複雑な問題を
避けるためにデータベース・エンジンに各書込動作を別
々に送る手法）と比較して、非常に改善された性能がも
たらされる。バッチ書込動作を使用する時には、ネット
ワーク・ラウンドトリップの数を、再悪条件シナリオの
（３×表の数）まで減らすことができる。ここで、３
は、異なる動作タイプの数を表す（１タイプの動作だけ
が実行される時には、ラウンドトリップの数を、影響さ
れる表の数まで減らすことができる）。

【００７６】まとめとして、本発明の構成に関して以下
の事項を開示する。

【００７７】（１）リレーショナル・データベースの参
照保全性を維持するために、前記データベースに対して
実行される動作を計画的に順序付けるコンピュータ・プ
ログラムであって、前記コンピュータ・プログラムが、
コンピュータを、前記データベースの複数の表の間の挿
入順序を判定する手段と、前記データベースの前記複数
の表の間の削除順序を判定する手段と、前記データベー
スに対して行われる複数の変更のそれぞれによって実行
される動作に従い、前記変更のそれぞれによって影響さ
れる前記表の特定の１つに従って、前記複数の変更をク
ラスタ化する手段と、前記クラスタ化された変更を前記
データベースに適用する手段であって、さらに、まず、
前記挿入順序に従って、前記動作が挿入である前記クラ
スタ化された変更のすべてを適用する手段と、次に、前
記動作が更新である前記クラスタ化された変更のすべて
を適用する手段と、最後に、前記削除順序に従って、前
記動作が削除である前記クラスタ化された変更のすべて
を適用する手段とを含む、前記クラスタ化された変更を
前記データベースに適用する手段として機能させるため
のコンピュータ・プログラム。 （２）前記動作が更新である前記クラスタ化された変更
が、任意の順序で適用される、上記（１）に記載のコン
ピュータ・プログラム。 （３）前記挿入順序を判定する前記手段の動作および前
記削除順序を判定する前記手段の動作を、前記クラスタ
化する手段の動作および前記適用する手段の動作の前の
時に実行することができる、上記（１）に記載のコンピ
ュータ・プログラム。 （４）前記コンピュータ・プログラムが、リレーショナ
ル・データベース・エンジンで動作する、上記（１）に
記載のコンピュータ・プログラム。 （５）前記コンピュータ・プログラムが、前記変更を生
成するアプリケーション・プログラムと別に動作する、
上記（１）に記載のコンピュータ・プログラム。 （６）前記クラスタ化する手段の動作および前記適用す
る手段の動作が、後続の複数の変更のそれぞれについて
繰り返して実行される、上記（１）に記載のコンピュー
タ・プログラム。 （７）前記適用する手段が、バッチ書込モードで実行さ
れる、上記（１）に記載のコンピュータ・プログラム。 （８）前記挿入順序を判定する前記手段が、さらに、前
記表の選択された１つのそれぞれについて、１つまたは
複数の関係する表を識別する手段と、前記選択された表
および前記関連する表のそれぞれの間で、挿入優先順位
を判定する手段と、前記選択された表がそれに関する挿
入優先順位を有する前記関連する表の前に前記選択され
た表を順序付け、前記選択された表がそれに関する挿入
優先順位を有しない前記関連する表の後に前記選択され
た表を順序付ける手段とを含む、上記（１）に記載のコ
ンピュータ・プログラム。 （９）前記削除順序を判定する前記手段が、さらに、前
記表の選択された１つのそれぞれについて、１つまたは
複数の関係する表を識別する手段と、前記選択された表
および前記関連する表のそれぞれの間で、削除優先順位
を判定する手段と、前記選択された表がそれに関する削
除優先順位を有する前記関連する表の前に前記選択され
た表を順序付け、前記選択された表がそれに関する削除
優先順位を有しない前記関連する表の後に前記選択され
た表を順序付ける手段とを含む、上記（１）に記載のコ
ンピュータ・プログラム。 （１０）前記挿入優先順位を判定する前記手段が、さら
に、前記選択された表および前記関係する表の各特定の
１つについて、前記選択された表と前記特定の関係する
表との間の関係が制約を有するかどうかを判定する手段
と、前記制約が存在する時に、前記制約の外部キーが前
記特定の関係する表内に配置されているかどうかを判定
する手段と、前記制約が存在しない時、または前記外部
キーが前記特定の関係する表内に配置されていない時
に、前記選択された表が前記挿入優先順位を有しないと
結論する手段と、前記外部キーが前記特定の関係する表
内に配置されている時に、前記選択された表が前記挿入
優先順位を有すると結論する手段とを含む、上記（８）
に記載のコンピュータ・プログラム。 （１１）前記削除優先順位を判定する前記手段が、さら
に、前記選択された表および前記関係する表の各特定の
１つについて、前記選択された表と前記特定の関係する
表との間の関係が制約を有するかどうかを判定する手段
と、前記制約が存在する時に、前記制約の外部キーが前
記選択された表内に配置されているかどうかを判定する
手段と、前記制約が存在しない時、または前記外部キー
が前記選択された表内に配置されていない時に、前記選
択された表が前記削除優先順位を有しないと結論する手
段と、前記外部キーが前記選択された表内に配置されて
いる時に、前記選択された表が前記削除優先順位を有す
ると結論する手段とを含む、上記（９）に記載のコンピ
ュータ・プログラム。 （１２）コンピュータ環境内でリレーショナル・データ
ベースの参照保全性を維持するために、前記データベー
スに対して実行される動作を計画的に順序付けるシステ
ムであって、前記データベースの複数の表の間の挿入順
序を判定する手段と、前記データベースの前記複数の表
の間の削除順序を判定する手段と、前記データベースに
対して行われる複数の変更のそれぞれによって実行され
る動作に従い、前記変更のそれぞれによって影響される
前記表の特定の１つに従って、前記複数の変更をクラス
タ化する手段と、前記クラスタ化された変更を前記デー
タベースに適用する手段であって、さらに、まず、前記
挿入順序に従って、前記動作が挿入である前記クラスタ
化された変更のすべてを適用する手段と、次に、前記動
作が更新である前記クラスタ化された変更のすべてを適
用する手段と、最後に、前記削除順序に従って、前記動
作が削除である前記クラスタ化された変更のすべてを適
用する手段とを含む、前記クラスタ化された変更を前記
データベースに適用する手段とを含むシステム。 （１３）前記動作が更新である前記クラスタ化された変
更が、任意の順序で適用される、上記（１２）に記載の
システム。 （１４）前記挿入順序を判定する前記手段の動作および
前記削除順序を判定する前記手段の動作を、前記クラス
タ化する手段の動作および前記適用する手段の動作の前
の時に実行することができる、上記（１２）に記載のシ
ステム。 （１５）前記システムが、リレーショナル・データベー
ス・エンジンで動作する、上記（１２）に記載のシステ
ム。 （１６）前記システムが、前記変更を生成するアプリケ
ーション・プログラムと別に動作する、上記（１２）に
記載のシステム。 （１７）前記クラスタ化する手段の動作および前記適用
する手段の動作が、後続の複数の変更のそれぞれについ
て繰り返して実行される、上記（１２）に記載のシステ
ム。 （１８）前記適用する手段が、バッチ書込モードで実行
される、上記（１２）に記載のシステム。 （１９）前記挿入順序を判定する前記手段が、さらに、
前記表の選択された１つのそれぞれについて、１つまた
は複数の関係する表を識別する手段と、前記選択された
表および前記関連する表のそれぞれの間で、挿入優先順
位を判定する手段と、前記選択された表がそれに関する
挿入優先順位を有する前記関連する表の前に前記選択さ
れた表を順序付け、前記選択された表がそれに関する挿
入優先順位を有しない前記関連する表の後に前記選択さ
れた表を順序付ける手段とを含む、上記（１２）に記載
のシステム。 （２０）前記削除順序を判定する前記手段が、さらに、
前記表の選択された１つのそれぞれについて、１つまた
は複数の関係する表を識別する手段と、前記選択された
表および前記関連する表のそれぞれの間で、削除優先順
位を判定する手段と、前記選択された表がそれに関する
削除優先順位を有する前記関連する表の前に前記選択さ
れた表を順序付け、前記選択された表がそれに関する削
除優先順位を有しない前記関連する表の後に前記選択さ
れた表を順序付ける手段とを含む、上記（１２）に記載
のシステム。 （２１）前記挿入優先順位を判定する前記手段が、さら
に、前記選択された表および前記関係する表の各特定の
１つについて、前記選択された表と前記特定の関係する
表との間の関係が制約を有するかどうかを判定する手段
と、前記制約が存在する時に、前記制約の外部キーが前
記特定の関係する表内に配置されているかどうかを判定
する手段と、前記制約が存在しない時、または前記外部
キーが前記特定の関係する表内に配置されていない時
に、前記選択された表が前記挿入優先順位を有しないと
結論する手段と、前記外部キーが前記特定の関係する表
内に配置されている時に、前記選択された表が前記挿入
優先順位を有すると結論する手段とを含む、上記（１
９）に記載のシステム。 （２２）前記削除優先順位を判定する前記手段が、さら
に、前記選択された表および前記関係する表の各特定の
１つについて、前記選択された表と前記特定の関係する
表との間の関係が制約を有するかどうかを判定する手段
と、前記制約が存在する時に、前記制約の外部キーが前
記選択された表内に配置されているかどうかを判定する
手段と、前記制約が存在しない時、または前記外部キー
が前記選択された表内に配置されていない時に、前記選
択された表が前記削除優先順位を有しないと結論する手
段と、前記外部キーが前記選択された表内に配置されて
いる時に、前記選択された表が前記削除優先順位を有す
ると結論する手段とを含む、上記（２０）に記載のシス
テム。 （２３）リレーショナル・データベースの参照保全性を
維持するために、前記データベースに対して実行される
動作を計画的に順序付ける方法であって、前記データベ
ースの複数の表の間の挿入順序を判定するステップと、
前記データベースの前記複数の表の間の削除順序を判定
するステップと、前記データベースに対して行われる複
数の変更のそれぞれによって実行される動作に従い、前
記変更のそれぞれによって影響される前記表の特定の１
つに従って、前記複数の変更をクラスタ化するステップ
と、前記クラスタ化された変更を前記データベースに適
用するステップであって、さらに、まず、前記挿入順序
に従って、前記動作が挿入である前記クラスタ化された
変更のすべてを適用するステップと、次に、前記動作が
更新である前記クラスタ化された変更のすべてを適用す
るステップと、最後に、前記削除順序に従って、前記動
作が削除である前記クラスタ化された変更のすべてを適
用するステップとを含む、前記クラスタ化された変更を
前記データベースに適用するステップとを含む方法。 （２４）前記動作が更新である前記クラスタ化された変
更が、任意の順序で適用される、上記（２３）に記載の
方法。 （２５）前記挿入順序を判定する前記ステップの動作お
よび前記削除順序を判定する前記ステップの動作を、前
記クラスタ化するステップの動作および前記適用するス
テップの動作の前の時に実行することができる、上記
（２３）に記載の方法。 （２６）前記方法が、リレーショナル・データベース・
エンジンで動作する、上記（２３）に記載の方法。 （２７）前記方法が、前記変更を生成するアプリケーシ
ョン・プログラムと別に動作する、上記（２３）に記載
の方法。 （２８）前記クラスタ化するステップの動作および前記
適用するステップの動作が、後続の複数の変更のそれぞ
れについて繰り返して実行される、上記（２３）に記載
の方法。 （２９）前記適用するステップが、バッチ書込モードで
実行される、上記（２３）に記載の方法。 （３０）前記挿入順序を判定する前記ステップが、さら
に、前記表の選択された１つのそれぞれについて、１つ
または複数の関係する表を識別するステップと、前記選
択された表および前記関連する表のそれぞれの間で、挿
入優先順位を判定するステップと、前記選択された表が
それに関する挿入優先順位を有する前記関連する表の前
に前記選択された表を順序付け、前記選択された表がそ
れに関する挿入優先順位を有しない前記関連する表の後
に前記選択された表を順序付けるステップとを含む、上
記（２３）に記載の方法。 （３１）前記削除順序を判定する前記ステップが、さら
に、前記表の選択された１つのそれぞれについて、１つ
または複数の関係する表を識別するステップと、前記選
択された表および前記関連する表のそれぞれの間で、削
除優先順位を判定するステップと、前記選択された表が
それに関する削除優先順位を有する前記関連する表の前
に前記選択された表を順序付け、前記選択された表がそ
れに関する削除優先順位を有しない前記関連する表の後
に前記選択された表を順序付けるステップとを含む、上
記（２３）に記載の方法。 （３２）前記挿入優先順位を判定する前記ステップが、
さらに、前記選択された表および前記関係する表の各特
定の１つについて、前記選択された表と前記特定の関係
する表との間の関係が制約を有するかどうかを判定する
ステップと、前記制約が存在する時に、前記制約の外部
キーが前記特定の関係する表内に配置されているかどう
かを判定するステップと、前記制約が存在しない時、ま
たは前記外部キーが前記特定の関係する表内に配置され
ていない時に、前記選択された表が前記挿入優先順位を
有しないと結論するステップと、前記外部キーが前記特
定の関係する表内に配置されている時に、前記選択され
た表が前記挿入優先順位を有すると結論するステップと
を含む、上記（３０）に記載の方法。 （３３）前記削除優先順位を判定する前記ステップが、
さらに、前記選択された表および前記関係する表の各特
定の１つについて、前記選択された表と前記特定の関係
する表との間の関係が制約を有するかどうかを判定する
ステップと、前記制約が存在する時に、前記制約の外部
キーが前記選択された表内に配置されているかどうかを
判定するステップと、前記制約が存在しない時、または
前記外部キーが前記選択された表内に配置されていない
時に、前記選択された表が前記削除優先順位を有しない
と結論するステップと、前記外部キーが前記選択された
表内に配置されている時に、前記選択された表が前記削
除優先順位を有すると結論するステップとを含む、上記
（３１）に記載の方法。

【図面の簡単な説明】

【図１】本発明を実践することができるコンピュータ・
ワークステーション環境のブロック図である。

【図２】本発明を実践することができるネットワーク接
続されたコンピュータ環境を示す図である。

【図３】従来技術による、リレーショナル・データベー
ス表に記憶されたデータ値の簡単な例を示す図である。

【図４】従来技術による、リレーショナル・データベー
ス表に記憶されたデータ値の簡単な例を示す図である。

【図５】従来技術による、リレーショナル・データベー
ス表に記憶されたデータ値の簡単な例を示す図である。

【図６】従来技術による、リレーショナル・データベー
ス表に記憶されたデータ値の簡単な例を示す図である。

【図７】従来技術による、リレーショナル・データベー
ス表に記憶されたデータ値の簡単な例を示す図である。

【図８】図３ないし７の記憶されたデータに対して行わ
れる変更の簡単な例を示す図である。

【図９】図３ないし７の記憶されたデータに対して行わ
れる変更の簡単な例を示す図である。

【図１０】本発明に従って実行される表順序付けの例を
示す図である。

【図１１】本発明に従って実行される表順序付けの例を
示す図である。

【図１２】本発明に従って実行される表順序付けの例を
示す図である。

【図１３】これによって本発明の好ましい実施形態を実
施することができる論理を示す流れ図である。

【図１４】これによって本発明の好ましい実施形態を実
施することができる論理を示す流れ図である。

【図１５】これによって本発明の好ましい実施形態を実
施することができる論理を示す流れ図である。

【図１６】これによって本発明の好ましい実施形態を実
施することができる論理を示す流れ図である。

【図１７】これによって本発明の好ましい実施形態を実
施することができる論理を示す流れ図である。

【図１８】従来技術によるデータベース・スキーマのた
めに使用可能な関係情報を示す図である。

【符号の説明】

１２ マイクロプロセッサ １６ ユーザ・インターフェース・アダプタ １８ キーボード ２０ マウス ２２ インターフェース装置 ２４ ディスプレイ装置 ２６ ディスプレイ・アダプタ ２８ メモリ ３０ 記憶装置

Claims (33)

【特許請求の範囲】
1. 【請求項１】リレーショナル・データベースの参照保全
   性を維持するために、前記データベースに対して実行さ
   れる動作を計画的に順序付けるコンピュータ・プログラ
   ムであって、前記コンピュータ・プログラムが、コンピ
   ュータを、 前記データベースの複数の表の間の挿入順序を判定する
   手段と、 前記データベースの前記複数の表の間の削除順序を判定
   する手段と、 前記データベースに対して行われる複数の変更のそれぞ
   れによって実行される動作に従い、前記変更のそれぞれ
   によって影響される前記表の特定の１つに従って、前記
   複数の変更をクラスタ化する手段と、 前記クラスタ化された変更を前記データベースに適用す
   る手段であって、さらに、 まず、前記挿入順序に従って、前記動作が挿入である前
   記クラスタ化された変更のすべてを適用する手段と、 次に、前記動作が更新である前記クラスタ化された変更
   のすべてを適用する手段と、 最後に、前記削除順序に従って、前記動作が削除である
   前記クラスタ化された変更のすべてを適用する手段とを
   含む、前記クラスタ化された変更を前記データベースに
   適用する手段として機能させるためのコンピュータ・プ
   ログラム。
2. 【請求項２】前記動作が更新である前記クラスタ化され
   た変更が、任意の順序で適用される、請求項１に記載の
   コンピュータ・プログラム。
3. 【請求項３】前記挿入順序を判定する前記手段の動作お
   よび前記削除順序を判定する前記手段の動作を、前記ク
   ラスタ化する手段の動作および前記適用する手段の動作
   の前の時に実行することができる、請求項１に記載のコ
   ンピュータ・プログラム。
4. 【請求項４】前記コンピュータ・プログラムが、リレー
   ショナル・データベース・エンジンで動作する、請求項
   １に記載のコンピュータ・プログラム。
5. 【請求項５】前記コンピュータ・プログラムが、前記変
   更を生成するアプリケーション・プログラムと別に動作
   する、請求項１に記載のコンピュータ・プログラム。
6. 【請求項６】前記クラスタ化する手段の動作および前記
   適用する手段の動作が、後続の複数の変更のそれぞれに
   ついて繰り返して実行される、請求項１に記載のコンピ
   ュータ・プログラム。
7. 【請求項７】前記適用する手段が、バッチ書込モードで
   実行される、請求項１に記載のコンピュータ・プログラ
   ム。
8. 【請求項８】前記挿入順序を判定する前記手段が、さら
   に、 前記表の選択された１つのそれぞれについて、１つまた
   は複数の関係する表を識別する手段と、 前記選択された表および前記関連する表のそれぞれの間
   で、挿入優先順位を判定する手段と、 前記選択された表がそれに関する挿入優先順位を有する
   前記関連する表の前に前記選択された表を順序付け、前
   記選択された表がそれに関する挿入優先順位を有しない
   前記関連する表の後に前記選択された表を順序付ける手
   段とを含む、請求項１に記載のコンピュータ・プログラ
   ム。
9. 【請求項９】前記削除順序を判定する前記手段が、さら
   に、 前記表の選択された１つのそれぞれについて、１つまた
   は複数の関係する表を識別する手段と、 前記選択された表および前記関連する表のそれぞれの間
   で、削除優先順位を判定する手段と、 前記選択された表がそれに関する削除優先順位を有する
   前記関連する表の前に前記選択された表を順序付け、前
   記選択された表がそれに関する削除優先順位を有しない
   前記関連する表の後に前記選択された表を順序付ける手
   段とを含む、請求項１に記載のコンピュータ・プログラ
   ム。
10. 【請求項１０】前記挿入優先順位を判定する前記手段
    が、さらに、 前記選択された表および前記関係する表の各特定の１つ
    について、前記選択された表と前記特定の関係する表と
    の間の関係が制約を有するかどうかを判定する手段と、 前記制約が存在する時に、前記制約の外部キーが前記特
    定の関係する表内に配置されているかどうかを判定する
    手段と、 前記制約が存在しない時、または前記外部キーが前記特
    定の関係する表内に配置されていない時に、前記選択さ
    れた表が前記挿入優先順位を有しないと結論する手段
    と、 前記外部キーが前記特定の関係する表内に配置されてい
    る時に、前記選択された表が前記挿入優先順位を有する
    と結論する手段とを含む、請求項８に記載のコンピュー
    タ・プログラム。
11. 【請求項１１】前記削除優先順位を判定する前記手段
    が、さらに、 前記選択された表および前記関係する表の各特定の１つ
    について、前記選択された表と前記特定の関係する表と
    の間の関係が制約を有するかどうかを判定する手段と、 前記制約が存在する時に、前記制約の外部キーが前記選
    択された表内に配置されているかどうかを判定する手段
    と、 前記制約が存在しない時、または前記外部キーが前記選
    択された表内に配置されていない時に、前記選択された
    表が前記削除優先順位を有しないと結論する手段と、 前記外部キーが前記選択された表内に配置されている時
    に、前記選択された表が前記削除優先順位を有すると結
    論する手段とを含む、請求項９に記載のコンピュータ・
    プログラム。
12. 【請求項１２】コンピュータ環境内でリレーショナル・
    データベースの参照保全性を維持するために、前記デー
    タベースに対して実行される動作を計画的に順序付ける
    システムであって、 前記データベースの複数の表の間の挿入順序を判定する
    手段と、 前記データベースの前記複数の表の間の削除順序を判定
    する手段と、 前記データベースに対して行われる複数の変更のそれぞ
    れによって実行される動作に従い、前記変更のそれぞれ
    によって影響される前記表の特定の１つに従って、前記
    複数の変更をクラスタ化する手段と、 前記クラスタ化された変更を前記データベースに適用す
    る手段であって、さらに、 まず、前記挿入順序に従って、前記動作が挿入である前
    記クラスタ化された変更のすべてを適用する手段と、 次に、前記動作が更新である前記クラスタ化された変更
    のすべてを適用する手段と、 最後に、前記削除順序に従って、前記動作が削除である
    前記クラスタ化された変更のすべてを適用する手段とを
    含む、前記クラスタ化された変更を前記データベースに
    適用する手段とを含むシステム。
13. 【請求項１３】前記動作が更新である前記クラスタ化さ
    れた変更が、任意の順序で適用される、請求項１２に記
    載のシステム。
14. 【請求項１４】前記挿入順序を判定する前記手段の動作
    および前記削除順序を判定する前記手段の動作を、前記
    クラスタ化する手段の動作および前記適用する手段の動
    作の前の時に実行することができる、請求項１２に記載
    のシステム。
15. 【請求項１５】前記システムが、リレーショナル・デー
    タベース・エンジンで動作する、請求項１２に記載のシ
    ステム。
16. 【請求項１６】前記システムが、前記変更を生成するア
    プリケーション・プログラムと別に動作する、請求項１
    ２に記載のシステム。
17. 【請求項１７】前記クラスタ化する手段の動作および前
    記適用する手段の動作が、後続の複数の変更のそれぞれ
    について繰り返して実行される、請求項１２に記載のシ
    ステム。
18. 【請求項１８】前記適用する手段が、バッチ書込モード
    で実行される、請求項１２に記載のシステム。
19. 【請求項１９】前記挿入順序を判定する前記手段が、さ
    らに、 前記表の選択された１つのそれぞれについて、１つまた
    は複数の関係する表を識別する手段と、 前記選択された表および前記関連する表のそれぞれの間
    で、挿入優先順位を判定する手段と、 前記選択された表がそれに関する挿入優先順位を有する
    前記関連する表の前に前記選択された表を順序付け、前
    記選択された表がそれに関する挿入優先順位を有しない
    前記関連する表の後に前記選択された表を順序付ける手
    段とを含む、請求項１２に記載のシステム。
20. 【請求項２０】前記削除順序を判定する前記手段が、さ
    らに、 前記表の選択された１つのそれぞれについて、１つまた
    は複数の関係する表を識別する手段と、 前記選択された表および前記関連する表のそれぞれの間
    で、削除優先順位を判定する手段と、 前記選択された表がそれに関する削除優先順位を有する
    前記関連する表の前に前記選択された表を順序付け、前
    記選択された表がそれに関する削除優先順位を有しない
    前記関連する表の後に前記選択された表を順序付ける手
    段とを含む、請求項１２に記載のシステム。
21. 【請求項２１】前記挿入優先順位を判定する前記手段
    が、さらに、 前記選択された表および前記関係する表の各特定の１つ
    について、前記選択された表と前記特定の関係する表と
    の間の関係が制約を有するかどうかを判定する手段と、 前記制約が存在する時に、前記制約の外部キーが前記特
    定の関係する表内に配置されているかどうかを判定する
    手段と、 前記制約が存在しない時、または前記外部キーが前記特
    定の関係する表内に配置されていない時に、前記選択さ
    れた表が前記挿入優先順位を有しないと結論する手段
    と、 前記外部キーが前記特定の関係する表内に配置されてい
    る時に、前記選択された表が前記挿入優先順位を有する
    と結論する手段とを含む、請求項１９に記載のシステ
    ム。
22. 【請求項２２】前記削除優先順位を判定する前記手段
    が、さらに、 前記選択された表および前記関係する表の各特定の１つ
    について、前記選択された表と前記特定の関係する表と
    の間の関係が制約を有するかどうかを判定する手段と、 前記制約が存在する時に、前記制約の外部キーが前記選
    択された表内に配置されているかどうかを判定する手段
    と、 前記制約が存在しない時、または前記外部キーが前記選
    択された表内に配置されていない時に、前記選択された
    表が前記削除優先順位を有しないと結論する手段と、 前記外部キーが前記選択された表内に配置されている時
    に、前記選択された表が前記削除優先順位を有すると結
    論する手段とを含む、請求項２０に記載のシステム。
23. 【請求項２３】リレーショナル・データベースの参照保
    全性を維持するために、前記データベースに対して実行
    される動作を計画的に順序付ける方法であって、 前記データベースの複数の表の間の挿入順序を判定する
    ステップと、 前記データベースの前記複数の表の間の削除順序を判定
    するステップと、 前記データベースに対して行われる複数の変更のそれぞ
    れによって実行される動作に従い、前記変更のそれぞれ
    によって影響される前記表の特定の１つに従って、前記
    複数の変更をクラスタ化するステップと、 前記クラスタ化された変更を前記データベースに適用す
    るステップであって、さらに、 まず、前記挿入順序に従って、前記動作が挿入である前
    記クラスタ化された変更のすべてを適用するステップ
    と、 次に、前記動作が更新である前記クラスタ化された変更
    のすべてを適用するステップと、 最後に、前記削除順序に従って、前記動作が削除である
    前記クラスタ化された変更のすべてを適用するステップ
    とを含む、前記クラスタ化された変更を前記データベー
    スに適用するステップとを含む方法。
24. 【請求項２４】前記動作が更新である前記クラスタ化さ
    れた変更が、任意の順序で適用される、請求項２３に記
    載の方法。
25. 【請求項２５】前記挿入順序を判定する前記ステップの
    動作および前記削除順序を判定する前記ステップの動作
    を、前記クラスタ化するステップの動作および前記適用
    するステップの動作の前の時に実行することができる、
    請求項２３に記載の方法。
26. 【請求項２６】前記方法が、リレーショナル・データベ
    ース・エンジンで動作する、請求項２３に記載の方法。
27. 【請求項２７】前記方法が、前記変更を生成するアプリ
    ケーション・プログラムと別に動作する、請求項２３に
    記載の方法。
28. 【請求項２８】前記クラスタ化するステップの動作およ
    び前記適用するステップの動作が、後続の複数の変更の
    それぞれについて繰り返して実行される、請求項２３に
    記載の方法。
29. 【請求項２９】前記適用するステップが、バッチ書込モ
    ードで実行される、請求項２３に記載の方法。
30. 【請求項３０】前記挿入順序を判定する前記ステップ
    が、さらに、 前記表の選択された１つのそれぞれについて、１つまた
    は複数の関係する表を識別するステップと、 前記選択された表および前記関連する表のそれぞれの間
    で、挿入優先順位を判定するステップと、 前記選択された表がそれに関する挿入優先順位を有する
    前記関連する表の前に前記選択された表を順序付け、前
    記選択された表がそれに関する挿入優先順位を有しない
    前記関連する表の後に前記選択された表を順序付けるス
    テップとを含む、請求項２３に記載の方法。
31. 【請求項３１】前記削除順序を判定する前記ステップ
    が、さらに、 前記表の選択された１つのそれぞれについて、１つまた
    は複数の関係する表を識別するステップと、 前記選択された表および前記関連する表のそれぞれの間
    で、削除優先順位を判定するステップと、 前記選択された表がそれに関する削除優先順位を有する
    前記関連する表の前に前記選択された表を順序付け、前
    記選択された表がそれに関する削除優先順位を有しない
    前記関連する表の後に前記選択された表を順序付けるス
    テップとを含む、請求項２３に記載の方法。
32. 【請求項３２】前記挿入優先順位を判定する前記ステッ
    プが、さらに、 前記選択された表および前記関係する表の各特定の１つ
    について、前記選択された表と前記特定の関係する表と
    の間の関係が制約を有するかどうかを判定するステップ
    と、 前記制約が存在する時に、前記制約の外部キーが前記特
    定の関係する表内に配置されているかどうかを判定する
    ステップと、 前記制約が存在しない時、または前記外部キーが前記特
    定の関係する表内に配置されていない時に、前記選択さ
    れた表が前記挿入優先順位を有しないと結論するステッ
    プと、 前記外部キーが前記特定の関係する表内に配置されてい
    る時に、前記選択された表が前記挿入優先順位を有する
    と結論するステップとを含む、請求項３０に記載の方
    法。
33. 【請求項３３】前記削除優先順位を判定する前記ステッ
    プが、さらに、 前記選択された表および前記関係する表の各特定の１つ
    について、前記選択された表と前記特定の関係する表と
    の間の関係が制約を有するかどうかを判定するステップ
    と、 前記制約が存在する時に、前記制約の外部キーが前記選
    択された表内に配置されているかどうかを判定するステ
    ップと、 前記制約が存在しない時、または前記外部キーが前記選
    択された表内に配置されていない時に、前記選択された
    表が前記削除優先順位を有しないと結論するステップ
    と、 前記外部キーが前記選択された表内に配置されている時
    に、前記選択された表が前記削除優先順位を有すると結
    論するステップとを含む、請求項３１に記載の方法。