エンティティ (実体) とは

まず身近な例で: 表の 1 行を「何」にするか

Excel か Google Sheets で生徒の表を作るとき、いちばん最初に決めるのは「1 行を何にするか」。生徒 1 人 = 1 行にするのか、 生徒とクラス担任のセット = 1 行にするのか、あるいは日々の出欠 = 1 行にするのか、 で表の意味も列も全部変わる。この 「1 行にしたい単位」 こそが、 ER 図でいう エンティティ。

エンティティは実世界の名詞そのものではない。 「システムが区別したい単位」だ。生徒 A と生徒 B を区別したいから「生徒」がエンティティになる。 「日本語」と「英語」を区別したいなら「言語」もエンティティ。区別する必要がなければ、単なる属性で終わる。

ER 図でのエンティティの描き方

ER 図では四角い箱で描き、箱の中に「エンティティ名 (通常は名詞、単数形が慣例)」を上段、 「属性のリスト」を下段に書く。主キー (行を一意に見分けるための列) には下線を引くのが IE 記法の慣習。

エンティティにするか、属性にするかの判断基準

現場で迷うのは、「これは属性か、それとも独立のエンティティか」 の判断。 以下の 3 点のうちどれかに Yes なら、独立エンティティとして切り出したほうがよい:

• 複数値を持ちうるか — 「生徒の履修科目」は複数持てる → 独立エンティティ「履修」に切り出す
• 独立にライフサイクルを持つか — 「担任」は生徒と別に管理されている (異動・退職・引き継ぎがある) → 別エンティティ「教員」に切り出す
• 複数の他のエンティティから参照されるか — 「教員 (担任)」を学級からも、履修からも、成績表からも参照する → 独立エンティティ「教員」を用意して、 複数のエンティティから FK で参照する構造にする

逆に、「生徒の血液型」のような 1 対 1 で単一値・独立管理も参照もされない データは属性で十分。 余計な箱を作らないほうが図はシンプルになる。

変なER図 との対応: 違和感 #2「顧客」の属性欄破綻

変なER図 の「顧客」エンティティには、注文履歴JSON、カート内商品ID配列、レビュー全て、血液型 … と粒度もライフサイクルも違うものが並んでいる。

• 注文履歴 は複数値を持ち、注文ごとに独立して管理される → 別エンティティ「注文」「注文明細」に切り出すべき
• レビュー全て は複数属性の塊 (評価・本文・投稿日時…) → 別エンティティ「レビュー」に切り出すべき
• カート内商品ID配列 は複数値そのもの → 別エンティティ「カート項目」との関連に切り出すべき

これらを 1 つのエンティティに詰め込むと、更新のたびに JSON の一部だけ書き換えて残りを壊すなど、第1正規形 (1NF) の違反となる問題も同時に起きる。 ER 図の粒度と正規化は表裏一体の話だ。

強エンティティと弱エンティティの導入

エンティティは 強エンティティ と 弱エンティティ の 2 種類がある:

• 強エンティティ: 自前の主キーだけで一意に識別できる。生徒 (学籍番号)、クラス (クラスID) など
• 弱エンティティ: 親エンティティのキーを借りて初めて一意になる。注文明細 (注文ID + 明細番号) など。 詳細は 弱エンティティ ページ

判定基準は 「親を消したら子は意味を持つか」。 注文を消したら明細に意味はない → 弱。生徒を消してもクラスは意味を持つ → 強。