數據庫的設計大致流程想必大家都知道。不知道的也能非常easy的在網上找到相關的資料，通常，我們將數據庫設計分為6個階段。即需求分析階段、概念結構設計階段、邏輯結構設計階段、物理結構設計階段、實施階段、執行和維護階段。

本次我們不談數據庫設計的理論知識，主要是以機房收費系統的數據庫設計為背景來說明數據庫的概念結構設計是怎樣產生的，當然包含了數據庫設計中最難的需求分析了，否則就談不上什麽數據庫的概念結構設計了。

由於我們都已經做過一遍了，並且從一開始我們就是照著系統原型做的，沒有從無到有的過程，所以無法體會真正的需求分析是什麽樣的，也就不會去思考待開發系統的的各種功能是怎樣抽象出來的。以下我就以我個人的理解來開始機房收費系統的數據庫的設計之旅。

機房收費系統是給機房的值班人員和管理人員使用的。因此系統的用戶將會是一個實體，為了滿足客戶須要，還要給用戶進行權限設置。

系統要管理的信息自然是學生本身的信息和學生因上機所產生的數據記錄，因此學生也是一個不可缺少的實體。

非常多人由於三範式的原則，將原來學生信息中的有關卡信息的部分抽出來，形成了還有一個實體，即卡實體。這樣做提高了數據庫的靈活性。在某位學生的卡丟了之後，就可以將丟失的卡的信息從數據庫中刪除，將學生信息中的卡號更新就可以。可是在系統的實際使用過程中，這種設計並無多大優勢。反而減少了查詢效率，由於涉及到了兩張表。

有人說用視圖就可搞定，可是相對於一張表來說。那就相對麻煩了點。

我們接著分析，系統用戶操作會產生工作記錄，學生在機房上機會產生上機記錄，系統用戶擁有對卡的註冊、註銷和充值的權限。因此會產生對應的數據信息，這樣就差一個系統執行的基礎數據設置了，這些數據信息須要一張表去存儲。因此主要的數據庫實體圖就能夠畫出來了。

上面的圖是極其簡單的一張圖。可能還有非常多錯誤，畢竟還沒有具備熟練準確的對待開發系統的進行抽象分析的能力。當然上面的圖並沒有給出各個實體的屬性，以下我用power designer軟件畫出系統的概念結構圖，當然這個圖也不是標準的CDM，主要目的是給大家展示出各個實體的屬性。

總之數據庫的設計最難的是初期的需求分析階段，或許須要開發方和客戶方經過非常長時間的重復討論和交流，方才可以產生終於的結果，而且在興許的開發過程中或許還要不斷的進行改進和完好。當然嚴格來講，我這裏說的也不能算是真正意義上的數據庫設計，由於系統的藍本和數據庫藍本的存在，會幹擾我們的思考和分析。但這就是學習。要經歷這個過程，親手去做一個數據庫，才會有深刻的體會，由於站在岸上永遠也學不會遊泳。

機房收費系統數據庫概念結構設計