参加制約 (必須参加 / 任意参加) とは

まず身近な例で: 「0 人の部署」と「配属前の新入社員」を認めるか

参加制約 (optionality) を理解する一番簡単な問いは、以下の 2 つ:

• この会社は、所属する社員が 0 人の部署（新設したばかりで人事異動を待っている部署）の存在を認めますか？
• この会社は、どの部署にもまだ所属していない新入社員（配属前の内定者）をシステムに登録できますか？

「0 個も許容する」= 任意参加、「必ず 1 個以上」= 必須参加。 つまり参加制約は「相手が最低 何個 必要か」の指定で、カーディナリティ が「最大基数」なら 参加制約は 最小基数。両方セットで初めて関連の意味が完成する。

ER 図での参加制約の記号

IE 記法 (crow's foot) では、線の端の記号で表す:

• 縦棒 (|) — 必ず 1 (必須参加)
• 円 (○) — 0 も許容 (任意参加)

試してみる: 円 (○) と縦棒 (|) の切り替えで業務ルールがどう変わるか

カーディナリティ ページ と同じ 3 シナリオを、今度は 下限側の記号 (○ vs |) のみ 切り替えられる形で用意した。 上限側の記号 (鳥足の有無) は各シナリオの業務仕様に合わせて固定してある。 「0 個も許すのか、必ず 1 個以上必要か」の差が、現実世界のどのルールに直結しているかを試してほしい。

参加制約を DB 上で表現する: FK 制約

参加制約は ER モデル層 の設計仕様であって、そのままでは DB は何も強制してくれない。 これを実装層で担保する主な手段が FK 制約 (外部参照制約)。 FK 列の NOT NULL / NULL 許可 の使い分けで、参加制約を DB のスキーマに落とし込む:

• 必須参加 → FK 列を NOT NULL にする (相手を必ず持たせる)
• 任意参加 → FK 列を NULL 許可 にする (相手を持たない状態を許す)

ただし FK 制約が保証するのは「参照した先が存在すること」だけで、「必ず参照すること」まで踏み込まない。 任意参加は NULL 許可 だけで足りるが、必須参加を厳密に強制したければ NOT NULL + 挿入時トリガや業務ルールのバリデーションを追加する必要がある。 「参加制約 = 設計」「FK 制約 = 実装」と考え、後者は前者を DB に翻訳する道具、と押さえておくと混乱しない。

変なER図 との対応: 違和感 #9 参加制約の矛盾

変なER図 の「注文 —明細— 注文明細」の線を注意深く見ると、注文側 に |○ (最大 1、最小 0)、注文明細側 に 1..N (最大 N、最小 1) が並んでいる。 IE 記法として厳密に読むと:

• 注文明細側から: 「1 つの注文は明細を 1 件以上 必ず持つ」(必須参加)
• 注文側から: 「1 つの明細は親の注文を 0 or 1 個しか持たない」(任意参加、注文なしでも存在可)

この 2 つは 存在論的に両立しない。 「注文には明細が必ず 1 件以上ある」なら、その明細を逆から見れば必ず親の注文を持つ (= 最小 1) はず。 参加制約は片側だけで決まらず、両側の最小基数が整合していないと関連そのものが破綻する。

さらにこの線は 識別関係(弱エンティティを親に繋ぐ関連) なので、 「弱エンティティは親なしでは存在できない」という定義と親側 min=0 が真っ向から衝突する。 参加制約の矛盾は、関連の意味と組み合わさると設計そのものを崩壊させる。