数据仓库永远不会是静态的。它随着业务的发展而发展。随着业务的发展，其需求不断变化，因此必须设计数据仓库以应对这些变化。因此，数据仓库系统需要灵活。

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

运输方式

交付方法是用于数据仓库交付的联合应用程序开发方法的一种变体。我们已经上演了数据仓库交付过程，以最大程度地降低风险。我们将在此处讨论的方法不会减少整体交付时间，但可以确保在开发过程中逐步交付业务收益。

注–交付过程分为多个阶段，以降低项目和交付风险。

下图说明了交付过程中的各个阶段-

IT策略

数据仓库是需要业务流程才能产生收益的战略投资。需要IT战略来采购和保留该项目的资金。

商业案例

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

教育与原型

组织在尝试解决方案之前尝试数据分析的概念，并就拥有数据仓库的价值进行自我教育。这可以通过原型解决。它有助于理解数据仓库的可行性和好处。小规模的原型制作活动可以促进教育过程，只要-

• 该原型解决了已定义的技术目标。

• 在显示出可行性概念之后，可以将原型扔掉。

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

• 活动时间表并不重要。

要提早发布并带来业务收益，请记住以下几点。

• 确定能够发展的架构。

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

• 将第一个构建阶段的范围限制在可带来业务收益的最小范围内。

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

业务需求

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

在此阶段确定以下方面-

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

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

• 即时需求的查询配置文件。

• 提供此数据的源系统。

技术蓝图

此阶段需要提供满足长期需求的总体架构。此阶段还提供了必须在短期内实施的组件，才能获得任何业务收益。蓝图需要确定以下内容。

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

建立版本

在此阶段，生产出第一批生产交付品。此生产交付物是数据仓库的最小组成部分。这个最小的组件增加了业务收益。

历史载入

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

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

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

临时查询

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

注–在对数据库进行实质性修改时，建议不要使用这些访问工具。

自动化

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

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

• 监视查询概要文件并确定适当的聚合以维护系统性能。

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

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

• 备份，还原和归档数据。

扩大范围

在此阶段，数据仓库被扩展以解决一组新的业务需求。范围可以通过两种方式扩展-

• 通过将其他数据加载到数据仓库中。

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

注–此阶段应单独执行，因为它涉及大量的工作和复杂性。

需求演变

从交付过程的角度来看，需求始终是可变的。它们不是静态的。交付过程必须对此提供支持，并允许这些更改反映在系统中。

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

该体系结构旨在进行更改和发展，以适应业务需求，该过程作为伪应用程序开发过程运行，在此过程中，新需求不断地馈送到开发活动中，并产生部分可交付成果。这些部分可交付成果将反馈给用户，然后进行重新处理，以确保不断更新整个系统以满足业务需求。