設計之路：數據庫設計的心得（一）

文/阿蜜果

日期：/2013-4-17

1、定義命名規范——沒有規矩不成方圓

         在數據庫設計之初，為了管理和維護方便，事先定義索引、觸發器、視圖、外鍵、字段名、表名等的命名規范。沒有規矩就不成方圓。

2、字段適當冗余——提供處理速度

設計關系數據庫時，遵從不同的規范要求，設計出合理的關系型數據庫，這些不同的規范要求被稱為不同的范式，各種范式呈遞次規范，越高的范式數據庫冗余越小。

目前關系數據庫有六種范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、巴德斯科范式（BCNF）、第四范式(4NF）和第五范式（5NF，又稱完美范式）。滿足最低要求的范式是第一范式（1NF）。在第一范式的基礎上進一步滿足更多規范要求的稱為第二范式（2NF），其余范式以次類推。一般說來，數據庫只需滿足第三范式(3NF）就行了。

第三范式（3NF）要求一個數據庫表中不包含已在其它表中已包含的非主關鍵字信息。例如，存在一個部門信息表，其中每個部門有部門編號、部門名稱、部門簡介等信息。那么在員工信息表中列出部門編號后就不能再將部門名稱、部門簡介等與部門有關的信息再加入員工信息表中。如果不存在部門信息表，則根據第三范式（3NF）也應該構建它，否則就會有大量的數據冗余。

但往往在進行數據庫設計的時候，為了提高處理速度提倡適當冗余。只有低級冗余才會增加數據的不一致性，因為同一數據，可能從不同時間、地點、角色上多次錄入。因此，我們提倡高級冗余（派生性冗余），反對低級冗余（重復性冗余）。

例如某個表中有“總結算金額”、“SI比率”、“運營商比率”字段，為了提高處理速度可適當冗余加入“SI結算總金額”和“運營商結算金額”字段。

又如“考核信息表”中會有某次考核的“總分”、“考核日期”字段，在具體的各個考核指標打分表“考核數據表”中加入“考核日期”字段。

設計人員需要在數據冗余和處理速度中找到適當的平衡點。

3、主鍵取值——自增主鍵 or UUID

         主鍵是供程序員使用的表間連接工具，一般可采用自增主鍵、UUID等，不建議將具有物理意義的字段或字段組合作為主鍵。例如將登錄名作為主鍵等。如果需要多個字段作為聯合主鍵，建議采用無意義的代理字段作為主鍵。聯合主鍵的字段個數太多時不但索引空間大，而且速度慢。

4、基本表提供CODE字段

         當系統與多個外圍系統有關系，而且需要保持唯一字段保持一致時。建議采用CODE（編號）字段與其它系統建立關系，ID字段可以是UUID，CODE字段可以系統自己定義規則。可能對于獨立的系統加上CODE字段有點多余，但對于與外圍關系復雜的系統，你會認識到必要性。

5、分解多對多關系——使用關聯表

         分解多對多關系的辦法就是添加中間表，例如在基于角色的權限分配的物理模型中，“角色表”和“權限表”中間添加“角色權限關聯表”，“用戶表”和“角色表”間添加“用戶角色關聯表”。關聯表與兩個主表建立外鍵關系。這是基本的數據庫設計方法，不一一贅述。

6、舉一反三，觸類旁通

         系統資源這一塊的設計需要“資源類型表”（例如虛擬機）、“資源類型參數表”（例如CPU、內存、硬盤、IP地址等參數）、“資源清單表”（具體的虛擬機）、“資源參數值表”（資源清單記錄的CPU、內存、硬盤、IP地址等參數的具體值）。

         類似這種設計可以用在很多地方，例如薪酬通的工資條模板針對不同公司有不同的模板，有可能同一個公司也有不同的工資模板。可以有“工資模板表”、“工資模板項表”、“工資數據表”、“工資模板項值表”。

         待續。

7、參考文檔

《數據庫范式_百度百科》：http://baike.baidu.com/view/402020.htm

《3NF_百度百科》：http://baike.baidu.com/view/726437.htm

《數據庫設計的一點心得和體驗》：http://www.nowamagic.net/librarys/veda/detail/642