データベース構築でIDを降る前に”弱実体集合”を考える

Last updated at 2025-09-22Posted at 2025-09-01

【DB設計】「全部idでいいや」は危険信号！"弱実体"でモデルを綺麗にする思考法

データベース初心者が設計をしていると、こんな状況に陥ることがあります。

とりあえず全部に id を振ったら…
- 課題マスタ を作ったら、同じ科目 1 に対して「課題番号 1」が複数できてしまった。
現場の言葉とモデルがずれている…
- 現場では「注文ID 100 の明細 3 番目」のように呼んでいるのに、モデル上はその「3番目」という情報がどこにもない。
親を消したら、子が迷子に…
- 注文 レコードを削除したら、関連する 注文明細 だけがデータベースに取り残されてしまった。

これらの問題は、弱実体集合 という概念をモデルに反映させることで解決できます。

ほとんどのテーブルはこれに該当します。「自分のキーだけで意味が完結している」のが特徴です。

モデルを考えるとき、まず基本となるのがこの強い実体です。

ここからが本題です。弱い実体は、以下の2つの特徴を併せ持ちます。

子は、親が存在して初めて意味を持ちます。

本とページ
本という「親」がなければ、「25ページ目」という「子」も存在しません。
ブログ記事とコメント
記事という「親」が削除されたら、それに付いたコメントという「子」だけが残るのは不自然。
もし親が削除されたら、子も一緒に削除されるべき運命共同体です。これが「孤児レコード」を防ぐための重要な考え方です。

子の識別には、親のキーが必須です。
「どの親に属する、何番目の子か」で特定するのが、業務上の自然な考え方であることが多いです。

🏢 建物（親） → 🚪 部屋（子）
- 「部屋番号 101」だけでは、どのマンションか分かりません。
- 建物ID: A-101 + 部屋番号: 101 のように、セットで初めて一意に特定できます。
🛒 注文（親） → 🧾 注文明細（子）
- 行番号: 1 だけでは、どの注文の明細か分かりません。
- 注文ID: 12345 + 行番号: 1 で初めて意味を持ちます。

💡 業務での典型例

ある実体（テーブル）を弱実体としてモデリングすべきか迷ったら、この2つの質問を自問自答してみてください。

存在の質問： その子は、"親"なしで存在できますか？
- → No（例：注文がないのに注文明細は存在しない）
識別の質問： 業務上、「親のID」と「子の中の番号」の組み合わせで一意に識別されていますか？
- → Yes（例：「注文123の明細3番」と呼んでいる）

両方が "Yes" なら、それは弱実体として扱うのが最も自然です。

自分も実体集合の概念を初めて耳にした時こう考えました。
「order_details テーブルに id という連番を振れば、それで一意になるから問題ないのでは？」

これは半分正解で、半分危険な考え方です。
内部的な一意性を保証する id (サロゲートキー) は便利ですが、それだけではモデル上のルールが表現しきれません。

モデルは、業務上のルールを表現することが第一の目的です。弱実体の概念は、この「親と子の関係性」「業務上の識別方法」というルールを明確に定義するためにあります。

強実体集合：（例：学生）
- 自分自身の属性だけで、個々のレコードを一意に特定できる集団。
- 例：「学籍番号」さえあれば、特定の学生が誰なのか分かる。
- 弱実体集合以外は全て強実体集合と考えて良い
弱実体集合：（例：注文明細）
- "親"となる実体のキーを借りないと、個々のレコードを一意に特定できない集団。
- 例：「部屋番号 101」だけではどの建物か不明。「建物ID + 部屋番号」で初めて一意になる。