前言：中文期刊網精心挑選了關系數據庫范文供你參考和學習，希望我們的參考范文能激發你的文章創作靈感，歡迎閱讀。
關系數據庫范文1
【關鍵詞】關系數據庫；數據倉庫；數據挖掘；關系
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 關系數據庫、數據倉庫與數據挖掘的融合
日常事務處理需要關系數據庫，構建分析處理環境需要數據倉庫，幫助決策者尋找數據之間的潛在的關聯需要數據挖掘。他們之間是相互聯系又有區別的，不能互相取代的，又需要相互融合。數據倉庫中的數據并不是最新的，專有的，而是來源于其他關系數據庫，它是建立在一個更全面和完善的信息應用的基礎上，用于支持高層決策分析的數據基地。數據倉庫是數據庫新技術，到目前為止，數據倉庫仍用關系數據庫管理系統管理數據。數據挖掘是從大量存儲在數據庫、數據倉庫或其他信息庫中發現有趣知識的過程。只有這三個數據庫技術互相融合，取長補短，各盡其責，才能更好的為廣大用戶所使用，為社會各個領域所應用。
【參考文獻】
[1]華冠萍.數據倉庫、數據挖掘及OLAP之兩兩關系[J].福建電腦，2007，8.
關系數據庫范文2
關鍵詞:關系數據庫;云端數據庫;Bigtable;時間戳
中圖分類號: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.
[5] Dean J,Ghemawat S.MapReduce:Simplified data processing on large clusters.In:
關系數據庫范文3
>> 基于關系數據庫的本體構建方法研究 面向關系數據庫的裝備領域本體構建研究 基于對象關系數據庫的移動對象數據庫管理系統的研究 基于UML模型的關系數據庫設計 基于關系數據庫的XML存儲技術 基于．NET平臺的關系數據庫轉換 基于架構的關系數據庫與云端數據庫比較分析 基于關系數據庫的關鍵詞查詢研究 基于關系數據庫的時態XML存取研究 基于關系數據庫的動態工資管理系統研究 基于關系數據庫的文件樹存儲策略研究 基于關系數據庫的可適性系統研究 基于DOM的XML文檔到關系數據庫的數據轉換方法 基于關系數據庫的實時XML數據查詢處理 淺談關系數據庫的數據保護策略 一種基于依賴關系的關系數據庫語義模式提取方法 關系數據庫查詢優化策略研究 關系數據庫查詢優化策略與研究 XML文檔與關系數據庫數據轉換的研究 WebService在LDAP與關系數據庫之間數據同步的研究 常見問題解答 當前所在位置：），但該工具只能創建輕量級本體，映射簡單，不能完全地對關系數據庫中存在的概念進行建模。
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 研究瓶頸及建議
現在，基于關系數據庫生成本體的研究已經引起越來越多研究者的興趣?；舅悸窡o非是從關系數據庫中提取出數據模式，然后設定數據模式轉化為本體的規則，然后編程實現。每個研究人員都提出了自己的轉化規則，而并沒有人對規則的可行性給出評價結果。至今，尚未有研究者或機構給出權威的轉換規則。轉換規則的可行性和合理性應該是未來研究的重點。
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.
[5] Shihan Yang,Ying Zheng.Semi-Automatically Building Ontologies from Relational Databases[J].IEEE,2010:150-154.
關系數據庫范文4
關鍵詞：關系數據庫；關系模型；數據查詢；多表查詢
中圖分類號：TP311.52
關系數據庫是基于關系模型作為數據的組織方式的，它借助于集合代數等數學概念和方法來處理數據庫中的數據?，F實世界中的各種實體以及實體之間的各種聯系均用關系模型來表示。它是由埃德加?科德于1970年首先提出的，并配合“科德十二定律”?，F如今雖然對此模型有一些批評意見，但它還是數據存儲的傳統標準。標準數據查詢語言SQL就是一種基于關系數據庫的語言，這種語言執行對關系數據庫中數據的檢索和操作。
1 數據查詢
所謂數據查詢（數據檢索）就是從關系數據庫的數據表中找出用戶所需的數據，只要表（關系）中存在，則可以通過各種各樣的方式將它找出來，SQL的查詢功能就是實現這一功能的。本文主要研究討論多表查詢。
在實際應用中，由于一個關系數據庫根據需求分析后得到很多表，而且表與表之間互相存在一對一，一對多或是多對多的表間關系，這些表中的數據往往互相有較為緊密的復雜聯系，在這種情況下，要查找用戶所需的數據時就得用多表查詢才能實現用戶的查詢目的和要求，比如在倉庫數據庫中分別有四張表，倉庫表，職工表，訂單表和供應商表，這四個表兩兩存在一對多的表間關系，一個倉庫可以有多名職工，一名職工只能屬于一個倉庫；一名職工可以經手多筆訂單，一筆訂單只能由一名職工經手；一家供應商可以完成多表訂單，一筆訂單只能由一家供應商完成，在實際應用中，如果要根據倉庫表中的數據作為條件查詢檢索供應商表中的數據時，必須得用基于多表的連接查詢才能完成。
1.1 簡單連接查詢。簡單連接查詢的SQL語句格式可總結如下。Select from 注：連接條件是兩個表的主外鍵相等，主表表名.主鍵=子表表名.外鍵 如：倉庫表.倉庫號=職工表.倉庫號。
如果from后面跟兩張表，則是兩個表的簡單連接查詢，有一個連接條件，如果from后面跟三張表，則有兩個連接條件，如果from 后面跟四張表，則有三個連接條件，依此類推。而且查找數據的條件和連接條件必須用and連接，連接條件之間也用and連接。
示例：在倉庫管理數據庫的四張表中檢索出回民所在倉庫的倉庫信息。對應的SQL語句為：select 倉庫表.* from 倉庫表，職工表 where 民族=’回’ and 倉庫表.倉庫號=職工表.倉庫號。
從這個簡單連接查詢實例來看。在基于多表的簡單連接查詢中，第一先確定最終要查詢的數據所在的字段來自于幾張表的幾個字段，查找數據的條件涉及到幾個表的幾個字段，其次根據表間關系確定查詢涉及到幾張表，然后確定連接條件。且where是必選項。
1.2 嵌套查詢。嵌套查詢的意思是，一個查詢語句（select-from-where）塊可以嵌套在另外一個查詢塊的where子句中，稱為嵌套查詢。其中外層查詢也稱為父查詢或主查詢。內層查詢也稱子查詢或從查詢。嵌套查詢的工作方式是：先處理內查詢，由內向外處理，外層查詢需要內層查詢的結果來支持，但內層查詢不需要外層查詢的支持。示例：Select城市from倉庫表where倉庫號in（select倉庫號from職工表where工資=4532）。
在這類嵌套查詢中，帶有IN或ONT IN謂詞的嵌套查詢在實際應用中用的最多，這里的IN相當于集合運算符∈。本文在闡述嵌套查詢中就以帶有IN或NOT IN謂詞的嵌套查詢進行闡述，帶有比較運算符的子查詢、帶有ANY或ALL謂詞的子查詢、帶有EXISTS謂詞的子查詢就再不做詳細闡述了。
1.3 超連接查詢。超連接查詢分為內連接和外連接，外連接又分為左外連接，右外連接和全外連接。如果表中不匹配的數據不需要出現在查詢結果中，則用內連接。如果在查詢結果中兩個表中不匹配的數據都要出現在查詢結果中的話，則用全外連接，其對應表中對應字段用NULL表示。其SQL語句格式為（以基于兩張表的超連接為主）：Selectfrom on [where 查找數據的條件]。示例（以全外連接為例）：select倉庫.倉庫號，城市，面積，職工號，工資 from 倉庫表 full join職工表 on 倉庫表.倉庫號=職工表.倉庫號JOIN連接格式在連接多個表時的書寫方法要特別注意，在這種格式中JOIN的順序和ON的順序正好是相反的。
2 三種多表查詢的特點及規律
在以上研究的三種多表查詢中，基于多表的簡單連接查詢中，要查詢的數據所在的字段可以是來自于一張表的字段，也可以是來自于多張表的字段，而查找數據的條件可以來自于一張表的字段，也可以來自于多張表的字段，即使沒有查找數據的條件，但連接條件必須得有，在其SQL語句格式中，where是必選項。
在嵌套查詢中，通過實際應用可以得出，嵌套查詢不管由幾個查詢語句塊組成，它們都是基于單表的簡單查詢構成的，而且最內層的查詢結果就是其外層查詢的條件，沒有內層查詢的結果，就不可能得到外層查詢的結果，執行順序都是由內往外執行的。
在超連接查詢中，這種查詢往往是在有關系的表中出現了所謂的不匹配數據時，根據用戶的不同需要而使用的查詢，到底選用哪一種主要取決于查詢結果中要不要出現不匹配的數據和出現哪個表中的不匹配數據而定。
如果要查找的數據來自于多張表的多個字段，則可用連接查詢和內連接查詢，查詢結果相同。如果要查找的數據來自于一張表的字段，而條件發生在不同的表中，則可用連接查詢，嵌套查詢和內連接查詢，查詢結果相同。
3 結束語
SQL的查詢功能，尤其是多表查詢有很大的靈活性，在實際應用中要視具體情況來決定用哪一類，這需要在實踐中摸索總結，只有這樣才能對SQL語句的查詢功能運用的得心應手。
參考文獻：
[1]薩師煊.王珊.數據庫系統概論（第三版）[M].北京：高等教育出版社，2000.
[2]賀桂英.數據庫原理及應用―SQL Server 2008[M].北京：中國人民大學出版社，2013.
關系數據庫范文5
【關鍵詞】關系數據庫 計算機 網絡設計 應用 優越性
信息時代的到來，為計算機網絡技術的發展提供了一個新的發展機遇，在人們的生產與生活中發揮著重要的作用。近年來，我國對計算機網絡技術的發展給予了高度的關注，并投入大量的人力、物力支持，使計算機網絡技術得到了充分的發展。然而由于我國計算機技術起步較晚，且對計算機技術的應用還不夠成熟，因此，必須采取吸收并借鑒國內外先進技術，促進計算機網絡設計的成熟與發展。
1 關系數據庫概述
計算機網絡設計離不開對數據庫的輔作用，它能夠提高計算機應用軟件的有效性，對一些重要的信息及數據進行科學的管理。近年來，計算機網絡規模實現了一系列的壯大，數據及信息量也有所增長，這就對數據庫提出了更高的要求。新時期，關系數據庫技術的提出引起了社會各界的廣泛關注。它是在傳統數據庫技術的發展基礎上，對計算機網絡設計起到輔作用的一種新型技術。在關系數據庫技術的發展初期，還只是對一些簡單的表格進行數據處理與分析，從而形成一個完善的數據庫系統，不僅便于儲存，而且使處理后的數據能夠一目了然，一旦需要某一方面的數據，便能夠通過簡單的調度來實現，具有無限的優越性。
2 關系數據庫技術在計算機網絡設計中的應用原理
計算機網絡技術發展至今，也包含了豐富的內容與類別。但從計算機的數據庫技術來說，就能體現計算機技術的豐富性與多樣性。首先，數據庫技術在發展過程中包含了多個種類。而關系數據庫作為其中最為先進的一種數據庫技術，它能夠對數據進行連接，具有極強的適應性。在計算機網絡技術中得到了廣泛地應用。一般情況下，計算機網絡數據是相對獨立的，在實際的操作與處理過程中，關系數據庫能夠將與之相關的任意計算機數據進行相互關聯，對這些數據進行統一處理與分析，數據處理的范圍比較廣，綜合性比較強，滿足了計算機數據的多樣性與豐富性的要求。目前，大多數的計算機網絡設計都將關系數據庫作為日常數據處理與分析的首選，體現出其在計算機網絡技術中的優越性。關系數據庫是一種相對獨立的數據庫技術，它有著自己專門的信息管理平臺，一般情況下可通過網絡編程語言實現與客戶的信息交流與共享，具有全面性與便利性的特征。計算機數據庫系統主要包括數據庫的連接與訪問對象，兩者相互獨立，分別向客戶提供信息共享與交流。對與使用者來說，則可以通過C語言獲取數據庫信息，并能夠實現交流。
3 關系數據庫技術在計算機網絡設計中的優越性
3.1 數據存儲功能性強
關系數據庫在計算機網絡設計中具有明顯的應用優勢。其中最為突出的一點就是，關系數據庫能夠對大量計算機數據進行科學儲存。當今的計算機網絡設計的不斷發展，在各行各業中的應用也更加普遍，因此，其所包含的內容與容量也不斷擴大，這對計算機的數據存儲功能來說是一個巨大的挑戰。關系數據庫作為一種先進的數據庫技術，能夠對計算機網絡設計中所包含的大量的數據進行存儲，并利用獨立的數據信息管理平臺，對這些數據信息進行綜合的科學分析與管理，為計算機網絡技術設計諸如了新的活力與生命力，這也在一定程度上提高了網絡設計的效率。計算機操作人員可借助關系數據庫的強大儲存功能，在實際的計算機網絡操作中，收集、整理數據參數，進而進行快捷的數據處理與分析，對計算機網絡技術設計起到良好的輔作用。數據信息的管理是計算機網絡設計面臨的一大問題，而關系數據庫技術的應用能夠有效保障計算機網絡設計的存儲功能，促進計算機網絡系統職能的有效發揮。
3.2 數據轉換簡單、快捷
目前，關系數據庫還有效的促進了計算機網絡設計中數據的轉換功能。大多數的計算機網絡設計工作，不可避免地會涉及到社會生產活動的各個方面，這就要求計算機網絡能夠實現不同數據之間的轉換，促進計算機網絡設計的軟件系統正常運行。因此，對不同數據的轉換工作成為計算機網絡技術發展的重中之重。關系數據庫具有關聯性的特點，它能夠從不同的數據信息中發掘其存在的共同特征，并為此建立起一定的聯系，保障各類數據之間的相互轉換，對計算機網絡設計中的復雜問題達到有效的解決。一旦數據轉換問題得到了解決，那么計算機網絡設計在日常運行中便能夠起到良好的作用與效果。需要注意的是，在進行信息存儲時，要優先選用應用范圍比較廣的數據，確保計算機網絡設計對數據及信息的不同需求，進而保障計算機網絡設計順利進行。
4 結束語
隨著我國社會主義現代化建設的不斷發展，計算機網絡技術已成為人們日常生活與工作中重要的組成部分，這對計算機網絡技術設計來說是一個巨大的挑戰。因此，要抓住當前的發展機遇，充分利用先進的關系數據庫技術，使其為計算機網絡技術設計提供必不可少的支持，促進計算機技術的進一步發展。
參考文獻
[1]孫睿.關系數據庫技術在計算機網絡設計中的運用[J].網絡安全技術與應用，2014，12：41-42.
關系數據庫范文6
關鍵詞；工作流；活動；UML；數據庫
引言
辦公自動化（office automation，簡稱OA）建設不僅要重視信息的充分共享，而且更強調各方面相互之間的協作，這種協作關系是通過工作流技術實現的。國際工作流管理聯盟WMFC（WorkflowManagement Coalition）給出如下的工作流定義；文檔、信息或者任務按照定義好的規則在參與者之間傳遞，從而完成整個業務目標的自動化處理過程。在部隊信息化建設中，工作流代表了部隊信息化試點中辦公環境的工作過程，包括一組活動及它們的相互順序關系，還包括過程及活動的啟動和終止條件，以及對每個活動的描述。在應用上，工作流的定義、執行、監控需要一套工具，稱之為工作流管理系統?？紤]到部隊信息化試點工作流管理系統需求的復雜多變，因此，工作流管理系統應該具有良好的擴展性和可重用性。
1工作流管理系統的設計相關術語
?業務流程（Business Process）；在具有組織機構功能的組織結構中，能夠實現業務目標和策略的相互連接的過程和活動集合。
?過程定義（Process Definition）；業務流程的形式化描述，用來支持系統建模和運行過程的自動化。過程可分解為一系列子過程和活動，其定義包括描述過程的起始、終止的活動關系網絡以及一些關于個體行為的信息，具體而言，即構成過程的各個活動及其各活動的關系、組成成員的角色、應用中的數據結構等。
?活動（Active）；實現過程邏輯步驟的工作任務的描述，一般分為手動操作和自動處理兩類?；顒邮沁^程執行中可被工作及調度的最小工作單元，要求有人或者機器的參與。
?過程/活動實例（Process/Active Instances）；實際運行中的一個過程活著活動、它們是以業務流程的過程定義或活動為模板創建的。每個實例代表一個能獨立控制執行，具有內部狀態的線路，可被外界通過標識進行讀取。實例是真正執行的工作流。
工作流管理系統（workflow management sys-tem）是定義、管理并根據預定義邏輯執行工作流的系統，其核心是工作流引擎（workflow engine），提供流程的創建、管理和執行功能。引擎的執行又是以工作流定義數據、控制數據和應用相關數據為根據的，因此，要設計一個工作流管理系統首先必須給出數據模型。一般包括三節階段；模型建立階段、模型實例化階段和模型執行階段。
模型建立階段，利用工作流建模工具，將信息化試點的工作過程轉換成計算機可以處理的工作流模型。
模型實例化階段，完成每個過程定義所需要的參數，分配每個活動執行所需要的資源。
模型執行階段，完成實際工作流實例的執行。
2工作流引擎的數據模型建立
2.1工作流分析
正確描述工作流動態流轉的過程，應考慮動態流轉中的參與者、流轉戒指、任務的執行和任務轉移路線等。UML提供的活動圖可以用于工作流程的建模，活動圖包括活動狀態和動作狀態，活動狀態表示過程中命令的執行和工作流中活動的進行，動作狀態與活動狀態類似，但是它是原子活動，一個活動狀態可能被分解為多個動作狀態?？梢园凑找欢ǖ目刂平Y構轉移活動狀態，活動圖提供了順序流控制結構，用分叉和結合表示控制結構，分支和合并表示根據條件轉移的活動。
任何工作流系統必須能夠處理WFMC定義了五種工作流原語，原語系統歸納了業務過程中通常出現的共性流程模型，對應活動圖順序流和并發流的控制結構。
2.2設計思路
工作流引擎的設計應分別考慮數據模型和功能模型。根據WFMC標準，數據模型包含組織機構模型和信息模型，而功能模型則包含工作流引擎和五類標準接口。
組織機構模型；組織機構模型通常為樹狀的層次結構，定義了工作過程中各項活動的參與者和所屬部門，在一個工作流過程中，具體的一個人是沒有意義的，必須給定確定的角色。
信息模型存儲對工作流程的描述和具體工作實例的運行信息，因此，將模型分為工作模板和工作實例兩部分。工作模板用于定義工作流程，工作實例是工作模板的實例化。
組成工作流的每個執行單元稱為活動（Activity），每個工作都是由一系列相互關聯的活動組成的，這些相互關聯構成了活動路由信息。一個工作實例可以看作是以系列具體工作和它們之間的邏輯關系構成的一個有機整體。
每個工作流實例都有一個創建者，他是啟動此工作的人。
每個活動都有一個擁有者，他是活動的執行者。
活動有六種類型；開始活動、結束活動、人工活動、虛活動、同步活動、決策點。開始活動表示工作的開始，結束活動表示工作的結束。虛活動表示不需要人員參與的活動，在進行了一定處理之后系統自動轉入后續活動。同步活動把多個邏輯分支同步到一個節點，用于后續實現工作流原語中的“分叉與結合”。
兩個活動之間的轉換有三種類型；無條件、有條件和數據。無條件轉換表示前面節點結束后必須啟動后面的節點；有條件轉換是指前面節點結束后有條件轉入后面節點；數據轉換表示前面節點的輸出數據作為后面節點的輸入數據。
工作流實例的狀態有初始、運行、掛起、激活、終止、完成?；顒訉嵗臓顟B有運行、掛起、激活、終止、完成。由工作流服務組件負責狀態之間的轉換。
2.3數據模型
根據上述分析給出了實體關系模型，限于篇幅，很多細節省略了。
工作流定義；靜態定義工作流的主要信息。包括自動生成的工作ID、工作流名稱、工作流類型（自動型和人工型，自動型不需要人工參與，由工作流引擎自動執行）、工作流生命周期（每個工作流在該期限內還沒完成直接死亡）。還包括兩個重要的方面；一是工作流附件，包含了工作流運行過程中的一些信息，例如請假申請工作流中的請假申請表，公文流轉中的word形式的公文；二是工作流流程描述，包含了若干活動（Activity），這些活動通過一定的順序組織。
工作流附件；靜態定義了附件ID、工作流ID、附件名稱、附件類型。
工作流流程；靜態定義了工作流的流程由若干活動組成，包括了所屬工作流ID、活動名稱、崗位ID（定義了操作該活動的崗位）、上一個活動、下一個活動。
工作流實例；動態定義了工作流實例信息，實例化之前需要準備的一些信息，然后交給工作流引擎。該表描述了所屬工作流ID、創建者ID、完成時間和完成標志。
工作流實例過程；以活動為單位描述工作流實例的處理過程。該表是工作流流程表和工作流實例表的連接表，包括了工作流實例ID、工作流實例對應活動ID。
工作項表；動態描述參與該工作流實例處理的參與者的工作情況，包括自動生成的工作項ID、工作項名稱、當前工作項的狀態、執行的動作和時間。
3實現及應用
工作流引擎根據數據模型的相關信息和應用的具體狀態控制工作流的流程的自動流轉。WFMC給出了工作流引擎的基本功能結構，如圖6所示。
一條工作流建立之后，當用戶生成一個工作流實例，則將該工作流實例存入工作流實例表，再由工作流引擎分配第一個活動到工作項表中，并將其狀態設置成就緒狀態，同時在工作流實例過程表中產生一條記錄。工作流執行者或者IT工具選擇就緒狀態的工作項執行，當一個活動完成之后，由工作流引擎選擇后繼活動，并在工作流實例過程表中增加一條新的記錄，如果后繼活動為空，則該工作流已經結束，這時需要根據結束節點的類型對工作流實例的狀態進行修改。如此反復執行就可以實現對工作流的控制。
筆者根據本文所述的數據模型的基礎上，利用python語言實現了基于Djrdngo平臺的工作流引擎，并成功用于部隊信息化管理試點系統中。
