實體-關系模型(或ER模型)描述特定知識領域中相關的事物?；镜腅R模型由實體類型(對感興趣的事物進行分類)和指定實體之間可能存在的關系(那些實體類型的實例)組成。

在軟件工程中，為了執(zhí)行業(yè)務流程，ER模型通常用于表示業(yè)務需要記住的內(nèi)容。因此，ER模型變成了一個抽象的數(shù)據(jù)模型，它定義了一個可以在數(shù)據(jù)庫(通常是關系數(shù)據(jù)庫)中實現(xiàn)的數(shù)據(jù)或信息結構。

實體-關系建模是由Peter Chen開發(fā)的數(shù)據(jù)庫和設計，并在1976年發(fā)表了一篇論文。然而，這個想法的變體之前就已經(jīng)存在了。一些ER模型顯示由一般化-專門化關系連接的超實體和子類型實體，[3]和ER模型也可用于特定領域本體的規(guī)范

使用Chen符號的MMORPG的實體關系圖。

介紹

E-R模型通常是系統(tǒng)分析的結果，用于定義和描述業(yè)務領域中哪些流程是重要的。它沒有定義業(yè)務流程;它只以圖形形式表示業(yè)務數(shù)據(jù)模式。它通常以圖形形式繪制為方框(實體)，這些方框由表示實體之間的關聯(lián)和依賴關系的線(關系)連接。ER模型也可以用口頭形式表達，例如:一棟建筑可以分為零個或多個公寓，但一個公寓只能位于一棟建筑內(nèi)。

實體不僅可以由關系來描述，還可以由附加的屬性(屬性)來描述，這些屬性包括稱為“主鍵”的標識符。為表示屬性以及實體和關系而創(chuàng)建的圖可以稱為實體-屬性-關系圖，而不是實體-關系模型。

ER模型通常作為數(shù)據(jù)庫實現(xiàn)。在簡單關系數(shù)據(jù)庫實現(xiàn)中，表的每一行表示實體類型的一個實例，表中的每個字段表示屬性類型。在關系數(shù)據(jù)庫中，實體之間的關系是通過將一個實體的主鍵作為指針或“外鍵”存儲在另一個實體的表中來實現(xiàn)的

傳統(tǒng)上，ER/數(shù)據(jù)模型是在兩個或三個抽象級別上構建的。注意，下面的概念-邏輯-物理層次結構用于其他類型的規(guī)范，并且與軟件工程的三種模式方法不同。

概念數(shù)據(jù)模型

這是最高級別的ER模型，因為它包含了最少的粒度細節(jié)，但是建立了模型集中所包含內(nèi)容的總體范圍。概念ER模型通常定義了組織通常使用的主引用數(shù)據(jù)實體。開發(fā)企業(yè)范圍的概念ER模型對于支持組織的數(shù)據(jù)架構文檔化非常有用。

一個概念性的ER模型可以用作一個或多個邏輯數(shù)據(jù)模型的基礎(參見下面)。概念ER模型的目的是在一組邏輯ER模型之間建立主數(shù)據(jù)實體的結構元數(shù)據(jù)共性。概念數(shù)據(jù)模型可用于在ER模型之間形成共性關系，作為數(shù)據(jù)模型集成的基礎。

邏輯數(shù)據(jù)模型

邏輯ER模型不需要概念ER模型，特別是當邏輯ER模型的范圍僅包括開發(fā)不同的信息系統(tǒng)時。邏輯ER模型比概念ER模型包含更多的細節(jié)。除了主數(shù)據(jù)實體之外，現(xiàn)在還定義了操作和事務數(shù)據(jù)實體。開發(fā)每個數(shù)據(jù)實體的詳細信息，并建立這些數(shù)據(jù)實體之間的關系。然而，邏輯ER模型是獨立于特定的數(shù)據(jù)庫管理系統(tǒng)開發(fā)的，它可以在該系統(tǒng)中實現(xiàn)。

物理數(shù)據(jù)模型

可以從每個邏輯ER模型開發(fā)一個或多個物理ER模型。物理ER模型通常被開發(fā)為實例化為數(shù)據(jù)庫。因此，每個物理ER模型必須包含足夠的細節(jié)來生成數(shù)據(jù)庫，而且每個物理ER模型都依賴于技術，因為每個數(shù)據(jù)庫管理系統(tǒng)有所不同。

物理模型通常在數(shù)據(jù)庫管理系統(tǒng)的結構元數(shù)據(jù)中實例化，如關系數(shù)據(jù)庫對象(如數(shù)據(jù)庫表)、數(shù)據(jù)庫索引(如惟一鍵索引)和數(shù)據(jù)庫約束(如外鍵約束或共性約束)。ER模型通常還用于設計對關系數(shù)據(jù)庫對象的修改和維護數(shù)據(jù)庫的結構元數(shù)據(jù)。

信息系統(tǒng)設計的第一階段在需求分析期間使用這些模型來描述信息需求或?qū)⒋鎯υ跀?shù)據(jù)庫中的信息類型。數(shù)據(jù)建模技術可以用來描述某個興趣領域的任何本體(即使用術語及其關系的概述和分類)。在設計基于數(shù)據(jù)庫的信息系統(tǒng)時，概念數(shù)據(jù)模型在后期(通常稱為邏輯設計)被映射到邏輯數(shù)據(jù)模型，例如關系模型;這反過來又在物理設計期間映射到物理模型。注意，有時這兩個階段都被稱為“物理設計”。

實體關系模型

兩個相關的實體

具有屬性的實體

與屬性的關系

主鍵

一個實體可以被定義為一個能夠被唯一識別的獨立存在的事物。實體是對領域復雜性的抽象。當我們談到一個實體時，我們通常指的是現(xiàn)實世界的某些方面，這些方面與現(xiàn)實世界的其他方面是不同的

實體是物理上或邏輯上存在的事物。實體可以是一個物理對象，如房子或汽車(它們以物理形式存在)，一個事件，如房屋銷售或汽車服務，或一個概念，如客戶交易或訂單(它們以概念的形式邏輯地存在)。雖然“實體”是最常用的一個術語，但在陳之后，我們應該真正區(qū)分實體和實體類型。實體類型是一個類別。嚴格地說，實體是給定實體類型的實例。實體類型通常有許多實例。因為術語實體類型有點麻煩，大多數(shù)人傾向于使用術語實體作為該術語的同義詞

實體可以被認為是名詞。例如:一臺電腦，一個雇員，一首歌，一個數(shù)學定理，等等。

關系捕獲實體之間的關系。關系可以被認為是動詞，連接兩個或多個名詞。例如:a擁有公司和電腦之間的關系，a管理員工和部門之間的關系，a表演藝術家和一首歌之間的關系，a證明數(shù)學家和一個猜想之間的關系，等等。

上面描述的模型的語言方面在模仿自然語言構造的聲明式數(shù)據(jù)庫查詢語言ERROL中得到了利用。ERROL的語義和實現(xiàn)基于重新構造的關系代數(shù)(RRA)， RRA是一種適應實體-關系模型并捕捉其語言方面的關系代數(shù)。

實體和關系都可以有屬性。示例:雇員實體可能具有社會保險號(SSN)屬性，而已證明的關系可能具有日期屬性。

每個實體(除非它是弱實體)必須有一組最小的惟一標識屬性，這稱為實體的主鍵。

實體關系圖不顯示單個實體或單個關系實例。相反，它們顯示實體集(同一實體類型的所有實體)和關系集(同一關系類型的所有關系)。例如:一首歌是一個實體;數(shù)據(jù)庫中所有歌曲的集合是一個實體集;孩子和午餐之間被吃掉的關系是單一的關系;數(shù)據(jù)庫中所有這些兒童-午餐關系的集合就是一個關系集合。換句話說，一個關系集合對應于數(shù)學上的一個關系，而一個關系對應于關系中的一個成員。

還可以指定關系集上的某些基數(shù)約束。

映射自然語言

陳提出了將自然語言描述映射到ER圖的“經(jīng)驗法則”:Peter Chen的“英語、漢語和ER圖”。

English grammar structureER structureCommon nounEntity typeProper nounEntityTransitive verbRelationship typeIntransitive verbAttribute typeAdjectiveAttribute for entityAdverbAttribute for relationship

物理視圖顯示數(shù)據(jù)的實際存儲方式。

關系、角色和基數(shù)

在陳的原始論文中，他給出了一個關系及其作用的例子。他將一段關系描述為“婚姻”，并將其分為“丈夫”和“妻子”兩個角色。

一個人在婚姻(關系)中扮演丈夫，另一個人在同一婚姻中扮演妻子。這些詞是名詞。這并不奇怪;給東西命名需要一個名詞。

陳的術語也被用于早期的思想。一些圖表的線條、箭頭和魚尾紋更多的是源于早期的巴赫曼圖表，而不是陳的關系圖表。

陳模型的另一個常見擴展是將關系和角色“命名”為動詞或短語。

角色的命名

用is的所有者和is所屬的短語來命名角色也變得很流行。這里正確的名詞是owner和possession。因此，人扮演所有者的角色，汽車扮演占有的角色，而不是人扮演所有者的角色，等等。

當從語義模型生成物理實現(xiàn)時，名詞的使用有直接的好處。當一個人與car有兩種關系時，就有可能產(chǎn)生像owner_person和driver_person這樣的名字，這是有意義的

基數(shù)

對原始規(guī)范的修改是有益的。陳描述了四處查看的基數(shù)。順便說一句，在Oracle Designer中使用的Barker-Ellis符號使用同側表示最小基數(shù)(類似于可選性)和角色，但是查找最大基數(shù)(烏鴉腳)。(需要澄清)

在Merise，[6] Elmasri & Navathe[7]和其他[8]中，對于角色以及最小和最大基數(shù)都有對同側的偏好。最近的研究人員(Feinerer，[9] Dullea等人，[10])已經(jīng)表明，當應用于n元關系大于2時，這是更連貫的。

在Dullea等人看來，“在UML中使用的‘查看’表示法并不能有效地表示施加在關系上的參與約束的語義，這些關系的程度高于二進制?！?/p>

Feinerer說:“如果我們像使用UML關聯(lián)那樣在查找語義下操作，就會出現(xiàn)問題。”Hartmann[11]調(diào)查了這種情況，并展示了不同的轉換是如何以及為什么會失敗?！?雖然上面提到的“簡化”是虛假的，因為兩個圖3.4和3.5實際上是相同的)，而且“正如我們在接下來的幾頁中看到的，這種交叉解釋引入了一些困難，這些困難阻止了簡單機制從二元關聯(lián)擴展到n元關聯(lián)?！?/p>

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

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

基數(shù)約束表示如下:

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

相關圖表的約定技術:

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

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

兩個相關的實體顯示使用魚尾紋符號。在這個例子中，歌手和歌曲之間顯示了一個可選的關系;最接近歌曲實體的符號代表“0、1或多個”，而一首歌有“一個且只有一個”藝術家。因此，前者被理解為藝術家可以表演“零首，一首，或多首”歌曲。

烏鴉腳符號

魚尾紋符號，其起源可追溯到戈登埃佛勒斯特(1976)的一篇文章，[12]用于巴克的符號，結構化系統(tǒng)分析與設計方法(SSADM)和信息技術工程。魚尾紋圖將實體表示為框，將關系表示為框之間的線。這些線兩端的不同形狀表示關系的相對基數(shù)。

在咨詢公司CACI中使用了魚尾紋符號。CACI的許多顧問(包括Richard Barker)后來都搬到了Oracle英國，在那里他們開發(fā)了Oracle CASE工具的早期版本，并將這種表示法介紹給更廣泛的用戶。

使用這種表示法，關系不能有屬性。在必要時,關系提升為實體的:例如,如果需要捕捉藝術家表演歌曲,介紹了一個新的實體“性能”(屬性反映了時間和地點),和藝術家,歌曲的關系成為一個間接的通過性能(artist-performs-performance performance-features-song)的關系。

三個符號用來表示基數(shù):

• 這個環(huán)代表“0”
• 破折號代表“1”
• 魚尾紋代表“許多”或“無限”

這些符號成對使用，表示一個實體在關系中可能具有的四種基數(shù)類型。符號的內(nèi)部分量表示最小值，外部分量表示最大值。

• 環(huán)和破折號→最小零，最大一(可選)
• 破折號與破折號→最小一，最大一(強制)
• 環(huán)和魚尾紋→最小零，最大多(可選)
• 破折號和魚尾紋→最少一項，最多多項(強制)

模型可用性問題

在使用建模的數(shù)據(jù)庫時，用戶可能會遇到兩個眾所周知的問題，其中返回的結果與查詢作者假定的結果不同。

第一個是“粉絲陷阱”。它與一個(主)表一起出現(xiàn)，該表以一對多的關系鏈接到多個表。這個問題的名稱來自于模型在實體關系圖中繪制時的樣子:從主表“展開”的鏈接表。這種類型的模型與星型模式類似，星型模式是數(shù)據(jù)倉庫中使用的一種模型。當試圖使用主表上的標準SQL計算聚合的總和時，會出現(xiàn)意外(和不正確)的結果。解決方案是調(diào)整模型或SQL。此問題主要發(fā)生在決策支持系統(tǒng)的數(shù)據(jù)庫中，查詢此類系統(tǒng)的軟件有時包括處理此問題的特定方法。

第二個問題是“鴻溝陷阱”。當模型表明實體類型之間存在某種關系，但某些實體之間不存在路徑時，就會出現(xiàn)鴻溝陷阱。例如，一個建筑物有一個或多個房間，這些房間可以容納0或更多的計算機。人們希望能夠查詢該模型以查看大樓中的所有計算機。然而，目前沒有分配到房間的電腦(因為它們正在修理或在其他地方)不在列表中。建筑和計算機之間的另一種關系是需要捕獲建筑中所有的計算機。最后一個建模問題是由于未能在模型中捕獲現(xiàn)實世界中存在的所有關系。詳見實體-關系建模2。

實體關系和語義建模

語義模型

語義模型是概念的模型，有時被稱為“平臺無關模型”。這是一個內(nèi)涵模式。自Carnap以來，最晚的是眾所周知的:[13]

“…概念的全部意義由概念的內(nèi)涵和外延兩個方面構成。第一部分包括概念作為一個整體嵌入到概念的世界中，即所有與其他概念的關系的總和。第二部分確立了概念的指稱意義，即它在現(xiàn)實世界或可能世界中的對應物。

擴展模型

擴展模型是映射到特定方法或技術元素的模型，因此是“特定于平臺的模型”。UML規(guī)范明確地聲明類模型中的關聯(lián)是擴展的，通過考慮規(guī)范提供的比任何先前候選的“語義建模語言”提供的更多的“裝飾”，這實際上是不言而喻的。UML作為數(shù)據(jù)建模符號，第2部分"

實體關系的起源

ER建模之父Peter Chen在他的開創(chuàng)性論文中說:

實體-關系模型采用更自然的觀點，認為現(xiàn)實世界由實體和關系組成。它整合了一些關于現(xiàn)實世界的重要語義信息。”[1]

在他1976年的原始文章中，陳明確對比了實體關系圖和記錄建模技術:

數(shù)據(jù)結構圖是記錄組織的表示，而不是實體和關系的精確表示。

其他幾位作者也支持陳的項目:[14][15][16][17][18]

哲學對齊

從古希臘哲學家蘇格拉底、柏拉圖和亞里士多德(公元前428年)到現(xiàn)代認識論、符號學和邏輯學的皮爾斯、弗雷格和羅素，陳都符合他們的哲學和理論傳統(tǒng)。

柏拉圖本人將知識與對不變形式的理解(根據(jù)蘇格拉底的說法，這些形式大致上是許多類型的事物和屬性的原型或抽象表示)及其相互之間的關系聯(lián)系起來。

限制

• ER假設可以在關系數(shù)據(jù)庫中方便地表示信息內(nèi)容。它們只描述了此信息的關系結構。
• 它們不適用于信息不能以關系形式(需要引用)表示的系統(tǒng)，例如半結構化數(shù)據(jù)。
• 對于許多系統(tǒng)來說，對所包含的信息進行可能的更改是非常重要的，足以保證明確的規(guī)范。
• 一些(誰?作者擴展了ER建模，用結構來表示變化，這種方法得到了最初作者的支持;[19]是錨建模的一個例子。另一種方法是使用流程建模技術分別對更改進行建模。其他技術可以用于系統(tǒng)的其他方面。例如，ER模型大致對應于UML提供的14種不同建模技術中的1種。
• 即使在原則上合適的地方，ER建模也很少作為單獨的活動使用。原因之一是現(xiàn)在有大量的工具可以直接支持關系數(shù)據(jù)庫管理系統(tǒng)上的圖表繪制和其他設計支持。這些工具可以很容易地從現(xiàn)有數(shù)據(jù)庫中提取與ER關系圖非常接近的數(shù)據(jù)庫關系圖，并且它們提供了關于此類關系圖中包含的信息的可選視圖。
• 在一項調(diào)查中，Brodie和Liu[20]在十個財富100強公司的樣本中找不到一個實體-關系建模的實例。Badia和Lemire[21]將這種缺乏使用歸咎于缺乏指導，但也歸咎于缺乏好處，比如缺乏對數(shù)據(jù)集成的支持。
• 增強實體-關系模型(EER建模)引入了一些與面向?qū)ο笤O計密切相關的概念，而不是ER建模，比如is-a關系。
• 為了對時態(tài)數(shù)據(jù)庫建模，已經(jīng)考慮了許多ER擴展。類似地，ER模型被發(fā)現(xiàn)不適合多維數(shù)據(jù)庫(用于OLAP應用程序);在這一領域還沒有出現(xiàn)主流的概念模型，盡管它們通常圍繞OLAP cube(在該領域內(nèi)也稱為數(shù)據(jù)立方體)的概念

另請參閱

• 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图转为数据流程图_「数据架构」实体关系模型介绍的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。