2008-07-16 11:03 [推薦]資料庫正規化和設計技巧
?SQL 好文轉寄 平均分數:0 顆星 投票人數:0 人
我要評分:
資料庫正規化和設計技巧 |
<> 隨著各種互動式網站的設計(ASP、PHP、JSP)越來越盛行,資料庫設計的重要性不言而喻。今天我就來和大家談一談資料庫的正規化以及設計技巧。
在互動式動態網站的設計中,資料庫的規劃以及設計可以說是一切的根本,如果資料庫的設計不當,程式在對資料庫進行各項操作時就會顯得非常吃力,效能也會受到影響。所以無論你使用的是SQL SERVER或者Oracle資料庫,透過正規化的資料表設計,可以使你的程式更具可讀性,更易於維護,也會提升網站整體的效能。
簡單說來,正規化就是在資料表設計時,消除重複性和不協調的從屬關系。在本文中,我將透過五個循序漸進的過程來告訴你在資料表設計時應該了解的正規化技巧進而建立一個可行而且效率高的資料庫。 現在假設我們要建立一個會員資料的資料表,其中要儲存會員的姓名、公司、公司地址和一些個人網站的網址。
首先,你可能定義一個如下的表格結構: 零狀態形式 >|
| USER資料表 | | 欄位名稱 | 資料型態 | | name | CHAR(50) | | company | CHAR(50) | | company_address | CHAR(150) | | url1 | CHAR(150) | | url2 | CHAR(150) |
由於沒有進行任何的正規化處理,我們將這種形式的表稱為零狀態形式的表。留意其中的url1和url2欄位---如果我們在應用中需要第三個url呢?這樣你就要在表格中多加一列,很明顯,這不是一個好辦法。如果你要建立一個具有擴充性的系統,你就要考慮使用第一個正規化的形式,並且應用到這個資料表中。 第一級正規化規則 - 消除每個資料表中同類型的欄位
- 為每個相關的資料建立一個獨立的資料表
- 使用一個主鍵值(KEY)來識別每一筆資料
以上的資料表明顯的違反了上面第一條的規定,那麼第三項中的主鍵值(KEY)又是什麼意思呢?其實很簡單,它只是在每筆資料中加入一個唯一的、且自動增加的整數值。透過這個值,就可以將兩個姓名一樣的資料區分出來。透過第一級的正規化規則,我們得到了以下的資料表: | USER資料表 | | 欄位名稱 | 資料型態 | | userid | IDENTITY | | name | CHAR(50) | | company | CHAR(50) | | company_address | CHAR(150) | | url | CHAR(150) |
現在我們的資料表可以說已經處在第一級正規化的形式了,它已經解決了url欄位的重複問題,不過這樣的處理後又帶來了一個新的問題。每次在user表中插入一條記錄的時候,我們都必須重複所有的公司和會員資料。這樣不僅令資料庫比以前大了,而且很容易出現錯誤。因此還要經過第二級正規化處理。
第二級正規化規則 - 為將會重複出現的欄位資料建立一個獨立的資料表
- 透過一個foreign key來關聯這些資料表的資料
我們將url的值放在一個獨立的表格中,這樣我們就可以在以後加入更多的資料,而無需擔心產生重複的值。我們還可以透過主鍵值來關聯這些資料,分割後的資料表如下: | USER資料表 | | 欄位名稱 | 資料型態 | | userid | IDENTITY | | name | CHAR(50) | | company | CHAR(50) | | company_address | CHAR(150) |
| URL資料表 | | 欄位名稱 | 資料型態 | | urlid | IDENTITY | | userid | INT | | url | CHAR(150) |
如上所示,我們建立了獨立的urls資料表,users資料表中的主鍵值userid現在與url資料表中的 relUserId(foreign key)關聯。現在的情形好像已經得到了明顯的改善。不過,如果我們要為公司加入一筆員工資料呢?或者更多,200個?這樣我們就必須重複的使用公司名稱和地址,這明顯不夠簡潔。因此我們將使用第三級正規化規則: 第三級正規化規則 1.消除與主鍵值沒有關係的欄位 company及company_address與Userd都是沒有關係的,因此應該將它們獨立出來建立一個資料表: | USER資料表 | | 欄位名稱 | 資料型態 | | userid | IDENTITY | | name | CHAR(50) | | companyid | INT |
| URL資料表 | | 欄位名稱 | 資料型態 | | urlid | IDENTITY | | reluserid | INT | | url | CHAR(150) |
| COMPANY資料表 | | 欄位名稱 | 資料型態 | | companyid | IDENTITY | | company | CHAR(50) | | company_address | CHAR(150) |
這樣我們就將company資料表中的主鍵值companyid和user資料表中名字為Companyid的資料關聯起來,就算要為同一家公司加入200個員工的資料,在company中也只有一筆資料。我們的user和url資料表可以不斷地擴大,而無需擔心加入重複的資料。大部分的開發者都認為經過三步的正規化分析就足夠了,這個資料庫的設計已經可以很方便地處理整個企業的負擔,這個想法在大多數的情況下雖然是正確的。 希望這篇文章對你有用,並且可以幫助你在所有的項目中應用這些正規化的規定。你可能想知道這些方法是從哪來的,我可以告訴你,這三個正規化的規定是1972年,Dr. E.F. Codd在他的論文“進一步正規化資料庫的關係模型中”提出的。其實另外還有更高級的兩個正規化是經過後來的集合理論和關係數學家理論化而成的,但是其時候價值並不高在此我們就不討論。
不過正所謂物極必反,將表格分得過細有時並不是最好的,因為這樣需要將各表進行各種的關聯,反而會令查詢時變得更為複雜,而且效率也可能降低,所以在實際應用時,必須要根據項目的大小,以及各種情況來作運用,必要時可以進行一些測試,以設計出更合理的資料庫結構。 |
