使用 Rational Data Architect 集成數據源

信息的集成無疑是具有挑戰性的。許多的業務決策都需要文檔化，許多變革都要執行。IBM Rational Data Architect可以幫助你文檔化你的決策，并且這個過程的一部分是自動完成的。通過學習這篇文章，你可以了解只用五個步驟進行聯邦設計的一個工具支持的過程。

簡介

當你試圖集成數據源時，你需要考慮許多活動。Rational Data Architect可以幫助你進行文檔化決策，并且自動執行你的部分任務。在這篇文章中，向你介紹了一個你可以使用的過程，你可以根據你的特定數據集合需要作相應的更改。這篇文章中提到了一個成功設計所需要的五個步驟，他們是：

1. 注釋現有的基礎構架
2. 在數據源之間做映射
3. 建立一個聯邦模型
4. 映射聯邦數據源
5. 產生聯邦代碼

 

回頁首

Rational Data Architect產品概覽

Rational Data Architect是一個數據建模，集成設計工具，被用來幫助數據架構師理解信息資源，他們之間的關系是相互依賴的，資源之間是相互映射的，并且建立集成的計劃。為任何大小的團隊建立構架，Rational Data Architect 通過映射發現和模型來集成數據建模，并進進行數據庫分析——所有都在一個單一的工具中完成。另外，Rational Data Architect支持企業標準的執行。Rational Data Architect 使用一個不同種類的方法——促進聯邦設計，它是一個信息集成項目的經典工具。

Rational Data Architect提供簡化設計和開發時間的工具。這個新式的軟件建立在開放的Eclipse平臺之上，它可以幫助構架師在多樣的信息源基礎上進行建模，發現，映射和分析數據，并且可以在復雜的環境中自動的進行信息集成。

注釋現有的基礎構架

五個步驟中的第一步是幫助用戶評估他們現有的情況。雖然這個階段的很多過程都是自動執行的，但是像逆向工程等等這些過程還是需要手動完成的，因為每一個注釋都是根據它出現的概率推測出的。讓數據源最初的設計者和數據源的用戶參與這個步驟是很重要的。

注釋你現有的基礎構架：

1. 連接到現有的數據源。

   為了訪問數據結構，你需要遵守標準連通性協議。 你需要了解數據源的類型，連接到它的驅動程序以及注冊信息（大多數情況需要注冊和密碼）。 Rational Data Architect使用標準的JDBC連通性去連接數據源。 數據源之間所有深層次的交流都是使用數據源系統表的本地查詢來實現的。

2. 從數據源中選擇可用數據結構的子集。

   很多數據源包括的數據都是和存儲信息無關的，例如計數器，用來分類數據的臨時助手以及用戶接口的多種語言文本。在這個步驟的開始消除這些數據結構是件非常簡單的事情。

   Rational Data Architect允許在Database Explorer的任何數據結構層級進行過濾操作，如圖1所示： 我們準備定義一個只允許相關信息的過濾器。

   
   
   圖1：連接到數據源。
   
   
   
   
3. 在所選的子集中建立一個模型。

   從數據源建立模型有兩個原因：

   • 大多數據庫不能夠捕獲到一個成功集成過程所需的詳細程度的業務相關注解和文檔信息。

      

   • 變更管理。集成需要被設計在一個穩定的數據構架之上。一旦數據源的結構發生了變化，你就需要為集成執行更新的操作，從而產生一個新版本的模型。
   從數據源建立的一個物理的數據模型基本上是一個數據源數據結構的摘要拷貝。察看圖2：

    

   
   
   圖2：建立物理數據模型
   
   
   
   
4. 在模型中文檔化數據結構。

   當一個模型顯示大多數層級的數據源規范細節時，這對我們理解數據是不夠的。 例如，CLNR中的CHAR(16)并不是會被每一個開發人員使用相同的方式解釋。 在這種情況中，你把文檔添加到模型的每一個元素中，包括每個列，每個表，每個約束和每個觸發器。 你應該列出業務相關的名稱，這樣可以允許模型具有更好的可讀性。

   同樣我們強烈建議你建立背景相關的圖表。但是這不意味著你要建立一個從很多會議室墻壁上收集來的巨大圖表。 取而代之的是你應該使用大約七個要點元素來建立一個小型的圖表。（你可以使用更少的元素，但是盡量不要多用。）

5. 建立一個與模型相關的術語表。

   使用活動4，你可以建立一個術語表，它定義了數據源中名字的含義。設計人員和開發人員經常會使用各種名稱來使他們的工作簡單。 當名字的長度受到限制時，命名標準就會為簡化名稱而被使用。連貫性是依靠每一個數據源的規則和生命周期的。

   你可以查閱Rational Data Architect的術語表，它包含很多可用的業務名稱的縮寫。如圖3所示： 例如縮寫CL，它表示client，縮寫NR表示number等等。 有些數據源的縮寫很極端，并不是人們的常規想法，例如J9表示client，或者O1表示的是identifier等等。 雖然Rational Data Architect并不限制同時使用術語表的數量，但是我個人建議你一個模型只使用一個術語表。（這并不是一個出于技術上的建議，而是出于用戶體驗的建議。）

   
   
   圖3：定義術語表
   
   
   
   

這五個注釋你現有情況的活動或許顯得有些不足，而大多數用的情況下是很耗時的，并且包括很多手動的工作。

回頁首

數據源之間的相互映射。

集成的過程包括從很多數據源集成，每一個數據源在你使用之前都需要注釋。 在注釋現有的基礎結構之后，雖然你了解每一個數據源，但是你并不了解集合在一起的所有數據源。

映射現有的數據源是可選的，因為它不會產生更多注釋過程需要的結果。但是我們仍然強烈建議你執行映射，這樣可以幫助你理解集成數據的完整性，并且可以預見不同數據源之間可能出現的沖突。

數據源之間的相互映射：

1. 在每一對數據源模型之間建立一個新的映射模型。

   一個映射是兩個數據之間的依賴，它在數據源的實現時并不被執行。一個映射模型是兩個獨立數據源或者數據模型之間映射的概要。映射模型隨著數據源的增長而快速的增長。你可以使兩個資源擁有一個映射模型，三個資源擁有三個映射模型，四個資源擁有六個映射模型——這些都隨模型的變化而變化。 如果你使用很多的數據源，你就不需要建立所有的模型。 而只是使用它們中的一部分作為參考，為這些模型建立映射模型，如圖4所示：

   
   
   圖4：映射數據源模型
   
   
   
   
2. 發現（自動或者手動）數據源結構之間的映射。

   還記得之前章節建立的術語表么？ 現在，它可以幫助你注釋一個方法了。 映射發現可以使用術語表來為可能的映射建立更好的建議。 每一個映射表達了數據源結構的目標結構的建立規則。 例如，假設你有一個作為目標的driver's license和作為源的birth certificates之間的映射，映射在駕照上的"name"應該是出生證明上的"first name，" "middle name，"和"last name"。 這是一個包含轉換的映射的例子。 模型包含上百個這樣的元素。 你可以手動定義所有這些映射，但是它會花費好幾周的工作。

   Rational Data Architect可以幫助你分辨所有實際應用中的簡單的映射：一對一映射。 例如，從"family name"到"surname,"的映射。 在Rational Data Architect的第一個版本中，映射塊可以使用一個五個發現算法的結合。

   最簡單的映射是把模型元素的名稱作比較，并且隨意的使用術語表模型來增加結果的精確性，這個過程是在比較之前把縮寫展開到業務名稱中來實現的。 大多數復雜的映射發現是使用外部購買的辭典來從數據源中查找同義詞或者數據樣本，從而驗證映射的可能性。 對于每一個映射模型都必須完成映射發現，并且為了模型的易讀性，同時還應當有單個映射的文檔。

3. 完成數據源模型的注釋。

   你可以從映射模型獲得關于數據源模型的更多的理解。 例如，你可能會發現第一個數據源中一些數據結構和另外一個數據源中的數據是結構相關聯的。 它經常是一個無效的通告，部分的數據集成過程中應該不會被考慮，因為他們是錯誤的。完成現有數據源之間的映射是非常有價值的操作，即使你不打算集成信息。

映射的結果會從兩個試圖展現：

• 來自不同模型之間數據的競爭。競爭數據可以導致更加復雜的集成規格的產生，無論數據是來自兩個不同的數據源還是包含最新的數據。
• 數據結構的排外性。這些結構應該檢查他們是否必須在聯邦模型中包含他們。

 

兩種檢查方式導致了業務的決策并且依靠于你的信息集成原因。

回頁首

建立聯邦模型

對數據源有很好的理解是驗證你是否能夠完成信息集成過程的關鍵。這個過程的一個主要部分是指定目標，或者是計劃，這在集成之后是可見的。這個過程應該把集成過程中的業務需求統一化。

1. 建立一個業務（邏輯）模型的解決方案。

   業務模型定義了實體和實體之間的關系，并且忽略執行平臺。 模型需要解決業務問題。 如果業務問題之需要一個數量上的匯總，那么模型就不需要包括次序信息。

   Rational Data Architect把這個模型作為邏輯數據模型執行，如圖所示：圖5：

   
   
   圖5：邏輯數據模型
   
   
   

   一個邏輯數據模型不受不同實體之間關系的限制。 它可以包含任何種類的關系，包括圖表類型和多到多的關系。 在邏輯模型設計過程中，業務人員正在確認和業務過程的擁有者是非常重要的。 只有當有些東西缺少或者模型之間的關系以及規則不正確的時候他們才能識別出來。

   想要讓模型更加好的理解，你應該按照需要建立很多圖表來表達不同的業務視圖。 文檔和注釋是模型最重要的兩個部分。 想象一下如果有人給你一個未加任何文檔的模型去讀——這樣這個模型就會失去很多它的意思，并且你不會比畫一個圖表來表達它理解的更多。

2. 把邏輯模型放到一個物理執行模型中。

   邏輯模型表達了信息的業務視圖。 下一個環節是把這個模型放到一個物理模塊中，這個問題受限于我們實現它所使用的技術。這個過程是和第一次轉換相關聯的，并且在模型更新中需要多加關注。

   Rational Data Architect允許你把一個邏輯模型轉換成一個物理模型。 在轉換的過程中，Rational Data Architect會自動地解決所有目標模型的約束，例如缺少多到多的關系或者圖表類型，然后為選中的目標正確的執行這個過程。 Rational Data Architect同時還允許你把邏輯模型和物理模型作比較，并且通過比較來為物理模型進行更新，這個過程使用Compare & Synchronize函數。

這個物理模型并不是WebSphere Information Integrator中執行計劃所產生的模型；而是集成模型的原型，它是在代碼產生和使用相關匿名和試圖改變表格時建立的。

回頁首

映射聯邦數據源

這個信息集成設計的第四個主要步驟是在物理模型所表達的原始數據源和目標聯邦模型中建立映射。 這個映射需要完成并且要可以產生代碼。

這個映射的例子是和 在數據源之間相互映射一部分非常類似的，它們之間只有細微的差別。

1. 在每一個數據源模型和聯邦模型之間建立映射模型。

   這個步驟導致模型的數量和數據源的數量一致。 這些模型的概要定義了如何從現有的數據源建立完整的聯邦計劃。 在不同數據模型元素中非常有可能產生競爭規范。 我們并沒有在這個過程中使用他們，但是在稍后會組織他們。

2. 數據源結構之間的發現（自動或者手動）映射。

   在先前的例子中，你需要數據源和聯邦計劃之間的發現映射，如圖所示：圖6： 這個例子和先前討論的不同源計劃的例子基本相同。 你需要關注更多復雜的情形，它們使用映射組來存放更多的表結構。 一個映射組比用一個源數據選擇出的結果更能達到聯邦數據的要求（或者一個"選擇"語句）。

   你可以使用Rational Data Architect中映射組的替代來評估和定義連接的復雜性。 如果連接已經存在于源模型中，那么它將會自動在映射編輯器中顯示。

   
   
   圖6：映射發現
   
   
   
   
3. 完成數據源模型之間的映射轉換。

   使用映射建立聯邦代碼，你需要定義可執行的轉換。 當需要格式，內容或者數據結構變化時，你需要指定這是如何執行的。 這就需要服務器的轉換代碼——這個例子中就是：WebSphere Information Integrator。

   使用語法構建器或者在Rational Data Architect的映射語法屬性中直接輸入轉換。 語法構建器已經預先定義了WebSphere Information Integrator挑選的函數供你使用。

下面你需要定義所有從源到聯邦計劃的轉換。 這只是一個問題：有太多的轉換了。 由于獨立的映射編輯器被使用，你不能具有任何的控制來超過被在目標中每一個元素（列）中定義的映射的數量，。 如果你想要產生代碼，就需要解決這個問題。

回頁首

產生聯邦代碼

最后一步是從模型回到可執行代碼的轉換。 你可以從映射模型完成這個步驟。 但是你如何確定能夠產生正確的代碼？

從所有的數據源為信息集成接收正確的代碼：

1. 把所有映射模型合并到一個模型中。

   首先，你需要有一個數據源到聯邦模型的整體視圖。 如果你在一端覆蓋所有源模型那么你就可以這么做，并且把單個聯邦模型作為目標留在另外一端。 這個步驟使用很多映射導致一個非常忙碌的模型，并且沒有很大的關聯，你將會在下一步中刪除其中的很多關聯。

   Rational Data Architect能讓你使用多種方法把兩個模型合并成一個模型。 其中的一個方法就是使用同樣的目標。 我們重復這個過程直到所有的模型都添加到一個模型中。

   另外一個合并兩個映射模型的方法是當一個目標和另一個目標的源相同的時候。

2. 除去競爭映射。

   如果你想得到一個單獨的可用模型，那么這個步驟是關鍵。 結果是需要每一個目標元素（列）都有一個單獨的可執行的映射。 合并所有的映射模型建立了很多元素，它們是單個映射的目標。 我們將要看到這種元素并且選擇一個單獨的映射。 所有其它的映射都不需要了，所以可以刪除掉。

   當然你也可以刪除一個你認為不需要的映射組。

   你還需要刪除說有空的映射組。 你可以通過選擇結果映射模型中的映射組細節來輕松的完成這些工作。

3. 從映射模型產生目標計劃。

   雖然你可以從模型中產生DDL，但是這個過程還是要小心。 請記住每一個物理模型都要了解目標的容量。 你需要選擇一個WebSphere Information Integrator產生的模型來使用匿名和產生試圖來接收聯邦代碼。

   映射模型的代碼產生向導中，Rational Data Architect允許為任何產生的元素更改名稱，如圖所示：圖7： 代碼的產生結果是一個帶所有目標集成模型中的模型的計劃，還有代碼產生的腳本。

   
   
   圖7：產生集成的計劃
   
   
   
   
4. 使用WebSphere Information Integrator執行計劃DDL。

   它值得去查看產生的腳本并了解它變化的可用性。 我建議從模型自身產生代碼，因為你可以把它根目標和產生代碼作比較。

   當產生代碼的時候，你會使用一個到WebSphere Information Integrator的連接——和反向工程初始模型一樣。

現在你已經完成了設計過程?，F在要考慮測試和部署問題了。

回頁首

總結

這篇文章描述了聯邦設計產生集成計劃的五個步驟的過程。 你將以一系列的中間模型結束，他們都可以被再度使用，在下次開發中將會縮短過程的時間。這個過程還能增加你對總體信息結構的理解。

Rational Data Architect的建立幫助你理解信息的集成。我建議你訪問資源以獲得更多的信息。

原文轉自：http://www.anti-gravitydesign.com