《電子技術(shù)應(yīng)用》
您所在的位置:首頁 > 嵌入式技術(shù) > 設(shè)計應(yīng)用 > 基于XQuery的商業(yè)報告查詢引擎的設(shè)計與實現(xiàn)
基于XQuery的商業(yè)報告查詢引擎的設(shè)計與實現(xiàn)
來源:微型機與應(yīng)用2013年第12期
王曉琳1, 樸 勇1, 王秀坤2
(1. 大連理工大學(xué) 軟件學(xué)院, 遼寧 大連116621; 2. 大連理工大學(xué) 電信學(xué)院, 遼寧
摘要: 基于XQuery查詢語言的XBRL查詢引擎首先借助JavaCC工具處理輸入的XQuery語句形成抽象語法樹,而后根據(jù)XQuery查詢特點編寫程序遍歷此語法樹來簡化查詢語言的處理流程,降低查詢匹配的復(fù)雜度,提高查詢效率,利用“SAX+ DOM”方式解析XBRL文件并提取XQuery語句所查詢的數(shù)據(jù)信息。SAX方法可以提高查詢效率并節(jié)省內(nèi)存消耗,DOM方法可以支持對XBRL文件的上下文相關(guān)查詢及頻繁查詢。實驗證明,將二者結(jié)合起來應(yīng)用滿足高查詢效率和低內(nèi)存消耗雙重需求。
關(guān)鍵詞: 軟件 XBRL XQuery 解析器
Abstract:
Key words :

摘 要: 基于XQuery查詢語言的XBRL查詢引擎首先借助JavaCC工具處理輸入的XQuery語句形成抽象語法樹,而后根據(jù)XQuery查詢特點編寫程序遍歷此語法樹來簡化查詢語言的處理流程,降低查詢匹配的復(fù)雜度,提高查詢效率,利用“SAX+ DOM”方式解析XBRL文件并提取XQuery語句所查詢的數(shù)據(jù)信息。SAX方法可以提高查詢效率并節(jié)省內(nèi)存消耗,DOM方法可以支持對XBRL文件的上下文相關(guān)查詢及頻繁查詢。實驗證明,將二者結(jié)合起來應(yīng)用滿足高查詢效率和低內(nèi)存消耗雙重需求。
關(guān)鍵詞: XBRL; XQuery; 解析器

    XBRL[1](可擴展商業(yè)報告語言)是XML語言的擴展應(yīng)用,主要面向金融財政領(lǐng)域,對其進行數(shù)據(jù)挖掘和分析具有重大意義,在實際項目中如何方便高效率地對其進行數(shù)據(jù)提取并降低內(nèi)存消耗是需要解決的問題。
     W3C制定的XQuery語言中的FLOWR[2]可以高效率地對XBRL進行查詢處理,目前國內(nèi)外有很多支持XQuery查詢語言的查詢引擎,如國外開源的XQEngine是一個基于JavaBean的用來查詢本地XML文檔的XQuery查詢引擎,該引擎使用SAX[3]解析方式來解析并提取XML中的所需信息,節(jié)省了內(nèi)存也保證了查詢速度。但是由于XBRL中的實例文件是承載財政數(shù)據(jù)的文件,其節(jié)點間存在密切的數(shù)據(jù)關(guān)聯(lián)關(guān)系,用戶多使用頻繁查詢及復(fù)合查詢等查詢實例文件進行數(shù)據(jù)分析,“邊讀邊扔數(shù)據(jù)”的SAX方式無法滿足這一需求。本文提出的SAX+DOM方式可以解決這一問題,同時在一定程度上比純DOM[4]讀取方式節(jié)省了大量內(nèi)存。
    圖1給出了基于XQuery的商業(yè)報告查詢引擎的整體框架,主要分為XQuery預(yù)處理模塊、查詢優(yōu)化器和查詢執(zhí)行器3個模塊。傳統(tǒng)的查詢優(yōu)化包括Schema模式優(yōu)化[5]、 XQuery語句查詢重寫、XML文檔索引技術(shù)、XQuery語句規(guī)范化等[6],而本文涉及的解析方式創(chuàng)新及抽象樹的遍歷簡化則是從查詢引擎內(nèi)部實現(xiàn)角度對XQuery查詢進行了優(yōu)化,下面著重對查詢引擎內(nèi)部優(yōu)化中的XQuery預(yù)處理模塊及查詢執(zhí)行器進行具體闡述。

1 遍歷Javacc生成的抽象語法樹
     XQuery查詢語言被設(shè)計用來查詢XML(XBRL本質(zhì)上也為XML)文件,其語法中的FLWOR表達式是最重要的,它代表 For-Let-Where-Order by-Return。For子句通過將節(jié)點綁定到變量,以便繼續(xù)循環(huán)遍歷序列中的每一個節(jié)點;let子句為一個變量賦一個值或一個序列;return 子句定義每個元組要返回的內(nèi)容;對于where子句,如果其有效布爾值為真,那么該元組就被保留,并且它的變量綁定用在return子句中,反之該元組就被廢棄[7]。
    在查詢預(yù)處理模塊,通過JavaCC[8]工具和W3C已定義的XQuery語法規(guī)則來進行詞法分析,將輸入的XQuery語句查詢語句中的每個成分都變成帶有特定屬性的節(jié)點并生成與之相對應(yīng)的類(例如顯示的是MainModule等,則語法解析時JavaCC中的JJtree以這些類為節(jié)點在內(nèi)存中生成樹形結(jié)構(gòu)),然后編寫程序遍歷抽象語法樹。下面的算法流程為遍歷FLOWR表達式中For語句對應(yīng)的抽象語法樹分支的流程,其中MainModule等均為使用JavaCC工具并根據(jù)W3C XQuery規(guī)范中XQuery BNF定義生成的語法樹中的抽象樹節(jié)點名字。XQuery語句解析算法的流程圖如圖2所示,首先取得根節(jié)點XQuery開始處理語法樹的內(nèi)容,循環(huán)三次依次得到QueryList、Module和MainModule節(jié)點。

    判斷節(jié)點MainModule是否為null,如為null,則報錯;如果不為null,取出第一個節(jié)點prolog和第二個節(jié)點QueryBody,分別對這兩個節(jié)點進行分析處理。
    對prolog節(jié)點進行處理,左節(jié)點prefix和右節(jié)點url為命名空間的格式,保存為名值對。在實際項目操作中,QueryBody環(huán)節(jié)只會出現(xiàn)一個FLOWR語句,很少會有嵌套語句,本文只給出FLOWR的子節(jié)點為ForClause的情況,其他子節(jié)點暫不考慮。
    判斷ForClause子節(jié)點類型,若為用來表示變量所對應(yīng)的Xpath值PathExpr節(jié)點,則取出PathExpr節(jié)點的子節(jié)點判斷其類型。節(jié)點為函數(shù)的情況下則調(diào)用預(yù)定義函數(shù),根據(jù)字段名稱在節(jié)點樹中定位并保存其內(nèi)容;如節(jié)點類型為分隔符,則表示任意節(jié)點都可以作為下一個節(jié)點字段的起始狀態(tài)。最后將PathExpr節(jié)點的處理結(jié)果ResultList與Varname變量節(jié)點對應(yīng)并保存。
2 結(jié)合SAX和DOM解析XBRL文件
    對于XBRL文件來說,存在DOM和SAX兩種基本的解析手段。如果進行一次性查詢或非頻繁性查詢,建議采用內(nèi)存消耗小的基于事件驅(qū)動模型的SAX解析方式,無需像DOM解析方式中為所有節(jié)點創(chuàng)建對象。但當需要大量上下文相關(guān)查詢及頻繁查詢時,尤其在查詢后經(jīng)修改合并而得到的結(jié)果集上進行復(fù)查詢,則采用DOM方式為好。
    XBRL文件解析分為兩種情況: (1)分類標準比較穩(wěn)定,對其進行首次框架解析后將在數(shù)據(jù)庫中將其保存,可以采取單獨的SAX解析方式簡單地進行逐條解析;(2)實例文件承載大量重要數(shù)據(jù),用戶多使用頻繁查詢及復(fù)合查詢等查詢實例文件來進行數(shù)據(jù)分析,在這種情況下DOM解析方式是最好的選擇。但是實例文件數(shù)量較多時,為XBRL實例文件中所有節(jié)點創(chuàng)建對象會大大增加內(nèi)存需求。這時需要考慮將這兩種方式結(jié)合起來使用。在讀取實例文件數(shù)據(jù)時,利用SAX只讀取用戶所需要的若干小數(shù)據(jù)文件,并為小數(shù)據(jù)文件在內(nèi)存中建立DOM對象,每次讀取新的數(shù)據(jù)片段,則在已存在的DOM對象上進行添加或者修改等操作。這樣做既有效地節(jié)省了大量資源,也充分利用了DOM對象的易操作性。
    圖3為兩種解析方式結(jié)合的工作原理,其處理過程為:首先SAX對象objSAX的parse方法被調(diào)用來解析XBRL實例文件,在startElement事件中進行元素篩選,如為所需元素,則保存該元素及其子節(jié)點元素,在endElement事件中調(diào)用DOM對象的loadXML()方法將數(shù)據(jù)轉(zhuǎn)化為DOM樹,從而可以方便下一步的數(shù)據(jù)處理(如頻繁查詢、信息更新等)。這樣不僅保證了快速解析,也在更大程度上支持XQuery的上下文查詢及信息檢索。

3 系統(tǒng)實驗結(jié)果
    實驗環(huán)境采用Inter Pentium Dual E2160 @1.80 GHz、1 GB 內(nèi)存、Windows XP。
    本文引擎解析文件時利用SAX+DOM方式,下面的實驗結(jié)果證明了使用這種方式的優(yōu)勢,如圖4所示。使用SAX+DOM方式處理時,只需將所需內(nèi)容裝入內(nèi)存,故文檔處理的時間不會因為文檔的大小發(fā)生太大變化,事件均小于0.003 s。而采用DOM方法處理文檔,當文檔大小達到一定程度時,需要使用硬盤的虛擬內(nèi)存,其處理時間也會急劇增大。


    本文所提出的查詢引擎簡化了XQuery語句解析流程和復(fù)雜度,節(jié)點尋址路線相對于開源軟件XQEngine變得簡單。本實驗利用上述兩種引擎對中國Taxonomy的cas_core_2010-09-30.xsd文件進行查詢,查詢語句如圖5所示,兩個解析器都正確地返回結(jié)果2 847個節(jié)點。本文提出的查詢引擎用時1.25 s,XQEngine因其復(fù)雜的XQuery解析算法使得用時稍長,為3.7 s。

 

 

    本文在深入剖析XQuery查詢語法特點后,結(jié)合“SAX+自定義DOM”文件解析方式完成對FLWOR抽象語法樹的遍歷及查詢信息讀取,來簡化XQuery語句的查詢處理流程并降低查詢匹配的復(fù)雜度,設(shè)計并實現(xiàn)了XBR查詢引擎,提高了查詢效率,降低了內(nèi)存消耗。該引擎在項目中的數(shù)據(jù)信息查詢模塊起著重要作用。
參考文獻
[1] 呂科,劉曉峰.XBRL技術(shù)原理與應(yīng)用[M].北京:電子工業(yè)出版社,2007.
[2] WALMSLEY P. XQuery權(quán)威指南[M].王銀輝,譯.北京:電子工業(yè)出版社, 2009.
[3] 馮進,丁博,史殿習(xí),等.XML解析技術(shù)研究[J].計算機工程與科學(xué),2009,31(2):120-124.
[4] 楊波.DOM解析器OnceDOMParser的設(shè)計與實現(xiàn)[D].北京:中國科學(xué)院研究生院(軟件研究所),2005.
[5] 孟曉峰,王宇,王小峰. XML查詢優(yōu)化研究[J]. 軟件學(xué)報, 2006,17(10):2069-20.
[6] PAPARIZOS S, PATEL J M, JAGADISH H V. SIGOPT:Using schema to optimize XML query processing international[C]. Istanbul: International Conference on Data Engineering, 2007.
[7] 華珊珊,謝鉉洋.XML查詢語言XQuery的研究與實現(xiàn)[J].計算機技術(shù)與發(fā)展, 2009,19(4): 48-50.
[8] VISWANDAHA S, SANKAR S. Java Compiler Compiler(JavaCC)-The java papser generator[J].URL:https://javaCC.dev.java.net.2006.

此內(nèi)容為AET網(wǎng)站原創(chuàng),未經(jīng)授權(quán)禁止轉(zhuǎn)載。