實體-關系模型(或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元關聯。”

陳的實體-關系建模表示法使用矩形表示實體集，用菱形表示適合于一級對象的關系:它們可以有自己的屬性和關系。如果一個實體集參與了一個關系集，它們將被連接到一條線上。

屬性被繪制為橢圓，并與一條線連接到一個實體或關系集。

基數約束表示如下:

• 雙線表示參與約束、總體或滿射:實體集合中的所有實體必須參與關系集合中的至少一個關系;
• 從實體集到關系集的箭頭表示一個關鍵約束，即注入性:實體集的每個實體最多可以參與關系集中的一個關系;
• 粗線表示兩者，即雙射性:實體集合中的每個實體只涉及一個關系。
• 屬性的帶下劃線名稱表示它是鍵:與此屬性相關的兩個不同實體或關系總是具有此屬性的不同值。
• 屬性經常被省略，因為它們會使圖表混亂;其他圖表技術通常在為實體集繪制的矩形中列出實體屬性。

相關圖表的約定技術:

• 巴赫曼符號
• 巴克的符號
• 表達
• IDEF1X
• 魚尾紋符號(也叫馬丁符號)
• (min, max)- 1974年Jean-Raymond Abrial的記譜法
• UML類圖
• Merise
• Object-role建模

將同一關系表示為多個關系的各種方法。在每種情況下，圖表都顯示了一個人和一個出生地之間的關系:每個人都必須在一個地點出生，而且只能在一個地點出生，但是每個地點可能沒有或有更多的人出生在那里。

兩個相關的實體顯示使用魚尾紋符號。在這個例子中，歌手和歌曲之間顯示了一個可選的關系;最接近歌曲實體的符號代表“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

原文：https://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model

本文：http://jiagoushi.pro/entity-relationship-model-0

討論：請加入知識星球【首席架構圈】或者飛聊小組【首席架構師智庫】

總結

以上是生活随笔為你收集整理的er图转为数据流程图_「数据架构」实体关系模型介绍的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。