CREATE VIEW ステートメント

呼び出し

このステートメントは、アプリケーション・プログラムに組み込んだり、動的 SQL ステートメントを使用して発行したりすることができます。 これは、DYNAMICRULES の実行動作がパッケージに効力を持つ場合にのみ、動的に準備できる実行可能ステートメントです (SQLSTATE 42509)。

許可

グループ特権は、CREATE VIEW ステートメントで指定された表やビューに対しては考慮されません。

特権は、フェデレーテッド・データベースのニックネームにビューを定義するときには考慮されません。 このニックネームで示されている表またはビューのデータ・ソースの許可要件は、照会の処理時に適用されます。 ステートメントの許可 ID は、別のリモート許可 ID へマップできます。

既存のビューを置換するには、ステートメントの許可 ID が既存のビューの所有者でなければなりません (SQLSTATE 42501)。

構文

root-view-definition

subview-definition

oid-column

with-options

under-clause

説明

OR REPLACE

ビューの定義が現行のサーバー上に存在している場合に、そのビューの定義を置換するために指定します。 既存の定義は、新しい定義がカタログ内で置換される前に効率的にドロップされます。ただし、ビューに対して付与された特権は影響を受けないという例外があります。 このオプションは、ビューの定義が現行のサーバー上に存在しない場合は無視されます。 このオプションは、オブジェクトの所有者しか指定できません。

ビュー名

ビューの名前を指定します。 暗黙または明示の修飾子を含む名前は、 カタログに記述されている表、ビュー、ニックネーム、 または別名を指定するものであってはなりません。 修飾子は、SYSIBM、SYSCAT、SYSFUN、または SYSSTAT であってはなりません (SQLSTATE 42939)。

この名前は、作動不能ビューの名前と同じにすることができます ( 作動不能ビューを参照)。 このような場合、作動不能なビューは、 CREATE VIEW ステートメントに指定した新しいビューによって置き換えられます。 作動不能なビューが置き換えられると、ユーザーに警告 (SQLSTATE 01595) が出されます。 BIND オプション SQLWARN を NO に設定してアプリケーションがバインドされた場合は、 警告は戻されません。

column-name

ビューの列の名前を指定します。 列名のリストを指定する場合、リスト中の列の名前の数は、 全選択の結果表の列の数と同じ数でなければなりません。 各 column-name (列名) は、固有、しかも非修飾でなければなりません。 列名のリストの指定がない場合、ビューの列は、全選択の結果表の列名を継承します。

全選択の結果表の列名が重複している場合、または無名の列がある場合には、 列名のリストを指定する必要があります (SQLSTATE 42908)。 無名列とは、定数、関数、式、またはセット演算から派生した列で、 選択リストの AS 節によって名前が指定されていない列を指します。

OF タイプ名

ビューの列が type-name で指定される構造化タイプの属性に基づいていることを指定します。 type-name の指定にスキーマ名が含まれていない場合、 そのタイプ名は SQL パス上のスキーマを探索することによって決まります (このパスは、 静的 SQL の場合は FUNCPATH プリプロセス・オプションによって、 動的 SQL の場合は CURRENT PATH レジスターによって定義されます)。 ここに指定するタイプ名は、既存のユーザー定義タイプ名で (SQLSTATE 42704)、 かつインスタンス化の可能な構造化タイプでなければなりません (SQLSTATE 428DP)。

MODE DB2SQL

この節は、型付きビューのモードを指定するために使用されます。 これは、現在サポートされている唯一有効なモードです。

UNDER スーパービュー名

このビューが superview-name のサブビューであることを指定します。 スーパービューは既存のビューでなければならず (SQLSTATE 42704)、 このビューは type-name のすぐ上位にあるスーパータイプである 構造化タイプで定義する必要があります (SQLSTATE 428DB)。 view-name と superview-name のスキーマ名は、 同じでなければなりません (SQLSTATE 428DQ)。 superview-name で識別されるビューには、 type-name を使用して既に定義されている既存のサブビューがあってはなりません (SQLSTATE 42742)。

ビューの列には、スーパービューのオブジェクト ID 列が含まれています。 オブジェクト ID 列のタイプは REF(type-name) に変更されており、 type-name の属性に基づく列が続きます (ここでいうタイプには、 スーパータイプの属性も含まれていることを念頭に置いてください)。

INHERIT SELECT PRIVILEGES

スーパービューに対して SELECT 特権を持つユーザーやグループはすべて、 新しく作成したサブビューに対しても同様の特権を付与されます。 この特権は、サブビュー定義者によって付与されたものと見なされます。

OID 列

型付きビューのオブジェクト ID 列を定義します。

REF IS OID-column-name ユーザー生成

オブジェクト ID (OID) 列をビューの最初の列として定義することを指定します。 ビュー階層のルート・ビューには、OID が必須です (SQLSTATE 428DX)。 このビューはサブビュー以外の型付きビュー (OF 節が必須) でなければなりません (SQLSTATE 42613)。 この列の名前は OID-column-name として定義されますが、 構造化タイプ type-name のどの属性の名前とも同一にすることはできません (SQLSTATE 42711)。 fullselect で指定した最初の列は、 REF(type-name) というタイプでなければなりません (キャストして適切なタイプにする必要があるかもしれません)。 UNCHECKED を指定しない場合、索引 (主キー、ユニーク制約、ユニーク索引、 または OID 列) を使用して固有性を強制できる列 (NULL 可能ではない) に基づいている必要があります。 この列は、 オブジェクト ID 列 または OID 列と呼ばれます。 USER GENERATED というキーワードは、 行を挿入する際にユーザーが OID 列の初期値を提供しなければならないことを指しています。 行を挿入した後は、OID 列を更新することはできません (SQLSTATE 42808)。

UNCHECKED

固有であることをシステムが証明できない場合でも、 型付きビュー定義のオブジェクト ID の列を固有であると見なすように定義します。 この属性は、 次のような型付きビュー階層に定義されている表またはビューでの使用を想定しています。 すなわち、そのデータが固有性規則に準拠しているものの、 システムが固有性を証明できる規則には準拠していないことをユーザーが認識しているという場合です。 UNCHECKED オプションは、 複数の階層や従来型の表またはビューにわたる範囲を持つビュー階層には必須のオプションです。UNCHECKED を指定する場合、ユーザーの責任でビューの各行にユニークな OID が確実にあるようにします。 ユーザーがこの特性を保証しなかったために、ビューに重複した OID 値が入ってしまうと、固有でない OID 値のどれかを含むパスの式または DEREF 演算子はエラーになります (SQLSTATE 21000)。

オプション付き

型付きビューの列に適用される追加オプションを定義します。

column-name WITH オプション

追加オプションを指定する列の名前を指定します。 column-name は、 ビューの type-name に定義されている (継承されてはいない) 属性名に対応していなければなりません。 この列は参照タイプである必要があります (SQLSTATE 42842)。 また、既にスーパービューに存在する列に対応することはできません (SQLSTATE 428DJ)。 列名は、ステートメント内の 1 つの WITH OPTIONS SCOPE 節に 1 回しか指定できません (SQLSTATE 42613)。

SCOPE

参照タイプ列の有効範囲を指定します。 間接参照演算子の左オペランド、または DEREF 関数の引数として使用する列には、 すべて有効範囲を指定する必要があります。

参照タイプ列の有効範囲指定は後続の ALTER VIEW ステートメントまで遅らせることができます (有効範囲が継承されていない場合)。これにより、ターゲット表またはターゲット・ビューを定義できるようになります (通常は、相互参照表および相互参照ビューの場合)。 ビューの参照タイプ列で有効範囲が指定されておらず、基礎表またはビュー列の有効範囲が指定されている場合、基礎列の有効範囲が参照タイプ列によって継承されます。 基礎表またはビューの列に有効範囲がない場合には、この列に有効範囲は指定されません。 有効範囲と参照タイプの列について詳しくは、 注 を参照してください。

型付き表名 (typed-table-name)

型付き表の名前。 この表は既に存在しているものか、 作成する表と同じ名前のものでなければなりません (SQLSTATE 42704)。 column-name のデータ・タイプは REF(S) でなければなりません。 S は typed-table-name のタイプを表します (SQLSTATE 428DM)。 値が typed-table-name の既存行を実際に参照していることを確認するための、 column-name の既存値の検査は行われません。

型付きビュー名

型付きビューの名前。 このビューは既に存在しているものか、 作成するビューと同じ名前のものでなければなりません (SQLSTATE 42704)。 column-name のデータ・タイプは REF(S) でなければなりません。 S は typed-view-name のタイプを表します (SQLSTATE 428DM)。 値が typed-view-name の既存行を実際に参照していることを確認するための、column-name の既存値の検査は行われません。

読み取り専用

列を読み取り専用列として指定します。 このオプションは、列を読み取り専用にすることで、サブビューの定義において、暗黙的に読み取り専用である同じ列を式に指定できるようにするために使用されます。

AS

ビュー定義を指定します。

WITH 共通表式 (common-table-expression)

後続の fullselect で使用する共通表式を定義します。 型付きビューを定義するときには、共通表式は指定できません。

全選択

ビューを定義します。 ビューは常に、SELECT ステートメントが実行された場合の結果となる複数行で構成されます。 ビューの列のデータ・タイプは、データ・タイプ制約を持つ特殊タイプ、配列タイプ、カーソル・タイプ、または行タイプにはできません。 全選択でホスト変数、パラメーター・マーカー、 または宣言済み一時表を参照することはできません。 ただし、パラメーター化されたビューを SQL 表関数として作成することは可能です。 全選択では、FROM 節に SQL データ変更ステートメントを含めることはできません (SQLSTATE 428FL)。 また、全選択は一時外部表を参照できません (SQLSTATE 428I)。

「SELECT *」ステートメントを使用して作成されたビューは、新しい列が基本表に追加されても更新されません。

型付きビューおよびサブビューの場合: fullselect は、以下の規則に準拠していなければなりません。 そうでない場合、エラーが戻されます (特に他の指定がなければ、SQLSTATE 428EA)。

• 全選択に、DBPARTITIONNUM または HASHEDVALUE 関数、非 deterministic 関数、 または外部アクションを持つように定義されている関数への参照を含めることはできません。
• ビューの本体は、単一の副選択、または複数の副選択の UNION ALL で構成する必要があります。 ビューの本体に直接加わっている各副選択を、ビューの分岐 と呼びます。 ビューには、1 つかそれ以上の分岐がある場合があります。
• 各分岐の FROM 節は、単一の表またはビュー (その分岐の基礎 表またはビューといい、 必ずしも型付きではない) で構成される必要があります。
• 各分岐の基礎表またはビューは、別々の階層にする必要があります (つまり、 ビューは、同じ階層内の基礎表またはビューが付いた複数の分岐を持つことはできません)。
• 型付きビュー定義の分岐はいずれも GROUP BY または HAVING を指定できません。
• ビューの本体に UNION ALL が含まれる場合、 階層内にあるルート・ビュー の OID 列に UNCHECKED オプションを指定する必要があります。

ビューおよびサブビューの階層の場合 : BR1 および BR2 が、 階層内のビュー定義に現れる分岐になるようにします。 T1 を BR1 の基礎表またはビューに、T2 を BR2 の基礎表またはビューにします。 この場合は以下のようになります。

• T1 および T2 が同じ階層でない場合、 ビュー階層にあるルート・ビューの OID 列に UNCHECKED オプションを指定する必要があります。
• T1 および T2 が同じ階層にある場合、 行セットが結合しないことを十分保証する述部または ONLY 節を、 BR1 および BR2 に含める必要があります。

EXTEND AS を使って定義された型付きサブビューの場合: サブビューの本体内の各分岐について:

• 各分岐の基礎表は、 すぐ上のスーパービューのどこか (必ずしも厳密ではない) の基礎表の副表でなければなりません。
• SELECT リストの式は、 サブビューの非継承列に割り当てられなければなりません (SQLSTATE 42854)。

AS (EXTEND なし) を使って定義された型付きサブビューの場合:

• サブビューの本体内にあるそれぞれの分岐について、SELECT リストにある式は、 サブビューの継承列と非継承列の宣言済みタイプに割り当てられるようにする必要があります (SQLSTATE 42854)。
• サブビューで指定した階層上のそれぞれの分岐の OID 式は、 ルート・ビュー内の同じ階層上の分岐の OID 式と (キャスト以外で) 同じでなければなりません。
• スーパービュー内の READ ONLY として (暗黙的または明示的に) 指定されていない列の式は、 そのサブビュー内の同じ基礎階層上のすべての分岐と同じでなければなりません。

WITH CHECK OPTION

ビューによって挿入または更新される行すべてが、 ビューの定義に従っていなければならないという制約を指定します。 ビューの定義に従わない行とは、ビューの検索条件を満たしていない行です。

WITH CHECK OPTION は、以下のいずれかの条件が真である場合には指定できません。

• ビューが読み取り専用である場合 (SQLSTATE 42813)。 挿入が許されていない更新可能なビューに対して WITH CHECK OPTION を指定すると、 制約は更新にのみ適用されます。
• ビューが、DBPARTITIONNUM または HASHEDVALUE 関数、非 deterministic 関数、 または外部アクションを伴う関数を参照する場合 (SQLSTATE 42997)。
• ニックネームがビューの更新の対象である場合。
• INSTEAD OF トリガーが定義されているビューが、ビューの更新対象である場合 (SQLSTATE 428FQ)。

WITH CHECK OPTION を省略すると、 ビューを使用するどのような挿入操作または更新操作のチェックにおいても、ビューの定義は使用されません。 ただし、ビューが WITH CHECK OPTION が指定された他のビューに直接または間接的に従属する場合には、 挿入操作または更新操作の過程で、何らかのチェックが行われる場合があります。 ビューの定義が使用されるわけではないため、 ビューを介して、ビューの定義に従っていない行が挿入または更新される可能性があります。

CASCADED

ビュー V に対する WITH CASCADED CHECK OPTION 制約は、 V が従属するいずれかの更新可能ビューから、 制約としての検索条件を V が継承することを意味します。 さらに、 V に従属するすべての 更新可能 ビューも、これらの制約の対象となります。 したがって、V の検索条件と、 V が従属している各ビューの検索条件との AND を取ったものが、 V あるいは V に従属するいずれかのビューの挿入または更新に対して 適用される制約となります。

LOCAL

ビュー V に対する WITH LOCAL CHECK OPTION 制約は、 V の検索条件が、 V または V に従属するいずれかのビューの挿入あるいは更新に対する 制約として適用されることを意味しています。

次の例は、CASCADED と LOCAL の差異を示しています。 次のような更新可能なビューを想定します (Y は、下記の表の列見出しに示しているように、 LOCAL または CASCADED に置き換えます)。

   V1 defined on table T
   V2 defined on V1 WITH Y CHECK OPTION
   V3 defined on V2
   V4 defined on V3 WITH Y CHECK OPTION
   V5 defined on V4

次の表は、挿入または更新された行を検査するのに使われる検索条件を示しています。

	Y が LOCAL の場合	Y が CASCADED の場合
V1 でのチェック条件:	対象となるビューなし	対象となるビューなし
V2 でのチェック条件:	V2	V2, V1
V3 でのチェック条件:	V2	V2, V1
V4 でのチェック条件:	V2, V4	V4, V3, V2, V1
V5 でのチェック条件:	V2, V4	V4, V3, V2, V1

また、次のような更新可能ビューについても考えてみます。 これは、デフォルトの CASCADED オプションを使用した場合の WITH CHECK OPTION の効果を示しています。

   CREATE VIEW V1 AS SELECT COL1 FROM T1 WHERE COL1 > 10

   CREATE VIEW V2 AS SELECT COL1 FROM V1 WITH CHECK OPTION

   CREATE VIEW V3 AS SELECT COL1 FROM V2 WHERE COL1 < 100

次の INSERT ステートメントは V1 を使用するものですが、 V1 に WITH CHECK OPTION が指定されておらず、 また V1 が、WITH CHECK OPTION の指定された他のどのビューにも従属していないため、 このステートメントは成功します。

   INSERT INTO V1 VALUES(5)

次の INSERT ステートメントは V2 を使用するものですが、 V2 に WITH CHECK OPTION が指定されており、 挿入 (INSERT) によって V2 の定義に従っていない行が作成されるため、 このステートメントはエラーになります。

   INSERT INTO V2 VALUES(5)

次の INSERT ステートメントでは V3 を使用しています。 V3 に WITH CHECK OPTION は指定されていませんが、 これは、WITH CHECK OPTION の指定された V2 の従属であるため、 エラーになります (SQLSTATE 44000)。

   INSERT INTO V3 VALUES(5)

次の INSERT ステートメントも、V3 を使用しています。 これは V3 の定義に準拠していませんが、 成功します (V3 には WITH CHECK OPTION が指定されていません)。 これは、WITH CHECK OPTION の指定された V2 の定義に従ったものになっています。

   INSERT INTO V3 VALUES(200)

WITH NO ROW MOVEMENT または WITH ROW MOVEMENT

基礎表のチェック制約に違反する方法で行が更新されたときに、 更新可能 UNION ALL ビューに対して行うアクションを指定します。 デフォルトは WITH NO ROW MOVEMENT です。

WITH NO ROW MOVEMENT

基礎表のチェック制約に違反する方法で行が更新されたときに、 エラー (SQLSTATE 23513) を戻すよう指定します。

WITH ROW MOVEMENT

表のチェック制約に対する違反があっても、更新された行を該当する基礎表に移動させるよう指定します。

行の移動には、チェック制約に違反する行の削除と、それらの行のビューへの再挿入が関係します。 WITH ROW MOVEMENT 節を指定できるのは、 UNION ALL ビューの列がすべて更新可能になっている場合だけです (SQLSTATE 429BJ)。 行が削除されたのと同じ基礎表に行が挿入される (おそらく、トリガー起動の後) 場合は、 エラーが戻されます (SQLSTATE 23524)。 WITH ROW MOVEMENT 節を使用して定義されたビューには、 最外部の全選択を除き、ネストされた UNION ALL 操作を含めることはできません (SQLSTATE 429BJ)。 WITH ROW MOVEMENT 節を使用して定義されたビューには、システム期間テンポラル表、アプリケーション期間テンポラル表、またはバイテンポラル表への参照を含めることはできません。

注

• まだ存在していないスキーマ名を用いてビューを作成すると、 ステートメントの許可 ID に IMPLICIT_SCHEMA 権限がある場合に限り、 そのスキーマが暗黙的に作成されます。 スキーマの所有者は SYSIBM になります。 スキーマに対する CREATEIN 特権が PUBLIC に付与されます。
• ビュー列は、列が式から派生するとき以外は、 基本表またはビューの NOT NULL WITH DEFAULT 属性を継承します。 基本表に制約 (主キー制約、参照整合性制約、またはチェック制約) が定義されている場合、更新可能ビューで行が挿入または更新されると、それらの制約に照らして検査が行われます。
• 定義の中で作動不能ビューを使用して新しいビューを作成することはできません (SQLSTATE 51024)。
• ビューの本文に指定したオブジェクトが存在しない場合、無効のマークが付いている場合、または定義者にそのオブジェクトに対するアクセス権が一時的にない場合でも、データベース構成パラメーターの auto_reval が DEFERRED_FORCE に設定されていれば、ビューは正常に作成されます。 このビューは、無効とマークを付けられ、次回参照されたときに再度有効化されます。
• このステートメントでは、 宣言済み一時表をサポートしていません (SQLSTATE 42995)。
• カラム・オーガナイズ 表に基づくビュー:
  • カラム・オーガナイズ 表での型付きビューの作成はサポートされていません。
  • カラム・オーガナイズ 表がビュー定義の一部である場合、WITH CHECK OPTION 節を指定することはできません。
• 削除可能ビュー: 削除操作の INSTEAD OF トリガーがビューに定義されている場合、または下記の条件のすべてが当てはまる場合、ビューは削除可能 です。
  • 外部全選択の各 FROM 節には、基本表 (OUTER 節なし)、 削除可能ビュー (OUTER 節なし)、削除可能なネストした表式、 または削除可能な共通表式 (ニックネームが識別不能) のいずれかが 1 つだけ指定されている。 さらに、基本表または削除可能ビューに指定された period-specification で、SYSTEM_TIME 期間を参照していない。
  • 外部全選択に VALUES 節が含まれない
  • 外部全選択に GROUP BY 節も HAVING 節も含まれない
  • 外部全選択の選択リストに集約関数が含まれない
  • 外部全選択に、UNION ALL を除くセット演算 (UNION、EXCEPT、または INTERSECT) が含まれない
  • UNION ALL のオペランドの基本表が同じ表ではなく、各オペランドが削除可能
  • 外部全選択の選択リストに DISTINCT が含まれない
• 更新可能ビュー: 更新操作の INSTEAD OF トリガーがビューに定義されている場合、または下記の条件のすべてが当てはまる場合、ビューの列は更新可能 です。
  • ビューが削除可能 (削除の INSTEAD OF トリガーとは無関係) であり、 列の解決結果が基本表の列 (間接参照操作は使用しない) となり、READ ONLY オプションが指定されない
  • ビューの全選択に UNION ALL が含まれる場合、 UNION ALL のオペランドの対応するすべての列のデータ・タイプおよびデフォルト値が正確に一致する (長さ、 または精度と位取りを含む)

  ビューのいずれかの 列が更新可能なら、ビューは更新可能です。

• 挿入可能なビュー: 挿入操作の INSTEAD OF トリガーがビューに定義されている場合、またはビューの少なくとも 1 つの列が更新可能 (更新の INSTEAD OF トリガーとは関係なく) である場合、ビューの全選択に UNION ALL が含まれていなければ、そのビューは挿入可能です。

  特定の行が、基礎となる基本表のうちの正確に 1 つにおけるチェック制約を満たしている場合にのみ、 その行をビュー (UNION ALL を含む) に挿入できます。

  更新不可の列が含まれているビューに挿入するには、それらの列を列リストから除外する必要があります。

• 読み取り専用ビュー: ビューが読み取り専用 であるのは、削除可能でも、更新可能でも、挿入可能でもない 場合です。

  ビューが読み取り専用かどうかは、SYSCAT.VIEWS カタログ・ビューの READONLY 列に示され、期間指定または INSTEAD OF トリガーが考慮されることはありません。

• 共通表式とネストした表式は、削除可能かどうか、更新可能かどうか、 挿入可能かどうか、または読み取り専用かどうかを判別する上で、同じ一連の規則に従います。
• テンポラル・サポート用の特殊レジスター: 特殊レジスター CURRENT TEMPORAL SYSTEM_TIME および CURRENT TEMPORAL BUSINESS_TIME の値は、ビューの定義中にビューを定義する照会式に影響を与えません。 SQL ステートメントでビューを使用する場合、 その SQL ステートメントを処理しているセッションの CURRENT TEMPORAL SYSTEM_TIME および CURRENT TEMPORAL BUSINESS_TIME 特殊レジスター の値が、ビューに適用されます。
• 作動不能ビュー: 作動不能ビュー とは、SQL ステートメントで使用できなくなったビューのことです。 ビューは、次の場合に作動不能になります。
  • ビュー定義が従属している特権が取り消された場合
  • ビュー定義が従属している表、ニックネーム、別名、または関数などのオブジェクトがドロップされた場合
  • ビュー定義が従属しているビューが作動不能になった場合
  • ビュー定義 (サブビュー) のスーパービューであるビューが作動不能になった場合

  実際には、作動不能ビューとは、ビュー定義が間違ってドロップされたビューです。 例えば、別名がドロップされると、 その別名を使用して定義されているビューすべてが作動不能になります。 それに従属するすべてのビューも作動不能になり、 そのビューに従属するパッケージは無効になります。

  作動不能ビューが明示的に再作成またはドロップされるまで、その作動不能ビューを使用するステートメント のコンパイルはできません (SQLSTATE 51024)。 ただし、CREATE ALIAS、CREATE VIEW、DROP VIEW、 および COMMENT ON TABLE の各ステートメントは例外です。 作動不能ビューが明示的にドロップされるまで、 その修飾名を使って別の表や別名を作成することはできません (SQLSTATE 42710)。

  作動不能ビューは、作動不能ビューの定義テキストを使用して、 CREATE VIEW ステートメントを発行することにより、再作成することができます。 このビュー定義テキストは、SYSCAT.VIEWS カタログの TEXT 列に保管されています。 作動不能ビューを再作成する場合は、そのビューに対して他のユーザーが必要とする特権すべてを明示的に付与する必要があります。 これは、ビューが作動不能と見なされると、 ビューのすべての許可レコードが削除されるためです。 作動不能ビューを再作成するために、それを明示的にドロップする必要はありません。 作動不能ビューと同じ view-name を指定して CREATE VIEW ステートメントを発行すると、 作動不能ビューは置き換えられ、CREATE VIEW ステートメントは警告を戻します (SQLSTATE 01595)。

  作動不能ビューであることは、SYSCAT.VIEWS カタログ・ビューの VALID 列が X、 また SYSCAT.TABLES カタログ・ビューの STATUS 列が X であることによって示されます。

• 特権: ビューの定義者は、ビューに対する SELECT 特権と、ビューをドロップする権限を常に与えられます。 ビューの定義者は、その定義者が全選択で指定されたすべての基本表、ビューまたはニックネームに対する CONTROL 特権を持っている場合、あるいは定義者が以下の各権限を持っている場合にのみ、そのビューに対する CONTROL 特権が付与されます。
  • データベースに対する ACCESSCTRL または SECADM、または全選択で指定されたすべての基本表、ビュー、またはニックネームを含んでいるスキーマに対する ACCESSCTRL
  • データベースに対する DATAACCESS、または全選択で指定されたすべての基本表、ビュー、またはニックネームを含んでいるスキーマに対する DATAACCESS
  • 全選択で指定されたすべての基本表、ビュー、またはニックネームを含んでいるスキーマに対する DBADM または SCHEMAADM

  ビューの定義者は、そのビューが読み取り専用でなく、 定義者が基礎となるオブジェクトに対して対応する特権を持っている場合に、 そのビューに対する INSERT、 UPDATE、列レベルの UPDATE、 または DELETE の特権を与えられます。

  WITH ROW MOVEMENT でビューが定義された場合は、 定義者がビューのすべての列に対する UPDATE 特権を持っており、 またすべての基礎表またはビューに対する INSERT および DELETE 特権を持っている場合のみ、 その定義者に、そのビューでの UPDATE 特権が与えられます。

  ビューの定義者にそれらの特権が与えられるのは、 それらの特権の派生元の特権がビューの作成時に存在している場合に限ります。 定義者は、これらの特権を直接持っているか、または PUBLIC の特権として持っていることが必要です。 特権は、フェデレーテッド・サーバーのニックネームでビューを定義するときには考慮されません。 ただし、ニックネームを使ったビューを使用する場合、ユーザーの許可 ID には、 そのニックネームがデータ・ソースで参照する表またはビューに対する有効な SELECT 特権がなければなりません。 それ以外の場合、エラーが戻されます。 ビューの定義者がメンバーであるグループを持つ特権は考慮されません。

  サブビューが作成されると、 すぐ上のスーパービューに対して持っている SELECT 特権が自動的にサブビューに対しても付与されます。

• 有効範囲および REF 列: ビュー定義の全選択で参照タイプ列を選択する際には、必要なターゲット・タイプと有効範囲について考慮してください。
  • 必要なターゲット・タイプおよび有効範囲が基礎表または基礎ビューのものと同じ場合には、 参照列をそのまま選択することができます。
  • 有効範囲を変更する必要がある場合には、WITH OPTIONS SCOPE 節を使って、 必要な有効範囲の表またはビューを定義します。
  • 参照のターゲット・タイプを変更する必要がある場合には、 まず列を参照の対象の表示タイプにキャストしてから、 新規の参照タイプへもキャストする必要があります。 この場合、有効範囲は参照タイプへのキャストで指定できますし、 WITH OPTIONS SCOPE 節を使っても指定できます。 例えば、REF(TYP1) SCOPE TAB1 として定義された Y 列を選択したとしましょう。 そして、この列を REF(VTYP1) SCOPE VIEW1 として定義するとします。 この場合、選択リスト項目は次のようになります。

       CAST(CAST(Y AS VARCHAR(16) FOR BIT DATA) AS REF(VTYP1) SCOPE VIEW1)

• ID 列: ビューの列が ID 列と見なされるのは、ビュー定義の全選択内における対応する列のエレメントが、表の ID 列の名前であるか、または基本表の ID 列の名前に直接または間接的にマップするビューの列の名前である場合です。
  これ以外の場合はすべて、ビューの列は ID のプロパティーを取得しません。 以下に例を示します。

  • ビュー定義の選択リストに ID 列の名前のインスタンスが複数含まれている (つまり、 同じ列を複数回選択している) 場合
  • ビュー定義に結合が関与している場合
  • ビュー定義の列に ID 列を参照する式が含まれている場合
  • ビュー定義に UNION が含まれている場合

  挿入先のビューにおいて、ビュー定義の選択リストに直接または間接的に基本表の ID 列の名前が含まれている場合は、 INSERT ステートメントが基本表の ID 列を直接参照する場合と同じ規則が適用されます。

• フェデレーテッド・ビュー: フェデレーテッド・ビューとは、全選択内のどこかにニックネームへの参照を含むビューのことです。 この種のニックネームが存在する場合、後続する照会でそのビューが参照されるとき、ビューに使用される許可モデルが変更されます。

  ビューを作成しても、ビュー定義者がニックネームの基礎データ・ソース表またはビューにアクセス できるかどうかを判別する特権検査は行われません。 フェデレーテッド・データベースでの表またはビューに対する参照の特権検査は通常どおりに処理され、ビュー定義者には、そのようなオブジェクトに対して少なくとも SELECT 特権が必要になります。

  その後、照会でフェデレーテッド・ビューが参照されるとき、ニックネームがあるためにデータ・ソースに対する照会が行われることになり、その照会を発行した許可 ID (またはそれにマップするリモート許可 ID) は、データ・ソースの表またはビューにアクセスするために必要な特権が必要です。 フェデレーテッド・ビューを参照する照会を発行する許可 ID には、 フェデレーテッド・サーバーに存在する (フェデレーテッドでない) 表またはビューに対する追加の特権は必要ありません。

• ROW MOVEMENT、トリガー、および制約: WITH ROW MOVEMENT 節を使用して定義されたビューを更新すると、トリガーと制約の操作の順序は以下のようになります。
  1. 最終的には移動される行も含め、 更新されるすべての行に対して BEFORE UPDATE トリガーがアクティブ化されます。
  2. 更新操作が処理されます。
  3. 更新されるすべての行に対して制約が処理されます。
  4. 更新操作の後、制約を満たしたすべての行に対し、 作成された順番で AFTER UPDATE トリガーが (行レベルとステートメント・レベルの両方で) アクティブ化されます。 これは UPDATE ステートメントであるため、 すべての基礎表に対して、UPDATE ステートメント・レベルのすべてのトリガーがアクティブ化されます。
  5. 更新操作の後、 制約を満たさなかったすべての行 (移動される行) に対して BEFORE DELETE トリガーがアクティブ化されます。
  6. 削除操作が処理されます。
  7. 削除されるすべての行に対して制約が処理されます。
  8. 削除されるすべての行に対し、 作成された順番で AFTER DELETE トリガーが (行レベルとステートメント・レベルの両方で) アクティブ化されます。 ステートメント・レベルのトリガーは、削除操作に関係する表に対してのみアクティブ化されます。
  9. 挿入されるすべての行 (つまり、移動される行) に対して BEFORE INSERT トリガーがアクティブ化されます。 BEFORE INSERT トリガーの新しい遷移表には、ユーザーからの入力データが含まれています。 そのようなトリガーには UPDATE、DELETE、INSERT の各操作を組み込むことができず、そのような操作を組み込んだルーチンを呼び出すこともできません (SQLSTATE 42987)。
  10. 入力操作が処理されます。
  11. 挿入されるすべての行に対して制約が処理されます。
  12. 挿入されるすべての行に対し、 作成された順番で AFTER INSERT トリガーが (行レベルとステートメント・レベルの両方で) アクティブ化されます。 ステートメント・レベルのトリガーは、挿入操作に関係する表に対してのみアクティブ化されます。
• ネストされた UNION ALL ビュー: UNION ALL で定義され、直接的または間接的に、UNION ALL で定義されているビューに基づくビューは、いずれかのビューが WITH ROW MOVEMENT 節を使用して定義されている場合は更新できません (SQLSTATE 429BK)。
• 暗黙的な隠し列に関する考慮事項: 暗黙的な隠し列として定義された基本表の列が、全選択の結果表に含まれることがあります。 暗黙的な隠し列がビュー定義の全選択で明示的に参照されている場合に、これが発生します。 ただし、ビューの対応する列は、暗黙的な隠し列としての属性を継承しません。 ビューの列を隠し列として定義することはできません。
• 副選択 isolation-clause は fullselect に指定できません (SQLSTATE 42601)。
• 難読化: CREATE VIEW ステートメントを難読化形式でサブミットできます。 難読化されたステートメントでは、ビュー名のみを判読できます。 残りのステートメントは、読み取れないようにエンコードされますが、データベース・サーバーによりデコードできます。 難読化ステートメントの作成は、DBMS_DDL.WRAP 関数を呼び出すことによって行えます。
• 代替構文: Db2® およびその他のデータベース製品。
  • FEDERATED キーワードは、キーワード CREATE および VIEW の間に指定できます。 しかし FEDERATED キーワードは無視されます。これはフェデレーテッド・オブジェクトがビュー定義で使用される場合は、 警告は戻されないからです。

例

• 例 1: PROJECT 表に基づくビュー MA_PROJ を作成します。このビューには、文字 'MA' で始まるプロジェクト番号 (PROJNO) を持つ行だけを入れます。

     CREATE VIEW MA_PROJ  AS SELECT *
       FROM PROJECT
        WHERE SUBSTR(PROJNO, 1, 2) = 'MA'

• 例 2: 例 1 と同様にビューを作成しますが、プロジェクト番号 (PROJNO)、プロジェクト名 (PROJNAME)、およびプロジェクトを担当する従業員 (RESPEMP) の列のみを選択します。

     CREATE VIEW MA_PROJ
       AS SELECTPROJNO, PROJNAME, RESPEMP
       FROM PROJECT
       WHERE SUBSTR(PROJNO, 1, 2) = 'MA'

• 例 3: 例 2 と同様のビューを作成します。 ただし、ビューの中でプロジェクトの責任者の列を IN_CHARGE と呼びます。

     CREATE VIEW MA_PROJ
       (PROJNO, PROJNAME, IN_CHARGE) 
       AS SELECTPROJNO, PROJNAME, RESPEMP
       FROM PROJECT
       WHERE SUBSTR(PROJNO, 1, 2) = 'MA'

  注: 列名を 1 つだけ変更する場合でも、MA_PROJ の後の括弧内に、ビュー内の 3 つの列すべての名前をリストする必要があります。
• 例 4: プロジェクト (RESPEMP) の責任者の姓 (LASTNAME) とともに PROJECT 表の最初の 4 つの列 (PROJNO、PROJNAME、DEPTNO、RESPEMP) を含む PRJ_LEADER という名前のビューを作成します。 この名前は、EMPLOYEE 表の EMPNO を PROJECT 表の RESPEMP と突き合わせることによって、EMPLOYEE 表から入手します。

     CREATE VIEW PRJ_LEADER
       AS SELECT PROJNO, PROJNAME, DEPTNO, RESPEMP, LASTNAME
       FROM PROJECT, EMPLOYEE
       WHERE RESPEMP = EMPNO

• 例 5: 例 4 と同様にビューを作成します。ただし、列 PROJNO、PROJNAME、DEPTNO、RESPEMP、および LASTNAME に加えて、責任者である従業員の合計給与 (SALARY + BONUS + COMM) を表示します。 また、平均スタッフ数 (PRSTAFF) が 1 より大きいプロジェクトだけを選択します。

     CREATE VIEW PRJ_LEADER
     (PROJNO, PROJNAME, DEPTNO, RESPEMP, LASTNAME, TOTAL_PAY )
     AS SELECT PROJNO, PROJNAME, DEPTNO, RESPEMP, LASTNAME, SALARY+BONUS+COMM
       FROM PROJECT, EMPLOYEE
       WHERE RESPEMP = EMPNO
       AND PRSTAFF > 1

  全選択で、式 SALARY+BONUS+COMM に TOTAL_PAY という名前を付けることによって、 次のように、列名リストの指定を省略することができます。

     CREATE VIEW PRJ_LEADER
       AS SELECT PROJNO, PROJNAME, DEPTNO, RESPEMP,
                    LASTNAME, SALARY+BONUS+COMM AS TOTAL_PAY
         FROM PROJECT, EMPLOYEE
         WHERE RESPEMP = EMPNO AND PRSTAFF > 1

• 例 6: 次の図に示すような表とビューのセットがあるとします。

  

  ユーザー ZORPIE (ACCESSCTRL、DATAACCESS、または DBADM 権限のいずれも持たない) は、 各オブジェクトについて括弧内に示している特権を持っています。
  1. 次のステートメントによって作成するビューに対して、ZORPIE は CONTROL 特権を獲得します。

        CREATE VIEW VA AS SELECT * FROM S1.V1

     これは、ZORPIE が S1.V1 に対して CONTROL 権限を持っているからです。 ACCESSCTRL または SECADM のいずれかの権限を持つユーザーが、 S1.V1 に対する CONTROL 権限を ZORPIE に与えている必要があります。 基礎となる基本表に対して、どのような特権が与えられているかは関係ありません。
  2. ZORPIE には、次のようなビューの作成は許可されません。

        CREATE VIEW VB AS SELECT * FROM S1.V2

     これは、ZORPIE には、S1.V2 に対する CONTROL も SELECT も与えられていないからです。 基礎となる基本表 (S1.T2) に対して CONTROL を与えられているかどうかは、関係ありません。
  3. 次のステートメントによって作成するビューに対して、ZORPIE は CONTROL 特権を獲得します。

        CREATE VIEW VC (COLA, COLB, COLC, COLD)
          AS SELECT * FROM S1.V1, S1.T2
          WHERE COLA = COLC

     これは、ZORPIE.VC の全選択では、ビュー S1.V1 と表 S1.T2 を参照しており、 ZORPIE はその両方に対する CONTROL を持っているからです。 ビュー VC は読み取り専用で、INSERT、UPDATE、 または DELETE のいずれの権限も ZORPIE には与えられないことに注意してください。
  4. 次のステートメントによって作成するビューに対して、ZORPIE は SELECT 特権を入手します。

        CREATE VIEW VD (COLA,COLB, COLE, COLF)
          AS SELECT * FROM S1.V1, S1.V3
          WHERE COLA = COLE

     これは、ZORPIE.VD の全選択で 2 つのビュー S1.V1 および S1.V3 を参照しており、ZORPIE はその 1 つに対しては SELECT 特権のみを、もう 1 つに対しては CONTROL 特権を与えられているからです。 ZORPIE.VD に対する特権として、 2 つの特権のうち低い方の特権である SELECT が ZORPIE に与えられます。
  5. 以下のビュー定義では、ZORPIE はビュー VE に対して WITH GRANT OPTION を伴う INSERT、 UPDATE および DELETE の各特権と、SELECT 特権を与えられます。

        CREATE VIEW VE
           AS SELECT * FROM S1.V1
          WHERE COLA > ANY
                 (SELECT COLE FROM S1.V3)

     ZORPIE の VE に対する特権は、主として S1.V1 に対する特権によって決定されます。 S1.V3 は副照会で参照されるだけなので、ビュー VE の作成には S1.V3 に対する SELECT 特権のみ必要となります。 ビューの定義者は、ビュー定義で参照されるすべてのオブジェクトに対して CONTROL を持っている場合のみ、そのビューに対する CONTROL を得ます。 ZORPIE は S1.V3 に対する CONTROL を持っていないため、VE に対する CONTROL は得られません。