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;

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 に設定して、コミットが実行されるまでデータの一貫性が失われることを許容してください。

また、プライマリキーに加えた変更に合わせて、外部キーが自動的に修正されるように定義することもできます。上の例では、Employees テーブルから Departments テーブルへの外部キーが ON DELETE CASCADE を使用して定義された場合、部署 ID を削除すると、Employees テーブルの対応するエントリが自動的に削除されます。

ここまでの例では、整合性のないデータベースが確定的なものとしてコミットされることはありません。変更することによってデータベースの整合性が失われる可能性がある場合、SQL Anywhere では代替の動作もサポートされています。

• wait_for_commit オプション
• データ整合性