1.9 Workspace Managerによる制約のサポート

この項では、データベース制約の使用に関連するWorkspace Managerの考慮事項について説明します。

親トピック: Workspace Managerの概要

1.9.1 参照整合性のサポート

バージョン対応表には、CASCADEオプションおよびRESTRICTオプションを使用した制約などの参照整合性制約を定義できます。ただし、その場合は、次の考慮点および制限事項が適用されます。

  • 参照整合性関係における親表がバージョン対応である場合、子表もバージョン対応である必要があります。(子表は、制約が定義されている表です。) たとえば、作成後に外部キー制約が追加された次のEMPLOYEE表定義およびDEPARTMENT表定義があるとします(つまり、各EMPLOYEE行のdept_id値は、DEPARTMENT行の既存のdept_id値と一致する必要があります)。 

    CREATE TABLE employee (
  employee_id NUMBER,
  last_name VARCHAR2(32),
  first_name VARCHAR2(32),
  dept_id NUMBER);
CREATE TABLE department (
  dept_id NUMBER,
  name VARCHAR2(32);
ALTER TABLE employee ADD CONSTRAINT emp_forkey_deptid
  FOREIGN KEY (dept_id) REFERENCES department (dept_id)
  ON DELETE CASCADE;

    この例では、DEPARTMENTが参照整合性関係における親、EMPLOYEEが子とみなされます。DEPARTMENTがバージョン対応である場合は、EMPLOYEEもバージョン対応である必要があります。この関係定義では、DEPARTMENT行が削除されると、EMPLOYEE表内のその子行もすべて削除されます(カスケード削除操作)。

  • 参照整合性関係における子表は、その親表がバージョン対応でなくてもバージョン対応にすることができます。次の例(読みやすくするために少し編集されています)では、ptという名前の親表とctという名前の子表を作成し、子表のj列と親表のid列との間の外部キー関係を指定して、子表をバージョン対応にします。 

    SQL> create table pt(id integer primary key, j integer);
Table created.

SQL> create table ct(id integer primary key, j integer);
Table created.

SQL> alter table ct add foreign key(j) references pt(id);
Table altered.

SQL> exec dbms_wm.enableversioning('ct');
PL/SQL procedure successfully completed.

    参照整合性制約を追加するときに、子表がすでにバージョン対応である場合は、BeginDDLおよびCommitDDLの使用時に、子表の特別な<table-name>_LTS表を変更する必要があります。たとえば: 

    SQL> create table pt(id integer primary key, j integer);
Table created.

SQL> create table ct(id integer primary key, j integer);
Table created.

SQL> exec dbms_wm.enableversioning('ct');
PL/SQL procedure successfully completed.

SQL> exec dbms_wm.beginddl('ct');
PL/SQL procedure successfully completed.

SQL> alter table ct_lts add foreign key(j) references pt(id);
Table altered.

SQL> exec dbms_wm.commitddl('ct');
PL/SQL procedure successfully completed.

  • 子表の外部キーは親表の主キーを参照する必要があります。(前述の項目の例を参照してください。)

  • 親表の主キーの値は更新できません。たとえば、DEPARTMENTが親表でEMPLOYEEが子表の場合、DEPARTMENTのdepartment IDは変更できません。

  • マルチレベルの参照整合性制約はバージョン対応表に適用できます。たとえば、表EMPLOYEE(emp_id、dept_id)に、部門IDが表DEPARTMENT(dept_id、dept_name、loc_id)に存在する必要があるという制約を適用でき、表DEPARTMENT(dept_id、dept_name、loc_id)に、位置IDが表LOCATION(loc_id、loc_name)に存在する必要があるという制約を適用できます。ただし、関連するすべての参照整合性制約がRestrictルールを伴わないかぎり、マルチレベルの参照整合性制約に関連するすべての表を、まとめてバージョン対応およびバージョン非対応にする必要があります。関連するすべての制約にRestrictルールがある場合は、表をまとめてバージョン対応にすることも、子表、親表の順で1つずつバージョン対応にすることもできます。表名は、カンマで区切ったリストとしてEnableVersioningプロシージャおよびDisableVersioningプロシージャに渡す必要があります。

Workspace Managerは、ALL_WM_RIC_INFO静的データ・ディクショナリ・ビューおよびUSER_WM_RIC_INFO静的データ・ディクショナリ・ビュー(「Workspace Managerの静的データ・ディクショナリ・ビュー」を参照)を使用して、参照整合性のサポートに関連する情報を保持します。

2つの表が関連する参照整合性制約を追加、削除、使用可能または使用禁止にする必要がある場合は、表をバージョン対応にする前に、これらの操作を実行すると便利です。ただし、次のステップを実行すると、バージョン対応表が関連する参照整合性制約を追加、削除、使用可能または使用禁止にできます。

  1. 親表がバージョン対応にされている場合、親表を指定してDDLセッションを開始します。

  2. 子表を指定して、DDLセッションを開始します。

  3. 子表の<table-name>_LTS表を変更して、外部キー制約を追加します。バージョン対応表が参照先表の場合は、親表の<table-name>_LTSを指定します。<table-name>_LTS表の詳細とバージョン対応表に対するDDL操作の実行の詳細は、「バージョン対応表と関連するDDL操作」を参照してください。)

  4. 子表を指定して、DDL変更をコミットします。

  5. 親表がバージョン対応にされている場合、親表を指定してDDLの変更をコミットします。

外部キー制約の追加例を例1-3に示します。EMPLOYEE表およびDEPARTMENT表はバージョン対応で、次のとおり定義されていると想定します。 

EMPLOYEE(emp_id number  primary key, dept_id number)
DEPARTMENT(dept_id number  primary key, dept_name varchar2(30))

例1-3 参照整合性制約の追加

-- Begin a DDL session on the parent table.
DBMS_WM.BeginDDL('DEPARTMENT'); 

-- Begin a DDL session on the child table.
DBMS_WM.BeginDDL('EMPLOYEE'); 

-- Add the constraint between EMPLOYEE_LTS and DAPATMENT_LTS.
ALTER TABLE employee_lts ADD CONSTRAINT employee_fk FOREIGN KEY (dept_id)
   REFERENCES department_lts(dept_id);

-- Commit DDL on the child table (transfers the constraint on employee_lts
-- to employee and drops employee_lts). 
EXECUTE DBMS_WM.CommitDDL('EMPLOYEE'); 

-- Commit DDL on the parent table (drops the department_lts table). 
EXECUTE DBMS_WM.CommitDDL('DEPARTMENT');

DDLセッション中(BeginDDLプロシージャをコールした場合)、1つの表がバージョン対応で、もう1つの表がバージョン非対応の場合、2つの表が関連する参照整合性制約を追加、削除、使用可能または使用禁止にできません。両方の表が、バージョン対応である必要があります。

親トピック: Workspace Managerによる制約のサポート

1.9.1.1 参照整合性制約を持つ表のDML操作でのロック

参照整合性制約を持つバージョン対応表に対してデータ操作言語(DML)操作が実行された場合、Workspace Managerは共有ロックを取得し、次の条件が規定されます。

  • 子表の外部キーに影響する挿入または更新操作中は、親表での削除操作は実行できません。たとえば、DEPARTMENTが親表、EMPLOYEEが子表の場合、新規従業員の追加中、または既存の従業員の異なる部門への割当て中に部門の削除はできません。

  • 親表での削除操作中は、子表に対して外部キー列に影響する挿入または更新操作は実行できません。たとえば、部門の削除中、新規従業員の追加および既存の従業員の異なる部門へ割当てはできません。

ノート:

共有ロックおよび排他ロックの説明など、Workspace Managerによるロックについては、「Workspace Managerでのロック管理」を参照してください。

次のどちらかのDML操作を複数のセッションで同時に実行できます。ただし、次の両方を同時には実行できません。

  • 子表の外部キー列に影響する挿入操作または更新操作。

  • 親表での削除操作。

次のWorkspace Manager操作のいずれかを、複数のセッションで同時に実行できます。

  • MergeTableプロシージャを使用して、異なる作業領域で子表または親表に変更を適用します。

  • MergeTableプロシージャを使用して、1つの作業領域で子表に変更を適用し、別の作業領域で子表に挿入または更新をします。

  • MergeTableプロシージャを使用して、1つの作業領域で親表に変更を適用し、別の作業領域で親表から削除します。

次の場合、セッションは他のセッションが終了するまでブロックされます。

  • セッションが1つの作業領域で子表への変更をマージしようとしており、別のセッションが別の作業領域で親表への変更をマージしようとしている場合。

  • セッションが1つの作業領域で子表への変更をマージしようとしており、別のセッションが親表から削除しようとしている場合。

  • セッションが1つの作業領域で親表への変更をマージしようとしており、別のセッションが子表へ挿入、または子表の外部キーの値を変更しようとしている場合。

親トピック: 参照整合性のサポート

1.9.2 一意制約

一意制約が定義されている表をバージョン対応にすることができます。次の内容がサポートされています。

  • 1列または複数列に対するUNIQUE制約

  • 1列または複数列の一意索引

  • 表のファンクションの一意索引

NULL値の取扱いは、バージョン対応表の場合もバージョン対応でない表の場合も同じです。

Workspace Managerは、次の静的データ・ディクショナリ・ビュー(「Workspace Managerの静的データ・ディクショナリ・ビュー」を参照)を使用して、一意制約のサポートに関連する情報を保持します。

親トピック: Workspace Managerによる制約のサポート

1.9.3 SET NULL制約

SET NULL制約はWorkspace Managerでサポートされません。表がSET NULL制約を持つ場合、この制約は表がバージョン対応になったときRESTRICTオプションに変換されます。

たとえば、ON DELETE SET NULL制約はON DELETE RESTRICTへ変換されます。

親トピック: Workspace Managerによる制約のサポート