版權聲明：本文為部落客chszs的原創文章，未經部落客允許不得轉載。 https://blog.csdn.net/chszs/article/details/5332408
資料庫重構探讨系列
(1) 基礎
1、資料庫重構分成6類：
2、資料庫味道
與“代碼味道”概念相似，代碼味道是代碼中出現常見問題，表明需要進行重構。
資料庫味道表明資料庫需要重構。這些味道包括：
(1) 多用途的列
如一個列被用于多種用途，就可能存在額外的代碼來確定源資料以“正确的方式”使用，這些代碼常常會檢查一個列或更多其它列的值。
比如：
某列用于存儲某人的生日，如果此人是顧客的話。假如此人是公司雇員，此列則用于存儲入廠日期。
(2) 多用途的表
如一個表被用于存放幾種類型的實體，就可能存在設計缺陷。
例如：
某個表Customer同時存放了人和公司的資訊。
(3) 重複的資料
重複的資料對操作型資料庫來說是一個嚴重的問題，因為如資料存放在幾個地方，不一緻的機會就增加了。
(4) 列太多的表
當一個表包含太多的列，則說明這個表缺乏内聚。
Customer表包含了一些列，存放了3種不同的位址（發貨位址、賬單位址、公司位址）或幾個電話号碼（家庭電話、工作電話、手機号等），你可能需要将這種結構進行标準化處理，加入Address和PhoneNumber表。
(5) “智能”列
“智能”列是這樣一種列，其中資料的不同位置代表不同的概念。
客戶ID的前4位數字代表客戶的開戶行，則客戶ID就是一個“智能”列。因為你會解析它以取得更細粒度的資訊，如開戶行ID。
3、資料庫重構
資料庫重構是一種資料庫實作技術，與代碼重構相似，對資料庫Schema進行重構，使得在上面增加東西變得容易。
上圖提供了一些關鍵開發活動的高層視圖，這些活動發生在涉及對象和關系資料庫技術的現代項目中。需要在這些活動之間來回疊代。
資料庫重構是演進式資料庫開發的一個重要組成部分。還需要采用演進/靈活的方式進行資料模組化。
耦合越厲害，就越難重構。代碼重構、資料庫重構均是如此。
最簡單的場景：單應用資料庫。因為資料庫Schema隻與它本身和一個應用相耦合。
而在多應用的資料庫架構中，你的資料庫Schema可能與應用源碼、持久架構、ORM工具、其它資料庫(提供複制、資料抽取/加載等)、資料檔案Schema、測試代碼，甚至資料庫自身等耦合在一起。
減少涉及資料庫的耦合的一種有效方式是封裝對資料庫的通路。讓外部程式通過持久層來通路資料庫，可以實作對資料庫通路的封裝。
持久層有多種實作方式：
(1) 通過資料通路對象DAO，它實作了所需的SQL代碼；
(2) 通過架構；
(3) 通過存儲過程；
(4) 通過Web服務。
永遠也不可能把耦合降到0，但肯定可以把它降到能管理的程度。