機房收費系統資料庫概念結構設計

標籤：資料庫

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

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

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

         機房收費系統是給機房的值班人員和管理員使用的，因此系統的使用者將會是一個實體，為了滿足客戶需要，還要給使用者進行使用權限設定。系統要管理的資訊自然是學生本身的資訊和學生因上機所產生的資料記錄，因此學生也是一個必不可少的實體。

         很多人因為三範式的原則，將原來學生資訊中的有關卡資訊的部分抽出來，形成了另一個實體，即卡實體。這樣做提高了資料庫的靈活性，在某位學生的卡丟了之後，即可將丟失的卡的資訊從資料庫中刪除，將學生資訊中的卡號更新即可。但是在系統的實際使用過程中，這樣的設計並無多大優勢，反而降低了查詢效率，因為涉及到了兩張表。有人說用視圖就可搞定，但是相對於一張表來說，那就相對麻煩了點。

         我們接著分析，系統使用者操作會產生工作記錄，學生在機房上機會產生上機記錄，系統使用者擁有對卡的註冊、登出和充值的許可權，因此會產生相應的資料資訊，這樣就差一個系統啟動並執行基礎資料設定了，這些資料資訊需要一張表去儲存，因此基本的資料庫實體圖就可以畫出來了。

         

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

          

         總之資料庫的設計最難的是初期的需求分析階段，也許需要開發方和客戶方經過很長時間的反覆討論和交流，方才能夠產生最終的結果，並且在後續的開發過程中也許還要不斷的進行改進和完善。當然嚴格來講，我這裡說的也不能算是真正意義上的資料庫設計，因為系統的藍本和資料庫藍本的存在，會干擾我們的思考和分析，但這就是學習，要經曆這個過程，親手去做一個資料庫，才會有深刻的體會，因為站在岸上永遠也學不會遊泳！