ビューを使用したデータの挿入と更新

単一の表に対してビューを定義する場合、挿入、更新、または削除操作でビューの名前を参照可能です。 このビューが複雑であるか、または複数の表が含まれている場合、INSTEAD OF トリガーを定義して初めて、INSERT、UPDATE、MERGE、または DELETE ステートメントの中でそのビューが参照できるようになります。 ここでは、単純なケースの処理方法について説明します。ここで、 Db2 は、基本表に対する挿入または更新を行います。

挿入または更新がビュー定義に必ず適合するようにするには、WITH CHECK OPTION 文節を指定します。 次の例で、この検査を省略した、好ましくない結果をいくつか示します。

汎用プログラミングインターフェース情報の終了。

例

汎用プログラミングインターフェース情報の開始。
例
ビュー V1 が以下のように定義されていると仮定します。
CREATE VIEW V1 AS
  SELECT * FROM EMP
  WHERE DEPT LIKE 'D%'

ビュー V1 の SELECT 権限を持つユーザーは、ID が D で始まる部門内の従業員の情報を EMP 表から表示できます。EMP 表には、条件を満たす ID を持つ部門 (D11) が 1 つだけあります。

ユーザーにビュー V1 の INSERT 権限があると想定します。 SELECT および INSERT の両権限を持つユーザーは、部門 E01 の行を (誤って) 挿入することはできますが、挿入した行を選択することはできません。

例
次の例は、ビュー V1 の代替定義方法を示します。 ビュー定義に一致しない値が基本表に挿入される状態を回避できます。 このためには、WITH CHECK OPTION 文節を組み込んで、ビュー V1 を定義します。
CREATE VIEW V1 AS SELECT * FROM EMP
  WHERE DEPT LIKE 'D%' WITH CHECK OPTION;

この新しい定義では、ビュー V1 への挿入または更新は、WHERE 文節に含まれている述部 (DEPT LIKE 'D%') を満たす必要があります。 検査は重要ですが、処理コストも伴います。可能性ある挿入または更新それぞれで、ビュー定義に照らして検査する必要があります。 したがって、データ保全性の保護の利点と、パフォーマンス低下の欠点とを比較検討する必要があります。