|
参照整合性(RI)を使用すると、同一のフィールド値がそのテーブルまたはほかのテーブルに存在するかどうかに基づき、データの変更または、変更や追加や削除の禁止を行うことができます。
いくつかの重要な用語を明確にすることにより、RI がよく理解できます。
規則は、原因とその効果の単純なステートメントで、データベースに定義された RI システムによって実行されます。
たとえば、削除規則によって、主キーを持つレコードが削除されたときに、外部キーを持つレコードに何が起きるかが次のように定義されているとします。「'Bhargava Building' を含むレコードが削除されたとき、そのレコードを参照するテーブル A のすべての行は削除される。」
削除規則は、主キー値を参照する外部キーがある場合、その主キー値を含む行が削除されるのを禁止することもできます。
更新規則は、ユーザーがレコードを更新またはレコードを追加しようとしたときに、外部キーを含むレコードに何が起こるかを定義したもので、次のようなものです。「ユーザーがテーブル B に新しいレコードを追加しようとしたとき、ビル名がテーブル C に存在しなければ、追加することを拒否する。」
主キーは規則が従属する 1 つまたは複数の列です。どのテーブルでも主キーは 1 つだけ許可されており、重複値は許可されていません。更新規則では、主キーというのは、レコードの更新または追加が許可されるかどうかを判断するために、更新または追加した列と比較される列のことです。
例 A では、"Bhargava Building" を含む列が主キーです。
例 B では、テーブル C のビル名を含む列が主キーです。
外部キーは、処理方法を決定するために主キーと比較される 1 つまたは複数の列です。
前述の例 A では、テーブル A の "Bhargava Building" を含む列が主キーです。
前述の例 B では、テーブル B のビル名を含む列が外部キーです。
カスケード規則は、データベースがある操作が起こることを許可し、ほかのテーブルまたは行を最初の操作と同期をとるように変更することによって RI を確実にする規則です。たとえば、カスケード削除規則が定義されていると、主キー テーブルでのレコードの削除により、データベースは削除された行の主キーと同じ値の外部キーを持つデータベース中のすべての行を検索して削除します。
制限規則は、データベースに既に存在する値に基づく操作を許可するかどうかをデータベースが決定するのに使用する規則です。たとえば、更新制限規則が定義されている場合、外部キーを含む行をテーブルに追加しようとすると、データベース エンジンは外部キー フィールドの値を主キーの値と比較します。同じ値の主キーを持つ行が存在しない場合、その行を外部キー テーブルに追加することは許可されません。
このセクションでは、主キーおよび外部キーの概念についてより詳細に説明します。
上記の例では、テーブル A の student_ID
(A.student_ID
)は IDENTITY データ型で、2 つの行が同じ値を持つことを許可していません。学生はそれぞれユニークな ID 番号を持ちます。student_ID
をテーブル A の主キーとして定義します。
それから、テーブル B の stud_ID
(B.stud_ID
)を A.student_ID
を参照する外部キーとして定義します。stud_ID
のデータ型は、IDENTITY と比較できる INTEGER などのデータ型である必要があります。主キーと外部キーのデータ型には互換性が必要です。参照整合性を確実にするために、必要なだけの外部キーをいくつでも設定することができます。複数の外部キーは同一の主キーを参照することができます。
主キーを持つテーブルは親テーブルと呼ばれ、外部キーを持つテーブルは子テーブルと呼ばれます。いったんキーが定義されると、表 30 に示すように選択できる動作の範囲が限られます。必要なだけ規則を定義することができますが、タイプごとには 1 つしか定義できません。たとえば、削除制限規則を定義した場合、同じキーにカスケード削除規則を定義することはできません。これは、2 つの動作が相互に排他的であるためです。
前述の例で説明すると、更新制限規則を設定することにより、新規または更新された行の B.stud_ID
の値は必ず A.student_ID
にも存在していることが保証されます。テーブル B に行を追加できるようにするには、その前に、テーブル A に行があることが必要です。言い方を変えると、子行を作成する前に少なくとも 1 つの親行を作成する必要があります。
例では、削除制限規則を設定することにより、テーブル A の行は、テーブル B のいずれかの行がその行を参照している場合は削除できないことが保証されます。Name の値が "John" である行は、John の student_ID がテーブル B で参照されているため、削除できません。
John の student_ID を参照するテーブル B の行がすべて削除されたら、テーブル A から John の行を削除することができます。
例では、削除カスケード規則を設定することにより、Name 値が "John" の行が削除された場合、テーブル B の両方の行が削除されることを保証します。
Pervasive PSQL では、自己参照するテーブルに対し、循環するカスケード削除を使用できます。このため、削除カスケードは慎重に使用してください。親テーブル、子テーブル、または両テーブルのすべてのレコードを不用意に削除しないようにしてください。
このようなカスケード削除がどのようにして発生するかをわかりやすくするために例を示します。2 つの列を持つテーブル d3 を作成するとします。
CREATE TABLE d3 (c1 INT PRIMARY KEY, c2 INT) INSERT INTO d3 VALUES (2.2) INSERT INTO d3 VALUES (3.2) INSERT INTO d3 VALUES (1.3) INSERT INTO d3 VALUES (4,1)
次に、外部キーを追加し、カスケード削除規則を設定するようにテーブルを変更します。
次のステートメントにより、テーブル内のすべての行が削除されます。
c1 = 2 の行だけでなく、すべての行が削除されるのはなぜでしょう?
削除カスケードは、削除された主キーと同じ値の外部キーを持つすべての行を削除します。2 番目の行は最初の行と外部キー関係があります。同様に、3 番目の行は 2 番目の行と、4 番目の行は 3 番目の行と外部キー関係があります。外部キー関係があることで、すべての行に渡ってカスケード削除規則が適用されるため、1 行目により 2 行目が、2 行目により 3 行目が、そして 3 行目により 4 行目が削除されることになります。
Pervasive PSQL は、相互に参照するテーブルでの循環削除カスケードを許可していません。たとえば、テーブル d1 と d2 があるとして、次のようなシナリオを考えます。
次の変更ステートメントは許可されます。
次の変更ステートメントは許可されません。テーブル d1 と d2 には既に削除カスケードの関係があるからです。
|