|
参照制約を定義するデータベースは次の条件を満たしている必要があります。
データベースが参照整合性をサポートするためには、外部キーの概念をサポートする必要があります。外部キーは 1 つのテーブル(従属テーブルと呼ばれる)の 1 つの列または一連の列で、別のテーブル(親テーブルと呼ばれる)の主キーを参照するのに使用します。RI 規則はすべての外部キー値が有効な主キー値を参照することを必要とします。たとえば、学生は存在しない講座に登録することはできません。
CREATE TABLE または ALTER TABLE ステートメントを使用して、名前付きデータベースのテーブルにキーを定義することができます。次のセクションでは、キーの作成と変更方法について説明します。また、参照制約の例も用意されています。
データベースに参照制約を定義した後は、更新を行うアプリケーションは参照規則に従わないと失敗します。たとえば、アプリケーションが対応する親行を親テーブルに挿入する前に従属テーブルに行を挿入しようとすると、これは失敗します。詳細については、参照整合性規則を参照してください。
メモ
ファイルに参照制約が定義されている場合、これはバウンド データ ファイルです。ユーザーがこのファイルに Btrieve を使用してアクセスしようとすると、アクセスできますが、RI 制約の範囲内のアクションを実行するのに限られます。バウンド データ ファイルについての詳細は、データベース権限の理解を参照してください。
データベース テーブルに参照制約を定義した場合、従属テーブルの行の挿入と更新、および親テーブルの行の更新と削除に一定の規則が適用されます。Pervasive PSQL は、次のように制限規則とカスケード規則をサポートします。
挿入規則は制限規則です。挿入される行の外部キーは、それぞれ親テーブルの主キー値と等価である必要があります。親テーブルは、挿入しようとする行の外部キーの親行を持っている必要があり、そうでない場合は挿入は失敗します。Pervasive PSQL は、トランザクショナル データベース エンジンが、従属テーブルに自動的に挿入規則を適用するようにします。
更新規則は制限規則でもあります。外部キー値は、親テーブルの対応する主キー値に更新される必要があります。親テーブルが外部キー値に対応する親行を持たない場合、更新は失敗します。
テーブルに外部キーを定義する際に明示的に更新規則として制限規則を指定することもできますが、指定しなかった場合、Pervasive PSQL は トランザクショナル データベース エンジンに対しデフォルトでこの規則を順守させます。
外部キーを定義する際に、削除規則として制限またはカスケードを明示的に指定することができます。明示的に削除規則を指定しなかった場合、Pervasive PSQL は削除規則として制限をデフォルトと見なします。
次のガイドラインは、外部キーの削除規則を決定します。
Pervasive PSQL はこれらのガイドラインを参照制約の定義されているデータベース上で強制します。これらのガイドラインに違反する削除規則を宣言しようとすると、Pervasive PSQL はエラーの発生を示すステータス コードを返します。
Pervasive PSQL は、テーブルから従属行を削除する際、発生し得る例外を回避するために削除規則のガイドラインを強制します。これらのガイドラインがなければ発生する例外を次に示します。
自己参照テーブルの削除規則はカスケード規則である必要があります。次のステートメントは English 学部のすべての教職員を削除します。
このステートメントは、Pervasive PSQL が次の順序で行を削除する場合に成功します。
ただし、Pervasive PSQL がこれ以外の順序で行の削除を試みると、削除処理は失敗します。このような矛盾を避けるには、Head_of_Dept の削除規則にカスケード削除規則を指定します。
このガイドラインによって、最初に削除された行を(削除後に)参照するすべての行も確実に削除されるようにします。自己参照テーブルから行を削除する場合、ステートメントが、不用意にテーブル内の全部またはほとんどの行を削除しないようにしてください。
2 つ以上のテーブルのサイクルでは、テーブルそれ自体に対して連鎖削除できません。したがって、サイクル内の少なくとも 2 つの従属テーブルは制限削除規則である必要があります。
次のステートメントを実行するとします。
Faculty と Department テーブルの間の関係により、Faculty からの行の削除は、まず Faculty から、次に Department から行を削除します。Department の名前の制限規則により、ここでカスケード削除は停止します。
Pervasive PSQL が Faculty テーブルから行を削除する順によって、結果に矛盾が生じることがあります。ID が 181831941 の行を削除しようとすると、その削除処理は失敗します。Department の Name 列 の制限規則により、Pervasive PSQL は、主キーの値が Mathematics と等しい Department テーブルの最初の行を削除することができません。これは、Faculty の 2 番目の行がこの行の主キーを参照し続けるためです。
そうではなく、Pervasive PSQL が、主キーが 179321805 と 310082269 に等しい Faculty の行を最初に削除した場合、Faculty と Department のすべての行が削除されます。
この例の DELETE ステートメントの結果には一貫性があるので、行は削除されません。
複数の連鎖削除パスからの削除規則は同一である必要があります。図 2 はこのガイドラインを使用しないと発生する可能性のある 1 つの例外を示しています。図中の矢印は従属テーブルを指しています。
Faculty は Room に対し、異なる削除規則を持つ複数の連鎖削除パスで連鎖削除になっています。次のステートメントを実行するとします。
操作が成功するかどうかは、Pervasive PSQL が Faculty と Department の削除規則を確実にするため、これらにアクセスする順序に依存します。
問題を回避するため、Pervasive PSQL は、Faculty へ導く両方のパスに対する削除規則が同一であることを保証します。
|