数据仓库 - 交付流程

---

---

数据仓库从来都不是静态的；它会随着业务的扩展而发展。随着业务的发展，其需求不断变化，因此必须设计数据仓库来适应这些变化。因此，数据仓库系统需要具有灵活性。

理想情况下，应该有一个交付流程来交付数据仓库。但是，数据仓库项目通常会遇到各种问题，这些问题使得难以按照瀑布方法严格有序的方式完成任务和交付成果。大多数情况下，需求并未完全理解。只有在收集和研究所有需求后，才能完成架构、设计和构建组件。

交付方法

交付方法是为交付数据仓库而采用的联合应用开发方法的一种变体。我们已经将数据仓库交付流程分阶段进行，以最大限度地降低风险。我们在这里将讨论的方法不会缩短整体交付时间，但可以确保通过开发流程逐步交付业务利益。

注意 - 交付流程被分解成多个阶段，以降低项目和交付风险。

下图解释了交付流程中的各个阶段：

IT战略

数据仓库是需要业务流程来产生效益的战略性投资。需要IT战略来获得和保留项目的资金。

商业案例

商业案例的目的是评估使用数据仓库应该获得的业务效益。这些效益可能无法量化，但需要明确说明预计效益。如果数据仓库没有明确的商业案例，那么在交付过程中某个阶段，业务往往会遇到信誉问题。因此，在数据仓库项目中，我们需要了解投资的商业案例。

教育和原型设计

组织在确定解决方案之前，会尝试数据分析的概念，并了解拥有数据仓库的价值。这是通过原型设计来实现的。它有助于了解数据仓库的可行性和效益。小规模的原型设计活动可以促进教育过程，只要：

• 原型解决了明确的技术目标。

• 在证明可行性概念后，可以丢弃原型。

• 该活动涉及数据仓库最终数据内容的一小部分。

• 活动时间范围不关键。

为了尽早发布并交付业务效益，需要记住以下几点：

• 确定能够发展的架构。

• 关注业务需求和技术蓝图阶段。

• 将第一构建阶段的范围限制在交付业务效益的最低限度。

• 了解数据仓库的短期和中期需求。

业务需求

为了提供高质量的交付成果，我们应该确保理解总体需求。如果我们理解短期和中期的业务需求，那么我们可以设计一个解决方案来满足短期需求。然后可以将短期解决方案发展为完整的解决方案。

在此阶段确定以下方面：

• 应用于数据的业务规则。

• 数据仓库中信息的逻辑模型。

• 当前需求的查询配置文件。

• 提供此数据的源系统。

技术蓝图

此阶段需要交付一个满足长期需求的整体架构。此阶段还将交付必须在短期内实施才能获得任何业务利益的组件。蓝图需要确定以下内容：

• 整体系统架构。
• 数据保留策略。
• 备份和恢复策略。
• 服务器和数据仓储架构。
• 硬件和基础设施的容量规划。
• 数据库设计的组件。

构建版本

在此阶段，将生成第一个生产交付成果。此生产交付成果是数据仓库的最小组件。此最小组件增加了业务效益。

历史加载

这是将所需其余历史数据加载到数据仓库的阶段。在此阶段，我们不添加新的实体，但可能会创建额外的物理表来存储增加的数据量。

让我们举个例子。假设构建版本阶段交付了一个包含 2 个月历史数据的零售销售分析数据仓库。此信息将允许用户仅分析近期趋势并解决短期问题。在这种情况下，用户无法识别年度和季节性趋势。为了帮助他做到这一点，可以从存档中加载过去 2 年的销售历史记录。现在，40GB 的数据扩展到 400GB。

注意 - 备份和恢复过程可能会变得复杂，因此建议在单独的阶段执行此活动。

特设查询

在此阶段，我们配置一个用于操作数据仓库的特设查询工具。这些工具可以生成数据库查询。

注意 - 建议在数据库发生重大修改时不要使用这些访问工具。

自动化

在此阶段，运营管理流程将完全自动化。这些将包括：

• 将数据转换为适合分析的形式。

• 监控查询配置文件并确定适当的聚合以维护系统性能。

• 从不同的源系统提取和加载数据。

• 从数据仓库中预定义的定义生成聚合。

• 备份、恢复和存档数据。

扩展范围

在此阶段，数据仓库将扩展以满足一组新的业务需求。可以通过两种方式扩展范围：

• 通过将额外数据加载到数据仓库中。

• 通过使用现有信息引入新的数据仓储。

注意 - 由于此阶段涉及大量工作和复杂性，因此应单独执行。

需求演变

从交付流程的角度来看，需求始终是可变的。它们不是静态的。交付流程必须支持这一点，并允许将这些更改反映到系统中。

这个问题是通过围绕业务流程中数据的使用来设计数据仓库来解决的，而不是现有查询的数据需求。

该架构旨在改变和发展以匹配业务需求，该流程作为一个伪应用程序开发流程运行，其中新的需求不断被输入到开发活动中，并产生部分交付成果。这些部分交付成果会被反馈给用户，然后进行重新设计，确保整个系统不断更新以满足业务需求。