資料庫設計經驗談 一 （引）

 資料庫設計經驗談

作者: 水若寒

一個成功的管理系統，是由：[50% 的業務 + 50% 的軟體] 所組成，而 50% 的成功軟體又有 [25% 的資料庫 + 25% 的程式] 所組成，資料庫設計的好壞是一個關鍵。如果把企業的資料比做生命所必需的血液，那麼資料庫的設計就是應用中最重要的一部分。有關資料庫設計的材料汗牛充棟，大學學位課程裡也有專門的講述。不過，就如我們反複強調的那樣，再好的老師也比不過經驗的教誨。

<script language=javascript>document.write(" ");ad_dst = ad_dst+1;</script> 插入一些資料庫設計心得：

一、 設計思想

對許多程式員來說，設計一個資料庫應用程式并不是很難的一件事。但是卻有許多資料庫應用軟體得不到使用者的承認，其原因就是前期調研中，資訊化設計機關和使用機關沒有得到相應的思想溝通。

這裡所說的溝通包括使用者對軟體功能的要求，時間效益的要求，軟體平台的要求，價格的要求和軟體維護的要求。這五種要求構成一個成功應用的軟體的所有的調研項目。

但是這裡最重要的就是對軟體功能的要求，不同的企業對軟體要求的是不一樣的。下面就軟體功能的需求要求做一個概要介紹：

1． 對象性：

這并不是軟體工程或者其他參考書中所描繪的軟體設計要求，但是這是一個必然的發展趨勢。我國軟體主要由财務軟體起步，财務業務流程是國家統一規定的，零售業的财務流程和建材業的财務業務流程并沒有多大不同，是以設計一種軟體就可以應用不同的公司甚至是跨行業的公司也就是很正常的一件事，但是随着我國市場經濟的發展，用資訊化技術來推動企業發展成為一種切實有效的手段，許多不同行業的企業甚至同行業不同企業對資訊化應用軟體都有不同的要求。

在現代程式開發技術中，面對對象的技術是一個大的飛躍。但是許多開發的資料庫應用軟體并沒由認識到這一點，是以開發的軟體就沒有市場。有一次，一個軟體推銷員到我公司來推銷軟體，是明煌軟體公司的人事管理軟體，公司人事部門上司很感興趣，随口問了幾個問題，其中一個是有沒有臨時工的管理，一個是工資統計查詢能不能按照職工年齡，崗位，職稱，學曆分類統計查詢。結果這個軟體沒有這兩項功能，是以人事部門上司很客氣的拒絕了這個應用軟體推銷員的關于示範軟體的請求。

作為一個開發人員來說，在一個資料庫應用軟體加上以上兩個功能實在是很一般的工作，但是就是因為在開發時沒有面對對象的考慮使用者的需求導緻了這次軟體推銷的失敗。

是以對一個應用軟體來說一開始就考慮軟體的對象性是一個成功的必要因素。

2．易用性

關于易用性的好壞不是由開發部門測定的，也不是由軟體評測機構認定的，而是由使用者認定的。這是在工作交流中得到确認的。

許多軟體考慮精細，例如ORACLE資料庫為背景資料庫的ORACLE公司的ERP軟體解決方案，就沒有考慮到中國的國情，不但應用界面分類複雜，而且在工作業務繁忙的時候，由于操作複雜往往還适得其反，到耽誤了工作，惹得上司埋怨，職工抱怨，反而不如不用。

在銷售系統軟體的調試過程中，我認識了一個銷售公司的業務員，他跟我談了使用軟體後的許多感想。他說軟體本來是減輕工作量的，但是銷售系統有的應用界面就很不友好，在向網絡資料庫中錄入資料時，錄入資料很多，但是軟體總要求一會用鍵盤打字，一會用滑鼠點選，這幾千項資料輸入時，人一會用鍵盤一會用滑鼠，活就像個鐘擺，累死了，幹嗎不設計的都能用鍵盤控制呢。

事實上就是這樣，軟體在編制的過程中一定要多與業務人員交流，了解工作流程很重要，但是決不能忽視易用性在整個軟體性能中不可忽視的比例。

3． 擴充性

作為現代軟體系統的一部分，可擴充性越來越成為構成軟體生命的主要功能之一。無論什麼公司都希望買的軟體能夠适應并滿足公司業務發展變化的需求，還希望能夠和其他購買的軟體一起構成一個完整的企業軟體系統。

在軟體上來說，這有點困難，因為要滿足這項要求不但要預測企業發展方向，并且在軟體中預留出資料交換接口，在應用文檔中要公布部分資料庫構成甚至時部分源碼。

但是從大的應用方向上，我們設計的軟體必須達到這樣使用的功能。金蝶，用友這兩個大的軟體公司已經實作的客戶開發工具包來實作客戶化二次開發的需求。

4． 維護功能

為了保證軟體正常工作，軟體維護是必要的。但是遠水救不了近火，誰也不能保證軟體在故障的時候軟體維護人員能夠及時維護，這就要求在軟體設計是要增加軟體維護功能。有了軟體維護功能，哪怕是簡單的備份功能，也能夠在突發事件中将資料損失降到最低點。

除了一般功能外，在軟體設計時，我認為上述四個功能是注意要添加和完善的，這樣我們作出來的資料庫應用軟體才能夠具有更高的使用價值。

。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。

是以我歸納曆年來所走的彎路及體會，并在網上找了些對資料庫設計頗有造詣的專業人士給大家傳授一些設計資料庫的技巧和經驗。精選了其中的 60 個最佳技巧，并把這些技巧編寫成了本文，為了友善索引其内容劃分為 5 個部分：

第 1 部分 - 設計資料庫之前

這一部分羅列了 12 個基本技巧，包括命名規範和明确業務需求等。

第 2 部分 - 設計資料庫表

總共 24 個指南性技巧，涵蓋表内字段設計以及應該避免的常見問題等。

第 3 部分 - 選擇鍵

怎麼選擇鍵呢？這裡有 10 個技巧專門涉及系統生成的主鍵的正确用法，還有何時以及如何索引字段以獲得最佳性能等。

第 4 部分 - 保證資料完整性

讨論如何保持資料庫的清晰和健壯，如何把有害資料降低到最小程度。

第 5 部分 - 各種小技巧

不包括在以上 4 個部分中的其他技巧，五花八門，有了它們希望你的資料庫開發工作會更輕松一些。

第 1 部分 - 設計資料庫之前

1. 考察現有環境

在設計一個新資料庫時，你不但應該仔細研究業務需求而且還要考察現有的系統。大多數資料庫項目都不是從頭開始建立的；通常，機構内總會存在用來滿足特定需求的現有系統（可能沒有實作自動計算）。顯然，現有系統并不完美，否則你就不必再建立新系統了。但是對舊系統的研究可以讓你發現一些可能會忽略的細微問題。一般來說，考察現有系統對你絕對有好處。

2. 定義标準的對象命名規範

一定要定義資料庫對象的命名規範。對資料庫表來說，從項目一開始就要确定表名是采用複數還是單數形式。此外還要給表的别名定義簡單規則（比方說，如果表名是一個單詞，别名就取單詞的前 4 個字母；如果表名是兩個單詞，就各取兩個單詞的前兩個字母組成 4 個字母長的别名；如果表的名字由 3 個單詞組成，你不妨從頭兩個單詞中各取一個然後從最後一個單詞中再取出兩個字母，結果還是組成 4 字母長的别名，其餘依次類推）對工作用表來說，表名可以加上字首 WORK_ 後面附上采用該表的應用程式的名字。表内的列[字段]要針對鍵采用一整套設計規則。比如，如果鍵是數字類型，你可以用 _N 作為字尾；如果是字元類型則可以采用 _C 字尾。對列[字段]名應該采用标準的字首和字尾。再如，假如你的表裡有好多“money”字段，你不妨給每個列[字段]增加一個 _M 字尾。還有，日期列[字段]最好以 D_ 作為名字打頭。

檢查表名、報表名和查詢名之間的命名規範。你可能會很快就被這些不同的資料庫要素的名稱搞糊塗了。假如你堅持統一地命名這些資料庫的不同組成部分，至少你應該在這些對象名字的開頭用 Table、Query 或者 Report 等字首加以差別。

如果采用了 Microsoft Access，你可以用 qry、rpt、tbl 和 mod 等符号來辨別對象（比如 tbl_Employees）。我在和 SQL Server 打交道的時候還用過 tbl 來索引表，但我用 sp_company （現在用 sp_feft_）辨別存儲過程，因為在有的時候如果我發現了更好的處理辦法往往會儲存好幾個拷貝。我在實作 SQL Server 2000 時用 udf_ （或者類似的标記）辨別我編寫的函數。

3. 工欲利其器

采用理想的資料庫設計工具，比如：SyBase 公司的 PowerDesign，她支援 PB、VB、Delphe 等語言，通過 ODBC 可以連接配接市面上流行的 30 多個資料庫，包括 dBase、FoxPro、VFP、SQL Server 等，今後有機會我将着重介紹 PowerDesign 的使用。

4. 擷取資料模式資源手冊

正在尋求示例模式的人可以閱讀《資料模式資源手冊》一書，該書由 Len Silverston、W. H. Inmon 和 Kent Graziano 編寫，是一本值得擁有的最佳資料模組化圖書。該書包括的章節涵蓋多種資料領域，比如人員、機構和工作效能等。其他的你還可以參考：[1]薩師煊　王珊著　資料庫系統概論(第二版)高等教育出版社 1991、[2][美] Steven M.Bobrowski 著 Oracle 7 與客戶／伺服器計算技術從入門到精通　劉建元等譯　電子工業出版社，1996、[3]周中元　資訊系統模組化方法(下)　電子與資訊化　1999年第3期，1999

5. 暢想未來，但不可忘了過去的教訓

我發現詢問使用者如何看待未來需求變化非常有用。這樣做可以達到兩個目的：首先，你可以清楚地了解應用設計在哪個地方應該更具靈活性以及如何避免性能瓶頸；其次，你知道發生事先沒有确定的需求變更時使用者将和你一樣感到吃驚。

一定要記住過去的經驗教訓！我們開發人員還應該通過分享自己的體會和經驗互相幫助。即使使用者認為他們再也不需要什麼支援了，我們也應該對他們進行這方面的教育，我們都曾經面臨過這樣的時刻“當初要是這麼做了該多好..”。

6. 在實體實踐之前進行邏輯設計

在深入實體設計之前要先進行邏輯設計。随着大量的 CASE 工具不斷湧現出來，你的設計也可以達到相當高的邏輯水準，你通常可以從整體上更好地了解資料庫設計所需要的方方面面。

7. 了解你的業務

在你百分百地确定系統從客戶角度滿足其需求之前不要在你的 ER（實體關系）模式中加入哪怕一個資料表（怎麼，你還沒有模式？那請你參看技巧 9）。了解你的企業業務可以在以後的開發階段節約大量的時間。一旦你明确了業務需求，你就可以自己做出許多決策了。

一旦你認為你已經明确了業務内容，你最好同客戶進行一次系統的交流。采用客戶的術語并且向他們解釋你所想到的和你所聽到的。同時還應該用可能、将會和必須等詞彙表達出系統的關系基數。這樣你就可以讓你的客戶糾正你自己的了解然後做好下一步的 ER 設計。

8. 建立資料字典和 ER 圖表

一定要花點時間建立 ER 圖表和資料字典。其中至少應該包含每個字段的資料類型和在每個表内的主外鍵。建立 ER 圖表和資料字典确實有點費時但對其他開發人員要了解整個設計卻是完全必要的。越早建立越能有助于避免今後面臨的可能混亂，進而可以讓任何了解資料庫的人都明确如何從資料庫中獲得資料。

有一份諸如 ER 圖表等最新文檔其重要性如何強調都不過分，這對表明表之間關系很有用，而資料字典則說明了每個字段的用途以及任何可能存在的别名。對 SQL 表達式的文檔化來說這是完全必要的。

9. 建立模式

一張圖表勝過千言萬語：開發人員不僅要閱讀和實作它，而且還要用它來幫助自己和使用者對話。模式有助于提高協作效能，這樣在先期的資料庫設計中幾乎不可能出現大的問題。模式不必弄的很複雜；甚至可以簡單到手寫在一張紙上就可以了。隻是要保證其上的邏輯關系今後能産生效益。

10. 從輸入輸出下手

在定義資料庫表和字段需求（輸入）時，首先應檢查現有的或者已經設計出的報表、查詢和視圖（輸出）以決定為了支援這些輸出哪些是必要的表和字段。舉個簡單的例子：假如客戶需要一個報表按照郵政編碼排序、分段和求和，你要保證其中包括了單獨的郵政編碼字段而不要把郵政編碼糅進位址字段裡。

11. 報表技巧

要了解使用者通常是如何報告資料的：批處理還是線上送出報表？時間間隔是每天、每周、每月、每個季度還是每年？如果需要的話還可以考慮建立總結表。系統生成的主鍵在報表中很難管理。使用者在具有系統生成主鍵的表内用副鍵進行檢索往往會傳回許多重複資料。這樣的檢索性能比較低而且容易引起混亂。

12. 了解客戶需求

看起來這應該是顯而易見的事，但需求就是來自客戶（這裡要從内部和外部客戶的角度考慮）。不要依賴使用者寫下來的需求，真正的需求在客戶的腦袋裡。你要讓客戶解釋其需求，而且随着開發的繼續，還要經常詢問客戶保證其需求仍然在開發的目的之中。一個不變的真理是：“隻有我看見了我才知道我想要的是什麼”必然會導緻大量的返工，因為資料庫沒有達到客戶從來沒有寫下來的需求标準。而更糟的是你對他們需求的解釋隻屬于你自己，而且可能是完全錯誤的。