書評－解決資料庫的結構性問題

Refactoring Databases: Evolutionary 　Database Design 　傑Scott W. Ambler、Pramodkumar J.Sadalage/著 　Addison Wesley Professional出版 　售價：49.99美元 　Amazon 四顆半星

重構（Refactoring）這個字眼想必大家應該不陌生，由Martin Fowler提出此革命性的觀點，基本精神是在外觀不被更動的前提下，進行內部重整的動作。而重整的對象通常是指軟體架構、演算邏輯、物件關係及程式碼內容，當時《Refactoring》一書主要針對程式內容的改良進行討論，並未將資料庫設計納入範疇。

歷史的包袱是資料庫明日的負擔
然而，在應用系統不斷地進行功能擴充或版本升級時，原本設計的資料庫規格必然會有異動的需求。當功能變動幅度不大時，也許會以在基本原始架構下新增資料表的方式進行；然而，時間一久，資料表之間的關聯錯綜複雜，資料的一致性及正確性可能因此大打折扣，在資料模型上較不如設計初期時那麼具備語意及行為概念，慢慢變成疊床架屋後的高風險違建，更談不上什麼符合資料庫正規化的理想了。

這樣的狀況在資料量不多的情況下，或許感受還不太明顯。當資料量成長一段時間後，在資料的一致性及處理效能上，就會付出較高的維護成本。

資料庫重構（Database Refactoring）的動機，即是在改善資料庫因長時間發展所造成的設計問題，在不增加新設計的前提下，針對現有資料庫結構設計及資料內容的重整。除了讓後續的設計能更容易維護，在擴充上也更具彈性。

真的要重構，那該怎麼做？
《Refactoring Databases》第三章提到資料庫重構的建議步驟，依照這些標準作業程序，可使進行重構時將風險降到最低：

● 評估重構的需求是否真的適用在你現有的資料庫系統上。
● 依照你的資料庫現況選擇最適合的重構方式。
● 在重構的過渡時期保留原有資料結構。
● 不斷地測試，測試完成後便著手進行重構作業。
● 重構完畢後執行原始資料的轉移作業
● 修改外部程式對資料庫的存取方式。
● 持續進行迴歸測試，確保重構的作業順利無誤。
● 對變動內容進行版本控管。

資料庫重構的觀念立意雖佳，但規畫及執行的過程必須十分謹慎周延。大部分的狀況下，資料庫不會僅單純提供給某一個應用系統使用，若因重構處理不當而中斷服務，來自開發人員、使用者等四面八方的抗議聲會蜂湧而至，所以在執行策略上必須妥善設計。在本書第五章便討論到這些內容。

包含完整的資料庫重構技術
作者在本書歸納整理了過去的成功經驗，將重構的方法大致分成以下幾大類：

● 結構性（Structural）重構：針對既有的Table、View重新設計。像是欄位的搬移、分割、刪除等。

● 資料品質（Data Quality）的重構：提高資料內容值的正確度或嚴謹度。像是減少非空值欄位以提高資料的可讀性，或是強迫定義格式（像是電話欄位），使其內容規格一致，或是加入欄位的限制條件（Constraints）等。

● 資料關連一致性（Referential Integrity）的重構：確保不同資料表之間的資料關連性都能正確。像是透過Trigger輔助進行跨資料表中之關連性資料刪除、加入外來鍵（Foreign Key）限制資料之間的一致性。

● 架構性（Architectural）的重構：架構設計的改善，藉此讓外部存取資料時更容易處理。

● 方法（Method）的重構：針對資料庫相關程式（像是Stored Procedure、 Function、Trigger等程式）的修改，可能是換上一個比較容易識別的名稱，或是將多個程式合併等。

● 其他改變：上述都是屬於重構，但也有機會不是以重構的方式變更系統，像是在現有資料表中增加欄位。

列了這麼多的資料庫重構方式，此時你便得審慎評估需要採取那一種。本書從第六到十一章便針對這些不同的重構方式逐一討論。每個大類中包括了作者提出的許多重構方法，內容從需求的動機（Motivation）談起，了解需要使用該方法的真正原因為何，指出其潛在可能發生的問題供讀者評估；也列出更改資料庫綱要之建議步驟、結構變更後的既有資料轉移方法以及技術實作方式。

《作者簡介》陳宏一
交通大學資訊管理研究所碩士。目前任職於某數位行銷公司技術經理，曾任職於南亞科技資訊部工程師、資迅人網路研發副理、艾群科技產品研發部經理，專精於OOAD、 J2EE 相關技術、Open Source、資料庫設計、軟體開發流程及專案管理等；取得SCJP、SCWCD、SCJD、SCEA、ITIL等認證。曾經歷大型社群及電子商務網站、 WAP/3G行動加值服務、CTI/CRM客服系統架構規畫設計等。