mysql學習之數據庫設計

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.在數據規範化同時，要綜合考慮數據庫的性能