前言

通常情況下，可以從兩個方面來判斷資料庫設計的是否規範:

1)一是看看是否擁有大量的窄表
窄表往往對於OLTP比較合適，符合正規化設計原則

2)寬表的數量是否足夠的少。
所謂的寬表就是欄位比較多的表，包含的維度層次比較多，造成冗餘也比較多，毀正規化設計，但是利於取數統計

若符合這兩個條件，我們可以說資料庫設計的比較好.

當然這是兩個泛泛而談的指標。為了達到資料庫設計規範化的要求，一般來說，需要符合以下五個要求。

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

雖然表中允許空列，但是，空欄位是一種比較特殊的資料型別。資料庫在處理的時候，需要進行特殊的處理。如此的話，就會增加資料庫處理記錄的複雜性。當表中有比較多的空欄位時，在同等條件下，資料庫處理的效能會降低許多。

所以，雖然在資料庫表設計的時候，允許表中具有空欄位，但是，我們應該儘量避免。若確實需要的話，我們可以通過一些折中的方式，來處理這些空欄位，讓其對資料庫效能的影響降低到最少。

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

如現在有一個進銷存管理系統，這個系統中有一張產品基本資訊表中。這個產品開發有時候可以是一個人完成，而有時候又需要多個人合作才能夠完成。所以，在產品基本資訊表產品開發者這個欄位中，有時候可能需要填入多個開發者的名字。

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

為了解決這個問題，有多種實現方式。但是，若設計不合理的話在，則會導致重複的值或者列。如我們也可以這麼設計，把客戶資訊、聯絡人都放入同一張表中。為了解決多個聯絡人的問題，可以設定第一聯絡人、第一聯絡人電話、第二聯絡人、第二聯絡人電話等等。若還有第三聯絡人、第四聯絡人等等，則往往還需要加入更多的欄位。

所以，我們在資料庫設計的時候要儘量避免這種重複的值或者列的產生。筆者建議，若資料庫管理員遇到這種情況，可以改變一下策略。如把客戶聯絡人另外設定一張表。然後通過客戶ID把供應商資訊表跟客戶聯絡人資訊表連線起來。也就是說，儘量將重複的值放置到一張獨立的表中進行管理。然後通過檢視或者其他手段把這些獨立的表聯絡起來。

要求三：表中記錄應該有一個唯一的識別符號。

在資料庫表設計的時候，資料庫管理員應該養成一個好習慣，用一個ID號來唯一的標識行記錄，而不要通過名字、編號等欄位來對紀錄進行區分。每個表都應該有一個ID列，任何兩個記錄都不可以共享同一個ID值。另外，這個ID值最好有資料庫來進行自動管理，而不要把這個任務給前臺應用程式。否則的話，很容易產生ID值不統一的情況。

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

要求四：資料庫物件要有統一的字首名。

一個比較複雜的應用系統，其對應的資料庫表往往以千計。若讓資料庫管理員看到物件名就瞭解這個資料庫物件所起的作用，恐怕會比較困難。而且在資料庫物件引用的時候，資料庫管理員也會為不能迅速找到所需要的資料庫物件而頭疼。

其次，表、檢視、函式等最好也有統一的字首。如檢視可以用V為字首，而函式則可以利用F為字首。如此資料庫管理員無論是在日常管理還是物件引用的時候，都能夠在最短的時間內找到自己所需要的物件。

要求五：儘量只儲存單一實體型別的資料。

這裡將的實體型別跟資料型別不是一回事，要注意區分。這裡講的實體型別是指所需要描述物件的本身。筆者舉一個例子，估計大家就可以明白其中的內容了。如現在有一個圖書館裡系統，有圖書基本資訊、作者資訊兩個實體物件。若使用者要把這兩個實體物件資訊放在同一張表中也是可以的。如可以把表設計成圖書名字、圖書作者等等。可是如此設計的話，會給後續的維護帶來不少的麻煩。

如當後續有圖書出版時，則需要為每次出版的圖書增加作者資訊，這無疑會增加額外的儲存空間，也會增加記錄的長度。而且若作者的情況有所改變，如住址改變了以後，則還需要去更改每本書的記錄。同時，若這個作者的圖書從資料庫中全部刪除之後，這個作者的資訊也就蕩然無存了。很明顯，這不符合資料庫設計規範化的需求。

遇到這種情況時，筆者建議可以把上面這張表分解成三種獨立的表，分別為圖書基本資訊表、作者基本資訊表、圖書與作者對應表等等。如此設計以後，以上遇到的所有問題就都引刃而解了。

以上五條是在資料庫設計時達到規範化水平的基本要求。除了這些另外還有很多細節方面的要求，如資料型別、儲存過程等等。