支援XML文件查詢的索引結構

全文

(1)支援 XML 文件查詢的索引結構張雅惠吳俊頡謝璨隆國立台灣海洋大㈻㈾訊科㈻系 202 基隆市北寧路２號 yahui@cyber.cs.ntou.edu.tw 電子公會，正嘗試利用 XML 訂定符合㉂己需. 摘要. 求的規則，作為㈾料交換的標準。而在電腦廠商㆗，康柏電腦主導的 [台威計劃]，設計. 近年來，在網際網路㆖從事商業行為，㈵別是處理㈽業與㈽業間大量㈾料的交換，成為. RosettaNet 提供全球供應鏈之㈿同㈾訊運作架. ㆒個非常重要的課題，而 XML (eXtensible. 構，即以 XML 來定義康柏與在台供應商之㈿. Markup Language) 的提出受到很大的重視與. 同商務運作模式。供應鏈㆗的㆖㆘游廠商，只. 廣泛的支持，我們預期未來將㈲很多㈽業將公. 要透過雙方同意的 XML 標準經由網際網路來. 司㈾料以 XML 格式存放。本篇論文討論管理. 傳輸㈾料，就可以快速的建立交易關係或分享訊息。. +. 眾多 XML 文件的方式，透過所設計的 B -Tree 與元素定位點兩種索引結構，可提高㈾料查詢. 因為預見未來大量的㈽業㈾料會以 XML. 的速度。我們並做了多㊠實驗，測試這兩種㈾. 表示，各大㈾料庫廠商如微軟、IBM、㆙骨文. 料結構個別的效率，而且討論同時使用這兩種結構來查詢時所需的時間。. (Oracle) 等，都在其既㈲的關聯式㈾料庫系統裡，擴充了處理 XML 的功能。但是，這些㈾料庫軟體本身相當昂貴，技術也很複雜，所以. 關鍵字：全球㈾訊網，XML 技術，查詢處理. 另㆒種作法是直接管理 XML 文件，如微軟提出 XML 的解析器(parser)，用來解析 XML 文. ㆒、簡介. 件，以便於針對 XML 文件開發應用程式。本篇論文提出的作法，是利用微軟處理 XML 文件之軟體開發套件，配合㉂行設計的㈵殊索引. 近年來，在網際網路 (Internet) ㆖從事商業行為，也就是所謂的電子商務，正蓬勃發展. 結構，包括元素定位點 (offset) 與 B+-Tree，. ㆗，而當前電子商務㆒個很受重視的課題，便. 以加快查詢 XML 文件時的速度。元素定位點. 是處理㈽業與㈽業間 (B2B) 的㈾料交換，. 是針對單㆒ XML 文件，表示其㈾料所在的位. XML (eXtensible Markup Language) 的提出則. 置，B+-Tree 則可以㈿助我們從多份 XML 文件. 加速了相關的發展。XML 是由 W3C (World. ㆗快速找到所需要的文件。經過多方的實驗與. Wide Web Consortium) 所訂定的㆒個描述. 測試，顯示我們所設計的索引結構的確㈲效㆞ 加速了查詢的速度。. Web 文件結構的標準規範，在 1996 年 11 ㈪㈲了最先的雛形，並於 1998 年 2 ㈪確立 XML1.0. 本篇論文的基本架構介紹如㆘：我們於第. 規格書。XML 為 SGML (Standard Generalized. ㆓節㆗，首先簡介 XML，說明其㈵殊的㈾料. Markup Language) 的子集，是㆒個結構性的、. 儲存格式及定義的方式，微軟提供的分析文件. 以文字格式儲存的標註語言 (markup. 的方法也㆒並介紹之；在第㆔節㆗，介紹我們. language)。XML 具㈲可擴充性，各個團體可. 為 XML ㈾料查詢處理所設計的㈾料結構，包. 以依 XML 的規範訂定符合㉂己需求的㈾料結. 括元素定位點及 B+-Tree 索引結構；我們對這. 構，而該團體的使用者依其規則建立出來的㈾. 兩個㈾料結構的效能所做的實驗，則在第㆕節. 料便具㈲㆒致的表示方式，使㈾料的交換與流通更為方便。. ㆗討論；最後，在第㈤節裡，我們舉出相關的研究報告以做比較，並在第㈥節的結論裡，指出未來的研究方向。. 目前㈲許多組織，包含銀行公會和高科技 1.

(2) L1 <?xml version="1.0" encoding="Big5" ?> <!DOCTYPE Books SYSTEM "Books.dtd"> L2 <Books amount="1"> L3 <Book id="N00001" no="312.4321" lang="ch"> L4 <Title>實戰 XML</Title> L5 <Author>Willian J. Pardi</Author> L6 <ISBN>9578239394</ISBN> L7 <Publisher>華采軟體</Publisher> L8 <Date year="1999" month="7" /> L9 <Keyword>XML</Keyword> L10 </Book> L11 L12 </Books> 圖㆒：XML 範例. L1 L2 L3 L4 L5 L6 L7 L8 L9 L10 L11 L12. <?xml version="1.0" encoding="Big5"?> <!ELEMENT Books (Book*)> <!ATTLIST Books amount NMTOKEN "1"> <!ELEMENT Book (Title, Author+, ISBN, Publisher, Date, Keyword+)> <!ATTLIST Book id ID #REQUIRED no NMTOKEN #REQUIRED lang (ch|en|jp|hz) "ch"> <!ELEMENT Title (#PCDATA)> <!ELEMENT Author (#PCDATA)> <!ELEMENT ISBN (#PCDATA)> <!ELEMENT Publisher (#PCDATA)> <!ELEMENT Date EMPTY> <!ATTLIST Date year NMTOKEN #REQUIRED month NMTOKEN #REQUIRED> <!ELEMENT Keyword (#PCDATA)> 圖㆓：DTD 範例. 圖例：. /. 元素. B o o ks. 屬性. am o un t. B oo k. 內容. 1. T itle. A uth or. ISB N. Publisher. 實戰 XM L. W illian J. Pardi. 9 57 82 3 93 94. 華采軟體. D ate. Keyword. id. no. lang. XM L. N 0 00 0 1. 3 12 .4 32 1. ch. y ear. m o nth. 1 9 99. 7. 圖㆔：DOM 結構範例. 2.

(3) L1 L2 L3 L4 L5 L6 L7 L8 L9. TCOMIXMLDOMDocument2 DOMPtr = CoDOMDocument30::Create(); DOMPtr ->async = false; DOMPtr ->load( “example.xml” ); TCOMIXMLDOMElement pRoot = DOMPtr ->documentElement; TCOMIXMLDOMNodeList pBooksList = pRoot->childNodes; TCOMIXMLDOMElement pBooksNode = pBooksList ->get_item( 0 ); TCOMIXMLDOMNodeList pBookItemList = pBooksList ->childNodes; TCOMIXMLDOMElement pBookNode = pBookItemList ->get_item( 0 ); AnsiString type = pRoot->text; 圖㆕：DOM 範例程式只㆒個時，可以用這㆔個部分為㆒個單位㆒直. ㆓、XML 簡介. 重複㆘去。譬如，由 L5 行開始，定義了 Book 這個元素具㈲ id、no、lang 這㆔個屬性，id 屬性的類別為 ID，表示該屬性值在同㆒個 XML. 我們首先簡單說明 XML 文件的結構。㆒. 文件㆗不可重複，預設行為的描述為 #REQUIRED ，表示該屬性值必須存在。. 份 XML 文件主要是由宣告 (declaration，或稱 prolog)、處理指令 (processing. instructions)、. 元素 (element) 以及註解 (comments) 所組. 為了分析 XML 文件，W3C 通過㆒種叫做. 成。圖㆒為㆒個 XML 文件的範例，圖㆗㊧欄. DOM (document object model) 的規格，提供了. 的 Li ㈹表行數，其㆗ L1 行為 XML 宣告，說. XML 文件架構模組的文件物件模型。它指出. 明此檔案採用的編碼為 Big5。L3 行的 Books. ㆒份文件均從㆒個根節點 (root node) 開始往. 為本文件㆗的根元素，㆒個 XML 文件㆗只能. ㆘發展成㆒個樹狀架構。圖㆔的 DOM 範例對. ㈲㆒個根元素。L4 行的 Book 是直屬於 Books. 應到圖㆒的 XML 文件，高度為 2 的節點為. 這個母元素㆘的子元素，它另外定義了㆔個屬. XML 文件之根元素 Books，根元素之㆘再建. 性，屬性等號後面的值則為屬性值，譬如 id. 立其他節點，包括子元素 Book 及屬性. 屬性的值為 N00001，no 屬性的值為. Amount，如此依序往㆘發展為㆒個樹狀結. 312.4321，lang 屬性的值為 ch。而 L5 ㉃ L10. 構。DOM 的內容包含了邏輯結構和實體結. 定義的子元素如 Title 等，則是進㆒步提供 Book 元素的相關㈾料。. 構，邏輯結構就如同圖㆗所示的每㆒個內部節點，它說明這份文件應該包含那㆒些元素及屬. 另外在圖㆒ L2 行裡使用了 Books.dtd，其. 性，並規定了這㆒些元素及屬性的順序，而實. 檔案的作用是檢查此文件是否正確。DTD. 體結構則為文件的真實㈾料也就是內容，如圖. (document type definition) 是用來定義某種. ㆗所示的每㆒個外部節點。透過 DOM 模型，. XML 文件的格式，也就是將每㆒個元素包含. 我們可以清楚㆞知道㆒個 XML 文件內部㈾料. 哪些子元素或屬性、各元素出現的順序等，清. 的相關性，以便於加以處理取出所需要的㈾料。. 楚㆞加以定義和規範。用 DTD 定義出來的㆒ 套元素組合，通常稱為「語彙」 (vocabulary) 。圖㆓即為 Books.dtd 的內容。. 我們所使用的 DOM 是 Microsoft 提供的 MSXML 3.0 軟體開發套件，其功用如同 W3C. 在 DTD 文件㆗，ELEMENT 標籤之後放. 所制定的，可以將 XML 文件分析並建立成如. 的是元素㈴，接著用小括號括起來的，是它的. 圖㆔的樹狀結構，它並進㆒步提供各種方法以. “內容模型”，也就是在對應的 XML 文件㆗可. 便取得元素內容或是屬性值，以㆘則以 C++ 的程式碼說明之。. 以出現的內容。圖㆓㆗的 L4 行說明，Book 這個元素包含了 Title、Author 等子元素，而在. 在圖㆕㆗的 L1 行，我們首先宣告 XML. L6 行㆗進㆒步註明 Title 元素存放的㈾料為. DOM 物件指標，指向㆒個新建立的 DOM 物. #PCDATA (parsable character data)，其為預先. 件；接著在 L2 行，我們設定此 DOM 物件的. 定義的標記，㈹表可解析的文字㈾料。. 行為，是先讀取完整個 XML 檔案再分析該文件。假定圖㆒內的 XML 範例所對應的檔案㈴. ATTLIST 標籤則是宣告元素的屬性，包含了屬性㈴、屬性類別及預設行為的描述，若屬性不 3.

(4) 00 01 00 61 00 50 00 44 00 66 00 7E 00 9E 00 BD unit 1 unit 2 unit 3 unit 4 unit 5 unit 6 unit 7 unit 8 圖㈤：元素定位檔範例稱為 example.xml，在 L3 行，我們以 DOM 物. 圖㈤表示的元素定位點㈾料對應到圖㆒. 件將此 XML 文件檔案載入，接㆘來我們就可. 的 XML 範例檔案，其㆗ unit 1 表示檔案內㈲. 直接從該 DOM 物件㆗把所要的元素取出。譬. ㆒個 record，這是因為圖㆒內的主要元素 Book. 如，在 L4 行，我們取得 DOM 物件的 root. 只出現㆒次。unit 2 到 unit 8 則組成本檔案內. element，也就是 Books 元素；而在 L5 行，則. 的唯㆒㆒筆記錄。unit 2 是表示第㆒個主要元. 取得 Books 元素㆘所㈲子元素的清單，在此範. 素(Book 元素)為從檔頭開始第 97（61h）byte，. 例㆗是所㈲ Book 元素所成的集合。同樣的，. 在檔案內我們以 16 進位表示，unit3 表示第㆒. 我們可用不同的方法 (method) 去取得更㆘層. 個子元素 Title 的㈾料距 Book 元素 45 (2Dh). 的元素。譬如在 L6 行㆗，我們取得 Book 元. bytes，unit 4 表示第㆓個子元素 Author 的㈾料. 素集合內的第 1 個元素，L7 行則取得第 1 個. 元素距 Book 元素 68 (44h) bytes，unit 5 到 unit. Book 元素㆘的所㈲子元素清單，在這裡指的. 8 也是依相同的方式表示。當子元素沒㈲㈾. 是 Title, Author, …等元素所成的集合；L8 行，. 料，以 0 (00h) bytes 來表示。我們記錄元素間. 取得第 1 個 Book 元素㆘子元素集合的第 1 個. 的相對位置，而非在檔案內的絕對位置，如此. 子元素，在這裡指的就是 Title 元素；最後的. 可使定位點㈾料不會因為 XML 檔案的㈾料修改而需頻頻修正。. L9 行，就可以直接取得 Title 元素的元素值，也就是 XML 文件 example.xml 內第 1 個 Book 元素㆘的第 1 個 Title 元素的值。. 接㆘來我們介紹為多份 XML 文件所設計的索引結構。㆒般㈽業若將㈾料以 XML 檔案. ㆔、索引結構. 存放時，由於㈾料量極大，所以多會表示成數個固定格式的 XML 檔案，也就是都符合同㆒ 個 DTD 檔案的定義。不過，若要查詢某筆㈵. 本節說明為支援快速查詢 XML 文件所設. 定㈾料時，必須循序搜尋所㈲檔案，效率會非. 計的㈾料結構，首先討論提供查詢單㆒ XML. 常不理想。因此，我們針對幾個比較重要的元. 文件的索引結構。由於 XML 檔案內的元素具. 素，建立查詢值 (search key) 與 XML 檔案對. ㈲固定的順序，所以我們利用此順序性建立元. 應的索引結構，如此便可直接開啟所需要的 XML 檔案，加快查詢的速度。. 素定位點 (offset)，以記錄元素在檔案內的位置，如此則可省略利用 DOM 分析整份 XML 文件的步驟，快速搜尋到某元素的㈾料。我們. 我們提出的索引結構，是依據目前傳統㈾. 設計讓㆒個 XML ㈾料檔案㈲㆒個對應的元素. 料庫裡最常見的 B+-Tree 樹狀結構所設計。㆒. 定位檔 (offset file)。檔案內每兩個位元組. 棵樹包含樹根 (root node) 、內部節點. (byte) 為㆒個單元 (unit)，第㆒個單元記錄此. (internal node) 及外部節點 (external node) ，. 檔案之記錄 (record) 個數，之後的單元則組. 每個節點皆存放數個查詢值與指標。如圖㈥所. 成㆒筆筆記錄。元素定位檔內的每㆒筆記錄對. 示，最㆖層的節點就是樹根，同時它也是此. 應到 XML ㈾料檔裡每㆒個主要元素的所㈲㈾. 樹唯㆒的內部節點，會指向其他內部節點或外. 料，所謂的 “主要元素” 是根元素之㆘的第㆒. 部節點。而最㆘層的兩個節點是外部節點，指. 個子元素。以圖㆒為例，根元素為 Books，而. 向真正㈾料存放的檔案位置。當我們要查詢某. 主要元素為 Book。每㆒筆記錄的第㆒個單. ㆒個值時，必須從樹根開始，根據查詢值的大. 元，記錄其對應的主要元素㈾料的位置，也就. 小往㆘走到最底層，然後循著指標將㈾料取回。. 是在 XML ㈾料檔案㆗與前㆒個主要元素㈾料之距離。而其後之單元，則記錄各子元素與主要元素的距離。. B+-Tree 的㈵色在於其樹狀結構是平衡的，也就是從樹根到外部節點的每條路徑都是 4.

(5) O ffic e. A c a d e m ic. B u sin ess. M arket. O ffic e. O cean. W in 9 8. XML. +. 圖㈥：B -Tree 結構 L1. <?xml version="1.0" encoding="Big5"?>. L2. <!ELEMENT Node (Pointer*,Next?)>. L3. <!ATTLIST Node type (ex|in) "ex">. L4. <!ELEMENT Pointer (#PCDATA)>. L5. <!ATTLIST Pointer key CDATA #REQUIRED>. L6. <!ELEMENT Next (#PCDATA)> 圖㈦：B+-Tree 節點檔案之 DTD. L1. <?xml version="1.0" encoding="Big5" ?>. L2. <!DOCTYPE BTree-Node SYSTEM "Btree.dtd">. L3. <Node type="ex">. L4. <Pointer key="Office">B0001.3,</Pointer>. L5. <Pointer key="Win98">B0002.2,</Pointer>. L6. <Pointer key="XML">B0001.1,</Pointer>. L7. <Next>B3.bt</Next>. L8. </Node> 圖㈧：B+-Tree 節點之範例檔案點，則存放㆘㆒層 B+-Tree 節點之檔㈴，而屬. 相同的長度，所以搜尋每個值所需的時間大致. 性 key 值則存放此指標對應的查詢值如. 相同。另外每個節點的大小㈲所限制。若. Office。若此節點為外部節點，則 L6 行定義的. B+-Tree 的 order 為 n，則每個內部節點（除了. Next 元素㈹表㆘㆒個外部節點的檔㈴，以方便處理範圍查詢。. 根節點）最多㈲ n 個指標（或 n-1 個查詢值），最少必須㈲ én / 2ù 個指標（或 é(n - 1) / 2ù 個查詢. 值），所以 B+-Tree 之高度不大於 élog én / 2 ù K ù ，這裡 K 為查詢值的個數。假設查詢值為 10,000. 圖㈧為 B+-Tree 節點的㆒個範例檔案，對應到圖㈥㊨㆘角節點，其格式遵循圖㈦之. 筆，當 order 為 20 時，則 B+-Tree 之高度只㈲. DTD。L3 行表示此檔案對應到㆒個外部節. 4，所以查詢的速度相當快。圖㈥的 B+-Tree 其 order 為 5。. 點，L4 行㉃ L6 行表示了此節點內的㆔筆㈾料，第㆒筆㈾料其查詢值為 Office，B0001.3 則表示完整的真實㈾料為 B0001 這個檔案㆗. 我們的設計是每㆒個 B+-Tree 的節點存成. 的第㆔筆㈾料。值得㊟意的是，我們不只指出. ㆒個 XML 檔案，其 DTD 如圖㈦所示。在該. 對應的檔案㈴，也㆒併記錄在該檔案裡的位. 圖㆗，L2 行表示 Node 元素為本文件之根元. 置，如此可省卻比較檔案內容的步驟，更進㆒. +. 素，內含多個 B -Tree 之指標，以 Pointer 元素. 步加快查詢的速度。最後 L7 行表示此外部節. 表示之。L3 行定義了 Node 的㆒個屬性 type，. 點的㆘㆒個外部節點，是對應到 B3.bt 這個檔. 用來㈹表對應節點之型態，若值為 ex ㈹表外. 案。此外我們還必須記錄每㆒個 B+-Tree，其. 部節點，若值為 in 則㈹表內部節點。 L4 行及. 根節點的檔㈴，以作為查詢的起點，此類㈾料. L5 行分別定義 Pointer 元素的內容及其屬性. 存放在系統設定檔內，該檔案也是 XML 格式。. key，若此節點為外部節點，則 Pointer 元素的內容存放真實㈾料之檔㈴與位置，若為內部節 5.

(6) 圖㈨：元素定位點與 DOM 查詢速度的比較. 表㆒：元素定位點與 DOM 查詢到大量㈾料筆數的效能比較㈾料筆數. DOM 所需時間. 元素定位點所需時間. 1948. 28101. 17996. 1928. 28190. 17986. 1925. 27800. 17605. 1894. 27780. 17485 PentiumIII650 的個㆟電腦及 256M 的記憶體. 於是，利用 B+-Tree 索引結構和元素定位. (RAM)，加㆖ Win2000 Server 的作業系統。實. 檔，從多份 XML 文件㆗查詢到㈵定㈾料的處理步驟大致如㆘：. 驗㆗所用來測試的㈾料，是以電腦亂數的方式產生，而實驗數據的收集是根據關鍵字的查. 1. 利用系統設定檔，找出所查詢元素，如 Title. 詢。為了避免程式執行時㈲不確定因素影響到. +. 或 Keyword 所對應的 B -Tree 根節點為何檔案，開啟該檔案。. 實驗結果，我們都是在固定的系統環境㆘，進行多次的實驗，取得平均值。以㆘針對各實驗作仔細的說明。. 2. 若開啟的檔案對應到 B+-Tree 的內部節. (㆒) 元素定位點與 DOM 的效能比較. 點，則比較查詢值的大小，繼續走到樹的㆘ ㆒層，也就是開啟另㆒個 B+-Tree 節點檔案。. 在本實驗㆗，我們利用所設計的元素定位點，與微軟所提供的 DOM 元件，比較對單㆒. 3. 若開啟的檔案對應到 B+-Tree 的外部節. XML 文件查詢的速度。該文件表示了 50000. 點，且真實㈾料存放的位置假設為. 筆不同的書籍㈾料。. Bxxxx.n，則先開啟 Bxxxx.xml 所對應的元. 如圖㈨所示，找到㈾料的筆數為 X 軸，. 素定位檔 Bxxxx.of，取得第 n 筆㈾料位於. 查詢所需時間為 Y 軸，以微秒 (ms) 為單位。. Bxxxx.xml 內的位置所在，然後再開啟. 元素定位點 (offset) 所對應到的折線是以圓. Bxxxx.xml ㈾料檔案，利用之前得到的位置. 圈連起來，位於圖的㆘方，而 DOM 則是對應. ㈾訊，直接取出第 n 筆元素㈾料，處理後傳. 到以方塊連起來的折線，位於圖的㆖方。我們. 回結果。. 可觀察到，DOM 所需的時間，遠遠㆞超過元素定位點，這是因為 DOM 必須先分析完. ㆕、實驗結果. 50000 筆㈾料，以建立出如圖㆔的樹狀結構，而這段時間花費甚鉅。. 在本節㆗我們設計數個實驗，來評估所提出的索引結構的效能。我們使用的實驗環境為 6.

(7) 350. 9 8 7 6 5 4 3 2 1 0. 300 250 200 150 100 50 2500. 2250. 2000. 1750. 1500. 1250. 1000. 750. 500. 250. 0. 0 y = 96.873Ln(x) + 22.318. 圖㈩：檔案個數與利用 B+-Tree 查詢所需時間之對照表另外，我們也發現到，不管使用何種方. 而圖㈩㆗，由菱形方塊連成的折線圖記錄. 法，查詢所需的時間會隨著找到的㈾料筆數增. 各種不同檔案個數查詢所需的時間。我們發. 加，但元素定位點顯然較 DOM 增加得還快。. 現，當檔案個數增加時，查詢的時間並沒㈲隨. 為了瞭解當找到的㈾料筆數非常大時，使用元. 之線性成長，由此可見針對多個檔案的查詢，. 素定位點查詢是否仍然較 DOM 快，我們做了. B+-Tree 提供了比循序查詢更㈲效的方法。我. 如表㆒的實驗。由表㆒所示，在找到的㈾料筆. 們也根據折線圖找到㆒條對數的趨近線，以玆. 數將近兩千筆時，雖然兩者的差距較圖㈨的大. 對照。同時我們發現，當 B+-Tree 的高度增加. 為減少，但是 DOM 的時間仍然約為元素定位點的㆒倍半。因此我們再做了㆒個㈵殊的實. 時，查詢時間不㆒定隨之增加，這是因為查詢. 驗，也就是比較兩者將所㈲書籍㈾料 (50000. 時間除了和 B+-Tree 高度㈲關外，亦與每個關. 筆) 找出來所需的時間，在這個實驗㆗，使用. 鍵字在 B+-Tree 節點內所在的位置㈲關，也就. 元素定位點查詢時所需的時間為. 是關鍵字的分布會讓搜尋時間㈲差異。目前我. 1138654ms，而使用 DOM 查詢時所需的時間. 們所使用的是線性搜尋的演算法，若是改用其. 為 1102456ms，兩者的差距並不大。因此我們. 它更快速的搜尋演算法，如㆓元演算法，可讓. 可以得知，使用元素定位點查詢確實較 DOM. 此現象較不明顯。. 快，其差距則隨著找到的㈾料筆數越多而遞 (㆔) Cost Model 的建立. 減。. 在本節㆗，我們希望建立出㆒個時間公式. (㆓) B+-Tree 與多檔案查詢效能的關係. (cost model)，可以用來推算利用我們的. 本實驗是測試當 XML 檔案很多時，. B+-Tree 與元素定位點，去多個 XML 檔案㆗查. B+-Tree 索引比循序查詢更㈲效率。我們將 20. 詢㈾料時，所需要的時間。我們以 I/O cost 做. 筆書籍㈾料存放在㆒個檔案，分別針對擁㈲不. 為 cost model 的衡量標準，並不考慮 CPU. 同檔案個數的㈾料做關鍵字的查詢，關鍵字對. time，而處理㆒個 block 的時間視為㆒個 I/O. 應到的 B+-Tree 之 order 則定為 4。. cost。由於我們使用的 Win2000 作業系統磁碟. 如圖㈩所示，X 軸為檔案個數，㊨側的 Y. 分割格式為 NTFS，其㆒個 block 的大小為 512. 軸刻度表示查詢所需的時間，這裡的時間只記. bytes，為了簡化起見，我們讓 2 筆書籍㈾料存. 錄找到㈾料所在的檔案。根據查詢的演算法，. 放在㆒個 XML 檔案，所以存取㆒個 XML 檔案約為㆒個 block I/O。. 該時間應該就是走過 (traverse) B+-Tree 的時間，所以我們在㊧側的 Y 軸刻度同時表示. 雖然在這樣的設計㆘，每個 XML 檔案、. B+-Tree 的高度，並利用柱狀圖㈹表各種不同. offset 檔案、及 B+-Tree 的所㈲節點檔案，大. 檔案個數所對應到的 B+-Tree 高度。 7.

(8) 表㆓：實際時間與預測時間對照表實驗. A. B. C. D. E. 實際時間預測時間(I/O cost) 比率(實際/預測). 24.14 45. 88 0.5262. 25.94 49. 88 0.5200. 28.94 53. 88 0.5371. 30.14 57. 88 0.5207. 32.45 61. 88 0.5244. 實驗. F. G. H. I. J. 實際時間預測時間(I/O cost) 比率(實際/預測). 26.64 53. 88 0.4944. 26.44 53. 88 0.4907. 30.05 60.86 0.4938. 25.74 51. 88 0.4961. 31.24 62.86 0.4970. 小皆約為㆒個 block，但是 B+-Tree 的節點檔案. 的實驗做進㆒步的說明。. 都必須被 DOM 解析(parse)，而由先前的實驗. 表㆓㆗的實驗 A 到 E 以具㈲ 2000 個關鍵. 得知，它會耗費相當大的時間，不可忽略。為. 字的 10000 筆書籍㈾料做為實驗範本，B+-Tree. +. 了得到每個 B -Tree 節點檔案比純粹對㆒個. 的 order 為 4，其所建立的 B+-Tree 高度為 6，. block 做 I/O 時多花的額外時間，我們加以實. 而根據關鍵字的查詢所找到的㈾料，由實驗 A. 驗，結果得到處理㆒個 XML 檔案及其相對應. 到 E 分別為 2、4、6、8、10 筆。觀察表㆓㆗. 的㆒個 offset 檔案共需要 1.0525ms，加以平均. 的數據，我們發現由於 B+-Tree 的高度為定. 得到處理㆒個檔案的時間，也就是㆒個 block. 值，所以查詢時間並不受 B+-Tree 高度的影. I/O 需要花 0.5263ms。另外我們得到處理㆒個. 響，而是隨著找到㈾料筆數的增加而增加，此. B+-Tree 節點檔案需要 3.6716 ms，相除後得知. 結果與我們的 cost model 吻合。. 處理每個 B+-Tree 節點檔案大約需要 6.98 個. 而在表㆓的實驗 F 、G 及 H，則分別以. block I/O 的時間。根據此結果，我們㈲㆘列推論：. 具㈲ 1000、2000 和 5000 個關鍵字的 10000 筆. cost model. 高度各為 6、6 和 7，我們取根據關鍵字查詢. 書籍㈾料做為實驗範本，其所建立的 B+-Tree 所找到的㈾料為 6 筆的查詢時間。我們發現當. +. ＝B -Tree 所需之時間+元素定位點所需之時間+XML 檔案所需之時間. 找到的㈾料筆數固定時，查詢時間隨著 B+-Tree 的高度而改變，這個結果也符合我們 cost model 的設計。同時我們發現，當實驗的. ＝6.98×B+-Tree 之高度+找到㈾料所對應的元. ㈾料來源及環境完全相同時，如實驗 C 及實驗. 素定位點檔案個數+找到㈾料所對應的 XML 檔案個數. G 皆是以擁㈲相同 2000 個關鍵字的 10000 筆書籍㈾料做為實驗範本，而使用不同的關鍵字做查詢時，雖然找到的㈾料筆數相同，可是其實際的查詢時間卻不㆒樣，這是因為關鍵字在. 為了驗證我們所訂定的 cost model 之正確. B+-Tree 節點內的分布會影響搜尋時間。. 性，我們針對 5000 個 XML 檔案加以實驗，根據關鍵字的查詢，將實際所需的時間記錄在. 最後，表㆓㆗的實驗 I 及 J，以分別具㈲. 表㆓㆗的第㆓欄。表㆗的預測時間 (第㆔欄)，. 3000 和 5000 個關鍵字的 10000 筆書籍㈾料做. 則是利用 cost model 的公式計算出來。由該公. 為實驗範本，其所建立的 B+-Tree 高度各為 6. 式得知，實際時間與預測時間的比率，就是對. 和 7，而找到的㈾料筆數則為 5 和 7 筆，也就. ㆒個 block 實際做 I/O 所需的時間，我們由表. 是所㈲的環境皆不同。但觀察實驗數據，我們. ㆓的第㆕欄可以發現，大部份的實驗結果都與. 發現實際的查詢時間與 cost model 所預測的. 之前得到的 0.5263 相當接近，由此可知我們. I/O cost 非常接近，由此可知我們所訂的 cost. 的 cost model 相當正確。以㆘對各個不同環境. model 是正確的。 8.

(9) 定義做㆒個統㆒而㈲效的管理，所以可以從眾. ㈤、相關研究. 多 XML 文件㆗找到查詢所需要的文件，而加快 XML 文件的查詢速度 [8]。㉃於在 [6]. 隨著 XML ㈰益受到重視，眾多研究者也. ㆗，則設計了㆒個多緒 (multi-threaded) 的系. 開始進行相關的研究。例如，㈲研究者針對. 統，可以平行處理多個查詢 XML ㈾料的需. XML ㈾料實作了 Java 翻譯引擎( rendering. 求，所以效能可以達到可調整 (scalable) 的目的。. engine)，以便處理具㈲複雜㈵殊符號的文件 (Z Specifications)，並使其可在網際網路㆖快. ㈥、結論. 速傳遞與呈現 [5] 。 XML-GL [3]，則為針對 XML 文件的圖形化查詢語言，可提供傳統關聯式㈾料庫的基本查詢功能。種種 XML 在㈾. 電子商務是未來的趨勢，在網際網路㆖從. 料庫㈻門所帶來的影響以及可能的研究方. 事㈽業間的㈾料交換，是其㆗重要的課題，而. 向，在文獻㆗已可見廣泛的討論 [11]，以㆘ 則針對和我們論文較為相近的研究提出討論。. XML 的推出更加速了這方面的推展，我們相信未來㈲很多㈽業將會以 XML 表示其㈾料。本篇論文的目的，是討論加快眾多 XML 文件. 由史丹佛 (Stanford) 大㈻提出的 Lore 計劃，實做㆒套半結構化㈾料 (semistructured. 查詢速度的方式，我們設計了 B+-Tree 及元素. data) 的管理系統，該系統的查詢語言 Lorel. 定位點的㈵殊㈾料索引結構，並建立測試㈾料. [1]，能夠表示比 SQL 更具彈性的查詢句。為. 測量效能。根據我們的實驗數據，不管是針對. 了針對此語言的查詢過程做最佳化的處理，相. 單㆒ XML 文件，或是多份 XML ㈾料，我們所設計的索引結構都提供相當好的查詢效率。. 對應的索引結構也同時被提出 [9]。由於 XML 具㈲半結構化的㈵性，所以該研究㈲很大的參. 本研究未來可能改進的方向㈲㆘列幾點：. 考性，而史丹佛大㈻也逐漸把該系統轉化為 XML ㈾料的管理系統。他們除了針對 XML. 1.. 我們目前設計的 B+-Tree 索引結. ㈾料可能的路徑表示 (path expression) 提出. 構，由於是 XML 格式，所以仍然. 數個索引結構，另外也提出更複雜的㈾料庫統. 需要透過微軟提供的 DOM 發展套. 計與執行策略，使該系統能夠對 XML ㈾料提供㈲效的查詢處理 [10]。. 件來分析該 XML 文件，耗時極大，未來希望能加以改善。. ㉃於在單㆒ XML 文件的查詢處理方面，. 2.. 目前所設計的索引結構只支援針對. ㈲的研究者針對 PAT algebra 提供的㆕種運. 某㆒㈵定元素的查詢，隨著更多. 算，也就是內容選擇 (content-select) 、屬性. XML 查詢語言結構的提出，我們希. 選擇 (attr-select) 、字串包含和被包含. 望能擴充目前的設計，以支援更複雜的查詢功能。. (includes 和 incl-in)等，設計以事件為基礎 (event-based) 和以樹狀為基礎 (tree-based) 的處理方式，同時討論最佳化處理的方法. 誌謝. [2]。㈲研究者則設計了聚集 (aggregation) 函. 此計畫由國科會贊助，編號為：NSC. 式，並利用傳統㈾料庫 “pushing selections”. 90-2213-E-019-011. 的方法，為查詢處理做最佳化 [7]。㈲的研究. ㈦、參考文獻. 者則替 XML 查詢提供了㆒個㈹數的方法，然後依此基礎設計同時使用數個不同㈾料庫的方式，並達到最佳的執行策略 [4]。. [1]. S. Abiteboul, D. Quass, J. McHugh, J. Widom, J. Wiener, “The Lorel Query Language for Semistructured Data”, International Journal on Digital Libraries, volume 1, number 1, pages: 68–88, 1997.. [2]. K. Bohm, “On extending the XML engine. 另外㆒個與本論文相關的議題是眾多 XML 文件或㈾料可能產生的效能問題。XML 綱要目錄 (XML schema directory)，是㆒個㈵殊的索引結構，它將不同 XML 文件的綱要 9.

(10) with query-processing capabilities”, In Proceedings of IEEE Advances in Digital Libraries, pages: 127 –138, 2000. [3]. S. Ceri, S. Comai, E. Damiani, P. Fraternali and L. Tanca, “Complex Queries in XML-GL”, ACM Symposium on Applied Computing, volume 2, pages: 888 – 893, 2000.. [4]. V. Christophides, S. Cluet and J. Simeon, “On Wrapping Query Languages and Efficient XML Integration”, In Proceedings of ACM SIGMOD Conference on Management of Data, pages: 141–152, 2000.. [5]. P. Ciancarini, F. Vitali, C. Mascolo, “Managing Complex Documents Over the WWW: A Case Study for XML”, IEEE Transactions on Knowledge and Data Engineering, volume 11, issue 4, pages: 629 – 638, 1999.. [6]. T. Grabs, K. Bohm, H.- J. Schek, “Scalable Distributed Query and Update Service Implementations for XML Document Elements”, Eleventh International Workshop on Proceedings of Research Issues in Data Engineering, pages : 35 – 42, 2001.. [7]. H. Kato, K. Oyama, M. Yoshikawa, S. Uemura, “A query optimization for XML document views constructed by aggregations”, Proceedings of 1999 International Symposium on Database Applications in Non-Traditional Environments, pages: 189 –196, 1999.. [8]. E. Kotsakis, K. Bohm, “XML Schema Directory: A data structure for XML data processing”, Proceedings of the First International Conference on Web Information Systems Engineering, volume 1, pages: 62 – 69, 2000.. [9]. J. McHugh, J. Widom, “Query optimization for semistructured data”, Technical report, Stanford University Database Group, February 1999.. [10]. J. McHugh, J. Widom, “Query Optimization for XML”, Twenty-Fifth International Conference on Very Large Databases, 1999.. [11]. J. Widom, “Data Management for XML : Research Directions”, IEEE Data Engineering Bulletin, volume 22, number 3, 1999. 10.

(11)