通常情況下，可以從兩個方面來判斷資料庫是否設計的比較規範。一是看看是否擁有大量的窄表，二是寬表的數量是否足夠的少。若符合這兩個條件，則可以說明這個資料庫的規範化水平還是比較高的。
當然這是兩個泛泛而談的指標。為了達到資料庫設計規範化的要求，一般來說，需要符合以下五個要求。
要求一：表中應該避免可為空的列
雖然表中允許空列，但是，空字段是一種比較特殊的資料型別。資料庫在處理的時候，需要進行特殊的處理。如此的話，就會增加資料庫處理記錄的複雜性。
當表中有比較多的空字段時，在同等條件下，資料庫處理的效能會降低許多。
所以，雖然在資料庫表設計的時候，允許表中具有空欄位，但是，我們應該盡量避免。若確實需要的話，我們可以通過一些折中的方式，來處理這些空欄位，讓其對資料庫效能的影響降低到最少。
一是通過設定預設值的形式，來避免空字段的產生。如在乙個人事管理系統中，有時候身份證號碼字段可能允許為空。因為不是每個人都可以記住自己的身份證號碼。
而在員工報到的時候，可能身份證沒有帶在身邊。所以，身份證號碼字段往往不能及時提供。為此，身份證號碼字段可以允許為空，以滿足這些特殊情況的需要。
但是，在資料庫設計的時候，則可以做一些處理。如當使用者沒有輸入內容的時候，則把這個欄位的預設值設定為0或者為n/a。以避免空字段的產生。
二是若一張表中，允許為空的列比較多，接近表全部列數的三分之一。而且，這些列在大部分情況下，都是可有可無的。若資料庫管理員遇到這種情況，筆者建議另外建立一張副表，以儲存這些列。
然後通過關鍵字把主表跟這張副表關聯起來。將資料儲存在兩個獨立的表中使得主表的設計更為簡單，同時也能夠滿足儲存空值資訊的需要。
要求二：表不應該有重複的值或者列
如現在有乙個進銷存管理系統，這個系統中有一張產品基本資訊表中。這個產品開發有時候可以是乙個人完成，而有時候又需要多個人合作才能夠完成。所以，在產品基本資訊表產品開發者這個欄位中，有時候可能需要填入多個開發者的名字。
如進銷存管理中，還需要對客戶的聯絡人進行管理。有時候，企業可能只知道客戶乙個採購員的姓名。但是在必要的情況下，企業需要對客戶的採購代表、倉庫人員、財務人員共同進行管理。
因為在訂單上，可能需要填入採購代表的名字;可是在出貨單上，則需要填入倉庫管理人員的名字等等。
為了解決這個問題，有多種實現方式。但是，若設計不合理的話在，則會導致重複的值或者列。如我們也可以這麼設計，把客戶資訊、聯絡人都放入同一張表中。
為了解決多個聯絡人的問題，可以設定第一聯絡人、第一聯絡人**、第二聯絡人、第二聯絡人**等等。若還有第三聯絡人、第四聯絡人等等，則往往還需要加入更多的字段。
可是這麼設計的話，會產生一系列的問題。如客戶的採購員流動性比較大，在一年內換了六個採購員。此時，在系統中該如何管理呢?
難道就建立六個聯絡人字段?這不但會導致空字段的增加，還需要頻繁的更改資料庫表結構。明顯，這麼做是不合理的。
也有人說，可以直接修改採購員的名字呀。可是這麼處理的話，會把原先採購訂單上採購員的名字也改變了。因為採購單上客戶採購員資訊在資料庫中儲存的不是採購員的名字，而只是採購員對應的乙個編號。
在編號不改而名字改變了的情況下，採購訂單上顯示的就是更改後的名字。這不利於時候的追蹤。
所以，在資料庫設計的時候要盡量避免這種重複的值或者列的產生。筆者建議，若資料庫管理員遇到這種情況，可以改變一下策略。如把客戶聯絡人另外設定一張表。
然後通過客戶id把**商資訊表跟客戶聯絡人資訊表連線起來。也就是說，盡量將重複的值放置到一張獨立的表中進行管理。然後通過檢視或者其他手段把這些獨立的表聯絡起來。
要求三：表中記錄應該有乙個唯一的識別符號
在資料庫表設計的時候，資料庫管理員應該養成乙個好習慣，用乙個id號來唯一的標識行記錄，而不要通過名字、編號等字段來對紀錄進行區分。每個表都應該有乙個id列，任何兩個記錄都不可以共享同乙個id值。另外，這個id值最好有資料庫來進行自動管理，而不要把這個任務給前台應用程式。
否則的話，很容易產生id值不統一的情況。
另外，在資料庫設計的時候，最好還能夠加入行號。如在銷售訂單管理中，id號是使用者不能夠維護的。但是，行號使用者就可以維護。
如在銷售訂單的行中，使用者可以通過調整行號的大小來對訂單行進行排序。通常情況下，id列是以1為單位遞進的。但是，行號就要以10為單位累進。
如此，正常情況下，行號就以10、20、30依次擴充套件下去。若此時使用者需要把行號為30的紀錄調到第一行顯示。此時，使用者在不能夠更改id列的情況下，可以更改行號來實現。
如可以把行號改為1，在排序時就可以按行號來進行排序。如此的話，原來來行號為30的紀錄現在行號變為了1，就可以在第一行中顯示。這是在實際應用程式設計中對id列的乙個有效補充。
這個內容在教科書上是沒有的。需要在實際應用程式設計中，才會掌握到這個技巧。
要求四：資料庫物件要有統一的字首名
乙個比較複雜的應用系統，其對應的資料庫表往往以千計。若讓資料庫管理員看到物件名就了解這個資料庫物件所起的作用，恐怕會比較困難。而且在資料庫物件引用的時候，資料庫管理員也會為不能迅速找到所需要的資料庫物件而頭疼。
為此，筆者建立，在開發資料庫之前，最好能夠花一定的時間，去制定乙個資料庫物件的字首命名規範。如筆者在資料庫設計時，喜歡跟前臺應用程式協商，確定合理的命名規範。筆者最常用的是根據前台應用程式的模組來定義後台資料庫物件字首名。
如跟物料管理模組相關的表可以用m為字首;而以訂單管理相關的，則可以利用c作為字首。具體採用什麼字首可以以使用者的愛好而定義。但是，需要注意的是，這個命名規範應該在資料庫管理員與前台應用程式開發者之間達成共識，並且嚴格按照這個命名規範來定義物件名。
其次，表、檢視、函式等最好也有統一的字首。如檢視可以用v為字首，而函式則可以利用f為字首。如此資料庫管理員無論是在日常管理還是物件引用的時候，都能夠在最短的時間內找到自己所需要的物件。
要求五：盡量只儲存單一實體型別的資料
這裡將的實體型別跟資料型別不是一回事，要注意區分。這裡講的實體型別是指所需要描述物件的本身。筆者舉乙個例子，估計大家就可以明白其中的內容了。
如現在有乙個圖書館裡系統，有圖書基本資訊、作者資訊兩個實體物件。若使用者要把這兩個實體物件資訊放在同一張表中也是可以的。如可以把錶設計成圖書名字、圖書作者等等。
可是如此設計的話，會給後續的維護帶來不少的麻煩。
如當後續有圖書出版時，則需要為每次出版的圖書增加作者資訊，這無疑會增加額外的儲存空間，也會增加記錄的長度。而且若作者的情況有所改變，如住址改變了以後，則還需要去更改每本書的記錄。同時，若這個作者的圖書從資料庫中全部刪除之後，這個作者的資訊也就蕩然無存了。
很明顯，這不符合資料庫設計規範化的需求。
遇到這種情況時，筆者建議可以把上面這張表分解成三種獨立的表，分別為圖書基本資訊表、作者基本資訊表、圖書與作者對應表等等。如此設計以後，以上遇到的所有問題就都引刃而解了。
以上五條是在資料庫設計時達到規範化水平的基本要求。除了這些另外還有很多細節方面的要求，如資料型別、儲存過程等等。而且，資料庫規範往往沒有技術方面的嚴格限制，主要依靠資料庫管理員日常工作經驗的累積。
資料表的設計原則:
(1)不應針對整個系統進行資料庫設計，而應該根據系統架構中的元件劃分，針對每個元件所處理的業務進行元件單元的資料庫設計;不同元件間所對應的資料庫表之間的關聯應盡可能減少，如果不同元件間的表需要外來鍵關聯也盡量不要建立外來鍵關聯，而只是記錄關聯表的乙個主鍵，確保元件對應的表之間的獨立性，為系統或表結構的重構提供可能性。
(2)採用領域模型驅動的方式和自頂向下的思路進行資料庫設計，首先分析系統業務，根據職責定義物件。物件要符合封裝的特性，確保與職責相關的資料項被定義在乙個物件之內，這些資料項能夠完整描述該職責，不會出現職責描述缺失。並且乙個物件有且只有一項職責，如果乙個物件要負責兩個或兩個以上的職責，應進行分拆。
(3)根據建立的領域模型進行資料庫表的對映，此時應參考資料庫設計第二正規化：乙個表中的所有非關鍵字屬性都依賴於整個關鍵字。關鍵字可以是乙個屬性，也可以是多個屬性的集合，不論那種方式，都應確保關鍵字能夠保證唯一性。
在確定關鍵字時，應保證關鍵字不會參與業務且不會出現更新異常，這時，最優解決方案為採用乙個自增數值型屬性或乙個隨機字串作為表的關鍵字。
(4)由於第一點所述的領域模型驅動的方式設計資料庫表結構，領域模型中的每乙個物件只有一項職責，所以物件中的資料項不存在傳遞依賴，所以，這種思路的資料庫表結構設計從一開始即滿足第三正規化：乙個表應滿足第二正規化，且屬性間不存在傳遞依賴。
(5)同樣，由於物件職責的單一性以及物件之間的關係反映的是業務邏輯之間的關係，所以在領域模型中的物件存在主物件和從物件之分，從物件是從1-n或n-n的角度進一步主物件的業務邏輯，所以從物件及物件關係對映為的表及表關聯關係不存在刪除和插入異常。
(6)在對映後得出的資料庫表結構中，應再根據第四正規化進行進一步修改，確保不存在多值依賴。這時，應根據反向工程的思路反饋給領域模型。如果表結構中存在多值依賴，則證明領域模型中的物件具有至少兩個以上的職責，應根據第一條進行設計修正。
第四正規化：乙個表如果滿足bcnf，不應存在多值依賴。
(7)在經過分析後確認所有的表都滿足
二、三、四正規化的情況下，表和表之間的關聯盡量採用弱關聯以便於對表字段和表結構的調整和重構。並且，我認為資料庫中的表是用來持久化乙個物件例項在特定時間及特定條件下的狀態的，只是乙個儲存介質，所以，表和表之間也不應用強關聯來表述業務(資料間的一致性)，這一職責應由系統的邏輯層來保證，這種方式也確保了系統對於不正確資料(髒資料)的相容性。當然，從整個系統的角度來說我們還是要盡最大努力確保系統不會產生髒資料，單從另乙個角度來說，髒資料的產生在一定程度上也是不可避免的，我們也要保證系統對這種情況的容錯性。
這是乙個折中的方案。
資料庫設計和規範化
某汽車維修公司需建立乙個汽車維修資料庫，該資料庫需要儲存和管理下列資訊 車輛資訊 車牌號，車型，發動機號，行駛里程，車輛所有人，聯絡 維修專案 專案號，專案名稱，維修費 汽車備件 備件號，備件名稱，備件單價，庫存數量 以上資料之間存在下列約束 1 可以對乙個車輛進行多個維修專案，每個維修專案可用於多...
資料庫設計規範
修訂歷史記錄 編制部門 產品研發部 發放範圍 產品研發部 目錄1.概述 5 2.資料庫設計的基本原則 63.資料庫建模 7 3.1 資料分析 7 3.2 資料關係分析 7 3.3 資料量分析 7 3.4 擴充套件性分析 7 3.5 資料字典 參考 7 3.5.1 資料項 7 3.5.2 資料結構 7...
資料庫系統工程師設計規範化的要求
如進銷存管理中，還需要對客戶的聯絡人進行管理。有時候，企業可能只知道客戶乙個採購員的姓名。但是在必要的情況下，企業需要對客戶的採購代表 倉庫人員 財務人員共同進行管理。因為在訂單上，可能需要填入採購代表的名字 可是在出貨單上，則需要填入倉庫管理人員的名字等等。為了解決這個問題，有多種實現方式。但是，...