前面的話
本文將詳細介紹數據庫設計的相關知識
設計范式
數據庫設計共有三大范式：
第一范式：無重復的列
第二范式：屬性完全依賴於主鍵
第三范式：屬性不能依賴於主屬性
下面將分別對這三個范式進行詳細介紹
第一范式
數據庫表中的每一列都是不可分割的基本數據項，同一列中不能有多個值。具體而言，有以下兩條要求
1、每一列屬性都是不可再分的，確保每一列的原子性
2、兩列的屬性相近或相似或一樣，盡量合並屬性一樣的列， 確保不產生冗余數據
以考勤表設計為例，考勤表用來記錄每天學生的考勤情況
最簡單的情況是，每一天都建立一張表。字段是每個學生的姓名，列值表示是否簽到。這樣，可以很方便的存儲當天的考勤情況。但是，這也導致了每天都需要在數據庫里新建一張考勤表。而且，這種做法違反了第一范式，這張考勤表的字段的屬性含義都是一樣的，都是記錄學員的考勤情況。因此，這些字段是需要合並的
更優化的設計是，第一字段是學生姓名，第二字段是0101表示`1月1日，第三字段是0102表示1月2日，以此類推。這種做法，不再需要設計那么多表，將學生的姓名列合並成了一個姓名列。但是，同樣它沒有遵循第一范式，1年365天， 代碼除了學生姓名列外，還需要設置365個字段。而且，這些列的含義都是一樣的，記錄當天的考勤。因此，這些字段也是需要合並的
下面是優化的情況，把所有的日期合並成一個日期字段，新增一個考勤狀態字段，如下所示，完全遵循了第一范式，沒有重復的列，且每一列都是可拆分的。
總而言之，用第一范式設計數據庫時，就是分解數據，並將屬性相似的列合並
第二范式
第二范式需要遵循以下要求：
1、一個表表必須有一個主鍵
2、沒有包含在主鍵中的列必須完全依賴於主鍵，而不能只 依賴於主鍵的一部分
以下面購物車表為例，用戶ID和商品ID構成了商品的主鍵，數量列依賴於用戶購買商品的數量，單價和商品名稱只依賴於商品ID。因此，這張表不滿足第二范式
優化后，修改如下
第三范式
非主鍵列必須直接依賴於主鍵，不能存在傳遞依賴。第三范式，相較於第二范式而言，強調的是直接依賴，而不能是傳遞依賴
關於傳遞依賴，以下面的中獎信息表為例，中獎金額依賴於中獎等級，而中將等級及依賴於用戶ID，這就是傳遞依賴
要遵循第三范式，就要消除傳遞依賴
新聞系統
下面嘗試利用三個范式，來設計新聞系統數據庫。包括以下要點：
1、用戶名、密碼、是否是管理員
2、新聞標題、新聞內容、作者、新聞時間、是否上線
3、評論人、評論內容、評論時間、評論源
分別對應用戶表、新聞表和評論表
一般來說，用戶名長度不超過20個字符，密碼長度不超過20個字符，新聞標題長度不超過30個字符，新聞內容長度不超過5000個字符，評論內容長度不超過300個字符
用戶表詳細如下
新聞表詳細如下
評論表詳細如下
最后
在設計數據庫時，只需滿足以上三個范式，就可以設計既合理又滿足需求的數據庫