実体関連モデル(じったいかんれんモデル、(英: entity-relationship Model、ERM)は、概念的データモデルの高レベルな記述を可能とするモデルの一種である。また、実体関連モデルによって具体的なシステムのデータモデルを図で表現したものを実体関連図(英: entity-relationship Diagram、ERD)あるいはER図と呼ぶ。本項ではピーター・チェンの1975年の論文で提唱された技法を中心に解説する。ただし、同様のアイデアはそれ以前から存在し、実体と関連を扱う様々な派生モデルが考案されている。

## 概要

ERモデルは、データベース、特に関係データベースを抽象的に表現する手法の1つである。関係データベースは表にデータを格納し、表内の一部のデータは他の表内のデータを指している。例えば個人情報のデータベースでは、ある個人のエントリが当人のいくつかの電話番号のデータを指している構成になっていることがある。ERモデルでは、その個人のエントリが1つの「実体」であり、電話番号も「実体」で、それら実体間に「一件の電話番号を持つ」という「関連」が存在するという見方をする。そういった実体や関連を設計する際に作られる図が実体関連図またはER図である。

三層スキーマをソフトウェア開発に使用する場合、三層それぞれに対応するERモデルが構築される。

情報システム設計の第一段階(要求分析)でこれを使い、必要な情報を洗い出し、それら情報をデータベースに格納する際の型を決定する。データモデリング技術は、任意の議論領域についてオントロジー(すなわち、使用する項目とその関連を分類し概観すること)を記述するのに使用可能である。データベースを基盤とする情報システムの設計では、概念データモデルを論理設計などと呼ばれる後の工程で関係モデルなどの論理データモデルにマッピングする。関係モデルはその後さらに物理的設計時に物理的モデルにマッピングされる。ただし、設計工程の呼び方は様々であることに注意されたい。

## 実体関連モデリング

### 構成要素: 実体、関連、属性

実体は、独立した存在として認識され、一意に識別されるものと定義できる。実体とは、ある領域の複雑さから抽象したものである。実体は、実世界のある面だけを取り出し、他の面を捨象したものである。

実体は家や自動車といった物理的な物体ということもあるし、住宅販売や自動車サービスといったイベントということもあるし、客単価や注文といった概念ということもある。実体という用語はよく使われるが、チェンによれば「実体」と「実体型」を明確に区別すべきである。実体型はカテゴリである。そして実体は、厳密にいえば1つの実体型のインスタンスである。1つの実体型には多数のインスタンスが存在するのが普通である。しかし、「実体」という用語で実体型も指すような使い方をすることが多い。

実体は名詞に対応すると考えることができる。例えば、コンピュータ、従業員、楽曲、数学的定理といった名詞である。

関連は2つの実体間の関係を捉えたものである。関連は2つ以上の名詞句を結び付ける動詞に対応すると考えることができる。例えば、企業とコンピュータの間の「所有する」という関連、従業員と部門の間の「監督する」という関連、アーティストと楽曲の間の「演奏するという関連、数学者と定理の間の「証明した」という関連などである。

このような言語的側面を利用したのが宣言型データベースクエリ言語 ERROLであり、自然言語の構成を真似ている。ERROLの意味論と実装は実体関連モデルの言語的側面を捉えた関係代数の一種「reshaped relational algebra」 (RRA)に基づいている。

実体と関連はどちらも属性 (attribute) を持つことができる。例えば、「従業員」という実体は「社会保障番号」(SSN) という属性を持つことがある。また、「証明した」という関連は(証明した)「日付」という属性を持つことがある。

全ての実体は(弱実体でない限り)、一意に識別可能な最低限の属性集合を持たなければならない。この属性の集合を実体の主キーと呼ぶ。

実体関連図はインスタンスとしての実体やインスタンス間の関連を表したものではなく、むしろ実体の集合と関連の集合を表したものである。例えば、ある特定の楽曲はインスタンスとしての実体であり、データベース内の全ての楽曲が実体の集合である。子どもと昼食の間に「食べた」という関連があるとき、データベース内の全ての「食べた」関連が関連の集合である。言い換えれば、関連の集合は数学における関係に対応し、個々の関連はその関係の個数に対応して存在する。

関連の集合上に濃度制約が設けられることもある。

### 自然言語とのマッピング

チェンは、自然言語とER図とのマッピングの経験則を次のように提案した。

### 役割

チェンの最初の論文で、関連とその役割 (role) についての例が示されている。彼が示した例は「結婚」関連と「夫」と「妻」という2つの役割である。役割とは、関連を持つ2つの実体について、関連から見たそれぞれの名称ということができる。結婚という関連において、夫という役割を演じる人物と、妻という役割を演じる人物がいる。これらの関連と役割は名詞である。

しかし、今では関連や役割の「名前」は動詞または動詞句にすることが多い。特に is-the-owner-of(-は-の所有者である)とか is-owned-by(-は-に所有されている)といった句を使うことが多い。これを名詞で表すなら「所有者」(owner) や「所有」(possession) である。

### 濃度

役に立つ改良も加えられてきた。チェンは役割と関連する相手側の濃度 (cardinality)、すなわち対応する実体の数を論じていた。Oracle Designer が採用している Barker-Ellis 記法では、役割の側の最小濃度と相手側の最大濃度(カラスの足)を採用している。

Meriseや Elmasri & Navatheなどでは、最小濃度も最大濃度も役割と同じ側に設定する傾向がある。最近の研究者ら(Feinerer、Dullea et al.)は、このような方式の方が2項を超えるN項関係にも一貫して適用できることを示した。

Dullea et al. によれば、UMLに見られるような相手側に濃度を記述する記法では、2項を超える多項関係の参加制約の意味論を効果的に表現できないとしている。

Feinerer でも同様にUMLで使われている相手側での濃度指定では問題が生じるとしている。Hartmann がそういった状況を調査した。

## ER図の様々な記法

チェンが実体関連モデルの記法として採用したのは、実体の集合を長方形で表し、(それ自体が属性や関連を持つことができる)第一級オブジェクトとしての関連を菱形で表すものだった。実体の集合が関連の集合と関与している場合、それらを直線で結ぶ。

属性は楕円で表され、1つの実体または関連の集合と直線で結ばれる。

濃度制約は次のように表現される。

- 二重線が参加制約 (participation constraint)、完全関係または全射を意味する。その実体の集合に含まれる全実体は、その関連の集合にある「少なくとも1つの」関連に関与していなければならない。
- 実体の集合から関連の集合への矢印がキー制約を意味する。すなわち単射であり、実体の集合にあるそれぞれの実体は、その関連の集合にある「高々1つの」関連に関与できる。
- 太い線がそれら両方、すなわち全単射を意味する。実体の集合にあるそれぞれの実体は、常に1つの関係に関与している。
- 属性名に下線をひいた場合、その属性が主キーであることを示す。実体や関連にそのような属性がある場合、その値は常にそれぞれに異なる。

属性を書き込むと図が混み合うので、省略されることが多い。他の描法では、実体の集合を表す長方形内にその実体の持つ属性を列挙することが多い。

関連する図の描画技法:

- バックマン線図
- Barker's Notation
- EXPRESS
- IDEF1X
- Martin notation
- (min, max)-notation (Jean-Raymond Abrial,1974)
- UMLのクラス図
- Merise
- Object-Role Modeling (ORM)

### Crow's Foot (カラスの足)記法

Crow's Foot(カラスの足)記法は、Barker's Notation、SSADM、IE で使われている。その場合、実体を矩形で表し、関連は矩形同士を結ぶ直線で表される。その直線の両端の形状によって関連の濃度を表現する。

この記法は1980年代にCACIがコンサルタント業務で使っていた。Richard Barker を含むCACIのコンサルタントらがオラクルイギリス支社に移籍し、CASEツールを開発。そこでこの記法を採用したことで広く知られるようになった。カラスの足記法を使っているツールとしては、ARIS、System Architect、Visio、PowerDesigner、Toad Data Modeler、DeZign for Databases、Devgems Data Modeler、OmniGraffle、MySQL Workbench、SQL Developer Data Modeler などがある。CAテクノロジーズの CA Gen もこの記法を採用している。

## ER図作成ツール

ER図を描画する様々なツールが存在する。ERモデルやSQLを入力としてER図を生成し、データベースを分析できるフリーソフトウェアとして MySQL Workbench、Open ModelSphere(オープンソース)がある。ER図からデータベースやアプリケーション層のコード(Webサービス)を生成できるフリーウェアのERツールとして RISE Editor がある。SQL Power Architect はプロプライエタリだが、フリーなバージョンもある。

プロプライエタリなER図描画ツールとしては、Avolution、dbForge Studio for MySQL、ER/Studio、ERwin、MagicDraw、ModelRight、Navicat Data Modeler 、OmniGraffle、Oracle Designer、PowerDesigner、Rational Rose、Sparx Enterprise Architect、SQLyog、IBM Rational System Architect、Toad Data Modeler、Visual Paradigm、GitMind などがある。

単に描画だけが可能なフリーソフトウェアの描画ツールもある。SQLの生成といった機能はない。例えば、label=Creately、yEd、LucidChart、Calligra Flow、Dia などがある。

## ERと意味論的モデリング

ERモデリングを考案したピーター・チェンは、その論文で次のように述べている。

これは、古代ギリシアの哲学者ソクラテス、プラトン、アリストテレスからパース、フレーゲ、ラッセルに始まる現代の認識論・記号学・論理までの流れを踏まえた上での言葉である。プラトンのイデア論では、不変の範型があるとし、それらの関係を論じている。1976年の論文でチェンは実体関連モデルと様々なレコードモデリング技法を明確に対比させて次のように記している。

この考え方を支持する人々もいる。

意味論的モデルは概念のモデルであり「プラットフォームに依存しないモデル」である。また、内包的なモデルである。ルドルフ・カルナップ以来、次のようなことが常識となっている。

外延的モデルは、特定の方法論やテクノロジーの要素群にマッピングされるもので、「プラットフォーム固有のモデル」である。UML仕様においてクラスモデルの関係は外延的だと明確に記されており、そのことは仕様上さまざまな装飾が追加されている点からもUMLの元になった「意味論モデリング言語」群が提供したものからも自明である。

## 限界

- ERモデルは関係データベースで表現されることが可能な情報を扱うことが多い。その場合、情報の関連構造だけを扱う。
- 関係モデルで表現されない情報を扱うのは難しい。例えば半構造データなどである。
- 多くの場合、システムに格納される情報のとりうる変化は自明ではなく、明確な仕様を定めるのに十分な重要性がある。
- ERモデリングはそのような変化をも表現できるよう拡張が試みられており、ピーター・チェンもその方向性を支持している。例えば、Anchor Modeling がある。別の対策としてプロセス・モデリング技法を使って変化を個別にモデル化する方法がある。また、システムの他の観点を表現する追加技法を使うこともできる。実際、UMLではERモデルは14の各種モデリング技法の1つに過ぎない。
- ERモデリングは一から情報を指定していくのに向いている。したがって新規システム設計やスタンドアロン型情報システムには適しているが、データ表現の詳細が決まっている既存の情報源との連携にはあまり役に立たない。
- ERモデリングは関係データベースを使ったシステムで主に使われ、他のシステムではたとえ原理的に問題なくとも滅多に使われない。これは、関係データベースを直接サポートしたツール群が豊富だということが影響している。
- Brodie and Liu の調査によれば、フォーチュン100企業10社で実体関連モデリングを使った例が全く見られなかったという。Badia and Lemire ではその原因を、指導の欠如だけでなくデータ統合サポートなどの利点の欠如もあるとしている。
- 拡張実体関連モデル(EERモデリング)はERモデリングには欠如していたいくつかの概念を導入しており、is-a関連のようなオブジェクト指向分析設計と密接に関連した概念も導入している。
- 時制データベースのモデリングでは、実体関連モデルに様々な拡張を施す必要がある。また、OLAPで使われる多次元データベースにも適さない。