情報処理試験を勉強していると、「外部スキーマって概念スキーマや内部スキーマとどう違うの?」と混乱しがちです。この記事では、外部スキーマの意味と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層スキーマの構造
(営業部の画面)
(経理部の画面)
(管理者の画面)
(テーブル定義・正規化・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層スキーマの「論理的データ独立性」により、概念スキーマが変わっても外部スキーマ(ビュー定義)を適切に修正すれば、アプリケーション側には影響を与えずに済みます。逆に言えば、ビュー定義の修正を怠れば影響が出るため、「完全に無関係」ではなく「影響を局所化できる」という理解が正確です。