ER図の記号は記法がいくつもあって最初は混乱しますが、実務で読み書きするのは事実上カラスの足（IE記法）ひとつです。この記事は大半をカラスの足の記号を漏れなく身につけることに割き、学校で習うChen記法とOracle系文書で見かけるBarkerまで、同じ例で比較します。
記法が複数ある理由は単純です。1970年代に学界（Chen）が概念を作り、その後、実務のツールが画面に描きやすい形（IE）に整えて採用しました。学ぶときと働くときで見る図が違うのはそのためです。
カラスの足の記号の読み方
本題です。IE（Information Engineering）記法で覚えることはちょうど2つ、線の端の記号と線の種類だけです。これさえ身につければ、どのER図を開いてもリレーションが読めます。
ER図の記号と「矢印」の意味
先に押さえておくことがあります。線の端に付く印は矢印ではなく、件数（カーディナリティ）の記号です。基本の記号は3つだけです。
| 記号 | 意味 |
|---|---|
縦棒 | |
1 |
丸 ○ |
0（なくてもよい） |
| カラスの足（三つ叉） | N（複数） |
実際の線の端には、この記号が2つずつ組み合わさって付きます。読み方の要はひとつです。内側（線の中央寄り）の記号が最小、エンティティに接する外側の記号が最大。 あり得る組み合わせは4つで全部です。
||ちょうど1。その行が必ず1件あります。○|0または1。なくてもよく、あっても1件です。|<1以上（1..N）。最低1件は必要です。○<0以上（0..N)。0件でも複数でも構いません。
線の種類：実線と点線
線そのものにも2種類あります。実線は識別関係で、親のキーが子の主キーの一部になる場合です。注文明細のPKが（注文ID+商品ID）の複合キーになっているのが代表例です。点線は非識別関係で、親のキーを通常のFKカラムとして参照するだけです。投稿がmember_idカラムで会員を参照する、実務で一番よくある形はこちらです。
読み始めのうちは、実線・点線の区別より線の端の記号を正確に読むほうが先です。区別が効いてくるのは複合キーの設計に出会ってからです。
読み取り練習1：1対多（1:N）はどう表すか
掲示板DBで練習します。会員と投稿の間の線はこう描かれます。
会員 ||──────○< 投稿会員側の端から読みます。投稿から見た会員は ||、ちょうど1人です。反対側、会員から見た投稿は ○<、0件かもしれないし複数かもしれません。合わせて読むと「投稿は必ず会員1人のもの。会員は投稿がないことも多数のこともある」。一番よくある1:Nリレーションの標準形です。
読み取り練習2：最小値が変わると
注文と注文明細は形が少し違います。
注文 ||──────|< 注文明細注文明細側の端が ○< ではなく |< です。最小が0ではなく1という意味です。読むと「注文明細は必ず注文1件に属し、注文には明細が最低1件は必要」。空の注文を許さないという業務ルールが、記号ひとつに入っています。○< と |< の違いを見落とすと、このルールが図から消えます。
読み取り練習3：0または1
会員とプロフィールのように1対1で対応する関係でよく見る形です。
会員 ||──────○| プロフィールプロフィール側の端が ○|、0または1です。「会員はプロフィールを持たないこともあり、持っても1つだけ」と読みます。
読み取り練習4：点線が混ざったら
今度は線の種類まで一緒に読みます。投稿と会員の間が点線で描かれています。
会員 ||- - - - ○< 投稿端の記号は練習1と同じなので、件数は変わりません。変わったのは点線、つまり非識別関係だという情報です。「投稿は会員のキーを通常のカラム（member_id）として参照し、そのカラムは投稿の主キーには含まれない」まで読み取れます。逆にこの線が実線だったら、member_idが投稿のPKの一部だという意味になるので、線ひとつでキー設計が変わります。
読み取り練習5：多対多が解かれた形
最後に、実務の図で多対多が実際に見える形です。投稿とタグのN:Mは、ふつう中間テーブルを挟んでこう描かれています。
投稿 ||──────○< post_tags >○──────|| タグ中間テーブルpost_tagsから両側に伸びる線をそれぞれ読めば済みます。投稿1件にpost_tagsが0件以上、タグ1件にもpost_tagsが0件以上。1:Nが2本合わさって「投稿にタグが複数、タグに投稿が複数」という多対多が完成します。図でこの砂時計のような形を見たら、多対多を解いたものだと読めばよいのです。
5つの練習を通過したなら、IE記法で出会う組み合わせは全部読んだことになります。あとは実際の図で繰り返すだけです。続きはER図の書き方の掲示板実習で練習できます。
読むときによく間違える3つ
練習のついでに、設計レビューでよく見る読み間違いも押さえておきます。
記号を矢印として読む。 カラスの足が矢じりのように見えて「データがこちらへ流れる」と読んでしまう場合がありますが、向きではなく件数です。カラスの足が付いた側が複数という意味しかありません。
最小と最大を逆に読む。 ○< を「最大0」と読むと、リレーション全体がひっくり返ります。常に内側が最小、エンティティに接する側が最大です。迷ったら、エンティティに触れている記号から確認すれば大丈夫です。
カーディナリティとFKの位置を混同する。 「会員 1 : N 投稿」で、FK（member_id）は常にN側の投稿テーブルにあります。図を読んでいてFKが1側にあるように見えたら、図を疑う前に、リレーションを逆に読んでいないかを疑うのが先です。
Chen記法：学校で習うあの図
データベースの授業でひし形と楕円を描いた記憶があるなら、それがChen記法です。試験対策も兼ねて、記号を表にまとめておきます。
| Chen記号 | 意味 |
|---|---|
| 四角 | 実体（エンティティ） |
| ひし形 | リレーション |
| 楕円 | 属性 |
| 下線付きの楕円 | キー属性 |
| 二重の楕円 | 多値属性 |
| 線上の1・N・M | カーディナリティ |
概念を学ぶには良い構造です。リレーション自体がひし形という独立した図形なので、「実体と実体の間にリレーションがある」というモデルの骨格が目に見えます。試験に出るのもそのためです。
実務で使われない理由も同じ構造から来ます。リレーションごとにひし形、属性ごとに楕円を描くと、テーブル30個のスキーマで図形が数百個になります。画面が持ちませんし、カラムの型や制約といった実装情報を書く場所もありません。課題でChenを指定された場合を除けば、IEで描くのが実務の基準です。
ChenからIEへの読み替えは機械的にできます。ひし形（リレーション）は2つのテーブルを結ぶ線に、線上の1とNは線の端の記号に、楕円（属性）はテーブルの箱の中のカラム行になります。概念は何も捨てずに、描き方だけが変わります。
Barker記法：Oracle系文書で見かける方式
もうひとつ、Oracle系の文書や古い設計資料でBarker記法に出会うことがあります。カラスの足でNを表すのはIEと似ていますが、線の半分を点線（なくてもよい）・半分を実線（必ずある）で描いて必須かどうかを表現し、リレーション名を両方向に書くのが特徴です。自分で描く機会は少なくても、読めれば古い設計文書の前で戸惑いません。
同じリレーションを3つの記法で比較
言葉で比べるより、同じリレーションを並べて見るのが早いです。「会員 1 : N 投稿」を3つの記法で描くとこうなります。
持っている情報は同じです。違うのは描くコストと読むコストで、IEが一番圧縮的、Chenが一番説明的、Barkerはその中間あたりです。
実務がカラスの足に収束した理由
実務のER図ツールの多くがIEを既定の記法にしています。理由は上で見たとおりです。テーブルが数十個に増えても箱と線だけで図が保て、テーブルの箱の中にカラム・型・キーの情報まで入るので、図がそのまま実装ドキュメントになります。MermaidのerDiagramも、無料オンラインER図ツールも同じカラスの足の体系です。一度覚えればツールが変わってもそのまま通用します。
よくある質問
学校ではChen記法を習ったのに、実務はなぜIE記法なのですか？
実務がIEを使う理由はスペースとツールです。Chenはリレーションごとにひし形、属性ごとに楕円を描くため、テーブルが30個もあれば画面が持ちません。IEはテーブルの箱と線だけで同じ情報を持て、大きなスキーマでも読めるので、実務のER図ツールの多くがIEを採用して事実上の標準になりました。Chenで学んだ概念はそのまま有効なので、記号だけ読み替えれば大丈夫です。
ER図の点線と実線は何が違うのですか？
違いは識別関係かどうかです。実線（識別関係）は親のキーが子の主キーの一部になる場合で、注文明細のPK（注文ID+商品ID）が代表例です。点線（非識別関係）は親のキーを通常のFKカラムとして参照するだけの場合で、投稿のmember_idのように、実務のリレーションの大半はこちらです。
ER図の矢印の向きにはどんな意味がありますか？
IE記法の線の端の記号は、向きを示す矢印ではなく件数（カーディナリティ）を表す記号です。カラスの足のように三つに開いた側が複数（N）、短い縦棒が1件を意味します。矢印だと思ってデータの流れる向きで読むと逆に読んでしまうので、それぞれの端をそのテーブル側の件数として読んでください。
多対多（N:M）のリレーションはどう描きますか？
多対多は両端にカラスの足を描いて表します。ただしリレーショナルDBはN:Mを直接保存できないため、実装では両方のキーを持つ中間テーブルを置いて1:N二本に分解します。そのため実務のER図では、N:Mの線そのものより中間テーブル（post_tagsのような）が描かれた形をよく見ることになります。
最後に、この記事全体を4つの文に圧縮します。線の端の記号は矢印ではなく件数。内側が最小、エンティティ側が最大。組み合わせは ||・○|・|<・○< の4つで全部。実線は識別、点線は非識別。この4文が頭にあれば、どのER図でも読めます。
記号を暗記するより、繰り返し読んでみることが大事です。もうひとつ言っておくと、記号を完璧に知らなくても始めるのに支障はありません。DDLをWorksCove ERDに貼り付ければリレーション線はカラスの足の記法どおりに描かれて出てくるので、その図をこの記事の記号表と見比べながら読むのも良い練習になります。