時間：2022-10-02 03:30:59
序論：速發表網結合其深厚的文秘經驗，特別為您篩選了11篇數據庫設計范文。如果您需要更多原創資料，歡迎隨時與我們的客服老師聯系，希望您能從中汲取靈感和知識！
中圖分類號：TP311 文獻標識碼：A 文章編號：1009-3044（2015）31-0001-02
Optimal Design of Case Database in Database Course Teaching
HUANG Xin
（Jiaxing Technician College Department of Trade and Tourism，Jiaxing 314036， China）
Abstract：Aiming at the problem of selecting the teaching cases in， we analysis and research the case database designed int the domestic and mainstream textbook of database course. We propose a forum database named “simpleforumdb” as teaching and laboratorial case， and the detailed design of this database is given at the mean time.
Key words：database；course teaching；case database design
數據庫技術是現代IT技術的重要支撐技術，是構建各類信息系統與應用系統的核心技術和重要基礎[1]。教育部的相關文件指出“當代大學生應具備利用數據庫技術對信息進行管理、加工和處理的意識與能力，用以解決本專業領域中的問題的能力”[2]。
國內主流數據庫課程教材在組織內容時，雖然有的側重數據庫實現原理的介紹，有的以某一數據庫管理系統（如Oracle、MySQL等）為平臺介紹數據庫技術的應用，有的兼顧理論和技術，但無一例外都引入了一個或多個數據庫教學項目作為貫穿全書各章節、演示數據庫關鍵概念和技術的案例。許多在教學中廣泛使用的案例數據庫較為簡單，與實際工程項目相差較大，不能很好地覆蓋數據庫課程所有知識點，導致學生在未來工作中遇到實際項目時無法快速上手。如何設計合理的教學案例數據庫已成為數據庫課程教學亟待解決的重要課題。
1 主流數據庫課程教材使用的案例數據庫分析
下面從本?？苾蓚€教學層次，選取兩本主流數據庫課程教材中引入的案例數據庫加以分析各自的優點和不足。
1.1 圖書管理系統數據庫
由南京師范大學鄭阿奇教授主編的數據庫課程系列教材被列為普通高等學校國家級規劃教材，在職業院校和應用型本科院校的數據庫課程教學中廣泛使用。該教材以圖書管理系統數據庫作為教學案例[3]。
1.1.1 圖書管理系統數據庫邏輯結構
圖書管理系統數據庫的邏輯結構[3]如下：
1）管理員表：Administrator（角色名，密碼，備注）
2）讀者表：TReader（借書證號，密碼，姓名，性別，出生時間，專業，借書量，照片，備注，聯系方式）
3）圖書表：TBook（ISBN，書名，作譯者，出版社，出版年月，價格，復本量，庫存量，分類號，內容提要，封面照片）
4）借閱表：TLend（借書證號，ISBN，圖書ID，借書時間，應還時間）
5）還書表：HLend（編號，借書證號，ISBN，圖書ID，借書時間，還書時間）
6）借出表：TBLend（圖書ID，ISBN，是否借出）
1.1.2 圖書管理系統數據庫設計分析
優點：圖書管理系統數據庫設計較為完整，學習者不難結合其他程序設計語言（如C#、JSP、等）構造出一個實用的數據庫應用系統作為課程設計。另外，該案例數據庫的屬性較為豐富，可涵蓋SQL語言的主要數據類型。
不足：第一，可能是為了方便數據查詢，圖書管理系統數據庫設計上存在不規范問題：部分表沒有達到3NF的規范化要求。例如在借閱表TLend中，存在非主屬性ISBN對碼（借書證號， 圖書ID ， 借書時間）的部分函數依賴[4]。還書表HLend也存在類似問題。改進的方法是從借閱表TLend和還書表HLend中去除屬性ISBN，同時在TLend中加入“編號”屬性作為該表的主碼。第二，圖書管理系統數據庫的設計存在冗余問題，部分屬性屬于冗余屬性，可以從相關表中去除[4]。例如圖書表TBook中每本書的“復本量”和“庫存量”可通過對借出表TBLend中相關記錄進行聚集函數查詢（使用函數count）得到，所以這兩個屬性應該從圖書表Tbook中去除（如果存在，為了維護數據完整性系統將付出很大的性能代價）。第三，和企業實際工程項目相比，圖書管理系統數據庫略顯簡單。
1.2 學生選課數據庫
由中國人民大學王珊和薩師煊兩位教授編著的《數據庫系統概論》一書引入的案例數據庫――學生選課數據庫在國內多數本科院校授課時廣泛采用[5]?！稊祿煜到y概論》也是國內第一部介紹數據庫的教材，一直被國內大多數本科院校作為課程教材和主要教學參考書。
3、邏輯結構設計：將概念結構轉換為某個DBMS所支持的數據模型；
4、數據庫物理設計：為邏輯數據模型選取一個最適合應用環境的物理結構；
數據庫系統是隨著計算機在數據處理方面的應用發展而產生的。從19世紀50年代末開始,數據管理技術就一直是計算機應用領域中的一項重要技術和研究課題。利用計算機實現數據的管理經歷了三個發展階段:(1)人工管理階段;(2)文件系統階段;(3)數據庫階段。數據庫系統的起源則在60年代中期,其發展始終以數據模型的發展為主線。按著數據庫模型的進展情況,數據庫系統的發展可以劃分為三代:(1)第一代數據庫系統,即層次數據庫系統和網狀數據庫系統;(2)第二代數據庫系統,即關系數據庫系統(RDBMS);(3)第三代數據庫系統,即面向對象數據庫系統。一般來說一個完整的數據庫系統由四個部分組成:數據庫、數據庫管理系統、數據庫管理員和應用程序。目前關系型數據庫的使用范圍最廣，人數也最多，不過針對某些特殊需求一般的關系型數據庫則無能為力，比如醫學數據庫。醫學數據庫主要包括兩種，一是醫學文獻的數據庫，它包括了基礎醫學、臨床醫學、預防醫學、藥學、口腔醫學、中醫學及中藥學等生物醫學的各個領域的文獻這種數據主要是提供有自由詞，中文文題，英文文題，作者，摘要，參考文獻，期刊名，出版年期，文獻類型，特征詞等的檢索，這類醫學數據庫和一般的數據庫系統沒有太大區別；二是醫學臨床信息數據庫，這種數據庫用于記錄病人全面詳細的信息，主要用來支持醫生的診斷，使得醫生可以對醫療全過程（FullMedicalProcesses）進行規范、監督、控制、管理和分析統計。這種數據庫數據結構較為復雜，通過傳統的數據庫形式已經無法滿足要求。
2、國外的醫學數據庫研究現狀
外國的醫學數據庫研究起步較早，已經取得了相當多的成果，像美國國家醫學圖書館(NationalLibraryofMedicine)的可視化人體項目，他們通過獲取男性和女性的1mm間隔的CT和MRI數據，用于醫學教育和科研；美國的EMBBS醫學圖像數據庫也主要用于教學和管理信息，該數據庫擁有大量實用的臨床照片、X光照片、文章、工作指南以及臨床信息等;南佛羅里達大學的圖像數據庫，該數據庫用于為研究機構提供圖像，促進圖像顯示技術及教學輔助工具的開發;類似的還有Rorida的病理學者Dr.JohnMinarclk首先開創的腫瘤圖像數據庫(Tumorboard)，美國卡耐基梅隆大學的圖像數據庫等。
3、醫學臨床信息數據庫的需求與設計
3.1醫學臨床信息數據庫的需求和工程數據庫特點
數據是數據庫的核心，醫學臨床信息需要處理的數據具有一些特點：（1）類型比較復雜，既有傳統的數值和文字，還有大量的臨床照片、X光照片等信息，以后還可能進一步的有視頻和音頻信息需要存貯，類型多，所需的存儲空間大；（2）臨床數據需要進行動態的版本管理，應該能夠體現出整個的診斷過程；（3）臨床數據之間往往具有豐富的關聯語義。這些特點和工程數據庫有很多相似之處，這使得在進行醫學臨床信息數據庫建立的過程中可以參考借鑒工程數據庫的理論和知識。工程數據庫是面向對象的數據庫系統，能夠支持復雜對象(如圖形數據和工程設計文檔)的表示和處理;可擴展的數據類型;支持復雜多樣的工程數據的存儲和集成管理;變長結構數據實體的處理;工程長事務和嵌套事務的并發控制和恢復;設計過程中多個不同數據版本的存儲和管理;支持模式的動態修改與擴展和支持多種工程應用程序等。以上的工程數據庫功能的實現方式都可以用來指導臨床信息數據庫的建立。
3.2醫學臨床信息數據庫的設計
中圖分類號：TP311.1 文獻標識碼：A 文章編號：1007-9416（2015）11-0000-00
Web服務中大多是以文件傳輸的形式來進行管理和運營的，但是隨著社會發展信息量的加大，系統的反應速度受到很大影響，并且Web的應用領域逐漸擴大，已經不能夠滿足人們對于信息實時性的要求；另外，數據庫近幾年的發展十分迅猛且數據庫的功能強大，能夠快速檢索查詢大批量的數據，達到高效運行的目標。所以Web數據庫就將Web技術與數據庫技術相結合，這不僅能夠將二者的優勢相互結合，最重要的是可以將數據庫的重要資源放到網絡平臺進行檢索和瀏覽，使用戶能夠在瀏覽器輕松跨平臺實現多媒體的服務。Web數據庫作為研究設計的方向，與傳統的數據庫有明顯的不同，比如體系結構以及訪問方式等等。
1 Web數據庫系統的體系結構
數據庫系統的體系結構是涵蓋了系統硬件、軟件以及語言和算法的綜合性概念，具體指的就是組成計算機系統的各部分之間的相互關系。對Web數據庫系統結構的研究主要就是對其硬件分布及軟件功能分配方面的內容。一個邏輯性清晰、開發容易和便于維護的數據庫系統的建立必然是以一個統一的體系結構為指導，同時還要對系統的軟件功能分配及硬件分布進行科學的規劃。
數據庫系統體系結構是隨著計算機模式的改變而不斷的改變，與計算機體系結構有著緊密的聯系。伴著計算體系的集中模式和C/S模式以及三層C/S模式的演變，數據庫體系結構也歷經了集中式的主機結構和C/S結構以及多層的C/S結構演變。
2 Web數據庫應用編程模型
Web數據庫經過兩種技術的結合，需要解決的就是各個模塊之間復雜的信息傳輸交換方式以及對于數據庫的管理和運行，另外還有在設計應用編程中模塊和層次間的銜接和整合中存在的問題。
2.1 MVC模型
不管是什么樣的應用程序都需要對相關的流程進行控制，根據這些就能夠總結出常用的設計模型，在MVC模型中應用程序由三部分組成：模型：是程序的核心邏輯，面對應用領域的抽象對象，對其傳輸的信息要求進行檢索和瀏覽，實現完成業務的目的。視圖：這部分主要是面向用戶的應用程序，負責用戶與數據庫應用程序的鏈接作用。一方面，視圖能夠為用戶提供所需要的信息輸入方式，并能夠將需求以最快的速度傳輸給邏輯應用領域；另一方面，在傳出形式上，將邏輯結果以一定的方式呈現給用戶?？刂疲壕褪菍⑦壿嫵绦蚺c視圖之間進行模式切換，方便兩者的信息數據接收和傳出。一方面，能夠將視圖傳來的信息進行解讀，以一種系統能夠接受理解的方式傳送出去；另一方面，將邏輯結果和模型的轉變的執行進行處理，反饋給用戶。
針對MVC模型應用程序的優化設計，包括對用戶界面、流程控制以及邏輯方面的設計，將各部分進行分離，然后設計開發出個部分之間的接口，根據不同部分的主要功能，選擇最合適的接口技術進行開發設計，最終形成完美結合，突出模型的技術細節和重要功能。
2.2 Web數據庫應用系統設計開發中存在的問題
Web數據庫的設計開發主要包括三個方面，分別是網頁的設計、業務邏輯的設計以及數據庫的管理設計。這些實際都是由多個開發人員應用不同的技術來結合成一個完整的程序的，所以編程技術很多，對應的客戶的主機也要進行不斷地升級才能夠接受高功能的程序邏輯。在開發Web數據庫的應用程序時，要考慮到運行速度、效率以及邏輯功能等多方面問題，同時各種技術自身都存在一定的不足，如果只采用一種技術來連接Web數據庫各部分之間的接口會帶來很大的運行困難，所以需要采用多種技術共同設計開發，保證Web數據庫的高效率運行。
目前的Web數據庫存在的種種問題，主要是編程模型的開發問題，從而造成的網頁、邏輯和數據庫之間的交流不順暢。在設計開發的過程中引用系統、合理有效的編輯模型，要求設計和開發人員務必按照一定程序來對各部分接口進行獨立的設計和開發維護，并保證不影響整體之間的交流和鏈接。
3 Web數據庫的安全性設計分析
在對Web數據庫進行設計的過程中首先需要對其工作環境進行最優化的系統安全配置，進而有效避免非法人員對Web站點的攻擊，其具體包括了對操作系統、相關服務器的安全配置，只有將相關工作有效的結合起來，才能為Web數據庫的建立提供一個安全的工作環境。3.1服務器的安全配置
對系統不同層次的運行環境要提供出具有較強針對性的安全機制。（1）操作系統的安全設置及措施。在用戶進行使用系統之前首先需要做的就是登錄，對于一些不能成功登錄的用戶，系統禁止其使用服務器的一切資源；對系統所有的默認賬號和密碼進行刪除，同時限制用戶嘗試登錄系統的次數；將系統磁盤設置為只讀模式；對于系統中一些重要的目錄要進行及時的備份，避免丟失；對用戶的硬盤使用空間進行限制；對于允許訪問系統的用戶，對該用戶資源訪問權限進行設置。（2）數據庫的安全設置。Oracle的安全模式設置為標準的安全模式，設置用戶只能通過登錄ID號以及相關口令進行數據庫服務器的訪問；對不同的用戶在數據庫的管理系統中給予不用的用戶名設置；同時賦予不同的用戶不同的權限；對系統中的用戶名和對應口令進行定時的更改；定期的對應用程序中的用戶進行審計。
3.2數據庫應用程序的安全性設計及實現
對于服務端的應用程序采取了以下幾種安全性措施，如下所述：（1）程序連接數據庫的應用，Oracle中對數據庫的連接用戶進行用戶名的設置，并賦予其相應的訪問權限。同時在應用程序中設置了用戶的登錄名和登錄口令。在應用程序進行數據庫鏈接時，利用系統賦予的用戶名和口令方能進行數據庫的訪問，隨后實現Oracle原有的全部用戶以及管理權限才能得以實現。具體實施方案：對于每一個數據庫的應用程序設置一個相應的數據庫賬號，該賬號對所有的數據信息都具備了操作的所有權限。另外，這對于系統的操作人員還需要創建一個系統賬號。這樣一來，當用戶在訪問數據庫時，必然會以真正的數據庫賬號進行登錄，然后是相關登錄程序的執行過程。這一安全體系直接造成的結果就是整個應用系統成為了數據庫的直接用戶，而系統的所有操作人員卻成為了數據庫的間接用戶。也就是應用系統在完成了相應的邏輯基礎之上，還徹底的分割開了數據庫和系統用戶，為數據的安全提供了一道堅固的“防火墻”。（2）有效的增強用戶的授權機制。在系統中不僅對Oracle的數據用戶采用了授權機制，對系統賬號也采用了手段機制，在上述的安全體系中，應用程序有效的為數據庫和用戶之間提供了一道安全防火墻，這對應用程序本身的要求就需要具備足夠的安全特性。由于用戶授權管理機制的嚴密性將對整個系統的安全將產生直接的影響，所以強化用戶授權機制就顯得尤為重要。本文研究的系統中將整個系統根據其功能特性將其劃分為了多個最小的權限單元，這些單元同時都具備了可分配的特性，單元權限主要也就表現在了對數據庫相應表格屬性以及視圖文件的操作等內容的劃分上，然后再有效的結合相關系統操作人員的工作性質，運用工作組或角色的概念，完成了應用系統賬號基本等級的創建工作，如根據等級的不同可將用戶分為普通游客、初級會員、高級會員等，同時賦予了不同等級的用戶群不同的使用權限，由此以來使得系統權限管理工作得到了有效的簡化。為了使系統安全管理的靈活性有效提高，對系統某一等級的用戶的權限，授權管理模塊需要做進一步的限制工作，以實現所有權限均能達到任意組合的應用效果。除此之外，為了保證相關管理工作人員工作效率的有效提高，對所有的系統權限和每一種等級的用戶群體以及不同用戶所對應的不同組合權限，建立一部完善的數據詞典，為的就是能夠保證在任何一種工作環境下，工作人員都能夠方便的對用戶等級進行添加或者對不同等級的用戶權限進行修改等操作；為了能夠有效的限制某一系統應用賬號的繼續使用，該系統還需要設置相應的賬號封鎖或解凍的功能。（3）系統的審計和檢測。系統的檢測和審計工作對整個系統的安全穩定具有重要的意義。系統中的日志系統具有良好的數據庫操作數據的采集以及記錄功能。日志系統能夠有效的記錄某一用戶在登錄系統直到退出系統這一訪問時間段內的所有操作，包括了用戶在登錄過程中的失敗操作以及在成功登錄系統后所執行的增、刪、查、改等一系列的操作行為。日志記錄的內容還包括了用戶的IP地址以及名稱、操作類型及操作對象等多項內容。為充分保證系統的安全性和穩定性，系統管理工作人員就需要對日志記錄的文件內容進行必要的審計和檢測工作，及時的找出系統中存在的不安全因素，并做出及時的處理。
4結語
近幾年來，隨著網絡信息鋪天蓋地的傳播，人們對信息的及時性和有效性的要求越來越高，Web技術的靜態網頁內容已經遠遠滿足不了人們對于信息的追求。本文將數據庫技術與Web技術完美設計結合，實現了全球信息資源的交流和共享，促進了各行業的迅猛發展。同時Web數據庫的設計成功，也激勵了企業單位的創新精神，建立自己的Web數據庫系統以積極適應信息的快速發展。
參考文獻
1.1虛擬數據庫的基本操作數據庫的基本操作分為插入，更新，刪除，查詢，針對每張表的操作方式，也是基于基本的四類操作，根據操作條件進行操作，總可以將數據轉化成SQL語句進行操作。
1.2虛擬數據庫的實現虛擬數據庫操作的底層接口是各種物理數據庫提供的API，虛擬數據庫需要將這些API集中地封裝起來，并根據用戶的需求選擇使用。封裝結構可以如下所示。示例中僅封裝了幾個常用的數據庫API，也可以根據需求追加定義其他API進入封裝結構，也可以根據用戶需求隨時將其他數據庫API封裝進來。
2數據下發過程
2.1數據正常下發過程（1）底層網元首先向上層網元上報數據資源審計請求，并將底層網元的數據標識（通常為MD5校驗碼）帶給上層網元。（2）計算底層網元數據審計標識，判斷底層數據是否與上層網元數據一致，如果一致，發送數據審計結果正確給底層網元，否則發送數據不一致給底層網元。（3）根據結果判斷，如果無需同步，向上層網元發送數據審計流程結束，如果需要同步，向上層網元發送數據請求，數據請求中包含請求數據表，以及數據指針，用于標識上次請求到的數據位置。（4）按照請求數據，從數據庫中取出數據，以及數據指針，封裝進數據下發包。（5）數據循環向下層網元發送，直到底層網元不在請求數據為止，同時底層網元上報數據審計流程結束，完成數據下發過程。
2.2數據異常下發過程（1）底層網元在無法打開本地的數據庫情況下，判斷為本地數據庫已經損壞，向上層網元發送數據庫崩潰通知。（2）生成下層網元的數據庫，根據網元類型，通過FTP向底層網元發送數據庫文件或者數據文件。（3）底層網元接收完成數據庫后，打開數據庫，上報數據資源審計請求。
中圖分類號:TP311文獻標識碼:A 文章編號:1009-3044(2009)36-10176-02
Discussion on Principles for Database Primary Key Design
CHANG Yu-hui
(Jiangsu Technical Teachers College, Computer Engineering, Changzhou 203001, China)
Abstract: Primary keys are very important in databases, and .their design directly affects the application and performance of database systems. Starting from the concept of the primary key, the paper compares the commonly used design methods of the primary key, and proposes the relevant principles for primary key design.
Key words: Database; primary key
1 主鍵的概念及其設計主鍵的必要性
在我們進行數據庫設計中,不可逃避的就是要定義數據庫表的主鍵,主鍵的設計對整個數據庫的設計影響很大,因此我們不得不要重視起來。那么我們首先來看看什么是數據庫的主鍵和與它密切相關的外鍵。
1.1 主鍵
能夠唯一表示數據表中的每個記錄的字段或者字段的組合就稱為主鍵(主碼)。一旦確定為主鍵則該字段不可為空也不可以重復。一個主鍵是唯一識別一個表的每一記錄,但這只是其作用的一部分。主鍵的主要作用是將記錄和存放在其他表中的數據進行關聯。在這一點上主鍵是不同表中各記錄之間的簡單指針。所以主鍵的值對用戶而言是沒有什么意義并且和它要賦予的值也沒有什么特別的聯系。比如學生表中的學號就可以定義成該表的主鍵。
1.2 外鍵
外鍵的定義是相對于主鍵而言的若有兩個表A、B,key是A的主鍵而B中也有key字段則key就是表B的外鍵。比如另有一張成績表表中也出現了學生表中的對應學號字段則相對于學生表學號就是成績表的外鍵。
1.3 設計主鍵的必要性
有些朋友可能不提倡數據庫表必須要主鍵,但在我的思考中,覺得每個表都應該具有主鍵,不管是單主鍵還是雙主鍵,主鍵的存在就代表著表結構的完整性,表的記錄必須得有唯一區分的字段,主鍵主要是用于其他表的外鍵關聯,本記錄的修改與刪除,當我們沒有主鍵時,這些操作會變的非常麻煩。主鍵除了上述作用外常常與外鍵構成參照完整性約束防止出現數據不一致。所以數據庫在設計時主鍵起到了很重要的作用。
2 主鍵設計的原則
大家都設計過數據庫,也為表定義過主鍵,我想闡述的是,應該如何正確的設計一個主鍵,在以往的一些資料中,都只是提了主鍵設計的方法而沒有提及到主鍵設計的原則。針對于此,我對幾種常用的設計主鍵的方法做了如下總結:
2.1 是否要采用自動遞增的方式
對于以前談到的主鍵,要求唯一性,因此大家都用自動遞增的方式。這樣的方式是非常不可取的。可能是為了方便插入記錄時,不必去人為創建主鍵值。以為這樣會方便,其實不是的。帶來的麻煩要遠遠勝于這種所謂的"方便"。第一,數據導入不方便,經常會有從另一系統導入數據進來,自動遞增的主鍵,將不允許原表中的ID被導入進來。這會導致主鍵丟失。第二,對于象訂單這樣的有主外鍵的表來說,如果訂單的"主檔表"主鍵是自動生成的,那么在保存一個訂單時,會要求對主檔表與明細表同進行事務保存,而此時,先要生成一條訂單,然后取出這個訂單自動生成的主鍵,然后再把此作為明細表的一個外鍵,進行明細的保存。這過程中,將變的復雜而且不可行,事務將如何處理呢?訂單主檔表插入記錄后,要是明細保存時遇到錯誤,主檔表記錄還要進行刪除。繁瑣。插入成功以后,還要取出產生的最大值。這將是一個嚴重的浪費。記錄多的話會影響速度,而且會存在并行插入。導致獲取的記錄可能是不正確的。因此在以上的嚴重問題下,請不要采用自動遞增方式。
2.2 是否要采用int型作為主鍵
以前大家都采用int型作為主鍵,導致主鍵的值都是數字。其實我們也明白。并不是只是數字的東西就是數字型的,比如電話號碼等。因此對于主鍵采用int型的優勢是速度快插入查詢時都可能會比其他的方式快。但我這種快的效果也未必有多明顯比如以varchar(15)為例物理主鍵排序的數據會自動以主鍵進行物理數據排序。因此就算是字符型的數據在插入時也會插入到相應的物理位置上也就是說在插入時可能會影響一些速度。但在以后的查詢中速度影響不會太明顯。而我要說的不采用int型作為主鍵不是說里面不存數據。我還是建議大家在主鍵中存放數字這樣的排序比較要比夾雜字母的排序來的快之所以要采用字符型也是為以后的數據導入作準備有一天會要求從其他表導入數據時可以在導入數據的主鍵上加一個特定字母來避免與原主鍵沖突。比如在導入數據的主鍵前加一個“N”字母。這也就不用擔心要求導入數據表中的主鍵是數字型還是字符型了。
2.3 是否采用編號來定義主鍵
主鍵設計有個原則就是主鍵不應具有任何實際意義,這條其實是非常重要的。有人就是覺得編號本身是唯一的可以作為主鍵用但可能會為以后帶來麻煩。因為帶有實際意義的字段還是存在被修改的可能性,而對于主鍵最大的忌諱就是修改主鍵,這可能會導致非常嚴重的不可估計的后果。比如學生編號平時以為永遠不會修改但修改的可能還是會存在。
還有一種表面上是唯一的但實際上應該是允許重復的。舉個例子,訂單編號應該是唯一吧。邏輯上是的,可是會存在這樣的情況一張原來的訂單是因為某個原因要求訂單作廢。那好給訂單的狀態標識為"cancel"。然后允許再次錄入同樣編號的訂單。因此。對于這樣的情況下在雖然有效的訂單編號只有一個但在數據庫角度會允許編號重復。所以不管如何還是建議大家為表都建一個沒有任何意義的主鍵如ID。
2.4 是否要采用GUID作為主鍵
很多項目是多級建庫的,經常需要數據導入、導出、合并很需要一套產生全局唯一主鍵的機制。一種方法是自己設計一套編碼規范(類似于身份證、信用卡)最好有一個統一編碼服務器;第二種方法也是自己產生主鍵為每一個獨立的數據庫分配一個NameSpace產生主鍵時前面加上這個NameSpace;最后一種方法就是UUID我想重點討論一下后者。
UUID(Universally Unique Identifier)是通用惟一標識符,是128位比特的數字,用來惟一地標識因特網上的某些對象或者實體。UUID是是由開放軟件基金會(OSF)作為分布式計算環境(DCE)的一部分而制定的標準。UUIDs的目的就是使分布式系統可以不需要重要的中央調合系統而能唯一地標識信息。這樣,任何人能創造一個UUID和使用它來標識一些東西,而且,你有足夠的信心來確定這個標識是永遠不會被任何人無意地使用在任何東西上。因此,信息加上了UUID標簽就能合并到單個數據庫中而不用去解決命名沖突的問題。這個標準的廣泛應用在微軟的全球唯一標識符(GUIDs)上,GUID實現了這個標準。
用GUID作主鍵有它的優勢與不足。優勢是GUID具有唯一性,在任何情況下,可以產生全球唯一的值。這是GUID最大的優勢,也方便數據導入,比如要求從另一個系統中把數據導入進來,那么不用擔心導入時,會導致主鍵沖突。不足是GUID值太復雜、不易記憶,因為有時難免我們會用記錄的方式來進行記錄判斷。而且數據太長,影響數據庫效率。GUID的產生不是以一定的次序產生,對于按主鍵物理排序的數據庫來說,如果在記錄的前部插入一條記錄,可能會導致后面N次方的數據條數后移。這將導致數據插入效率。而且這個值是隨機、無順序的。GUID的值有16個字節,與其它那些諸如4字節的整數相比要相對大一些。這意味著如果在數據庫中使用unique identifier鍵,可能會帶來兩方面的消極影響,一是存儲空間增大,二是索引時間較慢。因此GUID的采用應該要慎重。
3 結束語
數據庫主鍵在數據庫中具有重要的地位。主鍵的設計直接影響到數據庫系統的應用和效能。數據庫主鍵的設計并沒有定論,因此,我們在設計主鍵時,因根據具體應用的需要,綜合考慮各方面的因素,考慮數據庫的規模,以及插入、刪除、檢索等操作的頻繁來選擇合適而快捷的數據庫主鍵設計方法,從而達到優化數據庫主鍵的目的。
參考文獻:
[1] 張云濤.商業智能的設計部署與實現[M].北京:電子工業出版社,2004.
2 OFA結構的應用
OFA（最佳靈活體系結構）是Oracle數據庫用于優化邏輯配置和性能提供的一種結構，通過OFA的利用能夠簡化Oracle數據庫物理結構的設計，提高邏輯數據對象的分布效率。因此，首先需要根據數據庫中的邏輯對象的使用方式以及物理結構對數據庫的影響進行分類，這種分類包括將系統數據以及用戶數據分開、一般數據和索引數據分開、低活動表與高活動表分開等。數據庫邏輯設計的結果需要遵循幾點原則：（1）將使用相同方式的字段類型進行統一存儲；（2）按照標準使用對數據庫系統進行設計；（3）存在用于例外的分離區域；（4）表空間沖突的最小化；（3）實現數據字典的分離。
3 SGA的應用
SGA（內存分配）是Oracle數據庫中進行內存管理的關鍵模塊。正確的SGA大小對提高數據庫的性能具有重要作用。SGA主要包括四個部分。
（1）數據塊緩沖區。數據塊緩沖區是SGA中的一塊高速緩存，大約占據了整個數據庫的1%～2%左右，主要用于數據庫中經常需要進行訪問的數據塊，因此，采用最近最少使用的方法對其空間進行管理。通過查詢v$sysstat動態性能表，能夠獲取到數據塊緩沖區的具體使用情況，當命中率低于85%時，則需要為其分配更多的內存。
（2）字典緩沖區。字典緩沖區中的信息主要包括用戶賬號數據、數據文件名、字段名、位置、表說明以及權限，該緩沖區也通過最近最少使用的方法進行空間管理。通過查詢v$librarycache動態性能表，能夠獲取到字典緩沖區的具體使用情況，當命中率低于90%時，則可能需要增加共享池的空間來提高字典的緩存速度。
（3）重做日志緩沖區。重做日志緩沖區保存為數據庫的恢復過程中用于前滾操作。
（4）SQL共享池。SQL共享池保存執行計劃以及運行數據庫的SQL語句的語法分析樹，也采用最近最少使用的方法對其空間進行管理。如果設置過小，就可能導致語句連續不斷地再裝入庫緩存，導致系統性能下降。
4 規范化與反規范
4.1 規范化
范式是符合某個級別的關系模式的集合，根據約束條件的差異，通常分為第一范式、第二范式和第三范式三種范式。規范化理論是以這些范式為中心建立的，規范化的基本思想是將數據依賴中不合理的部分逐步消除，從而使模式中的關系模型在一定程度上實現分離，因此，所謂的規范化從本質上來看就是概念的單一化。數據庫的規范化管理，能夠進一步減少數據冗余情況的發生，減少冗余數據對存儲空間的占用，同時調用邏輯和物理I/O的次數也會減少，提高數據操作的效率。
4.2反規范化
數據庫中數據的規范化并非一定能夠實現數據庫的最優性能，因為對數據庫的查詢通常需要更多的操作鏈接，從而對查詢速度產生影響。因此，在數據庫的設計過程中，有時需要對規范規則進行故意破壞，這樣能夠在特定的情況下改進數據庫的查詢性能，提高數據庫的相應速度。
5 邏輯結構的優化
5.1 基本表的設計
5.1.1以用戶為中心進行表的設計
當數據模型設計不合理時，則所有的SQL調整所發揮的作用都十分有限，規范化的表設計能夠提高數據庫的靈活性并降低整個系統開發和運行的開銷。數據庫的完整性檢查能夠在數據庫中完成，同時也能夠通過應用程序實現。如果將數據庫完整性檢查隱藏在應用程序中，則需要將大量的管理代碼加入到應用程序中，同時還會導致服務器的信息通信量大大增加，這會在較大的程度上影響到整個系統的運行效率。相反，如果按照規范化理論對數據庫的邏輯結構進行設計，則能夠使數據庫的完整性和一致性檢查均在數據庫服務器中實現，但是完全按照第三范式的要求進行數據表的設計會拆分大量的表，系統運行過程中，服務器需要頻繁進行多表連接，影響整個數據庫系統的性能。
因此，在對數據庫表進行設計時，需要實現靈活性與核心事務性能之間的相對平衡，使數據庫在盡量滿足規范化要求的同時能夠對其中的核心事務提供最直接的訪問路徑。比如，某個信息查詢系統中存在銷售表Distribution（Card、Operator）和營業廳表Office（Office、Operator）。在系統運行的過程中，如果有如下語句在檢索條件中以較高的頻率出現Where Distribution.operator=Office.operator，則可以考慮在銷售表中增加一個字段Office。顯然，如果一個operator只屬于一個office，則在新生成的銷售表中非主鍵office依賴另一非主鍵operator，這樣就與規范化理論相違背，但是通過綜合考慮，后者也是可行的。
5.1.2數據類型的合理使用
Oracle數據庫提供了非常豐富的數據類型，通過準確的數據類型以及合理的數據長度對數據類型進行定義，不但能夠有效減少數據冗余，同時還能夠提高系統的檢索效率。目前，常用的一些違背此原則的做法主要包括利用字符串存儲日期數據、利用BLOB型存儲文本等。要想避免這類做法，需要盡可能使用專門的數據類型對相應的數據進行存儲，即日期型存儲日期數據、數值型存儲數值等。另外，在滿足需求的情況下應該盡量減少占用空間。比如，數據能夠采用Int型表示時，就不要使用Float型。在部分數據庫中，如果無法確定數據長度，通常對其進行最大長度定義，這種方式通常會嚴重影響數據庫系統的性能。
5.2 索引的優化設計
5.2.1管理組織索引
索引的建立能夠實現對數據表中的邏輯值的安全映射，使其映射到安全的RowID。因此，通過建立索引的方式可以快速定位數據的物理地址。但是部分DBA發現，建立大型數據表的索引，往往會影響系統的性能，導致這種情況發生主要是由于SGA管理方式所引起的。Oracle數據庫在管理數據塊高速緩存時，索引數據往往能夠獲得更高的內存駐留權限，而在與普通數據競爭內存空間時，數據庫往往會優先將普通數據移出內存空間。針對建立索引的大型數據庫而言，在進行數據查詢的過程中，索引數據可能會使用所有的數據塊緩存空間，導致數據庫頻繁地從磁盤中進行數據的讀取，影響系統性能。對此，在建立一個大型表進行分區之后，可以按照分區建立分區索引，如果大型表的索引數據查詢頻率過高，則可以不建立索引。另外，DBA在建立索引時，需要保證where語句中對建立的索引進行應用。由于索引必須指向適合的訪問路徑，因此在查詢過程中如果簡單的指定一個索引，則并不一定能夠取得優化效果。
5.2.2聚簇
如果兩個或者多個表需要進行查詢連接，則可以考慮建立聚簇。比如，對通話信息表Dial（caller，receiver，time，length）和電話信息表Phone（name，address，number），如果下列檢索語句在檢索條件中經常出現Where receiver=‘123456’AND Dial.caller=Phone.number，則能夠產生聚簇，在產生聚簇之后，兩個表的物理存儲結構會產生一定的變化，通話信息和電話信息的記錄將會混合存儲到一起，每個電話信息記錄后面是該電話所撥打的所有電話記錄。因此，如果能夠確定Dial和Phone之間基于電話號碼存在頻發的連接，則可以采用一種聚簇文件結構提高兩個表之間的連接效率。但是聚簇結構不利于兩個表的單獨查詢，因此，在設計中需要對該邏輯結構謹慎使用。
5.2.3索引被使用的條件
優化設置的索引，必須充分利用才能夠實現數據庫訪問速度的進一步提高。Oracle要使用一個索引，有一些最基本的條件：第一，Where子句中的這個字段，必須與索引的第1個字段相符合；第二，Where子句中的這個字段不應該參與到任何形式的計算中。
6 物理結構的優化
Oracle數據庫物理存儲結構的優化對于提高數據庫的性能非常重要，物理結構的優化就是依靠提高磁盤讀寫的并行度、減少存儲的動態擴展來實現數據庫系統的性能優化。
6.1 磁盤讀寫的并行優化
磁盤I/O是數據庫訪問開銷的重要指標之一，數據庫物理結構的優化雖然無法減少從磁盤中讀寫數據的次數，但是可以通過并行化的方式，減少對此磁盤讀寫的競爭，從而提高系統的性能。提高磁盤讀寫并行化需要遵循兩點基本原則：（1）將系統的SYSTEM、TEMP、ROLLBACK、REDO LOG表空間盡量放在不同物理磁盤中，能夠有效減少系統進程與用戶進程對I/O的競爭；（2）為表以及索引分別創建不同的表空間，并分別部署到不同的磁盤上，對于實現表和索引的并行訪問十分有利。
6.2 減少存儲的動態擴展
當數據庫建立的時候如果沒有分配足夠的存儲空間以及合理的增幅長度，則存儲結構在運行階段會形成動態擴展。在動態擴展過程中，需要通過SQL語句存取數據字典，以實現對空閑空間的利用，這個過程需要消耗較長的時間，還可能導致數據文件和表空間增加。這可能導致本來處于正常運行狀態的系統的性能出現突然之間的大幅度下降。因此，在系統設計階段，需要綜合計算存儲空間大小、增幅長度和最大值，并在此基礎上對INITIAL、NEXT以及MINEXTENTS的值進行定義，實現數據庫物理存儲和動態增長次數的平衡。
7 結束語
Oracle數據庫的庫結構直接決定了數據庫系統的性能，優良的庫結構對于提高系統的性能具有重要作用，因此對整個庫結構的優化也是數據庫性能優化的基礎，低劣的結構則可能導致整個優化無法發揮作用。良好的數據庫系統不是靠調試產生的，而是需要優秀的設計，在Oracle數據庫設計階段就對整個系統的任務和需求進行充分的計算，不僅能夠為應用程序的開發提供便利，同時還能使運行維護工作大大簡化。
一、前言
數據庫是承載數據的載體，存放和提供數據的“庫房”，為我們進行數據查詢、修改、管理等操作提供便利。建立數據庫可以幫我們提升工作效率，通常適合較為龐大的系統數據存儲。
例如，國網新疆電力目前覆蓋全疆14個地州（市），涉及用戶達2000多萬人口，管理40多個部門和下屬單位。這么復雜的機構需要高效穩定的IT系統支撐國網新疆電力公司。國網新疆電力目前有多個IT系統，比較重要的系統有綜合管理數據庫、營銷系統數據庫、ODS系統、財務系統。這么多系統數據日增長量超過2TB，這需要有效的優化手段解決數據庫的性能問題。
目前通用的方式為采用Oracle數據庫來對這些數據進行存儲管理，面對廠里人員的變動則需要進行數據更新，隨著系統長期運行、用戶數和數據量不斷增大以及業務不斷變化，系統運行期間就會涉及到數據庫優化。本文就從Oracle數據庫優化進行簡單的討論，針對在優化過程中的一些注意事項、優化事項進行分析，為我們在工作中能夠熟練的掌握優化技術。
二、Oracle數據庫介紹
Oracle數據庫，英文全名為Oracle Data-base，又被稱為Oracle RDBMS或者直接簡稱為Oracle。目前最流行的B/S和C/S架構的系統中均應用到了數據庫，由于它們的架構設計中都具有自己的服務器，而數據存在這些服務器中，則需要數據庫對其進行儲存。目前對于數據庫的使用越來越廣泛，隨著人們對于數據庫的研究越來越深入，逐漸出現了數據庫云，將計算機的云計算應用到了數據庫之中，這樣使得多個數據庫聯合組成了更加龐大的數據庫網，它們之間實現了數據共享，因此對于知識、信息的涵蓋將會變得更廣。云計算的實現，帶給計算機網絡發展巨大的空間，使得將世界的計算機聯合起來形成一層一層的網絡，與此同時也將數據庫采用云管理，為數據庫的發展提供更加廣闊的空間[1]。
三、數據庫優化方案介紹
多數研究者在面對Oracle數據庫優化課題時，都會存在這樣的思想誤區，即認為只有在系統出現運行問題時才需要進行系統性能調整。而事實上，對Oracle數據庫的性能進行調整和優化是一個漫長而復雜的過程，是貫穿于整個系統運行周期的。因此，在進行系統性能優化時，應按照以下流程來進行：對系統各功能組件和硬件設備進行正確的配置對數據庫結構進行調整對SQL語句進行優化調整參數進行磁盤I/O與服務器網絡性能的調整。以上流程是一個密切聯系的整體，只有保證嚴格按照這一流程進行Oracle數據庫系統性能調整，才能確保系統的性能達到最佳狀態，真正實現Oracle數據庫的優化設計。
圖1所示是進行數據庫優化時需要考慮的內容。優化是數據庫體系的延續，數據庫的結構和運行的機制決定了數據庫的優化模式，所以說數據庫的體系結構是優化的基石。如果對數據庫的體系結構有深刻的理解，優化便水到渠成。反過來，通過優化數據庫，可以更深入的了解數據庫體系結構。數據庫各個方面都有優化的余地，主要的優化方向分為實例的優化、數據庫的優化、SQL語句的優化。其中SQL優化是重中之重。
對Oracle數據庫進行優化，應該遵循優化SQL查詢語句――索引優化――合理分布數據庫物理文件――分析及優化Oracle內存分配原則。具體如下：
（一）SQL查詢優化
SQL查詢，主要針對數據庫的信息進行搜索，尋找自己的需求信息。數據庫內的一切操作都是經由SQL語句進行執行，因此SQL語句的執行效率很大程度上決定了Oracle數據庫的性能。進行SQL語句的優化，首先應該構建原始數據庫BASICPROJECT，其中包含了與生產數據庫基本一致的數據庫對象;其次，應該充分的利用SQL Trace、awrsqrpt、sqlplus中的autotrace、explain等跟蹤技術對語句進行優化重寫 [4]。我們在建立SQL語句的時候要盡量的避免出現相關子查詢，以及選擇語句的使用，這樣就能從數據建立的時候減輕查詢的負擔。針對聯合查詢連接遇到5張或者5張表單以上的選擇時，建議采用優化器對SQL語句中所包含的表單進行物理大小排序，建立起一定的查詢順序，來提升查詢的效率。
（二）索引優化分析
索引技術是提升檢索速度和系統性能的主要技術，對于數據查詢來說，合理使用索引可以極大的提高查詢的命中率和效率。索引是將表中數據的邏輯值映射到rowid中，所以在查詢時使用索引功能能夠快速的定位出查詢數據的物理地址，從而找出數據。
索引對數據庫的性能影響是巨大的，但索引不是萬能的，數據庫對索引的使用是有選擇的，我們可以強制使用索引，也可以強制不使用索引。一般的情況下數據庫會自動的判斷是否使用索引，除非你明確的在SQL語句中指定。
所有索引的原形都是樹狀結構，由根、枝干和葉子組成。根和枝干中存放鍵值范圍的導引指針，葉子中存放的是條目，條目中存放的是索引的鍵值和該數據行ROWID。索引的葉子間通過指針橫向的聯系在一起，前一個葉子指向下一片葉子，這樣的目的是數據庫在找到一個葉子后就可以查找相臨近的葉子，而不必再次去查找根和枝干的數據塊。
有的DBA發現了索引并不能提高查詢速度，反而對整個數據庫的性能有較大的不良影響，出現該問題主要是和SGA數據管理方式有關。當Oracle進行數據高速緩存管理時，普通數據的駐留權限要比索引數據的權限要低，當兩者在空間上競爭時，索引數據往往會駐留;如果是大型表建立索引時，索引數據占了大部分的緩存空間，使Oracle只能通過磁盤讀寫來獲得數據，所以在大型表分區后，伴隨索引也得進行相應分區，索引的使用應該有一個指定的合適路徑[5]。
（三）分布表空間
在整個數據庫工作過程中，各相關進程會將數據庫中的事務分別寫到聯機日志文件、歸檔日志文件和數據文件當中，這會不可避免的造成這三類文件之間的I/O沖突;并且歸檔日志文件因其特殊性，無法同系統、業務和索引這些表空間共存，這就需要一個獨立的磁盤來完成合理分布表空間的功能，對各項數據進行合理的分配，以避免文件之間的I/O沖突。
（四）數據緩沖區的調整分析
數據庫的緩沖區是SGA不可缺少的組成部分，它的作用是對磁盤的讀入數據進行存儲，存儲的數據為用戶共享。如果需要修改數據時，首先要從數據文件中將數據讀取出來存儲在數據緩沖區;如果用戶對數據緩沖區的設置太小，那么數據的操作性能將會受到很大的影響。用戶越多，該問題越突出，該問題的出現使得很多人去關心如何判斷數據緩沖區大小，如何確定緩沖區的效率，該類問題可以通過計算命中率來進行確認。
數據緩沖區V$sysstat中的consistent_gets、db_block_gets是consistent mode和current mode模式下的數據讀取總量，physical reads是整個磁盤物理數據讀取總量，這兩個數據的讀取總量的比值就是所謂的命中率，如果兩個數據比值<90%，那么就需要對該緩沖區大小進行調整[2]。
（五）共享池調整分析
共享池同樣也是SGA的重要組成部分，它主要包含了數據字典高速緩存與庫高速緩存，這兩者的作用是對整個SQL程序進行語法分析、編譯以及執行。
庫高速緩存中會將解析過的SQL語句、PL/SQL（存儲過程、函數、包）進行緩存。如果為了工作的需要，將解析過的SQL信息重用會提高整個數據庫的性能，可以將解析過的SQL信息存儲在共享池中，這就需要共享池的設置要足夠的大。通過對V$librarycache查詢實例來觀察整個庫高速度緩存的活動情況，其中的reloads和pins，它們分別是庫高速緩存執行階段的未命中數目和庫高速緩存中被執行的次數，如果庫緩沖區的失敗率超過的1%，那么就需要對其進行調整。除此之外，還有些情況也需要共享池的設置要大，字典數據高速緩存的總丟失數和總的存取數的比值應該接近零，當這個數值超過10%，那么就需要對其進行調整。如將表定義的詳細信息長期的存儲在共享池中，將其進行重用，提高數據庫的整體性能[3]。
通過V$rowcache來對數據字典高速緩存活動進行詳細查詢，其中的get misses和gets分別代表的是字典數據讀取的失敗和成功次數，通常要求的比值小于10%，若超過則需要進行及時的調整。
（六）日志緩沖區優化方案
日志緩沖區主要是保存了對數據庫修改信息，設置的大小一般為2兆以內的內存，最小為500K。日志緩沖區也不能過小，否則會增加日志的寫盤次數，從而為I/O接口增加負擔。日志緩沖區中的常見指令為：immediate gets表示成功立即得到日志緩沖區次數;immediate misses 則表示未成功立即獲取日志緩沖區次數。V$latch中的gets和misses表示成功獲得緩沖日志次數以及未成功獲得日志緩沖區次數，其失敗率要小于1%，如果超出則需要對數據庫進行調整。
（七）合理的使用工具
有時候想直接在SQLPLUS中看ASH/ADDM/AWR報告，用下面方法比較方便，因為AWR數據在數據庫中默認只保留7天，當我們進行性能對比分析需要保留時段之前的AWR時，可以采用腳本定時將AWR報告輸出保存。
ASH （Active Session History）
ASH以V$SESSION為基礎，每秒采樣一次，記錄活動會話等待的事件。不活動的會話不會采樣，采樣工作由新引入的后臺進程MMNL來完成。
生成ASH報告：
SQLPLUS>@？/rdbms/ashrpt.sql
ASH內存記錄數據始終是有限的，為了保存歷史數據，引入了自動負載信息庫（Autom-atic Workload Repository ，AWR） 由后臺進程MMON完成。ASH信息同樣被采集寫出到AWR負載庫中。由于內存不是足夠的，所以MMNL進程在ASH寫滿后會將信息寫出到AWR負載庫中。ASH全部寫出是不可接受的，所以一般只寫入收集的10%的數據量，而且使用direct-path insert完成，盡量減少日志的生成，從而最小化數據庫性能影響。
寫出到AWR負載庫的ASH信息記錄在AWR的基礎表wrh$active_session_hist中，wrh$active_session_hist是一個分區表，Oracle會自動進行數據清理。
AWR（Automatic Workload Repository）自動工作負載信息庫
AWR是Oracle 10g中的一個新特性，類似于10g以前的statspack。不過在使用上要比statspack簡單，提供的性能指標要比statspack多很多，能更好的幫助DBA來發現數據庫的性能瓶頸。
AWR 是Oracle安裝好后自動啟動的，不需要特別的設置。收集的統計信息存儲在SYSAUX表空間SYS模式下，以WRM$_*和WRH$_*的格式命名， 默認會保留最近7天收集的統計信息。每個小時將收集到的信息寫到數據庫中，這一系列操作是由一個叫MMON的進程來完成的。
AWR存儲的數據分類：
WRM$表存儲AWR的元數據（awrinfo.sql腳本）
WRH$表存儲采樣快照的歷史數據（awrrpt.sql腳本）
WRI$表存儲同數據庫建議功能相關的數據（ADDM相關數據）
生成AWR報告：
SQL>@？/rdbms/admin/awrrpt
根據向導來完成AWR報告的生成。需要注意的是，在選擇時間范圍的時候，中間不能有停機（如果顯示的中間有空白行，表示有停機情況）。在選擇報告類型的時候一般使用默認的HTML，方便查看。
查看數據庫的AWR的設置：
SQL> select snap_interval， retention from dba_hist_wr_control;
SNAP_INTERVAL
RETENTION
--------------------------------- ----------------------------------
+00000 01：00：00.0（每小時收集一次） +00007 00：00：00.0（保留7天）
修改默認設置：
begin
DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS（interval => 20，
retention => 2*24*60）;
end;
修改成每20分鐘收集一次統計量，保留最近的2天統計量信息。
手動收集一次數據庫的統計信息：
exec DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT;
我們還可以通過DBMS_WORKLOAD_REPOSITORY包完成對基線、默認設置的修改等操作。
ADDM （Automatic Database Diagnostic Monitor AWR）
是Oracle內部的一個顧問系統，能夠自動的完成最數據庫的一些優化的建議，給出SQL 的優化、索引的創建、統計量的收集等建議。
ADDM報告生成：
SQLPLUS>@？/rdbms/addmrpt.sql
Oracle 性能調整最重要的就是對最影響性能的SQL的調整。在一個應用中，能夠影響到數據庫的只有SQL，也只能是SQL。我們不能一味依靠增強硬件，修改系統、數據庫參數來提高數據庫的性能，更多的應該關注那些最影響性能的SQL語句。ASH報告、AWR報告、ADDM報告都是能夠找出最影響性能的SQL語句的工具。 在分析ASH報告、AWR報告的時候，最重要的就是關注SQL Statistics，SQL Statistics中最應該關注的是SQL ordered by Gets和SQL ordered by Reads兩個指標。大量的Gets（邏輯讀）會占用大量的CPU時間，大量的Reads（物理讀）會引起IO的瓶頸出現。一般情況下，大量的Gets會伴隨著大量的Reads出現。當然，我們可以通過增大SGA的大小來減少Reads的量。通過這兩個指標找到了最影響性能的SQL，這是首要的，也是必要的。下一步就可以通過創建索引，調整SQL來提高SQL單獨執行的性能，減少SQL執行時出現的高Gets，Reads。當然整體的性能影響還和excutions有關，如果這條SQL執行的次數過多，累加起來的量很大，那么就可以考慮通過在應用上緩存等手段來減少SQL執行的次數。另外還有一個需要注意的問題就是在開發過程中SQL一定要使用綁定變量，來減少硬解析（大量的硬解析也會消耗大量的CPU時間，占用大量的Latch）。在開發過程中有個原則就是：小事務操作完成及時提交。
我們使用這么多種方式、報告只有一個目的：找出最影響系統性能的SQL語句。找到SQL下一步就是對它進行調整了。
我們在監控數據庫時，如果是當前正在發生的問題，我們可以通過v$session+v$sqlarea來找出性能最差的SQL語句。如果在一個小時以內發生的我們可以通過生成ASH報告來找出SQL。如果是1小時以上或幾天我們可以通過AWR報告來找出幾小時，幾天以來最影響系統的SQL語句。ADDM報告基于AWR庫，默認可以保存30天的ADDM報告。
我們也可以直接查詢試圖：
v$session （當前正在發生）
v$session_wait （當前正在發生）
v$session_wait_history
（會話最近的10次等待事件）
v$active_session_history
（內存中的ASH采集信息，理論為1小時）
wrh$_active_session_history （寫入AWR庫中的ASH信息，理論為1小時以上）
dba_hist_active_sess_history （根據wrh$_active_session_history生成的視圖）
四、總結語
企業中使用Orcale數據庫來儲存數據，有效的改善了以前對于企業信息數據處理的問題。有效的節約了信息處理資源，且采用Orcale數據庫將所有的員工等信息進行備份，方便以后查詢，若數據庫的數據不丟失，那么則能夠通過查詢進行查詢。本文主要針對Oracle數據庫進行介紹，然后根據數據庫中的內容進行優化，為以后企業在數據庫的優化上提供借鑒。
參考文獻
[1]溫創新.電視廣告商務平臺中Oracle數據庫的ADICI設計與優化研究[D].中南大學，2011.
[2]王斌.基于Oracle數據庫技術的航行情報系統（CNMS）性能優化[D].電子科技大學，2010.
[3]張舒.超大型Oracle數據庫的基礎設計和優化設計[J].價值工程，2011，10：178.
2元數據的定義和形成
元數據又叫做描述數據，是臺灣學者通過英文翻譯過來的（英文為Metadata），現在我國對該術語還沒有形成統一的認識。國際標準化組織地理信息、地球空間信息技術委員會的地理信息元數據標準草案將元數據簡單的定義為“數據的數據”。美國聯邦地理數據委員會在數字地理空間元數據內容標準中將元數據定義為“關于數據的內容、質量、條件和其他性質的數據”。國際地球科學信息網絡學會對元數據定義為“關于數據和信息資源的描述信息，他們描述、指向或者補充與之相關的信息內容”。元數據的定義和專業術語出現的時間雖然不長，但是元數據的本質內涵確實流傳了很久。舉一個簡單的例子，在很早以前的圖書管理當中，管理人員對書籍目錄的編寫，記載了書籍的各種相信內容，包括作者、寫作時間、頁數和字數等，這種對書籍信息的記錄就可以理解為元數據。只不過在以前涉及到的數據不是特別復雜，只是到了現代隨著網絡技術的普及，數字資源呈現出爆炸性增長的速度，人們為了便于統計這些數字信息不得不將以前的文本化數據向網絡表格化數據方面進行轉變。從上世紀八十年代開始出現元數據的記錄方式，到現在元數據的應用已經擴展到了各個行業。
3元數據標準內容分析
根據元數據的使用目的不同可以將元數據大體分為兩類，即：管理和組織數據的元數據；瀏覽和導航數據的元數據。第一種類型的元數據的代表就是美國nasa描述遙感數據的目錄交換格式標準（DIF），這一標準有一個典型的特征就是必備六個字段：登錄目錄標識、登錄目錄的名稱、參數、原數據中心（包含名字、數據集標識、聯系人等）和數據概要描述。另外，為了讓信息表達的更加明確，這一標準當中還要增加字段，如傳感器的名字、位置、數據分析、計劃口令、品質等，增加這些字段可以提高用戶的使用效率，盡可能的完善元數據。第二種元數據的代表就是澳大利亞新西蘭土地信息委員會制定的元數據標準。這一標準確立的核心元素較少，能夠讓用戶在最短的時間內查詢到所需要的數據信息。核心元素能夠說明現有數據的種類、數據信息、數據范圍、與其他應用的作用，以及獲取更多信息的位置等。核心元數據共分為九類三十二個元素：數據集中、展示、數據時間、數據狀況、訪問和瀏覽情況、數據品質、聯系信息、元數據時間、元數據附加內容。除此之外，核心元數據還要制定了數據格式，使用指南，以方便用戶查找信息。
4元數據表達方式的分析
美國聯邦地理數據委員會的數字化地理空間元數據內容標準元數據信息單元是元素、實體（包括復合實體）和字集。元素是元數據的基本信息單位，元數據實體由元數據元素組成，元數據實體、元素則構成復合實體，最終部分元素、簡單或者復合元數據實體組成元數據子集，元數據的組成結構從小到大排列為，元素、實體（復合實體）、子集。元數據是利用巴克斯諾爾范式進行表達的，巴克諾斯爾范式可以定義常規語言元素和屬性標準語法，在確定復合實體和其他元素、實體間的聯系的時候，采用類似于數學等式的關系將標識符和表達式用等號連接起來，以此來表表達式產生標識符這一進化關系。這一規則公式代表了各種符合的意義，從數學角度可以解釋為，A=B+(C)表示A由B和可選項C構成，A=3{B}5表示A由B重復3到5次而成，子集、實體、元素之間的關系可以用元素比實體進一格的辦法來表達，美國的數字化地理空間元數據內容標準利用這種方式可以清晰的表達數據實體和元素之間的各種關系，但是它也只是包含了標準化當中元數據和元素的定義，并沒有規定數據的格式，有時候用元數據元素分層縮排來表示，有時候用編號系統表示，這就使得元數據使用起來并不簡潔。為了解決這一問題，建立了空間數據信息交換網絡，利用比較統一的SGML、Z39.50和其他協議來表示，可以更加靈活的執行元數據。ISO/TC211的元數據標準利用了圖表和數據字典相融合的表達方式，清晰的表示了元數據內容之間的各種關系。數據字典可以詳細的解釋元數據的內涵，圖表則是面向對象的統一建模語言UML靜態結構圖、ISO借口定義語言，在圖表當中信息單位是包、類和屬性。數據字典當中元數據的信息單元是子集、實體以及元素，這一標準說明了圖表和字典當中的對應關系。因為靜態結構圖準確的解釋了元數據的語義和句法結構規則，制定了標準的描述數據信息的方法和格式，通過輔助設計軟件可以精確的表達數據元素關系，檢查元數據設計的整體性和統一性，所以ISO/TC211的元數據表達方式對全世界各個行業的數據管理和服務產生了重要的影響。
5元數據網絡管理模型分析
當下比較流行的元數據管理系統模式可以分為：集中式數據管理體系和分散式數據管理體系。集中式數據管理體系就是所有的元數據都聚集在一個元數據管理站點上，數據集元數據是通過數據制造者免費上傳的，數據的使用者可以通過當下的數據管理站來進行訪問好查詢元數據。這一模式比較有代表性的就是英國地理數描述目錄，這一機構的數據來源于國家制圖機構。這種模式的優點就是使用者可以迅速的查找元數據，工作效率很高，當然缺點也很明顯，就是這一模式分裂了這一管理系統和其他網絡元數據體系的鏈接，導致這一體系的元數據數目較少，在數據信息的更新和維護方面就取決于元數據的上傳者，元數據信息不能及時的更新，提供的數據有可能出現錯誤。分布式元數據管理體系就是要設立一個元數據網絡交換的核心連接點，使用者可以在這一連接點進行元數據的查詢，而對于元數據的供給者和元數據的數據制造者，則需要設立分節點，保存各種元數據的信息，然后將核心連接點和分節點聯系起來。元數據的使用者不能直接訪問數據的制造者，只能通過核心連接點來訪問數據信息，進行元數據的查詢。這一模式的代表性機構就是美國空間數據交換網絡，它將用戶、服務器內容、數據庫服務器進行了分離。通過網關根據數據信息的類型、數據信息覆蓋位置等條件構成元數據的查詢界面，用戶通過網絡進行查詢，核心連接點通過用戶信息向分節點進行傳輸，然后在將內容反饋到用戶瀏覽的頁面當中。這種模式的優點在于能夠增加元數據的數量，減少核心連接點對元數據的更新負擔，缺點在于元數據的查詢速度較慢，影響使用者的查詢效率。
6元數據傳輸各式的統一
雖然當前已經制定了一些元數據的標準，但也只是確定了元數據的內容、含義、類別、組成結構等特征，但是這還不能滿足元數據的使用要求，制訂元數據標準的目的是為了元數據的查找和檢索，了解數據信息和內容，因此必須要注重元數據的傳輸標準，以此為基礎來設計元數據的管理體系，從而達到對元數據的搜尋、修改、更新維護和查詢檢索。在DOS環境下和ARC/INFO環境下，美國誕生了很多元數據錄入和編輯的軟件，澳大利亞也開發類似的軟件，這些元數據軟件都是為了便于自身的查詢需求，符合各自制定的元數據標準的。但是各個元數據錄入軟件的數據格式卻不相同，有的是文本格式，有的是HTML格式，還有的是關系型數據庫格式，雖然方便了用戶，但是在元數據的修改和維護方面成本很高，所以要制定統一的元數據轉化標準，方便網絡上的元數據交換。美國和澳大利亞建議更改統一的后綴格式，例如，將SGML/HTML的統一轉換成XMLDTD或者是XMLSchema，將表格改編成ASCII的格式。這種方式優點在于有利于建設元數據索引和能夠在不同地區的互聯網當中進行元數據的查詢。
7元數據管理平臺設計和實現
7.1功能流程設計
功能流程設計需要滿足元數據生命周期的要求，當前大多數公司單位都是分散式的數據管理體系，數據比較分散，需要采集多元數據并且簡化數據的存儲體系?？梢詫SV（三層階梯式圖）引用到元數據管理體系當中，在元數據導入配置方面，可以利用懸掛點配置的方式，在任務采集的起始階段可以配置相應的懸掛點（類似分支點），建設元數據的查詢樹，在數據源配置方面要表明數據源的類型、銜接數據、賬戶情況等，還要進行測試觀察后續問題。為了更好的完善元數據的管理體系，保持元數據地圖的完整性，需要對元數據進行完備的采集，采集方式又分為手動采集和自動采集。手動采集是對用戶要求的數據庫進行單次采集，自動采集則額外的配置采集時間和采集周期。
7.2元數據的瀏覽
將配置好的懸掛點體現在元數據的樹狀結構當中，以形象的結果提供給用戶，基于TSV的思想元數據樹需要具有三層以上的結構，首先是系統，其次是各系統數據庫，再者是各數據庫的下屬表。在庫級元數據方面需要展示各個表名和創立的時間，在表級元數據方面需要雙擊查看該表的詳細信息，包括字段、約束、索引、鍵、視圖等，在下拉菜單當中可以檢索相應的元數據信息。在字段級元數據方面包括字段名、字段類型、字段解釋、所屬的表和庫，前三項屬于特點描述，后兩項是定義描述，這樣能夠方便對字段進行分析和定位。
7.3元數據的構架設計
中圖分類號：TP311.13 文獻標識碼：A 文章編號：1007-9416（2012）09-0186-02
在現在通信行業業務支撐系統建設中，由于數據庫數據量的巨大，通常會根據不同業務模塊建設成分布式數據庫。如將計費帳務系統中數據可以按清單查詢提供、前臺帳務營收、計費處理、報表統計等劃分，分布到不同的數據庫實例，這樣，通過模塊化的數據分流，減輕了單一數據庫的資源壓力，均衡了負載，提高了各應用模塊程序的效能。
同時，各數據庫實例作為一個整體，存在一定的耦合性，分布的數據庫之間的存在不同程度的相互溝通。如統計數據需要采集清單數據、營收帳務數據，計費處理時需要訪問客戶資料數據等。這些操作如果通過數據庫之間進行操作就涉及到跨庫操作的問題。
作為一個整體系統中的分布式數據庫之間存在跨庫操作是非常普遍的，尤其是數據庫鏈接、同義詞和存儲過程的跨庫操作在應用程序中廣泛使用，這些給應用程序的設計實現帶來了極大的方便，同時，從安全的角度也帶來了一些問題。下面從安全管理的角度針對跨庫操作進行一些討論。
1、數據庫鏈接（DATABASE LINK）
數據庫鏈接是在分布式環境下，為了訪問遠程數據庫而創建的數據通信鏈路。通過數據庫鏈接隱藏了對遠程數據庫訪問的復雜性。數據庫之間通過數據庫鏈接的創建，使得登陸到本地數據庫上的用戶可以訪問遠程數據庫上的數據或進行其他跨庫操作。可以說，跨庫操作實現的基礎就是數據庫鏈接的使用。
創建數據庫鏈接的語句如下：
CREATE DATABASE LINK 鏈接名 CONNECT TO 賬戶 IDENTIFIED BY 口令 USING 服務名；
數據庫鏈接建立測試成功后，就可以采用以下形式來訪問遠程用戶的表：
表名@數據庫鏈接名
例如：在局域網上創建和使用數據庫鏈接。
首先：在本地數據庫網絡服務名配置文件（tnsnames.ora）中添加遠端數據庫的服務名，假定服務名為remotedb。
然后：登錄本地數據庫，執行創建數據庫鏈接命令：
CREATE DATABASE LINK link_rmt1 CONNECT TO scott IDENTIFIED BY tiger USING 'remotedb'；
測試是否可以使用：
SELECT sysdate FROM dual@link_rmt1；
如果正常返回遠端數據庫的系統時間，則數據庫鏈接正常建立。
這里有兩個問題需要注意，一是遠端數據庫scott帳戶的權限，二是public參數。
建立數據庫鏈接用到的遠端數據庫帳戶的權限對跨庫操作有很大的影響，從一定意義上說，跨庫操作的安全級別就是由這個帳戶所決定的。本地用戶在本地數據庫可以進行的操作，只要這個數據庫鏈接用戶擁有這些權限，本地用戶同樣可以用于遠端數據庫進行操作（通過數據庫鏈接是不可以進行DDL操作的，如create、drop、truncate等）。本例中，如本地用戶擁有resources權限，在本地數據庫可以對自己的對象進行DML（update、delete、insert）操作。在數據庫鏈接用戶scott具有update any tables權限的情況下，本地用戶是可以對遠端數據庫進行update any tables操作的，如
UPDATE scott2.test_table@link_rmt1 SET state=’YES’；
即在本地數據庫只能對自己所屬對象進行DML操作的權限限制，在遠端數據庫則沒有這個限制了。
其次，在對public參數使用上，也是要比較注意的。Public參數在數據庫中處于較低的級別，幾乎不可能對登陸數據庫用戶進行限制訪問。建立了public數據庫鏈接，就等于承認在數據庫鏈接的權限范圍內，遠端數據庫對本地數據庫所有用戶都是開放的。
再者，在測試庫等管理相對開放的數據庫用權限較大的帳戶建立了數據庫鏈接，必將成為遠端數據庫管理的安全漏洞。
所以，在進行數據庫設計時，應該嚴格控止public參數的數據庫鏈接的建立；其次，建立的數據庫鏈接盡量避免使用具有DML權限的用戶；然后，對數據庫中的密碼定期進行修改也可起到一定修補安全漏洞的效果。
2、同義詞（SYNONYM）
同義詞是數據庫方案對象的一個別名，經常用于簡化對象訪問和提高對象訪問的安全性。在Oracle數據庫中的大部分數據庫對象，如表、視圖、同義詞、序列、存儲過程、函數、JAVA類、包等，都可以根據實際情況為他們定義同義詞。同義詞可以分兩類，分別是公用同義詞與私有同義詞。公用同義詞由一個特殊的用戶組Public所擁有，數據庫中所有的用戶都可以使用公用同義詞。私有同義詞是由創建他的用戶或者方案所有。
使用同義詞有以下優點，可以實現在不同的數據庫用戶之間的無縫交互，不同用戶在訪問時都使用同一個名稱；可以創建指向遠端數據庫的對象，簡化了遠程數據庫的對象的訪問；可以為不存在的對象創建同義詞，為應用開發提供了方便。
創建同義詞語句：
CREATE OR REPLACE SYNONYM 同義詞名 FOR 對象名；
跨庫操作使用遠程的數據庫上的表的同義詞，如下語句：
CREATE SYNONYM customer_t FOR erp.customer_t@remotedb；
在使用同義詞時，Oracle數據庫將它翻譯成對應方案對象的名字。用戶使用同義詞訪問對象可以分兩部分，使用同義詞和訪問對象。例如，PUBLIC同義詞是數據庫中所有用戶都可以使用的，但是要想實際訪問到數據，還必須有訪問原本對象的權限。如果沒有同義詞指向的表的操作權限，就會遇到報錯信息“ora-00942： table or view does not exist”。
在跨庫同義詞的管理上，首先，要注意使用公用同義詞，避免同義詞和其他對象名稱的重疊，如本地庫中的表和指向遠程數據庫的表的同義詞名稱一樣，可能就會在操作時造成一定混淆；其次，要注意同義詞操作權限的賦予，盡量避免DML操作，當然，跨庫同義詞的操作權限是同數據庫鏈接的權限相關的。
3、存儲過程（PROCEDURES）
數據庫中過程是一個PL/SQL塊描述，它存儲在數據字典中并可被應用調用。
存儲過程在分布式數據庫環境下，可以分兩部分理解，
一個是跨庫調用存儲過程，二是在存儲過程中使用了數據庫鏈接或者跨庫同義詞。
跨庫調用存儲過程在實際應用中很少用到。當然，用不到更好。因為跨庫存儲過程的調用有很多限制，會發生意想不到的錯誤事件，如DDL操作在跨庫操作時是不允許的；同時，由于執行跨庫存儲過程調用對本地用戶和數據庫鏈接用戶的權限要求都比較高，也不利于數據庫權限的管理。
在本地存儲過程中使用到數據庫鏈接或者跨庫同義詞在分布式數據庫環境的應用中是經常用到的。好處是它可以增加數據庫之間的耦合性，減少了設計難度，尤其是跨庫同義詞的使用，對程序的編寫也提供了方便。缺點是，為了使用的方便而忽略了安全的考慮，如 public數據庫鏈接、public同義詞的使用，遠端數據庫DML權限的賦予等。因為這些設計是應用的基礎，后期發現安全問題再去修復將花費相當的時間和代價。
4、結語
跨庫操作方便了大型應用系統分布式數據庫之間的互訪性，同時，也帶了安全隱患，只有從數據庫管理的基礎層面考慮，將設計基于安全層面之上，才能使應用得到充分的施展，也能將數據得到有效的保障。
參考文獻
近年來，隨著Web技術的蓬勃發展，人們已不滿足于只在瀏覽器上獲取靜態的信息，想要通過它發表意見、查詢數據。隨著電子商務的普及人們開始參與一些網絡商務活動，這就迫切需要實現Web與數據庫的互連[1]。產品異地并行設計對數據的要求有一定的特殊性，主要有（1）產品數據多種多樣。產品設計，特別是機械產品設計常常是大型而又復雜，在異地通過不同的設計小組，按不同的分工設計同一產品，所要管理和通訊的數據類型隨著分工的不同而有不同的表現形式，如常規的數字組成的數據集，以圖形、圖象形式表達的產品模型數據，以文字形式描述設計的文檔，還有圖表、公式等形式，復雜多樣。（2）產品數據交換頻繁，流量大。產品設計是一個協同工作的創造性集體智慧凝聚的過程，要使設計順利進行，分布在異地的不同設計小組之間就要經常性地進行數據交換，并且有些形式表達的產品數據是較大的文件。（3）產品數據的一致性要求高。分工合作的不同設計小組之間的設計任務是彼此關聯，互相依賴的。如果其中一個數據改變了，相關聯的數據必須跟著改變，在Web數據庫設計時必須考慮數據的一致性問題。（4）產品數據的并發性訪問頻繁。由于異地產品設計的特殊屬性，數據的并發性訪問非常頻繁。所以，進行基于Internet的產品異地并行設計的Web數據庫設計與一般的電子商務不同，要充分考慮以上屬性。本文結合我們近期開發的機械產品異地并行設計系統（RCDS， Remote Concurrent Design System），綜合比較了多種當今流行的網絡數據存取技術，設計出可靠安全的數據庫系統。
1.1數據庫連接方案選擇
RDO、DAO和ADO是比較常見的Web數據庫訪問技術。
DAO (Data Access Objects) 數據訪問對象是第一個面向對象的接口，它含有 Microsoft Jet 數據庫引擎（由 Microsoft Access 所使用），并允許 Visual Basic 開發者通過 ODBC 象連接到其他數據庫一樣，直接訪問到 Access 表。DAO 最適用于單系統應用程序或小范圍本地分布使用，對大范圍的異地并行設計顯得功能不夠強大。
RDO (Remote Data Objects) 遠程數據對象是一個到 ODBC 的、面向對象的數據訪問接口，它同易于使用的 DAO style組合在一起，提供了一個接口，形式上展示出所有 ODBC 的底層功能和靈活性。RDO 在訪問 Jet 或 ISAM 數據庫方面有一定的限制，而且它只能通過現存的 ODBC 驅動程序來訪問關系數據庫。但是，RDO 已被證明是許多 SQL Server、Oracle
以及其他大型關系數據庫開發者經常選用的最佳接口。RDO 提供了用來訪問存儲過程和復雜結果集的更多和更復雜的對象、屬性，以及方法。對異地并行設計Web數據庫來說也不是十分理想。
ADO（ActiveX Data Objects）為ActiveX組件中數據庫訪問組件，ASP就是通過它實現對數據庫的訪問。ADO 是 DAO、RDO 的后繼產物。ADO 2.0在功能上與 RDO 更相似，而且一般來說，在這兩種模型之間有一種相似的映射關系。ADO “擴展”了 DAO 和 RDO 所使用的對象模型，這意味著它包含較少的對象、更多的屬性、方法（和參數），以及事件。例如，ADO 沒有與 rdoEngine 和 rdoEnvironment 對象相等同的對象，可以包含 ODBC 驅動程序管理器和 hEnv 接口。盡管事實上接口可能是通過 ODBC OLE DB 服務提供程序實現的，但目前也不能從 ADO 中創建 ODBC 數據源。ADO 是為 Microsoft最新和最強大的數據訪問范例 OLE DB 而設計的，是一個便于使用的應用程序層接口。OLE DB 為任何數據源提供了高性能的訪問，這些數據源包括關系和非關系數據庫、電子郵件和文件系統、文本和圖形、自定義業務對象等等。ADO 在關鍵的 Internet 方案中使用最少的網絡流量，并且在前端和數據源之間使用最少的層數，所有這些都是為了提供輕量、高性能的接口。同時 ADO 使用了與 DAO和 RDO相似的約定和特性，簡化的語義使它更易于學習。
ADO最早是在IIS中引入的，主要用于ASP，用ADO可以使服務器端的腳本通過ODBC存取和操縱數據庫服務器的數據。使用ADO的對象可以建立和管理數據庫的連接，從數據庫服務器請求和獲取數據，執行更新、刪除、添加數據、獲取ODBC的錯誤信息等。ADO是ASP方案中最具吸引力的數據庫連接控件，它為用戶提供了連接任何兼容ODBC的數據庫以及創建全功能數據庫應用程序的能力。
ADO具有簡單易用、高速、占用資源少等的優點。不同于DAO和RDO，ADO有著更高的執行效率。ADO 對象模型如圖1a所示。每個 Connection、Command、Recordset 和 Field 對象都有 Properties 集合，如圖1b所示。
a)
b)
圖1 ADO對象模型及屬性
應該說，ADO是微軟的下一代數據庫連接技術，用來全面取代RDO和DAO的數據訪問工具。從發展趨勢來看，ADO今后將逐步替代老的DAO特別是RDO數據訪問接口，成為新的遠程數據訪問方法。所以，選擇ADO作為產品異地并行設計的Web數據庫接口技術是合適的。
1.2 ADO應用分析
ADO 并不是自動和現存的數據訪問應用程序代碼兼容的。當 ADO 封裝 DAO 和 RDO 的功能性的時候，必須將許多語言要素轉換為 ADO 語法。在某些情況下，這將意味著要對現存代碼的某些功能做一個簡單轉換。在其他情況下，最佳的做法可能是用 ADO 的新功能重寫該應用程序。
包含在 DAO 和 RDO 模型中的許多功能被合并為單個對象，這樣就生成了一個簡單得多的對象模型。然而，由于這個原因，起初可能會覺得找到合適的 ADO 對象、集合、屬性、方法，或事件非常困難。與 DAO 和 RDO不同的是，盡管 ADO 對象是分層結構的，但在分層結構范圍之外也是可以創建的。同時，也應當注意，ADO 當前并不支持 DAO 的所有功能。ADO 主要包括 RDO 風格的功能性，以便和 OLE DB 數據源交互，另外還包括遠程和 DHTML 技術。
一般說來，在 ADO 的演化過程中，馬上把大多數 DAO 應用程序（except possibly是那些使用 ODBCDirect 的應用程序）移植到 ADO 上為時太早，因為當前的 ADO 并不支持數據定義 (DDL)、用戶、組等等。不過，如果只將 DAO 用于客戶—服務器應用程序，并不依賴于 Jet 數據庫引擎或不使用 DDL，那么就可能移植到 ADO。最終，Microsoft 將提供一個 ADO DDL 組件來幫助進行 DAO 到 ADO 的移植，并為 OLE DB 供應商提供一般的 DDL 支持。
在ASP中使用ADO技術來訪問Web數據庫，其應用前景是無可估量的。原理圖如下：
圖2 ADO在ASP程序中的應用
常見的數據庫類型有面向對象的數據庫（OODB）和關系型數據庫。OODB對主流數據庫應用開發來說是相當新穎的，使用OODB使應用程序中的數據對象與現實世界中的對象一一對應，面向對象數據庫擴充了對象模型。一個常用的對象模型是由對象數據庫管理組（ODMG）開發出來，具有比傳統的關系數據庫更優越的性能，但畢竟在目前還是一種探索階段，暫時還未有相應的技術普及。
關系數據庫已經是數據庫體系的世界標準。當開發一個數據驅動應用程序時，大多數情況下用戶需要訪問網絡（如Internet、Intranet等）上的數據信息，就RCDS就是建立在網絡的信息通訊之上，是完全的客戶機/服務器應用程序。
SQL Server是一個可縮放、高性能的關系型數據庫管理系統（RDBMS），它的設計是為了滿足分布式客戶/服務器計算的需要，允許客戶應用程序使用幾個特定的工具和技術控制從服務器檢索的數據。這些包括觸發器、存儲過程和規則的選項。因此，系統采用MS SQL Server7.0作為后臺數據庫。
數據模型通常有層次模型、網狀模型、關系模型及OO（面向對象）模型等。其中關系模型是建立在數學概念基礎之上的一種模型，由若干個關系框架組成的集合，它也是到目前為止最為成熟的一種數據庫類型。本文RCDS采用MS SQL Server作為后臺數據庫，根據數據庫工具和數據庫特點，開發出一套可靠健壯的數據存儲方案。
整個數據庫共有AdminData、ChatNames、DesignUnits、Message、OnlineUnits、Products、RqtTasks、RqtTaskUnits、RqtDesignUnits、ShareData、Tasks、TaskUnits和UploadFiles等表格。在建立數據模型的時候首先考慮是要避免重復數據，也就是建立規范化數據庫。規范化數據庫可以通過被稱為范式水平的指標來衡量，級別有第一范式、第二范式和第三范式，通常第三范式就是要達到的目標，因為它提供了數據冗余和開發簡易性之間的最好折衷。
RCDS數據庫正是按照第三范式標準來設計的，它保證了模型的精簡和表格的緊湊性。而第三范式標準也最大發揮了關系數據庫的優勢，圖3是部分表格的視圖鏈接情況。
圖3 關系表格視圖 4.1 并發控制的處理 在多個用戶同時訪問一個數據庫時就產生并發問題，特別是在其中一些用戶對數據庫有添加或刪除修改等操作時，那么其他所獲得的數據可能是一塌糊涂，甚至造成整個數據訪問的沖突、終止，從而使系統發生混亂以至崩潰。RCDS采用的解決辦法是鎖定技術，總體上分為共享鎖定和排它鎖定兩種類型（如圖4）。前者是指同時有幾個過程共享一個鎖定，比如一個用戶（或客戶）正在讀取一個數據，雖然在這之前他已經對該數據設置了鎖（LOCK），但其他用戶同樣可以（也只能是）讀取它。而排他鎖定一般應用于對數據進行修改或更新（包括添加刪除等）操作，即是用戶在修改一個數據之前設置了鎖定，在一定的時間里其他用戶是不能訪問到該數據的，只有等待鎖定解除（UNLOCK）才能進行訪問到它，當然在計算機處理的時候，其他的用戶一般是感覺不到有這個等待時間的。通過這樣的處理，就保證了數據的一致性。
a) 共享鎖定
b) 排它鎖定
圖4 安全鎖定類型
在ADO進行數據庫操作時，它的鎖定類型相對來說復雜一些。打開記錄集時，可以指定鎖定類型。鎖定類型決定了當不止一個用戶同時試圖改變一個記錄時，數據庫應如何處理。ADO中的鎖定主要有以下四種類型：
l AdLockReadOnly 指定你不能修改記錄集中的記錄
l AdLockPessimistic 指定在編輯一個記錄時，立即鎖定它
l AdLockOptimstic 指定只有調用記錄集的Update方法時，才鎖定記錄
l AdLockBatchOptimstic 指定記錄只能成批地更新
在缺省情況下，記錄集使用只讀鎖定。要指定不同的鎖定類型，可以在打開記錄集時包含這些鎖定常量之一。部分代碼如下：
… …
Set MyConn=Sever.CreateObject(“ADODB.Connection”)
//定義數據庫連接MyConn
Set RS=Sever.CreateObject(“ADODB.RecordSet”)
//定義返回數據記錄集
MyConn.Open “ByktDB.dsn”//建立應用程序與數據源的連接
RS.Open “SELECT * FROM Mytable”， MyConn， adOpenDynamic， adLockPessimistic
//進行數據庫操作，并且設置鎖定
RS.Close
MyConn.Close
… …
數據的安全因素除了前面所提到的并行控制之外，還要考慮事務處理。網絡數據庫有其不同的地方，例如：假設某個時間有一個設計人員在你的站點上索取一些設計信息，有關的設計信息存儲在兩個表中。一個表用來保存該設計者的信息，另一個表包含了要索取的設計信息。該設計人員的信息已經輸入了第一個表中。但是，就在這時，發生了意外情況，一道閃電擊中了你的服務器，使第二個表沒有被更新。在這種情況下，一個健壯的系統就必須保證最后的結果是兩個表都沒有被更新過。這時候事務處理就發揮了重要的功效。
使用事務處理，你可以防止第二個表沒有被更新而第一個表被更新的情況出現：當一組語句構成一個事務處理時，如果一個語句沒有執行成功，則所有的語句都不成功。不管是針對多個表，還是進行表內多個記錄的操作，它們所需要的安全保證是一樣的。事務處理的實現代碼如下：
… …
Set MyConn=Sever.CreateObject(“ADODB.Connection”)
MyConn.Open “ByktDB.dsn”
MyConn.BeginTrans //事務處理開始
MyConn.Execute “INSERT DataTable(Num) Values(‘3628’)”
MyConn.Execute “INSERT Shipping (Address) VALUES(‘Paris，France’)”
MyConn.CommitTrans //事務處理結束
MyConn.Close
… …
在上面這段代碼中，用BeginTrans方法和CommitTrans方法來標記事務處理的開始和結束。在BeginTrans方法被調用之后，CommitTRans方法被調用之前，不管出現什么錯誤，兩個表都不會被更新，在這個過程中所有處理的數據都保持了完全可靠的一致性。
5 結論 ADO是由微軟公司推出的以ActiveX技術為基礎的數據存取方法。它的主要特點是使用更加容易，訪問速度更快，支持建立各種客戶/服務器模式與基于Web的應用程序。RCDS正是采用ADO 所基于的OLE DB技術，可以對電子郵件、文本文件、數據表格等各類數據通過統一的接口API接口進行存取，是遠程數據存取的一個主要發展方向。
