獲取數(shù)據(jù)模式資源手冊

　　正在尋求示例模式的人可以閱讀《數(shù)據(jù)模式資源手冊》一書，該書由 Len Silverston、W. H. Inmon 和 Kent Graziano 編寫，是一本值得擁有的最佳數(shù)據(jù)建模圖書。該書包括的章節(jié)涵蓋多種數(shù)據(jù)領域，比如人員、機構和工作效能等。其他的你還可以參考相關書籍。

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

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

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

　　在物理實踐之前進行邏輯設計

　　在深入物理設計之前要先進行邏輯設計。隨著大量的 CASE 工具不斷涌現(xiàn)出來，你的設計也可以達到相當高的邏輯水準，你通�？梢詮恼�體上更好地了解數(shù)據(jù)庫設計所需要的方方面面。

　　了解你的業(yè)務

　　在你百分百地確定系統(tǒng)從客戶角度滿足其需求之前不要在你的 ER(實體關系)模式中加入哪怕一個數(shù)據(jù)表(怎么，你還沒有模式?那請你參看技巧 9)。了解你的企業(yè)業(yè)務可以在以后的開發(fā)階段節(jié)約大量的時間。一旦你明確了業(yè)務需求，你就可以自己做出許多決策了。

　　一旦你認為你已經(jīng)明確了業(yè)務內(nèi)容，你最好同客戶進行一次系統(tǒng)的交流。采用客戶的術語并且向他們解釋你所想到的和你所聽到的。同時還應該用可能、將會和必須等詞匯表達出系統(tǒng)的關系基數(shù)。這樣你就可以讓你的客戶糾正你自己的理解然后做好下一步的 ER 設計。

　　創(chuàng)建數(shù)據(jù)字典和 ER 圖表

　　一定要花點時間創(chuàng)建 ER 圖表和數(shù)據(jù)字典。其中至少應該包含每個字段的數(shù)據(jù)類型和在每個表內(nèi)的主外鍵。創(chuàng)建 ER 圖表和數(shù)據(jù)字典確實有點費時但對其他開發(fā)人員要了解整個設計卻是完全必要的。越早創(chuàng)建越能有助于避免今后面臨的可能混亂，從而可以讓任何了解數(shù)據(jù)庫的人都明確如何從數(shù)據(jù)庫中獲得數(shù)據(jù)。

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

　　創(chuàng)建模式

　　一張圖表勝過千言萬語：開發(fā)人員不僅要閱讀和實現(xiàn)它，而且還要用它來幫助自己和用戶對話。模式有助于提高協(xié)作效能，這樣在先期的數(shù)據(jù)庫設計中幾乎不可能出現(xiàn)大的問題。模式不必弄的很復雜;甚至可以簡單到手寫在一張紙上就可以了。只是要保證其上的邏輯關系今后能產(chǎn)生效益。

　　從輸入輸出下手

　　在定義數(shù)據(jù)庫表和字段需求(輸入)時，首先應檢查現(xiàn)有的或者已經(jīng)設計出的報表、查詢和視圖(輸出)以決定為了支持這些輸出哪些是必要的表和字段。舉個簡單的例子：假如客戶需要一個報表按照郵政編碼排序、分段和求和，你要保證其中包括了單獨的郵政編碼字段而不要把郵政編碼糅進地址字段里。

　　報表技巧

　　要了解用戶通常是如何報告數(shù)據(jù)的：批處理還是在線提交報表?時間間隔是每天、每周、每月、每個季度還是每年?如果需要的話還可以考慮創(chuàng)建總結表。系統(tǒng)生成的主鍵在報表中很難管理。用戶在具有系統(tǒng)生成主鍵的表內(nèi)用副鍵進行檢索往往會返回許多重復數(shù)據(jù)。這樣的檢索性能比較低而且容易引起混亂。

　　理解客戶需求

　　看起來這應該是顯而易見的事，但需求就是來自客戶(這里要從內(nèi)部和外部客戶的角度考慮)。不要依賴用戶寫下來的需求，真正的需求在客戶的腦袋里。你要讓客戶解釋其需求，而且隨著開發(fā)的繼續(xù)，還要經(jīng)常詢問客戶保證其需求仍然在開發(fā)的目的之中。一個不變的真理是：“只有我看見了我才知道我想要的是什么”必然會導致大量的返工，因為數(shù)據(jù)庫沒有達到客戶從來沒有寫下來的需求標準。而更糟的是你對他們需求的解釋只屬于你自己，而且可能是完全錯誤的。