DB2 最佳實踐: 使用 DB2 pureXML 管理 XML 數據的最佳實踐，第 1 部分：概述和基本配置

XML 數據用於提高性能和存儲有效性的存儲選項

◆對 DB2 DMS 表空間啟用自動存儲。

◆為 XML 數據使用更大的頁大小，比如 16KB 或 32KB 。

◆如果性能分析需要，就為 XML 數據選擇一個不同的表空間頁大小。

◆很多 XML 文檔足夠小並且能和其它 non-XML 數據存在數據頁上，就為 XML 文檔使用內 嵌存儲。否則文檔存放在表之外，類似於 LOBs，並且通過區域索引來訪問。

◆使用壓縮來減少 XML 文檔以 inline 方式存放時的空間大小。

在 DB2 數據庫中添加 XML 數據的技術：

◆為了提高你在使用 insert、import 或 load 添加數據時的性能，

◆使用使用較大頁大小的 DMS 表空間，比如 16KB 或 32KB 。

◆提供足夠的緩沖池空間以支持 XML 區域索引和路徑索引的讀取。

◆如果你有多個用戶定義的 XML 索引，通常最好在添加數據之前定義它們。

◆如果有必要，把行抽取選中的 XML 元素值放入到和 XML 文檔相同的關系列中。關系列 中存放的數據允許簡單、SQL-only 的形式來訪問重要的數據或經常訪問數據條目、可以定義 主鍵、外鍵或其它約束、以及可以定義多列（組合鍵）關系索引。

◆如果更小的片段更適合數據訪問的粒度，就把大型 XML 文檔分割成更小的片段。

◆定義觸發器來對插入和更新 XML 數據進行自動驗證

有效查詢並更新 XML 文檔的技術：

◆使用 SQL/XML 函數 XMLTABLE 或 XMLQUERY 來從 XML 文檔中抽取數據。

◆在SQL WHERE 子句中使用 XMLEXISTE 謂詞來指定對 XML 數據的謂詞 ，通過檢查更少的行來提高查詢性能。

◆使用一個完全指定的 XML 路徑，而不要使用通配符 * 或 // 來定位到期望的 XML 元素 。這樣做可以提供更好的性能，因為 DB2 可以跳過 XML 文檔中不相關的部分直接找到期望的 XML 元素。

◆出於增加商業洞察力和最大化一個混合數據庫服務器的價值的需要，你在查詢中需要要 對 XML 和關系數據進行連接。

◆當在一個 XML 文檔中更新多個元素時，把更新合並到一個轉換描述中以獲得最佳的更新 性能

◆在查詢中聲明名稱空間，更新 XML 索引以匹配你的 XML 商業數據。這個讓你能從多個 或復雜的域中處理 XML 文檔。

為什麼使用 XML

XML 提供了一個普通而具有彈性的方法來在不同的系統、應用程序和組織之間交換數據。 使用 XML，數據是在一個可擴展自描述格式下進行維護，以提供給所有涉及的商業需求。 XML 文檔是用標簽來描述它們包含的數據值，並且通過嵌套標簽來表示數據條目間的層次關系。 XML 可以描述高度結構化的數據並通過 XML 模式來保持結構，但是它也能描述半結構化的數 據，這些數據普遍存在於內容為導向的應用程序。

以服務為導向的架構（SOA）、企業應用程序整合（EAI）、企業信息整合（EII）、Web 服 務、企業消息總線和很多依賴於 XML 作為底層數據交換技術的標准化成就。

就像行業這樣的機構使用標准化的 XML 模式來促進信息交換並且發展那些模式來滿足變化 中的商業需求。這些努力包括在保險行業中的 ACORD、金融行業中的 FpML 和 FIXML、供應 鏈管理中的 違規廣告、零售商業中的 ARTS、衛生保健中的 HL7、商業報告裡的 XBRL 和在印 刷行業中用於授權、管理和發布文檔的 DITA 以及整個網絡。

這類具體行業創新（比如管理需求）在驅動 XML 發展。越來越多的企業事務通過基於網絡 接口和電子表格來操作。政府代理和商業企業對保留原始訂單、請求、申明、交易或簽名承擔 更多的責任。 XML 提供了一個簡單的方法來抓取並維護和那些電子交易相關的數據。事實上 ，XML 文檔常常在基於消息的事務系統中表現事務記錄。

XML 和關系數據的優缺點

作為一個自描述數據格式，XML 允許不同的數據（有模式或沒有）在不犧牲搜索或聚合能 力的情況下被同時存在一個文檔中或某一行中。應用程序可以在對底層數據庫模式不進行任何 改變的情況下發展他們自己的 XML 模式。然而，對於 XML 的這種擴展意味著比起存儲在關系 表中的數據在檢查和解釋 XML 數據時會花費更多的 CPU 和 I/O 資源 – 這可能不切實際。

對更多的剛性模式定義，關系模式需要更少的解釋並允許更多的優化數據操作。就像這樣 ，他可以提供非常高的性能，不過卻不能滿足應用程序需要的模式彈性。關系型數據模型非常 適合有穩定數據結構和可預知訪問形式的應用程序。 XML 更適合有復雜多變數據結構以及混 有結構化和非結構化信息的應用程序。

在某些情況下，XML 提供的性能好處超過了關系模型正好是因為它的彈性。關系型數據庫 經常需要標准化來使商業數據適應簡單平坦的結構。對復雜商業數據的標准化需要在數據存取 的時候進行轉化，並經常在關系型數據庫中導致多路的連接需求。 XML 可以在一個文檔中更 自然的表現復雜的商業對象以及對象間的所有關系。在一個 XML 文檔中的層次本質上就是預 先計算的相關數據條目之間的連接。

在選擇一個數據模式時的另外一個考慮是應用程序使用數據。就算數據源自 XML，如果數 據後來的處理取決於存儲在表格中的數據—例如，在一個數據倉庫中應用關系行在線分析處理 （OLAP）的數據—那麼把這些數據存入關系格式而非 XML 可能是正確的選擇。

關系數據模式問題的 XML 解決方案

為了最大的可能范圍，存儲數據的模型應該和你數據的最高值和最關鍵的使用模式相匹配 。如果數據被模式化成為自然表格，比起 XML 這通常表現為關系型格式更好。然而，有些情 況下關系型模式不是最好的選擇而且有時用來存儲數據甚至是很差的選擇。下面是用 XML 表 現比用關系型格式更好一些情況。

當模式不穩定時

關系型數據的問題：如果數據模式經常改變，那麼在關系表結果中表現的數據，更改關系 模式將產生成本和開銷。一些模式的表格更改在關系型數據庫中是無痛的，比如在表中增加一 個新列、把模式的其它表加入進來，還有就是刪除一列或更改一列的類型。不過模式的其它表 要更改（比如把一個表正常化進多個表中）會非常困難。首先要改變表然後應用程序需要改變 訪問的 SQL 語句。

XML 數據解決方案：模式中易變的那一部分可以作為一個單獨的 XML 列存在。 XML 天然 的自描述和易擴展功能可以無縫的處理模式變化和改進。 XML 文檔格式中的改變是在不需要 在數據庫中更改表或者列並且通常不需要破壞現有 XML 查詢。

當數據是自然的層次時

關系型數據的相關問題：天然分層或遞歸數據在關系模式中常常很難表現。例如包括原料 賬單、工程對象或生物學數據。一個原料清單可以存進一個關系型數據庫，不過可能需要遞歸 SQL 來把它部分或全部重新構建。

XML 數據解決方案：因為 XML 是一個層次型數據庫模式，它可以非常自然的表現本身就是 層次型的商業數據。如果相同數據表現為表格形式需要，使用 XML 可以用簡單、導行的數據 訪問來代替復雜的一系列操作。

當數據表現商業對象時

關系型數據的問題：如果應用程序數據要表現商業對象，比如保險保單，它經常從保留有 數據條目和一個詳細聲明的組合中得到好處，而不是把它們分散到一系列表中。這對一個保單 的那些本身沒有有效商業含義並且只能在有上下文的完整表單中被解釋的單獨的數據條目來說 尤其如此。通過數十個關系型表來正常化這個保單意味著應用程序處理一個復雜的並且對於他 們的商業來說是不成體系的數據。這增加了負載和出錯的幾率。

XML 數據的解決方案：XML 讓你可以表現非常復雜的商業對象比如緊密相關的文檔以及截 然不同的文檔同時還抓取所有組成商業對象的數據條目之間的關系。以一個在表中單獨一行裡 的 XML 文檔來表現每個保單（商業對象）為應用程序開發人員提供了非常直觀的存儲模型並 可以快速進行應用程序開發。

當對象有稀疏的屬性時

關系型數據的問題：某些程序有非常多的可能屬性，它們大多數很稀疏，例如，可以適應 非常少的對象。一類例子是一個產品編目，這裡不同產品屬性數目非常多，包括：大小、顏色 、重量、長度、高度、原料、款式、編織方法、伏特、決議、放水以及無止境的其它屬性。對 於任何產品，只和這些屬性的子集相關。一個可能的關系型方法是存儲這些數據時一個屬性一 列，這意味著表中包含 NULL 值得單元占非常大的比例。這是不期望的並且是低效率的。對這 些稀疏數據的另一個不同的關系型方法是一個有 3 列的表，對每個產品 ID 存儲了幾對名字 / 值。這意味著屬性的名字不是列名不過是在 VARCHAR 列中的值。這使得關系型數據不能精 確的估計可選約束和生成一個有效的查詢計劃。要定義並執行一個約束同樣非常困難，比如對 一個特定屬性的唯一性約束。

XML 數據解決方案：XML 的美妙之處就是元素和屬性是可選的，例如，如果不需要應用一 個特定的產品他們完全可以省略。無論是 NULL 值還是名稱以及值都不需要。 XML 模式可以 定義非常多的可選元素，卻對所有對象只使用它們中的一部分。在一個關系型表中每一行必須 有相同的列， XML 列中的 XML 文檔每一行可以有不同的元素。同樣，如果這個元素只有很小 的百分比，這個可選元素的 XML 索引可能非常小。這對每一行都有嚴格輸入的關系型索引的 一個很明顯的優勢。

當數據需要交換時

關系數據的問題：如果你從關系表中導出一批記錄並把它們發送到另外一個應用程序或組 織中，接收者不能在沒有額外數據來描述這一列的情況下解釋數據。如果你的關系模式從你上 次發送數據開始已經改變的情況下，尤其如此。

XML 數據解決方案：XML 是自描述數據。 XML 標簽是描述它們嵌套值的元數據。

DB2 pureXML 超過其它存儲選項的優勢

因為 XML 已經日益變成企業運營的關鍵，XML 文檔是一種資產共享、保持、搜索、保護和 更新並保持完全的事務一致性。基於它的用途，XML 數據也可能需要與其它數據進行轉換、審 計和整合。為了達到這些要求，把 XML 數據在 DB2 數據庫中存成自然層次格式，這有很多好 處，包括：

◆注意 XML 數據的內部結構。這對在數據庫中以字符或二進制大對象（CLIBs 或 BLOBs） 的形式來存儲 XML 文檔具有優勢。准確的說，你可以很容易使用 XQuery、XPath 和 SQL/XML 利用 XML 結構來查詢 XML 數據，而且你可以通過對 XML 數據創建索引來提高查詢性能。另 外，你可以很容易的使用 SQL、XQuery 和 XSLT 來更新、轉換並發布 XML 數據。

◆維護 XML 數據的層次和靈活的性質。這在分解（切割）XML 文檔到關系型表中，在這裡 管理員映射 XML 元素和屬性到關系列中。在分解後，XML 文檔之被存儲在這些表中並且沒有 最初的標簽。分解常常需要大量的表，而且實際使用中非常復雜。查詢分解後的 XML 文檔可 能需要復雜的 SQL 連接，這很難開發和調試。改變 XML 模式常常會破壞對關系數據庫模式的 映射。這會使維護變得昂貴和耗時，並違背了出於靈活性而選擇 XML 的初衷。這也是為什麼 DB2 pureXML 允許你適應一個 XML 列來存儲和查詢基於不同 XML 模式的 XML 文檔，或一個 XML 模式的不同版本。

◆在一個數據庫中整合 XML 文檔和關系數據。這比在兩個數據庫中分別存儲關系數據和 XML 文檔 -XML-only 數據庫更有優勢。後者需要技巧和人力來操作並維護兩個數據庫系統而 不僅僅是一個。同樣，從兩個數據庫中聯合數據，通常需要應用程序有額外的邏輯，而這常常 很困難且效率低。當你在一個 DB2 數據庫中同時存儲 XML 和關系數據時，可以在查詢中聯合 兩種類型的數據，甚至可以根據需要把一種轉數據換成另外一種。這樣做更加劃算而且比起使 用兩個不同的數據庫，它提供了更好的性能。

DB2 pureXML 的最佳實踐：概述

DB2 pureXML 功能提供了在存儲、索引、驗證和查詢 XML 數據上成熟的能力 – 並完全整 合了 DB2 關系型數據管理功能。本文描述了以有效並高效的方式使用 pureXML 的原則。本文 的目標不是介紹 pureXML 功能或者它們如何工作。相反本文提供了保證高性能 pureXML 的指 南，也示范了如何開發 pureXML 功能來有效的解決特定的商業問題。

我們使用一個現實世界的應用程序場景來安排最佳實踐和本文中的例子。這是來自金融行 業的場景而且是基於 XML 格式的叫做 FpML（金融產品標記語言）的“金融衍生交易”的交易 和管理。你不需要一個金融專家來理解這個場景。雖然我們只使用這個特定的場景，最佳實踐 同樣應用到其它 XML 使用情況，比如 XML 表格處理、訂單管理系統、XML 在健康保健和電子 病歷，和其它情況

本文的主題是根據數據庫對象的生命周期粗略組織的。我們這個章節從查看應用程序需要 的數據和表開始。然後我們討論 DB2 對 XML 數據（第 4 章）的存儲選項。之後 , 第 5 章 提供了添加 XML 數據到 DB2 數據庫的竅門和技巧。在第 6 章我們提供了更有效查詢 XML 數 據的指南和例子。為了提高查詢性能，定義和使用 XML 索引的最佳實踐在第 7 章中進行了介 紹。 XML 名稱空間和 XML 更新在第 8 章和第 9 章中分別有所討論。第 10 章和 11 章涵蓋 了對數據庫管理員（DBAs）以及應用程序開發的附加的主題。最後，12 章以總結最重要的指 南作為結束。

簡單場景：FpML 形式中的金融衍生交易

一個“金融衍生交易”是一個基於（起源於）其它一些金融資產的金融交易，比如股票、 指數、利率、流通、或其它的。在一個金融衍生交易中，根據影響底層資產的市場條件，當事 人雙方同意交易現金。通常情況下，一方利用交易以減輕風險；另外一方利用這個交易來獲得 立即的收入（通過費用或額外費用）或對未來市場情況將提供收益進行投機。讓我們看一個例 子：

YourWord Investments 和 MyGlobal Back 達成了一個外匯兌換交易。他們商議在 10 月 25 號 YourWord 將支付 71,900,000 人民幣給 MyGlobal，並且 MyGlobal 將支付 10,000,000 美元給 YourWorld 。如果 1 美元兌換人民幣從現在到 10 月 25 日其間低於 7.19，MyGlobal 將從這次交易中獲利 .MyGlobal 可能會使用這個交易來避免美元下降的風險 。 YourWorld 可以投機美元將增值，或從 MyGlobal 收取進行交易的前期費用。

衍生交易的奇妙之處是（a）有很多不同的類型和變化，（b）一個特定交易的狀態往往需 要單獨談判而且很復雜，（c）一個衍生交易的生命周期可以是從幾天到數年的范圍而且它們 的條件可以隨時間而改變。金融企業發現在定義一個可以捕捉到衍生交易高度變化標准的數據 格式時需要 XML 的靈活性和可擴展性。結果就是，他們開發了 FpML 。 FpML 本質上是定義 了 XML 元素和屬性如何用來描述金融衍生交易的一個 XML 模式。 International Swaps and Derivatives Association, Inc (ISDA) 代表一個投資銀行組織管理 FpML 標准使市場在場外 進行衍生交易。更多金融衍生交易和 FpML 的信息參考【 8 】和【 9 】。

樣本數據和表

本文的樣本數據庫由 3 個表組成，見清單 1。

清單 1. 定義樣本表

create　table　trades　(tradeId　integer,　tradedoc　

XML);　
　create　table　partIEs(partyInfo　XML);　
　create　table　currencIEs(symbol　char(4),　name　varchar(30),　USDvalue　double,　
　　　　　　　　　　　　lastUpdated　

timestamp);

所有的表定義和命令以使用樣本數據來填充它們，以及需要本文中顯示的其它語句可以在 中以文本文件的形式下載。

TRADES 表包含 FpML 文檔和每個文檔的交易 ID 。每個交易文檔涉及兩個交易方使文檔中 用 PRTYID 元素的值。更多關於各個部分詳細信息都以 XML 格式存放在 PARTIES 表中。我們 可以從一個 TRADES 和 PARTIES 之間的 XML 到 XML 連接中找到相關交易的詳細資料，反之 亦然。很多 FpML 交易通過標記來引用具體貨幣。額外的貨幣信息在關系型中可以在 CURRENCIES 表中，如清單 2 所示。我們需要 XML 到關系型表的連接來把相關交易和貨幣信 息聯系起來。

清單 2. currency表中的內容

SYMBOL　NAME　　　　　　　　　　　　　　USDVALUE　

　LASTUPDATED　
　------　------------------------------　--------　　-------------------　
　USD　　US　Dollar　　　　　　　　　　　　　1.000　　2008-02-05-15.15.57　
　EUR　　Euro　　　　　　　　　　　　　　　1.460　　2008-02-05-15.15.59　
　GBP　　Great　Britain　Pounds　　　　　　　1.960　　2008-02-05-15.16.23　
　JPY　　Japanese　Yen　　　　　　　　　　　0.009　　2008-02-05-15.15.53　
　CNY　　Chinese　Yuan　(Renminbi,　RMB)　　　7.190　　2008-02-05-

15.16.13