弱エンティティと識別関係

まず身近な例で: 「注文書の 3 行目」だけを見せられたら？

紙の注文書を思い浮かべる。1 冊の注文書には表紙 (注文番号・注文日・顧客) があって、 本文に商品明細が何行か書かれている。ここで 「明細の 3 行目」だけを紙から切り取って渡すと、受け取った人は「これはどの注文の 3 行目ですか？」と聞き返したくなる。

「明細の 3 行目」は、注文書というコンテキストがないと存在意味を持たない。 こういう性質のエンティティを 弱エンティティ (weak entity) と呼ぶ。 親エンティティ (注文書) のキー (注文番号) を借りて初めて一意になる。

ER 図での見分け方 — 主キーの構造がすべて

弱エンティティかどうかは、視覚記号ではなく 主キーの構造 で決まる。 子側の主キーが親側の主キーを含んでいれば弱、独立の主キーだけで完結していれば強。

「注文明細」なら、主キーは (注文ID, 明細番号)。 明細番号だけでは「どの注文の 3 行目か」分からないので、 必ず親の 注文ID を含めて初めて世界の中で 1 行に絞れる。 この 「親のキーを借りないと一意にならない」 という性質そのものが、 弱エンティティの正体。親との関連は 識別関係 (identifying relationship) と呼ばれる (詳細は下の「対比 — 非識別関係の場合」節)。

だから弱エンティティは 名前で判断できない。 「配送先」「部屋」「注文明細」「扶養家族」— どれも一見独立のモノに見えるが、 意味的に親なしでは成立しないなら弱として扱い、主キーに親のキーを組み込む。 逆に、独立の意味を持つエンティティに親のキーを無理に押し込むのは過剰な結合で、設計としては筋が悪い。

弱と見抜くと、実装上の判断もいくつか自動的に決まる:

• 削除の連鎖: 親を消したら子も消す (FK に ON DELETE CASCADE) が原則
• 重複制御: 「同じ注文に同じ明細番号は 2 つない」が主キーで自動的に担保される
• 単独 SELECT の意味の薄さ: 明細だけを取り出しても業務的にはほぼ役立たず、常に親と JOIN される

(記法補足: Chen 記法 では弱エンティティを二重四角、識別関係を二重菱形で描く慣習があり、 IPA データベーススペシャリスト試験や大学の教科書ではこの表記に出会うことがある。 本サイトを含めモダンな作図ツールの既定である IE 記法 では特別な視覚記号を使わず、 上に書いた通り主キーの構造で判別する。以下の図もこの流儀で描く。)

弱エンティティ判定のチェックリスト

• 単独で識別できないか: 「明細番号 3」だけでは、どの注文の 3 行目か分からない
• 親を消したら意味を失うか: 注文が消えたら明細は存在意義がゼロ
• 親のライフサイクルに従属するか: 明細は注文と一緒に作られ、一緒に消える

3 つとも Yes なら弱エンティティ。1 つでも No があるなら、独立の強エンティティにする方が自然。

典型的な例

• 注文 — 注文明細 (主キー: 注文ID + 明細番号)
• 建物 — 部屋 (主キー: 建物ID + 部屋番号。「101号室」は建物なしには意味不明)
• 従業員 — 扶養家族 (主キー: 従業員ID + 家族番号)
• 会計期 — 期別集計 (主キー: 期ID + 集計項目)

対比 — 非識別関係の場合

弱エンティティを別名で呼ぶこともある。親との関連を 関連の側 から見たとき、 「親のキーが子の主キーの一部として継承される関連」を 識別関係 (identifying relationship) と呼び、 その対義の「親のキーは子の外部キーとしてだけ現れる (子の主キーには含まれない) 関連」を 非識別関係 (non-identifying relationship) と呼ぶ。 つまり 「弱エンティティ = 識別関係の子」「強エンティティ = 非識別関係の子」 と読み替えても意味は変わらない。

非識別関係の代表例が「顧客 — 注文」。顧客は 1 回だけ登録され、注文はその後何回も発生する。 注文の主キーは注文ID 単独で十分 (顧客なしでも注文行を一意に指せる)、顧客ID は FK として属性欄に持つだけ。 注文は顧客と一緒に消える存在ではなく、顧客が消えても履歴として残せる (実装上は SET NULL や履歴保持ルールで別途担保する)。

IE 記法では識別 / 非識別の線の見た目は同じ。判別は必ず子の主キー欄で行う。 IDEF1X 記法では 実線 (識別) と 破線 (非識別) で描き分ける慣習がある。 詳細は 記法比較ページ。

練習問題: 弱か強か

3 つの ER 図を用意した。それぞれ子側のエンティティが 弱エンティティ か 強エンティティ か、主キーの構造を見て判定してほしい。 本サイトは IE 記法なので視覚記号のヒントはない — 主キー欄が親のキーを含んでいるかどうかがすべて。

変なER図 との対応: 違和感 #7「配送先」が独立主キーで単独存在

変なER図 の「配送先」エンティティは、 意味的には 顧客に従属する弱エンティティ であるはず (「田中さんの自宅」「田中さんの会社宛」という 文脈なしには成立しない) にもかかわらず、実装が 「配送先ID」という独立の主キー になっており、 顧客エンティティとの関連さえ引かれていない。

正しくは「顧客 — 配送先」を関連で繋ぎ、配送先側の主キーを(顧客ID, 配送先連番) のような複合キーにする。 これで「田中さんの自宅」「田中さんの会社宛」を配送先ID なしで一意に区別できる。

変なER図 との対応: 違和感 #8「注文明細」の識別関係 PK 非継承

変なER図 の「注文明細」は、意味的には 注文に従属する弱エンティティ (識別関係の子) として描かれている。 にもかかわらず、注文明細の主キーは 「明細ID」単独 になっており、 親の 注文ID が主キーに継承されていない。

識別関係で親と繋がっている以上、注文明細の主キーは(注文ID, 明細番号) の複合キーになるべき。 設計意図 (識別関係 = 弱として扱う) と 主キー構成 (独立キー = 強として扱う) が矛盾している状態は、 読み手に「どっちが正しい？」と迷わせる。

#7 と #8 は、両方とも 「本来弱として扱うべきものを強のように描いた」という大枠は共通するが、破綻の出方は違う。#7 (配送先) は関連そのものが引かれておらず「親が誰か不明」の 関係欠落型。#8 (注文明細) は識別関係の線は引かれているのに主キーが親を継承しておらず 「意匠と実装の不整合」の PK 非継承型。 前者は「関連を追加する」、後者は「主キーを (親ID, 連番) の複合キーに直す」で修正する。