参照整合性の設定

参照整合性（RI）を使用すると、同一のフィールド値がそのテーブルまたはほかのテーブルに存在するかどうかに基づき、データの変更または、変更や追加や削除の禁止を行うことができます。

いくつかの重要な用語を明確にすることにより、RI がよく理解できます。

規則は、原因とその効果の単純なステートメントで、データベースに定義された RI システムによって実行されます。

たとえば、削除規則によって、主キーを持つレコードが削除されたときに、外部キーを持つレコードに何が起きるかが次のように定義されているとします。「'Bhargava Building' を含むレコードが削除されたとき、そのレコードを参照するテーブル A のすべての行は削除される。」

削除規則は、主キー値を参照する外部キーがある場合、その主キー値を含む行が削除されるのを禁止することもできます。

更新規則は、ユーザーがレコードを更新またはレコードを追加しようとしたときに、外部キーを含むレコードに何が起こるかを定義したもので、次のようなものです。「ユーザーがテーブル B に新しいレコードを追加しようとしたとき、ビル名がテーブル C に存在しなければ、追加することを拒否する。」

主キーは規則が従属する 1 つまたは複数の列です。どのテーブルでも主キーは 1 つだけ許可されており、重複値は許可されていません。更新規則では、主キーというのは、レコードの更新または追加が許可されるかどうかを判断するために、更新または追加した列と比較される列のことです。

例 A では、"Bhargava Building" を含む列が主キーです。

例 B では、テーブル C のビル名を含む列が主キーです。

外部キーは、処理方法を決定するために主キーと比較される 1 つまたは複数の列です。

前述の例 A では、テーブル A の "Bhargava Building" を含む列が主キーです。

前述の例 B では、テーブル B のビル名を含む列が外部キーです。

カスケード規則は、データベースがある操作が起こることを許可し、ほかのテーブルまたは行を最初の操作と同期をとるように変更することによって RI を確実にする規則です。たとえば、カスケード削除規則が定義されていると、主キーテーブルでのレコードの削除により、データベースは削除された行の主キーと同じ値の外部キーを持つデータベース中のすべての行を検索して削除します。

制限規則は、データベースに既に存在する値に基づく操作を許可するかどうかをデータベースが決定するのに使用する規則です。たとえば、更新制限規則が定義されている場合、外部キーを含む行をテーブルに追加しようとすると、データベースエンジンは外部キーフィールドの値を主キーの値と比較します。同じ値の主キーを持つ行が存在しない場合、その行を外部キーテーブルに追加することは許可されません。

このセクションでは、主キーおよび外部キーの概念についてより詳細に説明します。

表 25 主キーおよび外部キー
テーブル A	テーブル B
•student_ID	•Name	•stud_ID	•Class
20543	John	20543	ENG -101
20577	Mary	20543	AST-202

上記の例では、テーブル 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 などのデータ型である必要があります。主キーと外部キーのデータ型には互換性が必要です。参照整合性を確実にするために、必要なだけの外部キーをいくつでも設定することができます。複数の外部キーは同一の主キーを参照することができます。

主キーを持つテーブルは親テーブルと呼ばれ、外部キーを持つテーブルは子テーブルと呼ばれます。いったんキーが定義されると、表 26 に示すように選択できる動作の範囲が限られます。必要なだけ規則を定義することができますが、タイプごとには 1 つしか定義できません。たとえば、削除制限規則を定義した場合、同じキーにカスケード削除規則を定義することはできません。これは、2 つの動作が相互に排他的であるためです。

表 26 RI 規則の選択
行いたい動作	... 定義する規則
B.stud_ID の値が A.student_ID のいずれかの値に一致しなければ、テーブル B に行が追加されたり更新されたりすることを許可しない。	更新制限
B.stud_ID の値がその行と一致しなければ、テーブル A の行を削除することを許可しない。	削除制限
テーブル A から行が削除された場合、その削除された A.student_ID の値に一致する B.stud_ID のすべての行をテーブル B から削除する。	削除カスケード

前述の例で説明すると、更新制限規則を設定することにより、新規または更新された行の 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 を作成するとします。

次に、外部キーを追加し、カスケード削除規則を設定するようにテーブルを変更します。

次のステートメントにより、テーブル内のすべての行が削除されます。

c1 = 2 の行だけでなく、すべての行が削除されるのはなぜでしょう?

削除カスケードは、削除された主キーと同じ値の外部キーを持つすべての行を削除します。2 番目の行は最初の行と外部キー関係があります。同様に、3 番目の行は 2 番目の行と、4 番目の行は 3 番目の行と外部キー関係があります。外部キー関係があることで、すべての行に渡ってカスケード削除規則が適用されるため、1 行目により 2 行目が、2 行目により 3 行目が、そして 3 行目により 4 行目が削除されることになります。

Pervasive PSQL は、相互に参照するテーブルでの循環削除カスケードを許可していません。たとえば、テーブル d1 と d2 があるとして、次のようなシナリオを考えます。

次の変更ステートメントは許可されます。

次の変更ステートメントは許可されません。テーブル d1 と d2 には既に削除カスケードの関係があるからです。

主キーは、SQL ステートメントまたは Pervasive PSQL Control Center を使用して作成することができます。『Pervasive PSQL User's Guide』の列のタスクを参照してください。

CREATE TABLE ステートメントで PRIMARY KEY キーワードを使用して、テーブル作成時に主キーを作成することができます。主キーは 1 つまたは複数の列で構成されます。次の例では id が作成され、主キーに指定されることを示しています。

次の例は複数の列を使ってユニークな値を持つ主キーを作成する方法を示しています。

主キーに指定した単一または複数の列に UNIQUE 属性を指定したかどうかに関わらず、データベースエンジンはその列に重複値とヌル値を許可しないインデックスを自動的に作成します。どのような場合もキー列にヌル値は許可されません。すべての主キー値はユニークです。

ほかの例については、『SQL Engine Reference』の CREATE TABLEを参照してください。

PCC を使用して、または ADD PRIMARY KEY を使った ALTER TABLE ステートメントによって、既存のテーブルに主キーを追加することができます。『Pervasive PSQL User's Guide』の列に主キーを設定または削除するにはおよび SQL Editor を参照してください。

主キーは重複およびヌル値を許可しない列にしか作成することができません。

必要な場合には、列属性を変更し、その列を主キーに設定することを同時に行うことができます。SQL を使った例を示します。

複数の列から成る主キーを追加したい場合は、キーを分けて追加する必要があります。

ほかの例については、『SQL Engine Reference』のALTER TABLEを参照してください。

外部キーは、SQL ステートメントまたは Pervasive PSQL Control Center を使用して作成することができます。外部キーを作成するときに、同時に関連する規則も定義できます。同一のキーに複数の規則を定義することができます。関連する規則を指定しないで外部キーを作成した場合、更新と削除はどちらもデフォルトの参照整合性によって制限されます。

列の定義で REFERENCES キーワードを使用して、テーブル作成時に外部キーを作成することができます。外部キーは 1 つまたは複数の列で構成されます。列のデータ型は、この外部キーが参照する主キーと同じでなければなりません。次の例では your_id が作成され、mytable.id を参照する外部キーに指定されることを示しています。

ステートメントの最後に外部キーの指定を追加することもできます。キーに複数列を使用する場合、この技法を使う必要があります。

外部キーを作成すると、データベースエンジンは指定された列にインデックスを追加します。

ほかの例については、『SQL Engine Reference』のCREATE TABLEを参照してください。

PCC を使用して、または ADD FOREIGN KEY を使った ALTER TABLE ステートメントによって、既存のテーブルに外部キーを追加することができます。『Pervasive PSQL User's Guide』の外部キーのタスクおよび SQL Editor を参照してください。

次の例ではこの外部キーに削除規則と更新規則の 2 つの規則が定義されています。

DELETE CASCADE は慎重に使用してください。削除カスケードに記載されている例を参照してください。

ほかの例については、『SQL Engine Reference』のALTER TABLEを参照してください。

Pervasive PSQL は、リレーショナルインターフェイスとトランザクショナルインターフェイスの両方を介して同一データへの同時アクセスをサポートするように設計されていますが、リレーショナル（SQL）データベースアーキテクチャの機能によって、リレーショナルアクセスを妨げるものがあります。たとえば、参照整合性（RI）のようなリレーショナルアクセスを制限するように設計された機能は、データ整合性という点では Btrieve アクセスも制限します。

整合性の設定、バウンドデータベース、ODBC/SQL セキュリティ、トリガー、参照整合性、およびオーナーネームなどの機能をトランザクショナル（Btrieve）アプリケーションが使用するデータベースに実装するには、あらかじめこれらの機能について完全に理解している必要があります。ほとんどの場合、一挙両得のデータベースアクセスを得られますが、セキュリティ、参照整合性、およびトリガーはアクセスやオペレーションに制約を設けるため、一部の Btrieve オペレーションは、それらの実装によって制限されたり妨害されたりする場合があります。

整合性の設定、バウンドデータベース、セキュリティ、トリガー、または参照整合性を使用している場合には、データまたはファイルへの Btrieve アクセス時、そのデータに設定されているバインドおよび制約に違反すると、Btrieve アクセスが制限されたりアクセスできなくなったりすることがあります。トリガーと RI は主として Btrieve API を介したデータの操作能力を制限します。

セキュリティとオーナーネームは、適切なアカウント、アクセス権、およびパスワードを持たないデータへのアクセスまたは操作能力を制限する場合があります。これらの機能について考えられるさまざまな組み合わせはたくさんあるので、最も一般的な組み合わせのみを以下に一覧表示します。

表 27 リレーショナル制約と Btrieve アクセス間の相互作用
条件						結果
DDF の有無	整合性の設定	バウンドデータベース	リレーショナルセキュリティの使用	トリガーの使用	RI の使用	Btrieve アクセス可能	SQL/ODBC アクセス可能
No	-	-	-	-	-	Yes	No
Yes	No	No	No	No	-	Yes	Yes
Yes	No	No (1)	No	Yes (2)	-	Yes (2)	Yes
Yes	Yes	No	No	No	No	Yes	Yes
Yes	Yes	No	Yes	No	No	Yes (3)	Yes (3)
Yes	Yes	No (1)	Yes	No	Yes	Yes (4)	Yes (3) (4)
Yes	Yes	No (1)	Yes	Yes (2)	No	Yes (1)	Yes (3)
Yes	Yes	Yes	No	No	No	Yes	Yes
Yes	Yes	Yes	Yes	No	No	Yes (3)	Yes (3)
Yes	Yes	Yes (1)	Yes	No	Yes	Yes (2) (4)	Yes (3) (4)
Yes	Yes	Yes (1)	Yes	Yes (2)	No	Yes (2) (3)	Yes (3)

（1）データベースにバウンドデータベースが設定されているかどうかに関係なく、データベースエンジンは、データファイルにトリガーある場合、外部キーがある場合、あるいは外部キーで参照される主キーがある場合には、自動的にデータファイルをバウンドとしてスタンプします。バウンドデータベースやファイルの詳細については、バウンドデータベースを参照してください。

（2）テーブルにトリガーを追加すると、Btrieve インターフェイスはトリガーの実行を引き起こすあらゆるオペレーションについて、そのファイルへのアクセスが妨げられます。トリガーは Btrieve インターフェイスを介したデータベース操作には作用しないため、このロックアウト動作によってデータの一貫性が保持されます。詳細については、バウンドデータベースと整合性の設定を参照してください。

（3）データベースまたはファイルがセキュリティで保護されている場合、ユーザーがそのファイルに対する権限（リレーショナルユーザー名とパスワード、または有効な Btrieve オーナーネーム）を持っているのであれば、アクセスは許可されます。セキュリティで保護されたデータベース内にあるがオーナーネームが設定されていないファイルには、Btrieve ユーザーはアクセスできません。Btrieve オーナーネームが既に設定されているファイルにリレーショナルセキュリティを最初に設定するとき、Master ユーザーがオーナーネームを使ってユーザーにリレーショナル権限を付与する必要があります。詳細については、Pervasive PSQL セキュリティを参照してください。

（4）テーブルに参照整合性制約が含まれており、そのデータベースで整合性の設定が有効になっている場合、制約に違反する Btrieve および SQL 操作は共に行えません。このメカニズムにより、アクセス方法に関係なくデータの整合性が保たれます。

名前付きデータベースに［整合性の設定］属性を指定しない場合、データベースエンジンは参照整合性、トリガー、セキュリティ規則のいずれも強制しません。名前付きデータベースに［整合性の設定］属性を指定すると、データのアクセスに使用する方法とは無関係に、MicroKernel はデータベースの定義済みセキュリティ、参照整合性（RI）およびトリガーを設定できます。MicroKernel は以下のようにこれらの規則を設定します。

•Btrieve ユーザーはリレーショナルセキュリティの制約を受けません。ファイルにオーナーネームが設定されている場合、それは有効なままです。ファイルにオーナーネームがない場合、Btrieve ユーザーはリレーショナルセキュリティ制約に関係なくデータにアクセスできます。Btrieve オペレーションは RI やそれ以外のデータベースに定義されているすべての制約に加え、以下に示すトリガー制限の影響を受けます。

表 28 Btrieve アクセスの制限－整合性の設定
ファイルの制約	Btrieve を使ったアクセスで許可されるレベル
RI 制約の定義あり	ユーザーはデータのアクセス、および RI 制約の範囲内でのオペレーションの実行が可能です。
INSERT トリガーの定義あり	読み取り専用、更新、および削除オペレーションが許可されます。
UPDATE トリガーの定義あり	読み取り専用、挿入、および削除オペレーションが許可されます。
DELETE トリガーの定義あり	読み取り専用、更新、および挿入オペレーションが許可されます。

バウンドファイルに複数の制約が存在する場合、アクセスレベルは最大限の制約または制約の組み合わせに従います。たとえば、ファイルに INSERT トリガーと UPDATE トリガーが定義されている場合、Btrieve ユーザーは読み取り専用および削除アクセスのみが行えます。

「整合性の設定」が直接「バウンドデータベース」に関連付けられていません。データベースは整合性の設定なしでバインドされるか、データベースはバインドされずに整合性の設定を設定されます。

名前付きデータベースに「バインド」属性を指定した場合、そのデータベースの DDF およびデータファイルはほかのデータベースとは関連付けることができません。また、バウンドデータファイルを、データベース内の複数のテーブル定義と関連付けることもできません。新しいテーブルまたは DDF をバウンドデータベースに追加すると、データベースエンジンが自動的に新しいオブジェクトのバインドを行います。この動作により、予測できない動作やデータ整合性を壊すことになる矛盾を防ぎます。たとえば、同じデータベース内の 2 つの異なるテーブル定義に同じデータファイルを使用した場合、一方のテーブルに RI 規則を定義し、もう一方には定義しないでおくことができます。この場合、RI 規則を持たないテーブルに行を挿入することは、もう一方のテーブルの RI 規則に違反することになります。データファイルと DDF をバインドすることによりこのような矛盾を防ぎます。

DDF およびデータファイルは、個々にバインドできます。データファイルにトリガーがある場合、外部キーがある場合、または外部キーで参照される主キーがある場合、データベースエンジンは自動的にそのデータファイルをバインドデータファイルとして特徴付けます。これらのファイルは別のデータベースと共有できず、複数のテーブル定義に関連付けられることもできません。

データファイルがバインドされていることは、そのデータファイルへの Btrieve アクセスには直接影響しません。ただし、バインドされたファイルには Btrieve アクセスを制限するほかの制約があることがあります。