資料庫表結構設計方法及原則

資料庫表結構設計方法及原則
Author: Chancey 
 
在目前的公司資訊系統中，資料庫還是最佳的資料存放區方式，雖然已經有很多的書籍在指導我們進行資料庫設計，但應該那種方式是設計資料庫的表結構的最好方法、設計時應遵從什麼樣的原則、四個範式如何能夠用一種方式達到順暢的應用等是我一直在思考和總結的問題，下文是我針對這幾個問題根據自己的設計經曆準備總結的一篇文章的提綱，歡迎大家一塊進行探討，集思廣益。其中提到了領域建模的概念，但未作詳細解釋，希望以後能夠有時間我們針對這個命題進行深入探討。

1)不應該針對整個系統進行資料庫設計，而應該根據系統架構中的組件劃分，針對每個組件所處理的業務進行組件單元的資料庫設計；不同組件間所對應的資料庫表之間的關聯應儘可能減少，如果不同組件間的表需要外部索引鍵關聯也盡量不要建立外部索引鍵關聯，而只是記錄關聯表的一個主鍵，確保組件對應的表之間的獨立性，為系統或表結構的重構提供可能性。

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

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

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

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

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

7)在經過分析後確認所有的表都滿足二、三、四範式的情況下，表和表之間的關聯盡量採用弱關聯以便於對錶欄位和表結構的調整和重構。並且，我認為資料庫中的表是用來持久化一個對象執行個體在特定時間及特定條件下的狀態的，只是一個儲存介質，所以，表和表之間也不應用強關聯來表述業務（資料間的一致性），這一職責應由系統的邏輯層來保證，這種方式也確保了系統對於不正確資料（髒資料）的相容性。當然，從整個系統的角度來說我們還是要盡最大努力確保系統不會產生髒資料，單從另一個角度來說，髒資料的產生在一定程度上也是不可避免的，我們也要保證系統對這種情況的容錯性。這是一個折中的方案。

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

9)盡量少採用預存程序，目前已經有很多技術可以替代預存程序的功能如“對象/關係映射”等，將資料一致性的保證放在資料庫中，無論對於版本控制、開發和部署、以及資料庫的遷移都會帶來很大的影響。但不可否認，預存程序具有效能上的優勢，所以，當系統可使用的硬體不會得到提升而效能又是非常重要的品質屬性時，可經過平衡考慮選用預存程序。

10)當處理表間的關聯約束所付出的代價（常常是使用性上的代價）超過了保證不會出現修改、刪除、更改異常所付出的代價，並且資料冗餘也不是主要的問題時，表設計可以不符合四個範式。四個範式確保了不會出現異常，但也可能由此導致過於純潔的設計，使得表結構難於使用，所以在設計時需要進行綜合判斷，但首先確保符合四個範式，然後再進行精化修正是剛剛進入資料庫設計領域時可以採用的最好辦法。

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

12)設計出的表要儘可能減少資料冗餘，確保資料的準確性，有效控制冗餘有助於提高資料庫的效能。