相關期刊
時間：2022-01-30 23:44:56
序論：好文章的創(chuàng)作是一個不斷探索和完善的過程，我們?yōu)槟扑]十篇關系數(shù)據(jù)庫范例，希望它們能助您一臂之力，提升您的閱讀品質(zhì)，帶來更深刻的閱讀感受。
中圖分類號：TP311文獻標識碼：A文章編號：1009-3044(2012)05-1002-02
A Brief Analysis of the Relationship between Notes Databases and Relational Databases
YE Hao-bo
(City College of Dongguan, University of Technology, Dongguan 523106, China)
Abstract: With the wide application of office automation system, the Notes database technology has become a hot issue for it’s suitable for office automation system workflow. This paper analysis the relationship between the Notes database and the relational database and their re? spective advantages at first; then desribe the transformation method between the Notes database and the relational database from the applica? tion angle.
Key words: workflow technology; notes databases; relational databases; transforming method
在科技不斷發(fā)展的今天，辦公室人員的工作已經(jīng)發(fā)生了較大的變化，已經(jīng)從原來的數(shù)據(jù)與文件為中心的個人獨立工作方式發(fā)展到了以工作流為核心的團隊工作上。現(xiàn)代化的辦公體系正朝著高速的信息處理、統(tǒng)一的工作流程、先進的知識管理為一身的知識型方向發(fā)展，所以現(xiàn)代化辦公自動化（OA）系統(tǒng)在現(xiàn)代化的企業(yè)管理中發(fā)揮的著越來越重要的作用。
OA系統(tǒng)的后臺數(shù)據(jù)庫產(chǎn)品有很多，從目前的軟件開發(fā)的情況來看，主流產(chǎn)品是IBM的Notes數(shù)據(jù)庫，正因為如此，Notes數(shù)據(jù)庫已經(jīng)成為大家關注的熱點問題，而在辦公自動化系統(tǒng)里有一部分功能的實現(xiàn)需要用到關系數(shù)據(jù)庫，這兩種數(shù)據(jù)庫之間的關系及他們之間的轉(zhuǎn)化方法是怎的呢？本文下面將作一個簡單的分析。
1工作流技術
從OA系統(tǒng)的發(fā)展過程來看，我們可以清楚的認識到，辦公自動化系統(tǒng)的核心技術是工作流技術。那么什么是工作流技術呢？它是在一個工作群組中，為了一個共同的目的或者某種任務，在這個群組的人員需要共同協(xié)作地去完成某一項工作，工作的方式可以是按先后順序或者同時進行。它包含一組活動、活動之間的內(nèi)在關系、活動開始和結(jié)束的條件、活動的功能描述等內(nèi)容。概括來說，它是一個電子化的辦公流程，能方便地處理辦公系統(tǒng)中文檔的收發(fā)、傳遞、審閱等操作。把工作流技術用在OA系統(tǒng)中可以對現(xiàn)代化管理提供幫助：
第一、它可以加強事務處理的各個環(huán)節(jié)的協(xié)同工作的能力，從而可以讓工作的運作的非常通暢。
第二、工作流技術將各項事務的管理由原來的人工管理轉(zhuǎn)變?yōu)楣ぷ髁鞣掌鱽砉芾恚赞k公人員可以從大量的繁瑣的工作中解脫出來，從而可以將工作重點轉(zhuǎn)換到怎么更好地做好事件。
第三、工作流技術對工作流程重組提供了非常實用的技術支持和分析方法。在快速發(fā)展的當今社會，管理水平和技術水平都在日益更新，對于辦公室的工作流程發(fā)生變化的機會也在增多。所以辦公自動化系統(tǒng)應該能夠快速適應這種動態(tài)的變化。一般傳統(tǒng)的技術或者方法不能適應這種變化，可是工作流技術和OA系統(tǒng)的結(jié)合就能很快適應這種動態(tài)變化，從而實現(xiàn)企業(yè)的協(xié)同辦公。
2關系數(shù)據(jù)庫與Notes數(shù)據(jù)庫的比較與轉(zhuǎn)化方法
2.1關系數(shù)據(jù)庫和Notes數(shù)據(jù)庫的比較
Notes數(shù)據(jù)庫：它主要是以存儲文本文檔為其主要內(nèi)容的數(shù)據(jù)庫管理系統(tǒng)，也就是說它的數(shù)據(jù)的元組就是文本文檔，是一種非數(shù)值型的數(shù)據(jù)。但是這種非數(shù)值型（非結(jié)構(gòu)型）的數(shù)據(jù)對于Lotus Notes處理起來更為方便，如視頻、聲頻、傳真、OLE對象、圖形、頁面、表格等數(shù)據(jù)類型Notes處理起來會靈活一點。
對于數(shù)據(jù)的訪問，Lotus Notes是通過全文檢索方式訪問數(shù)據(jù)庫的數(shù)據(jù)，對于檢索定位方面，Lotus Notes是通過視圖定位數(shù)據(jù)的方式。
關系數(shù)據(jù)庫：它是一個數(shù)值型的DBMS，主要通過數(shù)學公式來處理數(shù)據(jù)，所以對于一個事務型的流程，它必須先將其轉(zhuǎn)化為嚴格 的數(shù)學公式以后，才能在數(shù)據(jù)庫上進行處理，數(shù)據(jù)庫中的表實際就是一張二維表，關系型數(shù)據(jù)庫對一些結(jié)構(gòu)化（數(shù)值型）的數(shù)據(jù)處理起來相當快捷。
對于數(shù)據(jù)的訪問，關系型數(shù)據(jù)庫是通過SQL語言訪問數(shù)據(jù)庫的數(shù)據(jù)，對于檢索定位方面，關系型數(shù)據(jù)庫是通過實時查詢來定位數(shù)據(jù)。
通過上述的比較，兩種數(shù)據(jù)庫各有各的優(yōu)勢，而在辦公自動化系統(tǒng)中有一些部門可能會用到一些復雜計算、數(shù)據(jù)處理等方面的功能，我們知道這些都是Notes不太善長的地方，又加之現(xiàn)在的JSP、ASP等腳本語言訪問關系型數(shù)據(jù)庫是十分方便的，所以要是能將兩種數(shù)據(jù)庫進行相互轉(zhuǎn)化就能解決系統(tǒng)中的問題，下面本文介紹在本系統(tǒng)中他們之間的轉(zhuǎn)換方法。
2.2兩種數(shù)據(jù)庫之間的轉(zhuǎn)化方法
2.2.1 Notes數(shù)據(jù)庫轉(zhuǎn)化為關系數(shù)據(jù)庫
為了與其他的管理信息系統(tǒng)進行信息的交換，在Notes數(shù)據(jù)庫管理系統(tǒng)里面有一套專門針對和外部程序數(shù)據(jù)的擴展類庫，也就是Lotus Script Data Object，，這套擴展類庫由三個基本的類構(gòu)成的一個整體，它們分別是ODBC Result Set、ODBC Query和ODBC Connection，通過他們來完成與外部數(shù)據(jù)之間的訪問和修改，由于它所使用的標準是ODBC，就通過這樣的標準來讀取的修改外部數(shù)據(jù)庫的數(shù)據(jù)的屬性和相應的方法。這三種類主要分工是這樣的，ODBC Connection是負責與外部數(shù)據(jù)庫之間的連接，ODBC Query主要用于一個結(jié)構(gòu)化查詢語言語句的定義，而ODBC Result Set主要用于在通過SQL語句查詢結(jié)果數(shù)據(jù)集上執(zhí)行相應數(shù)據(jù)讀取的操作，在數(shù)據(jù)庫中我們主要利用RTF域存放Notes文檔數(shù)據(jù)，而對于RTF域來說，我們可以在數(shù)據(jù)庫的表單的任何位置放置它，正是因為RTF域可以包含無限制的數(shù)據(jù)的特點剛好可以滿足文本的特性，所以對于文本中包含有圖片、文字、獨立的文件、甚至可以是一些對象。在關系型數(shù)據(jù)庫中常處理的一些數(shù)據(jù)，如文件的名字、生成的時間、文字、日期等我們可以在關系型數(shù)據(jù)庫直接處理。對于每一個程序文檔完成后就執(zhí)行QuerySave，使用Lotus腳本語言編寫子程序模塊QuerySave將查詢的信息數(shù)據(jù)寫到關系型數(shù)據(jù)庫中。
綜上所述，Notes數(shù)據(jù)庫轉(zhuǎn)化為關系數(shù)據(jù)庫可以是以下幾個過程；
第一步就是要創(chuàng)建三個類：即ODBC Connection、ODBC Query、ODBC Result Set；
第二步就是數(shù)據(jù)庫的連接，即用ConnectTo函數(shù)連接到SQL數(shù)據(jù)庫，同時使用查詢語句進行查詢操作；
第三步就是將查詢的qry. Sql和結(jié)果集相連接，執(zhí)行有關函數(shù)如result.execute查詢到關系數(shù)據(jù)庫中的情況，當result.currentrow等于零的時候，則可以寫入新一批的數(shù)據(jù)，李不然就修改數(shù)據(jù)。
2.2.2關系數(shù)據(jù)庫轉(zhuǎn)化為Notes數(shù)據(jù)庫
在Notes數(shù)據(jù)庫中我們采取ODBC標準來訪問各種不同數(shù)據(jù)類型的信息，我們可以利用Notes的內(nèi)部函數(shù)或者相應的腳本語言，就可以將關系數(shù)據(jù)庫中的有關數(shù)據(jù)寫入到Notes文檔中，把這些數(shù)據(jù)變換為Notes數(shù)據(jù)，我們具體的方法有兩種：
方法一：將@Db函數(shù)引入到Notes有關的函數(shù)當中。Notes內(nèi)部有三個函數(shù)，即@DbCommand、@DbLookup和@DbColumn，只要在上述函數(shù)在第一個參數(shù)使用了“ODBC，這樣就是讀取有關的關系型數(shù)據(jù)庫中的表，這種方法也有很明顯的不足之處，它對于信息的提取只能以列的方式進行，不能以行的方式進行。
方法二：采用Lotus Script數(shù)據(jù)對象LSX，同時利用Lotus腳本語言編寫相關的數(shù)據(jù)讀取函數(shù)，在Notes里面的ODBC Connection、ODBC Query、ODBC Result Set就是使用ODBC標準來讀取外部的各種不同的數(shù)據(jù)。
上面兩種方法進行比較，作者認為第二種方法更為科學，下面就簡單談談這種方法的實現(xiàn)過程：
首先，在Notes數(shù)據(jù)庫中，我們按照SQL數(shù)據(jù)庫相應表單里的結(jié)構(gòu)同樣建立一個一樣結(jié)構(gòu)的表單，這樣做的好處就在于能夠?qū)㈥P系型數(shù)據(jù)庫中的數(shù)據(jù)進行一一轉(zhuǎn)換，并且容易理解，然后就建立相關的，用腳本語言寫相應的轉(zhuǎn)換程序；
然后，創(chuàng)建視圖來執(zhí)行上述的，從而可以實現(xiàn)將關系型數(shù)據(jù)庫中有關的數(shù)據(jù)表單轉(zhuǎn)換成notes數(shù)據(jù)庫中的信息。
3結(jié)束語
本文在上面的敘述當中我們可以發(fā)現(xiàn)在OA系統(tǒng)的開發(fā)過程中，只要處理好數(shù)據(jù)庫，就可以做到有的放矢，這就是說，我們可以根據(jù)系統(tǒng)的要求，在需要使用Notes數(shù)據(jù)庫的模塊里就Notes數(shù)據(jù)庫，在需要使用SQL數(shù)據(jù)庫的地方就使用關系型數(shù)據(jù)庫，通過相應的轉(zhuǎn)換辦法，就可以實現(xiàn)它們之間的數(shù)據(jù)共享。
參考文獻：
0 引言
關系數(shù)據(jù)庫是20世紀70年代初提出來，經(jīng)過數(shù)據(jù)庫專家?guī)资甑呐Γ碚摵蛯嵺`都取得了顯著成果，標志著數(shù)據(jù)庫技術的日益成熟。但它仍然難以實現(xiàn)對關系數(shù)據(jù)庫中數(shù)據(jù)的分析，不能很好地支持決策，因此在80年代，產(chǎn)生了數(shù)據(jù)倉庫的思想，90年代，數(shù)據(jù)倉庫的基本原理、架構(gòu)形式和使用原則都已確定。主要技術包括對數(shù)據(jù)庫中數(shù)據(jù)訪問、網(wǎng)絡、C / S結(jié)構(gòu)和圖形界面，一些大公司已經(jīng)開始構(gòu)建數(shù)據(jù)倉庫。針對數(shù)據(jù)倉庫中迅速增長的海量數(shù)據(jù)的收集、存放，用人力已經(jīng)不能解決，那么數(shù)據(jù)倉庫中有用的知識的提取就需要數(shù)據(jù)挖掘來實現(xiàn)。數(shù)據(jù)挖掘與統(tǒng)計學子領域“試探性數(shù)據(jù)分析”及人工智能子領域“知識發(fā)現(xiàn)”和機器學有關，是一門綜合性的技術學科。了解關系數(shù)據(jù)庫、數(shù)據(jù)倉庫與數(shù)據(jù)挖掘三者之間的區(qū)別與聯(lián)系，使之更好的使用這3種技術，處理各種信息需求是非常必要和重要的。
1 關系數(shù)據(jù)庫、數(shù)據(jù)倉庫和數(shù)據(jù)挖掘之間的關系
1.1 關系數(shù)據(jù)庫和數(shù)據(jù)倉庫之間的聯(lián)系與區(qū)別
關系數(shù)據(jù)庫是面向事務的設計，數(shù)據(jù)倉庫是一個面向主題的設計；關系數(shù)據(jù)庫存儲在線事務數(shù)據(jù)，數(shù)據(jù)倉庫通常存儲歷史數(shù)據(jù)，關系數(shù)據(jù)庫的設計將盡量避免冗余，但數(shù)據(jù)倉庫是傾向于引入冗余；關系數(shù)據(jù)庫設計用于捕獲數(shù)據(jù)，數(shù)據(jù)倉庫設計用于分析數(shù)據(jù)。傳統(tǒng)的關系數(shù)據(jù)庫面向以事務處理為主的系統(tǒng)應用，所以它無法滿足決策支持系統(tǒng)的分析要求。事務處理和分析處理有非常不同的性質(zhì)，他們有不同的需求數(shù)據(jù)。
1.2 數(shù)據(jù)倉庫與數(shù)據(jù)挖掘之間的聯(lián)系與區(qū)別
數(shù)據(jù)挖掘是基于數(shù)據(jù)倉庫和多維數(shù)據(jù)庫中的數(shù)據(jù)，找到數(shù)據(jù)的潛在模式進行預測，它可以對數(shù)據(jù)進行復雜處理。大多數(shù)情況下，數(shù)據(jù)挖掘是讓數(shù)據(jù)從數(shù)據(jù)倉庫到數(shù)據(jù)挖掘數(shù)據(jù)庫中。從數(shù)據(jù)倉庫中直接得到進行數(shù)據(jù)挖掘的數(shù)據(jù)有許多優(yōu)點，因為數(shù)據(jù)倉庫中數(shù)據(jù)的清理和數(shù)據(jù)挖掘中幾乎是相同的，如果數(shù)據(jù)在數(shù)據(jù)倉庫中已被清除，數(shù)據(jù)挖掘中不再被清除，并且數(shù)據(jù)不一致也得到了解決。數(shù)據(jù)倉庫是數(shù)據(jù)挖掘的先期步驟，通過數(shù)據(jù)倉庫的構(gòu)建，提高了數(shù)據(jù)挖掘的效率和能力，保證了數(shù)據(jù)挖掘中的數(shù)據(jù)的寬廣性和完整性。
1.3 關系數(shù)據(jù)庫與數(shù)據(jù)挖掘之間的聯(lián)系與區(qū)別
數(shù)據(jù)挖掘的數(shù)據(jù)源不一定是數(shù)據(jù)倉庫。也可以是一個關系數(shù)據(jù)庫中的數(shù)據(jù)，但要事先進行數(shù)據(jù)預處理，才能用于數(shù)據(jù)挖掘。數(shù)據(jù)預處理是數(shù)據(jù)挖掘的關鍵步驟，并且是數(shù)據(jù)挖掘過程中的主要工作部分。因此，數(shù)據(jù)倉庫和數(shù)據(jù)挖掘沒有必然的聯(lián)系，有些人簡單地認為，數(shù)據(jù)倉庫是數(shù)據(jù)挖掘的準備，這種理解是不全面的，也可以使用關系數(shù)據(jù)庫中的數(shù)據(jù)作為數(shù)據(jù)挖掘的數(shù)據(jù)源。
2 三種技術的應用
2.1 應用價值
2.1.1 關系數(shù)據(jù)庫
關系數(shù)據(jù)庫的主要價值體現(xiàn)在事務處理。關系數(shù)據(jù)庫已經(jīng)滲透到各行各業(yè)的日常事務，該事務管理離不開關系數(shù)據(jù)庫的應用系統(tǒng)，這是對傳統(tǒng)事務管理的一個重大突破，是社會甚至家庭不可或缺的工具，它對社會的應用價值是100%。
2.1.2 數(shù)據(jù)倉庫
數(shù)據(jù)倉庫的主要價值體現(xiàn)在為決策分析提供數(shù)據(jù)源。一方面，在一個事務中，用戶要求高效的訪問系統(tǒng)和數(shù)據(jù)庫，操作時間應該短。在一個決策分析中，決策問題的一些請求可能會導致系統(tǒng)的操作，解決這一問題的決策分析需要遍歷大多數(shù)數(shù)據(jù)庫中的數(shù)據(jù)，這對一般日常事務處理系統(tǒng)是困難的，所以操作數(shù)據(jù)和決策分析數(shù)據(jù)應該分開。另一方面，決策數(shù)據(jù)需求問題。在決策分析時，由于不同的應用系統(tǒng)中，實體、字段存在數(shù)據(jù)類型、名稱和格式的不符，需要在集成時進行轉(zhuǎn)換，這個轉(zhuǎn)換必須在決策之前完成；一些決策數(shù)據(jù)需要動態(tài)更新，需要經(jīng)常進行匯總和總結(jié)，這些需求用事務處理系統(tǒng)解決比較繁瑣。三是數(shù)據(jù)的操作模式問題。決策分析人員要以專業(yè)用戶身份，使用各種工具以各種形式來操作數(shù)據(jù)，對數(shù)據(jù)操作的結(jié)果以商業(yè)智能的方式表達出來。事務處理系統(tǒng)不能滿足這一要求，只有數(shù)據(jù)倉庫系統(tǒng)能夠滿足數(shù)據(jù)挖掘技術對數(shù)據(jù)環(huán)境的要求，所以使用數(shù)據(jù)倉庫中的數(shù)據(jù)省去了對數(shù)據(jù)預處理的步驟。
2.1.3 數(shù)據(jù)挖掘
面對日益激烈的市場競爭，客戶對迅速應答各種業(yè)務問題的能力要求越來越高，對過量數(shù)據(jù)的及時處理要求越來越高，帶來的挑戰(zhàn)一方面大規(guī)模、復雜數(shù)據(jù)系統(tǒng)讓用戶感覺漫無頭緒，無法開始；另一方面，這些大量數(shù)據(jù)背后隱藏很多有意義的有價值的決策信息。如計算機界都熟知的“啤酒與尿布”的故事，就是零售業(yè)巨頭“沃爾瑪”從大量銷售數(shù)據(jù)中分析出來的規(guī)律：美國的男士在下班要去超市買嬰兒尿布，同時他們還會買啤酒。“沃爾瑪”就把這兩種“毫不相干”的商品擺放在靠近的貨架上，并且還擺放一些下灑小菜，使這些商品銷量大增。所以應用數(shù)據(jù)挖掘從大量數(shù)據(jù)中發(fā)現(xiàn)規(guī)律，具有具體的指導意義。
2.2 應用領域
2.2.1 關系數(shù)據(jù)庫
關系數(shù)據(jù)庫應用領域非常廣泛，如：證券行業(yè)、醫(yī)院、銀行、銷售部門、公司或企業(yè)，以及政府、國防工業(yè)，科學和技術發(fā)展領域等等，這些領域都需要使用數(shù)據(jù)庫來存儲數(shù)據(jù)。例如：人事管理系統(tǒng)、工資管理系統(tǒng)，xxx部門信息管理系統(tǒng)，手機話費管理系統(tǒng)等，都需要關系數(shù)據(jù)庫作為后臺提供數(shù)據(jù)源。
2.2.2 數(shù)據(jù)倉庫
數(shù)據(jù)倉庫應用領域主要有兩個方面：一是全局應用。因為數(shù)據(jù)倉庫獲得來自多方面的數(shù)據(jù)，所以在把數(shù)據(jù)向數(shù)據(jù)倉庫輸入時，要進行轉(zhuǎn)換、計算和綜合等集成處理。通過處理把來自不同地方的數(shù)據(jù)源轉(zhuǎn)換成統(tǒng)一的格式，以促進全局應用。二是復雜系統(tǒng)。信息處理的要求越來越復雜，除了數(shù)據(jù)處理操作，如添加、刪除、修改、和統(tǒng)計匯總，高級管理層也希望對歷史的和現(xiàn)在的數(shù)據(jù)進行各種復雜性分析，以支持決策。數(shù)據(jù)倉庫中就是存儲了舊的歷史數(shù)據(jù)，方便復雜分析、應用，為高層決策服務。
2.2.3 數(shù)據(jù)挖掘
數(shù)據(jù)挖掘的應用領域主要表現(xiàn)在特定應用問題和應用背景。數(shù)據(jù)挖掘技術已經(jīng)應用于各行各業(yè)，如電信，保險，交通，學校、銀行、超級市場等。例如：數(shù)據(jù)挖掘技術應用在大學。高校擴招，學生增加到幾萬人，但是學生的學習積極性不高，成績不好，因此引入數(shù)據(jù)挖掘技術找出影響學生學習積極性和學習成績的原因，制定措施，提高教育和教學質(zhì)量。分析的數(shù)據(jù)源是考試成績和成績之外的影響因素，分析的方法是采用關聯(lián)規(guī)則、模型庫、去“噪”處理、粗糙集等進行數(shù)據(jù)挖掘，得出的結(jié)論是：傳統(tǒng)的學習方法不能完全滿足需要，改進教學方法和教學模式，從而調(diào)動學生學習的積極性，提高教學質(zhì)量。
3 關系數(shù)據(jù)庫、數(shù)據(jù)倉庫與數(shù)據(jù)挖掘的融合
日常事務處理需要關系數(shù)據(jù)庫，構(gòu)建分析處理環(huán)境需要數(shù)據(jù)倉庫，幫助決策者尋找數(shù)據(jù)之間的潛在的關聯(lián)需要數(shù)據(jù)挖掘。他們之間是相互聯(lián)系又有區(qū)別的，不能互相取代的，又需要相互融合。數(shù)據(jù)倉庫中的數(shù)據(jù)并不是最新的，專有的，而是來源于其他關系數(shù)據(jù)庫，它是建立在一個更全面和完善的信息應用的基礎上，用于支持高層決策分析的數(shù)據(jù)基地。數(shù)據(jù)倉庫是數(shù)據(jù)庫新技術，到目前為止，數(shù)據(jù)倉庫仍用關系數(shù)據(jù)庫管理系統(tǒng)管理數(shù)據(jù)。數(shù)據(jù)挖掘是從大量存儲在數(shù)據(jù)庫、數(shù)據(jù)倉庫或其他信息庫中發(fā)現(xiàn)有趣知識的過程。只有這三個數(shù)據(jù)庫技術互相融合，取長補短，各盡其責，才能更好的為廣大用戶所使用，為社會各個領域所應用。
【參考文獻】
中圖分類號：TP311 文獻標識碼：A 文章編號：1009-2374(2011)07-0088-02
在信息技術與網(wǎng)絡技術高速發(fā)展的今天，網(wǎng)絡已經(jīng)成為新一代操作平臺。信息正全面地以互聯(lián)網(wǎng)方式展開，互聯(lián)網(wǎng)的信息傳播，極大地加速了人類發(fā)展的進程。隨著WEB技術的日益發(fā)展，WEB已經(jīng)成為信息制造、、加工和處理的主要平臺。XML技術已日益受到更為廣泛的關注，已經(jīng)在電子商務、電子數(shù)據(jù)交換、科學數(shù)據(jù)表示、數(shù)據(jù)建模與分析和搜索引擎等領域有著廣泛的應用。隨著XML應用技術的深入，將會有大量的XML文檔出現(xiàn)，并且現(xiàn)在在網(wǎng)絡上已經(jīng)積累了大量的XML文檔。本文主要就基于關系數(shù)據(jù)庫的XML存儲技術相關問題進行探討。
一、XML與關系數(shù)據(jù)庫結(jié)構(gòu)上的差異
XML文檔是半結(jié)構(gòu)化的數(shù)據(jù)，是一個樹模型，如果考慮到XML元素次序，則是一棵有序樹模型，其數(shù)據(jù)結(jié)構(gòu)是非結(jié)構(gòu)化的，而關系數(shù)據(jù)庫管理系統(tǒng)是采用二維表格作為存儲數(shù)據(jù)的模型，表格由行和列組成，列被稱作“字段”用于表示組成數(shù)據(jù)有效信息的屬性，行則用于儲存一條完整的數(shù)據(jù)記錄。XML數(shù)據(jù)與關系表之間數(shù)據(jù)結(jié)構(gòu)有很大的差異，具體來說，XML數(shù)據(jù)是有序的，而關系數(shù)據(jù)則是無序的，另外XML數(shù)據(jù)的模式往往經(jīng)常變化，可是關系數(shù)據(jù)庫的數(shù)據(jù)結(jié)構(gòu)是固定不變的，XML數(shù)據(jù)可以無限層次嵌套，而關系數(shù)據(jù)則不能。雖然XML放松的類型限制和自描述性有利于數(shù)據(jù)之間的交換，但是卻不利于數(shù)據(jù)存儲。因此，XML的數(shù)據(jù)模型的半結(jié)構(gòu)化、有序性與平坦、無序的關系模型之間存在固有的不匹配。另外遵循文檔類型定義(DTD)或文檔模式定義(XML SCHEMA)的XML文檔也與遵循關系存儲模式的關系數(shù)據(jù)在語法、結(jié)構(gòu)以及約束等很多方面存在著固有的異構(gòu)性，因此很難直接由XML數(shù)據(jù)產(chǎn)生關系模式。甚至即使多個XML文檔實例都遵循同一個文檔模式定義，它們也可能有不同的結(jié)構(gòu)。可以看出，XML映射到關系數(shù)據(jù)庫中存在固有的困難。映射時主要存在以下需要解決的問題：(1)如何利用可能有的XML文檔模式(或類型)信息來采取各種不同的存儲策略；(2)如何將XML文檔無損地存入關系數(shù)據(jù)庫；(3)如何從關系數(shù)據(jù)庫中查詢并重構(gòu)XML信息。
二、基于關系數(shù)據(jù)庫的存儲策略
(一) 基于結(jié)構(gòu)映射的策略
具體來說，基于結(jié)構(gòu)的映射方法可以分為兩個步驟來實現(xiàn)：
第一步：簡化DTD并生成DTD圖。因為XML DTD的元素是相當復雜的，需要對復雜的DTD進行簡化。DTD的簡化變換主要有以下三種方式：(1)平面化變換：將DTD內(nèi)的層次嵌套關系打平，把嵌套的定義轉(zhuǎn)換為非嵌套的定義；(2)簡化變換：將連續(xù)的多個一元操作轉(zhuǎn)換為一個一元操作；(3)聚集變換：將多個具有相同名稱的子元素聚在一起，形成一個子元素。一個DTD圖表示的是一個DTD的結(jié)構(gòu)，圖的結(jié)點表示DTD中的元素、屬性或操作符，DTD中的元素在DTD圖中只出現(xiàn)一次，屬性和操作符在DTD圖中出現(xiàn)的次數(shù)則與它們在DTD中出現(xiàn)的次數(shù)相同。
第二步：DTD圖到關系模式的映射。從DTD圖到關系模式的映射方法主要有：基本內(nèi)聯(lián)法、共享內(nèi)聯(lián)法和綜合內(nèi)聯(lián)法。
首先，基本內(nèi)聯(lián)法。基本內(nèi)聯(lián)法的原則是在存儲一個結(jié)點的時候，盡可能多地將這個元素的后代結(jié)點存儲在一個表中。其次，共享內(nèi)聯(lián)法。共享內(nèi)聯(lián)法為以下三種DTD結(jié)點生成獨立的關系：(1)DTD圖中入度大于l或者等于0(根結(jié)點)的元素結(jié)點生成獨立的關系；(2)DTD圖中結(jié)點“幸”的孩子結(jié)點(將值集元素作為單獨的關系保存)；(3)互為遞歸的入度均為1的元素結(jié)點，其中之一生成獨立的關系。而其余的結(jié)點都生成關系屬性。共享內(nèi)聯(lián)法相對減少了XML查詢轉(zhuǎn)換為SOL語句的數(shù)目，但增加了每個SOL查詢中的連接運算。再次，綜合內(nèi)聯(lián)法。綜合內(nèi)聯(lián)方法在處理入度大于1的結(jié)點上與共享內(nèi)聯(lián)方法不同，綜合內(nèi)聯(lián)法將所有入度大于1的元素結(jié)點也內(nèi)聯(lián)進入父結(jié)點所生成的關系表中，但是帶回路的結(jié)點以及結(jié)點“}”或“+”的直接后繼結(jié)點除外，該方法減少了子結(jié)點與父結(jié)點的連接運算。
(二) 基于模型映射的策略
模型映射的方法是用一個固有的模式來存儲XML文檔。它用固定的關系模式來存放任何格式的XML數(shù)據(jù)，而不考慮XML文檔的模式(DTD或SCHEMA)，其實質(zhì)是存儲XML文檔本身的結(jié)構(gòu)信息。
第一，Edge方法。Edge方法圓的存儲策略是把要存入的XML文檔看做圖形結(jié)構(gòu)，每個圖的邊界都表示為圖中的元組，把XML文檔圖中的所有邊都存入到關系表Edge中，用表Edge(source，ordinal，target，label，flag，value)存儲XML文檔圖中的邊，其中的source字段和target字段分別用來存儲邊的源結(jié)點和目標結(jié)點的標識符；label域為目標結(jié)點的類型；flag用來區(qū)分目標結(jié)點；target是一個元素結(jié)點還是一個文本結(jié)點，如果該目標結(jié)點是文本結(jié)點，則文本值存儲于value域中；ordinal字段指出target結(jié)點在source結(jié)點的所有孩子中的位置。由于Edge方法將所有XML數(shù)據(jù)都用Edge表存放，操作方法簡單。但缺點是在Edge方法中每條邊都是單獨管理的，所以在用戶進行查詢操作時就需在大量的表上進行連接操作以形成路徑。如果要判斷祖先/后代關系就需要從祖先到后代(或與之相反)遍歷所有的邊，造成代價非常昂貴。
第二，XRel方法。XRel方法為了存儲XML文檔的所有信息，將XML文檔樹分解為一個個路徑表達式，對于樹中每一個結(jié)點，都將從根結(jié)點到其自身的路徑存儲。而在樹中有可能有多個結(jié)點的路徑是一樣的，所以單個的簡單路徑表達式并不能夠存儲整棵XML文檔樹的信息。XRel模式是通過區(qū)間編碼[start，end]來反映XML文檔的模型結(jié)構(gòu)，并根據(jù)結(jié)點類型來劃分，分為元素結(jié)點表、屬性結(jié)點表和文本結(jié)點表，同時將所有路徑進行存儲。因此，XRel模式由四個關系表組成如圖1所示：
在Path表中，存儲所有的不重復的路徑，其中，PathID為標記路徑的標識，pathexp域存儲標記路徑。為了實現(xiàn)路徑表達式的字符串匹配操作，防止意外的結(jié)果出現(xiàn)，將標記路徑中的“/”替換為“#/”進行存儲。對于Element表、Attribute表和Text表，Attribute表和Text表中的value字段存儲的分別是屬性結(jié)點的值和文本結(jié)點的值。對于每一個路徑表達式，查詢過程都可以分為兩部：第一步，利用字符串的匹配操作，能夠快速的查找出與路徑表達式相匹配的所有標記路徑的標識；第二步，利用這些路徑標識，能夠快速的查找出隸屬于這些路徑終端的值。
XRel存儲模式的特點可以總結(jié)如下：(1)用簡單路徑表達式和結(jié)點的區(qū)間編碼(start，end)存儲XML文檔的所有信息；(2)分別為每一種結(jié)點類型創(chuàng)建一個對應的關系表；(3)用一個Path表把文檔中所有不重復的路徑都提取出來，有效地降低了數(shù)據(jù)庫的存儲容量。
第三，XParent方法。XParent模式和XRel模式一樣，將文本數(shù)據(jù)路徑獨立出來，共包含四個關系表，如圖2所示：
其中，表LabelPath中的pathexp字段用來存儲所有不重復的標簽路徑，即模式路徑。每一個標簽路徑被賦予一個標識符pathlD，length為標記路徑的長度。Parent表存儲的是雙親/孩子關系，pid和cid分別表示一個邊的起始結(jié)點與結(jié)尾結(jié)點。did為XML文檔中元素結(jié)點的標識，它也可以作為以該結(jié)點為終端點的數(shù)據(jù)路徑的標識。
中圖分類號：TP311 文獻標識碼：A 文章編號：1009-3044（2016）26-0008-02
1 引言
關系數(shù)據(jù)庫是當今應用最廣泛的數(shù)據(jù)庫系統(tǒng)。關系數(shù)據(jù)庫支持關系數(shù)據(jù)模型。關系數(shù)據(jù)結(jié)構(gòu)非常單一，現(xiàn)實世界中的實體及實體之間的聯(lián)系都是用關系來表示，在用戶看來，關系數(shù)據(jù)結(jié)構(gòu)就是二維表。常用的關系操作包括查詢操作和插入、刪除、修改操作兩大部分，其中查詢操作的表達能力最重要。數(shù)據(jù)查詢是數(shù)據(jù)庫應用中非常重要的組成部分，數(shù)據(jù)查詢是否具備較高的執(zhí)行效率和反應速度受到數(shù)據(jù)庫設計者和用戶的極大關注。
2 不同查詢方案代價對比
關系模型中的查詢語言早期通常是用代數(shù)方法或邏輯方法來表示，分別稱為關系代數(shù)和關系演算，隨后出現(xiàn)一種介于關系代數(shù)和關系演算的語言稱為結(jié)構(gòu)化查詢語言，簡稱SQL。SQL語言作為關系數(shù)據(jù)庫的標準語言向用戶提供了易于掌握、高度非過程化得查詢語言。大多數(shù)商用數(shù)據(jù)庫都支持SQL語言，用戶只需指明“干什么？”不需指出“怎么干。”對同一個查詢要求有不同的查詢解決方案，查詢優(yōu)化就是盡量在不同的解決方案中找到效率高、代價小的方案。
為了提升數(shù)據(jù)庫系統(tǒng)性能對數(shù)據(jù)查詢進行優(yōu)化成了必須解決的問題，查詢優(yōu)化技術的發(fā)展與應用，也助推了數(shù)據(jù)庫技術的推廣與普及。
下面我們通過一個實例對比不同查詢方案所花費的代價。
商品銷售管理數(shù)據(jù)庫
銷售點信息表（銷售點編號，城市、地址，聯(lián)系電話，開設時間）
產(chǎn)品信息表（產(chǎn)品編號，產(chǎn)品名，類型，規(guī)格，生產(chǎn)廠家，進貨價格）
銷售情況表（銷售點編號，產(chǎn)品編號，銷售量，銷售單價）
求銷售產(chǎn)品編號為’JD051’這種產(chǎn)品的銷售點信息？
用SQL語言表達該查詢：
Select 銷售點信息表.*
From 銷售點信息表 ， 銷售情況表
Where 銷售點信息表.銷售點編號=銷售情況表.銷售點編號 and 產(chǎn)品編號=’JD051’
SQL語言是高度的非過程化語言，同一個查詢要求可以有不同的執(zhí)行方式。下面針對上述查詢要求運用關系代數(shù)表達式來表示不同的執(zhí)行方式。
方案1
Π銷售點信息表.*（σ銷售點信息表.銷售點編號=銷售情況表.銷售點編號∧銷售情況表.產(chǎn)品編號=’JD051’（銷售點信息表×銷售情況表））
第一種方式需要占用內(nèi)存空間保留廣義笛卡爾積的中間結(jié)果，讀取數(shù)據(jù)量過多及耗時較長；
方案2
Π銷售點信息表.*（σ產(chǎn)品編號=’JD051’（銷售點信息表∞銷售情況表））
第二種方案相比第一種方式減少了中間結(jié)果，使用自然連接相比笛卡爾積大大減少了中間結(jié)果；
方案3
Π銷售點編號（σ產(chǎn)品編號=’JD051’ （銷售情況表））∞銷售點信息表
第三種方式減少了數(shù)據(jù)讀取量，中間結(jié)果相比第二種情況更少。總的查詢時間最短、查詢代價最少。
以上三種表達式雖然等價，但其執(zhí)行的查詢策略不同，數(shù)據(jù)規(guī)模越大，查詢所花費的代價差別就越大。通過三種不同查詢方式的對比，說明查詢優(yōu)化的必要性，選擇合適的查詢策略將大大減少查詢時間、降低查詢代價，因此查詢優(yōu)化問題一直是數(shù)據(jù)庫研究的重點。
3 關系數(shù)據(jù)庫查詢處理過程
當用戶發(fā)出查詢請求，要采用不同的處理步驟對原始查詢進行轉(zhuǎn)換，這些轉(zhuǎn)換工作必須在系統(tǒng)處理查詢請求和返回查詢結(jié)果前完成。關系數(shù)據(jù)庫查詢處理過程如圖1所示。
圖1
主要步驟：語法分析與翻譯處理，查詢優(yōu)化處理，執(zhí)行。
4 查詢優(yōu)化技術分類
查詢優(yōu)化技術一般分為代數(shù)優(yōu)化和非代數(shù)優(yōu)化（物理結(jié)構(gòu)優(yōu)化）。
1）代數(shù)優(yōu)化，通過對查詢語句進行變換，改變基本操作的次序，使查詢語句執(zhí)行起來更有效，這種查詢優(yōu)化僅涉及查詢語句本身，而不涉及實際存取路徑，稱為獨立于存取路徑的優(yōu)化，或代數(shù)優(yōu)化。
查詢是由高級查詢語言表示的對數(shù)據(jù)庫的一個或一組操作的集合，通常由投影、選擇、連接、笛卡爾積等操作符組成。通過語法分析功能分析查詢語句的正確性、完整性、有效性，并將其轉(zhuǎn)換為等價關系代數(shù)查詢樹，如圖2。
根據(jù)關系代數(shù)等價變換規(guī)則，查詢樹可以按以下方法進行變換：
方法1：下移選擇和投影運算，以減少中間結(jié)果的元組數(shù)和參與運算的關系的規(guī)模；
方法2：將某些選擇運算與笛卡爾積運算相結(jié)合；
方法3：同時執(zhí)行同一個關系上的選擇、投影運算，減少對關系的掃描次數(shù)；
方法4：將連接運算與投影運算結(jié)合起來執(zhí)行。
圖2可變換為圖3。
對比圖2和圖3選擇運算和投影運算優(yōu)先執(zhí)行，減少了查詢中間結(jié)果的元組數(shù)，大大降低了參與連接運算的關系規(guī)模。
在制定具體的查詢策略時應盡量減少對數(shù)據(jù)表的訪問，減少對磁盤的訪問次數(shù)，訪問磁盤所需的時間大大長于對內(nèi)存的訪問時間，減少對磁盤的訪問次數(shù)將大大降低系統(tǒng)的響應時間。選擇運算盡可能提前做，往往可以使執(zhí)行時間降低幾個數(shù)量級，通過選擇運算減少中間結(jié)果。在執(zhí)行連接操作前，對關系進行適當?shù)念A處理，在連接的字段上建立索引以及對關系進行排序，加快查詢速度。
關系代數(shù)優(yōu)化的一般步驟：[3]
（a）把查詢轉(zhuǎn)換成語法樹；（b）優(yōu)化語法樹；（c）選擇低層次的存取路徑；（d）選擇代價較小的查詢方案。
2）非代數(shù)優(yōu)化，也稱物理結(jié)構(gòu)優(yōu)化。數(shù)據(jù)庫物理結(jié)構(gòu)是整個數(shù)據(jù)庫存儲的基礎，物理結(jié)構(gòu)設計是在邏輯結(jié)構(gòu)設計的基礎上完成的，應確保數(shù)據(jù)庫存儲和訪問或操作數(shù)據(jù)表具有較高的執(zhí)行效率。物理結(jié)構(gòu)優(yōu)化是指為數(shù)據(jù)庫系統(tǒng)的數(shù)據(jù)推薦合適的物理存儲位置或存儲結(jié)構(gòu)，以及為查詢推薦合適的存取路徑，進而提升系統(tǒng)的整體性能。
5 小結(jié)
查詢優(yōu)化技術是數(shù)據(jù)庫中一項重要的技術。對于的查詢要求，我們應該根據(jù)數(shù)據(jù)規(guī)模大小，具體的物理存儲結(jié)構(gòu)等因素進行分析，選擇合適的查詢策略。具體的SQL查詢語句應根據(jù)代數(shù)優(yōu)化的相關原則進行變換，提高查詢效率。查詢優(yōu)化目的是為了提升系統(tǒng)的性能，如果進行優(yōu)化本身需要花費的代價過大，反而會降低系統(tǒng)的性能。所以只有兼顧了查詢效率、控制系統(tǒng)開銷、保障數(shù)據(jù)庫安全等諸多方面才能真正地優(yōu)化系統(tǒng)的性能。
參考文獻：
[1] 馮衛(wèi)兵.關系數(shù)據(jù)庫的查詢優(yōu)化[J].現(xiàn)代計算機，2010（1）.
[2] 王能斌.數(shù)據(jù)庫系統(tǒng)原理[M].北京：電子工業(yè)出版社，2001.
[3] 薩師煊，王珊. 數(shù)據(jù)庫系統(tǒng)概論[M].3版.北京：高等教育出版社，2000.
[4] 谷震離.關系數(shù)據(jù)庫查詢方法研究[J].微計算機信息，2006.
中圖分類號:TP399文獻標識碼:A文章編號:1009-3044(2009)25-7090-03
Comparison and Analysis for Relational Database and Cloud Database Based on Architecture
ZHANG Zhen-yong, WEN Jing-hua
(Guizhou College of Finance and Economics, Guiyang 550004,China)
Abstract: Aiming at the shortcoming that relational database processes a large number of video,audio,images and complex data types, this thesis compared and analyzed relational database and Bigtable representing cloud database and based on architecture. The results showed that cloud database was more advantageous than relational database in precessing a great mass of data and complex data types. With the development of the cloud database technology,cloud database will be superseding the relational database as the mainstream of the database.
Key words: ralational database; cloud database; bigtable; timestamp
關系數(shù)據(jù)庫從1970年發(fā)展至今,雖功能日趨完善,但對數(shù)據(jù)類型的處理大多采用數(shù)字、字符等基本數(shù)據(jù)類型,對多媒體信息的處理只是停留在簡單的二進制代碼文件的存儲。隨著信息技術的發(fā)展,互聯(lián)網(wǎng)上數(shù)據(jù)量高速增長,非結(jié)構(gòu)化數(shù)據(jù)的應用日趨擴大,再加上用戶應用需求的提高、硬件技術的發(fā)展和Web2.0提供的多彩的多媒體交流方式,用戶對多媒體處理的要求從簡單的存儲上升為識別、檢索和深入加工等高級應用。關系數(shù)據(jù)庫在處理這類數(shù)據(jù)時,逐漸暴露出了一些缺陷。
如何來高效處理占數(shù)據(jù)總量70%的聲音、圖像和視頻等復雜數(shù)據(jù)類型是目前互聯(lián)網(wǎng)界亟待解決的問題。正是在這種狀態(tài)下,云端數(shù)據(jù)庫便應運而生并開始發(fā)展起來。目前云端數(shù)據(jù)庫技術在云計算中的應用有Google的Bigtable系統(tǒng)[1]、Amazon公司的Dynamo系統(tǒng)、Hadoop的一個子項目Hbase、微軟的Live Mesh系統(tǒng)等等。無論是Bigtable還是Hbase都是采用通用的云端數(shù)據(jù)庫架構(gòu),只是核心技術不同。所以本文就以Google的Bigtable架構(gòu)為代表與傳統(tǒng)的關系數(shù)據(jù)庫架構(gòu)進行比較和分析。
1關系數(shù)據(jù)庫
1.1關系數(shù)據(jù)庫概念及特點
關系數(shù)據(jù)庫在一個給定的應用領域中,所有實體及實體之間聯(lián)系的關系的集合。它是建立在集合代數(shù)基礎上,應用數(shù)學方法來處理數(shù)據(jù)庫中的數(shù)據(jù),現(xiàn)實世界中的各種實體以及實體之間的各種聯(lián)系均用關系模型來表示,也就是說關系數(shù)據(jù)庫是建立在關系模型基礎上的數(shù)據(jù)庫[2]。
關系數(shù)據(jù)庫具有數(shù)據(jù)結(jié)構(gòu)化、最低冗余度、較高的程序與數(shù)據(jù)獨立性、易于擴充、易于編制應用程序等優(yōu)點,目前較大的應用軟件系統(tǒng)都是建立在結(jié)構(gòu)化數(shù)據(jù)庫設計之上的。
1.2關系數(shù)據(jù)庫系統(tǒng)的架構(gòu)
關系數(shù)據(jù)庫的架構(gòu)包括六個部分[3]:
1) 查詢語言接口
查詢語言接口通過使用SQL語言對數(shù)據(jù)庫進行特設查詢數(shù)據(jù)。
2)交互式查詢工具
交互式查詢工具是用于訪問,修改以及更新一個或多個關聯(lián)的數(shù)據(jù)表,并以視圖的方式返回給用戶。
3) 核心軟件
該核心軟件用于控制查詢處理,存取數(shù)據(jù)路徑,用戶訪問管理,存儲管理,索引,交易處理和讀取/更新信息。
4) 公用機制
公用機制主要用于輸入/輸出/備份調(diào)整工具及參數(shù)/報告撰寫。
5) 存儲機制
存儲機制主要進行數(shù)據(jù)庫寫入,歸檔,用戶管理器,服務器管理,重做日志文件。
6) 數(shù)據(jù)庫
數(shù)據(jù)庫的特點是以數(shù)據(jù)文件的方式對數(shù)據(jù)對象進行物理存儲,包含了系統(tǒng)目錄即數(shù)據(jù)目錄,一個或多個數(shù)據(jù)文件以結(jié)構(gòu)化形式存儲組成集合即二維表,并將不同數(shù)據(jù)集通過主鍵和外鍵進行關聯(lián)。
關系數(shù)據(jù)庫的架構(gòu)如圖1所示。
1.3關系數(shù)據(jù)庫的缺陷
通過對關系數(shù)據(jù)庫架構(gòu)的分析,可以發(fā)現(xiàn)關系數(shù)據(jù)庫的一些不足,概括如下四點:
1) 數(shù)據(jù)類型表達能力差
因為關系數(shù)據(jù)庫所處理的是結(jié)構(gòu)化的數(shù)據(jù),所以關系數(shù)據(jù)庫缺乏直接構(gòu)造與現(xiàn)代軟件應用有關的信息的類型表達能力。隨著信息技術的飛速發(fā)展,圖像、視頻、音頻以及文檔等非結(jié)構(gòu)化的數(shù)據(jù)已被應用到人們的日常生活當中,利用關系數(shù)據(jù)庫來處理這些非結(jié)構(gòu)化的數(shù)據(jù)已經(jīng)顯得有點力不從心了。因此目前大多數(shù)RDBMS產(chǎn)品所采用的簡單類型在重構(gòu)復雜數(shù)據(jù)的過程中將會出現(xiàn)性能問題;數(shù)據(jù)庫設計過程中的額外復雜性;RDBMS產(chǎn)品和編程語言在數(shù)據(jù)類型方面的不協(xié)調(diào),需要通過較復雜的程序化進行數(shù)據(jù)類型之間的轉(zhuǎn)換來達到數(shù)據(jù)類型的一致性。
對于工程應用來說,關系數(shù)據(jù)庫不能支持復雜數(shù)據(jù)類型的典型結(jié)果就是需要額外地分解數(shù)據(jù)結(jié)構(gòu)工作,這些被分解的結(jié)構(gòu)不能直接表示應用數(shù)據(jù),且從基本成分重構(gòu)時也非常繁瑣和費時間。
2) 復雜查詢功能比較差
在關系數(shù)據(jù)庫中,利用SQL語言進行查詢數(shù)據(jù)。雖然SQL語言為數(shù)據(jù)查詢提供了很好的定義方法,但是當用于復雜信息的查詢時可能會非常繁瑣。這是由于在工程應用時規(guī)范化的過程通常會產(chǎn)生大量的簡單表,從而降低數(shù)據(jù)的冗余度。那么在這種環(huán)境下由存取信息產(chǎn)生的查詢必須處理大量的表和復雜主鍵和外鍵之間的聯(lián)系以及連接運算,會影響系統(tǒng)的查詢效率。
3) 支持長事務能力差
由于RDBMS記錄鎖機制的顆粒度限制,對于支持多種記錄類型的大段數(shù)據(jù)的登記和檢查來說,簡單的記錄級的鎖機制是不夠的,但基于鍵值關系的較復雜的鎖機制來說卻很難推廣也難以實現(xiàn)。
4) 環(huán)境應變能力差
在要求系統(tǒng)改變的環(huán)境下,關系數(shù)據(jù)庫從一種系統(tǒng)移植到另一個系統(tǒng)上的成本高且修改困難。再加上,關系數(shù)據(jù)庫和編程語言所提供的數(shù)據(jù)類型的不一致,使得從一個環(huán)境轉(zhuǎn)換到另一個環(huán)境時需要多至30%的附加代碼。
正是由于關系數(shù)據(jù)庫的這些缺陷,才推動了數(shù)據(jù)庫技術的發(fā)展,產(chǎn)生了云端數(shù)據(jù)庫技術,進而彌補了關系數(shù)據(jù)庫的不足。
2 云端數(shù)據(jù)庫
2.1 Bigtable的介紹
Google在 2004 年初就開始研發(fā)了BigTable,到了2005年大概有100個左右的服務使用BigTable。BigTable 讓Google在提供新服務時的運行成本降低,最大限度地利用了計算能力。
Bigtable是一個大型,容錯,自我管理的分布式存儲系統(tǒng),并用于管理分布在成千上萬臺服務器上的結(jié)構(gòu)化數(shù)據(jù)[4]。它是建立在GFS分布式文件系統(tǒng)[5]、Scheduler分布式集群調(diào)度、Lock Service分布式的鎖服務[6]和 MapReduce編程模式[7]基礎之上的系統(tǒng)。
2.2 Bigtable的架構(gòu)
1) Bigtable的數(shù)據(jù)模型
一個Bigtable(大表)是一個稀疏的,分布的,持續(xù)的以及多維的排序的數(shù)據(jù)映射。這個映射由行主鍵,列主鍵和時間戳進行索引[4]。每一項值在映射中是一系列不被解釋的字節(jié)元組即(row:string,column:string,timestamp:int64)string。
在Bigtable的數(shù)據(jù)模型中,所有的數(shù)據(jù)都存放在表格單元中,每一行表示一個事物的數(shù)據(jù)內(nèi)容,其所在列表示這個事物的唯一標志,其所對應的時間戳表示這個事物在某個時間上的狀態(tài)即具體的數(shù)據(jù)內(nèi)容。關系數(shù)據(jù)庫只能反映當前時間上事物所處的狀態(tài),而Bigtable不僅能顯示事物當前所處的狀態(tài),而且還可以記錄某個事物的過去某個時間所處狀態(tài)。Bigtable的數(shù)據(jù)模型如圖2所示。
2) Bigtable的架構(gòu)
與目前的關系數(shù)據(jù)庫類似,BigTable也是客戶端和服務器端的聯(lián)合設計,使得性能能夠最大程度地符合應用的需求。
BigTable系統(tǒng)依賴于集群系統(tǒng)的底層結(jié)構(gòu),一個是 Google的分布式文件系統(tǒng)(GFS),一個是分布式的集群任務調(diào)度(scheduler),還有一個分布式的鎖服務(Lock Service)。BigTable使用Lock Service來保存根數(shù)據(jù)表格的指針,即客戶端用戶可以首先從Lock Service鎖服務器中獲得根表的位置,進而對數(shù)據(jù)進行訪問。BigTable使用一臺服務器作為主服務器,用來保存和操作元數(shù)據(jù)。主服務器除了管理元數(shù)據(jù)之外,還負責對tablet服務器(即一般意義上的數(shù)據(jù)服務器)進行遠程管理與負載調(diào)配。客戶端通過編程接口與主服務器進行元數(shù)據(jù)通信,與tablet服務器進行數(shù)據(jù)通信[8]。
Bigtable的架構(gòu)由Bigtable master、Bigtable tablet servers和Bigtable client library三部分組成,如圖3所示。
Bigtable master存儲了許多由大量的tablets組成的表。主要負責指派tablet到tablet的各個服務器上,并檢測tablet服務器的增減和服務程序裝載滿與否,進行實時的分配任務,使tablet服務器負載均衡并回收GFS文件系統(tǒng)中的垃圾文件。此外,它還處理模式更改,如表和列簇的創(chuàng)建。
每一個tablet服務器用于管理一部分tablets,通常有10-1000個tablet和處理客戶端用戶的讀/寫請求。tablet是由大表以行為單位分隔而成的。每個tablet保存了連續(xù)的行,然后別分配到各個tablet服務器上。
Bigtable client library是客戶端用戶和Bigtable服務器通信的接口。用戶通過Bigtable client library接口來讀數(shù)據(jù)和寫數(shù)據(jù)等操作。
3 關系數(shù)據(jù)庫與云端數(shù)據(jù)庫的比較
3.1 兩者架構(gòu)的區(qū)別
關系數(shù)據(jù)庫架構(gòu)與云端數(shù)據(jù)庫中的Bigtable架構(gòu)主要區(qū)別如表1所示。
3.2 基于架構(gòu)的比較分析
通過對關系數(shù)據(jù)庫架構(gòu)和云端數(shù)據(jù)庫中的Bigtable架構(gòu)的分析,可以從以下幾個方面對兩者進行比較:
1) 數(shù)據(jù)模型
在關系數(shù)據(jù)庫中創(chuàng)建的表是一張二維表包括行和列,使用簡單的數(shù)據(jù)類型對結(jié)構(gòu)化的數(shù)據(jù)進行存儲。但對于非結(jié)構(gòu)化的數(shù)據(jù)的存儲,因為關系數(shù)據(jù)庫要保持數(shù)據(jù)冗余度低這一優(yōu)點,所以關系數(shù)據(jù)庫的設計會比較復雜且困難。而Bigtable創(chuàng)建的類似于二維表,但事實上不是二維表,它是由行主鍵、列主鍵、時間戳三個域組成的多維map。雖然Bigtable存儲數(shù)據(jù)的冗余度比較高,但是Bigtable比關系數(shù)據(jù)庫的二維表多了一個域――時間戳域,時間戳域可以記錄事物的不同時間時的狀態(tài)。另外Bigtable是以一條記錄為原子對數(shù)據(jù)進行操作的,所以Bigtable不僅可以對事物的當前狀態(tài)進行更新,還可以對事物的過去狀態(tài)進行查詢。在這一點上,關系數(shù)據(jù)庫是不支持歷史查詢的。
2) 數(shù)據(jù)的存取方式
在關系數(shù)據(jù)庫中用戶對數(shù)據(jù)進行查詢、添加、修改及刪除等的操作是使用SQL語言。對于處理海量及復雜數(shù)據(jù)時,使用SQL語言對多個關聯(lián)表進行操作就可能會顯得非常繁瑣。Bigtable并非支持SQL語言的數(shù)據(jù)庫,而是以map 函數(shù)方式的,以列導向的數(shù)據(jù)庫。Bigtable對數(shù)據(jù)的存取是以一行記錄為原子進行的,不必關聯(lián)其他的表,那么數(shù)據(jù)存取的速率要比關系數(shù)據(jù)庫要高。
3) 數(shù)據(jù)遷移能力
關系數(shù)據(jù)庫提供了一些簡單的數(shù)據(jù)類型,在環(huán)境發(fā)生變化比如應用平臺或者是編程語言所提供的數(shù)據(jù)類型與關系數(shù)據(jù)庫所提供的不一致時,那么數(shù)據(jù)之間的轉(zhuǎn)化過程將會相當復雜而且還會增加成本。而Bigtable所提供的數(shù)據(jù)類型只有字符串類型,所有數(shù)據(jù)都是以字符串的形式進行處理,因此Bigtable在進行數(shù)據(jù)遷移時相比關系數(shù)據(jù)庫要容易并且成本也要比關系數(shù)據(jù)庫要低得多。
4) 支持事務
關系數(shù)據(jù)庫為了保持數(shù)據(jù)的完整性和一致性,提供了事務處理功能。關系數(shù)據(jù)庫在處理簡單事務方面,顯現(xiàn)出了關系數(shù)據(jù)庫的優(yōu)勢。但是在處理繁瑣的事務方面,比如執(zhí)行了n條SQL語句來對多個關聯(lián)的數(shù)據(jù)表進行處理,執(zhí)行效率就會顯得比較低。目前,Bigtable還不支持事務處理功能,但是Google已經(jīng)考慮到了該功能,一旦Bigtable支持了多行數(shù)據(jù)的事務支持,執(zhí)行效率將會大大提高。
總之,云端數(shù)據(jù)庫在處理非結(jié)構(gòu)化數(shù)據(jù)時要比關系數(shù)據(jù)庫的效率高,更適宜在多節(jié)點的服務器集群上工作,比關系數(shù)據(jù)庫更適應環(huán)境的變化,最大的優(yōu)點是使用成本比關系數(shù)據(jù)庫要低得多。
4 結(jié)束語
本文通過對關系數(shù)據(jù)庫架構(gòu)和云端數(shù)據(jù)庫架構(gòu)的比較分析,可以得出云端數(shù)據(jù)庫在許多方面要比關系數(shù)據(jù)庫占優(yōu)勢,也就是說云端數(shù)據(jù)庫技術具有很大的發(fā)展前景。雖然云端數(shù)據(jù)庫技術還不夠成熟,再加上各大關系數(shù)據(jù)庫供應商對關系數(shù)據(jù)庫技術的不斷改進以及對查詢算法進行優(yōu)化,但是隨著云端數(shù)據(jù)庫技術的不斷成熟,將會得到廣泛的應用,進而逐步會取代關系數(shù)據(jù)庫成為數(shù)據(jù)庫中的主流。
參考文獻:
[1] Chang F,Dean J,Ghemawat S,Hsieh WC,Wallach DA,Burrows M,Chandra T,Fikes A,Gruber RE.Bigtable:A distributed storage system for structured data.In:Proc.of the 7th USENIX Symp.on Operating Systems Design and Implementation.Berkeley:USENIX Association,2006:205-218.
[2] 瞿裕忠 胡偉 鄭東棟 仲新宇. 關系數(shù)據(jù)庫模式和本體間映射的研究綜述[J].計算機研究與發(fā)展,2008,45(2):300-309.
[3] Fay Chang,Jeffrey Dean,Sanjay Ghemawat,Wilson C.Hsieh,Deborah A.Wallach Mike Burrows, Tushar Chandra, Andrew Fikes,Robert E.Gruber.Bigtable: A Distributed Storage System for Structured Data,OSDI,2006:1-5.
[4] Ghemawat S,Gobioff H,Leung ST.The Google file system.In:Proc.of the 19th ACM Symp.on Operating Systems Principles.New York:ACM Press,2003.29-43.
中圖分類號：TP311文獻標識碼：A 文章編號：1009-3044(2008)16-21188-02
On Optimization Method for Query in Relational Database
YIN Mei-gui
(Heyuan Polytechnic, Heyuan 517000, China)
Abstract: In the database application MIS, query process is the most frequent. Whether query process is good or bad will directly affect the performance of database application system. Therefore, query in database should be optimized. This article suggests some methods of how to realize the optimization by making use of the technology of query in relational database.
Key words: RDBMS; query optimization; methods
1 引言
數(shù)據(jù)庫系統(tǒng)是管理信息系統(tǒng)的核心，基于數(shù)據(jù)庫的聯(lián)機事務處理（OLTP）以及聯(lián)機分析處理（OLAP）是企業(yè)、銀行、政府部分最為重要的計算機應用之一。從大多數(shù)數(shù)據(jù)庫系統(tǒng)的應用實例來看，查詢操作是所有數(shù)據(jù)庫操作中所占據(jù)比重最大的操作。當數(shù)據(jù)庫系統(tǒng)積累到一定程度（如稅務系統(tǒng)的賬戶達到上百萬甚至上千萬條記錄），全表掃描一次往往需要數(shù)十分鐘，甚至數(shù)小時。如果采用比全表掃描更好的查詢策略，往往能降低查詢時間。如何設計數(shù)據(jù)庫，采取什么樣的查詢方法，提高查詢效率，這就是查詢優(yōu)化要解決的問題。
2 合理使用索引
索引是數(shù)據(jù)庫一個常用的數(shù)據(jù)庫對象，優(yōu)化查詢的重要方法是建立索引，也是數(shù)據(jù)庫同時預先將數(shù)據(jù)分類導入到多表格的方式。在關系數(shù)據(jù)庫的表上建立合適的索引，可以提高數(shù)據(jù)庫數(shù)據(jù)查詢的速度，改善數(shù)據(jù)庫的性能。除了集簇索引，每一索引的使用都以磁盤容量作為代價，當使用一個索引，數(shù)據(jù)庫引擎必須執(zhí)行兩個數(shù)據(jù)讀取，這兩個數(shù)據(jù)讀取是數(shù)據(jù)庫記錄所必需的，第一個數(shù)據(jù)被讀取到實際數(shù)據(jù)指針的索引，第二個數(shù)據(jù)被讀入到指針指定的位置。因此創(chuàng)建索引時必須要與實際應用系統(tǒng)的查詢需求密切結(jié)合，才能達到優(yōu)化查詢的目的。
2.1 建索引的必要性
判斷索引必要性的最終標準是判斷這些索引是否對數(shù)據(jù)庫的工作效率有所幫助。在實際的應用過程中，應該為優(yōu)化工作做以下幾點準備：
首先觀察數(shù)據(jù)庫應用程序中所有的SQL語句，并從中統(tǒng)計出常用且可能對性能有影響的部分語句，然后分析、歸納出作為Where條件子句的字段及其各種組合方式；在這一基礎上可以初步判斷出哪些表的哪些字段應該建立索引。其次，必須了解應用程序，要了解哪些表是數(shù)據(jù)操作頻繁的表；哪些表經(jīng)常與其他表進行連接；哪些表中的數(shù)據(jù)量可能很大；數(shù)據(jù)量大的表中各個字段的數(shù)據(jù)分布情況如何等等。對于滿足上述條件的這些表，必須重點關注。因為建立在這些表上的索引，將對SQL語句的性能產(chǎn)生舉足輕重的影響。
2.2 使用索引的規(guī)則
索引的使用要恰到好處，其使用原則如下：
（1）在經(jīng)常進行連接，但是沒有指定為外鍵的列上建立索引，而不經(jīng)常連接的字段則由優(yōu)化器自動生成索引。
（2）在主鍵索引方面，不應有超過25%列成為主鍵，而普通列很少，這會浪費索引空間。
（3）在條件表達式中經(jīng)常用到的不同值較多的列上建立檢索，在不同值少的列上不要建立索引。
（4）在頻繁進行排序或分組（即進行group by 或 order by 操作）的屬性上建立索引。
（5）在作為最小值等聚集函數(shù)的屬性上考慮建立索引。
索引的建立、維護和使用都需要付出代價，應合理使用索引。錯誤的索引不會使數(shù)據(jù)庫性能得到預期的提高，往往還會產(chǎn)生一些負面影響。
3 SQL語句優(yōu)化
要對查詢進行優(yōu)化，一個簡單直接有效的方法是對SQL語句進行調(diào)整，減少計算量，提高查詢的效率。以下是一些書寫SQL的一些經(jīng)驗。
3.1 避免相關子查詢
查詢嵌套層數(shù)每增加一層，查詢的效率成幾何級的降低。要想提高嵌套語句的執(zhí)行效率，則應減少嵌套語句的嵌套的層次。所以在實際應用中，若可以用連接查詢代替的子查詢，則用連接查詢實現(xiàn)。
例：查詢選修了“3-105”號課程的學生基本信息
用子查詢的方法如下所示：
SELECT * FROM student WHERE SNO IN (SELECT sno FROM sc WHERE cno=’3-105’)
改寫成連接查詢?nèi)缦拢?/p>
SELECT student.* FROM student,sc WHERE stuent.sno=sc.sno AND cno=’3-105’
3.2 用UNION替換OR
合理建立索引有助于提高查詢效率。有時盡管在所有的檢索列上都有索引，但有些形式SELECT查詢語句可能不會促使查詢優(yōu)化器使用索引，從而降低查詢效率。如果對查詢語句進行改寫，用UNION替換OR，可以強迫優(yōu)化器按索引路徑處理。如：假定分別在“職工”關系中的“年齡”和“月工資”字段上創(chuàng)建了索引，對以下SQL語句
SELECT 姓名，年齡，月工資 FROM 職工 WHERE 年齡>45 OR 月工資
可替換為：
SELECT 姓名，年齡，月工資 FROM 職工 WHERE 年齡>45
UNION
SELECT 姓名，年齡，月工資 FROM 職工 WHERE月工資
3.3 使用臨時表優(yōu)化查詢
在涉及相關查詢的某些情形中，構(gòu)造臨時關系可以提高查詢效率。如：查詢每個部門中月工資最高的“職工號”
SELECT 職工號 FROM 職工 AS e1 WHERE 月工資=(SELECT MAX(月工資)FROM 職工 AS e2 WHERE e1.部門號=e2.部門號)
以上的查詢對于外層的職工關系e1中的每一個元組，都要對內(nèi)層的整個職工關系e2進行檢索，因此查詢效率不高。可以構(gòu)建臨時關系提高查詢效率。
SELECT MAX（月工資） AS 最高工資，部門號 INTO temp FROM職工 GROUP BY 部門號
SELECT 職工號 FROM 職工，temp WHERE 月工資=最高工資 AND 職工.部門號=temp.部門號
3.4 避免在索引列上使用計算
WHERE子句中，如果索引列是函數(shù)的一部分。優(yōu)化器不使用索引而使用全表掃描。如
SELECT * FROM職工 WHERE 月工資*12>20000
可改為：
SELECT * FROM 職工 WHERE 月工資>20000/12
3.5 謂詞的等價變換
由于執(zhí)行引擎對各種謂詞的處理方法不同，把邏輯表達式重寫成等價的且效率較高的表達式是提高效率的有效方法，同時也是切實可行的。針對執(zhí)行引擎對各種謂詞執(zhí)行效率的不同，總結(jié)如下謂詞轉(zhuǎn)換規(guī)則：
1）將BETWEEN轉(zhuǎn)化為AND 連接的謂詞
把BETWEEN．．．AND．．．形式改寫為用AND連接的兩個謂詞，效率往往
有一定的提高。
例如：月工資 BETWEEN 1000 AND 2000 改為： 月工資>=1000 AND 月工資
2）避免使用In語句
當查詢語句中有In關鍵詞時，優(yōu)化器采用OR并列條件。
如：職工號IN (‘1001’,’2001’) 改為：職工號=’1001’ OR 職工號=’2001’
4 結(jié)束語
查詢處理是數(shù)據(jù)管理系統(tǒng)的核心，而查詢優(yōu)化技術是查詢處理的關鍵技術。查詢優(yōu)化就要抓住關鍵問題。在數(shù)據(jù)庫的開發(fā)和維護過程中，查詢優(yōu)化設計可以提高系統(tǒng)的性能，尤其對于數(shù)據(jù)量大的數(shù)據(jù)庫系統(tǒng)最為重要。本文提到一些優(yōu)化方法是根據(jù)自己的經(jīng)驗，并查閱了大量的資料。在具體的使用時候要根據(jù)實際情況，才能合理制定出良好的優(yōu)化方法，實現(xiàn)快速、高效的數(shù)據(jù)查詢。
參考文獻：
一、關系數(shù)據(jù)庫關鍵詞查詢概述
關系數(shù)據(jù)庫通常通過結(jié)構(gòu)化查詢語言SQL來訪問。SQL訪問方式不但要求用戶知道并理解關系數(shù)據(jù)庫模式,也要懂得書寫復雜的SQL查詢語言,因此,它一般適合于專業(yè)用戶使用。普通用戶一般通過定制的關系數(shù)據(jù)庫查詢接口程序RQI(Relational databases Query Interface)或者關系數(shù)據(jù)庫應用程序RAP(Relational databases Application Program)來訪問關系數(shù)據(jù)庫。RQI訪問方式雖然不要求用戶書寫復雜SQL查詢語言,但是要求用戶知道并理解關系數(shù)據(jù)庫模式,對于不同的關系數(shù)據(jù)庫需要使用不同的RQI,而且定制的RQI也往往不能滿足靈活多變的用戶查詢需求,當RQI不能滿足用戶查詢需求時,就需要應用開發(fā)人員來修改RQI,由此,使用RQI訪問方式則需要較高的開發(fā)費用和維護費用。
隨著Internet和Web技術的快速發(fā)展和應用,一方面用戶越來越習慣于使用簡單的查詢關鍵詞通過Web搜索引擎如Google,Baidu等來搜索信息;另一方面,越來越多的關系數(shù)據(jù)庫到Web上面向廣大普通用戶,形成所謂的“Deep Web”問題,使得普通用戶也期望能夠使用簡單的關鍵詞來查詢關系數(shù)據(jù)庫數(shù)據(jù)。
二、相關定義
定義1:關系數(shù)據(jù)庫模式Sdb(Relational Database Schema)假設關系數(shù)據(jù)庫的模式,Sdb=(R,FK),R={R1,R2,…,Rk}是一組關系模式,FK是R中關系模式間引用關系的映射,FK:RR,如果FK(Ri)=Rj,記為RiRj(1≤i,j≤n),它表示Rj一個外鍵引用了Ri主鍵。
定義2:關系數(shù)據(jù)庫模式圖Gs(Relational Database Schema Graph)假設Gs=(V,E)表示模式Sdb=(R,FK)的關系數(shù)據(jù)庫對應的模式圖。Gs是一個有向圖,將關系數(shù)據(jù)庫中的每一個關系模式Rk(1≤k≤n)看作是Gs的一個節(jié)點,當且僅當關系模式Ri∈Gs,關系模式Rj∈Gs,(RiRj)∈FK時,(Ri,Rj)∈E。
定義3:連接元組樹Jt(Joning Tree of Tuples)給定一個關系數(shù)據(jù)庫的模式圖Gs=(V,E),Jt是以數(shù)據(jù)庫中的元組tl為結(jié)點的一棵樹,其中tl(1≤l≤m)是關系rk(1≤k≤m)中元組,關系rk(1≤k≤m)是關系模式Rk(1≤k≤n)上的實例,如果(Ri,Rj)∈E且(ti tj)∈(ri rj),那么,(ti,tj)是Jt的一條邊,其中ti∈ri,tj∈rj,(1≤i, j≤n),稱Jt為一棵連接元組樹。
定義4:關鍵詞查詢Kq(Keyword Query)把關鍵詞查詢定義為查詢函數(shù)f:KqT,其中Kq是一個集合,其元素ki(1≤i≤m)為關鍵詞,T是一個集合,其元素Jti(1≤i≤n)為一個關鍵詞查詢結(jié)果。
定義5:關鍵詞查詢結(jié)果T(Keywords Qeury Results)關鍵詞查詢結(jié)果是OR語義,Kq是一個集合,其元素為ki(1≤i≤m)為關鍵詞,一個查詢結(jié)果是至少含有Kq中一個ki(1≤i≤m)且每個葉結(jié)點都至少含有Kq中一個ki(1≤i≤m) 的連接元組樹。
關鍵詞查詢結(jié)果是AND語義,Kq是一個集合,其元素為ki(1≤i≤m)為關鍵詞,一個查詢結(jié)果是Kq中的每一個的關鍵詞ki(1≤i≤m)都必須出現(xiàn)在結(jié)果中,并且每個葉子節(jié)點都至少含有一個Kq中的關鍵詞ki(1≤i≤m)的連接元組樹。
三、體系結(jié)構(gòu)
(1)系統(tǒng)設置系統(tǒng)啟動模塊,做一些系統(tǒng)初始化工作,如系統(tǒng)的參數(shù)配置
(2)模式圖生成器從系統(tǒng)配置文件讀入數(shù)據(jù)庫模式圖的模式配置信息,生成數(shù)據(jù)庫模式圖。
(3)用戶查詢該模塊為用戶查詢接口,接受用戶輸入的查詢關鍵詞,
提交后續(xù)模塊處理。
(4)元組集生成器該模塊利用由關系數(shù)據(jù)庫的全文檢索功能建立的IR引擎,將關系數(shù)據(jù)庫中具有文本屬性的每個關系生成元組集,只有那些與某個查詢關鍵詞或者查詢關鍵詞組合相關的非空的元組集保留下來,稱為非自由元組集,每個非自由元組集都是其源表(即生成該元組集的表)的一個子集,每個非自由元組集實際上也是一個臨時表,繼承其源表的主外鍵關系。
(5)候選網(wǎng)絡生成器候選網(wǎng)絡生成器利用元組集生成器生成的非自由元組集擴展模式圖,形成元組集圖,然后對該元組集圖進行擴展,生成結(jié)點不超過預定最大允許結(jié)點數(shù)的候選網(wǎng)絡。所謂候選網(wǎng)絡,也稱元組集連接樹,也是可以看做是要用來產(chǎn)生關鍵詞查詢潛在結(jié)果的JOIN表達式。
(6)候選網(wǎng)絡執(zhí)行器候選網(wǎng)絡執(zhí)行器完全執(zhí)行所有候選網(wǎng)絡得到全部結(jié)果,或者采用某種top-k算法執(zhí)行候選網(wǎng)絡,以得到top-k查詢結(jié)果。
四、查詢處理
系統(tǒng)啟動時,首先會生成數(shù)據(jù)庫模式圖,這個過程非常短,然后系統(tǒng)接收到用戶提交的查詢關鍵詞。當用戶提交查詢關鍵詞時,元組集生成器利用IR引擎生成元組集,然后,候選網(wǎng)絡產(chǎn)生器利用非自由元組集擴展Gs生成元組集圖,廣度優(yōu)先遍歷元組集圖生成候選網(wǎng)絡,最后,候選網(wǎng)絡執(zhí)行器執(zhí)行全部候選網(wǎng)絡。或者采用某種top-k查詢算法執(zhí)行候選網(wǎng)絡,生成最終查詢結(jié)果返回給用戶。通過介紹SDSG系統(tǒng),可以發(fā)現(xiàn)SDSG系統(tǒng)存在的優(yōu)點:數(shù)據(jù)庫模式圖占用內(nèi)存少;缺點:候選網(wǎng)絡產(chǎn)生器執(zhí)行效率低、候選網(wǎng)絡執(zhí)行效率低、缺少語義查詢。
參考文獻
[1] 施伯樂,丁寶康,汪衛(wèi).數(shù)據(jù)庫系統(tǒng)教程.第二版.高等教育出版社,2003:1-359
2）德克薩斯大學的Sunitha Ramanujam提出了“Bi-directional Translation of Relational Data into Virtual RDF Stores”[5]，即關系數(shù)據(jù)和RDF間的雙向轉(zhuǎn)換，并在D2R的基礎上開發(fā)了工具D2RQ++。
3）中科院國家科學圖書館成都分館的Shihan Yang等人提出“半自動化地從關系數(shù)據(jù)庫中構(gòu)建本體”，文中提出了利用中間件來實現(xiàn)關系數(shù)據(jù)庫到本體轉(zhuǎn)化的方法，并且提出了W-graph的中間件語言，W-graph映射語義使用與關系數(shù)據(jù)庫和本體都無關的雙向模擬等價圖表示。中間件模式是動態(tài)的，當數(shù)據(jù)庫模式或本體頻繁變化時，該方法因此有很好的適應性。此方法不僅可以處理數(shù)據(jù)庫模式而且也可以處理數(shù)據(jù)庫中存儲的實例。圖形語義編輯工具的開發(fā)，提高了方法的可用性。
4）許卓明提出 “一種從關系數(shù)據(jù)庫學習OWL本體的方法”，開發(fā)出了關系數(shù)據(jù)庫模式到OWL本體轉(zhuǎn)換原型工具DB2WO，并給出了實例驗證。該研究首先給出了關系數(shù)據(jù)庫模式和OWL本體的定義，其次定義了關系數(shù)據(jù)庫模式到OWL本體的一組映射規(guī)則，然后開發(fā)了轉(zhuǎn)換工具DB2WO。關系數(shù)據(jù)庫模式信息通過讀取關系數(shù)據(jù)庫字典來提取。
5）陳和平等人提出“基于關系數(shù)據(jù)庫的本體生成器的設計與實現(xiàn)”[6] 。該研究中首先指出需要解決的2個關鍵問題：（1）如何提取關系數(shù)據(jù)庫的ER模式（2）如何定義由ER模式到OWL本體的映射規(guī)則。然后給出ER模式的提取一般可以通過查詢該關系數(shù)據(jù)庫的數(shù)據(jù)字典或應用數(shù)據(jù)庫的逆向工程工具，接著給出了ER模式到OWL本體的10多條轉(zhuǎn)化規(guī)則。最后，給出了本體生成器OWLFROMDB的功能模塊結(jié)構(gòu)圖，并給出了實例驗證。
6）中國人民理工大學的Peng Liu等人在2010第九屆國際網(wǎng)格和云計算會議提出“基于關系數(shù)據(jù)庫的本體自動構(gòu)建”[7]。其思想跟前述許卓明、陳和平等一致：通過分析關系數(shù)據(jù)庫模式，建立一系列的從關系數(shù)據(jù)模式到OWL的轉(zhuǎn)換規(guī)則，然后給出了算法和流程圖，最后給出了生成的本體的層次圖。
7）W3C成立了 RDB2RDF研究組，致力于提供一個從關系數(shù)據(jù)庫RDB到本體描述語言RDF的規(guī)范性的映射標準，到目前為止，該研究小組提出了幾個關于RDB到RDF映射語言的內(nèi)部草稿，還未成為標準。
3 研究瓶頸及建議
現(xiàn)在，基于關系數(shù)據(jù)庫生成本體的研究已經(jīng)引起越來越多研究者的興趣。基本思路無非是從關系數(shù)據(jù)庫中提取出數(shù)據(jù)模式，然后設定數(shù)據(jù)模式轉(zhuǎn)化為本體的規(guī)則，然后編程實現(xiàn)。每個研究人員都提出了自己的轉(zhuǎn)化規(guī)則，而并沒有人對規(guī)則的可行性給出評價結(jié)果。至今，尚未有研究者或機構(gòu)給出權威的轉(zhuǎn)換規(guī)則。轉(zhuǎn)換規(guī)則的可行性和合理性應該是未來研究的重點。
4 結(jié)束語
利用關系數(shù)據(jù)庫中結(jié)構(gòu)化的數(shù)據(jù)作為數(shù)據(jù)源來構(gòu)建本體的方法，已經(jīng)引起了眾多研究人員的重視，而隨著W3C的介入， 必將使這種轉(zhuǎn)換規(guī)范化。
參考文獻：
[1] /RDF[EB/OL].
[2] /TR/owl-features[EB/OL].
[3] Du Xiaoyong, Li Man, Wang Shan. A Survey on Ontology Learning Research[J] .Journal of Software, 2006,17(9): 1837-1847.
[4] Sunitha Ramanujam ,VaibhavKhadilkar.Bi-directional Translation of Relational Data into Virtual RDF Stores[C].2010 IEEE Fourth International Conference on Semantic Computing,2010,61:268-276.
關鍵詞：關系數(shù)據(jù)庫 關鍵詞查詢 數(shù)據(jù)庫索引
1 系統(tǒng)總體設計
人們在求解一個復雜問題時，通常采用的是逐步分解、分而治之的方法。也就是把一個大問題分解成若干個比較容易求解的小問題，然后分別求解。設計一個復雜的系統(tǒng)時，往往也是把整個系統(tǒng)劃分為若干個功能較為單一的功能模塊，然后分別予以設計、實現(xiàn)，這就是模塊化設計。本系統(tǒng)也采用這種模塊化設計方式。
■
圖1 面向關系數(shù)據(jù)庫關鍵字查詢系統(tǒng)框圖
2 數(shù)據(jù)庫設計
本系統(tǒng)為面向關系數(shù)據(jù)庫的關鍵字查詢系統(tǒng)，在實驗中本文選取了IMDB 數(shù)據(jù)集，為了進行實驗，將數(shù)據(jù)集整理為以下七個表數(shù)據(jù)結(jié)構(gòu)。
實驗數(shù)據(jù)集（電影信息數(shù)據(jù)庫）：
create table Actor（ //演員表
actorname varchar（50） Primary Key ; //演員姓名key
sex varchar（2）; //性別
mvname varchar（50）; //出演電影或電視劇名
mvyear varchar（10）; //電影上映時間
mvactorname varchar（10）; //電影中人物姓名
position varchar（20）; //電影中人物排名
made varchar（10）; //TV 或是Video
setname varchar（50）; //出演電視劇集名
episode varchar（10）; //出演電視劇集
date varchar（10）; //電視劇播出日期
classification varchar（30）; //（achieve football）
）
creat table Consume（ //設計師
consumename varchar（20） Primary Key; //設計師姓名key
mvname varchar（20）; //電影名或電視劇名
mvyear varchar（10）; //上映日期
setname varchar（20）; //電視劇集名
episode varchar（10）; //電視劇集
productiondate varchar（10）; //電視劇播放日期
classification varchar（30）; //（as M...）
made varchar（10）; ///（V/TV/uncredited）
）
creat table Director（ //導演信息
directorname varchar（20） Primary Key; //導演姓名key
mvname varchar（20）; //電影或電視劇名
mvyear varchar（10）; //上映日期
setname varchar（20）; //電視劇集名
episode varchar（20）; //電視劇集
made varchar（10）; //（V/TV/VG）
explantaion varchar（30）; //（as M...）
）
creat table Business（ //投資
mvname varchar（20） Primary Key; //電影名key
productiondate varchar（20）; //拍攝日期
company varchar（50）; //出品公司
studiodate varchar（50）; //上映日期
masterpiece varchar（1000）;///OW
budget varchar（20）; //預算
ad varchar（50）; ///AD
general_revenue varchar（20）; //收入
wg varchar（50）; //WG
）
editorname varchar（20） Primary Key; //編輯名
mvname varchar（20）; //電影或電視劇名key
mvyear varchar（10）; //上映日期
made varchar（10）; //（V/TV/video）
setname varchar（20）; //電視劇集名key
episode varchar（20）; //電視劇集key
explantaion varchar（30）; //（as M...）
）
creat table Color { //顏色信息
mvname varchar（20）; //電影或電視劇名key
mvyear varchar（10）; //上映日期
setname varchar（20）; //電視劇集名key
episode varchar（20）; //電視劇集key
color varchar（20）; //顏色分類color或black and white
explantaion varchar（10）; //顏色分類之后的（）中有（HD）等，（HD）是高清
Primary Key（mvname，setname，episode）;
}
creat table Keyword（ //關鍵詞
mvname varchar（20）; //電影或電視劇名key
mvyear varchar（10）; //上映日期
setname varchar（20）; //電視劇集名key
episode varchar（10）; //電視劇集key
keyword varchar（50）; //關鍵詞
Primary Key（mvname，setname，episode）;
）
3 數(shù)據(jù)庫索引設計
由于關系型數(shù)據(jù)庫對于文本屬性上全文索引的支持，所以在文本屬性可以直接利用數(shù)據(jù)庫中的全文索引。對于給定的關鍵字k，全文索引能檢索出查詢關鍵字所在位置。
對于數(shù)據(jù)庫中的表屬性，構(gòu)建索引的方式比較簡單，依賴于DBMS的IR索引。對于數(shù)據(jù)庫中具有文本屬性的列，在該列上建立全文索引。在進行關鍵字查詢時，對于給定的關鍵字，通過數(shù)據(jù)庫的全文索引，會返回包含該關鍵字的元組集合。
在進行關鍵字查詢的時候，對于用戶給定查詢關鍵字，系統(tǒng)首先要對給定的關鍵字進行定位，確定關鍵字所匹配的信息是模式項還是數(shù)值項。
例如，關鍵字{“Color”“Director”}的索引結(jié)構(gòu)如表1所示。
表1 關鍵字{“Color”“Director”}的索引結(jié)構(gòu)
■
4 關鍵字檢索設計
在搜索引擎行業(yè)，所謂關鍵字，就是用戶在使用搜索引擎時輸入的、能夠最大程度概括用戶所要查找的信息內(nèi)容的字或者詞，是信息的概括化和集中化。關鍵字檢索作為一種易于使用的檢索方式，為大量普通用戶所喜愛。本文從關鍵字個數(shù)角度介紹現(xiàn)有的關鍵字檢索技術中最常見的單關鍵字查詢和多關鍵字查詢這兩種關鍵字檢索形式。
5 結(jié)果生成設計
在本文中，將查詢結(jié)果定義為元組連接樹。
元組連接樹（Joined Tuple Tree）是給定一個數(shù)據(jù)庫模式圖GS，一個元組連接樹T是一棵元組樹。其中，T中的每一條邊（ti，tj）（ti∈Ri，tj∈Rj）滿足以下兩個要求：
①（Ri，Rj）∈RS，
②ti∞tj∈Ri∞Rj。
同時這些元組連接樹滿足以下條件：
①完整性：用戶提交的所有關鍵字均出現(xiàn)在元組連接樹上;
②最小性：從元組連接樹中移除任何元組后的元組連接樹都不具有完整性。
6 結(jié)束語
通過分析相關檢索系統(tǒng)的實現(xiàn)策略，設計了支持關鍵字檢索的系統(tǒng)架構(gòu)和核心構(gòu)成組件，主要包括數(shù)據(jù)庫索引、數(shù)據(jù)庫模式圖、關鍵字檢索和結(jié)果生成。
參考文獻：
中圖分類號：TP391
文獻標識碼：A 文章編號：16727800（2014）002012703
0引言
工作流是公文流轉(zhuǎn)系統(tǒng)的重要組成部分，不同于一般概念上的工作流，公文流轉(zhuǎn)中的工作流具有自身特點和要求。本文提出的公文工作流模型基于關系數(shù)據(jù)庫，降低了業(yè)務系統(tǒng)與公文流轉(zhuǎn)系統(tǒng)集成的復雜度，減輕了復雜工作流引擎帶來的系統(tǒng)負擔，使公文流轉(zhuǎn)系統(tǒng)能夠適應不同的公文業(yè)務需求。
1工作流技術
通常把工作中具有固定程序的活動集合叫做工作流。它把工作活動細分成定義良好的角色、任務、過程和規(guī)則來完成工作的監(jiān)控和執(zhí)行，從而提高了工作效率和生產(chǎn)組織水平。國際工作流管理聯(lián)盟（Workflow Management Coalition，WFMC）對工作流的概念進行了定義[1]：工作流是指在計算機支持下的整個或部分經(jīng)營過程的全自動或半自動化。通常，工作流由計算機軟件系統(tǒng)控制其執(zhí)行。它包括一組活動以及活動之間的順序關系、一系列過程和對每個活動的具體描述以及活動的啟動和終止條件。通過分離應用邏輯和過程邏輯，可以在只修改過程模型而不修改具體功能的前提下改變系統(tǒng)功能，實現(xiàn)對生產(chǎn)經(jīng)營過程部分或全部的自動化管理，合理、有效地把人、應用和信息組織在一起，實現(xiàn)了“在合理的時間把適當?shù)男畔鬟f給正確的人”的要求。
2公文流轉(zhuǎn)工作流
2.1公文流轉(zhuǎn)工作流定義
WMFC 給工作流做出了如下定義： 按照事先定義好的規(guī)則，文檔、任務或者信息在參與者之間進行傳遞，從而完成整個業(yè)務過程的自動化處理。依據(jù)公文流轉(zhuǎn)的特點，公文流轉(zhuǎn)中的工作流包括如下4 個要素： 多人參與、同一個業(yè)務目標、每個參與者通過動作來完成自己的任務、按照一定的順序和規(guī)則傳遞。公文流轉(zhuǎn)通過多個參與者完成的一系列任務達到業(yè)務目標。由工作流的要素可知，在定義公文流轉(zhuǎn)中的工作流時應考慮以下5方面定義：傳遞的公文文檔定義、角色定義、活動定義、路線定義和事件定義。下面用一個公文流轉(zhuǎn)過程來描述和定義公文流轉(zhuǎn)中的工作流 [2]，如圖1 所示。
（1）活動節(jié)點：實際上代表了組成一個實際過程所需要的任務，包括不可分割的原子級任務和套嵌的公文工作流過程。公文工作流主要依靠流轉(zhuǎn)過程中各個節(jié)點的實現(xiàn)來達到公文流轉(zhuǎn)的目的。
（2）事件節(jié)點：主要是用于確認流程是否推動，如果滿足條件則流程繼續(xù)，否則繼續(xù)等待。
（3）控制節(jié)點：用于控制相鄰活動節(jié)點的先序關系。控制條件一般在活動中定義，由繼續(xù)流轉(zhuǎn)條件、停止流轉(zhuǎn)條件、退改條件組成。繼續(xù)流轉(zhuǎn)條件表示進入這個活動，是這個活動被激活的前提或準備條件；退改條件表示如果活動沒有滿足某個特定條件，則重復執(zhí)行，一直到滿足繼續(xù)流轉(zhuǎn)條件為止。
2.2公文流轉(zhuǎn)工作流分析
2.2.1公文流轉(zhuǎn)工作流程
按照公文流轉(zhuǎn)中節(jié)點處理的時間先后順序，可以把工作流程分為串行和并行兩類。串行流程中所有節(jié)點呈“一”字型排列，后一個節(jié)點的啟動時間為前一個節(jié)點的完成時間；并行流程中兩個或者兩個以上節(jié)點并排排列，節(jié)點可在同一時刻工作。典型的串行流程和并行流程如圖2（a）和圖2（b）所示。
一般情況下，并行流程和串行流程的各種不同組合構(gòu)成一個復雜的公文流程，如圖2（c）所示。
2.2.2公文流轉(zhuǎn)并行工作流程
傳統(tǒng)意義上的紙制公文只有一份，在同一時間只能交給一個人來處理，因此不會有流程分支的情況。公文電子化后，突破了紙制公文只有一份的限制，使流程分支成為可能。但是，公文系統(tǒng)業(yè)務要求保留每個處理過程的修改痕跡，如果將同一份電子文檔交給多人同時修改，不僅會造成文檔修改時的邏輯混亂，也會帶來文檔的存取問題。同一時間一份文檔只能交給一個人處理和修改，某一用戶處理和修改文檔時，文檔是被鎖的，其它用戶要使用此文檔，必須等到該用戶處理完畢。針對以上問題，本文提出了文檔版本的思想來實現(xiàn)公文流轉(zhuǎn)中的并行工作。
用戶A對公文擬稿后，點擊提交按鈕，進入公文流轉(zhuǎn)流程，流程流轉(zhuǎn)到步驟2。此時，系統(tǒng)自動在工作流表中插入一條記錄，F(xiàn)LOW_STATE狀態(tài)為1，表示流程正在流轉(zhuǎn)，公文電子文檔被保存到公文文檔表中。同時在工作流步驟表中插入步驟1和步驟2兩條記錄：步驟1為文件起草，F(xiàn)LOWSTEPS_STATE為2，表示公文已處理；步驟2為B處理過程，F(xiàn)LOWSTEPS_STATE為1，表示公文待處理。在工作流人員表中插入對應步驟1和步驟2的兩條記錄：步驟1的執(zhí)行者為A，F(xiàn)LOWPERSON_OPTION字段為提交；步驟2的執(zhí)行者為B， FLOWPERSON_OPTION字段為未知，表示還未處理。在工作流事件表中插入步驟1的執(zhí)行事件，事件為提交。流程流轉(zhuǎn)到步驟2后，B用戶可選擇的事件有同意、退還、否決。如果B用戶同意，則流程進入步驟3，在工作流步驟表中插入步驟3的記錄，同時把步驟2的狀態(tài)改為2，步驟3的狀態(tài)標為1。在工作流人員表中插入步驟3的執(zhí)行者記錄為C，同時更改B的FLOWPERSON_OOPTION為提交。如果用戶B退還，則流程回到步驟1，同時刪除步驟1后的所有記錄，把步驟1的狀態(tài)改為1，表示公文待處理。如果用戶B否決，則流程終止流轉(zhuǎn)，并把公文流轉(zhuǎn)表中的FLOW_STATE改為終止。
4.2同一任務多人處理策略
在同一任務多人處理流程中，一個任務可能需要多個執(zhí)行者參與，沒有明確的先后順序（即并行流程）。某任務的多人處理流程如圖6所示。
用戶A對公文擬稿后，點擊提交按鈕，進入公文流轉(zhuǎn)流程，流程流轉(zhuǎn)到步驟2。此時判斷出步驟2的任務為兩個人處理，在工作流人員表中對應于步驟2插入兩條記錄，執(zhí)行者分別為B和C，同時生成文檔版本b和文檔版本c，存入公文文檔表，分別由FLOW_ID、FLOWSTEPD_ID和FLOWPERSONS_ID三個字段進行約束。待用戶B和C都提交后，流程流轉(zhuǎn)到步驟3。 D用戶綜合B和C的修改意見，生成版本d。
4.3系統(tǒng)實現(xiàn)
本文采用以上技術，研制開發(fā)了一套以公文流轉(zhuǎn)為核心的辦公自動化系統(tǒng)。該系統(tǒng)基于B/S結(jié)構(gòu)，以IIS 為Web服務器。系統(tǒng)的開發(fā)平臺為ASP. NET，關系數(shù)據(jù)庫為Oracle9i，通過數(shù)據(jù)模型實現(xiàn)對數(shù)據(jù)庫的訪問。系統(tǒng)界面如圖7 所示。
5結(jié)語
本文提出了一種基于關系數(shù)據(jù)庫的公文流轉(zhuǎn)系統(tǒng)實現(xiàn)方法，采用與其它業(yè)務系統(tǒng)相一致的主流數(shù)據(jù)庫將工作流及公文數(shù)據(jù)存儲在結(jié)構(gòu)開放的關系數(shù)據(jù)庫中，大大降低了公文流轉(zhuǎn)系統(tǒng)與其它業(yè)務系統(tǒng)集成的復雜度，同時減輕了復雜工作流引擎帶給系統(tǒng)的負擔。
參考文獻：
