|
XML標準和文檔的出現爲關係數據庫出了一道難題，以訪問二維表數據爲主的SQL和XML的結合就成了一條中和之路。於是乎，漫長的SQL/XML結合之旅開始了。
隨着新XML文檔規範的問世，廠商正在加大在RDBMS(關係型數據庫管理系統)中對XML支持的力度。
當XML五年前推出時，它所具有的改寫數據管理規則的前景引起了關係型數據庫廠商的注意，不過他們並沒有恐慌。十年前就經歷過這一幕，當時對象數據庫被人們賦予了範例改變者的作用。這種新軟件規範的確出現了，並普及了持久性概念：即無需費勁地轉換關係表格就能保存和檢索編程語言對象的能力。但結果是，RDBMS學會了新“把戲”，那就是找到了如何利用SQL:1999對象模型保存複雜的數據類型的辦法。現在已經有了用於關係型數據庫和對象數據庫的JDO(Java 數據對象)應用。微軟表示，即將推出的Yukon版SQL Server將能夠保持.Net對象。
吸收了對象後，RDBMS廠商現在正爲吸收XML文檔而努力工作。不過，不要指望歷史能夠簡單重演。我們都知道運營企業的大部分信息存儲在我們創建和交換的文檔中，這些文檔很少被保存在企業數據庫中。既然XML既可以代表我們看到和接觸到的文檔(如採購訂單)，又可以代表在Web服務網絡上交換這些文檔的信息，因此我們的數據庫能否保存和管理XML文檔比以往更加至關重要。一枚真正的重磅炸彈正在製造中,沒人準確知道它將生產什麼影響，但是目前可以分析它，做出一些有根據的猜測。
SQL/XML結合之旅第一步
漫長的SQL/XML結合之旅第一步,是將關係型數據作爲XML格式發佈。XML發佈是合乎邏輯的起點，因爲它可以容易地在XML中代表SQL結果集合，因爲那麼多的動態網頁都是由SQL查詢來提供的。傳統的方法要求用程序訪問結果集合和用程序構建網頁。新方法以完全公佈的方式製作動態網頁，利用SQL-to-XML查詢生成數據的XML表示,並利用XSLT(可擴展樣式表語言轉換)將XML溶入到HTML中。
最初這些虛擬文檔是利用專有的SQL擴展來創建的。現在有了一種叫做SQL/XML的新ISO/ANSI標準，這項標準定義了一種通用的方法。目前，SQL/XML得到了Oracle和DB2的支持。它定義了用於這些產品中的本機XML數據類型的面向XML的操作符。SQL Server現在還不支持XML數據類型或SQL/XML擴展，微軟定於2004年推出的Yukon將支持它們。
存儲文檔的方式
企業中的大多數信息保存在存儲文檔中，而不是關係型數據庫中。將這些文檔輸入到數據庫中的理由始終存在，那就是集中式管理和全文本搜索，但是在缺少一種將文檔中的數據與數據庫中的數據建立關係方法的情況下，這些理由不具有說服力。而XML則爲人們提供了論據。
當企業文檔從已有格式映射到XML時(這是一條纔剛剛開始的漫長路程)，將兩種風格的數據建立關係成爲了可能。比如說，有一種在關係型表格中保存索賠數據和以XML格式保存索賠文檔的保險應用。混合型SQL/XML數據庫使這個應用可以從文檔子集中提取XML段落。這個子集可以通過將文檔中的XML元素與關係型表格中的列值結合在一起來創建。
利用一些不同類型的存儲和查詢戰略，目前取得了巨大的進展。在存儲方面，存在兩種通用的方法。一種是可以將整個文檔輸入到數據庫的列中，或者可以將文檔“撕碎”後放到多個關係型表格中。後一種方法充分利用了數據庫的查詢引擎和強大的更新功能，但是從不規則XML數據到SQL的映射比從SQL到XML的映射要困難得多。如果你的XML文檔由XML模式描述控制的話，將對映射有所幫助。XML模式描述爲XML-to-SQL映射器提供了線索，並且用戶可以向這類描述添加註釋來更準確地控制映射。如果數據庫支持可以接收形狀不規則的XML數據對象的話，也將對映射有所幫助。Oracle公司擴展了關係型數據庫技術，使它包括了作爲SQL：1999一部分的對象。在其8i和9i上已經成熟到了這種程度，那就是可以在對象/關係類型中表示XML 模式的類型系統。
查詢戰略
XPath是所有面向XML查詢戰略的基礎，這是一種用於向下生成樹型結構和刪除樹枝的語法。當一張XSLT樣式錶轉換XML文檔時，它使用XPath來隔離文檔的分段。支持XML查詢的關係型數據庫(包括老牌產品Oracle、DB2和SQL Server以及像OpenLink Software的Virtuoso這樣的新軍，但還不包括MySQL)以同樣的方式使用XPath。起初，這種對XPath的支持是以專有擴展的形式提供的。最近，SQL/XML標準定義了具有XPath意識的SQL擴展的通用集合。XPath還在W3C即將發佈的XQuery標準中得到了應用。XQuery標準致力於使SQL數據連接功能適應半結構化XML數據世界。IBM公司表示，其正在努力開發XQuery，以使SQL開發人員可以他們熟悉的方式處理XML內容。
儘管廠商急不可待地等待XQuery 1.0的最終完成，但是它們的XQuery應用在某些方面將不如目前的SQL/XML應用強大。最明顯的是，XQuery 沒有定義用於更新XML文檔中的元素的語法。雖然SQL/XML的更新機制還沒有得到批准，但它已經被定義了，已被應用在Oracle和DB2中。
SQL/XML搶走了XQuery的風頭嗎？從短期看，XQuery看起來只是一種完成可能用SQL和XPath同樣可以完成工作的替代方法。但是，從長期看，開發人員可能希望在他們的所有數據源上保持XML抽象。在這種情況下，作爲一種爲處理複雜的數據而開發的豐富而全面的編程語言，XQuery可能將成爲一種重要的範例。
文檔的未來
讓我們假設2005年的某個時刻，有一張正在流經業務過程的採購訂單。這是一個利用像InfoPath這樣的工具創建的XML文檔，它上面混合記錄着核心數據和上下文元數據。包括商品號和部門代碼的核心數據將輸入到一張關係型表格的列中。可能包含由請求人、審查人和批准人蔘加的包括討論的上下文元數據將仍以文檔形式保存。目前，這種上下文內容從來沒有被保存在RDBMS中。重要的是瞭解數據怎樣到達那裏以及它的含意。
一旦填寫後，這張採購訂單就被輸入到在Web服務網絡上流動的工作流中。安全服務可以通過更新SOAP頭來執行授權政策，編排服務可以搜索具有同樣相關ID的SOAP頭的文檔集合。這些活動的中間階段將需要某種數據庫技術來管理透明地出現在查詢中的XML，不過這可能不是Oracle或DB2的任務。這時，一個專門的XML數據庫，如Software AG的Tamino 或Sleepycat Software的Berkeley DB XML，可能更適於完成這項任務。它們的速度很快，可以很好地用於動態XML文檔，甚至在這些文檔缺少RDBMS SQL/XML映射器所依賴的模式時。
在工作流過程以及在完成後，文檔將通過某個URL可以供有關各方訪問。這個URL可以決定文檔的映射，從混合的SQL/XML RDBMS到一臺Intranet Web服務器或WebDAV存儲庫；或者可以決定本機保存在RDBMS中的文檔基礎實例。不管是哪一種情況，業務過程的狀態(核心數據和上下文元數據)將在任何時候都可以爲對它感興趣並獲得授權的人員所訪問。此外，文檔中保存的兩種類型的數據將可以跨越企業查詢，從而將SQL和XML數據源整合在一起，創建融合的視圖。
企業數據管理風格正在發生重大改變，有許多重要的架構問題還沒有得到解決。毫不奇怪，Oracle希望將各種東西都保存在集中式混合DBMS中。而IBM則表示寧願讓你能夠跨多種來源將數據結合在一起。每一種戰略都有自己的長處，而大多數企業最終將由於不同的原因以不同的方式購買這兩種技術。儘管存在這些不同，我們正在見證一次神聖的結合。SQL和XML結爲夫妻，蜜月開始了。
|
