如果將數據庫設計比作是福爾摩斯破案，根據各種條件，限制，規則，抽絲撥繭，尋找其中的相互聯系，一步一步深入案件的中間，最終解決案件。但破案首先需要有方法，那麼對於數據庫設計目前以使用已久的一系列設計數據庫結構的成熟方法（比如：規范化）都可以作為破案所需方法的良好的根基。實際上，這些方法幾乎都是經典的設計方法，因此，在進行數據庫設計的時候，遵循這些方法並不會感覺到太困難。正如同我們所知，我們可以直接將你按方法的設計可以直接轉變成SQL Server表。
但是，除非你只是為了抓一個現顯的小偷，否則需要各種條件，規則，限制，聯系都必須考慮到。如同我們在需要統一的考慮數據庫解決方案中的分布、冗余、集群、24/7支持、存取過程、觸發器、約束和完整性等問題的時候，就需要引入數據庫結構的技術。這種技術沒有提供物理地實現數據庫的方法，但可以通過它來選擇一種最佳的方法。
在現代按照不同的設計可以將整個數據庫系統按不同服務需求分解成不同的組成部分，而不是使用一種技術完成整個的任務。它們可以分為：
● OLTP（聯機事務處理）－－OLTP數據庫存儲當前業務運作所需要得數據，它的主要目的是使當前的公共數據完整合理，要達到這個目的需要遵循兩條原則：1、每一個當前數據塊只能存儲在一個可供編輯的位置，此處的如何改動都會反映倒所有使用這一數據的地方。2、提供事務支持，以便對數據庫進行多項更改一起生效。如果事務中的一個更改失敗了，其他的所有更改也都不允許生效，事務中止，所有操作回滾。
● 業務數據存儲（Operational Data Store，ODS）――用於日報表的匯總數據。這些數據經常取之幾個完全不同的地方，並進行了一定程度的預匯總，以便節省查詢的時間。它的目的是向用戶提供操作數據並跟蹤近期的趨勢，以便做出決策。
● 數據倉庫（Data Warehouse）――保存整個公司的重要數據和歷史數據，它的目的一是利用公司現存歷史信息做出決策；二是從數據庫系統的角度將活動的事務處理從報告中分力出來，以便更加細致地進行查詢，而不會影響用戶在OLTP系統中創建和存儲的數據的能力。
● 數據集市（Data Mart）――為匯總而優先的專用數據存儲，用於特定的場合，其存儲的內容作為數據倉庫的子集。數據集市通常使用被成為OLAP的技術進行處理。它通常為一個公司的特定需求，或一個機構的特定業務而建立的，一般有兩種特殊的數據庫結構：星型模式和雪花模式。
對於以上四種類型，最終采用的數據庫總體結構完全取決於該數據庫將要解決的問題規模。
現在的大部分計算機系統中，數據庫是核心。即使不是一個以數據庫為核心的系統，也擁有一個數據存儲的需要。軟件歸根結底，也是對數據的處理。
在Internet中，在銀行、政府機關、公司、學校、超市、藥店等地方，都有許多數據庫實例。這類數據庫設計的過程一般可以分解成下面幾個步驟：
● 定義目標――不要由於覺得顯而易見而一笑置之,這個很重要，因為很多項目都是由於開發者不清楚用戶實際上要做什麼或需要什麼，而冒然斷定或沒有能夠很好地聽取用戶的正確意見或全部意見而帶來的麻煩。在這個階段，我們要為最終創建的系統定義功能、性能、面向客戶群，並寫需求報告。
● 邏輯設計――為了達到最終的目標而，通過對用戶業務的分析，實施的邏輯設計
● 物理設計――利用邏輯設計的成果，並將其轉換成一個真正的實現。這個階段涉及到數據庫系統如何物理地實現以及我們需要使用那些硬件和軟件。
● 物理實現――項目的實現階段涉及實際的物理數據、數據庫服務器的制定以及編寫存取數據的代碼。
● 復查――評定是否達到最終目標的過程。大多數的項目都忽視了這個階段，原因是耗時太長，並且引發不起人們的一點興趣：測試、編寫文檔以及完成一些不願意做，但又必須做的事情。這個階段，應該有一個利用用戶反饋信息的方法和維護更改所有問題的計劃。
在用戶使用過程中，用戶實際只要能夠浏覽和處理他們所需的數據，就很少對原始數據或者用來存取數據的實際接口感興趣。項目設計分析人員，可能因為這樣那樣原因，往往使一些系統使用起來非常笨拙，考慮欠佳的原因。
下面幾點是我從學校、從同事、從書籍，從實際設計中得到的一些概念設計經驗之談：
1、定義目標階段：信息采集，收集數據庫項目中的信息。
a、在這裡應該盡量避免一開始就設計結構。即使你具有數據庫設計的經驗，也不要在這裡定義表和字段等等，你應該對它們逐步地進行處理。在聽取用戶講解其想法和需求，並歸納出該項目應該應該完成的任務之前，不要深入到某一個具體的部分。我們常常在對所完成的任務沒有足夠了解之前，就對它實施一種結構和一種解決方案，這樣即不利於客戶也不利於我們。
b、在分析過程中，盡快地將所需的數據編寫成文檔是一個很好的習慣。例如：在公司，因為一個員工生病或者另謀高就，為了不對開發速度造成很大的影響，接替人員需全力以赴地了解項目的全部內容，能夠為其提供幫助的唯一途徑就是全部的信息文檔。因此你了解編寫文檔重要性，要求是不把任何項目內容留在你的腦袋中。在對用戶需求進行記錄時應注意：
△ 維護一套共享的系統設計和說明書文檔。文檔應該主要包含：設計會議記錄，記錄口頭更改需求的文檔和最終的所有說明書，比如，功能、技術、測試等各方面的內容。
△ 除了規范的文檔外，要為所有的信息而開發和維護一個公共資料庫。
△ 花一些時間召開會議，在客戶講述時，盡量不要發表你個人的意見。讓客戶暢所欲言，注意傾聽客戶的每一個建議、請求或想法。
△ 注意那些你添加的而沒有得到用戶許可的信息。
△ 應早確立項目使用的范圍，並始終牢記在心。這樣做可以避免日後開發的項目過大或遺漏了有用的東西。編寫項目操作范圍的說明書（任務說明或任務對象），用以來描述項目的參數。該說明書應該在項目的設計、實現過程中不斷地進行協商、對比、完善，直到最後完成為止。若項目的對象和最終目標在這個階段不予確認，或者沒有記載任何內容，當你和客戶的想法出現不一致時，就很可能與用戶發生沖突。因此，要確保客戶對你將要實現的系統十分清楚，並使用清晰易懂的語言進行描敘，盡可能詳細描述項目所有內容。
c、在整個數據庫設計期間，客戶通常會對字段名、字段定義、業務規則、用戶界面和顏色做一些修改，為此，你要做好思想准備。無論客戶有什麼要求，都應該給予支持，這個項目最終要由用戶控制使用，所以你必須要使系統能夠靈活地適用各種用途的變化，不管是次要的還是主要的，但對於這些客戶的想法都要在客戶在設計階段對你做出的決策確認簽字的基礎上。
因為在任何時候，客戶都有可能對你說，“怎麼這裡少了一項”、“我根本沒這樣說”等等。如果你在說話時，手中沒有文檔為自己撐腰，就會帶來很多麻煩。因此，保存文檔，如果你做出的決策與客戶所說的不同，就應該利用文檔來證明自己決策的正確性。
d、數據庫原型作為公司與客戶簽定合約時相互交流信息所使用的畫面。每次協商都要借助於開發的原型，它可以很好的反映開發商最終開發的產品。數據庫設計者可以利用其為工作模型，設計文檔所使用，避免用戶所需信息的缺失。
e、與客戶商談時應注意，不要搶先發言；威脅客戶；以及在他們向你講述他們想要做的事情之前大談你的看法，而不顧用戶的期望都有可能造成項目的失敗。與客戶進行友善地商談是我們獲得設計信息得堅實基礎。如果基礎不牢靠，最終的產品也不會成功。在向客戶提出：
1、誰使用這些數據？
2、如何使用這些數據？
3、客戶需要那些報表？
4、以前數據處理辦法？
5、由那些規則控制數據的使用？
這幾個問題都很有必要了解清楚。
2、邏輯設計階段
a、我認為在邏輯設計階段，應禁止談論性能問題，應該瞄准概念模型。作為一般建議，設計者最好嘗試規范化盡量高的級別。如果在系統測試中，發現了性能問題，則可以反向規范化這個系統。但我們永遠不要為了調整應用程序的性能而放棄規范化的結構。所以，提倡等到物理模型化階段或至少迫不得已的理由再反向規范化。
b、在邏輯設計結束，下一步開始時，建議考慮一下以下問題：
1、數據的用法
報表的處理；數據的使用和所有權；與外部系統的接口；數據轉換計劃
2、容量的測定
表和數據庫的增長
3、項目計劃
4、最後的文檔復審
通讀所有文檔，並對其修改和校准。使客戶在合同上簽字。
c、作為設計者，你還應對客戶在未來可能產生的需求進行必要預測和文檔編寫。這樣可以在客戶未來的業務到來時，可以獲得更多的操作時間。
結束語
當然，隨著數據庫技術的發展，各種技術，新方法都會不斷的出現。這都需要我們在紛繁錯雜中去探尋，去發掘。
參考文獻
1 Louis Davidson編著，《SQL Server 2000數據庫設計權威指南》 中國電力出版 2003
2 George Reese,Randy Jay Yarger,Tim King Gugb E. Williams著 《MySQL權威指南》：中國電力出版社 2003
