第二級正規化形式
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關聯。現在的情況好象已經得到了明顯的改善。不過，如果我們要為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輸入，或者更多一點。這種情況下，我們的數據庫還可以進行下一級別的優化--第四步，對於大多數的開發者來說，這一步都是忽略的，因為它要依賴一個很特別的關系--一個多對多的關系，這在我們的應用中是還沒有遇到過的
