ビューと権限の付与

結論：ビューは「名前を付けた導出表」

ビューは、実際にデータを持っている表（実表＝基底表）に問合せをして得られる表に、名前を付けて保存したものです。保存されるのは「どう取り出すか」という定義（SELECT 文）だけです。データそのものはコピーされません。

たとえるなら、ビューは**ネットショップの「保存した検索条件」**です。「在庫あり・1万円以下」という条件を保存しても商品データは増えず、開くたびに最新の商品一覧がその条件で表示されます。

ビューについて正しい性質は次のとおりです。

• ビューの上に、さらにビューを定義できる
• 一つの基底表に、ビューをいくつでも定義できる
• 基底表が先にあり、ビューは後から定義する（逆はない）

CREATE VIEW の書き方

ビューは CREATE VIEW ビュー名(列名…) AS SELECT 文 で定義します。AS の後ろに来るのは必ず SELECT です。ビューは「問合せの結果」に名前を付けるものだからです。

CREATE VIEW 売上報告(製品番号, 製品名, 金額)
  AS SELECT 製品.製品番号, 製品.製品名, 売上.納品数 * 製品.単価
     FROM 製品, 売上
     WHERE 製品.製品番号 = 売上.製品番号

空欄補充では、ほかの SQL 文と取り違えさせる選択肢が並びます。SQL 文は役割で3種類に分かれます。

CREATE VIEW の AS の後ろに INSERT や GRANT が入ることはありません。

ビューの行数は元の表に合わせて変わる

ビューはデータを持たないので、基底表を更新すると、ビューの中身も自動で変わります。WHERE の条件を満たす行だけがビューに現れます。

行数の問題は「更新後の値で条件式を計算し直し、各行が条件の内側か外側かを判定する」だけで解けます。手順は下の例題で確認してください。

ビューの目的：見せる範囲を絞ってデータを守る

ビューを使う一番の目的は、利用できる範囲を限定して、データを保護・保全することです。行（例：自部署の社員だけ）や列（例：給与列を除く）を絞ったビューだけを使わせれば、元の表の残りの部分は隠せます。

ほかにも、利用者はビューの構造だけ知っていればよく、元の表の構造を知る必要はありません。元の表に列を追加しても、その列を使っていないビューは再定義しなくてよいです。

目的として誤りになる選択肢の型は次のとおりです。

• 「物理的データ独立性を提供する」…記憶装置上の構造変更の影響を隠すのは内部スキーマの役割で、ビューの目的とは別の話です
• 「ビューにインデックスを付けて高度な検索をする」…インデックスは通常、実表に付けます
• 「GROUP BY や DISTINCT を使った処理で単純な更新手段を提供する」…集計したビューは元の行と1対1に対応しないので、通常は更新できません

GRANT 文と、ビューの権限

GRANT 文は、利用者に表やビューへの操作権限（問合せ・更新・追加・削除など）を与える SQL 文です。取り上げるときは REVOKE 文を使います。

GRANT SELECT, UPDATE ON 社員 TO 佐藤

ビューの権限は、元の表の権限とは別に管理されます。ビューの SELECT 権限があれば、元の表の SELECT 権限がなくても、そのビューに問合せできます。これができるからこそ「元の表には触らせず、ビューだけ見せる」という保護が成り立ちます。

たとえるなら、ビルの受付窓口です。来客は窓口（ビュー）に用があるので、事務所の奥（元の表）に入る鍵は渡されません。

flowchart LR
  A["社員表（基底表）"] -->|"定義"| B["ビュー：自部署社員（給与列なし）"]
  C["利用者"] -->|"ビューの SELECT 権限だけ"| B
  C -.->|"社員表の権限なし"| A

機密保護と整合性：別の機能を混ぜない

DBMS（データベース管理システム）の機能のうち、機密保護（見てはいけない人に見せない・変えさせない）を実現するのはアクセス権限の管理です。選択肢に並ぶトランザクション管理・参照制約・排他制御は、データの矛盾を防ぐ整合性の機能です。

パスワードによる接続制限（認証）や、データの暗号化も機密保護に関わる手段です。ただしこれらは GRANT 文の機能ではありません。「GRANT 文の説明」を問われたら、権限の付与を述べた選択肢を選びます。