DB2 的 DB2 Cube VIEws 功能通過共享關系數據庫和商業智能應用程序之間的多維元數據，使商業智能應用程序與數據倉庫的集成變得更加容易。了解如何使商業智能應用程序或工具能夠利用這一強大的新功能。
本文適用對象
本文的適用對象是那些希望通過使用 DB2 Cube Views 應用程序編程接口（API）以便在 IBM® DB2® Universal Database™ V8（UDB）上開發或集成 OLAP 應用程序的技術經理和技術人員。該信息尤其適用於那些構建組件以在 DB2 Cube VIEws 和其它工具或元數據資源庫之間交換元數據的開發人員。為簡單起見，我們將交換元數據的軟件稱為“元數據橋”或者就是“橋”。
具備關系數據庫、倉庫和 OLAP 概念方面的背景知識將有助於對本文的理解。
簡介
公司和用戶目前日益需要具有分析大型數據集以及能夠深入訪問和報告更詳細數據的能力。象 DB2 UDB 之類高可伸縮性的數據庫服務器在向企業交付 OLAP 解決方案中起著日益重要的作用。通過 DB2 Cube VIEws，DB2 UDB 提供了一個甚至更健壯的基礎結構，這種基礎結構可以在端對端倉庫和商業智能部署中起到“重大支撐”作用。
對於許多 OLAP 工具和應用程序而言，與 DB2 Cube Views 的集成需要構建元數據橋。這些橋可以通過使用 DB2 Cube VIEws 的基於 XML 的存儲過程接口來讀取或創建元數據。我們將在本文中討論如何使用這個接口來構建橋。
DB2 Cube VIEws 的概述
IBM DB2 Cube VIEws 是 DB2 通用數據庫的附加功能部件，它增強了 DB2 UDB，使 DB2 UDB 作為開發和部署商業智能產品和應用程序的平台。特別地，DB2 Cube VIEws 有助於加速位於 DB2 UDB 上的 OLAP 解決方案和應用程序的開發和管理。
DB2 Cube Views 功能部件是如何做到這一點呢？首先，它允許 DB2 UDB 支持 OLAP。如果沒有多維數據視圖，關系數據庫對於不熟悉數據庫結構和內容的人來說似乎是一組令人生畏的帶有一些列的表。DB2 Cube VIEws 元數據使您能夠更完整地記錄 DB2 數據庫中的底層結構。
通常，倉庫或數據集市是特別為維分析設計的。在這種情況下，數據庫通常由被組織為一個或多個星型（或雪花型）模式的表組成。簡單的星型模式包含一個事實表，事實表周圍有一些維表。例如，事實表可以記錄公司各個產品和分店每日銷售數據。維表（或許是 PRODUCTS 和 STORES 表）可能包含有關各個產品和分店的詳細信息，並且與事實表相連接。
元數據對象
DB2 Cube Views 元數據尤其擅長捕獲星型或雪花型模式中固有的結構（請參閱 圖 1）。該元數據通過一組元數據對象提供關系數據的“空間視圖”。元數據對象被劃分為多層，從簡單對象（如 Attribute，簡單的 Attribute 對表列建模）到更復雜的對象（如 Join、Hierarchy、Dimension 和 Cube Model）。完整定義的多維數據模型對象通常符合星型（或雪花型）模式，並對一組具有公共維數的度量建模。然後，多維數據模型就封裝其它 DB2 Cube VIEws 元數據對象（如 Dimension 和 Measure），這一點都不奇怪。
圖 1. 引用關系星型模式的 DB2 Cube VIEws 多維數據模型
簡而言之，DB2 Cube VIEws 元數據使您能夠捕獲 DB2 數據庫的多維結構和設計。在 IBM DB2 Cube VIEws Setup and User's Guide 的第 2 章中詳細描述了元數據對象。
DB2 Cube VIEws 元數據除了使 DB2 支持 OLAP 外，至少還有兩種使用方法：
DB2 Cube VIEws 功能部件利用元數據來優化命中 DB2 數據庫的 SQL 查詢。
位於 DB2 UDB 之上的產品和應用程序可以使用元數據。
讓我們簡要地討論一下這兩種用法。
將 DB2 Cube VIEws 元數據用於優化
DB2 Cube VIEws 通過創建合適的實例化的查詢表（materialized query table，MQT）來加速 SQL 查詢，這些 MQT 中保存了預先聚集的數據。MQT 也稱為（自動）匯總表。如果可以，DB2 優化器會將 SQL 查詢重新路由給 MQT（請參閱 圖 2）。MQT 通常比底層的基本表（MQT 構建於這些基本表之上）小好幾個數量級。因而，對於同一個 SQL 查詢，將該查詢重新路由給 MQT 這種查詢方法通常比用查詢基本表的方法快得多。
DB2 Cube Views 有一個基於元數據和用戶輸入的優化顧問程序，它推薦一組合適的 MQT。有關更多信息，請參閱 DB2 Cube VIEws Setup and User's Guide中有關優化的章節。
圖 2. DB2 優化器在適當時將查詢路由到 MQT
元數據使用者
多維數據視圖元數據還有其它好處。商業智能工具可以從 DB2 UDB 讀取元數據來了解 DB2 表的維結構。然後，根據元數據，這些工具提供處理 DB2 UDB 數據的查詢和報告解決方案。
使用 DB2 Cube VIEws 元數據的工具和應用程序一般分為兩類：
第一類應用程序“咬住”DB2 Cube VIEws 。它們通常通過使用元數據來構造 SQL 查詢，以讀取元數據並直接用它對 DB2 數據庫進行分析。大多數情況下，這些工具對 DB2 Cube VIEws 多維數據模型和多維數據對象進行查詢和報告。
第二類工具使多維數據視圖元數據從 DB2 流入自己的工具，然後根據自己的元數據查詢 DB2。這些工具必須能夠將 DB2 Cube VIEws 元數據映射到自己的元數據。這一映射的復雜程度取決於元數據的相似程度（或相異程度）。
元數據生產者
請注意：並非所有對 DB2 Cube VIEws 元數據感興趣的應用程序都讀取元數據，這一點也很重要。還有一類工具和應用程序產生元數據並將它 推入 DB2。維元數據通常來自數據庫設計、抽取-轉換-裝入（extract-transform-load，ETL）和其它數據庫管理工具。通過使維元數據流入 DB2 UDB，這些工具可以利用先前提到的這些優化和管理好處。
顯然，為了讀取、創建、修改和刪除元數據對象，工具和應用程序需要一種與 DB2 中多維數據視圖元數據交互的方法。
DB2 Cube VIEws 為此提供了一個 API，我們接下來將研究它。
API — db2info.md_message() 的概述
DB2 Cube VIEws API 是用於訪問維元數據的接口。它以名為 db2info.md_message() 的 DB2 存儲過程的方式實現，該存儲過程為其所有參數傳入（出）XML 文檔。
存儲過程的優點是使該 API 變成與語言無關。任何可以與 DB2 交流的編程語言都可以調用這個存儲過程。可以使用嵌入式 SQL 和通過 ODBC 或 JDBC™ 的動態 SQL 等。
您可以從 DB2 Cube VIEw Setup and User's Guide 的附錄中獲得有關這個 API 的詳盡描述。在本文中，我們將向您演示幾個示例：向這個存儲過程傳入什麼，以及期望從它那兒返回什麼，通過這幾個示例來設法讓您更快地理解該存儲過程。
輸入參數
這個存儲過程的語法如下：
DBINFO.MD_MESSAGE(Operation IN, metadata IN/OUT, response OUT)
所有參數都屬於 CLOB 類型。
該存儲過程有兩個輸入參數。第一參數是必需的，它指定調用程序希望執行什麼操作。這些操作有：
DESCRIBE
CREATE
ALTER
RENAME
DROP
IMPORT
VALIDATE
某些操作（象 CREATE 和 IMPORT）需要通過第二個參數將元數據傳入這個存儲過程。操作 DESCRIBE 通過第二個參數返回元數據。
輸出參數
該存儲過程的第三個參數是輸出參數。對於對該存儲過程的每個調用，都會通過第三個參數返回響應文檔。然而，如果發生某些嚴重錯誤，則不會創建任何輸出響應文檔。
解析 XML
要使用 API，程序必須構造要傳入該存儲過程的 XML 文檔。還需要解析該存儲過程所返回的 XML。
DB2 Cube VIEws API 使用的 XML 的語法由隨該產品一起提供的 XSD 模式文件（位於 sqllib/cfg 目錄中）指定。您將使用的 XSD 模式文件如 表 1所示。
表 1. 與輸入和輸出參數相關聯的 XSD 文件
API 參數 模式文件 操作和響應
（第一個和第三個參數）
db2md_parameter.xsd 元數據（第二個參數） db2md_metadata.xsd 和db2md_types.xsd
使用 API
用於調用 md_message() 存儲過程的樣本 C++ 代碼與 DB2 Cube Views 產品一起提供，位於 sqllib/samples/olap/client/db2mdapiclIEnt.cpp 中。
關於用 Java™ 編寫的代碼，下面是使用 JDBC 來調用該存儲過程的樣本代碼片段：
/* Calls the DB2 stored procedure passing in the request string
* as the first parameter and the metadata string as the second
* parameter. If XMLRequestString contains a script or no output
* metadata is required the XMLMetadata parameter may be null.
* The outputMetadata boolean controls what is returned by the
* method. If it is true any output metadata is returned. If
* false the response output is returned. */
private String callDB2StoredProc(String XMLRequestString,
String XMLMetadataString,
boolean outputMetadata)
throws OCException,
OCApIException
{
/* Create an SQL command to call the Stored procedure in DB2
* to get the XML */
String sql = "CALL db2info.MD_MESSAGE (?, ?, ?)";
String response = null;
String XMLMetadataResponse = null;
CallableStatement callStmt = null;
try
{
callStmt = auroraCatalogConnection.prepareCall(sql);
/* Set input parameter to request and metadata strings. */
callStmt.setString (1, XMLRequestString);
callStmt.setString (2, XMLMetadataString);
/* Register the output parameters. */
callStmt.registerOutParameter (2, Types.VARCHAR);
callStmt.registerOutParameter (3, Types.VARCHAR);
/* Call the stored procedure */
callStmt.execute();
/* RetrIEve output parameters. If the procedure was called with
* a request that returns metadata in the middle parameter then
* xmlMetadataResponse will store the output XML. */
if (outputMetadata == true)
XMLMetadataResponse = callStmt.getString(2);
response = callStmt.getString(3);
/* See if there are any warnings. */
SQLWarning warning = callStmt.getWarnings();
/* If execute returns a warning with a non-zero SQL state
* then the API has had an error and returned some response
* info in the output XML document. */
if (warning != null)
{
OCLog.trace("Stored procedure execute returned a warning.");
OCLog.trace("SQL state: " + warning.getSQLState());
OCLog.trace("SQL state: " + warning.getErrorCode());
/* readResponseFromXML will throw an OCApIException containing
* the error info (which will then be thrown to our caller) or
* it will throw an OCException if a parsing error occurred. If
* for some strange reason the file does not contain error
* info it will just return and then we'll throw an OCException
* to notify the user. */
try { readResponseFromXML(response); }
/* If an API exception was thrown add the SQL state etc to
* it and then throw it again. */
catch (OCApiException apIE)
{
apIE.setSqlException(warning);
throw apIE;
}
/* If we have had a warning we always want to rollback any changes.
* If we have a problem rolling back the exception will be caught
* below. */
finally
{
auroraCatalogConnection.rollback();
}
/* If we got here there must have been a warning with nothing
* in the output XML so throw an exception explaining this. */
throw new OCException("OC_ERR_API_DB2_STORED_PROC_FAIL_NO_INFO");
}
}
/* If we had an error executing the SQL, log the information and
* throw an exception. We also rollback any changes and catch
* the exception if the rollback has a problem. */
catch (SQLException e)
{
OCApiException newe = new OCApIException(e);
OCLog.trace( newe.getMessage() );
logExceptionInfo(e);
try { auroraCatalogConnection.rollback(); }
catch (SQLException e2)
{
OCLog.trace("An exception also occurred rolling back.");
logExceptionInfo(e2);
}
throw newe;
}
讀取元數據
在獲得成功調用該 API 的一些代碼之後，將需要把注意力放在將正確的 XML 傳遞給該 API，以及能夠解析輸出 XML。
大多數程序將需要通過使用 DESCRIBE 操作來從 DB2 Cube VIEws 讀取元數據。下面是一些示例：
示例 1. 讀取所有元數據
下面是您要使用的操作 XML：
<
olap:request XMLns:olap="http://www.ibm.com/olap"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" version="8.1.2.1.0">
<describe objectType="all" recurse="no">
</describe>
</olap:request>
注：
調用程序和服務器上的 DB2 存儲過程之間的版本號（如 8.1.2.1.0）必須一致。
請注意，應該將請求標記限定為 <olap:request> 。
輸出時，第二個參數將返回包含元數據的 CLOB。通常會返回許多對象。如果 DB2 只有一個 Attribute 對象，那麼輸出元數據 XML 將類似於：
<olap:metadata XMLns:olap="http://www.ibm.com/olap"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" version="8.1.2.1.0">
<attribute name="FAMILY" schema="MDSAMPLE" businessName="FAMILY"
createTime="2003-04-11T21:28:22" creator="db2admin">
<datatype schema="SYSIBM" name="VARCHAR" length="15" scale="0"/>
<sqlExpression template="{$$1}">
<column name="FAMILY" tableSchema="MDSAMPLE" tableName="FAMILY"/>
</sqlExpression>
</attribute>
</olap:metadata>
如果成功，響應文檔將類似於：
<olap:response XMLns:olap="http://www.ibm.com/olap"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" version="8.1.2.1.0">
<describe>
<status id="0" text="Operation completed successfully. No errors were encountered."
type="informational"/>
</describe>
</olap:response>
示例 2. 獲取特定的多維數據模型及相關對象
下面是您將用來獲取 db2admin.MyCubeModel 的多維數據模型及其相關對象的操作 XML：
<olap:request XMLns:olap="http://www.ibm.com/olap"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" version="8.1.2.1.0">
<describe objectType="cubeModel"
recurse="yes">
<restriction>
<predicate property="name" Operator="=" value="MyCubeModel"/>
<predicate property="schema" Operator="=" value="db2admin"/>
</restriction>
</describe>
</olap:request>
注：
Recurse="yes" 告訴 API 返回多維數據模型以及該多維數據模型遞歸引用的所有對象。
請注意，謂詞的運用，謂詞指定我們感興趣的多維數據模型。
創建元數據
有兩個用於創建新元數據的操作：CREATE 和 IMPORT。在創建新的元數據時，使用 CREATE。如果您想要創建的對象碰巧與現有對象沖突（因為名稱相同），則使用 IMPORT。
示例. 在 DB2 Cube VIEws 中創建一些元數據對象
下面是您要使用的操作 XML：
<olap:request XMLns:olap="http://www.ibm.com/olap"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" version="8.1.2.1.0">
<create/>
</olap:request>
通過第二個參數以 XML 格式將一個或多個元數據對象傳遞給存儲過程。
改變元數據
有兩個用於修改元數據對象的操作：ALTER 和 RENAME。
示例 1. 改變連接對象
ALTER 操作類似於 CREATE，但被傳入的元數據對象必須已經存在。由新定義的對象替代原有對象。下面是您要使用的操作 XML：
<olap:request XMLns:olap="http://www.ibm.com/olap"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" version="8.1.2.1.0">
<alter/>
</olap:request>
對於元數據 XML，傳入我們想讓它成為的 Join 對象：
<join name="ProductFamily" schema="db2admin" businessName="ProductFamily"
type="inner" cardinality="n:1">
<attributeJoin Operator="=">
<leftAttributeRef name="FAMILYID" schema="db2admin"/>
<rightAttributeRef name="FAMILYID (FAMILY)" schema="db2admin"/>
</attributeJoin>
</join>
示例 2. 重命名多維數據模型對象
假設我們想要將多維數據模型對象 db2admin.SalesModel 重命名為 db2admin.SalesModel (2003) 。下面是做到這一點的操作 XML：
<olap:request XMLns:olap="http://www.ibm.com/olap"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" version="8.1.2.1.0">
<rename objectType="cubeModel">
<currentRef name="SalesModel" schema="db2admin"/>
<newRef name="SalesModel (2003)" schema="db2admin"/>
</rename>
</olap:request>
對於重命名，不需要元數據 XML。
刪除元數據
用 DROP 操作刪除元數據對象。
示例 1：刪除 所有元數據對象
執行該操作時必須小心！下面是要使用的操作 XML：
<olap:request XMLns:olap="http://www.ibm.com/olap"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" version="8.1.2.1.0">
<drop objectType="all"/>
</olap:request>
示例 2. 刪除多維數據對象及其相關對象
下面是刪除 db2admin.MyCube 及其相關對象的操作 XML。請注意，特殊的 <script> 標記，它可以在一次 API 調用中執行多次刪除：
<olap:request XMLns:olap="http://www.ibm.com/olap"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" version="8.1.2.1.0">
<script>
<drop objectType="cube">
<restriction>
<predicate property="name" Operator="=" value="My Cube"/>
<predicate property="schema" Operator="=" value="db2admin"/>
</restriction>
</drop>
<drop objectType="cubeFacts">
<restriction>
<predicate property="name" Operator="=" value="Cube Facts (My Cube)"/>
<predicate property="schema" Operator="=" value="db2admin"/>
</restriction>
</drop>
<drop objectType="cubeDimension"><restriction>
<predicate property="name" Operator="=" value="Market (My Cube)"/>
<predicate property="schema" Operator="=" value="db2admin"/>
</restriction></drop>
<drop objectType="cubeHIErarchy">
<restriction><predicate property="name" Operator="=" value="Region (My Cube)"/>
<predicate property="schema" Operator="=" value="db2admin"/>
</restriction>
</drop>
</script>
</olap:request>
無需傳入任何元數據 XML。
調試錯誤
盡管您必須習慣於消息中如何引用對象的命名約定，但是存儲過程中的大多數錯誤都相當清楚，無需解釋。正因如此，您常常不得不相當仔細地閱讀消息。
下面是報告錯誤的 API 響應示例。當我們試圖刪除已不存在的 Cube 對象（ db2admin.My Cube ）時，會返回下面的響應。（ 請注意：由於空間有限，狀態消息被分成兩行。）
<olap:response XMLns:olap="http://www.ibm.com/olap"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" version="8.1.2.1.0">
<drop>
<status id="6006" text="No objects were found matching search criteria:
"objectType=CUBE & name=My Cube & schema=db2admin"." type="warning">
<tokens>
<text value="objectType=CUBE & name=My Cube & schema=db2admin"/>
</tokens>
</status>
</drop>
</olap:response>
跟蹤
當發生錯誤而您又無法斷定 API 失敗的原因時，通常有必要打開 API 跟蹤。從高級別跟蹤（信息量最少）開始，僅當絕對需要時才打開中級或低級跟蹤（這些級別的信息要詳細得多）。
要打開跟蹤，請修改配置文件 db2md_config.xml ，如下所示。每個 DB2 實例都有一個這樣的文件，可以在實例目錄中找到它。在 Windows 上，缺省的 DB2 實例名為“DB2”，可以在 sqllib/DB2/db2md_config.xml 中找到這個配置文件。在下面的 XML 中，已經將跟蹤級別設置為 high。
<?XML version="1.0" encoding="UTF-8" ?>
<!-- <copyright> -->
<!-- Licensed Materials - Property of IBM -->
<!-- 5724-E15 -->
<!-- (c) Copyright IBM Corp. 2002, 2003 All Rights Reserved. -->
<!-- US Government Users Restricted Rights - Use, duplication or disclosure -->
<!-- restricted by GSA ADP Schedule Contract with IBM Corp. -->
<!-- </copyright> -->
<olap:config XMLns:olap="http://www.ibm.com/olap">
<log>
<trace level="
high" logFile="db2mdtrace.log" bufferSize="0"/>
<error level="medium" logFile="db2mderror.log" bufferSize="0"/>
</log>
</olap:config>
請注意：不要嘗試重命名跟蹤文件。其名稱必須是 db2mdtrace.log 。可以在實例目錄中找到跟蹤文件 db2mdtrace.log 。
創建元數據橋
元數據橋是將元數據從一種格式映射成另一種格式的軟件組件或實用程序。開發橋是為了在第三方商業智能或 OLAP 工具與 DB2 Cube VIEws 之間交換元數據。
圖 3. 元數據橋
例如，IBM 在 DB2 Cube Views 和 IBM DB2 OLAP Server™ 產品之間提供了橋。更准確地講，橋在 DB2 Cube VIEws 和 DB2 OLAP Server 的 OLAP 集成服務器附加功能部件之間交換元數據。
在規劃元數據橋時，有許多初始考慮事項。我們將更詳細地討論其中一些問題。
DB2 Cube VIEws 元數據對象模型與其它格式的對象模型相比，兼容性／相似程度如何？
橋應該是單向的還是雙向的？
同時可以映射什麼高級別的元數據分組？通常，多維數據模型或多維數據對象（以及所有引用對象）是橋的源或目標。
橋將支持並管理增量元數據更改嗎？
將使用何種編程語言？
該編程語言可以使用哪些 XML 解析器？
當使用 DB2 Cube VIEws 元數據時，橋將調用 API 來讀取元數據還是讀取導出的元數據 XML 文件？
當產生 DB2 Cube VIEws 元數據時，橋將調用 API 來創建元數據還是將元數據寫入 XML 文件？
映射練習
做映射練習是設計橋的首要步驟。做這個練習的架構設計師或開發人員必須通曉 DB2 Cube VIEws 元數據對象模型和其它元數據對象模型方面的應用知識。我們建議在原型設計和實現工作開始之前，仔細地記錄並復查映射。
如 表 2所示，每個 DB2 Cube VIEws 對象在進行映射時都有一些需要考慮的公共特性。
表 2. DB2 Cube VIEws 對象的公共特性
特性 說明 模式 當映射到 DB2 Cube Views 時，所有新對象通常都被放入單個模式中。但允許多維數據視圖對象引用其它不同模式中的多維數據視圖對象。DB2 Cube VIEws 中每個對象的完整名稱由它的模式和名稱構成，如 MYSCHEMA.MYATTRIBUTE 。
模式的長度不超過 30 個字節。
名稱 每個 DB2 Cube VIEws 對象類型都有自己的名稱空間，除了 Attribute 和 Measure 共享同一個名稱空間。因此，例如，Attribute 和 Join 可以具有同一個完整名稱。至 DB2 Cube VIEws 的橋通常必須生成一些目標對象的名稱。
名稱的長度不超過 128 個字節。
商業名稱 最多 128 個字節。 注釋 最多 254 個字節。 創建者 當映射到 DB2 Cube VIEws 時不需要。 創建時間 當映射到 DB2 Cube VIEws 時不需要。 修改者 當映射到 DB2 Cube VIEws 時不需要。 修改時間 當映射到 DB2 Cube VIEws 時不需要。必須對 DB2 Cube Views 對象模型進行研究，並將它與作為映射目標或源的元數據進行比較。請仔細地注意元數據間的差異，在映射元數據時，這些差異會導致元數據丟失。如果橋是雙向的，那麼在元數據往返時確定將如何改變元數據。對於大多數橋，不推薦使用元數據往返，因為您最終會得到一個與開始時明顯不同的元數據。 表 3 包括一些按對象類型分需要牢記的說明。當映射至 DB2 Cube Views 時，輸出元數據 XML 必須有效。XML 在語法上必須是正確的。橋應該通過依據模式文件 db2md_metadata.xsd 驗證它們輸出的 DB2 Cube VIEws 元數據 XML 來檢查是否格式良好。此外，輸出元數據必須遵守 DB2 Cube Views 指定的所有元數據驗證規則。在 DB2 Cube Views 中，有三種驗證級別。當映射到 DB2 Cube Views 時，遵守“基本”規則就足夠了。從 DB2 Cube Views 進行讀取的橋或許想要堅持：元數據要遵守“多維數據模型完整性”元數據規則。請參閱 Setup and User's Guide，以獲取有關 DB2 Cube VIEws 中元數據驗證級別的詳細信息。
表 3. 不同對象類型的映射說明
對象類型 映射說明 Attribute SQL 表達式模板是映射過程中最難的特性，因為它通常需要對表達式進行解析。另外，始於 DB2 Cube VIEws 的橋需要處理引用其它 Attribute 的 Attribute，並以遞歸方式遍歷所有 Attribute 來確定給定 Attribute 的最終 SQL 表達式。
當映射為 Attribute 時，不需要數據類型特性；當創建該 Attribute 時，由 DB2 多維數據視圖確定它。
Join 當映射到 DB2 Cube VIEws 時創建 Join 很重要，因為它們捕獲構建 Dimension 和 Cube Model 所需的結構信息。 Attribute Relationship 屬於 HIErarchy 的一部分。可在較復雜的 Cube Model 中找到它。 Measure 與 Attribute 的問題一樣（即 SQL 表達式模板的映射很難）。通常，橋對支持十分復雜的量方面有一些限制。 Facts 一組具有相同維數的 Measure。請注意，需要映射可選的 Attribute 和 Join。 Dimension 當創建 Dimension 時，請確保包括了所有的 Attribute。請注意，HIErarchy 和 Join 是可選的。 層次結構 請注意，Attribute 列表是經過排序的。還要注意，並不允許所有的類型和部署的組合。有時候，橋在可以映射的層次結構類型方面有一些限制。 Cube Model 它是橋在通常的映射過程中的最高一層對象。如果完全可能的話，至 DB2 Cube VIEws 的橋應該創建 Cube Model 對象。 Cube（和 Cube Facts、Cube Dimension、Cube HIErarchy） 被映射為 Cube Model 的一部分（如果它有意義的話）。使用者或生產者
橋可以產生或使用 DB2 Cube VIEws 元數據。人們常常期望橋是雙向的，而且通常先實現一個方向，然後再實現另一個方向。在這個實例中，我們建議先針對 兩個方向理解和記錄映射，即使只馬上實現了一個方向，也是如此。通過定義兩個方向的映射，將有助於確保映射是合理而完整的。
映射什麼
Cube Model 是 DB2 Cube VIEws 中豐富的元數據對象，它通常是橋進行映射過程中的對象。有時候，橋還會與 Cube Model 一起產生或使用 Cube 對象。
將元數據推入 DB2 UDB 的橋並不總是具有足夠的信息來創建 Cube Model。要創建 Cube Model，橋通常需要知道哪些表是事實表，哪些表是維表。如果橋沒有這些信息，那麼它仍可以創建象 Attribute 和 Join 之類比較簡單的對象，這些對象仍然要增加值。
增量更改
支持增量元數據更改是橋在企業倉庫環境中運用的一個重要特性。
所有多維數據視圖元數據對象都有一個“修改時間”，如在對象的 XML 表示中有 modifyTime="2003-03-25T09:54:51" 。使用這來確定已經更改了哪些元數據對象。API 沒有提供一種方法來查詢自某一時間戳記以來更改的所有對象，所以您必須讀取一組對象，然後檢查每個對象的修改時間。
使用這個 API 的 altER 或 IMPORT 操作，將元數據更改推入 DB2。通過使用 IMPORT 操作，可以決定是否要覆蓋已經更改的對象。還可以在實際執行導入之前發現哪些對象有沖突。請參閱 Setup and User's Guide中詳細描述的 IMPORT“方式”。
編程語言
如果映射是從 XML 到 XML 的映射，則常常考慮使用 XSLT。但要知道，有時候，映射所需的復雜邏輯難以用 XSLT 實現。我們所知道的大多數橋都是用 Java 或 C/C++ 實現的。
XML 解析器
可以選擇使用 Xerces 解析器。有關信息，請參閱 http://XML.apache.org/xerces-c/index.Html。
API 還是 XML 文件
不管是產生還是使用 DB2 Cube VIEws XML，橋都需要決定是調用 API 還是處理 XML 文件。這兩種方法各有優缺點。
使用 XML 文件的優缺點
使用 XML 文件的優點是橋可以獨立於 DB2 Cube VIEws 運行，如在另一個客戶機或服務器機器上運行。
使用 XML 文件的缺點是：
當使用多維數據視圖 XML 時，您不能確保元數據是有效的並與 DB2 中的關系模式同步。
當產生 DB2 多維數據視圖 XML 時，您不能確保稍後可以成功地導入元數據。
使用 API 的優缺點
使用 API 的優點是：
橋可以使用 VALIDATE 操作來確保它從 DB2 讀取的任何元數據都是有效的。
橋可以通過查詢 DB2 系統目錄表來讀取有關引用表和列的附加信息。
橋可以查看 DB2 中的所有元數據。
API 的缺點是實現橋所花的時間會較長，因為您需要添加代碼來調用 DB2 Cube VIEws API。程序將需要產生操作 XML 並解析響應 XML。
實現步驟
下面是如何成功地設計並實現橋的基本概述：
產生一個設計文檔，該文檔包括詳細的映射。
針對實際的測試案例設計原型並測試映射。根據需要，修訂設計。
實現橋（產品級代碼）。
對橋執行嚴格的 QA。
經驗告訴我們，典型的橋項目需要三個以上的人月來完成。一個月左右的時間用於設計，至少有一個月的時間用於實現，測試大致需要一個月。建議用戶進行 Beta 版測試。
結束語
IBM 鼓勵商業智能工具和解決方案的開發人員能夠使他們的產品與 DB2 UDB 的 DB2 Cube Views 功能部件相互操作。對於許多 OLAP 工具和應用程序，與 DB2 Cube VIEws 的集成需要通過使用基於 XML 的存儲過程接口來讀取或創建元數據。正如我們所看到的，在我們熟悉了存儲過程在輸入和輸出中所使用的 XML 語法之後，該接口就很簡單了。
在我們對 API 感到滿意之後，就可以從事將 DB2 Cube Views 元數據映射到其它格式的工作。有關為 DB2 Cube VIEws 構建元數據橋方面，我們已經分享了許多應牢記的考慮事項。對元數據進行合理映射的橋將受到解決方案構建者的高度贊揚，因為一個好的橋將為他們節省構建和部署解決方案的時間。
