利用 UML 進行實體關系模組化

簡介： 軟體行業中最常被誤解的一個術語實際上是我們非常熟悉的一個：實體關系（ER）。這是因為我們經常缺少一種能被開發團隊的所有成員了解的共同定義。我們假定團隊的每個成員都對與 ER 和 ER 模組化相關的方法學、文法和機制（mechanics）有着同樣清楚的了解。

實體關系模組化

軟體行業中最常被誤解的一個術語實際上是我們非常熟悉的一個：實體關系（ER）。這是因為我們經常缺少一種能被開發團隊的所有成員了解的共同定義。我們假定團隊的每個成員都對與 ER 和 ER 模組化相關的方法學、文法和機制（mechanics）有着同樣清楚的了解。

ER 模組化本身定義了在基于資訊的系統的分析和設計中用到的方法。資料庫設計者通常使用該方法來收集需求，并定義資料庫系統的構架。該方法的輸出是實體類型、關系類型和限制條件的清單。

不幸的是，ER 模組化沒有為 ER 圖的表示定義圖解文法。資料庫團隊經常單獨使用表示法，并且将 ER 模組化限制在關系資料庫設計的範圍内。我們需要一種能讓整個系統開發團隊的成員獲得更廣泛了解的表示法。

統一模組化語言（UML）是一種分析人員和軟體開發人員廣泛使用的語言，特别适合 ER 圖的圖形化表示。通過使用 UML，開發團隊受益匪淺，這些獲益包括團隊成員間的交流更加簡單，由于該語言是基于元模型的因而更容易與知識庫內建，标準化輸入/輸出格式（XMI）的使用，應用模組化和資料模組化的普遍使用，從分析到實施再到部署的統一表示，以及規格說明書的完整性。

本白皮書定義了 ER 模組化的核心概念，并解釋了開發團隊如何能夠利用 UML 開發 ER 模型。

回頁首

ER 模組化的核心要素

ER 模組化基于工件，可以是實體工件（比如 Product 或 Employee）的表示或者工件（比如 Order 或 Delivery）之間事務的表示。每個工件都包含關于自身的資訊。ER 模組化還專注于工件間的關系。這些關系可以是二進制的（連接配接兩個工件），也可以是三元的（在幾個工件之間）。

ER 模組化的四個必要元素是：

1. 實體類型
2. 屬性
3. 關系類型
4. 關系屬性

實體類型是具有相同的結構并在企業内部獨立存在的一組工件。Employees 或 Products 就是實體類型的例子。

工件的一次出現就是一個實體。雖然實體類型描述了結構，但是實體本身辨別了單個執行個體以及該執行個體的所有資料。Employee Joe Ward 就是 Employees 實體的一個例子。

實體類型的結構是用屬性定義的。屬性可看作實體類型的特征。Employee 的屬性可能有姓名、住址、社會安全号碼、出生日期、參加工作日期以及職務等。

實體通過屬性值來互相區分。由于實體的屬性可能有相同的值，如果這樣我們就不能區分某些特定的實體。是以，我們必須保證特定實體的屬性值與其他實體的屬性值不同。各個 Employee 都有一個唯一的姓名和社會安全号碼屬性組合。

Employee 的屬性值的一個例子是：Joe Ward，位址為 34 Main Road, Redmond, WA, 98053，社會安全号碼為 555-32-2222，出生于 1971 年 9 月 7 日，2001 年十月 1 日加入公司，是家電服務工程師。

實體類型描述了獨立工件，而關系類型描述了實體類型間有意義的關聯。更準确的說，關系類型描述了參與該關系的實體類型的實體可以建構一個有意義的關聯。實體間實際發生的關聯被稱為一種關系。

有一點我們必須了解：盡管我們已經定義了一種關系類型，但是這并不意味着每一對實體都建構了一種關系。關系類型規定了發生關系的類型。

關系類型的一個例子是 Employee 擁有 Product。在該例中，關系類型是 Owns。關系本身是：Employee Joe Ward 擁有一種産品--一部編号 320 TS 03880 的黃色電話機。

也有可能有一位名叫 Martin Weber 的雇員就沒有擁有電話機。

關系類型的屬性

關系類型還可以包含屬性。比如，Employee 和 Product 間的關系類型 Services 可以包含屬性 Date 和 Status，辨別了服務的日期以及服務之後産品的狀态。

當在具體發生的服務中實作關系時，該關系的屬性值就被設定。關系的含義可能是：Joe Ward 在 2002 年 7 月 3 日為序号是 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 組成。

足球比賽中經常有隊員由于不當的行為或者犯規而領到黃牌或紅牌。它們用實體類型 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就已經失效。

特化和泛化

核心 ER 模型隻定義了實體類型間的基本關系。雖然利用基本的實體和關系就可以很容易地表示商業機構中的大多數簡單資料結構，但是技術應用要求基于實體類型間的相似點和不同點的更複雜的結構。

特化和泛化的目的在于重用與實體類型關聯的屬性和行為。

特化用于定義代表一個大型實體類型的一個特定部分的實體類型。特化後的實體類型從父實體類型繼承了結構和行為，比如業務規則。然而，雖然特化後的實體類型擴充了父結構或類型，但是這決不是說它小于父類型。

比如，Employee 是實體類型 Person 的一個特化，它需要實體類型 Person 的所有屬性和關系。另外還有一種叫做 Customer 的實體類型，它也是實體類型 Person 的一個特化。這兩種實體類型都具有 Person 的屬性，它們被看作 Employee 或 Customer 的屬性。是以在我們看 Customer 時，看到的是在實體類型 Person 和實體類型 Customer 中指定的所有屬性。

泛化是正好相反的工作流。泛化實體類型（或者父類型）代表所有子類型的共同結構和行為，并且包含了來自子實體類型的所有共同屬性。子實體類型具有父屬性的所有内容，并且還擁有自己的屬性。

泛化過程找出共同結構并在父實體類型中抽象出來。父實體類型通常在比較實體類型和簡化模型時的重構階段被找到。

雖然泛化僅利用面向對象或者對象關系資料庫就可以直接實作，但是泛化也可以通過使用外鍵的任何關系資料庫直接實作。

圖 9 實體類型 Customer 和實體類型 Employee 被泛化為人實體類型；反向過程就是特化

分類（Categorization）

特化是在實體上完成的，而分類則定義了關系類型上的限制條件。大多數情況下，分類是排他性的，這意味着根據實體狀态的不同，一個實體要麼參與關系 A 要麼參與關系 B。該狀态可能是一個屬性值（另一種關系的存在），或是某些外部狀态。

分類不改變實體的屬性。它需要資料通路和操縱，來考慮分類中指定的限制條件。

交通工具就是分類的一個好例子。根據交通工具種類的不同，我們需要建構不同的關系。對于卡車，我們需要貨物資訊，而對于公共汽車，我們需要乘客姓名。這些資訊将被用于不同的關系中，以便為這些關系提供有意義的上下文。

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 中，對象是類的執行個體。這意味着實體本身與對象相對應。

對象的表示來源于類的表示。最顯著的差別在于對象的名稱有下劃線，并且隻有一個或兩個部分。

第一個部分包含以冒号隔開的可選的原型、對象名稱，以及派生類的名稱，之間用冒号隔開。至少必須指定其中一個名稱。第二部分包含相關屬性以及它們的值。

表示對象的最好的方法就是隻使用一個部分，并将辨別符 指定為對象的名稱。

UML 中的屬性

實體的相關狀态和資訊被作為對象的屬性存放。實體類型的屬性對于其他實體類型必須是可見的或者公開的。在類規格說明書中屬性是按照可見性、名稱和類型指定的。屬性的類型為分析類型。它在設計階段可能發生變更。

屬性是在類的第二部分指定的。它們包含對于實體總是"＋"（公開）的可見性規格說明書。名稱與類型之間用冒号隔開。

UML 中的關系類型

在 UML 中類之間的關系是為類型而非執行個體指定的。關系雙方上的數字指定了基數：參與該關系的可能執行個體的數量。

關系的名稱是直接在關系行中指定的，用于辨別該關系。它有助于讀者了解存在這種關系的原因。如果沒有為一個關系指定名稱，那麼角色名将用于幫助讀者了解該關系。下圖可以這樣了解：Products 被 Employees 擁有或者 Employees 是 Products 的擁有者。該關系描述中單詞的單複數通過基數确定。

實體類型中用到的資料類型沒有被标準化。使用者可以使用所需要的任何資料類型。建立具有所有資料類型的術語表是一個不錯的做法，因為它可以在公司内多個設計者和項目中實作标準化和可了解性。

UML 中關系類型的屬性

關系可以具有屬性，這些屬性顯示在 UML 關聯類中。關聯類顯示在一個矩形中，并且包含該關系的公共屬性清單。關聯類利用虛線與關系連接配接。不需要原型來解釋類用法和為該類分類，因為附件已經對它做了定義。

關聯類中的屬性是用可見性、名稱和類型指定的。

盡管看上去關聯類、附件和關系是獨立元素，但是它們實際上代表了同樣的元素。關系和關聯類的名稱必須相關。

UML 中的簡單限制條件

基數

UML 定義了一種一緻的方法來指定基數。它總是被關系雙方上的數字指定。可能的定義包括用于一定數量（也可能是不限量的）執行個體的指定基數的單個數字，以及一對規定了基數的範圍的以".."隔開的數字。用于無限基數的符号是"*"，它可以單獨使用辨別可選的無限關系，也可以與另一個很低的值結合使用，來指定強制關系（如"1..*"）。基數的下限和上限值可以是任意正數或者"*"，但是第一個數字必須小于或等于第二個數字。

UML 可以分辨兩種形式的實體類型間的依賴關系。聚合是需要依賴性實體類型的兩個實體類型之間的一種依賴關系。UML 中聚合的文法是在聚合方用空心菱形表示。同一方還有一個值為 1 的強制基數，它可以省略。

當聚合不是對于所有依賴關系都唯一，并且不是所有依賴性執行個體都必須與同一個實體相關時，就可以使用聚合。當聚合是所有依賴關系的唯一實體時，UML 指定了一種叫做組合的強依賴關系。組合被表示為聚合方上的一個實心菱形。當聚合包含下級實體類型時會使用這種關系。

基數可以與聚合群組合一起使用，以便定義這些關系上的限制條件。

實體類型的相同點和不同點分析是必不可少的一部分。特化降低了風險，并通過從父方那裡繼承需求進而減少了需求匮乏。泛化簡化了系統中實體類型的模型和實作過程。

在 UML 中泛化是在關系的父方用空箭頭表示的。泛化不是兩個實體類型間的一種關系。它是從特定實體類型到一般實體類型的派生。在泛化關系上不允許有基數。

父實體類型的所有屬性和關系被特化後的實體類型繼承。到其他實體類型的屬性和關系不能從特化實體類型中删除。

分類

同一實體類型的範疇規定了實體如何根據它們的特征（比如所有員工都缺勤）互相相關。分類的文法使用了在 OCL（對象限制語言）中指定的與該關系連接配接的限制條件。

限制條件旨在指定動态行為。當限制條件被評估為有效時，這些關系也是有效的。

通常限制條件是互相排斥的，可以利用互斥關系之間的限制條件{xor}為限制條件模組化。

結束語

與一般的觀點不同，ER 方法學并不僅限于關系資料庫的開發。筆者不得不同意在大多數情況下，設計流程的輸出會在關系資料庫中實作；然而，這并不是它的一個條件。ER 方法學的焦點在于基于工件的設計。它輸出的是互相有關系的工件（實體類型），以及澄清了實體類型和關系的限制條件。該輸出用于建立具有額外技術相關限制條件的關系模型。

ER 方法學用于工件驅動系統的分析和設計。它可用于概念和邏輯上的模組化，但本意并非是為了實體設計。ER 方法學隻描述了工件的靜态視圖，而沒有描述系統的動态。

為了建立一個平滑的開發流程，開發團隊的所有成員需要"操同一種語言"，這一點很重要。這是因為對資訊的曲解可能導緻延誤，造成意想不到的錯誤，并降低團隊成員的總體效率。UML 通過提供一種很容易被系統開發團隊所有成員了解的标準化語言消除了這些擔憂。

IBM軟體內建方案

• DB2® 軟體利用資料啟用（data enablement）、資料管理和資料分布解決方案幫助您充分利用資訊。
• Lotus® 軟體利用授權、管理、交流和共享知識方面的解決方案幫助您的職員提高生産力。
• Tivoli® 軟體幫助您管理運作電子商務基礎構架的技術。
• WebSphere® 軟體幫助您将現有的業務關鍵流程擴充到 Web 上。
• Rational® 軟體利用工具、服務和最佳實踐幫助您提高了軟體開發能力。