基本情報 2022 サンプル問題 問21：テクノロジ系に関する問題

答えは a「ビューとは，名前を付けた導出表のことである」 です。

データベースの「ビュー」は、もとの表（基底表）から欲しい部分だけを取り出して見せる「仮想の表（窓ガラス越しの見え方）」みたいなものです。

たとえば社員名簿の表から「営業部の人だけ」「給料は見せない」みたいにフィルタ＆切り抜きした見え方に名前を付けて保存しておくと、いつでもその切り口で見られて便利。実体（データ本体）は元の表のままなので場所を取りません。

👉 覚え方：ビュー＝名前付きの見え方。元データはそのまま、見せ方だけ作る。

ほかの選択肢：b ビューからまたビューも作れます／c 元の表（基底表）がないとビューは作れません／d 1つのビューは複数の表をくっつけて作れます（join 可）。

なぜこれが正解か

正解は a。RDBMS におけるビュー（view）は、1つ以上の基底表（base table）に対する問合せ（SELECT 文）に名前を付けて定義した仮想表（導出表／derived table）。物理的にデータを保持せず、参照時に定義 SQL を実行して結果を返す。

各選択肢の解説

• b：誤り。ビューを基にさらに別のビューを定義することは可能（ビューのネスト）。
• c：誤り。基底表がなければビューは定義できない。順序が逆で、基底表が先、ビューは後。
• d：誤り。ビューは複数の基底表を結合（join）して定義できる。1対1の制限はない。

覚え方・ひっかけ注意

ビューの主な利点は (1)アクセス権制御（センシティブな列を隠せる）(2)複雑な問合せの簡略化（毎回 JOIN を書かずに済む）(3)論理的データ独立性（基底表の構造変更をビューで吸収）。ビューへの更新（INSERT/UPDATE/DELETE）は更新可能ビュー（updatable view）の条件を満たす場合のみ可能、というのも頻出論点。

理論的背景

ビューは ANSI/ISO SQL 標準で `CREATE VIEW view_name AS SELECT ...` で定義される。基底表との関係：

• 論理データ独立性の実現：基底表のスキーマ変更があってもビュー定義で吸収すれば、ビューを参照するアプリは影響を受けない。
• 更新可能ビュー（updatable view）の条件：単一基底表ベース、DISTINCT・GROUP BY・集約関数・UNION を含まない、結合を含まない等の制約。標準SQL の WITH CHECK OPTION を付けると、ビュー定義条件を満たさない更新を拒否できる。
• マテリアライズドビュー（materialized view）：ビュー結果を物理テーブルとして保持し、定期的に再計算する派生概念。集計クエリの高速化に有効（Oracle・PostgreSQL 等で対応）。

実務での使われ方

• セキュリティ：個人情報を含む表から、業務に必要な列だけを公開するビューを作成し権限制御。
• レポーティング：BI ツール向けに複雑な結合・集計を隠蔽した「データマート的ビュー」。
• マイグレーション：旧スキーマと新スキーマの橋渡しにビューを使い、アプリ改修を段階的に進める。
• 行レベルセキュリティ（RLS）：ビュー＋WHERE 句で「ユーザは自分のレコードだけ見える」を実現（PostgreSQL では RLS ポリシーが標準サポート）。

試験での位置づけ

基本情報・応用情報のデータベース分野で必出。3層スキーマ構造（外部スキーマ＝ビュー／概念スキーマ＝基底表／内部スキーマ＝物理格納）と絡めて出題されることが多い。データベーススペシャリスト試験ではマテリアライズドビュー・更新可能ビューの厳密な条件、共通表式（CTE / WITH 句）との対比が問われる。

選択肢の発展補足

• b ネストビュー：実用上は性能劣化（クエリプランナがビュー展開で複雑化）に注意。
• c 基底表依存：基底表を DROP するとビューは無効化（DBMS により挙動異なる）。
• d 複数表結合ビュー：JOIN ビューは更新不可になりがち。代替手段としてINSTEAD OF トリガを定義して更新を実現可能。
• CTE との違い：CTE は一時的（クエリ内のみ）、ビューは永続定義オブジェクト。