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

# 定義資料庫分解的範圍和需求
<a name="scope"></a>

當您定義範圍並識別資料庫分解專案的需求時，您必須從組織的需求中恢復工作。這需要系統化的方法，在技術可行性與商業價值之間取得平衡。這個初始步驟為整個程序奠定基礎，並協助您確保專案的目標與組織的目標和功能保持一致。

**Topics**
+ [建立核心分析架構](#scope-core-analysis-framework)
+ [定義資料庫分解的系統邊界](#scope-system-boundaries)
+ [考慮發行週期](#scope-release-cycle)
+ [評估資料庫分解的技術限制條件](#scope-constraints)
+ [了解組織內容](#scope-context)
+ [評估資料庫分解的風險](#scope-risk)
+ [定義資料庫分解的成功條件](#scope-success-criteria)

## 建立核心分析架構
<a name="scope-core-analysis-framework"></a>

範圍定義從系統化工作流程開始，引導分析完成四個互連階段。這種全面的方法可確保資料庫分解工作以對現有系統和操作需求的透徹了解為基礎。以下是核心分析架構中的階段：

1. **演員分析** – 徹底識別與資料庫互動的所有系統和應用程式。這包括映射執行寫入操作的生產者和處理讀取操作的取用者，同時記錄其存取模式、頻率和尖峰使用時間。此以客戶為中心的檢視可協助您了解任何變更的影響，並識別在分解期間需要特別注意的關鍵路徑。

1. **活動分析** – 深入了解每個演員執行的特定操作。您可以為每個系統建立詳細的建立、讀取、更新和刪除 (CRUD) 矩陣，並識別它們存取的資料表及其方式。此分析可協助您探索分解的自然界限，並反白顯示您可以簡化目前架構的區域。

1. **相依性映射** – 記錄系統之間的直接和間接相依性，建立資料流程和關係的清晰視覺化。這有助於識別需要仔細規劃以獲得信任的潛在中斷點和領域。分析會同時考慮技術相依性，例如共用資料表和外部金鑰，以及業務流程相依性，例如工作流程序列和報告需求。

1. **一致性要求** – 使用高標準檢查每個操作的一致性需求。判斷哪些操作需要立即的一致性，例如金融交易。其他操作可以最終一致性運作，例如分析更新。此分析會直接影響整個專案中分解模式和架構決策的選擇。

## 定義資料庫分解的系統邊界
<a name="scope-system-boundaries"></a>

*系統邊界*是邏輯周邊，可定義一個系統結束和另一個系統開始的位置，包括資料擁有權、存取模式和整合點。定義系統界限時，請做出深思熟慮但果斷的選擇，在全面規劃與實際實作需求之間取得平衡。將資料庫視為可能跨越多個實體資料庫或結構描述的邏輯單位。此界限定義可達成下列關鍵目標：
+ 識別所有外部演員及其互動模式
+ 全面映射傳入和傳出相依性
+ 文件技術和操作限制
+ 清楚描述分解工作的範圍

## 考慮發行週期
<a name="scope-release-cycle"></a>

了解發行週期對於規劃資料庫分解至關重要。檢閱目標系統和任何相依系統的續約時間。識別協調變更的機會。請考慮任何計劃停用的連線系統，因為這可能會影響您的分解策略。考慮現有的變更時段和部署限制條件，將業務中斷降至最低。請確定您的實作計劃符合所有連線系統的發行排程。

## 評估資料庫分解的技術限制條件
<a name="scope-constraints"></a>

在繼續進行資料庫分解之前，請評估將塑造現代化方法的關鍵技術限制。檢查目前技術堆疊的功能，包括資料庫版本、架構、效能需求和服務水準協議。考慮安全和合規要求，尤其是受監管的產業。檢閱目前的資料磁碟區、成長預測和可用的遷移工具，以通知您的擴展決策。最後，請確認您對原始程式碼和系統修改的存取權，因為這些權限將決定可行的分解策略。

## 了解組織內容
<a name="scope-context"></a>

成功的資料庫分解需要您了解系統運作所在的更廣泛的組織環境。映射跨部門相依性，並在團隊之間建立明確的溝通管道。評估您團隊的技術能力，並找出您需要解決的任何訓練需求或技能差距。考慮變革管理影響，包括如何管理轉換和維護業務連續性。評估可用資源和任何限制，例如預算或人員配置限制。最後，將您的分解策略與利益相關者的期望和優先事項保持一致，以在整個專案中促進持續支援。

## 評估資料庫分解的風險
<a name="scope-risk"></a>

全面的風險評估對於資料庫分解成功至關重要。仔細評估風險，例如遷移期間的資料完整性、潛在的系統效能降低、可能的整合失敗，以及安全漏洞。這些技術挑戰必須平衡業務風險，包括潛在的營運中斷、資源限制、時間軸延遲和預算限制。針對每個已識別的風險，制定特定的緩解策略和應變計畫，以維持專案動能，同時保護業務營運。

建立風險矩陣，以評估潛在問題的影響和機率。與技術團隊和業務利益相關者合作，以識別風險、設定明確的介入閾值，並制定特定的緩解策略。例如，將資料遺失風險評分為高影響和低機率，而且需要強大的備份策略。輕微效能降低可能是中度影響和高機率，而且需要主動監控。

建立定期風險審查週期，以重新評估優先順序，並在專案發展時調整緩解計劃。這種系統性方法可確保資源專注於最關鍵的風險，同時為新興問題維持明確的呈報路徑。

## 定義資料庫分解的成功條件
<a name="scope-success-criteria"></a>

資料庫分解的成功條件必須明確定義且可跨多個維度測量。從業務角度來看，建立降低成本、改善time-to-market、系統可用性和客戶滿意度的特定目標。技術成功應透過可量化的系統效能、部署效率、資料一致性和整體可靠性改善來衡量。對於遷移程序，請定義對零資料遺失、可接受的業務中斷限制、預算合規和時間表遵循的嚴格要求。

透過維護基準和目標指標、明確的測量方法和定期檢閱排程，徹底記錄這些條件。為每個成功指標指派明確的擁有者，並在不同的指標之間映射相依性。這種衡量成功的全方位方法使技術成就與業務成果保持一致，同時在整個分解過程中保持責任制。