如果不想看理論性的數的話，又想重溫一下數據庫知識，又是日本動漫迷的話，可以看一下： 作為漫畫和專業知識結合在一起的點子十分有創意，而且讀起來也有趣。 數據庫通過E-R，entity-relationship模型進行數據庫的設計，根據具體的關系。 一對多，一個職員對

如果不想看理論性的數的話，又想重溫一下數據庫知識，又是日本動漫迷的話，可以看一下：

作為漫畫和專業知識結合在一起的點子十分有創意，而且讀起來也有趣。

數據庫通過E-R，entity-relationship模型進行數據庫的設計，根據具體的關系。

一對多，一個職員對多個客戶。如果只有一個職員。

多對一，反過來。

多對多，多個職員對多個客戶。

確定關系后，還需要進行normalization，規范化，分三范式。

先看看非規范化：

你會發現一個王國里面的商品又有兩個列，你設計數據庫的時候不會這樣吧。

規范化有什么用呢？你一改一樣水果的單價，就要全部都要改動，如果規范化之后，將水果單獨分開，那就不會造成矛盾了。

第一范式：

第一范式，商品和訂單分開。如果蘋果單價一變化，就不用將非范式表中含有蘋果的價格全部改過。

每一列都是不可分割的，除去了非規范式中的重復記錄（記錄就是一行）。

但是，存在的問題是，如果商品沒有賣出去過，那么數量為0，也沒有報表編碼，但是我們確實需要商品的名稱，單價和商品編碼。

所以，繼續看第二范式。

第二范式：

商品的名稱，單價和商品編碼單獨做成一個表，通過商品編碼這一列確定其他兩個字段的值，這種原則成為函數依賴（functionally dependent）通過主鍵確定其他列的值。

回頭看看報表編碼，出口國編碼這個表，第二范式。

報表編碼可以確定出口國編碼，確定出口國編碼后再確定出口國名稱。

問題所在，出口國編碼雖然能通過一列確認其他值，但是如果出口國根本就沒有進口過，那么所謂的商品編碼便是不存在的。

第三范式：

只能由主鍵確定其他列值，而第二范式中出現的，由報表編碼可以確定出口國編碼，確定出口國編碼后再確定出口國名稱。這種通過某一列的值間接確定另外一列的值，我們成為傳遞依賴，第三范式去除傳遞依賴。

其實報表編碼，商品編碼，數量這一個表，和商品編碼，商品名稱，單價這一個表不只滿足第二范式了，也滿足第三范式了。

但是，第二范式中，報表編碼，口國編碼，出口國名稱的表卻不滿足第三范式，因為有傳遞依賴，分割之后就滿足第三范式了。

總結一下：

第一范式：列不可分，行中沒有重復記錄。

第二范式：通過主鍵確定其他列的值，通過其他列又確定其他列的值，會存在傳遞依賴。

第三范式：只能通過主鍵確定其他列的值，不存在傳遞依賴，其實第三范式就是特殊的第二范式。

聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com