女性向けエンジニアスクール
3秒でわかる
業務の中で情報を記録しておきたい対象そのもの。会員や注文などを指し、DB 設計ではおおむね 1 つの表として形になります。
もう少し詳しく
どういうものか
エンティティは、業務の中で情報として記録しておきたい対象を指す。会員、商品、注文、貸出のように、独立して数えられて、それぞれを区別する必要があるものがこれにあたる。ER 図では四角形で描かれ、多くの場合そのままデータベースの 1 つの表になる。エンティティが持つ個々の情報 (氏名、価格など) は属性と呼ばれる。
なぜ必要か
設計の最初に、何を独立した表として持つかを決めなければ、後の作業がすべてぶれる。注文の中に商品名や単価をそのまま書き込む形にすると、商品名が変わったときに過去の注文を全部書き換えることになり、書き換え漏れが矛盾として残る。記録したい対象を切り出しておくと、変更が一か所で済む。
具体例
図書館の貸出を扱う場合、対象は次のように分かれる。
[会員] ---< [貸出 ] >--- [蔵書]
会員ID 貸出ID 蔵書ID
氏名 会員ID 書名
連絡先 蔵書ID 著者
貸出日表として書き起こすと次のようになる。
CREATE TABLE members (
member_id INT PRIMARY KEY,
name VARCHAR(100) NOT NULL
);
CREATE TABLE loans (
loan_id INT PRIMARY KEY,
member_id INT NOT NULL,
book_id INT NOT NULL,
loaned_on DATE NOT NULL,
FOREIGN KEY (member_id) REFERENCES members(member_id)
);つまずきやすいところ
属性とエンティティの区別で迷いやすい。判断の目安は、それ自体を一覧にしたいか、独自の情報を後から足したくなるかになる。住所は当初ただの文字列でも、都道府県ごとに集計したくなった時点で切り出す価値が出る。
もう一つ、会員と蔵書のように多対多の関係を、2 つの表だけで表そうとして詰まる例が多い。上の貸出のように、関係そのものを表として立てると素直に収まる。この表は貸出日という固有の情報も持てる。
似た用語との違い
エンティティは設計上の概念で、テーブルはそれをデータベース上に実装した形になる。インスタンスは、そのエンティティの具体的な 1 件 (会員番号 1023 の佐藤さん) を指す。
覚え方
「一覧画面を作りたくなるもの」はだいたいエンティティになる。会員一覧、注文一覧は作るが、氏名だけの一覧は作らない。迷ったら、その対象を単独で検索したくなるかどうかを考える。
