データ活用やシステム連携が当たり前になり、設計段階でデータの持ち方を問われる場面が増えています。画面や帳票の項目を並べただけでは、主キーや関係が定まらず、実装後に改修が連鎖しやすい状態です。レビューでも指摘が散らばり、設計意図が共有されないまま進むと、運用でデータ品質が崩れがちでしょう。
本記事では、要件からエンティティ・リレーション・属性・キーを決め、概念→論理→物理へ落とす手順をテンプレ付きで整理します。IE表記とIDEF1X表記の読み書き、ありがちな失敗の直し方まで押さえ、説明できるデータモデルを作れる状態へ導きます。
目次
データモデルの書き方を学ぶ意義
データモデルの書き方を押さえると、要件定義から設計、実装、運用までの判断がぶれにくくなります。データモデルはシステムが扱う情報を整理し、変更や拡張に強い設計へ導く土台です。
まずは、データモデルの書き方について学ぶ意義を、改めて確認していきましょう。
業務とデータの構造を正しく整理するため
業務は人や部署によって言い方が変わり、同じ言葉でも指す内容がずれる場合があります。データモデルで業務上の実体や出来事を整理すると、扱うべき情報の範囲と粒度が明確になり、要件の抜け漏れが見つけやすくなります。
業務の流れを「顧客」「注文」「請求」のような実体と関係として表せるため、画面や帳票の項目を増やす前に、情報の整合性を確認しやすい点も強みです。結果として、後工程での仕様調整が少なくなり、開発のスピードと品質が両立しやすくなります。
設計ミスや手戻りを防ぐため
データモデルが曖昧なまま実装へ進むと、テーブル追加やキー変更が頻発し、修正が連鎖しやすくなります。主キーや外部キー、リレーションの任意性を早い段階で固めると、データの重複や更新不整合といった事故を未然に防ぎやすいです。
また、多対多の扱い、履歴の持ち方、制約の置き方は後から直すほど影響範囲が広がります。設計段階で論点を可視化し、レビューで潰しておくことが、手戻りのコストを最小化する近道です。
関係者間の共通認識を形成するため
データモデルは、業務担当者とエンジニアが同じ対象を同じ意味で話すための共通言語になります。要件が文章だけだと解釈が分かれやすい一方、エンティティと関係で示すと、どのデータを誰がどの目的で使うかが共有しやすいです。
レビュー時も「どの項目が正なのか」「どのタイミングで更新されるのか」を図と定義で確認できます。合意形成が早まるほど、後工程の仕様変更が減り、運用開始後の問い合わせやトラブルも抑えやすくなります。
データモデルを書く前にそろえるインプット
データモデルは、頭の中の理解だけで描くと抜け漏れが起きやすい成果物です。データモデル作成の前に情報源をそろえると、判断の根拠が明確になり、レビューでも説明しやすくなります。
業務フロー・ユースケース・画面項目
業務フローとユースケースは、業務の出来事と登場人物を整理し、データの発生タイミングを確定させる材料です。業務の出来事を起点にすると、エンティティの粒度がそろいやすく、リレーションの理由も業務ルールとして説明できます。
画面項目は、入力・更新・参照の責任を整理し、属性の必須性や制約を具体化する助けになります。画面項目を要件の答えとして扱うと項目が増えやすいため、業務フローとユースケースでスコープを先に固める姿勢が重要です。
帳票・CSV・外部連携データ
帳票やCSVは、現場が実際に扱うデータの単位と表記を示すため、属性設計の現実解をつかむ材料です。帳票とCSVの項目を確認すると、コード体系、桁数、必須項目、重複しやすい項目が早い段階で見えてきます。
外部連携データは、システム間で共有するキーやデータ定義の整合性に直結します。外部連携のインターフェース仕様を確認し、更新頻度と遅延の許容範囲まで押さえると、実装後の手戻りを減らせるでしょう。
既存DB・ログ・運用ルール
既存DBがある開発では、既存DBの構造が現行業務の前提になっている場合が多く、移行や互換性の判断に欠かせません。既存DBを読み解く際は、テーブル名だけで意味を決めず、運用ルールと突き合わせて解釈する必要があります。
ログは、業務イベントの発生順や状態遷移を示すため、履歴の持ち方や監査要件の検討に役立ちます。運用ルールは、更新責任、承認フロー、保持期間、例外処理を明確にし、物理モデルの制約設計にも影響する要素です。
データモデルの書き方
データモデルは、要件を図と定義に落とし込み、実装と運用へつなげるための設計手順です。作成手順を固定すると判断がぶれにくくなり、レビューでも論点を整理しやすくなります。
STEP1．業務の前提と用語をそろえる
業務の前提が揃わない状態では、同じ言葉でも人によって意味が変わり、モデルの土台が崩れやすいです。対象業務、対象期間、対象データの範囲を決め、用語集で定義を固定すると議論が進みます。
粒度の合意も欠かせません。たとえば「注文」を1件単位にするのか、明細行単位にするのかで、後続のエンティティ設計とキー設計が大きく変わります。
STEP2．エンティティを洗い出す
エンティティは、業務で扱う実体や出来事を名詞で切り出し、情報の箱として定義する考え方です。要件文、画面、帳票から名詞を拾い、リソース（人・物・場所）とイベント（取引・手続き）に分けると抜けが減ります。
マスタとトランザクションの切り分けも有効でしょう。マスタは参照の基準になりやすく、トランザクションは発生のたびに増える記録になりやすいため、更新頻度と責任範囲の設計へつながります。
STEP3．リレーションを定義する
リレーションは、エンティティ間の関係を線で結ぶ作業ではなく、業務ルールを構造として表す作業です。「顧客が注文を行う」のように、関係が成立する理由と成立するタイミングを言語化すると関係の誤解が減ります。
任意性と多重度を決める場面では、例外処理が設計の分かれ目です。注文が必ず顧客に紐づくのか、ゲスト購入を許すのかを決めると、NULL許容や参照整合性の方針が定まりやすくなります。
STEP4．属性を洗い出す
属性は、業務判断に必要な項目だけを定義し、入力と更新の責任を説明できる状態にすることが重要です。必須と任意を分け、値の範囲、桁数、形式、コード体系などの制約も合わせて決めます。
履歴の扱いを後回しにすると、運用開始後に分析や監査で困る場合があります。住所変更や価格改定のように変化する項目は、最新値だけで良いのか、時点管理が必要なのかを先に判断したいところです。
STEP5．キーと制約を決める
キー設計は、レコードを一意に識別し、関係を破綻させないための最重要論点です。主キーを自然キーで持つのか代理キーで持つのかを決め、重複を防ぐ一意制約もセットで設計します。
外部キーは参照関係を保証する仕組みなので、運用上の例外まで含めて定義が必要です。参照先が消える可能性、論理削除の方針、必須関係の扱いまで揃うと、後工程の手戻りが減ります。
STEP6．概念→論理→物理に落とし込む
概念モデルは業務の全体像を示し、論理モデルはデータの意味と関係を具体化し、物理モデルは実装可能な定義へ落とす段階です。段階を分けると、関係者の理解と実装制約の両方を満たしやすくなります。
成果物はER図だけでは不十分で、エンティティ定義書と制約の根拠が揃って初めて設計として機能します。図と定義の整合を取り、レビュー観点で抜け漏れを潰してから実装へ渡す流れが堅実です。
データモデルの表記法と読み書きの基本
データモデルは、同じ内容でも記法によって見え方が変わり、読み手の理解度にも差が出ます。まずは記法の違いを押さえ、最低限の読み書きができる状態を目指すと安心です。
IE表記の見方と書き方
IE表記は、エンティティ間の関係を線とカーディナリティで直感的に読みやすく、初学者にも扱いやすい記法です。エンティティは箱で表し、属性は箱の中に並べ、主キーは識別できる形で示します。
リレーションは「1対多」などの多重度と、必須か任意かを合わせて表す点が重要です。IE表記の作図では、業務上の文で関係を説明し、その説明を多重度と任意性へ落とす順番がわかりやすいです。
IDEF1X表記の見方と書き方
IDEF1X表記は、識別関係と非識別関係の違いを明確に表せるため、キー設計を意識したい場面で強みが出ます。子エンティティの主キーに親の主キーが含まれる場合は識別関係になりやすく、設計上の依存度が読み取れます。
IDEF1X表記を扱う際は、関係線の意味を先に理解し、主キーと外部キーの役割を崩さないことが重要です。設計レビューでは、依存関係が本当に業務要件として必要かを確認し、過度な結合を避ける視点が欠かせません。
記法を選ぶ判断軸
記法選びは好みではなく、共有相手と運用方法に合わせて決めると失敗しにくいです。業務担当者も含めて理解をそろえたい場合はIE表記が相性が良く、キーや依存関係を厳密に扱いたい場合はIDEF1X表記が向く傾向があります。
ツールとの相性も判断材料になります。共同編集、版管理、DDL出力、リバースエンジニアリングの要否を整理し、チームが継続して更新できる形を優先するのが現実的です。
エンティティの書き方
エンティティ設計は、データモデルの良し悪しを大きく左右する工程です。エンティティの切り方が整理できると、属性やリレーションの迷いも減ります。
業務上の実体を名詞で定義
エンティティは、業務で管理したい対象を名詞で表し、データとして保存する単位を決める考え方です。業務文書や画面項目から名詞を拾い、「顧客」「商品」「注文」のように実体として存在するものから候補を作ります。
候補を出す段階では、リソース（人・物・場所）とイベント（取引・処理）を分けると漏れが減ります。「注文」「請求」のようなイベント系エンティティは、発生タイミングと状態変化を伴う点も意識したいところです。
粒度を揃えて整理
エンティティの粒度が揃わないと、属性が膨らみすぎたり、関係が不自然になったりします。たとえば「注文」と「注文明細」を同じ粒度で扱うと、数量や単価の扱いが曖昧になり、キー設計も迷いやすいです。
粒度を揃えるには、1レコードが表す意味を文で言える状態にするのが有効でしょう。「注文は1回の購買行為」「注文明細は1注文内の1商品行」のように定義すると、分割すべき単位が見えてきます。
曖昧な概念の分割と統合
業務では「案件」「取引」「顧客情報」のように、範囲が広い言葉が頻繁に出ます。曖昧な言葉を1つのエンティティに押し込むと、役割が混ざり、更新責任や履歴設計が破綻しやすくなります。
分割は、用途が違う情報を別エンティティに分ける判断です。統合は、同義の概念を別名で管理している重複を解消し、キーと定義をそろえる判断になります。
リレーションシップの書き方
リレーションシップ設計は、業務ルールをデータの構造として固定する工程です。関係の定義が曖昧だと、キー設計や制約設計まで連鎖して崩れます。
1対多や多対多の関係を明確化
リレーションシップは、エンティティ間の関係を「1対1」「1対多」「多対多」で整理し、データの増え方を説明できる状態にします。たとえば「顧客は複数の注文を持つ」「注文は1人の顧客に属する」と定義できれば、基本の1対多が確定します。
多対多は曖昧さが残りやすい関係です。「注文と商品」などの組み合わせは多対多になりやすく、数量や単価のような関係の属性も発生するため、扱いを早めに決めたいところです。
業務ルールに基づく関連付け
リレーションシップは図の見栄えではなく、業務ルールに根拠があるかで判断します。関係が成立する条件、成立するタイミング、例外ケースを業務文で説明し、その説明を任意性と多重度へ落とし込みます。
たとえば「注文は必ず請求を持つ」と決めるのか、「請求は後処理で作られない場合がある」と扱うのかで、NULL許容や参照整合性の方針が変わります。関係の必須性を先に決めると、実装と運用の齟齬が減るでしょう。
中間エンティティの活用
多対多の関係は、中間エンティティを置いて2つの1対多へ分解すると扱いやすくなります。中間エンティティは「注文明細」「契約プラン適用」のように、関係そのものを業務上の実体として表す設計です。
中間エンティティを採用する判断は、関係に属性が付くかどうかが目安になります。数量、金額、適用開始日などの情報が必要なら、中間エンティティに持たせるほうが整合性が取りやすいです。
アトリビュートの書き方
アトリビュート設計は、エンティティの中身を業務で使える形に整える工程です。項目を増やすだけでは品質が上がらないため、必要性と制約をセットで決めます。
業務で必要な項目のみ定義
アトリビュートは、業務判断や処理に必要な項目に絞り、目的が説明できる状態で定義します。画面や帳票の項目をそのまま採用すると肥大化しやすいため、入力される理由と利用される場面を確認してから採用します。
必須項目と任意項目を分け、値の形式、桁数、選択肢、デフォルトの扱いまで決めると運用で迷いません。入力ルールまで含めて定義しておくと、後からデータ品質が崩れるリスクも下がります。
IDと識別子の明確化
IDは、レコードを一意に識別し、他エンティティから参照される基準になる項目です。業務上の識別子（会員番号、注文番号など）と、システム内部の識別子（連番IDなど）を混同すると、連携や移行でトラブルになりやすいです。
設計では「業務で使う番号」と「主キーとして使うID」を分けて考え、必要なら両方を保持します。外部連携で使う識別子は一意制約の対象になりやすいため、採番ルールと重複時の扱いも合わせて決めたいところです。
粒度と重複の整理
アトリビュートの粒度が揃わないと、検索や集計で扱いにくくなり、入力もぶれやすくなります。たとえば住所を1項目で持つのか、都道府県・市区町村・番地に分けるのかは、利用目的と更新頻度で判断します。
重複は、同じ意味の項目が別名で存在する状態や、同じ値が複数箇所に保存される状態です。重複を放置すると更新不整合が起きやすいため、正の値を持つ場所を決め、参照で済む項目は参照に寄せる設計が堅実です。
モデル表記の基本ルール
データモデルは、内容だけでなく表記の揺れが理解の妨げになります。命名と表現のルールを先に決めると、関係者が読みやすく、運用で更新しやすい成果物になります。
業務用語を優先した命名
命名は、業務担当者が読んでも意味が通る言葉を優先し、業務の定義と一致させる姿勢が重要です。エンティティ名と属性名は業務用語をベースにし、略語や英語は定義書で意味を補足すると誤解が減ります。
たとえば「顧客」と「取引先」を混在させると、参照先がわからなくなり、モデルの議論が止まりやすいです。業務で使う呼称を1つに揃え、別呼称が必要なら別エンティティとして定義する判断が堅実です。
命名規則の統一
命名規則は、同じ種類の情報が同じ形で表れるようにするためのルールです。単数形と複数形、区切り文字、英語表記のスタイル、IDやコードの付け方を統一すると、検索性と保守性が上がります。
命名規則を決める際は、データモデルだけで完結させず、テーブル定義やAPI項目との整合も意識します。命名の揺れは後から直すほど影響が広がるため、早い段階で合意を取るべき論点です。
図表の表現方法の統一
図表の表現が揺れると、読み手が意味を推測する負担が増えます。記法はIE表記かIDEF1X表記のどちらかを基本にし、カーディナリティ、任意性、主キーの表現を統一しましょう。
図の配置ルールも決めておくと、モデルが大きくなっても読みやすさが保てます。たとえば上位概念を左上に寄せる、サブシステムごとに分割する、凡例を付けるといったルールが有効です。
概念モデル・論理モデル・物理モデルの書き分け
データモデルは、目的と読み手に合わせて概念・論理・物理の3段階に分けると整理しやすいです。段階を分けると、業務理解と実装制約を混ぜずに設計を進められます。
概念モデルでの抽象化
概念モデルは、業務の全体像を共有するためのモデルで、業務上の実体と関係を大づかみに表します。概念モデルでは詳細な属性やデータ型を入れず、業務担当者が理解できる言葉でエンティティと関係を整理します。
概念モデルで重要なのは、対象範囲と粒度がぶれないことです。業務境界が曖昧なまま進むと、後工程の論理モデルで論点が増え、設計の手戻りが起きやすくなります。
論理モデルでの詳細化
論理モデルは、業務上の意味を保ったまま、データとして矛盾なく管理できる形へ落とすモデルです。論理モデルでは属性を追加し、主キーと外部キー、任意性、制約を定義し、データの整合性を担保します。
論理モデルの段階では、正規化や重複排除も検討対象です。業務ルールを反映しつつ、更新不整合を防げる構造に整えることが論理モデルの役割でしょう。
物理モデルでの実装定義
物理モデルは、特定のデータベースで実装できる形に落とすモデルで、テーブル定義としての具体性が必要です。物理モデルではデータ型、桁数、NULL可否、インデックス、パーティションなど、性能と運用を考慮した定義を追加します。
物理モデルは実装制約が入るため、論理モデルの意味を壊さない配慮が欠かせません。採番方式や外部連携のキー、削除方針、履歴の保持期間まで含めて定義できると、運用開始後のトラブルが減ります。
データモデルの成果物テンプレ
データモデルはER図だけだと解釈がぶれやすく、実装や運用に渡す際の説明も重くなりがちです。エンティティ定義書とテーブル定義書、レビュー観点をセットにすると、設計の根拠が残り、変更にも強くなります。
ここでは、設計の根拠を残し変更に強くするための3つの成果物——エンティティ定義書、テーブル定義書、レビュー用チェックリスト——のテンプレを整理します。
エンティティ定義書のテンプレ
エンティティ定義書は、エンティティの意味と利用目的を言葉で固定し、関係者の認識を揃えるための成果物です。ER図の箱に何を入れるかだけでなく、更新責任や例外ルールまで説明できる形が望ましいでしょう。
記載項目の例を挙げます。
- エンティティ名は業務用語で統一し、別名がある場合は同義語も併記する
- 概要は業務上の役割と、管理対象の範囲を1〜2文で定義する
- 主キーは識別の根拠と採番ルールを明記し、業務IDとの関係も示す
- 属性一覧は論理名、型の想定、必須任意、制約、説明を揃えて記載する
- 関連は親子関係と任意性を言語化し、成立条件を業務ルールとして残す
記入例として「顧客」エンティティを扱う場合、「顧客は取引の主体として識別し、契約や請求の参照先になる対象」と定義します。主キーが代理キーなら「customer_idはシステム採番で一意」と書き、会員番号がある場合は一意制約の対象として併記する形です。
テーブル定義書のテンプレ
テーブル定義書は、物理モデルを実装へ落とすための成果物で、型や制約まで含めて再現性を担保します。DDLを生成できる環境でも、設計意図と運用前提を残すために定義書が欠かせません。
記載項目の例を挙げます。
- テーブル名は命名規則に従い、論理名と対応付けて記載する
- カラムは論理名、物理名、データ型、桁数、NULL可否をセットで書く
- 主キーと外部キーは参照先、更新削除時の扱い、制約名まで明確にする
- 一意制約とチェック制約は業務ルールとの対応関係を備考で補足する
- インデックスは想定クエリと更新負荷を踏まえ、理由付きで記載する
記入例として「orders」テーブルを扱う場合、「order_idはBIGINTでNOT NULL、主キー」と決めます。外部キーとして「customer_id」を置くなら、参照整合性と論理削除方針の整合が取れる制約設計が必要です。
レビュー用チェックリスト
レビュー用チェックリストは、設計の品質を属人化させず、指摘の観点を揃えるための道具です。抜け漏れ、整合性、拡張性の3軸で確認すると、レビューが短時間でも深くなります。
チェック観点の例を挙げます。
- エンティティの粒度が揃い、1レコードの意味が文で説明できるか
- 多対多の関係に中間エンティティがあり、関係の属性が置き場を失っていないか
- 主キーと一意制約が適切で、重複データが入りにくい設計になっているか
- 任意性とNULL可否の整合が取れ、業務の例外処理が破綻しないか
- 履歴が必要な項目が定義され、時点参照や監査の要件に耐えられるか
データモデル作成ツールの選び方
データモデル作成ツールは、作図のしやすさよりも「設計を育て続けられるか」で選ぶのが基本です。データモデルは要件変更や運用改善で更新が発生するため、共有と版管理のしやすさが欠かせません。結果として、ER図と定義書を同じ前提で保てるツールほど、現場で役立ちます。
選定では、チームの作業形態と成果物の出し方に合うかを確認します。判断軸をまとめると整理が楽です。
- 共同編集とレビューができ、差分や承認の履歴を追える設計か
- IE表記やIDEF1X表記を統一しやすく、表記揺れを抑えられるか
- DDL出力やリバースエンジニアリングの要否に合い、二重管理が起きにくいか
- 権限管理と監査ログの有無が、扱うデータの機密性に見合うか
導入初期は軽量なツールで素早く共有し、運用が回り始めた段階で機能を拡張する考え方も現実的です。ツールの機能に設計判断が引きずられないよう、命名規則と成果物テンプレを先に決めておくと迷いが減ります。
データモデルの作成でよくある失敗と改善策
データモデルは、書き方の手順を知っていても、考え方のズレで失敗しやすい成果物です。代表的な失敗パターンを先に押さえると、レビューでの手戻りや運用後の混乱を減らせます。
ここでは、よくある3つの失敗パターン——粒度の不統一、業務理解不足による誤設計、ツール依存による本質の見失い——と、それぞれの改善策を整理します。
粒度の不統一
粒度の不統一は、エンティティが表す単位が混ざり、設計全体の整合が崩れる状態です。「注文」と「注文明細」を同列に扱ったり、「顧客」と「顧客担当者」の境界が曖昧だったりすると、属性の置き場が迷子になります。
改善策は、各エンティティの1レコードが表す意味を文章で定義し、イベントとリソース、マスタとトランザクションを分けて整理することです。粒度が揃うとリレーションの多重度も自然になり、キー設計の迷いも減るでしょう。
業務理解不足による誤設計
業務理解が浅いままモデルを作ると、現場の例外や運用ルールが抜け落ち、実装後に破綻しやすくなります。たとえば「請求は必ず発行される」「注文は必ず顧客に紐づく」と決め打ちすると、返品や取消、ゲスト購入などで整合性が取れなくなる場合があります。
改善策は、業務フローとユースケースを先に固め、関係が成立する条件と例外を業務ルールとして定義書に残すことです。画面項目や帳票も合わせて確認し、入力責任と更新タイミングまで揃えると誤設計が減ります。
ツール依存による本質の見失い
ツール依存の失敗は、作図のしやすさや自動生成の結果が優先され、業務の意味や設計意図が置き去りになる状態です。DDL生成やリバースエンジニアリングは便利ですが、命名規則が崩れたり、不要なテーブルが増えたりすると、読めないモデルになりやすくなります
改善策は、先に命名規則と成果物テンプレを決め、図と定義書で設計意図を固定することです。ツールは表現手段に過ぎないため、業務用語の定義、粒度、キーと制約の根拠が説明できる状態を優先するべきでしょう。
まとめ：データモデルを迷わず書くためにまずやること
データモデルの書き方は、図をきれいに描く技術ではなく、業務の意味を構造として固定する設計力です。業務の前提と用語が揃い、エンティティ・リレーション・属性・キーが根拠付きで説明できれば、実装や運用で破綻しにくいモデルになります。
最初にやるべきことは、業務フローとユースケース、画面項目、帳票などのインプットを集め、対象範囲と粒度を決めることです。次に、名詞からエンティティ候補を出し、関係の理由を業務ルールで言語化し、例外ケースまで含めて任意性を確定すると進めやすくなるでしょう。
作成したER図は、定義書とセットで残すと迷いが減ります。エンティティ定義書に「何を管理し、誰が更新し、どのタイミングで変わるか」を書き、テーブル定義書に制約と根拠を残せば、レビューも運用も回りやすくなります。
今日から始めるなら、まず1つの業務領域を選び、概念モデルを作って関係者と合意を取ってください。合意が取れた範囲だけ論理モデルへ落とし、チェックリストで抜け漏れを潰してから物理モデルへ進む流れが堅実です。
「これからデータモデルを作成したいけれど、何から実施していいかわからない」「データ専門家の知見を取り入れたい」という方は、データ領域の実績豊富な弊社、データビズラボにお気軽にご相談ください。
貴社の課題や状況に合わせて、データモデルの取り組みをご提案させていただきます。
