ER図の読み方：要件定義とDB設計レビューで押さえるべき最小知識

ある程度の規模のシステム開発では、要件定義の中盤から終盤にかけて、ベンダーが ER図（Entity-Relationship Diagram） を提出してきます。これはデータベースの構造を図示したものですが、「テーブルがたくさんあって線でつながっている図」として眺めるだけでは、設計の妥当性を確認できません。

発注側がER図を完全に理解する必要はありません。しかし、最低限の読み方を知っていると、設計の抜け漏れや業務要件とのズレを早い段階で発見できます。

ER図の構成要素

ER図は大きく3つの要素で構成されています。

エンティティ（Entity）
テーブルに対応する箱です。「顧客」「注文」「商品」といった業務上の主要な概念が一つひとつの箱として表現されます。箱の中には、そのテーブルが持つ列（属性）が列挙されます。

リレーションシップ（Relationship）
エンティティ間をつなぐ線です。「顧客は複数の注文を持つ」「注文は一人の顧客に紐づく」といった関係性を表します。

カーディナリティ（Cardinality）
線の端についた記号で、関係の数量を示します。「1対多」「多対多」など、エンティティ間の数の関係を表現します。

カーディナリティの読み方

線の端に付く記号の意味は表記法によって異なりますが、よく使われる**IE記法（鳥の足記法）**では以下のように読みます。

記号	意味
`	` （縦線1本）
< または > （鳥の足）	多（0以上）
○	0（任意）

「1対多」の関係は、線の片端に |（1）、もう片端に <（多）が付きます。例えば「1人の顧客が複数の注文を持つ」関係は、顧客側に縦線、注文側に鳥の足が付きます。

「0または1」「必ず1」「0以上の多」「1以上の多」の組み合わせで、業務ルールが表現されています。「この関係はゼロが許容されているか」を確認することは、業務要件のチェックとして重要です。

要件定義・設計レビューでの確認ポイント

業務上の主要なエンティティがすべて存在するか

「受注」「顧客」「商品」「請求」など、業務の中心となるデータが漏れなくテーブルとして定義されているか確認します。エンティティが少なすぎる場合、重要なデータがどこかに埋もれているか、設計が省略されている可能性があります。

多対多のテーブルが適切に中間テーブルで解決されているか

「1件の注文に複数の商品が含まれ、1つの商品は複数の注文に含まれる」という多対多の関係は、そのまま二つのテーブルをつなぐことができません。この場合「注文明細」のような中間テーブルが必要です。ER図でテーブルが直接つながっている多対多の関係を見つけたら、設計上の問題です。

削除したときの影響範囲が考慮されているか

あるテーブルのレコードを削除したとき、それを参照している別のテーブルのレコードはどう扱われるかを確認します。「顧客を削除したとき、その顧客の注文履歴はどうなるか」という問いに答えられる設計かどうかは、外部キー制約と削除ポリシー（CASCADE・RESTRICT等）として定義されているはずです。

業務キーと主キーの区別がされているか

「受注番号」や「商品コード」のような業務上の識別番号（自然キー）と、データベース内部で一意性を保証するための連番ID（代理キー）が混同されていないか確認します。業務コードを主キーとして使用している場合、コード体系の変更がシステム全体に波及するリスクがあります。

非機能要件に関わるテーブルが設計されているか

ログ・履歴・通知・設定値など、画面には出てこないが運用上必要なテーブルが設計に含まれているかを確認します。これらは要件定義で明示的に話し合わないと、開発後半や運用フェーズで追加が必要になることがあります。

ER図は「会話の道具」として使う

ER図は完成した設計書である前に、発注側とベンダーが「業務の理解が合っているか」を確認するための会話の道具です。

「この線の関係は正しいですか」「このテーブルにはどんな情報が入りますか」と問いかけることで、業務要件の認識のズレを早い段階で発見できます。完全に読み解けなくても、気になる箇所を指摘して議論できるだけで、設計レビューの質は大きく変わります。