更新オペレーションまたは削除オペレーションを行う場合にも、外部キー・エラーが発生する可能性があります。たとえば、Departments テーブルから R&D 部を削除するとします。DepartmentID フィールドは Departments テーブルのプライマリ・キーなので、1 対多の関係の「1」の側を構成します (対応する外部キーは Employees テーブルの DepartmentID フィールドで、「多」の側を構成します)。1 対多の関係の「1」のレコードは、対応する「多」のレコードすべてが削除されるまで削除できません。
Departments テーブルの R&D 部 (DepartmentID は 100) を削除するとします。R&D 部を参照するその他のレコードがデータベース内にあることを示すエラーがレポートされて、削除オペレーションが実行されません。R&D 部を削除するには、次のように、その部署に所属しているすべての従業員を削除する必要があります。
DELETE FROM Employees WHERE DepartmentID = 100; |
これで、R&D 部に所属するすべての従業員が削除されたため、R&D 部を削除することができます。
DELETE FROM Departments WHERE DepartmentID = 100; |
次の ROLLBACK 文を入力して、データベースのこれらの変更をキャンセルしてください。
ROLLBACK; |
たとえば、Employees テーブルの DepartmentID フィールドを変更するとします。DepartmentID フィールドは Employees テーブルの外部キーなので、1 対多の関係の「多」の側を構成します (対応するプライマリ・キーは Departments テーブルの DepartmentID フィールドで、「1」の側を構成します)。1 対多の関係の「多」の側のレコードは、「1」の側のレコードに対応しないかぎり、つまり参照するプライマリ・キーがなければ変更できません。
たとえば次の UPDATE 文を実行すると、整合性エラーが発生します。
UPDATE Employees SET DepartmentID = 600 WHERE DepartmentID = 100; |
「テーブル 'Employees' の外部キー 'FK_DepartmentID_DepartmentID' に対応するプライマリ・キーの値がありません
」というエラー・メッセージが表示されるのは、DepartmentID が 600 である部署が Departments テーブルにないからです。
Employees テーブルの DepartmentID フィールドの値を変更するには、Departments テーブルの既存の値に対応する必要があります。次に例を示します。
UPDATE Employees SET DepartmentID = 300 WHERE DepartmentID = 100; |
この文は、DepartmentID 300 は既存の Finance 部に対応するので実行できます。
次の ROLLBACK 文を入力して、データベースのこれらの変更をキャンセルしてください。
ROLLBACK; |
前述の例で、それぞれのコマンドの実行時にデータベースの整合性が検査されています。データベースの整合性を失わせる可能性があるオペレーションは実行されません。
wait_for_commit オプションを使用すると、コミット時まで整合性が検査されないようにデータベースを設定することができます。これは、変更を加えている間にデータの一貫性が一時的に失われる可能性があるような変更の必要がある場合に便利です。たとえば、Employees テーブルと Departments テーブルの R&D 部を削除するとします。これらのテーブルには相互参照があり、かつ削除は一度に 1 テーブルずつ実行する必要があるため、削除中はテーブル間で一貫性が失われます。この場合、データベースでは削除が完了するまでコミットを実行できません。wait_for_commit オプションを On に設定して、コミットが実行されるまでデータの一貫性が失われることを許容してください。wait_for_commit オプション [データベース]を参照してください。
また、プライマリ・キーに加えた変更に合わせて、外部キーが自動的に修正されるように定義することもできます。上の例では、Employees テーブルから Departments テーブルへの外部キーが ON DELETE CASCADE を使用して定義された場合、部署 ID を削除すると、Employees テーブルの対応するエントリが自動的に削除されます。
ここまでの例では、整合性のないデータベースが確定的なものとしてコミットされることはありません。変更することによってデータベースの整合性が失われる可能性がある場合、SQL Anywhere では代替の動作もサポートされています。データ整合性の確保を参照してください。
Copyright © 2009, iAnywhere Solutions, Inc. - SQL Anywhere 11.0.1 |