MySQL系列之一：數據庫設計

MySQL系列之一：數據庫設計

前言

這裡將以前不怎麼熟悉的數據庫設計知識重新拾起，做一個簡單的知識梳理。之前一直認為數據庫設計無非就是創建數據庫、建表、添加字段、確定字段類型（這點隨意性很大），諸如此類。當系統地對數據庫知識重新學習的時候才發現數據庫設計也有一套類似軟件開發流程的規范，並且每一個步驟都是有不同的側重點的。

數據庫設計的概念

簡單來說，數據庫設計就是對需求進行分析、邏輯設計、物理設計以及維護和優化的過程。可以看到，數據庫設計不僅僅體現在軟件開發過程中，還體現在軟件後期的維護上。（時間周期）
這裡的軟件需求分析與軟件開發過程中的需求分析不太一樣，數據庫設計中的需求分析更側重數據源（什麼數據）、數據的屬性以及數據和屬性的特點。

數據庫設計的一系列過程都需要結合我們現有的DBMS，設計表以及表之間聯系，從而對數據進行有限的存儲以及高效訪問。

數據庫設計的步驟

在此之前還有一個問題沒有弄清楚，為什麼要進行數據庫設計？就我自己總結而言，有以下好處：

良好的數據庫設計對減少數據冗余和操作異常、對數據有限存儲和高效訪問有很大幫助。之前自己做的畢業設計實現的實驗管理系統就是由於沒有對數據庫好好設計，導致後面數據查找的困難，事實是，你寫一大堆SQL代碼還不一定得到你想要的結果，所以這就是糟糕的數據庫設計的後果。各位小伙伴要引以為鑒吶。

數據庫設計的步驟

OK，言歸正傳，數據庫設計包括四個步驟：

需求分析 邏輯設計 物理設計 維護與優化

作為一名非專業DBA，本著實用即王道的原則，認為周邊知識了解即可，不求深入。所以對最後的維護和優化不做詳細的介紹，如果有小伙伴對這塊比較感興趣，可以參考數據庫設計教程。

需求分析

需求分析需要解決三個問題：軟件需要哪些數據、數據有哪些屬性以及數據屬性的特點。首先，軟件需要的數據是由軟件業務決定的，這點可以從前期的需求文檔中看到；數據的屬性就是數據庫每個表中的字段，數據的屬性是構成數據的不可缺少的元素，在數據庫中一行數據成為數據的基本單元，也稱為元組；數據屬性的特點就是分析該數據是否需要永久保存，如果是則數據將一直存在數據庫中，如果否，則該數據不能永久存在數據庫中（這類數據一直是時間敏感的，涉及頻繁的讀寫操作）。

邏輯設計

邏輯設計承接需求分析，要解決的核心問題就一個：繪制E-R圖。E-R圖就是把需求分析的結果轉換成邏輯模型的過程。E-R圖由三個要素組成：實體集、屬性集和聯系集。實體集都是具有相同屬性的，屬性集是實體所具有的，聯系集則是由實體之間的聯系組成的（這裡的聯系包括多種聯系，後面的文章將詳細說明這點，敬請期待）。所謂“邏輯設計”，就是與具體的DBMS無關。要繪制E-R圖需要了解以下幾個概念:

關系：一個關系對應數據庫中的一張表 實體：具有一組相同屬性的數據庫管理對象 元組：表的一行數據 屬性：每個屬性對應數據庫表的一列 主關鍵字：可以唯一標識實體的一條或多條屬性 候選關鍵字：特指需要多條屬性才能標識實體的情況

說完基本概念，下面就是實例講解了，下面以我自己正在做的項目加以說明：

整個系統是學生信息管理系統，具有很多模塊，我負責的模塊是住宿信息管理，經過需求分析，最終確定該模塊具有三部分的功能：學生物品報修、學生查詢水電信息、宿管登記住宿信息、物業處理物品報修和後勤分配住宿信息。

學生: {學號,姓名,性別,聯系方式,宿捨號}

宿管: {宿管ID,姓名,性別,聯系方式}

物業: {物業管理人員ID,姓名,性別,聯系方式}

後勤: {後勤管理人員ID,姓名,性別,聯系方式}

住宿信息表: {id,姓名,學號,性別,宿捨號,專業,班級號,聯系方式}

宿捨: {宿捨ID,樓棟號,宿捨號}

物品報修信息表: {id,物品名稱,損壞情況,報修人,聯系方式,宿捨號,報修時間,緊急程度,是否處理}

用水信息: {id,宿捨號,用水量,本月剩余水量,剩余金額,欠費狀態}

用電信息: {id,宿捨號,用電量,本月剩余電量,剩余金額,欠費狀態}

根據上面這些數據，可以繪制下面的E-R圖：

由於原圖過大所以，只展示了部分。下面簡要說明一下圖的內容，每一個矩形代表一個實體，每個實體都有屬性集，代表該字段不能為空，代表該字段是實體的主鍵，代表該字段是實體的候選關鍵字。實體之間存在各種聯系，圖中的線條就表示了實體與實體的具體聯系。下面就簡要說說這個聯系是什麼鬼：

在數據庫設計中，存在4種基本的聯系（Relationship）：一對多、一對一、多對一。舉例來說，老師可以帶多個學生上課，學生也有多個多個老師，所以老師和學生是多對多的聯系；一個學生只能在一個班級，而一個班級可以有多個學生，所以學生與班級是多對一的聯系。反正分析思路就是一個和多個的對應關系能否成立。繼承（Inheritance）：例如學生、老師都是人，所以“學生”和“老師”這兩個實體和“人”之間構成繼承關系。繼承關系的存在是為了以後更好的擴展。連接：具有連接關系的實體之間的地位是平等的，請仔細思考下圖：

下面是開發人員、專家與講座之間的關系：

從圖中可以看出，如果兩者不是連接關系就意味著地位的不平等。所以連接關系也挺好理解的。Ok，next，依賴：依賴就是某個實體不能單獨存在，必須和另一個實體共存才有存在的意義。舉例來說：門窗必須依賴房子而存在，沒有房子，就沒有門窗存在的必要。

物理設計

物理設計是最終的數據庫設計的核心，也是可見成果的關鍵步驟。那麼物理設計要解決什麼問題呢？

選擇合適的DBMS 規定數據庫、表和字段的命名規范 根據所選的DBMS確定具體字段的字段類型

選擇合適的數據庫

目前，企業級數據庫有Oracle和SQL Server，這類數據庫對數據的安全性和容量有較高要求。互聯網項目使用的一般都是MySQL、PgSQL，所以根據需要根據自己項目的類型選擇合適的數據庫。

規定命名規范

命名規范需要遵循字段可讀性原則和見名知義原則，不然隨意的字段名還要建立數據字典，增加額外的工作量，沒什麼必要。

確定字段類型

就我自己而言，覺得最不好判斷的是char和var char類型，兩種數據類型特別容易選擇，所以一般情況都是選擇更保守的varchar類型。但是只要仔細分析發現兩種類型首先在表達的范圍就存在限制，char類型不能超過255個字節，所以只要不是那種常文本一般都可以容納，這點上講，varchar比char節省空間，但是varchar比char效率更差，這一點可以這麼理解：當對varchar類型的數據進行修改的時候，可能因為數據長度的不同（以字符串”abc”為例，char類型需要5個字節，而varchar只需要3個字節）導致“行遷移(Row Migration)”，下面Oracle對行遷移的官方解釋：

當一行的記錄初始插入時是可以存儲在block（block是磁盤存儲的最小單位）中的，由於更新操作導致行增加了，而block的自由空間已經滿了，這個時候就產生了行遷移。在這種情況下，oracle將會把正行數據遷移到一個新的block中，oracle會保留被遷移的行的原始指針指向新的存放行數據的block，這意味著被遷移的ROW ID是不會改變的。

說的有點復雜，但總結起來可以知道varchar和char類型的差距不大，當然在大數據開發應用中除外。