《Refactoring Database》重構讓你的資料庫品質更提升

重構（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）談起，了解需要使用該方法的真正原因為何，指出其潛在可能發生的問題供讀者評估；也列出更改 資料庫綱要之建議步驟、結構變更後的既有資料轉移方法以及技術實作方式。

資料庫重構的工程可大可小，花時間進行這樣的投資仍然是值得的。規畫者在事前的評估規畫及執行所需的方法，在本書的章節都可以找到你要的答案。字字珠璣，絕對是值得一讀的好書。

 

《Prefactoring》避開重蹈覆轍的陷阱

refactoring

早從1999年Martin Fowler的著作至今，重構（Refactoring）似乎已經成為提昇軟體品質的重要觀念，但軟體專案常常會因為時程壓力及人力不足的現實問題，在專 案執行的過程中進行Refactoring是很難被允許的。以專案管理的觀念看來，這是需要花費時間與金錢的。故在架構設計及程式撰寫上，這樣的觀念就相 對地不被重視，程式開發人員也都以「只要將功能開發出來」的想法來運作。

重構的實現較易在軟體產品研發上，落實在版本更新的規劃中，不過產品規劃的時程也不見得允許重構，因為Refactoring不會改變任何外部功能；而依客戶需求量身訂做的客製化軟體專案，甚至涉及到系統整合的案例，則更難以將重構落實在專案中。

累積預防經驗有助於日後專案發展

有鑑於Refactoring不易落實，所以一個適應性的做法－Prefactoring（預構）也許是個另類的解決方式。作者Ken Pugh提出這樣的觀念，根據自己或他人多年的軟體開發經驗，整理成開發專案時的指導方針，以利於未來專案啟始時做為遵循的準則。它與重構的差別主要在於 執行的時間點，Prefactoring是在專案開始前就先行思考，並非在專案執行期間才發生。

這裡的指導方針有絕大部份跟一般基本的設計原則（像是OOAD的特性）相符，而其他的方針則主要圍繞在分析抽象化（Extreme Abstraction），設計分離（Extreme Separation），提供可讀性（Extreme Readability），以及介面設計（Interface）幾個重點上。

抽象化設計其實已經是物件導件分析設計中的重要觀念，強調「做什麼（What）」而非「如何去做（How）」。所以在這個過程中，很難意會到實作 時的細節，容易造成分析階段到設計階段時實現（Realization）的落差。針對這個問題，本書建議在抽象化設計時搭配雛型系統 （Prototype）的使用，而在設計過程中使用與特定式語言與無關的的方式，採OOAD之標準原則（像是Class、Interface、 Exception等）來進行設計。

分離設計最常見的方式，便是將操作畫面的呈現與商業邏輯，以不同的元件各司其職。在日後需求變動時，不會牽一髮而動全身；而為了日後維護容易，寫出來的程式碼不僅是給電腦看，也要讓人能輕易地看得懂。本書建議最理想的程式是連您的客戶都看得懂。

預構強調軟體開發流程與方法

本書的內容共分成十七個章節，作者以開發一套CD出租店系統的虛擬故事為主軸，說明在進行一項軟體專案時會面臨到的課題。開宗明義不免俗地簡介 Prefactoring的觀念以及其基本方針，接下來便從與老板Sam聊起他理想中的系統應該長什麼樣子開始，文中不時穿插主角與客戶之間的對話，活生 生地如同您在與客戶之間的溝通互動。

為了精確掌握使用者在想什麼，首先釐清字詞明確的描述（光CDTitle、CDRelease、CDDisc的定義就引起一番爭論），再將相關的 字詞分類歸納，轉化成物件的方式來設計。這裡頭像是一些常見物件設計原則就會被討論到，像是多形（Polymorphism）、抽象化資料型態 （Abstract Data Type）等等，甚至直接用一個雛型系統（Prototype）來與使用者確認需求內容的正確性。

雖然設計必須奉行理論，但還是有無法被落實的狀況發生。起因可能是與使用者想法的不一致，對事物解讀的誤解。但這些軟體開發的準則並不是標準答 案，就像是開車一樣，每個人都有自己的風格，重要的是讓自己面臨類似問題時能快速且有效地解決。而且每個準則都有適用的使用時機，而非一條鞭式地適用於任 何狀況。

就本書的內容看來，還是在強調軟體開發流程與方法的重要性。在每個章節中作者以座右銘的方式提醒需要強調的重點，並在書末的附錄中整理了所有的原 則。如果了解物件導向分析設計的重要，同時亦希望用省時省錢的方法來進行專案，本書也許可以提供一些想法，雖然無法保證從此不需要 Refactoring，但次數的減少是可以肯定的。