數據庫課程設計的非功能性需求_第1頁
數據庫課程設計的非功能性需求_第2頁
數據庫課程設計的非功能性需求_第3頁
數據庫課程設計的非功能性需求_第4頁
數據庫課程設計的非功能性需求_第5頁
全文預覽已結束

下載本文檔

版權說明:本文檔由用戶提供并上傳,收益歸屬內容提供方,若內容存在侵權,請進行舉報或認領

文檔簡介

數據庫課程設計的非功能性需求對一個數據庫來說,只能做到更優,不可能最優,并且根據實際需要,優化方案也是有所差異的,大概需要我們關心的有它的讀取速度、存儲空間、可維護性以及可擴展性等,而這些方面往往又是相互矛盾的,下面就結合網上的一些資料來談談數據的分析設計。一般來說,在系統分析階段往往有很多需要關注的方面,系統各種功能性、可用性、可靠性、平安性需要求往往吸引了我們大局部的注意力,但是,我們還需要注意,性能也是很重要的非功能性需求,必須根據系統的特點確定其實時性需求、響應時間的需求、硬件的配置等。最好是能有各種需求的量化指標。設計階段可以說是以后系統性能的關鍵階段,在這個階段,有一個關系到以后幾乎所有性能調優的過程,那就是數據庫的設計。在數據庫設計完成后,可以進行初步的索引設計,好的索引設計可以指導編碼階段寫出高效的代碼,為整個系統的性能打下良好的根底。下面是一些關于性能要求數據庫設計階段必須要注意的:1、數據庫邏輯設計的標準化數據庫邏輯設計的標準化就是我們一般所說的范式,我們可以這樣來簡單理解范式:第1標準:沒有重復的組或多值的列,這是數據庫設計的最低要求。第2標準:每個非關鍵字段必須依賴于主關鍵字,不能依賴于一個組合式主關鍵字的某些組成局部。即消除局部依賴,大局部情況下,數據庫設計都應該到達第二范式。第3標準:一個非關鍵字段不能依賴于另一個非關鍵字段。即消除傳遞依賴,到達第三范式應該是系統中大局部表的要求,除非一些特殊作用的表。更高的范式要求這里就不再作介紹了,個人認為,如果全部到達第二范式,大局部到達第三范式,系統會產生較少的列和較多的表,因而減少了數據冗余,也利于性能的提高。2、合理的冗余完全按照標準化設計的系統幾乎是不可能的,除非系統特別的小,在標準化設計后,有方案地參加冗余也是必要的〔比方:有些情況有冗余也是為了減少聯合查詢,提高查詢速度〕。冗余可以是冗余數據庫、冗余表或者冗余字段,不同粒度的冗余可以起到不同的作用。冗余可以是為了編程方便而增加,也可以是為了性能的提高而增加。從性能角度來說,冗余數據庫可以分散數據庫壓力,冗余表可以分散數據量大的表的并發壓力,也可以加快特殊查詢的速度,冗余字段可以有效減少數據庫表的連接,提高效率。3、主鍵的設計主鍵是必要的,SQLSERVER的主鍵同時是一個唯一索引,而且在實際應用中,我們往往選擇最小的鍵組合作為主鍵,所以主鍵往往適合作為表的聚集索引。聚集索引對查詢的影響是比擬大的,這個在下面索引有表達。在有多個鍵的表,主鍵的選擇也比擬重要,一般選擇總的長度小的鍵,小的鍵的比擬速度快,同時小的鍵可以使主鍵的B樹結構的層次更少。主鍵的選擇還要注意組合主鍵的字段次序,對于組合主鍵來說,不同的字段次序的主鍵的性能差異可能會很大,一般應該選擇重復率低、單獨或者組合查詢可能性大的字段放在前面。4、外鍵的設計外鍵作為數據庫對象,很多人認為麻煩而不用,實際上,外鍵在大局部情況下是很有用的,理由是:外鍵是最高效的一致性維護方法,數據庫的一致性要求,依次可以用外鍵、CHECK約束、規則約束、觸發器、客戶端程序,一般認為,離數據越近的方法效率越高。謹慎使用級聯刪除和級聯更新,級聯刪除和級聯更新作為SQLSERVER2000當年的新功能,在2005作了保存,應該有其可用之處。我這里說的謹慎,是因為級聯刪除和級聯更新有些突破了傳統的關于外鍵的定義,功能有點太過強大,使用前必須確定自己已經把握好其功能范圍,否則,級聯刪除和級聯更新可能讓你的數據莫名其妙的被修改或者喪失。但是從性能看級聯刪除和級聯更新是比其他方法更高效的方法。5、字段的設計字段是數據庫最根本的單位,其設計對性能的影響是很大的。需要注意如下:A、數據類型盡量用數字型,數字型的比擬比字符型的快很多。B、數據類型盡量小,這里的盡量小是指在滿足可以預見的未來需求的前提下的。C、盡量不要允許NULL,除非必要,可以用NOTNULL+DEFAULT代替。D、少用TEXT和IMAGE,二進制字段的讀寫是比擬慢的,而且,讀取的方法也不多,大局部情況下最好不用。E、自增字段要慎用,不利于數據遷移。6、數據庫物理存儲和環境的設計在設計階段,可以對數據庫的物理存儲、操作系統環境、網絡環境進行必要的設計,使得我們的系統在將來能適應比擬多的用戶并發和比擬大的數據量。這里需要注意文件組的作用,適用文件組可以有效把I/O操作分散到不同的物理硬盤,提高并發能力。7、系統設計整個系統的設計特別是系統結構設計對性能是有很大影響的,對于一般的OLTP(聯機事務處理系統)系統,可以選擇C/S結構、三層的C/S結構等,不同的系統結構其性能的關鍵也有所不同。系統設計階段應該歸納一些業務邏輯放在數據庫編程實現,數據庫編程包括數據庫存儲過程、觸發器和函數。用數據庫編程實現業務邏輯的好處是減少網絡流量并可更充分利用數據庫的預編譯和緩存功能。8、索引的設計在設計階段,可以根據功能和性能的需求進行初步的索引設計,這里需要根據預計的數據量和查詢來設計索引,可能與將來實際使用的時候會有所區別。關于索引的選擇,應改主意:A、根據數據量決定哪些表需要增加索引,數據量小的可以只有主鍵。B、根據使用頻率決定哪些字段需要建立索引,選擇經常作為連接條件、篩選條件、聚合查詢、排序的字段作為索引的候選字段。C、把經常一起出現的字段組合在一起,組成組合索引,組合索引的字段順序與主鍵一樣,也需要把最常用的字段放在前面,把重復率低的字段放在前面。D、一個表不要加太多索引,因為索引影響插入和更新的速度總結:系統性能優化無疑是為了提高系統的執行速度

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯系上傳者。文件的所有權益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網頁內容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經權益所有人同意不得將文件中的內容挪作商業或盈利用途。
  • 5. 人人文庫網僅提供信息存儲空間,僅對用戶上傳內容的表現方式做保護處理,對用戶上傳分享的文檔內容本身不做任何修改或編輯,并不能對任何下載內容負責。
  • 6. 下載文件中如有侵權或不適當內容,請與我們聯系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論