利用 UML 进行实体关系建模
ER 建模的核心要素
ER 建模基于工件，可以是物理工件（比如 Product 或 Employee）的表示或者工件（比如 Order 或 Delivery）之間事務的表示。每個工件都包含關于自身的信息。ER 建模還專注于工件間的關系。這些關系可以是二元的（連接兩個工件），也可以是三元的（在幾個工件之間）。
ER 建模的四個必要元素是：
實體類型
實體類型是具有相同的結構并在企業內部獨立存在的一組工件。Employees 或 Products 就是實體類型的例子。
工件的一次出現就是一個實體。雖然實體類型描述了結構，但是實體本身標識了單個實例以及該實例的所有數據。Employee Joe Ward 就是 Employees 實體的一個例子。
圖 1 實體類型 Employees 和實體 Employees Joe Ward
?
屬性
實體類型的結構是用屬性定義的。屬性可看作實體類型的特征。Employee 的屬性可能有姓名、住址、社會安全號碼、出生日期、參加工作日期以及職務等。
實體通過屬性值來互相區分。由于實體的屬性可能有相同的值，如果這樣我們就不能區分某些特定的實體。因此，我們必須保證特定實體的屬性值與其他實體的屬性值不同。各個 Employee 都有一個唯一的姓名和社會安全號碼屬性組合。
Employee 的屬性值的一個例子是：Joe Ward，地址為 34 Main Road, Redmond, WA, 98053，社會安全號碼為 555-32-2222，出生于 1971 年 9 月 7 日，2001 年十月 1 日加入公司，是家電服務工程師。
圖 2 實體類型 Employee 的屬性以及實體 Employee Joe Ward 的屬性值
?
關系類型
實體類型描述了獨立工件，而關系類型描述了實體類型間有意義的關聯。更準確的說，關系類型描述了參與該關系的實體類型的實體可以構建一個有意義的關聯。實體間實際發生的關聯被稱為一種關系。
有一點我們必須理解：盡管我們已經定義了一種關系類型，但是這并不意味著每一對實體都構建了一種關系。關系類型規定了發生關系的類型。
關系類型的一個例子是 Employee 擁有 Product。在該例中，關系類型是 Owns。關系本身是：Employee Joe Ward 擁有一種產品--一部編號 320 TS 03880 的黃色電話機。
圖 3 雇員 Joe Ward 和序號 320 TS 03880 的產品之間的擁有關系類型和擁有關系
?
也有可能有一位名叫 Martin Weber 的雇員就沒有擁有電話機。
關系類型的屬性
關系類型還可以包含屬性。比如，Employee 和 Product 間的關系類型 Services 可以包含屬性 Date 和 Status，標識了服務的日期以及服務之后產品的狀態。
當在具體發生的服務中實現關系時，該關系的屬性值就被設置。關系的含義可能是：Joe Ward 在 2002 年 7 月 3 日為序號是 0462834 DF 4的黑色飲水機提供維修服務，并且使其建立了良好的工作狀態。
圖 4 services 關系類型的屬性，以及 Joe Ward 為序號 0462834 DF 4的產品提供服務的關系的屬性
?
ER 建模中的簡單約束
ER 模型中的實體、關系和屬性建立了一些定義企業結構的限制。該結構受被稱為"約束"的規則所限制。比如，一個雇員不可能與 100 多位客戶打交道。或者說，每個雇員必須與某一個恰當的部門關聯。
基數（Cardinality）
每個指定的關系類型都定義了在所有參與實體之間建立關系的可能性。大多數情況下，這不是必需的。比如，并非所有 Employee 都擁有全部 Product。
關系是雙向的，連接了兩種實體類型（Employees 和 Products）或者扮演兩個不同角色（作為經理的 Employee 和作為下屬的 Employee）的同一實體類型。關系還可以是多向的，連接兩個以上的實體類型。連接一個雇員、一個客戶和兩部話機的一次電話呼叫就是多向關系的一個例子。不管是哪種情況，每個實體類型都指定了針對該關系類型的基數。
通過每個實體最大的關系數目指定了最簡單的基數。如果只有一個部門參與和一個雇員關聯的關系，那么我們在連接器上寫一個 1。這意味著 Joe Ward 必須與一個并且只能是一個部門關聯。
其他的基數還有 Not Specified 或 Specified By a Variable。Not Specified 基數沒有限制。基數 Specified By a Variable （大部分為M 或N）同樣沒有基數限制。
當一個關系中的參與實體的上限和下限不同時，我們為上限和下限指定一對值，用括號括起來，之間用逗號分開，如（M，N）。根據上限的不同，可選的關系可以用（0，1）或（0，N）表示。
比如，足球隊和球員的關系為（11，18）。實體 Redmond Lions 足球隊與實體類型球員之間建立了一種關系，它由 Joe Coplen、David Archer、John Good、Kevin Hale、Ivan Komashinsky、Steven Cooper、Andrew Bliven、Art Lounsbery、Chad Beery、Randall DuBois、Ron Baghai、Lance Delo、Tito Magobet、Curtis Hrischuk 和 Ian Leslie 組成。
圖 5 足球隊和球員之間的關系規定這種關系只有在球隊球員在 11 到 18 之間時才有效
?
圖 6 有效的關系是 Redmond Lions 足球俱樂部和 15 名球員之間的隊員
?
足球比賽中經常有隊員由于不當的行為或者犯規而領到黃牌或紅牌。它們用實體類型 Cards 來表示。Cards 實體類型與基數為（0，N）的球員構建了一種 Received 關系。這意味著球員 David Archer 可能與三個 Card 實體有著 Received 關系，而 Lance Delo 卻一個也沒有。
?
圖 7 實體類型球員可能收到 0 個或者任意數目的 Card 實體類型：David Archer 收到 3 張牌，而 Lance Delo 一張牌也沒有收到。
依賴關系
依賴關系指的如果在一個關系中指定的其中一個實體不存在，那么另一個實體也沒有存在的意義。當依賴型實體（子類型）的各個實體依賴于超類型中對應父實體存在時，則一個實體類型依賴于另一個實體類型。
必須通過顯式地定義一個下限不為 0 的基數，或者定義個一個不為 0 的固定基數，來指定一個強制的依賴關系。實體類型結婚證就是兩個實體間依賴關系的一個例子，其中結婚證依賴于實體類型人。關系是結婚，并且結婚證和兩個人之間具有固定的依賴關系。
比如，實體結婚證 352647003 與實體 Joe Ward 和 Melinda Bell 具有固定的依賴關系。這意味著如果 Melinda Bell 或 Joe Ward 脫離該關系，那么至少從數據的角度來說，結婚證352647003就已經失效。
圖 8 建立在實體類型人之上的依賴性實體類型結婚證，以及實體結婚證 352647003 與 Melinda Bell 和 Joe Ward 間的依賴關系
?
特化和泛化
核心 ER 模型只定義了實體類型間的基本關系。雖然利用基本的實體和關系就可以很容易地表示商業機構中的大多數簡單數據結構，但是技術應用要求基于實體類型間的相似點和不同點的更復雜的結構。
特化和泛化
特化和泛化的目的在于重用與實體類型關聯的屬性和行為。
特化用于定義代表一個大型實體類型的一個特定部分的實體類型。特化后的實體類型從父實體類型繼承了結構和行為，比如業務規則。然而，雖然特化后的實體類型擴展了父結構或類型，但是這決不是說它小于父類型。
比如，Employee 是實體類型 Person 的一個特化，它需要實體類型 Person 的所有屬性和關系。另外還有一種叫做 Customer 的實體類型，它也是實體類型 Person 的一個特化。這兩種實體類型都具有 Person 的屬性，它們被看作 Employee 或 Customer 的屬性。因此在我們看 Customer 時，看到的是在實體類型 Person 和實體類型 Customer 中指定的所有屬性。
泛化是正好相反的工作流。泛化實體類型（或者父類型）代表所有子類型的共同結構和行為，并且包含了來自子實體類型的所有共同屬性。子實體類型具有父屬性的所有內容，并且還擁有自己的屬性。
泛化過程找出共同結構并在父實體類型中抽象出來。父實體類型通常在比較實體類型和簡化模型時的重構階段被找到。
雖然泛化僅利用面向對象或者對象關系數據庫就可以直接實現，但是泛化也可以通過使用外鍵的任何關系數據庫直接實現。
圖 9 實體類型 Customer 和實體類型 Employee 被泛化為人實體類型；反向過程就是特化
?
分類（Categorization）
特化是在實體上完成的，而分類則定義了關系類型上的約束條件。大多數情況下，分類是排他性的，這意味著根據實體狀態的不同，一個實體要么參與關系 A 要么參與關系 B。該狀態可能是一個屬性值（另一種關系的存在），或是某些外部狀態。
分類不改變實體的屬性。它需要數據訪問和操縱，來考慮分類中指定的約束條件。
交通工具就是分類的一個好例子。根據交通工具種類的不同，我們需要構建不同的關系。對于卡車，我們需要貨物信息，而對于公共汽車，我們需要乘客姓名。這些信息將被用于不同的關系中，以便為這些關系提供有意義的上下文。
圖 10 根據范疇的不同，卡車和公共汽車中的分類與實體類型 Cargo 和 Person發生關系
?
回頁首
ER 方法學的表示法
目前，ER 建模中使用了數種表示法，包括陳氏 ER、Barker ER Information Engineering (IE)和 IDEF1X，其中大部分還包含關系表示法。
對象角色建模（ORM）表示法也是 ER 方法學的一員。它能表達非常精確和完整的業務規則，并且可以用圖形闡述約束條件。不幸的是，這種詳細程度需要具有豐富細節的大量圖表。與 ORM 相關的問題是我們是否需要 ER 模型級的表示法精確度。ORM 表示法還很復雜，并且與其他表示法完全不同，因而那些沒有使用 ORM 的項目組成員很難理解它。
UML 是一種表示法語言，最初用于軟件設計，目前軟件設計已經擴展到業務和數據庫設計。UML 包括從分析到實施再到部署指定任何事項所必需的元素和圖表。通過使用幾種圖表和數十種元素，UML 還能表達不同程度的系統抽象。這是一項非常獨特的功能。但是，我們不需要知道 UML 的所有細節或者成功利用 UML 進行 ER 建模所需的所有視圖和表示。
為了更好理解 UML 在 ER 方法學中扮演的角色，我們將描述 UML 如何處理前面已經提到過的 ER 建模的核心元素。
UML 中的實體類型
如前所述，實體類型標識了具有同樣結構的一系列工件。實體類型是一幅藍圖，根據它能生成只能通過身份和狀態互相區別的任意數目的工件。
UML 中的相應元素是類。根據定義，類能夠隱藏內容，而實體具有可訪問接口。這看上去互相矛盾，但是實際上并非如此。UML 允許類利用公共屬性使結構公共化。
類一般用矩形表示，該矩形最多可分為三個部分：
第一部分包括類的原型和名稱。原型指的是 UML 中為了強化共同特征而進一步進行的元素分類。比如，所有可能帶有遺留原型的遺留類，可能將立即將遺留原型劃分為不可修改的一類。雖然類本身是類型的一種表示，但是我們用原型<<實體>>來劃分類型（<<…>>是用于指定原型的語法）。
第二部分包含具有類型和可見性的屬性。它還可以包含屬性的其他細節，比如初始值和原型。第二部分在縮略圖中可以省略。
第三部分是為類的行為保留的。由于實體類型不需要行為，所以我們就略過該部分。
根據抽象級別的不同，類可以用一個、兩個或三個部分顯式。
實體是實體類型的一個實例。在 UML 中，對象是類的實例。這意味著實體本身與對象相對應。
對象的表示來源于類的表示。最顯著的區別在于對象的名稱有下劃線，并且只有一個或兩個部分。
第一個部分包含以冒號隔開的可選的原型、對象名稱，以及派生類的名稱，之間用冒號隔開。至少必須指定其中一個名稱。第二部分包含相關屬性以及它們的值。
表示對象的最好的方法就是只使用一個部分，并將標識符 指定為對象的名稱。
圖 11 實體類型 Employees 和實體 553-32-2222 在 UML 中被顯示為類和對象
?
UML 中的屬性
實體的相關狀態和信息被作為對象的屬性存放。實體類型的屬性對于其他實體類型必須是可見的或者公開的。在類規格說明書中屬性是按照可見性、名稱和類型指定的。屬性的類型為分析類型。它在設計階段可能發生變更。
屬性是在類的第二部分指定的。它們包含對于實體總是"＋"（公開）的可見性規格說明書。名稱與類型之間用冒號隔開。
圖 12 具有公開屬性（社會安全號碼、姓名、地址、出生日期、加入日期和職位）的實體類型 Employees
?
UML 中的關系類型
在 UML 中類之間的關系是為類型而非實例指定的。關系雙方上的數字指定了基數：參與該關系的可能實例的數量。
關系的名稱是直接在關系行中指定的，用于標識該關系。它有助于讀者理解存在這種關系的原因。如果沒有為一個關系指定名稱，那么角色名將用于幫助讀者理解該關系。下圖可以這樣理解：Products 被 Employees 擁有或者 Employees 是 Products 的擁有者。該關系描述中單詞的單復數通過基數確定。
圖 13 實體類型 Employee 和 Product 之間的關系
?
實體類型中用到的數據類型沒有被標準化。用戶可以使用所需要的任何數據類型。創建具有所有數據類型的術語表是一個不錯的做法，因為它可以在公司內多個設計者和項目中實現標準化和可理解性。
UML 中關系類型的屬性
關系可以具有屬性，這些屬性顯示在 UML 關聯類中。關聯類顯示在一個矩形中，并且包含該關系的公共屬性清單。關聯類利用虛線與關系連接。不需要原型來解釋類用法和為該類分類，因為附件已經對它做了定義。
關聯類中的屬性是用可見性、名稱和類型指定的。
盡管看上去關聯類、附件和關系是獨立元素，但是它們實際上代表了同樣的元素。關系和關聯類的名稱必須相關。
圖 14 關聯類中指定了關系類型 Services 的屬性
?
UML 中的簡單約束條件
基數
UML 定義了一種一致的方法來指定基數。它總是被關系雙方上的數字指定。可能的定義包括用于一定數量（也可能是不限量的）實例的指定基數的單個數字，以及一對規定了基數的范圍的以".."隔開的數字。用于無限基數的符號是"*"，它可以單獨使用標識可選的無限關系，也可以與另一個很低的值結合使用，來指定強制關系（如"1..*"）。基數的下限和上限值可以是任意正數或者"*"，但是第一個數字必須小于或等于第二個數字。
圖 15 實體類型 SoccerTeam 定義了與 11 到 18 個球員的實體類型 Player 的 plays 關系
?
依賴關系
UML 可以分辨兩種形式的實體類型間的依賴關系。聚合是需要依賴性實體類型的兩個實體類型之間的一種依賴關系。UML 中聚合的語法是在聚合方用空心菱形表示。同一方還有一個值為 1 的強制基數，它可以省略。
圖 16 每個結婚證實體類型都依賴于扮演新郎和新娘角色的兩個人
?
當聚合不是對于所有依賴關系都唯一，并且不是所有依賴性實例都必須與同一個實體相關時，就可以使用聚合。當聚合是所有依賴關系的唯一實體時，UML 指定了一種叫做組合的強依賴關系。組合被表示為聚合方上的一個實心菱形。當聚合包含下級實體類型時會使用這種關系。
圖 17 實體類型 OrderPositions 完全由組合指定的實體類型 Orders 定義
?
基數可以與聚合和組合一起使用，以便定義這些關系上的約束條件。
特化和泛化
實體類型的相同點和不同點分析是必不可少的一部分。特化降低了風險，并通過從父方那里繼承需求從而減少了需求匱乏。泛化簡化了系統中實體類型的模型和實現過程。
在 UML 中泛化是在關系的父方用空箭頭表示的。泛化不是兩個實體類型間的一種關系。它是從特定實體類型到一般實體類型的派生。在泛化關系上不允許有基數。
父實體類型的所有屬性和關系被特化后的實體類型繼承。到其他實體類型的屬性和關系不能從特化實體類型中刪除。
圖 18 泛化將實體類型 Employees 和 Customers 定義為繼承了 Persons 屬性的實體類型 Persons
?
分類
同一實體類型的范疇規定了實體如何根據它們的特征（比如所有員工都缺勤）互相相關。分類的語法使用了在 OCL（對象約束語言）中指定的與該關系連接的約束條件。
約束條件旨在指定動態行為。當約束條件被評估為有效時，這些關系也是有效的。
通常約束條件是互相排斥的，可以利用互斥關系之間的約束條件{xor}為約束條件建模。
圖 19 實體類型的分類定義了關系類型的標準--Cargo 對于卡車類型的 Vehicle 很重要；Person 可以利用"公共汽車"類型的 Vehicle 被運輸
?
回頁首
結束語
與一般的觀點不同，ER 方法學并不僅限于關系數據庫的開發。筆者不得不同意在大多數情況下，設計流程的輸出會在關系數據庫中實現；然而，這并不是它的一個條件。ER 方法學的焦點在于基于工件的設計。它輸出的是互相有關系的工件（實體類型），以及澄清了實體類型和關系的約束條件。該輸出用于創建具有額外技術相關約束條件的關系模型。
ER 方法學用于工件驅動系統的分析和設計。它可用于概念和邏輯上的建模，但本意并非是為了物理設計。ER 方法學只描述了工件的靜態視圖，而沒有描述系統的動態。
為了創建一個平滑的開發流程，開發團隊的所有成員需要"操同一種語言"，這一點很重要。這是因為對信息的曲解可能導致延誤，造成意想不到的錯誤，并降低團隊成員的總體效率。UML 通過提供一種很容易被系統開發團隊所有成員理解的標準化語言消除了這些擔憂。
本文轉自莫水千流博客園博客，原文鏈接：http://www.cnblogs.com/zhoug2020/archive/2012/06/19/2554448.html，如需轉載請自行聯系原作者
總結
以上是生活随笔為你收集整理的利用 UML 进行实体关系建模的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 函数，高级特性
- 下一篇： 浅析Banner设计