首頁 > 文章中心 > 關系型數據庫

          關系型數據庫

          前言:想要寫出一篇令人眼前一亮的文章嗎?我們特意為您整理了5篇關系型數據庫范文,相信會為您的寫作帶來幫助,發現更多的寫作思路和靈感。

          關系型數據庫

          關系型數據庫范文第1篇

          關鍵詞:關系數據庫 理論 實踐

          中圖分類號:TP311 文獻標識碼:A 文章編號:1674-098X(2014)07(b)-0054-01

          數據庫設計(Database Design)是指根據用戶的需求,在某一具體的數據庫管理系統上,設計數據庫的結構和建立數據庫的過程。而關系型數據庫則是創建在關系模型基礎上的數據庫,是借助于集合代數等數學概念和方法來處理數據,使之能夠有效地存儲數據,以滿足用戶的各種應用需求。

          1 數據庫的重要性

          數據庫設計是計算機軟件設計的重要內容,同時也是支撐計算機軟件系統運行的關鍵,是軟件設計的起點,起著決定性的質變作用,必須對數據庫的設計高度重視起來。

          (1)數據庫設計最起碼要占用整個項目開發的40%以上的時間。數據庫是用戶需求的直觀反應和表現,需求的要求和變化都要一一體現在數據庫的設計中。

          (2)數據庫設計不僅僅停留在頁面demo的表面,還有模塊交互、表之間的聯系、中轉數據等所需要的字段。因此,在數據庫設計中不僅包括基本的數據存儲,還包括邏輯數據的存儲。

          (3)數據庫設計完成后,項目80%的設計開發在腦海中已經完成了。在設計每一個字段時,已經考慮好這些字段的運用,在表中如何體現。當數據庫設計完成后,程序中所有的實現思路和實現方式已經考慮清楚了,否則會造成一系列不可預測的問題。

          由此可見,數據庫設計在整個軟件開發過程中起到了舉足輕重的作用。

          2 關系型數據庫設計的基本步驟

          關系型數據庫設計的過程可大體分為四個時期七個階段。

          (1)用戶需求分析時期,主要是了解和分析用戶對數據的功能需求和應用需求,是整個設計過程的基礎,事關整個數據庫應用系統設計的成敗。

          (2)數據庫設計時期,主要是將用戶需求進行綜合、歸納與抽象,形成一個獨立于具體DBMS的數據模型,可用實體―聯系模型來表示,然后將其轉換為已選好的關系型數據庫管理系統RDBMS所支持的一組關系模式并為其選取一個適合應用環境的物理結構,包括存儲結構和存取方法。

          (3)數據庫實現時期,包括數據庫結構創建階段和應用行為設計與實現階段,是根據數據庫的物理模型創建數據庫、創建表、創建索引、創建聚簇等。

          (4)數據庫運行與維護階時期,最后一個階段則是數據庫應用系統經過試運行后即可投入正式運行。

          3 關系型數據庫設計的幾個原則

          在進行關系型數據庫的設計過程中,要遵循以下幾個原則,借此可以提高數據庫的存儲效率、數據完整性和可擴展性。

          3.1 命名規范化

          在概念模型設計中,對于出現的實體、屬性及相關表的結構要統一。例如在數據庫設計中,指定學生Sstudent,專指本科生,相關的屬性有:學號、姓名、性別、出生年月等,及每個屬性的類型、長度、取值范圍等都要進行確定,這樣就能保證在命名時不會出現同名異義或異名同義、屬性特征及結構沖突等問題。

          3.2 數據的一致性和完整性

          在關系型數據庫中可以采用域完整性、實體完整性和參照完整性等約束條件來滿足其數據的一致性和完整性,用check、default、null、主鍵和外鍵約束來實現。

          3.3 數據冗余

          數據庫中的數據應盡可能地減少冗余,這就意味著重復數據應該減少到最少。例如:若一個部門職員的電話存儲在不同的表中,假設該職員的電話號碼發生變化時,冗余數據的存在就要求對多個表進行更新操作,若某個表不幸被忽略了,那么就會造成數據不一致的情況。所以在數據庫設計中一定要盡可能存在少地冗余。

          3.4 范式理論

          在關系數據庫設計時,一般是通過設計滿足某一范式來獲得一個好的數據庫模式,通常認為3NF在性能、擴展性和數據完整性方面達到了最好的平衡,因此,一般數據庫設計要求達到3NF,消除數據依賴中不合理的部分,最終實現使一個關系僅描述一個實體或者實體間一種聯系的目的。

          4 以具體實例設計的關系型數據庫設計的實踐

          以大學教學管理軟件開發中的數據庫設計為例進行分析。

          (1)重視系統的總體設計。總體設計不僅與軟件項目順利開展的進度有關,還與是否可以達到預期的項目開發目標有關。下面以大學教學管理數據庫開發為例進行說明。

          (2)首先對大學教學管理軟件所涉及的數據進行詳細的分析。按照上述的設計思想,共設計了如下表,例如,學生關系表、專業關系表等,然后創建視圖和存儲過程。

          ①學生關系表S:S#(學號),SNAME(姓名),SSEX(性別),SBIRTHIN(出生年月)等字段,主鍵為S#(學號)。②專業關系表SS:SCODE#(專業代碼),SSNAME(專業名稱)等字段,主鍵為SCODE#(專業代碼)。③課程關系表C:C#(課程號),CNAME(課程名稱),CLASSH(學時)等字段,主鍵為C#(課程號)。④設置關系表CS:SCODE#(專業代碼),C#(課程號)等字段,主鍵為SCODE#(專業代碼),C#(課程號)。⑤學習關系表SC:S#(學號),C#(課程號),GRADE(分數)等字段,主鍵為S#(學號),C#(課程號)。⑥教師關系表T:T#(教工號),TNAME(姓名),TSEX(性別)等字段,主鍵為T#(教工號)。⑦講授關系表TEACH:T#(教工號),C#(課程號)等字段,主鍵為TEACH:T#(教工號),C#(課程號)。

          數據庫中的每一個表都建立了主鍵,部分表為了滿足查詢和排序的需要,還需要建立索引。例如查詢學生信息時,除了按學號查詢,有時還會用到按照班級查詢。因此,在學生表中除了對主鍵“學號”建立主索引外,也對“班級”建立了次索引。同時,在數據庫中,數據按照主鍵和外鍵的關系,建立起了關系。另外,根據查詢需要,還建立了教學安排視圖、課程成績視圖和學生平均成績視圖及相關的存儲過程。

          5 結語

          通過前面的分析和研究,數據庫的設計是非常重要的,為之后整個系統的穩定可靠運行提供了穩固的后臺保障。數據庫必須與應用程序的業務需求相輔相成,在設計過程中要嚴格遵循關系數據庫的設計步驟,并靈活運用上述原則。

          參考文獻

          [1] 潘博.計算機軟件數據庫設計的重要性以及原則研究[J].計算機光盤軟件與應用,2013(8).

          [2] 王曉軍.數據庫設計的理論和實踐在軟件開發中的作用[J].科技與生活,2012 (8).

          [3] 孟志偉.管理系統的數據庫設計[J].信息與電腦,2009(7).

          關系型數據庫范文第2篇

          【關鍵詞】Hadoop;非關系型數據庫;安全技術;HBase

          1.Hadoop云計算環境與HBase

          Hadoop是一個分布式系統環境,能夠運行于大型集群上。Hadoop主要包括兩個方面:HDFS文件系統和MapReduce計算框架。在Hadoop中用戶無需詳細了解底層系統的實現細節,即可開發分布式應用程序。在云環境的實際使用時,用戶的核心數據需要上傳到云端,這就會使用戶考慮云端是否能夠保障這些數據的安全性、完整性以及可用性。作為典型的一種云架構,Hadoop環境的用戶在連接服務器時無需驗證即可與服務器進行通信,這就難免存在數據的安全性問題。

          Hadoop上集成應用最多的非關系型數據庫是HBase,HBase的架構是典型的主從結構,包括一個Master和若干個RegionServer,另外還使用Zookeeper作為其數據一致性的協調程序。HBase數據庫底層存儲數據時使用的是Hadoop的HDFS文件系統,客戶端在借助HBase API訪問存儲在HBase數據庫中的數據。

          Zookeeper的作用是保證整個HBase集群中只有一個master節點,同時實時監控regionserver的狀態,一旦regionserver不能繼續提供服務,zookeeper會將其狀態通知給HBase Master。

          HBase數據庫中有兩張特殊的系統表:-ROOT-和.META.。-ROOT-系統表中存儲的是.META.的分片(region)信息,.META.中則存儲了所有的用戶表的分片(region)信息,每個分片都可以存儲到不同的regionserver上。這種類似B+樹的三層結構,可以實現高效的rowkey查詢,并保證HBase數據庫是一個高可靠、高可伸縮的分布式數據庫。

          2.非關系型數據庫及其安全需求

          云計算技術及電子商務的興起,使得互聯網絡上的數據量越來越大,傳統的關系型數據庫已經難以滿足大數據環境中大規模數據處理以及高并發的需求,非關系型數據庫應運而生,非關系型數據庫具有高并發以及高擴展性等特性,并且具有和關系型數據庫不同的存儲結構。

          與關系型數據庫相比,非關系型數據庫改變了其數據存儲結構和架構設計,從而可以更好地處理高并發以及大規模數據的問題。關系型數據庫存儲的是結構化的數據,數據存儲在行列組成的二維表中,所有行含有的字段完全相同;這樣的存儲方式雖然有利于表的連接操作,但當數據量很大時會占用大量的存儲空間,這在一定程度上限制了其處理大規模數據的性能。非關系型數據庫存儲的是“鍵值對”,數據庫中每一行的結構不必須完全一致,每行可以有不同的字段,這樣的松散數據結構非常適合非結構化數據。非關系型數據庫存儲數據的結構如圖1所示。

          與關系型數據庫利用SQL語言作為其訪問接口不同,非關系型數據庫由于沒有固定的字段結構,其訪問接口是鍵值對,這種結構設計使得非關系型數據庫可以隨著數據量的增加而橫向擴展,即如果非關系型數據庫所在的集群服務器數目增加一倍,則其負載能力也相應提高一倍。

          橫向擴展主要是通過數據分片(shard)和分區(partition)實現的,數據分片又可以分為垂直分片和水平分片兩種;水平分片指的是把表中的行劃分為多個子集,這些子集分布在集群中的多個節點上,以此提高整個集群的性能、降低數據出錯造成的影響。非關系型數據庫中水平分片上比傳統的關系型數據庫具有更好的擴展性,由于非關系型數據庫一倍都是基于鍵值對模型的,很少對整個數據庫進行掃描查詢,所以能夠簡單地通過在集群中加入新的節點對方式來進行擴展。

          非關系型數據庫一般是分布式的,其數據分布在多個節點上,所以其安全要考慮內部安全和外部安全兩方面。前者指的是非關系型數據庫內部數據存儲上的安全,主要滿足的是數據庫管理員的安全需求;后者指的是非關系型數據庫客戶端和服務器之間的安全,主要滿足的是數據庫用戶的安全需求。

          3.Hadoop中HBase的安全策略

          HBase是非關系型數據庫中安全性最完善的,對其安全機制進行研究有助于為其他的非關系型數據庫提供一定的參考價值。HBase是集成在Hadoop云計算開發平臺上的,所以Hadoop為其提供了訪問安全機制。Hadoop的安全特性主要包括四個方面:“基于令牌的認證機制、基于Kerberos的安全認證方案、基于ACL角色控制的權限控制,以及HDFS數據存儲的一致性保證和數據完整性驗證”。

          Hadoop中包含服務級和文件級兩類權限驗證,其中前者是系統級別的,后者是文件級別的。對于服務級別的安全驗證,是通過ACL角色控制實現的,默認情況下hadoop中服務級別的安全驗證是關閉的,要想開啟服務級別的安全驗證,可以將配置文件${HADOOP_CONF_DIR}/core-site.xml中的hadoop.security.authorization屬性設置為true。

          除了hadoop.security.authorization屬性外,還有一組類似的屬性可以控制哪些用戶可以訪問哪些資源。借助基于ACL的角色控制,Hadoop可以保證HBase的底層具備服務級別的安全訪問策略,以此限制用戶和組對資源的訪問,從而防止了非法用戶對數據進行惡意操作。

          當HBase的底層文件系統對數據進行讀寫請求時,客戶端可以指定訪問的用戶或用戶組,如果不對用戶進行認證,則客戶端用戶就可能偽裝為其他用戶訪問HBase數據庫中的數據,基于令牌的認證機制有效解決了此問題。Hadoop中有兩種認證機制:基于MD5的令牌認證機制和基于GSSAPI的Kerberos的認證機制;令牌認證又分為兩種:對HDFS文件系統的授權令牌認證和對MapReduce任務框架的任務令牌認證。Kerberos認證包括域內認證和跨域認證兩種,其認證步驟分為以下幾步:

          (1)客戶端程序首先發送相關信息到AS服務器,這些信息包括用戶名IDc、認證域、隨機數以及授權服務器TGS等;使用TGS的密鑰加密后得到TGT。

          (2)客戶端程序獲得AS的應答后,向TGS發送加密的用戶名、認證域以及TGT、服務器名稱等相關信息;TGS解密收到的信息,并根據解密的結果對比確定請求的用戶、TGT票據的所有者等,并產生對應的TS返回給客戶端。

          (3)客戶端解密收到的TGS應答,并發送TS、加密的用戶名及認證域等信息到應用服務器,訪問對應的應用資源。

          HBase數據庫底層的HDFS分布式文件系統具有高度容錯性,不僅可以保證數據存儲的完整性,而且能夠保證數據傳輸的完整性。Hadoop集群中的DataNode定期檢查其自身管理的數據庫,并對其進行完整性驗證,通過驗證的數據塊就滿足數據存儲的完整性;Hadoop的客戶端在和DataNode進行數據傳輸時,會對數據進行傳輸完整性驗證。

          HBase協處理器(Coprocessor)是HBase數據庫中的重要框架,它可以使用戶在服務端插入其定制代碼。HBase協處理器分為兩種類型:系統協處理器和表協處理器,前者能夠全局導入regionserver上所有的表,表協處理器允許用戶指定一張表使用協處理器。為了更好地提供靈活得控制,HBase協處理器提供了兩種不同的執行模式,分別是Observer模式和Endpoint模式,分別類似于傳統關系型數據庫中的觸發器和存儲過程的概念。HBase的協處理器框架允許HBase數據庫實現聚合、訪問控制等豐富的特性。

          4.結語

          本文結合HBase數據庫的分布式特性,圍繞非關系型數據庫中數據的機密性、完整性以及一致性,分析了HBase數據庫的安全需求。在此基礎上,研究了以HBase數據庫為代表的非關系型數據庫的安全機制,包括基于ACL的角色控制機制、令牌認證機制、HDFS數據一致性機制以及HBase協處理器機制等。

          參考文獻

          [1]蔡平.基于Hadoop的NoSQL數據庫安全研究[D].上海交通大學,2012.

          [2]張少敏,李曉強,王保義.基于Hadoop的智能電網數據安全存儲設計[J].電力系統保護與控制,2013(7).

          [3]朱敏.基于HBase的RDF數據存儲與查詢研究[D].南京大學,2013.

          [4]劉河,陳宇.云計算環境下NoSQL數據庫技術及應用研究[J].軟件導刊,2013.

          關系型數據庫范文第3篇

          關鍵詞:SQL Server;Oracle;Transact-SQL;企業管理器;查詢分析器

          中圖分類號:TP311文獻標識碼:A文章編號:1009-3044(2009)14-3614-02

          Large and Medium-sized Database Management System Performance Analysis of Differences

          ZHANG Qun-hui, WANG Cong, TONG Xin

          (Hunan Information Science Vocational College, Changsha 410151, China)

          Abstract: The article introduces the architecture, security model, database file management method, data conversion, backup, restore and replication as well as the Transact-SQL language design. Describes the application process and the flip-flop storage to ensure data integrity and consistency between the realization of the process. Focus on the underlying SQL Server database configuration, management data, performance optimization and security management in detail. Finally, the above study, the SQL Server 2000 and oracle database performance comparison, summed up the characteristics of their own. At present, the practical application in the database field, a lot of database management are some problems still exist, resulting in poor database performance. To study the subject for the selection and application of database systems have a certain significance.

          Key words: SQL Server; Oracle; Transact-SQL; Enterprise Manager; Query Analyzer

          1 引言

          SQL Server 2000是微軟公司最新版的大型數據庫服務器,其性能指標在各方面都有趕超Oracle數據庫的趨勢。在經歷了SQL Server 6.5和7.0兩個版本的嘗試之后,微軟公司終于開始向大規模的業務領域進發了。微軟公司聘請了世界上最優秀的數據庫專家而且專門搭建了信息量可謂空前龐大的地理信息系統,勵精圖治。有了強大的性能和功能支持,并且徹底脫離了Sybase,它將數據庫連接到Internet,并通過Web瀏覽器顯示數據操作,具有客戶機/服務器結構,并與Microsoft公司的其他產品及第三方產品具有良好的兼容性,能方便的實現無縫操作。此外,SQL Server 2000還提供了對分布式事務處理的支持,為大型數據庫項目提供優秀的企業級的解決方案。再配合其一向為人稱道的易用性,SQL Server可以說成為了開發者手中的一柄利器。

          因此,在數據庫需求日益增長的今天。學好SQL對于開發和維護數據庫,以及研究其他數據庫是非常重要的。

          2 SQL Server體系結構

          SQL Server是由一系列數量眾多的數據組件組成。這些組件在功能上互相補充,在使用方式上彼此協調,以滿足用戶在數據存儲和管理、大型Web站點支持和企業數據分析處理上的需求。從不同的應用和功能角度出發,SQL Server具有不同的系統結構分類。具體可以劃分為:

          ?數據庫體系結構

          ?客戶機/服務器體系結構

          ?關系數據庫引擎體系結構

          ?服務器管理體系結構

          其中,客戶機/服務器體系結構又可以劃分為客戶端組件、服務器組件和通信組件三部分。用戶不用直接訪問 SQL Server進行分析服務的,而是使用客戶應用程序來訪問數據的。客戶端-服務器組件體系結構如圖1。

          3 SQL Server主要功能

          SQL Server充分整合Analysis Services 和資料采集(Data Mining),因而可以調整資訊,掌握機會。領先業界支持XML、增強系統管理和調整等工具,以及在企業和電子商務等應用上有著可調適性和可靠性。其主要功能包括管理數據庫文件,管理的安全性,執行管理任務等方面,具體如圖2所示。

          由于篇幅的關系,在這里主要介紹SQL Server在安全方面的管理特點。SQL Server的安全性機制分為4個等級。

          ?客戶機操作系統的安全性

          ?SQL Server的登錄安全性

          ?數據庫的使用安全性

          ?數據庫對象的使用安全性

          每個安全等級就好像一道門,如果門沒有上鎖或用戶擁有開門的鑰匙,則用戶可以通過這道門達到一個安全等級。如果通過了所有的門,則用戶就可實現對數據庫的訪問了。這個關系用圖3來表示。

          4 SQL Server性能優化

          數據庫是企業信息的核心,其應用水平的高低直接影響到企業管理水平。選擇了一個高性能的數據庫產品不等于就有一個好的數據庫應用系統,如果數據庫系統設計不合理,不僅會增加客戶端和服務器端程序的編程和維護的難度,而且還會影響系統實際運行的性能。

          4.1 影響SQL Server性能主要因素及解決辦法

          影響SQL Server數據庫性能的因素有很多。比如:在開發工具、數據庫設計、應用程序的結構、查詢設計、接口選擇等發面都有多種選擇,這取決于特定的應用環境和應用需求。平常在優化SQL Server性能,主要從以下幾個方面著手:

          ?數據庫設計問題

          ?應用系統設計

          ?操作系統相關優化

          4.2 SQL Server優化器

          SQL Server優化器通過分析查詢語句,自動對查詢進行優化并決定最有效的執行方案。主要是通過查詢分析、索引選擇、合并選擇三個階段完成的。完成以上三個過程后,優化器就會生成一個基于費用的查詢執行計劃,這個計劃充分利用了可用的索引,并以最小的系統開支和良好的執行性能訪問原來的數據。

          4.3 SQL Server優化應用分析

          在實際操作過程中,可以先使用SQL事件偵查器創建一個工作負荷文件,來跟蹤一段時間內某個指定數據庫的活動。然后根據跟蹤記錄,使用索引優化向導來對索引進行優化。

          5 SQL Server與Oracle數據庫的比較

          5.1 SQL Server的優越性

          SQL Server是當今最重要的數據庫管理系統之一。之所以能夠在現代數據庫管理系統行列中立于不敗之地,SQL Server有著他獨自的優點。主要體現在以下以個方面:

          1)非過程化語言

          SQL是一個非過程化的語言,因為它一次處理一個記錄,對數據提供自動導航。

          2)統一的語言

          SQL可用于所有用戶的DB活動模型,包括系統管理員、數據庫管理員、 應用程序員、決策支持系統人員及許多其它類型的終端用戶。基本的SQL 命令只需很少時間就能學會,最高級的命令在幾天內便可掌握。

          3)是所有關系數據庫的公共語言

          由于所有主要的關系數據庫管理系統都支持SQL語言,用戶可將使用SQL的技能從一個RDBMS(關系數據庫管理系統)轉到另一個,所有用SQL編寫的程序都是可以移植的。

          5.2 Oracle數據庫介紹

          Oracle9i是業界第一個完整、簡單的用于互聯網的新一代智能化的、協作各種應用的軟件基礎架,其主要特點體現在:

          1)支持大數據庫、多用戶的高性能的事務處理。

          2)ORACLE遵守數據存取語言、操作系統、用戶接口和網絡通信協議的工業標準。

          3)實施安全性控制和完整性控制。

          4)支持分布式數據庫和分布處理。

          5)具有可移植性、可兼容性和可連接性。

          5.3 兩種數據庫的比較結果

          通過對SQL Server數據庫的學習和Oracle數據庫的查閱。總結出兩種數據庫大致區別,如下所示:

          1)開放性

          SQL Server:只能在Windows下運行,沒有絲毫的開放性。

          Oracle:能在所有主流平臺上運行(包括 Windows)。完全支持所有的工業標準。采用完全開放策略。可以使客戶選擇最適合的解決方案。對開發商全力支持。

          2)可伸縮性和并行性

          SQL Server:并行實施和共存模型并不成熟,很難處理日益增多的用戶數和數據卷,伸縮性有限。

          Oracle:平行服務器通過使一組結點共享同一簇中的工作來擴展Window NT的能力,提供高可用性和高伸縮性的簇的解決方案。如果WindowsNT不能滿足需要, 用戶可以把數據庫移到UNIX中。

          3)安全性

          SQL server:沒有獲得任何安全證書。

          Oracle Server:獲得最高認證級別的ISO標準認證。

          4)性能

          SQL Server:多用戶時性能不佳,C/S結構,只支持Windows客戶,可以用ADO,DAO,OLEDB,ODBC連接。

          Oracle:性能最高, 保持WindowsNT下的TPC-D和TPC-C的世界記錄。多層次網絡計算,支持多種工業標準,可以用ODBC,JDBC,OCI等網絡客戶連接。

          5)操作簡便

          SQL Server:操作簡單,但只有圖形界面。

          Oracle:較復雜, 同時提供GUI和命令行,在Windows NT和Unix下操作相同。

          6)使用風險

          SQL Server:完全重寫的代碼,經歷了長期的測試,不斷延遲,許多功能需要時間來證明。并不十分兼容早期產品。使用需要冒一定風險。

          Oracle:長時間的開發經驗,完全向下兼容。得到廣泛的應用。完全沒有風險。

          以上是SQL Server與Oracle數據庫之間較為粗略的比較。具體要考慮該使用什么軟件時,還要根據自己的業務需求和基礎設施來綜合考慮。

          6 數據庫系統回顧與展望

          縱觀當今的商用數據庫市場,稱之為群雄割據毫不為過。自20世紀70年代關系模型提出后,由于其突出的優點,迅速被商用數據庫系統所采用。據統計,70年代以來新發展的DBMS系統中,近百分之九十是采用關系數據模型, 80年代和90年代是RDBMS產品發展和競爭的時代。各種產品經歷了從集中到分布,從單機環境到網絡環境,從支持信息管理到聯機事務處理(OLTP),再到聯機分析處理(OLAP)的發展過程;對關系模型的支持也逐步完善;系統的功能也不斷增強。

          Oracle9i已經出爐,它增強了針對電子商務的新特性,和對因特網應用的支持,提供了對大數據量的在線事務處理(OLTP)環境、查詢密集型數據倉庫以及要求苛刻的互聯網應用的高效、可靠及安全的數據管理能力。

          SQL Server 2000的下一代產品YuKon預計在今年推出。YuKon主要增強的特性大概是集群,每個服務器自己進行數據處理、管理內存、加鎖和事務處理,與此同時保持與集群中其他及其的內部聯系,能做到集群中一臺機器不能工作,不會影響整個系統的工作。

          7 結束語

          在信息量日益增多的今天,數據的管理及安全問題已成為眾多企業的“頭等大事”。隨之而來的,是眾多大中型數據庫管理系統相繼推出,選擇一個好的數據庫系統能在某種程度上來彌補企業數據管理上的一些不足。有鑒于此,本文詳細分析了SQL Server數據庫管理系統的原理,無論是從其安全性能方面,還是從其操作方面來說,SQL Server數據庫基本能滿足多數企業用戶的需要。特別是在安全等級方面,通過圖文并茂的方式得以體現,讓用戶一看就懂,希望能對讀者了解SQL Server數據庫帶來幫助。

          參考文獻:

          [1] Microsoft.企業級數據庫的安裝、配置和管理[M].北京:高等教育出版社,2003.8.

          [2] 李真文.SQL Server 2000開發人員指南[M].北京:北京希望電子出版社.2001.5.

          [3] Microsoft.SQL Server 2000系統管理[M].北京:清華大學出版社,2001.11.

          [4] 李曉,張曉輝,李祥勝.SQL Server2000管理及應用系統開發[M].北京:人民郵電出版社,2002.12.

          [5] 劉耀儒.新概念SQL Server 2000教程[M].北京:北京科海集團公司出版,2000.9.

          [6] 薩師煊,王珊.數據庫系統概論[M].北京:高等教育出版社,2001.7.

          關系型數據庫范文第4篇

          Abstract: There are more and more data produced in equipment management systems. For decision making, all kinds of data must be collected and integrated from different management systems. By analyzing the diversity and isomerous quality of the data resources, the architecture of equipment management data warehouse is proposed in this paper. We discussed important components of the data warehouse. From the macroscopic point of view, the needs of the equipment management system are described by UML and this will help manage and use equipment data more efficiently.

          關鍵詞: 數據倉庫;數據管理;用例圖

          Key words: data warehouse;data management;use case diagram

          中圖分類號:TP302.1 文獻標識碼:A 文章編號:1006-4311(2013)26-0192-04

          0 引言

          隨著大量信息化裝備列裝部隊,圍繞裝備全壽命過程的保障數據日趨增加,繁冗的數據體系,給管理決策增加了難度。當前,裝備部門按照各自的業務職能,在各個環節分別建立了相應的信息管理系統,如裝備儲備管理系統、裝備使用管理系統、維修計劃管理信息系統等。雖然各類應用系統能夠滿足相應業務部門需求,但各類數據庫或文件系統是分散的、獨立的子系統,時效性差,共享困難,無法從統一的角度為領導層的全局分析提供及時、準確的綜合信息[1]。本文提出構建裝備保障數據倉庫的思路與方法,將裝備保障數據及信息進行匯總,按照決策需求,以數據倉庫的形式進行重新組織和存儲,建設綜合性的服務系統。通過使用UML用例圖,對系統整體需求進行分析,為裝備保障數據倉庫的構建提供模型基礎。

          1 裝備保障數據倉庫框架模型構建

          結構框架是構建裝備保障數據倉庫最基本問題,其主要目的是研究裝備保障數據倉庫的靜態結構,利用合適的方法來描述裝備保障數據倉庫系統的結構框架與功能的實現。

          1.1 裝備保障數據倉庫的總體設計方法 數據系統的設計方法通常有兩種,一是依據需求構建的系統開發生命周期(System Development Life Cycle,SDLC)方法,這種方法以需求為驅動,由上層領導提出具體需求,通過設計人員加以實現;二是依據在已有數據構建的數據倉庫環境下的系統開發生命周期(Cycle Life Development System,CLDS)方法[2],這種方法以數據為驅動,通過原有的業務系統與數據,設計上層數據系統。在分析型環境中構建裝備保障數據倉庫,上層分析需求不能像底層業務需求準確給出,存在不確定性,這就使得在構建裝備保障數據倉庫過程中,要使用CLDS的設計方法,從數據開始,結束于需求,將需求分析的過程貫穿在整個設計過程中,整體流程如圖1所示。

          整體流程中,始終伴隨著需求理解,并逐步完善體系構架。從數據源獲取的信息經過數據獲取與集成,進入數據倉庫中心數據庫,通過DSS(Decision Support System)決策支持系統應用編程,使得數據倉庫實現輔助決策功能。在系統測試階段,對系統進行整體測試,并以反饋需求的方式,進行系統的更改和完善。

          1.2 裝備保障數據倉庫的體系結構模型設計 裝備保障數據倉庫的建設,一方面要實現數據的集成,另一方面要實現對上層領導的決策支持,這就要求該倉庫應具有良好的可擴展性和靈活性,能夠適應復雜多變的需求。裝備保障數據倉庫主要以目前運行的業務系統為基礎,包含從裝備設計生產到使用退役的全壽命過程的數據內容[3]。這些數據分布于異構的數據平臺,數據不易集成。我們盡可能地以最基本、最不可分割、最基礎的可復用組件的方法來收集和儲存數據,只有這樣,才能高效地利用數據實現上層領導的管理決策。裝備保障數據倉庫的體系結構建立在傳統的業務系統數據庫之上,將這些數據以統一的格式,集成、存儲在一起,向后通過數據分析技術,最終向各類用戶提供包括輔助決策在內的各類服務。裝備保障數據倉庫體系結構模型如圖2所示。

          現有業務系統數據庫是裝備保障數據倉庫的數據源,從各種數據源開始,通過數據管理與建模工具,對數據進行抽取、轉換、裝載,在元數據的同一規范下,各類數據按照不同的粒度需求,整合存儲在中心數據庫之中。根據用戶需求的不同,建立各類數據集市,以滿足不同業務部門的高效使用。中心數據庫與數據集市通過OLAP(On-Line Analytical Processing)在線聯機分析處理、數據挖掘等多種方式,對數據進行加工處理,最終滿足不同用戶對數據的需求。

          2 裝備保障數據倉庫功能模型構建

          功能建模是為了進一步細化和描述裝備保障數據倉庫功能的組成和邏輯關系,體現系統的實際需求,為裝備保障數據倉庫設計和實現提供支持[4]。這里主要采用UML用例圖的建模方法對系統功能需求進行描述。如圖3所示, “管理功能需求”、“控制功能需求”、“接口功能需求”四個層次的劃分,從不同的側面反映了數據倉庫所應具備的功能需求[5]。根據實際使用情況,將裝備保障數據倉庫得功能需求進一步細化,其中“管理功能需求”分為“裝備數據管理”、“用戶管理”兩部分;“控制功能需求”分為“項目運行控制”和“用戶訪問控制”兩部分;“接口功能需求”包含“數據接口管理”和“外部系統接入”。

          2.1 管理功能需求建模

          2.1.1 用戶管理 用戶是數據倉庫的使用者和操作者,用戶管理主要是進行用戶及相關信息的創建和維護,如圖4所示。

          在裝備保障數據倉庫中,參與者主要包括系統管理人員,上層決策人員、中層業務人員、基層保障人員。系統管理人員負責系統軟硬件維護,根據用戶需求實現系統功能;中層業務人員是系統的主要操作者,并配合系統管理人員保障系統的功能實現與日常維護;上層決策人員與基層保障人員是裝備保障數據的主要使用者,前者側重數據的輔助決策作用,后者注重數據對于保障活動的指導作用。主要用例包括:

          ①“創建用戶”,對用戶進行新建、修改、保存等操作。

          ②“編輯用戶信息”,定義和修改用戶的基本信息(如用戶姓名、職務、所屬部門等)。

          ③“信息上報”,用戶對自身信息進行上報,完善系統用戶信息。

          ④“用戶分類”,按照用戶所屬類型的不同進行分類,以區別數據獲取權限等。

          ⑤“用戶權限管理”,為用戶設置權限,使用戶具備不同的操作內容,如讀、寫、修改、刪除等。

          2.1.2 保障數據管理 裝備保障數據是數據倉庫的核心內容,良好的模型的構建,有利于數據的便捷維護與高效利用。管理裝備保障數據,構建數據創建、使用、維護活動模型如圖5所示。

          其參與者為中層業務人員與基層保障人員,中層業務人員負責裝備保障數據的整體收集、維護,基礎保障人員對權限內裝備保障數據進行上報、查詢。此外系統管理員配合中層業務人員,確保需求功能實現。主要用例包括:

          ①“增加裝備保障數據” 、“刪除裝備保障數據”、“更改裝備保障數據”,系統管理人員在中層業務人員的配合下,實現裝備保障數據的增加。

          ②“數據查詢”,可以按照給定的關鍵詞來檢索所需要的綜合保障數據或系統數據。

          ③“數據上報”,基層保障人員在實際操作過程中,對錯誤數據的修正以及對新數據的添加。

          2.2 控制功能

          2.2.1 項目運行控制 系統控制功能伴隨項目運行而產生,用戶控制功能的實現,必須建立在項目運行的前提下。項目由中層業務人員創建,在實時跟蹤的同時將現實情況及時向上層反饋,如圖6所示。

          其參與者為中層業務人員,同時需要基層保障人員與上層決策人員的配合,主要用例包括:

          ①“項目運行”,項目運行是項目控制的前提,各項控制活動,總是依托項目運行展開。

          ②“項目創建”,最基本的項目運行活動,由中層業務人員參與,創建項目。

          ③“實施跟蹤”,主要根據相應的條件和規則來確定業務活動所處狀態(準備、運行、結束、錯誤等),為控制活動提供依據。

          ④“反饋上層”,通過項目運行數據實現對上層決策的支持。

          ⑤ “決策交互”是對“反饋上層”的擴展,支撐“反饋上層”活動。

          ⑥“信息填報”,用戶對自身信息進行上報,完善系統用戶信息。

          2.2.2 用戶訪問控制 裝備保障數據倉庫由于其業務活動的特殊性,必須嚴格控制訪問,用戶訪問不僅與用戶的身份和權限有關,還涉及相關的軟件工具和業務活動,如圖7所示。

          其參與者為中層業務人員與系統管理人員,主要用例包括:

          ①“項目運行”,項目運行是用戶訪問控制的前提,對用戶身份的驗證、外部系統接入及業務系統的檢查,伴隨項目運行展開。

          ②“登陸控制”,主要檢查用戶是否注冊、是否分配了相應的權限,以決定其是否能執行相應的操作。

          ③“外部系統接入”,主要檢查外部系統接入數據倉庫的情況,并根據授予權限的區別,實現不同數據內容的傳輸。

          ④“上層決策系統接入”,上層決策系統的權限與數據需求都存在差別,根據上層決策的實際數據需求,形成不容的系統接入與數據傳輸。

          “登陸控制”、“外部系統接入控制”、“上層決策系統接入控制”都與“接入控制”形成泛化關系。

          2.3 接口功能 當一些相對獨立的現有或遺留軟件應用系統需要與裝備保障數據倉庫進行交互時,通過項目運行,配合相關功能,實現外部系統管理與數據接口管理,如圖8所示。

          其參與者為系統管理員,主要用例包括:

          ①“項目運行”,系統、數據的接入圍繞項目運行活動展開。

          ②“信息采集”,以采集信息為中心,通過基礎數據上報,原始數據過濾、加載,實現系統與數據的接入。

          ③“基礎數據上報”,基層保障人員將實際保障過程中產生的數據上報,充實中心數據庫。

          ④“原始數據過濾加載”,將繁冗異構的原始數據,通過數據轉換,具備統一標準,以完成數據的交換與共享。

          ⑤“決策信息交互”,當決策有數據需求或決策信息需要時,通過“決策信息”交互實現數據傳輸。

          3 結論

          本文描述了基于數據倉庫技術構建裝備保障數據管理系統的總體構架,并將系統的相關需求以UML用例圖的形式給出。裝備保障數據倉庫在完成數據存儲功能的同時,形成了全方位的保障數據服務體系,是我軍裝備管理工作發展的必然。在服務基層裝備保障、支持業務工作的同時,裝備保障數據倉庫會對有效輔助領導層決策,大大提高裝備綜合保障能力,為提升我軍裝備保障水平發揮重要作用。

          參考文獻:

          [1]吳小勇.基于數據倉庫的裝備體系數據建模方法[J].計算機工程,2006,36(1):76-78.

          [2]張云濤,龔玲.商業智能設計部署與實現[M].北京:電子工業出版社,2004.

          [3]單志偉,等.裝備綜合保障工程[M].北京:國防工業出版社,2007.

          關系型數據庫范文第5篇

          關鍵詞:數據倉庫;飛行大學生;流轉管理系統;應用;研究

          1 數據倉庫概念

          數據倉庫英文名稱data warehouse,簡稱DW,數據倉庫是隨著信息高速發展而產生的一種概念。數據倉庫是為了進一步挖掘數據資源,充分利用數據,它區別于靜態數據存儲,而是一種數據處理過程,在這個過程當中包含數據的收集、數據集中整理、數據加工等幾個過程。數據倉庫沒有嚴格的數據庫理論基礎,更偏向于工程應用,按照關鍵技術劃分為數據的抽取、存儲以及數據的呈現三個方面[1]。

          2 飛行學生流轉管理現狀

          飛行大學生培養模式是兩年內在校本部完成所有本科階段的理論課學習,符合理論課結業后下分院進行飛行訓練。兩年的時間里完成二十多門課程。其他大學生而言,時間緊,課程重。在理學習階段和私商儀考試時間是1.5年到2.5年(即18到30個日歷月),飛行學生采用準軍事化管理模式,學生要在相應的時限內必須完成40余門基礎和專業課程的學習,并且只有考試通過后,并通過私商儀執照理論考試才能下分院。以飛行學院為例,目前學校有五個訓練分院,學生在理論課程全部完成并且順利通過考試后就要下分院進行訓練,同時在中教訓練完成后又要返回學校本部,其中中教在分院訓練時間超過一年。由行大學生培養的特殊性,每個學生的訓練進度情況都不一定相同,學生在下分院以及從分院返回校本部時每個學生的信息都不一樣,為了加強對于學生的管理,數據流轉顯得十分重要。這其中學生的數據包括:學生基礎信息(姓名、學號、性別等),學生課程信息(已經上了哪些課程,是否已經通過),學生執照及ICAO考試情況,學生體檢情況等。

          3 基于數據倉庫的飛行學生流轉管理系統分析

          根據當前的數據情況以及目前飛行大學生管理現狀,現有的學生流轉數據主要是以EXCEL方式管理為主,隨著學生數量增多,學生情況差異,原有的管理方式越來越繁雜,人力工作量越來越大,已經不能滿足當前學生流轉管理的需要。借助計算機技術,我們可以對于現有的數據進行加工,存儲以及統計分析,這樣可以充分挖掘數據價值,并且實現學生流轉數據的科學高效管理。設計基于數據倉庫的飛行學生流轉管理系統通過ETL技術,達到數據抽取、數據清洗,數據轉換,數據裝載的目的。在此基礎上導入學生基礎信息、學生課程信息、學生執照考試信息、學生體檢信息等,從而構建飛行學生流轉倉庫體系結構圖,如圖1所示。

          設計飛行學生信息流轉系統數據倉庫的數據源通過使用ETL技術將數據放到數據庫中去,在這個過程中首先要導入基礎信息包括學生課程信息、學生執照考試信息、學生體檢信息等。

          (1)數據源。數據源是整個系統的基礎,是存儲和管理數據的核心所在。包括飛行學生的各類信息,比如學生基礎信息,學生體檢情況,學生執照考試情況,學生現實表現情況等等。(2)數據處理。數據存儲在系統之后,會根據實際業務需要對于數據庫進行操作,包括數據抽取、數據整理、數據組裝。數據倉庫在管理過程中遵循安全、備份、維護、修復等工作。(3)OLAP引擎。聯機分析處理(OLAP)系統是數據倉庫系統最主要的應用,針對實際使用需要對數據進行有效集成。這樣就可以就行多方位多角度分析得到最終結果[2]。(4)前段展示。通過報表、查詢工具等等對數據進行全方位的匯總分析,最后形成圖標或者報表的形式可以直觀得看到結果。

          4 系統數據模型和功能結構

          系統設計過程中采用“星型”模型,數據庫中至少要包含一張“事實表”,事實表中的每一條記錄都指向各個維表的外鍵,飛行學生流轉管理系統建立學生基礎信息表、學生體檢情況,學生執照考試情況,學生現實表現情況表。具體示例如圖2所示。

          多維數據分析主要完成飛行學生信息流轉數據倉庫建立和數據展現部分的設計,以飛行學生現實表現為例,通過統計分析各學期,橫向以及縱向比較,可以得出某一個學生同時期的現實表現比較或者同其他同學存在的差距或者問題。從而可以得到該生是否有進步,存在哪些問題,同時也可以給航空公司提供一個平臺,了解學員在學生以及飛行訓練階段的情況。

          5 結束語

          建立飛行學生流轉管理系統數據倉庫是一個很復雜的過程,特別是數據搜集,數據處理,數據展示等等。隨著飛行學生日益增多,數據量將會越來越大,傳統人工數據管理顯然已經不能滿足需要。因此借助計算機軟件系統,建立數據倉庫,對于數據進行統一整理,統一管理,統一存放,使得數據合理規劃和整合,搭建便捷的飛行大學生數據流轉平臺,為學校和航空公司管理者提供足夠的信息支持,對于培養飛行員是大有意義的。

          參考文獻

          相關期刊更多

          國際關系研究

          CSSCI南大期刊 審核時間1-3個月

          上海社會科學院

          閩臺關系研究

          部級期刊 審核時間1個月內

          中共福建省委黨校;福建行政學院

          現代國際關系

          CSSCI南大期刊 審核時間1-3個月

          中國現代國際關系研究所