最終更新日：2026年9月23日

fe fe-technology database sql

まず結論

ビューとは、実表の一部や複数の表から得た結果を、1つの表のように見せる仮想的な表です。

基本情報技術者試験では、次の2点を切り分けられるようにしておくと判断しやすくなります。

① 誰が何をSELECTするか
→ ビューと元の表の権限を分けて考える

② ビューを更新できるか
→ 元の表の1行に対応づけられるかを見る

迷ったら、次の2つを思い出します。

SELECT権限は「何を問い合わせるか」を見る。

更新可能性は「元の表の1行に戻せるか」を見る。

直感的な説明

ビューは、元の表にある情報のうち、見せてもよい部分だけを切り出した窓のようなものです。

例えば、社員表に次の情報があるとします。

社員表
-----------------
社員番号
氏名
部署
給与
住所

一般の利用者には、給与や住所を見せたくないとします。

そこで、氏名と部署だけを見せるビューを作ります。

社員公開ビュー
-----------------
氏名
部署

利用者には、このビューを参照する権限だけを与えます。

利用者
  ↓ SELECT
社員公開ビュー
  ↓ 元になっている
社員表

利用者は社員表を直接見るのではなく、公開用のビューを通して必要な情報だけを見ると考えると分かりやすいです。

一方、ビューを更新できるかどうかは別の話です。

例えば、部署ごとの人数を GROUP BY でまとめたビューを考えます。

営業部  10人
開発部  8人

ここで「営業部 10人」を「11人」に更新しようとしても、元の社員表のどの行をどう変更すればよいか一意に決まりません。

このように、複数行をまとめた結果は更新できないと考えると理解しやすくなります。

定義・仕組み

関係データベースのビューは、実表に対する選択・射影・結合などの結果を、1つの表のように扱えるようにしたものです。

ビューそのものに実データを持つというより、元の表から得られる結果を表のように見せます。

例えば、次のようなSQLでビューを作るイメージです。

CREATE VIEW employee_public AS
SELECT name, department
FROM employee;

この場合、employee_public は employee 表から氏名と部署だけを見せるビューです。

実表とビューの違い

観点 実表 ビュー
データ 実データを保持する 元の表から得た結果を表のように見せる
用途 データを保存する 必要な部分を見せる、複雑な問合せを簡単にする
アクセス権 実表に対して設定する ビューに対して設定できる

ビューを使う理由は、単にSQLを短くするためだけではありません。

  • 見せたくない列を隠す
  • 利用者ごとに公開範囲を分ける
  • 複雑な問合せ結果を簡単に利用する
  • 分かりにくい表や列を使いやすい形で見せる

といった目的があります。

SELECT権限は何に対する権限か

SELECT 権限は、表やビューに対して問合せを行うための権限です。

試験では、次のように切り分けます。

ビューへのSELECT権限
→ そのビューを問い合わせるための権限

元の表へのSELECT権限
→ 元の表を直接問い合わせるための権限

したがって、ビューを問い合わせるときに重要なのは、ビューに対するSELECT権限があるかです。

更新可能ビューと更新不可能ビュー

ビューは、定義の仕方によって更新できる場合と、更新できない場合があります。

試験では細かなDBMSごとの差を追うより、まず次の基準で判断します。

ビューの1行を、元の表の1行に対応づけられるか。

元の表のどの行を変更すればよいか明確なら、更新可能になりやすいです。

CREATE VIEW sales_employee AS
SELECT employee_id, name, department
FROM employee
WHERE department = '営業部';

WHERE は元の行を絞っているだけなので、ビューの行と元の表の行の対応が分かります。

一方、GROUP BY や集約関数を使うと、複数行を1行にまとめます。

CREATE VIEW department_count AS
SELECT department, COUNT(*) AS employee_count
FROM employee
GROUP BY department;

このビューの「営業部 10人」を11人に変更しようとしても、元の表のどの行を追加・変更すればよいのか決まりません。

そのため、GROUP BY を含むビューは更新不可と判断するのがFE試験では重要です。

試験での切り分け

ビューの定義 判断の目安 理由
WHERE で行を絞る 更新可能になり得る 元の行との対応が残る
GROUP BY 更新不可 複数行をまとめる
SUM、COUNT、AVG などの集約関数 更新不可 元のどの行を直すか決められない
DISTINCT 更新不可と考える 重複をまとめるため元の行が一意に決まりにくい
ビューに対するビュー 条件次第 元のビューが更新可能かなどによる
元表の主キーを含まない それだけで更新不可とは限らない 主キーの有無だけでは決まらない

このテーマは基本情報技術者試験の「データベース」と関係します。公式の出題範囲やシラバスは、IPA：基本情報技術者試験 から確認できます。

科目Aでどう出る？

科目Aでは、ビューについて主に次の2パターンで問われます。

1. SELECT権限を問う問題

判断するときは、誰が何を問い合わせようとしているかを確認します。

ビューを問い合わせたい
↓
ビューのSELECT権限を見る

元の表を直接問い合わせたい
↓
元の表のSELECT権限を見る
選択肢の考え方 判断
ビューと元の表の両方のSELECT権限が必要 誤りと判断する
ビューか元の表のどちらか一方の権限があればよい 誤りと判断する
元の表のSELECT権限があればビューも見られる 誤りと判断する
ビューのSELECT権限があればビューを参照できる 正しいと判断する

試験中は、次の言い換えが役立ちます。

元の表から作られていることと、元の表を直接見る権限があることは別。

2. 更新可能かを問う問題

このタイプでは、SQLを細かく読む前に、次の語を探します。

GROUP BY
SUM / COUNT / AVG などの集約関数
DISTINCT

これらは、複数行をまとめる処理です。

したがって、更新不可を強く疑います。

元表の1行に戻せる
→ 更新可能になりやすい

複数行をまとめている
→ 更新不可

特に4択で、GROUP BY を含むビューと WHERE を含むビューが並んでいたら、GROUP BY の方を更新不可として切るのが基本です。

どんな場面で使う？

ビューは、利用者に必要な情報だけを見せたい場面で役立ちます。

例えば、人事部だけが給与を見られるシステムを考えます。

社員表
氏名・部署・給与・住所

一般利用者には、氏名と部署だけを公開します。

一般利用者用ビュー
氏名・部署

人事担当者は、より多くの情報を参照できる別のビューや実表を使います。

このように、ビューを使うことで、利用者ごとに見せる情報を分けることができます。

また、複数の表を結合した複雑な問合せをビューとして定義しておけば、利用者はその複雑さを意識せずに利用できます。

複雑なJOINや条件
↓
ビューとして定義
↓
利用者は1つの表のように参照

よくある誤解・混同

WHERE があると更新できない

WHERE は行を絞り込むための条件です。

元の表のどの行に対応するかが分かる場合は、WHERE があるだけで更新不可になるわけではありません。

WHERE
→ 行を絞る
→ 元の行との対応は残りやすい

元の表の主キーを含まないビューは必ず更新できない

FE試験では、主キーを含むかどうかだけで更新可能性を決めないようにします。

まず見るべきなのは、ビューの行と元の表の行の対応です。

ビューにSELECT権限があるなら元の表も見られる

これは別に考えます。

ビューへのSELECT権限
→ ビューを参照できる

元の表へのSELECT権限
→ 元の表を直接参照できる

ビューのSELECT権限を持っているからといって、元の表を自由に直接参照できるという意味ではありません。

ビューはデータのコピー

ビューは、元の表を単純に複製した別ファイルとして考えるものではありません。

実表
→ 実データを保持

ビュー
→ 元の表から得た結果を表のように見せる

標準仕様・公式ドキュメントで確認する

ビューを含むSQLの基本仕様は ISO/IEC 9075 シリーズで標準化されています。具体的なビュー定義や更新可能性は、PostgreSQLの公式ドキュメントでも確認できます。

PostgreSQLでは、単純なビューが自動更新可能になるための条件が示されており、トップレベルにDISTINCT、GROUP BY、HAVING、集約関数などを含まないことが条件に含まれます。

ただし更新可能ビューの細かな条件はDBMSによって異なるため、FE試験では既存記事どおり 「元の表の行と対応づけられるか」「集約・グループ化されていないか」 を判断軸にします。

まとめ（試験直前用）

  • ビューは、実表から得た結果を1つの表のように見せる仮想的な表
  • SELECT権限は、利用者が何に対してSELECTするかで判断する
  • 更新可能性は、ビューの1行を元の表の1行に戻せるかで考える
  • WHERE は行を絞るだけなので、それだけで更新不可ではない
  • GROUP BY、集約関数、DISTINCT は更新不可を強く疑う
  • 元表の主キーを含まないことだけで更新不可とは決めない
権限問題
→ 何をSELECTする？

更新問題
→ 元の1行に戻せる？

GROUP BY / 集約 / DISTINCT
→ 複数行をまとめる
→ 更新不可を疑う

© 2024-2026 stemtazoo. All rights reserved.