時間：2022-05-08 12:37:37
引言：易發表網憑借豐富的文秘實踐，為您精心挑選了九篇關系數據庫范例。如需獲取更多原創內容，可隨時聯系我們的客服老師。
【關鍵詞】關系數據庫；非關系數據庫；NoSql
前言
從上個世紀60年代至今的半個世紀，數據庫技術伴隨著信息技術的發展不斷發展，到目前共經歷了人工管理階段、文件系統階段和數據庫系統階段，在數據庫系統階段又經歷了網狀數據庫、層次數據庫和關系數據庫階段，進二十來年，關系數據被廣泛使用，發展成主流，但隨著互聯網技術的蓬勃發展，關系數據庫使用遇到了一些新的問題，為應對這些新的問題，近兩年來非關系數據庫NOSql越來越引起人們的注視，得到了快速發展。
1 關系數據庫
1.1 關系數據庫的簡介
支持關系模型的數據庫系成之為關系數據庫，是目前各類數據庫中使用最為廣泛的數據庫系統。關系數據庫在經過二十幾年的發展，已經變的功能強大，使用廣泛，產品成熟的數據庫系統，現在使用主流的數據庫都為關系型數據庫，比較熟悉的如SQL Server、Mysql、Oracle、Sybase、Informix、DB2等。在網絡上使用比較廣泛的是Sql Server、Mysql和Oracle。
1.2 關系數據庫的特點
關系數據庫是支持關系模型的數據庫系統。而關系模型是由二維表來表示實體和實體間聯系的模型。使用二維表存儲數據，對使用者來說很直觀，更容易理解。使用關系數據庫的優勢主要表現在以下幾個特性：
（1）操作方便性。通過開發應用程序和數據庫連接，用戶能方便的對數據庫中數據進行操作，特別對沒有數據庫基礎的人，也可以通過數據庫管理系統，直接在數據庫中操作。
（2）易于維護性。關系數據庫在完整性約束中提供了實體完整性、參照完整性和用戶定義的完整性，通過完整性約束可以大大降低了數據存儲的冗余及數據不一致的概率。
（3）訪問數據的靈活性。關系數據庫中提供了諸如視圖，存儲過程，觸發器，索引等對象，是訪問數據更加靈活。
1.3 目前關系數據庫面臨的問題
隨著互聯網技術的發展，尤其是web2.0 技術使用，更注重用戶和服務器以及用戶和用戶之間的交互作用，用戶成為既是網站內容的瀏覽者，也是網站內容的制造者。例如：博客（BLOG）、社會網絡（SNS）、以及現在比較熱的微博等。對于在使用web2.0技術并且訪問量比較大網站，使用傳統關系數據庫就會遇到一些問題，主要表現在以下幾點：
（1）對數據庫高并發讀寫的需求
Web 2.0網站要根據用戶個性化信息來實時生成動態頁面和提供動態信息，無法使用動態頁面靜態化技術，因此數據庫的并發負載非常高，往往要達到每秒上萬次的的讀寫請求，此時服務器上的磁盤根本無法承受如此之多的讀寫請求。
（2）對海量數據的高效率存儲和訪問的需求
對于大型的社交網站網站，每天用戶產生海量的用戶動態，隨著用戶的不斷增減，一個數據表中的記錄可能有幾億條，對于關系型數據庫來說，在一個有上億條記錄的表里面進行SQL詢，效率是極其低下的。一些大型Web 網站的用戶登錄系統也是如此，如騰訊、163郵箱都有數億的帳號。
（3）對數據庫的高擴展性和高可用性的需求
在基于Web的架構中，數據庫是最難進行橫向擴展的，當用戶量和訪問量增加時， 數據庫沒有辦法像Web Server 那樣簡單的通過添加更多的硬件和服務結點來擴展性能和負載能力，對于很多需要24 小時不間斷服務的網站來說，對數據庫系統的升級和擴展往往需要停機維護。
2 非關系數據庫NoSql
2.1 NoSql概述
NoSql是應對關系數據庫出現的問題而發展起來的，近幾年隨著web2.0技術的廣泛應用，NoSQL 得到了快速的發展，NoSQL數據庫指的是非關系性的、定義不是很明確的數據存儲倉庫。NoSQL數據庫不再使用關系模型的概念，放棄了使用SQL語句對數據庫進行操作。
NoSQL 數據庫根據數據的存儲模型和特點又分為很多種類。主要有
（1）面向列的存儲系統。按列存儲，區別于關系數據庫中按行存儲，容易擴展，適用與存儲海量數據，對一個或幾個字段進行查詢的效率很高，但在復雜查詢功能比較弱，如多表聯合查詢。此類數據庫產品有BigTable、Hbase、assandra和Hypertable。
（2）面向文檔存儲系統。保證海量數據存儲的同時，具有良好的查詢性能。用JSON或類JSON格式進行存儲，存儲的內容是文檔型的，文檔中的格式是自由的。此類數據庫產品有MongoDB和CouchDB。
（3）鍵-值（key/value）存儲系統。是最簡單的Nosql系統，具有極高的并發讀寫性能。通過key能夠快速查詢到value，并且不考慮value 的格式。此類數據庫產品有Tokyo Cabinet/Tyrant、BerkeleyDB、MemcacheDB和Redis。
（4）圖存儲系統。圖形關系的最佳存儲模式。如Neo4J、FlockDB。
（5）對象存儲。類似面向對象語言的語法操作數據庫，通過對象的方式存取數據。此類數據庫產品有db4o、Versant。
（6）xml 數據庫。高效存儲XML 數據，并支持XML的內部查詢語法。此類數據庫產品有Berkeley DBXML、BaseX。
2.2 NoSql數據庫的優勢
相對于關系數據庫，Nosql數據庫的優點主要表現在：
（1）容易擴展和高性能。NoSQL 數據庫種類很多，但是都有一個共同的特點就是去掉關系型數據庫的關系型特性。數據之間彼此無關系，這樣就非常容易擴展。可以存儲海量數據。同樣由于數據之間無關系，數據庫的結構簡單，在處理大數據量時，NoSQL 數據庫會有出色的讀寫性能。
（2）靈活的數據模型。NoSQL 數據庫不使用傳統的關系數據庫模型，而是使用如key-value 存儲、文檔型的、列存儲、圖型數據庫、xml 等方式存儲數據模型，使用這些模型都無需事先為要存儲的數據建立字段，隨時可以存儲自定義的數據格式。同時根據需求可以選擇合適的模型。
（3）經濟性
在數據量和訪問量比較大的情況下，傳統的關系數據庫對服務器的要求比較高，甚至使用專用硬件設備，這樣造價就比較高。而NoSQL數據庫的易擴展的特點使配置較低服務器上運行，也可以使用低配服務器組成集群來使用，并且有研究證實使用NoSql數據庫基于低配硬件的分布式存儲解決方案比現在的高端關系數據庫更加可靠。這樣就極大的降低了投資成本。
2.3 NoSql的不足
（1）成熟度方面。NoSQL數據庫的實際應用，近幾年才逐漸開始使用，并且大部分NoSQL的產品都還處于實驗和不斷完善的階段。在產品成熟度和穩定性方面，NoSq數據庫遠不及發展了二十多年且已被廣泛使用的關系數據庫。
（2）商業支持方面。大部分NoSQL數據庫都是開源項目，沒有專門的數據庫廠商提供完善的服務，一旦出現故障，只能自己的能力解決，對于一般使用者來說風險比較大。
（3）使用習慣方面。軟件開發人員已經習慣了關系數據庫的模式，解決問題的思路已經被固定在關系模型上，而NoSQL數據庫的開發以放棄了關系模型，要軟件開發人員放棄原來的思路，而掌握和使用NoSql數據庫是很困難的，導致使用NoSQL數據庫的開發人員不可能在短時間內快速增加，這也成為NoSql數據庫發展的一個障礙。
3 關系數據庫與NoSQL 數據庫結合使用
Web2.0時代，關系數據庫不能滿足對數據庫高并發讀寫、海量數據的高效率存儲和訪問、高擴展性和高可用性方面的需求，而NoSql數據庫可以解決這些問題，從而推動了NoSql數據庫應用和發展，那是不是說NoSql數據庫就能取代關系數據可了呢？從目前來看，基于NoSql數據庫的不足，NoSql數據庫還不能完全取代關系數據庫，對NoSql數據庫的使用，單獨使用的情況很少，大多數情況下都是關系數據庫和NoSql數據庫結合使用。
關系數據庫和NoSql數據庫結合使用又分為兩種模式：
（1）NoSql數據庫作為輔助存儲。在這種模式下，把所有的數據都存放在關系數據庫中，可能被經常頻繁讀取的數據再存放在NoSql數據庫中一份，其目的是提高數據的查詢速度，減少關系數據庫的并發訪問負載。
（2）NoSql數據庫作為主存儲。在這種模式下，把所有的數據存儲在NOSQL數據庫中，為了一些特殊業務或功能的需要，在將數據存入NOSQL 的時候，同時存儲到關系數據庫一份。在數據存儲和查詢主要是由Nosql數據庫完成，少量的數據是從關系數據庫讀取。
4 結語
目前關系數據庫仍是主流數據庫，仍被廣泛使用，NoSQL數據庫還不能完全取代關系數據庫，雖然NoSql數據庫打破了關系數據庫存儲的觀念，采用創新的存儲方式，在快速讀寫、海量存儲，高擴展性上很好滿足web2.0時代數據存儲的要求，但NoSql數據庫也有自己的缺陷。在現階段的某些情況下，可以將關系型數據庫和NoSQL數據庫結合使用，相互彌補各自的不足。隨著NoSql數據庫的不斷發展和完善，將來也有可能取代關系數據庫成為主流數據庫。
參考文獻：
[1]盧冬海，何先波.淺析NoSQL數據庫 中國西部科技 2011年02期
【關鍵詞】關系數據庫；數據倉庫；數據挖掘；關系
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.
關鍵詞：非關系數據庫；CouchDB；Map/Reduce
中圖分類號：TP311 文獻標識碼：A 文章編號：1009-3044（2013）14-3220-03
隨著以社交網絡、云計算為代表的Web2.0網站的興起，非關系數據庫（NoSQL）得到了廣泛的關注[1-2]。這是因為傳統的關系數據庫在面對這類應用的時候暴露出許多問題，在處理超大規模的數據、應對高度并發的請求時顯得力不從心。這種情況下非關系數據庫得到了迅速的發展，成為業界和學界所探討的熱點問題。
CouchDB是在處理半結構化的文檔中具有獨特的優勢，在CMS系統、大數據分析和挖掘中具有廣泛的用途。該文首選對非關系數據庫的特征及Map/Reduce的工作方式進行分析，然后詳介紹了CouchDB的安裝、配置及使用方法。
1 非關系數據庫
1.1 非關系數據庫的特點
非關系數據庫是根據Web應用發展的需要而產生的，與傳統關系數據庫有很大的差異。關系數據庫最為顯著的是ACID特性，即原子性（Atomicity）、一致性（Consistency）、隔離性（Isolation）、持久性（Durability）。從分布式應用的CPA理論[3，4]的角度來看，關系數據庫主要關注的是一致性和可用性，能夠很好的滿足傳統的應用需求。但是在Web2.0時代，對數據處理的要求高并發性、海量數據的處理能力和訪問需求，以及對數據庫的高擴展性和高可用性要求。相對而言，關系數據庫所關注的一致性、讀寫的實時性和復雜的SQL查詢在新的應用中卻并不需要[5]。
CPA理論認為一致性、可用性和分區容錯性不可能同時實現。因此非關系數據庫的主要特征為與ACID有著顯著差異的BASE模型[6]。即基本可用（Basically Available）、軟狀態（Soft state）和最終一致（Eventually consistent），它允許系統在一段時間內有不一致性，而放寬至只要最終狀態下數據是一致的就可以了，從而以犧牲高一致性為代價獲得了高可用性。由于非關系數據庫沒有數據庫模式的約束，從而具備了良好的可擴充性。
1.2 Map/Reduce機制
Map函數的輸出為數據庫中的文檔或數據，輸出為鍵值對。這里的鍵和值可以是系統支持的任何類型的數據，用戶可以在Map函數中對文檔數據加以處理，把所需的數據以鍵值的形式輸出。Map函數會對數據庫中所有數據進行處理，結果由主控制器按鍵進行分組，如果用戶不指定Reduce函數則按鍵分組的結果直接輸出。Reduce函數的功能是把鍵值組合進一步處理，比如統計、匯總等。
2 CouchDB的安裝及應用
2.1 CouchDB簡介
CouchDB是最著名的非關系數據庫系統之一，它是Apache軟件基金會的頂級開源項目。CouchDB使用Erlang語言開發，繼承了其強大的強大的并發性和分布式的特征，因此在大數據處理及諸如社交網絡等Web2.0應用開發中具有重要的應用價值。CouchDB的早期版本只能安裝在POSIX系統之上，最新版本則提供了對Windows的支持。
CouchDB是一個面向文檔的、分布式的數據庫，支持REST接口訪問。面向文檔是指CouchDB中存儲的是半結構化的JSON文檔，而且可以方便的將文檔對象映射為具體編程語言的對象。由于JSON在Ajax技術及社交網絡應用中廣泛應用，因此CouchDB在這類應用的數據存儲和處理中具有良好的應用前景。CouchDB是分布式的數據庫系統，源于Erlang極好的并發特性，CouchDB存儲系統可以分布到多臺計算機之上，每臺計算機稱為存儲系統的一個節點。CouchDB能夠很好的協調和同步多個節點之間的數據一致性和完整性，有效的應用系統應用中可能出現的各種錯誤。CouchDB支持REST接口訪問，即可以通過GET、PUT、POST、HEAD和DELETE等標準的Http請求對數據庫進行寫入和查詢分析等操作。因此，任何一種編程語言只要具備Http請求模塊就可以方便的與CouchDB進行對接，甚至只要利用正確的URL地址只要運用瀏覽器就可以訪問CouchDB得到所需要的數據。
與其他的非關系數據庫一樣，CouchDB利用Map/Reduce對數據進行插入、搜索等操作。CouchDB將鍵值對存儲在B-樹引擎之上，并根據鍵值進行排序，因此具有高效的查詢和操作性能。需要注意的是，CouchDB是一個基于版本的數據庫系統，即只能添加數據不能刪除和修改數據，當數據需要更新時CouchDB只是增加了新的版本，所有的版本數據依舊保存在數據庫中，且可以方便的得到。如果要刪除數據則需要將整個數據庫刪除。
2.2 CouchDB的安裝和配置
CouchDB在包括Windows在內的各種操作系統中安裝都非常方便，幾乎不需要做任何復雜的配置，特別是在Mac OS中，下載之后直接運行即可。CouchDB默認使用5984端口，在本機可使用http：//127.0.0.1：5984訪問。在瀏覽器中訪問該Url即可得到關于版本等信息的JSON格式的數據。CouchDB的管理控制臺稱為Futon，通過http：//127.0.0.1：5984/_utils訪問并操作。在Futon中可以手工創建數據庫、添加和查看文檔，并管理CouchDB。默認情況下，CouchDB開放admin權限，為了安全起見需要添加用戶名和密碼。
2.3 CouchDB的操作
3）統計和匯總
對CouchDB進行更復雜的查詢需要同時使用map函數reduce函數。圖5所示的代碼對數據庫文檔數量進行統計，程序運行輸出結果為數據庫中文檔的總數。如果數據庫中僅有圖2所加入的數據，則圖5輸出結果為2。如果要進行匯總操作，只需改變map函數返回值為需要匯總的數值，并根據需要改變group參數的值為True。
結合map函數和reduce函數，可以在CouchDB數據庫中實現傳統關系數據庫中的運算，如選擇、投影、并、交、差，以及連接等。此外，與傳統數據庫一樣，CouchDB也可以利用ViewDefinition將查詢保存為視圖，其使用參數與query較為類似。不同的是視圖的信息要保存在設計文檔之中，因此要指定相應的鍵值，在使用中，數據庫根據這些鍵值生成url用于進行訪問。
3 結論
CouchDB作為一種高性能的面向文檔的非關系數據庫具有廣泛的用途，其開源、免費，以及易用使用的特點使其在Web2.0應用開發、大數據挖掘與分析等方面都有潛在的重要應用價值。該文對CouchDB的應用的分析，有助于深入了解非關系數據庫的工作機制和使用方法。需要指出的是，盡管非關系數據庫在處理大數據方面有很高的效率，但是它絕不是關系數據庫的替代，在數據更新頻繁的傳統應用中關系數據庫依舊是最優的選擇。
參考文獻：
[1] 蔡金花.淺析NOSQL及使用[J].電腦知識與技術，2012，7（12）：2757-2758.
[2] 柯棟梁，鄭嘯，李喬.云計算：實例研究與關鍵技術[J].小型微型計算機系統，2012，33（11）： 2321-2329.
[3] Brewer E A.Towards Robust Towards Robust Distributed Systems[C].Proceedings of the 19th Annual ACM Symposium on Principles of Distributed Computing， 2000.
[4] Gilbert S，Lynch N.Brewer's Conjeture and the Feasibility of Consistent， Available， Partition-Tolerant Web[J]. ACM SIGACT News， 2002， 33（2）：51-59.
[5] 范凱.NoSQL數據庫探討之——為什么要用非關系數據庫？[EB/OL].（2009-11-25）. http：///topic/524977.
關鍵詞：數據庫轉換；.NET；XML
中圖分類號：TP311.13文獻標識碼：A 文章編號：1009-3044(2008)26-1615-02
Relational Databases Conversion Based on .NET Platform
HU Shu-gang
(Dongying Vocational College, Dongying 257091, China)
Abstract: Combining the advantages of XML technology,.NET platform provides the feasibility of data conversion between relational databases. One example demonstrated the SQL Server database can be converted to an XML file, and then the XML file can be converted to other database. It has realized the data conversion between relational databases.
Key words: database conversion; .NET; XML
1 引言
網絡資源中通常包含多種格式和管理系統的關系數據庫，為了實現資源的共建共享，需要完成多種數據庫之間的數據轉換。不同的開發商采用分布式對象技術和各自的思路來實現數據庫的互操作，如OMG的CORBA技術、Sun公司的EJB/RMI和微軟的.NET技術等。
2 數據庫轉換思路
.NET是微軟公司開發的下一代基于互聯網平臺的軟件開發構想，它提供了一個全新的編程模型。該平臺建立在XML和因特網標準協議的基礎上，具有平立性和語言獨立性，它包含了強大數據庫操控能力的。編程模型由一系列的數據庫相關類和接口組成，運用技術，應用程序既能訪問關系型數據庫中的數據，又能訪問層次化的XML數據[1]。XML是W3C的通用標記語言SGML的一個簡化子集。它是一種存儲和傳輸數據的行業標準格式，普遍貫穿于.NET平臺，具有簡單性、可擴展性、互操作性和開放性等特點，其本質特點是數據獨立，它存儲的數據全部是文本，而且使用標記標示，利于網絡傳輸。XML模式提供了很強的數據類型識別功能，可正確處理各種數據類型。XML和.NET的結合為解決數據庫互操作問題奠定了基礎[2]。通過以上分析，可以在.NET平臺上，以XML為中間數據源完成多種關系數據庫之間的轉換[3]。演示示例用的操作系統是Windows XP Professional，開發平臺為Visual Studio 2005，示例用C#語言編寫。
2.1 數據庫的導入[4]
為了導入SQLServe數據庫，先用Connection對象連接數據庫，演示示例中用SqlConnection連接了服務器METC\SQLEXPRESS的數據庫books.mdf。將數據庫讀入DataSet。DataSet對象主要存放數據庫的DataTable的對象，可以使用DataAdapter建立DataSet對象。盡管DataSet可以存儲數據，但仍需要使用DataAdapter對象來創建和初始化各種表，還需要使用Fill()方法來把查詢結果移入到DataSet中去，再將數據寫入到XML文件。關鍵源代碼如下。
String strTableName = "books";
String strConnection = "server=METC\\SQLEXPRESS;database=books;uid=sa;pwd=;trusted_connection=yes ";
String strSql = "select * from " + strTableName;
SqlConnection objConn = new SqlConnection(strConnection);
SqlDataAdapter objAdapter = new SqlDataAdapter(strSql, objConn);
DataSet objDSet = new DataSet();
objAdapter.Fill(objDSet, "temp");
XmlTextWriter objXmlWriter;
String strtemp1 = Request.PhysicalApplicationPath;
String strpath = strtemp1 + "newxml.xml";
objXmlWriter = new XmlTextWriter(strpath, null);
objXmlWriter.WriteStartDocument();
objXmlWriter.WriteStartElement("xml");
for (int i = 0; i < objDSet.Tables["temp"].Rows.Count; i++)
{
objXmlWriter.WriteStartElement("menu");
for (int j = 0; j < objDSet.Tables["temp"].Columns.Count; j++)
{
objXmlWriter.WriteAttributeString(objDSet.Tables["temp"].Columns[j].ColumnName, objDSet.Tables["temp"].Rows[i][j].ToString());
}
objXmlWriter.WriteEndElement();
}
objXmlWriter.WriteEndElement();
objXmlWriter.WriteEndDocument();
objXmlWriter.Close();
2.2 數據的導出[5-6]
以下演示示例是將以上創建的“newxml.xml”文件轉換為Access數據庫demo.mdb中的一個表“newxml”。首先建立與目標數據庫的連接，也就是通過OLE DB Provider提供的OleDBConnection對象建立與Access數據庫demo.mdb的連接。當然，該示例也可通過OLE DB Provider提供的其他連接數據庫的對象來連接Oracle、Sybase或DB2這樣的數據庫以及Excel表格。以下關鍵源代碼部分省略了命名空間的引用、系統自生成代碼和對數據庫中表是否建立的檢查部分。
private void TableCheck()
{ OleDbConnection oledbConn = new OleDbConnection(textBoxOleDb.Text);
Try
{ oledbConn.Open();
DataTable schemaTable = oledbConn.GetOleDbSchemaTable(OleDbSchemaGuid.Tables, new object[] {null, null, tableName, "TABLE"});
String sqlCmd = "";
if(schemaTable.Rows.Count < 1)
{sqlCmd = "create table " + tableName + " (";
for(int i = 0;i < dataTableXml.Columns.Count;i++)
{sqlCmd = sqlCmd + dataTableXml.Columns[i].ColumnName.ToString() + " char(100),";}
sqlCmd= sqlCmd .Substring(0,sqlCmd.Length - 1) + ");";
OleDbCommand oledbCmd = new OleDbCommand(sqlCmd,oledbConn);
oledbCmd.ExecuteNonQuery();}
}
catch
{Message.Text = "數據庫不存在或無法創建表.";}
finally
{oledbConn.Close();}
}
private void TableInsert()
{ OleDbConnection oledbConn = new OleDbConnection(textBoxOleDb.Text);
try
{ oledbConn.Open();
foreach(DataRow dr in dataTableXml.Rows)
{ string sqlCmd = "insert into [" + tableName + "] (";
for(int i = 0;i < dataTableXml.Columns.Count;i++)
{sqlCmd = sqlCmd + dataTableXml.Columns[i].ColumnName.ToString() + ",";}
sqlCmd= sqlCmd.Substring(0,sqlCmd.Length - 1) + ") values (";
for(int x = 0;x < dataTableXml.Columns.Count;x++)
{sqlCmd = sqlCmd + "'" + dr[x].ToString().Replace("'","''") + "',";}
sqlCmd = sqlCmd.Substring(0,sqlCmd.Length - 1) + ");";
OleDbCommand oledbCmd = new OleDbCommand(sqlCmd,oledbConn);
oledbCmd.ExecuteNonQuery();
}
}
}
3 結束語
通過以上實例，演示了以XML為中間轉換數據源，在.NET平臺上方便地完成異構關系數據庫之間的數據轉換和共享。基于.NET平臺，充分利用XML技術的優勢，來解決異構數據庫集成的問題，能夠給用戶提供一個透明的全局數據庫，方便用戶的使用，還使得系統在可擴展性、安全性、可維護性等方面有所提高。
參考文獻：
[1] Lair R, Lefbvre 開發人員手冊[M].張俊,譯.北京:電子工業出版社,2002:38-39,169-193,246-488.
[2] Bray T, Paoli J, Sperberg-McQueen C M, et al.XML標準[EB/OL].[2006-08-16]./TR/2006/REC-xml-20060816/.
[3] 石玉晶,牛存良,馬新娜.使用XML進行異構數據庫間數據傳送[J].現代計算機,2003,19(11):79-80.
[4] 呂品,夏紅霞,李明.異構數據庫互操作平臺的開發研究[J].武漢理工大學學報,2003,25(1):35-37.
關鍵詞:關系數據庫;云端數據庫;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:
【關鍵詞】數據庫設計；單元測試；集成測試
一、數據庫設計
本系統為面向關系數據庫的關鍵字查詢系統，在實驗中本文選取了IMDB 數據集，為了進行實驗，將數據集整理為以下七個表數據結構。
實驗數據集（電影信息數據庫）：
Actor（演員表）、Consume（設計師）、Director（導演信息）、Business（投資）、Editor（編輯）、Color（顏色信息）、Keyword（關鍵詞）。本數據庫抽象的數據庫關系E-R圖如圖1所示。
二、單元測試
為保證代碼中SQL語句的正確性，需要對數據庫中數據進行查詢檢測，當輸入關鍵字為“black”時，查詢結果如圖2所示。
通過外鍵mvname的連接，再查詢Business關系表，顯示結果如圖3所示。
圖3說明當關鍵字是“black”時查詢出來的actor表中，與business中mvname相同的值沒有。當關鍵字為“a”時查詢兩表，顯示結果不為空，如圖4所示。
按照上述方法和SQL語句依次查詢檢測其他關系表。
三、集成測試
在確定系統代碼中關鍵字轉化的SQL語句都正確的前提下，進行系統測試，即進行關鍵字檢索測試。
（一）當輸入的關鍵字為為單關鍵字時，關鍵字分析過程比較簡單，假設檢索關鍵字選擇“keyword”，查詢結果如圖5所示。
關鍵字“keyword”為表名，直接輸出keyword表即可。
（二）當輸入的關鍵字為多個時，情況比單個的復雜一些，假設檢索關鍵字選擇“director color”，檢索結果如圖6所示。
顯示的結果中，包含director和color均為表名時兩表合一的元組；director為表名color為color表中屬性名時，通過mvname、mvyear、setname、episode、made、explantaion等屬性值相等連接后的元組；以及director為表名、color為director和color兩表中的屬性值時，同樣通過mvname、mvyear、setname、episode、made、explantaion等屬性值相等連接所得元組。這三種情況合到一起即為關鍵字“director color”的查詢結果。
四、結語
從單元測試的角度，在MySQL數據庫中測試了系統代碼中SQL語句的正確性。最后，系統測試中測試了系統的關鍵字檢索功能，從單關鍵字和多關鍵字的角度驗證了系統中的查詢功能，保證了系統的正確性、可靠性。
參考文獻
[1] Mac K，David J，Linda C.A hierarchical Dirichiet language model[J].Natural Language Engineering，1995，1（3）.
關鍵詞：網絡設計；關系數據庫技術；儲存功能；轉換功能
一、關系數據庫技術的功能
關系數據庫技術的主要作用是為網絡設計提供輔助功能，在關系數據庫中包含各種各樣網絡設計所需的數據和信息，合理應用關系數據庫技術可網絡設計提供便利條件。促使網絡設計更加完善，比如：在關系數據輸入過程中，要先把對數據的賦值進行全面系統的分類處理，然后對這些數據進行整合和重組，促使網絡設計能獲得更加全面的數據參數和參考信息，促使網絡設計效果和服務質量不斷提升。
二、網絡設計對關系數據庫技術的需求分析
在計算機網絡技術具有很強的開放性，安全性容易受到挑戰，大大增加了管理的難度。為完整網絡設計對安全性和性能的需求，就必須切實滿足如下要求：高性能。網絡設計需要應用到支持線速交換的骨干交換設備，才能確保數據交換的流暢性，在關系數據庫中幾乎包含網絡設計所需的全部信息，合理應用關系數據庫技術可為網絡設計提供數據支持和理論指導。高質量。網絡設計需要滿足業務服務質量，應用業務數據通常情況下，都包含多種多樣的形式，關鍵業務數據流在網絡流量高峰期內，所需的響應時間會有響應的延長。因此，在具體設計過程中，為最大限度上滿足網絡設計的服務質量，高性能網絡必須具備關系數據庫的相關功能。網絡的安全性。網絡病毒、黑客等是目前影響計算機網絡安全的主要因素。因此，網絡設計中需要采取有針對性的手段和技術，禁止病毒的傳播和黑客的攻擊。
三、網絡設計中關系數據庫技術的具體應用
（一）應用思路
為滿足計算機網絡對高性能、高質量、高安全性的需求，在具體設計過程中，對網絡的控制需要以設備分層結構的總線型為主要設計依據，在滿足高性能、高質量、高安全性的基礎上，提升網絡技術應用范圍的靈活性和有效性。關系數據庫的基礎就是數據的有效性，因此，在應用關系數據庫技術時，需要重復結合對象技術，有針對的實現計算機網絡對數據集的功能。此外，針對關系數據庫存在不合理的產品，可在綜合事務處理中進行及時糾正處理，全面體會網絡數據系統的開放性和可擴展性。在關系數據庫中結構比較清晰，簡潔，配置協議的錄入也可以輕松實現，并且協議中的數量，對網絡涉及的難易程度并不會造成較大影響，大大提升了網絡設計的可操作。關系數據庫訪問對象和網絡設計形式之間具有非常密切的聯系，因此，在進行計算機網絡訪問系統設計過程中，要充分結合關系數據庫，可通過C語言編程的使用來完成訪問工作。
（二）存儲功能的實現
在網絡數據處理中，XML（可擴展標記語言）是進行數據轉換的主要標準，通過描述數據自身的意義來實現數據實體間復雜嵌套的關系連接。因此存儲功能的實現主要包括以下兩個方面：1.結構映射XML中文件類型定義比較復雜，需要先進行簡化處理，生成文件類型定義圖，具有的簡化流程為：先進行層次嵌套關系的平面優化轉換處理，將其轉換為非嵌套定義；然后再對多個一元操作進行簡化轉換；最后把聚集轉換為多個子元素，通過整合和歸類的作用，構成一個子元素。在具體簡化過程中，要完成文件類型定義圖像關系模式的映射，通過共享內聯法，為文件類型定義提供達先對獨立的關系。再通過綜合內聯法，在父節點形成的關系表中，除直接后繼節點之外，內聯和入度都超過1的元素節點。2.模型映射XML文檔在存儲過程中，常用的方法有兩種，一種是Edge法，主要過程為把XML文檔當做圖形結構進行處理，并在相應的關系表中，完成邊界存儲，而目標節點的區分通過flag來實現。Source主要應用在資源節點存儲中，target則主要應用目標節點標識符的儲存中。
（三）轉換功能的實現
關系數據庫中數據轉換流程包括以下幾個步驟：第一步，定義模式映射通過XSD格式來完成，進而實現目標數據庫到XML模式映射的建立，此外，XSD格式和文件類型定義相比，可更好的定義類型，并且在網絡設計中也容易實現數據之間的相互交換，可保證數據庫中信息和數據的傳輸都是XML格式。第二步，當模式映射文件形成以后，還需要綁定同步模塊，為后期XML的導入提供參考指導。第三步，在目標數據庫中和本庫中主要通過源數據庫的使用，完成相關數據模式的對比，并判斷其是否為同步的表結構，為創建異構模式映射文件提供數據支持。第四步，根據同步模式中的相關任務，形成對源數據庫，所有的同步數據都可以通過該查詢來獲取。第五步，把關系數據庫中查詢到的結果進行同步處理，形成XML格式數據，并寫入相應的文件中。
>> 基于關系數據庫的本體構建方法研究 面向關系數據庫的裝備領域本體構建研究 基于對象關系數據庫的移動對象數據庫管理系統的研究 基于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 研究瓶頸及建議
現在，基于關系數據庫生成本體的研究已經引起越來越多研究者的興趣。基本思路無非是從關系數據庫中提取出數據模式，然后設定數據模式轉化為本體的規則，然后編程實現。每個研究人員都提出了自己的轉化規則，而并沒有人對規則的可行性給出評價結果。至今，尚未有研究者或機構給出權威的轉換規則。轉換規則的可行性和合理性應該是未來研究的重點。
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.
關鍵詞：關系；E-R圖；實體
中圖分類號：TP301 文獻標識碼：A 文章編號：1009-3044（2013）25-5587-02
數據庫技術的應用實例在我們生活中隨處可見，如企業、學校、醫院、超市、社區等，可見數據庫技術的重要性不言而喻。而在普通高等院校、三本或高職類（非）計算機專業的群體中，數據庫課程也是作為其中一門必修的公共基礎課存在。開設的課程有SQL Server、Oracle、Visual FoxPro、Access等，無論是哪門課程，它們都有一個共同的特點，都是關系型數據庫[1]，而關系型數據庫在我們現實生活中應用也是最為廣泛的。下面我們就以一個簡單的實例來闡述關系數據庫設計的基本原則和實踐應用。
1 數據庫系統結構與邏輯設計
1.1 三級模式和二級映像結構的優點
數據庫系統的標準結構為三級模式和二級映像。三級模式分別為內模式、模式和外模式，二級映射為內模式/模式映像和模式/外模式映像。如圖1所示：
模式即概念模式，該模式是對數據的邏輯結構和特征的描述，是對所有應用程序的數據綜合抽象得到的全局數據視圖；外模式是所有應用程序或用戶訪問數據的邏輯結構和特征的描述；內模式是數據的底層物理存儲結構的描述。二級映像保證了各級數據在不破壞底層數據存儲結構的基礎上完成上層數據的所有操作任務，保證了數據庫中數據較高的邏輯獨立性和物理獨立性。
1.2 邏輯設計內容和方法
計算機處理客觀應用問題的一般框架如圖2所示：
在設計開發數據庫時，邏輯設計的內容有應用語義環境下如何設計表、定義表、定義表間關系、如何操作表等，可通過文字或一套業務實體表格來描述。大致可通過兩步來完成，第一步：從應用問題中提取核心概念建立概念模型；概念模型可用實體—關系圖（E-R圖）來描述；第二步基于一定的轉換原則建立關系數據模型。關系模型的表示形式為：R（U， F），其中，R為關系名，U為屬性集，F為函數依賴關系。轉換原則有以下七種[2][3]：
1）一個實體型轉換為一個關系模式，通俗的說即一個實體對應一張二維表。
2）一個1：1實體聯系可轉換為一個獨立關系模式，也可以與任意一端對應的關系合并。
3）一個1：N實體聯系可轉換為一個獨立關系模式，也可以與任意一端對應的關系合并。
4）一個M：N實體聯系一定轉換為一個獨立的關系模式，特別是帶有屬性的聯系。
5）三個以上實體間的多元聯系可轉換為一個關系模式。
6）相同碼的關系模式可以合并。
7）同一實體集的實體間聯系與對應的關系合并為一個關系模式。
除此之外，數據庫的設計不僅需考慮理論支持，還需要結合實際的業務流程。
2 應用實例解析
其中，實體“學生”、“課程”和“系別”分別轉換為三個關系模式，照應原則1；另外有兩個聯系，“所屬”聯系可以獨立轉換為一個關系模式，也可以與“學生”和“系別”任意一個關系合并，照應原則3；而“選課”聯系自身具有特殊屬性“成績”，特殊性體現在該屬性既不能作為“學生”的屬性存在，也不能作為“課程”的屬性存在，故必須將該聯系轉換為一個獨立的關系模式，照應原則4。綜上所述，E-R圖可被轉換為4個關系模式，根據對該領域的認識和經驗為每個關系添加屬性描述其特征，同時指定關系的主碼、外碼以及用戶自定義完整性約束，最終實現E-R圖到關系模型合理正確的轉換，建立數據庫同時進一步優化其性能[4]。
原則4實際應用的例子有很多，又如銷售商與供應商之間的供銷關系問題。在該業務流程中三個主要的實體：供應商，源材料和工廠。他們之間時刻有著密切的業務往來，而在三個實體間共同存在“供銷”聯系，而該聯系具有屬性“供應量”，供應量就如同上述的“成績”一樣，需轉換為一個獨立的關系模式來描述。
3 結束語
文中以關系數據庫基本理論為依據展開闡述數據庫邏輯設計的內容和方法，并以簡單實例來論證理論方法的指導意義和應用效果。
參考文獻：
[1] 薩師煊，王珊. 數據庫系統概論[M].北京：高等教育出版社，2000.
[2] 袁國銘.關系數據庫設計的總體原則[C].第七屆中國通信學會學術年會論文集，2010：168-171
