情報処理試験を勉強していると、「概念データモデル・論理データモデル・物理データモデルって何が違うの？」と混乱しがちです。
この記事では、物理データモデルの意味を日常の例え話で整理し、試験で問われるポイントを確認テスト付きで解説します。
対象試験と出題頻度
物理データモデルは、基本情報技術者・応用情報技術者で出題されるテーマです。
データベース方式の分野で「3層スキーマ」や「データモデルの種類」の問題として繰り返し登場しており、概念データモデル・論理データモデルとの違いを正確に区別できるかが問われます。
詳細をクリックして確認
基本情報技術者
応用情報技術者
★★★★☆
ランクA（重要）必ず覚えておくべき
用語の定義
物理データモデル（Physical Data Model）とは、一言で言うと
「論理データモデルで定義されたデータ構造を、実際のDBMSの記憶装置上にどう格納するかを具体的に定めたモデル」
のことです。
イメージとしては、「家の施工図面（構造図）」です。
家を建てるとき、まず「どんな暮らしがしたいか」を考え（概念設計）、次に「部屋の数や配置」を決め（論理設計）、最後に「柱をどの木材で作るか、配管をどこに通すか」を決めます。
この最後の工程が物理データモデルに当たります。データベースでは「テーブルをどのファイル形式で保存し、どの列にインデックスを張るか」を決める段階です。
📊 物理データモデルの基本情報
| 項目 | 内容 |
|---|---|
| 英語名 | Physical Data Model |
| 対応するスキーマ | 内部スキーマ（記憶スキーマ） |
| 決定する内容 | ファイル編成、インデックス設計、パーティション分割、データ型の物理サイズ |
| IPA シラバスでの分類 | テクノロジ系 ＞ データベース ＞ データベース方式 |
解説
データベース設計は、抽象度の高い順に「概念データモデル → 論理データモデル → 物理データモデル」の3段階で進みます。この3段階は、ANSI/SPARC 3層スキーマの考え方と密接に対応しています。
3段階のデータモデルと3層スキーマの対応
3つのデータモデルがそれぞれ何を決めるものかを整理すると、以下のようになります。
概念 → 論理 → 物理 の流れ
概念データモデル
「何を管理するか」をエンティティと関連で整理
対応：外部スキーマ ＋ 概念スキーマの上流
論理データモデル
「どんな構造で表現するか」を表・正規化で定義
対応：概念スキーマ
物理データモデル
「記憶装置上にどう格納するか」を具体的に決定
対応：内部スキーマ（記憶スキーマ）
3つのデータモデルの比較表
ここだけは確実に押さえてください。
3者を「誰のため」「何を決める」「成果物は何か」で整理すると一発で区別がつきます。
| 観点 | 概念データモデル | 論理データモデル | 物理データモデル |
|---|---|---|---|
| 誰のため | ユーザー・業務担当者 | DB設計者 | DBA（データベース管理者） |
| 何を決める | 管理対象（エンティティ）と関連 | テーブル構造・正規化・制約 | 格納方式・インデックス・パーティション |
| 成果物 | E-R図 | テーブル定義書（CREATE TABLE） | ファイル編成定義・インデックス定義 |
| DBMS依存 | しない | しない（モデルに依存） | する（MySQL, Oracleなど） |
| 対応スキーマ | （概念スキーマの上流工程） | 概念スキーマ | 内部スキーマ |
物理データモデルで決定する具体的な内容
何となくで覚えたい人はスキップOK ― 詳細を見る
物理データモデルの段階で決めるのは、大きく分けて以下の4点です。
① ファイル編成の選択
順編成、索引順編成、直接編成、VSAM（Virtual Storage Access Method）など、レコードをどの方式でディスク上に並べるかを選びます。
② インデックス（索引）設計
検索速度を上げるために、どの列にB+木インデックスやハッシュインデックスを作成するかを決めます。AP R4春 午前問27では、内部スキーマの設計内容としてインデックスの定義が正解でした。
③ パーティション分割
大量データを扱うテーブルを水平分割（行単位）や垂直分割（列単位）で複数の物理領域に分ける方法です。
④ データ型の物理サイズ指定
VARCHAR(255)やINT(11)のように、具体的なDBMS製品に合わせた型とサイズを指定します。論理データモデルの段階では「文字列型」「整数型」程度だった定義が、ここで具体化されます。
では、この用語が試験でどのように出題されるか見ていきましょう。
💡 物理データモデルの核心を3行で
・論理データモデルを記憶装置上に実装するための具体的な格納構造を定義する
・ANSI/SPARC 3層スキーマでは「内部スキーマ」に対応する
・ファイル編成・インデックス設計・パーティション分割が主な決定事項
試験ではこう出る！
物理データモデルそのものをピンポイントで問う問題は少なく、3層スキーマの文脈で「内部スキーマ＝物理的な格納構造」を選ばせる形式が中心です。
📊 過去問での出題実績
| 試験回 | 出題内容 | 問われたポイント |
|---|---|---|
| AP R4春 午前 問27 |
内部スキーマの設計に含まれるものを選ぶ問題。 | ・正解は「インデックスの定義」 ・E-R図作成、正規化、参照制約は概念スキーマ |
| AP H28秋 午前 問26 |
3層スキーマ構造に関する記述を選ぶ問題。 | ・正解は「外部スキーマはデータの利用者からの見方を表現する」 ・ひっかけ：「物理スキーマ」は3層スキーマに存在しない名称 |
| FE H27春 午前 問26 |
3層スキーマアーキテクチャを採用する目的を選ぶ問題。 | ・正解は「物理的な格納構造の変更がアプリに影響しない」 ・物理データ独立性の確保が問われた |
| AP R1秋 午前 問26 |
概念設計で使われるデータモデルを選ぶ問題。 | ・正解は「E-Rモデル」 ・階層モデル、関係モデル、ネットワークモデルとの区別 |
📝 IPA試験での出題パターン
パターン1：「3層スキーマの説明を選べ」
概念スキーマ・外部スキーマ・内部スキーマの役割説明が並び、正しいものを選ぶ形式。ひっかけとして「概念スキーマは物理的関係を表現する」「物理スキーマは〜」のように存在しない名称や役割を入れ替えた選択肢が紛れ込む。キーワードは「格納構造」「ファイル編成」「インデックス」。
パターン2：「内部スキーマの設計に含まれるものを選べ」
AP R4春のように、内部スキーマの設計作業として正しいものを選ばせる形式。「インデックスの定義」を選ばせる問題が典型。「E-R図作成」「正規化」は概念スキーマの作業なので除外する。
試験ではここまででOKです。物理データモデルの詳細な設計手法（パーティション分割の種類など）まで問われることはFE・APレベルではほぼないので、深追いは不要です。
【確認テスト】理解度チェック
ここまでの内容を理解できたか、簡単なクイズで確認してみましょう。
Q. ANSI/SPARC 3層スキーマモデルにおける内部スキーマの説明として、最も適切なものはどれでしょうか？
- A. データベース化対象の業務とデータの内容を論理的なデータモデルとして表現したもの。
- B. 概念スキーマで定義されたデータモデル上に、利用者ごとの目的に応じた見方を表現したもの。
- C. 概念スキーマで定義されたデータモデルを、記憶装置上にどのような形式で格納するかを表現したもの。
正解と解説を見る
正解：C
解説：
内部スキーマは、データを記憶装置上にどのような形式で格納するかを定義するスキーマであり、物理データモデルに対応します。ファイル編成やインデックスの設定がこれに該当します。
選択肢Aは概念スキーマの説明です。概念スキーマは業務上のデータ構造を論理的に定義するもので、テーブル定義や正規化が該当します。選択肢Bは外部スキーマの説明です。外部スキーマは利用者ごとに異なるデータの見方を定義するもので、SQLのビューが該当します。
よくある質問（FAQ）
Q. 「物理スキーマ」と「内部スキーマ」は同じものですか？
実務では「物理スキーマ」という表現を使う場面もありますが、ANSI/SPARC 3層スキーマの正式な名称は「内部スキーマ（記憶スキーマ）」です。AP H28秋 午前問26では、選択肢に「物理スキーマは〜」という表現が登場しましたが、「3層スキーマ構造には物理スキーマという名称は存在しない」として不正解でした。IPA試験では「内部スキーマ」と答えるのが正解です。
Q. 「物理データ独立性」と「論理データ独立性」はどう違いますか？
物理データ独立性とは、内部スキーマ（格納構造）を変更しても概念スキーマに影響が及ばない性質です。たとえばインデックスを追加してもテーブル定義は変わりません。一方、論理データ独立性は、概念スキーマ（テーブル構造）を変更しても外部スキーマ（利用者のビュー）に影響が及ばない性質です。FE H27春 午前問26では「物理的な格納構造を変更してもアプリケーションに影響が及ばない」が3層スキーマの採用目的の正解でした。
Q. 実務で物理データモデルを設計するのは誰ですか？
主にDBA（データベース管理者）やインフラエンジニアが担当します。使用するDBMS製品（MySQL、PostgreSQL、Oracle Databaseなど）の特性を踏まえ、ストレージエンジンの選択、テーブルスペースの配置、インデックス戦略、パーティションの分割方針を決定します。アプリケーション開発者が概念・論理データモデルを設計し、DBAが物理データモデルに落とし込むという分業が一般的です。
Q. 論理データモデルの「関係モデル」「階層モデル」「ネットワークモデル」は物理データモデルとどう関係しますか？
関係モデル・階層モデル・ネットワークモデルは、いずれも論理データモデルのレベルで「データをどんな構造で表現するか」を定めるものです。物理データモデルは、これらの論理構造を受け取った上で、特定のDBMS上に実装するための格納方式を決定します。したがって、同じ関係モデル（リレーショナル）でも、MySQLとOracle Databaseでは物理データモデルの内容（ストレージエンジン、データ型サイズ等）が異なります。
