導語：如何才能寫好一篇關系型數據庫，這就需要搜集整理更多的資料和文獻，歡迎閱讀由公務員之家整理的十篇范文，供你借鑒。

篇1

因特網發展提出的新挑戰

自20世紀80年代以來，開發人員在開發企業級應用的時候，關系型數據庫已經成為主流的選擇，因為這種最初由E. F.Codd博士提出、并由IBM公司作為一種通用數據庫而廣泛推行的數據庫技術已經相當成熟。關系型數據庫可以提供高擴展性的高性能事務處理和多平臺支持，同時還提供一個數據建模框架，其中很多框架都包括應用開發的腳本語言。

然而，20世紀90年代的因特網革命，使開發人員們已經開始接受新的數據模型和程序范本。一些封裝在面向對象的程序理論，如數據與代碼結合、信息與方法相結合等，已成為全新的開發路線，打破了傳統的關系型數據庫的工作模式。同時，因特網革命產生了更復雜的數據需求。數字數據通過因特網提供的大量數字信息在全球得以輕松傳播，并因此產生了大量的數據文件或二進制大對象 (BLOBs)――這些都遠不是傳統的關系型數據模型所能解決的。

面向對象的數據庫技術

面向對象是一種遠比傳統的關系模型強大得多的邏輯結構。一些面向對象的概念，如“對象繼承”等，更強調用一種真實可行的角度來看待并處理現實世界的信息。其它概念，如“封裝”和“多態”等，則提供了更強大的機制來管理對象，大大提高了可重用性和標準化等編程效率。面向對象還可以很經濟地將代碼、數據和BLOBs聯系在一起，同時為基于因特網的快速應用開發（RAD）提供理想的基礎。

絕大多數開發人員已經意識到面向對象理論的實用性和重要性，并已開始采用面向對象的程序語言。然而，面向對象的理論，在很大程度上仍然受制于傳統的關系型數據庫技術。以網絡為中心的數據庫必須擁有更強大的性能和伸縮性，這些都是存儲信息型的關系型數據庫永遠不可能做到的。

面向對象的理論與關系型數據庫技術的應用開發，產生了“抗阻不匹配”現象，即開發人員的邏輯（對象）結構與物理的二維（關系的）表不相匹配，而所謂的“對象關系映射”在許多應用開發項目中會消耗掉40％的成本。抗阻不匹配的現象，大大增加了開發和平臺的成本，并降低了性能和伸縮性。應用越大，面向對象的關系型建模就越復雜，問題就會越嚴重。

面向對象的后關系型數據庫

多年來令開發人員工作輕松的關系模型數據庫正令他們越來越頭疼。引導潮流的先驅們正不斷地去尋求新的數據庫管理系統的替代品。

面向對象的后關系型數據庫管理系統也許是一個不錯的選擇。它所采用的靈活的物理結構，可以同時根據關系和面向對象來存儲數據。開發人員可以在單一的數據庫管理系統中選擇最適合應用的開發范本、存儲代碼和BLOBs。表與對象在數據庫層之間能夠相互轉換，可以作為一種不同系統與不同應用之間數據共享的通用機制來支持SQL。后關系型數據庫會帶來更低的軟件和平臺成本、更好的運行性能與伸縮性，并且降低用戶跨應用、環境和平臺的數據庫管理成本。

篇2

關鍵詞：非關系型數據庫；無模式；聚合結構；實驗教學；云計算

中圖分類號：TP399 文獻標識碼：A 文章編號：1009-3044（2013）31-7046-03

云計算是現階段計算機技術和網絡技術發展的必然結果，是當今信息領域的重大變革，是解決信息時代大用戶、大數據和大系統挑戰的切實可行的方案[1]。當今世界發達國家或地區如美國、歐洲、日本等都是政府牽頭推動云計算的發展，而中國政府的“十二五”規劃中將云計算作為重點發展項目[2]，并鼓勵企業推廣開發應用，目前已獲得了最大的經濟效益和社會影響力。因此云計算是新一代信息技術的主流，在云計算的基礎上可衍生出云制造、云服務及云媒體等技術。現代企業的市場競爭日趨激烈，所面對的用戶數量和業務數據量與日激增，其業務系統日并發訪問管理、海量數據的存儲、復雜的系統架構等問題給企業帶來了最大的管理壓力，其開發成本也激烈上升，而物聯網、移動互聯網快速發展增加了這一趨勢。在諸多問題中，海量數據庫的設計、存儲和訪問顯得尤為突出。而傳統的關系型數據庫在處理集群環境下的海量數據時已沒有非關系型數據庫那樣優勢明顯和靈活，實際上使用非關系型數據庫能構建性能更高、擴展性更好及更易編程的web系統。

因此在大數據時代下，數據庫課程教學必須引入非關系型數據庫的教學內容，其教學課時比重應與關系型數據庫相當（48課時），這是當今用戶業務系統的迫切需求和云計算技術發展對此類信息化人才大量需求的必然結果，也是目前高校實施信息化卓越工程師的重點解決方案[3]。

1 大數據時代非關系型數據庫課程理論教學設計

以解決集群環境下的海量數據庫的設計、存儲和查詢為目的的非關系型數據庫在教學時可以參照關系型數據庫的課程體系和教學方法[4]。以關系型數據庫教學的主要內容包括關系理論、關系代數、規范化設計、SQL應用、儲存過程、函數、觸發器、事務與并發性、安全性及高級語言的開發等。與關系型數據庫相比，非關系型數據庫沒有復雜的關系特性和嚴格的范式設計，更具靈活性，兩者的比較如表1所示。

從表1可以得出，在大數據時代主要解決了數據庫的并發負載問題、海量數據存儲問題、高可擴展性與高可用性問題、讀寫實時性問題以及開發與維護成本問題。

由非關系型數據庫的特點，設計的理論教學內容如下：

1）非關系型數據庫的基本概念 主要包括該數據庫的組成、分類、特征及作用、邏輯結構、集合、文檔、鍵值對、聚合；課內教學大約占4課時。

2）非關系型數據庫建模 與關系型數據庫的ER模型不同，非關系型數據庫集合之間主要采用聚合結構，因為聚合使得在集群中管理數據存儲更為方便，當然設計的聚合模型會因人而異，圖1是某CRM系統銷售模塊的數據庫ER模型，而圖2是其對應的非關系型數據庫的聚合模型。這部分內容是重點，課內教學大約占8課時。

5）非關系型數據庫的管理 主要包括用戶的創建、授權機制；索引創建與維護；數據備份與恢復；事務及并發性等，這里的事務主要指一致性，海量存儲中是靠很多節點來執行數據操作的，具有較好的事務一致性，要做的僅僅是在網絡延遲與一致性之間取得平衡[5]。課內教學大約占4課時。

6）非關系型數據庫系統網絡架構 主要包括集群環境下復制集、分片技術的原理及由復制集加分片技術共同構建項目開發環境，可實現數據海量存儲和高可用性需求，課內教學大約占4課時。

7）非關系型數據庫的實例開發 主要內容包括使用Java或C#語言實現一個非關系型數據庫小型系統的設計與實現，與開發關系型數據庫使用JDBC或組件不同，非關系型數據庫的開發使用專門的API接口，該接口簡單易學易用。課內教學大約占6課時。

因此該課程的課內理論總課時為38，不足的部分學生可利用課外時間補充與完善所學知識點。

2 大數據時代非關系型數據庫課程實驗項目設計

該課程的實驗設計依據是按照大數據時代下的信息系統的開發應用為前提。學生要能單獨設計無模式的數據模型，進行文檔對象的CRUD操作，掌握集群環境下的復制與分片技術，并能通過某種高級語言開發非關系型數據庫。設計實驗5個，每個實驗2學時，共10學時。如表2所示。

3 結束語

高校作為先進信息技術研究、教學的最前端，應適應當今信息技術的快速發展，與時俱進。與其對應的課程應做出相應的改革和調整。關系型數據庫作為傳統的數據庫課程一直占據信息化系列課程的主導地位，數十年沒有動搖。但隨著大數據時代的來臨，非關系型數據庫來勢迅猛，大有取代前者的趨勢，但關系型數據庫在實時聯機事務處理、數據倉庫與數據挖掘、完整性約束等方面具有無可替代的優勢，因此這兩種數據庫還將在一定時間內長期存在，現行系統的數據存儲仍是混合式存儲模式結構，因此早日引入非關系型數據庫課程的教學有利于保持高校課程體系的先進性，有利于新技術人才的培養，有利于國家推動云計算的進展。

參考文獻：

[1] 姚宏宇，田舒寧.云計算大數據時代的系統工程[M].北京：電子工業出版社，2013.

[2] 許守東.云計算技術應用與實踐[M].北京：中國鐵道出版社，2012.

[3] 劉鵬.云計算（第二版）[M].北京：電子工業出版社，2013.

篇3

【關鍵詞】 VB6.0 C# SQL SERVER T-SQL 類

【中圖分類號】G42 【文獻標識碼】A 【文章編號】2095-3089（2013）05-0243-03

前言

中央廣播電視大學的數據庫應用技術教材是基于VB6.0和SQL SERVER2000實驗環境下的，這為我們的數據庫應用技術教學實踐帶來一些困擾和不便，尤其不便于學生課后更準確有效地自學教材。對此問題，筆者借助多年教學經驗的積累，將中央電大本門課程的形考任務“數據庫應用系統開發”在VB6.0、和C#多種環境下的實現進行了思考和實驗，對不同環境下的數據庫應用系統設計實現方法和關鍵技術進行了比較，能夠有效地指導學生在不同應用程序開發環境下，以簡捷的方式、方法，較快地設計、實現一個具備增、刪、改、查詢功能的小型數據庫應用系統，同時滿足了學生接受新事物、新技術的愿望，激發了他們搞好畢業設計的創作熱情，為學生們后續畢業設計打下了堅實的基礎。

實現

本系統是基于 C/S 結構的信息管理系統，分別使用 VB6.0、和C#作為開發語言，前端應用程序通過ADO、技術來與數據庫進行連接，優點是易于使用、高速度、低內存支出和占用磁盤空間較少。

該數據庫應用系統雖然規模小，但是已經具備增加、修改、刪除、查詢等系統功能。下面介紹一下系統開發的主要方法：

一、進行數據庫設計

（一）需求分析

1.業務流程分析

“學生成績管理系統”，主要目的是用以實現學生、課程以及成績等多項管理。本系統管理的對象簡單，每個數據之間都有較強的關聯性，涉及過程并不復雜。因此，比較適合于數據庫管理。

2.數據流程分析

圖1學生成績管理數據流程圖

（二）概念結構設計

根據需求分析的結果，進行概念結構設計，依照收集信息標識對象（實體）標識每個對象需要存儲的詳細信息（屬性）標識對象之間的關系的步驟，采用E-R圖工具表示，設計結果如圖2所示：

圖2學生成績管理E-R圖

（三）邏輯結構設計和物理實現

邏輯結構設計的方法與步驟，是將概念結構設計的結果E-R圖轉換為某個DBMS所支持的數據模型，并對其進行優化的過程。具體過程為：

將各實體轉化為對應的表，將各屬性轉化為各表對應的列；標識每個表的主鍵列；在表之間體現實體之間的映射關系，遵守參照完整性規則；根據范式理論，對表進行修改，盡量滿足第三范式。

通過規范化數據庫設計，可以減少存儲的冗余數據量，減輕數據維護工作，減少存儲的要求，提高數據庫的完整性。

物理實現階段的主要工作是，把設計好的數據庫全局模式轉換為相應的內模式。在此用以上方法建立一個名稱為“學生成績管理”的數據庫，其中包含3張數據表，即學生情況表、課程情況表、學生成績表。

二、操縱和訪問數據庫的基本SQL語句

SQL是關系數據庫支持的標準查詢語言，也是一種雙重式語言，即用于查詢和更新的交互式數據庫語言（Interactive SQL），又是一種應用程序進行數據庫訪問時所采取的編程式數據庫語言，即嵌入式SQL（Embedded SQL）[1]。嵌入式SQL是數據庫應用程序的一種開發方法。它要將SQL語句直接嵌入到程序的源代碼中，與其他程序設計語言語句混合使用。

開發的應用程序將針對上述數據庫進行管理，主要有插入（insert）、修改（update）、刪除（delete）、查詢（select）和打印（print）等5種基本的操作。

三、界面設計

（一）創建項目工程

項目工程名稱為“學生成績管理”。

（二）創建主窗體

運用菜單技術創建主窗體。

（三）創建增加、刪除、修改、查詢功能窗體

使用標簽、文本框、組合框、表格、命令按鈕等控件，添加并創建“查詢記錄”、“增加新記錄”、“修改記錄”、“刪除記錄”等窗體。

四、代碼設計

.NET框架的一個主要組成部分是類庫，這些類被拆分為命名空間，它是類庫的邏輯分區。類庫所采用的命名空間是層次結構，即命名空間下又可以再分成子命名空間，每個命名空間都包含一組按照功能劃分的相關的類。

在.NET環境下，必須指向包含所使用類的命名空間（例如Imports System.Data，Imports System.Data.SqlClient）才能激活相應的類；借助于封裝，把常用的數據連接、數據庫查詢和對數據庫操縱的功能模塊定義為公共函數，包括createConn（）用于建立數據庫連接的函數，sqlUpdate（）用于對數據庫操縱的函數，sqlfind（）用于數據庫查詢的函數；使用時調用即可，避免相同功能模塊的重復建設。針對該系統，筆者創建了SqlConnection、SqlCommand公共類的實例和系統常用的公共函數。

在不同模塊的設計中都可以調用這些自定義函數，在此不再贅述。

五、報表設計

一個功能完整的數據庫應用系統，除了具有數據維護、查詢和顯示功能外，還必須具有報表輸出功能。Visual Studio2005報表體系結構圖]，其ReportViewer控件負責解釋RDLC報表定義、處理報表參數并按照各種用戶可選格式提供報表的“報表處理器”。它既可以運行于“本地模式”也可以運行于“遠程模式”[2]。由用戶編寫的存儲過程負責管理連接或運行基于參數的查詢；報表只駐留以報表為中心的Parameters集合，尋址遠程報表服務并呈現給用戶。

六、幾種實現方法的比較

嵌入式SQL在VB6.0下和在下使用的基本形式和處理過程對比如下：

（一）在VB6.0環境下的具體實現

ADO是微軟公司提出的第三種數據庫訪問對象，它把OLE DB封裝在一個數據對象中，使得VB6.0程序可以方便地實現對數據庫的訪問。ADO對象模型共包含7個對象，即Connection，command，Recordset，Parameter，Property，Field和Error。

VB6.0應用程序中主要用Connection對象建立與數據庫的連接，用Recordset和Field對象，對數據表進行操作，實現數據表增加、刪除、修改等不返回結果集的操作，語法參閱文獻[1]。

（二）在環境下的具體實現

是微軟.NET Framework框架中針對與數據庫進行交互的一組對象類的名稱[3]。提供對Microsoft SQL Server、Oracle等數據源以及通過 OLEDB和XML公開的數據源的一致訪問，也就是提供與數據源進行交互的相關的公共方法。應用程序可以使用來連接到這些數據源，并檢索、操作和更新數據。

比ADO更適用于分布式應用環境，增加了更好的性能；它有更好的可操作性、它可以結合XML語言來開發數據庫；它有更好的可維護性、可編程性和可伸縮性。

對象模型中包含五個主要的組件，即是Connection對象、Command對象、 Dataadapter對象、Datareader對象以及Dataset對象。架構圖參見[3]。

其中Connection對象、Command對象、 DataAdapter對象和DataReader對象四個組件是負責建立聯機與數據操作部分的，被稱為數據提供組件 （Managed Providers）。而Dataset對象是非連接架構下把數據庫中的數據映射到內存緩存中所構成的數據容器，是一個或多個DataTable 對象的集合。DataSet在使用時就像駐留在客戶端計算機上的一個小型關系數據庫，但又與任何具體的數據庫完全無關。DataAdapter對象在后臺數據庫和前臺Dataset對象之間起著橋梁作用。其Fill方法將后臺數據庫的數據取到前臺客戶端的Dataset對象中來。而其Update方法則按相反方向把前臺對數據庫的寫操作寫入數據庫中去，它由應用程序在Dataset中添加、更改或刪除的行對數據庫進行更新，在使用DataAdapter時，需要將查出的數據起一個表名放到DataSet中。一個Dataset可以存放多個表，而TableAdapter的結果就是一個表，不能再繼續添加表。

DataReader實現數據操作以及對數據的快速、只進、只讀訪問。Connection對象提供與數據源的連接。Command對象能夠訪問用于返回數據、修改數據、運行存儲過程、發送或檢索參數信息的數據庫命令。DataReader從數據源中提供高性能的數據流。它需要與數據庫保持連接，ExecuteReader（）函數返回一個SqlDataReader對象或OleDbDataReader對象，通過這個對象來檢查查詢結果，它是一種“單向”流，一次只能提供一行數據，就像高速傳送帶上的一排箱子，一旦它們被放在帶子上，就無法對它們排序或過濾出選定的箱子，也因此占用內存少，執行效率高。當用戶讀取大量數據時，可以使用DataReader來提高性能。

根據應用程序所需功能和性能的要求，來確定是使用DataSet還是DataReader。

嵌入式SQL在環境下通過SqlCommand.ExecuteNonQuery（）方法，對連接執行SQL語句，并返回受影響的行數，當行數大于0時，命令執行成功，否則說明對數據庫沒產生影響。通過使用SqlCommand.ExecuteScalar（）方法來執行命令對象的SQL語句，從數據庫中檢索單個值，當值大于0時，命令執行成功，否則命令執行失敗。該方法不接受任何參數，僅僅返回查詢結果集中的第一行第一列。

在環境下通過調用以上定義的函數，就可以實現使用各種嵌入式SQL語句來操縱后臺數據庫的功能。

（三）C#語言環境下的設計實現

由于C#簡單易學，而且可以跨平臺使用，因此它正在成為程序開發人員使用的主流編程語言。[4] 它具有如下諸多優點：

C#遵守通用語言規范（common language specification，CLS）。

C#具備自動內存管理功能：CLR 內建垃圾收集器，當變量實例的生命周期結束時，垃圾收集器負責收回不被使用的實例占用的內存空間。

C#具有交叉語言處理能力：由于任何遵守通用語言規范的程序設計語言源程序，都可編譯為相同的中間語言代碼，不同語言設計的組件，可以互相通用，可以從其他語言定義的類派生出語言的新類。

C#更加安全：C#語言不支持指針，一切對內存的訪問都必須通過對象的引用變量來實現，只允許訪問內存中允許訪問的部分，這就防止病毒程序使用非法指針訪問私有成員，也避免指針的誤操作產生的錯誤。

C#軟件的安裝更加容易：在.NET 中這些組件或動態連接庫不必在注冊表中注冊，每個程序都可以使用自帶的組件或動態連接庫，使軟件的安裝更加容易。

C#是完全面向對象的：C#語言中所有的函數、變量和常量都必須定義在類中，避免了命名沖突。C#語言不支持多重繼承。

在開發項目中以類的形式來組織、封裝一些常用的方法和事件，不僅可以提高代碼的重用率，也大大方便了代碼的管理。

本系統中using System.Data.SqlClient命名空間包含有關專門操作SqlServer數據庫的類，如SqlConnection，SqlCommand，SqlDateAdapter等，System.Data命名空間包含數據庫操作所需要用到的普通數據，如數據表，數據行等；DbHelperSQL類定義了與數據庫的連接配置、執行SQL語句的公用方法等。調用并且構建這些類的實例設計完成系統主窗體和系統的增、刪、改、查詢功能。

七、結論

（一）在不同高級語言環境下創建應用程序的過程都一樣。

（二）在不同環境下使用的SQL語句都完全一樣，可以實現同樣的數據庫操縱功能。

（三）在VB6.0環境下編寫的應用程序，搬到.NET環境下不能使用。

（四）NET開發平臺具有更加強大的內部函數庫，.NET編程很大程度上依靠程序庫中提供的可重用源代碼，.NET框架提供了2500多個可重用的類。公共語言運行時庫（CLR）提供了執行程序的服務，實現了編程語言的統一。.NET程序需要經過兩次編譯才能在CPU上運行，首先編譯生成與CPU無關的中間語言（MSIL）程序，在CLR的支持下，中間語言程序被編譯成由本地CPU指令組成的程序，實現了.NET跨平臺運行的目標。[5]

（五）NET采用數據訪問技術，支持離線的數據訪問功能，同時提供了只進的、一次只能讀取一條記錄的消耗資源極小的DataReader對象，提高了應用程序對數據庫訪問的性能。更適用于分布式數據庫應用系統的應用。

（六）和C#生成的代碼可以完全通用。VB提供了很多類型轉換函數型運算符，如CInt（）， CSng（）， CStr（）等，在C#中只要用（int） ， （float）， （String）即可； VB支持兩種形式的異常，即.net框架的異常和VB自己的錯誤號碼，而C#只支持第一種。用到VB自己的錯誤號碼的程序幾乎無法移植到C#中。

（七）VB支持模塊，C#不支持。在C#中制造一個abstract類，共享所有成員，就和模塊一樣了。C#不能像VB一樣直接訪問模塊中的成員，需要使用“類名.成員名”的用法。

（八）C#代碼更加簡潔，像一樣簡單，像C++一樣強大， 是第一流的面向組件的語言。C#語言是.NETFrame Work 中新一代的開發工具，是一種現代的、面向對象的語言，它簡化了C++語言在類、命名空間、方法重載和異常處理等方面的操作，摒棄了 C++的復雜性，更易使用，更少出錯。它使用組件編程，和VB一樣容易使用。C#語法和 C++、JAVA 語法非常相似。所有的.NET Framework中的基類庫（Base Class Library）都由C# 編寫。

參考文獻：

[1]劉世峰.數據庫應用技術（本科）[M].中央廣播電視大學出版社，2008，103

[2]顧曉梅.數據庫應用技術教程[M]，上海電視大學教材， 2010， 171

[3]呂軍.軟件項目綜合實訓（.NET篇）[M]，清華大學出版社，2010，96～97

篇4

[關鍵詞]關系數據庫SQL查詢對策

中圖分類號:TP3文獻標識碼:A文章編號:1671-7597(2009)1210080-01

在各類大型應用軟件的數據庫中,都存在大量的數據信息和記錄,經常要對它們進行各種數據操作。SQL(Structrued Query Language)作為結構化查詢語言,是大型計算機操作關系數據庫的標準查詢語言,同時也廣泛地應用到小型計算機的數據庫管理系統中。它是一種高度非過程化的語言,即只要用戶按其語法規則寫出符合操作要求的語句,而并不需要告訴系統應如何執行SQL語句,就可得到所要求的結果。隨著數據庫技術的廣泛應用,在數據庫程序的開發過程中,大量的工作是要進行數據查詢和檢索處理。本文從SQL查詢語句執行的過程入手,對其執行效率進行分析,并給出參考性建議和優化策略。

一、SQL語句執行過程解析

在平時書寫SQL查詢語句時,雖然每個人的寫法不盡相同,而且有時個別子句順序并不影響操作結果,但是在各種數據庫管理系統中,標準的SQL的解析順序為:

1.FROM子句,組裝來自不同數據源的數據;

2.WHERE子句,基于指定的條件對記錄進行篩選;

3.GROUP BY子句,將數據劃分為多個分組;

4.使用聚合函數進行計算;

5.使用HAVING子句篩選分組;

6.計算所有的表達式;

7.使用ORDER BY對結果集進行排序。

通過以上SQL語句的解析過程,我們可以對SQL查詢語句進行優化處理。SQL查詢語句的核心結構是SELECT…FROM…WHERE,了解了這個基本結構,我們可以從以下幾個方面對其進行優化處理。

二、效率分析及優化對策

(一)從From子句入手

From子句后面接單表或者多表,通常情況下接受來自不同數據源的多表。如果是單表,一般情況下對表進行快速全表掃描。如果是多表的情況,查詢設計優化器將采取自右向左的順序依次讀取數據表。如以下語句:“From table1,table2,table3”,優化器將優先讀取table3表,然后是table2表,最后是table1表。在進行From子句的多表連接時,就需要結合條件子句WHERE進行分析,需要遵循下面的規則:1. 當WHERE后面接的條件能夠一次性過濾某個表的大量記錄時,應優先處理該表。2. 如果WHERE后面接的條件不能過濾掉大量記錄時應該優先考慮處理記錄數最少或者索引關鍵值最少的表。

(二)從條件子句WHERE入手

WHERE子句后面通常接過濾條件,對表的記錄進行篩選,篩選出符合條件的記錄。如果SELECT查詢語句沒有WHERE子句,則無須對表記錄進行過濾。若后面接單個表,則通常順序掃描全表。若后接多表或者大量記錄表時,則可以考慮用索引來減少查詢的時間。所以在查詢前可對各個表建立比較的索引。對WHERE子句中出現的條件,可以依據以下原則首先來驅動查詢。

(1)建立索引字段的列比沒有建立索引的要快;(2)主索引要比普通索引快;(3)單索引要比符合索引快;(4)有條件約束要比沒有條件約束要快。

此外,WHERE子句通常采用自下而上的順序解析WHERE子句,根據這個原理,表之間的連接必須寫在其他WHERE條件之前,那些可以過濾掉最大數量記錄的條件必須寫在WHERE子句的末尾。根據以上原則,我們可以判斷出以下四個語句中哪個選項語句效率最高。

Select * Frommobilewhere (mobileno='13775637677') andbegINtime>

{^2009-1-308:20:11} andbegintime

B) SELECT*Frommobilewhere(mobileno='13775637677' )andbegINtime

{^2009-1-30 8:20:11} andbegintime>{^2009-1-30 8:20:11}

C) SELECT*Frommobilewherebegintime

{^2009-1-308:20:11}and(mobileno='13775637677' )

很顯然,綜合以上原則C選項效率最高。

(三)從GROUP BY和HAVING子句入手

在SELECT語句中,GROUP BY語句的作用是對記錄進行分組(劃分成較小的組),使用聚合函數返回每一個組的匯總信息,而HAVING子句限制返回的結果集。在一個SQL語句中可以有WHERE子句和HAVING子句。HAVING與WHERE子句類似,均用于設置限定條件。WHERE子句的作用是在對查詢結果進行分組前,將不符合WHERE條件的記錄過濾掉,而HAVING子句的作用是篩選滿足條件的組,即在分組之后過濾數據,但它不能單獨使用,只能配合GROUP By語句使用,該條件中經常包含聚組函數,使用HAVING條件顯示特定的組,也可以使用多個分組標準進行分組。雖然HAVING子句可以起到過濾的作用,但是要盡量避免使用HAVING子句,HAVING只會在檢索出所有記錄之后才對結果集進行過濾。這個處理需要排序,總計等操作。如果能通過WHERE子句限制記錄的數目,而且能盡早地把不滿足條件的記錄過濾掉,那就能減少這方面的開銷。

(四)從謂詞等方面入手

在SELECT語句中,由于實際需要,查詢語句會經常出現謂詞。常用的謂詞有EXIST,NOT EXSIT,IN,NOT IN等,巧用謂詞也會提高SQL語句的執行效率,可參考以下原則編寫SQL語句。

1.Where子句中盡量不要使用IS NULL或IS NOT NULL的語句,因為它們不會使用索引。

2.WHERE子句盡量不要將通配符(%)放在搜尋詞首出現,通配符(%)在搜尋詞首出現不會使用索引。

3.用EXISTS代替IN。在許多基于基礎表的查詢中,為了滿足一個條件,往往需要對另一個表進行聯接。在這種情況下,使用EXISTS(或NOT EXISTS)通常將提高查詢的效率。

4.用表連接代替EXISTS。通常來說,采用表連接的方式比EXISTS更有效率。

5.用EXISTS代替DISTINCT。當提交一個包含一對多表信息(比如班級表和學生表)的查詢時,避免在SELECT子句中使用DISTINCT。一般可以考慮用EXIST替換。

6.WHERE子句盡量少使用NOT或是,應該成OR來實行,使用OR時應該把結果集小的條件放在前面。

7.UNION改用UNION ALL,UNION要對合并的結果進行排序,UNION ALL不排序。

8.ORDER BY子句中盡量不要使用非索引列。

三、結語

通過對SQL查詢語句執行過程的分析,可以從以上幾個方面對其進行優化改進,從而提高了數據庫查詢和檢索的效率。當然,具體的查詢語句還要根據具體需要,并結合具體的數據庫系統而定。只有多總結多積累才能寫出高質量高效率的查詢語句,當然這只是提高數據檢索的一個方面,在其他方面的設計也要進行優化,如對表建立必要的索引,減少表之間的連接,或盡量在索引屬性列上建立連接等。總之,通過以上幾個方面的綜合優化,一定會使數據庫查詢與檢索效率有很大的提高。

參考文獻:

[1]王振輝、吳廣茂,SQL查詢語句優化研究[J].計算機應用,2005,25(12).

[2]徐鳳梅,關系數據庫中SQL查詢語言的優化策略[J].廣西輕工業,2009,126(5).

[3]鄧文艷,基于關系數據庫的查詢優化技術[J].太原科技,2007(12).

[4]楊克昌,Visual FoxPro程序設計教程[M].長沙:湖南科學技術出版社,2004.

[5]李瑩、代勤,關系代數運算與SQL查詢的對應關系[J].內蒙古農業大學學報(自然科學版),2003,24(3).

篇5

【關鍵詞】Mysql數據庫 圖書管理 系統安全 研究

SQL（結構化查詢語言）是世界上最流行的和標準化的數據庫語言。Mysql可以說是目前最為流行的開源數據庫管理系統軟件，是一個真正的多用戶、多線程SQL數據庫服務器。Mysql開放源碼，快捷靈活、穩定和容易使用等優點決定了其在中小型管理系統應用的優勢。本文以基于Mysql網絡數據庫的圖書管理系統為例，從安全穩定性要求和采取的安全策略等方面進行分析研究。

1 Mysql在信息管理系統的應用與優勢

1.1 Mysql的基本特性與應用

Mysql與其他大型數據庫Oracle、DB2、SQL Server等相比，有自身的不足之處，但是沒有影響到Mysql在信息管理系統的應用。在個人或者是中小型的企業，Mysql發揮了自身的優勢與作用。Mysql開放源碼，具有快捷靈活、穩定和容易使用等優點，并有效的提供了PHP、C，C++，JAVA和HTML等主流前端開發軟件的API接口。支持多種操作系統包括Windows 、Linux 、Solaris、Mas OS等。目前，搭建動態網站或者服務器的開源軟件組合有典型的網絡架構LAMP，極大地方便了開發者。Mysql應用非常廣泛，Google、facebook、等使用Mysql作為網絡數據庫。

1.2 Mysql應用于圖書管理系統的優勢

Mysql應用于圖書管理系統的優勢主要分為三個方面，一是免費開源優勢，如果再使用linux操作系統，可以減少購買操作系統和數據庫的開銷。二是多種平臺支持的優勢，Mysql可以與多個平臺進行有效的連接，實現信息資源的共享。三是中小型數據庫靈活穩定的優勢，在設計Mysql程序的時候，加入了SQL中沒有的一些補充條件，更加的適用于在中小型數據庫中使用。圖書管理系統通常要保存用戶信息、圖書信息和借閱信息，以及建立相關的書籍查詢等，數據倉庫并不是很龐大，因此，使用Mysql來管理數據非常合適。

2 基于Mysql的圖書管理系統安全穩定性分析

高校圖書管理系統是基于互聯網的網絡數據庫，通常采用B/S的體系結構，因此，在瀏覽器層、Web 服務器層、數據庫服務器層都會存在安全性要求，以及在操作系統、網絡技術等方面的安全問題。只有控制好圖書管理系統的安全問題，才能保證信息資源的有效共享。

基于網絡數據庫的圖書管理系統的安全穩定性具有以下幾個特點：

（1）較高的穩定性，包括操作系統的穩定性和數據庫系統的穩定性，要保持Mysql數據庫的正常運行軌跡。

（2）數據的保密性能，對客戶信息、訪問瀏覽量、客戶端等進行有效的保密。

（3）運行的速度很快，包括瀏覽器端、數據庫服務器端的訪問速度，以保證數據信息在查找、修改等方面的快速反應。

（4）數據的備份與數據的恢復功能。數據庫服務器中，包括圖書信息、借閱圖書記錄、客戶賬號等在內的相關數據的安全問題，是保證圖書管理系統正常運轉的重要因素。要采取嚴格的防范措施，同時，當發生數據故障的時候，要在最短的時間內恢復數據與系統。

3 基于Mysql的圖書管理系統安全穩定性策略

圖書管理系統通常采用三層B/S結構模式，即用戶層、Wed服務器層和數據庫層。圖書管理系統要注意提高數據庫安全、操作系統安全和網絡安全技術等方面的安全策略。

3.1 優化數據庫設計

比如，在遵循關系模式規范化的基礎上，優化表設計適當增加中間表或增加冗余字段以減少連接查詢所花的時間，優化JOIN操作和子查詢盡量使用全連接避免產生中間表，盡量避免LIKE 關鍵字和通配符進行查詢。另外，還可以修改my.ini文件，對相關參數如sort_buffer_size 、read_buffer_size 、query_cache_size、max_connections等，設置合適的緩沖區大小和MySQL允許的最大連接進程數，以優化服務器提高系統性能，提高保證圖書信息資源查詢效率。

3.2 數據容災與備份機制

要定期地進行數據備份，保護圖書書目數據、流通數據、客戶信息等。定期的進行數據庫的重組工作，增強數據庫的使用性能。用好MYSQL的容災與備份機制，比如：建立主從數據庫集群，采用 MySQL 復制；制定數據庫備份/恢復計劃；啟動數據庫服務器的二進制變更日志；定期檢查數據表；定期對備份文件進行備份；把 MySQL 的數據目錄和備份文件分別放到兩個不同的驅動器中，等等。

3.3 帳戶安全策略

可以從賬戶安全檢查、系統內部安全措施、哈希加密等方面著手進行。比如，檢查用戶表mysql.user是否有匿名空賬號（user=‘’ ），如有應將其刪除。使用哈希加密帳戶密碼。加強客戶的登錄認證，尤其是服務器主機的登錄認證。在主數據庫創建從數據庫操作所用的用戶，并指定使用SLL 認證等等。

3.4 網絡安全和操作系統安全策略

在網絡安全策略方面，利用NAT技術，有效的防止發生來自網絡外部的攻擊現象，將局域網絡內部的計算機系統進行隱蔽。正確設置計算機操作系統，確保客戶使用真實身份，登錄具有合法性。此外，還可以設置系統的實時監控，優化網絡防火墻、文件加密以及殺毒軟件技術的升級，等等。

4 結語

綜上所述，要確保基于Mysql在圖書館管理系統的安全穩定性能，要考慮很多種因素的影響，在數據庫設計、數據庫服務器、數據容災與備份、帳戶安全，以及計算機網絡、操作系統等方面進行優化配置。圖書管理系統的安全與穩定性能保證了信息數據的安全、穩定性與高效，保證了客戶在不同的時間、地點、平臺中有效的使用圖書館的資源信息共享。

參考文獻

[1]晉征.論基于網絡數據庫的圖書館管理系統安全性研究與實現[J].網絡安全技術與應用，2015（3）：27-29.

[2]陽學軍.基于網絡和人工智能的圖書館信息管理系統研究[J].岳陽職業技術學院學報，2005（3）：59-61.

[3]林愛鮮.基于神經網絡的圖書館管理系統的構建研究[J].電腦與電信，2012（4）：48-50.

[4]田華.圖書館分布式數據庫安全技術研究[J].現代情報，2007（4）：161-163

篇6

數據庫技術發展至今已有40多年的歷史,它作為數據管理的有效手段,大大促進了計算機應用技術的發展。從早期的文件系統到層次數據庫和網狀數據庫,從關系數據庫到面向對象數據庫,以及面向不同應用的時態數據庫、演繹數據庫等等,均向人們展示了數據庫技術的廣闊應用前景[2]。關系數據庫,顧名思義是建立在關系數據庫模型基礎上的數據庫,借助于集合代數、離散數學等概念和方法來處理數據庫中的數據。關系數據庫是一個被組織成一組擁有正規描述的表格,該形式表格作用的實質是裝載著數據項的特殊收集體。這些表格中的數據以許多不同的方式被存取或重新召集而不需要重新組織數據庫表格[3]。除了相對容易創建和存取之外,關系數據庫具有容易擴充的優勢。在最初數據庫創造之后,一個新的數據種類能被添加而不需要修改所有的現有應用軟件。目前主流的關系數據庫有Oracle、SQL、Aceess、DB2、MySQL、SQLServer、Sybase等等[4]。根據本校辦學規模和處理信息量,采用ACEESS作為本系統數據庫的管理工具。

2數據庫模型建立

2.1應用需求抽象

根據學員信息管理的具體任務,按照管理功能進行業務劃分和模塊化設計。按照簡單性、獨立性及完整性原則,學員信息管理系統后臺可以分為以下幾個子系統:即學員檔案管理子系統、課程管理子系統、成績管理子系統、中隊管理子系統、管理統計子系統、系統管理子系統、系統維護子系統。(1)學員檔案管理子系統學員檔案管理主要有學員管理、批量學員添加、按中隊批量學員添加等功能。(2)課程管理子系統課程管理子系統主要有課程管理、批量課程添加、任課管理、任課添加等功能。(3)成績管理子系統成績管理子系統完成成績管理、批量成績添加、按中隊成績添加功能。(4)中隊管理子系統中隊管理子系統完成中隊管理、中隊批量添加兩個子模塊功能。(5)管理統計子系統管理統計子系統顯示學校基本信息,包括年級數、中隊數、學員數、教師數、課程數、用戶瀏覽統計等相關信息,還可完成學員統計、排名統計功能。(6)系統管理子系統系統管理子系統包括修改管理員密碼、帳號管理、干部管理、年級管理、學期管理功能。(7)系統維護子系統系統維護子系統主要完成系統的相關設置功能,包括站點名稱,站點LOGO設置,網站主體表格屬性設置,年級變遷(這里主要是對年級進行批量升級操作,也可以在中隊管理下單個進行升級)。

2.2數據庫表關系建立

關系數據庫模式的建立,離不開數據表之間關系的建立,只有建立表之間的關系,整個數據庫才能形成一個系統,提供強大的信息存儲、查詢、和處理功能[5]。對比應用需求說明和現實學校各部門的業務流程,設計數據庫表之間的關系如圖1所示。(1)學員和評語之間存在一對多的對應關系,即一個學員可以有多條來自不同老師的評語;學員和家長存在一對多的對應關系,即一個學員可以對應一個家長,方便家長對學員相關信息進行查詢。學員和平時成績存在一對多的對應關系,即一個學員可以有多種平時成績;同時,學員還和中隊有多對一對應關系,即一個中隊可以有多個學員。(2)中隊和成績有一對多的對應關系,即一個中隊可以有多條成績;中隊和年級有一對一的對應關系,即一個中隊屬于一個年級。中隊和大隊有一對一的對應關系,即一個中隊屬于一個大隊,中隊和任課信息有一對多的對應關系即一個中隊有多條任課關系與之對應。大隊和中隊有一對多的對應關系,即一個大隊對應多個中隊。(3)任課信息表中的教師ID和教師信息表中ID存在一一對應關系。教師表中ID和任課教師信息表中的ID存在一對多的關系。即一個教師可以有多個任課關系。任課教師表中的課程ID和課程表中的課程ID存在一一對應關系。任課信息表中的學期和學期ID存在一一對應關系。即一個任課信息對應一個學期。成績表中的課程ID和課程信息表中的ID存在一一對應關系,成績表中的學期ID和學期表中的學期ID存在一一對應關系。

2.3數據庫模式設計

2.3.1關系數據庫設計中存在問題

(1)數據冗余:在一個數據集合中重復的數據稱為數據冗余。例如在設計時沒有把教師信息表Teacher和任課信息表tea_sub分開,那么每存儲一條任課信息tea_sub(tsid、ts_tea_user、ts_sub_id、ts_ter_id、ts_cla_id)教師表中的其他信息也要重復存儲[4]。(2)更新異常:更新異常分為插入異常和刪除異常。插入異常:比如學員信息表student,如果不知道學號,那么插入再多的其他信息都是沒有意義的。例如一個剛入職的教師理所當然要在任課信息表中有其相關數據,但此時他還沒有任課,即他對應的元組是不完全的,只有而沒有,不能將他的信息放到數據庫中。因此無法注冊該教師的任課信息,這與實際需求不符。這樣的操作是不合理的,將這種現象稱為插入異常。刪除異常:例如在沒分解的教師信息表中的任課信息中,相應的任課關系解除。那么刪除整條記錄,該教師的其他信息也被刪除,在查詢的時候無法查閱該教師相關信息,這也與實際需求相悖,將這種現象稱為刪除異常。數據庫的性能優化包括硬件優化,查詢優化和設計優化三個方面。本文著重介紹設計優化即模式優化,模式優化重點解決數據冗余和更新異常問題。

2.3.2數據庫模式的規范化

在對數據庫進行模式設計時,對關系的分解并不是盲目的,分解的目的在于減少關系模式的規模,避免不必要的存儲及操作的冗余和數據更新異常。為了清除異常,需要對關系模式進行合理地分解。為此,人們設計數據庫設計的規范化理論,以便能夠設計出異常盡可能少的數據庫模式[4]。據參考文獻[4]所述,數據庫模式分為6級,具體的定義見參考書目。分別是1NF:是關系數據 庫對模式的基本要求,即要求屬性的值必須是原子屬性不可再分。2NF:消除了數據庫模式中非主屬性對碼的部分依賴。3NF:消除了數據庫模式中非主屬性對碼的傳遞依賴。BCNF:消除了數據庫模式中一切屬性對碼的傳遞依賴。4NF:消除了數據庫模式中非平凡的和非碼所隱患的多值依賴。5NF:消除了數據庫模式中非平凡的和非碼所隱患的連接依賴[4]。范式的級別由小到大分別是有1NF到5NF。范式的級別越低,冗余與更新異常就越容易產生[6]。(1)滿足1NF的學員信息表分解,在學員信息表中每一個屬性都該是原子屬性,故對部職別進行分解。由消防部隊的編制特點,每個省、自治區、直轄市均有相應的消防總隊;每個地級市、自治州、區都有相應的消防支隊。學校學員來自五湖四海,故對學員信息表中的部職別屬性進行分解。由于有的學員來自總隊和支隊機關,故把部職別分為總隊和部職別兩個屬性,即分解為,province為province表中的省份ID。總隊表設計為province(pid、pname)。在學員信息表中只要存儲省份ID就行。不用再存儲省份名。最長總隊名新疆維吾爾族自治區消防總隊所占字節為26Btye,所占ID為2Byte。按新疆總隊有學員121名計算,模式分解前學員原部別信息中存儲總隊信息需用26Btye×121=3164Byte;而模式分解后存儲ID信息占用2Btye×121=242Byte。(2)滿足BCNF的教師信息表分解,在2.4.1節數據庫設計存在問題中提到數據冗余和刪除異常,在沒分解的教師信息表的任課信息中,相應的任課關系解除。那么刪除整條記錄,該教師的其他信息也被刪除,在查詢的時候無法查閱該教師相關信息,這也與實際需求相悖。要解決刪除異常,即把教師信息表Teacher分解為教師基本信息表teacher和任課教師信息表tea_sub(tsid、ts_tea_user、ts_sub_id、ts_ter_id、ts_cla_id)。這樣的分解既解決了數據冗余的問題,也解決了刪除異常的問題。分解后Teacher和tea_sub關系模式都是1NF,且在其中不存在這樣的屬性A,A傳遞依賴與Teacher和tea_sub的碼、由于關系模式Teacher={R1,R2…,Rn}和tea_sub={R1,R2…,Rn}中Ri(i=1,2,…,n)為BC范式,則關系模式Teacher和tea_sub也滿足BCNF。數據庫的規范化設計還有很多,根據系統應用需求的變更和數據規模的遞增,需要設計相應的數據模式來優化昆明消防指揮學校學員綜合信息管理系統的數據庫性能,使之滿足應用需求,更好地為學校教師、學員和管理人員提供便捷的信息化服務。

篇7

關鍵詞 分布式異構數據庫；高校；數字圖書館

中圖分類號：G258.6 文獻標識碼：B

文章編號：1671-489X（2015）11-0078-02

在我國高校數字圖書館的建設過程中，由于各個數字圖書館在建設的過程中缺乏協調性以及統一性，導致不同高校之間的數字圖書館的資源共享出現嚴重的阻礙，不利于各高校數字圖書館之間的數據交流。各高校數字圖書館之間封閉的特性，導致資源的浪費，也影響了廣大用戶的正常使用。以中間件技術作為基礎可以建立高校數字圖書館之間的分布式異構數據庫檢索模型，能夠為解決當前高校數字圖書館之間的資源共享問題提供可行性的技術方案。

1 分布式異構數據庫的概念

分布式數據庫技術是伴隨著信息技術的發展而出現，是數據庫技術與信息網絡技術相互結合的產物。分布式異構數據庫技術實現了諸多數據庫系統的結合，可以實現不同數據庫之間的資源的共享，同時又不損害任何一個數據庫系統的整體性與安全性。在實現資源共享的同時，每一個數據的完整性、獨立性以及安全性并不會受到人為威脅。異構數據庫的異構性主要體現在三個方面：計算機結構的異構性、DBMS的異構性以及操作系統的異構性。異構數據庫所要實現的最終目標是不同數據庫之間的信息資源、硬件資源以及人力資源的共享。目前，我國數字圖書館在建設的過程中呈現明顯的獨立性的特點，不利于各高校之間信息資源的共享，造成嚴重的資源浪費現象。因此，分布式異構數據庫信息檢索模型在高校數字圖書館中的應用有利于提高資源的利用率。

2 分布式異構數據庫的技術研究

分布式異構數據庫的主要技術包含兩種：一種是中間技術，負責服務器與數據庫之間的連接；一種是數據查詢處理技術，負責信息資源的查詢。

1）中間件（Middleware）是計算機軟件系統與應用軟件系統之間實現連接的軟件系統。中間件的存在，方便了電腦系統各個部分之間的溝通，特別是應用軟件對于系統軟件的集中的邏輯，在現代信息技術應用框架（如Web服務和面向服務的體系結構等）中應用比較廣泛。中間件為實現服務器與數據庫之間的連接提供服務。這類服務系統都有十分標準的程序接口以及網絡服務協議。目前在市場上流通的中間技術主要有OMG公司所提供的CORBA，本文的主要設計就是立足于CORBA。

2）數據查詢處理技術。數據查詢處理技術指的是用戶根據自己的實際需求在客戶端進行搜索并獲得自己所需要的新的技術。數據查詢技術主要是通過科學地選擇有效的方法，根據客戶輸入的條件以獲得滿足條件的信息資源反饋給用戶。就一般情況而言，數據庫查詢技術主要包括四個方面：首先是信息轉化，就是將用戶輸入的內容轉化為內部語言；其次，把語法樹轉換成標準（優化）形式；再次，選擇低層的存取路徑；最后，選擇科學合理的查詢計劃進行查詢，并最后反饋查詢結果。

3 系統模型的建構

CORBA的英文全稱是Common Object Request Broker Architecture，即公共對象請求體系結構，構成當前主要的三大中間技術之一。在設計之初，CORBA就被當作是遠程體系結構，是為了解決不同地區之間的計算機的通信問題。就一般而言，CORBA分為三個不同的主要層次系統。

1）處于最底層的系統是對象請求，構成CORBA系統的軟總線，規定了分布對象的定義以及對語言的映射，得以實現遠距離對象之間的通信以及相互操作。

2）公共服務對象。CORBA的公共服務對象包含有很多內容，如為客戶提供位置服務、安全服務等多樣化的服務。

3）位于最上層的公共設施，它明確規定了CORBA的組件結構以及協作服務中的有效協議。

由于目前CORBA為客戶提供多樣化的服務，所以使用范圍十分廣泛，已成為主流的分布式平臺。

分布式異構數據庫的信息檢索模型 分布式異構數據庫的信息檢索模型是建立在現代高校數字化圖書館的基礎之上的，其主要的圖形結構如圖1所示。

該系統模型可以依據現在學校的網絡，無需另行設計，通過互聯網可以有效地整合各高校數字圖書館之間的資源為客戶提供服務。同時，服務終端和服務器可以處于不同的網絡地點和環境。ORB不再負責完成用戶與數據庫之間透明的同時，并不會對各高校數字圖書館的完整性以及安全性造成任何的威脅。

CORBA中間件層次結構體系 把CORBA作為基礎的中間件結構，主要分為四個層次分明的結構體系：用戶端與ORB之間主要處理用戶與系統之間的交互，為用戶提供統一的、具體的服務；ORB層主要通過ORB為客戶提供透明的路徑搜索服務；應用服務層主要通過相關技術為客戶提供具體的搜索服務；數據庫層主要完成對數據的存儲以及處理。

4 分布式數據庫系統模型在高校數字圖書館中的實現

CORBA的應用是在Java平臺基礎之上實現的，原因是Java可以跨越平臺，以及Java技術本身所具有的可解釋性、可移植性、高性能和面向對象的編程語言以及運行環境等特性。CORBA是一項集成技術，它為已有高校數字圖書館提供各種模塊及組成，通過鏈接技術，CORBA間不同的數字圖書館的信息資源與用戶實現透明性。在應用的過程中，CORBA發揮的作用不僅僅是對象請求，同時也構成一個對象分布式的整體。通過CORBA，Java在各種環境中的使用得到極大的拓展。Java所創建的可移動的對象，可以通過CORBA的連接作用，與數據庫等對象實現相互集成。

建立在CORBA基礎上的分布式的系統模型，用戶在進行使用時，可以使用網絡上的統一的檢索平臺，從各高校的數字圖書館中選擇符合自己實際需要的信息資源。這些服務的實現主要是由Java Beans及JSP來完成的。在Web服務器上選用VisiBroker For Java為該數據庫提供安全的、可靠的、健全的ORB通信服務。Gatekeerper允許向駐留在Web服務器上的對象發出操作請求，并可接收對象的回調。利用Smart Agent搜索并且定位已注冊的CORBA對象， 為客戶端程序和服務端對象通信建立好連接，并提供CORBA對象負載平衡和容錯能力。

5 結語

由于高校在數字圖書館的建設過程中缺少溝通，導致各高校數字圖書館在資源共享方面存在一定阻礙。如何實現不同高校之間信息資源的跨庫檢索，已經成為圖書館管理工作中的一個重點。根據信息技術發展的最新成果，利用分布式數據庫技術可以實現各高校數字圖書館之間信息資源的共享，可以有效提高信息資源的利用率。

參考文獻

[1]孔祥疆.軟件開發方法與建立異構數據庫使用平臺模型[D].烏魯木齊：中國科學院新疆理化技術研究所，2005.

[2]羅林球，孔祥疆，李曉.基于CORBA/數據字典/JDBC的異構數據庫檢索系統實現[J].計算機應用，2006（6）.

[3]朱學芳.國內外異構數據庫統一檢索系統的比較研究[J].情報檢索，2005（12）.

篇8

【關鍵詞】電網地理信息系統；關系型數據庫；圖數據庫；拓撲遍歷

隨著中國電力行業生產管理信息化的不斷推進，大多數電網企業已經建立起基于地理信息系統的輸電網絡、配電網絡規劃、營銷、生產、巡檢、搶修、調度等的系信息化系統。目前常用的地理信息系統對電力設備的信息存儲管理都是架構在傳統的關系型數據庫系統（RMDBS）之上。傳統的關系型數據庫系統應用模式深入人心，已為廣大系統用戶及軟件開發廠商所熟悉。基于傳統的關系型數據庫系統可以快速的開發出能滿足業務需求的應用系統。

但是，當電力企業對電網的管理粒度越來越細致、電力企業業務對地理信息系統依賴程度越來越高、地理信息系統存儲的數據量越來越大時，傳統的關系型數據逐漸暴露出其先天的局限性，其中的一些局限無法簡單地通過應用程序優化得到解決。這時，探討另辟蹊徑、使用合適的數據存儲系統顯得適時與必要。

1 地理信息系統數據庫在電網設備管理上的應用現狀

電網線路及各型設備整體上具備顯著的地理位置相關性，在地理信息系統中，電網線路及設備一般分為三類模型：點模型、線模型、面模型。典型的點模型有桿塔、開關等；典型的線模型有架空線、電纜等；典型的面模型有配電房、變電站（根據不同的管理粒度，如不需對變電站內設備進行管理，則變電站可以表達為點模型）等。基于地理信息系統的電網管理系統，一般包含對電網設備模型的屬性信息的管理功能，包括瀏覽、查找、增加、編輯、刪除等操作，系統存儲著管理中需要的設備屬性信息。其中非常重要的的屬性信息包括：設備所在地理坐標，各設備之間的連接關系，各設備之間的從屬關系，設備本身的狀態信息（例如開關的開合狀態）。所有這些電網設備屬性以及電網設備間的關聯從屬關系，均存放在關系型數據庫中，通常，各企業均采用關系型數據庫（例如Oracle），將這些屬性信息及關系信息存儲在關系表中，通過標準的SQL操作對信息進行新建、檢索、更新。

1.1 主要應用點

地理信息系統通過企業數據總線，與各業務系統進行了松耦合的服務集成和交互，為各業務應用提供各類電網空間信息服務，提供的業務支撐包括以下領域：生產管理、營銷管理、調度管理、搶修管理、綜合停電、電網規劃等。

生產管理應用有：設備圖形描繪錄入、設備屬性編輯、設備連接從屬關系錄入等。

營銷業務應用有：設備查詢定位、電網拓撲分析、專題圖展示、戶變關系交互、業擴報裝輔助決策、負荷遷移輔助決策等。

調度業務應用有：專題圖展現、專題圖審核與、電網圖形數據交換等。

搶修管理應用：應急資源查詢定位、電網拓撲關系分析、熱點查詢定位、專題圖展示等。

電網規劃業務應用：電網規劃模型管理、規劃圖管理、電網現狀分析、區域負荷分析、變電站選址輔助決策、線路供電廊帶等。

綜合停電業務應用：為綜合停電提供電網拓撲數據、停電影響用戶數據。

可以看出，以上應用點可以歸類為三類基本的電網地理信息系統服務：

（1）設備屬性、圖紙錄入維護；對應的業務應用是：生產管理應用。

（2）設備定位查詢、圖紙查詢；對應的業務應用是：營銷業務應用、調度業務應用、搶修管理應用等。

（3）電網拓撲連接分析。對應的業務應用是：營銷業務應用、搶修管理應用、電網規劃業務應、綜合停電業務應用。

1.2 主要的局限性及傳統應對方法

1.2.1 電網設備大并發讀寫性能不高

一般關系型數據庫使用關系表級別的查詢緩存，每次表中的一個記錄被更新，整個表的緩存即告失效，需要重新進行加載，這是一種大粒度的緩存。由于日常使用中生產管理系統會頻繁地調用第一類電網地理信息系統服務“設備屬性、圖紙錄入維護”，直接導致數據庫緩存被頻繁更新，造成系統I/O頻繁，影響到第二類和第三類電網地理信息系統服務。

為應對這個局限性，確保大部分第二類和第三類服務的性能，一般采取對編輯錄入結果延（例如在凌晨進行）的方法，以使緩存更新錯開系統業務高峰。

1.2.2 電網模型屬性增減不靈活

關系型數據庫里，由于所有記錄是按行存儲，原則上是假設記錄的長度（即字段個數及長度）是固定的，增刪字段會引表的重構并導致性能的損失。即使采用字典表的組織形式（如Oracle），也會在日積月累的字段增減使得整個表存儲結構的零碎化，慢慢的導致訪問性能下降。如果生產管理上經常對設備屬性進行調整，這個局限會影響到了前文提到的所有三類服務。

為了減輕這個局限帶來的影響，地理信息系統一般采取預先分配字段的方式，建表時先添加多于實際需要的字段，以應付以后的字段增長需求。這樣的設計能有效抵消屬性字段增減帶來的負面影響，但是造成存儲空間上額外開銷。

1.2.3 電網拓撲分析性能低下

由于地理信息系統所采用的關系型數據庫的特點，每一對電網設備的連接關系都被表達成一個二元組的形式，并被按行存儲在存儲介質中。如圖1所示。

圖1 關系型數據庫中設備邏輯的存儲

關系型數據庫均沒有自帶內嵌的節點物理遍歷存儲過程或方法，當要遍歷一次設備連接鏈時，必然要通過應用程序會存儲過程經過對每一個設備節點進行查找才能完成遍歷。假設該連接表建有索引，對每個節點的查詢時間復雜度即為對索引的查詢復雜度

O（nlogn）（1）

由于這個遍歷過程由應用程序執行，因此執行效率還會受應用程序與數據庫系統間數據傳遞開銷影響。

常見的應對方法是嘗試由應用程序將整個連接表導入內存中以減少遍歷過程中對數據的訪問次數。理論上這種方法是可行的，但實際上由于一條設備連接鏈邏輯節點會分布在表中的各個位置而不是集中在一起，而且整個數據庫的設備總數十分大，把整個連接表導入內存并不可行。此問題也是關系型數據庫在電網設備地理信息系統上難以解決的問題，對第三類服務的執行效率造成很大影響。

2 圖數據庫在電網地理信息系統上的應用前景

前文提到關系型數據庫在電網地理信息系統上的應用局限性，雖然大部分局限性均有辦法通過應用程序優化進行減輕，但由此帶來的應用開發難度提升、軟硬件資源的額外消耗，增加了應用系統的建設成本。并且，這些減輕措施并非真正解決根本問題，當遇到極限場合時，這些局限性又會不可控制地爆發。然而，隨著數據庫技術的不斷發展，關系型數據庫的這些局限性均可以通過使用新型數據庫進行有效地解決。

2.1 圖數據庫的技術特點

為了解決的關系型數據庫的種種局限性，業界研發了大量能解決這些問題且各自具有鮮明特點的不同技術，它們可以與現有關系型數據庫相互配合或代替關系型數據庫，它們被統稱為NOSQL數據庫（Not Only SQL-databases）。其中，圖數據庫（Graph Database），是這些NOSQL數據庫中基于大型稠密網絡結構的一種數據庫技術，其技術特點，剛好可以切合電網地理信息系統的種種需求。

2.1.1 圖數據庫的邏輯結構

圖數據庫里的信息建模使用三種構造單元：

節點；

邊；

屬性。

以上三種單元以以下規則進行組織：

節點和邊有可變的屬性列表；

邊具有方向和類型；

兩個節點間可以存在多條邊。

為更感性的了解這個邏輯結構可以參考圖2。

圖2 圖數據庫的邏輯結構

每一個節點相當于關系型數據庫中的一個記錄，節點中的屬性則對應著關系型數據庫中記錄中的字段。由于節點的屬性表是可變的，應用程序隨時可以為一個節點添加刪減屬性，添加屬性不會影響現有代碼任何邏輯。

另外，圖數據庫與關系型數據庫最大的不同點在于，在關系型數據庫中使用連接表（另一個關系表）來表達的連接和從屬關系，在圖數據庫中已經作為一個基本單元來進行表達。

2.1.2 圖數據庫的物理存儲結構

為了支撐前文提到的邏輯結構，開發者對圖數據庫的物理存儲進行了針對性的設計。

節點是按固定大小的記錄順序存儲在物理介質上；

節點帶有兩個固定指針，分別指向其第一個邊和第一個屬性；

邊記錄包含兩個指針，分別指向邊兩端的兩個節點；

屬性除了屬性值外，還帶有兩個指針，分別指向前同一節點（或邊）的前一個屬性和后一個屬性。

為簡便起見，圖3對圖2中的設備1和設備2在圖數據庫中的存儲進行了表述，其他設備只提及被設備2指向的連接。

圖3 圖數據庫的物理存儲結構

由以上結構可知，由于設備節點是順序存儲的定常結構，節點到邊以及邊到節點又是以指針形式存儲，圖數據庫對單個節點或邊的訪問均是直接定位到存儲位置的，不需要進行額外的物理存儲讀寫來對節點或邊進行訪問。

2.2 圖數據庫的優劣勢

2.2.1 優勢

由于圖數據特殊擁有網絡化的邏輯結構及物理存儲結構，在圖數據庫中對節點根據連接關系進行遍歷十分迅速，由于連接關系在數據錄入時就已經建立完畢并且直接反映到物理存儲結構中，對節點網絡的遍歷（無論是深度優先遍歷還是廣度優先遍歷）時間復雜度是常數級的，即

O（n）（2）

同時，由于圖數據庫每個節點均有獨立的屬性列表，因此，可以在如數據庫任意添加或刪除屬性（對應與關系數據庫中的字段），而不對整個數據庫造成負面影響，從而實現良好的伸縮性。

另外，由于圖數據庫不存在表，緩存也是針對節點級別的，因此，數據更新對緩存的總體命中率的影響比關系型數據庫在相同場景下要輕微。

這些優點，恰恰能解決前文提到的關系型數據庫在電網地理信息系統中應用的三個局限性。

2.2.2 劣勢

在眾多優點的光環下，圖數據庫依然有其短板。首先，其不存在關系表，因此數據節點的組織在數據庫層面的邏輯聯系不顯而易見，開發者往往要閱讀應用程序才能完全明白數據間的關系，造成對數據理解的額外開銷。其次，由于圖數據庫以節點及邊為基礎的物理存儲方式，真對某一屬性進行全量數據的分類檢索可能會十分緩慢，不適合用作屬性檢索類的應用基礎。因此，圖數據庫不能完全替代關系型數據庫，在實際應用場景中，圖數據庫應與關系型數據庫互補長短，才能發揮出系統的最大功效。

3 結論

本文對關系型數據庫在電網地理信息系統中的應用局限進行了分析，并針對這些缺陷結合圖數據庫技術特點探討了應用圖數據庫的可行性，得出以下結論：

（1）圖數據庫的優勢可以有效解決現在電網地理信息系統中由于關系型數據庫局限性遇到的問題。

篇9

【關鍵詞】智能電網；海迅數據庫；PI實時數據庫

0.引言

信息化、自動化和互動化是智能電網的三大特征，這其中，信息化是基礎，是解決智能電網可觀測，繼而實現可控與在控的重要途徑。隨著智能電網建設的不斷深入，越來越多的智能測量裝置遍布整個電網，尤其是各網省公司和直屬單位輸變電設備狀態監測、用電信息采集、配電自動化、發電集團信息化等項目的試點與推廣，產生了大量實時數據。實時數據沉淀生成海量歷史數據，連同調度生產控制大區生成的電網運行方式、關口電量、保護、雷電等歷史/實時數據一起，這些數據是重要財富，是實現精益化管理的重要基礎。如何高效地采集、處理、存儲、檢索和利用這些海量信息，已經成為建設智能電網所要面臨的首要問題。關系型數據庫和實時數據庫是目前數據庫市場上應用較為廣泛的兩類數據庫，故數據的存儲一般采用關系型數據庫或者實時數據庫存儲。本文先介紹這兩個類型數據庫的定義及特點。

1.實時數據庫與關系數據庫

1.1關系數據庫的介紹

關系型數據庫，是建立在關系模型基礎上的數據庫，以關系模型組織數據并借助于集合代數等數學概念和方法來處理數據庫中的數據，用二維表的形式來表示實體和實體間聯系的數據模型。關系模型由關系數據結構、關系操作集合、關系完整性約束三部分組成，具有數據結構簡單、查詢與處理方便、數據獨立性高、理論基礎堅實等特點。關系模型也是目前技術最成熟、應用最廣泛的數據庫技術，設計和實現風險較低，但由于關系模型提供了較高的數據獨立性和非過程化的查詢功能，系統的查詢速度和查詢效率較低，但其仍是數據存儲的傳統標準。

1.1.1關系型數據庫組件

關系型數據庫通常包含下列組件：

（1）客戶端應用程序（ Client ）。

（2）數據庫服務器（ Server）。

（3）數據庫（ Database）。

1.1.2關系型數據庫優缺點分析（相比實時數據庫）

關系型數據庫相比實時數據庫而言，有著以下優點：

（1）容易理解。二維表結構是非常貼近邏輯世界的一個概念，建立在嚴格的數學概念基礎上，數據結構簡單、清晰。因此，關系模型相對其他模型來說更容易理解。

（2）使用方便。通用的SQL語言易學易懂，程序員、數據管理員可以方便地在邏輯層面操作數據庫，而完全不必理解其底層實現。其提供的諸如視圖、存儲過程、觸發器、索引等對象使數據訪問趨于便利。

（3）易于維護。豐富的完整性大大降低了數據冗余和數據不一致的概率。

（4）安全性高。登錄身份驗證功能完善，提高安全性。

1.2實時數據庫的介紹

實時數據庫是數據庫系統發展的一個分支，是一種專用的處理海量實時信息的基于測點模型的數據庫，針對實時采集的具有時序特征的海量數據具有極高的事務處理能力、數據壓縮比和查詢檢索速度。實時數據庫是基于先進控制和優化控制而出現的，對數據的實時性要求比較高，因而實時、高效、穩定是實時數據庫最關鍵的指標。

1.2.1實時數據庫的邏輯結構

實時數據庫邏輯上包含實時數據庫、歷史數據庫和測點數據庫三部分。實時數據庫維護實時數據，實時數據是每個測點時間戳最大的量測值（也就是當前值）；歷史數據庫維護歷史數據，歷史數據由實時數據不斷歸檔沉淀后產生，實時數據庫中往往采用壓縮的方式存儲歷史數據；測點數據庫則維護所有測點的各種信息。

1.2.2實時數據庫在處理實時數據上的優勢

實時數據庫具有實時數據寫入和訪問速度快、歷史數據歸檔和訪問速度快、歷史數據高效壓縮、數據以及接口符合測點模型等優點。但實時數據庫對測點數有限制，而且往往按測點數收費，導致等量數據的管理成本相對關系型數據庫偏高。

實時數據庫在數據通信、數據組織、數據存儲、數據檢索、數據訪問、數據處理、數據展現等方面的專業化及產品化，為構建基于大容量實時歷史數據之上的分析應用提供了便捷穩定的數據支撐，使應用系統可以從更高更深層次充分利用寶貴的生產實時歷史數據。

1.3實時數據庫的和關系數據庫的對比

從下表對關系型數據庫和實時數據庫在數據組織方式、訪問方式、壓縮方式、應用領域等的比較結果可見，實時數據庫產品更適合供電企業生產的需要。這是因為電力生產具有生產、傳輸和使用同時完成的特點，生產過程中產生大量的時序數據，應用也需要大量圍繞著這些實時/歷史數據。實時數據庫在處理時序數據時具有的存儲速度快、數據壓縮比大、節省存儲空間等有點，在供電企業的生產應用中具有不可替代的優勢。

2.實時數據庫產品的介紹

目前市面上比較有名的實時數據庫產品有PI實時數據庫，eDNA實時數據庫，iHistorian 實時數據庫，此外，SyncBASE、海迅和安捷（Agilor）在數據庫市場中也占有一定份額。其中，國際市場占有率最大的PI實時數據庫。另外，我國自主研發的數據庫產品海迅實時數據庫也在配調自動化等領域暫露頭角，取得了較大份額。因此下面重點對比這兩個產品。

2.1 PI實時數據庫

PI是由美國OSI Software公司開發的一套基于C/S架構的實時數據庫軟件應用平臺，主要應用于存儲和獲取時間序列的實時數據，是工廠底層控制系統與上層管理信息系統連接的橋梁。一方面，PI用于工廠數據的自動采集、存貯和監視，作為大型實時數據庫和歷史數據庫，PI可存貯每個過程點的多年數據，并提供清晰、精確的操作情況畫面，用戶既可瀏覽工廠當前的生產情況，也可查看過去的生產情況；另一方面，PI為最終用戶和應用軟件開發人員提供了快捷高效的工廠信息，PI在業務管理和實時生產之間起到了橋梁作用。

2.2海迅實時數據庫

海迅實時數據庫管理系統是江蘇瑞中數據股份有限公司研發的國內擁有完全自主知識產權的大型通用實時數據庫，該軟件在全面總結國內外同類產品優缺點的基礎上按照智能電網、工業自動化系統以及物聯網特點和實際需求精心設計、潛心研制而成，是進行海量歷史/實時數據處理的專業平臺。 （下轉第249頁）

（上接第155頁）3.海迅實時數據庫與PI實時數據庫的對比

以下為PI和瑞中的海迅數據庫在服務器端模塊部署方式，性能指標、組態工具、應用領域、市場占有率等方面的對比介紹。

海迅數據庫有著分布式體系架構和跨平臺特性，讓它在各廠商的實時數據庫產品中格外突出。分布式體系架構使得它能支持更多的測點容量，達到更高的性能。跨平臺特性使它的應用領域更廣泛，使用更安全高效。

篇10

關鍵詞：云計算 數據模型 云數據庫 NoSQL數據庫

0 引言

從2006年Google提出“云計算”的概念至今，云計算正以史無前例的速度發展，國內外各大IT企業都在開署各自的云計算平臺，云計算的應用更趨多樣化，目前在互聯網上我們看到的很多應用都可以看到“云”的身影，諸如“云存儲”、“云安全”、“云物聯”、“云郵件”、“云輸入法”等等。總的來說云計算包括三個層次的服務：基礎設施即服務（IaaS），平臺即服務（PaaS）和軟件即服務（SaaS）。云服務模式實現了資源集中配置和管理，實現按需采購、配置，避免資源浪費，能夠更好滿足用戶不斷變化的需求。同時降低管理維護成本，隨著云計算技術的不斷發展，系統的可靠性、擴展性、穩定性也會更好，云計算將影響傳統數據庫的發展趨勢，云服務模式將逐步得到市場認可，反過來講，傳統數據庫必須能更好適應云計算環境的需求。傳統的關系型數據庫由于其天生的限制，已經越來越無法滿足目前時代的要求，云計算時代對數據庫技術提出了新的需求，主要表現在海量數據處理，大規模集群管理，低延遲讀寫速度，建設及運營成本。雖然它在數據存儲方面占據了不可動搖的地位，但對數據擴展、讀寫速度、支撐容量以及建設和運營成本的要求方面，就稍顯遜色。下面我們來探討適應于云計算的數據庫所支持的數據模型。

1 云數據模型的類型

無論是關系型數據庫還是非關系型數據庫，都是某種數據模型的實現，不同的數據模型可以滿足不同的應用需求。數據模型會影響客戶端通過API對數據的操作，決定了客戶端如何對數據進行編碼存儲。云數據庫的設計可以采用不同的數據模型，目前適應于云計算平臺的數據模型有以下幾類：

1.1 基于云計算的關系模型。關系型云數據庫的數據模型涉及行組和表組等相關概念。此模型的數據結構為一個表是一個邏輯關系，它包含一個分區鍵，用來對表進行分區。具有相同分區鍵的多個表的集合稱為表組。在表組中，具有相同分區鍵值的多個行的集合稱為行組。一個行組中包含的行總是被分配到同一個數據節點上。每個表組會包含多個行組，這些行組會被分配到不同的數據節點上。一個數據分區包含了多個行組。因此，每個數據節點都存儲了位于某個分區鍵值區間內的所有行。微軟的SQL Azure云數據庫就是基于此模型的。

1.2 NoSQL數據庫數據模型。由于在設計上和傳統的關系型數據庫相比有很大的不同，故稱此類數據庫為“NoSQL（Not only SQL）”系列數據庫，即非關系型的數據庫。與關系型數據庫相比，此類數據庫非常關注對數據高并發讀寫和海量數據的存儲，在架構和數據模型方面做了簡化，而在擴展和并發等方面做了增強。此類數據庫種類繁多，且各有優缺點，其數據模型有如下四類：①鍵值（key-value）存儲模型。使用一個哈希表，這個表中有一個特定的鍵和一個指針指向特定的數據。其數據模型為一系列的鍵值對。它能提供非常快的查詢速度、大的數據存放量和高并發操作，非常適合通過主鍵對數據進行查詢和修改等操作，缺點是存儲的數據缺少結構化，不支持復雜的操作。運用此模型的數據庫有BigTable、Tokyo cabinet/Tyrant、Redis、Voldmort、Berkeley DB等。②列式存儲模型。列式存儲和關系模型相似，與關系模型存儲記錄不同，列式存儲以流的方式在列中存儲所有的數據。其數據模型為以列簇式存儲，將同一列數據存放在一起。屬于同一列的數據會盡可能地存儲在硬盤同一個頁中，而不是將屬于同一個行的數據存放在一起。使用列式數據庫，將會節省大量I/O，并且大多數列式數據庫都支持Column Family這個特性，能將多個列并為一個小組。總體而言，這種數據模型的優點是查找速度快，可擴展性強，更容易進行分布式擴展，缺點是功能相對局限。運用此模型的數據庫有Cassandra、HBase、Riak等。③文檔模型。在數據結構上，文檔型和鍵值型很相似，也是一個key對應一個value，但是這個Value主要以JSON或者XML等格式的文檔來進行存儲，是有語義的，并且文檔數據庫一般可以對Value來創建Secondary Index來方便上層的應用，而這點是普通鍵值數據庫所無法支持的。這種數據模型的優點是對數據結構要求不嚴格，缺點是對查詢性能不高，而且缺乏統一的查詢語法。運用此類模型的數據庫有MongoDB、CouchDB等。④圖形模型。圖形結構的數據庫同其他行列以及剛性結構的SQL數據庫不同，它是使用靈活的圖形模型，并且能夠擴展到多個服務器上。其數據模型為圖結構，其優點是可以很方便地利用圖的相關算法，缺點是需要對整個圖做計算才能得出結果，不容易做分布式的集群方案。運用此類模型的數據庫有Neo4J、InfoGrid、Infinite Graph等。數據模型有著各自的優缺點，它們適用于不同的領域。不管選擇關系模型，還是非關系模型，都要根據實際應用的場景做出選擇。有時候單一的數據模型并不能滿足我們的需求，對于許多大型的應用可能需要集成多種數據模型。