XML和資料庫之間的關係

 1.0 簡介
    本論文簡要的探討了XML和資料庫之間的關係，同時列出一些可以使用資料庫處理XML文檔的軟體。 雖然這裡不打算詳盡地介紹這些軟體，但是筆者希望它能夠描述使用資料庫處理XML文檔中的主要部分。這裡有點偏向與關聯式資料庫，因為我的經驗如此。
     2.0 XML是資料庫嗎?
     在開始討論XML和資料庫之前，我們需要回答一個縈繞在很多心頭的問題: "XML是資料庫嗎?"在嚴格意義上將，如果"XML"是指XML文檔時，答案是"否"。儘管XML文檔包含了資料，但是如果沒有其他的軟體來處理這些資料，它對於資料庫的意義和其他文字檔沒有什麼區別。
     如果在更為寬泛一些的意義上將，當"XML是指XML文檔以及所有相關的XML的工具和技術時，答案則是"是"。 之所以肯定是由於XML提供了許多資料庫中所需要的部分:儲存(XML文檔),結構(DTD,XML schema語言),查詢語言(XQL, XML-QL, QUILT等), 編程介面(SAX, DOM),等等。不過...XML還缺少很多在真實的資料庫中所必備的內容: 有效儲存、索引、安全、交易、資料完備性、多使用者訪問、觸發、多文檔查詢等。
因此如果在資料量一般、使用者較少、效能要求不高的環境下可以把XML當作資料庫來使用；而在大多產品的環境中，要求有許多的使用者使用、需要嚴格的資料完整性並且對效能有很高的要求，XML就不能勝任了。而且，考慮到象dBase和Access等資料庫既便宜又十分易用，因此甚至在第一種情況下XML都很少有理由充當資料庫的角色。
     3.0 為什麼使用資料庫?
當在考慮使用XML和資料庫時，第一個要問自己的問題應該是：為什麼我需要使用資料庫？你需要將原有的資料匯出？你需要儲存你的Web首頁？你是要在一個電子商務應用中使用資料庫，而且其中XML當做傳輸的資料格式？這些問題的答案都將直接影響到你對資料庫和中介軟體(如果有的話)的選擇。
    例如，假設你在電子商務應用程式中使用XML來進行資料轉送。這是很好的方案，因為你的資料具有高度規範的結構，而XML中的那些實體和編碼對你而言並不重要了。畢竟樣你關心的僅僅是資料而不在於這些資料如何在文檔中進行物理的儲存。如果你的應用程式相對比較簡單的話，關聯式資料庫和資料轉送中介軟體將可以滿足你的需求；如果應用程式龐大而且複雜，那麼你就需要一個完全支援XML的開發環境了。
    從另一方面來說，假設你有一個從零散的XML檔案建立的網站。你不僅需要管理這個網站，你還要提供方法讓使用者可以查詢其中的內容。這時你的檔案將非常的不規範，而實體的使用對你來說將變得很重要，因為這些檔案的結構是網站的根本。在這個例子中，你就需要某類"原生XML"資料庫可以執行版本化、跟蹤實體的使用並且支援如XQL這樣的查詢語言。
     4.0 資料和文檔的對比
     筆者認為，在選擇資料庫時，最重要的判斷因素可能是你是利用資料庫來儲存資料還是儲存文檔。如果你想儲存資料，你需要的資料庫主要是面向資料存放區(例如關係型資料庫或者物件導向型資料庫)以及在資料庫和XML文檔之間相互轉換。從另一個角度來將，如果你想儲存文檔，你需要一個專門設計用來隱藏檔的內容管理系統。
     雖然你可以自己把檔案儲存在關聯式資料庫或物件導向資料庫中，可是你常會發現你的工作是在重複內容管理系統的功能。類似的，雖然一個內容管理系統通常是建立在物件導向資料庫或關聯式資料庫之上，但要是把一個內容管理系統當做資料庫來使用就可能非常的令人困繞。
     你需要儲存資料還是文檔，答案常常取決於你的XML文檔。原因是XML檔案分為兩大類：以資料為中心和以文檔為中心。.
     4.1 以資料為中心的檔案
     以資料為中心的檔案的特點是結構相當規範、資料顆粒度好(也就是說，資料中最小的獨立單元是PCDATA元素或者是屬性)、很少或者沒有混合內容。其中同層次元素和PCDATA的出現順序並不重要。典型的例子是，XML文檔包含了銷售定單、飛行安排、餐館菜單等等。資料為中心的文檔常被用於機器的使用，這時XML可能是多餘的---它僅僅是資料轉送的手段而已。
     例如，下面的銷售定單的文檔就是以資料為中心的：
     ABC Industries
     123 Main St.
     Chicago
     IL
     60609  
     981215
     Turkey wrench:
     Stainless steel, one-piece construction,
     lifetime guarantee.     
     9.95
     
     10
     Stuffing separator:
     Aluminum, one-year guarantee.     
     13.27  
     5
     在XML的世界中，許多內容豐富的文檔實際上都是資料為中心的。我們以顯示圖書資訊的Amazon.com網站為例。雖然這個頁面是相當巨大的文本，但是這個文本的結構是高度規範的，其中許多的部分對任何的書本描述頁面都是相同的，並且特點頁面中的各部分的大小都是有限的。也就是說，該頁面可以通過一個簡單的、資料為中心的XML文檔來建立，其中包含了從資料庫中檢索得到的文本資訊以及一個XSL樣式表。通常，目前任何通過在模板中填充資料庫資料而動態構造HTML頁面的網站都可以被上面介紹的用以資料為中心的XML文檔和一個或者多個的XSL樣式表方式替代。
     ABC Industries agrees to lease the property at
     123 Main St., Chicago, IL from XYZ
     Properties for a term of not less than TimeUnit="Months">18 at a cost of Currency="USD" TimeUnit="Months">1000   
     可以從下面的XML文檔和簡單的樣式表得到:
     ABC Industries
     123 Main St., Chicago, IL
     XYZ Properties
     18
     1000
     4.2 以以文件為主的檔案
     以以文件為主的文檔的特點是:結構不規範、資料顆粒度更大(即，最小的獨立資料單元是包含有混合內容的元素或者就是整個XML文檔)以及含有大量的混合內容。其中相同層次的元素和PCDATA出現順序是非常重要的。典型的例子是書、電子郵件、廣告以及大多數XHTML文檔。以以文件為主的文檔是用於人的使用。
     例如，下面的產品描述文檔就是以文檔為中心： 
     Turkey Wrench
     
     Full Fabrication Labs, Inc.
     
     Like a monkey wrench, but not as big.

     The turkey wrench, which comes in both right- and
     left-handed versions (skyhook optional), is made of the finest
     stainless steel. The Readi-grip rubberized handle quickly adapts
     to your hands, even in the greasiest situations. Adjustment is
     possible through a variety of custom dials.
     
     You can:
     
     
     Order your own turkey wrench
     Read more about wrenches
     Download the catalog
     
     
     The turkey wrench costs just $19.99 and, if you
     order now, comes with a hand-crafted shrimp hammer as a
     bonus gift.
     4.3 資料、文檔和資料庫
     在現實情況中，以資料為中心的檔案和以文件為主的檔案之間的區別並不是很嚴格。例如，一個以資料為中心的檔案(如一張發票)，也有可能包含粗顆粒度、不規則的資料(如發票的描述部分)。而一個以文檔為中心檔案(如使用者手冊)也可能包含有良好顆粒度、規則的結構化資料(通常是中繼資料),例如作者和修訂日期。除此之外，讓你的文檔具有以資料為中心或者以以文件為主的特點有助於你判斷是關心資料還是文檔，這也將決定你需要採用什麼樣的系統。
     要儲存或檢索資料，你可以使用一個資料庫(通常是關係型、物件導向型或者是層次型)和中介軟體(字帶或者是採用第三方)，你也可以使用XML伺服器(即建立分布式應用的平台，例如利用XML進行資料轉送的電子商務應用)。要儲存文檔，你將需要一個內容管理系統或者是一致性的DOM實現系統。有關各類系統的探討在5.0 
     "儲存和檢索資料" 小節和6.0 "
     
     href="#storingretrievingdocs">儲存和檢索文檔 " 小節。你也能夠在 
     
     href="http://www.rpbourret.com/xml/XMLDatabaseProds.htm"> 
     
     XML資料庫產品 中瞭解詳細的相關產品列表。

     5.0 儲存和檢索資料 
     在以資料為中心的文檔中的資料內容可能來自資料庫(此時你想把資料匯出為XML格式)，也可能是XML文檔(此時你想把資料存放區在資料庫中)。前者的例子是在關係型資料庫中儲存的大量現有資料(或稱遺產資料);後者的例子是將資料作為XML發布在Web中，而且你想要在你的資料庫中進行儲存以進行更多的處理。如此，根據你的需求，你可能需要將XML文檔轉移到資料庫的軟體，也可能需要從資料庫轉移到XML文檔的軟體，或者兩者都支援。
     5.1 轉移資料
     將資料存放區在資料庫中時，經常需要丟棄大量與文檔有關的資訊，例如文檔名稱和DTD，同時還有其物理結構，例如實體的定義和使用、屬性值和同層元素的順序、位元據的儲存方式(是Base64編碼、是未析實體或他方式)、字元資料段和其他的編碼資訊。類似的，當從資料庫中檢索資料時，產生的XML文檔結果除了非預定義實體lt(<"),gt(">"), amp("&"), apos("’"), quot(""")不包含任何CDATA或實體引用。而同層元素和屬性的出現順序也常常就是從資料庫中返回的資料的次序。    
     儘管一開始有些讓你吃驚，但是這常常是合理的。例如，假設你需要用XML作為資料格式把一張銷售從一個資料庫中轉移到另一個資料庫中。在這種情況下，在XML文檔中並不關心銷售單的編號是儲存在銷售單的日期的前面還是後面，也不用關心是否將顧客的名稱儲存在字元資料(CDATA)段還是作為一個外部實體，或者直接當成一個PCDATA。最重要的在於相關的資料是從第一個資料庫轉移到第二個資料庫中。這樣，這個資料轉送軟體就需要考慮資料的階層(該結構將銷售單的有關進行進行了分組)，而其他則不必過多考慮。 
     忽略文檔資訊以及其物理結構的後果之一是文檔的"逆反迴歸"的不一致效應，即將一個文檔的資料存放區在資料庫中，然後根據這些資料重新組織成新的文檔。而即便是根據標準格式處理，得到的也常常是和前面不同的文檔。這是否可以接受要取決於你的需求，而且也將影響到你對資料庫和資料轉送中介軟體的選擇。
     5.2 
     
     從文檔結構到資料庫結構的映射
     為了在XML和資料庫之間傳輸資料，需要在文檔結構和資料庫結構之間進行相互的映射。這樣的映射通常分為兩大類: 模板驅動和模式驅動。
     5.2.1 模板驅動的映射
     在以模板驅動的映射中,沒有預先定義文檔結構和資料庫結構之間的映射關係 
     
     ，而是使用將命令語句內嵌入模板的方法，讓資料轉送中介軟體來處理該模板。例如，考慮下面的模板(注意該模板並不適用任何實際的產品)，在<SelectStmt>元素中內嵌了SELECT語句：
     
     <?xml version="1.0"?>
     <FlightInfo>
     <Intro>The following flights have available seats:</Intro>
     <SelectStmt>SELECT Airline, FltNumber, Depart, Arrive FROM Flights</SelectStmt>
     <Conclude>We hope one of these meets your needs</Conclude>
     </FlightInfo>
     當資料轉送中介軟體處理到該文檔時,每個SELECT語句都將被各自的執行結果所替換，得到下面的XML格式:
     
     <?xml version="1.0"?>
     <FlightInfo>
     <Intro>The following flights have available seats:</Intro>
     <Flights>
     <Row>
     <Airline>ACME</Airline>
     <FltNumber>123</FltNumber>
     <Depart>Dec 12, 1998 13:43</Depart>
     <Arrive>Dec 13, 1998 01:21</Arrive>
     </Row>
     ...
     </Flights>
     <Conclude>We hope one of these meets your needs</Conclude>
     </FlightInfo>
     
     這種以模板驅動的映射可以相當的靈活。例如,有些產品可以允許你在任何結果集合中替換你想要的內容(包括在SELECT中使用參數),而不是象上面的例子中簡單地格式化結果。另外它還支援使用編程來進行構造，例如迴圈和條件判斷結構。還有一些還支援SELECT語句的參數化，例如通過HTTP來傳遞參數。 
     目前，以模板驅動的映射只支援從一個關係型資料庫轉換成XML文檔的情況。
     5.2.2 模型驅動的映射
     在以模型驅動的映射中,利用XML文檔結構對應的資料模型顯式或隱式地將映射成資料庫的結構，而且反之亦然。它的缺點是靈活性不夠，但是卻簡單易用，這是因為它是基於具體的資料模型來進行映射的，通常能夠為使用者實現很多地轉換工作。由於將資料從資料庫轉換成XML的結果依照了單個模型, 
     
     因此通常在這種方式下通常結合XSL來提供模板驅動的系統中所具有的靈活性。
     在XML文檔中的資料檢視通常有兩種模型:表格模型和特定資料物件模型。有時候也可能會出現其他的模型。例如，通過採用ID和IDREF屬性，一個XML文檔可以用來一個指定的圖形。不過，很多現有的中介軟體並不支援這些模型。
     5.2.2.1 表格模型
     許多中介軟體軟體包都採用表格模型在XML和關係型資料庫之間進行轉換。它把XML的模型看成是一個單獨的表格或者是一系列的表格。也就是說，XML的文檔的結構和下面的例子相類似，其中在單個表格的情況下，<database>並不出現:

     <database>
     <table>
     <row>
     <column1>...</column1>
     <column2>...</column2>
     ...
     </row>
     ...
     </table>
     ...
     </database>

     其中的術語"table"可理解為單個的結果集(當從資料庫向XML中轉換資料時)，或者是一個單獨的表格或可更新的視圖(當從XML向資料庫轉換資料時)。如果資料需要來自多個結果集(當資料來自資料庫中時)或者與僅僅表達成一系列表格的集合(當轉換資料到資料庫時)相比，XML的文檔包含有更深層次的嵌套元素，那麼類似的轉換幾乎是不可能的。

     5.2.2.2 特定資料物件模型

     XML文檔中第二種普遍的資料模型是特定資料對象的樹型結構。在該模型中,元素類型通常對應對象，而XML中的內容模型、屬性和PCDATA則對應對象的屬性。這種模型直接映射成物件導向的資料庫和層次型資料庫，當然藉助於傳統的對象-關係映射技術和SQL 
     
     3物件檢視也可以映射成關聯式資料庫。要注意的是，這種模型並不是文件物件模型(DOM)。DOM是對文檔本身進行建模，而不是對文檔中的資料。如
     
     href="#writeyourown">6.1.2小節所述,DOM用來在關係型資料庫的基礎上建立內容管理系統。
     例如，上面的銷售定單文檔就可以看作是由五個類所組成的樹型結構。如下面的視圖所示，包括Orders, SalesOrder, Customer, 
     
     Line和Part類:
     
     Orders
     |
     SalesOrder
     / | Customer Line Line
     | |
     Part Part
     當把一個XML文檔建模為一棵特定資料對象樹時，就沒有必要要求元素一定要對應於對象。例如，如果一個元素只包含PCDATA，如銷售定單文檔中的CustName元素，它可以當作一個屬性進行處理，因此屬性只包含單一的、標量型數值。類似的，有時將混合元素或元素內容模型化成屬性也是非常有用的。一個現成的例子就是在銷售定單文檔中對Description元素的處理：儘管它在XHTML的格式中有混合內容，但是將Description元素看作單個的屬性會更有用些，因為它的組成部分本身並沒有什麼意義。

     5.3 資料類型、空值、字元集合和其它
     本節將探討一些有關來自資料庫的XML文檔的儲存問題。通常，你決定不了你選擇的中介軟體是如何解決這些問題的，但是你最好應該意識到這些問題的存在，因為這有助於你正確選擇你的中介軟體。
     5.3.1 資料類型
     XML不支援任何有實際意義的資料類型。除了未析實體，所有XML文檔中的資料都被當成文本來對待，即便它能夠用其他的資料類型(如日期或者整數)來表示。通常，資料轉換中介軟體將把XML文檔中的文本轉換成其它資料庫中的資料類型，反之亦然。然而，特定的資料類型所識別的文字格式設定是有限制的，例如受到提供的JDBC 
     
     Driver所支援的資料類型的限制。在這些眾多的資料類型中，日期類型通常會導致麻煩。不同國際地區的數字格式的差異也可能產生問題。
     5.3.2 位元據
     通常有兩種方法將位元據儲存到XML文檔中的：未析實體和Base64編碼處理(一種MIME編碼方法，可以將位元據映射成US-ASCII的子集)。 
     
     對於關係型資料庫，這兩種方法都可能存在問題，因為從資料庫中儲存和檢索位元據的規則非常的嚴格，這樣對會導致中介軟體出現問題。
     另外，並沒有一種標準的符號用來說明一個XML文檔中的元素包含有Base64編碼資料，從而使得中介軟體可能根本就不能夠識別這種編碼。最後，在儲存資料到資料庫時，可能會忽略與未析實體或Base64編碼元素相關的符號。所以，如果對你而言位元據非常重要的話，請務必要確認你的中介軟體是否支援位元據。
     5.3.3 空值
     在資料庫世界中，空值(null)資料意味著資料不存在值。但是這與一個值為0的數字或長度為0的字串有很大的區別。例如，假設你的資料來自一個氣象站， 
     
     如果氣象站的溫度計出了毛病讀不出溫度值，那麼你的資料庫中將儲存一個null值而不是一個0。顯然，值為0完全是另外一回事了 
     XML中空值概念的支援可以通過設定可選的元素類型或屬性來實現。如果元素類型或屬性值為null，XML只要在文檔不包含該元素或者屬性就可以了。但是對資料庫而言，空的元素或包含0長度字串的屬性並不是空值null：它們的值為長度為0的字串。
     當在XML文檔和資料庫結構之間相互映射過程中，你必須特別注意那些可選的元素類型或屬性是否對應於資料庫中的空值項。如果不這麼做的話，很可能出現插入錯誤(當將資料轉換到資料庫中時)或者無效文檔錯誤(當將資料從資料庫讀出時)。
     
     因為同樣要用符號空值，XML中相對與資料庫而言更為靈活。具體來講，許多XML使用者很可能包含Null 字元串的空元素或屬性是空值。這個時候你必須考慮如何選擇合適的中介軟體來解決這個問題。一些中介軟體可以讓使用者選擇在XML文檔中定義用什麼來組成空值。
     5.3.4 字元集

     根據定義，除了一些控制字元，XML文檔能夠包含任何的Unicode字元。但是不幸的是，許多資料庫都限制或則不支援Unicode，而且需要一些特殊的配置才能夠處理非ASCII編碼的字元資料。如果你的資料包含了非ASCII字元，那麼務必要核實你的資料庫和中介軟體是否能夠處理這些字元。
     5.3.5 處理指示

     處理指示並不屬於XML文檔中的“資料”部分，因此目前許多中介軟體可能不能正常的處理。問題是，尤其是在將XML文檔結構嚴格映射成資料庫結構時，處理指示通常是很難處理的，因為它們可以虛擬地出現在文檔的任何位置。因此，中介軟體就很難判斷將它們儲存到什麼位置以及在什麼時候檢索讀取出來。如果處理指示和文檔的迴圈回複("round-tripping")對你而言是非常重要的話，就務必檢查你的中介軟體是如解決這個問題的。

     5.3.6 儲存標記

     在
     
     href="#markup">4
     
     href="#markup">.2.2 
     
     小節中提到，有時候將包含元素或者混合內容的元素不作進一步的解析而直接儲存到資料庫中是非常有用的。最常見的方法是簡單的把這個標記本身直接儲存到資料庫中。不幸的是，當從資料庫中檢索資料時將產生問題：不可能判斷資料庫中的標記到底是真的標記還是代表了標記字元的實體，如由lt和gt轉義的字元。
     
     例如，下面的description元素:
 
     <description>
     <b>Confusing example:</b> <foo/>
     </description>

     在資料庫中儲存為:
     
     <b>Confusing example:</b> <foo/>

     這時資料庫就不能判斷<b>和<foo>是標記還是文本。有幾種可能的解決方案，如以一定的方式來標誌標記或者對非標記的標記字元使用實體。但是這時你要格外注意這樣的方式是否和使用這些的資料的其它應用相容。例如，如果你想查詢資料庫中的小於符號("<")和 
     
     lt實體("<")時就要特別留心。

     5.4 從資料庫的結構產生DTD及其互逆過程

     在XML文檔和資料庫之間轉換資料時，一個普遍問題是：如何從資料庫的結構(Schema)產生XML的DTD,如果從XML的DTD產生資料庫的結構。簡而言之，這是非常直接的操作，但是產生的結果通常離許多使用者的期望值還有一些距離。

     (還要注意這通常是一次性操作，而大多數應用，尤其是所有的垂直性應用都結合了已知的DTD和關係型Schema的集合。顯而易見的特例是在關聯式資料庫中儲存隨機XML文檔或者將關係型資料發布為XML文檔的工具;而在後面的情況中，DTD的作用並不明顯。)

     對於元素類型中每個有單一數值的屬性和只包含有PCDATA內容的子項目類型在該ta 
     
     ble中建立立一列（欄位）。如果子項目類型或則屬性是可選的，讓該欄位允許為空白。 
     
     對於每個有多值的屬性或則多僅含有PCDATA內容的子項目類型，再建立一個分開的 
     
     table來儲存他們的值，通過它們的父表的主關鍵字串連到父表。 
     
     對於每個子項目，這些子項目本身還有元素或則混合內容，使用父表中的關鍵字將 
     
     父元素表串連到子項目表中。 
     
     而下面則是一個從關聯式資料庫的結構產生XML文檔的過程（簡化過的）： 
     
     對每個table，建立一個元素。 
     
     對錶中的每列，建立一個屬性或則只含PCDATA的子項目 
     
     對每個包含有在主鍵/外鍵關鍵字關係中主索引值的列，建立一個子項目。
     例如，下面的過程(經簡化）說明了如何從一個DTD產生一個關係型結構:

     對於每種包含元素或者混合內容的元素類型，建立一個表格和一個主鍵欄位。 

     對於每個包含混合內容的元素類型，建立一個單獨的表格，其中存放未析資料，通過父元素主鍵連結到父表格。 

     對於此元素類型的每個單值屬性和只包含未析資料內容、只出現一次的子項目，在該表格中建立一個欄位。如果元素類型或者屬性是可選的，可以讓設定該欄位為空白值。 

     對於每個多值屬性和多次出現的子項目，建立一個單獨的表格來儲存數值，並且通過父元素主鍵連結到父表格。 

     對每個有元素或者混合內容的子項目，通過父元素主鍵將父元素表格和子項目表格相串連。 

     下面的過程(經簡化)說明了如何從一個關係型的結構產生一個DTD:

     對於每個表格，建立一個元素； 

     對於表格中的每個欄位，建立一個屬性或者是只包含未析資料的子項目； 

     對於每個表格欄位中提供主鍵的主鍵/外鍵的關係都建立一個子項目。 

     不幸的是，這些過程還存在著一些缺陷。例如，DTD中沒有方法預先準確地規定資料類型或者欄位長度。

     因為任何的預先定義(例如通過讀取一個範例文件)在讀取其它“類型”的文檔或者其他文檔中包含有超過字長內容的文檔時就會產生錯誤。(長久之策是使用XML schema文檔的資料類型。)簡單來說，當從一關係型結構產生DTD時，是沒有辦法預先判斷子項目“應該”出現的順序或者欄位(如資料庫內部的行標識)是否該進行完全轉換。 
     
     在以上兩種情況中都可能產生命名的衝突。

     儘管有這樣那樣的缺陷，但是這些方法仍然能夠很好地奠定在關係型結構和DTD之間互相轉換的起點。