情報処理試験を勉強していると、「概念データモデル・論理データモデル・物理データモデルの3つって何が違うの？」と混乱しがちです。
この記事では、データベース設計の中核を担う論理データモデルに絞って、定義・設計手順・試験対策をまとめます。
対象試験と出題頻度
論理データモデルは、基本情報技術者・応用情報技術者で出題されるテーマです。
データベース設計の工程分類や、概念・物理との違いを正確に区別できるかが問われます。3層スキーマの概念スキーマとの対応関係も頻出ポイントです。
詳細をクリックして確認
基本情報技術者
応用情報技術者
★★★★☆
ランクA（重要）必ず覚えておくべき
用語の定義
論理データモデル（Logical Data Model）とは、一言で言うと
「概念設計で洗い出したエンティティや関連を、特定のDBMS製品に依存しないテーブル構造として定義したデータモデル」
のことです。
イメージとしては、「間取り図」です。
家を建てるとき、まず「リビング・寝室・キッチンが必要」と要望を出す段階が概念設計です。次に、各部屋の広さや配置を決めた間取り図を描く段階が論理設計に当たります。
そして、鉄筋にするか木造にするか、断熱材に何を使うかを決める段階が物理設計です。
論理データモデルも同じで、「どんなテーブルを、どんな列構成で、どう関連付けるか」を、建材（＝DBMS製品）に縛られずに定義します。
📊 論理データモデルの基本情報
| 項目 | 内容 |
|---|---|
| 英語名 | Logical Data Model |
| 位置づけ | 概念データモデルと物理データモデルの中間に位置する |
| 代表的な種類 | 関係モデル、階層モデル、ネットワークモデル、オブジェクト指向モデル |
| 主な成果物 | 正規化されたテーブル定義、E-R図（詳細版） |
| DBMS依存 | しない（製品固有の設定は物理データモデルで行う） |
解説
データベース設計は「概念設計→論理設計→物理設計」の3段階で進みます。概念設計で「何のデータが必要か」を洗い出し、物理設計で「どのDBMS製品にどう格納するか」を決めます。
この両端をつなぐ中間工程が論理設計であり、ここで作成されるのが論理データモデルです。
3段階のデータモデル比較
概念・論理・物理の3つのモデルは「抽象度」と「DBMS依存の有無」で整理すると区別しやすくなります。
| モデル | 目的 | 抽象度 | DBMS依存 | 主な成果物 |
|---|---|---|---|---|
| 概念データモデル | 業務上必要なデータの実体と関連を洗い出す | 高い | なし | E-R図（概要レベル） |
| 論理データモデル | エンティティを正規化し、テーブル構造・キー・制約を定義する | 中間 | なし | 正規化済みテーブル定義、E-R図（詳細版） |
| 物理データモデル | 特定のDBMS製品上の格納形式・インデックス・容量を決定する | 低い | あり | DDL（CREATE TABLE文）、インデックス定義、パーティション設計 |
図解：概念→論理→物理の設計フロー
3段階の流れを視覚的に整理します。
データベース設計の3段階
① 概念設計
業務要件からエンティティ（顧客・商品など）と関連を抽出
成果物：E-R図（概要レベル）
② 論理設計（← 論理データモデルの作成）
正規化でテーブルを分割し、主キー・外部キー・制約を定義
成果物：正規化済みテーブル定義、E-R図（詳細版）
③ 物理設計
DBMS製品に合わせてDDLを記述し、インデックスや領域を設定
成果物：CREATE TABLE文、インデックス定義、ディスク容量見積り
▲ 上から下へ進むほど抽象度が下がり、DBMS製品への依存度が上がる
論理設計で行う作業
論理設計の中心作業は「正規化」です。
概念設計で抽出したエンティティには、属性の重複や依存関係の不整合が残っている場合があります。これを第1正規形→第2正規形→第3正規形と段階的に分解し、データの冗長性を排除します。
正規化と並行して、主キー・外部キー・一意性制約などの整合性制約を定義し、エンティティ間のカーディナリティ（1対1、1対多、多対多）を確定させます。
詳細解説：正規化の3ステップ（折りたたみ）
第1正規形：繰り返し項目を排除し、すべての属性を単一値にする。例えば「注文明細」の中に商品が3つ並んでいたら、それぞれ別の行に分解する。
第2正規形：部分関数従属を排除する。複合キーの一部だけで決まる属性を別テーブルに切り出す。
第3正規形：推移関数従属を排除する。非キー属性が別の非キー属性を経由して主キーに依存している場合、その属性を別テーブルに分離する。
※IPA試験の午前問題では第3正規形までの理解で十分です。ボイスコッド正規形・第4正規形以降はデータベーススペシャリスト試験の範囲なので、FE/APでは深追い不要です。
4種類の論理データモデル
論理データモデルには複数の種類が存在します。現在最も普及しているのは関係モデル（リレーショナルモデル）であり、IPA試験で「論理データモデル」と言えばほぼ関係モデルを指します。
| モデル名 | データ構造 | 特徴 |
|---|---|---|
| 関係モデル | 2次元の表（テーブル） | 最も普及。集合論に基づき、SQLで操作する |
| 階層モデル | 木構造（親子関係） | 1対多の関係を表現。多対多は直接表現できない |
| ネットワークモデル | 網構造（グラフ） | 多対多を表現可能だが構造が複雑 |
| オブジェクト指向モデル | オブジェクト（属性＋操作） | 継承・カプセル化などのOOP概念を取り入れたモデル |
3層スキーマとの対応関係
前述の3段階の設計工程は、ANSI/SPARCの3層スキーマアーキテクチャと対応しています。
| 設計工程 | 対応するスキーマ | 定義する内容 |
|---|---|---|
| 概念設計 | 概念スキーマ | DB全体の論理構造（テーブル定義・正規化） |
| 論理設計 | 概念スキーマ（詳細化） | 正規化済みテーブル・キー・制約の確定 |
| 物理設計 | 内部スキーマ | ファイル編成・インデックス・格納領域 |
では、この用語が試験でどのように出題されるか見ていきましょう。
💡 論理データモデルの核心を3行で
・概念設計の成果をテーブル構造・キー・制約として定義するDBMS非依存のモデル
・代表的な種類は関係モデル・階層モデル・ネットワークモデル・オブジェクト指向モデルの4つ
・論理設計の中心作業は正規化（第1→第2→第3正規形）によるテーブル分割
試験ではこう出る！
論理データモデルは、FE・APの午前問題で繰り返し出題されています。直接「論理データモデルとは何か」を問う形式のほか、外部設計の工程で行う作業として間接的に問われるケースもあります。
📊 過去問での出題実績
| 試験回 | 出題内容 | 問われたポイント |
|---|---|---|
| AP H17秋 午前 問43 |
論理データモデル作成のアプローチ（トップダウン/ボトムアップ）に関する正しい記述を選ぶ問題 | ・正解は「最終的な論理データモデルは正規化され、すべての属性を備えていなければならない」 ・トップダウン＝概念モデルから、ボトムアップ＝画面・帳票からの違いがひっかけ |
| FE H31春 午前 問26 |
関係モデルの属性に関する記述として適切なものを選ぶ問題 | ・「データを2次元の表で表す論理データモデル」が関係モデルの定義 ・階層モデル・ネットワークモデルの特徴がひっかけ |
| FE H29春 午前 問46 |
外部設計工程で実施する作業を選ぶ問題 | ・正解は「論理データモデル設計」を含む選択肢 ・内部設計の作業（物理データ設計など）がひっかけ |
| AP R4春 午前 問57 |
データ管理者（DA）の役割として適切なものを選ぶ問題 | ・正解は「論理データベース設計を行い、データ項目を標準化する」 ・物理設計・パフォーマンスチューニング・障害復旧はDBA（データベース管理者）の役割 |
📝 IPA試験での出題パターン
パターン1：「論理データモデルの種類・特徴を選べ」
関係モデル・階層モデル・ネットワークモデルの説明文が並び、正しい組み合わせを選ぶ形式です。ここだけは確実に押さえてください。判別キーワードは「2次元の表＝関係モデル」「木構造＝階層モデル」「網構造＝ネットワークモデル」です。
パターン2：「外部設計の工程で行う作業を選べ」
FEでは繰り返し出題されている定番問題です。外部設計＝「サブシステムの定義と機能分割、論理データモデル設計、画面・帳票・コードの設計」と丸ごと覚えてしまうのが最も効率的です。
パターン3：「DA（データ管理者）の役割を選べ」
DAが論理設計を担い、DBAが物理設計・運用保守を担うという役割分担が問われます。「論理＝DA」「物理＝DBA」の対応さえ覚えれば即答できます。
試験ではここまででOKです。各正規形の詳細な計算手順はデータベーススペシャリスト試験の領域なので、FE/AP対策では深追い不要です。
【確認テスト】理解度チェック
ここまでの内容を理解できたか、簡単なクイズで確認してみましょう。
Q. データベース設計における論理データモデルの説明として、最も適切なものはどれでしょうか？
- A. 概念設計で抽出したエンティティや関連を正規化し、特定のDBMS製品に依存しないテーブル構造として定義したモデルである。
- B. 特定のDBMS製品に合わせてインデックスやファイル編成を定義し、ディスク上の格納方式を決定したモデルである。
- C. 業務上必要なデータの実体と関連を、技術的な制約を考慮せずに図として洗い出した最も抽象度の高いモデルである。
正解と解説を見る
正解：A
解説：
論理データモデルは、概念設計の成果を正規化によって整理し、DBMS製品に依存しないテーブル構造・キー・制約として定義するモデルです。
選択肢Bは物理データモデルの説明です。インデックスやファイル編成といったDBMS固有の設定は物理設計で行うため、論理データモデルの範囲には含まれません。選択肢Cは概念データモデルの説明です。概念データモデルは最も抽象度が高く、業務要件の把握に焦点を当てたモデルであり、正規化やテーブル定義には踏み込みません。
よくある質問（FAQ）
Q. 論理データモデルの作成はトップダウンとボトムアップのどちらで行いますか？
どちらのアプローチも使えます。トップダウンは概念データモデル（E-R図）をもとに具体化する方法で、将来の拡張性を見据えた設計がしやすい反面、現場のニーズとズレるリスクがあります。ボトムアップは既存の画面・帳票を素材にテーブルを組み立てる方法で、現場の実態を反映しやすい反面、全体最適の視点が欠けやすくなります。AP H17秋 午前問43ではこの違いが直接出題されました。
Q. E-R図は概念データモデルと論理データモデルのどちらに属しますか？
両方で使われます。概念設計段階ではエンティティ間の大まかな関連を示す「概要E-R図」として作成し、論理設計段階では属性・キー・カーディナリティまで記述した「詳細E-R図」に発展させます。IPA試験の文脈では「概念データモデルをE-R図で表す」という出題が多いですが、論理設計でもE-R図を活用する点は押さえておいてください。
Q. NoSQLデータベースにも論理データモデルはありますか？
あります。ただし、関係モデルのような統一的な標準は存在しません。KVS（キーバリューストア）ではキーと値のペア設計、ドキュメント指向ではJSONスキーマの設計、グラフ型ではノードとエッジの設計がそれぞれ論理設計に相当します。IPA試験のFE/APの範囲では、論理データモデルと言えば関係モデルのことを指すため、NoSQLの論理設計まで深追いする必要はありません。
Q. 実務ではどのツールで論理データモデルを作成しますか？
代表的なツールとしてはER/Studio、A5:SQL Mk-2、MySQL Workbench、draw.ioなどがあります。いずれもエンティティ・属性・リレーションシップを視覚的に配置し、そこからDDL（CREATE TABLE文）を自動生成する機能を備えています。ツール名自体がIPA試験で問われることはないので、参考知識として把握しておけば十分です。
