資料庫設計---正規化

資料庫設計第一正規化
在動態網站的設計中，資料庫設計的重要性不言而喻。如果設計不當,查詢起來就非常吃力，程式的效能也會受到影響。無論你使用的是mySQL 或者Oracle 資料庫，透過進行正規化的表格設計，可以令你的PHP 程式碼更具可讀性，更容易擴充套件，從而也會提升應用的效能。

簡單說來，正規化就是在表格設計時，消除冗餘性和不協調的從屬關係。在本文中，我將透過五個漸進的過程來告訴你在設計中應該瞭解的正規化技巧。從而建立一個可行而且效率高的資料庫。本文也會詳細分析一下可以利用的關係型別。

這裡假定我們要建立一個使用者資訊的表格，其中要儲存使用者的名字、公司、公司地址和一些個人的收藏夾或url 。在開始時，你可能定義一個如下的表格結構：

零狀態形式


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


由於沒有進行任何的正規化處理，我們將這種形式的表稱為零狀態形式的表。留意其中的url1 和url2 欄位---如果我們在應用中需要第三個url 呢？這樣你就要在表格中多加一列，很明顯，這不是一個好辦法。如果你要建立一個富有擴充套件性的系統，你就要考慮使用第一個正規化的形式，並且應用到該表格中。

第一級正規化形式
1. 消除每個表格中重複的組
2. 為每套相關的資料建立一個獨立的表格
3. 使用一個主鍵來標識每套相關的資料

以上的表格明顯違反了上面第一條的規定，那麼第三條的主鍵又是什麼意思呢？很簡單，它只是在每個記錄中加入一個唯一的、自動增加的整型值。透過這個值，就可以將兩個姓名一樣的記錄區分開來。透過應用第一級正規化形式，我們得到了以下的表格：

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


現在我們的表格可以說已經處在第一級正規化的形式了，它已經解決了url 欄位的限制問題，不過這樣的處理後又帶來了一個新的問題。每次在users 表中插入一條記錄的時候，我們都必須重複所有的公司和使用者資料。這樣不僅令資料庫比以前大了，而且很容易出錯。因此還要經過第二級正規化處理

資料庫設計二三正規化
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 現在與urls 表中的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 輸入，或者更多一點。這種情況下，我們的資料庫還可以進行下一級別的最佳化--第四步，對於大多數的開發者來說，這一步都是忽略的，因為它要依賴一個很特別的關係--一個多對多的關係，這在我們的應用中是還沒有遇到過的.

資料庫設計四正規化，五正規化
在定義第四個正規化的形式前，我想首先提一下三種基本的資料關係：一對一，一對多和多對多。我們回頭看一下經過第一個正規化的users 表。要是我們將url 的欄位放在一個獨立的表中，每次在users 表中插入一個記錄，我們就會在urls 表中插入一行。我們將得到一個一對一的關係：使用者表中的每一行，都將在urls 表中找到相應的一行。對於我們的應用來說，這既不實用也不標準。

然後看看第二個正規化的例子。對於每個使用者記錄，我們的表格允許有多個urls 的記錄與之關聯。這是一個一對多的關係，這是一個很常見的關係。

對於多對多的關係來說，就有點複雜了。在我們的第三個正規化形式的例子中，我們的一個使用者與很多的url 有關，而我們想將該結構變為允許多個使用者與多個的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


為了進一步減低資料的冗餘，我們運用第四級正規化形式。我們建立了一個頗奇怪的url_relations 表，裡面的欄位均為主鍵或者foreign key 。透過這個表，我們就可以消除urls 表中的重複專案。以下是第四個正規化形式的具體要求：

第四個正規化形式

1. 在一個多對多的關係中，獨立的實體不能存放在同一個表格中
由於它僅應用於多對多的關係，因此大多數的開發者可以忽略這條規定。不過在某些情況下，它是非常實用的，這個例子就是這樣，我們透過將相同的實體分離出來，並且將關係移到它們自己的表格中，從而改進了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


第五級正規化形式

還有一級正規化的形式，它並不常見，有點深奧，並且在大部分的情況下都是不必要的。它的原則是：
1. 原來的表格必須可以透過由它分離出去的表格重新構建
使用這個規定的好處是，你可以確保不會在分離的表格中引入多餘的列，所有你建立的表格結構都與它們的實際需要一樣大。應用這條規定是一個好習慣，不過除非你要處理一個非常大型的資料，否則你將不需要用到它。

希望這篇文章對你有用，並且可以幫助你在所有的專案中應用這些正規化的規定。你可能想知道這些方法是從哪來的，我可以告訴你，前面三個正規化的規定是1972 年，Dr. E.F. Codd 在他的論文“進一步正規化資料庫的關係模型中”提出的，其餘的規定是經過後來的集合理論和關係數學家理論化的。

評論：正所謂物級必反，將表格分得過細有時並不好，因為這樣需要將各表進行各種的關聯，這會令查詢時變得複雜，而且效率也可能降低，這些正規化的規定可以參考，在實際應用時，要根據專案的大小，必要時可以進行一些測試，以設計出更合理的表格結構。