実体関連モデル

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

概要

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

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

概念データモデル: 詳細さという面では最も大まかだが、モデルセットに含めるべき全体像を明らかにするという役割を担う最も上位のERモデル。概念ERモデルは通常、組織が使用するマスタ参照データ実体を定義する。組織全体の概念ERモデルを開発することで、組織のデータアーキテクチャ（英語版）の文書化に役立つ。概念ERモデルは1つ以上の論理データモデルの基盤として使うことができる。概念ERモデルのその際の目的は、論理ERモデル間でマスタデータ実体の構造的メタデータの共通性を確立することにある。概念データモデルは、データモデル統合の基盤としてERモデル間の共通性確立に使われることもある。
論理データモデル: 異機種混合の単一のシステムを対象として論理ERモデルを構築するなら、概念ERモデルは特に必要とされない。論理ERモデルは概念ERモデルよりも詳細である。マスタデータ実体に加え、運用上および業務上のデータ実体も定義する。各データ実体を詳細化し、それらデータ実体間の実体関連を確立する。ただし、論理ERモデルの実装にはそれぞれ独立の技術が使用される。
物理データモデル: 1つの論理ERモデルに対応して1つ以上の物理ERモデルが作られる。物理ERモデルは通常、そのままデータベースとして実体化される。したがって物理ERモデルにはデータベースを作るのに十分な詳細さが必須であり、個々の物理ERモデルは対応するデータベース管理システムの仕様に影響される。物理モデルは通常、構造化メタデータをデータベース管理システム上の関係データベースオブジェクト（表、主キーなどの索引、外部キー制約などのデータベースの制約）として実装できるよう設計が進められる。物理ERモデルは関係データベースの改造の際にもよく使われる。

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

実体関連モデリング

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

自然言語とのマッピング

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

自然言語における品詞	ER構造
普通名詞	実体の型
固有名詞	実体
他動詞	関連の型
自動詞	属性の型
形容詞	実体の属性
副詞	関連の属性

役割

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

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

濃度

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

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

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

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

ER図の様々な記法

Crow's Foot（カラスの足）記法で2つの実体の関連を表現した図。"Song" の側の記号はゼロを含む不定個を意味している。"Artist" 側の記号は唯一であることを意味している。したがって、この図全体としては「アーティストは（ゼロかもしれない）不定個の楽曲を演奏する（ことができる）」ことを示している。

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

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

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

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

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

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モデリングを考案したピーター・チェンは、その論文で次のように述べている。

実体関連モデルは現実の世界が実体と関連から構成されるというさらに自然な見方を採用している。それは実世界についての重要な意味情報の一部を含んでいる。^[1]

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

データ構造図はレコード群の構成を表現したものであり、実体と関連を正確に表現したものではない。

この考え方を支持する人々もいる^[16]^[17]^[18]^[19]^[20]。

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

ある概念の完全な意味は内包と外延という2つの側面から成る。前者は世界を構成する全概念における概念の埋め込み、すなわち他の概念とのあらゆる関連の総体からなる。後者はその概念の指示的意味を確立するもので、実世界や可能世界にそれに対応するものが存在する。

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

限界

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

脚注

参考文献

ERモデルの基本はたいていのデータベースの教科書で触れられている。

Chen, Peter Pin-Shan (March 1976). “The Entity-Relationship Model - Toward a Unified View of Data”. ACM Transactions on Database Systems 1 (1): 9–36. doi:10.1145/320434.320440. [Original paper by Chen]
Peter Chen (2002) "Entity-Relationship Modeling: Historical Events, Future Trends, and Lessons Learned" in Software pioneers, pp. 296-310, Springer-Verlag, ISBN 3-540-43081-4 [A retrospective]

ERベースのモデリングに関する論文:

Richard Barker (1990). CASE Method: Entity Relationship Modelling, Addison-Wesley, ISBN 0201416964
Richard Barker (1990). CASE Method: Tasks and Deliverables, Addison-Wesley. ISBN 0201416972
Heikki Mannila, Kari-Jouko Räihä (1992). The Design of Relational Databases. Addison-Wesley. ISBN 0201565234
Bernhard Thalheim (2000). Entity-Relationship Modeling: Foundations of Database Technology. Springer. ISBN 978-3-540-65470-4
Sikha Bagui; Richard Earp (2011). Database Design Using Entity-Relationship Diagrams (2nd ed.). CRC Press. ISBN 978-1-4398-6176-9

外部リンク

ER図小暮仁（「経営と情報」に関する教材と意見）
Entity Relationship Modeling - Article from Development Cycles
Entity Relationship Modelling
An Entity Relationship Diagram Example
Case study: E-R diagram for Acme Fashion Supplies by Mark H. Ridley.
Logical Data Structures (LDSs) - Getting started by Tony Drewry.
Crow's Foot Notatition Introduction, Overview and Tutorial

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]

[16]

[17]

[18]

[19]

[20]

[21]

[22]

[23]

[24]

[25]

[26]

Search