作者:allsky

1.為應用在多條記錄的字段建立獨立的表格

　　2.通過一個foreign key來關聯這些表格的值


　　我們將url的值放在一個獨立的表格中，這樣我們就可以在以后加入更多的數據，而無需擔心產生重復的值。我們還通
過主鍵值來關聯這些字段：

　　users

　　userId name company company_address

　　1 Joe ABC 1 Work Lane

　　2 Jill XYZ 1 Job Street

　　urls

　　urlId relUserId url

　　1 1 abc.com

　　2 1 xyz.com

　　3 2 abc.com

　　4 2 xyz.com

　　如上所示，我們創建了獨立的表格，users表中的主鍵userid現在與url表中的foreign key relUserId關聯�，F在的情
況好象已經得到了明顯的改善。不過，如果我們要為ABC公司加入一個員工記錄呢？或者更多，200個？這樣我們就必須重
復使用公司名和地址，這明顯不夠冗余。因此我們將應用第三級正規化方法：

　　第三級正規化形式

　　1.消除不依賴于該鍵的字段

　　公司名及地址與User Id都是沒有關系的，因此它們應用擁有自己的公司Id：

　　users

　　userId name relCompId

　　1 Joe 1

　　2 Jill 2

　　companies

　　compId company company_address

　　1 ABC 1 Work Lane

　　2 XYZ 1 Job Street

　　urls

　　urlId relUserId url

　　1 1 abc.com

　　2 1 xyz.com

　　3 2 abc.com

　　4 2 xyz.com

　　這樣我們就將companies表中的主鍵comId和users表中名字為relCompId的foreign key關聯起來，就算為ABC公司加入
200個員工，在companies中也只有一條記錄。我們的users和urls表可以不斷地擴大，而無需擔心插入不必要的數據。大部
分的開發者都認為經過三步的正規化就足夠了，這個數據庫的設計已經可以很方便地處理整個企業的負擔，此看法在大多
數的情況下是正確的。

　　我們可以留意一下URL的字段--你注意到數據的冗余了嗎？如果給用戶用戶輸入這些url數據的HTML頁面是一個文本
框，可任意輸入的話，這并沒有問題，兩個用戶輸入同樣收藏夾的概率較少，不過，如果是通過一個下拉式的菜單，只讓
用戶選擇兩個url輸入，或者更多一點。這種情況下，我們的數據庫還可以進行下一級別的優化--第四步，對于大多數的開
發者來說，這一步都是忽略的，因為它要依賴一個很特別的關系--一個多對多的關系，這在我們的應用中是還沒有遇到過的.