エンティティ（管理対象の実体）
データベースで管理対象となるデータの実体。
📌エンティティとは
エンティティとは、データベースで管理したい対象（実体）のことです。「社員」「商品」「注文」のように、業務の中で情報を記録したいものがエンティティになります。E-R図（＝実体と関連を描く設計図）では長方形で表します。
身近な例で考えると、図書館の管理に似ています。図書館で管理したい対象は「本」「会員」「貸出」などで、これらがそのままエンティティになります。何を記録したいかを書き出すことが、データベース設計の第一歩です。
上の図解では、エンティティ「社員」が属性を持ち、インスタンス（具体的な1件1件のデータ）で表が埋まっていく様子を示しています。最終的にエンティティは、データベース上では「表（テーブル）」として実装されます。
📌属性との関係
属性とは、エンティティが持つ性質や項目のことです。エンティティが「何を管理するか」だとすると、属性は「その対象のどんな情報を記録するか」を表します。
エンティティ「社員」なら、次のような属性が考えられます。
・社員番号：社員を識別する番号
・氏名：社員の名前
・所属部署：所属している部署名
・入社日：会社に入った日付
E-R図では属性を楕円で表し、エンティティの長方形と線でつなぎます。データベースの表に置き換えると、エンティティが表（テーブル）、属性が列（カラム）に対応します。表計算ソフトでいう「見出し行の項目」が属性だと考えると分かりやすいです。
📌インスタンスの考え方
インスタンスとは、エンティティに当てはまる具体的な1件1件のデータのことです。「社員」というエンティティに対して、「社員番号101の田中太郎さん」が1つのインスタンスになります。
エンティティとインスタンスの違いは、「種類」と「具体例」の関係です。
・エンティティ：管理対象の種類（型）。例：社員
・インスタンス：その種類に属する1件の実データ。例：田中さん、鈴木さん
表に置き換えると、エンティティが表、インスタンスが1行（レコード）に対応します。
身近な例で考えると、クラスの名簿に似ています。「生徒」というエンティティに対して、名簿に並ぶ「出席番号1番の山田さん」「2番の田中さん」がそれぞれインスタンスです。設計の段階ではエンティティ（型）を考え、実際にデータを登録するときにインスタンス（1件1件）が増えていく、と捉えると整理しやすいです。
🔗エンティティはER図の主役
ER図（Entity-Relationship Diagram＝エンティティ関連図）とは、データベースの構造を図で表す設計図です。ER図では、エンティティを長方形、エンティティ同士の関係（リレーションシップ）を菱形で描きます。
上の図は「社員は1つの部署に所属する」という関係を表しています。
・長方形（社員・部署）：エンティティ＝管理したい実体
・菱形（所属）：リレーションシップ（＝エンティティ同士のつながり）
・多・1（多重度）：「1つの部署に複数の社員が所属できる」という数の関係
エンティティがなければ、エンティティ同士の関係（リレーションシップ）も描けません。ER図でまずエンティティを書き出すことが、データベース設計の土台になります。ER図が完成すると、それぞれのエンティティをデータベースの表（テーブル）、リレーションシップを外部キー（＝表と表を結ぶ列）に変換してデータベースを作ります。
💡なぜエンティティを先に決めるのか
なぜエンティティを先に決めるのか。それは、「何を管理するか」が決まらないと「どんな情報を持つか（属性）」も「どう関係するか（リレーションシップ）」も決められないからです。
データベース設計は次の順で進めます。
・① 業務を理解する：「この会社では何を記録したいか」を把握する。例：受注管理システムなら注文・商品・顧客が対象
・② エンティティを決める：管理する実体（モノ・人・出来事）を書き出す。例：「顧客」「商品」「注文」
・③ 属性・関連を決める：各エンティティが持つ項目（属性）と、エンティティ同士のつながり（リレーションシップ）を整理する
身近な例で考えると、学校の名簿を作るときに、まず「生徒の名簿か、先生の名簿か、授業の記録か」という管理する対象（エンティティ）を決め、それから「名前・番号・クラス（属性）」を決める流れと同じです。エンティティを先に決めることで、設計全体の方向性がはっきりし、後から作り直す手間が減ります。
