ER図とは、データベースに保存するデータの構造を、エンティティ（実体）とその関係で表す設計図です。テーブルをいきなり作り始めるのではなく、まず「何を、どんな単位で、どうつなげて持つか」をER図で固めてから物理的なテーブルへ落とすと、後から効いてくるデータの整合性を設計段階で作り込めます。この記事では、エンティティ・属性・リレーションという基本要素から、1対1や多対多を表すカーディナリティの読み方、IE記法とIDEF1Xの書き分け、多対多を中間テーブルへ分解する正規化との関係、概念・論理・物理の3層でモデリングを進める設計プロセス、erDiagramやDBMLでコードとして管理してCREATE TABLEへ落とす手順、そして設計工程で書くべき場面と書きすぎになる失敗パターンまでを、公式ドキュメントの記述とコード例つきで整理します。
まとめ：ER図の構成要素・書き方とデータベース設計での役割
ER図の芯は、業務で扱うデータを「エンティティ」という箱に分け、箱と箱の関係（リレーション）を線で結んで、データの全体像を一枚で見渡せるようにすることにあります。エンティティは顧客や注文といったデータの実体、属性はその箱が持つ項目（顧客名やメールアドレスなど）、リレーションは注文が顧客に紐づくといった箱どうしのつながりを指します。この3つを押さえれば、ER図の骨格は読み解けるはずです。
関係の線には、1対1・1対多・多対多という数の関係（カーディナリティ）を添えます。ひとりの顧客が複数の注文を持つなら1対多、といった具合です。記法にはIE記法（鳥の足）とIDEF1Xがあり、どちらを使うかはツールとチームの慣れで選びます。多対多の関係はそのままテーブルにできないため、中間に別のエンティティを立てて1対多ふたつに分解します。この分解は、正規化という整理作業と地続きです。
作図の実務では、GUIツールで線を引くより、テキストから図を生成する方式のほうが変更に強くなりました。MermaidのerDiagramなら関係記号でカーディナリティを、属性ブロックでPK・FK・UKを書ける仕様です。dbdiagram.ioのDBMLならテーブルと参照関係を書いてSQLへ書き出せます。本記事では、この2つの記法と、そこからPostgreSQLのCREATE TABLEへ落とすところまでを、公式ドキュメントの記述に沿ったコードで示します。
ER図が効くのは、複数のテーブルが絡む業務システムのデータ構造を、実装前に関係者で合意する場面です。逆に、テーブルが数個しかない小さな仕組みまで律儀に描くと、更新されない紙の資料に終わります。どこまで描き、どこで手を止めるか、その線引きまで条件付きで言い切ります。DBの種類やRDBとNoSQLの選び方といった土台はデータベースとは何かで扱い、本記事はその中身をどう設計するかを描く役割です。
ER図とは何か：実体関連モデルの定義とデータベース設計での位置づけ
はじめに言葉の範囲をそろえます。ER図は、データを「実体（エンティティ）」と「関連（リレーションシップ）」で捉える考え方を図にしたもので、Entity Relationship Diagram の頭文字を取っています。プログラムの処理ではなく、保存するデータそのものの構造を対象にする点が特徴です。
ER図の定義と、データ構造を表す実体関連モデルとしての位置づけ
ER図は、1970年代にピーター・チェンが提唱した実体関連モデル（ERモデル）を作図したもので、現実の業務に登場する「モノ」や「コト」をエンティティとして抜き出し、その間の関係を線で結んで表します。狙いは、テーブルを作る前に「どんなデータを、どの粒度で、どうつなげて持つか」をデータの設計として固めることです。たとえばECサイトなら、顧客・商品・注文・注文明細といったエンティティを置き、顧客が注文を持ち、注文が複数の商品を明細として抱える、という構造を線で描きます。
用語の細かい話をひとつ補います。Mermaidの公式ドキュメントは、厳密にはエンティティ型（entity type）とその実例（instance）を区別すべきだが、実務家はほぼ例外なくエンティティ型を単に「エンティティ」と呼ぶため、それに従うと明記しています（Mermaid公式のER図構文ドキュメント）。同じ理由から、エンティティ名は単数形の名詞で付けるのが慣例です。CUSTOMERSではなくCUSTOMER、ORDERSではなくORDERと書きます。
処理の流れを時間順に描くクラス図やシーケンス図が「動き」を扱うのに対し、ER図が扱うのは「データの静的な構造」です。オブジェクトの構造を属性と操作で描くクラス図とは多重度の記法が近く、対比しながら読むと関係の表し方が整理できます。処理の時間軸を追うシーケンス図と並べると、同じ設計工程で「データ」「構造」「振る舞い」のどれを担当する図なのかがはっきりします。
概念・論理・物理の3層でER図を描くデータモデリングの進め方
ER図は一枚で完成させるものではなく、抽象度を3段階で降ろしながら詳細化するのが実務の進め方です。まず概念モデルで、業務に登場する主要なエンティティと関係だけを大づかみに描きます。顧客と注文がある、程度の粗さです。次に論理モデルで、各エンティティの属性、主キー、正規化を反映した関係を書き込み、特定のデータベース製品に依存しない形でデータ構造を確定させます。最後の物理モデルは、実際に載せるRDBMSに合わせてテーブル名・カラム名・データ型・インデックスまで具体化する段階です。
この3層を分けておくと、業務の議論（概念・論理）と製品固有の実装（物理）を切り離して進められ、途中でデータベース製品を変えても論理設計を作り直さずに済みます。3層という区切り方は、ANSI/SPARCの三層スキーマ（外部・概念・内部）と対応関係にあり、両方の言葉が現場で混ざりがちです。用語の整理はデータベースのスキーマと三層スキーマの記事にまとめており、どのレイヤの話をしているのかを合わせてから議論すると齟齬が減ります。物理設計で載せる製品の選び方はDBMSとは何かで、具体的なRDBMSの採用判断はMySQLとは何かで詳しく扱っています。
エンティティ・属性・リレーションというER図の3つの基本要素
ER図は、3つの要素さえ読めれば骨格をつかめます。エンティティは、データとして管理したい実体で、四角形で表します。顧客・商品・注文のように、後でテーブルになる単位だと考えると分かりやすいです。属性は、そのエンティティが持つ項目で、顧客なら顧客ID・氏名・メールアドレスなどが該当し、テーブルの列にあたります。属性のうち、行を一意に識別するものが主キー（顧客IDなど）で、下線や記号で区別するのが約束事です。リレーションは、エンティティ間のつながりを表す線で、注文は必ずどれかの顧客に属する、といった業務上の関係を示します。この3要素が組み合わさって、業務データの全体像を一枚に収めた設計図ができあがります。
属性を書き込むときに迷うのが、外部キーを属性として並べるかどうかです。Mermaidの公式ドキュメントは、リレーショナル実装を前提としない論理モデルなら外部キーは省いたほうがよい、関連の線そのものが結びつきを語っているからだ、という立場を示しています。JSONの配列やオブジェクト指向言語の参照でも1対多は実装できる、という理由づけです。逆に、物理設計に近い図では外部キーを明記したほうが実装との照合が楽になります。論理モデルでは省き、物理モデルでは書く、という切り替えを層ごとに決めておくと、図の粒度がぶれません。
ER図の記法：カーディナリティとIE記法・IDEF1Xの書き分け
ER図で表現に差が出るのは、線に添える数の関係（カーディナリティ）と、その描き方（記法）です。ここを正しく読み書きできると、図がデータの制約まで語り始めます。なお、ここでのカーディナリティはテーブル間の多重度を指し、列に含まれる一意な値の数を表す索引設計の指標としてのカーディナリティとは別概念です。
1対1・1対多・多対多を表すカーディナリティ（多重度）の読み方
リレーションの線には、両端のエンティティが「いくつ対いくつ」で対応するかを示すカーディナリティを添えます。基本は3種類です。1対1は、一方のデータに対して他方がひとつだけ対応する関係で、社員と社員証のように分けて持つ場面で使います。1対多は、一方に対して他方が複数対応する関係で、ひとりの顧客が複数の注文を持つ、が典型です。多対多は、双方が互いに複数対応する関係で、注文と商品（ひとつの注文に複数商品、ひとつの商品は複数の注文に登場）が代表例です。
あわせて、その関係が必須か任意か（最小のカーディナリティ）も表します。注文には顧客が必ず要る（必須）、顧客はまだ注文を持たなくてよい（任意）、といった区別です。この「多重度」と「必須/任意」を線に落とすことで、ER図はデータ間の制約そのものを表現します。多重度を線に添える発想は、オブジェクト間の関連を数で表すクラス図の多重度と共通する考え方です。
IE記法（鳥の足）とIDEF1X記法を実務で選び分ける判断基準
カーディナリティの描き方には、主にIE記法とIDEF1X記法の2つがあります。IE記法は、関係の「多」側を線の枝分かれ（鳥の足のような三又）で表す記法で、鳥の足記法とも呼ばれます。三又が「多」、線に交わる短い縦棒が「1」、丸が「任意（0を含む）」を示し、線の端を見るだけで多重度と必須/任意が直感的に読める点が長所です。
IDEF1X記法は、米国政府の標準として整備された記法で、エンティティを識別従属（親なしに存在できない子）かどうかで角丸と角ばりに描き分け、キーの依存関係を厳密に表現できる記法です。この記法は現在、ISO/IEC/IEEE 31320-2:2012（IDEF1X97）として国際規格に取り込まれており、記法の正典を参照したい場合はこの規格が出発点になります。規格の版は2012年発行のものが有効（2026年9月時点）で、識別関係・非識別関係やキーの継承といった語彙は、ここで定義された意味で使われます。
実務での選び分けはこう考えると迷いません。関係者に非エンジニアが多く、直感的な合意を優先するならIE記法が向きます。金融や公共システムのように、キーの依存や識別関係を厳密に管理したい場面ではIDEF1Xが向きます。多くの作図ツールが既定でIE記法を採用しており、Mermaidも公式ドキュメントで「もっとも普及している鳥の足記法を使う」と明言しているため、特段の要件がなければIE記法で始め、チームの標準に合わせるのが現実的です。
多対多を中間テーブルに分解するER図と正規化・非正規化の関係
多対多の関係は、そのままではリレーショナルデータベースのテーブルにできません。注文と商品が多対多なら、間に「注文明細」という中間エンティティを立て、注文（1）対注文明細（多）、商品（1）対注文明細（多）という1対多ふたつに分解します。この分解は、データの重複や矛盾を防ぐために表を適切な単位へ分ける正規化と同じ作業です。正規化そのものの手順は第1〜第3正規形の分解手順を解説した記事で整理しています。
ひとつのエンティティに属性を詰め込みすぎず、繰り返し現れる項目や、主キー以外の項目に従属する項目を別エンティティへ切り出していくと、結果として第3正規形に沿ったER図になります。逆に、参照ばかりで更新が少なく、結合の負荷を避けたい部分では、あえて正規化を崩して属性を持たせる判断（非正規化）もあり、これは物理設計での性能とのかね合いで決める設計判断です。論理モデルまでは正規化を徹底し、物理モデルで必要な箇所だけ崩す、という順で進めると、整合性と性能の両方を管理できます。
分解のしかたには、定型化された失敗の型があります。多対多を分解せずに配列やカンマ区切りの列で持たせる、中間エンティティに意味を持たせすぎて実体が二重になる、といったものです。この手の型を先に知っておくと図のレビューが速くなるため、DB設計のアンチパターン一覧を横に置きながら描くと、線を引く前に踏み外しを避けられます。
ER図の書き方：エンティティ抽出からコードでの管理までの手順
要素と記法を押さえたら、実際に描く手順に移ります。いきなり四角と線を書き始めず、業務に登場するモノを洗い出すところから始めるのが、破綻しない図への近道です。
業務要件からエンティティと属性を洗い出すER図の基本的な作成手順
ER図は、次の5ステップで組み立てると過不足がありません。業務の言葉からデータの構造へ、段階的に翻訳していきます。
- エンティティを洗い出す：業務に出てくる名詞（顧客・商品・注文・入金など、管理したいモノやコト）を挙げ、四角形で並べる
- 属性を割り当てる：各エンティティが持つ項目を書き出し、行を一意に識別する主キーを決める
- リレーションを引く：エンティティ間の業務上の関係を線で結び、どのエンティティがどれと関わるかを確定する
- カーディナリティを添える：各関係が1対1・1対多・多対多のどれか、必須か任意かを線の端に記す
- 多対多を分解する：多対多の関係に中間エンティティを立て、1対多ふたつへ正規化する
最初から細かい属性やコード値まで詰めようとせず、まずは主要なエンティティと関係だけの概念モデルを描き切るのがコツです。全体の骨格が固まってから属性と主キーを足していくと、後戻りが減ります。エンティティの洗い出しは、そもそも業務で何を管理するかを決める要件定義と地続きの作業です。要件をどうまとめるかは要件定義の進め方にまとめており、要件からデータモデルへつなぐ入口になります。
Mermaidやdbdiagram.ioでER図をコードとして管理する方法
作図ツールで描いたER図は、仕様が変わるたびにエンティティと線を引き直す手間がかかります。バージョン管理と相性がよいのが、テキストから図を生成するツールです。Mermaidなら、Markdown内にerDiagramのブロックを書き、CUSTOMER ||--o{ ORDER : placesのような一行で1対多の関係を表せて、GitHubやドキュメントツールでそのまま描画されます。dbdiagram.ioは、DBMLという専用言語でテーブルとリレーションを記述でき、そのままSQLのCREATE文へ書き出せる点が実装寄りです。
日本のRDBMS開発ではA5:SQL Mk-2も広く使われ、既存データベースからER図を逆生成（リバースエンジニアリング）できます。フリーソフトとして配布されており、SQL開発支援とER図編集をひとつのツールで済ませたい場面に向きます。図をコードで持てば、レビューでスキーマの変更差分を追え、論理設計から物理設計へ、さらにSQLのCREATE TABLEへと落とす流れをGitで一貫して管理できる点が利点です。ツールに任せる前に、カーディナリティや正規化の意味を理解しておくと、生成された図やDDLの善し悪しを判断できます。
同じ発想はER図に限りません。システム間のデータの流れを図で持つ場合も、テキスト管理にしておくと版の追跡が楽になります。粒度と記法の決め方はデータ連携図の書き方で整理しています。
MermaidのerDiagramでER図を書く手順とコード例の読み方
ここからは実際に手を動かす節です。MermaidでER図を書くのに必要なのは、erDiagramという宣言、エンティティ名、関係記号の3つだけです。GitHubのMarkdown、VS Codeのプレビュー、多くのドキュメントツールがそのまま描画するため、リポジトリに置いた設計書がレビュー可能な図になります。以下は、注文と商品が多対多になるECのデータ構造を、中間エンティティへ分解したうえでMermaidで書いた例です。そのまま貼り付けて描画できます。
erDiagram
CUSTOMER ||--o{ ORDER : places
ORDER ||--|{ ORDER_ITEM : contains
PRODUCT ||--o{ ORDER_ITEM : "is ordered in"
CUSTOMER {
bigint customer_id PK
string name
string email UK "ログインIDを兼ねる"
string? phone
}
ORDER {
bigint order_id PK
bigint customer_id FK
date ordered_on
string status
}
ORDER_ITEM {
bigint order_id PK, FK
bigint product_id PK, FK
int quantity
}
PRODUCT {
bigint product_id PK
string product_name
decimal(10,2) unit_price
}
読み方はこうです。1行目のCUSTOMER ||--o{ ORDER : placesは「顧客はゼロ個以上の注文を持ち、注文は必ずひとつの顧客に属する」を表す記述です。2行目の||--|{は「注文は1件以上の明細を必ず持つ」で、明細ゼロの注文を許さない業務ルールを図の側で宣言しています。この2行の違いが、そのまま外部キーのNULL許可やCHECK制約の設計につながります。
erDiagramの関係記号でカーディナリティと任意・必須を書き分ける
関係記号は2文字で構成され、外側の文字が最大値、内側の文字が最小値を表す、という規則になっています。Mermaidの公式ドキュメントが示す対応は次のとおりです。
| 左側 | 右側 | 意味 |
|---|---|---|
|o |
o| |
ゼロまたは1 |
|| |
|| |
ちょうど1 |
}o |
o{ |
ゼロ以上（上限なし） |
}| |
|{ |
1以上（上限なし） |
記号が覚えにくければ、公式が用意している英語の別名も使用可能です。one or more、zero or many、only one、1+、0+といった書き方が、それぞれ同じ意味の記号に解決されます。レビュー相手が非エンジニアの場合は別名で書いたほうが読みやすい、という使い分けもできます。
線そのものにも意味があります。--は識別関係（identifying）の実線、..は非識別関係（non-identifying）の破線という描画です。識別関係は、子エンティティが親なしには存在できない場合に使います。先の例でORDER_ITEMを--でつないだのは、注文明細が注文と商品の両方なしには成立しないためです。逆に、人と車のように互いに独立して存在できる多対多はPERSON }|..|{ CAR : "driver"のように破線で書きます。この識別／非識別の区別はIDEF1Xの識別従属と同じ考え方で、記法をまたいで通用する概念です。
PK・FK・UKと省略可能な属性をMermaidのコードで表現する手順
属性は、エンティティ名の後ろに波括弧のブロックを置き、型 名前の組で並べます。型は英字で始まり、数字・ハイフン・アンダースコア・丸括弧・角括弧を含められるため、decimal(10,2)やvarchar(255)のような物理型をそのまま書けます。Mermaid側に決まった型の一覧があるわけではなく、書いた文字列がそのまま図に出る仕様です。
キー種別はPK（主キー）、FK（外部キー）、UK（一意キー）の3つが使え、複合主キー兼外部キーのように複数を付けたい場合はPK, FKとカンマで区切ります。先の例のORDER_ITEMがこの形です。属性の末尾にダブルクォートで囲んだ文字列を置くとコメントになり、図の右側に注記として並びます。ダブルクォート自体をコメント内に含める書き方は用意されていません。
NULL許可を図で表したい場合は、型の末尾に?を付けます。例のstring? phoneがそれで、電話番号が未登録でもよいことを図の段階で宣言しています。この省略可能型はMermaid 11.16.0以降で使える機能、エンティティをグループ化するsubgraphは11.17.0以降の機能です。MermaidのGitHubリリース一覧で確認すると、2026年8月時点の最新は11.17系にあたります。導入先のドキュメントツールが同梱しているMermaidの版が古いと、これらの記法が構文エラーになるため、使う前に版を確認しておくと安全です。erDiagram以外の図種も含めた書き方の全体像はマーメイド記法の書き方とテキスト管理の記事に整理しています。
DBMLとCREATE文でER図をテーブル定義へ落とす実装手順
Mermaidは「読ませる図」に強い一方、そこから実際のDDLを生成する機能はありません。図と実装のスキーマを同じ源から出したい場合は、dbdiagram.ioが採用しているDBML（Database Markup Language）が有力です。DBMLはテーブル・列・制約・参照関係を宣言する言語で、記述からER図とSQLの両方を出力できます。ここでは、先ほどMermaidで描いたのと同じデータ構造をDBMLで書き、PostgreSQLのDDLへ落とすところまでを追います。
DBMLでテーブルとRefを定義しdbdiagram.ioからSQLへ書き出す
DBMLの基本は、Tableブロックで列を並べ、角括弧の中に列の設定を書く形です。参照関係はRefでの宣言です。DBMLの公式ドキュメントによれば、関係の記号は4種類で、<が1対多、>が多対1、-が1対1、<>が多対多を表します。削除時・更新時の参照動作も[delete: cascade]のように設定でき、これがSQLのON DELETE句へ対応します。
Project shop_core {
database_type: 'PostgreSQL'
}
Table customers {
id bigint [pk]
email varchar(255) [unique, not null]
name varchar(100) [not null]
phone varchar(20)
}
Table orders {
id bigint [pk]
customer_id bigint [not null]
ordered_on date [not null]
status varchar(20) [not null, default: 'draft']
}
Table order_items {
order_id bigint [not null]
product_id bigint [not null]
quantity int [not null, default: 1]
indexes {
(order_id, product_id) [pk]
}
}
Ref: orders.customer_id > customers.id [delete: restrict]
Ref: order_items.order_id > orders.id [delete: cascade]
Ref: order_items.product_id > products.id [delete: restrict]
この記述をdbdiagram.ioに貼るとER図が描画され、SQLへ書き出せば同じ構造のCREATE文を得られる仕組みです。多対多については、<>で1本の関係として書く方法と、中間テーブルを立てて多対1を2本書く方法の両方が公式に用意されています。公式ドキュメントは、この2つの違いが「SQLへ書き出したときの物理設計への落ち方」に出ると説明しています。中間テーブルに数量や単価といった固有の属性を持たせる必要があるなら、後者を選ぶ以外にありません。上の例でorder_itemsを独立したテーブルにしているのは、明細ごとの数量を持つためです。
列の設定にはpk、unique、not null、default、noteなどが並べられます。複合主キーは列の設定では書けず、indexesブロックの中で列の組に[pk]を付ける形になります。上のorder_itemsがその書き方です。図とDDLを同じ記述から出せることが、ER図を「更新されない紙の資料」にしない仕掛けになります。
外部キー制約と削除時の参照動作をCREATE文で実装する判断基準
DBMLから書き出したDDLは、そのまま使うのではなく、参照動作と一意制約を業務ルールに照らして見直します。ER図で「必須」と描いた関係はNOT NULL付きの外部キーに、「任意」と描いた関係はNULL許可の外部キーになります。ここが図と実装のいちばん直接的な対応点です。PostgreSQLでの書き方は次のようになります。
CREATE TABLE customers (
id bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
email varchar(255) NOT NULL UNIQUE,
name varchar(100) NOT NULL,
phone varchar(20)
);
CREATE TABLE products (
id bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
name varchar(200) NOT NULL,
unit_price numeric(10,2) NOT NULL CHECK (unit_price >= 0)
);
CREATE TABLE orders (
id bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
customer_id bigint NOT NULL REFERENCES customers (id) ON DELETE RESTRICT,
ordered_on date NOT NULL,
status varchar(20) NOT NULL DEFAULT 'draft'
);
CREATE TABLE order_items (
order_id bigint NOT NULL REFERENCES orders (id) ON DELETE CASCADE,
product_id bigint NOT NULL REFERENCES products (id) ON DELETE RESTRICT,
quantity int NOT NULL CHECK (quantity > 0),
PRIMARY KEY (order_id, product_id)
);
削除時の挙動をどちらにするかが、設計判断の分かれ目です。PostgreSQL公式ドキュメントの制約の章は、参照される行を消そうとしたときの既定動作がNO ACTIONであること、RESTRICTは制約検査を遅延できない点だけがNO ACTIONと異なることを説明しています。上の例で、注文明細は注文と一蓮托生なのでCASCADE、顧客や商品は履歴として残す必要があるのでRESTRICTとしました。この使い分けは、ER図の識別関係（実線）と非識別関係（破線）の区別とほぼ重なります。親なしに存在できない子はCASCADE、独立して存在する側はRESTRICT、という対応で考えると迷いが減ります。
1対1をどう実装するかも、図から実装へ落とすときに詰まりやすい箇所です。外部キーの列にUNIQUEを付けると1対1、付けなければ1対多という違いがあります。図で||--||と描いたなら、DDL側で一意制約を忘れていないかが必須の確認事項です。参照整合性の考え方そのものはPostgreSQL公式チュートリアルの外部キーの節が短くまとまっており、なぜ孤児行を作らせないのかという前提から追えます。なお本記事のDDLはPostgreSQL 18系（2026年9月時点の安定版）の構文で確認したもので、GENERATED ALWAYS AS IDENTITYのような標準SQL寄りの書き方は製品によって差があります。
制約を張るだけでは守り切れない整合性もあります。複数テーブルにまたがる更新をひとまとまりで確定させる仕組みはトランザクションの記事で扱っており、ER図で表せる静的な制約と、実行時に守る動的な整合性は役割が別だと切り分けて設計します。
データベース設計工程でER図を使う判断と書きすぎの失敗パターン
ここからは立場を明確にします。ER図は、どんな開発でも必ず描くべき図ではありません。効く場面があり、逆に描くことが手間だけを増やす状況もあります。どちらかを見極める基準を、具体的な条件で示します。
論理設計でER図が効く場面と物理テーブル定義への橋渡しの判断
ER図がもっとも力を発揮するのは、複数のエンティティが複雑に関連する業務システムのデータ構造を設計する場面です。販売管理・在庫管理・会計のように、注文・在庫・請求が互いに参照し合う仕組みでは、データの持ち方を図で共有しておくと、テーブル分割の抜けや整合性の崩れを実装前に発見できます。工程全体のどこにER図という設計成果物が位置づくかはシステム開発の工程と7フェーズの成果物の全体像が判断の土台です。概念モデルで業務の合意を取り、論理モデルで正規化とキーを固め、物理モデルでRDBMSに合わせて具体化する、という順で使い分けると、業務の議論と実装の詳細を切り離して進められます。本記事は、その設計工程で使うデータモデリング手法そのものを掘り下げる役割です。
ER図を書きすぎない見極めと、過剰設計になりがちな失敗パターン
ER図を描くべきでない場面もはっきりあります。第一に、テーブルが数個で関係も単純な小さな仕組みです。コードやテーブル定義を見れば分かる構造を図にしても、保守の手間が増えるだけです。第二に、まだ業務要件が固まっていない検討初期に、細かい属性まで清書すると、要件が動くたびに描き直しになります。
ありがちな失敗は3つあります。ひとつは、すべての属性やコード値まで一枚に詰め込み、線が交差して読めない巨大な図にしてしまうこと。ふたつめは、論理モデルと物理モデルを分けず、いきなり製品固有のデータ型やインデックスまで書き込んで、業務の議論ができなくなること。みっつめは、図を作ること自体が目的化し、実装後にスキーマが変わっても更新されず、実態と食い違ったまま放置されることです。三つに共通するのは、ER図がデータ構造の合意と設計判断の道具であるという原点を見失っている点にあります。
三つめの「更新されない図」は、運用の工夫によって相当程度の抑制が可能です。図をDBMLやMermaidのテキストとしてリポジトリへ置き、スキーマ変更のプルリクエストに図の差分も含める運用にすると、コードレビューと同じ経路で図が更新されます。全体を一枚に描き切ろうとせず、業務の中核となるエンティティと関係に絞り、詳細はDDLやデータ辞書に任せるほうが、図は長く使われます。
受託開発でデータモデルを業務要求から一貫して設計する体制の作り方
ER図が真価を発揮するのは、基幹システムや業務システムのように、多くのデータが連携し、長く保守し続ける前提の開発です。データ構造の設計を初期に誤ると、後からデータの重複や不整合が顕在化し、改修に多大な工数がかかります。とはいえ、業務の要求を破綻しないデータモデルへ落とし込むには、正規化の理論とドメイン（業務知識）の両方が要る仕事です。社内にデータ設計を主導できる人材がいない、既存システムのテーブル構造が複雑で手を入れづらい、といった場面では、外部の伴走が歯止めになります。一創では基幹システム開発として、業務要求をエンティティとリレーションへ整理する要件定義から、論理・物理設計、実装、運用までを一貫して支援しています。図を描く技術だけでなく、変更や拡張に強いデータモデルを業務要求から導くところまで含めた伴走が一創の強みです。
よくある質問
ER図の理解と実務でつまずきやすい点を、5つの質問に絞って整理します。
ER図とデータベースのテーブルは何が違いますか？
抽象度が異なります。ER図は、業務で扱うデータを実体（エンティティ）と関係で表した設計図で、特定のデータベース製品に依存しない論理レベルまでを主に扱います。テーブルは、そのER図を物理設計で具体化した実装で、製品固有のデータ型やインデックスを持つ実体です。実務では、ER図の論理モデルで正規化とキーを固めてから、物理モデルでテーブル定義（CREATE文）へ落とす、という順で使います。ER図が「どんなデータをどう持つかの合意」、テーブルが「その合意を実際に載せた形」だと考えると分かりやすいです。
1対多と多対多はどう描き分けますか？
関係の両端の数で判断します。一方に対して他方が複数対応するなら1対多で、顧客と注文（ひとりが複数注文）が典型です。双方が互いに複数対応するなら多対多で、注文と商品が代表例になります。IE記法では「多」側を鳥の足（三又）で描き、「1」側を短い縦棒で示すのが約束事です。MermaidのerDiagramなら1対多が||--o{、多対多が}|..|{という記号にあたります。多対多はそのままテーブルにできないため、間に中間エンティティ（注文明細など）を立てて1対多ふたつへ分解してから物理設計へ進めます。
IE記法とIDEF1Xはどちらを使えばよいですか？
関係者と要件で選びます。非エンジニアを含む関係者と直感的に合意したい場合や、多くの作図ツールの既定に合わせたい場合はIE記法（鳥の足）が読みやすいはずです。キーの依存や識別関係を厳密に管理したい金融・公共システムなどではIDEF1Xが向き、記法の正典はISO/IEC/IEEE 31320-2:2012にあります。特段の要件がなければ、読みやすさとツール対応の広さからIE記法で始め、チームやプロジェクトの標準があればそれに合わせるのが実際的です。記法よりも、カーディナリティと正規化を正しく反映することのほうが設計の質を左右します。
ER図と正規化はどう関係しますか？
地続きの作業です。正規化は、データの重複や矛盾を防ぐために表を適切な単位へ分ける整理で、その結果がER図のエンティティ分割に反映されます。多対多を中間エンティティへ分解したり、繰り返し項目を別エンティティへ切り出したりする操作が、第2・第3正規形に沿った形です。論理モデルまでは正規化を徹底し、物理モデルで結合の負荷を避けたい箇所だけ、あえて崩す（非正規化）判断を性能とのかね合いで加える、という順で進めると整合性と性能を両立できます。
ER図はどのツールで作成できますか？
作図に特化したツールとして、draw.io、Lucidchart、A5:SQL Mk-2などが挙げられます。テキストから図を生成するMermaid（erDiagram）やdbdiagram.ioのDBMLも使え、Gitでのバージョン管理と併せて運用でき、DBMLはSQLのCREATE文へ書き出せます。既存データベースからER図を逆生成したい場合はA5:SQL Mk-2が便利です。スキーマの変更が頻繁で図を実装と同期させたい場合はコードで管理できるツール、見た目を細かく整えたい場合はGUIの作図ツールが向きます。チームが図をコードで持つか資料として持つかに合わせて選ぶのが実際的です。
関連記事
- データベースとは：ER図で設計するデータを載せるDBの種類・DBMS・RDBとNoSQLの選び方の全体像
- SQLとは：論理設計したER図を物理設計のCREATE TABLEへ落とす、DDLの書き方
- クラス図とは：多重度の記法が近いUMLの図。オブジェクト構造とデータ構造を対にして読む
- データベースのスキーマとは：概念・論理・物理と三層スキーマの用語を突き合わせて整理する
- マーメイド記法とは：erDiagramを含む各図種の書き方とテキストでの版管理の手順
- 要件定義とは：エンティティ抽出の入口。業務要求からデータモデルへつなぐ上流工程
- システム開発の工程とは：ER図を作る設計がどの工程に位置づくかの全体像
