カーディナリティ (多重度) とは

まず身近な例で: 部長は何人の部下を持てるか

「1 人の部長は複数の部下を持つ」「1 人の部下は 1 人の部長にしか報告しない」。 これがカーディナリティの直感。線の両端から見て、相手を 何個と結び付けているか を規定する制約。

よく見ると、上の一文には実は 2 つの情報が混ざっている:

• 上限: 相手を「多くて何個持てるか」(1 個までか、何個でも OK か)
• 下限: 相手を「最低何個持たないといけないか」(0 個で OK か、必ず 1 個以上か)

用語としては上限を 最大基数、下限を 最小基数 (= 参加制約) と呼ぶ。 ER 図の記号はこの 2 つを 1 本の線に同居させて描く仕組みになっている。

本ページでは主に 上限 (最大基数) の話 — 1:1、1:N、N:M の使い分け — を扱う。 下限側の話は 参加制約 ページ で詳しく解説する。

3 種類のカーディナリティ

1:1 (1 対 1)

両側ともに「多くて 1 個」。「社員」と「社員証」など、物理的な 1:1 対応があるときに使う。

この図が現実世界で語っているルール:

• 1 人の社員は必ず 1 つの社員証を持つ (社員証を持たない社員は存在しない)
• 1 枚の社員証は必ず 1 人の社員に紐付く (誰にも配られていない社員証は存在しない)
• 1 人の社員に社員証を 2 枚以上配布することはない
• 1 枚の社員証を複数人で使い回すことはない

1:N (1 対 多)

片側は「多くて 1 個」、もう片側は「複数個」。もっとも頻出のパターン。

この図が現実世界で語っているルール:

• 1 人の部下は必ず 1 人の部長に報告する (どの部長にも属さない部下はいない)
• 1 人の部長は必ず 1 人以上の部下を持つ (部下 0 人の部長は存在しない)
• 1 人の部下が同時に 2 人以上の部長に報告することはない
• 1 人の部長が持てる部下の人数に上限はない

N:M (多 対 多)

両側とも「複数個」。学生と履修科目、顧客と商品 (直接繋いだ場合) など。実装時には必ず連関実体 (中間テーブル) に分解する。 詳細は 多対多と連関実体 ページ。

この図が現実世界で語っているルール:

• 1 人の学生は 1 科目以上を履修する (履修必須)
• 1 つの科目は 1 人以上の学生に履修される (履修者必須)
• 1 人の学生が複数の科目を同時に履修できる
• 1 つの科目を複数の学生が同時に履修できる

IE 記法 (crow's foot) の記号早見

• 縦棒 (|) — 「必ず 1」の最小基数
• 円 (○) — 「0 も許容」の最小基数
• 鳥足 (<) — 「多 (N)」の最大基数

これらを線の両端に配置する。「入口から見て遠い側」の記号が「相手からの参加制約」で、 「入口から見て近い側」の記号が「相手からの最大基数」を表すという読み方の慣習になっている。

試してみる: 記号を変えると現実世界のルールがどう変わるか

3 つの ER 図を用意した。両端のボタンで 上限側の記号 (| と |＜) を切り替えると、 その図が表す業務ルール (O = 成立 / X = 成立しない) が動的に変わる。 下限 (円 vs 縦棒) は本ページでは触らず、 参加制約 ページで別途扱う。まずは「上限だけの差」が現実世界のどのルールに直結しているかを、実際に手を動かして確かめてほしい。

変なER図 との対応: 違和感 #4「EC サイトなのに 1:1」

変なER図 の「顧客 —発注— 注文」は、 顧客側が 縦棒 1 本 (最大 1)、注文側が 縦棒+円 (最大 1、最小 0)。 両端とも 最大基数が 1 に固定 されているので、「1 人の顧客は 最大 1 注文しか持てず、1 つの注文にも 最大 1 顧客しか紐付けられない」 という実質 1:0..1 (ほぼ 1:1 固定) の関係を強制している。

EC サイトなら本来は 1 顧客が複数回注文でき、購入履歴も保持したい。 カーディナリティの選択は業務ルールを直接規定するので、最初にここで間違えると その後のスキーマも実装も破綻する。「EC サイト」と「顧客-注文 1:1」は 1 秒でおかしいと気づけるようになりたい。