這里我們思考兩個問題：
修建茅屋需要設計嗎？修建大廈需要設計嗎？
結論是：當數據庫比較復雜（如數據量大，表較多，業務關系復雜）時，我們需要先設計數據庫；
因為，良好的數據庫設計能夠：
q 節省數據的存儲空間
q 能夠保證數據的完整性
q 方便進行數據庫應用系統的開發
糟糕的數據庫設計：
q 數據冗余、存儲空間浪費
q 內存空間浪費
q 數據更新和插入的異常
軟件項目開發周期
我們再來看看軟件項目的開發周期：
• 需求分析階段：分析客戶的業務和數據處理需求;
• 概要設計階段：設計數據庫的E-R模型圖，確認需求信息的正確和完整;
• 詳細設計階段：將E-R圖轉換為多張表，進行邏輯設計，並應用數據庫設計的三大范式進行審核;
• 代碼編寫階段：選擇具體數據庫進行物理實現，並編寫代碼實現前端應用;
• 軟件測試階段：……
• 安裝部署：……
設計數據庫
• 在需求分析階段，設計數據庫的一般步驟為：
– 收集信息
– 標識對象
– 標識每個對象的屬性
– 標識對象之間的關系
• 在概要設計階段和詳細設計階段，設計數據庫的步驟為：
– 繪制E-R圖
– 將E-R圖轉換為表格
– 應用三大范式規范化表格
下面我們以一個BBS簡易論壇的數據庫設計為例來看看設計數據庫的步驟：
• 收集信息：
與該系統有關人員進行交流、坐談，充分理解數據庫需要完成的任務
BBS論壇的基本功能：
l 用戶注冊和登錄，后台數據庫需要存放用戶的注冊信息和在線狀態信息；
l 用戶發貼，后台數據庫需要存放貼子相關信息，如貼子內容、標題等；
l 論壇版塊管理：后台數據庫需要存放各個版塊信息，如版主、版塊名稱、貼子數等；
• 標識對象（實體－Entity）
標識數據庫要管理的關鍵對象或實體
實體一般是名詞：
l 用戶：論壇普通用戶、各版塊的版主。
l 用戶發的主貼
l 用戶發的跟貼（回貼）
l 版塊：論壇的各個版塊信息
• 標識每個實體的屬性（Attribute）
• 標識對象之間的關系（Relationship）
l 跟貼和主貼有主從關系：我們需要在跟貼對象中表明它是誰的跟貼；
l 版塊和用戶有關系：從用戶對象中可以根據版塊對象查出對應的版主用戶的情況；
l 主貼和版塊有主從關系：需要表明發貼是屬於哪個版塊的；
l 跟貼和版塊有主從關系：需要表明跟貼是屬於哪個版塊的；
• 繪制E-R圖
• 將E-R圖轉化為表格
• 將各實體轉換為對應的表，將各屬性轉換為各表對應的列
• 標識每個表的主鍵列，需要注意的是：沒有主鍵的表添加ID編號列，它沒有實際含義，用於做主鍵或外鍵，例如用戶表中的“UID”列，版塊表中添加“SID”列，發貼表和跟貼表中的“TID”列
• 在表之間建立主外鍵，體現實體之間的映射關系
這里我們繪制ER圖可以使用微軟的Word或VISIO以及Sybase公司的PowerDesigner，它主要用於和客戶溝通交流意見，並反復修改，直到客戶確認。客戶確認后，再將E-R圖轉換為表。上面我們已經做好了這個工作。那接下來就是最后一步：應用三大范式對設計的多張表進行審核並規范化表的結構。
數據規范化
• 僅有好的RDBMS並不足以避免數據冗余，必須在數據庫的設計中創建好的表結構。表設計后，很可能結構不合理，出現數據重復保存，簡稱數據的冗余，這對數據的增刪改查帶來很多后患，所以我們需要審核是否合理，就像施工圖設計后，還需要其他機構進行審核圖紙是否設計合理一樣。
• 如何審核呢？需要一些有關數據庫設計的理論指導規則，這些規則業界簡稱數據庫的范式。Dr E.F.codd 最初定義了規范化的三個級別，范式是具有最小冗余的表結構。這些范式是：
– 第一范式(1st NF －First Normal Fromate)
– 第二范式(2nd NF－Second Normal Fromate)
– 第三范式(3rd NF－ Third Normal Fromate)
• 如果每列都是不可再分的最小數據單元（也稱為最小的原子單元），則滿足第一范式（1NF）。第一范式的目標是確保每列的原子性。
• 如果一個關系滿足1NF，並且除了主鍵以外的其他列，都依賴於該主鍵，則滿足第二范式（2NF）。第二范式要求每個表只描述一件事情，確保表中的每列，都和主鍵相關。
• 如果一個關系滿足2NF，並且除了主鍵以外的其他列都不傳遞依賴於主鍵列，則滿足第三范式（3NF）。第三范式確保每列都和主鍵列直接相關，而不是間接相關。
下面我們來看個形象的例子吧！假設某建築公司要設計一個數據庫。公司的業務規則概括說明如下：
• 公司承擔多個工程項目，每一項工程有：工程號、工程名稱、施工人員等
• 公司有多名職工，每一名職工有：職工號、姓名、性別、職務（工程師、技術員）等
• 公司按照工時和小時工資率支付工資，小時工資率由職工的職務決定（例如，技術員的小時工資率與工程師不同）
• 公司定期制定一個工資報表，如圖-1所示
圖-1 某公司打印的工資報表
圖-2 某公司的項目工時表
大家都看到，上面這樣設計的表會有很多問題：
1.表中包含大量的冗余，可能會導致數據異常：
• 更新異常
例如，修改職工號=1001的職務，則必須修改所有職工號=1001的行
• 添加異常
若要增加一個新的職工時，首先必須給這名職工分配一個工程。或者為了添加一名新職工的數據，先給這名職工分配一個虛擬的工程。（因為主關鍵字不能為空）
• 刪除異常
例如，1001號職工要辭職，則必須刪除所有職工號＝1001的數據行。這樣的刪除操作，很可能丟失了其它有用的數據
2．采用這種方法設計表的結構，雖然很容易產生工資報表，但是每當一名職工分配一個工程時，都要重復輸入大量的數據。這種重復的輸入操作，很可能導致數據的不一致性。
我們用第二范式規范一下：
我們再用第三范式規范一下，是不是明晰了很多？！
規范化和性能的關系
• 為滿足某種商業目標，數據庫性能比規范化數據庫更重要
– 通過在給定的表中添加額外的字段，以大量減少需要從中搜索信息所需的時間
– 通過在給定的表中插入計算列（如成績總分），以方便查詢
• 進行規范化的同時，還需要綜合考慮數據庫的性能。數據庫的三大范式和數據庫的性能有時是矛盾的。
打個比方：大家都知道，環境保護非常重要，西方總是拿環保問題和中國刁難，說中國為了發展不顧環境保護、生態自然等。可中國目前的經濟實力不夠強大，如果人都吃不飽，空談環保還有什么用呢？所以我們只能是在保持地區經濟發展的前提下，盡量注重環保問題。這就是一種折中處理問題的典型。本例同樣如此：為了滿足三大范式，我們在規范化表格時就會拆分出越來越明細的表格。但客戶喜歡綜合的信息，為了滿足客戶，我們又需要把這些表通過連接查詢還原為客戶喜歡的綜合數據。這和從一張表中讀出數據相比，大大影響了數據庫的查詢性能。所以有時為了性能，需要做適當折中，適當犧牲規范化的要求，來提高數據庫的性能。再如：在成績表中添加一列－“成績總分”，屬於數據冗余，因為總分在查詢時可由各門成績求出來。但頻繁查詢成績總分，並希望保存下來，所以有時表中就干脆添加總分這一列。