在動態(tài)網站的設計中，數據庫設計的重要性不言而喻。如果設計不當,查詢起來就非常吃力，程序的性能也會受到影響。無論你使用的是mySQL或者Oracle數據庫，通過進行正規(guī)化的表格設計，可以令你的PHP代碼更具可讀性，更容易擴展，從而也會提升應用的性能。
簡單說來，正規(guī)化就是在表格設計時，消除冗余性和不協調的從屬關系。在本文中，我將通過五個漸進的過程來告訴你在設計中應該了解的正規(guī)化技巧。從而建立一個可行而且效率高的數據庫。本文也會詳細分析一下可以利用的關系類型。
這里假定我們要建立一個用戶信息的表格，其中要存儲用戶的名字、公司、公司地址和一些個人的收藏夾或url。在開始時，你可能定義一個如下的表格結構：
零狀態(tài)形式
[users]
| name |
company |
company_address |
url1 |
url2 |
| Joe |
ABC 1 |
Work Lane |
abc.com |
xyz.com |
| Jill |
XYZ 1 |
Job Street |
abc.com |
xyz.com |
由于沒有進行任何的正規(guī)化處理，我們將這種形式的表稱為零狀態(tài)形式的表。留意其中的url1和url2字段---如果我們在應用中需要第三個url呢？這樣你就要在表格中多加一列，很明顯，這不是一個好辦法。如果你要創(chuàng)建一個富有擴展性的系統，你就要考慮使用第一個正規(guī)化的形式，并且應用到該表格中。
第一級正規(guī)化形式
1．消除每個表格中重復的組
2．為每套相關的數據建立一個獨立的表格
3．使用一個主鍵來標識每套相關的數據
以上的表格明顯違反了上面第一條的規(guī)定，那么第三條的主鍵又是什么意思呢？很簡單，它只是在每個記錄中加入一個唯一的、自動增加的整型值。通過這個值，就可以將兩個姓名一樣的記錄區(qū)分開來。通過應用第一級正規(guī)化形式，我們得到了以下的表格：
[users]
| userId |
name |
company |
company_address |
url |
| 1 |
Joe |
ABC 1 |
Work Lane |
abc.com |
| 1 |
Joe |
ABC 1 |
Work Lane |
xyz.com |
| 2 |
Jill |
XYZ 1 |
Job Street |
abc.com |
| 2 |
Jill |
XYZ 1 |
Job Street |
xyz.com |
現在我們的表格可以說已經處在第一級正規(guī)化的形式了，它已經解決了url字段的限制問題，不過這樣的處理后又帶來了一個新的問題。每次在user表中插入一條記錄的時候，我們都必須重復所有的公司和用戶數據。這樣不僅令數據庫比以前大了，而且很容易出錯。因此還要經過第二級正規(guī)化處理。
第二級正規(guī)化形式
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 |
如上所示，我們創(chuàng)建了獨立的表格，users表中的主鍵userid現在與url表中的foreign key relUserId關聯�，F在的情況好象已經得到了明顯的改善。不過，如果我們要為ABC公司加入一個員工記錄呢？或者更多，200個？這樣我們就必須重復使用公司名和地址，這明顯不夠冗余。因此我們將應用第三級正規(guī)化方法：
第三級正規(guī)化形式
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表可以不斷地擴大，而無需擔心插入不必要的數據。大部分的開發(fā)者都認為經過三步的正規(guī)化就足夠了，這個數據庫的設計已經可以很方便地處理整個企業(yè)的負擔，此看法在大多數的情況下是正確的。
我們可以留意一下url的字段--你注意到數據的冗余了嗎？如果給用戶用戶輸入這些url數據的HTML頁面是一個文本框，可任意輸入的話，這并沒有問題，兩個用戶輸入同樣收藏夾的概率較少，不過，如果是通過一個下拉式的菜單，只讓用戶選擇兩個url輸入，或者更多一點。這種情況下，我們的數據庫還可以進行下一級別的優(yōu)化--第四步，對于大多數的開發(fā)者來說，這一步都是忽略的，因為它要依賴一個很特別的關系--一個多對多的關系，這在我們的應用中是還沒有遇到過的。
數據關系
在定義第四個正規(guī)化的形式前，我想首先提一下三種基本的數據關系：一對一，一對多和多對多。我們回頭看一下經過第一個正規(guī)化的users表。要是我們將url的字段放在一個獨立的表中，每次在users表中插入一個記錄，我們就會在urls表中插入一行。我們將得到一個一對一的關系：用戶表中的每一行，都將在urls表中找到相應的一行。對于我們的應用來說，這既不實用也不標準。
然后看看第二個正規(guī)化的例子。對于每個用戶記錄，我們的表格允許有多個urls的記錄與之關聯。這是一個一對多的關系，這是一個很常見的關系。
對于多對多的關系來說，就有點復雜了。在我們的第三個正規(guī)化形式的例子中，我們的一個用戶與很多的url有關，而我們想將該結構變?yōu)樵试S多個用戶與多個的urls有關，這樣我們就可以得到一個多對多的結構。在討論前，我們先看看表格結構會有些什么變化
[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 |
url |
| 1 |
abc.com |
| 2 |
xyz.com |
[url_relations]
| relationId |
relatedUrlId |
relatedUserId |
| 1 |
1 |
1 |
| 2 |
1 |
2 |
| 3 |
2 |
1 |
| 4 |
2 |
2 |
為了進一步減低數據的冗余，我們運用第四級正規(guī)化形式。我們創(chuàng)建了一個頗奇怪的url_relations表，里面的字段均為主鍵或者foreign key。通過這個表，我們就可以消除urls表中的重復項目。以下是第四個正規(guī)化形式的具體要求：
第四個正規(guī)化形式
1．在一個多對多的關系中，獨立的實體不能存放在同一個表格中
由于它僅應用于多對多的關系，因此大多數的開發(fā)者可以忽略這條規(guī)定。不過在某些情況下，它是非常實用的，這個例子就是這樣，我們通過將相同的實體分離出來，并且將關系移到它們自己的表格中，從而改進了urls表格。
為了令你更容易明白，我們舉個具體的例子，以下將用一個SQL語句選擇出所有屬于joe的urls：
SELECT name, url FROM users, urls, url_relations WHERE url_relations.relatedUserId = 1 AND users.userId = 1 AND urls.urlId = url_relations.relatedUrlId
如果我們想要遍歷每個人的個人信息和url信息，我們可以這樣做：
SELECT name, url FROM users, urls, url_relations WHERE users.userId = url_relations.relatedUserId AND urls.urlId = url_relations.relatedUrlId
第五級正規(guī)化形式
還有一級正規(guī)化的形式，它并不常見，有點深奧，并且在大部分的情況下都是不必要的。它的原則是：
1．原來的表格必須可以通過由它分離出去的表格重新構建
使用這個規(guī)定的好處是，你可以確保不會在分離的表格中引入多余的列，所有你創(chuàng)建的表格結構都與它們的實際需要一樣大。應用這條規(guī)定是一個好習慣，不過除非你要處理一個非常大型的數據，否則你將不需要用到它。
希望這篇文章對你有用，并且可以幫助你在所有的項目中應用這些正規(guī)化的規(guī)定。你可能想知道這些方法是從哪來的，我可以告訴你，前面三個正規(guī)化的規(guī)定是1972年，Dr. E.F. Codd在他的論文“進一步正規(guī)化數據庫的關系模型中”提出的，其余的規(guī)定是經過后來的集合理論和關系數學家理論化的。 評論：正所謂物級必反，將表格分得過細有時并不好，因為這樣需要將各表進行各種的關聯，這會令查詢時變得復雜，而且效率也可能降低，這些正規(guī)化的規(guī)定可以參考，在實際應用時，要根據項目的大小，必要時可以進行一些測試，以設計出更合理的表格結構。
出處：天極網
責任編輯：風狗
◎進入論壇網絡編程版塊參加討論
|
