1 MySql資料庫建模過程

需求分析階段：分析客戶的業務和處理需求

概要設計階段：設計資料庫的E-R模型圖，確認需求資訊的正確和完整

詳細設計階段：應用三大正規化稽核資料表結構

程式碼編寫階段：物理實現資料庫，編碼實現應用

軟體測試階段：....

安裝部署：...

2設計資料庫的步驟1瞭解需求：與該系統有關人員進行交流、座談，充分了解使用者需求，理解資料庫需要完成的任務

2標識實體：標識資料庫要管理的關鍵物件或實體（名詞）

3標識每個實體的屬性（名詞）

4標識實體之間的關係（動詞）

在E-R圖中，實體用矩形標識，屬性用橢圓形標識，關係用菱形標識

1.一對一:X中的一個實體最對與Y中的一個實體關聯,
    並且Y中的一個實體最多與X中的一個實體關聯.
    Eg:一個人只有一張身份證.
2.一對多:X中的一個實體可以與Y中的任意數量的實體關聯;
    Y中的一個實體最多與X中的一個實體關聯.
    Eg:一個班級有多名學生.
3.多對多:X中的一個實體可以與Y中的任意數量的實體關聯,反之亦然.
    Eg:學生和課程之間的關係,一個學生可以有多門課程,一門課程可以對應多名學生.
E-R圖設計練習

某醫院病房計算機管理中心需要如下資訊：
    科室：科名、科地址、科電話、醫生姓名
    病房：病房號、床位號、所屬科室名
    醫生：姓名、職稱、所屬科室名、年齡、工作證號
    病人：病歷號、姓名、性別、診斷、主管醫生、病房號
其中，一個病房只能屬於一個科室，一個科室可以有多個病房，一個醫生只屬於一個科室，一個科室可以有多名醫生，一個醫生可負責多個病人的診治，一個病人的主管醫生只有一個。一個病人只能住一間病房，一間病房可以入住多名病人。
完成如下設計：
（1）       設計該計算機管理系統的E-R圖
（2）       將該E-R圖轉換為關係模式結構。

E-R圖設計（表設計）  重要！！！

1.如果是1：1的關係：那麼將實體轉換成表，將任意1端實體的主鍵拿到另一端實體做外來鍵。

2.如果是1：N的關係：那麼將實體轉換成表，關係不成表，將1端實體的主鍵拿到N端實體做外來鍵。

3.如果是M：N的關係：將實體轉換成表，關係形成表，同時將兩端實體的主鍵拿過來作為該表的外來鍵，形成複合主鍵。

資料庫設計三大正規化

為了建立冗餘較小、結構合理的資料庫，設計資料庫時必須遵循一定的規則。在關係型資料庫中這種規則就稱為正規化。

正規化是符合某一種設計要求的總結。

要想設計一個結構合理的關係型資料庫，必須滿足一定的正規化。

第一正規化： 要求表的每個欄位必須是不可分割的獨立單元

student：name       --違反第一正規化

　　　　張小名丨狗娃

student ： name old_name  --符合第一正規化

　　　　張小名    狗娃

第一正規化是最基本的正規化。如果資料庫表中的所有欄位值都是不可分解的原子值，就說明該資料庫表滿足了第一正規化。

第一正規化的合理遵循需要根據系統的實際需求來定。比如某些資料庫系統中需要用到“地址”這個屬性，本來直接將“地址”屬性設計成一個數據庫表的欄位就行。但是如果系統經常會訪問“地址”屬性中的“城市”部分，那麼就非要將“地址”這個屬性重新拆分為省份、城市、詳細地址等多個部分進行儲存，這樣在對地址中某一部分操作的時候將非常方便。這樣設計才算滿足了資料庫的第一正規化。

第二正規化

第二正規化： 在第一正規化的基礎上，要求每張表只表達一個意思。表的每個欄位都和表的主鍵有依賴。

employee（員工）：

員工編號 員工姓名 訂單名稱  --違反第二正規化

員工表：員工編號 員工姓名

訂單表：訂單編號 訂單名稱  --符合第二正規化

第二正規化在第一正規化的基礎之上更進一層。第二正規化需要確保資料庫表中的每一列都和主鍵相關，而不能只與主鍵的某一部分相關（主要針對聯合主鍵而言）。也就是說在一個數據庫表中，一個表中只能儲存一種資料，不可以把多種資料儲存在同一張資料庫表中。

比如要設計一個訂單資訊表，因為訂單中可能會有多種商品，所以要將訂單編號和商品編號作為資料庫表的聯合主鍵，如下表所示。

訂單資訊表

這樣就產生一個問題：這個表中是以訂單編號和商品編號作為聯合主鍵。這樣在該表中商品名稱、單位、商品價格等資訊不與該表的主鍵相關，而僅僅是與商品編號相關。所以在這裡違反了第二正規化的設計原則。
而如果把這個訂單資訊表進行拆分，把商品資訊分離到另一個表中，把訂單專案表也分離到另一個表中，就非常完美了。如下所示。

這樣設計，在很大程度上減小了資料庫的冗餘。如果要獲取訂單的商品資訊，使用商品編號到商品資訊表中查詢即可。
第三正規化

第三正規化： 在第二正規化基礎，要求每張表的主鍵之外的其他欄位都只能和主鍵有直接決定依賴關係。

員工表：員工編號（主鍵） 員工姓名 部門編號 部門名    --符合第二正規化，違反第三正規化   （資料冗餘高）

員工表：員工編號（主鍵 ）  員工姓名  部門編號  

部門表：部門編號 部門名     ------符合第三正規化（降低資料冗餘 ）

總結：1.為滿足某種商業目標，資料庫效能比規範化資料庫更重要
通過在給定的表中新增額外的欄位，以大量減少需要從中搜索資訊所需的時間
通過在給定的表中插入計算列（如成績總分），以方便查詢
2.在資料規範化同時，要綜合考慮資料庫的效能