Tsuzura

ER図とデータモデルの作り方

業務上の情報をエンティティ、属性、識別子、関係、個数、制約に分け、画面項目や物理設計と混同せず論理データモデルとER図へまとめる手順です。

公開日
更新日

ER図は、システムが扱う業務上の情報について、「何を1件として区別するか」「その1件がどんな情報を持つか」「それらがどう結び付くか」を記録する図です。本記事では、画面の見た目や操作順は扱いません。

ここでは、保持する情報の意味、構造、関係、守る条件をまとめたものをデータモデルとして扱います。特定のデータベース製品へ依存しない論理データモデルを、ER図と作図票へまとめます。読み終えると、一つの利用場面について、エンティティ、属性、識別子、関係、個数、制約、未決事項を記録できます。

入力として、一機能分の要件と受入条件と、業務で使う用語を確認できる資料が必要です。保持期間、機密性、性能などの条件は非機能要件の決め方で先に確認します。この記事では、作図ツールの操作、SQL、データ型、インデックス、特定のデータベース製品を使った物理設計、完成済みの作図例は扱いません。

作業は、対象範囲、エンティティと属性、識別子、関係と個数、制約、正規化の順で進めます。最後に作図票から図へ移し、未決事項と物理設計への引き渡しを確認します。

ER図とデータモデルが必要な理由

画面には、入力欄、表示項目、検索条件、操作中だけ使う値が並びます。そこに見える項目だけでは、システムが継続して保持する事実、同じ1件とみなす条件、別の1件との関係までは決まりません。複数の画面やAPIが同じ事実を扱う場合もあります。そのため、画面の項目をそのままデータ構造とみなさず、保持する事実、関係、制約を別に確認します。

ERモデルは、現実の意味情報をエンティティとリレーションシップで表し、データベース設計に使う図式として提案されました。Peter Chenの原著論文では、アクセス方法に依存しない情報構造と、アクセス方法に依存する構造も分けています。

画面を作る前に論理データモデルを決める目的は、次の判断を画面やデータベース製品から切り離して確認することです。

  • 業務上、何の1件を区別して保持するか
  • 各情報は何に属するか
  • 同じ1件と別の1件を何で区別するか
  • 1件どうしが何件まで結び付くか
  • どの時点で情報や関係が必須になるか
  • 重複や不正な値を何の条件で防ぐか
  • まだ確認できていない判断は何か

ER図だけで設計が終わるわけではありません。図に表しにくい根拠、未決事項、状態によって変わる条件、実装への引き渡しは作図票にも残します。

完成状態を先に決める

この工程は、図を書き終えただけでは完了しません。論理ER図と作図票の内容が一致し、未決事項と物理設計で決める項目が分かれ、業務上の事実を確認できる状態を完了とします。詳しい条件は「次へ進める状態」にまとめています。

確認者にデータベースの経験は必要ありません。対象業務の事実と用語を判断できる人へ確認します。自分だけが業務を把握している場合は、自己確認した範囲と第三者が未確認の範囲を分けます。未確認の判断に依存する実装は、確認先と期限が決まるまで進めません。

論理モデルと物理設計を分ける

三つは、どれか一つを選ぶものではありません。業務上の意味を論理モデルで決めた後、リレーショナルモデルで表・列と表どうしの対応として表します。そこから、選んだデータベース製品の設定へ物理モデルで落とし込みます。Oracle SQL Developer Data Modelerの公式資料も、三つを分け、論理モデルを実装に依存しない情報の見方として説明しています。

別々の文書を必ず作るという意味ではありません。一つの作図票でも、今決める業務上の意味と、後で決める実装項目の欄を分けます。

論理モデルで決める 物理設計へ渡す
エンティティの意味と1件の単位 表（テーブル）名と列（カラム）名
属性の意味と所属先 データ型と長さ
論理上の識別子 主キー（Primary Key）の構成と生成方法
関係と最小・最大個数 外部キー（Foreign Key）の配置と動作
必須性、一意性、参照、値の条件 データベース製品で使う制約
意図的に残す重複と更新責任 索引（Index）、分割方法、保存形式
未決事項と確認先 変更・移行方法と性能確認

画面項目も別に扱います。表示のために組み合わせた値、入力途中の値、絞り込み条件を、確認なしに属性にはしません。反対に、画面に表示しない識別情報や関係も、業務上必要なら論理モデルへ記録します。

作図する範囲と情報源を決める

最初からシステム全体を一枚にまとめず、一つの利用場面に絞ります。範囲が広いと、場所によって意味が変わる言葉や、確認者が異なるルールまで一度に決めることになります。

一つの利用場面に絞る

作図を始める前に、次の8項目を書きます。

項目 記入する内容
利用場面 誰が何を完了する範囲か
利用者・役割 その範囲で情報を扱う人と役割
開始 どの事実が起きたところから扱うか
終了 どの結果を記録したところまで扱うか
業務上の例外 通常と異なる条件や扱いを確認する資料
情報源 要件、業務資料、既存データ定義、API仕様等の所在
確認者 用語と業務ルールを確認できる人
対象外 今回は決めない機能、情報、状態

開始と終了は画面の移動ではなく、扱う業務上の事実で区切ります。別の利用場面との境界では、受け取る情報と渡す情報だけを記録し、未確認の内部構造まで作りません。

確認済みと未決を分ける

情報源から、名詞をエンティティへ、項目名を属性へ機械的に変換することはできません。同じ言葉が別の意味で使われたり、異なる言葉が同じ対象を指したりするためです。候補ごとに、意味、情報源、確認者、確認状態を残します。

確認できない欄は空欄にせず、「未決」と書きます。あわせて、確認する相手、必要な資料、確認期限を記録します。AIが自然に補える内容でも、資料にない業務ルールは未決のままにします。

エンティティと属性を決める

エンティティは、業務上で個別に区別し、情報を保持する対象または概念です。Chenの原著論文は個別に識別できる対象として、Oracleの公式資料は情報を保持したい対象（Object）または概念（Concept）として説明しています。

エンティティ名を決める前に、「このエンティティの1件は何か」を一文で書きます。その一文が異なる意味を含む、確認者が一件を同じ条件で数えられない、利用場面によって意味が変わる場合は、名前ではなく定義を見直します。

エンティティ候補ごとに次を確認します。

  • その1件を別の1件と区別する必要があるか
  • その1件について継続して保持する情報があるか
  • 作成、変更、終了等の時点を確認する必要があるか
  • ほかのエンティティとの関係を記録する必要があるか
  • 意味と更新責任を確認できる人がいるか

画面、帳票、処理、ボタン、操作手順の名前を、そのままエンティティにしません。情報を保持する対象がない場合は、別の設計資料で扱う可能性があります。

情報が何に属するかを確認する

属性は、エンティティが共通して持つ特徴です。名称だけでなく、意味、単位、値の条件、いつ決まるか、変更できるかを記録します。

一つの情報が複数のエンティティの組み合わせに対して意味を持つ場合は、どちらか片方へ置く前に、リレーションシップに属する属性かを確認します。Chenの原著論文は、エンティティだけでなくリレーションシップ自体も属性を持ち得ると説明しています。

属性候補には次の判断を付けます。

判断 確認すること
所属先 どのエンティティまたは関係についての情報か
意味 何を表し、似た用語とどう違うか
取得元 人が入力するか、外部から受け取るか、ほかの値から求めるか
保持 正本として保存するか、必要なときに求めるか
時点 いつ値が決まり、いつ変更できるか
条件 必須性、一意性、許される値、単位、形式
根拠 どの資料と誰の確認に基づくか

画面上で近くに並んでいるという理由だけで、同じエンティティへ置きません。情報の意味が何に依存するかで所属先を決めます。

識別子候補を決める

識別子は、エンティティの各1件を一意に区別するための属性、または属性の組です。Oracleの論理モデルでは、一意識別子（Unique Identifier）を一つ以上の属性から構成できます。詳しくはOracleの一意識別子の説明で確認できます。

各エンティティについて、次を確認します。

  1. 何が一致したら同じ1件とみなすか
  2. その値または組は、対象範囲で本当に重複しないか
  3. 値は後から変わるか
  4. 外部から受け取る値なら、発行元と適用範囲はどこか
  5. 候補がない、または確定できない場合、誰が何を確認するか

論理上の識別子と、データベースで使うPrimary Keyは同じ段階で固定しません。物理設計では代理のIDや生成方法を選ぶ場合がありますが、自動採番のIDを追加するだけでは、業務上の同じ1件と重複の条件は決まりません。

複数の候補がある場合は、主に使う候補だけでなく、ほかの一意条件も記録します。確認できない場合は「識別子なし」と確定せず、「識別条件が未決」として止めます。

関係と個数を決める

リレーションシップは、二つ以上のエンティティの間にある業務上の結び付きです。カーディナリティは、関係する相手側の件数を示します。Oracleの関係の説明は、1対1、1対多、多対多を区別しています。

関係は必ず両方向に読みます。次の空欄を、業務上の文章として埋めます。

  • [エンティティA]の1件は、[エンティティB]の最小[0または1]件、最大[1または多]件と関係する
  • [エンティティB]の1件は、[エンティティA]の最小[0または1]件、最大[1または多]件と関係する

最大個数だけでは不十分です。Oracleの論理モデルでは、関係の両端で0件でもよい任意（Optional）と、1件以上を必要とする必須（Mandatory）を区別できます。Oracleの任意・必須の説明

記録 意味
最小0 相手が存在しない状態を許す
最小1 少なくとも1件の相手が必要
最大1 相手は1件まで
最大多 相手は複数件になり得る

作成途中と確定後で最小個数が変わる場合は、どの状態でどの条件になるかを作図票へ書きます。図へ一つの記号で表せない条件は、文章と制約票へ残します。

多対多を実装前に確認する

論理モデルで多対多になる関係は、それ自体を誤りとして消しません。まず、業務上本当に両方向で複数件になり得るかを確認します。次に、関係そのものが持つ属性、関係を一意に区別する条件、関係の開始・終了を保持する必要があるかを確認します。

リレーショナルモデルへ渡すときは、中間のエンティティとして扱うか、どの識別子と外部キーで実装するかを決めます。本記事では、その物理的な変換方法までは扱いません。

必須項目と制約を決める

画面の入力必須と、業務上の必須と、データベース保存時のNOT NULLは分けて考えます。入力途中は値がなくても保存でき、確定時には必要になる場合があります。外部から後で受け取る情報もあります。必須性には、対象、条件、適用する時点を付けます。

属性と関係について、次の制約候補を確認します。

制約の種類 論理モデルで確認すること 実装へ渡すこと
識別 何で1件を区別するか 主キー等の候補
一意 重複してはいけない値または組は何か UNIQUE等の候補
必須 どの時点で値や関係が必要か NOT NULL、状態確認等の候補
参照 関係する相手が存在する必要があるか 外部キー等の候補
値 許す範囲、組み合わせ、形式は何か CHECK、アプリケーションでの確認等の候補
状態依存 どの状態で条件が変わるか アプリケーション処理とテストの候補

PostgreSQL 18の公式資料では、CHECKは値の条件、NOT NULLはNULLの禁止、UNIQUEは重複の制限、PRIMARY KEYは行の一意かつ非NULLの識別、FOREIGN KEYは表（テーブル）間の参照整合性を扱います。

これはPostgreSQL 18での役割です。NULLとUNIQUEの組み合わせ、参照先の更新・削除、制約で表せる条件はデータベース製品によって確認が必要です。論理ER図に制約候補を書いただけで実装済みとは扱わず、実際のデータベース定義（DDL）、アプリケーション、テストのどこで守るかを物理設計へ渡します。

最小限の正規化を確認する

正規化は、同じ事実の重複と不整合な依存を減らすように、表（テーブル）と関係を見直す考え方です。表（テーブル）の数を増やすこと自体が目的ではありません。

初めて論理モデルを作る段階では、次の3点を確認します。

  1. 同じ種類の値を複数の欄へ繰り返していないか
  2. 同じ事実を複数の1件へコピーし、別々に更新する構造になっていないか
  3. 非識別属性が、識別子ではなく別の非識別属性だけで決まっていないか。業務資料と確認者から判断できなければ未決にする

該当する場合は、別のエンティティや関係へ分ける候補にします。

Microsoftの正規化に関する入門資料は、重複と不整合な依存を見直し、繰り返し項目、複数の行へ重複する値、識別子に依存しない項目を分ける基本を説明しています。同じ資料は、完全な正規化が常に実用的とは限らないことにも触れています。

本記事では、特定の正規形をすべての案件の合格条件にしません。意図的に重複を残す場合は、次を記録します。

  • どの情報を正本とするか
  • 誰またはどの処理が更新するか
  • 同時に更新できなかった場合にどう検出するか
  • どのテストで不整合を確認するか
  • どの条件になったら設計を見直すか

理由と更新方法を説明できない重複は、未決事項として残します。

ER作図票にまとめる

次の記入用ひな形を複製し、一つの利用場面について記入します。Markdownの表として使える形式ですが、同じ項目を保持できれば作図ツールや文書形式は問いません。

# ER作図票

## 1. 対象範囲

- 利用場面：
- 利用者・役割：
- 開始となる業務上の事実：
- 終了となる業務上の事実：
- 業務上の例外：
- 情報源：
- 業務ルールの確認者：
- 対象外：

## 2. エンティティ

| 名称 | 何の1件か | 保持する理由 | 情報源 | 確認者 | 状態 |
|---|---|---|---|---|---|
|  |  |  |  |  | 確認済み／未決 |

## 3. 属性

| 名称 | 属するエンティティまたは関係 | 意味 | 取得元 | 保存または導出 | 必須になる時点 | 値の条件 | 根拠 |
|---|---|---|---|---|---|---|---|
|  |  |  |  |  |  |  |  |

## 4. 識別子

| エンティティ | 候補となる属性の組 | 同じ1件とみなす条件 | 変更可能性 | 根拠 | 未決 |
|---|---|---|---|---|---|
|  |  |  |  |  |  |

## 5. リレーションシップ

| 関係名 | A | Aの1件に対するBの最小・最大 | B | Bの1件に対するAの最小・最大 | 成立する時点 | 関係の属性 | 根拠 |
|---|---|---|---|---|---|---|---|
|  |  | 最小：／最大： |  | 最小：／最大： |  |  |  |

## 6. 制約

| 業務ルール | 対象 | 識別／一意／必須／参照／値／状態依存 | 適用時点 | 実装候補 | テスト観点 | 根拠または未決 |
|---|---|---|---|---|---|---|
|  |  |  |  |  |  |  |

## 7. 正規化の確認

- 繰り返し項目：
- 同じ事実の重複：
- 識別子以外への依存：
- 意図的に残す重複：
- 正本：
- 更新責任：
- 不整合の検出方法：
- 見直し条件：

## 8. 画面・入出力との分離

| 画面、API、CSV等の項目 | 正本として保持する事実か | 対応する属性または関係 | 一時値または導出値か | 未決 |
|---|---|---|---|---|
|  |  |  |  |  |

## 9. 未決事項

| 未決の判断 | 確認する相手 | 必要な資料 | 期限 | 未決の間に止める作業 |
|---|---|---|---|---|
|  |  |  |  |  |

## 10. 物理設計への引き渡し

- 論理モデルから引き渡す条件：
- 未決事項：
- 確認先：
- 後続工程で決める項目（該当する項目に印を付ける）：
  - [ ] 対象データベース製品
  - [ ] 表・列の名前
  - [ ] データ型と長さ
  - [ ] 主キーと生成方法
  - [ ] 外部キーと更新・削除時の動作
  - [ ] データベースで守る制約
  - [ ] 索引
  - [ ] 変更・移行方法
  - [ ] 性能確認
  - [ ] アプリケーションとテストで守るルール

## 11. 確認

- 業務ルール確認者：
- 確認日：
- 確認した範囲：
- 未承認の範囲：

作図票を埋めたら、次の順で図へ移します。

  1. エンティティごとに一つの枠を置く
  2. 各枠へ主な属性と識別子を書く
  3. 関係する枠どうしを線で結ぶ
  4. 線の両端へ最小0・1と最大1・多を書く
  5. 図の名称、識別子、個数を作図票と照合する

記号の形は作図ツールによって異なるため、本記事では固定しません。根拠、状態別の条件、長い説明、未決事項は作図票に残します。図と票で名称や個数が異なる場合は、どちらかを推測で合わせず、確認者へ戻します。

AIで候補を整理し、人が決める

AIは、確認済み資料から用語候補を抜き出し、表の形式をそろえ、同じ用語の表記揺れや空欄を指摘する作業に使えます。ER図の記法へ整形したり、関係を両方向の文章へ変換したりする作業も、候補作成として利用できます。

一方、次の項目は、資料上の根拠を確かめたうえで、対象業務を確認できる人が判断します。

  • 何を独立したエンティティとするか
  • 一件を同じものとみなす識別条件
  • 情報がどのエンティティまたは関係に属するか
  • 関係の最小・最大個数
  • 必須になる状態と時点
  • 許される値、一意性、参照のルール
  • 意図的な重複と更新責任
  • 未決のまま実装を止める範囲

AIへは作図票全体を一度に完成させるよう頼みません。対象範囲、エンティティ候補、一つの関係の順に、一回につき一つの判断に絞ります。各回で、根拠箇所があるか、1件の意味を説明できるか、関係を両方向に読めるか、未決を補っていないかを確認してから次へ進みます。

AIへ渡す資料は、利用を許可された範囲に限定します。資料にない内容を補わないよう指示し、各候補へ根拠箇所または「根拠なし」を付けさせます。AIの出力は承認済みの業務仕様ではありません。人の確認前はすべて候補として扱います。

AIに渡す資料に個人情報、顧客情報、社内の機密情報、基幹システムのデータが含まれる場合や、外部共有、認証連携、複数部署での利用を伴う場合は、事前確認が済むまで資料提供と実装を止めます。組織のルールに従い、業務責任者、IT部門、セキュリティや個人情報の担当者へ、利用可否と扱う範囲を確認します。

次へ進める状態

次の項目を満たしたら、論理データモデルを後続の設計へ渡します。

  • 対象範囲と対象外を一つの利用場面で説明できる
  • 各エンティティの1件の意味と確認者が記録されている
  • 各属性の所属先、意味、取得元、保存または導出が記録されている
  • 識別子候補、または識別条件の未決が記録されている
  • すべての関係を両方向に読み、最小0・1と最大1・多が記録されている
  • 必須性、一意性、参照、値の条件に適用時点と根拠がある
  • 正規化の3点を確認し、意図的な重複には更新と検出の方法がある
  • 画面項目と正本として保持する事実を分けている
  • 未決事項に確認者と、未決の間に止める作業がある
  • 論理上の判断と物理設計への引き渡しが分かれている
  • 業務を確認できる人が、確認した範囲を記録している

APIの入出力へ使う項目と制約を契約にする場合は、OpenAPIでAPI仕様を作るへ渡します。後続では、論理モデルをソフトウェア設計の基本原則と技術選定の進め方へ渡します。作図票の未決事項と実装候補はAI実装タスクの分け方で作業に分け、制約はソフトウェアテストの種類と選び方で確認範囲へ変えます。公開可否、権限、運用責任、引き継ぎ、廃止条件は論理ER図だけでは決まりません。Webサービスの最低限の運用設計を含む後続工程で判断します。

出典