概念データモデル・とは？初心者でも分かる基本と実例ガイド共起語・同意語・対義語も併せて解説！

この記事を書いた人

高岡智則

年齢：33歳性別：男性職業：Webディレクター（兼ライティング・SNS運用担当）居住地：東京都杉並区・永福町の1LDKマンション出身地：神奈川県川崎市身長：176cm 体系：細身〜普通（最近ちょっとお腹が気になる）血液型：A型誕生日：1992年11月20日最終学歴：明治大学・情報コミュニケーション学部卒通勤：京王井の頭線で渋谷まで（通勤20分）家族構成：一人暮らし、実家には両親と2歳下の妹恋愛事情：独身。彼女は2年いない（本人は「忙しいだけ」と言い張る）

概念データモデル・とは？

データを現実世界の概念で整理する設計の第一歩が「概念データモデル」です。DBMSに依存しない高レベルな設計図として、関係や意味を分かりやすく描くことを目的としています。

概念データモデルは、実際のデータベースの作り方を決める前の、共通言語の役割を果たします。エンティティ（現実世界のものを表す枠組み）、属性（エンティティの特徴）、リレーションシップ（エンティティ同士の関係）といった要素で構成されます。

概念データモデルの特徴

特徴1: 現実世界の意味を中心に記述するため、技術やツールに縛られない点です。

特徴2: コミュニケーションの共通言語として使われ、関係者間での誤解を減らします。

特徴3: 後続の設計段階（論理データモデル、物理データモデル）への橋渡し役を果たします。

構成要素

概念データモデルの三つの基本要素は以下のとおりです。エンティティ、属性、リレーションシップです。

<th>要素

説明	例
エンティティ	現実世界の概念を表す枠組み	顧客, 商品
属性	エンティティの特徴を表す情報	顧客ID, 名前
リレーションシップ	エンティティ同士の関係	購入, 所有

作成の流れ

手順1: 実世界の要素を洗い出す まずは現実世界で関連する概念を紙に書き出します。具体的には「誰が」、「何を」、「いつ・どのように関係するか」を拾い上げます。

手順2: エンティティと属性を整理 次に、どの要素をエンティティとして扱うか、主要な属性は何かを決めます。ここで過剰な詳細を避け、要点だけをまとめると後の設計が楽になります。

手順3: 関係と制約を定義 エンティティ同士のつながり方や、データの整合性を保つための制約（例: 1対多、必須属性など）を決めます。

手順4: 実装の前提を外す この段階ではDBMS固有の機能や用語は使わず、概念としての表現にとどめます。

実例

以下は非常にシンプルな例です。現実のデータベース設計の第一歩として役立ちます。

エンティティ	顧客	注文
主要属性	顧客ID, 氏名	注文ID, 日付
関係	顧客が注文を出す	1対多

よくある誤解と注意点

誤解: 概念データモデルはそのままDBの物理構造になるわけではありません。実装の前提を外すことが大切です。

概念データモデルから次の段階へ

概念データモデルは、論理データモデル、物理データモデルへの橋渡し役です。現実世界の要素を整理してから、データベースの具体的な設計へ移行します。

まとめ

概念データモデルは、データベース設計の最初のステップであり、関係性と意味を高レベルで表現します。DBMSに依存せず、関係者との共通理解を生み出す点が最大の利点です。

概念データモデルの同意語

概念モデル: データの本質的な構造を、実装技術に依存せず高レベルで表現するモデル。エンティティ・属性・関係といった要素を抽象的に定義します。
ERモデル: Entity-Relationship Modelの略。概念データモデルで用いられる代表的な表現で、エンティティ、属性、リレーションシップを使ってデータ間の関係を抽象的に定義します。
ER図: ERモデルを図として表現したもの。要素間の関係を視覚的に把握でき、概念設計の補助として広く使われます。
高レベルデータモデル: 実装技術を問わず、データの大枠を表現する概念的なモデル。概念データモデルとほぼ同義として使われることがあります。
概念設計データモデル: データの概念設計フェーズで作成されるモデルで、要件をもとにエンティティ・属性・関係を定義します。実装前の抽象設計です。
概念データ設計: データの概念設計そのもの、またはその成果物を指す表現。概念モデルと同様の意味で使われることがあります。
ビジネス概念データモデル: ビジネス用語や業務要件を反映した概念データモデル。現場の意味をそのままデータ設計に落とす役割を持ちます。
抽象データモデル: 実装の細部を省略し、データの関係性や意味を抽象的に表現するモデル。概念データモデルの別名として使われることがあります。

概念データモデルの対義語・反対語

物理データモデル: データベースの実装・運用を前提とした、テーブルの列のデータ型・長さ・制約、インデックス、ストレージ配置など、DBMS固有の仕様を反映した具体的な設計。概念データモデルの対義語として挙げられることが多い。
実装データモデル: 特定のデータベース製品やプラットフォームでの実装を前提に、構造を決定したデータモデル。パフォーマンスやストレージの最適化など、現実の運用を重視する段階の設計。
具体データモデル: 概念データモデルの抽象度を下げ、データ属性の型・長さ・制約・キーなど、現実のデータ構造に直結する要素を定義したモデル。
論理データモデル: 概念データモデルから派生し、テーブル・属性・キー・リレーションなどを、DBMS非依存の形で整理した設計。物理的な実装をまだ含まないが、実装寄りの視点を持つ段階。
抽象データモデル: データの性質・関係を高い抽象レベルで表現するモデル。概念データモデルよりも抽象的な観点を持ち、対比として挙げられることがある。
低水準データモデル: 物理的な実装をさらに細かく設計する段階に近い、データの保存形式やアクセス方法といった低レベルの設計を指すことがある。

概念データモデルの共起語

エンティティ: 現実世界の事物や概念を抽象化して表すデータ集合。顧客・商品など、データベースで扱う対象を指す。
属性: エンティティが持つ情報の項目。例：顧客名、住所、価格など。
関係: エンティティ同士の結びつきを表す概念。例：顧客が注文を行う、商品が注文に含まれる。
ER図: Entity-Relationship図。エンティティと関係を図で表現した設計図。
概念スキーマ: 概念データモデルの全体像を示す抽象的な構造。ビジネス要件をデータに落とす設計。
論理データモデル: 概念データモデルを、データベースの論理構造（テーブル・キー・制約など）に落とし込んだ設計。
物理データモデル: 実際のデータベースの物理構造（テーブル設計、データ型、インデックスなど）を表す設計。
ドメイン: 属性が取り得る値の集合と意味を定義する範囲。値の型・制約を含む。
データ型: 属性が保持する値の種類。文字列、整数、日付など。
主キー: エンティティの各レコードを一意に識別する属性または属性の組み合わせ。
候補キー: 主キーとして選択可能な、一意性を満たす属性の集合。
外部キー: 他のエンティティを参照する属性。リレーションを結ぶための参照です。
正規化: データの重複を減らし、整合性を保つための設計手法。段階的な分解を含む。
データ整合性: データの正確性・一貫性を保つ性質。制約の適用が重要。
ビジネスルール: 業務上の制約や条件をデータモデルに反映するルール。
ビジネス概念: 業務の現実を表す概念。データモデルの要件源として重要。
メタデータ: データについてのデータ。定義・出所・作成・更新情報を含む。
データ辞書: エンティティ・属性の定義・意味・型・制約を整理した参照資料。
ドメインモデル: 値の意味付けと制約を抽象化したモデル。実世界の意味を正確に表現。
エンティティタイプ: エンティティの種類を表す概念。例：顧客タイプ、商品タイプ。
属性タイプ: 属性が持つデータ型や性質の分類。
ER図記法: Entity-Relationship図の表現方法。Chen記法や Crow's Foot 記法など。
一意性制約: 値が重複しないようにする制約。主キーや候補キーに関連。
スキーマ: データ構造の設計図。概念・論理・物理のいずれかの階層を指すことがある。
命名規則: エンティティ名・属性名の付け方に関する規則。可読性と一貫性を保つ。

概念データモデルの関連用語

概念データモデル: 現実世界のビジネス概念を抽象化して表現する、データモデリングの最上位レベル。実世界の事象・事物をエンティティと属性で整理する設計段階です。
ERモデル: エンティティとリレーションシップ（関係）を用いて現実世界を表すデータモデル。概念データモデルの代表的な手法です。
ER図: ERモデルを図として描いたダイアグラム。エンティティ、属性、関係の配置とカーディナリティを視覚的に示します。
エンティティ: 現実世界の物事や概念を表すもの。例: 顧客、商品、受注など。
属性: エンティティが持つ特徴や情報。例: 顧客の名前、商品価格。
複合属性: 複数の値をひとつの属性で表す属性。例: 住所を都道府県・市区町村・番地の複合属性として表す。
多値属性: 1つのエンティティに対して複数の値をとる属性。例: 電話番号を複数持てる。
派生属性: 他の属性から導かれて値が決まる属性。例: 年齢は誕生日から計算される。
主キー: 各エンティティを一意に識別する属性・属性の組み合わせ。
候補キー: 主キーとして使える候補となる一意性を持つ属性や属性の組。
自然キー: 現実世界の実務で自然に識別できるキー。例: 社員番号。
リレーションシップ: エンティティ間の意味のある関係性。1対1、1対N、N対N などのカーディナリティを表現します。
カーディナリティ: エンティティ間の関係の数的制約。例: 1対1、1対N、N対N。
弱エンティティ: 自ら識別子を持たず、識別には関連する強いエンティティの関係が必要なエンティティ。
強いエンティティ: 独立して識別子を持つエンティティ。
識別関係: 弱エンティティを識別するために、強いエンティティと結びつく関係。
非識別関係: 識別子の連結が不要な通常の関係。
EERモデル: 拡張ERモデル。一般化・特殊化、総称化などの概念を追加して表現力を高めたERモデル。
一般化/特化: 共通点を抽象化して上位クラス/下位クラスを表現する概念。
データディクショナリ/データ辞書: データ要素の定義・意味・型・制約などを体系的に集約した辞書。
ビジネスルール: 現実世界の要件や制約をデータモデルに反映するルール。
ドメイン: 属性値が取り得る値の集合（値域）。属性のデータ型・制約の基礎となる。
論理データモデル: 概念データモデルを仕様どおりに整理し、DBMSの論理構造へ対応させた設計段階。
物理データモデル: 論理データモデルを実際のDBMSに実装するための、テーブル・列・インデックスなどの具体的設計。
正規化: データの冗長性を減らす設計技法。論理デザインで重要だが、概念デザインの段階では概念が中心です。