**

良好的資料庫設計能夠

**：
節省資料的儲存空間。
能夠保證資料的完整性。
方便進行資料庫應用系統的開發。

糟糕的資料庫設計：
資料冗餘、儲存空間浪費。
記憶體空間浪費。
資料更新和插入異常麻煩。

資料庫的生命週期：
1、需求分析階段 確定需求（與客戶溝通）
2、邏輯設計階段 通過資料模型（E-R模型、UML圖例）得到資料概念模型 -> 轉換為SQL表 -> 規範化
3、物理設計階段 選擇索引
4、實現階段 把物理設計的結果轉換為資料庫管理系統（DBMS）中的DDL建立資料結構。通過SQL語句來進行增刪改查。
5、再設計再修改。
6、廢止

E-R圖
E 實體 （一個學生、一本書、一門課、一個會議、一個關係…）
R 屬性 （人的屬性：年齡、性別 學生的屬性：學號、性別、年齡…）

元組就是表中的一行。
分量就是某個屬性值。
碼就是表中唯一可以確定一個元組的某個屬性，可以作為碼的都是候選碼，選出的一個碼就是主碼。
外碼是一個屬性（或者屬性組），它不是碼，但是它是別的表的碼。
域是屬性的取值範圍。

概率示例圖：

專業的畫圖工具有 Microsoft Vision 、、、

現在有一個教學管理系統。系統實體有：
教師，屬性有 教師號、姓名、性別、年齡、出生日期、專業，其中教師號為碼。
學生，屬性有 學號、姓名、性別、出生日期、籍貫、專業，其中學號為碼。
課程，屬性有 課程號、課程名、學時數、學分、教材，其中課程號為碼。
實體間的關係是：一個教師可以教授多門課程，一門課程可以被多名教師講授，即教師與課程之間是多對多的關係。一個學生可以選修多門課程，一門課程可以被多名學生選修，即學生與課程之間是多對多的關係。

E-R圖設計是屬於資料庫的邏輯設計階段的。

E-R圖轉換為資料表的原則：
1、每一個實體應該對映為一個表。
例如：教師表、課程表、學生表

2、一般多對多的關係也應該對映為一個表，表中應該包含關係雙方的碼屬性，同時還應該包含該關係本身的一些屬性，如果該關係有屬性的話（例如上例中的選修關係它就含有一個成績屬性，因為每位學生選的每一門課都有一個唯一的成績，這個成績屬性就包含在選修這個關係中，所以我們建立選修表的時候不但要將學生和課程的碼放進來，同時也要將該學生選修該門課程的成績放進來；再例如上例中的教課關係也會有一個自己的屬性：教課時間，因為每位老師上的每一門課的時間都是唯一的而且不同的課不同的老師時間不一定相同，所以教課時間是教課關係表中的一個屬性，關係表的主鍵一般以雙方的主鍵組合作為聯合主鍵）。但是一對多（例如一個學生屬於一個班，但是一個班可以有很多個學生，這個時候，可以在學生實體表中新增一個班級的碼就可以有效關聯學生和班級而不需要再去建一張學生和班級的關係表了）或者一對一（可以將一對一的兩張表合併定義為一張新的表也可以按照一對多的方法建表）的關係則可以不用映射出一個關係表。
兩個關係表大致如下：
選課表（課程號，

資料庫的規範化
就是要對錶中的屬性來做設計，防止資料冗餘，儲存空間浪費，記憶體空間浪費，資料更新和插入異常。
基於資料冗餘提出了有五個設計正規化。
第五正規化資料冗餘率最低，但是資料會被分解到很多張表，會給檢索造成較大負擔，因為檢索結果要關聯很多張表才能得到。
一般設計到第三正規化就已經不錯了。即可以減少資料冗餘又可以實現較快的檢索。

1NF表示表中的資料的每一個欄位都是不可以再分割的原子資料。

2NF表示在滿足1NF的情況下，表中的非碼屬性必須被聯合主鍵決定，不能有聯合主鍵中的某一個屬性決定。例如：
成績表（課程號，學號，成績，課程名）
這個成績表中的”課程名“這個屬性只依賴課程號這一個屬性，而不是依賴課程名和學號這個聯合主鍵，所以這張表不滿足2NF，需要將這張表分解為如下兩張表才能滿足2NF
成績表（課程號，學號，成績）
課程表（_課程號，課程名）

3NF表示在滿足2NF的情況下，每一個非關鍵字必須由關鍵字來決定而不能由非關鍵字來決定。
例如：
資訊表（_職工編號，職工姓名，部門名稱，部門位置）
這個資訊表的主鍵是職工編號，但是部門經理名稱並不依賴職工編號而是依賴與非主鍵的部門名，這樣就不滿足3NF了，可做如下修改
職工表（_職工編號，職工姓名，部門編號）
部門表（_部門編號，部門名稱，部門位置）