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

標籤：span   改進   ack   重複   設計   理論知識   物理   gpo   個人   

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

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

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

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

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

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

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

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

         

watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvbGlhbmppYW5nd2Vp/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center" >

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

          

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

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