| 導購 | 订阅 | 在线投稿
分享
 
 
 

通過進行正規化的表格設計提升應用性能

來源:互聯網  2008-06-04 06:44:56  評論

在動態網站的設計中,數據庫設計的重要性不言而喻。如果設計不當,查詢起來就非常吃力,程序的性能也會受到影響。無論你使用的是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字段的限制問題,不過這樣的處理後又帶來了一個新的問題。每次在user表中插入一條記錄的時候,我們都必須重複所有的公司和用戶數據。這樣不僅令數據庫比以前大了,而且很容易出錯。因此還要經過第二級正規化處理。

第二級正規化形式

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輸入,或者更多一點。這種情況下,我們的數據庫還可以進行下一級別的優化--第四步,對于大多數的開發者來說,這一步都是忽略的,因爲它要依賴一個很特別的關系--一個多對多的關系,這在我們的應用中是還沒有遇到過的數據關系。

在定義第四個正規化的形式前,我想首先提一下三種基本的數據關系:一對一,一對多和多對多。我們回頭看一下經過第一個正規化的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_relationsswheresurl_relations.relatedUserId = 1 AND

users.userId = 1 AND

urls.urlId = url_relations.relatedUrlId

如果我們想要遍曆每個人的個人信息和url信息,我們可以這樣做:

SELECT name, url FROM users, urls,

url_relationsswheresusers.userId =

url_relations.relatedUserId AND

urls.urlId

= url_relations.relatedUrlId

第五級正規化形式

還有一級正規化的形式,它並不常見,有點深奧,並且在大部分的情況下都是不必要的。它的原則是:

1.原來的表格必須可以通過由它分離出去的表格重新構建

使用這個規定的好處是,你可以確保不會在分離的表格中引入多余的列,所有你創建的表格結構都與它們的實際需要一樣大。應用這條規定是一個好習慣,不過除非你要處理一個非常大型的數據,否則你將不需要用到它。

希望這篇文章對你有用,並且可以幫助你在所有的項目中應用這些正規化的規定。你可能想知道這些方法是從哪來的,我可以告訴你,前面三個正規化的規定是1972年,Dr. E.F. Codd在他的論文「進一步正規化數據庫的關系模型中」提出的,其余的規定是經過後來的集合理論和關系數學家理論化的。評論:正所謂物級必反,將表格分得過細有時並不好,因爲這樣需要將各表進行各種的關聯,這會令查詢時變得複雜,而且效率也可能降低,這些正規化的規定可以參考,在實際應用時,要根據項目的大小,必要時可以進行一些測試,以設計出更合理的表格結構。

在動態網站的設計中,數據庫設計的重要性不言而喻。如果設計不當,查詢起來就非常吃力,程序的性能也會受到影響。無論你使用的是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字段的限制問題,不過這樣的處理後又帶來了一個新的問題。每次在user表中插入一條記錄的時候,我們都必須重複所有的公司和用戶數據。這樣不僅令數據庫比以前大了,而且很容易出錯。因此還要經過第二級正規化處理。 第二級正規化形式 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輸入,或者更多一點。這種情況下,我們的數據庫還可以進行下一級別的優化--第四步,對于大多數的開發者來說,這一步都是忽略的,因爲它要依賴一個很特別的關系--一個多對多的關系,這在我們的應用中是還沒有遇到過的數據關系。 在定義第四個正規化的形式前,我想首先提一下三種基本的數據關系:一對一,一對多和多對多。我們回頭看一下經過第一個正規化的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_relationsswheresurl_relations.relatedUserId = 1 AND users.userId = 1 AND urls.urlId = url_relations.relatedUrlId 如果我們想要遍曆每個人的個人信息和url信息,我們可以這樣做: SELECT name, url FROM users, urls, url_relationsswheresusers.userId = url_relations.relatedUserId AND urls.urlId = url_relations.relatedUrlId 第五級正規化形式 還有一級正規化的形式,它並不常見,有點深奧,並且在大部分的情況下都是不必要的。它的原則是: 1.原來的表格必須可以通過由它分離出去的表格重新構建 使用這個規定的好處是,你可以確保不會在分離的表格中引入多余的列,所有你創建的表格結構都與它們的實際需要一樣大。應用這條規定是一個好習慣,不過除非你要處理一個非常大型的數據,否則你將不需要用到它。 希望這篇文章對你有用,並且可以幫助你在所有的項目中應用這些正規化的規定。你可能想知道這些方法是從哪來的,我可以告訴你,前面三個正規化的規定是1972年,Dr. E.F. Codd在他的論文「進一步正規化數據庫的關系模型中」提出的,其余的規定是經過後來的集合理論和關系數學家理論化的。評論:正所謂物級必反,將表格分得過細有時並不好,因爲這樣需要將各表進行各種的關聯,這會令查詢時變得複雜,而且效率也可能降低,這些正規化的規定可以參考,在實際應用時,要根據項目的大小,必要時可以進行一些測試,以設計出更合理的表格結構。
󰈣󰈤
王朝萬家燈火計劃
期待原創作者加盟
 
 
 
>>返回首頁<<
 
 
 
 
 熱帖排行
 
 
 
靜靜地坐在廢墟上,四周的荒凉一望無際,忽然覺得,淒涼也很美
© 2005- 王朝網路 版權所有