通常情況下,可以從兩個方面來判斷資料庫是否設計的比較規範。一是看看是否擁有大量的窄表,二是寬表的數量是否足夠的少。若符合這兩個條件,則可以說明這個資料庫的正常化水平還是比較高的。當然這是兩個泛泛而談的指標。為了達到資料庫設計正常化的要求,一般來說,需要符合以下五個要求。
要求一:表中應該避免可為空白的列。
雖然表中允許空列,但是,空欄位是一種比較特殊的資料類型。資料庫在處理的時候,需要進行特殊的處理。如此的話,就會增加資料庫處理記錄的複雜性。當表中有比較多的空欄位時,在同等條件下,資料庫處理的效能會降低許多。
所以,雖然在資料庫表設計的時候,允許表中具有空欄位,但是,我們應該盡量避免。若確實需要的話,我們可以通過一些折中的方式,來處理這些空欄位,讓其對資料庫效能的影響降低到最少。
一是通過設定預設值的形式,來避免空欄位的產生。如在一個人事管理系統中,有時候社會安全號碼碼欄位可能允許為空白。因為不是每個人都可以記住自己的社會安全號碼碼。而在員工報到的時候,可能身份證沒有帶在身邊。所以,社會安全號碼碼欄位往往不能及時提供。為此,社會安全號碼碼欄位可以允許為空白,以滿足這些特殊情況的需要。但是,在資料庫設計的時候,則可以做一些處理。如當使用者沒有輸入內容的時候,則把這個欄位的預設值設定為0或者為N/A。以避免空欄位的產生。
二是若一張表中,允許為空白的列比較多,接近表全部列數的三分之一。而且,這些列在大部分情況下,都是可有可無的。若資料庫管理員遇到這種情況,筆者建議另外建立一張副表,以儲存這些列。然後通過關鍵字把主表跟這張副表關聯起來。將資料存放區在兩個獨立的表中使得主表的設計更為簡單,同時也能夠滿足儲存空值資訊的需要。
要求二:表不應該有重複的值或者列。
如現在有一個進銷存管理系統,這個系統中有一張產品基本資料表中。這個產品開發有時候可以是一個人完成,而有時候又需要多個人合作才能夠完成。所以,在產品基本資料表產品開發人員這個欄位中,有時候可能需要填入多個開發人員的名字。
如進銷存管理中,還需要對客戶的連絡人進行管理。有時候,企業可能只知道客戶一個採購員的姓名。但是在必要的情況下,企業需要對客戶的採購代表、倉庫人員、財務人員共同進行管理。因為在訂單上,可能需要填入採購代表的名字;可是在出貨單上,則需要填入倉庫管理員的名字等等。
為瞭解決這個問題,有多種實現方式。但是,若設計不合理的話在,則會導致重複的值或者列。如我們也可以這麼設計,把客戶資訊、連絡人都放入同一張表中。為瞭解決多個連絡人的問題,可以設定第一連絡人、第一連絡人電話、第二連絡人、第二連絡人電話等等。若還有第三連絡人、第四連絡人等等,則往往還需要加入更多的欄位。
可是這麼設計的話,會產生一系列的問題。如客戶的採購員流動性比較大,在一年內換了六個採購員。此時,在系統中該如何管理呢?難道就建立六個連絡人欄位?這不但會導致空欄位的增加,還需要頻繁的更改資料庫表結構。明顯,這麼做是不合理的。也有人說,可以直接修改採購員的名字呀。可是這麼處理的話,會把原先採購訂單上採購員的名字也改變了。因為採購單上客戶採購員資訊在資料庫中儲存的不是採購員的名字,而只是採購員對應的一個編號。在編號不改而名字改變了的情況下,採購訂單上顯示的就是更改後的名字。這不利於時候的追蹤。
所以,在資料庫設計的時候要盡量避免這種重複的值或者列的產生。筆者建議,若資料庫管理員遇到這種情況,可以改變一下策略。如把客戶連絡人另外設定一張表。然後通過客戶ID把供應商資訊表跟客戶連絡人資訊表串連起來。也就是說,盡量將重複的值放置到一張獨立的表中進行管理。然後通過視圖或者其他手段把這些獨立的表聯絡起來。
要求三:表中記錄應該有一個唯一的標識符。
在資料庫表設計的時候,資料庫管理員應該養成一個好習慣,用一個ID號來唯一的標識行記錄,而不要通過名字、編號等欄位來對紀錄進行區分。每個表都應該有一個ID列,任何兩個記錄都不可以共用同一個ID值。另外,這個ID值最好有資料庫來進行自動管理,而不要把這個任務給前台應用程式。否則的話,很容易產生ID值不統一的情況。
另外,在資料庫設計的時候,最好還能夠加入行號。如在銷售訂單管理中,ID號是使用者不能夠維護的。但是,行號使用者就可以維護。如在銷售訂單的行中,使用者可以通過調整行號的大小來對訂單行進行排序。通常情況下,ID列是以1為單位遞進的。但是,行號就要以10為單位累進。如此,正常情況下,行號就以10、20、30依次擴充下去。若此時使用者需要把行號為30的紀錄調到第一行顯示。此時,使用者在不能夠更改ID列的情況下,可以更改行號來實現。如可以把行號改為1,在排序時就可以按行號來進行排序。如此的話,原來行號為30的紀錄現在行號變為了1,就可以在第一行中顯示。這是在實際應用程式設計中對ID列的一個有效補充。這個內容在教科書上是沒有的。需要在實際應用程式設計中,才會掌握到這個技巧。