情報処理試験を勉強していると、「概念データモデルって何?E-R図と何が違うの?」と混乱しがちです。

この記事では、データベース設計の最初のステップである概念データモデルの意味と役割を、身近な例え話と図解で整理します。

対象試験と出題頻度

概念データモデルは、基本情報技術者・応用情報技術者で出題されるテーマです。

UMLのクラス図における多重度の読み取り問題や、E-Rモデルの選択問題として繰り返し問われており、「論理データモデル」「物理データモデル」との違いを正確に区別できるかがポイントになります。

詳細をクリックして確認
対象試験:
基本情報技術者
応用情報技術者
出題頻度:
★★★★☆
ランクA(重要)必ず覚えておくべき

概念データモデルの定義

概念データモデル(Conceptual Data Model)とは、一言で言うと

 「現実世界のデータ構造を、特定のDBMSに依存しない形で抽象的に表現したモデル

のことです。

イメージとしては、家を建てる前の間取りのスケッチです。

間取りのスケッチには「リビング」「キッチン」「寝室」といった部屋の役割と、部屋同士のつながりが描かれています。しかし、柱の材質や配管の径のような施工の詳細は一切書かれていません。

概念データモデルも同じで、「どんなデータがあり、それらがどう関係しているか」だけをシンプルに整理した設計図です。

📊 概念データモデルの基本情報

項目 内容
英語名 Conceptual Data Model
代表的な表記法 E-R図(Entity-Relationship Diagram)、UMLクラス図
主な利用工程 概念設計(要件定義後・論理設計前)
構成要素 エンティティ(実体)、リレーションシップ(関連)、属性(アトリビュート)

解説

データベースを設計するとき、いきなりテーブル定義やSQL文を書き始めると、業務上必要なデータの抜け漏れや関係の矛盾が後から発覚します。

この問題を防ぐために、まず「業務で扱うデータの全体像」をDBMS非依存の形で整理するステップが必要になります。

それが概念設計であり、そこで作成される成果物が概念データモデルです。

3段階のデータモデル

データベース設計は「概念 → 論理 → 物理」の3段階で進みます。

それぞれの役割を正確に区別することが理解の土台になります。

データベース設計の3段階

① 概念データモデル

「何のデータが、どう関係するか」を整理
DBMS非依存 / E-R図で表現

② 論理データモデル

テーブル構造・主キー・外部キーを定義
正規化を適用 / まだDBMS非依存

③ 物理データモデル

インデックス・パーティション・データ型を決定
特定のDBMS(MySQL、PostgreSQLなど)に依存

段階 目的 扱う内容 DBMS依存
概念 業務データの全体像を可視化 エンティティ、リレーションシップ、属性 なし
論理 テーブルとキーの構造を設計 テーブル、主キー、外部キー、正規化 なし
物理 実装レベルの最適化 データ型、インデックス、パーティション あり

E-R図の基本構造

概念データモデルを図として表現する代表的な手法がE-R図(Entity-Relationship Diagram)です。

構成要素は3つだけなので、ここだけは確実に押さえてください。

要素 記号 役割
エンティティ(実体) 長方形 管理したいデータの集合。「顧客」「商品」「注文」など
リレーションシップ(関連) ひし形 or 線 エンティティ間の結びつき。「顧客が注文する」など
属性(アトリビュート) 楕円 エンティティが持つ個別の項目。「顧客名」「注文日」など

図解:ECサイトの概念データモデル(E-R図)

ECサイトを例にした簡易的なE-R図を示します。エンティティ間のカーディナリティ(多重度)にも注目してください。

ECサイトの概念データモデル(E-R図)

顧客

顧客ID
顧客名
メール

1 ———— *
注文する

注文

注文ID
注文日
合計金額

1 ———— *
含む

注文明細

明細ID
数量

* ———— 1
参照する

商品

商品ID
商品名
単価

▲ 顧客と注文は1対多、注文と商品は多対多のため連関エンティティ(注文明細)を挟んで表現

UMLクラス図での多重度表記

IPA試験ではE-R図だけでなく、UMLクラス図の記法で概念データモデルが出題されます。

多重度の読み方は以下の通りです。

記法 意味
1 ちょうど1つ
0..1 0または1つ
* 0以上(制限なし)
1..* 1つ以上
0..* 0以上(*と同義)

UMLクラス図での多重度の読み方

部署
1..* ———————— 0..*
所属する
従業員

部署側の「1..*」=従業員から見て、所属する部署は1つ以上(必ずどこかに所属する)

従業員側の「0..*」=部署から見て、所属する従業員は0人以上(空の部署もあり得る)

では、この多重度の読み取りが試験でどのように出題されるか見ていきましょう。

💡 概念データモデルの核心を3行で

・現実世界のデータ構造をDBMS非依存で抽象的に表現する、データベース設計の最初のステップ
・E-R図(エンティティ・リレーションシップ・属性)またはUMLクラス図で表現する
・「概念 → 論理 → 物理」の3段階の最上流に位置し、業務全体のデータの関係性を俯瞰する


試験ではこう出る!

概念データモデルは、FE・APの科目A(午前)問題で繰り返し出題されています。出題パターンは大きく2つに分かれます。

📊 過去問での出題実績

試験回 出題内容 問われたポイント
FE サンプル
問22
UMLで表した概念データモデルの解釈として適切なものを選ぶ問題。 ・多重度「1..*」「0..*」の読み取り
・「同時に複数の部署に所属してもよい」が正解
FE R1秋
問25
上記サンプル問22と同一構成の問題。 ・FEサンプルとの流用問題
・選択肢の文言もほぼ同一
AP R1秋
午前 問26
概念設計に用いるデータモデルを4択から選ぶ問題。 ・正解は「E-Rモデル」
・階層モデル・関係モデル・ネットワークモデルがひっかけ
AP R6秋
午前 問29
オブジェクト図に対応する概念データモデルを選ぶ問題。 ・インスタンス間の数量関係から多重度を逆算する力が必要

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

パターン1:「多重度を読み取れ」
UMLクラス図で部署と従業員などのエンティティが描かれ、多重度から正しい解釈を選ばせる形式。「1..*」なら「1つ以上」、「0..*」なら「0以上」が読めれば正答できる。ひっかけは「総数が一致する」「所属しない従業員がいてもよい」など。

 

パターン2:「概念設計に使うモデルを選べ」
E-Rモデル・階層モデル・関係モデル・ネットワークモデルの4択が並び、概念設計に用いるものを選ばせる形式。「実体と実体間の関連」というキーワードが出たらE-Rモデルが正解。

 

試験ではここまででOKです。概念データモデルの作成手順や記法の詳細(IE記法・IDEF1Xなど)まで問われることはほぼないので、深追いは不要です。


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

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


Q. データベースの概念設計に用いられ、対象世界を「実体」と「実体間の関連」という二つの概念で表現するデータモデルはどれでしょうか?

  • A. 関係モデル ― データを二次元の表(テーブル)として管理し、表同士を属性値で関連付けるモデル。
  • B. 階層モデル ― データを木構造で構成し、親レコードと子レコードを1対多の関係で結ぶモデル。
  • C. E-Rモデル ― 対象世界をエンティティ(実体)とリレーションシップ(関連)で表現し、概念設計で用いるモデル。

正解と解説を見る

正解:C

解説:
E-Rモデル(Entity-Relationship Model)は、現実世界の対象を「実体」と「実体間の関連」という二つの概念で整理するデータモデルで、データベースの概念設計に広く利用されています。AP R1秋 午前問26でもこの定義がそのまま問われました。

選択肢Aの関係モデルは、データを二次元の表で管理するモデルであり、概念設計ではなく論理設計以降で用いるものです。選択肢Bの階層モデルは、データを親子関係の木構造で表現するモデルであり、多対多の関係を直接表現できないため概念設計には適しません。


よくある質問(FAQ)

Q. 概念データモデルとスキーマ(概念スキーマ)は同じものですか?

異なります。概念データモデルは設計工程で作成するデータの設計図であり、エンティティやリレーションシップで業務データの全体像を表現します。一方、概念スキーマはANSI/SPARC 3層スキーマアーキテクチャにおける用語で、データベース全体の論理的な構造定義を指します。概念データモデルは「設計段階の成果物」、概念スキーマは「データベースの内部定義」と整理してください。

Q. E-R図とUMLクラス図、どちらで概念データモデルを描くのが一般的ですか?

実務ではどちらも使われます。伝統的なデータベース設計ではE-R図(IE記法やIDEF1X記法)が主流ですが、オブジェクト指向開発ではUMLクラス図で概念データモデルを表現するケースも多くなっています。IPA試験では両方の記法が出題されるため、E-R図とUMLクラス図のどちらが出ても読み取れるようにしておくのが安全です。

Q. 概念データモデルの作成は誰が担当しますか?

一般的には、データベース設計者(DBA)やシステムアーキテクトが、業務担当者へのヒアリングをもとに作成します。概念データモデルは技術的な詳細を含まないため、業務部門との認識合わせのコミュニケーションツールとしても機能します。大規模プロジェクトではデータモデラーという専門職が担当することもあります。

Q. 正規化は概念データモデルの段階で行いますか?

行いません。排他制御やインデックスの設計と同様に、正規化は概念設計の次の段階である論理設計で行う作業です。概念データモデルの段階では、あくまでエンティティ間の関係性を大まかに把握することが目的であり、第1正規形〜第3正規形への分解は論理データモデルで実施します。