【正文】 ；　　數(shù)據(jù)庫表3中也存在非關鍵字段標題、內容對關鍵字段回復ID的部分函數(shù)依賴，也不滿足第二范式的要求，但是與數(shù)據(jù)庫表2相似，這一設計也不會導致數(shù)據(jù)冗余和操作異常?！　∥覀儗?shù)據(jù)庫表分解為（帶下劃線的為關鍵字）：　?。?） 用戶信息：用戶名，主頁，電話，聯(lián)系地址　　（2） 帖子信息：發(fā)帖ID，標題，內容　?。?） 回復信息：回復ID，標題，內容　?。?） 發(fā)貼：用戶名，發(fā)帖ID　　（5） 回復：發(fā)帖ID，回復ID　　這樣的設計是滿足第3范式和BCNF范式要求的，但是這樣的設計是不是最好的呢？　　不一定。所謂傳遞函數(shù)依賴，指的是如果存在A → B → C的決定關系，則C傳遞函數(shù)依賴于A。 反之則是亂七八糟，不僅給數(shù)據(jù)庫的編程人員制造麻煩，而且面目可憎，可能存儲了大量不需要的冗余信息?！　〉诙妒剑?NF）：數(shù)據(jù)庫表中不存在非關鍵字段對任一候選關鍵字段的部分函數(shù)依賴（部分函數(shù)依賴指的是存在組合關鍵字中的某些字段決定非關鍵字段的情況），也即所有非關鍵字段都完全依賴于任意一組候選關鍵字?！　“褜W生關系表分為如下兩個表：　　學生：(學號, 姓名, 年齡, 所在學院)；　　學院：(學院, 地點, 電話)?！　∮纱丝梢钥闯?，并不一定要強行滿足范式的要求，對于1：N關系，當1的一邊合并到N的那邊后，N的那邊就不再滿足第二范式了，但是這種設計反而比較好！　　對于M：N的關系，不能將M一邊或N一邊合并到另一邊去，這樣會導致不符合范式要求，同時導致操作異常和數(shù)據(jù)冗余。我們需要增加發(fā)帖ID、回復ID字段，即將表修改為：用戶名主頁電話聯(lián)系地址發(fā)帖ID發(fā)帖標題發(fā)帖內容回復ID回復標題回復內容　　這樣數(shù)據(jù)表中的關鍵字(用戶名，發(fā)帖ID，回復ID)能決定整行：　　(用戶名,發(fā)帖ID,回復ID) → (,主頁,電話,聯(lián)系地址,發(fā)帖標題,發(fā)