實體-關係模型(或ER模型)描述特定知識領域中相關的事物。基本的ER模型由實體類型(對感興趣的事物進行分類)和指定實體之間可能存在的關係(那些實體類型的實例)組成。
在軟體工程中，為了執行業務流程，ER模型通常用於表示業務需要記住的內容。因此，ER模型變成了一個抽象的數據模型，它定義了一個可以在資料庫(通常是關係資料庫)中實現的數據或信息結構。
實體-關係建模是由Peter Chen開發的資料庫和設計，並在1976年發表了一篇論文。然而，這個想法的變體之前就已經存在了。一些ER模型顯示由一般化-專門化關係連接的超實體和子類型實體，[3]和ER模型也可用於特定領域本體的規範
使用Chen符號的MMORPG的實體關係圖。
介紹E-R模型通常是系統分析的結果，用於定義和描述業務領域中哪些流程是重要的。它沒有定義業務流程;它只以圖形形式表示業務數據模式。它通常以圖形形式繪製為方框(實體)，這些方框由表示實體之間的關聯和依賴關係的線(關係)連接。ER模型也可以用口頭形式表達，例如:一棟建築可以分為零個或多個公寓，但一個公寓只能位於一棟建築內。
實體不僅可以由關係來描述，還可以由附加的屬性(屬性)來描述，這些屬性包括稱為「主鍵」的標識符。為表示屬性以及實體和關係而創建的圖可以稱為實體-屬性-關係圖，而不是實體-關係模型。
ER模型通常作為資料庫實現。在簡單關係資料庫實現中，表的每一行表示實體類型的一個實例，表中的每個欄位表示屬性類型。在關係資料庫中，實體之間的關係是通過將一個實體的主鍵作為指針或「外鍵」存儲在另一個實體的表中來實現的
傳統上，ER/數據模型是在兩個或三個抽象級別上構建的。注意，下面的概念-邏輯-物理層次結構用於其他類型的規範，並且與軟體工程的三種模式方法不同。
概念數據模型這是最高級別的ER模型，因為它包含了最少的粒度細節，但是建立了模型集中所包含內容的總體範圍。概念ER模型通常定義了組織通常使用的主引用數據實體。開發企業範圍的概念ER模型對於支持組織的數據架構文檔化非常有用。
一個概念性的ER模型可以用作一個或多個邏輯數據模型的基礎(參見下面)。概念ER模型的目的是在一組邏輯ER模型之間建立主數據實體的結構元數據共性。概念數據模型可用於在ER模型之間形成共性關係，作為數據模型集成的基礎。
邏輯數據模型邏輯ER模型不需要概念ER模型，特別是當邏輯ER模型的範圍僅包括開發不同的信息系統時。邏輯ER模型比概念ER模型包含更多的細節。除了主數據實體之外，現在還定義了操作和事務數據實體。開發每個數據實體的詳細信息，並建立這些數據實體之間的關係。然而，邏輯ER模型是獨立於特定的資料庫管理系統開發的，它可以在該系統中實現。
物理數據模型可以從每個邏輯ER模型開發一個或多個物理ER模型。物理ER模型通常被開發為實例化為資料庫。因此，每個物理ER模型必須包含足夠的細節來生成資料庫，而且每個物理ER模型都依賴於技術，因為每個資料庫管理系統有所不同。
物理模型通常在資料庫管理系統的結構元數據中實例化，如關係資料庫對象(如資料庫表)、資料庫索引(如惟一鍵索引)和資料庫約束(如外鍵約束或共性約束)。ER模型通常還用於設計對關係資料庫對象的修改和維護資料庫的結構元數據。
信息系統設計的第一階段在需求分析期間使用這些模型來描述信息需求或將存儲在資料庫中的信息類型。數據建模技術可以用來描述某個興趣領域的任何本體(即使用術語及其關係的概述和分類)。在設計基於資料庫的信息系統時，概念數據模型在後期(通常稱為邏輯設計)被映射到邏輯數據模型，例如關係模型;這反過來又在物理設計期間映射到物理模型。注意，有時這兩個階段都被稱為「物理設計」。
實體關係模型兩個相關的實體
具有屬性的實體
與屬性的關係
主鍵
一個實體可以被定義為一個能夠被唯一識別的獨立存在的事物。實體是對領域複雜性的抽象。當我們談到一個實體時，我們通常指的是現實世界的某些方面，這些方面與現實世界的其他方面是不同的
實體是物理上或邏輯上存在的事物。實體可以是一個物理對象，如房子或汽車(它們以物理形式存在)，一個事件，如房屋銷售或汽車服務，或一個概念，如客戶交易或訂單(它們以概念的形式邏輯地存在)。雖然「實體」是最常用的一個術語，但在陳之後，我們應該真正區分實體和實體類型。實體類型是一個類別。嚴格地說，實體是給定實體類型的實例。實體類型通常有許多實例。因為術語實體類型有點麻煩，大多數人傾向於使用術語實體作為該術語的同義詞
實體可以被認為是名詞。例如:一臺電腦，一個僱員，一首歌，一個數學定理，等等。
關係捕獲實體之間的關係。關係可以被認為是動詞，連接兩個或多個名詞。例如:a擁有公司和電腦之間的關係，a管理員工和部門之間的關係，a表演藝術家和一首歌之間的關係，a證明數學家和一個猜想之間的關係，等等。
上面描述的模型的語言方面在模仿自然語言構造的聲明式資料庫查詢語言ERROL中得到了利用。ERROL的語義和實現基於重新構造的關係代數(RRA)， RRA是一種適應實體-關係模型並捕捉其語言方面的關係代數。
實體和關係都可以有屬性。示例:僱員實體可能具有社會保險號(SSN)屬性，而已證明的關係可能具有日期屬性。
每個實體(除非它是弱實體)必須有一組最小的惟一標識屬性，這稱為實體的主鍵。
實體關係圖不顯示單個實體或單個關係實例。相反，它們顯示實體集(同一實體類型的所有實體)和關係集(同一關係類型的所有關係)。例如:一首歌是一個實體;資料庫中所有歌曲的集合是一個實體集;孩子和午餐之間被吃掉的關係是單一的關係;資料庫中所有這些兒童-午餐關係的集合就是一個關係集合。換句話說，一個關係集合對應於數學上的一個關係，而一個關係對應於關係中的一個成員。
還可以指定關係集上的某些基數約束。
映射自然語言陳提出了將自然語言描述映射到ER圖的「經驗法則」:Peter Chen的「英語、漢語和ER圖」。
English grammar structureER structureCommon nounEntity typeProper nounEntityTransitive verbRelationship typeIntransitive verbAttribute typeAdjectiveAttribute for entityAdverbAttribute for relationship
物理視圖顯示數據的實際存儲方式。
關係、角色和基數在陳的原始論文中，他給出了一個關係及其作用的例子。他將一段關係描述為「婚姻」，並將其分為「丈夫」和「妻子」兩個角色。
一個人在婚姻(關係)中扮演丈夫，另一個人在同一婚姻中扮演妻子。這些詞是名詞。這並不奇怪;給東西命名需要一個名詞。
陳的術語也被用於早期的思想。一些圖表的線條、箭頭和魚尾紋更多的是源於早期的巴赫曼圖表，而不是陳的關係圖表。
陳模型的另一個常見擴展是將關係和角色「命名」為動詞或短語。
角色的命名用is的所有者和is所屬的短語來命名角色也變得很流行。這裡正確的名詞是owner和possession。因此，人扮演所有者的角色，汽車扮演佔有的角色，而不是人扮演所有者的角色，等等。
當從語義模型生成物理實現時，名詞的使用有直接的好處。當一個人與car有兩種關係時，就有可能產生像owner_person和driver_person這樣的名字，這是有意義的
基數對原始規範的修改是有益的。陳描述了四處查看的基數。順便說一句，在Oracle Designer中使用的Barker-Ellis符號使用同側表示最小基數(類似於可選性)和角色，但是查找最大基數(烏鴉腳)。(需要澄清)
在Merise，[6] Elmasri & Navathe[7]和其他[8]中，對於角色以及最小和最大基數都有對同側的偏好。最近的研究人員(Feinerer，[9] Dullea等人，[10])已經表明，當應用於n元關係大於2時，這是更連貫的。
在Dullea等人看來，「在UML中使用的『查看』表示法並不能有效地表示施加在關係上的參與約束的語義，這些關係的程度高於二進位。」
Feinerer說:「如果我們像使用UML關聯那樣在查找語義下操作，就會出現問題。」Hartmann[11]調查了這種情況，並展示了不同的轉換是如何以及為什麼會失敗。」(雖然上面提到的「簡化」是虛假的，因為兩個圖3.4和3.5實際上是相同的)，而且「正如我們在接下來的幾頁中看到的，這種交叉解釋引入了一些困難，這些困難阻止了簡單機制從二元關聯擴展到n元關聯。」
陳的實體-關係建模表示法使用矩形表示實體集，用菱形表示適合於一級對象的關係:它們可以有自己的屬性和關係。如果一個實體集參與了一個關係集，它們將被連接到一條線上。
屬性被繪製為橢圓，並與一條線連接到一個實體或關係集。
基數約束表示如下:
雙線表示參與約束、總體或滿射:實體集合中的所有實體必須參與關係集合中的至少一個關係;
從實體集到關係集的箭頭表示一個關鍵約束，即注入性:實體集的每個實體最多可以參與關係集中的一個關係;
粗線表示兩者，即雙射性:實體集合中的每個實體只涉及一個關係。
屬性的帶下劃線名稱表示它是鍵:與此屬性相關的兩個不同實體或關係總是具有此屬性的不同值。
屬性經常被省略，因為它們會使圖表混亂;其他圖表技術通常在為實體集繪製的矩形中列出實體屬性。
相關圖表的約定技術:
將同一關係表示為多個關係的各種方法。在每種情況下，圖表都顯示了一個人和一個出生地之間的關係:每個人都必須在一個地點出生，而且只能在一個地點出生，但是每個地點可能沒有或有更多的人出生在那裡。
兩個相關的實體顯示使用魚尾紋符號。在這個例子中，歌手和歌曲之間顯示了一個可選的關係;最接近歌曲實體的符號代表「0、1或多個」，而一首歌有「一個且只有一個」藝術家。因此，前者被理解為藝術家可以表演「零首，一首，或多首」歌曲。
烏鴉腳符號魚尾紋符號，其起源可追溯到戈登埃佛勒斯特(1976)的一篇文章，[12]用於巴克的符號，結構化系統分析與設計方法(SSADM)和信息技術工程。魚尾紋圖將實體表示為框，將關係表示為框之間的線。這些線兩端的不同形狀表示關係的相對基數。
在諮詢公司CACI中使用了魚尾紋符號。CACI的許多顧問(包括Richard Barker)後來都搬到了Oracle英國，在那裡他們開發了Oracle CASE工具的早期版本，並將這種表示法介紹給更廣泛的用戶。
使用這種表示法，關係不能有屬性。在必要時,關係提升為實體的:例如,如果需要捕捉藝術家表演歌曲,介紹了一個新的實體「性能」(屬性反映了時間和地點),和藝術家,歌曲的關係成為一個間接的通過性能(artist-performs-performance performance-features-song)的關係。
三個符號用來表示基數:
這個環代表「0」
破折號代表「1」
魚尾紋代表「許多」或「無限」
這些符號成對使用，表示一個實體在關係中可能具有的四種基數類型。符號的內部分量表示最小值，外部分量表示最大值。
環和破折號→最小零，最大一(可選)
破折號與破折號→最小一，最大一(強制)
環和魚尾紋→最小零，最大多(可選)
破折號和魚尾紋→最少一項，最多多項(強制)
模型可用性問題在使用建模的資料庫時，用戶可能會遇到兩個眾所周知的問題，其中返回的結果與查詢作者假定的結果不同。
第一個是「粉絲陷阱」。它與一個(主)表一起出現，該表以一對多的關係連結到多個表。這個問題的名稱來自於模型在實體關係圖中繪製時的樣子:從主表「展開」的連結表。這種類型的模型與星型模式類似，星型模式是數據倉庫中使用的一種模型。當試圖使用主表上的標準SQL計算聚合的總和時，會出現意外(和不正確)的結果。解決方案是調整模型或SQL。此問題主要發生在決策支持系統的資料庫中，查詢此類系統的軟體有時包括處理此問題的特定方法。
第二個問題是「鴻溝陷阱」。當模型表明實體類型之間存在某種關係，但某些實體之間不存在路徑時，就會出現鴻溝陷阱。例如，一個建築物有一個或多個房間，這些房間可以容納0或更多的計算機。人們希望能夠查詢該模型以查看大樓中的所有計算機。然而，目前沒有分配到房間的電腦(因為它們正在修理或在其他地方)不在列表中。建築和計算機之間的另一種關係是需要捕獲建築中所有的計算機。最後一個建模問題是由於未能在模型中捕獲現實世界中存在的所有關係。詳見實體-關係建模2。
實體關係和語義建模語義模型語義模型是概念的模型，有時被稱為「平臺無關模型」。這是一個內涵模式。自Carnap以來，最晚的是眾所周知的:[13]
「…概念的全部意義由概念的內涵和外延兩個方面構成。第一部分包括概念作為一個整體嵌入到概念的世界中，即所有與其他概念的關係的總和。第二部分確立了概念的指稱意義，即它在現實世界或可能世界中的對應物。
擴展模型擴展模型是映射到特定方法或技術元素的模型，因此是「特定於平臺的模型」。UML規範明確地聲明類模型中的關聯是擴展的，通過考慮規範提供的比任何先前候選的「語義建模語言」提供的更多的「裝飾」，這實際上是不言而喻的。UML作為數據建模符號，第2部分"
實體關係的起源ER建模之父Peter Chen在他的開創性論文中說:
實體-關係模型採用更自然的觀點，認為現實世界由實體和關係組成。它整合了一些關於現實世界的重要語義信息。」[1]
在他1976年的原始文章中，陳明確對比了實體關係圖和記錄建模技術:
數據結構圖是記錄組織的表示，而不是實體和關係的精確表示。
其他幾位作者也支持陳的項目:[14][15][16][17][18]
哲學對齊從古希臘哲學家蘇格拉底、柏拉圖和亞里斯多德(公元前428年)到現代認識論、符號學和邏輯學的皮爾斯、弗雷格和羅素，陳都符合他們的哲學和理論傳統。
柏拉圖本人將知識與對不變形式的理解(根據蘇格拉底的說法，這些形式大致上是許多類型的事物和屬性的原型或抽象表示)及其相互之間的關係聯繫起來。
限制ER假設可以在關係資料庫中方便地表示信息內容。它們只描述了此信息的關係結構。
它們不適用於信息不能以關係形式(需要引用)表示的系統，例如半結構化數據。
對於許多系統來說，對所包含的信息進行可能的更改是非常重要的，足以保證明確的規範。
一些(誰?作者擴展了ER建模，用結構來表示變化，這種方法得到了最初作者的支持;[19]是錨建模的一個例子。另一種方法是使用流程建模技術分別對更改進行建模。其他技術可以用於系統的其他方面。例如，ER模型大致對應於UML提供的14種不同建模技術中的1種。
即使在原則上合適的地方，ER建模也很少作為單獨的活動使用。原因之一是現在有大量的工具可以直接支持關係資料庫管理系統上的圖表繪製和其他設計支持。這些工具可以很容易地從現有資料庫中提取與ER關係圖非常接近的資料庫關係圖，並且它們提供了關於此類關係圖中包含的信息的可選視圖。
在一項調查中，Brodie和Liu[20]在十個財富100強公司的樣本中找不到一個實體-關係建模的實例。Badia和Lemire[21]將這種缺乏使用歸咎於缺乏指導，但也歸咎於缺乏好處，比如缺乏對數據集成的支持。
增強實體-關係模型(EER建模)引入了一些與面向對象設計密切相關的概念，而不是ER建模，比如is-a關係。
為了對時態資料庫建模，已經考慮了許多ER擴展。類似地，ER模型被發現不適合多維資料庫(用於OLAP應用程式);在這一領域還沒有出現主流的概念模型，儘管它們通常圍繞OLAP cube(在該領域內也稱為數據立方體)的概念
另請參閱Associative entity
Concept map
Database design
Data structure diagram
Enhanced entity–relationship model
Enterprise architecture framework
Value range structure diagrams
Comparison of data modeling tools
Ontology
Object-role modeling
Three schema approach
Structured-Entity-Relationship-Model
Schema-agnostic Databases
本文http://jiagoushi.pro/entity-relationship-model-0討論：請加入知識星球【首席架構師圈】或者加微信小號【jiagoushi_pro】或者加QQ群【11107777】公眾號