本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

分析資料庫分解的凝聚和耦合

本節可協助您分析單體資料庫中的耦合和凝聚模式，以引導其分解。了解資料庫元件如何相互互動和依賴，對於識別自然中斷點、評估複雜性和規劃分階段遷移方法至關重要。此分析會顯示隱藏的相依性、反白顯示適合立即分離的區域，並協助您排定分解工作的優先順序，同時將轉換風險降至最低。透過檢查耦合和凝聚力，您可以對元件分離序列做出明智的決策，以在整個轉換過程中維持系統穩定性。

關於凝聚和耦合

耦合會測量資料庫元件之間的相互依存性。在設計良好的系統中，您想要實現鬆耦合，其中對一個元件的變更對其他元件的影響最小。Cohesion 會測量資料庫元件中的元素搭配運作的程度，以達成單一、明確定義的用途。高度黏性表示元件的元素具有強烈關聯性，並專注於特定函數。分解單體資料庫時，您必須分析個別元件內的凝聚力，以及它們之間的耦合。此分析可協助您針對如何分解資料庫，同時維持系統完整性和效能，做出明智的決策。

下圖顯示具有高黏著性的鬆散耦合。資料庫中的元件會一起運作，以執行特定 函數，而且您可以將變更對單一元件的影響降至最低。這是理想的狀態。

下圖顯示高耦合與低黏著性。資料庫元件會中斷連線，而變更很可能會影響其他元件。

單體資料庫中的常見耦合模式

將單體資料庫分解為微服務特定的資料庫時，通常會發現數種耦合模式。了解這些模式對於成功的資料庫現代化計劃至關重要。本節說明每種模式、其挑戰，以及減少耦合的最佳實務。

實作耦合模式

定義：元件在程式碼和結構描述層級緊密互連。例如，修改customer資料表的結構會影響 order、 inventory和 billing服務。

現代化影響：每個微服務都需要自己的專用資料庫結構描述和資料存取層。

挑戰：

減少耦合的最佳實務：

時間耦合模式

定義：操作必須以特定順序執行。例如，在庫存更新完成之前，訂單處理無法繼續。

現代化影響：每個微服務都需要自動控制資料。

挑戰：

減少耦合的最佳實務：

部署耦合模式

定義：系統元件必須部署為單一單位。例如，付款處理邏輯的次要變更需要重新部署整個資料庫。

現代化影響：每個服務的獨立資料庫部署

挑戰：

減少耦合的最佳實務：

網域耦合模式

定義：商業網域共用資料庫結構和邏輯。例如，customer、 order和 inventory網域共用資料表和預存程序。

現代化影響：網域特定資料隔離

挑戰：

減少耦合的最佳實務：

單體資料庫中的常見凝聚模式

評估資料庫元件進行分解時，通常會發現數種凝聚模式。了解這些模式對於識別結構良好的資料庫元件至關重要。本節說明每種模式、其特性，以及強化凝聚力的最佳實務。

功能凝聚力模式

定義：所有元素都直接支援並有助於執行單一、定義明確的函數。例如，付款處理模組中的所有預存程序和資料表只會處理與付款相關的操作。

現代化影響：微型服務資料庫設計的理想模式

挑戰：

強化凝聚力的最佳實務：

順序凝聚模式

定義：一個元素的輸出會變成另一個元素的輸入。例如，訂單饋送至訂單處理的驗證結果。

現代化影響：需要仔細的工作流程分析和資料流程映射

挑戰：

強化凝聚力的最佳實務：

通訊凝聚力模式

定義：元素在相同的資料上運作。例如，客戶設定檔管理功能都可以使用客戶資料。

現代化影響：協助識別服務分離的資料邊界，以減少模組之間的耦合

挑戰：

強化凝聚力的最佳實務：

程序性凝聚模式

定義：元素會分組在一起，因為它們必須以特定順序執行，但可能不會與功能相關。例如，在順序處理中，處理訂單驗證和使用者通知的預存程序只會因為依序發生，即使它們有不同的用途，也可以由不同的服務處理。

現代化影響：需要謹慎區隔程序，同時維護流程

挑戰：

強化凝聚力的最佳實務：

暫時凝聚力模式

定義：元素與時間要求相關。例如，下訂單時，數個操作必須一起執行：庫存檢查、付款處理、訂單確認和運送通知都必須在特定時段內發生，才能維持一致的訂單狀態。

現代化影響：可能需要在分散式系統中進行特殊處理

挑戰：

強化凝聚力的最佳實務：

邏輯或同時的凝聚力模式

定義：元素在邏輯上會分類為執行相同動作，即使它們的關係較弱或沒有有意義的關係。其中一個範例是在相同的資料庫結構描述中存放客戶訂單資料、倉儲庫存計數和行銷電子郵件範本，因為它們都與銷售操作相關，儘管有不同的存取模式、生命週期管理和擴展需求。另一個範例是在相同的資料庫元件中結合訂單付款處理和產品目錄管理，因為它們都是電子商務系統的一部分，即使它們為具有不同營運需求的不同業務職能提供服務。

現代化影響：應重構或重組

挑戰：

強化凝聚力的最佳實務：

實作低耦合和高凝聚性

最佳實務

下列最佳實務可協助您實現低耦合：

下列最佳實務可協助您實現高凝聚力：

階段 1：映射資料相依性

映射資料關係並識別自然界限。您可以使用 等工具SchemaSpy，透過在實體關係 (ER) 圖表中顯示資料表來視覺化資料庫。這可提供資料庫的靜態分析，並指出資料庫中的一些明確界限和相依性。

您也可以在圖形資料庫或Jupiter筆記本中匯出資料庫結構描述。然後，您可以套用叢集或互連元件演算法，以識別自然界限和相依性。其他 AWS Partner 工具，例如 CAST Imaging，可協助了解您的資料庫相依性。

階段 2：分析交易界限和存取模式

分析交易模式以維護原子性、一致性、隔離性、耐久性 (ACID) 屬性，並了解資料的存取和修改方式。您可以使用資料庫分析和診斷工具，例如 Oracle Automatic Workload Repository (AWR)或 PostgreSQL pg_stat_statements。此分析可協助您了解誰正在存取資料庫，以及交易界限是什麼。它也可以協助您了解資料表在執行時間的凝聚和耦合。您也可以使用監控和分析工具來連結程式碼和資料庫執行設定檔，例如 Dynatrace AppEngine。

AI 工具，例如 vFunction，可以透過分析應用程式的功能和網域邊界來協助您識別網域邊界。雖然 vFunction主要會分析應用程式層，但其洞見可以引導應用程式和資料庫的分解，以支援與業務網域的一致性。

階段 3：識別獨立資料表

尋找示範兩個關鍵特性的資料表：

下列耦合黏附矩陣可協助您識別解耦每個資料表的難度。出現在此矩陣右上角的資料表是初始解耦工作的理想候選者，因為它們是最容易分離的。在 ER 圖表中，這些資料表幾乎沒有外部索引鍵關係或其他相依性。解耦這些資料表之後，會朝具有更複雜關係的資料表前進。