情報処理試験を勉強していると、「外部スキーマって概念スキーマや内部スキーマとどう違うの?」と混乱しがちです。この記事では、外部スキーマの意味と3層スキーマの中での位置づけを、日常の例え話を交えて解説します。

対象試験と出題頻度

外部スキーマは、基本情報技術者・応用情報技術者で出題されるテーマです。

ANSI/SPARC 3層スキーマの各層の役割を正確に区別できるかが問われます。

「概念スキーマ」「内部スキーマ」との違いを整理しておくことが得点の鍵です。

詳細をクリックして確認
対象試験:
基本情報技術者
応用情報技術者
出題頻度:
★★★☆☆
ランクB(標準)覚えておくと有利

用語の定義

外部スキーマ(External Schema)とは、一言で言うと

 「データベースを利用者ごとの目的に応じた見方で切り出した定義

のことです。

イメージとしては、図書館の検索端末に表示される画面です。

図書館には膨大な蔵書データがありますが、一般利用者が検索端末で見られるのは「書名・著者名・貸出状況」程度です。一方、図書館職員が使うシステムでは「仕入れ価格・保管棚番号・廃棄予定日」まで表示されます。

このように、同じデータベースでも利用者の役割に応じて「見える範囲」を切り替えたもの、それが外部スキーマです。RDBMSでは「ビュー(VIEW)」が外部スキーマの代表的な実装にあたります。

📊 外部スキーマの基本情報

項目 内容
英語名 External Schema
別名 サブスキーマ、ユーザビュー
所属モデル ANSI/SPARC 3層スキーマアーキテクチャ
RDBMSでの実装例 SQLのビュー(CREATE VIEW文)
役割 利用者ごとに必要なデータだけを見せる

解説

データベースは複数の部署や役職のユーザーが同時に利用します。しかし、全員に同じデータを同じ形で見せると、不要な情報が混在して業務効率が落ちるだけでなく、セキュリティ上のリスクにもなります。

この問題を解決するために、ANSI/SPARC(米国規格協会の標準計画要求委員会)は1975年にデータベースの定義を3つの層に分離するアーキテクチャを提唱しました。

3層スキーマの全体像

3層スキーマは「外部スキーマ」「概念スキーマ」「内部スキーマ」の3階層で構成されます。

各層が独立しているからこそ、ある層の変更が他の層に波及しない=「データの独立性」が確保されます。

ANSI/SPARC 3層スキーマの構造

外部スキーマA
(営業部の画面)
外部スキーマB
(経理部の画面)
外部スキーマC
(管理者の画面)
↕ 論理的データ独立性
概念スキーマ
(テーブル定義・正規化・E-R図)
↕ 物理的データ独立性
内部スキーマ
(ファイル編成・インデックス設定)

▲ 上から順に「利用者に近い層」→「記憶装置に近い層」となる

3層それぞれの役割比較

何を定義するか RDBMSでの具体例
外部スキーマ 利用者ごとの目的に応じたデータの見え方 ビュー(VIEW)、サブスキーマ
概念スキーマ データベース全体の論理的な構造 テーブル定義、正規化、E-R図
内部スキーマ データを記憶装置上にどう格納するか ファイル編成、インデックス定義

データの独立性が確保される仕組み

3層に分離する最大のメリットは「データの独立性」です。具体的には2種類あります。

論理的データ独立性:概念スキーマ(テーブル構造)を変更しても、外部スキーマ(ビュー)を適切に再定義すれば、アプリケーションプログラムに影響を与えません。

物理的データ独立性:内部スキーマ(格納方式やインデックス)を変更しても、概念スキーマに影響を与えません。つまり、ハードディスクからSSDへの移行やインデックスの追加は、テーブル定義やビューに波及しません。

SQLビューで見る外部スキーマの具体例

実際のRDBMSでは、外部スキーマはCREATE VIEW文で定義します。

以下は「社員テーブル」から営業部向けに必要な列だけを抽出するビューの例です。

-- 概念スキーマ(実テーブル)
CREATE TABLE 社員 (
    社員ID    INT PRIMARY KEY,
    氏名      VARCHAR(50),
    部署      VARCHAR(30),
    給与      INT,
    入社日    DATE
);

-- 外部スキーマ(営業部向けビュー)
CREATE VIEW 営業部員一覧 AS
SELECT 社員ID, 氏名, 入社日
FROM 社員
WHERE 部署 = '営業部';

▲ ビュー「営業部員一覧」では給与列が非表示になり、営業部の社員だけに絞られる

この例では、営業部の利用者には給与情報が見えません。同じ実テーブルでも、経理部向けには給与列を含む別のビューを定義できます。

これが「利用者ごとの見方を分離する」外部スキーマの本質です。

では、この用語が試験でどのように出題されるか見ていきましょう。

💡 外部スキーマの核心を3行で

・ANSI/SPARC 3層スキーマの最上位層で、利用者ごとのデータの見え方を定義する
・RDBMSではSQLのビュー(CREATE VIEW)が外部スキーマに該当する
・概念スキーマとの間で「論理的データ独立性」を確保する役割を持つ


試験ではこう出る!

外部スキーマは、FE・APの科目A(午前)問題で3層スキーマの各層の役割を問う形で繰り返し出題されています。

📊 過去問での出題実績

試験回 出題内容 問われたポイント
AP R4春
午前 問27
内部スキーマの設計に含まれるものを選ぶ問題。 ・正解は「インデックスの定義」
・E-R図作成や正規化は概念スキーマとして除外
AP H28秋
午前 問26
3層スキーマ構造に関する正しい記述を選ぶ問題。 ・正解は「外部スキーマは利用者からの見方を表現する」
・「物理スキーマ」は3層スキーマに存在しない
FE H27春
午前 問26
3層スキーマアーキテクチャを採用する目的を選ぶ問題。 ・正解は「物理的格納構造の変更がアプリに影響しないようにする」
・データ独立性の確保が最大の目的
FE H18秋
午前 問58
3層スキーマの各層と具体例の対応を選ぶ問題。 ・外部スキーマ=ビュー
・概念スキーマ=テーブル定義・正規化
・内部スキーマ=ファイル編成

📝 IPA試験での出題パターン

パターン1:「各スキーマの説明として正しいものを選べ」
3層それぞれの説明文を入れ替えたひっかけが定番です。「概念スキーマ=物理的関係」「内部スキーマ=論理的関係」のように入れ替えた選択肢が紛れ込みます。ここだけは確実に押さえてください。外部=利用者の見方、概念=論理構造、内部=格納方式、と対応を暗記すれば対処できます。

 

パターン2:「3層スキーマの目的・メリットを選べ」
FE H27春のように「なぜ3層に分けるのか」を直接問う形式です。正解は常に「データの独立性の確保」に帰着します。「ビューの作成」や「プログラム言語の限定」はひっかけです。

 

試験ではここまででOKです。ANSI/SPARCの歴史的経緯やネットワークモデルでのサブスキーマの詳細まで深追いする必要はありません。


【確認テスト】理解度チェック

ここまでの内容を理解できたか、簡単なクイズで確認してみましょう。


Q. ANSI/SPARC 3層スキーマにおける外部スキーマの説明として、最も適切なものはどれでしょうか?

  • A. データベース化対象の業務とデータの内容を、論理的なデータモデルとして表現したもの。
  • B. 概念スキーマで定義されたデータモデル上に、利用者ごとの目的に応じた見方を表現したもの。
  • C. 概念スキーマで定義されたデータモデルを、記憶装置上にどのような形式で格納するかを表現したもの。

正解と解説を見る

正解:B

解説:
外部スキーマは、利用者ごとの視点でデータの見え方を定義する層です。RDBMSではビュー(VIEW)がこれに該当します。

選択肢Aは概念スキーマの説明です。概念スキーマはデータベース全体の論理構造を定義する層であり、テーブル定義・正規化・E-R図がこれに相当します。選択肢Cは内部スキーマの説明です。内部スキーマはデータの物理的な格納方式を定義する層であり、ファイル編成やインデックスの設定が該当します。


よくある質問(FAQ)

Q. 外部スキーマは複数定義できますか?

定義できます。1つのデータベースに対して、利用者や部門ごとに複数の外部スキーマを作成するのが一般的です。営業部用・経理部用・管理者用など、用途に応じてビューを分けることで、不要な列やレコードを非表示にし、セキュリティと操作性を両立させます。

Q. 「物理スキーマ」という用語は3層スキーマに含まれますか?

含まれません。ANSI/SPARC 3層スキーマは「外部・概念・内部」の3つで構成されており、「物理スキーマ」という名称は存在しません。AP H28秋 午前 問26では、選択肢エに「物理スキーマはデータの物理的関係を表現する」という記述が登場しましたが、これは不正解です。内部スキーマが物理的な格納方式を扱います。

Q. 外部スキーマと排他制御は関係がありますか?

直接の関係はありません。外部スキーマは「見え方」を制御する仕組みであり、排他制御は「同時アクセスによるデータ矛盾」を防ぐ仕組みです。ただし、ビューに対する更新操作が実テーブルに反映される場合、排他制御(ロック)の対象は実テーブル側になります。試験では別々の論点として出題されます。

Q. 概念スキーマを変更したら外部スキーマも必ず壊れますか?

必ず壊れるわけではありません。3層スキーマの「論理的データ独立性」により、概念スキーマが変わっても外部スキーマ(ビュー定義)を適切に修正すれば、アプリケーション側には影響を与えずに済みます。逆に言えば、ビュー定義の修正を怠れば影響が出るため、「完全に無関係」ではなく「影響を局所化できる」という理解が正確です。