【データ構造を本質をつかめるER図の基本も、簡単な事例から学べます！】

ER図を作るのは面倒

多くの実務者がそう感じています

ツールを開いて、ボックスを置いて、線を引いて、カーディナリティを設定して… 気づけば「図を作ること」が目的になってしまう

でも、ER図は“業務の本質”をつかむための道具であって、 作図作業に時間を奪われるべきではありません

そこで役に立つのが Mermaidコード です

コードで書けば、

• 図形を並べる必要もない
• カーディナリティも一行で表現できる
• 修正も一瞬
• 生成AIとの相性も抜群

そして何より、データ構造の理解が圧倒的に深まる

この記事では、 顧客 → 注文 → 注文明細 → 商品 という実務で最もよく登場する4つのテーブルを題材に、 ER図の本質と、Mermaidでの表現方法を解説します

さらに後半では、 Excelの表からでもER図が作れる という“現場で即使える視点”も補足します

まずは、次のGIFをご覧ください。 左側のコードと右側のER図が連携しているのが良く分かると思います

事例の紹介

ER図の説明に入る前に、まずは いきなり事例から 見ていただきたいと思います

理由はとてもシンプルで、ER図は“文章よりもビジュアルで理解するもの” だからです

データ構造の話を文章だけで読んでも、「テーブル」「リレーション」「主キー」「外部キー」などの用語が並び、 初心者の方にはどうしてもイメージしづらい部分があります

しかし、図を一度見れば一気に理解が進む

だからこそ、最初に“完成形のイメージ”を提示することが重要なのです

この記事では、次のような 顧客 → 注文 → 注文明細 → 商品 の4つのテーブルからなる 典型的な業務データのER図を例に進めていきます

このER図と対応するMermaidコードも、すぐ下に掲載しています

コードと図をセットで見ることで、 「ER図はコードで書くとこんなにシンプルなのか」 という感覚がつかめるはずです

erDiagram
    顧客マスタ ||--o{ 注文テーブル : 顧客の注文
    注文テーブル ||--|{ 注文明細テーブル : 注文の明細
    商品マスタ ||--o{ 注文明細テーブル : 商品の明細行
    顧客マスタ {
        string 客先ID　PK　"オートナンバー"
        string 顧客名 "氏名"
        string メールアドレス　"取得できないこともある"
    }
    注文テーブル {
        string 注文ID
        string 客先ID
        date 注文日
        string ステータス
    }
    商品マスタ {
        string 商品ID
        string 商品名
        float 価格
    }
    注文明細テーブル {
        string 注文ID
        string 商品ID
        int 数量
        float 価格
    }

各テーブル（マスタ）の意味と役割

上記のER図の意味合いを紐解くために、各テーブル（マスタ）の詳細を解説します

● 顧客（Customer）

顧客を一意に識別するためのテーブルです

内部的なID（オートナンバー）を主キーとし、 顧客名やメールアドレスなど、顧客に紐づく基本情報を保持します

● 注文（Order）

顧客が行った注文を記録するテーブルです

注文IDを主キーとし、どの顧客が、いつ、どんなステータスで注文したかを管理します

顧客IDは外部キーとして、顧客テーブルとつながります

● 商品（Product）

販売している商品の一覧を管理するテーブルです

商品IDを主キーとし、商品名や価格などの基本情報を保持します

商品は複数の注文に登場するため、後述の注文明細と関係します

● 注文明細（OrderDetail）

注文と商品を結びつける“中間テーブル”です

1つの注文に複数の商品が含まれるため、 注文ID × 商品ID の組み合わせで1行を識別します

数量や価格は「注文時点の情報」を保持するために必要です

リレーション・属性・主キー／外部キーの基本

ここからは、先ほど紹介した事例をもとに、 ER図を読み解くために欠かせない基本概念を整理していきます

図を見ただけで理解できる人もいますが、 多くの人にとっては 「言葉の意味」 が分かることで ER図が一気に読みやすくなります

リレーション（Relation）とは何か

リレーションとは、テーブル同士の“関係そのもの”のことです

例：

• 顧客 と 注文 の関係
• 注文 と 注文明細 の関係
• 商品 と 注文明細 の関係

これらはすべて リレーション です

リレーションは「線」そのもの

ER図では、テーブル同士を結ぶ線がリレーションです

リレーションには“名前”をつけられる

Mermaidコードでは以下のように書きます

顧客マスタ ||--o{ 注文テーブル : 顧客の注文

この顧客の注文がリレーション名です

カーディナリティ（Cardinality）とは何か

カーディナリティは「その関係が何対何か」を表す記号です。

例：

• || = 1
• o{ = 0..多
• |{ = 1..多

つまり、 リレーション（関係）に対して “どれくらいの数が結びつくか” を示すのがカーディナリティ

リレーション（関係)

→顧客 と 注文 がつながっている

カーディナリティ（多重度）

→顧客1人に対して、注文は0件以上

このように 別の概念 です

ここからは、前述のER図にしたがって各カージナリティについて解説します

顧客マスタ ||–o{ 注文テーブル : 顧客の注文

✔ カーディナリティの意味

• 顧客（左側）：|| → 必ず1人
• 注文（右側）：o{ → 0件以上

✔ 詳細解説

1人の顧客は、0件以上の注文を持つことができる（注文しない顧客もいるし、複数回注文する顧客もいる）

結果として以下の画像のように表示されます

注文テーブル ||–|{ 注文明細テーブル : 注文の明細

✔ カーディナリティの意味

• 注文（左側）：|| → 必ず1件
• 明細（右側）：|{ → 1件以上

✔ 詳細解説

1件の注文には、必ず1件以上の明細（商品の注文）が存在する。 （明細が1つもない注文はあり得ない）

結果として以下の画像のように表示されます

商品マスタ ||–o{ 注文明細テーブル : 商品の明細行

✔ カーディナリティの意味

• 商品（左側）：|| → 必ず1商品
• 明細（右側）：o{ → 0件以上

✔ 詳細解説

結果として以下の画像のように表示されます

属性（Attribute）とは何か

属性とは、テーブルの中にある“項目（列）”のことです

例： 顧客マスタ

• 客先ID
• 顧客名
• メールアドレス

注文テーブル

• 注文ID
• 注文日
• ステータス

これらはすべて 属性 です

主キー（Primary Key）とは何か

主キーとは、テーブルの中で“1行を一意に識別するための項目”です

例：

• 顧客マスタ → 客先ID（オートナンバー）
• 商品マスタ → 商品ID
• 注文テーブル → 注文ID
• 注文明細 → 注文ID × 商品ID（複合キー）

主キーがないと、本に全部カバーがかかった本棚と一緒で「どの行がどのデータなのか」 が分からなくなります

外部キー（Foreign Key）とは何か

外部キーとは、別のテーブルの主キーを参照する項目です

例：

• 注文テーブルの「客先ID」
• 注文明細テーブルの「注文ID」「商品ID」

外部キーがあることで、 テーブル同士がつながり、リレーションが成立します

Mermaid ER図の書き方ガイド

MermaidでER図を書くときは、 ① テーブルを書く → ② リレーションを書く → ③ カーディナリティを書く → ④ リレーション名を書く という順番で考えると迷いません

テーブル（エンティティ）の書き方

基本形はこれだけです

テーブル名 {
    データ型 属性名
}
テーブル名 {    データ型 属性名}

例：

顧客マスタ {
    string 客先ID PK
    string 顧客名
    string メールアドレス
}

ポイント

• { } の中は 属性（列） を書く
• データ型はゆるくてOK（string / int / float / date など）
• 主キーは PK、外部キーは FK と書くと読みやすい
• さらに以下のように注釈も加えることができます（例：string 客先ID　PK　”オートナンバー”）

リレーション（関係）の書き方

テーブル同士を線でつなぐ部分です。

コード

A ||--o{ B : リレーション名

構造は3つだけ

1. 左側のテーブル名
2. カーディナリティ記号
3. 右側のテーブル名
4. : リレーション名（任意）

カーディナリティ（多重度）の書き方

下記のように４種類あります

注意点としては、上記のように書いても図にはそのままの形で反映されません

|oの場合と||の場合は、以下です

その他のは以下の通りです

}oの場合

}|の場合

リレーション名の書き方

リレーション名は 線の意味を短く表す“名前” です。

例：

コード

顧客マスタ ||--o{ 注文テーブル : 顧客の注文

✔ 日本語でOK

• 顧客の注文
• 注文の明細
• 商品の明細行

初心者向けの記事では 日本語のほうが圧倒的に理解しやすい です。

ER図の書き方のコツ

✔ コツ1：まずは「業務の流れ」を書く

顧客 → 注文 → 明細 → 商品 という流れを線でつなぐだけで、ER図の骨格ができる。

✔ コツ2：カーディナリティは“現場の実態”で決める

• 注文しない顧客もいる → o{
• 明細がない注文は存在しない → |{
• 売れない商品もある → o{

✔ コツ3：リレーション名は日本語でOK

図を見る人の理解が一気に深まります

書き方まとめ：Mermaid ER図は「書き方の型」を覚えれば迷わない

1. テーブルを書く
2. リレーションを書く
3. カーディナリティを書く
4. リレーション名を書く

この順番で書けば、 誰でも再現性高くER図を作れる ようになります。

（参考）生成AIに作成させることもできます

エクセルの画像を生成AIに喰わせて、Mermaidコードを書くこともできます

例えば、こんなエクセルの画像を生成AIにアップロードして、「ER図をMermaidコードを書いて」と依頼したとします

そうすれば、きちんとMermaidコードを書いてくれます

erDiagram
    顧客 ||--o{ 注文 : places

    顧客 {
        int 客先コード PK
        string 客先名
    }

    注文 {
        date 注文日
        int 客先コード FK
        int 数量
    }

＜まとめ＞

ER図は“業務理解 × 自動化 × AI活用”の基盤になる

• 業務の流れを構造として理解できる
• 自動化やデータ分析の前提が整う
• 生成AIと組み合わせると作図が圧倒的に速くなる
• ExcelしかなくてもER図を作れる

ER図は、単なる図ではなく 業務の本質をつかむための“共通言語” です。

そして Mermaid を使えば、 その共通言語を 誰でも・素早く・正確に 書けるようになります。

にほんブログ村

にほんブログ村

にほんブログ村

にほんブログ村