時間：2022-01-30 23:44:56
序論：好文章的創作是一個不斷探索和完善的過程，我們為您推薦十篇關系數據庫范例，希望它們能助您一臂之力，提升您的閱讀品質，帶來更深刻的閱讀感受。
中圖分類號：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
在科技不斷發展的今天，辦公室人員的工作已經發生了較大的變化，已經從原來的數據與文件為中心的個人獨立工作方式發展到了以工作流為核心的團隊工作上。現代化的辦公體系正朝著高速的信息處理、統一的工作流程、先進的知識管理為一身的知識型方向發展，所以現代化辦公自動化（OA）系統在現代化的企業管理中發揮的著越來越重要的作用。
OA系統的后臺數據庫產品有很多，從目前的軟件開發的情況來看，主流產品是IBM的Notes數據庫，正因為如此，Notes數據庫已經成為大家關注的熱點問題，而在辦公自動化系統里有一部分功能的實現需要用到關系數據庫，這兩種數據庫之間的關系及他們之間的轉化方法是怎的呢？本文下面將作一個簡單的分析。
1工作流技術
從OA系統的發展過程來看，我們可以清楚的認識到，辦公自動化系統的核心技術是工作流技術。那么什么是工作流技術呢？它是在一個工作群組中，為了一個共同的目的或者某種任務，在這個群組的人員需要共同協作地去完成某一項工作，工作的方式可以是按先后順序或者同時進行。它包含一組活動、活動之間的內在關系、活動開始和結束的條件、活動的功能描述等內容。概括來說，它是一個電子化的辦公流程，能方便地處理辦公系統中文檔的收發、傳遞、審閱等操作。把工作流技術用在OA系統中可以對現代化管理提供幫助：
第一、它可以加強事務處理的各個環節的協同工作的能力，從而可以讓工作的運作的非常通暢。
第二、工作流技術將各項事務的管理由原來的人工管理轉變為工作流服務器來管理，所以辦公人員可以從大量的繁瑣的工作中解脫出來，從而可以將工作重點轉換到怎么更好地做好事件。
第三、工作流技術對工作流程重組提供了非常實用的技術支持和分析方法。在快速發展的當今社會，管理水平和技術水平都在日益更新，對于辦公室的工作流程發生變化的機會也在增多。所以辦公自動化系統應該能夠快速適應這種動態的變化。一般傳統的技術或者方法不能適應這種變化，可是工作流技術和OA系統的結合就能很快適應這種動態變化，從而實現企業的協同辦公。
2關系數據庫與Notes數據庫的比較與轉化方法
2.1關系數據庫和Notes數據庫的比較
Notes數據庫：它主要是以存儲文本文檔為其主要內容的數據庫管理系統，也就是說它的數據的元組就是文本文檔，是一種非數值型的數據。但是這種非數值型（非結構型）的數據對于Lotus Notes處理起來更為方便，如視頻、聲頻、傳真、OLE對象、圖形、頁面、表格等數據類型Notes處理起來會靈活一點。
對于數據的訪問，Lotus Notes是通過全文檢索方式訪問數據庫的數據，對于檢索定位方面，Lotus Notes是通過視圖定位數據的方式。
關系數據庫：它是一個數值型的DBMS，主要通過數學公式來處理數據，所以對于一個事務型的流程，它必須先將其轉化為嚴格 的數學公式以后，才能在數據庫上進行處理，數據庫中的表實際就是一張二維表，關系型數據庫對一些結構化（數值型）的數據處理起來相當快捷。
對于數據的訪問，關系型數據庫是通過SQL語言訪問數據庫的數據，對于檢索定位方面，關系型數據庫是通過實時查詢來定位數據。
通過上述的比較，兩種數據庫各有各的優勢，而在辦公自動化系統中有一些部門可能會用到一些復雜計算、數據處理等方面的功能，我們知道這些都是Notes不太善長的地方，又加之現在的JSP、ASP等腳本語言訪問關系型數據庫是十分方便的，所以要是能將兩種數據庫進行相互轉化就能解決系統中的問題，下面本文介紹在本系統中他們之間的轉換方法。
2.2兩種數據庫之間的轉化方法
2.2.1 Notes數據庫轉化為關系數據庫
為了與其他的管理信息系統進行信息的交換，在Notes數據庫管理系統里面有一套專門針對和外部程序數據的擴展類庫，也就是Lotus Script Data Object，，這套擴展類庫由三個基本的類構成的一個整體，它們分別是ODBC Result Set、ODBC Query和ODBC Connection，通過他們來完成與外部數據之間的訪問和修改，由于它所使用的標準是ODBC，就通過這樣的標準來讀取的修改外部數據庫的數據的屬性和相應的方法。這三種類主要分工是這樣的，ODBC Connection是負責與外部數據庫之間的連接，ODBC Query主要用于一個結構化查詢語言語句的定義，而ODBC Result Set主要用于在通過SQL語句查詢結果數據集上執行相應數據讀取的操作，在數據庫中我們主要利用RTF域存放Notes文檔數據，而對于RTF域來說，我們可以在數據庫的表單的任何位置放置它，正是因為RTF域可以包含無限制的數據的特點剛好可以滿足文本的特性，所以對于文本中包含有圖片、文字、獨立的文件、甚至可以是一些對象。在關系型數據庫中常處理的一些數據，如文件的名字、生成的時間、文字、日期等我們可以在關系型數據庫直接處理。對于每一個程序文檔完成后就執行QuerySave，使用Lotus腳本語言編寫子程序模塊QuerySave將查詢的信息數據寫到關系型數據庫中。
綜上所述，Notes數據庫轉化為關系數據庫可以是以下幾個過程；
第一步就是要創建三個類：即ODBC Connection、ODBC Query、ODBC Result Set；
第二步就是數據庫的連接，即用ConnectTo函數連接到SQL數據庫，同時使用查詢語句進行查詢操作；
第三步就是將查詢的qry. Sql和結果集相連接，執行有關函數如result.execute查詢到關系數據庫中的情況，當result.currentrow等于零的時候，則可以寫入新一批的數據，李不然就修改數據。
2.2.2關系數據庫轉化為Notes數據庫
在Notes數據庫中我們采取ODBC標準來訪問各種不同數據類型的信息，我們可以利用Notes的內部函數或者相應的腳本語言，就可以將關系數據庫中的有關數據寫入到Notes文檔中，把這些數據變換為Notes數據，我們具體的方法有兩種：
方法一：將@Db函數引入到Notes有關的函數當中。Notes內部有三個函數，即@DbCommand、@DbLookup和@DbColumn，只要在上述函數在第一個參數使用了“ODBC，這樣就是讀取有關的關系型數據庫中的表，這種方法也有很明顯的不足之處，它對于信息的提取只能以列的方式進行，不能以行的方式進行。
方法二：采用Lotus Script數據對象LSX，同時利用Lotus腳本語言編寫相關的數據讀取函數，在Notes里面的ODBC Connection、ODBC Query、ODBC Result Set就是使用ODBC標準來讀取外部的各種不同的數據。
上面兩種方法進行比較，作者認為第二種方法更為科學，下面就簡單談談這種方法的實現過程：
首先，在Notes數據庫中，我們按照SQL數據庫相應表單里的結構同樣建立一個一樣結構的表單，這樣做的好處就在于能夠將關系型數據庫中的數據進行一一轉換，并且容易理解，然后就建立相關的，用腳本語言寫相應的轉換程序；
然后，創建視圖來執行上述的，從而可以實現將關系型數據庫中有關的數據表單轉換成notes數據庫中的信息。
3結束語
本文在上面的敘述當中我們可以發現在OA系統的開發過程中，只要處理好數據庫，就可以做到有的放矢，這就是說，我們可以根據系統的要求，在需要使用Notes數據庫的模塊里就Notes數據庫，在需要使用SQL數據庫的地方就使用關系型數據庫，通過相應的轉換辦法，就可以實現它們之間的數據共享。
參考文獻：
0 引言
關系數據庫是20世紀70年代初提出來，經過數據庫專家幾十年的努力，理論和實踐都取得了顯著成果，標志著數據庫技術的日益成熟。但它仍然難以實現對關系數據庫中數據的分析，不能很好地支持決策，因此在80年代，產生了數據倉庫的思想，90年代，數據倉庫的基本原理、架構形式和使用原則都已確定。主要技術包括對數據庫中數據訪問、網絡、C / S結構和圖形界面，一些大公司已經開始構建數據倉庫。針對數據倉庫中迅速增長的海量數據的收集、存放，用人力已經不能解決，那么數據倉庫中有用的知識的提取就需要數據挖掘來實現。數據挖掘與統計學子領域“試探性數據分析”及人工智能子領域“知識發現”和機器學有關，是一門綜合性的技術學科。了解關系數據庫、數據倉庫與數據挖掘三者之間的區別與聯系，使之更好的使用這3種技術，處理各種信息需求是非常必要和重要的。
1 關系數據庫、數據倉庫和數據挖掘之間的關系
1.1 關系數據庫和數據倉庫之間的聯系與區別
關系數據庫是面向事務的設計，數據倉庫是一個面向主題的設計；關系數據庫存儲在線事務數據，數據倉庫通常存儲歷史數據，關系數據庫的設計將盡量避免冗余，但數據倉庫是傾向于引入冗余；關系數據庫設計用于捕獲數據，數據倉庫設計用于分析數據。傳統的關系數據庫面向以事務處理為主的系統應用，所以它無法滿足決策支持系統的分析要求。事務處理和分析處理有非常不同的性質，他們有不同的需求數據。
1.2 數據倉庫與數據挖掘之間的聯系與區別
數據挖掘是基于數據倉庫和多維數據庫中的數據，找到數據的潛在模式進行預測，它可以對數據進行復雜處理。大多數情況下，數據挖掘是讓數據從數據倉庫到數據挖掘數據庫中。從數據倉庫中直接得到進行數據挖掘的數據有許多優點，因為數據倉庫中數據的清理和數據挖掘中幾乎是相同的，如果數據在數據倉庫中已被清除，數據挖掘中不再被清除，并且數據不一致也得到了解決。數據倉庫是數據挖掘的先期步驟，通過數據倉庫的構建，提高了數據挖掘的效率和能力，保證了數據挖掘中的數據的寬廣性和完整性。
1.3 關系數據庫與數據挖掘之間的聯系與區別
數據挖掘的數據源不一定是數據倉庫。也可以是一個關系數據庫中的數據，但要事先進行數據預處理，才能用于數據挖掘。數據預處理是數據挖掘的關鍵步驟，并且是數據挖掘過程中的主要工作部分。因此，數據倉庫和數據挖掘沒有必然的聯系，有些人簡單地認為，數據倉庫是數據挖掘的準備，這種理解是不全面的，也可以使用關系數據庫中的數據作為數據挖掘的數據源。
2 三種技術的應用
2.1 應用價值
2.1.1 關系數據庫
關系數據庫的主要價值體現在事務處理。關系數據庫已經滲透到各行各業的日常事務，該事務管理離不開關系數據庫的應用系統，這是對傳統事務管理的一個重大突破，是社會甚至家庭不可或缺的工具，它對社會的應用價值是100%。
2.1.2 數據倉庫
數據倉庫的主要價值體現在為決策分析提供數據源。一方面，在一個事務中，用戶要求高效的訪問系統和數據庫，操作時間應該短。在一個決策分析中，決策問題的一些請求可能會導致系統的操作，解決這一問題的決策分析需要遍歷大多數數據庫中的數據，這對一般日常事務處理系統是困難的，所以操作數據和決策分析數據應該分開。另一方面，決策數據需求問題。在決策分析時，由于不同的應用系統中，實體、字段存在數據類型、名稱和格式的不符，需要在集成時進行轉換，這個轉換必須在決策之前完成；一些決策數據需要動態更新，需要經常進行匯總和總結，這些需求用事務處理系統解決比較繁瑣。三是數據的操作模式問題。決策分析人員要以專業用戶身份，使用各種工具以各種形式來操作數據，對數據操作的結果以商業智能的方式表達出來。事務處理系統不能滿足這一要求，只有數據倉庫系統能夠滿足數據挖掘技術對數據環境的要求，所以使用數據倉庫中的數據省去了對數據預處理的步驟。
2.1.3 數據挖掘
面對日益激烈的市場競爭，客戶對迅速應答各種業務問題的能力要求越來越高，對過量數據的及時處理要求越來越高，帶來的挑戰一方面大規模、復雜數據系統讓用戶感覺漫無頭緒，無法開始；另一方面，這些大量數據背后隱藏很多有意義的有價值的決策信息。如計算機界都熟知的“啤酒與尿布”的故事，就是零售業巨頭“沃爾瑪”從大量銷售數據中分析出來的規律：美國的男士在下班要去超市買嬰兒尿布，同時他們還會買啤酒。“沃爾瑪”就把這兩種“毫不相干”的商品擺放在靠近的貨架上，并且還擺放一些下灑小菜，使這些商品銷量大增。所以應用數據挖掘從大量數據中發現規律，具有具體的指導意義。
2.2 應用領域
2.2.1 關系數據庫
關系數據庫應用領域非常廣泛，如：證券行業、醫院、銀行、銷售部門、公司或企業，以及政府、國防工業，科學和技術發展領域等等，這些領域都需要使用數據庫來存儲數據。例如：人事管理系統、工資管理系統，xxx部門信息管理系統，手機話費管理系統等，都需要關系數據庫作為后臺提供數據源。
2.2.2 數據倉庫
數據倉庫應用領域主要有兩個方面：一是全局應用。因為數據倉庫獲得來自多方面的數據，所以在把數據向數據倉庫輸入時，要進行轉換、計算和綜合等集成處理。通過處理把來自不同地方的數據源轉換成統一的格式，以促進全局應用。二是復雜系統。信息處理的要求越來越復雜，除了數據處理操作，如添加、刪除、修改、和統計匯總，高級管理層也希望對歷史的和現在的數據進行各種復雜性分析，以支持決策。數據倉庫中就是存儲了舊的歷史數據，方便復雜分析、應用，為高層決策服務。
2.2.3 數據挖掘
數據挖掘的應用領域主要表現在特定應用問題和應用背景。數據挖掘技術已經應用于各行各業，如電信，保險，交通，學校、銀行、超級市場等。例如：數據挖掘技術應用在大學。高校擴招，學生增加到幾萬人，但是學生的學習積極性不高，成績不好，因此引入數據挖掘技術找出影響學生學習積極性和學習成績的原因，制定措施，提高教育和教學質量。分析的數據源是考試成績和成績之外的影響因素，分析的方法是采用關聯規則、模型庫、去“噪”處理、粗糙集等進行數據挖掘，得出的結論是：傳統的學習方法不能完全滿足需要，改進教學方法和教學模式，從而調動學生學習的積極性，提高教學質量。
3 關系數據庫、數據倉庫與數據挖掘的融合
日常事務處理需要關系數據庫，構建分析處理環境需要數據倉庫，幫助決策者尋找數據之間的潛在的關聯需要數據挖掘。他們之間是相互聯系又有區別的，不能互相取代的，又需要相互融合。數據倉庫中的數據并不是最新的，專有的，而是來源于其他關系數據庫，它是建立在一個更全面和完善的信息應用的基礎上，用于支持高層決策分析的數據基地。數據倉庫是數據庫新技術，到目前為止，數據倉庫仍用關系數據庫管理系統管理數據。數據挖掘是從大量存儲在數據庫、數據倉庫或其他信息庫中發現有趣知識的過程。只有這三個數據庫技術互相融合，取長補短，各盡其責，才能更好的為廣大用戶所使用，為社會各個領域所應用。
【參考文獻】
中圖分類號：TP311 文獻標識碼：A 文章編號：1009-2374(2011)07-0088-02
在信息技術與網絡技術高速發展的今天，網絡已經成為新一代操作平臺。信息正全面地以互聯網方式展開，互聯網的信息傳播，極大地加速了人類發展的進程。隨著WEB技術的日益發展，WEB已經成為信息制造、、加工和處理的主要平臺。XML技術已日益受到更為廣泛的關注，已經在電子商務、電子數據交換、科學數據表示、數據建模與分析和搜索引擎等領域有著廣泛的應用。隨著XML應用技術的深入，將會有大量的XML文檔出現，并且現在在網絡上已經積累了大量的XML文檔。本文主要就基于關系數據庫的XML存儲技術相關問題進行探討。
一、XML與關系數據庫結構上的差異
XML文檔是半結構化的數據，是一個樹模型，如果考慮到XML元素次序，則是一棵有序樹模型，其數據結構是非結構化的，而關系數據庫管理系統是采用二維表格作為存儲數據的模型，表格由行和列組成，列被稱作“字段”用于表示組成數據有效信息的屬性，行則用于儲存一條完整的數據記錄。XML數據與關系表之間數據結構有很大的差異，具體來說，XML數據是有序的，而關系數據則是無序的，另外XML數據的模式往往經常變化，可是關系數據庫的數據結構是固定不變的，XML數據可以無限層次嵌套，而關系數據則不能。雖然XML放松的類型限制和自描述性有利于數據之間的交換，但是卻不利于數據存儲。因此，XML的數據模型的半結構化、有序性與平坦、無序的關系模型之間存在固有的不匹配。另外遵循文檔類型定義(DTD)或文檔模式定義(XML SCHEMA)的XML文檔也與遵循關系存儲模式的關系數據在語法、結構以及約束等很多方面存在著固有的異構性，因此很難直接由XML數據產生關系模式。甚至即使多個XML文檔實例都遵循同一個文檔模式定義，它們也可能有不同的結構。可以看出，XML映射到關系數據庫中存在固有的困難。映射時主要存在以下需要解決的問題：(1)如何利用可能有的XML文檔模式(或類型)信息來采取各種不同的存儲策略；(2)如何將XML文檔無損地存入關系數據庫；(3)如何從關系數據庫中查詢并重構XML信息。
二、基于關系數據庫的存儲策略
(一) 基于結構映射的策略
具體來說，基于結構的映射方法可以分為兩個步驟來實現：
第一步：簡化DTD并生成DTD圖。因為XML DTD的元素是相當復雜的，需要對復雜的DTD進行簡化。DTD的簡化變換主要有以下三種方式：(1)平面化變換：將DTD內的層次嵌套關系打平，把嵌套的定義轉換為非嵌套的定義；(2)簡化變換：將連續的多個一元操作轉換為一個一元操作；(3)聚集變換：將多個具有相同名稱的子元素聚在一起，形成一個子元素。一個DTD圖表示的是一個DTD的結構，圖的結點表示DTD中的元素、屬性或操作符，DTD中的元素在DTD圖中只出現一次，屬性和操作符在DTD圖中出現的次數則與它們在DTD中出現的次數相同。
第二步：DTD圖到關系模式的映射。從DTD圖到關系模式的映射方法主要有：基本內聯法、共享內聯法和綜合內聯法。
首先，基本內聯法。基本內聯法的原則是在存儲一個結點的時候，盡可能多地將這個元素的后代結點存儲在一個表中。其次，共享內聯法。共享內聯法為以下三種DTD結點生成獨立的關系：(1)DTD圖中入度大于l或者等于0(根結點)的元素結點生成獨立的關系；(2)DTD圖中結點“幸”的孩子結點(將值集元素作為單獨的關系保存)；(3)互為遞歸的入度均為1的元素結點，其中之一生成獨立的關系。而其余的結點都生成關系屬性。共享內聯法相對減少了XML查詢轉換為SOL語句的數目，但增加了每個SOL查詢中的連接運算。再次，綜合內聯法。綜合內聯方法在處理入度大于1的結點上與共享內聯方法不同，綜合內聯法將所有入度大于1的元素結點也內聯進入父結點所生成的關系表中，但是帶回路的結點以及結點“}”或“+”的直接后繼結點除外，該方法減少了子結點與父結點的連接運算。
(二) 基于模型映射的策略
模型映射的方法是用一個固有的模式來存儲XML文檔。它用固定的關系模式來存放任何格式的XML數據，而不考慮XML文檔的模式(DTD或SCHEMA)，其實質是存儲XML文檔本身的結構信息。
第一，Edge方法。Edge方法圓的存儲策略是把要存入的XML文檔看做圖形結構，每個圖的邊界都表示為圖中的元組，把XML文檔圖中的所有邊都存入到關系表Edge中，用表Edge(source，ordinal，target，label，flag，value)存儲XML文檔圖中的邊，其中的source字段和target字段分別用來存儲邊的源結點和目標結點的標識符；label域為目標結點的類型；flag用來區分目標結點；target是一個元素結點還是一個文本結點，如果該目標結點是文本結點，則文本值存儲于value域中；ordinal字段指出target結點在source結點的所有孩子中的位置。由于Edge方法將所有XML數據都用Edge表存放，操作方法簡單。但缺點是在Edge方法中每條邊都是單獨管理的，所以在用戶進行查詢操作時就需在大量的表上進行連接操作以形成路徑。如果要判斷祖先/后代關系就需要從祖先到后代(或與之相反)遍歷所有的邊，造成代價非常昂貴。
第二，XRel方法。XRel方法為了存儲XML文檔的所有信息，將XML文檔樹分解為一個個路徑表達式，對于樹中每一個結點，都將從根結點到其自身的路徑存儲。而在樹中有可能有多個結點的路徑是一樣的，所以單個的簡單路徑表達式并不能夠存儲整棵XML文檔樹的信息。XRel模式是通過區間編碼[start，end]來反映XML文檔的模型結構，并根據結點類型來劃分，分為元素結點表、屬性結點表和文本結點表，同時將所有路徑進行存儲。因此，XRel模式由四個關系表組成如圖1所示：
在Path表中，存儲所有的不重復的路徑，其中，PathID為標記路徑的標識，pathexp域存儲標記路徑。為了實現路徑表達式的字符串匹配操作，防止意外的結果出現，將標記路徑中的“/”替換為“#/”進行存儲。對于Element表、Attribute表和Text表，Attribute表和Text表中的value字段存儲的分別是屬性結點的值和文本結點的值。對于每一個路徑表達式，查詢過程都可以分為兩部：第一步，利用字符串的匹配操作，能夠快速的查找出與路徑表達式相匹配的所有標記路徑的標識；第二步，利用這些路徑標識，能夠快速的查找出隸屬于這些路徑終端的值。
XRel存儲模式的特點可以總結如下：(1)用簡單路徑表達式和結點的區間編碼(start，end)存儲XML文檔的所有信息；(2)分別為每一種結點類型創建一個對應的關系表；(3)用一個Path表把文檔中所有不重復的路徑都提取出來，有效地降低了數據庫的存儲容量。
第三，XParent方法。XParent模式和XRel模式一樣，將文本數據路徑獨立出來，共包含四個關系表，如圖2所示：
其中，表LabelPath中的pathexp字段用來存儲所有不重復的標簽路徑，即模式路徑。每一個標簽路徑被賦予一個標識符pathlD，length為標記路徑的長度。Parent表存儲的是雙親/孩子關系，pid和cid分別表示一個邊的起始結點與結尾結點。did為XML文檔中元素結點的標識，它也可以作為以該結點為終端點的數據路徑的標識。
中圖分類號：TP311 文獻標識碼：A 文章編號：1009-3044（2016）26-0008-02
1 引言
關系數據庫是當今應用最廣泛的數據庫系統。關系數據庫支持關系數據模型。關系數據結構非常單一，現實世界中的實體及實體之間的聯系都是用關系來表示，在用戶看來，關系數據結構就是二維表。常用的關系操作包括查詢操作和插入、刪除、修改操作兩大部分，其中查詢操作的表達能力最重要。數據查詢是數據庫應用中非常重要的組成部分，數據查詢是否具備較高的執行效率和反應速度受到數據庫設計者和用戶的極大關注。
2 不同查詢方案代價對比
關系模型中的查詢語言早期通常是用代數方法或邏輯方法來表示，分別稱為關系代數和關系演算，隨后出現一種介于關系代數和關系演算的語言稱為結構化查詢語言，簡稱SQL。SQL語言作為關系數據庫的標準語言向用戶提供了易于掌握、高度非過程化得查詢語言。大多數商用數據庫都支持SQL語言，用戶只需指明“干什么？”不需指出“怎么干。”對同一個查詢要求有不同的查詢解決方案，查詢優化就是盡量在不同的解決方案中找到效率高、代價小的方案。
為了提升數據庫系統性能對數據查詢進行優化成了必須解決的問題，查詢優化技術的發展與應用，也助推了數據庫技術的推廣與普及。
下面我們通過一個實例對比不同查詢方案所花費的代價。
商品銷售管理數據庫
銷售點信息表（銷售點編號，城市、地址，聯系電話，開設時間）
產品信息表（產品編號，產品名，類型，規格，生產廠家，進貨價格）
銷售情況表（銷售點編號，產品編號，銷售量，銷售單價）
求銷售產品編號為’JD051’這種產品的銷售點信息？
用SQL語言表達該查詢：
Select 銷售點信息表.*
From 銷售點信息表 ， 銷售情況表
Where 銷售點信息表.銷售點編號=銷售情況表.銷售點編號 and 產品編號=’JD051’
SQL語言是高度的非過程化語言，同一個查詢要求可以有不同的執行方式。下面針對上述查詢要求運用關系代數表達式來表示不同的執行方式。
方案1
Π銷售點信息表.*（σ銷售點信息表.銷售點編號=銷售情況表.銷售點編號∧銷售情況表.產品編號=’JD051’（銷售點信息表×銷售情況表））
第一種方式需要占用內存空間保留廣義笛卡爾積的中間結果，讀取數據量過多及耗時較長；
方案2
Π銷售點信息表.*（σ產品編號=’JD051’（銷售點信息表∞銷售情況表））
第二種方案相比第一種方式減少了中間結果，使用自然連接相比笛卡爾積大大減少了中間結果；
方案3
Π銷售點編號（σ產品編號=’JD051’ （銷售情況表））∞銷售點信息表
第三種方式減少了數據讀取量，中間結果相比第二種情況更少。總的查詢時間最短、查詢代價最少。
以上三種表達式雖然等價，但其執行的查詢策略不同，數據規模越大，查詢所花費的代價差別就越大。通過三種不同查詢方式的對比，說明查詢優化的必要性，選擇合適的查詢策略將大大減少查詢時間、降低查詢代價，因此查詢優化問題一直是數據庫研究的重點。
3 關系數據庫查詢處理過程
當用戶發出查詢請求，要采用不同的處理步驟對原始查詢進行轉換，這些轉換工作必須在系統處理查詢請求和返回查詢結果前完成。關系數據庫查詢處理過程如圖1所示。
圖1
主要步驟：語法分析與翻譯處理，查詢優化處理，執行。
4 查詢優化技術分類
查詢優化技術一般分為代數優化和非代數優化（物理結構優化）。
1）代數優化，通過對查詢語句進行變換，改變基本操作的次序，使查詢語句執行起來更有效，這種查詢優化僅涉及查詢語句本身，而不涉及實際存取路徑，稱為獨立于存取路徑的優化，或代數優化。
查詢是由高級查詢語言表示的對數據庫的一個或一組操作的集合，通常由投影、選擇、連接、笛卡爾積等操作符組成。通過語法分析功能分析查詢語句的正確性、完整性、有效性，并將其轉換為等價關系代數查詢樹，如圖2。
根據關系代數等價變換規則，查詢樹可以按以下方法進行變換：
方法1：下移選擇和投影運算，以減少中間結果的元組數和參與運算的關系的規模；
方法2：將某些選擇運算與笛卡爾積運算相結合；
方法3：同時執行同一個關系上的選擇、投影運算，減少對關系的掃描次數；
方法4：將連接運算與投影運算結合起來執行。
圖2可變換為圖3。
對比圖2和圖3選擇運算和投影運算優先執行，減少了查詢中間結果的元組數，大大降低了參與連接運算的關系規模。
在制定具體的查詢策略時應盡量減少對數據表的訪問，減少對磁盤的訪問次數，訪問磁盤所需的時間大大長于對內存的訪問時間，減少對磁盤的訪問次數將大大降低系統的響應時間。選擇運算盡可能提前做，往往可以使執行時間降低幾個數量級，通過選擇運算減少中間結果。在執行連接操作前，對關系進行適當的預處理，在連接的字段上建立索引以及對關系進行排序，加快查詢速度。
關系代數優化的一般步驟：[3]
（a）把查詢轉換成語法樹；（b）優化語法樹；（c）選擇低層次的存取路徑；（d）選擇代價較小的查詢方案。
2）非代數優化，也稱物理結構優化。數據庫物理結構是整個數據庫存儲的基礎，物理結構設計是在邏輯結構設計的基礎上完成的，應確保數據庫存儲和訪問或操作數據表具有較高的執行效率。物理結構優化是指為數據庫系統的數據推薦合適的物理存儲位置或存儲結構，以及為查詢推薦合適的存取路徑，進而提升系統的整體性能。
5 小結
查詢優化技術是數據庫中一項重要的技術。對于的查詢要求，我們應該根據數據規模大小，具體的物理存儲結構等因素進行分析，選擇合適的查詢策略。具體的SQL查詢語句應根據代數優化的相關原則進行變換，提高查詢效率。查詢優化目的是為了提升系統的性能，如果進行優化本身需要花費的代價過大，反而會降低系統的性能。所以只有兼顧了查詢效率、控制系統開銷、保障數據庫安全等諸多方面才能真正地優化系統的性能。
參考文獻：
[1] 馮衛兵.關系數據庫的查詢優化[J].現代計算機，2010（1）.
[2] 王能斌.數據庫系統原理[M].北京：電子工業出版社，2001.
[3] 薩師煊，王珊. 數據庫系統概論[M].3版.北京：高等教育出版社，2000.
[4] 谷震離.關系數據庫查詢方法研究[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
關系數據庫從1970年發展至今,雖功能日趨完善,但對數據類型的處理大多采用數字、字符等基本數據類型,對多媒體信息的處理只是停留在簡單的二進制代碼文件的存儲。隨著信息技術的發展,互聯網上數據量高速增長,非結構化數據的應用日趨擴大,再加上用戶應用需求的提高、硬件技術的發展和Web2.0提供的多彩的多媒體交流方式,用戶對多媒體處理的要求從簡單的存儲上升為識別、檢索和深入加工等高級應用。關系數據庫在處理這類數據時,逐漸暴露出了一些缺陷。
如何來高效處理占數據總量70%的聲音、圖像和視頻等復雜數據類型是目前互聯網界亟待解決的問題。正是在這種狀態下,云端數據庫便應運而生并開始發展起來。目前云端數據庫技術在云計算中的應用有Google的Bigtable系統[1]、Amazon公司的Dynamo系統、Hadoop的一個子項目Hbase、微軟的Live Mesh系統等等。無論是Bigtable還是Hbase都是采用通用的云端數據庫架構,只是核心技術不同。所以本文就以Google的Bigtable架構為代表與傳統的關系數據庫架構進行比較和分析。
1關系數據庫
1.1關系數據庫概念及特點
關系數據庫在一個給定的應用領域中,所有實體及實體之間聯系的關系的集合。它是建立在集合代數基礎上,應用數學方法來處理數據庫中的數據,現實世界中的各種實體以及實體之間的各種聯系均用關系模型來表示,也就是說關系數據庫是建立在關系模型基礎上的數據庫[2]。
關系數據庫具有數據結構化、最低冗余度、較高的程序與數據獨立性、易于擴充、易于編制應用程序等優點,目前較大的應用軟件系統都是建立在結構化數據庫設計之上的。
1.2關系數據庫系統的架構
關系數據庫的架構包括六個部分[3]:
1) 查詢語言接口
查詢語言接口通過使用SQL語言對數據庫進行特設查詢數據。
2)交互式查詢工具
交互式查詢工具是用于訪問,修改以及更新一個或多個關聯的數據表,并以視圖的方式返回給用戶。
3) 核心軟件
該核心軟件用于控制查詢處理,存取數據路徑,用戶訪問管理,存儲管理,索引,交易處理和讀取/更新信息。
4) 公用機制
公用機制主要用于輸入/輸出/備份調整工具及參數/報告撰寫。
5) 存儲機制
存儲機制主要進行數據庫寫入,歸檔,用戶管理器,服務器管理,重做日志文件。
6) 數據庫
數據庫的特點是以數據文件的方式對數據對象進行物理存儲,包含了系統目錄即數據目錄,一個或多個數據文件以結構化形式存儲組成集合即二維表,并將不同數據集通過主鍵和外鍵進行關聯。
關系數據庫的架構如圖1所示。
1.3關系數據庫的缺陷
通過對關系數據庫架構的分析,可以發現關系數據庫的一些不足,概括如下四點:
1) 數據類型表達能力差
因為關系數據庫所處理的是結構化的數據,所以關系數據庫缺乏直接構造與現代軟件應用有關的信息的類型表達能力。隨著信息技術的飛速發展,圖像、視頻、音頻以及文檔等非結構化的數據已被應用到人們的日常生活當中,利用關系數據庫來處理這些非結構化的數據已經顯得有點力不從心了。因此目前大多數RDBMS產品所采用的簡單類型在重構復雜數據的過程中將會出現性能問題;數據庫設計過程中的額外復雜性;RDBMS產品和編程語言在數據類型方面的不協調,需要通過較復雜的程序化進行數據類型之間的轉換來達到數據類型的一致性。
對于工程應用來說,關系數據庫不能支持復雜數據類型的典型結果就是需要額外地分解數據結構工作,這些被分解的結構不能直接表示應用數據,且從基本成分重構時也非常繁瑣和費時間。
2) 復雜查詢功能比較差
在關系數據庫中,利用SQL語言進行查詢數據。雖然SQL語言為數據查詢提供了很好的定義方法,但是當用于復雜信息的查詢時可能會非常繁瑣。這是由于在工程應用時規范化的過程通常會產生大量的簡單表,從而降低數據的冗余度。那么在這種環境下由存取信息產生的查詢必須處理大量的表和復雜主鍵和外鍵之間的聯系以及連接運算,會影響系統的查詢效率。
3) 支持長事務能力差
由于RDBMS記錄鎖機制的顆粒度限制,對于支持多種記錄類型的大段數據的登記和檢查來說,簡單的記錄級的鎖機制是不夠的,但基于鍵值關系的較復雜的鎖機制來說卻很難推廣也難以實現。
4) 環境應變能力差
在要求系統改變的環境下,關系數據庫從一種系統移植到另一個系統上的成本高且修改困難。再加上,關系數據庫和編程語言所提供的數據類型的不一致,使得從一個環境轉換到另一個環境時需要多至30%的附加代碼。
正是由于關系數據庫的這些缺陷,才推動了數據庫技術的發展,產生了云端數據庫技術,進而彌補了關系數據庫的不足。
2 云端數據庫
2.1 Bigtable的介紹
Google在 2004 年初就開始研發了BigTable,到了2005年大概有100個左右的服務使用BigTable。BigTable 讓Google在提供新服務時的運行成本降低,最大限度地利用了計算能力。
Bigtable是一個大型,容錯,自我管理的分布式存儲系統,并用于管理分布在成千上萬臺服務器上的結構化數據[4]。它是建立在GFS分布式文件系統[5]、Scheduler分布式集群調度、Lock Service分布式的鎖服務[6]和 MapReduce編程模式[7]基礎之上的系統。
2.2 Bigtable的架構
1) Bigtable的數據模型
一個Bigtable(大表)是一個稀疏的,分布的,持續的以及多維的排序的數據映射。這個映射由行主鍵,列主鍵和時間戳進行索引[4]。每一項值在映射中是一系列不被解釋的字節元組即(row:string,column:string,timestamp:int64)string。
在Bigtable的數據模型中,所有的數據都存放在表格單元中,每一行表示一個事物的數據內容,其所在列表示這個事物的唯一標志,其所對應的時間戳表示這個事物在某個時間上的狀態即具體的數據內容。關系數據庫只能反映當前時間上事物所處的狀態,而Bigtable不僅能顯示事物當前所處的狀態,而且還可以記錄某個事物的過去某個時間所處狀態。Bigtable的數據模型如圖2所示。
2) Bigtable的架構
與目前的關系數據庫類似,BigTable也是客戶端和服務器端的聯合設計,使得性能能夠最大程度地符合應用的需求。
BigTable系統依賴于集群系統的底層結構,一個是 Google的分布式文件系統(GFS),一個是分布式的集群任務調度(scheduler),還有一個分布式的鎖服務(Lock Service)。BigTable使用Lock Service來保存根數據表格的指針,即客戶端用戶可以首先從Lock Service鎖服務器中獲得根表的位置,進而對數據進行訪問。BigTable使用一臺服務器作為主服務器,用來保存和操作元數據。主服務器除了管理元數據之外,還負責對tablet服務器(即一般意義上的數據服務器)進行遠程管理與負載調配。客戶端通過編程接口與主服務器進行元數據通信,與tablet服務器進行數據通信[8]。
Bigtable的架構由Bigtable master、Bigtable tablet servers和Bigtable client library三部分組成,如圖3所示。
Bigtable master存儲了許多由大量的tablets組成的表。主要負責指派tablet到tablet的各個服務器上,并檢測tablet服務器的增減和服務程序裝載滿與否,進行實時的分配任務,使tablet服務器負載均衡并回收GFS文件系統中的垃圾文件。此外,它還處理模式更改,如表和列簇的創建。
每一個tablet服務器用于管理一部分tablets,通常有10-1000個tablet和處理客戶端用戶的讀/寫請求。tablet是由大表以行為單位分隔而成的。每個tablet保存了連續的行,然后別分配到各個tablet服務器上。
Bigtable client library是客戶端用戶和Bigtable服務器通信的接口。用戶通過Bigtable client library接口來讀數據和寫數據等操作。
3 關系數據庫與云端數據庫的比較
3.1 兩者架構的區別
關系數據庫架構與云端數據庫中的Bigtable架構主要區別如表1所示。
3.2 基于架構的比較分析
通過對關系數據庫架構和云端數據庫中的Bigtable架構的分析,可以從以下幾個方面對兩者進行比較:
1) 數據模型
在關系數據庫中創建的表是一張二維表包括行和列,使用簡單的數據類型對結構化的數據進行存儲。但對于非結構化的數據的存儲,因為關系數據庫要保持數據冗余度低這一優點,所以關系數據庫的設計會比較復雜且困難。而Bigtable創建的類似于二維表,但事實上不是二維表,它是由行主鍵、列主鍵、時間戳三個域組成的多維map。雖然Bigtable存儲數據的冗余度比較高,但是Bigtable比關系數據庫的二維表多了一個域――時間戳域,時間戳域可以記錄事物的不同時間時的狀態。另外Bigtable是以一條記錄為原子對數據進行操作的,所以Bigtable不僅可以對事物的當前狀態進行更新,還可以對事物的過去狀態進行查詢。在這一點上,關系數據庫是不支持歷史查詢的。
2) 數據的存取方式
在關系數據庫中用戶對數據進行查詢、添加、修改及刪除等的操作是使用SQL語言。對于處理海量及復雜數據時,使用SQL語言對多個關聯表進行操作就可能會顯得非常繁瑣。Bigtable并非支持SQL語言的數據庫,而是以map 函數方式的,以列導向的數據庫。Bigtable對數據的存取是以一行記錄為原子進行的,不必關聯其他的表,那么數據存取的速率要比關系數據庫要高。
3) 數據遷移能力
關系數據庫提供了一些簡單的數據類型,在環境發生變化比如應用平臺或者是編程語言所提供的數據類型與關系數據庫所提供的不一致時,那么數據之間的轉化過程將會相當復雜而且還會增加成本。而Bigtable所提供的數據類型只有字符串類型,所有數據都是以字符串的形式進行處理,因此Bigtable在進行數據遷移時相比關系數據庫要容易并且成本也要比關系數據庫要低得多。
4) 支持事務
關系數據庫為了保持數據的完整性和一致性,提供了事務處理功能。關系數據庫在處理簡單事務方面,顯現出了關系數據庫的優勢。但是在處理繁瑣的事務方面,比如執行了n條SQL語句來對多個關聯的數據表進行處理,執行效率就會顯得比較低。目前,Bigtable還不支持事務處理功能,但是Google已經考慮到了該功能,一旦Bigtable支持了多行數據的事務支持,執行效率將會大大提高。
總之,云端數據庫在處理非結構化數據時要比關系數據庫的效率高,更適宜在多節點的服務器集群上工作,比關系數據庫更適應環境的變化,最大的優點是使用成本比關系數據庫要低得多。
4 結束語
本文通過對關系數據庫架構和云端數據庫架構的比較分析,可以得出云端數據庫在許多方面要比關系數據庫占優勢,也就是說云端數據庫技術具有很大的發展前景。雖然云端數據庫技術還不夠成熟,再加上各大關系數據庫供應商對關系數據庫技術的不斷改進以及對查詢算法進行優化,但是隨著云端數據庫技術的不斷成熟,將會得到廣泛的應用,進而逐步會取代關系數據庫成為數據庫中的主流。
參考文獻:
[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] 瞿裕忠 胡偉 鄭東棟 仲新宇. 關系數據庫模式和本體間映射的研究綜述[J].計算機研究與發展,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 引言
數據庫系統是管理信息系統的核心，基于數據庫的聯機事務處理（OLTP）以及聯機分析處理（OLAP）是企業、銀行、政府部分最為重要的計算機應用之一。從大多數數據庫系統的應用實例來看，查詢操作是所有數據庫操作中所占據比重最大的操作。當數據庫系統積累到一定程度（如稅務系統的賬戶達到上百萬甚至上千萬條記錄），全表掃描一次往往需要數十分鐘，甚至數小時。如果采用比全表掃描更好的查詢策略，往往能降低查詢時間。如何設計數據庫，采取什么樣的查詢方法，提高查詢效率，這就是查詢優化要解決的問題。
2 合理使用索引
索引是數據庫一個常用的數據庫對象，優化查詢的重要方法是建立索引，也是數據庫同時預先將數據分類導入到多表格的方式。在關系數據庫的表上建立合適的索引，可以提高數據庫數據查詢的速度，改善數據庫的性能。除了集簇索引，每一索引的使用都以磁盤容量作為代價，當使用一個索引，數據庫引擎必須執行兩個數據讀取，這兩個數據讀取是數據庫記錄所必需的，第一個數據被讀取到實際數據指針的索引，第二個數據被讀入到指針指定的位置。因此創建索引時必須要與實際應用系統的查詢需求密切結合，才能達到優化查詢的目的。
2.1 建索引的必要性
判斷索引必要性的最終標準是判斷這些索引是否對數據庫的工作效率有所幫助。在實際的應用過程中，應該為優化工作做以下幾點準備：
首先觀察數據庫應用程序中所有的SQL語句，并從中統計出常用且可能對性能有影響的部分語句，然后分析、歸納出作為Where條件子句的字段及其各種組合方式；在這一基礎上可以初步判斷出哪些表的哪些字段應該建立索引。其次，必須了解應用程序，要了解哪些表是數據操作頻繁的表；哪些表經常與其他表進行連接；哪些表中的數據量可能很大；數據量大的表中各個字段的數據分布情況如何等等。對于滿足上述條件的這些表，必須重點關注。因為建立在這些表上的索引，將對SQL語句的性能產生舉足輕重的影響。
2.2 使用索引的規則
索引的使用要恰到好處，其使用原則如下：
（1）在經常進行連接，但是沒有指定為外鍵的列上建立索引，而不經常連接的字段則由優化器自動生成索引。
（2）在主鍵索引方面，不應有超過25%列成為主鍵，而普通列很少，這會浪費索引空間。
（3）在條件表達式中經常用到的不同值較多的列上建立檢索，在不同值少的列上不要建立索引。
（4）在頻繁進行排序或分組（即進行group by 或 order by 操作）的屬性上建立索引。
（5）在作為最小值等聚集函數的屬性上考慮建立索引。
索引的建立、維護和使用都需要付出代價，應合理使用索引。錯誤的索引不會使數據庫性能得到預期的提高，往往還會產生一些負面影響。
3 SQL語句優化
要對查詢進行優化，一個簡單直接有效的方法是對SQL語句進行調整，減少計算量，提高查詢的效率。以下是一些書寫SQL的一些經驗。
3.1 避免相關子查詢
查詢嵌套層數每增加一層，查詢的效率成幾何級的降低。要想提高嵌套語句的執行效率，則應減少嵌套語句的嵌套的層次。所以在實際應用中，若可以用連接查詢代替的子查詢，則用連接查詢實現。
例：查詢選修了“3-105”號課程的學生基本信息
用子查詢的方法如下所示：
SELECT * FROM student WHERE SNO IN (SELECT sno FROM sc WHERE cno=’3-105’)
改寫成連接查詢如下：
SELECT student.* FROM student,sc WHERE stuent.sno=sc.sno AND cno=’3-105’
3.2 用UNION替換OR
合理建立索引有助于提高查詢效率。有時盡管在所有的檢索列上都有索引，但有些形式SELECT查詢語句可能不會促使查詢優化器使用索引，從而降低查詢效率。如果對查詢語句進行改寫，用UNION替換OR，可以強迫優化器按索引路徑處理。如：假定分別在“職工”關系中的“年齡”和“月工資”字段上創建了索引，對以下SQL語句
SELECT 姓名，年齡，月工資 FROM 職工 WHERE 年齡>45 OR 月工資
可替換為：
SELECT 姓名，年齡，月工資 FROM 職工 WHERE 年齡>45
UNION
SELECT 姓名，年齡，月工資 FROM 職工 WHERE月工資
3.3 使用臨時表優化查詢
在涉及相關查詢的某些情形中，構造臨時關系可以提高查詢效率。如：查詢每個部門中月工資最高的“職工號”
SELECT 職工號 FROM 職工 AS e1 WHERE 月工資=(SELECT MAX(月工資)FROM 職工 AS e2 WHERE e1.部門號=e2.部門號)
以上的查詢對于外層的職工關系e1中的每一個元組，都要對內層的整個職工關系e2進行檢索，因此查詢效率不高。可以構建臨時關系提高查詢效率。
SELECT MAX（月工資） AS 最高工資，部門號 INTO temp FROM職工 GROUP BY 部門號
SELECT 職工號 FROM 職工，temp WHERE 月工資=最高工資 AND 職工.部門號=temp.部門號
3.4 避免在索引列上使用計算
WHERE子句中，如果索引列是函數的一部分。優化器不使用索引而使用全表掃描。如
SELECT * FROM職工 WHERE 月工資*12>20000
可改為：
SELECT * FROM 職工 WHERE 月工資>20000/12
3.5 謂詞的等價變換
由于執行引擎對各種謂詞的處理方法不同，把邏輯表達式重寫成等價的且效率較高的表達式是提高效率的有效方法，同時也是切實可行的。針對執行引擎對各種謂詞執行效率的不同，總結如下謂詞轉換規則：
1）將BETWEEN轉化為AND 連接的謂詞
把BETWEEN．．．AND．．．形式改寫為用AND連接的兩個謂詞，效率往往
有一定的提高。
例如：月工資 BETWEEN 1000 AND 2000 改為： 月工資>=1000 AND 月工資
2）避免使用In語句
當查詢語句中有In關鍵詞時，優化器采用OR并列條件。
如：職工號IN (‘1001’,’2001’) 改為：職工號=’1001’ OR 職工號=’2001’
4 結束語
查詢處理是數據管理系統的核心，而查詢優化技術是查詢處理的關鍵技術。查詢優化就要抓住關鍵問題。在數據庫的開發和維護過程中，查詢優化設計可以提高系統的性能，尤其對于數據量大的數據庫系統最為重要。本文提到一些優化方法是根據自己的經驗，并查閱了大量的資料。在具體的使用時候要根據實際情況，才能合理制定出良好的優化方法，實現快速、高效的數據查詢。
參考文獻：
一、關系數據庫關鍵詞查詢概述
關系數據庫通常通過結構化查詢語言SQL來訪問。SQL訪問方式不但要求用戶知道并理解關系數據庫模式,也要懂得書寫復雜的SQL查詢語言,因此,它一般適合于專業用戶使用。普通用戶一般通過定制的關系數據庫查詢接口程序RQI(Relational databases Query Interface)或者關系數據庫應用程序RAP(Relational databases Application Program)來訪問關系數據庫。RQI訪問方式雖然不要求用戶書寫復雜SQL查詢語言,但是要求用戶知道并理解關系數據庫模式,對于不同的關系數據庫需要使用不同的RQI,而且定制的RQI也往往不能滿足靈活多變的用戶查詢需求,當RQI不能滿足用戶查詢需求時,就需要應用開發人員來修改RQI,由此,使用RQI訪問方式則需要較高的開發費用和維護費用。
隨著Internet和Web技術的快速發展和應用,一方面用戶越來越習慣于使用簡單的查詢關鍵詞通過Web搜索引擎如Google,Baidu等來搜索信息;另一方面,越來越多的關系數據庫到Web上面向廣大普通用戶,形成所謂的“Deep Web”問題,使得普通用戶也期望能夠使用簡單的關鍵詞來查詢關系數據庫數據。
二、相關定義
定義1:關系數據庫模式Sdb(Relational Database Schema)假設關系數據庫的模式,Sdb=(R,FK),R={R1,R2,…,Rk}是一組關系模式,FK是R中關系模式間引用關系的映射,FK:RR,如果FK(Ri)=Rj,記為RiRj(1≤i,j≤n),它表示Rj一個外鍵引用了Ri主鍵。
定義2:關系數據庫模式圖Gs(Relational Database Schema Graph)假設Gs=(V,E)表示模式Sdb=(R,FK)的關系數據庫對應的模式圖。Gs是一個有向圖,將關系數據庫中的每一個關系模式Rk(1≤k≤n)看作是Gs的一個節點,當且僅當關系模式Ri∈Gs,關系模式Rj∈Gs,(RiRj)∈FK時,(Ri,Rj)∈E。
定義3:連接元組樹Jt(Joning Tree of Tuples)給定一個關系數據庫的模式圖Gs=(V,E),Jt是以數據庫中的元組tl為結點的一棵樹,其中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)把關鍵詞查詢定義為查詢函數f:KqT,其中Kq是一個集合,其元素ki(1≤i≤m)為關鍵詞,T是一個集合,其元素Jti(1≤i≤n)為一個關鍵詞查詢結果。
定義5:關鍵詞查詢結果T(Keywords Qeury Results)關鍵詞查詢結果是OR語義,Kq是一個集合,其元素為ki(1≤i≤m)為關鍵詞,一個查詢結果是至少含有Kq中一個ki(1≤i≤m)且每個葉結點都至少含有Kq中一個ki(1≤i≤m) 的連接元組樹。
關鍵詞查詢結果是AND語義,Kq是一個集合,其元素為ki(1≤i≤m)為關鍵詞,一個查詢結果是Kq中的每一個的關鍵詞ki(1≤i≤m)都必須出現在結果中,并且每個葉子節點都至少含有一個Kq中的關鍵詞ki(1≤i≤m)的連接元組樹。
三、體系結構
(1)系統設置系統啟動模塊,做一些系統初始化工作,如系統的參數配置
(2)模式圖生成器從系統配置文件讀入數據庫模式圖的模式配置信息,生成數據庫模式圖。
(3)用戶查詢該模塊為用戶查詢接口,接受用戶輸入的查詢關鍵詞,
提交后續模塊處理。
(4)元組集生成器該模塊利用由關系數據庫的全文檢索功能建立的IR引擎,將關系數據庫中具有文本屬性的每個關系生成元組集,只有那些與某個查詢關鍵詞或者查詢關鍵詞組合相關的非空的元組集保留下來,稱為非自由元組集,每個非自由元組集都是其源表(即生成該元組集的表)的一個子集,每個非自由元組集實際上也是一個臨時表,繼承其源表的主外鍵關系。
(5)候選網絡生成器候選網絡生成器利用元組集生成器生成的非自由元組集擴展模式圖,形成元組集圖,然后對該元組集圖進行擴展,生成結點不超過預定最大允許結點數的候選網絡。所謂候選網絡,也稱元組集連接樹,也是可以看做是要用來產生關鍵詞查詢潛在結果的JOIN表達式。
(6)候選網絡執行器候選網絡執行器完全執行所有候選網絡得到全部結果,或者采用某種top-k算法執行候選網絡,以得到top-k查詢結果。
四、查詢處理
系統啟動時,首先會生成數據庫模式圖,這個過程非常短,然后系統接收到用戶提交的查詢關鍵詞。當用戶提交查詢關鍵詞時,元組集生成器利用IR引擎生成元組集,然后,候選網絡產生器利用非自由元組集擴展Gs生成元組集圖,廣度優先遍歷元組集圖生成候選網絡,最后,候選網絡執行器執行全部候選網絡。或者采用某種top-k查詢算法執行候選網絡,生成最終查詢結果返回給用戶。通過介紹SDSG系統,可以發現SDSG系統存在的優點:數據庫模式圖占用內存少;缺點:候選網絡產生器執行效率低、候選網絡執行效率低、缺少語義查詢。
參考文獻
[1] 施伯樂,丁寶康,汪衛.數據庫系統教程.第二版.高等教育出版社,2003:1-359
2）德克薩斯大學的Sunitha Ramanujam提出了“Bi-directional Translation of Relational Data into Virtual RDF Stores”[5]，即關系數據和RDF間的雙向轉換，并在D2R的基礎上開發了工具D2RQ++。
3）中科院國家科學圖書館成都分館的Shihan Yang等人提出“半自動化地從關系數據庫中構建本體”，文中提出了利用中間件來實現關系數據庫到本體轉化的方法，并且提出了W-graph的中間件語言，W-graph映射語義使用與關系數據庫和本體都無關的雙向模擬等價圖表示。中間件模式是動態的，當數據庫模式或本體頻繁變化時，該方法因此有很好的適應性。此方法不僅可以處理數據庫模式而且也可以處理數據庫中存儲的實例。圖形語義編輯工具的開發，提高了方法的可用性。
4）許卓明提出 “一種從關系數據庫學習OWL本體的方法”，開發出了關系數據庫模式到OWL本體轉換原型工具DB2WO，并給出了實例驗證。該研究首先給出了關系數據庫模式和OWL本體的定義，其次定義了關系數據庫模式到OWL本體的一組映射規則，然后開發了轉換工具DB2WO。關系數據庫模式信息通過讀取關系數據庫字典來提取。
5）陳和平等人提出“基于關系數據庫的本體生成器的設計與實現”[6] 。該研究中首先指出需要解決的2個關鍵問題：（1）如何提取關系數據庫的ER模式（2）如何定義由ER模式到OWL本體的映射規則。然后給出ER模式的提取一般可以通過查詢該關系數據庫的數據字典或應用數據庫的逆向工程工具，接著給出了ER模式到OWL本體的10多條轉化規則。最后，給出了本體生成器OWLFROMDB的功能模塊結構圖，并給出了實例驗證。
6）中國人民理工大學的Peng Liu等人在2010第九屆國際網格和云計算會議提出“基于關系數據庫的本體自動構建”[7]。其思想跟前述許卓明、陳和平等一致：通過分析關系數據庫模式，建立一系列的從關系數據模式到OWL的轉換規則，然后給出了算法和流程圖，最后給出了生成的本體的層次圖。
7）W3C成立了 RDB2RDF研究組，致力于提供一個從關系數據庫RDB到本體描述語言RDF的規范性的映射標準，到目前為止，該研究小組提出了幾個關于RDB到RDF映射語言的內部草稿，還未成為標準。
3 研究瓶頸及建議
現在，基于關系數據庫生成本體的研究已經引起越來越多研究者的興趣。基本思路無非是從關系數據庫中提取出數據模式，然后設定數據模式轉化為本體的規則，然后編程實現。每個研究人員都提出了自己的轉化規則，而并沒有人對規則的可行性給出評價結果。至今，尚未有研究者或機構給出權威的轉換規則。轉換規則的可行性和合理性應該是未來研究的重點。
4 結束語
利用關系數據庫中結構化的數據作為數據源來構建本體的方法，已經引起了眾多研究人員的重視，而隨著W3C的介入， 必將使這種轉換規范化。
參考文獻：
[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.
關鍵詞：關系數據庫 關鍵詞查詢 數據庫索引
1 系統總體設計
人們在求解一個復雜問題時，通常采用的是逐步分解、分而治之的方法。也就是把一個大問題分解成若干個比較容易求解的小問題，然后分別求解。設計一個復雜的系統時，往往也是把整個系統劃分為若干個功能較為單一的功能模塊，然后分別予以設計、實現，這就是模塊化設計。本系統也采用這種模塊化設計方式。
■
圖1 面向關系數據庫關鍵字查詢系統框圖
2 數據庫設計
本系統為面向關系數據庫的關鍵字查詢系統，在實驗中本文選取了IMDB 數據集，為了進行實驗，將數據集整理為以下七個表數據結構。
實驗數據集（電影信息數據庫）：
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 數據庫索引設計
由于關系型數據庫對于文本屬性上全文索引的支持，所以在文本屬性可以直接利用數據庫中的全文索引。對于給定的關鍵字k，全文索引能檢索出查詢關鍵字所在位置。
對于數據庫中的表屬性，構建索引的方式比較簡單，依賴于DBMS的IR索引。對于數據庫中具有文本屬性的列，在該列上建立全文索引。在進行關鍵字查詢時，對于給定的關鍵字，通過數據庫的全文索引，會返回包含該關鍵字的元組集合。
在進行關鍵字查詢的時候，對于用戶給定查詢關鍵字，系統首先要對給定的關鍵字進行定位，確定關鍵字所匹配的信息是模式項還是數值項。
例如，關鍵字{“Color”“Director”}的索引結構如表1所示。
表1 關鍵字{“Color”“Director”}的索引結構
■
4 關鍵字檢索設計
在搜索引擎行業，所謂關鍵字，就是用戶在使用搜索引擎時輸入的、能夠最大程度概括用戶所要查找的信息內容的字或者詞，是信息的概括化和集中化。關鍵字檢索作為一種易于使用的檢索方式，為大量普通用戶所喜愛。本文從關鍵字個數角度介紹現有的關鍵字檢索技術中最常見的單關鍵字查詢和多關鍵字查詢這兩種關鍵字檢索形式。
5 結果生成設計
在本文中，將查詢結果定義為元組連接樹。
元組連接樹（Joined Tuple Tree）是給定一個數據庫模式圖GS，一個元組連接樹T是一棵元組樹。其中，T中的每一條邊（ti，tj）（ti∈Ri，tj∈Rj）滿足以下兩個要求：
①（Ri，Rj）∈RS，
②ti∞tj∈Ri∞Rj。
同時這些元組連接樹滿足以下條件：
①完整性：用戶提交的所有關鍵字均出現在元組連接樹上;
②最小性：從元組連接樹中移除任何元組后的元組連接樹都不具有完整性。
6 結束語
通過分析相關檢索系統的實現策略，設計了支持關鍵字檢索的系統架構和核心構成組件，主要包括數據庫索引、數據庫模式圖、關鍵字檢索和結果生成。
參考文獻：
中圖分類號：TP391
文獻標識碼：A 文章編號：16727800（2014）002012703
0引言
工作流是公文流轉系統的重要組成部分，不同于一般概念上的工作流，公文流轉中的工作流具有自身特點和要求。本文提出的公文工作流模型基于關系數據庫，降低了業務系統與公文流轉系統集成的復雜度，減輕了復雜工作流引擎帶來的系統負擔，使公文流轉系統能夠適應不同的公文業務需求。
1工作流技術
通常把工作中具有固定程序的活動集合叫做工作流。它把工作活動細分成定義良好的角色、任務、過程和規則來完成工作的監控和執行，從而提高了工作效率和生產組織水平。國際工作流管理聯盟（Workflow Management Coalition，WFMC）對工作流的概念進行了定義[1]：工作流是指在計算機支持下的整個或部分經營過程的全自動或半自動化。通常，工作流由計算機軟件系統控制其執行。它包括一組活動以及活動之間的順序關系、一系列過程和對每個活動的具體描述以及活動的啟動和終止條件。通過分離應用邏輯和過程邏輯，可以在只修改過程模型而不修改具體功能的前提下改變系統功能，實現對生產經營過程部分或全部的自動化管理，合理、有效地把人、應用和信息組織在一起，實現了“在合理的時間把適當的信息傳遞給正確的人”的要求。
2公文流轉工作流
2.1公文流轉工作流定義
WMFC 給工作流做出了如下定義： 按照事先定義好的規則，文檔、任務或者信息在參與者之間進行傳遞，從而完成整個業務過程的自動化處理。依據公文流轉的特點，公文流轉中的工作流包括如下4 個要素： 多人參與、同一個業務目標、每個參與者通過動作來完成自己的任務、按照一定的順序和規則傳遞。公文流轉通過多個參與者完成的一系列任務達到業務目標。由工作流的要素可知，在定義公文流轉中的工作流時應考慮以下5方面定義：傳遞的公文文檔定義、角色定義、活動定義、路線定義和事件定義。下面用一個公文流轉過程來描述和定義公文流轉中的工作流 [2]，如圖1 所示。
（1）活動節點：實際上代表了組成一個實際過程所需要的任務，包括不可分割的原子級任務和套嵌的公文工作流過程。公文工作流主要依靠流轉過程中各個節點的實現來達到公文流轉的目的。
（2）事件節點：主要是用于確認流程是否推動，如果滿足條件則流程繼續，否則繼續等待。
（3）控制節點：用于控制相鄰活動節點的先序關系。控制條件一般在活動中定義，由繼續流轉條件、停止流轉條件、退改條件組成。繼續流轉條件表示進入這個活動，是這個活動被激活的前提或準備條件；退改條件表示如果活動沒有滿足某個特定條件，則重復執行，一直到滿足繼續流轉條件為止。
2.2公文流轉工作流分析
2.2.1公文流轉工作流程
按照公文流轉中節點處理的時間先后順序，可以把工作流程分為串行和并行兩類。串行流程中所有節點呈“一”字型排列，后一個節點的啟動時間為前一個節點的完成時間；并行流程中兩個或者兩個以上節點并排排列，節點可在同一時刻工作。典型的串行流程和并行流程如圖2（a）和圖2（b）所示。
一般情況下，并行流程和串行流程的各種不同組合構成一個復雜的公文流程，如圖2（c）所示。
2.2.2公文流轉并行工作流程
傳統意義上的紙制公文只有一份，在同一時間只能交給一個人來處理，因此不會有流程分支的情況。公文電子化后，突破了紙制公文只有一份的限制，使流程分支成為可能。但是，公文系統業務要求保留每個處理過程的修改痕跡，如果將同一份電子文檔交給多人同時修改，不僅會造成文檔修改時的邏輯混亂，也會帶來文檔的存取問題。同一時間一份文檔只能交給一個人處理和修改，某一用戶處理和修改文檔時，文檔是被鎖的，其它用戶要使用此文檔，必須等到該用戶處理完畢。針對以上問題，本文提出了文檔版本的思想來實現公文流轉中的并行工作。
用戶A對公文擬稿后，點擊提交按鈕，進入公文流轉流程，流程流轉到步驟2。此時，系統自動在工作流表中插入一條記錄，FLOW_STATE狀態為1，表示流程正在流轉，公文電子文檔被保存到公文文檔表中。同時在工作流步驟表中插入步驟1和步驟2兩條記錄：步驟1為文件起草，FLOWSTEPS_STATE為2，表示公文已處理；步驟2為B處理過程，FLOWSTEPS_STATE為1，表示公文待處理。在工作流人員表中插入對應步驟1和步驟2的兩條記錄：步驟1的執行者為A，FLOWPERSON_OPTION字段為提交；步驟2的執行者為B， FLOWPERSON_OPTION字段為未知，表示還未處理。在工作流事件表中插入步驟1的執行事件，事件為提交。流程流轉到步驟2后，B用戶可選擇的事件有同意、退還、否決。如果B用戶同意，則流程進入步驟3，在工作流步驟表中插入步驟3的記錄，同時把步驟2的狀態改為2，步驟3的狀態標為1。在工作流人員表中插入步驟3的執行者記錄為C，同時更改B的FLOWPERSON_OOPTION為提交。如果用戶B退還，則流程回到步驟1，同時刪除步驟1后的所有記錄，把步驟1的狀態改為1，表示公文待處理。如果用戶B否決，則流程終止流轉，并把公文流轉表中的FLOW_STATE改為終止。
4.2同一任務多人處理策略
在同一任務多人處理流程中，一個任務可能需要多個執行者參與，沒有明確的先后順序（即并行流程）。某任務的多人處理流程如圖6所示。
用戶A對公文擬稿后，點擊提交按鈕，進入公文流轉流程，流程流轉到步驟2。此時判斷出步驟2的任務為兩個人處理，在工作流人員表中對應于步驟2插入兩條記錄，執行者分別為B和C，同時生成文檔版本b和文檔版本c，存入公文文檔表，分別由FLOW_ID、FLOWSTEPD_ID和FLOWPERSONS_ID三個字段進行約束。待用戶B和C都提交后，流程流轉到步驟3。 D用戶綜合B和C的修改意見，生成版本d。
4.3系統實現
本文采用以上技術，研制開發了一套以公文流轉為核心的辦公自動化系統。該系統基于B/S結構，以IIS 為Web服務器。系統的開發平臺為ASP. NET，關系數據庫為Oracle9i，通過數據模型實現對數據庫的訪問。系統界面如圖7 所示。
5結語
本文提出了一種基于關系數據庫的公文流轉系統實現方法，采用與其它業務系統相一致的主流數據庫將工作流及公文數據存儲在結構開放的關系數據庫中，大大降低了公文流轉系統與其它業務系統集成的復雜度，同時減輕了復雜工作流引擎帶給系統的負擔。
參考文獻：
