如果把企業(yè)的數(shù)據(jù)比做生命所必需的血液，那么數(shù)據(jù)庫的設(shè)計就是應(yīng)用中最重要的一部分。有關(guān)數(shù)據(jù)庫設(shè)計的材料汗牛充棟，大學(xué)學(xué)位課程里也有專門的講述。不過，就如我們反復(fù)強調(diào)的那樣，再好的老師也比不過經(jīng)驗的教誨。所以我最近找了些對數(shù)據(jù)庫設(shè)計頗有造詣的專業(yè)人士給大家傳授一些設(shè)計數(shù)據(jù)庫的技巧和經(jīng)驗。我從收到的130 個反饋中精選了其中的60 個最佳技巧，并把這些技巧編寫成了本文，為了方便索引其內(nèi)容劃分為5 個部分：
第1 部分— 設(shè)計數(shù)據(jù)庫之前
1. 考察現(xiàn)有環(huán)境
在設(shè)計一個新數(shù)據(jù)庫時，你不但應(yīng)該仔細研究業(yè)務(wù)需求而且還要考察現(xiàn)有的系統(tǒng)。大多數(shù)數(shù)據(jù)庫項目都不是從頭開始建立的；通常，機構(gòu)內(nèi)總會存在用來滿足特定需求的現(xiàn)有系統(tǒng)（可能沒有實現(xiàn)自動計算）。顯然，現(xiàn)有系統(tǒng)并不完美，否則你就不必再建立新系統(tǒng)了。但是對舊系統(tǒng)的研究可以讓你發(fā)現(xiàn)一些可能會忽略的細微問題。一般來說，考察現(xiàn)有系統(tǒng)對你絕對有好處。
我曾經(jīng)接手過一個為地區(qū)運輸公司開發(fā)的數(shù)據(jù)庫項目，活不難，用的是Access 數(shù)據(jù)庫。我設(shè)置了一些項目設(shè)計參數(shù)，而且同客戶一道對這些參數(shù)進行了評估，事先還查看了開發(fā)環(huán)境下所采取的工作模式，等到最后部署應(yīng)用的時候，只見終端上出了幾個提示符然后立馬在我面前翹辮子了！抓耳撓腮的折騰了好幾個小時，我才意識到，原來這家公司的網(wǎng)絡(luò)上跑著兩個數(shù)據(jù)庫應(yīng)用，而對網(wǎng)絡(luò)的訪問需要明確和嚴格的用戶賬號及其訪問權(quán)限。明白了這一點，問題迎刃而解：只需采用客戶的系統(tǒng)即可。這個項目給我的教訓(xùn)就是：記住，假如你在諸如Access 或者Interbase 這類公共環(huán)境下開發(fā)應(yīng)用程序，一定要從表面下手深入系統(tǒng)內(nèi)部搞清楚你面臨的環(huán)境到底是怎么回事。
2. 定義標準的對象命名規(guī)范
一定要定義數(shù)據(jù)庫對象的命名規(guī)范。對數(shù)據(jù)庫表來說，從項目一開始就要確定表名是采用復(fù)數(shù)還是單數(shù)形式。此外還要給表的別名定義簡單規(guī)則（比方說，如果表名是一個單詞，別名就取單詞的前4 個字母；如果表名是兩個單詞，就各取兩個單詞的前兩個字母組成4 個字母長的別名；如果表的名字由3 個單詞組成，你不妨從頭兩個單詞中各取一個然后從最后一個單詞中再取出兩個字母，結(jié)果還是組成4 字母長的別名，其余依次類推）對工作用表來說，表名可以加上前綴WORK_ 后面附上采用該表的應(yīng)用程序的名字。表內(nèi)的列要針對鍵采用一整套設(shè)計規(guī)則。比如，如果鍵是數(shù)字類型，你可以用_NO 作為后綴；如果是字符類型則可以采用_CODE 后綴。對列名應(yīng)該采用標準的前綴和后綴。再如，假如你的表里有好多“money”字段，你不妨給每個列增加一個_AMT 后綴。還有，日期列最好以DATE_作為名字打頭。
檢查表名、報表名和查詢名之間的命名規(guī)范。你可能會很快就被這些不同的數(shù)據(jù)庫要素的名稱搞糊涂了。假如你堅持統(tǒng)一地命名這些數(shù)據(jù)庫的不同組成部分，至少你應(yīng)該在這些對象名字的開頭用table、query 或者report 等前綴加以區(qū)別。
如果采用了Microsoft Access，你可以用qry、rpt、tbl 和mod 等符號來標識對象（比如
tbl_Employees）。我在和SQL Server（或者Oracle）打交道的時候還用過tbl 來索引表，但我用sp_company （現(xiàn)在用sp_feft_）標識存儲過程，因為在有的時候如果我發(fā)現(xiàn)了更好的處理辦法往往會保存好幾個拷貝。我在實現(xiàn)SQL Server 2000 時用udf_ （或者類似的標記）標識我編寫的函數(shù)。
3. 預(yù)先計劃
上個世紀80 年代初，我還在使用資產(chǎn)帳目系統(tǒng)和System 38 平臺，那時我負責設(shè)計所有的日期字段，這樣在不費什么力氣的情況下將來就可以輕松處理2000 年問題了。許多人給我說就別去解決這一問題了，因為要處理起來太麻煩了（這在世人皆知的Y2K 問題之前很久了）。我回擊說只要預(yù)先計劃今后就不會遇到大麻煩。結(jié)果我只用了兩周的時間就把程序全部改完了。因為預(yù)先計劃的好，后來Y2K 問題對該系統(tǒng)的危害降到了最低程度（最近聽說該程序甚至到了1995 年都還運行在AS/400 系統(tǒng)上，唯一出現(xiàn)的小問題是從代碼中刪除注釋費了點工夫）。
4. 獲取數(shù)據(jù)模式資源手冊
正在尋求示例模式的人可以閱讀《數(shù)據(jù)模式資源手冊》一書，該書由Len Silverston、W. H.Inmon 和Kent Graziano 編寫，是一本值得擁有的最佳數(shù)據(jù)建模圖書。該書包括的章節(jié)涵蓋多種數(shù)據(jù)領(lǐng)域，比如人員、機構(gòu)和工作效能等。
5. 暢想未來，但不可忘了過去的教訓(xùn)
我發(fā)現(xiàn)詢問用戶如何看待未來需求變化非常有用。這樣做可以達到兩個目的：首先，你可以清楚地了解應(yīng)用設(shè)計在哪個地方應(yīng)該更具靈活性以及如何避免性能瓶頸；其次，你知道發(fā)生事先沒有確定的需求變更時用戶將和你一樣感到吃驚。
一定要記住過去的經(jīng)驗教訓(xùn)！我們開發(fā)人員還應(yīng)該通過分享自己的體會和經(jīng)驗互相幫助。即使用戶認為他們再也不需要什么支持了，我們也應(yīng)該對他們進行這方面的教育，我們都曾經(jīng)面臨過這樣的時刻“當初要是這么做了該多好;”。
6. 在物理實踐之前進行邏輯設(shè)計
在深入物理設(shè)計之前要先進行邏輯設(shè)計。隨著大量的CASE 工具不斷涌現(xiàn)出來，你的設(shè)計也可以達到相當高的邏輯水準，你通?？梢詮恼w上更好地了解數(shù)據(jù)庫設(shè)計所需要的方方面面。
7. 了解你的業(yè)務(wù)
在你百分百地確定系統(tǒng)從客戶角度滿足其需求之前不要在你的ER（實體關(guān)系）模式中加入哪怕一個數(shù)據(jù)表（怎么，你還沒有模式？那請你參看技巧9）。了解你的企業(yè)業(yè)務(wù)可以在以后的開發(fā)階段節(jié)約大量的時間。一旦你明確了業(yè)務(wù)需求，你就可以自己做出許多決策了。
一旦你認為你已經(jīng)明確了業(yè)務(wù)內(nèi)容，你最好同客戶進行一次系統(tǒng)的交流。采用客戶的術(shù)語并且向他們解釋你所想到的和你所聽到的。同時還應(yīng)該用可能、將會和必須等詞匯表達出系統(tǒng)的關(guān)系基數(shù)。這樣你就可以讓你的客戶糾正你自己的理解然后做好下一步的ER 設(shè)計。
8. 創(chuàng)建數(shù)據(jù)字典和ER 圖表
一定要花點時間創(chuàng)建ER 圖表和數(shù)據(jù)字典。其中至少應(yīng)該包含每個字段的數(shù)據(jù)類型和在每個表內(nèi)的主外鍵。創(chuàng)建ER 圖表和數(shù)據(jù)字典確實有點費時但對其他開發(fā)人員要了解整個設(shè)計卻是完全必要的。越早創(chuàng)建越能有助于避免今后面臨的可能混亂，從而可以讓任何了解數(shù)據(jù)庫的人都明確如何從數(shù)據(jù)庫中獲得數(shù)據(jù)。
有一份諸如ER 圖表等最新文檔其重要性如何強調(diào)都不過分，這對表明表之間關(guān)系很有用，而數(shù)據(jù)字典則說明了每個字段的用途以及任何可能存在的別名。對SQL 表達式的文檔化來說這是完全必要的。
9. 創(chuàng)建模式
一張圖表勝過千言萬語：開發(fā)人員不僅要閱讀和實現(xiàn)它，而且還要用它來幫助自己和用戶對話。模式有助于提高協(xié)作效能，這樣在先期的數(shù)據(jù)庫設(shè)計中幾乎不可能出現(xiàn)大的問題。模式不必弄的很復(fù)雜；甚至可以簡單到手寫在一張紙上就可以了。只是要保證其上的邏輯關(guān)系今后能產(chǎn)生效益。
10. 從輸入輸出下手
在定義數(shù)據(jù)庫表和字段需求（輸入）時，首先應(yīng)檢查現(xiàn)有的或者已經(jīng)設(shè)計出的報表、查詢和視圖（輸出）以決定為了支持這些輸出哪些是必要的表和字段。舉個簡單的例子：假如客戶需要一個報表按照郵政編碼排序、分段和求和，你要保證其中包括了單獨的郵政編碼字段而不要把郵政編碼糅進地址字段里。
11. 報表技巧
要了解用戶通常是如何報告數(shù)據(jù)的：批處理還是在線提交報表？時間間隔是每天、每周、每月、每個季度還是每年？如果需要的話還可以考慮創(chuàng)建總結(jié)表。系統(tǒng)生成的主鍵在報表中很難管理。用戶在具有系統(tǒng)生成主鍵的表內(nèi)用副鍵進行檢索往往會返回許多重復(fù)數(shù)據(jù)。這樣的檢索性能比較低而且容易引起混亂。
12. 理解客戶需求
看起來這應(yīng)該是顯而易見的事，但需求就是來自客戶（這里要從內(nèi)部和外部客戶的角度考慮）。不要依賴用戶寫下來的需求，真正的需求在客戶的腦袋里。你要讓客戶解釋其需求，而且隨著開發(fā)的繼續(xù)，還要經(jīng)常詢問客戶保證其需求仍然在開發(fā)的目的之中。一個不變的真理是：“只有我看見了我才知道我想要的是什么”必然會導(dǎo)致大量的返工，因為數(shù)據(jù)庫沒有達到客戶從來沒有寫下來的需求標準。而更糟的是你對他們需求的解釋只屬于你自己，而且可能是完全錯誤的。
本站僅提供存儲服務(wù)，所有內(nèi)容均由用戶發(fā)布，如發(fā)現(xiàn)有害或侵權(quán)內(nèi)容，請
點擊舉報。
