機房重構--資料庫設計（二），機房重構--資料庫

機房重構--資料庫設計（二），機房重構--資料庫

    在完成了機房收費系統資料庫需求分析、ER圖、關聯式模式的階段之後，就該根據關聯式模式來設計資料庫了，下面是我對這個階段的一個總結。

    這次的關聯式模式有使用者、學生、卡、基本資料、電腦、賬單、工作記錄、充值、退卡、上機共10個，要由這10個關聯式模式來設計資料庫表，其中對於電腦（電腦名  系統時間  系統日期）這個關係，沒有必要單獨拿出來設計，其他的幾個都需要轉換成資料表，在確定了哪些關聯式模式需要轉換為關係表之後，就需要分析的資料表欄位的明確以及資料表三範式的規範的確定。

 先來重溫下資料庫設計三大範式：

    （一）資料表中的每個欄位不能有多個值或者不能有重複的屬性，符合原子性。

    （二）要求實體的屬性完全依賴於主關鍵字。所謂完全依賴是指不能存在僅依賴主關鍵字一部分的屬性。

    （三）在1NF基礎上，任何非主屬性不依賴於其它非主屬性[在2NF基礎上消除傳遞依賴]。

     分析一張舊的資料表：

    像這張表OnLine_Info，主鍵CardNo，其他欄位有：cardtype，studentname，Department，sex等，而這些資訊完全是和Student_Info中的內容重複，So，完全可以通過主外鍵將兩張表關聯起來，這樣這些重複的欄位就不必要在不同的表裡重複出現了。

    再看一張表Studetn_Info:

    當時的表名是Student_Info，可認真分析之後發現這完全就是學生資訊和卡的資訊的疊加，道理上一卡對應一個人，但是當修改或刪除卡資訊時，學生資訊也有被修改的風險，同時由於這張表包含了太多的資訊，導致查詢學生資訊需要這張表、查詢卡資訊需要這張表、結賬算錢需要這張表，查看是否結賬等也需要這張表，嚴重違背物件導向思想中“單一職責”原則，所以這次的設計必須改掉這些不足。

 

 對資料類型的研究    昨天在把關聯式模式對應到資料表的時候由於各種資料對應的類型需要分別考慮，比如說字元型、數值型、時間日期型、金錢型……，用到最多的還是字元型，那就對char(n)、nchar(n)、varchar(n)和nvarchar(n)進行一個簡單的總結。

      這是在查閱資料後在OneNote裡做的圖，總而言之，如果是Unicode資料類型（即含有中文或者中文英文結合）則選擇varchar或者nvarchar，如果需要變長，則選擇nchar或者nvarchar.比如當我們在登入表單的時候使用者名稱用char(10)定義之後，需要在代碼中用Trim(UserID)來傳入資料庫，為了是避免空格，當然這樣要求使用者名稱中不能含有空格，但是在密碼這個欄位中，可能會涉及到空格，這裡就不建議使用nchar，最好使用char(n)。

    其次，這次的所有涉及到金錢類型的欄位全部用到了money類型來表示，只要在代碼中用decimal(m,n)的資料類型來對應就OK了。

  資料表涉及展示

   資料庫名稱：Restructurecharge

   一共9張表：

  （1）User_Info

  （2）Card_Info

  （3）Student_Info

  （4）Recharge_Info

  （5）Online_Info

  （6）LogoffCard_Info

  （7）Worklog_Info

  （8）BasicDate_Info

  （9）Bill_Info

   這就是這次設計的9張表，比起之前的11張表少了2張，這次的表也去掉了那些10多個欄位的冗餘表，在設計過程中，對於CancelCard_Info是否需要繼續使用進過了思想鬥爭後還是加上了，畢竟不多一張表的話對Card_Info的壓力比較大，還是保證“單一職責”吧，其次有幾張表類似Worklog_Info、Bill_Info還是需要添加序號的，便於查詢時候的方便。

   這樣，資料庫的設計就完成了，雖然還有不符合第二、三範式的地方，但是和上次相比已經好多了，在代碼的實現階段，對資料類型的設計、字元的長短，是不是還是要回頭看自己的總結的。