本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 定义数据库分解的范围和要求
<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、系统可用性和客户满意度设定具体目标。应通过系统性能、部署效率、数据一致性和整体可靠性方面的可量化改进来衡量技术成功。对于迁移过程，定义严格的要求，包括零数据丢失、可接受的业务中断限制、预算合规性和遵守时间表。

通过维护基线和目标指标、明确的测量方法和定期的审查时间表，全面记录这些标准。为每个成功指标分配明确的所有者，并映射不同指标之间的依赖关系。这种衡量成功的全面方法使技术成就与业务成果保持一致，同时在整个分解过程中保持问责制。