資料庫正規化和設計技巧 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
由於沒有進行任何的正規化處理,我們將這種形式的表稱為零狀態形式的表。留意其中的url1和url2欄位---如果我們在應用中需要第三個url呢?這樣你就要在表格中多加一列,很明顯,這不是一個好辦法。如果你要建立一個具有擴充性的系統,你就要考慮使用第一個正規化的形式,並且應用到這個資料表中。 第一級正規化規則
以上的資料表明顯的違反了上面第一條的規定,那麼第三項中的主鍵值(KEY)又是什麼意思呢?其實很簡單,它只是在每筆資料中加入一個唯一的、且自動增加的整數值。透過這個值,就可以將兩個姓名一樣的資料區分出來。透過第一級的正規化規則,我們得到了以下的資料表:
現在我們的資料表可以說已經處在第一級正規化的形式了,它已經解決了url欄位的重複問題,不過這樣的處理後又帶來了一個新的問題。每次在user表中插入一條記錄的時候,我們都必須重複所有的公司和會員資料。這樣不僅令資料庫比以前大了,而且很容易出現錯誤。因此還要經過第二級正規化處理。 第二級正規化規則
我們將url的值放在一個獨立的表格中,這樣我們就可以在以後加入更多的資料,而無需擔心產生重複的值。我們還可以透過主鍵值來關聯這些資料,分割後的資料表如下:
如上所示,我們建立了獨立的urls資料表,users資料表中的主鍵值userid現在與url資料表中的 relUserId(foreign key)關聯。現在的情形好像已經得到了明顯的改善。不過,如果我們要為公司加入一筆員工資料呢?或者更多,200個?這樣我們就必須重複的使用公司名稱和地址,這明顯不夠簡潔。因此我們將使用第三級正規化規則: 第三級正規化規則 1.消除與主鍵值沒有關係的欄位 company及company_address與Userd都是沒有關係的,因此應該將它們獨立出來建立一個資料表:
這樣我們就將company資料表中的主鍵值companyid和user資料表中名字為Companyid的資料關聯起來,就算要為同一家公司加入200個員工的資料,在company中也只有一筆資料。我們的user和url資料表可以不斷地擴大,而無需擔心加入重複的資料。大部分的開發者都認為經過三步的正規化分析就足夠了,這個資料庫的設計已經可以很方便地處理整個企業的負擔,這個想法在大多數的情況下雖然是正確的。 希望這篇文章對你有用,並且可以幫助你在所有的項目中應用這些正規化的規定。你可能想知道這些方法是從哪來的,我可以告訴你,這三個正規化的規定是1972年,Dr. E.F. Codd在他的論文“進一步正規化資料庫的關係模型中”提出的。其實另外還有更高級的兩個正規化是經過後來的集合理論和關係數學家理論化而成的,但是其時候價值並不高在此我們就不討論。 |
- Jul 16 Wed 2008 11:03
[推薦]資料庫正規化和設計技巧
close
全站熱搜
留言列表