データベース基本概念

エンティティ えんてぃてぃ

ER図データモデリングテーブル属性リレーションシップデータベース設計
エンティティについて教えて

簡単に言うとこんな感じ!

データベースの「管理したい対象のこと」だよ!たとえば「顧客」「商品」「注文」みたいに、システムで扱うモノや出来事1つ1つがエンティティなんだ。設計図を書くとき、まず「何を管理するの?」って決めるのがエンティティ選びってこと!


エンティティとは

エンティティ(Entity)とは、データベースで管理・記録する対象となる「もの」や「こと」を指します。日本語では「実体」と訳されることもあります。たとえば、顧客管理システムなら「顧客」「商品」「注文」「店舗」などがエンティティにあたります。現実世界に存在するモノ・人・出来事・概念のうち、「データとして記録しておく必要があるもの」がエンティティです。

データベース設計の入口となる工程では、**ER図(Entity-Relationship Diagram:実体関連図)を使って、エンティティ同士の関係を整理します。エンティティはER図の中で長方形のボックスで表され、そのエンティティが持つ情報(属性)や、他のエンティティとのリレーションシップ(関係)とともに描かれます。最終的にエンティティは、データベース上のテーブル(表)**として実装されます。

エンティティを正しく洗い出すことは、システム全体の品質に直結します。「何を管理するか」が曖昧なまま開発を進めると、後から「この情報が取れない」「テーブル構造を大幅に変えなければならない」といった手戻りが生じます。発注・要件定義の段階でエンティティの概念を理解しておくと、ベンダーとの打ち合わせがスムーズになります。


エンティティの構造と種類

エンティティは「名前」「属性」「主キー」の3要素で構成されます。

要素説明例(「顧客」エンティティの場合)
エンティティ名管理対象の名前顧客
属性(Attribute)そのエンティティが持つ情報顧客ID、氏名、メールアドレス、電話番号
主キー(Primary Key)各データを一意に識別するID顧客ID

エンティティの種類

エンティティにはいくつかの分類があります。

種類説明
強エンティティ単独で存在できるエンティティ顧客、商品、社員
弱エンティティ他のエンティティに依存して存在するエンティティ注文明細(注文がなければ存在しない)
連関エンティティ多対多の関係を解消するために作るエンティティ受講履歴(学生と講座の中間)

覚え方:「エンティティ=名詞」

エンティティを洗い出すコツは「業務の中に出てくる名詞を拾う」ことです。「顧客が商品を注文する」という文なら、「顧客」「商品」「注文」がエンティティ候補になります。動詞(注文する・購入する)は後でリレーションシップになります。「名詞=エンティティ、動詞=リレーション」と覚えておくと設計の入口で迷いにくくなります。


歴史と背景

  • 1970年 — Edgar F. Codd(エドガー・コッド)がリレーショナルデータベースの概念を論文で発表。データを表形式で管理するという考え方が登場
  • 1976年 — Peter Chen(ピーター・チェン)がER モデル(実体関連モデル)を提唱。エンティティ・属性・リレーションシップという3つの要素でデータ構造を記述する手法を確立
  • 1980年代 — Oracle・IBM DB2 などのリレーショナルデータベース管理システム(RDBMS)が普及。ER図によるデータベース設計が標準手法となる
  • 1990年代 — UML(統一モデリング言語)が登場し、クラス図がER図の役割を補完。オブジェクト指向設計とデータベース設計が融合し始める
  • 2000年代以降NoSQLデータベースが台頭するが、業務系システムではRDBMSが引き続き主流。エンティティ設計の重要性は変わらず

エンティティ・属性・リレーションシップの関係

エンティティは単独では意味が完結しません。属性(持つ情報)とリレーションシップ(他エンティティとの関係)が揃って初めてデータモデルになります。

顧客 🔑 顧客ID 氏名 メールアドレス 電話番号 ← 強エンティティ (単独で存在可能) 注文 🔑 注文ID 注文日時 合計金額 ステータス ← 連関エンティティ (顧客と商品を結ぶ) 商品 🔑 商品ID 商品名 価格 在庫数 ← 強エンティティ (単独で存在可能) 1 対多 対多 🔑 主キー(黒背景)はテーブルの各行を一意に識別する。エンティティごとに必ず1つ必要

上の図のように、エンティティはそれぞれ「属性(持つ情報)」と「主キー(識別子)」を持ち、リレーションシップ(関係の線)でつながります。「顧客」1人が「注文」を複数持ち(1対多)、「注文」は「商品」を複数含む(多対多)という構造が、システムの骨格になります。

エンティティとテーブルの対応

ER図で設計したエンティティは、そのままデータベースのテーブルになります。

エンティティ「顧客」
  ↓ データベース上では
テーブル「customers」
  ┌──────────┬────────┬─────────────────────┬──────────────┐
  │顧客ID    │氏名    │メールアドレス       │電話番号      │
  ├──────────┼────────┼─────────────────────┼──────────────┤
  │C001      │山田太郎│yamada@example.com   │090-1234-5678 │
  │C002      │鈴木花子│suzuki@example.com   │080-8765-4321 │
  └──────────┴────────┴─────────────────────┴──────────────┘
  ↑主キー(重複・NULLなし)

関連する規格・RFC

規格内容
ISO/IEC 9075(SQL標準)リレーショナルデータベースの国際標準。エンティティをテーブルとして定義するSQLの仕様を規定
IEEE 1320.2情報モデリング(IDEF1X)の標準。エンティティとリレーションシップの記法を規定

関連用語

  • ER図 — エンティティとリレーションシップを図で表したデータベース設計の設計図
  • 属性(Attribute) — エンティティが持つ具体的な情報・データ項目
  • 主キー — テーブル内の各行を一意に識別するための列(カラム)
  • リレーションシップ — エンティティ同士の関係性(1対1・1対多・多対多など)
  • テーブル — データベース上でエンティティを実装した行・列からなる表形式のデータ構造
  • 正規化 — データの重複や矛盾をなくすためにエンティティ・テーブルを整理する設計手法
  • データモデリング — エンティティを洗い出しER図を作成するデータベース設計プロセス全体