【データベース】親がいないと存在できない!ER図の「弱実体」|情報処理問題1000本ノック
データベースの概念設計(ER図)において、実体同士の深い絆を表す概念。「自分だけの力では番号を決められない」という、依存度の高い実体の性質を攻略しましょう。
1. 【 問題 】:ER図における実体の分類
【 問題 】 データベースの概念設計で用いられるER図(実体関連図)において、自分自身が持つ「属性(カラム)」だけではデータを一意に識別(特定)することができず、関連する「他の実体(親実体)」の主キーを取り込んで初めてデータを一意に識別できるようになる実体を何と呼ぶでしょうか?
① 強実体 (Strong Entity / 独立実体)
② 弱実体 (Weak Entity / 依存実体)
③ 連関実体 (Associative Entity)
④ サブタイプ実体 (Subtype Entity)
2. 正解:
正解: ② 弱実体(じゃくじったい)
3. 解説:親の番号を借りて、初めて一人前になるデータ
テーブル設計(データモデリング)において、単体では迷子になってしまう特殊な実体が存在します。それを表す言葉が弱実体(依存実体)です。
・会社のシステムで「社員(親実体)」テーブルと、その「家族(子実体)」テーブルがあるとします。
・家族テーブルに「第1子」「配偶者」という【続柄(属性)】だけを持たせても、日本中に同じデータが溢れてしまい、誰の家族なのか一意に識別できません。
・そこで、親である社員テーブルの主キー(例:社員番号「S001」)を借りてきて、【社員番号:S001 + 続柄:第1子】とセットにすることで、初めて世界に1人だけのデータとして一意に識別(特定)できるようになります。このときの「家族」のように、親なしでは識別できない実体を弱実体と呼びます。 ← ココが問題の正解!
※ER図の表記法(IE表記法やIDEF1Xなど)では、この弱実体を「角が丸い四角形」で表現したり、親との結びつきを「実線(依存リレーションシップ)」で表現したりして、普通のテーブルと明確に区別します。
★ ① 強実体(独立実体):弱実体の真逆です。他のテーブルに頼ることなく、自分自身の属性(例:社員番号、商品コードなど)だけでデータを一意に識別できる普通の主役級テーブルのことです。
★ ③ 連関実体:「多対多」の関連を持つテーブル同士(例:学生と授業)を結合するために、間に挟む「履修登録」のような中間テーブル(交差実体)のことです。
★ ④ サブタイプ実体:「社員」という共通データ(スーパータイプ)に対して、「正社員」「契約社員」のように、特定のグループだけに存在する固有の属性を小分けにした子テーブルのことです。
1. 理解のコツ: 「ホテルの部屋番号と、そこに置かれたアメニティ」に例えてみましょう。
・ホテルそのものは「強実体」です。「101号室」というだけで部屋を特定できます。
・しかし、部屋の中にある「ベッド」は、単に「ベッドA」という名前(属性)だけでは、どこの部屋のベッドか分かりません。「101号室(他の実体)の、ベッドA」という関連があって初めて、清掃員が一意に識別できますよね。この、場所を借りないと特定できないベッドのような存在が弱実体です。
2. 試験対策の視点: 「自身の属性では一意に識別できない」「他の実体との関連において識別できる」という定義フレーズが来たら「弱実体(依存実体)」が一択です。基本情報や応用情報の午前試験では、リレーショナルデータベースの概念設計やER図の読み取り問題において、データの主従関係(親子関係)を正しく見抜くための必須知識として出題されます。
4. まとめ
「親となるテーブルの主キーを分け与えてもらう(依存する)ことで、ようやく自身のデータを1行に特定できるようになる子側の実体構造」。これが弱実体です。この関係性を正しくER図に表現することは、データの登録・削除ルール(親が消えたら子も消す、など)をシステムに実装する上での重要な設計図となります。