対象試験と出題頻度
3層スキーマは、基本情報技術者・応用情報技術者で出題されるテーマです。
データベース分野の設計・方式に関する問題として定番化しており、「外部スキーマ」「概念スキーマ」「内部スキーマ」それぞれの役割と対応する具体例を正確に区別できるかが問われます。
詳細をクリックして確認
基本情報技術者
応用情報技術者
★★★★☆
ランクA（重要）必ず覚えておくべき
用語の定義
情報処理試験を勉強していると、「外部スキーマ？概念スキーマ？内部スキーマ？何が違うの？」と混乱しがちです。
3層スキーマ（ANSI/SPARC 3層スキーマ）とは、一言で言うと
「データベースの構造を外部・概念・内部の3階層に分けて定義するモデル」
のことです。
イメージとしては、「同じ建物を”利用者・設計者・施工業者”の3つの立場から見る設計図」です。
マンションの住人は間取り図（外部スキーマ）だけ見れば十分です。建築士はマンション全体の構造図（概念スキーマ）を描きます。施工業者は鉄筋の配置や配管の経路（内部スキーマ）を扱います。3者が見ている情報はまったく異なりますが、対象は同じ一棟のマンションです。
3層スキーマも同じで、1つのデータベースを「利用者の見方」「論理的な全体構造」「物理的な格納方法」の3階層に分離して管理します。
📊 3層スキーマの基本情報
| 項目 | 内容 |
|---|---|
| 正式名称 | ANSI/SPARC 3層スキーマアーキテクチャ |
| 提唱 | ANSI（米国国家規格協会）のSPARC委員会が1975年に提案 |
| 目的 | データの論理的独立性と物理的独立性の確保 |
| 3つの層 | 外部スキーマ・概念スキーマ・内部スキーマ |
解説
データベースを運用する現場では、利用者ごとに必要なデータの範囲が異なります。経理部門は売上データだけ見たいし、人事部門は従業員データだけ見たい。
一方で、DBMSの管理者はデータ全体の構造を把握しなければならず、さらにディスクへの格納方式を調整する担当者も存在します。
もしこれらをすべて1つの定義で管理すると、物理的な格納方式を変更しただけでアプリケーション側のプログラムまで書き直す必要が生じます。
この「変更の連鎖」を断ち切るために、3つの階層に分離する設計思想が採用されました。
3つのスキーマの役割
各スキーマが「誰の視点で、何を定義するか」を正確に区別することが理解の土台になります。
| スキーマ | 視点 | 役割 | 具体例 |
|---|---|---|---|
| 外部スキーマ | 利用者 | 個々の利用者やアプリケーションが必要とするデータの見方を定義 | SQLのビュー、サブスキーマ |
| 概念スキーマ | DB管理者 | データベース全体の論理的な構造を定義 | E-R図、CREATE TABLE文、正規化 |
| 内部スキーマ | 記憶装置 | データを記憶装置上にどのように格納するかを定義 | ファイル編成、インデックス定義 |
※外部スキーマ・概念スキーマ・内部スキーマの個別の詳細は、それぞれの詳細ページで解説しています。
図解：3層スキーマの構造と独立性
3つのスキーマがどのように積み重なり、データの独立性を実現しているかを図で整理します。
ANSI/SPARC 3層スキーマの構造
視点
外部スキーマ
ビュー・サブスキーマなど利用者ごとの見方
視点
概念スキーマ
DB全体の論理構造（テーブル定義・正規化・E-R図）
視点
内部スキーマ
物理的な格納形式（ファイル編成・インデックス）
▲ 各層の間に「独立性」があるため、ある層を変更しても他の層への影響を最小化できる
2種類のデータ独立性
3層に分離する最大の目的は、データの独立性を確保することです。独立性には2種類あります。
| 独立性の種類 | 意味 | 具体例 |
|---|---|---|
| 論理的データ独立性 | 概念スキーマを変更しても外部スキーマ（利用者の見方）に影響を与えない | テーブルに列を追加しても、既存のビュー定義はそのまま動く |
| 物理的データ独立性 | 内部スキーマを変更しても概念スキーマ（論理構造）に影響を与えない | ディスクの格納方式やインデックスを変更しても、テーブル定義は変わらない |
先ほどの図で示した「↕」の部分がこの独立性に該当します。この仕組みがあるからこそ、物理的な格納構造を変更してもアプリケーションプログラムに影響が及ばないのです。
では、この用語が試験でどのように出題されるか見ていきましょう。
💡 3層スキーマの核心を3行で
・外部スキーマ＝利用者の見方（ビュー）、概念スキーマ＝論理構造（テーブル定義）、内部スキーマ＝物理格納（インデックス）
・目的は「論理的データ独立性」と「物理的データ独立性」の2つの独立性の確保
・ANSI/SPARCが1975年に提案し、現在のDBMSの設計思想の基盤となっている
試験ではこう出る！
3層スキーマは、FE・APの午前問題で繰り返し出題されている定番テーマです。
出題パターンは大きく2つに分かれます。
📊 過去問での出題実績
| 試験回 | 出題内容 | 問われたポイント |
|---|---|---|
| AP R4春 午前 問27 |
内部スキーマの設計に含まれるものを選ぶ問題 | ・正解は「インデックスの定義」 ・E-R図や正規化は概念スキーマのひっかけ |
| AP H28秋 午前 問26 |
3層スキーマ構造に関する記述の正誤を判定する問題 | ・正解は「外部スキーマは利用者からの見方を表現」 ・「物理スキーマ」という存在しない名称がひっかけ |
| FE H27春 午前 問26 |
3層スキーマアーキテクチャを採用する目的を問う問題 | ・正解は「物理的な格納構造を変更してもアプリに影響が及ばない」 ・ビューやカーソル操作の目的がひっかけ |
| FE H18秋 午前 問58 |
「記録媒体にどのように格納するかを記述したもの」はどれかを選ぶ問題 | ・正解は「内部スキーマ」 ・サブスキーマ＝外部スキーマの別称であることも問われた |
📝 IPA試験での出題パターン
パターン1：「各スキーマの説明として正しいものを選べ」
外部・概念・内部の3つの説明文を入れ替えたひっかけが典型です。「利用者の見方＝外部スキーマ」「論理構造＝概念スキーマ」「物理格納＝内部スキーマ」の対応を暗記しておけば即答できます。AP H28秋 問26では「物理スキーマ」という存在しない名称が選択肢に含まれており、名前に惑わされない知識が必要でした。
パターン2：「3層スキーマの目的（データ独立性）を選べ」
FE H27春 問26のように、3層に分離する目的そのものを問う形式です。ここだけは確実に押さえてください。正解の核心は「物理的な格納構造を変更しても、アプリケーションに影響が及ばないようにする」です。ビューの導出やカーソル操作などの別概念がひっかけとして紛れ込みます。
試験ではここまででOKです。各スキーマの内部的な記述言語や歴史的経緯まで深追いする必要はありません。
【確認テスト】理解度チェック
ここまでの内容を理解できたか、簡単なクイズで確認してみましょう。
Q. DBMSが3層スキーマアーキテクチャを採用する目的として、最も適切なものはどれでしょうか？
- A. データの物理的な格納構造を変更しても、アプリケーションプログラムに影響が及ばないようにする。
- B. 関係演算によって元の表から新たな表を導出し、それが実在しているように見せる。
- C. プログラム言語を限定して、アプリケーションプログラムとDBMSを緊密に結合する。
正解と解説を見る
正解：A
解説：
3層スキーマアーキテクチャは、データベースの構造を外部・概念・内部の3階層に分離し、各層の変更が他の層に波及しないようにする仕組みです。これにより、ディスクの格納方式やインデックスを変更（内部スキーマの変更）しても、概念スキーマや外部スキーマには影響が及びません。
選択肢Bはビュー（外部スキーマの一要素）の説明です。ビューは導出表として仮想的なテーブルを提供しますが、3層に分離する目的そのものではありません。選択肢Cは3層スキーマの目的と真逆です。3層スキーマはアプリケーションとDBMSを「分離」するための設計であり、「緊密に結合」するものではありません。
よくある質問（FAQ）
Q. 「スキーマ」と「テーブル」は何が違いますか？
スキーマは「データベースの構造や制約を定義した設計情報」のことで、テーブルは「実際にデータが格納される表」です。例えるなら、スキーマは建物の設計図であり、テーブルは設計図に基づいて建てられた実際の部屋に相当します。IPA試験では「スキーマ＝構造の定義」という意味で使われます。
Q. 「サブスキーマ」という言葉が出てきたら、どのスキーマのことですか？
サブスキーマは外部スキーマの別称です。FE H18秋 午前問58では選択肢に「サブスキーマ」が含まれており、これを外部スキーマと同一視できるかがポイントでした。「サブスキーマ＝外部スキーマ」とセットで覚えておけば、選択肢の消去に役立ちます。
Q. 現在のRDBMS（MySQL、PostgreSQLなど）は3層スキーマを採用していますか？
ANSI/SPARC 3層スキーマはあくまで「設計思想のモデル」であり、特定のRDBMS製品がそのまま実装しているわけではありません。ただし、ビュー機能（外部スキーマに相当）やCREATE TABLE文（概念スキーマに相当）、ストレージエンジンの設定（内部スキーマに相当）など、3層の考え方は現在のRDBMSの機能に色濃く反映されています。
Q. 3層スキーマと3層クライアントサーバシステムは別物ですか？
まったく別の概念です。3層スキーマは「データベースの構造定義を3階層に分ける設計モデル」であり、3層クライアントサーバシステムは「プレゼンテーション層・ファンクション層・データ層にシステムの機能を分離する構成」です。どちらも「3層」という言葉を使いますが、対象がデータベース設計なのかシステム構成なのかで完全に異なります。
