數(shù)據(jù)表的設計原則:

　　(1)不應針對整個系統(tǒng)進行數(shù)據(jù)庫設計，而應該根據(jù)系統(tǒng)架構中的組件劃分，針對每個組件所處理的業(yè)務進行組件單元的數(shù)據(jù)庫設計;不同組件間所對應的數(shù)據(jù)庫表之間的關聯(lián)應盡可能減少，如果不同組件間的表需要外鍵關聯(lián)也盡量不要創(chuàng)建外鍵關聯(lián)，而只是記錄關聯(lián)表的一個主鍵，確保組件對應的表之間的獨立性，為系統(tǒng)或表結構的重構提供可能性。

　　(2)采用領域模型驅動的方式和自頂向下的思路進行數(shù)據(jù)庫設計，首先分析系統(tǒng)業(yè)務，根據(jù)職責定義對象。對象要符合封裝的特性，確保與職責相關的數(shù)據(jù)項被定義在一個對象之內(nèi)，這些數(shù)據(jù)項能夠完整描述該職責，不會出現(xiàn)職責描述缺失。并且一個對象有且只有一項職責，如果一個對象要負責兩個或兩個以上的職責，應進行分拆。

　　(3)根據(jù)建立的領域模型進行數(shù)據(jù)庫表的映射，此時應參考數(shù)據(jù)庫設計第二范式：一個表中的所有非關鍵字屬性都依賴于整個關鍵字。關鍵字可以是一個屬性，也可以是多個屬性的集合，不論那種方式，都應確保關鍵字能夠保證唯一性。在確定關鍵字時，應保證關鍵字不會參與業(yè)務且不會出現(xiàn)更新異常，這時，最優(yōu)解決方案為采用一個自增數(shù)值型屬性或一個隨機字符串作為表的關鍵字。

　　(4)由于第一點所述的領域模型驅動的方式設計數(shù)據(jù)庫表結構，領域模型中的每一個對象只有一項職責，所以對象中的數(shù)據(jù)項不存在傳遞依賴，所以，這種思路的數(shù)據(jù)庫表結構設計從一開始即滿足第三范式：一個表應滿足第二范式，且屬性間不存在傳遞依賴。

　　(5)同樣，由于對象職責的單一性以及對象之間的關系反映的是業(yè)務邏輯之間的關系，所以在領域模型中的對象存在主對象和從對象之分，從對象是從1-N或N-N的角度進一步主對象的業(yè)務邏輯，所以從對象及對象關系映射為的表及表關聯(lián)關系不存在刪除和插入異常。

　　(6)在映射后得出的數(shù)據(jù)庫表結構中，應再根據(jù)第四范式進行進一步修改，確保不存在多值依賴。這時，應根據(jù)反向工程的思路反饋給領域模型。如果表結構中存在多值依賴，則證明領域模型中的對象具有至少兩個以上的職責，應根據(jù)第一條進行設計修正。第四范式：一個表如果滿足BCNF，不應存在多值依賴。

　　(7)在經(jīng)過分析后確認所有的表都滿足二、三、四范式的情況下，表和表之間的關聯(lián)盡量采用弱關聯(lián)以便于對表字段和表結構的調整和重構。并且，我認為數(shù)據(jù)庫中的表是用來持久化一個對象實例在特定時間及特定條件下的狀態(tài)的，只是一個存儲介質，所以，表和表之間也不應用強關聯(lián)來表述業(yè)務(數(shù)據(jù)間的一致性)，這一職責應由系統(tǒng)的邏輯層來保證，這種方式也確保了系統(tǒng)對于不正確數(shù)據(jù)(臟數(shù)據(jù))的兼容性。當然，從整個系統(tǒng)的角度來說我們還是要盡最大努力確保系統(tǒng)不會產(chǎn)生臟數(shù)據(jù)，單從另一個角度來說，臟數(shù)據(jù)的產(chǎn)生在一定程度上也是不可避免的，我們也要保證系統(tǒng)對這種情況的容錯性。這是一個折中的方案。

　　(8)應針對所有表的主鍵和外鍵建立索引，有針對性的(針對一些大數(shù)據(jù)量和常用檢索方式)建立組合屬性的索引，提高檢索效率。雖然建立索引會消耗部分系統(tǒng)資源，但比較起在檢索時搜索整張表中的數(shù)據(jù)尤其時表中的數(shù)據(jù)量較大時所帶來的性能影響，以及無索引時的排序操作所帶來的性能影響，這種方式仍然是值得提倡的。

　　(9)盡量少采用存儲過程，目前已經(jīng)有很多技術可以替代存儲過程的功能如“對象/關系映射”等，將數(shù)據(jù)一致性的保證放在數(shù)據(jù)庫中，無論對于版本控制、開發(fā)和部署、以及數(shù)據(jù)庫的遷移都會帶來很大的影響。但不可否認，存儲過程具有性能上的優(yōu)勢，所以，當系統(tǒng)可使用的硬件不會得到提升而性能又是非常重要的質量屬性時，可經(jīng)過平衡考慮選用存儲過程。

　　(10)當處理表間的關聯(lián)約束所付出的代價(常常是使用性上的代價)超過了保證不會出現(xiàn)修改、刪除、更改異常所付出的代價，并且數(shù)據(jù)冗余也不是主要的問題時，表設計可以不符合四個范式。四個范式確保了不會出現(xiàn)異常，但也可能由此導致過于純潔的設計，使得表結構難于使用，所以在設計時需要進行綜合判斷，但首先確保符合四個范式，然后再進行精化修正是剛剛進入數(shù)據(jù)庫設計領域時可以采用的最好辦法。

　　(11)設計出的表要具有較好的使用性，主要體現(xiàn)在查詢時是否需要關聯(lián)多張表且還需使用復雜的SQL技巧。

　　(12)設計出的表要盡可能減少數(shù)據(jù)冗余，確保數(shù)據(jù)的準確性，有效的控制冗余有助于提高數(shù)據(jù)庫的性能。

我要為大家介紹的有關數(shù)據(jù)表設計的原則就為大家講到這，希望大家都能從中收獲知識，很高興與大家一起分享數(shù)據(jù)表的設計原則。

【編輯推薦】

1. sybase數(shù)據(jù)表的導出與導入
2. 教您如何批量修改MySQL數(shù)據(jù)表字段內(nèi)容
3. MySQL數(shù)據(jù)表中插入數(shù)據(jù)并查詢輸出的實現(xiàn)