sql資料庫設計學習---資料庫設計正常化的五個要求

標籤：

http://blog.csdn.net/taijianyu/article/details/5945490

一：表中應該避免可為空白的列；

二：表不應該有重複的值或者列；

三： 表中記錄應該有一個唯一的標識符 
　　在資料庫表設計的時候，資料庫管理員應該養成一個好習慣，用一個ID號來 唯一的標識行記錄，而不要通過名字、編號等欄位來對紀錄進行區分。每個表都應該有一個ID列，任何兩個記錄都不可以共用同一個ID值。另外，這個ID值最 好有資料庫來進行自動管理，而不要把這個任務給前台應用程式。否則的話，很容易產生ID值不統一的情況。
　　另外，在資料庫設計的時候，最好還能 夠加入行號。如在銷售訂單管理中，ID號是使用者不能夠維護的。但是，行號使用者就可以維護。如在銷售訂單的行中，使用者可以通過調整行號的大小來對訂單行進行 排序。通常情況下，ID列是以1為單位遞進的。但是，行號就要以10為單位累進。如此，正常情況下，行號就以10、20、30依次擴充下去。若此時使用者需 要把行號為30的紀錄調到第一行顯示。此時，使用者在不能夠更改ID列的情況下，可以更改行號來實現。如可以把行號改為1，在排序時就可以按行號來進行排 序。如此的話，原來行號為30的紀錄現在行號變為了1，就可以在第一行中顯示。這是在實際應用程式設計中對ID列的一個有效補充。這個內容在教科書上是沒 有的。需要在實際應用程式設計中，才會掌握到這個技巧。

四：資料庫物件要有統一的首碼名 
　　一個比較複雜的應用系統，其對應的資料庫表往往以千計。若讓資料庫管理員看到對象名就瞭解這個資料庫物件所起的作用，恐怕會比較困難。而且在資料庫物件引用的時候，資料庫管理員也會為不能迅速找到所需要的資料庫物件而頭疼。
　 　為此，筆者建立，在開發資料庫之前，最好能夠花一定的時間，去制定一個資料庫物件的首碼命名規範。如筆者在資料庫設計時，喜歡跟前台應用程式協商，確定 合理的命名規範。筆者最常用的是根據前台應用程式的模組來定義後台資料庫物件首碼名。如跟物料管理模組相關的表可以用M為首碼;而以訂單管理相關的，則可 以利用C作為首碼。具體採用什麼首碼可以以使用者的愛好而定義。但是，需要注意的是，這個命名規範應該在資料庫管理員與前台應用程式開發人員之間達成共識，並 且嚴格按照這個命名規範來定義對象名。
　　其次，表、視圖、函數等最好也有統一的首碼。如視圖可以用V為首碼，而函數則可以利用F為首碼。如此資料庫管理員無論是在日常管理還是對象引用的時候，都能夠在最短的時間內找到自己所需要的對象。

五：盡量只儲存單一實體類型的資料 
　　這裡將的實體類型跟資料類型不是一回事，要注意區分。這裡講的實體類型 是指所需要描述對象的本身。筆者舉一個例子，估計大家就可以明白其中的內容了。如現在有一個圖書館裡系統，有圖書基本資料、作者資訊兩個實體物件。若使用者 要把這兩個實體物件資訊放在同一張表中也是可以的。如可以把表設計成圖書名字、圖書作者等等。可是如此設計的話，會給後續的維護帶來不少的麻煩。
　 　如當後續有圖書出版時，則需要為每次出版的圖書增加作者資訊，這無疑會增加額外的儲存空間，也會增加記錄的長度。而且若作者的情況有所改變，如住址改變 了以後，則還需要去更改每本書的記錄。若這個作者的圖書從資料庫中全部刪除之後，這個作者的資訊也就蕩然無存了。很明顯，這不符合資料庫設計正常化的需 求。
　　遇到這種情況時，筆者建議可以把上面這張表分解成三種獨立的表，分別為圖書基本資料表、作者基本資料表、圖書與作者對應表等等。如此設計以後，以上遇到的所有問題就都引刃而解了。

sql資料庫設計學習---資料庫設計正常化的五個要求