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

數據庫設計范文第1篇

2、概念結構設計：對用戶需求綜合、歸納與抽象，形成概念模型；

3、邏輯結構設計：將概念結構轉換為某個DBMS所支持的數據模型；

4、數據庫物理設計：為邏輯數據模型選取一個最適合應用環境的物理結構；

5、數據庫實施：建立數據庫，編制與調試應用程序，組織數據入庫，程序試運行；

數據庫設計范文第2篇

基站網元需要對數據的各種操作方式作出快速的響應，以及用戶信息的固化存儲，防止斷電后引起的數據丟失，基站的系統資源有限制，不能選用耗費系統資源的物理數據庫，專用通信網絡使用SQLite數據庫，集成了內存的高效操作以及支持物理存儲，無需安裝，應用廣，商用性好。基站控制器，調度臺服務器，網管服務器等網元需要存儲各種不同的用戶信息以及呼叫服務信息，計費信息等各種海量數據，它們對操作數據的反應時間沒有很嚴格的需求，但對數據庫存儲能力有較大的需求，可以采用應用比較廣泛的MySQL數據庫。一級網元，作為整網的數據存儲以及處理中心，數據量以及數據安全性是需要首先考慮的問題，Oracle是最值得信賴的大型關系型數據庫。虛擬數據庫使上層軟件開發人員無需關心任何物理數據庫接口，只需要使用虛擬數據庫提供的一套接口，即可自由靈活進行數據的管理操作。

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）底層網元接收完成數據庫后，打開數據庫，上報數據資源審計請求。

3結束語

數據庫設計范文第3篇

【關鍵詞】計算機;數據庫;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.

[4]勵文杰.大型數據庫ORACLE數據庫的優化設計方案[J].科技風，2011，19：145.

數據庫設計范文第4篇

關鍵詞： Internet 異地設計 Web數據庫

近年來，隨著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接口進行存取，是遠程數據存取的一個主要發展方向。

RCDS的后臺數據庫采用的是Ms SQL Server的最新版本7.0，它的高性能和周密的數據管理措施是系統穩定的保證。除了數據庫工具本身所具備的安全保障措施，系統的開發過程中從代碼實現及用戶訪問等考慮了更為具體的數據安全措施：并發控制和事務處理。

數據庫設計范文第5篇

    第一章緒言

    本論文主要介紹的是企事業使用的人事治理系統的整個設計。

    隨著計算機技術的不斷發展,計算機應用于各大領域,并給人們的生活帶來了極大的便利,在人員治理系統亦是。以往企事業人事員由于缺乏適當的軟件而給其工作帶來了很多不便。本論文所介紹的便是一個企事業人事治理系統,以方便其在人事安排和人事治理上的工作任務。

    該系統適用于企事業人事員,其功能主要分為四大類:

    系統初始化;檔案更新;檔案查詢;檔案打印等,該系統性能力求易于使用,具有較高的擴展性和可維護性。

    整個系統的開發過程嚴格遵循軟件工程的要求,做到模塊化分析、模塊化設計和代碼編寫的模塊化。

    第二章系統需求分析

    2.1現行業務系統描述

    在企業,人事治理工作是非常重要的一項工作,它負責整個企業的日常人事安排,人員的人事治理等等。以前都是人工進行操作。隨著企業規模擴大,人事處的人事治理工作量大大加重。隨著計算機應用的發展,人事工作者急切希望能夠將大部分繁瑣的工作交由計算機的處理,已減輕人工的壓力并提高工作效率。而計算機的普及更加快了人事治理系統的產生。

    上一代的人事治理系統主要采用Foxbase或FoxPro,系統開發環境也是數據庫內置的開發工具。其特點是單機單用戶方式,開發簡單,能充分利用數據庫的特性。其缺點是開發出的系統依靠性強,運行必須依托數據庫環境;不輕易升級與擴展;無法實現數據的共享與并行操作;代碼重用性差。

    原有人事治理系統數據共享差的問題更加突出,而新需求的提出也越來越多,越來越頻繁。這就要求系統在可擴展性和標準化的要求更高。而原有的系統由于其與生俱來的缺點而無法在適應現有的需求了。

    因此,使用現在的新技術,開發出適應新的需求的新系統的任務刻不容緩。

    2.2組織結構

    在企事業中,其中和人事治理系統由直接關系的部門是人事處,是使用綜合人事系統的主要部門,對人員的人事治理主要由人事處承擔,進行集中治理。

    2.3業務流程分析

    人事治理系統是一個面向企業人事人員,為其提供服務的綜合信息治理系統。人事人員通過本系統完成相關的日常工作,這些工作也是平常較為繁重的工作。人員的個人信息、以及各種相關的親屬等情況開課情況都記錄在人事系統里進行治理。

    由人事人員在檔案更新中完成對運行人事系統所需的基本數據的維護。包括這些信息的增、修、改等,變動都將在這進行操作。系統開始投入使用,人事人員先根據企業實際情況,建立相關人員的信息,主要信息包括系所的姓名及它的學歷等。輸入人員信息的過程是首先從系統數據庫中選擇相關的系所,然后再它下面加入新的輔助信息。當人員情況發生變動后,人事人員要及時完成對庫中的信息進行維護。假如發生人事的變動,則可以在檔案更新中進行處理,因為不同企業的員工數量不同,因此非凡設立了一個檔案查詢模塊,可以進行相關人員的快速查詢,并可以根據某一個具體的條件,如具有相同屬性的人員,進行同一類型的人員統計,并可以將結果通過打印輸出,以便備案。

    2.4現行系統存在的主要問題分析

    現行系統的主要問題歸納起來主要有,

    1.單機單用戶系統,隨著網絡的發展,同時人事治理系統中信息的使用者大大增加,原有的單機單用戶系統已遠遠不能滿足需要。同時,原有的數據庫也不支持多用戶的網絡運行環境。

    2.系統獨立性差,原有系統一般都是使用數據庫提供的開發工具編寫的程序,因此收數據庫的制約比較大,編寫出來的程序性能也不好。非凡是無法支持如Access,MSSQLServer等新的數據庫。

    3.模塊性差,由于不是一個完整的編程語言,故無法做到代碼的模塊化,給功能的擴展帶來了巨大的不便。

    2.5提出可能的解決方案

    鑒于目前企業對人事治理系統的需求與實際情況,新系統方案的重點放在系統的可擴展性上,為了實現這一設計,新系統應具備以下幾方面的要求:

    1.新系統采用VisualFoxpro6.0開發成功,充分利用該開發程序的優勢,提高了工作效率。

    2.新系統從設計到實現都應遵循模塊化,是用一致的接口進行信息的傳遞與模塊調用。模塊的劃分應盡量符合實際業務的劃分,以保證以后新模塊的加入盡可能少的影響現有功能模塊的運行。

    3、新系統所具有的特性:

    *通用性:用戶可根據本單位的需求靈活設置人員類別及其數據庫結構,可滿足不同層次,不同性質,不同業務工作的需求。

    *標準化:提供了豐富完善的人事治理內容,為各級人事部門之間的數據共享及數據交換奠定了良好的基礎。