利用DB2 pureXML管理XML數(shù)據(jù)實踐
XML 數(shù)據(jù)用于提高性能和存儲有效性的存儲選項
◆對 DB2 DMS 表空間啟用自動存儲。
◆為 XML 數(shù)據(jù)使用更大的頁大小，比如 16KB 或 32KB 。
◆如果性能分析需要，就為 XML 數(shù)據(jù)選擇一個不同的表空間頁大小。
◆很多 XML 文檔足夠小并且能和其它 non-XML 數(shù)據(jù)存在數(shù)據(jù)頁上，就為 XML 文檔使用內(nèi) 嵌存儲。否則文檔存放在表之外，類似于 LOBs，并且通過區(qū)域索引來訪問。
◆使用壓縮來減少 XML 文檔以 inline 方式存放時的空間大小。
在 DB2 數(shù)據(jù)庫中添加 XML 數(shù)據(jù)的技術(shù)：
◆為了提高你在使用 insert、import 或 load 添加數(shù)據(jù)時的性能，
◆使用使用較大頁大小的 DMS 表空間，比如 16KB 或 32KB 。
◆提供足夠的緩沖池空間以支持 XML 區(qū)域索引和路徑索引的讀取。
◆如果你有多個用戶定義的 XML 索引，通常最好在添加數(shù)據(jù)之前定義它們。
◆如果有必要，把行抽取選中的 XML 元素值放入到和 XML 文檔相同的關(guān)系列中。關(guān)系列 中存放的數(shù)據(jù)允許簡單、SQL-only 的形式來訪問重要的數(shù)據(jù)或經(jīng)常訪問數(shù)據(jù)條目、可以定義 主鍵、外鍵或其它約束、以及可以定義多列（組合鍵）關(guān)系索引。
◆如果更小的片段更適合數(shù)據(jù)訪問的粒度，就把大型 XML 文檔分割成更小的片段。
◆定義觸發(fā)器來對插入和更新 XML 數(shù)據(jù)進行自動驗證
有效查詢并更新 XML 文檔的技術(shù)：
◆使用 SQL/XML 函數(shù) XMLTABLE 或 XMLQUERY 來從 XML 文檔中抽取數(shù)據(jù)。
◆在SQL WHERE 子句中使用 XMLEXISTE 謂詞來指定對 XML 數(shù)據(jù)的謂詞 ，通過檢查更少的行來提高查詢性能。
◆使用一個完全指定的 XML 路徑，而不要使用通配符 * 或 // 來定位到期望的 XML 元素 。這樣做可以提供更好的性能，因為 DB2 可以跳過 XML 文檔中不相關(guān)的部分直接找到期望的 XML 元素。
◆出于增加商業(yè)洞察力和最大化一個混合數(shù)據(jù)庫服務(wù)器的價值的需要，你在查詢中需要要 對 XML 和關(guān)系數(shù)據(jù)進行連接。
◆當在一個 XML 文檔中更新多個元素時，把更新合并到一個轉(zhuǎn)換描述中以獲得最佳的更新 性能
◆在查詢中聲明名稱空間，更新 XML 索引以匹配你的 XML 商業(yè)數(shù)據(jù)。這個讓你能從多個 或復雜的域中處理 XML 文檔。
為什么使用 XML
XML 提供了一個普通而具有彈性的方法來在不同的系統(tǒng)、應(yīng)用程序和組織之間交換數(shù)據(jù)。 使用 XML，數(shù)據(jù)是在一個可擴展自描述格式下進行維護，以提供給所有涉及的商業(yè)需求。 XML 文檔是用標簽來描述它們包含的數(shù)據(jù)值，并且通過嵌套標簽來表示數(shù)據(jù)條目間的層次關(guān)系。 XML 可以描述高度結(jié)構(gòu)化的數(shù)據(jù)并通過 XML 模式來保持結(jié)構(gòu)，但是它也能描述半結(jié)構(gòu)化的數(shù) 據(jù)，這些數(shù)據(jù)普遍存在于內(nèi)容為導向的應(yīng)用程序。
以服務(wù)為導向的架構(gòu)（SOA）、企業(yè)應(yīng)用程序整合（EAI）、企業(yè)信息整合（EII）、Web 服 務(wù)、企業(yè)消息總線和很多依賴于 XML 作為底層數(shù)據(jù)交換技術(shù)的標準化成就。
就像行業(yè)這樣的機構(gòu)使用標準化的 XML 模式來促進信息交換并且發(fā)展那些模式來滿足變化 中的商業(yè)需求。這些努力包括在保險行業(yè)中的 ACORD、金融行業(yè)中的 FpML 和 FIXML、供應(yīng) 鏈管理中的 違規(guī)廣告、零售商業(yè)中的 ARTS、衛(wèi)生保健中的 HL7、商業(yè)報告里的 XBRL 和在印 刷行業(yè)中用于授權(quán)、管理和發(fā)布文檔的 DITA 以及整個網(wǎng)絡(luò)。
這類具體行業(yè)創(chuàng)新（比如管理需求）在驅(qū)動 XML 發(fā)展。越來越多的企業(yè)事務(wù)通過基于網(wǎng)絡(luò) 接口和電子表格來操作。政府代理和商業(yè)企業(yè)對保留原始訂單、請求、申明、交易或簽名承擔 更多的責任。 XML 提供了一個簡單的方法來抓取并維護和那些電子交易相關(guān)的數(shù)據(jù)。事實上 ，XML 文檔常常在基于消息的事務(wù)系統(tǒng)中表現(xiàn)事務(wù)記錄。
XML 和關(guān)系數(shù)據(jù)的優(yōu)缺點
作為一個自描述數(shù)據(jù)格式，XML 允許不同的數(shù)據(jù)（有模式或沒有）在不犧牲搜索或聚合能 力的情況下被同時存在一個文檔中或某一行中。應(yīng)用程序可以在對底層數(shù)據(jù)庫模式不進行任何 改變的情況下發(fā)展他們自己的 XML 模式。然而，對于 XML 的這種擴展意味著比起存儲在關(guān)系 表中的數(shù)據(jù)在檢查和解釋 XML 數(shù)據(jù)時會花費更多的 CPU 和 I/O 資源 – 這可能不切實際。
對更多的剛性模式定義，關(guān)系模式需要更少的解釋并允許更多的優(yōu)化數(shù)據(jù)操作。就像這樣 ，他可以提供非常高的性能，不過卻不能滿足應(yīng)用程序需要的模式彈性。關(guān)系型數(shù)據(jù)模型非常 適合有穩(wěn)定數(shù)據(jù)結(jié)構(gòu)和可預知訪問形式的應(yīng)用程序。 XML 更適合有復雜多變數(shù)據(jù)結(jié)構(gòu)以及混 有結(jié)構(gòu)化和非結(jié)構(gòu)化信息的應(yīng)用程序。
在某些情況下，XML 提供的性能好處超過了關(guān)系模型正好是因為它的彈性。關(guān)系型數(shù)據(jù)庫 經(jīng)常需要標準化來使商業(yè)數(shù)據(jù)適應(yīng)簡單平坦的結(jié)構(gòu)。對復雜商業(yè)數(shù)據(jù)的標準化需要在數(shù)據(jù)存取 的時候進行轉(zhuǎn)化，并經(jīng)常在關(guān)系型數(shù)據(jù)庫中導致多路的連接需求。 XML 可以在一個文檔中更 自然的表現(xiàn)復雜的商業(yè)對象以及對象間的所有關(guān)系。在一個 XML 文檔中的層次本質(zhì)上就是預 先計算的相關(guān)數(shù)據(jù)條目之間的連接。
在選擇一個數(shù)據(jù)模式時的另外一個考慮是應(yīng)用程序使用數(shù)據(jù)。就算數(shù)據(jù)源自 XML，如果數(shù) 據(jù)后來的處理取決于存儲在表格中的數(shù)據(jù)—例如，在一個數(shù)據(jù)倉庫中應(yīng)用關(guān)系行在線分析處理 （OLAP）的數(shù)據(jù)—那么把這些數(shù)據(jù)存入關(guān)系格式而非 XML 可能是正確的選擇。
關(guān)系數(shù)據(jù)模式問題的 XML 解決方案
為了最大的可能范圍，存儲數(shù)據(jù)的模型應(yīng)該和你數(shù)據(jù)的最高值和最關(guān)鍵的使用模式相匹配 。如果數(shù)據(jù)被模式化成為自然表格，比起 XML 這通常表現(xiàn)為關(guān)系型格式更好。然而，有些情 況下關(guān)系型模式不是最好的選擇而且有時用來存儲數(shù)據(jù)甚至是很差的選擇。下面是用 XML 表 現(xiàn)比用關(guān)系型格式更好一些情況。
當模式不穩(wěn)定時
關(guān)系型數(shù)據(jù)的問題：如果數(shù)據(jù)模式經(jīng)常改變，那么在關(guān)系表結(jié)果中表現(xiàn)的數(shù)據(jù)，更改關(guān)系 模式將產(chǎn)生成本和開銷。一些模式的表格更改在關(guān)系型數(shù)據(jù)庫中是無痛的，比如在表中增加一 個新列、把模式的其它表加入進來，還有就是刪除一列或更改一列的類型。不過模式的其它表 要更改（比如把一個表正常化進多個表中）會非常困難。首先要改變表然后應(yīng)用程序需要改變 訪問的 SQL 語句。
XML 數(shù)據(jù)解決方案：模式中易變的那一部分可以作為一個單獨的 XML 列存在。 XML 天然 的自描述和易擴展功能可以無縫的處理模式變化和改進。 XML 文檔格式中的改變是在不需要 在數(shù)據(jù)庫中更改表或者列并且通常不需要破壞現(xiàn)有 XML 查詢。
當數(shù)據(jù)是自然的層次時
關(guān)系型數(shù)據(jù)的相關(guān)問題：天然分層或遞歸數(shù)據(jù)在關(guān)系模式中常常很難表現(xiàn)。例如包括原料 賬單、工程對象或生物學數(shù)據(jù)。一個原料清單可以存進一個關(guān)系型數(shù)據(jù)庫，不過可能需要遞歸 SQL 來把它部分或全部重新構(gòu)建。
XML 數(shù)據(jù)解決方案：因為 XML 是一個層次型數(shù)據(jù)庫模式，它可以非常自然的表現(xiàn)本身就是 層次型的商業(yè)數(shù)據(jù)。如果相同數(shù)據(jù)表現(xiàn)為表格形式需要，使用 XML 可以用簡單、導行的數(shù)據(jù) 訪問來代替復雜的一系列操作。
當數(shù)據(jù)表現(xiàn)商業(yè)對象時
關(guān)系型數(shù)據(jù)的問題：如果應(yīng)用程序數(shù)據(jù)要表現(xiàn)商業(yè)對象，比如保險保單，它經(jīng)常從保留有 數(shù)據(jù)條目和一個詳細聲明的組合中得到好處，而不是把它們分散到一系列表中。這對一個保單 的那些本身沒有有效商業(yè)含義并且只能在有上下文的完整表單中被解釋的單獨的數(shù)據(jù)條目來說 尤其如此。通過數(shù)十個關(guān)系型表來正常化這個保單意味著應(yīng)用程序處理一個復雜的并且對于他 們的商業(yè)來說是不成體系的數(shù)據(jù)。這增加了負載和出錯的幾率。
XML 數(shù)據(jù)的解決方案：XML 讓你可以表現(xiàn)非常復雜的商業(yè)對象比如緊密相關(guān)的文檔以及截 然不同的文檔同時還抓取所有組成商業(yè)對象的數(shù)據(jù)條目之間的關(guān)系。以一個在表中單獨一行里 的 XML 文檔來表現(xiàn)每個保單（商業(yè)對象）為應(yīng)用程序開發(fā)人員提供了非常直觀的存儲模型并 可以快速進行應(yīng)用程序開發(fā)。
當對象有稀疏的屬性時
關(guān)系型數(shù)據(jù)的問題：某些程序有非常多的可能屬性，它們大多數(shù)很稀疏，例如，可以適應(yīng) 非常少的對象。一類例子是一個產(chǎn)品編目，這里不同產(chǎn)品屬性數(shù)目非常多，包括：大小、顏色 、重量、長度、高度、原料、款式、編織方法、伏特、決議、放水以及無止境的其它屬性。對 于任何產(chǎn)品，只和這些屬性的子集相關(guān)。一個可能的關(guān)系型方法是存儲這些數(shù)據(jù)時一個屬性一 列，這意味著表中包含 NULL 值得單元占非常大的比例。這是不期望的并且是低效率的。對這 些稀疏數(shù)據(jù)的另一個不同的關(guān)系型方法是一個有 3 列的表，對每個產(chǎn)品 ID 存儲了幾對名字 / 值。這意味著屬性的名字不是列名不過是在 VARCHAR 列中的值。這使得關(guān)系型數(shù)據(jù)不能精 確的估計可選約束和生成一個有效的查詢計劃。要定義并執(zhí)行一個約束同樣非常困難，比如對 一個特定屬性的唯一性約束。
XML 數(shù)據(jù)解決方案：XML 的美妙之處就是元素和屬性是可選的，例如，如果不需要應(yīng)用一 個特定的產(chǎn)品他們完全可以省略。無論是 NULL 值還是名稱以及值都不需要。 XML 模式可以 定義非常多的可選元素，卻對所有對象只使用它們中的一部分。在一個關(guān)系型表中每一行必須 有相同的列， XML 列中的 XML 文檔每一行可以有不同的元素。同樣，如果這個元素只有很小 的百分比，這個可選元素的 XML 索引可能非常小。這對每一行都有嚴格輸入的關(guān)系型索引的 一個很明顯的優(yōu)勢。
當數(shù)據(jù)需要交換時
關(guān)系數(shù)據(jù)的問題：如果你從關(guān)系表中導出一批記錄并把它們發(fā)送到另外一個應(yīng)用程序或組 織中，接收者不能在沒有額外數(shù)據(jù)來描述這一列的情況下解釋數(shù)據(jù)。如果你的關(guān)系模式從你上 次發(fā)送數(shù)據(jù)開始已經(jīng)改變的情況下，尤其如此。
XML 數(shù)據(jù)解決方案：XML 是自描述數(shù)據(jù)。 XML 標簽是描述它們嵌套值的元數(shù)據(jù)。
DB2 pureXML 超過其它存儲選項的優(yōu)勢
因為 XML 已經(jīng)日益變成企業(yè)運營的關(guān)鍵，XML 文檔是一種資產(chǎn)共享、保持、搜索、保護和 更新并保持完全的事務(wù)一致性。基于它的用途，XML 數(shù)據(jù)也可能需要與其它數(shù)據(jù)進行轉(zhuǎn)換、審 計和整合。為了達到這些要求，把 XML 數(shù)據(jù)在 DB2 數(shù)據(jù)庫中存成自然層次格式，這有很多好 處，包括：
◆注意 XML 數(shù)據(jù)的內(nèi)部結(jié)構(gòu)。這對在數(shù)據(jù)庫中以字符或二進制大對象（CLIBs 或 BLOBs） 的形式來存儲 XML 文檔具有優(yōu)勢。準確的說，你可以很容易使用 XQuery、XPath 和 SQL/XML 利用 XML 結(jié)構(gòu)來查詢 XML 數(shù)據(jù)，而且你可以通過對 XML 數(shù)據(jù)創(chuàng)建索引來提高查詢性能。另 外，你可以很容易的使用 SQL、XQuery 和 XSLT 來更新、轉(zhuǎn)換并發(fā)布 XML 數(shù)據(jù)。
◆維護 XML 數(shù)據(jù)的層次和靈活的性質(zhì)。這在分解（切割）XML 文檔到關(guān)系型表中，在這里 管理員映射 XML 元素和屬性到關(guān)系列中。在分解后，XML 文檔之被存儲在這些表中并且沒有 最初的標簽。分解常常需要大量的表，而且實際使用中非常復雜。查詢分解后的 XML 文檔可 能需要復雜的 SQL 連接，這很難開發(fā)和調(diào)試。改變 XML 模式常常會破壞對關(guān)系數(shù)據(jù)庫模式的 映射。這會使維護變得昂貴和耗時，并違背了出于靈活性而選擇 XML 的初衷。這也是為什么 DB2 pureXML 允許你適應(yīng)一個 XML 列來存儲和查詢基于不同 XML 模式的 XML 文檔，或一個 XML 模式的不同版本。
◆在一個數(shù)據(jù)庫中整合 XML 文檔和關(guān)系數(shù)據(jù)。這比在兩個數(shù)據(jù)庫中分別存儲關(guān)系數(shù)據(jù)和 XML 文檔 -XML-only 數(shù)據(jù)庫更有優(yōu)勢。后者需要技巧和人力來操作并維護兩個數(shù)據(jù)庫系統(tǒng)而 不僅僅是一個。同樣，從兩個數(shù)據(jù)庫中聯(lián)合數(shù)據(jù)，通常需要應(yīng)用程序有額外的邏輯，而這常常 很困難且效率低。當你在一個 DB2 數(shù)據(jù)庫中同時存儲 XML 和關(guān)系數(shù)據(jù)時，可以在查詢中聯(lián)合 兩種類型的數(shù)據(jù)，甚至可以根據(jù)需要把一種轉(zhuǎn)數(shù)據(jù)換成另外一種。這樣做更加劃算而且比起使 用兩個不同的數(shù)據(jù)庫，它提供了更好的性能。
DB2 pureXML 的最佳實踐：概述
DB2 pureXML 功能提供了在存儲、索引、驗證和查詢 XML 數(shù)據(jù)上成熟的能力 – 并完全整 合了 DB2 關(guān)系型數(shù)據(jù)管理功能。本文描述了以有效并高效的方式使用 pureXML 的原則。本文 的目標不是介紹 pureXML 功能或者它們?nèi)绾喂ぷ鳌Ｏ喾幢疚奶峁┝吮ＷC高性能 pureXML 的指 南，也示范了如何開發(fā) pureXML 功能來有效的解決特定的商業(yè)問題。
我們使用一個現(xiàn)實世界的應(yīng)用程序場景來安排最佳實踐和本文中的例子。這是來自金融行 業(yè)的場景而且是基于 XML 格式的叫做 FpML（金融產(chǎn)品標記語言）的“金融衍生交易”的交易 和管理。你不需要一個金融專家來理解這個場景。雖然我們只使用這個特定的場景，最佳實踐 同樣應(yīng)用到其它 XML 使用情況，比如 XML 表格處理、訂單管理系統(tǒng)、XML 在健康保健和電子 病歷，和其它情況
本文的主題是根據(jù)數(shù)據(jù)庫對象的生命周期粗略組織的。我們這個章節(jié)從查看應(yīng)用程序需要 的數(shù)據(jù)和表開始。然后我們討論 DB2 對 XML 數(shù)據(jù)（第 4 章）的存儲選項。之后 , 第 5 章 提供了添加 XML 數(shù)據(jù)到 DB2 數(shù)據(jù)庫的竅門和技巧。在第 6 章我們提供了更有效查詢 XML 數(shù) 據(jù)的指南和例子。為了提高查詢性能，定義和使用 XML 索引的最佳實踐在第 7 章中進行了介 紹。 XML 名稱空間和 XML 更新在第 8 章和第 9 章中分別有所討論。第 10 章和 11 章涵蓋 了對數(shù)據(jù)庫管理員（DBAs）以及應(yīng)用程序開發(fā)的附加的主題。最后，12 章以總結(jié)最重要的指 南作為結(jié)束。
簡單場景：FpML 形式中的金融衍生交易
一個“金融衍生交易”是一個基于（起源于）其它一些金融資產(chǎn)的金融交易，比如股票、 指數(shù)、利率、流通、或其它的。在一個金融衍生交易中，根據(jù)影響底層資產(chǎn)的市場條件，當事 人雙方同意交易現(xiàn)金。通常情況下，一方利用交易以減輕風險；另外一方利用這個交易來獲得 立即的收入（通過費用或額外費用）或?qū)ξ磥硎袌銮闆r將提供收益進行投機。讓我們看一個例 子：
YourWord Investments 和 MyGlobal Back 達成了一個外匯兌換交易。他們商議在 10 月 25 號 YourWord 將支付 71,900,000 人民幣給 MyGlobal，并且 MyGlobal 將支付 10,000,000 美元給 YourWorld 。如果 1 美元兌換人民幣從現(xiàn)在到 10 月 25 日其間低于 7.19，MyGlobal 將從這次交易中獲利 .MyGlobal 可能會使用這個交易來避免美元下降的風險 。 YourWorld 可以投機美元將增值，或從 MyGlobal 收取進行交易的前期費用。
衍生交易的奇妙之處是（a）有很多不同的類型和變化，（b）一個特定交易的狀態(tài)往往需 要單獨談判而且很復雜，（c）一個衍生交易的生命周期可以是從幾天到數(shù)年的范圍而且它們 的條件可以隨時間而改變。金融企業(yè)發(fā)現(xiàn)在定義一個可以捕捉到衍生交易高度變化標準的數(shù)據(jù) 格式時需要 XML 的靈活性和可擴展性。結(jié)果就是，他們開發(fā)了 FpML 。 FpML 本質(zhì)上是定義 了 XML 元素和屬性如何用來描述金融衍生交易的一個 XML 模式。 International Swaps and Derivatives Association, Inc (ISDA) 代表一個投資銀行組織管理 FpML 標準使市場在場外 進行衍生交易。更多金融衍生交易和 FpML 的信息參考【 8 】和【 9 】。
樣本數(shù)據(jù)和表
本文的樣本數(shù)據(jù)庫由 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); |
所有的表定義和命令以使用樣本數(shù)據(jù)來填充它們，以及需要本文中顯示的其它語句可以在
TRADES 表包含 FpML 文檔和每個文檔的交易 ID 。每個交易文檔涉及兩個交易方使文檔中 用 PRTYID 元素的值。更多關(guān)于各個部分詳細信息都以 XML 格式存放在 PARTIES 表中。我們 可以從一個 TRADES 和 PARTIES 之間的 XML 到 XML 連接中找到相關(guān)交易的詳細資料，反之 亦然。很多 FpML 交易通過標記來引用具體貨幣。額外的貨幣信息在關(guān)系型中可以在 CURRENCIES 表中，如清單 2 所示。我們需要 XML 到關(guān)系型表的連接來把相關(guān)交易和貨幣信 息聯(lián)系起來。
清單 2. currency表中的內(nèi)容
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 |
我們的 PARTIES 表包含 3 行，每一行有一個 XML 文檔。他們描述了與金融衍生交易的例 子有關(guān)的各參與方。下表顯示 3 個締約方的 XML 文檔：
清單 3. Parties 表的內(nèi)容
<Party>
<PtyID>510026</PtyID>
<ShortName>MIB</ShortName>
<Name>MyGlobal International Bank</Name>
<Status>Active</Status>
<Address>
<Street>498 Wall Street</Street>
<City>New York</City>
<Country>USA</Country>
</Address>
<Rating>
<RatingDate>2006-05-16</RatingDate>
<RatingValue>Baa1</RatingValue>
</Rating>
</Party>
<Party>
<PtyID>67781</PtyID>
<ShortName>NVB</ShortName>
<Name>National Village Bank</Name>
<Status>Active</Status>
<Address>
<Street>1805 Back Street</Street>
<PostalCode>EC3M 4TD</PostalCode>
<City>London</City>
<Country>UK</Country>
</Address>
<Rating>
<RatingDate>2006-06-01</RatingDate>
<RatingValue>Aa</RatingValue>
</Rating>
</Party>
<Party>
<PtyID>99114</PtyID>
<ShortName>YWI</ShortName>
<Name>YourWorld Investments</Name>
<Status>Active</Status>
<Address>
<POBox>98765</POBox>
<PostalCode>100027</PostalCode>
<City>Beijing</City>
<Country>China</Country>
</Address>
<Rating>
<RatingDate>2007-01-15</RatingDate>
<RatingValue>Aaa</RatingValue>
</Rating>
<Rating>
<RatingDate>2005-04-21</RatingDate>
<RatingValue>Aa</RatingValue>
</Rating>
</Party>清單 4 顯示 FpML 文檔表現(xiàn)先前我們描述過的 YourWorld Investment 和 MyGlobal International Bank 之間的貨幣兌換交易。交易以 tradeHeader 元素開始，以“ party1 ”和“ party2 ”標記兩個交易方，并把他們和他們的交易 IDs 以及交易日期聯(lián)系起 來。在 FpML 文檔的最底部，“ party1 ”和“ party2 ”是映射到具體的標識符“ 510026 ”和“ 99114 ”他們引用 PARTIES 表中交易方信息。交易具體的主要部分在 fxSingleLeg 元素中。 FX 是聲明外匯交易，有兩個元素叫 exchangedCurrency1 和 exchangedCurrency1 。第一個表示 YourWorld 支付 CNY 71,900,000 給 MyGlobal，第二個顯示 MyGlobal 支付 10,000,000 給 YourWorld.
為了更清楚的表示，我們已經(jīng)從 FpML 樣本數(shù)據(jù)刪除了所有名稱空間。我們將在本文后面 部分重新訪問名稱空間。
清單 4. FpML格式中的一個利率衍生工具
<FpML>
<trade>
<tradeHeader>
<partyTradeIdentifier>
<partyReference href="party1"/>
<tradeId tradeIdScheme="http://www.MyGlobal.com/trade-id">MyGlobal941</tradeId>
</partyTradeIdentifier>
<partyTradeIdentifier>
<partyReference href="party2"/>
<tradeId tradeIdScheme="http://www.YourWorld.com/trade-id">YWI0089</tradeId>
</partyTradeIdentifier>
<tradeDate>2001-10-23Z</tradeDate>
</tradeHeader>
<fxSingleLeg>
<exchangedCurrency1>
<payerPartyReference href="party2"/>
<receiverPartyReference href="party1"/>
<paymentAmount>
<currency>CNY</currency>
<amount>71900000</amount>
</paymentAmount>
</exchangedCurrency1>
<exchangedCurrency2>
<payerPartyReference href="party1"/>
<receiverPartyReference href="party2"/>
<paymentAmount>
<currency>USD</currency>
<amount>10000000</amount>
</paymentAmount>
</exchangedCurrency2>
<valueDate>2001-10-25Z</valueDate>
<exchangeRate>
<quotedCurrencyPair>
<currency1>CNY</currency1>
<currency2>USD</currency2>
<quoteBasis>Currency2PerCurrency1</quoteBasis>
</quotedCurrencyPair>
<rate>7.91</rate>
</exchangeRate>
</fxSingleLeg>
</trade>
<party id="party1">
<partyId>510026</partyId>
</party>
<party id="party2">
<partyId>99114</partyId>
</party>
</FpML> |
清單 5 顯示一個 FpML 文檔的其它例子。這個文檔是一個 “隔夜拆借存款”。 National Village Bank 對來自于 YourWorld Investment 的 25,000,000 歐元存款支付 3% 固定貸款 利率。
清單 5. 在 FpML 中的一個“隔夜拆借存款”例子
<FpML>
<trade>
<tradeHeader>
<partyTradeIdentifier>
<partyReference href="party1"/>
<tradeId tradeIdScheme="http://www.YourWorld.com/trade-id">YWI7623</tradeId>
</partyTradeIdentifier>
<partyTradeIdentifier>
<partyReference href="party2"/>
<tradeId tradeIdScheme="http://www.NationalV.com/swaps/trade-id">69197</tradeId>
</partyTradeIdentifier>
<tradeDate>2002-02-14Z</tradeDate>
</tradeHeader>
<termDeposit>
<productType>Overnight Term Deposit</productType>
<initialPayerReference href="party1"/>
<initialReceiverReference href="party2"/>
<startDate>2002-03-15Z</startDate>
<maturityDate>2002-03-16Z</maturityDate>
<dayCountFraction>ACT/360</dayCountFraction>
<principal>
<currency>GBP</currency>
<amount>35000000.00</amount>
</principal>
<fixedRate>0.03</fixedRate>
</termDeposit>
</trade>
<party id="party1">
<partyId>99114</partyId>
</party>
<party id="party2">
<partyId>67781</partyId>
</party>
</FpML>
這兩個列子（清單 4 和清單 5）讓你對 FpML 衍生數(shù)據(jù)有了一個概念。 FpML 模式定義了 大約 1800 個不同的 XML 元素和超過 600 種類型。任何一個實例文檔都只包含了其中的一部 分。然而，一個關(guān)系型數(shù)據(jù)庫模式在沒有 XML 列的情況下需要至少 400 到 500 個表才能顯 示任意可能的 FpML 文檔。這是令人恐怖的復雜度，而且通常被認為不可管理。這是為什么 XML 是必須的。
OurTRADES 表包含了 5 個 FpML 文檔，包括上面的兩個。完整的數(shù)據(jù)樣例可以在一個 DB2 命令行（CLP）腳本中下載。
為 XML 存儲選擇正確的存儲選項
正確的配置存儲選項對于最大化 DB2 數(shù)據(jù)庫性能非常重要。在這個章節(jié)，我們討論數(shù)據(jù)庫 的表空間類型、XML 數(shù)據(jù)在數(shù)據(jù)庫中存儲的頁面大小、以及在數(shù)據(jù)庫中存儲 XML 數(shù)據(jù)的方法 。
提示：在 DB2 9.5 中 XML 在一個 DB2 表空間中消耗的存儲空間是原始 XML 數(shù)據(jù)以文本 格式在操作系統(tǒng)中占用空間的 0.7 到 1.5 倍。要得到更精確的評估，比如插入 1000 個有代 表性的文檔到一個空表中并抓取一個 DB2 表的快照來查看這個表已使用的頁數(shù)。
為 XML 數(shù)據(jù)選擇表空間類型和頁大小
數(shù)據(jù)庫管理表空間（DMS）提供了比系統(tǒng)管理 ( 操作系統(tǒng)管理 ) 表空間（SMS）更高的性 能。這對關(guān)系型數(shù)據(jù)尤其如此，對 XML 讀寫訪問上更是如此。最新創(chuàng)建的表空間默認是 DMS 。推薦使用 DMS 表空間與自動存儲，所以 DMS 容器根據(jù)需要增長而不需要人工干預。如果一 個 XML 文檔太大而不能放入這個表空間的單個頁面中，DB2 會把這個文檔分別存入多個域中 ，這樣就存入多個頁面中了。很顯然你的應(yīng)用程序可以讓 DB2 處理最大 2G 的 XML 文檔。
通常，一個文檔的域的數(shù)目越低性能越好，尤其對于插入和讀取整個文檔。如果文檔不能 放入一個頁面中，每個文檔拆分的數(shù)目取決于頁大小（4KB，8KB，16KB 或 32KB）。你的表空 間頁大小越大，每個文檔可能被拆分的數(shù)目就越小。例如，假設(shè)一個文檔跨了 40 個 4k 頁。 相同的文檔在 8KB 表空間中可能只需要 20 頁，或 10 個 16KB 頁，5 個 32KB 頁，因為多 個小的文檔可以存儲在一個頁面中所以不會有空間浪費。
提示：大多數(shù) XML 應(yīng)用程序最好在 16KB 和 32KB 頁面上運行。如果大多數(shù)文檔非常小（ 比如小于 4KB）16KB 頁面可以提供良好的性能，因此在一個頁面中存放多個文檔。更大的文 檔最好使用 32KB 頁面保存。對于我們的 FpML 場景，需要 16KB 頁面。如果你對關(guān)系型數(shù)據(jù) 和 XML 數(shù)據(jù)使用同樣的頁面，或者數(shù)據(jù)和索引也存放在相同頁面，16KB 頁面同樣可以做很好 的折衷，而且你會發(fā)現(xiàn) 32KB 頁面對關(guān)系數(shù)據(jù)和索引有的訪問有負面影響。這這種情況下，你 可以考慮使用其它的頁面大小。
XML 和關(guān)系數(shù)據(jù)使用不同的表空間和頁大小
在清單 1 中的 CREATE TABLE 語句把表中的 XML 數(shù)據(jù)和關(guān)系型數(shù)據(jù)都存在了相同表空間 里。這意味著它們使用相同的頁面大小和緩沖池。在表空間中，關(guān)系數(shù)據(jù)是存儲在基本數(shù)據(jù)頁 面上，同時 XML 數(shù)據(jù)是存在另外的 XML 數(shù)據(jù)域（XDA）里的頁面中。這是因為就像大對象 （LOBs），XML 文檔可能很大，不能放在表的一個數(shù)據(jù)頁中的一行里。這種默認的規(guī)劃對于大 多數(shù)應(yīng)用場景提供了很好的性能。這個選項，叫做“基礎(chǔ)內(nèi)嵌表”，將在下面章節(jié)中進行介紹 ，你應(yīng)該對在同時存儲 XML 文檔和關(guān)系型數(shù)據(jù)的數(shù)據(jù)頁面上選擇這個選項。然而，默認情況 下關(guān)系型數(shù)據(jù)和 XML 數(shù)據(jù)是分開存儲的。
提示：如果你已經(jīng)完成了性能分析并發(fā)現(xiàn)你需要對 XML 數(shù)據(jù)使用一個大頁面，而關(guān)系型數(shù) 據(jù)和索引需要小頁面，你可以使用不同的表空間來滿足它們。在你定義一個表的時候，你可以 指定“長型”數(shù)據(jù)到一個有不同頁面大小的單獨的表空間。長型數(shù)據(jù)包括 LOB 和 XML 數(shù)據(jù)。
下面的例子定義了兩個緩沖池和兩個表空間，緩沖池和表空間都分別有 4KB 頁和 32KB 頁 。注意，一個表空間總是需要一個匹配頁大小的緩沖池。我們的 3 個表所在的 relData 表空 間是 4KB 頁面。所有的列都存在這個表空間中，除了 XML 列。它們被存儲在 xmlData 表空 間的 32KB 頁面中。
清單 6. XML 和關(guān)系型數(shù)據(jù)存放在不同頁大小的表空間中的例子
create bufferpool bp4k pagesize 4k;
create bufferpool bp32k pagesize 32k;
create tablespace relData
pagesize 4K bufferpool bp4k;
create tablespace xmlData
pagesize 32K bufferpool bp32k;
create table trades (tradeId integer, tradedoc XML)
in relData
long in xmlData;
create table parties(partyInfo XML) in relData long in xmlData;
create table currencies(symbol char(4), name varchar(30), USDvalue double,
lastUpdated timestamp) in relData; |
除非明確指定，新表空間都是創(chuàng)建為有大行 IDs 的 DMS 表空間。這意味著一個 4KB 頁大 小的表空間可以存儲多達 2TB 的數(shù)據(jù)并支持在 32KB 大小的頁面存放 2335 行記錄。
內(nèi)置并壓縮 XML 數(shù) 據(jù)
DB2 VERSION 9.5 也允許你“內(nèi)置”存儲 XML 數(shù)據(jù)并壓縮。
提示：如果某些或你的所有 XML 文檔都足夠小，就可以在基礎(chǔ)表頁面里把它們放進相應(yīng)的 行對象中，就可以把 XML 數(shù)據(jù)內(nèi)置到關(guān)系行中。這樣做也提供了對 XML 數(shù)據(jù)的更直接訪問并 避免了重定向到 XDA 對象中。如果在 XML 列中的一些文檔仍然太大而不能內(nèi)置，它們通常被 存儲在“外部” XDA 對象中。內(nèi)置可以顯著的減少域索引，因為嵌入文檔不需要任何域索引 輸入。它們總是組成一個單獨的內(nèi)置域。嵌入文檔也可以使用普通的 DB2 深度行壓縮來壓縮 ，如圖 7 所示：
清單 7. 嵌入及壓縮 XML 存儲的定義
create table trades (tradeId integer, tradedoc XML in line length 16000)
in relData compress yes; |
在這個例子中，XML 列使用 INLINE LENGTH 16000 定義 . 這意味著任何等于或小于 16000 字節(jié)的文檔都將以嵌入方式存儲。這里指定的大小是參照 XML 在 DB2 中解析后的大小 ，不是 XML 文本文檔在你文件系統(tǒng)中的大小。嵌入長度必須小于頁面大小減去本頁中其它列 之后的大小。
提示：通常你應(yīng)該尋求嵌入最多或全部文檔。如果你在表中只有一個 XML 字段，達到這個 目的的最簡單的方法是設(shè)置內(nèi)置長度為這一行中的最大可能值。 DB2 不會允許你定義一個太 長的嵌入長度。選擇一個較大的嵌入長度將不會浪費任何空間，因為只有存儲文檔真正需要的 空間才會被使用。然而，指定一個較大的內(nèi)置長度可以阻止你在以后添加新列到這個表中。
嵌入 XML 數(shù)據(jù)總是以這個表的關(guān)系型列存放在相同表空間中，并且不能存在一個有不同頁 面大小的其它表空間中。
因為我們的樣本表示定義時指定了 COMPRESS YES，關(guān)系數(shù)據(jù)和內(nèi)置 XML 文檔會被壓縮。 以 60%-70% 的比例壓縮內(nèi)置 XML 數(shù)據(jù)并不罕見。下面的語句可以用來檢查 PRODUCT 表的壓 縮比率：
清單 8. 用來檢查數(shù)據(jù)壓縮率的管理函數(shù)
select
tabname,pages_saved_percent,bytes_saved_percent
from table(sysproc.admin_get_tab_compress_info('MYSCHEMA','TRADES','ESTIMATE'))
as t |
提示：
如果你的系統(tǒng)是 I/O 限制而非 CPU 限制，壓縮 XML 數(shù)據(jù)可以提供極大的性能提升。然而 ，要注意內(nèi)置文檔會顯著的增加在你頁面中的行的大小。這反過來減少了每一頁中的行數(shù)。只 訪問表中關(guān)系列的查詢現(xiàn)在需要讀取比沒有嵌入文檔要多很多的頁面。這會造成比沒有使用 XML 嵌入文檔情況下更多的 I/O 以及更低的查詢性能。如果你的查詢通常總是查詢 XML 列， 那么對你沒有影響，然而，如果你有很多不涉及 XML 列的查詢，你應(yīng)或許不應(yīng)該選擇“內(nèi)置 ”存儲。
【編輯推薦】
