大型數據庫設計原則與技巧
???????一個好的數據庫產品不等于就有一個好的應用系統，如果不能設計一個合理的數據庫模型，不僅會增加客戶端和服務器段程序的編程和維護的難度，而且將會影響系統實際運行的性能。一般來講，在一個MIS系統分析、設計、測試和試運行階段，因為數據量較小，設計人員和測試人員往往只注意到功能的實現，而很難注意到性能的薄弱之處，等到系統投入實際運行一段時間后，才發現系統的性能在降低，這時再來考慮提高系統性能則要花費更多的人力物力，而整個系統也不可避免的形成了一個打補丁工程。筆者依據多年來設計和使用數據庫的經驗，提出以下一些設計準則，供同仁們參考。

1：命名的規范
????? 不同的數據庫產品對對象的命名有不同的要求，因此數據庫中的各種對象的命名、后臺程序的代碼編寫應采用大小寫敏感的形式，各種對象命名長度不要超過30個字符，這樣便于應用系統適應不同的數據庫。

2：游標（Cursor）的慎用
游標提供了對特定集合中逐行掃描的手段，一般使用游標逐行遍歷數據，根據取出的數據不同條件進行不同的操作。尤其對多表和大表定義的游標（大的數據集合）循環很容易使程序進入一個漫長的等特甚至死機，筆者在某市《住房公積金管理系統》進行日終帳戶滾積數計息處理時，對一個10萬個帳戶的游標處理導致程序進入了一個無限期的等特（后經測算需48個小時才能完成）(硬件環境：Alpha/4000 128Mram ,Sco Unix
,Sybase 11.0)，后根據不同的條件改成用不同的UPDATE語句得以在二十分鐘之內完成。
示例如下：
Declare Mycursor cursor for select count_no from COUNT
Open Mycursor
Fetch Mycursor into @vcount_no
While (@@sqlstatus=0)
??? Begin
If @vcount_no=’’ 條件1
操作1
?? If @vcount_no=’’ 條件2
?? 操作2
Fetch Mycursor into @vcount_no
End
改為
Update COUNT set 操作1 for 條件1
Update COUNT set 操作2 for 條件2
在有些場合，有時也非得使用游標，此時也可考慮將符合條件的數據行轉入臨時表中，再對臨時表定義游標進行操作，可時性能得到明顯提高。筆者在某地市〈電信收費系統〉數據庫后臺程序設計中，對一個表（3萬行中符合條件的30多行數據）進行游標操作(硬件環境：PC服務器，PII266 64Mram ,NT4.0 Ms Sqlserver 6.5)。 示例如下：
Create? #TmpTable?? /* 定義臨時表 */
(
?? 字段1
?? 字段2
)
INSERT? INTO? #tmp? SELECT? *? FROM? TotalTable? WHERE 條件 /* TOTAL中3萬行 符合條件只有幾十行 */
Declare Mycursor cursor for select * from #tmp
/*對臨時表定義游標*/

3：索引(Index)的使用原則
???? 創建索引一般有以下兩個目的：維護被索引列的唯一性和提供快速訪問表中數據的策略。大型數據庫有兩種索引即簇索引和非簇索引，一個沒有簇索引的表是按堆結構存儲數據，所有的數據均添加在表的尾部，而建立了簇索引的表，其數據在物理上會按照簇索引鍵的順序存儲，一個表只允許有一個簇索引，因此，根據B樹結構，可以理解添加任何一種索引均能提高按索引列查詢的速度，但會降低插入、更新、刪除操作的性能，尤其是當填充因子（Fill Factor）較大時。所以對索引較多的表進行頻繁的插入、更新、刪除操作，建表和索引時因設置較小的填充因子，以便在各數據頁中留下較多的自由空間，減少頁分割及重新組織的工作。

4：數據的一致性和完整性
?? 為了保證數據庫的一致性和完整性，設計人員往往會設計過多的表間關聯（Relation），盡可能的降低數據的冗余。表間關聯是一種強制性措施，建立后，對父表（Parent Table）和子表(Child Table)的插入、更新、刪除操作均要占用系統的開銷，另外，最好不要用Identify 屬性字段作為主鍵與子表關聯。如果數據冗余低，數據的完整性容易得到保證，但增加了表間連接查詢的操作，為了提高系統的響應時間，合理的數據冗余也是必要的。使用規則（Rule）和約束（Check）來防止系統操作人員誤輸入造成數據的錯誤是設計人員的另一種常用手段，但是不必要的規則和約束也會占用系統的不必要開銷，需要注意的是，約束對數據的有效性驗證要比規則快。所有這些，設計人員在設計階段應根據系統操作的類型、頻度加以均衡考慮。

5：事務的陷阱
??? 事務是在一次性完成的一組操作。雖然這些操作是單個的操作，SQL Server能夠保證這組操作要么全部都完成，要么一點都不做。正是大型數據庫的這一特性，使得數據的完整性得到了極大的保證。眾所周知，SQL Server為每個獨立的SQL語句都提供了隱含的事務控制，使得每個DML的數據操作得以完整提交或回滾，但是SQL Server還提供了顯式事務控制語句
---- BEGIN TRANSACTION????? 開始一個事務
---- COMMIT TRANSACTION??? 提交一個事務
---- ROLLBACK TRANSACTION? 回滾一個事務
---- 事務可以嵌套，可以通過全局變量@@trancount檢索到連接的事務處理嵌套層次。需要加以特別注意并且極容易使編程員犯錯誤的是，每個顯示或隱含的事物開始都使得該變量加1，每個事務的提交使該變量減1，每個事務的回滾都會使得該變量置0，而只有當該變量為0時的事務提交（最后一個提交語句時），這時才把物理數據寫入磁盤。

6：數據庫性能調整
???????? 在計算機硬件配置和網絡設計確定的情況下，影響到應用系統性能的因素不外乎為數據庫性能和客戶端程序設計。而大多數數據庫設計員采用兩步法進行數據庫設計：首先進行邏輯設計，而后進行物理設計。數據庫邏輯設計去除了所有冗余數據，提高了數據吞吐速度，保證了數據的完整性，清楚地表達數據元素之間的關系。而對于多表之間的關聯查詢（尤其是大數據表）時，其性能將會降低，同時也提高了客 戶端程序的編程難度，因此，物理設計需折衷考慮，根據業務規則，確定對關聯表的數據量大小、數據項的訪問頻度，對此類數據表頻繁的關聯查詢應適當提高數據冗余設計。

7：數據類型的選擇
??????? 數據類型的合理選擇對于數據庫的性能和操作具有很大的影響，有關這方面的書籍也有不少的闡述，這里主要介紹幾點經驗。Identify字段不要作為表的主鍵與其它表關聯，這將會影響到該表的數據遷移。Text 和Image字段屬指針型數據，主要用來存放二進制大型對象（BLOB）。這類數據的操作相比其它數據類型較慢，因此要避開使用。日期型字段的優點是有眾多的日期函數支持，因此，在日期的大小比較、加減操作上非常簡單。但是在按照日期作為條件的查詢操作也要用函數，相比其它數據類型速度上就慢許多,因為用函數作為查詢的條件時，服務器無法用先進的性能策略來優化查詢而只能進行表掃描遍歷每行。
---- 例如：要從DATA_TAB1中（其中有一個名為DATE的日期字段）查詢1998年的所有記
錄。
---- SELECT * FROM? DATA_TAB1 WHERE? datepart(yy,DATE) = 1998

隨著計算機技術越來越廣泛地應用于國民經濟的各個領域，在計算機硬件不斷微型化的同時，應用系統向著復雜化、大型化的方向發展。數據庫是整個系統的核心，它的設計直接關系系統執行的效率和系統的穩定性。因此在軟件系統開發中，數據庫設計應遵循必要的數據庫范式理論，以減少冗余、保證數據的完整性與正確性。只有在合適的數據庫產品上設計出合理的數據庫模型，才能降低整個系統的編程和維護難度，提高系統的實際運行效率。雖然對于小項目或中等規模的項目 開發人員可以很容易地利用范式理論設計出一套符合要求的數據庫，但對于一個包含大型數據庫的軟件項目，就必須有一套完整的設計原則與技巧。
一、成立數據小組
大型數據庫數據元素多，在設計上有必要成立專門的數據小組。由于數據庫設計者不一定是使用者，對系統設計中的數據元素不可能考慮周全，數據庫設計出來后，往往難以找到所需的庫表，因此數據小組最好由熟悉業務的項目骨干組成。
數據小組的職能并非是設計數據庫，而是通過需求分析，在參考其他相似系統的基礎上，提取系統的基本數據元素，擔負對數據庫的審核。審核內容包括審核新的數據庫元素是否完全、能否實現全部業務需求；對舊數據庫（如果存在舊系統）的分析及數據轉換；數據庫設計的審核、控制及必要調整。
二、設計原則
１．規范命名。所有的庫名、表名、域名必須遵循統一的命名規則，并進行必要說明，以方便設計、維護、查詢。
２．控制字段的引用。在設計時，可以選擇適當的數據庫設計管理工具，以方便開發人員的分布式設計和數據小組的集中審核管理。采用統一的命名規則，如果設計的字段已經存在，可直接引用；否則，應重新設計。
３．庫表重復控制。在設計過程中，如果發現大部分字段都已存在，開發人員應懷疑所設計的庫表是否已存在。通過對字段所在庫表及相應設計人員的查詢，可以確認庫表是否確實重復。
４．并發控制。設計中應進行并發控制，即對于同一個庫表，在同一時間只有一個人有控制權，其他人只能進行查詢。
５．必要的討論。數據庫設計完成后，數據小組應與相關人員進行討論，通過討論來熟悉數據庫，從而對設計中存在的問題進行控制或從中獲取數據庫設計的必要信息。
６．數據小組的審核。庫表的定版、修改最終都要通過數據小組的審核，以保證符合必要的要求。
７．頭文件處理。每次數據修改后，數據小組要對相應的頭文件進行修改（可由管理軟件自動完成），并通知相關的開發人員，以便進行相應的程序修改。

三、設計技巧
１．分類拆分數據量大的表。對于經常使用的表（如某些參數表或代碼對照表），由于其使用頻率很高，要盡量減少表中的記錄數量。例如，銀行的戶主賬表原來設計成一張表，雖然可以方便程序的設計與維護，但經過分析發現，由于數據量太大，會影響數據的迅速定位。如果將戶主賬表分別設計為活期戶主賬、定期戶主賬及對公戶主賬等，則可以大大提高查詢效率。
２．索引設計。對于大的數據庫表，合理的索引能夠提高整個數據庫的操作效率。在索引設計中，索引字段應挑選重復值較少的字段；在對建有復合索引的字段進行檢索時，應注意按照復合索引字段建立的順序進行。例如，如果對一個５萬多條記錄的流水表以日期和流水號為序建立復合索引，由于在該表中日期的重復值接近整個表的記錄數，用流水號進行查詢所用的時間接近３秒；而如果以流水號為索引字段建立索引進行相同的查詢，所用時間不到１秒。因此在大型數據庫設計中，只有進行合理的索引字段選擇，才能有效提高整個數據庫的操作效率。
３．數據操作的優化。在大型數據庫中，如何提高數據操作效率值得關注。例如，每在數據庫流水表中增加一筆業務，就必須從流水控制表中取出流水號，并將其流水號的數值加一。正常情況下，單筆操作的反應速度尚屬正常，但當用它進行批量業務處理時，速度會明顯減慢。經過分析發現，每次對流水控制表中的流水號數值加一時都要鎖定該表，而該表卻是整個系統操作的核心，有可能在操作時被其他進程鎖定，因而使整個事務操作速度變慢。對這一問題的解決的辦法是，根據批量業務的總筆數批量申請流水號，并對流水控制表進行一次更新，即可提高批量業務處理的速度。另一個例子是對插表的優化。對于大批量的業務處理，如果在插入數據庫表時用普通的Ｉｎｓｅｒｔ語句，速度會很慢。其原因在于，每次插表都要進行一次Ｉ/Ｏ操作，花費較長的時間。改進后，可以用Ｐｕｔ語句等緩沖區形式等滿頁后再進行Ｉ/Ｏ操作，從而提高效率。對大的數據庫表進行刪除時，一般會直接用Ｄｅｌｅｔｅ語句，這個語句雖然可以進行小表操作，但對大表卻會因帶來大事務而導致刪除速度很慢甚至失敗。解決的方法是去掉事務，但更有效的辦法是先進行Ｄｒｏｐ操作再進行重建。
４．數據庫參數的調整。數據庫參數的調整是一個經驗不斷積累的過程，應由有經驗的系統管理員完成。以Ｉｎｆｏｒｍｉｘ數據庫為例，記錄鎖的數目太少會造成鎖表的失敗；邏輯日志的文件數目太少會造成插入大表失敗等，這些問題都應根據實際情況進行必要的調整。
５．必要的工具。在整個數據庫的開發與設計過程中，可以先開發一些小的應用工具，如自動生成庫表的頭文件、插入數據的初始化、數據插入的函數封裝、錯誤跟蹤或自動顯示等，以此提高數據庫的設計與開發效率。
６．避免長事務。對單個大表的刪除或插入操作會帶來大事務，解決的辦法是對參數進行調整，也可以在插入時對文件進行分割。對于一個由一系列小事務順序操作共同構成的長事務（如銀行交易系統的日終交易），可以由一系列操作完成整個事務，但其缺點是有可能因整個事務太大而使不能完成，或者，由于偶然的意外而使事務重做所需的時間太長。較好的解決方法是，把整個事務分解成幾個較小的事務，再由應用程序控制整個系統的流程。這樣，如果其中某個事務不成功，則只需重做該事務，因而既可節約時間，又可避免長事務。
７．適當超前。計算機技術發展日新月異，數據庫的設計必須具有一定前瞻性，不但要滿足當前的應用要求，還要考慮未來的業務發展，同時必須有利于擴展或增加應用系統的處理功能。
相對于中小型數據庫，大型數據庫的設計與開發要復雜得多，因此在設計、開發過程中，除了要遵循數據庫范式理論、增加系統的一致性和完整性外，還要在總體上根據具體情況進行分布式設計，緊緊把握集中控制、統一審核的基本原則，保證數據庫設計結構緊湊、分布平衡、定位迅速。在數據庫操作上，要采用一定的技巧提高整個應用系統的執行效率，并注意適當超前，以適應不斷變化的應用及系統發展的要求。
一個好的數據庫產品不等于就有一個好的應用系統，如果不能設計一個合理的數據庫模型，不僅會增加客戶端和服務器段程序的編程和維護的難度，而且將會影響系統實際運行的性能。一般來講，在一個MIS系統分析、設計、測試和試運行階段，因為數據量較小，設計人員和測試人員往往只注意到功能的實現，而很難注意到性能的薄弱之處，等到系統投入實際運行一段時間后，才發現系統的性能在降低……
??? 數據庫設計是建立數據庫及其應用系統的核心和基礎，它要求對于指定的應用環境，構造出較優的數據庫模式，建立起數據庫應用系統，并使系統能有效地存儲數據，滿足用戶的各種應用需求。一般按照規范化的設計方法，常將數據庫設計分為若干階段：
系統規劃階段
??? 主要是確定系統的名稱、范圍；確定系統開發的目標功能和性能；確定系統所需的資源；估計系統開發的成本；確定系統實施計劃及進度；分析估算系統可能達到的效益；確定系統設計的原則和技術路線等。對分布式數據庫系統，還應分析用戶環境及網絡條件，以選擇和建立系統的網絡結構。
需求分析階段
????? 要在用戶調查的基礎上，通過分析，逐步明確用戶對系統的需求，包括數據需求和圍繞這些數據的業務處理需求。通過對組織、部門、企業等進行詳細調查，在了解現行系統的概況、確定新系統功能的過程中，收集支持系統目標的基礎數據及其處理方法。
?概念設計階段
????? 要產生反映企業各組織信息需求的數據庫概念結構，即概念模型。概念模型必須具備豐富的語義表達能力、易于交流和理解、易于變動、易于向各種數據模型轉換、易于從概念模型導出與DBMS有關的邏輯模型等特點。
邏輯設計階段
??? 除了要把E－R圖的實體和聯系類型，轉換成選定的DBMS支持的數據類型，還要設計子模式并對模式進行評價，最后為了使模式適應信息的不同表示，需要優化模式。
物理設計階段
??? 主要任務是對數據庫中數據在物理設備上的存放結構和存取方法進行設計。數據庫物理結構依賴于給定的計算機系統，而且與具體選用的DBMS密切相關。物理設計常常包括某些操作約束，如響應時間與存儲要求等。
系統實施階段
??? 主要分為建立實際的數據庫結構；裝入試驗數據對應用程序進行測試；裝入實際數據建立實際數據庫三個步驟。
??? 另外，在數據庫的設計過程中還包括一些其他設計，如數據庫的安全性、完整性、一致性和可恢復性等方面的設計,不過，這些設計總是以犧牲效率為代價的,設計人員的任務就是要在效率和盡可能多的功能之間進行合理的權衡。
一個好的數據庫產品不等于就有一個好的應用系統，如果不能設計一個合理的數據庫模型，不僅會增加客戶端和服務器段程序的編程和維護的難度，而且將會影響系統實際運行的性能。一般來講，在一個MIS系統分析、設計、測試和試運行階段，因為數據量較小，設計人員和測試人員往往只注意到功能的實現，而很難注意到性能的薄弱之處，等到系統投入實際運行一段時間后，才發現系統的性能在降低
?????? 數據庫設計是建立數據庫及其應用系統的核心和基礎，它要求對于指定的應用環境，構造出較優的數據庫模式，建立起數據庫應用系統，并使系統能有效地存儲數據，滿足用戶的各種應用需求。一般按照規范化的設計方法，常將數據庫設計分為若干階段：
系統規劃階段
??? 主要是確定系統的名稱、范圍；確定系統開發的目標功能和性能；確定系統所需的資源；估計系統開發的成本；確定系統實施計劃及進度；分析估算系統可能達到的效益；確定系統設計的原則和技術路線等。對分布式數據庫系統，還應分析用戶環境及網絡條件，以選擇和建立系統的網絡結構。
?需求分析階段
??? 要在用戶調查的基礎上，通過分析，逐步明確用戶對系統的需求，包括數據需求和圍繞這些數據的業務處理需求。通過對組織、部門、企業等進行詳細調查，在了解現行系統的概況、確定新系統功能的過程中，收集支持系統目標的基礎數據及其處理方法。
?概念設計階段
??? 要產生反映企業各組織信息需求的數據庫概念結構，即概念模型。概念模型必須具備豐富的語義表達能力、易于交流和理解、易于變動、易于向各種數據模型轉換、易于從概念模型導出與DBMS有關的邏輯模型等特點。
?邏輯設計階段
??? 除了要把E－R圖的實體和聯系類型，轉換成選定的DBMS支持的數據類型，還要設計子模式并對模式進行評價，最后為了使模式適應信息的不同表示，需要優化模式。
??? 物理設計階段
??? 主要任務是對數據庫中數據在物理設備上的存放結構和存取方法進行設計。數據庫物理結構依賴于給定的計算機系統，而且與具體選用的DBMS密切相關。物理設計常常包括某些操作約束，如響應時間與存儲要求等。
??? 系統實施階段
??? 主要分為建立實際的數據庫結構；裝入試驗數據對應用程序進行測試；裝入實際數據建立實際數據庫三個步驟。
??? 另外，在數據庫的設計過程中還包括一些其他設計，如數據庫的安全性、完整性、一致性和可恢復性等方面的設計,不過，這些設計總是以犧牲效率為代價的,設計人員的任務就是要在效率和盡可能多的功能之間進行合理的權衡。

?

轉載于:https://www.cnblogs.com/PatrickLee/archive/2012/07/24/2606383.html

總結

以上是生活随笔為你收集整理的大型数据库设计原则与技巧的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。