2005 年 3 月 19 日
這篇文章描述了一種基于統一建模語(yǔ)言（Unified Modeling Language，UML）的新方法，作者相信該方法可以達到企業(yè)數據架構建模的真正要求。
不同于書(shū)本和培訓課程中所提的單例模式，真正的企業(yè)具有非常復雜的數據架構。大多數數據將會(huì )存于大型遺留或包系統中，數據結構的細節對于這些系統來(lái)說(shuō)可能是不可見(jiàn)的。其他數據將存于電子表格和個(gè)人數據庫（例如 Microsoft Access）中，且可能對于 IT 部門(mén)或高級業(yè)務(wù)數據管理員來(lái)說(shuō)是不可見(jiàn)的。一些關(guān)鍵數據可能存于由服務(wù)供應商或業(yè)務(wù)合作伙伴維系的外部系統中。隨著(zhù)您對復雜數據架構的探究，就會(huì )逐漸接受兩個(gè)現實(shí)：
您很少控制的了高級業(yè)務(wù)數據概念實(shí)現的方式。數據很可能是高度分散的，并且常常在質(zhì)量方面缺乏足夠的控制。
大部分數據在大量系統中進(jìn)行復制，并且在質(zhì)量、格式及含義上出現重大變更。一些由企業(yè)應用程序集成（Enterprise Application Integration，EAI）技術(shù)或精心的的業(yè)務(wù)流程進(jìn)行維護的副本，也許是好的（但很可能不完善）。大部分僅僅由臨時(shí)的批量傳輸或受迫并破裂的人工流程維護的副本是很差的。組織及業(yè)務(wù)流程的沖突或簡(jiǎn)單的信任上的失敗可能會(huì )阻礙常識的增長(cháng)。
這些條件有幾個(gè)重要的結果。例如，當計劃，如客戶(hù)關(guān)系管理（Customer Relationship Management，CRM）和業(yè)務(wù)智能（Business Intelligence）需要通過(guò)各種各樣的來(lái)源來(lái)合并數據時(shí)，差的副本也許會(huì )使得業(yè)務(wù)或技術(shù)問(wèn)題惡化。一些組織在端到端流程中利用各種遺留系統。業(yè)務(wù)或 IT 都可能會(huì )進(jìn)行改變以簡(jiǎn)化業(yè)務(wù)流程，流水化數據流并減少復制。盡管建模為解決這些難題帶來(lái)好處，但是傳統的建模方法不能解決這些難題。它們會(huì )建立要么過(guò)于詳細以至于無(wú)法使用的模型，要么建立不夠詳細的模型，并且他們沒(méi)有著(zhù)重于企業(yè)數據架構和各種組件整合的難題。
我們相信用企業(yè)級觀(guān)點(diǎn)來(lái)創(chuàng )建強有力的、簡(jiǎn)單并有效的數據結構模型是很重要的 —— 一組被稱(chēng)為“企業(yè)數據架構”的模型。本文描述了一種新的基于統一建模語(yǔ)言（UML）的方法，我們相信該方法可以滿(mǎn)足企業(yè)數據架構建模的真正需求。
注意：該方法后面的一些步驟介紹了可能在開(kāi)始時(shí)有些難懂的技術(shù)。不要擔心！您不必每次都使用所有的技術(shù)，早些的步驟用其方式提供好處。最重要的是開(kāi)發(fā)幫助解決您問(wèn)題的模型。
企業(yè)的信息系統架構有許多相關(guān)的方面，包括應用程序、硬件、網(wǎng)絡(luò )、業(yè)務(wù)流程、技術(shù)選擇和數據。如圖 1 中所示，數據架構是一組分層的模型，為戰略性的計劃提供堅實(shí)的基礎，如：
數據策略（Data Strategy），概括了為改進(jìn)集合及數據使用的業(yè)務(wù)目標。
業(yè)務(wù)流程改進(jìn)。
對新的變更系統的未來(lái)的決策。
整合、數據存儲及報告計劃。
圖 1：企業(yè)數據架構模型 —— 支持各種公共的 IT 和業(yè)務(wù)改進(jìn)計劃。
在介紹數據架構的含義之前，先考慮一下它不是什么是很有幫助的。如圖 2 所示，數據架構不是一組單個(gè)系統的詳細模型，因為它們不能傳送用來(lái)滿(mǎn)足以上需求的所需要的“大圖片”信息。而且它不僅僅是業(yè)務(wù)流程和系統范圍的頂級模型，因為它們沒(méi)有包含足夠的細節以回答實(shí)際的問(wèn)題。
圖 2 是“數據架構圖”，它說(shuō)明了范圍和數據架構環(huán)境。企業(yè)的主要數據領(lǐng)域映射到其中一個(gè)軸，各種類(lèi)型的模型映射到另一個(gè)軸，范圍從高度著(zhù)重業(yè)務(wù)的模型到詳細的系統架構。完整的數據架構的范圍呈現為跨圖表中央的帶狀。
圖 2： 數據架構圖 —— 說(shuō)明了哪個(gè)模型用于企業(yè)中哪個(gè)數據領(lǐng)域，完整的數據架構是橫跨中央的帶狀。
（）
組成數據架構的模型將在下面的部分進(jìn)行更加詳細的介紹。水平分組是按照企業(yè)到企業(yè)區分的，上面的那些代表典型的集合。在右側邊緣的帶不是“圖”的部分，但顯示了模型如何映射到標準的基于 UML 方法（如 Rational Unified Process， 或 RUP）的三級透視圖上。
除了利用該模型來(lái)闡述數據架構工作的范圍，您還可以利用它來(lái)建立知識的當前狀態(tài)和正在進(jìn)行或計劃著(zhù)的活動(dòng)的范圍的映象。簡(jiǎn)單地在適當的交點(diǎn)繪制現有的或計劃著(zhù)的建模工作。您還可以通過(guò)顏色來(lái)指示模型的狀態(tài)或有效性，這是很有用的。
數據架構圖描述了“什么”組成了數據架構。支持它的數據策略和計劃闡述了“為什么?！眴蝹€(gè)的模型說(shuō)明數據是什么、在哪里，以及什么時(shí)候由誰(shuí)如何改變的。
數據架構主要由下面部分介紹的四級模型定義的。通常，只有在業(yè)務(wù)流程發(fā)生重大變更時(shí)，高級數據模型才會(huì )變更，但其他的模型將存在于各種各樣的版本中，代表“目前”的結構和一個(gè)或多個(gè)“將來(lái)”的進(jìn)展。
頂層是一組高級數據模型，用概念性觀(guān)點(diǎn)描述業(yè)務(wù)數據，獨立于任何當前實(shí)際系統的實(shí)現。每個(gè)高級數據模型（high-level data model，HLDM）包含：
主要數據項（業(yè)務(wù)實(shí)體）及其關(guān)系的通用（規范的）UML 類(lèi)模型。
業(yè)務(wù)屬性的超級，包含對這些屬性含義（語(yǔ)義）、標準化格式（語(yǔ)法）和普遍制約的描述。
因為這些是數據模型，所以它們不會(huì )包含類(lèi)方法，盡管若業(yè)務(wù)對象有責任管理其他結構的話(huà)，對這些方法進(jìn)行概括是適合的。
模型應包含所有業(yè)務(wù)意義的屬性和定義數據結構的內容（例如，控制多樣性業(yè)務(wù)規則的輸入）。
設想一個(gè)假設的汽車(chē)租賃公司。圖 3 顯示了實(shí)例 HLDM 的部分內容，說(shuō)明了業(yè)務(wù)實(shí)體“vehicle”如何擁有兩個(gè)變量 —— car 和 van，以及任意一個(gè)車(chē)輛（vehicle）怎樣隸屬于一個(gè)或多個(gè)租賃業(yè)務(wù)（rental）。
圖 3： 部分高級數據模型 —— 用于假設的汽車(chē)租賃業(yè)務(wù)。
出于本文的原因，我們的實(shí)例非常地簡(jiǎn)化，但這些實(shí)例仍舊可以說(shuō)明那些技術(shù)如何能夠應用于帶有真實(shí)世界復雜度的實(shí)例中。而且我們還在命名類(lèi)及屬性方面放松 UML 的約定，以使其更具可讀性 —— 例如，“Registration Mark”包含一個(gè)空格。
下一個(gè)步驟是將 HLDM 的概念化實(shí)體和當前或計劃系統的真實(shí)關(guān)鍵數據對象之間的關(guān)系模型化，說(shuō)明了真實(shí)對象如何實(shí)現概念實(shí)體。同一數據項的不同實(shí)現之間的關(guān)系和跨多種系統擴展變更的方式將在后面進(jìn)行模型化。
此處的關(guān)鍵是著(zhù)重于“可見(jiàn)的”系統的數據結構 —— 例如，由用戶(hù)接口暴露出的數據結構、報告及數據接口。這也許和物理的數據結構不同，但不重要。高度可定制的包可能內含復雜的元模型，但所關(guān)心的內容是依照業(yè)務(wù)的系統實(shí)例化。出于歷史原因，舊的遺留系統也許會(huì )具有不可思議的物理結構，而且外部服務(wù)的實(shí)現細節可能會(huì )完全地隱藏在接口后面，但在這兩種情況下，您的關(guān)注點(diǎn)將會(huì )在可視化結構上 —— 邏輯系統實(shí)體和他們的屬性。
圖 4 顯示了簡(jiǎn)單汽車(chē)租賃 HLDM 是如何由三個(gè)系統進(jìn)行實(shí)現的：CarFleet（內部隊伍管理系統）、VanCare（用于支持篷車(chē)隊外包維護的外部系統）和 RentalSystem（主要的租賃控制系統）。
圖 4：部分實(shí)現模型 —— 說(shuō)明了三個(gè)系統中的關(guān)鍵數據對象如何實(shí)現來(lái)自于高級數據模型的概念化實(shí)體（呈現黃色）。
（）
對于本模型，UML 實(shí)現關(guān)系是關(guān)鍵。顏色和物理布局可以帶來(lái)好的效果和一致的命名方案，如這個(gè)顯示出的圖應該能標識出邏輯系統實(shí)體及其宿主系統。
在概念上的實(shí)體的和真實(shí)的實(shí)體的結構或含義有所不同的地方，當可以直接將關(guān)系進(jìn)行映射（如圖 4 所示）之前，一般化和聚集關(guān)系是用來(lái)分解類(lèi)結構的。甚至當 HLDM 作為元模型并且實(shí)現模型是具體的時(shí)候該方法也可以使用，反之亦然。
模型的下一層顯示了同一數據項的不同實(shí)現之間的關(guān)系、如何在不同系統上擴展變更，以及不同數據元素的組織的管理人。
除了關(guān)注點(diǎn)在識別角色、起源及每個(gè)數據項的發(fā)展上意外，模型類(lèi)似于實(shí)現概述，利用下面的構造型：
<<Master>> 標識已經(jīng)過(guò)協(xié)議的原版數據源。
<<Use in place>> 和 <<Update in place>> 標識一個(gè)能夠直接通過(guò)現有接口使用另一系統數據的位置。注釋將解釋其如何工作的。
<<Copy>> and <<Updates Copy>> 標識出一個(gè)系統得到了另一系統的規則或不規則的數據（或者更新列表）的副本，及該副本是否未修改或被接收系統修改了。注釋中將描述計時(shí)及相似的問(wèn)題。
<<Independent master>> 標識出在哪里系統不是原版的，并且在理論上應具有原版數據的副本，但由于流程不是足夠地確定，所以第二數據集出現分歧。
<<Custodian>> 標識出數據項和組織或角色（顯示為業(yè)務(wù)角色，和適當的數據類(lèi)有依賴(lài)關(guān)系）的保管關(guān)系。
<<Uses>> 標識出重要的跨組織的數據的使用。
在需要對不同屬性用不同方式進(jìn)行處理的地方（例如，一個(gè)實(shí)現對類(lèi)的一些屬性是原版的，另一個(gè)類(lèi)對其他屬性是原版的），高級數據模型應通過(guò)兩個(gè)或多個(gè)分離的類(lèi)對那些屬性進(jìn)行建模。來(lái)源及使用者模型（圖 5）能夠清楚地說(shuō)明不同的責任及他們的來(lái)源。
圖 5： 來(lái)源及使用者模型 ——添加描述不同實(shí)現如何相關(guān)及它們如何與不同組織角色相關(guān)的信息（綠色）。
（）
模型的最后一層描述了執行系統的數據如何在系統間移動(dòng)時(shí)進(jìn)行轉換。它們表現在：
系統接口的物理類(lèi)及屬性結構（等同于數據庫結構，在其中直接數據訪(fǎng)問(wèn)是最好或唯一的選擇）。該模型還將顯示帶有接口機制（如 EAI 集線(xiàn)器或干線(xiàn)）的 HLDM 的實(shí)現。
不同物理數據結構之間的實(shí)現關(guān)系。
屬性級的轉換規則，用目標約束語(yǔ)言（Object Constraint language，OCL）編制而成。
接口驅動(dòng)器、約束和計時(shí)規則，通過(guò)交互或時(shí)序圖進(jìn)行建模。
如果這看起來(lái)有一點(diǎn)復雜，那么記得無(wú)需一直使用該技術(shù)，如果您喜歡，可以使用簡(jiǎn)單的文本注釋而不用 OCL。
擴充我們的汽車(chē)租賃實(shí)例，假設我們想通過(guò) EAI 來(lái)保持 RentalSystem 中列出的 Hire Unit 保持最新，提取、合并，并轉換兩個(gè)源列表。圖 6 中的“將來(lái)”的模型描述了物理接口和轉換規則，包括 EAI 消息中數據的正則結構。
圖 6： 轉換模型 —— 添加說(shuō)明數據在系統間移動(dòng)時(shí)如何轉換的細節。
（）
CarFleet 有一個(gè)由兩個(gè)主要表格組成的基于數據的接口，Vancare 有一個(gè)程序化的接口（例如，對象模型或 Web 服務(wù)），Rental System 也一樣，包含一個(gè)接收更新的 Insert() 方法。
公共的或行業(yè)的標準有兩個(gè)任務(wù)：
它們?yōu)?HLDM 或在 EAI 干線(xiàn)和外部接口內的 HLDM 的實(shí)現形成基礎。
它們會(huì )確定外部接口或一些物理系統的數據結構，因此描繪出在接口中進(jìn)行轉換的物理數據結構。
總之，圖 7 中的元模型展示了設計中各種模型及其組件之間如何相關(guān)：
圖 7： 元模型 ——展示了數據架構中各種模型和模型元素間的關(guān)系。
數據架構有很多用途。它幫助您處理數據如同它真的在由業(yè)務(wù)使用，并且如果您想要開(kāi)發(fā)并實(shí)現支持數據策略的治理，它是其中關(guān)鍵的部件。它還應該用于指導跨系統的開(kāi)發(fā)，例如企業(yè)應用程序整合（EAI）、公共報告和數據存儲計劃。
雖然我們對數據架構的闡述是按照“自頂向下”的，但是數據架構通常按照“由中間開(kāi)始”進(jìn)行開(kāi)發(fā)，從特定系統接口的數據需求和合理化實(shí)行開(kāi)始，并不按照嚴格的自頂向下的流程和信息需求分析。這種方式允許數據架構開(kāi)發(fā)以滿(mǎn)足不帶有難于管理的依賴(lài)性的具體的戰術(shù)戰略需求，并向基于分離的自頂向下和自底向上建模運行的數據分析提供交叉校驗。
數據架構業(yè)務(wù)對整個(gè)企業(yè)從來(lái)不是“完整的”。雖然如此，它提供了一種一致的方法和用于建?；顒?dòng)的環(huán)境。然而，隨著(zhù)數據架構的成熟化，采取一些工作來(lái)“填補空白”是適合的。
模型，尤其是來(lái)源及使用者模型，將通過(guò)確定目標數據是否包含于單個(gè)系統，由良好定義的接口和流程進(jìn)行維護，或在一些（潛在地不一致的）源中間進(jìn)行擴展，來(lái)支持目標業(yè)務(wù)流程的驗證。
將“目前”的數據架構進(jìn)行建模非常有用，它能夠很確定地顯示出哪里是次佳的。然而，如果您想要進(jìn)行提高，就需要有比好的模型多得多的東西。圍繞改進(jìn)數據集合、使用和治理的大部分問(wèn)題是非技術(shù)的。IT 部門(mén)，及業(yè)務(wù)經(jīng)理，需要開(kāi)發(fā)若干內容：
設定企業(yè)如何收集、管理并使用數據的原則。
包含“目前”的和“將來(lái)”的模型的數據架構。
數據架構的治理規則和變更控制流程，由 IT 和適當的業(yè)務(wù)代表共同管理。
在每個(gè)業(yè)務(wù)領(lǐng)域內的數據管理規則：
存儲什么數據。
誰(shuí)負責數據的收集和質(zhì)量。
誰(shuí)控制，誰(shuí)管理
存儲多久，將來(lái)如何安排或歸檔。
誰(shuí)可以使用，及如何向常規用戶(hù)組之外的用戶(hù)公開(kāi)。
關(guān)于信息和相關(guān)風(fēng)險分類(lèi)的方案，以確保定義恰當的安全方法。
您還需要幫助改進(jìn)并編制業(yè)務(wù)流程以改進(jìn)數據管理。
數據策略需要建立在清晰的意見(jiàn)一致的原則之上，例如以下部分：
不論在哪里，數據的輸入必須簡(jiǎn)單且數據能準確地反應情況，還要以一種對輸入輸出有效的且可用的格式。
如果數據具有已知且編制了的用途和值，就應收集。
對于那些對數據有合法業(yè)務(wù)需要的數據應是易用的。
數據獲取、驗證和處理的流程不論在哪都應是自動(dòng)的。數據只應輸入一次。
在整個(gè)企業(yè)范圍內，更新所給數據項的流程應是標準的。
應盡可能準確完整地記錄數據，利用最廣博的來(lái)源，使其與原始內容盡可能接近，在最初的時(shí)候將其變成電子格式，并采取可檢查可跟蹤的方式。
數據收集和共享的費用應最小。
企業(yè)，而不是任何個(gè)人或業(yè)務(wù)單元，擁有所有數據。
每個(gè)數據源必須有確定的管理人（業(yè)務(wù)角色）負責數據的精確性、完全性和安全性。
防止對數據進(jìn)行未授權的訪(fǎng)問(wèn)和更改。
除非有實(shí)踐的原因需要進(jìn)行復制，否則不能夠對數據進(jìn)行復制。在此情況下，一個(gè)源必須明確地作為原版，要有健壯的流程確保每一步的副本，并且不能修改副本。
數據結構必須在嚴格的變更控制下，以便于可以適當地管理各種業(yè)務(wù)和系統牽連的變更。
無(wú)論什么時(shí)候，對公共數據模型采用國際、國家或行業(yè)標準。在不可能采用時(shí)，開(kāi)發(fā)組織的標準來(lái)替代。
對企業(yè)數據架構的文檔化的理解是許多公共 IS 和業(yè)務(wù)改進(jìn)計劃的必要先決條件。適當的模型與詳細的系統模型和高級業(yè)務(wù)模型截然不同。本文概述了一組有助于滿(mǎn)足這些需求的 UML 模型和技術(shù)。
您可以參閱本文在 developerWorks 全球站點(diǎn)上的
英文原文。
使用 UML 進(jìn)行企業(yè)建模是一個(gè)新興領(lǐng)域。此處描述的技術(shù)是很新的，這是首次對它們進(jìn)行公開(kāi)介紹。然而，我們發(fā)現以下內容是關(guān)于在架構或業(yè)務(wù)級使用 UML 建模的問(wèn)題的有用的介紹，包括：
Hans-Erik Eriksson 和 Magnus Penker， Business Modeling with UML: Business Patterns at Work。 Wiley， 2000 年。
Chris Marshall， Enterprise Modeling with UML: Designing Successful Software Through Business Analysis。 Addison Wesley，2000 年。
Paul Allen，Realizing e-Business with Components。 Addison Wesley， 2001 年。
1我們計劃將來(lái)出一篇文章討論各種模型怎樣建立系統間的整合“干線(xiàn)”或“集線(xiàn)器”的流程，并利用它創(chuàng )建接口，及填充數據倉庫。
