數據庫設計規範化的五個要求(轉載)

一般狀況下，能夠從兩個方面來判斷數據庫是否設計的比較規範。一是看看是否擁有大量的窄表，二是寬表的數量是否足夠的少。若符合這兩個條件，則能夠說明這個數據庫的規範化水平仍是比較高的。固然這是兩個泛泛而談的指標。爲了達到數據庫設計規範化的要求，通常來講，須要符合如下五個要求。

　　要求一：表中應該避免可爲空的列。

　　雖然表中容許空列，可是，空字段是一種比較特殊的數據類型。數據庫在處理的時候，須要進行特殊的處理。如此的話，就會增長數據庫處理記錄的複雜性。當表中有比較多的空字段時，在同等條件下，數據庫處理的性能會下降許多。

　　因此，雖然在數據庫表設計的時候，容許表中具備空字段，可是，咱們應該儘可能避免。若確實須要的話，咱們能夠經過一些折中的方式，來處理這些空字段，讓其對數據庫性能的影響下降到最少。

　　一是經過設置默認值的形式，來避免空字段的產生。如在一我的事管理系統中，有時候身份證號碼字段可能容許爲空。由於不是每一個人均可以記住本身的身份證號碼。而在員工報到的時候，可能身份證沒有帶在身邊。因此，身份證號碼字段每每不能及時提供。爲此，身份證號碼字段能夠容許爲空，以知足這些特殊狀況的須要。可是，在數據庫設計的時候，則能夠作一些處理。如當用戶沒有輸入內容的時候，則把這個字段的默認值設置爲0或者爲N/A。以免空字段的產生。

　　二是若一張表中，容許爲空的列比較多，接近表所有列數的三分之一。並且，這些列在大部分狀況下，都是無關緊要的。若數據庫管理員遇到這種狀況，筆者建議另外創建一張副表，以保存這些列。而後經過關鍵字把主表跟這張副表關聯起來。將數據存儲在兩個獨立的表中使得主表的設計更爲簡單，同時也可以知足存儲空值信息的須要。

　　要求二：表不該該有重複的值或者列。

　　如如今有一個進銷存管理系統，這個系統中有一張產品基本信息表中。這個產品開發有時候能夠是一我的完成，而有時候又須要多我的合做纔可以完成。因此，在產品基本信息表產品開發者這個字段中，有時候可能須要填入多個開發者的名字。

　　如進銷存管理中，還須要對客戶的聯繫人進行管理。有時候，企業可能只知道客戶一個採購員的姓名。可是在必要的狀況下，企業須要對客戶的採購表明、倉庫人員、財務人員共同進行管理。由於在訂單上，可能須要填入採購表明的名字;但是在出貨單上，則須要填入倉庫管理人員的名字等等。

　　爲了解決這個問題，有多種實現方式。可是，若設計不合理的話在，則會致使重複的值或者列。如咱們也能夠這麼設計，把客戶信息、聯繫人都放入同一張表中。爲了解決多個聯繫人的問題，能夠設置第一聯繫人、第一聯繫人電話、第二聯繫人、第二聯繫人電話等等。若還有第三聯繫人、第四聯繫人等等，則每每還須要加入更多的字段。

　　但是這麼設計的話，會產生一系列的問題。如客戶的採購員流動性比較大，在一年內換了六個採購員。此時，在系統中該如何管理呢?難道就創建六個聯繫人字段?這不但會致使空字段的增長，還須要頻繁的更改數據庫表結構。明顯，這麼作是不合理的。也有人說，能夠直接修改採購員的名字呀。但是這麼處理的話，會把原先採購訂單上採購員的名字也改變了。由於採購單上客戶採購員信息在數據庫中存儲的不是採購員的名字，而只是採購員對應的一個編號。在編號不改而名字改變了的狀況下，採購訂單上顯示的就是更改後的名字。這不利於時候的追蹤。

　　因此，在數據庫設計的時候要儘可能避免這種重複的值或者列的產生。筆者建議，若數據庫管理員遇到這種狀況，能夠改變一下策略。如把客戶聯繫人另外設置一張表。而後經過客戶ID把供應商信息表跟客戶聯繫人信息錶鏈接起來。也就是說，儘可能將重複的值放置到一張獨立的表中進行管理。而後經過視圖或者其餘手段把這些獨立的表聯繫起來。

要求三：表中記錄應該有一個惟一的標識符。

　　在數據庫表設計的時候，數據庫管理員應該養成一個好習慣，用一個ID號來惟一的標識行記錄，而不要經過名字、編號等字段來對紀錄進行區分。每一個表都應該有一個ID列，任何兩個記錄都不能夠共享同一個ID值。另外，這個ID值最好有數據庫來進行自動管理，而不要把這個任務給前臺應用程序。不然的話，很容易產生ID值不統一的狀況。

　　另外，在數據庫設計的時候，最好還可以加入行號。如在銷售訂單管理中，ID號是用戶不可以維護的。可是，行號用戶就能夠維護。如在銷售訂單的行中，用戶能夠經過調整行號的大小來對訂單行進行排序。一般狀況下，ID列是以1爲單位遞進的。可是，行號就要以10爲單位累進。如此，正常狀況下，行號就以十、20、30依次擴展下去。若此時用戶須要把行號爲30的紀錄調到第一行顯示。此時，用戶在不可以更改ID列的狀況下，能夠更改行號來實現。如能夠把行號改成1，在排序時就能夠按行號來進行排序。如此的話，原來行號爲30的紀錄如今行號變爲了1，就能夠在第一行中顯示。這是在實際應用程序設計中對ID列的一個有效補充。這個內容在教科書上是沒有的。須要在實際應用程序設計中，纔會掌握到這個技巧。

　　要求四：數據庫對象要有統一的前綴名。

　　一個比較複雜的應用系統，其對應的數據庫表每每以千計。若讓數據庫管理員看到對象名就瞭解這個數據庫對象所起的做用，恐怕會比較困難。並且在數據庫對象引用的時候，數據庫管理員也會爲不能迅速找到所須要的數據庫對象而頭疼。

　　爲此，筆者創建，在開發數據庫以前，最好可以花必定的時間，去制定一個數據庫對象的前綴命名規範。如筆者在數據庫設計時，喜歡跟前臺應用程序協商，肯定合理的命名規範。筆者最經常使用的是根據前臺應用程序的模塊來定義後臺數據庫對象前綴名。如跟物料管理模塊相關的表能夠用M爲前綴;而以訂單管理相關的，則能夠利用C做爲前綴。具體採用什麼前綴能夠以用戶的愛好而定義。可是，須要注意的是，這個命名規範應該在數據庫管理員與前臺應用程序開發者之間達成共識，而且嚴格按照這個命名規範來定義對象名。

　　其次，表、視圖、函數等最好也有統一的前綴。如視圖能夠用V爲前綴，而函數則能夠利用F爲前綴。如此數據庫管理員不管是在平常管理仍是對象引用的時候，都可以在最短的時間內找到本身所須要的對象。

　　要求五：儘可能只存儲單一實體類型的數據。

　　這裏將的實體類型跟數據類型不是一回事，要注意區分。這裏講的實體類型是指所須要描述對象的自己。筆者舉一個例子，估計你們就能夠明白其中的內容了。如如今有一個圖書館裏系統，有圖書基本信息、做者信息兩個實體對象。若用戶要把這兩個實體對象信息放在同一張表中也是能夠的。如能夠把表設計成圖書名字、圖書做者等等。但是如此設計的話，會給後續的維護帶來很多的麻煩。

　　如當後續有圖書出版時，則須要爲每次出版的圖書增長做者信息，這無疑會增長額外的存儲空間，也會增長記錄的長度。並且若做者的狀況有所改變，如住址改變了之後，則還須要去更改每本書的記錄。同時，若這個做者的圖書從數據庫中所有刪除以後，這個做者的信息也就蕩然無存了。很明顯，這不符合數據庫設計規範化的需求。

　　遇到這種狀況時，筆者建議能夠把上面這張表分解成三種獨立的表，分別爲圖書基本信息表、做者基本信息表、圖書與做者對應表等等。如此設計之後，以上遇到的全部問題就都引刃而解了。

　　以上五條是在數據庫設計時達到規範化水平的基本要求。除了這些另外還有不少細節方面的要求，如數據類型、存儲過程等等。並且，數據庫規範每每沒有技術方面的嚴格限制，主要依靠數據庫管理員平常工做經驗的累積。

 

原文地址http://space.itpub.net/7698721